Правильная настройка NTP для нескольких серверов


9

У меня около 20 серверов Linux в небольшой сети, и мне нужно, чтобы их часы были прилично близко друг к другу (например, в течение 20 мс). Я начал с каждой из них, синхронизированной с europe.pool.ntp.org, и работа сделана.

Теперь у меня есть два вопроса:

  1. Я заметная ноша для бассейна? Т.е. имеет ли это какое-то заметное значение для пула, если я бью с 20 серверов или с 2?
  2. Если это что-то меняет, какие настройки / конфигурации будут синхронизировать мою подсеть и пул под небольшой нагрузкой? Есть рекомендации для больших сетей ( http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm#AEN3101 ), но я не нашел ни одной для небольших сетей.

1
Обычно у вас должен быть один или два внутренних сервера времени, с которыми вы синхронизируете свою внутреннюю сеть. Ваши два внутренних сервера могут иметь peerотношения. См. Например, ntp.org/ntpfaq/NTP-s-config-adv.htm#AEN3101
Марки,

Спасибо за комментарии и ссылку Марки. Что касается ссылки, она отмечает, что это для "огромной сети", что, конечно, не в моем случае. Что касается вашего предложения: я не думаю, что один внутренний сервер времени является хорошей идеей (единая точка отказа), но 2 выглядят как хорошая идея. Можете ли вы объяснить, что такое отношения со сверстниками (или предоставить ссылку)?
ndemou

Следует также отметить, что я определенно не эксперт по NTP - отнюдь нет :-)
ndemou

Не повредит, если вы немного погуглите о том, что такое пэр. Обратите внимание, что этот сайт ничего не размещает на серебряном блюде, когда люди вообще ничего не исследуют.
Марки

Не поймите меня неправильно, я сделал свою домашнюю работу, но NTP - одна из тех тем, где большая часть документации либо слишком проглатывает (это ntp.conf - просто используйте ее), либо слишком глубоко (50 страниц теории работы, чтобы прочитать ее перед вами) может начать понимать основные факты).
ndemou

Ответы:


8
  1. Я заметная ноша для бассейна? Т.е. имеет ли это какое-то заметное значение для пула, если я бью с 20 серверов или с 2?

Учитывая, что пул постоянно нуждается в серверах в течение многих лет (см. [1]), я бы сказал, что хотя 2 или 20 серверов на самом деле не имеют значения, вы всегда должны помнить, что вы не одиноки. Так что вам лучше подумать о 1000 администраторах, в этом случае мы говорим о 2000 или 20000 серверах, и это имеет значение.

  1. Если это что-то меняет, какие настройки / конфигурации будут синхронизировать мою подсеть и пул под небольшой нагрузкой?

Вы должны синхронизировать два [2] сервера в вашей сети с пулом (назовем их Первичными NTP-серверами ), а затем синхронизировать все остальные серверы с этими двумя. Этот метод также имеет преимущество в том, что время между всеми вашими серверами будет более точно согласовано (в пределах менее 1 мсек). Это соответствует лучшим практикам IETF .

1) Конфигурация для основных серверов NTP

Замените строки serverand restrictвашего ntp [d] .conf следующим текстом, а остальные оставьте по умолчанию для вашего дистрибутива [3]:

server 10.11.12.1  iburst peer
#      ^^^^^^^^^^^
#      The LAN IP of the _other_ Primary NTP server 
server 0.europe.pool.ntp.org 
server 1.europe.pool.ntp.org 
server 2.europe.pool.ntp.org 
server 3.europe.pool.ntp.org 
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1

