Data Domain: La limpieza programada no se inicia, y se muestra la ADVERTENCIA "EVT-GC-00002: No se puede iniciar la limpieza programada del sistema de archivos"

La limpieza de Data Domain (recolección de elementos no utilizados, GC) está programada para ejecutarse en días y horas determinados. En DDOS 6.0.x y versiones posteriores, cuando existe una programación de este tipo y, por algún motivo, no se puede iniciar el proceso de limpieza, el demonio de monitoreo del sistema detecta esto y, finalmente, genera una alerta como la que se muestra a continuación:

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

 

Además, se envía una alerta ASUP con detalles como el siguiente:

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. 

 

La alerta solo informa que hay un proceso de limpieza programado que no se pudo iniciar en el momento en que se suponía que debía comenzar. Múltiples razones posibles para esto, la mayoría de las cuales no son una indicación de ningún problema. Entre las razones por las que se puede activar la alerta, se incluyen las siguientes:

• DD GC ya estaba en ejecución en el momento en que se debía iniciar el proceso de limpieza programado. Dado que solo se puede ejecutar un proceso de GC en un momento dado y que intentar uno no se adelantará a un GC en ejecución, el programado se omitió y, por lo tanto, la alerta
• Acciones incompatibles con GC, como, por ejemplo, la ejecución de la transferencia de datos (FMIG) desde el nivel de almacenamiento activo al nivel de archivo o la ejecución de la limpieza del nivel de nube en el momento en que GC del nivel activo estaba a punto de iniciarse
• Un cambio anterior en la zona horaria del sistema podría haber causado que el demonio interno "cron" a cargo de las tareas programadas aún se ejecute en la zona horaria anterior, en lugar de en la nueva, por lo que, según las zonas horarias anterior y actual, DD GC se puede ejecutar varias horas antes o después de lo esperado, por lo tanto, se genera la alerta para el GC omitido. Puede comprobar KB Data Domain: Cómo modificar la fecha/hora y/o la zona horaria en un restaurador de Data Domain (DDR) para obtener más detalles sobre los cambios de zona horaria en un DD
• Internamente, la limpieza de DD se inicia mediante el envío de un trabajo al demonio "sms" interno para el comando "filesys clean start". Si los "sms" no responden o el FS no responde a los "sms" a tiempo, la GC no se iniciará y se omitirá. Es posible que desee comprobar el registro de "sms.info" para ver si hay entradas coincidentes como estas, lo que indicaría que se intentó la limpieza, pero el trabajo no se pudo iniciar:

28/02 12:00:26.495 (TID 0xa79c040): trabajo completado: 3278752 para la operación: sms_filesys_clean_start, duración: 25 067 ms, estado: El sistema de archivos no responde.

• Igual que el anterior, pero debido al "salto de tiempo hacia atrás", el servicio de cron no se sincroniza con el nuevo conjunto
  de tiempo, podemos encontrar algo como lo siguiente en ASUP:

config.snmp.trapinfo.17 = El sistema de archivos está deshabilitado debido a una condición crítica. EVT-OBJ::Enclosure=1 EVT-INFO::Cause=Salto de tiempo hacia atrás del sistema
config.snmp.trapinfo.19 = No se puede iniciar la limpieza programada del sistema de archivos el Tue Nov 15 06:00:00 2022.

• Si el FS está inactivo, no responde, se produjo una conmutación por error de HA en ese momento o DD se estaba reiniciando o inactivo, es posible que también se haya omitido la GC

Otra razón que hemos visto en el pasado, aunque con muy poca frecuencia, para que se omita GC, es cierta inconsistencia para el programa de limpieza en el registro. Por ejemplo, tanto el registro como la CLI muestran que GC está programado para ejecutarse los domingos a las 06:00 a. m., hora local:

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

 

Sin embargo, una clave de registro diferente (collection.1.crontab.expunge), que utiliza el programador de procesos "crontab" para iniciar los trabajos configurados, es incorrecta, por ejemplo:

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

 

La clave de registro anterior indica que la limpieza programada se iniciará a las 06:00 a. m., hora local, los martes (2 en la quinta especificación de trabajo "crontab") en lugar de los domingos (0).

Puede borrar la alerta en cualquier momento, pero hacerlo no resolverá el problema subyacente ni dará lugar a un inicio limpio de inmediato. Según la causa del ciclo de GC omitido, el enfoque será diferente y en esta base de conocimientos no se brindarán más detalles al respecto. Consulte los artículos de la base de conocimientos de DELL EMC DataDomain para obtener ayuda o, si no, comuníquese con el proveedor de soporte contratado.


En el caso del 'salto de tiempo hacia atrás', podemos volver a verificar si la configuración del registro coincide con el programa 'filesys clean' y reiniciar el servicio cron:
* Nota: El comando necesita una consola en modo bash, en caso de que abra una nueva SR para obtener ayuda del soporte de 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

 

Para el problema con las entradas de registro incoherentes solamente, la solución es establecer forzosamente el programa de limpieza correcto desde la CLI o la CLI. Entonces, continuando con el ejemplo, el administrador tendría que establecer el horario de limpieza en los domingos a las 06.00 a.m., incluso si "filesys clean show schedule" ya informa que ese es el caso:

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

 

Después de hacer esto, confirme que se haya actualizado la clave de registro que indica que la limpieza se programará para el día incorrecto:

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