🥇Stworzenie odpornej na awarie infrastruktury IT. Część 2. Instalacja i konfiguracja klastra oVirt 4.3

Ten artykuł jest kontynuacją poprzedniego - „Stworzenie odpornej na awarie infrastruktury IT. Część 1 - przygotowanie do wdrożenia klastra oVirt 4.3".

Obejmie proces podstawowej instalacji i konfiguracji klastra oVirt 4.3 do hostowania maszyn wirtualnych o wysokiej dostępności, biorąc pod uwagę fakt, że wszystkie wstępne etapy przygotowania infrastruktury zostały już wcześniej wykonane.

Część wprowadzająca

Głównym celem artykułu jest przedstawienie instrukcji krok po kroku, takich jak „Następna -> Tak -> koniec„jak wyświetlić niektóre funkcje podczas instalacji i konfiguracji. Proces wdrażania Twojego klastra może nie zawsze pokrywać się z opisanym w nim, ze względu na charakterystykę infrastruktury i środowiska, ale ogólne zasady będą takie same.

Z subiektywnego punktu widzenia, oVirt 4.3 jego funkcjonalność jest podobna do VMware vSphere w wersji 5.x, ale oczywiście z własnymi funkcjami konfiguracyjnymi i operacyjnymi.

Dla zainteresowanych wszystkie różnice pomiędzy RHEV (aka oVirt) a VMware vSphere można znaleźć w Internecie np. tutaj, ale w miarę postępu artykułu od czasu do czasu będę odnotowywał pewne różnice lub podobieństwa między nimi.

Osobno chciałbym trochę porównać pracę z sieciami dla maszyn wirtualnych. oVirt realizuje podobną zasadę zarządzania siecią dla maszyn wirtualnych (zwanych dalej VM), jak w VMware vSphere:

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

Należy zaznaczyć, że ze względu na łatwość wdrożenia, w artykule zostanie opisane konfigurowanie sieci w oVirt dla VM przy użyciu standardowego Linux Bridge, co jest standardowym wyborem w przypadku korzystania z hypervisora KVM.

W związku z tym istnieje kilka podstawowych zasad pracy z siecią w klastrze, których najlepiej nie naruszać:

Wszystkie ustawienia sieciowe na hostach przed dodaniem ich do oVirt muszą być identyczne, z wyjątkiem adresów IP.
Gdy host zostanie przejęty przez oVirt, zdecydowanie nie zaleca się ręcznej zmiany czegokolwiek w ustawieniach sieciowych bez całkowitego zaufania do swoich działań, ponieważ agent oVirt po prostu przywróci je do poprzednich po ponownym uruchomieniu hosta lub agent.
Dodawanie nowej sieci dla maszyny wirtualnej oraz praca z nią powinna odbywać się wyłącznie z poziomu konsoli zarządzania oVirt.

Inne ważna uwaga — w bardzo krytycznym środowisku (bardzo wrażliwym na straty pieniężne) nadal zaleca się korzystanie z płatnego wsparcia i użytkowania Wirtualizacja Red Hata 4.3. W trakcie działania klastra oVirt mogą pojawić się pewne problemy, w przypadku których wskazane jest jak najszybsze skorzystanie z wykwalifikowanej pomocy, zamiast zajmować się nimi samodzielnie.

I wreszcie zalecane Przed wdrożeniem klastra oVirt zapoznaj się z oficjalna dokumentacja, aby znać przynajmniej podstawowe pojęcia i definicje, w przeciwnym razie przeczytanie dalszej części artykułu będzie trochę trudne.

Podstawą zrozumienia artykułu i zasad działania klastra oVirt są poniższe wytyczne:

Objętość nie jest zbyt duża, w ciągu godziny lub dwóch można całkiem opanować podstawowe zasady, ale tym, którzy lubią szczegóły, zaleca się przeczytanie Dokumentacja produktu dotycząca wirtualizacji Red Hat 4.3 — RHEV i oVirt to zasadniczo to samo.

Tak więc, jeśli wszystkie podstawowe ustawienia hostów, przełączników i systemów pamięci masowej zostały zakończone, przystępujemy bezpośrednio do wdrożenia oVirt.

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

Dla ułatwienia orientacji wymienię główne sekcje tego artykułu, które należy wypełnić jedna po drugiej:

Instalowanie serwera zarządzania oVirt
Utworzenie nowego centrum danych
Tworzenie nowego klastra
Instalowanie dodatkowych hostów w środowisku hostowanym samodzielnie
Tworzenie obszaru przechowywania lub domen przechowywania
Tworzenie i konfiguracja sieci dla maszyn wirtualnych
Tworzenie obrazu instalacyjnego do wdrożenia maszyny wirtualnej
Utwórz maszynę wirtualną

Instalowanie serwera zarządzania oVirt

