Tworzenie odpornej IT infrastruktury. Część 2. Instalacja i konfiguracja klastra oVirt 4.3

Ten artykuł jest kontynuacją poprzedniego – „Tworzenie odpornej infrastruktury IT. Część 1 — przygotowanie do wdrożenia klastra oVirt 4.3».

W artykule zostanie omówiony proces podstawowej instalacji i konfiguracji klastra oVirt 4.3, przeznaczonego do hostowania wysoko dostępnych maszyn wirtualnych, zakładając, że wszystkie wcześniejsze kroki przygotowawcze zostały już zrealizowane.

Część wprowadzająca

Głównym celem artykułu jest nie tyle dostarczenie krok po kroku instrukcji w stylu „Dalej -> Tak -> Zakończ”, ile pokazanie niektórych cech podczas jego instalacji i konfiguracji. Proces wdrażania twojego klastra nie zawsze musi pokrywać się z opisanym w nim, ze względu na różnice w infrastrukturze i otoczeniu, ale ogólne zasady będą jednakowe.

Z subiektywnego punktu widzenia, oVirt 4.3 pod względem funkcjonalności przypomina VMware vSphere w wersji 5.x, ale oczywiście ma swoje własne cechy w konfiguracji i działaniu.

Dla zainteresowanych, wszystkie różnice między RHEV (aka oVirt) a VMware vSphere można znaleźć w Internecie, na przykład tutaj, ale czasami będę zaznaczał ich niektóre różnice lub podobieństwa w trakcie artykułu.

Osobno chciałbym nieco porównać pracę z sieciami dla maszyn wirtualnych. W oVirt wdrożono podobną zasadę zarządzania sieciami dla maszyn wirtualnych (dalej VM), jak w VMware vSphere:

• przy użyciu standardowego mostu Linux (w VMware — Standard vSwitch), działającego na hostach wirtualizacji;
• przy użyciu Open vSwitch (OVS) (w VMware — Distributed vSwitch) – to rozproszony wirtualny przełącznik składający się z dwóch głównych komponentów: centralnego serwera OVN i kontrolerów OVN na zarządzanych hostach.

Należy zauważyć, że z powodu prostoty realizacji, w artykule zostanie opisana konfiguracja sieci w oVirt dla VM przy użyciu standardowego mostu Linux, który jest standardowym wyborem przy używaniu hipernadzorcy KVM.

W związku z tym istnieje kilka podstawowych zasad dotyczących pracy z siecią w klastrze, których lepiej nie łamać:

• Wszystkie ustawienia sieciowe na hostach przed dodaniem ich do oVirt muszą być identyczne, z wyjątkiem adresów IP.
• Po tym, jak host zostanie przejęty pod kontrolę przez oVirt, zdecydowanie nie zaleca się wprowadzania jakichkolwiek zmian ręcznych w ustawieniach sieciowych, bez pełnej pewności co do swoich działań, ponieważ agent oVirt po prostu przywróci je do poprzednich po restarcie hosta lub agenta.
• Dodawanie nowej sieci do VM oraz praca z nią powinny być wykonywane jedynie z konsoli zarządzania oVirt.

Jeszcze jedno ważne zauważenie — dla bardzo krytycznego środowiska (bardzo wrażliwego na straty finansowe) naprawdę zalecałoby się korzystanie z płatnego wsparcia i wykorzystanie Red Hat Virtualization 4.3. W trakcie eksploatacji klastra oVirt mogą wystąpić sytuacje, w których warto jak najszybciej uzyskać pomoc fachową, zamiast radzić sobie z nimi samodzielnie.

I w końcu, zaleca się przed wdrożeniem klastra oVirt warto zaznajomić się z oficjalną dokumentacją, aby być na bieżąco przynajmniej z podstawowymi pojęciami i definicjami, w przeciwnym razie dalsze czytanie artykułu będzie trochę trudne.

Podstawowe dla zrozumienia artykułu i zasad działania klastra oVirt są te dokumenty pomocnicze:

• oVirt Installation Guide
• oVirt Self-Hosted Engine Guide
• oVirt Administration Guide
  

Objętość nie jest zbyt duża, w ciągu godziny-dwóch można ogarnąć podstawowe zasady, a dla miłośników szczegółów zaleca się przeczytanie Product Documentation for Red Hat Virtualization 4.3 — RHEV i oVirt w zasadzie to samo.

Tak więc, jeśli wszystkie podstawowe ustawienia na hostach, przełącznikach i macierzach dyskowych zostały pomyślnie wykonane, przechodzimy bezpośrednio do wdrożenia oVirt.

Część 2. Instalacja i konfiguracja klastra oVirt 4.3

Dla wygody orientacji, podam w formie listy główne sekcje w tym artykule, które powinny być kolejno wykonane:

1. Instalacja serwera zarządzającego oVirt
2. Tworzenie nowego centrum danych
3. Tworzenie nowego klastra
4. Instalacja dodatkowych hostów w środowisku Self-Hosted
5. Tworzenie obszarów przechowywania lub Storage Domains
6. Tworzenie i konfiguracja sieci dla maszyn wirtualnych
7. Tworzenie obrazu instalacyjnego do wdrożenia maszyny wirtualnej
8. Tworzenie maszyny wirtualnej

