VM com o ntpd em execução, mas não sincronizando

5

TL; DR

VM usando o KVM, o horário não está sincronizado. Após uma pausa de 2 minutos, mantém um intervalo permanente de 2 min. Configurar outra VM com configuração de rede diferente mostra que a configuração de rede impede o funcionamento do ntp. Corrigir este problema de rede está fora de tópico.

No entanto, a nova VM que não tem o problema de rede não é sincronizada depois de um reinício. Mesmo teste: suspenda 2 minutos. Verifique a diferença de data com uma máquina que esteja sincronizada corretamente. O atraso de 2 minutos é permanente.

Este parece ser um problema comum e há controvérsias sobre como manter uma VM sincronizada e sobre como usar o NTP e o kvm-clock ao mesmo tempo. Eu encontrei muitas referências para isso, mas não tenho resposta.

Pergunta

Eu tenho uma máquina virtual Debian com ntpd em execução, mas não corrigindo o tempo. Por exemplo, após uma suspensão / retomada, recebo um deslocamento permanente de 2 minutos.

/etc/ntp.conf é o padrão ou próximo do padrão, nada sofisticado:

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntp/ntp.drift


# Enable this if you want statistics to be logged.
#statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable


# You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example

# pool.ntp.org maps to about 1000 low-stratum NTP servers.  Your server will
# pick a different set every time it starts up.  Please consider joining the
# pool: <http://www.pool.ntp.org/join.html>
server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst


# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details.  The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
# might also be helpful.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust


# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
#broadcast 192.168.123.255

# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines.  Please do this only if you trust everybody on the network!
#disable auth
#broadcastclient

O ntpq parece reportar um problema:

# cat ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 37.187.7.160    .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 195.154.211.37  .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 195.154.216.44  .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 95.81.173.155   .INIT.          16 u    - 1024    0    0.000    0.000   0.000

No entanto, não sou um assistente do netcat, mas o tráfego de saída do AFAIU na porta UDP 123 passa por:

# nc -vvzu 37.187.7.160 123
mail.lafkor.de [37.187.7.160] 123 (ntp) open
 sent 0, rcvd 0

Este teste é suficiente para descartar o problema do firewall?

O host (também uma máquina Debian) tem a mesma configuração NTP e a sincronização está funcionando. A configuração de rede para ambas as máquinas é diferente, e é por isso que estou pensando que pode ser um problema de rede.

Algum outro teste útil que eu possa executar?

Eu não acho que o parâmetro tinker panic 0 seja relevante aqui, já que se destina a forçar atualizações em grandes lacunas, não em intervalos de 2 minutos. E de qualquer maneira, AFAIU, isso afetaria o comportamento em caso de deslocamento de tempo, mas não resolveria ntpq -pn retornando apenas zeros.

FWIW, outras saídas de teste inspiradas em esta pergunta :

# ntpq
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 mail.lafkor.de  .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 atoll.tropicdre .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 oods.roflcopter .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 ntp-3.arkena.ne .INIT.          16 u    - 1024    0    0.000    0.000   0.000
ntpq> as

ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 21025  8011   yes    no  none    reject    mobilize  1
  2 21026  8011   yes    no  none    reject    mobilize  1
  3 21027  8011   yes    no  none    reject    mobilize  1
  4 21028  8011   yes    no  none    reject    mobilize  1
ntpq> rv
associd=0 status=c012 leap_alarm, sync_unspec, 1 event, freq_set,
version="ntpd [email protected] Fri Apr 10 19:04:04 UTC 2015 (1)",
processor="x86_64", system="Linux/3.16.0-4-amd64", leap=11, stratum=16,
precision=-23, rootdelay=0.000, rootdisp=6683.055, refid=INIT,
reftime=00000000.00000000  Mon, Jan  1 1900  0:09:21.000,
clock=d9b51587.b7a1085f  Tue, Sep 29 2015 15:49:59.717, peer=0, tc=3,
mintc=3, offset=0.000, frequency=-0.125, sys_jitter=0.000,
clk_jitter=0.000, clk_wander=0.000
ntpq> rv 21025
associd=21025 status=8011 conf, sel_reject, 1 event, mobilize,
srcadr=mail.lafkor.de, srcport=123, dstadr=147.210.157.185, dstport=123,
leap=11, stratum=16, precision=-23, rootdelay=0.000, rootdisp=0.000,
refid=INIT, reftime=00000000.00000000  Mon, Jan  1 1900  0:09:21.000,
rec=00000000.00000000  Mon, Jan  1 1900  0:09:21.000, reach=000,
unreach=1137, hmode=3, pmode=0, hpoll=10, ppoll=10, headway=0,
flash=1600 peer_stratum, peer_dist, peer_unreach, keyid=0, offset=0.000,
delay=0.000, dispersion=15937.500, jitter=0.000, xleave=0.167,
filtdelay=     0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00,
filtoffset=    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00,
filtdisp=   16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0

