NVP vProxy : Connectivité réseau pour les opérations de sauvegarde et de restauration

Systèmes et ports impliqués dans les opérations de sauvegarde et de restauration des machines virtuelles (VM) VMware.

D’après le Guide de configuration de la sécurité de NetWorker, NetWorker utilise une connexion à socket direct pour communiquer et déplacer les données sur le réseau vers le service requis avec un temps système minimal. Alors que NetWorker ouvre certains ports TCP et UDP, NetWorker n’a besoin que des ports TCP. Les ports UDP sont facultatifs, à l’exception de SNMP qui utilise les ports UDP 161 et 162.

La table des ports et la topologie réseau affichées dans cet article de la base de connaissances proviennent directement du Guide d’intégration de NetWorker VMware. Les guides d’intégration et de configuration de la sécuritéVMware sont disponibles sur la page produit NetWorker du support Dell.

Configuration requise des ports

DNS (Domain Name System)

Assurez-vous de vérifier que le DNS est résolu correctement pour les systèmes concernés, y compris le nom de domaine complet (FQDN), le nom abrégé et l’adresse IP (recherche inversée).

nslookup FQDN
nslookup SHORT_NAME
nslookup IP_ADDRESS

Consultez l'article suivant : NetWorker : Meilleures pratiques

de dépannage pour la résolution de nomsIl est également conseillé de vérifier les fichiers des hôtes du système. Les entrées du fichier hôte peuvent créer un conflit ou remplacer une requête DNS, ou conduire à une adresse IP ou un nom d’hôte incorrect.

• Systèmes Linux : /etc/hosts
• Systèmes Windows : C:\Windows\System32\drivers\etc\hosts

Serveur NetWorker

L’environnement NetWorker nsrports peut être utilisée pour confirmer la résolution de noms et la connectivité des ports entre les systèmes concernés. Reportez-vous au tableau ci-dessus pour savoir quels ports et quel système cible doivent être spécifiés lors du test de communication.

nsrports -t target_system -p port

Les systèmes Linux peuvent utiliser la commande curl Commande pour tester la connectivité :

curl -v target_system:port

Les systèmes Windows peuvent utiliser Test-NetConnection Applet de commande PowerShell :

Test-NetConnection -ComputerName target_system  -port port

Appliance vProxy

L’utilitaire ProxyHC (bilan de santé) peut être exécuté sur le vProxy pour vérifier la connectivité des ports entre les systèmes. Voir l’article : NVP-vProxy : Utilisation de l’outil de bilan de santé ProxyHC sur l’appliance vProxy.

L’appliance vProxy peut également utiliser la commande curl pour tester la connectivité. Reportez-vous au tableau ci-dessus pour savoir quels ports et quel système cible doivent être spécifiés lors du test de communication.

curl -v target_system:port

Serveur ESXi

La commande netcat (nc) peut être utilisée sur les hôtes ESXi pour vérifier la connectivité des ports. Reportez-vous au tableau ci-dessus pour savoir quels ports et quel système cible doivent être spécifiés lors du test de communication.

nc -zv target_system port

Voir l’article NVP vProxy : NetWorker VIB pour ouvrir les ports NFS pour vProxy FLR.

vCenter Server

Les serveurs vCenter utilisent des commandes de connexion basées sur le système d’exploitation. Reportez-vous au tableau ci-dessus pour savoir quels ports et quel système cible doivent être spécifiés lors du test de communication.

curl -v target_system:port

Machines virtuelles

Qu’il s’agisse de tester la communication à partir d’une machine virtuelle pour Data Protection Restore Client, NetWorker Web User Interface (NWUI) ou la connectivité avec Data Domain, la commande utilisée dépend du système d’exploitation de la machine virtuelle. Les systèmes Linux peuvent utiliser la commande curl Commande pour tester la connectivité :

curl -v target_system:port

Les systèmes Windows peuvent utiliser Test-NetConnection Applet de commande PowerShell :

Test-NetConnection -ComputerName target_system  -port port

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

Hôtes Linux

Les étapes suivantes peuvent être effectuées sur les serveurs NetWorker Linux, les nœuds de stockage, l’appliance vProxy et/ou l’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

Hôtes Windows

Les étapes suivantes peuvent être effectuées sur les serveurs Windows NetWorker et/ou le nœud de stockage distant.

1. Créez un script .bat (timestamped_ping.bat) contenant les éléments suivants. Remplacez ADDRESS par l’adresse IP ou le nom de domaine complet pouvant être résolu par le DNS de l’hôte distant. Modifiez l’emplacement de sortie vers un autre chemin si NetWorker n’est pas installé dans le chemin d’installation par défaut, ou si vous souhaitez diriger la sortie ailleurs.

@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. Ouvrez une invite de commande Administrateur dans le répertoire où le script a été enregistré.

3. Exécutez le script :

timestamped_ping.bat

4. Laissez le script en cours d’exécution et reproduisez le problème de sauvegarde ou de restauration. 
5. Une fois le problème résolu, reproduisez-le. Arrêtez le script à l’aide des touches CTRL+C dans l’invite de commande dans laquelle il s’exécute.
6. Passez en revue le fichier C :\Program Files\EMC NetWorker\nsr\logs\ping.out (ou l’emplacement que vous avez spécifié) pour détecter les éventuels problèmes réseau (paquets abandonnés, latence élevée, etc.) qui chevauchent l’horodatage à partir duquel le problème de sauvegarde ou de restauration est observé.  

Remarque : Le NetWorker Performance Optimization Planning Guide indique que la latence ne doit pas dépasser 50 ms entre le serveur/nœud de stockage NetWorker et le système Data Domain. Cela peut entraîner un débit médiocre. Une latence plus élevée peut entraîner des fermetures de sessions inattendues.