Data Domain : Comment surveiller le déplacement des données à l’aide d’un Data Domain Restorer

Certains modèles de Data Domain Restorer (DDR) peuvent être configurés avec une fonctionnalité appelée Extended Retention (ER) ou Long Term Retention (LTR). Cette fonctionnalité permet d’ajouter un deuxième niveau de stockage au système vers lequel les fichiers nécessitant une rétention à long terme peuvent être migrés. Le type de stockage utilisé pour ce second niveau dépend de la fonctionnalité spécifique utilisée, à savoir :

• Extended Retention : Le deuxième niveau de stockage, appelé niveau d’archivage, est constitué de boîtiers de disques physiquement reliés à la DDR
• Rétention à long terme : Le deuxième niveau de stockage, connu sous le nom de niveau Cloud, est formé à partir du stockage en mode objet provisionné à partir d’un fournisseur de Cloud pris en charge (c’est-à-dire externe à la DDR)

Mécanismes de déplacement des données :

Dans les deux cas, pour migrer physiquement le fichier du niveau actif vers le niveau d’archivage/Cloud, un processus appelé déplacement des données (FMIG) est utilisé. Lorsqu’il est lancé, le FMIG passe par 5 phases d’exploitation, comme décrit ci-dessous :

Phase 1 - Ensemencement en vrac :

• Cette opération est ignorée sur tous les systèmes compatibles LTR
• Cette opération est ignorée sur les systèmes ER exécutant DDOS 5.5.1.x (et versions ultérieures)
• Sur les systèmes ER exécutant DDOS 5.5.0.x (et versions antérieures), cette opération peut effectuer une copie en mode bloc des données sélectionnées à partir du niveau actif vers le niveau d’archivage. Les mécanismes de cette copie dépassent le cadre de ce document et ne sont donc pas abordés ici.

Phase 2 - Analyse :

• Le système de fichiers Data Domain (DDFS) recherche les fichiers du niveau actif qui sont candidats à la migration vers le niveau d’archivage/Cloud (fichiers qui n’ont pas été modifiés depuis plus longtemps que la règle de déplacement des données MTree parente/seuil d’âge)
• Un certain nombre de threads de copie sont démarrés (le nombre spécifique dépend du modèle/de la configuration du système) avec chacun des threads lisant un fichier candidat sur le niveau actif et copiant des données uniques vers le niveau d’archivage/Cloud (c’est-à-dire des données qui n’existent pas déjà sur le niveau cible)
• Un certain nombre de threads de vérification sont lancés (encore une fois, le nombre de threads spécifiques dépend du modèle/de la configuration du système) qui, une fois la copie du fichier candidat terminée, permettent de relire la copie du fichier à partir du niveau cible pour s’assurer qu’il est valide et que toutes les données sont accessibles
• Une fois qu’un fichier candidat a été copié/vérifié, il est ajouté à une liste de fichiers en attente d'« installation » dans le niveau cible (une mise à jour des métadonnées par rapport au fichier pour indiquer qu’il existe désormais sur le niveau cible). Périodiquement, un thread d’installation sort de veille pour « installer » tous les fichiers en attente

Phase 3 - Vérification :

• Au cours de cette phase, DDFS attend que la vérification de tous les fichiers copiés sur le niveau cible se termine

Phase 4 - Emballage :

• Cette opération est ignorée sur tous les systèmes compatibles LTR
• Sur les systèmes ER, FMIG tente de supprimer tous les segments de données dupliqués qui ont été copiés vers le niveau d’archivage lors de la phase d’analyse. Notez que des segments de données dupliqués peuvent être copiés pour accélérer le processus de copie. Toutefois, compte tenu de la conception du niveau d’archivage (taux de compression global maximal avec performances de lecture dégradées), ces données dupliquées doivent être supprimées

Phase 5 - Installation :

• Au cours de cette phase, DDFS attend que l’installation de tous les fichiers copiés/vérifiés se termine

Suivi de l’avancement du GMF :

Le shell de ligne de commande Data Domain (DDSH) est principalement utilisé pour surveiller la progression de FMIG sur les systèmes ER et LTR. Remarque :

• Sur les systèmes ER, les commandes 'archive data-movement [status|watch]' doivent être utilisées, tandis que sur les systèmes LTR, les commandes 'data-movement [status|watch]' doivent être utilisées, c’est-à-dire :

• Sur les systèmes ER, la progression des 5 phases est signalée (c’est-à-dire que la sortie affichera la « phase x sur 5 ») tandis que sur les systèmes LTR, étant donné que les phases 1 et 4 sont toujours ignorées, la progression des phases 2/3/5 est affichée uniquement (c’est-à-dire que la sortie affichera la « phase x de 3 »)
• La commande « status » affiche un snapshot ponctuel de la progression du FMIG :

• La commande « watch » affiche une sortie propagée au fur et à mesure que FMIG progresse d’une phase à l’autre :

Un ensemble de clés de registre est également utilisé pour suivre la progression du FMIG. Celles-ci sont capturées dans les autosupports générés par le système et peuvent également être affichées via DDSH :

