Sincronizar tempo

Para quê?

Uma única e exata hora é a base de organização de eventos, correlação correta de logs/trailers, assinatura de transações e reprodução de relatórios. Para plataformas de fluxo de dinheiro, é uma questão de complacência e confiança: «quem foi o primeiro», «quando o resultado foi registrado», «qual seed usado».

Conceitos básicos

UTC vs TAI: UTC contém inserções de segundos bissextos; TAI - sem eles. A maior parte dos sistemas funciona em UTC.
Leap segundo: inserção/remoção de segundos. Suporte/flexibilização (smear) são críticos para o trabalho sem fio.
Stratum (NTP): nível de distância da referência (0 - átomo/GNSS, 1 - servidores, 2 + - clientes).
PTP роли: Grandmaster (GM) → Boundary Clock (BC) / Transparent Clock (TC) → Slave.
PPS: impulso-em-segundo para uma ligação precisa de GNSS/gerador.
Servo: algoritmo que ajusta a frequência/fase do relógio local (crony/ptp4l/phc2sys).

Quando NTP, quando PTP

NTP (Crony): precisão de milissegundos/centésimos milissegundos; WAN/Internet; Simples e confiável.
PTP (IEEE 1588): sub-milissegundos e até microssegundos com marca de hardware; exige disciplina de rede (L2/multicast/QoS).
Híbrido: NTP/Crony fornece referência para PTP-GM; mais adiante no centro de dados - PTP com HW-timestamp.

Fontes de tempo e sustentabilidade

GNSS (GPS/GLONASS/Galileo/BeiDou) + PPS como referência primária.
OCXO/TCXO (geradores) para holdover em caso de perda de satélites.
Dois receptores GNSS independentes, antenas/cabos diferentes, bloqueadores de jamming.
Poulos NTP secundários: provedores de serviços de confiança externos e servidores privados (VPN).
Grandmaster x2 com BMC (Best Master Clock) e plano de failover manual.

Arquitetura de rede PTP

Perfis: Default, Telecom (G.8275. x), Power. Para um centro de dados, Default ou perfis de vendedor são mais frequentes.
Transparent Clock (TC): O switch adiciona atraso (correção field) - melhora a precisão.
Boundary Clock (BC): switch/roteador - cliente para superior e assistente para o segmento inferior.
QoS: Priorizar o multicaço PTP/unicast, minimizar as filas.
Isolamento: VLAN/DRF selecionados para o tempo; Falta de L3-NAT no caminho PTP.

Segurança: NTS para NTP, proteção PTP

NTP: use NTS (Rede Time Security, RFC 8915) - Autenticação TLS dos servidores de tempo. As chaves simétricas (classic auth) são válidas dentro do perímetro. O Autokey é obsoleto.
PTP: O MAS/autenticação nativa quase não é usado; compensa por isolamento de rede, LCA, MACsec/IPsec em L2/L3.
GNSS: Protecção contra jamming/spoofing - monitor de qualidade de sinal, observação de DOPS, geo-filtros, detecção de anomalias.

Processamento de segundo bissexto e lubrificação

Leap-announce: NTP/Crony informa sobre a próxima inserção de segundo.
Smear: alongamento de 24 horas por dia. 5 c (ou outra janela), evitando o estágio. O Google-semelhante smear é conveniente para deixar de «saltar», mas todos os serviços devem seguir uma única política (ou isolar os contornos).

SLO para o tempo (exemplos)

Offset p95 cliente ↔ referência ≤ 1. 0 ms (contorno NTP de centro), p99 ≤ 5 ms.
PTP com HW-timestamp: offset p95 ≤ 20 £ s, p99 ≤ 100 £ s dentro do domínio.
Jitter (stddev) ≤ 0. 2 ms (NTP) / ≤ 5 μs (PTP-HW).
Clock step eventos = 0; apenas o slew (correção suave) na classe prod.
Draft com holdover OCXO: ≤ 1 ppm (controlando e alertando).

Práticas de engenharia (NTP/Crony)

Por que o Chrony: É melhor em uma rede «barulhenta», resistente a packet loss/assimetria, NTS flexível.

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

Clientes: especifique pelo menos dois servidores; ativar 'makestep' para iniciar cedo e 'maxslewrate', conforme necessário.

Práticas de engenharia (PTP/linuxptp)

Marca de tempo de hardware (HW-TS): NIC/drivers com PHC (PHC = PTP Hardware Clock) são necessários.

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, virtualização e contêineres

Nodes K8s são sincronizados como hospedeiros normais. Os contentores usam a hora do hóspede.
Para PTP: PTP Operator/DaemonSet (por exemplo, 'linuxptp-daemonset') em nodes selecionados com HW-TS; 'NodeFeatureDiscovery' para marcação NIC com PHC.
Isolamento da carga de trabalho com sensibilidade ao tempo (RNG/Ivents de Jogo): taints/tolerações → nódulos com melhor sincronização.
Na virtualização, desabilite os controladores de hipervisor «virtual» agressivos, use uma disciplina de tempo (ou guest NTP/PTP ou hipervisor).

