Здраво, читаоци Хабра! У прошлом чланку смо говорили о једноставном средству за опоравак од катастрофе у системима за складиштење АЕРОДИСК ЕНГИНЕ - репликација. У овом чланку ћемо заронити у сложенију и занимљивију тему – метрокластер, односно средство аутоматизоване заштите од катастрофе за два дата центра, омогућавајући дата центрима да раде у активно-активном режиму. Рећи ћемо вам, показати, покварити и поправити.
Као и обично, прво теорија
Метрокластер је кластер распрострањен на неколико локација у граду или региону. Реч „кластер” нам јасно наговештава да је комплекс аутоматизован, односно да се пребацивање чворова кластера у случају кварова дешава аутоматски.
Ту лежи главна разлика између метрокластера и регуларне репликације. Аутоматизација операција. То јест, у случају одређених инцидената (квар центра података, покварени канали, итд.), систем за складиштење ће самостално извршити неопходне радње како би одржао доступност података. Када користите обичне реплике, ове радње у потпуности или делимично обавља администратор.
Шта он ради?
Главни циљ који корисници теже када користе одређене имплементације метрокластера је да минимизирају РТО (Рецовери Тиме Објецтиве). Односно, да се минимизира време опоравка ИТ услуга након квара. Ако користите редовну репликацију, време опоравка ће увек бити дуже од времена опоравка код метрокластера. Зашто? Врло једноставна. Администратор мора бити за својим столом и ручно пребацити репликацију, а метрокластер то ради аутоматски.
Ако немате дежурног наменског администратора који не спава, не једе, не пуши, не разболи се и 24 сата дневно прати стање система за складиштење, онда нема начина да гарантујете да ће администратор бити доступан за ручно пребацивање током квара.
Сходно томе, РТО у одсуству метрокластера или бесмртног администратора 99. нивоа дежурне службе администратора биће једнак збиру времена укључивања свих система и максималног временског периода након којег администратор гарантује да ће почети са радом. са системима за складиштење и сродним системима.
Дакле, долазимо до очигледног закључка да метрокластер треба користити ако је захтев за РТО минути, а не сати или дани, односно када у случају најгорег квара дата центра ИТ одељење мора да обезбеди пословању време да вратите приступ ИТ услугама у року од неколико минута или чак секунди.
Како то функционише?
На нижем нивоу, метрокластер користи механизам за синхрону репликацију података, који смо описали у претходном чланку (види. ). Пошто је репликација синхрона, захтеви за њу су одговарајући, тачније:
- оптичко влакно као физика, 10 гигабитни Етхернет (или више);
- удаљеност између центара података није већа од 40 километара;
- Кашњење оптичког канала између центара података (између система за складиштење) је до 5 милисекунди (оптимално 2).
Сви ови захтеви су саветодавне природе, односно метрокластер ће радити и ако ови захтеви нису испуњени, али морамо разумети да су последице непоштовања ових захтева једнаке успоравању рада оба система складиштења у метрокластера.
Дакле, синхрона реплика се користи за пренос података између система за складиштење, а како се реплике аутоматски пребацују и, што је најважније, како избећи подељени мозак? Да би се то урадило, на вишем нивоу, користи се додатни ентитет - арбитар.
Како ради арбитар и који је његов задатак?
Арбитар је мала виртуелна машина или хардверски кластер који се мора покренути на трећем месту (на пример, у канцеларији) и обезбедити приступ систему за складиштење преко ИЦМП-а и ССХ-а. Након покретања, арбитар треба да подеси ИП, а затим са стране складишта наведе његову адресу, плус адресе даљинских управљача који учествују у метрокластеру. Након овога, судија је спреман за рад.
Арбитар стално прати све системе складиштења у метрокластеру и ако је одређени систем складиштења недоступан, након потврде недоступности од другог члана кластера (један од „живих” система за складиштење), одлучује да покрене процедуру за пребацивање правила репликације. и мапирање.
Веома важна тачка. Арбитар мора увек бити лоциран на месту различитом од оних на којима се налазе системи за складиштење података, односно ни у дата центру 1, где је инсталиран систем за складиштење података 1, нити у центру података 2, где је инсталиран систем за складиштење података 2.
Зашто? Јер то је једини начин на који арбитар, уз помоћ једног од преживелих система за складиштење података, може недвосмислено и тачно утврдити пад било које од две локације на којима су системи за складиштење инсталирани. Било који други начин постављања арбитра може довести до поделе мозга.
Хајде сада да заронимо у детаље рада арбитра.
Арбитар покреће неколико сервиса који стално испитују све контролере складишта. Ако се резултат анкете разликује од претходног (доступан/недоступан), онда се евидентира у малој бази података, која такође ради на арбитру.
Погледајмо детаљније логику рада арбитра.
Корак 1: Утврдите недоступност. Догађај квара система за складиштење је одсуство пинга од оба контролера истог система за складиштење у року од 5 секунди.
Корак 2. Покрените процедуру пребацивања. Након што арбитар схвати да је један од система за складиштење недоступан, он шаље захтев „живом” систему складиштења како би се уверио да је „мртви” систем за складиштење заиста мртав.
Након што добије такву команду од арбитра, други (живи) систем складиштења додатно проверава доступност палог првог складишног система и, ако га нема, шаље потврду арбитру своје претпоставке. Систем за складиштење је заиста недоступан.
Након што добије такву потврду, арбитар покреће удаљену процедуру за пребацивање репликације и подизање мапирања на оне реплике које су биле активне (примарне) на палом систему складиштења и шаље команду другом систему складиштења да промени ове реплике из секундарних у примарни и подизање мапирања. Па, други систем складиштења, сходно томе, обавља ове процедуре, а затим обезбеђује приступ изгубљеним ЛУН-овима из себе.
Зашто је потребна додатна верификација? За кворум. То јест, већина од укупног непарног (3) броја чланова кластера мора потврдити пад једног од чворова кластера. Тек тада ће ова одлука бити дефинитивно исправна. Ово је неопходно како би се избегло погрешно пребацивање и, сходно томе, подељени мозак.
Временски корак 2 траје отприлике 5 - 10 секунди, тако да, узимајући у обзир време потребно за утврђивање недоступности (5 секунди), у року од 10 - 15 секунди након несреће, ЛУН-ови из палог система складиштења ће аутоматски бити доступни за рад са уживо систем складиштења.
Јасно је да да бисте избегли губитак везе са хостовима, такође морате да водите рачуна о правилном конфигурисању тајмаута на хостовима. Препоручено временско ограничење је најмање 30 секунди. Ово ће спречити хост да прекине везу са системом за складиштење током промене оптерећења у случају катастрофе и може обезбедити да нема И/О прекида.
Чекај мало, испоставиће се да ако је све тако добро са метрокластером, зашто нам је уопште потребна редовна репликација?
У стварности, све није тако једноставно.
Хајде да размотримо предности и недостатке метрокластера
Дакле, схватили смо да су очигледне предности метрокластера у поређењу са конвенционалном репликацијом:
- Потпуна аутоматизација, обезбеђујући минимално време опоравка у случају катастрофе;
- То је све :-).
А сада, пажња, недостаци:
- Цена решења. Иако метрокластер у Аеродиск системима не захтева додатно лиценцирање (користи се иста лиценца као и за реплику), цена решења ће и даље бити већа од коришћења синхроне репликације. Мораћете да примените све захтеве за синхрону реплику, плус захтеве за метрокластер повезане са додатним пребацивањем и додатним сајтом (погледајте планирање метрокластера);
- Сложеност решења. Метрокластер је много сложенији од обичне реплике и захтева много више пажње и труда за планирање, конфигурацију и документацију.
Коначно. Метроцлустер је свакако веома технолошки напредно и добро решење када заиста треба да обезбедите РТО за неколико секунди или минута. Али ако нема тог задатка, а РТО у сатима је ОК за посао, онда нема сврхе гађати врапце из топа. Довољна је уобичајена радничка-сељачка репликација, јер ће метро кластер проузроковати додатне трошкове и компликацију ИТ инфраструктуре.
Планирање метрокластера
Овај одељак не тврди да је свеобухватан водич за пројектовање метрокластера, већ само показује главне правце које треба разрадити ако одлучите да изградите такав систем. Стога, када стварно имплементирате метрокластер, обавезно укључите произвођача система за складиштење (то јест, нас) и друге сродне системе за консултације.
Игралишта
Као што је горе наведено, метрокластер захтева најмање три локације. Два дата центра у којима ће функционисати системи за складиштење података и повезани системи, као и трећа локација на којој ће радити арбитар.
Препоручена удаљеност између дата центара није већа од 40 километара. Већа удаљеност ће вероватно изазвати додатна кашњења, која су у случају метрокластера изузетно непожељна. Подсетимо, кашњења би требало да буду до 5 милисекунди, мада је препоручљиво да их држите унутар 2.
Препоручује се да проверите кашњења и током процеса планирања. Сваки мање или више зрео провајдер који обезбеђује оптичко влакно између центара података може прилично брзо да организује проверу квалитета.
Што се тиче кашњења пред арбитром (односно између трећег сајта и прва два), препоручени праг кашњења је до 200 милисекунди, односно прикладна је редовна корпоративна ВПН веза преко Интернета.
Пребацивање и умрежавање
За разлику од шеме репликације, где је довољно повезати системе за складиштење са различитих локација, шема метрокластера захтева повезивање хостова са оба система складиштења на различитим локацијама. Да би било јасније у чему је разлика, обе шеме су приказане у наставку.
Као што се може видети из дијаграма, домаћини нашег сајта 1 посматрају и систем складиштења 1 и систем складиштења 2. Такође, напротив, хостови сајта 2 гледају и систем за складиштење 2 и систем складиштења 1. То јест, сваки домаћин види оба система складиштења. Ово је предуслов за рад метрокластера.
Наравно, нема потребе да повезујете сваки хост оптичким каблом са другим центром података; никакви портови или каблови неће бити довољни. Све ове везе морају бити направљене преко Етхернет 10Г+ или ФибреЦханнел 8Г+ прекидача (ФЦ је само за повезивање домаћина и система складиштења за ИО, канал за репликацију је тренутно доступан само преко ИП-а (Етхернет 10Г+).
Сада неколико речи о топологији мреже. Важна тачка је исправна конфигурација подмрежа. Потребно је одмах дефинисати неколико подмрежа за следеће врсте саобраћаја:
- Подмрежа за репликацију преко које ће подаци бити синхронизовани између система за складиштење. Може их бити неколико, у овом случају није битно, све зависи од тренутне (већ имплементиране) топологије мреже. Ако их има два, онда очигледно рутирање мора бити конфигурисано између њих;
- Подмреже за складиштење преко којих ће хостови приступати ресурсима за складиштење (ако је иСЦСИ). У сваком центру података треба да постоји једна таква подмрежа;
- Контролне подмреже, односно три рутабилне подмреже на три локације са којих се управља системима за складиштење података, а ту се налази и арбитар.
Овде не разматрамо подмреже за приступ ресурсима хоста, пошто оне у великој мери зависе од задатака.
Раздвајање различитог саобраћаја у различите подмреже је изузетно важно (посебно је важно одвојити реплику од И/О), јер ако помешате сав саобраћај у једну „дебелу“ подмрежу, тада ће овим саобраћајем бити немогуће управљати, а у услови два дата центра то и даље може изазвати различите опције сукоба мреже. Нећемо се дубоко упуштати у ово питање у оквиру овог чланка, јер о планирању мреже која се протеже између центара података можете прочитати на ресурсима произвођача мрежне опреме, где је то врло детаљно описано.
Конфигурација арбитра
Арбитар мора да обезбеди приступ свим управљачким интерфејсима система за складиштење преко ИЦМП и ССХ протокола. Такође треба размишљати о сигурности арбитра. Овде постоји нијанса.
Арбитер фаиловер је веома пожељан, али није обавезан. Шта се дешава ако се судија сруши у погрешно време?
- Рад метрокластера у нормалном режиму неће се променити, јер арбтир апсолутно нема утицаја на рад метрокластера у нормалном режиму (његов задатак је да благовремено пребаци оптерећење између центара података)
- Штавише, ако арбитар из овог или оног разлога падне и „преспава“ несрећу у дата центру, онда неће доћи до пребацивања, јер неће имати ко да даје потребне команде за пребацивање и организује кворум. У овом случају, метрокластер ће се претворити у редовну шему са репликацијом, која ће се морати ручно пребацити током катастрофе, што ће утицати на РТО.
Шта из овога следи? Ако заиста треба да обезбедите минимални РТО, морате да се уверите да је арбитар толерантан на грешке. За ово постоје две опције:
- Покрените виртуелну машину са арбитром на хипервизору отпорном на грешке, на срећу сви хипервизори за одрасле подржавају толеранцију грешака;
- Ако сте на трећем месту (у конвенционалној канцеларији) превише лењи да инсталирате нормалан кластер и не постоји кластер хипервозора, онда смо обезбедили хардверску верзију арбитра, која је направљена у кутији од 2У у којој су два обична к-86 сервери раде и који могу да преживе локални квар.
Топло препоручујемо да се обезбеди толеранција грешака арбитра, упркос чињеници да метрокластеру није потребна у нормалном режиму. Али као што показују и теорија и пракса, ако изградите заиста поуздану инфраструктуру отпорну на катастрофе, онда је боље играти на сигурно. Боље је да заштитите себе и своје пословање од „закона подлости“, односно од пропуста и арбитра и једне од локација на којима се налази систем за складиштење.
Арһитектура решења
Узимајући у обзир горе наведене захтеве, добијамо следећу општу архитектуру решења.
ЛУН-ови треба да буду равномерно распоређени на две локације да би се избегло озбиљно преоптерећење. Истовремено, приликом димензионисања у оба дата центра, требало би да укључите не само дупли волумен (који је неопходан за истовремено складиштење података на два система за складиштење), већ и двоструке перформансе у ИОПС и МБ/с како бисте спречили деградацију апликације у случај квара једног од дата центара.ов.
Посебно напомињемо да уз правилан приступ димензионисању (односно, под условом да смо обезбедили одговарајуће горње границе ИОПС и МБ/с, као и неопходне ЦПУ и РАМ ресурсе), ако један од система за складиштење података у метро кластер не успе, неће доћи до озбиљног пада перформанси под условима привременог рада на једном систему складиштења.
Ово се објашњава чињеницом да када две локације раде истовремено, синхрона репликација „једе“ половину перформанси писања, пошто свака трансакција мора бити уписана у два система за складиштење (слично РАИД-1/10). Дакле, ако један од система за складиштење поквари, утицај репликације привремено (док се неуспели систем складиштења не опорави) нестаје и добијамо двоструко повећање перформанси писања. Након што се ЛУН-ови неисправног система за складиштење поново покрену на радном систему за складиштење података, ово двоструко повећање нестаје због чињенице да се оптерећење појављује са ЛУН-ова другог система за складиштење и враћамо се на исти ниво перформанси који смо имали пре „пада“, али само у оквиру једног сајта.
Уз помоћ компетентног димензионисања можете осигурати услове под којима корисници уопште неће осетити квар читавог система складиштења. Али још једном понављамо, ово захтева веома пажљиво димензионисање, за које, иначе, можете нас контактирати бесплатно :-).
Постављање метрокластера
Постављање метрокластера је веома слично постављању редовне репликације, коју смо описали у . Зато, хајде да се фокусирамо само на разлике. Поставили смо клупу у лабораторији засновану на архитектури изнад, само у минималној верзији: два система за складиштење података повезана преко 10Г Етхернета, два 10Г прекидача и један хост који гледа кроз прекидаче на оба система за складиштење података са 10Г портовима. Арбитар ради на виртуелној машини.
Када конфигуришете виртуелне ИП адресе (ВИП) за реплику, требало би да изаберете ВИП тип - за метрокластер.
Направили смо две везе за репликацију за два ЛУН-а и дистрибуирали их у два система складиштења: ЛУН ТЕСТ Примарни на систему за складиштење 1 (МЕТРО веза), ЛУН ТЕСТ2 Примарни за систем складиштења 2 (МЕТРО2 веза).
За њих смо конфигурисали два идентична циља (у нашем случају иСЦСИ, али је подржан и ФЦ, логика подешавања је иста).
Систем за складиштење 1:
Систем за складиштење 2:
За везе за репликацију, мапирања су направљена на сваком систему за складиштење.
Систем за складиштење 1:
Систем за складиштење 2:
Поставили смо вишеструки пут и представили га домаћину.
Постављање арбитра
Не морате ништа посебно да радите са самим арбитром; само га морате омогућити на трећем сајту, дати му ИП и конфигурисати приступ преко ИЦМП-а и ССХ-а. Само подешавање се врши из самих система за складиштење. У овом случају, довољно је једном конфигурисати арбитар на било ком од меморијских контролера у метрокластеру; ова подешавања ће се аутоматски дистрибуирати свим контролерима.
У одељку Удаљена репликација>> Метроцлустер (на било ком контролеру)>> дугме „Конфигуриши”.
Уносимо ИП арбитра, као и контролне интерфејсе два даљинска контролера складиштења.
Након тога, потребно је да омогућите све услуге (дугме „Поново покрени све“). Ако се у будућности поново конфигуришу, услуге се морају поново покренути да би подешавања ступила на снагу.
Проверавамо да ли све услуге раде.
Ово завршава подешавање метрокластера.
Црасх тест
Тест црасх теста у нашем случају ће бити прилично једноставан и брз, пошто је функционалност репликације (пребацивање, конзистентност, итд.) разматрана у . Због тога је за тестирање поузданости метрокластера довољно да проверимо аутоматизацију откривања кварова, пребацивања и одсуства губитака при снимању (И/О заустављања).
Да бисмо то урадили, емулирамо потпуни отказ једног од система за складиштење тако што ћемо физички искључити оба његова контролера, након што смо прво започели копирање велике датотеке на ЛУН, која мора бити активирана на другом систему за складиштење.
Онемогућите један систем складиштења. На другом систему складиштења видимо упозорења и поруке у логовима да је веза са суседним системом изгубљена. Ако су обавештења преко СМТП или СНМП надзора конфигурисана, администратор ће примати одговарајућа обавештења.
Тачно 10 секунди касније (видљиво на оба снимка екрана), МЕТРО веза за репликацију (она која је била примарна на неуспелом систему за складиштење) аутоматски је постала примарна на радном систему за складиштење. Користећи постојеће мапирање, ЛУН ТЕСТ је остао доступан домаћину, снимање је мало пало (унутар обећаних 10 процената), али није прекинуто.
Тест је успешно завршен.
Сумирање
Тренутна имплементација метрокластера у системе за складиштење АЕРОДИСК Енгине Н-серије у потпуности омогућава решавање проблема где је потребно елиминисати или минимизирати застоје ИТ услуга и обезбедити њихов рад 24/7/365 уз минималне трошкове рада.
Можемо рећи, наравно, да је све ово теорија, идеални лабораторијски услови и тако даље... АЛИ имамо низ реализованих пројеката у којима смо имплементирали функционалност отпорности на катастрофе, а системи раде савршено. Један од наших прилично познатих купаца, који користи само два система за складиштење података у конфигурацији отпорној на катастрофе, већ је пристао да објави информације о пројекту, па ћемо у наредном делу говорити о борбеној имплементацији.
Хвала вам, радујемо се продуктивној дискусији.
Извор: ввв.хабр.цом