NVP vProxy: Problemen met netwerkconnectiviteit oplossen voor back-up- en herstelbewerkingen

Systemen en poorten die betrokken zijn bij back-up- en herstelbewerkingen voor VMware Virtual Machine (VM).

Volgens de NetWorker Security Configuration Guide maakt NetWorker gebruik van een directe socketverbinding om met minimale overhead te communiceren en data via het netwerk naar de vereiste service te verplaatsen. Hoewel NetWorker enkele poorten voor TCP en UDP opent, heeft NetWorker alleen TCP-poorten nodig. UDP-poorten zijn optioneel, behalve voor SNMP dat UDP-poort 161 en 162 gebruikt.

De poorttabel en netwerktopologie die in deze KB worden weergegeven, zijn rechtstreeks opgehaald uit de NetWorker VMware Integration Guide. De configuratiehandleidingen voor VMware-integratie en -beveiliging vindt u op de productpagina van Dell Support NetWorker.

Poortvereisten

Domain Name System (DNS)

Controleer of DNS correct is omgezet voor de betrokken systemen, inclusief de FQDN (Fully Qualified Domain Name), de korte naam en het IP-adres (Reverse Lookup).

nslookup FQDN
nslookup SHORT_NAME
nslookup IP_ADDRESS

Zie het artikel: NetWorker: Best practices

voor het oplossen van problemen met naamresolutieHet wordt ook aangeraden om de bestanden van de systeemhosts te controleren. Hostbestandsvermeldingen kunnen conflicteren of een DNS-query overschrijven, of leiden tot een onjuist IP-adres of hostnaam.

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

NetWorker Server

De NetWorker nsrports Command kan worden gebruikt om de naamomzetting en poortconnectiviteit tussen de betrokken systemen te bevestigen. Zie de bovenstaande tabel met informatie over welke poorten en doelsysteem moeten worden opgegeven bij het testen van de communicatie.

nsrports -t target_system -p port

Linux-systemen kunnen gebruik maken van de curl Opdracht om de connectiviteit te testen:

curl -v target_system:port

Windows-systemen kunnen gebruik maken van Test-NetConnection PowerShell cmdlet:

Test-NetConnection -ComputerName target_system  -port port

vProxy Appliance

Het hulpprogramma ProxyHC (Health Check) kan worden uitgevoerd op de vProxy om de poortconnectiviteit tussen systemen te controleren, zie artikel: NVP-vProxy: De healthcheck-tool ProxyHC gebruiken op een vProxy-apparaat.

Het vProxy-apparaat kan ook het volgende gebruiken: curl Opdracht om de connectiviteit te testen. Zie de bovenstaande tabel met informatie over welke poorten en doelsysteem moeten worden opgegeven bij het testen van de communicatie.

curl -v target_system:port

ESXi-server

De netcat (nc) kan worden gebruikt op ESXi-hosts om de poortconnectiviteit te controleren. Zie de bovenstaande tabel met informatie over welke poorten en doelsysteem moeten worden opgegeven bij het testen van de communicatie.

nc -zv target_system port

Zie artikel NVP vProxy: NetWorker VIB om NFS-poorten te openen voor vProxy FLR.

vCenter Server

vCenter servers gebruiken verbindingsopdrachten op basis van het besturingssysteem. Zie de bovenstaande tabel met informatie over welke poorten en doelsysteem moeten worden opgegeven bij het testen van de communicatie.

curl -v target_system:port

Virtuele machines

Of het nu gaat om het testen van communicatie van een VM voor de Data Protection Restore Client, NetWorker Web User Interface (NWUI) of connectiviteit met Data Domain, de gebruikte opdracht is afhankelijk van het besturingssysteem van de virtuele machine. Linux-systemen kunnen gebruik maken van de curl Opdracht om de connectiviteit te testen:

curl -v target_system:port

Windows-systemen kunnen gebruik maken van Test-NetConnection PowerShell cmdlet:

Test-NetConnection -ComputerName target_system  -port port

• NetWorker server -> vProxy Appliance
• NetWorker server/storageknooppunt -> Data Domain
• vProxy Appliance -> Data Domain
• vProxy Appliance -> vCenter server

Linux-hosts

De volgende stappen kunnen worden uitgevoerd op Linux NetWorker-servers, storageknooppunten, vProxy-appliance en/of de vCenter Server-appliance.

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

De volgende stappen kunnen worden uitgevoerd op Windows NetWorker-servers en/of een extern storageknooppunt.

1. Maak een .bat script (timestamped_ping.bat) met daarin het volgende. Vervang ADDRESS door het IP-adres of de DNS-oplosbare FQDN van de externe host. Wijzig de uitvoerlocatie in een ander pad als NetWorker niet in het standaard installatiepad is geïnstalleerd of als u de uitvoer ergens anders naartoe wilt sturen.

@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. Open een Administrator-opdrachtprompt in de map waarin het script is opgeslagen.

3. Voer het script uit:

timestamped_ping.bat

4. Laat het script actief en reproduceer het back-up- of herstelprobleem. 
5. Zodra het probleem zich voortplant. Stop het script met behulp van CTRL+C in de opdrachtprompt waarin het script wordt uitgevoerd.
6. Controleer het bestand C:\Program Files\EMC NetWorker\nsr\logs\ping.out (of de locatie die u hebt opgegeven) op netwerkproblemen (wegvallende pakketten, hoge latentie, enzovoort) die overlappen met de tijdstempel vanaf het moment waarop het back-up- of herstelprobleem wordt waargenomen.  

OPMERKING: In de NetWorker Performance Optimization Planning Guide staat dat de latentie tussen de NetWorker server/storage knooppunt en Data Domain niet groter mag zijn dan 50 ms. Dit kan leiden tot een slechte doorvoer. Een hogere latentie kan ertoe leiden dat sessies onverwacht worden gesloten.