chrony vs. systemd-timesyncd - Які відмінності та випадки використання як клієнтів NTP?

Якось, але не зовсім спираючись на старе питання "ntpd vs. systemd-timesyncd - Як досягти надійної синхронізації NTP?" , Я хотів би запитати про відмінності між chrony та systemd-timesyncd з точки зору клієнта NTP .

Я знаю, що systemd-timesyncd - це більш-менш мінімальна реалізація ntp-клієнта, тоді як chrony є повноцінним рішенням демона NTP, яке, як правило, включає клієнт NTP.

Нотатки до випуску ubuntu Bionic Beaver констатують наступне:

Для простої синхронізації потрібна базова система, яка вже поставляється з systemd-timesyncd. Chrony потрібен лише для того, щоб діяти як сервер часу або якщо ви хочете, щоб рекламована реклама була більш точною та ефективною синхронізацією.

Мені подобається ідея використання мінімально попередньо встановленого інструменту для виконання роботи, і я впевнений, що systemd-timesyncd зробить роботу для моїх випадків використання, мені все ж цікаво:

Які реальні світові відмінності між ними в точності?
Які відмінності в ефективності?
Що таке "не прості" часові синхронізації?

systemd ntp chrony

— wedi
джерело

Відповіді:

Оголошення Systemd-timesyncd в Systemd файлі NEWS робить хорошу роботу по поясненню відмінностей цього інструменту в порівнянні з Chrony і інструменти , як це. (наголос мій):

Новий «Systemd-timesyncd» демон був доданий для синхронізації внутрішнього годинника по всій мережі. Він реалізує клієнт SNTP . На відміну від реалізацій NTP, таких як chrony або NTP-сервер, цей реалізує лише клієнтську сторону і не переймається повною складністю NTP, зосереджуючись лише на запитах часу з одного віддаленого сервера та синхронізації локального годинника на ньому . Якщо ви не збираєтесь обслуговувати NTP для мережевих клієнтів або не хочете підключитися до локальних апаратних годин, цей простий клієнт NTP повинен бути більш ніж підходящим для більшості установок. [...]

Ця установка є загальним випадком використання для більшості хостів серверного флоту. Зазвичай вони синхронізуються з локальних серверів NTP, які самі синхронізуються з декількох джерел, можливо, включаючи апаратні. systemd-timesyncd намагається надати просте у використанні рішення для цього загального випадку використання.

Намагаючись вирішити ваші конкретні питання:

Які реальні світові відмінності між ними в точності?

Я вважаю, що ви можете отримати більш високу точність, отримавши дані синхронізації з декількох джерел, що конкретно не підтримується випадком використання для systemd-timesyncd. Але коли ви використовуєте їх для отримання даних синхронізації з центральних серверів NTP, підключених до вашої надійної внутрішньої мережі, використання декількох джерел насправді не так актуально, і ви отримуєте хорошу точність з одного джерела.

Якщо ви синхронізуєте ваш сервер із надійним сервером у локальній мережі та в тому самому центрі обробки даних , різниці в точності між NTP та SNTP практично не існуватимуть. NTP може враховувати RTT і робити часовий показник, але це не так вигідно, коли RTT насправді невеликий, що стосується швидкої локальної мережі та машини поблизу. Також вам не потрібно декілька джерел, якщо ви можете довіряти тому, який ви використовуєте.

Які відмінності в ефективності?

Отримати синхронізацію з одного джерела набагато простіше, ніж отримати її з декількох джерел, оскільки вам не потрібно приймати рішення про те, які джерела кращі за інші, і, можливо, комбінувати інформацію з кількох джерел. Алгоритми набагато простіші і вимагають меншої завантаження процесора для простого випадку.

Що таке "не прості" часові синхронізації?

Це розглянуто у цитаті вище, але у будь-якому випадку це випадки використання для Chrony, які не охоплені systemd-timesyncd:

запуск сервера NTP (щоб інші хости могли використовувати цей хост як джерело для синхронізації);
отримання інформації про синхронізацію NTP з декількох джерел (що важливо для хостів, які отримують цю інформацію з загальнодоступних серверів в Інтернеті); і
отримання інформації про синхронізацію з місцевого годинника, яка зазвичай передбачає спеціалізоване обладнання, наприклад GPS-пристрої, які можуть отримувати точну інформацію про час із супутників.

