У Цитимобилу користимо МиСКЛ базу података као наше главно трајно складиште података. Имамо неколико кластера база података за различите услуге и сврхе.

Стална доступност мастера је критичан показатељ перформанси целог система и његових појединачних делова. Аутоматски опоравак кластера у случају квара главног система у великој мери смањује време одговора на инцидент и време застоја система. У овом чланку ћу погледати дизајн високе доступности (ХА) за МиСКЛ кластер заснован на МиСКЛ Орцхестратор и виртуелне ИП адресе (ВИП).

ХА решење засновано на ВИП

Прво ћу вам укратко рећи шта је наш систем за складиштење података.

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

Репликација се врши у полусинхроном режиму на основу GTID. То значи да најмање једна реплика мора да евидентира трансакцију пре него што се сматра успешном. Овај режим репликације обезбеђује оптималну равнотежу између перформанси и безбедности података у случају квара главног чвора. У основи, све промене се преносе са мастера на реплике помоћу Row Based Replication (RBR), али неки чворови могу имати mixed binlog format.

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

Један једноставан начин да вратите мастер ако не успе јесте да користите плутајуће ВИП адресе.

Шта треба да знате о овом решењу пре него што кренете даље:

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

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

Мрежна повезаност са мастером је нестала или је настао проблем на нивоу хардвера, а сервер је недоступан

Оркестратор ажурира топологију кластера, свака реплика извештава да је мастер недоступан. Оркестратор започиње процес одабира реплике погодне за улогу новог мајстора и почиње опоравак.
Покушавамо да скинемо ВИП са старог мајстора - безуспешно.
Реплика прелази у улогу мајстора. Топологија се поново гради.
Додавање новог мрежног интерфејса са ВИП-ом. Пошто није било могуће уклонити ВИП, почињемо периодично да шаљемо захтев у позадини бесплатни АРП. Ова врста захтева/одговора вам омогућава да ажурирате табелу мапирања ИП и МАЦ адреса на повезаним прекидачима, чиме вас обавештавамо да се наш ВИП померио. Ово минимизира вероватноћу split brain при повратку старог мајстора.
Све нове везе се одмах преусмеравају на нови мастер. Старе везе не успевају и поновљени позиви бази података се врше на нивоу апликације.

Сервер ради у нормалном режиму, дошло је до квара на нивоу ДБМС

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

Остали проблеми

Квар реплика или средњих мајстора не води на аутоматске радње и захтева ручну интервенцију.

Виртуелни мрежни интерфејс се увек додаје привремено, односно, након поновног покретања сервера, ВИП се не додељује аутоматски. Свака инстанца базе података подразумевано почиње у режиму само за читање, оркестратор аутоматски пребацује нови мастер за писање и покушава да инсталира read only на старог мајстора. Ове акције имају за циљ смањење вероватноће split brain.

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

Општи дијаграм решења ХА је представљен у наставку.

Избор новог мајстора

Оркестратор је довољно паметан и покушава да бира најпогоднија реплика као нови мајстор по следећим критеријумима:

реплика заостаје за мајстором;
МиСКЛ верзија мастера и реплике;
тип репликације (РБР, СБР или мешовити);
локација у истим или различитим центрима података;
доступност errant GTID — трансакције које су извршене на реплици, а нису на мастеру;
узимају се у обзир и прилагођена правила одабира.

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

Време одговора и опоравка

У случају инцидента, важно је минимизирати време застоја система, па хајде да размотримо МиСКЛ параметре који утичу на креирање и ажурирање топологије кластера од стране оркестратора:

slave_net_timeout — број секунди током којих реплика чека да нови подаци или сигнал откуцаја срца стигну од мастера пре него што се веза препозна као изгубљена и поново се повеже. Што је нижа вредност, то брже реплика може да утврди да је комуникација са мастером прекинута. Поставили смо ову вредност на 5 секунди.
MASTER_CONNECT_RETRY — број секунди између покушаја поновног повезивања. У случају проблема са мрежом, ниска вредност за овај параметар ће омогућити брзо поновно повезивање и спречити покретање процеса опоравка кластера. Препоручена вредност је 1 секунда.
MASTER_RETRY_COUNT — максималан број покушаја поновног повезивања.
MASTER_HEARTBEAT_PERIOD — интервал у секундама након којег мастер шаље сигнал откуцаја срца. Подразумевано је половина вредности slave_net_timeout.

Опције оркестратора:

DelayMasterPromotionIfSQLThreadNotUpToDate - ако је једнако true, тада главна улога неће бити примењена на реплику кандидата све док СКЛ нит реплике не заврши све непримењене трансакције из Релаи Лог-а. Користимо ову опцију да бисмо избегли губитак трансакција када све реплике кандидата заостану.
InstancePollSeconds — учесталост изградње и ажурирања топологије.
RecoveryPollSeconds — учесталост тополошке анализе. Ако се открије проблем, покреће се опоравак топологије. Ово константан, једнако 1 секунди.

Сваки чвор кластера оркестратор испитује једном InstancePollSeconds секунди Када се открије проблем, форсира се стање кластера ажуриран, а затим се доноси коначна одлука да се изврши опоравак. Експериментисањем са различитим параметрима базе података и оркестратора, успели смо да смањимо време одговора и опоравка на 30 секунди.

Тест постоље

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

Током вежби бирамо једну од метода емулације проблема: одмах упуцајте мајстора користећи kill -9, лагано прекинути процес и зауставити сервер (docker-compose stop), симулирају мрежне проблеме користећи iptables -j REJECT или iptables -j DROP. Очекујемо следеће резултате:

оркестратор ће открити проблеме са мастером и ажурирати топологију за не више од 10 секунди;
аутоматски ће се покренути поступак опоравка: конфигурација мреже ће се променити, улога мастера ће прећи на реплику, топологија ће бити поново изграђена;
нови мастер ће постати уписив, живе реплике неће бити изгубљене током процеса реконструкције;
подаци ће почети да се уписују на нови мастер и реплицирају;
Укупно време опоравка неће бити више од 30 секунди.

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

Налази

Здравље главног чвора система за складиштење је један од главних задатака СРЕ и оперативног тима. Имплементација оркестратора и ХА решења заснованог на ВИП-у нам је омогућила да постигнемо следеће резултате:

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

Међутим, решење има своја ограничења и недостатке:

скалирање ХА шеме на неколико центара података ће захтевати једну Л2 мрежу између њих;
Пре него што доделимо ВИП на новом мастеру, морамо га ослободити на старом. Процес је секвенцијалан, што повећава време опоравка;
отпуштање ВИП захтева ССХ приступ серверу, или било који други метод позивања удаљених процедура. Пошто сервер или база података имају проблеме који су изазвали процес опоравка, не можемо бити сигурни да ће се уклањање ВИП-а успешно завршити. А то може довести до појаве два сервера са истом виртуелном ИП адресом и проблема split brain.

Избећи split brain, можете користити метод СТОНИТХ („Пуцај други чвор у главу“), који потпуно изолује или онемогућава проблемски чвор. Постоје и други начини за имплементацију високе доступности кластера: комбинација ВИП-а и ДНС-а, услуга откривања и проки сервиса, синхроне репликације и других метода које имају своје недостатке и предности.

Говорио сам о нашем приступу креирању МиСКЛ кластера за превазилажење грешке. Лако се имплементира и пружа прихватљив ниво поузданости у тренутним условима. Како се цео систем уопште, а посебно инфраструктура развијају, овај приступ ће се несумњиво развијати.

Извор: ввв.хабр.цом

Оркестратор и ВИП као ХА решење за МиСКЛ кластер