VxRail: Anleitung zum Troubleshooting von NTP in einem VxRail-Cluster
Summary: Anleitung zum Troubleshooting von Problemen mit dem Network Time Protocol (NTP).
Instructions
/etc/ntp.conf direkt. Informationen zum Konfigurieren von NTP auf den Hosts finden Sie unter: https://knowledge.broadcom.com/external/article/313808
und https://knowledge.broadcom.com/external/article/313810/vsphere-esxi-70-u3-and-later-versions-nt.html
Verwenden Sie ntpq So überprüfen Sie den Synchronisationsstatus über 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
Hinweis: Wenn NTP einwandfrei funktioniert, sollte das Ergebnis wie folgt lauten 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,
Wenn die Reichweite nicht "yes" lautet und die Bedingung nicht sys.peer lautet (was bedeutet, dass bei der Zeitsynchronisation ein Problem vorliegt), überprüfen Sie die lokale Zeit und die NTP-Serverzeit. Wenn die Ortszeit größer oder kleiner als 1000 Sekunden ist, stellt ntpd die Uhr nicht ein. Die Uhrzeit muss manuell eingestellt werden.
Der folgende Status zeigt den ungewöhnlichen Synchronisationsstatus an:
vrm:~ # ntpq -c assoc ind assid status conf reach auth condition last_event cnt =========================================================== 1 58280 8011 yes no none reject mobilize 1
Die Spalte reach=no bedeutet, dass der NTP-Server nicht auf die Anfrage antwortet oder das Netzwerk nicht verfügbar ist. Führen Sie eine Fehlerbehebung für das Netzwerk und den NTP-Server durch.
Szenario 1: Netzwerkproblem:
Verwenden Sie Ping, um zu überprüfen, ob der NTP-Server erreichbar ist, und befolgen Sie das Netzwerk-Troubleshooting, um dies zu überprüfen. Sobald das Netzwerkproblem bestätigt wurde, bitten Sie den Nutzer, sich an das Netzwerkteam zu wenden und zu bestätigen, dass das Netzwerkproblem behoben ist.
Szenario 2: Falsche NTP-IP oder Serviceproblem:
Wenn der NTP-Server pingbar ist, kann es sein, dass der Nutzer die falsche NTP-IP eingegeben hat oder dass ein Problem mit dem NTP-Dienst auftritt. Lassen Sie sich von dem/der NutzerIn bestätigen, dass die NTP-IP-Adresse korrekt ist, oder verwenden Sie einen anderen NTP-Server, wenn der/die NutzerIn über einen verfügt, und bitten Sie den/die NutzerIn, das Administratorteam zur Überprüfung einzubeziehen. Manchmal kann ein Serverneustart das Problem beheben, sodass wir diesen Weg ausprobieren können, wenn dies für den Benutzer akzeptabel ist.
Szenario 3: Windows NTP-Server:
Der Windows-Zeitdienst implementiert ein NTP ohne vollen Funktionsumfang. Wenn der Benutzer einen Windows-Server als NTP-Server verwendet, wird die rootdisp kann höher als 1000 sein. Konfigurieren Sie in diesem Fall den Windows NTP-Server so, dass ein zuverlässiger externer NTP-Server synchronisiert wird.
Wenn die reach=yesaber condition=rejectgebrauchen ntpq möglicherweise nicht mit assoc und rv So überprüfen Sie die flash code, dispersionund rootdisp.
vrm:~ # ntpq -c assoc ind assid status conf reach auth condition last_event cnt =========================================================== 1 3898 9014 yes yes none reject reachable 1
Hinweis: Die Spalte assoc kann die assid die für die rv später.
Verwenden Sie die Funktion rv Befehl zum Abrufen der flash code, dispersionund rootdispaus.
Führen Sie den Befehl ntpq Befehl zum Eingeben der ntpq Shell, und verwenden Sie dann rv assid , um die detaillierten Informationen zu erhalten.
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 gibt an, dass die Entfernung zum Stamm-NTP-Server zu groß ist. Es ist nicht für die Synchronisierung geeignet.
Weitere Informationen zu Flash-Code finden Sie unter folgendem Link:
https://www.eecis.udel.edu/~mills/ntp/html/decode.html#flashAllgemein dispersion Ein Wert über 1000 gilt als ungeeigneter NTP-Server. Wenn der Windows NTP-Server so konfiguriert ist, dass die Zeit mit sich selbst synchronisiert wird, oder die Parameter nicht korrekt konfiguriert sind, wird das rootdisp höher als 1000 ist, muss die NTP-Konfiguration in Windows Server korrigiert werden.
Informationen zum Konfigurieren des Windows-Zeitservers finden Sie im folgenden Microsoft KB-Artikel.
https://support.microsoft.com/en-us/help/816042/how-to-configure-an-authoritative-time-server-in-windows-serverAnmerkung: Änderung MaxPosPhaseCorrection, MaxNegPhaseCorrection und SpecialPollInterval bis 300 Sekunden
Szenario 4: Instabiles Netzwerk zwischen NTP-Server und externem NTP-Server:
Befolgen Sie das Netzwerk-Troubleshooting, um das Netzwerk zu überprüfen. Sie können Ping verwenden, um zu überprüfen, ob eine hohe Latenz vorliegt.