NetWorker : Pratiques d’excellence en matière de résolution de noms

NetWorker dépend de la résolution des noms. Si la résolution des noms n’est pas correcte et entièrement cohérente, des problèmes peuvent survenir dans de nombreuses opérations de NetWorker. Étant donné que NetWorker gère les données potentiellement sensibles, il doit garantir les identités des hôtes avec lesquels il interagit de différentes manières.

Un certain nombre de symptômes dans NetWorker peuvent être le résultat des problèmes de résolution de noms dans NetWorker :

• Messages d’erreur indiquant des problèmes de recherche de noms directe et inversée.
• Impossibilité de sonder les clients pendant la sauvegarde
• Impossibilité pour les clients d’enregistrer manuellement sur le serveur ou de restaurer.
• Problèmes lors du clonage ou de l’accès aux périphériques du nœud de stockage
• Problèmes de navigation ou d’enregistrement dans la base de données des médias.
• Le serveur ou le nœud de stockage cesse de répondre au démarrage ou en cours de fonctionnement normal.
• Répertoires d’index mal nommés ou imbriqués
• Erreurs de client mal configurées

Workflow de résolution de noms

Les tentatives de résolution d’un nom d’hôte utilisé par la commande ou la configuration interne doivent être résolues sur une adresse IP pour pouvoir être utilisées. Les ressources suivantes sont vérifiées, dans l’ordre suivant, pour voir si name  :IP a déjà été mis en cache, et s’arrêtent lorsque le nom est mis en correspondance. 

1. Cache de noms NetWorker : La plupart des principaux processus NetWorker ; Durée de vie configurable dans la base de données NSRLA 
2. Cache du résolveur d’hôte local : Varie selon le système d’exploitation et diffère la charge des hôtes ou des recherches DNS
3. Entrées du fichier des hôtes locaux : Recherche locale rapide, mais maintenue manuellement ; utile pour remplacer la résolution DNS
4. Recherches de serveurs DNS : Préférence du secteur en raison de l’administration centralisée, mais plus lente

1. Mise en cache NetWorker:

Les processus NetWorker conservent des caches de noms internes. Les clients mettent en cache les noms résolus dans nsrexecd, tandis que les processus principaux tels que nsrd et nsmmdbd conservent leurs propres caches. Il s’agit de la première table IP vérifiée, et la plus rapide. La durée de vie du cache interne peut être définie dans la base de données nsrla de chaque hôte NetWorker à l’aide de 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

Doit renvoyer 30 minutes par défaut (1800 secondes) :

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

Cette valeur contrôle le temps nécessaire avant que NetWorker ne vide délibérément le cache de processus en faveur des informations mises à jour des couches suivantes, de manière séquentielle. En tant que tel, l’augmenter est approprié pour les environnements où la recherche DNS est lente, mais l’adressage DNS est relativement statique. À l’inverse, des valeurs inférieures peuvent être souhaitables pour les environnements dont les adresses changent fréquemment. 

Si un nom obligatoire est présent dans le cache interne de NetWorker, il est utilisé et la requête suivante s’arrête. Pour le dépannage, si les mappages nom-IP mis en cache semblent incorrects, utilisez les commandes pour consigner le cache actuel, puis vider ou résoudre à nouveau les entrées :

• • dbgcommand -n nsrd PrintDnsCache=1 (Vidage vers daemon.raw)
  • dbgcommand -n nsrd FlushDnsCache=1 (affleurant), ou, 
  • dbgcommand -n nsrd FlushDnsCache=9 (Vider et résoudre/reconstruire immédiatement le cache)

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

2. Cache du résolveur :

• • Le vidage du cache du résolveur varie en fonction du système d’exploitation ou de la distribution. Reportez-vous à la documentation du fournisseur.
  • Windows. : ipconfig /flushdns

3. Fichiers d’hôtes :

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

4. Résolution directe :

• Exécutez nslookup sans argument pour accéder à l’invite interactive.
• Saisissez l’itération de nom à rechercher, puis appuyez sur Entrée pour récupérer l’enregistrement direct à partir du serveur DNS auquel vous êtes connecté.
• Saisissez le même nom deux fois de plus pour voir si l’enregistrement de nom est en permutation circulaire en mode silencieux entre différents hôtes ou renvoie les mêmes données.
• Répétez le même processus pour toute instance de n’importe quel nom pouvant être donné à l’hôte par d’autres hôtes ou qu’il considère lui-même pour la même adresse IP.
• Répétez le même processus pour n’importe quel autre serveur DNS que l’hôte est configuré pour utiliser potentiellement en saisissant server next_dns_server.

