Привіт, Хабре!
Після новорічних свят ми перезапустили катастрофічну хмару на базі двох майданчиків. Сьогодні розповімо, як це влаштовано, і покажемо, що відбувається з клієнтськими віртуальними машинами у разі відмови окремих елементів кластера та падіння цілого майданчика (спойлер – з ними все добре).
СГД катастрофостійкої хмари на майданчику OST.
Що всередині
Під капотом у кластера сервери Cisco UCS з гіпервізором VMware ESXi, дві СХД INFINIDAT InfiniBox F2240, мережеве обладнання Cisco Nexus, а також SAN-світи Brocade. Кластер рознесений на два майданчики – OST та NORD, тобто у кожному дата-центрі ідентичний набір обладнання. Власне, це і робить його катастрофічним.
В рамках одного майданчика основні елементи також продубльовані (хости, SAN-світчі, сітківка).
Два майданчики з'єднані виділеними оптоволоконними трасами, які теж зарезервовані.
Кілька слів про СГД. Перший варіант катастрофостійкої хмари ми будували на NetApp. Тут вибрали INFINIDAT, і ось чому:
- Опція Active-Active реплікації. Вона дозволяє віртуальній машині залишатися у працездатному стані навіть при повній відмові однієї із СГД. Про реплікацію розповім детальніше далі.
- Три дискові контролери для підвищення відмовостійкості системи. Зазвичай їх два.
- Готове рішення. До нас приїхала вже зібрана стійка, яку потрібно підключити до мережі і налаштувати.
- Уважна техпідтримка. Інженери INFINIDAT постійно аналізують логи та події СГД, встановлюють нові версії у прошивці, допомагають із налаштуванням.
Ось трохи фоточок з unpacking'а:
Як працює
Хмара вже стійка до відмови всередині себе. Воно захищає клієнта від одиничних апаратних та програмних відмов. Катастрофостійке допоможе захиститися від масових збоїв в межах одного майданчика: наприклад, відмова СГД (або кластера SDS, що трапляється нерідко 🙂 ), масові помилки в мережі зберігання та інше. Ну і найголовніше: така хмара рятує, коли стає недоступним цілий майданчик через пожежу, блекаут, рейдерське захоплення, висадку інопланетян.
У всіх цих випадках клієнтські віртуальні машини продовжують працювати, і ось чому.
Схема кластера влаштована так, що будь-який ESXi-хост із клієнтськими віртуальними машинами може звертатися до будь-якої з двох СГД. Якщо СГД на майданчику OST вийде з ладу, віртуальні машини продовжать працювати: хости, на яких вони працюють, звертатимуться за даними до СГД на NORD.
Ось так виглядає схема підключення у кластері.
Це можливо завдяки тому, що між SAN-фабриками двох майданчиків налаштований Inter-Switch Link: SAN-світч Fabric A OST з'єднаний з SAN-світлом Fabric A NORD, аналогічно і для SAN-світчої Fabric B.
Ну і щоб усі ці поєднання SAN-фабрик мали сенс, між двома СХД налаштована Active-Active реплікація: інформація практично одночасно записується на локальну і віддалену СХД, RPO=0. Виходить, що на одній СГД зберігається оригінал даних, на іншій – їхня репліка. Дані реплікуються лише на рівні томів СХД, а на них зберігаються дані ВМ (її диски, конфігураційний файл, swap-файл тощо.).
ESXi-хост бачить основний том та його репліку як один дисковий пристрій (Storage Device). Від ESXi-хоста до кожного дискового пристрою йдуть 24 шляхи:
12 шляхів пов'язують його з локальною СХД (оптимальні шляхи), інші 12 – з віддаленої (не оптимальні шляхи). У штатній ситуації ESXi звертається до даних на локальній СГД, використовуючи "оптимальні" шляхи. При виході з ладу цієї СГД ESXi втрачає оптимальні шляхи та перемикається на “неоптимальні”. Ось як це виглядає на схемі.
Схема катастрофостійкого кластера.
Усі клієнтські мережі заведені на обидва майданчики через загальну мережеву фабрику. На кожному майданчику працює Provider Edge (PE), на якому термінуються мережі клієнта. PE об'єднані у загальний кластер. При відмові PE на одному майданчику весь трафік перенаправляється на другий майданчик. Завдяки цьому віртуальні машини з майданчика без PE, залишаються доступними по мережі для клієнта.
Давайте тепер подивимося, що відбуватиметься з віртуальними машинами клієнта за різних відмов. Почнемо з найлайтовіших варіантів і закінчимо найсерйознішим – відмовою всього майданчика. У прикладах основним майданчиком буде OST, а резервною з репліками даних – NORD.
Що відбувається з віртуальною машиною клієнта, якщо…
Відмовляє Replication Link. Реплікація між СГД двох майданчиків припиняється.
ESXi працюватимуть лише з локальними дисковими пристроями (оптимальними шляхами).
Віртуальні машини продовжують працювати.
Відбувається розрив ISL (Inter-Switch Link). Випадок малоймовірний. Хіба що якийсь скажений екскаватор перекопає одразу кілька оптичних трас, які проходять незалежними маршрутами та заведені на майданчики через різні вводи. Але все таки. У цьому випадку ESXi-хости втрачають половину шляхів і можуть звертатися лише до своїх локальних СГД. Репліки збираються, але хости не зможуть до них звертатися.
Віртуальні машини працюють штатно.
Відмовляє SAN-світч на одному з майданчиків. ESXi-хости втрачають частину шляхів до СГД. У цьому випадку хости на майданчику, де відмовив свитч, працюватимуть лише через один свій HBA.
Віртуальні машини у своїй продовжують працювати штатно.
Відмовляють усі SAN-світи на одному з майданчиків. Припустимо, така біда сталася на майданчику OST. В цьому випадку ESXi-хости на цьому майданчику втратять усі шляхи до своїх дискових пристроїв. У справу вступає стандартний механізм VMware vSphere HA: він перезапустить усі віртуальні машини майданчика OST у NORD`і максимум через 140 секунд.
Віртуальні машини, які працюють на хостах майданчика NORD, працюють штатно.
Відмовляє ESXi-хост на одному майданчику. Тут знову відпрацьовує механізм vSphere HA: віртуальні машини зі збійного хоста перезапускаються на інших хостах - на тому ж або віддаленому майданчику. Час перезапуску віртуальної машини – до 1 хвилини.
Якщо відмовляють всі ESXi-хости майданчики OST, тут вже без варіантів: ВМ перезапускаються на інший. Час перезапуску той самий.
Відмовляє СГД на одному майданчику. Припустимо, відмовила СГД на майданчику OST. Тоді ESXi-хости майданчики OST перемикаються на роботу з репліками СГД у NORD'e. Після повернення збійної СГД до ладу відбудеться примусова реплікація, ESXi-хости OST знову почнуть звертатися до локальної СГД.
Віртуальні машини весь цей час працюють штатно.
Відмовляє один із майданчиків. У цьому випадку всі віртуальні машини перезапускатимуться на резервному майданчику через механізм vSphere HA. Час перезапуску ВМ – 140 секунд. При цьому всі мережеві налаштування віртуальної машини збережуться, і вона залишається доступною для клієнта через мережу.
Щоб перезапуск машин на резервному майданчику пройшов без проблем, кожен майданчик заповнений лише наполовину. Друга половина – резерв на випадок переїзду всіх віртуальних машин із другого, потерпілого майданчика.
Ось від таких відмов захищає катастрофічну хмару на базі двох дата-центрів.
Задоволення це недешеве, тому що, на додачу до основних ресурсів, потрібний резерв на другому майданчику. Тому розміщують у такій хмарі бізнес-критичні сервіси, тривалий простий яких зазнає великих фінансових та репутаційних збитків, або якщо до інформаційної системи пред'являються вимоги щодо катастрофостійкості від регуляторів або внутрішніх регламентів компанії.
Джерела:
Джерело: habr.com