Data Domain : Une vue d’ensemble des phases Clean/garbage collection (CG) des systèmes de fichiers Data Domain (DDFS)

Le système de fichiers Data Domain (DDFS) est différent de la plupart des implémentations de systèmes de fichiers courants, lorsqu’un fichier est supprimé de l’espace du système de fichiers utilisé par ce fichier n’est pas immédiatement disponible pour une réutilisation. Cela s’explique par le fait que le Data Domain Restorer (DDR) ne sait pas immédiatement si les données qui ont été référencées par le fichier supprimé sont également dédupliquées par rapport à d’autres fichiers et, par conséquent, qu’il est possible de supprimer ces données ou non.

Le nettoyage (parfois appelé garbage collection/CG) est le processus par lequel un DDR :

• Détermine quelles données sont superflues sur le disque (c’est-à-dire, qui ne sont plus référencées par des objets, tels que des fichiers ou des instantanés)
• Supprime physiquement les données superflues, ce qui permet de réutiliser l’espace disque sous-jacent (c’est-à-dire l’acquisition de nouvelles données).

Le mode Clean/GC est généralement planifié pour s’exécuter à intervalles réguliers (par défaut, il commence à 06h00 chaque mardi) et peut être :

• Exécution longue
• Calcul coûteux

Notez toutefois qu’il n’y a pas d’autre manière qu’en exécutant les méthodes Clean/GC, dans lesquelles les données peuvent être supprimées ou l’espace physiquement libéré sur un système de restauration Data Domain (c’est-à-dire qu’il n’y a pas de raccourcis pour accélérer ce processus).

Cet article décrit les éléments suivants :

• Les phases en fonctionnement normal sont généralement différentes
• Différents algorithmes de démarrage utilisés dans différentes versions de DDOS

Aucune

Chaque fois que le nettoyage/le GC est exécuté, il a deux objectifs principaux : tout d’abord, il doit trouver des données superflues sur le DDR-une brève présentation de la réalisation de cette opération est la suivante :

• Clean/GC énumère le contenu du système de fichiers DDFS à la recherche d’objets tels que les fichiers, les instantanés et les logs de réplication qui existent actuellement sur le système
• Elle détermine ensuite l’ensemble des données physiques sur disque qui sont activement référencées par ces objets.
• Les données qui sont activement référencées sont dites « Live » et ne peuvent pas être supprimées du DDR sinon, les objets faisant référence à ces données sont endommagés (ils ne peuvent plus être lus car les données sous-jacentes dont ils dépendent ne sont plus disponibles sur le disque).
• Les données qui ne sont pas référencées activement par un objet sont dites « inactifes » et sont superflues : ces données peuvent être supprimées en toute sécurité du système.
• Toutes les données d’une DDR sont compressées en objets d’une taille de 4,5 Mo, connue sous le nom de conteneurs
• L’énumération Clean/GC peut déterminer les conteneurs de 4,5 Mo qui contiennent des données inactives et la quantité de données inactives dans chaque
• Par défaut, le nettoyage/la CG sélectionne les conteneurs de 4,5 Mo, qui hébergent > 8% des données inactives pour le traitement

Ensuite, il doit supprimer les données inactives sur le DDR-une brève explication de la façon dont cela est fait est la suivante :

• Les conteneurs sélectionnés pour le traitement sont de nouveau vérifiés pour confirmer qu’ils tiennent une bonne quantité de données inactives
• Les données en temps réel sont extraites de ces conteneurs et écrites dans les nouveaux conteneurs de 4,5 Mo à la fin du système de fichiers.
• Une fois cette opération terminée, les conteneurs sélectionnés (y compris les données inactives qu’ils contiennent) sont supprimés du disque, ce qui libère physiquement de l’espace disque.

Le processus de désinstallation est divisé en plusieurs phases dont le nombre total de phases dépend de :

• La version de l’DDOS utilisé sur le DDR (par conséquent, l’algorithme de démarrage utilisé, par défaut, par cette version de DDOS)
• Configuration/contenu du système

