У меня есть серия внутренних серверов NTP; каждая другая машина в моей сети настроена для взаимодействия с этими серверами следующим образом:

# ntp.conf for client machines
server 0.ntp.internal iburst
server 1.ntp.internal iburst
server 2.ntp.internal iburst

Между тем эти внутренние NTP-серверы настроены для взаимодействия с NTP-серверами Amazon следующим образом:

# ntp.conf for the internal NTP servers
server 0.amazon.pool.ntp.org iburst
server 1.amazon.pool.ntp.org iburst
server 2.amazon.pool.ntp.org iburst
server 3.amazon.pool.ntp.org iburst

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

Я читал о пиринге NTP, но получаю много смешанных сообщений о том, что он на самом деле делает и поможет ли это уменьшить проблему смещения часов. Чаще всего я вижу, что установка сервера в качестве однорангового узла позволит ntpd рассматривать одноранговый узел как потенциальный источник времени, но это не заставляет два сервера пытаться объединить свои часы; однако я видел источники, говорящие об обратном. Я также видел источники, в которых говорилось, что если вы работаете вместе с серверами, вы не должны позволять им иметь один и тот же список server , что для меня не имеет смысла. Я не знаю, что думать.

Итак ... добавит ли этот раздел в мои внутренние NTP-серверы ntp.conf чтобы приблизить их часы друг к другу?

# adding to ntp.conf for 0.ntp.internal
peer 1.ntp.internal
peer 2.ntp.internal
# adding to ntp.conf for 1.ntp.internal
peer 0.ntp.internal
peer 2.ntp.internal
# adding to ntp.conf for 2.ntp.internal
peer 1.ntp.internal
peer 2.ntp.internal

Между прочим, я не могу пиринговать клиентские машины, так как они временные, поэтому даже если пиринг является решением, это можно сделать только с моими внутренними NTP-серверами.

|источник

1 ответ1

0

Как правило, вам нужно нечетное количество серверов и / или пиров. Алгоритм выбора NTP-сервера сложен, и я не нашел хорошей документации по нему.

Некоторые из факторов, которые рассматриваются, включают:

  • Уровень сервера. Нижние слои являются предпочтительными.
  • Стабильность сервера. Серверы с более стабильными данными предпочтительнее.
  • Насколько хорошо время сервера согласуется с другими серверами.

Вот несколько правил, которые я использую при настройке NTP:

  • Выполните одноранговую связь со всеми внутренними серверами, чтобы они знали друг друга и могли выбирать друг друга как сервер. По моему опыту одноранговые узлы, как правило, включаются в выбранный пул серверов.
  • Используйте один или три внешних сервера на каждом внутреннем сервере.
  • Если используются внутренние часы, выдумайте слой до 8 или выше. Используйте разные значения выдумки для каждого сервера.
  • При желании, выберите один сервер, если доступно несколько одинаково надежных серверов.

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

Пиринг клиентов на сервере вряд ли сработает. Уровень клиента обычно будет на один уровень выше, чем у сервера, поэтому он будет иметь меньший вес.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .