Расхождение системного времени между серверами

Синхронизированное время на серверах баз данных имеет важное значение для распределённых баз данных. Если системные часы на серверах YDB будут сильно расходиться, это приведёт к увеличению задержек в распределённых транзакциях.

Симптомы и пороги

Основные проявления расхождения времени между узлами:

• Замедление распределённых транзакций — время выполнения может увеличиваться примерно на величину расхождения часов между узлами (узел с более «быстрыми» часами ждёт согласования с узлами с отстающими часами).
• Рост задержек и ошибок по таймаутам — при рассинхронизации возможны ложные срабатывания дедлайнов и таймаутов запросов.
• Проблемы с аутентификацией — при сильном сдвиге времени возможны ошибки из‑за несогласованности сроков действия токенов и проверок на стороне сервисов.

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

• Менее 1 миллисекунды — нормальный уровень для штатной работы кластера.
• 1 — 5 миллисекунд — зона, в которой уже имеет смысл искать причину рассинхронизации и усиливать наблюдение.
• Более 5 миллисекунд — критический уровень: требуется срочная диагностика и выравнивание времени.
• 25 миллисекунд и выше — нарастающая деградация производительности, пользователи получают массовые задержки и таймауты при выполнении распределённых транзакций.
• 30 секунд — распределённые транзакции перестают выполняться (см. ниже).

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

Более того, если отклонение во времени превысит 30 секунд, система YDB откажется обрабатывать распределённые транзакции. Перед тем как координаторы приступят к планированию транзакции, задействованные data shards определяют допустимый диапазон временных меток для транзакции. Начало этого диапазона — текущее системное время таблетки-медиатора, а конец определяет тайм-аут планирования в 30 секунд. Если системное время координатора выходит за пределы этого временного диапазона, он не может запланировать распределённую транзакцию, что приводит к ошибкам в таких запросах.

Диагностика

Чтобы диагностировать расхождение в системном времени серверов YDB, используйте следующие методы:

1. Используйте Healthcheck во Встроенном UI:

   1. Во Встроенном UI перейдите на вкладку Databases и нажмите на наименование базы данных.

   2. На вкладке Navigation убедитесь, что требуемая база данных выбрана.

   3. Откройте вкладку Diagnostics.

   4. На вкладке Info нажмите на кнопку Healthcheck.

      Если кнопка Healthcheck отображает статус MAINTENANCE REQUIRED, возможно, в кластере YDB возникли проблемы, например, расхождение системных часов. Все выявленные неполадки будут перечислены в разделе DATABASE под кнопкой Healthcheck.

   5. Чтобы увидеть диагностированные неполадки, раскройте раздел DATABASE.

      

      Проблемы с расхождением системного времени отображаются в разделе NODES_TIME_DIFFERENCE.

   Примечание

   Для получения дополнительной информации см. Health Check API

2. Откройте страницу Interconnect overview во Встроенном UI. По метрикам interconnect (в т.ч. связанным с рассинхронизацией часов между узлами) можно оценить масштаб проблемы вместе с общей картиной задержек и ошибок соединений.

   Примечание

   Увеличение расхождения системного времени по данным мониторинга интерконнекта (как отображаемым во Встроенном UI, так и собираемым через метрики кластера) может быть связано как с фактическим расхождением часов, так и с исчерпанием ресурсов в процессорном пуле интерконнекта, либо с перегрузкой сетевого оборудования.

3. Используйте такие инструменты, как pssh или ansible, чтобы выполнить команду (например, date +%s%N) на всех узлах YDB и отобразить значение системных часов.

   Важно

   На результаты будут влиять сетевые задержки между хостом, на котором запущены pssh или ansible, и хостами YDB.

   Если вы используете утилиты синхронизации времени, вы также можете запросить их статус вместо запроса текущих временных меток. Например:

   chronyc sources -v
   

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

Рекомендации

1. Вручную синхронизируйте системные часы серверов, на которых работают узлы YDB. Например, используйте pssh или ansible, чтобы выполнить команду синхронизации часов на всех узлах.

2. Убедитесь, что системные часы на всех серверах YDB регулярно синхронизируются с помощью ntpd, chrony или аналогичного инструмента. Используйте один и тот же логический источник времени (одинаковый набор NTP-серверов или иерархию NTP) для всех серверов в кластере YDB, и подключите несколько независимых NTP-источников.

Примеры конфигурации NTP

Ниже — примеры настроек для chrony. Список серверов замените на актуальный для вашей среды и политики безопасности.

chrony (/etc/chrony/chrony.conf):

server ntp1.example.net iburst
server ntp2.example.net iburst
server ntp3.example.net iburst
server ntp4.example.net iburst
maxslewrate 10000
local stratum 10

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

Настройте оповещения по расхождению времени между узлами и по связанным симптомам (в том числе по данным встроенного UI и внешнего мониторинга). Ориентиры по порогам см. в разделе «Симптомы и пороги».

Аварийное восстановление

При критическом расхождении времени может потребоваться принудительная синхронизация на узлах (выполняйте осознанно и по согласованной процедуре для вашего кластера):

# Пример для chrony: остановка службы и однократная подстройка
sudo systemctl stop chrony
sudo chronyd -q 'server ntp1.example.net iburst'
sudo systemctl start chrony

Рекомендуемый порядок действий на кластере:

1. Убедиться, что используются корректные и доступные NTP-серверы.
2. Выровнять время на всех узлах (без рассогласования конфигурации между узлами).
3. Проверить сходимость времени через Healthcheck и мониторинг.
4. Зафиксировать причину сбоя синхронизации (сеть, DNS, блокировки исходящего NTP и т.д.).

Профилактика

• Регулярно проверяйте метрики и отчёты Healthcheck на предмет роста расхождения времени.
• Периодически проверяйте отказоустойчивость цепочки синхронизации (несколько NTP-серверов, доступность порта UDP 123 при необходимости).
• Держите конфигурацию используемого клиента NTP согласованной на всех узлах кластера.