Crearea unei infrastructuri IT reziliente. Partea 2. Instalarea și configurarea cluster-ului oVirt 4.3

Acest articol este o continuare a precedentului – „Crearea unei infrastructuri IT reziliente. Partea 1 – pregătirea pentru desfășurarea clusterului oVirt 4.3».

În acesta va fi discutat procesul de instalare și configurare de bază a unui cluster oVirt 4.3, pentru găzduirea mașinilor virtuale cu disponibilitate ridicată, având în vedere că toate pașii preliminari pentru pregătirea infrastructurii au fost deja finalizați anterior.

Partea introductivă

Obiectivul principal al articolului este, nu atât de a oferi un ghid pas cu pas de tipul „Next -> Da -> Finish”, cât de a arăta anumite particularități la instalarea și configurarea acestuia. Procesul de desfășurare a clusterului dumneavoastră nu va corespunde întotdeauna cu ceea ce este descris aici, din cauza particularităților infrastructurii și mediului, dar principiile generale vor fi aceleași.

Din punct de vedere subiectiv, oVirt 4.3 este similar funcțional cu VMware vSphere versiunea 5.x, dar, desigur, are propriile sale particularități de configurare și funcționare.

Pentru cei interesați, toate diferențele dintre RHEV (cunoscut și sub numele de oVirt) și VMware vSphere pot fi găsite pe internet, de exemplu, aici, însă voi menționa din când în când diferitele lor distincții sau similarități pe parcursul articolului.

De asemenea, aș dori puțin să compar modul de gestionare a rețelelor pentru mașinile virtuale. În oVirt este implementat un principiu similar de gestionare a rețelelor pentru mașinile virtuale (denumite în continuare VM), ca și în VMware vSphere:

• prin intermediul unui standard Linux bridge (în VMware — Standard vSwitch), care funcționează pe gazdele de virtualizare;
• prin intermediul Open vSwitch (OVS) (în VMware — Distributed vSwitch) – acesta este un comutator virtual distribuit, format din două componente principale: serverul central OVN și controlerele OVN de pe gazdele gestionate.

Este de remarcat că, din cauza simplității implementării, în articol vor fi descrise rețelele în oVirt pentru VM folosind standardul Linux bridge, care este alegerea standard atunci când se folosește hipervizorul KVM.

În acest context, există câteva reguli de bază privind lucrul cu rețeaua în cluster, pe care este mai bine să nu le încalci:

• Toate setările de rețea de pe gazde înainte de a fi adăugate în oVirt trebuie să fie identice, cu excepția adreselor IP.
• După ce gazda a fost preluată sub control de oVirt, nu este recomandat să modificați manual setările de rețea fără a avea o certitudine completă în privința acțiunilor, deoarece agentul oVirt va reveni pur și simplu la setările anterioare după repornirea gazdei sau a agentului.
• Adăugarea unei noi rețele pentru VM, la fel ca și lucrul cu aceasta, ar trebui să se realizeze doar din consola de management oVirt.

O altă observație importantă Pentru un mediu extrem de critic (foarte sensibil la pierderi financiare), ar fi recomandabil să folosiți suportul plătit și să utilizați Red Hat Virtualization 4.3. În timpul exploatării cluster-ului oVirt, pot apărea anumite situații pentru care este de dorit să obțineți asistență calificată cât mai repede, în loc să le rezolvați singuri.

Și, în sfârșit, se recomandă înainte de desfășurarea cluster-ului oVirt, să vă familiarizați cu documentația oficială, pentru a fi la curent cu cel puțin noțiunile și definițiile de bază, altfel va fi puțin dificil să citiți articolul în continuare.

Documentele de bază pentru înțelegerea articolului și a principiilor de funcționare a cluster-ului oVirt sunt următoarele:

• Ghid de instalare oVirt
• Ghid pentru Engine-ul Auto-găzduit oVirt
• Ghid de administrare oVirt
  

Volumul nu este foarte mare, în decurs de o oră-două se pot învăța principiile de bază, iar pentru cei care preferă detaliile, este recomandat să citiți Documentația produsului pentru Red Hat Virtualization 4.3 — RHEV și oVirt sunt practic același lucru.

Așadar, dacă toate setările de bază pe gazde, comutatoare și stocări sunt realizate, trecem direct la desfășurarea oVirt.

Partea 2. Instalarea și configurarea cluster-ului oVirt 4.3

Pentru o orientare mai ușoară, voi prezenta pe scurt principalele secțiuni din acest articol care trebuie realizate pe rând:

