У Ситимобил мы выкарыстоўваем базу дадзеных MySQL у якасці асноўнага сховішчы пастаянных дадзеных. У нас ёсць некалькі кластараў баз дадзеных пад розныя сэрвісы і мэты.

Пастаянная даступнасць майстра з'яўляецца крытычным паказчыкам працаздольнасці ўсёй сістэмы і яе асобных частак. Аўтаматычнае аднаўленне кластара ў выпадку адмовы майстра моцна змяншае час рэагавання на інцыдэнт і час прастою сістэмы. У гэтым артыкуле я разгледжу схему забеспячэння высокай даступнасці (HA) кластара MySQL на аснове MySQL Orchestrator і віртуальных IP адрасоў (VIP).

HA-рашэнне на аснове VIP

Спачатку коратка раскажу аб тым, што з сябе ўяўляе наша сістэма захоўвання дадзеных.

Мы выкарыстоўваем класічную схему рэплікацыі з адным майстрам, даступным на запіс, і мноствам рэплік, якія выкарыстоўваюцца толькі на чытанне. Кластар можа змяшчаць прамежкавы майстар - вузел, які адначасова з'яўляецца і рэплікай, і майстрам для іншых. Кліенты звяртаюцца да рэплікаў праз HAProxy, што дазваляе раўнамерна размяркоўваць нагрузку і лёгка маштабавацца. Выкарыстанне HAProxy абумоўлена гістарычнымі прычынамі, і зараз мы ў працэсе міграцыі на ProxySQL.

Рэплікацыя выконваецца ў паўсінхронным рэжыме на аснове GTID. Гэта значыць, што як мінімум адна рэпліка павінна запісаць транзакцыю ў часопіс, перш чым тая будзе прызнана паспяховай. Такі рэжым рэплікацыі забяспечвае аптымальны баланс паміж прадукцыйнасцю і захаванасцю дадзеных у выпадку выхаду са строю галоўнага вузла. У асноўным усе змены перадаюцца ад майстра да рэплікаў з дапамогай Row Based Replication (RBR), але частка вузлоў можа мець mixed binlog format.

Аркестратар перыядычна абнаўляе стан тапалогіі кластара, аналізуе атрыманую інфармацыю і ў выпадку ўзнікнення праблем можа запусціць працэдуру аўтаматычнага аднаўлення. За саму працэдуру адказвае распрацоўшчык, паколькі яе можна рэалізаваць рознымі спосабамі: на аснове VIP, DNS, з выкарыстаннем службаў выяўлення сэрвісаў (service discovery) ці самапісных механізмаў.

Адным з простых спосабаў аднаўлення майстра ў выпадку яго адмовы з'яўляецца выкарыстанне плывучых VIP-адрасоў.

Што трэба ведаць аб гэтым рашэнні, перш чым рухацца далей:

VIP - гэта IP-адрас, які не прывязаны да канкрэтнага фізічнага сеткавага інтэрфейсу. Пры выхадзе вузла са строю або пры планавых работах мы можам пераключыць VIP на іншы рэсурс з мінімальным часам прастою.
Вызваленне і выдача віртуальнага IP-адрасы - танныя і хуткія аперацыі.
Для працы з VIP патрабуецца доступ да сервера па SSH, альбо выкарыстанне спецыяльных утыліт, напрыклад, keepalived.

Разгледзім магчымыя праблемы з нашым майстрам і ўявім, як павінен адпрацаваць механізм аўтаматычнага аднаўлення.

Прапала сеткавая складнасць да майстра, або ўзнікла праблема на ўзроўні «жалеза», і сервер недаступны

Аркестратар абнаўляе тапалогію кластара, кожная рэпліка паведамляе аб недаступнасці майстра. Аркестратар запускае працэс выбару рэплікі, прыдатнай на ролю новага майстра, і пачынае аднаўленне.
Спрабуем зняць VIP са старога майстра - беспаспяхова.
Рэпліка перамыкаецца на ролю майстра. Тапалогія перабудоўваецца.
Дадаем новы сеткавы інтэрфейс з VIP. Паколькі зняць VIP не ўдалося, у фонавым рэжыме запускаем перыядычную адпраўку запыту gratuitous ARP. Гэты від запыту/адказу дазваляе абнавіць на падлучаных камутатарах табліцу адпаведнасці IP- і MAC-адрасоў, тым самым апавяшчаючы аб пераездзе нашага VIP. Гэта мінімізуе верагоднасць split brain пры вяртанні старога майстра.
Усе новыя злучэнні адразу ж перанакіроўваюцца на новы майстар. Старыя злучэнні завяршаюцца няўдала, выконваюцца паўторныя звароты да БД на ўзроўні дадатку.

