NVP vProxy: Solução de problemas de conectividade de rede para operações de backup e restauração

Sistemas e portas envolvidos nas operações de backup e restauração de máquina virtual (VM) VMware.

De acordo com o Guia de configuração de segurança do NetWorker, o NetWorker usa uma conexão direta de soquete para se comunicar e mover dados pela rede para o serviço necessário com sobrecarga mínima. Embora o NetWorker abra algumas portas para TCP e UDP, ele requer apenas portas TCP. As portas UDP são opcionais, exceto para SNMP que usa as portas UDP 161 e 162.

A tabela de portas e a topologia de rede exibidas neste artigo da KB foram extraídas diretamente do Guia de integração do NetWorker VMware. Os guias de configuração de integração e segurança do VMware podem ser encontrados na página do produto NetWorker do Suporte Dell.

Requisitos de porta

Sistema de Nomes de Domínio (DNS)

Verifique se o DNS foi resolvido corretamente para os sistemas envolvidos, incluindo o FQDN (Fully Qualified Domain Name, nome de domínio totalmente qualificado), nome abreviado e endereço IP (pesquisa inversa).

nslookup FQDN
nslookup SHORT_NAME
nslookup IP_ADDRESS

Consulte o artigo: NetWorker: Práticas

recomendadas para solução de problemas de resolução de nomesTambém é aconselhável verificar os arquivos dos hosts do sistema. As entradas do arquivo host podem entrar em conflito ou substituir uma consulta DNS ou resultar em um endereço IP ou nome de host incorreto.

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

NetWorker Server

O NetWorker nsrports O comando pode ser usado para confirmar a resolução de nome e a conectividade de porta entre os sistemas envolvidos. Consulte a tabela acima em relação a quais portas e sistema de destino devem ser especificados ao testar a comunicação.

nsrports -t target_system -p port

Os sistemas Linux podem usar o curl Comando para testar a conectividade:

curl -v target_system:port

Os sistemas Windows podem usar Test-NetConnection Cmdlet do PowerShell:

Test-NetConnection -ComputerName target_system  -port port

Equipamento vProxy

O utilitário ProxyHC (verificação de integridade) pode ser executado no vProxy para verificar a conectividade de porta entre sistemas, consulte o artigo: NVP - vProxy: Como usar a ferramenta de verificação de integridade ProxyHC no equipamento vProxy.

O equipamento vProxy também pode usar o curl Comando para testar a conectividade. Consulte a tabela acima em relação a quais portas e sistema de destino devem ser especificados ao testar a comunicação.

curl -v target_system:port

Servidor ESXi

A coluna netcat O comando (nc) pode ser usado em hosts do ESXi para verificar a conectividade da porta. Consulte a tabela acima em relação a quais portas e sistema de destino devem ser especificados ao testar a comunicação.

nc -zv target_system port

Consulte o artigo NVP vProxy: VIB do NetWorker para abrir portas NFS para FLR do vProxy.

vCenter Server

Os vCenter Servers usam comandos de conexão baseados em sistema operacional. Consulte a tabela acima em relação a quais portas e sistema de destino devem ser especificados ao testar a comunicação.

curl -v target_system:port

Máquinas virtuais

Seja testando a comunicação de uma VM para o Data Protection Restore Client, a Interface do usuário da Web do NetWorker (NWUI) ou a conectividade com o Data Domain, o comando usado depende do sistema operacional da máquina virtual. Os sistemas Linux podem usar o curl Comando para testar a conectividade:

curl -v target_system:port

Os sistemas Windows podem usar Test-NetConnection Cmdlet do PowerShell:

Test-NetConnection -ComputerName target_system  -port port

• Servidor NetWorker -> Equipamento vProxy
• Servidor/nó de armazenamento do NetWorker —> Data Domain
• Equipamento vProxy —> Data Domain
• Equipamento vProxy —> vCenter Server

Linux Hosts

As etapas a seguir podem ser executadas em servidores NetWorker no Linux, nós de armazenamento, equipamento vProxy e/ou no equipamento 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

As etapas a seguir podem ser executadas em servidores Windows NetWorker e/ou nó de armazenamento remoto.

1. Crie um script de .bat (timestamped_ping.bat) contendo o seguinte. Substitua ADDRESS pelo endereço IP ou FQDN resolvível de DNS do host remoto. Altere o local de saída para outro caminho se o NetWorker não estiver instalado no caminho de instalação padrão ou se você quiser direcionar a saída para outro 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 um prompt de comando de administrador no diretório em que o script foi salvo.

3. Execute o script:

timestamped_ping.bat

4. Deixe o script em execução e reproduza o problema de backup ou restauração. 
5. Assim que o problema for reproduzido. Interrompa o script usando CTRL+C no prompt de comando em que o script está sendo executado.
6. Analise o arquivo C:\Program Files\EMC NetWorker\nsr\logs\ping.out (ou local que você especificou) em busca de quaisquer problemas de rede (pacotes descartados, alta latência etc.) que se sobreponham ao registro de data e hora de quando o problema de backup ou restauração é observado.  

Nota: O Guia de planejamento de otimização de desempenho do NetWorker afirma que a latência não deve exceder 50 ms entre o nó de armazenamento/servidor do NetWorker e o Data Domain. Isso pode resultar em uma taxa de transferência baixa. Uma latência maior pode resultar no fechamento inesperado das sessões.