chrony против systemd-timesyncd - Каковы различия и варианты использования в качестве клиентов NTP?

Как-то, но не совсем, опираясь на старый вопрос «ntpd против systemd-timesyncd - как добиться надежной синхронизации NTP?» Я хотел бы спросить о различиях между chrony и systemd-timesyncd с точки зрения клиента NTP .

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

В примечаниях к выпуску Ubuntu Bionic Beaver говорится следующее:

Для простой синхронизации времени базовая система уже поставляется с systemd-timesyncd. Хроника нужна только для того, чтобы выступать в роли сервера времени или, если вы хотите, чтобы объявленная синхронизация была более точной и эффективной.

Мне нравится идея использовать минимальный предустановленный инструмент для выполнения этой работы, и я почти уверен, что systemd-timesyncd выполнит эту работу для моих сценариев использования, но мне все же любопытно:

Каковы реальные различия между двумя с точки зрения точности?
Каковы различия в эффективности?
Что такое «непростая» синхронизация времени, такая как сценарии использования chrony в качестве клиента NTP?

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 в качестве клиента NTP?

Об этом говорится в приведенной выше цитате, но в любом случае это варианты использования Chrony, которые не охватываются systemd-timesyncd:

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

Эти варианты использования требуют Chrony или NTDP или аналогичные.

— filbranden
источник

Большое спасибо за ваш сложный ответ и большие пальцы за конкретное решение моих вопросов. Чтобы уточнить это: - 1. Каков порядок величины дельты точности. Знание этого определенно добавит некоторую субстанцию к принятию решений. Мы говорим о 10 ^ -9 или 10 ^ -1 секунд? - - 2. Ваш ответ по поводу эффективности сделал меня еще более смелым: добавляет ли кощунственно некоторое усреднение нескольких чисел настолько большую нагрузку на процессор, что вам нужно упомянуть об этом в примечаниях к выпуску Ubuntu?

— WEDI

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

— TooTea

Спасибо, @TooTea! Ok. Понимаю. Таким образом, повышенная точность достигается за счет использования более одного источника, и любой особой магической хроникой, выполняемой с одним единственным источником, можно пренебречь. Мое понимание: - - 1. Использование единственного сервера времени metadata.google.internal на экземпляре GCE => нет ощутимых различий в точности (давайте исключим timemearing et.al.) - - 2. Использование трех серверов времени с отличной репутацией на виртуальной машине в какой-то устоявшейся хостинговой компании => вы видите разницу, но не "большую" (что бы это ни было) - - 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 является то, что вы не можете сделать его более точным, получая время из нескольких источников, как по умолчанию протокол сетевого времени.

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

PS systemd-timesyncdне должно быть рекомендуемой альтернативой, когда не используется systemd.

— Руи Ф Рибейро
источник

Это не совсем очевидно. Теоретически можно запустить systemd-timesyncdпрограмму под другим менеджером службы. service-managerС 2018 года я предоставляю пакет услуг для запуска его под инструментарием nosh. Что вы упустили, так это то, что пользователи systemd (согласно ошибке Debian # 812522) поощряют гостевые службы VirtualBox и других явно конфликтовать с этой systemd-timesyncdслужбой, чтобы предотвратить ее использование. в виртуальных машинах.

— JdeBP

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

— Руи Ф Рибейру

(отредактируйте мой ответ в свете вашего замечания, в этом тексте была одна ошибка об управлении vmtools против (S) NTP, и сделайте его более явным)

— Руи Ф. Рибейро,

@wedi В случае VmWare синхронизацию по времени с гипервизором можно отключить как в 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 - это форк, и я упомянул в своем вопросе, что chrony реализует сервер и клиент, тогда как systemd-timesyncd - только клиент. Спасибо за упоминание соответствующих RFC.

— WEDI