VxRail : La vue physique ne s’affiche pas car le nœud ne répond pas à la commande « esxcli »

Summary: Vue physique du nœud de cluster VxRail manquante, le nœud ne répond pas à la commande « esxcli », NTP n’est pas synchronisé.

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.

Symptoms

  1. Les vues physiques de tous les nœuds sont manquantes.
    À partir de web.log, la passerelle API a expiré au bout de 10 minutes de récupération des données de la vue physique :

    2023-11-20T09:24:31.039Z <7527c8d153655e9bbb43b32dcd312443> marvin [ERROR] <261> ApplianceServiceImpl.java populatePvCache() (276): failed to fetch data.
    javax.ws.rs.ServerErrorException: HTTP 504 Gateway Time-out
    	at org.glassfish.jersey.client.JerseyInvocation.createExceptionForFamily(JerseyInvocation.java:1125) ~[jersey-client-2.27.jar:?]
    	at org.glassfish.jersey.client.JerseyInvocation.convertToException(JerseyInvocation.java:1105) ~[jersey-client-2.27.jar:?]
    	at org.glassfish.jersey.client.JerseyInvocation.translate(JerseyInvocation.java:883) ~[jersey-client-2.27.jar:?]
    	at org.glassfish.jersey.client.JerseyInvocation.lambda$invoke$1(JerseyInvocation.java:767) ~[jersey-client-2.27.jar:?]
    	at org.glassfish.jersey.internal.Errors.process(Errors.java:316) ~[jersey-common-2.27.jar:?]
    	at org.glassfish.jersey.internal.Errors.process(Errors.java:298) ~[jersey-common-2.27.jar:?]
    	at org.glassfish.jersey.internal.Errors.process(Errors.java:229) ~[jersey-common-2.27.jar:?]
    	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:414) ~[jersey-common-2.27.jar:?]
    	at org.glassfish.jersey.client.JerseyInvocation.invoke(JerseyInvocation.java:765) ~[jersey-client-2.27.jar:?]
    	at org.glassfish.jersey.client.JerseyInvocation$Builder.method(JerseyInvocation.java:456) ~[jersey-client-2.27.jar:?]
    	at org.glassfish.jersey.client.JerseyInvocation$Builder.post(JerseyInvocation.java:357) ~[jersey-client-2.27.jar:?]
    	at com.vce.commons.domainowner.graphq.DefaultQueryExecutorImpl.doJsonRequestExecution(DefaultQueryExecutorImpl.java:139) ~[commons-7.0.480.jar:?]
    	at com.vce.commons.domainowner.graphq.DefaultQueryExecutorImpl.execute(DefaultQueryExecutorImpl.java:94) ~[commons-7.0.480.jar:?]
    	at com.emc.mystic.manager.graphql.client.host.HostQuery.configuredHosts(HostQuery.java:138) ~[do-host-graphql-client-1.20.41.jar:?]
    	at com.emc.mystic.manager.graphql.client.host.HostQuery.configuredHosts(HostQuery.java:102) ~[do-host-graphql-client-1.20.41.jar:?]
    	at com.vce.commons.domainowner.node.NodeRepository.getAllClusterNodeData(NodeRepository.java:1997) ~[commons-7.0.480.jar:?]
    	at com.emc.mystic.manager.cluster.service.ApplianceServiceImpl.getAllHostData(ApplianceServiceImpl.java:543) ~[classes/:?]
    	at com.emc.mystic.manager.cluster.service.ApplianceServiceImpl.populatePvCache(ApplianceServiceImpl.java:260) ~[classes/:?]
    	at com.emc.mystic.manager.cluster.service.ApplianceServiceImpl.lambda$updateCacheTask$6(ApplianceServiceImpl.java:320) ~[classes/:?]
    	at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
    	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
    	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
    	at java.lang.Thread.run(Thread.java:829) [?:?]
    2023-11-20T09:24:31.045Z <7527c8d153655e9bbb43b32dcd312443> marvin [INFO] <261> ApplianceServiceImpl.java lambda$updateCacheTask$6() (321): Success to refresh cache for node: <node SN>
    2023-11-20T09:24:31.046Z <7527c8d153655e9bbb43b32dcd312443> marvin [INFO] <59> ApplianceDataRoot.java refreshVxRailClusterTag() (289): Skip refreshing VxRail-Cluster-Tag triggered by scheduled job as it has already been done within 15 minutes.
    2023-11-20T09:24:31.046Z <7527c8d153655e9bbb43b32dcd312443> marvin [INFO] <59> ApplianceDataRoot.java fetchData() (357): [VXMPERF] PV fetch data execution time in 602 seconds
    
  2. Exécutez la commande ci-dessous sur VxRail Manager pour interroger les données de la vue physique du nœud :

    #curl -X GET --unix-socket /var/lib/vxrail/nginx/socket/nginx.sock http://127.0.0.1/rest/vxm/internal/do/v1/host/query -H 'Content-Type: application/json' -d '{"query":"{ configuredHosts { hardware { sn } } }"}' 2>/dev/null | jq | egrep "name|sn" | awk -F\" '/sn/{print $4}' | sort -u | while read sn; do time curl -X POST --unix-socket /var/lib/vxrail/nginx/socket/nginx.sock -H 'Content-Type: application/json' -d '{"variables":"{\"sn\":\"'${sn}'\"}","query":"query ($sn:[String]){ configuredHosts(sn:$sn) { moid name type summary{ hardware{ cpuNum}} config{ hostUUID isPrimary network{ vnic{ device ipv4 allIpv6s nonLinkLocalIpv6} idrac{ ipAddress ipAddressSource netmask gateway ipAddressV6 gatewayV6 prefixLen ipv6AutoConfig vlan{ enabled id priority}}} localSlotClaims{ slot bay type usage diskgroupId} diskgroup{ slotNum current{ type}} installedComponent{ displayName version model description installedTime}} runtime{ connectionState overallStatus powerState inMaintenanceMode} hardware{ sn psnt slot manufacturer name systemStatusLed tpm model firmware{ id model} firmwareRevisions{ idsdmFwRevision biosFwRevision bmcFwRevision diskCtrlFwRevision bossFwRevision cpldFwRevision expanderBackplane nonExpanderBackplane dcpmFwRevision percDiskCtrlFwRevision} baseline{ sn slot chassisId isMissing} chassis{ name model psnt partNumber serviceTag psus{ sn name slot manufacturer partNumber firmwareVersion baseline{ sn slot isMissing}}} disks{ sn guid capacity slot firmwareVersion diskType diskState manufacturer protocol maxCapableSpeed model ledStatus writeEndurance bay enclosure remainingWriteEnduranceRate encryptionAbility encryptionStatus baseline{ sn slot bay isMissing}} bootDevices{ sn firmwareVersion sataType powerOnHours powerCycleCount avrEraseCount maxEraseCount capacity deviceModel slot health bootDeviceType status blockSizeBytes partNumber manufacturer controllerFirmware controllerModel controllerStatus raidStatus} nics{ mac linkSpeed firmwareFamilyVersion linkStatus fqdd specificNicType wwnn wwpn drivers{ driverName driverVersion}} position{ rackName rackSlot} storageInstance{ securityStatus encryptionMode}}} }","operationName":null}' http://0/rest/vxm/internal/do/v1/host/query; echo ""; echo ""; echo "Done checking $sn"; done
  3. Résultat indiquant qu’un ou plusieurs nœuds n’ont pas renvoyé les données dans les 10 minutes :
    Les nœuds en question présentent l’erreur « 504 Gateway Time-out » alors que les nœuds en cours de fonctionnement ont des données de vue physique correctes renvoyées.
    Résultats indiquant qu’un ou plusieurs nœuds n’ont pas renvoyé les données dans un délai de 10 minutes

  4. En vous basant sur le numéro de série du nœud identifié ci-dessus, connectez-vous au nœud et exécutez esxcli , elle est restée bloquée mais localcli fonctionne :
    Exécutez la commande esxcli et elle se bloque, mais localcli fonctionne

 

