Синхронизация времени на сервере: NTP и chrony

Почему точное время на сервере — это не мелочь

Серверные часы кажутся второстепенной деталью до тех пор, пока расхождение не становится заметным на практике — а происходит это внезапно и обычно в самый неудобный момент. Операционная система Linux ведёт собственный отсчёт времени через аппаратный таймер, и без внешней коррекции этот отсчёт постепенно расходится с реальным временем из-за физической погрешности генератора тактовой частоты, которая есть в любом оборудовании, включая самые дорогие серверы.

Наиболее очевидное практическое последствие — проверка TLS-сертификатов. Каждый сертификат имеет строго определённый период действия, и клиент (браузер, curl, библиотека HTTP-запросов) проверяет текущее системное время именно относительно собственных часов, а не относительно какого-то внешнего эталона. Если часы сервера отстали и показывают дату до начала действия сертификата или ушли вперёд за его окончание, соединение будет отклонено как небезопасное, даже если сам сертификат абсолютно корректен и оплачен на годы вперёд.

Расхождение времени не менее болезненно сказывается на распределённых системах: репликация баз данных, консенсус-протоколы в кластерах и системы логирования, агрегирующие записи с нескольких серверов, в значительной степени полагаются на то, что временные метки разных узлов сопоставимы друг с другом. Если на одном сервере кластера время отстаёт на несколько минут, события с этого сервера в общем логе будут выглядеть так, будто произошли раньше, чем случились в реальности, что серьёзно затрудняет расследование инцидентов.

Наконец, сама аутентификация во многих протоколах опирается на время: одноразовые токены с ограниченным сроком жизни, подписи запросов с временной меткой (как в некоторых схемах API-аутентификации) и Kerberos в корпоративных сетях допускают лишь небольшое расхождение часов между клиентом и сервером, после которого запрос или токен просто отклоняется как просроченный или ещё не наступивший.

NTP, chrony и в чём разница

NTP (Network Time Protocol) — это сетевой протокол для синхронизации часов компьютера с внешним эталонным источником времени, разработанный ещё в 1980-х годах и остающийся стандартом де-факто по сей день. Классическая эталонная реализация — демон ntpd — долгое время была единственным широко используемым вариантом на Linux-серверах.

Chrony — это отдельная реализация того же протокола NTP, а не конкурирующий протокол: она общается с теми же NTP-серверами по той же сети тем же способом, но иначе устроена внутри. Практическое преимущество chrony особенно заметно в двух сценариях: на системах с непостоянным сетевым соединением (например, ноутбуки, засыпающие и просыпающиеся) и на виртуальных машинах, где системные часы могут временно останавливаться или скачкообразно смещаться из-за особенностей гипервизора.

Chrony заметно быстрее сходится к точному времени после старта службы или после длительного простоя без сети, чем классический ntpd, и делает это плавно — постепенно замедляя или ускоряя ход часов вместо резкого скачка на большую величину, что важно для приложений, чувствительных к внезапным перемещениям времени назад (повторное выполнение уже отработавших задач по расписанию) или вперёд (преждевременное истечение сроков действия токенов).

На современных дистрибутивах Linux — включая свежие версии Ubuntu, Debian, CentOS, AlmaLinux и RHEL — chrony уже является демоном синхронизации времени по умолчанию, и на новых установках менять ничего не нужно, кроме, возможно, конкретных источников синхронизации, о чём в следующем разделе.

Установка и базовая настройка chrony

На системах, где chrony ещё не установлен, установка выполняется через стандартный пакетный менеджер дистрибутива.

# Debian / Ubuntu
apt install chrony

# CentOS / AlmaLinux / RHEL
dnf install chrony

systemctl enable --now chronyd

После установки основной конфигурационный файл находится в /etc/chrony/chrony.conf (Debian/Ubuntu) или /etc/chrony.conf (RHEL-подобные системы). Ключевая директива в нём — список серверов времени, к которым chrony будет обращаться для синхронизации, задаваемый директивами server или pool.

pool 2.ru.pool.ntp.org iburst
pool time.cloudflare.com iburst
pool time.google.com iburst

driftfile /var/lib/chrony/drift
makestep 1.0 3

Директива pool указывает не один конкретный сервер, а пул из нескольких серверов, объединённых под общим доменным именем через DNS-балансировку, — это устойчивее к недоступности отдельного сервера, чем жёстко заданный единственный адрес через директиву server. Флаг iburst ускоряет первичную синхронизацию сразу после запуска службы, отправляя несколько быстрых запросов подряд вместо ожидания обычного интервала между опросами.

Директива makestep разрешает chrony сделать резкий скачок времени (а не только плавную коррекцию), если расхождение превышает заданный порог, но ограничивает число таких скачков — в примере выше первые три коррекции после запуска службы могут быть резкими, если расхождение больше секунды, а после этого chrony переходит исключительно на плавную коррекцию, чтобы не создавать резких скачков времени на уже работающем сервере.

