🥇Хиперконвергентно решение AERODISK vAIR. Основата — файловата система ARDFS

Здравейте, читатели на Хабра. С тази статия отваряме цикъл, който ще разкаже за разработената от нас хиперконвергентна система AERODISK vAIR. Първоначално искахме с първата статия да разкажем всичко за всичко, но системата е доста сложна, затова ще я разгледаме на части.

Нека започнем с историята на създаването на системата, ще се задълбочим във файловата система ARDFS, която е основата на vAIR, и ще споделим разсъждения за позиционирането на това решение на руския пазар.

В бъдещите статии ще разгледаме по-подробно различните архитектурни компоненти (клъстър, хипервизор, балансировчик на натоварването, система за мониторинг и др.), процеса на настройка, ще повдигнем въпроси за лицензиране, отделно ще покажем краш-тестовете и, разбира се, ще пишем за натоварващото тестване и сайзинга. Също така ще посветим отделна статия на community-версията на vAIR.

Аеродиск – това е нещо свързано с СХД? Или защо изобщо започнахме да се занимаваме с хиперконвергентност?

Първоначалната идея да създадем свой хиперконвергентен продукт дойде някъде около 2010 година. Тогава нямаше нито Аеродиск, нито подобни решения (комерсиални готови хиперконвергентни системи) на пазара. Задачата ни беше следната: от набор от сървъри с локални дискове, свързани с интерконект по протокол Ethernet, да се направи разширено хранилище и там да се стартират виртуални машини и софтуерна мрежа. Всичко това трябваше да се реализира без СХД (защото нямаше средства за СХД и нейните компоненти, а своя СХД все още не бяхме изобретили).

Опитахме много open source решения и в крайна сметка решихме тази задача, но решението беше много сложно и трудно за повторение. Освен това, това решение беше от типа 'Работи? Не го пипай!'. Затова, след като решихме задачата, не продължихме с развитието на идеята да превърнем резултата от нашата работа в завършен продукт.

След този случай се дистанцирахме от тази идея, но усещането, че задачата е напълно решима, все пак не ни напускаше, а ползата от такова решение беше повече от очевидна. Впоследствие новите HCI-продукти на чуждестранни компании само потвърдиха това усещане.

Затова в средата на 2016-та година се върнахме към тази задача в контекста на създаването на пълноценен продукт. Тогава все още нямахме никакви взаимоотношения с инвеститори, поради което стендът за разработка трябваше да бъде закупен с нашите не толкова големи средства. Набрали на Авито втора ръка сървъри и комутатори, започнахме работа.

Основната начална задача беше създаването на собствена, макар и проста, файловата система, която да може автоматично и равномерно да разпределя данни под формата на виртуални блокове на n-брой нодове в кластера, свързани помежду си чрез Ethernet. При това файловата система трябва да се мащабира добре и лесно и да бъде независима от съседни системи, т.е. да може да се отделя от vAIR под формата на „просто хранилище“.

Първа концепция на vAIR

Умишлено се отказахме от използването на готови open source решения за организиране на разпределено хранилище (ceph, gluster, lustre и подобни) в полза на собствена разработка, тъй като вече имахме много проектен опит с тях. Безспорно, сами по себе си тези решения са отлични и преди работата по Аеродиска сме реализирали не един интеграционен проект с тях. Но едно е да реализираш конкретна задача на един клиент, да обучиш персонал и евентуално да получиш поддръжка от голям вендор, и съвсем друго е да създадеш лесно тиражируем продукт, който да бъде използван за различни задачи, за които ние, като вендор, може би даже сами няма да знаем. За втората цел съществуващите open source продукти не отговаряха на нашите нужди, затова решихме сами да разработим разпределена файловата система.
След две години усилията на няколко разработчици (които съчетаваха работата си по vAIR с работата по класическата СХД Engine) донесоха определени резултати.

До 2018-та година написахме най-простата файловата система и я допълнихме с необходимата обвивка. Системата обединяваше физическите (локални) дискове от различни сървъри в един плосък пул чрез вътрешен интерконект и ги „разрязваше“ на виртуални блокове, от които след това се създаваха блочни устройства с известна степен на отказоустойчивост, на които с помощта на хипервизор KVM се създаваха и изпълняваха виртуални машини.