5. Résolution inversée :

• Exécutez nslookup sans argument pour accéder à l’invite interactive.
• Entrer dans l’ensemble q=ptr pour modifier le type de requête en Reverse Zone.
• Saisissez l’adresse IP pour la résolution inversée, puis appuyez sur Entrée.
• Assurez-vous que le nom renvoyé dans l’enregistrement inversé correspond au nom/à l’adresse IP de l’enregistrement direct.

[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 de la résolution de noms

Tous les hôtes NetWorker doivent disposer d’une résolution de noms directe et inversée cohérente pour tous les hôtes avec lesquels ils communiquent, en fonction de leur rôle de zone de données. Les administrateurs NetWorker doivent impérativement s’assurer que tous les problèmes de résolution des hôtes sont résolus immédiatement et complètement.
Lors du dépannage des problèmes de résolution de noms ou pour les exclure de votre zone de données NetWorker :
    1. Recherchez tous les hôtes impliqués dans l’opération défaillante : serveur, clients et éventuellement nœuds de stockage, etc.
    2. Pour chacun d’eux, déterminez les adresses IP configurées localement et tous les noms pouvant être résolus pour ces adresses IP.
    3. Configurez tous les hôtes pour qu’ils utilisent le fichier d’hôtes avant DNS dans la résolution des hôtes.
    4. Au début du fichier d’hôtes d’un hôte, configurez une entrée unique pour chaque adresse IP, avec chaque nom correspondant sur la même ligne.
    5. Copiez ces lignes de manière exacte à partir du premier hôte vers les fichiers hôtes des autres hôtes concernés.
    6. Modifiez les objets du client NetWorker pour qu’ils aient des alias correspondant correctement aux adresses IP souhaitées.
    7. Arrêtez NetWorker sur tous les hôtes concernés.
    8. Videz le cache du programme de résolution sur chaque hôte à l’aide du mécanisme approprié du système d’exploitation.
    9. Redémarrez NetWorker et relancez l’opération problématique.

Pour prouver que le nom est résolu par un hôte donné, utilisez ce test :
    1. À partir du premier hôte NetWorker (par exemple, le Client), connectez-vous au second (par exemple, le Serveur) : nsradmin -s remote_host -p nsrexec - Laissez la session ouverte.
    2. Sur le même hôte, déterminez le processus pour nsradmin (par exemple, Windows, tasklist | findstr nsradmin)
3. Exécutez netstat pour afficher la socket associée à ce processus (par exemple, Windows, netstat -ao | findstr process_id)
4. Déterminez le socket de connexion de cet hôte (l’appariement IP:port le plus à gauche dans la sortie)
    5. Sur l’hôte distant : exécutez netstat -a et findstr/grep pour :calling_port_from_first_host.
    6. Le nom d’hôte avant les deux-points est la façon dont le second hôte résout le premier hôte lors de l’acceptation de la connexion entrante.
    7. Exécutez à nouveau avec la commande -n switch ajouté à la commande netstat pour vérifier l’IP du même socket, pour vérifier si l’IP/route est attendue.
    8. Inversez le même test pour vous assurer que le second hôte résout le premier hôte dans les paramètres attendus.

À propos des alias de client NetWorker

NetWorker dispose également d’un champ configurable, global pour toutes les instances du client, appelé « Aliases », qui doit refléter tous les noms pouvant être résolus pour ce client. Cela permet à NetWorker de lier plusieurs noms résolus à une instance client. Par exemple, client1.domain.prod peut également s’afficher sous la forme client1.domain.bkup ou client1, en fonction de l’adresse IP utilisée.

Les opérations NetWorker telles que le groupe de sauvegarde utilisent plusieurs sockets TCP : un pour les mises à jour de contrôle, un socket de données et un socket d’index. Si un socket utilise un nom incohérent (mais valide), l’opération peut échouer.

• La permutation circulaire est parfois délibérément utilisée et configurée, mais elle est généralement inattendue et doit être évitée
• netstat -a révèle les sockets TCP ouverts/actifs, qui révèlent le nom résolu par le système d’exploitation de l’hôte étranger - cela peut être utilisé pour identifier les problèmes
• Le routage statique peut parfois être nécessaire lorsque le trafic réseau utilise un adaptateur inattendu/indésirable, ce qui peut entraîner ultérieurement des problèmes de résolution de noms.

Voir également :  Processus et ports NetWorker