☰

NTP/Chrony hält die Zeit unter CentOS 7.9 nicht synchronisiert (VM läuft auf VMware ESXi)

tag-icon • tag-icon centos7 time-synchronization ntpd chrony
NTP/Chrony hält die Zeit unter CentOS 7.9 nicht synchronisiert (VM läuft auf VMware ESXi)

Ich habe 3 Server in einem Rechenzentrum (VMware ESXi), auf denen CentOS 7.9.2009 läuft. Diese Server melden, dass die Zeit nicht synchronisiert ist. Ich habe eine ähnliche Testumgebung auf einem internen VMware ESXi-Server, auf dem die Server synchronisiert werden. Die Zeit ist ok. Die Produktionsumgebung wurde ursprünglich genauso eingerichtet – aber offensichtlich im Laufe der Zeit mit Paketaktualisierungen aktualisiert. Sie „sollten“ also identisch sein – aber das kann ich nicht mehr garantieren. Die ESXi-Server sind beide Version 6.

Die Server wurden ursprünglich mit „ntpd“ konfiguriert. Bei der Fehlerbehebung dieses Problems in den letzten Tagen habe ich jedoch festgestellt, dass „Chrony“ unter CentOS 7 die bessere Wahl zu sein scheint. Daher habe ich die Server für die Verwendung von Chrony neu konfiguriert. Das Problem besteht jedoch weiterhin.

Bearbeiten: Schritte zum Wechsel zu Chrony

  • yum installiere chrony
  • systemctl stoppt ntpd
  • systemctl deaktiviert ntpd
  • systemctl start chronyd
  • systemctl aktiviere chronyd

Wenn ich also verwende, timedatectlerhalte ich diese Ausgabe:

      Local time: Mon 2021-08-02 09:14:43 CEST
  Universal time: Mon 2021-08-02 07:14:43 UTC
        RTC time: Mon 2021-08-02 07:16:34
       Time zone: Europe/Copenhagen (CEST, +0200)
     NTP enabled: yes
NTP synchronized: no
 RTC in local TZ: no
      DST active: yes
 Last DST change: DST began at
                  Sun 2021-03-28 01:59:59 CET
                  Sun 2021-03-28 03:00:00 CEST
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2021-10-31 02:59:59 CEST
                  Sun 2021-10-31 02:00:00 CET

Wenn ich Chrony neu starte, meldet systemctl restart chronydes nach ein paar Sekunden timedatectl:

      Local time: Mon 2021-08-02 09:26:06 CEST
  Universal time: Mon 2021-08-02 07:26:06 UTC
        RTC time: Mon 2021-08-02 07:26:08
       Time zone: Europe/Copenhagen (CEST, +0200)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: yes
 Last DST change: DST began at
                  Sun 2021-03-28 01:59:59 CET
                  Sun 2021-03-28 03:00:00 CEST
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2021-10-31 02:59:59 CEST
                  Sun 2021-10-31 02:00:00 CET

Nach einiger Zeit (Minuten) steht es wieder auf NTP synchronized: no.

Beim Ausführen ntpstaterhalte ich Folgendes:

synchronised to NTP server (217.198.219.102) at stratum 2
   time correct to within 124123 ms
   polling server every 64 s

oder

unsynchronised
poll interval unknown

Im letzten Fall wird dann nach einiger Zeit wieder die erste Ausgabe angezeigt. Aber das „innerhalb von ... ms“ scheint ziemlich hoch???

Da ich es durch einen Neustart von Chrony synchronisieren kann, gehe ich davon aus, dass Firewall/Netzwerk in Ordnung sind. Ich verwende die Standardkonfiguration von Chrony (wie ich es zuvor mit ntpd getan habe).

Der VMwaretools-Dienst ist installiert und gestartet (open-vm-tools,http://github.com/vmware/open-vm-tools).

Ich würde mich über alle Vorschläge zur weiteren Fehlerbehebung freuen – und um das Problem eventuell zu beheben ;-)

Dank im Voraus!

/John

Antwort1

Ich glaube, ich habe es jetzt gelöst.

Im Grunde war Chrony der Meinung, dass die Zeit zu stark variierte. Ich bin also dem Link von Peter Rosenberg (und den darin verlinkten Ressourcen) gefolgt und auf die Spur gekommen …

Ich habe diese Informationen hier eingefügt, für den Fall, dass jemand anders danach sucht.

Die ersten Schritte im Prozess waren der Status des Chronyd-Dienstes:

systemctl status chronyd
● chronyd.service - NTP client/server
   Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2021-08-02 22:23:39 CEST; 10h ago
     Docs: man:chronyd(8)
           man:chrony.conf(5)
  Process: 24758 ExecStartPost=/usr/libexec/chrony-helper update-daemon (code=exited, status=0/SUCCESS)
  Process: 24754 ExecStart=/usr/sbin/chronyd $OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 24756 (chronyd)
   CGroup: /system.slice/chronyd.service
           └─24756 /usr/sbin/chronyd