Serwer zarządzania oVirt to najważniejszy element infrastruktury oVirt w postaci maszyny wirtualnej, hosta lub urządzenia wirtualnego zarządzającego całą infrastrukturą oVirt.

Jego bliskimi odpowiednikami ze świata wirtualizacji są:

VMware vSphere – serwer vCenter
Microsoft Hyper-V — Menedżer maszyn wirtualnych System Center (VMM).

Aby zainstalować serwer zarządzający oVirt, mamy dwie możliwości:

opcja 1
Wdrożenie serwera w postaci wyspecjalizowanej maszyny wirtualnej lub hosta.

Opcja ta sprawdza się całkiem nieźle, jednak pod warunkiem, że taka VM działa niezależnie od klastra, tj. nie działa na żadnym hoście klastra jako zwykła maszyna wirtualna z systemem KVM.

Dlaczego takiej maszyny wirtualnej nie można wdrożyć na hostach klastra?

Już na samym początku procesu wdrażania serwera zarządzającego oVirt mamy dylemat – musimy zainstalować zarządzającą VM, ale tak naprawdę nie ma jeszcze samego klastra, a zatem co możemy wymyślić na bieżąco? Zgadza się – zainstaluj KVM na przyszłym węźle klastra, następnie utwórz na nim maszynę wirtualną np. z CentOS OS i wdróż w niej silnik oVirt. Zwykle można to zrobić ze względu na pełną kontrolę nad taką maszyną wirtualną, ale jest to błędny zamiar, ponieważ w tym przypadku w przyszłości na 100% będą problemy z taką sterującą maszyną wirtualną:

nie można go migrować w konsoli oVirt pomiędzy hostami (węzłami) klastra;
podczas migracji przy użyciu KVM przez virsh migruje, ta maszyna wirtualna nie będzie dostępna do zarządzania z konsoli oVirt.
nie można wyświetlić hostów klastra Tryb konserwacji (tryb konserwacji), jeśli migrujesz tę maszynę wirtualną z hosta na host za pomocą virsh migruje.

Zrób więc wszystko zgodnie z zasadami - użyj albo osobnego hosta dla serwera zarządzającego oVirt, albo działającej na nim niezależnej maszyny wirtualnej, albo jeszcze lepiej postępuj tak, jak napisano w drugiej opcji.

opcja 2
Instalowanie urządzenia oVirt Engine na zarządzanym przez nie hoście klastra.

To właśnie ta opcja będzie dalej uważana za bardziej poprawną i odpowiednią w naszym przypadku.
Wymagania dla takiej VM opisano poniżej, dodam tylko, że w infrastrukturze, na której można uruchomić sterującą VM, zaleca się posiadanie co najmniej dwóch hostów, aby była ona odporna na awarie. Tutaj dodam, że jak już pisałam w komentarzach w poprzednim artykule, nigdy nie udało mi się tego uzyskać rozdwojony mózg w klastrze oVirt składającym się z dwóch hostów, z możliwością uruchamiania na nich maszyn wirtualnych z hostowanym silnikiem.

Instalowanie urządzenia oVirt Engine na pierwszym hoście klastra

Link do oficjalnej dokumentacji - Przewodnik po silniku hostowanym samodzielnie przez Virt, rozdział "Wdrażanie silnika hostowanego samodzielnie przy użyciu wiersza poleceń»

Dokument określa wymagania wstępne, jakie należy spełnić przed wdrożeniem maszyny wirtualnej z hostowanym silnikiem, a także szczegółowo opisuje sam proces instalacji, więc nie ma sensu powtarzać go dosłownie, dlatego skupimy się na kilku ważnych szczegółach.

Przed rozpoczęciem wszystkich działań pamiętaj o włączeniu obsługi wirtualizacji w ustawieniach BIOS-u na hoście.
Zainstaluj pakiet instalatora hostowanego silnika na hoście:

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

Procedurę wdrażania oVirt Hosted Engine rozpoczynamy na ekranie na hoście (można z niej wyjść Ctrl-A + D, zamknąć Ctrl-D):

screen
hosted-engine --deploy

Jeśli chcesz, możesz 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 hostowanego silnika określamy wszystkie niezbędne parametry:

- имя кластера
- количество vCPU и vRAM (рекомендуется 4 vCPU и 16 Гб)
- пароли
- тип хранилища для hosted engine ВМ – в нашем случае FC
- номер LUN для установки hosted engine
- где будет находиться база данных для hosted engine – рекомендую для простоты выбрать Local (это БД PostgreSQL работающая внутри этой ВМ)
и др. параметры.

Aby zainstalować wysoce dostępną maszynę wirtualną z hostowanym silnikiem, wcześniej utworzyliśmy specjalną jednostkę LUN w systemie pamięci masowej o rozmiarze 4 i 150 GB, która następnie została przedstawiona hostom klastra - patrz Poprzedni artykuł.

