Stvaranje otporne IT infrastrukture. Dio 2. Instalacija i podešavanje oVirt 4.3 klastera

Ta članek je nadaljevanje prejšnjega – «Ustvarjanje odpornosti IT infrastrukture. Del 1 — priprava na širitev gruče oVirt 4.3».

V njem bo obravnavan postopek osnovne namestitve in konfiguracije klasterja oVirt 4.3 za gostovanje visoko razpoložljivih virtualnih strojev, pri čemer so bili vsi predhodni koraki za pripravo infrastrukture že izvedeni prej.

Uvodni del

Glavni cilj članka ni toliko podati korak za korakom navodila tipa «Next -> Da -> Dokončaj», ampak pokazati nekatere posebnosti pri njegovi namestitvi in konfiguraciji. Postopek postavitve vašega klasterja se morda ne bo vedno sklada z opisanem v njem zaradi značilnosti infrastrukture in okolja, vendar bodo skupna načela ostala enaka.

Z subjektivnega stališča, oVirt 4.3 ima funkcionalnosti, podobne VMware vSphere verziji 5.x, vendar seveda z nekaterimi svojimi značilnostmi nastavitve in delovanja.

Za tiste, ki jih zanima, so vse razlike med RHEV (tudi znan kot oVirt) in VMware vSphere dostopne na spletu, na primer ovde, a vseeno bom občasno omenil nekatere razlike ali podobnosti med seboj v teku članka.

Posebej bi želel nekoliko primerjati delo z omrežji za virtualne stroje. V oVirt-u so implementirane podobne načelne metode upravljanja omrežij za virtualne stroje (dalje VMs), kot v VMware vSphere:

• s pomočjo standardnega Linux bridge (v VMware — Standard vSwitch), ki deluje na gostiteljih virtualizacije;
• s pomočjo Open vSwitch (OVS) (v VMware — Distributed vSwitch) – gre za razdeljeni virtualni stikalo, ki ga sestavljata dva glavna komponenta: centralni strežnik OVN in kontrolerji OVN na upravljanih gostiteljih.

Potrebno je poudariti, da bo zaradi preprostosti izvedbe v članku opisana nastavitev omrežij v oVirt-u za VMs s pomočjo standardnega Linux bridge, ki je standardna izbira pri uporabi hipervizorja KVM.

Zaradi tega obstaja več osnovnih pravil za delo z omrežjem v klasterju, katerih je bolje ne kršiti:

• Vse omrežne nastavitve na gostiteljih morajo biti pred dodajanjem v oVirt identične, razen IP naslovov.
• Po tem, ko je gostitelj prevzet pod upravljanje oVirt-a, se na njem zelo odsvetuje spreminjanje omrežnih nastavitev ročno, brez popolnega prepričanja v svoje dejanja, saj bo oVirt agent preprosto ponastavil te nastavitve na prejšnje po ponovnem zagonu gostitelja ali agenta.
• Dodajanje novega omrežja za VMs, tako kot delo z njim, se mora izvajati samo iz konzole za upravljanje oVirt-a.

Še eno pomembno opozorilo — za zelo kritična okolja (zelo občutljiva na finančne izgube) bi bilo vseeno priporočljivo uporabiti plačano podporo in uporabiti Red Hat Virtualization 4.3. Med obratovanjem klasterja oVirt se lahko pojavijo nekateri trenutki, ko bi bilo zaželeno čim prej pridobiti kvalificirano pomoč, namesto da bi se s tem ukvarjali sami.

In nazadnje, priporočeno pred uvedbo klasterja oVirt se seznanite z uradne dokumentacije, da boste vsaj na tekočem z osnovnimi pojmi in definicijami, sicer bo kasneje branje članka nekoliko težavno.

Osnovni dokumenti za razumevanje članka in načel delovanja klasterja oVirt so naslednji:

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

Obseg tam ni zelo velik, v eni ali dveh urah se lahko obvladajo osnovna načela, za ljubitelje podrobnosti pa je priporočljivo prebrati Product Documentation for Red Hat Virtualization 4.3 — RHEV in oVirt sta v bistvu eno in isto.

Torej, če so vse osnovne nastavitve na gostiteljih, stikalih in SAN izvedene, preidemo neposredno k uvedbi oVirt.

Del 2. Namestitev in konfiguracija klasterja oVirt 4.3

Za lažje orientiranje bom podal seznam osnovnih razdelkov v tem članku, ki jih je potrebno zaporedno izvesti:

1. Namestitev upravljavskega strežnika oVirt
2. Ustvarjanje novega podatkovnega centra
3. Ustvarjanje novega klasterja
4. Namestitev dodatnih gostiteljev v self-hosted okolje
5. Ustvarjanje področij za shranjevanje ali Storage Domains
6. Ustvarjanje in konfiguracija omrežij za virtualne stroje
7. Ustvarjanje namestitvenega slike za uvedbo virtualnega stroja
8. Ustvarjanje virtualnega stroja

Namestitev upravljavskega strežnika oVirt

Upravni strežnik oVirt – je najpomembnejši element v infrastrukturi oVirt, v obliki virtualnega stroja, gostitelja ali virtualne naprave, ki upravlja celotno infrastrukturo oVirt.

Njegovi bližnji analogi iz sveta virtualizacije so:

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

Za namestitev upravljavskega strežnika oVirt imamo na voljo dve možnosti:

Možnost 1
Uvedba strežnika v obliki specializirane VM ali gostitelja.

Ta možnost deluje, vendar pod pogojem, da takšna VM deluje neodvisno od klasterja, tj. ni zagnana na katerem koli gostitelju klasterja v obliki običajnega virtualnega stroja pod nadzorom KVM.

Zakaj ni mogoče uvajati take VM na gostiteljih klasterja?

Na začetku postopka postavitve upravljavskega strežnika oVirt imamo dilemo — upravljavsko VM je potrebno postaviti, vendar samega klasterja dejansko še ni, zato kaj lahko hitro izmislimo? Pravilno – namestiti KVM na bodoči strežnik klasterja, nato pa na njem ustvariti virtualno napravo, na primer, z operacijskim sistemom CentOS in v njej postaviti oVirt engine. To se običajno dela iz razlogov popolnega nadzora nad to VM, vendar je to napačna namera, saj se v tem primeru v prihodnosti 100% pojavijo težave z to upravljavsko VM:

• ni mogoče migrirati v konzoli oVirt med gostitelji (vozli) klasterja;
• med migracijo s KVM preko virsh migrate, ta VM ne bo dostopna za upravljanje iz konzole oVirt.
• Gostiteljev klasterja ni mogoče postaviti v Maintenance mode (način vzdrževanja), če migrirate to VM z gostitelja na gostitelja s pomočjo virsh migrate.

Zato delajte vse po pravilih — uporabite za upravljavski strežnik oVirt ali ločen gostitelj, ali neodvisno VM, ki jo poganjate na njem, še bolje pa storite, kot je zapisano v drugem primeru.

Možnost 2
Namestitev oVirt Engine Appliance na upravljani gostiteljski klaster.

Ta možnost bo obravnavana naprej, kot bolj pravilna in primerna v našem primeru.
Zahteve za to VM so opisane spodaj, dodajam le, da je priporočljivo imeti vsaj dva gostitelja v infrastrukturi, na katerih lahko deluje upravljavska VM, da bi bila odporna na napake. Tu bi rad dodal, da kot sem že pisal v komentarjih v prejšnjem članku, mi ni uspelo doseči splitbrain na klasterju oVirt z dvema gostiteljema, pri čemer je možen zagon hosted-engine VM na njiju.

Namestitev oVirt Engine Appliance na prvi gostitelj klasterja

Povezava na uradno dokumentacijo — oVirt Self-Hosted Engine Guide, poglavje „Deploying the Self-Hosted Engine Using the Command line»

V dokumentu so navedeni predpogoji, ki jih je treba izpolniti pred postavitvijo hosted-engine VM, ter podrobno opisuje sam proces njene namestitve, zato ni posebnega smisla ponavljati ga dobesedno, osredotočimo se na nekatere pomembne podrobnosti.

• Pred začetkom vseh dejanj obvezno omogočite podporo virtualizaciji v nastavitvah BIOS-a na gostitelju.
• Na gostitelju namestite paket za namestitev hosted-engine:

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

• Зап запуска на хосте procedura развёртывания oVirt Hosted Engine в screen’е (выйти из него можно через Ctrl-A + D, закрыть через Ctrl-D):

screen
hosted-engine --deploy

При желании можно запустить установку с заранее подготовленным файлом ответов:

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

• Во время развёртывания hosted-engine, указываем все необходимые параметры:

- имя кластера
- количество vCPU и vRAM (рекомендуется 4 vCPU и 16 Гб)
- пароли
- тип хранилища для hosted engine ВМ – в нашем случае FC
- номер LUN для установки hosted engine
- где будет находиться база данных для hosted engine – рекомендую для простоты выбрать Local (это БД PostgreSQL работающая внутри этой ВМ)
и др. параметры. 

