Коли справа доходить до промислового рішення, то необхідно вибирати максимально просте, зрозуміле і монолітне рішення ... яке перевірено часом. Тут вже немає місця експериментальним технологій. І, що особливо важливо, завжди грає не малу роль і людський фактор - тобто систему потрібно поставити і навчити людей нею правильно користуватися (в нашому випадку, адмінів). І тут дуже важливо, щоб був нормальний інтерфейс для управління цими справами, тому що багато працювати з «голою» командним рядком просто відмовляться або не зможуть. Також важливі дуже багато вбудовані функції, такі як: відсутність централізованого вузла (стан кворуму), об'єднання серверів в кластер і всі супутні цьому фішки.
У моєму випадку, використовуватися будуть в основному контейнери OpenVZ. але зазвичай виртуалки KVM є більш затребуваною функцією, ніж контейнери (для них ми і будемо намагатися по ходу статті). Але і про контейнери хотілося б замовити слівце ... Я б із задоволенням використав LXC. замість OpenVZ (які є йому, по суті - батьком), але для LXC досі відсутній чіткий веб-інтерфейс (ФОРКОМ LXC Web Panel на github я б дав статус - experimental), а про об'єднання в кластер і мови не йде ... а коли нам потрібно автоматизувати цілий дата-центр, як бути без цього? У чому ж різниця між OpenVZ і LXC. Хм, та за великим рахунком це одне і теж, то й говорити про код. По суті, різниця лише в тому, що OpenVZ використовує своє пропатчені ядро 2.6 (з включеними всіма патчами з безпеки, свіжим KVM і дровами), а LXC включений в апстріп, тобто в ванільне ядро починаючи з 3.8. І як би з часом, очевидно що він буде ще сильніше допив, і «видавить» OpenVZ. Але на даний момент, OpenVZ в складі Proxmox виглядає більш готовим і завершеним рішенням (розробники Proxmox обіцяють в майбутніх релізах замінити OpenVZ на LXC. Коли вони будуть рівносильні по функціональності).
До речі ... дивно, але щодо Proxmox в рунеті я практично не знайшов ніякої документації російською мовою. Все тільки на буружуйскіх офф.доках і форумах. Так що, цей мануал повинен бути досить корисний для громадськості :)
Гаразд, вистачить демагогії. поїхали встановлювати і налаштовувати наш десятеро на Ноди!
Практика показує. різні кластера повинні бути в різних подсетях, щоб не заважати один одному (приклад: один кластер в 1.1.1.X, другий в 1.1.2.X, маска і шлюз скрізь однакові).
Після поновлення, перевірте дату і час на відповідність з реальним станом справ.
Якщо час не відповідає, поправте його (опціонально):
де:
MM - місяць
DD - день
hh - годину
mm - хвилини
YYYY - рік
ss - секунди
Після цього, настройка Ноди вважається закінченою. Налаштуйте всі інші Ноди і тільки потім об'єднуйте їх в кластер.
Спочатку, на першій ноді потрібно створити кластер. Це робиться одноразово.
3.1) Створення кластера
Тут же можна задати ім'я кластера (надалі змінити його буде не можна):
Перевірити статус кластера:
Усе! Далі потрібно тільки додавати в нього вже налаштовані Ноди.
3.2) Додавання нод в кластер
Щоб додати Ноди в кластер, виконайте команду (виконувати команди потрібно на самій додається ноді):
При додаванні вас попросять прийняти RSA-ключ (потрібно буде ввести «yes» коли запитають) і ввести пароль від рута тієї Ноди, з якої ми єднаємося.
Перевірити статус кластера:
Практика показує. всі ноди кластера краще прописати всіх серверів кластера в / etc / hosts для надійності.
3.3) Видалення Ноди з кластера
Цей пункт вимагає особливої уваги, якщо тут накосячіть - можна зламати весь кластер. Значить так, спочатку потрібно прибрати все ВМ з видаляється Ноди (перенести їх на інший сервера або видалити зовсім). Після, потрібно вимкнути цю ноду і фізично відключити її з мережі (важливо: переконайтеся, що в поточному її стані вона більше ніколи не з'явиться в мережі!)
Перевірити кількість нод:
Що видалить ноду з кластера. Все, більше доп. дій не потрібно.
Перевірити кількість нод ще раз:
Якщо потім цю ноду потрібно буде повернути в кластер, то на ній потрібно повністю під чисту перевстановити Proxmox + дати їй нове ім'я і новий IP = ввести її в кластер як нову (див. Пункт 3.2).
Ноди налаштовані і готові, об'єднані в кластер .... саме час підключити сховище. Тут ми розглянемо типовий приклад використовуваний нами, підключення сховища до серверів безпосередньо через Fibre Channel. Основна настройка, звичайно ж, відбувається з самим сховищем. У нашому випадку це буде IBM Chassis C4A (на 24 SAS диска IBM, 22 з яких об'єднані в RAID6). Його потрібно налаштувати «як завжди» (це тема для окремої статті). Після підключити його до вже готовим Нодаме. Особливість роботи з сховищем, підключеного через LVM. на ньому можна розмістити тільки диски віртуалок KVM (і тільки в форматі raw), але ніяк не файли контейнерів OpenVZ.
Відповідь має бути приблизно таким:
В умовах з одним рідним рейдом, повинні бути тільки диска sda1,2,3 ... Перезавантажуємо наші сервера по черзі. Коли на всіх серверах з'явиться новий пристрій sdb. можна приступати до діагностики. або відразу до підключення сховища. Зовнішнє сховище, підключений через LVM може використовувати тільки raw формат дисків для VM.
4.1) Діагностика (опціонально)
Опишемо, як варто проводити діагностику того, що сховище «зачепилося» і система його бачить. Ця дія не є обов'язковим, а в разі виконання - його досить виконати тільки на одній ноді.
Відповідь має бути приблизно таким:
Після перезавантаження, там повинно з'явиться це самий пристрій sdb. Це і є наше сховище. Хочете переконається в цьому на 100%? Ок, поїхали!
Перевірюємо, що система бачить контролер Fibre Channel і дрова на нього встали.
Відповідь має бути приблизно таким:
Це добре. Далі, встановимо необхідні нам тулзи для діагностики:
Скануємо на пошук нових пристроїв:
Відповідь має бути приблизно таким:
А тепер ми переконуємося, що наше сховище відповідає саме букві sdb:
Відповідь має бути приблизно таким:
Перевіряємо ще раз і переконуємося, що все на місці.
На цьому діагностика завершена. Можна приступати до створення LVM і підключенню його до Proxmox VE.
4.2) Створення LVM
LVM - особлива технологія зберігання в Linux, завдяки якій ми зможемо забезпечити живу міграцію машин з Ноди на ноду. Разом, все це працює подібно VMware vMotion. Її настройка дуже проста :) Все пункти робляться тільки один раз, при первинному підключенні сховища в кластеру.
Позначаємо те sdb як пристрій LVM (особливу увагу. Небезпека втрати даних на sdb. Ви повинні чітко розуміти, що робите ...):
Створюємо на пристрої sdb групу, під назвою «ibm»:
Усе! Всі настройки автоматично синхронізуються з усім кластером. Далі, просто заходимо в веб-інтерфейс і «пристібаємо» наш LVM.
Datacenter >>> Storage >>> Add >> LVM в графі «Volume Group» вибираємо ibm.
Усе! Сховище успішно додано і актуалізувалося на всіх позначених вами нодах.
Multipath - технологія підключення вузлів мережі зберігання даних з використанням декількох маршрутів. В нашій конфігурації використовується 2 FC контролера з боку сервера + 2 FC контролера з боку сервера сховища + SAN-світч. Разом виходить, що сховище видно по 4-м каналах. Підключення сховища через multipath забезпечує агрегацію каналів і їх резервування, на рівні ядра системи. Це збільшує швидкість, а в разі відмов - непомітно для користувача використовує доп. канали. Щоб ви розуміли, сама технологія є частиною ядра Linux, і в більшості випадків (на нормальному залозі) вся конфігурація визначається автоматично. Отже, встановимо тулзи:
Проведіть діагностику, як це показано в п.4.1. Перевірити id кожного диска можна командою:
У нашому випадку конфіг визначився автоматично. Загальна картина у нас така (при підключенні тільки одного сховища до SAN-свічу):
sdb, sdc, sdd, sde - наше сховище і його 4-ре каналу.
Перевіряємо, автоопределілся чи multipath:
Більш повна інформація виводиться командою:
Як ми бачимо, сховище підключено 4-ма каналами. Але ключовим параметром тут є id: 360080e50003e2c4c000003b555000a25, а додатковим: dm-2 (це тимчасове ім'я сховища). Так ось, монтується в систему воно потім в будь-якому випадку по id автоматично, а ім'я нам буде потрібно для створення LVM в п.4.2.
На це ім'я ми і створюємо LVM:
Усе! Далі, сховище залишилося активувати через веб-інтерфейс, як уже було показано вище.
Це, мабуть, найскладніша частина. За замовчуванням VM працюють в класичному режимі: розміщені на сервері, але якщо сервер стає недоступним, то все VM стають недоступні разом з ним. У режимі ж HA, відбувається наступне: в разі відмови сервера, все його VM автоматично переїжджають на інший сервер (а) кластера. HA налаштовується просто, через веб-GUI. Однак, однією з вимог роботи HA (на додаток до high-end обладнання та спільному сховища) є наявність апаратного Fencing -Пристрої для кожного сервера (щоб уникнути одночасного помилкового доступу до даних VM з декількох серверів, це називається «split-brain condition» і може привезти до «data corruption»). Саме цим і важливий Fencing. він виконує роль вишибали - фізично блокує доступ сервера до даних VM (закриває SAN порти, відключає від мережі або від живлення, або просто перезавантажує сервер). Апаратний Fencing - є найбільш ефективним і стабільним рішенням. Приклади таких пристроїв: APC річки, SAN свитчи. і сервіси типу HP iLO. У нашому випадку, ми будемо використовувати утиліту HP ILO. яка вшита в наші сервера HP DL360 Gen9. Вона ідеально підходить для цієї ролі. Підключіть і налаштуйте iLO на сервері, задайте йому пароль і налаштуйте доступ. Після, продовжуємо:
6.1) Fencing
Налаштування відбувається повністю через консоль і конфіги. Морально приготуйтеся. Більш того, під кожне Fencing -обладнання будуть свої, особливі конфіги. Насамперед, треба активувати програмний Fencing -домен і об'єднати в нього все сервера кластера (дані операції виконати на всіх серверах). Для це потрібно раскоментіть рядок (FENCE_JOIN = "yes") в цьому конфіги:
Перевіряємо і додаємо сервер в Fencing-домен:
Після цього у сервера може відбутися втрата синхронізації з кластером. Необхідно тепер перезапустити головний сервіс:
Далі, встановлюємо тулзи для зв'язку з HP iLO з ОС за допомогою інтерфейсу IPMI:
Запуск і перезапуск сервісу:
Очевидно, що він буде ругатся ... для роботи IPMI необхідно активувати доп.модулі ядра системи:
Зробимо так, щоб вони активувалися автоматично після ребута ОС (поправити конфиг і вставити туди след.значенія):
У 1-му випадку повинен з'явиться девайс ipmidev, а в другому вихлоп буде схожий на це:
Перевіряємо Fencing. Ці команди роблять приблизно одне і теж (1-2 перевіряють статус, 3 - відправляє в ребут ... логін і пароль від iLO):
Щоб не палити пароль в конфіги безпосередньо (в т.ч. веб-GUI), напишемо найпростіший скрипт:
Все, після того, як зазначені операції будуть виконані на всіх серверах кластера - ми переходимо до найважливішою і відповідальною речі ... правці основного конфіга кластера. Потрібно діяти дуже акуратно і уважно. Запам'ятайте, після кожної правки конфіга - необхідно там же і збільшувати його версію на 1 (параметр config_version = ..). Створюємо новий тимчасовий конфиг:
Ось повністю робочий конфіг кластера 'cluster', який був написаний мною вручну: cluster_test1_ilo4
Виглядає це так:
А тепер перевіряємо роботу Fencing -Пристрої (з будь-якого сервера кластера) і відправляємо цю ноду в ребут:
Усе! Більше редагувати конфіги не доведеться, все подальші дії проводяться через веб-GUI.
Сервіс HA потрібно включати для кожної окремої VM. Увага: перед включенням HA переконайтеся, що дана VM вимкнена.
Так виглядає статус VM без HA:
Додаємо VM в HA:
Новий статус VM з HA:
Усе! Не забувайте підключати нові VM в HA.
Якщо сховища немає, то сервера і раніше можуть бути частиною кластера - тільки при цьому вони будуть використовувати тільки свою дискову підсистему. Їх перевагою є те, що такі сервера можуть використовувати як контейнери OpenVZ. так і віртуальні машини KVM. Диски віртуальних машин можуть бути в декількох форматах. Особливості форматів дисків:
- найкраща продуктивність
- резервує місце під виртуалку повністю (фіксований диск)
- можливість робити snapshot (в т.ч. «живі»)
- резервує місце під виртуалку НЕ повністю (динамічний диск)
- повна сумісність з VMware
- резервує місце під виртуалку НЕ повністю (динамічний диск)
Файли контейнерів OpenVZ зберігаються на самій ноді тут: / var / lib / vz / private / ID (де ID - айди конейнера в веб-інтерфейсі)
Коротко. контейнери рекомендуються до використання, якщо мова йде про ноді без підключеного до неї сховища і гостьовий linux системі. Колосальна економія ресурсів + розширення диска / пам'яті «на льоту».
Щоб зайти в контейнер, потрібно з Ноди виконати команду (де 109 - ID виртуалки):
Все, потім налаштовуйте ОС як вам треба, встановлюєте весь софт (все як на звичайній виртуалке). Коли ви повністю налаштуєте контейнер, давайте зробимо з нього шаблон ... потім вже з цього шаблону можна розплодити цілу купу контейнерів. Перш ніж приступити, натисніть Shutdown в веб-інтерфейсі і повністю погасите потрібний вам контейнер. Потім, через веб-інтерфейс повністю видаліть мережевий інтерфейс контейнера:
Точка в кінці рядка важлива, не чіпайте її!
Все, новий шаблон для контейнерів готовий до роботи. Він з'явиться в веб-інтерфейсі Proxmox.
В процесі експлуатації ніяких питань виникнути не повинно, все дуже логічно і інтуїтивно зрозуміло. При логін в систему, можна навіть включити російську мову в інтерфейсі. Системою підтримується жива міграція і живі бекапи, так що віртуальні машини можна вільно переміщувати між нодамі у включеному стані + робити їх бекапи. Можна завантажити в локальні сховища нодов дистрибутиви систем в .iso - що потім робить більш комфортним створення нових віртуальних машин.
Користуйтеся із задоволенням!)