У меня около 20 серверов Linux, и я хочу синхронизировать все их часы с одним сервером NTP, который находится в той же стойке и коммутаторе, что и мои серверы. Ничего не виртуализировано.
У наших администраторов возникают проблемы с синхронизацией часов на разных машинах ближе, чем примерно 500 мс. Я бы догадался, а эта почта подразумевает, что мы должны иметь возможность синхронизировать Linux-боксы с точностью до 2 мс от источника и друг друга.
Мои ожидания от NTP необоснованны? Любые намеки на то, что администраторы должны делать / проверять?
У меня есть хостинговая компания, и мы делаем именно это. Вот как мы этого добиваемся.
Для начала вам понадобится главный источник NTP. Так что один из ваших серверов Linux станет главным. Я бы создал запись DNS A с именем time.example.com (при условии, что example.com является доменом). Таким образом, если ваш хозяин двинется, вам не нужно обновлять остальные 19 серверов.
На главном сервере вам необходимо иметь правильно настроенный файл ntp.conf.
Вот как выглядит один из наших основных файлов /etc/ntp.conf. Обратите внимание, что это центр обработки данных с частным адресным пространством (RFC1918), использующим 172.17.x.x, поэтому вам необходимо внести соответствующие изменения. Если вам нужно более одного мастера, создайте более одной записи DNS A с разными IP-адресами, чтобы при желании получить некоторую отказоустойчивость.
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
server 0.north-america.pool.ntp.org
server 1.north-america.pool.ntp.org
server 2.north-america.pool.ntp.org
server 3.north-america.pool.ntp.org
# Logging & Stats
statistics loopstats
statsdir /var/log/ntp/
filegen peerstats file peers type day link enable
filegen loopstats file loops type day link enable
# Drift file. Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
#
driftfile /etc/ntp/drift
broadcastdelay 0.008
restrict default noquery nomodify
restrict 0.north-america.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
restrict 1.north-america.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
restrict 2.north-america.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
restrict 3.north-america.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
# Allow LAN to query us
restrict 172.17.0.0 mask 255.255.0.0 nomodify notrap
# Trust ourselves. :-)
restrict 127.0.0.1
Теперь на каждом клиенте у нас есть файл /etc/ntp.conf, который выглядит так:
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
server time.example.com
# Drift file. Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
driftfile /etc/ntp/drift
multicastclient # listen on default 224.0.1.1
broadcastdelay 0.008
# Don't serve time or stats to anyone else by default (more secure)
restrict default noquery nomodify
restrict time.example.com mask 255.255.255.255 nomodify notrap noquery
# Allow LAN to query us
restrict 172.17.0.0 mask 255.255.0.0 nomodify notrap
# Trust ourselves. :-)
restrict 127.0.0.1
Используйте команду ntpq, чтобы увидеть серверы, с которыми вы синхронизированы. Он предоставил вам список настроенных серверов времени, а также задержку, смещение и джиттер, которые ваш сервер испытывает с ними. Для правильной синхронизации значения задержки и смещения должны быть отличными от нуля, а значение джиттера должно быть меньше 100.
Также на наших клиентских узлах у нас есть сценарий rc (/etc/rc.d/rc.local), который синхронизирует часы перед запуском демона NTPD. Вот важные части ... Они зависят от заказа.
Синхронизируйте часы клиента с основным источником времени / usr / sbin / ntpdate -b time.example.com
Запустите демон NTPD, допускающий большие корректировки времени во время запуска. / usr / sbin / ntpd -g -x
Наконец, в зависимости от вашей настройки, вам нужно будет пробить правило брандмауэра, чтобы позволить вашему мастеру time.example.com подключаться к общедоступному Интернету через порт UDP. Вот типичное и правильно размещенное правило IPTables
iptables -t nat -A POSTROUTING -o $ PUB_IF -p udp --dport 123 -j MASQUERADE
Где PUB_IF - публичный интерфейс (eth0, eth1, что угодно)
Правильно настроенный NTP обеспечит синхронизацию в течение нескольких мс. Я всегда гарантирую, что каждый клиент NTP взаимодействует как минимум с тремя серверами NTP.
Использовать ntpq -p для отслеживания статуса - он должен указывать на то, почему синхронизация не улучшается.
Я не уверен, что вы можете добиться гораздо меньшей синхронизации времени, но правильная конфигурация сервера ntp заставит серверы синхронизировать почти 10-20 мс, что я сделал на своих серверах. Минимизируйте время дрейфа. Это не невозможно получить, но после настройки сервера NTP и указания всех серверов на этот сервер NTP и синхронизации времени в первый раз вручную уменьшит разницу времени между серверами ч / б.