NVP vProxy: Odstraňování problémů se síťovým připojením pro operace zálohování a obnovení

Systémy a porty, které jsou zapojené do operací zálohování a obnovení virtuálního počítače VMware (VM).

Podle průvodce konfigurací zabezpečení NetWorker používá nástroj NetWorker přímé připojení soketu ke komunikaci a přesunu dat přes síť do požadované služby s minimální režií. Zatímco nástroj NetWorker otevírá některé porty pro protokoly TCP a UDP, nástroj NetWorker vyžaduje pouze porty TCP. Porty UDP jsou volitelné, s výjimkou protokolu SNMP, který používá porty UDP 161 a 162.

Tabulka portů a topologie sítě zobrazené v tomto článku znalostní databáze byly získány přímo z Průvodce integrací NetWorker VMware. Průvodce integrací systému VMware a konfigurací zabezpečení naleznete na stránce produktu Dell Support NetWorker.

Požadavky na porty

Systém DNS (Domain Name System)

Zkontrolujte, zda je služba DNS správně přeložena pro příslušné systémy, včetně plně kvalifikovaného názvu domény (FQDN), krátkého názvu a IP adresy (zpětné vyhledávání).

nslookup FQDN
nslookup SHORT_NAME
nslookup IP_ADDRESS

Viz článek: NetWorker: Doporučené postupy

při odstraňování problémů s překladem názvůDoporučujeme také zkontrolovat soubory hostitelů systému. Položky hostitelského souboru mohou být v konfliktu nebo přepsat dotaz DNS nebo vést k nesprávné IP adrese nebo názvu hostitele.

• Systémy Linux: /etc/hosts
• Systémy Windows: C:\Windows\System32\drivers\etc\hosts

Server NetWorker

Pracovník sítě nsrports Příkaz lze použít k potvrzení překladu IP adres a připojení portů mezi zúčastněnými systémy. Informace o portech a cílovém systému, které je třeba zadat při testování komunikace, naleznete v tabulce výše.

nsrports -t target_system -p port

Systémy Linux mohou používat curl Příkaz k otestování připojení:

curl -v target_system:port

Systémy Windows mohou používat Test-NetConnection Rutina PowerShellu:

Test-NetConnection -ComputerName target_system  -port port

Zařízení vProxy

Na serveru vProxy lze spustit nástroj ProxyHC (Health Check), který kontroluje konektivitu portů mezi systémy, viz článek: NVP – vProxy: Jak používat nástroj pro kontrolu stavu ProxyHC na zařízení vProxy.

Zařízení vProxy může také používat curl Příkaz k otestování připojení. Informace o portech a cílovém systému, které je třeba zadat při testování komunikace, naleznete v tabulce výše.

curl -v target_system:port

ESXi Server

Skript netcat Příkaz (nc) lze použít na hostitelích ESXi ke kontrole připojení portu. Informace o portech a cílovém systému, které je třeba zadat při testování komunikace, naleznete v tabulce výše.

nc -zv target_system port

Viz článek NVP vProxy: Soubor NetWorker VIB k otevření portů NFS pro systém vProxy FLR.

vCenter Server

Servery vCenter používají příkazy pro připojení založené na operačním systému. Informace o portech a cílovém systému, které je třeba zadat při testování komunikace, naleznete v tabulce výše.

curl -v target_system:port

Virtuální počítače

Ať už testujete komunikaci z virtuálního počítače pro klienta Data Protection Restore, webové uživatelské rozhraní NetWorker (NWUI) nebo připojení k systému Data Domain, použitý příkaz závisí na operačním systému virtuálního počítače. Systémy Linux mohou používat curl Příkaz k otestování připojení:

curl -v target_system:port

Systémy Windows mohou používat Test-NetConnection Rutina PowerShellu:

Test-NetConnection -ComputerName target_system  -port port

• Server NetWorker –> zařízení vProxy
• Server NetWorker / uzel úložiště –> Data Domain
• Zařízení vProxy –> Data Domain
• Zařízení vProxy –> server vCenter

Hostitelé v systému Linux

Následující kroky lze provést na serverech NetWorker se systémem Linux, uzlech úložiště, zařízení vProxy nebo zařízení 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

Hostitelé Windows

Následující kroky lze provést na serverech Windows NetWorker nebo uzlu vzdáleného úložiště.

1. Vytvořte .bat skript (timestamped_ping.bat) obsahující následující položky. Nahraďte ADDRESS IP adresou nebo plně kvalifikovaným názvem domény DNS vzdáleného hostitele. Pokud není ve výchozí instalační cestě nainstalován nástroj NetWorker nebo pokud chcete výstup nasměrovat někam jinam, změňte umístění výstupu na jinou cestu.

@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. Otevřete příkazový řádek správce v adresáři, kam byl skript uložen.

3. Spusťte skript:

timestamped_ping.bat

4. Nechte skript spuštěný a reprodukujte problém se zálohováním nebo obnovením. 
5. Jakmile se problém reprodukuje. Zastavte skript pomocí kombinace kláves CTRL+C v příkazovém řádku, ve kterém je skript spuštěn.
6. Zkontrolujte, zda soubor C:\Program Files\EMC NetWorker\nsr\logs\ping.out (nebo zadané umístění) neobsahuje problémy se sítí (zahozené pakety, vysoká latence atd.), které se překrývají s časovým razítkem od okamžiku, kdy dojde k problému se zálohováním nebo obnovením.  

POZNÁMKA: Průvodce plánováním optimalizace výkonu NetWorker uvádí, že latence by neměla překročit 50 ms mezi serverem/uzlem úložiště NetWorker a systémem Data Domain. To může mít za následek nízkou propustnost. Vyšší latence může vést k neočekávanému ukončení relací.