VxRail: Slik feilsøker du NTP i en VxRail-klynge
Summary: Slik feilsøker du NTP-problemer (Network Time Protocol).
Instructions
/etc/ntp.conf direkte. Hvis du vil konfigurere NTP på vertene, kan du se: https://knowledge.broadcom.com/external/article/313808
Bruk ntpq Slik kontrollerer du synkroniseringsstatusen fra 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
Merk: Hvis NTP fungerer bra, bør resultatet være 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,
Hvis rekkevidden ikke er ja, og tilstanden ikke er sys.peer (som betyr at tidssynkroniseringen har problemer), kontrollerer du lokal tid og NTP-servertid. Hvis lokal tid er større eller mindre enn 1000 sekunder, vil ntpd ikke stille klokken. Tiden må stilles inn manuelt.
Følgende status viser statusen for unormal synkronisering:
vrm:~ # ntpq -c assoc ind assid status conf reach auth condition last_event cnt =========================================================== 1 58280 8011 yes no none reject mobilize 1
Informasjonen i reach=no betyr at NTP-serveren ikke svarer på forespørselen, eller at nettverket ikke er tilgjengelig. Feilsøk nettverket og NTP-serveren.
Scenario 1: Nettverksproblem:
Bruk ping for å sjekke om NTP-serveren er tilgjengelig, og følg nettverksfeilsøkingen for å sjekke. Når nettverksproblemet er bekreftet, ber du brukeren om å engasjere nettverksteamet og bekrefte at nettverksproblemet er løst.
Scenario 2: Feil NTP IP- eller tjenesteproblem:
Hvis NTP-serveren er pingbar, kan det være at brukeren legger inn feil NTP-IP eller NTP-tjenesten får problemer. Bekreft med brukeren at NTP IP-adressen er riktig, eller bruk en annen NTP-server hvis brukeren har en og bedt brukeren om å engasjere sitt adminteam for å sjekke. Noen ganger kan en omstart av serveren løse problemet, så vi kan prøve den ruten, hvis det er akseptabelt for brukeren.
Scenario 3: Windows NTP-server:
Windows time service implementerer en NTP uten alle funksjoner. Hvis brukeren bruker en Windows Server som NTP-server, kan rootdisp kan være høyere enn 1000. I så fall konfigurerer du Windows NTP Server til å synkronisere en pålitelig ekstern NTP-server.
Hvis reach=yesmen condition=rejectbruk ntpq med assoc og rv for å kontrollere flash code, dispersionog rootdisp.
vrm:~ # ntpq -c assoc ind assid status conf reach auth condition last_event cnt =========================================================== 1 3898 9014 yes yes none reject reachable 1
Merk: Informasjonen i assoc Alternativet kan vise assid som er nødvendig for rv senere.
Bruk rv kommandoen for å få flash code, dispersionog rootdisp.
Kjør ntpq Kommando for å angi ntpq skall, bruk deretter rv assid for å få detaljert informasjon.
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 indikerer at avstanden til rot-NTP-serveren er for lang. Det er uegnet til å synkronisere.
Finn mer informasjon om flash-kode fra følgende lenke:
https://www.eecis.udel.edu/~mills/ntp/html/decode.html#flashVanligvis dispersion høyere enn 1000 regnes som uegnet NTP-server. Hvis Windows NTP Server er konfigurert til å synkronisere tiden med seg selv, eller parametere ikke er riktig konfigurert, kan rootdisp er høyere enn 1000, og NTP-konfigurasjonen i Windows Server må korrigeres.
Se følgende Microsoft KB-artikkel for å konfigurere tidsserveren i Windows.
https://support.microsoft.com/en-us/help/816042/how-to-configure-an-authoritative-time-server-in-windows-serverNotat: Endring MaxPosPhaseCorrection, MaxNegPhaseCorrection og SpecialPollInterval til 300 sekunder
Scenario 4: Ustabilt nettverk mellom NTP-server og ekstern NTP-server:
Følg nettverksfeilsøking for å sjekke nettverket, Kan bruke ping for å sjekke om det er høy ventetid.