Loobumise ja talitluse kestlik IT-infrastruktuur. Osa 2. oVirt 4.3 klastrite seadistamine ja seadistamine

See artikkel on jätk eelnevale – «Tõrgeteta IT-infrastruktuuri loomine. Osa 1 — ettevalmistus oVirt 4.3 klastri kasutuselevõtuks».

Selles käsitletakse oVirt 4.3 klastrite põhiseadistamise ja seadistamise protsessi, et majutada kõrge kättesaadavusega virtuaalmasinaid, eeldades, et kõik eelnevad infrastruktuuri ettevalmistamise sammud on juba varem tehtud.

Sissejuhatus

Artikli peamine eesmärk ei ole anda samm-sammult juhendit stiilis «Next -> Jah -> Lõpeta», vaid näidata mõningaid eripära selle seadistamisel ja seadistamisel. Teie klastrite seadistamise protsess ei pruugi alati kattuda selle artiklis kirja pandud protsessiga, sõltuvalt infrastruktuuri ja keskkonna eripärast, kuid üldised põhimõtted jäävad samaks.

Subjektiivsest vaatenurgast oVirt 4.3 on oma funktsionaalsuses sarnane VMware vSphere 5.x versiooniga, kuid loomulikult on tal oma seadistamise ja toimimise eripärad.

Huvi korral saate kõik erinevused RHEV (aka oVirt) ja VMware vSphere'i vahel leida Internetist, näiteks siin, kuid siiski tahan mõningaid erinevusi või sarnasusi vahel kindlasti välja tuua artikli vältel.

Sooviksin eraldi natuke võrrelda virtuaalmasinate võrgutööd. oVirtis on rakendatud sarnane põhimõte virtuaalmasinate (edaspidi VMs) võrkude haldamiseks nagu VMware vSphere:

• standardse Linuxi sildiga (VMware — Standard vSwitch), mis töötab virtualiseerimisklientide põhjal;
• Open vSwitchi (OVS) abil (VMware — Distributed vSwitch) – see on hajutatud virtuaalne lüliti, mis koosneb kahest põhikomponendist: keskserver OVN ja OVN-i kontrollpunktid hallatavates hostides.

Oluline on märkida, et rakendatuse lihtsuse tõttu käsitletakse artiklis virtuaalmasinate võrkude seadistamist oVirtis standardse Linuxi silla abil, mis on KVM hüperviisori kasutamisel tavaline valik.

Seoses sellega on mõned põhireeglid võrgu haldamiseks klastris, millest ei tasu kinni pidada:

• Kõik võrgu seadistused hostides peavad enne nende lisamist oVirti olema identilised, välja arvatud IP-aadressid.
• Pärast seda, kui host on allutatud oVirtile, ei soovita võrgu seadistustes käsitsi muudatusi teha ilma täieliku kindluse saamata, kuna oVirti agent lihtsalt taastab need eelnevatele, pärast hosti või agendi taaskäivitamist.
• Uue võrgu lisamine VM-ile ja selle haldamine tuleb teostada ainult oVirt halduskeskkonnast.

Veel üks tähtis märkus – väga kriitilise keskkonna (mis on rahaliste kaotuste suhtes väga tundlik) jaoks oleks siiski soovitav kasutada tasulist tuge ja rakendada Red Hat Virtualization 4.3.oVirt klastrit kasutades võivad ilmneda olukorrad, kus on soovitatav võimalikult kiiresti saada kvalifitseeritud abi, mitte proovida ise hakkama saada.

Ja lõpuks, soovitatakse tutvuda oVirt klastrite juurutamisel ametlikuga dokumentatsiooniga, et olla kursis vähemalt põhimõisted ja määratlemised, vastasel juhul on artikli lugemine natuke keeruline.

Ovit klastrite tööpõhimõtete ja artikli arusaamise aluseks on need juhised:

• oVirt Installation Guide
• oVirt Self-Hosted Engine Guide
• oVirt Administration Guide
  

Maht seal pole väga suur, tunni-kahe jooksul võib täiesti omandada põhialused, ning neile, kes armastavad üksikasju, soovitatakse lugeda Product Documentation for Red Hat Virtualization 4.3 – RHEV ja oVirt on tegelikult ühesugused.

Nii et kui kõik põhiseaded hostides, lülitites ja SAN-is on tehtud, liigume edasi oVirt-i juurutamise juurde.