ER : # reg show dynamic.art.fmig
LTR: # reg show state.fmig2

Dans les deux cas, les clés de registre affichées sont très similaires et, par conséquent, seules celles provenant d’un système compatible LTR sont affichées ici :

# reg show state.fmig2
state.fmig2_checked_inodes = 13 <=== NOMBRE TOTAL DE FICHIERS DANS L’ESPACE DE NOMMAGE DDFS VÉRIFIÉS POUR VOIR S’ILS RÉPONDENT AUX CRITÈRES POUR ÊTRE CANDIDATS
state.fmig2_end_time = 1470059610 <=== HEURE DE FIN DE LA DERNIÈRE EXÉCUTION DE FMIG
state.fmig2_fcopy_byte_count = 11274289151 <=== OCTETS PRÉ-COMP (LOGIQUES) COPIÉS VERS LE NIVEAU CIBLE JUSQU’À PRÉSENT
state.fmig2_fcopy_post_lc_size = 10944662855 <=== OCTETS POST-COMP (PHYSIQUES) COPIÉS VERS LE NIVEAU CIBLE, DONC PLUS TARD
...
state.fmig2_files_copied = 8 <=== FICHIERS DONT LA COPIE
EST TERMINÉE state.fmig2_files_failed_in_copy = 0 <=== FICHIERS DONT LA COPIE N’A PAS PU ÊTRE COPIÉE
state.fmig2_files_failed_in_install = 0 <=== FICHIERS COPIÉS/VÉRIFIÉS MAIS QUI N’ONT PAS PU ÊTRE INSTALLÉS
state.fmig2_files_failed_in_verify = 0 <=== FICHIERS COPIÉS MAIS VÉRIFIÉS
state.fmig2_files_installed = 4 <=== FICHIERS COPIÉS/VÉRIFIÉS/INSTALLÉS
state.fmig2_files_verified = 4 <=== FICHIERS QUI ONT TERMINÉ LA COPIE/VÉRIFICATION
...
state.fmig2_is_running = 1 <=== FMIG EST EN COURS D’EXÉCUTIONstate.fmig2_is_waiting = 0 <=== FMIG EST EN ATTENTE (PAR EXEMPLE POUR QUE LE NETTOYAGE SE TERMINE)
state.fmig2_progress_current_phase = 2 <=== PHASE ACTUELLE (DANS CE CAS, COPIE/NUMÉRISATION)
state.fmig2_progress_percent_complete = 92 <=== % D’ACHÈVEMENT DE LA PHASE ACTUELLE EN FONCTION DES FICHIERS VÉRIFIÉS PAR RAPPORT AU NOMBRE TOTAL DE FICHIERS DANS L’ESPACE DE
NOMS state.fmig2_progress_phase_time = 1 245
<=== SECONDES PASSÉES DANS LA PHASE ACTUELLE JUSQU’À PRÉSENT
state.fmig2_progress_total_time = 1255 <=== SECONDES D’EXÉCUTION DU FMIG JUSQU’À PRÉSENT
state.fmig2_start_time = 1470061560 <=== HEURE DE DÉBUT DE L’EXÉCUTION ACTUELLE DU FMIG...

state.fmig2_total_inodes = 14 <=== NOMBRE TOTAL DE FICHIERS À ARCHIVER DANS L’ESPACE DE
NOMMAGE...

Enfin, divers messages sont consignés dans les fichiers journaux DDFS (/ddr/var/log/debug/ddfs.info) pour indiquer la progression du FMIG. Là encore, la sortie est très similaire pour les fonctionnalités ER et LTR, de sorte que seuls ceux provenant d’un système compatible LTR sont affichés ici :

08/01 15:26:00.945 (tid 0x7ff4c683e090) : NOTICE: MSG-FMIG-00004 : Data-movement started <=== FMIG STARTS
...
08/01 15:26:00.977 (tid 0x7ff4cbeabcf0) : INFO: Fmig : phase 1 (seeding) started <=== BULK SEEDING STARTS (DOES NOT RUN ON LTR)
08/01 15:26:10.978 (tid 0x7ff4cbeabcf0) : INFO: Fmig : fin
de la phase 1 (ensemencement)08/01 15:26:10.978 (tid 0x7ff4cbeabcf0) : INFO: Fmig : phase 2 (numérisation) démarrée <=== DÉBUT
 
DE LA PHASE DE NUMÉRISATION08/01 15:26:22.162 (tid 0x4ca2150) : Fmig : candidate file /data/col1/jftest/file2, src file snap_fh 10:0:12:0 :e8b645a6:57989b6e :0 <=== CANDIDATE FILE PICKED UP BY COPY THREAD
08/01 15:26:22.164 (tid 0x7ff4c5214670) : Fmig : candidate file /data/col1/jftest/file3, src file snap_fh 10:0:13:0 :e9b64736:57989b6e :0<=== CANDIDATE FILE STARTS COPY
08/01 15:26:22.273 (tid 0x7ff7d252a9e0) : Fmig : candidate file /data/col1/jftest/file4, src file snap_fh 10:0:14:0 :e6b64286:57989b6e :0 <=== CANDIDATE FILE STARTS COPY
08/01 15:26:22.274 (tid 0x7ff7d090a630) : Fmig : candidate file /data/col1/jftest/file5, src file snap_fh 10:0:15:0 :e7b64416:57989b6e :0 <=== CANDIDATE FILE STARTS COPY
 
