Хеј Хабр!
Подсећамо да смо објавили још једну изузетно занимљиву и корисну о Кубернетес обрасцима. Све је почело са "“ Брендан Бернс, и, иначе, имамо посла у овом сегменту . Данас вас позивамо да прочитате чланак са МинИО блога који укратко описује трендове и специфичности образаца складиштења података у Кубернетес-у.
Кубернетес је фундаментално променио традиционалне обрасце развоја и примене апликација. Сада тим може да развије, тестира и примени апликацију за неколико дана — у више окружења, све у Кубернетес кластерима. Такав рад са претходним генерацијама технологије обично је трајао недељама, ако не и месецима.
Ово убрзање је омогућено апстракцијом коју обезбеђује Кубернетес – односно зато што сам Кубернетес комуницира са детаљима ниског нивоа физичких или виртуелних машина, омогућавајући корисницима да декларишу жељени процесор, жељену количину меморије и број контејнера. инстанце, између осталих параметара. Са огромном заједницом која подржава Кубернетес и његово усвајање се стално шири, Кубернетес је лидер међу свим платформама за оркестрацију контејнера са великом разликом.
Како употреба Кубернетеса расте, расте и конфузија око његових образаца складиштења..
Пошто се сви такмиче за део Кубернетес колача (тј. складиштење података), када је реч о складиштењу података, сигнал је утопљен у много буке.
Кубернетес представља модеран модел за развој, примену и управљање апликацијама. Овај савремени модел раздваја складиштење података од рачунања. Да бисте у потпуности разумели одвајање у контексту Кубернетеса, такође морате да разумете шта су апликације са стањем и без стања и како се складиште података уклапа у то. Овде РЕСТ АПИ приступ који користи С3 има јасне предности у односу на ПОСИКС/ЦСИ приступ других решења.
У овом чланку ћемо говорити о обрасцима складиштења података у Кубернетес-у и посебно се дотакнути дебате између апликација са статусом и без држављанства да бисмо боље разумели у чему је разлика између њих и зашто је то важно. Остатак текста ће се осврнути на апликације и њихове обрасце складиштења података у светлу најбољих пракси за рад са контејнерима и Кубернетес-ом.
Контејнери без држављанства
Контејнери су по природи лагани и ефемерни. Могу се лако зауставити, уклонити или распоредити на други чвор - све за неколико секунди. У великом систему оркестрације контејнера такве операције се дешавају стално, а корисници чак и не примећују такве промене. Међутим, потези су могући само ако контејнер нема никакве зависности од чвора на коме се налази. За такве контејнере се каже да раде без држављанства.
Статефул Цонтаинерс
Ако контејнер складишти податке на локално прикљученим уређајима (или на блок уређају), онда ће складиште података на којем се налази морати да се премести на нови чвор, заједно са самим контејнером, у случају квара. Ово је важно јер у супротном апликација која ради у контејнеру неће моћи исправно да функционише јер треба да приступи подацима ускладиштеним на локалном медију. За такве контејнере се каже да раде државотворан.
Са чисто техничке тачке гледишта, контејнери са стањем се такође могу премештати у друге чворове. Ово се обично постиже коришћењем дистрибуираних система датотека или блокова мрежног складиштења везаног за све чворове који покрећу контејнере. На овај начин контејнери приступају волуменима за трајно складиштење података, а информације се чувају на дисковима који се налазе широм мреже. Назваћу ову методу „приступ контејнеру са стањем“, а у наставку чланка ћу га тако назвати ради униформности.
У типичном приступу контејнера са стањем, сви модули апликације су прикључени на један дистрибуирани систем датотека—неку врсту дељене меморије у којој се налазе сви подаци апликације. Иако су неке варијације могуће, ово је приступ на високом нивоу.
Хајде сада да погледамо зашто је приступ контејнера са подацима о стању анти-образац у свету усредсређеном на облак.
Дизајн апликације заснован на Цлоуд-у
Традиционално, апликације су користиле базе података за структурирано складиштење информација и локалне дискове или дистрибуиране системе датотека где су сви неструктурирани или чак полуструктурирани подаци били бачени. Како је количина неструктурираних података расла, програмери су схватили да је ПОСИКС превише брбљив, да има значајне трошкове и на крају омета перформансе апликације када се пређе на заиста велике размере.
Ово је углавном допринело настанку новог стандарда за складиштење података, односно складиштења у облаку, који ради првенствено на основу РЕСТ АПИ-ја и ослобађа апликацију од оптерећујућег одржавања локалног складишта података. У овом случају, апликација ефективно прелази у режим без стања (пошто је стање у удаљеном складишту). Савремене апликације се праве од нуле имајући на уму овај фактор. По правилу, свака савремена апликација која обрађује податке ове или оне врсте (логове, метаподатке, блобове, итд.) изграђена је према парадигми оријентисаној на облак, где се стање преноси на софтверски систем посебно намењен за његово складиштење.
Приступ контејнера који садржи стање враћа целу ову парадигму тачно тамо где је почела!
Коришћењем ПОСИКС интерфејса за складиштење података, апликације функционишу као да имају статус и због тога одступају од најважнијих принципа дизајна усмереног на облак, односно од могућности да варирају величину нити радника апликације у зависности од долазног унос, учитавање, прелазак на нови чвор чим тренутни чвор откаже и тако даље.
Ако боље погледамо ову ситуацију, откривамо да се приликом избора складишта података изнова суочавамо са дилемом ПОСИКС наспрам РЕСТ АПИ-ја, АЛИ са додатним погоршањем ПОСИКС проблема због дистрибуиране природе Кубернетес окружења. Нарочито,
- ПОСИКС је брбљив: ПОСИКС семантика захтева да свака операција буде повезана са метаподацима и дескрипторима датотека који помажу у одржавању стања операције. То резултира значајним трошковима који немају стварну вредност. АПИ-ји за складиштење објеката, посебно С3 АПИ, ослобађају се ових захтева, дозвољавајући апликацији да се покрене, а затим „заборави“ на позив. Одговор система за складиштење показује да ли је акција била успешна или не. Ако не успе, апликација може да покуша поново.
- Мрежна ограничења: У дистрибуираном систему, подразумева се да може постојати много апликација које покушавају да запишу податке на исти прикачени медиј. Стога, не само да ће се апликације међусобно такмичити за пропусни опсег за пренос података (за слање података на медијум), већ ће се и сам систем за складиштење такмичити за овај пропусни опсег слањем података преко физичких дискова. Због говорљивости ПОСИКС-а, број мрежних позива се повећава неколико пута. С друге стране, С3 АПИ пружа јасну разлику између мрежних позива између оних који потичу од клијента ка серверу и оних који се јављају унутар сервера.
- безбедност: ПОСИКС безбедносни модел је дизајниран за активно људско учешће: администратори конфигуришу специфичне нивое приступа за сваког корисника или групу. Ову парадигму је тешко прилагодити свету који је усредсређен на облак. Савремене апликације зависе од безбедносних модела заснованих на АПИ-ју, где су права приступа дефинисана као скуп политика, налози за услуге, привремени акредитиви, итд.
- Управљивост: Контејнери са стањем имају одређене трошкове управљања. Говоримо о синхронизацији паралелног приступа подацима, обезбеђивању конзистентности података, све ово захтева пажљиво разматрање које обрасце приступа подацима користити. Додатни софтвер мора бити инсталиран, надгледан и конфигурисан, а да не спомињемо додатне напоре у развоју.
Интерфејс за складиштење података контејнера
Иако је интерфејс за складиштење контејнера (ЦСИ) био од велике помоћи у ширењу слоја запремине Кубернетес, делимично га предајући спољним добављачима складишта трећих страна, он је такође ненамерно допринео уверењу да је приступ контејнера са подацима о стању препоручени метод за чување података у Кубернетесу.
ЦСИ је развијен као стандард за обезбеђивање произвољних блокова и система за складиштење датотека за старе апликације када се извршавају на Кубернетес-у. И, као што је овај чланак показао, једина ситуација у којој приступ контејнера са стањем (и ЦСИ у његовом тренутном облику) има смисла је када је сама апликација застарели систем у који није могуће додати подршку за АПИ за складиштење објеката .
Важно је разумети да ћемо коришћењем ЦСИ у његовом тренутном облику, односно монтирањем волумена при раду са савременим апликацијама, наићи на приближно исте проблеме који су се појавили у системима где је складиштење података организовано у ПОСИКС стилу.
Бољи приступ
У овом случају, важно је разумети да већина апликација није сама по себи дизајнирана посебно за рад са стањем или без држављанства. Ово понашање зависи од укупне архитектуре система и направљених специфичних избора дизајна. Хајде да причамо мало о апликацијама са статусом.
У принципу, сви подаци апликације могу се поделити у неколико широких типова:
- Подаци дневника
- Подаци о временској ознаци
- Подаци о трансакцији
- Метаподаци
- Слике контејнера
- Блоб (бинарни велики објекат) подаци
Сви ови типови података су веома добро подржани на модерним платформама за складиштење, а постоји и неколико платформи које су изворне у облаку прилагођених за испоруку података у сваком од ових специфичних формата. На пример, подаци о трансакцијама и метаподаци могу да се налазе у модерној бази података која је изворна у облаку, као што је ЦоцкроацхДБ, ИугаБите, итд. Слике контејнера или блоб подаци могу да се чувају у доцкер регистру заснованом на МинИО. Подаци о временској ознаци могу се чувати у бази података временских серија као што је ИнфлукДБ, итд. Овде нећемо улазити у детаље о сваком типу података и његовим применама, али општа идеја је да се избегне трајно складиштење података које се ослања на монтирање локалног диска.
Поред тога, често је ефикасно обезбедити привремени слој за кеширање који служи као привремено складиште датотека за апликације, али апликације не би требало да зависе од овог слоја као извора истине.
Складиштење апликација са стањем
Иако је у већини случајева корисно држати апликације без стања, оне апликације које су дизајниране за складиштење података – као што су базе података, складишта објеката, складишта кључ/вредност – морају бити са стањем. Хајде да погледамо зашто су ове апликације распоређене на Кубернетес. Узмимо МиниИО као пример, али слични принципи важе за било који други велики систем за складиштење у облаку.
Цлоуд изворне апликације су дизајниране да у потпуности искористе флексибилност својствену контејнерима. То значи да не праве никакве претпоставке о окружењу у којем ће бити распоређени. На пример, МинИО користи механизам кодирања интерног брисања да обезбеди систему довољно отпорности да остане оперативан чак и ако половина дискова поквари. МинИО такође управља интегритетом и безбедношћу података користећи власнички хеширање и шифровање на страни сервера.
За такве апликације оријентисане на облак, локални трајни волумени (ПВ) су најпогоднији као складиште резервних копија. Локални ПВ пружа могућност складиштења необрађених података, док апликације које раде на овим ПВ независно прикупљају информације за скалирање података и управљање растућим захтевима за подацима.
Овај приступ је много једноставнији и знатно скалабилнији од ПВ базираних на ЦСИ, који уводе сопствене слојеве управљања подацима и редундантности у систем; поента је да се ови слојеви обично сукобљавају са апликацијама које су дизајниране да имају статус.
Снажан покрет ка раздвајању података од прорачуна
У овом чланку смо говорили о томе како се апликације преоријентишу да раде без чувања стања, или, другим речима, складиштење података је одвојено од рачунара на њему. У закључку, погледајмо неке стварне примере овог тренда.
, истакнута платформа за анализу података, традиционално је била са стањем и распоређена на ХДФС. Међутим, како Спарк прелази у свет усредсређен на облак, платформа се све више користи без држављанства користећи `с3а`. Спарк користи с3а за пренос стања на друге системе, док сами Спарк контејнери раде потпуно без држављанства. Други велики пословни играчи у области аналитике великих података, посебно, , , Прелазе и на посао са одвајањем складиштења података и прорачуна на њима.
Слични обрасци се такође могу видети на другим великим аналитичким платформама, укључујући Престо, Тенсорфлов то Р, Јупитер. Пребацивањем стања на удаљене системе за складиштење у облаку, постаје много лакше управљати и скалирати вашу апликацију. Поред тога, олакшава преносивост апликације у различитим окружењима.
Извор: ввв.хабр.цом