Увод

Пре извесног времена добио сам задатак да развијем кластер за прелазак на грешку ПостгреСКЛ, који раде у неколико центара података повезаних оптичким влакном у оквиру једног града и могу да издрже квар (на пример, замрачење) једног центра података. Као софтвер који је одговоран за толеранцију грешака, изабрао сам Пацемакерјер је ово званично решење компаније РедХат за креирање кластера за превазилажење грешке. Добро је јер РедХат пружа подршку за њега и зато што је ово решење универзално (модуларно). Уз његову помоћ биће могуће обезбедити толеранцију грешака не само ПостгреСКЛ-а, већ и других сервиса, било коришћењем стандардних модула или креирањем за специфичне потребе.

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

Сада је управа дозволила отворите пројекат заједници отвореног кода под МИТ лиценцом. РЕАДМЕ ће ускоро бити преведен на енглески (јер се очекује да ће главни потрошачи бити програмери Пејсмејкера и ПостгреСКЛ-а), а ја сам одлучио да представим стару руску верзију РЕАДМЕ-а (делимично) у облику овог чланка.

Кластери се постављају на виртуелне машине ВиртуалБок. Биће распоређено укупно 12 виртуелних машина (укупно 36ГиБ), које формирају 4 кластера отпорна на грешке (различите опције). Прва два кластера састоје се од два ПостгреСКЛ сервера, који се налазе у различитим центрима података, и заједничког сервера сведок c кворум уређај (хостован на јефтиној виртуелној машини у трећем центру података), што решава неизвесност 50% / 50%, дајући свој глас једној од странака. Трећи кластер у три дата центра: један мастер, два славе, бр кворум уређај. Четврти кластер се састоји од четири ПостгреСКЛ сервера, два по дата центру: један мастер, остали реплике, а такође користи сведок c кворум уређај. Четврти може да издржи квар два сервера или једног дата центра. Ово решење се може скалирати на већи број реплика ако је потребно.

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

Верзије

в0. Ради са ЦентОС 7 и ПостгреСКЛ 11 на ВиртуалБок-у 6.1.

Структура кластера

Сви кластери су дизајнирани да буду смештени у више центара података, комбиновани у једну равну мрежу и морају да издрже квар или мрежну изолацију једног центра података. Зато немогуће користити за заштиту од сплит-браин стандардна технологија пејсмејкера тзв СТОНИТХ (Пуцај у други чвор у главу) или мачевање. Његова суштина: ако чворови у кластеру почну да сумњају да нешто није у реду са неким чвором, не реагује или се понаша погрешно, онда га насилно искључују преко „спољних“ уређаја, на пример, ИПМИ или УПС контролне картице . Али ово ће функционисати само у случајевима када, у случају једног квара, ИПМИ или УПС сервер наставља да ради. Овде планирамо да се заштитимо од много катастрофалнијег квара, када цео дата центар поквари (на пример, изгуби напајање). А са таквим одбијањем све стонитх-уређаји (ИПМИ, УПС, итд.) такође неће радити.

Уместо тога, систем је заснован на идеји кворума. Сви чворови имају глас, а само они који могу да виде више од половине свих чворова могу да раде. Ова количина "пола + 1" се зове kvorum. Ако кворум није достигнут, онда чвор одлучује да је у мрежној изолацији и мора да искључи своје ресурсе, тј. ово је оно што је заштита подељеног мозга. Ако софтвер који је одговоран за ово понашање не ради, онда ће чувар, на пример, заснован на ИПМИ-ју, морати да ради.

Ако је број чворова паран (кластер у два дата центра), онда може настати тзв. 50% / 50% (Фифти Фифти) када изолација мреже дели кластер тачно на пола. Стога, за паран број чворова, додајемо кворум уређај је незахтеван демон који се може покренути на најјефтинијој виртуелној машини у трећем дата центру. Он даје свој глас једном од сегмената (који види) и тиме решава несигурност 50%/50%. Именовао сам сервер на коме ће бити покренут кворум уређај сведок (терминологија из репмгр-а, свидело ми се).

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

