Tõrkeületava IT infrastruktuuri loomine. Osa 2. oVirt 4.3 kihi installimine ja seadistamine

See artikkel on jätk eelmisele – „Tõrkeületava IT infrastruktuuri loomine. Osa 1 — ettevalmistus oVirt 4.3 kihi juurutamiseks».

Selles käsitletakse oVirt 4.3 kihi baasinstalli ja seadistamise protsessi, et majutada kõrgelt kättesaadavaid virtuaalmasinaid, arvestades, et kõik eelnevad infrastruktuuri ettevalmistamise sammud on juba tehtud.

Sissejuhatus

Artikli peamine eesmärk ei ole niivõrd anda samm-sammult juhendit tüüpi „Järgmine -> Jah -> Lõpeta“, vaid näidata mõned eripärad selle installimisel ja seadistamisel. Teie kihi juurutamisprotsess ei pruugi alati vastata sellele, mis on siin kirjeldatud, sõltuvalt infrastruktuuri ja keskkonna eripäradest, kuid üldised põhimõtted jäävad samaks.

Subjektiivsest vaatenurgast, oVirt 4.3 on oma funktsionaalsuses sarnane VMware vSphere versiooniga 5.x, kuid loomulikult on seal omad seadmise ja töötamise eripärad.

Huvi korral võib kõik erinevused RHEV (tuntud ka kui oVirt) ja VMware vSphere vahel leida internetist, näiteks siit, kuid ma tõstan ikka esile nende vahelisi erinevusi või sarnaseid jooni artikli käigus.

Soovin veidi võrrelda ka võrke, mis on seotud virtuaalmasinatega. oVirtis on rakendatud sarnane võrgu haldamise põhimõte virtuaalmasinatele (edasi lühendatult VM) nagu VMware vSphere'is:

• standardse Linuxi silla abil (VMwares — Standard vSwitch), mis töötab virtualiseerimise hostides;
• Open vSwitchi (OVS) abil (VMwares — Distributed vSwitch) – see on jaotatud virtuaalswitch, mis koosneb kahest põhikomponendist: kesksest OVN-serverist ja OVN-kontrolleritest hallatavates hostides.

Oluline on märkida, et rakenduse lihtsuse tõttu kirjeldatakse artiklis võrgu seadistamist oVirtis VM-ide jaoks standardse Linuxi silda kasutades, mis on KVM hüperviisorit kasutades optimaalne valik.

Selle seose tõttu kehtivad ridade võrgu haldamisel klastris järgmised põhireeglid, millest tasub kinni pidada:

• Kasutajate teabe seadistamine hostides peab olema enne nende lisamist oVirtisse ühesugune, välja arvatud IP-aadressid.
• Pärast seda, kui host on üle viidud oVirt'i juhtimise alla, ei soovitata sellel käsitsi võrgu seadetes muudatusi teha, kui ei ole täielikku kindlust oma tegevustes, kuna oVirt'i agent lihtsalt tagastab need eelnevatele seadetele pärast hosti või agendi taaskäivitamist.
• Uue võrgu lisamine VM-ile ja selle haldamine peaks toimuma ainult oVirt juhtimiskeskkonnast.

Veel üks oluline märkus — väga kriitilise keskkonna (mis on raha kaotuse suhtes ülitundlik) puhul soovitatakse siiski kasutada tasulist tuge ja rakendada Red Hat Virtualization 4.3. oVirt klastrit kasutades võivad tekkida olukorrad, kus on soovitatav võimalikult kiiresti küsida kvalifitseeritud abi, mitte üritada ise toime tulla.

Ja lõpuks, soovitame enne oVirt klastri käivitamist tutvuda ametliku dokumentatsiooniga, et olla kursis vähemalt põhiteadmiste ja definitsioonidega, muidu võib edasine lugemine olla veidi keeruline.

Arusaamiseks artiklist ja oVirt klastrite tööpõhimõtetest on need juhised aluseks:

• oVirt Installation Guide
• oVirt Self-Hosted Engine Guide
• oVirti haldusjuhend
  

Selle maht ei ole väga suur, tunni või kahe jooksul on võimalik omandada põhialused, ja detailide armastajatele soovitatakse lugeda. Tootedokumentatsioon Red Hat Virtualization 4.3 jaoks — RHEV ja oVirt on põhimõtteliselt ühesugused.

Nii et kui kõik põhiseaded hostides, lülitites ja SAN-is on tehtud, liikume otse oVirti juurutamise juurde.

Osa 2. oVirt 4.3 klastrite installimine ja seadistamine

Kasutusmugavuse huvides toon loetelu peamistest jaotistest, mis järk-järgult tuleb täita:

1. oVirti juhtserveri installimine
2. Uue andmekeskuse loomine
3. Uue klastrite loomine
4. Lisahostide installimine iseseisvasse keskkonda
5. Salvestusala või Storage Domains loomine
6. Võrgustike loomine ja seadistamine virtuaalmasinate jaoks
7. Installeerimise pildi loomine virtuaalmasina juurutamiseks
8. Virtuaalmasina loomine

oVirti juhtserveri installimine

oVirti juhtserver on kõige olulisem element oVirti infrastruktuuris, mis võib olla virtuaalmasina, hosti või virtuaalse seadmena, mis haldab kogu oVirti infrastruuri.

Selle lähedased analoogid virtualiseerimise maailmas:

• VMware vSphere — vCenter Server
• Microsoft Hyper-V — System Center Virtual Machine Manager (VMM).

oVirti haldusserveri installimiseks on meil kaks võimalust:

Valik 1
Serveri käivitamine spetsialiseeritud virtuaalmasina või hostina.

See variant töötab, kuid tingimusel, et selline virtuaalmasin töötab iseseisvalt klastrist, st ei ole käivitatud ühelgi klastrihostil tavalisena KVM-i haldamisel.

Miks ei tohi sellist virtuaalmasinat klastrihostides käivitada?

oVirti haldusserveri käivitamise protsessi alguses seisame silmitsi dilemmas — hallatav virtuaalmasin tuleb installida, kuid klastrit endiselt tegelikult ei ole, seega mida saab koheselt välja mõelda? Täpselt – installida KVM tulevases klastrisõlmes, seejärel luua seal virtuaalmasin, näiteks CentOS operatsioonisüsteemiga ja sellel käivitada oVirt engine. Seda võib teha tavaliselt täieliku juhtimise tagamiseks sellise virtuaalmasina üle, kuid see on vale lähenemine, sest hiljem võivad tekkida 100% probleemid sellise hallatava virtuaalmasinaga:

• seda ei saa migreerida oVirti konsoolis klastrihostide (sõlmede) vahel;
• KVM-i kaudu migreerimise korral virsh migrate, see VM ei ole saadaval oVirti konsoolist haldamiseks.
• klastri hoste ei saa kuvada Hooldusrežiim (Hooldusrežiim), kui selles VM migratsiooni hakatakse hostist hosti kaudu virsh migrate.

Niisiis, tehke kõik õigesti — kasutage oVirti juhtserverina kas eraldi hosti või sõltumatut VM-d, mis töötab sellel, ning veel parem, toimige nagu on öeldud teises variandis.

Variant 2
oVirt Engine Appliance'i installimine selle haldamise alla kuuluvale hostile.

Just seda varianti käsitletakse järgmisena, kui õigemat ja sobivamat meie olukorras.
Selle VM-i nõuded on allpool kirjeldatud, lisaks mainin, et soovitatakse omada vähemalt kahte hosti infrastruktuuris, kus haldavat VM-i saab käivitada, et muuta see tõrkevastaseks. Siin tahaksin lisada, et nagu olen juba eelnevates artiklites kommenteerinud, ei ole mul õnnestunud saavutada splitbrain kaks hosti toetava oVirti klastris, mille kaudu on võimalik käivitada hosted-engine VM-e.

oVirt Engine Appliance'i installimine esimesel hostil

Link ametlikule dokumentatsioonile — oVirt Self-Hosted Engine Guide, peatükk „Iseseisva mootori juurutamine käsurealt»

Dokumendis on välja toodud eeldused, mis peavad olema täidetud enne hosted-engine VM-i kasutuselevõttu, samuti on põhjalikult kirjeldatud selle installimise protsessi, seega pole mõtet seda sõnasõnaliselt korrata, keskendume mõnedele olulistele detailidele.

• Enne kõiki toiminguid lülitage kindlasti BIOS-i seadetes sisse virtualiseerimise tugi hostis.
• Installige hostile hosted-engine installeripakett:

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

• Käivitage hostis oVirt Hosted Engine'i kasutuselevõtt screen'i kaudu (kustuda saab Ctrl-A + D, sulgeda Ctrl-D):

screen
hosted-engine --deploy

Soovi korral saab installimise käivitada ettevalmistatud vastustefailiga:

hosted-engine --deploy --config-append=/var/lib/ovirt-hosted-engine-setup/answers/answers-ohe.conf

• Hosted-engine'i kasutuselevõtu ajal määrake kõik vajalikud parameetrid:

- klastrinimi
- vCPU ja vRAM arv (soovitatavalt 4 vCPU ja 16 GB)
- paroolid
- salvestustüüp hosted engine VM jaoks – meie puhul FC
- LUN number hosted engine'i paigaldamiseks
- kus asub hosted engine'i andmebaas – lihtsuse huvides soovitan valida Local (see on PostgreSQL andmebaas, mis toimib selles VM-i sees)
ja muid parameetreid. 

• Kõrge saadavusega hosted engine VM-i installimiseks oleme meie poolt andmesalvestuses eelnevalt loonud spetsiaalse LUN-i numbriga 4 ja suurusega 150 GB, misjärel see esitati klastrite hostidele – vt. eelnevas artiklis.