С името на файловата система не се затруднявахме твърде много и я нарекохме лаконично ARDFS (познайте какво значи това))

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

Точно по това време се оформи общата архитектура на решението, която до днешен ден не е претърпяла сериозни промени.

Преминаваме към файловата система ARDFS

ARDFS е основата на vAIR, която осигурява разпределено отказоустойчиво съхранение на данни за целия клъстер. Една от (но не единствената) отличителна черта на ARDFS е, че тя не използва никакви допълнителни на посветени сървъри методи и управление. Това беше замислено от самото начало за опростяване на конфигурацията на решението и за неговата надеждност.

Структура на съхранение

В рамките на всички възли на клъстера ARDFS организира логичен пул от всичкото налично дисково пространство. Важно е да се разбере, че пулът все още не е данни и не е форматирано пространство, а просто разпределение, т.е. всякакви възли с инсталиран vAIR при добавяне към клъстера автоматично се добавят към общия пул на ARDFS и дисковите ресурси автоматично стават общи за целия клъстер (и достъпни за бъдещо съхранение на данни). Този подход позволява в движение да добавяте и премахвате възли без никакво сериозно влияние върху вече работещата система. Т.е. системата е много лесна за мащабиране с "кирпичи", добавяйки или премахвайки възли в клъстера при необходимост.

Върху пула ARDFS се добавят виртуални дискове (обекти за съхранение за виртуалките), които се изграждат от виртуални блокове с размер 4 мегабайта. На виртуалните дискове се съхраняват данните. На ниво виртуални дискове също така се задава схема за отказоустойчивост.

Както вече се подразбира, за отказоустойчивостта на дисковата подсистема не използваме концепцията RAID (Redundant array of independent Disks), а вместо това използваме RAIN (Redundant array of independent Nodes). Тоест, отказоустойчивостта се измерва, автоматизира и управлява в зависимост от нодите, а не от дисковете. Дисковете, разбира се, също са обект на съхранение, те, както и всичко останало, се мониторят и с тях може да се извършват всички стандартни операции, включително и изграждане на локален хардуер RAID, но клъстерът оперира именно с нодите.

В ситуация, когато много искате RAID (например, сценарий, поддържащ множество откази на малки клъстери), нищо не пречи да се използват локални RAID-контролери, а отгоре да се изградят разпределено хранилище и RAIN-архитектура. Такъв сценарий е напълно жизнеспособен и се поддържа от нас, затова ще ви разкажем за него в статията за типични сценарии за употреба на vAIR.

Схеми за отказоустойчивост на хранилища

Може да има две схеми за отказоустойчивост на виртуалните дискове в vAIR:

1) Replication factor или просто репликация – този метод на отказоустойчивост е прост "като пръчка и въже". Извършва се синхронна репликация между нодите с фактор 2 (2 копия на клъстера) или 3 (съответно 3 копия). RF-2 позволява на виртуалния диск да издържи отказа на една нода в клъстера, но "изяжда" половината полезен обем, а RF-3 би издържал отказа на 2 ноди в клъстера, но би резервирал вече 2/3 от полезния обем за своите нужди. Тази схема много напомня на RAID-1, тоест виртуалният диск, конфигуриран в RF-2, е устойчив на отказа на всяка една нода в клъстера. В този случай с данните всичко ще бъде в ред и дори вход-изходът няма да спре. Когато повредената нода се върне в строй, ще започне автоматично възстановяване/синхронизация на данните.

По-долу са приведени примери за разпределение на данните RF-2 и RF-3 при нормален режим и в ситуации на откази.

Имаме виртуална машина с обем 8MB уникални (полезни) данни, която работи на 4 нода vAIR. Разбира се, в реалността навярно няма да бъдат създадени толкова малко данни, но за схемата, която отразява логиката на ARDFS, този пример е най-разбираем. AB са виртуални блокове по 4MB, съдържащи уникални данни от виртуалната машина. При RF-2 се създават две копия на тези блокове A1+A2 и B1+B2, съответно. Тези блокове се „разпределят“ по нодовете, като се избягва наличието на едни и същи данни на един нод, т.е. копия A1 няма да бъде на един и същи нод с копия A2. С B1 и B2 е аналогично.

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

