Data Domain: A limpeza agendada falha ao iniciar, postando o AVISO "EVT-GC-00002: Não foi possível iniciar a limpeza agendada do file system"

A limpeza do Data Domain (coleta de lixo, GC) está agendada para ser executada em dias e horários específicos. No DDOS 6.0.x e versões posteriores, quando há algum agendamento e, por qualquer motivo, o processo de limpeza não pode ser iniciado, isso é notado pelo daemon de monitoramento do sistema e, eventualmente, gera um alerta como o abaixo:

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

 

Além disso, um alerta ASUP é enviado com detalhes como o seguinte:

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. 

 

O alerta informa apenas que há um processo de limpeza agendado que não pôde ser iniciado no momento em que deveria começar. Várias razões possíveis para isso, a maioria das quais não são uma indicação de qualquer problema. Os motivos pelos quais o alerta pode ser acionado incluem:

• O DD GC já estava em execução no momento em que o processo de limpeza agendado teve que iniciar. Como apenas um processo de GC pode ser executado a qualquer momento, e a tentativa de um não antecipará um GC em execução, o processo agendado foi ignorado e, portanto, o alerta
• Ações incompatíveis com o GC, como, por exemplo, executar a movimentação de dados (FMIG) do nível de armazenamento ativo para o de arquivamento ou executar a limpeza do Cloud Tier no momento em que o GC do nível ativo estava prestes a iniciar
• Uma alteração anterior no fuso horário do sistema poderia fazer com que o daemon "cron" interno responsável pelas tarefas agendadas ainda estivesse em execução no fuso horário antigo, em vez do novo, portanto, dependendo dos fusos horários anterior e atual, o DD GC pode ser executado várias horas antes ou depois do esperado, gerando o alerta para o GC ignorado. Você pode verificar KB Data Domain: Como modificar a data/hora e/ou o fuso horário em um Data Domain Restorer (DDR) para obter mais detalhes sobre alterações de fuso horário em um DD
• Internamente, a limpeza do DD é iniciada enviando um trabalho ao daemon interno "sms" para o comando "filesys clean start". Se "sms" não responder ou se o FS não responder a "sms" no prazo, a GC não será iniciada e será ignorada. Talvez você queira verificar o log "sms.info" em busca de entradas correspondentes, como estas, o que indicaria que houve uma tentativa de limpeza, mas que o trabalho não foi iniciado:

28/02 12:00:26.495 (TID 0xa79c040): Trabalho concluído: 3278752 para operação: sms_filesys_clean_start, duração: 25067 mseg, status: O file system não está respondendo.

• O mesmo que o acima, mas devido ao "Time backward jump" o serviço do cron não é sincronizado de volta com o novo conjunto
  de tempo Podemos encontrar algo como o abaixo no ASUP:

config.snmp.trapinfo.17 = o file system está desativado devido a uma condição crítica. EVT-OBJ::Enclosure=1 EVT-INFO::Cause=System Time backward jumped
config.snmp.trapinfo.19 = não foi possível iniciar a limpeza agendada do file system em Tue Nov 15, 06:00:00 2022.

• Se o FS estiver inativo, sem responder ou se houvesse um failover de HA ocorrendo naquele momento, ou se o DD estivesse reinicializando ou inativo, a GC também pode ter sido ignorada

Outra razão que vimos no passado, embora muito raramente, para GC ser ignorado, é alguma inconsistência para o cronograma limpo no registro. Por exemplo, o registro e a CLI mostram que a GC está agendada para ser executada aos domingos, às 6h no horário 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".

 

No entanto, uma chave de registro diferente (collection.1.crontab.expunge), que é usada pelo agendador de processos "crontab" para iniciar os trabalhos configurados, está incorreta, por exemplo:

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

 

A chave de registro acima indica que a limpeza agendada deve ser iniciada às 06h, horário local, às terças-feiras (2 na quinta especificação de trabalho "crontab") em vez de domingos (0).

Você pode limpar o alerta a qualquer momento, mas isso não resolverá o problema subjacente nem resultará na inicialização imediata da limpeza. Dependendo da causa do ciclo de GC ignorado, a abordagem será diferente e este artigo da KB não entrará em mais detalhes sobre ele. Verifique os artigos da base de conhecimento do Dell EMC DataDomain para obter assistência ou, se não estiver, entre em contato com o provedor de suporte contratado.


No caso de 'Time backward jump' , podemos apenas verificar novamente se a configuração reg corresponde ao agendamento 'filesys clean' e reiniciar o serviço cron:
* Nota: o comando precisa de um console no modo bash, caso abra um novo chamado para obter ajuda do suporte do 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 o problema apenas com as entradas de registro inconsistentes, a correção é forçar a definição do agendamento de limpeza correto a partir da CLI ou da CLI. Então, continuando com o exemplo, o administrador teria que definir a agenda limpa para domingos às 06:00 da manhã, mesmo que "filesys clean show schedule" já informe que seja o 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".

 

Depois de fazer isso, confirme se a chave do Registro indicando que a limpeza será agendada para o dia errado foi atualizada:

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