Восстановление деградированного пула

Деградированный пул работает, но потерял избыточность: следующий отказ диска в той же группе устройств стоит данных. Задача сценария одна — вернуть избыточность, ничего не потеряв по дороге. Скорость здесь важна, но последовательность важнее: неверно опознанный диск превращает аварию в потерю.

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

Источник	Где доступен	Что даёт	Когда использовать
Живой опрос узлов	Только через API	Дерево пулов и устройств с состоянием каждого элемента	Подтвердить аварию, найти отказавший диск
Свойства пула глазами ZFS	Карточка пула, раздел Properties	Ёмкость, заполненность, эффективность, обслуживающий узел	Разобраться в свойствах конкретного пула
База vStack Center	Storage Resources, таблица ZFS pools	Состояние, заполненность, признаки восстановления и проверки	Понять, идёт ли восстановление и хватит ли места

Живой опрос без указания узла спрашивает все узлы кластера сразу и собирает ответы в один список. Частичный ответ допустим: недоступный узел приходит отдельной записью с состоянием UNAVAILABLE и не роняет весь опрос. Отсюда важное правило чтения: «узел не ответил» и «пул сломан» — разные события, и путать их нельзя.

Восстановление избыточности выполняется той же операцией, что и плановая замена: пул переводится на диск-донора, дальше идёт ресинхронизация. Защита от потери данных работает и в аварии — vStack Center опрашивает узел о доноре и отправляет команду только если донор свободен. Неизвестное состояние донора трактуется как отказ.

Операции с физическими дисками, кроме подсветки, в веб-интерфейсе не представлены: живой опрос пулов, опрос роли диска, метку запасного, замену и снятие диска с кластера выполняет администратор через API — см. Справочник API.

Предусловия

• роль Cluster master (role_id=1) — её требуют операции с физическими дисками и чтение пулов кластера;
• признак feature.physical_disc_management — без него закрыта дисковая подсистема: живой опрос пулов, список дисков, замена, метка запасного и подсветка;
• диск-донор в том же узле, где деградировал пул: свободный или запасной. Донор из другого узла не подойдёт;
• в этом пуле не идёт другая замена: одна замена на пул за раз;
• версия vStack Center — 3.0.5.

Шаг 1. Подтвердить деградацию

Первым делом убедитесь, что деградация реальна, а не отставание базы.

1. Откройте Provider Data Center → Storage Resources. Таблица ZFS pools несёт колонки GUID, Name, Health, Consuming, Scrubbing, Resilvering, Current node и Capacity (RAW). Нездоровый пул виден по колонке Health.

2. Запросите живой опрос пулов через API. Опрос только читает, повтор безопасен, и он отвечает на вопрос, который экран не закрывает: какое устройство внутри пула отказало.

3. Прочитайте ответ как дерево, свёрнутое в список.

   Уровень записи	Что описывает	Что смотреть
   Пул на узле	Пул целиком	Имя пула, состояние, узел
   Группа устройств	Группа внутри пула — например зеркало	Состояние группы
   Устройство	Конкретный диск	Путь устройства и его состояние

Запись «узел в состоянии UNAVAILABLE» означает, что узел не ответил на опрос, а не что пул узла сломан. Такой узел проверяют отдельно — по таблице Server Nodes и колонке Health; возможно, авария не в дисках.

Данные в таблице ZFS pools приходят из базы, поэтому в аварии сверяйтесь с живым опросом: экран может показывать последнее снятое состояние.

Шаг 2. Понять, идёт ли восстановление уже сейчас

Если ресинхронизация уже началась — например, пул сам подставил запасной диск — вмешательство навредит.

1. В таблице ZFS pools посмотрите колонку Resilvering нужного пула. Единица означает «восстановление идёт»: дождитесь его окончания и только потом решайте, нужна ли замена.
2. Откройте пул и прочитайте раздел Properties: Capacity, Provisioned, Used и Free. Переполненный пул восстанавливается дольше, а места под ресинхронизацию должно хватать.
3. Заодно посмотрите Scrubbing: проверка целостности, запущенная на узле, тоже нагружает пул.

Шаг 3. Локализовать отказавший диск

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

1. Возьмите путь устройства из записи живого опроса с ненормальным состоянием.
2. Откройте карточку пула, раздел Pool Disks (или блок Disks на карточке узла) и найдите этот путь на табе Placement в колонке Device. Рядом стоят Enclosure_device, Enclosure_id и Dev_index — это адрес диска в корзине.
3. Проверьте модель и здоровье носителя на табе Disk props: колонки Model, Size (GB) и Status.
4. Подсветите диск, чтобы инженер в зале не ошибся слотом. На карточке узла в блоке Disks перейдите на таб Front view или Inner view — у каждого диска там есть кнопки подсветки и индикации отказа. В аварии уместнее индикатор отказа: он прямо говорит «этот отказал».
5. Проверьте, что индикаторы горят: таб LED on panel, колонки Led_fault и Led_locate.

Если в списке дисков нет пути из живого ответа, диск не учтён инвентаризацией. Запустите инвентаризацию узла по классу cam, затем ses, и откройте список заново.

Шаг 4. Проверить, что пул вообще импортирован

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

1. В таблице ZFS pools посмотрите колонку Current node: она говорит, какой узел несёт пул сейчас. Пустое значение или отсутствие пула в таблице — признак, что сервис пула не поднят.
2. Откройте пул из таблицы и в меню Actions выберите Start pool.
3. Убедитесь, что пул появился в таблице живым, и повторите живой опрос — пул должен появиться и в нём.

Разрешение сервиса — вторая, независимая ось: запрещённый сервис не поднимется, сколько бы раз его ни запускали. Разрешение и запрет в веб-интерфейсе не представлены, их выполняет администратор через API; порядок разобран в «Как управлять сервисами кластера».

Принятая команда подтверждает приём Cluster Manager, а не фактический старт. Фактическое состояние показывает сама таблица пулов, когда узел отчитается.

Шаг 5. Найти или подготовить донора

Замена не начнётся, пока в узле нет свободного диска. Свободный означает роль «запасной» или «неиспользуемый»; роль в базе может отставать, поэтому её подтверждают живым опросом.

1. Найдите кандидатов в блоке Disks карточки узла: на табе ZFS props у свободного диска пустые Pool name и Vdev_pool_name. Сверьте Size (GB) — донор должен быть не меньше заменяемого.
2. Обновите роль кандидата живым опросом узла через API: узел отвечает о диске по пути устройства, vStack Center записывает актуальную роль.
3. Если явного запасного диска нет, пометьте свободный диск запасным через API. На диске с живыми данными узел откажет, пока операцию не потребуют принудительно — это защита.
4. Перечитайте список дисков и убедитесь, что Pool name у донора пустой.

предупреждение

Не берите донором диск из другого пула, даже если он выглядит свободным. Защита отклонит команду с кодом -24907, но проверить роль до вызова дешевле, чем разбирать отказ в аварии.

Шаг 6. Запустить замену

Замену выполняет администратор через API. Все проверки проходят до отправки на узел: ошибочный вызов не доедет до диска.

Что нужно подготовить:

• узел, в котором стоят отказавший диск и донор;
• имя пула из колонки Name таблицы ZFS pools;
• путь отказавшего устройства из живого опроса;
• путь донора — он должен отличаться от отказавшего устройства.

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

Повторно ту же команду не отправляйте. Вторая замена в том же пуле отклоняется с кодом -24906, а второй деструктив над тем же диском — с -24504.

Шаг 7. Дождаться возврата избыточности

Восстановление идёт на узле, vStack Center только показывает его. Смотрите два места: живое состояние дерева и признак процесса на экране пулов.

1. В таблице ZFS pools следите за колонками Health и Resilvering. Единица в Resilvering — восстановление идёт; ноль при здоровом Health — закончилось.
2. Повторяйте живой опрос по этому узлу. Признак успеха: на месте старого пути стоит путь донора, а состояние пула и группы устройств вернулось к норме.
3. Сверьте состав пула на карточке пула: раздел Pool Disks, таб Placement.

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

Завершение работ

1. Погасите индикацию: карточка узла → блок Disks → таб Front view или Inner view; результат проверьте на табе LED on panel.
2. Снимите отказавший диск с кластера перед извлечением — операция идёт через API по серийному номеру или пути устройства. Убедитесь живым опросом, что пул больше не опирается на этот диск.
3. Восстановите резерв. Донор ушёл в пул, запасного в узле больше нет: выведите в кластер новый диск и пометьте его запасным.
4. Обновите инвентарь после физических изменений — инвентаризация узла по классам ses, затем cam. Иначе в списке дисков останется запись о вынутом диске с устаревшим Last_seen.
5. Прочитайте свойство пула autoreplace через API. Если оно выключено, автоматической подстановки запасного диска не будет — в следующий раз замену снова придётся запускать вручную.

Проверка результата

Что проверяем	Где смотреть	Ожидаемо
Пул вернул избыточность	Storage Resources, колонка Health	Пул показан здоровым
Пул опирается на донора	Живой опрос через API	На месте отказавшего устройства путь донора
Ресинхронизация закончилась	Storage Resources, колонка Resilvering	Значение 0 при здоровом Health
Донор учтён членом пула	Карточка пула, Pool Disks → ZFS props	У донора заполнены Pool name и Vdev_pool_name
Отказавший диск снят с кластера	Через API	Признак «выведен в кластер» снят
Индикация погашена	Блок Disks → LED on panel	Led_fault и Led_locate выключены
Резерв восстановлен	Через API	В узле есть диск с ролью «запасной» и пустым Pool name
Все узлы отвечают	Живой опрос через API	В ответе нет записей в состоянии UNAVAILABLE

