Огляд варіантів реалізації відмовостійких кластерів. Висока і постійна доступність



Є різновиди бізнесу, де перерви в наданні сервісу неприпустимі. Наприклад, якщо у стільникового оператора з-за поломки сервера зупиниться білінгова система, абоненти залишаться без зв'язку. Від усвідомлення можливих наслідків цієї події виникає резонне бажання підстрахуватися.

Ми розповімо які є способи захисту від збоїв серверів і які архітектури використовують при впровадженні VMmanager Cloud: продукту, який призначений для створення кластера високої доступності.


Передмова
В області захисту від збоїв на кластерах термінологія в Інтернеті відрізняється від сайту до сайту. Для того щоб уникнути плутанини, ми позначимо терміни та визначення, які будуть використовуватися в цій статті.

  • Відмовостійкість (Fault Tolerance, FT) — здатність системи до подальшої роботи після виходу з ладу будь-якого її елемента.
  • Кластер — група серверів (обчислювальних одиниць), об'єднаних каналами зв'язку.
  • Відмовостійкий кластер (Fault Tolerant Cluster, FTC) — кластер, відмову сервера, якій не призводить до повної непрацездатності всього кластера. Завдання вийшла з ладу машини розподіляються між однією або кількома залишилися нодами в автоматичному режимі.
  • Безперервна доступність (Continuous Availability, CA) — користувач може в будь-який момент скористатися сервісом, перерв у наданні послуг не відбувається. Скільки часу пройшло з моменту відмови вузла не має значення.
  • Висока доступність (High Availability, HA) — в разі виходу з ладу вузла користувач якийсь час не буде отримувати послугу, проте відновлення системи відбудеться автоматично; час простою мінімізується.
  • КНД — кластер безперервної доступності, CA-кластер.
  • КВД — кластер високої доступності, HA-кластер.
Нехай потрібно розгорнути кластер з 10 сайтів, де на кожній ноде запускаються віртуальні машини. Стоїть завдання захистити віртуальні машини від збоїв обладнання. Для збільшення обчислювальної щільності стійок прийнято рішення використовувати двопроцесорні сервери.

На перший погляд найбільш привабливий варіант для бізнесу той, коли в разі збою обслуговування користувачів не переривається, тобто кластер безперервної доступності. Без КНД ніяк не обійтися щонайменше у завданнях вже згаданого білінгу абонентів і при автоматизації неперервних виробничих процесів. Однак поряд з позитивними рисами такого підходу є і «підводні камені». Про них наступний розділ статті.

Continuous availability / безперервна доступність
Безперебійне обслуговування клієнта можливо тільки в разі наявності в будь-який момент часу точної копії сервера (фізичної або віртуального), на якому запущений сервіс. Якщо створювати копію вже після відмови обладнання, то на це потрібен час, а значить, буде перебій у наданні послуги. Крім цього, після поломки неможливо буде отримати вміст оперативної пам'яті з проблемною машини, а значить знаходилася там інформація буде втрачена.
Для реалізації CA існує два способи: апаратний і програмний. Розповімо про кожній з них трохи докладніше.

Апаратний спосіб представляє собою «роздвоєний» сервер: всі компоненти дубльовані, а обчислення виконуються одночасно і незалежно. За синхронність відповідає вузол, який в числі іншого звіряє результати з половинок. У разі невідповідності виконується пошук причини і спроба корекції помилки. Якщо помилка не коригується, то несправний модуль відключається.
На Хабре нещодавно була стаття на тему апаратних CA-серверів. Описуваний в матеріалі виробник гарантує, що річне час простою не більше 32 секунд. Так от, для того щоб домогтися таких результатів, треба придбати устаткування. Російський партнер компанії Stratus повідомив, що вартість CA-сервера з двома процесорами на кожен синхронізований модуль становить близько $160 000 в залежності від комплектації. Разом на кластер буде потрібно $1 600 000.

