Data Domain: Zaplanowane czyszczenie nie rozpoczyna się, wyświetlając komunikat "OSTRZEŻENIE "EVT-GC-00002: Nie można rozpocząć zaplanowanego czyszczenia systemu plików"

Czyszczenie domeny danych (odśmiecanie pamięci, GC) jest zaplanowane do uruchomienia w określone dni i o określonych godzinach. W DDOS 6.0.x i nowszych wersjach, jeśli istnieje taki harmonogram i z jakiegokolwiek powodu nie można uruchomić procesu czyszczenia, jest to zauważane przez demona monitorowania systemu i ostatecznie zgłasza alert, taki jak ten poniżej:

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

 

Wysyłany jest również ASUP alertu ze szczegółami podobnymi do poniższych:

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. 

 

Alert informuje tylko o zaplanowanym procesie czyszczenia, którego nie można było rozpocząć w czasie, gdy miał się rozpocząć. Istnieje wiele możliwych przyczyn takiego stanu rzeczy, z których większość nie wskazuje na żaden problem. Przyczyny wyzwolenia alertu są następujące:

• DD GC był już uruchomiony w momencie rozpoczęcia zaplanowanego procesu czyszczenia. Ponieważ w danym momencie można uruchomić tylko jeden proces GC, a próba jego uruchomienia nie spowoduje wywłaszczenia uruchomionego GC, zaplanowany proces został pominięty, w związku z czym alert
• Akcje niezgodne z GC, takie jak na przykład uruchamianie przenoszenia danych (FMIG) z warstwy pamięci masowej Active do Archive lub uruchamianie czyszczenia warstwy chmury w momencie rozpoczęcia GC warstwy aktywnej
• Poprzednia zmiana systemowej strefy czasowej mogła spowodować, że wewnętrzny demon "cron" odpowiedzialny za zaplanowane zadania nadal działał w starej strefie czasowej, a nie w nowej, więc w zależności od poprzedniej i bieżącej strefy czasowej DD GC mógł zostać uruchomiony kilka godzin wcześniej lub później niż oczekiwano, a tym samym zgłaszając alert dla pominiętego GC. Możesz sprawdzić KB Data Domain: Jak zmodyfikować datę/godzinę i/lub strefę czasową w Data Domain Restorer (DDR), aby uzyskać więcej informacji na temat zmian strefy czasowej w DD
• Wewnętrznie czyszczenie DD jest uruchamiane przez przesłanie zadania do wewnętrznego demona "sms" dla polecenia "filesys clean start". Jeśli "sms" nie odpowiada lub FS nie odpowie na "sms" na czas, GC nie uruchomi się i zostanie pominięty. Warto sprawdzić, czy w dzienniku "sms.info" znajdują się pasujące wpisy, takie jak te, które wskazują, że podjęto próbę czyszczenia, ale nie udało się uruchomić zadania:

02/28 12:00:26.495 (tid 0xa79c040): Ukończone zadanie: 3278752 eksploatacji: sms_filesys_clean_start, czas trwania: 25067 ms, stan: System plików nie odpowiada.

• Tak samo jak powyżej, ale z powodu "Time backward leap" usługa crona nie jest zsynchronizowana z nowym ustawieniem
  czasu Na ASUP możemy znaleźć coś takiego jak poniżej:

config.snmp.trapinfo.17 = System plików jest wyłączony z powodu stanu krytycznego. EVT-OBJ::Enclosure=1 EVT-INFO::Cause=Przeskok czasu systemowego do tyłu
config.snmp.trapinfo.19 = Nie można rozpocząć zaplanowanego czyszczenia systemu plików we wtorek 15 listopada 2022 r. o godz. 06:00:00.

• Jeśli FS nie działa, nie odpowiada lub w tym czasie miało miejsce przełączenie awaryjne HA, lub DD był ponownie uruchamiany lub wyłączony, GC również mógł zostać pominięty

Innym powodem, dla którego w przeszłości zaobserwowaliśmy pominięcie GC, choć bardzo rzadko, jest pewna niespójność harmonogramu czyszczenia w rejestrze. Na przykład rejestr i interfejs wiersza polecenia pokazują, że GC jest zaplanowane do uruchomienia w niedziele o godzinie 06:00 czasu lokalnego:

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

 

Jednak inny klucz rejestru (collection.1.crontab.expunge), który jest używany przez harmonogram procesów "crontab" do uruchamiania skonfigurowanych zadań, jest niepoprawny, na przykład:

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

 

Powyższy klucz rejestru wskazuje, że zaplanowane czyszczenie ma się rozpocząć o godzinie 06:00 czasu lokalnego we wtorki (2 w piątej specyfikacji zadania "crontab") zamiast w niedziele (0).

Alert można wyczyścić w dowolnym momencie, ale nie rozwiąże to podstawowego problemu ani nie spowoduje natychmiastowego rozpoczęcia czyszczenia. W zależności od przyczyny pominięcia cyklu GC podejście będzie inne i ten artykuł bazy wiedzy nie będzie zawierał dalszych szczegółów na ten temat. Zapoznaj się z artykułami bazy wiedzy DELL EMC DataDomain, aby uzyskać pomoc, a jeśli nie, skontaktuj się z dostawcą usług pomocy technicznej, z którym zawarto umowę.


W przypadku 'Time backward leap' możemy po prostu dwukrotnie sprawdzić, czy konfiguracja reg pasuje do harmonogramu 'filesys clean' i zrestartować usługę cron:
* Uwaga: polecenie wymaga konsoli trybu bash na wypadek, gdyby otworzyć nowe zgłoszenie SR w celu uzyskania pomocy technicznej 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

 

Tylko w przypadku problemu z niespójnymi wpisami rejestru poprawka polega na wymuszeniu prawidłowego harmonogramu czyszczenia z poziomu interfejsu wiersza poleceń lub interfejsu wiersza poleceń. Kontynuując przykład, administrator musiałby ustawić harmonogram czyszczenia na niedziele o 06:00 , nawet jeśli "filesys clean show schedule" już to zgłasza:

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

 

Po wykonaniu tej czynności sprawdź, czy klucz rejestru wskazujący czyszczenie, które ma zostać zaplanowane na niewłaściwy dzień, został zaktualizowany:

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