Хиперконвергирани раствори AERODISK vaIR. Основата е датотечен систем ARDFS

Здраво, читатели на Хабр. Со оваа статија отвораме серијал кој ќе зборува за хиперконвергираниот систем AERODISK vAIR што го развивме. Првично, сакавме да кажеме сè за сè во првата статија, но системот е прилично сложен, па затоа ќе го јадеме слонот на делови.

Да ја започнеме приказната со историјата на создавањето на системот, да истражуваме во датотечниот систем ARDFS, кој е основа на vAIR, а исто така да разговараме малку за позиционирањето на ова решение на рускиот пазар.

Во идните написи подетално ќе зборуваме за различни архитектонски компоненти (кластер, хипервизор, балансер на оптоварување, систем за следење итн.), за процесот на конфигурација, ќе ги покренеме прашањата за лиценцирање, одделно ќе прикажуваме тестови за несреќа и, се разбира, ќе пишуваме за тестирање на оптоварување и димензионирање. Исто така, ќе посветиме посебна статија на верзијата на заедницата на vAIR.

Дали Aerodisk е приказна за системи за складирање? Или зошто на прво место почнавме да правиме хиперконвергенција?

Првично, идејата да создадеме сопствена хиперконвергенција ни дојде некаде околу 2010 година. Во тоа време, на пазарот немаше ниту Aerodisk ниту слични решенија (комерцијални хиперконвергирани системи во кутии). Нашата задача беше следна: од збир на сервери со локални дискови, обединети со интерконекција преку етернет протоколот, беше неопходно да се создаде продолжено складирање и таму да се лансираат виртуелни машини и софтверска мрежа. Сето ова мораше да се имплементира без системи за складирање (бидејќи едноставно немаше пари за системи за складирање и неговиот хардвер, а ние сè уште немавме измислено сопствени системи за складирање).

Пробавме многу решенија со отворен код и конечно го решивме овој проблем, но решението беше многу сложено и тешко да се повтори. Освен тоа, ова решение беше во категоријата „Дали функционира? Не допирајте! Затоа, откако го решивме тој проблем, не ја развивме понатаму идејата за трансформација на резултатот од нашата работа во полноправен производ.

По тој инцидент се оддалечивме од оваа идеја, но сепак имавме чувство дека овој проблем е целосно решлив, а придобивките од таквото решение беа повеќе од очигледни. Последователно, објавените HCI производи на странски компании само го потврдија ова чувство.

Затоа, во средината на 2016 година, се вративме на оваа задача како дел од создавањето на полноправен производ. Во тоа време сè уште немавме никакви односи со инвеститорите, па моравме да купиме штанд за развој за наши не многу големи пари. Откако собравме користени сервери и прекинувачи на Avito, се фативме за работа.

Главната почетна задача беше да создадеме сопствен, иако едноставен, но наш сопствен датотечен систем, кој би можел автоматски и рамномерно да дистрибуира податоци во форма на виртуелни блокови на n-тиот број кластерски јазли, кои се поврзани со интерконекција преку Ethernet. Во исто време, FS треба добро и лесно да се скалира и да биде независен од соседните системи, т.е. да се отуѓи од vAIR во форма на „само складиште“.

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

Намерно ја напуштивме употребата на готови решенија со отворен код за организирање на затегнато складирање (ceph, gluster, luster и слично) во корист на нашиот сопствен развој, бидејќи веќе имавме големо проектно искуство со нив. Секако, самите овие решенија се одлични и пред да работиме на Аеродиск, со нив реализиравме повеќе од еден проект за интеграција. Но, едно е да се имплементира одредена задача за еден клиент, да се обучи персоналот и, можеби, да се купи поддршката од голем продавач, а сосема друго е да се создаде лесно реплициран производ кој ќе се користи за различни задачи, кои ние, како продавач, може дури и да знаеме за себе, ние нема. За втората цел, постоечките производи со отворен код не ни беа соодветни, па решивме сами да креираме дистрибуиран датотечен систем.
Две години подоцна, неколку програмери (кои ја комбинираа работата на vAIR со работата на класичниот систем за складирање Engine) постигнаа одреден резултат.

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

