Sincronización de tiempo

¿por

Tiempo único y preciso: base para la organización de eventos, corrección correcta de logs/trays, firma de transacciones y reproducibilidad de informes. Para las plataformas con flujos de caja es una cuestión de cumplimiento y confianza: «quién fue el primero», «cuando se registró el resultado», «qué semilla se utilizó».

Conceptos básicos

UTC vs TAI: UTC contiene inserciones de segundos bisiestos; TAI - sin ellos. La mayor parte de los sistemas funcionan en UTC.
Leap second: inserción/eliminación de segundos. El soporte/la mitigación (smear) son críticos para el funcionamiento sin problemas.
Stratum (NTP): nivel de distancia de referencia (0 - átomo/GNSS, 1 - servidores, 2 + - clientes).
PTP роли: Grandmaster (GM) → Boundary Clock (BC) / Transparent Clock (TC) → Slave.
PPS: pulso en segundo para una referencia precisa de GNSS/generador.
Servo: algoritmo que corrige la frecuencia/fase del reloj local (chrony/ptp4l/phc2sys).

Cuando NTP, Cuando PTP

NTP (Chrony): precisión milisegundos/centésimas milisegundos; WAN/Internet; simple y confiable.
PTP (IEEE 1588): sub-milisegundos y hasta microsegundos con marca de hardware; requiere disciplina de red (L2/multicast/QoS).
Híbrido: NTP/Chrony suministra una referencia a PTP-GM; más en el centro de datos - PTP con HW-timestamp.

Fuentes de tiempo y sostenibilidad

GNSS (GPS/GLONASS/Galileo/BeiDou) + PPS como referencia primaria.
OCXO/TCXO (generadores) para holdover en la pérdida de satélites.
Referencias de respaldo: dos receptores GNSS independientes, diferentes antenas/cables, protectores de emisión.
Grupos NTP secundarios: proveedores de confianza externos y servidores privados (VPN).
Grandmaster x2 con BMC (Best Master Clock) y plan manual failover.

🚨 Check Alignment of PTs> Arquitectura de red PTP

Perfiles: Default, Telecom (G.8275. x), Power. Para el centro de datos, es más probable que Default o los perfiles de vendedores.
Clock transparente (TC): el conmutador agrega latencia (campo de corrección) - mejora la precisión.
Boundary Clock (BC): switch/router - cliente a la parte superior y asistente al segmento inferior.
QoS: priorizar el multicast/unicast PTP, minimizar las colas.
Aislamiento: VLAN/VRF dedicados para el tiempo; falta de L3-NAT en la ruta PTP.

Seguridad: NTS para NTP, protección PTP

NTP: use NTS (Red Time Security, RFC 8915) - Autenticación TLS de servidores de tiempo. Las claves simétricas (auth clásico) son válidas dentro del perímetro. Autokey es obsoleto.
PTP: los MAS/autenticación nativa apenas se utilizan; compensar con aislamiento de red, ACL, MACsec/IPsec por L2/L3.
GNSS: protección contra jamming/spoofing - monitor de calidad de señal, observación DOP, geo-filtros, detecto de anomalías.

Procesamiento del segundo bisiesto y «lubricación»

Leap-announce: NTP/Chrony informa sobre la próxima inserción de un segundo.
Smear: estiramiento del día en ± 0. 5 s (u otra ventana), evitando el paso. Un smear similar a Google es conveniente para rechazar el «salto», pero todos los servicios deben seguir una sola política (o aislar los contornos).

SLO para tiempo (ejemplos)

Offset p95 cliente ↔ referencia ≤ 1. 0 ms (contorno NTP de DATAa), p99 ≤ 5 ms.
PTP con HW-timestamp: offset p95 ≤ 20 μs, p99 ≤ 100 μs dentro del dominio.
Jitter (stddev) ≤ 0. 2 ms (NTP) / ≤ 5 μs (PTP-HW).
Clock step eventos = 0; sólo slew (corrección suave) en la clase prod.
Drift en holdover OCXO: ≤ 1 ppm (controlamos y alertim).

Prácticas de ingeniería (NTP/Chrony)

Por qué Chrony: converge mejor en una red «ruidosa», resistente al paquete loss/asimetría, NTS flexible.

Mínimo 'chrony. amb '(servidor):

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

Verificación y supervisión:

bash chronyc tracking chronyc sources -v chronyc sourcestats -v

Clientes: especifique un mínimo de dos servidores; habilita 'makestep' para un inicio temprano y 'maxslewrate' según sea necesario.

Prácticas de ingeniería (PTP/linuxptp)

Marca de tiempo de hardware (HW-TS): se requieren controladores NIC/con PHC (PHC = PTP Hardware Clock).

Validación:

bash ethtool -T eth0      grep timestamp phc2sys -l

ptp4l (slave/GM/BC) es un ejemplo de configuración:

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

Ligamento PHC → reloj del sistema:

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

Para clocks Boundary/Transparent: utilice firmware/imágenes de conmutadores compatibles con BC/TC e incluya sus perfiles; controle el campo de corrección en pmc:

bash pmc -u -b 0 "GET TIME_STATUS_NP"

Kubernetes, virtualización y contenedores

Los nodos K8s se sincronizan como hosts normales. Los contenedores utilizan el tiempo del host.
Para PTP: PTP Operator/DaemonSet (por ejemplo, 'linuxptp-daemonset') en nodos dedicados con HW-TS; 'NodeFeatureDiscovery' para marcar NIC con PHIC C..
Aislamiento de carga de trabajo con sensibilidad de tiempo (RNG/eventos de juego): taints/tolerations → nodos con una mejor sincronización.
En la virtualización, desactive los agresivos correctores de drift «virtuales» del hipervisor, use una disciplina de tiempo (ya sea un guest NTP/PTP o un hipervisor).

