Прывітанне, чытачы хабра! Тэмай гэтага артыкула будзе рэалізацыя сродкаў катастрофаўстойлівасці ў сістэмах захоўвання AERODISK Engine. Першапачаткова мы хацелі напісаць у адным артыкуле пра абодва сродкі: рэплікацыю і метракластэр, але, на жаль, артыкул атрымаўся занадта вялікі, таму мы разбілі артыкул на дзве часткі. Пойдзем ад простага да складанага. У гэтым артыкуле мы наладзім і пратэстуем сінхронную рэплікацыю – уранім адзін ЦАД, а таксама абарвём канал сувязі паміж ЦАД-амі і паглядзім, што з гэтага атрымаецца.
Нашы заказчыкі нам часта задаюць розныя пытанні аб рэплікацыі, таму, перш чым пераходзіць да настройкі і тэсціравання рэалізацыі рэплік, мы крыху раскажам, што такое рэплікацыя ў СХД.
крыху тэорыі
Рэплікацыя ў СГД - гэта пастаянны працэс забеспячэння ідэнтычнасці дадзеных адначасова на некалькіх СГД. Тэхнічна рэплікацыя выконваецца двума метадамі.
Сінхронная рэплікацыя – гэта капіраванне дадзеных з асноўнай СХД на рэзервовую з наступным абавязковым пацвярджэннем абедзвюх СХД, што дадзеныя запісаны і пацверджаны. Менавіта пасля пацверджання з двух бакоў (з абодвух СГД) дадзеныя лічацца запісанымі, і з імі можна працаваць. Тым самым забяспечваецца гарантаваная ідэнтычнасць дадзеных на ўсіх СГД, якія ўдзельнічаюць у рэпліцы.
Плюсы такога метаду:
- Дадзеныя заўсёды ідэнтычныя на ўсіх СГД
Мінусы:
- Высокі кошт рашэння (хуткія каналы сувязі, дарагое оптавалакно, даўгахвалевыя трансіверы і да т.п.)
- Абмежаванні па адлегласці (у межах некалькіх дзясяткаў кіламетраў)
- Няма абароны ад лагічнага псуты дадзеных (калі дадзеныя сапсуюць (свядома ці выпадкова) на асноўны СХД, то яны аўтаматам і маментальна стануць сапсаваны на рэзервовай, бо дадзеныя заўсёды ідэнтычныя (вось такі парадокс)
Асінхронная рэплікацыя – гэта таксама капіраванне дадзеных з асноўнай СХД на рэзервовую, але з пэўнай затрымкай і без неабходнасці пацверджання запісу на другім баку. Працаваць з дадзенымі можна адразу пасля запісу на асноўную СГД, а на рэзервовай СГД дадзеныя будуць даступныя праз некаторы час. Ідэнтычнасць дадзеных у гэтым выпадку, зразумела, не забяспечваецца зусім. Дадзеныя на рэзервовай СГД заўсёды знаходзяцца крыху «ў мінулым».
Плюсы асінхроннай рэплікацыі:
- Невысокі кошт рашэння (любыя каналы сувязі, оптыка апцыянальная)
- Няма абмежаванняў па адлегласці
- На рэзервовай СХД дадзеныя не псуюцца ў выпадку іх псуты на асноўны (як мінімум, некаторы час), калі дадзеныя сталі сапсаваны, заўсёды можна спыніць рэпліку, каб не дапусціць псуту дадзеных на рэзервовай СХД
Мінусы:
- Дадзеныя ў розных ЦАД заўсёды неідэнтычныя
Такім чынам, выбар рэжыму рэплікацыі залежыць ад задач бізнэсу. Калі вам крытычна, каб у рэзервовым ЦАД былі абсалютна тыя ж дадзеныя што і ў асноўным (г.зн. патрабаванне бізнесу па RPO = 0), то прыйдзецца раскашэліцца і мірыцца з абмежаваннямі сінхроннай рэплікі. А калі затрымка стану дадзеных дапушчальная ці проста няма грошай, то, адназначна, трэба выкарыстоўваць асінхронны метад.
Яшчэ асобна вылучым такі рэжым (дакладней, ужо тапалогію) як метрокластэр. У рэжыме метракластара выкарыстоўваецца сінхронная рэплікацыя, але, у адрозненне ад звычайнай рэплікі, метракластар дазваляе абедзвюм СГД працаваць у актыўным рэжыме. Г.зн. у вас няма падзелу на актыўны-рэзервовы ЦАДы. Прыкладанні працуюць адначасова з двума СХД, якія фізічна размешчаны ў розных ЦАД-ах. Даўнтаймы пры аварыях у такой тапалогіі вельмі невялікія (RTO, як правіла хвіліны). У гэтым артыкуле мы не будзем разглядаць нашу рэалізацыю метракластара, паколькі гэтая вельмі вялікая і ёмістая тэма, таму ёй мы прысвяцім асобны, наступны артыкул, у працяг гэтым.
Таксама вельмі часта, калі мы гаворым аб рэплікацыі сродкамі СГД, у многіх узнікае слушнае пытанне: > «У многіх прыкладанняў ёсць свае сродкі рэплікацыі, навошта ж выкарыстоўваць рэплікацыю на СХД? Гэта лепш ці горш?
Тут няма адназначнага адказу, таму прывядзем аргументы ЗА і СУПРАЦЬ:
Аргументы ЗА рэплікацыю СГД:
- Прастата рашэння. Адным сродкам вы можаце рэплікаваць увесь масіў дадзеных, незалежна ад тыпу нагрузкі і прыкладанняў. Калі выкарыстоўваць рэпліку ад прыкладанняў, то наладжваць давядзецца кожнае прыкладанне ў асобнасці. Калі іх больш за 2-х, то гэта вельмі працаёмка і дорага (рэплікацыя прыкладанняў патрабуе, як правіла, асобную і не бясплатную ліцэнзію на кожнае прыкладанне. Але пра гэта ніжэй).
- Можна рэплікаваць што заўгодна - любыя прыкладанні, любыя дадзеныя - і яны заўсёды будуць кансістэнтныя. Многія (большасць) прыкладанні не маюць сродкаў рэплікацыі, і рэплікі з боку СГД - адзіны сродак забяспечыць абарону ад катастроф.
- Ня трэба пераплачваць за функцыянал рэплікацыі прыкладанняў. Як правіла, ён каштуе нятанна, гэтак жа, як і ліцэнзіі на рэпліку СГД. Але за ліцэнзію на рэплікацыю СГД трэба заплаціць аднойчы, а ліцэнзію на рэпліку прыкладанняў трэба купляць для кожнага дадатку асобна. Калі такіх прыкладанняў шмат, то гэта ўлятае ў капеечку і кошт ліцэнзій на рэплікацыю СГД становіцца кропляй у моры.
Аргументы СУПРАЦЬ рэплікацыі СГД:
- Рэпліка сродкамі прыкладанняў мае больш функцыянальнасці з пункту гледжання саміх прыкладанняў, дадатак лепш ведае свае дадзеныя (што відавочна), таму варыянтаў працы з імі больш.
- Вытворцы некаторых прыкладанняў не гарантуюць кансістэнтнасць сваіх дадзеных, калі рабіць рэплікацыю іншымі сродкамі. *
*- спрэчны тэзіс. Напрыклад, вядомая кампанія-вытворца СКБД, вельмі доўга афіцыйна заяўляла, што іх СКБД можа нармальна рэплікавацца толькі іх сродкамі, а астатняя рэплікацыя (у тым ліку і СХД-шная) гэта "не true". Але жыццё паказала, што гэта не так. Хутчэй за ўсё, (але гэта не дакладна) гэта проста не самая сумленная спроба дапрадаць яшчэ ліцэнзій замоўцам.
У выніку ў большасці выпадкаў рэплікацыя з боку СГД лепш, т.я. гэта прасцейшы і меней дарагі варыянт, але ёсць складаныя выпадкі, калі неабходны спецыфічны функцыянал прыкладанняў, і трэба працаваць менавіта з рэплікацыяй узроўня прыкладанняў.
З тэорыяй скончылі, зараз практыка
Наладжваць рэпліку мы будзем у нашай лабе. У лабараторных умовах мы эмулявалі два ЦАДа (насамрэч, дзве побач стаячыя стойкі, якія як быццам стаяць у розных будынках). Стэнд складаецца з двух СХД Engine N2, якія злучаны паміж сабой аптычнымі кабелямі. Да абедзвюх СХД падлучаны фізічны сервер з АС Windows Server 2016 выкарыстоўваючы 10Gb Ethernet. Стэнд даволі просты, але сутнасці гэта не мяняе.
Схематычна ён выглядае так:
Лагічна рэплікацыя арганізавана наступным чынам:
Цяпер разбяром функцыянальныя магчымасці рэплікацыі, якія ў нас ёсць зараз.
Падтрымліваецца два рэжыму: асінхронны і сінхронны. Лагічна, што сінхронны рэжым абмежаваны адлегласцю і каналам сувязі. У прыватнасці, для сінхроннага рэжыму патрабуецца выкарыстоўваць оптавалакно ў якасці фізікі і 10 гігабітны Ethernet (або вышэй).
Падтрымліваецца адлегласць для сінхроннай рэплікацыі - 40 кіламетраў, значэнне затрымак канала оптыкі паміж ЦАД да 2 мілісекунд. Наогул працаваць будзе і з вялікімі затрымкамі, але тады будуць моцныя тормазы пры запісе (што таксама лагічна), таму калі вы задумалі сінхронную рэплікацыю паміж ЦАД-амі, варта праверыць якасць оптыкі і затрымкі.
Да асінхроннай рэплікацыі патрабаванні не такія сур'ёзныя. Дакладней, іх няма зусім. Падыдзе любое якое працуе злучэнне па Ethernet.
На бягучы момант у СХД AERODISK ENGINE падтрымліваецца рэплікацыя для блокавых прылад (LUNов) па пратаколе Ethernet (па медзі ці па оптыцы). Для праектаў, дзе абавязкова патрабуецца рэплікацыя праз SAN-фабрыку па Fibre Channel, мы зараз дапісваем адпаведнае рашэнне, але пакуль яно не гатова, таму ў нашым выпадку - толькі Ethernet.
Рэплікацыя можа працаваць паміж любымі СГД серыі ENGINE (N1, N2, N4) з малодшых сістэм на старэйшыя і наадварот.
Функцыянал абодвух рэжымаў рэплікацыі поўнасцю ідэнтычны. Ніжэй падрабязней аб тым, што ёсць:
- Рэплікацыя "one to one" ці "адзін да аднаго", гэта значыць класічны варыянт з двума ЦАД-амі, асноўным і рэзервовым
- Рэплікацыя "one to many" ці "адзін да многіх", г.зн. адзін LUN можна рэпліцыраваць на некалькі СХД адразу
- Актывацыя, дэактывацыя і «разварот» рэплікацыі, адпаведна, для ўключэння, выключэнні ці змены кірунку рэплікацыі
- Рэплікацыя даступная як для пулаў RDG (Raid Distributed Group), так і для DDP (Dynamic Disk Pool). Пры гэтым LUN пула RDG можна рэплікаваць толькі ў іншы RDG. C DDP аналагічна.
Ёсць яшчэ мноства дробных асаблівасцяў, але пералічваць іх няма асаблівага сэнсу, іх мы будзем згадваць па ходзе наладкі.
Настройка рэплікацыі
Працэс налады досыць просты і складаецца з трох этапаў.
- Настройка сеткі
- Настройка сховішча
- Настройка правіл (сувязей) і мапінгу
Важным момантам наладкі рэплікацыі з'яўляецца тое, што першыя два этапы варта паўтараць на выдаленай СГД, трэці этап - толькі на асноўны.
Настройка сеткавых рэсурсаў
Перш за ўсё трэба наладзіць сеткавыя парты, па якіх будзе перадавацца трафік рэплікацыі. Для гэтага порты трэба ўлучыць і задаць на іх IP-адрасы ў падзеле Front-end адаптары.
Пасля гэтага нам трэба стварыць пул (у нашым выпадку RDG) і віртуальны IP для рэплікацыі (VIP). VIP - гэта плывучы IP-адрас, які прывязаны да двух «фізічных» адрасоў кантролераў СХД (партам, якія мы наладжвалі толькі што). Ён будзе асноўным інтэрфейсам рэплікацыі. Таксама можна апераваць не VIP-ым, а VLAN-ым, калі трэба працаваць з тэгіраваным трафікам.
Працэс стварэння VIP-а для рэплікі мала чым адрозніваецца ад стварэння VIP-а для ўводу-высновы (NFS, SMB, iSCSI). VIP у дадзеным выпадку мы ствараем звычайны (без VLAN), але абавязкова паказваем, што ён для рэплікацыі (без гэтага паказальніка мы не зможам дадаць VIP у правіла на наступным кроку).
VIP абавязкова павінен быць у той жа падсеткі, што і IP партоў, паміж якімі ён "плавае".
Паўтараем гэтыя налады на выдаленай СХД, з іншым IP-шнікам, само сабой.
VIP-ы з розных СГД могуць быць у розных падсетках, галоўнае, каб паміж імі была маршрутызацыя. У нашым выпадку як раз паказаны гэты прыклад (192.168.3.XX і 192.168.2.XX)
На гэтым падрыхтоўка сеткавай часткі завершана.
Наладжваем сховішчы
Настройка сховішча пад рэпліку адрозніваецца ад звычайнага толькі тым, што мапінг мы робім праз спецыяльнае меню "Мапінг рэплікацыі". У астатнім усё гэтак жа, як са звычайнай наладай. Цяпер па парадку.
У раней створаным пуле R02 патрабуецца стварыць LUN. Ствараем, завем яго LUN1.
Таксама нам трэба стварыць такі ж LUN на выдаленай СГД ідэнтычнага аб'ёму. Ствараем. Каб пазбегнуць блытаніны, выдалены LUN назавем LUN1R
Калі б нам запатрабавалася ўзяць LUN, які ўжо існуе, то на час налады рэплікі гэты прадуктыўны LUN запатрабавалася бы адмантаваць ад хаста, а на выдаленай СХД проста стварыць пусты LUN ідэнтычнага аб'ёму.
Настройка сховішча завершана, пераходзім да стварэння правіла рэплікацыі.
Настройка правіл рэплікацыі або рэплікацыйных сувязей
Пасля стварэння LUN-ов на СХД, якая будзе на дадзены момант асноўнай (Primary), наладжваем правіла рэплікацыі LUN1 на СХД1 у LUN1R на СХД2.
Настройка робіцца ў меню «Выдаленая рэплікацыя»
Ствараем правіла. Для гэтага трэба пазначыць атрымальніка рэплікі. Тамака жа задаем імя сувязі і тып рэплікацыі (сінхронная ці асінхронная).
У поле "выдаленыя сістэмы" дадаем нашу СХД2. Для дадання трэба выкарыстоўваць кіравальныя IP СХД (MGR) і імя выдаленага LUN, у які мы будзем выконваць рэплікацыю (у нашым выпадку LUN1R). Кіраўнікі IP патрэбныя толькі на этапе дадання сувязі, трафік рэплікацыі праз іх перадавацца не будзе, для гэтага будзе выкарыстоўвацца сканфігураваны раней VIP.
Ужо на гэтым этапе мы можам дадаць больш за адну выдаленай сістэмы для тапалогіі "one to many": націскаем кнопку "дадаць вузел", як на малюнку ніжэй.
У нашым выпадку выдаленая сістэма адна, таму абмяжоўваемся гэтым.
Правіла гатова. Звярніце ўвагу, што дадаецца яно аўтаматычна на ўсіх удзельніках рэплікацыі (у нашым выпадку іх два). Такіх правіл можна стварыць колькі заўгодна, для любой колькасці LUN-ов і ў любыя бакі. Напрыклад, мы можам для балансавання нагрузкі частка LUN-ов рэплікаваць з СХД1 на СХД2, а іншую частку наадварот - з СХД2 на СХД1.
СГД1. Адразу пасля стварэння пачалася сінхранізацыя.
СХД2. Бачым тое ж правіла, але ўжо скончылася сінхранізацыя.
LUN1 на СХД1 знаходзіцца ў ролі Primary, гэта значыць ён з'яўляецца актыўным. LUN1R на СХД2 знаходзіцца ў ролі Secondary, гэта значыць ён знаходзіцца на падхваце, на выпадак адмовы СХД1.
Цяпер мы можам падключыць наш LUN да хасту.
Будзем рабіць падлучэнне па iSCSI, хаця можна рабіць і па FC. Налада мапінгу па iSCSI LUN-а ў рэпліцы практычна не адрозніваецца ад звычайнага сцэнара, таму падрабязна тут разглядаць гэта не будзем. Калі што, гэты працэс апісаны ў артыкуле «.
Адзінае адрозненне - мапінг ствараем у меню "Мапінг рэплікацыі"
Наладзілі мапінг, падалі LUN хасту. Хост убачыў LUN.
Фарматуем яго ў лакальную файлавую сістэму.
Усё, на гэтым настройка завершана. Далей пайдуць тэсты.
Тэставанне
Тэставаць мы будзем тры асноўныя сцэнары.
- Штатнае пераключэнне роляў Secondary > Primary. Штатнае пераключэнне роляў трэба на выпадак, калі, напрыклад, у асноўным ЦАД-е нам трэба выканаць якія-небудзь прафілактычныя аперацыі і на гэты час, каб дадзеныя былі даступныя, мы пераводзім нагрузку ў рэзервовы ЦАД.
- Аварыйнае пераключэнне роляў Secondary > Primary (адмова ЦАД-а). Гэта асноўны сцэнар, дзеля якога існуе рэплікацыя, які можа дапамагчы перажыць поўную адмову ЦАД, не спыніўшы працу кампаніі на працяглы тэрмін.
- Абрыў каналаў сувязі паміж ЦАД-амі. Праверка карэктных паводзін двух СХД ва ўмовах, калі па якіх-небудзь прычынах недаступны канал сувязі паміж ЦАД-амі (напрыклад, экскаватар капнуў не там і парваў цёмную оптыку).
Для пачатку мы пачнем пісаць дадзеныя на наш LUN (пішам файлы з рандомнымі дадзенымі). Адразу глядзім, што утылізуецца канал сувязі паміж СГД. Гэта лёгка зразумець, калі адкрыць маніторынг нагрузкі партоў, якія адказваюць за рэплікацыю.
На абедзвюх СГД ёсць зараз "карысныя" дадзеныя, можам пачынаць тэст.
На ўсякі выпадак, паглядзім хэш-сумы аднаго з файлаў і запішам.
Штатнае пераключэнне роляў
Аперацыю па пераключэнні роляў (змене кірунку рэплікацыі) можна рабіць з любой СХД, але ўсё роўна схадзіць трэба будзе на абедзве, паколькі на Primary трэба будзе адключыць мапінг, а на Secondary (якая стане Primary) уключыць яго.
Магчыма, зараз узнікае слушнае пытанне: а чаму б гэта не аўтаматызаваць? Адказваем: усё проста, рэплікацыя - гэта просты сродак катастрофаўстойлівасці, заснаванае выключна на ручных аперацыях. Для аўтаматызацыі гэтых аперацый існуе рэжым метракластара, ён цалкам аўтаматызаваны, але яго настройка значна складаней. Аб наладзе метракластара мы напішам у наступным артыкуле.
На асноўны СХД адключаем мапінг, каб гарантавана спыніць запіс.
Потым на адной з СХД (не важна, на асноўнай ці рэзервовай) у меню "Выдаленая рэплікацыя" выбіраем нашу сувязь REPL1 і націскаем "Змяніць ролю".
Праз некалькі секунд LUN1R (рэзервовая СГД), становіцца Primary.
Які робіцца мапінг LUN1R з СХД2.
Пасля гэтага на хасце аўтаматычна чапляецца наш дыск E:, толькі на гэты раз ён "прыляцеў" з LUN1R.
На ўсякі выпадак, параўноўваем хэш-сумы.
Ідэнтычна. Тэст пройдзены.
Аварыйнае пераключэнне. Адмова ЦАД-а
У дадзены момант асноўны СХД пасля штатнага пераключэння з'яўляецца СХД2 і LUN1R, адпаведна. Для эмуляцыі аварыі мы адключым харчаванне на абодвух кантролерах СХД2.
Доступу да яе больш няма.
Глядзім, што адбываецца на СХД 1 (рэзервовы на дадзены момант).
Бачым, што Primary LUN (LUN1R) недаступны. Зьявілася паведамленьне пра памылку ў логах, у інфармацыйнай панэлі, а таксама ў самім правіле рэплікацыі. Адпаведна, дадзеныя з хаста зараз недаступныя.
Змяняны ролю LUN1 на Primary.
Справам мапінг да хаста.
Пераконваемся, што дыск E з'явіўся на хасце.
Правяраем хэш.
Усё ў парадку. Падзенне ЦАД-а, які быў актыўны, СГД перажыла паспяхова. Прыкладны час, які мы патрацілі на падлучэнне «развароту» рэплікацыі і падлучэнне LUN-а з рэзервовага ЦАД-а склала каля 3-х хвілін. Зразумела, што ў рэальным прадуктыве ўсё нашмат складаней, і акрамя дзеянняў з СХД трэба выканаць яшчэ мноства аперацый у сетцы, на хастах, у прыкладаннях. І ў жыцці гэты прамежак часу будзе значна даўжэйшым.
Тут жадаецца напісаць, што ўсё, тэст паспяхова завершаны, але не будзем спяшацца. Асноўная СГД "ляжыць", мы ведаем, што калі яна "падала", яна была ў ролі Primary. Што адбудзецца, калі яна раптоўна ўключыцца? Будуць дзве ролі Primary, што роўна псуту дадзеных? Цяпер праверым.
Ідзем раптам уключаць ляжалую СГД.
Яна загружаецца некалькі хвілін і пасля гэтага вяртаецца ў строй пасля нядоўгай сінхранізацыі, але ўжо ў ролі Secondary.
Усё ОК. Split-brain-а не здарылася. Мы аб гэтым падумалі, і заўсёды пасля падзення СГД паднімаецца ў ролі Secondary, незалежна ад таго, у якой ролі яна была "пры жыцці". Цяпер дакладна можна сказаць, што тэст на адмову ЦАД прайшоў паспяхова.
Адмова каналаў сувязі паміж ЦАД-амі
Галоўная задача гэтага тэсту - пераканацца ў тым, што СГД не пачне дзівачыць, калі ў яе часова знікнуць каналы сувязі паміж двума СХД, а потым з'явяцца зноў.
Такім чынам. Адключаем правады паміж СХД (уявім, што іх капнуў экскаватар).
На Primary бачым, што няма сувязі з Secondary.
На Secondary бачым, што няма сувязі з Primary.
Працуе ўсё нармальна, і мы працягваем пісаць дадзеныя на асноўную СГД, гэта значыць, яны з рэзервовай ужо гарантавана адрозніваюцца, гэта значыць "раз'ехаліся".
Праз некалькі хвілін "чынім" канал сувязі. Як толькі СГД адзін аднаго ўбачылі, аўтаматычна ўключаецца сінхранізацыя дадзеных. Тут ад адміністратара нічога не патрабуецца.
Праз некаторы час сінхранізацыя завяршаецца.
Злучэнне адноўлена, ніякіх няштатных сітуацый абрыў каналаў сувязі не выклікаў, а пасля ўключэння аўтаматычна прайшла сінхранізацыя.
Высновы
Мы разабралі тэорыю - што і навошта трэба, дзе плюсы, а дзе мінусы. Потым настроілі сінхронную рэплікацыю паміж двума СГД.
Далей былі праведзены асноўныя тэсты на штатнае пераключэнне, адмова ЦАД-а і абрыў каналаў сувязі. Ва ўсіх выпадках СГД адпрацавала добра. Стратаў дадзеных няма, адміністрацыйныя аперацыі зведзены да мінімуму для ручнога сцэнара.
У наступны раз мы ўскладнім сітуацыю і пакажам як уся гэтая логіка працуе ў аўтаматызаваным метрокластары ў рэжыме active-active, гэта значыць калі абедзве СГД з'яўляюцца асноўнымі, а паводзіны пры адмовах СГД цалкам аўтаматызавана.
Пішыце калі ласка каментары, будзем рады разумнай крытыцы і слушным парадам.
Да новых сустрэч.
Крыніца: habr.com