Erstellung einer ausfallsicheren IT-Infrastruktur. Teil 2. Installation und Konfiguration des oVirt 4.3 Clusters

Dieser Artikel ist eine Fortsetzung des vorherigen – „Aufbau einer ausfallsicheren IT-Infrastruktur. Teil 1 — Vorbereitung auf die Bereitstellung eines Clusters oVirt 4.3».

Hier wird der Prozess der grundlegenden Installation und Konfiguration des oVirt 4.3 Clusters für das Hosting von hochverfügbaren virtuellen Maschinen behandelt, unter der Annahme, dass alle erforderlichen Schritte zur Vorbereitung der Infrastruktur bereits zuvor abgeschlossen sind.

Introduction

Das Hauptziel des Artikels besteht nicht darin, eine Schritt-für-Schritt-Anleitung wie „Next -> Ja -> Fertigstellen“ zu liefern, sondern einige Besonderheiten bei der Installation und Konfiguration aufzuzeigen. Der Prozess zum Bereitstellen Ihres Clusters kann aufgrund spezifischer Infrastruktur- und Umgebungseigenschaften von dem hier beschriebenen abweichen, aber die allgemeinen Prinzipien werden dieselben sein.

Aus subjektiver Sicht oVirt 4.3 ist in seiner Funktionalität vergleichbar mit VMware vSphere Version 5.x, hat aber natürlich seine eigenen spezifischen Konfigurationen und Arbeitsweisen.

Für Interessierte sind alle Unterschiede zwischen RHEV (auch bekannt als oVirt) und VMware vSphere im Internet zu finden, zum Beispiel hier, dennoch werde ich gelegentlich einige Unterschiede oder Ähnlichkeiten im Verlauf des Artikels erwähnen.

Es ist wichtig, die Netzwerkarbeit für virtuelle Maschinen (VM) ein wenig zu vergleichen. In oVirt wird ein ähnliches Prinzip zur Verwaltung von Netzwerken für VMs umgesetzt wie in VMware vSphere:

• über einen standardmäßigen Linux Bridge (in VMware — Standard vSwitch), der auf den Virtualisierungs-Hosts betrieben wird;
• über Open vSwitch (OVS) (in VMware — Distributed vSwitch) – dies ist ein verteilter virtueller Switch, der aus zwei Hauptkomponenten besteht: einem zentralen OVN-Server und OVN-Controllern auf den verwalteten Hosts.

Es sei darauf hingewiesen, dass aufgrund der einfachen Implementierung in diesem Artikel die Netzwerkkonfiguration in oVirt für VMs mittels eines standardmäßigen Linux Bridges beschrieben wird, der die Standardwahl bei der Verwendung des KVM-Hypervisors ist.

Daher gibt es mehrere grundlegende Regeln für die Netzwerkarbeit im Cluster, die besser nicht verletzt werden sollten:

• Alle Netzwerkeinstellungen auf den Hosts müssen vor der Hinzufügung zu oVirt identisch sein, außer bei den IP-Adressen.
• Nachdem der Host unter die Verwaltung von oVirt gestellt wurde, wird dringend davon abgeraten, manuell an den Netzwerkeinstellungen zu ändern, ohne sich der eigenen Handlungen vollständig bewusst zu sein, da der oVirt-Agent diese nach einem Neustart des Hosts oder des Agents auf die vorherigen Einstellungen zurücksetzt.
• Das Hinzufügen und Arbeiten mit einem neuen Netzwerk für die VM sollte nur über die oVirt-Verwaltungskonsole erfolgen.

Ein weiteres wichtiges Hinweis — für sehr kritische Umgebungen (die empfindlich auf finanzielle Verluste reagieren), wäre es dennoch ratsam, kostenpflichtigen Support in Anspruch zu nehmen und Red Hat Virtualization 4.3. Während des Betriebs des oVirt-Clusters können einige Situationen entstehen, in denen es wünschenswert ist, so schnell wie möglich qualifizierte Hilfe zu erhalten, anstatt selbst mit ihnen umzugehen.

Und schließlich, es empfohlen wird vor der Bereitstellung des oVirt-Clusters sollten Sie sich mit der offiziellen Dokumentationvertraut machen, um zumindest die grundlegenden Konzepte und Definitionen zu kennen, da es sonst schwierig sein wird, den Artikel weiterzulesen.

Die folgenden Leitfäden sind grundlegend für das Verständnis des Artikels und der Funktionsweise des oVirt-Clusters:

• oVirt Installationshandbuch
• oVirt Selbstgehostetes Engine-Handbuch
• oVirt Verwaltungshandbuch
  

Der Umfang ist nicht besonders groß; in ein oder zwei Stunden kann man die grundlegenden Prinzipien gut verstehen. Für Detailverliebte empfehle ich, weiterzulesen. Produktdokumentation für Red Hat Virtualization 4.3 — RHEV und oVirt sind im Wesentlichen dasselbe.

Wenn also alle grundlegenden Einstellungen an den Hosts, Switches und Speicherlösungen vorgenommen wurden, gehen wir direkt zur Bereitstellung von oVirt über.

Teil 2. Installation und Konfiguration des oVirt 4.3 Clusters

Zur besseren Orientierung führe ich hier die wichtigsten Abschnitte in diesem Artikel auf, die nacheinander abgearbeitet werden sollten:

1. Installation des oVirt-Managementservers
2. Erstellung eines neuen Rechenzentrums
3. Erstellung eines neuen Clusters
4. Installation zusätzlicher Hosts in einer Self-Hosted-Umgebung
5. Erstellung von Speicherbereichen oder Storage Domains
6. Erstellung und Konfiguration von Netzwerken für virtuelle Maschinen
7. Erstellung eines Installationsimages für die Bereitstellung einer virtuellen Maschine
8. Erstellung einer virtuellen Maschine

