NetWorker: Anbefalte fremgangsmåter for feilsøking av navneløsing

NetWorker avhenger av navneløsing. Hvis navneløsingen ikke er riktig og helt konsekvent, kan det oppstå problemer i mange av NetWorkers operasjoner. Siden NetWorker administrerer potensielt sensitive data, må de sikre identiteten til vertene de samhandler med på ulike måter.

Et hvilket som helst antall symptomer i NetWorker kan være et resultat av ufullkommenheter i navneløsing i NetWorker:

• Feilmeldinger som indikerer problemer med videresending eller omvendt navneoppslag.
• Manglende evne til å undersøke klienter under sikkerhetskopiering
• Manglende evne til klienter å lagre manuelt på serveren eller gjenopprette.
• Problemer med kloning eller tilgang til lagringsnodeenheter
• Problemer med surfing eller mediedatabasepost.
• Server- eller lagringsnoden slutter å svare ved oppstart eller under vanlig drift.
• Feilnavnede eller nestede indekskataloger
• Feilkonfigurerte klientfeil

Arbeidsflyt for navneløsing

Forsøk på å løse et vertsnavn som brukes av kommando eller intern konfigurasjon må løses til en IP-adresse for å kunne brukes. Følgende ressurser kontrolleres, i følgende rekkefølge, for å se om navn:IP allerede er bufret, og stopper når navnet samsvarer. 

1. Hurtigbuffer for NetWorker-navn: De fleste store NetWorker-demoner; Konfigurerbar levetid i NSRLA-database 
2. Lokal vertsløserbuffer: Varierer etter operativsystem og utsetter belastning fra verter eller DNS-oppslag
3. Lokale vertsfiloppføringer : Raskt lokalt oppslag, men manuelt vedlikeholdt; nyttig å overstyre DNS-oppløsning
4. DNS-serveroppslag : Industrien foretrukket på grunn av sentralisert administrasjon, men tregere

1. NetWorker-hurtigbufring:

NetWorker-bakgrunnsprosesser vedlikeholder interne navnehurtigbuffere. Klienter cacher løste navn i nsrexecd, mens kjernedemoner som nsrd og nsmmdbd beholder sine egne cacher. Dette er den første IP-tabellen som sjekkes, og den raskeste. Levetiden for den interne hurtigbufferen kan angis i nsrla-databasen til hver NetWorker-vert ved hjelp av 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 verdien styrer hvor lang tid det tar før NetWorker bevisst tømmer prosessbufferen til fordel for oppdatert informasjon fra de neste lagene sekvensielt. Som sådan er det hensiktsmessig å heve det for miljøer der DNS-oppslag er tregt, men DNS-adressering er relativt statisk. Omvendt kan lavere verdier være ønskelig for miljøer med adresser som endres ofte. 

Hvis et påkrevd navn finnes i NetWorkers interne hurtigbuffer, brukes det, og ytterligere spørring stopper. Hvis bufrede navn-til-IP-tilordninger virker feil for feilsøking, bruker du kommandoer til å logge gjeldende hurtigbuffer og deretter tømme eller løse oppføringer på nytt:

• • dbgcommand -n nsrd PrintDnsCache=1 (Dump til daemon.raw)
  • dbgcommand -n nsrd FlushDnsCache=1 (Flush), eller, 
  • dbgcommand -n nsrd FlushDnsCache=9 (Tøm og umiddelbart løse / gjenoppbygge cache)

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

2. Resolver Cache:

• • Tømming av løserbufferen varierer avhengig av OS/distribusjon – se leverandørdokumentasjon.
  • Windows: ipconfig /flushdns

3. Hosts filer:

• • UNIX/Linux: /etc/hosts
  • Windows: % systemroot% System32 drivers etc hosts

4. Oppløsning fremover:

• Kjør nslookup uten argumenter for å gå inn i den interaktive ledeteksten.
• Skriv inn navniterasjonen som skal slås opp, og trykk enter for å hente videresendt post fra DNS-serveren du har koblet til.
• Skriv inn samme navn to ganger til for å se om navneposten er stille mellom forskjellige verter, eller returnerer de samme dataene.
• Gjenta den samme prosessen for enhver forekomst av et hvilket som helst navn som verten kan bli kalt av andre verter eller anser seg selv som for samme IP-adresse.
• Gjenta den samme prosessen for alle andre DNS-servere som verten er konfigurert til å potensielt bruke ved å skrive inn server next_dns_server.