Тучанка1 (коло са сабијањем)

Структура

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

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

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

Неуспех сведочења

Пропуст да сведочи (кворум уређај) Разматраћу само за кластер Тучанка1, са свим осталима биће иста прича. Ако сведок не успе, ништа се неће променити у структури кластера, све ће наставити да функционише на исти начин. Али кворум ће постати 2 од 3, и стога ће сваки наредни неуспех бити фаталан за кластер. То ће ипак морати хитно да се поправи.

Туцханка1 одбијање

Квар једног од дата центара за Тучанку1. У овом случају сведок даје свој глас другом чвору у другом центру података. Тамо се бивши славе претвара у господара, као резултат тога, оба мастера раде на истом серверу и оба њихова флоат ИП-а указују на њих.

Тучанка2 (класична)

Структура

Класична шема два чвора. Господар ради на једном, роб на другом. Оба могу да изврше захтеве (славе је само за читање), тако да на оба указује ИП са флоат-ом: кроган2 је мастер, кроган2с1 је славе. И господар и роб ће имати толеранцију грешака.

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

Туцханка2 одбијање

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

Тучанка4 (много робова)

Структура

Већ друга крајност. Постоје базе података које примају много захтева само за читање (типичан случај сајта са великим оптерећењем). Тучанка4 је ситуација у којој могу бити три или више робова за обраду таквих захтева, али ипак не превише. Са веома великим бројем робова, биће неопходно измислити хијерархијски систем репликације. У минималном случају (на слици), сваки од два дата центра има два сервера, сваки са ПостгреСКЛ инстанцом.

Још једна карактеристика ове шеме је да је већ могуће организовати једну синхрону репликацију. Конфигурисан је да се реплицира, ако је могуће, у други центар података, а не у реплику у истом центру података као главни. На мастер и сваки славе указује ИП са флоат-ом. На срећу, између робова ће бити потребно некако избалансирати захтеве скл проки, на пример, на страни клијента. Различити типови клијената могу захтевати различите типове скл проки, а само програмери клијената знају коме шта треба. Ову функционалност може да имплементира или спољни демон или клијентска библиотека (повезивање) итд. Све ово превазилази тему кластера базе података за прелазак на грешку (фаиловер СКЛ проки може се имплементирати независно, заједно са толеранцијом грешака клијента).

Туцханка4 одбијање

Ако један центар података (тј. два сервера) поквари, сведок гласа за други. Као резултат тога, два сервера раде у другом центру података: један покреће мастер, а главни флоат ИП указује на њега (за пријем захтева за читање-уписивање); а на другом серверу постоји подређени сервер који ради са синхроном репликацијом, а један од подређених флоат ИП адреса указује на њега (за захтеве само за читање).

Прва ствар коју треба приметити је да неће сви подређени флоат ИП-ови бити радници, већ само један. А да бисте исправно радили с њим, то ће бити неопходно скл проки преусмерио све захтеве на једину преосталу флоат ИП; а ако скл проки не, онда можете навести све флоат ИП славе одвојене зарезима у УРЛ-у везе. У овом случају, са либпк веза ће бити на први радни ИП, то се ради у систему за аутоматско тестирање. Можда у другим библиотекама, на пример, ЈДБЦ, ово неће радити и неопходно је скл проки. Ово је урађено зато што је забрањено подизање флоат ИП-ова за славе-ове истовремено на једном серверу, тако да су равномерно распоређени међу славе серверима ако их ради неколико.

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

Тучанка3 (3 дата центра)

Структура

Ово је кластер за ситуацију у којој постоје три потпуно функционална центра података, од којих сваки има потпуно функционалан сервер базе података. У овом случају кворум уређај непотребно. У једном центру података ради главни, а у друга два подређени. Репликација је синхрона, тип АНИ (славе1, славе2), односно, клијент ће добити потврду урезивања када било који од славе-а први одговори да је прихватио урезивање. Ресурси су означени једном флоат ИП за мастер и два за славе. За разлику од Туцханка4, сва три флоат ИП-а су отпорна на грешке. Да бисте уравнотежили СКЛ упите само за читање, можете користити скл проки (са одвојеном толеранцијом грешака), или доделите један славе флоат ИП половини клијената, а другу половину другом.

