Server und virtuelle Maschinen

Wie Time-Drift Server ausbremsen kann – NTP, Chrony & Zeit-Synchronisation

NTP Chrony Hosting stoppt Time-Drift, der Server ausbremst, indem es Uhren zügig angleicht, Log-Zeiten ordnet und Authentifizierungen zuverlässig hält. Ich zeige, wie Chrony, NTP und systemd-timesyncd zusammenspielen, warum Drift entsteht und welche Einstellungen in Hosting-Umgebungen Ausfälle und Sicherheitsrisiken vermeiden.

Zentrale Punkte

Time-Drift: Ursachen, Folgen und warum Millisekunden zählen
NTP-Hierarchie: Stratum-Design für interne Zeitquellen
Chrony vs. ntpd vs. systemd-timesyncd in Rechenzentren
NTS & Hardware-Timestamps: Sicherheit und Genauigkeit
Monitoring & Troubleshooting für dauerhafte Konsistenz

Wie Server-Time-Drift entsteht und wirkt

Time-Drift entsteht, weil die RTC eines Hosts leicht zu schnell oder zu langsam läuft und sich der Fehler mit jedem Tag summiert. Schon kleine Abweichungen erzeugen widersprüchliche Zeitstempel, was Transaktionen, Caches und Replikation stört. Zertifikate können plötzlich „zu früh“ oder „zu spät“ erscheinen und Authentifizierungen scheitern. In verteilten Systemen verliert man die Ordnung von Events und Debugging wird schwer bis unmöglich. Ich sehe in Hosting-Umgebungen regelmäßig, dass fehlende Synchronisation zu Ausfällen führt, die man mit einem soliden Zeitdesign vermeidet.

NTP-Stratum kurz erklärt

Das Stratum-Modell ordnet Zeitquellen hierarchisch und reduziert Abhängigkeiten vom Internet. Stratum‑0 sind Referenzuhren wie GPS oder Funk; Stratum‑1-Server hängen direkt an ihnen; Stratum‑2 bezieht von Stratum‑1. In Hosting-Umgebungen lohnt sich ein interner Stratum‑3-Server, der alle Knoten versorgt und externe Last senkt. So verteile ich eine einheitliche Zeit an Hosts und Container ohne jeden Knoten ins Internet zu schicken. Diese Architektur ermöglicht konsistente Logs, passende Zertifikatsfenster und replizierte Datenbanken mit sauberer Reihenfolge.

NTP, Chrony oder systemd-timesyncd? Der Vergleich

Ich setze Chrony in produktiven Setups ein, weil es schneller einrückt und bei instabilen Netzen sauber nachzieht. Der Klassiker ntpd arbeitet solide, braucht aber länger, bis die Uhr „sitzt“. systemd-timesyncd ist leichtgewichtig und genügt für einfache Hosts, dient jedoch nicht als Server. Für Cluster oder Hosting empfehle ich eine einheitliche Implementierung auf allen Knoten, um Mischbetrieb und Nebeneffekte zu vermeiden. Die folgende Tabelle fasst die wichtigsten Unterschiede zusammen.

Implementierung	Stärken	Schwächen	Geeignet für
Chrony	Schnelle Synchronisation, tolerant bei Packet-Loss, Server- und Client-Modus, guter Offline-Umgang	Mehr Optionen erfordern saubere Konfiguration	Produktive Server, Clouds, VMs, Container
ntpd	Langjährig erprobt, breite Verfügbarkeit	Träge beim Anlauf, weniger flexibel bei mobilen Hosts	Legacy-Umgebungen, konservative Setups
systemd-timesyncd	Schlank, SNTP-Client, quasi „zero config“	Kein Server-Modus, eingeschränkte Features	Kleine Server, Appliances, einfache VMs

Rollenmodell: Zeit-Clients und interne Server klar trennen

In der Praxis trenne ich strikt zwischen Client-only-Hosts und internen NTP-Servern. Clients fragen nur definierte Quellen ab und bieten selbst keinen NTP-Port an. Interne Server aggregieren mehrere Quellen, prüfen Qualität und verteilen Zeit in die Umgebung. So reduziere ich Angriffsfläche und halte die Abhängigkeitskette kurz.

Wichtig ist, Polling-Intervalle und Präferenzen sauber zu setzen. Ich markiere eine zuverlässige interne Quelle mit prefer und halte externe Anbieter als Fallback. In Netzen mit Latenzschwankungen senke ich gelegentlich minpoll, um schneller Korrekturen zu messen, erhöhe aber maxpoll wieder, sobald Stabilität erreicht ist, um Netzwerk-Last niedrig zu halten.

