Ein Thema das öfters mal etwas vernachlässigt wird ist das Thema „Zeit“. Oftmals reicht es einem aus, wenn die Uhr in etwa richtig geht und man noch die Zeitzone richtig eingestellt bekommt, fertig. Dabei ist eine exakte Uhr gar nicht so unwichtig. Es gibt viele Dienste, für die eine recht exakte Uhrzeit wichtig ist, wie z.B. 2-Faktor-Authentifizierung oder auch das Authentifizierungsprotokoll Kerberos. Geht die Uhr „zu viel“ falsch, funktioniert die Anmeldung über diese Dienste nicht mehr. Bei 2FA ist eine Abweichung von einer Minute meist noch verkraftbar, bei Kerberos reichen jedoch schon Fehler im Sekundenbereich und das Protokoll funktioniert nicht mehr.
Aber auch das Auffinden von Fehlern wird erleichtert. Hat man ein Setup aus zwei oder mehreren Servern, ein Server ist z.B. Proxy, auf den anderen läuft die Applikation, so ist es sehr hilfreich wenn die Zeiten in den Log-Dateien der Server vergleichbar sind. Und nicht „10:13:12“ auf Server A entspricht „10:13:42“ auf Server B und das wiederum entspricht „10:13:34“ auf Server C…
Zum Glück gibt es ein einfaches Protokoll, dass unser Problem lösen kann: NTP. Und dazu gibt es auch gleich einen fertigen Client/Server, den man nur noch zu installieren braucht. Dafür führen wir als erstes auf der Konsole folgenden Befehl aus:
$ apt-get install ntp
Damit ist der NTP-Dienst installiert und verfügt auch schon über eine funktionierende Standard-Konfiguration. Der NTP-Dienst ist immer gleichzeitig Client und Server, d.h. er aktualisiert die Zeit eures Systems, stellt aber auch seine Zeit anderem System zur Verfügung. Unter Debian werden standardmäßig Zeit-Server (oder auch NTP-Server) des „NTP Pool Project“ verwendet. Im Grunde braucht ihr auch jetzt erst mal nichts mehr anzupassen, in der Standard-Einstellung funktioniert der Dienst eigentlich tadellos und beginnt eure Zeit zu synchronisieren. Anschauen könnt ihr euch das mit folgendem Befehl:
$ ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
-78.46.93.XXX 193.67.79.202 2 u 574 1024 377 21.899 3.623 5.974
+52.29.139.XXX 130.149.17.21 2 u 161 1024 377 17.773 0.419 0.301
*213.136.86.XXX 131.188.3.221 2 u 394 1024 177 23.875 -0.648 0.355
+46.235.112.XXX 193.171.23.163 2 u 281 1024 377 23.534 0.395 0.290
Die IP mit dem * ist der aktuell genutzte Zeit-Server. Die Zeile delay enthält quasi den Ping, den ihr zu dem Server habt. offset entspricht der Abweichung eurer Uhr zu der Uhr des Servers. Und jitter gibt an, wie „genau“ die Zeitmessung über das Internet ist bzw. um wie viel sie schwankt. Alle Zeiten sind in Millisekunden.
In diesem Beispiel synchronisiert die Uhr des Systems mit der Uhr des Zeit-Servers „213.136.86.XXX“, die Paketlaufzeit zum Zeitserver beträgt etwa 24ms und die Abweichung der lokalen Uhr zur Uhr des Zeitservers beträgt etwa -0,6ms. Die Schwankung der Messwerte (und damit die Messungenauigkeit) beträgt etwa 0,4ms. Von daher sollte die Zeit auf dem lokalen System nicht mehr wie 1ms von der des Zeit-Servers abweichen. Wenn ihr mehr Details zu den Bedeutungen der einzelnen Einträge haben wollt empfehle ich euch folgende Seite: Real Life NTP
Mit den Standard-Einstellungen von Debian erreicht man also eine Genauigkeit von etwa 1ms. Das ganze lässt sich aber noch etwas optimieren. Der NTP-Dienst wird mithilfe der Datei /etc/ntp.conf konfiguriert. Diese öffnen wir nun und schauen uns vor allem die Zeilen server an, die wie folgt aussehen:
server 0.debian.pool.ntp.org iburst server 1.debian.pool.ntp.org iburst server 2.debian.pool.ntp.org iburst server 3.debian.pool.ntp.org iburst
Hier werden 4 Zeit-Server festgelegt. Diese stammen aus dem Vendor-Pool von Debian. Jedoch gibt es noch weitere Pools die nach anderen Kriterien geordnet sind, wie z.B. nach Land. So gibt es z.B. einen Pool, indem nur deutsche Server vorhanden sind. Sollte man in Deutschland sein, ist es sehr sinnvoll, diesen Pool zu nutzen. Damit stellt man sicher, das einem nicht Zeitserver aus z.B. Amerika zugeordnet werden. Diese haben logischerweise eine größere Latenz und der Jitter ist aufgrund der langen Strecke ebenfalls größer, was zu höheren Ungenauigkeiten führen kann.
Daher ersetzten wir die Zeit-Server in der Config-Datei durch deutsche Zeit-Server aus dem Pool:
server 0.de.pool.ntp.org iburst server 1.de.pool.ntp.org iburst server 2.de.pool.ntp.org iburst server 3.de.pool.ntp.org iburst
Anschließend müssen wir nur noch den NTP-Dienst neu starten und anschließend ist sichergestellt, dass nur noch deutsche Zeit-Server verwendet werden:
$ service ntp restart
Aufbau NTP
Ein ganz kleiner Einblick in den Aufbau von NTP:
NTP kann man sich als Hierarchie vorstellen: Ein Server „bestimmt“ was die aktuelle Zeit ist, und gibt diese per NTP weiter. Dieser Server kann wiederum die Zeit an andere weitergeben und so weiter. Diese Ebenen bezeichnet man als Stratum. „Stratum 0“ entspricht dabei der Zeitquelle, also z.B. die Zeit via GPS, DCF77 oder sonstigen hochpräzisen Zeitquellen. Stratum 1 ist dann der erste NTP-Server, der diese Zeit verbreitet. Der nächste Server, der seine Zeit von einem Stratum 1 Server bezieht, wird Stratum 2. Der Server, der seine Zeit von einem Stratum 2 Server bezieht und weiter verteilt wird Stratum 3 und so weiter.
Je höher das Stratum, desto höher das Potential, dass die Zeit einen Fehler hat. In der Ausgabe von ntpq -pn steht in der Spalte „st“ das Stratum-Level der Zeit-Server, die genutzt werden. In unserem Beispiel oben synchronisieren wir mit Zeit-Server vom Stratum-Level 2, d.h. diese Server haben ihr Zeit von einem Stratum 1 Server, der seine wiederum von einer hochpräzisen Zeitquelle hat. Wir selbst sind dann ein Stratum 3 Server.
Zudem steht bei der Ausgabe von ntpq -pn, woher der Server seine Zeit bezieht. Diese Information ist in der Spalte refid enthalten. Ist dies eine IP, so zeigt die IP auf den Zeitserver, von woher die Zeit bezogen wird. Es muss aber nicht zwangsläufig eine IP sein. Handelt es sich um einen Stratum 1 Server, so wird dort die Zeitquelle angegeben, z.B. .DCFx. wenn es sich um einen DCF77-Empfänger handelt, .GPS. wenn die Zeit vom GPS-Signal kommt…
mehrere Server synchronisieren
Betreibt man mehrere Server, so empfiehlt sich ein leicht geändertes Setup. Wie bereits erwähnt fungiert jeder NTP-Dienst als Client, aber auch als Server. Von daher reicht es aus, einen oder zwei Server (wir nennen sie mal A und B) mit einem externen Dienst zu synchronisieren, und die restlichen internen Server (C, D, E…) mit diesen beiden Servern (A und B) zu synchronisieren. Der Vorteil dieser Lösung ist, dass die Server untereinander nur eine minimale Abweichung haben, da die Uhrzeit nur über das lokale Netzwerk synchronisiert werden muss, wodurch Delay und Jitter sehr klein werden.
Des Weiteren kann man sich überlegen, falls die Server über eine statische IP verfügen, selbst am „NTP Pool Project“ teilzunehmen. Die durch NTP verursachte Last ist quasi kaum feststellbar, merklich Bandbreite wird auch nicht benötigt, die Einschränkungen sind also minimalst. Daher habe ich selbst 3 meiner Server dem NTP Pool Project via IPv4 und IPv6 zur Verfügung gestellt.
Wenn ihr euch jedoch überlegt, dem Projekt beizutreten, müsst ihr eure Konfiguration ändern. Server, die Zeit für das „NTP Pool Project“ zur Verfügung stellen, sollen ihre Zeit selbst nicht von genau diesem Projekt beziehen. Klingt paradox, ist aber sinnvoll.
Wenn wir nun Teil des NTP Pool Projects werden wollen, sollten wir möglichst präzise Zeit-Server nutzen. Es empfehlen sich Zeit-Server vom Stratum 2 oder sogar vom Stratum 1 Level zu nutzen. Dazu könnt ihr auf die Links klicken, diese enthalten Listen von öffentlich verfügbaren Zeit-Servern. Nun solltet ihr in eurer Konfiguration 4-6 Server, die in eurere Nähe sind, eintragen. Ich nutze z.B. die Zeit-Server des PTB sowie einige Zeit-Server von Universitäten. Anschließend starten wir wieder den NTP-Dienst neu und lassen uns den Status des NTP-Dienstes nach einer Minute anzeigen.
$ service ntp restart
$ ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
+192.53.103.108 .PTB. 1 u 495 1024 377 14.799 0.003 1.367
*192.53.103.104 .PTB. 1 u 509 1024 377 14.847 -0.003 0.621
+130.133.1.10 .PPS. 1 u 539 1024 377 17.702 -0.207 0.698
-130.149.17.8 130.149.17.21 2 u 980 1024 377 14.477 -1.864 1.360
Diese Ausgabe sieht nun leicht anders aus. Wie man sieht verwende ich 3 Stratum 1 Server und einen Stratum 2 Server. Die Spalte refid gibt an, von woher der Server seine Zeit bezieht. Die ersten beiden Server sind die Zeit-Server des PTB, diese beziehen ihre Zeit von der Atomuhr des PTB, welche die offizielle Zeit in Deutschland wiederspiegelt. Der dritte Zeit-Server nutzt eine hochgenaue Frequenzquelle zur Ermittlung der aktuellen Zeit. Und der letzte Server nutz die angegebene IP als Zeitquelle. Wie man anhand des * sieht, wird aktuell der zweite Server genutzt, welcher ein Stratum 1 Server des PTB ist. Somit ist euer Server selbst Stratum 2.
Mit dieser Konfiguration kann man nun dem NTP Pool Project beitreten. Dazu klickt ihr einfach oben auf „Join the Pool“, legt euch einen Account an und schaltet diesen mit dem Link in der E-Mail frei und hinterlegt anschließend nur noch bei „Manage Servers“ die IP eures Servers. Anschließend wird euer Server zunächst überwacht in Hinsicht auf Zuverlässigkeit. Sobald er einen Grenzwert überschritten hat, wird er dem Pool hinzugefügt. Fertig 🙂 Hier könnt ihr z.B. meine Server sehen die Teil des Pooles sind: klick
Solltet ihr weitere eigene Server haben, so empfiehlt es sich für diese Server nun nicht mehr den Pool zu nutzen, sondern euren eigenen Stratum 2 Zeit-Server. Und falls ihr, warum auch immer, den Pool mal verlassen möchtet, so könnt ihr dies online über das Interface eure IP löschen. Aber seit gewarnt, es kann sehr lange dauern bis eure IP aus allen Caches verschwunden ist, von daher wundert euch nicht das es einige Zeit dauern kann, bis keine NTP-Pakete mehr kommen.
Ein Gedanke zu „NTP – damit der Server richtig tickt“