Если не получилось

Что видите	Почему	Что делать
В ответе живого опроса узел в состоянии UNAVAILABLE	Узел не ответил на опрос. Это не деградация пула	Проверьте узел в таблице Server Nodes; авария может быть не в дисках
Код ошибки -25003	Не удалось получить список узлов кластера при опросе всех узлов	Опросите узлы по одному; проверьте доступность Cluster Manager
Код ошибки -24907	Донор не свободен: роль не «запасной» и не «неиспользуемый»	Возьмите другой диск или освободите этот; роль обновите живым опросом
Код ошибки -24908	Состояние донора выяснить не удалось: узел не ответил или истёк тайм-аут	Замена отклонена намеренно. Проверьте связь с узлом и повторите опрос диска
Код ошибки -24906	В этом пуле уже идёт замена	Дождитесь завершения текущей: одна замена на пул
Код ошибки -24905	Отказавшее и новое устройство совпадают	Укажите разные устройства
Код ошибки -24902	Пул пустой или не существует на узле	Пул может быть не импортирован. Проверьте Current node и запустите пул из меню Actions
Код ошибки -24903	Не передан путь отказавшего устройства	Возьмите путь из живого опроса
Код ошибки -24904, -24502, -24402, -24803	Путь устройства не прошёл проверку формата	Приведите путь к виду /dev/daN
Код ошибки -24504	Над диском уже идёт деструктивная операция	Дождитесь ответа узла: два деструктива над одним диском не выполняются
Код ошибки -24503	Диск уже помечен запасным	Повтор не нужен, проверьте роль диска
Код ошибки -24307, -24316	Не тот формат имени корзины или корзина не найдена	Передавайте имя в виде /dev/sesN; при расхождении переснимите инвентарь корзин
Код ошибки -24311, -24313, -24315	Значение индикатора не 0 и не 1 либо не передан ни один индикатор	Передайте хотя бы один индикатор значением 0 или 1
Код ошибки -25002, -24901, -24501, -24401, -24301, -24201, -24801	Выключен признак feature.physical_disc_management	Включите управление физическими дисками в опциях кластера
Код ошибки -403	Операция открыта только роли Cluster master	Войдите под ролью уровня кластера
Код ошибки -29	Не удалось получить карту пулов из базы	Опирайтесь на живой опрос: база сейчас недоступна
Код ошибки -20512, -20522, -713	Имя сервиса или узел не прошли проверку либо команда не дошла до Cluster Manager	Возьмите имя пула из колонки Name; проверьте доступность Cluster Manager
Команда принята, состояние не меняется	Команда только передана агенту узла	Откройте экраны заново и повторите живой опрос; исход приходит ответом узла
Живой опрос говорит «здоров», таблица ZFS pools — «деградирован»	Картина в базе отстаёт: её обновляет инвентаризация	Верьте живому опросу; обновите базу сбором данных о хостах
Замена прошла, но пул остался деградированным	В пуле отказал не один диск, либо отказ в другой группе устройств	Перечитайте дерево живого опроса целиком и замените остальные отказавшие устройства по одному
Пул деградирован, а отказавших дисков в дереве нет	Пул мог остаться без части устройств из-за узла, а не диска	Проверьте состояние узлов и сервис пула; диск менять не нужно

Ограничения

Проверку целостности пула из vStack Center не запустить — такой операции нет. Колонка Scrubbing только сообщает, идёт ли процесс, начатый на узле.

Живое здоровье пулов в базу vStack Center не пишется: живой опрос возвращает состояние на момент вызова. Историю деградаций по нему не построить.

Прогресс ресинхронизации в процентах недоступен — есть только признак «идёт или нет». Оценивайте по объёму пула из раздела Properties.

См. также

• Плановый порядок, когда диск ещё жив, — «Плановая замена диска в узле».
• Модель слоя хранения и источники состояния пула — «Пулы хранения».
• Карта пулов, страница пула и живой опрос узла — «Как посмотреть пулы кластера».
• Сервисы пулов и их привязка к узлам — «Как управлять сервисами кластера».

Методы API

Операции этой страницы в API: pd-pools-status, pd-list, pd-status-map, pd-led, pd-info, pd-spare, pd-replace, pd-use, pd-unuse, pool-map, pool-map-by-guid, pools-list, pools-get, get-statusmap, node-list, node-inventory, host-inventory, cluster-service-enable, cluster-service-start — см. Справочник API.