Увод у рачунарство велике доступности: концепти и теорија

Усредсредимо се више на неке веће архитектонске принципе управљања кластерима него на било које појединачно технолошко решење.

Неке стварне примене ћемо видети касније у књизи - а о томе како ово функционише на Амазоновом АВС-у можете сазнати много у мојој књизи Научите Амазон Веб Сервицес ин Монтх оф Лунцхес из Маннинг-а. Али за сада, хајде да се прво побринемо да нам пријају основе.

Покретање серверских операција помоћу кластера било физичких или виртуелних рачунара је све у циљу побољшања поузданости и перформанси изнад онога што бисте могли очекивати од једног, моћног сервера. Поузданост додајете избегавањем да целокупну инфраструктуру окачите о једну тачку квара (тј. О једном серверу). А перформансе можете повећати способношћу да врло брзо додате рачунарску снагу и капацитет повећавањем и смањивањем.

То би се могло догодити интелигентним ширењем вашег радног оптерећења у различита географска окружења и окружења потражње (балансирање оптерећења)

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

Доћи ћемо до свега тога. Прво, ипак, ево неколико основних дефиниција:

Чвор : Једна машина (било физичка или виртуелна) која самостално покреће рад сервера на свом оперативном систему. Будући да било који појединачни чвор може отказати, испуњавање циљева доступности захтева да више чворова ради као део кластера.

Кластер : Два или више чворова сервера који раде у међусобној координацији да би извршавали појединачне задатке као део веће услуге, где узајамна свест омогућава једном или више чворова да надокнаде губитак другог.

Неуспех сервера : Немогућност серверског чвора да адекватно одговори на захтеве клијента. То је могло бити због потпуног пада, проблема са повезивањем или зато што је преплављена великом потражњом.

Отказивање : Начин на који кластер покушава да прилагоди потребе клијената осиротелих неуспехом појединачног серверског чвора покретањем или преусмеравањем других чворова како би попунио празнину у услузи.

Фаилбацк : Враћање одговорности на чвор сервера када се опорави од квара.

Репликација : Стварање копија критичних складишта података како би се омогућио поуздан синхрони приступ са више чворова сервера или клијената и како би се осигурало да ће преживети катастрофе. Репликација се такође користи да би се омогућило поуздано уравнотежење оптерећења.

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

Подељени мозак : Стање грешке у којем се мрежна комуникација између чворова или дељене меморије некако покварила и више појединачних чворова, који верују да је једини чвор још увек активан, наставља да приступа и ажурира заједнички извор података. Иако ово не утиче на дизајн заједничког ничега, може довести до грешака клијента и оштећења података унутар дељених кластера.

Ограђивање : Да би се спречило раздвајање мозга, демон стонитхд може бити конфигурисан да аутоматски искључи неисправни чвор или да наметне виртуелну ограду између њега и ресурса података остатка кластера. Све док постоји шанса да чвор и даље може бити активан, али се не усклађује правилно са остатком кластера, остаће иза ограде. Стонитх је кратица за „Пуцај у други чвор у глави“. Стварно.

Кворум : Можете да конфигуришете ограђивање (или принудно гашење) које ће се наметати чворовима који нису испали међусобно или са неким заједничким ресурсима. Кворум се често дефинише као више од половине свих чворова на укупном кластеру. Користећи тако дефинисане конфигурације, избегавате да имате два поткластера чворова, који верују да други не ради исправно, покушавајући да нокаутирају други.

Опоравак од катастрофе : Ваша инфраструктура се тешко може сматрати високо доступном ако немате аутоматизован систем за резервне копије, заједно са интегрисаним и тестираним планом опоравка од катастрофе. Ваш план ће морати да узме у обзир прерасподелу сваког од сервера у вашем кластеру.

Активни / пасивни кластер

Идеја иза прекида услуге је да би изненадни губитак било ког чвора у кластеру услуга брзо надокнадио други чвор који би заузео његово место. Да би ово функционисало, ИП адреса се аутоматски премешта у чвор приправности у случају отказа. Алтернативно, мрежни алати за усмеравање попут уравнотеживача оптерећења могу се користити за преусмеравање саобраћаја даље од неуспелих чворова. Прецизан начин преласка на фаиловер зависи од начина на који сте конфигурисали чворове.

Само један чвор ће у почетку бити конфигурисан да служи клијентима и наставиће то да ради сам док некако не закаже. Одговорност за постојеће и нове клијенте тада ће се пребацити (тј. „Фаиловер“) на пасивни - или резервни - чвор који се до сада пасивно држао у резерви. Примењујући модел на више сервера или компоненте серверске собе (попут извора напајања), н + 1 редундантност пружа таман довољно ресурса за тренутну потражњу и још једну јединицу за покривање квара.

Активни / активни кластер

Кластер који користи активни / активни дизајн имаће два или више идентично конфигурисаних чворова који независно опслужују клијенте.

Ако један чвор закаже, његови клијенти ће се аутоматски повезати са другим чвором и, колико ресурси дозвољавају, добити пуни приступ ресурсима.

Једном када се први чвор опорави или замени, клијенти ће се поново поделити између оба чвора сервера.

Примарна предност покретања активних / активних кластера лежи у способности ефикасног балансирања радног оптерећења између чворова и чак мрежа. Равнотежа оптерећења - која усмерава све захтеве од клијената ка доступним серверима - конфигурисана је за надгледање активности чворова и мреже и употребу неког унапред одређеног алгоритма за усмеравање промета до оних чворова који су у стању да то најбоље обраде. Смернице рутирања могу следити кружни образац, где се захтеви клијента једноставно мењају између расположивих чворова или унапред задате тежине где се неком чвору даје предност неким односом.

