Здравейте, читатели на Хабра! В последната статия говорихме за просто средство за катастрофна устойчивост в системите за съхранение AERODISK ENGINE – репликацията. В тази статия ще се потопим в по-сложна и интересна тема – метрокластера, тоест средство за автоматизирана защита от катастрофи за две дата центрове, позволяващо им да работят в режим активен-активен. Ще разкажем, ще покажем, ще счупим и ще поправим.
Както обикновено, започваме с теорията
Метрокластера е клъстер, разположен на няколко площадки в рамките на града или района. Думата „клъстер“ явно подсказва, че комплексът е автоматизиран, тоест превключването на възлите на клъстера в случай на повреди (failover) се случва автоматично.
Тук се крие основното отличие на метрокластера от обикновената репликация. Автоматизация на операциите. Тоест, в случай на различни инциденти (повреда на дата центъра, прекъсвания на каналите и т.н.), системата за съхранение сама ще извърши необходимите действия, за да запази достъпността на данните. При използването на обикновени реплики, тези действия се извършват напълно или частично ръчно от администратора.
За какво е нужно това?
Основната цел, която клиентите преследват, използвайки различни реализации на метрокластера, е да минимизират RTO (Recovery Time Objective). Тоест, да намалят времето за възстановяване на ИТ услугите след повреда. Ако се използва обикновена репликация, времето за възстановяване винаги ще бъде по-дълго отколкото времето за възстановяване с метрокластер. Защо? Много просто. Администраторът трябва да е на работното си място и да превключи репликацията ръчно, а метрокластерът го прави автоматично.
Ако нямате назначен дежурен администратор, който да не спи, не яде, не пуши и не боледува, а 24 часа в денонощието наблюдава състоянието на СХД, то нямате и възможност да гарантирате, че администраторът ще бъде на разположение за ръчно превключване по време на повреда.
Съответно, RTO в случай на отсъствието на метрокластер или безсмъртен администратор от 99-то ниво на дежурните администратори ще бъде равен на сумата от времето за превключване на всички системи и максималния период, след който администраторът гарантирано ще започне да работи със СХД и свързаните системи.
По този начин стигаме до очевидното заключение, че метро кластерът трябва да се използва в случай, че изискването за RTO е в минути, а не в часове или дни. Тоест, когато в случай на най-страшния срив на ЦОД, ИТ отделът трябва да осигури на бизнеса време за възстановяване на достъпа до ИТ услуги в рамките на минути, дори секунди.
Как работи това?
На най-ниското ниво метро кластерът използва механизъм за синхронно репликиране на данни, който описахме в предишната статия (вж. ). Тъй като репликирането е синхронно, изискванията към него са съответно, а именно:
- оптично влакно като физически носител, 10-гигабитен Ethernet (или по-висок);
- разстоянието между ЦОД-ите не трябва да надвишава 40 километра;
- забавянето на оптичния канал между ЦОД-ите (между СХД) до 5 милисекунди (оптимално 2).
Всички тези изисквания са препоръчителни, тоест метро кластерът ще работи, дори ако тези изисквания не са спазени, но трябва да се разбере, че последствията от неспазването на тези изисквания са забавяне на работата на двете СХД в метро клъстера.
И така, за предаване на данни между СХД се използва синхронна реплика. А как автоматично се превключват репликите и най-важното, как да се избегне split-brain? За това на по-високо ниво се използва допълнителен елемент — арбитър.
Как работи арбитърът и каква е неговата задача?
Арбитърът представлява малка виртуална машина или хардуерен кластер, който трябва да се стартира на трета площадка (например в офиса) и да се осигури достъп до СХД по ICMP и SSH. След стартиране арбитърът трябва да зададе IP, а след това от страна на СХД да посочи неговия адрес, плюс адресите на отдалечените контролери, които участват в метро кластер. След това арбитърът е готов за работа.
Арбитърът извършва постоянно наблюдение на всички СХД в метро клъстера и в случай на недостъпност на определена система за съхранение той, след потвърждение на недостъпността от друг участник в клъстера (една от „живите“ СХД), взема решение за стартиране на процедурата за превключване на правилата за репликация и мапинг.
Много важен момент. Арбитърът винаги трябва да бъде на площадка, различна от тези, на които се намират СХД, тоест нито в ЦОД 1, където е СХД 1, нито в ЦОД 2, където е инсталирана СХД 2.
Защо? Защото само така арбитърът с помощта на един от оцелелите СХД може недвусмислено и без грешка да определи падението на който и да е от двата майданчика, където са инсталирани СХД. Всякакви други начини за разполагане на арбитъра могат да доведат до split-brain.
Сега да се потопим в детайлите на работата на арбитъра.
На арбитъра са активирани няколко услуги, които постоянно проверяват всички контролери на СХД. Ако резултатът от проверката се различава от предишния (достъпен/недостъпен), той се записва в малка база данни, която също работи на арбитъра.
Нека да разгледаме логиката на работа на арбитъра по-подробно.
Стъпка 1. Определяне на недостъпността. Събитието-сигнал за отказ на СХД е отсъствието на пинг от двата контролера на едно СХД в продължение на 5 секунди.
Стъпка 2. Стартиране на процедурата за превключване. След като арбитърът е разбрал, че едно от СХД е недостъпно, той изпраща заявка до „живото“ СХД, за да се увери, че „мъртвото“ СХД наистина е мъртво.
След получаване на такава команда от арбитъра, второто (живото) СХД допълнително проверява достъпността на падналото първо СХД и, ако го няма, изпраща на арбитъра потвърждение на неговото предположение. СХД наистина е недостъпно.
След получаване на такова потвърждение, арбитърът стартира отдалечената процедура за превключване на репликацията и активиране на мапинга на онези реплики, които са били активни (primary) на падналото СХД, и изпраща команда до второто СХД да направи тези реплики от secondary в primary и да активира мапинга. А второто СХД, съответно, изпълнява тези процедури, след което осигурява достъп до загубените LUN-ове.
Защо е нужно допълнително проверка? За кворума. Тоест, мнозинството от общото нечетно (3) количество участници в кластера трябва да потвърдят падението на един от възлите на кластера. Само тогава това решение ще бъде точно верно. Това е необходимо, за да се избегне погрешно превключване и, съответно, split-brain.
Стъпка 2 по време отнема около 5 — 10 секунди, така че, като се вземе предвид времето, необходимо за определяне на недостъпността (5 секунди), в рамките на 10 – 15 секунди след аварията LUN-овете с падналото СХД ще бъдат автоматично достъпни за работа с живото СХД.
Очевидно е, че за да се избегне прекъсването на връзката с хостовете, трябва да се погрижите и за правилната настройка на таймаутите на хостовете. Препоръчителният таймаут е не по-малко от 30 секунди. Това няма да позволи на хоста да прекъсне връзката с СХД по време на смяната на натоварването при авария и ще гарантира отсъствието на прекъсвания в входа-изхода.
Чекайте малко, ако с метрокластера е всичко толкова добре, защо изобщо е нужна обикновена репликация?
Всъщност, не е толкова просто.
Нека разгледаме предимствата и недостатъците на метрокластера
И така, разбираме, че очевидните предимства на метрокластера в сравнение с обикновената репликация са:
- Пълна автоматизация, осигуряваща минимално време за възстановяване в случай на катастрофа;
- И това е всичко :-).
А сега, внимание, недостатъците:
- Цена на решението. Въпреки че метрокластерът в системите Аеродиск не изисква допълнително лиценизиране (използва се същото разрешение, както за репликата), цената на решението все пак ще бъде по-висока, отколкото при използването на синхронна репликация. Необходими са да се изпълнят всички изисквания за синхронна реплика, плюс изискванията за метрокластер, свързани с допълнителната комутация и допълнителната площадка (вж. планиране на метрокластера);
- Сложност на решението. Метрокластерът е значително по-сложен от обикновената реплика и изисква значително повече внимание и усилия за планиране, настройка и документиране.
В резултат. Метрокластерът е определено много технологично и добро решение, когато наистина трябва да осигурите RTO в секунди или минути. Но ако такава задача не съществува и RTO в часове е приемливо за бизнеса, няма смисъл да се стреля с топ от пушката по врабчета. Достатъчно е обикновената работническа репликация, тъй като метрокластерът ще доведе до допълнителни разходи и усложняване на ИТ инфраструктурата.
Планиране на метрокластера
Тази глава не претендира за всепризнато ръководство по проектиране на метрокластер, а просто показва основните направления, които трябва да се разгледат, ако решите да изградите подобна система. Затова при реалното внедряване на метрокластер задължително привлекайте за консултации производителя на СХД (т.е. нас) и други съседни системи.
Площадки
Както е посочено по-горе, за метрокластера са необходими най-малко три площадки. Два ЦОД-а, където ще работят СХД и свързани системи, както и трета площадка, където ще работи арбитърът.
Препоръчителното разстояние между ЦОД-ите не трябва да надвишава 40 километра. По-голямо разстояние с висока вероятност ще предизвика допълнителни забавяния, които в случая на метрокластера са крайно нежелателни. Напомняме, че забавянията трябва да бъдат до 5 милисекунди, макар желателно да се вместим в 2.
Препоръчва се забавянията да се проверяват и в процеса на планиране. Всеки по-възрастен доставчик, предлагащ оптични влакна между ЦОД-ите, може да организира качествена проверка доста бързо.
Що се отнася до забавянията до арбитъра (тоест между третата площадка и двете първи), препоръчителният праг за забавяния е до 200 милисекунди, т.е. подхожда обикновено корпоративно VPN-свързване върху мрежата Интернет.
Комутация и мрежа
В отличие от схемата с репликация, където е достатъчно да се свържат помежду си СХД от различни площадки, схемата с метрокластера изисква свързване на хостовете с двете СХД на различни площадки. За да стане по-ясно, в какво се състои разликата, и двете схеми са посочени по-долу.
Както се вижда от схемата, хостовете на площадка 1 гледат към СХД1 и СХД2. Също така обратното, хостовете на площадка 2 гледат към СХД2 и СХД1. Тоест, всеки хост вижда и двете СХД. Това е задължително условие за функционирането на метрокластера.
Разбира се, няма нужда всеки хост да бъде влачен с оптичен кабел в друг ЦОД, никакви портове и кабели няма да стигнат. Всички тези свързвания трябва да се извършват чрез комутатори Ethernet 10G+ или FibreChannel 8G+ (FC само за свързване на хостовете и СХД за IO, каналът за репликация в момента е достъпен само по IP (Ethernet 10G+).
Сега няколко думи за топологията на мрежата. Важен момент е правилната конфигурация на подсетите. Необходимо е незабавно да се определят няколко подсети за следните типове трафик:
- Подсетка за репликация, по която ще се синхронизират данните между СХД. Те могат да бъдат няколко, в този случай няма значение, всичко зависи от текущата (вече реализирана) топология на мрежата. Ако са две, очевидно трябва да бъде настроена маршрутизация между тях;
- Подмрежи за съхранение на данни, чрез които хостовете ще получават достъп до ресурсите на СХД (ако е iSCSI). Трябва да има по една такава подмрежа във всеки ЦОД;
- Управляващи подмрежи, т.е. три маршрутизируеми подмрежи на три площадки, от които се управлява СХД, а също така е разположен арбитър.
Подмрежите за достъп до ресурсите на хостовете не разглеждаме тук, тъй като те зависят значително от задачите.
Разделението на различен трафик по различни подмрежи е изключително важно (особено е нужно да се отдели репликацията от входно-изходния трафик), тъй като смесването на целия трафик в една "едра" подмрежа прави управлението на този трафик невъзможно, а при наличие на два ЦОД-а може да предизвика различни мрежови колизии. В тази статия няма да навлизаме дълбоко в този въпрос, тъй като за планирането на мрежа, разширена между ЦОД-ите, можете да се информирате от ресурсите на производителите на мрежово оборудване, където е описано подробно.
Конфигурация на арбитъра
Арбитърът трябва да осигури достъп до всички управляеми интерфейси на СХД по протоколите ICMP и SSH. Трябва също така да се обмисли устойчивостта на арбитъра. Има нюанси.
Устойчивостта на арбитъра е много желателна, но не е задължителна. Какво ще се случи, ако арбитърът се срине навреме?
- Работата на метрокластера в нормален режим няма да се промени, тъй като арбитърът не влияе абсолютно на работата на метрокластера в нормален режим (неговата задача е навременно да прехвърли товара между ЦОД-ите)
- Ако арбитърът по някаква причина се срине и "проспи" аварията в ЦОД-а, то никакво прехвърляне няма да се случи, защото няма кой да даде нужните команди за прехвърляне и да организира кворума. В този случай метрокластерът ще се превърне в обикновена схема с репликация, която ще трябва ръчно да прехвърляте по време на катастрофа, което ще повлияе на RTO.
Какво произлиза от това? Ако наистина трябва да осигурите минимален показател RTO, трябва да осигурите устойчивост на арбитъра. Има два варианта за това:
- Да стартирате виртуална машина с арбитър на устойчив хипервизор, добре че всички зрелите хипервизори поддържат устойчивост;
- Ако на третата площадка (в условния офис) е мързеливо да се постави нормален кластер и няма съществуващ хиперконвергиран кластер, тогава предвидихме хардуерна версия на арбитъра, която е реализирана в кутия 2U, в която работят два обикновени x-86 сървъра и която може да оцелява при локален отказ.
Настоятелно ви препоръчваме да осигурите отказоустойчивост на арбитъра, въпреки че в нормален режим той не е необходим за метрокластера. Но както показват теорията, така и практиката, ако изграждате наистина надеждна инфраструктура за справяне с бедствия, по-добре е да се застраховате. По-добре е да защитите себе си и бизнеса от 'закона на подлостта', тоест от едновременното излизане от строя на арбитъра и една от площадките, където е разположена СХД.
Архитектура на решението
Като вземем предвид горепосочените изисквания, получаваме следната обща архитектура на решението.
LUN-ите трябва да се разпределят равномерно между двете площадки, за да се избегне сериозно натоварване. При това, при сайзинга и в двете ЦОД-ове, е нужно да се предвиди не само двойният обем (който е необходим за съхранение на данни едновременно на две СХД), но и двойната производителност в IOPS и MB/s, за да не се допуска деградация на приложенията при отказ на едно от ЦОД-овете.
Отделно отбелязваме, че при правилен подход към сайзинга (т.е. при условие, че сме предвидили подходящи горни граници за IOPS и MB/s, а също така необходимите ресурси CPU и RAM) при отказ на една от СХД в метрокластера няма да има сериозна загуба на производителност при временното работа само на една СХД.
Това се обяснява с факта, че при работа на две площадки, работещата синхронна репликация 'отнема' половината производителност при запис, тъй като всяка транзакция трябва да бъде записвана на две СХД (аналогично на RAID-1/10). Така, при отказ на една от СХД, влиянието на репликацията временно (докато не се възстанови отказалата се СХД) отпада и получаваме двукратен ръст на производителността при запис. След като LUN-ите на отказалата се СХД се рестартират на работещата СХД, този двукратен ръст изчезва, тъй като се появява натоварване от LUN-ите на другата СХД, и се връщаме към същото ниво на производителност, което имахме преди 'падането', но само в рамките на вече една площадка.
С помощта на правилен сайзинг могат да се осигурят условия, при които потребителите няма да усетят отказа на цяла СХД. Но отново подчертаваме, че това изисква много внимателен сайзинг, към който, между другото, може да се обърнете към нас безплатно :-).
Настройка на метрокластер
Настройката на метрокластера е много подобна на настройката на обикновена репликация, която описахме в . Затова ще се фокусираме само върху различията. Настроихме в лаборатория стенд, основан на горната архитектура, само в минимален вариант: две СХД, свързани помежду си чрез 10G Ethernet, два 10G суича и един хост, който гледа през суичовете към двете СХД с 10G портове. Арбитърът работи на виртуална машина.
При настройката на виртуални IP (VIP) за репликата трябва да се избере тип VIP – за метрокластер.
Създадохме две репликационни връзки за два LUN-а и ги разпределихме между двете СХД: LUN TEST Primary на СХД1 (връзка METRO), LUN TEST2 Primary за СХД2 (връзка METRO2).
За тях настроихме две идентични цели (в нашия случай iSCSI, но поддържа се и FC, логиката на настройката е същата).
СХД1:
СХД2:
За репликационните връзки създадохме мапинги на всяка СХД.
СХД1:
СХД2:
Настроихме multipath и го предоставихме на хоста.
Настройваме арбитъра
С арбитъра не е необходимо да се прави много, просто трябва да се включи на третата площадка, да му зададете IP и да настроите достъп до него чрез ICMP и SSH. Самата настройка се извършва от самите СХД. При това настройката на арбитъра е достатъчно да се извърши само веднъж на някой от контролерите на СХД в метрокластера, тези настройки ще се разпространят автоматично на всички контролери.
В раздела Удалена репликация>> Метрокластер (на който и да е контролер)>> бутон 'Конфигуриране'.
Въвеждаме IP на арбитъра, както и управляващите интерфейси на двата контролера на отдалечената СХД.
След това е необходимо да се включат всички услуги (бутон 'Всички да се рестартират'). В случай на пренастройка в бъдеще услугите трябва задължително да се рестартират, за да влязат в сила настройките.
Проверяваме дали всички услуги са стартирани.
С това настройката на метрокластера е завършена.
Краш-тест
Краш-тестът в нашия случай ще бъде достатъчно прост и бърз, тъй като функционалността на репликацията (превключване, консистентност и пр.) беше разгледана в . Затова, за да тестваме надеждността на метрокластера, ни е достатъчно да проверим автоматизацията на откритие на аварии, превключвания и отсъствие на загуби при запис (спиране на входно-изходните операции).
За целта емулираме пълен отказ на една от СХД, физически изключвайки и двата й контролера, преди това стартирайки копирането на голям файл на LUN, който трябва да се активира на другата СХД.
Изключваме една СХД. На втората СХД виждаме алерти и съобщения в логовете, че е изгубена връзката с съседната система. Ако са настроени уведомления по SMTP или SNMP мониторинг, администраторът ще получи съответните уведомления.
Точно след 10 секунди (видимо на и двете скрийншотове) репликационната връзка METRO (тази, която беше Primary на падналата СХД) автоматично стана Primary на работещата СХД. Използвайки съществуващото мапинг, LUN TEST остана достъпен за хоста, записът леко отпадна (в рамките на обещаните 10 процента), но не беше прекъснат.
Тестът приключи успешно.
Нека обобщим
Текущата реализация на метрокластера в системите за съхранение AERODISK Engine N-серията напълно позволява решаването на задачи, при които е необходимо да се изключи или минимизира времето на простои на ИТ услугите и да се осигури тяхната работа в режим 24/7/365 с минимални трудозатрати.
Може да се каже, разбира се, че всичко това е теория, идеални лабораторни условия и т.н.… НО имаме редица реализирани проекти, в които сме въвели функционалност за устойчивост на катастрофи, и системите работят отлично. Един от нашите доста известни клиенти, където се използват две СХД в конфигурация за устойчивост на катастрофи, вече даде съгласие за публикуване на информация за проекта, затова в следващата част ще разкажем за бойното внедряване.
Благодарим, очакваме продуктивна дискусия.
Източник: habr.com
