Home	Artikel > April > Immer im Takt bleiben

Zeitsynchronisation im LAN Immer im Takt bleiben Jörg Reitter

Bei einer Umfrage, welcher der wichtigste Netzwerkdienst sei, läge der Zeitserver bestimmt nicht an erster Stelle. Aber da gehört er hin. Ohne einheitliche Zeit verursachen Netzwerkdienste massive Probleme: Die Synchronisation von Datenbanken schlägt mit Sicherheit fehl, wenn die Zeitstempel nicht übereinstimmen. Backups brechen ab, wenn die Dateien in die Zukunft datiert sind.

Auch Verschlüsselungs- und Authentisierungs-Software hängt von der korrekten Zeit im Netzwerk ab. Einige Betriebssysteme haben ebenfalls Probleme, wenn die Zeit im Netzwerk zu stark abweicht. Netware verweigert sogar den Dienst, wenn es keinen Zeit-Client auf den Maschinen findet. Auf Linux hat der Administrator die Wahl.

Ob die Zeit von einem Internetserver geholt wird oder von einem speziellen Empfänger, der direkt an einem lokalen Rechner hängt, ist ein kleiner, aber feiner Unterschied. Auch die eingesetzten Applikationen sind zu berücksichtigen. Viele hängen entscheidend von der richtigen Zeit ab, nur wenigen Anwendungen ist die Zeit egal.

In auf mehrere Standorte verteilten LANs, deren Datenbanken sich per WAN-Leitung synchronisieren, muss die gleiche Zeit herrschen, sonst ist das Chaos programmiert. Isolierte Netzwerke hingegen können auch mit geringen Zeitabweichungen leben oder kommen sogar ganz ohne Zeitgeber aus. Ungefährlich ist dies allerdings nicht.

Sinn für Zeit

Solche Netzwerke sollten zumindest per Software die Zeit von einem Internet-Zeitserver holen und diese an die restlichen Maschinen verteilen. Linux setzt das Network-Time-Protokoll (NTP)[1] ein, um solche Zeitquellen anzuzapfen. Allerdings bringt die Synchronisation übers Internet Gefahren mit sich und der Verwaltungsaufwand wächst. Der Administrator muss ein Auge auf eventuelle Sicherheitslücken haben und außerdem die Firewalls mit dem entsprechenden Regelwerk ausstatten.

Etwas einfacher hat es der IT-Verantwortliche, wenn eine richtige Uhr am LAN-Zeitserver angeschlossen ist. Die Konfiguration der Firewall entfällt zwar nicht, schließlich soll sich niemand von außen mit der Zeitmaschine verbinden. Aber der Administrator ist nicht dem Wohl und Weh der öffentlichen Internet-Zeitserver respektive der WAN-Anbindung ausgeliefert.

Zwei Sender sind in Europa interessant. Der DCF77-Sender (siehe Kasten "Das steckt hinter DCF77",[2]) steht nahe Frankfurt am Main und sendet den Zeitcode je nach den klimatischen Bedingungen bis zu 1500 Kilometer weit in den alten Kontinent. Die Weiterentwicklung in Allouis nahe der französischen Hauptstadt nennt sich TDF (siehe Kasten "Das steckt hinter TDF",[3]) und kommt bis zu 3500 Kilometer weit - ideal für Unternehmen, die Außenstellen in ganz Europa unterhalten.

Das steckt hinter DCF77