Varasemalt 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

• Hosted-engine'i juurutamise protsess ei ole keeruline, lõpus peaksime saama umbes sellise sõnumi:

[ 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 deployed

Kontrollime oVirt teenuste olemasolu hostis:

Kui kõik on õigesti tehtud, siis pärast installatsiooni lõppu pääseme veebibrauseriga aadressile https://ovirt_hostname/ovirt-engine administratori arvutist ja klikkime [Administration Portal].

Ekraanipilt „Administration Portal’ist”

Sisestades sisselogimise ja parooli (mida seati installatsiooni käigus) aknas nagu ekraanipildil, pääseme Open Virtualization Manageri halduspaneeli, kus on võimalik teha kõiki toiminguid virtuaalse infrastruktuuriga:

1. lisada andmekeskus
2. lisada ja konfigureerida klaster
3. lisada hoste ja hallata neid
4. lisada salvestusruume või Storage Domains virtuaalmasinate kõvaketaste jaoks
5. lisada ja konfigureerida virtuaalmasinate võrgud
6. lisada virtuaalmasinaid, installipilte, VM-malle ja hallata neid

Kõiki neid toiminguid käsitletakse allpool, mõningad suuremas mahus, teised detailsemalt ja nüansirikkamalt.
Aga esmalt soovitaksin lugeda seda täiendust, mis kindlasti paljudele kasuks võib tulla.

Täiendamine

1) Põhimõtteliselt, kui on selline vajadus, ei takista miski KVM hüperviisori eelinstallimist klastri sõlmedesse, kasutades pakette libvirt ja qemu-kvm (või qemu-kvm-ev) soovitud versioon, kuigi oVirt klastrisõlme juurutamisel võib see seda teha ka ise.

Aga kui libvirt ja qemu-kvm ei ole installitud kõige uuemat versiooni, siis võib hosted engine'i juurutamisel tekkida selline viga:

error: unsupported configuration: unknown CPU feature: md-clear

St. on vajalik uuendatud versioon libvirt md-clear kaitsega MDS, mis toetab sellist poliitikat:

<feature policy='require' name='md-clear'/>

Paigaldame libvirt v.4.5.0-10.el7_6.12, md-clear toe:

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

Kontrollime 'md-clear' toe olemasolu:

virsh domcapabilities kvm | grep require

Pärast seda võite jätkata hosted engine'i installimist.

2) oVirt 4.3 puhul on tulemüüri olemasolu ja kasutamine firewalld on vajalik nõue.

Kui hosted-engine'i VM-i juurutamisel tekib järgmine viga:

[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "firewalld peab olema lubatud ja aktiivne, et hosted-engine õigesti juurutada. Palun kontrollige, parandage vastavalt ja juurutage uuesti."}
[ ERROR ] Ebaõnnestus etapi 'Sulgemine' täitmine: ansible-playbook'i täitmine ebaõnnestus
[https://bugzilla.redhat.com/show_bug.cgi?id=1608467

Seega tuleb teine tulemüür (kui seda kasutatakse) välja lülitada ning firewalld:

installida ja käivitada

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-zones

Edasi, uue klastriteenuse hosti ovirt-agendi installimise korral seadistab see vajalikud pordid firewalld automaatselt.

3) Hosti taaskäivitamine, millel on toimiv VM hosted-engineiga.

Nagu tavaliselt, link 1 ja link 2 juhendite dokumentidele.

Kogu hosted-engine VM-i haldamine toimub AINULT käsu kaudu hosted-engine hostis, kus see töötab, virsh saab unustada, samuti tuleb unustada, et sellele VM-le saab ühenduda SSH kaudu ja selles täita käsku «shutdown».

VM-i hooldusrežiimi viimise protseduur:

hosted-engine --set-maintenance --mode=global

hosted-engine --vm-status
!! Klaster on GLOBAL MAINTENANCE režiimil !!
--== Host host1.test.local (id: 1) olek ==--
conf_on_shared_storage             : True
Status ajakohane                    : True
Hostname                           : host1.test.local
Host ID                            : 1
Mootori olek                      : {"health": "good", "vm": "up", "detail": "Up"}
Skoor                              : 3400
peatanud                        : False
Kohalik hooldus                  : False
crc32                              : dee1a774
local_conf_timestamp               : 1821
Host ajamärk                     : 1821
Lisa metaandmed (kehtivad ajamärgi järgi):
        metadata_parse_version=1
        metadata_feature_version=1
        timestamp=1821 (Laup Nov 29 14:25:19 2019)
        host-id=1
        score=3400
        vm_conf_refresh_time=1821 (Laup Nov 29 14:25:19 2019)
        conf_on_shared_storage=True
        maintenance=False
        state=GlobalMaintenance
        stopped=False

