NetWorker: Fejlfinding af navnefortolkning Bedste praksis

NetWorker afhænger af navnefortolkning. Hvis navnefortolkningen ikke er korrekt og helt konsistent, kan der opstå problemer i mange af NetWorkers operationer. Da NetWorker administrerer potentielt følsomme data, skal det sikre identiteten af de værter, som det interagerer med på forskellige måder.

Et vilkårligt antal symptomer i NetWorker kan være resultatet af ufuldkommenheder i navneopløsning i NetWorker:

• Fejlmeddelelser, der angiver problemer med fremad- eller omvendt navneopslag.
• Manglende evne til at undersøge klienter under sikkerhedskopiering
• Klienters manglende evne til manuelt at gemme på serveren eller gendanne.
• Problemer med kloning af eller adgang til Storage Node-enheder
• Problemer med browsing eller mediedatabaseregistrering.
• Server- eller storagenode holder op med at reagere ved opstart eller under normal drift.
• Forkert navngivne eller indlejrede indeksmapper
• Fejl i forkert konfiguration af klient

Arbejdsproces for navnefortolkning

Forsøg på at fortolke et værtsnavn, der bruges af kommando eller intern konfiguration, skal løses til en IP-adresse for at blive brugt. Følgende ressourcer kontrolleres i følgende rækkefølge for at se, om navnet:IP allerede er cachelagret, og stopper, når navnet matches. 

1. NetWorker-navnecache: De fleste større NetWorker-dæmoner; Konfigurerbar levetid i NSRLA-database 
2. Lokal host resolver cache: Varierer afhængigt af operativsystem og udskyder indlæsning fra værter eller DNS-opslag
3. Lokale værtsfilposter : Hurtigt lokalt opslag, men manuelt vedligeholdt; nyttigt at tilsidesætte DNS-opløsning
4. DNS-serveropslag : Industrien foretrækkes på grund af centraliseret administration, men langsommere

1. NetWorker-cachelagring:

NetWorker-dæmoner vedligeholder interne navnecacher. Klienter cachelagrer løste navne i nsrexecd, mens kernedæmoner som nsrd og nsmmdbd holder deres egne cacher. Dette er den første IP-tabel, der kontrolleres, og den hurtigste. Den interne cachelevetid kan indstilles i hver NetWorker-værts nsrla-database ved hjælp af nsradmin:

Linux/UNIX

printf ". type: nsrla\nshow positive DNS cache TTL; negative DNS cache TTL\nprint\n" | nsradmin -p nsrexec -s remote_host

Windows

(echo . type: nsrla & echo show positive DNS cache TTL; negative DNS cache TTL & echo print) | nsradmin -p nsrexec -s remote_host

Skal returnere 30 minutter som standard (1800 sekunder):

positive DNS cache TTL: 1800;
negative DNS cache TTL: 1800;

Denne værdi styrer, hvor lang tid der går, før NetWorker bevidst renser procescachen til fordel for opdaterede oplysninger fra de næste lag sekventielt. Som sådan er det passende at hæve det for miljøer, hvor DNS-opslag er langsomt, men DNS-adressering er relativt statisk. Omvendt kan lavere værdier være ønskelige for miljøer med hyppigt skiftende adresser. 

Hvis et påkrævet navn findes i NetWorkers interne cache, bruges det, og yderligere forespørgsler stopper. Hvis cachelagrede navne-til-IP-tilknytninger virker forkerte til fejlfinding, skal du bruge kommandoer til at logføre den aktuelle cache og derefter rydde eller løse problemer igen:

• • dbgcommand -n nsrd PrintDnsCache=1 (Dump til daemon.raw)
  • dbgcommand -n nsrd FlushDnsCache=1 (Flush), eller 
  • dbgcommand -n nsrd FlushDnsCache=9 (Skyl cachen for at løse den igen/genopbyg den med det samme)

• • Linux/UNIX: ps -ef | grep nsr 
  • Windows: tasklist | findstr nsr

2. Resolver Cache:

• • Lagertømning af resolvercache varierer afhængigt af operativsystem/distribution – se leverandørdokumentation.
  • Windows: ipconfig /flushdns

3. Hoster filer:

• • UNIX/Linux: /etc/værter
  • Windows: %systemroot%\System32\drivers\etc\hosts

4. Fremadrettet løsning:

• Kør nslookup uden argumenter for at åbne den interaktive prompt.
• Indtast navnet iteration til opslag, og tryk på enter for at hente forward record fra den DNS-server, du har oprettet forbindelse til.
• Indtast det samme navn to gange mere for at se, om navneposten er round-robining lydløst mellem forskellige værter eller returnerer de samme data.
• Gentag den samme proces for enhver forekomst af ethvert navn, som værten kan kaldes af andre værter eller betragte sig selv som for den samme IP-adresse.
• Gentag den samme proces for enhver anden DNS-server, som værten er konfigureret til potentielt at bruge ved at indtaste serverens next_dns_server.