Не се замаравме премногу со името на датотечен систем и кратко го нарековме ARDFS (погодете што значи))

Овој прототип изгледаше добро (не визуелно, се разбира, сè уште немаше визуелен дизајн) и покажа добри резултати во однос на перформансите и скалирањето. По првиот реален резултат, го започнавме овој проект, организирајќи полноправно развојно опкружување и посебен тим кој се занимаваше само со vAIR.

Само до тоа време, општата архитектура на решението беше созреана, која сè уште не претрпе големи промени.

Нуркање во датотечен систем ARDFS

ARDFS е основата на vAIR, која обезбедува дистрибуирано складирање на податоци толерантно на грешки низ целиот кластер. Една од (но не и единствената) карактеристична карактеристика на ARDFS е тоа што не користи никакви дополнителни посветени сервери за метаподатоци и управување. Ова првично беше замислено за да се поедностави конфигурацијата на решението и за неговата сигурност.

Структура на складирање

Во сите јазли на кластерот, ARDFS организира логички базен од целиот достапен простор на дискот. Важно е да се разбере дека базенот сè уште не е податочен или форматиран простор, туку едноставно обележување, т.е. Сите јазли со инсталиран vAIR, кога се додаваат во кластерот, автоматски се додаваат во споделениот ARDFS базен и ресурсите на дискот автоматски се споделуваат низ целиот кластер (и достапни за складирање податоци во иднина). Овој пристап ви овозможува да додавате и отстранувате јазли во лет без сериозно влијание врз веќе работи системот. Оние. системот е многу лесен за скалирање „во тули“, додавајќи или отстранувајќи ги јазлите во кластерот доколку е потребно.

На врвот на базенот ARDFS се додаваат виртуелни дискови (објекти за складирање на виртуелни машини), кои се изградени од виртуелни блокови со големина од 4 мегабајти. Виртуелните дискови директно складираат податоци. Шемата за толеранција на грешки е поставена и на ниво на виртуелен диск.

Како што веќе можевте да претпоставите, за толеранција на грешки на подсистемот на дискот, не го користиме концептот RAID (Redundant array of независни дискови), туку користиме RAIN (Redundant array of независно јазли). Оние. Толеранцијата на грешки се мери, автоматизира и управува врз основа на јазлите, а не на дисковите. Дисковите, се разбира, се исто така објект за складирање, тие, како и сè друго, се следат, можете да ги извршите сите стандардни операции со нив, вклучително и составување на локален хардверски 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 се виртуелни блокови од 4 MB што содржат уникатни податоци за виртуелната машина. RF-2 создава две копии од овие блокови A1+A2 и B1+B2, соодветно. Овие блокови се „поставени“ низ јазлите, избегнувајќи го пресекот на истите податоци на истиот јазол, односно копијата А1 нема да се наоѓа на истиот јазол како копијата А2. Истото со Б1 и Б2.

Ако еден од јазлите не успее (на пример, јазолот бр. 3, кој содржи копија од B1), оваа копија автоматски се активира на јазолот каде што нема копија од неговата копија (т.е. копија од B2).

Така, виртуелниот диск (и VM, соодветно) лесно може да го преживее неуспехот на еден јазол во шемата RF-2.

Шемата за репликација, иако е едноставна и сигурна, страда од истиот проблем како RAID1 - нема доволно простор за користење.

2) Кодирањето за бришење или кодирањето за бришење (исто така познато како „непотребно кодирање“, „кодирање за бришење“ или „шифра за вишок“) постои за да се реши проблемот погоре. EC е шема за вишок што обезбедува висока достапност на податоци со помал простор на дискот во споредба со репликацијата. Принципот на работа на овој механизам е сличен на RAID 5, 6, 6P.

При кодирање, EC процесот го дели виртуелниот блок (4 MB стандардно) на неколку помали „парчиња податоци“ во зависност од шемата на 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.

