Me gustaría ejecutar un gran grupo de nodos en la nube (AWS, Heroku o quizás VMS autogestionado), cuyos relojes deben sincronizarse con una tolerancia predefinida en mente. Estoy buscando una tolerancia de quizás 200 ms. Eso significa que si tengo 250 nodos, la mayor diferencia de reloj entre cualquiera de los 250 nodos nunca debería exceder los 200 ms. Realmente no me importa la fecha / hora real con respecto al mundo. La solución tiene que ser tolerante a fallas y no debería depender de la precisión del reloj de ningún sistema; de hecho, es probable que ninguno de los relojes sea terriblemente precis

El requisito es lo suficientemente fuerte cuando, si por alguna razón se determina que la sincronización del reloj no es confiable para un nodo en particular, preferiría eliminar un nodo del clúster debido a la desincronización del reloj, por lo que ante cualquier sospecha de falla, yo ' me gustaría poder realizar algún tipo de apagado controlado de ese nodo.

Me encantaría usar algo como NTP, pero de acuerdo con el NTP problemas conocidos twiki:

NTP no fue diseñado para ejecutarse dentro de una máquina virtual. Requiere un reloj del sistema de alta resolución, con tiempos de respuesta a las interrupciones del reloj que reciben servicio con un alto nivel de precisión. Ninguna máquina virtual conocida es capaz de cumplir estos requisitos.

Y aunque el mismo twiki va a describir varias formas de abordar la situación (como ejecutar ntp en el sistema operativo host), no creo que pueda modificar el entorno lo suficiente usando AWS o en horoku para cumplir con las soluciones alternativas.

Incluso si no estaba ejecutando en máquinas virtuales, un gerente de operaciones de confianza que tiene años de experiencia ejecutando ntp me dice que ntp puede y dejará de sincronizar (o simplemente se equivocará) debido al mal desplazamiento del reloj local de vez en cuando. No sucede a menudo, pero sucede, y a medida que aumenta las máquinas, aumenta sus posibilidades de que esto suceda. AFAIK, detectar qué tan lejos estás requiere detener ntpd, ejecutar un comando de modo de consulta e iniciarlo nuevamente, y puede tomar mucho tiempo obtener una respuesta.

ara resumir: necesito una sincronización de reloj cuyo objetivo principal es el siguiente:

Funciona bien en máquinas virtuales donde el control operativo es limitado (es decir, "proveedores de servicios en la nube") Tolerancias de tiempo en el clúster en alrededor de 200 ms entre todos los participantesCapacidad para detectar un nodo defectuoso y reaccionar a eso de forma activa Tolerante a fallas (sin punto único de falla)Scalable (la cosa no puede caerse cuando agrega más nodos; definitivamente evite n ^ 2) Podría soportar cientos de nodose debe considerar que ninguno de los nodos tiene una noción de tiempo superior a cualquier otro nodo Está bien que todo el clúster se desplace (dentro de lo razonable), siempre que se desplace al unísono

e la descripción, parece que la Algoritmo de Berkeley podría ser la opción correcta aquí, pero ¿ya está implementado?

Nice to haves:

onfiguración mínima (registro automático de nodos para participar): importante para activar nuevos nodosHTML dashboard o (REST?) API que informa los nodos que participan en la sincronización del reloj y cuáles son las compensaciones de tiempo relativas Gráficos bonitos?