Hibatűrő IT infrastruktúra létrehozása. 2. rész. Az oVirt 4.3 klaszter telepítése és konfigurálása

Ez a cikk a korábbi " folytatása.A megbízható IT-infrastruktúra kialakítása. 1. rész – felkészülés az oVirt 4.3 klaszter telepítésére».

Ebben a cikkben a 4.3-as verziójú oVirt klaszter alapértelmezett telepítési és beállítási folyamatát tárgyaljuk, amely képes magas rendelkezésre állású virtuális gépek (VM) hosztolására, figyelembe véve, hogy az összes korábbi lépés már el lett végezve az infrastruktúra előkészítése során.

Bevezető rész

A cikk fő célja nem annyira egy lépésről lépésre útmutató megadása, mint inkább az, hogy bemutassa a telepítés és beállítás során felmerülő néhány sajátosságot.Tovább -> Igen -> 9. ábra: A kapcsolatgyártó létrehozásának befejezése, hanem hogy néhány sajátosságot mutasson be az installáció és konfigurálás során. Az Ön klaszterének telepítési folyamata néha eltérhet a leírtaktól, az infrastruktúra és a környezet sajátosságai miatt, de az alapelvek azonosak lesznek.

Szubjektív szempontból oVirt 4.3 funkcionalitása hasonlít a VMware vSphere 5.x verziójára, de természetesen saját beállítási és működési sajátosságaival rendelkezik.

Érdeklődők számára az RHEV (alias oVirt) és a VMware vSphere közötti eltérésekről több információt találhat az interneten, például itt, de néha meg fogom említeni a kettejük közötti különbségeket vagy hasonlóságokat a cikk során.

Külön szeretném egy kicsit összehasonlítani a virtuális gépek hálózati kezelését. Az oVirt hasonló elvet alkalmaz a virtuális gépek (VM) hálózatainak kezelésére, mint a VMware vSphere:

• a standard Linux bridge segítségével (VMware esetén Standard vSwitch), amely a virtualizációs hosztokon működik;
• Open vSwitch (OVS) segítségével (VMware esetén Distributed vSwitch) – ez egy elosztott virtuális kapcsoló, amely két fő komponensből áll: a központi OVN szerverből és az irányítókból, amelyek a kezelt hosztokon találhatók.

Meg kell jegyezni, hogy a megvalósítás egyszerűsége miatt a cikkben az oVirt VM-jeihez tartozó hálózatok beállításának leírása a standard Linux bridge segítségével történik, amely a KVM hypervisor használatakor a default választás.

Ennek megfelelően néhány alapvető szabályt érdemes betartani a klaszter hálózati működése során:

• Minden hálózati beállításnak az oVirt-be való hozzáadás előtt azonosnak kell lennie a hosztokon, a IP címek kivételével.
• Miután a hosztot az oVirt irányítása alá vonják, semmiképpen sem javasolt kézzel megváltoztatni a hálózati beállításokat, hacsak nincs teljes bizonyosság a lépésekről, mivel az oVirt ügynöke visszaállítja azokat az előző állapotra a hoszt vagy az ügynök újraindítása után.
• Új hálózat hozzáadása a VM-hez, akárcsak annak kezelése, csak az oVirt irányítópultjából végezhető el.

Még egy fontos megjegyzés — a rendkívül kritikus környezetekhez (melyek jelentősen érzékenyek a pénzügyi veszteségekre) mindenképpen javallott a fizetett támogatás igénybevétele, és Red Hat Virtualization 4.3. Az oVirt klaszter üzemeltetése során előfordulhatnak olyan helyzetek, ahol célszerű minél hamarabb szakképzett segítséget kérni, ahelyett, hogy magunk próbálnánk megoldani.

És végül, ajánlott az oVirt klaszter telepítése előtt érdemes megismerkedni a hivatalos dokumentációval, hogy legalább az alapfogalmakat és meghatározásokat megértsük, különben később nehézkes lehet a cikk olvasása.

A cikk és az oVirt klaszter működésének megértéséhez ezek az irányelv dokumentumok alapvetőek:

• oVirt Telepítési Útmutató
• oVirt Saját Hozzáférési Motor Útmutató
• oVirt Adminisztrációs Útmutató
  

A terjedelem nem túl nagy, egy-két óra alatt könnyedén elsajátíthatók az alapelvek, míg a részletek iránt érdeklődőknek ajánlott elolvasni Termékdokumentáció a Red Hat Virtualization 4.3-hoz — a RHEV és az oVirt lényegében ugyanaz.

Tehát, ha minden alapvető beállítás a hosztokon, switcheken és tárolókon (SCS) elkészült, léphetünk a konkrét oVirt telepítésre.

2. rész. Az oVirt 4.3 klaszter telepítése és beállítása

A könnyű tájékozódás érdekében felsorolom a cikk főbb részeit, amelyeknek sorban teljesülniük kell:

1. Az oVirt vezérlő szerver telepítése
2. Új adattér létrehozása
3. Új klaszter létrehozása
4. További hosztok telepítése Saját Hozzáférésű környezetbe
5. Tárolóterületek létrehozása
6. Hálózatok létrehozása és konfigurálása virtuális gépekhez
7. Telepítési kép létrehozása virtuális gép telepítéséhez
8. Virtuális gép létrehozása

Az oVirt vezérlő szerver telepítése

Az oVirt vezérlő szerver — az oVirt infrastruktúrájának legfontosabb eleme, amely virtuális gépként, hosztként vagy virtuális eszközként működik, és irányítja az egész oVirt infrastruktúrát.

Közeli analógjai a virtualizáció világában:

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

Az oVirt vezérlő szerver telepítésére két lehetőségünk van:

1. lehetőség
Szerezzük be a szervert egy speciális VM vagy hoszt formájában.

Ez a lehetőség teljesen működőképes, de csak akkor, ha ez a VM függetlenül működik a klasztertől, tehát nem indítják el egy klaszterhoszton, mint egy szokásos virtuális gépet KVM kezelésével.

Miért nem telepíthetünk ilyen VMt a klaszter hosztjaira?

Az oVirt vezérlőszerver telepítési folyamatának kezdetén egy dilemmával állunk szemben – szükség van a vezérlő virtuális gépre (VM), de magának a klaszternak lényegében még nincs, ezért mit lehet hirtelen kitalálni? Helyes válasz – telepíteni a KVM-et a jövőbeli klaszternódra, majd létrehozni rajta egy virtuális gépet, például CentOS operációs rendszerrel, és abban telepíteni az oVirt engine-t. Ezt általában a VM teljes körű ellenőrzésének érdekében szokták megtenni, de ez téves szándék, mivel így a későbbiekben 100%-os problémák merülhetnek fel ezzel a vezérlő VM-mel:

• nem lehet migrálni az oVirt konzolon a klaszter hosztjai (nódjai) között;
• a KVM eszközeivel történő migráció során virsh migrate, ez a VM nem lesz elérhető az oVirt konzolból történő kezeléshez.
• A klaszter hosztjait nem lehet karbantartási módban ( Maintenance mode ) használni, ha ezt a VM-t hosztról hosztra migráljuk a virsh migrate.

Tehát mindent a szabályok szerint kell csinálni – használjon oVirt vezérlőszervert egy külön hoszton, vagy egy attól független VM-en, de jobb, ha a második lehetőség szerint jár el.

2. lehetőség
oVirt Engine Appliance telepítése az általa kezelt hosztra a klaszterben.

Pontosan ezt a lehetőséget fogjuk később tárgyalni, mint a helyesebb és megfelelőbb megoldást a mi esetünkben.
Az e VM-re vonatkozó követelmények alább vannak leírva, csak annyit fűznék hozzá, hogy ajánlott legalább két hosztot fenntartani az infrastruktúrában, ahol a vezérlő VM futtatható, hogy biztosítsuk a hibatűrést. Itt szeretném megjegyezni, hogy ahogy már korábbi cikkemben említettem a megjegyzésekben, így sem sikerült elérni a splitbrain a két hoszttal rendelkező oVirt klaszteren, hogy lehetővé váljon a hosted-engine VM indítása rajtuk.

oVirt Engine Appliance telepítése a klaszter első hosztjára

Hivatalos dokumentáció linkje – oVirt Saját Hozzáférési Motor Útmutató, a «A Self-Hosted Engine Telepítése Parancssoron Keresztül»

A dokumentumban szerepelnek a hosted-engine VM telepítése előtt teljesítendő előfeltételek, valamint részletesen le van írva maga a telepítési folyamat, ezért célszerű szóról szóra megismételni, így figyeljünk néhány fontos részletre.

• Mielőtt bármilyen műveletet végrehajtanánk, feltétlenül aktiváljuk a virtualizációs támogatást a hoszt BIOS beállításaiban.
• Telepítsük a hosztra a hosted-engine telepítő csomagját:

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

• Az oVirt Hosted Engine telepítési folyamatot a képernyőn indítjuk el (azt Ctrl-A + D kombinációval lehet elhagyni, Ctrl-D-vel bezárni):

screen
hosted-engine --deploy

Szükség esetén előre elkészített válaszfájllal is elindítható a telepítés:

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

• A hosted-engine telepítése során meg kell adnunk az összes szükséges paramétert:

- klaszter neve
- vCPU és vRAM száma (ajánlott 4 vCPU és 16 GB)
- jelszavak
- a hosted engine VM tárolásának típusa – a mi esetünkben FC
- LUN száma a hosted engine telepítéséhez
- hol lesz a hosted engine adatbázisa – egyszerűség kedvéért azt javaslom, hogy válaszd a Local lehetőséget (ez a PostgreSQL adatbázis a VM-en belül működik)
és egyéb paraméterek. 

• A nagy rendelkezésre állású VM hosted engine-nel való telepítéséhez a tárolószinten előre létrehoztunk egy speciális 4-es számú, 150 GB-os LUN-t, amelyet a klaszter hosztjai számára bemutattunk – lásd a előző cikkben.

