Прывітанне, Хабр! Уяўляю вашай увазе пераклад артыкула аўтара Andrew Beekhof.
Шматлікія людзі аддаюць перавагу кластары якія складаюцца з двух вузлоў, таму што яны здаюцца канцэптуальна прасцейшымі, акрамя таго яшчэ і на 33% таннейшымі чым іх трох-вузлавыя субраты. Хоць цалкам рэальна сабраць добры кластар з двух вузлоў, у большасці выпадкаў, з-за няўлічаных сцэнараў, такая канфігурацыя створыць мноства невідавочных праблем.
Першым крокам да стварэння любой сістэмы высокай даступнасці з'яўляецца пошук і спроба ўхілення асобных кропак адмовы, часта скарочана званымі. SPoF (single point of failure).
Варта мець на ўвазе, што ў любой сістэме немагчыма ўхіліць усе магчымыя рызыкі прастою. Гэта выцякае хоць бы з таго факту, што тыповай абаронай ад рызыкі з'яўляецца ўвод некаторай надмернасці, што прыводзіць да павелічэння складанасці сістэмы і з'яўленню новых кропак адмовы. Таму мы першапачаткова ідзем на кампраміс і засяроджваемся на падзеях звязаных з асобнымі кропкамі адмовы, а не на ланцужках звязаных і, такім чынам, усё менш верагодных падзей.
Улічваючы кампрамісы, мы не толькі шукаем SPoF, але таксама падводзім баланс рызык і наступстваў, у выніку выснова што з'яўляецца крытычным, а што не можа адрознівацца для кожнага разгортвання.
Не ўсім патрэбны альтэрнатыўныя пастаўшчыкі электраэнергіі з незалежнымі лініямі электраперадачы. Хоць параноя акупілася прынамсі для аднаго кліента, калі іх маніторынг выявіў няспраўны трансфарматар. Замовец тэлефанаваў па тэлефоне, спрабуючы папярэдзіць энергетычную кампанію, датуль пакуль няспраўны трансфарматар не ўзарваўся.
Натуральнай адпраўной кропкай з'яўляецца наяўнасць у сістэме больш за адзін вузл. Аднак, перш чым сістэма зможа перамясціць сэрвісы на пакінуты ў жывых пасля збою вузел, у агульным выпадку, неабходна пераканацца, што якія перамяшчаюцца сэрвісы не актыўныя ў нейкім іншым месцы.
У двухвузлавога кластара няма недахопаў, калі ў выніку збою абодва вузла абслугоўваюць адзін і той жа статычны вэб-сайт. Аднак усё змяняецца, калі ў выніку абодва бакі незалежна кіруюць агульнай чаргой заданняў або падаюць нескаардынаваны доступ на запіс да рэплікаванай базы дадзеных або агульнай файлавай сістэме.
Таму, каб прадухіліць пашкоджанне дадзеных у выніку адмовы аднаго вузла - мы належым на тое, што называецца «адмежаванне» (fencing).
Прынцып адмежавання
У аснове прынцыпу адмежавання ляжыць пытанне: ці можа канкуруючы вузел выклікаць пашкоджанне дадзеных? У выпадку, калі пашкоджанне дадзеных з'яўляецца верагодным сцэнарам - добрым рашэннем будзе ізаляцыя вузла як ад уваходных запытаў, так і ад пастаяннага сховішча. Найбольш распаўсюджаны падыход да адмежавання - адключэнне няспраўных вузлоў.
Ёсць дзве катэгорыі метадаў адмежавання, якія я назаву прамымі и ўскоснымі, але ў роўнай ступені іх можна назваць актыўнымі и пасіўнымі. Прамыя метады ўключаюць у сябе дзеянні з боку тых, хто выжыў аднарангавых вузлоў, такія як узаемадзеянне з прыладай IPMI (Intelligent Platform Management Interface – інтэрфейс для выдаленага маніторынгу і кіравання фізічным станам сервера) або iLO (механізм кіравання серверамі ва ўмовах адсутнасці фізічнага доступу да іх), у той час як ускосныя метады належаць на які адмовіў вузел, каб нейкім чынам распазнаць, што ён знаходзіцца ў нездаровым стане (ці, прынамсі, мяшае астатнім чальцам аднаўляцца) і сігналізаваць аб неабходнасці адключэння вузла, які адмовіў.
Кворум дапамагае ў выпадку выкарыстання як прамых так і ўскосных метадаў.
Прамое адмежаванне
У выпадку прамога адмежавання мы можам выкарыстоўваць кворум для прадухілення гонак адмежавання ў выпадку збою сеткі.
Размяшчаючы канцэпцыяй кворуму, у сістэме дастаткова інфармацыі (нават без падлучэння да сваіх партнёраў), каб вузлы аўтаматычна ведалі, ці варта ім ініцыяваць адмежаванне і / або аднаўленне.
Без кворуму абодва бакі сеткавага падзелу справядліва мяркуюць, што іншы бок мёртвы, і будуць імкнуцца адмежаваць іншага. У горшым выпадку абодвум бакам атрымоўваецца адключыць увесь кластар. Альтэрнатыўны сцэнар - deathmatch, бясконцы цыкл вузлоў, якія з'яўляюцца, не бачаць сваіх баляў, перазагружаюць іх і ініцыююць аднаўленне толькі для перазагрузкі, калі іх банкет праходзіць па той жа логіцы.
Праблема з адмежаваннем складаецца ў тым, што найболей часта выкарыстоўваныя прылады становяцца недаступнымі з-за тых жа падзей адмовы, на якія мы жадаем арыентавацца для ўзнаўлення. Большасць карт IPMI і iLO устаноўлены на хастах, якія яны кантралююць, і, па змаўчанні, выкарыстоўваюць адну і тую ж сетку, з-за якой мэтавыя вузлы мяркуюць, што астатнія вузлы знаходзяцца ў афлайне.
Нажаль, асаблівасці працы прылад IPMI і iLo рэдка разглядаюцца ў момант пакупкі абсталявання.
Ускоснае адмежаванне
Кворум таксама важны для кіравання ўскосным адмежаваннямі, калі ўсё зроблена правільна, кворум можа дазволіць тым, хто выжыў, выказаць здагадку, што страчаныя вузлы праз пэўны перыяд часу пяройдуць у бяспечны стан.
Пры такой наладзе таймер hardware watchdog скідаецца кожныя N секунд, калі кворум не страчаны. Калі таймер (звычайна некалькі кратных N) заканчваецца, то прылада выконвае ungraceful адключэнне харчавання (не shutdown).
Дадзены падыход з'яўляецца вельмі эфектыўным, але без кворуму для яго кіравання недастаткова інфармацыі ўнутры кластара. Нялёгка вызначыць розніцу паміж адключэннем сеткі і адмовай вузла-партнёра. Чыннік, па якой гэта мае значэнне, складаецца ў тым, што без магчымасці адрозніваць два выпадкі вы змушаныя выбіраць аднолькавы рэжым паводзін у абодвух выпадках.
Праблема з выбарам аднаго рэжыму заключаецца ў тым, што не існуе спосабу дзеянняў, які б максімальна павялічваў даступнасць і прадухіляў страту даных.
- Калі вы вырашыце выказаць здагадку, што вузел-партнёр актыўны, але на самай справе адбыўся збой, кластар залішне спыніць службы, якія павінны былі б працаваць для кампенсацыі страты службаў вузла-партнёра, які ўпаў.
- Калі вы вырашыце выказаць здагадку, што вузел не працуе, але гэта быў проста збой сеткі і на самай справе выдалены вузел функцыянуе, то, у лепшым выпадку, вы падпісваецеся на некаторую будучую ручную зверку выніковых набораў дадзеных.
Незалежна ад таго, якую эўрыстыку вы карыстаецеся, трывіяльна стварыць збой, які альбо прымусіць абодва бакі працаваць, альбо прымусіць кластар адключыць якія выжылі вузлы. Невыкарыстанне кворуму сапраўды пазбаўляе кластар адной з самых магутных прылад у яго арсенале.
Калі няма іншай альтэрнатывы, лепшым падыходам будзе ахвяраваць даступнасцю (тут аўтар адсылае да CAP-тэарэмы). Высокая даступнасць пашкоджаных дадзеных нікому не дапамагае, і выверка ўручную розных набораў дадзеных таксама не дастаўляе задавальненні.
Кворум
Кворум гучыць выдатна, праўда?
Адзіны недахоп складаецца ў тым, што для таго, каб мець яго ў кластары з N чальцамі, вам трэба каб заставалася злучэнне паміж N / 2 + 1 вашых вузлоў. Што немагчыма ў кластары з двума вузламі пасля збою аднаго вузла.
Што ў канчатковым выніку падводзіць нас да фундаментальнай праблемы з двума вузламі:
кворум не мае сэнсу ў двух вузлавых кластарах, і без гэтага немагчыма надзейна вызначыць курс дзеянняў, які максімальна павялічвае даступнасць і прадухіляе страту дадзеных
Нават у сістэме з двух вузлоў, злучаных крос-кабелем, немагчыма канчаткова правесці адрозненне паміж адключэннем сеткі і адмовай іншага вузла. Адключэнні аднаго канца (верагоднасць якога, безумоўна, прапарцыйная адлегласці паміж вузламі) будзе дастаткова, каб абвергнуць любую здагадку аб тым, што працаздольнасць канала роўная здароўю вузла-партнёра.
Прымушаем працаваць кластар з двух вузлоў
Часам кліент не можа ці не жадае дакупляць трэці вузел, і мы змушаныя шукаць альтэрнатыву.
Варыянт 1 - Дублюючы метад адмежавання
Прылада iLO або IPMI вузла ўяўляе сабой кропку адмовы, паколькі, у выпадку збою, пакінутыя ў жывых не могуць выкарыстоўваць яго для пераводу вузла ў бяспечны стан. У кластары з 3 ці больш вузлоў мы можам змякчыць гэта вылічэннем кворуму і выкарыстаннем hardware watchdog (механізм ўскоснага адмежавання, як абмяркоўвалася раней). У выпадку з двума вузламі мы павінны замест гэтага выкарыстоўваць сеткавыя перамыкачы сілкавання (power distribution units ці PDUs).
Пасля збою які выжыў спачатку спрабуе звязацца з асноўнай прыладай адмежавання (убудаваным iLO або IPMI). Калі гэта ўдалося, аднаўленне працягваецца як звычайна. Толькі ў выпадку збою прылады iLO/IPMI адбываецца зварот да PDU, калі зварот паспяхова, аднаўленне можа працягвацца.
Абавязкова змесціце PDU у сетку, выдатную ад трафіку кластара, у адваротным выпадку адзіночны збой у сетцы заблакуе доступ як да прылад адмежавання, так і заблакуе ўзнаўленне службаў.
Тут Вы можаце спытаць - ці не з'яўляецца прылада PDU адзінай кропкай адмовы? На што адказ - вядома з'яўляецца.
Калі гэтая рызыка значны для вас - вы не самотныя: падлучыце абодва вузла да двух PDU і пакажыце кластарнага праграмнага забеспячэння выкарыстоўваць абодва пры ўключэнні і выключэнні вузлоў. Зараз кластар застаецца актыўным, калі адзін PDU памірае, і для блакавання аднаўлення запатрабуецца другі збой альбо іншага PDU, альбо прылады IPMI.
Варыянт 2 - Даданне арбітра
У некаторых сцэнарах, хаця тэхнічна магчымы метад дублюючага адмежавання, ён палітычна складзены. Многім кампаніям падабаецца мець пэўны падзел паміж адміністратарамі і ўладальнікамі прыкладанняў, і якія клапоцяцца аб бяспецы сеткавыя адміністратары не заўсёды з энтузіязмам ставяцца да перадачы каму б там ні было параметраў доступу да PDU.
У гэтым выпадку рэкамендаванай альтэрнатывай з'яўляецца стварэнне нейтральнага трэцяга боку, які можа дапоўніць разлік кворуму.
У выпадку збою вузел павінен мець магчымасць бачыць эфір свайго партнёра ці арбітра, каб аднавіць сэрвісы. Арбітр таксама ўключае ў сябе функцыю разрыву сувязі, калі абодва вузла могуць бачыць арбітра, але не бачаць адзін аднаго.
Гэтая опцыя павінна выкарыстоўвацца ў пары з ускосным метадам адмежавання, такім як hardware watchdog таймер, які настроены на гашэнне машыны, калі яна губляе злучэнне са сваім вузлом-партнёрам і арбітрам. Такім чынам, хто выжыў можа з дастатковай упэўненасцю выказаць здагадку, што яго вузел-партнёр будзе ў бяспечным стане пасля заканчэння тэрміна дзеяння hardware watchdog таймера.
Практычнае адрозненне паміж арбітрам і трэцім вузлом складаецца ў тым, што арбітр патрабуе значна менш рэсурсаў для сваёй працы і, патэнцыйна, можа абслугоўваць больш за аднаго кластара.
Варыянт 3 - Чалавечы фактар
Апошні падыход заключаецца ў тым, каб выжылыя працягвалі выконваць любыя службы, якія яны ўжо выконвалі, але не запускаць новыя, пакуль альбо праблема не вырашыцца сама (аднаўленне сеткі, перазагрузка вузла), альбо чалавек не возьме на сябе адказнасць за ручное пацверджанне таго, што іншы бок мёртвы.
Бонусная опцыя
Я ўжо казаў, што вы можаце дадаць трэці вузел?
Дзве стойкі
Дзеля аргументу, давайце ўявім, што я пераканаў вас у добрых якасцях трэцяга вузла, зараз мы павінны разгледзець фізічнае размяшчэнне вузлоў. Калі яны размешчаны (і атрымліваюць харчаванне) у той жа стойцы, гэта таксама ўяўляе сабой SPoF, і такую, якая не можа быць вырашана шляхам дадання другой стойкі.
Калі гэта дзіўна, падумайце, што адбудзецца, калі стойка з двума вузламі выйдзе са строю, і як выжыў вузел будзе адрозніваць гэты выпадак і збой сеткі.
Кароткі адказ: гэта немагчыма, і мы зноў маем справу з усімі праблемамі ў выпадку з двума вузламі. Альбо выжыўшы:
- ігнаруе кворум і няправільна спрабуе ініцыяваць аднаўленне падчас перабояў у працы сеткі (магчымасць завяршэння адмежавання - гэта асобная гісторыя і залежыць ад таго, ці задзейнічаны PDU і ці падзяляюць яны магутнасць з якой-небудзь з стоек), ці
- паважае кворум і заўчасна адключае сябе, калі яго вузел-партнёр церпіць няўдачу
У любым выпадку, дзве стойкі не лепш за адну, і вузлы павінны альбо атрымліваць незалежныя крыніцы харчавання, альбо размяркоўвацца па трох (ці больш, у залежнасці ад таго, колькі ў вас вузлоў) стойкам.
Два дата-цэнтры
Да гэтага моманту чытачы, якія больш не схільныя да рызыкі, могуць падумаць аб узнаўленні пасля аварыі. Што адбываецца, калі астэроід трапляе ў адзін цэнтр апрацоўкі дадзеных з нашымі трыма вузламі, размеркаванымі па трох розных стойках? Відавочна, што Bad Things, але ў залежнасці ад вашых патрэбаў, даданне другога дата-цэнтра можа быць недастаткова.
Калі ўсё зроблена правільна, другі дата-цэнтр дае вам (і гэта разумна) актуальную і ўзгодненую копію вашых сэрвісаў і іх дадзеных. Аднак, як і ў сцэнарах з двума вузламі і двума стойкамі, у сістэме недастаткова інфармацыі для забеспячэння максімальнай даступнасці і прадухілення пашкоджання (або разыходжанні набораў дадзеных). Нават пры наяўнасці трох вузлоў (або стоек) іх размеркаванне толькі па двух цэнтрах апрацоўкі дадзеных пакідае сістэму няздольнай надзейна прыняць правільнае рашэнне ў выпадку (зараз значна больш верагоднай) падзеі, якую абодва бакі не могуць звязаць.
Гэта не азначае, што рашэньне з двума дата-цэнтрамі ніколі не падыходзіць. Кампаніі нярэдка хочуць, каб чалавек быў у курсе, перш чым зрабіць выключны крок пры пераходзе на рэзервовы дата-цэнтр. Проста майце на ўвазе, што калі вы жадаеце аўтаматызаваць збой, вам спатрэбіцца альбо трэці дата-цэнтр, каб кворум меў сэнс (наўпрост ці праз арбітра), альбо вы знойдзеце спосаб надзейна адключыць увесь дата-цэнтр.
Крыніца: habr.com