Der Name DCF77 beruht auf einer internationalen Vereinbarung. Der Buchstabe D steht dabei für Deutschland, C als Kennzeichen eines Langwellensenders und das F signalisiert die Nähe des Senders zu Frankfurt am Main. Die Antennen stehen tatsächlich rund 35 Kilometer von der Bankenmetropole entfernt in Mainflingen. Die 77 steht für die verwendete Sendefrequenz (77,5 kHz). Als Betreiber des DCF77 fungiert die Physikalisch-Technische Bundesanstalt (PTB). Die Deutsche Telekom AG verwaltet die Infrastruktur. Die Zeitreferenz stellt die Caesium-Atomuhr in Braunschweig, dem Sitz der PTB. Die Zeit, die der DCF77-Sender liefert und die auch per Satellit oder Telefondienst verbreitet wird, ist die gesetzliche Zeit in Deutschland. Ein Internet-Zeitserver, auch wenn er bei der PTB steht, liefert keinesfalls die gesetzliche Zeit. Dies müssen Unternehmen, die zeitkritische Transaktionen Cumputer-unterstützt vornehmen, beachten. Der Sender gibt das Signal dreimal stündlich zu den Minuten 19, 39 und 59 ab. Die Sendeleistung liegt bei 50 kW und erklärt die recht geringe Reichweite von offiziell 2000 Kilometern. Immerhin ist der Sender in den letzten Jahren niemals ausgefallen. Die Verfügbarkeit gibt der Betreiber trotzdem mit 99,7 Prozent an. Weitere Details zu DCF77, dem Kodierschema und dem Standort gibt es auf einer interessanten Seite im Web[2].

Das steckt hinter TDF

Das Zeitsignal TDF (TŽlŽ Distribution Francaise) kommt von der derzeit genauesten Atomuhr der Welt, der Caesium-Fontäne. Als Betreiber fungiert das Laboratoire Primaire du Temps et des Frequences (LPTF). Die internationale Institution mit Sitz in Paris koordiniert auch die offizielle Weltzeit (UTC). Die Infrastruktur unterhält der kommerzielle Sender France Inter. Das TDF-Signal ist kein exklusives Signal wie das deutsche DCF77, sondern einem ganz normalen Radiosender aufmoduliert. Das Zeitsignal im Empfänger zu dekodieren ist aufwändig, entsprechend sind die Geräte etwas teurer. Allerdings lohnen sich die paar Euro mehr, wenn das Unternehmen in ganz Europa verstreut Außenstellen unterhält. TDF deckt mit seiner Sendeleistung von 2000 kW ganz Europa bis auf Nordskandinavien ab. DCF77 reicht hingegen nicht einmal bis an die spanische Grenze.

Clock around the rock

In einem global operierenden Unternehmen reichen jedoch weder DCF77 noch TDF. Hier muss der Administrator Hilfe aus dem Orbit anfordern. Uhren, die das Signal des Global Positioning System (siehe Kasten "Das steckt hinter GPS",[4]) empfangen, eignen sich am besten, um die Zeit in einem auf mehrere Kontinente verteilten Netzwerk synchron zu halten. Allerdings sollte sich der Admin im Klaren darüber sein, dass die zivile Nutzung des US-Militärprojekts von den politischen Umständen beeinflusst wird und jederzeit ein Ende haben kann. Bis mit Galileo das rein zivile Äquivalent der EU Wirklichkeit wird, gibt es keine Alternative zu GPS.

Das steckt hinter GPS

Das GPS (Global Positioning System) setzt sich aus 24 Satelliten zusammen, die auf der Frequenz 1,575 GHz Lokalisierungs- und Synchronisationscodes senden. Zusätzlich enthält das Signal Datum und Uhrzeit. Schon drei Satelliten erlauben zusammen die Genauigkeit von mindestens einer Mikrosekunde (1/1000 s). Für den Empfang ist eine Außenantenne erforderlich. Die Zeitsynchronisation via GPS ist vor allem außerhalb Europas unumgänglich oder bei schwierigen Empfangslagen. GPS nutzen auch spezielle Anwendungen, die auf eine besonders genaue Uhrzeit angewiesen sind, etwa spezielle Zeiterfassungssysteme oder die präzise Datierung von Ereignissen. Eine interessante Facharbeit zu GPS, die sich auch mit mathematischen Hintergründen befasst, findet sich im Web auf[4].

So kommt die Zeit in den PC

