orm@doc-tcpip.org

Erstellt: Februar 1998 - Letzte Modifikation: November 2002

[ Main | Local ]


NTP-Deamon Konfiguration


Allgemeine Gedanken zur Zeitsynchronisation in einem Netzwerk

Für das Netz ist es viel schlimmer, wenn ein Server falsche Angaben macht - eine Workstation kann tagelang ohne eine neue, aktuelle Zeit laufen und wird trotzdem nur um Sekunden von der Referenz abweichen (die Uhren sind so stabil, und die bisher ermittelte Korrektur wird ja weiter angewandt). Ein Server mit instabiler oder falscher Zeit macht alles kaputt.

Folgende Punkte sollte man daher beachten und das Netz entsprechend ausrichten:

Hierbei ist die Zahl 3 eigentlich eine Minimal-Forderung. Der xntpd funktioniert so, das er in einem komplizierten Verfahren eine Gruppe von 10 Servern ermittelt, die alle in die letztendlich angewandte Änderung einfließen. Der Algorithmus funktioniert natürlich nur dann gut, wenn er auch was zu tun hat!

Diese Überlegungen sollte man im Licht des eigenen Netzes und der gewünschten Präzision der Zeit treffen. Ein spezielles Problem stellt sich bei der Verwendung einer funkgesteuerten Echtzeit-Uhr (In Deutschland meist auf einem DCF77-Empfänger basierend). Hier hat man nur eine Zeitquelle, und der Preis verbietet eine mehrfache Anschaffung. In diesem Fall kann man dem Master-Server des Netzes als Server einmal die Uhr mit dem Keyword prefer vorgeben und als weitere Adressen Server auf dem Internet eintragen - was einen permanenten Internet-Zugang vorraussetzt.

Grundsätzlich sollte man sich bei größeren Netzen an folgendem Schema orientieren (hier kann man natürlich Glaubenskriege führen). Die Zahlen sind das Stratum, indem sich die Clients befinden. Man sollte versuchen, kleine Werte anzustreben:

 
.        1    1   1   1   1   1     (GPS, DCF77, Internet)
.         \   /   \   /   \   /
.          \ /     \ /     \ /   
.           2 - P - 2 - P - 2       (P = Peer)
.          / \     /|      /|\
.         /   \____ 3 ____/ |       (Jeder Stratum 3 Client sieht
.        /       /          |        je 3 Stratum 2 Server)
.       /______ 3___________|
.

Wie finde ich heraus, ob eine Maschine zuverläßig ist?

Über Maschinen in einem nicht oder nur unzureichend klimatisiertem Raum brauchen wir gar nicht zu reden. Für eine gute Zeit ist das natürlich eine Vorraussetzung.
Sind diese Dinge geklärt, dann sollte man auf den Kandidaten NTP aufsetzen und die Maschinen gegen Zeit-Server im Netz oder eine Uhr laufen lassen. Dabei werden die loopstats gesammelt. Auftragen von Frequenz- und Zeit-Offset gegen die abgelaufene Zeit gibt eine gute Vorstellung von der Qualität des Servers (oder des Standortes..).

Die Qualität von Servern im Internet ist da schon schwerer zu prüfen. Eigentlich bräuchte man eine GPS-Uhr. Das Verfahren ist wie oben, nur mit wirklich guter Zeitquelle.
(Siehe Seite mit den Beispielen..)

Der Deamon, die Files und nützliche Kommandos

Der eigentliche Deamon ist in der Regel xntpd. Dieser Deamon muß auf jeder Maschine laufen, die als Client, Server oder beides funktioniert. Aufgabe des Deamons ist es, die Statistik über die empfangenen Zeitstempel zu führen, und den Kernel anzuweisen, die Systemzeit nachzuführen. Ausserdem übernimmt der Deamon alle Aufgaben, die mit dem Senden und Empfangen der zum Protokoll gehörigen Pakete zusammenhängen.

Der Deamon wird über das File /etc/ntp.conf (unter Solaris /etc/inet/ntp.conf) konfiguriert. Die aktuelle Abweichung der Systemzeit gegen die Referenz wird in ein File /etc/ntp.drift (unter Solaris /etc/inet/ntp.drift) eingetragen, damit die Synchronisation über einen Reboot nicht verloren geht. Weiterhin gibt es ein File für eventuelle Schlüßel, wenn mit Authentifizierung gearbeitet wird: /etc/ntp.keys (wo das unter Solaris liegt, dürfte jetzt klar sein..). Wahlweise kann man noch ein Trace-File zum Debuggen mitlaufen lassen: /etc/ntp.trace.

Neben dem eigentlichen Deamon gibt es noch mehrere Programme zum Debuggen und Anfahren des Services. Der Befehl ntpdate setzt die lokale Systemzeit nach der Zeitinformation vom angegebenen Server. Dazu ist kein NTP-Deamon erforderlich. Der Zeitsprung ist aber wirklich ein Sprung (Man kann ntpdate per cron laufen lassen). Zur Analyse dienen die Befehle ntpq und xntpdc, auf die auf dieser Seite weiter eingegangen wird. Zum Schluß existiert noch ein Tracetool: ntptrace. Damit kann man den Weg der aktuellen Zeitinformation vom Client zum Server verfolgen.

Wie man den xntpd konfiguriert

Das Konfigurationsfile für den xntpd ist /etc/ntp.conf (auf Solaris-Maschinen /etc/inet/ntp.conf). Es ist am einfachsten, sich für jede Art von Server bzw. Client ein Muster-File zu erstellen und dieses dann auf die Maschinen zu verteilen.

