Synchronisation temporelle et dérive

1) Pourquoi le temps est un composant architectural

• Casser Kerberos/OAuth/JWT (champs 'iat/nbf/bou') ;
• déformer les métriques/tracés et les alertes ;
• faire tomber les courtiers/clients (timeouts, retraits, backoff exponentiel) ;
• perturber l'ordre et l'idempotence dans les scénarios distribués.

• Offset (décalage) est la différence de temps local par rapport à la référence.
• Skew est la différence entre les nœuds.
• Drift (dérive) est la vitesse de sortie de l'horloge (ppm) en l'absence de correction.
• Jitter - variabilité des retards/mesures.

2) Sources et protocoles temporels

2. 1 NTP (Network Time Protocol)

Stratum (Stratum 1 - directement de GNSS/radio, Stratum 2 - de Stratum 1, etc.).

• slew (sans heurts, sans danger pour les applications) ;
• step (saut de temps ; indésirable sur la vente).
• Implémentations : chrony, ntpd, systemd-timesyncd. Pour les serveurs - de préférence chrony.

2. 2 NTS (NTP over TLS)

Synchronisation authentifiée (protection MITM et échange de temps).
Recommandé pour les serveurs de temps externes.

2. 3 PTP / IEEE 1588

Horodatage matériel (hardware timestamping) en NIC/ToR, précision milliaire et microseconde.
Modes : clock boundary/transparent, profils telecom/enterprise.
Utiliser avec des SLO durs sur l'ordre p99, HFT/Telecom/Industrie.

2. 4 GNSS (GPS/GLONASS) et PPS

Les récepteurs locaux donnent la référence PPS (pulse-per-second) pour Stratum 1.
Il est important de prendre en compte le spoofing/brouillage - mettre des antennes et surveiller l'intégrité.

2. 5 Nuages

Les sources cloud (pools stratum internes) réduisent l'offset et le jitter à l'intérieur du VPC.
Pour les environnements hybrides - combinez des références locales et cloud.

3) Temps dans OS et fer

TSC/HPET/RTC : les CPU modernes tiennent le TSC comme un compteur monotone rapide ; fixez la fréquence (invariant TSC).
Virtualisation/conteneurs : dérive et « sauts » plus souvent. L'hyperviseur est un service de temps strict ; en visite - chronique.
L'économie d'énergie peut interférer avec la monotonie des minuteries - vérifiez l'option BIOS/UEFI.

4) Monotone et montre « murale »

Wall-clock (temps réel, TZ/UTC) - pour les logs, les étiquettes d'événements, les gens.
Monotonic clock - pour mesurer les intervalles/temps.

• Linux: `CLOCK_MONOTONIC`.
• C++: `std::chrono::steady_clock`.
• Go : pièces monotones intégrées 'time. Time 'dans les intervalles.
• Java: `System. nanoTime () 'pour les durées, pas pour le calendrier.

Règle : dédelines et retraits - sur monotones horloges ; sérialisation/loging - sur UTC.

5) Leap second/ » leap smear » et les pièges de calendrier

Leap second peut déclencher « 00:59:60 » ou répéter une seconde → boucles dans les minuteries/métriques.

• Smear (« broyage » en douceur en N heures).
• Étape (non désirée).
• Ne comptez jamais sur les TZ/heures d'été locales pour la logique ; Stockez UTC, montrez dans la TZ de l'utilisateur.
• Mettez à jour le TZDB (base de fuseaux horaires) - les changements politiques se produisent.

6) Harmonisation de l'ordre sans confiance dans le « mur »

Lamport clocks et Vector clocks sont des relations causales sans horloge physique.
Hybrid Logical Clocks (HLC) - combinent le temps physique et le compteur, résistant à un petit skew.
Modèles TrueTime - renvoient l'intervalle '[earliest, latest]' et nécessitent commit-wait pour la sérialisation.

7) Impact du temps sur les protocoles et les systèmes

Sécurité : Kerberos permet un petit skew (généralement ± 5 minutes), les certificats TLS/sont sensibles à 'notBefore/notAfter', JWT à 'bou/nbf/iat'.
Courtiers/files d'attente : les deadline des tâches/visibility timeout dépendent du bon moment.
Bases de données/clusters : conflit de versions selon 'updated _ at '/ts - entrez HLC/versions plutôt que de comparer les wall-timestamps « bruts ».
Streaming : distinguer le temps d'événement et le temps de traitement ; configurez watermarks et lateness.
Couronnes/planificateurs : la dérive mène à des « bouffées »/doubles lancements. Utilisez des intervalles monotones et des clés de déduplication.

8) Observabilité et SLO du temps

8. 1 Métriques

`time. offset_ms' (offset au référent), 'time. jitter_ms`, `stratum`, `root_delay`, `root_dispersion`.
Для PTP: `path_delay`, `grandmaster_offset`, `gm_identity`, `clock_class`.
Alert : offset> seuil (par exemple 100-500 ms), perte de source, correction step.

8. 2 Diagnostics

`chronyc tracking/sources/sourcestats`

`ntpq -p`, `ntpstat`

PTP : 'pmc', utilitaires vendeurs NIC/ToR.

8. 3 SLO/budget erroné

Exemple SLO : "median offset ≤ 1 ms, p99 offset ≤ 25 ms, no step sur les nœuds prod ; PTP grandmaster failover ≤ 2 s».

9) Pratiques de configuration (Linux/containers/K8s)

9. 1 chronique (recommandé)

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`.
• Pour les DC isolés, référence locale + GPS/PPS.

