Sincronizzazione dell'ora

Perché è necessario

Un unico e preciso momento è la base per l'organizzazione degli eventi, la corretta correlazione tra logi/trailer, la firma delle transazioni e la riproduzione dei report. Per le piattaforme con flussi di cassa, è una questione di compliance e fiducia: «chi è stato il primo», «quando è stato rilevato il risultato», «quale seed viene utilizzato».

Concetti di base

UTC vs TAI: UTC contiene inserti di secondi bisestili TAI, senza di loro. La maggior parte dei sistemi funziona in UTC.
Leap second. incolla/elimina secondi. Il supporto/attenuazione (smear) è critico per il funzionamento silenzioso.
Stratum (NTP) - Livello di distanza dal riferimento (0 - atomo/GNSS, 1 - server, 2 + - client).
PTP роли: Grandmaster (GM) → Boundary Clock (BC) / Transparent Clock (TC) → Slave.
PPS: impulso-in-secondo per un preciso riferimento da GNSS/generatore.
Servo è un algoritmo che regola la frequenza/fase dell'orologio locale (chrony/ptp4l/phc2sys).

Quando NTP, quando PTP

NTP (Chrony) - Precisione millisecondi/centesimi millisecondi WAN/Internet; Semplice e affidabile.
PTP (IEEE 1588): secondario-millisecondo e fino a microsecondi hardware richiede una disciplina di rete (L2/multicast/QoS).
Ibrido: NTP/Chrony fornisce un riferimento a PTP-GM; più avanti nel centro dati - PTP con HW-timestamp.

Fonti temporali e sostenibilità

GNSS (GPS/GLONASS/Galileo/BeiDou) + PPS come riferimento primario.
OXO/TCXO (generatori) per holdover in caso di perdita di satelliti.
I comandi di riserva sono due ricevitori GNSS indipendenti, antenne/cavi diversi, blocchi da jamming.
Pool NTP secondari: provider esterni affidabili e server privati (VPN).
Grandmaster x2 con BMC (Best Master Clock) e piano failover manuale.

Architettura di rete PTP

Profili: Default, Telecom (G.8275. x), Power. Per un centro dati, Default o profili di venditore sono più frequenti.
Clarent Clock (TC) - Lo switch aggiunge latenza (correction field) - Migliora la precisione.
Boundary Clock (BC) - Switch/router client per superiore e procedura guidata per il segmento inferiore.
QoS - Priorità del multicast PTP/Unicast, minimizzazione delle code.
Isolamento: VLAN/VRF selezionati per il tempo; nessun L3-NAT sul percorso PTP.

Protezione NTS per NTP, protezione PTP

NTP: utilizzare NTS (Network Time Security, RFC 8915) - Autenticazione TLS dei server temporali. Le chiavi simmetriche (classic auth) sono valide all'interno del perimetro. Autokey è obsoleto.
PTP: MAS nativo/autenticazione è a malapena utilizzato; compensare con isolamento di rete, ACL, MACsec/IPsec su L2/L3.
GNSS - Protezione da jamming/spoofing - monitor della qualità dei segnali, osservazione DOP, filtri geo, rilevamento delle anomalie.

Lavorazione del secondo bisestile e lubrificazione

