Налаштування локального сервера NTP stratum 2


9

Я намагаюся налаштувати NTP в локальній мережі, яка не має (і ніколи не буде) підключення до Інтернету. Основним пріоритетом є те, що машини в мережі синхронізуються між собою, навіть якщо час, в який вони синхронізовані, не є на 100% точним.

У нас також є вимога використовувати ієрархію NTP для того, щоб повторити налаштування розгорнутої системи. Що я хочу зробити, це така ієрархія машин:

Moon  (Main Server running Windows) (10.1.3.10)
|____Earth   (Linux x64 client) (10.1.3.1)
|____Mars    (Linux x64 client) (10.1.3.2)
|____Saturn  (Linux x64 client) (10.1.3.3)
|____RackCard23   (Linux x64 client and server to the two machines below)  (10.1.3.23)
     |___RackCard21   (Linux x64 client) (10.1.4.21)
     |___RackCard22   (Linux x64 client) (10.1.4.22)

Зауважте, що RackCards мають два порти Ethernet, один підключений до мережі 10.1.3.x та один у мережі 10.1.4.x. RackCard23, який синхронізує головний сервер Moon, зробить це в мережі 10.1.3.x, і RackCard22 / 23 підключиться до RackCard23 в мережі 10.1.4.x. Це тому, що я не хочу, щоб RackCards22 / 23 залишали їх мережу для синхронізації часу і тому, що вона реплікує остаточну розгорнуту систему.

Поки мені вдалося отримати все, що слід, синхронізувавши Moon, щоб правильно синхронізувати (включаючи RackCard23).

Але у мене виникають труднощі з отриманням RackCard22 та 23 для синхронізації з RackCard23.

[root@RackCard23]# cat /etc/ntp.conf
# NTP Deamon Configuration File "ntp.conf"
# Created on 27/04/2010
# Original backed-up as "ntp.conf.backup"

server 10.1.3.10 iburst minpoll 4 maxpoll 4 prefer #This is what we want to happen
fudge   127.127.1.0 stratum 2   #Not sure about these two lines, was trying to force it to be a stratum 2 server
fudge   127.127.0.1 stratum 2

# 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 /var/lib/ntp/drift
restrict 10.1.3.10 mask 255.255.255.255 nomodify notrap noquery

#Attempt to get to act as an NTP Server
broadcast 10.1.4.255

restrict 10.1.3.21 mask 255.255.255.255 nomodify notrap
restrict 10.1.4.21 mask 255.255.255.255 nomodify notrap

Це вихід з ntptrace:

[rootRackCard23]# /usr/sbin/ntptrace
localhost.localdomain: stratum 16, offset 0.000000, synch distance 0.000030

Як ви бачите, машина звітує про себе як сервер 16-го шару, незважаючи на те, що він був синхронізований із сервером "stratum 1" (Moon):

[root@RackCard23 awd]# /usr/sbin/ntpdate -d 10.1.3.10
21 Jun 13:55:09 ntpdate[19410]: ntpdate 4.2.2p1@1.1570-o Tue May 19 13:57:56 UTC 2009 (1)
Looking for host 10.1.3.10 and service ntp
host found : 10.1.3.10
transmit(10.1.3.10)
receive(10.1.3.10)
transmit(10.1.3.10)
receive(10.1.3.10)
transmit(10.1.3.10)
receive(10.1.3.10)
transmit(10.1.3.10)
receive(10.1.3.10)
transmit(10.1.3.10)
server 10.1.3.10, port 123
stratum 1, precision -6, leap 00, trust 000
refid [LOCL], delay 0.04135, dispersion 0.00383
transmitted 4, in filter 4
reference time:    cfc99402.e010624d  Mon, Jun 21 2010  8:32:18.875
originate timestamp: cfc9dfad.48000000  Mon, Jun 21 2010 13:55:09.281
transmit timestamp:  cfc9dfad.47e27179  Mon, Jun 21 2010 13:55:09.280
filter delay:  0.04155  0.04155  0.04137  0.04135
         0.00000  0.00000  0.00000  0.00000
filter offset: -0.01448 0.000781 0.000537 0.000394
         0.000000 0.000000 0.000000 0.000000
delay 0.04135, dispersion 0.00383
offset 0.000394

21 Jun 13:55:09 ntpdate[19410]: adjust time server 10.1.3.10 offset 0.000394 sec

Конфігурація клієнтів (RackCard21 / 22) виглядає так:

[root@RackCard21]# cat /etc/ntp.conf
# NTP Deamon Configuration File "ntp.conf"
# Created on 27/04/2010
# Original backed-up as "ntp.conf.backup"

server 10.1.4.23 iburst minpoll 4 maxpoll 4 prefer