Instalacja serwera zarządzającego oVirt

Serwer zarządzający oVirt – to kluczowy element infrastruktury oVirt, w postaci maszyny wirtualnej, hosta lub urządzenia wirtualnego, zarządzającego całą infrastrukturą oVirt.

Jego bliskie odpowiedniki w świecie wirtualizacji to:

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

Aby zainstalować serwer zarządzający oVirt, mamy dwa warianty:

Opcja 1
Wdrożenie serwera w formie wyspecjalizowanej VM lub hosta.

Ta opcja działa, ale pod warunkiem, że taka VM działa niezależnie od klastra, tzn. nie jest uruchomiona na żadnym hoście klastra jako zwykła wirtualna maszyna zarządzana przez KVM.

Dlaczego nie można uruchamiać takiej VM na hostach klastra?

Na samym początku procesu uruchamiania serwera zarządzającego oVirt mamy dylemat — musimy zainstalować VM zarządzającą, ale samego klastra właściwie jeszcze nie ma, więc co można wymyślić? Oczywiście — zainstalować KVM na przyszłym węźle klastra, następnie utworzyć na nim wirtualną maszynę, na przykład z systemem CentOS i w niej uruchomić silnik oVirt. Zwykle robi się to w celu pełnej kontroli nad taką VM, ale to mylne zamierzenie, ponieważ w takim przypadku, później będą 100% problemy z tą VM zarządzającą:

• nie będzie można jej migrować w konsoli oVirt między hostami (węzłami) klastra;
• podczas migracji za pomocą KVM przez virsh migrate, ta VM będzie niedostępna do zarządzania z konsoli oVirt.
• hosty klastra nie będą mogły być wyłączone w tryb konserwacji (Maintenance mode), jeśli migrować tę VM z hosta na hosta za pomocą virsh migrate.

Zatem róbcie wszystko zgodnie z zasadami — używajcie do serwera zarządzającego oVirt lub oddzielnego hosta, lub niezależnej VM uruchomionej na nim, a jeszcze lepiej róbcie tak jak opisano w drugim wariancie.

Opcja 2
Instalacja oVirt Engine Appliance na zarządzanym przez niego hoście klastra.

Właśnie ten wariant zostanie omówiony dalej, jako bardziej poprawny i odpowiedni w naszym przypadku.
Wymagania dotyczące takiej VM opisano poniżej, dodam tylko, że zaleca się posiadanie co najmniej dwóch hostów w infrastrukturze, na których może być uruchomiona VM zarządzająca, aby zapewnić jej odporność na awarie. Chciałbym dodać, że jak już pisałem w komentarzach w poprzednim artykule, nie udało mi się uzyskać splitbrain na klastrze oVirt z dwóch hostów, z możliwością uruchomienia hosted-engine VM na nich.

Instalacja oVirt Engine Appliance na pierwszym hoście klastra

Link do oficjalnej dokumentacji — oVirt Self-Hosted Engine Guide, rozdział „Implementacja samodzielnie hostowanego silnika przy użyciu wiersza poleceń»

W dokumencie określono wstępne warunki, które muszą być spełnione przed uruchomieniem hosted-engine VM, a także dokładnie opisano sam proces jej instalacji, więc nie ma sensu powtarzać go dosłownie, dlatego zwrócimy uwagę na kilka ważnych szczegółów.

• Przed rozpoczęciem jakichkolwiek działań należy włączyć obsługę wirtualizacji w ustawieniach BIOS na hoście.
• Instalujemy na hoście pakiet dla instalatora 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

• Uruchamiamy na hoście procedurę wdrażania oVirt Hosted Engine w screenie (wyjście z niego można uzyskać przez Ctrl-A + D, zamknąć przez Ctrl-D):

screen
hosted-engine --deploy

W razie potrzeby można uruchomić instalację z wcześniej przygotowanym plikiem odpowiedzi:

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

• Podczas wdrażania hosted-engine wskazujemy wszystkie niezbędne parametry:

- nazwa klastra
- liczba vCPU i vRAM (zaleca się 4 vCPU i 16 GB)
- hasła
- typ pamięci masowej dla VM hosted engine – w naszym przypadku FC
- numer LUN dla instalacji hosted engine
- gdzie będzie znajdować się baza danych dla hosted engine – dla prostoty zalecam wybrać Local (jest to baza danych PostgreSQL działająca wewnątrz tej VM)
oraz inne parametry. 

• Aby zainstalować wysoko dostępne VM z hosted engine, w naszej macierzy dyskowej wcześniej utworzyliśmy specjalny LUN o numerze 4 i pojemności 150 GB, który następnie został zaprezentowany hostom klastra – patrz w poprzedniej artykule.

Wcześniej również sprawdzaliśmy jego widoczność na hostach:

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