Chrony in der Praxis: Konfiguration für Hosting

Ich starte mit einer klaren chrony.conf, die Drift, Stratum und Zugriffe festlegt. Eine Minimalbasis umfasst:

driftfile /var/lib/chrony/drift local stratum 8 manual allow 192.168.0.0/16

Die driftfile merkt sich den Taktfehler und beschleunigt die Korrektur nach Reboots. Mit „local stratum 8“ bleibt der interne Server niedrig priorisiert, falls externe Quellen verfügbar sind. „allow“ regelt, welche Netze Zeit holen dürfen und verhindert Missbrauch. Ich aktiviere den Dienst mit systemctl start chronyd und systemctl enable chronyd und prüfe anschließend Status und Quellen.

Client-only und Server-Profile

Auf reinen Clients deaktiviere ich den Server-Port und halte die Konfiguration schlank:

# Client-only Profil server ntp-intern.example iburst prefer server ntp-extern-1.example iburst server ntp-extern-2.example iburst port 0 makestep 1.0 3 rtcsync leapsectz right/UTC

port 0 verhindert, dass der Host selbst Zeit anbietet. makestep 1.0 3 erlaubt in den ersten drei Messungen eine harte Korrektur >1s, danach wird nur noch geslewt (sanft angepasst). rtcsync hält die RTC in vernünftigen Abständen synchron, damit Reboots ohne große Sprünge starten.

Auf internen NTP-Servern konsolidiere ich Quellen und regle Zugriffe fein:

# Interner NTP-Server pool 0.pool.example iburst maxsources 4 server ref1.example iburst prefer nts server ref2.example iburst nts allow 10.0.0.0/8 allow 192.168.0.0/16 bindaddress 0.0.0.0 bindcmdaddress 127.0.0.1 cmdallow 127.0.0.1 driftfile /var/lib/chrony/drift makestep 0.5 5 local stratum 8 leapsectz right/UTC

Ich binde den Kommando-Socket an 127.0.0.1 und erlaube ihn nur lokal. pool hält mehrere Quellen automatisch aktuell. prefer setzt die gewünschte Primärquelle. In größeren Setups setze ich bindaddress gezielt auf ein Management-VLAN.

Polling, Quellenqualität und Stabilität

Bei wackeligen Netzen erhöhe ich anfangs die Messdichte und fahre nach Stabilisierung hoch:

server ntp-extern-1.example iburst minpoll 6 maxpoll 10

Mit minsamples, maxsamples und maxdistance cancele ich schlechte Quellen frühzeitig. Bei asynchronen Pfaden oder asymmetrischem Routing hilft hwtimestamp auf geeigneten NICs, Jitter zu reduzieren:

hwtimestamp eth0

Sicherheit und Genauigkeit: NTS, Hardware-Timestamps, Leap Seconds

Ich schütze NTP-Verbindungen mit NTS, damit ein Angreifer keine falsche Zeit einschleust. Ein Eintrag wie server time.cloudflare.com iburst nts liefert zügigen Start durch iburst und kryptografische Absicherung. Wo die Netzwerkkarte es erlaubt, aktiviere ich Hardware-Timestamping, um Latenzschwankungen im Kernel zu umgehen. Für Schaltsekunden nutze ich „leapsectz right/UTC“, damit Dienste keine harten Zeitsprünge sehen. Diese Kombination hält Dienste verlässlich und verhindert Fehler bei empfindlichen Anwendungen.

Härtung und Netzdesign

Ich beschränke UDP/123 strikt auf die vorgesehenen Netze, sowohl Richtung eingehend (Clients → interner Server) als auch ausgehend (Server → externe Quellen). Auf Clients setze ich port 0, damit sie gar nicht erst als Quelle missbraucht werden können. allow/deny in Chrony filtert zusätzlich. In segmentierten Netzen positioniere ich die internen Server in einem Netz mit niedriger Latenz zu den Workern und halte den Pfad deterministisch (keine asymmetrischen Routen, kein übermäßiges Shaping).

NTS erfordert eine initiale Schlüsselvereinbarung über einen dedizierten Port. Ich erlaube diesen Zielport nur Richtung vertrauenswürdiger Anbieter. Fällt NTS aus, definiere ich bewusstes Fallback-Verhalten (strenger Alarm statt stilles Umschalten auf ungesicherte Quellen). So vermeide ich „leises Verrotten“ der Sicherheit.

