Par Henry Precheur et Kevin Jamieson

La réplication continue de Qumulo garantit qu'une copie à jour des données d'un cluster est répliquée dans un cluster Qumulo hors site ou dans le cloud. Cela permet à nos clients de dormir paisiblement la nuit en sachant qu'ils peuvent récupérer rapidement en cas de catastrophe naturelle ou de défaillance catastrophique.

Comment un système de fichiers pouvant traiter des milliards de fichiers et des pétaoctets de données parvient-il à conserver une copie des données généralement à jour en quelques minutes?

Les outils traditionnels de sauvegarde incrémentielle tels que rsync et robocopy ne sont tout simplement pas à l’échelle. Ces outils identifient les modifications entre un répertoire source et un répertoire de destination en parcourant l’ensemble de l’arborescence de répertoires pour comparer les attributs - typiquement la taille et l’heure de modification - ou les données de chaque fichier.

Lorsque seulement quelques fichiers peuvent avoir été modifiés entre les fichiers incrémentiels, même avec une parallélisation, parcourir des milliards de fichiers pour identifier ces modifications peut prendre des heures, voire des jours.

Chez Qumulo, l'un de nos mantras est «pas d'arborescence». La réplication continue de Qumulo est optimisée par la même agrégation en temps réel qui permet à nos fonctions d'analyse et de quota efficaces d'éviter les arborescences. Avec les instantanés, cela permet d'identifier efficacement les modifications apportées au système de fichiers et de les répliquer avec le minimum de temps et d'E / S.

La réplication continue fonctionne en prenant continuellement un nouvel instantané, en comparant cet instantané avec le dernier instantané répliqué et en répliquant les différences. Chaque instantané possède un identifiant ou une «époque» unique et auto-incrémenté; associé à chaque fichier et répertoire, nous appelons ce que nous appelons une «époque modifiée en dernier lieu». Cela agit comme un horodatage décrivant le dernier instantané dans lequel ce fichier ou répertoire a changé.

Chaque fois qu'un fichier est modifié, sa dernière époque modifiée est mise à jour. De cette façon, nous savons si un fichier a changé sans regarder son contenu, mais cela ne suffit pas à lui seul pour localiser un fichier modifié sans passer par l’arbre. Nous mettons également à jour la dernière époque modifiée du répertoire parent du fichier et du répertoire parent de son parent, et ainsi de suite jusqu'au répertoire racine du système de fichiers. Cela laisse une trace pour trouver rapidement toutes les modifications apportées au système de fichiers entre les instantanés.

Lorsque la réplication continue est exécutée, nous comparons ces dernières époques modifiées au dernier instantané, en commençant par le répertoire racine. Si cette comparaison indique que le répertoire n'a pas changé depuis la dernière exécution de la réplication, vous pouvez l'ignorer ainsi que tout son contenu. Si le répertoire a changé, nous comparons de manière récursive la dernière époque modifiée de chaque fichier et sous-répertoire de ce répertoire pour déterminer quels fichiers ont été modifiés et doivent être copiés sur le cluster distant.

Considérons cet exemple simple:
/ home (epoch = 1)
| - alice / (epoch = 1)
| | - diagram.svg (epoch = 1)
| `- report.doc (epoch = 1)
`- bob / (epoch = 1)
`- project.psd (epoch = 1)

Initialement, chaque fichier a sa dernière époque modifiée définie sur 1. Lorsque Alice met à jour report.doc dans / home / alice, la dernière époque modifiée de report.doc et de tous ses répertoires ancêtres est définie sur 2. Après quoi le système de fichiers ressemble maintenant à ceci:
/ home (epoch = 2)
| - alice / (epoch = 2)
| | - diagram.svg (epoch = 1)
| `- report.doc (epoch = 2)
`- bob / (epoch = 1)
`- project.psd (epoch = 1)

L'époque inchangée de /home/alice/diagram.svg indique à la réplication continue de sauter ce fichier et de ne copier que le fichier report.doc mis à jour, tandis que l'époque de / home / bob indique à la réplication d'ignorer complètement ce répertoire et de ne pas en examiner le contenu. .

Qu'en est-il des fichiers partiellement modifiés? Si seulement quelques octets d'un fichier volumineux ont changé, il serait inutile de répliquer ce fichier avec une perte de temps et de bande passante. Il est beaucoup plus efficace de ne répliquer que le sous-ensemble de blocs du fichier qui ont réellement changé. Étant donné que le système de fichiers Qumulo stocke les données d'un fichier dans une structure arborescente en blocs de données, le même concept de dernière époque modifié permettant l'identification efficace des fichiers modifiés dans une arborescence de répertoires s'étend également à l'identification efficace des blocs de données modifiés dans chaque élément individuel. fichier.

Par exemple, supposons qu'un fichier 3MB soit créé et répliqué dans epoch 1, après quoi un utilisateur remplace uniquement le milieu du fichier par de nouvelles données. L'arborescence de données du fichier ressemblerait alors à ceci:
filet
| - 0 - 1MB (Epoch = 1)
| - 1 - 2MB (Epoch = 2)
`- 2 - 3MB (epoch = 1)

Nous trouvons les morceaux de données mis à jour dans un fichier de la même manière que nous trouvons les fichiers mis à jour dans un répertoire - en examinant les dernières époques modifiées de son arbre. Dans l'exemple ci-dessus, nous omettons le premier et le dernier fragment du fichier et ne répliquons que les données situées au milieu avec la période mise à jour. Nous ne faisons qu'un tiers du travail que nous aurions à faire si nous copions l'intégralité du fichier.

De cette manière, les époques agissent comme une piste vers les fichiers et les données contenues dans les fichiers modifiés entre les instantanés répliqués, permettant ainsi au système de réplication continue de Qumulo d'identifier toutes les différences dans le système de fichiers dans un délai proportionnel à la taille de celles-ci. différences, pas la taille totale du système de fichiers!

Partager avec votre réseau

OBTENIR UNE DEMO