9. 2 Conteneurs et nœuds

Synchroniser sur l'hôte ; les conteneurs utilisent le noyau.
En K8s, DaemonSet avec chrony ou node-level time agent ; interdire l'apport de temps par les applications.

9. 3 piles PTP

NIC avec timestamping matériel, démon PTP, clocks boundaires sur ToR.
Diversité des domaines PTP (profils), protection contre les grandmaster « mauvais ».

10) Sécurité du temps

NTS/NTP authentifié, filtres et rate-limit (NTP-gain - vecteur DDoS).
Sécurité PTP : isolation L2, ACL sur multicast, surveillance GM spoofing.
GNSS : antennes avec un bon aperçu, detect spoofing/jamming, fallback-sources.

11) Modèles d'ingénierie et code

11. 1 Deadlines/Temporuts

Gardez les deadlines en tant que « départ monotone + delta » plutôt qu'en tant que wall-timestamp absolu.
Ajoutez toujours un stock sur skew (par exemple, 2 × du p99-skew attendu au token TTL).

11. 2 Comparaison des versions

• Versioning/ETag ;
• HLC/seq;
• des blocages optimistes.

11. 3 Logs et traçages

Toujours UTC ; incluez le champ 'time _ offset _ ms'du nœud dans les logs de l'agent.
Collez l'event-time dans les événements de trace.

11. 4 Traitement leap second

Sélectionnez la stratégie (smear/step) de manière uniforme pour tous les nœuds.
Testez : les métriques ne doivent pas « casser » une seconde de plus.

12) Impact sur les domaines

Auth : les jetons - prenez en considération "clock skew allowance" (par exemple, e2-5 des minutes).
Paiements/tranches de temps : arrondir les intervalles plutôt que le temps absolu.
Courtiers : les horaires des rétrogrades sont monotones.
OBD/TTL : TTL dans Redis/DB - s'appuie sur une horloge locale : placez votre stock.
Analyse : agrégations temporelles - utilisez un UTC unique et la synchronisation d'ingestion.

13) Test-playbooks (Game Days)

Drift injection : éloigner artificiellement l'horloge de +/ − Δ ; vérifier auth, courtiers, SLO.
NTP outage : désactiver les sources, suivre le drift et la connexion automatique.
Leap second/smear : simulation de l'offensive leap, estimation des graphiques/minuteries.
Failover PTP GM : vérifiez le temps de basculement et offset après.
VM suspend/resume : assurez-vous qu'il n'y a pas de « sauts » et step sur les invités.

14) Anti-modèles

Comparer les événements de différents nœuds par wall-time sans HLC/seq.
Mettre les « lignes locales » du temps (avec TZ) dans la base de données au lieu d'UTC.
Autoriser les applications à faire 'date -s '/' timedatectl set-time'.
Activer les corrections step sur la vente sans planification.
Ignorer les mises à jour TZDB et les règles de passage à l'heure d'été.
Utilisez wall-clock pour backoff/timeouts/token-TTL sans stock sur skew.
Essayer de « traiter l'ordre » avec le temps physique au lieu de l'horloge logique.

15) Chèque de mise en œuvre

• Politique unique : NTP (avec NTS) ou PTP ; liste des sources de confiance.
• Les nœuds sont configurés sur slew, step seulement au début.
• Une seule politique leap second (smear/step) pour tous les clusters.
• Suivi des indicateurs offset, jitter, stratum/PTP ; alerte.
• Les applications utilisent une horloge monotone pour les intervalles/deadlines.
• Pour ordre/conflits - HLC/version, pas wall-timestamps.
• Stocks sur skew en tokens TTL, certificats, horaires.
• K8s/VM : synchronisation sur les hôtes, conteneurs sans autorisation pour changer d'heure.
• Documentation et runbooks sur les pannes de temps, jours de jeu dans le calendrier CI/CD.
• Mises à jour régulières de TZDB, vérification du comportement dans les événements DST/leap.

16) FAQ

Q : Quand faut-il un PTP au lieu d'un NTP ?
R : Lorsque le SLO nécessite des microsecondes-dizaines de microsecondes (telecom/HFT/industrie) et qu'il existe une prise en charge des étiquettes matérielles sur le réseau/les cartes.

Q : Combien mettre sur le clock skew ?
A : Pour un NTP typique en DC - des dizaines à des centaines de ms (p99) ; placez 2 × de stock. Avec PTP - unités-dizaines de µs.

Q : Comment survivre au leap second ?
R : Utiliser smear et la même politique partout ; tester les graphiques/agrégateurs et les minuteurs.

Q : Peut-on compter sur le wall-clock pour les deadlines ?
R : Non. Seulement monotone + stock sur skew.

Q : Comment garder le « temps » dans une base de données ?
A : Dans UTC (« timestamptz »), plus les versions/HLC pour la résolution des conflits ; ne pas stocker les zones locales dans les données.

17) Résultats

Le temps fiable est un protocole + politique + discipline dans le code. Synchronisez les nœuds (NTP/NTS ou PTP), utilisez une horloge monotone pour les intervalles, UTC pour les données, HLC/version pour l'ordre, placez des stocks sur skew, surveillez l'offset et organisez régulièrement des journées de jeu. Vous éviterez ainsi les bogues d'authentification « mystiques », les divergences dans les événements et les SLO instables.