В инфраструктуре моей компании 5 центров обработки данных в удаленных местах.
В каждом удаленном месте есть пара серверов, которые содержат службы DNS и NTP и настроены на каждом из серверов в этом месте для получения вызовов DNS и NTP от этих двух серверов.
Все серверы - это машины CentOS 6.x.
Есть мотивация для создания избыточности между этими двумя серверами с точки зрения DNS и NTP.
Часть DNS покрыта, и у меня проблема только с NTP.
Каков правильный способ убедиться, что при выходе из строя одного сервера NTP второй / остальные серверы будут продолжать обслуживать клиентов, как будто ничего не произошло?
Я поискал в Google и нашел Решение RedHat чтобы установить один из серверов в качестве основного (настроив его в клиентах как «истинный»), но в случае отказа «истинного» (основного) сервера ... тогда он выйдет из строя, и клиенты не будут получать от него обновления NTP , так что это не просто избыточное решение.
Я хотел узнать, есть ли у кого-нибудь опыт настройки такого решения?
Редактировать # 1:
Для проверки ответа MadHatter я сделал следующее:
- Я остановил NTPd на сервере, который настроен как «предпочтительный» на каждом из клиентов NTP.
- Я жду, когда клиент NTP перестанет работать с этим сервером и начнет работать с партнерским сервером NTPd.
- я бегу
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 и по-прежнему обнаруживать фальшивки, выбрасывая одни сумасшедшие часы.