Introducere
Proiect open source — o platformă de virtualizare gratuită la nivel de întreprindere. După ce am derulat prin habr, am descoperit asta nu este acoperit aici atât de larg pe cât merită.
oVirt este de fapt un amonte pentru sistemul comercial Red Hat Virtualization (RHV, fost RHEV), care crește sub aripa Red Hat. Pentru a evita confuzia, aceasta nu la fel ca CentOS vs RHEL, model mai apropiat de Fedora vs RHEL.
Sub capotă - , o interfață web este utilizată pentru management. Bazat pe sistemul de operare RHEL/CentOS 7.
oVirt poate fi folosit atât pentru serverul „tradițional”, cât și pentru virtualizarea desktopului (VDI), spre deosebire de soluția VMware, ambele sisteme pot coexista într-un singur complex.
Proiectul este bun , a ajuns de mult la maturitate pentru utilizare productivă și este gata pentru sarcini mari.
Acest articol este primul dintr-o serie despre cum să construiți un cluster de failover funcțional. După ce le-am parcurs, în scurt timp (aproximativ 2 ore) vom obține un sistem complet funcțional, deși o serie de probleme, desigur, nu vor fi dezvăluite; voi încerca să le acopăr în articolele următoare.
Îl folosim de câțiva ani, începând cu versiunea 4.1. Sistemul nostru industrial rulează în prezent pe computere HPE Synergy 480 și ProLiant BL460c din a 10-a generație cu procesor Xeon Gold.
La momentul scrierii, versiunea actuală este 4.3.
Articole
- Introducere (Suntem aici)
Caracteristici funcționale
Există 2 entități principale în oVirt: ovirt-engine și ovirt-host(s). Pentru cei care sunt familiarizați cu produsele VMware, oVirt ca un întreg ca platformă este vSphere, ovirt-engine - nivelul de control - îndeplinește aceleași funcții ca vCenter, iar ovirt-host este un hypervisor, cum ar fi ESX (i). Deoarece vSphere este o soluție foarte populară, uneori o voi compara cu ea.
Orez. 1 — oVirt panoul de control.
Cele mai multe distribuții Linux și versiuni de Windows sunt acceptate ca mașini invitate. Pentru mașinile invitate există agenți și dispozitive virtuale optimizate și drivere virtio, în primul rând controlerul de disc și interfața de rețea.
Pentru a implementa o soluție tolerantă la erori și toate caracteristicile interesante, veți avea nevoie de stocare partajată. Sunt acceptate ambele stocări de fișiere bloc FC, FCoE, iSCSI și NFS etc.. Pentru a implementa o soluție tolerantă la erori, sistemul de stocare trebuie să fie, de asemenea, tolerant la erori (cel puțin 2 controlere, multipassing).
Utilizarea stocării locale este posibilă, dar în mod implicit doar stocările partajate sunt potrivite pentru un cluster real. Stocarea locală face ca sistemul să fie un set disparat de hipervizoare și, chiar și cu stocarea partajată, un cluster nu poate fi asamblat. Cea mai corectă modalitate sunt mașinile fără disc cu boot de la SAN sau discuri de dimensiune minimă. Probabil, prin hook-ul vdsm, este posibilă varianta de a asambla Software Defined Storage de pe discuri locale (de exemplu, Ceph) și de a-l prezenta la o VM, dar nu m-am gândit serios.
Arhitectură
Orez. 2 - oVirt arhitectură.
Mai multe detalii despre arhitectură găsiți în dezvoltator.
Orez. 3 — oVirt obiecte.
Elementul superior din ierarhie este − Data Center. Acesta determină dacă este utilizată stocarea partajată sau locală, precum și setul de caracteristici utilizat (compatibilitate, 4.1 până la 4.3). Poate fi unul sau mai multe. Pentru multe opțiuni, este potrivită utilizarea Centrului de date implicit - Implicit.
Centrul de date este format din unul sau mai multe clusterele. Clusterul determină tipul procesorului, politicile de migrare etc. Pentru instalări mici, vă puteți limita și la clusterul implicit.
Clusterul, la rândul său, este format din Gazdăcei care fac treaba principală - transportă mașini virtuale, stocarea este conectată la ele. Un cluster presupune 2 sau mai multe gazde. Deși din punct de vedere tehnic este posibil să se creeze un cluster cu 1 gazdă, acesta nu are nicio utilitate practică.
oVirt acceptă multe funcții, inclusiv. migrarea live a mașinilor virtuale între hipervizori (migrare live) și migrarea stocării (migrare stocare), virtualizare desktop (infrastructură desktop virtuală) cu pool-uri de VM, VM cu stare și fără stat, suport pentru NVidia Grid vGPU, import din vSphere, KVM, există o puternic și mult mai mult. Toate aceste funcții sunt disponibile fără drepturi de autor, iar dacă este necesar asistență, asistența poate fi achiziționată de la Red Hat prin intermediul partenerilor regionali.
Despre preturile RHV
Costul nu este mare în comparație cu VMware, se achiziționează doar suport - fără a fi necesară achiziționarea licenței în sine. Asistența este achiziționată numai pentru hipervizoare; ovirt-engine, spre deosebire de vCenter Server, nu necesită nicio cheltuială.
Exemplu de calcul pentru primul an de proprietate
Să luăm în considerare un grup de 4 aparate cu 2 prize și prețuri de vânzare cu amănuntul (fără reduceri de proiect).
Abonament RHV standard pe priză/an (premium 365/24/7 — 1499 USD), total 4*2*999 USD=$7992.
:
- VMware vCenter Server Standard 10,837.13 USD per instanță, plus abonamentul de bază 2,625.41 USD (Producție - 3,125.39 USD);
- VMware vSphere Standard 1,164.15 USD + Abonament de bază 552.61 USD (Producție 653.82 USD);
- VMware vSphere Enterprise Plus 6,309.23 USD + Abonament de bază 1,261.09 USD (Producție 1,499.94 USD).
Total: 10 + 837,13 + 2 * 625,41 * (4 + 2) = $ 27 196,62 pentru cea mai tânără variantă. Diferența este de aproximativ 3,5 ori!
În oVirt, toate funcțiile sunt disponibile fără restricții.
Scurte caracteristici și maxime
Cerințe de sistem
Hipervizorul necesită un procesor cu virtualizarea hardware activată, cantitatea minimă de RAM pentru pornire este de 2 GiB, cantitatea de stocare recomandată pentru sistemul de operare este de 55 GiB (mai ales pentru jurnalele etc., sistemul de operare în sine ocupă puțin).
Mai multe detalii - .
Pentru cerințe minime 2 nuclee/4 GiB RAM/25 GiB stocare. Recomandat - de la 4 nuclee/16 GiB de RAM/50 GiB de stocare.
Ca și în cazul oricărui sistem, există limitări privind volumele și cantitățile, dintre care majoritatea depășesc capacitățile serverelor comerciale de masă disponibile. Da, cuplu poate adresa 2 TiB de RAM și oferă 40 de nuclee (80 de fire), ceea ce este mai mic decât limitele unui singur VM.
Maxime mașini virtuale:
- Numărul maxim de mașini virtuale care rulează simultan: nelimitat;
- Procesoare virtuale maxime pe mașină virtuală: 384;
- Memoria maximă per mașină virtuală: 4 TiB;
- Dimensiunea maximă a unui singur disc per mașină virtuală: 8 TiB.
Maxime gazdă:
- Miezuri sau fire de execuție CPU logice: 768;
- RAM: 12 TiB;
- Număr de mașini virtuale găzduite: 250;
- Migrații live simultane: 2 de intrare, 2 de ieșire;
- Lățimea de bandă de migrare live: implicit la 52 MiB (~436 Mb) per migrare când utilizați politica de migrare moștenită. Alte politici folosesc valori adaptive de debit bazate pe viteza dispozitivului fizic. Politicile QoS pot limita lățimea de bandă de migrare.
Maximele entități logice ale managerului:
În 4.3 există .
- Centru de date
- Număr maxim de centre de date: 400;
- Număr maxim de gazde: 400 acceptate, 500 testate;
- Număr maxim de VM: 4000 acceptate, 5000 testate;
- Grup
- Număr maxim de clustere: 400;
- Număr maxim de gazde: 400 acceptate, 500 testate;
- Număr maxim de VM: 4000 acceptate, 5000 testate;
- Reţea
- Rețele logice/cluster: 300;
- SDN/rețele externe: 2600 testate, fără limită impusă;
- Depozitare
- Domenii maxime: 50 acceptate, 70 testate;
- Gazde pe domeniu: Fără limită;
- Volume logice pe domeniu de bloc (mai multe): 1500;
- Număr maxim de LUN-uri (mai multe): 300;
- Dimensiunea maximă a discului: 500 TiB (limitat la 8 TiB în mod implicit).
Opțiuni de implementare
După cum am menționat deja, oVirt este construit din 2 elemente de bază - ovirt-engine (control) și ovirt-host (hypervisor).
Motorul poate fi amplasat fie în afara platformei în sine (Manager de sine stătător - acesta poate fi o VM care rulează pe o altă platformă sau un hypervisor separat, sau chiar o mașină fizică), fie pe platforma în sine (motor auto-găzduit, similar cu abordarea VCSA de la VMware).
Hypervisorul poate fi instalat pe oricare (EL Gazdă) și mai departe (oVirt-Node, bazat pe el7).
Cerințele hardware pentru toate opțiunile sunt aproximativ aceleași.
Orez. 4 - arhitectura standard.
Orez. 5 - Arhitectura motorului auto-găzduit.
Pentru mine am ales opțiunea autonom Manager și EL Gazde:
- Managerul de sine stătător este puțin mai ușor când vine vorba de probleme de pornire, nu există o dilemă de pui și ou (ca și în cazul VCSA - nu puteți începe până când cel puțin o gazdă este complet activată), dar există o dependență de un alt sistem*;
- EL Host oferă toată puterea sistemului de operare, care este utilă pentru monitorizarea externă, depanare, depanare etc.
* Cu toate acestea, pe toată perioada de funcționare acest lucru nu a fost necesar, chiar și după o întrerupere gravă a curentului.
Dar să ne apropiem de subiect!
Pentru experimentare, este posibil să lansați o pereche de blade ProLiant BL460c G7 cu un procesor Xeon®. Le vom folosi pentru a reproduce procesul de instalare.
Să dăm nodurilor numele ovirt.lab.example.com, kvm01.lab.example.com și kvm02.lab.example.com.
Să mergem direct la .
Sursa: www.habr.com