• Для установки высокодоступной ВМ с hosted engine, на СХД нами был заранее создан специальный LUN под номером 4 и размером 150 Гб, который затем был презентован хостам кластера – см. в prejšnjem članku.

Ранее мы также проверяли его видимость на хостах:

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 ничего сложного в себе не несёт, в его конце мы должны получить примерно такое сообщение:

[ 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

Проверяем наличие сервисов oVirt на хосте:

Если всё было сделано правильно, то после окончания установки заходим с помощью веб-браузера на https:\/\/ovirt_hostname\/ovirt-engine с компьютера администратора, и кликаем [Administration Portal].

Скриншот «Administration Portal»

Введя логин и пароль (заданные в процессе установки) в окно как на скриншоте, попадаем в панель управления Open Virtualization Manager, в которой можно производить все действия с виртуальной инфраструктурой:

1. добавлять датацентр
2. добавлять и настраивать кластер
3. добавлять хосты и управлять ими
4. добавлять области хранения или Storage Domains, для дисков виртуальных машин
5. добавлять и настраивать сети для виртуальных машин
6. добавлять виртуальные машины, установочные образы, шаблоны ВМ и управлять ими

Все эти действия будут рассмотрены далее, что-то в крупную клетку, что-то более подробно и с нюансами.
Najpre bi bilo dobro pročitati ovaj dodatak, koji sigurno može biti koristan mnogima.

Dodatek

1) U principu, ako postoji potreba, ništa ne sprečava da unapred instalirate KVM hipervizor na čvorove klastera, koristeći pakete libvirt in qemu-kvm (ali qemu-kvm-ev) željene verzije, iako tokom postavljanja oVirt klaster čvora, to može učiniti i samo.

Međutim, ako libvirt in qemu-kvm su instalirane stare verzije, može doći do sledeće greške tokom postavljanja hosted engine:

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

To jest, potrebno je imati ažuriranu verziju libvirt sa zaštitom od MDS, koja podržava ovu politiku:

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

Instaliramo libvirt v.4.5.0-10.el7_6.12, sa podrškom za 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

Proveravamo prisutnost podrške za 'md-clear':

virsh domcapabilities kvm | grep require

Nakon toga, možete nastaviti sa instalacijom hosted engine.

2) U oVirt 4.3, prisustvo i korišćenje vatrozida firewalld je obavezan zahtev.

Ako tokom postavljanja VM za hosted-engine dobijete ovu grešku:

[ 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=1608467

Potrebno je isključiti drugi vatrozi (ako se koristi), i instalirati i pokrenuti 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

U budućnosti, prilikom instalacije agenta ovirt na novom hostu za klaster, on će automatski konfigurirati potrebne portove. firewalld automatski.

3) Ponovno pokretanje hosta sa radnom VM sa hosted engine.

Kao i obično, povezava 1 in povezava 2 na dokumentaciju.

Sva upravljanja hosted engine VM obavljaju se SAMO putem komande hosted-engine na hostu gde radi, zaboravite na virsh to, kao i na to da se ovoj VM može pristupiti putem SSH i na njoj izvršiti komandu "shutdown».

Postopek za preklop VM v način vzdrževanja:

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

hosted-engine --vm-status
!! Grozdi so v GLOBAL MAINTENANCE načinu !!
--== Gostitelj host1.test.local (id: 1) status ==--
conf_on_shared_storage             : True
Status posodobljen                  : True
Ime gostitelja                       : host1.test.local
ID gostitelja                        : 1
Status naprave                      : {"health": "good", "vm": "up", "detail": "Up"}
Ocena                              : 3400
ustavljen                          : False
Lokalno vzdrževanje                  : False
crc32                              : dee1a774
local_conf_timestamp               : 1821
Časovni žig gostitelja             : 1821
Dodatni metapodatki (veljavna ob časovnem žigu):
        metadata_parse_version=1
        metadata_feature_version=1
        timestamp=1821 (Sob Nov 29 14:25:19 2019)
        host-id=1
        score=3400
        vm_conf_refresh_time=1821 (Sob Nov 29 14:25:19 2019)
        conf_on_shared_storage=True
        maintenance=False
        state=GlobalMaintenance
        stopped=False

hosted-engine --vm-shutdown

Ponovno zagnamo gostitelja z agentom hosted engine in izvedemo potrebne operacije.

Po ponovnem zagonu preverimo status VM z agentom hosted engine:

hosted-engine --vm-status

Če se naš VM z agentom hosted-engine ne zažene in če vidimo podobne napake v dnevniku storitve:

Napaka v dnevniku storitve:

journalctl -u ovirt-ha-agent
...
Jun 29 14:34:44 host1 dnevnik: ovirt-ha-agent ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine ERROR Napaka pri zagonu potrebnih monitorjev
Jun 29 14:34:44 host1 dnevnik: 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 - ni uspelo zagnati monitorja preko ovirt-ha-broker: [Errno 2] Ni take datoteke ali imenika, [monitor: 'ping', options: {'addr': '172.20.32.32'}]
Jun 29 14:34:44 host1 dnevnik: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent ERROR Poskus ponovnega zagona agenta

Torej povežemo shrambo in ponovno zagnamo agenta:

hosted-engine --connect-storage
systemctl restart ovirt-ha-agent
systemctl status ovirt-ha-agent

hosted-engine --vm-start
hosted-engine --vm-status

Po zagonu VM z agentom hosted-engine, jo preklopimo iz načina vzdrževanja:

Postopek za preklop VM iz načina vzdrževanja:

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) Odstranění hosted engine a všeho s ní spojeného.

Někdy je nezbytné správně odstranit dříve nainstalovaný hosted engine — povezava na základě dokumentace.

Jednoduše provedeme příkaz na hostu:

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

Dále odstraníme nepotřebné balíčky, přičemž předtím zálohujeme některé konfigurace, pokud je to nutné:

yum autoremove ovirt* qemu* virt* libvirt* libguestfs 

Ustvarjanje novega podatkovnega centra

Referenční dokumentace — oVirt Administration Guide. Kapitola 4: Datacentra

Nejprve určíme, co je to datacentrum (cituji z dokumentace) — to je logická entita, která definuje soubor zdrojů používaných ve specifickém prostředí.

Datacentrum je jakýsi kontejner, který se skládá z:

• logických zdrojů ve formě clustrů a hostů
• síťových zdrojů clustrů ve formě logických sítí a fyzických adaptérů na hostech,
• úložišť (pro disky VM, šablony, obrazy) ve formě úložných domén (Storage Domains).

Datacentrum může zahrnovat několik clustrů, které se skládají z několika hostů s virtuálními stroji běžícími na nich, může mít také několik úložných domén asociovaných s ním.
Může existovat více datacenter, která pracují nezávisle na sobě. V oVirt dochází k dělení oprávnění na základě rolí a lze nastavit oprávnění individuálně, jak na úrovni datacentra, tak na jednotlivé logické prvky.

Datacentrum, nebo datacentra, pokud jich je více, jsou spravována z jediné administrativní konzole nebo portálu.

Chcete-li vytvořit datacentrum, přihlaste se do administrativního portálu a vytvořte nové datacentrum:
Compute >> Datacentra >> Nov

Jelikož používáme sdílené úložiště na SAN, musí být typ úložiště (Storage Type) nastaven na Shared:

Snímek obrazovky s průvodcem vytvořením datacentra

Pri namestitvi virtualnega strežnika z hosted-engine se privzeto ustvari podatkovno središče – Datacenter1, in nato, če je potrebno, se lahko spremeni tip shranjevanja (Storage Type) na drugega.

Ustvarjanje podatkovnega središča ni zapletena naloga, brez kakšnih posebej kompleksnih podrobnosti, vse dodatne dejavnosti z njim so opisane v dokumentaciji. Edina opomba je, da posamezni gostitelji, ki imajo le lokalno shranjevanje (disk) za VM, ne morejo vstopiti v podatkovno središče s tipom shranjevanja – Shared (ne moremo jih dodati), za njih je potrebno ustvariti ločeno podatkovno središče – torej vsakemu posameznemu gostitelju z lokalnim shranjevanjem je potrebno svoje ločeno podatkovno središče.

Ustvarjanje novega klasterja

Povezava do dokumentacije – oVirt Administration Guide. Poglavje 5: Klasterji

Brez odvečnih podrobnosti, grozd – to je logična skupina gostiteljev, ki imajo skupno področje shranjevanja (v obliki skupnih diskov na shranjevalnih sistemih, kot v našem primeru). Prav tako je zaželeno, da so gostitelji v klastru enaki glede strojne opreme in imajo enako vrsto procesorja (Intel ali AMD). Najbolje je, da so strežniki v klastru popolnoma enaki.

Klaster je del podatkovnega središča (s določenim tipom shranjevanja – Local ili Skupna), vsi gostitelji pa morajo nujno pripadati kakšnemu klastru, odvisno od tega, ali imajo skupno shranjevanje ali ne.

Pri namestitvi virtualnega strežnika z hosted-engine na gostitelju se privzeto ustvari podatkovno središče – Datacenter1, skupaj s klastrom – Cluster1, in nato lahko nastavite njegove parametre, vključite dodatne možnosti, dodate gostitelje itd.

