Безкоштовний кластер (Proxmox + Nexenta)

Напевно багато хто з нас, вирішуючи завдання організації невеликої IT-інфраструктури, стикалися з проблемою вибору гіпервізора. Яким функціоналом повинен володіти софт і скільки за це варто платити? А чи та, чи інша частина рішення сумісна з тим, що вже є?
І як би, все це поганяти на стенді, щоб переконатися в правильності вибору?
З урахуванням курсу однієї, відомої всім валюти, хочеться чогось простого, без надмірностей і, по можливості, безкоштовного. Тим більше, коли мова йде про малу або середньої компанії (стартапі), обмеженою в бюджеті.

Що нам потрібно?
image

  • Сумісний з устаткуванням гіпервізор
  • Кластер, з доступом до адмінки через веб-інтерфейс
  • High Availability для віртуальних машин в кластері
  • Функція бекапа і відновлення з коробки
  • Доступність для розуміння і роботи середньому адміністратора (вчорашньому школяреві-студенту).
З Open-Source рішень, найбільш простим в установці і налаштуванні є Proxmox. Щоб не ображати любителів oVirt тощо (це не рекламна стаття), зазначу, що початкове вимога до простоти установки і адміністрування, на мій погляд, у Proxmox все ж більш виражено. Також, повторюся, у нас не ЦОД, а всього лише кластер з 2-3-х нсд для невеликої компанії.
Як гіпервізора він використовує KVM і LXC, відповідно тримає KVM ОС (Linux, *BSD, Windows та інші) з мінімальними втратами продуктивності і Linux без втрат.

Отже, поїхали:
Установка гіпервізора найпростіша, качаємо його звідси:
Інсталюється буквально в кілька кліків і пароля адміна.
Після чого, нам видається вікно консолі з адресою веб-інтерфейсу виду
172.16.2.150:8006
(тут і далі адресація тестової мережі).
Далі, встановлюємо другу і третю ноди, з аналогічним результатом.

Запускаємо кластер:
1. Налаштовуємо hosts на pve1.local:
root@pve1:~# nano /etc/hosts
127.0.0.1 localhost.localdomain localhost
172.16.2.170 pve1.local pve1 pvelocalhost
172.16.2.171 pve2.local pve2

2. Налаштовуємо hosts на pve2.local:
root@pve2:~# nano /etc/hosts
127.0.0.1 localhost.localdomain localhost
172.16.2.171 pve2.local pve2 pvelocalhost
172.16.2.170 pve1.local pve1

3. За аналогією налаштовуємо hosts на pve3.local
4. На сервері pve1.local виконуємо:
root@pve1:~# pvecm create cluster

5. На сервері pve2.local виконуємо:
root@pve2:~# pvecm add pve1

6. Точно так само, налаштовуємо і додаємо в кластер третій хост pve3.local.

Оновлюємо всі ноди:
Приводимо у відповідність репозиторій:
root@pve1:~# nano /etc/apt/sources.list
deb http://ftp.debian.org.ru/debian jessie main contrib
# PVE pve-no-subscription repository provided by proxmox.com, NOT recommended for production use
deb http://download.proxmox.com/debian jessie pve-no-subscription
# security updates
deb http://security.debian.org/ jessie/updates main contrib


Коментуємо непотрібний репозиторій:
root@pve1:~# nano /etc/apt/sources.list.d/pve-enterprise.list
# deb https://enterprise.proxmox.com/debian jessie pve-enterprise

І оновлюємося (на кожній ноде відповідно):
root@pve1:~# apt-get update && apt-get dist-upgrade

Все, кластер готовий до бою!

image

Тут, ми вже з коробки маємо функцію бекапа (називається резервування), що підкуповує практично відразу ж!

Сховищі:
Далі, виникає питання вибору спільного сховища.
Вибираємо ISCSI (як найбільш бюджетний варіант) Storage:
В принципі, при настроюванні можна обмежитися одним інтерфейсом, однак у кластері не можна мати одну точку відмови, тому краще використовувати multipath від Proxmox, або об'єднання інтерфейсів від самої хранилки.

Тут, можна взяти якесь комерційне сховище, дискову полку та ін
Власне, перший тест проводився як раз разом з рішенням від Infortrend.

Але знову ж таки, що робити, якщо бюджет обмежений просто донезмоги (або його просто немає)?!
Найпростіше, набити дисками те залізо, що є, і зробити з нього сховище, що дозволяє досягти поставлених цілей.
У підсумку, нам необхідні можливості (з урахуванням того, що компанія може різко розширитися):

  • Unified storage: NAS/SAN
  • iSCSI target functionality
  • CIFS, NFS, FTP, HTTP Protocols
  • RAID 0,1,5,6,10 support
  • Bare metal or virtualization installation
  • 8TB+ Journaled filesystems
  • Filesystem Access Control Lists
  • Point In Time Copy (snapshots) support
  • Dynamic volume manager
  • Powerful web-based management
  • Block level remote replication
  • High Availability clustering
  • Основні функції повинні бути присутніми в Open-Cource/Community версії.
Після деяких мук вибору, залишилися OpenFiler і NexentaStor.
Хотілося б, звичайно, використовувати Starwind або FreeNAS NAS4Free), але якщо для роботи потрібен Windows і шаманство з ISCSI, то в іншого функція кластеризації не передбачена взагалі.
OpenFiler на жаль, має мізерний GUI і остання версія у нього від 2011 року. Так що залишається NexentaStor.
У неї, звичайно ж, схема роботи active-active у кластері Nexenta вже платна, якщо вам такий знадобиться в подальшому. Також якщо у сховищі 2 ноди (контролера) підтримка другого теж за гроші! Власне, всі плагіни доступні лише в Enterprise версії.
Однак те, що доступно в Community версії, покриває більшість початкових потреб. Це і 18ТБ обсягу сховища, і ZFS з снэпшотами, і можливість реплікації з коробки!

Установка NexentaStor Community Edition:
Насамперед, необхідно вивчити Compatibility List.
Дистрибутив качаємо звідси (знадобиться реєстрація, щоб отримати ключ для установки).
Процедура установки проста, наскільки це можливо, в її процесі налаштовуємо IP-адресу з портом для установки в GUI.
Далі, послідовно переходячи по запитам візарда, задаємо в GUI пароль і масив (у Nexenta він називається Volume).
Далі йдемо в розділ SCSI Target і послідовно створюємо:
  1. Target Portal Groups
  2. Targets
  3. Remote Initiators — для кожної ноди:
image

Далі, відповідно до мануалом:
root@pve1:~# mkdir /etc/pve/priv/zfs
root@pve1:~# ssh-keygen -f /etc/pve/priv/zfs/172.16.2.150_id_rsa
root@pve1:~# ssh-copy-id -i /etc/pve/priv/zfs/192.16.2.150_id_rsa.pub root@172.16.2.150

Копіюємо ключ на кожну ноду:
root@pve1:~# ssh -i /etc/pve/priv/zfs/172.16.2.150_id_rsa root@172.16.2.150

Підчепити ISCSI сховище в Proxmox, можна двома способами:
Через меню ISCSI в додаванні сховища (доведеться створювати додатковий LVM) — див.мануал.
Через меню ZFS over ISCSI — див.мануал.
Ми підемо другим шляхом, так як він дає нам можливість створення і зберігання снэпшотов. Також, це може робити і Nexenta.
Процес налаштування в GUI виглядає ось так:

image

У підсумку виходить:

image

При налаштуванні не переплутайте ім'я пулу (в nexenta він аналогічний Datastore):

root@nexenta:~# zpool status
pool: volume1
state: ONLINE
scan: none requested
config:

NAME STATE READ WRITE CKSUM
volume1 ONLINE 0 0 0
c0t1d0 ONLINE 0 0 0
errors: No known data errors

Тепер ми можемо вибирати, як і що бэкапить.
Можемо зробити автоматичний бекап VM на віддалене сховище прямо з Proxmox:
Тобто заходимо у вкладку «Сховище» і додаємо NFS-масив. Це може бути як звичайна NAS-хранилка, так і xNIX-сервер з папкою доступною через NFS (кому що зручніше). Потім, вказуємо вміст (backup).

Або ж, можна зробити реплікацію засобами Nexenta:
Реалізується в GUI вкладками Data Management -> Auto Services -> Auto-Tier Services -> Create.
Тут ми маємо на увазі віддалене сховище (або просто Linux-машина) із запущеною службою Rsync. Тому, перед цим необхідно створити зв'язок між хостами.
Вкладки Settings -> Network -> SSH-bind допомагають підняти коннект.

Налаштування HA:
Повністю настроюється через GUI.
  1. Виділяємо Датацентр, натискаємо вкладку HA зверху.
  2. Тиснемо Групи знизу і створюємо групу з хостів, на які може мігрувати VM.
  3. Далі тиснемо Ресурси і там додаємо VM, яку ми хочемо.
Можна також подивитися статус в консолі:
root@pve1:~# ha-manager status
quorum OK
master pve1 (active, Sun Mar 20 14:55:59 2016)
lrm pve1 (active, Sun Mar 20 14:56:02 2016)
lrm pve2 (active, Sun Mar 20 14:56:06 2016)
service vm:100 (pve1, started)

Тепер перевіримо працездатність кластера.
Встановлюємо VM, з Windows, з диском в загальному сховищі, і пробуємо міграцію вручну:



Працює!
Чудово, тепер перевіряємо його відмовостійкість, вимикаємо сервер через IPMI. Чекаємо переїзду. Машина автоматично мігрує через півтори хвилини.
В чому проблема? Тут необхідно розуміти, що механізм fencing у версії 4.х змінився. Тобто зараз працює Whatchdog fencing, який не має активної підтримки обладнання. Буде виправлено у версії 4.2.

Висновок
Отже, що ж ми отримали в результаті?
А отримали ми Production-ready кластер, що підтримує більшість ОС, з простим інтерфейсом управління, можливістю разового резервування даних (це і сам Proxmox і Nexentastor з снэпшотами та реплікацією).
Плюс до всього, ми завжди маємо можливості масштабування і додавання функцій, як з боку Proxmox, так і з боку Nexenta (в цьому випадку доведеться таки придбати ліцензію).
І все це абсолютно безкоштовно!
На мою думку, налаштування всього цього не вимагає ні особливих тимчасових витрат, ні детального вивчення різноманітних мінлива.
Звичайно ж, без деяких грабель не обходиться, тут порівняння з ESXi + VMWare vCenter буде на користь останнього. Однак, завжди можна поставити запитання на форумі підтримки!
У результаті, майже 100% функціоналу, найчастіше використовуваного адміном невеликого проекту (компанії), ми отримали відразу з коробки. Тому, рекомендую кожному задуматися, а чи варто витрачатися на зайві можливості, лише б вони були ліцензовані?

P. S. У вищеописаному експерименті використовувалося обладнання:

4 х Сервера STSS Flagman RX237.4-016LH у складі:
  • X9DRi-LN4F+
  • 2 х Xeon E5-2609
  • 8 х 4GB DDR-III ECC
  • ASR-6805 + FBWC
Три сервера з чотирьох використовувалися як ноди, один — був забитий 2ТБ-дисками і використовувався в якості хранилки.

У першому експерименті в якості NAS використовувалася готова СГД Infortrend EonNAS 3016R

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

Спасибі за увагу, чекаю Ваших коментарів!

Джерело: Хабрахабр

0 коментарів

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