5. Omvendt oppløsning:

• Kjør nslookup uten argumenter for å gå inn i den interaktive ledeteksten.
• Skriv inn angitt q=ptr for å endre spørringstypen til Omvendt sone.
• Skriv inn IP-adressen for å reversere løsningen, og trykk på Enter.
• Kontroller at navnet som returneres i omvendt post, samsvarer med navnet på videresendingsposten/IP-en.

[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.

Teste navneløsing

Alle NetWorker-verter må ha konsekvent navneløsing fremover og omvendt for alle verter de kommuniserer med, basert på datasonerollen. Det er viktig for NetWorker-administratorer å sørge for at eventuelle problemer med vertsoppløsning løses umiddelbart og fullstendig.
Når du feilsøker problemer med navneløsing, eller utelukker dem i NetWorker-datasonen:
    1. Finn alle verter som er involvert i den mislykkede operasjonen - server, klienter og muligens lagringsnoder, så videre.
    2. For hver av dem, bestem IP-adressene som er konfigurert lokalt, og alle forventede løsbare navn for disse IP-adressene.
    3. Konfigurer alle verter til å bruke vertsfilen før DNS for vertsoppløsning.
    4. I begynnelsen av en vertsvertsfil konfigurerer du en enkelt oppføring for hver IP, med hvert navn som tilsvarer den på samme linje.
    5. Kopier disse linjene nøyaktig fra den første verten til vertsfilene til de andre involverte vertene.
    6. Rediger NetWorker-klientobjektene slik at aliasene samsvarer riktig med de ønskede IP-adressene.
    7. Slå av NetWorker på alle involverte verter.
    8. Tøm resolverbufferen på hver vert ved hjelp av riktig operativsystemmekanisme.
    9. Start NetWorker på nytt, og prøv den problematiske operasjonen på nytt.

For å bevise at navnet er løst av en gitt vert, bruk denne testen:
    1. Fra den første NetWorker-verten (for eksempel klienten) kobler du til den andre (for eksempel serveren) ved hjelp av nsradmin -s remote_host -p nsrexec - La økten være åpen.
    2. På samme vert bestemmer du prosessen for nsradmin (for eksempel Windows, tasklist | findstr nsradmin)
3. Kjør netstat for å vise sokkelen som er knyttet til denne prosessen (for eksempel Windows, netstat -ao | findstr process_id)
4. Bestem tilkoblingskontakten fra den verten (IP:port-paringen lengst til venstre i utdataene)
5. På den eksterne verten - kjør netstat -a og findstr/grep for :calling_port_from_first_host.
    6. Vertsnavnet før kolon er hvordan den andre verten løser den første verten når den godtar den innkommende tilkoblingen.
    7. Kjør igjen med -n -bryteren lagt til netstat-kommandoen for å verifisere IP-adressen til samme kontakt, for å sjekke om IP / rute forventes.
    8. Reverser den samme testen for å sikre at den andre verten løser den første verten innenfor forventede parametere.

Om NetWorker-klientaliaser

NetWorker har også et konfigurerbart felt som er globalt for alle klientforekomster kalt 'Aliaser', som skal gjenspeile alle navn som kan løses for den klienten. Dette lar NetWorker koble flere løste navn til én klientforekomst. For eksempel kan client1.domain.prod også vises som client1.domain.bkup eller client1, avhengig av hvilken IP som brukes.

NetWorker-operasjoner som savegroup bruker flere TCP-socketer: én hver for kontroll-, data- og indeksoppdateringer. Hvis en sokling bruker et inkonsekvent (men gyldig) navn, kan operasjonen mislykkes.

• Round-robining brukes og konfigureres noen ganger bevisst - men er vanligvis uventet og bør unngås
• netstat -a avslører åpne/aktive TCP-kontakter, som avslører det OS-løste navnet på den utenlandske verten - dette kan brukes til å identifisere problemer
• Statisk ruting kan noen ganger være nødvendig når nettverkstrafikk bruker en uventet/uønsket adapter, noe som senere kan føre til problemer med navneløsing.

Se også:  NetWorker-prosesser og -porter