Ці випадки використання вимагають Chrony або ntpd або подібних.

— filbranden
джерело

Велике спасибі за вашу детальну відповідь та великі пальці за те, що конкретно вирішували мої запитання. Щоб уточнити це: - - 1. Який порядок величини дельти точності. Знаючи це, неодмінно додасть якусь субстанцію для прийняття рішень. Ми говоримо про 10 ^ -9 або 10 ^ -1 секунди? - - 2. Ваша відповідь щодо ефективності зробила мене ще більш люб’язним: чи - богохульно кажучи - деяке усереднення кількох чисел додає стільки навантаженню процесора, що вам потрібно згадати про це у примітках до випуску Ubuntu?

— WEDI

@wedi: Точність timesyncd залежатиме головним чином від сервера та мережі. Маючи лише один сервер, немає ніякого способу визначити, чи повертає сервер неправдиві дані, тому вам просто доведеться повністю довіряти цьому. (Максимальна помилка від цього не обмежена). Максимальна точність, яку ви можете досягти, визначатиме мережеве тремтіння між вами та сервером (може бути пару мілісекунд або більше).

— TooTea

Дякую, @TooTea! Добре. Я бачу. Таким чином, підвищена точність пов'язана з використанням більш ніж одного джерела, і будь-яку особливу магічну хроніку з одним джерелом можна знехтувати. Моє розуміння: - - 1. Використання метаданих.google.internal єдиного тайм-сервера для екземпляра GCE => відсутність вимірюваної різниці в точності (виключаємо часове вимірювання et.al.) - - 2. Використання трьохчасових серверів з великою репутацією на vm у якоїсь влаштованої хостингової компанії => ви бачите різницю, але не "сильно" (як би це не було) - - 3. Використовуючи pool.ntp.org на рапі, підключеному через якийсь ISP =>, ви такі щасливі, як може отримати Ларрі.

— WEDI

Я б сказав правильно на всіх трьох @wedi. Зокрема (1), якщо ви використовуєте таймер-сервер у тій же "локальній мережі", що і ваша машина, і, по суті, в тому ж центрі обробки даних (дуже низький rtt і дуже низький джиттер), переваги NTP і часового відтворення SNTP щодо точності, буде дуже низьким. Тож мало підстав запускати NTP (а не SNTP) у тих випадках використання!

— filbranden

@wedi Оновлено відповідь, щоб явно згадати використання надійного сервера в локальній мережі.

— filbranden

Як інша відповідь правильно стверджує, chronyреалізує NTP та systemd-timesyncdSNTP.

З точки зору клієнта, який обслуговує час:

SNTP - набагато простіший протокол для реалізації;
NTP дозволяє здійснювати покрокові збільшення / виправлення в часі. Однією з головних переваг NTP є те, що він також враховує RTT відповіді, щоб отримати більш точний час.

З https://www.meinbergglobal.com/english/faq/faq_37.htm

Хоча повнофункціональний сервер або клієнт NTP досягає дуже високого рівня точності і максимально уникає різких кроків часу, використовуючи різні математичні та статистичні методи та плавне регулювання швидкості тактової частоти, SNTP може бути рекомендовано лише для простих програм, де вимоги до точність і надійність не надто вимогливі. Нехтуючи значеннями дрейфу та використовуючи спрощені способи регулювання системних тактових годин (часто прості кроки в часі), SNTP досягає лише низької якості синхронізації часу в порівнянні з повною реалізацією NTP.

SNTP використовує набагато простіший підхід. Багато складності алгоритму NTP вилучено. Замість того, щоб перекручувати час, багато клієнтів SNTP крокують час. Це добре для багатьох програм, де потрібна проста часова марка. Крім того, SNTP не має можливості контролювати та фільтрувати декілька серверів NTP. Часто використовується простий підхід із круговим режимом, де, якщо один сервер виходить з ладу, використовується наступний у списку

З https://www.masterclock.com/company/masterclock-inc-blog/ntp-vs-sntp

