Прывітанне, Хабр!
Пасля навагодніх свят мы перазапусцілі катастрофаўстойлівае воблака на базе дзвюх пляцовак. Сёння распавядзем, як гэта ўладкована, і пакажам, што адбываецца з кліенцкімі віртуальнымі машынамі пры адмове асобных элементаў кластара і падзенні цэлай пляцоўкі (спойлер з імі ўсё добра).
СГД катастрофаўстойлівага аблокі на пляцоўцы OST.
Што ўнутры
Пад капотам у кластара серверы Cisco UCS з гіпервізарам VMware ESXi, дзве СХД INFINIDAT InfiniBox F2240, сеткавае абсталяванне Cisco Nexus, а таксама SAN-світчы Brocade. Кластар разнесены на дзве пляцоўкі - OST і NORD, т. е. у кожным дата-цэнтры ідэнтычны набор абсталявання. Уласна, гэта і робіць яго катастрофаўстойлівасцю.
У рамках адной пляцоўкі асноўныя элементы таксама прадубліраваны (хасты, SAN-світчы, сетка).
Дзве пляцоўкі злучаныя вылучанымі оптавалакновымі трасамі, таксама зарэзерваванымі.
Пару слоў пра СГД. Першы варыянт катастрофаўстойлівага аблокі мы будавалі на NetApp. Тут выбралі INFINIDAT, і вось чаму:
- Опцыя Active-Active рэплікацыі. Яна дазваляе віртуальнай машыне заставацца ў працаздольным стане нават пры поўнай адмове адной з СГД. Пра рэплікацыю раскажу падрабязней далей.
- Тры дыскавых кантролера для павышэння адмоваўстойлівасці сістэмы. Звычайна іх два.
- Гатовае рашэнне. Да нас прыехала ўжо сабраная стойка, якую толькі трэба падключыць да сеткі і настроіць.
- Уважлівая тэхпадтрымка. Інжынеры INFINIDAT пастаянна аналізуюць логі і падзеі СГД, усталёўваюць новыя версіі ў прашыўцы, дапамагаюць з наладай.
Вось крыху фотачак з unpacking'а:
Як працуе
Воблака ўжо адмоваўстойліва ўнутры сябе. Яно абараняе кліента ад адзінкавых апаратных і праграмных адмоў. Катастрофоустойчивое ж дапаможа абараніцца ад масавых збояў у межах адной пляцоўкі: напрыклад, адмова СХД (ці кластара SDS, што здараецца нярэдка 🙂 ), масавыя памылкі ў сетцы захоўвання і іншае. Ну і самае галоўнае: такое воблака ратуе, калі становіцца недаступнай цэлая пляцоўка з-за пажару, блэкаўту, рэйдэрскага захопу, высадкі іншапланецян.
Ва ўсіх гэтых выпадках кліенцкія віртуальныя машыны працягваюць працаваць, і вось чаму.
Схема кластара ўладкована так, што любы ESXi-хост з кліенцкімі віртуальнымі машынамі можа звяртацца да любой з двух СХД. Калі СГД на пляцоўцы OST выйдзе са строю, то віртуальныя машыны працягнуць працаваць: хасты, на якіх яны працуюць, будуць звяртацца за дадзенымі да СХД на NORD.
Вось так выглядае схема падключэння ў кластары.
Гэта магчыма дзякуючы таму, што паміж SAN-фабрыкамі дзвюх пляцовак наладжаны Inter-Switch Link: SAN-світч Fabric A OST злучаны з SAN-світчам Fabric A NORD, аналагічна і для SAN-світчаў Fabric B.
Ну і каб усе гэтыя хітраспляценні SAN-фабрык мелі сэнс, паміж двума СХД наладжаная Active-Active рэплікацыя: інфармацыя практычна адначасова запісваецца на лакальную і выдаленую СХД, RPO=0. Атрымліваецца, што на адной СГД захоўваецца арыгінал дадзеных, на іншай - іх рэпліка. Дадзеныя рэпліцыруюцца на ўзроўні тамоў СХД, а ўжо на іх захоўваюцца дадзеныя ВМ (яе дыскі, канфігурацыйны файл, swap-файл і інш.).
ESXi-хост бачыць асноўны том і яго рэпліку як адна дыскавая прылада (Storage Device). Ад ESXi-хаста да кожнай дыскавай прылады ідуць 24 шляхі:
12 шляхоў звязваюць яго з лакальнай СХД (аптымальныя шляхі), а астатнія 12 - з выдаленай (не аптымальныя шляхі). У штатнай сітуацыі ESXi звяртаецца да дадзеных на лакальнай СГД, выкарыстоўваючы "аптымальныя" шляхі. Пры выхадзе з ладу гэтай СХД ESXi губляе аптымальныя шляхі і перамыкаецца на "неаптымальныя". Вось як гэта выглядае на схеме.
Схема катастрофаўстойлівага кластара.
Усе кліенцкія сеткі заведзены на абедзве пляцоўкі праз агульную сеткавую фабрыку. На кожнай пляцоўцы працуе Provider Edge (PE), на якім і тэрмінуюцца сеткі кліента. PE аб'яднаны ў агульны кластар. Пры адмове PE на адной пляцоўцы ўвесь трафік перанакіроўваецца на другую пляцоўку. Дзякуючы гэтаму віртуальныя машыны з пляцоўкі, якая засталася без PE, застаюцца даступнымі па сетцы для кліента.
Давайце зараз паглядзім, што будзе адбывацца з віртуальнымі машынамі кліента пры розных адмовах. Пачнем з самых лайтавых варыянтаў і скончым самым сур'ёзным - адмовай усёй пляцоўкі. У прыкладах асноўнай пляцоўкай будзе OST, а рэзервовай, з рэплікамі дадзеных, - NORD.
Што адбываецца з віртуальнай машынай кліента, калі…
Адмаўляе Replication Link. Рэплікацыя паміж СГД дзвюх пляцовак спыняецца.
ESXi будуць працаваць толькі з лакальнымі дыскавымі прыладамі (па аптымальных шляхах).
Віртуальныя машыны працягваюць працаваць.
Адбываецца разрыў ISL (Inter-Switch Link). Выпадак малаверагодны. Няўжо што які-небудзь шалёны экскаватар перакапае адразу некалькі аптычных трас, якія праходзяць незалежнымі маршрутамі і заведзеныя на пляцоўкі праз розныя ўводы. Але ўсё ж. У гэтым выпадку ESXi-хасты губляюць палову шляхоў і могуць звяртацца толькі да сваіх лакальных СГД. Рэплікі збіраюцца, але хасты не змогуць да іх звяртацца.
Віртуальныя машыны працуюць штатна.
Адмаўляе SAN-світч на адной з пляцовак. ESXi-хасты губляюць частку шляхоў да СГД. У гэтым выпадку хасты на пляцоўцы, дзе адмовіў світч, будуць працаваць толькі праз адзін свой HBA.
Віртуальныя машыны пры гэтым працягваюць працаваць штатна.
Адмаўляюць усе SAN-світчы на адной з пляцовак. Дапушчальны, такая бяда здарылася на пляцоўцы OST. У гэтым выпадку ESXi-хасты на гэтай пляцоўцы страцяць усе шляхі да сваіх дыскавых прылад. У справу ўступае стандартны механізм VMware vSphere HA: ён перазапусціць усе віртуальныя машыны пляцоўкі OST у NORD`е максімум праз 140 секунд.
Віртуальныя машыны, якія працуюць на хастах пляцоўкі NORD, працуюць штатна.
Адмаўляе ESXi-хост на адной пляцоўцы. Тут зноў адпрацоўвае механізм vSphere HA: віртуальныя машыны са збойнага хаста перазапускаюцца на іншых хастах – на той жа ці выдаленай пляцоўцы. Час перазапуску віртуальнай машыны - да 1 хвіліны.
Калі адмаўляюць усе ESXi-хасты пляцоўкі OST, тут ужо без варыянтаў: ВМ перазапускаюцца на іншы. Час перазапуску тое ж.
Адмаўляе СГД на адной пляцоўцы. Дапусцім, адмовіла СГД на пляцоўцы OST. Тады ESXi-хасты пляцоўкі OST перамыкаюцца на працу з рэплікамі СХД у NORD'e. Пасля вяртання збойнай СХД у строй адбудзецца прымусовая рэплікацыя, ESXi-хасты OST зноў пачнуць звяртацца да лакальнай СХД.
Віртуальныя машыны ўвесь гэты час працуюць штатна.
Адмаўляе адна з пляцовак. У гэтым выпадку ўсе віртуальныя машыны будуць перазапускаць на рэзервовай пляцоўцы праз механізм vSphere HA. Час перазапуску ВМ - 140 секунд. Пры гэтым усе сеткавыя налады віртуальнай машыны захаваюцца, і яна застаецца даступнай для кліента па сетцы.
Каб перазапуск машын на рэзервовай пляцоўцы прайшоў без праблем, кожная пляцоўка запоўнена толькі напалову. Другая палова - рэзерв на выпадак пераезду ўсіх віртуальных машын з другой, пацярпелай, пляцоўкі.
Вось ад такіх адмоваў абараняе катастрофаўстойлівае воблака на базе двух дата-цэнтраў.
Задавальненне гэтае нятаннае, бо, у дадатак да асноўных рэсурсаў, патрэбен рэзерв на другой пляцоўцы. Таму размяшчаюць у такім воблаку бізнес-крытычныя сэрвісы, працяглы просты якіх нясе вялікія фінансавыя і рэпутацыйнага страты, або калі да інфармацыйнай сістэме прад'яўляюцца патрабаванні па катастрофаўстойлівасці ад рэгулятараў або ўнутраных рэгламентаў кампаніі.
Крыніцы:
Крыніца: habr.com