| orm@doc-tcpip.org | Erstellt: Februar 1998 - Letzte Modifikation: November 2002 |
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:
Servermaschinen sollten zuverläßig sein - es ist keine gute Idee, einen eh schon vielfach belasteten Server zusätzlich zum NTP-Server zu machen. Besser ist eine alte, schwachbrüstige aber zuverläßige Maschine nur mit NTP-Service zu betrauen.
Server sollten über das Netz geschickt verteilt sein. Es ist wünschenswert, pro Segment einen Server zu haben, also den Abgleich über mehrere Hops zu vermeiden.
Server sollten geschickt gruppiert werden. Ideal sind auf jeder Ebene, auf jedem Stratum, 3 Server. Diese haben untereinander eine Peer-Beziehung und gleichen sich gegenseitig ab. Jeder dieser Server sollte wieder 3 Quellen aus niederigeren Straten benutzen.
Clients sollten auch auf 3 Server zugreifen. Das erhöht die Ausfallsicherheit beträchtlich.
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___________| .
Ü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 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.
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.
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/traceDas File ist ziemlich simpel - hier die Bedeutung der einzelnen Einträge:
server: Diese Maschine ist ein Client dieser Adresse. Das kann entweder eine IP-Adresse oder ein Host-Name sein. In diesem Fall ist die IP Adresse sehr eigenartig: 127.127.1.0. Das NTP-Protokoll bezieht sich auf die Hardware der Referenz-Uhren mithilfe von IP-Adressen. Das Format ist 127.127.T.U wobei T der Treiber-Typ ist (1 ist die systemeigene Hardware-Clock) und U die Unit-Number ist, wenn man mehrere Referenzen unterstützt. Aus der Dokumentation der eigenen Referenz-Uhr erfährt man in der Regel, welchen der Treiber man benutzen muß und dessen "IP-Adresse".
fudge: Mit diesem Keywort kann man dem Deamon einige Informationen zur Behandlung der Referenz mitgeben, die dann in die Berechnung miteinfließen. In diesem Fall erniedirgen wir das Stratum künstlich, um die geringe Qualität der Zeitinformation klarzustellen - es ist nur eine undiziplinierte Hardware-Uhr.
driftfile: In dieses File wird der vom Deamon ermittelte Offset (die Abweichung) von der Referenz geschrieben. Es ist so nach einem Reboot problemlos möglich, wieder mit einer guten Zeitschätzung zu beginnen. Im Driftfile findet sich unter AIX einmal die Frequenzabweichung und der gemittelter Fehler. Die Frequenzabweichung ist der Unterschied der Anzahl der Takte, die beide Systeme für eine Sekunde zugrunde legen.
tracefile: Hier wird mitprotokolliert, welche Information der Deamon empfangen und gesendet hat. Nützlich zum debuggen.
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/traceDas File ist wieder ziemlich simpel - hier die Bedeutung der einzelnen Einträge:
server: Diese Maschine ist ein Client dieser Adresse. Es ist die IP des Server nimmaster, ich könnte auch den Namen nehmen. Mit diesem Statement geht diese Maschine hin und fragt den Server nach der Zeit. Das ist eine direkte Verbindung, und die Frequenz nimmt mit der Zeit, also mit der genaueren syncronisation, ab.
broadcast: Teilt dieser Maschine mit, das sie ihre Zeitinformation verteilen soll. Gibt man eine Broadcast Adresse an, also z.B. 192.168.32.255, dann wird in regelmäßigen Abständen ein Paket mit der Zeitinformation auf das Netz gegeben. In diesem Fall ist die "Broadcastadresse" eine bekannte NTP-Multicastadresse, die Pakete gehen also nur an Maschinen, die auf dieser Adresse hören.
driftfile: In dieses File wird der vom Deamon ermittelte Offset (die Abweichung) von der Referenz geschrieben. Es ist so nach einem Reboot problemlos möglich, wieder mit einer guten Zeitschätzung zu beginnen.
tracefile: Hier wird mitprotokolliert, welche Information der Deamon empfangen und gesendet hat. Nützlich zum debuggen.
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/traceDas File wird noch simpler:
multicastclient: Diese Maschine ist ein Client, der auf der NTP-Multicast Adresse horcht. Er erwartet auf dieser Adresse regelmäßig die Pakete mit der Zeitinformation und errechnet daraus seine Statistik und die entsprechende syncronisation. Wer diese Pakete ins Netz stellt, ist dem Client unbekannt und egal. Im Fall des multicastclient sieht man im netstat -ain (AIX/BSD) die Adresse 224.0.1.1. Will man einen Client, der auf der Broadcastadresse horcht, so muß das Keywort broadcastclient benutzt werden.
driftfile und tracefile: Haben diesselbe Bedeutung wie in den anderen Fällen auch.
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/traceDie 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/traceDieser 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
Das wird noch..
[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]
Copyright 2001-2021 by Orm Hager - Es gilt die GPL