NTP набагато більш точний і точний, ніж SNTP, і це робить його фактичним переможцем у більшості корпоративних програм. З іншого боку, простота SNTP робить його більш підходящим для таких речей, як IP камери, відеореєстратори та деякі мережеві комутатори. У цих типів апаратного забезпечення бракує ресурсів обробки для обробки складніших протоколів, але, оскільки підключені пристрої стають все більш потужними, це може змінитися.

Одним з головних слабких моментів SNTP є те, що ви не можете зробити його більш точним, отримуючи час з різних джерел, таких як Network Time Protocol за замовчуванням.

Ще один важливий момент, який я можу побачити, що реалізація SNTP, що створює більше проблем, ніж NTP, полягає у віртуалізації, коли у вас є і гіпервізор, і демон NTP, які намагаються змінити час роботи віртуального комп'ютера. Спеціально, якщо вони не погоджуються вчасно з деякими неправильними налаштуваннями, вони стають активними, це може спричинити великі проблеми. (Хоча компетентні системні адміністратори залишатимуться активними лише один метод синхронізації з часом, може статися, що вони обидва активні через помилку конфігурації).

PS systemd-timesyncdне повинен бути рекомендованою альтернативою, коли не використовується systemd.

— Rui F Ribeiro
джерело

Це не зовсім очевидно. Теоретично можна запустити systemd-timesyncdпрограму під іншим менеджером сервісів. Я надав пакет послуг для його запуску під інструментальним інструментом nosh service-managerз 2018 року. Те, що ви пропустили, - це те, що системні люди (за помилку Debian № 812522) заохочують гості сервісів VirtualBox та інших явно конфліктувати з systemd-timesyncdсервісом, щоб запобігти його використанню. у віртуальних машинах.

— JdeBP

@JdeBP Цікаве зауваження. Я використовую Debian без systemd.... Тим не менш, vmtools timesync може і буде відключений, і його слід відключити на серверах, що виконують NTP-сервіси (наприклад, VM-сервери NTP-серверів), а деякі sysadmins синхронізуються vmtools, інші слідкують за документами VmWare про відключення vmtools timesync (яку слід використовувати лише тоді, коли ви знаєте, що робите). Ця помилка не є лінійною для вирішення, і вона буде додатковою точкою конфігурації, яку легко пропускають люди, дотримуючись рекомендацій VmWare щодо не використання vmtools timesync.

— Rui F Ribeiro

(відредагуйте мою відповідь, зважаючи на ваше зауваження, була одна помилка у тому тексті щодо управління vmtools vs (S) NTP, і зробіть це більш явним)

— Rui F Ribeiro

@wedi У випадку VmWare timesync з гіпервізором можна відключити як у Vcenter, конфігурації зображення VM, так і на стороні Linux. див. пов'язані unix.stackexchange.com/questions/492487/… Я завжди роблю vmware-toolbox-cmd timesync disableна своїх NTP-серверах, незалежно від того, хлопці VmWare відключили функцію синхронізації для цих віртуальних машин. (Я зазвичай вважаю за краще використовувати chrony як клієнт NTP)

— Rui F Ribeiro

Я радий, що ти вказав на можливу гонку синхронізації за часом! Добре пам’ятати про це!

— WEDI

chronyне є форкою, ntpdале реалізується з нуля. Він реалізує як клієнтський, так і серверний режими повного протоколу NTPv4 ( RFC5905 ). Для користувачів класів підприємств ми спостерігаємо тенденцію переходу від традиційних ntpdдо chronyподібних Red Hat (RHEL 7 і далі) та SuSE (від SLES 15).

systemd-timesyncdзастосовувати лише клієнтський режим протоколу SNTP ( RFC4330 ) . Отже, випадки складного використання не охоплюються . Наприклад, SNTP не може зробити його більш точним, отримуючи час з декількох джерел, як NTP за замовчуванням. Як результат, не можна забезпечити максимально точний час .systemd-timesyncdsystemd-timesyncdchrony

— PT Huynh
джерело

Мммм. Я не помічав, щоб хтось вважав хронію - це вилка, і я зазначав, що chrony реалізує сервер і клієнт, тоді як systemd-timesyncd - лише клієнт. Дякуємо, що згадали про відповідні RFC.

— WEDI