SelfHeal хранилища
SelfHeal хранилища — механизм автоматического восстановления отказоустойчивости хранилища YDB.
Общий обзор механизмов и условий их работы приведён в разделе SelfHeal. Восстановление реплик State Storage, Board и SchemeBoard описано в разделе SelfHeal подсистем распространения метаданных.
Как работает SelfHeal хранилища
Компонент Sentinel, входящий в CMS, постоянно следит за состоянием PDisk и узлов. Если неисправность сохраняется достаточно долго (по умолчанию около часа), Sentinel инициирует перенос затронутых VDisk на исправное оборудование, чтобы снова соблюдалась модель отказа.
Команду исполняет Blob Storage Controller: данные реплицируются в фоне. Сам перенос может занять от минут до суток в зависимости от объёма данных и оборудования. После принятия команды для CMS задача уже поставлена; завершение репликации обеспечивает распределённое хранилище.
SelfHeal хранилища включён по умолчанию для динамических групп. В кластерах с конфигурацией V2 можно также включить SelfHeal статической группы. На конфигурации V1 SelfHeal статической группы включить нельзя.
Включение и выключение SelfHeal
Вы можете включать и выключать SelfHeal с помощью утилиты YDB DSTool.
Чтобы включить SelfHeal выполните команду:
ydb-dstool -e <bs_endpoint> cluster set --enable-self-heal
<bs_endpoint> — эндпоинт произвольного узла хранения кластера.
Чтобы выключить SelfHeal выполните команду:
ydb-dstool -e <bs_endpoint> cluster set --disable-self-heal
Настройки SelfHeal
Вы можете настроить SelfHeal в Viewer → Cluster Management System → CmsConfigItems.
Чтобы создать настройки впервые, нажмите кнопку Create. Если вам нужно изменить существующие настройки, нажмите кнопку
Доступны следующие настройки:
| Параметр | Описание |
|---|---|
| Status | Включение и выключение SelfHeal в CMS. |
| Dry run | Включение и выключение режима, в котором CMS не изменяет настройку BSC. |
| Config update interval (sec.) | Период обновления конфигурации из BSC. |
| Retry interval (sec.) | Период повторных попыток обновления конфигурации. |
| State update interval (sec.) | Период обновления состояний PDisk'ов. |
| Timeout (sec.) | Таймаут обновления состояний PDisk'ов. |
| Change status retries | Количество повторных попыток на изменение статуса PDisk в BSC (ACTIVE, FAULTY, BROKEN и др.). |
| Change status retry interval (sec.) | Задержка между попытками на изменение статуса PDisk в BSC. CMS наблюдает состояние диска с интервалом State update interval. Если диск пребывает в одном состоянии несколько циклов Status update interval, то CMS меняет его статус в BSC. Далее идут настройки количества циклов обновления, через которое CMS будет изменять статус диска. Если состояние диска Normal, то диск переводится в статус ACTIVE, в остальных состояниях диск переводится в статус FAULTY.Значение 0 выключает изменение статуса для состояния (так реализовано для Unknown по умолчанию).Например, при настройках по умолчанию, если CMS наблюдает состояние диска Initial на протяжении 5 циклов Status update interval по 60 с каждый, статус диска будет изменен на FAULTY. |
| Default state limit | Для состояний, для которых не указана настройка, может использоваться это значение «по умолчанию». Для неизвестных состояний PDisk, для которых нет настройки, тоже используется это значение. Это значение используется, если значение не задано для состояний Initial, InitialFormatRead, InitialSysLogRead, InitialCommonLogRead, Normal. |
| Initial | PDisk начинает инициализацию. Переход в FAULTY. |
| InitialFormatRead | PDisk читает свою запись формата. Переход в FAULTY. |
| InitialFormatReadError | PDisk получил ошибку при чтении своей записи формата. Переход в FAULTY. |
| InitialSysLogRead | PDisk читает системный лог. Переход в FAULTY. |
| InitialSysLogReadError | PDisk получил ошибку при чтении системного лога. Переход в FAULTY. |
| InitialSysLogParseError | PDisk получил ошибку при парсинге или проверке консистентности системного лога. Переход в FAULTY. |
| InitialCommonLogRead | PDisk читает общий лог VDisk'ов. Переход в FAULTY. |
| InitialCommonLogReadError | PDisk получил ошибку при чтении общего лога VDisk'ов. Переход в FAULTY. |
| InitialCommonLogParseError | PDisk получил ошибку при парсинге или проверке консистентности общего лога. Переход в FAULTY. |
| CommonLoggerInitError | PDisk получил ошибку при инициализации внутренних структур предназначенных для записи в общий лог. Переход в FAULTY. |
| Normal | PDisk завершил инициализацию и работает нормально. Переход в ACTIVE произойдет через указанное количество циклов (например, если Normal держится 5 минут, диск переходит в состояние ACTIVE). |
| OpenFileError | PDisk получил ошибку при открытии файла диска. Переход в FAULTY. |
| Missing | Нода отвечает, но в её списке нет данного PDisk. Переход в FAULTY. |
| Timeout | Нода не ответила за отведенный таймаут. Переход в FAULTY. |
| NodeDisconnected | Отключение ноды. Переход в FAULTY. |
| Stopped | PDisk остановлен. Переход в FAULTY. |
| Unknown | Неожиданный ответ, например, ответ TEvUndelivered на запрос состояния. Переход в FAULTY. |
Работа с дисками-донорами
Диск-донор — это предыдущий VDisk после переноса данных, который продолжает хранить свои данные и отвечает только на запросы чтения от нового VDisk'а. При переносе с включенными дисками-донорами предыдущие VDisk'и продолжают функционировать до тех пор, пока данные не будут полностью перенесены на новые диски. Чтобы предотвратить потерю данных при переносе VDisk'а, включите возможность использования дисков-доноров:
ydb-dstool -e <bs_endpoint> cluster set --enable-donor-mode
Чтобы выключить диски-доноры, введите команду:
ydb-dstool -e <bs_endpoint> cluster set --disable-donor-mode