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

Article Number: 000056125

Dell EMC VxRail: vSAN Health rapporterer av og til meldinger om «Verter med kommunikasjonsproblemer»

Summary: ESXi-verter i en VxRail VSAN-klynge kan oppleve midlertidige tilkoblingsproblemer, og som et resultat kan VSAN-tilstand rapportere feilmeldinger om «Verter med kommunikasjonsproblemer». ...

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 annen kan verter rapportere tilkoblingsproblemer. Verter forblir tilkoblet, men vSAN-helsesjekk kan med jevne mellomrom vise tilfeldige verter med kommunikasjonsproblemer. Hvis VSAN-tilstanden testes på nytt, forsvinner problemet, men kommer tilbake etter noen minutter.

Berørte versjoner:
Så langt ser vi at VxRail-versjonene 4.5.x og 4.7.x er berørt. 

Sammendrag av logganalyse:

Vi kan se vSAN-helsealarmen som 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 tilkobling av vSAN-tilstandsvert: 
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 angitt til å utføre en SCSI-enhet, og bussen kan søkes på nytt hvert tredje minutt. Denne typen spørring er å se etter nye disker eller andre maskinvareenheter som er koblet til serveren. Den har blitt utvidet til å også kontrollere andre blokkenheter, for eksempel iSCSI. I hovedsak sjekker vi den lokale HBA-en for å se om det nylig er lagt til nye disker. 
ESXi-lagringsstabelen utfører også sin egen enhet, og bussen kan skann på nytt hvert femte minutt som standard, og ser også etter det samme. En enhet og busskanne er en dyr operasjon fra et lagringssynspunkt. Det kan føre til at visse deler av SCSI-bussen blokkeres mens du venter på at operasjonen skal fullføres. Dette kan ha innvirkning på den økte ventetiden når du venter på at operasjonen skal fullføres. Hvis det allerede er mange lagringsoperasjoner i fly, kan det hende at de må fullføres før de kan gå til rescan.

Vi har funnet ut at PTAgent og ESXi noen ganger kjører på nytt samtidig. Dette kan føre til en forsinkelse i et svar mens reskannene fullføres, noe som av og til utløser en vSAN-helsealarm. vSAN-tilstand utløser ikke en alarm for en mislykket test, men testen den kjører, merkes som mislykket da vSAN-tilstandsspørringen ble tidsavbrutt.
Totalt sett er problemet én tidsberegning. vSAN-tilstand har en kort tidsavbrudd for forespørsler om å svare, og har ingen forsøk eller annen bekreftelsesmekanisme for å bekrefte en feil. Rescan fra PTAgent og ESXi som kjører samtidig (sammen med andre I/O i kø) kan føre til en forsinkelse lenge nok til at det utløser tidsavbrudd for vSAN-tilstand.

Resolution

Løsningen er å deaktivere PTAgent-rescan og i hovedsak la standard ESXi-lagring skann på plass. Dette bruker i hovedsak samme intervall for rescan som VMware bruker som standard med vSAN. Det er ingen risiko for data- eller I/U-operasjoner med denne endringen. Det betyr at rescan ikke vil forekomme så ofte, men disker som legges til eller fjernes, er ikke noe som er vanlig. Hvis en disk legges til via hotplug, har HBA spesiell logikk for å informere operativsystemet (ESXi) om at det har blitt endret en disk. Andre ganger vil du legge til eller fjerne disker når serveren er slått av, og en rescan er en del av oppstartssekvensen. Det finnes noen tilfeller der parallelle rescans kan være ønskelige. For eksempel replikerings-failover eller nye disker som er lagt til fra en iSCSI-, FC- og FCoE-matrise). Men failover-mekanismer som SRM, har logikk til å håndtere dette gjennom flere skannere eller bruker funksjonene til disse disktypene (for eksempel RSCN i FC). Ingen av disse scenariene bør gjelde i dette tilfellet, og selv når de er i spill, håndterer ESXi dem godt.

Løsning:
MERK: Følgende atferd er riktig implementert på PTAgent 1.9.2 og nyere. 

Sjekk VxRail-produktmerknadene for PTAgent-versjonen som er inkludert i den gjeldende versjonen. 
1) Kontroller om rescans faktisk fortsatt utløser:


[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) Sett ESXi-verten i vedlikeholdsmodus.

3) Deaktiver rescan ved å bruke disse kommandoene:


       # /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) Bekreft at den er deaktivert 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) Start PTAgent-tjenesten på nytt på noden med:


       # /etc/init.d/DellPTAgent restart
6) Avslutt vedlikeholdsmodus.

7) Gjenta samme trinn for alle noder i klyngen.

Additional Information

Det er ingen lagringskapasitet eller funksjonalitetsproblemer ved å slå av PTAgent rescan, ettersom ESXi allerede har det i seg selv med jevne mellomrom.
Selv om skanningen av enheten i bånd er deaktivert, vil PTAgent fortsatt skanne ved oppstart. Hvis symptomet fortsetter å skje selv etter at du har deaktivert skanningen, må du sjekke årsaken til at PTAgent startes på nytt gjentatte ganger.

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