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

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

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

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

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

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

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

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

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

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

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

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

Использование

## Общие термины

**Стирающее кодирование** (англ. erasure coding, EC) - в теории кодирования помехоустойчивый код, способный восстанавливать части данных в случае их потери. Бит чётности, код Хэмминга, код Рида-Соломона - это всё представители данного класса кода. Каждый из них характеризуется алгоритмической сложностью и избыточностью данных, т.е. количеством частей, которые можно потерять, но суметь восстановить изначальное сообщение. В продукте **Закрома.Хранение** в сервисе [ZDS](https://zakroma.ru/knowledgeBase/storage/article/zds?version=2.6) используется код Рида-Соломона для организации отказоустойчивого хранения файлов.

Общую схему EC можно представить в виде D+N, где D - кол-во частей данных, N - избыточное кол-во частей. Перед записью файла на диски, он разбивается на D частей (data part). Затем по алгоритму создаются дополнительные N частей чётности (parity part). Далее D+N частей будут равномерно распределены между дисками кластера.

**Схему кодирования EC** (далее в тексте будет использоваться именно она) также указывают следующим образом - `EC K:N`, где K - общее кол-во частей, N - избыточное кол-во частей. Кол-во частей данных в таком случае равно `K-N`.

![image](https://storage.yandexcloud.net/zakroma-ru/media/2bca0a117e966369c3fb52de5a14090c.jpg)

Основываясь на алгоритме, для успешного чтения файла в схеме `EC K:N` необходимо, чтобы были доступны любые `K-N` частей. Или с другой стороны - мы не должны терять более N частей от общего кол-ва.

> [!warning] Соотношение частей
> Существует несколько простых ограничений на **K** и **N** из схемы EC:
> * **K** должно быть кратно (делиться без остатка) кол-ву узлов (серверов).
> * Кол-во всех дисков должно быть кратно **K**.	
> * **N** должно быть меньше или равно чем  `K/2`

**Коэффициент хранения (КХ)** - это отношение полезного объёма к общему объёму хранения. Для схемы `EC K:N` он равен `(K-N)/K` или `1-(N/K)`. Чем больше избыточность, тем меньше полезного объёма у нас остаётся.

## Базовые рекомендации

Точки отказа существующие в рамках EC - это диск и сервер. Требования к отказоустойчивости, которые часто предъявляют к системе хранения данных:
* Потеря одного диска не должна приводить к отказу системы
* Потеря/выключение одного сервера (например для целей обновления ОС) не должно приводить к отказу системы

EC имеет одно существенное ограничение не позволяет изменять соотношение частей данных и частей избыточности (data/parity) после начала использования.

На примере этих требований рассмотрим, как это влияет на схему EC. Допустим у нас 4 сервера по 4 диска в каждом. Исходя из ограничений схемы K может принимать следующие значения - 4,8,16. Рассмотрим несколько вариантов для N:

| Схема EC | Коэффициент хранения | Отказоустойчивость                                                                          |
| -------- | -------------------- | ------------------------------------------------------------------------------------------- |
| EC 4:1   | 0.75                 | можем потерять один диск на любом сервере или один сервер                                   |
| EC 8:2   | 0.75                 | можем потерять два диска на любых серверах или один сервер                                  |
| EC 8:3   | 0.625                | можем потерять три диска на любых серверах или один сервер + один диск на любом сервере     |
| EC 16:4  | 0.75                 | можем потерять четыре диска на любых серверах или один сервер                               |
| EC 16:5  | 0.6875               | можем потерять пять дисков на любых серверах или один сервер + один диск на любом сервере   |
| EC 16:6  | 0.625                | можем потерять шесть дисков на любых серверах или один сервер + два диска на любых серверах |

Видно, что `EC 16:6` сопоставим с `EC 8:3` по коэффициенту хранения, но превосходит его по отказоустойчивости. Но негативным моментом увеличения количества частей является:
* замедление работы, т.к. для записи файла необходимо записать файл на большее кол-во дисков. 
* накладные расходы на метаданные, т.к. там хранится информация о местонахождении каждой части файла.

Так же нужно принимать во внимание профиль среднестатистического файла. Если мы понимаем, что будем хранить небольшие файлы, менее 1 MB, то разбивать их 16 частей невыгодно, как минимум с точки зрения последовательного чтения/записи с диска.

Общие рекомендации можно свести к следующим моментам:
* Минимально возможная конфигурация - 3 сервера. Не стоит ожидать хорошего КХ и отказоустойчивости от такой конфигурации.
* Если мы считаем, что сервера достаточно отказоустойчивые (или используем виртуальные машины), то можем закладывать возможность одновременного отказа только одного сервера из кластера.
* Желательно закладывать возможность отказа диска на любом работающем сервере в момент отказа/недоступности другого сервера (т.е. не использовать конфигурации вида EC X:1 без RAID / отказоустойчивого СХД).
* Между конфигурациями с одинаковыми параметрами выбирать те, у которых кол-во частей K меньше: EC 8:3 предпочтительнее чем EC 16:6
* Максимально рекомендуемое кол-во серверов в одном кластере - 9. Лучше организовать 2 кластера меньшего размера, чем один большой. Кластера [ZDS](https://zakroma.ru/knowledgeBase/storage/article/zds?version=2.6) можно "объединить" уже на уровне Закрома.Хранения.

## Типовые схемы

| Схема EC | Количество серверов | Кратность кол-ва дисков на одном сервере | Коэффициент хранения | Отказоустойчивость                          |
| -------- | ------------------- | ---------------------------------------- | -------------------- | ------------------------------------------- |
| EC 9:4   | 3                   | 3                                        | 0.55                 | 4 диска или 1 сервер + 1 диск               |
| EC 12:4  | 4                   | 3                                        | 0.66                 | 4 диска или 1 сервер + 1 диск               |
| EC 16:5  | 4                   | 4                                        | 0.6875               | 5 дисков или 1 сервер + 2 диска             |
| EC 15:4  | 5                   | 3                                        | 0.73                 | 4 диска или 1 сервер + 1 диск               |
| EC 10:4  | 5                   | 2                                        | 0.6                  | 4 диска или 1 сервер + 1 диск или 2 сервера |
| EC 14:4  | 7                   | 2                                        | 0.71                 | 4 диска или 1 сервер + 1 диск или 2 сервера |


## EC и RAID

EC и RAID не противоречат друг другу и могут использоваться в Закрома.Хранения совместно.  Если  их использовать совместно, то для EC каждый RAID массив будет являться просто отдельным диском. Приведём сравнительный анализ на примере 4 серверов с 4 дисками.

|                                                       | EC 16:4                                                | EC 16:5                                                | EC 4:1 + RAID5                                    |
| ----------------------------------------------------- | ------------------------------------------------------ | ------------------------------------------------------ | ------------------------------------------------- |
| Коэффициент хранения                                  | 0.75                                                   | 0.6875                                                 | 0.5625                                            |
| Отказоустойчивость                                    | 4 диска или 1 сервер                                   | 5 дисков или 1 сервер + 1 диск                         | 4 диска на разных серверах или 1 сервер + 1 диск  |
| Нагрузка инфраструктуру в момент восстановления диска | на сеть и диски на разных серверах                     | на сеть и диски на разных серверах                     | на локальные диски в рамках RAID массива          |
| Возможность расширения хранилища                      | только кратное увеличение дисков, от 16 штук суммарно. | только кратное увеличение дисков, от 16 штук суммарно. | от 1 диска на RAID массив - от 4 дисков суммарно. |

Для такого количества дисков RAID5 будет проигрывать по коэффициенту хранения и даже отказоустойчивости. Но если кол-во дисков будет значительно больше, картина не будет столь однозначной. Возьмём те же 4 сервера , но уже 8 дисков.

|                                  | EC 16:4                                                | EC 16:5                                                | EC 4:1 + RAID5                                    |
| -------------------------------- | ------------------------------------------------------ | ------------------------------------------------------ | ------------------------------------------------- |
| Коэффициент хранения             | 0.75                                                   | 0.6875                                                 | 0.656                                             |
| Отказоустойчивость               | 4 диска или 1 сервер                                   | 5 дисков или 1 сервер + 1 диск                         | 4 диска или 1 сервер + 1 диск                     |
| Возможность расширения хранилища | только кратное увеличение дисков, от 16 штук суммарно. | только кратное увеличение дисков, от 16 штук суммарно. | от 1 диска на RAID массив - от 4 дисков суммарно. |


## EC и СХД

Так же возможно использование мощностей уже существующих СХД. Обычно оно уже предоставляет отказоустойчивую конфигурацию дисковой подсистемы. В таком случае предлагается использовать минимально избыточную конфигурацию вида EC X:1, где X - количество серверов выделенных под хранение. Чем больше X, тем выше коэффициент хранения, но и тем большее кол-во серверов вам понадобится. Мы рекомендуем остановиться на EC 4:1 (КХ - 0,75) или EC 5:1 (КХ - 0,8)


Краткое описание схемы работы Erasure Coding

Масштабирование объёма хранения

# Миграция данных


Миграция данных позволяет осуществить перенос данных бакета из одного [Хранилища](https://zakroma.ru/knowledgeBase/storage/article/storages?version=2.6) в другое без остановки бизнес приложений.

## С чего начать

1. Добавьте и проверьте доступность целевого хранилища (куда мигрируем) в списке на странице [Хранилища](https://zakroma.ru/knowledgeBase/storage/article/storages?version=2.6).
2. Откройте страницу настройки бакета, данные которого нужно перенести.
3. Откройте вкладку [Настройка хранения бакета](https://zakroma.ru/knowledgeBase/storage/article/nastrojka-hraneniya-baketa?version=2.6).

## Запуск миграции данных
1. На странице настройки хранения выберите хранилище, на котором лежат данные для миграции.
2. В контекстном меню (...) выберите пункт `Мигрировать данные`.
![image](https://storage.yandexcloud.net/zakroma-ru/media/18c92ee2987746bab9f0026c81b628bb.png)
3. С помощью активирования чекбокса  `Мигрировать в новую мирроринг группу` определите использовать существующую группу политик или создать новую.
![image](https://storage.yandexcloud.net/zakroma-ru/media/75fa15fa06aecd82237666e85524ca13.png)
4. В диалоговом окне введите имя группы,  хранилище и путь в хранилище
![image](https://storage.yandexcloud.net/zakroma-ru/media/58552fee7fd1dd77b87229af4a9c932e.png)
5. Нажмите кнопку `Мигрировать`.

## Процесс миграции
После нажатия кнопки `Мигрировать` начнётся процесс копирования данных. Отобразится сообщение об успешной миграции. 
![image](https://storage.yandexcloud.net/zakroma-ru/media/8d9aef55b96c010fa1283f196ed2308d.png)

Выбранная группа хранения будет отмечена как удаленная и будет недоступна для взаимодействия.
![image](https://storage.yandexcloud.net/zakroma-ru/media/f24522ade0ecbb80bac0be25703fa92f.png)

> [!info] Процесс миграции занимает неопределённое время и зависит от ряда параметров (скорость хранилищ, сетевая связанность, объём хранимых данных). При этом **клиентские приложения могут работать без остановки.** 

Все новые объекты будут записаны как в исходное хранилище, так и в новое. В процессе миграции, чтение происходит с исходного хранилища.

## Завершение миграции
После завершения миграции, старое хранилище будет отключено и убрано из интерфейса настройки хранения бакета. Чтение и запись новых объектов будет происходит с нового (целевого) хранилища.

> [!warning] Для исключения потери информации, данные на исходном хранилище остануться после завершения миграции и, при необходимости, должны быть удалены вручную.
## Возможные ошибки

При совершении миграции могут возникнуть следующие ошибки:
- **BlockingLink** (Блокирующие связи)

![image](https://storage.yandexcloud.net/zakroma-ru/media/594d35ed66fb2f93ddda3753e35db72d.png)

Данная ошибка сообщает о том, что миграция невозможна для групп хранения, т.к. она связана с правилами в разделе "Жизненный цикл".
- **TransportError** (Ошибка перемещения)

![image](https://storage.yandexcloud.net/zakroma-ru/media/7cb4458feb3a3e7f70da455a31b14c78.png)

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

Перенос данных бакета из одного Хранилища в другое

Миграция данных

Таблица поддерживаемых методов AWS S3

Поддержка методов AWS S3

Работа с S3 Browser

Первые шаги в приложении

Начало работы

Описание общей архитектуры решения и компонент

Архитектура решения

Расчет требований к инфраструктуре

Требования

С чего начать

Установка Закрома.Хранение

Установка

CLI (Command Line Interface, zcli)

Отслеживание задач и статуса системы

Мониторинг

Описание работы страницы с операциями

Операции

Как создавать и настраивать бакеты

Бакет (bucket)

Управление рабочими областями

Рабочие области

Удаление бакета

Версионирование бакета

Версионирование

Просмотр бакета

CORS

Публичные бакеты

Подключение ресурса хранения

Хранилища

Описание типов хранилищ

Тип Хранилища

Шардирование

Настройка хранения

Управление ключами доступа

Группы пользователей

Администраторы workspace/bucket

Фильтрация по IP

Профиль пользователя

Редактирование информации о пользователях

Пользователи

Политики доступа предназначены для создания правил разграничения доступа пользователей к операциям S3.

Политики доступа

Роли

Доступ

Настройка конфигурации для пакетов

Принцип работы кластерного режима

Мультикластер

Включение кластерного режима

Добавление кластера

Настройка конфигурации для kubernetes

Управление

Путь хранения объектов бакета на подключенном хранилище

Формирование пути хранения данных

Правила жизненного цикла данных

Жизненный цикл

Механизм оповещения других систем о событиях в хранилище.

Webhooks

Политика Расширение позволяет объединить несколько ресурсов хранения

Расширение

Политика Зеркалирование позволяет настроить синхронную и асинхронную репликацию бакета

Зеркалирование

Как подключить хранилище с уже имеющимися данными в нем

Подключение хранилища с данными

Политики хранения

Как загружать, скачивать, синхронизировать, удалять и просматривать объекты через S3 Browser

Пример работы c S3 через S3 Browser

Настройка подключения к Закрома Хранение

Подключение к Закрома.Хранение

Что изменилось в приложении в текущем релизе