NetWorker: Bästa praxis för felsökning av namnmatchning

NetWorker är beroende av namnmatchning. Om namnmatchningen inte är korrekt och helt konsekvent kan det uppstå problem i många av NetWorkers verksamheter. Eftersom NetWorker hanterar potentiellt känsliga data måste det säkerställa identiteten hos de värdar som det interagerar med på olika sätt.

Ett antal symptom i NetWorker kan bero på fel i namnmatchning i NetWorker:

• Felmeddelanden som indikerar problem med att slå upp namn framåt eller bakåt.
• Det går inte att avsöka klienter under säkerhetskopieringen
• Det går inte att spara klienter manuellt på servern eller återställa.
• Problem med kloning eller åtkomst till lagringsnodenheter
• Problem med bläddring eller mediadatabaspost.
• Servern eller lagringsnoden slutar svara vid start eller under normal drift.
• Felaktigt namngivna eller kapslade indexkataloger
• Felkonfigurerade klientfel

Arbetsflöde för namnmatchning

Försök att matcha ett värdnamn som används av ett kommando eller en intern konfiguration måste matchas till en IP-adress för att kunna användas. Följande resurser kontrolleras, i följande ordning, för att se om namnet:IP redan har cachelagrats, och stoppas när namnet matchas. 

1. NetWorker-namncache: De flesta större NetWorker-demoner; Konfigurerbar livslängd i NSRLA-databas 
2. Lokal värdmatcharcache: Varierar beroende på operativsystem och skjuter upp belastning från värdar eller DNS-sökningar
3. Filposter för lokala värdar: Snabb lokal sökning, men manuellt underhållen; användbart för att åsidosätta DNS-upplösning
4. DNS-serversökningar : Branschen föredras på grund av centraliserad administration, men långsammare

1. NetWorker-cachelagring:

NetWorker-daemoner underhåller interna namncacher. Klienter cachelagrar matchade namn i nsrexecd, medan kärndaemoner som nsrd och nsmmdbd behåller sina egna cacheminnen. Det här är den första IP-tabellen som kontrolleras, och den snabbaste. Livslängden för interna cacheminnen kan ställas in i varje NetWorker-värds nsrla-databas med hjälp 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

Bör returnera 30 minuter som standard (1800 sekunder):

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

Det här värdet styr hur lång tid det tar innan NetWorker avsiktligt rensar processcachen till förmån för uppdaterad information från nästa lager sekventiellt. Därför är det lämpligt att höja den för miljöer där DNS-sökningen är långsam, men DNS-adresseringen är relativt statisk. Omvänt kan lägre värden vara önskvärda för miljöer med adresser som ändras ofta. 

Om det finns ett obligatoriskt namn i NetWorkers interna cache används det och ytterligare frågor stoppas. För felsökning, om cachelagrade namn-till-IP-mappningar verkar fel, använd kommandon för att logga den aktuella cachen och töm eller matcha sedan poster:

• • dbgcommand -n nsrd PrintDnsCache=1 (Dumpa till daemon.raw)
  • dbgcommand -n nsrd FlushDnsCache=1 (Flush), eller, 
  • dbgcommand -n nsrd FlushDnsCache=9 (Spola och lös omedelbart/återskapa cacheminnet)

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

2. Lösningscacheminne:

• • Tömningsmatchcachen varierar beroende på operativsystem/distribution – se leverantörens dokumentation.
  • Windows: ipconfig /flushdns

3. Hosts-filer:

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

4. Framtida upplösning:

• Kör nslookup utan argument för att ange den interaktiva prompten.
• Ange namnet iteration som ska slås upp och tryck på Retur för att hämta vidarebefordran av posten från den DNS-server som du har anslutit till.
• Ange samma namn två gånger till för att se om namnposten resursallokering tyst mellan olika värdar eller returnerar samma data.
• Upprepa samma process för alla instanser av alla namn som värden kan anropas av andra värdar eller betrakta sig själv som för samma IP-adress.
• Upprepa samma process för alla andra DNS-servrar som värden är konfigurerad att potentiellt använda genom att ange server next_dns_server.