Korábban azt is ellenőriztük, hogy látható-e a hosztokon:

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

• A hosted-engine telepítési folyamata nem bonyolult, a végén körülbelül az alábbi üzenetet kell kapnunk:

[ 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 sikeresen telepítve

Ellenőrizzük az oVirt szolgáltatások meglétét a hoszton:

Ha minden rendben ment, a telepítés befejezése után az adminisztrátori számítógépről a webböngésző segítségével navigáljunk a https://ovirt_hostname/ovirt-engine és kattintsunk [Administration Portal].

A "Administration Portal" képernyője

A bejelentkezési adatok (a telepítés során megadott) megadásával, a megjelenő ablakban, a képernyőn látható módon beléphetünk az Open Virtualization Manager vezérlőpultjára, ahol mindenféle műveletet végezhetünk a virtuális infrastruktúrával:

1. data center hozzáadása
2. klaszter hozzáadása és konfigurálása
3. hosztok hozzáadása és kezelése
4. tárolási területek vagy Storage Domains hozzáadása a virtuális gépek lemezeihez
5. hálózatok hozzáadása és konfigurálása a virtuális gépek számára
6. virtuális gépek, telepítési képek, VM sablonok hozzáadása és kezelése

Ezeket a műveleteket később részletesebben tárgyaljuk, egyeseket röviden, másokat részletesebben és a finom részletekkel.
De először azt ajánlanám, hogy olvassa el ezt a kiegészítést, amely sokaknak hasznos lehet.

Kiegészítés

1) Alapvetően, ha szükséges, semmi sem akadályozza meg, hogy előre telepítse a KVM hypervisort a klaszter csomópontjaira a csomagok használatával. libvirt és qemu-kvm SysWOW64 qemu-kvm-ev) a kívánt verzió, bár az oVirt klaszter csomópont telepítésekor ezt elvégezheti önállóan is.

De ha libvirt és qemu-kvm nem a legfrissebb verziót telepítették, akkor ilyen hibát kaphatunk a hosted engine telepítése közben:

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

Vagyis szükséges egy frissített verzió libvirt a védelmi politikával, amely támogatja ezt: MDS, amely támogatja ezt a politikát:

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

Telepítsük a libvirt v.4.5.0-10.el7_6.12 verziót md-clear támogatással:

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

Ellenőrizzük a 'md-clear' támogatás meglétét:

virsh domcapabilities kvm | grep require

Ezt követően folytathatjuk a hosted engine telepítését.

2) Az oVirt 4.3 verzióban a tűzfal megléte és használata firewalld kötelező követelmény.

Ha a hosted-engine VM telepítése során ilyen hibát kapunk:

[ 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

Akkor ki kell kapcsolni egy másik tűzfalat (ha használatban van), és telepíteni, valamint elindítani kell 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

A jövőben, amikor az oVirt ügynököt telepítjük egy új gazdagépre a klaszterben, automatikusan beállítja a szükséges portokat. firewalld automatikusan.

3) A gazdagép újraindítása, amelyen a hosted engine VM fut.

Mint mindig, link 1 és link 2 az iránymutató dokumentumokra.

A hosted engine VM teljes vezérlése CSAK a következő parancs segítségével történik: hosted-engine a gazdagépen, ahol fut, a virsh el kell felejteni, ahogyan azt is, hogy ehhez a VM-hez SSH-n keresztül lehet csatlakozni, és rajta a 'leállítás».

A VM karbantartási módba állításának folyamata:

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

hosted-engine --vm-status
!! A klaszter globális karbantartási módban van !!
--== Host host1.test.local (id: 1) állapot ==--
conf_on_shared_storage             : True
Status up-to-date                  : True
Hostname                           : host1.test.local
Host ID                            : 1
Engine status                      : {"health": "jó", "vm": "fel", "detail": "Fent"}
Score                              : 3400
stopped                            : False
Local maintenance                  : False
crc32                              : dee1a774
local_conf_timestamp               : 1821
Host timestamp                     : 1821
Extra metadata (érvényes időpont):
        metadata_parse_version=1
        metadata_feature_version=1
        timestamp=1821 (2019. nov. 29. 14:25:19)
        host-id=1
        score=3400
        vm_conf_refresh_time=1821 (2019. nov. 29. 14:25:19)
        conf_on_shared_storage=True
        maintenance=False
        state=GlobalMaintenance
        stopped=False

hosted-engine --vm-shutdown

Újraindítjuk a hosztot a hosted engine ügynökkel, és megcsináljuk, amire szükségünk van.

Újraindítás után ellenőrizzük a VM státuszát a hosted engine-nel:

hosted-engine --vm-status

Ha a hosted-engine-nel rendelkező VM nem indul el, és hasonló hibákat látunk a szolgáltatás naplójában:

Hiba a szolgáltatás naplójában:

journalctl -u ovirt-ha-agent
...
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine ERRORS Szükséges monitorok indítása nem sikerült
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent ERROR Traceback (legutóbbi hívás):#012  Fájl "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/agent.py", vonal 131, a _run_agent-be#012    visszatér a művelethez(he)#012  Fájl "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/agent.py", vonal 55, a action_proper-ben#012    visszatér he.start_monitoring()-ra#012  Fájl "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/hosted_engine.py", vonal 413, a start_monitoring-ban#012    self._initialize_broker()#012  Fájl "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/hosted_engine.py", vonal 537, a _initialize_broker-ben#012    m.get('options', {}))#012  Fájl "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/lib\/brokerlink.py", vonal 86, a start_monitor-nál#012    ).format(t=type, o=options, e=e)#012RequestError: brokerlink - a monitor indítása meghiúsult az ovirt-ha-broker-en: [Errno 2] Nincs ilyen fájl vagy könyvtár, [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 Az ügynök újraindítása

Csatlakoztatjuk a tárolót, és újraindítjuk az ügynököt:

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

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

A hosted-engine-nel rendelkező VM indítása után kivesszük a karbantartási módból:

A VM karbantartásból való kivételének folyamata:

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) A hosted engine és az ezzel kapcsolatos összes eltávolítása.

Néha szükséges a korábban telepített hosted engine helyes eltávolítása — link a használati dokumentumban.

Egyszerűen futtassuk a parancsot a gazdán:

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

Ezután eltávolítjuk a felesleges csomagokat, mielőtt biztonsági másolatot készítenénk bizonyos konfigurációkról, ha szükséges:

yum autoremove ovirt* qemu* virt* libvirt* libguestfs 

Új adattér létrehozása

Segéddokumentáció — oVirt Adminisztrációs Útmutató. 4. fejezet: Adatközpontok

Először határozzuk meg, hogy mi az adatközpont (idézve a dokumentumból) — egy logikai entitás, amely meghatározza az erőforrások készletét, amelyeket egy specifikus környezetben használnak.

Az adatközpont gyakorlatilag egy konténer, amely a következőkből áll:

• logikai erőforrásokból, mint például cluster-ek és gazdák
• a cluster hálózati erőforrásaiból, mint a logikai hálózatok és a gazdák fizikai adapterei,
• tárolási erőforrásokból (a VM-ek, sablonok, képek lemezeinek) a tárolási területek (Storage Domains) formájában.

Az adatközpont több cluster-t tartalmazhat, amelyek több gazdából állnak, rajtuk futó virtuális gépekkel, a hozzá tartozó tárolási területek is lehetnek.
Több adatközpont létezhet, amelyek függetlenül működnek egymástól. Az oVirt-ben szerepkör alapú hatáskörmegosztás van, és a jogosultságok személyre szabhatók, az adatközpont szintjén és a különböző logikai elemein is.

Az adatközpontot, vagy ha több van, az adatközpontokat egy közönséges adminisztratív konzolon vagy portálon keresztül kezeljük.

Adatközpont létrehozásához lépjünk be az adminisztratív portálra, és hozzunk létre egy új adatközpontot:
Számítás >> Adatközpontok >> Új

Mivel közös tárolót használunk a tároló rendszerben, a tároló típusa (Storage Type) meg kell, hogy legyen Shared:

Képernyőkép az adatközpont létrehozása varázslóról

Virtuális gép telepítésekor a hosted-engine-nel alapértelmezés szerint létrejön egy adatközpont – Datacenter1, és szükség esetén a tárolási típus (Storage Type) módosítható egy másikra.

Az adatközpont létrehozása nem bonyolult feladat, nincsenek különösebb bonyodalmak, és az összes további teendő a dokumentációban található. Egy dolgot azonban megjegyeznék, hogy az olyan egyedi hosztok, amelyek csak helyi tárolóval (lemezzel) rendelkeznek a VM-hez, nem tudnak belépni abba az adatközpontba, amelynek a Storage Type-ja — Shared (nem lehet őket hozzáadni), és számukra külön adatközpontot kell létrehozni – tehát minden egyes helyi tárolóval rendelkező hosztnak szüksége van egy külön adatközpontra.

Új klaszter létrehozása

Dokumentációs hivatkozás — oVirt Adminisztrációs Útmutató. 5. fejezet: Klaszterek

Felesleges részletek nélkül, klaszter – ez a hosztok logikai csoportosítása, amelyek közös tárolóval rendelkeznek (közös lemezként az tárolórendszeren, mint a mi esetünkben). Érdemes, ha a klaszterben lévő hosztok azonos hardverrel rendelkeznek, és azonos típusú processzorral (Intel vagy AMD). A legjobb persze, ha a klaszterben lévő szerverek teljesen azonosak.

A klaszter része az adatközpontnak (egy adott tárolási típussal — Helyi vagy Megosztott), és minden hosztnak kötelezően egy klaszterhez kell tartoznia, attól függően, hogy van-e közös tárolójuk vagy sem.

Virtuális gép telepítésekor a hosted-engine-nel egy hosztra, alapértelmezés szerint létrejön egy adatközpont — Datacenter1, egy klaszterrel együtt – Cluster1, és a továbbiakban beállíthatók annak paraméterei, engedélyezhetők további opciók, hosztok adhatók hozzá stb.

