Прывітанне, чытачы Хабра! У мінулым артыкуле мы распавялі аб простым сродку катастрофаўстойлівасці ў сістэмах захоўвання AERODISK ENGINE - аб рэплікацыі. У гэтым артыкуле мы пагрузімся ў больш складаную і цікавую тэму - метрокластэр, гэта значыць сродак аўтаматызаванай абароны ад катастроф для двух ЦАД-ов, якое дазваляе працаваць ЦАД-ам у рэжыме active-active. Раскажам, пакажам, зламаем і паправім.
Як звычайна, у пачатку тэорыя
Метракластар - гэта кластар, разнесены на некалькі пляцовак у межах горада ці раёна. Слова "кластар" нам відавочна намякае на тое, што комплекс аўтаматызаваны, гэта значыць пераключэнне вузлоў кластара ў выпадку збояў (failover) адбываецца аўтаматычна.
Менавіта тут крыецца асноўнае адрозненне метракластара ад звычайнай рэплікацыі. Аўтаматызацыя аперацый. Гэта значыць, у выпадку тых ці іншых здарэнняў (адмова ЦАД-а, абрыў каналаў і да т.п.) сістэма захоўвання самастойна выканае неабходныя дзеянні для таго, каб захаваць даступнасць дадзеных. Пры выкарыстанні ж звычайных рэплік гэтыя дзеянні выконваюцца поўнасцю або часткова ўручную адміністратарам.
Для чаго гэта трэба?
Асноўная мэта, якую пераследуюць заказчыкі, выкарыстоўваючы тыя ці іншыя рэалізацыі метракластара - мінімізаваць RTO (Recovery Time Objective). Гэта значыць мінімізаваць час аднаўлення ІТ-паслуг пасля збою. Калі выкарыстоўваць звычайную рэплікацыю, той час аднаўлення будзе заўсёды больш часу аднаўлення пры метрокластары. Чаму? Вельмі проста. Адміністратар павінен быць на працоўным месцы і пераключыць рэплікацыю рукамі, а метракластар гэта робіць аўтаматычна.
Калі ў вас няма выдзеленага дзяжурнага адміна, які не спіць, не есць, не паліць і не хварэе, а 24 гадзіны ў суткі глядзіць на стан СГД, то і няма магчымасці гарантаваць, што адміністратар будзе даступны для ручнога пераключэння падчас збою.
Адпаведна RTO у выпадку адсутнасці метракластара або несмяротнага адміна 99. ўзроўню дзяжурнай службы адміністратараў будзе роўным суме часу пераключэння ўсіх сістэм і максімальнаму прамежку часу, праз які адміністратар гарантавана пачне працаваць з СХД і сумежнымі сістэмамі.
Такім чынам прыходзім да відавочнай высновы, што метрокластар трэба выкарыстоўваць у выпадку, калі патрабаванне да RTO - хвіліны, а не гадзіны ці дні. Гэта значыць, калі ў выпадку самага страшнага падзення ЦАД-а ІТ-дэпартамент павінен забяспечыць бізнэсу час аднаўлення доступу да ІТ -паслугам на працягу хвілін, а то і секунд.
Як гэта працуе?
На ніжнім узроўні метрокластар выкарыстоўвае механізм сінхроннай рэплікацыі дадзеных, які мы апісалі ў папярэднім артыкуле (гл. ). Паколькі рэплікацыя сінхронная, то і патрабаванні да яе адпаведныя, а дакладней:
- оптавалакно ў якасці фізікі, 10 гігабітны Ethernet (або вышэй);
- адлегласць паміж ЦАД-амі не больш за 40 кіламетраў;
- затрымка канала оптыкі паміж ЦАД-амі (паміж СГД) да 5 мілісекунд (аптымальна 2).
Усе гэтыя патрабаванні носяць рэкамендацыйны характар, гэта значыць працаваць метрокластар будзе, нават калі гэтыя патрабаванні выкананы не будуць, але трэба разумець, што наступствы невыканання гэтых патрабаванняў роўныя запаволенню працы абедзвюх СГД у метрокластэры.
Такім чынам, для перадачы даных паміж СХД выкарыстоўваецца сінхронная рэпліка, а якім чынам рэплікі аўтаматычна перамыкаюцца і самае галоўнае, як пазбегнуць split-brain? Для гэтага на ўзроўні вышэй выкарыстоўваецца дадатковая сутнасць - арбітр.
Як працуе арбітр і ў чым яго задача?
Арбітр уяўляе з сябе невялікую віртуальную машыну, альбо апаратны кластар, які трэба запусціць на трэцяй пляцоўцы (напрыклад, у офісе) і забяспечыць доступ да СХД па ICMP і SSH. Пасля запуску арбітру варта ўсталяваць IP, а потым ужо са боку СХД паказаць яго адрас, плюс адрасы выдаленых кантролераў, якія ўдзельнічаюць у метрокластэры. Пасля гэтага арбітр готаў да працы.
Арбітр выконвае пастаянны маніторынг усіх СГД у метракластэры і ў выпадку недаступнасці той ці іншай сістэмы захоўвання ён, пасля пацверджання недаступнасці ад яшчэ аднаго ўдзельніка кластара (адной з «жывых» СГД), прымае рашэнне аб запуску працэдуры пераключэння правілаў рэплікацыі і аб мапінгу.
Вельмі важны момант. Арбітр заўсёды павінен знаходзіцца на пляцоўцы, выдатнай ад тых, на якіх знаходзяцца СГД, гэта значыць ні ў ЦАД-е 1, дзе стаіць СГД 1, ні ў ЦАД-е 2, дзе ўсталявана СГД 2.
Чаму? Таму што толькі так арбітр з дапамогай адной з тых, хто выжыў СГД можа адназначна і беспамылкова вызначыць падзенне любой з двух пляцовак, дзе ўсталяваныя СГД. Любыя іншыя спосабы размяшчэння арбітра, могуць прывесці да split-brain-у.
Цяпер пагрузімся ў дэталі працы арбітра.
На арбітры запушчаны некалькі службаў, якія пастаянна апытваюць усе кантролеры СГД. Калі вынік апытання адрозніваецца ад папярэдняга (даступны/недаступны), то ён запісваецца ў невялікую базу дадзеных, якая працуе таксама на арбітры.
Разгледзім логіку працы арбітра больш падрабязна.
Крок 1. Вызначэнне недаступнасці. Падзеяй-сігналам аб адмове СГД з'яўляецца адсутнасць пінгу з абодвух кантролераў адной СГД на працягу 5 секунд.
Крок 2. Запуск працэдуры пераключэння. Пасля таго, як арбітр зразумеў, што адна з СГД недаступная, ён адпраўляе запыт на "жывую" СГД з мэтай пераканацца, што "мёртвая" СГД, сапраўды, памерла.
Пасля атрымання такой каманды ад арбітра, другая (жывая) СГД дадаткова правярае даступнасць упалай першай СГД і, калі яе няма, адпраўляе арбітру пацвярджэнне яго здагадкі. СГД, сапраўды, недаступная.
Пасля атрымання такога пацверджання арбітр запускае выдаленую працэдуру пераключэння рэплікацыі і ўзняцці мапінга на тых рэпліках, якія былі актыўныя (primary) на якая ўпала СХД, і адпраўляе каманду на другую СХД зрабіць гэтыя рэплікі з secondary у primary і падняць мапінг. Ну а другая СГД, адпаведна, гэтыя працэдуры выконвае, пасля чаго забяспечвае доступ да страчаных LUN-ам з сябе.
Навошта патрэбная дадатковая праверка? Для кворуму. Гэта значыць большасць з агульнай няцотнай (3) колькасці ўдзельнікаў кластара павінны пацвердзіць падзенне аднаго з вузлоў кластара. Толькі тады гэтае рашэнне будзе сапраўды дакладным. Гэта трэба для таго, каб пазбегнуць памылковага пераключэння і, адпаведна, split-brain-а.
Крок 2 па часе займае прыкладна 5 - 10 секунд, такім чынам, з улікам часу, неабходнага на вызначэнне недаступнасці (5 секунд), на працягу 10 - 15 секунд пасля аварыі LUN-ы c ўпалай СГД будуць аўтаматычна даступныя для працы з жывой СХД.
Зразумелая справа, што для таго каб пазбегнуць парыву злучэння з хастамі, трэба таксама паклапаціцца аб карэктнай наладзе тайм-аўтаў на хастах. Рэкамендуемы тайм-аўт складае не менш за 30 секунд. Гэта не дасць магчымасці хасту разарваць злучэнне з СХД падчас пераключэння нагрузкі пры аварыі і зможа гарантаваць адсутнасць перапынення ўводу-вываду.
Секундачку, атрымліваецца, калі з метракластэрам так усё добра, навошта наогул патрэбна звычайная рэплікацыя?
Насамрэч усё не вось так проста.
Разгледзім плюсы і мінусы метракластара
Такім чынам, мы зразумелі, што відавочнымі плюсамі метракластара ў параўнанні са звычайнай рэплікацыяй з'яўляюцца:
- Поўная аўтаматызацыя, якая забяспечвае мінімальны час аднаўлення ў выпадку катастрофы;
- І ўсё :-).
А зараз, увага, мінусы:
- Кошт рашэння. Хоць метрокластар ў сістэмах Аэрадыск не патрабуе дадатковага ліцэнзавання (выкарыстоўваецца тая ж ліцэнзія, што і на рэпліку), кошт рашэння будзе ўсё роўна яшчэ вышэй, чым з выкарыстаннем сінхроннай рэплікацыі. Спатрэбіцца рэалізаваць усе патрабаванні для сінхроннай рэплікі, плюс патрабаванні для метракластара, звязаныя з дадатковай камутацыяй і дадатковай пляцоўкай (гл. планаванне метракластара);
- Складанасць рашэння. Метракластар уладкованы значна складаней, чым звычайная рэпліка, і патрабуе значна больш увагі і працавыдаткаў на планаванне, наладу і дакументаванне.
У выніку. Метракластар - гэта, безумоўна, вельмі тэхналагічнае і добрае рашэнне, калі вам рэальна трэба забяспечыць RTO у секунды ці хвіліны. Але калі такой задачы няма, і RTO у гадзіны - гэта для бізнесу ОК, то няма сэнсу страляць з гарматы па вераб'ях. Досыць звычайнай працоўна-сялянскай рэплікацыі, паколькі метрокластар выкліча дадатковыя выдаткі і ўскладненне ІТ-інфраструктуры.
Планаванне метракластара
Гэты падзел не прэтэндуе на ўсёабдымны дапаможнік па праектаванні метракластара, а толькі паказвае асноўныя кірункі, якія варта прапрацаваць, калі вы вырашылі пабудаваць падобную сістэму. Таму пры рэальным укараненні метракластара абавязкова прыцягвайце для кансультацый вытворцы СГД (гэта значыць нас) і іншых сумежных сістэм.
Пляцоўкі
Як паказана вышэй, для метракластара неабходна мінімум тры пляцоўкі. Два ЦАД-ы, дзе будуць працаваць СГД і сумежныя сістэмы, а таксама трэцяя пляцоўка, дзе будзе працаваць арбітр.
Рэкамендаванай адлегласць паміж ЦАД-амі - не больш за 40 кіламетраў. Большую адлегласць з высокай верагоднасцю выкліча дадатковыя затрымкі, якія ў выпадку метракластара вельмі непажаданыя. Нагадаем, затрымкі павінны быць да 5 мілісекунд, хаця пажадана ўкласціся ў 2.
Затрымкі рэкамендуецца правяраць таксама падчас планаванняў. Любы больш-менш дарослы правайдэр, які прадстаўляе оптавалакно паміж ЦАД-амі, якасную праверку можа арганізаваць даволі хутка.
Што да затрымак да арбітра (гэта значыць паміж трэцяй пляцоўкай і двума першымі), то рэкамендуемы парог затрымак да 200 мілісекунд, гэта значыць падыдзе звычайнае карпаратыўнае VPN-злучэнне па-над сеткай Інтэрнэт.
Камутацыя і сетка
У адрозненні ад схемы з рэплікацыяй, дзе дастаткова злучыць паміж сабой СХД з розных пляцовак, схема з метрокластэрам патрабуе злучэння хастоў з абедзвюма СХД на розных пляцоўках. Каб было больш зразумела, у чым адрозненне, абедзве схемы пазначаны ніжэй.
Як відаць са схемы, у нас хасты пляцоўкі 1 глядзяць і на СХД1, і на СХД 2. Таксама наадварот, хасты пляцоўкі 2 глядзяць і на СХД 2 і на СХД1. Гэта значыць кожны хост бачыць абедзве СГД. Гэта абавязковая ўмова працы метракластара.
Само сабой, няма патрэбы кожны хост цягнуць аптычным шнурком у іншы ЦАД, ніякіх партоў і шнуркоў не хопіць. Усе гэтыя злучэнні павінны выконваюцца праз камутатары Ethernet 10G+ ці FibreChannel 8G+ (FC толькі для злучэння хастоў і СХД для IO, канал рэплікацыі пакуль даступны толькі па IP (Ethernet 10G+).
Цяпер пару слоў аб тапалогіі сеткі. Важным момантам з'яўляецца правільная канфігурацыя падсетак. Неабходна адразу вызначыць некалькі падсетак для наступных тыпаў трафіку:
- Падсетку для рэплікацыі, па якой будуць сінхранізавацца дадзеныя паміж СГД. Іх можа быць некалькі, у дадзеным выпадку не мае значэння, усё залежыць ад бягучай (ужо рэалізаванай) тапалогіі сеткі. Калі іх дзве, то, відавочна, павінна быць наладжана маршрутызацыя паміж імі;
- Падсеткі захоўвання дадзеных, праз якія хасты будуць атрымліваць доступ да рэсурсаў СХД (калі гэта iSCSI). Такіх падсетак павінна быць па адной у кожным ЦАД-е;
- Кіравальныя падсеткі, гэта значыць тры маршрутызуемыя падсеткі на трох пляцоўках, з якіх ажыццяўляецца кіраванне СГД, а таксама тамака размешчаны арбітр.
Падсеткі для доступу да рэсурсаў хастоў мы тут не разглядаем, паколькі яны моцна залежаць ад задач.
Падзел рознага трафіку па розных падсетках вельмі важна (асабліва важна аддзяліць рэпліку ад уводу-высновы), паколькі калі змяшаць увесь трафік у адну «тоўстую» падсетку, то гэтым трафікам будзе немагчыма кіраваць, а ва ўмовах двух ЦАД-ов гэта яшчэ можа выклікаць розныя варыянты сеткавых калізій. У гэтае пытанне мы ў рамках гэтага артыкула моцна апускацца не будзем, паколькі аб планаванні расцягнутай паміж ЦАД-амі сеткі можна пачытаць на рэсурсах вытворцаў сеткавага абсталявання, дзе гэта вельмі падрабязна апісана.
Канфігурацыя арбітра
Арбітру неабходна забяспечыць доступ да ўсіх кіраўнікоў інтэрфейсаў СХД па пратаколах ICMP і SSH. Таксама варта падумаць аб адмоваўстойлівасці арбітра. Тут ёсць нюанс.
Адмаўстойлівасць арбітра вельмі пажаданая, але неабавязковая. А што адбудзецца, калі не ў час грымнецца арбітр?
- Праца метракластара ў штатным рэжыме не зменіцца, т.я. арбітр на працу метракластара ў штатным рэжыме не ўплывае абсалютна ніяк (яго задача - своечасова пераключыць нагрузку паміж ЦАД-амі)
- Пры гэтым калі арбітр па тым ці іншым чынніку зваліцца і «праспіць» аварыю ў ЦОД-е, то ніякага пераключэння не адбудзецца, таму што няма каму будзе аддаць патрэбныя каманды на пераключэнне і арганізаваць кворум. У гэтым выпадку метрокластэр ператворыцца ў звычайную схему з рэплікацыяй, якую давядзецца падчас катастрофы перамыкаць рукамі, што паўплывае на RTO.
Што з гэтага вынікае? Калі рэальна трэба забяспечыць мінімальны паказчык RTO, патрабуецца забяспечыць адмоваўстойлівасць арбітра. Для гэтага ёсць два варыянты:
- Запусціць віртуалку з арбітрам на адмоваўстойлівым гіпервізоры, балазе ўсе дарослыя гіпервізары падтрымліваюць адмоваўстойлівасць;
- Калі на трэцяй пляцоўцы (ва ўмоўным офісе) лянота ставіць нармальны кластар няма існуючага кластара гіперівазар, то мы прадугледзелі апаратны варыянт арбітра, які выкананы ў скрынцы 2U, у якой працуюць два звычайных x-86 сервера і які можа перажыць лакальную адмову.
Мы настойліва рэкамендуем забяспечыць адмоваўстойлівасць арбітра нягледзячы на тое, што ў штатным рэжыме ён метракластару не патрэбен. Але як паказвае і тэорыя, і практыка, калі будаваць сапраўды надзейную катастрофаўстойлівую інфраструктуру, то лепш перастрахавацца. Лепш абараніць сябе і бізнэс ад «закону подласці», гэта значыць ад выхаду са строю адначасова і арбітра, і адной з пляцовак, дзе стаіць СГД.
Архітэктура рашэння
Улічваючы патрабаванні вышэй, мы атрымліваем наступную агульную архітэктуру рашэння.
LUN-ы варта раўнамерна размяркоўваць па двух пляцоўкам, каб пазбягаць моцнай перагрузкі. Пры гэтым пры сайзінгу ў абодвух ЦАД-ах варта закладваць не толькі падвойны аб'ём (які неабходны для захоўвання дадзеных адначасова на двух СХД), але і падвойную прадукцыйнасць у IOPS і MB/s, каб не дапускаць дэградацыі прыкладанняў ва ўмовах адмовы аднаго з ЦАД- ов.
Асобна адзначым, што пры належным падыходзе да сайзінгу (гэта значыць, пры ўмове, што мы прадугледзелі належныя верхнія межы IOPS і MB/s, а таксама неабходныя рэсурсы CPU і RAM) пры адмове адной з СХД у метрокластары не будзе сур'ёзнай прасадкі прадукцыйнасці ва ўмовах часовай працы на адной СГД.
Гэта тлумачыцца тым, што ва ўмовах працы адначасова двух пляцовак, якая працуе сінхронная рэплікацыя "з'ядае" палову прадукцыйнасці пры запісе, паколькі кожную транзакцыю трэба запісваць на дзве СХД (аналагічна RAID-1/10). Так, пры адмове адной з СГД, уплыў рэплікацыі часова (пакуль не паднімецца адмовілася СГД) знікае, і мы атрымліваем двухразовы прырост прадукцыйнасці на запіс. Пасля таго, як LUN-ы якая адмовіла СГД перазапусціліся на якая працуе СГД, гэты двухразовы прырост знікае за кошт таго, што з'яўляецца нагрузка з LUN-ов іншы СГД, і мы вяртаемся да таго ж узроўню прадукцыйнасці, які ў нас быў да «падзення», але толькі ў межах ужо адной пляцоўкі.
З дапамогай пісьменнага сайзінгу можна забяспечыць умовы, пры якіх адмова цэлай СХД карыстачы не адчуюць зусім. Але яшчэ раз паўторымся, гэта патрабуе вельмі ўважлівага сайзінгу, за якім, дарэчы, можна бясплатна да нас звярнуцца:-).
Настройка метракластара
Настройка метракластара вельмі падобная на настройку звычайнай рэплікацыі, якую мы апісалі ў . Таму засяродзімся толькі на адрозненнях. Мы наладзілі ў лабараторыі стэнд, заснаваны на архітэктуры вышэй, толькі ў мінімальным варыянце: дзве СХД, злучаныя па 10G Ethernet паміж сабой, два камутатара 10G і адзін хост, які глядзіць праз камутатары на абедзве СХД партамі 10G. Арбітр працуе на віртуальнай машыне.
Пры наладзе віртуальных IP (VIP) для рэплікі варта абраць тып VIP - для метракластара.
Стварылі дзве рэплікацыйныя сувязі для двух LUN-ов і размеркавалі іх па двух СХД: LUN TEST Primary на СХД1 (сувязь METRO), LUN TEST2 Primary для СХД2 (сувязь METRO2).
Для іх мы наладзілі два аднолькавых таргета (у нашым выпадку iSCSI, але падтрымліваецца і FC, логіка налады тая ж).
СГД1:
СГД2:
Для рэплікацыйных сувязей зрабілі мапінгі на кожнай СГД.
СГД1:
СГД2:
Настроілі multipath і прэзентавалі на хост.
Наладжваем арбітра
З самім арбітрам асоба рабіць нічога не трэба, яго трэба проста ўлучыць на трэцяй пляцоўцы, задаць яму IP і наладзіць да яго доступ па ICMP і SSH. Сама ж настройка выконваецца з саміх СГД. Пры гэтым наладу арбітра дастаткова выканаць адзін раз на любым з кантролераў СХД у метрокластэры, гэтыя налады будуць распаўсюджаны на ўсе кантролеры аўтаматычна.
У раздзеле Выдаленая рэплікацыя>> Метракластар (на любым кантролеры)>> кнопка «Сканфігураваць».
Уводзім IP арбітра, а таксама кіраўнікі інтэрфейсы двух кантролераў выдаленай СХД.
Пасля гэтага трэба ўключыць усе службы (кнопка "Усё перазапусціць"). У выпадку пераналадкі ў будучыні службы трэба абавязкова перазапускаць, каб настройкі ўступілі ў сілу.
Правяраем, што ўсе службы запушчаны.
На гэтым настройка метракластара завершана.
Краш-тэст
Краш-тэст у нашым выпадку будзе дастаткова просты і хуткі, паколькі функцыянал рэплікацыі (пераключэнне, кансістэнтнасць і інш.) быў разгледжаны ў . Таму для выпрабавання надзейнасці менавіта метракластара нам дастаткова праверыць аўтаматызацыю выяўлення аварыі, пераключэння і адсутнасць страт пры запісе (прыпынку ўводу-вываду).
Для гэтага мы эмулюем поўную адмову адной з СХД, фізічна выключыўшы абодва яе кантролера, запусціўшы папярэдне капіраванне вялікага файла на LUN, які павінен актывавацца на іншы СХД.
Адключаем адну СГД. На другой СГД бачым алерты і паведамленні ў логах аб тым, што знікла сувязь з суседняй сістэмай. Калі настроены абвесткі па SMTP або SNMP маніторынг, то адміну прыйдуць адпаведныя абвесткі.
Роўна праз 10 секунд (відаць на абодвух скрыншотах) рэплікацыйная сувязь METRO (тая, што была Primary на якая ўпала СГД) аўтаматычна стала Primary на якая працуе СГД. Задзейнічаўшы існуючы мапінг, LUN TEST застаўся даступны хасту, запіс крыху асеў (у межах абяцаных 10 працэнтаў), але не перарваўся.
Тэст завершаны паспяхова.
падводзім вынік
Бягучая рэалізацыя метракластара ў сістэмах захоўвання AERODISK Engine N-серыі ў поўнай меры дазваляе вырашаць задачы, дзе патрабуецца выключыць ці мінімізаваць час прастою ІТ-паслуг і забяспечыць іх працу ў рэжыме 24/7/365 з мінімальнымі працавыдаткамі.
Можна сказаць, вядома, што ўсё гэта тэорыя, ідэальныя лабараторныя ўмовы і гэтак далей… А ў нас ёсць шэраг рэалізаваных праектаў, у якіх мы рэалізавалі функцыянал катастрофаўстойлівасці, і сістэмы працуюць выдатна. Адзін з нашых даволі вядомых заказчыкаў, дзе выкарыстоўваюцца якраз дзве СХД у катастрофаўстойлівай канфігурацыі, ужо даў згоду на публікацыю інфармацыі аб праекце, таму ў наступнай частцы мы раскажам аб баявым укараненні.
Дзякуй, чакаем прадуктыўнай дыскусіі.
Крыніца: habr.com