Einrichten eines lokalen Stratum 2-NTP-Servers

9

Ich versuche, NTP in einem lokalen Netzwerk einzurichten, das keine Internetverbindung hat (und dies auch nie tun wird). Die Hauptpriorität besteht darin, dass die Computer im Netzwerk miteinander synchronisiert werden, auch wenn die Zeit, zu der sie synchronisiert werden, nicht 100% genau ist.

Wir müssen auch eine NTP-Hierarchie verwenden, um das Setup eines bereitgestellten Systems zu replizieren. Was ich tun möchte, ist eine Hierarchie von Maschinen wie diese:

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)

Beachten Sie, dass die RackCards über zwei Ethernet-Ports verfügen, von denen einer mit dem 10.1.3.x-Netzwerk und einer mit dem 10.1.4.x-Netzwerk verbunden ist. RackCard23, die vom Master-Server Moon synchronisiert wird, tut dies im 10.1.3.x-Netzwerk und die RackCard22 / 23 stellt eine Verbindung zu RackCard23 im 10.1.4.x-Netzwerk her. Dies liegt daran, dass die RackCards22 / 23 ihr Netzwerk nicht verlassen sollen, um die Uhrzeit zu synchronisieren, und dass ein endgültig bereitgestelltes System repliziert wird.

Bisher habe ich es geschafft, alles, was sollte, durch Synchronisieren von Moon zu bekommen, um korrekt zu synchronisieren (einschließlich RackCard23).

Ich habe jedoch Schwierigkeiten, RackCard22 und 23 dazu zu bringen, RackCard23 zu synchronisieren.

