Апгрейд ActiveScale OS: с какой версии можно, как проверить и почему назад нельзя

1. Разрешённые пути

Два вывода из таблицы. Первый: путь «через версию» — норма, а не перестраховка: если система стоит на 6.5, до 7.3 одним шагом не дойти. Второй: сборка и версия — разные вещи, при сверке с релиз-нотами нужны обе.

Сверить текущую версию и доступные образы можно в GUI: раздел Upgrade показывает историю версий и доступные образы; те же данные отдаёт getAvailableUpgradeVersions.

2. Три правила, которые не обсуждаются

1. Апгрейд на 7.3 — только с 7.1+. Более старые сборки сначала доводятся до 7.1.
2. Pre-upgrade health check должен быть без проблем. Не «в целом ок», а без незакрытых критичных пунктов. Если проверка показывает замечания — сначала лечится система, потом апгрейд.
3. Даунгрейда нет. Это указано во всех релиз-нотах. Значит, апгрейд — односторонняя операция, и всё, что может понадобиться откатить, должно быть сохранено до него.

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

3. Что меняется по версиям (то, что важно эксплуатации)

• 7.1. IAM conditions и переменные политик; ranged restore из Glacier; автоматический scale-out через GUI. Безопасность: закрыты CVE-2023-44487 и CVE-2023-48795; предупреждение об истечении SSL за 6 месяцев. По ленте: невалидный штрихкод даёт событие COLD_STORAGE_INVALID_BARCODE_DETECTED.
• 7.2. ОС переходит на Ubuntu 20.04 LTS; обновление платформ X200/P200 (SuperMicro X12); Z200 — новые 10/25GbE NIC. Появляется MFA (TOTP) для администраторов в UI/CLI/REST. Cold Storage: restore быстрее более чем в 5 раз, ремонт ленты +35 %. Исправления: multipart с x-amz-storageclass, IAM на scaled-out нодах.
• 7.3. Migration and Decommission (Disk Only) — вывод старого железа с переносом данных; Tape Space Reclamation — повторное использование ёмкости кассет; LTO-10; Multi-Path Failover; Cold Storage QoS; S3-checksums (CRC32/CRC32C/SHA-1/SHA-256). Безопасность: веб-интерфейс Tape Connector требует аутентификации, митигация Mongobleed (CVE-2025-14847), отключены устаревшие key-exchange (CVE-2002-0001).

Для эксплуатации главное здесь — не только новые функции, но и изменения поведения: метрики S3 в Prometheus в 7.3 перестроены (лейблы и единицы), поэтому кастомные дашборды после апгрейда могут показывать не то. Это проверяется сразу после окна, а не «когда дойдут руки».

4. Pre-upgrade проверка (только чтение)

Минимальный набор до окна:

1. Полевой health-check по всем нодам → код выхода 0, ни одного [FAIL]. См. Полевой health-check за 30 секунд.
2. Время. ntpq -p — есть *, стратум < 16; разброс по нодам минимальный. Апгрейд с разъехавшимися часами — плохая идея: часть шагов завязана на время.
3. Федерация. GET /federated/_status/ с каждой ноды → 200 и меньше 50 мс (не 30 секунд).
4. DSS. Барометр ok; все неймспейсы в статусе ok; selectedstoragepolicy не null; w+s ≤ N.
5. Задачи. Нет зависших задач в STARTED и незакрытых REVOKED; блокировка 423 LOCKED снята. Планировщик в рабочем состоянии (enabled у штатных задач).
6. События. Список LIVE разобран: критичные закрыты, ложные — задокументированы.
7. Диски и лента. Нет идущего repair crawl; кассеты в реестре в правильной форме; safety больше нуля.
8. Сертификаты. Срок действия не истекает в окне апгрейда.
9. Бэкап. Модель и конфигурация сохранены вне каталога продукта и проверены чтением.

5. Порядок работ

Апгрейд идёт через GUI: раздел Upgrade → загрузка образа (upload firmware) → запуск (performSystemUpgrade) → прогресс и страница Jobs. За ходом следить там же, а не по косвенным признакам: длительность шагов на разных платформах разная.

Общие правила окна:

• Окно обслуживания. Даже при rolling-подходе (вендор заявляет непрерывные rolling-апгрейды) часть шагов переконфигурирует ноды, и S3-клиенты могут увидеть кратковременные ошибки. Окно согласуется с заказчиком заранее, вместе с планом «что делаем, если».
• По одной ноде. Не запускать параллельные операции на других нодах: расширение, замену диска и апгрейд не совмещать.
• Не трогать marvinservices целиком во время работ: перезапуск поднимает samurai и haproxy, и узел может уйти в красное независимо от апгрейда.
• Фиксировать состояние до и после: версия, сборка, список применённых обходов, показания барометра, состояние кассет.

6. После апгрейда

Проверки, которые надо пройти до закрытия окна:

Отдельно: в релиз-нотах 7.0 указан upgrade consideration — в первые дни после апгрейда возможен всплеск decommission дисков из-за нового алгоритма. Это работа алгоритма, а не отказ железа; не начинать срочную замену дисков, не разобравшись.

7. Откат и план «Б»

Отката нет. Поэтому план «Б» строится не на возврате версии, а на сохранении состояния:

• бэкап модели и конфигурации, снятый до окна;
• список обходов с точными путями и версиями файлов;
• доступ к поддержке вендора в окне (часть изменений — митигации CVE и изменения key-exchange — требуют её участия);
• согласованный с заказчиком порядок действий при деградации: что считаем поводом остановить работы, кого вызываем, что сообщаем клиентам S3.

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

• Сверять релиз-ноты раз в квартал: путь апгрейда может измениться раньше, чем закончится поддержка текущей версии.
• Держать систему в состоянии, которое пройдёт pre-upgrade проверку без ремонта на месте: закрытые события, живые часы, корректная политика DSS.
• Не накапливать обходы: каждый обход — это долг, который придётся закрыть в окне апгрейда.
• Фиксировать версии в журнале обслуживания по нодам, а не «по памяти»: рассинхрон сборок между нодами — отдельная проблема.

Источники

• ActiveScale Software Release Notes — версии, апгрейд-пути, даунгрейд, изменения 7.1–7.3 (2026-11-07)
• Software Documentation Center (2026-11-07)
• Z200 Datasheet — rolling-апгрейды, ОС 7.x (2026-11-07)
• Наша практика (обезличено): подготовка и приёмка апгрейдов на 3-нодных стендах, разборы влияния на федерацию и ленту.
• Обновлено: 2026-11-07.