Обратите внимание, что эта конфигурация также позволяет хостам со всего Интернета запрашивать время вашего хоста с помощью запросов NTP. Используйте свой брандмауэр, если не хотите. В моем примере 10.11.12.1 и 10.11.12.2 - это IP-адреса первичных серверов NTP (у них две сетевые карты, одна из которых обращена к общедоступному Интернету, а другая - в локальную подсеть 10.11.12.x). Каждый первичный NTP-сервер имеет другой, объявленный как одноранговый (в основном одноранговый сервер означает и сервер, и клиента - вы используете другой хост в качестве источника времени, а другой хост также использует вас в качестве источника времени). Поэтому настройте IP-адрес в 1-й строке, чтобы конфигурация каждого основного NTP-сервера указывала на другой в качестве равноправного. См. [4] относительно моего выбора использовать 4 сервера.

2) Конфигурация для всех остальных серверов

2А) Если у вас есть два сетевых интерфейса

Вам лучше использовать 2-й интерфейс для создания локальной подсети (например 10.11.12.0/24) и использовать ее для запросов NTP. В этом случае ограничительные линии могут быть более узкими. Итак, еще раз замените строки serverи restrictвашего ntp [d] .conf на следующее, а остальные оставьте по умолчанию для вашего дистрибутива [3]:

restrict -4 default ignore
restrict -6 default ignore
restrict 10.0.0.0 mask 255.0.0.0 kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1

# Only use our Primary NTP Servers
server 10.11.12.1 iburst
server 10.11.12.2 iburst
#      ^^^^^^^^^^
#      The IPs of your 2 Primary NTP Servers

2B) Если у вас нет двух сетевых интерфейсов

Вы должны использовать приведенные ниже строки ограничения (и прочитайте примечание об использовании вашего брандмауэра, чтобы заблокировать доступ к вашим NTP-серверам выше). Итак, еще раз замените строки serverи restrictвашего ntp [d] .conf на следующее, а остальные оставьте по умолчанию для вашего дистрибутива [3]:

restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1

# Only use our Primary NTP Servers
server 10.11.12.1 iburst
server 10.11.12.2 iburst
#      ^^^^^^^^^^
#      The IPs of your 2 Primary NTP Servers

Ноты

[1] В период с 2006 по 2012 год они постоянно просят присоединить больше серверов: запрос 2006 года , 2009 год и 2012 год . Проверьте www.pool.ntp.org для обновления на текущий статус.

[2] Два первичных сервера NTP предлагаются только в качестве простого способа обеспечения избыточности без сложных механизмов высокой доступности. Вы можете выбрать 3 или 4 по другим причинам (снова ознакомьтесь с рекомендациями IETF )

[3] На практике, независимо от вашего дистрибутива, единственное, что вам нужно включить в конфигурацию ntpd, - это строка, определяющая каталог для размещения дрейфового файла и его имени - например driftfile /var/lib/ntp/ntp.drift. Я протестировал свое решение в CentOS, Debian и Ubuntu. Я думаю, это работает в большинстве других дистрибутивов.

[4] Я настроил 4 пула серверов, следуя рекомендациям . Конфигурирование более 4 серверов технически приемлемо, но вы увеличите нагрузку на пул NTP для сомнительного увеличения доступности, так что не делайте этого. В лучших практиках я вижу, что «начиная с ntp-4.2.6 директива 'pool' будет приводить к" достаточному количеству "ассоциаций, чтобы обеспечить надежную службу времени", поэтому если вы используете .pool. адреса, как я здесь и ntp> = 4.2.6 точное количество строк сервера, вероятно, не имеет значения.

Рэнт О! Я ненавижу NTP (кроме того, что мне нравится, что это работает). Официальная документация полна устаревшей информации, и у них есть "как мне ее использовать?" информация, смешанная с научными подробностями о внутренностях. И я также ненавижу, как на restrict 127.0.0.1самом деле означаетallow everything for 127.0.0.1


История обновлений

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


кредиты

Комментарии и ответы от пользователей SF Marki и Sven послужили хорошей отправной точкой для этого ответа. Спасибо им обоим.


1
+1 от меня. Я запускаю сервер пула и не могу переоценить правильность этого поста, за исключением того, что iburstэто раздражающий параметр для использования на публичных серверах, поэтому, пожалуйста, не делайте этого (хотя это не так раздражает, как burst). Администраторы пула делают вам одолжение, не зная, кто вы есть, и без какой-либо компенсации самим себе, просто для лучшего функционирования Интернета. Если вы, работая усерднее, можете облегчить им жизнь, вы обязаны сделать это.
MadHatter