Проверка статуса синхронизации: chronyc

Утилита chronyc — это интерактивная консоль для взаимодействия с работающей службой chronyd, через которую проверяется текущий статус синхронизации, список источников времени и качество связи с каждым из них.

chronyc tracking

Вывод chronyc tracking показывает несколько ключевых полей: Reference ID и Stratum — источник, с которым сервер синхронизируется сейчас, и его удалённость от эталонных атомных часов в сети NTP (Stratum 1 — сервер, напрямую подключённый к атомным часам или GPS-приёмнику, каждый следующий уровень получает время на шаг дальше от эталона); System time — текущее расхождение системных часов с рассчитанным точным временем, обычно выражаемое в миллисекундах или их долях на исправно работающем сервере.

chronyc sources -v

Команда chronyc sources выводит список всех настроенных источников времени с отметкой текущего состояния каждого: символ звёздочки перед строкой означает источник, выбранный как основной прямо сейчас, плюс — резервные кандидаты, а символ вопросительного знака или пустая строка — источник, с которым в данный момент нет связи. Столбцы Reach показывают историю успешных опросов в восьмеричном виде, а Delay и Offset — сетевую задержку до источника и текущее измеренное расхождение времени с ним соответственно.

Если все источники в выводе chronyc sources помечены как недоступные, стоит в первую очередь проверить исходящий доступ по UDP на порт 123 — многие конфигурации firewall по умолчанию разрешают только исходящий TCP-трафик, забывая про UDP, на котором работает протокол NTP, и в такой ситуации chrony формально запущен, но не может достучаться ни до одного сервера времени.

timedatectl: общее управление временем через systemd

На системах с systemd команда timedatectl служит общей точкой управления настройками времени — часовым поясом, состоянием NTP-синхронизации и форматом хранения аппаратных часов, — не подменяя при этом саму работу chrony, а лишь включая или отключая её использование на уровне системы в целом.

timedatectl

В выводе timedatectl без аргументов видно текущее локальное и всемирное время, установленный часовой пояс сервера и статус System clock synchronized — булево значение, отражающее, синхронизированы ли часы прямо сейчас согласно активной службе синхронизации, будь то chrony или её альтернатива.

timedatectl set-timezone Europe/Moscow
timedatectl set-ntp true

Часовой пояс сервера стоит устанавливать осознанно и, как правило, в UTC для серверов, обслуживающих несколько регионов или интегрированных с другими системами, где сравнение временных меток критично, — локальный часовой пояс удобнее для чтения логов человеком, но усложняет автоматическое сопоставление событий между серверами в разных часовых поясах и создаёт дополнительную путаницу дважды в год в регионах с переходом на летнее время (хотя в России этот переход отменён с 2014 года).

Флаг set-ntp true в timedatectl включает использование службы синхронизации на уровне системы в целом — при значении false демон синхронизации времени (chronyd или альтернативный) может быть формально запущен, но его результаты не будут применяться к системным часам, что на практике выглядит как полностью нерабочая синхронизация без единой явной ошибки в логах самой службы.

Синхронизация времени на виртуальных машинах: особенности

Виртуальные машины синхронизируют время сложнее, чем физическое оборудование, поскольку у гостевой операционной системы нет прямого доступа к аппаратным часам физического сервера — представление о ходе времени эмулируется гипервизором и передаётся гостевой системе через паравиртуализированный интерфейс.

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

Для большинства современных гипервизоров (KVM, VMware, Hyper-V) существуют собственные механизмы синхронизации времени на уровне паравиртуализации, дополняющие или в некоторых конфигурациях подменяющие NTP-синхронизацию внутри гостевой системы. Тем не менее для предсказуемого поведения на VPS практика показывает, что chrony внутри самой гостевой системы стоит держать активным независимо от механизмов гипервизора — так синхронизация не зависит от того, насколько корректно настроена паравиртуализация конкретного облачного провайдера.

После восстановления виртуальной машины из длительной приостановки стоит проверить chronyc tracking сразу же — если расхождение оказалось больше порога, заданного директивой makestep, chrony применит резкую коррекцию времени одним скачком, что для большинства сценариев безопаснее, чем оставлять систему с заметно неверным временем на период, пока плавная коррекция постепенно подтянет часы к точному значению.

Влияние неточного времени на конкретные сервисы

TLS-сертификаты — самый частый практический симптом сломанной синхронизации времени: если системные часы сервера ушли за границу срока действия сертификата (в любую сторону — как вперёд, так и назад), клиенты начинают получать ошибку недоверенного сертификата, хотя сам файл сертификата абсолютно корректен и действителен по факту календарной даты.

Репликация баз данных особенно чувствительна к рассинхронизации часов между узлами в схемах, использующих временные метки для определения порядка операций или для разрешения конфликтов записи в мультимастер-конфигурациях — при заметном расхождении времени между узлами операция, реально выполненная позже, может быть ошибочно интерпретирована как более ранняя, что приводит к потере данных при разрешении конфликта в пользу неверной версии записи.

