NTP/Chrony nu păstrează timpul sincronizat pe CentOS 7.9 (VM care rulează pe VMware ESXi)

Am 3 servere care rulează CentOS 7.9.2009 într-un centru de date (VMware ESXi). Aceste servere raportează că ora nu este sincronizată. Am un mediu de testare similar care rulează pe un server intern VMware ESXi unde serverele se sincronizează. timpul ok.Mediul de producție a fost configurat inițial exact în același mod - dar evident actualizat cu actualizări de pachet în timp. Deci ele „ar trebui” să fie identice - dar nu pot garanta asta. Serverele ESXi sunt ambele versiunea 6.

Serverele au fost inițial configurate folosind „ntpd” - dar când am remediat această problemă în ultimele două zile, am descoperit că „Chrony” pare a fi o alegere mai bună pe CentOS 7. Prin urmare, am reconfigurat serverele pentru a utiliza Chrony - dar totuși au problema.

Editare: pașii utilizați pentru a trece la Chrony

• yum instalează chrony
• systemctl stop ntpd
• systemctl dezactivează ntpd
• systemctl start chronyd
• systemctl enable chronyd

Deci când folosesc timedatectl Obțin această ieșire:

      Ora locală: Luni 2021-08-02 09:14:43 CEST
  Ora universală: Luni 2021-08-02 07:14:43 UTC
        Ora RTC: Luni 2021-08-02 07:16:34
       Fus orar: Europe/Copenhaga (CEST, +0200)
     NTP activat: da
NTP sincronizat: nu
 RTC în TZ local: nr
      DST activ: da
 Ultima modificare de ora de vară: ora de vară a început la
                  Duminica 28-03-2021 01:59:59 CET
                  Duminica 28-03-2021 03:00:00 CEST
 Următoarea schimbare de ora de oră: ora de oră se termină (ceasul sare cu o oră înapoi) la
                  Duminica 31-10-2021 02:59:59 CEST
                  Duminica 31-10-2021 02:00:00 CET

Dacă repornesc Chrony folosind systemctl reporniți chronyd apoi după câteva secunde timedatectl rapoarte:

      Ora locală: Luni 2021-08-02 09:26:06 CEST
  Ora universală: Luni 2021-08-02 07:26:06 UTC
        Ora RTC: Luni 2021-08-02 07:26:08
       Fus orar: Europe/Copenhaga (CEST, +0200)
     NTP activat: da
Sincronizat NTP: da
 RTC în TZ local: nr
      DST activ: da
 Ultima modificare de ora de vară: ora de vară a început la
                  Duminica 28-03-2021 01:59:59 CET
                  Duminica 28-03-2021 03:00:00 CEST
 Următoarea schimbare de ora de oră: ora de oră se termină (ceasul sare cu o oră înapoi) la
                  Duminica 31-10-2021 02:59:59 CEST
                  Duminica 31-10-2021 02:00:00 CET

După ceva timp (minute) se întoarce la NTP sincronizat: nu.

Când alerg ntpstat Eu iau:

sincronizat cu serverul NTP (217.198.219.102) la stratul 2
   timpul corectat la 124123 ms
   server de sondare la fiecare 64 de secunde

sau

nesincronizat
interval de sondaj necunoscut

În ultimul caz, după ceva timp, va afișa din nou prima ieșire. Dar „în ... ms” pare destul de mare???

Deoarece îl pot sincroniza repornind Chrony, cred că firewall-ul/rețeaua este în regulă. Folosesc configurația implicită Chrony (cum am făcut cu ntpd înainte).

Serviciul VMwaretools este instalat și pornit (open-vm-tools, http://github.com/vmware/open-vm-tools).

Aș aprecia orice sugestii pentru depanarea în continuare a problemei - și, eventual, remediați-o ;-)

Mulțumesc anticipat!

/Ioan

Cred că am rezolvat-o acum.

Practic, chrony credea că timpul variază prea mult. Așa că, urmând link-ul lui Peter Rosenberg (și resursele la care s-a legat) am intrat pe pistă....

