Привіт читачі Хабра! Минулої статті розповіли про простий засіб катастрофостійкості в системах зберігання AERODISK ENGINE – про реплікацію. У цій статті ми поринемо в складнішу і цікавішу тему – метрокластер, тобто засіб автоматизованого захисту від катастроф для двох ЦОД-ів, що дозволяє працювати ЦОД-ам у режимі active-active. Розкажемо, покажемо, зламаємо і полагодимо.
Як завжди, на початку теорія
Метрокластер – це кластер, рознесений на кілька майданчиків у межах міста чи району. Слово "кластер" нам явно натякає на те, що комплекс автоматизований, тобто перемикання вузлів кластера у разі збоїв (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