Konfigurowanie lokalnego serwera NTP warstwy 2


9

Próbuję skonfigurować NTP w sieci lokalnej, która nie ma (i nigdy nie będzie) połączenia z Internetem. Głównym priorytetem jest synchronizacja komputerów w sieci, nawet jeśli czas synchronizacji nie jest w 100% dokładny.

Mamy również wymaganie użycia hierarchii NTP w celu zreplikowania konfiguracji wdrożonego systemu. Chcę mieć hierarchię takich maszyn:

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)

Zauważ, że RackCards mają dwa porty Ethernet, jeden podłączony do sieci 10.1.3.x, a drugi do sieci 10.1.4.x. RackCard23, który synchronizuje serwer główny Moon, zrobi to w sieci 10.1.3.x, a RackCard22 / 23 połączy się z RackCard23 w sieci 10.1.4.x. Wynika to z faktu, że nie chcę, aby karty RackCards22 / 23 opuszczały swoją sieć, aby zsynchronizować czas i ponieważ replikuje końcowy wdrożony system.

Do tej pory udało mi się uzyskać wszystko, co powinno, synchronizując Moon do prawidłowej synchronizacji (w tym RackCard23).

Mam jednak trudności z uzyskaniem RackCard22 i 23, aby zsynchronizować 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

To jest wynik działania ntptrace:

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

Jak widać, maszyna zgłasza się jako serwer warstwy 16, mimo że została zsynchronizowana z serwerem „warstwy 1” (Księżyc):

