NVP vProxy: rozwiązywanie problemów z łącznością sieciową dla operacji tworzenia kopii zapasowych i przywracania

Systemy i porty biorące udział w operacjach tworzenia kopii zapasowych i przywracania maszyny wirtualnej VMware (VM).

Zgodnie z Podręcznikiem konfiguracji zabezpieczeń NetWorker, NetWorker używa bezpośredniego połączenia przez gniazdo do komunikacji i przenoszenia danych przez sieć do wymaganej usługi przy minimalnym obciążeniu. Podczas gdy NetWorker otwiera niektóre porty dla TCP i UDP, NetWorker wymaga tylko portów TCP. Porty UDP są opcjonalne, z wyjątkiem protokołu SNMP, który używa portów UDP 161 i 162.

Tabela portów i topologia sieci wyświetlane w tej bazie wiedzy zostały pobrane bezpośrednio z Podręcznika integracji NetWorker VMware. Podręczniki integracji i konfiguracji zabezpieczeńVMware można znaleźć na stronie produktu Dell Support NetWorker.

Wymagania dotyczące portów

System nazw domen (DNS)

Upewnij się, że system DNS został poprawnie rozpoznany dla systemów, których to dotyczy, w tym w pełni kwalifikowanej nazwy domeny (FQDN), nazwy skróconej i adresu IP (wyszukiwanie wsteczne).

nslookup FQDN
nslookup SHORT_NAME
nslookup IP_ADDRESS

Zobacz artykuł: NetWorker: Nazwa Rozwiązywanie problemów z rozwiązywaniem problemów Najlepsze praktyki

Zaleca się również sprawdzanie plików hostów systemowych. Wpisy w pliku hosta mogą powodować konflikt lub zastępować zapytanie DNS albo prowadzić do nieprawidłowego adresu IP lub nazwy hosta.

• Systemy Linux: /etc/hosts
• Systemy Windows: C:\Windows\System32\drivers\etc\hosts

Serwer NetWorker

Interfejs NetWorker nsrports Można użyć polecenia do potwierdzenia rozwiązywania nazw i połączeń portów między systemami. Zapoznaj się z powyższą tabelą, aby określić, które porty i system docelowy należy określić podczas testowania komunikacji.

nsrports -t target_system -p port

Systemy Linux mogą korzystać z curl Polecenie do testowania łączności:

curl -v target_system:port

Systemy Windows mogą korzystać z Test-NetConnection Polecenie cmdlet programu PowerShell:

Test-NetConnection -ComputerName target_system  -port port

Urządzenie vProxy

Narzędzie ProxyHC (Health Check) można uruchomić na vProxy w celu sprawdzenia łączności portów między systemami, patrz artykuł: NVP-vProxy: Jak używać narzędzia do sprawdzania kondycji ProxyHC na urządzeniu vProxy.

Urządzenie vProxy może również korzystać z curl polecenie do testowania łączności. Zapoznaj się z powyższą tabelą, aby określić, które porty i system docelowy należy określić podczas testowania komunikacji.

curl -v target_system:port

Serwer ESXi

Polecenie netcat Polecenia (nc) można użyć na hostach ESXi w celu sprawdzenia łączności portu. Zapoznaj się z powyższą tabelą, aby określić, które porty i system docelowy należy określić podczas testowania komunikacji.

nc -zv target_system port

Zapoznaj się z artykułem NVP vProxy: NetWorker VIB otworzy porty NFS dla FLR vProxy.

Serwer vCenter Server

Serwery vCenter korzystają z poleceń połączenia opartych na systemie operacyjnym. Zapoznaj się z powyższą tabelą, aby określić, które porty i system docelowy należy określić podczas testowania komunikacji.

curl -v target_system:port

Maszyny wirtualne

Niezależnie od tego, czy testowana jest komunikacja z maszyny wirtualnej dla klienta Data Protection Restore, sieciowego interfejsu użytkownika NetWorker (NWUI), czy łączność z Data Domain, używane polecenie zależy od systemu operacyjnego maszyny wirtualnej. Systemy Linux mogą korzystać z curl Polecenie do testowania łączności:

curl -v target_system:port

Systemy Windows mogą korzystać z Test-NetConnection Polecenie cmdlet programu PowerShell:

Test-NetConnection -ComputerName target_system  -port port

• Serwer NetWorker —> urządzenie vProxy
• Serwer NetWorker/węzeł pamięci masowej —> Data Domain
• Urządzenie vProxy —> Data Domain
• Urządzenie vProxy —> serwer vCenter

Hosty Linux

Poniższe czynności można wykonać na serwerach Linux NetWorker, węzłach pamięci masowej, urządzeniu vProxy lub urządzeniu vCenter Server.

sudo su -

nohup ping ADDRESS | while read l; do echo "$(date) $l"; done >> /nsr/logs/$(hostname)_ping.log &

ps -ef | grep ping

kill -9 PID_OF_PING

[root@nsr ~]# ps -ef | grep ping
gdm         4066    1993  0 Nov15 tty1     00:00:18 /usr/libexec/gsd-housekeeping
root      215151  215146  0 Nov18 ?        00:16:25 /opt/nsr/rabbitmq-server-3.11.16/erts-13.2.2/bin/beam.smp -W w -MBas ageffcbf -MHas ageffcbf -MBlmbcs 512 -MHlmbcs 512 -MMmcs 30 -P 1048576 -t 5000000 -stbt db -zdbbl 128000 -sbwt none -sbwtdcpu none -sbwtdio none -B i -- -root /opt/nsr/rabbitmq-server-3.11.16 -bindir /opt/nsr/rabbitmq-server-3.11.16/erts-13.2.2/bin -progname erl -- -home /nsr/rabbitmq -- -pa  -noshell -noinput -s rabbit boot -boot start_sasl -syslog logger [] -syslog syslog_error_logger false -kernel prevent_overlapping_partitions false
root      467940  467115  0 16:10 pts/3    00:00:00 ping nsr-vproxy02.amer.lan
root      468141  467115  0 16:11 pts/3    00:00:00 grep --color=auto ping
[root@nsr ~]# kill -9 467940

Host Windows

Poniższe kroki można wykonać na serwerach Windows NetWorker i/lub w zdalnym węźle pamięci masowej.

1. Utwórz skrypt .bat (timestamped_ping.bat) zawierający następujące elementy. Zastąp ciąg ADDRESS adresem IP lub rozpoznawalną nazwą FQDN DNS zdalnego hosta. Zmień lokalizację wyjściową na inną, jeśli NetWorker nie jest zainstalowany w domyślnej ścieżce instalacji lub jeśli chcesz skierować dane wyjściowe w inne miejsce.

@echo off
ping -t ADDRESS |find /v ""|cmd /q /v:on /c "for /l %%a in (0) do (set "data="&set /p "data="&if defined data echo(!date! !time! !data!)" >> "C:\Program Files\EMC NetWorker\nsr\logs\ping.out" 2<&1

2. Otwórz wiersz polecenia administratora w katalogu, w którym zapisano skrypt.

3. Uruchom skrypt:

timestamped_ping.bat

4. Pozostaw uruchomiony skrypt i odtwórz problem z kopią zapasową lub przywracaniem. 
5. Po odtworzeniu problemu. Zatrzymaj skrypt, używając kombinacji CTRL+C w wierszu polecenia, w którym skrypt jest uruchamiany.
6. Sprawdź plik C:\Program Files\EMC NetWorker\nsr\logs\ping.out (lub lokalizację określoną) pod kątem problemów z siecią (porzucone pakiety, duże opóźnienia itp.), które pokrywają się z sygnaturą czasową od momentu zaobserwowania problemu z kopią zapasową lub przywracaniem danych.  

UWAGA: Podręcznik planowania optymalizacji wydajności NetWorker podaje, że opóźnienie między serwerem/węzłem pamięci masowej NetWorker a systemem Data Domain nie powinno przekraczać 50 ms. Może to spowodować niską przepustowość. Większe opóźnienie może spowodować nieoczekiwane zamknięcie sesji.