Data Domain: La pulizia pianificata non si avvia, con l'avviso U"EVT-GC-00002: Impossibile avviare la pulizia pianificata del file system"

L'esecuzione della pulizia di DataDomain (Garbage Collection, GC) è pianificata in giorni e orari specifici. In DDOS 6.0.x e versioni successive, quando è presente una pianificazione di questo tipo e, per qualsiasi motivo, il processo di pulizia non può essere avviato, il daemon di monitoraggio del sistema lo rileva e alla fine genera un avviso come quello riportato di seguito:

# 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.
-----   ------------------------   --------   -----------   ---------    -----------------------------------------------------------------------------------------

 

Inoltre, viene inviato un ASUP di avviso con dettagli come quelli riportati di seguito:

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'avviso informa solo che è presente un processo di pulizia pianificato che non è stato possibile avviare nel momento in cui avrebbe dovuto avviarsi. Molteplici possibili ragioni per questo, la maggior parte delle quali non sono un'indicazione di alcun problema. Ecco alcuni motivi per cui potrebbe essere attivato l'avviso:

• DD GC era già in esecuzione nel momento in cui è stato avviato il processo di pulizia pianificato. Poiché è possibile eseguire un solo processo GC in qualsiasi momento e il tentativo di eseguirne uno non impedisce la priorità di un GC in esecuzione, quello pianificato è stato ignorato e da qui l'avviso
• Azioni incompatibili con GC, come, ad esempio, l'esecuzione dello spostamento dei dati (FMIG) dallo storage tier attivo allo storage tier di archiviazione o l'esecuzione della pulizia del Cloud Tier al momento dell'avvio del GC del tier attivo
• Una precedente modifica del fuso orario del sistema potrebbe aver fatto sì che il daemon interno "cron" responsabile delle attività pianificate sia ancora in esecuzione nel vecchio fuso orario, anziché in quello nuovo, pertanto, a seconda dei fusi orari precedenti e correnti, DD GC potrebbe essere eseguito diverse ore prima o dopo del previsto, generando pertanto l'avviso per il GC ignorato. È possibile controllare KB Data Domain: Come modificare la data/ora e/o il fuso orario su un Data Domain Restorer (DDR) per ulteriori dettagli sulle modifiche del fuso orario in un DD
• Internamente, la pulizia DD viene avviata inviando un processo al daemon "sms" interno per il comando "filesys clean start". Se "sms" non risponde o se FS non risponde a "sms" in tempo, GC non si avvia e viene ignorato. È possibile controllare nel registro "sms.info" la presenza di voci corrispondenti come queste, che indicherebbero che è stato tentato di eseguire la pulizia, ma il processo non è stato avviato:

28/02 12:00:26.495 (Tid 0xa79c040): lavoro completato: 3278752 per il funzionamento: sms_filesys_clean_start, durata: 25067 msec, stato: Il file system non risponde.

• Come sopra, ma a causa di "Salto temporale all'indietro" il servizio cron non è sincronizzato con il nuovo tempo impostato
  , possiamo trovare qualcosa di simile al seguente su ASUP:

config.snmp.trapinfo.17 = Il file system è disabilitato a causa di una condizione critica. EVT-OBJ::Enclosure=1 EVT-INFO::Cause=Tempo di sistema saltato indietro
config.snmp.trapinfo.19 = Impossibile avviare la pulizia pianificata del file system il Tue Nov 15 06:00:00 2022.

• Se FS è inattivo, non risponde o in quel momento era in corso un failover HA oppure DD era in fase di riavvio o inattivo, anche GC potrebbe essere stato ignorato

Un altro motivo per cui abbiamo visto in passato, anche se molto raramente, per cui GC viene saltato, è una certa incoerenza per la pianificazione pulita nel registro. Ad esempio, sia il registro che la CLI mostrano che l'esecuzione di GC è pianificata la domenica alle 06:00 ora 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".

 

Tuttavia, una chiave di registro diversa (collection.1.crontab.expunge), utilizzata dall'utilità di pianificazione del processo "crontab" per avviare i processi configurati, non è corretta, ad esempio:

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

 

La chiave del Registro di sistema sopra indicata indica che la pulizia pianificata deve essere avviata alle 06:00 ora locale del martedì (2 nella quinta specifica di lavoro "crontab") anziché la domenica (0).

È possibile cancellare l'avviso in qualsiasi momento, ma questa operazione non risolverà il problema sottostante né comporterà l'avvio immediato della pulizia. A seconda della causa del ciclo GC ignorato, l'approccio sarà diverso e questo articolo della Knowledge Base non approfondirà ulteriormente l'argomento. Per assistenza, consultare gli articoli della Knowledge Base di DELL EMC DataDomain o, in caso contrario, contattare il provider di supporto a contratto.


Nel caso di 'Salto temporale all'indietro' possiamo semplicemente ricontrollare se la configurazione reg corrisponde al programma 'filesys clean' e riavviare il servizio cron:
* Nota: il comando richiede una console in modalità bash, nel caso in cui si apra una nuova SR per ottenere assistenza dal supporto di 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

 

Solo per il problema relativo alle voci di registro incoerenti, la correzione consiste nell'impostare forzatamente la pianificazione pulita corretta dalla CLI o dalla CLI. Quindi, continuando con l'esempio, l'amministratore dovrebbe impostare la pianificazione pulita sulla domenica alle 06:00 , anche se "filesys clean show schedule" segnala già che è così:

# 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".

 

Dopo aver eseguito questa operazione, verificare che la chiave di registro che indica la pulizia da pianificare per il giorno sbagliato sia stata aggiornata:

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