Wcześniej sprawdziliśmy także 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 wdrożenia hostowanego silnika nie jest skomplikowany, na koniec powinniśmy otrzymać coś takiego:

[ 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 użyj przeglądarki internetowej, aby przejść do https://ovirt_hostname/ovirt-engine z komputera administratora i kliknij [Portalu Administracyjnym].

Zrzut ekranu „Portalu administracyjnego”

Wpisując login i hasło (ustawione podczas instalacji) w oknie jak na zrzucie ekranu, trafiamy do panelu sterowania Open Virtualization Manager, w którym można wykonać wszystkie czynności z infrastrukturą wirtualną:

dodaj centrum danych
dodaj i skonfiguruj klaster
dodawaj hosty i zarządzaj nimi
dodaj obszary pamięci lub domeny pamięci masowej dla dysków maszyn wirtualnych
dodawać i konfigurować sieci dla maszyn wirtualnych
dodawaj i zarządzaj maszynami wirtualnymi, obrazami instalacyjnymi, szablonami maszyn wirtualnych

Wszystkie te działania zostaną omówione dalej, niektóre w dużych komórkach, inne bardziej szczegółowo i z niuansami.
Na początek jednak polecam przeczytać ten dodatek, który zapewne wielu osobom się przyda.

Dodatek

1) W zasadzie, jeśli jest taka potrzeba, nic nie stoi na przeszkodzie, aby wcześniej zainstalować hiperwizora KVM na węzłach klastra za pomocą pakietów libvirt и qemu-sq.m (or qemu-kvm-ev) żądanej wersji, chociaż podczas wdrażania węzła klastra oVirt może to zrobić sam.

Ale jeśli libvirt и qemu-sq.m Jeśli nie zainstalowałeś najnowszej wersji, podczas wdrażania hostowanego silnika może pojawić się następujący błąd:

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

Te. muszę mieć zaktualizowana wersja libvirt z ochroną przed MDS, który wspiera tę politykę:

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

Zainstaluj bibliotekę 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

Sprawdź obsługę „md-clear”:

virsh domcapabilities kvm | grep require
      <feature policy='require' name='ss'/>
      <feature policy='require' name='hypervisor'/>
      <feature policy='require' name='tsc_adjust'/>
      <feature policy='require' name='clflushopt'/>
      <feature policy='require' name='pku'/>
      <feature policy='require' name='md-clear'/>
      <feature policy='require' name='stibp'/>
      <feature policy='require' name='ssbd'/>
      <feature policy='require' name='invtsc'/>

Następnie możesz kontynuować instalację hostowanego silnika.

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

Jeśli podczas wdrażania maszyny wirtualnej dla hostowanego silnika pojawi się następujący 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

Następnie musisz wyłączyć inną zaporę ogniową (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

Później, podczas instalowania agenta ovirt na nowym hoście klastra, skonfiguruje on wymagane porty firewalld automatycznie.

3) Ponowne uruchamianie hosta z uruchomioną maszyną wirtualną z hostowanym silnikiem.

Zwykle Łącze 1 и Łącze 2 do dokumentów rządzących.

Całe zarządzanie hostowaną maszyną wirtualną silnika odbywa się TYLKO za pomocą polecenia silnik hostowany na hoście, na którym działa, około Virsh musimy zapomnieć, a także fakt, że możesz połączyć się z tą maszyną wirtualną przez SSH i uruchomić polecenie „zamknięcie".

Procedura wprowadzania maszyny wirtualnej w tryb konserwacji:

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

hosted-engine --vm-status
!! Cluster is in GLOBAL MAINTENANCE mode !!
--== 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                              : dee1a774
local_conf_timestamp               : 1821
Host timestamp                     : 1821
Extra metadata (valid at timestamp):
        metadata_parse_version=1
        metadata_feature_version=1
        timestamp=1821 (Sat Nov 29 14:25:19 2019)
        host-id=1
        score=3400
        vm_conf_refresh_time=1821 (Sat Nov 29 14:25:19 2019)
        conf_on_shared_storage=True
        maintenance=False
        state=GlobalMaintenance
        stopped=False

hosted-engine --vm-shutdown

Ponownie uruchamiamy hosta za pomocą hostowanego agenta silnika i robimy z nim, co potrzebujemy.

Po ponownym uruchomieniu sprawdź stan maszyny wirtualnej za pomocą hostowanego silnika:

hosted-engine --vm-status

Jeśli nasza maszyna wirtualna z hostowanym silnikiem nie uruchamia się i jeśli widzimy podobne błędy w dzienniku usługi:

Błąd w dzienniku serwisowym:

journalctl -u ovirt-ha-agent
...
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine ERROR Failed to start necessary monitors
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent ERROR Traceback (most recent call last):#012  File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", line 131, in _run_agent#012    return action(he)#012  File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", line 55, in action_proper#012    return he.start_monitoring()#012  File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py", line 413, in start_monitoring#012    self._initialize_broker()#012  File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py", line 537, in _initialize_broker#012    m.get('options', {}))#012  File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py", line 86, in start_monitor#012    ).format(t=type, o=options, e=e)#012RequestError: brokerlink - failed to start monitor via ovirt-ha-broker: [Errno 2] No such file or directory, [monitor: 'ping', options: {'addr': '172.20.32.32'}]
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent ERROR Trying to restart agent

Następnie 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 hostowanym silnikiem wychodzimy z trybu konserwacji:

Procedura usuwania 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) Usuwanie hostowanego silnika i wszystkiego, co z nim związane.

Czasami konieczne jest prawidłowe usunięcie wcześniej zainstalowanego silnika hostowanego - łącze do dokumentu zawierającego wytyczne.

Po prostu uruchom polecenie na hoście:

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

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

yum autoremove ovirt* qemu* virt* libvirt* libguestfs

Utworzenie nowego centrum danych

Dokumentacja referencyjna — Przewodnik administracyjny oVirt. Rozdział 4: Centra danych

Najpierw zdefiniujmy, co to jest Centrum danych (cytuję z pomocy) to jednostka logiczna określająca zbiór zasobów wykorzystywanych w konkretnym środowisku.

Centrum danych to rodzaj kontenera składającego się z:

zasoby logiczne w postaci klastrów i hostów
zasoby sieciowe klastra w postaci sieci logicznych i adapterów fizycznych na hostach,
zasoby pamięci masowej (dla dysków VM, szablonów, obrazów) w postaci obszarów pamięci (Storage Domains).

Centrum danych może obejmować wiele klastrów składających się z wielu hostów z uruchomionymi na nich maszynami wirtualnymi, a także może mieć powiązanych z nim wiele obszarów pamięci masowej.
Centrów danych może być kilka, działają one niezależnie od siebie. Ovirt posiada rozdział uprawnień ze względu na rolę, a uprawnienia można konfigurować indywidualnie, zarówno na poziomie centrum danych, jak i na jego poszczególnych elementach logicznych.

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

Aby utworzyć centrum danych, przejdź do portalu administracyjnego i utwórz nowe centrum danych:
obliczać >> Centra przetwarzania danych >> Nowości

Ponieważ w systemie pamięci masowej używamy pamięci współdzielonej, typ pamięci powinien mieć wartość Współdzielony:

Zrzut ekranu przedstawiający Kreatora tworzenia centrum danych

Podczas instalowania maszyny wirtualnej z silnikiem hostowanym domyślnie tworzone jest centrum danych - Centrum danych1, a następnie, jeśli to konieczne, możesz zmienić jego Typ przechowywania na inny.

Utworzenie centrum danych jest prostym zadaniem, bez żadnych skomplikowanych niuansów, a wszystkie dodatkowe działania z nim związane są opisane w dokumentacji. Jedyne na co zwrócę uwagę to to, że pojedyncze hosty, które mają tylko lokalną pamięć masową (dysk) dla maszyn wirtualnych, nie będą mogły dostać się do centrum danych z typem przechowywania - współdzielone (nie można ich tam dodać) i dla nich trzeba utworzyć oddzielne centrum danych – tj. Każdy indywidualny host z lokalną pamięcią masową potrzebuje własnego, oddzielnego centrum danych.

Tworzenie nowego klastra

Link do dokumentacji - Przewodnik administracyjny oVirt. Rozdział 5: Klastry

Bez zbędnych szczegółów, grupa – jest to logiczne zgrupowanie hostów, które mają wspólny obszar przechowywania (w postaci współdzielonych dysków w systemie przechowywania, jak w naszym przypadku). Pożądane jest również, aby hosty w klastrze były identyczne pod względem sprzętowym i miały ten sam typ procesora (Intel lub AMD). Najlepiej oczywiście, żeby serwery w klastrze były całkowicie identyczne.

Klaster jest częścią centrum danych (z określonym typem pamięci masowej - miejscowy lub wspólne), a wszystkie hosty muszą należeć do pewnego rodzaju klastra, w zależności od tego, czy mają wspólną pamięć, czy nie.

Podczas instalowania maszyny wirtualnej z silnikiem hostowanym na hoście domyślnie tworzone jest centrum danych - Centrum danych1wraz z klastrem – Klaster1, a w przyszłości będziesz mógł konfigurować jego parametry, włączać dodatkowe opcje, dodawać do niego hosty itp.

Jak zwykle, aby uzyskać szczegółowe informacje na temat wszystkich ustawień klastra, warto zapoznać się z oficjalną dokumentacją. Z niektórych funkcji konfigurowania klastra dodam tylko, że przy jego tworzeniu wystarczy skonfigurować tylko podstawowe parametry na zakładce Ogólne.