Cron и другие планировщики задач по расписанию уязвимы к резким скачкам времени: если системные часы внезапно перескакивают вперёд через момент запланированного выполнения задачи, задача может быть полностью пропущена; если, наоборот, время резко отбрасывается назад после того, как задача уже отработала, тот же момент времени может наступить повторно, и задача выполнится второй раз, что особенно опасно для задач, не рассчитанных на повторный запуск (например, отправка уведомлений или списание средств).

Логи и системы мониторинга теряют часть своей диагностической ценности при неточном времени — сопоставление записей из логов веб-сервера, приложения и базы данных по временным меткам становится ненадёжным, если часы этих компонентов расходятся хотя бы на секунды, а расследование инцидента, где важен точный порядок событий на нескольких серверах, превращается в угадывание вместо анализа фактов.

Диагностика типичных проблем синхронизации

Если chronyc tracking показывает большое и не уменьшающееся расхождение времени, первым делом стоит проверить, действительно ли служба chronyd запущена и не завершилась ли она аварийно вскоре после старта — статус проверяется через systemctl status chronyd, а причина возможного сбоя обычно видна в journalctl -u chronyd.

systemctl status chronyd
journalctl -u chronyd --since "10 min ago"

Если служба запущена, но chronyc sources показывает все источники недоступными, вероятная причина — блокировка исходящего UDP-трафика на порт 123 сетевым firewall, будь то iptables/ufw на самом сервере или правила безопасности на уровне облачного провайдера. Стоит явно проверить исходящее правило для UDP 123, поскольку многие типовые конфигурации firewall по умолчанию разрешают исходящий TCP почти без ограничений, но забывают про UDP на нестандартных портах.

Отдельная ситуация — сервер, находящийся во внутренней сети без прямого выхода в интернет, где публичные пулы NTP недоступны в принципе. Для таких случаев решение — указать в конфигурации chrony внутренний корпоративный NTP-сервер вместо публичных пулов, либо, если такого сервера в сети нет, поднять один узел с доступом наружу как единую точку синхронизации для остальных внутренних серверов через ту же директиву server.

Если время систематически отстаёт на постоянную величину даже при формально работающей синхронизации, стоит проверить содержимое driftfile — этот файл хранит оценку скорости естественного дрейфа аппаратных часов сервера, и повреждённый или обнулённый driftfile заставляет chrony заново накапливать эту оценку с нуля, временно снижая точность коррекции до накопления новой статистики за несколько часов работы.

Чек-лист настройки синхронизации времени

Шаг 1. Убедитесь, что chrony установлен и служба chronyd включена в автозапуск: systemctl enable --now chronyd.

Шаг 2. Проверьте список источников времени в /etc/chrony/chrony.conf — используйте несколько независимых пулов, а не единственный сервер, чтобы избежать полной потери синхронизации при недоступности одного источника.

Шаг 3. Убедитесь, что исходящий UDP-трафик на порт 123 разрешён на уровне firewall сервера и на уровне сетевых правил облачного провайдера.

Шаг 4. Проверьте текущий статус синхронизации командой chronyc tracking и убедитесь, что System time показывает расхождение в единицы миллисекунд, а не секунды.

Шаг 5. Установите корректный часовой пояс через timedatectl set-timezone и убедитесь, что set-ntp включён.

Шаг 6. На виртуальных машинах после восстановления из снапшота или живой миграции проверяйте синхронизацию отдельно — не полагайтесь только на механизмы паравиртуализации гипервизора.

Итог: незаметная служба с заметными последствиями сбоя

Синхронизация времени — одна из тех фоновых задач сервера, которая остаётся полностью незамеченной, пока работает штатно, и создаёт трудноуловимые проблемы в самых разных частях инфраструктуры, если перестаёт работать. TLS-соединения, репликация баз данных, планировщики задач и распределённые логи — всё это в той или иной степени опирается на предположение о точности системных часов, редко проверяемое явно до тех пор, пока не проявится в виде конкретной ошибки.

Chrony на современных дистрибутивах Linux обычно уже установлен и настроен по умолчанию разумно для базового сценария, но осмысленный выбор нескольких независимых источников синхронизации, проверка доступности порта 123 на firewall и периодическая проверка chronyc tracking превращают синхронизацию времени из невидимого предположения в контролируемый и проверяемый компонент инфраструктуры.

Особое внимание к синхронизации времени стоит уделить именно на виртуальных серверах — там расхождение часов возникает не из-за пренебрежения настройкой, а из самой природы виртуализации, и регулярная проверка после операций вроде миграции или восстановления из снапшота позволяет заметить проблему раньше, чем она проявится в виде отклонённого TLS-сертификата или сбойной репликации базы данных.