Leap-announce: NTP/Chrony riporta l'inserimento successivo di un secondo.
Stretching di 24 ore su 24. 5 c (o un'altra finestra), evitando il gradino. Google-simile smear è utile per evitare il «salto», ma tutti i servizi devono seguire un'unica regola (o isolare i tracciati).

SLO per il tempo (esempi)

Offset p95 client di riferimento 1. 0 ms (tracciato NTP del centro dati), p99 ≤ 5 ms.
PTP con HW-timestamp: offset p95 20 s, p99 100 © s all'interno del dominio.
Jitter (stddev) ≤ 0. 2 ms (NTP) / ≤ 5 μs (PTP-HW).
Clock step eventi = 0; Solo slew (correzione fluida) nella classe prod.
Drift a holdover OCXO: ≤ 1 ppm (controlliamo e alertim).

Tecniche di ingegneria (NTP/Chrony)

Perché Chrony: è più adatto a una rete «rumorosa», resistente a packet loss/asimmetrie, NTS flessibile.

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

Client: specificare almeno due server; attivare «makestep» per la partenza precoce e «maxslewrate» per necessità.

Tecniche di progettazione (PTP/linuxptp)

Timeout hardware (HW-TS): sono necessari NIC/driver PHC (PHC = PTP Hardware Clock).

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"

Kubernets, virtualizzazione e contenitori

I nodi K8s vengono sincronizzati come host comuni. I contenitori usano l'ora dell'host.
Per PTP: PTP Operator/DaemonSet (ad esempio «linuxptp-daemonset») su nodi selezionati con HW-TS; «NodeFeatureDiscovery» per etichettare NIC con PHC.
Isolamento del carico di lavoro con la sensibilità al tempo (RNG/Games Events): taints/tolerations con sincronizzazione migliore.
Nella virtualizzazione, disattivare i regolatori di ipervisor «virtuali» aggressivi, utilizzare una sola disciplina temporale (guest NTP/PTP o ipervisor).

Rete e QoS

Separare time-VLAN/VRF, mantenere i ritardi e jitter minimi.
Per PTP E2E - evitare le asimmetrie dei percorsi; per P2P - Utilizzare la latenza link-locale.
Accendere jumbo MTU end-to-end solo se è concordato ovunque; altrimenti, MTU standard, ma fila stabile.
Instradare NTP su UDP/123, consentire porte NTS-TLS; per PTP - ACL corrette per il multicast (224. 0. 1. 129/130).

Monitoraggio e alert

• Offset (soluzione temporanea corrente), jitter, frequency drivt, correzioni/secondi.
• Для PTP: `offsetFromMaster`, `meanPathDelay`, `grandmasterIdentity`, `stepsRemoved`.
• Per GNSS: SNR, DOP, satelliti visibili, PPS jitter.

• «crony» esporta in Prometheus (chrony-exporter), fogli di testo di Loki.
• «linuxptp» statistiche («ptp4l -m»), metriche tramite node-exporter textfile.
• Contatori di rete: drops/retransmit/queue-len sul time-VLAN.

• NTP offset p95> 1 ms per 5 minuti
• PTP offsetFromMaster > 25 μs (p95) 5 мин.
• Perdita GNSS/PPS> 1 min (transizione a holdover).
• Cambia grandmaster (BMC) fuori dalla finestra pianificata.
• Differenza tra RTC e system clock> soglia di caricamento.

Operazioni e aggiornamenti

Start/slart: ripristina prima la rete/GNSS/PPS di GM BC/TC per i clienti.
Leap-seconds - Annuncia in anticipo, controlla il criterio smear e la compatibilità.
Aggiornamenti firmware NIC/switch, 'linuxptp/crony' - staged con controllo offset.
Runbooks: perdita di GNSS, sostituzione di GM, traslazione del dominio PTP, disincronizzazione del cluster, incidenti VLAN.

Assegno foglio di implementazione

• Definiti SLO in ordine di tempo (offset/jitter) per servizi e registri.
• Due sorgenti di tempo indipendenti (GNSS + NTP), due GM, la Marina/il piano manuale del feelover.
• Selezione time-VLAN/VRF, QoS, ACL/MACsec; PTP BC/TC abilitati.
• Un unico criterio leap è ovunque (smear/step non consentito in vendita).
• Chrony с NTS; ptp4l/phc2sys - su nodi con PHC, impostazioni di zolfo.
• Monitoraggio offset/jitter/GM/perdite GNSS, alert e dashboard.
• Runbooks: loss of GNSS, GM failover, leap-second, drift-hunt.
• Documentazione di verifica: sorgenti, configi, report SLO, registro dei turni GM.

Errori tipici

Un solo server temporale senza ridondanza un mix di pool pubblici e privati senza controllo.
PTP attraverso percorsi L3/asimmetria «rumorosi», senza BC/TC.
Nessun NTS/Isolante - Possibilità di sostituire NTP/Spoofing PTP.
Diversi criteri leap nei sottosistemi → una faglia temporale tra i servizi.
Ignora il monitoraggio draft/holdover, correzioni di passo improvvise.
Le macchine virtuali a doppia disciplina (host + guest) non sono più compatibili.

Specifico per iGaming/Fintech

Etichette temporali giuridicamente significative: memorizzare gli stati di avanzamento e di sincronizzazione nei loghi transazioni/ivent (per dimostrare la validità).
Ordine eventi: il correlatore cross-servizio utilizza un orologio logico monotono + etichette UTC, non solo pareti.
Tornei/partite: fissa start/stop tramite singolo source of time (dominio PTP/server NTP), cache TTL sui fronti, verifica offset prima del fischietto.
Inizializzazione RNG/seed - Inizializzare da crittografie e utilizzare il tempo solo come componente per verificare offset all'interno di SLO.
Report/regolatori: resoconti periodici SLO del tempo e registro dei turni GM/sorgenti.

Mini playbook

1) Controllo rapido del tempo in un cluster

1. 'chronyc tracking', su ogni nodo è possibile assemblare offset/jitter.
2. «ptp4l - m »/« pmc» sui nodi PTP per controllare GM, delay, .
3. Incrocia i criteri leap, controlla l'uniformità.

2) Perdita GNSS

1. Vai a holdover (OCXO), alert.
2. Connetti l'NTP esterno over VPN come comando temporaneo.
3. Controllare l'antenna/cavo/ricevitore; piano di sostituzione.

3) Cambio Grandmaster

1. Verifica della priorità BMC; aumento manuale della seconda GM.
2. Controllo offset presso i clienti e le aziende se necessario, il riavvio di phc2sys.
3. Rapporto dell'incidente con le serie temporanee offset.

Totale

Un tracciato affidabile del tempo è un riferimento sostenibile (GNSS + PPS + OCXO), un'architettura di rete PTP (BC/TC/QoS/Isolamento), un NTP sicuro con NTS, una politica leap coerente, una disciplina slew-correzione, e l'osservabilità SLO (NTS) offset/jitter/holdover). Fissate tutto in runbook, controllate regolarmente gli offset e imparate ad esercitare - e il vostro tempo rimarrà preciso anche quando tutto il resto tremerà.