Zwrócę uwagę na najważniejsze parametry:

Typ procesora — jest wybierany na podstawie tego, jakie procesory są zainstalowane na hostach klastra, jakiego producenta są i który procesor na hostach jest najstarszy, tak aby w zależności od tego wykorzystane zostały wszystkie dostępne instrukcje procesorowe w klastrze.
Typ przełącznika – w naszym klastrze korzystamy wyłącznie z mostu linuksowego, dlatego go wybieramy.
Typ zapory sieciowej – tutaj wszystko jest jasne, jest to firewall, który należy włączyć i skonfigurować na hostach.

Zrzut ekranu z parametrami klastra

Instalowanie dodatkowych hostów w środowisku hostowanym samodzielnie

Połączenie dla dokumentacji.

Dodatkowe hosty dla środowiska Self-Hosted są dodawane w taki sam sposób, jak zwykły host, z dodatkowym krokiem polegającym na wdrożeniu maszyny wirtualnej z silnikiem hostowanym — Wybierz akcję wdrożenia hostowanego silnika >> Rozmieścić. Ponieważ dodatkowy host musi także posiadać jednostkę LUN dla maszyny wirtualnej z hostowanym silnikiem, oznacza to, że tego hosta można w razie potrzeby używać do hostowania maszyny wirtualnej z hostowanym silnikiem.
Ze względu na odporność na awarie zdecydowanie zaleca się, aby istniały co najmniej dwa hosty, na których można umieścić maszynę wirtualną hostowanego silnika.

Na dodatkowym hoście wyłącz iptables (jeśli włączone), włącz firewalld

systemctl stop iptables
systemctl disable iptables

systemctl enable firewalld
systemctl start firewalld

