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

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

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

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

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

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

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

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

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

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

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

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

cloud ntp clock clock-synchronization
person Bernie Habermeier    schedule 05.01.2012    source источник
comment
+1. В прошлом году я столкнулся с подобными вопросами для облачной платформы Windows Azure. Вот мое описание (сообщение в блоге) на случай, если оно кому-нибудь поможет: blog.codingoutloud.com/2011/08/25/   -  person codingoutloud    schedule 23.04.2012
comment
Уважаемые будущие читатели: Служба поддержки Heroku автоматически синхронизирует время unix всех dyno с NTP в соответствии с заявкой в ​​службу поддержки, которую я открыл.   -  person noɥʇʎԀʎzɐɹƆ    schedule 10.08.2015

Ответы (2)


arrow_upward
2
arrow_downward

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

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

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

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

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

Между прочим, "отказ" 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.
person synthesizerpatel    schedule 05.01.2012
comment
Я бы хотел, чтобы мне не требовалась грубая синхронизация часов, но в данном случае, думаю, нужна. Представьте себе систему, которая обрабатывает много событийного типа. Большая часть этого передается через внешние посты в систему. Но представьте, что многие из этих событий ведут к будущим событиям, которые необходимо рассчитать по времени. Итак, событие X хочет запланировать событие Y через n секунд, и мы хотим, чтобы это событие Y могло быть обработано на любом узле в облаке. Так что, если вы сможете решить эту проблему без централизованного понятия времени, я буду рад это услышать. - person Bernie Habermeier; 06.01.2012
comment
Я настоятельно рекомендую вам взглянуть на zeromq, если вам нужно низкоуровневое решение для этого, его LGPL, хорошо документированная и мультиплатформенная, поддерживает uni и multicast. Если бы вы могли немного подробнее рассказать о том, что именно вы разрабатываете, я мог бы дать вам несколько лучших предложений. - person synthesizerpatel; 06.01.2012
comment
Посмотрел corosync, и я не думаю, что это может помочь в планировании будущих распределенных событий, но спред выглядит так, хотя, когда я смотрю на список рассылки пользователей распространения, я беспокоюсь о небольшой пользовательской базе, и ошибки, которые выглядят пугающе. - person Bernie Habermeier; 06.01.2012
comment
Я уже использую ZMQ :) Я люблю ZMQ. здесь описано, что Я пытаюсь сделать. Извините за внешнюю ссылку, но я не могу описать ее в 500 символов или меньше. - person Bernie Habermeier; 06.01.2012

arrow_upward
1
arrow_downward

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

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

person juice    schedule 28.08.2018