Opennebula. Кратки бележки.

Здравейте на всички. Тази статия е написана за тези, които все още се колебаят между избора на платформи за виртуализация и след като прочетат статията от серията „Инсталирахме proxmox и всичко е чудесно, 6 години работа без прекъсване“. Но след инсталирането на едно или друго готово решение, възниква въпроса как да направим тук и там, за да е мониторингът по-разбираем и тук за да контролираме резервните копия… А после идва времето и осъзнавате, че искате нещо по-функционално, или искате всичко в системата ви да е разбираемо, а не това черно кутия, или искате да използвате нещо повече от хипервизор и куп виртуални машини. В тази статия ще има малко размишления и практика, базирана на платформата Opennebula — избрах я, защото не е взискателна към ресурсите и архитектурата не е толкова сложна.

И така, както виждаме, много облачни доставчици работят на kvm и правят външен интерфейс за управление на машините. Ясно е, че големите хостинг компании пишат свои интерфейси за облачната инфраструктура, същият YANDEX например. Някой използва openstack и прави интерфейс на база това — SELECTEL, MAIL.RU. Но ако имате собствено оборудване и малък екип от специалисти, обикновено избират нещо от готовите решения — VMWARE, HYPER-V, има безплатни и платени лицензии, но сега не е за това. Нека поговорим за ентусиастите — това са хората, които не се страхуват да предложат и пробват новото, въпреки че в компанията ясно са дали да се разбере „Кой ще се грижи за това след теб“, „А ние ли ще го внедрим в продукция? Страшно.“ Но всъщност, започвайки да прилагаме тези решения в условия на тестова среда и ако на всички им хареса, можем да поставим въпроса за по-нататъшното развитие и използване в по-сериозни среди.

Ето тук линк към доклад www.youtube.com/watch?v=47Mht_uoX3A от активен участник в развитието на тази платформа.

Възможно е в тази статия нещо да е излишно и вече да е ясно на опитния специалист, а в някои случаи няма да описвам всичко, тъй като подобни команди и описания вече се срещат в мрежата. Тук ще споделя само моя опит с тази платформа. Надявам се активните участници да допълнят в коментарите какво може да се направи по-добре и какви грешки съм допуснал. Всички действия са извършени при домашни условия с три компютъра с различни характеристики. Също така нарочно не посочвам как работи софтуерът и как се инсталира. Не, само опитът от администриране и проблемите, с които съм се сблъскал. Може би на някого ще му е полезно при избора.

И така, да започнем. За мен, като системен администратор, важни са следните точки, без които малко вероятно ще използвам това решение.

1. Повторяемост на инсталацията

Има купища инструкции по инсталиране на opennebula, тук не би трябвало да възникнат проблеми. От версия до версия се появяват нови функции, които не винаги могат да работят при прехода от версия на версия.

2. Мониторинг

Ще наблюдаваме самата нода, kvm и opennebula. За щастие, вече има готово решение. По отношение на мониторинга на linux хостове има множество опции, например zabbix или node exporter — когото какво му допада. В момента определям така, че мониторингът на системните метрики (температура там, където може да се измерва, консистентност на дисковия масив) да става чрез zabbix, а мониторингът на приложенията — чрез експортер в prometheus. За мониторинга на kvm, например, можете да вземете проекта github.com/zhangjianweibj/prometheus-libvirt-exporter.git и да настроите стартиране чрез systemd, работи доста добре и показва метрики за kvm, има и готова табла. grafana.com/grafana/dashboards/12538.

Например, ето моя файл:

/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, използвах следния. github.com/kvaps/opennebula-exporter/blob/master/opennebula_exporter

Може да се добави в обикновения node_exporter за системен мониторинг следното.

В файла за 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

Добавяме задача в cron за всяка минута:

*1 * * * * (/usr/local/bin/opennebula_exporter.sh > /var/lib/opennebula_exporter/textfile_collector/opennebula.prom)

Метрикът започна да се появява, може да се извлече с Prometheus, да се изградят графики и да се направят аларми. В Grafana може да се нарисува, например, такъв прост дашборд.

(вижда се, че тук направих overcommit на CPU, RAM)