In einer heilen Welt müsste der Admin von außen keine Zeit holen, denn in jedem Rechner steckt ja bereits ein Zeitgeber mit dem verheißungsvollen Namen Echtzeituhr (Real Time Clock, RTC). Die CMOS-Uhren oder Hardware-Clocks genannten Billiguhren sind jedoch nicht gerade ein Muster an Genauigkeit. Sie gehen pro Tag mehrere Sekunden falsch. Ohne Synchronisation benutzt dann jeder Rechner im Netzwerk seine eigene Zeit. Der Kernel verwaltet daher zusätzlich eine Software-Uhr. Diese so genannte Systemuhr zählt die Sekunden seit dem 1.1.1970. Beim Systemstart liest er die Hardware-Uhr aus und stellt die Systemuhr. Die Zeitzone verwaltet jedoch die Software-Uhr.

Sehr viel einfacher, als periodisch alle Uhren per Cron zu stellen, erhält der Verwalter ein zeitsynchrones Netzwerk mit einem Server. Der verteilt die Zeit an alle Stationen im Netzwerk und dient als Referenz. Als Transportprotokoll im homogenen Linux-Unix-Netzwerk empfiehlt sich NTP (Network Time Protocol, RFC 1305,[5]), das alle Unixe unterstützen. Wer zusätzlich Windows-2000/XP-Maschinen synchronisiert, kann wählen. Diese Microsoft-Systeme bringen SNTP (Simple Network Time Protocol, RFC 2030,[5]) mit, das mit dem NTP zusammenarbeitet.

Protokolle im Vergleich

NTP ist das gebräuchliche Protokoll unter Linux und den anderen Unix-Varianten. Wie nicht anders zu erwarten, bringt es eine Menge Optionen mit. Das auf Windows-2000/XP standardmäßig installierte SNTP glänzt hingegen mit einfacher Einrichtung und Verwaltung. Das Problem: Im heterogenen Netz muss der Admin das Linux- mit dem Microsoft-Protokoll verheiraten.

Sowohl NTP als auch SNTP kommunizieren über TCP/UDP und den Port 123. Sie fragen die Zeit von externen Quellen wie etwa einer Funkuhr im Rechenzentrum oder einem Zeitserver im Internet ab. Entweder holen sich die Clients die Zeit selbst ab oder bekommen sie via Broad-, Multi- oder Manycast vom Server gestellt.

Während SNTP lediglich eine Zeitquelle befragt und die Systemzeit anpasst, geht NTP genauer vor. Es benutzt mehrere Quellen über einen relativ langen Zeitraum. Auch bei anfangs hohen Abweichungen stellt es die Systemzeit nur in kleinen Schritten nach. Damit verhindert es, dass plötzlich ein Dienst nicht wie gewohnt funktioniert, weil die Zeitabweichung zu hoch ist. Dieser Aufwand schlägt sich in hoher Genauigkeit nieder, denn je nach der Genauigkeit der Quelle weiß NTP, wie es den lokalen Zeitserver einzuschätzen hat.

Die Einteilung der Genauigkeit erfolgt in Schichten, so genannten Strata. Die höchste Genauigkeit bieten GPS-Uhren oder DCF77- respektive TDF-Empfänger. Sie werden als Stratum 0 bezeichnet, da sie niemals falsch gehen. Bezieht der lokale Server die Zeit von einem Stratum-0-Gerät, wird er zur nächst ungenaueren Instanz, zum Stratum-1-Server.

Systemzeit und RTC stellen

Das Network Time Protocol liefert jede Distribution mit. Das aktuelle Paket als Quelltext gibt es auf[1]. Ob »ntp« oder »xntp« zum Einsatz kommt, ist letztlich egal. Der Unterschied ist laut der FAQ von Ntp.org, dass »xntp« auf die Protokollversionen 3 und früher verweist und mit »ntp« die Versionen 4 und höher gemeint sind. Das x in »xntp« stand ursprünglich für experimental. Dieser Artikel bezieht sich auf NTPv4, weshalb auch alle Befehle und Init-Skripts mit »ntp« anfangen.