Имати пасивни чвор који делује као резервна замена за свог партнера у активној / пасивној конфигурацији кластера пружа значајну уграђену редунданцију. Ако ваша операција апсолутно захтева непрекидну услугу и неометане прелазе у случају отказа, онда би вам нека варијација активне / пасивне архитектуре требала бити циљ.

Кластери Схаред-Нотхинг вс. Схаред-Диск

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

Сада, замислите да имате неколико десетина чворова који се сви ослањају на један сервер базе података за своју функцију. Иако квар било ког броја чворова неће утицати на континуирано здравље тих чворова који остају, ако база података пропадне, читав кластер би постао бескористан. Чворови у кластеру дељеног ничега, међутим, (обично) ће одржавати сопствене базе података тако да - под претпоставком да су правилно синхронизовани и конфигурисани за трајну сигурност трансакција - ниједан спољни квар неће на њих утицати.

То ће имати значајнији утицај на кластер уравнотеженог оптерећења, јер сваки чвор уравнотежен оптерећења има сталну и критичну потребу за истовременим приступом подацима. Пасивни чвор на једноставном систему преусмеравања, међутим, могао би преживети неко време без приступа.

Иако би таква поставка могла успорити начин на који кластер одговара на неке захтеве - делимично зато што би због страхова од кварова подељених мозгова могло бити потребно периодично ограђивање кроз стонитх - компромис може бити оправдан за критично распоређивање на мисијама где је поузданост примарна брига.

Доступност

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

Очигледно је да ће се систем који направите за услугу која може проћи током викенда, а да то нико не примети, веома разликовати од веб локације за е-трговину чији купци очекују приступ 24 сата дневно. У најмању руку, требало би да циљате на просек доступности од најмање 99% - а неке операције захтевају знатно веће резултате у стварном свету. Време продужења од 99% би значило губитак краћи од укупно четири дана сваке године.

Постоји релативно једноставна формула помоћу које можете изградити корисну процену доступности (А). Идеја је поделити средње време пре отказа са средњим временом пре отказа плус средње време за поправак.

А = МТБФ / (МТБФ + МТТР)

Што се вредност А приближи 1, то ће ваш кластер бити доступнији. Да бисте добили реалну вредност за МТБФ, вероватно ћете морати да потрошите време излажући стварни систем озбиљној казни и пажљиво га проматрајући због софтверских, хардверских и мрежних кварова. Претпостављам да бисте могли да погледате и објављене метрике животног циклуса добављача хардвера или великих потрошача попут Бацкблазе-а да бисте стекли идеју колико дуго може да се очекује да интензивно коришћени хардвер траје.

МТТР ће бити производ времена које је потребно вашем кластеру да замени функционалност серверског чвора који није успео (поступак који је сличан, мада није идентичан опоравку од катастрофе - који се фокусира на брзу замену отказалог хардвера и повезаности). У идеалном случају, то би била вредност што је ближа нули секунди.

Проблем је у томе што у стварном свету обично има превише непознатих променљивих да би ова формула била заиста тачна, јер ће чворови који раде са различитим софтверским конфигурацијама и изграђени са хардвером различитих профила и старости имати широк спектар очекиваног животног века. Ипак, то може бити добар алат који ће вам помоћи да идентификујете дизајн кластера који је најбољи за ваш пројекат.

Помоћу тих информација можете лако да направите процену колики ће застој ваша услуга вероватно бити у току целе године.

С тим у вези, ако размештате своје ресурсе на независном добављачу платформе као што је ВМВаре или Амазон Веб Сервицес, уговор је о нивоу услуге добављача (СЛА). Амазонов ЕЦ2, на пример, гарантује да ће њихове рачунске инстанце и уређаји за складиштење података у блоковима испоручивати месечни проценат непрекидног рада од најмање 99,95% - што је мање од пет сати застоја годишње. АВС ће издавати кредите за месеце у којима су пропустили циљеве - иако недовољно довољно да надокнаде укупне пословне трошкове вашег застоја. Помоћу тих информација можете да уговорите ниво вишка услуге који одговара вашим јединственим потребама.

Наравно, као добављач услуга својим купцима, можда ћете морати да објавите сопствени СЛА на основу процена МТБФ и МТТР.

Руковање сесијама

За било који однос сервера и клијента, подаци генерисани ХТТП сесијама са статусом морају бити сачувани на начин који ће их учинити доступним за будуће интеракције. Кластер архитектуре могу унијети озбиљну сложеност у ове односе, јер се одређени сервер са којим клијент или корисник комуницира може мијењати између једног и другог корака.

Илустрације ради, замислите да сте пријављени на Амазон.цом, прегледавате њихове књиге о ЛПИЦ обуци и повремено додајете ставке у корпу (надамо се, још примерака ове књиге). Док сте спремни да унесете податке о плаћању и одјавите се, сервер који сте користили за прегледавање можда више неће ни постојати. Како ће ваш тренутни сервер знати које сте књиге одлучили да купите?

Не знам тачно како Амазон то решава, али проблем се често решава помоћу алата за репликацију података попут мемцацхед покретања на

спољни чвор (или чворови). Циљ је пружити сталан приступ поузданом и доследном извору података било којем чвору који би му могао затребати.

Овај чланак је преузет из књиге Научите себе Линук виртуелизација и велика доступност: припремите се за испит за сертификацију ЛПИЦ-3 304 “. Погледајте моје друге књиге о АВС и Линук администрацији , укључујући Линук у акцији и Линук у покрету  - хибридни курс који се састоји од више од два сата видео записа и око 40% текста Линука у акцији.