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

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

Общую схему 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.4) можно "объединить" уже на уровне Закрома.Хранения.

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

| Схема 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

## Запуск миграции данных
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)

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

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

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


При росте объема хранения масштабирование может быть осуществлено на двух уровнях:
- Ну уровне дисковой подсистемы (zds)
- На логическом уровне за счёт добавления дополнительных ресурсов хранения.

Первый способ может быть ограничен серверной инфраструктурой: например, возможностью подключить диск(и). Второй способ, напротив, не ограничен и может быть всегда использован.

## Масштабирование на уровне дисковой подсистемы

При использовании в качестве ресурса хранения **zds** (Zakroma data storage) рекомендуется объединять физические диски в volume group и логические вольюмы (lvm) для упрощения процедуры увеличения размера без необходимости ребаланса кластера Erasure coding. Следует учесть, что технология помехоустойчивого кодирования Erasure cooding не позволяет изменять соотношение частей данных и частей избыточности (data/parity) после начала использования.

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

Применение этого метода не требует использование механизмов приложения, т.к. происходит на уровне нижележащей инфраструктуры и может быть произведено по инструкции используемых для этого сторонних компонент.

## Масштабирование на логическом уровне (приложения)

В любой момент можно расширить ёмкость хранения за счет добавления нового ресурса хранения (хранилища) и подключения его как новую группу хранения бакета.

Например, при использовании кластера `zds` в качестве основного хранилища данных бакета, при невозможности его расширения, вы можете создать второй кластер `zds` и подключить его в тот же бакет. Для S3-клиентов будет доступен суммарный объём двух кластеров таким образом, как если бы он был единый.

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

**Для увеличения размера ёмкости хранения бакета в административной веб-консоли**:

1. [Хранилища](https://zakroma.ru/knowledgeBase/storage/article/storages?version=2.4) на странице `Хранилища`
2. Откройте вкладку `Настройка хранения` [бакета](https://zakroma.ru/knowledgeBase/storage/article/nastrojka-hraneniya-baketa?version=2.4).
3. Нажмите кнопку `+ Добавить группу хранения`
4. Выберите созданное на первом шаге хранилище и укажите путь в нём (при необходимости, иначе будет использован корень файловой системы).
5. При необходимости укажите ограничение на максимальный объём хранения для других групп хранения в параметрах группы. Это свойство учитывается для автоматического выбора при загрузке объекта вместе с приоритетом группы хранения (порядком следования в настройках хранения бакета).

## Классы хранения

При этом подключаемое хранилище может быть того же или  другого типа. Также это позволяет с помощью политик [Жизненный_цикл](https://zakroma.ru/knowledgeBase/storage/article/zhiznennyj-czikl?version=2.4) настроить оптимальное распределение объектов по подключенным хранилищам, относясь к ним как к классам хранения.

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

Описание возможностей масштабирования объёма хранения кластера

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

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

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

В данной статье описаны два способа подключения в Закрома Хранение:

1. PathStyle url
2. DnsStyle url (Virtual-hosted–style)

Подключение описано на примере популярного S3-клиента - [S3 Browser](https://s3browser.com/).

## Подключение к S3 с PathStyle url

### Параметры доступа по умолчанию

- Admin-ui: **host:8083**
- Keycloak: **host:8180**
- S3 endpoint (***БЕЗ TLS/SSL***):
  - при возможности прописать записи DNS:
    - `<WORKSPACE_NAME>.ps.<BASE_DOMAIN>`,
где **\<BASE_DOMAIN>** - dns имя хоста, <WORKSPACE_NAME> - имя рабочей области (тенанта).
  - без возможности внести записи в DNS (deprecated):
    - `host:8081/workspaces/<WORKSPACE_NAME>/s3`

### Для подключения необходимо:
1. Определить S3 endpoint (см. раздел выше)
2. [Добавить нужные права](https://zakroma.ru/knowledgeBase/storage/article/politiki-dostupa?version=2.4) на рабочую область или бакет.
3. Ключом доступа (aws_access_key_id) - служит логин пользователя
4. [Сгенерировать новый или скопировать существующий](https://zakroma.ru/knowledgeBase/storage/article/upravlenie-klyuchami-dostupa?version=2.4) ключ s3 для пользователя - что является секретным ключом(aws_secret_access_key).
5. Заполнить все необходимые для подключения поля
![image](https://storage.yandexcloud.net/zakroma-ru/media/43b8d3f87c34ac6754eeed1103c968c5.png)

> [!warning] Обязательно указать в настройках конфигурации Advanced settings, что используется **AwsV4Sign** и **Path Style**


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

## Подключение к S3 с DnsStyle (Virtual-hosted–style)

#### Для подключения необходимо:
 
1. Настроить  Virtual-hosted–style. Подробнее о настройке можно прочитать [здесь](https://zakroma.ru/knowledgeBase/storage/article/nastrojka-virtual-hosted-style?version=2.4).
2. Сформировать правильный url:
 - **<workspaceName\>.<hostname\>.ru** 
 
 >[!info] **hostname** - это доменный путь до сервиса gateway;       **workspaceName** - это имя рабочей области

3. [Добавить нужные права](https://zakroma.ru/knowledgeBase/storage/article/buckets?version=2.4) на рабочую область или бакет.
4. Ключом доступа (aws_access_key_id) - служит логин пользователя
5. [Сгенерировать новый или скопировать существующий](https://zakroma.ru/knowledgeBase/storage/article/upravlenie-klyuchami-dostupa?version=2.4) ключ s3 для пользователя - что является секретным ключом(aws_secret_access_key)
6. Заполнить все необходимые для подключения поля
![image](https://storage.yandexcloud.net/zakroma-ru/media/a21cfd8ba4fb52c577e19422a729c575.png)

> [!warning] Обязательно указать в настройках конфигурации, что используется **AwsV4Sign** и  **Virtual hosted style** 


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

## Использование спецсимволов в ключах

> [!warning] Обратите внимание, что разные S3-клиенты могут по разному обрабатывать спецсимволы в ключах (именах) объектов.

Старайтесь избегать следующих спецсимволов:

- Вопросительный знак ("?")
- Плюс ("+")
- Решетка ("#")

## Возможные проблемы

- **Проблема**: В S3 Browser при получении списка объектов и загрузке файла ошибка 404 NotFound.
**Решение 1**: Убедитесь в корректности настройки метода подключения Virtual или Path style.
**Решение 2**: Если вы используете самоподписанные сертификаты, то c последних версий S3 Browser проверяет сертификаты и для работы с самоподписанными надо отключить эту проверку в настройках самого S3 Browser.

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

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

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

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

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

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

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

Требования

С чего начать

Установка через ansible

Установка тестовой инсталляции на 1 сервере

Установка на 1 сервере (Single Node)

Установка варианта с мультикластером

Подготовка окружения к установке

Описание типовой установки в 1 кластере

Установка базового кластера

Бинарные пакеты

Подготовка инфраструктуры

Установка helm-чартами

Контейнеры

Настройка Virtual-hosted–style

Настройка Keycloak

Настройка PostgreSQL

Self signed ssl certificate

Настройка Zakroma.Storage (ZDS)

Метрики

Окружение

Установка

CLI (Command Line Interface, zcli)

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

Мониторинг

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

Операции

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

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

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

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

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

Бакет (bucket)

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

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

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

Хранилища

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

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

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

CORS

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

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

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

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

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

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

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

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

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

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

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

Роли

Доступ

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

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

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

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

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

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

Управление

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

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

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

Webhooks

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

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

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

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

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

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

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

Расширение

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

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