Сервер працуе ў нармальным рэжыме, адбылася адмова на ўзроўні СКБД.

Алгарытм аналагічны папярэдняй нагоды: абнаўленне тапалогіі і запуск працэсу аднаўлення. Паколькі сервер даступны, мы паспяхова вызваляем VIP на старым майстру, пераносім яго на новы і адпраўляем некалькі ARP-запытаў. Магчымы зварот старога майстра не павінен паўплываць на перабудаваны кластар і працу прыкладання.

іншыя праблемы

Адмова рэплік ці прамежкавых майстроў не прыводзіць да аўтаматычных дзеянняў і патрабуе ручнога ўмяшання.

Віртуальны сеткавы інтэрфейс заўсёды дадаецца часова, гэта значыць пасля перазагрузкі сервера VIP аўтаматычна не прызначаецца. Кожны асобнік БД па змаўчанні запускаецца ў рэжыме толькі для чытання, аркестратар аўтаматычна перамыкае новы майстар на запіс і спрабуе ўсталяваць read only на старым майстру. Гэтыя дзеянні накіраваны на памяншэнне верагоднасці split brain.

У працэсе аднаўлення могуць узнікнуць праблемы, аб якіх варта таксама апавяшчаць праз UI аркестратара акрамя стандартных сродкаў маніторынгу. Мы пашырылі REST API, дадаўшы такую магчымасць (PR зараз знаходзіцца на разглядзе).

Агульная схема HA-рашэнні прадстаўлена ніжэй.

Выбар новага майстра

Аркестратар дастаткова разумны і імкнецца абраць найбольш прыдатную рэпліку у якасці новага майстра па наступных крытэрыях:

адставанне рэплікі ад майстра;
версія MySQL майстры і рэплікі;
тып рэплікацыі (RBR, SBR ці mixed);
размяшчэнне ў адным ці розных дата-цэнтрах;
наяўнасць errant GTID - транзакцыі, якія былі выкананы на рэпліцы і адсутнічаюць на майстру;
таксама ўлічваюцца карыстацкія правілы выбару.

Не кожная рэпліка з'яўляецца ідэальным кандыдатам на ролю майстра. Напрыклад, рэпліка можа выкарыстоўвацца для рэзервовага капіявання дадзеных, альбо сервер мае слабейшую канфігурацыю «жалеза». Аркестратар падтрымлівае ручныя правілы, з дапамогай якіх можна наладзіць свае перавагі па выбары кандыдата ад найбольш пераважных да ігнаруемых.

Час рэагавання і аднаўленні

У выпадку інцыдэнту важна мінімізаваць час прастою сістэмы, таму разгледзім параметры MySQL, якія ўплываюць на пабудову і абнаўленне тапалогіі кластара аркестратарам:

slave_net_timeout - колькасць секунд, на працягу якіх рэпліка чакае паступленні новых дадзеных ці heartbeat-сігналу ад майстра, перш чым злучэнне прызнаецца страчаным і выконваецца перападлучэнне. Чым меншае значэнне, тым хутчэй рэпліка зможа вызначыць, што сувязь з майстрам парушана. Мы ўсталёўваем гэтае значэнне роўным 5 секундам.
MASTER_CONNECT_RETRY - Колькасць секунд паміж спробамі перападключэння. У выпадку сеткавых праблем нізкае значэнне гэтага параметра дазволіць хутка перападключыцца і прадухіліць запуск працэсу аднаўлення кластара. Рэкамендуемае значэнне - 1 секунда.
MASTER_RETRY_COUNT - Максімальную колькасць спроб перападлучэння.
MASTER_HEARTBEAT_PERIOD - Інтэрвал у секундах, пасля якога майстар адпраўляе heartbeat-сігнал. Па змаўчанні роўны палове значэння slave_net_timeout.

Параметры аркестратара:

DelayMasterPromotionIfSQLThreadNotUpToDate - калі роўны true, то роля майстра не будзе прыменена на рэпліцы-кандыдату да таго часу, пакуль SQL-струмень рэплікі не выканае ўсе непрымененыя транзакцыі з Relay Log. Мы выкарыстоўваем гэтую опцыю, каб не губляць транзакцыі ва ўмовах адставання ўсіх рэплік-кандыдатаў.
InstancePollSeconds - Частата пабудовы і абнаўлення тапалогіі.
RecoveryPollSeconds - Частата аналізу тапалогіі. У выпадку выяўлення праблемы запускаецца аднаўленне тапалогіі. Гэта канстанта, роўная 1 секундзе.

