NetWorker är beroende av namnmatchning. Om namnmatchningen inte är korrekt och är helt konsekvent kan problem uppstå i många av NetWorker-åtgärder. Eftersom NetWorker hanterar potentiellt känsliga data måste det säkerställa identiteterna för de värdar som de interagerar med på olika sätt.
Ett antal symptom i NetWorker kan bero på namnmatchningsarymptom i NetWorker:
- Felmeddelanden som indikerar problem med vanlig eller omvänd namnsökning.
- Det går inte att avsöka klienter under säkerhetskopiering.
- Det går inte att spara klienter manuellt på servern eller återställa.
- Problem med att klona eller komma åt Lagringsnodsenheter.
- Problem med bläddring eller mediedatabaspost.
- Server- eller lagringsnoden slutar svara vid start eller under normal drift.
- Felmärkta eller kapslade indexkataloger.
- Felkonfigurerade klientfel.
Namnmatchning sker utifrån olika mekanismer och på olika nivåer:
- NetWorker-namncache
- Cacheminne för lokal värd
- Lokala värdars filposter
- DNS-serversökningar
Namnmatchningsmetodik
1. NetWorker-cachelagring: NetWorker upprätthåller ett internt namncacheminne och kanske inte återspeglar miljöändringar som gjorts för att korrigera namnmatchningsproblem utan att starta om tjänsterna. NetWorker har också ett konfigurerbart fält som är globalt för alla klientinstanser som kallas "Alias", vilket måste återspegla alla namn som kan lösas för den klientinstansen för att undvika problem av flera typer. Om ett obligatoriskt namn finns i NetWorker:s interna cacheminne används det därifrån och värdens Resolver-cacheminne stöds inte. NetWorker-serverns daemon (nsrd) kan dumpa sitt lösta namncacheminne i daemon.raw, rensa cacheminnet eller rensa och matcha namn på nytt:
- dbgcommand -nsrd PrintDnsCache=1 (dump till daemon.raw)
- dbgcommand -nsrd FlushDnsCache=1 (rensning )
- dbgcommand -nsrd FlushDnsCache=9 (rensa och lösa)
- För ovanstående kommandon kan antingen "-n process name" eller "-p PID" användas. För att använda PID måste du köra andra kommandon först för att få PID; till exempel "ps -ef | grep nsr" (Linux) eller "tasklist | findstr nsr" (windows)
2. Lös cacheminne: Alla värdar och operativsystem har ett lokalt matcharcacheminne som underlättar värdmatchningen och hastigheten utan att förlita sig på värdfiler eller DNS-servrar. Cacheminnet kontrolleras enligt normala namnmatchningsregler för operativsystemet och om värdposten finns (även om den är gammal eller felaktig) används den innan du frågar någon annan datakälla. Resolver-cacheposter anges i cacheminnet vid det första "lyckade" åtgärdsförsöket och ligger kvar en förutbestämd tid. Vissa operativsystem kan visa innehållet i matcharcache (till exempel kan Windows-värdar köra ipconfig /displaydns) och alla har en mekanism för att framtvinga eller rensa det:
- Tömningen av DNS i Linux kan variera beroende på linux-distribution och installerade paket. Mer information finns i leverantörens dokumentation.
- Windows: ipconfig /flushdns
3. Värdars filer: Den äldre mekanismen för värdmatchning är att uttryckligen ange IP-adressen, följt av alla namn som ska matcha den adressen, på separata rader avgränsade med blanksteg. Detta kontrolleras före DNS som standard i Windows. Källordningen för Linux-upplösning kan vanligtvis konfigureras i /etc/nsswitch.conf eller /etc/netsvc.conf. Värdfiler tolkas endast för den första matchande posten som efterfrågas, vilket innebär att alla andra instanser av en IP-adress eller ett värdnamn, korta eller långa, aldrig hittas när namn matchas. Varje namn eller IP bör endast visas en gång eftersom alla namn ska anges på samma rad som motsvarande IP-adress.
- Unix/Linux: /etc/hosts
- Windows: %systemroot%\System32\drivers\etc\hosts
Obs! Värdfiler kan skadas, precis som alla andra filer. Om du är osäker byter du namn på den befintliga värdfilen, skapar den nya, rensar matcharens cacheminne och försöker igen.
4. Framåtlösning: Om du vill kommunicera med en främmande värd när namnet anges måste en värd upptäcka att externa värdars IP-adress för TCP/IP-kommunikation ska uppstå; När du använder DNS måste frågan utföras för värdnamnet i zonen för vanlig sökning för att hämta IP-adressen. Flera DNS-värdar kan konfigureras för att en klient ska kunna använda; på Windows-system använder du ipconfig /all för att få DNS-namn; på Linux/UNIX-operativsystem har /etc/resolv.conf vanligtvis DNS-serverordningen. nslookup är det vanligaste verktyget för att fråga efter DNS och finns på alla plattformar, men används ofta felaktigt; så här frågar du forward-zonen:
- Kör nslookup utan argument för att ange den interaktiva prompten.
- Ange det namn iteration du vill söka efter och tryck på Retur för att hämta post för vidarebefordran från den DNS-server som du har anslutit till.
- Ange samma namn två gånger till för att se om namnposten round-robining 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 anses ha samma IP-adress.
- Upprepa samma process för alla andra DNS-servrar som värden är konfigurerade för potentiell användning genom att ange next_dns_server.
Obs! Alla poster som returneras måste vara konsekventa mellan sig och överensstämde med vad administratören tolkar det som korrekt. och alla kända namn måste anges och kontrolleras.
5. Omvänd upplösning: Om du vill kommunicera med en främmande värd när IP-adressen anges kan värden behöva hitta värdens namn; När du använder DNS utförs frågan mot zonen omvänd sökning för att hitta värdnamnet för den aktuella IP-adressen. Det här används ofta felaktigt, eftersom det inte går att ange nslookup IP_Address eller ange IP-adressen i nslookup i zonen för omvänd sökning:
- Kör nslookup utan argument för att ange den interaktiva prompten.
- Ange q=ptr för att ändra frågetyp till omvänd zon.
- Ange IP-adressen för att lösa problemet omvänd och tryck på Retur.
- Kontrollera att det namn som returneras i omvänd post matchar det framåtriktade postnamnet/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.
I exemplet ovan är det tydligt att när du kör nslookup icke-interaktivt frågar du aldrig zonen för omvänd sökning.
Obs! NetWorker är mycket beroende av perfekta och konsekventa omvända lösningar och standardupplösning framåt. Det här är en del av auktoriseringsprocessen och har den som utgångspunkt för att förhindra IP-spoofing eller andra typer av attacker som är avsedda att stjäla säkerhetskopieringsdata.
Upplösning
Alla NetWorker-värdar måste garanteras att ha konsekvent namnmatchning, både framåt och bakåt, för alla värdar som de kommunicerar med (som varierar beroende på datazonens roll). Det är viktigt att NetWorker-administratörer ser till att eventuella värdmatchningsproblem åtgärdas omedelbart och helt och hållet.
När du felsöker problem med namnmatchning eller utesluter dem i Din NetWorker-datazon:
1. Hitta alla värdar som är inblandade i den misslyckade åtgärden – servrar, klienter och eventuellt lagringsnoder osv.
2. För varje fastställer IP-adresserna som konfigurerats lokalt och alla förväntade matchningsbara namn för dessa IP-adresser.
3. Konfigurera alla värdar att använda värdfilen före DNS för värdmatchning.
4. I början av en värdfil konfigurerar du en enda post för varje IP, 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 de har alias som motsvarar de önskade IP-adresserna.
7. Stäng av NetWorker på alla berörda värdar
8. Rensa matcharcacheminnet på varje värd med rätt operativsystemmekanism
9. Starta om NetWorker och försök att utföra den problematiska åtgärden igen
Om du vill bevisa att namnet har lösts av en viss värd använder du det här testet:
1. Från den första NetWorker-värden (t.ex. klienten) ansluter du till den andra (t.ex. servern) med
nsradmin -s remote_host -p nsrexec - lämna sessionen öppen
2. På samma värd fastställer du processen för nsradmin (till exempel Windows,
aktivitetslistan | findstr nsradmin)
3. Kör netstat för att visa sockeln som är kopplad till den processen (t.ex. Windows,
netstat -ao | findstr process_id)
4. Bestäm anslutningssockeln från den värden (parkoppling av IP:port längst till vänster i utdata)
5. På fjärrvärden - kör netstat -a och findstr/grep för: calling_port_from_first_host (det visas nu på höger sida)
6. Värdnamnet som visas på vänster sida av kolonet är namnet på den första värden som den andra värden tolkar den inkommande anslutningen med
7. Kör igen med -n-switchen som lagts till i netstat-kommandot för att verifiera IP-adressen för samma sockel för att kontrollera om IP/rutt är förväntad
8. Återställ samma test för att säkerställa att den andra värden löser den första värden inom förväntade parametrar
Många NetWorker-åtgärder, t.ex. en spargrupp, använder flera separata TCP-socklar – i spargruppsexempel, en för en kontrollsession, en för data och en för uppdatering av indexet – om någon session använder ett inkonsekvent namn (tekniskt korrekt) kan åtgärden misslyckas.
- Round-robining används och konfigureras ibland felaktigt – men är vanligtvis oväntat och kan undvikas
- netstat -a visar öppna/aktiva TCP-socklar, som visar det OS-lösta namnet på den främmande värden. Detta kan användas för att identifiera problem
- Statisk routning kan ibland vara nödvändig när nätverkstrafiken använder ett oväntat/oöndat kort, vilket kan senare leda till problem med namnmatchning.
Se även:
KB-463606:
Felsöka problem med DNS och namnmatchning