Kot običajno, za podrobnosti o vseh nastavitvah klastru, je priporočljivo, da se posvetujete z uradno dokumentacijo. Kar se tiče posebnosti nastavitve klastru, dodam le to, da je ob njegovi ustvaritvi dovolj, da nastavite samo osnovne parametre na zavihku Splošno.

Omenil bom najbolj pomembne parametre:

• Vrsta procesorja – se izbere glede na to, kateri procesorji so nameščeni na gostiteljih klastru, od katerega proizvajalca so in kateri procesor na gostiteljih je najstarejši, da se na tej osnovi uporabi vse razpoložljive procesorske instrukcije v klastru.
• Vrsta stikala – v našem klastru uporabljamo le Linux bridge, zato ga izberemo.
• Vrsta požarnega zidu – tukaj je vse jasno, to je firewalld, ki mora biti vklopljen in nastavljen na gostiteljih.

Posnetek zaslona s parametri klastru

Namestitev dodatnih gostiteljev v okolju Self-Hosted

Link na dokumentacijo.

Dodatni gostitelji za okolje Self-Hosted se dodajajo enako kot običajni gostitelj, s dodatnim korakom za namestitev VM z gostiteljem – Izberite dejanje za namestitev gostitelja >> Deploy. Ker mora biti tudi dodatnemu gostitelju predstavljen LUN za VM z gostiteljem, to pomeni, da se ta gostitelj lahko po potrebi uporablja za gostovanje VM z gostiteljem.
Zaradi odpornosti priporočamo, da sta prisotna vsaj dva gostitelja, na katerih lahko gostuje VM z gostiteljem.

Na dodatnem gostitelju izklopimo iptables (če je vklopljen) in vklopimo firewalld

systemctl stop iptables
systemctl disable iptables

systemctl enable firewalld
systemctl start firewalld

Namestimo zahtevano različico KVM (po potrebi):

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

Namestimo potrebne repozitorije in namestitveni program za gostitelja:

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

Nato preidemo v konzolo Open Virtualization Manager, dodamo nov gostitelj in izvajamo vse korake, kot je navedeno v dokumenti.

Kot rezultat, po dodajanju dodatnega gostitelja, bi morali imeti približno sliko v administrativni konzoli, kot na posnetku zaslona.

Posnetek zaslona administrativnega portala — gostitelji

Gostitelj, na katerem je trenutno aktiven VM z gostiteljem, ima zlato krono in napis „Running the Hosted Engine VM“, gostitelj, na katerem se lahko ta VM po potrebi zažene – napis „Can run the Hosted Engine VM».

V primeru napake gostitelja, na katerem „Running the Hosted Engine VM“, se bo avtomatsko ponovno zagnala na drugem gostitelju. Tudi to VM se lahko preseli z aktivnega gostitelja na rezervnega za njegovo vzdrževanje.

Nastavitev upravljanja z energijo / fencing na gostiteljih oVirt

Povezave do dokumentacije:

• Red Hat Virtualization 4.3 –> Tehnična referenca -> Poglavje 4. Upravljanje z energijo
• oVirt Administrativni priročnik -> Poglavje 7: Gostitelji

Čeprav se zdi, da sta dodajanje in nastavitev gostitelja končana, pa to ni povsem res.
Za normalno delovanje gostiteljev in odkrivanje/odpravljanje napak z njimi, je potrebna nastavitev upravljanja z energijo / fencing.

Fencing, ali ograđivanje – to je proces privremenog isključenja neispravnog ili neuspešnog hosta iz klastera, tokom kojeg se ponovo pokreću ili servisi oVirt na njemu, ili sam host.

Sve pojedinosti o definicijama i parametrima Power Management / ograđivanja su date, kao obično u dokumentaciji, samo ću navesti primer kako podesiti ovaj važan parametar, u odnosu na Dell R640 servere sa iDRAC 9.

1. Ulazimo u administrativni portal, kliknemo Compute >> Hosts izbor hosta.
2. Kliknemo Uredi.
3. Kliknite na karticu Power Management.
4. Obeležavamo kvačicu pored opcije Enable Power Management.
5. Obeležavamo kvačicu pored opcije Kdump integracija, kako bi host prešao u režim ograđivanja (fencing) tokom snimanja kritične dump datoteke.

Opomba.

Nakon uključivanja Kdump integracije na već aktivnom hostu, mora se ponovo instalirati u skladu sa procedurom iz oVirt Administration Guide -> Poglavje 7: Gostitelji -> Ponovna instalacija hostova.