Туцханка3 одбијање

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

Одлучио сам да не укључим детаљан опис структуре датотеке и примене. Свако ко жели да се поигра може све да прочита у РЕАДМЕ. Дајем само опис аутоматског тестирања.

Систем за аутоматско тестирање

За тестирање толеранције грешака кластера симулацијом различитих кварова, креиран је систем за аутоматско тестирање. Покренуто по скрипти test/failure. Скрипта може да узме као параметре бројеве кластера које желите да тестирате. На пример, ова команда:

test/failure 2 3

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

Терминал је подељен на колоне према броју тестираних кластера (на снимку екрана) постоје четири; Описаћу садржај колона на примеру Тучанке2. Панели на снимку екрана су нумерисани:

Овде се приказује статистика теста. Колоне:
- неуспех — назив теста (функције у скрипти) који емулира грешку.
- реакција — просечно аритметичко време у секундама током којег је кластер повратио своју функционалност. Мери се од почетка скрипте која емулира грешку до тренутка када кластер обнови своју функционалност и може да настави да пружа услуге. Ако је време веома кратко, на пример, шест секунди (ово се дешава у групама са неколико славе-а (Туцханка3 и Туцханка4)), то значи да је грешка била на асинхроном славе-у и није ни на који начин утицала на перформансе; прекидачи стања кластера.
- одступање — показује ширење (тачност) вредности реакција користећи методу стандардне девијације.
- рачунати — колико пута је овај тест изведен.
Кратак дневник вам омогућава да процените шта кластер тренутно ради. Приказује се број итерације (тест), временска ознака и назив операције. Предуго трчање (> 5 минута) указује на проблем.
срце (срце) - тренутно време. За визуелну процену перформанси мајстори Тренутно време се константно уписује у њену табелу користећи флоат ИП мастер. Ако успе, резултат се приказује на овом панелу.
победити (пулс) - „тренутно време“, које је претходно снимио сценарио срце овладати, сада читати из Роб преко његовог флоат ИП-а. Омогућава вам да визуелно процените перформансе славе и репликације. У Туцханка1 не постоје славе са флоат ИП (нема славе који пружају услуге), али постоје две инстанце (ДБ), тако да неће бити приказано овде победитиИ срце другостепени.
Праћење здравља кластера помоћу услужног програма pcs mon. Приказује структуру, дистрибуцију ресурса по чворовима и друге корисне информације.
Овде је приказано надгледање система са сваке виртуелне машине у кластеру. Таквих панела може бити више у зависности од тога колико виртуелних машина има кластер. Два графикона Оптерећење процесора (виртуелне машине имају два процесора), назив виртуелне машине, Оптерећење система (назван Просек оптерећења јер је у просеку за 5, 10 и 15 минута), процесни подаци и алокација меморије.
Траг скрипте која врши тестирање. У случају квара - изненадног прекида рада или бесконачног циклуса чекања - овде можете видети разлог оваквог понашања.

Тестирање се спроводи у две фазе. Прво, скрипта пролази кроз све врсте тестова, насумично бира виртуелну машину на коју ће применити овај тест. Затим се изводи бесконачан циклус тестирања, виртуелне машине и грешка се бирају насумично сваки пут. Изненадни прекид скрипте за тестирање (доњи панел) или бесконачна петља чекања нечега (> 5 минута времена извршења за једну операцију, то се види на трагу) указује да су неки од тестова на овом кластеру неуспели.

Сваки тест се састоји од следећих операција:

Покрените функцију која емулира грешку.
Спремни? — чека да се кластер обнови (када се обезбеде све услуге).
Приказује временско ограничење за опоравак кластера (реакција).
Поправити — кластер се „поправља“. Након тога би требало да се врати у потпуно оперативно стање и да буде спреман за следећи квар.

Ево листе тестова са описом шта раде:

ФоркБомб: Креира „Недостаје меморије“ помоћу виљушке бомбе.
Ван свемира: Чврсти диск је пун. Али тест је прилично симболичан са безначајним оптерећењем које се ствара током тестирања, ПостгреСКЛ обично не пада када је чврсти диск пун.
Постгрес-КИЛЛ: убија ПостгреСКЛ командом killall -KILL postgres.
Постгрес-СТОП: виси ПостгреСКЛ команду killall -STOP postgres.
Искључивање: „искључује“ виртуелну машину командом VBoxManage controlvm "виртуалка" poweroff.
Ресетовати: преоптерећује виртуелну машину командом VBoxManage controlvm "виртуалка" reset.
СБД-СТОП: суспендује СБД демона командом killall -STOP sbd.
Искључити: шаље команду виртуелној машини преко ССХ-а systemctl poweroff, систем се елегантно искључује.
УнЛинк: мрежна изолација, команда VBoxManage controlvm "виртуалка" setlinkstate1 off.

Завршавање тестирања помоћу стандардне тмук команде "килл-виндов" Цтрл-б &, или команду "детацх-цлиент". Цтрл-б д: у овом тренутку тестирање се завршава, тмук се затвара, виртуелне машине су искључене.

Проблеми идентификовани током тестирања

Тренутно чувар демон сбд ради на заустављању посматраних демона, али не и на њиховом замрзавању. И, као резултат, кварови који доводе само до смрзавања Цоросинц и Пацемакер, али не виси сбд. За проверу Цоросинц је већ ПР#83 (на ГитХуб-у на сбд), прихваћено на тему мајстор. Обећали су (у ПР#83) да ће бити нешто слично за Пејсмејкер, надам се да ће до РедХат 8 ће учинити. Али такви „кварови“ су спекулативни и могу се лако вештачки симулирати користећи, на пример, killall -STOP corosync, али се никада не сретну у стварном животу.
У Пацемакер у верзији за КСНУМКС Уник погрешно постављена синц_тимеоут у кворум уређај, као резултат ако је један чвор отказао, са извесном вероватноћом и други чвор се такође поново покреће, на који је мајстор требало да се пресели. Излечен проширењем синц_тимеоут у кворум уређај током имплементације (у скрипти setup/setup1). Програмери нису прихватили овај амандман Пацемакер, уместо тога су обећали да ће редизајнирати инфраструктуру на такав начин (у некој неодређеној будућности) да ће тај тајм-аут бити аутоматски израчунат.
Ако конфигурација базе података то наводи LC_MESSAGES (текстуалне поруке) Уницоде се може користити, нпр. ru_RU.UTF-8, затим при покретању постгрес у окружењу где локализација није УТФ-8, рецимо у празном окружењу (овде пејсмејкер+пгсклмс(паф) трчи постгрес), онда дневник ће садржати знаке питања уместо УТФ-8 слова. ПостгреСКЛ програмери се нису сложили шта да раде у овом случају. То кошта, морате инсталирати LC_MESSAGES=en_US.UTF-8 приликом конфигурисања (креирања) инстанце базе података.
Ако је вал_рецеивер_тимеоут подешен (подразумевано је 60 с), онда током ПостгреСКЛ-СТОП теста на мастеру у кластерима туцханка3 и туцханка4 репликација се не повезује поново са новим мастером. Репликација је тамо синхрона, тако да се не зауставља само славе, већ и нови мастер. Заобилази постављањем вал_рецеивер_тимеоут=0 приликом конфигурисања ПостгреСКЛ-а.
Повремено сам приметио замрзавање репликације у ПостгреСКЛ-у у тесту ФоркБомб (преливање меморије). Након ФоркБомб-а, понекад се славе можда неће поново повезати са новим мастером. Ово сам срео само у кластерима туцханка3 и туцханка4, где се мастер замрзнуо због синхроне репликације. Проблем је нестао сам после дужег времена (око два сата). Потребно је више истраживања да би се ово исправило. Симптоми су слични претходној грешци, која је узрокована другим разлогом, али са истим последицама.