Назад | Перейти на главную страницу

NTP: Как создать резервное решение для серверов NTP?

В инфраструктуре моей компании 5 центров обработки данных в удаленных местах.

В каждом удаленном месте есть пара серверов, которые содержат службы DNS и NTP и настроены на каждом из серверов в этом месте для получения вызовов DNS и NTP от этих двух серверов.

Все серверы - это машины CentOS 6.x.

Есть мотивация для создания избыточности между этими двумя серверами с точки зрения DNS и NTP.

Часть DNS покрыта, и у меня проблема только с NTP.

Каков правильный способ убедиться, что при выходе из строя одного сервера NTP второй / остальные серверы будут продолжать обслуживать клиентов, как будто ничего не произошло?

Я поискал в Google и нашел Решение RedHat чтобы установить один из серверов в качестве основного (настроив его в клиентах как «истинный»), но в случае отказа «истинного» (основного) сервера ... тогда он выйдет из строя, и клиенты не будут получать от него обновления NTP , так что это не просто избыточное решение.

Я хотел узнать, есть ли у кого-нибудь опыт настройки такого решения?

Редактировать # 1:

Для проверки ответа MadHatter я сделал следующее:

  1. Я остановил NTPd на сервере, который настроен как «предпочтительный» на каждом из клиентов NTP.
  2. Я жду, когда клиент NTP перестанет работать с этим сервером и начнет работать с партнерским сервером NTPd.
  3. я бегу ntpq -p на клиенте, чтобы увидеть изменения. Это результат ntpq -p:
[root@ams2proxy10 ~]# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.X.X.38      .INIT.          16 u    -  128    0    0.000    0.000   0.000
*10.X.X.39      131.211.8.244    2 u    2   64  377    0.123    0.104   0.220

Что такое "как в ntpq"? какую команду мне запустить, пожалуйста?

Редактировать # 2: Результат как:

[root@ams2proxy10 ~]# ntpq
ntpq> as

ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 64638  8011   yes    no  none    reject    mobilize  1
  2 64639  963a   yes   yes  none  sys.peer    sys_peer  3
ntpq>

Выход pe:

ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.X.X.38      .INIT.          16 u    -  512    0    0.000    0.000   0.000
*10.X.X.39      131.211.8.244    2 u   36   64  377    0.147    0.031 18874.7
ntpq>

Я подозреваю, что это не проблема: NTP уже устойчив к этому.

У вас нет «основного» NTP-сервера и некоторых дополнительных: у вас есть набор настроенных серверов. NTPd будет решать, какой из них надежен, который, скорее всего, будет предлагать хороший сигнал времени, и будет постоянно переоценивать свои решения.

Это набор привязок с моего сервера пула NTP за последний месяц или около того:

Как видите, большую часть времени состояние 6 (узел системы) занято зеленой линией, ntp0.jonatkins.com, который является сервером уровня 1, к которому я привязываюсь с разрешением (все мои другие серверы относятся к слою 2, поэтому NTPd предпочитает сервер более высокого уровня, если не действуют другие факторы).

Но вы можете увидеть провал в этой линии в начале 44 недели, а числовые значения под изображением подтверждают, что в течение периода графика ntp0.jonatkins.com упал до состояния 4 (outlyer), а linnaeus.inf.ed.ac.uk, который проводил большую часть своего времени в состоянии 5 (кандидат), тем не менее достиг максимума в 6 (равноправный сервер системы). (Линии не доходят до 4 / до 6, потому что это 2-часовые средние 5-минутные необработанные данные; предположительно, все, что произошло, длилось заметно меньше 2 часов и поэтому было сглажено.)

Это показывает, что без какого-либо вмешательства с моей стороны NTPd в какой-то момент решил, что его обычный партнер недостаточно надежен, и выбрал лучший альтернативный источник во время «простоя». Как только его предпочтительный партнер снова прошел внутренние тесты QA, он был восстановлен до статуса однорангового узла.

Четыре или более одноранговых узла NTP обеспечивают обнаружение фальшивки и избыточность n + 1. Это тоже Рекомендация Red Hat (хотя сейчас, похоже, это контент только для подписчиков).

Выберите 4 или более Интернет-источников или используйте проект NTP Pool. Добавьте источники не из Интернета, например часы GPS, если они у вас есть. Настройте все свои NTP-серверы на все эти источники.

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

Настройте все "клиентские" хосты для использования всех ваших серверов NTP. Настройте не менее 4 на каждого клиента.

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