☰

NTP/Chrony no mantiene la hora sincronizada en CentOS 7.9 (VM ejecutándose en VMware ESXi)

tag-icon • tag-icon centos7 time-synchronization ntpd chrony
NTP/Chrony no mantiene la hora sincronizada en CentOS 7.9 (VM ejecutándose en VMware ESXi)

Tengo 3 servidores ejecutando CentOS 7.9.2009 en un centro de datos (VMware ESXi). Estos servidores informan que la hora no está sincronizada. Tengo un entorno de prueba similar ejecutándose en un servidor VMware ESXi interno donde los servidores se sincronizan. la hora está bien. El entorno de producción se configuró originalmente exactamente de la misma manera, pero obviamente se actualizó con actualizaciones de paquetes con el tiempo. Por lo tanto, "deberían" ser idénticos, pero ya no puedo garantizarlo. Los servidores ESXi son ambos de la versión 6.

Los servidores se configuraron originalmente usando "ntpd", pero al solucionar este problema en los últimos días descubrí que "Chrony" parece ser una mejor opción en CentOS 7. Por lo tanto, he reconfigurado los servidores para usar Chrony, pero aún así tiene el problema.

Editar: pasos utilizados para cambiar a Chrony

  • yum instalar crony
  • systemctl detener ntpd
  • systemctl deshabilita ntpd
  • systemctl inicia chronyd
  • systemctl habilitar chronyd

Entonces, cuando lo uso, timedatectlobtengo este resultado:

      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

Si reinicio el uso de Chrony systemctl restart chronyd, después de un par de segundos timedatectlse informa:

      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

Después de un tiempo (minutos), vuelve a ser NTP synchronized: no.

Cuando corro ntpstatme sale:

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

o

unsynchronised
poll interval unknown

En el último caso, después de un tiempo volverá a mostrar el primer resultado. ¿Pero el "dentro de... ms" parece bastante alto?

Como puedo sincronizarlo reiniciando Chrony, supongo que el firewall/red está bien. Utilizo la configuración predeterminada de Chrony (como hice antes con ntpd).

El servicio VMwaretools está instalado e iniciado (open-vm-tools,http://github.com/vmware/open-vm-tools).

Agradecería cualquier sugerencia para solucionar este problema en mayor profundidad y, eventualmente, solucionarlo ;-)

¡Gracias de antemano!

/John

Respuesta1

Creo que ya lo he solucionado.

Básicamente, Chrony pensó que el tiempo variaba demasiado. Así que siguiendo el enlace de Peter Rosenberg (y los recursos a los que enlaza) me puse en camino....

He puesto esta información aquí por si alguien más la busca.

Los primeros pasos del proceso fueron el estado del servicio chronyd:

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

Mostró claramente que algo andaba mal. Entonces el siguiente paso fue:

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

Observe el time too variablepara todos los servidores....

Y chronyc trackingtambién muestra que el tiempo no está alineado en absoluto:

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

Después de leer un poco más las referencias a los artículos mencionados, intenté ajustar el makesteparchivo /etc/chrony.confpara forzar una actualización. Ya había cambiado los servidores del grupo NTP para que estuvieran "más cerca" de los servidores de aplicaciones, por lo que el archivo de configuración ahora se ve así:

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

Ya lleva un rato funcionando y parece que mantiene la hora sincronizada ;-)

EDITAR:

Como señaló Paul Gear, no había resuelto el problema... El tiempo todavía pasaba.

Usando /usr/bin/vmware-toolbox-cmd timesync statusencontré que en los servidores de producción la sincronización de la hora con el host ESXi estaba HABILITADA (!!!). ¿No tengo idea de cómo ha sucedido esto? La máquina virtual que configuré y cargué originalmente en el centro de datos no la tenía habilitada. De cualquier forma, obviamente, no debería sincronizarse. tiempo con el anfitrión.

Es bastante fácil de desactivar usando:/usr/bin/vmware-toolbox-cmd timesync disable

Y ahora tenemos datos más realistas de 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

así como 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

Ha estado funcionando sin problemas durante media hora, así que estoy seguro de que esta es la solución. ¡¡¡Gracias por el aporte!!!

Respuesta2

Considere utilizar la configuración mínima del cliente como se sugiere aquí:https://www.golinuxcloud.com/configure-chrony-ntp-server-client-force-sync/ Cuando se alcanza el umbral de deriva, abandona la sincronización, lo que parece que le sucede a usted.

información relacionada