Skip to main content
  • Place orders quickly and easily
  • View orders and track your shipping status
  • Enjoy members-only rewards and discounts
  • Create and access a list of your products
  • Manage your Dell EMC sites, products, and product-level contacts using Company Administration.
Some article numbers may have changed. If this isn't what you're looking for, try searching all articles. Search articles

Dell EMC VxRail: Stav sítě vSAN občas hlásí zprávy "Hosts with communication issues"

Summary: Hostitelé ESXi v rámci clusteru VxRail VSAN mohou zaznamenat dočasné problémy s připojením a jako výsledky může stav VSAN hlásit chybové zprávy "Hosts with communication issues".

This article may have been automatically translated. If you have any feedback regarding its quality, please let us know using the form at the bottom of this page.

Article Content


Symptoms

Hostitelé mohou občas hlásit problémy s připojením. Hostitelé zůstanou připojeni, ale kontrola stavu sítě vSAN může pravidelně zobrazovat náhodné hostitele s problémy s komunikací. Pokud bude stav VSAN znovu testován, problém zmizí, ale po několika minutách se vrátí.

Dotčené verze:
Zatím dochází k ovlivnění verzí VxRail 4.5.x a 4.7.x. 

Shrnutí analýzy protokolů:

Vidíme, že se v nástroji vCenter zobrazuje alarm stavu sítě vSAN:

2019-08-14T12:56:01.422Z INFO vsan-mgmt[EventMonitor] [VsanEventUtil::_generateVcEvent opID=noOpId] Generate VC event for managed object NC1V01 with testName=Hosts with connectivity issues, testId=com.vmware.vsan.health.test.hostconnectivity, preStatus=green, curStatus=red
V protokolu vmware-vsan-health-summary-result.log jsou uvedeny problémy s připojením hostitele stavu vSAN:
2019-08-14T12:56:01.355Z INFO vsan-mgmt[EventMonitor] [VsanHealthSummaryLogUtil::PrintHealthResult opID=noOpId] Cluster NB1X01  Overall Health : red
   Group network health : red
      Test hostdisconnected health : green
      Test hostconnectivity health : red
         HostsWithCommunicationIssues: Host
                                       (Host-234),
      Test clusterpartition health : green
      Test vsanvmknic health : green
      Test smallping health : green
      Test largeping health : green
      Test vmotionpingsmall health : green
      Test vmotionpinglarge health : green
      Test hostlatencycheck health : green
         NetworkLatencyCheckResults: FromHost  ToHost  NetworkLatency(Ms)  NetworkLatencyCheckResult
                                     (Host-227, Host-236, 0.18, Green), (Host-227, Host-234, 0.23, Green), (Host-227, Host-238, 0.16, Green), (Host-227, Host-232, 0.12, Green), (Host-234, Host-232, 0.27, Green),
                                     (Host-234, Host-238, 0.31, Green), (Host-234, Host-236, 0.29, Green), (Host-234, Host-227, 0.26, Green), (Host-236, Host-227, 0.1, Green), (Host-236, Host-234, 0.12, Green),
                                     (Host-236, Host-238, 0.1, Green), (Host-236, Host-232, 0.1, Green), (Host-232, Host-236, 0.1, Green), (Host-232, Host-238, 0.1, Green), (Host-232, Host-234, 0.12, Green),
                                     (Host-232, Host-227, 0.11, Green), (Host-238, Host-232, 0.15, Green), (Host-238, Host-236, 0.11, Green), (Host-238, Host-234, 0.23, Green), (Host-238, Host-227, 0.12, Green),
   Group cloudhealth health : yellow
      Test vsancloudhealthceipexception health : yellow
   Group vum health : yellow
      Test vumconfig health : yellow


 
vmware-vsan-health-service.log:

2019-08-14T12:55:54.403Z ERROR vsan-mgmt[Thread-590807] [VsanPyVmomiProfiler::InvokeMethod opID=noOpId] Timed out for host nc1v02ps12.corp.ukrail.net in invoke-method:vsanSystem:Query
HostStatus
2019-08-14T12:55:54.403Z INFO vsan-mgmt[Thread-590807] [VsanPyVmomiProfiler::logProfile opID=noOpId]   invoke-method:vsanSystem:QueryHostStatus: 8.44s:nc1v02ps12.corp.ukrail.net
2019-08-14T12:55:54.403Z ERROR vsan-mgmt[Thread-590807] [VsanClusterHealthSystemImpl::PerHostQueryNetworkHealth opID=noOpId] Exception in host nc1v02ps12.corp.ukrail.net:
Traceback (most recent call last):
  File "C:\Program Files\VMware\vCenter Server\vsan-health\pyMoVsan\VsanClusterHealthSystemImpl.py", line 1004, in PerHostQueryNetworkHealth
    SetHostClusterUuid(host, hostInfos[host], fetchHostStatus=True)
  File "C:\Program Files\VMware\vCenter Server\vsan-health\pyMoVsan\VsanClusterHealthSystemImpl.py", line 784, in SetHostClusterUuid
    status = vs.QueryHostStatus()
..
..
..
    return self._sslobj.read(len, buffer)
  File "C:\Program Files\VMware\vCenter Server\python\lib\ssl.py", line 583, in read
    v = self._sslobj.read(len, buffer)
socket.timeout: The read operation timed out
 

Cause