Zu Beginn der Konfiguration stellt der Admin die Systemuhr so genau wie möglich. Denn fällt dem NTP-Daemon beim ersten Start auf, dass die Abweichung zur tatsächlichen Zeit mehr als 1000 Sekunden beträgt, bricht er die Synchronisation ab. Das Programm »date« stellt das Datum und die Uhrzeit ein:

date -s "2004-01-20 12:00:00"

Das Kommando setzt das Datum auf den 20. Januar 2004 und justiert die Systemzeit auf 12.00 Uhr mittags. Mit dem Programm »hwclock« setzt der Admin anschließend die Systemzeit auf die UTC:

hwclock --set --utc --date "2004-01-20 12:00:00"

Die Option »--localtime« statt »--utc« übernimmt die lokale Zeit als Systemzeit. Das ist nur in einem kleinen Netzwerk empfehlenswert und auch nur dann, wenn sich kein Dienst per WAN-Leitung synchronisiert.

Zeit-Daemon konfigurieren

Der Zeit-Daemon »ntpd« kümmert sich darum, dass alle Rechner im Netzwerk dieselbe Zeit haben. Dazu benutzt er unter anderem eine Kernelfunktion, die alle elf Minuten die Systemzeit auf die Hardware-Zeit überträgt. Das lässt man sich folgendermaßen anzeigen:

adjtimex --print

Der Daemon Ntpd benutzt diese Funktion automatisch, sodass der Admin nicht Hand anlegen muss.

Nach diesen Vorbereitungen kommen die Stratum-2-Server in die Datei »/etc /ntp.conf«. Die Stratum-2-Server sind vor allem in der Testphase vorzuziehen, da die Stratum-1-Server sehr viele Clients bedienen müssen. Es gilt als Ehrensache, den Administrator des Internet-Zeitservers zu informieren, dass ein weiterer Kunde dauerhaft seinen Zeitdienst in Anspruch nimmt. Die E-Mail-Adressen der Ansprechpartner stehen in der Liste der öffentlichen NTP-Server, die auf[1] einzusehen ist:

server tick.fh-augsburg.de
server ntp.ndsoftwarenet.com
server ntp1.tuxfamily.net
server fartein.ifi.uio.no
server 127.127.1.0

Die Server der Universitäten ermitteln die Zeit in der Regel über das Satelliten-Navigationssystem GPS. Der Stratum-1-Server der PTB (Physikalisch-Technische Bundesanstalt,[6]) bezieht die Zeit hingegen von einer Atomuhr. Der letzte Server 127.127.1.0 ist die lokale Uhr, die als unzuverlässiger Zeit-Server gilt. Doch ist diese Zeit die einzige Rettung, falls die Internetverbindung ausfällt.

Vorsicht übrigens: Die per NTP übers Internet bezogene Zeit ist in Deutschland nicht die gesetzliche Zeit. Diese liefert der DCF77-Sender in Frankfurt. Wichtig ist das, falls ein Unternehmen viele zeitkritische Transaktionen durchführt, etwa eine Bank. Wer sich mit Forderungen in diesem Zusammenhang konfrontiert sieht, hat bei Internet-NTP schlechte Karten.

Abweichungen abfangen

Abweichungen der Systemuhr von der Zeitquelle über einen bestimmten Zeitraum werden als Drift bezeichnet. Die langsame Verschiebung in die eine oder andere Richtung hält der NTP-Daemon in der Drift-Datei fest, sie kann eigentlich überall im System liegen. Zu beachten ist nur, dass das Drift-File vor dem Einsatz des NTP-Daemon nicht vorhanden sein darf, sonst bricht er ab. In der Regel legen die Distributionen das Drift-File irgendwo unter »/var/lib/ntp« ab. Der Admin stellt dies in der »ntp.conf« ein, zum Beispiel:

driftfile /var/lib/ntp/ntp.drift

Die Abweichung zu bestimmen ist mühsam und dauert mehrere Tage bis Wochen. Immer wieder vergleicht der lokale NTP-Daemon die Zeiten, sodass er bei einer Trennung vom Internet-NTP-Server so lange wie möglich selbst die richtige Zeit verteilen kann.

