Zeitsynchronisation

Warum es notwendig ist

Eine einzige und genaue Zeit ist die Grundlage für die Reihenfolge der Ereignisse, die korrekte Korrelation von Protokollen/Traces, die Signatur von Transaktionen und die Reproduzierbarkeit der Berichterstattung. Für Cashflow-Plattformen sei es eine Frage der Compliance und des Vertrauens: „wer war zuerst dran“, „wann das Ergebnis feststand“, „welcher Seed verwendet wurde“.

Grundlegende Konzepte

UTC vs TAI: UTC enthält Einfügungen von Schaltsekunden; TAI - ohne sie. Die meisten Systeme arbeiten in UTC.
Leap second: Sekundenlang einfügen/löschen. Unterstützung/Abschwächung (Smear) ist entscheidend für einen nahtlosen Betrieb.
Stratum (NTP): Entfernungsstufe von der Referenz (0 - Atom/GNSS, 1 - Server, 2 + - Clients).
PTP роли: Grandmaster (GM) → Boundary Clock (BC) / Transparent Clock (TC) → Slave.
PPS: Impuls-pro-Sekunde für präzise Referenzierung vom GNSS/Generator.
Servo: Algorithmus, der die Frequenz/Phase der lokalen Uhr korrigiert (chrony/ptp4l/phc2sys).

Wenn NTP, wenn PTP

NTP (Chrony): Millisekunden/Hundertstel Millisekunden Genauigkeit; WAN/Internet; einfach und zuverlässig.
PTP (IEEE 1588): Sub-Millisekunden und bis zu Mikrosekunden mit Hardwaremarke; erfordert Netzwerkdisziplin (L2/Multicast/QoS).
Hybrid: NTP/Chrony liefert Benchmark für PTP-GM; weiter im Rechenzentrum - PTP mit HW-timestamp.

Zeitquellen und Nachhaltigkeit

GNSS (GPS/GLONASS/Galileo/BeiDou) + PPS als primäre Referenz.
OCXO/TCXO (Generatoren) für Holdover bei Satellitenverlust.
Redundante Referenzen: zwei unabhängige GNSS-Empfänger, verschiedene Antennen/Kabel, Jamming-Barrieren.
Sekundäre NTP-Pools: externe zuverlässige Anbieter und private Server (über VPN).
Grandmaster x2 mit BMC (Best Master Clock) und manuellem Failover-Plan.

PTP-Netzwerkarchitektur

Profile: Default, Telecom (G.8275. x), Power. Bei Rechenzentren sind Default oder die Profile des Anbieters häufiger.
Transparente Uhr (TC): Der Schalter fügt eine Verzögerung (Korrekturfeld) hinzu - verbessert die Genauigkeit.
Boundary Clock (BC): Switch/Router - Client zum höheren und Master zum unteren Segment.
QoS: Priorisierung von PTP-Multicast/Unicast, Minimierung von Warteschlangen.
Isolation: dedizierte VLANs/VRFs für die Zeit; Keine L3-NAT auf dem PTP-Pfad.

Sicherheit: NTS für NTP, PTP-Schutz

NTP: Verwenden Sie NTS (Network Time Security, RFC 8915) - TLS-Authentifizierung für Zeitserver. Symmetrische Schlüssel (classic auth) sind innerhalb des Umfangs zulässig. Autokey ist veraltet.
PTP: native IAS/Authentifizierung wird kaum genutzt; Kompensieren Sie Netzwerkisolierung, ACL, MACsec/IPsec auf L2/L3.
GNSS: Schutz vor Jamming/Spoofing - Signalqualitätsmonitor, DOP-Überwachung, Geo-Filter, Anomaliedetektion.

Schaltsekundenverarbeitung und „Schmierung“

Leap-announce: NTP/Chrony meldet bevorstehende Sekundeneinfügung.
Smear: Dehnung des Tages auf ± 0. 5c (oder ein anderes Fenster), Vermeidung der Stufe. Ein Google-ähnlicher Smear ist praktisch, um einen „Sprung“ zu vermeiden, aber alle Dienste müssen einer einzigen Richtlinie folgen (oder Konturen isolieren).

SLO für Zeit (Beispiele)

Offset p95 Client ↔ Benchmark ≤ 1. 0 ms (NTP-Schleife des Rechenzentrums), p99 ≤ 5 ms.
PTP mit HW-Timestamp: Offset p95 ≤ 20 μ s, p99 ≤ 100 μ s innerhalb der Domain.
Jitter (stddev) ≤ 0. 2 ms (NTP) / ≤ 5 μs (PTP-HW).
Zeitschritt der Ereignisse = 0; nur slew (glatte Korrektur) in der Prod-Klasse.
Drift bei Holdover OCXO: ≤ 1 ppm (Kontrolle und Alertim).

