Data Domain : présentation de la rétention à long terme/du nettoyage du niveau Cloud/du nettoyage de la mémoire sur les restaurateurs Data Domain (DDR)

Data Domain Operating System (DDOS) 6.0 introduit une nouvelle fonctionnalité appelée rétention Cloud ou rétention à long terme (LTR). Cette fonctionnalité permet d’ajouter un deuxième niveau de stockage en mode objet provisionné par un fournisseur de Cloud à certains modèles de Data Domain Restorer (DDR) avec une licence CLOUD_CAPACITY associée.

Sur les systèmes qui utilisent des fichiers LTR ingérés par le DDR, ces derniers sont d’abord écrits sur le niveau actif (stockage rattaché localement). Les règles de déplacement des données/seuils d’âge sont ensuite configurées sur une base par arborescence MTree, de sorte que certains fichiers nécessitant une rétention à long terme soient migrés ultérieurement du niveau actif vers le niveau Cloud par le processus de déplacement des données (tâche planifiée régulièrement).

Les fichiers du niveau Cloud peuvent être supprimés normalement, mais l’espace associé sur le stockage Cloud/en mode objet n’est pas immédiatement récupéré pour utilisation. Pour supprimer les données superflues du Cloud, le niveau Cloud doit être nettoyé.

Structure du niveau Cloud :

le niveau Cloud est subdivisé en « unités de Cloud ». Remarque :

• le niveau Cloud peut contenir jusqu’à deux unités de Cloud
• Chaque unité de Cloud peut être aussi grande que la taille maximale prise en charge du niveau actif pour le modèle de DDR donné
• Chaque unité de Cloud peut être provisionnée à partir d’un fournisseur de stockage en mode objet distinct

Exemple :

# cloud unit list
Name                      Profile        Status
-----------------------   ------------   ------
B-unit                    LTR-ECS-Ben    Active <=== ECS provider
cloud-unit-virtustream1   virtustream1   Active <=== Virtustream provider
-----------------------   ------------   ------

Concepts de base du nettoyage du Cloud :

• Le nettoyage du Cloud ne fonctionne que sur une seule unité de Cloud lors de chaque exécution. Pour déterminer l’unité de Cloud nettoyée, le message suivant se trouve dans les journaux DDFS (/ddr/var/log/debug/ddfs.info). Dans ce cas, l’unité de Cloud cloud-unit-virtustream1 est en cours de nettoyage :

• Si un système dispose de plusieurs unités de Cloud configurées, le nettoyage du Cloud effectue le nettoyage par permutation circulaire de ces unités en essayant de nettoyer une seule unité chaque fois que le nettoyage du Cloud est exécuté
• Le nettoyage du Cloud peut être démarré manuellement ou automatiquement via une planification. Pour démarrer manuellement, la commande suivante est utilisée :

• Le nettoyage du niveau actif et le nettoyage du Cloud ne peuvent pas s’exécuter en parallèle (car les deux utilisent les mêmes structures de mémoire dans DDFS)
• Si le nettoyage du niveau actif est en cours d’exécution (démarré manuellement ou via sa planification) et que vous tentez de démarrer nettoyage du Cloud, une erreur s’affiche, par exemple :

• Si le nettoyage du Cloud a été démarré automatiquement (c’est-à-dire via sa planification) et que le nettoyage du niveau actif est démarré, le nettoyage de l’unité de Cloud est abandonné pour permettre l’exécution du nettoyage du niveau actif. Ceci est indiqué par ce qui suit dans les journaux DDFS :

• Si le nettoyage du Cloud a été démarré manuellement et que vous tentez de démarrer le nettoyage du niveau actif, le nettoyage du niveau actif ne démarre pas. Le nettoyage du Cloud reste en cours d’exécution jusqu’à la fin, c’est-à-dire :

• Pour que le nettoyage du Cloud démarre, une unité de Cloud doit avoir subi une perte de données d’au moins 1 % (c’est-à-dire >= 1 % des données actuellement présentes sur l’unité de Cloud doivent être considérées comme superflues et donc supprimables). Si ce n’est pas le cas, ce qui suit s’affiche sur la ligne de commande si le nettoyage du Cloud est démarré manuellement :

• Si un système contient deux unités de Cloud et que le nettoyage planifié de la première unité échoue pour une raison quelconque (par exemple, un taux de perte insuffisant), le nettoyage tente automatiquement de démarrer sur la deuxième unité (c’est-à-dire qu’il n’est pas nécessaire d’attendre la prochaine exécution planifiée du nettoyage du Cloud pour que la deuxième unité soit nettoyée)
• Le nettoyage du Cloud peut être régulé (de la même manière que le nettoyage du niveau actif) pour déterminer l’action à entreprendre lorsque le système est soumis à une autre charge applicative importante (c’est-à-dire ingestion/restaurations/réplication).

Planification de nettoyage du Cloud :

dans DDOS 6.0 et versions ultérieures, la façon dont le nettoyage du niveau actif est planifié n’a pas changé : par défaut, le nettoyage du niveau actif est planifié pour s’exécuter une fois par semaine à 0600 le mardi, c’est-à-dire :

# filesys clean show Schedule
Filesystem cleaning is scheduled to run "Tue" at "0600".

Par défaut, le nettoyage du Cloud est planifié pour s’exécuter tous les 4e appels de nettoyage du niveau actif planifié. Pour afficher la planification de nettoyage du Cloud, vous devez utiliser la commande suivante :

# cloud clean frequency show
Cloud tier cleaning frequency is set to run after every 4 active tier cleaning cycles.

Par conséquent, sur un système avec une configuration par défaut, le nettoyage du Cloud est démarré toutes les 4 semaines. Si le système dispose de deux unités de Cloud, chaque unité est nettoyée une fois toutes les 8 semaines.

