.png)
Quiero configurar varios servidores horarios Stratum 2 en mi red local. Sin duda, las máquinas virtuales serían una forma más económica de hacer esto que comprar tres servidores de 1U. ¿Qué limitaciones impondría hacerlo? Es decir, ¿hasta qué punto la precisión se verá afectada negativamente?
Además, mi instinto es que estos servidores de hora local deben residir en diferentes máquinas físicas para mitigar cualquier irregularidad del hardware. ¿Es correcta esta intuición?
Editar Debo decir que por "máquinas virtuales" noespecíficamentesignificarVMware. Más bien me refiero al concepto general de instancias virtualizadas.
Respuesta1
Ahora es 2023 ytodas las respuestas anteriores a esta pregunta ahora son incorrectas(y lo han sido desde al menos finales de 2016), al menos en lo que respecta a las máquinas virtuales Linux. [Es posible que los siguientes consejos no se apliquen a las máquinas virtuales de Windows.]
Si está leyendo esto en 2023 o después, no crea en las afirmaciones de las respuestas de 2013 o antes sobre una precisión máxima de 20 a 100 ms. La sincronización de tiempo en las máquinas virtuales modernas puede lograr una precisión inferior a 1 milisegundo en una LAN y aproximarse a 1 milisegundo en una conexión a Internet de consumo.
Las siguientes preguntas de ServerFault contienen discusiones más actualizadas:
- Cosas a considerar al ejecutar servidores NTP públicos
- La configuración "menos mala" para Chrony como servidor NTP en una máquina virtual
Aquí hay algunos gráficos de compensación ilustrativos (presentados en orden cronológico) para respaldar mis afirmaciones. En algunos casos todavía tengo los archivos de registro sin procesar, que estaría más que feliz de proporcionar a cualquiera que quiera investigar por sí mismo. Tenga en cuenta la escala del gráfico en cada caso:
- Una máquina virtual que se ejecuta
ntpd
en una nube privada OpenStack bajo el hipervisor KVM (en algún tipo de Intel Xeon) a finales de 2016: - Una máquina virtual que se ejecuta
ntpd
en un host KVM independiente (en un Intel Celeron 1037U) a mediados de 2020: - Varias
t3a.micro
instancias de AWS (AMD) que se ejecutaránchronyd
a finales de 2021: - Varias
t4g.micro
instancias de AWS (ARM) que se ejecutaránchronyd
a finales de 2021: - Varias
Standard_B1s
instancias de Azure (Intel) que se ejecutaránchronyd
a principios de 2022: - Varios contenedores que se ejecutan
chronyd
en AWS ECS/Fargate (Intel) a finales de 2022:
Respuesta2
El simple hecho es que en 2010 la precisión del reloj dentro de una VM sigue siendo realmente mala. Esto proviene de algunos puntos, pero lo mejor 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 incorporada una compensación de reloj, pero fue diseñado con un factor de deriva estática 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 a NTP le resulte realmente difícil mantenerse al día en un entorno de 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 verifica sus fuentes horarias principales, puede causar cambios importantes en el factor de deriva y hacer que se desincronice con mucha más frecuencia. El tiempo desincronizado se produce en cascada en toda su organización.
NTP para una red local es un protocolo de impacto relativamente bajo con una huella de memoria muy pequeña y puede complementarse felizmente con otros servidores de infraestructura de red, como sus servidores DNS y DHCP. Algunos enrutadores también pueden proporcionar funcionalidad NTP, por lo que es posible que desees investigarlo.
Lo ideal sería tener dos servidores separados en ubicaciones separadas, cada uno de los cuales se sincroniza 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 'par', lo que minimizará el impacto en el servicio de tiempo en caso de que una de las fuentes de tiempo ascendentes salga mal; Habrá un cambio de estrato, pero al menos no informará desincronización. Y finalmente, sea amable con sus proveedores de tiempo ascendentes 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 fuera absolutamente necesario utilizar máquinas virtuales para esto, configuraría no menos de tres servidores NTP de este tipo. Cada uno de ellos debe estar en un host diferente y, si es posible, en un centro de datos diferente. Como ocurre con lo que acabo de sugerir, necesitan diferentes fuentes de tiempo y deben compararse entre sí. Luego configure todos sus clientes NTP para usar los tres como fuentes principales. Asegúrese de que sus valores 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 dentro de la red. Es muy 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 aguantar el evento ocasional de falta 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 hacer un cálculo aproximado, diría que su tiempo de consenso en el entorno de máquina virtual pura probablemente estaría entre 30 y 100 ms del verdadero. En un entorno puramente físico, su tiempo de consenso probablemente estaría dentro de los 10 ms una vez que los servidores hubieran estado activos el tiempo suficiente para que se estabilizara el tiempo.
Respuesta3
Ver el cronometraje de vmwaredocumento. Ejecutar un demonio NTP en una máquina virtual probablemente no sea una buena idea, especialmente si necesita tiempo confiable.
Respuesta4
Al ejecutar NTP en un entorno virtualizado, tendrá suerte si logra una precisión de 20 ms (eso es lo que hemos hecho con VMware). El desfase del reloj virtualizado es malo, particularmente en un entorno virtualizado con contención de recursos.
Depende de qué tan preciso necesites ser. Si solo le importa el segundo (por ejemplo, para servidores web), probablemente estará bien, siempre y cuando no tenga competencia por recursos. Si desea una precisión de milisegundos (como una base de datos ocupada, un servidor de registros, un proyecto de investigación), olvídese de los servidores de tiempo virtualizados.
Los servidores NTP siempre deben estar en hosts físicos. Debe tener al menos 3 de ellos emparejados en un grupo (para que el grupo rechace un servidor fraudulento); y, si es posible, obtenga su tiempo a través del GPS u otra fuente local de nivel 0 en lugar de hacerlo a través de Internet.