Red y QoS

Comparta el tiempo-VLAN/VRF, mantenga los retrasos y el jitter mínimos.
Para PTP E2E - evite las asimetrías de las vías; para P2P: utilice retardos link-local.
Active el jumbo MTU end-to-end sólo si está acordado en todas partes; de lo contrario es una MTU estándar, pero una cola estable.
Enrutar NTP por UDP/123, permitir puertos NTS-TLS; para PTP - ACL correctas para multicast (224. 0. 1. 129/130).

Monitoreo y alertas

Qué medir:

Offset (discrepancia actual), jitter, frequency drift, correcciones/sec.
Для PTP: `offsetFromMaster`, `meanPathDelay`, `grandmasterIdentity`, `stepsRemoved`.
Para GNSS: SNR, DOP, satélites visibles, PPS jitter.

Herramientas:

'chrony' exportación a Prometheus (chrony-exporter), registros de texto → Loki.
'linuxptp' estadística ('ptp4l -m'), métricas a través de node-exporter textfile.
Contadores de red: drops/retransmitir/queue-len en time-VLAN.

Alertas (ideas):

NTP offset p95> 1 ms durante 5 minutos.
PTP offsetFromMaster > 25 μs (p95) 5 мин.
Pérdida de GNSS/PPS> 1 min (cambiar a holdover).
Cambio de grandmaster (BMC) fuera de la ventana programada.
Diferencia de RTC ↔ clock del sistema> umbral durante el arranque.

Operaciones y actualizaciones

Inicio/interrupción: restaure primero la red/GNSS/PPS → GM → BC/TC → los clientes.
Leap-second: anuncie con antelación, compruebe la política de smear y la compatibilidad.
Actualizaciones: firmware NIC/switches, 'linuxptp/chrony' - staged con control offset.
Runbooks: pérdida de GNSS, reemplazo de GM, reubicación de dominio PTP, resincronización de clúster, accidente de VLAN.

Lista de comprobación de implementación

SLO definidos en tiempo (offset/jitter) para servicios y registros.
Dos fuentes de tiempo independientes (GNSS + NTP), dos GM, DIU/plan de failover manual.
Tiempo dedicado/VLAN/VRF, QoS, ACL/MACsec; Se incluyen PTP BC/TC.
En todas partes, una sola política de leap (smear/step prohibida en la venta).
Chrony с NTS; ptp4l/phc2sys - en nodos con PHC, ajustes de serv.
Monitoreo de pérdidas offset/jitter/GM/GNSS, alertas y dashboards.
Runbooks: loss of GNSS, GM failover, leap-second, drift-hunt.
Documentación para auditoría: fuentes, confecciones, informes de SLO, registro de turnos de GM.

Errores típicos

Un servidor de tiempo sin redundancia; mezcla de piscinas públicas y privadas sin control.
PTP a través de rutas L3/asimetría «ruidosas», sin BC/TC.
Sin NTS/aislamiento: posibilidad de reemplazar NTP/spuff PTP.
Las diferentes políticas de leap en los subsistemas → una «grieta» en el tiempo entre los servicios.
Ignora el monitoreo de drift/holdover, correcciones de pasos repentinos.
Máquinas virtuales de doble disciplina (host + guest) → discrepancias.

Características específicas para iGaming/Fintech

Marcas de tiempo legalmente significativas: guarde los offsets y los estados de sincronización en los logs de transacciones/eventos (para probar la validez).
Orden de eventos: el correlador de servicio cruzado utiliza relojes lógicos monótonos + etiquetas UTC, no solo «paredes».
Torneos/partidos: graba start/stop a través de un solo origen de tiempo (dominio PTP/servidor NTP), caché TTL en los frentes, validación offset antes del «silbato».
Inicialización RNG/seed: inicialice desde fuentes criptográficas y utilice el tiempo sólo como un componente, verificando offset dentro de SLO.
Informes/reguladores: informes periódicos de tiempo de SLO y registro de turnos/fuentes de GM.

Minibuses

1) Auditoría rápida de tiempo en el clúster

1. 'chronyc tracking' en cada nodo → montar offset/jitter.
2. 'ptp4l -m '/' pmc' en nodos PTP → comprobar GM, delay, stepsRemoved.
3. Verificar la política de leap, asegurarse de la uniformidad.

2) Pérdida de GNSS

1. Ir a holdover (OCXO), alerta.
2. Conectar una VPN NTP externa como referencia temporal.
3. Comprobar antena/cable/receptor; un plan de reemplazo.

3) Cambio de Grandmaster

1. Validación de prioridad BMC; elevación manual del segundo GM.
2. Control de offset en las Fuerzas Armadas/clientes; reiniciar phc2sys si es necesario.
3. Informe de incidentes con series temporales offset.

Resultado

Un circuito de tiempo confiable es una referencia sostenible (GNSS + PPS + OCXO), una arquitectura de red PTP correcta (BC/TC/QoS/aislamiento), NTP segura con NTS, una política de leap coherente, disciplina de correcciones slew, y observabilidad de SLO (offset/jitter/holdover). Fije todo en el runbook-ah, revise los offsets regularmente y aprenda de las enseñanzas - y su tiempo permanecerá exacto incluso cuando todo lo demás «tiembla».