tcpdump / testes ntpdate

Em uma máquina em que a sincronização de NTP funciona corretamente, eu inicio tcpdump udp port ntp e quando eu reinicio ntpd , vejo esse tipo de saída:

# tcpdump udp port ntp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:31:33.719166 IP 10.0.2.15.ntp > spica.beduzar.fr.ntp: NTPv4, Client, length 48
17:31:33.736804 IP spica.beduzar.fr.ntp > 10.0.2.15.ntp: NTPv4, Server, length 48
17:31:35.973551 IP 10.0.2.15.ntp > ntp.tuxfamily.net.ntp: NTPv4, Client, length 48
17:31:35.992671 IP ntp.tuxfamily.net.ntp > 10.0.2.15.ntp: NTPv4, Server, length 48
[...]

Na máquina com a qual tenho o problema, não vejo nenhuma saída ao reiniciar ntpd (sem solicitação, sem resposta). Eu não deveria, pelo menos, ver os pedidos?

Na boa máquina:

# ntpdate 0.debian.pool.ntp.org
29 Sep 17:24:49 ntpdate[700]: adjust time server 193.55.167.1 offset -0.005196 sec

Na má máquina:

# ntpdate 0.debian.pool.ntp.org
29 Sep 17:43:18 ntpdate[3180]: no server suitable for synchronization found

Teste com outra VM

Nós configuramos outra VM com a mesma configuração NTP, mas com outra configuração de rede.

Os resultados de tcpdump e ntpdate estão corretos e ntpq -pn retorna bons resultados. Então, aparentemente, a configuração da rede é de fato um problema na VM defeituosa.

No entanto, a nova VM também não sincroniza. Se eu suspendê-lo para que ele tenha aproximadamente 100s de atraso, ele não será sincronizado (quero dizer, depois de alguns minutos, a diferença ainda é o mesmo número de segundos). No entanto, ao reiniciar o ntpd, ele é sincronizado instantaneamente.

Parece que tenho dois problemas:

  • Configuração de rede na primeira VM

  • O ntp não sincroniza em ambos (a menos que seja reiniciado)

por Jérôme 29.09.2015 / 15:46

1 resposta

1

Problema resolvido.

Problema de rede

A VM tinha problemas de rede que impediam o sucesso do ntpd. Ele tem duas interfaces eth , e a outra com o gateway passa por um roteador que não gerenciamos diretamente. Embora meus testes não mostrem, acho que alguns quadros UDP foram bloqueados. Nós configuramos outra VM com outra configuração de rede e ntpq gerou melhores resultados.

Por fim, alteramos o ntp config para que o host transmita o tempo localmente e todas as VMs sincronizem nele. Faz mais sentido e minimiza a carga em ntp servidores públicos.

ntpd define o relógio instantaneamente após alguns minutos

Uma coisa que provavelmente me enganou durante os testes é que o ntpd não é sincronizado imediatamente. Eu pensei que iria detectar uma lacuna imediatamente e, em seguida, modificar a velocidade do clock para que o relógio progressivamente se junte ao relógio de origem. De fato, notamos que (a menos que o ntpd seja reiniciado) o relógio permaneça inalterado por alguns minutos, então, de repente, é definido o que parece instantaneamente. Enquanto isso, as colunas mais à direita em ntpq output mostram que a sincronização está acontecendo.

Esse comportamento ntpd provavelmente explica por que achei que ntpd não funcionou, mesmo que tenha funcionado. Eu simplesmente não esperei o suficiente e não entendi ntpq output.

    
por 20.10.2015 / 09:40

Tags