[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

Dies ist die Ausgabe von ntptrace:

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

Wie Sie sehen, meldet sich der Computer selbst als Stratum 16-Server, obwohl er mit einem "Stratum 1" -Server (Moon) synchronisiert wurde:

[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

Die Konfiguration der Clients (RackCard21 / 22) sieht folgendermaßen aus:

[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

Und ntptrace gibt dies:

[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

Daher kann kein geeigneter Server gefunden werden, da der Server, den ich verwenden möchte, meldet, dass es sich um einen Stratum 16-Server handelt (was meiner Meinung nach nicht synchronisiert bedeutet). Dies trotz der Tatsache, dass es synchronisiert ist.

Also muss ich RackCard23 irgendwie zu einer höheren Schicht machen (idealerweise Schicht 2). Wie mache ich das?

Jede Hilfe wird sehr geschätzt, da ich seit Tagen versuche, dies zum Laufen zu bringen!

BEARBEITEN:

Hallo Christopher,

Ich habe das ntpd neu gestartet, ja;)

Auf allen Linux-Boxen läuft CentOS 5.4.

Dies ist die Ausgabe der von Ihnen vorgeschlagenen Befehle. Erstens vom Server:

[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

Und dann vom Kunden:

[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

ntp

— fwgx
quelle

Wenn Sie keine Internetverbindung haben, was ist Ihre Zeitquelle, habe ich sie irgendwo vermisst?

— Dbasnett

Die Zeitquelle spielt keine Rolle, wir sind nicht nach 100% genauer Zeit. Was wir wollen, ist, dass alle Maschinen miteinander synchronisiert sind, auch wenn dies bedeutet, dass ihre Zeiten mehr als 10 Minuten von der tatsächlichen Zeit entfernt sind. Wir verwenden also eine zufällige Maschine im Netzwerk als Hauptzeitquelle - dh nur ihre interne Uhr. Was wir wissen und akzeptieren, ist unzuverlässig, aber solange sich die Dinge synchronisieren, ist es für uns in Ordnung. In dem tatsächlich bereitgestellten System werden wir mit einer Zeitquelle auf einem anderen System synchronisieren, über das wir keine Kontrolle haben, was möglicherweise genauer ist oder nicht.

— fwgx

5

Wie Chris erwähnt hat, zeigt die Schicht 16 an, dass ein Server nicht tatsächlich mit einem Server synchronisiert wurde. Um sicherzugehen, haben Sie die NTP-Dienste neu gestartet, oder? ( service ntpd restart) Ich versuche nicht anzudeuten, dass du das einfache Zeug vermisst, aber ich tue es immer!

Können Sie die Ausgabe einiger weiterer Befehle zur Diagnose veröffentlichen?

ntpq -pauf dem Client & Server. Sollte anzeigen, welche Server konfiguriert wurden, sowie Statistiken für diese Server.
ntpdc -c monlistauf dem Server. Sollte die verbundenen Clients anzeigen.

Da Sie kein Betriebssystem erwähnt haben, verwende ich außerdem Befehle im RHEL-Stil. Lassen Sie mich wissen, wenn Sie etwas anderes haben.

BEARBEITEN nach weiteren Informationen
OK, sehen Sie Ihre Ausgabe, hier ist Ihr Problem: Sie haben keinen Stratum 1-Server. Tatsächlich benutzt der "Mond" seine lokale Uhr. Es meldet sich als Stratum 16-Server. Als Referenz hätte ein Stratum1-Server ein lokales GPS oder eine Atomuhr. Hast du eine davon? Andernfalls muss Moon seine Uhr mit einem anderen NTP-Server synchronisieren. Wenn es keinen Netzwerkzugriff hat, müssen Sie seine Schicht fummeln. (Dies erfordert, dass Sie sich nicht zu sehr um die "wahre" Zeit kümmern. Was Sie nicht tun, aber jeder andere, der dies liest, sollte dies beachten.)

Fügen Sie auf Moon Ihrer ntp.conf-Datei die folgende Zeile hinzu : fudge 127.127.1.0 stratum 10. Dadurch wird die lokale Uhr als Schicht 10 gemeldet. Dadurch verwenden alle anderen Server sie über die Uhr der lokalen Schicht 16.

- Christ Karel

— Christopher Karel
quelle

Ergebnisse zum Hauptfragenbeitrag hinzugefügt.

— fwgx

mit Christopher einverstanden. viele Missverständnisse über Strata ntp.org/ntpfaq/NTP-s-algo.htm

— dbasnett

3

Ein lokaler Stratum 2-Server erfordert möglicherweise keine Verbindung zu einem Stratum 1-Server, und in Ihrem isolierten Netzwerk haben Sie keinen.

Sie können ein billiges GPS-Modul und einen Raspberry Pi erwerben, einen Einplatinencomputer mit minimalem Stromverbrauch und ausreichender Schnittstellenfähigkeit. Schließen Sie Ihr GPS-Modul an den Raspberry Pi an und verbinden Sie den Pi mit der richtigen Software in Ihrem Netzwerk. Dies kann Ihr Stratum 1-NTP-Server sein, mit dem Ihr Stratum 2-Server arbeitet, oder die Synchronisierungszeit, da Sie ihn auf jedem Computer in Ihrem Netzwerk haben.

2

NTPd legt seine eigene Schicht fest gemäß:

Wenn die Drift der lokalen Uhr nicht bewertet wurde, setzen Sie die Schicht auf 16. Dieser Vorgang dauert auf einem normalen Server etwa 15 Minuten. Anschließend wird mit dem nächsten Schritt fortgefahren.
Stellen Sie eine Verbindung zu allen konfigurierten Zeitservern her, bewerten Sie, welche zuverlässig sind (und welche bevorzugt werden), und setzen Sie die lokale Schicht auf die Schicht des niedrigsten zuverlässigen Servers plus eins. Wenn also der niedrigste gefundene zuverlässige Server 1 ist, ist local 2.

(Dies ist nicht unbedingt die Reihenfolge der Ereignisse, sondern die Reihenfolge, in der sie zum Festlegen der lokalen Schicht verarbeitet werden.)
(Außerdem bedeutet Schicht 16 nicht unbedingt, dass sie nicht synchronisiert ist.)

— Chris S.
quelle

1

Könnte es sein, dass Moon, da Moon ein Windows XP Pro x64-Computer ist, der den Standard-NTP-Dienst W32Time verwendet, bei dem es sich tatsächlich um einfaches NTP (SNTP) handelt, RackCard23 ihn nicht als richtigen NTP-Server ansieht und daher seine Schicht niemals auf etwas anderes setzt als 16?

— fwgx

D'oh, ich habe das nicht gesehen, bevor ich meinen Beitrag bearbeitet habe. Das ist ziemlich wahrscheinlich. Gibt es einen Grund, keinen richtigen NTP-Client oben in Ihrer Hierarchie zu verwenden? (Entweder Windows oder Unix)

— Christopher Karel

2

Nebenbei werde ich eine Analyse Ihrer ntpq-Ausgabe einschließen. Nur um Ihnen und anderen in Zukunft bei der allgemeinen Fehlerbehebung zu helfen.

Zunächst von Ihrem Server:

[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

In der ersten Spalte werden die beiden Server angegeben, für die die Synchronisierung dieses Computers konfiguriert ist. Bemerkenswert ist das Fehlen von *oder +das würde auf einen synchronisierten Peer oder sekundäre Kandidaten hinweisen. Dies bedeutet, dass Ihr Server die Einträge hier nicht verwendet, aber zumindest bei ihnen eincheckt.

Spalte drei, "st", gibt die Schicht dieser Server an. In diesem Fall bedeutet dies, dass beide Computer ihre lokale Uhr verwenden. (Standardschicht von 16) Die letzten drei Spalten geben an, wie weit die beiden Uhren entfernt sind. Entweder in einem Wert von "Sekunden Unterschied in den Uhren" oder der Latenz zwischen den beiden Maschinen zum Unterschied in dieser Latenz. Hier sind höhere Zahlen schlechter.

Der Grund für solche nicht synchronisierten Einträge kann von einigen Faktoren abhängen: Wenn der Versatz in Uhren zu groß ist, wird ntp es nicht einmal versuchen, da dies zu einem zu großen Sprung in der Ortszeit führen würde. Wenn der Jitter zu schlecht wird, wird der Client desynchronisieren, bis sich die Dinge stabilisiert haben. (Dies ist normalerweise vorübergehend und tritt immer wieder auf.) Alternativ, wie in Ihrem Fall, wenn die konfigurierten Server gleiche oder höhere Schichtwerte haben, was darauf hinweist, dass sie als Zeitquellen weniger zuverlässig sind, wird der Client sie nicht verwenden.

- Christ Karel

— Christopher Karel
quelle