See artikkel on jätk eelmisele - "'.
See hõlmab oVirt 4.3 klastri põhiinstallatsiooni ja seadistamise protsessi kõrge kättesaadavusega virtuaalmasinate majutamiseks, võttes arvesse asjaolu, et kõik infrastruktuuri ettevalmistamise eeltoimingud on juba varem tehtud.
Sissejuhatav osa
Artikli põhieesmärk on anda samm-sammult juhiseid nagu "järgmine -> Jah -> lõpp"kuidas kuvada mõningaid funktsioone selle installimisel ja konfigureerimisel. Teie klastri juurutamise protsess ei pruugi infrastruktuuri ja keskkonna omaduste tõttu alati selles kirjeldatuga kokku langeda, kuid üldpõhimõtted on samad.
Subjektiivsest vaatenurgast, selle funktsionaalsus on sarnane VMware vSphere versioonile 5.x, kuid loomulikult oma konfiguratsiooni- ja tööfunktsioonidega.
Huvilistele võib kõik RHEV-i (aka oVirt) ja VMware vSphere'i erinevused leida näiteks internetist , kuid artikli edenedes märgin siiski aeg-ajalt nende erinevusi või sarnasusi.
Eraldi tahaksin veidi võrrelda tööd virtuaalmasinate võrkudega. oVirt rakendab virtuaalsete masinate (edaspidi VM) jaoks sarnast võrguhalduse põhimõtet nagu VMware vSphere'is:
- kasutades tavalist Linuxi silda (VMware'is - Standardne vSwitch), töötab virtualiseerimishostidel;
- kasutades Open vSwitchi (OVS) (VMware'is - Distributed vSwitch) on hajutatud virtuaalne lüliti, mis koosneb kahest põhikomponendist: kesksest OVN-serverist ja hallatavatel hostidel olevatest OVN-kontrolleritest.
Tuleb märkida, et juurutamise lihtsuse tõttu kirjeldatakse artiklis võrkude seadistamist oVirt-is VM-i jaoks, kasutades standardset Linuxi silda, mis on KVM-i hüperviisori kasutamisel tavaline valik.
Sellega seoses on klastris võrguga töötamiseks mitu põhireeglit, mida on parem mitte rikkuda:
- Kõik hostide võrgusätted peavad enne nende oVirti lisamist olema identsed, välja arvatud IP-aadressid.
- Kui host on võetud oVirti kontrolli alla, ei ole väga soovitatav midagi võrguseadetes käsitsi muuta ilma oma tegevustes täieliku kindlustundeta, kuna oVirt agent viib need pärast hosti taaskäivitamist või taaskäivitamist lihtsalt tagasi eelmistele. agent.
- VM-i jaoks uue võrgu lisamine ja sellega töötamine tuleks teha ainult oVirt halduskonsoolist.
Teine oluline märkus — väga kriitilise keskkonna (rahalise kahju suhtes väga tundlik) puhul soovitaks siiski kasutada tasulist tuge ja kasutamist . oVirt klastri töötamise käigus võivad tekkida probleemid, mille lahendamiseks on soovitav võimalikult kiiresti kvalifitseeritud abi saada, mitte ise tegeleda.
Ja lõpuks on soovitatav Enne oVirt klastri juurutamist tutvuge sellega , et olla kursis vähemalt põhimõistete ja määratlustega, vastasel juhul on ülejäänud artikli lugemine pisut keeruline.
Artiklist ja oVirt klastri tööpõhimõtetest arusaamiseks on järgmised juhenddokumendid:
Maht pole seal kuigi suur, tunni-kahega saab põhiprintsiibid päris selgeks, aga kellel detailid meeldivad, siis soovitan lugeda — RHEV ja oVirt on sisuliselt sama asi.
Seega, kui kõik hostide, lülitite ja salvestussüsteemide põhiseaded on tehtud, jätkame otse oVirt juurutamisega.
Osa 2. oVirt 4.3 klastri installimine ja konfigureerimine
Orienteerumise hõlbustamiseks loetlen selle artikli peamised jaotised, mis tuleb täita ükshaaval:
- oVirt haldusserveri installimine
- Uue andmekeskuse loomine
- Uue klastri loomine
- Täiendavate hostide installimine isehostitavasse keskkonda
- Salvestusala või salvestusdomeenide loomine
- Virtuaalsete masinate võrkude loomine ja seadistamine
- Virtuaalse masina juurutamiseks installipildi loomine
- Looge virtuaalne masin
oVirt haldusserveri installimine
oVirt haldusserver on oVirt infrastruktuuri kõige olulisem element virtuaalmasina, hosti või virtuaalse seadme kujul, mis haldab kogu oVirt infrastruktuuri.
Selle lähedased analoogid virtualiseerimise maailmast on:
- VMware vSphere – vCenter Server
- Microsoft Hyper-V – System Centeri virtuaalmasinahaldur (VMM).
oVirt haldusserveri installimiseks on meil kaks võimalust:
Valik 1
Serveri juurutamine spetsiaalse VM-i või hosti kujul.
See valik töötab üsna hästi, kuid eeldusel, et selline VM töötab klastrist sõltumatult, s.t. ei tööta üheski klastri hostis tavalise virtuaalmasinana, milles töötab KVM.
Miks ei saa sellist VM-i klastri hostidesse juurutada?
Kohe oVirt haldusserveri juurutamise protsessi alguses on meil dilemma - peame installima haldus-VM-i, kuid tegelikult pole veel klastrit ennast ja seega mida me saame käigu pealt välja mõelda? See on õige – installige KVM tulevasse klastri sõlme, seejärel looge sellele virtuaalne masin näiteks CentOS OS-iga ja juurutage selles oVirt mootor. Tavaliselt saab seda teha sellise VM-i täieliku kontrolli tagamiseks, kuid see on ekslik kavatsus, kuna sel juhul on tulevikus sellise juhtimis-VM-iga 100% probleeme:
- seda ei saa oVirt-konsoolis migreerida klastri hostide (sõlmede) vahel;
- migreerimisel KVM-i kaudu virsh rännata, ei ole see VM oVirt-konsoolist haldamiseks saadaval.
- klastri hoste ei saa kuvada Hooldusrežiim (hooldusrežiim), kui migreerite selle VM-i hostist hosti kasutades virsh rännata.
Seega tee kõik reeglite järgi – kasuta kas oVirt haldusserveri jaoks eraldi hosti või sellel töötavat sõltumatut VM-i või veel parem – tee nii, nagu teises variandis kirjas.
Valik 2
oVirt Engine Appliance'i installimine selle hallatavasse klastri hosti.
Just seda võimalust peetakse meie puhul õigemaks ja sobivamaks.
Allpool on kirjeldatud nõudeid sellisele VM-ile, lisan vaid, et tõrketaluvuse tagamiseks on soovitatav, et taristus oleks vähemalt kaks hosti, millel saab juht-VM-i käivitada. Siinkohal tahaksin lisada, et nagu ma juba eelmises artiklis kommentaarides kirjutasin, ei saanud ma kordagi lõhenenud aju kahest hostist koosnevas oVirt-klastris, kus on võimalik käitada hostitud mootoriga VM-e.
oVirt Engine Appliance'i installimine klastri esimesse hosti
Link ametlikule dokumentatsioonile - , peatükk "»
Dokumendis täpsustatakse eeltingimused, mis peavad olema täidetud enne hostitud mootoriga VM-i juurutamist, ja kirjeldatakse üksikasjalikult ka installiprotsessi ennast, seega pole mõtet seda sõna-sõnalt korrata, seega keskendume mõnele olulisele detailile.
- Enne kõigi toimingute alustamist lubage hosti BIOS-i sätetes kindlasti virtualiseerimise tugi.
- Installige hostimootori installija pakett hosti:
yum -y install http://resources.ovirt.org/pub/yum-repo/ovirt-release43.rpm
yum -y install epel-release
yum install screen ovirt-hosted-engine-setup- Alustame oVirt Hosted Engine juurutamise protseduuri hosti ekraanil (saate sellest väljuda Ctrl-A + D abil, sulgeda Ctrl-D abil):
screen
hosted-engine --deploySoovi korral saate installi käivitada eelnevalt ettevalmistatud vastusefailiga:
hosted-engine --deploy --config-append=/var/lib/ovirt-hosted-engine-setup/answers/answers-ohe.conf- Hostimootori juurutamisel määrame kõik vajalikud parameetrid:
- имя кластера
- количество vCPU и vRAM (рекомендуется 4 vCPU и 16 Гб)
- пароли
- тип хранилища для hosted engine ВМ – в нашем случае FC
- номер LUN для установки hosted engine
- где будет находиться база данных для hosted engine – рекомендую для простоты выбрать Local (это БД PostgreSQL работающая внутри этой ВМ)
и др. параметры. - Väga kättesaadava hostitud mootoriga VM-i installimiseks lõime varem salvestussüsteemis spetsiaalse LUN-i, suurusega 4 ja 150 GB, mida seejärel esitleti klastri hostidele - vt. .
Varem kontrollisime ka selle nähtavust hostides:
multipath -ll
…
3600a098000e4b4b3000003c95d171065 dm-3 DELL , MD38xxf
size=150G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 rdac' wp=rw
|-+- policy='service-time 0' prio=14 status=active
| `- 15:0:0:4 sdc 8:32 active ready running
`-+- policy='service-time 0' prio=9 status=enabled
`- 18:0:0:4 sdj 8:144 active ready running- Hostimootori juurutamisprotsess ise pole keeruline; lõpuks peaksime saama midagi sellist:
[ INFO ] Generating answer file '/var/lib/ovirt-hosted-engine-setup/answers/answers-20191129131846.conf'
[ INFO ] Generating answer file '/etc/ovirt-hosted-engine/answers.conf'
[ INFO ] Stage: Pre-termination
[ INFO ] Stage: Termination
[ INFO ] Hosted Engine successfully deployedKontrollime oVirt-teenuste olemasolu hostis:
Kui kõik tehti õigesti, kasutage pärast installimise lõpetamist veebibrauserit administraatori arvutist ja klõpsake [Haldusportaal].
Ekraanipilt "Haldusportaalist"
Sisestades aknasse sisselogimise ja parooli (installiprotsessi käigus määratud) nagu ekraanipildil, jõuame Open Virtualization Manageri juhtpaneelile, kus saate teha kõiki virtuaalse infrastruktuuriga toiminguid:
- lisada andmekeskus
- klastri lisamine ja konfigureerimine
- lisada ja hallata hoste
- lisage virtuaalmasina ketaste salvestusalasid või salvestusdomeene
- lisage ja konfigureerige virtuaalmasinate jaoks võrke
- lisada ja hallata virtuaalmasinaid, installipilte, VM-malle
Kõiki neid toiminguid arutatakse edasi, mõned suurtes lahtrites, teised üksikasjalikumalt ja nüanssidega.
Kuid kõigepealt soovitaksin lugeda seda lisandmoodulit, mis on ilmselt paljudele kasulik.
Lisamine
1) Põhimõtteliselt ei takista miski sellise vajaduse korral KVM-i hüperviisorit pakettide abil eelnevalt klastri sõlmedesse installimast. libvirt и qemu-kvm (Või qemu-kvm-ev) soovitud versioonist, kuigi oVirt-klastri sõlme juurutamisel saab see seda ise teha.
Aga kui libvirt и qemu-kvm Kui te pole uusimat versiooni installinud, võite hostitud mootori juurutamisel kuvada järgmise tõrketeate:
error: unsupported configuration: unknown CPU feature: md-clearNeed. peab olema libvirt eest kaitstud , mis toetab seda poliitikat:
<feature policy='require' name='md-clear'/>Installige libvirt v.4.5.0-10.el7_6.12 koos md-cleari toega:
yum-config-manager --disable mirror.centos.org_centos-7_7_virt_x86_64_libvirt-latest_
yum install centos-release-qemu-ev
yum update
yum install qemu-kvm qemu-img virt-manager libvirt libvirt-python libvirt-client virt-install virt-viewer libguestfs libguestfs-tools dejavu-lgc-sans-fonts virt-top libvirt libvirt-python libvirt-client
systemctl enable libvirtd
systemctl restart libvirtd && systemctl status libvirtdKontrollige "md-clear" tuge:
virsh domcapabilities kvm | grep require
<feature policy='require' name='ss'/>
<feature policy='require' name='hypervisor'/>
<feature policy='require' name='tsc_adjust'/>
<feature policy='require' name='clflushopt'/>
<feature policy='require' name='pku'/>
<feature policy='require' name='md-clear'/>
<feature policy='require' name='stibp'/>
<feature policy='require' name='ssbd'/>
<feature policy='require' name='invtsc'/>Pärast seda saate jätkata hostitud mootori installimist.
2) oVirt 4.3 puhul tulemüüri olemasolu ja kasutamine tulemüür on kohustuslik nõue.
Kui hostitud mootori jaoks mõeldud VM-i juurutamise ajal kuvatakse järgmine tõrketeade:
[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "firewalld is required to be enabled and active in order to correctly deploy hosted-engine. Please check, fix accordingly and re-deploy.n"}
[ ERROR ] Failed to execute stage 'Closing up': Failed executing ansible-playbook
[https://bugzilla.redhat.com/show_bug.cgi?id=1608467Seejärel peate välja lülitama teise tulemüüri (kui seda kasutatakse) ning installima ja käivitama tulemüür:
yum install firewalld
systemctl enable firewalld
systemctl start firewalld
firewall-cmd --state
firewall-cmd --get-default-zone
firewall-cmd --get-active-zones
firewall-cmd --get-zonesHiljem ovirt agendi installimisel klastri uude hosti konfigureerib see vajalikud pordid tulemüür automaatselt.
3) Hosti taaskäivitamine, millel töötab VM koos hostitud mootoriga.
Nagu tavaliselt, и reguleerivate dokumentide juurde.
Kogu hostitud mootori VM-i haldamine toimub AINULT käsu abil hostitud mootor hostil, kus see jookseb, umbes Virsh peame unustama, samuti selle, et saate selle VM-iga ühenduse luua SSH kaudu ja käivitada käsk "seiskamine'.
VM-i hooldusrežiimi lülitamise protseduur:
hosted-engine --set-maintenance --mode=global
hosted-engine --vm-status
!! Cluster is in GLOBAL MAINTENANCE mode !!
--== Host host1.test.local (id: 1) status ==--
conf_on_shared_storage : True
Status up-to-date : True
Hostname : host1.test.local
Host ID : 1
Engine status : {"health": "good", "vm": "up", "detail": "Up"}
Score : 3400
stopped : False
Local maintenance : False
crc32 : dee1a774
local_conf_timestamp : 1821
Host timestamp : 1821
Extra metadata (valid at timestamp):
metadata_parse_version=1
metadata_feature_version=1
timestamp=1821 (Sat Nov 29 14:25:19 2019)
host-id=1
score=3400
vm_conf_refresh_time=1821 (Sat Nov 29 14:25:19 2019)
conf_on_shared_storage=True
maintenance=False
state=GlobalMaintenance
stopped=False
hosted-engine --vm-shutdownTaaskäivitame hosti hostitud mootoriagendiga ja teeme sellega, mida vajame.
Pärast taaskäivitamist kontrollige hostitud mootoriga VM-i olekut:
hosted-engine --vm-statusKui meie hostitud mootoriga VM ei käivitu ja näeme teenuselogis sarnaseid tõrkeid:
Viga teeninduslogis:
journalctl -u ovirt-ha-agent
...
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine ERROR Failed to start necessary monitors
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent ERROR Traceback (most recent call last):#012 File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", line 131, in _run_agent#012 return action(he)#012 File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", line 55, in action_proper#012 return he.start_monitoring()#012 File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py", line 413, in start_monitoring#012 self._initialize_broker()#012 File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py", line 537, in _initialize_broker#012 m.get('options', {}))#012 File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py", line 86, in start_monitor#012 ).format(t=type, o=options, e=e)#012RequestError: brokerlink - failed to start monitor via ovirt-ha-broker: [Errno 2] No such file or directory, [monitor: 'ping', options: {'addr': '172.20.32.32'}]
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent ERROR Trying to restart agentSeejärel ühendame salvestusruumi ja taaskäivitame agendi:
hosted-engine --connect-storage
systemctl restart ovirt-ha-agent
systemctl status ovirt-ha-agent
hosted-engine --vm-start
hosted-engine --vm-statusPärast VM-i käivitamist hostitud mootoriga eemaldame selle hooldusrežiimist:
VM-i hooldusrežiimist eemaldamise protseduur:
hosted-engine --check-liveliness
hosted-engine --set-maintenance --mode=none
hosted-engine --vm-status
--== Host host1.test.local (id: 1) status ==--
conf_on_shared_storage : True
Status up-to-date : True
Hostname : host1.test.local
Host ID : 1
Engine status : {"health": "good", "vm": "up", "detail": "Up"}
Score : 3400
stopped : False
Local maintenance : False
crc32 : 6d1eb25f
local_conf_timestamp : 6222296
Host timestamp : 6222296
Extra metadata (valid at timestamp):
metadata_parse_version=1
metadata_feature_version=1
timestamp=6222296 (Fri Jan 17 11:40:43 2020)
host-id=1
score=3400
vm_conf_refresh_time=6222296 (Fri Jan 17 11:40:43 2020)
conf_on_shared_storage=True
maintenance=False
state=EngineUp
stopped=False4) Hostitud mootori ja kõige sellega seotud eemaldamine.
Mõnikord on vaja eelnevalt installitud hostitud mootor korralikult eemaldada - juhenddokumendi juurde.
Käivitage lihtsalt hostis käsk:
/usr/sbin/ovirt-hosted-engine-cleanupJärgmisena eemaldame mittevajalikud paketid, vajadusel varundame mõned konfiguratsioonid enne seda:
yum autoremove ovirt* qemu* virt* libvirt* libguestfs Uue andmekeskuse loomine
Viitedokumentatsioon – oVirt haldusjuhend.
Kõigepealt määratleme, mis see on andmekeskus (Tsiteerin abist) on loogiline olem, mis määratleb konkreetses keskkonnas kasutatavate ressursside komplekti.
Andmekeskus on teatud tüüpi konteiner, mis koosneb:
- loogilisi ressursse klastrite ja hostide kujul
- klastri võrguressursid loogiliste võrkude ja hostidel olevate füüsiliste adapterite kujul,
- salvestusressursid (VM-ketaste, mallide, piltide jaoks) salvestusalade (Storage Domains) kujul.
Andmekeskus võib sisaldada mitut klastrit, mis koosnevad mitmest hostist, milles töötavad virtuaalmasinad, ning sellega võib olla seotud ka mitu salvestusala.
Andmekeskusi võib olla mitu, need töötavad üksteisest sõltumatult. Ovirtil on volitused rollide kaupa ja saate õigusi individuaalselt konfigureerida nii andmekeskuse tasemel kui ka selle üksikute loogiliste elementide puhul.
Andmekeskust või andmekeskusi, kui neid on mitu, hallatakse ühest halduskonsoolist või portaalist.
Andmekeskuse loomiseks minge haldusportaali ja looge uus andmekeskus:
Arvutama >> andmekeskuste >> Uus
Kuna me kasutame salvestussüsteemis jagatud salvestusruumi, peaks salvestuse tüüp olema jagatud:
Andmekeskuse loomise viisardi ekraanipilt
Kui installite hostitud mootoriga virtuaalmasina, luuakse vaikimisi andmekeskus - Andmekeskus 1ja seejärel saate vajaduse korral selle salvestustüübi teiseks muuta.
Andmekeskuse loomine on lihtne ülesanne, ilma keeruliste nüanssideta ning kõik sellega tehtavad lisatoimingud on kirjeldatud dokumentatsioonis. Ainus, mida ma märkan, on see, et üksikud hostid, millel on VM-ide jaoks ainult kohalik salvestusruum (ketas), ei pääse andmekeskusesse salvestustüübiga - jagatud (neid ei saa sinna lisada) ja nende jaoks peate looma eraldi andmekeskus – st. Iga kohaliku salvestusruumiga host vajab oma eraldi andmekeskust.
Uue klastri loomine
Link dokumentatsioonile – oVirt haldusjuhend.
Ilma tarbetute detailideta, klaster – see on hostide loogiline rühmitus, millel on ühine salvestusala (jagatud ketaste kujul salvestussüsteemis, nagu meie puhul). Samuti on soovitav, et klastri hostid oleksid riistvaralt identsed ja neil oleks sama tüüpi protsessor (Intel või AMD). Parim on muidugi see, et klastri serverid on täiesti identsed.
Klaster on osa andmekeskusest (teatud tüüpi salvestusruumiga - kohalik või Jagatud) ja kõik hostid peavad kuuluma mingisse klastrisse, olenevalt sellest, kas neil on jagatud salvestusruum või mitte.
Hostimootoriga virtuaalmasina installimisel hostile luuakse vaikimisi andmekeskus - Andmekeskus 1, koos klastriga – Klaster1, ja edaspidi saate seadistada selle parameetreid, lubada lisavõimalusi, lisada sellele hoste jne.
Nagu tavaliselt, on kõigi klastri sätete üksikasjade jaoks soovitatav vaadata ametlikku dokumentatsiooni. Mõnest klastri seadistamise funktsioonist lisan vaid selle, et selle loomisel piisab, kui konfigureerida vahekaardil ainult põhiparameetrid Üldine.
Märgin kõige olulisemad parameetrid:
- Protsessori tüüp — valitakse selle järgi, millised protsessorid on klastri hostidele installitud, mis tootjalt need on ja milline hostidel olev protsessor on vanim, nii et olenevalt sellest kasutatakse kõiki klastris olevaid protsessori juhiseid.
- Lüliti tüüp - meie klastris kasutame ainult Linuxi silda, seetõttu valime selle.
- Tulemüüri tüüp – siin on kõik selge, see on tulemüür, mis peab olema hostides lubatud ja konfigureeritud.
Ekraanipilt klastri parameetritega
Täiendavate hostide installimine isehostitavasse keskkonda
dokumenteerimiseks.
Isehostitava keskkonna täiendavad hostid lisatakse samamoodi nagu tavalisele hostile, lisatoiminguks on hostitud mootoriga VM juurutamine – Valige hostitud mootori juurutamise toiming >> juurutada. Kuna hostitud mootoriga VM-i jaoks tuleb lisahostile esitada ka LUN, tähendab see, et seda hosti saab vajadusel kasutada hostitud mootoriga VM-i hostimiseks.
Veataluvuse huvides on väga soovitatav, et hostitud mootori VM-i saab paigutada vähemalt kahele hostile.
Täiendavas hostis keelake iptables (kui see on lubatud), lubage tulemüür
systemctl stop iptables
systemctl disable iptables
systemctl enable firewalld
systemctl start firewalldInstallige vajalik KVM-versioon (vajadusel):
yum-config-manager --disable mirror.centos.org_centos-7_7_virt_x86_64_libvirt-latest_
yum install centos-release-qemu-ev
yum update
yum install qemu-kvm qemu-img virt-manager libvirt libvirt-python libvirt-client virt-install virt-viewer libguestfs libguestfs-tools dejavu-lgc-sans-fonts virt-top libvirt libvirt-python libvirt-client
systemctl enable libvirtd
systemctl restart libvirtd && systemctl status libvirtd
virsh domcapabilities kvm | grep md-clearInstallige vajalikud hoidlad ja hostitud mootori paigaldaja:
yum -y install http://resources.ovirt.org/pub/yum-repo/ovirt-release43.rpm
yum -y install epel-release
yum update
yum install screen ovirt-hosted-engine-setupJärgmisena minge konsooli Avage virtualiseerimishaldur, lisage uus host ja tehke kõike samm-sammult, nagu sisse kirjutatud .
Selle tulemusena peaksime pärast täiendava hosti lisamist saama midagi sellist, nagu on halduskonsoolis, nagu ekraanipildil.
Haldusportaali ekraanipilt – hostid
Hostil, millel hostitud mootoriga VM praegu aktiivne on, on kuldne kroon ja kiri "Hostitud mootori VM-i käitamine", host, millel selle VM-i saab vajadusel käivitada - silt "Saab käitada hostitud mootori VM-i'.
Hosti rikke korral, millel "Hostitud mootori VM-i käitamine", taaskäivitub see automaatselt teises hostis. Selle VM-i saab selle hooldamiseks migreerida ka aktiivsest hostist ooterežiimi hosti.
Toitehalduse / tara seadistamine oVirt hostidel
Dokumentatsiooni lingid:
- Red Hat virtualiseerimine 4.3 –> Tehniline viide ->
- oVirt haldusjuhend ->
Kuigi võib tunduda, et olete hosti lisamise ja konfigureerimise lõpetanud, pole see päris tõsi.
Hostide normaalseks tööks ja nende tõrgete tuvastamiseks/lahendamiseks on vaja toitehalduse/tarastuse sätteid.
Vehklemine, ehk piiramine, on vigase või ebaõnnestunud hosti ajutine klastrist väljajätmise protsess, mille käigus taaskäivitatakse sellel olevad oVirt-teenused või host ise.
Kõik üksikasjad toitehalduse / tara määratluste ja parameetrite kohta on esitatud nagu tavaliselt dokumentatsioonis; Toon ainult näite selle olulise parameetri konfigureerimisest, nagu seda rakendatakse iDRAC 640-ga Dell R9 serveritele.
- Minge haldusportaali, klõpsake nuppu Arvutama >> hosts vali host.
- Klõpsake Edit.
- Klõpsake vahekaarti power Management.
- Märkige valiku kõrval olev ruut Toitehalduse lubamine.
- Märkige valiku kõrval olev ruut Kdump integratsioonvältimaks hosti kerneli krahhi tõmmise salvestamise ajal piiramisrežiimi minemist.
Märkus.
Pärast Kdumpi integreerimise lubamist juba töötavas hostis tuleb see uuesti installida vastavalt oVirt haldusjuhendis toodud protseduurile -> -> Hostide uuesti installimine.
- Soovi korral saate ruudu märkida Keela toitehalduse poliitikakontroll, kui me ei soovi, et hosti toitehaldust juhiks klastri ajastamispoliitika.
- Klõpsake nuppu (+) uue toitehaldusseadme lisamiseks avaneb agendi omaduste redigeerimise aken.
iDRAC9 puhul täitke järgmised väljad:- AADRESS – iDRAC9 aadress
- Kasutajanimi Parool – vastavalt sisselogimine ja parool iDRAC9-sse sisselogimiseks
- KASUTUSALA -drac5
- märk Kindlustama
- lisage järgmised valikud: cmd_prompt=>,login_timeout=30
Ekraanipilt „Toitehalduse” parameetritega hosti atribuutides
Salvestusala või salvestusdomeenide loomine
Link dokumentatsioonile – oVirt haldusjuhend, .
Salvestusdomeen, ehk salvestusala, on tsentraliseeritud koht virtuaalmasina ketaste, installipiltide, mallide ja hetktõmmiste salvestamiseks.
Salvestusalasid saab andmekeskusega ühendada erinevate protokollide, klastri- ja võrgufailisüsteemide abil.
oVirt pakub kolme tüüpi laopinda:
- Andmete domeen – salvestada kõik virtuaalmasinatega seotud andmed (kettad, mallid). Andmedomeeni ei saa jagada erinevate andmekeskuste vahel.
- ISO domeen (vananenud salvestusala tüüp) – OS-i installipiltide salvestamiseks. ISO domeeni saab jagada erinevate andmekeskuste vahel.
- Ekspordi domeen (vananenud salvestusala tüüp) – andmekeskuste vahel teisaldatud piltide ajutiseks salvestamiseks.
Meie konkreetsel juhul kasutab andmedomeeni tüüpi salvestusala Fibre Channel Protocol (FCP) salvestussüsteemi LUN-idega ühenduse loomiseks.
OVirti seisukohalt on salvestussüsteemide (FC või iSCSI) kasutamisel iga virtuaalne ketas, hetktõmmis või mall loogiline ketas.
Plokkseadmed koondatakse üheks üksuseks (klastri hostidel) Volume Groupi abil ja seejärel jagatakse LVM-i abil loogilisteks köideteks, mida kasutatakse virtuaalsete masinate jaoks virtuaalketastena.
Kõiki neid rühmi ja paljusid LVM-i köiteid saab käskude abil näha klastri hostis jne и lvs. Loomulikult tuleks kõiki toiminguid selliste ketastega teha ainult oVirt-konsoolist, välja arvatud erijuhtudel.
Virtuaalarvutite virtuaalseid kettaid võib olla kahte tüüpi – QCOW2 või RAW. Plaadid võivad olla "õhuke"või"paks". Hetketõmmised luuakse alati kui "õhuke".
Storage domeenide ehk FC kaudu ligipääsetavate salvestusalade haldamise viis on üsna loogiline – iga VM virtuaalse ketta jaoks on eraldi loogiline köide, mida saab kirjutada ainult üks host. FC-ühenduste jaoks kasutab oVirt midagi sellist nagu rühmitatud LVM.
Samal salvestusalal asuvaid virtuaalmasinaid saab migreerida samasse klastrisse kuuluvate hostide vahel.
Nagu kirjeldusest näeme, tähendab klaster oVirtis, nagu klaster VMware vSphere'is või Hyper-V-s, sisuliselt sama asja – see on hostide loogiline rühmitus, mis on riistvara koostiselt eelistatavalt identne ja millel on virtuaalse salvestusruumi jaoks ühine salvestusruum. masina kettad.
Jätkame otse andmete (VM-ketaste) salvestusala loomisega, kuna ilma selleta andmekeskust ei lähtestata.
Lubage mul teile meelde tuletada, et kõik salvestussüsteemis klastri hostidele esitatud LUN-id peavad olema neil nähtavad, kasutades käsku "multipath -ll'.
Vastavalt , minge portaali, minge aadressile Säilitamine >> Domeenid -> Uus domeen ja järgige jaotises "FCP salvestusruumi lisamine" olevaid juhiseid.
Pärast viisardi käivitamist täitke nõutud väljad:
- Nimi — määrake klastri nimi
- Domeeni funktsioon — Andmed
- Salvestuse tüüp - Fiber kanal
- Kasutatav host — valige host, millel meie vajalik LUN on saadaval
Märkige LUN-ide loendis see, mida vajame, klõpsake nuppu lisama ja siis ОК. Vajadusel saate klõpsates reguleerida salvestusala täiendavaid parameetreid Täiustatud parameetrid.
Ekraanipilt „Salvestusdomeeni” lisamise viisardist
Nõustaja tulemuste põhjal peaksime saama uue salvestusala ja meie andmekeskus peaks liikuma olekusse UPvõi initsialiseeritud:
Ekraanipildid andmekeskusest ja selles asuvatest salvestusaladest:
Virtuaalsete masinate võrkude loomine ja seadistamine
Link dokumentatsioonile – oVirt haldusjuhend,
Võrgud või võrgud on mõeldud oVirt virtuaalses infrastruktuuris kasutatavate loogiliste võrkude rühmitamiseks.
Virtuaalse masina võrguadapteri ja hosti füüsilise adapteri vahel suhtlemiseks kasutatakse loogilisi liideseid, näiteks Linuxi silda.
Liikluse rühmitamiseks ja jagamiseks võrkude vahel on lülitites konfigureeritud VLAN-id.
Virtuaalsete masinate loogilise võrgu loomisel oVirtis tuleb sellele määrata lülitil olevale VLAN-i numbrile vastav identifikaator, et VM-id saaksid omavahel suhelda, isegi kui nad töötavad klastri erinevates sõlmedes.
Virtuaalsete masinate ühendamiseks tuli sisse teha hostide võrguadapterite eelseaded - konfigureeritud loogiline liides võlakiri1, siis tuleks kõik võrguseaded teha ainult oVirt haldusportaali kaudu.
Pärast hostitud mootoriga VM-i loomist loodi lisaks andmekeskuse ja klastri automaatsele loomisele meie klastri haldamiseks automaatselt ka loogiline võrk - ovritmgmt, millega see VM oli ühendatud.
Vajadusel saate vaadata loogilisi võrgusätteid ovritmgmt ja neid kohandada, kuid peate olema ettevaatlik, et mitte kaotada kontrolli oVirt infrastruktuuri üle.
Loogilise võrgu seaded ovritmgmt
Tavaliste VM-ide jaoks uue loogilise võrgu loomiseks minge haldusportaalis aadressile võrk >> Networks >> Uusja vahekaardil Üldine lisage soovitud VLAN-i ID-ga võrk ja märkige ka ruut valiku "VM-võrk", see tähendab, et seda saab kasutada VM-ile määramiseks.
Ekraanipilt uuest VLAN32 loogilisest võrgust
Vahekaardil Cluster, ühendame selle võrgu oma klastriga Klaster1.
Pärast seda läheme Arvutama >> hosts, minge kordamööda iga hosti juurde vahekaardile Võrgu liidesedja käivitage viisard Seadistage hostivõrgud, uue loogilise võrgu hostidega sidumiseks.
Ekraanipilt viisardist „Hotstivõrkude seadistamine”.
oVirt agent teeb automaatselt hostis kõik vajalikud võrguseaded – loob VLAN ja BRIDGE.
Hosti uute võrkude konfiguratsioonifailide näited:
cat ifcfg-bond1
# Generated by VDSM version 4.30.17.1
DEVICE=bond1
BONDING_OPTS='mode=1 miimon=100'
MACADDR=00:50:56:82:57:52
ONBOOT=yes
MTU=1500
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=no
cat ifcfg-bond1.432
# Generated by VDSM version 4.30.17.1
DEVICE=bond1.432
VLAN=yes
BRIDGE=ovirtvm-vlan432
ONBOOT=yes
MTU=1500
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=no
cat ifcfg-ovirtvm-vlan432
# Generated by VDSM version 4.30.17.1
DEVICE=ovirtvm-vlan432
TYPE=Bridge
DELAY=0
STP=off
ONBOOT=yes
MTU=1500
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=noLubage mul teile veel kord meelde tuletada, et klastri hosti puhul POLE TARVIS luua võrguliidesed eelnevalt käsitsi ifcfg-bond1.432 и ifcfg-ovirtvm-vlan432.
Pärast loogilise võrgu lisamist ning hosti ja hostitud mootori VM-i vahelise ühenduse kontrollimist saab seda virtuaalmasinas kasutada.
Virtuaalse masina juurutamiseks installipildi loomine
Link dokumentatsioonile – oVirt haldusjuhend, , jaotis Piltide üleslaadimine andmesalvestusdomeeni.
Ilma OS-i installipildita pole virtuaalset masinat võimalik installida, kuigi see pole muidugi probleem, kui see on näiteks võrku installitud eelnevalt loodud piltidega.
Meie puhul pole see võimalik, seega peate selle pildi ise oVirti importima. Varem oli selleks vaja ISO domeeni loomist, kuid oVirt uues versioonis on see aegunud ja seetõttu saab nüüd administratiivportaalist pilte otse Storage domeeni üles laadida.
Minge haldusportaalis aadressile Säilitamine >> Disks >> Täiendava >> Avaleht
Lisame oma OS-i pildi ISO-failina, täidame kõik vormi väljad ja klõpsame nuppu "Katsetage ühendust".
Installipildi lisamise viisardi ekraanipilt
Kui saame sellise vea:
Unable to upload image to disk d6d8fd10-c1e0-4f2d-af15-90f8e636dadc due to a network error. Ensure that ovirt-imageio-proxy service is installed and configured and that ovirt-engine's CA certificate is registered as a trusted CA in the browser. The certificate can be fetched from https://ovirt.test.local/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA`
Seejärel peate lisama oVirt sertifikaadi kausta "Usaldusväärsed juur-CA-d"(Trusted Root CA) administraatori juhtimisjaamas, kust proovime pilti alla laadida.
Pärast sertifikaadi lisamist usaldusväärse juur-CA-sse klõpsake uuesti "Katsetage ühendust", peaks saama:
Connection to ovirt-imageio-proxy was successful.Kui olete sertifikaadi lisamise lõpetanud, võite proovida ISO-pildi uuesti salvestusdomeeni üles laadida.
Põhimõtteliselt saate teha andmetüübiga eraldi salvestusdomeeni, et salvestada pilte ja malle VM-ketastest eraldi, või isegi salvestada need hostitud mootori jaoks salvestusdomeeni, kuid see on administraatori äranägemisel.
Ekraanipilt ISO-kujutistega hostitud mootori salvestusdomeenis
Looge virtuaalne masin
Dokumentatsiooni link:
oVirt virtuaalmasina haldusjuhend –>
Pärast OS-i installipildi laadimist oVirtisse saate jätkata otse virtuaalse masina loomisega. Palju tööd on tehtud, kuid oleme juba lõppjärgus, mille nimel seda kõike alustati - tõrketaluva taristu hankimine kõrge kättesaadavusega virtuaalmasinate majutamiseks. Ja see kõik on täiesti tasuta – ühegi tarkvaralitsentsi ostmisele ei kulutatud ühtegi senti.
CentOS 7-ga virtuaalmasina loomiseks tuleb OS-ist alla laadida installipilt.
Me läheme haldusportaali, minge aadressile Arvutama >> Virtuaalsed masinadja käivitage VM-i loomise viisard. Täitke kõik parameetrid ja väljad ning klõpsake nuppu ОК. Kõik on väga lihtne, kui järgite dokumentatsiooni.
Näitena toon väga kättesaadava VM-i põhi- ja lisaseaded, millel on loodud ketas, mis on ühendatud võrku ja käivitatakse installipildilt:
Väga saadaolevate VM-i sätetega ekraanipildid
Pärast viisardiga töö lõpetamist sulgege see, käivitage uus VM ja installige sellele OS.
Selleks minge haldusportaali kaudu selle VM-i konsooli:
Ekraanipilt haldusportaali sätetest VM-konsooliga ühenduse loomiseks
VM-konsooliga ühenduse loomiseks peate esmalt konfigureerima konsooli virtuaalmasina atribuutides.
VM-i sätete ekraanipilt, vahekaart „Konsool”.
VM-konsooliga ühenduse loomiseks võite kasutada näiteks .
VM-konsooliga otse brauseriaknas ühenduse loomiseks peaksid konsooli kaudu ühenduse seaded olema järgmised:
Pärast OS-i installimist VM-ile on soovitatav installida oVirt külalisagent:
yum -y install epel-release
yum install -y ovirt-guest-agent-common
systemctl enable ovirt-guest-agent.service && systemctl restart ovirt-guest-agent.service
systemctl status ovirt-guest-agent.serviceSeega on meie tegevuse tulemusena loodud VM kõrgelt kättesaadav, s.o. kui klastri sõlm, millel see töötab, ebaõnnestub, taaskäivitab oVirt selle automaatselt teises sõlmes. Seda VM-i saab migreerida ka klastri hostide vahel nende hooldamiseks või muudel eesmärkidel.
Järeldus
Loodan, et see artikkel suutis anda mõista, et oVirt on täiesti tavaline virtuaalse infrastruktuuri haldamise tööriist, mille juurutamine polegi nii keeruline – peaasi, et järgida teatud reegleid ja nõudeid, mis on kirjeldatud nii artiklis kui ka dokumentatsioonis.
Artikli suure mahu tõttu ei olnud võimalik sinna lisada paljusid asju, näiteks erinevate võlurite samm-sammult täitmine koos kõigi üksikasjalike selgituste ja ekraanipiltidega, mõnede käskude pikad järeldused jne. Tegelikult eeldaks see terve raamatu kirjutamist, millel pole erilist mõtet, kuna pidevalt ilmuvad uued tarkvaraversioonid koos uuenduste ja muudatustega. Kõige olulisem on mõista selle kõige koos toimimise põhimõtet ja saada üldine algoritm virtuaalmasinate haldamiseks tõrketaluva platvormi loomiseks.
Kuigi oleme loonud virtuaalse infrastruktuuri, peame nüüd õpetama seda suhtlema nii selle üksikute elementide vahel: hostid, virtuaalmasinad, sisevõrgud ja välismaailmaga.
See protsess on süsteemi- või võrguadministraatori üks peamisi ülesandeid, mida käsitletakse järgmises artiklis - VyOS-i virtuaalsete ruuterite kasutamise kohta meie ettevõtte tõrketaluvas infrastruktuuris (nagu arvasite, töötavad need virtuaalsena meie oVirt klastri masinad).
Allikas: www.habr.com