Здраво читаоци Хабра. Овим чланком отварамо серију која ће говорити о хиперконвергентном систему АЕРОДИСК вАИР који смо развили. У почетку смо хтели у првом чланку да испричамо све о свему, али систем је прилично сложен, па ћемо слона јести у деловима.
Почнимо причу са историјом настанка система, удубимо се у систем датотека АРДФС, који је основа вАИР-а, а такође мало причамо о позиционирању овог решења на руском тржишту.
У будућим чланцима ћемо детаљније говорити о различитим архитектонским компонентама (кластер, хипервизор, балансатор оптерећења, систем за праћење, итд.), процесу конфигурације, покренути питања лиценцирања, посебно приказати тестове пада и, наравно, писати о тестирању оптерећења и димензионисање. Такође ћемо посветити посебан чланак верзији вАИР-а за заједницу.
Да ли је Аеродиск прича о системима за складиштење података? Или зашто смо уопште почели да радимо хиперконвергенцију?
У почетку, идеја да створимо сопствену хиперконвергенцију дошла нам је негде око 2010. године. У то време на тржишту није постојао ни Аеродиск ни слична решења (комерцијални боксовани хиперконвергентни системи). Наш задатак је био следећи: од скупа сервера са локалним дисковима, уједињених интерконекцијом преко Етернет протокола, било је потребно направити проширено складиште и тамо покренути виртуелне машине и софтверску мрежу. Све ово је морало бити имплементирано без система за складиштење података (јер једноставно није било новца за системе за складиштење и њихов хардвер, а још нисмо измислили сопствене системе за складиштење података).
Испробали смо многа решења отвореног кода и коначно решили овај проблем, али решење је било веома сложено и тешко га је поновити. Осим тога, ово решење је било у категорији „Да ли ради? Не дирај! Стога, решивши тај проблем, нисмо даље развијали идеју да резултат нашег рада трансформишемо у пуноправни производ.
После тог инцидента смо се удаљили од ове идеје, али смо и даље имали осећај да је овај проблем у потпуности решив, а користи од таквог решења су биле више него очигледне. Касније су објављени ХЦИ производи страних компанија само потврдили овај осећај.
Стога смо се средином 2016. вратили овом задатку у склопу стварања пуноправног производа. У то време још нисмо имали никакве односе са инвеститорима, па смо морали да купимо развојни штанд за своје не баш велике паре. Сакупивши коришћене сервере и прекидаче на Авиту, прионули смо послу.
Главни почетни задатак је био да направимо сопствени, додуше једноставан, али сопствени систем датотека, који би могао аутоматски и равномерно да дистрибуира податке у виду виртуелних блокова на н-ти број чворова кластера, који су повезани интерконекцијом преко Етернета. Истовремено, ФС треба добро и лако да се скалира и да буде независан од суседних система, тј. бити отуђен од ВАИР-а у облику „само складишног објекта“.
Први вАИР концепт
Намерно смо одустали од употребе готових опен соурце решења за организовање стретцхед стораге-а (цепх, глустер, лустер и слично) у корист сопственог развоја, пошто смо већ имали доста пројектног искуства са њима. Наравно, ова решења су сама по себи одлична, а пре рада на Аеродиск-у, имплементирали смо више од једног пројекта интеграције са њима. Али једна је ствар имплементирати конкретан задатак за једног купца, обучити особље и, можда, купити подршку великог добављача, а сасвим друга ствар креирати производ који се лако реплицира и који ће се користити за различите задатке, што ми као продавац, можда чак и нећемо знати за себе. За другу сврху, постојећи производи отвореног кода нису нам одговарали, па смо одлучили да сами креирамо дистрибуирани систем датотека.
Две године касније, неколико програмера (који су комбиновали рад на вАИР-у са радом на класичном Енгине систему за складиштење) постигли су одређени резултат.
До 2018. смо написали једноставан систем датотека и допунили га потребним хардвером. Систем је комбиновао физичке (локалне) дискове са различитих сервера у један равни базен преко интерне интерконекције и „исекао“ их на виртуелне блокове, а затим су од виртуелних блокова креирани блок уређаји са различитим степеном толеранције на грешке, на којима су креирани виртуелни. и извршено коришћењем КВМ хипервизора аутомобила.
Нисмо се превише замарали именом система датотека и сажето смо га назвали АРДФС (погодите шта значи))
Овај прототип је изгледао добро (не визуелно, наравно, визуелног дизајна још није било) и показао је добре резултате у погледу перформанси и скалирања. Након првог правог резултата, покренули смо овај пројекат, организујући потпуно развојно окружење и посебан тим који се бавио само вАИР-ом.
Управо до тада је сазрела општа архитектура решења, која још није претрпела веће промене.
Заронити у систем датотека АРДФС
АРДФС је основа вАИР-а, који обезбеђује дистрибуирано складиштење података отпорно на грешке у целом кластеру. Једна од (али не и једина) карактеристична карактеристика АРДФС-а је да не користи никакве додатне наменске сервере за метаподатке и управљање. Ово је првобитно замишљено да поједностави конфигурацију решења и ради његове поузданости.
Структура складиштења
Унутар свих чворова кластера, АРДФС организује логички скуп из свог расположивог простора на диску. Важно је разумети да базен још увек није подаци или форматирани простор, већ једноставно означавање, тј. Сви чворови са инсталираним вАИР-ом, када се додају у кластер, аутоматски се додају у дељено АРДФС спремиште и дисковни ресурси се аутоматски деле у целом кластеру (и доступни за будуће складиштење података). Овај приступ вам омогућава да додајете и уклањате чворове у ходу без икаквог озбиљног утицаја на већ покренути систем. Оне. систем је веома лако скалирати „у цигле“, додајући или уклањајући чворове у кластеру ако је потребно.
Виртуелни дискови (објекти за складиштење виртуелних машина) се додају на врх АРДФС базена, који су направљени од виртуелних блокова величине 4 мегабајта. Виртуелни дискови директно складиште податке. Шема толеранције грешака је такође подешена на нивоу виртуелног диска.
Као што сте можда већ претпоставили, за толеранцију грешака подсистема диска, не користимо концепт РАИД (Редундантни низ независних дискова), већ користимо РАИН (Редундантни низ независних чворова). Оне. Толеранција грешака се мери, аутоматизује и управља на основу чворова, а не дискова. Дискови су, наравно, такође објекти за складиштење, они се, као и све остало, надгледају, са њима можете обављати све стандардне операције, укључујући и склапање локалног хардверског РАИД-а, али кластер ради посебно на чворовима.
У ситуацији у којој заиста желите РАИД (на пример, сценарио који подржава вишеструке кварове на малим кластерима), ништа вас не спречава да користите локалне РАИД контролере и изградите растегнуто складиште и РАИН архитектуру на врху. Овај сценарио је прилично активан и ми га подржавамо, па ћемо о њему говорити у чланку о типичним сценаријима за коришћење вАИР-а.
Шеме толеранције грешака у складиштењу
Могу постојати две шеме толеранције грешака за виртуелне дискове у вАИР-у:
1) Фактор репликације или једноставно репликација - овај метод толеранције грешака је једноставан као штап и конопац. Синхрона репликација се врши између чворова са фактором 2 (2 копије по кластеру) или 3 (3 копије, респективно). РФ-2 омогућава виртуелном диску да издржи квар једног чвора у кластеру, али „једе“ половину корисне запремине, а РФ-3 ће издржати квар 2 чвора у кластеру, али резервише 2/3 корисна запремина за своје потребе. Ова шема је веома слична РАИД-1, односно виртуелни диск конфигурисан у РФ-2 отпоран је на квар било ког чвора у кластеру. У овом случају, све ће бити у реду са подацима, па чак ни И/О неће стати. Када се пали чвор врати у функцију, аутоматски опоравак/синхронизација података ће почети.
Испод су примери дистрибуције РФ-2 и РФ-3 података у нормалном режиму иу ситуацији квара.
Имамо виртуелну машину капацитета 8МБ јединствених (корисних) података, која ради на 4 вАИР чвора. Јасно је да је у стварности мало вероватно да ће бити тако мали обим, али за шему која одражава логику рада АРДФС-а, овај пример је најразумљивији. АБ су виртуелни блокови од 4МБ који садрже јединствене податке виртуелне машине. РФ-2 креира две копије ових блокова А1+А2 и Б1+Б2, респективно. Ови блокови су „распоређени“ по чворовима, избегавајући пресек истих података на истом чвору, односно копија А1 неће бити лоцирана на истом чвору као копија А2. Исто са Б1 и Б2.
Ако један од чворова откаже (на пример, чвор бр. 3, који садржи копију Б1), ова копија се аутоматски активира на чвору где нема копије његове копије (тј. копије Б2).
Дакле, виртуелни диск (и ВМ, сходно томе) може лако преживети квар једног чвора у РФ-2 шеми.
Шема репликације, иако једноставна и поуздана, пати од истог проблема као и РАИД1 - нема довољно корисног простора.
2) Кодирање за брисање или кодирање за брисање (такође познато као „редундантно кодирање“, „кодирање за брисање“ или „код редундансе“) постоји да би се решио горњи проблем. ЕЦ је редундантна шема која обезбеђује високу доступност података са мањим оптерећењем простора на диску у поређењу са репликацијом. Принцип рада овог механизма је сличан РАИД 5, 6, 6П.
Приликом кодирања, ЕЦ процес дели виртуелни блок (подразумевано 4МБ) на неколико мањих „кометова података“ у зависности од ЕЦ шеме (на пример, 2+1 шема дели сваки блок од 4МБ на 2 дела од 2МБ). Затим, овај процес генерише „паритетне делове“ за „комедове података“ који нису већи од једног од претходно подељених делова. Приликом декодирања, ЕЦ генерише делове који недостају читајући „преживеле“ податке у целом кластеру.
На пример, виртуелни диск са 2 + 1 ЕЦ шемом, имплементиран на 4 чвора кластера, лако ће издржати квар једног чвора у кластеру на исти начин као РФ-2. У овом случају, режијски трошкови ће бити нижи, посебно, коефицијент корисног капацитета за РФ-2 је 2, а за ЕЦ 2+1 ће бити 1,5.
Да то једноставније опишемо, суштина је у томе што је виртуелни блок подељен на 2-8 (зашто од 2 до 8, види доле) „комада“, а за ове комаде се рачунају „комади“ паритета сличне запремине.
Као резултат, подаци и паритет су равномерно распоређени по свим чворовима кластера. Истовремено, као и код репликације, АРДФС аутоматски дистрибуира податке међу чворовима на начин да спречи да се идентични подаци (копије података и њихов паритет) чувају на истом чвору, како би се елиминисала могућност губитка података због на чињеницу да ће подаци и њихов паритет одједном завршити на једном складишном чвору који откаже.
Испод је пример, са истом виртуелном машином од 8 МБ и 4 чвора, али са ЕЦ 2+1 шемом.
Блокови А и Б подељени су на два дела од по 2 МБ (два јер 2+1), односно А1+А2 и Б1+Б2. За разлику од реплике, А1 није копија А2, то је виртуелни блок А, подељен на два дела, исто као и блок Б. Укупно добијамо два сета од 4МБ, од којих сваки садржи два дела од два МБ. Затим, за сваки од ових скупова, паритет се израчунава са запремином не више од једног комада (тј. 2 МБ), добијамо додатних + 2 комада паритета (АП и БП). Укупно имамо 4×2 података + 2×2 паритет.
Затим се делови „полажу“ међу чворовима тако да се подаци не секу са њиховим паритетом. Оне. А1 и А2 неће бити на истом чвору као АП.
У случају квара једног чвора (на пример, и трећег), пали блок Б1 ће се аутоматски вратити из БП паритета, који је ускладиштен на чвору бр. 2, и биће активиран на чвору где постоји нема Б-паритета, тј. комад БП. У овом примеру, ово је чвор бр. 1
Сигуран сам да читалац има питање:
„Све што сте описали је одавно имплементирано и од стране конкурената и у решењима отвореног кода, која је разлика између ваше имплементације ЕЦ у АРДФС?“
А онда ће бити занимљиве карактеристике АРДФС-а.
Брисање кодирања са фокусом на флексибилност
У почетку смо обезбедили прилично флексибилну ЕЦ Кс+И шему, где је Кс једнако броју од 2 до 8, а И је једнако броју од 1 до 8, али увек мање од или једнако Кс. Ова шема је обезбеђена за флексибилност. Повећање броја делова података (Кс) на које је виртуелни блок подељен омогућава смањење режијских трошкова, односно повећање корисног простора.
Повећање броја паритета (И) повећава поузданост виртуелног диска. Што је већа И вредност, више чворова у кластеру може да пропадне. Наравно, повећање обима паритета смањује количину корисног капацитета, али ово је цена коју треба платити за поузданост.
Зависност перформанси од ЕЦ кола је скоро директна: што је више „комада”, то су ниже перформансе; овде је, наравно, потребан уравнотежен поглед.
Овај приступ омогућава администраторима да конфигуришу растегнуто складиште уз максималну флексибилност. У оквиру АРДФС пула можете користити било које шеме толеранције грешака и њихове комбинације, што је, по нашем мишљењу, такође веома корисно.
Испод је табела која упоређује неколико (не свих могућих) РФ и ЕЦ шема.
Табела показује да чак и „фротир“ комбинација ЕЦ 8+7, која дозвољава губитак до 7 чворова у кластеру истовремено, „једе“ мање корисног простора (1,875 наспрам 2) од стандардне репликације и штити 7 пута боље , што овај заштитни механизам, иако сложенији, чини много атрактивнијим у ситуацијама када је потребно обезбедити максималну поузданост у условима ограниченог простора на диску. У исто време, морате да схватите да ће сваки „плус“ на Кс или И представљати додатни трошак перформанси, тако да у троуглу између поузданости, уштеде и перформанси морате да бирате веома пажљиво. Из тог разлога, посветићемо посебан чланак брисању величине кодирања.
Поузданост и аутономија система датотека
АРДФС ради локално на свим чворовима кластера и синхронизује их коришћењем сопствених средстава преко наменских Етхернет интерфејса. Важна ствар је да АРДФС независно синхронизује не само податке, већ и метаподатке који се односе на складиштење. Док смо радили на АРДФС-у, истовремено смо проучавали низ постојећих решења и открили да многа синхронизују мета фајл система користећи екстерни дистрибуирани ДБМС, који такође користимо за синхронизацију, али само конфигурације, а не ФС метаподатке (о овом и другим сродним подсистемима у следећем чланку).
Синхронизација ФС метаподатака коришћењем екстерног ДБМС-а је, наравно, радно решење, али би тада конзистентност података ускладиштених на АРДФС-у зависила од екстерног ДБМС-а и његовог понашања (и, искрено говорећи, то је хировита дама), који у наше мишљење је лоше. Зашто? Ако се ФС метаподаци оштете, сами ФС подаци се такође могу рећи „збогом“, па смо одлучили да кренемо на сложенији, али поузданији пут.
Сами смо направили подсистем за синхронизацију метаподатака за АРДФС и он живи потпуно независно од суседних подсистема. Оне. ниједан други подсистем не може оштетити АРДФС податке. По нашем мишљењу, ово је најпоузданији и најисправнији начин, али време ће показати да ли је то заиста тако. Поред тога, овај приступ има додатну предност. АРДФС се може користити независно од вАИР-а, баш као и растегнуто складиште, што ћемо сигурно користити у будућим производима.
Као резултат тога, развојем АРДФС-а, добили смо флексибилан и поуздан систем датотека који даје избор где можете уштедети на капацитету или одустати од свега на перформансама, или направити ултра-поуздано складиште по разумној цени, али смањујући захтеве за перформансама.
Заједно са једноставном политиком лиценцирања и флексибилним моделом испоруке (гледајући унапред, вАИР се лиценцира по чвору и испоручује се или као софтвер или као софтверски пакет), ово омогућава веома прецизно прилагођавање решења широком спектру захтева корисника и онда лако одржавати ову равнотежу.
Коме треба ово чудо?
С једне стране, можемо рећи да на тржишту већ постоје играчи који имају озбиљна решења у области хиперконвергенције, и ту заправо идемо. Чини се да је ова изјава тачна, АЛИ...
С друге стране, када изађемо на терен и комуницирамо са купцима, ми и наши партнери видимо да то уопште није случај. Много је задатака за хиперконвергенцију, на неким местима људи једноставно нису знали да постоје таква решења, на другима се чинило скупим, на трећим је било неуспешних тестирања алтернативних решења, а на некима уопште забрањују куповину због санкција. Уопште, испоставило се да је поље неорано, па смо отишли да подигнемо девичанско тло))).
Када је систем складиштења бољи од ГЦС-а?
Док радимо са тржиштем, често нас питају када је боље користити класичну шему са системима за складиштење података, а када хиперконвергентну? Многе компаније које производе ГЦС (посебно оне које немају системе за складиштење у свом портфељу) кажу: „Складишни системи постају застарели, само хиперконвергирани!“ Ово је смела изјава, али не одражава у потпуности стварност.
Истина, тржиште складиштења се заиста креће ка хиперконвергенцији и сличним решењима, али увек постоји „али“.
Прво, дата центри и ИТ инфраструктуре изграђене по класичној шеми са системима за складиштење података не могу се лако обновити, тако да је модернизација и завршетак таквих инфраструктура и даље наслеђе за 5-7 година.
Друго, инфраструктура која се тренутно гради највећим делом (мисли се на Руску Федерацију) се гради по класичној шеми коришћењем система за складиштење података, и то не зато што људи не знају за хиперконвергенцију, већ зато што је тржиште хиперконвергенције ново, решења и стандарди још нису успостављени, ИТ људи још нису обучени, имају мало искуства, али треба да граде центре података овде и сада. И овај тренд ће трајати још 3-5 година (и онда још једно наслеђе, види тачку 1).
Треће, постоји чисто техничко ограничење у додатним малим кашњењима од 2 милисекунде по писању (искључујући локални кеш, наравно), што је трошак дистрибуираног складиштења.
Па, не заборавимо на употребу великих физичких сервера који воле вертикално скалирање дисковног подсистема.
Постоји много неопходних и популарних задатака где се системи за складиштење понашају боље од ГЦС-а. Овде се, наравно, неће сложити са нама они произвођачи који немају системе за складиштење у свом производном портфељу, али ми смо спремни да разумно расправљамо. Наравно, ми, као програмери оба производа, свакако ћемо упоредити системе за складиштење и ГЦС у некој од наших будућих публикација, где ћемо јасно показати шта је боље под којим условима.
А где ће хиперконвергентна решења функционисати боље од система за складиштење података?
На основу горе наведених тачака, могу се извући три очигледна закључка:
- Тамо где су додатне 2 милисекунде кашњења за снимање, које се доследно јављају у било ком производу (сада не говоримо о синтетици, наносекунде се могу приказати на синтетици), нису критичне, погодна је хиперконвергентна.
- Тамо где се оптерећење са великих физичких сервера може претворити у много малих виртуелних и дистрибуирати међу чворовима, хиперконвергенција ће такође добро функционисати тамо.
- Тамо где је хоризонтално скалирање већи приоритет од вертикалног скалирања, ГЦС ће и тамо добро проћи.
Која су ово решења?
- Све стандардне инфраструктурне услуге (услуга именика, пошта, ЕДМС, фајл сервери, мали или средњи ЕРП и БИ системи, итд.). Ово називамо „општем рачунарству“.
- Инфраструктура цлоуд провајдера, где је потребно брзо и стандардизовано хоризонтално проширити и лако „исећи“ велики број виртуелних машина за клијенте.
- Инфраструктура виртуелне радне површине (ВДИ), где многе мале корисничке виртуелне машине раде и тихо „лебде“ унутар јединственог кластера.
- Мреже филијала, где је свакој грани потребна стандардна, отпорна на грешке, али јефтина инфраструктура од 15-20 виртуелних машина.
- Било које дистрибуирано рачунарство (услуге великих података, на пример). Где оптерећење не иде „у дубину“, већ „у ширину“.
- Тестна окружења у којима су додатна мала кашњења прихватљива, али постоје буџетска ограничења, јер су ово тестови.
Тренутно смо управо за ове задатке направили АЕРОДИСК вАИР и на њих се (до сада успешно) фокусирамо. Можда ће се то ускоро променити, јер... свет не мирује.
Тако…
Овим је завршен први део велике серије чланака; у следећем чланку ћемо говорити о архитектури решења и коришћеним компонентама.
Поздрављамо питања, сугестије и конструктивне спорове.
Извор: ввв.хабр.цом