Virt za 2 godziny. Część 1: Otwarta platforma wirtualizacji odporna na awarie

Wprowadzenie

projekt open source o Virt to bezpłatna platforma wirtualizacji klasy korporacyjnej. Przewijając habr, znalazłem to o Virt nie jest omawiany tak szeroko, jak na to zasługuje.
oVirt jest w rzeczywistości upstream dla komercyjnego systemu Red Hat Virtualization (RHV, dawniej RHEV), rozwijającego się pod skrzydłami Red Hat. Aby uniknąć zamieszania, to nie to samo co CentOS vs RHEL, model bliższy Fedorze vs RHEL.
Pod maską - KVM, do zarządzania używany jest interfejs sieciowy. Oparty na systemie operacyjnym RHEL/CentOS 7.
oVirt może być używany zarówno do „tradycyjnej” wirtualizacji serwerów, jak i desktopów (VDI), w przeciwieństwie do rozwiązania VMware, oba systemy mogą współistnieć w jednym kompleksie.
Projektuj dobrze udokumentowane, już dawno osiągnął dojrzałość do produktywnego użytku i jest gotowy do dużych obciążeń.
Ten artykuł jest pierwszym z serii na temat tworzenia działającego klastra pracy awaryjnej. Po ich przejrzeniu w krótkim czasie (około 2 godzin) otrzymamy w pełni działający system, choć szeregu kwestii oczywiście nie da się ujawnić, postaram się je omówić w kolejnych artykułach.
Używamy go od kilku lat, zaczynaliśmy od wersji 4.1. Nasz system przemysłowy działa teraz na komputerach HPE Synergy 480 i ProLiant BL460c 10. generacji z procesorami Xeon Gold.
W chwili pisania tego tekstu aktualna wersja to 4.3.

Artykuły

1. Wprowadzenie (jesteśmy tutaj)
2. Instalowanie menedżera (ovirt-engine) i hiperwizorów (hosty)
3. Ustawienia zaawansowane

Funkcje funkcjonalne

Istnieją 2 główne jednostki w oVirt: ovirt-engine i ovirt-host(s). Dla tych, którzy są zaznajomieni z produktami VMware, oVirt jako całość jako platforma to vSphere, ovirt-engine - warstwa kontrolna - wykonuje te same funkcje co vCenter, a ovirt-host to hypervisor, podobnie jak ESX (i). Ponieważ vSphere to bardzo popularne rozwiązanie, czasami będę je z nim porównywać.

Ryż. 1 - Panel kontrolny oVirt.

Większość dystrybucji Linuksa i wersji systemu Windows jest obsługiwana jako maszyny-gościa. Dla maszyn-gości są agenci i zoptymalizowane urządzenia wirtualne oraz sterowniki virtio, przede wszystkim kontroler dysku i interfejs sieciowy.
Aby wdrożyć rozwiązanie odporne na błędy i wszystkie interesujące funkcje, będziesz potrzebować współdzielonej pamięci masowej. Obsługiwane są zarówno blokowe pamięci masowe FC, FCoE, iSCSI, jak i plikowe NFS itp. Aby wdrożyć rozwiązanie odporne na uszkodzenia, system pamięci masowej musi być również odporny na uszkodzenia (co najmniej 2 kontrolery, wieloprzebiegowość).
Korzystanie z magazynów lokalnych jest możliwe, ale domyślnie dla prawdziwego klastra odpowiednie są tylko magazyny współdzielone. Lokalne magazyny sprawiają, że system jest odrębnym zestawem hiperwizorów, a nawet w przypadku współdzielonej pamięci masowej nie można utworzyć klastra. Najbardziej poprawnym sposobem są maszyny bezdyskowe z rozruchem z SAN lub dyski o minimalnym rozmiarze. Prawdopodobnie poprzez hak vdsm można zbudować z lokalnych dysków Software Defined Storage (na przykład Ceph) i zaprezentować jego VM, ale nie brałem tego poważnie pod uwagę.

Architektura

Ryż. 2 - architektura oVirt.
Więcej informacji o architekturze można znaleźć w dokumentacja deweloper.

