¿Necesito ejecutar un servidor NTP en cada VM?

18

¿No podrían los invitados de alguna manera heredar la hora del sistema del host?

Parece inútil ejecutar el mismo demonio para obtener los mismos resultados en la misma máquina varias veces, pero no encontré nada relacionado con el tiempo al leer artículos de KVM o Xen. Tengo entendido que el invitado obtiene el tiempo de host en el arranque, pero que luego puede separarse. Es eso correcto ?

Zimbatm
fuente
3
linux-kvm.org/page/KVMClock
Hauke ​​Laging
1
¿Supongo que te refieres a un cliente NTP?
Michael Hampton
1
@MichaelHampton: Sí, la distinción entre un cliente NTP y un servidor nunca fue realmente clara para mí, ya que el paquete ntp siempre proporciona ambos.
zimbatm
2
Relacionado con esta pregunta: en Debian y derivados, el openntppaquete tiene mucho más peso que el ntppaquete. No se une de forma predeterminada, por lo que solo actúa como un cliente, que es exactamente lo que necesitamos aquí.
zimbatm

Respuestas:

13

Esto es correcto. Cabe señalar que el tiempo no solo "puede" derivarse, sino que se alejará debido al hecho de que los intervalos entre las interrupciones del temporizador (en las que a menudo se basa el cronometraje en el sistema operativo) se estiran y comprimen como el hipervisor lo considere adecuado.

Una solución alternativa comúnmente utilizada en la mayoría de las plataformas de virtualización (servicios de integración Hyper-V, herramientas VMWare) es ejecutar un demonio en el invitado que sincroniza periódicamente los relojes con el host VM. Como señaló Hauke ​​en un comentario a su pregunta, KVM también proporciona un reloj paravirtualizado que necesitaría el controlador respectivo cargado en el sistema operativo invitado para funcionar.

Otras lecturas:

Cronometraje en máquinas virtuales VMWare (vmware.com)
Sincronización de reloj de invitados KVM (s19n.net)

el wabbit
fuente
Muchas gracias. Para aquellos en EC2, Xen también parece proporcionar una fuente de reloj: cat /sys/devices/system/clocksource/clocksource0/current_clocksource=> xen
zimbatm
Todavía se recomienda cronyd, incluso si se usa kvm-clock con el host como servidor y la VM como cliente.
akostadinov
21

En un mundo perfecto, sus invitados VM mantendrían el tiempo perfecto, o al menos tan perfecto como el host proporciona. Lamentablemente no vivimos en un mundo perfecto.

Según mi experiencia con prácticamente todos los hipervisores conocidos por el hombre, siempre ejecuto un cliente NTP en máquinas virtuales, sin excepción. Mi configuración habitual es ntpd con la opción -g, o ntpdate que comienza justo antes para los sistemas antiguos, para acelerar el reloj (que puede estar muy fuera de sincronización en el arranque del sistema).

KVM tiene una configuración casi perfecta, con su reloj en tiempo real paravirtualizado ; los invitados con el controlador apropiado (todos los Linux recientes, al menos) mantendrán el tiempo y el host. Pero aún así las cosas salen mal aquí: por ejemplo, el host puede no estar ejecutando NTP, el host puede tener una zona horaria incorrecta, el reloj del host puede estar simplemente mal, etc.

VMware e Hyper-V caen en el medio. Cada uno tiene una herramienta destinada a ejecutarse en el invitado que sincroniza el reloj con el host periódicamente, pero de nuevo, esto es vulnerable a cualquier problema existente con el reloj del host.

Los invitados en mi servidor Hyper-V de prueba también exhibieron un comportamiento extraño: incluso con los servicios de integración, el reloj del invitado se desplazaría más rápido que 500 ppm, evitando que el ntpd funcione ( considera que el reloj está loco si se mueve más rápido que esto ). Tuve que cambiar estos invitados a crony , lo que permite que este valor se ajuste.

Xen es lo peor a este respecto; no tiene absolutamente ninguna sincronización y es casi obligatorio ejecutar NTP en los invitados. (Me han dicho que las versiones muy recientes de Xen tienen algún tipo de sincronización pero aún no he trabajado personalmente con ella).

Las cosas empeoran si el hipervisor host no está bajo su control, como una nube pública. Estás a merced del proveedor con respecto al reloj del host, y si no son diligentes para mantenerlo sincronizado, pierdes.

Con todo eso, ejecutar clientes NTP en sus máquinas virtuales es bastante necesario si necesita incluso un reloj semi-preciso. NB: si ejecuta máquinas virtuales de Windows, obtenga un cliente NTP de terceros que ajuste el reloj continuamente; La pobre excusa para un cliente que viene con Windows solo ajusta el reloj una vez por semana , lo cual es completamente ridículo.

Michael Hampton
fuente
¿Se está ejecutando ntpdateen un trabajo cron diario suficiente o tiene que ser el demonio ntp?
AngerClown
44
Realmente necesitas algo para sincronizar el reloj continuamente, ya que podría sincronizarse lo suficiente en un día como para causar problemas. Y a algunos programas no les gusta que se pase el reloj.
Michael Hampton
El problema con el demonio ntp es que su objetivo principal es proporcionar tiempo a los demás y, por lo tanto, dejará de funcionar si el tiempo se separa demasiado. Realmente desearía que hubiera algo más como ntpdate que se ejecute continuamente y no se vincule a ningún puerto.
zimbatm
1
@JonasPfenniger Si ntpd no funciona para usted, intente usar chrony en su lugar (como se sugirió anteriormente). Se puede ajustar un poco más que ntpd para acomodar los escenarios extraños que vemos con las máquinas virtuales.
Michael Hampton
3
Si bien estoy de acuerdo con el 95% de lo que dijo, solo quería señalar que un cliente de Windows que usa NTP no se limita a un cambio de reloj por semana. La siguiente clave de registro le permite definir el intervalo de actualización de manera efectiva: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\UpdateIntervalel valor se define en segundos y generalmente se establece en 360000 (100 horas), pero puede configurarlo en 900 para sincronizar cada 15 minutos si sus aplicaciones son particularmente sensibles al tiempo. Recuerde reiniciar el servicio W32Time después.
kayjay
3

Recomendaría usar NTP porque es bien conocido y existe desde hace mucho tiempo. Ajustar el reloj no es trivial. NTP ha resuelto este problema.

La línea oficial de VMware es usar un mecanismo, con NTP preferido porque es más fino y toma medidas más pequeñas para ajustar el tiempo. La solución interna de VMware da pasos más grandes. Cuando corres ambos, podrían pelear entre ellos. Con la solución interna de VMware dando un gran paso y luego NTP ajustándola y retirándola un poco.

En la práctica, sin embargo, corremos ambos al mismo tiempo y todavía no he visto ningún problema.

$ 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
jris198944
fuente