Zeitsynchronisation und Drift

1) Warum Zeit eine architektonische Komponente ist

• Kerberos/OAuth/JWT brechen (Felder 'iat/nbf/exp');
• Verzerrung von Metriken/Traces und Alerts;
• Broker/Kunden fallen lassen (Timeouts, Retrays, exponentieller Backoff);
• Ordnung und Idempotenz in verteilten Szenarien zu stören.

• Offset - Die Differenz der lokalen Zeit von der Referenz.
• Skew - die Differenz der Offsets zwischen den Knoten.
• Drift (Drift) - Die Geschwindigkeit der Uhr (ppm), wenn keine Korrektur erfolgt.
• Jitter - Variabilität von Verzögerungen/Messungen.

2) Quellen und Zeitprotokolle

2. 1 NTP (Network Time Protocol)

Strats (Stratum 1 - direkt von GNSS/Radio, Stratum 2 - von Stratum 1, etc.).

• slew (glatte Frequenzanpassung, sicher für Anwendungen);
• step (Zeitsprung; unerwünscht bei Proda).
• Implementierungen: chrony, ntpd, systemd-timesyncd. Für Server - vorzugsweise chrony.

2. 2 NTS (NTP over TLS)

Authentifizierte Synchronisation (Schutz vor MITM und Zeitwechsel).
Empfohlen für externe Zeitserver.

2. 3 PTP / IEEE 1588

Hardware-Zeitstempel (Hardware Timestamping) in NIC/ToR, Milli- und Mikrosekundengenauigkeit.
Modi: boundary/transparente Uhr, Telekom/Enterprise-Profile.
Verwenden Sie für harte SLO auf p99-Ordnung, HFT/Telekom/Industrie.

2. 4 GNSS (GPS/GLONASS) und PPS

Lokale Empfänger geben PPS (pulse-per-second) die Referenz für Stratum 1.
Es ist wichtig, Spoofing/Jamming zu berücksichtigen - setzen Sie Antennen ein und überwachen Sie die Integrität.

2. 5 Wolken

Cloud-Quellen (interne Stratum-Pools) reduzieren Offset und Jitter innerhalb des VPC.
Für hybride Umgebungen - Kombinieren Sie lokale und Cloud-Bezüge.

3) Zeit in OS und Hardware

TSC/HPET/RTC: moderne CPUs halten TSC als schnellen monotonen Zähler; Frequenz sichern (invariant TSC).
Virtualisierung/Container: Driften und „Springen“ häufiger. Auf dem Hypervisor - strenger Zeitdienst; Zu Gast bei chrony.
Energieeinsparung kann die Monotonie der Timer stören - überprüfen Sie die BIOS/UEFI-Optionen.

4) Monotone und „Wand“ Uhren

Wall-Clock (Echtzeit, TZ/UTC) - für Logs, Event-Tags, Menschen.
Monotonische Uhr - zur Messung von Intervallen/Timeouts.

