Здравейте, читатели на Хабр! Темата на тази статия ще бъде внедряването на инструменти за възстановяване след бедствие в системи за съхранение на AERODISK Engine. Първоначално искахме да напишем в една статия за двата инструмента: репликация и metrocluster, но, за съжаление, статията се оказа твърде дълга, така че я разделихме на две части. Нека преминем от просто към сложно. В тази статия ще настроим и тестваме синхронна репликация - ще премахнем един център за данни, а също така ще прекъснем комуникационния канал между центровете за данни и ще видим какво ще се случи.
Нашите клиенти често ни задават различни въпроси относно репликацията, така че преди да преминем към настройката и тестването на внедряването на реплики, ще ви разкажем малко за това какво представлява репликацията в хранилището.
Малко теория
Репликацията в системите за съхранение е непрекъснат процес на осигуряване на идентичност на данните в няколко системи за съхранение едновременно. Технически, репликацията се осъществява по два начина.
Синхронна репликация – това е копиране на данни от основната система за съхранение в резервната, последвано от задължително потвърждение от двете системи за съхранение, че данните са записани и потвърдени. След потвърждение от двете страни (и двете системи за съхранение), данните се считат за записани и с тях може да се работи. Това гарантира гарантирана идентичност на данните на всички системи за съхранение, участващи в репликата.
Предимствата на този метод:
- Данните винаги са идентични на всички системи за съхранение
против:
- Висока цена на решението (бързи комуникационни канали, скъпи оптични влакна, дълговълнови приемо-предаватели и др.)
- Ограничения за разстояние (в рамките на няколко десетки километра)
- Няма защита срещу повреда на логически данни (ако данните са повредени (умишлено или случайно) в основната система за съхранение, те автоматично и незабавно ще се повредят в резервната, тъй като данните винаги са идентични (това е парадоксът)
Асинхронна репликация – това също е копиране на данни от основната система за съхранение в резервната, но с известно забавяне и без необходимост от потвърждаване на записа от другата страна. Можете да работите с данни веднага след записването им в основната система за съхранение, а в резервната система за съхранение данните ще бъдат достъпни след известно време. Идентичността на данните в този случай, разбира се, изобщо не е гарантирана. Данните в системата за резервно съхранение винаги са малко „в миналото“.
Плюсове на асинхронната репликация:
- Евтино решение (всякакви комуникационни канали, оптика по избор)
- Без ограничения на разстоянието
- В резервната система за съхранение данните не се влошават, ако са повредени в основната (поне за известно време); ако данните се повредят, винаги можете да спрете репликата, за да предотвратите повреда на данните в резервната система за съхранение
против:
- Данните в различните центрове за данни винаги не са идентични
По този начин изборът на режим на репликация зависи от бизнес целите. Ако за вас е критично резервният център за данни да съдържа точно същите данни като основния център за данни (т.е. бизнес изискване за RPO = 0), тогава ще трябва да отделите парите и да се примирите с ограниченията на синхронен реплика. И ако забавянето на състоянието на данните е приемливо или просто няма пари, тогава определено трябва да използвате асинхронния метод.
Нека отделно подчертаем такъв режим (по-точно топология) като метрокластър. В режим metrocluster се използва синхронна репликация, но за разлика от обикновената реплика metrocluster позволява и на двете системи за съхранение да работят в активен режим. Тези. нямате разделение между активни и резервни центрове за данни. Приложенията работят едновременно с две системи за съхранение, които са физически разположени в различни центрове за данни. Прекъсванията по време на аварии в такава топология са много малки (RTO, обикновено минути). В тази статия няма да разглеждаме нашата реализация на metrocluster, тъй като това е много голяма и обемна тема, така че ще посветим отделна, следваща статия на нея, в продължение на тази.
Също така, много често, когато говорим за репликация с помощта на системи за съхранение, много хора имат разумен въпрос: > „Много приложения имат свои собствени инструменти за репликация, защо да използват репликация на системи за съхранение? По-добре ли е или по-лошо?
Тук няма ясен отговор, затова ето аргументите ЗА и ПРОТИВ:
Аргументи ЗА репликация за съхранение:
- Простота на решението. С един инструмент можете да копирате целия си набор от данни, независимо от вида на натоварването и приложението. Ако използвате реплика от приложения, ще трябва да конфигурирате всяко приложение отделно. Ако има повече от 2 от тях, тогава това е изключително трудоемко и скъпо (репликацията на приложение обикновено изисква отделен и не безплатен лиценз за всяко приложение. Но повече за това по-долу).
- Можете да копирате всичко - всяко приложение, всякакви данни - и то винаги ще бъде последователно. Много (повечето) приложения нямат възможности за репликация и репликите от системата за съхранение са единственият начин да се осигури защита от бедствия.
- Няма нужда да плащате повече за функционалността за репликация на приложения. По правило не е евтино, точно както лицензите за реплика на система за съхранение. Но трябва да платите за лиценз за репликация за съхранение веднъж, а лиценз за реплика на приложение трябва да бъде закупен за всяко приложение поотделно. Ако има много такива приложения, тогава струва доста пари и цената на лицензите за репликация на съхранение се превръща в капка в кофата.
Аргументи ПРОТИВ репликацията за съхранение:
- Replica чрез приложения има повече функционалност от гледна точка на самите приложения, приложението си знае по-добре данните (очевидно), така че има повече възможности за работа с тях.
- Производителите на някои приложения не гарантират последователността на своите данни, ако репликацията се извършва с помощта на инструменти на трети страни. *
* - спорна теза. Например, известен производител на СУБД официално декларира от много дълго време, че тяхната СУБД може да се репликира нормално само с техните средства, а останалата част от репликацията (включително системите за съхранение) е „невярна“. Но животът показа, че това не е така. Най-вероятно (но това не е сигурно) това просто не е най-честният опит да се продадат повече лицензи на клиентите.
В резултат на това в повечето случаи репликацията от системата за съхранение е по-добра, т.к Това е по-прост и по-евтин вариант, но има сложни случаи, когато е необходима конкретна функционалност на приложението и е необходимо да се работи с репликация на ниво приложение.
Готово с теорията, сега практика
Ние ще конфигурираме репликата в нашата лаборатория. В лабораторни условия емулирахме два центъра за данни (всъщност два съседни стелажа, които сякаш бяха в различни сгради). Стендът се състои от две системи за съхранение на Engine N2, които са свързани помежду си с оптични кабели. Физически сървър, работещ под Windows Server 2016, е свързан към двете системи за съхранение с помощта на 10Gb Ethernet. Стойката е доста проста, но това не променя същността.
Схематично това изглежда така:
Логично репликацията е организирана по следния начин:
Сега нека да разгледаме функционалността за репликация, която имаме сега.
Поддържат се два режима: асинхронен и синхронен. Логично е, че синхронният режим е ограничен от разстояние и комуникационен канал. По-специално, синхронният режим изисква използването на влакна като физика и 10 Gigabit Ethernet (или по-висок).
Поддържаното разстояние за синхронна репликация е 40 километра, стойността на забавяне на оптичния канал между центровете за данни е до 2 милисекунди. По принцип ще работи с големи закъснения, но тогава ще има силни забавяния по време на запис (което също е логично), така че ако планирате синхронна репликация между центровете за данни, трябва да проверите качеството на оптиката и закъсненията.
Изискванията за асинхронна репликация не са толкова сериозни. По-точно ги няма изобщо. Всяка работеща Ethernet връзка ще свърши работа.
Понастоящем системата за съхранение на AERODISK ENGINE поддържа репликация за блокови устройства (LUN) чрез Ethernet протокола (по медна връзка или оптично). За проекти, при които се изисква репликация през SAN тъкан през Fibre Channel, в момента добавяме подходящо решение, но то все още не е готово, така че в нашия случай само Ethernet.
Репликацията може да работи между всяка система за съхранение от серия ENGINE (N1, N2, N4) от младши системи до по-стари и обратно.
Функционалността на двата режима на репликация е напълно идентична. По-долу има повече подробности за това какво е налично:
- Репликация „един към един“ или „един към един“, тоест класическата версия с два центъра за данни, основният и резервният
- Репликацията е „едно към много“ или „едно към много“, т.е. един LUN може да бъде репликиран към няколко системи за съхранение наведнъж
- Активиране, деактивиране и „обратно“ репликиране, съответно, за активиране, деактивиране или промяна на посоката на репликация
- Репликацията е достъпна както за RDG (Raid Distributed Group), така и за DDP (Dynamic Disk Pool) пулове. Въпреки това, LUN на RDG пул могат да бъдат копирани само към друг RDG. Същото с DDP.
Има още много малки функции, но няма особен смисъл да ги изброяваме; ще ги споменем, докато настройваме.
Настройка на репликация
Процесът на настройка е доста прост и се състои от три етапа.
- Конфигурация на мрежата
- Настройка на съхранението
- Настройка на правила (връзки) и картографиране
Важен момент при настройката на репликацията е, че първите два етапа трябва да се повторят на отдалечената система за съхранение, третият етап - само на основната.
Настройка на мрежови ресурси
Първата стъпка е да конфигурирате мрежовите портове, през които ще се предава трафикът на репликация. За да направите това, трябва да активирате портовете и да зададете техните IP адреси в секцията Front-end адаптери.
След това трябва да създадем пул (в нашия случай RDG) и виртуален IP за репликация (VIP). VIP е плаващ IP адрес, който е свързан с два „физически“ адреса на контролери за съхранение (портовете, които току-що конфигурирахме). Това ще бъде основният интерфейс за репликация. Можете също така да работите не с VIP, а с VLAN, ако трябва да работите с маркиран трафик.
Процесът на създаване на VIP за реплика не се различава много от създаването на VIP за I/O (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 на системата за съхранение, която ще бъде основната в момента, ние конфигурираме правилото за репликация LUN1 на система за съхранение 1 към LUN1R на система за съхранение 2.
Настройката се извършва в меню „Отдалечена репликация”.
Нека създадем правило. За да направите това, трябва да посочите получателя на репликата. Там също задаваме името на връзката и вида на репликацията (синхронна или асинхронна).
В полето „отдалечени системи“ добавяме нашата система за съхранение2. За да добавите, трябва да използвате системите за съхранение на IP за управление (MGR) и името на отдалечения LUN, в който ще извършим репликация (в нашия случай LUN1R). Контролните IP са необходими само на етапа на добавяне на връзка; трафикът на репликация няма да се предава през тях; за това ще се използва предварително конфигурираният VIP.
Още на този етап можем да добавим повече от една отдалечена система за топологията „един към много“: щракнете върху бутона „добавяне на възел“, както е на фигурата по-долу.
В нашия случай има само една отдалечена система, така че се ограничаваме до това.
Правилото е готово. Моля, обърнете внимание, че той се добавя автоматично към всички участници в репликацията (в нашия случай те са двама). Можете да създадете толкова правила, колкото желаете, за произволен брой LUN и във всяка посока. Например, за да балансираме натоварването, можем да копираме част от LUN от система за съхранение 1 към система за съхранение 2, а другата част, напротив, от система за съхранение 2 към система за съхранение 1.
Система за съхранение1. Веднага след създаването започна синхронизирането.
Система за съхранение2. Виждаме същото правило, но синхронизирането вече е приключило.
LUN1 на система за съхранение 1 е в основната роля, т.е. той е активен. LUN1R на система за съхранение 2 е в ролята на вторичен, т.е. той е в режим на готовност в случай, че системата за съхранение 1 се повреди.
Сега можем да свържем нашия LUN към хоста.
Ще се свържем чрез iSCSI, въпреки че може да стане и през FC. Настройването на картографиране чрез iSCSI LUN в реплика практически не се различава от обичайния сценарий, така че няма да разглеждаме това подробно тук. Ако не друго, този процес е описан в статията „".
Единствената разлика е, че създаваме картографиране в менюто „Картографиране на репликация“.
Настроихме картографиране и дадохме LUN на хоста. Домакинът видя LUN.
Форматираме го в локална файлова система.
Това е всичко, настройката е завършена. Следват тестове.
Тестване
Ще тестваме три основни сценария.
- Редовно превключване на роли Вторичен > Основен. Редовната смяна на ролите е необходима в случай, че например трябва да извършим някои превантивни операции в основния център за данни и през това време, за да са налични данните, прехвърляме товара към резервния център за данни.
- Спешна смяна на ролята Вторичен > Основен (повреда на центъра за данни). Това е основният сценарий, за който съществува репликация, която може да помогне да се преживее пълен срив на центъра за данни, без да спира компанията за продължителен период.
- Прекъсване на комуникационните канали между центровете за данни. Проверка на правилното поведение на две системи за съхранение в условия, при които по някаква причина комуникационният канал между центровете за данни е недостъпен (например багер копае на грешното място и счупи тъмната оптика).
Първо, ще започнем да записваме данни в нашия LUN (запис на файлове с произволни данни). Веднага виждаме, че комуникационният канал между системите за съхранение се използва. Това е лесно да се разбере, ако отворите наблюдението на натоварването на портовете, които отговарят за репликацията.
И двете системи за съхранение вече имат „полезни“ данни, можем да започнем теста.
За всеки случай нека погледнем хеш сумите на един от файловете и да ги запишем.
Редовна смяна на ролите
Операцията по превключване на ролите (промяна на посоката на репликация) може да се извърши с всяка система за съхранение, но все пак ще трябва да отидете и на двете, тъй като ще трябва да деактивирате картографирането на Primary и да го активирате на Secondary (което ще стане Primary ).
Може би сега възниква разумен въпрос: защо да не автоматизираме това? Отговорът е: просто е, репликацията е просто средство за устойчивост при бедствия, базирано единствено на ръчни операции. За автоматизиране на тези операции има режим metrocluster, той е напълно автоматизиран, но конфигурацията му е много по-сложна. Ще напишем за създаването на metrocluster в следващата статия.
В основната система за съхранение деактивираме картографирането, за да гарантираме, че записът спира.
След това на една от системите за съхранение (няма значение, на основната или резервната) в менюто „Отдалечена репликация“ изберете нашата връзка REPL1 и щракнете върху „Промяна на ролята“.
След няколко секунди LUN1R (система за резервно съхранение) става Основна.
Ние картографираме LUN1R със система за съхранение2.
След това нашето устройство E: автоматично се прикачва към хоста, само че този път „пристигна“ от LUN1R.
За всеки случай сравняваме хеш сумите.
Идентично. Тестът премина.
Срив. Повреда в центъра за данни
В момента основната система за съхранение след редовно превключване е система за съхранение 2 и съответно LUN1R. За да емулираме инцидент, ще изключим захранването и на двата контролера за съхранение2.
Вече няма достъп до него.
Да видим какво се случва на система за съхранение 1 (резервната в момента).
Виждаме, че основният LUN (LUN1R) е недостъпен. Появи се съобщение за грешка в регистрационните файлове, в информационния панел, а също и в самото правило за репликация. Съответно данните от хоста в момента не са налични.
Променете ролята на LUN1 на Primary.
Правя картографиране към хоста.
Уверете се, че устройство E се появява на хоста.
Проверяваме хеша.
Всичко е наред. Системата за съхранение успешно преживя падането на центъра за данни, който беше активен. Приблизителното време, което прекарахме в свързване на „обратното“ репликиране и свързване на LUN от резервния център за данни, беше около 3 минути. Ясно е, че в реалното производство всичко е много по-сложно и в допълнение към действията със системите за съхранение, трябва да извършите много повече операции в мрежата, на хостове, в приложения. И в живота този период от време ще бъде много по-дълъг.
Тук бих искал да напиша, че всичко, тестът е завършен успешно, но нека не бързаме. Основната система за съхранение „лежи“, знаем, че когато е „паднала“, е била в основната роля. Какво се случва, ако внезапно се включи? Ще има две основни роли, което се равнява на повреда на данни? Нека да го проверим сега.
Нека внезапно включим основната система за съхранение.
Зарежда се за няколко минути и след кратка синхронизация се връща към обслужване, но в ролята на вторичен.
Всичко е наред. Разделеният мозък не се случи. Помислихме за това и винаги след падане системата за съхранение се издига до ролята на Вторична, независимо каква роля е изпълнявала „по време на живота“. Сега можем да кажем със сигурност, че тестът за отказ на центъра за данни е успешен.
Отказ на комуникационните канали между центровете за данни
Основната задача на този тест е да се увери, че системата за съхранение няма да започне да се държи странно, ако временно загуби комуникационни канали между две системи за съхранение и след това се появи отново.
Така. Изключваме кабелите между системите за съхранение (нека си представим, че са изкопани от багер).
На Primary виждаме, че няма връзка с Secondary.
На Secondary виждаме, че няма връзка с Primary.
Всичко работи добре и ние продължаваме да записваме данни в основната система за съхранение, тоест те са гарантирани, че са различни от резервната, тоест те са „отделени“.
За няколко минути „ремонтираме“ комуникационния канал. Веднага след като системите за съхранение се видят една друга, синхронизирането на данни се активира автоматично. Тук не се изисква нищо от администратора.
След известно време синхронизацията е завършена.
Връзката беше възстановена, загубата на комуникационни канали не предизвика никакви аварийни ситуации и след включване синхронизацията се извърши автоматично.
Данни
Анализирахме теорията - какво е необходимо и защо, къде са плюсовете и къде минусите. След това настроихме синхронна репликация между две системи за съхранение.
След това бяха проведени основни тестове за нормално превключване, повреда в центъра за данни и повреда на комуникационния канал. Във всички случаи системата за съхранение работи добре. Няма загуба на данни и административните операции са сведени до минимум за ръчен сценарий.
Следващият път ще усложним ситуацията и ще покажем как цялата тази логика работи в автоматизиран метрокластер в активен-активен режим, тоест когато и двете системи за съхранение са основни и поведението в случай на повреда на системата за съхранение е напълно автоматизирано.
Моля, пишете коментари, ще се радваме да получим разумна критика и практически съвети.
До следващия път.
Източник: www.habr.com