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.

Dell EMC VxRail: vSAN Health rapporterar ibland meddelanden om "värdar med kommunikationsproblem"

Summary: ESXi-värdar i ett VxRail VSAN-kluster kan få tillfälliga anslutningsproblem och VSAN-hälsan kan ge felmeddelandena "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

Då och då kan värdar rapportera anslutningsproblem. Värdar förblir anslutna, men vSAN-hälsokontrollen kan regelbundet visa slumpmässiga värdar med kommunikationsproblem. Om VSAN-hälsan testas på nytt försvinner problemet men återkommer efter ett par minuter.

Berörda versioner:
Hittills har VxRail-versionerna 4.5.x och 4.7.x påverkats. 

Sammanfattning av logganalys:

VSAN-hälsolarm genereras 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
I vmware-vsan-health-summary-result.log kan vi se problem med vSAN-hälsovärdanslutning:
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 är PTAgent inställd på att utföra en SCSI-enhet och genomsöka bussen var tredje minut. Den här typen av fråga är att söka efter nya diskar eller andra maskinvaruenheter som är anslutna till servern. Det har utökats för att även kontrollera andra blockenheter, till exempel iSCSI. I princip kontrollerar vi den lokala värdbussadapterenheten för att se om några nya diskar har lagts till nyligen. 
ESXi-lagringsstacken utför även en egen enhets- och bussomsökning var femte minut som standard också söker efter samma sak. En enhets- och bussomsökning är en dyr åtgärd ur lagringssynpunkt. Det kan leda till att vissa delar av SCSI-bussen blockeras i väntan på att åtgärden slutförs. Det kan påverka den ökade fördröjningen i väntan på att åtgärden slutförs. Om det redan pågår många lagringsåtgärder kan de behöva slutföras innan de kan gå vidare till genomsökningen.

Vi har upptäckt att det finns tillfällen då PTAgent och ESXi kör rescans samtidigt. Det kan leda till fördröjning i ett svar när genomsökningarna slutförs, vilket ibland utlöser ett vSAN-hälsolarm. vSAN-tillstånd utlöser inte ett larm för ett misslyckat test, men testet som körs markeras som misslyckat eftersom vSAN-hälsofrågan överser tidsgränsen.
Överlag är problemet en tidsinställning. vSAN-tillstånd har kort tidsgräns för svar på frågor och har inga försök eller någon annan verifieringsmekanism för att bekräfta ett fel. Omsökningen från PTAgent och ESXi körs samtidigt (tillsammans med andra I/O i kö) kan resultera i en fördröjning som utlöser tidsgränsen för vSAN-tillstånd.

Resolution

Lösningen är att avaktivera PTAgent-genomsökningen och praktiskt taget lämna standard-ESXi-lagringssökningen på plats. Detta använder i princip samma genomsökningsintervall som VMware använder som standard med vSAN. Det finns ingen risk för data- eller I/O-åtgärder med den här ändringen. Det innebär att genomsökningen inte sker lika ofta, men att diskar som läggs till eller tas bort inte är något som är vanligt. Om en disk läggs till via snabbkoppling har HBA en särskild logik för att informera operativsystemet (ESXi) om att disken har ändrats. Andra gånger som du lägger till eller tar bort diskar när servern är avstängd och en omskanning är en del av startsekvensen. Det finns vissa fall där parallella genomsökningar kan vara önskvärda. Till exempel replikerings-failover eller nya diskar som lagts till från ett iSCSI-, FC- eller FCoE-disksystem). Failover-mekanismer, t.ex. SRM, har logik för att hantera detta genom ytterligare genomsökningar eller använder funktioner i dessa disktyper (t.ex. RSCN i FC). Inget av dessa scenarier bör vara tillämpliga i det här fallet och även när de är i spel hanterar ESXi dem väl.

Tillfällig lösning:
Obs! Följande beteende implementeras korrekt på PTAgent 1.9.2 och senare. 

Kontrollera versionskommentarerna för VxRail för PTAgent-versionen som ingår i den aktuella versionen.
1) Kontrollera om genomsökningar verkligen fortfarande utlö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ätt ESXi-värden i underhållsläge.

3) Avaktivera genomsökningen genom att använda följande kommandon:

       # /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) Kontrollera att den är avaktiverad 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) Starta om PTAgent-tjänsten på noden med:

       # /etc/init.d/DellPTAgent restart
6) Avsluta underhållsläget.

7) Upprepa samma steg för alla noder i klustret.



Additional Information

Det finns inga lagringskapacitets- eller funktionsproblem genom att stänga av PTAgent-genomsökningen eftersom ESXi gör det redan regelbundet.
Även om in-band-enhetsskanningen är avaktiverad skannar PTAgent fortfarande vid start. Om symptomet kvarstår även efter att skanningen har avaktiverats är det nödvändigt att titta på orsaken till att PTAgent startas om upprepade gånger.

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