Data Domain: Planlagt rensning starter ikke og sender ADVARSEL "EVT-GC-00002: Kunne ikke starte planlagt rensning af filsystemet"

DataDomain clean (Garbage Collection, GC) er planlagt til at køre på bestemte dage og tidspunkter. I DDOS 6.0.x og nyere versioner, når der er en sådan tidsplan, og af en eller anden grund kan den rene proces ikke startes, bemærkes dette af systemovervågningsdæmonen og rejser til sidst en advarsel som den 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.
-----   ------------------------   --------   -----------   ---------    -----------------------------------------------------------------------------------------

 

Der sendes også en advarsel ASUP 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. 

 

Advarslen informerer kun om, at der er en planlagt ren proces, som ikke kunne startes på det tidspunkt, den skulle starte. Flere mulige årsager til dette, hvoraf de fleste ikke er en indikation af noget problem. Årsager til, at advarslen kan blive udløst, omfatter:

• DD GC kørte allerede på det tidspunkt, hvor den planlagte rensningsproces skulle starte. Da kun én GC-proces kan køres ad gangen, og forsøg på en ikke vil tilsidesætte en kørende GC, blev den planlagte sprunget over, og dermed advarslen
• Handlinger, der er inkompatible med GC, som f.eks. kørsel af dataflytning (FMIG) fra lagerniveauet Active til Archive eller kørsel af Cloud Tier-rensning på det tidspunkt, hvor GC på aktivt niveau skulle starte
• En tidligere ændring i systemets tidszone kunne have forårsaget, at den interne "cron"-dæmon, der har ansvaret for planlagte opgaver, stadig kører i den gamle tidszone i stedet for den nye, så afhængigt af de tidligere og aktuelle tidszoner kan DD GC køres flere timer tidligere eller senere end forventet, hvilket øger alarmen for den sprunget GC op. Du kan kontrollere KB Data Domain: Sådan ændres dato/klokkeslæt og/eller tidszone på en Data Domain Restorer (DDR) for at få flere oplysninger om tidszoneændringer i en DD
• Internt startes DD-oprydningen ved at indsende et job til den interne "sms"-dæmon for kommandoen "filesys clean start". Hvis "sms" ikke reagerer, eller FS ikke reagerer på "sms" til tiden, starter GC ikke og springes over. Det kan være en god idé at kontrollere loggen "sms.info" for matchende poster som disse, hvilket ville indikere, at rensning blev forsøgt, men jobbet ikke kunne startes:

02/28 12:00:26.495 (TID 0xa79c040): afsluttet job: 3278752 til drift: sms_filesys_clean_start, varighed: 25067 MSEC, status: Filsystemet svarer ikke.

• Samme som ovenstående, men på grund af "Time backward jump" er cron's service ikke synkroniseret tilbage med det nye tidssæt
  Vi kan finde noget som nedenstående på ASUP:

config.snmp.trapinfo.17 = Filsystemet er deaktiveret på grund af en kritisk tilstand. EVT-OBJ::Kabinet=1 EVT-INFO::Årsag=System Tid baglæns sprunget
config.snmp.trapinfo.19 = Kan ikke starte planlagt oprydning af filsystemet den Tue Nov 15 06:00:00 2022.

• Hvis FS er nede, ikke reagerer, eller der fandt en HA-failover sted på det tidspunkt, eller DD genstartede eller nede, kan GC også være blevet sprunget over

En anden grund til, at vi tidligere har set, omend meget sjældent, at GC springes over, er en vis inkonsekvens for den rene tidsplan i registreringsdatabasen. For eksempel viser registreringsdatabasen og CLI begge, at GC er planlagt til at køre om søndagen 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 anden registreringsdatabasenøgle (collection.1.crontab.expunge), som bruges af procesplanlægningsprogrammet "crontab" til at starte de konfigurerede job, er imidlertid forkert, f.eks.:

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

 

Ovenstående registreringsdatabasenøgle angiver, at planlagt oprydning skal startes kl. 06.00 lokal tid om tirsdagen (2 i den femte "crontab"-jobspecifikation) i stedet for søndage (0).

Du kan når som helst rydde advarslen, men det vil ikke løse det underliggende problem eller resultere i, at rensningen påbegyndes med det samme. Afhængigt af årsagen til den sprunget GC-cyklus vil tilgangen være anderledes, og denne KB vil ikke gå ind i yderligere detaljer om den. Se artiklerne i DELL EMC DataDomain KB for at få hjælp, eller hvis ikke, skal du kontakte din supportudbyder,


der har indgået kontrakt med support.I tilfælde af 'Time backward jump' kan vi bare dobbelttjekke, om reg-konfigurationen matcher tidsplanen 'filesys clean' og genstarte cron-tjenesten:
* Bemærk: Kommandoen skal bruge en konsol med bash-tilstand, hvis du åbner en ny SR for at få hjælp 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

 

For problemet med kun de inkonsekvente poster i registreringsdatabasen er rettelsen at tvinge den korrekte oprydningsplan fra enten CLI eller CLI. Så fortsætter med eksemplet, skal administratoren indstille den rene tidsplan til søndage kl. 06.00 , selvom "filesys clean show schedule" allerede rapporterer, at det er tilfældet:

# 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, skal du kontrollere, at registreringsdatabasenøglen, der angiver, at ren skal planlægges for den forkerte dag, er blevet opdateret:

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