Rede e QoS

Divida o time-VLAN/VRF, mantenha os atrasos e jitter mínimos.
Para PTP E2E - evite as assimetrias dos caminhos; para P2P - Use o link local de atraso.
Ative o jumbo MTU end-to-end apenas se estiver alinhado; senão é um MTU padrão, mas uma fila estável.
Rode NTP por UDP/123, autorize as portas NTS-TLS; para PTP - LCA correta para multicaço (224. 0. 1. 129/130).

Monitoramento e alertas

• Offset (discrepância atual), jitter, frequency drivt, correções/segundos.
• Для PTP: `offsetFromMaster`, `meanPathDelay`, `grandmasterIdentity`, `stepsRemoved`.
• Para GNSS: SNR, DOP, satélites visíveis, PPS jitter.

• 'crony' exportar para Prometheus (crony-expositor), logs de texto → Loki.
• 'linuxptp' estatísticas ('ptp4l -m'), métricas através de node-exporter textfile.
• Contadores de rede: drops/retransmit/queue-len no time-VLAN.

• NTP offset p95> 1 ms em 5 minutos
• PTP offsetFromMaster > 25 μs (p95) 5 мин.
• Perda de GNSS/PPS> 1 min (mudança para holdover).
• Mudar o grandmaster (BMC) fora da janela de planejamento.
• Diferença de RPC ↔ system clock> limiar de carregamento.

Operações e atualizações

Iniciar/abrir: primeiro restabeleça a rede/GNSS/PPS → GM → BC/TC → clientes.
Leap-segundo: anuncie com antecedência, verifique a política smear e a compatibilidade.
Atualizações: firmware NIC/switches, 'linuxptp/crony' - staged com controle offset.
Runbooks: perda de GNSS, substituição de GM, mudança de domínio PTP, desabastecimento de cluster, acidente VLAN.

Folha de cheque de implementação

• Definidos por SLO (offset/jitter) para serviços e registros.
• Duas fontes de tempo independentes (GNSS + NTP), duas GM, a Marinha/plano manual do feelover.
• Time-VLAN/VRF selecionado, QoS, LCA/MACsec; PTP BC/TC incluídos.
• Uma única política leap está em todo o lado (smear/step não é permitido em venda).
• Chrony с NTS; ptp4l/phc2sys - em nódulos com PHC, configurações de enxofre.
• Monitoramento offset/jitter/GM/perdas GNSS, alertas e dashboard.
• Runbooks: loss of GNSS, GM failover, leap-second, drift-hunt.
• Documentação para a auditoria: fontes, configs, relatórios SLO, diário da GM.

Erros típicos

Um servidor de tempo sem reserva; Mistura de grupos públicos e privados sem controle.
PTP através de «barulhentos» rotas L3/assimetria, sem BC/TC.
Sem NTS/isolamento - possibilidade de substituir NTP/spufing PTP.
Políticas leap diferentes nos subistemas → «fenda» no tempo entre os serviços.
Ignorar monitoramento draft/holdover, correções súbitas a passos.
Máquinas virtuais duplas (host + guest) → discrepâncias.

Especificidades para iGaming/Fintech

Marcas de tempo legalmente significativas: guarde os arquivos e estatais de sincronização nos logs de transações/iventes (para comprovar a validade).
Ordem de eventos: O correlador de serviço cruzado usa um relógio lógico monótono + rótulos UTC, e não apenas «paredes».
Torneios/jogos: fixe o start/stop através do single fonte of time (domínio PTP/servidor NTP), TTL-dinheiro nas frentes, teste de ofset antes do «apito».
Inicialização RNG/seed: Inicialize a partir de criptomoedas e use o tempo apenas como componente, verificando offset dentro do SLO.
Relatórios/Reguladores: relatórios periódicos SLO do tempo e registros de turnos GM/fontes.

Mini-playbooks

1) Auditoria rápida do tempo no cluster

1. 'cronyc tracking' em cada nó → montar offset/jitter.
2. 'ptp4l -m '/' pmc' em nodes PTP → verificar GM, delay, stepsRemoved.
3. Verificar política leap, certificar-se de uniformidade.

2) Perda de GNSS

1. Ir para holdover (OCXO), alert.
2. Ligar NTP over VPN externo como um árbitro temporário.
3. Verificar antena/cabo/receptor; plano de substituição.

3) Mudar o Grandmaster

1. Verificação de prioridade BMC; aumento manual do segundo GM.
2. Controle offset do PR/clientes; se necessário, reiniciar phc2sys.
3. Relatório de incidente com filas temporárias offset.

Resultado

Um circuito de tempo confiável é uma referência sustentável (GNSS + PPS + OCXO), uma arquitetura de rede PTP (BC/TC/QoS/Isolamento), NTP com NTS segura, política leap coerente, disciplina slew-correção, e observabilidade SLO (NTS) offset/jitter/holdover). Fixe tudo em runbook-s, verifique regularmente e aprenda em exercícios - e o seu tempo ficará exato mesmo quando o resto estiver «tremendo».