Кластер віртуалізації

Архів номерів / 2014 / Випуск №11 (144) / Кластер віртуалізації. Частина 1. Розгортаємо бюджетне відмовостійке рішення

Рубрика: Адміністрація / Віртуалізація

СЕРГІЙ УРУШКІН, системний адміністратор ІТЦ Телрос, [email protected]

Кластер віртуалізації. Частина 1 Розгортаємо бюджетне відмовостійке рішення

Підбір програмного та апаратного забезпечення та початкове налаштування кластера

У бізнесі часто виникають завдання, які потребують високої доступності сервісів та даних. На сьогоднішній день такі завдання найефективніше вирішуються з використанням віртуалізації, приватних чи публічних хмар. Для малого та середнього бізнесу щомісячні витрати на публічну хмару часом виявляються зависокими. У той же час, розгортання приватної хмари вимагає великих одноразових вкладень як у програмне забезпечення (ПЗ) (VMware, Citrix, Microsoft), так і в апаратну частину (брендові сервери, СГД, мережеве обладнання).

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

Так як кластер бюджетний, обходимося без SAN, Fibre Channel і т.п. Пропонується використовувати два сервери (вузла), у кожного дві мережеві карти. Одна забезпечує зв'язок вузлів та віртуальних машин (ВМ) із зовнішнім світом,друга – приватна мережа між вузлами обмінюватись даними кластера. Всі дані ВМ синхронізуватимуться між вузлами в реальному часі, стане можлива жива міграція ВМ з одного вузла на інший. Під час падіння одного вузла всі ВМ, запущені на ньому, автоматично запускаються на іншому вузлі.

Для розуміння подальшого матеріалу, читачеві необхідні такі навички:

знання складових частин та принципів роботи апаратної архітектури x86 та периферійних пристроїв;
розуміння семирівневої моделі OSI, принципів побудови та маршрутизації мереж TCP/IP, технології VLAN;
розуміння термінів: віртуальний хост, віртуальна машина, гіпервізор, RAID, файлова система (ФС), LVM, пакетний менеджер, кластер;
вміння працювати з командним рядком Linux лише на рівні адміністратора.

Використовуватиметься наступне вільне ПЗ:

Гіпервізор: KVM. Чому не XEN? Просто досвід роботи більше з KVM, а на даний момент важливих відмінностей по функціональності практично немає.
Менеджер ВМ: libvirt. Має багату функціональність і широко використовується в різних проектах хмарного ПЗ, наприклад, OpenStack.
Зберігання даних: DRBD + DLM + CLVM + GFS2. DRBD – реалізація мережевого RAID1 для Linux, що забезпечує синхронізацію даних на вузлах. DLM – розподілений менеджер блокування. CLVM – менеджер томів із підтримкою кластеризації. GFS2 – кластерна ФС. Для максимальної продуктивності образи ВМ зберігатимуться як томи LVM. За такої схеми продуктивність ФС не важлива, GFS2 тут цілком підходить. Інші компоненти практично не мають альтернатив.
Менеджер кластера: Corosync + Pacemaker. Це основна зв'язка, яка використовується у сучасних дистрибутивах.
ОС: CentOS 7.0. Спочатку схема була розгорнута на Ubuntu 14.04, але при тестуванні стійкості до відмови спостерігалися проблеми на зв'язці Corosync + Pacemaker. У результаті було обрано CentOS. Це, по суті, RHEL, а якщо судити з багтрекерів, саме в Red Hat кластерне ПЗ обкатується особливо активно. До того ж у RHEL періодично інтегрується нова функціональність KVM/libvirt.

За основу було взято побутові PC на Intel i7. Коротко конфігурації:

Материнська плата – два слоти PCIEx16 (або x8). Чому див. нижче.
CPU, RAM - за вашими потребами. Головне - розуміти, що, якщо один вузлів вийде з ладу, на решті має вистачити ресурсів, щоб запустити всі ВМ-кластери.
Апаратний RAID з батареєю (BBU). При використанні DRBD найпростіший спосіб забезпечити високу швидкість та чуйність запису при збереженні надійності – BBU. Якщо швидкості побутового HDD для завдань достатньо, можна використовувати програмне дзеркало md-raid. У результаті при побудові кластера використовувався LSI Nytro 8100-4i + LSI00355 та 4 SATA HDD розміром 3 Tб, зібрані у RAID-10. SSD-кеш та BBU забезпечать високу чуйність, а HDD – великий обсяг. Контролер займає один слот PCIEx8 (x16 також підійде).
Мережеві карти. Потрібно як мінімум дві. Одна для управління та ВМ. У разі вбудована в материнську плату гігабітна карта. У другий мережевий карти завдання забезпечити синхронізацію даних між вузлами з мінімальними накладними витратами пропускну здатність і чуйності, тобто. продуктивність передачі не меншу, ніж в дискового масиву. Знову ж таки для побутового HDD досить гігабітної мережевої карти. Для обраного RAID було взято 2x10Gbps Intel E10G42BTDA + 2 кабелі XDACBL1M,займає другий слот PCIEx8 (x16).
STONITH. У відмовостійкому кластері при недоступності одного з вузлів необхідно забезпечити fencing/STONITH – екстрене вимкнення збійного вузла. Це обов'язкова частина кластеру. Без цього існує ризик втратити дані. Механізми бувають різні: IPMI, PDU та інші. В даному випадку використовувався PDU EG-PDU-002 (розподільник живлення з віддаленим керуванням). Цей бюджетний варіант цілком підходить для кластера із двох вузлів. Однак, якщо планується масштабувати кластер і є зайві кошти, краще взяти PDU серйозніше, наприклад APC. Якщо ж є серверне обладнання, можна використовувати модулі IPMI.
SWITCH. Комутатор мережі/маршрутизатор для з'єднання вузлів і ВМ зі світом. З міркувань безпеки слід використовувати комутатор з підтримкою VLAN, хоча в принципі можливий варіант без окремих VLAN. В описі використовується комутатор компанії Сisco.
UPS – кероване джерело безперебійного живлення.

Отже, приблизна вартість сервера з наведених вище компонентів із 32 Гб оперативної пам'яті – 110 000 руб., PDU – 10 000 руб. ДБЖ та комутатор не вважаємо, т.к. ці компоненти необхідні використання будь-якого сервера. ПЗ безкоштовне. Разом - 230 000 руб. Це можна порівняти з вартістю одного брендового сервера аналогічної продуктивності, але у разі кластера є 100% резерв.

Мережеві системи зберігання даних (СГД) забезпечують високу надійність та продуктивність, але одна така система коштуватиме не менших коштів. Адже до СГД потрібні ще й окремі обчислювальні вузли. Виходячи з цього можна вважати реалізований кластер бюджетним, відмовостійким і таким, що забезпечує продуктивність введення-виведення, близьку до продуктивностілокальних дискових масивів

Основний мінус побутового обладнання – обмежена кількість оперативної пам'яті. Якщо ваші навантаження вимагають (або можуть незабаром вимагати) більшого, ніж 32 Гб, обсягу пам'яті або інших ресурсів, слід дивитися у бік серверного обладнання. Кластерне програмне забезпечення працюватиме ефективно на будь-яких потужностях.

PDF-версію цього номера можна придбати у нашому магазині.