Skip to main content
Sign Out

Welcome to Dell

My Account
  • 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.
Sign In Create an Account Dell Financial Services Premier Sign In Partner Program Sign In
Contact Us

Your Dell.com Carts

Some article numbers may have changed. If this isn't what you're looking for, try searching all articles. Search articles

Article Number: 000056125

Dell EMC VxRail: vSAN-sundhedsrapporter lejlighedsvis "Værter med kommunikationsproblemer" meddelelser

Summary: ESXi-værter i en VxRail VSAN-klynge kan opleve problemer med midlertidig forbindelse, og som et resultat kan VSAN-sundhed rapportere fejlmeddelelser om "Værter med kommunikationsproblemer". ...

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

Fra tid til anden kan værter rapportere problemer med forbindelsen. Værter forbliver tilsluttet, men vSAN-sundhedstjekket kan periodisk vise tilfældige værter med kommunikationsproblemer. Hvis VSAN-sundhed prøves igen, forsvinder problemet, men vender tilbage efter et par minutter.

Berørte versioner:
Indtil videre er VxRail-versionerne 4.5.x og 4.7.x berørt. 

Loganalyseoversigt:

Vi kan se vSAN-tilstandsalarmen, der genereres i vCenter:

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
Fra vmware-vsan-health-summary-result.log kan vi se problemer med tilslutning af vSAN-sundhedsværten: 
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

SOM standard er PTAgent indstillet til at udføre en SCSI-enhed og bus-genscanne hvert 3. minut. Denne type forespørgsel er at søge efter nye diske eller andre hardwareenheder, der er tilsluttet serveren. Det er blevet udvidet til også at kontrollere andre blokenheder som f.eks. iSCSI. Grundlæggende kontrollerer vi den lokale HBA for at se, om der er tilføjet nye diske for nylig. 
ESXi-lagerstakken udfører også sin egen enhed og bus-genscanninger hvert 5. minut som standard og leder også efter den samme. En genscanning af en enhed og bus er en dyr handling fra et lagersynspunkt. Det kan resultere i, at visse dele af SCSI-bussen blokeres, mens de venter på, at handlingen fuldføres. Dette kan have en afslaget på, at der ventes på, at handlingen fuldføres, med øget ventetid. Hvis der allerede er mange lagerhandlinger på flyrejsen, kan det være nødvendigt at lade dem afslutte, før den kan gå til den nye scanning.

Vi har identificeret, at der er tidspunkter, hvor PTAgent og ESXi har genscanninger kørende på stort set samme tid. Dette kan resultere i en forsinkelse i et svar, mens genscanninger fuldføres, hvilket nogle gange udløser en vSAN-sundhedsalarm. vSAN-tilstand udløser ikke en alarm for en mislykket test, men den test, den kører, markeres som mislykket som timeout for vSAN-tilstandsforespørgslen.
Generelt er problemet et af timingen. vSAN-tilstand har en kort timeout for forespørgsler, der skal besvares, og har ingen prøv igen eller anden verificeringsmekanisme til at bekræfte en fejl. Genscanninger fra PTAgent og ESXi, der kører samtidigt (sammen med anden I/O i kø), kan resultere i en forsinkelse længe nok til, at det udløser timeout for vSAN-tilstand.

Resolution

Løsningen er at deaktivere PTAgent-genscanning og grundlæggende lade standard ESXi-lagerscanning være på plads. Dette anvender grundlæggende det samme genscan interval, som VMware bruger som standard med vSAN. Der er ingen risiko for data- eller I/O-handlinger med denne ændring. Det betyder, at genscanninger ikke sker så ofte, men diske, der tilføjes eller fjernes, er ikke noget, der er en almindelig forekomst. Hvis en disk tilføjes via hot-plug, har HBA en særlig logik, der informerer operativsystemet (ESXi) om, at der har været en diskændring. Andre gange vil du tilføje eller fjerne diske, når serveren er slukket, og en genscanninger er en del af startsekvensen. Der er nogle tilfælde, hvor parallel genscanninger kan være ønskelige. F.eks. replikeringsfailover eller nye diske, der er tilføjet fra et iSCSI-, FC- eller FCoE-system). Men failover-mekanismer som SRM har logik til at håndtere dette gennem yderligere genscanninger eller anvender funktioner i disse disktyper (som RSCN i FC). Ingen af disse scenarier bør være gældende i dette tilfælde, og selv når de er i spil, håndterer ESXi dem godt.

Omgå problemet:
BEMÆRK: Følgende adfærd er korrekt implementeret på PTAgent 1.9.2 og nyere. 

Kontrollér VxRail-produktbemærkningerne for PTAgent-versionen, der er inkluderet i den aktuelle version. 
1) Kontroller, om genscanninger faktisk stadig udløses:


[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) Sæt ESXi-værten i vedligeholdelsestilstand.

3) Deaktiver genscanninger ved at anvende disse kommandoer:


       # /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) Bekræft, at den er deaktiveret med

       # /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) Genstart PTAgent-tjenesten på noden med:


       # /etc/init.d/DellPTAgent restart
6) Afslut vedligeholdelsestilstand.

7) Gentag de samme trin for alle noder i klyngen.

Additional Information

Der er ingen lagerkapacitet eller funktionalitetsproblemer ved at deaktivere PTAgent-genscanning, da ESXi allerede gør det med regelmæssige intervaller.
Selv hvis in-band-enhedsscanningen er deaktiveret, vil PTAgent stadig scanne ved opstart. Hvis symptomet fortsat opstår, selv efter at du har deaktiveret scanningen, er det nødvendigt at undersøge årsagen til, at PTAgent genstartes gentagne gange.

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

Back to Top