NetWorker: La clonazione abilitata per RPS non riesce dopo l'aggiornamento a 19.11 se il server ha lo stato DNS inverso impostato su banned

Dopo l'aggiornamento a NetWorker 19.11, i job di clonazione non rispondono, registrando il seguente ciclo di messaggi:

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)

Il problema si verifica quando:

• Il server ha stato DNS inverso: banned set nel database dell'agente locale (nsrladb)
• Il processo di clonazione è configurato per utilizzare uno storage node remoto anziché il server come nodo di origine (lettura)
• Il processo di clonazione richiede RPS, impostato a livello globale nella risorsa NSR (Server) (Disabilitare RPS Clone: No) o richiamato automaticamente a causa del tipo di saveset (vProxy/OAPP)

Il processo non viene completato e ha esito negativo o deve essere interrotto.

La causa sembra essere correlata a modifiche alle comunicazioni in NetWorker 19.11. Il nuovo valore dello stato del DNS inverso consente agli amministratori di rimuovere i requisiti di corrispondenza di ricerca inversa, che fanno parte di NetWorker sin dalle sue versioni iniziali.

Tuttavia, questo importante cambiamento sembra aver introdotto questioni che sono oggetto di indagine. Anche se lo stato DNS inverso non è "vietato" per impostazione predefinita, gli amministratori che lo utilizzano sul server riscontrano problemi con la clonazione RPS quando viene utilizzato uno storage node separato.

La correzione è in fase di analisi nel bug NETWORKER-111382. Al momento in cui scriviamo, questa correzione non verrà visualizzata almeno fino a quando non sarà disponibile NetWorker 19.11.0.5 o NetWorker 19.12.0.1. 

A breve termine, esistono tre potenziali soluzioni alternative per il problema:

• Usa lo stato DNS inverso: memorizzato nella cache o non memorizzato nella cache invece di bannato sul server. Se attualmente ci si affida all'impostazione vietata per la riuscita dei backup dei client non risolvibili tramite inverso, sarà necessario assicurarsi che le voci della zona di ricerca DNS inversa vengano create per gli indirizzi IP di tali client, interrogabili dal server e dai nodi NetWorker, affinché continuino a funzionare. Per modificare questa impostazione sul server, in un prompt dei comandi con privilegi elevati, eseguire: 

(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 -

Quindi riavviare i servizi dopo la modifica:

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.

• Modificare i nodi di origine e di destinazione nell'azione clone in modo da utilizzare il server (nsrserverhost) anziché uno storage node, se possibile. Per i job di clonazione di Data Domain, lo storage node è in gran parte irrilevante poiché i Data Domain stessi gestiscono il traffico di dati e dipende solo dall'accesso del server a ciascun Data Domain.
• Disabilitare RPS globalmente. Avvertenza: Ciò non è utile per i tipi di saveset che richiedono RPS e lo richiamano automaticamente come parte dell'operazione di clonazione, ad esempio i saveset vProxy e OAPP. Se non si clonano questi tipi di saveset, non è necessario impedire le ricerche inverse e non è possibile usare il server come nodo per qualsiasi motivo, si ottiene una terza opzione, anche se meno ideale (perché è preferibile RPS ove possibile). A tale scopo, sul server, in un prompt dei comandi con privilegi elevati, eseguire: 

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

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

Non è necessario riavviare il servizio: il processo di clonazione successivo dovrebbe iniziare con RPS disabilitato.

Per problemi simili con NetWorker 19.11 riguardanti gli errori di backup correlati alle nuove impostazioni dello stato del DNS inverso , consultare: NetWorker: Dopo l'aggiornamento alla versione 19.11, il backup non riesce segnalando "Hostname resolution failed"