AERODISK Engine: Катастрофоустойчивост. Част 1

Здравейте, читатели на хабра! Темата на тази статия ще бъде реализацията на средства за катастрофоустойчивост в системите за съхранение на AERODISK Engine. Първоначално искахме да напишем в една статия за двете средства: репликация и метрокластер, но за съжаление, статията стана твърде голяма, затова я разделихме на две части. Ще започнем от простото до сложното. В тази статия ще настроим и тестваме синхронна репликация – ще унищожим един ЦОД и ще прекъснем връзката между ЦОД-овете и ще видим какво ще се случи.

Нашите клиенти често задават различни въпроси за репликацията, затова преди да преминем към настройка и тестване на репликите, малко ще разкажем какво е репликация в СХД.

Няколко теории

Репликация в СХД – това е постоянен процес на осигуряване на идентичност на данните едновременно на няколко СХД. Технически репликацията се изпълнява по два метода.

Синхронна репликация – това е копиране на данни от основната СХД на резервната с последващо задължително потвърждение от двете СХД, че данните са записани и потвърдени. Именно след потвърждението от двете страни (от двете СХД) данните се считат за записани и могат да се използват. Така се осигурява гарантирана идентичност на данните на всички СХД, участвали в репликата.

Плюсове на този метод:

• Данните винаги са идентични на всички СХД

Минуси:

• Висока цена на решението (бързи комуникационни канали, скъпо оптично влакно, дълговълнови трансивери и т.н.)
• Ограничения по разстояние (в рамките на десетки километри)
• Няма защита от логическо повреждане на данни (ако данните бъдат повредени (съзнателно или случайно) на основната СХД, те автоматично и моментално ще станат повредени и на резервната, тъй като данните винаги са идентични (такъв е парадоксът))

Асионна репликация – това също е копиране на данни от основната СХД на резервната, но с определена закъснение и без необходимост от потвърждение за запис на другата страна. С данните може да се работи веднага след записа на основната СХД, а на резервната СХД данните ще бъдат достъпни след известно време. Идентичността на данните в този случай, разбира се, не е осигурена. Данните на резервната СХД винаги са леко "в миналото".

Предимства на асинхронната репликация:

• Ниска цена на решението (всякакви комуникационни канали, оптичната комуникация е по избор)
• Няма ограничения по разстояние
• Данните на резервната СХД не се повреждат, ако основната СХД е повредена (поне за известно време); ако данните са вече повредени, винаги можете да спрете репликата, за да предотвратите повреждането на данните на резервната СХД

Минуси:

• Данните в различни ЦОД винаги са различни

Следователно, изборът на режим на репликация зависи от бизнес задачите. Ако е критично важно резервната ЦОД да съдържа абсолютно същите данни като основната (т.е. изискването на бизнеса за RPO=0), ще трябва да сте готови да платите и да се примирите с ограниченията на синхронната реплика. А ако закъснението в състоянието на данните е допустимо или просто нямате средства, то определено трябва да използвате асинхронния метод.

Отделно ще разгледаме такъв режим (по-точно, топология) като метрокластер. В режим на метрокластер се използва синхронна репликация, но, за разлика от обичайната реплика, метрокластерът позволява на двете СХД да работят в активен режим. Т.е. няма разделение на активен и резервен ЦОД. Приложенията работят едновременно с две СХД, които физически се намират в различни ЦОД. Всеки даунтайм при аварии в такава топология е много малък (RTO обикновено е в минути). В тази статия няма да разглеждаме нашата реализация на метрокластера, тъй като това е много обширна и сложна тема, на която ще посветим отделна, следваща статия.

Също така, много често, когато говорим за репликация с помощта на СХД, мнозина задават основателния въпрос: > „Много приложения имат свои средства за репликация, защо да използваме репликация на СХД? По-добре ли е или по-лошо?“

Тук няма еднозначен отговор, затова ще приведем аргументи ЗА и ПРОТИВ:

Аргументи ЗА репликацията на СХД:

• Простота на решението. С едно средство можете да реплицирате целия масив от данни, независимо от типа натоварване и приложения. Ако използвате реплика от приложения, ще трябва да настроите всяко приложение поотделно. Ако са повече от 2, това е изключително трудоемко и скъпо (репликацията на приложения обикновено изисква отделна и не безплатна лицензия за всяко приложение. Но за това по-късно).
• Можете да репликирате всичко – всякакви приложения, всякакви данни – и те винаги ще бъдат последователни. Много (повечето) приложения нямат средства за репликация, а репликите от СХД са единственият начин да осигурите защита от бедствия.
• Не е нужно да плащате излишно за функционалността на репликация на приложения. Обикновено, тя не е евтина, както и лицензите за репликации на СХД. Но лицензът за репликация на СХД се плаща само веднъж, а лицензът за репликация на приложения трябва да се купува за всяко приложение поотделно. Ако имате много от тези приложения, цената на лицензиите за репликация на приложения става значителна, а разходите за лицензиите за репликация на СХД остават малка част от общото.

