Здравейте, читатели на Хабр. С тази статия откриваме серия, която ще говори за хиперконвергентната система AERODISK vAIR, която разработихме. Първоначално искахме да разкажем всичко за всичко в първата статия, но системата е доста сложна, така че ще изядем слона на части.
Нека започнем историята с историята на създаването на системата, да се задълбочим във файловата система ARDFS, която е в основата на vAIR, а също така да поговорим малко за позиционирането на това решение на руския пазар.
В бъдещи статии ще говорим по-подробно за различни архитектурни компоненти (клъстер, хипервайзор, балансьор на натоварването, система за наблюдение и т.н.), процеса на конфигуриране, ще повдигнем проблеми с лицензирането, отделно ще покажем краш тестове и, разбира се, ще пишем за тестване на натоварване и оразмеряване. Също така ще посветим отделна статия на версията на общността на vAIR.
Aerodisk история ли е за системи за съхранение? Или защо започнахме да правим хиперконвергенция на първо място?
Първоначално идеята да създадем собствена хиперконвергенция ни хрумна някъде около 2010 г. По това време на пазара нямаше нито Aerodisk, нито подобни решения (комерсиални кутийни хиперконвергирани системи). Нашата задача беше следната: от набор от сървъри с локални дискове, обединени чрез връзка чрез Ethernet протокол, беше необходимо да създадем разширено хранилище и да стартираме там виртуални машини и софтуерна мрежа. Всичко това трябваше да се реализира без системи за съхранение (защото просто нямаше пари за системи за съхранение и техния хардуер, а ние все още не бяхме измислили собствени системи за съхранение).
Опитахме много решения с отворен код и най-накрая решихме този проблем, но решението беше много сложно и трудно за повторение. Освен това това решение беше в категорията „Работи ли? Не пипай! Следователно, след като решихме този проблем, ние не доразвихме идеята за трансформиране на резултата от нашата работа в пълноценен продукт.
След този инцидент се отдръпнахме от тази идея, но все още имахме чувството, че този проблем е напълно разрешим, а ползите от подобно решение бяха повече от очевидни. Впоследствие пуснатите HCI продукти на чуждестранни компании само потвърдиха това усещане.
Затова в средата на 2016 г. се върнахме към тази задача като част от създаването на пълноценен продукт. По това време все още нямахме никакви отношения с инвеститори, така че трябваше да купим щанд за разработка за нашите собствени не много големи пари. След като събрахме използвани сървъри и комутатори на Avito, се заехме с работата.
Основната първоначална задача беше да създадем наша собствена, макар и проста, но собствена файлова система, която може автоматично и равномерно да разпределя данни под формата на виртуални блокове върху n-тия брой клъстерни възли, които са свързани чрез интерконект чрез Ethernet. В същото време FS трябва да се мащабира добре и лесно и да е независим от съседни системи, т.е. да бъдат отчуждени от vAIR под формата на „просто складово съоръжение“.
Първа vAIR концепция
Съзнателно се отказахме от използването на готови решения с отворен код за организиране на разтегнато съхранение (ceph, gluster, luster и други подобни) в полза на собственото ни развитие, тъй като вече имахме много проектен опит с тях. Разбира се, тези решения сами по себе си са отлични и преди да работим върху Aerodisk, реализирахме повече от един интеграционен проект с тях. Но едно е да изпълните конкретна задача за един клиент, да обучите персонал и, може би, да купите поддръжката на голям доставчик, и съвсем друго нещо е да създадете лесно репликиран продукт, който ще се използва за различни задачи, които ние, като продавач, може дори да знаем за себе си, ние няма да. За втората цел съществуващите продукти с отворен код не бяха подходящи за нас, затова решихме сами да създадем разпределена файлова система.
Две години по-късно няколко разработчици (които комбинираха работата по vAIR с работата по класическата система за съхранение на Engine) постигнаха определен резултат.
До 2018 г. бяхме написали проста файлова система и я допълнихме с необходимия хардуер. Системата комбинира физически (локални) дискове от различни сървъри в един плосък пул чрез вътрешно свързване и ги „нарязва“ на виртуални блокове, след което от виртуалните блокове се създават блокови устройства с различна степен на устойчивост на грешки, върху които се създават виртуални и се изпълнява с помощта на автомобилите на KVM хипервайзора.
Не се занимавахме много с името на файловата система и я нарекохме накратко ARDFS (познайте какво означава))
Този прототип изглеждаше добре (не визуално, разбира се, все още нямаше визуален дизайн) и показа добри резултати по отношение на производителност и мащабиране. След първия реален резултат задвижихме този проект, като организирахме пълноценна среда за разработка и отделен екип, който се занимаваше само с vAIR.
Точно по това време общата архитектура на решението е узряла, която все още не е претърпяла големи промени.
Гмуркане във файловата система ARDFS
ARDFS е основата на vAIR, която осигурява разпределено, устойчиво на грешки съхранение на данни в целия клъстер. Една от (но не единствените) отличителни черти на ARDFS е, че не използва допълнителни специални сървъри за метаданни и управление. Това първоначално е замислено за опростяване на конфигурацията на решението и за неговата надеждност.
Структура за съхранение
Във всички възли на клъстера ARDFS организира логически пул от цялото налично дисково пространство. Важно е да се разбере, че пулът все още не е данни или форматирано пространство, а просто маркиране, т.е. Всички възли с инсталиран vAIR, когато се добавят към клъстера, автоматично се добавят към споделения ARDFS пул и дисковите ресурси автоматично стават споделени в целия клъстер (и достъпни за бъдещо съхранение на данни). Този подход ви позволява да добавяте и премахвате възли в движение без сериозно въздействие върху вече работещата система. Тези. системата е много лесна за мащабиране „на тухли“, добавяйки или премахвайки възли в клъстера, ако е необходимо.
Виртуалните дискове (обекти за съхранение на виртуални машини) се добавят върху пула на ARDFS, които са изградени от виртуални блокове с размер 4 мегабайта. Виртуалните дискове директно съхраняват данни. Схемата за устойчивост на грешки също е зададена на ниво виртуален диск.
Както може би вече се досещате, за отказоустойчивост на дисковата подсистема, ние не използваме концепцията за RAID (Излишен масив от независими дискове), а използваме RAIN (Излишен масив от независими възли). Тези. Толерантността към грешки се измерва, автоматизира и управлява въз основа на възлите, а не на дисковете. Дисковете, разбира се, също са обект за съхранение, те, както всичко останало, се наблюдават, можете да извършвате всички стандартни операции с тях, включително сглобяване на локален хардуерен RAID, но клъстерът работи специално върху възли.
В ситуация, в която наистина искате RAID (например сценарий, който поддържа множество повреди на малки клъстери), нищо не ви пречи да използвате локални RAID контролери и да изградите разтеглено хранилище и RAIN архитектура отгоре. Този сценарий е доста активен и се поддържа от нас, така че ще говорим за него в статия за типичните сценарии за използване на vAIR.
Схеми за устойчивост на грешки при съхранение
Може да има две схеми за устойчивост на грешки за виртуални дискове във vAIR:
1) Коефициент на репликация или просто репликация - този метод на отказоустойчивост е прост като пръчка и въже. Синхронната репликация се извършва между възли с коефициент 2 (2 копия на клъстер) или 3 (съответно 3 копия). RF-2 позволява на виртуален диск да издържи на отказ на един възел в клъстера, но „изяжда“ половината от полезния обем, а RF-3 ще издържи на отказ на 2 възела в клъстера, но запазва 2/3 от полезен обем за нейните нужди. Тази схема е много подобна на RAID-1, тоест виртуален диск, конфигуриран в RF-2, е устойчив на повреда на всеки един възел в клъстера. В този случай всичко ще е наред с данните и дори I/O няма да спре. Когато повреденият възел се върне в експлоатация, ще започне автоматично възстановяване/синхронизиране на данни.
По-долу са дадени примери за разпространение на данни 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) Кодиране за изтриване или кодиране за изтриване (известно също като „излишно кодиране“, „кодиране за изтриване“ или „код за излишък“) съществува, за да реши проблема по-горе. EC е схема за резервиране, която осигурява висока наличност на данни с по-малко натоварване на дисковото пространство в сравнение с репликацията. Принципът на работа на този механизъм е подобен на RAID 5, 6, 6P.
При кодиране процесът на EC разделя виртуален блок (4MB по подразбиране) на няколко по-малки „частове данни“ в зависимост от схемата на EC (например схема 2+1 разделя всеки блок от 4MB на 2 части от 2MB). След това този процес генерира „части с паритет“ за „частите с данни“, които не са по-големи от една от предишните разделени части. Когато декодира, EC генерира липсващите части, като чете „оцелелите“ данни в целия клъстер.
Например виртуален диск със схема 2 + 1 EC, реализиран на 4 клъстерни възела, лесно ще издържи повредата на един възел в клъстера по същия начин като RF-2. В този случай режийните разходи ще бъдат по-ниски, по-специално коефициентът на полезен капацитет за RF-2 е 2, а за EC 2+1 ще бъде 1,5.
За да го опишем по-просто, същността е, че виртуалният блок е разделен на 2-8 (защо от 2 до 8, вижте по-долу) „парчета“ и за тези парчета се изчисляват „парчета“ с паритет с подобен обем.
В резултат на това данните и паритетът се разпределят равномерно във всички възли на клъстера. В същото време, както при репликацията, ARDFS автоматично разпределя данни между възли по такъв начин, че да предотврати съхраняването на идентични данни (копия на данни и техния паритет) на същия възел, за да елиминира възможността от загуба на данни поради на факта, че данните и техният паритет внезапно ще се окажат на един възел за съхранение, който се проваля.
По-долу е даден пример със същата 8 MB виртуална машина и 4 възела, но със схема EC 2+1.
Блокове A и B са разделени на две части от по 2 MB всяка (две, защото 2+1), тоест A1+A2 и B1+B2. За разлика от репликата, A1 не е копие на A2, това е виртуален блок A, разделен на две части, същото като блок B. Общо получаваме два комплекта от 4 MB, всеки от които съдържа две части от по 2 MB. След това за всеки от тези набори се изчислява паритетът с обем не повече от едно парче (т.е. 2 MB), получаваме допълнително + 4 парчета паритет (AP и BP). Общо имаме 2×2 данни + 2×XNUMX паритет.
След това частите се „подреждат“ между възлите, така че данните да не се пресичат с техния паритет. Тези. A1 и A2 няма да бъдат на същия възел като AP.
В случай на повреда на един възел (например и третия), падналият блок B1 ще бъде автоматично възстановен от паритета на BP, който се съхранява на възел № 2, и ще бъде активиран на възела, където има няма B-четност, т.е. парче BP. В този пример това е възел №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, ние едновременно проучихме редица съществуващи решения и открихме, че много синхронизират мета файловата система с помощта на външна разпределена СУБД, която също използваме за синхронизация, но само конфигурации, а не FS метаданни (за тази и други свързани подсистеми в следващата статия).
Синхронизирането на FS метаданни с помощта на външна СУБД е, разбира се, работещо решение, но тогава последователността на данните, съхранявани в ARDFS, ще зависи от външната СУБД и нейното поведение (и, честно казано, това е капризна дама), което в нашето мнение е лошо. Защо? Ако метаданните на FS се повредят, на самите данни на FS също може да се каже „сбогом“, така че решихме да поемем по-сложен, но надежден път.
Ние сами направихме подсистемата за синхронизиране на метаданни за ARDFS и тя живее напълно независимо от съседните подсистеми. Тези. никоя друга подсистема не може да повреди данните на ARDFS. Според нас това е най-надеждният и правилен начин, но времето ще покаже дали наистина е така. В допълнение, този подход има допълнително предимство. ARDFS може да се използва независимо от vAIR, точно като разтеглено хранилище, което със сигурност ще използваме в бъдещи продукти.
В резултат на това чрез разработването на ARDFS получихме гъвкава и надеждна файлова система, която дава избор, където можете да спестите от капацитет или да се откажете от всичко по отношение на производителността, или да направите свръхнадеждно съхранение на разумна цена, но намалявайки изискванията за производителност.
Заедно с проста лицензионна политика и гъвкав модел на доставка (гледайки напред, vAIR се лицензира от възел и се доставя или като софтуер, или като софтуерен пакет), това прави възможно много точното приспособяване на решението към голямо разнообразие от изисквания на клиентите и след това лесно поддържайте този баланс.
Кому е нужно това чудо?
От една страна, можем да кажем, че на пазара вече има играчи, които имат сериозни решения в областта на хиперконвергенцията и всъщност натам вървим. Изглежда това твърдение е вярно, НО...
От друга страна, когато излезем на полето и общуваме с клиентите, ние и нашите партньори виждаме, че това съвсем не е така. Има много задачи за хиперконвергенция, на някои места хората просто не знаеха, че съществуват такива решения, на други изглеждаше скъпо, на трети имаше неуспешни тестове на алтернативни решения, а на трети изобщо забраниха купуването поради санкции. Като цяло полето се оказа неразорано, така че отидохме да вдигнем девствена почва))).
Кога системата за съхранение е по-добра от GCS?
Докато работим с пазара, често ни питат кога е по-добре да използваме класическа схема със системи за съхранение и кога да използваме хиперконвергентна? Много компании, произвеждащи GCS (особено тези, които нямат системи за съхранение в портфолиото си), казват: „Системите за съхранение стават остарели, само хиперконвергентни!“ Това е смело твърдение, но не отразява напълно реалността.
Всъщност пазарът за съхранение наистина се движи към хиперконвергенция и подобни решения, но винаги има едно „но“.
Първо, центровете за данни и ИТ инфраструктурите, изградени по класическата схема със системи за съхранение, не могат лесно да бъдат възстановени, така че модернизацията и завършването на такива инфраструктури все още е наследство за 5-7 години.
Второ, инфраструктурата, която в момента се изгражда в по-голямата си част (което означава Руската федерация) е изградена по класическата схема, използвайки системи за съхранение, и не защото хората не знаят за хиперконвергенцията, а защото пазарът на хиперконвергенция е нов, решения и стандартите все още не са установени, ИТ хората все още не са обучени, имат малко опит, но трябва да изградят центрове за данни тук и сега. И тази тенденция ще продължи още 3-5 години (и след това още едно наследство, виж точка 1).
Трето, има чисто техническо ограничение в допълнителните малки закъснения от 2 милисекунди на запис (с изключение на локалния кеш, разбира се), които са цената на разпределеното хранилище.
Е, нека не забравяме за използването на големи физически сървъри, които обичат вертикалното мащабиране на дисковата подсистема.
Има много необходими и популярни задачи, при които системите за съхранение се държат по-добре от GCS. Тук, разбира се, тези производители, които нямат системи за съхранение в продуктовото си портфолио, няма да се съгласят с нас, но ние сме готови да спорим разумно. Разбира се, ние, като разработчици на двата продукта, определено ще сравним системите за съхранение и GCS в една от бъдещите ни публикации, където ясно ще демонстрираме кое е по-добро при какви условия.
И къде хиперконвергентните решения ще работят по-добре от системите за съхранение?
Въз основа на горните точки могат да се направят три очевидни заключения:
- Когато допълнителните 2 милисекунди латентност за запис, които постоянно се срещат във всеки продукт (сега не говорим за синтетика, наносекунди могат да се показват на синтетика), не са критични, хиперконвергентът е подходящ.
- Когато натоварването от големи физически сървъри може да се превърне в много малки виртуални и разпределено между възли, хиперконвергенцията също ще работи добре там.
- Когато хоризонталното мащабиране е с по-висок приоритет от вертикалното мащабиране, GCS ще се справи добре и там.
Какви са тези решения?
- Всички стандартни инфраструктурни услуги (справочна услуга, поща, EDMS, файлови сървъри, малки или средни ERP и BI системи и др.). Ние наричаме това „общо изчисление“.
- Инфраструктурата на облачните доставчици, където е необходимо бързо и стандартизирано хоризонтално разширяване и лесно „нарязване“ на голям брой виртуални машини за клиенти.
- Инфраструктура за виртуален десктоп (VDI), където много малки потребителски виртуални машини работят и тихо „плуват“ в единен клъстер.
- Клонови мрежи, където всеки клон се нуждае от стандартна, устойчива на грешки, но евтина инфраструктура от 15-20 виртуални машини.
- Всякакви разпределени изчисления (услуги за големи данни, например). Където товарът отива не „в дълбочина“, а „в ширина“.
- Тестови среди, при които са допустими допълнителни малки забавяния, но има бюджетни ограничения, защото това са тестове.
В момента именно за тези задачи сме направили AERODISK vAIR и именно върху тях се фокусираме (засега успешно). Може би скоро това ще се промени, защото... светът не стои неподвижен.
Така…
Това завършва първата част от голяма поредица от статии, в следващата статия ще говорим за архитектурата на решението и използваните компоненти.
Приветстваме въпроси, предложения и конструктивни спорове.
Източник: www.habr.com