hosted-engine --vm-shutdown

Taaskäivitame hosti hosted engine agendi abil ja teeme sellega, mida vajame.

Pärast taaskäivitamist kontrollime VM staatust hosted engine'iga:

hosted-engine --vm-status

Kui meie VM hosted-engine'iga ei käivitu ja kui näeme teenuse logis sarnaseid vigu:

Viga teenuse logis:

journalctl -u ovirt-ha-agent
...
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine ERROR Ei suutnud käivitada vajalikke monitoore
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent ERROR Jälgimisprotsessi tõrge (viimane kõne viidatud):#012  Fail "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", rida 131, funktsioonis _run_agent#012    return action(he)#012  Fail "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", rida 55, funktsioonis action_proper#012    return he.start_monitoring()#012  Fail "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py", rida 413, funktsioonis start_monitoring#012    self._initialize_broker()#012  Fail "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py", rida 537, funktsioonis _initialize_broker#012    m.get('options', {}))#012  Fail "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py", rida 86, funktsioonis start_monitor#012    ).format(t=type, o=options, e=e)#012RequestError: brokerlink - ei suutnud käivitada monitori ovirt-ha-broker kaudu: [Errno 2] Faili või katalooge ei leitud, [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 Proovib agenti taaskäivitada

Seome 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-status

Pärast masinavahe käivitamist hosted-engine'iga, eemaldame selle hooldusrežiimist:

Masinavahe väljaarvamise protseduur hooldusrežiimist:

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=False

4) Hosted engine ja kõik sellega seotud eemaldamine.

Mõnikord on vajalik õigesti eemaldada varem installitud hosted engine — link seotud juhenddokumendi.

Lihtsalt täidame käsu hostis:

/usr/sbin/ovirt-hosted-engine-cleanup

Seejärel eemaldame mittevajalikud paketid, varundades enne seda mõned konfiguratsioonifailid, kui see on vajalik:

yum autoremove ovirt* qemu* virt* libvirt* libguestfs 

Uue andmekeskuse loomine

Kasutusjuhend — oVirt Administration Guide. Lood: Andmepunktid

Esmalt määratleme, mis on andmepunkt (tsiteerin abimaterjalist) — see on loogiline entiteet, mis määratleb ressursside komplekti, mida kasutatakse konkreetsetes tingimustes.

Andmesenter on omamoodi konteiner, mis koosneb:

• loogilistest ressurssidest klastrite ja hostide vormis
• võrguressurssidest klastrites loogiliste võrkude ja füüsiliste adaptsioonide vormis hostidel,
• salvestusressurssidest (VM-ide kettad, mallid, pildid) salvestusala (Storage Domains) vormis.

Andmesenter võib sisaldada mitmeid klastreid, millel on mitmed hostid koos nendel töötavate virtuaalmasinatega, samuti võivad sellega olla seotud mitmed salvestusalad.
Andmesentreid võib olla mitu, need töötavad iseseisvalt. Ovirtis on rollide järgi õiguste jaotamine, ja õigusi saab seadistada individuaalselt nii andmesentril kui selle eraldi loogilistel elementidel.

Andmesenter, või andmesentreid, kui neid on mitu, hallatakse ühest administratiivkonsoolist või portaalist.

Andmesentra loomiseks siseneme administratiivportaalile ja loome uue andmesentra:
Arvutus >> Andmesentrid >> Uus

Kuna kasutame ühiseid salvestusi SAN-il, peab salvestustüüp (Storage Type) olema Shared:

Kuvapilt andmesentra loomiseks viisist

Virtuaalmasina seadistamisel koos hosted-engine'iga luuakse vaikimisi andmepunkt – Andmepunkt1, ning vajadusel saab selle salvestusvahet (Storage Type) muuta teiseks.

Andmepunkti loomine on lihtne ülesanne, ilma keeruliste nüanssideta, ning kõik täiendavad toimingud on dokumentatsioonis kirjas. Tuleb siiski märkida, et üksikhostid, millel on ainult lokaalne salvestus (ketas) VM-ide jaoks, ei saa andmepunkti, mille salvestusvahet on – Shared, lisatud (neid ei saa sinna lisada), ning nende jaoks tuleb luua eraldi andmepunkt – see tähendab, et igaühele eraldi hostile lokaalse salvestusega on vajalik oma eraldi andmepunkt.

Uue klastrite loomine

Dokumentatsioonile viitamine – oVirt Administration Guide. Peatükk 5: Klasterd

Ilma liigsete detailideta, klaster – see on loogiline gruppeerimine hostidest, mis omavad ühist salvestusruumi (näiteks jagatud kettad SAN-is, nagu meie puhul). Samuti on soovitatav, et klastris olevad hostid oleksid riistvaralt sarnased ja neil oleks sama protsessoritüüp (Intel või AMD). Parim oleks muidugi, et klasteri serverid oleksid täielikult identsed.

