Всім привіт. Ця стаття написана для тих, хто досі кидається між вибором платформ віртуалізації і після прочитання статті із серії «Поставили proxmox і взагалі все чудово, 6 років аптайм не єдиного розриву». Але після встановлення того чи іншого коробкового рішення, виникає питання, а як би тут підправити і тут, щоб моніторинг був зрозуміліший і ось тут, щоб контролювати бекапи. А потім приходить час і ви розумієте, що хочеться чогось більш функціонального, ну або хочеться щоб усередині вашої системи стало все зрозуміло, а не цей чорний ящик або хочеться використовувати щось більше, ніж гіпервізор і купа віртуальних машин. У цій статті буде трохи роздумів та практика на основі платформи Opennebula - вибрав т.к. не вимоглива до ресурсів та архітектура не така складна.
І так, як бачимо багато хмарних провайдерів працюють на kvm і роблять зовнішню обв'язку для керування машинами. Зрозуміло, що великі хостери пишуть свої обв'язки для хмарної інфраструктури, той же YANDEX наприклад. Хтось використовує openstack і робить обв'язку на цій основі - SELECTEL, MAIL.RU. Але якщо у вас є своє залізо та невеликий штат фахівців, то зазвичай вибирають щось із готового – VMWARE, HYPER-V, є безкоштовні ліцензії та платні, але зараз не про це. Поговоримо про ентузіастів — це ті, хто не боїться запропонувати й спробувати нове, незважаючи на те, що в компанії явно дали зрозуміти «Хто це потім буде після тебе обслуговувати», «А ми це чи згодом потім викотимо? Страшно. Але можна спершу застосовувати ці рішення в умовах тестового стенду і якщо всім сподобається, то можна порушити питання про подальший розвиток і використання в більш серйозних середовищах.
Також ось посилання на доповідь від активного учасника розвитку цієї платформи.
Можливо в цій статті щось буде зайве і вже зрозуміло досвідченому фахівцю, а в деяких випадках не описуватиму всі т. к. подібні команди і опис є в мережі. Тут тільки мій досвід роботи з цією платформою. Сподіваюся, активні учасники доповнять у коментарях, що можна зробити краще і яких я припустився помилок. Всі дії були в умовах домашнього стенду, що складаються з 3х ПК з різними характеристиками. Також я спеціально не став вказувати як працює цей софт і як встановлювати. Ні, лише досвід адміністрування та проблеми з якими зіткнувся. Можливо комусь це знадобиться у виборі.
І так, приступимо. Мені як системному адміністратору важливі такі пункти, без яких я навряд чи використовуватиму це рішення.
1. Повторюваність установки
Є купа інструкцій із встановлення opennebula, тут не повинно виникнути проблем. Від версії до версії з'являються нові фічі, які не завжди зможуть заробити під час переходу від версії до версії.
2. Моніторинг
Моніторитимемо саму ноду, kvm і opennebula. Благо, вже є готове. Про моніторинг linux хостів є маса варіантів, той же заббікс або node exporter - кому що більше подобається - на даний момент визначаю так, що моніторинг системних метрик (температура там де вона може вимірюватися, консистентність дискового масиву), через zabbix, а то що стосується програм через експортер в прометей. За моніторингом kvm, наприклад, можна взяти проект і поставити запуск через systemd, добре працює і показує метрики kvm, також є готовий dashboard .
Наприклад, ось мій файл:
/etc/systemd/system/libvirtd_exporter.service
[Unit]
Description=Node Exporter
[Service]
User=node_exporter
ExecStart=/usr/sbin/prometheus-libvirt-exporter --web.listen-address=":9101"
[Install]
WantedBy=multi-user.targetІ так у нас 1 експортер, треба другий для моніторингу самої opennebula, використав такий
Можна додати до звичайного для моніторингу системи таке.
У файлі node_exporter змінюємо старт таким чином:
ExecStart=/usr/sbin/node_exporter --web.listen-address=":9102" --collector.textfile.directory=/var/lib/opennebula_exporter/textfile_collectorСтворюємо директорію mkdir -p /var/lib/opennebula_exporter
bash скрипт представлений вище спочатку перевіряємо роботу через консоль, якщо показує те, що треба (якщо видає помилку, то ставимо xmlstarlet), копіюємо його в /usr/local/bin/opennebula_exporter.sh
Додаємо в крон завдання на кожну хвилину:
*/1 * * * * (/usr/local/bin/opennebula_exporter.sh > /var/lib/opennebula_exporter/textfile_collector/opennebula.prom)Метрики стали з'являтися, можна забирати їх прометеєм та будувати графіки та робити алерти. У графані можна намалювати наприклад такий простий дашборд.
(мабуть що тут я зробив overcommit cpu, ram)
Для тих, хто любить і використовує заббікс, є
Щодо моніторингу все, головне він є. Звичайно можна на додаток використовуючи вбудовані засоби моніторингу віртуальних машин і вивантажувати дані в білінг, тут у всіх своє бачення, поки щільніше до цього не брався.
До логування поки особливо не приступав. Як найпростіший варіант це додати td-agent на парсинг директорії /var/lib/one з регулярними виразами. Наприклад, файлик sunstone.log підходить під regexp nginx та інші файли, які показують історію звернень з платформою - який у цьому плюс? Ну, наприклад, ми можемо явно відстежувати кількість «Error, error» і швидше відстежити, де і на якому рівні є несправність.
3. Резервні копії
Є також платні допиляні проекти - наприклад, sep :OpenNebula_Backup. Тут ми повинні розуміти, що просто бекапит образ машини, в даному випадку зовсім не те, адже наші віртуальні машини повинні працювати з повною інтеграцією (той же контекст файлик, в якому описуються налаштування мережі, ім'я vm і кастомні налаштування для ваших додатків). Тому тут визначаємося, що і як будемо бекапити. У деяких випадках краще робити копії того, що знаходиться в самій vm. І можливо, треба бекапити тільки один диск від даної машини.
Наприклад, ми визначилися, що всі машини запускаються з persistent images, отже, почитавши
значить спочатку з нашої vm можемо вивантажити образ:
onevm disk-saveas 74 3 prom.qcow2
Image ID: 77
Смотрим, под каким именем он сохранился
oneimage show 77
/var/lib/one//datastores/100/f9503161fe180658125a9b32433bf6e8
И далее копируем куда нам необходимо. Конечно, так себе способ. Просто хотел показать, что используя инструменты opennebula можно строить подобные решения.Також у просторах мережі знайшов і є ще Але тут тільки під qcow2 сховище.
Але як ми всі знаємо, рано чи пізно настає момент, коли хочеться інкрементальних бекапів, тут складніше і можливо керівництво виділить гроші на платне рішення, або піти іншим шляхом та розумінням того, що тут ми пиляємо лише ресурси, а резервування робити на рівні додатків та додавання кількості нових нод і віртуалок - так тут, я кажу, що використовувати хмару чисто для запуску кластерів додатків, а бд запускати на іншій платформі або брати готове від постачальника, якщо є така можливість.
4. Зручність використання
У цьому пункті опишу ті проблеми, з якими зіткнувся я. Наприклад, за образами, як ми знаємо, є persistent — при монтуванні цього образу до vm, всі дані записуються в цей образ. А якщо non-persistent, то копіюється образ на сховище і дані пишуться в те, що скопіювалося від вихідного образу - так працюють заготівлі шаблонів. Неодноразово сам собі робив проблеми тим, що забув вказати persistent і 200 гб образ копіювався, проблема в тому, що, напевно, цю процедуру скасувати не можна, треба йти на ноду і прибивати поточний процес «cp».
Один з важливих мінусів - це не можна скасувати дії, просто використовуючи gui. Точніше ти їх скасуєш і побачиш, що нічого не відбувається і знову запустиш, скасуєш і за фактом вже буде 2 процеси cp, які копіюють образ.
І тут приходить розумінням, чому opennebula кожен новий інстанс нумерує новим id, наприклад у тому ж proxmox створив vm з id 101, видалив її, потім знову створюєш і id 101. У opennebula такого не буде, кожен новий інстанс буде створюватися з новим id і у цьому є своя логіка — наприклад, очищення старих даних чи успішних інсталяцій.
Те саме по сховищу, найбільше ця платформа націлена на централізоване сховище. Є аддони для використання локального, але в даному випадку не про те. Думаю, що в майбутньому хтось напише статтю, про те, як вдалося використовувати локальне сховище на нодах і успішно використовувати в production.
5. Максимальна простота
Звичайно тут чим далі йдеш, тим менше стає тих, хто розумітиме тебе.
В умовах мого стенду – 3 ноди з nfs сховищем – все працює в порядку. Але якщо проводити експерименти на відключення енергії, то наприклад при запуску snapshot і відключення харчування ноди, у нас зберігаються налаштування в БД, що є snapshot, а за фактом його немає (ну ми ж все розуміємо, що вихідно записав в SQL базу про дану дію , але сама операція пройшла успішно). Плюс у тому, що при створенні знімка формується окремий файл і є «батько», отже у разі проблем і навіть якщо через gui не працює, ми можемо забрати qcow2 файл і відновиться окремо
По мережах, на жаль, не все так просто. Ну принаймні простіше ніж в openstack, я використовував тільки vlan (802.1Q) - цілком працює, але якщо ви з template network зробіть зміни в налаштуваннях, то дані налаштування не застосовуватися на машинах, що вже працюють, тобто треба видалити і додати мережеву карту, тоді нові налаштування застосовуватися.
Якщо ще хочеться порівняти з openstack, то можна сказати так, у opennebula немає чіткого визначення які технології використовувати для зберігання даних, управління мережею, ресурсами — кожен адміністратор вирішує сам, як йому зручніше.
6. Додаткові плагіни та установки
Адже як ми розуміємо хмарна платформа може керувати не лише kvm, а й vmware esxi. На жаль пула з Vcenter у мене не виявилося, якщо хтось пробував напишіть.
За підтримки інших хмарних провайдерів заявлено
AWS, AZURE.
Також пробував прикрутити Vmware Cloud від селектелів, але нічого не вийшло - загалом забив тому що багато факторів, а писати в тех.підтримку хостинг провайдера немає сенсу.
Також, зараз у новій версії є firecracker — це запуск microvm, типу kvm обв'язування над докером, що дає ще більше універсальності, безпеки та підвищення продуктивності, оскільки не треба витрачати ресурси на емуляцію обладнання. Я бачу лише перевагу по відношенню до докеру в тому, що не займає додаткову кількість процесів і немає сокетів, що займаються при використанні даної емуляції, тобто. Цілком собі можна використовувати як балансувальник навантаження (але про це напевно варто написати окрему статтю, поки не провів усі тести повною мірою).
7. Позитивний досвід використання та дебаг помилок
Хотів поділиться своїми спостереженнями щодо роботи, частину описав вище, хочеться написати більше. Справді, мабуть, не я один, хто спочатку думає, що ця не та система і взагалі тут все милицево — як із цим взагалі працюють? Але потім приходить розуміння і все цілком логічно. Звичайно, всім не догодити і деякі моменти вимагають доробок.
Наприклад, проста операція копіювання образу диска з одного datastore на інший. У моєму випадку є 2 ноди з nfs, відправляю образ - копіювання йде через frontend opennebula, хоча всі ми звикли до того, що дані повинні копіюватися безпосередньо між хостами - в тій же vmware, hyper-v ми звикли саме до цього, але тут іншому. Тут інший підхід і інша ідеологія, і в 5.12 версії прибрали кнопку "migrate to datastore" - переноситься тільки сама машина, але не сховище. мається на увазі централізоване сховище.
Далі популярна помилка з різними причинами "Error deploying virtual machine: Could no create domain from /var/lib/one//datastores/103/10/deployment.5" Нижче буде топ, що треба подивитися.
- Права на образ для користувача oneadmin;
- Права для користувача oneadmin для запуску libvirtd;
- А чи правильно змонтовано datastore? Іди і перевір шлях на самій ноді, можливо щось відвалилося;
- Неправильно налаштована мережа, вірніше на frontend стоїть в налаштуваннях мережі, що як основний інтерфейс для vlan стоїть br0, а на ноді прописано - bridge0 - треба щоб було однаково.
system datastore зберігає метадані для вашої vm, якщо ви запускаєте vm із persistent image, то vm необхідно мати доступ до початково створеної конфігурації на тому сховищі, де ви створювали vm – це дуже важливо. Тому при переносі vm на інший datastore треба все перевіряти ще раз.
8. Документація, спільнота. Подальший розвиток
І решта, хороша документація, спільнота і головне, щоб проект надалі продовжував жити.
Тут загалом усе досить добре документовано і навіть за офіційним джерелом не складе проблем встановити і знайти відповіді на запитання.
Спільнота, активна. Публікує багато готових рішень, які можна використовувати у своїх установках.
На даний момент з 5.12 змінилися деякі політики у компанії буде цікаво дізнатися, як розвиватиметься проект. На початку я спеціально вказав деяких постачальників, які використовують свої рішення і те, що пропонує індустрія. Чіткої відповіді, що використовувати вам, звичайно ж ні. Але для невеликих організацій підтримка своєї маленької приватної хмари може обійтися не так дорого, як це здається. Головне, достеменно знати, що це вам потрібно.
Як результат, незалежно від того, що ви вибрали як хмарна система не варто зупинятися на одному продукті. Якщо у вас є час, варто придивитися до інших більш відкритих рішень.
Є хороший чатик активно допомагають і не відправляють шукати вирішення проблеми до гугл. Приєднуйтесь.
Джерело: habr.com