NetWorker: Konfigurowanie i rozwiązywanie problemów z buforowaniem nazw NetWorker

Najbardziej efektywnym sposobem, w jaki NetWorker może przekształcić nazwę w adres IP, jest zachowanie buforowanej mapy IP:name w pamięci dla głównych procesów. To sprawia, że wewnętrzna pamięć podręczna procesów jest pierwszym portem wywołania dla wyszukiwań nazwa:IP i pozwala uniknąć droższych metod wyszukiwania.

Wszystkie hosty NetWorker utrzymują wewnętrzną pamięć podręczną nazw dla wszystkich głównych demonów — każdy typ hosta, w tym klienci, pamięć podręczna pomyślnie rozpoznała nazwy w nsrexecd, a nsrd, nsmmdbdi nsrjobd serwera również. 

Kiedy należy wziąć pod uwagę pamięć podręczną nazw

• Gdy rozpoznawanie nazw wydaje się być niepoprawne lub niekompletne w odniesieniu do skojarzeń IP:name
• W przypadku gdy pamięć podręczna rozpoznawania nazw trwa zbyt długo, zbyt długo do wypełnienia plików binarnych

Nieprawidłowe lub brakujące wpisy: Pamięć podręczna nazw raportowania

Następujące polecenia zrzucają bieżącą pamięć podręczną dla dowolnego procesu do dziennika demona, opróżniają lub opróżniają/natychmiast ponownie je rozwiązują, zgodnie z potrzebami:

dbgcommand -n nsrexecd PrintDnsCache=1
dbgcommand -n nsrexecd FlushDnsCache=1
dbgcommand -n nsrexecd FlushDnsCache=9

Powoduje to, że dany demon zgłasza komunikaty dla każdego hosta w pamięci podręcznej w formacie:

<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

Długi czas zaludnienia: Wydłużenie żywotności pamięci podręcznej

Problematyczny serwer DNS może powodować ekstremalne opóźnienia, gdy pliki binarne próbują buforować wszystkie wymagane hosty, aby uniknąć konieczności okresowego ponownego wypełniania na żądanie. Sprawdź daemon.raw na hoście, którego dotyczy problem, pod kątem komunikatów podobnych do:

<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: korzystanie z nsr_render_log
 

Jeśli te czynności trwają 60 sekund lub dłużej, korzystne może być wydłużenie okresu istnienia pamięci podręcznej. Zachowaj ostrożność, jeśli adresy IP mogą się często zmieniać w tym środowisku; jednak nawet w przypadku DHCP dzierżawy mogą być przypisywane, aby zapewnić, że hosty otrzymują te same adresy IP od organu centralnego.

Okres istnienia wewnętrznej pamięci podręcznej można ustawić w bazie danych nsrla każdego hosta NetWorker za pomocą polecenia 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

Domyślnie jest to 30 minut (1800 sekund):

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

Ta wartość określa, ile czasu upłynie, zanim NetWorker celowo usunie pamięć podręczną procesu na rzecz zaktualizowanych informacji z kolejnych warstw sekwencyjnie. W związku z tym podniesienie go jest odpowiednie dla środowisk, w których wyszukiwanie DNS jest powolne, ale adresowanie DNS jest względnie statyczne (dzierżawy DHCP lub adresowanie statyczne). I odwrotnie, niższe wartości mogą być pożądane w środowiskach z często zmieniającymi się adresami.

W przypadku środowisk statycznych, w których system DNS może powodować spadek wydajności, należy wziąć pod uwagę wartość 86400 (1 dzień), aby zapobiec niepotrzebnym wyszukiwaniom co pół godziny. Aby ta zmiana została wprowadzona, należy ponownie uruchomić komputer.

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