Mint mindig, a klaszter összes beállításának részleteihez érdemes az hivatalos dokumentációhoz fordulni. A klaszter beállításának néhány jellemzőjéből csak annyit szeretnék hozzátenni, hogy létrehozásakor elegendő csak az alapvető paraméterek beállítása a Általános.

Kiemelném a legfontosabb paramétereket:

• Processzor típusa – a klaszter hosztjain telepített processzorok alapján választandó, figyelembe véve a gyártót és a hosztok legöregebb processzorát, hogy ennek megfelelően kihasználhassuk az összes elérhető processzorigénylési instrukciót a klaszterben.
• Switch típusa – a klaszterben csak Linux bridge használatos, ezért azt választjuk.
• Tűzfal típusa – itt minden világos, a firewalld, amelynek be kell kapcsolva és be kell állítva lennie a hosztokon.

Képernyőkép a klaszter paramétereiről

További hosztok telepítése Self-Hosted környezetben

Link a dokumentációra.

A Self-Hosted környezethez tartozó további hosztok hozzáadása úgy történik, mint egy normál hoszt, kiegészítve egy extra lépéssel, amely a VM hosted engine-nel való telepítését tartalmazza — Válassza a hosted engine telepítési akciót >> Kiosztás. Mivel a további hosztnak is prezentálni kell egy LUN-t a VM hosted engine-nel, ez azt jelenti, hogy ezt a hosztot szükség esetén a VM hosted engine-nek a futtatásához is fel lehet használni.
Hibatűrés érdekében erősen ajánlott, hogy minimum két hoszt álljon rendelkezésre, amelyeken VM hosted engine tárolható.

A további hoszton kapcsolja ki az iptables-t (ha be van kapcsolva), és kapcsolja be a firewalld-t

systemctl stop iptables
systemctl disable iptables

systemctl enable firewalld
systemctl start firewalld

Telepítsük az igényelt KVM verziót (szükség szerint):

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

Telepítsük a szükséges tárolókat és a hosted engine telepítőt:

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

Tovább lépünk a konzolba Open Virtualization Manager, hozzáadunk egy új hosztot, és mindent lépésről lépésre végezünk, ahogy le van írva a dokumentáció.

Ennek eredményeként, miután hozzáadjuk a további hosztot, nagyjából olyan képet kell kapnunk az adminisztrációs konzolban, mint a képernyőképen.

Adminisztrációs portál képernyőképe — hosztok

A hoszt, amelyen a VM hosted engine jelenleg aktív, arany koronával és a következő felirattal rendelkezik: "Running the Hosted Engine VM", a hoszt, amelyen ez a VM szükség esetén futtatható — a következő felirattal: "Can run the Hosted Engine VM».

Ha a hoszt, amelyen "Running the Hosted Engine VM", meghibásodik, automatikusan újraindul a második hoszton. Ezen kívül ezt a VM-t is át lehet migrálni az aktív hosztból a tartalékhoz karbantartás céljából.

Power Management / fencing beállítása az oVirt hosztokon

Dokumentációs hivatkozások:

• Red Hat Virtualization 4.3 –> Műszaki referencia -> 4. fejezet. Power Management
• oVirt Adminisztrációs útmutató -> 7. fejezet: Hosztok

Bár úgy tűnhet, hogy a hosztok hozzáadása és beállítása befejeződött, ez nem teljesen így van.
A hosztok normális működéséhez, és bármilyen meghibásodás észleléséhez/elhárításához Power Management / fencing beállítás szükséges.

Fencing, vagy a lemorzsolódás – ez a folyamat a hibás vagy leállt gazdagépek ideiglenes kizárása a klaszterből, amely során vagy az oVirt szolgáltatásokat indítják újra rajta, vagy magát a gazdagépet.

A Power Management / fencing definícióira és paramétereire vonatkozó minden részlet, mint mindig, megtalálható a dokumentációban, itt csak egy példát hozok arra, hogyan állíthatjuk be ezt a fontos paramétert Dell R640 szerverek iDRAC 9 esetében.

1. Belépünk az adminisztrációs portálra, kattintunk Számítás >> Gazdák választunk egy gazdagépet.
2. Kattintunk Szerkesztés.
3. Kattintunk a Power Management.
4. Megjelöljük a jelölőnégyzetet az alábbi opció mellett Enable Power Management.
5. Megjelöljük a jelölőnégyzetet az alábbi opció mellett Kdump integráció, hogy a gazdagép ne kerüljön lemaradó állapotba (fencing), miközben a kernel hibaállomány írása zajlik.

Megjegyzés.

A Kdump integráció engedélyezése után a már működő gazdagépet újra kell telepíteni az oVirt Administration Guide eljárásának megfelelően -> 7. fejezet: Hosztok -> Gazdagépek újratelepítése.

