VxRail : Comment dépanner NTP dans un cluster VxRail
Summary: Comment résoudre les problèmes NTP (Network Time Protocol).
Instructions
/etc/ntp.conf directement. Pour configurer NTP sur les hôtes, reportez-vous à la section https://knowledge.broadcom.com/external/article/313808
et https://knowledge.broadcom.com/external/article/313810/vsphere-esxi-70-u3-and-later-versions-nt.html
À utiliser ntpq Pour vérifier l’état de synchronisation à partir de VxRail Manager :
vrm:~ # ntpq -c assoc ind assid status conf reach auth condition last_event cnt =========================================================== 1 3898 961a yes yes none sys.peer sys_peer 1
Remarque : Si le NTP fonctionne correctement, le résultat doit être reach=yes, condition=sys.peer.
ntpq> rv 3898 associd=3898 status=961a conf, reach, sel_sys.peer, 1 event, sys_peer, srcadr=10.XX.1XX.1X0, srcport=123, dstadr=10.XX.1XX.1X1, dstport=123, leap=00, stratum=12, precision=-6, rootdelay=31.250, rootdisp=64.575, refid=10.62.68.236, reftime=e0d00ab8.2af01902 Wed, Jul 10 2019 6:56:56.167, rec=e0d00c5e.d78d706e Wed, Jul 10 2019 7:03:58.842, reach=377,
Si la portée n’est pas yes et que la condition n’est pas sys.peer (ce qui signifie que la synchronisation de l’heure présente un problème), vérifiez l’heure locale et l’heure du serveur NTP. Si l’heure locale est supérieure ou inférieure à 1000 secondes, ntpd ne règle pas l’horloge. L’heure doit être réglée manuellement.
L’état suivant indique un état de synchronisation anormal :
vrm:~ # ntpq -c assoc ind assid status conf reach auth condition last_event cnt =========================================================== 1 58280 8011 yes no none reject mobilize 1
La commande reach=no signifie que le serveur NTP ne répond pas à la demande ou que le réseau n’est pas disponible. Dépannez le réseau et le serveur NTP.
Scénario 1 : Problème réseau :
Utilisez ping pour vérifier si le serveur NTP est accessible et suivez les instructions de dépannage réseau pour vérifier. Une fois le problème réseau confirmé, demandez à l’utilisateur de contacter l’équipe réseau et confirmez que le problème réseau est résolu.
Scénario 2 : Adresse IP NTP incorrecte ou problème de service :
Si le serveur NTP peut faire l’objet d’une commande ping, il se peut que l’utilisateur saisisse une adresse IP NTP incorrecte ou que le service NTP rencontre un problème. Vérifiez auprès de l’utilisateur que l’adresse IP NTP est correcte ou utilisez un autre serveur NTP si l’utilisateur en possède un, et demandez à l’utilisateur de contacter son équipe d’administration pour vérifier. Parfois, un redémarrage du serveur peut résoudre le problème. Nous pouvons donc essayer cette voie, si cela est acceptable pour l’utilisateur.
Scénario 3 : Serveur NTP Windows :
Le service de temps Windows implémente un NTP non complet. Si l’utilisateur utilise un serveur Windows en tant que serveur NTP, le rootdisp peut être supérieur à 1000. Dans ce cas, configurez le serveur NTP Windows pour synchroniser un serveur NTP externe fiable.
Si la demande reach=yesmais condition=rejectutiliser ntpq par assoc et rv pour vérifier le flash code, dispersionet rootdisp.
vrm:~ # ntpq -c assoc ind assid status conf reach auth condition last_event cnt =========================================================== 1 3898 9014 yes yes none reject reachable 1
Remarque : La commande assoc peut afficher l’option assid ce qui est nécessaire pour rv plus tard.
Utilisez l’option rv pour obtenir la commande flash code, dispersionet rootdisp.
Exécutez la commande ntpq pour entrer dans le champ ntpq shell, puis utilisez rv assid pour obtenir des informations détaillées.
ntpq ntpq> rv 3898 associd=3898 status=9014 conf, reach, sel_reject, 1 event, reachable, srcadr=10.XX.1XX.1X0, srcport=123, dstadr=10.XX.1XX.1X1, dstport=123, leap=00, stratum=12, precision=-6, rootdelay=31.250, rootdisp=1814.209, refid=10.XX.XX.2X6, reftime=e0cff348.12fb407d Wed, Jul 10 2019 5:16:56.074, rec=e0cff42b.60680b73 Wed, Jul 10 2019 5:20:43.376, reach=377, unreach=0, hmode=3, pmode=4, hpoll=6, ppoll=6, headway=50, flash=400 peer_dist, keyid=0, offset=-2536.264, delay=0.354, dispersion=16.515, jitter=4.414, xleave=0.038, filtdelay= 0.35 0.29 0.32 0.26 0.28 3.22 0.28 0.35, filtoffset= -2536.2 -2538.2 -2529.4 -2536.2 -2541.6 -2530.0 -2532.5 -2538.1, filtdisp= 15.63 16.63 17.59 18.55 19.53 20.53 21.52 22.50 flash=400 peer_dist #reject reason dispersion=16.515 #it presents the error/variance between that NTP server and client rootdisp=1814.209 #it presents the total amount of error/variance from the root NTP server to client
flash=400 peer_dist indique que la distance jusqu’au serveur NTP racine est trop longue. Il est impropre à la synchronisation.
Pour plus d’informations sur le code de voyant, cliquez sur le lien suivant :
https://www.eecis.udel.edu/~mills/ntp/html/decode.html#flashGénéralement dispersion supérieur à 1 000 est considéré comme un serveur NTP inapte. Si le serveur Windows NTP est configuré pour synchroniser l’heure avec lui-même, ou si les paramètres ne sont pas configurés correctement, le rootdisp est supérieur à 1 000 et la configuration NTP dans Windows Server doit être corrigée.
Reportez-vous à l’article suivant de la base de connaissances Microsoft pour configurer le serveur de temps Windows.
https://support.microsoft.com/en-us/help/816042/how-to-configure-an-authoritative-time-server-in-windows-serverNote: Changement MaxPosPhaseCorrection, MaxNegPhaseCorrection et SpecialPollInterval à 300 secondes
Scénario 4 : Réseau instable entre le serveur NTP et le serveur NTP externe :
Suivez le dépannage réseau pour vérifier le réseau. Vous pouvez utiliser ping pour vérifier s’il y a une latence élevée.