NetWorker: Best practices voor het oplossen van problemen met naamresolutie

NetWorker is afhankelijk van naamresolutie. Als de naamomzetting niet correct en volledig consistent is, kunnen er problemen ontstaan in veel van de activiteiten van NetWorker. Aangezien NetWorker potentieel gevoelige data beheert, moet het de identiteit van de hosts waarmee het communiceert op verschillende manieren waarborgen.

Een willekeurig aantal symptomen in NetWorker kan het gevolg zijn van onvolkomenheden in de naamresolutie in NetWorker:

• Foutberichten die wijzen op problemen met het voorwaarts of omgekeerd opzoeken van namen.
• Kan clients niet testen tijdens back-up
• Onmogelijkheid voor clients om handmatig op de server op te slaan of te herstellen.
• Problemen bij het klonen of toegang tot Storage Node apparaten
• Problemen met browsen of mediadatabaserecords.
• Server of storageknooppunt reageert niet meer bij het opstarten of tijdens normale werking.
• Verkeerd benoemde of geneste indexdirectory's
• Verkeerd geconfigureerde clientfouten

Workflow voor naamresolutie

Pogingen om een hostnaam op te lossen die wordt gebruikt door een opdracht of interne configuratie, moeten worden omgezet in een IP-adres om te kunnen worden gebruikt. De volgende bronnen worden gecontroleerd, in de volgende volgorde, om te zien of de naam:IP al in de cache is opgeslagen, en stoppen wanneer de naam overeenkomt met elkaar. 

1. NetWorker name cache: De meeste grote NetWorker-daemons; Configureerbare levensduur in NSRLA database
2. Cache van lokale hostresolver: Verschilt per besturingssysteem en stelt de belasting van hosts of DNS-lookups uit
3. Bestandsvermeldingen van lokale hosts: Snel lokaal opzoeken, maar handmatig onderhouden; handig om DNS-resolutie te overschrijven
4. DNS-server lookups: Industrie heeft de voorkeur vanwege gecentraliseerd beheer, maar trager

1. NetWorker Caching:

NetWorker-daemons onderhouden interne naamcaches. Clients cachen opgeslagen namen in nsrexecd, terwijl core daemons zoals nsrd en nsmmdbd hun eigen caches behouden. Dit is de eerste IP-tabel die wordt gecontroleerd en de snelste. De interne cachelevensduur kan worden ingesteld in de nsrla-database van elke NetWorker-host met behulp van 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

Retourneert standaard 30 minuten (1800 seconden):

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

Deze waarde bepaalt hoe lang het duurt voordat NetWorker opzettelijk de procescache opschoont ten gunste van bijgewerkte informatie uit de volgende lagen opeenvolgend. Als zodanig is het verhogen ervan geschikt voor omgevingen waar DNS-lookup traag is, maar DNS-adressering relatief statisch is. Omgekeerd kunnen lagere waarden wenselijk zijn voor omgevingen met vaak veranderende adressen. 

Als een vereiste naam aanwezig is in de interne cache van NetWorker, wordt deze gebruikt en wordt verdere query's gestopt. Voor het oplossen van problemen, als naam-naar-IP-toewijzingen in de cache onjuist lijken, gebruikt u opdrachten om de huidige cache te loggen en vervolgens vermeldingen leeg te maken of opnieuw op te lossen:

• • dbgcommand -n nsrd PrintDnsCache=1 (Dumpen naar daemon.raw)
  • dbgcommand -n nsrd FlushDnsCache=1 (Flush), of, 
  • dbgcommand -n nsrd FlushDnsCache=9 (Cache leegmaken en onmiddellijk opnieuw oplossen/opnieuw opbouwen)

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

2. Resolver Cache:

• • Het leegmaken van de resolvercache is afhankelijk van het besturingssysteem/de distributie - zie de documentatie van de leverancier.
  • Windows: ipconfig /flushdns

3. Hostbestanden:

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

4. Voorwaartse oplossing:

• Voer nslookup zonder argumenten om de interactieve prompt in te voeren.
• Voer de naamiteratie in die u wilt opzoeken en druk op enter om het doorstuurrecord op te halen van de DNS-server waarmee u verbinding hebt gemaakt.
• Voer dezelfde naam nog twee keer in om te zien of de naamrecord stil wordt round-robining tussen verschillende hosts of dezelfde gegevens retourneert.
• Herhaal hetzelfde proces voor elke instantie van elke naam die de host kan worden aangeroepen door andere hosts of zichzelf kan beschouwen als voor hetzelfde IP-adres.
• Herhaal hetzelfde proces voor elke andere DNS-server waarvoor de host is geconfigureerd door server next_dns_server in te voeren.

