Здраво читаоци Хабра! Тема овог чланка биће имплементација алата за опоравак од катастрофе у АЕРОДИСК Енгине системима за складиштење података. У почетку смо хтели да у једном чланку пишемо о оба алата: репликацији и метрокластеру, али се, нажалост, показало да је чланак предугачак, па смо га поделили на два дела. Идемо од једноставног ка сложеном. У овом чланку ћемо поставити и тестирати синхрону репликацију - избацићемо један центар података, а такође ћемо прекинути комуникациони канал између центара података и видети шта ће се десити.
Наши купци нам често постављају разна питања о репликацији, па ћемо вам пре него што пређемо на подешавање и тестирање имплементације реплика рећи нешто о томе шта је репликација у складишту.
Мало теорије
Репликација у системима за складиштење је континуирани процес обезбеђивања идентитета података на неколико система складиштења истовремено. Технички, репликација се остварује на два начина.
Синхрона репликација – ово је копирање података из главног система за складиштење у резервни, након чега следи обавезна потврда из оба система складиштења да су подаци снимљени и потврђени. Након потврде са обе стране (оба система складиштења) подаци се сматрају снимљеним и са њима се може радити. Ово осигурава загарантован идентитет података на свим системима за складиштење који учествују у реплици.
Предности ове методе:
- Подаци су увек идентични на свим системима за складиштење
Против:
- Висока цена решења (брзи комуникациони канали, скупа оптичка влакна, дуготаласни примопредајници, итд.)
- Ограничења удаљености (унутар неколико десетина километара)
- Не постоји заштита од логичког оштећења података (ако су подаци оштећени (намерно или случајно) на главном систему за складиштење, они ће се аутоматски и тренутно оштетити на резервном, пошто су подаци увек идентични (то је парадокс)
Асинхрона репликација – ово је такође копирање података из главног система за складиштење у резервни, али са одређеним закашњењем и без потребе за потврдом уписа на другој страни. Можете радити са подацима одмах након што их снимите у главни систем за складиштење, а на систему резервне копије подаци ће бити доступни након неког времена. Идентитет података у овом случају, наравно, уопште није обезбеђен. Подаци у систему за складиштење резервних копија су увек мало „у прошлости“.
Предности асинхроне репликације:
- Решење са ниским трошковима (било који канали комуникације, опциона оптика)
- Нема ограничења удаљености
- На систему за складиштење резервних копија подаци се не погоршавају ако се оштете на главном (барем неко време); ако се подаци оштете, увек можете зауставити реплику да бисте спречили оштећење података на систему за складиштење резервних копија
Против:
- Подаци у различитим центрима података нису увек идентични
Дакле, избор начина репликације зависи од пословних циљева. Ако је за вас кључно да резервни центар података садржи потпуно исте податке као и главни центар података (тј. пословни захтев за РПО = 0), онда ћете морати да издвојите новац и да се помирите са ограничењима синхроног реплика. А ако је кашњење у стању података прихватљиво или једноставно нема новца, онда свакако морате користити асинхрони метод.
Хајде да такође посебно истакнемо такав режим (тачније, топологију) као метрокластер. У режиму метрокластера користи се синхрона репликација, али, за разлику од обичне реплике, метрокластер омогућава да оба система складиштења раде у активном режиму. Оне. немате раздвајање између активних и приправних центара података. Апликације раде истовремено са два система за складиштење података, који се физички налазе у различитим центрима података. Застоји током незгода у таквој топологији су веома мали (РТО, обично минути). У овом чланку нећемо разматрати нашу имплементацију метрокластера, пошто је ово веома велика и обимна тема, па ћемо јој посветити посебан, следећи чланак, у наставку овог.
Такође, веома често, када говоримо о репликацији користећи системе за складиштење, многи људи имају разумно питање: > „Многе апликације имају сопствене алате за репликацију, зашто користити репликацију на системима за складиштење? Да ли је боље или горе?
Овде нема јасног одговора, па ево аргумената ЗА и ПРОТИВ:
Аргументи ЗА репликацију складишта:
- Једноставност решења. Са једним алатом, можете да реплицирате цео скуп података, без обзира на врсту оптерећења и примену. Ако користите реплику из апликација, мораћете да конфигуришете сваку апликацију посебно. Ако их има више од 2, онда је ово изузетно радно интензивно и скупо (репликација апликације обично захтева посебну, а не бесплатну лиценцу за сваку апликацију. Али више о томе у наставку).
- Можете реплицирати било шта - било коју апликацију, било који податак - и увек ће бити доследно. Многе (већина) апликација немају могућности репликације, а реплике из система за складиштење су једини начин да се обезбеди заштита од катастрофа.
- Нема потребе да преплаћујете за функционалност репликације апликације. По правилу, није јефтин, баш као и лиценце за реплику система за складиштење података. Али морате једном да платите лиценцу за репликацију складишта, а лиценцу за реплику апликације потребно је купити за сваку апликацију посебно. Ако има много таквих апликација, онда то кошта прилично пени, а цена лиценци за репликацију складиштења постаје кап у чаши.
Аргументи ПРОТИВ репликације складишта:
- Реплика кроз апликације има више функционалности са становишта самих апликација, апликација боље познаје своје податке (очигледно), тако да има више опција за рад са њима.
- Произвођачи неких апликација не гарантују конзистентност својих података ако се репликација врши помоћу алата треће стране. *
* - контроверзна теза. На пример, познати произвођач ДБМС-а је већ дуже време званично изјављивао да се њихов ДБМС може нормално реплицирати само помоћу њихових средстава, а остатак репликације (укључујући системе за складиштење) „није тачно“. Али живот је показао да то није тако. Највероватније (али то није сигурно) ово једноставно није најпоштенији покушај да се више лиценци прода купцима.
Као резултат тога, у већини случајева, репликација из система за складиштење је боља, јер Ово је једноставнија и јефтинија опција, али постоје сложени случајеви када је потребна специфична функционалност апликације и потребно је радити са репликацијом на нивоу апликације.
Готово са теоријом, сада пракса
Конфигурисаћемо реплику у нашој лабораторији. У лабораторијским условима емулирали смо два дата центра (у ствари, два суседна сталка која су изгледала као да су у различитим зградама). Сталак се састоји од два система за складиштење мотора Н2, који су међусобно повезани оптичким кабловима. Физички сервер који ради под оперативним системом Виндовс Сервер 2016 је повезан са оба система за складиштење помоћу 10Гб Етхернет-а. Сталак је прилично једноставан, али то не мења суштину.
Шематски то изгледа овако:
Логично, репликација је организована на следећи начин:
Сада погледајмо функционалност репликације коју сада имамо.
Подржана су два режима: асинхрони и синхрони. Логично је да је синхрони режим ограничен растојањем и комуникационим каналом. Конкретно, синхрони режим захтева употребу оптичких влакана као физике и 10 Гигабит Етхернет (или више).
Подржано растојање за синхрону репликацију је 40 километара, вредност кашњења оптичког канала између центара података је до 2 милисекунде. Генерално, радиће са великим кашњењима, али тада ће доћи до јаких успоравања током снимања (што је и логично), па ако планирате синхрону репликацију између дата центара, требало би да проверите квалитет оптике и кашњења.
Захтеви за асинхрону репликацију нису тако озбиљни. Тачније, њих уопште нема. Било која исправна Етхернет веза ће бити довољна.
Тренутно, АЕРОДИСК ЕНГИНЕ систем складиштења подржава репликацију за блок уређаје (ЛУН-ове) преко Етхернет протокола (преко бакра или оптичког). За пројекте где је потребна репликација преко САН тканине преко Фибре Цханнел-а, тренутно додајемо одговарајуће решење, али оно још није спремно, тако да у нашем случају само Етхернет.
Репликација може да ради између било којег система за складиштење серије ЕНГИНЕ (Н1, Н2, Н4) од млађих система до старијих и обрнуто.
Функционалност оба режима репликације је потпуно идентична. Испод је више детаља о томе шта је доступно:
- Репликација „један на један“ или „један на један“, односно класична верзија са два дата центра, главним и резервним
- Репликација је „један према многима“ или „један према многима“, тј. један ЛУН се може реплицирати на неколико система за складиштење одједном
- Активирајте, деактивирајте и „обрните“ репликацију, респективно, да бисте омогућили, онемогућили или променили смер репликације
- Репликација је доступна за РДГ (Раид Дистрибутед Гроуп) и ДДП (Динамиц Диск Поол) скупове. Међутим, ЛУН-ови РДГ скупа могу се реплицирати само на други РДГ. Исто са ДДП-ом.
Има још много малих карактеристика, али нема посебне сврхе да их набрајамо; поменућемо их како будемо постављали.
Подешавање репликације
Процес подешавања је прилично једноставан и састоји се од три фазе.
- Подешавање мреже
- Подешавање складиштења
- Постављање правила (веза) и мапирање
Важна тачка у постављању репликације је да се прве две фазе треба поновити на систему за удаљено складиштење, трећа фаза - само на главном.
Подешавање мрежних ресурса
Први корак је конфигурисање мрежних портова преко којих ће се преносити саобраћај репликације. Да бисте то урадили, потребно је да омогућите портове и подесите њихове ИП адресе у одељку Фронт-енд адаптери.
Након овога, потребно је да креирамо базен (у нашем случају РДГ) и виртуелну ИП адресу за репликацију (ВИП). ВИП је плутајућа ИП адреса која је везана за две „физичке“ адресе контролера складишта (портови које смо управо конфигурисали). Ово ће бити главни интерфејс за репликацију. Такође можете да радите не са ВИП, већ са ВЛАН-ом, ако треба да радите са означеним саобраћајем.
Процес креирања ВИП-а за реплику се не разликује много од креирања ВИП-а за И/О (НФС, СМБ, иСЦСИ). У овом случају креирамо обичан ВИП (без ВЛАН-а), али обавезно назначите да је за репликацију (без овог показивача нећемо моћи да додамо ВИП правилу у следећем кораку).
ВИП мора бити у истој подмрежи као и ИП портови између којих лебди.
Понављамо ова подешавања на удаљеном систему за складиштење, са другачијим ИП-ом, наравно.
ВИП-ови из различитих система складиштења могу бити у различитим подмрежама, главна ствар је да постоји рутирање између њих. У нашем случају, овај пример је тачно приказан (192.168.3.КСКС и 192.168.2.КСКС)
Овим је завршена припрема мрежног дела.
Подешавање складишта
Подешавање складишта за реплику разликује се од уобичајеног само по томе што мапирање вршимо кроз посебан мени „Мапирање репликације“. Иначе је све исто као и код нормалног подешавања. Сада, редом.
У претходно креираном скупу Р02, потребно је да креирате ЛУН. Хајде да га направимо и назовемо га ЛУН1.
Такође морамо да креирамо исти ЛУН на удаљеном систему за складиштење идентичне величине. Ми стварамо. Да не би било забуне, назовимо даљински ЛУН ЛУН1Р
Ако је потребно да узмемо ЛУН који већ постоји, онда би приликом постављања реплике морали да искључимо овај продуктивни ЛУН са хоста и једноставно креирамо празан ЛУН идентичне величине на систему за удаљено складиштење.
Подешавање складишта је завршено, пређимо на креирање правила репликације.
Постављање правила репликације или веза за репликацију
Након креирања ЛУН-ова на систему за складиштење, који ће у овом тренутку бити примарни, конфигуришемо правило репликације ЛУН1 на систему складиштења 1 на ЛУН1Р на систему складиштења 2.
Подешавање се врши у менију „Удаљена репликација“.
Хајде да направимо правило. Да бисте то урадили, потребно је да наведете примаоца реплике. Ту такође постављамо име везе и тип репликације (синхрона или асинхрона).
У поље „удаљени системи“ додајемо наш систем складиштења2. Да бисте додали, потребно је да користите управљачке ИП системе за складиштење (МГР) и име удаљеног ЛУН-а у који ћемо извршити репликацију (у нашем случају ЛУН1Р). Контролне ИП адресе су потребне само у фази додавања везе; саобраћај репликације се неће преносити преко њих, већ ће се за то користити претходно конфигурисани ВИП.
Већ у овој фази можемо додати више од једног удаљеног система за топологију „један према више“: кликните на дугме „додај чвор“, као на слици испод.
У нашем случају постоји само један удаљени систем, па се ограничавамо на ово.
Правило је спремно. Имајте на уму да се аутоматски додаје свим учесницима репликације (у нашем случају их има два). Можете креирати онолико таквих правила колико желите, за било који број ЛУН-ова иу било ком правцу. На пример, да бисмо уравнотежили оптерећење, можемо реплицирати део ЛУН-ова из система за складиштење 1 у систем складиштења 2, а други део, напротив, из система за складиштење 2 у систем складиштења 1.
Систем за складиштење 1. Одмах по креирању почела је синхронизација.
Систем за складиштење2. Видимо исто правило, али синхронизација је већ завршена.
ЛУН1 на систему складиштења 1 је у примарној улози, односно активан је. ЛУН1Р на систему за складиштење 2 је у улози секундарног, односно у стању приправности у случају квара система за складиштење 1.
Сада можемо да повежемо наш ЛУН са хостом.
Повезиваћемо се преко иСЦСИ-а, мада се то може урадити и преко ФЦ-а. Постављање мапирања преко иСЦСИ ЛУН-а у реплици се практично не разликује од уобичајеног сценарија, тако да ово овде нећемо детаљно разматрати. Ако ништа друго, овај процес је описан у чланку „'.
Једина разлика је у томе што креирамо мапирање у менију „Мапирање репликације“.
Поставили смо мапирање и дали ЛУН домаћину. Домаћин је видео ЛУН.
Форматирамо га у локални систем датотека.
То је то, подешавање је завршено. Следећи ће бити тестови.
Тестирање
Ми ћемо тестирати три главна сценарија.
- Редовна промена улога Секундарни > Примарни. Редовно мењање улога је потребно у случају да, на пример, треба да извршимо неке превентивне операције у главном дата центру и за то време, да би подаци били доступни, пребацимо оптерећење на резервни дата центар.
- Промена улоге у хитним случајевима Секундарни > Примарни (отказ центра података). Ово је главни сценарио за који постоји репликација, која може помоћи да се преживи потпуни отказ центра података без заустављања компаније на дужи период.
- Распад комуникационих канала између центара података. Провера исправног понашања два система за складиштење података у условима када је из неког разлога комуникациони канал између дата центара недоступан (на пример, багер је копао на погрешном месту и разбио тамну оптику).
Прво, почећемо да пишемо податке у наш ЛУН (писање датотека са насумичним подацима). Одмах видимо да се користи комуникациони канал између система за складиштење података. Ово је лако разумети ако отворите праћење оптерећења портова који су одговорни за репликацију.
Оба система за складиштење сада имају „корисне“ податке, можемо започети тест.
За сваки случај, погледајмо хеш суме једне од датотека и запишемо их.
Редовна замена улога
Операција замене улога (промена смера репликације) се може обавити са било којим системом за складиштење, али ћете и даље морати да одете на оба, пошто ћете морати да онемогућите мапирање на примарном и омогућите га на секундарном (који ће постати примарни ).
Можда се сада поставља разумно питање: зашто ово не аутоматизовати? Одговор је: једноставно је, репликација је једноставно средство отпорности на катастрофе, засновано искључиво на ручним операцијама. За аутоматизацију ових операција постоји метрокластер режим, потпуно је аутоматизован, али је његова конфигурација много компликованија. О постављању метрокластера ћемо писати у следећем чланку.
На главном систему складиштења онемогућавамо мапирање како бисмо осигурали да се снимање заустави.
Затим на једном од система за складиштење (није важно, на главном или резервном) у менију „Удаљена репликација“ изаберите нашу везу РЕПЛ1 и кликните на „Промени улогу“.
Након неколико секунди, ЛУН1Р (резервни систем складиштења) постаје примарни.
Мапирамо ЛУН1Р са системом складиштења2.
Након овога, наш Е: диск је аутоматски прикључен на хост, само што је овај пут „стигао“ са ЛУН1Р.
За сваки случај, упоредимо хеш суме.
Идентично. Испит положен.
Фаиловер. Грешка дата центра
У овом тренутку, главни систем складиштења након редовног пребацивања је систем складиштења 2 и ЛУН1Р, респективно. Да бисмо емулирали несрећу, искључићемо напајање на оба контролера складиштења2.
Нема више приступа томе.
Хајде да видимо шта се дешава на систему складиштења 1 (резервном тренутно).
Видимо да је примарни ЛУН (ЛУН1Р) недоступан. Порука о грешци се појавила у евиденцији, на табли са информацијама, као иу самом правилу репликације. Сходно томе, подаци са хоста тренутно нису доступни.
Промените улогу ЛУН1 у Примарну.
Радим мапирање са домаћином.
Уверите се да се диск Е појављује на хосту.
Проверавамо хеш.
Све је у реду. Систем за складиштење је успешно преживео пад дата центра који је био активан. Приближно време које смо потрошили на повезивање „преокретања“ репликације и повезивање ЛУН-а из резервног дата центра било је око 3 минута. Јасно је да је у стварној производњи све много компликованије, а поред радњи са системима за складиштење, потребно је извршити још много операција на мрежи, на хостовима, у апликацијама. А у животу ће овај временски период бити много дужи.
Овде бих желео да напишем да је све, тест је успешно завршен, али да не журимо. Главни систем за складиштење „лежи“, знамо да је када је „пао“ био у Примарној улози. Шта се дешава ако се изненада укључи? Биће две Примарне улоге, што је једнако корупцији података? Хајде сада да проверимо.
Хајде да одједном укључимо основни систем за складиштење података.
Учитава се неколико минута, а затим се враћа у функцију након кратке синхронизације, али у улози Секундарне.
Све у реду. Раздвајање мозга се није догодило. Размишљали смо о овоме, и увек након пада систем за складиштење се уздиже до улоге Секундарне, без обзира у којој је улози био „током живота“. Сада можемо са сигурношћу рећи да је тест квара дата центра био успешан.
Отказивање комуникационих канала између центара података
Главни задатак овог теста је да се увери да систем за складиштење не почне да се понаша чудно ако привремено изгуби комуникационе канале између два система за складиштење, а затим се поново појави.
Тако. Искључујемо жице између система за складиштење (замислимо да их је ископао багер).
На Примарном видимо да нема везе са Секундаром.
На Секундарни видимо да нема везе са Примарном.
Све функционише добро, а ми настављамо да уписујемо податке у главни систем складиштења, односно гарантовано се разликују од резервног, односно „раздвојили су се“.
За неколико минута „поправљамо“ комуникациони канал. Чим се системи за складиштење виде, синхронизација података се аутоматски активира. Овде се ништа не тражи од администратора.
Након неког времена, синхронизација је завршена.
Веза је обновљена, губитак комуникационих канала није изазвао никакве ванредне ситуације, а након укључивања синхронизација се одвија аутоматски.
Налази
Анализирали смо теорију – шта је потребно и зашто, где су предности, а где мане. Затим смо поставили синхрону репликацију између два система за складиштење.
Затим су спроведени основни тестови за нормално пребацивање, квар дата центра и квар комуникационог канала. У свим случајевима, систем складиштења је добро функционисао. Нема губитка података и административне операције су сведене на минимум за ручни сценарио.
Следећи пут ћемо закомпликовати ситуацију и показати како функционише сва ова логика у аутоматизованом метрокластеру у активно-активном режиму, односно када су оба система складиштења примарна, а понашање у случају кварова система складиштења је потпуно аутоматизовано.
Напишите коментаре, биће нам драго да добијемо разумне критике и практичне савете.
До идућег пута.
Извор: ввв.хабр.цом