Introducere
Proiect open source — o platformă de virtualizare de nivel enterprise. Răsfoind habr, am descoperit că nu este discutată aici atât de mult pe cât merit.
oVirt este, de fapt, upstream-ul pentru sistemul comercial Red Hat Virtualization (RHV, anterior RHEV), crescând sub aripa Red Hat. Pentru a evita confuzia, acesta nu este similar cu CentOS vs RHEL, modelul este mai aproape de Fedora vs RHEL.
Sub capotă — se utilizează o interfață web pentru management. Se bazează pe RHEL/CentOS 7.
oVirt poate fi folosit atât pentru virtualizarea „tradițională” a serverelor, cât și pentru virtualizarea desktop (VDI); spre deosebire de soluția VMware, ambele sisteme pot coexista într-un singur complex.
Proiectul este bine , a atins de mult maturitatea pentru utilizare în producție și este pregătit pentru sarcini ridicate.
Acest articol este primul dintr-o serie despre cum să construiești un cluster tolerant la erori. Parcurgându-le, vom obține în scurt timp (aproximativ 2 ore) un sistem complet funcțional, deși unele întrebări, desigur, nu vor putea fi abordate, voi încerca să le discut în articolele următoare.
Îl folosim de câțiva ani, am început cu versiunea 4.1. Sistemul nostru industrial rulează acum pe computere HPE Synergy 480 și ProLiant BL460c de generația a 10-a cu CPU Xeon Gold.
La momentul scrierii, versiunea operativă este 4.3.
Articole
- Introducere (Suntem aici)
Caracteristici funcționale
În oVirt există 2 entități principale: ovirt-engine și ovirt-host(s). Pentru cei care sunt familiarizați cu produsele VMware, oVirt, în general, ca platformă, este vSphere, ovirt-engine - stratul de management - îndeplinește aceleași funcții ca vCenter, iar ovirt-host - hipervizorul, ca ESX(i). Deoarece vSphere este o soluție foarte populară, uneori voi face comparații cu aceasta.
Fig. 1 — panoul de control oVirt.
Ca mașini gazdă, sunt acceptate majoritatea distribuțiilor Linux și versiunilor de Windows. Pentru mașinile gazdă există agenți și dispozitive virtuale și drivere optimizate virtio, în principal un controler de discuri și o interfață de rețea.
Pentru implementarea unei soluții de toleranță la defecte și a tuturor funcțiilor interesante este nevoie de un stocaj partajat. Suportă atât stocarea bloc FC, FCoE, iSCSI, cât și stocările fișierelor NFS și altele. Pentru a implementa o soluție de toleranță la defecte, sistemul de stocare trebuie, de asemenea, să fie tolerant la defecte (minim 2 controlere, multipathing).
Utilizarea stocărilor locale este posibilă, dar în mod implicit pentru un cluster autentic sunt potrivite doar stocările partajate. Stocările locale fac sistemul un set disperat de hypervizori și chiar și în prezența unui stocaj partajat, nu este posibil să se construiască un cluster. Cea mai corectă cale este mașinile fără disc cu boot din SAN sau discuri de volum minim. Probabil, prin hook-ul vdsm este posibil un variant de construcție din discuri locale Software Defined Storage (de exemplu, Ceph) și prezentarea acestuia către VM, dar nu l-am analizat serios.
Arhitectură
Fig. 2 – arhitectura oVirt.
Pentru detalii despre arhitectură, consultați dezvoltatorul.
Fig. 3 – obiectele oVirt.
Elementul de vârf în ierarhie este Data Center. Acesta definește dacă se folosesc stocări partajate (shared) sau locale, precum și setul de funcții utilizate (compatibilitate, între 4.1 și 4.3). Pot exista unul sau mai multe. Pentru multe opțiuni, utilizarea Data Center-ului implicit – Default este adecvată.
Data Center-ul constă din unul sau mai multe Clusters. Clusterul definește tipul procesorului, politicile de migrare și altele. Pentru instalații mici, se poate limita și la clusterul Default.
Clusterul, la rândul său, constă din Hosthosturi care efectuează lucrările principale – ele găzduiesc mașinile virtuale, la ele sunt conectate stocările. Se presupune că în cluster sunt 2 sau mai multe hosturi. Deși tehnic este posibil să se facă un cluster cu un singur host, acest lucru nu are utilitate practică.
În oVirt sunt suportate multe funcții, inclusiv migrarea live a mașinilor virtuale între hypervizori (live migration) și stocări (storage migration), virtualizarea desktopului (virtual desktop infrastructure) cu grupuri de VM, mașini VM cu stări (statefull) și fără stări (stateless), suport pentru NVidia Grid vGPU, import din vSphere, KVM, există capacități puternice și multe altele. Toate aceste funcții sunt disponibile fără taxe de licență, iar în caz de nevoie de suport, acesta poate fi achiziționat de la Red Hat prin intermediul partenerilor regionali.
Despre prețurile pentru RHV
Costul nu este ridicat comparativ cu VMware, achiziția se face doar pentru suport - fără a necesita achiziționarea licenței în sine. Suportul se achiziționează doar pentru hypervizorii, ovirt-engine, spre deosebire de vCenter Server, care necesită cheltuieli suplimentare.
Exemplu de calcul pentru primul an deținut
Să considerăm un cluster format din 4 mașini cu 2 socket-uri și prețurile retail (fără discount-uri de proiect).
Abonament standard RHV pe socket/an (premium 365/24/7 - $1499), total 4*2*$999=$7992.
:
- VMware vCenter Server Standard $10,837.13 per instanță, plus abonament Basic $2,625.41 (Production - $3,125.39);
- VMware vSphere Standard $1,164.15 + Abonament Basic $552.61 (Production $653.82);
- VMware vSphere Enterprise Plus $6,309.23 + Abonament Basic $1,261.09 (Production $1,499.94).
Total: 10,837.13 + 2,625.41 + 4 * 2 * (1,164.15 + 552.61) = $27 196,62 pentru cea mai mică variantă. Diferența este de aproximativ 3,5 ori!
În oVirt, toate funcțiile sunt disponibile fără restricții.
Specificații și maxime scurte
Cerințe sistem
Pentru hypervizor este necesar un CPU cu virtualizare hardware activată, volumul minim de RAM pentru pornire - 2 GiB, volumul recomandat de stocare pentru OS - 55 GiB (în principal pentru jurnale etc., OS-ul în sine ocupă puțin).
Mai multe detalii - .
Pentru cerințele minime sunt 2 nuclee/4 GiB RAM/25 GiB stocare. Recomandate - de la 4 nuclee/16 GiB RAM/50 GiB stocare.
Ca în orice sistem, există limitări asupra volumelor și numărilor, majoritatea depășind capacitățile serverelor comerciale disponibile. Astfel, o pereche poate adresa 2 TiB RAM și oferă 40 de nuclee (80 de fire), ceea ce este mai puțin decât limitele unei VM singure.
Maximele Mașinii Virtuale:
- Numărul maxim de mașini virtuale care pot rula simultan: Nelimitat;
- Numărul maxim de CPU virtuale per mașină virtuală: 384;
- Memoria maximă per mașină virtuală: 4 TiB;
- Dimensiunea maximă a unui singur disc per mașină virtuală: 8 TiB.
Maximele Host-ului:
- Nuclee sau fire logice CPU: 768;
- RAM: 12 TiB;
- Numărul mașinilor virtuale găzduite: 250;
- Migrații live simultane: 2 intrări, 2 ieșiri;
- Banda de migrație live: Se setează la 52 MiB (~436 Mb) per migrare atunci când folosiți politica de migrare legacy. Alte politici folosesc valori adaptive de throughput bazate pe viteza dispozitivului fizic. Politicile QoS pot limita banda de migrare.
Maximele Entităților Logice de Manager:
În 4.3 există .
- Centru de date
- Numărul maxim de centre de date: 400;
- Numărul maxim de gazde: 400 suportate, 500 testate;
- Numărul maxim de VM-uri: 4000 suportate, 5000 testate;
- Cluster
- Numărul maxim de clustere: 400;
- Numărul maxim de gazde: 400 suportate, 500 testate;
- Numărul maxim de VM-uri: 4000 suportate, 5000 testate;
- Rețea
- Rețele logice/cluster: 300;
- Rețele SDN/externe: 2600 testate, fără limită impusă;
- Stocare
- Numărul maxim de domenii: 50 suportate, 70 testate;
- Gazde per domeniu: Fără limită;
- Volume logice per domeniu bloc (mai mult): 1500;
- Numărul maxim de LUN-uri (mai mult): 300;
- Dimensiunea maximă a discului: 500 TiB (limitată la 8 TiB în mod implicit).
Opțiuni de implementare
Așa cum s-a menționat, oVirt constă din 2 elemente de bază - ovirt-engine (management) și ovirt-host (hypervizor).
Motorul poate fi găzduit fie în afara platformei (Manager standalone — acesta poate fi o VM rulată pe o altă platformă sau un hypervisor separat și chiar o mașină fizică), fie pe însăși platforma (motor auto-găzduit, similar cu abordarea VCSA de la VMware).
Hypervisorul poate fi instalat atât pe (EL Host), cât și pe (oVirt-Node, bazat pe el7).
Cerințele hardware pentru toate variantele sunt aproximativ aceleași.
Fig. 4 — arhitectura standard.
Fig. 5 — arhitectura Self-hosted Engine.
Am ales varianta Manager standalone și EL Hosts pentru mine:
- Managerul standalone este puțin mai simplu în cazul problemelor de pornire, nu există dilema oului și a găinii (la fel ca și pentru VCSA — nu poți porni dacă nu se ridică complet măcar un host), dar apare dependența de un alt sistem*;
- EL Host oferă întreaga putere a sistemului de operare, ceea ce este util pentru monitorizarea externă, depanare, identificarea defectelor etc.
* Totuși, pe parcursul întregii perioade de utilizare, acest lucru nu a fost necesar, chiar și după un accident grav cu alimentarea.
Dar să trecem la subiect!
Pentru experiment, există posibilitatea de a elibera câteva lame ProLiant BL460c G7 cu CPU Xeon®. Pe ele vom reproduce procesul de instalare.
Vremurilor le vom da nume ovirt.lab.example.com, kvm01.lab.example.com și kvm02.lab.example.com.
Trecem direct la .
Sursa: habr.com
