Синхронізація часу

Навіщо це потрібно

Єдиний і точний час - основа впорядкування подій, коректної кореляції логів/трейсів, підпису транзакцій і відтворюваності звітності. Для платформ з грошовими потоками це питання комплаєнсу і довіри: «хто був першим», «коли був зафіксований результат», «який seed використаний».

Базові поняття

UTC vs TAI: UTC містить вставки високосних секунд; TAI - без них. Більша частина систем працює в UTC.
Leap second: секундна вставка/видалення. Підтримка/пом'якшення (smear) критичні для безшовної роботи.
Stratum (NTP): рівень віддаленості від еталона (0 - атом/ГНСС, 1 - сервери, 2 + - клієнти).
PTP ролі: Grandmaster (GM) → Boundary Clock (BC) / Transparent Clock (TC) → Slave.
PPS: імпульс-в-секунду для точної прив'язки від ГНСС/генератора.
Servo: алгоритм, який коригує частоту/фазу локальних годинників (chrony/ptp4l/phc2sys).

Коли NTP, коли PTP

NTP (Chrony): точність мілісекунди/соті мілісекунди; WAN/інтернет; просто і надійно.
PTP (IEEE 1588): суб-мілісекундна і до мікросекунд з апаратною позначкою; вимагає мережевої дисципліни (L2/мультикаст/QoS).
Гібрид: NTP/Chrony подає еталон на PTP-GM; далі в ЦОД - PTP з HW-timestamp.

Джерела часу і стійкість

GNSS (GPS/GLONASS/Galileo/BeiDou) + PPS як первинний еталон.
OCXO/TCXO (генератори) для holdover при втраті супутників.
Резервні референси: два незалежних GNSS-приймача, різні антени/кабелі, загороджувачі від джамінгу.
Вторинні NTP-пули: зовнішні надійні провайдери та приватні сервери (за VPN).
Grandmaster x2 з BMC (Best Master Clock) і ручним failover планом.

Мережева архітектура PTP

Профілі: Default, Telecom (G.8275. x), Power. Для ЦОДа частіше Default або профілі вендора.
Transparent Clock (TC): комутатор додає затримку (correction field) - покращує точність.
Boundary Clock (BC): комутатор/маршрутизатор - клієнт до вищого і майстер до нижнього сегменту.
QoS: пріоритизація PTP-мультикасту/унікасту, мінімізація черг.
Ізоляція: виділені VLAN/VRF для часу; відсутність L3-NAT на PTP-шляху.

Безпека: NTS для NTP, захист PTP

NTP: використовуйте NTS (Network Time Security, RFC 8915) - TLS-аутентифікація серверів часу. Симетричні ключі (classic auth) допустимі всередині периметра. Autokey - застарілий.
PTP: рідною МАС/автентифікацією майже не користуються; компенсуйте мережевою ізоляцією, ACL, MACsec/IPsec на L2/L3.
GNSS: захист від jamming/spoofing - монітор якості сигналів, спостереження DOP, гео-фільтри, детект аномалій.

Обробка високосної секунди і «змащування»

Leap-announce: NTP/Chrony повідомляє про майбутню вставку секунди.
Smear: розтягнення доби на ± 0. 5 с (або інше вікно), уникаючи сходинки. Google-подібний smear зручний для відмови від «стрибка», але всі сервіси повинні слідувати єдиній політиці (або ізолюйте контури).

SLO для часу (приклади)

Offset p95 клієнт ↔ еталон ≤ 1. 0 ms (NTP-контур ЦОДа), p99 ≤ 5 ms.
PTP с HW-timestamp: offset p95 ≤ 20 μ s, p99 ≤ 100 μ s всередині домену.
Jitter (stddev) ≤ 0. 2 ms (NTP) / ≤ 5 μs (PTP-HW).
Clock step подій = 0; тільки slew (плавна корекція) в прод-класі.
Drift при holdover OCXO: ≤ 1 ppm (контролюємо і алертим).

Інженерні практики (NTP/Chrony)

Чому Chrony: краще сходиться на «галасливій» мережі, стійкий до packet loss/асиметрії, гнучкий NTS.

Мінімальна'chrony. conf'( сервер):

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

Клієнти: вкажіть мінімум два сервери; увімкніть'makestep'для раннього старту і'maxslewrate'за необхідності.

Інженерні практики (PTP/linuxptp)

Апаратна відмітка часу (HW-TS): потрібні NIC/драйвери з PHC (PHC = PTP Hardware Clock).

Перевірка:

bash ethtool -T eth0      grep timestamp phc2sys -l

ptp4l (slave/GM/BC) - приклад конфігу:

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

Зв'язка PHC → системний годинник:

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

Для Boundary/Transparent clocks: використовуйте прошивки/образи комутаторів з підтримкою BC/TC і включайте їх профілі; контролюйте correction field в pmc:

bash pmc -u -b 0 "GET TIME_STATUS_NP"

Kubernetes, віртуалізація та контейнери

Ноди K8s синхронізуються як звичайні хости. Контейнери використовують час хоста.
Для PTP: PTP Operator/DaemonSet (наприклад,'linuxptp-daemonset') на виділених нодах з HW-TS;'NodeFeatureDiscovery'для маркування NIC з PHC.
Ізоляція робочого навантаження з чутливістю до часу (RNG/ігрові івенти): taints/tolerations → ноди з кращою синхронізацією.
У віртуалізації вимкніть агресивні «віртуальні» drift-коректори гіпервізора, використовуйте одну дисципліну часу (або guest NTP/PTP, або від гіпервізора).