1. Instalarea serverului de control oVirt
2. Crearea unui nou centru de date
3. Crearea unui nou cluster
4. Instalarea gazdelor suplimentare în mediu Auto-găzduit
5. Crearea domeniilor de stocare
6. Crearea și configurarea rețelelor pentru mașinile virtuale
7. Crearea unei imagini de instalare pentru desfășurarea unei mașini virtuale
8. Crearea unei mașini virtuale

Instalarea serverului de control oVirt

Serverul de control oVirt – este cel mai important element din infrastructura oVirt, sub formă de mașină virtuală, gazdă sau dispozitiv virtual, care gestionează întreaga infrastructură oVirt.

Omologii săi apropiați din lumea virtualizării sunt:

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

Pentru instalarea serverului de control oVirt, avem două opțiuni:

Opțiunea 1
Desfășurarea serverului sub formă de VM specializată sau gazdă.

Această variantă funcționează destul de bine, dar cu condiția ca această VM să funcționeze independent de cluster, adică să nu fie lansată pe nici o gazdă a cluster-ului ca o mașină virtuală obișnuită gestionată de KVM.

De ce nu se poate desfășura o astfel de VM pe gazdele cluster-ului?

La începutul procesului de instalare a serverului de gestionare oVirt, ne confruntăm cu o dilemă — trebuie să instalăm mașina virtuală de gestionare, dar clusterul de fapt încă nu există, așa că ce putem face rapid? Corect – să instalăm KVM pe viitorul nod al clusterului, apoi să creăm o mașină virtuală, de exemplu, cu sistemul de operare CentOS și să desfășurăm motorul oVirt în aceasta. Acest lucru se poate face de obicei din rațiuni de control complet asupra unei astfel de mașini virtuale, dar aceasta este o intenție greșită, deoarece în acest caz, mai târziu vor apărea 100% probleme cu această mașină virtuală de gestionare:

• nu va putea fi migrată în consola oVirt între gazde (noduri) ale clusterului;
• la migrarea prin KVM folosind virsh migrate, această mașină virtuală va deveni inaccesibilă pentru gestionare din consola oVirt.
• Halele clusterului nu vor putea fi puse în Mod de întreținere dacă migrați această mașină virtuală de la gazdă la gazdă cu ajutorul virsh migrate.

Așa că faceți totul conform regulilor — folosiți pentru serverul de gestionare oVirt fie o gazdă separată, fie o mașină virtuală independentă rulată pe aceasta, iar cel mai bine este să faceți precum este descris în a doua variantă.

Opțiunea 2
Instalarea oVirt Engine Appliance pe gazda pe care o gestionează.

Exact această variantă va fi discutată mai departe, ca fiind mai corectă și mai potrivită în cazul nostru.
Cerințele pentru o astfel de mașină virtuală sunt descrise mai jos, adaug doar că se recomandă să aveți cel puțin două gazde în infrastructură, pe care poate fi rulată mașina virtuală de gestionare, pentru a-i asigura redundanța. Aș dori să adaug că, după cum am menționat deja în comentariile din articolul anterior, nu am reușit să obțin splitbrain în clusterul oVirt cu două gazde, având posibilitatea să ruleze mașini virtuale hosted-engine pe acestea.

Instalarea oVirt Engine Appliance pe prima gazdă a clusterului

Link către documentația oficială — Ghid pentru Engine-ul Auto-găzduit oVirt, capitolul „Dezvoltarea motorului auto-găzduit folosind linia de comandă»

Documentul prezintă condițiile preliminare care trebuie îndeplinite înainte de desfășurarea mașinii virtuale hosted-engine, precum și procesul detaliat de instalare, așa că nu are sens să-l repetăm literalmente, așa că ne concentram asupra câtorva detalii importante.

• Înainte de a începe toate acțiunile, asigurați-vă că activați suportul pentru virtualizare în setările BIOS de pe gazdă.
• Instalăm pe gazdă pachetul pentru installer-ul 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

• Lansăm procedura de implementare a oVirt Hosted Engine pe gazdă în screen (poate fi părăsit cu Ctrl-A + D, închis cu Ctrl-D):

screen
hosted-engine --deploy

Dacă doriți, puteți lansa instalarea cu un fișier răspuns pregătit anterior:

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

• În timpul desfășurării hosted-engine, indicăm toate parametrii necesari:

- numele cluster-ului
- numărul de vCPU și vRAM (recomandat 4 vCPU și 16 GB)
- parolele
- tipul de stocare pentru VM-ul hosted engine – în cazul nostru FC
- numărul LUN pentru instalarea hosted engine
- unde va fi situată baza de date pentru hosted engine – recomand pentru simplificare să alegem Local (aceasta este o bază de date PostgreSQL care funcționează în interiorul acestei VM)
și altele. 

• Pentru instalarea unei VM de înaltă disponibilitate cu hosted engine, pe SĨD am creat anterior un LUN special cu numărul 4 și dimensiunea de 150 GB, care a fost apoi prezentat gazdelor cluster-ului – vezi în articolul anterior.

Anterior, am verificat de asemenea vizibilitatea acestuia pe gazde:

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

• Întregul proces de desfășurare a hosted-engine nu implică nimic complicat, iar la final ar trebui să primim un mesaj de genul:

[ 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

Verificăm prezența serviciilor oVirt pe gazdă:

Dacă totul a fost realizat corect, atunci după finalizarea instalării, accesați dintr-un browser web https://ovirt_hostname/ovirt-engine de pe computerul administratorului și faceți clic pe [Administration Portal].

Captura de ecran „Administration Portal”

Introducând numele de utilizator și parola (stabilite în timpul instalării) în fereastra, la fel ca în captura de ecran, ajungem în panoul de control al Open Virtualization Manager, unde putem efectua toate acțiunile cu infrastructura virtuală:

1. adăuga centru de date
2. adăuga și configura cluster
3. adăuga gazde și gestionați-le
4. adăuga domenii de stocare sau Storage Domains, pentru discurile mașinilor virtuale
5. adăuga și configura rețele pentru mașinile virtuale
6. adăuga mașini virtuale, imagini de instalare, șabloane VM și gestionați-le

Toate aceste acțiuni vor fi discutate mai departe, unele pe scurt, altele mai detaliat și cu nuanțe.
Dar mai întâi, ți-aș recomanda să citesti această completare care, cu siguranță, le va fi de ajutor multora.

Complement

1) În principiu, dacă este necesar, nu există nimic care să împiedice instalarea anterior a hipervizorului KVM pe nodurile clusterului, utilizând pachetele libvirt și qemu-kvm (sau qemu-kvm-ev) versiunea dorită, deși la desfășurarea nodului clusterului oVirt, el poate face acest lucru și singur.

Dar dacă libvirt și qemu-kvm au fost instalate versiuni mai vechi, atunci poți primi o astfel de eroare în timpul desfășurării motorului găzduit:

eroare: configurare nesuportată: caracteristică CPU necunoscută: md-clear

Adică, este necesar să ai o versiune actualizată libvirt cu suport pentru MDS, care susține o astfel de politică:

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

Instalăm libvirt v.4.5.0-10.el7_6.12, cu suport pentru 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

Verificăm suportul pentru 'md-clear':

virsh domcapabilities kvm | grep require

După aceasta, poți continua cu instalarea motorului găzduit.

2) În oVirt 4.3, prezența și utilizarea unui firewall firewalld este o cerință obligatorie.

Dacă în timpul desfășurării VM-ului pentru motorul găzduit obții o astfel de eroare:

[ EROARE ] fatal: [localhost]: EȘEC! => {"changed": false, "msg": "firewalld trebuie să fie activat și activ pentru a desfășura corect motorul găzduit. Te rugăm să verifici, să corectezi și să desfășori din nou.n"}
[ EROARE ] A eșuat executarea etapei 'Finalizare': A eșuat executarea ansible-playbook
[https://bugzilla.redhat.com/show_bug.cgi?id=1608467

Atunci este necesar să dezactivezi un alt firewall (dacă este utilizat) și să instalezi și să pornești 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

Ulterior, la instalarea agentului ovirt pe un nou host pentru cluster, el va configura automat porturile necesare. firewalld automatically.

3) Rebootarea host-ului pe care rulează VM-ul cu motorul găzduit.

Ca de obicei, link 1 și link 2 la documentele de orientare.

Toată gestionarea VM-ului motorului găzduit se face DOAR prin comanda hosted-engine pe host-ul unde rulează, despre virsh trebuie să uiți, la fel ca și despre faptul că acest VM poate fi accesat prin SSH și să executăm pe el comanda "shutdown».

Procedura de scoatere a VM-ului în modul de întreținere:

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