Блоковите А и Б се поделени на два дела од по 2 MB (два затоа што 2+1), односно A1+A2 и B1+B2. За разлика од репликата, А1 не е копија на А2, тоа е виртуелен блок А, поделен на два дела, ист со блокот Б. Севкупно, добиваме два сета од 4 MB, од кои секоја содржи по две парчиња од два MB. Следно, за секое од овие множества, паритетот се пресметува со волумен од не повеќе од едно парче (т.е. 2 MB), добиваме дополнителни + 2 парчиња паритет (АП и БП). Вкупно имаме 4×2 податоци + 2×2 паритет.

Следно, парчињата се „поставени“ меѓу јазлите, така што податоците не се вкрстуваат со нивниот паритет. Оние. A1 и A2 нема да бидат на истиот јазол како AP.

Во случај на неуспех на еден јазол (на пример, и третиот), паднатиот блок Б1 автоматски ќе се врати од паритетот на BP, кој е зачуван на јазолот бр. 2, и ќе се активира на јазолот каде што има нема Б-паритет, т.е. парче БП. Во овој пример, ова е јазол бр. 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 работи локално на сите јазли на кластерот и ги синхронизира користејќи свои средства преку посветени етернет интерфејси. Важно е дека ARDFS независно ги синхронизира не само податоците, туку и метаподатоците поврзани со складирањето. Додека работевме на ARDFS, истовремено проучувавме голем број постоечки решенија и откривме дека многумина ја синхронизираат мета на датотечниот систем користејќи надворешен дистрибуиран DBMS, кој исто така го користиме за синхронизација, но само конфигурации, а не метаподатоци FS (за овој и други поврзани потсистеми во следната статија).

Синхронизирањето FS метаподатоци со помош на надворешен DBMS е, се разбира, работно решение, но тогаш конзистентноста на податоците зачувани на ARDFS ќе зависи од надворешниот DBMS и неговото однесување (и, искрено кажано, тоа е каприциозна дама), која во нашето мислење е лошо. Зошто? Ако метаподатоците на FS се оштетат, на самите податоци на FS може да се каже и „збогум“, па затоа решивме да тргнеме по сложен, но сигурен пат.

Сами го направивме потсистемот за синхронизација на метаподатоци за ARDFS и тој живее целосно независно од соседните потсистеми. Оние. ниту еден друг потсистем не може да ги корумпира податоците од ARDFS. Според нас, ова е најсигурниот и најточниот начин, но времето ќе покаже дали е тоа навистина така. Покрај тоа, постои дополнителна предност со овој пристап. ARDFS може да се користи независно од vAIR, исто како и растегнатото складирање, кое секако ќе го користиме во идните производи.

Како резултат на тоа, со развивање на ARDFS, добивме флексибилен и сигурен датотечен систем кој дава избор каде што можете да заштедите на капацитет или да се откажете од сè за перформансите или да направите ултра доверливо складирање по разумна цена, но со намалување на барањата за изведба.

Заедно со едноставна политика за лиценцирање и флексибилен модел на испорака (гледајќи напред, vAIR е лиценциран по јазол и се испорачува или како софтвер или како софтверски пакет), ова ви овозможува многу прецизно да го приспособите решението на широк спектар на барања на клиентите, а потоа лесно одржувајте ја оваа рамнотежа.

На кого му треба ова чудо?

Од една страна, можеме да кажеме дека веќе има играчи на пазарот кои имаат сериозни решенија на полето на хиперконвергенцијата и токму тука се движиме. Се чини дека оваа изјава е вистинита, НО...

Од друга страна, кога излегуваме на полињата и комуницираме со клиентите, ние и нашите партнери гледаме дека тоа воопшто не е така. Има многу задачи за хиперконвергенција, на некои места луѓето едноставно не знаеја дека постојат такви решенија, во други се чинеше скапо, во други имаше неуспешни тестови на алтернативни решенија, а на други воопшто забрануваат купување поради санкции. Во принцип, полето се покажа како неорано, па отидовме да подигнеме девица почва))).

Кога системот за складирање е подобар од GCS?

