Bonjour,
J’ai un problème avec mon client ntp qui se désynchronise sans que je n’en comprenne la raison.
(chrony marche lui sans aucun problème, mais je dois utiliser ntp)
Ma configuration, j’ai une VM (nommé K2) qui me sert de serveur de temps, j’ai plusieurs autres VMs qui se synchronise sur K2.
K2 utilise maintenant chrony pour se synchroniser sur internet, car ntp ne fait rapidement plus la synchronisation. Pour les autres VMs je dois impérativement utiliser ntp.
Le problème est que je ne sais pas depuis combien de temps la synchronisation ne fonctionne plus, elle n'est importante que dans une cas particulier de serveur en RAC que je n'ai plus fait depuis un moment.
L’offset grossi rapidement après le boot et ne cesse d’augmenter.
# while [ true ]; do date; ntpq -p; sleep 60; done
Mon Dec 19 16:16:50 CET 2016
remote refid st t when poll reach delay offset jitter
==============================================================================
*K2.orcl 163.172.10.91 3 u 2 64 1 1.077 -159.25 0.000
Mon Dec 19 16:17:50 CET 2016
remote refid st t when poll reach delay offset jitter
==============================================================================
*K2.orcl 163.172.10.91 3 u 62 64 1 1.077 -159.25 0.000
Mon Dec 19 16:18:50 CET 2016
remote refid st t when poll reach delay offset jitter
==============================================================================
K2.orcl 163.172.10.91 3 u 55 64 3 0.933 -1665.0 1505.79
Mon Dec 19 16:19:50 CET 2016
remote refid st t when poll reach delay offset jitter
==============================================================================
K2.orcl 163.172.10.91 3 u 50 64 7 0.933 -1665.0 1483.63
Mon Dec 19 16:20:50 CET 2016
remote refid st t when poll reach delay offset jitter
==============================================================================
K2.orcl 163.172.10.91 3 u 44 64 17 0.933 -1665.0 2088.09
Mon Dec 19 16:21:50 CET 2016
remote refid st t when poll reach delay offset jitter
==============================================================================
K2.orcl 163.172.10.91 3 u 39 64 37 0.933 -1665.0 2850.82
Comme l'étoile devant K2 disparaît, je pense à une désynchronisation. Sur l'exemple ce n'est pas en mis en évidence mais l'offset ne cesse d'augmenter, au bout de 4h la VM avancera de 10mn par rapport au serveur de temps K2.
Si je stop ntpd, synchronise avec ntpdate et démarre ntpd, le problème met moins de 6mn à réapparaître.
systemctl status ntpd -l
● ntpd.service - Network Time Service
Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2016-12-19 16:21:54 CET; 3s ago
Process: 3149 ExecStart=/usr/sbin/ntpd -u ntp:ntp $OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 3150 (ntpd)
CGroup: /system.slice/ntpd.service
└─3150 /usr/sbin/ntpd -u ntp:ntp -x -I eth0 -p /var/run/ntpd.pid
Dec 19 16:21:54 srvloulou01.orcl ntpd[3150]: Listen normally on 2 lo 127.0.0.1 UDP 123
Dec 19 16:21:54 srvloulou01.orcl ntpd[3150]: Listen normally on 3 eth0 192.250.240.107 UDP 123
Dec 19 16:21:54 srvloulou01.orcl ntpd[3150]: Listen normally on 4 lo ::1 UDP 123
Dec 19 16:21:54 srvloulou01.orcl ntpd[3150]: Listen normally on 5 eth0 fe80::a00:27ff:fecc:a520 UDP 123
Dec 19 16:21:54 srvloulou01.orcl ntpd[3150]: Listening on routing socket on fd #22 for interface updates
Dec 19 16:21:54 srvloulou01.orcl ntpd[3150]: 0.0.0.0 c016 06 restart
Dec 19 16:21:54 srvloulou01.orcl ntpd[3150]: 0.0.0.0 c012 02 freq_set ntpd 0.000 PPM
Dec 19 16:21:54 srvloulou01.orcl ntpd[3150]: 0.0.0.0 c011 01 freq_not_set
Dec 19 16:21:55 srvloulou01.orcl ntpd[3150]: io_setbclient: Opened broadcast client on interface #3 eth0
Dec 19 16:21:55 srvloulou01.orcl ntpd[3150]: 0.0.0.0 c614 04 freq_mode
Et dans journalctl je ne vois rien d’anormal.
/etc/ntp.conf :
[ RIEN DE MODIFIER AVANT ]
# Hosts on local network are less restricted.
restrict 192.250.240.0 mask 255.255.255.0 nomodify notrap
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server K2 burst
[RIEN DE MODIFIE APRES ]
J’ai essayé pas mal de petits changement dans /etc/ntp.conf mais qui n’ont rien données.
(Par exemple remplacer burst par iburst, ajouter restrict -6 ::1 et un bon nombre d'autre chose trouvé sur le net)
A tout hasard qq avec des connaissances ntp pourrait m’éclairer ?
Mon os : Oracle Linux 7
Linux srvloulou01.orcl 3.8.13-118.15.1.el7uek.x86_64 #2 SMP Fri Dec 2 09:02:33 PST 2016 x86_64 x8
6_64 x86_64 GNU/Linux
# plusieurs points
Posté par NeoX . Évalué à 3.
ta VM est sur quelle type d'hyperviseur ?
a-t-elle les guest additions (ou pilotes specifiques à ton hyperviseur) ?
j'ai deja vu le cas ou c'est simplement que l'hyperviseur ne donne pas un tick horloge stable, simplement parce que la vm dort, donc il ne lui donne pas du temps CPU (micro freeze en somme)
et au bout d'un moment ta machine est decalée, parfois meme trop decalée pour etre recuperable par NTP
[^] # Re: plusieurs points
Posté par Kangs . Évalué à 1.
J'utilise VirtualBox, sans aucun 'Guest Additions'.
Le problème se produit indépendamment de l'activité.
Au niveau de VirtualBox j'ai activé hpet, mais je n'ai pas vus de changement.
Si je résume le problème, sans ntpd d'actif l'horloge avance très rapidement.
Quand ntp est actif, il n'arrive plus au bout de 5 à 8mn à synchroniser l'horloge et elle se met à avancer très rapidement.
Ce qui me surprend le plus c'est que chrony fonctionne très bien, mais dans la doc RedHat il est fortement conseillé d'utiliser chrony sur une VM.
[^] # Re: plusieurs points
Posté par NeoX . Évalué à 2.
ben justement, si c'est conseillé, autant le faire, non ?
et si en plus cela fonction tres bien pourquoi s'en priver ?
[^] # Re: plusieurs points
Posté par Kangs . Évalué à 1.
Je n'est pas le choix.
[^] # Re: plusieurs points
Posté par NeoX . Évalué à 1. Dernière modification le 19 décembre 2016 à 21:57.
regarde si les guests additions ne permettent pas une synchronisation entre la machine hote et la machine virtuelle…
, et installe les
sinon tu n'as pas le choix ?
on a toujours le choix, et c'est l'avantage du logiciel libre, si un outil ne fait pas le boulot, un autre le fera tres bien.
un comparatif chrony vs les autres (fait par chrony, mais ca donne une idée)
https://chrony.tuxfamily.org/comparison.html
ensuite je penses que ton projet (stage ou pro) n'est pas de configurer une horloge sur un PC, mais une infra stable, avec d'autres machines qui vont avoir diverses fonctions…
donc si ntp ne fait pas son travail, utilise autre chose.
plusieurs references :
http://unix.stackexchange.com/questions/238709/difference-between-chronyd-and-ntpd
des graphs pour comparer et donc pouvoir argumenter aupres de ton boss/ton maitre de stage …
https://mlichvar.fedorapeople.org/clknetsim/chrony_ntp/
[^] # Re: plusieurs points
Posté par Kangs . Évalué à 1.
Non, je n'ai pas le choix, le soft détecte la présence de ntp. Si pas de ntp pas de soft et chrony et fortement n'est pas supporté. (Il existe une alternative, mais mon problème c'est qu'est ce qui fait que ntp dérive)
RedHat conseille chrony surtout parce-que c'est son soft maison, mais il est le premier à expliquer comment désinstaller chrony pour utiliser ntp et à faire des "Best Practices" et pas que pour Oracle.
[^] # Re: plusieurs points
Posté par NeoX . Évalué à 1.
triche,
installe chrony,
appelle le ntp
execute le 'nouveau ntp'
ou bien change de techno de virtualisation pour limiter le drift
[^] # Re: plusieurs points
Posté par Donk . Évalué à 3.
Dans la doc de virtualbox, il y a ça: https://www.virtualbox.org/manual/ch09.html#idm7891
[^] # Re: plusieurs points
Posté par Marotte ⛧ . Évalué à 1. Dernière modification le 20 décembre 2016 à 17:18.
Dans le cas où tu voudrais monter une VM qui servira de serveur de temps à tout un tas d’autres VM existantes, qui utilisent ntp par défaut, c’est appréciable de ne pas avoir à modifier toutes tes VM (en y installant chrony)… même si tu utilises puppet ou autre…
Par contre je pense effectivement que la piste des guest additions est la bonne.
Une rapide recherche : http://superuser.com/questions/688127/how-to-correctly-sync-time-in-linux-running-as-virtual-guest-after-host-resumes
Ce que la doc semble confirmer : https://www.virtualbox.org/manual/ch04.html#idm1948
Lien vers la doc et explication déjà donnée par d’autre, je me rends compte…
Notons que les fonctionnalités apportées par les guest additions ne sont pas libres.
# Synchronisation d'une VM ?
Posté par mazarini . Évalué à 1.
Bonsoir,
Un question peut être bête. On synchronise l'horloge de la machine physique et la machine physique et les vm utilisent la même horloge physique.
Plusieurs logiciels synchronisant la même horloge ne risquent pas de foutre le bordel ?
[^] # Re: Synchronisation d'une VM ?
Posté par Kangs . Évalué à 1.
Oui, c'est une très mauvaise idée d'avoir 2 mécanismes de synchronisation.
La synchronisation via le 'host' n'est viable que pour une VM simple communiquant peu, il est vraiment préférable de synchroniser via chrony (ntp c'est plus compliqué).
[^] # Re: Synchronisation d'une VM ?
Posté par mazarini . Évalué à 0.
Je crois que tu n'as pas compris mon interrogation.
Mon impression est que seul le host (ou une seule VM si le host ne le fait pas) doit gérer la synchronisation parce qu'il n'y a qu'une seul horloge. Cette horloge unique est utilisée aussi bien par le host que les VM.
Autrement, j'ai vu sur une de mes VM des messages d'erreur de systemd qui n'arrivait pas à communiquer avec des serveurs ntp (le port est fermé).
[^] # Re: Synchronisation d'une VM ?
Posté par Kangs . Évalué à 1.
Tu fais un choix, tu synchronises ta VM sur le host ou tu utilises ntp, avoir les 2 mécanismes n'est pas bon. Mais attention, au moins sur VBox et VmWare, la synchro par le host est bourrin.
Donc tu n'utilises pas ntp pour la synchro.
# Solution non commercial
Posté par Kangs . Évalué à 1.
Pour information, la version 5.1.12 de VirtualBox corrige le problème.
Pour les versions précédentes il fallait désactiver kvmclock & co.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.