• Sam proces wdrażania hosted-engine nie jest skomplikowany, na końcu powinniśmy otrzymać mniej więcej takie komunikaty:

[ 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

Sprawdzamy obecność usług oVirt na hoście:

Jeśli wszystko zostało wykonane poprawnie, po zakończeniu instalacji wchodzimy za pomocą przeglądarki internetowej na https://ovirt_hostname/ovirt-engine z komputera administratora i klikamy [Portal administracyjny].

Zrzut ekranu 'Portal administracyjny'

Wprowadzając nazwę użytkownika i hasło (ustawione w trakcie instalacji) w oknie jak na zrzucie ekranu, trafiamy do panelu zarządzania Open Virtualization Manager, w którym można wykonywać wszelkie czynności związane z wirtualną infrastrukturą:

1. dodawanie centrum danych
2. dodawanie i konfigurowanie klastra
3. dodawanie hostów i zarządzanie nimi
4. dodawanie obszarów przechowywania lub Storage Domains dla dysków maszyn wirtualnych
5. dodawanie i konfigurowanie sieci dla maszyn wirtualnych
6. dodawanie maszyn wirtualnych, obrazów instalacyjnych, szablonów VM oraz zarządzanie nimi

Wszystkie te czynności będą omówione dalej, niektóre w dużych szczegółach, inne dokładniej i z niuansami.
Najpierw poleciłbym przeczytać to uzupełnienie, które na pewno przyda się wielu osobom.

Uzupełnienie

1) Zasadniczo, jeśli zachodzi taka potrzeba, to nic nie stoi na przeszkodzie, aby zainstalować hipernadzorcę KVM na węzłach klastra, korzystając z pakietów libvirt i qemu-kvm (lub qemu-kvm-ev) pożądanej wersji, chociaż podczas wdrażania węzła klastra oVirt, może to zrobić samodzielnie.

Ale jeśli libvirt i qemu-kvm zainstalowano wersję, która nie jest najnowsza, to można napotkać taki błąd podczas wdrażania hosted engine:

error: unsupported configuration: unknown CPU feature: md-clear

To znaczy, że konieczne jest posiadanie aktualnej wersji libvirt z ochroną przed MDS, która obsługuje taką politykę:

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

Instalujemy libvirt v.4.5.0-10.el7_6.12, z obsługą 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

Sprawdzamy wsparcie dla 'md-clear':

virsh domcapabilities kvm | grep require

Po tym można kontynuować instalację hosted engine.

2) W oVirt 4.3 obecność i użycie zapory ogniowej firewalld jest obowiązkowym wymaganiem.

Jeśli podczas wdrażania VM dla hosted-engine pojawia się taki błąd:

[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "firewalld is required to be enabled and active in order to correctly deploy hosted-engine. Please check, fix accordingly and re-deploy.n"}
[ ERROR ] Failed to execute stage 'Closing up': Failed executing ansible-playbook
[https://bugzilla.redhat.com/show_bug.cgi?id=1608467

Należy wtedy wyłączyć inny zaporę (jeśli jest używana) oraz zainstalować i uruchomić 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

Następnie, podczas instalacji agenta ovirt na nowym hoście dla klastra, ustawi wymagane porty w firewalld automatycznie.

3) Restartowanie hosta z działającą na nim maszyną wirtualną z hosted engine.

Jak zwykle, link 1 i link 2 do dokumentacji.

Cała administracja VM z hosted engine odbywa się TYLKO za pomocą polecenia hosted-engine na hoście, na którym działa, o virsh należy zapomnieć, tak samo jak o tym, że można połączyć się z tą maszyną wirtualną przez SSH i wykonać na niej polecenie „shutdown».

Procedura przechodzenia maszyny wirtualnej w tryb konserwacji:

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

hosted-engine --vm-status
!! Klaster znajduje się w trybie GLOBALNEJ KONSERWACJI !!
--== Stan hosta host1.test.local (id: 1) ==--
conf_on_shared_storage             : True
Status na bieżąco                     : True
Nazwa hosta                          : host1.test.local
ID hosta                            : 1
Status silnika                    : {"health": "good", "vm": "up", "detail": "Up"}
Wynik                               : 3400
zatrzymany                           : False
Lokalna konserwacja                 : False
crc32                               : dee1a774
local_conf_timestamp                : 1821
Znacznik czasu hosta                : 1821
Dodatkowe metadane (ważne w znaczniku czasu):
        metadata_parse_version=1
        metadata_feature_version=1
        timestamp=1821 (Sob Nov 29 14:25:19 2019)
        host-id=1
        score=3400
        vm_conf_refresh_time=1821 (Sob Nov 29 14:25:19 2019)
        conf_on_shared_storage=True
        maintenance=False
        state=GlobalMaintenance
        stopped=False

hosted-engine --vm-shutdown

Restartujemy hosta z agentem hosted engine i robimy z nim co należy.

Po restarcie sprawdzamy status maszyny wirtualnej z hosted engine:

hosted-engine --vm-status