Installation des oVirt-Managementservers

Der oVirt-Managementserver ist das zentrale Element in der oVirt-Infrastruktur, das entweder als virtuelle Maschine, Host oder virtuelles Gerät auftritt und die gesamte oVirt-Infrastruktur verwaltet.

Ähnliche Gegenstücke in der Virtualisierungswelt sind:

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

Für die Installation des oVirt-Managementservers haben wir zwei Optionen:

Option 1
Bereitstellung des Servers als spezialisierte VM oder Host.

Diese Option funktioniert gut, solange die VM unabhängig vom Cluster betrieben wird, d.h. sie läuft nicht auf einem der Cluster-Hosts als gewöhnliche virtuelle Maschine unter KVM.

Warum kann eine solche VM nicht auf den Hosts des Clusters bereitgestellt werden?

Zu Beginn des Prozesses zur Bereitstellung des oVirt-Managementservers stehen wir vor einem Dilemma – die Management-VM muss installiert werden, aber der Cluster existiert faktisch noch nicht, also was können wir direkt tun? Richtig – installiere KVM auf dem zukünftigen Cluster-Knoten, erstelle dann eine virtuelle Maschine, beispielsweise mit CentOS, und darauf den oVirt-Engine. Dies geschieht normalerweise aus dem Gedanken des vollständigen Kontrollebens über diese VM, aber das ist eine fehlerhafte Absicht, da in der Folge 100% Probleme mit dieser Management-VM auftreten werden:

• Sie kann nicht in der oVirt-Konsole zwischen den Hosts (Knoten) des Clusters migriert werden;
• bei der Migration mit KVM über virsh migrate, wird diese VM nicht mehr über die oVirt-Konsole verwaltbar sein.
• Cluster-Hosts können nicht in Wartungsmodus (Maintenance Mode) versetzt werden, wenn diese VM von Host zu Host migriert wird mit virsh migrate.

Halten Sie sich an die Richtlinien – verwenden Sie einen oVirt-Manager-Server oder einen separaten Host oder eine unabhängige VM, die darauf ausgeführt wird, idealerweise folgen Sie der zweiten Variante.

Option 2
Installation der oVirt Engine Appliance auf dem managed Host des Clusters.

Diese Variante wird im Folgenden als die korrektere und geeignetere betrachtet.
Die Anforderungen an diese VM sind unten beschrieben. Ich möchte nur hinzufügen, dass es empfohlen wird, mindestens zwei Hosts in der Infrastruktur zu haben, auf denen die verwaltete VM betrieben werden kann, um ihre Ausfallsicherheit zu gewährleisten. Ich möchte auch anmerken, dass, wie ich bereits in den Kommentaren zum vorherigen Artikel geschrieben habe, ich es nicht geschafft habe, Splitbrain im oVirt-Cluster mit zwei Hosts zu erreichen, wobei die Möglichkeit besteht, die hosted-engine VM auf ihnen zu starten.

Installation der oVirt Engine Appliance auf dem ersten Host des Clusters

Link zur offiziellen Dokumentation – oVirt Selbstgehostetes Engine-Handbuch, Kapitel „Implementierung der selbstgehosteten Engine über die Kommandozeile»

In diesem Dokument sind die Voraussetzungen aufgeführt, die erfüllt sein müssen, bevor die hosted-engine VM bereitgestellt wird. Zudem wird der Installationsprozess im Detail beschrieben, sodass es keinen besonderen Sinn macht, ihn wortwörtlich zu wiederholen. Daher möchten wir auf einige wichtige Details hinweisen.

• Bevor Sie irgendwelche Schritte unternehmen, aktivieren Sie unbedingt die Unterstützung für Virtualisierung in den BIOS-Einstellungen des Hosts.
• Installieren Sie auf dem Host das Paket für den Hosted-Engine-Installer:

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

• Starten Sie auf dem Host den Bereitstellungsprozess der oVirt Hosted Engine in einem Screen (zum Verlassen drücken Sie Ctrl-A + D, zum Schließen Ctrl-D):

screen
hosted-engine --deploy

Wenn gewünscht, können Sie die Installation mit einer zuvor vorbereiteten Antwortdatei starten:

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

• Während der Bereitstellung der Hosted Engine geben Sie alle erforderlichen Parameter an:

- Clustername
- Anzahl vCPU und vRAM (empfohlen 4 vCPU und 16 GB)
- Passwörter
- Art des Speichers für die Hosted Engine VM – in unserem Fall FC
- LUN-Nummer für die Installation der Hosted Engine
- Wo sich die Datenbank für die Hosted Engine befinden soll – ich empfehle zur Vereinfachung, Local zu wählen (das ist eine PostgreSQL-Datenbank, die innerhalb dieser VM betrieben wird)
und weitere Parameter. 

• Für die Installation einer hochverfügbaren VM mit Hosted Engine haben wir im SAN im Voraus ein spezielles LUN mit der Nummer 4 und einer Größe von 150 GB erstellt, welches anschließend den Hosts des Clusters präsentiert wurde – siehe in im vorherigen Artikel.

Wir haben zuvor auch die Sichtbarkeit auf den Hosts geprüft:

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

• Der Prozess der Bereitstellung der Hosted Engine ist nicht kompliziert. Am Ende sollten wir etwa folgende Nachricht erhalten:

[ INFO  ] Generierung der Antwortdatei '/var/lib/ovirt-hosted-engine-setup/answers/answers-20191129131846.conf'
[ INFO  ] Generierung der Antwortdatei '/etc/ovirt-hosted-engine/answers.conf'
[ INFO  ] Phase: Vorbeendigung
[ INFO  ] Phase: Beendigung
[ INFO  ] Hosted Engine erfolgreich bereitgestellt

Überprüfen der Verfügbarkeit der oVirt-Dienste auf dem Host:

Wenn alles richtig gemacht wurde, rufen Sie nach der Installation über einen Webbrowser die folgende Adresse auf: https://ovirt_hostname/ovirt-engine von Ihrem Administrationscomputer aus und klicken Sie auf [Administration Portal].

Screenshot des «Administration Portal»

Indem Sie den Benutzernamen und das Passwort (während der Installation festgelegt) in das Fenster wie im Screenshot eingeben, gelangen Sie in das Open Virtualization Manager-Dashboard, in dem Sie alle notwendigen Aktionen mit der virtuellen Infrastruktur durchführen können:

1. Rechenzentren hinzufügen
2. Cluster hinzufügen und konfigurieren
3. Hosts hinzufügen und verwalten
4. Speicherbereiche oder Storage Domains für die Festplatten von virtuellen Maschinen hinzufügen
5. Netzwerke für virtuelle Maschinen hinzufügen und konfigurieren
6. Virtuelle Maschinen, Installationsbilder, VM-Vorlagen hinzufügen und verwalten

All diese Aktionen werden im Folgenden behandelt, einige in groben Zügen, andere ausführlicher mit Details.
Ich empfehle jedoch zunächst, dieses Ergänzungsdokument zu lesen, das sicherlich vielen von Nutzen sein kann.

Ergänzung

1) Grundsätzlich steht es Ihnen frei, wenn nötig, vorab den KVM-Hypervisor auf den Cluster-Knoten zu installieren, indem Sie die Pakete verwenden: libvirt und qemu-kvm (oder qemu-kvm-ev) der gewünschten Version, da beim Bereitstellen eines oVirt-Cluster-Knotens dies auch automatisch erfolgen kann.

Aber wenn libvirt und qemu-kvm eine nicht ganz aktuelle Version installiert wurde, kann während der Bereitstellung des Hosted Engines der folgende Fehler auftreten:

Fehler: nicht unterstützte Konfiguration: unbekannte CPU-Funktion: md-clear

Das heißt, es ist notwendig, eine aktualisierte Version libvirt mit Schutz vor MDS, die eine solche Richtlinie unterstützt:

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

Installieren Sie libvirt v.4.5.0-10.el7_6.12, mit Unterstützung für 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

Überprüfen wir die Unterstützung für 'md-clear':

virsh domcapabilities kvm | grep require

Danach kann die Installation des Hosted Engines fortgesetzt werden.

2) In oVirt 4.3 ist das Vorhandensein und die Nutzung einer Firewall firewalld ist eine zwingende Voraussetzung.

Wenn während der Bereitstellung der VM für hosted-engine dieser Fehler auftritt:

[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "firewalld muss aktiviert und aktiv sein, um hosted-engine korrekt bereitzustellen. Bitte überprüfen Sie dies, beheben Sie es entsprechend und setzen Sie die Bereitstellung fort."}
[ ERROR ] Fehler beim Ausführen der Phase 'Abschluss': Fehler beim Ausführen des ansible-playbooks
[https://bugzilla.redhat.com/show_bug.cgi?id=1608467

Dann muss eine andere Firewall (sofern verwendet) deaktiviert und installiert sowie gestartet werden: 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

In Zukunft wird beim Installieren des ovirt-Agenten auf einem neuen Host für das Cluster die erforderlichen Ports in firewalld automatisch konfiguriert.

3) Ein Neustart des Hosts mit der darauf laufenden VM mit hosted engine.

Wie üblich, Link 1 und Link 2 zu den Dokumentationsrichtlinien.

Die gesamte Verwaltung der hosted engine VM erfolgt NUR über den Befehl hosted-engine auf dem Host, auf dem sie läuft, über virsh sollte man ebenso vergessen wie die Möglichkeit, über SSH auf diese VM zuzugreifen und das Kommando „shutdown».

Verfahren zum Versetzen der VM in den Wartungsmodus:

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

hosted-engine --vm-status
!! Cluster befindet sich im GLOBALEN WARTUNGSmodus !!
--== Host host1.test.local (id: 1) Status ==--
conf_on_shared_storage             : True
Status aktuell                     : True
Hostname                           : host1.test.local
Host ID                            : 1
Engine Status                      : {"health": "gut", "vm": "aktiv", "detail": "Aktiv"}
Punktzahl                          : 3400
gestoppt                           : False
Lokale Wartung                     : False
crc32                              : dee1a774
local_conf_timestamp               : 1821
Host-Zeitstempel                   : 1821
Zusätzliche Metadaten (gültig zum Zeitstempel):
        metadata_parse_version=1
        metadata_feature_version=1
        timestamp=1821 (Sam Nov 29 14:25:19 2019)
        host-id=1
        score=3400
        vm_conf_refresh_time=1821 (Sam Nov 29 14:25:19 2019)
        conf_on_shared_storage=True
        wartung=False
        state=GlobalMaintenance
        stopped=False

hosted-engine --vm-shutdown

Wir starten den Host mit dem Hosted Engine Agent neu und erledigen, was wir benötigen.

Nach dem Neustart überprüfen wir den Status der VM mit Hosted Engine:

hosted-engine --vm-status

Wenn unsere VM mit Hosted Engine nicht startet und wir ähnliche Fehler im Service-Log sehen:

Fehler im Service-Log:

journalctl -u ovirt-ha-agent
...
29. Jun 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine FEHLER Konnte notwendige Überwachungen nicht starten
29. Jun 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent FEHLER Traceback (letzter Aufruf zuletzt):#012  Datei "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", Zeile 131, in _run_agent#012    return action(he)#012  Datei "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", Zeile 55, in action_proper#012    return he.start_monitoring()#012  Datei "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py", Zeile 413, in start_monitoring#012    self._initialize_broker()#012  Datei "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py", Zeile 537, in _initialize_broker#012    m.get('options', {}))#012  Datei "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py", Zeile 86, in start_monitor#012    ).format(t=type, o=options, e=e)#012RequestError: brokerlink - konnte Überwachung über ovirt-ha-broker nicht starten: [Errno 2] Datei oder Verzeichnis nicht gefunden, [Überwachung: 'ping', Optionen: {'addr': '172.20.32.32'}]
29. Jun 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent FEHLER Versuch, Agent neu zu starten

Verbinden Sie den Speicher und starten Sie den Agenten neu:

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

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

Nachdem die VM mit hosted-engine gestartet wurde, nehmen wir sie aus den Wartungsmodus:

Verfahren zum Herausnehmen der VM aus dem Wartungsmodus:

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": "gut", "vm": "aktiv", "detail": "Aktiv"}
Punktzahl                          : 3400
gestoppt                           : False
Lokale Wartung                     : False
crc32                              : 6d1eb25f
lokale_conf_timestamp              : 6222296
Host timestamp                     : 6222296
Zusätzliche Metadaten (gültig zum Zeitstempel):
        metadata_parse_version=1
        metadata_feature_version=1
        timestamp=6222296 (Fr 17 Jan 11:40:43 2020)
        host-id=1
        punktzahl=3400
        vm_conf_refresh_time=6222296 (Fr 17 Jan 11:40:43 2020)
        conf_on_shared_storage=True
        Wartung=False
        status=EngineUp
        gestoppt=False

4) Entfernen des hosted engines und aller damit verbundenen Komponenten.

Manchmal ist es erforderlich, das zuvor installierte hosted engine korrekt zu entfernen — Link auf das Dokument Bezug nehmen.

Führen Sie einfach den Befehl auf dem Host aus:

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

Danach entfernen wir die unnötigen Pakete, nachdem wir zuvor einige Konfigurationen gesichert haben, falls erforderlich:

yum autoremove ovirt* qemu* virt* libvirt* libguestfs 

Erstellung eines neuen Rechenzentrums

Dokumentation — oVirt Administrationshandbuch. Kapitel 4: Rechenzentren

Zuerst definieren wir, was ein Rechenzentrum (zitiert aus der Dokumentation) — ist eine logische Entität, die eine Menge von Ressourcen definiert, die in einer spezifischen Umgebung verwendet werden.

Ein Rechenzentrum ist eine Art Behälter, bestehend aus:

• logischen Ressourcen in Form von Clustern und Hosts
• Netzwerkressourcen des Clusters in Form von logischen Netzwerken und physischen Adaptern auf Hosts,
• Speicherressourcen (für VM-Disketten, Vorlagen, Abbildungen) in Form von Speicherbereichen (Storage Domains).

Das Rechenzentrum kann mehrere Cluster beinhalten, die aus mehreren Hosts bestehen, auf denen virtuelle Maschinen laufen. Außerdem kann es mehrere Speicherbereiche geben, die mit ihm assoziiert sind.
Es können mehrere Rechenzentren existieren, die unabhängig voneinander arbeiten. In oVirt gibt es eine Rollentrennung, die es ermöglicht, Berechtigungen individuell auf der Ebene des Rechenzentrums sowie auf seinen einzelnen logischen Elementen festzulegen.

Rechenzentren, oder mehrere Rechenzentren, werden von einer einzigen Verwaltungs-Konsole oder einem Portal aus verwaltet.

Um ein Rechenzentrum zu erstellen, gehen wir ins Verwaltungsportal und erstellen ein neues Rechenzentrum:
Compute >> Rechenzentren >> New

Da wir gemeinsamen Speicher auf dem SAN nutzen, muss der Speichertyp (Storage Type) Shared sein:

Screenshot mit dem Assistenten zur Erstellung des Rechenzentrums

Bei der Installation einer virtuellen Maschine mit hosted-engine wird standardmäßig ein Rechenzentrum erstellt – Rechenzentrum1, und bei Bedarf kann der Speichertyp (Storage Type) geändert werden.

Die Erstellung eines Rechenzentrums ist eine unkomplizierte Aufgabe ohne komplizierte Besonderheiten, und alle zusätzlichen Schritte sind in der Dokumentation beschrieben. Ich möchte nur anmerken, dass einzelne Hosts mit nur lokalem Speicher (Festplatte) für die VM nicht in ein Rechenzentrum mit dem Speichertyp – Shared hinzugefügt werden können. Daher muss für sie ein separates Rechenzentrum erstellt werden – d.h. jeder einzelne Host mit lokalem Speicher benötigt sein eigenes Rechenzentrum.

Erstellung eines neuen Clusters

Link zur Dokumentation – oVirt Administrationshandbuch. Kapitel 5: Cluster

Ohne überflüssige Details, ein Cluster – ist eine logische Gruppierung von Hosts, die einen gemeinsamen Speicherbereich (in Form von gemeinsamen Festplatten auf dem SAN, wie in unserem Fall) haben. Es ist auch wünschenswert, dass die Hosts im Cluster in Bezug auf die Hardware identisch sind und denselben Prozessor-Typ (Intel oder AMD) besitzen. Idealerweise sollten die Server im Cluster vollständig identisch sein.

Ein Cluster gehört zu einem Rechenzentrum (mit einem bestimmten Speichertyp – Lokal oder Shared), und alle Hosts müssen zwingend einem Cluster zugeordnet werden, je nachdem, ob sie über gemeinsamen Speicher verfügen oder nicht.

Beim Hochladen einer virtuellen Maschine mit hosted-engine auf einen Host wird standardmäßig ein Rechenzentrum erstellt — Rechenzentrum1, zusammen mit dem Cluster – Cluster1, und die Parameter können später angepasst, zusätzliche Optionen aktiviert und Hosts hinzugefügt werden usw.

Wie gewohnt ist es ratsam, für detaillierte Informationen zu allen Cluster-Einstellungen die offizielle Dokumentation zu konsultieren. Von den Besonderheiten der Cluster-Konfiguration möchte ich nur hinzufügen, dass es bei der Erstellung ausreicht, nur die Hauptparameter im Tab einzustellen. Allgemein.

Ich möchte die wichtigsten Parameter hervorheben:

• Prozesstyp — wird basierend auf den Prozessoren, die in den Hosts des Clusters installiert sind, deren Hersteller und dem ältesten Prozessor in den Hosts ausgewählt, um alle verfügbaren Prozessoranweisungen im Cluster je nach diesem zu nutzen.
• Schaltertyp – in unserem Cluster wird nur ein Linux-Bridge verwendet, daher wählen wir diesen aus.
• Firewalltyp – hier ist alles klar, es handelt sich um firewalld, der auf den Hosts aktiviert und konfiguriert sein muss.

Screenshot mit den Cluster-Einstellungen

Hinzufügen zusätzlicher Hosts in einer Self-Hosted-Umgebung

Link zur Dokumentation.

Zusätzliche Hosts für die Self-Hosted-Umgebung werden ebenso hinzugefügt wie ein regulärer Host, wobei ein zusätzlicher Schritt zur Bereitstellung der VM mit dem hosted engine erforderlich ist — Wählen Sie die Bereitstellungsaktion für den hosted engine >> Bereitstellen. Da dem zusätzlichen Host ebenfalls ein LUN für die VM mit dem hosted engine zugewiesen werden muss, bedeutet dies, dass dieser Host bei Bedarf zur Bereitstellung der VM mit dem hosted engine verwendet werden kann.
Für Redundanz wird dringend empfohlen, mindestens zwei Hosts zu haben, auf denen die VM mit dem hosted engine bereitgestellt werden kann.

Auf dem zusätzlichen Host iptables deaktivieren (falls aktiviert), firewalld aktivieren

systemctl stop iptables
systemctl disable iptables

systemctl enable firewalld
systemctl start firewalld

Installieren Sie die erforderliche KVM-Version (falls nötig):

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

Benötigte Repositories und Installer für den hosted engine einrichten:

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

Gehen Sie zur Konsole über Open Virtualization Manager, fügen Sie einen neuen Host hinzu und folgen Sie den Schritten wie beschrieben in Dokumentation..

Nach dem Hinzufügen eines zusätzlichen Hosts sollte das Administrationskonsole ungefähr so aussehen wie im Screenshot.

Screenshot des Administrationsportals – Hosts

Der Host, auf dem die VM mit der Hosted-Engine aktuell aktiv ist, hat eine goldene Krone und die Aufschrift „Running the Hosted Engine VM“, der Host, auf dem diese VM bei Bedarf gestartet werden kann – die Aufschrift „Can run the Hosted Engine VM».

Im Falle eines Ausfalls des Hosts, auf dem „Running the Hosted Engine VM“, wird sie automatisch auf dem zweiten Host neu gestartet. Diese VM kann auch von einem aktiven Host auf einen Backup-Host migriert werden, um Wartungsarbeiten durchzuführen.

Konfiguration des Power Managements / Fencing auf oVirt-Hosts

Links zur Dokumentation:

• Red Hat Virtualization 4.3 –> Technisches Referenzdokument -> Kapitel 4. Power Management
• oVirt Administrationshandbuch -> Kapitel 7: Hosts

Obwohl es so aussieht, als ob die Hinzufügung und Konfiguration des Hosts abgeschlossen sind, ist das nicht ganz richtig.
Um die Funktionalität der Hosts sicherzustellen und Störungen bei einem der Hosts zu erkennen und zu beheben, ist eine Konfiguration des Power Managements / Fencing notwendig.

Fencing, oder Fencing – das ist der Prozess, bei dem ein fehlerhafter oder abgestürzter Host vorübergehend aus dem Cluster ausgeschlossen wird. Dabei werden entweder die Dienste von oVirt auf dem Host neu gestartet oder der Host selbst.

Alle Details zu den Definitionen und Parametern zur Stromverwaltung / Fencing sind wie gewohnt in der Dokumentation zu finden. Ich werde nur ein Beispiel geben, wie man diesen wichtigen Parameter für Dell R640 Server mit iDRAC 9 einstellt.

1. Wir gehen ins Verwaltungsportal, klicken auf Compute >> Hosts und wählen den Host aus.
2. Wir klicken auf Bearbeiten.
3. den Tab Power Management.
4. Setzen Sie das Häkchen neben der Option Enable Power Management.
5. Setzen Sie das Häkchen neben der Option Kdump-Integration, damit der Host nicht in den Fencing-Modus wechselt, während der Kernel-Dumps geschrieben werden.

Hinweis.

Nach der Aktivierung der Kdump-Integration auf einem bereits laufenden Host muss dieser gemäß dem Verfahren im oVirt Administration Guide neu installiert werden -> Kapitel 7: Hosts -> Reinstalling Hosts.

1. Optional können Sie das Häkchen setzen bei Disable policy control of power management, wenn wir nicht wollen, dass die Stromverwaltung des Hosts durch die Cluster-Planungspolitik (Scheduling Policy) gesteuert wird.
2. Wir klicken auf die Schaltfläche (+), um ein neues Energieverwaltungsgerät hinzuzufügen, ein Fenster zur Bearbeitung der Agenteneigenschaften öffnet sich.
   Für iDRAC9 füllen wir die Felder aus:
   • Adresse – iDRAC9-Adresse
   • Benutzername / Passwort – entsprechend Login und Passwort für den Zugang zu iDRAC9
   • Type — drac5
   • markieren Sicher
   • folgende Optionen hinzufügen: cmd_prompt=>,login_timeout=30

Screenshot der Einstellungen „Power Management“ in den Host-Eigenschaften

Erstellung von Speicherbereichen oder Storage Domains

Link zur Dokumentation — oVirt Administrationshandbuch, Kapitel 8: Speicher.

Speicherdomäne, oder Speicherdomäne – dies ist ein zentraler Ort zum Speichern von Festplatten virtueller Maschinen, Installationsbildern, Vorlagen und Snapshots.

Speicherdomänen können über verschiedene Protokolle, Cluster- und Dateisysteme mit dem Rechenzentrum verbunden werden.

oVirt hat drei Arten von Speicherdomänen:

• Daten-Domäne – für die Speicherung aller mit virtuellen Maschinen verbundenen Daten (Festplatten, Vorlagen). Die Daten-Domäne kann nicht zwischen verschiedenen Rechenzentren geteilt werden.
• ISO-Domäne (veraltete Art der Speicherdomäne) – zur Speicherung von Installationsbildern von Betriebssystemen. Die ISO-Domäne kann zwischen verschiedenen Rechenzentren geteilt werden.
• Export-Domäne (veraltete Art der Speicherdomäne) – zur vorübergehenden Speicherung von Bildern, die zwischen Rechenzentren verschoben werden.

In unserem speziellen Fall verwendet die Speicherdomäne vom Typ Daten-Domäne das Fibre Channel-Protokoll (FCP), um sich mit LUNs auf dem SAN zu verbinden.

Aus der Sicht von oVirt stellt jeder virtuelle Datenträger, Snapshot oder Template, das mit einem Speichersystem (FC oder iSCSI) verwendet wird, eine logische Festplatte dar.
Blockgeräte werden auf den Cluster-Hosts durch eine Volume Group zusammengefasst und dann mittels LVM in logische Volumes unterteilt, die als virtuelle Festplatten für VMs verwendet werden.

Alle diese Gruppen und viele LVM-Volumes können auf dem Cluster-Host mit den Befehlen angezeigt werden. lvs und 3) Informationen anzeigen und mit RAID arbeitenEs ist selbstverständlich, dass alle Vorgänge mit solchen Festplatten ausschließlich über die oVirt-Konsole durchgeführt werden sollten, außer in speziellen Fällen.

Virtuelle Festplatten für VMs können zwei Typen sein – QCOW2 oder RAW. Die Festplatten können "dünn" oder "dick" sein. Snapshots werden immer als "dünn".

" erstellt. Der Umgang mit Storage Domains, die über FC zugänglich sind, ist recht logisch: Für jede virtuelle Festplatte einer VM gibt es ein separates logisches Volume, das nur von einem Host beschreibbar ist. Bei Verbindungen über FC verwendet oVirt eine Art von Cluster-LVM.

Virtuelle Maschinen, die sich im selben Speicherbereich befinden, können zwischen Hosts migriert werden, die demselben Cluster angehören.

Wie aus der Beschreibung ersichtlich, bezeichnet ein Cluster in oVirt, wie auch ein Cluster in VMware vSphere oder Hyper-V, im Wesentlichen dasselbe – es handelt sich um eine logische Gruppierung von Hosts, die idealerweise ähnliche Hardware aufweisen und über einen gemeinsamen Speicher für die Festplatten virtueller Maschinen verfügen.

Kommen wir nun direkt zur Erstellung eines Speichers für die Daten (VM-Festplatten), denn ohne diesen wird das Rechenzentrum nicht initialisiert.
Ich erinnere daran, dass alle den Hosts im Cluster präsentierten LUNs auf dem SAN sichtbar sein müssen, indem wir den Befehl "multipath -ll».

Laut Dokumentation.", gehen wir im Portal zu Speicher >> Domains -> New Domain und befolgen die Anweisungen aus dem Abschnitt "Adding FCP Storage".

Nach dem Start des Assistenten füllen wir die erforderlichen Felder aus:

• Name — Name des Clusters festlegen
• Domain Function — Daten
• Storage Type — Fibre Channel
• Host to Use — Wählen Sie den Host aus, auf dem der gewünschte LUN verfügbar ist.

In der Liste der LUNs markieren wir den benötigten und klicken auf Add und dann OK. Bei Bedarf können zusätzliche Speicherparameter angepasst werden, indem Sie auf Advanced Parameters.

Screenshot des Assistenten zur Hinzufügung einer "Storage Domain"

Nach Abschluss der Arbeiten des Assistenten sollten wir einen neuen Speicherbereich erhalten, und unser Rechenzentrum wechselt in den Status UP, oder initialisiert:

Screenshots des Rechenzentrums und der darin enthaltenen Speicherbereiche:

Erstellung und Konfiguration von Netzwerken für virtuelle Maschinen

