Как мне установить синхронизацию часов в облаке (AWS, heroku и т. Д.) На многих узлах?

Я хотел бы запустить большой кластер узлов в облаке (AWS, Heroku или, возможно, самоуправляемую VMS), часы которых должны быть синхронизированы с заранее заданным допуском. . Я ищу допуск в 200 мс. Это означает, что если у меня есть 250 узлов, самая большая разница в часах между любым из 250 узлов никогда не должна превышать 200 мс. Меня действительно не волнует фактическая дата / время по отношению к миру. Решение должно быть отказоустойчивым и не должно полагаться на точность часов какой-либо одной системы - на самом деле, вполне вероятно, что ни один из часов не будет ужасно точным.

Требование достаточно сильное, если по какой-либо причине синхронизация часов определена как ненадежная для какого-либо конкретного узла, я бы предпочел удалить узел из кластера из-за десинхронизации часов - так что при любом подозрении на сбой, Я хотел бы иметь возможность выполнять контролируемое отключение этого узла.

Я бы хотел использовать что-то вроде NTP, но согласно известным проблемам NTP twiki :

NTP не предназначен для работы внутри виртуальной машины. Требуются системные часы с высоким разрешением и временем отклика на прерывания часов. которые обслуживаются с высокой точностью. Нет известных виртуальных машин способный удовлетворить эти требования.

И хотя тот же твики затем описывает различные способы решения ситуации (например, запуск ntp в ОС хоста), я не верю, что у меня будет возможность достаточно изменить среду с помощью AWS или на horoku. соблюдать обходные пути.

Даже если я не работал на виртуальных машинах, доверенный диспетчер операций, имеющий многолетний опыт работы с ntp, сказал мне, что ntp может и будет прерывать синхронизацию (или просто неправильно указывать время) из-за плохого дрейфа локальных часов каждый раз в в то время как. Это случается не часто, но случается, и по мере увеличения числа машин вы увеличиваете свои шансы на то, что это произойдет. AFAIK, для определения того, как далеко вы находитесь, требуется остановить ntpd, запустить команду режима запроса и снова запустить его, а получение ответа может занять много времени.

Подводя итог - мне нужна синхронизация часов, основная цель которой заключается в следующем:

• Хорошо работает в виртуальных машинах, где операционный контроль ограничен (например, «поставщики облачных услуг»).
• Допуски по времени в кластере при около 200 мс между всеми участниками
• Способность обнаруживать неисправный узел и активно реагировать на него
• Отказоустойчивый (без единой точки отказа)
• Масштабируемость (вещь не может упасть, когда вы добавляете больше узлов - определенно избегайте n ^ 2)
• Может поддерживать сотни узлов
• Ни один из узлов не должен считаться имеющим лучшее представление о времени по сравнению с любым другим узлом
• Это нормально, чтобы весь кластер дрейфовал (в пределах разумного) - пока он дрейфует синхронно

Из описания кажется, что Алгоритм Беркли может быть правильным выбором здесь, но реализован ли он уже?

Приятно иметь:

• Минимальная конфигурация (узлы автоматически регистрируются для участия) - важна для развертывания новых узлов.
• Панель мониторинга HTML или (REST?) API, который сообщает об узлах, участвующих в синхронизации часов и каковы относительные временные смещения
• Красивые графики?