Zainstaluj wymaganą wersję KVM (jeśli 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

Zainstaluj niezbędne repozytoria i instalator hostowanego 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 przejdź do konsoli Otwórz Menedżera wirtualizacji, dodaj nowego hosta i wykonaj wszystko krok po kroku tak jak napisano dokumentacja.

W rezultacie po dodaniu dodatkowego hosta powinniśmy otrzymać coś takiego jak na obrazku w konsoli administracyjnej, jak na zrzucie ekranu.

Zrzut ekranu portalu administracyjnego - hosty

Host, na którym aktualnie aktywna jest maszyna wirtualna z hostowanym silnikiem, ma złotą koronę i napis „Uruchamianie maszyny wirtualnej hostowanego silnika„, host, na którym w razie potrzeby można uruchomić tę maszynę wirtualną – napis „Można uruchomić maszynę wirtualną Hosted Engine".

W przypadku awarii hosta, na którym „Uruchamianie maszyny wirtualnej hostowanego silnika", automatycznie uruchomi się ponownie na drugim hoście. Tę maszynę wirtualną można również migrować z aktywnego hosta do hosta rezerwowego w celu jej konserwacji.

Konfigurowanie zarządzania energią/ogrodzenia na hostach oVirt

Linki do dokumentacji:

Red Hat Virtualization 4.3 –> Informacje techniczne -> Rozdział 4. Zarządzanie energią
oVirt Przewodnik administracyjny -> Rozdział 7: Gospodarze

Choć może się wydawać, że dodawanie i konfigurowanie hosta zostało już zakończone, nie jest to do końca prawdą.
Do normalnego działania hostów oraz do identyfikowania/rozwiązywania awarii któregokolwiek z nich wymagane są ustawienia zarządzania energią/ogrodzenia.

Ogrodzenialub ogrodzenie to proces tymczasowego wykluczenia wadliwego lub uszkodzonego hosta z klastra, podczas którego albo usługi oVirt na nim, albo sam host są ponownie uruchamiane.

Wszystkie szczegóły dotyczące definicji i parametrów Power Management/ogrodzenia podano jak zwykle w dokumentacji, podam jedynie przykład konfiguracji tego ważnego parametru, w odniesieniu do serwerów Dell R640 z iDRAC 9.

Przejdź do portalu administracyjnego, kliknij obliczać >> Zastępy niebieskie wybierz gospodarza.
Kliknij Edytuj.
Kliknij kartę Zarządzanie energią.
Zaznacz pole obok opcji Włącz zarządzanie energią.
Zaznacz pole obok opcji Integracja z Kdumpemaby uniemożliwić hostowi przejście w tryb ogrodzenia podczas nagrywania zrzutu awaryjnego jądra.

Uwaga.

Po włączeniu integracji Kdump na już działającym hoście należy go ponownie zainstalować zgodnie z procedurą opisaną w Przewodniku administracyjnym oVirt -> Rozdział 7: Gospodarze -> Ponowna instalacja hostów.

Opcjonalnie możesz zaznaczyć to pole Wyłącz kontrolę zasad zarządzania energią, jeśli nie chcemy, aby zarządzanie energią hosta było kontrolowane przez zasady planowania klastra.
Naciśnij przycisk (+), aby dodać nowe urządzenie zarządzające energią, otworzy się okno edycji właściwości agenta.
W przypadku kontrolera iDRAC9 wypełnij pola:
- Adres – Adres iDRAC9
- Nazwa użytkownika Hasło – odpowiednio login i hasło do logowania do kontrolera iDRAC9
- Rodzaj Nieruchomości —drac5
- znak Zabezpieczać
- dodaj następujące opcje: cmd_prompt=>,login_timeout=30

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

Tworzenie obszaru przechowywania lub domen przechowywania

Link do dokumentacji - Przewodnik administracyjny oVirt, Rozdział 8: Przechowywanie.

Domena magazynulub obszar przechowywania to scentralizowana lokalizacja do przechowywania dysków maszyn wirtualnych, obrazów instalacyjnych, szablonów i migawek.

Obszary pamięci masowej można podłączyć do centrum danych przy użyciu różnych protokołów, klastrów i sieciowych systemów plików.

oVirt oferuje trzy rodzaje powierzchni magazynowych:

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

W naszym konkretnym przypadku obszar pamięci masowej typu Data Domain wykorzystuje protokół Fibre Channel (FCP) do łączenia się z jednostkami LUN w systemie pamięci masowej.

Z punktu widzenia oVirt, w przypadku korzystania z systemów pamięci masowej (FC lub iSCSI), każdy dysk wirtualny, migawka lub szablon jest dyskiem logicznym.
Urządzenia blokowe są łączone w jedną jednostkę (na hostach klastra) przy użyciu grupy woluminów, a następnie dzielone przy użyciu LVM na woluminy logiczne, które służą jako dyski wirtualne dla maszyn wirtualnych.

Wszystkie te grupy i wiele woluminów LVM można zobaczyć na hoście klastra za pomocą poleceń bdb и lv. Oczywiście wszelkie działania na takich dyskach należy wykonywać wyłącznie z poziomu konsoli oVirt, poza wyjątkowymi przypadkami.

Dyski wirtualne dla maszyn wirtualnych mogą być dwojakiego rodzaju - QCOW2 lub RAW. Płyty mogą być „cienki" lub "gruby„. Zrzuty ekranu są zawsze tworzone jako „cienki".

Sposób zarządzania domenami pamięci masowej, czyli obszarami pamięci masowej, do których uzyskuje się dostęp za pośrednictwem FC, jest całkiem logiczny — dla każdego dysku wirtualnego maszyny wirtualnej istnieje oddzielny wolumin logiczny, który może zapisywać tylko jeden host. W przypadku połączeń FC oVirt używa czegoś w rodzaju klastrowego LVM.

Maszyny wirtualne znajdujące się w tym samym obszarze pamięci masowej można migrować pomiędzy hostami należącymi do tego samego klastra.

Jak widać z opisu klaster w oVirt, podobnie jak klaster w VMware vSphere czy Hyper-V, w zasadzie oznacza to samo - jest to logiczne zgrupowanie hostów, najlepiej identyczne pod względem składu sprzętowego i posiadające wspólną pamięć masową dla wirtualnych dyski maszynowe.

Przejdźmy bezpośrednio do utworzenia obszaru przechowywania danych (dysków wirtualnych), ponieważ bez niego centrum danych nie zostanie zainicjowane.
Przypominam, że wszystkie jednostki LUN prezentowane hostom klastra w systemie pamięci masowej muszą być na nich widoczne za pomocą polecenia „wielościeżkowy -ll".

Według dokumentacja, przejdź do portalu przejdź do Magazynowanie >> domeny -> Nowa domena i postępuj zgodnie z instrukcjami z sekcji „Dodawanie pamięci FCP”.

Po uruchomieniu kreatora wypełnij wymagane pola:

Imię — ustaw nazwę klastra
Funkcja domeny -Dane
Typ składowania — Fibre Channel
Host do użycia — wybierz hosta, na którym dostępna jest wymagana przez nas jednostka LUN

Na liście jednostek LUN zaznacz tę, której potrzebujemy, kliknij Dodaj i wtedy ОК. W razie potrzeby możesz dostosować dodatkowe parametry powierzchni magazynowej klikając Zaawansowane parametry.

Zrzut ekranu kreatora dodawania „domeny pamięci masowej”

Bazując na wynikach kreatora powinniśmy otrzymać nową powierzchnię magazynową, a nasze centrum danych powinno przejść do stanu UPlub zainicjowany:

Zrzuty ekranu centrum danych i znajdujących się w nim obszarów przechowywania:

Tworzenie i konfiguracja sieci dla maszyn wirtualnych

Link do dokumentacji - Przewodnik administracyjny oVirt, Rozdział 6: Sieci logiczne

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

Do interakcji pomiędzy kartą sieciową na maszynie wirtualnej a adapterem fizycznym na hoście używane są interfejsy logiczne, takie jak most Linux.

Aby grupować i dzielić ruch pomiędzy sieciami, na przełącznikach konfiguruje się sieci VLAN.

Tworząc sieć logiczną dla maszyn wirtualnych w oVirt należy nadać jej identyfikator odpowiadający numerowi VLAN na przełączniku, aby maszyny wirtualne mogły się ze sobą komunikować, nawet jeśli działają na różnych węzłach klastra.

Należało dokonać wstępnych ustawień kart sieciowych na hostach w celu podłączenia maszyn wirtualnych Poprzedni artykuł – skonfigurowany interfejs logiczny bond1, wówczas wszelkich ustawień sieciowych należy dokonać wyłącznie poprzez portal administracyjny oVirt.

Po utworzeniu maszyny wirtualnej z hostowanym silnikiem, oprócz automatycznego utworzenia centrum danych i klastra, automatycznie utworzono także sieć logiczną do zarządzania naszym klastrem - ovitmgmt, z którym ta maszyna wirtualna była połączona.

W razie potrzeby można wyświetlić ustawienia sieci logicznej ovitmgmt i dostosuj je, ale musisz uważać, aby nie stracić kontroli nad infrastrukturą oVirt.

Ustawienia sieci logicznej ovritmgmt

Aby utworzyć nową sieć logiczną dla zwykłych maszyn wirtualnych, w portalu administracyjnym przejdź do Sieć >> sieci >> Nowościi na zakładce Ogólne dodaj sieć o żądanym identyfikatorze VLAN, a także zaznacz pole obok „Sieć maszyn wirtualnych", oznacza to, że można go użyć do przypisania do maszyny wirtualnej.

Zrzut ekranu nowej sieci logicznej VLAN32

W zakładce Grupa, dołączamy tę sieć do naszego klastra Klaster1.

Po tym idziemy do obliczać >> Zastępy niebieskie, przejdź po kolei do każdego hosta, do zakładki Interfejsy sieciowei uruchom kreatora Skonfiguruj sieci hostów, aby powiązać się z hostami nowej sieci logicznej.

Zrzut ekranu kreatora „Konfiguracja sieci hostów”.

Agent oVirt automatycznie dokona wszystkich niezbędnych ustawień sieciowych na hoście - utworzy VLAN i BRIDGE.

Przykładowe pliki konfiguracyjne dla nowych sieci na hoście:

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

Przypomnę jeszcze raz, że na serwerze klastra NIE POTRZEBNE wcześniej ręcznie utworzyć interfejsy sieciowe ifcfg-bond1.432 и ifcfg-ovirtvm-vlan432.

Po dodaniu sieci logicznej i sprawdzeniu połączenia pomiędzy hostem a maszyną wirtualną hostowanego silnika można z niej korzystać na maszynie wirtualnej.

Tworzenie obrazu instalacyjnego do wdrożenia maszyny wirtualnej

Link do dokumentacji - Przewodnik administracyjny oVirt, Rozdział 8: Przechowywanie, sekcja Przesyłanie obrazów do domeny przechowywania danych.

Bez obrazu instalacyjnego systemu operacyjnego nie będzie możliwości zainstalowania maszyny wirtualnej, choć oczywiście nie stanowi to problemu, jeśli jest ona zainstalowana np. w sieci Szewc z wcześniej utworzonymi obrazami.

W naszym przypadku nie jest to możliwe, dlatego będziesz musiał samodzielnie zaimportować ten obraz do oVirt. Wcześniej wymagało to utworzenia domeny ISO, ale w nowej wersji oVirt stało się to przestarzałe i dlatego można teraz przesyłać obrazy bezpośrednio do domeny Storage z portalu administracyjnego.

W portalu administracyjnym przejdź do Magazynowanie >> Tarcze >> Prześlij >> Start
Dodajemy obraz naszego systemu operacyjnego jako plik ISO, wypełniamy wszystkie pola w formularzu i klikamy przycisk „Połączenie testowe".

Zrzut ekranu przedstawiający Kreatora dodawania obrazu instalacyjnego

Jeżeli otrzymamy taki błąd:

Unable to upload image to disk d6d8fd10-c1e0-4f2d-af15-90f8e636dadc due to a network error. Ensure that ovirt-imageio-proxy service is installed and configured and that ovirt-engine's CA certificate is registered as a trusted CA in the browser. The certificate can be fetched from https://ovirt.test.local/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA`

Następnie musisz dodać certyfikat oVirt do „Zaufane główne urzędy certyfikacji„(Zaufany główny urząd certyfikacji) na stacji kontrolnej administratora, skąd próbujemy pobrać obraz.

Po dodaniu certyfikatu do Zaufanego głównego urzędu certyfikacji kliknij ponownie „Połączenie testowe", powinien dostać:

Connection to ovirt-imageio-proxy was successful.

Po zakończeniu czynności dodawania certyfikatu możesz spróbować ponownie przesłać obraz ISO do domeny magazynu.

Zasadniczo można utworzyć oddzielną domenę pamięci masowej z typem danych, aby przechowywać obrazy i szablony oddzielnie od dysków maszyn wirtualnych, a nawet przechowywać je w domenie pamięci masowej dla hostowanego silnika, ale zależy to od uznania administratora.

Zrzut ekranu z obrazami ISO w domenie pamięci masowej dla hostowanego silnika

Utwórz maszynę wirtualną

Link do dokumentacji:
oVirt Przewodnik zarządzania maszyną wirtualną –> Rozdział 2: Instalowanie maszyn wirtualnych z systemem Linux
Zasoby klientów konsoli

Po załadowaniu obrazu instalacyjnego z systemem operacyjnym do oVirt można bezpośrednio przystąpić do tworzenia maszyny wirtualnej. Wykonano wiele pracy, ale jesteśmy już na końcowym etapie, dla którego to wszystko się rozpoczęło - uzyskaniu odpornej na awarie infrastruktury do hostowania maszyn wirtualnych o wysokiej dostępności. A wszystko to całkowicie za darmo – nie wydano ani grosza na zakup jakichkolwiek licencji na oprogramowanie.

Aby utworzyć maszynę wirtualną z CentOS 7, należy pobrać obraz instalacyjny z systemu operacyjnego.

Wchodzimy do portalu administracyjnego, przechodzimy do obliczać >> Maszyny wirtualnei uruchom kreatora tworzenia maszyny wirtualnej. Wypełnij wszystkie parametry i pola i kliknij ОК. Wszystko jest bardzo proste, jeśli postępujesz zgodnie z dokumentacją.

Jako przykład podam podstawowe i dodatkowe ustawienia maszyny wirtualnej o wysokiej dostępności, z utworzonym dyskiem, podłączonej do sieci i uruchamiającej się z obrazu instalacyjnego:

Zrzuty ekranu z ustawieniami maszyny wirtualnej o wysokiej dostępności

Po zakończeniu pracy z kreatorem zamknij go, uruchom nową maszynę wirtualną i zainstaluj na niej system operacyjny.
W tym celu należy przejść do konsoli tej maszyny wirtualnej poprzez portal administracyjny:

Zrzut ekranu przedstawiający ustawienia portalu administracyjnego dotyczące łączenia się z konsolą maszyny wirtualnej

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

Zrzut ekranu ustawień maszyny wirtualnej, zakładka „Konsola”.

Aby połączyć się z konsolą VM możesz użyć np. Przeglądarka maszyny wirtualnej.

Aby połączyć się z konsolą VM bezpośrednio w oknie przeglądarki, ustawienia połączenia poprzez konsolę powinny wyglądać następująco:

Po zainstalowaniu systemu operacyjnego na maszynie wirtualnej zaleca się 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

Tym samym w wyniku naszych działań utworzona maszyna wirtualna będzie charakteryzowała się wysoką dostępnością, tj. jeśli węzeł klastra, na którym działa, ulegnie awarii, oVirt automatycznie uruchomi go ponownie na drugim węźle. Tę maszynę wirtualną można również migrować między hostami klastra w celu konserwacji lub w innych celach.

wniosek

Mam nadzieję, że tym artykułem udało się przekazać, że oVirt to zupełnie normalne narzędzie do zarządzania infrastrukturą wirtualną, które nie jest aż tak trudne w wdrożeniu - najważniejsze jest przestrzeganie pewnych 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ę w nim zawrzeć wielu rzeczy, jak np. wykonanie krok po kroku różnych kreatorów ze wszystkimi szczegółowymi objaśnieniami i zrzutami ekranu, długie wnioski z niektórych poleceń itp. Tak naprawdę 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 wraz z innowacjami i zmianami. Najważniejsze jest zrozumienie zasady działania tego wszystkiego i uzyskanie ogólnego algorytmu tworzenia odpornej na awarie platformy do zarządzania maszynami wirtualnymi.

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

Proces ten jest jednym z głównych zadań administratora systemu lub sieci, o czym napiszemy w kolejnym artykule – o wykorzystaniu wirtualnych routerów VyOS w infrastrukturze odpornej na błędy naszego przedsiębiorstwa (jak się domyślacie, będą one działać jako wirtualne maszyn w naszym klastrze oVirt).

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

Stworzenie odpornej na awarie infrastruktury IT. Część 2. Instalacja i konfiguracja klastra oVirt 4.3