Synchronisation temporelle

Pourquoi est-ce nécessaire

L'heure unique et précise est la base de l'organisation des événements, de la corrélation correcte des logs/trajets, de la signature des transactions et de la reproductibilité des rapports. Pour les plates-formes à flux de trésorerie, c'est une question de complication et de confiance : « qui a été le premier », « quand le résultat a été enregistré », « quel seed utilisé ».

Notions de base

UTC vs TAI : UTC contient des inserts de secondes bissextiles ; TAI - sans eux. La plupart des systèmes fonctionnent en UTC.
Leap second : Insertion/suppression en secondes. Le support/assouplissement (smear) est essentiel pour un travail sans soudure.
Stratum (NTP) : niveau de distance par rapport à la référence (0 - atome/GNSS, 1 - serveurs, 2 + - clients).
PTP роли: Grandmaster (GM) → Boundary Clock (BC) / Transparent Clock (TC) → Slave.
PPS : impulsion-par-seconde pour une liaison précise du GNSS/générateur.
Servo : algorithme correcteur de fréquence/phase de l'horloge locale (chrony/ptp4l/phc2sys).

Quand NTP, quand PTP

NTP (Chrony) : précision milliseconde/centième milliseconde ; WAN/Internet ; simple et fiable.
PTP (IEEE 1588) : Sous-milliseconde et jusqu'à microsecondes avec une marque matérielle ; nécessite une discipline réseau (L2/multicast/QoS).
Hybride : NTP/Chrony fournit une référence à PTP-GM ; plus loin dans le centre de données - PTP avec HW-timestamp.

Sources de temps et résilience

GNSS (GPS/GLONASS/Galileo/BeiBou) + PPS comme référence primaire.
OCXO/TCXO (générateurs) pour holdover en cas de perte de satellites.
Références de secours : deux récepteurs GNSS indépendants, des antennes/câbles différents, des barrages de jamming.
Pools NTP secondaires : fournisseurs de confiance externes et serveurs privés (par VPN).
Grandmaster x2 avec BMC (Best Master Clock) et plan d'échec manuel.

Architecture réseau PTP

Profils : Par défaut, Telecom (G.8275. x), Power. Pour les centres de données, les profils par défaut ou par fournisseur sont plus fréquents.
Clock transparent (TC) : le commutateur ajoute du retard (champ de correction) - améliore la précision.
Boundary Clock (BC) : commutateur/routeur - client vers le haut et maître vers le segment inférieur.
QoS : hiérarchisation du multicast PTP/unicast, minimisation des files d'attente.
Isolation : VLAN/VRF dédié pour le temps ; Absence de L3-NAT sur le chemin PTP.

Sécurité : NTS pour NTP, protection PTP

NTP : utiliser NTS (Network Time Security, RFC 8915) - authentification TLS des serveurs temporels. Les clés symétriques (classic auth) sont valides à l'intérieur du périmètre. Autokey est obsolète.
PTP : le MAS/authentification natif est à peine utilisé ; Compenser par isolation réseau, ACL, MACsec/IPsec par L2/L3.
GNSS : protection contre le jamming/spoofing - moniteur de qualité de signal, observation DOP, filtres géo, détecteur d'anomalies.

Traitement des secondes bissextiles et « lubrification »

Leap-announce : NTP/Chrony annonce l'insertion prochaine d'une seconde.
Smear : étirement de la journée à ± 0. 5 s (ou une autre fenêtre) en évitant l'étape. Google-comme smear est pratique pour refuser le « saut », mais tous les services doivent suivre une politique unique (ou isoler les contours).

SLO pour le temps (exemples)

Offset p95 client ↔ référence ≤ 1. 0 ms (boucle NTP du centre de données), p99 ≤ 5 ms.
PTP avec HW-timestamp : offset p95 ≤ 20 μ s, p99 ≤ 100 μ s à l'intérieur du domaine.
Jitter (stddev) ≤ 0. 2 ms (NTP) / ≤ 5 μs (PTP-HW).
Clock step événements = 0 ; seulement slew (correction en douceur) en classe pro.
Drift avec holdover OCXO : ≤ 1 ppm (nous contrôlons et alertim).

Pratiques d'ingénierie (NTP/Chrony)

Pourquoi Chrony : meilleure convergence sur un réseau « bruyant », résistant à la loss/asymétrie packet, flexible NTS.

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

bash chronyc tracking chronyc sources -v chronyc sourcestats -v

Clients : spécifiez au moins deux serveurs ; inclure 'makestep' pour le démarrage précoce et 'maxslewrate' si nécessaire.

Pratiques d'ingénierie (PTP/linuxptp)

Horodatage matériel (HW-TS) : NIC/pilotes avec PHC (PHC = PTP Hardware Clock) sont requis.

bash ethtool -T eth0      grep timestamp phc2sys -l

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

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

bash pmc -u -b 0 "GET TIME_STATUS_NP"

Kubernetes, virtualisation et conteneurs

Les noeuds de K8s sont synchronisés en tant qu'hôtes ordinaires. Les conteneurs utilisent le temps hôte.
Pour PTP : PTP Operator/DaemonSet (par exemple « linuxptp-daemonset ») sur les noeuds sélectionnés avec HW-TS ; « NodeFeatureDiscovery » pour le marquage NIC avec PHC.
Isolation de la charge de travail avec sensibilité au temps (RNG/gaming ivens) : taints/tolerations → nodes avec meilleure synchronisation.
Dans la virtualisation, désactivez les correcteurs « virtuels » agressifs de l'hyperviseur, utilisez une seule discipline temporelle (guest NTP/PTP ou hyperviseur).