Aug 03 08:41:24 db1.aqua.dtu.dk chronyd[24756]: Selected source 162.159.200.1
Aug 03 08:41:24 db1.aqua.dtu.dk chronyd[24756]: System clock wrong by 5.118732 seconds, adjustment started
Aug 03 08:41:26 db1.aqua.dtu.dk chronyd[24756]: Can't synchronise: no majority
Aug 03 08:41:33 db1.aqua.dtu.dk chronyd[24756]: Selected source 162.159.200.123
Aug 03 08:41:33 db1.aqua.dtu.dk chronyd[24756]: System clock wrong by 1.761045 seconds, adjustment started
Aug 03 08:42:29 db1.aqua.dtu.dk chronyd[24756]: Can't synchronise: no majority
Aug 03 08:42:30 db1.aqua.dtu.dk chronyd[24756]: Selected source 192.36.143.130
Aug 03 08:42:30 db1.aqua.dtu.dk chronyd[24756]: System clock wrong by 4.500188 seconds, adjustment started
Aug 03 08:43:34 db1.aqua.dtu.dk chronyd[24756]: System clock wrong by 4.842190 seconds, adjustment started
Aug 03 08:44:39 db1.aqua.dtu.dk chronyd[24756]: Can't synchronise: no selectable sources

Es zeigte sich deutlich, dass etwas nicht stimmte. Der nächste Schritt war also:

chronyc sources -v
210 Number of sources = 4

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current synced, '+' = combined , '-' = not combined,
| /   '?' = unreachable, 'x' = time may be in error, '~' = time too variable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^~ 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

Beachten Sie dies time too variablefür alle Server....

Und chronyc trackingzeigt auch, dass die Zeit überhaupt nicht übereinstimmt:

Reference ID    : C0248F82 (Time100.Stupi.SE)
Stratum         : 2
Ref time (UTC)  : Tue Aug 03 06:46:05 2021
System time     : 132.970306396 seconds slow of NTP time
Last offset     : -4.842189789 seconds
RMS offset      : 7.720179081 seconds
Frequency       : 63.104 ppm slow
Residual freq   : -81143.852 ppm
Skew            : 90.130 ppm
Root delay      : 0.008654756 seconds
Root dispersion : 19.424978256 seconds
Update interval : 58.2 seconds
Leap status     : Normal

makestepNachdem ich die Referenzen zu den erwähnten Artikeln noch einmal durchgelesen hatte, versuchte ich, die Datei anzupassen, /etc/chrony.confum ein Update zu erzwingen. Ich hatte die NTP-Pool-Server bereits so geändert, dass sie „näher“ an den Anwendungsservern liegen, sodass die Konfigurationsdatei nun folgendermaßen aussieht:

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
makestep 1 -1
rtcsync

Es läuft nun seit einiger Zeit und scheint die Zeit synchronisiert zu halten ;-)

BEARBEITEN:

Wie Paul Gear bemerkte, hatte ich das Problem nicht gelöst … Die Zeit verging immer noch.

Mithilfe von /usr/bin/vmware-toolbox-cmd timesync statushabe ich festgestellt, dass auf den Produktionsservern die Synchronisierung der Zeit mit dem ESXi-Host AKTIVIERT (!!!) war. Ich habe keine Ahnung, wie das passiert ist? Die VM, die ich ursprünglich konfiguriert und zu den Leuten im Rechenzentrum hochgeladen habe, hatte sie nicht aktiviert. Wie auch immer, offensichtlich sollte sie die Zeit nicht mit dem Host synchronisieren.

Die Deaktivierung ist relativ einfach:/usr/bin/vmware-toolbox-cmd timesync disable

Und jetzt haben wir realistischere Daten von chronyc sources -v:

210 Number of sources = 4

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current synced, '+' = combined , '-' = not combined,
| /   '?' = unreachable, 'x' = time may be in error, '~' = time too variable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^- 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

sowie chronyc tracking:

Reference ID    : 4D448B53 (77.68.139.83)
Stratum         : 2
Ref time (UTC)  : Tue Aug 03 10:45:26 2021
System time     : 0.000008465 seconds slow of NTP time
Last offset     : +0.000006720 seconds
RMS offset      : 7.358564854 seconds
Frequency       : 57.633 ppm slow
Residual freq   : +0.001 ppm
Skew            : 0.340 ppm
Root delay      : 0.009058274 seconds
Root dispersion : 0.000351956 seconds
Update interval : 128.8 seconds
Leap status     : Normal

Es läuft jetzt seit einer halben Stunde problemlos, daher bin ich zuversichtlich, dass dies die Lösung ist. Danke für den Hinweis!!!

Antwort2

Erwägen Sie die Verwendung des minimalen Client-Setups, wie hier vorgeschlagen:https://www.golinuxcloud.com/configure-chrony-ntp-server-client-force-sync/ Wenn die Schwelle des Abdriftens erreicht ist, wird die Synchronisierung abgebrochen, was bei Ihnen anscheinend der Fall ist.

verwandte Informationen