Tento článek je pokračováním předchozího – „».
V něm bude popsán proces základní instalace a konfigurace clustru oVirt 4.3 pro hosting vysoce dostupných virtuálních strojů, s ohledem na to, že všechny předchozí kroky na přípravu infrastruktury byly již dříve provedeny.
Úvodní část
Hlavním cílem článku není toliko poskytnout podrobný návod ve stylu „Další -> Ano -> Dokončit“, ale spíše ukázat některé zvláštnosti při jeho instalaci a konfiguraci. Proces nasazení vašeho clustru se nemusí vždy shodovat s tím, co je popsáno v článku, kvůli zvláštnostem infrastruktury a prostředí, ale obecné principy budou stejné.
Z subjektivního hlediska, má z hlediska funkcionality podobnost s VMware vSphere verze 5.x, ale samozřejmě s vlastními zvláštnostmi konfigurace a fungování.
Pro zájemce jsou všechny rozdíly mezi RHEV (aka oVirt) a VMware vSphere k nalezení na internetu, například , ale přesto budu občas uvádět jejich některé rozdíly nebo podobnosti mezi sebou během článku.
Rád bych také trochu porovnal práci se sítěmi pro virtuální stroje. V oVirt je realizován podobný princip správy sítí pro virtuální stroje (dále VM), jako v VMware vSphere:
- pomocí standardního Linux bridge (ve VMware — Standard vSwitch), pracujícího na hostitelích virtualizace;
- pomocí Open vSwitch (OVS) (ve VMware — Distributed vSwitch) – to je distribuovaný virtuální switch, skládající se ze dvou základních komponent: centrálního serveru OVN a kontrolerů OVN na spravovaných hostitelích.
Je třeba poznamenat, že z důvodu jednoduchosti realizace bude v článku popsána konfigurace sítí v oVirt pro VM pomocí standardního Linux bridge, což je standardní volba při použití hypervisoru KVM.
S tímto souvisejí některá základní pravidla pro práci se sítí v clustru, která by se neměla porušovat:
- Všechny síťové nastavení na hostitelích před jejich přidáním do oVirt musí být identické, kromě IP adres.
- Jakmile je hostitel spravován pomocí oVirt, je velmi doporučeno nic ručně neměnit v síťových nastaveních, pokud si nejsme jisti svými kroky, protože agent oVirt je po restartu hostitele nebo agenta jednoduše vrátí na předchozí nastavení.
- Přidání nové sítě pro VM, jakož i její správa, by mělo být prováděno pouze z ovládací konzole oVirt.
Ještě jedno důležité upozornění — pro velmi kritické prostředí (velmi citlivé na finanční ztráty) by se přesto doporučilo využít placené podpory a používat . Při provozu clustera oVirt se mohou objevit některé situace, kdy by bylo žádoucí co nejdříve získat kvalifikovanou pomoc, místo toho, abychom se s nimi snažili vypořádat sami.
A nakonec, se doporučuje před nasazením clustera oVirt se seznámit s , abychom byli alespoň v obraze s základními pojmy a definicemi, jinak bude obtížné dál číst tento článek.
Základními pro pochopení článku a principů fungování clustera oVirt jsou tyto průvodní dokumenty:
Objem tam není příliš velký, za hodinu dvě je možné zvládnout základní principy, a pro milovníky podrobností se doporučuje přečíst — RHEV a oVirt jsou v podstatě to samé.
Takže, pokud jsou všechna základní nastavení na hostitele, switchích a úložištích provedena, přecházíme přímo k nasazení oVirt.
Část 2. Instalace a nastavení clustera oVirt 4.3
Pro snadnou orientaci uvádím v seznamu hlavní části v tomto článku, které by se měly provádět po sobě jdoucím způsobem:
- Instalace řídícího serveru oVirt
- Vytvoření nového datového centra
- Vytvoření nového clustera
- Instalace dalších hostitelů do Self-Hosted prostředí
- Vytvoření úložné oblasti nebo Storage Domains
- Vytvoření a nastavení sítí pro virtuální stroje
- Vytvoření instalačního obrazu pro nasazení virtuálního stroje
- Vytvoření virtuálního stroje
Instalace řídícího serveru oVirt
Řídící server oVirt – je nejdůležitější prvek v infrastruktuře oVirt, ve formě virtuálního stroje, hostitele nebo virtuálního zařízení, které spravuje celou infrastrukturu oVirt.
Jeho blízké analogy ze světa virtualizace:
- VMware vSphere — vCenter Server
- Microsoft Hyper-V — System Center Virtual Machine Manager (VMM).
Pro instalaci řídicího serveru oVirt máme dvě možnosti:
Možnost 1
Nasazení serveru jako specializovaného VM nebo hostitele.
Tato možnost funguje, ale za podmínky, že takové VM funguje nezávisle na clusteru, tj. není spuštěna na žádném hostiteli clusteru jako běžná virtuální stroj pod KVM.
Proč nelze nasazovat takové VM na hostitele clusteru?
Na začátku procesu nasazení řídicího serveru oVirt máme dilema — řídicí VM je nutné mít, ale cluster vlastně ještě neexistuje, a proto co můžeme udělat hned? Správně – nainstalovat KVM na budoucím uzlu clusteru, poté na něm vytvořit virtuální stroj, například s OS CentOS, a v něm nasadit oVirt engine. To se obvykle dělá z důvodů úplné kontroly nad takovým VM, ale to je chybné zamýšlení, protože v takovém případě budou později zcela jistě problémy s takovým řídicím VM:
- nebude možné migrovat ji v konzoli oVirt mezi hostiteli (uzly) clusteru;
- při migraci pomocí KVM přes virsh migrate, toto VM nebude dostupné k řízení z konzole oVirt.
- Hostitele clusteru nebude možné uvést do Maintenance mode (režim údržby), pokud migrujete toto VM z hostitele na hostitele pomocí virsh migrate.
Takže dělejte vše podle pravidel — pro řídicí server oVirt používejte buď samostatný hostitel, nebo nezávislé VM spuštěné na něm, nebo ještě lépe postupujte, jak je napsáno ve druhé možnosti.
Možnost 2
Instalace oVirt Engine Appliance na hostitele clusteru, který řídí.
Právě tato možnost bude dále probrána jako správnější a vhodnější v našem případě.
Požadavky na takové VM jsou popsány níže, dodávám jen, že se doporučuje mít alespoň dva hostitele v infrastruktuře, na kterých může být spuštěno řídicí VM, aby bylo redundantní. Zde bych chtěl dodat, že jak jsem již psal v komentářích v předchozím článku, podařilo se mi nezískat splitbrain na clusteru oVirt ze dvou hostitelů, s možností spuštění hosted-engine VM na nich.
Instalace oVirt Engine Appliance na první hostitele clusteru
Odkaz na oficiální dokumentaci — , kapitola „»
V dokumentu jsou uvedeny předběžné podmínky, které musí být splněny před nasazením hosted-engine VM, a podrobně je popsán samotný proces její instalace, takže není zvlášť smysluplné opakovat ho doslovně, proto se zaměříme na některé důležité detaily.
- Před zahájením všech akcí je nutné povolit podporu virtualizace v nastavení BIOSu na hostiteli.
- Na hostitelském systému nainstalujeme balíček pro instalátor 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- Spustíme na hostiteli proceduru nasazení oVirt Hosted Engine v screen’u (opustit jej lze pomocí Ctrl-A + D, zavřít pomocí Ctrl-D):
screen
hosted-engine --deployPokud si přejete, můžete spustit instalaci s předem připraveným odpovědním souborem:
hosted-engine --deploy --config-append=/var/lib/ovirt-hosted-engine-setup/answers/answers-ohe.conf- Během nasazení hosted-engine uvedeme všechny potřebné parametry:
- název clusteru
- počet vCPU a vRAM (doporučuje se 4 vCPU a 16 GB)
- hesla
- typ úložiště pro hosted engine VM – v našem případě FC
- číslo LUN pro instalaci hosted engine
- kde bude umístěna databáze pro hosted engine – doporučuji pro jednoduchost zvolit Local (to je databáze PostgreSQL běžící uvnitř této VM)
a další parametry. - Pro instalaci vysoce dostupné VM s hosted engine byl na úložišti vytvořen speciální LUN s číslem 4 a velikostí 150 GB, který byl následně představen hostitelům clusteru – viz v .
Dříve jsme také kontrolovali jeho viditelnost na hostitelích:
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- Samotný proces nasazení hosted-engine nenese nic složitého, na jehož konci bychom měli obdržet přibližně takovou zprávu:
[ 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 deployedKontrolujeme přítomnost služeb oVirt na hostiteli:
Pokud bylo vše provedeno správně, po dokončení instalace se pomocí webového prohlížeče přihlásíme na z počítače administrátora a klikneme na [Administrace Portál].
Screenshot „Administrace Portál“
Zadáním přihlašovacích údajů (uživatelské jméno a heslo zadané během instalace) do okna jako na screenshotu se dostaneme do ovládacího panelu Open Virtualization Manager, kde lze provádět všechny operace s virtuální infrastrukturou:
- přidávat datová centra
- přidávat a konfigurovat klastr
- přidávat a spravovat hostitele
- přidávat úložné oblasti nebo Storage Domains pro disky virtuálních strojů
- přidávat a konfigurovat sítě pro virtuální stroje
- přidávat virtuální stroje, instalační obrazy, šablony VM a spravovat je
Všechny tyto činnosti budou popsány dále, některé v hrubých rysech, jiné podrobněji s nuancemi.
Ale nejprve bych doporučil přečíst si toto doplnění, které se určitě mnohým bude hodit.
Doplnění
1) V zásadě, pokud je potřeba, nic nebrání tomu, abyste předem nainstalovali hypervizor KVM na uzly klastru pomocí balíčků libvirt a qemu-kvm (nebo qemu-kvm-ev) požadované verze, i když při nasazení uzlu klastru oVirt to může udělat i sám.
Ale pokud libvirt a qemu-kvm byly nainstalovány ne nejnovější verze, může se při nasazení hosted engine objevit tato chyba:
error: unsupported configuration: unknown CPU feature: md-clearTo znamená, že je nutné mít libvirt s ochranou proti , která podporuje tuto politiku:
<feature policy='require' name='md-clear'/>Nainstalujeme libvirt v.4.5.0-10.el7_6.12, s podporou 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 libvirtdZkontrolujeme podporu 'md-clear':
virsh domcapabilities kvm | grep requirePo tomto kroku lze pokračovat v instalaci hosted engine.
2) V oVirt 4.3 je přítomnost a použití firewallu firewalld povinným požadavkem.
Pokud během nasazení VM pro hosted-engine dostaneme tuto chybu:
[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "firewalld musí být povolen a aktivní, aby mohl být správně nasazen hosted-engine. Zkontrolujte, opravte to a znovu nasadťe.n"}
[ ERROR ] Selhalo provedení fáze 'Uzavření': Selhalo provedení ansible-playbook
[https://bugzilla.redhat.com/show_bug.cgi?id=1608467Je nutné vypnout jiný firewall (pokud je používán) a nainstalovat a spustit 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-zonesPři instalaci agenta ovirt na novém hostu pro klastr se automaticky nastaví potřebné porty firewalld automaticky.
3) Restartování hosta s běžícím VM s hosted engine.
Jak obvykle, a na dokumentaci.
Celá správa hosted engine VM se provádí POUZE pomocí příkazu hosted-engine na hostu, kde běží, ohledně virsh se musí zapomenout, stejně jako na to, že se k tomuto VM lze připojit přes SSH a spustit na něm příkaz „shutdown».
Postup pro uvedení VM do režimu údržby:
hosted-engine --set-maintenance --mode=global
hosted-engine --vm-status
!! Klastr je v režimu ÚDRŽBY GLOBAL !!
--== Host host1.test.local (id: 1) status ==--
conf_on_shared_storage : True
Status aktuální : True
Hostname : host1.test.local
Host ID : 1
Stav engine : {"health": "good", "vm": "up", "detail": "Up"}
Skóre : 3400
stopped : False
Místní údržba : False
crc32 : dee1a774
časová značka místní konfigurace : 1821
časová značka hostitele : 1821
Další metadata (platná v časové značce):
metadata_parse_version=1
metadata_feature_version=1
timestamp=1821 (So 29. listopadu 2019 14:25:19)
host-id=1
skóre=3400
vm_conf_refresh_time=1821 (So 29. listopadu 2019 14:25:19)
conf_on_shared_storage=True
údržba=False
stav=GlobalMaintenance
stopped=False
hosted-engine --vm-shutdownRestartujeme host s hosted engine agentem a děláme s ním, co potřebujeme.
Po restartování zkontrolujeme stav VM s hosted engine:
hosted-engine --vm-statusPokud se naše VM s hosted-engine nespouští a pokud vidíme podobné chyby v logu služby:
Chyba v logu služby:
journalctl -u ovirt-ha-agent
...
29. června 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine CHYBA Nepodařilo se spustit potřebné monitory
29. června 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent CHYBA Sledování (poslední volání naposledy):#012 Soubor "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", řádek 131, v _run_agent#012 return action(he)#012 Soubor "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", řádek 55, v action_proper#012 return he.start_monitoring()#012 Soubor "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py", řádek 413, v start_monitoring#012 self._initialize_broker()#012 Soubor "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py", řádek 537, v _initialize_broker#012 m.get('options', {}))#012 Soubor "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py", řádek 86, v start_monitor#012 ).format(t=type, o=options, e=e)#012Chyba požadavku: brokerlink - nepodařilo se spustit monitor přes ovirt-ha-broker: [Errno 2] Žádný takový soubor nebo adresář, [monitor: 'ping', options: {'addr': '172.20.32.32'}]
29. června 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent CHYBA Pokus o restart agentaPřipojíme úložiště a restartujeme agenta:
hosted-engine --connect-storage
systemctl restart ovirt-ha-agent
systemctl status ovirt-ha-agent
hosted-engine --vm-start
hosted-engine --vm-statusPo spuštění VМ s hosted-engine ji vyjmeme z režimu údržby:
Postup k vyjmutí VМ z režimu údržby:
hosted-engine --check-liveliness
hosted-engine --set-maintenance --mode=none
hosted-engine --vm-status
--== Host host1.test.local (id: 1) stav ==--
conf_on_shared_storage : True
Stav aktuální : True
Hostname : host1.test.local
ID hostitele : 1
Stav motoru : {"health": "good", "vm": "up", "detail": "Up"}
Skóre : 3400
stopped : False
Místní údržba : False
crc32 : 6d1eb25f
časová značka místní konfigurace : 6222296
časová značka hostitele : 6222296
Extra metadata (platné k časové značce):
metadata_parse_version=1
metadata_feature_version=1
časová značka=6222296 (Pá 17. led 11:40:43 2020)
host-id=1
skóre=3400
vm_conf_refresh_time=6222296 (Pá 17. led 11:40:43 2020)
conf_on_shared_storage=True
údržba=False
stav=EngineUp
stopped=False4) Odstranění hosted engine a veškerého s ní spojeného.
Někdy je nutné správně odstranit dříve nainstalovaný hosted engine — na referenční dokument.
Jednoduše provedeme příkaz na hostiteli:
/usr/sbin/ovirt-hosted-engine-cleanupNásledně odstraníme nepotřebné balíčky, přičemž pokud je to nutné, zálohujeme některé konfigurace:
yum autoremove ovirt* qemu* virt* libvirt* libguestfs Vytvoření nového datového centra
Referenční dokumentace — oVirt Administration Guide.
Nejprve definujeme, co je datové centrum (cituji z dokumentace) — to je logická entita, která určuje soubor zdrojů používaných v specifickém prostředí.
Datové centrum je jakýsi kontejner složený z:
- logických zdrojů ve formě klastrů a hostitelů
- síťových zdrojů clusteru ve formě logických sítí a fyzických adaptérů na hostitelích,
- úložných zdrojů (pro disky VM, šablony, obrazy) ve formě úložných oblastí (Storage Domains).
Datacenter může zahrnovat několik clusterů, skládajících se z několika hostitelů s virtuálními stroji, které na nich běží, může mít také několik úložných oblastí s ním asociovaných.
Datacenter může být několik, fungují nezávisle na sobě. V ovirt existuje rozdělení pravomocí podle rolí a lze nastavit oprávnění individuálně, jak na úrovni datacentra, tak na jeho jednotlivé logické prvky.
Datacentrum, nebo datacentra, pokud jich je několik, jsou spravována z jediné administrativní konzoly nebo portálu.
Chcete-li vytvořit datacentrum, vstupte do administrativního portálu a vytvořte nové datacentrum:
Výpočetní >> Datacentra >> Nové
Jelikož používáme sdílené úložiště na SCSI, měla by být asociace úložiště (Storage Type) nastavena jako Shared:
Screenshot s průvodcem vytvoření datacentra
Při instalaci virtuálního stroje s hosted-engine se standardně vytváří datacentrum – Datacenter1, a poté je možné jeho typ úložiště (Storage Type) případně změnit na jiný.
Vytvoření datacentra je snadný úkol, bez nějakých složitých nuancí, a všechny další akce s ním jsou popsány v dokumentaci. Jen bych poznamenal, že jednotlivé hostitele, kteří mají pouze místní úložiště (disk) pro VM, nemohou být přidány do datacentra se Storage Type – Shared, a pro ně je třeba vytvořit samostatné datacentrum – tj. každému jednotlivému hostiteli s místním úložištěm je potřeba vytvořit své vlastní samostatné datacentrum.
Vytvoření nového clustera
Odkaz na dokumentaci – oVirt Administration Guide.
Bez zbytečných podrobností, cluster – je logická skupina hostitelů, kteří mají společnou úložnou oblast (ve formě sdílených disků na SCSI, jako v našem případě). Také je žádoucí, aby hostitelé v clusteru byli identičtí z hlediska hardwaru a měli stejný typ procesoru (Intel nebo AMD). Nejlepší je, aby servery v clusterech byly zcela identické.
Cluster je součástí datacentra (s určitým typem úložiště – Místní nebo Sdílené), a všichni hostitelé musí bezpodmínečně patřit do nějakého clusteru, v závislosti na tom, zda mají společné úložiště nebo ne.
Při instalaci virtuálního stroje s hosted-engine na hosta se automaticky vytvoří datové centrum — Datacenter1, spolu s clusterem – Cluster1, a dále je možné nastavit jeho parametry, aktivovat další možnosti, přidat do něj hosty atd.
Jak je obvyklé, pro podrobnosti o všech nastaveních clustera je dobré obrátit se na oficiální dokumentaci. Z některých specifik nastavení clustera bych dodal, že při jeho vytváření je nutné nastavit pouze základní parametry na záložce Obecné.
Poznamenám si nejdůležitější parametry:
- Typ procesoru — vybírá se na základě toho, jaké procesory jsou nainstalovány na hostitelích clustera, od jakého výrobce jsou, a jaký procesor je na hostitelích nejstarší, aby na základě toho bylo možné využít všechny dostupné instrukce procesoru v clusteru.
- Typ přepínače – v našem clusteru používáme pouze Linux bridge, a proto jej vybíráme.
- Typ firewallu – zde je to jasné, to je firewalld, který by měl být povolen a nastaven na hostitelích.
Screenshot s parametry clustera
Instalace dalších hostitelů v prostředí Self-Hosted
na dokumentaci.
Další hostitelé pro Self-Hosted prostředí se přidávají stejně jako běžný hostitel, s vykonáním dalšího bodu pro nasazení VM s hosted engine — Vyberte akci nasazení hosted engine >> Nasadit. Vzhledem k tomu, že dalšímu hostiteli by měl být také předložen LUN pro VM s hosted engine, to znamená, že tento hostitel může být v případě potřeby použit k umístění VM s hosted engine.
Z hlediska odolnosti proti chybám se velmi doporučuje mít alespoň dva hostitele, na kterých může být umístěna VM s hosted engine.
Na dalším hostiteli vypneme iptables (pokud je zapnuté), zapneme firewalld
systemctl stop iptables
systemctl disable iptables
systemctl enable firewalld
systemctl start firewalldNainstalujeme požadovanou verzi KVM (pokud je to nutné):
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-clearNainstalujeme potřebné repozitáře a instalátor hosted engine:
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-setupDále přecházíme do konzole Open Virtualization Manager, přidáváme nový host a postupujeme krok za krokem, jak je uvedeno v .
Výsledkem bude, že po přidání dalšího hostitele bychom měli získat přibližně takový obraz v administrativní konzoli, jako na screenshotu.
Screenshot administrativního portálu — hostitelé
Hostitel, na kterém je momentálně aktivní VM s hosted-engine, má zlatou korunu a nápis „Running the Hosted Engine VM“, hostitel, na kterém může být tato VM spuštěna v případě potřeby – nápis „Can run the Hosted Engine VM».
V případě selhání hostitele, na kterém „Running the Hosted Engine VM“, se automaticky restartuje na druhém hostiteli. Tuto VM lze také migrovat z aktivního hostitele na záložní k údržbě.
Nastavení správy napájení / fencing na hostitelích oVirt
Odkazy na dokumentaci:
- Red Hat Virtualization 4.3 –> Technická reference ->
- oVirt Administrativní příručka ->
I když se může zdát, že přidání a nastavení hostitele bylo dokončeno, není to úplně pravda.
Pro normální funkci hostitelů a identifikaci/odstranění selhání některého z nich je nezbytné nastavení správy napájení/fencing.
Fencing, nebo ohraničení – je proces dočasného vyloučení nefunkčního nebo selhávajícího hostitele z clusteru, během kterého se restartují buď služby oVirt na něm, nebo sám hostitel.
Všechny podrobnosti týkající se definic a parametrů správy napájení/fencing jsou jako obvykle uvedeny v dokumentaci, jen uvedu příklad, jak nastavit tento důležitý parametr, pro servery Dell R640 s iDRAC 9.
- Přejdeme do administrativního portálu, klikneme na Výpočetní >> Hosts vybereme hostitele.
- Klikneme na Edit.
- Klikneme na záložku Power Management.
- Zaškrtneme políčko vedle možnosti Enable Power Management.
- Zaškrtneme políčko vedle možnosti Integrace Kdump, aby hostitel nepřešel do režimu ohraničení (fencing) během zapisování nouzového jádra.
Poznámka.
Po aktivaci integrace Kdump na již běžícím hostiteli musí být přeinstalován podle postupu v oVirt Administrativní příručce -> -> Přeinstalace hostitelů.
- Volitelně můžeme zaškrtnout políčko Disable policy control of power management, pokud nechceme, aby správa napájení hostitele byla kontrolována politikou plánování (Scheduling Policy) clusteru.
- Klikneme na tlačítko (+), abychom přidali nové zařízení pro správu napájení, otevře se okno pro úpravy vlastností agenta.
Pro iDRAC9 vyplníme pole:- Address – adresa iDRAC9
- User Name / Password – příslušně přihlašovací jméno a heslo pro vstup do iDRAC9
- Type — drac5
- zaškrtnout Secure
- přidat následující možnosti: cmd_prompt=>,login_timeout=30
Screenshot s parametry „Power Management“ ve vlastnostech hostitele
Vytvoření úložné oblasti nebo Storage Domains
Odkaz na dokumentaci – oVirt Administration Guide, .
Úložná doména, nebo úložná oblast – to je centralizované místo pro ukládání disků virtuálních strojů, instalačních obrazů, šablon a snapshotů.
Úložné oblasti se mohou připojovat k datovému centru pomocí různých protokolů, clusterových a síťových souborových systémů.
oVirt má tři typy úložných oblastí:
- Data Domain – pro ukládání všech dat souvisejících s virtuálními stroji (disky, šablony). Data Domain nemůže být sdílena mezi různými datovými centry.
- ISO Domain (zastaralý typ úložiště) – pro uchovávání instalačních obrazů OS. ISO Domain může být sdílena mezi různými datovými centry.
- Export Domain (zastaralý typ úložiště) – pro dočasné ukládání obrazů, které jsou přesouvány mezi datovými centry.
V našem konkrétním případě úložná oblast typu Data Domain používá Fibre Channel Protocol (FCP) pro připojení k LUNům na SAN.
Z pohledu oVirt, při použití SAN (FC nebo iSCSI) je každý virtuální disk, snapshot nebo šablona – logický disk.
Bloková zařízení jsou shromažďována dohromady (na hostitelích clusteru) pomocí Volume Group a poté rozdělena pomocí LVM na logické svazky, které se používají jako virtuální disky pro VM.
Všechny tyto skupiny a mnoho svazků LVM lze vidět na hostiteli clusteru pomocí příkazů vgs a lvs. Samozřejmě, že všechny akce s takovými disky je třeba provádět pouze z konzole oVirt, kromě výjimečných případů.
Virtuální disky pro VM mohou být dvou typů – QCOW2 nebo RAW. Disky mohou být "tenké" nebo "silné". Snapshoty jsou vždy vytvářeny jako "tenké".
". Metoda správy úložných domén, nebo oblastí úložiště, k nimž je přístup přes FC, je docela logická – pro každý virtuální disk VM existuje samostatný logický svazek, který je přístupný pro zápis pouze jednomu hostiteli. V případě připojení přes FC, oVirt používá něco jako clusterové LVM.
Virtuální stroje umístěné na jedné úložné oblasti lze migrovat mezi hostiteli, kteří patří do stejného clusteru.
Jak vyplývá z popisu, cluster v oVirt, stejně jako cluster ve VMware vSphere nebo Hyper-V, v zásadě označuje to samé – jde o logickou skupinu hostitelů, ideálně stejného hardwarového složení, kteří mají společné úložiště pro disky virtuálních strojů.
Přejdeme přímo k vytvoření úlohy pro data (disky VM), protože bez ní nebude datové centrum inicializováno.
Připomínám, že všechny LUNy prezentované hostitelům clusteru by měly být viditelné prostřednictvím příkazu "multipath -ll».
Podle , přejdeme na portál a vstoupíme do Úložiště >> Domény -> Nová doména a provedeme pokyny z části "Přidání FCP úložiště".
Po spuštění průvodce vyplníme požadovaná pole:
- Název – nastavíme název clusteru
- Funkce domény – Data
- Typ úložiště – Fibre Channel
- Hostitel k použití – vybereme hostitele, na kterém je požadovaný LUN dostupný
Na seznamu LUNů označíme ten potřebný, klikneme na Přidat a poté OK. V případě potřeby můžeme upravit další parametry úložiště kliknutím na Pokročilé parametry.
Snímek obrazovky průvodce pro přidání "Storage domain"
Na základě výsledků práce průvodce bychom měli získat novou oblast úložiště a naše datové centrum přejde do stavu UP, nebo inicializováno:
Snímky datového centra a úložných oblastí v něm:
Vytvoření a nastavení sítí pro virtuální stroje
Odkaz na dokumentaci – oVirt Administration Guide,
Sítě, tedy Networks, slouží ke skupinování logických sítí používaných ve virtuální infrastruktuře oVirt.
Pro interakci síťového adaptéra na virtuálním stroji s fyzickým adaptérem na hostiteli se používají logické rozhraní typu Linux bridge.
Pro skupinování a oddělování provozu mezi sítěmi jsou na přepínačích nastaveny VLANy.
Při vytváření logické sítě pro virtuální stroje v oVirt je nutné jí přiřadit identifikátor odpovídající číslu VLAN na přepínači, aby VM mohly mezi sebou komunikovat, i když běží na různých uzlech clusteru.
Předběžné nastavení síťových adaptérů na hostitelích pro připojení virtuálních strojů mělo být provedeno v – byl nastaven logický interface bond1, dále by měly být všechny síťové nastavení prováděny pouze prostřednictvím administrativního portálu oVirt.
Po vytvoření VM s hosted-engine, vedle automatického vytvoření datového centra a clusteru, byla také automaticky vytvořena logická síť pro správu našeho clusteru – ovritmgmt, ke které je tato VM připojena.
Případně můžete zkontrolovat nastavení logické sítě ovritmgmt a upravit je, ale buďte opatrní, abyste neztratili kontrolu nad infrastrukturou oVirt.
Nastavení logické sítě ovritmgmt
Pro vytvoření nové logické sítě pro běžné VM v administrativním portálu přejděte do Síť >> Sítě >> Nové, a na kartě Obecné přidáme síť s potřebným identifikátorem VLAN a zaškrtneme možnost „VM Network“, to znamená, že ji lze použít pro přiřazení k VM.
Snímek nové logické sítě VLAN32
Na kartě Cluster, připojíme tuto síť k našemu clusteru Cluster1.
Poté přejdeme do Výpočetní >> Hosts, postupně navštívíme každý host, na kartě Síťové rozhraní, a spustíme průvodce Nastavení hostitelských sítí, abychom přidružili novou logickou síť k hostitelům.
Snímek obrazovky průvodce „Nastavení hostitelských sítí“
Agent oVirt automaticky provede veškerá potřebná nastavení sítě na hostiteli – vytvoří VLAN a BRIDGE.
Příklad konfiguračních souborů pro nové sítě na hostiteli:
cat ifcfg-bond1
# Generováno VDSM verze 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
# Generováno VDSM verze 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
# Generováno VDSM verze 4.30.17.1
DEVICE=ovirtvm-vlan432
TYPE=Bridge
DELAY=0
STP=off
ONBOOT=yes
MTU=1500
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=noJeště jednou připomínám, že na hostiteli clusteru NELZE předem ručně vytvářet síťová rozhraní ifcfg-bond1.432 a ifcfg-ovirtvm-vlan432.
Po přidání logické sítě a kontrole připojení mezi hostitelem a VM s hosted engine ji lze použít ve virtuálním stroji.
Vytvoření instalačního obrazu pro nasazení virtuálního stroje
Odkaz na dokumentaci – oVirt Administration Guide, , část Nahrávání obrázků do datové domény.
Bez instalačního obrazu OS nebude možné nainstalovat virtuální stroj, i když to samozřejmě není problém, pokud je v síti nainstalován například s předem vytvořenými obrazy.
V našem případě taková možnost není, takže budeme muset tento obraz importovat do oVirt sami. Dříve bylo nutné vytvořit ISO Domain, ale v nové verzi oVirt byl považován za zastaralý, a proto nyní lze nahrávat obrazy přímo do Storage domain z administrativního portálu.
V administrativním portálu jdeme do Úložiště >> Disky >> Nahrát >> Spustit
Přidáváme náš obraz OS ve formátu ISO, vyplníme všechna pole ve formuláři a klikneme na tlačítko "Otestovat připojení".
Snímek obrazovky průvodce přidání instalačního obrazu
Pokud obdržíme chybu tohoto druhu:
Nepodařilo se nahrát obrázek na disk d6d8fd10-c1e0-4f2d-af15-90f8e636dadc kvůli chybě sítě. Zajistěte, aby byla služba ovirt-imageio-proxy nainstalována a nakonfigurována a aby byla CA certifikát ovirt-engine zaregistrován jako důvěryhodná CA v prohlížeči. Certifikát lze stáhnout z https://ovirt.test.local/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA
Je třeba přidat certifikát oVirt do „Důvěryhodné kořenové certifikační autority„ (Trusted Root CA) na řídící stanici administrátora, odkud se pokoušíme nahrát obraz.
Po přidání certifikátu do Trusted Root CA znovu klikněte na "Otestovat připojení", měli byste obdržet:
Připojení k ovirt-imageio-proxy bylo úspěšné.Po provedení akce přidání certifikátu můžete zkusit znovu nahrát obraz ISO do Storage Domain.
V zásadě lze vytvořit samostatný Storage Domain typu Data pro ukládání obrazů a šablon oddělených od disků VM, nebo je dokonce ukládat do Storage Domain pro hostovanou infrastrukturu, ale to už je na uvážení administrátora.
Screenshot s obrazy ISO v Storage Domain pro hostovanou infrastrukturu
Vytvoření virtuálního stroje
Odkaz na dokumentaci:
oVirt Virtual Machine Management Guide –>
Po nahrání instalačního obrazu s OS do oVirt můžete přejít rovnou k vytvoření virtuálního stroje. Bylo vykonáno mnoho práce, ale již jsme na závěrečném kroku, pro který bylo všechno toto plánováno – zajištění odolné infrastruktury pro hosting vysoce dostupných virtuálních strojů. A to vše je zcela zdarma – nebyla utracena ani koruna za nákup licencí na software.
Pro vytvoření virtuálního stroje s CentOS 7 musí být nahrán instalační obraz s OS.
Vstupte do administračního portálu, přejděte na Výpočetní >> Virtuální stroje, a spusťte průvodce pro vytváření VM. Vyplňte všechny parametry a pole, a klikněte na OK. Je to velmi jednoduché, pokud se řídíte dokumentací.
Jako příklad uvedu základní a doplňkové nastavení pro vysoce dostupný VM, se vytvořeným diskem, připojeným k síti, a s bootováním z instalačního obrazu:
Snímky obrazovky s nastavením vysoce dostupného VM
Po dokončení práce s průvodcem jej zavřete, spusťte nový VM a nainstalujte na něj OS.
K tomu vstupte do konzole tohoto VM přes administrační portál:
Screenshot nastavení administračního portálu pro připojení k VM konzole
Aby bylo možné připojit se k VM konzole, je nejprve nutné nakonfigurovat konzoli v nastavení virtuálního stroje.
Screenshot nastavení VM, záložka „Konzole“
Pro připojení k VM konzoli lze použít například, .
Chcete-li se připojit k VM konzoli přímo v okně prohlížeče, musí být nastavení připojení prostřednictvím konzole následující:
Po instalaci OS na VM je doporučeno nainstalovat 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.serviceTím pádem, v důsledku našich akcí, vytvořená VM bude vysoce dostupná, tj. v případě selhání uzlu clusteru, na kterém je spuštěna, ji oVirt automaticky restartuje na druhém uzlu. Tuto VM lze také migrovat mezi hostiteli clusteru pro údržbu nebo jiné účely.
Závěr
Doufám, že se mi tímto článkem podařilo objasnit, že oVirt je zcela běžný nástroj pro správu virtuální infrastruktury, jehož nasazení není až tak složité – hlavně je třeba dodržovat určité pravidla a požadavky popsané jak v článku, tak v dokumentaci.
Vzhledem k rozsáhlému obsahu článku se do něj nepodařilo zahrnout mnoho věcí, jako jsou podrobné postupy různých wizardů se všemi podrobnými vysvětleními a screenshoty, dlouhé výstupy některých příkazů atd. Ve skutečnosti by to vyžadovalo napsat celou knihu, což nedává moc smysl kvůli neustále se objevujícím novým verzím SW s novinkami a změnami. Nejpodstatnější je pochopit princip, jak to všechno dohromady funguje, a získat obecný algoritmus úkonů pro vytvoření robustní platformy pro správu virtuálních strojů.
I když jsme vytvořili virtuální infrastrukturu, je nyní třeba naučit ji spolupracovat jak mezi jednotlivými prvky: hostiteli, virtuálními stroji, interními sítěmi, tak i s vnějším světem.
Tento proces je jedním z hlavních úkolů systémového nebo síťového administrátora, který bude podrobně osvětlen v dalším článku — o používání virtuálních routerů VyOS v robustní infrastruktuře naší společnosti (jak jste správně hádali, budou fungovat jako virtuální stroje na našem oVirt clusteru).
Zdroj: habr.com