Réseau et QoS

Séparez le temps-VLAN/VRF, gardez les retards et le jitter minimum.
Pour PTP E2E - éviter les asymétries de chemin ; Pour P2P - utilisez les délais link-local.
Activer le jumbo MTU end-to-end seulement si convenu partout ; sinon - MTU standard, mais la file d'attente stable.
Acheminer NTP par UDP/123, autoriser les ports NTS-TLS ; Pour PTP - ACL correct pour multicast (224. 0. 1. 129/130).

Surveillance et alertes

• Offset (divergence actuelle), jitter, frequency drift, corrections/s.
• Для PTP: `offsetFromMaster`, `meanPathDelay`, `grandmasterIdentity`, `stepsRemoved`.
• Pour GNSS : SNR, DOP, satellites visibles, PPS jitter.

• 'Chrony 'exporte vers Prometheus (chrony-exportateur), logs de texte → Loki.
• 'linuxptp' statistiques ('ptp4l -m'), métriques via node-exportateur textfile.
• Compteurs réseau : drops/retransmit/queue-len sur le VLAN-temps.

• NTP offset p95> 1 ms pendant 5 min.
• PTP offsetFromMaster > 25 μs (p95) 5 мин.
• Perte GNSS/PPS> 1 min (passage à holdover).
• Changement de grandmaster (BMC) en dehors de la fenêtre de planification.
• Différence RTC ↔ système clock> seuil de chargement.

Opérations et mises à jour

Démarrez/arrêtez l'art : tout d'abord, restaurez le réseau/GNSS/PPS → GM → BC/TC → les clients.
Leap-second : déclarez à l'avance, vérifiez la politique smear et l'interopérabilité.
Mises à jour : firmware NIC/commutateurs, 'linuxptp/chrony' - staged avec contrôle offset.
Runbooks : perte GNSS, remplacement GM, relocalisation du domaine PTP, dissynchronisation du cluster, accidents VLAN.

Chèque d'implémentation

• Défini par SLO (offset/jitter) pour les services et les journaux.
• Deux sources de temps indépendantes (GNSS + NTP), deux GM, NAVY/plan de faussaire manuel.
• Time-VLAN/VRF, QoS, ACL/MACsec ; PTP BC/TC inclus.
• Partout, une seule politique de leap (smear/step interdit dans la vente).
• Chrony с NTS; ptp4l/phc2sys - sur les nodes avec PHC, les paramètres de gris.
• Surveillance offset/jitter/GM/pertes GNSS, alertes et dashboards.
• Runbooks: loss of GNSS, GM failover, leap-second, drift-hunt.
• Documentation d'audit : sources, configurations, rapports SLO, Journal des postes GM.

Erreurs typiques

Un serveur de temps sans réservation ; mélange de pools publics et privés sans contrôle.
PTP via des routes L3 « bruyantes »/asymétrie, sans BC/TC.
Aucun NTS/isolation - possibilité de remplacer NTP/spoofing PTP.
Différentes politiques leap dans les sous-systèmes → « fracture » dans le temps entre les services.
Ignorer la surveillance drift/holdover, corrections brusques pas à pas.
Machines virtuelles à double discipline (host + guest) → divergence.

Spécificité pour iGaming/fintech

Horodatages juridiquement significatifs : stockez les offsets et les statuts de synchronisation dans les logs de transaction/events (pour prouver la validité).
Ordre des événements : le corrélateur cross-service utilise une horloge logique monotone + étiquettes UTC, et pas seulement des « murs ».
Tournois/matchs : enregistrez start/stop via single source of time (domaine PTP/serveur NTP), cache TTL sur les fronts, vérifiez l'offset avant de « siffler ».
RNG/seed-initialisation : initialiser à partir de crypto-sources, et utiliser le temps uniquement comme composant en vérifiant l'offset dans le SLO.
Rapports/régulateurs : rapports périodiques de SLO du temps et journal GM/sources.

Mini-playbooks

1) Vérification rapide du temps dans le cluster

1. 'chronyc tracking' sur chaque nœud → assembler offset/jitter.
2. 'ptp4l -m '/' pmc' sur les noeuds PTP → vérifier GM, delay, stepsRemoved.
3. Vérifiez la stratégie leap, assurez-vous de l'uniformité.

2) Perte de GNSS

1. Aller à holdover (OCXO), alert.
2. Connectez un NTP externe sur VPN en tant que référence temporaire.
3. Vérifier l'antenne/câble/récepteur ; plan de remplacement.

3) Changement de Grandmaster

1. Vérification du BMC de priorité ; augmentation manuelle du deuxième GM.
2. Le contrôle de l'offset par l'aéronef/les clients ; si nécessaire, redémarrer phc2sys.
3. Rapport d'incident de séries chronologiques offset.

Total

La boucle de temps robuste est une référence stable (GNSS + PPS + OCXO), une architecture réseau PTP correcte (BC/TC/QoS/isolation), un NTP sécurisé avec NTS, une politique leap cohérente, une discipline slew et une observation SLO (offset/jitter/holdover). Enregistrez tout dans le runbook, vérifiez régulièrement les offsets et apprenez les enseignements - et votre temps restera précis même lorsque tout le reste « tremble ».