5. Omvänd upplösning:

• Kör nslookup utan argument för att ange den interaktiva prompten.
• Ange uppsättning q=ptr för att ändra frågetypen till den omvända zonen.
• Ange IP-adressen som ska lösas omvänt och tryck på Retur.
• Kontrollera att namnet som returneras i den omvända posten matchar namnet på den framåtriktade posten/IP-adressen.

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

Testa namnmatchning

Alla NetWorker-värdar måste ha konsekvent namnmatchning framåt och bakåt för alla värdar de kommunicerar med, baserat på deras Data Zone-roll. Det är viktigt för NetWorker-administratörer att säkerställa att eventuella problem med värdmatchning åtgärdas omedelbart och fullständigt.
När du felsöker problem med namnmatchning eller för att utesluta dem i NetWorker-datazonen:
    1. Hitta alla värdar som är inblandade i den misslyckade åtgärden – server, klienter och eventuellt lagringsnoder osv.
    2. För var och en fastställs de IP-adresser som konfigurerats lokalt och alla förväntade matchningsbara namn för dessa IP-adresser.
    3. Konfigurera alla värdar så att den använder hosts-filen före DNS för värdmatchning.
    4. I början av en värds värdfil konfigurerar du en enda post för varje IP-adress, med varje namn som motsvarar den på samma rad.
    5. Kopiera dessa rader exakt från den första värden till värdfilerna för de andra berörda värdarna.
    6. Redigera NetWorker-klientobjekten så att aliasen motsvarar de önskade IP-adresserna.
    7. Stäng av NetWorker på alla berörda värdar.
    8. Rensa resolvercachen på varje värd med hjälp av lämplig operativsystemsmekanism.
    9. Starta om NetWorker och försök utföra den problematiska åtgärden igen.

Använd det här testet för att bevisa att namnet matchas av en viss värd:
    1. Från den första NetWorker-värden (t.ex. klienten) ansluter du till den andra (t.ex. servern) med hjälp av nsradmin -s remote_host -p nsrexec - Lämna sessionen öppen.
    2. På samma värd bestämmer du processen för nsradmin (till exempel Windows, tasklist | findstr nsradmin)
3. Kör netstat för att visa socketen som är associerad med den processen (till exempel Windows, netstat -ao | findstr process_id)
4. Fastställ det anslutande uttaget från den värden (IP:port-parkopplingen längst till vänster i utgången)
5. På fjärrvärden – kör netstat -a och findstr/grep för :calling_port_from_first_host.
    6. Värdnamnet före kolonet är hur den andra värden matchar den första värden när den inkommande anslutningen accepteras.
    7. Kör igen med -n switch tillagt i netstat-kommandot för att verifiera IP-adressen för samma socket, för att kontrollera om IP-adressen/rutten förväntas.
    8. Gör om samma test för att säkerställa att den andra värddatorn löser problemet med den första värden inom förväntade parametrar.

Om NetWorker-klientalias

NetWorker har också ett konfigurerbart fält som är globalt för alla klientinstanser med namnet "Aliases", som bör återspegla alla namn som kan matchas för klienten. På så sätt kan NetWorker länka flera matchade namn till en klientinstans. Client1.domain.prod kan till exempel även visas som client1.domain.bkup eller client1, beroende på vilken IP-adress som används.

NetWorker-åtgärder som savegroup använder flera TCP-socketar: en vardera för kontroll-, data- och indexuppdateringar. Om en socket använder ett inkonsekvent (men giltigt) namn kan åtgärden misslyckas.

• Resursallokering används ibland avsiktligt och konfigureras – men är vanligtvis oväntat och bör undvikas
• netstat -a avslöjar öppna/aktiva TCP-sockets, som avslöjar OS-löst namn på den främmande värden - detta kan användas för att identifiera problem
• Statisk routning kan ibland vara nödvändigt när nätverkstrafik använder ett oväntat/oönskat kort, vilket senare kan leda till problem med namnmatchning.

Se även:  NetWorker-processer och portar