1. Opcionalno se može označiti kvačica Disable policy control of power management, ako ne želimo da upravljanje napajanjem hosta bude kontrolisano politikom planiranja (Scheduling Policy) klastera.
2. Kliknite na dugme (+), da dodate novu uređaj za upravljanje napajanjem, otvoriće se prozor za uređivanje svojstava agenta.
   Za iDRAC9, popunite polja:
   • Address – adresa iDRAC9
   • Korisničko ime / Lozinka – odgovarajući korisnički naziv i lozinka za pristup iDRAC9
   • Tip — drac5
   • отметить Secure
   • dodajte sledeće opcije: cmd_prompt=>,login_timeout=30

Screenshot sa parametrima „Power Management“ u svojstvima hosta

Ustvarjanje področij za shranjevanje ali Storage Domains

Link na dokumentaciju — oVirt Administration Guide, Poglavlje 8: Storage.

Storage Domain, ili oblast skladišta – to je centralizovano mesto za skladištenje diskova virtuelnih mašina, instalacionih slika, šablona i snimaka.

Oblasti skladišta mogu se povezivati sa data centrom koristeći različite protokole, klasterske i mrežne fajl sisteme.

oVirt ima tri tipa oblasti skladišta:

• Data Domain – za skladištenje svih podataka povezanih sa virtuelnim mašinama (diskovi, šabloni). Data Domain ne može se deliti između različitih data centara.
• ISO Domain (zastarjeli tip oblasti skladišta) – za skladištenje instalacionih slika OS-a. ISO Domain se može deliti između različitih data centara.
• Export Domain (zastarjeli tip oblasti skladišta) – za privremeno skladištenje slika premeštenih između data centara.

U našem posebnom slučaju oblast skladišta tipa Data Domain koristi Fibre Channel Protocol (FCP) za povezivanje sa LUN-ovima na SAN-u.

Z vidika oVirt, pri uporabi SANS (FC ali iSCSI) je vsak virtualni disk, posnetek ali predloga logični disk.
Blokovne naprave so združene v celoto (na gostiteljih gruč) s pomočjo Volume Group in nato razdeljene s pomočjo LVM na logične volumne, ki se uporabljajo kot virtualni diski za VM.

Vse te skupine in množico LVM volumnov je mogoče videti na gostitelju gruč, s pomočjo ukazov vgs in lvs. Naravno je, da je treba vse operacije s takimi diski izvajati samo iz konzole oVirt, razen v posebnih primerih.

Virtualni diski za VM so dveh tipov — QCOW2 ali RAW. Diski so lahko "tanki" ali "debeli". Posnetki se vedno ustvarjajo kot "tanki".

Upravni sistem Storage domains, ali področij shranjevanja, do katerih je dostop preko FC, je dokaj logičen — za vsak virtualni disk VM obstaja ločen logični volumen, ki je dostopen za pisanje le enemu gostitelju. V primeru povezav preko FC, oVirt uporablja nekaj podobnega klasterskemu LVM.

Virtualne naprave, ki se nahajajo v enem področju shranjevanja, lahko migriramo med gostitelji, ki pripadajo istemu klastru.

Kot vidimo iz opisa, klaster v oVirt, prav tako kot klaster v VMware vSphere ali Hyper-V, v resnici pomeni eno in isto – to je logična grupacija gostiteljev, ki so po možnosti enaki po sestavi ‘železa’ in imajo skupno shranjevanje za diske virtualnih naprav.

Pojdimo neposredno k ustvarjanju področja shranjevanja za podatke (diske VM), saj brez njega podatkovni center ne bo inicializiran.
Spomnim se, da morajo biti vsi LUNi, predstavljeni gostiteljem gruč, na SANS vidni s pomočjo ukaza "multipath -ll».

Po dokumenti", gremo v portal in vstopimo v Shramba >> Domeni -> New Domain in sledimo navodilom iz razdelka "Adding FCP Storage".

Po zagonu čarovnika izpolnimo zahtevana polja:

• Ime — vnesemo ime klastru
• Domain Function — Data
• Storage Type — Fibre Channel
• Host to Use — izberemo gostitelja, na katerem je dostopen želeni LUN

Na seznamu LUNov označimo tistega, ki ga potrebujemo, kliknemo Dodaj a zatim O.K.. Po potrebi lahko prilagodimo dodatne parametre področja shranjevanja, tako da kliknemo na Advanced Parameters.

Posnetek čarovnika za dodajanje ‘Storage domain’