Jeśli nasza maszyna wirtualna z hosted-engine nie uruchamia się i widzimy podobne błędy w logu serwisu:

Błąd w logu serwisu:

journalctl -u ovirt-ha-agent
...
Jun 29 14:34:44 host1 dziennik: ovirt-ha-agent ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine BŁĄD Nie udało się uruchomić niezbędnych monitorów
Jun 29 14:34:44 host1 dziennik: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent BŁĄD Traceback (najnowsze wywołanie ostatnie):#012  Plik "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/agent.py", linia 131, w _run_agent#012    return action(he)#012  Plik "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/agent.py", linia 55, w action_proper#012    return he.start_monitoring()#012  Plik "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/hosted_engine.py", linia 413, w start_monitoring#012    self._initialize_broker()#012  Plik "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/hosted_engine.py", linia 537, w _initialize_broker#012    m.get('options', {}))#012  Plik "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/lib\/brokerlink.py", linia 86, w start_monitor#012    ).format(t=type, o=options, e=e)#012RequestError: brokerlink - nie udało się uruchomić monitora za pomocą ovirt-ha-broker: [Errno 2] Nie ma takiego pliku ani katalogu, [monitor: 'ping', options: {'addr': '172.20.32.32'}]
Jun 29 14:34:44 host1 dziennik: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent BŁĄD Próba ponownego uruchomienia agenta

Zatem podłączamy magazyn i restartujemy agenta:

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

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

Po uruchomieniu maszyny wirtualnej z hosted-engine, wyprowadzamy ją z trybu konserwacji:

Procedura wyprowadzania maszyny wirtualnej z trybu konserwacji:

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) Usunięcie hosted engine i wszystkiego z tym związanego.

Czasem konieczne jest poprawne usunięcie wcześniej zainstalowanego hosted engine — link na dokument roboczy.

Po prostu wykonujemy polecenie na hoście:

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

Następnie usuwamy niepotrzebne pakiety, wcześniej tworząc kopię zapasową niektórych konfiguracji, jeśli to konieczne:

yum autoremove ovirt* qemu* virt* libvirt* libguestfs 

Tworzenie nowego centrum danych

Dokumentacja referencyjna — oVirt Administration Guide. Rozdział 4: Centra danych

Najpierw określimy, czym jest centrum danych (cytuję z dokumentacji) — to logiczny byt, który definiuje zestaw zasobów używanych w specyficznym środowisku.

Centrum danych — to swego rodzaju kontener, składający się z:

• logicznych zasobów w postaci klastrów i hostów
• zasobów sieciowych klastra w postaci logicznych sieci i fizycznych adapterów na hostach,
• zasobów przechowywania (dla dysków VM, szablonów, obrazów) w postaci obszarów przechowywania (Storage Domains).

Centrum danych może obejmować kilka klastrów, składających się z kilku hostów z maszynami wirtualnymi działającymi na nich, może również mieć kilka obszarów przechowywania, z nim skojarzonych.
Może być wiele centrów danych, które działają niezależnie od siebie. W oVirt istnieje podział uprawnień na role, i można dostosować uprawnienia indywidualnie, zarówno na poziomie centrum danych, jak i na jego poszczególnych logicznych elementach.

Centrum danych, lub centra danych, jeśli jest ich wiele, zarządzane są z jednej konsoli administracyjnej lub portalu.

Aby stworzyć centrum danych, wchodzimy do portalu administracyjnego i tworzymy nowe centrum danych:
Obliczenia >> Centra danych >> Nowe

Ponieważ używamy wspólnego przechowywania na SStorage, typ przechowywania (Storage Type) musi być Wspólny:

Zrzut ekranu z kreatorem tworzenia centrum danych

Podczas instalacji maszyny wirtualnej z hosted-engine, domyślnie tworzony jest centrum danych – Datacenter1, a następnie w razie potrzeby można zmienić typ pamięci (Storage Type) na inny.

Utworzenie centrum danych jest prostym zadaniem, bez żadnych skomplikowanych niuansów, a wszystkie dodatkowe działania z nim są opisane w dokumentacji. Zauważam jedynie, że pojedyncze hosty posiadające tylko lokalne pamięci (dysk) dla VM nie będą mogły być dodane do centrum danych z typem pamięci — Shared, dlatego dla nich należy stworzyć oddzielne centrum danych – tzn. każdy oddzielny host z lokalną pamięcią potrzebuje swojego własnego centrum danych.

Tworzenie nowego klastra

Link do dokumentacji – oVirt Administration Guide. Rozdział 5: Klastery

Bez zbędnych szczegółów, klaster – to logiczna grupa hostów, które mają wspólny obszar pamięci (w postaci wspólnych dysków na macierzy, jak w naszym przypadku). Również pożądane jest, aby hosty w klastrze były identyczne pod względem sprzętowym i miały ten sam typ procesora (Intel lub AMD). Najlepiej, aby serwery w klastrze były całkowicie takie same.

Klaster wchodzi w skład centrum danych (z określonym typem pamięci — Local lub Wspólny), a wszystkie hosty muszą koniecznie należeć do jakiegoś klastra, w zależności od tego, czy mają wspólną pamięć, czy nie.