• Linux: `CLOCK_MONOTONIC`.
• C++: `std::chrono::steady_clock`.
• Go: eingebaute monotone Teile' Zeit. Zeit 'in Intervallen.
• Java: `System. nanoTime () 'für die Dauer, nicht für den Kalender.

Regel: Deadlines und Retrays - auf monotonen Stunden; Serialisierung/Protokollierung - auf UTC.

5) Leap second/“ leap smear“ und Kalenderfallen

Leap second kann „00:59:60“ oder eine Sekundenwiederholung → Loops in Timer/Metriken auslösen.

• Smear (glattes „Verschmieren“ von Sekunden in N Stunden).
• Schritt (unerwünscht).
• Verlassen Sie sich nie auf lokale TZ/Sommerzeit für Logik; UTC speichern, im TZ des Nutzers anzeigen.
• Aktualisieren Sie die TZDB (Zeitzonenbasis) - politische Veränderungen passieren.

6) Abstimmung der Reihenfolge ohne Vertrauen in die „Wand“

Lamport-Uhren und Vektor-Uhren - Ursache-Wirkungs-Beziehungen ohne physische Uhr.
Hybrid Logical Clocks (HLC) - kombinieren physische Zeit und Zähler, resistent gegen kleine Skew.
TrueTime-ähnliche Modelle - Geben das Intervall'[earliest, latest] 'zurück und erfordern commit-wait für die Serialisierung.

7) Auswirkungen der Zeit auf Protokolle und Systeme

Sicherheit: Kerberos erlaubt kleine Skew (in der Regel ± 5 Minuten), TLS/Zertifikate sind empfindlich gegenüber 'notBefore/notAfter', JWT gegenüber 'exp/nbf/iat'.
Makler/Warteschlangen: Aufgabenfrist/Sichtbarkeitszeitpunkt hängt vom richtigen Zeitpunkt ab.
DBMS/Cluster: Versionskonflikt durch 'updated _ at '/ts - HLC/Versionen eingeben, anstatt' rohe' Wall-Timestamps zu vergleichen.
Streaming: Unterscheiden Sie zwischen Ereigniszeit und Verarbeitungszeit; Wasserzeichen und Latenz anpassen.
Krohn/Planer: Drift führt zum „Kleben “/Doppelstart. Verwenden Sie monotone Intervalle und dedup Schlüssel.

8) Beobachtbarkeit und SLO der Zeit

8. 1 Metriken

`time. offset_ms' (Offset zum Bezug), 'time. jitter_ms`, `stratum`, `root_delay`, `root_dispersion`.
Для PTP: `path_delay`, `grandmaster_offset`, `gm_identity`, `clock_class`.
Alerts: Offset> Schwelle (z.B. 100-500 ms), Quellverlust, Step-Korrekturen.

8. 2 Diagnose

`chronyc tracking/sources/sourcestats`

`ntpq -p`, `ntpstat`

PTP: 'pmc', NIC/ToR Vendor Utilities.

8. 3 SLO/fehlerhaftes Budget

Beispiel SLO: "median offset ≤ 1 ms, p99 offset ≤ 25 ms, kein Schritt auf Prod-Knoten; PTP grandmaster failover ≤ 2 s».

9) Konfigurationspraktiken (Linux/containers/K8s)

9. 1 chrony (empfohlen)

pool time. example. org iburst maxsamples 9 nts makestep 0. 5 1 # one step at big error at start rtcsync # synchronize hardware clock leapsectz right/UTC # leap seconds from tzdata driftfile/var/lib/chrony/drift

• `maxsources`, `minsamples/maxsamples`, `maxslewrate`.
• Für isolierte DCs - lokale Referenz + GPS/PPS.

9. 2 Container und Baugruppen

Synchronisieren Sie auf dem Host; Container verwenden den Kernel.
Im K8s - DaemonSet mit Chronie oder Node-Level-Time-Agent; Verhindern Sie, dass Apps Zeit einbringen.

9. 3 PTP-Stack

NIC mit Hardware-Timestamping, PTP-Daemon, Boundary Clocks auf ToR.
PTP Domain Diversity (Profile), Schutz vor „schlechten“ Grandmaster.

10) Sicherheit der Zeit

NTS/authentifiziertes NTP, Filter und Rate-Limit (NTP-Verstärkung ist ein DDoS-Vektor).
PTP-Sicherheit: L2-Isolierung, ACL pro Multicast, GM-Spoofing-Überwachung.
GNSS: Antennen mit guter Übersicht, Spoofing/Jamming-Detektion, Fallback-Quellen.

11) Technische Muster und Code

11. 1 Deadlines/Timeouts

Speichern Sie die Deadlines als „monotones Start + Delta“ und nicht als absolutes Wall-Timestamp.
Fügen Sie dem Skew immer einen Vorrat hinzu (z. B. 2 × des erwarteten p99-Skew zum TTL-Token).

11. 2 Vergleich der Versionen

• Versionierung/ETag;
• HLC/seq;
• optimistische Blockaden.

11. 3 Protokolle und Traces

Immer UTC; schließen Sie das Feld 'time _ offset _ ms' des Knotens in die Agentenprotokolle ein.
Leime die Ereigniszeit in Trace-Ereignissen.

11. 4 Leap second-Verarbeitung

Wählen Sie die Richtlinie (smear/step) einheitlich für alle Knoten aus.
Testen: Die Metriken sollten nicht in einer zweiten Sekunde „brechen“.

12) Auswirkungen auf Domains

Auth: Token - berücksichtigen Sie „clock skew allowance“ (z.B. ± 2-5 Minuten).
Zahlungen/Zeitabschnitte: Runden Sie die Intervalle ab, nicht die absolute Zeit.
Makler: Die Zeitpläne der Retrays sind auf monotonen Stunden.
DB/TTL: TTL in Redis/DB - setzt auf lokale Uhr: Lager anlegen.
Analytik: Aggregationen nach Zeit - Verwenden Sie eine einzige UTC und ingestion Synchronisation.

13) Test-Playbooks (Spieltage)

Drift Injection: die Uhr künstlich auf +/ − Δ bringen; überprüfen Sie auth, Broker, SLO.
NTP-Outage: Deaktivieren Sie Quellen, verfolgen Sie Drift und Auto-Interconnect.
Leap second/smear: Simulierte Leap-Offensive, Bewertung von Charts/Timern.
PTP GM failover: Überprüfen Sie die Schaltzeit und Offset nach.
VM suspend/resume: Stellen Sie sicher, dass es keine „Sprünge“ und Schritte bei den Gästen gibt.

14) Anti-Muster

Vergleichen Sie die Ereignisse verschiedener Knoten nach Wall-Time ohne HLC/seq.
Setzen Sie „String-Locals“ der Zeit (mit TZ) in die DB anstelle von UTC.
Erlauben Sie Anwendungen, 'date -s '/' timedatectl set-time' zu machen.
Aktivieren Sie Step-Korrekturen auf dem Produkt ohne Planung.
Ignorieren Sie TZDB-Updates und Sommerzeitregeln.
Verwenden Sie wall-clock für backoff/timeouts/token-TTL ohne Lager auf skew.
Versuchen Sie, die Ordnung mit physischer Zeit statt mit logischer Uhr zu „heilen“.

15) Checkliste Umsetzung

• Einheitliche Politik: NTP (mit NTS) oder PTP; Liste der vertrauenswürdigen Quellen.
• Die Knoten sind auf slew, step nur beim Start eingestellt.
• Einheitliche Richtlinie leap second (smear/step) über alle Cluster hinweg.
• Überwachung von Offset, Jitter, Stratum/PTP Indikatoren; Alertas.
• Apps verwenden monotone Stunden für Intervalle/Deadlines.
• Für Ordnung/Konflikte - HLC/Versionen, nicht wall-timestamps.
• Bestände auf skew in TTL-Token, Zertifikate, Zeitpläne.
• K8s/VM: Synchronisation auf Hosts, Container ohne Rechte, die Zeit zu ändern.
• Dokumentation und Runbooks zu Zeitversagen, Spieltage im CI/CD-Kalender.
• Regelmäßige TZDB-Updates, Überprüfung des Verhaltens bei DST/Leap-Ereignissen.

16) FAQ

F: Wann wird PTP anstelle von NTP benötigt?
A: Wenn SLO Mikrosekunden-Dutzende von Mikrosekunden benötigt (Telekom/HFT/Industrie) und Hardware-Tags in Netzwerk/Karten unterstützt werden.

F: Wie viel auf der Uhr skew?
A: Für typische NTP in DC - Dutzende bis Hunderte von ms (p99); Legen Sie 2 × Lager. Mit PTP - Einheiten-Dutzende von µs.

F: Wie überlebt man Leap Second?
A: Verwenden Sie überall smear und die gleiche Politik; Diagramme/Aggregatoren und Timer testen.

F: Kann ich mich bei Terminen auf die Wanduhr verlassen?
A: Nein. Nur monotone Uhren + Lager auf skew.

F: Wie speichere ich „Zeit“ in der DB?
A: In UTC ('timestamptz'), plus Versionen/HLC für die Konfliktlösung; Speichern Sie keine lokalen Zonen in den Daten.

17) Ergebnisse

Zuverlässige Zeit ist Protokoll + Politik + Disziplin im Code. Synchronisieren Sie Knoten (NTP/NTS oder PTP), verwenden Sie die Monoton-Uhr für Intervalle, UTC für Daten, HLC/Versionen für Reihenfolge, legen Sie Inventar auf Skew, überwachen Sie das Offset und verbringen Sie regelmäßig Spieltage. So vermeiden Sie „mystische“ Authentifizierungsfehler, Diskrepanzen bei Ereignissen und instabile SLOs.