Така виртуалният диск (и ВМ, съответно) лесно ще преживее отказ на един нод в схемата RF-2.

Схемата с репликация, въпреки простотата и надеждността си, страда от същата болест, като RAID1 – недостатъчно полезно пространство.

2) Erasure coding или изтриване на кодове (също известно като „излишно кодиране“, „изтриващо кодиране“ или „код на излишъчност“) съществува именно за да реши горепосочената проблематика. EC е схема на излишъци, която осигурява висока наличност на данните с по-малки разходи за дисково пространство в сравнение с репликацията. Принципът на работа на този механизъм е подобен на RAID 5, 6, 6P.

При кодиране процесът EC разделя виртуалния блок (по подразбиране 4MB) на няколко по-малки „парчета данни“ в зависимост от схемата EC (например, схемата 2+1 разделя всеки блок от 4MB на 2 парчета по 2MB). След това този процес генерира „парчета по parity“ с размер не повече от едно от предходно разделените парчета. При декодиране EC генерира липсващите парчета, като прочита „оцелелите“ данни в целия кластер.

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

Ако опишем по-просто, същността е, че виртуалният блок се разделя на 2-8 (защо от 2 до 8 вижте по-долу) „парчета“, а за тези парчета се изчисляват „парчета“ по parity с аналогичен обем.

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

По-долу е пример, с тази съща виртуалка от 8 MB и 4 нода, но вече при схема EC 2+1.

Блоковете A и B се разделят на два стука по 2 MB (на две, защото 2+1), т.е. на A1+A2 и B1+B2. В отличие от репликата, A1 не е копие на A2, а виртуален блок A, разделен на две части, също и с блок B. Така получаваме два набора по 4MB, в които всеки съдържа по два двумигибайтови стука. След това, за всеки от тези набори се изчислява четността с обем не повече от един стук (т.е. 2 MB), получаваме допълнително + 2 стука четност (A-P и B-P). В крайна сметка имаме 4×2 данни + 2×2 четност.

След това стуковете се "разпределят" по нодовете така, че данните да не се пресекат с тяхната четност. Т.е. A1 и A2 няма да лежат на един и същ нод с A-P.

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

Сигурен съм, че у читателя възниква въпросът:

„Всичко, което описахте, отдавна е реализирано и от конкурентите, и в решения с отворен код, каква е разликата на вашата реализация на EC в ARDFS?“

А след това ще последват интересни особености на работата на 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 пъти по-добре, което прави този механизъм на защита, въпреки че е по-сложен, значително по-привлекателен в ситуации, когато трябва да се осигури максимална надеждност при недостиг на дисково пространство. Важно е да се разбере, че всяко „плюсче“ към X или Y ще бъде допълнителен разход за производителността, затова в триъгълника между надеждността, икономията и производителността трябва да се избира много внимателно. Поради тази причина ще посветим отделна статия на размерирането на отдалеченото кодиране.

Надеждност и автономност на файловата система

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

Синхронизация на метаданните на ФС с помощта на външна СУБД е работно решение, но тогава консистентността на данните, съхранявани на ARDFS, ще зависи от външната СУБД и нейното поведение (което, да кажем направо, е капризно), което, според нас, е лошо. Защо? Ако метаданните на ФС са повредени, самите данни на ФС също ще кажат "сбогом", затова решихме да поемем по по-сложен, но надежден път.

Подсистемата за синхронизация на метаданните за ARDFS я направихме сами и тя функционира напълно независимо от съседните подсистеми. Т.е. нито една друга подсистема не може да повреди данните на ARDFS. Според нас това е най-надеждният и правилен път, а всъщност дали е така – ще покаже времето. Освен това, с такъв подход се появява допълнително предимство. ARDFS може да се използва независимо от vAIR, просто като разширено хранилище, което непременно ще използваме в бъдещите продукти.

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

Вместо с проста лицензна политика и гъвкав модел на доставка (предварително, vAIR е лицензирана по ноди, а се предлага или като софтуер, или като ПАК), това позволява много точно да настроим решението според най-различните изисквания на клиентите и впоследствие лесно да поддържаме този баланс.

Кому е нужно това чудо?

От една страна, може да се каже, че на пазара вече има играчи с сериозни решения в областта на хиперконвергенцията, и към които ние всъщност се стремим. Изглежда, че това твърдение е вярно, НО…

