Узел живой? Полевой health-check за 30 секунд

Коротко. Полевой хелпер as-field-health.sh за ~30 секунд отвечает на вопрос «узел живой, время верное, S3 отвечает, ничего не отвалилось». Скрипт только читает: время и NTP, призрачный DHCP, ответ S3-фронта, haproxy, маунты блоксторов, службы. Норма — код выхода 0 и ни одного [FAIL]; 307 от фронта и * в ntpq -p — те значения, которые надо увидеть глазами.

1. Зачем отдельный скрипт

GUI показывает статус узла, но не показывает время. Поэтому самая частая авария выглядит так: всё зелёное, а внешние клиенты получают 403 на каждый запрос. Нода при этом ONLINE, внутренние запросы с неё самой проходят 200 — и оператор идёт смотреть сеть и ключи, хотя причина в часах.

Второй класс — «фронт отвечает не тем». Клиент говорит «S3 не подключается», а на самом деле не проброшен порт, не резолвится bucket-стиль имени или haproxy поднялся в двух экземплярах.

Поэтому проверки в хелпере подобраны по конкретным разборам, а не «для полноты»:

Проверка	Из какого класса проблем выросла
время и синхронизация NTP	часы уехали → `403` всем клиентам при зелёном GUI
ntpd не с `-c /run/ntp.conf.dhcp`	конфиг от DHCP = без кластерных peer'ов
нет `dhclient`, нет `/run/ntp.conf.dhcp`	фантомный DHCP на порту без линка
S3-фронт отвечает `307` и `Server: Quantum-ActiveScale`	«клиент не подключается» — начинать с фронта
haproxy: конфиг валиден, процессы живы	битый конфиг / лишние экземпляры держат 80/443
маунты блоксторов и заполнение ≥ 85 %	ёмкость и диски
службы `marvinservices`, failed units	общее здоровье узла

Скрипт — наш полевой инструмент, не часть дистрибутива продукта. Ничего не устанавливает и не меняет состояние.

2. Три режима запуска

На самой ноде (оператор копирует файл и запускает):

sudo bash as-field-health.sh

По нескольким нодам с рабочей станции (нужен ssh-доступ и sudo без пароля):

SSH_OPTS="-i ~/.ssh/id_rsa" as-field-health.sh \
    -n <NODE_IP> -n <NODE_IP> -n <NODE_IP>

При двух и более нодах скрипт дополнительно печатает блок «clock spread across nodes» — время на всех нодах в одну строку. Расхождение видно без арифметики.

Снаружи, как видит клиент (DNAT + DNS):

bash as-field-health.sh --s3 https://<DOMAIN>

Переменные: FIELD_USER (по умолчанию sysadmin), SSH_PORT, SSH_OPTS.

3. Как читать вывод

Три метки:

[ok] — значение в норме;
[warn] — повод проверить, но не поломка (сам по себе прогон не валит);
[FAIL] — то, что надо смотреть руками.

Код выхода: 0 — нет [FAIL]; 1 — есть хотя бы один. Итоговая строка — == summary: FAIL=… WARN=….

Типичный вывод здорового узла после устранения расхождения часов:

  [ok]   NTP synced: … leap_none, sync_ntp … selected: *_gateway st=2
  [ok]   S3 front (localhost) -> 307, Server=Quantum-ActiveScale
  [ok]   blockstore mounts: 4
  [ok]   no failed systemd units

4. Ожидаемые значения