Cause

Le nœud présentait un problème de synchronisation NTP entraînant le esxcli La commande est bloquée et aucune réponse.

Appels de la vue physique VxRail esxcli commandes sur le nœud pour récupérer les informations sur le firmware, il ne parvient pas à obtenir les informations lorsque le nœud est bloqué en cours d’exécution esxcli .

 

Resolution

La solution consiste à identifier le problème de synchronisation NTP sur tous les nœuds et à le résoudre. Reportez-vous aux étapes ci-dessous pour vérifier l’état du NTP sur les nœuds :

  1. Vérifiez dans le répertoire /var/log/vobd.log s’il y a des messages d’erreur indiquant que l’horloge système n’est plus synchronisée avec les serveurs de temps en amont.

  2. Si c’est le cas, vérifiez l’état du serveur NTP.

    #ntpq -p

    Exemple de commande ntpq -p

    Si la valeur « reach » n’est pas 377, l’hôte manque une transaction NTP, l’heure sur cet ESXi peut être incorrecte et nécessite une attention particulière.

    #ntpq -c

    Exemple de commande ntpq -c

    Si la valeur « stratum » se situe en dehors de la plage de 2 à 6, la synchronisation de l’heure sur cet ESXi peut subir des retards supplémentaires, ce qui peut entraîner un suivi horaire inexact.

  3. Vérifiez si l’adresse du serveur NTP dans la base de données VxRail Manager est correcte avec l’API.

    curl -k --user "[vCenter account]:[vCenter password]" --request GET "https://localhost/rest/vxm/v1/system/ntp"
  4. Si ce n’est pas le cas, suivez les procédures existantes (Procédures VxRail → Divers → Procédures d’utilisation → Modifier les adresses IP VxRail → Repointer vers une nouvelle adresse IP du serveur NTP) pour mettre à jour l’adresse IP du serveur NTP.

  5. Utilisez un autre serveur NTP en état de marche si nécessaire, redémarrez le vpxa du nœud et les services de l’hôte. Notez que le redémarrage du vpxa du nœud et des services de l’hôte résoudra temporairement le problème, mais que le problème réapparaîtra si NTP ne parvient pas à se synchroniser à nouveau.

    /etc/init.d/vpxa restart
    /etc/init.d/hostd restart

 

Affected Products

VxRail
Article Properties
Article Number: 000224344
Article Type: Solution
Last Modified: 24 May 2024
Version:  2
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.