NetWorker: RPS-aktivert kloning mislykkes etter oppgradering til 19.11 hvis serveren har omvendt DNS-tilstand satt til utestengt

Når du har oppgradert til NetWorker 19.11, vises det som om klonejobber ikke svarer, og følgende sløyfe med meldinger logges:

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)

Problemet oppstår når:

• Serveren har omvendt DNS-tilstand: utestengt angitt i Local Agent-databasen (nsrladb)
• Klonjobben er konfigurert til å bruke en ekstern lagringsnode i stedet for serveren som kildenode (lese)
• Klonjobb krever RPS – enten angitt globalt i NSR-ressursen (Server) (Deaktiver RPS-kloning: Nei) eller automatisk aktivert på grunn av saveset-type (vProxy/OAPP)

Jobben fullføres ikke, mislykkes eller må avbrytes.

Årsaken ser ut til å være relatert til kommunikasjonsendringer i NetWorker 19.11. Med den nye omvendte DNS-tilstandsverdien kan administratorer fjerne samsvarskrav for omvendt oppslag, som har vært en del av NetWorker siden de første utgivelsene.

Denne store endringen ser imidlertid ut til å ha introdusert problemer som er under utredning. Selv om omvendt DNS-tilstand ikke er "utestengt" som standard, møter administratorer som bruker den på serveren problemer med RPS-kloning når en separat lagringsnode brukes.

Reparasjonen blir undersøkt i feilen NETWORKER-111382. I skrivende stund vises ikke denne løsningen før tidligst NetWorker 19.11.0.5 eller NetWorker 19.12.0.1. 

På kort sikt er det tre potensielle løsninger for problemet:

• Bruk omvendt DNS-tilstand: bufret eller ubufret i stedet for utestengt på serveren. Hvis du for øyeblikket er avhengig av den forbudte innstillingen for sikkerhetskopier av klienter som ikke kan løses omvendt, må du sørge for at omvendte DNS-oppslagssoneoppføringer opprettes for disse klientenes IP-adresser, som NetWorker-serveren og noder kan spørre etter, for at de skal fortsette å fungere. Hvis du vil endre denne innstillingen på serveren, kjører du ved en hevet ledetekst: 

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

Start deretter tjenestene på nytt etter endringen:

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.

• Endre kilde- og målnodene i klonehandlingen til å bruke serveren (nsrserverhost) i stedet for en lagringsnode, hvis det er mulig. For Data Domain-klonejobber er lagringsnoden stort sett irrelevant siden datadomenene selv håndterer datatrafikken, og er bare avhengig av serverens tilgang til hvert datadomene.
• Deaktiver RPS globalt. Advarsel: Dette hjelper ikke med lagringssetttyper som krever RPS og automatisk starter det som en del av kloningsoperasjonen, for eksempel vProxy- og OAPP-lagringssett. Hvis du ikke kloner disse lagrede typene, krever at omvendte oppslag skal forbys, og ikke kan bruke serveren som node av en eller annen grunn, gir dette et tredje, om minst ideelt alternativ (på grunn av at RPS foretrekkes der det er mulig). Hvis du vil gjøre dette, kjører du på serveren ved en hevet ledetekst: 

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

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

Det er ikke nødvendig å starte på nytt – den neste klonejobben skal starte med RPS deaktivert.

Når det gjelder lignende problemer med NetWorker 19.11 som håndterer sikkerhetskopieringsfeil relatert til de nye innstillingene for omvendt DNS-tilstand , kan du se: NetWorker: Når sikkerhetskopieringen til 19.11 mislykkes, rapporteres "vertsnavnsløsingen mislyktes"