Гиперконвергентная система АЭРОДИСК vAIR v2. Часть 2. Файловая система ARDFS и её функциональность

Привет, Хабровчане! В этой статье мы продолжим знакомить вас с новой версией российской гиперконвергентной системы АЭРОДИСК vAIR v2. В данном случае в фокус статьи попадет компонент, отвечающий за распределенное хранение данных – файловая система ARDFS – её назначение, применение, функциональность и особенности.

С первой частью обзора, где мы рассказываем про гипервизор АИСТ, можно ознакомиться по ссылке.

Также вы можете почитать другие наши статьи про vAIR:

Гиперконвергентное решение АЭРОДИСК vAIR. Основа — файловая система ARDFS
Архитектура АЭРОДИСК vAIR или особенности национального кластеростроения

Но для начала вспомним, зачем вообще нужна гиперконвергентная система

Гиперконвергентная система – это, выражаясь простым языком, СХД, сеть и виртуализация в «одной коробке». Она нужна для того, чтобы с минимальными эксплуатационными издержками организовывать отказоустойчивые и легкомасштабируемые большие и маленькие фермы виртуализации: как аппаратной, так и контейнерной.

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

Ниже два примера:

• слева: как строятся инфраструктуры систем виртуализации «по классике», то есть из отдельных СХД, отдельных сетей хранения данных и, соответственно, из отдельных серверов виртуализации (гипервизоров).
• справа: все то же самое, только на гиперконвергентной системе, которая эти же компоненты выполняет внутри себя на программном уровне.

Гиперконвергентный подход в данном случае существенно упрощает и удешевляет строительство и обслуживание виртуальных ферм, т.к. количество объектов управления уменьшается с четырех – СХД, сеть хранения, серверы и система виртуализации – до одного – серверов кластера. Конечно, по-честному можно сказать, что коммутаторы сети передачи данных никуда не пропадают, т.к. они нужны для интерконнекта. Но, во-первых, в классической схеме они тоже присутствуют «за кадром», а, во-вторых, в большинстве случаев они на предприятиях уже есть и эксплуатируются, поэтому выносим их за скобки.

Кроме того, гиперконвергентный подход позволяет с минимальными эксплуатационными издержками масштабировать инфраструктуру почти до бесконечности (в случае vAIR – это пока 1024 узла).

К примеру, если мы хотим увеличить вычислительную мощность и емкость классического виртуального кластера, то нам следует затеять большое строительство, включающее покупку серверов под виртуализацию, расширение портовой емкости SAN, покупку полок, а иногда и контроллеров СХД, а потом коммутацию всего этого добра.

С гиперконвергентом всё куда проще. Расширяется он строго горизонтально по принципу «кирпичей». Взял ещё одну ноду, подключил к кластеру, расширил его вычислительную мощность и емкость. Всё.

Но является ли гиперконвергент «волшебной палочкой», позволяющей полностью отказаться от классических SAN/NAS-инфраструктур хранения? Нет, конечно, остается множество задач, где классические инфраструктуры более эффективны. Хороший пример можно привести иллюстрациями из обычной жизни.

Раньше почти у всех были вот эти устройства.

Но со временем они «сгиперконвергентились» в одно устройство, которое тоже есть почти у всех.

Смартфон прекрасно выполняет функции продвинутой «мыльницы», игровой консоли для простеньких игрушек, ну и, конечно, телефона. Но может ли смартфон выполнять функции профессиональной фототехники, крутой игровой консоли или устойчивой спец. связи?

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

Возвращаемся в ИТ-задачи. Ниже список задач, где, на наш взгляд, гиперконвергент хорош.

Гиперконвергент прекрасно справляется со следующими задачами:

• Стандартные инфраструктурные сервисы (служба каталогов, почта, СЭД, файловые серверы, СУБД, небольшие или средние ERP и BI системы и пр.). Мы это называем «общие вычисления».
• Инфраструктура облачных провайдеров, где необходимо быстро и стандартизованно горизонтально расширяться и легко «нарезать» большое количество виртуальных машин или контейнеров для заказчиков.
• Инфраструктура виртуальных рабочих столов (VDI), где много маленьких пользовательских виртуалок запускаются и спокойно «плавают» внутри единообразного кластера.
• Филиальные сети, где в каждом филиале нужно получить стандартную, отказоустойчивую, но при этом недорогую инфраструктуру из 10-20 виртуальных машин.
• Любые распределенные вычисления (big data-сервисы, например). Там, где нагрузка идет не «вглубь», а «вширь».
• Тестовые среды, где требуется постоянно разворачивать различные комбинации тестовых сред, и при этом есть бюджетные ограничения, ибо это тесты.

А вот ситуации, где лучше работать «по классике», то есть использовать SAN/NAS-подход:

• Там, где невозможно применить виртуализацию в силу тех или иных причин (КЭП), а используется классическая физика.
• Видеонаблюдение, где преобладает потоковая последовательная запись большими блоками.
• Высоконагруженные СУБД, где преобладают случайные операции записи маленькими и средними блоками (биллинг, процессинг, некоторые реализации автоматизированных банковских систем, крупные ERP/BI-системы и т.п.)
• Тяжелая виртуализация, т.е. там, где в силу тех или иных обстоятельств на одну вычислительную ноду приходится одна-две виртуаулки.
• Любые технические ограничения, связанные с наследственной инфраструктурой.

