NetWorker: A clonagem habilitada para RPS falhará após o upgrade para a versão 19.11 se o servidor tiver estado DNS inverso definido como banido

Após o upgrade para o NetWorker 19.11, os trabalhos de clonagem parecem parar de responder, registrando o seguinte loop de mensagens:

01/13/25 16:51:19.000291 nsrclone-D5 find_clone_backend_job(): ENTER
01/13/25 16:51:19.000323 nsrclone-D5 extend_mmd_reservation_all_clone_backend_jobs: ENTER
01/13/25 16:51:19.000335 nsrclone-D5 extend_mmd_reservation_all_clone_backend_jobs: EXIT
01/13/25 16:51:20.001007 nsrclone-D5 extend_mmd_reservation_all_clone_backend_jobs: ENTER
01/13/25 16:51:20.001070 nsrclone-D5 extend_mmd_reservation_all_clone_backend_jobs: EXIT
01/13/25 16:51:21.000097 nsrrecopy-D3 main 0x342e850 wait timed out (locked)

O problema aparece quando:

• O servidor tem estado DNS inverso: conjunto banido no banco de dados do agente local (nsrladb)
• O trabalho de clone é configurado para usar um nó de armazenamento remoto em vez do servidor como o nó de origem (leitura)
• O trabalho de clone requer RPS, definido globalmente no recurso NSR (servidor) (desabilitar o clone do RPS: Não) ou invocado automaticamente devido ao tipo de saveset (vProxy/OAPP)

O trabalho não é concluído, apresenta falha ou deve ser abortado.

A causa parece estar relacionada a alterações de comunicação no NetWorker 19.11. O novo valor de estado inverso do DNS permite que os administradores removam os requisitos de correspondência de pesquisa inversa, que fazem parte do NetWorker desde suas versões iniciais.

No entanto, esta importante alteração parece ter introduzido questões que estão a ser investigadas. Embora o estado DNS inverso não seja "proibido" por padrão, os administradores que o usam no servidor enfrentam problemas com a clonagem do RPS quando um nó de armazenamento separado é usado.

A correção está sendo investigada no bug NETWORKER-111382. No momento em que este artigo foi escrito, essa correção não será exibida até, pelo menos, o NetWorker 19.11.0.5 ou o NetWorker 19.12.0.1. 

Em curto prazo, há três possíveis soluções temporárias para o problema:

• Use o estado inverso do DNS: armazenado em cache ou não armazenado em cache em vez de banido no servidor. Se, no momento, você depende da configuração proibida para backups de client sem resolução reversa para ter sucesso, será necessário garantir que as entradas da zona de pesquisa inversa de DNS sejam criadas para os endereços IP desses clients, podendo ser consultadas pelo servidor e pelos nós do NetWorker, para que eles continuem funcionando. Para alterar essa configuração no servidor, em um prompt de comando elevado, execute: 

(echo . type: nsrla & echo upd reverse DNS state: cached) | nsradmin -p nsrexec -i -

printf ". type: nsrla\nupd reverse DNS state: cached\n" | nsradmin -p nsrexec -i -

Em seguida, reinicie os serviços após a alteração:

nsr_shutdown
systemctl start networker

net stop nsrexecd /y
net start nsrd
net start gstd
*Starting gstd is only required if NMC server is installed on the same host as the NetWorker server.

• Altere os nós de origem e destino na ação de clone para usar o servidor (nsrserverhost) em vez de um nó de armazenamento, se possível. Para trabalhos de clonagem do Data Domain, o nó de armazenamento é em grande parte irrelevante, pois os próprios Data Domains lidam com o tráfego de dados e dependem apenas do acesso do servidor a cada Data Domain.
• Desative o RPS globalmente. Advertência: Isso não ajudará com tipos de saveset que exigem RPS e o invocam automaticamente como parte da operação de clonagem, como savesets vProxy e OAPP. Se você não estiver clonando esses tipos de saveset, exigir que pesquisas inversas sejam banidas e não puder usar o servidor como nó por nenhum motivo, isso fornecerá uma terceira opção, embora menos ideal (devido ao RPS ser preferido sempre que possível). Para fazer isso, no servidor, em um prompt de comando elevado, execute: 

(echo . type: nsr & echo upd Disable RPS Clone: Yes) | nsradmin -i -

printf ". type: nsrla\nupd Disable RPS Clone: Yes\n" | nsradmin -i -

Não é necessário reiniciar o serviço. O próximo trabalho de clone deve começar com o RPS desativado.

Para problemas semelhantes com o NetWorker 19.11 que lida com falhas de backup relacionadas às novas configurações de estado inverso do DNS , consulte: NetWorker: Após o upgrade para a versão 19.11, o backup apresenta falha, relatando "Hostname resolution failed"