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 signale parfois des messages « Hosts with communication issues » (Hôtes présentant des problèmes de communication)

Summary: Les hôtes ESXi au sein d’un cluster VxRail VSAN peuvent rencontrer des problèmes de connexion temporaires et, en conséquence, l’intégrité VSAN peut signaler des messages d’erreur « Hôtes présentant des problèmes de communication ». ...

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 temps à autre, les hôtes peuvent signaler des problèmes de connexion. Les hôtes restent connectés, mais le contrôle d’intégrité vSAN peut afficher régulièrement des hôtes aléatoires présentant des problèmes de communication. Si l’intégrité VSAN est de nouveau testée, le problème disparaît, mais revient au bout de quelques minutes.

Versions concernées:
Jusqu’à présent, les versions 4.5.x et 4.7.x de VxRail sont concernées. 

Récapitulatif de l’analyse des logs:

L’alarme d’intégrité vSAN générée s’affiche dans 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
À partir de vmware-vsan-health-summary-result.log , nous pouvons voir les problèmes de connexion de l’hôte d’intégrité 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

Par défaut, PTAgent est défini pour effectuer un périphérique SCSI et relancer l’analyse du bus toutes les 3 minutes. Ce type de requête consiste à rechercher de nouveaux disques ou d’autres périphériques matériels connectés au serveur. Il a été étendu pour vérifier également d’autres périphériques en mode bloc tels que iSCSI. Nous vérifions essentiellement l’adaptateur HBA local pour voir si de nouveaux disques ont été ajoutés récemment. 
Par défaut, la pile de stockage ESXi effectue également son propre périphérique et le bus effectue une nouvelle analyse toutes les 5 minutes. Une nouvelle analyse des périphériques et des bus est une opération coûteuse du point de vue du stockage. Cela peut entraîner le blocage de certaines parties du bus SCSI en attendant la fin de l’opération. Cela peut avoir un impact sur l’impact de l’augmentation de la latence en attendant la fin de l’opération. S’il y a déjà beaucoup d’opérations de stockage en cours de transfert, il peut être nécessaire de les laisser terminer avant de pouvoir passer à la nouvelle analyse.

Nous avons constaté qu’il arrive que PTAgent et ESXi effectuent de nouveau des analyses en même temps. Cela peut entraîner un retard dans une réponse pendant la fin des nouvelles analyses, ce qui déclenche parfois une alarme d’intégrité vSAN. L’intégrité de vSAN ne déclenche pas d’alarme pour un test en échec, mais le test qu’il exécute est marqué comme étant en échec, car la requête d’intégrité vSAN a expiré.
Dans l’ensemble, le problème est lié au timing. L’intégrité vSAN a un court délai d’expiration pour que les requêtes répondent et n’a pas de nouvelle tentative ou d’autre mécanisme de vérification pour confirmer une panne. La nouvelle analyse à partir de PTAgent et ESXi s’exécutant simultanément (ainsi que d’autres E/S en file d’attente) peut entraîner un délai suffisamment long pour déclencher le délai d’expiration de l’intégrité vSAN.

Resolution

La solution de contournement consiste à désactiver la nouvelle analyse PTAgent et à laisser la nouvelle analyse du stockage ESXi par défaut en place. Il s’agit essentiellement de l’intervalle de rescan utilisé par défaut par VMware avec vSAN. Cette modification ne présente aucun risque pour les données ou les opérations d’E/S. Cela signifie que la nouvelle analyse ne se produira pas aussi fréquemment, mais que les disques ajoutés ou supprimés ne sont pas une occurrence courante. Si un disque est ajouté via une connexion à chaud, l’adaptateur HBA a une logique particulière pour informer le système d’exploitation (ESXi) qu’il y a eu une modification de disque. D’autres fois, vous devez ajouter ou supprimer des disques lorsque le serveur est hors tension et qu’une nouvelle analyse fait partie de la séquence de démarrage. Dans certains cas, des analyses parallèles peuvent être souhaitables. Tels que le basculement de la réplication ou les nouveaux disques ajoutés à partir d’une baie iSCSI, FC, FCoE). Mais les mécanismes de basculement, tels que SRM, ont une logique pour gérer cela via des analyses supplémentaires, ou utilisent des fonctionnalités de ces types de disques (comme RSCN dans FC). Aucun de ces scénarios ne doit être applicable dans ce cas et même lorsqu’ils sont en jeu, ESXi les gère correctement.

Contournement:
REMARQUE: le comportement suivant est correctement mis en œuvre sur PTAgent 1.9.2 et versions ultérieures. 

Consultez les notes de mise à jour de VxRail pour connaître la version PTAgent incluse dans la version actuelle. 
1) Vérifiez si les relances d’analyse continuent de se déclencher:


[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) Mettez l’hôte ESXi en mode maintenance.

3) Désactivez la nouvelle analyse en appliquant les commandes suivantes:


       # /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) Vérifiez qu’il est désactivé avec

       # /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) Redémarrez le service PTAgent sur le nœud avec:


       # /etc/init.d/DellPTAgent restart
6) Quittez le mode maintenance.

7) Répétez les mêmes étapes pour tous les nœuds du cluster.

Additional Information

Il n’y a pas de problème de capacité ou de fonctionnalité de stockage en désactivant PTAgent, car ESXi le fait déjà à intervalles réguliers.
Même si l’analyse intrabande de l’appareil est désactivée, PTAgent continue d’analyser au démarrage. Si le symptôme persiste même après la désactivation de l’analyse, il est nécessaire de rechercher la raison pour laquelle PTAgent est redémarré à plusieurs reprises.

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