отворена мъглявина. Кратки бележки

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

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

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

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

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

1. Повторяемост на монтажа

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

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

Ще наблюдаваме самия възел, kvm и opennebula. За щастие вече е готов. Има много опции за мониторинг на Linux хостове, същия zabbix или node exporter - който го харесва повече - в момента го дефинирам така, че да наблюдава системните показатели (температура, където може да се измери, консистенция на дисковия масив), чрез zabbix, но що се отнася до приложенията чрез износителя в prometheus. За мониторинг на kvm, например, можете да вземете проект github.com/zhangjianweibj/prometheus-libvirt-exporter.git и сложи стартирането през systemd, работи доста добре и показва kvm metrics, има и готово табло 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, например, можете да нарисувате такова просто табло.

(можете да видите, че тук прекарах процесора, RAM)

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

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

За регистриране, докато особено не започна. Най-лесният вариант е да добавите td-agent за анализиране на директорията /var/lib/one с регулярни изрази. Например, файлът sunstone.log съвпада с nginx regexp и други файлове, които показват историята на достъпа до платформата - какъв е плюсът? Е, например, можем изрично да проследим броя на „Грешка, грешка“ и бързо да проследим къде и на какво ниво има неизправност.

3. Архивиране

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

Например, установихме, че всички машини се стартират с постоянни изображения, следователно след четене 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. Лесна употреба

В този параграф ще опиша проблемите, които срещнах. Например, според изображенията, както знаем, има постоянен - ​​когато това изображение се монтира към vm, всички данни се записват в това изображение. И ако не е постоянен, тогава изображението се копира в хранилището и данните се записват в това, което е копирано от оригиналното изображение - така работят празните шаблони. Той многократно създаваше проблеми за себе си, като забрави да посочи persistent и изображението от 200 GB беше копирано, проблемът е, че тази процедура не може да бъде отменена със сигурност, трябва да отидете до възела и да убиете текущия процес „cp“.

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

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

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

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

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

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

В мрежите, за съжаление, не всичко е толкова просто. Е, поне е по-лесно, отколкото в openstack, използвах само vlan (802.1Q) - работи добре, но ако направите промени в настройките от шаблонната мрежа, тогава тези настройки няма да се прилагат на вече работещи машини, т.е. трябва да изтриете и добавите мрежова карта, тогава новите настройки ще бъдат приложени.

Ако все пак искате да сравните с 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, което дава още повече гъвкавост, сигурност и подобрения в производителността, тъй като няма нужда да се хабят ресурси за хардуерна емулация. Виждам само предимство по отношение на докера, че не заема допълнителен брой процеси и няма заети сокети при използване на тази емулация, т.е. напълно възможно е да го използвате като балансьор на натоварването (но вероятно си струва да напишете отделна статия за това, докато не завършите всички тестове изцяло).

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

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

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

След това популярна грешка с различни причини „Грешка при разполагането на виртуална машина: Не може да се създаде домейн от /var/lib/one//datastores/103/10/deployment.5“ По-долу е най-важното нещо, което трябва да разгледате.

• Права върху изображението за потребителя oneadmin;
• Разрешения за oneadmin потребителя да изпълнява libvirtd;
• Правилно ли е монтирано хранилището за данни? Отидете и проверете пътя на самия възел, може нещо да е паднало;
• Неправилно конфигурирана мрежа, или по-скоро на frontend, в мрежовите настройки е, че br0 е основният интерфейс за vlan, а bridge0 пише на възела - трябва да е същото.

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

8. Документация, общност. По-нататъчно развитие

И останалото, добра документация, общност и най-важното, че проектът продължава да живее в бъдеще.

Тук като цяло всичко е доста добре документирано и дори според официален източник няма да е проблем да се установят и намерят отговори на въпроси.

Активна общност. Той публикува много готови решения, които можете да използвате във вашите инсталации.

В момента някои политики в компанията са променени от 5.12 forum.opennebula.io/t/towards-a-stronger-opennebula-community/8506/14 Ще бъде интересно да видим как ще се развие проектът. В началото специално посочих някои от производителите, които използват техните решения и какво предлага индустрията. Разбира се, няма ясен отговор какво да използвате за вас. Но за по-малките организации поддържането на собствен малък частен облак може да не е толкова скъпо, колкото изглежда. Основното нещо е да знаете точно какво ви трябва.

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

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

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