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

Question

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

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

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

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

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

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

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

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

Из описания это похоже на Berkeley Алгоритм может быть правильным выбором, но он уже реализован?

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

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

Answer 1

Поскольку в разделе часто задаваемых вопросов для NTP конкретно указывается, почему синхронизация времени NTP не работает «правильно» на виртуальных машинах, это, вероятно, непреодолимая проблема.

Большинство машин имеют RTC (реальныйчасы на них, на ПК это то, как вы сохраняете время, чтобы у вас было «грубое» предположение о том, какое время, если ntp недоступен, после загрузки системы есть «тиковые» часы с более высоким разрешением- это то, что устанавливает NTP.

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

Вероятно, неоптимальный дизайн - попытаться применить синхронизацию ntp на виртуальных машинах, если дельта машины A и B равна 200 мс, а дельта компьютеров B и C равна 200 мс, а C может находиться на расстоянии 400 мс от A. Вы не можете контролироватьтот.

Вам лучше использовать централизованную систему обмена сообщениями, например, zeromq, чтобы синхронизировать всех с очередью заданий, это будет более затратно, но полагаться на время системного тика в лучшем случае непросто.Существует много кластерных решений, в которых учитывается участие кластера с использованием всевозможных надежных механизмов, обеспечивающих синхронизацию всех, взгляд на коросинхронизацию или распространение. Они уже решили это для таких вещей, как двухфазные фиксации.

Между прочим, ntp «сдаваться», когда дрейф слишком велик, можно обойти, дав ему команду «хлопать» время до нового значения, а не «убивать».По умолчанию ntp будет постепенно обновлять системное время, чтобы учесть его отклонение от «реального времени».Я забыл, как настроить это в ntpd, но если вы используете ntpdate, флаг -B

-B      Force the time to always be slewed using the adjtime(2) system call, even if the measured 
offset is greater than +-128 ms.  The default is to step the time using settimeofday(2) if the offset 
is greater than +-128 ms.  Note that, if the offset is much greater than +-128 ms in this case, it
can take a long time (hours) to slew the clock to the correct value.  During this time, the host 
should not be used to synchronize clients.

Answer 2

После многих месяцев борьбы с NTP на виртуальных машинах мы перешли на использование хроники https://chrony.tuxfamily.org.. Я обнаружил, что во многих отношениях он намного превосходит ntpd (настройка, управление, документация, проблемы с часы vm дрейфуют часто и резко).

Используй хрони и не оглядывайся назад :)