En général, toutefois, le processus de conclusion des données « inactifes » et de sélection des conteneurs correspondants a lieu sur plusieurs phases, tandis que la suppression des données inactives s’effectue en une seule phase connue sous le nom de « copie ». Par exemple, certaines versions de DDOS exécutent des phases propres, comme suit :

1. Pre-Enumeration : énumérer le contenu du système de fichiers DDFS
2. Pre-Merge : effectuez une fusion d’index DDFS pour vous assurer que la dernière copie des informations d’index est vidée sur le disque.
3. Pre-Filter : Déterminez si des données sont dupliquées au sein du système de fichiers DDFS et, si c’est le cas.
4. Pre-Select : Déterminez les conteneurs de 4,5 Mo qui doivent être traités par le nettoyage
5. Copy : extrait physiquement les données actives des conteneurs sélectionnés, les écrit dans les nouveaux conteneurs, puis supprime les conteneurs sélectionnés.
6. Summary : vecteurs récapitulatifs de reconstruction (qui sont utilisés comme optimisation lors de l’acquisition de nouvelles données)

Dans les exemples de phases ci-dessus, les étapes 1-4 sont utilisées pour déterminer où se trouvent les données inactives sur le DDR (appelées « phases d’énumération » dans le reste de ce document) alors que la phase 5 (copie) est utilisée pour supprimer physiquement ces données.

Notez qu’aucun espace ne sera physiquement libéré sur le système jusqu’à ce que le nettoyage/le GC atteigne la phase de copie. Par conséquent, il peut y avoir un délai significatif entre le démarrage du processus et l’espace à partir duquel il est libéré (en raison du processus d’énumération qui doit être exécuté pour la première fois). Pour cette raison, les systèmes ne doivent pas être autorisés à remplir 100% pleins avant le démarrage de l’opération de nettoyage/nettoyage.

Les phases d’énumération ont tendance à être onéreuses en termes d’utilisation du CPU (c’est-à-dire qu’elles sont généralement liées à l’UC) alors que la phase de copie est onéreuse en termes de CPU et d’e/s (c’est-à-dire qu’il s’agit généralement de CPU et d’e/s). En résumé, cependant, il est possible de déclarer :

• La longueur totale des phases d’énumération dépend de la quantité de données sur le DDR qui doit être énumérée.
• La durée totale de la phase de copie dépend de la quantité de données inactives sur le DDR qui doivent être supprimées et de la façon dont les données se trouvent sur le disque (décrites ci-dessous).

Le nombre/la fonctionnalité des phases d’énumération dépend de la version de DDOS utilisée sur un DDR.

DDOS 5,4 (et versions antérieures) : algorithme de démarrage complet : Exécute 6 ou 10 phases (comme indiqué ci-dessus) :

• Le contenu du système de fichiers DDFS est énuméré dans la partie supérieure (c’est-à-dire centrée sur les fichiers)
• DDFS Découvre tous les fichiers qui existent sur le DDR, puis analyse chaque fichier à son tour afin de déterminer quelles données sont référencées par ce fichier.
• Cela permet à Clean/GC de déterminer quelles données sur le disque sont actives.

DDOS 5,5 (et versions ultérieures)-algorithme de démarrage physique (PGC) : Exécute des phases de 7 ou 12 :

• Le contenu du DDFS est énuméré en bas (c’est-à-dire qu’il n’analyse plus les fichiers individuels)
• DDFS Découvre les métadonnées du système de fichiers qui font référence aux données physiques sur le disque et analyse les métadonnées afin de déterminer quelles données sont référencées.
• Cela permet à Clean/GC de déterminer quelles données sur le disque sont actives.
• Cela est rendu possible par l’ajout d’une phase d’analyse (par conséquent, l’augmentation du nombre de phases sur l’algorithme de démarrage complet).
• Dans la plupart des cas, il est prévu que la durée totale de la sauvegarde physique soit inférieure à la durée totale du même système (malgré des phases différentes).