Na podlagi rezultatov delovanja čarovnika moramo prejeti novo področje shranjevanja, naš podatkovni center pa preide v status UP, ali inicializiran:

Posnetki podatkovnega centra in področij shranjevanja v njem:

Ustvarjanje in konfiguracija omrežij za virtualne stroje

Link na dokumentaciju — oVirt Administration Guide, Poglavje 6: Logična omrežja

Omrežja služijo za grupiranje logičnih omrežij, ki se uporabljajo v virtualni infrastrukturi oVirt.

Za interakcijo omrežnega adapterja na virtualnem stroju s fizičnim adapterjem na gostitelju se uporabljajo logični vmesniki tipa Linux bridge.

Za grupiranje in ločevanje prometa med omrežji so na stikalah nastavljeni VLAN-i.

Pri ustvarjanju logičnega omrežja za virtualne stroje v oVirt je potrebno dodeliti identifikator, ki ustreza številki VLAN na stikalu, da bi se VM-ji lahko medsebojno povezovali, tudi če delujejo na različnih vozliščih v grozdu.

Predhodne nastavitve omrežnih adapterjev na gostiteljih za povezavo virtualnih strojev morajo biti opravljene v prejšnjem članku – nastavljen logični vmesnik bond1, nato pa morajo biti vse omrežne nastavitve opravljene le prek upravljalskega portala oVirt.

Po ustvarjanju VM s hosted-engine je bil poleg samodejnega ustvarjanja podatkovnega središča in grozda samodejno ustvarjen tudi logični omrežni vmesnik za upravljanje našega grozda – ovritmgmt, na katerega je bil povezan ta VM.

Če je potrebno, si lahko ogledate nastavitve logičnega omrežja ovritmgmt in jih prilagodite, vendar bodite previdni, da ne izgubite nadzora nad infrastrukturo oVirt.

Nastavitve logičnega omrežja ovritmgmt

Za ustvarjanje novega logičnega omrežja za običajne VM, v upravljalskem portalu preidite v Mreža >> Networks >> Nov, in na zavihku Splošno dodajte omrežje z zahtevanim identifikatorjem VLAN, ter označite polje "VM Network", kar pomeni, da se lahko uporablja za dodelitev VM-jem.

Posnetek novega logičnega omrežja VLAN32

Na zavihku Cluster, povežite to omrežje z našim grozdom Cluster1.

Nato preidite v Compute >> Hosts, posamezno vstopite v vsak gostitelj, na zavihek Omrežni vmesniki, in zaženite čarovnika Nastavi omrežja gostitelja, za povezavo novega logičnega omrežja s gostitelji.

Posnetek čarovnika "Nastavi omrežja gostitelja"

Agent oVirt bo samodejno opravil vse potrebne omrežne nastavitve na gostitelju – ustvaril bo VLAN in BRIDGE.

Primer konfiguracijskih datotek za nova omrežja na gostitelju:

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

Še enkrat opozarjam, da na gostitelju klasterja NI TREBA vnaprej ročno ustvarjati omrežnih vmesnikov ifcfg-bond1.432 in ifcfg-ovirtvm-vlan432.

Po dodajanju logične mreže in preverjanju povezave med gostiteljem in VM z hosted engine, jo je mogoče uporabiti v virtualnem stroju.

Ustvarjanje namestitvenega slike za uvedbo virtualnega stroja

Link na dokumentaciju — oVirt Administration Guide, Poglavlje 8: Storage, razdelka Nalaganje slik v domeno podatkovnega shranjevanja.

Brez namestitvenega slikovnega objekta ne bo mogoče namestiti virtualnega stroja, čeprav to seveda ni težava, če je v omrežju na voljo, na primer, Cobbler s vnaprej ustvarjenimi slikami.

V našem primeru te možnosti ni, zato bomo morali sami uvoziti to sliko v oVirt. Prej je bilo za to potrebno ustvariti ISO domeno, vendar je bila v novi različici oVirt ta priznana za zastarelo, zato je zdaj mogoče nalagati slike neposredno v Storage domain iz administrativnega portala.

V administrativnem portalu gremo na Shramba >> Diski >> Upload >> Začni
Dodamo našo sliko OS v obliki ISO datoteke, v obrazec izpolnimo vsa polja in kliknemo gumb "Preizkusite povezavo".

Posnetek zaslona čarovnika za dodajanje namestitvene slike

Če prejmemo napako te vrste:

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

je treba dodati certifikat oVirt v «Zanesljivi korenski CA» (Trusted Root CA) na upravljalni postaji administratorja, od koder poskušamo naložiti sliko.