Проверка	Норма	Что означает отклонение
`ntpq -c rv`	содержит `sync_ntp`/`clock_sync`	часы не синхронизированы → ждите `403`
`ntpq -p`	есть строка с `*`, стратум < 16	нет выбранного источника
`timedatectl`	`synchronized: yes`	флаг systemd-timedated; при живом ntpd бывает `no`
`ps -eo args \\| grep '[n]tpd'`	без `-c /run/ntp.conf.dhcp`	DHCP подменил конфиг, peer'ы потеряны
`pgrep -x dhclient`	`0`	фантомный DHCP на порту без линка
`/run/ntp.conf.dhcp`	отсутствует	DHCP перекрывает вендорский NTP
`marvin-dhcp.service`	`inactive/disabled`	на провижиненной ноде должен быть выключен
`haproxy -c -f …`	`Configuration file is valid`	битый конфиг шлюза
`pgrep -x haproxy`	≥ 1	фронт S3 не поднят
`curl -s -o /dev/null -w '%{http_code}' http://localhost/`	`307`	`200`/`403` без авторизации — warn; пусто — фронт молчит
то же на `localhost:8080`	`307`	приватный фронт не отвечает
`mount \\| grep -c blockstore`	≥ 1	блоксторы не смонтированы
`df -h` по `/mnt/blockstore*`	< 85 %	выше — warn, риск для ремонта и архивации
`/etc/init.d/marvinservices status`	нет `is not running`	служба узла не поднята
`systemctl --failed`	`0`	есть падающие юниты

307 — нормальный ответ фронта на запрос без бакета: это редирект на bucket-style имя, а не ошибка. Заголовок Server: Quantum-ActiveScale подтверждает, что ответил продукт, а не прокси.

5. То же руками, без скрипта

Если хелпера под рукой нет, минимум воспроизводится четырьмя командами:

date -u; timedatectl | grep -i synchronized
ntpq -p                      # ищем '*' и стратум
curl -si http://localhost/ | head -5
df -h | grep blockstore

Плюс ip route | grep default — на ноде должен быть маршрут по умолчанию. Его отсутствие означает, что узел жив только в своей подсети: маршрут рендерится из документа NIC в модели, и если записи там нет, gateway в конфиг не попадёт.

6. Снаружи: что видит клиент

Режим --s3 печатает код и заголовки ответа, затем проверяет, резолвится ли bucket-стиль имя (probe-bucket.<DOMAIN>).

307 — фронт доступен и отвечает как S3;
200/403 — фронт доступен, код зависит от запроса;
пусто — нет ответа: смотреть DNAT, порт и DNS;
bucket-стиль не резолвится — клиенту с virtual-hosted-стилем нужен path-style либо wildcard-DNS.

Порядок разбора, когда «клиент не подключается», а по узлам всё ok: (1) какие порты реально проброшены и на какой внутренний адрес; (2) отвечает ли эндпоинт (режим --s3); (3) резолвится ли bucket-стиль. Сертификат при этом может быть wildcard — ограничение бывает именно в DNS, а не в продукте.

7. Чего скрипт не видит

Хелпер сознательно узкий. За его границами остаются:

модель — статусы машин, колонок, приложений (/model/machine/, /model/column/);
DSS — барометр и заполнение неймспейсов (cli.dss.capacity.read_barometer() должен быть ok);
лента — safety, «пропавшие» кассеты, состояние коннектора;
федерация — GET /federated/_status/ (норма 200 и меньше 50 мс);
события — только то, что чекеры уже подняли в модель.

Эти проверки — отдельные, и в ежедневный 30-секундный прогон не входят. Их место — недельный и месячный срез регламента.

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

Держать хелпер и его версию в одном месте, чтобы у оператора и у инженера был одинаковый набор проверок.
После любой аварии питания или сети — прогонять полный набор по всем нодам, а не по «виноватой».
Не оставлять marvin-dhcp.service включённым на провижиненной ноде: подмена NTP возвращается на каждой аренде DHCP, и удаление файла /run/ntp.conf.dhcp помогает лишь до следующего продления.
Проверять время до того, как проверять ключи и политики: 403 при зелёном GUI почти всегда часы.
Фиксировать результат прогона в журнале обслуживания — иначе «было ок» ничем не подтверждается.

Источники

ActiveScale Software Documentation Center (2026-11-07)
Наша практика (обезличено): хелпер as-field-health.sh, прогоны на 3-нодных стендах; разбор расхождения часов, призрачного DHCP и ответов S3-фронта.
Обновлено: 2026-11-07.