Link zur Dokumentation — oVirt Administrationshandbuch, Kapitel 6: Logische Netzwerke

Netzwerke dienen der Gruppierung logischer Netzwerke, die in der virtuellen Infrastruktur oVirt verwendet werden.

Für die Interaktion des Netzwerkadapters in der virtuellen Maschine mit dem physischen Adapter auf dem Host werden logische Schnittstellen vom Typ Linux Bridge verwendet.

Um den Datenverkehr zwischen den Netzwerken zu gruppieren und zu trennen, sind VLANs auf den Switches konfiguriert.

Beim Erstellen eines logischen Netzwerks für virtuelle Maschinen in oVirt muss unbedingt eine ID zugewiesen werden, die der VLAN-Nummer auf dem Switch entspricht, damit die VMs miteinander kommunizieren können, auch wenn sie auf unterschiedlichen Cluster-Knoten arbeiten.

Die vorläufigen Einstellungen der Netzwerkadapter auf den Hosts für die Verbindung von virtuellen Maschinen sollten in im vorherigen Artikel – logische Schnittstelle konfiguriert bond1, danach sollten alle Netzwerkeinstellungen ausschließlich über das Verwaltungsportal oVirt vorgenommen werden.

Nach der Erstellung der VM mit hosted-engine wurde neben dem automatischen Erstellen des Rechenzentrums und des Clusters auch automatisch ein logisches Netzwerk zur Verwaltung unseres Clusters erstellt – ovritmgmt, zu dem diese VM angeschlossen ist.

Bei Bedarf können Sie die Einstellungen des logischen Netzwerks anzeigen ovritmgmt und anpassen, sollten jedoch vorsichtig sein, um die Kontrolle über die oVirt-Infrastruktur nicht zu verlieren.

Einstellungen des logischen Netzwerks ovritmgmt

Um ein neues logisches Netzwerk für normale VMs zu erstellen, gehen wir im Administrationsportal zu Netzwerk >> Networks >> New, und fügen auf dem Tab Allgemein ein Netzwerk mit der gewünschten VLAN-ID hinzu und aktivieren das Kontrollkästchen neben „VM Network“, was bedeutet, dass es für die Zuweisung an VMs verwendet werden kann.

Screenshot des neuen logischen Netzwerks VLAN32

Auf der Registerkarte Cluster, und fügen dieses Netzwerk zu unserem Cluster hinzu. Cluster1.

Danach gehen wir zu Compute >> Hosts, dann nacheinander zu jedem Host, auf den Tab Network interfaces, und starten den Assistenten Setup host networks, um das neue logische Netzwerk an die Hosts anzubinden.

Screenshot des Assistenten „Setup host networks“

Der oVirt-Agent konfiguriert automatisch alle erforderlichen Netzwerkeinstellungen auf dem Host – erstellt VLAN und BRIDGE.

Beispielkonfigurationsdateien für neue Netzwerke auf dem Host:

cat ifcfg-bond1
# Generiert von VDSM Version 4.30.17.1
DEVICE=bond1
BONDING_OPTS='mode=1 miimon=100'
MACADDR=00:50:56:82:57:52
ONBOOT=ja
MTU=1500
DEFROUTE=nein
NM_CONTROLLED=nein
IPV6INIT=nein

cat ifcfg-bond1.432
# Generiert von VDSM Version 4.30.17.1
DEVICE=bond1.432
VLAN=ja
BRIDGE=ovirtvm-vlan432
ONBOOT=ja
MTU=1500
DEFROUTE=nein
NM_CONTROLLED=nein
IPV6INIT=nein

cat ifcfg-ovirtvm-vlan432
# Generiert von VDSM Version 4.30.17.1
DEVICE=ovirtvm-vlan432
TYPE=Bridge
DELAY=0
STP=aus
ONBOOT=ja
MTU=1500
DEFROUTE=nein
NM_CONTROLLED=nein
IPV6INIT=nein

Ich möchte noch einmal daran erinnern, dass auf dem Cluster-Host NICHT VORAB manuell Netzwerkschnittstellen ifcfg-bond1.432 und ifcfg-ovirtvm-vlan432.

Nach dem Hinzufügen des logischen Netzwerks und der Überprüfung der Verbindung zwischen dem Host und der VM mit hosted engine kann es in der virtuellen Maschine verwendet werden.

Erstellung eines Installationsimages für die Bereitstellung einer virtuellen Maschine

Link zur Dokumentation — oVirt Administrationshandbuch, Kapitel 8: Speicher, Abschnitt Bilder hochladen in einen Datenspeicherbereich.

Ohne ein Installations-OS-Abbild kann die virtuelle Maschine nicht installiert werden, was jedoch kein Problem darstellt, wenn im Netzwerk beispielsweise Cobbler Vorausgefertigte Abbildungen vorhanden sind.

In unserem Fall gibt es diese Möglichkeit nicht, daher müssen wir dieses Abbild selbst in oVirt importieren. Früher war es erforderlich, eine ISO-Domain zu erstellen, aber in der neuen Version von oVirt wurde dies als veraltet erachtet, und jetzt können Abbildungen direkt aus dem Administrationsportal in die Storage-Domain hochgeladen werden.

Im Administrationsportal gehen wir zu Speicher >> Festplatten >> Hochladen >> Start
Wir fügen unser Betriebssystem-Abbild in Form einer ISO-Datei hinzu, füllen alle Felder im Formular aus und klicken auf die Schaltfläche "Verbindung testen".

Screenshot des Assistenten zum Hinzufügen des Installationsabbilds

