Еј Хабр! Ви го презентирам преводот на статијата од Ендрју Бихоф.
Многу луѓе претпочитаат кластери со два јазли бидејќи изгледаат концептуално поедноставни и исто така се 33% поевтини од нивните колеги со три јазли. Иако е сосема можно да се состави добар кластер од два јазли, во повеќето случаи, поради неразгледани сценарија, таквата конфигурација ќе создаде многу неочигледни проблеми.
Првиот чекор за создавање на кој било систем со висока достапност е да се пронајдат и обидат да се елиминираат поединечните точки на неуспех, честопати скратено како SPoF (една точка на неуспех).
Вреди да се има предвид дека е невозможно да се елиминираат сите можни ризици од застој во кој било систем. Ова произлегува од фактот дека типична одбрана од ризик е да се воведе некој вишок, што доведува до зголемена сложеност на системот и појава на нови точки на неуспех. Затоа, првично правиме компромис и се фокусираме на настани поврзани со поединечни точки на неуспех, а не на синџири на поврзани и, според тоа, сè помалку веројатни настани.
Со оглед на компромисите, не само што бараме SPoF, туку и ги балансираме ризиците и последиците, како резултат на што заклучокот за тоа што е критично, а што не може да се разликува за секое распоредување.
Не секој има потреба од алтернативни снабдувачи со електрична енергија со независни далноводи. Иако паранојата му се исплатеше на барем еден клиент кога нивниот мониторинг откри неисправен трансформатор. Корисникот телефонски се јавувал обидувајќи се да ја извести електростопанството додека не експлодирал неисправниот трансформатор.
Природна почетна точка е да има повеќе од еден јазол во системот. Меѓутоа, пред системот да може да ги премести услугите на преживеаниот јазол по дефект, генерално треба да се осигура дека услугите што се преместуваат не се активни на друго место.
Нема негативна страна на кластерот со два јазли ако неуспехот резултира со тоа што двата јазли ја служат истата статична веб-локација. Меѓутоа, работите се менуваат ако резултатот е дека двете страни самостојно управуваат со споделена редица за работа или обезбедуваат некоординиран пристап за пишување до реплицирана база на податоци или споделен датотечен систем.
Затоа, за да се спречи оштетување на податоците како резултат на неуспех на еден јазол - се потпираме на нешто што се нарекува „дисоцијација“ (оградување).
Принципот на дисоцијација
Во срцето на принципот на дисоцијација е прашањето: дали конкурентниот јазол може да предизвика оштетување на податоците? Во случај оштетувањето на податоците да е веројатно сценарио, добро решение би било да се изолира јазолот и од дојдовните барања и од постојаното складирање. Најчестиот пристап кон дисосоцијацијата е да се оневозможат неисправните јазли.
Постојат две категории на методи на дисоцијација, кои ќе ги наречам директно и индиректно, но подеднакво можат да се наречат активни и пасивно. Директните методи вклучуваат дејства на преживеаните врсници, како што е интеракција со IPMI (интелигентен интерфејс за управување со платформа) или iLO (механизам за управување со сервери во отсуство на физички пристап до нив), додека индиректните методи се потпираат на неуспешниот јазол некако да препознае дека е во нездрава состојба (или барем да ги спречи другите членови да закрепнат) и да сигнализира за потребата да се исклучи неуспешниот јазол.
Кворумот помага кога се користат и директни и индиректни методи.
Директна дисоцијација
Во случај на директна дисоцијација, можеме да користиме кворум за да спречиме дисоцијациски трки во случај на дефект на мрежата.
Со концептот на кворум, има доволно информации во системот (дури и без поврзување со неговите врсници) за јазлите автоматски да знаат дали треба да иницираат дисоцијација и/или обновување.
Без кворум, двете страни на поделбата на мрежата со право ќе претпостават дека другата страна е мртва и ќе се обиде да ја разграничи другата. Во најлош случај, двете страни успеваат да го затворат целиот кластер. Алтернативно сценарио е смртен натпревар, бескрајна јамка од јазли што се мрестат, не ги гледаат своите врсници, ги рестартираат и иницираат обновување само за да се рестартираат кога нивниот врсник ја следи истата логика.
Проблемот со деасоцијацијата е што најчесто користените уреди стануваат недостапни поради истите неуспешни настани што сакаме да ги таргетираме за обновување. Повеќето IPMI и iLO картички се инсталирани на хостовите што ги контролираат и, стандардно, ја користат истата мрежа, што предизвикува целните домаќини да веруваат дека другите хостови се офлајн.
За жал, оперативните карактеристики на уредите IPMI и iLo ретко се разгледуваат при купувањето на опремата.
Индиректна дисоцијација
Кворумот е исто така важен за управување со индиректната дисосоцијација; ако се направи правилно, кворумот може да им овозможи на преживеаните да претпостават дека изгубените јазли ќе преминат во безбедна состојба по одреден временски период.
Со оваа конфигурација, тајмерот за надзор на хардверот се ресетира на секои N секунди доколку не се изгуби кворумот. Ако тајмерот (обично неколку множители на N) истече, тогаш уредот врши непријатно исклучување (не исклучување).
Овој пристап е многу ефикасен, но без кворум нема доволно информации во кластерот за управување со него. Не е лесно да се направи разлика помеѓу прекин на мрежата и неуспех на peer-јазол. Причината зошто ова е важно е тоа што без способност да разликувате два случаи, вие сте принудени да го изберете истото однесување и во двата случаи.
Проблемот со изборот на еден режим е тоа што не постои начин на дејствување што ја максимизира достапноста и спречува губење на податоци.
- Ако изберете да претпоставите дека врснички јазол е активен, но всушност не успее, кластерот непотребно ќе ги стопира услугите што би се извршувале за да се компензира за загубата на услуги од неуспешниот врснички јазол.
- Ако одлучите да претпоставите дека некој јазол е во прекин, но тоа е само дефект на мрежата и всушност далечинскиот јазол е функционален, тогаш во најдобар случај се регистрирате за некое идно рачно усогласување на добиените збирки податоци.
Без оглед на тоа каква хеуристика користите, тривијално е да се создаде неуспех што или ќе предизвика неуспех на двете страни или ќе предизвика кластерот да ги затвори преживеаните јазли. Некористењето кворум навистина го лишува кластерот од една од најмоќните алатки во неговиот арсенал.
Ако нема друга алтернатива, најдобриот пристап е да се жртвува достапноста (овде авторот се повикува на теоремата CAP). Високата достапност на оштетени податоци никому не му помага, а рачно усогласувањето на различни збирки податоци не е ниту забавно.
Кворум
Кворумот звучи одлично, нели?
Единствениот недостаток е тоа што за да го имате во кластер со N членови, треба да имате врска помеѓу N/2+1 од преостанатите јазли. Што не е можно во кластер со два јазли откако еден јазол ќе пропадне.
Што на крајот нè доведува до основниот проблем со два јазли:
Кворумот нема смисла во два кластери на јазли и без него е невозможно со сигурност да се одреди текот на дејството што ја максимизира достапноста и спречува губење на податоци
Дури и во систем од два јазли поврзани со вкрстен кабел, невозможно е дефинитивно да се направи разлика помеѓу прекин на мрежата и дефект на другиот јазол. Оневозможувањето на едниот крај (чија веројатност е, се разбира, пропорционална на растојанието помеѓу јазлите) ќе биде доволно за да се поништи секоја претпоставка дека здравјето на врската е еднакво на здравјето на партнерскиот јазол.
Изработка на кластер со два јазли да работи
Понекогаш клиентот не може или не сака да купи трет јазол, а ние сме принудени да бараме алтернатива.
Опција 1 - Метод на дупликат дисоцијација
Уредот iLO или IPMI на јазолот претставува точка на неуспех бидејќи, ако не успее, преживеаните не можат да го користат за да го доведат јазолот во безбедна состојба. Во кластер од 3 или повеќе јазли, можеме да го ублажиме ова со пресметување на кворум и користење на хардверски чувар (индиректен механизам за дисоцијација, како што беше дискутирано претходно). Во случај на два јазли, наместо тоа мора да користиме мрежни единици за дистрибуција на енергија (PDU).
По неуспех, преживеаниот прво се обидува да стапи во контакт со примарниот уред за деасоцијација (вграден iLO или IPMI). Ако ова е успешно, закрепнувањето продолжува како и обично. Само ако уредот iLO/IPMI не успее, се пристапува до PDU; ако пристапот е успешен, обновувањето може да продолжи.
Погрижете се да го поставите PDU на друга мрежа од сообраќајот на кластерот, инаку еден мрежен неуспех ќе го блокира пристапот до двата уреди за дисоцијација и ќе го блокира обновувањето на услугите.
Овде може да прашате - дали PDU е единствена точка на неуспех? На што е одговорот, секако дека е.
Ако овој ризик е значаен за вас, не сте сами: поврзете ги двата јазли на два PDU и кажете му на софтверот за кластерирање да ги користи и двете при вклучување и исклучување на јазлите. Кластерот сега останува активен ако еден PDU изумре и ќе биде потребен втор дефект или на другиот PDU или на уредот IPMI за да се блокира обновувањето.
Опција 2 - Додавање Арбитер
Во некои сценарија, иако методот на дупликат дисосоцијација е технички возможен, тој е политички тежок. Многу компании сакаат да имаат одредена поделба помеѓу администраторите и сопствениците на апликации, а мрежните администратори кои се свесни за безбедноста не се секогаш ентузијасти за споделување на поставките за пристап на PDU со никого.
Во овој случај, препорачаната алтернатива е да се создаде неутрална трета страна која може да ја надополни пресметката на кворумот.
Во случај на неуспех, јазолот мора да може да ги види брановите на неговиот врсник или арбитер за да ги врати услугите. Арбитерот вклучува и функција за исклучување ако двата јазли можат да го видат арбитерот, но не можат да се видат еден со друг.
Оваа опција мора да се користи заедно со методот на индиректна дисоцијација, како што е тајмерот за чувар на хардверот, кој е конфигуриран да ја убие машината ако ја изгуби врската со нејзиниот врсник и арбитар јазол. Така, преживеан може разумно да претпостави дека неговиот врснички јазол ќе биде во безбедна состојба откако ќе истече тајмерот за хардверски надзор.
Практичната разлика помеѓу арбитер и трет јазол е дека арбитер бара многу помалку ресурси за да работи и потенцијално може да опслужува повеќе од еден кластер.
Опција 3 - Човечки фактор
Конечниот пристап е преживеаните да продолжат да ги извршуваат услугите што веќе ги користеле, но да не започнуваат нови додека проблемот не се реши самиот (обновување на мрежата, рестартирање на јазолот) или лицето не ја преземе одговорноста рачно да потврди дека другата страна е мртва.
Бонус опција
Дали спомнав дека можете да додадете трет јазол?
Две лавици
За доброто на аргументот, да се преправаме дека ве убедив во основаноста на третиот јазол, сега мора да го разгледаме физичкиот распоред на јазлите. Ако тие се сместени (и се напојуваат) во иста решетка, ова исто така претставува SPoF, и она што не може да се реши со додавање на втор држач.
Ако ова е изненадувачки, размислете што би се случило ако решетката со два јазли не успее, и како преживеаниот јазол би направил разлика помеѓу тоа и дефект на мрежата.
Краткиот одговор е дека тоа не е можно, и повторно се справуваме со сите проблеми во случајот со два јазли. Или преживеан:
- го игнорира кворумот и неправилно се обидува да иницира реставрација за време на прекини на мрежата (способноста да се заврши дисоцијацијата е друга приказна и зависи од тоа дали PDU е вклучен и дали ја делат струјата со некој од решетките), или
- го почитува кворумот и се исклучува предвреме кога неговиот врснички јазол не успее
Во секој случај, два решетки не се подобри од еден, а јазлите мора или да добиваат независно напојување или да се дистрибуираат на три (или повеќе, во зависност од тоа колку јазли имате) решетки.
Два центри за податоци
Во овој момент, читателите кои повеќе не се склони кон ризик можеби ќе сакаат да размислат за обновување од катастрофи. Што се случува кога астероид ќе удри во истиот центар за податоци со нашите три јазли распространети низ три различни лавици? Очигледно лоши работи, но во зависност од вашите потреби, додавањето втор центар за податоци можеби не е доволно.
Ако се направи правилно, вториот центар за податоци ви обезбедува (и разумно) ажурирана и конзистентна копија од вашите услуги и нивните податоци. Сепак, како и во сценаријата со два јазли, со две решетки, нема доволно информации во системот за да се обезбеди максимална достапност и да се спречи корупција (или несовпаѓања во множеството податоци). Дури и со три јазли (или лавици), нивното дистрибуирање низ само два центри за податоци го остава системот неспособен со сигурност да ја донесе вистинската одлука во случај на (сега многу поверојатен) настан што двете страни не можат да го комуницираат.
Ова не значи дека решението за двоен центар за податоци никогаш не е соодветно. Компаниите често сакаат личноста да биде свесна пред да преземе извонреден чекор да се пресели во резервен центар за податоци. Само имајте на ум дека ако сакате да го автоматизирате прекинот, или ќе ви треба трет центар за податоци за кворумот да има смисла (или директно или преку арбитер), или ќе најдете начин сигурно да ги исклучите сите податоци центар.
Извор: www.habr.com