server 127.127.1.0
fudge   127.127.1.0 stratum 10

# 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 /var/lib/ntp/drift

# restrict 127.0.0.1

restrict None mask 255.255.255.255 nomodify notrap noquery

І ntptrace дає це:

[root@RackCard21]# /usr/sbin/ntpdate -d 10.1.4.23
21 Jun 14:04:34 ntpdate[14381]: ntpdate 4.2.2p1@1.1570-o Tue May 19 13:57:56 UTC 2009 (1)
Looking for host 10.1.4.23 and service ntp
host found : 10.1.4.23
transmit(10.1.4.23)
receive(10.1.4.23)
transmit(10.1.4.23)
receive(10.1.4.23)
transmit(10.1.4.23)
receive(10.1.4.23)
transmit(10.1.4.23)
receive(10.1.4.23)
transmit(10.1.4.23)
10.1.4.23: Server dropped: strata too high
server 10.1.4.23, port 123
stratum 16, precision -20, leap 11, trust 000
refid [10.1.4.23], delay 0.02568, dispersion 0.00000
transmitted 4, in filter 4
reference time:    00000000.00000000  Thu, Feb  7 2036  6:28:16.000
originate timestamp: cfc9dfef.12b79516  Mon, Jun 21 2010 13:56:15.073
transmit timestamp:  cfc9e1e2.aeae7d56  Mon, Jun 21 2010 14:04:34.682
filter delay:  0.02573  0.02571  0.02568  0.02568
         0.00000  0.00000  0.00000  0.00000
filter offset: -499.609 -499.609 -499.609 -499.609
         0.000000 0.000000 0.000000 0.000000
delay 0.02568, dispersion 0.00000
offset -499.609286

21 Jun 14:04:34 ntpdate[14381]: no server suitable for synchronization found

Тому він не може знайти відповідний сервер, оскільки сервер, який я намагаюся використовувати, повідомляє, що це сервер 16-го шару (що, на мою думку, означає не синхронізований). Це при тому, що він синхронізований.

Тому мені потрібно якось зробити RackCard23 вищим прошарком (в ідеалі, шаром 2). Як мені це робити?

Будь-яка допомога дуже вдячна, оскільки я цілими днями намагаюся змусити її працювати!

Редагувати:

Привіт, Крістофере,

Я перезапустив ntpd, так;)

Усі вікна linux працюють з CentOS 5.4.

Це вихід із запропонованих вами команд. По-перше з сервера:

[root@RackCard23]# /usr/sbin/ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.1.3.10       .INIT.          16 u    -   16    0    0.000    0.000   0.000
 10.1.4.255      .BCST.          16 u    -   64    0    0.000    0.000   0.001

[root@RackCard23]# /usr/sbin/ntpdc -c monlist
remote address          port local address      count m ver code avgint  lstint
===============================================================================
localhost.localdomain  34566 127.0.0.1              1 7 2      0      0       0
10.1.4.21                123 10.1.4.23              5 3 4    180      5       1
10.1.4.22                123 10.1.4.23              7 3 4      0      2       2

А потім від клієнта:

[root@RackCard21]# /usr/sbin/ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.1.4.23       .INIT.          16 u   10   16    0    0.000    0.000   0.000
 LOCAL(0)        .LOCL.          10 l   44   64    1    0.000    0.000   0.001

Якщо у вас немає підключення до Інтернету, яке джерело вашого часу, я десь його пропустив?
dbasnett

Джерело часу насправді не має значення, ми не стоїмо на 100% точний час. Ми хочемо, щоб усі машини синхронізувались один з одним, навіть якщо це означає, що їх час становить 10+ хвилин від фактичного часу. Таким чином, ми використовуємо випадкову машину в мережі як основне джерело часу - тобто просто її внутрішній годинник. Те, що ми знаємо і приймаємо, є ненадійним, але поки це синхронізується, для нас це нормально. У реальній розгорнутій системі ми будемо синхронізуватись з джерелом часу в іншій системі, над яким ми не маємо контролю, що може бути або не бути більш точним.
fwgx

Відповіді:


5

Як згадував Кріс, прошарок 16 вказує, що сервер насправді не синхронізувався із сервером. Щоб бути певним, ви перезапустили служби ntp, правда? ( service ntpd restart) Я не намагаюся натякнути на те, що ти пропускаєш легкі речі, але це завжди роблю!

Чи можете ви опублікувати вихід ще кількох команд, щоб допомогти поставити діагноз?

ntpq -pна клієнті та сервері. Показує, які сервери він налаштував, а також статистику для цих серверів.
ntpdc -c monlistна сервері. Показувати клієнтів, які підключені.

Крім того, оскільки ви не згадали про ОС, я працюю з командами стилю RHEL. Дайте мені знати, чи є у вас щось інше.

