Как обеспечить отказоустойчивость СХД через архитектуру файловой системы

Данные — критически важный актив любого бизнеса. Компании используют данные, чтобы оптимизировать операции, усиливать свою конкурентоспособность и искать неочевидные взаимосвязи, которые позволят повысить прибыльность. Поэтому отказоустойчивость хранилища данных – важнейшая задача управления ИТ-системой компании.

Бизнесу требуются производительные распределенные файловые системы (ФС), способные обеспечить масштабируемость для растущих объемов данных, бесшовную интеграцию с аналитическими платформами и возможность расширения в рамках мультиоблачных архитектур. Увеличивается и количество приложений, генерирующих данные.

Управление ростом объемов информации и эволюцией ИТ-инструментов внутри компании — комплексный процесс. Если не опираться в нем на правильные и эффективные решения, данные могут оказаться изолированы в своих хранилищах, стать недоступными для поиска и анализа или просто пропасть.

Файловая система: роль, тип, задачи

Файловая система (далее будем называть ее ФС) выполняет роль связующего инструмента между хранилищем с прикладным ПО, которое использует данные, так как именно через нее осуществляется доступ к конкретным файлам. Приложения имеют в своем распоряжении только информацию об имени, размере и атрибутах необходимого им файла при запросе к БД.

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

ФС занимаются размещением и упорядочиванием файлов на носителе, создают, удаляют их и позволяют считывать, назначают и меняют атрибуты: размер, время создания и изменения, владелец и создатель файла, доступность только для чтения, скрытые, временные и архивные файлы, максимальная длина имени и так далее.

С их помощью также определяется структура файла, происходит поиск файлов, организуются каталоги для логической организации файлов. Одна из главных задач ФС — защита файлов при системном сбое, а также от несанкционированного доступа и изменения их содержимого.

Файловых систем довольно много: под различные платформы и ОС, а также под особые задачи, например под работу СХД.

ФС для ГКС

Все эти соображения учитываются нами при разработке СХД и программного обеспечения для управления ими. Например, серьезный вызов появился перед нами в ходе работ по созданию собственного гиперконвергентного (HCI) решения AerodiskvAIR.

Гиперконвергентные ИТ-инфраструктуры или ГКС – формат, где в единой программно-аппаратном комплексе вендор поставляет сразу все элементы ИТ: север, сетевые компоненты и СХД, плотно интегрированные между собой.

Мы проанализировали рынок и требования современных файловых систем, и приняли решение разработать собственную. На этапе выбора архитектуры мы отказались от использования готовых опенсорс-решений под Linux-подобные операционные системы — ceph, gluster, lustre.

Мы поставили цель создать не решение под конкретный проект у заказчика, а собственный продукт, который можно будет легко тиражировать под разные задачи.Разработка заняла 2 года, после чегосвет увидела файловая система ARDFS –AerodiskFileSystem.

Структура ARDFS

По внутреннему интерконнекту файловая система ARDFSобъединяет физические (локальные) диски с разных серверов в один плоский пул и «нарезает» их на виртуальные блоки. Далее из этих блоков формируются отказоустойчивые блочные устройства, на которых с помощью гипервизора KVM создаются и запускаются виртуальные машины.

ARDFS в рамках всех доступных нод кластера организует логический пул, включая в него все доступное дисковое пространство. Такой пул представляет собой разметку, то есть ноды с установленным ПО виртуализации ресурсов.

При добавлении ноды к кластеру они автоматически добавляются в общий пул ARDFS. Таким образом дисковые ресурсы автоматически становятся общими на весь кластер и доступны для хранения данных.

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

Далее, поверх пула ARDFS создаются виртуальные диски (объекты хранения для ВМ) которые строятся из виртуальных блоков размером 4 мегабайта. Непосредственно на этих виртуальных дисках и хранятся данные.

При этом для организации отказоустойчивости используется модель RAIN(RedundantarrayofindependentNodes), то есть отказоустойчивость измеряется, автоматизируется и управляется, исходя из нод, а не дисков (RAID).

Кластер в нашей парадигме оперирует именно нодами, хотя RAID-подход также реализуем, например, для сценария работы со множественными отказами на маленьких кластерах.

Схемы отказоустойчивости: RFvs. EC

Система под управлением vAIR предусматривает две схемы отказоустойчивости.

Первая - Replication factor (RF) или простая репликация. Выполняется синхронная репликация между нодами с фактором 2 (2 копии на кластер) или 3 (3 копии).

RF-2 позволяет виртуальному диску выдержать отказ одной ноды в кластере, но «съедает» половину полезного объема. RF-3 выдержит отказ двух нод в кластере, но зарезервирует уже 2/3 полезного объема под свои нужды.

