Data Domain : Le nettoyage planifié ne démarre pas et affiche l’avertissement « EVT-GC-00002 : Impossible de démarrer le nettoyage planifié du système de fichiers »

Le nettoyage DataDomain (nettoyage de la mémoire, GC) est planifié pour s’exécuter à des jours et heures particuliers. Dans DDOS 6.0.x et versions supérieures, lorsqu’il existe un tel planning et que, pour une raison quelconque, le processus de nettoyage ne peut pas être démarré, le processus de surveillance du système s’en rend compte et finit par déclencher une alerte, comme celle ci-dessous :

# alerts show current
# alerts show current
Id      Post Time                  Severity   Class         Object       Message
-----   ------------------------   --------   -----------   ---------    -----------------------------------------------------------------------------------------
m0-11   Tue Jun 27 16:32:03 2017   WARNING    Filesystem                 EVT-GC-00002: Unable to start scheduled file system cleaning on Tue Jun 27 16:04:00 2017.
-----   ------------------------   --------   -----------   ---------    -----------------------------------------------------------------------------------------

 

En outre, un ASUP d’alerte est envoyé avec des détails comme celui-ci :

Hostname: dd-6800
Location: Lab4_Row_M System
SerialNo: APMxxxxxxxxxxxxxx
Chassis SerialNo: FCxxxxxxxxxxxxxxx
ModelNo: DD6800
Version: 6.0.0.1
Time: Tue Jun 27 16:15:02 2017
Alert Id: m0-11
Event Id: EVT-GC-00002
Event Message: Unable to start scheduled file system cleaning on Tue Jun 27 16:04:00 2017.
Event Description: Cleaning has not started as scheduled. Space for deleted files will not be reclaimed until cleaning completes. This may impact the ability to backup.
Recommended Action: Determine the reason why cleaning did not start. Manually start cleaning if free space needs to be reclaimed before the next scheduled cleaning.
If problem persists, contact your contracted support provider or visit us online at https://support.emc.com. 

 

L’alerte signale uniquement qu’un processus de nettoyage planifié n’a pas pu être démarré à l’heure prévue. Il y a plusieurs raisons possibles à cela, dont la plupart ne sont pas une indication d’un problème. Les raisons pour lesquelles l’alerte peut être déclenchée sont les suivantes :

• DD GC était déjà en cours d’exécution au moment où le processus de nettoyage planifié a dû démarrer. Étant donné qu’un seul processus GC peut être exécuté à la fois, et que la tentative d’un processus ne préempte pas un GC en cours d’exécution, le processus planifié a été ignoré, d’où l’alerte
• Actions incompatibles avec le GC, telles que, par exemple, l’exécution du mouvement des données (FMIG) du niveau de stockage actif vers le niveau de stockage d’archive ou l’exécution du nettoyage du niveau Cloud au moment où le GC du niveau actif était sur le point de démarrer
• Une modification précédente du fuseau horaire du système peut avoir fait en sorte que le démon « cron » interne en charge des tâches planifiées soit toujours en cours d’exécution sur l’ancien fuseau horaire, au lieu du nouveau, de sorte qu’en fonction des fuseaux horaires précédents et actuels, DD GC peut être exécuté plusieurs heures plus tôt ou plus tard que prévu, déclenchant ainsi l’alerte pour le GC ignoré. Vous pouvez consulter KB Data Domain : Modification de la date/heure et/ou du fuseau horaire sur un Data Domain Restorer (DDR) pour plus de détails sur les modifications de fuseau horaire dans un système DD
• En interne, le nettoyage DD est démarré en soumettant une tâche au processus « sms » interne pour la commande « filesys clean start ». Si « sms » ne répond pas ou si le système de fichiers ne répond pas à temps aux « sms », le GC ne démarre pas et est ignoré. Vous pouvez vérifier dans le journal « sms.info » les entrées correspondantes telles que celles-ci, ce qui indiquerait que le nettoyage a été tenté mais que la tâche n’a pas pu être démarrée :

02/28 12 :00 :26.495 (tid 0xa79c040) : completed job : 3278752 for operation : sms_filesys_clean_start, duration : 25067 msec, status : Le système de fichiers ne répond pas.

