El simple hecho es que la precisión del reloj dentro de una VM todavía es realmente mala. Esto viene de algunos puntos, pero lo más importante es que la deriva del tiempo no es constante; El factor de deriva cambia de un momento a otro. NTP es un protocolo que tiene una compensación de reloj integrada, pero fue diseñado con un factor de deriva estático incorporado. Por ejemplo, si una máquina física pierde 12 segundos cada 30 días, NTP puede compensar eso y lo hace muy bien. Pero si esa máquina puede perder entre 4 y 70 segundos cada 30 días, NTP no es tan bueno para rastrear ese nivel de cambio.
Lo que hace que sea realmente difícil para NTP mantenerse al día en un entorno VM es que el reloj local que ve puede cambiar su factor de deriva en el transcurso de un minuto. Dependiendo de la frecuencia con la que esté verificando sus fuentes de tiempo padre, puede causar cambios importantes en el factor de deriva y hacer que se desincronice con mucha más frecuencia. Las cascadas de tiempo fuera de sincronización en toda su organización.
El NTP para una red local es un protocolo de impacto relativamente bajo con una huella de memoria muy pequeña, y puede acoplar felizmente sus otros servidores de infraestructura de red como sus servidores DNS y DHCP. Algunos enrutadores también pueden proporcionar la funcionalidad NTP, por lo que es posible que desee analizar eso.
Lo ideal es que desee dos servidores separados en ubicaciones separadas que se sincronicen con un conjunto diferente de servidores de estrato superior. También sería una muy buena idea que ambos servidores de tiempo estuvieran configurados para usar el otro servidor como un "par", lo que minimizará el impacto en el servicio de tiempo en caso de que una de las fuentes de tiempo aguas arriba salga mal; habrá un cambio de estrato pero al menos no informará fuera de sincronización. Y finalmente, sea amable con sus proveedores de tiempo aguas arriba y configure sus servidores para que pasen mucho tiempo entre encuestas una vez que el tiempo esté bien establecido. Este es el parámetro 'maxpoll' en la línea 'servidor', y es una potencia de dos en segundos entre intentos de sincronización.
Si absolutamente tuviera que usar máquinas virtuales para esto, configuraría no menos de tres de estos servidores NTP. Cada uno de ellos debe estar en un host diferente y, si es posible, en un centro de datos diferente. Al igual que con lo que acabo de sugerir, necesitan diferentes fuentes de tiempo y deberían verse entre sí. Luego configure todos sus clientes NTP para usar los tres como fuentes principales. Asegúrese de que sus valores de maxpoll sean lo suficientemente bajos como para nunca pasar más de una hora y media entre paquetes de sincronización fuera de la red y 30 minutos en la red. Es probable que al menos uno de los tres esté sincronizado en un momento dado. Para los clientes que solo pueden hablar con un host de tiempo, solo tendrán que soportar el evento ocasional fuera de sincronización. En general, la calidad del tiempo en este escenario no sería tan exacta como lo sería con los servidores físicos.
Si tuviera que estacionarme, diría que su tiempo de consenso en el entorno de VM puro probablemente estaría dentro de, oh, 30 a 100 ms de verdad. En un entorno puramente físico, su tiempo de consenso probablemente estaría dentro de los 10 ms una vez que los servidores de tiempo hayan estado activos el tiempo suficiente para establecerse.