Osa 2. Ovirt 4.3 klastrite installimine ja seadistamine

Selleks et oleks lihtne orienteeruda, loetlen artiklis põhiosemed, mis tuleb järjestikku täita:

1. oVirt haldussüsteemi installimine
2. Uue andmekeskuse loomine
3. Uue klastrite loomine
4. Lisahostide installimine Self-Hosted keskkonnas
5. Salvestusala või Storage Domains loomine
6. Virtuaalmasinate jaoks võrgu loomine ja seadistamine
7. Virtuaalmasina juurutamiseks installitava pildi loomine
8. Virtuaalmasina loomine

oVirt haldussüsteemi installimine

oVirt haldussüsteem – on peamine element oVirt infrastruktuuris, mis võib olla virtuaalne masin, host või virtuaalne seade, mis haldab kogu oVirt infrastruktuuri.

Selle lähimad analoogid virtualiseerimise maailmas on:

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

oVirt haldussüsteemi installimiseks on meil kaks varianti:

Variant 1
Serveri juurutamine spetsialiseeritud VM-ina või hostina.

See variant works well, but on the condition that such a VM operates independently of the cluster, i.e. it is not running on any host of the cluster as a regular virtual machine managed by KVM.

Why can't such a VM be deployed on the cluster hosts?

At the very start of the oVirt management server deployment process, we have a dilemma — we need to install the management VM, but the cluster itself doesn't actually exist yet, so what can we come up with on the fly? Right — install KVM on the future cluster node, then create a virtual machine on it, for example, with CentOS OS, and deploy the oVirt engine on it. This is usually done for complete control over such a VM, but this intention is erroneous because, in this case, there will 100% be problems with such a management VM in the future:

• it cannot be migrated in the oVirt console between the cluster hosts (nodes);
• when migrating via KVM using virsh migrate, this VM will be unavailable for management from the oVirt console.
• cluster hosts cannot be taken into Maintenance mode if you migrate this VM from host to host using virsh migrate.

So, do everything by the rules — use either a separate host or an independent VM running on it for the oVirt management server, or better follow the guidelines from the second option.

Option 2
Installing the oVirt Engine Appliance on the host it manages.

This option will be discussed further as it is more correct and suitable in our case.
The requirements for such a VM are described below; I would just add that it is recommended to have at least two hosts in the infrastructure on which the management VM can be run to make it fault-tolerant. Here I would like to add that as I have already mentioned in the comments in the previous article, I still couldn't achieve splitbrain on the oVirt cluster from two hosts, with the possibility of running the hosted-engine VM on them.

Installing the oVirt Engine Appliance on the first cluster host

Link to the official documentation — oVirt Self-Hosted Engine Guide, section “Deploying the Self-Hosted Engine Using the Command line»

The document specifies the prerequisites that must be fulfilled before deploying the hosted-engine VM, as well as detailing the installation process itself, so it makes little sense to repeat it verbatim, thus we will focus on some important details.

• Enne kõiki toiminguid, lubage kindlasti BIOS-i seadetes virtualiseerimise tugi hostis.
• Installime hostile paketi hosted-engine installer jaoks:

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 juurutamise protsess screen'is (sisseheitmiseks saate kasutada Ctrl-A + D, sulgemiseks Ctrl-D):

screen
hosted-engine --deploy

Soovi korral saab installatsiooni käivitada eelnevalt ettevalmistatud vastuste failiga:

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

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

- klastrinimi
- vCPU ja vRAM arv (soovitatav on 4 vCPU ja 16 GB)
- paroolid
- salvestustüüp hosted engine VM jaoks – meie juhul FC
- LUN number hosted engine'i installimiseks
- kus asub hosted engine'i andmebaas – soovitan lihtsuse huvides valida Local (see on PostgreSQL andmebaas, mis töötab selle VM sees)
ja jne. 

• Kõrge kättesaadavusega VM-i jaoks hosted engine'iga olime me ette valmistanud spetsiaalse LUNi numbriga 4 ja suurusega 150 GB, misjärel see esitati klastrihostidele – vaata eelnevas artiklis.

Varem kontrollisime ka, et 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 sisalda midagi keerulist, 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 siseneme veebibrauseriga aadressile https://ovirt_hostname/ovirt-engine administraatori arvutist ja klõpsame [Administration Portal].

Kuvake "Administration Portal"