Podczas instalacji maszyny wirtualnej z hosted-engine na hoście, domyślnie tworzone jest centrum danych — Datacenter1, wraz z klastrem – Cluster1, a następnie można dostosować jego parametry, włączyć dodatkowe opcje, dodać do niego hosty itd.

Jak zazwyczaj, aby uzyskać szczegóły dotyczące wszystkich ustawień klastra, warto odwołać się do oficjalnej dokumentacji. Z pewnych cech konfiguracji klastra dodam tylko, że podczas jego tworzenia wystarczy skonfigurować tylko podstawowe parametry na zakładce General.

Zaznaczę najważniejsze parametry:

• Typ procesora — wybiera się go w zależności od tego, jakie procesory są zainstalowane na hostach klastra, od jakiego są producenta, oraz który procesor na hostach jest najstarszy, aby w zależności od tego wykorzystać wszystkie dostępne instrukcje procesora w klastrze.
• Typ przełącznika – w naszym klastrze używamy tylko Linux bridge, dlatego to wybieramy.
• Typ zapory – wszystko jest jasne, to firewalld, który musi być włączony i skonfigurowany na hostach.

Zrzut ekranu z parametrami klastra

Instalacja dodatkowych hostów w środowisku Self-Hosted

Link w dokumentacji.

Dodatkowe hosty dla środowiska Self-Hosted dodawane są tak samo, jak zwykły host, z wykonaniem dodatkowego kroku dotyczącego wdrożenia VM z zainstalowanym silnikiem — Wybierz akcję wdrożenia z zainstalowanym silnikiem >> Wdróż. Dodatkowemu hostowi również musi być przedstawiony LUN dla VM z zainstalowanym silnikiem, co oznacza, że ten host można wykorzystać do umieszczania na nim VM z zainstalowanym silnikiem, jeśli zajdzie taka potrzeba.
W celu zapewnienia wysokiej dostępności zdecydowanie zaleca się posiadanie co najmniej dwóch hostów, na których można umieszczać VM z zainstalowanym silnikiem.

Na dodatkowym hoście wyłączamy iptables (jeśli jest włączony), włączamy firewalld

systemctl stop iptables
systemctl disable iptables

systemctl enable firewalld
systemctl start firewalld

Instalujemy wymaganą wersję KVM (jeżeli to konieczne):

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

Instalujemy potrzebne repozytoria oraz instalator zainstalowanego silnika:

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

Następnie przechodzimy do konsoli Open Virtualization Manager, dodajemy nowy host i wykonujemy wszystko krok po kroku, jak opisano w dokumentacji.

W rezultacie, po dodaniu dodatkowego hosta, powinniśmy uzyskać obraz w panelu administracyjnym, jak na zrzucie ekranu.

Zrzut ekranu panelu administracyjnego — hosty

Host, na którym VM z zainstalowanym silnikiem jest obecnie aktywna, ma złotą koronę i napis „Uruchamianie VM z zainstalowanym silnikiem”, host, na którym ta VM może być uruchomiona w razie potrzeby – napis „Może uruchomić VM z zainstalowanym silnikiem».

W przypadku awarii hosta, na którym „Uruchamianie VM z zainstalowanym silnikiem”, automatycznie uruchomi się na drugim hoście. Tę VM można również migrować z aktywnego hosta na rezerwowy, w celu jej konserwacji.

Konfiguracja zarządzania zasilaniem / fencing na hostach oVirt

Linki do dokumentacji:

• Red Hat Virtualization 4.3 –> Przewodnik techniczny -> Rozdział 4. Zarządzanie zasilaniem
• Przewodnik administracyjny oVirt -> Rozdział 7: Hosty

Chociaż może się wydawać, że dodanie i skonfigurowanie hosta zostało zakończone, to nie do końca prawda.
Aby zapewnić prawidłowe działanie hostów i identyfikację/rozwiązywanie problemów z którymkolwiek z nich, konieczna jest konfiguracja zarządzania zasilaniem/fencing.

Fencing, lub odizolowanie – to proces czasowego wyłączenia nieprawidłowego lub awaryjnego hosta z klastra, w trakcie którego uruchamiane są ponownie albo usługi oVirt na nim, albo sam host.

Wszystkie szczegóły dotyczące definicji i parametrów zarządzania zasilaniem / odizolowania znajdują się zwykle w dokumentacji, ja jedynie podam przykład, jak skonfigurować ten ważny parametr w odniesieniu do serwerów Dell R640 z iDRAC 9.

1. Wchodzimy do portalu administracyjnego, klikamy Obliczenia >> Hosts wybieramy hosta.
2. Klikamy Edit.
3. Klikamy zakładkę Power Management.
4. Zaznaczamy pole obok opcji Enable Power Management.
5. Zaznaczamy pole obok opcji Integracja Kdump, aby host nie przeszedł w tryb odizolowania (fencing) podczas zapisu awaryjnego zrzutu rdzenia.