1. Opcionálisan megjelölhetjük a jelölőnégyzetet Disable policy control of power management, ha nem akarjuk, hogy a gazdagép energiaellátását a klaszter ütemezési politikája irányítsa.
2. Megnyomjuk a gombot (+), hogy új energiaellátó eszközt adjunk hozzá, megnyílik az ügynök tulajdonságainak szerkesztő ablaka.
   iDRAC9 esetén kitöltjük a mezőket:
   • Cím – iDRAC9 címe
   • Felhasználónév / Jelszó – a megfelelő bejelentkezési név és jelszó az iDRAC9-hez
   • Típus — drac5
   • a szándékot Biztonságos
   • hozzáadni a következő opciókat: cmd_prompt=>,login_timeout=30

Képernyőkép a gazdagép Power Management paramétereivel

Tárolóterületek létrehozása

Hivatkozás a dokumentációra — oVirt Administration Guide, 8. fejezet: Tárolás.

Tárolási domain, vagy tárolási terület – ez egy központosított hely a virtuális gépek lemezeinek, telepítési képeinek, sablonjainak és pillanatfelvételeinek tárolására.

A tárolási területek különböző protokollok, klaszter- és hálózati fájlrendszerek segítségével csatlakozhatnak az adatközponthoz.

Az oVirt háromféle tárolási területet kínál:

• Data Domain – a virtuális gépekkel (lemezek, sablonok) kapcsolatos összes adat tárolására. A Data Domain nem osztható meg különböző adatközpontok között.
• ISO Domain (elavult tárolási terület típusa) – operációs rendszerek telepítési képeinek tárolására. Az ISO domain megosztható különböző adatközpontok között.
• Export Domain (elavult tárolási terület típusa) – ideiglenes tárolására a képeknek, amelyeket adatközpontok között mozgatnak.

A mi esetünkben a Data Domain típusú tárolási terület Fibre Channel Protocol (FCP) segítségével csatlakozik a LUN-okhoz az SAN-on.

Az oVirt szempontjából, amikor tárolóeszközöket (FC vagy iSCSI) használ, minden virtuális lemez, pillanatkép vagy sablon logikai lemeznek számít.
A blokkos eszközök egy egészbe gyűjtve (a cluster hosztjain) a Volumen Csoport segítségével, majd az LVM segítségével logikai kötetekre osztják, amelyek virtuális lemezként használhatók a VM-ek számára.

Mindezek a csoportok és az LVM kötetek a cluster hosztján megtekinthetők a következő parancsok segítségével vgs és lvs. Természetesen az ilyen lemezekkel végzett összes műveletet csak az oVirt konzoljából szabad végezni, kivéve néhány különleges esetet.

A VM-ek számára készült virtuális lemezek két típusúak lehetnek — QCOW2 vagy RAW. A lemezek lehetnek "vékony" vagy "vastag". A pillanatképek mindig "vékony".

" formában készülnek. A Storage domain-ek vagy tárolóterületek kezelése, amelyek elérhetők FC-n keresztül, meglehetősen logikus — minden virtuális lemez számára külön logikai kötet létezik, amely csak egy hoszt számára elérhető írásra. FC kapcsolatok esetén az oVirt valami hasonlót használ, mint a klaszteres LVM.

Az egy tárolóterületen lévő virtuális gépeket át lehet vinni a clusterhez tartozó hosztok között.

Ahogy a leírásból látható, az oVirt-ben a cluster, akárcsak a VMware vSphere-ben vagy a Hyper-V-ben, lényegében ugyanazt jelenti – ez egy logikai csoportosítása a hosztoknak, amely ideális esetben azonos 'hardver' összeállítású, és közös tárolással bír a virtuális gépek lemezei számára.

Lépjünk át közvetlenül az adattároló, azaz a VM-ek lemezeinek létrehozására, mivel nélküle az adatközpont nem lesz inicializálva.
Emlékeztetem, hogy minden cluster hosztjai számára bemutatott LUN-oknak a tárolóeszközön láthatónak kell lenniük az "multipath -ll».

A következő szerint dokumentáció", belépünk a portálba, belépünk itt Tárolás >> Domainek -> Új Domain és követjük az "FCP Storage" hozzáadásának útmutatóját.

A varázsló elindítása után kitöltjük a szükséges mezőket:

• Név — megadjuk a cluster nevét
• Domain Funkció — Adat
• Tárolási Típus — Fibre Channel
• Használni kívánt Hoszt — kiválasztjuk a hosztot, amelyen a szükséges LUN elérhető

A LUN-ok listájában kiválasztjuk a keresett LUN-t, rákattintunk Ezután adja meg az Amazon S3-hoz való hozzáféréshez szükséges fiókot — válassza ki a meglévőt a listából, vagy kattintson majd a következőt: OK. Szükség esetén az tárolóterület további paramétereit módosíthatjuk a Haladó Paraméterek.

képernyőképét az 'Storage domain' hozzáadásához

A varázsló munkájának eredményeként új tárolóterületet kell kapnunk, és az adatközpontunknak át kell kerülnie a UP, vagy inicializált státuszba:

Az adatközpont és a tárolóterületek képei benne:

Hálózatok létrehozása és konfigurálása virtuális gépekhez

Hivatkozás a dokumentációra — oVirt Administration Guide, 6. fejezet: Logikai Hálózatok

A hálózatok, vagyis a rendszerek célja, hogy csoportosítsák a virtuális infrastruktúrában használt logikai hálózatokat oVirt-ben.

A virtuális gép hálózati adapterének és a gazdagép fizikai adapterének interakciójához Linux bridge típusú logikai interfészeket használnak.

A forgalom csoportosításához és elválasztásához VLAN-ok vannak beállítva a switch-eken.

Amikor logikai hálózatot hozunk létre virtuális gépek számára oVirt-ben, mindenképpen meg kell adni egy azonosítót, amely megfelel a switch-en lévő VLAN számnak, hogy a virtuális gépek interakcióba léphessenek egymással, még akkor is, ha különböző klasztercsomópontokon futnak.

A virtuális gépek csatlakoztatásához szükséges alapvető beállításokat a gazdagépen a következő helyen kellett elvégezni: előző cikkben – beállítva a logikai interfész bond1, ezután minden hálózati beállítást csak az oVirt adminisztrációs portálján keresztül szabad elvégezni.

A hosted-engine-nel rendelkező virtuális gép létrehozásakor, a datacenter és a klaszter automatikus létrehozása mellett, automatikusan létrejött a logikai hálózat is az klaszterünk kezelésére – ovritmgmt, amelyhez ez a virtuális gép is csatlakozott.

Szükség esetén megtekinthetjük a logikai hálózat beállításait ovritmgmt és módosíthatjuk őket, de óvatosnak kell lennünk, hogy ne veszítsük el az oVirt infrastruktúra kezelését.

Az ovritmgmt logikai hálózat beállításai

Új logikai hálózat létrehozásához a szokásos virtuális gépek számára az adminisztrációs portálon a következő címre navigálunk: Hálózat >> Hálózatok >> Új, és a Általános fülre kattintvahozzáadunk egy hálózatot a szükséges VLAN azonosítóval, és kipipáljuk a „VM Network

” jelölőnégyzetet, ami azt jelenti, hogy ezt a virtuális gépekre lehet alkalmazni.

A KlaszterA új logikai hálózat VLAN32 képernyőképe Cluster1.

, csatlakoztatjuk ezt a hálózatot klaszterünkhöz. Számítás >> GazdákEzután a következő címre navigálunk: , sorban belépünk minden gazdagépbe, aHálózati interfészek fülre kattintunk, és elindítjuk a varázslót

Hálózatok beállítása gazdagépen

, hogy a gazdagépekhez hozzárendeljük az új logikai hálózatot.

Példa konfigurációs fájlokra az új hálózatokhoz a gazdagépen:

cat ifcfg-bond1
# Generálta a VDSM 4.30.17.1 verzió
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
# Generálta a VDSM 4.30.17.1 verzió
DEVICE=bond1.432
VLAN=yes
BRIDGE=ovirtvm-vlan432
ONBOOT=yes
MTU=1500
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=no

cat ifcfg-ovirtvm-vlan432
# Generálta a VDSM 4.30.17.1 verzió
DEVICE=ovirtvm-vlan432
TYPE=Bridge
DELAY=0
STP=off
ONBOOT=yes
MTU=1500
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=no

Még egyszer emlékeztetem, hogy a cluster gazdagépen NEM SZABAD előre létrehozni a hálózati interfészeket ifcfg-bond1.432 és ifcfg-ovirtvm-vlan432.

A logikai hálózat hozzáadása és a kapcsolat ellenőrzése után a gazdagép és a VM között, azt használni lehet a virtuális gépben.

Telepítési kép létrehozása virtuális gép telepítéséhez

Hivatkozás a dokumentációra — oVirt Administration Guide, 8. fejezet: Tárolás, az "Képek feltöltése egy adattároló domainbe" résznél.

Telepítési ISO image nélkül nem lehet virtuális gépet telepíteni, bár ez nem jelent problémát, ha a hálózaton például Cobbler előre létrehozott képek találhatóak.

A mi esetünkben ilyen lehetőség nincs, ezért ezt a képet manuálisan kell importálni az oVirt-be. Korábban ehhez ISO Domain-t kellett létrehozni, azonban az új oVirt verzióban ezt elavultnak minősítették, így most közvetlenül a tároló domainbe is feltölthetők a képek az adminisztrációs portálból.

Az adminisztrációs portálban menjünk a Tárolás >> Disks >> Upload >> osztályának
Hozzáadjuk az OS képünket ISO fájlként, kitöltjük az összes mezőt, majd rákattintunk a "Kapcsolat tesztelése".

A telepítési kép hozzáadásának varázslója képernyőkép

Ha a következő hibaüzenetet kapjuk:

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

Akkor hozzá kell adni az oVirt tanúsítványt a „Megbízható gyökér CA-k» (Trusted Root CA) a vezérlőállomáson, ahonnan megpróbáljuk feltölteni a képet.