Ingenieurpraktiken (NTP/Chrony)

Warum Chrony: passt besser zu einem „lauten“ Netzwerk, resistent gegen Paketverlust/Asymmetrie, flexibles NTS.

Minimal 'chrony. conf'(Server):

conf
Sources (top-level servers)
server ntp1. example iburst nts server ntp2. example iburst nts
Local GNSS with PPS (if any)
refclock SHM 0 poll 4 refid GNSS refclock PPS /dev/pps0 poll 4 refid PPS lock GNSS
Access restrictions allow 10. 0. 0. 0/8 deny all
makestep adjustment policy 0. 1 3 rtcsync log tracking measurements statistics

Prüfung und Überwachung:

bash chronyc tracking chronyc sources -v chronyc sourcestats -v

Clients: Geben Sie mindestens zwei Server an; Aktivieren Sie „makestep“ für einen frühen Start und „maxslewrate“ bei Bedarf.

Ingenieurpraktiken (PTP/linuxptp)

Hardware-Zeitstempel (HW-TS): erfordert NIC/Treiber mit PHC (PHC = PTP Hardware Clock).

Überprüfung:

bash ethtool -T eth0      grep timestamp phc2sys -l

ptp4l (slave/GM/BC) ist ein Beispiel für config:

conf
[global]
twoStepFlag      1 time_stamping     hardware tx_timestamp_timeout 30 logging_level     6 clock_class      248 clock_accuracy    0x20 priority1       128 priority2       128 delay_mechanism    E2E network_transport   L2 dsptp_domain     0

[eth0]
delay_filter     moving_average delay_filter_length  10 announceReceiptTimeout 3 syncReceiptTimeout   3

PHC → Systemuhr:

bash
PHC NIC -> system clock (slew)
phc2sys -s /dev/ptp0 -c CLOCK_REALTIME -O 0 -E ntpshm -w

Für Boundary/Transparent Clocks: Verwenden Sie Firmware/Images von BC/TC-fähigen Switches und aktivieren Sie deren Profile; Steuern Sie das Korrekturfeld in pmc:

bash pmc -u -b 0 "GET TIME_STATUS_NP"

Kubernetes, Virtualisierung und Container

Nodes werden K8s wie normale Hosts synchronisiert. Container nutzen die Host-Zeit.
Für PTP: PTP Operator/DaemonSet (z.B. 'linuxptp-daemonset') auf dedizierten Knoten mit HW-TS; 'NodeFeatureDiscovery' zur Kennzeichnung von NICs mit PHCs.
Zeitempfindliche Workload-Isolation (RNG/Gaming-Events): Taints/Tolerations → Nodes mit besserer Synchronisation.
Deaktivieren Sie in der Virtualisierung aggressive „virtuelle“ Hypervisor-Drift-Korrektoren, verwenden Sie eine Zeitdisziplin (entweder NTP/PTP-Gast oder Hypervisor).

Netzwerk und QoS

Trennen Sie Time-VLAN/VRF, halten Sie Latenz und Jitter minimal.
Für PTP E2E - Vermeiden Sie Asymmetrien der Wege; für P2P - Verwenden Sie Link-Local Delay.
Schalten Sie den MTU-Jumbo nur dann Ende-zu-Ende ein, wenn Sie sich überall einig sind; ansonsten eine Standard-MTU, aber eine stabile Warteschlange.
Leiten Sie NTP über UDP/123, erlauben Sie NTS-TLS-Ports; für PTP - korrekte ACLs für Multicast (224. 0. 1. 129/130).

Überwachung und Warnungen

Was zu messen:

Offset (aktuelle Diskrepanz), jitter, frequency drift, Korrekturen/sec.
Для PTP: `offsetFromMaster`, `meanPathDelay`, `grandmasterIdentity`, `stepsRemoved`.
Für GNSS: SNR, DOP, sichtbare Satelliten, PPS-Jitter.

Werkzeuge:

'chrony' Export nach Prometheus (Chrony-Exporteur), Textprotokolle → Loki.
'linuxptp' Statistik ('ptp4l -m'), Metriken über Node-Exporteur textfile.
Netzwerkzähler: drops/retransmit/queue-len auf time-VLAN.

Alerts (Ideen):

NTP Offset p95> 1 ms für 5 min.
PTP offsetFromMaster > 25 μs (p95) 5 мин.
GNSS/PPS Verlust> 1 min (Umschaltung auf Holdover).
Grandmaster-Wechsel (BMC) außerhalb des geplanten Fensters.
Der Unterschied zwischen RTC ↔ Systemuhr> Schwelle beim Booten.