Uwaga.

Po włączeniu integracji Kdump na już działającym hoście, musi on zostać przeinstalowany zgodnie z procedurą w oVirt Administration Guide -> Rozdział 7: Hosty -> Reinstalling Hosts.

1. Opcjonalnie można zaznaczyć pole Disable policy control of power management, jeśli nie chcemy, aby zarządzanie zasilaniem hosta było kontrolowane przez politykę planowania (Scheduling Policy) klastra.
2. Klikamy przycisk (+), aby dodać nowe urządzenie zarządzania zasilaniem, otworzy się okno edytowania właściwości agenta.
   Dla iDRAC9 wypełniamy pola:
   • Address – adres iDRAC9
   • User Name / Password – odpowiednio login i hasło do wejścia do iDRAC9
   • Type — drac5
   • zaznaczyć Secure
   • dodać następujące opcje: cmd_prompt=>,login_timeout=30

Zrzut ekranu z parametrami „Zarządzanie zasilaniem” w właściwościach hosta

Tworzenie obszarów przechowywania lub Storage Domains

Link do dokumentacji — oVirt Administration Guide, Chapter 8: Storage.

Storage Domain, lub obszar przechowywania – to scentralizowane miejsce do przechowywania dysków maszyn wirtualnych, obrazów instalacyjnych, szablonów i migawków.

Obszary przechowywania mogą być podłączone do centrum danych, wykorzystując różne protokoły, systemy plików klastrowych i sieciowych.

oVirt ma trzy typy obszarów przechowywania:

• Data Domain – do przechowywania wszystkich danych związanych z maszynami wirtualnymi (dyski, szablony). Data Domain nie może być współdzielona między różnymi centrami danych.
• ISO Domain (przestarzały typ obszaru przechowywania) – do przechowywania obrazów instalacyjnych systemu operacyjnego. ISO Domain może być współdzielona między różnymi centrami danych.
• Export Domain (przestarzały typ obszaru przechowywania) – do tymczasowego przechowywania obrazów przenoszonych między centrami danych.

W naszym przypadku obszar przechowywania typu Data Domain korzysta z protokołu Fibre Channel (FCP) w celu połączenia z LUN-ami na macierzy dyskowej.

Z perspektywy oVirt, przy użyciu pamięci masowej (FC lub iSCSI) każdy wirtualny dysk, migawka lub szablon to logiczny dysk.
Urządzenia blokowe są łączone w jedną całość (na hostach klastra) za pomocą Volume Group, a następnie dzielone za pomocą LVM na logiczne wolumeny używane jako wirtualne dyski dla VM.

Wszystkie te grupy i wiele wolumenów LVM można zobaczyć na hoście klastra za pomocą poleceń vgs i lvs. Oczywiście, że wszystkie operacje na takich dyskach należy wykonywać tylko z konsoli oVirt, z wyjątkiem szczególnych przypadków.

Wirtualne dyski dla VM mogą mieć dwa typy — QCOW2 lub RAW. Dyski mogą być "cienkie" lub "grube". Migawki zawsze są tworzone jako "cienkie".

". Metoda zarządzania domenami pamięci masowej, do których dostęp uzyskuje się przez FC, jest dość logiczna — dla każdego wirtualnego dysku VM istnieje oddzielny logiczny wolumen, który jest dostępny do zapisu tylko dla jednego hosta. W przypadku połączeń przez FC, oVirt korzysta z czegoś podobnego do klastrowego LVM.

Wirtualne maszyny znajdujące się w tej samej domenie pamięci masowej można migrować między hostami należącymi do tego samego klastra.

Jak widać z opisu, klaster w oVirt, podobnie jak klaster w VMware vSphere czy Hyper-V, oznacza w zasadzie to samo – jest to logiczna grupowanie hostów, najlepiej jednorodnych pod względem sprzętu, i posiadających wspólną pamięć do dysków wirtualnych maszyn.

Przejdźmy bezpośrednio do utworzenia domeny pamięci masowej dla danych (dysków VM), ponieważ bez niej centrum danych nie będzie zainicjalizowane.
Przypominam, że wszystkie LUNy prezentowane hostom klastra na pamięci masowej muszą być widoczne za pomocą polecenia „multipath -ll».

Zgodnie z dokumentacji, przechodzimy do portalu, wchodzimy w Pamięć >> Domeny -> Nowa Domen i wykonujemy instrukcje z sekcji "Dodawanie pamięci FCP".

Po uruchomieniu kreatora wypełniamy wymagane pola:

• Nazwa — ustalamy nazwę klastra
• Funkcja Domeny — Dane
• Typ Pamięci — Fibre Channel
• Host do Użycia — wybieramy host, na którym dostępny jest wymagany LUN

Na liście LUNów zaznaczamy odpowiedni, klikamy Dodaj i następnie OK. W razie potrzeby można skorygować dodatkowe parametry domeny pamięci, klikając na Zaawansowane Parametry.

Zrzut kreatora dodawania „domeny pamięci”