hosted-engine --vm-status
!! Clusterul este în modul de ÎNTREȚINERE GLOBALĂ !!
--== 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                              : dee1a774
local_conf_timestamp               : 1821
Host timestamp                     : 1821
Extra metadata (valid at timestamp):
        metadata_parse_version=1
        metadata_feature_version=1
        timestamp=1821 (Sâmbătă 29 Noi 14:25:19 2019)
        host-id=1
        score=3400
        vm_conf_refresh_time=1821 (Sâmbătă 29 Noi 14:25:19 2019)
        conf_on_shared_storage=True
        maintenance=False
        state=GlobalMaintenance
        stopped=False

hosted-engine --vm-shutdown

Rebootăm hostul cu agentul hosted engine și facem ce avem de făcut.

După reboot, verificăm statusul VM-ului cu hosted engine:

hosted-engine --vm-status

Dacă VM-ul nostru cu hosted-engine nu pornește și dacă vedem erori similare în jurnalul serviciului:

Eroare în jurnalul serviciului:

journalctl -u ovirt-ha-agent
...
Jun 29 14:34:44 host1 jurn: ovirt-ha-agent ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine ERROR Eșec la pornirea monitorilor necesari
Jun 29 14:34:44 host1 jurn: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent ERROR Traceback (cel mai recent apel ultimele):#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 - eșec la pornirea monitorului prin ovirt-ha-broker: [Errno 2] Nu există un fișier sau un director, [monitor: 'ping', options: {'addr': '172.20.32.32'}]
Jun 29 14:34:44 host1 jurn: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent ERROR Încercând să repornesc agentul

Așadar, conectăm stocarea și repornim agentul:

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

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

După pornirea VM-ului cu hosted-engine, o scoatem din modul de întreținere:

Procedura de scoatere a VM-ului din modul de întreținere:

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) Eliminarea hosted engine și tot ce este legat de aceasta.

Uneori este necesar să ștergem corect hosted engine-ului instalat anterior — linkul documentul de ghidare.

Pur și simplu executăm comanda pe host:

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

Apoi ștergem pachetele inutile, făcând mai întâi un backup al unor configurații, dacă este necesar:

yum autoremove ovirt* qemu* virt* libvirt* libguestfs 

Crearea unui nou centru de date

Documentație de referință — oVirt Administration Guide. Capitolul 4: Centre de date

Mai întâi să definim ce este Centru de date (citat din documentație) — acesta este o entitate logică care definește un set de resurse utilizate într-un mediu specific.

Centru de date — este un fel de container, compus din:

• resurse logice sub formă de clustere și host-uri
• resurse de rețea ale clusterului sub formă de rețele logice și adaptoare fizice pe host-uri,
• resurse de stocare (pentru discurile VM, șabloane, imagini) sub formă de domenii de stocare (Storage Domains).

Un centru de date poate include mai multe clustere, compuse din mai multe host-uri cu mașini virtuale care rulează pe ele, poate avea și mai multe domenii de stocare asociate.
Pot exista mai multe centre de date, care funcționează independent unul de celălalt. În ovirt există o separare a drepturilor pe roluri, iar permisiunile pot fi configurate personalizat, atât la nivel de centru de date, cât și pentru elementele logice individuale ale acestuia.

Centru de date, sau centre de date dacă sunt mai multe, sunt gestionate dintr-o singură consolă administrativă sau portal.

Pentru a crea un centru de date, accesăm portalul administrativ și creăm un nou centru de date:
Compute >> Centre de date >> Nou

Pentru că folosim stocare comună pe un array de stocare, tipul de stocare (Storage Type) trebuie să fie Shared:

Captură de ecran cu asistentul de creare a centrelor de date

At the installation of a virtual machine with hosted-engine, a datacenter is created by default - Datacenter1, and if necessary, the storage type can be changed to another.

Creating a datacenter is not a complicated task, without any tricky nuances, and all additional actions with it are described in the documentation. I would only note that standalone hosts with only local storage (disk) for VMs will not be able to join a datacenter with Storage Type - Shared (they cannot be added there), and a separate datacenter must be created for them - i.e., each separate host with local storage needs its own separate datacenter.

Crearea unui nou cluster

Documentation link - oVirt Administration Guide. Chapter 5: Clusters

Without going into unnecessary details, cluster – this is a logical grouping of hosts that have a common storage area (in the form of shared disks on a storage system, as in our case). It is also desirable that the hosts in the cluster are identical in hardware and have the same type of processor (Intel or AMD). Ideally, the servers in the cluster should be completely identical.

The cluster is part of the datacenter (with a specific storage type - Local sau Partajat), and all hosts must belong to some cluster, depending on whether they have shared storage or not.

