Zeit… Ein unendliches Mysterium. Der stete Wandel. Und unsere Server müssen damit klar kommen.
Auf der gesamten Welt (sollten!) alle Maschinen wie ein gut synchronisiertes Orchester laufen. Und genau wie im echten Leben ein Trompeter, der nicht im Takt ist, am Liedgut massiven Schaden anrichtet, kann auch ein Internetserver, dessen Systemzeit nicht stimmt, böse Zwischentöne spucken.
Um dem entgegenzuwirken gibt es Zeitserver, welche den Maschinen rund um den Globus “den Marsch blasen”, sprich eine sauber eingetaktete Zeitquelle bieten. Wir müssen sie nur gekonnt anzapfen…
In diesem Sinne: Der Ball ist rund und ein Spiel dauert 90 Minuten. So viel ist schon mal klar. Der Rest ist Theorie. Und ab!
Kümmern wir uns heute mal um ein Orchideenthema :)
Im Basissystem installieren wir ja “ntpd” – den “Network Time Protocol Daemon”. Der reicht auch und macht, was er soll.
Dann bin ich über diesen Artikel von heise gestolpert, der darlegt, dass Facebook intern auf Chrony wechselt. Facebook selbst hat dazu einen sehr umfangreichen Post in ihr Development Blog gestellt.
Im Zuge der Umstellung bietet Facebook aus seinem Netzwerk nun mehrere öffentlich zugängliche Zeitserver mit verschiedenen Standorten auf der ganze Welt an.
Hey, hab ich mir gedacht, warum dieses Thema nicht auch abschließend behandeln. Schauen wir uns das doch mal genauer an…
Chrony installieren
Die Installation geht sehr einfach und schnell mit einem Kommando:
apt -y install chrony dnsutils [...] Die folgenden Pakete werden ENTFERNT: ntp Die folgenden NEUEN Pakete werden installiert: chrony dnsutils libirs161 [...]
Dabei wird der “ntp”-Server entfernt und stattdessen “chrony” installiert. Die beiden würden sich sonst ins Gehege kommen. Wie zwei Web- oder Mailserver, die auch nicht einfach so parallel auf der gleichen Maschine laufen dürfen.
Chrony besteht aus zwei Teilen:
chronyd – der eigentliche Daemon, der im Hintergrund unseres Systems läuft.
chronyc – das Kommandozeilen-Tool, mit dem wir den Daemon beauskunften.
Nun müssen wir nachsehen, ob Chrony “enabled” wurde, also beim Systemstart automatisch geladen wird:
systemctl status chronyd
● chrony.service - chrony, an NTP client/server # |== hier müsste "enabled" stehen...
Loaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2020-04-12 20:19:11 CEST; 31s ago
Docs: man:chronyd(8)
man:chronyc(1)
man:chrony.conf(5)
Main PID: 23266 (chronyd)
Tasks: 2 (limit: 4701)
Memory: 1.3M
CGroup: /system.slice/chrony.service
├─23266 /usr/sbin/chronyd -F -1
└─23267 /usr/sbin/chronyd -F -1
Apr 12 20:19:11 xp-server.de systemd[1]: Starting chrony, an NTP client/server...
Apr 12 20:19:11 xp-server.de chronyd[23266]: chronyd version 3.4 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG)
Apr 12 20:19:11 xp-server.de chronyd[23266]: Frequency 10.473 +/- 0.293 ppm read from /var/lib/chrony/chrony.drift
Apr 12 20:19:11 xp-server.de chronyd[23266]: Loaded seccomp filter
Apr 12 20:19:11 xp-server.de systemd[1]: Started chrony, an NTP client/server.
Apr 12 20:19:17 xp-server.de chronyd[23266]: Selected source 2a03:2880:ff09::123 Steht hier “enabled”, dann passt alles. Sollte “disabled” auftauchen, müssen wir den Dienst noch “enablen”:
systemctl enable chronyd
Chrony konfigurieren
Nachdem Chrony installiert wurde, tragen wir ihm die Zeitserver ein, von denen er sich mit der aktuellen Systemzeit versorgen soll. Die nehmen wir von Google und Facebook, weil diese beiden absolute Dickschiffe im Netz sind und den Laden am Laufen halten. Darum vertraue ich denen, dass sie – schon aus eigenem Interesse – eine vernünftige Zeit ausliefern, der man vertrauen kann.
Die Server sind über den ganzen Globus verteilt, damit man immer auch in seiner eigenen Region ein System stehen hat, das man “schnell” ansprechen kann. Da macht nämlich die Laufzeit des Signals durch das WWW einen Faktor aus, den unser Zeitsystem später korrigieren muss. Die Konfiguration ist ebenfalls schnell erledigt:
nano /etc/chrony/chrony.conf ### Wir kommentieren den voreingestellten Pool aus: #pool 2.debian.pool.ntp.org iburst ### Dafür tragen wir gleich darunter unsere neuen Zeitserver ein: server time1.google.com iburst server time2.google.com iburst server time3.google.com iburst server time4.google.com iburst server time1.facebook.com iburst server time2.facebook.com iburst server time3.facebook.com iburst server time4.facebook.com iburst server time5.facebook.com iburst
Wir speichern die Änderungen. Dann starten wir den Chrony Daemon neu, damit er sich die geänderte Config lädt und entsprechend auch unsere gerade eingestellten Server benutzt.
Chrony neustarten und den Status abfragen
systemctl restart chronyd
Jetzt ist der Dienst neu gestartet. Schauen wir mal, was er macht:
chronyc activity 200 OK 0 sources online 0 sources offline 9 sources doing burst (return to online) 0 sources doing burst (return to offline) 0 sources with unknown address
Chrony “pingt” die neun Server an. Sobald das Ergebnis vorliegt, werden die Server “online” geschaltet.
Ein paar Sekunden später:
chronyc activity 200 OK 9 sources online 0 sources offline 0 sources doing burst (return to online) 0 sources doing burst (return to offline) 0 sources with unknown address
Schön, die Server wurden abgefragt und sind jetzt verfügbar.
Mehr Info, bitte:
chronyc tracking Reference ID : A8EF0BC5 (time1.facebook.com) Stratum : 2 Ref time (UTC) : Sun Mar 29 11:55:42 2020 System time : 0.000000003 seconds fast of NTP time Last offset : -0.000026087 seconds RMS offset : 0.000026087 seconds Frequency : 10.218 ppm fast Residual freq : -2.659 ppm Skew : 2.513 ppm Root delay : 0.003839974 seconds Root dispersion : 0.000210573 seconds Update interval : 1.8 seconds Leap status : Normal
Chrony hat sich für einen Zeitserver von Facebook entschieden.
Die genauen Werte sind für uns aber nicht wirklich von Bedeutung. Hauptsache, er macht “sein Ding” und setzt uns die Zeit richtig.
Was haben wir denn noch für Quellen?
chronyc sources -v 210 Number of sources = 9 .-- Source mode '^' = server, '=' = peer, '#' = local clock. / .- Source state '*' = current synced, '+' = combined , '-' = not combined, | / '?' = unreachable, 'x' = time may be in error, '~' = time too variable. || .- xxxx [ yyyy ] +/- zzzz || Reachability register (octal) -. | xxxx = adjusted offset, || Log2(Polling interval) --. | | yyyy = measured offset, || \ | | zzzz = estimated error. || | | \ MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^- time1.google.com 1 6 17 16 -138us[ -138us] +/- 5285us ^+ time2.google.com 1 6 17 17 -62us[ -88us] +/- 5503us ^+ time3.google.com 1 6 17 17 -50us[ -76us] +/- 5380us ^+ time4.google.com 1 6 17 16 -19us[ -45us] +/- 5495us ^* time1.facebook.com 1 6 17 16 -9567ns[ -36us] +/- 2073us ^- time2.facebook.com 1 6 17 17 +2980us[+2953us] +/- 11ms ^- time3.facebook.com 1 6 17 17 -16us[ -42us] +/- 6387us ^+ time4.facebook.com 1 6 17 16 -162ns[ -26us] +/- 2093us ^+ time5.facebook.com 1 6 17 17 +50us[ +24us] +/- 3997us
Mit diesem Kommando erhalten wir eine detaillierte Übersicht zu allen neun Zeitservern, welche wir eingetragen haben. Daraus setzt sich Chrony nun unsere Systemzeit zusammen.
systemd Zeitgeber ausschalten
Sven hat mich freundlicherweise darauf hingewiesen, den systemd-Zeitgeber abzuschalten, da wir ihn ja dank Chrony nicht mehr brauchen…
timedatectl set-ntp 0
Fazit
Chrony – besser oder schlechter als ntpd?
“Time will tell” (Pun not intendet)…
Nein, ohne Schmarrn. Für einen kleinen Einzelserver sollte das ziemlich wurscht sein, ob wir über ntpd oder Chrony unsere Zeit synchronisieren. In einem riesigen Serververbund, wie den Facebook Rechenzentren, macht das allerdings schon was aus. Und wenn die sagen, dass bei denen Chrony Vorteile zum ntpd hat…?
In der Gastronomie haben die auch das HACCP-Konzept bis in die kleinste Dorfwirtschaft aufgedrückt bekommen. Das ist ein Protokoll, das die NASA dafür entwickelt hat, bestmöglich sicherzustellen, dass Astronautennahrung nicht kontaminiert wird. Weil – schlecht. Und was für die NASA toll ist – hey – das kann man natürlich auch bis ins letzte Dorfgasthaus übertragen. Overkill hin oder her.
Sprich wenn Facebook sagt, Chrony ist für ihr Netzwerk OK… Dann bin ich mir sicher, dass es für unseren kleinen Server auch passt!