DDOS 6,0 (et versions ultérieures) : parfait algorithme de démarrage physique (PPGC) :

• Il s’agit simplement d’une optimisation de l’algorithme de démarrage physique et est abordé plus en détail ci-dessous.

Notez que DDOS est passé de l’algorithme de démarrage complet à l’algorithme de démarrage physique afin d’améliorer l’évolutivité et les performances du processus d’énumération, en raison de la nature de la partie supérieure de l’algorithme de démarrage complet qu’il n’a pas bien adapté aux DDR, avec l’une des méthodes suivantes :

• Un grand nombre de petits fichiers (comme commutateur de contexte lors du passage de l’énumération d’un fichier au suivant était coûteux/lent)
• Taux de déduplication élevé (étant donné que plusieurs fichiers font référence aux mêmes données physiques de manière à ce que les mêmes données soient énumérées plusieurs fois)

Vous pouvez basculer automatiquement les algorithmes DDR de Full vers les algorithmes de démarrage physique lors de la mise à niveau de DDOS 5,4 (ou version antérieure) vers 5,5 (ou version ultérieure). La seule exception à ce qui concerne les systèmes configurés avec Extended Retention, où le contenu du système de fichiers DDFS doit être vérifié pour que les fichiers « Spanning » puissent être activés, ce qui n’est pas le cadre de ce document, mais cette vérification s’exécute automatiquement après la mise à niveau et le nettoyage physique est activé à la fin de cette vérification sans aucune action manuelle.

De même, les DDR sont basculés automatiquement des algorithmes physiques vers les algorithmes de démarrage physique adaptés lors de la mise à niveau de DDOS 5. x vers 6,0 (ou version ultérieure). Toutefois, Notez que l’algorithme de suppression physique parfaite nécessite que les index soient au format « index 2,0 » avant d’être utilisés. Remarque :

• Le format « index 2,0 » a été introduit avec DDOS 5,5 (afin que tous les systèmes de fichiers créés sur 5,5 ou une version ultérieure utilisent déjà l’index 2,0).
• Le système de fichiers créé sur 5,4 ou une version antérieure avait initialement des index au format index 1,0. Après avoir effectué une mise à niveau vers DDOS 5,5 (ou version ultérieure), les index seront convertis au format de l’index 2,0. la conversion se produit chaque fois que le nettoyage s’exécute, mais seulement ~ 1% des index sont convertis lors de chaque nettoyage, ce qui peut prendre jusqu’à 2 ans (en supposant une exécution hebdomadaire) pour convertir entièrement les index au format 2,0.

Les DDR qui exécutent initialement DDOS 5,4 (ou une version antérieure), mais qui ont été mis à niveau vers DDOS 5,5 (ou version ultérieure), peuvent être forcés de convertir les index au format d’index 2,0 en une seule fois « index Rebuild ». Notez toutefois qu’une reconstruction d’index nécessite une période de temps indéfinie tandis que les index sont reconstruits physiquement. cette opération prend généralement 2-8 heures pour se poursuivre en fonction de la taille/quantité de données sur le DDR. Pour discuter de l’exécution d’une reconstruction d’index, contactez votre fournisseur de services de support contractuel.

Comme indiqué ci-dessus, quel que soit l’algorithme de nettoyage/nettoyage utilisé, le nettoyage peut nécessiter un certain nombre de phases. par exemple, l’algorithme de nettoyage complet peut nécessiter 6 ou 10 phases. Cela est dû au fait que :

• Lorsque DDFS est démarré, il réserve une quantité de mémoire fixe à utiliser par le nettoyage/nettoyage.
• Dans ce nettoyage de la mémoire, cette opération crée des structures de données afin de décrire les résultats de l’énumération (par exemple, la description du fait que les données dynamiques et inactives existent sur le disque).
• Lorsqu’un DDR contient une quantité relativement petite de données, l’ensemble du contenu du système de fichiers DDFS peut être décrit dans cette zone de mémoire.
• Dans de nombreux systèmes, toutefois, cela n’est pas possible et cette zone de mémoire serait épuisée avant que l’intégralité du contenu du système de fichiers DDFS n’ait été énumérée.
• Par conséquent, ces systèmes effectuent l’échantillonnage, ce qui augmente le nombre de nouvelles phases requises.

