NVP vProxy: risoluzione dei problemi di connettività di rete per le operazioni di backup e ripristino

Sistemi e porte coinvolti nelle operazioni di backup e ripristino delle macchine virtuali (VM) VMware.

In base a quanto riportato nella NetWorker Security Configuration Guide, NetWorker utilizza una connessione socket diretta per comunicare e spostare i dati attraverso la rete al servizio richiesto con overhead minimo. Sebbene NetWorker apra alcune porte per TCP e UDP, richiede solo le porte TCP. Le porte UDP sono opzionali, ad eccezione di SNMP che utilizza le porte UDP 161 e 162.

La tabella delle porte e la topologia di rete visualizzate in questo articolo della KB sono state estratte direttamente dalla NetWorker VMware Integration Guide. Le guide all'integrazione e alla configurazione della sicurezza di VMware sono disponibili nella pagina del prodotto NetWorker del supporto Dell.

Requisiti delle porte

DNS (Domain Name System)

Assicurarsi di verificare che DNS sia risolto correttamente per i sistemi interessati, inclusi il nome di dominio completo (FQDN), il nome breve e l'indirizzo IP (ricerca inversa).

nslookup FQDN
nslookup SHORT_NAME
nslookup IP_ADDRESS

consultare l'articolo NetWorker: Best practice

per la risoluzione dei problemiSi consiglia inoltre di controllare i file host di sistema. Le voci dei file host possono entrare in conflitto o sovrascrivere una query DNS oppure portare a un indirizzo IP o a un nome host errato.

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

Server NetWorker

The NetWorker nsrports Il comando può essere utilizzato per confermare la risoluzione dei nomi e la connettività delle porte tra i sistemi coinvolti. Vedere la tabella precedente per informazioni sulle porte e sul sistema di destinazione da specificare durante il test della comunicazione.

nsrports -t target_system -p port

I sistemi Linux possono utilizzare il comando curl per testare la connettività:

curl -v target_system:port

I sistemi Windows possono utilizzare Test-NetConnection Cmdlet di PowerShell:

Test-NetConnection -ComputerName target_system  -port port

Appliance vProxy

L'utilità ProxyHC (Health Check) può essere eseguita sul vProxy per controllare la connettività delle porte tra i sistemi. Consultare l'articolo: NVP-vProxy: Come utilizzare lo strumento di controllo integrità ProxyHC sull'appliance vProxy.

L'appliance vProxy può inoltre utilizzare curl per testare la connettività. Vedere la tabella precedente per informazioni sulle porte e sul sistema di destinazione da specificare durante il test della comunicazione.

curl -v target_system:port

ESXi Server

La colonna netcat (nc) può essere utilizzato sugli host ESXi per verificare la connettività delle porte. Vedere la tabella precedente per informazioni sulle porte e sul sistema di destinazione da specificare durante il test della comunicazione.

nc -zv target_system port

Consultare l'articolo NVP vProxy: NetWorker VIB per aprire le porte NFS per vProxy FLR.

vCenter Server

I vCenter Server utilizzano comandi di connessione basati sul sistema operativo. Vedere la tabella precedente per informazioni sulle porte e sul sistema di destinazione da specificare durante il test della comunicazione.

curl -v target_system:port

Macchine virtuali

Che si tratti di testare la comunicazione da una VM per Data Protection Restore Client, NetWorker Web User Interface (NWUI) o la connettività con Data Domain, il comando utilizzato dipende dal sistema operativo della macchina virtuale. I sistemi Linux possono utilizzare il comando curl per testare la connettività:

curl -v target_system:port

I sistemi Windows possono utilizzare Test-NetConnection Cmdlet di PowerShell:

Test-NetConnection -ComputerName target_system  -port port

• Server NetWorker -> Appliance vProxy
• Server/storage node NetWorker -> Data Domain
• Appliance vProxy -> Data Domain
• Appliance vProxy -> vCenter Server

Host Linux

I seguenti passaggi possono essere eseguiti sui server NetWorker Linux, sugli storage node, sull'appliance vProxy e/o sull'appliance 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

La seguente procedura può essere eseguita sui server NetWorker di Windows e/o sullo storage node remoto.

1. Creare uno script .bat (timestamped_ping.bat) contenente quanto segue. Sostituire ADDRESS con l'indirizzo IP o l FQDN risolvibile DNS dell host remoto. Modificare il percorso di output in un altro percorso se NetWorker non è installato nel percorso di installazione predefinito o se si desidera indirizzare l'output in un'altra posizione.

@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. Aprire un prompt dei comandi dell'amministratore nella directory in cui è stato salvato lo script.

3. Eseguire lo script:

timestamped_ping.bat

4. Lasciare lo script in esecuzione e riprodurre il problema di backup o ripristino. 
5. Una volta riprodotto il problema. Arrestare lo script utilizzando CTRL+C nel prompt dei comandi in cui è in esecuzione lo script.
6. Esaminare il file C:\Program Files\EMC NetWorker\nsr\logs\ping.out (o il percorso specificato) per rilevare eventuali problemi di rete (pacchetti ignorati, latenza elevata e così via) che si sovrappongono al timestamp di quando viene osservato il problema di backup o ripristino.  

NOTA: Il documento NetWorker Performance Optimization Planning Guide indica che la latenza non deve superare i 50 ms tra il server/storage node NetWorker e Data Domain. Ciò può causare una scarsa produttività. Una latenza più elevata può causare la chiusura imprevista delle sessioni.