Miután hozzáadtuk a tanúsítványt a Megbízható gyökér CA-hoz, ismét rákattintunk a "Kapcsolat tesztelése", a következőt kell kapnunk:

A kapcsolat az ovirt-imageio-proxy-hoz sikeres volt.

A tanúsítvány hozzáadásának végrehajtása után megpróbálhatjuk ismét feltölteni az ISO képet a Storage Domainbe.

Elvileg létrehozhatunk egy külön Storage Domain-t Data típusúként, hogy a képeket és sablonokat külön tároljuk a VM lemezeitől, vagy akár azokat a tároló domainbe is helyezhetjük, ahol a hosted engine található, de ez már az adminisztrátor döntése.

Képernyőkép ISO képekkel a Storage Domainben a hosted engine számára

Virtuális gép létrehozása

Hivatkozás a dokumentációra:
oVirt Virtuális Gép Kezelési Útmutató –> 2. fejezet: Linux virtuális gépek telepítése
Konzol kliens erőforrások

Az OS telepítő képének oVirt-be való feltöltése után közvetlenül a virtuális gép létrehozására léphetünk. Sok munka áll mögöttünk, de már a befejező szakaszban vagyunk, amiért az egész elkezdődött – a magas rendelkezésre állású virtuális gépekhez szükséges megbízható infrastruktúra kialakítása. És mindezt teljesen ingyen – egy centet sem költöttünk szoftverlicencek vásárlására.

A CentOS 7 virtuális gép létrehozásához telepítő képet kell betölteni az operációs rendszerről.

Belépünk az adminisztrációs portálra, és átmegyünk a Számítás >> Virtual Machines, és elindítjuk a virtuális gép létrehozó varázslót. Kitöltjük az összes paramétert és mezőt, majd rákattintunk a OK. Minden nagyon egyszerű, ha követjük a dokumentációt.

Példaként bemutatom a magas rendelkezésre állású virtuális gép alapvető és további beállításait, létrehozott lemezzel, hálózatra csatlakoztatva, és telepítő képről bootolva:

A magas rendelkezésre állású virtuális gép beállításainak képernyőképei

A varázsló befejezése után bezárjuk, elindítjuk az új virtuális gépet, és telepítjük rá az operációs rendszert.
Ehhez belépünk a virtuális gép konzoljába az adminisztrációs portálon keresztül:

Screenshot az adminisztrációs portál beállításairól a virtuális gép konzoljához való csatlakozáshoz

A virtuális gép konzoljához való csatlakozáshoz először be kell állítani a konzolt a virtuális gép tulajdonságaiban.

Screenshot a virtuális gép beállításairól, a 'Console' fül alatt

A virtuális gép konzol eléréséhez például használhatja a Virtual Machine Viewer.

Ahhoz, hogy közvetlenül a böngészőablakban csatlakozhasson a virtuális gép konzoljához, a csatlakozási beállításoknak a következőképpen kell kinézniük:

Az operációs rendszer telepítése után a virtuális gépre ajánlott telepíteni az oVirt vendég ügynököt:

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

Így a végrehajtott lépések eredményeként a létrehozott virtuális gép magas rendelkezésre állású lesz, azaz ha a klaszterben lévő csomópont, ahol fut, leáll, az oVirt automatikusan újraindítja azt egy második csomóponton. Ezt a virtuális gépet a klaszter hosztjai között is áthelyezheti karbantartás céljából, vagy más okok miatt.

Zárás

Remélem, hogy ezzel a cikkel sikerült megmutatnom, hogy az oVirt egy teljesen normális eszköz a virtuális infrastruktúra kezelésére, amelyet nem olyan nehéz kiépíteni – csak követni kell a cikkben és a dokumentációban leírt bizonyos szabályokat és követelményeket.

A cikk terjedelme miatt sok dolgot nem tudtunk belefoglalni, például a különböző mesterséges lépések részletes végrehajtását, magyarázatokkal és képernyőképekkel, hosszú parancskiadások kimeneteit stb. Valójában ehhez egy egész könyvet kellett volna írni, ami nem igazán lenne értelme, mivel folyamatosan új verziók jelennek meg a szoftverekből, újdonságokkal és változásokkal. A legfontosabb, hogy megértsük a működés elvét, és egy általános cselekvési algoritmust kapjunk a virtuális gépek kezelésére szolgáló megbízható platform létrehozásához.

Bár létrehoztuk a virtuális infrastruktúrát, most meg kell tanítani, hogy hogyan működjön együtt a saját elemei között: gazdagépek, virtuális gépek, belső hálózatok, valamint a külső világgal.

Ez a folyamat a rendszergazda vagy hálózati adminisztrátor egyik alapvető feladata, amelyet a következő cikkben tárgyalunk — a VyOS virtuális routerek használatáról a vállalatunk megbízható infrastruktúrájában (ahogy kitalálta, ezek virtuális gépek formájában fognak működni az oVirt klaszterünkben).

Forrás: habr.com