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 Health informa ocasionalmente mensajes de "Hosts con problemas de comunicación"

Summary: Los hosts ESXi dentro de un clúster VSAN de VxRail pueden experimentar problemas de conexión temporales y, como resultado, el estado de VSAN puede informar mensajes de error de "Hosts con problemas de comunicación". ...

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

De vez en cuando, los hosts pueden informar problemas de conexión. Los hosts permanecerán conectados, pero la evaluación del estado de vSAN puede mostrar periódicamente hosts aleatorios con problemas de comunicación. Si se vuelve a probar el estado de VSAN, el problema desaparece, pero volverá después de un par de minutos.

Versiones afectadas:
Hasta ahora, vemos que las versiones 4.5.x y 4.7.x de VxRail se ven afectadas. 

Resumen de análisis de registros:

Podemos ver que la alarma de estado de vSAN se genera y se muestra en 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
En vmware-vsan-health-summary-result.log , podemos ver problemas de conexión del host de estado de 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

PtAgent está configurado de manera predeterminada para realizar una reexaminación de bus y un dispositivo SCSI cada 3 minutos. Este tipo de consulta es para buscar discos nuevos u otros dispositivos de hardware conectados al servidor. Se extendió para comprobar también otros dispositivos de bloque, como iSCSI. Esencialmente, estamos comprobando el HBA local para ver si se han agregado nuevos discos recientemente. 
La pila de almacenamiento de ESXi también realiza su propio dispositivo y reexaminación de bus cada 5 minutos de manera predeterminada y también busca lo mismo. Una reexaminación de dispositivo y bus es una operación costosa desde el punto de vista del almacenamiento. Esto puede provocar que ciertas partes del bus SCSI se bloqueen a la espera de que se complete la operación. Esto puede tener un impacto en el aumento de la latencia a la espera de que se complete la operación. Si ya hay muchas operaciones de almacenamiento en transferencia, es posible que deba dejarlas terminar antes de que puedan ir a la reexaminación.

Hemos identificado que hay ocasiones en que PTAgent y ESXi han reexaminado la ejecución esencialmente al mismo tiempo. Esto puede provocar un retraso en una respuesta mientras se completan las reexaminaciones, lo que ocasionalmente activa una alarma de estado de vSAN. El estado de vSAN no activa una alarma para una prueba fallida, pero la prueba que está ejecutando se marca como fallida, ya que se agota el tiempo de espera de la consulta de estado de vSAN.
En general, el problema es uno de los tiempos. El estado de vSAN tiene un tiempo de espera breve para que las consultas respondan y no tiene ningún reintento u otro mecanismo de verificación para confirmar una falla. El reexaminar desde PTAgent y ESXi que se ejecuta simultáneamente (junto con otras I/O en línea de espera) puede provocar una demora lo suficientemente prolongada como para activar el tiempo de espera agotado de estado de vSAN.

Resolution

La solución alternativa es deshabilitar el reexaminar PTAgent y, esencialmente, dejar el almacenamiento ESXi predeterminado reexaminado en su lugar. Básicamente, esto utiliza el mismo intervalo de reexaminación que VMware utiliza de manera predeterminada con vSAN. No hay riesgo para los datos ni las operaciones de I/O con este cambio. Esto significa que la reexaminación no se producirá con tanta frecuencia, pero los discos que se agregan o eliminan no son algo común. Si se agrega un disco a través de la conexión en caliente, el HBA tiene una lógica especial para informar al sistema operativo (ESXi) que se ha producido un cambio de disco. Otras veces que agregaría o quitaría discos cuando el servidor está apagado y una reexaminación es parte de la secuencia de arranque. Hay algunos casos en los que es posible que las reexaminaciones paralelas sean convenientes. Como la conmutación por error de replicación o los discos nuevos agregados desde un arreglo iSCSI, FC o FCoE). Sin embargo, los mecanismos de conmutación por error, como SRM, tienen lógica para manejar esto a través de reexaminaciones adicionales o están utilizando funciones de esos tipos de discos (como RSCN en FC). Ninguno de esos escenarios debe ser aplicable en este caso e incluso cuando están en juego, ESXi los maneja bien.

Solución alternativa:
NOTA: El siguiente comportamiento se implementa correctamente en PTAgent 1.9.2 y versiones posteriores. 

Compruebe las notas de la versión de VxRail para la versión de PTAgent incluida en la versión actual. 
1) Compruebe si las reexaminaciones aún se están activando:


[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) Coloque el host ESXi en modo de mantenimiento.

3) Deshabilite la reexaminación mediante la aplicación de estos comandos:


       # /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) Confirme que está deshabilitado 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) Reinicie el servicio PTAgent en el nodo con lo siguiente:


       # /etc/init.d/DellPTAgent restart
6) Salga del modo de mantenimiento.

7) Repita los mismos pasos para todos los nodos del clúster.

Additional Information

No hay problemas de funcionalidad ni funcionalidad de almacenamiento desactivando el reexaminar PTAgent, ya que ESXi ya lo hace a intervalos regulares.
Incluso si el análisis de dispositivos en banda está deshabilitado, PTAgent seguirá escaneando durante el inicio. Si el síntoma continúa ocurriendo incluso después de deshabilitar el análisis, es necesario analizar el motivo por el cual PTAgent se reinicia repetidamente.

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