В рамках RFв случае «вылета» ноды или нод с данными будет все в порядке и даже ввод-вывод не остановится. Когда упавшая нода вернется в строй, начнется автоматическое восстановление/синхронизация данных.

Рассмотрим на примерес ВМ в 8 МБ и 4-мя нодами:

В случае отказа одной из нод (например, ноды №3, где содержится копия B1), данная копия автоматически активируется на ноде, где нет копии её копии (то есть копии B2).

Таким образом, виртуальный диск (и ВМ, соответственно) легко переживут отказ одной ноды в схеме RF-2. Очень надежная схема, а ее единственный, но ощутимый минус – маленький объем свободного полезного дискового пространства.

Вторая схема - Erasure coding (EC) или удаляющее кодирование («избыточное кодирование», «стирающее кодирование» или «код избыточности»). EC обеспечивает высокую доступность данных при меньших накладных расходах на дисковое пространство по сравнению с RF.

При кодировании процесс EC делит виртуальный блок (по умолчанию 4МБ) на несколько меньших «кусков данных» в зависимости от схемы EC (например, схема 2+1 делит каждый блок 4 МБ на 2 куска по 2МБ). Далее это процесс генерирует для «кусков данных» «куски четности» размером не более одной из ранее разделенных частей.

При декодировании EC генерирует недостающие куски, считывая «выжившие» данные по всему кластеру.

Ниже пример с той же ВМ в 8 МБ и 4-мя нодами, но уже при схеме EC «2+1».

Блоки A и B делятся на два куска каждый по 2 МБ (по причине схемы «2+1»), то есть на A1+A2 и B1+B2. В отличие от реплики, A1 не является копией A2, это виртуальный блок A, разделенный на две части, так же и с блоком B.

Итого получаем два набора по 4МБ, в каждом из которых лежит по два двухмегабайтных куска. Далее, для каждого из этих наборов вычисляется чётность объемом не более одного куска (т.е. 2-х МБ), получаем дополнительно + 2 куска чётности (A-P и B-P). Итого имеем 4x2 данных + 2x2 четность.

Куски «раскладываются» по нодам так, чтобы данные не пересекались с их четностью. То есть A1 и A2 не будут лежать на одной ноде с A-P.

В случае отказа одной ноды (допустим, тоже третьей) упавший блок B1 будет автоматически восстановлен из чётности B-P, которая хранится на ноде №2, и будет активирован на ноде, где нет B-четности, т.е. куска B-P. В данном примере – это нода №1.

Это – базовое описание работы обеих схем. В кастомном решении собственной разработки есть наши авторские нюансы, которые демонстрируют возможности ФС для достижения высокого уровня отказоустойчивости СХД.

ARDFS: уникальные особенности

Прежде всего, отметим, что Erasure coding в ARDFSреализован с упором на высокий уровень гибкости.

Он достигается за счет схемы EC X+Y, где X равен числу от 2-х до 8-ми, а Y равен числу от 1-ого до 8-ми, но всегда меньше или равному X. Увеличение числа кусков данных (X), на которые делится виртуальный блок, позволяет снижать накладные расходы, то есть увеличивать полезное пространство.

Увеличение же числа кусков четности (Y) улучшает надежность виртуального диска. Чем больше значение Y, тем больше нод в кластере может выйти из строя. Само собой, увеличение объема четности снижает объем полезной емкости, но такова плата за надежность.

Зависимость производительности от схем EC почти прямая: чем больше «кусков», тем ниже производительность. Зато такой подход позволяет администраторам максимально гибко конфигурировать растянутое хранилище.

В рамках пула ARDFS можно использовать любые схемы отказоустойчивости и их комбинации.

Ниже приведена таблица сравнения нескольких схем RF и EC.

Здесь последняя в таблице комбинация EC 8+7 допускает потерю одновременно до 7-ми нод в кластере, «съедая» меньше полезного пространства (1,875 против 2), чем стандартная репликация. Качество защиты данных, при этом, у нее в 7 раз выше.

Второй важной особенностью ARDFS является самостоятельная синхронизация данных и метаданных, относящихся к хранению.

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

Подсистема синхронизации метаданных для ARDFS размещается абсолютно независимо от смежных подсистем. То есть ни одна другая подсистема в случае своего отказа не может повредить данные ARDFS.

На наш взгляд — это наиболее надежный и правильный путь. Кроме того, с таким подходом появляется дополнительное преимущество. ARDFS можно использовать независимо от vAIR, просто как растянутую «хранилку».

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