Здравейте читатели на Хабр! В последната статия говорихме за просто средство за възстановяване след бедствие в системи за съхранение на AERODISK ENGINE - репликация. В тази статия ще се потопим в по-сложна и интересна тема - metrocluster, тоест автоматизиран инструмент за защита от бедствия за два центъра за данни, който позволява на центровете за данни да работят в режим активен-активен. Ще разкажем, покажем, разбием и поправим.
Както обикновено, в началото на теорията
Metrocluster е клъстер, разположен на няколко места в рамките на град или област. Думата "клъстер" ясно ни подсказва, че комплексът е автоматизиран, т.е. превключването на клъстерните възли в случай на повреда (failover) става автоматично.
Това е мястото, където се крие основната разлика между metrocluster и редовната репликация. Автоматизация на операциите. Тоест, в случай на определени инциденти (отказ на центъра за данни, счупване на канали и т.н.), системата за съхранение ще извърши независимо необходимите действия, за да поддържа наличността на данните. Когато използвате обикновени реплики, тези действия се извършват изцяло или частично ръчно от администратора.
Какво прави той?
Основната цел, преследвана от клиентите, използващи определени реализации на metrocluster, е да се сведе до минимум RTO (Recovery Time Objective). Тоест да се минимизира времето за възстановяване на ИТ услугите след повреда. Ако използвате конвенционална репликация, тогава времето за възстановяване винаги ще бъде по-голямо от времето за възстановяване с метро клъстер. Защо? Много просто. Администраторът трябва да е на работното място и да превключва репликацията ръчно, докато метро клъстерът прави това автоматично.
Ако нямате специален дежурен администратор, който не спи, не яде, не пуши и не се разболява, но гледа състоянието на системата за съхранение 24 часа в денонощието, тогава няма начин да гарантирате, че администраторът ще да бъде на разположение за ръчно превключване по време на повреда.
Съответно, RTO при липса на метро клъстер или безсмъртен администратор на 99-то ниво на дежурната служба на администраторите ще бъде равен на сумата от времето за превключване на всички системи и максималния период от време, след който администраторът гарантира, че започнете да работите със системата за съхранение и свързаните с нея системи.
Така стигаме до очевидното заключение, че metrocluster трябва да се използва, ако изискването за RTO е минути, а не часове или дни.Тоест, когато в случай на най-страшното падане на центъра за данни, ИТ отделът трябва да осигури на бизнеса с време за възстановяване на достъпа до ИТ услуги в рамките на минути или дори секунди.
Как действа тя?
На по-ниско ниво metrocluster използва механизма за синхронна репликация на данни, който описахме в предишната статия (вижте по-долу). ). Тъй като репликацията е синхронна, изискванията за нея са подходящи или по-скоро:
- влакна като физика, 10 гигабитов Ethernet (или по-висок);
- разстоянието между центровете за данни е не повече от 40 километра;
- забавяне на оптичния канал между центрове за данни (между системи за съхранение) до 5 милисекунди (оптимално 2).
Всички тези изисквания имат препоръчителен характер, т.е. метро клъстерът ще работи дори ако тези изисквания не са изпълнени, но трябва да се разбере, че последствията от неспазването на тези изисквания са равни на забавяне на работата на двете системи за съхранение в клъстера на метрото.
И така, синхронна реплика се използва за прехвърляне на данни между системи за съхранение, но как репликите автоматично се превключват и, най-важното, как да се избегне разделяне на мозъка? За да направите това, на нивото по-горе се използва допълнителен субект - арбитърът.
Как работи арбитърът и каква е неговата задача?
Арбитърът е малка виртуална машина или хардуерен клъстер, който трябва да бъде стартиран на трети сайт (например в офис) и да осигури достъп до хранилище чрез ICMP и SSH. След стартиране арбитърът трябва да зададе IP и след това да посочи неговия адрес от страната на съхранението, плюс адресите на дистанционните контролери, които участват в метро клъстера. След това реферът е готов за игра.
Арбитърът постоянно наблюдава всички системи за съхранение в метро клъстера и в случай, че определена система за съхранение е недостъпна, след потвърждение за недостъпност от друг член на клъстера (една от "живите" системи за съхранение), той решава да стартира процедурата за превключване на правила за репликация и картографиране.
Много важен момент. Арбитърът винаги трябва да се намира на място, различно от тези, на които са разположени системите за съхранение, тоест нито в DPC 1, където се намира хранилище 1, нито в DPC 2, където е инсталирано съхранение 2.
Защо? Защото само така арбитърът, с помощта на една от оцелелите системи за съхранение, може недвусмислено и точно да определи падането на който и да е от двата обекта, където са инсталирани системите за съхранение. Всеки друг начин за поставяне на арбитър може да доведе до раздвоен мозък.
Сега нека се потопим в детайлите на работата на арбитъра.
Няколко услуги работят на арбитъра, който постоянно анкетира всички контролери за съхранение. Ако резултатът от анкетата се различава от предишната (наличен/недостъпен), тогава той се записва в малка база данни, която също работи на арбитъра.
Разгледайте по-подробно логиката на арбитъра.
Стъпка 1. Определяне на неналичност. Събитие, сигнализиращо за повреда на системата за съхранение, е липсата на ping от двата контролера на същата система за съхранение за 5 секунди.
Стъпка 2. Стартиране на процедурата по превключване. След като арбитърът разбере, че една от системите за съхранение е недостъпна, той изпраща заявка до "живата" система за съхранение, за да се увери, че "мъртвата" система за съхранение наистина е мъртва.
След получаване на такава команда от арбитъра, втората (жива) система за съхранение допълнително проверява наличността на падналата първа система за съхранение и, ако не, изпраща на арбитъра потвърждение на неговото предположение. SHD наистина не е наличен.
След като получи такова потвърждение, арбитърът стартира дистанционна процедура за превключване на репликация и повишаване на картографирането на онези реплики, които са били активни (основни) на повредената система за съхранение, и изпраща команда до втората система за съхранение, за да направи тези реплики от вторични към първични и повдигнете картографирането. Е, втората система за съхранение, съответно, изпълнява тези процедури, след което осигурява достъп до изгубените LUN от себе си.
Защо е необходима допълнителна проверка? За кворум. Тоест по-голямата част от общия нечетен (3) брой членове на клъстера трябва да потвърди падането на един от възлите на клъстера. Само тогава това решение ще бъде точно правилно. Това е необходимо, за да се избегне погрешно превключване и съответно разделяне на мозъка.
Стъпка 2 отнема около 5-10 секунди във времето, така че, като се вземе предвид времето, необходимо за определяне на недостъпност (5 секунди), в рамките на 10-15 секунди след повредата, LUN с повредена система за съхранение ще бъдат автоматично достъпни за работа с live съхранение.
Ясно е, че за да избегнете прекъсване на връзката с хостовете, трябва да се погрижите и за правилната настройка на изчакванията на хостовете. Препоръчителното време за изчакване е поне 30 секунди. Това не позволява на хоста да прекъсне връзката към хранилището по време на зареждане при отказ и може да гарантира, че няма I/O прекъсване.
Чакай малко, оказва се, че ако всичко е наред с метро клъстера, защо изобщо се нуждаем от редовна репликация?
Всъщност всичко не е толкова просто.
Помислете за плюсовете и минусите на metrocluster
И така, разбрахме, че очевидните предимства на metrocluster в сравнение с конвенционалната репликация са:
- Пълна автоматизация, осигуряваща минимално време за възстановяване при авария;
- И това е :-).
И сега, внимание, минуси:
- Цена на решението. Въпреки че metrocluster в системите на Aerodisk не изисква допълнително лицензиране (използва се същият лиценз като за репликата), цената на решението ще бъде дори по-висока от използването на синхронна репликация. Ще трябва да приложите всички изисквания за синхронна реплика, плюс изискванията за метро клъстера, свързан с допълнително превключване и допълнителен сайт (вижте планиране на метро клъстер);
- Сложността на решението. Metrocluster е много по-сложен от обикновената реплика и изисква много повече внимание и усилия за планиране, конфигуриране и документиране.
В крайна сметка. Metrocluster със сигурност е много технологично и добро решение, когато наистина трябва да осигурите RTO за секунди или минути. Но ако няма такава задача и RTO в часове е ОК за бизнес, тогава няма смисъл да стреляте по врабчета от оръдие. Обичайната работническо-селска репликация е достатъчна, тъй като метрото ще доведе до допълнителни разходи и усложняване на ИТ инфраструктурата.
Метро клъстерно планиране
Този раздел не претендира да бъде изчерпателен урок за проектиране на метро клъстери, а само показва основните насоки, които трябва да бъдат разработени, ако решите да изградите такава система. Следователно, по време на реалното внедряване на метро клъстера, не забравяйте да включите производителя на системата за съхранение (тоест нас) и други свързани системи за консултация.
игрище
Както беше посочено по-горе, един метро клъстер изисква минимум три обекта. Два центъра за данни, където ще работят системи за съхранение и свързани системи, както и трета площадка, където ще работи арбитърът.
Препоръчителното разстояние между центровете за данни е не повече от 40 километра. По-голямото разстояние е много вероятно да причини допълнителни закъснения, които са крайно нежелателни в случай на метро клъстер. Спомнете си, че закъсненията трябва да бъдат до 5 милисекунди, въпреки че е желателно да се поддържат в рамките на 2.
Закъсненията също се препоръчват да бъдат проверени по време на процеса на планиране. Всеки повече или по-малко възрастен доставчик, който предоставя влакна между центровете за данни, може да организира проверка на качеството доста бързо.
Що се отнася до закъсненията до арбитъра (т.е. между третия сайт и първите два), препоръчителният праг на забавяне е до 200 милисекунди, тоест нормална корпоративна VPN връзка през интернет ще свърши работа.
Превключване и мрежа
За разлика от схемата за репликация, където е достатъчно да се свържат системи за съхранение от различни сайтове, схемата на метро клъстера изисква свързване на хостове към двете системи за съхранение на различни сайтове. За да стане по-ясно каква е разликата, двете схеми са изброени по-долу.
Както можете да видите от диаграмата, имаме хостове на сайт 1, които разглеждат както система за съхранение 1, така и система за съхранение 2. Също така, напротив, хостовете на сайт 2 разглеждат както система за съхранение 2, така и система за съхранение 1. Тоест всеки хост вижда и двете системи за съхранение. Това е предпоставка за функционирането на метрокластъра.
Разбира се, няма нужда да дърпате всеки хост с оптичен кабел към друг център за данни, няма да има достатъчно портове и кабели. Всички тези връзки трябва да бъдат направени чрез Ethernet 10G+ или FibreChannel 8G+ комутатори (FC само за свързване на хостове и съхранение за IO, каналът за репликация в момента е достъпен само през IP (Ethernet 10G+).
Сега няколко думи за топологията на мрежата. Важен момент е правилната конфигурация на подмрежите. Трябва незабавно да дефинирате няколко подмрежи за следните видове трафик:
- Подмрежа за репликация, през която данните ще се синхронизират между системите за съхранение. Може да има няколко от тях, в този случай няма значение, всичко зависи от текущата (вече внедрена) топология на мрежата. Ако има два от тях, тогава, очевидно, маршрутизирането между тях трябва да бъде конфигурирано;
- Подмрежи за съхранение, през които хостовете ще имат достъп до ресурсите за съхранение (ако е iSCSI). Трябва да има една такава подмрежа във всеки център за данни;
- Контролни подмрежи, тоест три маршрутизирани подмрежи на три места, от които се управлява съхранението, и арбитърът също се намира там.
Тук не разглеждаме подмрежи за достъп до ресурсите на хоста, тъй като те са силно зависими от задачите.
Разделянето на различен трафик в различни подмрежи е изключително важно (особено важно е да се отдели репликата от I/O), защото ако смесите целия трафик в една „дебела“ подмрежа, тогава този трафик ще бъде невъзможно да се управлява и в условията на два центъра за данни това все още може да причини различни опции за мрежов сблъсък. Няма да се задълбочаваме в този въпрос в рамките на тази статия, тъй като можете да прочетете за планирането на мрежа, опъната между центрове за данни на ресурсите на производителите на мрежово оборудване, където това е описано много подробно.
Конфигурация на арбитър
Арбитърът трябва да осигури достъп до всички контролни интерфейси на системата за съхранение чрез ICMP и SSH протоколи. Трябва да помислите и за толерантността на грешките на арбитъра. Тук има един нюанс.
Сривът на арбитър е силно желателен, но не е задължителен. И какво се случва, ако арбитърът катастрофира в неподходящия момент?
- Работата на метрокластера в нормален режим няма да се промени, т.к arbtir изобщо не засяга работата на metrocluster в нормален режим (неговата задача е да превключва натоварването между центровете за данни навреме)
- В същото време, ако арбитърът по една или друга причина падне и "заспи" аварията в центъра за данни, тогава няма да има превключване, защото няма да има кой да даде необходимите команди за превключване и да организира кворум. В този случай метро клъстерът ще се превърне в обикновена схема за репликация, която ще трябва да се превключва ръчно по време на бедствие, което ще засегне 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 Основно за съхранение1 (METRO връзка), LUN TEST2 Основно за съхранение2 (METRO2 връзка).
За тях конфигурирахме две идентични цели (в нашия случай iSCSI, но се поддържа и FC, логиката на конфигурацията е същата).
съхранение1:
съхранение2:
За връзките за репликация бяха направени съпоставки на всяка система за съхранение.
съхранение1:
съхранение2:
Настроихме multipath и го представихме на хоста.
Назначаване на арбитър
Не е необходимо да правите нищо специално със самия арбитър, просто трябва да го включите на третия сайт, да зададете неговия IP и да конфигурирате достъпа до него чрез ICMP и SSH. Самата конфигурация се извършва от самите системи за съхранение. В същото време е достатъчно да конфигурирате арбитъра веднъж на който и да е от контролерите за съхранение в метро клъстера, тези настройки ще бъдат разпределени автоматично до всички контролери.
Под Remote Replication>> Metrocluster (на всеки контролер)>> Бутон Configure.
Въвеждаме IP-то на арбитъра, както и контролните интерфейси на двата дистанционни контролера за съхранение.
След това трябва да активирате всички услуги (бутон „Рестартиране на всичко“). Ако преконфигурирате в бъдеще, услугите трябва да се рестартират, за да влязат в сила настройките.
Проверяваме дали всички услуги работят.
Това завършва настройката на metrocluster.
Краш тест
Краш тестът в нашия случай ще бъде доста прост и бърз, тъй като функционалността за репликация (превключване, последователност и т.н.) беше взета предвид в . Следователно, за да тестваме надеждността на метро клъстера, е достатъчно да проверим автоматизацията на откриването на аварии, превключването и липсата на загуби при запис (I/O спирания).
За да направим това, ние емулираме пълен отказ на една от системите за съхранение, като физически изключваме и двата контролера, след като започнем да копираме голям файл в LUN, който трябва да бъде активиран на друга система за съхранение.
Деактивирайте една система за съхранение. Във втората система за съхранение виждаме предупреждения и съобщения в регистрационните файлове, че връзката със съседната система е изчезнала. Ако известията чрез SMTP или SNMP мониторинг са конфигурирани, тогава съответните известия ще бъдат изпратени до администратора.
Точно 10 секунди по-късно (вижда се и на двете екранни снимки), връзката за репликация на METRO (тази, която беше основна на повредената система за съхранение) автоматично стана основна на работещата система за съхранение. Използвайки съществуващото картографиране, LUN TEST остана достъпен за хоста, записът намаля малко (в рамките на обещаните 10 процента), но не спря.
Тестът приключи успешно.
Обобщение
Текущото внедряване на metrocluster в системите за съхранение на AERODISK Engine N-серия напълно ви позволява да решавате проблеми, при които трябва да премахнете или минимизирате времето на престой на ИТ услугите и да осигурите тяхната работа в режим 24/7/365 с минимални разходи за труд.
Можете, разбира се, да кажете, че всичко това е теория, идеални лабораторни условия и така нататък ... НО имаме редица реализирани проекти, в които внедрихме функционалността за възстановяване след бедствие и системите работят перфектно. Един от нашите доста добре познати клиенти, където се използват само две системи за съхранение в конфигурация, устойчива на бедствия, вече се съгласи да публикува информация за проекта, така че в следващата част ще говорим за бойно внедряване.
Благодаря, очаквам продуктивна дискусия.
Източник: www.habr.com