Ўсім прывітанне. Дадзены артыкул напісаны для тых, хто да гэтага часу кідаецца паміж выбарам платформаў віртуалізацыі і пасля прачытання артыкула з серыі «Паставілі 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" – пераносіцца толькі сама машына, але не сховішча т.к. разумеецца цэнтралізаванае сховішча.
Далей папулярная памылка з рознымі чыннікамі Ніжэй будзе топ, што трэба паглядзець.
- Правы на выяву для карыстальніка oneadmin;
- Правы для карыстальніка oneadminдля запуску libvirtd;
- А ці правільна змантаваны datastore? Ідзі і правер шлях на самой надзе, магчыма што тое адвалілася;
- Няправільна сканфігураваная сетка, дакладней на frontend варта ў наладах сеткі, што ў якасці асноўнага інтэрфейсу для vlan варта br0, а на нодзе прапісана – bridge0 – трэба каб было аднолькава.
system datastore захоўвае метададзеныя для вашай vm, калі вы запускаеце vm з persistent image, то vm неабходна мець доступ да першапачаткова створанай канфігурацыі на тым сховішчы, дзе вы стваралі vm - гэта вельмі важна. Таму пры пераносе vm на іншы datastore трэба ўсё пераправерыць.
8. Дакументацыя, супольнасць. Далейшае развіццё
І астатняе, добрая дакументацыя, супольнасць і галоўнае, каб праект у далейшым працягваў жыць.
Тут у цэлым, усё даволі добра дакументавана і нават па афіцыйнай крыніцы не складзе праблем устанавіць і знайсці адказы на пытанні.
Супольнасць, актыўная. Публікуе шмат гатовых рашэнняў, якія вы можаце выкарыстоўваць у сваіх усталёўках.
На дадзены момант з 5.12 змяніліся некаторыя палітыкі ў кампаніі будзе цікава даведацца, як будзе развівацца праект. У пачатку я спецыяльна паказаў некаторых пастаўшчыкоў, якія выкарыстоўваюць свае рашэнні і тое, што прапануе індустрыя. Выразнага адказу што выкарыстоўваць вам, вядома ж няма. Але для невялікіх арганізацый падтрымка свайго маленькага прыватнага аблокі можа абысціся не так дорага, як гэта падаецца. Галоўнае, дакладна ведаць, што гэта вам трэба.
Як вынік, незалежна ад таго, што вы выбралі ў якасці хмарнай сістэмы не варта спыняцца на адным прадукце. Калі ў вас ёсць час, варта прыгледзецца да іншых больш адчыненых рашэнняў.
Ёсць добры Чацік актыўна дапамагаюць і не адпраўляюць шукаць рашэнне праблемы ў гугл. Далучайцеся.
Крыніца: habr.com