Рекомендации к подбору схемы Erasure Coding

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

Стирающее кодирование (англ. erasure coding, EC) - в теории кодирования помехоустойчивый код, способный восстанавливать части данных в случае их потери. Бит чётности, код Хэмминга, код Рида-Соломона - это всё представители данного класса кода. Каждый из них характеризуется алгоритмической сложностью и избыточностью данных, т.е. количеством частей, которые можно потерять, но суметь восстановить изначальное сообщение. В продукте Закрома.Хранение в сервисе ZDS используется код Рида-Соломона для организации отказоустойчивого хранения файлов.

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

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

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

Соотношение частей

Существует несколько простых ограничений на 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 16:6 сопоставим с EC 8:3 по коэффициенту хранения, но превосходит его по отказоустойчивости. Но негативным моментом увеличения количества частей является:

• замедление работы, т.к. для записи файла необходимо записать файл на большее кол-во дисков.
• накладные расходы на метаданные, т.к. там хранится информация о местонахождении каждой части файла.

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

Общие рекомендации можно свести к следующим моментам:

• Минимально возможная конфигурация - 3 сервера. Не стоит ожидать хорошего КХ и отказоустойчивости от такой конфигурации.
• Если мы считаем, что сервера достаточно отказоустойчивые (или используем виртуальные машины), то можем закладывать возможность одновременного отказа только одного сервера из кластера.
• Желательно закладывать возможность отказа диска на любом работающем сервере в момент отказа/недоступности другого сервера (т.е. не использовать конфигурации вида EC X:1 без RAID / отказоустойчивого СХД).
• Между конфигурациями с одинаковыми параметрами выбирать те, у которых кол-во частей K меньше: EC 8:3 предпочтительнее чем EC 16:6
• Максимально рекомендуемое кол-во серверов в одном кластере - 9. Лучше организовать 2 кластера меньшего размера, чем один большой. Кластера ZDS можно “объединить” уже на уровне Закрома.Хранения.

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

EC и RAID

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

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

EC и СХД

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