Klaster kuulub andmepunkti koosseisu (teatud salvestusvahetiga – Lokaalne või Jagatud), ja kõik hostid peavad tingimata kuuluma mingisse klastrisse, sõltuvalt sellest, kas neil on ühine salvestus või mitte.

Virtuaalmasina loomisel hosted-engine'iga hostile luuakse vaikimisi andmekeskus — Andmepunkt1, koos klastri – Cluster1, ning hiljem saab selle parameetreid konfigureerida, lisada täiendavaid valikuid, hoste jne.

Tavaliselt on soovitatav tutvuda ametliku dokumentatsiooniga, et saada üksikasjalikku teavet kõigi klastri seadete kohta. Mainin, et klastrit luues piisab olulisemate seadete seadmisest vahekaardil General.

Tõstetaks esile olulisemad parameetrid:

• Protsessori tüüp — valitakse, lähtudes sellest, millised protsessorid on klastrite hostides, milline on nende tootja ja milline on kõige vanem protsessor, et kasutada klassis kõiki saadaolevaid protsessori juhiseid.
• Lüliti tüüp – meie klastris kasutatakse ainult Linux bridge'i, seega valime selle.
• Tulekahju seina tüüp – siin on kõik selge, see on firewalld, mis peab olema lubatud ja seadistatud hostides.

Klastri parameetrite ekraanipilt

Lisahostide installimine Self-Hosted keskkonnas

Ling dokumendile.

Lisahostid Self-Hosted keskkonnas lisatakse nagu tavaline host, täiendava sammuna virtuaalmasina (VM) deployhimise toiminguga — Valige hosted engine deployhimise toiming >> Deploy. Kuna ka lisahostile peab olema esitatud LUN virtuaalmasinale hosted engine'iga, tähendab see, et seda hosti saab vajadusel kasutada virtuaalmasinate asukohtadena hosted engine'iga.
Kliendi turvalisuse tagamiseks on soovitatav, et oleks vähemalt kaks hosti, kus virtuaalmasinat võivad töötada hosted engine'iga.

Lisahostil keelame iptables (kui see on lubatud), aktiveerime firewalld

systemctl stop iptables
systemctl disable iptables

systemctl enable firewalld
systemctl start firewalld