За тези, които обичат и използват Zabbix, има github.com/OpenNebula/addon-zabbix

По отношение на мониторинга всичко е наред, основното е, че той съществува. Разбира се, може да се използват вградени средства за мониторинг на виртуални машини и да се извличат данни за фактуриране, тук всеки има свое виждане, но още не съм се захващал с това в детайли.

По отношение на логването, все още не съм се захванал особено. Най-простият вариант е да добавим td-agent за парсване на директорията /var/lib/one с регулярни изрази. Например, файлът sunstone.log отговаря на regexp nginx и други файлове, които показват историята на обращението с платформата — какво е предимството? Можем ясно да проследим броя на "Error, error" и по-бързо да установим къде и на какво ниво има неизправност.

3. Резервни копия

Има и платени проекти с подобрения — например sep wiki.sepsoftware.com/wiki/index.php/4_4_3_Tigon:OpenNebula_Backup. Тук трябва да разберем, че просто архивирането на образа на машината не е съвсем това, тъй като нашите виртуални машини трябва да работят с пълна интеграция (същият контекст файл, в който са описани настройките на мрежата, името на vm и персонализираните настройки за вашите приложения). Затова трябва да определим какво и как ще архивираме. В някои случаи е по-добре да правим копия на това, което се намира в самата vm. И възможно е да трябва да архивираме само един диск от тази машина.

Например, решихме, че всички машини стартират с persistent images, следователно, прочитайки docs.opennebula.io/5.12/operation/vm_management/img_guide.html

значи първо можем да извлечем образа от нашата vm:

onevm disk-saveas 74 3 prom.qcow2
Image ID: 77

Виждаме под какво име е запазен

oneimage show 77
/var/lib/one//datastores/100/f9503161fe180658125a9b32433bf6e8

И след това копираме където ни е необходимо. Разбира се, не е най-добрият метод. Просто исках да покажа, че с инструментите на OpenNebula може да се изградят подобни решения.

Също така в пространството на мрежата намерих интересно доклад и има още такъв открит проект, но тук само за qcow2 хранилище.

Но как всички знаем, рано или късно настъпва момент, когато искате инкрементални резервни копия. Тук е по-сложно и е възможно ръководството да отдели средства за платено решение, или да предприемете друг път, осъзнавайки, че тук просто използваме ресурси, а резервирането се прави на ниво приложения, добавяйки нови възли и виртуалки — да, тук казвам, че трябва да се използва облака чисто за стартиране на приложения в клъстери, а базите данни да се стартират на друга платформа или да се вземе готово решение от доставчика, ако има такава възможност.

4. Удобство на употреба

В този пункт ще опиша проблемите, с които се сблъсках. Например, относно образите, както знаем, съществуват постоянни — при монтиране на този образ към виртуалната машина, всички данни се записват в този образ. Ако е непостоянен, образът се копира в хранилището и данните се записват в това, което е копирано от изходния образ — така работят шаблоните. Многократно съм си създавал проблеми, забравяйки да посоча постоянен подход и образът от 200 ГБ беше копиран, проблемът е, че вероятно не може да се анулира тази процедура, трябва да отидеш на възела и да убиеш текущия процес "cp".

Един от важните недостатъци е, че не можете просто да анулирате действията, използвайки графичния интерфейс. Всъщност, ще ги анулирате и ще видите, че нищо не се случва и ще стартирате отново, анулирате и по същество ще има 2 процеса "cp", които копират образа.

И тук идва осъзнаването защо opennebula нумерува всеки нов инстанс с нов id, например в proxmox, ако създадете виртуална машина с id 101, след това я изтриете и отново създадете, id ще бъде 101. В opennebula такова нещо няма да се случи, всеки нов инстанс ще бъде създаден с нов id и това има своя логика — например, почистване на стари данни или неуспешни инсталации.

Същото важи и за хранилището, тази платформа е най-силно нацелена на централизирано хранилище. Има добавки за използване на локално хранилище, но в този случай не става въпрос за това. Мисля, че в бъдеще някой ще напише статия за това как е успял да използва локално хранилище на възлите и успешно да го използва в продукция.

5. Максимална простота

Разбира се, тук, колкото по-напред продължаваш, толкова по-малко стават онези, които ще те разбират.

