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

Локальные или общедоступные NTP-серверы?

Для относительно большой сети (тысячи хостов) - каковы аргументы за и против запуска локально управляемого (пула) сервера (ов) NTP (возможно, периодически настраиваемого через какой-либо общедоступный сервер NTP) и использования всех других хостов в сети что (пул) серверов NTP вместо того, чтобы все хосты просто использовали общедоступные серверы NTP напрямую, скажем, через ntp.pool.org?

Помимо плюсов и минусов, что сегодня является типичной передовой практикой?

Лучше всего запустить собственный пул серверов NTP, настроенных на синхронизацию с общедоступными серверами NTP. В случае, если ваша организация потеряет доступ в Интернет, вы не захотите, чтобы ваши часы были перекошены. Кроме того, было бы грубо устанавливать тысячи хостов на общедоступные серверы, когда вы можете (и должны) использовать зеркало.

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

РЕДАКТИРОВАТЬ: Поскольку было обсуждение этого, вот некоторые аппаратные средства:

Любое оборудование, поддерживающее PPS, похоже, работает на современном ntpd. Это включает в себя некоторые устройства GPS, хотя это кажется редкостью, по крайней мере, так же редко, как в наши дни серийные устройства GPS. Однако есть аппаратные устройства, которые продаются специально для этой функции, в том числе один продукт под названием TSync-PCIe. Согласно сайту производителя:

TSync-PCIe предлагает несколько конфигураций пакета синхронизированного считывателя / генератора временного кода, предлагая гибкость и легкую интеграцию точного времени во встроенное вычислительное приложение. Выберите синхронизацию с IRIG (и другими аналогичными временными кодами), GPS (внутренние или внешние приемники) или протоколом точного времени (PTP / IEEE-1588v2). - Ссылка на сайт: http://i564f.6o.to

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

Лучшая практика: установите 2 (или более) хоста NTP в вашем местоположении, подключитесь к ним. Пусть они синхронизируются как минимум с 4 (желательно до 8) внешними серверами от 0.pool.ntp.org до 3.pool.ntp.org. Если вы используете более четырех, вам следует настроить частоту опроса членов пула.

Вот отредактированная версия моего ntp.conf:

server 0.us.pool.ntp.org minpoll 8 maxpoll 14
server 1.us.pool.ntp.org minpoll 8 maxpoll 14
server 2.us.pool.ntp.org minpoll 8 maxpoll 14
server 3.us.pool.ntp.org minpoll 8 maxpoll 14

peer ntp2.example.com

driftfile /var/db/drift.ntp
logfile /var/log/ntp.log
logconfig +sysall +syncall

Вы можете опустить аргументы minpoll и maxpoll, я добавляю их, чтобы мне было легче на этих серверах. Значения - 2 ^ n секунд, где n - аргумент; эти значения выше значений по умолчанию (6 и 10), потому что я уже опросил 12 разных серверов между моими тремя хостами NTP.

Если вас очень беспокоит точность, вы также можете добавить следующее:

server tick.usno.navy.mil prefer minpoll 10 maxpoll 16

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

Как уже упоминалось, для тысяч внутренних хостов предоставление собственных серверов времени - лучший способ. По таким причинам, как (как уже упоминалось):

  • структура: настройте время по своему усмотрению; с как можно большим количеством источников страты
  • надежность: настройте систему NTP, чтобы она была надежной по мере необходимости; использование собственных источников часов (GPS) и / или источников NTP с разными маршрутами
  • вежливость: доброе отношение к принимающей организации внешних источников времени; меньше нагрузки для них
  • производительность: ограничение внешнего сетевого трафика NTP до нескольких хостов (незначительная проблема)
  • безопасность: ограничение сетевого трафика NTP извне до нескольких защищенных хостов

Что касается лучших практик:

Из http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm, вот рекомендуемая структура для источников только NTP.

EDITED - за Пола Гира и комментарий после диаграммы на веб-сайте ntp.org

 1a  1b     1c  1d     1e  1f      outside   
..\ /...\../..\/..\.../.\./...............  
   2a ---p--- 2b ---p--- 2c        inside   (stratum 2 has many stratum 1 sources)
    \   /|\   /|\  /|\  /
          ntp clients

ОРИГИНАЛЬНАЯ диаграмма

 1a  1b     1c  1d     1e  1f      outside
. \ / ...... \ / ...... \ / ..............
   2a ---p--- 2b ---p--- 2c        inside
  /|\        /|\        /|\
 / | \      / | \      / | \
3a 3b 3c   3e 3f 3g   3h 3i 3j

Key: 1 = stratum-1, 2 = stratum-2, 3 = stratum-3, p = peer

Дополнительная информация по настройке NTP-сервера взята из http://www.pool.ntp.org/join/configuration.html . Примеры:

  • Настроить около 5 серверов
  • Используйте стандартный ntpd
  • Не используйте ЛОКАЛЬНЫЙ драйвер часов
  • использовать источники времени NTP, которые находятся ближе всего к вам географически / по сети, и с низким числом слоев

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

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

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

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

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

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

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

Хорошая причина для запуска вашего собственного NTP-сервера (ов) в большой сети - убедиться, что все ваши машины согласовывают правильное время. Наличие большого количества систем со своими собственными настройками для внешних серверов времени (или все с использованием разных участников pool.ntp.org) может привести к небольшим различиям во времени в системах, что может привести к проблемам.

Другая веская причина заключается в том, что наличие собственного сервера (ов) NTP означает, что синхронизированное время будет оставаться доступным с нескольких (отслеживаемых!) Серверов, когда внешний канал выходит из строя или перегружен трафиком.

Все мое мнение как таймгика.