NOTMANAGED на диске: install-ng «прошёл», а блоксторов не прибавилось

Коротко. NOTMANAGED на диске — не «промежуточное состояние», а ловушка: инвентаризация ставит его, когда дискогруппы ещё нет в модели, а конфигурирование машин такие диски пропускает. Диск может висеть так неограниченно долго, install-ng -m при этом рапортует успех. Выход — привести дискогруппы в модель до инвентаризации, а застрявший диск вернуть в NOTCONFIGURED и прогнать configure заново.

Симптом

В модели у части дисков status = NOTMANAGED и role = null; число таких дисков не меняется между прогонами.
install-ng с флагами -m (и догон -a -AST -ASC -D -d) завершается, код возврата 0, в логах явной ошибки нет — но блоксторов не прибавилось.
mount | grep -c blockstore на ноде даёт меньше ожидаемого; df не показывает новые точки монтирования.
Колонка CONFIGURED, но resources пустые (или в витрине durability пусто), а S3 может отдавать 507 Storage is full при формально свободном месте — это следствие неразмеченной ёмкости.

Что проверить первым (read-only)

Модель — по mTLS, сертификаты продукта root-only, поэтому запросы на узле, root.

Сколько дисков в NOTMANAGED: bash sudo curl -sk --cert /opt/ampli/cfg/marvin/ssl/machine.cert \ --key /opt/ampli/cfg/marvin/ssl/machine.key \ "https://127.0.0.1:8443/model/machine/?fields=name,status" \ | jq -r '.["machine"][] | .name + " " + .status' Затем — диски конкретной машины (по её guid) с полями status, role, serial. Ожидается: дисков в NOTMANAGED 0; каждый диск имеет роль (os, meta, будущий blockstore).
Есть ли дискогруппы и в каком они состоянии: bash sudo curl -sk --cert /opt/ampli/cfg/marvin/ssl/machine.cert \ --key /opt/ampli/cfg/marvin/ssl/machine.key \ https://127.0.0.1:8443/model/diskgroup/ | jq '.["diskgroup"][] | {name, status}' Ожидается: дискогруппы существуют и не в NOTMANAGED. Их отсутствие или статус NOTMANAGED — причина петли.
Что на ноде фактически смонтировано: bash mount | grep -c blockstore ls -d /mnt/blockstore* 2>/dev/null | wc -l Ожидается: число точек монтирования равно ожидаемому для этой ноды. Ноль при «успешном» прогоне — прямое доказательство, что разметка не выполнялась.
Сколько блоксторов знает DSS (на узле, от marvin): bash /opt/ampli/apps/marvinbase/venv/bin/python -c " from dss_ng import blockstore as b from marvin_lib.application import get_port print(len(b.list_all(port=get_port('dssclientdaemon', porttype='management'))))" Ожидается число, кратное числу дисков под blockstore на всех нодах. Меньше — часть дисков не размечена.
Состояние колонки и барометра: bash /opt/ampli/bin/dss-ng-client-daemon -D 127.0.0.1 -p 11060 --barometer Ожидается ok. full при пустых resources — та же причина, вид с другой стороны.

Причина

Петля описана в самом продукте и воспроизводится по коду.

Шаг 1 — инвентаризация. Сканер оборудования ставит диску NOTMANAGED, если дискогруппа ещё не смоделирована или сама находится в NOTMANAGED:

if (model_diskgroup and model_diskgroup.get('status') == 'NOTMANAGED') or not model_diskgroup:
    current_disk['status'] = 'NOTMANAGED'

Комментарий вендора рядом объясняет мотив: так не «дёргаются» триггеры на стандартный NOTCONFIGURED у sled-дисков (внутренняя ссылка MCR-801). То есть поведение намеренное.

Шаг 2 — конфигурирование. Разметка дисков (machine.configure → авто-конфигурация дисков) работает по списку «состояний, которые не конфигурируются», и NOTMANAGED в этот список входит:

NOCONF_STATES = ('NOTMANAGED', 'NOTFOUND', 'DECOMMISSIONED', ..., 'INVALID', 'DISABLED')
for disk in self.disk:
    if disk.status not in NOCONF_STATES:
        disks.append(disk)

Дискогруппы нет → диск NOTMANAGED → из разметки исключён → роль не назначается → статус не меняется. Круг замкнулся, и «догон» -m его не разрывает.

Третий слой — фильтр машин. machine.configure берёт машины с фильтром status=NOTCONFIGURED. Если машина после частичного прогона осталась в CONFIGURING, configure её просто пропускает и рапортует успех, ничего не сделав. Это отдельная ловушка того же класса: «прогон прошёл» не значит «прогон что-то сделал».

Решение (штатное)

Порядок установки важнее команд: дискогруппы должны быть в модели до инвентаризации, а диск берётся в работу только в NOTCONFIGURED.

Убедиться, что дискогруппы смоделированы. Серийники дискогрупп выводятся из корпусного серийника (схема <SERIAL>_A, <SERIAL>_B); если они не сопоставятся с раскладкой, дискогруппа останется пустой, а диски — NOTMANAGED. Это проверяется до прогона, а не после.
Вернуть застрявший диск в рабочее состояние — документированный выход для уже испорченной установки: python for d in machine['disk']: if d['status'] == 'NOTMANAGED': cli.marvin.disk.update(d['guid'], status='NOTCONFIGURED') cli.marvin.machine.update(name, status='NOTCONFIGURED') Ожидается: в модели диск больше не NOTMANAGED, машина — NOTCONFIGURED.
Прогнать configure заново — тем же штатным install-ng с фазами configure (см. install-ng: фазы и флаги). Ожидается назначение роли диску и разметка.
Проверять результат фактом, а не кодом возврата: mount | grep -c blockstore, список блоксторов, barometer. Код 0 у установщика ничего не доказывает.

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

Не штатно, временная мера. В лабораторных условиях допускается инициализировать блокстор вручную (--init-blockstore с реальной ёмкостью --native-capacity, затем активация инициализированных блоксторов). Это обходит штатную разметку и годится только для проверки DSS на стенде: на площадке такой путь оставляет модель без ролей дисков, а ёмкость учитывается дважды при повторной инициализации того же пути.

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

Проверка

В модели дисков NOTMANAGED — 0; у каждого диска есть роль.
Дискогруппы существуют и не в NOTMANAGED.
mount | grep -c blockstore на ноде равно ожидаемому; ls -d /mnt/blockstore* совпадает.
Число блоксторов в DSS равно ожидаемому (кратно дискам под blockstore).
--barometer → ok; в колонке resources не пусто.
install-ng догон: подзадач в QUEUED нет, машины ONLINE.
S3 PUT/GET проходит, 507 не появляется.

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

Порядок: дискогруппы → инвентаризация → configure. Не наоборот; «догон» не исправляет пропущенный шаг модели.
Сверять серийники дискогрупп до прогона — Чек-лист подготовки к установке.
Приёмка по факту: диски с ролями, блоксторы, барометр, колонка. Код возврата — не приёмка.
Не путать с ложной тревогой DISK_NOT_FOUND — там чекер не видит диск, а здесь модель не берёт диск в работу; разборы разные, см. DISK_NOT_FOUND.
blockstore.id уникален в кластере. Перезапись идентификатора на живой системе создаёт вторую запись на том же пути, и ёмкость считается дважды — частая причина «лишних» блоксторов.

Источники и дата

Quantum, Software Documentation Center (ActiveScale 7.3): https://qsupport.quantum.com/kb/flare/Content/ActiveScale/Software/Content/Index_Files/Index_Software.htm (дата доступа: 2026-11-07).
Наша практика, обезличено: разбор петли NOTMANAGED на стенде — сканер ставил статус до появления дискогрупп, configure такие диски пропускал; выход через NOTCONFIGURED и повторный -m.
Обновлено: 2026-11-07.

NOTMANAGED на диске: капкан, а не статус