Damit ist die Konfiguration des NTP-Dienstes fürs Erste abgeschlossen. Der Zeitserver ist bereit für den ersten manuellen Start:

/etc/init.d/ntp start

Die Logdatei zeigt, was bei der Kontaktaufnahme passiert:

tail -f /var/log/ntp

Um weitere Informationen zu erhalten, steht der Client »ntpq« bereit. Er startet mit einer eigenen Shell ähnlich wie »ftp«. Bei einem Fragezeichen als Eingabe zeigt Ntpq alle möglichen Kommandos an. Jetzt am Anfang interessiert der Befehl »peer«, der eine Liste aller verbunden NTP-Server zusammen mit deren Stratum-Wert und der Zeitabweichung ausspuckt. Ein »*« hebt jenen Zeitserver hervor, den sich der lokale NTP-Dienst für die Synchronisation auserkoren hat. Mit »+« sind Server markiert, die der Daemon ansprechen wird, falls der aktive Hauptserver (»sys.peer«) nicht mehr richtig tickt. Es dauert allerdings je nach Zeitabweichung des lokalen Systems und der Laufzeit der LAN-Pakete einige Minuten, bis NTP die Synchronisation beginnt und einen Sys.peer aussucht.

Entsprechend sieht dann die NTP-Konfiguration weiterer Linux-Server aus. Hier steht nur noch das Referenzsystem in der Konfiguration:

server zeit.linuxmag.local
server 127.127.1.0
driftfile /var/lib/ntp/ntp.drift

Das NTP-Paket offeriert eine Menge Optionen, die normalerweise nicht von Interesse sind. Manchmal wichtig sind die Monitorfunktion und die Unterstützung für Kryptoschlüssel. Ausführlich behandelt diese Themen die FAQ[1].

Passende Hardware

Der Zeitserver im LAN muss sich die Referenz nicht aus dem Internet holen. Es gibt mehrere Hersteller weltweit, die Empfänger für DCF77/TDF oder GPS offerieren. Die Abbildungen zeigen einige Beispielgeräte, sie reichen vom günstigen Einsteigermodell (Abbildung 2) bis zu mehrfach gegen Störungen abgesicherten Präzisionsempfängern. Diese puffern die Zeit beispielsweise mehrere Monate, um schlechten Wetterbedingungen ein Schnippchen zu schlagen. Angeschlossen wird das Modell von Linum (Abbildung 1) an der seriellen Schnittstelle. Die PCI-Karte von Hopf (Abbildung 3) kommt wie das Linum-Modell bereits mit Linux-Treibern.

Abbildung 1: Die Neoclock 4X von Linum [9] offeriert unter dem Ufo zwei Antennen sowie einen DCF77- und TDF-Empfänger. Per serieller Schnittstelle mit bis zu 100 Meter Verlängerungskabel holt sich der Rechner die genaue Zeit von den Langwellensendern.

Abbildung 2: Günstige Funkuhren - hier von Conrad [7] - gibt es bereits ab 15 Euro. Sie eignen sich für kleine Netzwerke oder einzelne Maschinen. Den passenden Linux-Treiber hostet [8].

Abbildung 3: Per GPS-Einsteckkarte FG6039GPS von Hopf [10] bezieht das Netzwerk die Zeit aus dem Orbit. Die Karte erfordert den Anschluss einer Außenantenne, um das GPS-Signal einzufangen.

Infos

[1] NTP: [http://www.ntp.org] [2] DCF77: [http://www.dcf77.de] [3] TDF: [http://www.emetteurs.fr.fm] [4] GPS: [http://home.vr-web.de/benji/] [5] RFCs: [http://www.faqs.org/rfcs] [6] PTB: [http://www.ptb.de] [7] Conrad: [http://www.conrad.de] [8] Treiber für Conrad-Uhr: [http://www-stud.ims.uni-stuttgart.de/~voegelas/pcf.html] [9] Linum: [http://www.linum.com] [10] Hopf: [http://www.hopf.com]