When installing a virtual machine with hosted-engine on a host, a datacenter is created by default - Datacenter1, along with a cluster - Cluster1, and later its parameters can be configured, additional options enabled, hosts added, etc.

As usual, for details on all cluster settings, it is advisable to refer to the official documentation. Regarding some of the features of cluster configuration, I would like to add that when creating it, it is enough to configure only the basic parameters on the tab General.

I will highlight the most important parameters:

• Processor type — is selected based on the processors installed on the cluster hosts, their manufacturer, and which processor on the hosts is the oldest, so as to make use of all available processor instructions in the cluster accordingly.
• Switch type – we use only Linux bridge in our cluster, so we choose it.
• Firewall type – everything is clear here, it is firewalld, which must be enabled and configured on the hosts.

A screenshot with the cluster parameters

Instalarea gazdelor suplimentare în mediul Self-Hosted

Link în documentație.

Gazdele suplimentare pentru mediul Self-Hosted sunt adăugate la fel ca o gazdă obișnuită, cu realizarea unui pas suplimentar pentru desfășurarea VM-ului cu motorul gazduit – Alege acțiunea de desfășurare a motorului gazduit >> Desfășoară. Deoarece gazda suplimentară trebuie să primească LUN pentru VM-ul cu motorul gazduit, aceasta înseamnă că această gazdă poate fi, dacă este necesar, utilizată pentru a găzdui VM-ul cu motorul gazduit.
În scopul redundanței, este foarte recomandat să existe cel puțin două gazde pe care să poate fi desfășurat VM-ul cu motorul gazduit.

Pe gazda suplimentară dezactivăm iptables (dacă este activat), activăm firewalld

systemctl stop iptables
systemctl disable iptables

systemctl enable firewalld
systemctl start firewalld

Instalăm versiunea necesară de KVM (dacă este cazul):

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

Instalăm repozitorile necesare și instalatorul motorului gazduit:

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

Apoi trecem în consola Open Virtualization Manager, adăugăm o nouă gazdă și efectuăm totul pas cu pas, așa cum este scris în documentation.

Ca urmare, după adăugarea gazdei suplimentare, ar trebui să obținem o imagine similară în consola de administrare, ca în captura de ecran.

Captura de ecran a portalului de administrare – gazde

Gazda pe care VM-ul cu motorul gazduit este activ în acest moment are o coroană de aur și inscripția „Running the Hosted Engine VM”, gazda pe care acest VM poate fi pornit dacă este necesar – inscripția „Can run the Hosted Engine VM».

În caz de defecțiune a gazdei pe care „Running the Hosted Engine VM”, aceasta se va reporni automat pe a doua gazdă. De asemenea, acest VM poate fi migrați de pe gazda activă pe cea rezervă pentru întreținere.

Configurarea gestionării energiei / fencing pe gazdele oVirt

Linkuri către documentație:

• Red Hat Virtualization 4.3 –> Referință tehnică -> Capitolul 4. Gestionarea energiei
• Ghid de administrare oVirt -> Capitolul 7: Gazde

Deși poate părea că adăugarea și configurarea gazdei sunt finalizate, nu este chiar așa.
Pentru funcționarea normală a gazdelor și identificarea/remedierea defecțiunilor cu oricare dintre acestea, este necesară configurarea gestionării energiei / fencing.

Fencing, sau îngrădirea – este procesul de excludere temporară a unui gazduitor defectuos sau defect din cluster, în cadrul căruia se repornesc fie serviciile oVirt de pe acesta, fie gazduitorul însuși.

Toate detaliile despre definiții și parametrii Gestionării energiei / îngrădire sunt oferite, ca de obicei, în documentație, eu voi oferi doar un exemplu despre cum să configurăm acest parametru important, aplicat la serverele Dell R640 cu iDRAC 9.

1. Accesăm portalul admin, facem clic Compute >> Hosts alegem gazduitorul.
2. Facem clic Editare.
3. Facem clic pe fila Gestionarea energiei.
4. Bifăm caseta de lângă opțiunea Activare gestionare energie.
5. Bifăm caseta de lângă opțiunea Integrarea Kdump, pentru ca gazduitorul să nu intre în modul de îngrădire (fencing) în timpul scrierii unui dump de urgență al nucleului.

Notă.

După activarea integrării Kdump pe un gazduitor deja funcțional, acesta trebuie reinstalat conform procedurii din oVirt Administration Guide -> Capitolul 7: Gazde -> Reinstalarea gazduitorilor.

