Диск вышел из строя: замена, decommission и ввод нового

1. Три типа дисков — три разных риска

Прежде чем что-то трогать, надо понять, что вы меняете. В системе три роли:

Проверить роль можно по метке и точке монтирования:

ls -la /dev/disk/by-label/ | grep -i blockstore
mount | grep -E 'blockstore|meta'
lsblk

Одиночный OS-диск вывести нельзя — продукт отвечает DecommissionNotAllowed. Исключение — корень в RAID-массиве (SLED): тогда диск выводится из массива и меняется как зеркало. Если OS-диск один, замена означает переустановку ноды, и это надо планировать как отдельную работу.

Мета-диск — самый опасный случай, потому что метастор держит кворум из трёх узлов. Вывод двух из трёх одновременно означает потерю кворума и остановку S3. Правило простое: по одному узлу.

2. Диагностика до извлечения (только чтение)

Порядок разбора — от «что это за диск» к «что с ним»:

cat /sys/block/<dev>/device/model; cat /sys/block/<dev>/device/serial
ls -la /dev/disk/by-id/ | grep <SERIAL>
smartctl -a /dev/<dev>
cat /proc/mdstat

smartctl смотреть на три поля: Reallocated_Sector_Ct, Current_Pending_Sector, UDMA_CRC_Error_Count. Рост первых двух — деградация носителя; рост CRC — чаще кабель или backplane, а не диск.

Дальше — сверка с моделью: статус диска и блокстора. Расхождение «в DSS ok, в модели документа нет» (или наоборот) — повод разбираться до замены, а не после. Статусы блокстора в DSS: ok, abandoned, offline, readonly, decommissioned, initialized. abandoned и зависший decommissioned — аномалия: это висячие ссылки, а не нормальный вывод.

3. Штатный путь: decommission → ожидание → замена → ввод

Шаг 1. Вывод диска. В GUI путь такой: Resources → Machine → Disk → Decommission. За кнопкой стоит операция decommissionDisk, она закрыта правом EXECUTE_DISKDECOMMISSION — у read-only роли кнопки нет. Подтверждение — модальное окно, потому что операция меняет раскладку.

Внутри продукт делает несколько вещей по порядку: снимает SMART и складывает его в evidence bundle (/tmp/smartctl-*), уведомляет подсистему диагностики (wait_for_diagnostics, причина — decommission), выводит разделы из RAID-массива, если диск в mdadm, и размонтирует партиции. Если диск держит shlam-связь в модели, её надо почистить — иначе алерты на мёртвый диск мешают операции.

Шаг 2. Дождаться перекладки. Вывод запускает DSS repair crawl: данные блокстора перекладываются на живые диски. Пока crawl не завершён, физическое извлечение — потеря данных. Признаки завершения:

• --repair-in-progress-any возвращает «нет»;
• прогресс вывода — 100 %.

Это самый долгий шаг, и он нагружает кластер: во время crawl растёт IO. Планировать замену лучше не в час пик по записи.

Шаг 3. Замена. Вынуть диск, вставить новый. Если диск был в RAID/SLED — сначала вывод из массива, иначе массив уходит в degraded.

Шаг 4. Ввод нового диска. Продукт делает это операцией provisionDisks (в GUI — разметка дисков стойки, параметры — datacenter и rack). Цепочка внутри: скан оборудования находит диск, ему назначается роль blockstore, ставится метка blockstoreA…, раздел монтируется в /mnt/blockstore*, поднимается DSS storage daemon на своих портах (12001/12201/12101), метаданные блоков уходят в arakoon.

Проверка после ввода: блокстор в статусе ok, маунт на месте, daemon поднят. Статус initialized или зависший offline — аномалия, диск не активирован.

4. Мета-диск: отдельный порядок

Замена мета-диска обрывается на середине, если новый раздел не смонтирован как отдельная файловая система в /mnt/meta4. Продукт разбивает диск, ищет подходящий mountpoint, и только после этого создаёт каталоги демонов (home, tlog_dir, log_dir, tlf_dir). Папка внутри другой ФС не считается — отсюда ошибка «No suitable Arakoon mountpoint found».

Порядок:

1. df -h /mnt/meta4, mount | grep meta4, ls /mnt/meta4/arakoon_* — что есть сейчас.
2. Вывести старый мета-диск; дождаться, что кластер пережил потерю узла (кворум 3→2).
3. Вставить новый, разбить.
4. Смонтировать раздел как отдельную ФС в /mnt/meta4, проверить, что места достаточно.
5. Перезапустить задачу замены; проверить, что каталоги созданы, а узел догнал кворум.

Ловушка единиц: порог места в конфиге задан в GiB, а в проверке участвует в MiB/KiB. При диагностике «нет места» сначала пересчитать, а потом верить сообщению.

5. Migration and Decommission (Disk Only) в 7.3

В 7.3 появился штатный сценарий вывода старого железа — не одного диска, а поколения: данные и метаданные переносятся на новое, задача идёт в фоне, для S3 и Glacier это прозрачно. Запускается не оператором, а сервисной командой вендора — это не «кнопка в GUI для самостоятельной замены».

Практический смысл: плановое обновление парка перестаёт быть «переустановкой с миграцией данных», но окно и порядок всё равно согласуются заранее.

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

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

Чек-лист перед физическим извлечением:

• [ ] диск не root (или в RAID);
• [ ] repair crawl завершён, прогресс 100 %;
• [ ] для мета-диска остаётся ≥ 2 из 3 узлов метастора;
• [ ] SMART старого диска сохранён;
• [ ] связь shlam почищена;
• [ ] подсистема диагностики в курсе (уведомление прошло);
• [ ] новый диск разбит, а для мета — смонтирован как ФС в /mnt/meta4.

Типовые стоперы: 423 LOCKED на configure (залипла задача — снять её, а не повторять запуск); 503 No replica set members match (транзиент клиента, повторить); ответ HTTP=000 на mTLS-запрос с ноды без sudo — сертификаты продукта root-only.

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

• Не выдёргивать диск «на всякий случай» до завершения crawl — это единственная операция в обслуживании, которая может стоить данных.
• Не выводить два мета-диска подряд: кворум не переживёт.
• Различать ложную тревогу DISK_NOT_FOUND (чекер неверно сопоставил SSD по buslocation) и реальный отказ: ложная лечится моделью, а не заменой.
• После замены сверять три источника: SMART, модель, DSS. Пока они не совпали, работа не закрыта.
• Планировать замену как окно: crawl нагружает кластер, а на время операции лучше не совмещать её с апгрейдом или расширением.

Источники

• ActiveScale Datasheet DS00546A — DDR, erasure coding, раскладка (2026-11-07)
• ActiveScale Software Release Notes — Migration and Decommission (Disk Only), upgrade consideration про decommission (2026-11-07)
• Наша практика (обезличено): разборы вывода диска, repair crawl и замены мета-диска на 3-нодных стендах.
• Обновлено: 2026-11-07.