Data Domain: Schemalagd rensning startar inte, postar VARNING "EVT-GC-00002: Det går inte att starta schemalagd rensning av filsystemet"

DataDomain clean (skräpsamling, GC) är schemalagd att köras på vissa dagar och tider. I DDOS 6.0.x och senare versioner, när det finns ett sådant schema och rensningsprocessen av någon anledning inte kan startas, uppmärksammas detta av systemövervakningsdemonen och så småningom utlöser en varning som den nedan:

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

 

Dessutom skickas en ASUP-varning med information som följande:

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. 

 

Aviseringen informerar bara om att det finns en schemalagd rensningsprocess som inte kunde startas när den skulle starta. Det finns flera möjliga orsaker till detta, varav de flesta inte är en indikation på något problem. Orsaker till att aviseringen kan utlösas är:

• DD GC kördes redan när den schemalagda rensningsprocessen skulle starta. Eftersom endast en GC-process kan köras vid en given tidpunkt, och försök till en inte föregriper en GC som körs, hoppades den schemalagda processen över och därför aviserades
• Åtgärder som är inkompatibla med GC, till exempel att köra dataflytt (FMIG) från Active till Archive Storage Level eller köra rensning av molnnivå vid den tidpunkt då Active Tier GC skulle starta
• En tidigare ändring i systemets tidszon kan ha orsakat att den interna "cron"-daemonen som ansvarar för schemalagda aktiviteter fortfarande körs i den gamla tidszonen i stället för den nya, så beroende på tidigare och aktuella tidszoner kan DD GC köras flera timmar tidigare eller senare än förväntat, vilket ökar varningen för den överhoppade GC. Du kan kontrollera KB Data Domain: Så här ändrar du datum/tid och/eller tidszon på en Data Domain Restorer (DDR) för mer information om tidszonsändringar i en DD
• Internt startas DD-rensningen genom att skicka ett jobb till den interna "sms"-daemonen för kommandot "filesys clean start". Om "sms" inte svarar, eller om FS inte svarar på "sms" i tid, startar inte GC och hoppas över. Du kanske vill kontrollera "sms.info"-loggen för matchande poster som dessa, vilket skulle indikera att rensning gjordes men att jobbet inte kunde startas:

02/28 12:00:26.495 (tid 0xa79c040): slutfört jobb: 3278752 för drift: sms_filesys_clean_start, varaktighet: 25067 ms, status: Filsystemet svarar inte.

• Samma som ovanstående, men på grund av "Tidshopp bakåt" synkroniseras inte crons tjänst tillbaka med den nya tidsinställningen
  Vi kan hitta något liknande nedan på ASUP:

config.snmp.trapinfo.17 = Filsystemet är inaktiverat på grund av ett kritiskt tillstånd. EVT-OBJ::Enclosure=1 EVT-INFO::Cause=Systemtid bakåt hoppade
config.snmp.trapinfo.19 = Kunde inte starta schemalagd filsystemrensning tis nov 15 06:00:00 2022.

• Om FS är nere, inte svarar eller om det pågick en HA-redundans vid den tidpunkten, eller om DD startades om eller var nere, kan GC också ha hoppats över

En annan anledning som vi har sett tidigare, om än mycket sällan, för att GC ska hoppas över, är viss inkonsekvens för det rena schemat i registret. Både registret och CLI visar till exempel att GC är schemalagt att köras på söndagar kl. 06.00 lokal tid:

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

 

En annan registernyckel (collection.1.crontab.expunge), som används av processschemaläggaren "crontab" för att starta de konfigurerade jobben, är dock felaktig, till exempel:

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

 

Registernyckeln ovan anger att schemalagd rensning ska startas kl. 06.00 lokal tid på tisdagar (2 i den femte "crontab"-jobbspecifikationen) istället för söndagar (0).

Du kan ta bort varningen när som helst, men om du gör det löses inte det underliggande problemet eller så startar rensningen omedelbart. Beroende på orsaken till den överhoppade GC-cykeln kommer metoden att vara annorlunda, och denna KB kommer inte att gå in på ytterligare detaljer om den. Läs artiklarna om DELL EMC DataDomain KB för hjälp eller, om inte, kontakta din kontrakterade supportleverantör.


När det gäller "Tidshopp bakåt" kan vi bara dubbelkolla om reg-konfigurationen matchar schemat för "filesys clean" och starta om cron-tjänsten:
* Obs! Kommandot behöver en bash-lägeskonsol om du öppnar en ny SR för att få hjälp från Data Domain-supporten.

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

 

Endast för problemet med de inkonsekventa registerposterna är korrigeringen att tvinga fram rätt rensningsschema från antingen CLI eller CLI. Så om vi fortsätter med exemplet måste administratören ställa in det rena schemat till söndagar klockan 06.00, även om "filesys clean show schedule" redan rapporterar att så är fallet:

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

 

När du har gjort det kontrollerar du att registernyckeln som anger att rensning ska schemaläggas för fel dag har uppdaterats:

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