Am pus aceste informații aici în cazul în care altcineva le caută.

Primii pași ai procesului au fost starea serviciului chronyd:

systemctl status chronyd
â chronyd.service - client/server NTP
   Încărcat: încărcat (/usr/lib/systemd/system/chronyd.service; activat; prestabilit furnizor: activat)
   Activ: activ (în rulare) din Luni 2021-08-02 22:23:39 CEST; acum 10 ore
     Documente: man:chronyd(8)
           man:chrony.conf(5)
  Proces: 24758 ExecStartPost=/usr/libexec/chrony-helper update-daemon (code=exited, status=0/SUCCESS)
  Proces: 24754 ExecStart=/usr/sbin/chronyd $OPTIONS (cod=ieșit, stare=0/SUCCESS)
 PID principal: 24756 (cronic)
   CGroup: /system.slice/chronyd.service
           ââ24756 /usr/sbin/chronyd

Aug 03 08:41:24 db1.aqua.dtu.dk chronyd[24756]: Sursa selectată 162.159.200.1
Aug 03 08:41:24 db1.aqua.dtu.dk chronyd[24756]: Ceasul sistemului este greșit cu 5,118732 secunde, a început ajustarea
Aug 03 08:41:26 db1.aqua.dtu.dk chronyd[24756]: Nu se poate sincroniza: fără majoritate
Aug 03 08:41:33 db1.aqua.dtu.dk chronyd[24756]: Sursa selectată 162.159.200.123
Aug 03 08:41:33 db1.aqua.dtu.dk chronyd[24756]: Ceasul sistemului este greșit cu 1,761045 secunde, ajustarea a început
Aug 03 08:42:29 db1.aqua.dtu.dk chronyd[24756]: Nu se poate sincroniza: fără majoritate
Aug 03 08:42:30 db1.aqua.dtu.dk chronyd[24756]: Sursa selectată 192.36.143.130
Aug 03 08:42:30 db1.aqua.dtu.dk chronyd[24756]: Ceasul sistemului este greșit cu 4,500188 secunde, a început ajustarea
Aug 03 08:43:34 db1.aqua.dtu.dk chronyd[24756]: Ceasul sistemului este greșit cu 4,842190 secunde, a început ajustarea
Aug 03 08:44:39 db1.aqua.dtu.dk chronyd[24756]: Nu se poate sincroniza: nu există surse selectabile

Arăta clar că ceva nu era în regulă. Deci următorul pas a fost:

surse cronice -v
210 Număr de surse = 4

  .-- Modul sursă '^' = server, '=' = peer, '#' = ceas local.
 / .- Stare sursă „*” = sincronizat curent, „+” = combinat, „-” = necombinat,
| / '?' = inaccesibil, „x” = timpul poate fi în eroare, „~” = timpul prea variabil.
|| .- xxxx [ aaaa ] +/- zzzz
|| Registrul de accesibilitate (octal) -. | xxxx = offset ajustat,
|| Log2 (Interval de sondare) --. | | aaaa = offset măsurat,
|| \ | | zzzz = eroare estimată.
|| | | \
MS Nume/adresă IP Stratum Poll Reach LastRx Ultima mostră               
==================================================== ==============================
^~ time.cloudflare.com 3 6 377 1 -17.0s[ -17.0s] +/- 1318us
^~ Time100.Stupi.SE 1 6 377 2 -16.9s[ -16.9s] +/- 4458us
^~ time.cloudflare.com 3 6 377 53 -11.2s[ -11.2s] +/- 1306us
^~ n1.taur.dk 1 6 377 60 -10.4s[ -10.4s] +/- 4964us

Observați timpul prea variabil pentru toate serverele....

Și urmărire cronică arată, de asemenea, că timpul nu este deloc aliniat:

ID referință: C0248F82 (Time100.Stupi.SE)
Strat: 2
Ora de referință (UTC): marți 03 august 06:46:05 2021
Timp de sistem: 132,970306396 secunde lent din timpul NTP
Ultima compensare: -4,842189789 secunde
Offset RMS: 7,720179081 secunde
Frecvență: 63,104 ppm lentă
Frecvență reziduală: -81143,852 ppm
Înclinare: 90.130 ppm
Întârziere la rădăcină: 0,008654756 secunde
Dispersia rădăcină: 19,424978256 secunde
Interval de actualizare: 58,2 secunde
Stare de salt: Normal

După mai multe citite în referințele la articolele menționate, am încercat să ajustez maketep în /etc/chrony.conf fișier pentru a forța actualizarea. Am schimbat deja serverele de pool NTP pentru a fi „mai aproape” de serverele de aplicații, așa că fișierul de configurare arată acum așa:

server 0.dk.pool.ntp.org iburst
server 1.dk.pool.ntp.org iburst
server 2.dk.pool.ntp.org iburst
server 3.dk.pool.ntp.org iburst
driftfile /var/lib/chrony/drift
pasul 1 -1
rtcsync

Acum ruleaza de putin timp si se pare ca tine ora sincronizata ;-)

EDITAȚI | ×:

După cum a subliniat Paul Gear, nu rezolvasem problema... Timpul încă a plutit.

Folosind starea /usr/bin/vmware-toolbox-cmd timesync Am constatat că pe serverele de producție sincronizarea orei cu gazda ESXi a fost ACTIVATĂ (!!!). Nu am idee cum s-a întâmplat asta? VM-ul pe care l-am configurat inițial și l-am încărcat în centrul de date nu îl avea activat.În orice caz, evident, nu ar trebui să se sincronizeze. timp cu gazda.

Este destul de ușor de dezactivat folosind: /usr/bin/vmware-toolbox-cmd timesync dezactivat

Și acum avem date mai realiste de la surse cronice -v:

210 Număr de surse = 4

  .-- Modul sursă '^' = server, '=' = peer, '#' = ceas local.
 / .- Stare sursă „*” = sincronizat curent, „+” = combinat, „-” = necombinat,
| / '?' = inaccesibil, „x” = timpul poate fi în eroare, „~” = timpul prea variabil.
|| .- xxxx [ aaaa ] +/- zzzz
|| Registrul de accesibilitate (octal) -. | xxxx = offset ajustat,
|| Log2 (Interval de sondare) --. | | aaaa = offset măsurat,
|| \ | | zzzz = eroare estimată.
|| | | \
MS Nume/adresă IP Stratum Poll Reach LastRx Ultima mostră               
==================================================== ==============================
^- sweetums.eng.tdc.net 2 7 377 36 +30us[ +30us] +/- 45ms
^* 77.68.139.83 1 7 377 92 -191us[ -184us] +/- 4742us
^- 152.115.59.244 2 7 377 39 +99us[ +99us] +/- 31ms
^- pf.safe-con.dk 2 7 377 42 +359us[ +359us] +/- 29ms

precum și urmărire cronică:

ID referință: 4D448B53 (77.68.139.83)
Strat: 2
Ora de referință (UTC): marți 03 august 10:45:26 2021
Timp de sistem: 0,000008465 secunde lent din timpul NTP
Ultima compensare: +0,000006720 secunde
Offset RMS: 7,358564854 secunde
Frecvență: 57,633 ppm lentă
Frecvență reziduală: +0,001 ppm
Înclinare: 0,340 ppm
Întârziere la rădăcină: 0,009058274 secunde
Dispersia rădăcină: 0,000351956 secunde
Interval de actualizare: 128,8 secunde
Stare de salt: Normal

Acum a funcționat fără probleme de o jumătate de oră, așa că sunt sigur că aceasta este soluția. Multumesc pentru intrare!!!

Luați în considerare utilizarea setării minime a clientului așa cum este sugerat aici: https://www.golinuxcloud.com/configure-chrony-ntp-server-client-force-sync/ Când pragul de drifting este atins, renunță la sincronizarea ceea ce vi se pare.