В итоге, по факту, там, где есть много маленьких, хорошо распределяемых «нагрузок», будет хорош гиперконвергент, а где обратная ситуация, т.е. мало, но «больших нагрузок» и они плохо распределяются (и любят «бить в одну точку») – лучше использовать классические SAN/NAS-инфраструктуры. Но все это пока только начало развития гиперконвергентных систем. Что будет дальше – покажет время и технологии.

Что умеет ARDFS?

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

Далее поверх пула создается виртуальный диск для виртуальной машины или пул отдается по протоколам NFS или iSCSI внешнему хосту. На виртуальных дисках хранятся сами данные.

В отличие от классических СХД, ARDFS для отказоустойчивости дисковой подсистемы использует концепцию RAIN (Redundant array of independent Nodes), вместо классического RAID (Redundant array of independent Disks). Т.е. отказоустойчивость измеряется, автоматизируется и управляется, исходя из нод, а не дисков, как в классике. Диски при этом также являются объектом хранилища. Они, как и всё остальное, управляются и мониторятся, с ними можно выполнять все стандартные операции, в том числе и собирать локальный аппаратный RAID для развертывания RAIN-архитектуры поверх RAID-архитектуры, но кластер с точки зрения отказоустойчивости работает именно с нодами.
ARDFS поддерживает две базовые схемы отказоустойчивости:

• Replication factor или фактор репликации – данный метод работает путем выполнения синхронной репликации виртуального диска между нодами с фактором 2 (2 копии на кластер) или 3 (3 копии, соответственно). RF-2 позволяет виртуальному диску выдержать отказ одной ноды в кластере, но «съедает» половину полезного объема, а RF-3 выдержит отказ 2-х нод в кластере, но зарезервирует уже 2/3 полезного объема под свои нужды. Этот метод очень похож на классический RAID-1/10, то есть он очень хорош с точки зрения производительности, но крайне невыгоден с точки зрения объема.
• Метод erasure coding или удаляющее кодирование существует для решения проблемы объема. Принцип работы EC очень похож на RAID 5, 6, 6P. При кодировании процесс EC делит виртуальный блок (в версии vAIR v2 это 64МБ) на несколько меньших «кусков данных» в зависимости от схемы EC (например, схема 2+1 делит каждый блок 64 МБ на 2 куска по 32МБ). Далее для разделенных «кусков данных» генерируются «куски четности» размером не более одной из ранее разделенных частей. При декодировании EC генерирует недостающие куски, считывая «выжившие» данные по всему кластеру.

Например, виртуальный диск с EC-схемой 2 + 1, реализованный на 4-х нодах кластера, выдержит отказ одной ноды в кластере так же, как и RF-2. При этом накладные расходы будут ниже, в частности коэффициент полезной емкости при RF-2 равен 2, а при EC 2+1 он будет 1,5.

Структура управления

Управление распределённой файловой системой ARDFS выполняется из единого интерфейса управления (оттуда же управляется и гипервизор АИСТ) из меню «Хранилище ARDFS».

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

• пул можно задействовать под виртуальную машину АИСТ-а, создав на нем виртуальный диск,
• применить SDS-сценарий и отдать пул в качестве внешней системы хранения по протоколам NFS или iSCSI.

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

Как видно из рисунка, в случае использования пула под виртуальные диски и, соответственно, под виртуальные машины, один пул равен одному виртуальному диску. Это не есть жёсткое ограничение, можно на одном пуле разместить сколько угодно виртуальных дисков, но наша рекомендация делать именно так. Связано это с тем, что ARDFS, как и многие другие распределенные ФС, «любит» множественные маленькие операции, которые можно параллелить, но «не любит» большие и последовательные (не путать с последовательным характером нагрузки). То есть, чем больше небольших объектов, которые можно обрабатывать параллельно, тем лучше с точки зрения общей производительности. И наоборот, чем больше крупных объектов, обработку которых нельзя выполнять паралельно, тем хуже. Именно поэтому данная система прекрасно будет справляться с нагрузкой типа VDI, и совсем не прекрасно с условным видеонаблюдением (во втором случае классические СХД поведут себя лучше).

Оперативная память в ARDFS также может использоваться при локализации операций ввода/вывода. Эта функция не новая, но при этом крайне полезная, поэтому используется и в ARDFS. Её назначение заключается в том, чтобы увеличивать производительность операций чтения и разгружать кластерный интерконнект.

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

Как легко виртуализовать сторонние СХД с помощью ARDFS?

Виртуализация СХД различных производителей давно является интересной, но крайне нетривиальной задачей. К этому снаряду уже подошли многие производители и с переменном успехом эта задача решается, но обычно сложно и дорого. Для чего эта задача вообще может быть актуальна? Сценариев несколько:

• объединить несколько СХД (возможно даже недорогих, одноконтроллерных) или серверов хранения в отказоустойчивый кластер в рамках одного ЦОД-а/серверной
• объединить несколько СХД в растянутое распределенное хранилище в рамках нескольких ЦОД-ов (метрокластер)
• унифицировать управление зоопарком из СХД разных производителей
• с пользой использовать устаревшие СХД, у которых мало умного функционала

В нашей гиперконвергентной системе vAIR мы эту задачу решили на уровне ARDFS и сделали её максимально простой и доступной.

Итак, задача: кроме vAIR-а есть ещё несколько разных СХД поддерживающих блочный доступ по iSCSI и/или FC.

Шаг 1 – это создание пула. Пулы создаются из физических дисков, которые установлены в нодах или… из внешних блочных устройств. Соответственно, чтобы создать пул из внешних блочных устройств, нужно с них пригнать LUN-ы. Для этого на сторонних СХД (одной или нескольких) создаются LUN-ы одинакового размера (технически можно разного, но с точки зрения порядка – это зло) в количестве, кратном количеству нод vAIR-а, по которым эти LUN-ы нужно «размазать». Допустим, в нашем примере – это две СХД (в нашем случае использовали АЭРОДИСК Восток, разумеется, но напоминаем, поддерживаются любые), на каждой из которых создано по три LUN-а. Организовывать отказоустойчивость дисков с помощью RAID-а на СХД в данном случае – шаг опциональный, поскольку отказоустойчивость будет организована уровнем выше, на уровне файловой системы ARDFS (в данном примере использован RF3)

Шаг 2. Созданные LUN-ы физически подключаются к нодам vAIR (очевидно, через коммутаторы FC или Ethernet), на этих нодах выполняется сканирование, и список физических дисков ARDFS пополняется внешними блочными устройствами.

Когда на всех нодах мы увидели все LUN-ы, мы подключаем их к разным нодам и стандартным образом на базе 3-х нод создаем пул RF3, но в качестве дисков выбираем блочные устройства с 2-х внешних СХД.

Все! Пул создан, теперь он распределен по двум нодам, защищен от отказов и поддерживает весь функционал, который есть в vAIR-е. Далее на нем можно создавать виртуальные машины (диски) или отдать стороннему хосту для хранения данных.

При наличии хорошего канала связи и правильно построенной сети можно спокойно растащить ноды и СХД по двум ЦОДам, и вся эта схема будет работать в режиме метрокластера. Само собой, потребуется свидетель (небольшая виртуалка с Линуксом на удаленной площадке).

Резервное копирование

Бэкап для слабаков))), но жить без него все-равно не получается. Снэпшоты и клоны не могут заменить полноценного средства резервного копирования. Поэтому мы этот вопрос проработали отдельно.

WARNING: текущий функционал СРК находится в пред-релизном тесте, а релиз запланирован на начало третьего квартала 2021 года, поэтому в продуктивные инсталляции мы его пока не пускаем и рекомендуем использовать любые классические внешние СРК, которые умеют бэкапить KVM, но… поскольку в комментариях к предыдущей статье тема бэкапа вызвала бурный интерес, общую логику работы этого решения опишем здесь и сейчас, а более детально – ближе к релизу.

В vAIR-е есть два метода резервного копирования:

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

На основе агентов внутри ОС (соответственно есть агенты для Линукса и Винды). Этим способом нужно пользоваться для бэкапа, если вам нужно восстанавливать ВМ не целиком (например, если она очень большая), а конкретный файл. Также этот способ необходим для бэкапа СУБД, служб каталогов и других капризных, но нужных систем.

Механизм работы СРК следующий.

• Создается внешняя NFS-шара или пул ARDFS на ноде, где нет продуктивных ВМ. В этом пункте назначения создается бэкап-репозиторий, где в будущем будут храниться бэкапы и их метаданные.
• Для целевой ВМ, руками или по расписанию, запускается первая задача резервного копирования, в рамках которой создается теневой файл для накопления изменений, которые будут происходить по ходу задачи РК.
• С помощью Restful API выполняется запуск первой полной копии ВМ в бэкап-репозиторий
• По завершению операции первого полного резервного копирования происходит слияние полученной резервной копии и теневого файла с изменениями, после чего теневой файл удаляется, а в репозитории устанавливаются временные метки и другие метаданные, которые пригодятся в дальнейшем.
• Любая следующая задача резервного копирования будет автоматически инкрементальной, перед стартом задания система сравнит состояния ВМ продуктивной и той, что есть в репозитории, и запишет разницу тем же механизмом, что описан выше.
• В итоге мы получим н-ное количество точек восстановления, с любой из которых мы можем восстановить нашу ВМ.
• Если мы делали бэкап с помощью агента, то у нас появляется ещё приятная опция восстановить отдельный файл без необходимости восстанавливать ВМ целиком.

Подводим итог

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

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

Кроме этого раз в квартал мы будет организовывать углубленные технические онлайн курсы, где будем обучать всех желающих работе с нашими СХД и гиперконвергентной системой vAIR. Оставить заявку на участие можно по этой ссылке.

Всем спасибо за внимание.