Leap-Second-Strategien und Smearing

Ich entscheide pro Umgebung: klassisches Leap-Handling (UTC mit Sprungsekunde) oder Leapsmearing, bei dem die Sekunde über ein Fenster geglättet wird. Wichtig: Nicht mischen. Wenn manche Quellen schmieren und andere nicht, kommt es zu dauerhaften Offsets. In kritischen Clustern halte ich die gesamte Flotte auf einer Linie und dokumentiere die Wahl. Chrony erlaubt sauberes Leap-Handling über leapsectz; wer smootht, muss das konsistent für alle Knoten planen.

Monitoring und Troubleshooting: Drift sichtbar machen

Ich prüfe Status und Offsets mit timedatectl sowie den Chrony-Tools wie chronyc sources und tracking. Abweichungen zwischen RTC und Systemzeit sind anfangs normal, sollten aber schnell kleiner werden. Für Langzeitkontrolle integriere ich Metriken und Alarme in einen Monitoring-Stack. So erkenne ich Trends, Peaks und Ausreißer, bevor Nutzer etwas merken. Alerts triggern automatisch, wenn Offsets über definierte Schwellen gehen.

Kennzahlen und Alarm-Schwellen

System-Offset (Tracking last/avg offset): Warnung ab 5 ms, kritisch ab 25 ms in Web/DB-Stacks.
Root dispersion: Gibt die Unsicherheit der Quelle an. Steigt sie dauerhaft, reagiere ich mit Quellenwechsel.
Reachability und Jitter je Quelle: Paketverlust und Instabilität früh erkennen.
Stratum: Unerwartete Stratum-Erhöhungen deuten auf Isolierung oder Quellenverlust hin.

Für Ad-hoc-Diagnosen nutze ich zusätzlich:

chronyc sourcestats -v chronyc ntpdata chronyc rtcdata chronyc activity

Zeigt activity viele ungültige Quellen, prüfe ich Firewall, MTU/Fragmentierung und asymmetrische Pfade. Bei großen Sprüngen nach Reboots ist makestep oft nicht gesetzt oder blockiert durch zu enge Schwellen.

Best Practices für konsistente Zeit in Clustern

Ich halte die Zeitquelle redundant, typischerweise mit mindestens drei Servern, damit einer ausfallen darf. Ein interner Stratum‑3-Server versorgt die Flotte und bezieht selbst von mehreren Stratum‑2-Quellen. Mischbetrieb mit ntpd und Chrony vermeide ich, da unterschiedliche Algorithmen unerwartete Offsets erzeugen können. Die RTC speichere ich in UTC mit timedatectl set-local-rtc 0, damit Sommerzeitwechsel keine Überraschungen bringen. Jede Änderung dokumentiere ich, damit ich im Störfall schnell die Historie verstehe.

Kubernetes und Orchestrierung

In Kubernetes und ähnlichen Orchestrierungen setze ich Chrony nur auf den Nodes, nicht in einzelnen Pods. Container erben die Hostzeit; doppelte Korrekturen führen zu Drift. Komponenten wie etcd reagieren empfindlich auf Zeitfehler – schon zweistellige Millisekunden können Wahl-Timeouts tangieren. Ich stelle sicher, dass Control-Plane und Worker dieselbe interne Quelle nutzen und dass keine Pod/Node mit leapsmear-Mix unterwegs ist.

Cloud-Besonderheiten

Viele Cloud-Provider stellen interne Zeitserver bereit. Ich nutze diese gern als Primärquelle (niedrige Latenz) und ergänze externe NTS-Quellen als Fallback. Bei Instanzen mit hibernation oder stops erlaube ich initiale Steps per makestep. Host-zu-Gast-Zeitsynchronisation über Agenten schalte ich ab, wenn Chrony aktiv ist, um Doppelkorrekturen zu vermeiden.

Spezielle Szenarien: VMs, Container und Cloud

In VMs achte ich auf Host‑to‑Guest‑Zeit, denn doppelte Korrekturen (Hypervisor und Gast) erzeugen Chaos. Container beziehen Zeit vom Host, daher fokussiert sich die Pflege auf den Unterbau. In elastischen Umgebungen, in denen Instanzen häufig starten, zahlt sich die schnelle Konvergenz von Chrony aus. Bei Edge-Standorten mit schlechter Verbindung profitiert man von Chronys Verhalten bei Packet-Loss und temporärer Offline‑Phase. Für Performance-Analysen rund um Zeitbezug und Latenz hilft mir diese Antwortzeit-Analyse.