Редагуйте після отримання додаткової інформації.
Добре, побачивши ваш вихід, ось ваша проблема: у вас немає сервера stratum 1. Насправді "Місяць" використовує свій місцевий годинник. Він звітує про себе як прошарок 16. Для довідки, сервер Stratum1 матиме локальний GPS або атомний годинник. У вас є одна з таких? В іншому випадку Moon потрібно синхронізувати годинник з НІКОЛИМ сервером ntp. Якщо у нього немає доступу до мережі, вам потрібно буде виправити його прошарок. .

На Місяці, додайте наступний рядок в файл ntp.conf: fudge 127.127.1.0 stratum 10. Це змусить його звітувати про свій локальний годинник як прошарок 10. Що змусить усі інші сервери використовувати його протягом свого локального шару 16 годин.

- Крістофер Карел


додані результати до основного запитання.
fwgx

погоджуючись з Крістофером. багато хибних уявлень про Strata ntp.org/ntpfaq/NTP-s-algo.htm
dbasnett

3

Можливо, поза темою, локальний сервер Stratum 2 вимагає підключення до сервера Stratum 1, а у вашій ізольованій мережі його немає.

Ви можете придбати дешевий GPS-модуль та Raspberry Pi, одноплановий комп'ютер з мінімальним споживанням енергії та достатньою можливістю взаємодії. Підключіть ваш GPS-модуль до Raspberry Pi і приєднайте Pi до своєї мережі за допомогою відповідного програмного забезпечення, це може бути ваш NTP-сервер Stratum 1, на якому ваш сервер Stratum 2, або оскільки ви маєте його у вашій мережі з кожним комп'ютером, синхронізуйте час.


2

NTPd встановить власну прошарку відповідно до:

  1. Якщо переміщення локальних годин не було оцінено, встановіть прошарок на 16. Цей процес займає приблизно 15 хвилин на звичайному сервері, після чого він переходить до наступного кроку.
  2. Підключіться до всіх налаштованих серверів часу, оцініть, які з них надійні (і для цього бажані), встановіть місцевий прошарок на найнижчий надійний прошарок сервера плюс один. Отже, якщо найнижчий знайдений надійний сервер - 1, то локальним буде 2.

(Це не обов'язково порядок подій, а порядок, в якому вони обробляються з метою встановлення локального прошарку.)
(Також прошарок 16 не обов'язково означає, що він не синхронізований).


1
Чи може це бути тому, що Moon - це машина Windows XP Pro x64, яка використовує сервер WTPTime NTP за замовчуванням, який насправді є простим NTP (SNTP), що RackCard23 не сприймає його як належний сервер NTP, тому ніколи не встановлюватиме свій прошарок ні на що інше ніж 16?
fwgx

Да, я цього не бачив, перш ніж редагувати свою публікацію. Це досить вірогідно. Будь-яка причина не використовувати належний клієнт ntp у верхній частині вашої ієрархії? (Або на Windows, або на базі Unix)
Крістофер Карел

2

Як певний бік, я включу деякий аналіз вашого ntpq виводу. Просто для того, щоб допомогти загальному вирішенню несправностей у майбутньому для себе та інших.

Спочатку з вашого сервера:

[root@RackCard23]# /usr/sbin/ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.1.3.10       .INIT.          16 u    -   16    0    0.000    0.000   0.000
 10.1.4.255      .BCST.          16 u    -   64    0    0.000    0.000   0.001

Перший стовпець вказує на два сервери, на яких ця машина налаштована для синхронізації. Примітним є відсутність *або +те, що вказувало б на синхронізованого однорангового чи другорядного кандидата. Це означає, що ваш сервер не буде використовувати тут записи, але він принаймні перевіряє їх.

У третій колонці "st" вказується прошарок цих серверів. У цьому випадку це вказує на те, що обидва ці машини використовують свій локальний годинник. (типовий прошарок 16) Останні три стовпці вказували б на відстань двох годин. Або за значенням «різниця в тактових часах», або затримкою між двома машинами, до різниці в цій затримці. Тут вищі цифри гірші.

Причина несинхронізованих записів на кшталт цього може залежати від деяких факторів: Якщо зміщення в годиннику занадто багато, то ntp навіть не буде намагатися, оскільки це призведе до занадто великого стрибка за місцевим часом. Якщо тремтіння стає поганим, клієнт буде десинхронізуватися, поки все не стабілізується. (Це, як правило, тимчасово, але все-таки повторно виникає) По черзі, як у вашому випадку, якщо налаштовані сервери мають рівні або більші значення прошарку, що вказує на те, що вони менш надійні як джерела часу, то клієнт не використовуватиме їх.

- Крістофер Карел

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.