Блог компании 3v-Hosting
9 мин.
Для многих администраторов настройка времени на сервере выглядит нечто неважное, как мелочь, которой можно заняться потом. Часто её и правда откладывают на потом, но ровно до того момента, пока резервная копия базы данных "вдруг" не получает дату из будущего, SSL-сертификат начинает считаться просроченным, а cron запускает задачу совсем не тогда, когда от него этого ждали.
Такие проблемы могут долго оставаться невидимыми. Сервер работает неделями или месяцами без единой жалобы, а потом одна неверная настройка времени тянет за собой ошибки в логах, сбои мониторинга, странное поведение приложений и вопросы, на которые с первого взгляда сложно найти ответ. Особенно тяжелыми могут быть последствия в инфраструктуре, где есть несколько серверов, контейнеры, базы данных и разные сервисы, которые постоянно обмениваются данными между собой.
Путаницы добавляет ещё и другой момент, что Timezone и NTP часто воспринимают как что-то одно. На самом деле это совершенно разные механизмы, каждый из которых отвечает за свою часть работы со временем.
В этой статье мы разберёмся в этих понятиях, а также научимся настраивать время на своем Linux сервере.
Если упростить до одной фразы, то timezone отвечает за то, как сервер показывает время, а NTP - за то, насколько это время соответствует действительности.
Можно представить себе обычные настенные часы. Часовой пояс определяет, что именно будет на циферблате для конкретного региона, а NTP периодически проверяет эти часы по точному эталону и подправляет их, если они начинают спешить или отставать.
В Linux системное время хранится в UTC. Пользователь, приложения и журналы событий уже получают время с учётом выбранного часового пояса. Такой подход избавляет от множества проблем, особенно когда один сервер работает с пользователями из разных стран или находится в дата-центре за тысячи километров от владельца проекта.
Отсюда и появляется два отдельных шага настройки.
Пропускать любой из них - не очень хорошая идея, так как, например, сервер может показывать красивое локальное время и при этом отставать на несколько минут. А бывает и наоборот, когда часы идут абсолютно точно, но все события в логах записываются в чужом часовом поясе. И то и другое рано или поздно создаёт описанные выше проблемы.
Теперь, когда мы определились с этими понятиями, давайте по очереди разберёмся с каждым из них на реальных примерах.
В большинстве современных дистрибутивов Linux для работы со временем используется systemd. Проверить текущие настройки можно одной командой:
timedatectl
Среди прочей информации вы увидите строку с часовым поясом, например:
Time zone: Europe/Kyiv (EEST, +0300)
Если сервер показывает UTC или другой регион вместо нужного, то часовой пояс лучше исправить сразу, иначе потом придётся разбираться, почему записи в логах, задачи cron и уведомления приходят со странным временем.
Посмотреть полный список доступных временных зон можно так:
timedatectl list-timezones
Список довольно большой, поэтому удобнее искать нужный регион через фильтр:
timedatectl list-timezones | grep Kyiv
Для смены часового пояса достаточно выполнить такую команду:
timedatectl set-timezone Europe/Kyiv
После выполнения этой команды перезагрузки сервера не потребуется, так как новый часовой пояс применяется сразу, и большинство сервисов начинают использовать его без дополнительных действий. Иногда полезно проверить время повторно через timedatectl, просто чтобы убедиться, что настройка действительно сохранилась.
После настройки часового пояса стоит убедиться в том, что сервер показывает правильное время и действительно синхронизирует его с внешними источниками. Наиболее часто именно здесь часто обнаруживаются проблемы, которые до этого оставались незаметными.
Проверить текущее системное время можно командой:
date
Для получения полной информации о настройках времени удобнее использовать другую команду:
timedatectl status
В выводе timedatectl есть несколько строк, на которые обычно смотрят в первую очередь:
Time zone System clock synchronized NTP service
По ним можно быстро понять общую картину, а именно какой часовой пояс используется, синхронизированы ли системные часы и запущена ли в принципе служба NTP.
Иногда встречается такая ситуация, когда сервер показывает правильное локальное время, но строка System clock synchronized имеет значение no. Это может сбить с толку администратора, ведь внешне всё кажется исправным. А на самом деле часы уже постепенно начинают уходить от точного времени и через несколько недель такая мелочь вполне способна превратиться в одну из описанных выше проблем.
Если ваш сервер физический, выделенный или ваша виртуальная машина имеет доступ к аппаратным часам хост машины, то их состояние можно посмотреть отдельно командой:
hwclock --show
Аппаратные часы (RTC или Real-Time Clock) - это отдельный таймер на материнской плате, который продолжает работать даже после выключения системы. При загрузке Linux получает начальное время именно из RTC, а затем уже синхронизирует его через NTP.
Стоит помнить, что компьютерные часы не являются абсолютно точными. Любой аппаратный таймер, рано или поздно начинает постепенно отклоняться от эталонного времени. Иногда речь идет о долях секунды в сутки, а иногда и о нескольких секундах или минутах в месяц.
Чаще всего для VPS этот вопрос не актуален, так как аппаратные часы скрыты за слоем гипервизора, однако на выделенных серверах и домашних серверах неправильные аппаратные часы иногда становятся причиной сбоев.
За точность времени на сервере отвечает NTP (Network Time Protocol). Этот протокол периодически сравнивает локальные часы с эталонными источниками точного времени в интернете и при необходимости корректирует их.
Источниками могут быть специализированные серверы в университетах, дата-центрах, научных организациях или публичных пулах времени. Сервер обращается к ним через определённые интервалы, вычисляет расхождение и вносит поправки.
Интересно, что современные NTP-клиенты обычно не переводят время скачком на несколько секунд вперёд или назад. Такой подход мог бы вызвать проблемы у приложений, баз данных и различных сервисов. Вместо этого система плавно ускоряет или замедляет ход часов до тех пор, пока расхождение не исчезнет.
Для большинства проектов подходят публичные источники времени, например:
pool.ntp.org 0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org
Также часто используют и альтернативные серверы от популярных компаний Google или CloudFlare:
time.google.com time.cloudflare.com
Существуют сервисы, где можно подыскать для себя сервер точного времени по странам и континентам.
Впрочем, в большинстве современных дистрибутивов список серверов уже настроен по умолчанию, а его ручное изменение обычно требуется только в корпоративных сетях или специфических инфраструктурах.
Что касается самого NTP-клиента, то сегодня чаще всего встречаются два варианта: systemd-timesyncd и chrony.
systemd-timesyncd входит в состав systemd, практически не требует настройки и хорошо подходит для обычных VPS, ведь синхронизация времени работает по умолчанию после установки ОС, как говорится - "из коробки".
Chrony считается более функциональным решением, так как он быстрее выходит на точное время после запуска, лучше переносит нестабильные сетевые соединения, умеет работать в роли собственного NTP-сервера и предоставляет больше возможностей для настройки. Поэтому его часто используют на нагруженных серверах, в виртуализированных средах и сложных инфраструктурах.
Для нашего случая с обычным VPS разница между этими инструментами редко бывает заметна невооруженным взглядом. Поэтому если ваш сервер обслуживает простой сайт, интернет-магазин, корпоративную почту или несколько простеньких контейнеров, то вполне достаточно стандартного systemd-timesyncd. А вот когда требуется максимально точная синхронизация или речь идёт о большом количестве серверов, тогда чаще выбирают Chrony.
Раз уж мы пишем исчерпывающую статью на тему настройки времени и его синхронизации в Linux системах, то давайте для полноты картины быстренько пробежимся по тому, как установить и использовать Chrony на Linux сервер.
В Ubuntu и Debian установка выглядит так:
apt update apt install chrony -y
В AlmaLinux, Rocky Linux и CentOS:
dnf install chrony -y
После установки службу нужно запустить и добавить в автозагрузку:
systemctl enable --now chronyd
Через несколько секунд можно проверить состояние синхронизации:
chronyc tracking
В выводе будет указано, с каким источником времени работает сервер, насколько велики отклонения и синхронизированы ли часы в данный момент.
Для диагностики пригодятся ещё несколько команд.
Список используемых серверов времени:
chronyc sources
Подробная статистика по каждому источнику:
chronyc sourcestats
Общая информация о состоянии синхронизации:
chronyc tracking
Эти команды часто помогают быстрее, чем просмотр логов. Особенно когда нужно понять, получает ли сервер актуальное время, какой источник выбран в качестве основного и нет ли заметного расхождения с эталонными часами. Снова таки, на VPS такое бывает редко, но после миграции виртуальной машины, проблем с сетью или длительного простоя проверка лишней точно не будет.
Отдельно стоит поговорить о настройках времени в такой большой части инфраструктурных решений, как Docker, ведь с ним у многих возникает путаница. Внутри контейнера действительно есть своё отображение времени, но собственных часов у него нет.
По умолчанию контейнер использует системное время хостовой машины, поэтому если на сервере неправильно настроен часовой пояс или не работает синхронизация через NTP, те же проблемы появятся и внутри контейнеров.
Проверить текущее время можно напрямую:
docker exec -it container_name date
Обычно результат будет совпадать со временем на хосте. Исключения встречаются редко и связаны, в основном, со специфическими настройками контейнера или подменой файлов временной зоны.
Из-за этого попытки исправить время внутри отдельного контейнера чаще всего не имеют смысла и причину стоит искать на уровне самого сервера. Достаточно настроить timezone и NTP на хостовой системе, после чего изменения автоматически затронут все контейнеры.
Особенно это актуально в обширных микросервисных инфраструктурах, где работает множество контейнеров отвечающих каждый за свой участок работы. Один контейнер пишет логи, другой обрабатывает очереди, третий работает с базой данных. И если время между ними расходится хотя бы на несколько минут, то поиск причин ошибок быстро превращается в сущий кошмар. А когда речь идёт о CI/CD, кластерах Docker или системах мониторинга, то корректное время становится уже не просто удобством, а технической необходимостью.
Итак, настройка времени на Linux-сервере обычно занимает несколько минут, поэтому ни в коем случае не стоит пренебрегать этим при первичной настройке сервера. Проблема в том, что если этого не сделать, то последствия ошибок могут всплыть через недели или даже месяцы, когда связь между причиной и симптомами уже не будет очевидной, что приведёт к длительной локализации причины проблем и её устранением.
Одной из самых частых ошибок в работе со временем является попытка исправить неточное время на сервере простой сменой часового пояса. Логика вроде-бы понятна: сервер показывает неправильные часы, значит нужно поменять timezone. Но на самом деле часовой пояс влияет только на отображение времени. Поэтому, если системные часы спешат или отстают, то настройка timezone ничего не исправит.
Ещё одна распространённая ошибка это настройка нескольких NTP-клиентов на одном сервере. Это может случиться после обновлений, миграций или экспериментов администратора, когда одновременно оказываются запущены, напримерchronyd, ntpd и systemd-timesyncd. Каждый из них пытается управлять временем по своим правилам. А в результате синхронизация может быть нестабильной, что выражается чаще всего в скачках времени.
Встречается и более простая ошибка. Или даже не ошибка, а халатность, когда NTP-клиент устанавливают, службу запускают, а проверить статус синхронизации забывают или не считают необходимым это делать. А потом выясняется, что сервер так и не смог подключиться к источникам времени из-за проблем с сетью, файерволом или неверной конфигурацией.
Поэтому всегда после основной настройки полезно потратить ещё минуту на финальную проверку:
timedatectl отображается System clock synchronized: yes;
Собственно, на этом и всё.
Для международных проектов UTC часто удобнее, а для небольших серверов можно использовать и локальный часовой пояс.
Для большинства VPS достаточно systemd-timesyncd. Ну а если нужна более точная синхронизация и расширенная диагностика, тогда выбирают Chrony.
Да. При серьёзном расхождении времени сертификат может определяться как недействительный или просроченный.
Обычно нет, так как контейнеры используют время хост-системы.
Автоматически и регулярно. Точная периодичность зависит от используемого NTP-клиента.
Сервер продолжит использовать текущее время, а после восстановления соединения синхронизация возобновится автоматически.
Настройка времени на сервере занимает буквально несколько минут, но зато она способна избавить вас от долгого поиска ошибок в будущем.
Правильный timezone помогает нормально читать логи и понимать, когда именно произошло то или иное событие. А NTP следит за точностью системных часов. Если всё настроено корректно, тогда cron задачи запускаются вовремя, SSL-сертификаты работают без сюрпризов, а журналы событий не превращаются в головоломку.
Поэтому после установки Linux-сервера время лучше настроить сразу. Это такая же базовая процедура, как настройка SSH-доступа, файервола или резервного копирования.
Веб-сайт — это структурированный набор веб-страниц, размещенных на сервере и доступных через интернет. В данной статье рассматриваются основные компоненты веб-с...
В прошлой статье мы рассмотрели несколько самых популярных операционных систем, которые обычно выбирают для установки на VPS серверы. А сегодня мы хотим познако...
Мир вокруг нас полон красок и образов, но порой бывает сложно запечатлеть их на бумаге или холсте. А что, если бы вы могли просто описать желаемую картинку слов...
Netdata позволяет быстро организовать мониторинг VPS без сложной настройки. Разбираем установку, основные метрики, мониторинг Docker, уведомления и сравнение с ...
Что такое reverse DNS (PTR), зачем он нужен и почему без него возникают проблемы с доставкой почты. Разбираем настройку PTR, проверку записей и типичные ошибки ...
Как перенести сайт WordPress на VPS без Docker или Kubernetes. Пошаговое руководство с использованием Nginx, MariaDB, HTTPS, советами по оптимизации и распростр...