Програмний спосіб.
На момент написання статті найпопулярніший інструмент для розгортання кластера безперервної доступності — vSphere від VMware. Технологія забезпечення Continuous Availability в цьому продукті має назву «Fault Tolerance».

На відміну від апаратного способу даний варіант має обмеження у використанні. Перерахуємо основні:

  • На фізичному хості повинен бути процесор:
    • Intel архітектури Sandy Bridge (або новіше). Avoton не підтримується.
    • AMD Bulldozer (або новіше).

  • Машини, на яких використовується Fault Tolerance, повинні бути об'єднані в 10-гігабітну мережу з низькими затримками. Компанія VMware настійно рекомендує виділену мережу.
  • Не більше 4 віртуальних процесорів на ВМ.
  • Не більше 8 віртуальних процесорів на фізичний хост.
  • Не більше 4 віртуальних машин на фізичний хост.
  • Неможливо використовувати снэпшоты віртуальних машин.
  • Неможливо використовувати Storage vMotion.
Повний список обмежень і несумісності є в офіційній документації.
Експериментально встановлено, що технологія Fault Tolerance від VMware значно «гальмує» віртуальну машину. У ході дослідження vmgu.ru після включення FT продуктивність ВМ при роботі з базою даних впала на 47%.

Ліцензування vSphere прив'язане до фізичних процесорів. Ціна починається з $1750 за ліцензію + $550 за річну передплату і техпідтримку. Також для автоматизації управління кластером потрібно придбати VMware vCenter Server, який коштує від $8000. Оскільки для забезпечення безперервної доступності використовується схема 2N, для того щоб працювали 10 нод з віртуальними машинами, потрібно додатково придбати 10 дублюючих серверів і ліцензії до них. Загальна вартість програмної частини кластера складе 2*(10+10)*(1750+550)+8000=$100 000.

Ми не стали розписувати конкретні конфігурації нсд: склад комплектуючих в серверах завжди залежить від завдань кластера. Мережеве обладнання описувати також не має сенсу: у всіх випадках набір буде однаковим. Тому в даній статті ми вирішили вважати тільки те, що точно буде відрізнятися: вартість ліцензій.

Варто згадати і про тих продуктах, розробка яких зупинилася.

Remus на базі Xen, безкоштовне рішення з відкритим вихідним кодом. Проект використовує технологію микроснэпшотов. На жаль, документація давно не оновлювалася, наприклад, установка описана для Ubuntu 12.10, підтримка якої припинена в 2014 році. І як не дивно, навіть Гугл не знайшов жодної компанії, яка застосувала Remus у своїй діяльності.

Робилися спроби доопрацювання QEMU з метою додати можливість створення continuous availability кластера. На момент написання статті існує два таких проекти.

Перший — Kemari, продукт з відкритим вихідним кодом, яким керує Yoshiaki Tamura. Передбачається використовувати механізми живої міграції QEMU. Однак той факт, що останній комміт був зроблений у лютому 2011 року, говорить про те, що швидше за все розробка зайшла в глухий кут і не відновиться.

Другий — Micro Checkpointing, заснований Michael Hines, теж open source. На жаль, вже рік в репозиторії немає ніякої активності. Схоже, що ситуація склалася аналогічно проекту Kemari.

Таким чином, реалізації continuous availability на базі віртуалізації KVM в даний момент немає.

Отже, практика показує, що незважаючи на переваги систем безперервної доступності, є чимало труднощів при впровадженні та експлуатації таких рішень. Однак існують ситуації, коли відмовостійкість потрібно, але немає жорстких вимог до безперервності сервісу. У таких випадках можна застосувати кластери високої доступності, КВД.

High availability / висока доступність
У контексті КВД відмовостійкість забезпечується за рахунок автоматичного визначення відмови обладнання і подальшого запуску сервісу на справному вузлі кластеру.