Аргументи ПРОТИВ репликацията на СХД:

• Репликацията чрез приложения предлага повече функционалности от гледна точка на самите приложения, тъй като приложението по-добре познава своите данни (което е очевидно), следователно има повече възможности за работа с тях.
• Някои производители на приложения не гарантират последователността на данните си, ако репликацията се извършва с помощта на външни средства. *

*- спорен тезис. Например, известна компания производител на СУБД много дълго време официално твърдеше, че тяхната СУБД може да се репликира нормално само с техните средства, а всяка друга репликация (включително също и от СХД) «не е истинска». Но животът показа, че това не е така. По всичко изглежда, (но това не е сигурно) че това просто не е съвсем честна опит да се продадат още лицензи на клиентите.

В крайна сметка, в повечето случаи репликацията от СХД е по-добра, тъй като е по-прост и по-евтин вариант, но има сложни случаи, когато е необходим специфичен функционал на приложенията и е нужно да работите именно с репликация на ниво приложения.

С теорията приключихме, сега преминаваме към практиката.

Ще настроим репликацията в нашата лаборатория. В лабораторни условия емулирахме два ЦОД-а (всъщност, две близко разположени стойки, които приличат на стоящи в различни сгради). Стендът се състои от две СХД 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. С DDP аналогично.

Има още много малки особености, но няма особено значение да ги изреждаме, ще ги споменаваме по време на настройването.

Настройка на репликацията

Процесът на настройка е достатъчно прост и се състои от три етапа.

1. Настройка на мрежата
2. Настройка на хранилището
3. Настройка на правилата (връзките) и мапинга

Важно при настройката на репликацията е, че първите два етапа трябва да се повторят на отдалечената СХД, третият стадий – само на основната.

Настройка на мрежовите ресурси

Първо трябва да настроим мрежовите портове, през които ще тече трафикът на репликация. За целта портовете трябва да бъдат активирани и зададени на 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.

Вече на този етап можем да добавим повече от една отдалечена система за топологията „едно към много“: натискаме бутона „добави възел“, както е показано на изображението по-долу.

В нашия случай отдалечената система е една, така че се ограничаваме до нея.

Правилото е готово. Обърнете внимание, че то се добавя автоматично на всички участници в репликацията (в нашия случай те са двама). Можем да създадем колкото се може повече такива правила за всяко количество LUN-ове и в двете посоки. Например, можем за балансировка на натоварването част от LUN-овете да репликираме от СХД1 на СХД2, а другата част обратно – от СХД2 на СХД1.

СХД1. Веднага след създаването започна синхронизация.

СХД2. Виждаме същото правило, но синхронизацията вече е завършила.

LUN1 на СХД1 е в роля Primary, тоест той е активен. LUN1R на СХД2 е в роля Secondary, тоест той е подготвен в случай на отказ на СХД1.
Сега можем да свържем нашия LUN към хоста.

Ще направим свързването по iSCSI, въпреки че може да се направи и по FC. Настройването на мапинга по iSCSI LUN-а в репликата практически не се различава от обичайния сценарий, така че няма да разглеждаме това подробно тук. Ако е необходимо, този процес е описан в статията «Бърза настройка».

Единственото отличие – мапингът го създаваме в меню „Мапинг на репликацията“.

Настроихме мапинга, предоставихме LUN на хоста. Хостът видя LUN.

Форматираме го в локалната файлова система.

Всичко, с това настройката е завършена. Следват тестовете.

Тестиране

Ще тестваме три основни сценария.

1. Нормално превключване на ролите Secondary > Primary. Нормалното превключване на ролите е нужно в случай, че, например, в основния ЦОД ни е необходимо да извършим профилактика и през това време, за да бъдат данните достъпни, прехвърляме натоварването в резервния ЦОД.
2. Аварийно превключване на роли Secondary > Primary (повреда на ЦОД). Това е основният сценарий, за който съществува репликацията, която може да помогне за оцеляване при пълен отказ на ЦОД, без да спира работата на компанията за продължителен период.
3. Прекъсване на комуникационните канали между ЦОД-ите. Проверка на коректното поведение на двете СХД в условия, когато по някаква причина комуникационният канал между ЦОД-ите не е наличен (например, ако багер е изровил не там и е прекъснал тъмната оптика).

За начало ще започнем да записваме данни на нашия 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