NVP vProxy: rozwiązywanie problemów z łącznością sieciową dla operacji tworzenia kopii zapasowych i przywracania
Podsumowanie: Ten artykuł zawiera ogólne omówienie rozwiązywania problemów z łącznością sieciową między systemami, które biorą udział w operacjach tworzenia kopii zapasowych i przywracania maszyn wirtualnych (VM) chronionych przez urządzenie vProxy NetWorker VMware Protection (NVP). ...
Instrukcje

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
| Przy użyciu polecenia | Do (target_system) | Port | Zastosowanie | Wymagane uzgadnianie TLS? |
| Serwer NetWorker | Urządzenie vProxy | 9090 | Wywołania usług internetowych NetWorker VMware Protection w celu inicjowania i monitorowania kopii zapasowych, odzyskiwania obrazów i odzyskiwania granularnego. | Tak |
| Serwer NetWorker | Serwer vCenter Server | 443 | Widok VMware w konsoli NetWorker Management Console | Tak |
| Serwer NetWorker | Serwer ESXi | 443 | Przywracanie awaryjne, ponowne wdrożenie vProxy | Tak |
| Serwer vCenter Server | Serwer NetWorker | 9090 | Wtyczka Dell NetWorker klienta vSphere. | Tak |
| Interfejs klienta przywracania oprogramowania Dell Data Protection | Serwer NetWorker | 9090 | Odzyskiwanie na poziomie plików w kliencie Dell Data Protection Restore.
Uwaga: Dotyczy to również sieciowego interfejsu użytkownika NetWorker (NWUI).
|
Tak |
| Serwery ESXi | Domena danych | 111, 2049, 2052 | Odzyskiwanie na poziomie plików i natychmiastowe odzyskiwanie. | Nie |
| Maszyny wirtualne | Domena danych | 111, 2049 | Kopie zapasowe zgodne z aplikacjami SQL | Nie |
| Urządzenie vProxy | Serwer NetWorker | 9090 | Rejestracja vProxy i komunikacja statusu. | Tak |
| Urządzenie vProxy | System nazw domen (DNS) | 53 | Rozpoznawanie nazw. | Nie |
| Urządzenie vProxy | Domena danych | 22, 111, 131, 161, 2049, 2052, 3009 | Zarządzanie Data Domain
Uwaga: Port 3009 jest wymagany przez serwer vProxy z systemem DDOS 7.0 lub nowszym do przywracania FLR i funkcji Instant Access.
|
Tylko port 3009 |
| Urządzenie vProxy | Serwer ESXi | 443, 902 | Operacje tworzenia kopii zapasowych i odzyskiwania danych | Tylko port 443 |
| Urządzenie vProxy | Serwer vCenter Server | 443 | Operacje rejestracji, tworzenia kopii zapasowych i odzyskiwania vProxy.
Uwaga: Używanie innego niż domyślny portu vCenter dla protokołu HTTPS nie jest obsługiwane.
|
Tak |
| Urządzenie vProxy | Docelowa maszyna wirtualna | 9613 | vProxy FLR — komunikacja z agentem FLR na docelowej maszynie wirtualnej. | Nie |
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
Pakiet 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
Ruch TLS
Jeśli połączenie TCP między dwoma systemami powiedzie się, ale komunikacja nadal się nie powiedzie, a te systemy wymagają protokołu TLS, należy sprawdzić, czy uzgadnianie protokołu TLS zakończyło się pomyślnie.
Błędy, które zwykle wskazują na awarię połączenia TLS:
TLS alert, handshake failureSSL handshake failedSSL_ERROR_SYSCALL-
Connection reset by peer -
An error occurred, a low-level API call failure -
curl_easy_perform() returned error 35 -
SSL: certificate verification failed (result: XX) -
libCURL: error 35: SSL connect error -
Peer failed to perform TLS handshake
Polecenie hosta systemu Linux:
curl -kv https://HOSTNAME:PORT
Polecenie hosta systemu Windows:
curl.exe -kv https://HOSTNAME:PORT
curl Polecenie wyświetla również informacje o certyfikacie. Oczekuje się, że certyfikaty z podpisem własnym będą zgłaszać "unable to get local issuer certificate" lub inne komunikaty o weryfikacji certyfikatu. Należy sprawdzić, czy daty rozpoczęcia i zakończenia oraz nazwy/adresów hosta użyte w certyfikacie są poprawne. Wszelkie niepowodzenia uzgadniania TLS muszą zostać zbadane przez administratorów sieci lub zabezpieczeń.
Dodatkowe informacje
Wykonaj polecenie ping z oznaczeniem czasowym między systemami, których to dotyczy. Na przykład:
- 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.
2. Przełącz się na użytkownika głównego:
sudo su -
nohup ping ADDRESS | while read l; do echo "$(date) $l"; done >> /nsr/logs/$(hostname)_ping.log &
5. Zatrzymaj ping:
ps -ef | grep pingB. Zatrzymaj proces pingowania.
kill -9 PID_OF_PINGPrzykład:
[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<&12. Otwórz wiersz polecenia administratora w katalogu, w którym zapisano skrypt.
timestamped_ping.bat4. Pozostaw uruchomiony skrypt i odtwórz problem z kopią zapasową lub przywracaniem.
5. Po odtworzeniu problemu. Zatrzymaj skrypt, używając kombinacji klawiszy 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.