В ШВД не виконується синхронізація запущених на ноди процесів і не завжди виконується синхронізація локальних дисків машин. Стало бути, що використовуються вузлами носії повинні бути на окремому незалежне сховище, наприклад, на мережному сховищі даних. Причина очевидна: у разі відмови ноди пропаде зв'язок з нею, а значить, не буде можливості отримати доступ до інформації на її накопичувачі. Природно, що СГД теж має бути резервний, інакше КВД не вийде за визначенням.

Таким чином, кластер високої доступності ділиться на два подкластера:

  • Обчислювальний. До нього відносяться ноди, на яких безпосередньо запущені віртуальні машини
  • Кластер сховища. Тут знаходяться диски, які використовуються нодами обчислювального подкластера.
На даний момент для реалізації КВД з віртуальними машинами на ноди є наступні інструменти:

  • Heartbeat версії 1.х в зв'язці з DRBD;
  • Pacemaker;
  • VMware vSphere;
  • Proxmox VE;
  • XenServer;
  • Openstack;
  • Windows Server Failover Clustering в зв'язці з серверної роллю Hyper-V";
  • VMmanager Cloud.
Познайомимо вас з особливостями нашого продукту VMmanager Cloud.

VMmanager Cloud
Наше рішення VMmanager Cloud використовує віртуалізацію QEMU-KVM. Ми зробили вибір на користь цієї технології, оскільки вона активно розробляється і підтримується, а також дозволяє встановити будь-яку операційну систему на віртуальну машину. В якості інструменту для виявлення відмов кластера використовується Corosync. Якщо виходить з ладу один з серверів, VMmanager розподіляє по черзі працювали на ньому віртуальні машини залишилися нодам.

У спрощеній формі алгоритм такий:

  1. Відбувається пошук вузла кластера з найменшою кількістю віртуальних машин.
  2. Виконується запит вистачає вільної оперативної пам'яті для розміщення поточної ВМ у списку.
  3. Якщо пам'яті для розподіляється машини достатньо, то VMmanager віддає команду на створення віртуальної машини на цьому вузлі.
  4. Якщо пам'яті не вистачає, то виконується пошук на серверах, які несуть на собі більшу кількість віртуальних машин.
Ми провели тестування на багатьох конфігураціях заліза, опитали існуючих користувачів VMmanager Cloud і на підставі отриманих даних зроблено висновок, що для розподілу і відновлення роботи всіх ВМ з відмовив вузла потрібно від 45 до 90 секунд в залежності від продуктивності устаткування.

Практика показує, що краще виділити одну або кілька нод під аварійні ситуації і не розгортати на них ВМ у період штатної роботи. Такий підхід виключає ситуацію, коли на «живих» ноди в кластері не вистачає ресурсів, щоб розмістити всі віртуальні машини з «померлою». У випадку з одним запасним сервером схема резервування носить назву «N+1».

VMmanager Cloud підтримує наступні типи сховищ: файлова система, LVM, Network LVM, iSCSI і Ceph. У контексті КВД використовуються останні три.

При використанні вічної ліцензії вартість програмної частини кластера з десяти «бойових» вузлів та одного резервного складе €3520 або $3865 на сьогоднішній день (ліцензія коштує €320 за ноду незалежно від кількості процесорів на ній). В ліцензію входить рік безкоштовних оновлень, а з другого року вони будуть надаватися в рамках пакета оновлень вартістю €880 в рік за весь кластер.

Розглянемо за якими схемами користувачі VMmanager Cloud реалізовували кластери високої доступності.

FirstByte
Компанія FirstByte почала надавати хмарний хостинг в лютому 2016 року. Спочатку кластер працював під управлінням OpenStack. Однак відсутність доступних фахівців за цією системою (як за наявності, так і за ціною) спонукало до пошуку іншого рішення. До нового інструменту для управління КВД пред'являлися наступні вимоги:

  1. Можливість надання віртуальних машин KVM;
  2. Наявність інтеграції з Ceph;
  3. Наявність інтеграції з білінгом підходящим для надання наявних послуг;
  4. Доступна вартість ліцензій;
  5. Наявність підтримки виробника.