Ryż. 3 - obiekty oVirt.

Najwyższy element w hierarchii − Centrum danych. Określa, czy używana jest pamięć współdzielona, ​​czy lokalna, a także używany zestaw funkcji (kompatybilność, od 4.1 do 4.3). Może być jeden lub więcej. W przypadku wielu opcji użycie domyślnego Data Center to Domyślne.
Centrum danych składa się z jednego lub więcej Klastry. Klaster określa typ procesora, politykę migracji itp. W przypadku małych instalacji można również ograniczyć się do klastra Default.
Klaster z kolei składa się z Gospodarzktóre wykonują główną pracę - przenoszą maszyny wirtualne, do których są podłączone magazyny. Klaster zakłada 2 lub więcej hostów. Chociaż technicznie możliwe jest utworzenie klastra z 1 hostem, nie ma to praktycznego zastosowania.

oVirt obsługuje wiele funkcji, m.in. migracja na żywo maszyn wirtualnych między hypervisorami (migracja na żywo) a storage (migracja do storage), wirtualizacja desktopów (infrastruktura desktopów wirtualnych) z pulami VM, statefull i stateless VMs, wsparcie dla NVidia Grid vGPU, import z vSphere, KVM, jest potężny API i wiele więcej. Wszystkie te funkcje są dostępne bezpłatnie, aw razie potrzeby wsparcie można zakupić od firmy Red Hat za pośrednictwem partnerów regionalnych.

O cenach RHV

Koszt nie jest wysoki w porównaniu z VMware, wykupuje się tylko wsparcie - bez wymogu zakupu samej licencji. Wsparcie jest kupowane tylko dla hypervisorów, ovirt-engine, w przeciwieństwie do vCenter Server, nie wymaga nakładów finansowych.

Przykład obliczenia dla 1. roku posiadania

Rozważ klaster 4 2 maszyn gniazdowych i ceny detaliczne (bez rabatów projektowych).
Abonament standardowy RHV kosztuje 999 USD na gniazdo/rok (premium 365/24/7 - 1499 USD), łącznie 4*2*999 USD=$7992.
Cena vSphere:

• VMware vCenter Server Standard 10,837.13 2,625.41 USD na instancję plus subskrypcja Basic 3,125.39 XNUMX USD (Produkcja XNUMX XNUMX USD);
• VMware vSphere Standard 1,164.15 USD + Podstawowa subskrypcja 552.61 USD (Produkcja 653.82 USD);
• VMware vSphere Enterprise Plus 6,309.23 USD + subskrypcja podstawowa 1,261.09 USD (Produkcja 1,499.94 USD).

Suma: 10 837,13 + 2 625,41 + 4 * 2 * (1 164,15 + 552,61) = $ 27 196,62 dla najmniejszej opcji. Różnica jest około 3,5 raza!
W oVirt wszystkie funkcje są dostępne bez ograniczeń.

Krótka charakterystyka i maksima

Wymagania systemowe

Hiperwizor wymaga procesora z włączoną wirtualizacją sprzętową, minimalna ilość pamięci RAM do uruchomienia to 2 GiB, zalecana ilość pamięci dla systemu operacyjnego to 55 GiB (głównie na logi itp., sam system operacyjny zajmuje niewiele).
Więcej szczegółów - tutaj.
dla silnik minimalne wymagania 2 rdzenie/4 GiB RAM/25 GiB pamięci. Zalecane — od 4 rdzeni / 16 GiB pamięci RAM / 50 GiB pamięci.
Jak w przypadku każdego systemu, istnieją ograniczenia dotyczące wolumenów i ilości, z których większość przekracza możliwości dostępnych masowych serwerów komercyjnych. Tak, para. Intel Xeon Gold 6230 może zaadresować 2 TiB pamięci RAM i daje 40 rdzeni (80 wątków), czyli nawet mniej niż limity jednej maszyny wirtualnej.

Maksymalne wartości maszyn wirtualnych:

• Maksymalna liczba jednocześnie działających maszyn wirtualnych: nieograniczona;
• Maksymalna liczba procesorów wirtualnych na maszynę wirtualną: 384;
• Maksymalna pamięć na maszynę wirtualną: 4 TiB;
• Maksymalny rozmiar pojedynczego dysku na maszynę wirtualną: 8 TiB.

Maksymalne wartości hosta:

• Logiczne rdzenie lub wątki procesora: 768;
• RAM: 12 TiB
• Liczba hostowanych maszyn wirtualnych: 250;
• Jednoczesne migracje na żywo: 2 przychodzące, 2 wychodzące;
• Przepustowość migracji na żywo: domyślnie 52 MiB (~436 Mb) na migrację w przypadku korzystania ze starszych zasad migracji. Inne zasady wykorzystują adaptacyjne wartości przepustowości na podstawie szybkości urządzenia fizycznego. Zasady QoS mogą ograniczać przepustowość migracji.

Maksymalne wartości jednostek logicznych menedżera:

W 4.3 są następujące granice.

• Centrum danych
  • Maksymalna liczba centrów danych: 400;
  • Maksymalna liczba hostów: 400 obsługiwanych, 500 testowanych;
  • Maksymalna liczba maszyn wirtualnych: 4000 obsługiwanych, 5000 testowanych;
• Grupa
  • Maksymalna liczba klastrów: 400;
  • Maksymalna liczba hostów: 400 obsługiwanych, 500 testowanych;
  • Maksymalna liczba maszyn wirtualnych: 4000 obsługiwanych, 5000 testowanych;
• Sieć
  • Sieci logiczne/klaster: 300
  • Sieci SDN/zewnętrzne: 2600 przetestowanych, bez narzuconego limitu;
• Magazynowanie
  • Maksymalna liczba domen: 50 obsługiwanych, 70 testowanych;
  • Hosty na domenę: bez limitu;
  • Woluminy logiczne na domenę blokową (więcej): 1500;
  • Maksymalna liczba jednostek LUN (więcej): 300;
  • Maksymalny rozmiar dysku: 500 TiB (domyślnie ograniczony do 8 TiB).

Opcje implementacji

Jak już wspomniano, oVirt zbudowany jest z 2 podstawowych elementów - ovirt-engine (zarządzanie) i ovirt-host (hypervisor).
Silnik może być hostowany zarówno poza samą platformą (standalone Manager - może to być VM działająca na innej platformie lub oddzielnym hiperwizorze, a nawet maszynie fizycznej), jak i na samej platformie (silnik samoobsługowy, podobny do VCSA firmy VMware zbliżać się).
Hiperwizor można zainstalować na zwykły system operacyjny RHEL/CentOS 7 (gospodarz EL) i wyspecjalizowany minimalny system operacyjny (oVirt-Node, oparty na el7).
Wymagania sprzętowe dla wszystkich wariantów są w przybliżeniu takie same.

Ryż. 4 - standardowa architektura.

Ryż. 5 — Własna architektura silnika.

Dla siebie wybrałem samodzielną opcję Manager i EL Hosts:

• samodzielny Manager jest nieco łatwiejszy w przypadku problemów z uruchamianiem, nie ma dylematu kurczaka i jajka (jak w przypadku VCSA - nie uruchomisz, dopóki co najmniej jeden host nie będzie w pełni uruchomiony), ale istnieje zależność od innego systemu *;
• EL Host zapewnia pełną moc systemu operacyjnego, co jest przydatne do zewnętrznego monitorowania, debugowania, rozwiązywania problemów i nie tylko.

* Nie było to jednak wymagane przez cały okres eksploatacji, nawet po poważnej awarii zasilania.
Ale bardziej do rzeczy!
Do celów eksperymentalnych można wypuścić parę serwerów kasetowych ProLiant BL460c G7 z procesorem Xeon®. Odtworzymy na nich proces instalacji.
Nazwijmy węzły ovirt.lab.example.com, kvm01.lab.example.com i kvm02.lab.example.com.
Przejdźmy bezpośrednio do instalacja.

Źródło: www.habr.com