☰

NTP/Chrony não mantém o horário sincronizado no CentOS 7.9 (VM em execução no VMware ESXi)

tag-icon • tag-icon centos7 time-synchronization ntpd chrony
NTP/Chrony não mantém o horário sincronizado no CentOS 7.9 (VM em execução no VMware ESXi)

Tenho 3 servidores rodando CentOS 7.9.2009 em um data center (VMware ESXi). Esses servidores relatam que a hora não está sincronizada. Eu tenho um ambiente de teste semelhante em execução em um servidor VMware ESXi interno onde os servidores são sincronizados. a hora ok. O ambiente de produção foi originalmente configurado exatamente da mesma maneira - mas obviamente atualizado com atualizações de pacotes ao longo do tempo. Portanto, eles "deveriam" ser idênticos - mas não posso mais garantir isso. Os servidores ESXi são ambos da versão 6.

Os servidores foram originalmente configurados usando "ntpd" - mas ao solucionar esse problema nos últimos dias, descobri que "Chrony" parece ser uma escolha melhor no CentOS 7. Portanto, reconfigurei os servidores para usar o Chrony - mas ainda assim tenho o problema.

Editar: etapas usadas para mudar para Chrony

  • yum instalar o chrony
  • systemctl parar ntpd
  • systemctl desabilitar ntpd
  • systemctl iniciar chronyd
  • systemctl habilitar chronyd

Então, quando eu uso, timedatectlrecebo esta saída:

      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

Se eu reiniciar o Chrony usando systemctl restart chronyd, depois de alguns segundos timedatectl, os relatórios:

      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

Depois de algum tempo (minutos) ele volta a NTP synchronized: no.

Quando corro ntpstatrecebo:

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

ou

unsynchronised
poll interval unknown

No último caso, depois de algum tempo, a primeira saída será exibida novamente. Mas o "dentro...ms" parece bem alto???

Como consigo sincronizá-lo reiniciando o Chrony, acho que o firewall/rede está OK. Eu uso a configuração padrão do Chrony (como fiz com o ntpd antes).

O serviço VMwaretools está instalado e iniciado (open-vm-tools,http://github.com/vmware/open-vm-tools).

Eu apreciaria qualquer sugestão para solucionar esse problema - e, eventualmente, corrigi-lo ;-)

Desde já, obrigado!

/John

Responder1

Acho que resolvi isso agora.

Basicamente, Chrony achava que o tempo variava demais. Então, seguindo o link de Peter Rosenberg (e os recursos aos quais ele está vinculado), entrei no caminho certo....

Coloquei essas informações aqui caso alguém as procure.

As primeiras etapas do processo foram o status do serviço 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

Mostrou claramente que algo estava errado. Então o próximo passo foi:

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 o time too variablepara todos os servidores....

E chronyc trackingtambém mostra que o tempo não está nada alinhado:

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

Depois de ler mais algumas referências aos artigos mencionados, tentei ajustar o makesteparquivo /etc/chrony.confpara forçar uma atualização. Eu já havia alterado os servidores do pool NTP para ficarem "mais próximos" dos servidores de aplicativos, então o arquivo de configuração agora fica assim:

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

Já está funcionando há algum tempo e parece estar mantendo a hora sincronizada ;-)

EDITAR:

Como observou Paul Gear, eu não havia resolvido o problema... O tempo ainda passava.

Usando /usr/bin/vmware-toolbox-cmd timesync statusdescobri que nos servidores de produção a sincronização do horário com o host ESXi estava ATIVADA (!!!). Não tenho ideia de como isso aconteceu? A VM que configurei originalmente e carreguei para o pessoal do data center não estava habilitada. De qualquer forma, obviamente, não deveria sincronizar. tempo com o anfitrião.

É bastante fácil desativar usando:/usr/bin/vmware-toolbox-cmd timesync disable

E agora temos dados mais 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

assim 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

Já está funcionando perfeitamente há meia hora, então estou confiante de que esta é a solução. Obrigado pela contribuição!!!

Responder2

Considere usar a configuração mínima do cliente conforme sugerido aqui:https://www.golinuxcloud.com/configure-chrony-ntp-server-client-force-sync/ Quando o limiar da deriva é atingido, ele desiste da sincronização, o que parece acontecer com você.

informação relacionada