NVP-vProxy: Troubleshooting der Netzwerkverbindung bei Backup- und Wiederherstellungsvorgängen

Systeme und Ports, die an Backup- und Wiederherstellungsvorgängen einer VMware Virtual Machine (VM) beteiligt sind.

Gemäß dem NetWorker-Sicherheitskonfigurationsleitfaden verwendet NetWorker eine direkte Socket-Verbindung für die Kommunikation und Verschiebung von Daten über das Netzwerk zum erforderlichen Service mit minimalem Overhead. Obwohl NetWorker einige Ports für TCP und UDP öffnet, benötigt NetWorker nur TCP-Ports. UDP-Ports sind optional, mit Ausnahme von SNMP, das UDP-Port 161 und 162 verwendet.

Die Porttabelle und Netzwerktopologie, die in diesem Wissensdatenbank-Artikel angezeigt werden, wurde direkt aus dem NetWorker VMware Integration Guide abgerufen. Die Konfigurationshandbücher für VMware-Integration und -Sicherheit finden Sie auf der Produktseite für Dell Support NetWorker.

Portanforderungen

Domain Name System (DNS)

Stellen Sie sicher, dass DNS für die beteiligten Systeme korrekt aufgelöst wird, einschließlich des vollständig qualifizierten Domänennamens (FQDN), des Kurznamens und der IP-Adresse (Reverse-Lookup).

nslookup FQDN
nslookup SHORT_NAME
nslookup IP_ADDRESS

Siehe folgender Artikel: NetWorker: Best Practices

für das Troubleshooting bei der NamensauflösungEs wird auch empfohlen, die Hostdateien des Systems zu überprüfen. Hostdateieinträge können zu Konflikten führen oder eine DNS-Abfrage überschreiben oder zu einer falschen IP-Adresse oder einem falschen Hostnamen führen.

• Linux-Systeme: /etc/hosts
• Windows-Systeme: C:\Windows\System32\drivers\etc\hosts

NetWorker-Server

The NetWorker nsrports können die Namensauflösung und die Portkonnektivität zwischen den beteiligten Systemen bestätigt werden. In der obigen Tabelle finden Sie Informationen dazu, welche Ports und welches Zielsystem beim Testen der Kommunikation angegeben werden sollten.

nsrports -t target_system -p port

Linux-Systeme können die curl Befehl zum Testen der Konnektivität:

curl -v target_system:port

Windows-Systeme können Test-NetConnection PowerShell-Cmdlet:

Test-NetConnection -ComputerName target_system  -port port

vProxy-Appliance

Das ProxyHC-Dienstprogramm (Health Check) kann auf dem vProxy ausgeführt werden, um die Portkonnektivität zwischen Systemen zu überprüfen, siehe Artikel: NVP-vProxy: So verwenden Sie das Integritätsprüfungstool ProxyHC auf der vProxy-Appliance.

Die vProxy-Appliance kann auch die curl Befehl zum Testen der Konnektivität. In der obigen Tabelle finden Sie Informationen dazu, welche Ports und welches Zielsystem beim Testen der Kommunikation angegeben werden sollten.

curl -v target_system:port

ESXi-Server

Die Spalte netcat (nc) kann auf ESXi-Hosts verwendet werden, um die Portkonnektivität zu überprüfen. In der obigen Tabelle finden Sie Informationen dazu, welche Ports und welches Zielsystem beim Testen der Kommunikation angegeben werden sollten.

nc -zv target_system port

Siehe Artikel NVP-vProxy: NetWorker-VIB zum Öffnen von NFS-Ports für vProxy-FLR.

vCenter Server

vCenter Server verwenden betriebssystembasierte Verbindungsbefehle. In der obigen Tabelle finden Sie Informationen dazu, welche Ports und welches Zielsystem beim Testen der Kommunikation angegeben werden sollten.

curl -v target_system:port

Virtuelle Maschinen

Unabhängig davon, ob die Kommunikation von einer VM für den Data Protection Restore Client, die NetWorker Web User Interface (NWUI) oder die Konnektivität mit Data Domain getestet wird, hängt der verwendete Befehl vom Betriebssystem der virtuellen Maschine ab. Linux-Systeme können die curl Befehl zum Testen der Konnektivität:

curl -v target_system:port

Windows-Systeme können Test-NetConnection PowerShell-Cmdlet:

Test-NetConnection -ComputerName target_system  -port port

• NetWorker-Server –> vProxy-Appliance
• NetWorker-Server/Storage Node –> Data Domain
• vProxy-Appliance –> Data Domain
• vProxy-Appliance –> vCenter Server

Linux-Hosts

Die folgenden Schritte können auf Linux NetWorker-Servern, Speicher-Nodes, der vProxy-Appliance und/oder der vCenter Server Appliance durchgeführt werden.

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

Windows-Hosts

Die folgenden Schritte können auf Windows-NetWorker-Servern und/oder Remote-Storage-Nodes durchgeführt werden.

1. Erstellen Sie ein .bat Skript (timestamped_ping.bat) mit folgenden Elementen: Ersetzen Sie ADDRESS durch die IP-Adresse oder den auflösbaren DNS-FQDN des Remotehosts. Ändern Sie den Ausgabespeicherort in einen anderen Pfad, wenn NetWorker nicht im Standardinstallationspfad installiert ist oder wenn Sie die Ausgabe an einen anderen Ort leiten möchten.

@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. Öffnen Sie eine Administrator-Eingabeaufforderung in dem Verzeichnis, in dem das Skript gespeichert wurde.

3. Führen Sie das Skript aus:

timestamped_ping.bat

4. Lassen Sie das Skript ausgeführt und reproduzieren Sie das Backup- oder Wiederherstellungsproblem. 
5. Sobald das Problem reproduziert wird. Beenden Sie das Skript mithilfe von STRG+C in der Eingabeaufforderung, in der das Skript ausgeführt wird.
6. Überprüfen Sie die Datei C:\Program Files\EMC NetWorker\nsr\logs\ping.out (oder den Speicherort, den Sie angegeben haben) auf Netzwerkprobleme (verworfene Pakete, hohe Latenz usw.), die sich mit dem Zeitstempel überschneiden, von dem das Backup- oder Wiederherstellungsproblem beobachtet wird.  

HINWEIS: Im NetWorker Performance Optimization Planning Guide steht, dass die Latenz zwischen dem NetWorker-Server/Storage Node und Data Domain 50 ms nicht überschreiten sollte. Dies kann zu schlechtem Durchsatz führen. Eine höhere Latenz kann dazu führen, dass Sitzungen unerwartet geschlossen werden.