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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Работа с S3 Browser

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

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

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

Требования

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

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

С чего начать

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

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

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

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

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

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

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

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

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

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

Контейнеры

Настройка PostgreSQL

Метрики

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

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

Настройка Keycloak

Self signed ssl certificate

Окружение

Установка

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

Мониторинг

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

Операции

CLI (Command Line Interface, zcli)

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

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

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

CORS

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

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

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

Бакет (bucket)

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

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

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

Хранилища

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

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

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

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

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

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

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

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

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

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

Роли

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

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

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

Доступ

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

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

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

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

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

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

Управление

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

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

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

Webhooks

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

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

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

Расширение

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

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

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

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

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

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

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

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

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

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