Vorgänge und Aktualisierungen

Start/Stopp: Stellen Sie zuerst das Netzwerk/GNSS/PPS → GM → BC/TC → Clients wieder her.
Leap-second: Kündigen Sie im Voraus an, überprüfen Sie die Smear-Richtlinie und die Kompatibilität.
Updates: Firmware NIC/Switches, 'linuxptp/chrony' - staged mit Offset-Steuerung.
Runbooks: GNSS-Verlust, GM-Ersatz, PTP-Domain-Umzug, Cluster-Nicht-Synchronisation, VLAN-Abstürze.

Checkliste für die Implementierung

SLOs nach Zeit (Offset/Jitter) für Dienste und Protokolle definiert.
Zwei unabhängige Zeitquellen (GNSS + NTP), zwei GMs, Navy/manueller Failover-Plan.
Dediziertes Zeit-VLAN/VRF, QoS, ACL/MACsec; BC/TC PTPs sind aktiviert.
Überall eine einheitliche Leap-Politik (smear/step verboten in der Produktion).
Chrony с NTS; ptp4l/phc2sys - auf Knoten mit PHC, Serv-Einstellungen.
Überwachung von Offset/Jitter/GM/GNSS-Verlusten, Alerts und Dashboards.
Runbooks: loss of GNSS, GM failover, leap-second, drift-hunt.
Dokumentation für das Audit: Quellen, Configs, SLO Reports, GM Shift Log.

Typische Fehler

Ein nicht redundanter Zeitserver; Mischen von öffentlichen und privaten Pools ohne Kontrolle.
PTP durch „laute“ L3-Routen/Asymmetrie, ohne BC/TC.
Keine NTS/Isolierung - Möglichkeit, NTP/PTP-Spoofing zu ersetzen.
Verschiedene Leap-Richtlinien in Subsystemen → einen „Riss“ in der Zeit zwischen den Diensten.
Ignorieren der Drift/Holdover-Überwachung, plötzliche Schrittkorrekturen.
Virtuelle Maschinen mit doppelter Disziplin (Host + Gast) → Diskrepanzen.

Spezifität für iGaming/Fintech

Rechtlich relevante Zeitstempel: Speichern Sie Offset- und Synchronisationsstatus in Transaktions-/Eventprotokollen (zum Nachweis der Gültigkeit).
Reihenfolge der Ereignisse: Der Cross-Service-Korrelator verwendet monotone logische Uhren + UTC-Tags, nicht nur „Wände“.
Turniere/Matches: Start/Stop über Single-Source-of-Time (PTP-Domain/NTP-Server), TTL-Cache an den Fronten, Offset-Check vor dem „Pfeifen“.
RNG/Seed-Initialisierung: Initialisieren Sie von Kryptoquellen und verwenden Sie die Zeit nur als Komponente, indem Sie das Offset innerhalb des SLO überprüfen.
Reporting/Regulatoren: Periodische SLO-Zeitberichte und GM/Source Shift Log.

Mini-Playbooks

1) Schnelles Zeitaudit im Cluster

1. 'chronyc tracking' auf jedem Knoten → sammeln offset/jitter.
2. 'ptp4l -m '/' pmc' auf PTP-Knoten → GM, delay, stepsRemoved überprüfen.
3. Überprüfen Sie die Leap-Politik, stellen Sie die Einheitlichkeit sicher.

2) Verlust von GNSS

1. Gehen Sie zu holdover (OCXO), alert.
2. Verbinden Sie ein externes NTP über VPN als temporäre Referenz.
3. Überprüfen Sie die Antenne/Kabel/Empfänger; Ersatzplan.

3) Grandmaster-Wechsel

1. BMC-Prüfung der Priorität; manuelle Erhöhung des zweiten GM.
2. Offset-Kontrolle bei VS/Kunden; falls erforderlich, starten Sie phc2sys neu.
3. Bericht über einen Zwischenfall mit Zeitreihen-Offset.

Ergebnis

Eine robuste Zeitschleife ist eine stabile Referenz (GNSS + PPS + OCXO), eine korrekte PTP-Netzwerkarchitektur (BC/TC/QoS/Isolation), sicheres NTP mit NTS, eine konsistente Leap-Richtlinie, die Disziplin der Slew-Korrekturen und die SLO-Beobachtbarkeit (Offset/jitter/holdover). Notieren Sie alles in Runbooks, überprüfen Sie regelmäßig Offsets und lernen Sie aus Übungen - und Ihre Zeit bleibt auch dann genau, wenn alles andere „zittert“.