• Identique à ce qui précède, mais en raison du « saut en arrière dans le temps », le service de cron n’est pas synchronisé avec le nouveau jeu de temps Nous
  pouvons trouver quelque chose comme ce qui suit sur ASUP :

config.snmp.trapinfo.17 = Le système de fichiers est désactivé en raison d’une condition critique. EVT-OBJ ::Enclosure=1 EVT-INFO ::Cause=System Time backward jumped
config.snmp.trapinfo.19 = Impossible de démarrer le nettoyage planifié du système de fichiers le mardi 15 novembre 2022 06 :00 :00.

• Si le système de fichiers est arrêté, ne répond pas, ou qu’un basculement HA a eu lieu à ce moment-là, ou que DD redémarrait ou était arrêté, le GC peut également avoir été ignoré

Une autre raison pour laquelle nous avons vu dans le passé, bien que très rarement, pour que GC soit ignoré, est une certaine incohérence dans le calendrier de nettoyage dans le registre. Par exemple, le registre et l’interface de ligne de commande indiquent tous deux que l’exécution du GC est planifiée le dimanche à 06h00, heure locale :

# reg show collection.1.expunge.schedule
collection.1.expunge.schedule.days = Sun
collection.1.expunge.schedule.time = 0600

# filesys clean show config
Filesystem Cleaning Configuration
---------------------------------
        50 Percent Throttle
Filesystem cleaning is scheduled to run "Sun" at "0600".

 

Cependant, une autre clé de registre (collection.1.crontab.expunge), qui est utilisée par le planificateur de processus « crontab » pour démarrer les tâches configurées, est incorrecte, par exemple :

# reg show collection.1.crontab.expunge
collection.1.crontab.expunge = 00 6 * * 2 root /ddr/bin/ddsh -s filesys clean start nowait scheduled

 

La clé de registre ci-dessus indique que le nettoyage planifié doit être démarré à 06h00 heure locale le mardi (2 dans la cinquième spécification de tâche « crontab ») au lieu du dimanche (0).

Vous pouvez effacer l’alerte à tout moment, mais cela ne résoudra pas le problème sous-jacent et n’entraînera pas le démarrage immédiat du nettoyage. En fonction de la cause du cycle GC sauté, l’approche sera différente, et cet article de la base de connaissances n’entrera pas dans les détails à ce sujet. Veuillez consulter les articles de la base de connaissances DELL EMC DataDomain pour obtenir de l’aide ou, si ce n’est pas le cas, contactez votre fournisseur de support contractuel.


Dans le cas de 'Time backward jump' , nous pouvons simplement vérifier si la configuration reg correspond au planning 'filesys clean' et redémarrer le service cron :
* Remarque : la commande a besoin d’une console en mode bash, si vous ouvrez une nouvelle demande de service pour obtenir de l’aide auprès du support Data Domain.

1 | double-check job configuration
#  filesys clean show schedule
Filesystem cleaning is scheduled to run "Wed" at "1600".

# reg show collection.1.crontab.expunge
collection.1.crontab.expunge = 0 16 * * 3  root /ddr/bin/ddsh -s filesys clean start nowait scheduled

2 | set a new schedule if needed
# filesys clean set schedule Wed 1600

3 | Restart the cron service [you can use one of them]
# /etc/init.d/crond restart
or
# systemctl restart crond.service

 

Pour le problème des entrées de registre incohérentes uniquement, le correctif consiste à forcer la définition d’un planning de nettoyage correct à partir de l’interface de ligne de commande ou de l’interface de ligne de commande. Donc, en continuant avec l’exemple, l’administrateur devrait définir le planning de nettoyage sur le dimanche à 06h00 , même si « filesys clean show schedule » signale déjà que c’est le cas :

# filesys clean show schedule
Filesystem cleaning is scheduled to run "Sun" at "0600".

# filesys clean set schedule Sun 0600
Filesystem cleaning is scheduled to run "Sun" at "0600".

# filesys clean show schedule
Filesystem cleaning is scheduled to run "Sun" at "0600".

 

Après cela, vérifiez que la clé de registre indiquant un nettoyage à planifier pour le mauvais jour a été mise à jour :

# reg show collection.1.crontab.expunge
collection.1.crontab.expunge = 0 6 * * 0 root /ddr/bin/ddsh -s filesys clean start nowait scheduled