Po dodajanju certifikata v Trusted Root CA ponovno kliknemo "Preizkusite povezavo", morali bi prejeti:

Povezava do ovirt-imageio-proxy je bila uspešna.

Po izvedbi dejanja dodajanja certifikata lahko ponovno poskusimo naložiti ISO sliko v Storage Domain.

Načeloma lahko ustvarite ločen Storage Domain z vrsto Podatkov, za shranjevanje slik in predlog ločenih od diskov VM, ali pa jih celo shranite v Storage Domain za hosted engine, vendar je to že odvisno od odločitve administratorja.

Posnetek zaslona s slikami ISO v Storage Domain za hosted engine

Ustvarjanje virtualnega stroja

Povezava do dokumentacije:
oVirt Virtual Machine Management Guide –> Poglavje 2: Namestitev Linux virtualnih strojev
Viri konzolnih strank

Po nalaganju namestitvene slike operacijskega sistema v oVirt, lahko neposredno preidemo na ustvarjanje virtualnega stroja. Opravljeno je bilo veliko dela, vendar smo že na zaključni fazi, za kar vse to tudi je bilo namenjeno – pridobitev odpornosti infrastrukture za gostovanje visokoodpornih virtualnih strojev. In kar je najbolje, vse to je povsem brezplačno – za nakup kakršnih koli licenc programske opreme ni bilo porabljenega niti centa.

Za ustvarjanje virtualnega stroja s CentOS 7, mora biti naložena namestitvena slika operacijskega sistema.

Vstopimo v upravni portal, gremo na Compute >> Virtual Machines, in zaženemo čarovnika za ustvarjanje VM. Izpolnimo vse parametre in polja ter kliknemo O.K.. Vse je zelo preprosto, če sledite dokumentaciji.

Kot primer bom navedel osnovne in dodatne nastavitve visokoodpornega VM, z ustvarjenim diskom, povezanega v omrežje, in z nalaganjem iz namestitvene slike:

Posnetki zaslona z nastavitvami visokoodpornega VM

Po končanih delo s čarovnikom, ga zaprete, zaženete nov VM in namestite operacijski sistem nanj.
Za to vstopimo v konzolo tega VM preko upravnega portala:

Posnetek zaslona nastavitev upravnega portala za povezavo s konzolo VM

Da se povežete s konzolo VM, morate najprej nastaviti konzolo v lastnostih virtualnega stroja.

Posnetek zaslona nastavitev VM, zavihek „Console“

Za povezavo s konzolo VM lahko uporabite, na primer, Virtual Machine Viewer.

Da se povežete s konzolo VM neposredno v oknu brskalnika, morajo biti nastavitve povezave preko konzole take:

Po namestitvi operacijskega sistema na VM, je priporočljivo namestiti oVirt guest agent:

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

Tako bo v rezultatih naših dejanj ustvarjen VM visokoodporen, tj. v primeru okvare vozlišča klasterja, na katerem je zagnan, ga bo oVirt samodejno znova zagnal na drugem vozlišču. Prav tako lahko ta VM migrirate med gosti klasterja za njihovo vzdrževanje ali druge namene.

Zaključek

Upam, da mi je v tem članku uspelo prenesti, da je oVirt povsem normalen pripomoček za upravljanje virtualne infrastrukture, ki ga ni tako težko vzpostaviti — pomembno je le upoštevati določena pravila in zahteve, opisane tako v članku kot v dokumentaciji.

Zaradi velikega obsega članka vanj ni bilo mogoče vključiti mnogih stvari, kot so korak za korakom izvedbe različnih čarovnikov z vsemi podrobnimi razlagami in posnetki zaslona, dolge izpise nekaterih ukazov itd. V resnici bi za to bilo potrebno napisati celo knjigo, kar nima posebnega smisla, zaradi nenehnega pojava novih različic programske opreme z novostmi in spremembami. Najpomembnejše je razumeti načelo, kako vse skupaj deluje, in pridobiti skupni algoritem dejanj za ustvarjanje odpornosti sistema za upravljanje virtualnih strojev.

Čeprav smo ustvarili virtualno infrastrukturo, jo moramo zdaj naučiti komunicirati tako med njenimi posameznimi elementi: gostitelji, virtualnimi stroji, notranjimi omrežji, kot tudi z zunanjim svetom.

Ta proces je ena od glavnih nalog sistemskega ali omrežnega administratorja, ki bo razkrito v naslednjem članku - o uporabi virtualnih usmerjevalnikov VyOS v odpornosti infrastrukture našega podjetja (kot ste uganili, bodo delovali kot virtualni stroji v našem oVirt klastru).

Izvor: habr.com