В условия на моят стенд — 3 възела с nfs хранилище — всичко работи нормално. Но ако правим експерименти с изключване на енергия, например при стартиране на snapshot и изключване на захранването на възела, ние запазваме настройките в БД, че има snapshot, а всъщност го няма (всички разбираме, че първоначално записваме в sql базата относно това действие, но самата операция е неуспешна). Плюсът е, че при създаване на снимка се генерира отделен файл и има "родител", следователно в случай на проблеми и дори ако gui не работи, можем да вземем qcow2 файла и да се възстановим отделно. docs.opennebula.io/5.8/operation/vm_management/vm_instances.html

По мрежите, за съжаление, не всичко е толкова просто. По принцип е по-лесно от OpenStack, аз използвах само vlan (802.1Q) — работи напълно, но ако направите промени в настройките на template network, тези настройки няма да бъдат приложени на вече работещите машини т.е. трябва да изтриете и добавите мрежовата карта, за да се приложат новите настройки.

Ако искате да сравните с OpenStack, може да се каже, че в OpenNebula няма ясно определение относно технологиите, които да се използват за съхранение на данни, управление на мрежата, ресурсите — всеки администратор решава сам как е най-удобно.

6. Допълнителни плъгини и инсталации

В крайна сметка, както разбираме, облачната платформа може да управлява не само KVM, но и VMware ESXi. За съжаление, нямам пул с VCenter, ако някой е пробвал, нека пише.

В поддръжката на други облачни доставчици е обявено docs.opennebula.io/5.12/advanced_components/cloud_bursting/index.html
AWS, AZURE.

Също така опитах да свържа VMware Cloud от Selectel, но не успях — на кратко, се отказах, тъй като има много фактори и няма смисъл да пиша в техническата поддръжка на хостинг доставчика.

Сега в новата версия има Firecracker — това е стартиране на microvm, нещо като KVM обвивка над Docker, която дава още повече универсалност, сигурност и повишаване на производителността, тъй като не е необходимо да се харчат ресурси за емулация на оборудването. Виждам само предимства в сравнение с Docker, тъй като не заема допълнителни процеси и няма заети сокети при използване на тази емулация, т.е. спокойно може да се използва като балансир на натоварването (но за това вероятно е добре да напиша отделна статия, докато не проведох всички тестове изцяло).

7. Положителен опит от използване и дебъгване на грешки

Искам да споделя наблюденията си по отношение на работата, част от които описах по-горе, и бих искал да напиша още. Всъщност, вероятно не съм единственият, който първоначално си мисли, че това не е правилната система и всичко тук е временно — как работят с това въобще? Но след това идва разбирането, че всичко е напълно логично. Разбира се, на всички не може да се угоди и някои моменти изискват доработка.

Например, простата операция за копиране на образа на диска от един datastore на друг. В моя случай имам 2 възли с nfs, изпращам образа — копирането става през frontend opennebula, макар че всички ние сме свикнали данните да се копират директно между хостовете — в същата vmware, hyper-v ние сме свикнали точно с това, но тук е по друг начин. Тук има друг подход и друга идеология, а в версия 5.12 е премахната бутонът „migrate to datastore“ — преносът е само на самата машина, но не и на хранилището, тъй като се подразбира централизирано хранилище.

Следва популярната грешка с различни причини „Error deploying virtual machine: Could not 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 се промениха някои политики в компанията. forum.opennebula.io/t/towards-a-stronger-opennebula-community/8506/14 Интересно е да разберем как ще се развива проектът. В началото споменах няколко доставчици, които предлагат свои решения и онова, което индустрията предлага. Разбира се, няма ясен отговор какво да изберете. Но за малки организации поддръжката на собствено малко частно облако може да не струва толкова много, колкото изглежда. Най-важното е да знаете точно какво ви е необходимо.

В крайна сметка, независимо от това каква облачна система изберете, не трябва да се задоволявате с един продукт. Ако имате време, струва си да разгледате и други по-отворени решения.

Има добър чат. t.me/opennebula активно помагат и не ви изпращат да търсите решение на проблема в Google. Присъединявайте се.

Източник: habr.com