NetWorker : Configuration et dépannage de la mise en cache des noms NetWorker
Summary: Cet article fait partie d’une série qui traite du dépannage des communications dans NetWorker. Cet article fournit des détails sur le cache de résolution de noms de processus interne de NetWorker et sur son intégration dans le workflow. ...
Instructions
Tous les hôtes NetWorker conservent ce cache de noms interne pour tous les processus majeurs, c’est-à-dire tous les types d’hôtes, y compris les clients, les noms résolus dans nsrexecd, ainsi que les commandes nsrd, nsmmdbdet nsrjobd du serveur.
Quand prendre en compte le cache de noms ?
- Lorsque la résolution de noms semble incorrecte ou incomplète en ce qui concerne les associations IP :name
- Où le cache de résolution de noms est trop long pour que les fichiers binaires se remplissent
Entrées incorrectes ou manquantes : Cache de nom de rapport
Les commandes suivantes vident le cache actuel de n’importe quel processus dans le log du processus, le vidage ou le vidage / le résolvez immédiatement, respectivement, comme vous le souhaitez :
dbgcommand -n nsrexecd PrintDnsCache=1
dbgcommand -n nsrexecd FlushDnsCache=1
dbgcommand -n nsrexecd FlushDnsCache=9
Cela amène le processus en question à signaler des messages pour chaque hôte du cache, au format suivant :
<nsr_daemon> NSR notice hostname: <hostname>, address: <ip_address>, ai_flags: 0x0002, family: inet, protocol: tcp
<nsr_daemon> NSR notice DNS_II: hostname: <ip_address>, status: STATUS_OK, head: <hostname>, TTL: 0 secs
<nsr_daemon> NSR notice CLIENT_CACHE: hostname: <hostname_variation>, status: STATUS_OK, head: <hostname>, TTL: 0 secs
Longues durées de population : Extension de la durée de vie du cache
Un DNS problématique peut entraîner des retards extrêmes lorsque les fichiers binaires tentent de mettre en cache tous les hôtes requis pour éviter d’avoir à les repeupler périodiquement à la demande. Recherchez des messages similaires au daemon.raw sur l’hôte concerné :
<nsr_binary> NSR notice Populating of DNS cache took <number> secs
Linux/UNIX : /nsr/logs/daemon.raw
Windows : C :\Program Files\EMC NetWorker\nsr\logs\daemon.raw
NetWorker : utilisation de nsr_render_log
Si ces actions prennent 60 secondes ou plus, il peut être avantageux d’augmenter la durée de vie du cache. Soyez prudent si les adresses IP sont susceptibles de changer fréquemment dans cet environnement ; Toutefois, même avec DHCP, des baux peuvent être attribués pour s’assurer que les hôtes reçoivent les mêmes adresses IP d’une autorité centrale.
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
Windows
(echo . type: nsrla & echo show positive DNS cache TTL; negative DNS cache TTL & echo print) | nsradmin -p nsrexec
Par défaut, cette valeur est définie sur 30 minutes (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. Par conséquent, il est approprié de l’augmenter pour les environnements où la recherche DNS est lente, mais où l’adressage DNS est relativement statique (baux DHCP ou adressage statique). À l’inverse, des valeurs inférieures peuvent être souhaitables pour les environnements dont les adresses changent fréquemment.
Pour les environnements statiques où DNS peut être un frein aux performances, envisagez une valeur de 86 400 (1 jour) pour éviter les recherches inutiles toutes les demi-heures. Un redémarrage est nécessaire pour que cette modification prenne effet.
Linux / UNIX
printf ". type: nsrla\nupd positive DNS cache TTL: 86400\nupd negative DNS cache TTL: 86400\n" | nsradmin -p nsrexec
Windows
(echo . type: nsrla & echo upd positive DNS cache TTL: 86400 & echo upd negative DNS cache TTL: 86400) | nsradmin -p nsrexec