Lorsque l’échantillonnage est utilisé en mode Clean/GC :

• Exécution d’une passe d’échantillonnage de l’énumération sur l’ensemble du système de fichiers : Notez que cette énumération n’est pas « terminée » (c’est-à-dire qu’elle n’enregistre pas toutes les informations complètes sur chaque partie du système de fichiers, mais plutôt des informations approximatives pour chaque partie du système de fichiers)
• Utilisez ces informations d’échantillonnage pour déterminer quelle partie du système de fichiers DDFS devrait tirer le meilleur parti de l’exécution du nettoyage/du nettoyage du système de fichiers (c’est-à-dire que la partie du système de fichiers donnera la meilleure référence en termes d’espace libéré s’il a été nettoyé).
• Effectuez un second cycle d’énumération complète par rapport à la partie sélectionnée du système de fichiers dont le contenu peut désormais être entièrement décrit dans la mémoire réservée au CG.

L’échantillonnage est activé automatiquement au cours du nettoyage/du CG, si nécessaire, mais cela peut entraîner :

• Augmentation du nombre de phases nécessitant d’être exécutées par le nettoyage/la CG
• Augmentation correspondante de la durée totale du nettoyage/de la CG

Avant DDOS 6,0, la majorité des DDR effectue l’échantillonnage pendant le nettoyage/le nettoyage (sauf s’ils conservent un ensemble de données relativement petit). L’algorithme de nettoyage physique parfait, cependant, inclut diverses optimisations pour réduire la quantité de mémoire requise par Clean/GC lors de l’énumération des données au sein du système de fichiers. En d’autres termes, de nombreux systèmes qui effectuaient des échantillonnages lors de l’opération Clean/GC sur DDOS 5. x ne nécessiteront plus d’échantillonnage sur DDOS 6,0. cela réduit donc le nombre de phases effectuées par le nettoyage et entraîne une diminution de la durée totale de l’exécution (par exemple, une amélioration des performances).

Aucune information n’est disponible pour déterminer directement qu’un système a basculé de l’algorithme de démarrage physique à l’algorithme de suppression physique parfaite autre que :

• Lorsque le système exécutait Physical Clean sur DDOS 5,5-5,7, il exécutait 12 phases pendant le nettoyage.
• Suite à la mise à niveau du système vers DDOS 6,0 (ou version ultérieure), il n’effectue que 7 phases au cours du démarrage.

Si un système exécutant DDOS 6,0 doit toujours effectuer l’échantillonnage, celui-ci sera automatiquement activé pendant le fonctionnement normal, ce qui entraînera l’exécution de 12 phases au cours du démarrage.

Quel que soit l’algorithme de démarrage utilisé, la phase Copy (où les données inactives sont physiquement supprimées du système) fonctionne de la même manière sur toutes les versions. Les performances de la phase de copie dépendent généralement des éléments suivants :

• Quantité de données inactives qui doivent être supprimées
• « Fragmentation » de ces données inactives (par exemple, la façon dont elles sont réparties sur le disque)

Comme indiqué ci-dessus, la copie fonctionne en sélectionnant des conteneurs de 4,5 Mo qui stockent les données inactives, en extrayant les données en cours à partir de ces conteneurs et en écrivant les données en temps réel dans les nouveaux conteneurs, puis en supprimant les conteneurs initialement sélectionnés. Les exemples suivants décrivent la raison pour laquelle la fragmentation des données inactives est importante :

exemple 1 :

• 10 conteneurs sont sélectionnés pour la copie (données totales 45 Mo)
• Tous si ces conteneurs ne contiennent aucune donnée Live (par exemple, les données qu’ils contiennent ne sont pas entièrement référencées/inactives)
• En effet, la copie de résultat doit simplement marquer ces conteneurs comme supprimés pour libérer de l’espace physique 45 Mo sur le disque.

