Data Domain: Plánované čištění se nespustí, zobrazí se VAROVÁNÍ "EVT-GC-00002: Unable to start scheduled file system cleaning"

Vyčištění datové domény (Garbage Collection, GC) je naplánováno tak, aby se spouštělo v konkrétní dny a časy. Pokud v systému DDOS 6.0.x a novějších takový plán existuje a z nějakého důvodu nelze spustit proces čištění, démon monitorování systému si toho všimne a nakonec vyvolá výstrahu, jako je ta níže:

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

 

Odešle se také výstraha ASUP s podrobnostmi, jako je ta následující:

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. 

 

Výstraha pouze informuje o tom, že existuje naplánovaný proces čištění, který nebylo možné spustit v době, kdy měl být spuštěn. Existuje několik možných důvodů, z nichž většina nenaznačuje žádný problém. Mezi důvody, proč se výstraha může aktivovat, patří:

• Funkce DD GC byla v době zahájení plánovaného procesu čištění již spuštěna. Vzhledem k tomu, že v daném okamžiku lze spustit pouze jeden proces uvolňování paměti a pokus o něj nezabrání spuštěnému uvolňování paměti, byl naplánovaný proces přeskočen, a proto se výstraha
• Akce nekompatibilní s GC, jako je například spuštění přesunu dat (FMIG) z aktivní do archivní úrovně úložiště nebo spuštění čištění cloudové vrstvy v době, kdy se chystala spustit aktivní vrstva GC
• Předchozí změna systémového časového pásma mohla způsobit, že interní démon "cron", který má na starosti naplánované úlohy, stále běží ve starém časovém pásmu místo v novém, takže v závislosti na předchozím a aktuálním časovém pásmu může být DD GC spuštěn o několik hodin dříve nebo později, než se očekávalo, a proto vyvolá výstrahu pro přeskočený GC. Můžete zkontrolovat KB Data Domain: Jak změnit datum/čas anebo časové pásmo v systému Data Domain Restorer (DDR) kde naleznete další podrobnosti týkající se změn časových pásem v systému DD
• Interně se čištění systému DD spustí odesláním úlohy internímu daemonu "sms" pro příkaz "filesys clean start". Pokud "sms" nereaguje, nebo FS nereaguje na "sms" včas, GC se nespustí a bude přeskočen. Můžete zkontrolovat, zda protokol sms.info neobsahuje odpovídající položky, jako jsou tyto, které by signalizovaly, že došlo k pokusu o vyčištění, ale úlohu se nepodařilo spustit:

02/28 12:00:26.495 (TID 0xa79c040): Dokončená úloha: 3278752 provozu: sms_filesys_clean_start, doba trvání: 25 067 ms, stav: Systém souborů nereaguje.

• Stejné jako výše, ale kvůli "Time backward jump" není služba cronu synchronizována zpět s novou časovou sadou
  Něco podobného najdeme níže na ASUPu:

config.snmp.trapinfo.17 = Souborový systém je vypnut z důvodu kritického stavu. EVT-OBJ::Enclosure=1 EVT-INFO::Cause=Zpětný skok systémového času
config.snmp.trapinfo.19 = Nelze spustit plánované čištění souborového systému dne Út 15. listopadu 2022 06:00:00.

• Pokud je systém souborů mimo provoz, nereaguje nebo v té době došlo k převzetí služeb při selhání HA nebo se systém DD restartoval nebo byl mimo provoz, mohl být přeskočen i GC

Dalším důvodem, proč jsme v minulosti viděli, i když velmi zřídka, že GC byl přeskočen, je určitá nekonzistence čistého plánu v registru. Například registr i rozhraní příkazového řádku ukazují, že uvolňování paměti je naplánované na neděli v 6:00 místního času:

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

 

Jiný klíč registru (collection.1.crontab.expunge), který plánovač procesů "crontab" používá ke spouštění nakonfigurovaných úloh, je však nesprávný, například:

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

 

Výše uvedený klíč registru označuje, že plánované čištění má být spuštěno v úterý v 06:00 místního času (2 v páté specifikaci úlohy crontab) namísto neděle (0).

Výstrahu můžete kdykoli vymazat, ale tím se nevyřeší základní problém a nedojde k okamžitému spuštění čištění. V závislosti na příčině přeskočeného cyklu uvolňování paměti se přístup bude lišit a tento článek znalostní databáze o něm nebude zacházet do dalších podrobností. Vyhledejte pomoc v článcích DELL EMC DataDomain KB, nebo pokud ne, obraťte se na smluvního poskytovatele podpory.


V případě 'Time backward jump' můžeme jen dvakrát zkontrolovat, zda reg config odpovídá plánu 'filesys clean' a restartovat službu cron:
* Poznámka: Příkaz vyžaduje konzoli v režimu Bash, pro případ, že otevřete nový servisní požadavek a získejte pomoc od podpory 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

 

V případě problému pouze s nekonzistentními položkami registru spočívá oprava ve vynuceném nastavení správného plánu čištění z rozhraní příkazového řádku nebo rozhraní příkazového řádku. Pokračujeme-li tedy v příkladu, administrátor by musel nastavit čistý plán na neděli v 06:00 , i když "filesys clean show schedule" již hlásí, že tomu tak je:

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

 

Poté ověřte, zda byl aktualizován klíč registru, který označuje, že čištění bude naplánováno na nesprávný den:

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