1. Opțional, putem bifa caseta Dezactivează controlul politicii de gestionare a energiei, dacă nu dorim ca gestionarea energiei gazduitorului să fie controlată de politica de programare (Scheduling Policy) a clusterului.
2. Facem clic pe butonul (+), pentru a adăuga un nou dispozitiv de gestionare a energiei, va apărea o fereastră de editare a proprietăților agentului.
   Pentru iDRAC9, completăm câmpurile:
   • Address – adresa iDRAC9
   • Nume utilizator / Parolă – respectiv numele de utilizator și parola pentru accesul la iDRAC9
   • Tip — drac5
   • remarc Securizat
   • adăugați următoarele opțiuni: cmd_prompt=>,login_timeout=30

Captură de ecran cu parametrii „Gestionarea energiei” în proprietățile gazduitorului

Crearea domeniilor de stocare

Link către documentație – oVirt Administration Guide, Capitolul 8: Stocare.

Domeniul de stocare, sau domeniul de stocare – este un loc centralizat pentru stocarea discurilor mașinilor virtuale, imaginilor de instalare, șabloanelor și snapshot-urilor.

Domeniile de stocare pot fi conectate la centru de date, folosind diverse protocoale, sisteme de fișiere clusterizate și de rețea.

oVirt are trei tipuri de domenii de stocare:

• Domeniul de date – pentru stocarea tuturor datelor legate de mașinile virtuale (discuri, șabloane). Domeniul de date nu poate fi împărțit între diferite centre de date.
• Domeniul ISO (tip de domeniu de stocare învechit) – pentru stocarea imaginilor de instalare ale sistemului de operare. Domeniul ISO poate fi împărțit între diferite centre de date.
• Domeniul de export (tip de domeniu de stocare învechit) – pentru stocarea temporară a imaginilor, mutate între centrele de date.

În cazul nostru particular, domeniul de stocare de tip Domeniu de date folosește Protocolul Fibre Channel (FCP) pentru a se conecta la LUN-urile de pe sistemul de stocare.

Din perspectiva oVirt, atunci când se utilizează un sistem de stocare (FC sau iSCSI), fiecare disc virtual, snapshot sau șablon este un disc logic.
Discurile block sunt grupate împreună (pe gazdele clusterului) printr-un Volume Group și apoi sunt împărțite folosind LVM în volume logice utilizate ca discuri virtuale pentru VM-uri.

Toate aceste grupuri și numeroase volume LVM pot fi vizualizate pe gazda clusterului folosind comenzile vgs și lvs. Este evident că toate acțiunile legate de aceste discuri trebuie efectuate doar din consola oVirt, cu excepția cazurilor speciale.

Discurile virtuale pentru VM-uri pot fi de două tipuri - QCOW2 sau RAW. Discurile pot fi "subțiri" sau "groase". Snapshots sunt întotdeauna create ca "subțiri".

". Modul de gestionare a domeniilor de stocare, sau a zonelor de stocare, la care se accesează prin FC, este destul de logic - pentru fiecare disc virtual al VM-ului există un volum logic separat care este accesibil pentru scriere doar unei singure gazde. În cazul conexiunilor prin FC, oVirt folosește un sistem asemănător cu LVM de cluster.

Mașinile virtuale localizate într-o zonă de stocare pot fi migrate între gazdele care aparțin aceluiași cluster.

Așa cum vedem din descriere, un cluster în oVirt, la fel ca un cluster în VMware vSphere sau Hyper-V, denotă practic același lucru - este o grupare logică a gazdelor, preferabil identice din punct de vedere al „hardware”-ului, și având un sistem comun de stocare pentru discurile mașinilor virtuale.

Să trecem direct la crearea unei zone de stocare pentru date (discurile VM), deoarece fără aceasta, data center-ul nu va fi inițializat.
Reamintesc că toate LUN-urile prezentate gazdelor clusterului pe sistemul de stocare trebuie să fie vizibile prin comanda „multipath -ll».

Conform documentation, mergem în portal și accesăm Stocare >> Domains -> New Domain și urmăm instrucțiunile din secțiunea "Adding FCP Storage".

După ce lansăm expertul, completăm câmpurile necesare:

• Name — definim numele clusterului
• Domain Function — Data
• Storage Type — Fibre Channel
• Host to Use — alegem gazda pe care este disponibil LUN-ul de care avem nevoie

Din lista de LUN-uri selectăm pe cel dorit, dăm clic pe Adaugă apoi OK. Dacă este necesar, putem ajusta parametrii suplimentari ai zonei de stocare, dând clic pe Advanced Parameters.

Screenshot-ul asistentului pentru adăugarea „Storage domain”

