Hæ allir. Þessi grein var skrifuð fyrir þá sem eru enn að rífast á milli þess að velja sýndarvæðingarvettvang og eftir að hafa lesið greinina úr seríunni „Við settum upp proxmox og almennt er allt í lagi, 6 ára spenntur án nokkurs hlés. En eftir að hafa sett upp eina eða aðra út-af-the-box lausn, vaknar spurningin: hvernig get ég leiðrétt þetta hér, svo að eftirlitið sé skiljanlegra, og hér, til að stjórna afritum .... Og svo kemur tíminn og þú áttar þig á því að þú vilt eitthvað virkara, eða þú vilt að allt inni í kerfinu þínu verði skýrt, en ekki þessi svarti kassi, eða þú vilt nota eitthvað meira en hypervisor og fullt af sýndarvélum. Þessi grein mun innihalda nokkrar hugsanir og æfingar byggðar á Opennebula pallinum - ég valdi það vegna þess. það er ekki krefjandi fyrir fjármagn og arkitektúrinn er ekki svo flókinn.
Og svo, eins og við sjáum, vinna margir skýjaveitur á kvm og gera ytri tengingar til að stjórna vélum. Það er ljóst að stórir gestgjafar skrifa eigin ramma fyrir skýjainnviði, sama YANDEX til dæmis. Einhver notar openstack og gerir tengingu á þessum grundvelli - SELECTEL, MAIL.RU. En ef þú ert með þinn eigin vélbúnað og lítið starfsfólk af sérfræðingum, þá velurðu venjulega eitthvað tilbúið - VMWARE, HYPER-V, það eru ókeypis og greidd leyfi, en það er ekki það sem við erum að tala um núna. Við skulum tala um áhugamenn - þetta eru þeir sem eru óhræddir við að bjóða og prófa eitthvað nýtt, þrátt fyrir að fyrirtækið hafi greinilega tekið skýrt fram: „Hver mun þjónusta þetta eftir þig,“ „ætlum við að setja þetta í framleiðslu síðar ? Hræðilegt." En þú getur fyrst beitt þessum lausnum á prófunarbekk, og ef öllum líkar það, þá geturðu vakið upp spurninguna um frekari þróun og notkun í alvarlegri umhverfi.
Hér er einnig hlekkur á skýrsluna frá virkum þátttakanda í þróun þessa vettvangs.
Kannski í þessari grein verður eitthvað óþarfi og þegar skiljanlegt fyrir reyndan sérfræðing, og í sumum tilfellum mun ég ekki lýsa öllu vegna þess að svipaðar skipanir og lýsingar eru fáanlegar á Netinu. Þetta er bara mín reynsla af þessum vettvangi. Ég vona að virkir þátttakendur bæti við í athugasemdum hvað mætti betur fara og hvaða mistök ég gerði. Allar aðgerðir fóru fram í heimastandi sem samanstóð af 3 tölvum með mismunandi eiginleika. Einnig gaf ég ekki sérstaklega til kynna hvernig þessi hugbúnaður virkar og hvernig á að setja hann upp. Nei, aðeins stjórnsýslureynsla og vandamálin sem ég lenti í. Kannski mun þetta nýtast einhverjum að eigin vali.
Svo, við skulum byrja. Sem kerfisstjóri eru eftirfarandi atriði mikilvæg fyrir mig, án þeirra er ólíklegt að ég noti þessa lausn.
1. Endurtekningarhæfni uppsetningar
Það eru fullt af leiðbeiningum til að setja upp opna þoku, það ætti ekki að vera nein vandamál. Frá útgáfu til útgáfu birtast nýir eiginleikar sem munu ekki alltaf virka þegar farið er frá útgáfu til útgáfu.
2. Eftirlit
Við munum fylgjast með hnútnum sjálfum, kvm og opnum þoku. Sem betur fer er það þegar tilbúið. Það eru margir möguleikar til að fylgjast með Linux hýsingum, sama Zabbix eða hnútaútflytjanda - hverjum sem líkar betur - í augnablikinu skilgreini ég það sem eftirlitskerfismælingar (hitastig þar sem hægt er að mæla það, samkvæmni diskafylkisins), í gegnum zabbix , og varðandi umsóknir í gegnum Prometheus útflytjanda. Fyrir kvm eftirlit geturðu til dæmis tekið verkefnið og stilltu það til að keyra í gegnum systemd, það virkar nokkuð vel og sýnir kvm mælikvarða, það er líka tilbúið mælaborð .
Til dæmis, hér er skráin mín:
/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.targetOg svo erum við með 1 útflytjanda, við þurfum annan til að fylgjast með sjálfri opnu þokunni, ég notaði þetta
Hægt að bæta við venjulega að fylgjast með kerfinu eftirfarandi.
Í node_exporter skránni breytum við byrjuninni svona:
ExecStart=/usr/sbin/node_exporter --web.listen-address=":9102" --collector.textfile.directory=/var/lib/opennebula_exporter/textfile_collectorBúðu til möppu mkdir -p /var/lib/opennebula_exporter
bash forskrift sem kynnt er hér að ofan, fyrst athugum við verkið í gegnum stjórnborðið, ef það sýnir það sem við þurfum (ef það gefur villu, settu síðan upp xmlstarlet), afritaðu það á /usr/local/bin/opennebula_exporter.sh
Bættu við cron verkefni fyrir hverja mínútu:
*/1 * * * * (/usr/local/bin/opennebula_exporter.sh > /var/lib/opennebula_exporter/textfile_collector/opennebula.prom)Mælingar fóru að birtast, þú getur tekið þær eins og prómeþeus og smíðað línurit og gert viðvaranir. Í Grafana er til dæmis hægt að teikna svona einfalt mælaborð.
(það er ljóst að hér legg ég of mikið á örgjörva, vinnsluminni)
Fyrir þá sem elska og nota Zabbix, það er
Hvað eftirlitið varðar er aðalatriðið að það sé til staðar. Auðvitað geturðu að auki notað innbyggðu sýndarvélaeftirlitstækin og hlaðið upp gögnum á innheimtu, hér hafa allir sína eigin sýn, ég er ekki byrjaður að vinna að þessu nánar.
Ég er eiginlega ekki byrjuð að skrá mig ennþá. Einfaldasti kosturinn er að bæta við td-agent til að flokka /var/lib/one möppuna með reglulegum tjáningum. Sunstone.log skráin passar til dæmis við nginx regexp og aðrar skrár sem sýna sögu aðgangs að pallinum - hver er kosturinn við þetta? Jæja, til dæmis, við getum beinlínis fylgst með fjölda „Villa, villa“ og fylgst fljótt með hvar og á hvaða stigi er bilun.
3. Afrit
Einnig eru greidd unnin verkefni - til dæmis sep :OpenNebula_Backup. Hér verðum við að skilja að það að taka öryggisafrit af vélamynd er alls ekki það sama í þessu tilfelli, því sýndarvélarnar okkar verða að vinna með fullri samþættingu (sama samhengisskrá sem lýsir netstillingum, vm nafni og sérsniðnum stillingum fyrir forritin þín) . Þess vegna ákveðum við hér hvað og hvernig við munum taka öryggisafrit. Í sumum tilfellum er betra að gera afrit af því sem er í vm sjálfum. Og kannski þarftu aðeins að taka öryggisafrit af einum diski frá tiltekinni vél.
Til dæmis ákváðum við að allar vélar byrja með viðvarandi myndir, því eftir lestur
Þetta þýðir að fyrst getum við hlaðið upp myndinni frá vm okkar:
onevm disk-saveas 74 3 prom.qcow2
Image ID: 77
Смотрим, под каким именем он сохранился
oneimage show 77
/var/lib/one//datastores/100/f9503161fe180658125a9b32433bf6e8
И далее копируем куда нам необходимо. Конечно, так себе способ. Просто хотел показать, что используя инструменты opennebula можно строить подобные решения.Ég fann líka á netinu og það er meira , en það er aðeins geymsla fyrir qcow2.
En eins og við vitum öll, fyrr eða síðar kemur tími þar sem þú vilt stigvaxandi öryggisafrit, það er erfiðara hér og ef til vill munu stjórnendur úthluta peningum fyrir greidda lausn, eða fara í hina áttina og skilja að hér erum við aðeins að skera niður fjármagn, og gera öryggisafrit á forritastigi og bæta við fjölda nýrra hnúta og sýndarvéla - já, hér er ég að segja að nota skýið eingöngu til að ræsa forritaklasa og ræsa gagnagrunninn á öðrum vettvangi eða taka tilbúinn einn frá birgi, ef mögulegt er.
4. Auðvelt í notkun
Í þessari málsgrein mun ég lýsa vandamálunum sem ég lenti í. Til dæmis, samkvæmt myndum, eins og við vitum, er það viðvarandi - þegar þessi mynd er fest á vm, eru öll gögn skrifuð á þessa mynd. Og ef hún er ekki viðvarandi, þá er myndin afrituð í geymsluna og gögnin eru skrifuð á það sem var afritað af upprunamyndinni - svona virka sniðmátsniðmát. Ég olli sjálfum mér ítrekað vandamál með því að gleyma að tilgreina viðvarandi og 200 GB myndin var afrituð, vandamálið er að þetta ferli er vissulega ekki hægt að hætta við, þú verður að fara í hnútinn og drepa núverandi "cp" ferli.
Einn af mikilvægu ókostunum er að þú getur ekki hætt við aðgerðir einfaldlega með því að nota gui. Eða réttara sagt, þú munt hætta við þá og sjá að ekkert gerist og þú munt byrja þá aftur, hætta við þá og í raun verða nú þegar 2 cp ferli sem afrita myndina.
Og þá kemur að því að skilja hvers vegna opennebula númerar hvert nýtt tilvik með nýju auðkenni, til dæmis, í sama proxmox bjó til vm með id 101, eyddi því, þá býrðu til það aftur og id 101. Í opennebula mun þetta ekki gerast, hvert nýtt tilvik verður búið til með nýju auðkenni og það hefur sína eigin rökfræði - til dæmis að hreinsa gömul gögn eða misheppnaðar uppsetningar.
Sama gildir um geymslu; umfram allt miðar þessi vettvangur að miðlægri geymslu. Það eru viðbætur til að nota staðbundnar, en það er ekki það sem við erum að tala um í þessu tilfelli. Ég held að í framtíðinni muni einhver skrifa grein um hvernig þeim tókst að nota staðbundna geymslu á hnútum og nota það með góðum árangri í framleiðslu.
5. Hámarks einfaldleiki
Auðvitað, því lengra sem þú ferð, því færri verða þeir sem skilja þig.
Við aðstæður standsins míns - 3 hnútar með nfs geymslu - virkar allt fínt. En ef við gerum tilraunir sem fela í sér rafmagnsleysi, til dæmis þegar keyrt er skyndimynd og slökkt á afli hnútsins, vistum við stillingar í gagnagrunninum að það sé skyndimynd, en í raun er engin (jæja, við skiljum öll að við skrifaði upphaflega gagnagrunninn um þessa aðgerð í sql , en aðgerðin sjálf heppnaðist ekki). Kosturinn er sá að þegar þú býrð til skyndimynd myndast sérstök skrá og það er „foreldri“, því ef vandamál koma upp og jafnvel þótt það virki ekki í gegnum gui, getum við tekið upp qcow2 skrána og endurheimt hana sérstaklega
Á netum er því miður ekki allt svo einfalt. Jæja, það er allavega auðveldara en í openstack, ég notaði bara vlan (802.1Q) - það virkar nokkuð vel, en ef þú gerir breytingar á stillingum frá sniðmátnetinu, þá verða þessar stillingar ekki notaðar á vélar sem eru þegar í gangi, þ.e. þú þarft að eyða og bæta við netkorti, þá verða nýju stillingarnar notaðar.
Ef þú vilt samt bera það saman við openstack, þá geturðu sagt þetta: í opennebula er engin skýr skilgreining á því hvaða tækni á að nota til að geyma gögn, stjórna netinu, auðlindum - hver stjórnandi ákveður sjálfur hvað er þægilegra fyrir hann.
6. Viðbótarviðbætur og uppsetningar
Eftir allt saman, eins og við skiljum það, getur skýjapallinn stjórnað ekki aðeins kvm, heldur einnig vmware esxi. Því miður var ég ekki með sundlaug með Vcenter, ef einhver hefur reynt, vinsamlegast skrifaðu.
Stuðningur við aðrar skýjaveitur kemur fram
AWS, AZURE.
Ég reyndi líka að tengja Vmware Cloud frá Selectel, en ekkert virkaði - almennt var það lokað vegna þess að það eru margir þættir og það þýðir ekkert að skrifa til tækniaðstoðar hýsingaraðilans.
Nýja útgáfan er líka með eldflaug - þetta er kynning á microvm, tegund kvm beisli yfir docker, sem gefur enn meiri fjölhæfni, öryggi og aukna framleiðni vegna þess að engin þörf er á að eyða fjármagni í að líkja eftir búnaði. Eini kosturinn sem ég sé fram yfir Docker er að hann tekur ekki upp fleiri ferla og það eru engar uppteknar innstungur þegar þessi hermi er notuð, þ.e. Það er alveg hægt að nota það sem álagsjafnara (en það er líklega þess virði að skrifa sérstaka grein um þetta þar til ég hef keyrt öll prófin að fullu).
7. Jákvæð reynsla af notkun og villuleit
Mig langaði að deila athugasemdum mínum um verkið, ég lýsti sumu af því hér að ofan, mig langar að skrifa meira. Reyndar er ég sennilega ekki sá eini sem í fyrstu heldur að þetta sé ekki rétta kerfið og almennt er allt hérna hækja - hvernig vinna þeir með þetta? En svo kemur sá skilningur að allt er nokkuð rökrétt. Auðvitað geturðu ekki þóknast öllum og sumir þættir krefjast úrbóta.
Til dæmis einföld aðgerð að afrita diskmynd frá einni gagnageymslu yfir í aðra. Í mínu tilfelli eru 2 hnútar með nfs, ég sendi myndina - afritun á sér stað í gegnum framenda opna þokuna, þó við séum öll vön því að gögn eigi að afrita beint á milli hýsla - í sama vmware, hyper-v sem við erum vanur þessu, en hér að öðru. Það er önnur nálgun og önnur hugmyndafræði, og í útgáfu 5.12 fjarlægðu þeir hnappinn „flytja í gagnageymslu“ - aðeins vélin sjálf er flutt, en ekki geymslan vegna þess að þýðir miðlæg geymslu.
Næst er vinsæl villa af ýmsum ástæðum: „Villa við að dreifa sýndarvél: Gat ekki búið til lén úr /var/lib/one//datastores/103/10/deployment.5“ Hér að neðan er það helsta sem þarf að skoða.
- Myndréttur fyrir oneadmin notandann;
- Heimildir fyrir oneadmin notandann til að keyra libvirtd;
- Er gagnaverið rétt sett upp? Farðu og athugaðu leiðina á hnútnum sjálfum, kannski hefur eitthvað dottið af;
- Rangt stillt net, eða réttara sagt á framendanum það er í netstillingunum sem aðalviðmótið fyrir vlan er br0, en á hnútnum er það skrifað sem bridge0 - það verður að vera það sama.
system datastore geymir lýsigögn fyrir vm þinn, ef þú keyrir vm með viðvarandi mynd, þá þarf vm að hafa aðgang að upphaflegri uppsetningu á geymslunni þar sem þú bjóst til vm - þetta er mjög mikilvægt. Þess vegna, þegar þú flytur vm í aðra gagnageymslu, þarftu að athuga allt.
8. Skjalagerð, samfélag. Frekari þróun
Og restin, góð skjöl, samfélag og aðalatriðið er að verkefnið lifi áfram í framtíðinni.
Almennt séð er allt nokkuð vel skjalfest og jafnvel með því að nota opinbera heimild mun það ekki vera vandamál að setja upp og finna svör við spurningum.
Samfélag, virkt. Gefur út margar tilbúnar lausnir sem þú getur notað í uppsetningum þínum.
Eins og er hafa sumar stefnur í fyrirtækinu breyst frá 5.12 Það verður spennandi að sjá hvernig verkefnið þróast. Í upphafi benti ég sérstaklega á nokkra af söluaðilum sem nota lausnir þeirra og hvað iðnaðurinn býður upp á. Auðvitað er ekkert skýrt svar um hvað á að nota. En fyrir smærri stofnanir er kannski ekki eins dýrt að viðhalda litlu einkaskýinu sínu og það virðist. Aðalatriðið er að vita nákvæmlega hvað þú þarft.
Þar af leiðandi, óháð því hvað þú velur sem skýjakerfi, ættir þú ekki að stoppa við eina vöru. Ef þú hefur tíma er vert að skoða aðrar opnari lausnir.
Það er gott spjall Þeir hjálpa virkan og senda þig ekki til að leita að lausn á vandamálinu á Google. Gakktu til liðs við okkur.
Heimild: www.habr.com