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é.
Symptoms
-
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
-
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 -
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.

-
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 :

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 :
-
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.
-
Si c’est le cas, vérifiez l’état du serveur NTP.
#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

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.
-
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"
-
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.
-
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