08/01 15:27:11.072 (tid 0x7ff45ad95d30) : Fmig : fmig_dump_stats (Cloud) : phase 2, phase_time 61, total_time 71, total_inodes 14, checked_inodes 5, copied_files 0, verified_files 0, installed_files 0, failed_files_in_copy 0, failed_files_in_verify 0, failed_files_in_install 0, copied_vbytes 0, vbytes en cours 1936986672 <=== STATISTIQUES VIDÉES PÉRIODIQUEMENT
 
08/01 15:45:59.040 (tid 0x7ff7d25298c0) : Fmig : fmig verified file5, src file snap_fh 10:0:15:0 :e7b64416:57989b6e :0 <=== COPIED FILE COMPLETES VERIFICATION
08/01 15:45:59.140 (tid 0x7ff4c5218310) : Fmig : fmig verified file3, src file snap_fh 10:0:13:0 :e9b64736:57989b6e :0<=== COPIED FILE COMPLETES VERIFICATION
08/01 15:45:59.225 (tid 0x7ff4c540b5f0) : Fmig : fmig verified file2, src file snap_fh 10:0:12:0 :e8b645a6:57989b6e :0 <=== COPIED FILE COMPLETES VERIFICATION
08/01 15:45:59.228 (tid 0x7ff4e591bcd0) : Fmig : fmig verified file4, src file snap_fh 10:0:14:0 :e6b64286:57989b6e :0 <=== LE FICHIER COPIÉ TERMINE LA VÉRIFICATION
 
08/01 15:47:15.113 (tid 0x7ff45ad95d30) : Fmig : fmig_dump_stats (Cloud) : phase 2, phase_time 1265, total_time 1275, 14 total_inodes, 13 checked_inodes, 8 copied_files, 4 verified_files, installed_files 4, failed_files_in_copy 0, failed_files_in_verify 0, failed_files_in_install 0, copied_vbytes 10737418240, vbytes en cours 536870911 <=== PLUS DE STATISTIQUES PÉRIODIQUES
 
08/01 15:47:41.858 (tid 0x7ff4cbeabcf0) : INFO: Fmig : phase 2 (scanning) ended <=== SCANNING PHASE COMPLETES (ALL CANDIDATE FILES COPIED)
08/01 15:47:41.858 (TID 0x7ff4cbeabcf0) : INFO: Fmig : phase 3 (vérification) démarrée <=== VÉRIFICATION DES DÉBUTS
 
DE LA PHASE08/01 15:47:57.855 (tid 0x7ff50351a620) : Fmig : fmig verified file10, src file snap_fh 10:0:1a :0:64f703c6:57989b6e :0 <=== REMAINING FILES VERIFIED
08/01 15:47:57.875 (tid 0x7ff4cbeabcf0) : INFO: Fmig : phase 4 (packing) ended <=== PACKING PHASE (DOES NOT RUN ON LTR)
08/01 15:47:57.875 (tid 0x7ff4cbeabcf0) : INFO: Fmig : phase 5 (install) started <=== INSTALL PHASE STARTS
08/01 15:48:08.890 (tid 0x7ff4cbeabcf0) : INFO: Fmig : phase 5 [install] ended<=== INSTALL PHASE ENDS
 
08/01 15:48:35.337 (tid 0x7ff4cbeabcf0) : NOTICE: MSG-FMIG-00001 : Data-movement completed (cloud) on cloud cps : 0:22:35 écoulé, 9 fichiers migrés, 11274289152 du total des octets migrés< === FMIG COMPLETES
08/01 15:48:35.337 (tid 0x7ff4cbeabcf0) : INFO: Fmig :  Phase[1] : Phase de 10 secondes[2] : 1291 secs Phase[3] : 16 secs Phase[4] : 0 secs Phase[5] : 11 s === DURÉES DE PHASE INDIQUÉES<

Notez que :

• Les chiffres indiquant la quantité de données post-compression (physiques) copiées sur le niveau cible ne sont mis à jour qu’à la fin de la copie d’un fichier. Par conséquent, si un seul fichier volumineux est en cours de migration, post-comp affiche 0 octet jusqu’à ce que la copie (et la phase d’analyse) soit terminée
• Les chiffres indiquant la quantité de données (logiques) avant compression copiées vers le niveau cible sont mis à jour régulièrement et pas uniquement à la fin de la copie des fichiers
• Le % terminé indiqué lors de la phase d’analyse n’indique pas le pourcentage total de données candidates copiées jusqu’à présent. Au lieu de cela, il indique le pourcentage de fichiers totaux dans l’espace de nommage DDFS qui ont été vérifiés jusqu’à présent par les threads de copie afin de déterminer s’ils sont candidats à la migration. Par conséquent, lorsque FMIG est en phase de numérisation, il est courant de voir :