Sisestades oma kasutajanime ja parooli (installimise käigus määratud) aknasse nagu ekraanipildil, siseneme Open Virtualization Manageri juhtpaneelile, kus saame teostada kõiki toiminguid virtuaalse infrastruktuuriga:

1. lisada andmekeskuse
2. lisada ja seadistada klastrit
3. lisada hoste ja neid hallata
4. lisada salvestusruume või Storage Domains virtuaalmasinate ketaste jaoks
5. lisada ja konfigureerida võrgud virtuaalmasinate jaoks
6. lisada virtuaalmasinad, installatsioonipildid, VM-mallid ja hallata neid

Kõiki neid toiminguid käsitletakse hiljem, mõnedest suurte detailide sees, mõnedest aga põhjalikult ja nüansirikkalt.
Aga esmalt soovitaksin lugeda seda lisa, mis kindlasti paljudele kasuks tuleb.

Täiendav

1) Põhimõtteliselt, kui on vajadus, siis ei takista miski eelnevalt KVM hüperviisori installimist klastrite sõlmedele, kasutades pakette libvirt ja qemu-kvm (või qemu-kvm-ev) soovitud versioon, kuigi oVirt klastrite sõlme üles seadmise ajal võib ta seda ise teha.

Aga kui libvirt ja qemu-kvm oli installitud mitte kõige uuem versioon, siis võib selline viga ilmuda hosted engine'i üles seadmisel:

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

St. on vajalik omada uuendatud versiooni libvirt kaitsega MDS, mis toetab sellist poliitikat:

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

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

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 saab jätkata hosted engine'i installimist.

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

Kui hosted-engine'i virtuaalmasinate üles seadmise ajal saame sellise vea:

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

Siis tuleb keelata teine tulemüür (kui see on kasutusel) ja installida ning käivitada firewalld:

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, ovirt agendi installimisel uuel hostil klastris, seadistab ta vajalikud portid firewalld automaatsetä.

3) Hosti taaskäivitamine, kus töötab virtuaalmasin koos hosted engine'iga.

Nagu alati, link 1 ja link 2 juhendite dokumentide kohta.

Kogu hosted engine VM haldamine toimub AINULT käsu kaudu hosted-engine hostis, kus see töötab, unustage virsh ka, nagu ka see, et sellele VM-ile saab sisse logida SSH kaudu ja seal käivitada käsku „shutdown».

Üleminek protseduur VMi hooldusrežiimi:

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

hosted-engine --vm-status
!! Kluster on GLOBAL MAINTENANCE režiimis !!
--== Host host1.test.local (id: 1) olek ==--
conf_on_shared_storage: True
Olek ajakohane: True
Hostname: host1.test.local
Host ID: 1
Mootori olek: {"health": "good", "vm": "up", "detail": "Up"}
Skoor: 3400
stopped: False
Kohalik hooldus: False
crc32: dee1a774
local_conf_timestamp: 1821
Host timestamp: 1821
Lisa metaandmed (kehtivad ajatempli juures):
        metadata_parse_version=1
        metadata_feature_version=1
        timestamp=1821 (Laup Nov 29 14:25:19 2019)
        host-id=1
        skoor=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 koos hosted engine agentiga ja teeme selleks, mida vajame.

Peale taaskäitamist kontrollime VMi olekut koos hosted engine'iga:

hosted-engine --vm-status

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

Teenuse logis on viga:

journalctl -u ovirt-ha-agent
...
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine ERROR Ebaõnnestus vajalikku monitori käivitada
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent ERROR Jälgimise alguse jälgimise viga (#012  Fail "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/agent.py", rida 131, _run_agent()#012return action(he)#012  Fail "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/agent.py", rida 55, action_proper()#012return he.start_monitoring()#012  Fail "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/hosted_engine.py", rida 413, start_monitoring()#012self._initialize_broker()#012  Fail "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/hosted_engine.py", rida 537, _initialize_broker()#012m.get('options', {}))#012  Fail "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/lib\/brokerlink.py", rida 86, start_monitor()#012).format(t=type, o=options, e=e)#012RequestError: brokerlink - ebaõnnestus monitori käivitamine ovirt-ha-broker'i 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 Proovitakse agenti taaskäivitada

Seega ühendame andmesalvestuse 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 hosted-engine'iga VMi käivitamist, viime selle hooldusrežiimist välja:

Protseduur VMi hooldusrežiimist väljastamiseks:

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 sellega seotud kogu eemaldamine.

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

Lihtsalt käivita käsk hostis:

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

Seejärel eemaldame mittevajalikud paketid, tehes enne varukoopia mõningatest konfiguratsioonidest, kui see on vajalik:

yum autoremove ovirt* qemu* virt* libvirt* libguestfs 

Uue andmekeskuse loomine

Viidatud dokumentatsioon — oVirt Administration Guide. Chapter 4: Andmekeskused

Esmalt määratleme, mis on andmekeskus (tsiteerin abist) — see on loogiline entiteet, mis määratleb ressursside komplekti, mida kasutatakse konkreetsetes keskkondades.

Andmekeskus on omamoodi konteiner, mis koosneb:

• loogilistest ressursidest klastrite ja hostide kujul
• kliustrite võrguressurssidest loogiliste võrkude ja hostide füüsiliste adapterite kujul,
• salvestusressurssidest (VM diskide, mallide, piltide jaoks) salvestusalade (Storage Domains) kujul.

Andmekeskus võib sisaldada mitmeid klastreid, mis koosnevad mitmest hostist, millel töötavad virtuaalsed masinad, samuti võib sellel olla mitu salvestusala, mis on sellega seotud.
Andmekeskuseid võib olla mitu, need töötavad üksteisest sõltumatult. oVirtis on juurdepääsuõiguste jaotamine rollide kaupa ning lubasid saab seadistada isiklikult nii andmekeskuse tasemel kui ka selle eraldi loogiliste elementide tasemel.

Andmekeskus või andmekeskused, kui neid on mitu, haldatakse ühe halduskonsoli või portaali kaudu.

Andmekeskuse loomiseks siseneme haldustportaalisse ja loome uue andmekeskuse:
Arvutus >> Andmekeskused >> Uus

Kuna meil on kasutusel ühine salvestus SCSI-l, peab salvestuse tüüp (Storage Type) olema Jagatud:

Kuvavõtte andmekeskuse loomise viisardist

Virtuaalmasina installimisel, millel on hosted-engine, luuakse vaikimisi andmekeskus – Andmekeskus1, ja vajadusel saab selle salvestustüüpi (Storage Type) muuta.

Andmekeskuse loomine ei ole keeruline ülesanne, ilma salajaste nüanssideta, ja kõik täiendavad toimingud selle kohta on dokumentatsioonis kirjas. Üks asi, mida pean märkima, on see, et üksikud hostid, millel on ainult kohalik salvestus (ketas) VM-ide jaoks, ei saa minna andmekeskusesse, mille salvestustüüp on – Shared (neid ei saa sinna lisada), ning neile tuleb luua eraldi andmekeskus – see tähendab, et igal eraldiseisval hostil, millel on kohalik salvestus, peab olema oma eraldiseisev andmekeskus.

Uue klastrite loomine

Dokumentatsiooni link – oVirt Administration Guide. peatükk 5: Klaster

Ilma liigsete detailideta, klaster – see on loogiline hostide rühmitamine, millel on ühine salvestusala (nagu näiteks ühisfailid SAN-is, nagu meie juhul). Samuti on soovitatav, et klastris olevad hostid oleksid tehniliselt ühesugused ja oleks sama tüüpi protsessorid (Intel või AMD). Parim oleks, kui klastris olevad serverid oleks täielikult identsed.

Klaster kuulub andmekeskusesse (kindla salvestustüübiga – Local või Jagatud), ja kõik hostid peavad tingimata kuuluma mõnda klastrisse, sõltumata sellest, kas neil on ühine salvestus või mitte.

Virtuaalmasina installimisel hosted-engine-ga hostile luuakse vaikimisi andmekeskus – Andmekeskus1, koos klastri – Klaster1, ja edaspidi saab selle parameetreid seadistada, lisada täiendavaid valikuid, lisada hoste jne.

Nagu tavaliselt, on kõikides klastri seadetes üksikasjade saamiseks soovitatav tutvuda ametliku dokumentatsiooniga. Klasteri seadistamise eripäradest lisaks mainin, et selle loomisel tuleb seadistada vaid põhijooned vahekaardil Üldine.

Toon välja kõige olulisemad parameetrid:

• Protsessori tüüp – valitakse lähtuvalt sellest, millised protsessorid on klastris olevatel hostidel, kellelt need on tootnud ja milline protsessor on hostidel kõige vanem, et vastavalt sellele kasutada klastris kõiki saadaolevaid protsessorijuhiseid.
• Lüliti tüüp – meie klastris kasutatakse ainult Linux bridge'i, seetõttu valime selle.
• Tulemüüritüüp – siin on kõik selge, see on firewalld, mis peab olema lubatud ja seadistatud hostidel.

Klastri parameetrite ekraanipilt

Täiendavate hostide seadistamine iseteeninduses

Link dokumentatsioonile.

Iseteeninduse keskkonnas lisatakse täiendavad hostid nagu tavaliselt, täiendada tuleb ainulaadset sammu virtuaalmasina seadistamiseks hosted engine'iga — Valige hosted engine'i juurutamise tegevus >> Juurutada. Kuna ka täiendavale hostile peab olema esitatud LUN hosted engine'i virtuaalmasinale, tähendab see, et seda hosti saab vajadusel kasutada hosted engine'i virtuaalmasinate paigutamiseks.
Tõrkekindluse tagamiseks on soovitatav, et oleks vähemalt kaks hosti, kus võiks hostida hosted engine'i virtuaalmasinat.

Täiendaval hostil keela iptables (kui see on sisse lülitatud), lülita firewalld sisse

systemctl stop iptables
systemctl disable iptables

systemctl enable firewalld
systemctl start firewalld

Paigaldame nõutava 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

Paigaldame vajalikud hoidlad ja hosted engine'i seadistaja:

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

Seejärel liikume terminali Open Virtualization Manager, lisame uue hosti ja järgime samm-sammult juhiseid, nagu on kirjutatud dokumentatsioon.

Seetõttu, pärast täiendava hosti lisamist peaksime saama administraatori konsoolis sarnase pildi nagu ekraanipildil.

Ekraanipilt administratiivportaalist — hostid

Host, kus hosted-engine'i virtuaalmasin on hetkel aktiivne, omab kuldset krooni ja sildi "Running the Hosted Engine VM", host, kus seda virtuaalmasinat saab vajadusel käivitada – silt "Can run the Hosted Engine VM».

Kui host, kus "Running the Hosted Engine VM", ebaõnnestub, taaskäivitub see automaatselt teisel hostil. Samuti on võimalik seda virtuaalmasinat migreerida aktiivselt hostilt varu hostile hoolduseks.

Power Management / fencing seadistamine oVirt hostidel

Lingid dokumentatsioonile:

• Red Hat Virtualization 4.3 –> Tehniline viide -> Peatükk 4. Power Management
• oVirt haldusjuhend -> Peatükk 7: Hostid

Kuigi võib tunduda, et hosti lisamine ja seadistamine on lõpetatud, pole see päris nii.
Hostide nõuetekohase töö ja probleemide tuvastamise ning kõrvaldamise tagamiseks on vajalik Power Management / fencing seadistamine.

Fencing, või piiramine – see on protsess, mille käigus välistatakse riknenud või vigane host klastrist ajutiselt. Selle käigus kas taaskäivitatakse oVirt teenused sellel hostil või ise host.

Kõik Power Management / fencing määratlemise ja parameetrite detailid on nagu tavaliselt dokumentatsioonis. Toome siiski näite, kuidas seda olulist parameetrit seadistada Dell R640 serverite jaoks iDRAC 9 puhul.

1. Siseneme administraatori portaali, vajutame Arvutus >> Hosts valime hosti.
2. Vajutame Edit.
3. Vajutame vahelehte Power Management.
4. Märgi ruut valiku kõrval Enable Power Management.
5. Märgi ruut valiku kõrval Kdump integration, et host ei läheks piiramisrežiimi (fencing) kõvaketta varukoopia genereerimise ajal.

Märkus.

Pärast Kdump integration’i lubamist juba töötaval hostil, tuleb see vastavalt oVirt Administration Guide’i protseduurile uuesti installida -> Peatükk 7: Hostid -> Reinstalling Hosts.

1. Valikuliselt saab märkida ruudu Disable policy control of power management, kui me ei soovi, et hosti toitehaldus oleks seotud klastrite ajakava (Scheduling Policy) poliitikaga.
2. Vajutame nuppu (+), et lisada uus toitehaldusseade, avaneb agendi omaduste redigeerimise aken.
   iDRAC9 jaoks täidame väljad:
   • Address – iDRAC9 aadress
   • User Name / Password – vastavad sisselogimisandmed iDRAC9-sse
   • Tüüp — drac5
   • esile tõsta Secure
   • lisada järgmised valikud: cmd_prompt=>, login_timeout=30

Kuvapilt hosti Power Management parameetritega

Salvestusala või Storage Domains loomine

Link dokumentatsioonile — oVirt Administration Guide, Chapter 8: Storage.

Storage Domain, või salvestusala – see on tsentraliseeritud koht virtuaalmasinate, installatsiooniargumendi, malli ja snapshots’de ketaste salvestamiseks.

Salvestuspiirkonnad saavad olla ühendatud andmekeskusega, kasutades erinevaid protokolle, klastrite ja võrgufailisüsteemide kaudu.

oVirt-il on kolm tüüpi salvestusala:

• Data Domain – kõigi virtuaalmasinate (ketaste, mallide) seotud andmete salvestamiseks. Data Domain’i ei saa jagada erinevate andmekeskuste vahel.
• ISO Domain (mooduli tüüp) – operatsioonisüsteemi installatsioonifailide salvestamiseks. ISO Domain’i saab jagada erinevate andmekeskuste vahel.
• Export Domain (mooduli tüüp) – ajutiseks salvestamiseks pilte, mis liiguvad andmekeskuste vahel.

Meie erijuhtumit silmas pidades kasutab Data Domain tüüpi salvestusala Fibre Channel Protocol (FCP) LUN’ide ühendamiseks SAN-iga.

Ovirt'i seisukohalt, kui kasutatakse SCSI (FC või iSCSI), on iga virtuaalne ketas, snapshot või mall loogiline ketas.
Blokeeringud ühendatakse üheks tervikuks (klastrite hostides) Volume Group'i kaudu ja seejärel jagatakse LVM-i abil loogilisteks mahtudeks, mida kasutatakse VM-ide virtuaalsete diskidena.

Kodasid ja mitmeid LVM-i mahtusid saab näha klastrite hostis käskluste abil. vgs ja lvs. Loomulikult tuleb selliste diskidega tegeleda ainult oVirt'i konsoolist, välja arvatud erijuhtudel.

VM-ide virtuaalsed kettad võivad olla kaht tüüpi — QCOW2 või RAW. Kettad võivad olla "õhukesed" või "paksud". Snapshot'id luuakse alati kui "õhukesed".

Storage domain'ite, millele pääseb ligi FC kaudu, haldamise viis on üsna loogiline — igal virtuaalsel kettal on eraldi loogiline maht, mis on kirjutamiseks kättesaadav ainult ühele hostile. FC ühenduste korral kasutab oVirt midagi sarnast klastrilise LVM-iga.

Virtuaalmasinad, mis asuvad samas salvestusala, saavad migreerida hostide vahel, mis kuuluvad samasse klastrisse.

Nagu näeme kirjeldusest, tähistab klaster oVirt'is, nagu ka VMware vSphere'is või Hyper-V's, sisuliselt sama — see on loogiline hostide grupeerimine, mida on soovitatav, et „riistvara” koostisosad oleksid ühesugused, ning millel on ühine salvestus virtuaalmasinate kettad.

Lähme otse salvestusala loomisele andmete (VM-i kettad) jaoks, kuna ilma selleta ei saa andmekeskust algatada.
Meenutan, et kõik klastrile esitatud LUN'id SCSI-s, peavad olema nähtavad käskluse "multipath -ll».

Vastavalt dokumentatsioon, läheme portaalis ja logime sisse Salvestus >> Domains -> New Domain ja järgime jaotises "Adding FCP Storage" olevaid juhiseid.

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

• Nimi — määrame klastri nime
• Domain Function — Data
• Storage Type — Fibre Channel
• Host to Use — valime hosti, kus on kättesaadav vajaliku LUN

LUN'ide loendis valime vajaliku, klikkides Lisa ja seejärel OK. Vajadusel saab salvestusala täiendavaid parameetreid kohandada, klikkides Advanced Parameters.

Salvestusala lisamise viisardi ekraanipilt

Viisardi tulemusena peaksime saama uue salvestusala ja meie andmekeskus peaks minema staatusele UP, või initsialiseeritud:

Kaamera ja salvestusala ekraanipildid:

Virtuaalmasinate jaoks võrgu loomine ja seadistamine

Link dokumentatsioonile — oVirt Administration Guide, Peatükk 6: Loogilised võrgud

Võrgud, või jooksul on grupid loogilised võrgud, mida kasutatakse virtuaalses infrastruktuuris oVirt.

Virtuaalmasina võrguadapteri ja füüsilise adapteri vahel hostis kasutatakse loogilisi liideseid, nagu Linuxi sild.

Võrkudevahelise liikluse grupeerimiseks ja eraldamiseks on lülitites seadistatud VLAN-id.

Loogilise võrgu loomisel virtuaalmasinatele oVirtis tuleb sellele kindlasti määrata identifikaator, mis vastab VLAN-numbrile lülitis, et VM-id saaksid omavahel suhelda, isegi kui nad töötavad erinevates klastrite sõlmedes.

Hostide võrguadapterite eelseaded virtuaalmasinate ühendamiseks peaksid olema tehtud eelnevas artiklis - loogiline liides on seadistatud bond1, edaspidi tuleb kõik võrgu seaded teha ainult läbi oVirti haldusteenuse.

Pärast virtuaalmasina loomist hosted-engine'iga, automatiseeritakse lisaks andmekeskuse ja klastrite loomisele ka loogiline võrk meie klastrite haldamiseks - ovritmgmt, millele see VM ühendas.

Vajadusel saab vaadata loogilise võrgu seadeid ovritmgmt ja neid korrektiivida, kuid tuleb olla ettevaatlik, et mitte kaotada haldust oVirt infrastruktuuris.

Loogilise võrgu seaded ovritmgmt

Uue loogilise võrgu loomisel tavalistele VM-idele, läheme haldusteenuses Võrk >> Võrgud >> Uus, ja vahekaardil Üldine lisame võrgu vajaliku VLAN identifikaatoriga ning paneme märgi ''VM Network'' , see tähendab, et seda saab kasutada VM-idele määramiseks.

Ekraanipilt uue loogilise võrgu VLAN32-st

Sakil Cluster, kinnitame selle võrgu meie klastriga Klaster1.

Pärast seda lähme Arvutus >> Hosts, järjestikku siseneme igasse hosti, vahekaardile Võrgu liidesed, ja käivitame nõustaja Hosti võrkude seadistamine, et uut loogilist võrku hostidele siduda.

Ekraanipilt 'Hosti võrkude seadistamine' nõustajast

oVirti agent teostab automaatselt kõik vajalikud võrguseaded hostis - loob VLAN-i ja SILL.

Näide konfiguratsioonifailidest uute võrkude jaoks hostis:

cat ifcfg-bond1
# Genereritud VDSM versioon 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
# Genereritud VDSM versioon 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
# Genereritud VDSM versioon 4.30.17.1
DEVICE=ovirtvm-vlan432
TYPE=Bridge
DELAY=0
STP=off
ONBOOT=yes
MTU=1500
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=no

Tuletan meelde, et klastrihostil EI OLE VASTAV käsitsi luua võrgu liideseid ifcfg-bond1.432 ja ifcfg-ovirtvm-vlan432.

Pärast loogilise võrgu lisamist ja ühenduse kontrollimist hosti ja VM vahel, saab seda kasutada virtuaalses masinas.

Virtuaalmasina juurutamiseks installitava pildi loomine

Link dokumentatsioonile — oVirt Administration Guide, Chapter 8: Storage, peatükk Piltide üleslaadimine andmehoidla domeeni.

Ilma operatsioonisüsteemi installipildita ei õnnestu virtuaalset masinat installida, kuigi see ei ole probleem, kui võrgus on seadistatud näiteks Cobbler eelnevalt loodud pildid.

Meie juhul sellist võimalust ei ole, seega tuleb see pilt oVirtisse ise importida. Varem oli selleks vajalik ISO domeeni loomine, kuid uues oVirti versioonis on see tunnistatud aegunuks, seega saab pilte otse andmehoidla domeeni laadida haldusteenuse kaudu.

Haldussüsteemis liigume Salvestus >> Diskid >> Laadi üles >> Alusta
Lisame meie operatsioonisüsteemi pildi ISO failina, täidame vormis kõik väljad ja klikime nuppu "Testi ühendust".

Ekraanipilt installipildi lisamise assistendist

Kui saame sellise tõrke:

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 "Usaldatud juursertifikaadid" (Trusted Root CA) administraatori juhtimisse, kust üritame pilti üles laadida.

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

Ühendus ovirt-imageio-proxyga oli edukas.

Pärast sertifikaadi lisamise toimingut saame proovida uuesti ISO pilti andmehoidla domeeni laadida.

Põhimõtteliselt on võimalik luua eraldi andmehoidla domeen tüübi Andmed jaoks, et hoida pilte ja malle eraldi VM-de kettadest, või isegi hoida neid andmehoidla domeenis hosted engine jaoks, kuid see on juba administraatori otsustada.

Ekraanipilt ISO piltidest andmehoidla domeenis hosted engine jaoks

Virtuaalmasina loomine

Dokumentatsiooni link:
oVirti virtuaalmasina haldamise juhend -> Peatükk 2: Linuxi virtuaalmasinate installimine
Konsoli klientide ressursid

Pärast oVirti operatsioonisüsteemi installifaili üleslaadimist saab liikuda otse virtuaalse masina loomise juurde. Palju on tööd tehtud, kuid me oleme juba viimases etapis, milleks kõik see ette oli võetud – saada töökindel infrastruktuur kõrge k disponible virtuaalsete masinate majutamiseks. Ja kogu see on täiesti tasuta – ei ole kulutatud ühtegi senti mingite tarkvara litsentside ostmiseks.

CentOS 7 virtuaalse masina loomiseks peab olema üles laetud operatsioonisüsteemi installifail.

Sisenege haldusportaalist ja minge Arvutus >> Virtuaalsed masinad, ning alustage VM loomise meistritegevust. Täitke kõik parameetrid ja väljad ning klõpsake OK. Kõik on väga lihtne, kui järgite dokumentatsiooni.

Näiteks teen peamiste ja lisaseadetega töötava VM, mis on loodud ketas, ühendatud võrku ja mille käivitamine toimub installimispildist:

Kuvatõmmised kõrge k disponible VM seadistustest

Pärast töö lõpetamist assistendiga sulgege see, käivitage uus VM ja installige sellele operatsioonisüsteem.
Selleks sisenege selle VM konsooli haldusportaalist:

Kuvatõmmise haldusportaalist VM konsooli ühendamiseks

Et VM konsooli juurde pääseda, tuleb eelnevalt seadistada konsool virtuaalse masina omadustes.

Kuvatõmmine VM seadistustest, vahekaart «Konsol»

VM konsooli ühendamiseks võib kasutada näiteks Virtuaalmasina vaataja.

Et ühendada VM konsooli otse brauseri aknas, peavad ühenduse seadistused olema järgmised:

Pärast operatsioonisüsteemi paigaldamist VM-ile on soovitatav installida oVirti 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.service

Seega on meie tegevuste tulemusena loodud VM kõrge k disponible, st kui ilmneb rike klastrisõlmes, millel see töötab, käivitab oVirt selle automaatselt teisel sõlmel. Samuti saab seda VM-i migreerida klastrihostide vahel nende hooldamiseks või muudel eesmärkidel.

Kokkuvõte

Loodan, et selle artikliga õnnestus edastada, et oVirt on täiesti normaalne tööriist virtuaalse infrastruktuuri haldamiseks, mille seadistamine ei ole nii keeruline – peamine on järgida teatud reegleid ja nõudeid, mis on kirjeldatud nii artiklis kui ka dokumentatsioonis.

Kuna artikli suurus ei võimaldanud paljusid asju sisse panna, näiteks erinevate meisterduste samm-sammult tegemisi koos üksikasjalike selgituste ja ekraanipiltidega, pikka kokkuvõtet teatud käskudest jne. Tegelikult sellele kuluks terve raamatu kirjutamine, mis pole eriti mõttekas, kuna tarkvaraversioonide pidev ilmumine toob mukan uusi uuendusi ja muudatusi. Peamine on mõista, kuidas kõik koos töötab, ja saada ülevaade toimingutest, et luua tõrkeotsinguga platvorm virtuaalmasinate haldamiseks.

Kuigi me oleme virtuaalse infrastruktuuri loonud, peame nüüd õpetama seda suhtlema mitte ainult oma eraldatud elementide vahel: hostide, virtuaalmasinate, sisemiste võrkude, vaid ka välismaailmaga.

See protsess on üks süsteemi- või võrguadministraatori põhitegevusi, mida avatakse järgmises artiklis — virtuaalsete ruutmete VyOS kasutamine meie ettevõtte tõrkeotsingulises infrastruktuuris (nagu te juba arvata võisite, töötavad nad virtuaalmasinatena meie oVirt klastris).

Allikas: habr.com