Exemple 2 :

• les conteneurs 100 sont sélectionnés pour la copie (données totales 450Mb)
• Chacun de ces conteneurs conserve 90% de données en temps réel/10% inactifs
• Pour traiter la copie de ce conteneur :

Le nombre d’e/s et le CPU nécessaires à l’exécution de la copie, comme indiqué dans l’exemple 2, sont donc nettement plus longs pour libérer de l’espace physique 45 Mo sur le disque dans cet exemple.

En général, les utilisateurs n’ont pas de contrôle sur la « fragmentation » des données inactives sur le disque d’un DDR étant donné que cela dépend de l’exemple d’utilisation/type de données en cours d’écriture sur le système. Toutefois, Notez que les opérations de nettoyage et de nettoyage conservent des statistiques qui permettent de déterminer la « fragmentation » des données inactives rencontrées au cours de la phase de copie (ce qui permet à l’utilisateur de déterminer si cette fragmentation peut expliquer une phase de copie potentiellement longue). Ces statistiques de la dernière phase de Clean/GC sont collectées dans autosupports. Par exemple, l’exemple suivant illustre une phase de copie où les données inactives étaient assez contiguës (c’est-à-dire la majorité des conteneurs sélectionnés pour la copie en tant que données

inactives) : pourcentage des données en cours de copie :              3,6% 4,3%

Inversement, l’exemple suivant illustre une phase de copie où les données inactives ont été fragmentées (c’est-à-dire la majorité des conteneurs sélectionnés pour la copie, principalement en temps réel) :

pourcentage des données Live dans la copie :             70,9% 71,5%

Comme décrit ci-dessus, le nettoyage/le nettoyage doit être effectué de manière comparativement plus importante dans le deuxième scénario pour libérer physiquement de l’espace sur le DDR, ce qui entraînera une réduction du débit de la phase de copie.

Le débit de la phase de copie peut également être affecté par les éléments suivants :

• Utilisation du chiffrement : Vous devrez peut-être déchiffrer/rechiffrer les données au cours de la copie, ce qui augmente considérablement la quantité de CPU requise.
• Utilisation de l’optimisation de bande passante faible : Les conteneurs peuvent nécessiter des informations « d’esquisse » à générer lors de la copie, ce qui entraîne également une augmentation significative de la quantité de CPU requise.

Notez que si l’optimisation de bande passante faible et/ou le chiffrement ont été activés récemment, tous les conteneurs existants (qu’ils soient sélectionnés pour la copie ou non) devront peut-être être cryptés et/ou avoir des informations d’esquisse générées par rapport à celles-ci au cours du démarrage suivant. cela peut entraîner une opération de désinstallation plus longue que la normale

Vous trouverez plus d’informations sur la vérification et la modification de la planification et de la régulation dans l’article suivant de la base de connaissances : https://support.emc.com/kb/306100

Notez toutefois que :

• En temps normal, l’exécution doit être planifiée pour s’exécuter au maximum une fois par semaine. l’exécution de données sur le disque peut entraîner une indisponibilité excessive des données sur le disque, ce qui peut entraîner un ralentissement des performances de lecture/réplication/déplacement des données.
• La régulation propre n’affecte pas la quantité totale de CPU et la bande passante d’e/s consommée par le mode Clean-au lieu de cela, elle contrôle la façon dont la charge est sensible à d’autres charges applicatives sur le système. Par exemple :

• Par défaut, la régulation du niveau de charge est définie sur 50. il incombe à l’utilisateur de tester l’exécution de la commande Clean with differents Settings, tandis que les DDR connaissent une charge applicative normale pour déterminer un paramètre de régulation qui permet d’effectuer les opérations suivantes :

• Notez qu’un certain temps d’exécution n’est pas nécessairement un problème, tant que :

• Vous devez configurer le système à l’aide de la fonction Extended Retention de la manière suivante :

• Vous trouverez des informations complètes à partir de la dernière opération de suppression dans les informations et les informations d’Autosupport :