W wyniku działania kreatora powinniśmy otrzymać nową domenę pamięci, a nasze centrum danych powinno przejść do statusu UP, lub zainicjalizowano:

Zrzuty ekranu z centrum danych i obszarów przechowywania w nim:

Tworzenie i konfiguracja sieci dla maszyn wirtualnych

Link do dokumentacji — oVirt Administration Guide, Rozdział 6: Sieci logiczne

Sieci, czyli Networks, służą do grupowania logicznych sieci używanych w wirtualnej infrastrukturze oVirt.

Do interakcji między adapterem sieciowym na maszynie wirtualnej a fizycznym adapterem na hoście używane są logiczne interfejsy typu Linux bridge.

Aby grupować i dzielić ruch między sieciami, na przełącznikach skonfigurowano VLAN-y.

Przy tworzeniu logicznej sieci dla maszyn wirtualnych w oVirt należy przypisać identyfikator odpowiadający numerowi VLAN na przełączniku, aby VM mogły komunikować się ze sobą, nawet jeśli działają na różnych węzłach klastra.

Wstępne ustawienia adapterów sieciowych na hostach dla podłączenia maszyn wirtualnych musiały być wykonane w poprzedniej artykule – skonfigurowano interfejs logiczny bond1, następnie wszystkie ustawienia sieciowe powinny być realizowane wyłącznie przez portal administracyjny oVirt.

Po utworzeniu VM z hosted-engine, oprócz automatycznego tworzenia centrum danych i klastra, również automatycznie utworzono logiczną sieć do zarządzania naszym klastrem – ovritmgmt, do której podłączona była ta VM.

W razie potrzeby można sprawdzić ustawienia logicznej sieci ovritmgmt i skorygować je, ale należy być ostrożnym, aby nie stracić kontroli nad infrastrukturą oVirt.

Ustawienia logicznej sieci ovritmgmt

Aby utworzyć nową logiczną sieć dla zwykłych VM, w portalu administracyjnym przechodzimy do Sieć >> Sieci >> Nowe, a na karcie General dodajemy sieć z wymaganym identyfikatorem VLAN, a także zaznaczamy pole obok „Sieć VM”, co oznacza, że można ją używać do przypisania do VM.

Zrzut ekranu nowej logicznej sieci VLAN32

Na karcie Klaster, przypinamy tę sieć do naszego klastra Cluster1.

Po tym przechodzimy do Obliczenia >> Hosts, kolejno wchodzimy w każdy host, na kartę Interfejsy sieciowe, i uruchamiamy kreator Konfiguracja sieci hostów, aby powiązać nową logiczną sieć z hostami.

Zrzut ekranu kreatora „Konfiguracja sieci hostów”

Agent oVirt automatycznie wykona wszystkie niezbędne konfiguracje sieci na hoście – utworzy VLAN i BRIDGE.

Przykład plików konfiguracyjnych dla nowych sieci na hoście:

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

Przypominam, że na hoście klastra NIE TRZEBA wcześniej ręcznie tworzyć interfejsów sieciowych ifcfg-bond1.432 i ifcfg-ovirtvm-vlan432.

Po dodaniu sieci logicznej i sprawdzeniu połączenia między hostem a VM z hosted engine, można ją wykorzystać w maszynie wirtualnej.

Tworzenie obrazu instalacyjnego do wdrożenia maszyny wirtualnej

Link do dokumentacji — oVirt Administration Guide, Chapter 8: Storage, sekcja Przesyłanie obrazów do domeny pamięci danych.

Bez obrazu instalacyjnego systemu operacyjnego nie uda się zainstalować maszyny wirtualnej, chociaż nie stanowi to problemu, jeśli w sieci jest zainstalowany, na przykład, Cobbler z wcześniej utworzonymi obrazami.

W naszym przypadku taka możliwość nie istnieje, więc będziemy musieli samodzielnie zaimportować ten obraz do oVirt. Wcześniej wymagało to utworzenia ISO Domain, ale w nowej wersji oVirt zostało to uznane za przestarzałe, więc teraz można przesyłać obrazy bezpośrednio do domeny pamięci z portalu administracyjnego.

W portalu administracyjnym przechodzimy do Pamięć >> Dyski >> Prześlij >> Rozpocznij
Dodajemy nasz obraz systemu operacyjnego w formie pliku ISO, w formularzu wypełniamy wszystkie pola i klikamy przycisk "Testuj połączenie".

Zrzut ekranu kreatora dodawania obrazu instalacyjnego

Jeśli otrzymamy błąd w takiej postaci:

Nie można przesłać obrazu do dysku d6d8fd10-c1e0-4f2d-af15-90f8e636dadc z powodu błędu sieciowego. Upewnij się, że usługa ovirt-imageio-proxy jest zainstalowana i skonfigurowana oraz że certyfikat CA ovirt-engine jest zarejestrowany jako zaufany CA w przeglądarce. Certyfikat można pobrać z https://ovirt.test.local/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA

Należy dodać certyfikat oVirt do „Zaufane korzenne CA” (Trusted Root CA) na stacji zarządzającej administratorem, z której próbujemy przesłać obraz.