5. Omgekeerde resolutie:

• Voer nslookup zonder argumenten om de interactieve prompt in te voeren.
• Betreed de set q=ptr om het querytype te wijzigen in de Omgekeerde zone.
• Voer het IP-adres in dat u wilt terugdraaien en druk op Enter.
• Zorg ervoor dat de naam die wordt geretourneerd in de omgekeerde record overeenkomt met de naam/het IP-adres van de voorwaartse record.

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

Naamomzetting testen

Alle NetWorker-hosts moeten een consistente voorwaartse en omgekeerde naamresolutie hebben voor elke host waarmee ze communiceren, op basis van hun rol in de datazone. Het is van cruciaal belang dat NetWorker-beheerders ervoor zorgen dat eventuele problemen met de hostoplossing onmiddellijk en volledig worden aangepakt.
Bij het oplossen van problemen met naamomzetting of om ze uit te sluiten in uw NetWorker Data zone:
    1. Zoek alle hosts die betrokken zijn bij de mislukte bewerking: server, clients en mogelijk storageknooppunten, enzovoort.
    2. Bepaal voor elk de IP-adressen die lokaal zijn geconfigureerd en alle verwachte oplosbare namen voor die IP's.
    3. Configureer alle hosts voor het gebruik van het hostbestand vóór DNS voor hostresolutie.
    4. Configureer aan het begin van het hostbestand van een host een enkele vermelding voor elk IP-adres, waarbij elke naam op dezelfde regel correspondeert.
    5. Kopieer die regels precies van de eerste host naar de hostbestanden van de andere betrokken hosts.
    6. Bewerk de NetWorker-clientobjecten zodat aliassen correct overeenkomen met de gewenste IP-adressen.
    7. Sluit NetWorker af op alle betrokken hosts.
    8. Wis de resolvercache op elke host met behulp van het juiste besturingssysteemmechanisme.
    9. Start NetWorker opnieuw en probeer de problematische bewerking opnieuw uit te voeren.

Gebruik deze test om te bewijzen dat de naam door een bepaalde host is opgelost:
    1. Maak vanaf de eerste NetWorker-host (bijvoorbeeld de client) verbinding met de tweede (bijvoorbeeld de server) via nsradmin -s remote_host -p nsrexec - Laat de sessie open.
    2. Bepaal op dezelfde host het proces voor nsradmin (bijvoorbeeld Windows, tasklist | findstr nsradmin)
3. Voer netstat uit om de socket weer te geven die aan dat proces is gekoppeld (bijvoorbeeld Windows, netstat -ao | findstr process_id)
4. Bepaal de verbindingssocket van die host (de meest linkse IP:poort-koppeling in de uitgang)
5. Op de externe host - uitvoeren netstat -a als findstr/grep voor :calling_port_from_first_host.
    6. De hostnaam vóór de dubbele punt is hoe de tweede host de eerste host oplost bij het accepteren van de binnenkomende verbinding.
    7. Ren opnieuw met de -n switch toegevoegd aan de netstat-opdracht om het IP-adres van dezelfde socket te verifiëren, om te controleren of het IP/de route wordt verwacht.
    8. Voer dezelfde test in omgekeerde volgorde uit om er zeker van te zijn dat de tweede host de eerste host binnen de verwachte parameters oplost.

Over NetWorker Clientaliassen

NetWorker heeft ook een configureerbaar veld dat algemeen is voor alle clientinstanties, genaamd 'Aliassen', dat alle namen moet weergeven die voor die client kunnen worden opgelost. Hierdoor kan NetWorker meerdere opgeloste namen koppelen aan één clientexemplaar. client1.domein.prod kan bijvoorbeeld ook worden weergegeven als client1.domein.bkup of client1, afhankelijk van het gebruikte IP-adres.

NetWorker-bewerkingen zoals savegroup gebruiken meerdere TCP-sockets: één voor controle-, data- en indexupdates. Als een socket een inconsistente (maar geldige) naam gebruikt, kan de bewerking mislukken.

• Round-robining wordt soms opzettelijk gebruikt en geconfigureerd - maar meestal is het onverwacht en moet het worden vermeden
• netstat -a onthult open/actieve TCP-sockets, die de OS-opgeloste naam van de externe host onthullen - dit kan worden gebruikt om problemen te identificeren
• Statische routering kan soms nodig zijn wanneer netwerkverkeer een onverwachte/ongewenste adapter gebruikt, wat later kan leiden tot problemen met naamresolutie.

Zie ook:  NetWorker-processen en -poorten