Installime vajalikku KVM versiooni (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-clear

Installime vajalikud repod ja hosted engine'i installija:

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-setup

Seejame konsolile. Open Virtualization Manager, lisame uus host ja teeme kõik samm-sammult, nagu on kirjutatud. dokumentatsioonis.

Kuna oleme lisanud täiendava hosti, peaksime saama administraatori konsoolis vaate, nagu on näidatud ekraanipildil.

Ekraanipilt administraatori portaalist — hostid

Host, kus masinaga hosted-engine on hetkel aktiivne, on tähistatud kuldse krooni ja sildiga "Running the Hosted Engine VM"; host, kus see masin võib vajadusel käivituda — sildiga "Can run the Hosted Engine VM».

Kui host, millel "Running the Hosted Engine VM", kukub kokku, ta taaskäivitub automaatselt teisel hostil. Samuti saab seda masinat migreerida aktiivselt hostilt varu hostile hoolduse jaoks.

Power Management / fencing seadistamine oVirti hostidel

Dokumendi lingid:

• Red Hat Virtualization 4.3 –> Technical Reference -> Chapter 4. Power Management
• oVirt Administration Guide -> Chapter 7: Hosts

Kuigi võib tunduda, et hosti lisamine ja seadistamine on lõpule viidud, ei ole see päris nii.
Hostide normaalseks tööks ja rikete tuvastamiseks/ kõrvaldamiseks on vajalik Power Management / fencing seadistamine.

Fencing, või aediku loomine – see on ajutine protsess, mille käigus välistatakse rikke tõttu toimiv host klastrist, mille käigus käivitatakse kas oVirt teenused sellel hostil või käivitatakse host ise.

Kõik üksikasjad Power Managementi / fencing määratlemise ja parameetrite kohta on nagu tavaliselt dokumentatsioonis, toon vaid näite, kuidas seda olulist parameetrit konfigureerida Dell R640 serverite puhul, millel on iDRAC 9.

1. Logime sisse haldusteenusesse, klikime Arvutus >> Hosts valime hosti.
2. Klikime Edit.
3. Klikime vahelehele Power Management.
4. Märgime ruut valiku eest Enable Power Management.
5. Märgime ruut valiku eest Kdump integration, et host ei läheks aediku (fencing) režiimi, kui registreeritakse tuumakrahhi ärakiri.

Märkus.

Pärast Kdump integrationi sisselülitamist juba töötaval hostil tuleb see vastavalt oVirt Administration Guide’i protseduurile uuesti installida -> Chapter 7: Hosts -> Reinstalling Hosts.

1. Valikuliselt saab märkida ruutu Disable policy control of power management, kui me ei soovi, et hosti toitehaldus oleks klastriplaneerimise poliitika (Scheduling Policy) kaudu reguleeritud.
2. Klikime nuppu (+), et lisada uus toitehaldusseade, avatakse agendi omaduste redigeerimise aken.
   iDRAC9 puhul täidame välja:
   • Address – iDRAC9 aadress
   • Kasutajanimi / Parool – vastavalt sisselogimiseks vajalikud kasutajanimi ja parool iDRAC9-sse
   • Tüüp — drac5
   • märgi Turvaline
   • lisage järgmised valikud: cmd_prompt=>,login_timeout=30

Screenshot 'Power Management' seadetest hosti omadustes

Salvestusala või Storage Domains loomine

Dokumentatsiooni link — oVirt Administration Guide, Peatükk 8: Salvestamine.

Salvestusala, või salvestusala – see on keskne koht virtuaalsete masinate ketaste, installatsioonipiltide, mallide ja sätete salvestamiseks.

Salvestusalad saavad ühendada andmekeskusega erinevate protokollide, klastrite ja võrgu failisüsteemide abil.

oVirt-il on kolm tüüpi salvestusala:

• Andmeala – kõikide virtuaalsete masinatega seotud andmete (kettad, mallid) salvestamiseks. Andmeala ei saa jagada erinevate andmekeskuste vahel.
• ISO ala (eelmine salvestusala tüüp) – operatsioonisüsteemide installatsioonipiltide salvestamiseks. ISO ala võib olla jagatud erinevate andmekeskuste vahel.
• Eksportala (eelmine salvestusala tüüp) – ajutiseks salvestamiseks pilte, mis liiguvad andmekeskuste vahel.

Meie erijuhul kasutatakse andmeala tüüpi Data Domain, et ühendada LUN-ide juurde SAN-i kaudu Fibre Channel protokolli (FCP).

Ovirt'i vaatenurgast, kasutades ladustamisprotsesside (FC või iSCSI) jaoks, on iga virtuaalne kettag, välgutus või mall loogiline ketas.
Plokiseadmed on ühendatud tervikuks (klastrite hostides) Volume Group kaudu ja seejärel jagatud LVM abil loogilisteks mahtu, mida kasutatakse virtuaalsete kettadena VM-ides.

Kuidas neid rühmi ja mitmeid LVM mahtusid võib näha klastrite hostides, kasutades käske vgs ja lvs. Loomulikult tuleb selliste kettastega tehingud teha ainult oVirt'i konsoolist, välja arvatud erandid.

Virtuaalsed kettad VM-ide jaoks võid olla kahte tüüpi — QCOW2 või RAW. Kettad võivad olla "õhukesed" või "paksud". Välgutuspunktid luuakse alati kui "õhukesed".

Salvestusinimeste, või ladustamisalade haldamise meetod, millele pääseb ligi läbi FC, on üsna loogiline — igal virtuaalsel kettal VM-i jaoks on eraldi loogiline maht, mis on kirjutamiseks juurdepääsetav ainult ühele hostile. FC-ühenduste korral kasutab oVirt midagi, mis tuletab meelde klastrite LVM.

Virtuaalmasinad, mis asuvad ühes ladustamisalas, saab migreerida hostide vahel, mis kuuluvad samasse klastrisse.

Kuna näeme kirjelduse põhjal, tähistab klaster oVirt'is, nagu ka VMware vSphere'is või Hyper-V's, sisuliselt sama - see on loogiline rühm hoste, soovitatavalt sarnaste "riistvara" elementidega, ning millel on ühine salvestusruum virtuaalsete masinate ketaste jaoks.

Liigume otse andmete salvestusala (VM ketaste) loomise juurde, kuna ilma selleta ei saa andmekeskus alustada.
Tuletan meelde, et kõik klastrile esitatud LUN'id jaotustasandil peavad olema nähtavad käskluse abil "multipath -ll».

Vastavalt dokumentatsioonis", liigume portaalis Salvestus >> Domeenid -> Uus domeen ja järgime jaotises "FCP salvestuse lisamine" antud juhiseid.

Pärast abimehe käivitamist täidame vajalikud väljad:

• Nimi — määrame klastri nime
• Domeeni funktsioon — Andmed
• Salvestustüüp — Fiber Channel
• Host, mida kasutada — valime hosti, kus vajalik LUN on saadaval

LUN'ide loendis märkime meie soovitud, klikkime Lisa ja seejärel OK. Vajadusel saame täiendavaid salvestusala parameetreid kohandada, klikkides Täiendavad parameetrid.

Kuvatõmmis "Salvestusala" lisamise abimehest

Abimehe töö tulemuste põhjal peaks meil olema uus salvestusala ja meie andmekeskus peaks minema staatusele UP, või initsialiseeritud:

Keskuse ja salvestusala kuvatõmmised:

Võrgustike loomine ja seadistamine virtuaalmasinate jaoks

Dokumentatsiooni link — oVirt Administration Guide, Peatükk 6: Loogilised Võrgud

Võrgud on mõeldud loogiliste võrkude rühmitamiseks, mida kasutatakse virtuaalses infrastruktuuris oVirt.

Virtuaalmisina võrgukaardi ja füüsilise adaptori vahelise suhtluse tagamiseks hostis kasutatakse Linuxi sillaga loogilisi liideseid.

Võrkude vahelise liikluse rühmitamiseks ja jagamiseks on lülititel seadistatud VLAN-id.

Kui luuakse loogiline võrk virtuaalmashinatele oVirtis, peab seda kindlasti seostama identifikaatoriga, mis vastab VLAN-numbrile lülitis, et VM-id saaksid omavahel suhelda, isegi kui nad töötavad erinevates klastrisõlmedes.

Virtuaalmashinate ühendamiseks vajalikud võrgukaartide eelhäälestused hostides pidid olema tehtud eelnevas artiklis – loogiline liides on seadistatud bond1, seejärel tuleb kõik võrguseaded teha ainult oVirti halduskeskkonnas.

Pärast VM-i loomist hosted-engine'iga loodi automaatselt mitte ainult keskuse ja klastriga seotud seadistused, vaid ka loogiline võrk, et hallata meie klastrit – ovritmgmt, millega see VM ühendatud oli.

Vajadusel saab vaadata loogilise võrgu seadeid ovritmgmt , ja neid kohandada, kuid peab olema ettevaatlik, et mitte kaotada oVirt’i infrastruktuuri haldamise kontrolli.

Loogilise võrgu seaded ovritmgmt

Uue loogilise võrgu loomiseks tavalistele VM-idele, liikume administratiivportaalis Võrk log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy stats timeout 30s user haproxy group haproxy daemondefaults log global mode http option httplog option dontlognull timeout connect 5000 timeout client 50000 timeout server 50000frontend http_front bind *:80 stats uri /haproxy?stats default_backend http_backbackend http_back balance roundrobin server server_name1 private_ip1:80 check server server_name2 private_ip2:80 check >> Võrgud >> Uus, ja vahekaardil General lisame võrgu soovitud VLAN-i ID-ga ning märgime kastikese «VM Network», see tähendab, et seda saab kasutada VM-idele määramiseks.

VLAN32 uue loogilise võrgu ekraanipilt

Vahekaardil Klastri, kinnitame selle võrgu meie klastriga Cluster1.

Seejärel liigume Arvutus >> Hosts, siseneme igasse hosti järjestikku vahekaardile Võrguliidesed, ja käivitame viisardi Seadista hosti võrgud, et siduda uue loogilise võrgu hostidega.

Ekraanipilt viisardist «Setup host networks»

oVirt agent teeb automaatselt kõik vajalikud võrguseaded hostis – loob VLAN-i ja BRIDGE-i.

Uute võrkude konfigureerimise failide näidis hostis:

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=no

Te soovitan veel kord meeles pidada, et klastrihostis EI OLE VAJA enetente loodud käsitsi võrgu liidesed ifcfg-bond1.432 ja ifcfg-ovirtvm-vlan432.

Pärast loogilise võrgu lisamist ja ühenduse kontrollimist hosti ja VM-i vahel, kus on hosted engine, saab seda kasutada virtuaalses masinas.

Installeerimise pildi loomine virtuaalmasina juurutamiseks

Dokumentatsiooni link — oVirt Administration Guide, Peatükk 8: Salvestamine, osas Pilte andmesalvestuse domeeni üleslaadimisest.

Ilma installimisfaile OS ei saa virtuaalset masinat paigaldada, kuigi see ei ole probleem, kui võrgus on näiteks Cobbler ettevalmistatud pildid.

Meie puhul ei ole seda võimalust, seega on vajalik see pilt ise oVirt'i importida. Varasemalt oli vajalik ISO Domeeni loomine, kuid oVirt'i uues versioonis tunnistati see vananenuks, seega saab nüüd pilte üles laadida otse Storage domeeni kaudu haldusteenuse portaalist.

Haldusteenuse portaalis liikuda Salvestus >> Diskid >> Üleslaadimine >> Alusta
Lisame meie OS-i pildi ISO failina, täidame kõik väljad vormis ja vajutame nuppu "Testi ühendust".

Kuvatõmmis installatsiooni pildi lisamise assistendist

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

Siis tuleb lisada oVirt sertifikaat «Usaldusväärsed juured CA-d» (Trusted Root CA) administraatori juhtimisseadmesse, kust proovime pilti üles laadida.

Pärast sertifikaadi lisamist Trusted Root CA-sse, vajutame uuesti "Testi ühendust", peaksime saama:

Ühendus ovirt-imageio-proxyga õnnestus.

Pärast sertifikaadi lisamise toimingut saab proovida ISO pilti jälle Storage Domaini laadida.

Põhimõtteliselt on võimalik luua eraldi Storage Domain tüübi Data jaoks, et hoida pilte ja malle eraldi VM-i diskidest, või isegi hoida neid Storage Domainis hosted engine jaoks, kuid see jääb juba administraatori otsustada.

Kuvatõmmis ISO piltidest Storage Domainis hosted engine jaoks

Virtuaalmasina loomine

Dokumentatsiooni link:
oVirt Virtuaalmasinate Halduse Käsiraamat –> Kapitel 2: Linuxi Virtuaalmasinate Installimine
Konsoli Klientide Ressursid

Pärast installatsioonipildi üleslaadimist oVirtis OS-i jaoks võib alustada virtuaalmasina loomist. Töö on palju tehtud, kuid oleme juba lõpusirgel, milleks kõik see on ette võetud – käivituskatkestusteta infrastruktuuri saamine kõrge kättesaadavusega virtuaalmasinate jaoks. Ja kogu see protsess on täiesti tasuta – ei ole kulutatud ühtegi senti tarkvara litsentside ostmiseks.

Virtuaalmasina loomiseks CentOS 7-ga peab olema üles laaditud OS-i installatsioonipilt.

Siseneme haldusportaalile, liikumme Arvutus >> Virtuaalmasinad, ja käivitame VM-i loomise viisardi. Täidame kõik parameetrid ja väljad ning klõpsame OK. Kõik on väga lihtne, kui järgida dokumentatsiooni.

Näiteks toome välja peamised ja täiendavad seaded kõrge kättesaadavusega VM-ile, koos loodud ketase, ühendudes võrguga ja käivitades installatsioonipildi:

Ekraanipildid kõrge kättesaadavusega VM-i seadistustest

Kui viisardiga töö on lõpetatud, sulgeme selle, käivitame uue VM-i ja installime sellele OS-i.
Selleks siseneme selle VM-i konsoli kaudu haldusportaalist:

Kuvakaappaus hallintaportaaliin asetuksista virtuaalikoneen konsoliin yhdistämiseksi

Jotta voit yhdistää virtuaalikoneen konsoliin, konsolin asetukset on ensin määritettävä virtuaalikoneen ominaisuuksissa.

Kuvakaappaus virtuaalikoneen asetuksista, ''Console''-välilehti

Virtuaalikoneen konsoliin yhdistämiseen voidaan käyttää esimerkiksi Virtuaalikoneen katseluohjelma.

Voit yhdistää virtuaalikoneen konsoliin suoraan selainikkunassa, jos yhdistämisasetukset ovat seuraavat:

Kun käyttöjärjestelmä on asennettu virtuaalikoneeseen, on suositeltavaa asentaa oVirt-asiakasagentti:

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.service

Tällä tavoin toimintamme tuloksena luotu virtuaalikone on korkean käytettävyyden omaava, eli jos klusterin solmussa, jossa se on käynnissä, tapahtuu vika, oVirt käynnistää sen automaattisesti toisessa solmussa. Myös tätä virtuaalikonetta voidaan siirtää klusterin isäntien välillä huoltoa tai muita tarkoituksia varten.

Kokkuvõte

Loodan, et see artikkel suudab edastada, et oVirt on täiesti normaalne tööriist virtuaalse infrastruktuuri haldamiseks, mida on suhteliselt lihtne seadistada — kõige tähtsam on järgida teatud reegleid ja nõudeid, mis on kirjeldatud nii artiklis kui ka dokumentatsioonis.

Kuna artikkel on mahukas, ei ole õnnestunud sinna mahutada paljusid asju, näiteks erinevate wizardite samm-sammult teostamine koos kõigi üksikasjalike seletuste ja ekraanipiltidega, pikkade käskude väljunditega jne. Tegelikult oleks selle jaoks vaja kirjutada terve raamat, mis pole eriti mõttekas, kuna pidevalt ilmuvad uusi tarkvara versioone koos uuendustega ja muudatustega. Peamine on mõista põhimõtet, kuidas kõik koos töötab, ja omada üldist tegevusalgoritmi, et luua usaldusväärne platvorm virtuaalsete masinate haldamiseks.

Kuigi oleme virtuaalse infrastruktuuri loonud, peame nüüd õppima, kuidas see suudab suhelda nii oma eraldi elementide vahel: hostide, virtuaalsete masinate, sisemiste võrkude, kui ka välismaailmaga.

See protsess on üks peamisi süsteemi- või võrguadministraatori ülesandeid, mis käsitletakse järgmises artiklis — virtuaalsete marsruuterite VyOS kasutamine meie ettevõtte talitluse järjepidevuses (nagu võisite aru saada, töötavad nad meie oVirt klastris virtuaalmasinadena).

Allikas: habr.com