Data Domain: Geplande opschoning start niet, met WARNING "EVT-GC-00002: Kan geplande opschoning van bestandssysteem niet starten"

DataDomain clean (Garbage Collection, GC) is gepland om op bepaalde dagen en tijden te worden uitgevoerd. In DDOS 6.0.x en latere versies, wanneer er een dergelijk schema is en, om welke reden dan ook, het opschoonproces niet kan worden gestart, wordt dit opgemerkt door de systeembewakingsdaemon en wordt uiteindelijk een waarschuwing gegenereerd zoals hieronder:

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

 

Er wordt ook zo snel mogelijk een waarschuwing verzonden met details zoals de volgende:

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. 

 

De waarschuwing informeert alleen dat er een gepland opschoonproces is dat niet kon worden gestart op het moment dat het had moeten starten. Hiervoor zijn meerdere mogelijke redenen, waarvan de meeste geen indicatie zijn van een probleem. Redenen waarom de waarschuwing kan worden geactiveerd, zijn onder meer:

• DD GC werd al uitgevoerd op het moment dat het geplande opschoonproces moest beginnen. Aangezien er op een bepaald moment slechts één GC-proces kan worden uitgevoerd en een poging tot een GC een lopende GC niet kan voorkomen, is het geplande proces overgeslagen en vandaar de waarschuwing
• Acties die niet compatibel zijn met GC, zoals bijvoorbeeld het uitvoeren van dataverplaatsing (FMIG) van Active naar Archive-storagelaag, of het uitvoeren van Cloud Tier-opschoning op het moment dat Active Tier GC op het punt stond te starten
• Een eerdere wijziging in de tijdzone van het systeem kan ertoe hebben geleid dat de interne "cron"-daemon die verantwoordelijk is voor geplande taken nog steeds in de oude tijdzone wordt uitgevoerd in plaats van in de nieuwe, dus afhankelijk van de vorige en huidige tijdzones kan DD GC enkele uren eerder of later worden uitgevoerd dan verwacht, waardoor de waarschuwing voor de overgeslagen GC wordt geactiveerd. U kunt KB Data Domain controleren: De datum/tijd en/of tijdzone wijzigen in een Data Domain Restorer (DDR) voor meer informatie over tijdzonewijzigingen in een DD
• Intern wordt de DD clean gestart door een taak in te dienen bij de interne "sms"-daemon voor de opdracht "filesys clean start". Als "sms" niet reageert, of de FS niet op tijd reageert op "sms", zal GC niet starten en worden overgeslagen. Mogelijk wilt u het logboek "sms.info" controleren op overeenkomende vermeldingen zoals deze, wat aangeeft dat er is geprobeerd op te schonen, maar dat de taak niet kon worden gestart:

02/28 12:00:26.495 (TID 0xa79c040): Voltooide taak: 3278752 voor gebruik: sms_filesys_clean_start, duur: 25067 msec, status: Het bestandssysteem reageert niet.

• Hetzelfde als het bovenstaande, maar vanwege "Time backward jump" wordt de service van cron niet gesynchroniseerd met de nieuwe ingestelde tijd.
  We kunnen zoiets als het onderstaande vinden op ASUP:

config.snmp.trapinfo.17 = Bestandssysteem is uitgeschakeld vanwege een kritieke situatie. EVT-OBJ::Enclosure=1 EVT-INFO::Cause=System Time backward jumped
config.snmp.trapinfo.19 = Kan geplande opschoning van het bestandssysteem niet starten op Tue Nov 15 06:00:00 2022.

• Als de FS niet beschikbaar is, niet reageert, of als er op dat moment een HA-failover heeft plaatsgevonden, of als de DD opnieuw opstart of niet beschikbaar is, is GC mogelijk ook overgeslagen

Een andere reden die we in het verleden hebben gezien, zij het zeer zelden, waarom GC wordt overgeslagen, is enige inconsistentie voor het schone schema in het register. Het register en de CLI geven bijvoorbeeld beide aan dat GC is gepland om op zondag om 06.00 uur lokale tijd te worden uitgevoerd:

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

 

Een andere registersleutel (collection.1.crontab.expunge), die wordt gebruikt door de procesplanner "crontab" om de geconfigureerde taken te starten, is echter onjuist, bijvoorbeeld:

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

 

De bovenstaande registersleutel geeft aan dat de geplande opschoning moet worden gestart om 06.00 uur lokale tijd op dinsdag (2 in de vijfde "crontab"-taakspecificatie) in plaats van op zondag (0).

U kunt de melding op elk gewenst moment wissen, maar als u dit doet, wordt het onderliggende probleem niet opgelost en wordt de batterij niet onmiddellijk opnieuw gestart. Afhankelijk van de oorzaak van de overgeslagen GC-cyclus zal de aanpak anders zijn, en deze KB zal er niet verder op ingaan. Raadpleeg de KB-artikelen van DELL EMC DataDomain voor hulp of, als dat niet het geval is, neem dan contact op met uw gecontracteerde supportprovider.


In het geval van 'Time backward jump' kunnen we gewoon dubbelchecken of de reg config overeenkomt met het 'filesys clean' schema en de cron service opnieuw opstarten:
* Opmerking: de opdracht heeft een bash-modusconsole nodig, voor het geval u een nieuwe SR opent om hulp te krijgen van Data Domain Support.

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

 

Alleen voor het probleem met de inconsistente registervermeldingen is de oplossing om het juiste opschoonschema geforceerd in te stellen vanuit de CLI of de CLI. Dus voortbordurend op het voorbeeld, zou de beheerder het schone schema moeten instellen op zondag om 06.00 uur, zelfs als "filesys clean show schedule" al meldt dat dit het geval is:

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

 

Controleer hierna of de registersleutel die aangeeft dat schoon op de verkeerde dag moet worden gepland, is bijgewerkt:

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