NVP vProxy: Solución de problemas de conectividad de red para operaciones de respaldo y restauración

Sistemas y puertos involucrados en las operaciones de respaldo y restauración de máquinas virtuales (VM) de VMware.

Según la Guía de configuración de seguridad de NetWorker, NetWorker utiliza una conexión de socket directo para comunicar y transferir datos a través de la red al servicio requerido con una sobrecarga mínima. Si bien NetWorker abre algunos puertos para TCP y UDP, solo requiere puertos TCP. Los puertos UDP son opcionales, excepto SNMP que utiliza los puertos UDP 161 y 162.

La tabla de puertos y la topología de red que se muestran en esta base de conocimientos se extrajeron directamente de la Guía de integración de VMware de NetWorker. Las guías de configuración de seguridad e integración de VMware se pueden encontrar en la página del producto NetWorker de soporte de Dell.

Requisitos de puertos

Sistema de nombre de dominio (DNS)

Asegúrese de comprobar que DNS esté resuelto correctamente para los sistemas involucrados, incluidos el nombre de dominio calificado (FQDN), el nombre corto y la dirección IP (búsqueda inversa).

nslookup FQDN
nslookup SHORT_NAME
nslookup IP_ADDRESS

Consulte el artículo: NetWorker: Prácticas recomendadas

para la solución de problemas de resolución de nombresTambién se recomienda comprobar los archivos de los hosts del sistema. Las entradas de archivos de host pueden entrar en conflicto, reemplazar una consulta de DNS o dar lugar a una dirección IP o un nombre de host incorrectos.

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

Servidor de NetWorker

The NetWorker nsrports El comando se puede utilizar para confirmar la resolución de nombres y la conectividad de puertos entre los sistemas involucrados. Consulte la tabla anterior sobre qué puertos y sistemas de destino se deben especificar cuando se prueba la comunicación.

nsrports -t target_system -p port

Los sistemas Linux pueden usar la función curl Comando para probar la conectividad:

curl -v target_system:port

Los sistemas Windows pueden usar Test-NetConnection Cmdlet de PowerShell:

Test-NetConnection -ComputerName target_system  -port port

Dispositivo vProxy

La utilidad ProxyHC (evaluación del estado) se puede ejecutar en el vProxy para comprobar la conectividad de los puertos entre los sistemas. Consulte el artículo: NVP-vProxy: Cómo utilizar la herramienta de evaluación del estado ProxyHC en el dispositivo vProxy.

El dispositivo vProxy también puede usar curl comando para probar la conectividad. Consulte la tabla anterior sobre qué puertos y sistemas de destino se deben especificar cuando se prueba la comunicación.

curl -v target_system:port

Servidor ESXi

La variable netcat (nc) se puede utilizar en hosts ESXi para comprobar la conectividad de los puertos. Consulte la tabla anterior sobre qué puertos y sistemas de destino se deben especificar cuando se prueba la comunicación.

nc -zv target_system port

Consulte el artículo NVP vProxy: VIB de NetWorker para abrir puertos NFS para FLR de vProxy.

vCenter Server

Los vCenter Server utilizan comandos de conexión basados en el sistema operativo. Consulte la tabla anterior sobre qué puertos y sistemas de destino se deben especificar cuando se prueba la comunicación.

curl -v target_system:port

Máquinas virtuales

Ya sea que se pruebe la comunicación desde una VM para Data Protection Restore Client, la interfaz de usuario web de NetWorker (NWUI) o la conectividad con Data Domain, el comando utilizado depende del sistema operativo de la máquina virtual. Los sistemas Linux pueden usar la función curl Comando para probar la conectividad:

curl -v target_system:port

Los sistemas Windows pueden usar Test-NetConnection Cmdlet de PowerShell:

Test-NetConnection -ComputerName target_system  -port port

• Servidor NetWorker:> dispositivo vProxy
• NetWorker Server/Nodo de almacenamiento:> Data Domain
• Dispositivo vProxy:> Data Domain
• Dispositivo vProxy:> vCenter Server

Linux Hosts

Los siguientes pasos se pueden realizar en servidores Linux NetWorker, nodos de almacenamiento, dispositivo vProxy o el dispositivo 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

Windows Hosts

Los siguientes pasos se pueden realizar en servidores NetWorker de Windows o en el nodo de almacenamiento remoto.

1. Cree un script .bat (timestamped_ping.bat) que contenga lo siguiente. Reemplace ADDRESS por la dirección IP o el FQDN que se puede resolver por DNS del host remoto. Cambie la ubicación de salida a otra ruta si NetWorker no está instalado en la ruta de instalación predeterminada o si desea dirigir la salida a otro lugar.

@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. Abra una línea de comandos de administrador en el directorio en el que se guardó el script.

3. Ejecute el script:

timestamped_ping.bat

4. Deje el script en ejecución y reproduzca el problema de respaldo o restauración. 
5. Una vez que se reproduce el problema. Detenga el script mediante CTRL+C en el símbolo del sistema en el que se ejecuta el script.
6. Revise el archivo C:\Program Files\EMC NetWorker\nsr\logs\ping.out (o la ubicación que especificó) para ver si hay problemas de red (paquetes perdidos, alta latencia, etc.) que se superpongan con el registro de fecha y hora desde que se observa el problema de respaldo o restauración.  

NOTA: En la Guía de planificación de la optimización del rendimiento de NetWorker se indica que la latencia no debe superar los 50 ms entre NetWorker Server/nodo de almacenamiento y Data Domain. Esto puede dar lugar a un rendimiento deficiente. Una latencia mayor puede provocar que las sesiones se cierren inesperadamente.