Eine einfache Testsituation

Das Testnetz besteht aus der Maschine nimmaster, der Masterserver für das Testnetz. Diese Maschine betrachtet die eigene Hardwareclock als Referenz. Im Stratum 2 findet sich die Maschine cristina, die einmal Client von nimmaster und Server für die im Stratum 3 befindliche Maschine pinocchio ist.

Um es nochmal zu sagen: Generell ist jede Maschine ein Server. Wenn ich einen beliebigen Client direkt anspreche, werde ich eine Zeitinformation erhalten. Wenn ein solches Verhalten nicht erwünscht ist, dann kann es gezielt unterbunden werden.

Das xntpd-Konfigurationsfile des Master-Servers (nimmaster).

# Server Konfiguration mit System-clock als Referenz
server 127.127.1.0
fudge  127.127.1.0 stratum 10
driftfile /var/tmp/drift
tracefile /var/tmp/trace
Das File ist ziemlich simpel - hier die Bedeutung der einzelnen Einträge:

Das Konfigurationsfile des Clients, der zugleich Server für das niedrigerere Stratum ist (cristina).

# Client/Server Konfiguration (sendet multicasts)
server 192.168.16.4
broadcast 224.0.1.1
driftfile /var/tmp/drift
tracefile /var/tmp/trace
Das File ist wieder ziemlich simpel - hier die Bedeutung der einzelnen Einträge:

Das Konfigurationsfile des Clients, der am Ende der Kette im Stratum 3 hängt (pinocchio).

# Client Konfiguration (multicastclient)
multicastclient
driftfile /var/tmp/drift
tracefile /var/tmp/trace
Das File wird noch simpler:

Ein Schritt weiter (mehr Ausfallsicherheit)

Das war ein einfaches Beispiel. Tun wir jetzt so, wie wenn wir ein einem richtig großen Netz wären und sehr hohe Anforderungen an eine zuverlässige Zeitinformation haben. Geld spielt keine Rolle...

Zuallererst machen wir uns Gedanken über unser Stratum 1. Wir wollen mindestens 5 zuverläßige Zeitquellen haben, entweder öffentliche Server oder eigene Referenzuhren, die dann administriert werden müßen. Gehen wir davon aus, das wir an 5 verschiedenen Standorten 5 Stratum 1 Server mit je einer DCF77 Referenz-Uhr haben. Jeder Server syncronisiert seine Zeit gegen die Uhr, und ist zugleich ein Peer zu zwei anderen Stratum 1 Servern. Das /etc/ntp.conf von Server_1 sähe dann so aus:

# Server Konfiguration mit Referenz-Uhr - Stratum 1
server 127.127.T.U    # T und U hängen von der Uhr ab!
peer 192.168.4.5      # Server_2
peer 172.45.3.4       # Server_3
driftfile /var/tmp/drift
tracefile /var/tmp/trace
Die anderen Files sind analog, wobei die Partner immer wechseln - der Server_2 hätte seine Uhr und Server_4 und Server_5 als Peers. Man kann natürlich auch Mischen, also z.B. 3 Referenz-Uhren kaufen und zwei öffentliche Server ansprechen. Wir haben jetzt ein Stratum 1, indem 5 robuste und voneinander weitgehend unabhängige Zeitquellen existieren.

Im Stratum 2 definieren wir als Server verschiedene Kombinationen der Stratum 1 Server, sodaß jede Maschine auf je 3 Server aus dem Stratum 1 kommt. Da es für die Zuverläßigkeit der Zeitstatistik vorteilhaft ist, fügen wir noch einen Peer aus dem eigenen Stratum hinzu. Wieder werden die Server zyklisch gemischt, wobei es geschickt ist, sie geografisch ein bischen zu ordnen. Das Konfigurationsfile für einen Stratum 2 Server sähe so aus:

# Server Konfiguration - Stratum 2
server 145.23.34.5      # Server_1
server 192.168.4.5      # Server_2
server 172.45.3.4       # Server_3
peer 192.168.14.89      # anderer Stratum 2 Server
broadcast 224.0.1.1
driftfile /var/tmp/drift
tracefile /var/tmp/trace
Dieser Server bezieht eine zuverläßige Zeit aus 3 weitgehend unabhängigen Quellen - so soll es sein. Es können sehr viele Server auf dieser Ebene liegen. Das richtet sich nach der Verteilung der Clients. Um den Netzverkehr gering zu halten, werden die Clients, also die wirklichen Endabnehmer, per Multi- oder Broadcast bedient. Daher sind Verzögerungen und Latenzen im Netz kritisch für die erreichbare Präzision des Zeitabgleiches. Multicasts (Broadcasts sind das Extrem) sollten daher nur auf einem definierten LAN eingesetzt werden. Es ist besser, mehr Server aufzusetzen als Clients über verschiedene Hops an die Zeitinformation zu führen.

Meine Client-Konfiguration unterscheidet sich eigentlich nicht. Ich könnte auf dem LAN einen weiteren Server zur Verfügung stellen, um die Ausfallsicherheit zu erhöhen. Das ist bei vielen Clients sicher Vernünftig.

# Client Konfiguration (multicastclient)
multicastclient
driftfile /var/tmp/drift
tracefile /var/tmp/trace

Noch ein Schritt weiter (mehr Sicherheit)

Das wird noch..


[ Main | Local ]

[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | SMTP | Tracing | GPS ]

Copyright 2001-2014 by Orm Hager - Es gilt die GPL
Feedback bitte an: Orm Hager (orm@doc-tcpip.org )