Performance-Effekte: Datenbanken, Logs und Zertifikate

Saubere Zeit reduziert seltsame Deadlocks in Datenbanken, weil Transaktionsreihenfolgen konsistent bleiben. Caches invalidieren korrekt, CRLs und OCSP greifen in echten Zeitfenstern. In der Praxis verschwinden viele „Geisterfehler“, wenn Offsets unter Kontrolle sind. Für korrekte Korrelation von Ereignissen setze ich auf zentrale Log-Analyse mit identischer Zeitquelle. Zertifikate verhalten sich verlässlicher, weil Gültigkeitsfenster mit der Systemzeit übereinstimmen.

Migrationspfad zu Chrony ohne Aussetzer

Ich plane die Umstellung in Wellen, damit Dienste jederzeit Zeit beziehen. Zuerst baue ich einen internen Chrony-Server und lasse einige Staging-Hosts darauf zeigen. Sobald Quellen stabil laufen, wechsle ich produktive Knoten schrittweise. Während der Migration messe ich Offsets und Wartezeiten, um Abweichungen früh zu sehen. Ist alles konsistent, deaktiviere ich alte ntpd-Instanzen und räume Altlasten auf.

Rollback und Notfallplan

Ich halte ein Rollback bereit: alte Konfigurationen versioniere ich, und ich dokumentiere eine Reihenfolge für die Rückkehr auf ntpd oder systemd-timesyncd, falls nötig. Für den Ernstfall notiere ich ein kurzes Runbook: Dienste pausieren, chronyd stoppen, Zeit manuell setzen (nur wenn unabdingbar), Dienst wieder starten, Quellen prüfen, Offsets überwachen. Kritisch ist, manuelle Eingriffe eng zu begrenzen, um Sprünge in Applikationen zu vermeiden.

Checkliste zur Umsetzung

Ich definiere anfangs klare Zeitquellen und die Zielhierarchie mit internem Stratum‑3‑Server. Danach erstelle ich eine einheitliche Konfiguration für alle Hosts, teste sie in Staging und dokumentiere sie. Ich aktiviere NTS, wo es passt, und prüfe Hardware‑Timestamping auf geeigneter Netzwerkkarte. Anschließend binde ich Metriken in Alarme ein und setze Offsetschwellen. Zum Abschluss plane ich regelmäßige Überprüfungen, damit Zeitfehler gar nicht erst groß werden.

Runbook: 10‑Minuten‑Healthcheck

Wenn etwas „komisch“ wirkt, gehe ich so vor:

Systemstatus: timedatectl (NTP aktiv? RTC in UTC?)
Quellen: chronyc sources -v (Reach, Stratum, Jitter)
Tracking: chronyc tracking (Offset, Skew, Root dispersion)
Netz: Firewalls/ACLs für UDP/123 prüfen, Latenz/Verlust messen
Drift: chronyc sourcestats über mehrere Minuten beobachten
RTC: chronyc rtcdata, ggf. rtcsync aktivieren
Sicherheit: NTS-Status prüfen, keine stille Degradierung

Kosten und Nutzen in Euro gedacht

Eine falsche Uhr kostet schnell Zeit und Geld: Fehlgeschlagene Deployments, Supportfälle und SLA‑Abzüge summieren sich. Die Einrichtung eines internen Chrony-Servers und Monitoring ist günstig, oft bleibt der Aufwand im dreistelligen Euro‑Bereich. Demgegenüber stehen vermiedene Ausfälle, die leicht vier- bis fünfstellige Beträge in Euro gefährden. Besonders in Clustern mit vielen Transaktionen zahlt sich die Synchronisation Tag für Tag aus. Ich sehe NTP/NTS und Chrony daher als Pflicht statt Kür.

Zusammenfassung

Time-Drift bremst Server aus, verwirrt Logs und bringt Zertifikate aus dem Takt. Mit Chrony, NTP und einem internen Stratum‑Design halte ich Uhren synchron und Dienste verlässlich. NTS schützt die Quelle, Hardware‑Timestamping glättet Latenz, und korrektes Leap‑Second‑Handling verhindert Sprünge. Monitoring mit Metriken und Alarmen zeigt Abweichungen, bevor Nutzer sie spüren. Wer NTP Chrony Hosting sauber aufsetzt, erhält konsistente Zeitfenster, weniger Störungen und messbaren Nutzen in Euro.