Wenn wir einen Fehler dieses Typs erhalten:

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

muss das oVirt-Zertifikat in "Vertrauenswürdige Stammzertifizierungsstellen» (Trusted Root CA) auf der Administrationsstation hinzugefügt werden, von der aus wir versuchen, das Abbild hochzuladen.

Nach dem Hinzufügen des Zertifikats zu Trusted Root CA klicken wir erneut auf "Verbindung testen", und sollten erhalten:

Verbindung zu ovirt-imageio-proxy war erfolgreich.

Nachdem die Aktion zum Hinzufügen des Zertifikats durchgeführt wurde, kann das ISO-Abbild erneut in das Storage Domain hochgeladen werden.

Grundsätzlich kann ein separates Storage Domain vom Typ Data erstellt werden, um Abbilder und Vorlagen getrennt von den VMs zu speichern, oder sie können sogar im Storage Domain für die gehostete Engine gespeichert werden, aber das liegt im Ermessen des Administrators.

Screenshot mit ISO-Abbildern im Storage Domain für die gehostete Engine

Erstellung einer virtuellen Maschine

Link zur Dokumentation:
oVirt Virtual Machine Management Guide –> Kapitel 2: Installation von Linux-virtuellen Maschinen
Ressourcen für Konsolenclients

Nachdem das Installationsabbild mit dem Betriebssystem in oVirt hochgeladen wurde, können wir direkt mit der Erstellung der virtuellen Maschine beginnen. Viel Arbeit wurde bereits geleistet, und wir befinden uns nun in der abschließenden Phase, für die das alles angestoßen wurde – um eine ausfallsichere Infrastruktur für das Hosting von hochverfügbaren virtuellen Maschinen zu erhalten. Und das Beste daran: Es ist völlig kostenlos – es wurden keine Cent für den Erwerb von Softwarelizenzen ausgegeben.

Um eine virtuelle Maschine mit CentOS 7 zu erstellen, muss das Installationsabbild mit dem Betriebssystem hochgeladen werden.

Wir gehen zum Administrationsportal, navigieren zu Compute >> Virtual Machines, und starten den Assistenten zur Erstellung von VMs. Wir füllen alle Parameter und Felder aus und klicken auf OK. Es ist sehr einfach, wenn man der Dokumentation folgt.

Als Beispiel gebe ich die grundlegenden und zusätzlichen Einstellungen für eine hochverfügbare VM an, mit einem erstellten Datenträger, die an das Netzwerk angeschlossen ist und von einem Installationsabbild bootet:

Screenshots mit den Einstellungen der hochverfügbaren VM

Nach Abschluss der Arbeiten mit dem Assistenten schließen wir ihn und starten die neue VM, um das Betriebssystem zu installieren.
Dazu gehen wir über das Administrationsportal in die Konsole dieser VM:

Screenshot der Einstellungen des Administrationsportals zur Verbindung mit der VM-Konsole

Um eine Verbindung zur VM-Konsole herzustellen, müssen zuvor die Konsoleinstellungen in den Eigenschaften der virtuellen Maschine konfiguriert werden.

Screenshot der VM-Einstellungen, Tab „Konsole“

Zur Verbindung mit der VM-Konsole kann beispielsweise verwendet werden: Virtual Machine Viewer.

Um direkt im Browserfenster auf die VM-Konsole zuzugreifen, müssen die Verbindungseinstellungen wie folgt konfiguriert sein:

Nach der Installation des Betriebssystems auf der VM sollte der oVirt-Gast-Agent installiert werden:

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

Somit wird die erstellte VM hochverfügbar sein, d.h. im Falle eines Ausfalls des Clusterknotens, auf dem sie ausgeführt wird, wird oVirt sie automatisch auf dem zweiten Knoten neu starten. Außerdem kann diese VM zwischen den Clusternodes zur Wartung oder anderen Zwecken migriert werden.

Fazit

Ich hoffe, dass dieser Artikel verdeutlichen konnte, dass oVirt ein durchaus leistungsfähiges Werkzeug zur Verwaltung virtueller Infrastrukturen ist, dessen Implementierung nicht allzu kompliziert ist – es gilt lediglich, bestimmte Regeln und Anforderungen zu beachten, die sowohl im Artikel als auch in der Dokumentation beschrieben sind.

Leider war es aufgrund des umfangreichen Inhalts nicht möglich, viele Aspekte wie Schritt-für-Schritt-Anleitungen zu verschiedenen Assistenten mit ausführlichen Erklärungen und Screenshots, lange Ausgaben gewisser Befehle usw. zu integrieren. Tatsächlich würde es dafür erfordern, ein ganzes Buch zu schreiben, was wenig sinnvoll wäre angesichts der ständig neuen Softwareversionen mit Neuerungen und Änderungen. Das Wichtigste ist zu verstehen, wie alles zusammenarbeitet, und eine allgemeine Handlungsanweisung zur Erstellung einer ausfallsicheren Plattform zur Verwaltung virtueller Maschinen zu erhalten.

Obwohl wir die virtuelle Infrastruktur erstellt haben, müssen wir jetzt lernen, wie sie sowohl zwischen ihren einzelnen Komponenten: Hosts, virtuellen Maschinen, internen Netzwerken als auch mit der Außenwelt interagiert.

Dieser Prozess gehört zu den Kernaufgaben eines System- oder Netzwerkadministrators und wird im nächsten Artikel behandelt – über den Einsatz virtueller Router VyOS in der ausfallsicheren Infrastruktur unseres Unternehmens (wie Sie vermutet haben, werden sie als virtuelle Maschinen in unserem oVirt-Cluster betrieben).

Quelle: habr.com