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: o vSAN Health relata ocasionalmente mensagens "Hosts with communication issues"

Summary: Os hosts ESXi em um cluster VxRail VSAN podem apresentar problemas temporários de conexão e, como resultado, a integridade do VSAN pode relatar mensagens de erro "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

De tempos em tempos, os hosts podem relatar problemas de conexão. Os hosts permanecerão conectados, mas a verificação de integridade do vSAN pode mostrar periodicamente hosts aleatórios com problemas de comunicação. Se a integridade do VSAN for testada novamente, o problema desaparecerá, mas retornará após alguns minutos.

Versões afetadas:
Até agora, estamos vendo as versões 4.5.x e 4.7.x do VxRail serem afetadas. 

Resumo da análise de registros:

Podemos ver o alarme de integridade do vSAN sendo gerado exibido no 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
Em vmware-vsan-health-summary-result.log, podemos ver problemas de conexão do host de integridade do 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

Por padrão, o PTAgent é definido para executar um dispositivo SCSI e o barramento verifica novamente a cada 3 minutos. Esse tipo de consulta é procurar novos discos ou outros dispositivos de hardware conectados ao servidor. Ele foi estendido para também verificar outros dispositivos de block, como iSCSI. Essencialmente, estamos verificando o HBA local para ver se algum novo disco foi adicionado recentemente. 
A pilha de armazenamento do ESXi também executa seu próprio dispositivo e o barramento verifica novamente a cada 5 minutos, por padrão, também procurando o mesmo. Uma nova varredura de dispositivos e barramentos é uma operação cara do ponto de vista do armazenamento. Isso pode fazer com que determinadas partes do barramento SCSI sejam bloqueadas aguardando a conclusão da operação. Isso pode ter um impacto de aumento da latência aguardando a conclusão da operação. Se já houver muitas operações de armazenamento em trânsito, talvez seja necessário deixar que elas terminem antes que elas possam passar para a nova varredura.

Identificamos que há momentos em que o PTAgent e o ESXi analisam novamente em execução basicamente ao mesmo tempo. Isso pode resultar em um atraso em uma resposta enquanto as verificações são concluídas, o que ocasionalmente aciona um alarme de integridade do vSAN. A integridade do vSAN não está acionando um alarme para um teste com falha, mas o teste em execução é marcado como com falha conforme a consulta de integridade do vSAN timed out.
Em geral, o problema é um dos horários. A integridade do vSAN tem um tempo limite curto para que as consultas respondam e não tem nenhuma repetição ou outro mecanismo de verificação para confirmar uma falha. A nova varredura do PTAgent e do ESXi em execução simultaneamente (juntamente com outras E/S em fila) pode resultar em um atraso longo o suficiente para acionar o tempo limite de integridade do vSAN.

Resolution

A solução temporária é desativar a nova varredura do PTAgent e, essencialmente, deixar a verificação de armazenamento padrão do ESXi no lugar. Basicamente, isso está usando o mesmo intervalo de nova varredura que a VMware usa por padrão com o vSAN. Não há risco para os dados ou operações de E/S com essa alteração. Isso significa que a nova varredura não ocorrerá com a mesma frequência, mas os discos que estão sendo adicionados ou removidos não são uma ocorrência comum. Se um disco for adicionado por meio de conexão automática, o HBA tem uma lógica especial para informar ao sistema operacional (ESXi) que houve uma alteração no disco. Outras vezes que você adiciona ou remove discos quando o servidor está desligado e uma nova varredura faz parte da sequência de inicialização. Há alguns casos em que as varreduras paralelas podem ser desejáveis. Como failover de replicação ou novos discos adicionados a partir de um array iSCSI, FC e FCoE). Mas mecanismos de failover, como o SRM, têm lógica para lidar com isso por meio de novos testes adicionais ou estão usando recursos desses tipos de discos (como RSCN em FC). Nenhum desses cenários deve ser aplicável nesse caso e, mesmo quando eles estão em ação, o ESXi lida bem com eles.

Solução temporária:
NOTA: o seguinte comportamento é implementado corretamente no PTAgent 1.9.2 e versões posteriores. 

Verifique as notas da versão do VxRail para a versão do PTAgent incluída na versão atual. 
1) Verifique se as verificações novamente ainda estão acionando:


[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 o host do ESXi no modo de manutenção.

3) Desative a nova verificação aplicando estes 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 se ele está desativado com

       # /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 o serviço PTAgent no nó com:


       # /etc/init.d/DellPTAgent restart
6) Saia do modo de manutenção.

7) Repita as mesmas etapas para todos os nós do cluster.

Additional Information

Não há preocupações com funcionalidade ou capacidade de armazenamento desativando a nova varredura do PTAgent, pois o ESXi já faz isso em intervalos regulares.
Mesmo que a verificação do dispositivo em banda esteja desativada, o PTAgent ainda fará a varredura na inicialização. Se o sintoma continuar acontecendo mesmo depois de desativar a verificação, é necessário analisar o motivo pelo qual o PTAgent é reiniciado 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