Dois-je exécuter un serveur NTP dans chaque machine virtuelle?


18

Les invités ne pouvaient-ils pas hériter en quelque sorte de l'heure système de l'hôte?

Il semble un peu inutile d'exécuter le même démon pour obtenir plusieurs fois les mêmes résultats sur la même machine, mais je n'ai rien trouvé de lié au temps lors de la lecture d'articles KVM ou Xen. D'après ce que je comprends, l'invité obtient l'heure de l'hôte au démarrage, mais il peut ensuite s'écarter. Est-ce exact ?



1
Je suppose que vous voulez dire un client NTP?
Michael Hampton

1
@MichaelHampton: Oui, la distinction entre un client NTP et un serveur n'a jamais été vraiment claire pour moi car le paquet ntp fournit toujours les deux.
zimbatm

2
En relation avec cette question: sur Debian et ses dérivés, le openntppaquet est beaucoup plus léger que le ntppaquet. Il ne se lie pas par défaut et agit donc comme un client, ce qui est exactement ce dont nous avons besoin ici.
zimbatm

Réponses:


13

C'est correct. Il convient de noter que non seulement le temps "peut" s'éloigner, mais qu'il s'éloignera du fait que les intervalles entre les interruptions de la minuterie (sur lesquelles le chronométrage sur le système d'exploitation est souvent basé) sont étirés et compressés comme l'hyperviseur le jugerait bon.

Une solution de contournement couramment utilisée sur la plupart des plates-formes de virtualisation (services d'intégration Hyper-V, outils VMWare) exécute un démon sur l'invité qui synchronise périodiquement les horloges avec l'hôte VM. Comme indiqué par Hauke ​​dans un commentaire à votre question, KVM fournit en outre une horloge paravirtualisée qui aurait besoin du pilote respectif chargé sur le système d'exploitation invité pour fonctionner.

Lectures complémentaires:

Chronométrage dans les machines virtuelles VMWare (vmware.com)
Synchronisation de l'horloge des invités KVM (s19n.net)


Merci beaucoup. Pour ceux sur EC2, Xen semble également fournir une source d'horloge: cat /sys/devices/system/clocksource/clocksource0/current_clocksource=> xen
zimbatm

Toujours chronyd est recommandé même si kvm-clock est utilisé avec l'hôte en tant que serveur et la machine virtuelle en tant que client.
akostadinov

21

Dans un monde parfait, vos invités VM garderaient un temps parfait, ou au moins aussi parfait que l'hôte le leur fournit. Malheureusement, nous ne vivons pas dans un monde parfait.

Sur la base de mon expérience avec pratiquement tous les hyperviseurs connus de l'homme, je lance toujours un client NTP sur des machines virtuelles, sans exception. Ma configuration habituelle est ntpd avec l'option -g, ou ntpdate commençant juste avant pour les anciens systèmes, pour faire avancer l'horloge (qui peut être loin d'être synchronisée au démarrage du système).

KVM a une configuration presque parfaite, avec son horloge en temps réel paravirtualisée ; les invités avec le pilote approprié (tout Linux récent, au moins) garderont le temps ainsi que l'hôte. Mais les choses tournent mal ici: par exemple, l'hôte peut ne pas exécuter NTP, l'hôte peut avoir un fuseau horaire incorrect, l'horloge de l'hôte peut être tout simplement fausse, etc.

VMware et Hyper-V se situent au milieu. Chacun a un outil destiné à être exécuté sur l'invité qui synchronise l'horloge avec l'hôte périodiquement, mais là encore, il est vulnérable à tout problème existant avec l'horloge de l'hôte.

Les invités sur mon serveur Hyper-V de test ont également présenté un comportement étrange: même avec les services d'intégration, l'horloge invité dériverait plus vite que 500 ppm, empêchant ntpd de fonctionner ( il considère l'horloge comme folle si elle dérive plus vite que cela ). J'ai dû passer ces invités en chrony , ce qui permet d'ajuster cette valeur .

Xen est le pire à cet égard; il n'a absolument aucune synchronisation et l'exécution de NTP dans les invités est à peu près nécessaire. (On me dit que les versions très récentes de Xen ont une sorte de synchronisation mais ne l'ont pas encore personnellement utilisé.)

Les choses empirent simplement si l'hyperviseur hôte n'est pas sous votre contrôle, comme un cloud public. Vous êtes à la merci du fournisseur en ce qui concerne l'horloge hôte, et s'il ne fait pas preuve de diligence pour la maintenir synchronisée, vous perdez.

Avec tout cela, exécuter des clients NTP dans vos machines virtuelles est à peu près nécessaire si vous avez besoin d'une horloge semi-précise. NB: Si vous exécutez des machines virtuelles Windows, procurez-vous un client NTP tiers qui ajuste l'horloge en continu; la mauvaise excuse pour un client fourni avec Windows ne règle l'horloge qu'une fois par semaine , ce qui est tout à fait ridicule.


Est-ce que l'exécution ntpdatedans un travail cron quotidien est suffisante ou doit-il s'agir du démon ntp?
AngerClown

4
Vous avez vraiment besoin de quelque chose pour synchroniser l'horloge en continu, car il pourrait être suffisamment éloigné de la synchronisation en une journée pour vous causer des problèmes. Et certains programmes n'aiment pas faire avancer l'horloge.
Michael Hampton

Le problème avec le démon ntp est qu'il est principalement destiné à donner du temps aux autres et cessera donc de fonctionner si le temps s'écarte trop. Je souhaite vraiment qu'il y ait quelque chose de plus comme ntpdate qui fonctionnerait en continu et ne lierait aucun port.
zimbatm

1
@JonasPfenniger Si ntpd ne fonctionne pas pour vous, essayez plutôt d'utiliser chrony (comme suggéré ci-dessus). Il peut être réglé un peu plus que ntpd pour s'adapter aux scénarios étranges que nous voyons avec les machines virtuelles.
Michael Hampton

3
Bien que je sois d'accord avec 95% de ce que vous avez dit, je voulais juste souligner qu'un client Windows utilisant NTP n'est pas limité à un changement d'horloge par semaine. La clé de reg suivante vous permet de définir efficacement l'intervalle de mise à jour: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\UpdateIntervalLa valeur est définie en secondes et est généralement définie sur 360000 (100 heures), mais vous pouvez la définir sur 900 pour qu'elle se synchronise toutes les 15 minutes si vos applications sont particulièrement sensibles au facteur temps. N'oubliez pas de redémarrer le service W32Time par la suite.
kayjay

3

Je recommanderais d'utiliser NTP car il est bien connu et existe depuis longtemps. Le réglage de l'horloge n'est pas anodin. NTP a résolu ce problème.

La ligne officielle de VMware consiste à utiliser un mécanisme, NTP étant préféré car il est plus fin et prend des mesures plus petites pour régler l'heure. La solution VMware interne prend des mesures plus importantes. Lorsque vous exécutez les deux, ils pourraient se battre. La solution interne VMware franchit une étape importante, puis NTP l'ajuste et la reprend un peu.

Dans la pratique, cependant, nous courons les deux en même temps et je n'ai pas encore vu de problème.

$ ntpq   
ntpq> peers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
something.org  172.2.1.5          2 u   57   64  377    1.597   -2.409   5.952


$  vmware-toolbox-cmd  timesync status
Enabled


$ vmware-toolbox-cmd help timesync
timesync: functions for controlling time synchronization on the guest OS
Usage: vmware-toolbox-cmd timesync <subcommand>

Subcommands:
  enable: enable time synchronization
  disable: disable time synchronization
  status: print the time synchronization status
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.