Ca rezultat al activității asistentului, ar trebui să obținem o nouă zonă de stocare, iar data center-ul nostru să treacă în statutul UP, sau inițializat:

Screenshot-uri ale data center-ului și zonelor de stocare din acesta:

Crearea și configurarea rețelelor pentru mașinile virtuale

Link către documentație – oVirt Administration Guide, Capitolul 6: Rețele logice

Rețelele sunt utilizate pentru gruparea rețelelor logice folosite în infrastructura virtuală oVirt.

Pentru a interacționa adaptorul de rețea al unui sistem virtual cu adaptorul fizic de pe gazdă, se folosesc interfețe logice de tip Linux bridge.

Pentru a grupa și a separa traficul între rețele, VLAN-uri sunt configurate pe switch-uri.

Atunci când se creează o rețea logică pentru mașini virtuale în oVirt, trebuie să-i alocați un identificator care corespunde numărului VLAN de pe switch, astfel încât VM-urile să poată interacționa între ele, chiar dacă funcționează pe noduri diferite ale clusterului.

Configurările preliminare ale adaptoarelor de rețea pe gazde pentru conectarea mașinilor virtuale ar fi trebuit să fie realizate în articolul anterior – a fost configurată interfața logică bond1, toate celelalte setări de rețea trebuie efectuate doar prin portalul de administrare oVirt.

După crearea VM-ului cu hosted-engine, pe lângă crearea automată a centru de date și a clusterului, s-a creat de asemenea o rețea logică pentru gestionarea clusterului nostru – ovritmgmt, la care această VM a fost conectată.

Dacă este necesar, se pot vizualiza setările rețelei logice ovritmgmt și se pot ajusta, dar trebuie să fiți atenți să nu pierdeți controlul asupra infrastructurii oVirt.

Setările rețelei logice ovritmgmt

Pentru a crea o nouă rețea logică pentru VM-uri obișnuite, în portalul de administrare, accesați Rețea >> Rețele >> Nou, și pe tab-ul General adăugați o rețea cu identificatorul VLAN dorit și bifați căsuța lângă „VM Network”, ceea ce înseamnă că poate fi folosită pentru a fi alocată VM-urilor.

Captura de ecran a noii rețele logice VLAN32

Pe tab-ul Cluster, atașați această rețea la clusterul nostru Cluster1.

După aceasta, accesați Compute >> Hosts, intrați pe rând în fiecare gazdă, pe tab-ul Interfețe de rețea, și lansați asistentul Configurare rețele gazdă, pentru a lega noua rețea logică de gazde.

Captura de ecran a asistentului „Configurare rețele gazdă”

Agentul oVirt va efectua automat toate setările de rețea necesare pe gazdă – va crea VLAN și BRIDGE.

Exemplu de fișiere de configurare pentru noile rețele pe gazdă:

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

Reamintesc că pe gazda cluster-ului NU TREBUIE să creați manual interfețele de rețea ifcfg-bond1.432 și ifcfg-ovirtvm-vlan432.

După adăugarea rețelei logice și verificarea conexiunii între gazdă și VM cu hosted engine, aceasta poate fi utilizată în mașina virtuală.

Crearea unei imagini de instalare pentru desfășurarea unei mașini virtuale

Link către documentație – oVirt Administration Guide, Capitolul 8: Stocare, secțiunea Încărcarea imaginilor într-un domeniu de stocare de date.

Fără imaginea de instalare a sistemului de operare, nu veți putea instala mașina virtuală, deși acest lucru nu este, desigur, o problemă, dacă în rețea este instalat, de exemplu, Cobbler cu imagini create anterior.

În cazul nostru, această opțiune nu este disponibilă, așa că va trebui să importăm manual această imagine în oVirt. Anterior, era necesar să se creeze un domeniu ISO pentru aceasta, dar în noua versiune oVirt, acesta a fost declarat învechit, așa că acum se pot încărca imaginile direct în domeniul de stocare din portalul de administrare.

În portalul de administrare, mergem la Stocare >> Discuri >> Upload >> Start
Adăugați imaginea noastră a sistemului de operare sub formă de fișier ISO, completăm toate câmpurile în formular și facem clic pe butonul "Test connection".

Captura de ecran a wizard-ului de adăugare a imaginii de instalare

Dacă primim o eroare de acest tip:

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

Atunci este necesar să adăugați certificatul oVirt în „Autorități de certificare rădăcină de încredere» (Trusted Root CA) pe stația de administrare de unde încercăm să încărcăm imaginea.

