NTP и время: почему S3 отдаёт 403 при зелёном GUI

1. Время — часть API, а не «мелочь»

В SigV4 клиент подписывает запрос, включая дату и время. Шлюз пересчитывает подпись своим временем и сравнивает. Допустимое расхождение — ±15 минут. Дальше — 403, и текст ошибки прямо говорит про разницу времени между запросом и текущим моментом.

Коварство в том, что ломается только внешний доступ:

• узел жив, пингуется, отвечает по SSH;
• модель показывает ONLINE, событий про железо нет;
• внутренние запросы с самой ноды проходят 200;
• клиент не может даже получить листинг бакетов.

Отсюда типовой тикет: «S3 не работает, но система зелёная». Первое, что нужно проверить, — часы, а не сертификаты и не политики.

2. Откуда ноды берут время

• При установке ноды временно выставляют дату и время вручную; после настройки NTP они синхронизируются с указанным сервером. Связь с NTP-сервером должна быть активной постоянно.
• Штатное место настройки — Configuration > System > Network > NTP Server. Можно задать до трёх NTP-серверов на площадку.
• Вендор рекомендует внутренние NTP-серверы: публичные часто rate-limited, недоступны или закрыты firewall, что даёт ложные алерты и потерю контроля над временем.
• На многосайтовых системах разные NTP-серверы для разных площадок должны быть точно синхронизированы между собой.
• В кластере ноды дополнительно синхронизируются между собой (кластерные peer'ы в конфиге ntpd). Это не замена внешнему источнику, а страховка внутри кластера.

Практическое следствие: «NTP настроен» — не то же самое, что «время верное». Настроенный сервер может быть недоступен, а ntpd при этом формально запущен.

3. Проверка за минуту (read-only)

Выполнять на каждой ноде, сравнить результаты между нодами.

1. Текущее время и зона: bash date -u Ожидается UTC и расхождение между нодами в секунды, а не в минуты.

2. Синхронизация: bash timedatectl | grep synchronized Ожидается System clock synchronized: yes и корректный NTP service: active.

3. Источник и стратум: bash ntpq -p Ожидается строка с * (выбранный источник) и стратум меньше 16. Пустой список или стратум 16 — синхронизации нет.

4. Состояние самого демона: bash ntpq -c rv Ожидается leap_none, sync_ntp, ненулевой stratum, offset в пределах миллисекунд.

5. Кто слушает 123/udp: bash ss -lunp | grep ':123 ' Ожидается процесс ntpd на UDP 123.

6. Служба и подозрительные артефакты DHCP: bash systemctl is-active ntp pgrep -a dhclient ls -l /run/ntp.conf.dhcp 2>/dev/null Ожидается active, отсутствие dhclient и отсутствие /run/ntp.conf.dhcp. Если файл есть — ntpd мог быть перезапущен с конфигом от DHCP, без кластерных peer'ов.

7. Что видит клиент снаружи (с рабочего места, не с ноды): bash curl -sk -o /dev/null -w '%{http_code}\n' https://<DOMAIN>/ Ожидается 307 и заголовок Server: Quantum-ActiveScale. 403 на подписанном запросе при живом фронте — почти всегда время.

4. Почему часы уезжают

Механизм 1. Конфиг от DHCP. Если на ноде остался dhclient на порту без линка, каждое продление аренды через стоковый хук ОС пишет /run/ntp.conf.dhcp и перезапускает ntpd с этим файлом. В нём нет кластерных peer'ов — остаётся единственный внешний источник, который может быть недоступен. Время начинает уезжать, и подмена возвращается после каждой аренды.

Механизм 2. Нет источника. NTP-серверы заданы, но недоступны (ACL, firewall, сеть площадки). ntpd работает, стратум 16, часы идут по внутреннему генератору и постепенно расходятся.

Механизм 3. Старт раньше сети. После полной потери питания нода поднимается быстрее, чем появляется связь с NTP. До синхронизации время живёт своей жизнью; если сеть не вернулась — расхождение остаётся.

Механизм 4. Ручная правка без последующей сверки. Кто-то выставил дату «примерно», не проверив источник. Формально «время есть», фактически — сдвиг.

Во всех случаях модель и GUI не показывают время. Диагностический признак один: сверить date -u по нодам и с клиентом, который получает 403.

5. Штатное восстановление

1. Проверить настройку в GUI: Configuration > System > Network > NTP Server. Убедиться, что указаны внутренние серверы площадки (до трёх) и они доступны из сети управления.
2. Убедиться, что NTP-серверы действительно отвечают с этой ноды. Проверка доступности UDP 123 до сервера — задача сетевой команды, а не продукта.
3. Привести ntpd к штатному конфигу, если на ноде есть подмена от DHCP: bash sudo systemctl stop ntp sudo rm -f /run/ntp.conf.dhcp sudo systemctl start ntp Это перезапуск штатной службы с штатным /etc/ntp.conf; удаляется только файл, созданный хуком DHCP.
4. Убрать причину подмены. Остановить и выключить службу, которая держит фантомный dhclient на порту без линка (systemctl disable --now <DHCP_SERVICE>), и снять процесс из cgroup службы. Без этого шага шаг 3 даёт эффект до следующей аренды.
5. Проверить результат (раздел 6) и повторить проверку через несколько минут — подмена не должна вернуться.

Если штатный путь недоступен

Если NTP-серверов площадки нет и внешние недоступны, временная мера — выставить время вручную на всех нодах по одному источнику (например, по часам шлюза) и сразу зафиксировать расхождение. Это не штатно: при следующей перезагрузке или аренде DHCP время снова уедет. План замены — настроить внутренний NTP-сервер и внести его в GUI. Ручную правку без записанного источника времени не применять: потом невозможно доказать, чьи часы были верны.

6. Проверка после правки

• date -u на всех нодах — расхождение в секунды.
• timedatectl | grep synchronized → yes.
• ntpq -p → есть *, стратум меньше 16, видны кластерные peer'ы.
• ntpq -c rv → leap_none, sync_ntp.
• pgrep -a dhclient → пусто; /run/ntp.conf.dhcp отсутствует.
• S3-листинг бакета <BUCKET> клиентом → 200.
• События, поднявшиеся из-за времени (TASK_FAILED, MONA_DOWN, MACHINE_DOWN), больше не появляются.

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

• Внутренний NTP на площадке: до трёх серверов в GUI, все — в доступной сети управления.
• Запрет на фантомный DHCP на провижиненных нодах: служба выключена, процесс снят, конфиг не переписывается.
• Полевой health-check (у нас — скрипт только на чтение, ~30 секунд) проверяет время, наличие * в ntpq -p, отсутствие dhclient и разброс часов по нодам. Это дешевле, чем разбирать 403 от клиента.
• В регламенте обслуживания — сверка времени после каждого отключения питания и после апгрейда.
• Не полагаться на «GUI зелёный»: у статуса узла нет поля «время».

8. Границы: что не считать причиной

• Совпадение событий по времени — не цепочка. OOM_KILLER, DISK_NOT_FOUND и MONA_DOWN в одном окне — разные классы; связывать их без эмиттера нельзя.
• Не объявлять «сбой NTP-сервера» без доказательства. Если журнал ноды пуст, точный момент и источник скачка не восстановить — фиксировать факт расхождения, а не выдуманную причину.
• Сдвинутые часы дают картину сетевой аварии. Нода со старым штампом времени может выглядеть как MACHINE_DOWN/NIC_NOT_FOUND при целом кабеле. Порядок разбора обратный интуиции: сначала часы, потом сеть.
• 403 бывает и не из-за времени. Подпись, ключи, resource policy, TLS — отдельные классы; проверка времени отсекает только один из них.

Источники

• Quantum, Manage System Settings (дата доступа 2026-11-07): NTP-серверы, до трёх на площадку, рекомендация внутренних источников, выставление времени при установке.
• Наша практика (обезличено): 403 у всех внешних клиентов при зелёном GUI на кластере из трёх нод; причина — конфиг ntpd от DHCP без кластерных peer'ов.
• Обновлено: 2026-11-07.