Po dodaniu certyfikatu do Trusted Root CA, ponownie klikamy "Testuj połączenie", powinniśmy otrzymać:

Połączenie z ovirt-imageio-proxy powiodło się.

Wykonując czynność dodawania certyfikatu, możemy spróbować ponownie przesłać obraz ISO do domeny pamięci.

Można utworzyć osobną domenę pamięci typu Data do przechowywania obrazów i szablonów oddzielnie od dysków VM, lub nawet przechowywać je w domenie pamięci dla hosted engine, ale to już pozostaje w gestii administratora.

Zrzut ekranu z obrazami ISO w domenie pamięci dla hosted engine

Tworzenie maszyny wirtualnej

Link do dokumentacji:
Przewodnik po zarządzaniu maszynami wirtualnymi oVirt –> Rozdział 2: Instalacja wirtualnych maszyn Linux
Zasoby klientów konsoli

Po załadowaniu obrazu instalacyjnego systemu operacyjnego do oVirt, można przejść bezpośrednio do tworzenia maszyny wirtualnej. Wykonano dużo pracy, ale jesteśmy już na ostatnim etapie, dla którego wszystko to zostało zaplanowane - uzyskanie infrastruktury odpornej na awarie do hostingu wysoko dostępnych maszyn wirtualnych. I co najważniejsze, wszystko to jest całkowicie za darmo - nie wydano ani grosza na zakup jakichkolwiek licencji na oprogramowanie.

Aby stworzyć maszynę wirtualną z CentOS 7, należy załadować obraz instalacyjny systemu operacyjnego.

Wchodzimy do portalu administracyjnego, przechodzimy do Obliczenia >> Maszyn Wirtualnych, a następnie uruchamiamy kreator tworzenia VM. Wypełniamy wszystkie parametry i pola, a następnie klikamy OK. To naprawdę proste, jeśli postępuje się zgodnie z dokumentacją.

Jako przykład podam główne i dodatkowe ustawienia wysoko dostępnej VM, z utworzonym dyskiem, podłączoną do sieci, oraz z bootowaniem z obrazu instalacyjnego:

Zrzuty ekranu z ustawieniami wysoko dostępnej VM

Po zakończeniu pracy z kreatorem, zamykamy go, uruchamiamy nową VM i instalujemy na niej system operacyjny.
W tym celu wchodzimy do konsoli tej VM przez portal administracyjny:

Zrzut ekranu ustawień portalu administracyjnego do połączenia z konsolą VM

Aby połączyć się z konsolą VM, należy najpierw skonfigurować konsolę w właściwościach maszyny wirtualnej.

Zrzut ekranu ustawień VM, zakładka „Konsola”

Do połączenia z konsolą VM można na przykład użyć Virtual Machine Viewer.

Aby połączyć się z konsolą VM bezpośrednio w oknie przeglądarki, ustawienia połączenia przez konsolę powinny być następujące:

Po zainstalowaniu systemu operacyjnego na VM, wskazane jest zainstalowanie agenta gościa 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

W ten sposób, w wyniku naszych działań, utworzona VM będzie wysoko dostępna, tzn. w przypadku awarii węzła klastra, na którym jest uruchomiona, oVirt automatycznie zrestartuje ją na drugim węźle. Tę VM można również migrować między hostami klastra w celu ich konserwacji lub inny cel.

Podsumowanie

Mam nadzieję, że dzięki temu artykułowi udało się przekazać, że oVirt to całkiem normalne narzędzie do zarządzania infrastrukturą wirtualną, które można zainstalować dość łatwo — najważniejsze to przestrzegać określonych zasad i wymagań opisanych zarówno w artykule, jak i w dokumentacji.

Ze względu na dużą objętość artykułu nie udało się umieścić wielu rzeczy, jak krok po kroku wykonanie różnych kreatorów ze wszystkimi szczegółowymi wyjaśnieniami i zrzutami ekranu, długie wyniki niektórych poleceń itp. W rzeczywistości wymagałoby to napisania całej książki, co nie ma większego sensu ze względu na ciągłe pojawianie się nowych wersji oprogramowania z nowościami i zmianami. Najważniejsze jest to, aby zrozumieć zasady, jak wszystko razem działa i uzyskać ogólny algorytm działania w celu stworzenia stabilnej platformy do zarządzania maszynami wirtualnymi.

Chociaż stworzyliśmy infrastrukturę wirtualną, musimy teraz nauczyć ją współdziałać zarówno pomiędzy jej poszczególnymi elementami: hostami, maszynami wirtualnymi, wewnętrznymi sieciami, jak i ze światem zewnętrznym.

Ten proces jest jednym z podstawowych zadań administratora systemów lub sieci, które zostaną omówione w następnym artykule - o użyciu wirtualnych routerów VyOS w stabilnej infrastrukturze naszej firmy (jak się domyślacie, będą działały jako maszyny wirtualne w naszym klastrze oVirt).

Źródło: habr.com