După adăugarea certificatului în Trusted Root CA, facem din nou clic pe "Test connection", ar trebui să primim:

Conexiunea la ovirt-imageio-proxy a fost reușită.

După ce am realizat acțiunea de adăugare a certificatului, putem încerca din nou să încărcăm imaginea ISO în domeniul de stocare.

În principiu, se poate crea un domeniu de stocare separat de tip Data, pentru a stoca imaginile și șabloanele separat de discurile VM, sau chiar să le păstrăm în domeniul de stocare pentru hosted engine, dar aceasta depinde de decizia administratorului.

Captura de ecran cu imaginile ISO în domeniul de stocare pentru hosted engine

Crearea unei mașini virtuale

Link către documentație:
Ghidul de gestionare a mașinilor virtuale oVirt –> Capitolul 2: Instalarea mașinilor virtuale Linux
Resurse pentru clienți consola

După încărcarea imaginii de instalare a sistemului de operare în oVirt, putem trece direct la crearea mașinii virtuale. A fost mult de muncă, dar acum suntem în etapa finală, pentru care s-a făcut totul - obținerea unei infrastructuri rezistente pentru găzduirea mașinilor virtuale cu înaltă disponibilitate. Și totul este complet gratuit - niciun ban nu a fost cheltuit pentru achiziționarea de licențe software.

Pentru a crea o mașină virtuală cu CentOS 7, trebuie să fie încărcată imaginea de instalare a sistemului de operare.

Intrăm în portalul administrativ, mergem la Compute >> Mașini Virtuale, și lansăm asistentul pentru creare a MV. Completem toate parametrii și câmpurile, și facem clic pe OK. Este foarte simplu, dacă urmăm documentația.

Ca exemplu, voi prezenta setările principale și suplimentare pentru o MV cu înaltă disponibilitate, cu un disc creat, conectată la rețea, și cu încărcare din imaginea de instalare:

Capturi de ecran cu setările MV cu înaltă disponibilitate

După finalizarea lucrărilor cu asistentul, îl închidem, pornim o nouă MV și instalăm pe ea sistemul de operare.
Pentru aceasta, intrăm în consola acestei MV prin portalul administrativ:

Captură de ecran a setărilor portalului administrativ pentru conectarea la consola MV

Pentru a vă conecta la consola MV, trebuie mai întâi să configurați consola în proprietățile mașinii virtuale.

Captură de ecran a setărilor MV, tab-ul „Console”

Pentru a vă conecta la consola MV, puteți folosi, de exemplu, Virtual Machine Viewer.

Pentru a vă conecta la consola MV direct în fereastra browserului, setările de conectare prin consolă trebuie să fie următoarele:

După instalarea sistemului de operare pe MV, este recomandat să instalați agenții guest oVirt:

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

Astfel, ca rezultat al acțiunilor noastre, MV creată va fi cu înaltă disponibilitate, adică, în cazul unei căderi a nodului clusterului pe care este pornită, oVirt o va reporni automat pe al doilea nod. De asemenea, această MV poate fi migrată între gazdele clusterului pentru întreținere sau alte scopuri.

Concluzie

Sper că acest articol a reușit să comunice că oVirt este un instrument foarte decent pentru gestionarea infrastructurii virtuale, care nu este greu de implementat - important este să respectați anumite reguli și cerințe enunțate atât în articol, cât și în documentație.

Din cauza volumului mare al articolului, nu am putut include multe informații, cum ar fi execuția pas cu pas a diverselor asistențe cu toate explicațiile detaliate și capturile de ecran, ieșirile lungi ale unor comenzi etc. De fapt, ar fi necesar să scriem o carte întreagă, ceea ce nu are un sens deosebit, din cauza apariției constante a unor noi versiuni de software cu noutăți și modificări. Cea mai importantă este înțelegerea principiului cum funcționează totul împreună și obținerea unui algoritm general de acțiuni pentru crearea unei platforme de management a mașinilor virtuale reziliente.

Deși am creat infrastructura virtuală, acum trebuie să o învățăm să interacționeze atât între elementele sale distincte: gazde, mașini virtuale, rețele interne, cât și cu lumea exterioară.

Acest proces este una dintre sarcinile principale ale unui administrator de sistem sau de rețea, care va fi detaliat în articolul următor – despre utilizarea routerelor virtuale VyOS în infrastructura rezilientă a întreprinderii noastre (așa cum ați ghicit, ele vor funcționa ca mașini virtuale pe clusterul nostru oVirt).

Sursa: habr.com