NetWorker: Klonowanie z włączoną obsługą RPS nie powiedzie się po uaktualnieniu do wersji 19.11, jeśli serwer ma stan odwrotnego DNS ustawiony na banned

Po uaktualnieniu do NetWorker 19.11 zadania klonowania nie będą wyglądały na odpowiadające, rejestrując następującą pętlę komunikatów:

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)

Problem pojawia się, gdy:

• Serwer ma ustawiony odwrotny stan DNS w bazie danych agenta lokalnego (nsrladb)
• Zadanie klonowania jest skonfigurowane do korzystania ze zdalnego węzła pamięci masowej zamiast serwera jako węzła źródłowego (odczytu)
• Zadanie klonowania wymaga RPS — ustawionego globalnie w zasobie NSR (serwer) (Wyłącz klonowanie RPS: Nie) lub automatycznie wywoływane ze względu na typ zbioru zapisu (vProxy/OAPP)

Zadanie nie zostało ukończone, zakończyło się niepowodzeniem lub musi zostać przerwane.

Wydaje się, że przyczyna jest związana ze zmianami komunikacji w oprogramowaniu NetWorker 19.11. Nowa wartość stanu odwrotnego DNS umożliwia administratorom usunięcie wymagań dotyczących dopasowywania wyszukiwania wstecznego, które były częścią usługi NetWorker od czasu jej pierwszych wersji.

Wydaje się jednak, że ta poważna zmiana wprowadziła problemy, które są obecnie badane. Mimo że odwrotny stan DNS nie jest domyślnie "zablokowany", administratorzy korzystający z niego na serwerze napotykają problemy z klonowaniem RPS, gdy używany jest oddzielny węzeł pamięci masowej.

Poprawka jest badana w błędzie NETWORKER-111382. W chwili pisania tego tekstu ta poprawka pojawi się dopiero w wersji NetWorker 19.11.0.5 lub NetWorker 19.12.0.1. 

W perspektywie krótkoterminowej istnieją trzy potencjalne sposoby obejścia tego problemu:

• Użyj odwrotnego stanu DNS: buforowany lub niebuforowany zamiast zakazany na serwerze. Jeśli obecnie polegasz na ustawieniu zakazanym dla kopii zapasowych klientów, które nie są rozwiązywalne wstecznie, aby zakończyć się powodzeniem, musisz upewnić się, że wpisy strefy wyszukiwania wstecznego DNS są tworzone dla adresów IP tych klientów, które mogą być odpytywane przez serwer NetWorker i węzły, aby mogły nadal działać. Aby zmienić to ustawienie na serwerze, w wierszu polecenia z podwyższonym poziomem uprawnień uruchom polecenie: 

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

Następnie uruchom ponownie usługi zgodnie ze zmianą:

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.

• Jeśli to możliwe, zmień węzeł źródłowy i docelowy w akcji klonowania, aby użyć serwera (nsrserverhost) zamiast węzła pamięci masowej. W przypadku zadań klonowania Data Domain węzeł pamięci masowej jest w dużej mierze nieistotny, ponieważ same systemy Data Domain obsługują ruch danych i jest zależny tylko od dostępu serwera do każdej domeny danych.
• Wyłącz RPS globalnie. Ostrzeżenie: Nie pomoże to w przypadku typów zbiorów zapisów, które wymagają RPS i automatycznie wywołują go w ramach operacji klonowania, takich jak zestawy zapisów vProxy i OAPP. Jeśli nie klonujesz tych typów zbiorów zapisów, wymagasz zbanowania wyszukiwania wstecznego i nie możesz używać serwera jako węzła z jakiegokolwiek powodu, zapewnia to trzecią, choć najmniej idealną opcję (ze względu na to, że RPS jest preferowany tam, gdzie to możliwe). W tym celu na serwerze w wierszu polecenia z podwyższonym poziomem uprawnień uruchom: 

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

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

Ponowne uruchomienie usługi nie jest wymagane — następne zadanie klonowania powinno rozpocząć się z wyłączonym RPS.

Aby uzyskać informacje o podobnych problemach z NetWorker 19.11 dotyczących błędów tworzenia kopii zapasowych związanych z nowymi ustawieniami stanu odwrotnego DNS , zobacz: NetWorker: Po uaktualnieniu do wersji 19.11 kopia zapasowa nie powiodła się, zgłaszając komunikat "Hostname resolution failed"