Спасибо MadHatter. Что касается iburst, я подумал, что это нормально для типичных "всегда включенных" серверов. У вас есть какие-либо ссылки в поддержку вашего совета не использовать эту опцию? (Я проверил www.pool.ntp.org/en/use.html, а также погуглил в течение 10 минут, но не нашел ничего убедительного)
ndemou

Я с удовольствием поделюсь своей статистикой движения; быстрый пример показывает, что неправильно сконфигурированные хосты, то есть хосты, которые передают чаще, чем раз в минуту, составляют около 45% моих клиентов, но отвечают за около 75% трафика. В основном это будут серверы, которые используют burst, но даже iburstговорят (со ntpdстраницы руководства ), что « с этой опцией обмениваются залпом сообщений, чтобы обработать данные и установить часы примерно через 10 с ». Использование iburstговорит: « Быстро настроить мои часы важнее, чем поддерживать низкую нагрузку на ваш сервер », и это невежливо.
MadHatter

Вы правы насчет "залпа сообщений", но, насколько я понимаю, этот всплеск произойдет только во время запуска демона NTP и (возможно), если сервер пула на мгновение недоступен (я из исходного состояния). Вот аннотация со страницы Archi wiki NTPd: «Опция iburst рекомендуется и отправляет пакет пакетов, только если он не может установить соединение с первой попытки. Опция burst всегда делает это, даже с первой попытки, и никогда не должен использоваться без явного разрешения и может привести к занесению в черный список ".
ndemou

Вы правы, iburstэто гораздо менее нежелательно, чем burst. Моя точка зрения заключается в том, что когда вы используете чужой ресурс бесплатно, есть аргумент, что вы должны наклоняться назад, чтобы быть внимательным; может показаться, что недостаточно просто быть недостаточно внимательным. Я согласен, что считается, что это лучшая практика, но в этих документах не учитывается, являются ли вышестоящие серверы, с которыми вы синхронизируете, частью вашего предприятия или нет; они диктуют лучшую техническую практику (которую я согласен использовать iburst), а не лучшую социальную практику.
MadHatter

6

Обычный подход для этого - использовать многоуровневую настройку - вы синхронизируете один или два сервера в своей сети с пулом, а затем используете их в качестве локального источника времени. Эти уровни называются стратами в NTP lingo.

Кроме того, подумайте об этом: если вы сделаете это так, как описали, это будет не очень заметно, но если 1000 сайтов вашего размера начнут это, у вас останется 20 000 по большей части ненужных запросов, и в какой-то момент это станет заметно.

Читать http://en.wikipedia.org/wiki/Network_Time_Protocol


Но рассмотрим альтернативную точку зрения - еще двадцать клиентов на вершине миллионов существующих клиентов - это почти ничего.
200_success

2
Как он сказал, если все начнут так думать ...
Марки

Но в какой момент вы останавливаетесь? Подумайте обо всех устройствах класса Linksys, которые поставляются предварительно настроенными для использования pool.ntp.org. Конечно, трафик DNS превышает трафик NTP. Вы также должны кэшировать DNS локально? Даже DNS-трафик, вероятно, будет минимальным по сравнению с остальной частью вашего трафика.
200_success

@ 200_success: Это не стоит обсуждать, но большинство устройств класса «Linksys» действительно кешируют DNS-трафик локально, и они запрашивают у своего DNS-провайдера, который также кеширует ...
Sven

1
Если Linksys поставляет устройства, которые синхронизируются с ними, ntp.pool.orgони нарушают условия пула ; если они сделали это правильно, обратившись к зоне вендора (см. ссылку), то ожидается, что они также внесут свой вклад в проект пула пропорционально их нагрузке (опять же, см. ссылку).
MadHatter
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.