¿Cuáles son los límites de ejecutar servidores NTP en máquinas virtuales?

Quiero configurar varios servidores horarios Stratum 2 en mi red local. Las máquinas virtuales sin duda serían una forma más económica de hacerlo que comprar tres servidores de 1U. ¿Qué limitaciones impondría hacerlo? Es decir, ¿en qué medida la precisión se verá afectada negativamente?

Además, mi instinto es que estos servidores de hora local deberían residir en diferentes máquinas físicas para mitigar cualquier irregularidad de hardware. ¿Es correcta esta intuición?

Editar Debo decir que por "máquinas virtuales" no me refería específicamente a VMware . Más bien, me refería al concepto general de instancias virtualizadas.

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.

Consulte el documento de cronometraje de vmware . Ejecutar un demonio NTP en una VM probablemente no sea una buena idea, especialmente si necesita un tiempo confiable.

desafortunadamente, ntp y virtualización no van muy bien juntas. los clientes están bien en la mayoría de los casos, sin embargo, el servidor ntp (esp str2 y superior) generalmente no funcionará de manera confiable en el servidor virtual.

Estoy comentando desde la perspectiva empresarial de xen y xen, pero creo que vmware / kvm será igual.

re diferentes servidores, sí, tiene razón, idealmente deberían estar en diferentes entornos también, de modo que la temperatura / humedad tampoco afecten la precisión, pero al menos no me molesto con eso. Tampoco olvides que hagas lo que hagas no será tan preciso como el reloj atómico adecuado, así que acepta esta desviación (muy leve).

Al ejecutar NTP en un entorno virtualizado, tendrá la suerte de lograr una precisión de 20 ms (eso es lo que hemos hecho con VMware). El sesgo del reloj virtualizado es malo, particularmente en un entorno virtualizado con contención de recursos.

Depende de cuán preciso sea necesario. Si solo le importa el segundo (por ejemplo, para servidores web), probablemente estará bien, siempre que no tenga contención de recursos. Si desea una precisión de milisegundos (como una base de datos ocupada, un servidor de registro, un proyecto de investigación), olvide los servidores de tiempo virtualizados.

Los servidores NTP siempre deben estar en hosts físicos. Debería tener al menos 3 de ellos mirando en un grupo (para que un servidor no autorizado sea rechazado por el grupo); y si es posible, obtenga su tiempo del GPS u otra fuente local de nivel 0 en lugar de hacerlo a través de Internet.