Data Domain: Planlagt rengjøring starter ikke, og legger ut ADVARSEL "EVT-GC-00002: Kan ikke starte planlagt opprydding av filsystemet"

DataDomain-rengjøring (Garbage Collection, GC) er planlagt å kjøre på bestemte dager og tidspunkter. I DDOS 6.0.x og nyere versjoner, når det er en slik tidsplan og av en eller annen grunn ikke kan startes den rene prosessen, blir dette lagt merke til av systemovervåkingsdemonen og til slutt hever et varsel som det nedenfor:

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

 

Det sendes også et varsel med detaljer som følgende:

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. 

 

Varselet informerer bare om at det er en planlagt ren prosess som ikke kunne startes på det tidspunktet den skulle starte. Flere mulige årsaker til dette, hvorav de fleste ikke er en indikasjon på noe problem. Årsaker til at varselet kan utløses inkluderer:

• DD GC var allerede i gang da den planlagte ryddeprosessen måtte starte. Siden bare én GC-prosess kan kjøres til enhver tid, og forsøk på en ikke vil forhindre en kjørende GC, ble den planlagte hoppet over, og dermed varselet
• Handlinger som ikke er kompatible med GC, for eksempel å kjøre dataflytting (FMIG) fra aktivt til arkivlagringsnivå eller kjøre opprydding av skynivå på det tidspunktet Active tier GC var i ferd med å starte
• En tidligere endring i systemets tidssone kunne ha forårsaket at den interne "cron"-bakgrunnsprosessen med ansvar for planlagte oppgaver fortsatt kjører på den gamle tidssonen, i stedet for den nye, så avhengig av tidligere og nåværende tidssoner, kan DD GC kjøres flere timer tidligere eller senere enn forventet, og dermed øke varselet for den hoppet over GC. Du kan sjekke KB Data Domain: Slik endrer du dato/klokkeslett og/eller tidssone på en Data Domain Restorer (DDR) for mer informasjon om tidssoneendringer i en DD
• Internt startes DD-rensingen ved å sende en jobb til den interne "sms"-bakgrunnsprosessen for "filesys clean start"-kommandoen. Hvis "sms" ikke svarer, eller FS ikke svarer på "sms" i tide, vil GC ikke starte, og vil bli hoppet over. Det kan være lurt å sjekke "sms.info"-loggen for samsvarende oppføringer som disse, noe som indikerer at ren ble forsøkt, men jobben kunne ikke startes:

02/28 12:00:26.495 (tid 0xa79c040): Avsluttet jobb: 3278752 for drift: sms_filesys_clean_start, varighet: 25067 msek, status: Filsystemet svarer ikke.

• Samme som ovenfor, men på grunn av "Time backward jump" cron tjeneste er ikke synkronisert tilbake med den nye tiden satt
  Vi kan finne noe sånt nedenfor på ASUP:

config.snmp.trapinfo.17 = Filsystemet er deaktivert på grunn av en kritisk tilstand. EVT-OBJ::Kabinett = 1 EVT-INFO:: Årsak = System Tid bakover hoppet
config.snmp.trapinfo.19 = Kan ikke starte planlagt opprydding av filsystemet tirs Nov 15 06:00:00 2022.

• Hvis FS er nede, ikke reagerer, eller det oppstod en HA-failover på det tidspunktet, eller DD-en startet på nytt eller var nede, kan GC også ha blitt hoppet over

En annen grunn vi har sett tidligere, om enn svært sjelden, for GC å bli hoppet over, er noen inkonsekvens for den rene tidsplanen i registeret. For eksempel viser både registeret og CLI at GC er planlagt å kjøre på søndager klokken 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 annen registernøkkel (collection.1.crontab.expunge), som brukes av "crontab"-prosessplanleggeren til å starte de konfigurerte jobbene, er imidlertid feil, for eksempel:

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

 

Registernøkkelen ovenfor indikerer at planlagt opprydding skal startes kl. 06.00 lokal tid på tirsdager (2 i den femte "crontab"-jobbspesifikasjonen) i stedet for søndager (0).

Du kan slette varselet når som helst, men dette løser ikke det underliggende problemet og fører heller ikke til at det begynner å rengjøre umiddelbart. Avhengig av årsaken til den hoppet over GC-syklusen, vil tilnærmingen være annerledes, og denne KB vil ikke gå inn i ytterligere detaljer om den. Se KB-artiklene for DELL EMC DataDomain for hjelp, eller hvis ikke, ta kontakt med støtteleverandøren du har kontrakten på.


Når det gjelder 'Time backward jump' kan vi bare dobbeltsjekke om reg-konfigurasjonen samsvarer med 'filesys clean' tidsplanen og starte cron-tjenesten på nytt:
* Merk: kommandoen trenger en bash-moduskonsoll, i tilfelle åpne en ny SR for å få hjelp fra 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

 

Løsningen gjelder bare for problemet med inkonsekvente registeroppføringer ved å tvangsinnsette riktig oppryddingsplan fra CLI-lisensen eller CLI-en. Så fortsetter med eksemplet, administrator måtte sette den rene tidsplanen til søndager kl 06:00, selv om "filesys clean show schedule" allerede rapporterer at å være tilfelle:

# 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 dette, bekrefter du at registernøkkelen som angir at den er planlagt for feil dag, er oppdatert:

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