Домен даних: Заплановане очищення не запускається, публікується ПОПЕРЕДЖЕННЯ "EVT-GC-00002: Не вдається запустити заплановане очищення файлової системи"

Прибирання домену даних (Garbage Collection, GC) заплановано на певні дні та години. У DDOS 6.0.x і пізніших версіях, коли є будь-який такий розклад і з будь-якої причини процес очищення не може бути запущений, це помічається фоновою службою моніторингу системи і в кінцевому підсумку викликає попередження, подібне до наведеного нижче:

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

 

Крім того, надсилається оповіщення ASUP з такими деталями:

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. 

 

Сповіщення лише інформує про запланований процес очищення, який не вдалося розпочати в той час, коли він мав розпочатися. Для цього є кілька можливих причин, більшість з яких не є ознакою будь-якої проблеми. Причини, через які може спрацьовувати оповіщення, включають:

• DD GC вже працював, коли мав розпочатися запланований процес очищення. Оскільки в будь-який момент часу може бути запущений лише один процес GC, і спроба його не випередить запущений GC, запланований процес було пропущено, а отже, і попередження
• Дії, несумісні з GC, такі як, наприклад, запуск переміщення даних (FMIG) з активного рівня сховища на рівень архіву або запуск очищення хмарного рівня в той час, коли GC активного рівня ось-ось мав розпочатися
• Попередня зміна системного часового поясу могла призвести до того, що внутрішній фон "cron", який відповідає за заплановані завдання, все ще виконувався у старому часовому поясі, а не в новому, тому, залежно від попереднього та поточного часових поясів, DD GC може бути запущено на кілька годин раніше або пізніше, ніж очікувалося, таким чином підвищуючи попередження для пропущеного GC. Ви можете перевірити домен даних KB: Як змінити дату/час та/або часовий пояс на Data Domain Restorer (DDR) для отримання більш детальної інформації про зміну часового поясу в DD
• Внутрішнє очищення DD запускається надсиланням завдання у внутрішній фоновій службі "sms" для команди "fileys clean start". Якщо "sms" не відповідає, або FS не відповідає на "sms" вчасно, GC не запуститься, і буде пропущено. Ви можете перевірити журнал "sms.info" на наявність відповідних записів, подібних до цих, які вказуватимуть на те, що була зроблена спроба очищення, але завдання не вдалося розпочати:

28.02 12:00:26.495 (TID 0xa79c040): Виконана робота: 3278752 для роботи: sms_filesys_clean_start, тривалість: 25067 мсек, стан: Файлова система не відповідає.

• Те ж саме, що і вище, але через "Стрибок назад у часі" сервіс cron не синхронізується з новим набором
  часу Ми можемо знайти щось подібне до наведеного нижче на ASUP:

config.snmp.trapinfo.17 = Файлову систему вимкнено через критичну умову. EVT-OBJ::Enclosure=1 EVT-INFO::Cause=Системний час у зворотному напрямку
config.snmp.trapinfo.19 = Неможливо розпочати заплановане очищення файлової системи Вт листопада 15 06:00:00 2022 р.

• Якщо ФС не працює, не відповідає, або в той час відбувався збій HA, або DD перезавантажувався або не працював, GC також міг бути пропущений

Ще одна причина, через яку ми бачили в минулому, хоч і дуже рідко, пропускати ГК, – це деяка невідповідність чистому графіку в реєстрі. Наприклад, реєстр і CLI показують, що запуск GC заплановано на неділю о 06:00 ранку за місцевим часом:

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

 

Однак, інший розділ реєстру (collection.1.crontab.expunge), який використовується планувальником процесів "crontab" для запуску налаштованих завдань, є неправильним, наприклад:

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

 

Наведений вище ключ реєстру вказує на те, що заплановане очищення має розпочатися о 06:00 ранку за місцевим часом по вівторках (2 у п'ятій специфікації завдань «crontab»), а не в неділю (0).

Ви можете зняти попередження в будь-який час, але це не вирішить основну проблему та не призведе до негайного запуску очищення. Залежно від причини пропущеного циклу ГК підхід буде різним, і в цьому КБ не будемо вдаватися в подробиці про нього. Будь ласка, перегляньте статті бази даних DELL EMC DataDomain для отримання допомоги або, якщо ні, зверніться до постачальника послуг підтримки, з яким укладено контракт.


У випадку 'Time backward jump' ми можемо просто ще раз перевірити, чи конфігурація reg відповідає розкладу 'fileys clean' і перезапустити службу cron:
* Примітка: команді потрібна консоль режиму bash, на випадок, якщо ви відкриєте новий SR, щоб отримати допомогу від 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

 

Для проблеми лише з неузгодженими записами реєстру виправлення полягає в примусовому встановленні правильного розкладу очищення від CLI або CLI. Отже, продовжуючи приклад, адміністратор повинен буде встановити чистий розклад на неділю о 06.00 ранку, навіть якщо "fileys clean show schedule" вже повідомляє про це:

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

 

Зробивши це, переконайтеся, що ключ реєстру, який вказує на те, що очищення має бути заплановане на невідповідний день, було оновлено:

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