Эта статья была изначально написана Вильямом Голубом
Это вторая часть серии из двух частей. Прежде чем читать это, вы должны вернуться и прочитать оригинальную статью « Синхронизация часов в кластере Cassandra Pt. 1 — проблема«. В нем я рассмотрел, как важны часы и как плохие часы могут быть в виртуализированных системах (таких как Amazon EC2) сегодня. В сегодняшнем выпуске я расскажу о некоторых недостатках стандартных установок NTP и о том, как их преодолеть.
Настройка демонов NTP
Как указано в моем последнем посте , относительный сдвиг среди часов имеет наибольшее значение. Независимая синхронизация с общедоступными источниками приведет к неоптимальным результатам. Давайте посмотрим на другие варианты, которые у нас есть, и насколько хорошо они работают. Желаемыми свойствами являются:
- Хорошая относительная синхронизация ; Требуется для синхронизации в кластере
- Хорошая абсолютная синхронизация ; Желательно или требуется, если вы общаетесь с внешними службами или предоставляете API для клиентов
- Надежность и высокая доступность ; Синхронизация часов должна выдерживать сбой экземпляра или определенные перебои в сети
- Простота в обслуживании ; Должно быть легко добавлять / удалять узлы из кластера без необходимости изменять конфигурацию на всех узлах.
- Сетевой этикет ; Хотя сам NTP очень скромен в использовании пропускной способности сети, это не относится к общедоступным серверам NTP. Вы должны уменьшить их нагрузку, если это возможно
Настройте весь кластер как сетку
NTP использует древовидную топологию, но позволяет подключать пул пиров для лучшей синхронизации на одном уровне нитей. Это идеально подходит для синхронизации часов относительно друг друга. Пиры определяются аналогично серверам в /etc/ntp.conf; просто используйте peerключевое слово « » вместо « server» (вы можете объединить серверы и одноранговые узлы, но об этом позже):
peer c0 iburst peer c1 iburst peer c2 iburst restrict 10.0.0.0 mask 255.0.0.0 # XXX Don't copy this blindly
Мы определяем, что узлы c0-c2 являются узлами на одном уровне и будут синхронизироваться друг с другом. Оператор restrict включает пиринг для локальной сети, предполагая, что ваши экземпляры защищены брандмауэром для внешнего доступа, но включены в кластере. NTP связывается по UDP через порт 123. Перезапустите демон NTP:
service ntp restart
И проверьте, как это выглядит в ntpq -p:
remote refid st t when poll reach delay offset jitter ============================================================================== *c0 11.2.21.77 2 u 29 1024 377 1.318 -0.536 1.767 +c1 11.26.233.10 3 u 133 1024 377 1.587 0.401 1.837 -c2 11.129.56.278 4 u 662 1024 377 0.869 0.010 1.641
Однако этот параметр не идеален. Каждый узел действует независимо, и вы не можете контролировать, какие узлы будут синхронизироваться. Вы вполне можете оказаться в ситуации меньших пулов внутри кластера, синхронизированных друг с другом, но расходящихся по всему миру.
Относительно новый бесхозный режим решает эту проблему путем выбора лидера, с которым синхронизируется каждый узел. Добавьте это утверждение в /etc/ntp.conf on all nodes:
top orphan 7
включить сиротский режим. Режим включается, когда нет доступного слоя сервера меньше 7.
Эта настройка в конечном итоге будет идеально синхронизировать часы друг с другом. Однако вы рискуете уйти от часов , и поэтому синхронизация по абсолютному времени является неоптимальной. NTP-демон корректно обрабатывает отсутствующие узлы, и поэтому высокая доступность удовлетворяется.
Ведение списка одноранговых серверов в конфигурации NTP и его обновление при каждом изменении в кластере не является идеальным с точки зрения обслуживания. Сиротский режим позволяет использовать широковещательный или многокастовой поиск Вещание может быть недоступно в виртуализированной сети, и, если оно есть, не забудьте включить аутентификацию. Manycast работает за счет поддержки сервера мультикаста и снижения устойчивости к сбоям узлов.
- + относительные часы (стабильные в бесхозном режиме)
- — абсолютные часы (риск побега)
- + высокая надежность (- для многокамерного сервера)
- — обслуживание (+ в автоматическом обнаружении бесхозного режима)
- + низкая нагрузка на сеть
Используйте внешний NTP-сервер и настройте весь кластер как пул
Учитывая отсутствие времени в качестве основного недостатка в предыдущем варианте, как насчет включения синхронизации с внешними серверами и улучшения относительных часов путем настройки пула между узлами?
Конфигурация в /etc/ntp.confбудет выглядеть так:
server 0.debian.pool.ntp.org iburst # External servers server 1.debian.pool.ntp.org iburst # http://www.pool.ntp.org/ server 2.debian.pool.ntp.org iburst server 3.debian.pool.ntp.org iburst peer c0 iburst # Peers in the cluster peer c1 iburst peer c2 iburst restrict 10.0.0.0 mask 255.0.0.0 # XXX don't copy this blindly
Как бы хорошо это ни выглядело, на самом деле это работает не так хорошо, как предыдущая опция . Вы получите синхронизированные абсолютные часы, но относительные часы не будут затронуты. Это объясняется тем, что алгоритм NTP обнаружит внешний источник времени как более надежный, чем источники в пуле, и не примет их как авторитетные.
- — относительные часы
- ? абсолютные часы (как будто все узлы синхронизируются независимо)
- + высокая доступность
- — поддержание
- — высокая нагрузка на сеть
Настроить централизованный демон NTP
Следующий вариант — выделить один NTP-сервер (главный сервер, возможно, работающий в отдельном экземпляре). Этот сервер синхронизируется с внешними серверами, а остальная часть кластера синхронизируется с этим.
Помимо включения брандмауэра вам не требуется никакой специальной настройки на главном сервере. На стороне клиента вам нужно будет указать имя экземпляра ядра (пусть оно будет 0.ntp). /etc/ntp.confФайл должен содержать следующую строку:
server 0.ntp iburst
Все экземпляры в кластере будут синхронизироваться только с одним главным сервером и, следовательно, с одним тактовым генератором. Эта настройка обеспечит хорошую относительную и абсолютную синхронизацию часов. Учитывая, что имеется только один главный сервер, в случае сбоя экземпляра более высокая доступность отсутствует. Использование отдельного статического экземпляра обеспечивает гибкость при масштабировании и ремонте кластера.
Вы можете дополнительно настроить бесхозный режим среди узлов в кластере, чтобы синхронизировать относительные часы в случае отказа основного сервера.
- + относительные часы
- + абсолютные часы
- — высокая доступность (улучшена в бесхозном режиме)
- — сопровождение (в случае, если экземпляр является частью масштабируемого кластера)
- + низкая нагрузка на сеть
Настроить выделенный пул NTP
Эта опция похожа на выделенный демон NTP, но на этот раз вы используете пул серверов NTP (основных серверов). Рассмотрим три экземпляра 0.ntp, 1.ntp, 2.ntp, каждый из которых выполняется в своей зоне доступности, а демон NTP настроен на синхронизацию с внешними серверами, а также друг с другом в пуле.
Конфигурация на одном из основных серверов 0.ntp будет содержать:
server 0.debian.pool.ntp.org iburst # External servers server 1.debian.pool.ntp.org iburst server 2.debian.pool.ntp.org iburst server 3.debian.pool.ntp.org iburst peer 0.ntp iburst # Our NTP pool peer 1.ntp iburst restrict 10.0.0.0 mask 255.0.0.0 # XXX don't copy this blindly
Клиенты настроены на использование всех основных серверов, то есть 0.ntp-2.ntp. Например, /etc/ntp.confфайл содержит следующие строки:
server 0.ntp iburst server 1.ntp iburst server 2.ntp iburst
Развертывая пул основных серверов, мы достигаем высокой доступности на стороне сервера (частичное отключение сети), а также на стороне клиента (сбой экземпляра). Это также облегчает обслуживание кластера, поскольку пул не зависит от масштабируемого кластера. Недостаток заключается в запуске дополнительных экземпляров. Вы можете избежать запуска дополнительных экземпляров, используя экземпляры, уже доступные за пределами масштабируемого кластера (например, статические экземпляры), такие как база данных или почтовый сервер.
Обратите внимание, что на основных серверах наблюдаются некоторые различия в синхронизации, как если бы каждый узел отдельно синхронизировался с внешними серверами. Установка их в качестве одноранговых узлов поможет при сбоях в сети, но не так сильно при синхронизации часов относительно друг друга. Поскольку у вас нет контроля над тем, какой главный сервер клиент выберет в качестве авторитетного, это приведет к ухудшению относительной тактовой синхронизации между клиентами, хотя и значительно ниже, чем при внешней синхронизации всех клиентов.
Одним из решений является использование preferмодификатора для изменения алгоритма выбора NTP. Предположим, мы изменили бы конфигурацию на всех клиентах:
server 0.ntp iburst prefer server 1.ntp iburst server 2.ntp iburst
Тогда все клиенты будут синхронизироваться с узлом 0.ntp и переключаться на другой, только если 0.ntp не работает. Другим вариантом является явная установка возрастающего числа слоев для всех основных серверов, при условии, что клиенты будут стремиться к серверам с более низкими уровнями. Это больше взломать, хотя.
- + относительные часы
- + абсолютные часы
- + высокая доступность
- + обслуживание
- + низкая нагрузка на сеть
- — требует статических экземпляров
Резюме
Если вы используете вычислительный кластер, вы должны рассмотреть возможность запуска собственного NTP-сервера. Разрешение всем экземплярам синхронизировать свои часы независимо приводит к плохой относительной синхронизации часов. Это также не считается хорошим сетевым этикетом, поскольку вы без необходимости увеличиваете нагрузку на общедоступные NTP-серверы.
Для более масштабируемого кластера лучше всего запустить собственный пул серверов NTP с внешней синхронизацией. Это обеспечивает идеальную относительную и абсолютную синхронизацию часов, высокую доступность и простоту обслуживания.
Наше собственное развертывание синхронизирует часы всех узлов с точностью до миллисекунды.