5. Omvendt opløsning:

• Kør nslookup uden argumenter for at åbne den interaktive prompt.
• Indtast sæt q=ptr for at ændre forespørgselstypen til Omvendt zone.
• Indtast IP-adressen for at løse problemet omvendt, og tryk på Enter.
• Kontrollér, at det navn, der returneres i den omvendte post, stemmer overens med forwardpostens navn/IP.

[root@linux_a~]# nslookup linux_a
Server:         1.2.3.4
Address:        1.2.3.4#53
Name:   linux_a.domain.com
Address: 5.6.7.8
         
[root@linux_a~]# nslookup 5.6.7.8
Server:         1.2.3.4
Address:        1.2.3.4#53
Name:   linux_a.domain.com
Address: 5.6.7.8
         
[root@linux_a~]# nslookup
> set q=ptr
> 5.6.7.8
Server:         1.2.3.4
Address:        1.2.3.4#53
Non-authoritative answer:
8.7.6.5.in-addr.arpa        name = linux_a.domain.com.

Test af navneopløsning

Alle NetWorker-værter skal have ensartet fremadrettet og omvendt navnefortolkning for enhver vært, de kommunikerer med, baseret på deres datazonerolle. Det er afgørende for NetWorker-administratorer at sikre, at eventuelle problemer med værtsløsningen håndteres øjeblikkeligt og fuldstændigt.
Når du foretager fejlfinding af problemer med navnefortolkning eller for at udelukke dem i din NetWorker-datazone:
    1. Find alle værter, der er involveret i den mislykkede handling - server, klienter og muligvis lagernoder osv.
    2. For hver bestemmes IP-adresserne, der er konfigureret lokalt, og alle forventede opløselige navne for disse IP'er.
    3. Konfigurer alle værter til at bruge værtsfilen før DNS til værtsopløsning.
    4. I begyndelsen af en værtsværtsfil skal du konfigurere en enkelt post for hver IP, hvor hvert navn svarer til den på samme linje.
    5. Kopier disse linjer nøjagtigt fra den første vært til værtsfilerne for de andre involverede værter.
    6. Rediger NetWorker-klientobjekterne, så de har aliasser, der svarer korrekt til de ønskede IP-adresser.
    7. Luk NetWorker ned for alle involverede værter.
    8. Ryd resolver-cachen på hver vært ved hjælp af den relevante operativsystemmekanisme.
    9. Genstart NetWorker, og forsøg den problematiske handling igen.

For at bevise, at navnet er løst af en given vært, skal du bruge denne test:
    1. Fra den første NetWorker-vært (f.eks. klienten) skal du oprette forbindelse til den anden (f.eks. serveren) ved hjælp af nsradmin -s remote_host -p nsrexec - Lad sessionen være åben.
    2. På samme vært skal du bestemme processen for nsradmin (f.eks. Windows, tasklist | findstr nsradmin)
3. Kør netstat for at vise den sokkel, der er knyttet til den pågældende proces (f.eks. Windows, netstat -ao | findstr process_id)
4. Bestem tilslutningsstikket fra den pågældende vært (IP:port-parringen længst til venstre i udgangen)
5. På fjernværten - kør netstat -a og findstr/grep for :calling_port_from_first_host.
    6. Værtsnavnet før kolon er, hvordan den anden vært løser den første vært, når den indgående forbindelse accepteres.
    7. Kør igen med -n switch tilføjet til netstat-kommandoen for at verificere IP'en for den samme sokkel, for at kontrollere, om IP / rute forventes.
    8. Vend den samme test tilbage for at sikre, at den anden vært løser problemet med den første vært inden for de forventede parametre.

Om NetWorker-klientaliasser

NetWorker har også et konfigurerbart felt, der er globalt for alle klientforekomster kaldet "aliasser", som bør afspejle alle navne, der kan løses for den pågældende klient. Dette gør det muligt for NetWorker at knytte flere fortolkede navne til én klientforekomst. For eksempel kan client1.domain.prod også vises som client1.domain.bkup eller client1, afhængigt af den anvendte IP.

NetWorker-handlinger som savegroup bruger flere TCP-sokler: en hver til kontrol-, data- og indeksopdateringer. Hvis en sokkel bruger et inkonsekvent (men gyldigt) navn, kan handlingen mislykkes.

• Round-robining bruges og konfigureres undertiden bevidst - men er normalt uventet og skal undgås
• netstat -a afslører åbne/aktive TCP-stik, som afslører det OS-løste navn på den udenlandske vært - dette kan bruges til at identificere problemer
• Statisk routing kan nogle gange være nødvendig, når netværkstrafik bruger en uventet/uønsket adapter, hvilket senere kan føre til problemer med navneopløsning.

Se også:  NetWorker-processer og -porte