Ve výchozím nastavení je možnost PTAgent nastavena tak, aby každé 3 minuty znovu prohledávat zařízení a sběrnici SCSI. Tento typ dotazu je vyhledat nové disky nebo jiná hardwarová zařízení připojená k serveru. Byl rozšířen o kontrolu dalších blokových zařízení, jako je například iSCSI. V zásadě kontrolujeme místní adaptér HBA, jestli nebyly nedávno přidány nějaké nové disky. 
Stoh úložiště ESXi také provádí své vlastní zařízení a sběrnici ve výchozím nastavení každých 5 minut a hledá totéž. Opětovné skenování zařízení a sběrnice je z pohledu úložiště nákladnou operací. Může to vést k zablokování některých částí sběrnice SCSI a čekání na dokončení operace. To může mít zakroucený dopad na zvýšenou latenci při čekání na dokončení operace. Pokud je již v letadle mnoho operací úložiště, může být nutné je nechat dokončit, než bude možné provést kontrolu.

Zjistili jsme, že v některých případech se v zásadě znovu kontrolují agenty PTAgent a ESXi. To může vést k prodlevě odezvy při dokončení rescanů, což občas vyvolá alarm stavu sítě vSAN. Stav vSAN nespouští alarm pro selhání testu, ale test, který je spuštěn, je označen jako neúspěšný, jelikož vypršel časový limit dotazu na stav sítě vSAN.
Celkově jde o časování problému. Stav sítě vSAN má krátký časový limit pro odpověď na dotazy a nemá žádný pokus nebo jiný ověřovací mechanismus k potvrzení chyby. Opětovná kontrola z aplikace PTAgent a ESXi spuštěná současně (spolu s jinými I/O ve frontě) může způsobit dostatečně dlouhou prodlevu, která způsobí vypršení časového limitu stavu úložiště vSAN.

Resolution

Náhradním řešením je zakázat opětovné skenování agenta PTAgent a v podstatě ponechat výchozí úložiště ESXi znovu na místě. To v podstatě využívá stejný interval rescan, který systém VMware používá ve výchozím nastavení se systémem vSAN. S touto změnou není žádné riziko pro data ani operace I/O. Znamená to, že k opakované kontrole nedochází tak často, ale přidávání nebo odstraňování disků není běžným jevem. Pokud je disk přidán prostřednictvím připojení za provozu, adaptér HBA má speciální logiku, která informuje operační systém (ESXi), že došlo ke změně disku. V ostatních případech byste přidávat nebo odebírat disky, když je server vypnutý, a opětovné vyhledání je součástí pořadí spouštění. Existují některé případy, kdy je žádoucí paralelní opětovné hledejte. Například převzetí při selhání replikace nebo nové disky přidané z pole iSCSI, FC, FCoE). Mechanismy převzetí služeb při selhání, jako je například režim SRM, však mají logiku tuto funkci řešit dalšími rescany nebo využívají funkce těchto typů disků (například RSCN v FC). Žádná z těchto scénářů by v tomto případě neměla být platná, a to ani v případě, že jsou ve hře, systém ESXi je zvládne správně.

Náhradní řešení:
POZNÁMKA: V aplikaci PTAgent 1.9.2 a vyšších je řádně implementováno následující chování. 

Zkontrolujte poznámky k verzi VxRail pro verzi PTAgent, která je součástí aktuálního vydání.
1) Zkontrolujte, zda opětovné kontroly stále spouštějí:

[root@vs218:~] grep -w "Dispatch rescan" /var/run/log/hostd.log |tail -10
2019-10-17T12:16:06.080Z info hostd[2106293] [Originator@6876 sub=Solo.VmwareCLI opID=esxcli-0a-ae0b user=root] Dispatch rescan
2019-10-17T12:16:07.231Z info hostd[2106293] [Originator@6876 sub=Solo.VmwareCLI opID=esxcli-0a-ae0b user=root] Dispatch rescan done

2) Přepněte hostitele ESXi do režimu údržby.

3) Deaktivujte opětovnou kontrolu pomocí těchto příkazů:

       # /opt/dell/DellPTAgent/tools/pta_cfg set in_band_device_scan_enabled=false
       # /opt/dell/DellPTAgent/tools/pta_cfg set in_band_device_poll_interval_minutes=0
4) Potvrďte, že je vypnutý pomocí
       # /opt/dell/DellPTAgent/tools/pta_cfg list |grep "in_band_device"
           in_band_device_poll_interval_minutes => 0
           in_band_device_scan_enabled          => False
       # grep -A4 in_band_device_scan_enabled /scratch/dell/config/PTAgent.config
           "in_band_device_scan_enabled": {
               "value": false,
               "defaultValue": true,
               "description": "On ESXi platforms, controls if PT-agent should force adapter scans periodically (controlled by in_band_device_poll_interval_minutes) before probing storage devices."
           },
5) Restartujte službu PTAgent na uzlu pomocí:

       # /etc/init.d/DellPTAgent restart
6) Ukončete režim údržby.

7) Opakujte stejné kroky pro všechny uzly v clusteru.



Additional Information

Vypnutím aplikace PTAgent rescan nedochází k žádným problémům s funkčností úložiště, protože systém ESXi se již v pravidelných intervalech provádí sám.
I když je kontrola zařízení v pásmu zakázána, bude aplikace PTAgent při spuštění stále skenovat. Pokud k příznaku dochází i po deaktivaci kontroly, je nutné se podívat na důvod opakovaného restartování aplikace PTAgent.

Article Properties


Affected Product

VxRail Appliance Family

Product

VxRail Appliance Family, VxRail Appliance Series, VxRail E Series Nodes, VxRail E460, VxRail E560, VxRail E560F, VxRail P470, VxRail P570, VxRail P570F, VxRail S570, VxRail Software

Last Published Date

17 Jun 2023

Version

6

Article Type

Solution