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: l'integrità di vSAN segnala occasionalmente i messaggi "Host con problemi di comunicazione"

Summary: Gli host ESXi all'interno di un cluster VxRail VSAN potrebbero riscontrare problemi di connessione temporanei e, di conseguenza, l'integrità di VSAN potrebbe segnalare messaggi di errore "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

Di tanto in tanto, gli host possono segnalare problemi di connessione. Gli host rimarranno connessi, ma il controllo integrità di vSAN potrebbe mostrare periodicamente host casuali con problemi di comunicazione. Se viene eseguito un nuovo test dello stato di VSAN, il problema scompare ma si ripresentirà dopo un paio di minuti.

Versioni interessate:
Finora le versioni di VxRail 4.5.x e 4.7.x sono interessate. 

Riepilogo dell'analisi dei registri:

È possibile visualizzare l'avviso di integrità di vSAN in 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
Da vmware-vsan-health-summary-result.log possiamo vedere problemi di connessione dell'host integrità 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

Per impostazione predefinita, PTAgent è impostato per eseguire una nuova scansione del dispositivo e del bus SCSI ogni 3 minuti. Questo tipo di query consiste nel cercare nuovi dischi o altri dispositivi hardware collegati al server. È stato esteso anche per controllare altri dispositivi di blocco come iSCSI. In sostanza, stiamo verificando l'HBA locale per verificare se sono stati aggiunti di recente nuovi dischi. 
Per impostazione predefinita, lo stack di storage ESXi esegue anche la ripetizione della scansione del proprio dispositivo e del bus ogni 5 minuti. Una ripetizione dell'analisi di dispositivi e bus è un'operazione costosa dal punto di vista dello storage. Ciò può comportare il blocco di alcune parti del bus SCSI in attesa del completamento dell'operazione. Ciò può influire sull'impatto di una maggiore latenza in attesa del completamento dell'operazione. Se al volo sono già presenti numerose operazioni di storage, potrebbe essere necessario lasciarle terminare prima di poter passare alla ripetizione della scansione.

Abbiamo rilevato che in alcuni casi PTAgent ed ESXi hanno eseguito nuovamente le analisi essenzialmente allo stesso tempo. Ciò può causare un ritardo in una risposta durante il completamento delle nuove analisi, che occasionalmente attiva un allarme di integrità vSAN. L'integrità di vSAN non attiva un allarme per un test non riuscito, ma il test in esecuzione viene contrassegnato come non riuscito al timeout della query di stato vSAN.
Nel complesso, il problema è una delle tempistiche. Lo stato di vSAN ha un breve timeout per rispondere alle query e non dispone di alcun nuovo tentativo o altro meccanismo di verifica per confermare un guasto. La ripetizione dell'analisi da PTAgent ed ESXi in esecuzione contemporaneamente (insieme ad altre I/O in coda) può causare un ritardo sufficientemente lungo da attivare il timeout di integrità di vSAN.

Resolution

La soluzione alternativa consiste nel disabilitare ptAgent rescan e lasciare essenzialmente attiva la ripetizione dell'analisi dello storage ESXi predefinita. Si tratta essenzialmente di utilizzare lo stesso intervallo di ripetizione della scansione utilizzato per impostazione predefinita da VMware con vSAN. Non vi è alcun rischio per i dati o le operazioni di I/O con questa modifica. Ciò significa che la ripetizione dell'analisi non si verificherà con la frequenza richiesta, ma che i dischi da aggiungere o rimuovere non sono un evento comune. Se un disco viene aggiunto tramite hot plug, l'HBA ha una logica speciale per informare il sistema operativo (ESXi) che si è verificata una modifica del disco. Altre volte è possibile aggiungere o rimuovere dischi quando il server è spento e una nuova scansione fa parte della sequenza di avvio. In alcuni casi, potrebbe essere preferibile eseguire nuovamente l'analisi parallela. ad esempio il failover della replica o nuovi dischi aggiunti da un array iSCSI, FC, FCoE). Tuttavia, i meccanismi di failover come SRM dispongono della logica per gestire questo aspetto tramite nuove analisi aggiuntive o utilizzano le funzionalità di questi tipi di dischi (come RSCN in FC). Nessuno di questi scenari dovrebbe essere applicabile in questo caso e anche quando sono in gioco ESXi li gestisce bene.

Soluzione alternativa:
NOTA: il seguente comportamento è implementato correttamente su PTAgent 1.9.2 e versioni successive. 

Controllare le note di rilascio di VxRail per la versione DI PTAgent inclusa nella release corrente.
1) Verificare se le rescans sono ancora in fase di attivazione:

[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) Attivare la modalità di manutenzione dell'host ESXi.

3) Disabilitare la nuova scansione applicando questi comandi:

       # /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) Verificare che sia disattivata con
       # /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) Riavviare il servizio PTAgent sul nodo con:

       # /etc/init.d/DellPTAgent restart
6) Uscire dalla modalità di manutenzione.

7) Ripetere la stessa procedura per tutti i nodi del cluster.



Additional Information

Non ci sono problemi di funzionalità di storage disattivando PTAgent rescan poiché ESXi lo fa già a intervalli regolari.
Anche se la scansione del dispositivo in banda è disabilitata, PTAgent continuerà a eseguire la scansione all'avvio. Se il sintomo continua a verificarsi anche dopo aver disabilitato la scansione, è necessario esaminare il motivo per cui PTAgent viene riavviato ripetutamente.

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