Мережа і QoS

Розділяйте time-VLAN/VRF, тримайте затримки і джиттер мінімальними.
Для PTP E2E - уникайте асиметрій шляхів; для P2P - використовуйте лінк-local затримки.
Вмикайте jumbo MTU end-to-end тільки якщо скрізь погоджено; інакше - стандартний MTU, але стабільна черга.
Маршрутизуйте NTP по UDP/123, дозвольте NTS-TLS порти; для PTP - коректні ACL для мультикасту (224. 0. 1. 129/130).

Моніторинг та алерти

Що міряти:

Offset (поточна розбіжність), jitter, frequency drift, корекції/сек.
Для PTP: `offsetFromMaster`, `meanPathDelay`, `grandmasterIdentity`, `stepsRemoved`.
Для GNSS: SNR, DOP, видимі супутники, PPS jitter.

Інструменти:

'chrony'експорт в Prometheus (chrony-exporter), текстові логи → Loki.
'linuxptp'статистика ('ptp4l -m'), метрики через node-exporter textfile.
Мережеві лічильники: drops/retransmit/queue-len на time-VLAN.

Алерти (ідеї):

NTP offset p95> 1 ms протягом 5 хв.
PTP offsetFromMaster > 25 μs (p95) 5 мин.
Втрата GNSS/PPS> 1 хв (перемикання в holdover).
Зміна grandmaster (BMC) поза плановим вікном.
Різниця RTC ↔ system clock> порогу при завантаженні.

Операції та оновлення

Старт/перестарт: спочатку відновіть мережу/GNSS/PPS → GM → BC/TC → клієнти.
Leap-second: оголошуйте заздалегідь, перевірте smear-політику і сумісність.
Оновлення: firmware NIC/комутаторів,'linuxptp/chrony'- staged з контролем offset.
Runbooks: втрата GNSS, заміна GM, переїзд домену PTP, розсинхронізація кластера, аварії VLAN.

Чек-лист впровадження

Визначені SLO за часом (offset/jitter) для сервісів і журналів.
Два незалежних джерела часу (GNSS + NTP), два GM, ВМС/ручний план фейловера.
Виділений time-VLAN/VRF, QoS, ACL/MACsec; PTP BC/TC включені.
Скрізь єдина політика leap (smear/step заборонений в проді).
Chrony с NTS; ptp4l/phc2sys - на нодах з PHC, налаштування серв.
Моніторинг offset/jitter/GM/втрат GNSS, алерти і дашборди.
Runbooks: loss of GNSS, GM failover, leap-second, drift-hunt.
Документація для аудиту: джерела, конфіги, звіти SLO, журнал змін GM.

Типові помилки

Один сервер часу без резервування; змішання публічних пулів і приватних без контролю.
PTP через «галасливі» L3-маршрути/асиметрію, без BC/TC.
Немає NTS/ізоляції - можливість підміни NTP/спуфінгу PTP.
Різні leap-політики в підсистемах → «тріщина» в часі між сервісами.
Ігнор моніторингу drift/holdover, раптові крокові корекції.
Віртуальні машини з подвійною дисципліною (host + guest) → розбіжності.

Специфіка для iGaming/фінтех

Юридично значущі мітки часу: зберігайте офсети і статуси синхронізації в логах транзакцій/івентів (щоб доводити валідність).
Порядок подій: крос-сервісний корелятор використовує монотонний логічний годинник + UTC-мітки, а не тільки «стіни».
Турніри/матчі: фіксуйте start/stop через single source of time (PTP-домен/NTP-сервера), TTL-кеш на фронтах, перевірка офсету перед «свистком».
RNG/seed-ініціалізація: ініціалізуйте від криптожерел, а час використовуйте тільки як компонент, перевіряючи offset в межах SLO.
Звітність/регулятори: періодичні звіти SLO часу і журнал змін GM/джерел.

Міні-плейбуки

1) Швидкий аудит часу в кластері

1.'chronyc tracking'на кожному вузлі → зібрати offset/jitter.
2.'ptp4l -m '/' pmc'на PTP-нодах → перевірити GM, delay, stepsRemoved.
3. Звірити leap-політику, переконатися в однаковості.

2) Втрата GNSS

1. Перейти в holdover (OCXO), алерт.
2. Підключити зовнішній NTP over VPN як тимчасовий референс.
3. Перевірити антену/кабель/приймач; план заміни.

3) Зміна Grandmaster

1. Перевірка BMC пріоритету; ручне підвищення другого GM.
2. Контроль offset у ВС/клієнтів; при необхідності перезапуск phc2sys.
3. Звіт про інцидент з тимчасовими рядами offset.

Підсумок

Надійний контур часу - це стійкий еталон (GNSS + PPS + OCXO), коректна мережева архітектура PTP (BC/TC/QoS/ізоляція), безпечний NTP з NTS, узгоджена leap-політика, дисципліна slew-корекцій, і спостережуваність SLO (offset/jitter/holdover). Зафіксуйте все в runbook-ах, регулярно перевіряйте офсети і вчіться на навчаннях - і ваш час залишиться точним навіть тоді, коли все інше «тремтить».