[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

Konfiguracja klientów (RackCard21 / 22) wygląda następująco:

[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

A ntptrace daje to:

[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

Nie może więc znaleźć odpowiedniego serwera, ponieważ serwer, którego próbuję użyć, zgłasza, że ​​jest to serwer warstwy 16 (co moim zdaniem oznacza niezsynchronizowany). Dzieje się tak pomimo tego, że jest zsynchronizowany.

Więc muszę w jakiś sposób uczynić RackCard23 wyższą warstwą (idealnie warstwą 2). Jak mam to zrobić?

Każda pomoc jest mile widziana, ponieważ od kilku dni staram się, aby to zadziałało!

EDYTOWAĆ:

Cześć Christopher,

Zrestartowałem ntpd, tak;)

Wszystkie Linux-y działają w CentOS 5.4.

To jest wynik poleceń, które zasugerowałeś. Po pierwsze z serwera:

[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

A potem od klienta:

[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

Jeśli nie masz połączenia z internetem, jakie jest twoje źródło czasu, czy gdzieś mi to brakowało?
dbasnett

Źródło czasu tak naprawdę nie ma znaczenia, nie jesteśmy po 100% dokładnym czasie. Chcemy, aby wszystkie maszyny były zsynchronizowane ze sobą, nawet jeśli oznacza to, że ich czasy są ponad 10 minut wolnego czasu. Dlatego używamy przypadkowej maszyny w sieci jako głównego źródła czasu - tj. Tylko jej wewnętrznego zegara. To, co wiemy i akceptujemy, jest niewiarygodne, ale dopóki synchronizacja rzeczy jest dla nas OK. W rzeczywistym wdrożonym systemie będziemy synchronizować ze źródłem czasu w innym systemie, nad którym nie mamy kontroli, co może, ale nie musi być dokładniejsze.
fwgx

Odpowiedzi:


5

Jak wspomniał Chris, warstwa 16 wskazuje, że serwer nie został zsynchronizowany z serwerem. Dla pewności zrestartowałeś usługi NTTP, prawda? ( service ntpd restart) Nie próbuję sugerować, że tęsknisz za łatwymi rzeczami, ale zawsze tak robię!

Czy możesz opublikować wyniki kilku kolejnych poleceń, aby pomóc w zdiagnozowaniu?

ntpq -pna kliencie i serwerze. Powinien pokazywać skonfigurowane serwery, a także statystyki tych serwerów.
ntpdc -c monlistna serwerze. Powinny pokazywać połączonych klientów.

Ponadto, ponieważ nie wspomniałeś o systemie operacyjnym, korzystam z poleceń w stylu RHEL. Daj mi znać, jeśli masz coś innego.

EDYTUJ po dalszych informacjach
OK, widząc twój wynik, oto twój problem: Nie masz serwera warstwy 1. W rzeczywistości „Księżyc” używa lokalnego zegara. Zgłasza się jako serwer warstwy 16. Dla porównania, serwer Stratum1 miałby lokalny GPS lub zegar atomowy. Czy masz jeden z nich? W przeciwnym razie Moon musi zsynchronizować swój zegar z INNYM serwerem ntp. Jeśli nie ma dostępu do sieci, musisz sfałszować jego warstwę. (To wymaga, abyś nie przejmował się zbytnio „prawdziwym” czasem. Czego nie robisz, ale każdy, kto to czyta, powinien to zauważyć.)

Na Księżycu, dodaj następującą linię do pliku ntp.conf: fudge 127.127.1.0 stratum 10. Spowoduje to, że zgłosi swój lokalny zegar jako warstwę 10. Co sprawi, że wszystkie inne serwery będą go używać przez swój lokalny zegar warstwy 16.

- Krzysztof Karel


dodano wyniki do głównego pytania.
fwgx

zgadzając się z Christopherem. wiele nieporozumień na temat Strata ntp.org/ntpfaq/NTP-s-algo.htm
dbasnett

3

Być może nie na temat, lokalny serwer Stratum 2 wymaga połączenia z serwerem Stratum 1, a w odizolowanej sieci nie ma go.

Możesz kupić tani moduł GPS i Raspberry Pi, komputer jednopłytkowy o minimalnym zużyciu energii i szerokim zakresie interfejsów. Podłącz moduł GPS do Raspberry Pi i podłącz Pi do swojej sieci, z odpowiednim oprogramowaniem, może to być twój serwer NTP Stratum 1, z którym serwer Stratum 2, lub ponieważ masz go w sieci na każdym komputerze, synchronizuj czas.


2

NTPd ustawi własną warstwę zgodnie z:

  1. Jeśli dryft lokalnego zegara nie został oceniony, ustaw warstwę na 16. Proces ten trwa około 15 minut na normalnym serwerze, po czym przechodzi do następnego kroku.
  2. Połącz się ze wszystkimi skonfigurowanymi serwerami czasu, oceń, które z nich są niezawodne (a zatem preferowane), ustaw lokalną warstwę na najniższą niezawodną warstwę serwera plus jeden. Więc jeśli najniższy znaleziony niezawodny serwer to 1, to lokalny będzie wynosił 2.

(To niekoniecznie jest kolejność zdarzeń, ale kolejność, w jakiej są przetwarzane w celu ustalenia lokalnej warstwy).
(Również warstwa 16 niekoniecznie oznacza, że ​​jest niezsynchronizowana).


1
Być może dlatego, że Moon jest maszyną Windows XP Pro x64 korzystającą z domyślnej usługi NTP W32Time, która jest w rzeczywistości Simple NTP (SNTP), dlatego RackCard23 nie widzi go jako właściwego serwera NTP, więc nigdy nie ustawi swojej warstwy na nic innego niż 16?
fwgx

Nie widziałem tego przed edycją mojego postu. To całkiem prawdopodobne. Czy jest jakiś powód, aby nie używać odpowiedniego klienta NTTP na szczycie hierarchii? (Z systemem Windows lub Unix)
Christopher Karel

2

Na marginesie, dołączę analizę twojego wyniku ntpq. Aby pomóc w ogólnym rozwiązywaniu problemów w przyszłości dla siebie i innych.

Po pierwsze, z twojego serwera:

[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

Pierwsza kolumna wskazuje dwa serwery, z którymi ten komputer jest skonfigurowany do synchronizacji. Godny uwagi jest brak *lub +wskazujący na zsynchronizowanego równorzędnego lub wtórnych kandydatów. Oznacza to, że twój serwer nie będzie używał tutaj wpisów, ale przynajmniej się z nimi sprawdza.

Kolumna trzecia „st” wskazuje warstwę tych serwerów. W tym przypadku oznacza to, że oba komputery używają lokalnego zegara. (domyślna warstwa 16) Ostatnie trzy kolumny wskazują, jak daleko są dwa zegary. Albo w wartości „różnicy sekund zegarów”, albo w opóźnieniu między dwiema maszynami, do różnicy w tym opóźnieniu. Tutaj wyższe liczby są gorsze.

Przyczyna takich niezsynchronizowanych wpisów może zależeć od niektórych czynników: jeśli przesunięcie w zegarach jest zbyt duże, to ntp nawet nie spróbuje, ponieważ wprowadziłby zbyt duży skok w czasie lokalnym. Jeśli drgania się pogorszą, klient desynchronizuje się, aż sytuacja się ustabilizuje. (Zwykle jest to tymczasowe, a jednak ponowne przywracanie). Alternatywnie, jak w twoim przypadku, jeśli skonfigurowane serwery mają równe lub wyższe wartości warstwy, co oznacza, że ​​są mniej niezawodne jako źródła czasu, to klient ich nie użyje.

- Krzysztof Karel

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.