Отказоустойчивость

Общий подход к отказоустойчивости

Отказоустойчивость — это способность системы сохранять свою работоспособность и доступность данных даже при выходе из строя одного или нескольких компонентов. В ЗАКРОМА.Хранение применяется комплексный подход к обеспечению отказоустойчивости:

Уровень узлов (серверов): система спроектирована так, чтобы выдерживать отказы целых серверов без потери данных.
Уровень дисков: Применение помехоустойчивого кодирования Erasure Coding позволяет минимизировать затраты на резервирование данных, сохраняя при этом высокую надежность.

Отказоустойчивость на уровне узлов (серверов)

Каждый узел системы содержит набор сервисов (компонентов) системы. Сервисы системы не хранят состояние и могут быть запущены во множестве экземпляров на однотипных узлах. Это позволяет отключать (терять) узлы без потери работоспособности системы в целом. Состояние системы сохраняется в базе данных PostgreSQL, также запущенной в отказоустойчивом режиме средставми PostgreSQL.

Отказоустойчивость на уровне дисков

ЗАКРОМА использует технологию Erasure Coding, которая значительно повышает эффективность использования дискового пространства при сохранении высокой надежности.

Как работает Erasure Coding:

Исходные данные разбиваются на фрагменты.
Для каждого фрагмента рассчитываются дополнительные контрольные части (parity chunks).
Все фрагменты и контрольные части распределяются по дискам разных узлов.
Если происходит сбой одного или нескольких дисков, система может восстановить потерянные фрагменты данных, используя оставшиеся фрагменты и контрольные части.

Преимущества Erasure Coding:

Экономия дискового пространства по сравнению с полной репликацией.
Высокая надежность: система может пережить одновременный сбой нескольких дисков.
Гибкость: можно настроить количество фрагментов и контрольных частей в зависимости от требований к отказоустойчивости.

Стратегии защиты данных (Disaster Recovery Plan)

Кейс	Стратегии защиты	Ограничения применения	Процедура восстановления
Частичное удаление/порча данных (файлов) на уровне файловой системы/дисков.	Использование механизма erasure coding (EC).	Только при использовании ZDS хранилища в режиме EC. При этом порча данных должна затрагивать дисков не более чем позволяет механизм восстановления EC	Будет происходить автоматически.
	Использование политики хранения «Зеркалирование»	Возможно при использовании любого типа хранилища. Необходимо дополнительное пространство для хранения копии(й) объекта.	Включение функции «Быстрая проверка» и/или «Проверка контрольных сумм» автоматически восстанавливает повреждённые или удалённые объекты из «правильной» копии (по хэш-сумме, указанной в БД).
	Бекапирование файловой системы узлов (снапшот) средствами СРК.	Только при использовании ZDS хранилища. Происходит потеря данных, записанных со времени последнего бекапа. В зависимости от того, как было организована настройка групп хранений, возможно восстановление как одного бакета, так и всей рабочей области / хранилища.	Восстановить файловую систему ZDS из бекапа.
	Мультикластер (геораспределенное хранение в разных ЦОД)	Наличие в архитектуре несколько кластеров Закрома. Бакет находится в мультикластерной рабочей области.	По возможности переключить поток клиентских запросов на другой кластер. Удалить в настройке хранения бакета группы хранения (локальные вольюмы). Объекты будут читаться и записываться на удаленный кластер. Очистить и подготовить хранилище, для размещения данных. Добавления новую группу хранения (локальный вольюм), правильные данные будут синхронизированы на него автоматически.
Потеря БД без потери файлов.	Бекапирование баз(ы) данных хранилища	Единицей восстановления является шард данных.	Восстановить базу(ы) данных из бекапа средствами СРК или штатными для PostgreSQL. При недоступности (утрате) бекапа БД запустить процедуру сканирования хранилища и восстановления информации об объектах в БД.
Восстановление части данных (бакета) на определённый момент времени	Использование версионируемого бакета.	Данные бакета должны располагаться на отдельном шарде БД, т.к единицей восстановления является шард данных. Настроенно отдельное бекапирование шардов БД. Не получится восстановить данные, удалённые из хранилища (физическое удаление) между бекапами БД.	Восстановить базу данных шарда бакета из бекапа средствами СРК или штатными для PostgreSQL. Альтернативой является использование штатных средств S3 API (для точечных изменение): снятие маркера DELETE_MARKER у ненужно удаленных файлов. вызов метода восстановления версии объекта (установка её основной).
Частичное удаление/порча данных (файлов) со стороны S3 клиента	Использование версионируемого бакета.
Потеря/порча данных в бакете	Бекапирование содержимого бакета через zcli	Использование встроенной утилиты бекапирования в консольный интерфейс zcli (с версии 2.7 (дек. 2025)). zcli backup Позволяет делать полный и инкрементальный бекап бакета на файловую систему. Работает через S3 API, что может быть длительной операцией.	Восстановление через встроенную утилиту восстановления zcli restore Восстановление с файловой системы в бакет полного и набора инкрементальных бекапов. Работает через S3 API, что может быть длительной операцией.
Полная потеря кластера данных (БД и файлов).	Мультикластер (геораспределенное хранение в разных ЦОД)	Наличие в архитектуре несколько кластеров Закрома. Бакет находится в мультикластерной рабочей области.	Переключить поток клиентских запросов на другой кластер. Восстановить приложение с помощью запуска скриптов развёртывания Ansible/Helm. По возможности восстановить базу(ы) данных из бекапа средствами СРК или штатными для PostgreSQL. Удалить в настройке хранения бакета группы хранения (локальные вольюмы). Объекты будут читаться и записываться на удаленный кластер. Отчистить и подготовить хранилище, для размещения данных. Добавления новую группу хранения (локальный вольюм), правильные данные будут синхронизированы на него автоматически.
	Бекапирование файловой системы узлов и бекапирование баз(ы) данных хранилища	Только при использовании ZDS хранилища. Происходит потеря данных, записанных со времени последнего бекапа. В зависимости от того, как было организована настройка групп хранений, возможно восстановление как одного бакета, так и всей рабочей области / хранилища. Единицей восстановления является шард данных.	Восстановить файловую систему ZDS из бекапа. Восстановить базу(ы) данных из бекапа средствами СРК или штатными для PostgreSQL. При недоступности (утрате) бекапа БД запустить процедуру сканирования хранилища и восстановления информации об объектах в БД.
	Бекапирование содержимого бакета через zcli и бекапирование баз(ы) данных хранилища	Происходит потеря данных, записанных со времени последнего бекапа данных. Единицей восстановления является шард данных.	Восстановление с файловой системы в бакет полного и набора инкрементальных бекапов. Работает через S3 API, что может быть длительной операцией. Работает через S3 API, что может быть длительной операцией. Восстановить базу(ы) данных из бекапа средствами СРК или штатными для PostgreSQL. При недоступности (утрате) бекапа БД запустить процедуру сканирования хранилища и восстановления информации об объектах в БД.