NetWorker: NMC mangler detaljer i enhver fane. Daemon har fejl Modtaget ingen resultater for NSR Storage Node-ressourceforespørgsel for X på server X

Værtsfilposten var blevet opdateret, siden NetWorker sidst startede, med forkerte oplysninger.

Efter NetWorker-genstart eller servergenstart skal du have begge disse problemer:
NMC har ingen detaljer i nogen fane OG dæmonen har fejl nsrd RAP-advarsel Modtog ingen resultater for NSR Storage Noderessourceforespørgsel efter <navn> på servernavn <>

NSRWATCH viser, at serveren ser ud til at fungere normalt

Begge problemer er et symptom på en ændring af servernavnet fra FQDN til kort navn eller omvendt.

• Da EMC-support så problemet, begyndte fejlen: nsrd RAP-advarsel Modtog ingen resultater for NSR Storage Node-ressourceforespørgsel om <navn> på servernavn <> efter en NetWorker-genstart.
• <navn>var det korte navn på serveren, og den lagernode, den klager over, er til selve NW-serveren.
• Ved inspektion af lagernoderessourcen til backupserveren ved hjælp af nsradmin blev noden defineret som FQDN, som i name.domain.com - en noderessource kan ikke have et alias (selvom en klient kan).

Generelt bør værtsfiler ikke være nødvendige, hvis DNS fungerer korrekt.

• Hvis EMC-understøttelsen fungerede, var DNS-opslaget korrekt og returnerede FQDN som forventet.
• /etc/hosts havde en post for NW-serveren som: [IP-adresse] > [kort navn] > [FQDN]
• Fjernelse (eller hashing) af værtsposten for NW-serveren (så den kun brugte DNS til navnefortolkning), og derefter genstart af NetWorker løste problemet

Når NW genstartede, var fejlen 'nsrd RAP warning Received no results for NSR Storage Node resource query for <name> on server <name>' ikke længere til stede, og når GST var blevet genstartet, fungerede NMC normalt igen.

Dette skyldes, at NetWorker hentede det korte navn for sig selv fra værtsposten og forårsagede nogle navneløsningsproblemer, set som lagernodefejl og NMC-problemer.

Hvis værtsfilposter foretrækkes, vil ændring til '[IP-adresse] > [FQDN] > [kort navn]' løse dette.

Det er muligt (i det seneste tilfælde), at:

• Den forkerte værtspost (eller en anden faktor) blev foretaget, efter at NetWorker oprindeligt blev konfigureret, og derfor brugte NetWorker FQDN til sin lagernoderessource og GST-databasen.
• At en OS-konfigurationsændring eller programrettelse kan have ændret opslagsrækkefølgen fra DNS først til hostfil først

NetWorker ville ikke være blevet påvirket, før genstartet.