У підсумку найкраще за вимогами підійшов VMmanager Cloud.

Відмінні риси кластера:

  • Передача даних заснована на технології Ethernet і побудована на обладнанні Cisco.
  • За маршрутизацію відповідає Cisco ASR9001; в кластері використовується близько 50000 IPv6 адрес.
  • Швидкість лінка між обчислювальними нодами і комутаторами 10 Гбіт/с
  • Між комутаторами і нодами сховища швидкість обміну даними 20 Гбіт/с, використовується агрегування двох каналів по 10 Гбіт/с
  • Між стійками з нодами сховища є окремий 20-гігабітний лінк, який використовується для реплікації.
  • У вузлах сховища встановлені SAS-диски в зв'язці з SSD-накопичувачами.
  • Тип сховища — RBD.
В загальному вигляді система виглядає так:


Дана конфігурація підходить для хостингу сайтів з високою відвідуваністю, для розміщення ігрових серверів і баз даних з навантаженням від середньої до високої.

FirstVDS
Компанія FirstVDS надає послуги резервний хостингу, запуск продукту відбувся у вересні 2015 року.

До використання VMmanager Cloud компанія прийшла з наступних міркувань:

  1. Великий досвід роботи з продуктами ISPsystem.
  2. Наявність інтеграції з BILLmanager за замовчуванням.
  3. Відмінну якість техпідтримки продуктів.
  4. Підтримка Ceph.
Кластер має такі особливості:

  • Передача даних заснована на мережі Infiniband зі швидкістю з'єднання 56 Гбіт/с;
  • Infiniband-мережа побудована на обладнанні Mellanox;
  • У вузлах сховища встановлені SSD-носії;
  • Використовуваний тип сховища — RBD.
Загальна схема виглядає так:


У разі спільного відмови Infiniband-мережі зв'язок між сховищем дисків ВМ і обчислювальними серверами виконується через Ethernet-мережа, яка розгорнута на обладнанні Juniper. «Підхоплення» відбувається автоматично.

Завдяки високій швидкості взаємодії з сховищем такий кластер підходить для розміщення сайтів з надвисокою відвідуваністю, відеохостингу з потоковим відтворенням контенту, а також для виконання операцій з великими обсягами даних.

Епілог
Підіб'ємо підсумок статті. Якщо кожна секунда простою сервісу приносить значні збитки — не обійтися без кластера безперервної доступності.

Однак якщо обставини дозволяють почекати 5 хвилин, поки віртуальні машини розгортаються на резервній ноде, можна поглянути в бік КВД. Це дасть економію у вартості ліцензій та обладнання.

Крім цього не можемо не нагадати, що єдиний засіб підвищення відмовостійкості — надмірність. Забезпечивши резервування серверів, не забудьте зарезервувати лінії і обладнання передачі даних, канали доступу в Інтернет, електроживлення. Все що тільки можна зарезервувати — резервуйте. Такі заходи виключають єдину точку відмови, тонке місце, з-за несправності в якому припиняє працювати вся система. Прийнявши всі вищеописані заходи, ви отримаєте відмовостійкий кластер, який дійсно важко вивести з ладу.

Якщо ви вирішили, що для ваших завдань більше підходить схема високої доступності і вибрали VMmanager Cloud як інструмент для її реалізації, до ваших послуг інструкція по установці, документация, яка допоможе детально ознайомитися з системою. Бажаємо вам безперебійної роботи!

p.s. Якщо у вас в організації є апаратні CA-сервери — напишіть, будь ласка, в коментарях хто ви і для чого ви їх використовуєте. Нам дійсно цікаво почути для яких проектів використання такого обладнання економічно доцільно :)
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.