Как часто обслуживать ActiveScale и что именно проверять

1. Что продукт делает без оператора

Регламент имеет смысл только там, где продукт не закрывает вопрос сам:

• DDR (Dynamic Data Repair). Фоновый мониторинг, проверка целостности и самовосстановление раскладки — без ожидания физической замены диска (datasheet).
• DSS-верификация блоксторов. Отдельный фоновый процесс сверяет экстенты; интервал задаётся параметром DSS --verification-interval.
• Чекеры mona. Сверяют модель с железом (диски, NIC, вентиляторы, PSU, службы) и поднимают события. В нашей конфигурации цикл — 600 секунд, то есть событие закрывается само в пределах ~10 минут после устранения причины.
• Планировщик задач. logs_pruner, column_bucket_update, reconcile_federateddata включаются в конце успешного прогона install-ng; чистка старых задач идёт по retention_config документа environment.
• Лента. Проверка коннектора идёт своим циклом (в наших наблюдениях — примерно раз в 4 часа), safety пересчитывается раз в час. Кассета, числящаяся отсутствующей дольше заданного окна (у нас — 96 часов), снимается с учёта автоматически, если «пропавших» не больше порога max_tape_allowed.

Значит, регламент оператора — про то, что автоматика не видит: расхождение часов, внешний доступ по S3, свободное место, деградацию, которая ещё не стала событием.

2. Периодичность: таблица работ

Периодичность ниже — рекомендация практики, а не вендорский SLA.

Продукт предупреждает об истечении SSL-сертификата за 6 месяцев (7.1) — это не отменяет ежемесячного взгляда: письмо легко пропустить.

3. Ежедневный минимум — 30 секунд

Полевой health-check — скрипт только на чтение, ничего не ставит и не меняет:

sudo bash as-field-health.sh

По нескольким нодам с рабочей станции:

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

Снаружи, как видит клиент:

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

Код выхода 0 — нет [FAIL]; 1 — есть. [warn] сам по себе прогон не валит, но это повод посмотреть руками. Что именно проверяется и какие значения ожидаются — в статье Полевой health-check за 30 секунд.

Параллельно — события за сутки. При работающей автоматике LIVE-список почти пуст; долгоживущее LIVE-событие почти всегда означает неустранённую причину, а не «глючный чекер».

4. Недельный срез: ёмкость, диски, лента

Ёмкость. Смотреть динамику, а не абсолют: 85 % — не авария, но дальше растёт вероятность, что ремонт и архивация начнут конкурировать за место. Заполнение блоксторов — сигнал на расширение или на перенос части данных в холодный тир.

Диски. Три источника надо сверять между собой: SMART (smartctl -a), события модели (DISK_*, DISK_NOT_FOUND) и статус блокстора в DSS. Расхождение «в DSS ok, в модели нет документа» — повод разбираться сразу. DISK_NOT_FOUND бывает ложной тревогой чекера (SSD, buslocation) — отдельный класс, который нельзя лечить выдёргиванием диска.

Лента. Смотреть minimum_tape_safety и число записей в missing_tape_media. Ноль safety — не «предупреждение», а отсутствие резервной копии в ленточном тире; разбор — в статье Кассеты и штрихкоды.

Задачи. /model/task/ без limit тяжёлый — фильтровать по статусу. Задача в STARTED, висящая часами, блокирует следующую операцию (423 LOCKED на configure) и требует решения, а не повторного запуска.

5. Месяц: конфигурация, сертификаты, «долгожители»

Бэкап конфигурации. Модель — источник истины, из неё рендерятся конфиги. Копию снимать до любых изменений и хранить вне каталога продукта. Правило: если бэкап нельзя прочитать и сравнить, его нет. См. Бэкап конфигурации и модели.

Сертификаты. Проверять срок и цепочку. Ловушка: сертификат без SAN работает только с отключённой проверкой TLS — это дефект конфигурации, а не «настройка клиента».

События-долгожители. Раз в месяц пройти по событиям, висящим неделями: часть — ложные тревоги платформы (FAN/PSU/NIC), часть — реальные, но «привычные». Привычных быть не должно: каждое либо закрывается, либо документируется как принятый риск.

Часы. Дрейф часов — самая недооценённая причина «S3 не работает, а GUI зелёный». Окно подписи SigV4 — ±15 минут: этого достаточно, чтобы отбивать всех внешних клиентов, при этом нода остаётся ONLINE. Раз в месяц — сверить ntpq -p и разброс по нодам, а не только «служба запущена».

6. Квартал: политика, restore, апгрейд-путь

Политика DSS. Проверить w+s ≤ N при текущем числе блоксторов и что selectedstoragepolicy не null. Политика, которая «влезает ровно», запаса не имеет: первый отказ диска останавливает запись с 507. Смена политики не форматирует диск — она меняет схему вновь записываемых экстентов, старые объекты остаются читаемыми.

Restore. Холодный тир без проверенного restore — надежда, а не архив. Раз в квартал восстанавливать по одному объекту из Glacier: код ответа, размер, контрольная сумма. Заодно проверяется, что кассеты на месте и очередь не забита.

Апгрейд-путь. Сверить сборку с релиз-нотами: с какой версии разрешён апгрейд, какие обходы применены и надо ли их снять. Даунгрейда нет — решение принимается до, а не после. См. Планирование апгрейда OS.

7. Журнал обслуживания

Регламент без записи превращается в ритуал. Минимальные поля: дата, что проверяли, команда/экран, полученное значение, кто смотрел, что сделали. Полезно фиксировать и «норму» на момент проверки — тогда отклонение видно сразу.

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

8. Чего в регламенте быть не должно

• Правки вендорского кода «на всякий случай». Каждая — афтер-фикс после апгрейда и отклонение от поддержки.
• Инъекция ёмкости руками. 507 при свободных дисках — смоделированная ёмкость; лечится политикой и прогоном install-ng, а не записью в модель.
• Оптовые операции с кассетами. media unused --delete пачкой и удаление кассеты из библиотеки, пока она заведена в продукте, ведут к «пропавшим» кассетам и нулевому safety.
• Выдёргивание диска до завершения repair crawl. Единственная операция регламента, которая может стоить данных.
• Перезапуск marvinservices целиком ради одной службы: вместе поднимаются samurai и haproxy, узел может уйти в красное.

Источники

• ActiveScale Datasheet DS00546A — DDR, DDP (2026-11-07)
• ActiveScale Software Release Notes — апгрейд-пути, SSL за 6 месяцев, лента (2026-11-07)
• Наша практика (обезличено): health-check ~30 с, разборы по времени/NTP, ленте и дискам на 3-нодных стендах.
• Обновлено: 2026-11-07.