Pour modifier la fréquence de nettoyage du Cloud, vous pouvez utiliser la commande suivante :

# Cloud Clean Frequency set 2
Cloud tier cleaning frequency is set to run after every 2 active tier cleaning cycles.

Pour réinitialiser le nettoyage du Cloud à sa planification par défaut de « après chaque nettoyage de 4 niveaux actifs », vous pouvez utiliser la commande suivante :

# Cloud Clean Frequency reset
Cloud tier cleaning frequency is reset to default (every 4 active tier cleaning cycles).

Lorsque vous planifiez le calendrier de nettoyage du Cloud, assurez-vous d’exclure les cycles de nettoyage du niveau actif démarrés manuellement. Par conséquent, sur le système ci-dessus, même si le nettoyage du niveau actif était exécuté manuellement chaque jour, le nettoyage du niveau Cloud ne commencerait qu’une fois toutes les 4 semaines.

Il est également possible de désactiver complètement le nettoyage de Cloud planifié à l’aide de la commande suivante :

# cloud clean frequency set never
Cloud tier cleaning frequency is set to "never".

Dans ce cas, le nettoyage du Cloud ne s’exécute que lorsqu’il est démarré manuellement.

Pour arrêter un nettoyage du Cloud en cours d’exécution, vous pouvez utiliser la commande suivante :

# cloud clean stop

Pour déterminer la date de la dernière exécution du nettoyage du Cloud, vous pouvez utiliser la commande suivante :

# cloud clean status
Cloud tier cleaning finished at 2016/08/01 20:54:43.

Algorithme du nettoyage du Cloud :

le nettoyage du Cloud utilise le même algorithme de nettoyage que celui configuré pour le niveau actif. Dans DDOS 6.0 et versions ultérieures, cette option est définie par défaut sur le nettoyage parfait de la mémoire physique (PPGC), mais elle peut être remplacée par le nettoyage de la mémoire physique (PGC) via les paramètres système.

Notez que le nettoyage de la mémoire ne doit pas être désactivé, car l’utilisation de l’algorithme de nettoyage traditionnel/complet pour nettoyer une unité de Cloud peut entraîner un dysfonctionnement/redémarrage de DDFS

L’algorithme utilisé pour le nettoyage du Cloud s’affiche dans les journaux DDFS lorsque le nettoyage démarre, c’est-à-dire :

06/28 10:51:56.960 (tid 0x7fc5bccb2d50): gc: gc_start_intern: Algorithme sélectionné : Physical Cleaning <=== PPGC or PGC
07/27 12:21:18.224 (tid 0x7f92b8cfe7e0): gc: gc_start_intern: Algorithme sélectionné : Full Cleaning <=== Traditional GC

Notez qu’à partir de la sortie ci-dessus, il n’est pas possible de faire la distinction entre PPGC et PGC (l’algorithme spécifique utilisé est évident en raison du nombre de phases exécutées par le nettoyage). En général :

GC traditionnel/complet : 10 phases
PGC : 12 phases
PPGC : 6 phases

Pour plus d’informations sur la modification de l’algorithme de nettoyage utilisé sur un système, contactez votre fournisseur de support sous contrat

Différences entre les phases de nettoyage du niveau actif et de copie propre du niveau Cloud :

la phase de copie du nettoyage est la phase où les données superflues sur un DDR sont physiquement supprimées/récupérées de l’espace. Notez que la copie fonctionne différemment entre les niveaux actif et Cloud :

Niveau actif :

• Les données écrites sur le niveau actif d’un DDR sont contenues dans des conteneurs de 4,5 Mo
• Par défaut, un conteneur ne sera pris en compte pour la « copie » par nettoyage que s’il contient <= 92 % de données « Live » (c’est-à-dire activement référencées)
• Les données actives seront extraites du conteneur et écrites dans un nouveau conteneur (avec les données actives d’autres conteneurs copiés) à la fin du système de fichiers
• Sur le disque, les index sont mis à jour pour refléter le nouveau conteneur contenant les données actives
• Le conteneur d’origine (contenant à la fois les données actives et inactives) est ensuite supprimé et l’espace disque sous-jacent est mis à disposition pour utilisation

Niveau Cloud :

• Les données écrites sur le niveau Cloud d’un DDR sont structurées différemment : au lieu d’être placées dans des conteneurs de 4,5 Mo, des fragments de données individuels (régions de compression de 64 Ko) sont écrits sur l’unité de Cloud. (Remarque : pour DDOS 6.1.2.0 et versions ultérieures, les objets stockés dans l’unité de Cloud seront plus volumineux, voir Data Domain : Grande taille d’objet pour le niveau Cloud pour plus d’informations)
• Au lieu d’extraire des données actives à partir d’une région de compression existante et de les copier, le nettoyage du Cloud ne prendra en compte que les régions de compression qui contiennent uniquement des données inactives à supprimer

Cette différence est due au coût inhérent à la lecture/écriture d’une grande quantité de données sur le stockage Cloud, mais cela signifie qu’une unité de Cloud peut devenir artificiellement saturée (c’est-à-dire contenir un grand nombre de régions de compression, chacune contenant une très petite quantité de données actives empêchant leur suppression).

Dans ce cas, il est possible de définir des paramètres système forçant un nettoyage de défragmentation de l’unité de Cloud. Cela permet de copier les données actives à partir des régions de compression existantes afin de consolider les données actives dans le moins de régions de compression possible, ce qui permet de libérer de l’espace.

Pour plus d’informations sur l’exécution d’un nettoyage de défragmentation, contactez votre fournisseur de support sous contrat.