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

Архитектура сервера NTP

У меня есть виртуальная среда, в которой работает несколько компьютеров с Linux, и я планирую, как управлять всей архитектурой ntp.
Насколько я знаю, нет смысла иметь два сервера в файле 'ntp.conf', должен быть только один или более трех серверов ntp, указанных клиентом, поэтому мой первый подход состоит в том, чтобы один сервер 'server1' указывал на 4 общедоступных сервера, в частности, RHEL, затем с другим ящиком server2, указывающим на server1, и под всеми моими другими серверами Linux, указывающими на server2, но я наблюдал странное поведение с этой архитектурой. Я видел, как некоторые серверы десинхронизируются между server2 и ними, и даже иногда server1 и server2 не синхронизируются идеально.
Мой первый вопрос: почему это происходит?
Затем я придумал другую архитектуру, в которой тот же server1 указывал на общедоступные серверы ntp, а затем имелось три сервера, server2, server3 и server4, указывающие на server1 и все остальные мои машины, указывающие на server2-4.
Есть ли шанс, что эта архитектура может улучшить синхронизацию во всей моей сети?
Или между синхронизациями будет такая же производительность?
Как лучше всего это спроектировать?

Отредактировано

Вот результат ntpq -p с server1:

remote          refid      st t when poll reach   delay   offset  jitter
=========================================================================
*Time100.Stupi. .PPS.       1 u  317 1024  377  182.786    5.327   3.022
LOCAL(0)        .LOCL.     10 l  46h   64    0    0.000    0.000   0.000

И вот его ntp.conf:

# For more information about this file, see the man pages
# ntp.conf(5), ntp_acc(5), ntp_auth(5), ntp_clock(5), ntp_misc(5), ntp_mon(5).

driftfile /var/lib/ntp/drift

# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery

# Permit all access over the loopback interface.  This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1
restrict -6 ::1

# Hosts on local network are less restricted.
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server 0.rhel.pool.ntp.org iburst
server 1.rhel.pool.ntp.org iburst
server 2.rhel.pool.ntp.org iburst
server 3.rhel.pool.ntp.org iburst
#broadcast 192.168.1.255 autokey        # broadcast server
#broadcastclient                        # broadcast client
#broadcast 224.0.1.1 autokey            # multicast server
#multicastclient 224.0.1.1              # multicast client
#manycastserver 239.255.254.254         # manycast server
#manycastclient 239.255.254.254 autokey # manycast client

# Enable public key cryptography.
#crypto

includefile /etc/ntp/crypto/pw

# Key file containing the keys and key identifiers used when operating
# with symmetric key cryptography.
keys /etc/ntp/keys

# Specify the key identifiers which are trusted.
#trustedkey 4 8 42

# Specify the key identifier to use with the ntpdc utility.
#requestkey 8

# Specify the key identifier to use with the ntpq utility.
#controlkey 8

# Enable writing of statistics records.
statistics clockstats cryptostats loopstats peerstats sysstats rawstats

### Added by IPA Installer ###
server 127.127.1.0
fudge 127.127.1.0 stratum 10

Вот результат работы трех клиентов:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*server1         172.16.29.21     3 u    1   64    1    1.090   -0.138   0.036


     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*server1         172.16.29.21     3 u 1035 1024  377    1.117   -1.943   0.530


     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*server1         172.16.29.21     3 u   32   64    1    0.902    1.788   0.140

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

Почему бы не синхронизировать все серверы server1, server2, server3, server4 с 4 или 5 партнерами в Интернете. Тогда ваша внутренняя сеть может ссылаться на эти системы?

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

Посмотри пожалуйста; 5.3.3. Количество серверов времени восходящего направления

Кроме того, вы упомянули странности и проблемы с вашей текущей конфигурацией. Было бы полезно увидеть результат ntpq -p для соответствующих хостов.

Хотя не совсем верно, что 2 сервера бесполезны, Проект RFC Best Current Practices рекомендует как минимум 4. Алгоритм пересечения NTP не зависит только от кворума в число серверов, но и в качественный времени, когда они вернутся - и вы не можете этого предсказать. Так что чем больше, тем лучше. Нет проблем с наличием до 10 восходящих NTP-серверов.

Как упоминал Аарон, все предлагаемые вами серверы 1–4 должны указывать на вышестоящие серверы NTP, а ваши внутренние системы должны указывать на все 4 из них. Серверы 1–4 также могут взаимодействовать друг с другом (в симметричном режиме), но это не обязательно.

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