Кожны вузел кластара апытваецца аркестратарам адзін раз у InstancePollSeconds секунд. Пры выяўленні праблемы стан кластара прымусова абнаўляецца, А затым прымаецца канчатковае рашэнне аб выкананні аднаўлення. Эксперыментуючы з рознымі параметрамі БД і аркестратара, нам удалося знізіць працягласць рэагавання і аднаўлення да 30 секунд.

Выпрабавальны стэнд

Тэставанне HA-схемы мы пачалі з распрацоўкі лакальнага тэставага стэнда і далейшага ўкаранення ў тэставае і баявое асяроддзі. Лакальны стэнд цалкам аўтаматызаваны на аснове Docker і дазваляе эксперыментаваць з канфігурацыяй аркестратара і сеткі, маштабаваць кластар ад 2-3 сервераў да некалькіх дзясяткаў і праводзіць вучэнні ў бяспечным асяроддзі.

У час вучэнняў мы выбіраем адзін з метадаў эмуляцыі праблемы: імгненна адстрэліць майстар з дапамогай kill -9, мякка завяршыць працэс і спыніць сервер (docker-compose stop), імітаваць праблемы з сеткай з дапамогай iptables -j REJECT або iptables -j DROP. Мы чакаем такія вынікі:

аркестратар выявіць праблемы з майстрам і абновіць тапалогію не больш за за 10 секунд;
аўтаматычна запусціцца працэдура аднаўлення: зменіцца сеткавая канфігурацыя, роля майстра пяройдзе да рэплікі, тапалогія перабудуецца;
новы майстар стане даступны для запісу, жывыя рэплікі не будуць страчаныя ў працэсе перастраення;
дадзеныя пачнуць запісвацца ў новы майстар і рэпліцыравацца;
агульны час аднаўлення складзе не больш за 30 секунд.

Як вы ведаеце, сістэма можа паводзіць сябе па-рознаму ў тэставым і production-асяроддзі з-за рознай канфігурацыі «жалеза» і сеткі, адрозненняў у сінтэтычнай і рэальнай нагрузцы і г.д. Таму перыядычна мы праводзім вучэнні ў рэальных умовах, правяраючы, як паводзіць сябе сістэма пры страце сеткавай складнасці або дэградацыі яе асобных частак. У будучыні жадаем пабудаваць цалкам ідэнтычную інфраструктуру для абедзвюх асяроддзяў і аўтаматызаваць яе тэставанне.

Высновы

Працаздольнасць галоўнага вузла сістэмы захоўвання дадзеных з'яўляецца адной з асноўных задач каманды SRE і эксплуатацыі. Укараненне аркестратара і HA-рашэнні на аснове VIP дазволіла дабіцца наступных вынікаў:

надзейнае выяўленне праблем з тапалогіяй кластара БД;
аўтаматычнае і хуткае рэагаванне на інцыдэнты, звязаныя з майстрам, што змяншае час прастою сістэмы.

Аднак рашэнне мае свае абмежаванні і недахопы:

маштабаванне HA-схемы на некалькі ЦАД запатрабуе наяўнасці адзінай L2-сеткі паміж імі;
перш чым прызначыць VIP на новым майстру, нам трэба вызваліць яго на старым. Працэс з'яўляецца паслядоўным, што павялічвае час аднаўлення;
вызваленне VIP патрабуе SSH-доступу да сервера, альбо любога іншага спосабу выкліку выдаленых працэдур. Паколькі сервер або БД адчувае праблемы, якія выклікалі працэс аднаўлення, мы не можам быць упэўнены, што зняцце VIP завершыцца ўдала. А гэта можа прывесці да з'яўлення двух сервераў з аднолькавым віртуальным IP-адрасам і праблеме. split brain.

Каб пазбегнуць split brain, можна выкарыстоўваць метад STONITH ("Shoot The Other Node In The Head"), які цалкам ізалюе ці адключае праблемны вузел. Існуюць і іншыя спосабы рэалізацыі высокай даступнасці кластара: камбінацыя VIP і DNS, выяўленне службаў і проксі-сэрвісы, сінхронная рэплікацыя і іншыя спосабы, якія маюць свае недахопы і перавагі.

Я распавёў аб нашым падыходзе да стварэння абароненай ад збояў кластара MySQL. Ён просты ў рэалізацыі і забяспечвае прымальны ўзровень надзейнасці ў бягучых умовах. Па меры развіцця ўсёй сістэмы ў цэлым і інфраструктуры у прыватнасці гэты падыход, несумненна, будзе эвалюцыянаваць.

Крыніца: habr.com

Orchestrator і VIP як HA-рашэнне для кластара MySQL