oVirt w 2 godziny. Część 1. Otwarta, odporna na awarie platforma wirtualizacji

Wprowadzenie

Projekt open source oVirt — wolna platforma wirtualizacji dla przedsiębiorstw. Przeglądając Habr, odkryłem, że oVirt nie jest tu tak szeroko omówiona, jak na to zasługuje.
oVirt jest w zasadzie upstreamem do komercyjnego systemu Red Hat Virtualization (RHV, wcześniej RHEV), rozwija się pod skrzydłami Red Hat. Aby uniknąć zamieszania, to nie to samo, co CentOS vs RHEL, model bardziej przypomina Fedora vs RHEL.
Pod maską — KVM, do zarządzania używa się interfejsu webowego. Opiera się na systemie RHEL/CentOS 7.
oVirt może być używany zarówno do „tradycyjnej” wirtualizacji serwerów, jak i wirtualizacji na desktopy (VDI), w przeciwieństwie do rozwiązania VMware, obie systemy mogą współistnieć w jednym kompleksie.
Projekt jest dobrze udokumentowany, od dawna osiągnął dojrzałość do użytkowania produkcyjnego i jest gotowy na duże obciążenia.
Ten artykuł jest pierwszym w cyklu o tym, jak zbudować działający klaster odporny na awarie. Przechodząc przez nie, w krótkim czasie (około 2 godziny) uzyskamy w pełni działający system, chociaż niektóre kwestie, oczywiście, nie będą mogły zostać poruszone, postaram się omówić je w następnych artykułach.
U siebie używamy go od kilku lat, zaczynaliśmy od wersji 4.1. Nasz system przemysłowy teraz działa na serwerach HPE Synergy 480 i ProLiant BL460c 10. generacji z procesorem Xeon Gold.
W momencie pisania aktualna wersja to 4.3.

Artykuły

1. Wprowadzenie (Jesteśmy tutaj)
2. Instalacja menedżera (ovirt-engine) i hipernadzorców (hosts)
3. Dodatkowe ustawienia

Cechy funkcjonalne

W oVirt istnieją 2 główne byty: ovirt-engine i ovirt-host(s). Dla tych, którzy dobrze znają produkty VMware, oVirt w ogóle jako platforma to vSphere, ovirt-engine — warstwa zarządzająca — pełni te same funkcje, co vCenter, a ovirt-host — hipernadzorca, jak ESX(i). Ponieważ vSphere jest bardzo popularnym rozwiązaniem, czasami będę porównywał je z nią.

Rys. 1 — panel sterowania oVirt.

Jako maszyny gościnne obsługiwane są większość dystrybucji Linux i wersji Windows. Dla maszyn gościnnych dostępne są agenty oraz zoptymalizowane wirtualne urządzenia i sterowniki virtio, w pierwszej kolejności kontroler dysku i interfejs sieciowy.
Aby zrealizować rozwiązanie zapewniające ciągłość działania oraz wszystkie interesujące funkcje, potrzebna jest współdzielona pamięć masowa. Obsługiwane są zarówno blokowe rozwiązania FC, FCoE, iSCSI, jak i plikowe pamięci NFS i inne. Aby zrealizować rozwiązanie zapewniające ciągłość działania, system pamięci również musi być niezawodny (minimum 2 kontrolery, multipathing).
Użycie lokalnych pamięci jest możliwe, ale domyślnie dla prawdziwego klastra nadają się tylko współdzielone pamięci (shared storages). Lokalne pamięci tworzą rozproszony zestaw hypervisorów, a nawet przy obecności współdzielonej pamięci, nie można zbudować klastra. Najlepszym rozwiązaniem są maszyny bezdyskowe z boot from SAN lub dyski o minimalnej pojemności. Prawdopodobnie przez vdsm hook możliwa jest wersja budowy z lokalnych dysków Software Defined Storage (np. Ceph) i prezentacja go VM, ale poważnie tego nie rozważałem.

Architektura