От друга страна, когато излизаме "в полето" и общуваме с клиентите, ние и нашите партньори виждаме, че не е точно така. Има много задачи за хиперконвергенцията, където хората просто не са знаели, че такива решения съществуват, на места това е изглеждало скъпо, на места е имало неуспешни тестове на алтернативни решения, а някъде е забранено изобщо да се купува, заради санкции. Общо взето, полето се оказа непрано, затова решихме да започнем да обработваме целината))).

Кога НСД е по-добра от ГКС?

В хода на работата с пазара често ни питат кога е по-добре да се прилага класическата схема с СХД, а кога – хиперконвергентна? Много компании – производители на ГКС (особено тези, които нямат СХД в портфолиото си) казват: «СХД остарява, хиперконвергентно само!». Това е смело твърдение, но не напълно отразява действителността.

Правяки това изявление, пазарът на СХД наистина се накланя към хиперконвергентните решения, но винаги има «но».

На първо място, построените ЦОД и ИТ инфраструктури по класическата схема с СХД не могат просто така да бъдат преобразувани, затова модернизацията и надстрояването на такива инфраструктури са наследство за поне 5-7 години.

На второ място, инфраструктурите, които се изграждат в момента масово (в Русия) са по класическата схема с използване на СХД, не защото хората не знаят за хиперконвергентността, а защото пазарът на хиперконвергентност е нов, решенията и стандартите все още не са установени, ИТ специалистите не са обучени, опитът е малко, а изграждането на ЦОД е необходимо тук и сега. Тази тенденция ще продължи още 3-5 години (и след това още наследство, вижте точка 1).

На трето място, чисто техническо ограничение в допълнителните малки закъснения от 2 милисекунди при запис (разбира се, без да се отчита локалното кеширане), които са цената за разпределено съхранение.

И нека не забравяме използването на големи физически сървъри, които обичат вертикалното мащабиране на дисковата подсистема.

Има много важни и популярни задачи, при които СХД се представя по-добре, отколкото ГКС. Разбира се, производителите, които нямат СХД в продуктовото си портфолио, няма да се съгласят с нас, но ние сме готови да спорим аргументирано. Разбира се, като разработчици на два от тези продукти, в една от бъдещите публикации непременно ще направим сравнение между СХД и ГКС, където наглядно ще демонстрираме при какви условия кое е по-добро.

А къде хиперконвергентните решения ще работят по-добре от СХД?

На базата на горните твърдения, можем да направим три очевидни заключения:

Там, където допълнителните 2 милисекунди закъснение при запис, които последователно възникват в продуктивна среда (в момента не става въпрос за синтетичен тест, при него може да се показват и наносекунди), не са критични, хиперконвергентното решение ще е подходящо.
Там, където натоварването от големи физически сървъри може да се трансформира в много малки виртуални и да се разпредели по възлите, там хиперконвергентните решения също ще бъдат успешни.
Там, където хоризонталното мащабиране е с по-голям приоритет от вертикалното, хиперконвергентните системи също ще намерят своето място.

Какви са тези решения?

Всички стандартни инфраструктурни услуги (каталогова услуга, поща, системи за електронен документооборот, файлови сървъри, малки или средни ERP и BI системи и др.). Ние ги наричаме „общи изчисления“.
Инфраструктура на облачни доставчици, където е необходимо бързо и стандартизирано хоризонтално разширяване и лесно „разделяне“ на голямо количество виртуални машини за клиентите.
Инфраструктура виртуални работни桌логове (VDI), където много малки потребителски виртуалки се стартират и плавно „плават“ в еднороден кластер.
Клонови мрежи, където във всеки клон е нужно да се получи стандартна, отказоустойчива, но и икономична инфраструктура от 15-20 виртуални машини.
Всякакви разпределени изчисления (например big data услуги). Там, където натоварването се разпространява не 'в надолнище', а 'в ширина'.
Тестови среди, където малки забавяния са допустими, но има бюджетни ограничения, тъй като става въпрос за тестове.

Към момента именно за тези задачи създадохме AERODISK vAIR и именно на тях основаваме фокуса си (все още успешно). Възможно е скоро това да се промени, тъй като светът не стои на едно място.