Додека работиме со пазарот, често нѐ прашуваат кога е подобро да се користи класична шема со системи за складирање и кога да се користи хиперконвергентна? Многу компании кои произведуваат GCS (особено оние кои немаат системи за складирање во своето портфолио) велат: „Системите за складирање стануваат застарени, само хиперконвергирани! Ова е смела изјава, но не ја одразува целосно реалноста.

За волја на вистината, пазарот за складирање навистина се движи кон хиперконвергенција и слични решенија, но секогаш постои „но“.

Прво, центрите за податоци и ИТ инфраструктурите изградени според класичната шема со системи за складирање не можат лесно да се обноват, така што модернизацијата и комплетирањето на таквите инфраструктури сè уште е наследство 5-7 години.

Второ, инфраструктурата што во моментов се гради во најголем дел (се мисли на Руската Федерација) е изградена според класичната шема користејќи системи за складирање, и не затоа што луѓето не знаат за хиперконвергенција, туку затоа што пазарот на хиперконвергенција е нов, решенија и стандардите сè уште не се воспоставени, ИТ луѓето сè уште не се обучени, имаат мало искуство, но треба да градат центри за податоци овде и сега. И овој тренд ќе трае уште 3-5 години (а потоа уште едно наследство, види точка 1).

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

Па, да не заборавиме на употребата на големи физички сервери кои сакаат вертикално скалирање на потсистемот на дискот.

Има многу неопходни и популарни задачи каде системите за складирање се однесуваат подобро од GCS. Овде, се разбира, оние производители кои немаат системи за складирање во нивното портфолио на производи нема да се согласат со нас, но ние сме подготвени разумно да се расправаме. Се разбира, ние, како развивачи на двата производи, дефинитивно ќе ги споредиме системите за складирање и GCS во една од нашите идни публикации, каде јасно ќе покажеме што е подобро под кои услови.

И каде хиперконвергираните решенија ќе работат подобро од системите за складирање?

Врз основа на горенаведените точки, може да се извлечат три очигледни заклучоци:

1. Онаму каде што дополнителни 2 милисекунди латентност за снимање, кои постојано се појавуваат во кој било производ (сега не зборуваме за синтетика, наносекундите може да се прикажат на синтетиката), се некритични, хиперконвергентниот е погоден.
2. Онаму каде што оптоварувањето од големите физички сервери може да се претвори во многу мали виртуелни и да се дистрибуира меѓу јазлите, хиперконвергенцијата исто така ќе работи добро таму.
3. Онаму каде што хоризонталното скалирање е повисок приоритет од вертикалното скалирање, GCS и таму ќе се справи многу добро.

Кои се овие решенија?

1. Сите стандардни инфраструктурни услуги (услуга за именици, пошта, EDMS, сервери за датотеки, мали или средни ERP и BI системи, итн.). Ова го нарекуваме „општо пресметување“.
2. Инфраструктурата на давателите на облак, каде што е неопходно брзо и стандардизирано хоризонтално проширување и лесно „сечење“ на голем број виртуелни машини за клиентите.
3. Виртуелна десктоп инфраструктура (VDI), каде што работат многу мали кориснички виртуелни машини и тивко „пловат“ во униформен кластер.
4. Мрежи на филијали, каде што секоја гранка има потреба од стандардна, толерантна за грешки, но евтина инфраструктура од 15-20 виртуелни машини.
5. Секое дистрибуирано пресметување (услуги за големи податоци, на пример). Онаму каде што товарот не оди „во длабочина“, туку „во ширина“.
6. Тест околини каде што се прифатливи дополнителни мали доцнења, но има буџетски ограничувања, бидејќи тоа се тестови.

Во моментов токму за овие задачи го направивме AERODISK vair и токму на нив се фокусираме (досега успешно). Можеби ова наскоро ќе се промени, бидејќи ... светот не мирува.

Значи

Ова го комплетира првиот дел од големата серија написи; во следната статија ќе зборуваме за архитектурата на решението и употребените компоненти.

Ги поздравуваме прашањата, предлозите и конструктивните спорови.

Извор: www.habr.com