Rys. 2 — architektura oVirt.
Szczegółowe informacje na temat architektury można znaleźć w dokumentacji dokumentacji dewelopera.

Rys. 3 — obiekty oVirt.

Najwyższy element w hierarchii — Data Center. Określa, czy używane są współdzielone (shared) czy lokalne pamięci, a także zestaw funkcji (kompatybilność, od 4.1 do 4.3). Może być jeden lub więcej. Dla wielu wariantów można użyć domyślnego Data Center — Default.
Data Center składa się z jednego lub więcej Clusters. Klaster określa typ procesora, politykę migracji itp. Dla małych instalacji można także ograniczyć się do klastra Default.
Klaster z kolei składa się z Hostów, które wykonują główne zadania — noszą wirtualne maszyny, do których podłączone są pamięci. W klastrze zakłada się 2 lub więcej hostów. Choć technicznie możliwe jest utworzenie klastra z 1 hostem, to nie ma to praktycznego sensu.

W oVirt obsługiwanych jest wiele funkcji, w tym żywa migracja wirtualnych maszyn między hypervisorami (live migration) i pamięciami (storage migration), wirtualizacja desktopów (virtual desktop infrastructure) z pulami VM, maszyny stateful i stateless, wsparcie dla NVidia Grid vGPU, import z vSphere, KVM, a także wiele innych. Wszystkie te funkcje są dostępne bez opłat licencyjnych, a w razie potrzeby wsparcia można je zakupić od Red Hat poprzez regionalnych partnerów. API O cenach na RHV

O cenach na RHV

Koszt jest niski w porównaniu do VMware, kupuje się tylko wsparcie — bez wymogu zakupu samej licencji. Wsparcie jest dostępne tylko dla hipernadzorców, ovirt-engine, w przeciwieństwie do vCenter Server nie wymaga wydatków.

Przykład obliczeń na pierwszy rok posiadania

Rozważmy klaster z 4 maszynami dwu-socketowymi i ceny detaliczne (bez rabatów projektowych).
Standardowa subskrypcja RHV kosztuje 999 USD za socket/rok (premium 365/24/7 — 1499 USD), razem 4*2*999=$7992.
Cena vSphere:

• VMware vCenter Server Standard 10 837,13 USD za egzemplarz, plus subskrypcja Basic 2 625,41 USD (Produkcja — 3 125,39 USD);
• VMware vSphere Standard 1 164,15 USD + subskrypcja Basic 552,61 USD (Produkcja 653,82 USD);
• VMware vSphere Enterprise Plus 6 309,23 USD + subskrypcja Basic 1 261,09 USD (Produkcja 1 499,94 USD).

Razem: 10 837,13 + 2 625,41 + 4 * 2 * (1 164,15 + 552,61) = $27 196,62 za najtańszy wariant. Różnica wynosi około 3,5 razy!
W oVirt wszystkie funkcje są dostępne bez ograniczeń.

Skrócone charakterystyki i maksima

Wymagania systemowe

Do hipernadzorcy wymagany jest procesor z włączoną wirtualizacją sprzętową, minimalna ilość pamięci RAM do uruchomienia — 2 GiB, zalecana ilość pamięci masowej dla systemu operacyjnego — 55 GiB (głównie dla dzienników itp., sam system zajmuje niewiele).
Szczegóły — tutaj.
Dla Engine minimalne wymagania 2 rdzenie/4 GiB RAM/25 GiB pamięci masowej. Zalecane — od 4 rdzeni/16 GiB RAM/50 GiB pamięci masowej.
Jak w każdej systemie, istnieją ograniczenia co do ilości i wielkości, z których większość przekracza możliwości dostępnych masowych serwerów komercyjnych. Na przykład para Intel Xeon Gold 6230 może adresować 2 TiB RAM i daje 40 rdzeni (80 wątków), co jest mniej niż limity jednej VM.

Maksima Maszyn Wirtualnych:

• Maksymalnie jednocześnie działające maszyny wirtualne: Nielimitowane;
• Maksymalne wirtualne CPU na maszynę wirtualną: 384;
• Maksymalne pamięci na maszynę wirtualną: 4 TiB;
• Maksymalny rozmiar pojedynczego dysku na maszynę wirtualną: 8 TiB.

Maksima Gospodarza:

• Logiczne rdzenie CPU lub wątki: 768;
• RAM: 12 TiB;
• Liczba hostowanych maszyn wirtualnych: 250;
• Jednoczesne migracje na żywo: 2 przychodzące, 2 wychodzące;
• Pasmowe parametry migracji na żywo: Domyślnie 52 MiB (~436 Mb) na migrację w przypadku użycia polityki migracji tradycyjnej. Inne polityki używają wartości adaptacyjnych w oparciu o prędkość fizycznego urządzenia. Polityki QoS mogą ograniczać pasmo migracji.

Maksima Logicznymi Jednostkami Menedżera:

W wersji 4.3 istnieją następujące limity.

• Centrum danych
  • Maksymalna liczba centrów danych: 400;
  • Maksymalna liczba hostów: 400 wspieranych, 500 przetestowanych;
  • Maksymalna liczba VM: 4000 wspieranych, 5000 przetestowanych;
• Klaster
  • Maksymalna liczba klastrów: 400;
  • Maksymalna liczba hostów: 400 wspieranych, 500 przetestowanych;
  • Maksymalna liczba VM: 4000 wspieranych, 5000 przetestowanych;
• Sieć
  • Sieci logiczne/klaster: 300;
  • SDN/sieci zewnętrzne: 2600 przetestowanych, bez wymuszonego limitu;
• Pamięć
  • Maksymalna liczba domen: 50 wspieranych, 70 przetestowanych;
  • Hosty na domenę: Bez limitu;
  • Logiczne woluminy na blok domeny (więcej): 1500;
  • Maksymalna liczba LUN-ów (więcej): 300;
  • Maksymalny rozmiar dysku: 500 TiB (ograniczone domyślnie do 8 TiB).

Opcje wdrożenia

Jak już wspomniano, oVirt składa się z 2 podstawowych elementów — ovirt-engine (zarządzanie) i ovirt-host (hipernadzorca).
Silnik może być umieszczony zarówno poza samą platformą (standalone Manager - może to być VM uruchomiona na innej platformie lub oddzielnym hypervisorze, a nawet fizycznej maszynie), jak i na samej platformie (self-hosted engine, podobnie jak w przypadku podejścia VCSA od VMware).
Hypervisor może być zainstalowany zarówno na zwykłym systemie operacyjnym RHEL/CentOS 7 (EL Host), jak i na specjalizowanym minimalnym systemie operacyjnym (oVirt-Node, opartym na el7).
Wymagania sprzętowe dla wszystkich wariantów są w przybliżeniu identyczne.

Rys. 4 — standardowa architektura.

Rys. 5 — architektura Self-hosted Engine.

Dla siebie wybrałem wariant standalone Manager i EL Hosts:

• standalone Manager jest trochę prostszy w przypadku problemów z uruchomieniem, nie ma dylematu kurczaka i jajka (podobnie jak w przypadku VCSA — nie uruchomisz, dopóki przynajmniej jeden host nie zostanie całkowicie uruchomiony), ale pojawia się zależność od innego systemu*;
• EL Host zapewnia całą moc systemu operacyjnego, co jest pomocne w zdalnym monitorowaniu, debugowaniu, poszukiwaniu usterek itd.

* Jednak przez cały czas eksploatacji to nie było potrzebne, nawet po poważnej awarii zasilania.
Ale już bliżej do sedna!
Dla eksperymentu istnieje możliwość zwolnienia kilku ostrzy ProLiant BL460c G7 z procesorem Xeon®. Na nich będziemy reprodukować proces instalacji.
Węzłom nadamy nazwy ovirt.lab.example.com, kvm01.lab.example.com i kvm02.lab.example.com.
Przechodzimy bezpośrednio do instalacji.

Źródło: habr.com