Dieser Artikel ist eine Fortsetzung des vorherigen – „».
Dabei wird der Prozess der grundlegenden Installation und Konfiguration des oVirt 4.3 Clusters für das Hosting hochverfügbarer virtueller Maschinen behandelt, unter der Voraussetzung, dass alle vorherigen Schritte zur Vorbereitung der Infrastruktur bereits durchgeführt wurden.
Einleitung
Das Hauptziel des Artikels ist nicht so sehr, eine Schritt-für-Schritt-Anleitung wie „Weiter -> Ja -> Fertigstellen“ zu geben, sondern vielmehr einige Besonderheiten bei der Installation und Konfiguration aufzuzeigen. Der Prozess der Bereitstellung Ihres Clusters kann aufgrund der Besonderheiten der Infrastruktur und Umgebung von dem beschriebenen abweichen, jedoch werden die allgemeinen Prinzipien identisch sein.
Aus subjektiver Sicht ist in seiner Funktionalität ähnlich wie VMware vSphere Version 5.x, hat jedoch natürlich seine eigenen Besonderheiten in der Konfiguration und im Betrieb.
Für Interessierte sind alle Unterschiede zwischen RHEV (aka oVirt) und VMware vSphere im Internet zu finden, zum Beispiel , aber ich werde dennoch gelegentlich auf einige ihrer Unterschiede oder Ähnlichkeiten im Verlauf des Artikels hinweisen.
Separat möchte ich die Arbeit mit Netzwerken für virtuelle Maschinen vergleichen. In oVirt gibt es ein ähnliches Prinzip für das Netzwerkmanagement von virtuellen Maschinen (VM), wie in VMware vSphere:
- mit einem Standard-Linux-Brücke (in VMware – Standard vSwitch), die auf den Virtualisierungs-Hosts arbeitet;
- mit Open vSwitch (OVS) (in VMware – Distributed vSwitch) – dies ist ein verteilter virtueller Switch, der aus zwei Hauptkomponenten besteht: dem zentralen OVN-Server und den OVN-Controllern auf den verwalteten Hosts.
Es ist zu beachten, dass in Anbetracht der Einfachheit der Implementierung, in diesem Artikel die Konfiguration der Netzwerke in oVirt für VMs mithilfe der Standard-Linux-Brücke beschrieben wird, die die Standardwahl ist, wenn der Hypervisor KVM verwendet wird.
In diesem Zusammenhang gibt es mehrere grundlegende Regeln für die Arbeit mit Netzwerken im Cluster, die besser nicht verletzt werden sollten:
- Alle Netzwerkeinstellungen auf den Hosts müssen vor ihrer Hinzufügung zu oVirt identisch sein, außer den IP-Adressen.
- Nachdem ein Host von oVirt verwaltet wird, wird dringend davon abgeraten, manuelle Änderungen an den Netzwerkeinstellungen vorzunehmen, ohne sich absolut sicher zu sein, da der oVirt-Agent diese nach einem Neustart des Hosts oder Agents einfach auf die vorherigen zurücksetzen wird.
- Das Hinzufügen eines neuen Netzwerks für VMs sowie die Arbeit damit sollte ausschließlich über die oVirt-Verwaltungskonsole erfolgen.
Noch eine wichtige Anmerkung — für sehr kritische Umgebungen (die sehr empfindlich gegenüber finanziellen Verlusten sind) wäre es ratsam, kostenpflichtigen Support in Anspruch zu nehmen und . Während des Betriebs eines oVirt-Clusters können verschiedene Situationen auftreten, in denen es wünschenswert ist, so schnell wie möglich qualifizierte Unterstützung zu erhalten, anstatt selbst damit zurechtzukommen.
Und schließlich, wird empfohlen vor der Bereitstellung eines oVirt-Clusters die , um zumindest mit den grundlegenden Begriffen und Definitionen vertraut zu sein, da es sonst etwas schwierig sein könnte, den Artikel weiterzulesen.
Basisdokumente, die für das Verständnis des Artikels und der Funktionsweise des oVirt-Clusters wichtig sind, sind die folgenden Leitfäden:
Der Umfang ist nicht sehr groß, die grundlegenden Prinzipien können problemlos in ein bis zwei Stunden erlernt werden, und für Detailverliebte wird empfohlen, zu lesen — RHEV und oVirt sind im Wesentlichen dasselbe.
Wenn also alle grundlegenden Einstellungen auf Hosts, Switches und Storage-Systemen vorgenommen wurden, gehen wir direkt zur Bereitstellung von oVirt über.
Teil 2. Installation und Konfiguration des oVirt-Clusters 4.3
Zur besseren Orientierung werde ich die wichtigsten Abschnitte dieser Anleitung auflisten, die nacheinander bearbeitet werden sollten:
- Installation des oVirt-Managementservers
- Erstellung eines neuen Rechenzentrums
- Erstellung eines neuen Clusters
- Installation zusätzlicher Hosts in einer Self-Hosted-Umgebung
- Erstellung eines Speicherbereichs oder Storage Domains
- Erstellung und Konfiguration von Netzwerken für virtuelle Maschinen
- Erstellung eines Installationsimages zur Bereitstellung einer virtuellen Maschine
- Erstellung einer virtuellen Maschine
Installation des oVirt-Managementservers
Der oVirt-Managementserver ist das zentrale Element der oVirt-Infrastruktur, entweder als virtuelle Maschine, Host oder virtuelles Gerät, das die gesamte oVirt-Infrastruktur verwaltet.
Ähnliche Lösungen aus 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 Möglichkeiten:
Option 1
Bereitstellung des Servers als spezialisierte VM oder Host.
Diese Variante funktioniert durchaus, vorausgesetzt, dass eine solche VM unabhängig vom Cluster arbeitet, d. h. dass sie nicht auf einem der Hosts des Clusters als normale virtuelle Maschine unter KVM betrieben wird.
Warum kann man eine solche VM nicht auf den Hosts des Clusters bereitstellen?
Zu Beginn des Bereitstellungsprozesses des oVirt-Managementservers stehen wir vor der Dilemma – eine Verwaltungs-VM muss installiert werden, aber der Cluster existiert eigentlich noch nicht, also was kann man sofort erfinden? Richtig – KVM auf dem zukünftigen Clusterknoten zu installieren, dann darauf eine virtuelle Maschine zu erstellen, zum Beispiel mit CentOS und darin die oVirt-Engine bereitzustellen. Das kann normalerweise aus Gründen der vollständigen Kontrolle über eine solche VM getan werden, aber das ist eine falsche Absicht, denn in diesem Fall wird es später 100 % Probleme mit dieser Verwaltungs-VM geben:
- sie kann nicht zwischen den Hosts (Knoten) des Clusters in der oVirt-Konsole migriert werden;
- bei der Migration mit KVM-Tools über virsh migrate, wird diese VM nicht über die oVirt-Konsole verwaltet werden können.
- Die Hosts des Clusters können nicht in den Maintenance mode (Wartungsmodus) versetzt werden, wenn diese VM von Host zu Host migriert wird mit Hilfe von virsh migrate.
Also, macht alles nach den Regeln – verwendet für den oVirt-Managementserver entweder einen separaten Host oder eine unabhängige VM, die darauf ausgeführt wird, oder noch besser, macht es wie im zweiten Vorschlag beschrieben.
Option 2
Installation der oVirt Engine Appliance auf dem verwalteten Host des Clusters.
Genau diese Variante wird im Folgenden als die passendere und geeignetere in unserem Fall betrachtet.
Die Anforderungen an eine solche VM sind unten beschrieben, ich füge nur hinzu, dass es empfohlen wird, mindestens zwei Hosts in der Infrastruktur zu haben, auf denen die Verwaltungs-VM ausgeführt werden kann, um ihre Hochverfügbarkeit zu gewährleisten. Hier möchte ich hinzufügen, dass ich, wie ich bereits in den Kommentaren zum vorherigen Artikel geschrieben habe, es nicht geschafft habe, splitbrain im oVirt-Cluster mit zwei Hosts zu erreichen, mit der Möglichkeit, die hosted-engine VM dort auszuführen.
Installation der oVirt Engine Appliance auf dem ersten Host des Clusters
Link zur offiziellen Dokumentation – , Kapitel „»
Im Dokument sind die Voraussetzungen angeführt, die vor der Bereitstellung der hosted-engine VM erfüllt sein müssen, und der Installationsprozess wird detailliert beschrieben, weshalb es wenig Sinn macht, ihn wortwörtlich zu wiederholen. Daher konzentrieren wir uns auf einige wichtige Details.
- Vor Beginn aller Aktionen aktivieren wir unbedingt die Unterstützung für die Virtualisierung in den BIOS-Einstellungen des Hosts.
- Wir installieren das Paket für den Installer hosted-engine auf dem Host:
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- Wir starten den Bereitstellungsprozess für oVirt Hosted Engine auf dem Host in einem Screen (man kann ihn durch Ctrl-A + D verlassen, durch Ctrl-D schließen):
screen
hosted-engine --deployFalls gewünscht, kann die Installation auch mit einer bereits vorbereiteten Antwortdatei gestartet werden:
hosted-engine --deploy --config-append=/var/lib/ovirt-hosted-engine-setup/answers/answers-ohe.conf- Während der Bereitstellung von hosted-engine geben wir alle erforderlichen Parameter an:
- Name des Clusters
- Anzahl von vCPU und vRAM (wir empfehlen 4 vCPU und 16 GB)
- Passwörter
- Speichertyp für die hosted engine VM – in unserem Fall FC
- LUN-Nummer für die Installation von hosted engine
- Wo sich die Datenbank für hosted engine befinden wird – ich empfehle zur Einfachheit, Local zu wählen (das ist eine PostgreSQL-Datenbank, die innerhalb dieser VM läuft)
und weitere Parameter. - Für die Installation einer hochverfügbaren VM mit der hosted engine haben wir im SAN zuvor einen speziellen LUN mit der Nummer 4 und einer Größe von 150 GB erstellt, der dann den Hosts des Clusters präsentiert wurde – siehe in .
Wir haben außerdem zuvor die Sichtbarkeit auf den Hosts überprü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 gesamte Prozess der Bereitstellung der hosted-engine ist nicht kompliziert, am Ende sollten wir eine ähnliche Nachricht erhalten:
[ 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 erfolgreich bereitgestelltWir überprüfen die Verfügbarkeit der oVirt-Dienste auf dem Host:
Wenn alles richtig gemacht wurde, können wir nach Abschluss der Installation über den Webbrowser zu vom Administratorteam gelangen und auf klicken [Administration Portal].
Screenshot 'Administration Portal'
Nachdem wir den Benutzernamen und das Passwort (die während der Installation festgelegt wurden) in das Fenster wie auf dem Screenshot eingegeben haben, gelangen wir zum Steuerfeld des Open Virtualization Manager, in dem alle Aktionen mit der virtuellen Infrastruktur durchgeführt werden können:
- Rechenzentren hinzufügen
- Cluster hinzufügen und konfigurieren
- Hosts hinzufügen und verwalten
- Speicherbereiche oder Storage Domains für virtuelle Festplatten hinzufügen
- Netzwerke für virtuelle Maschinen hinzufügen und konfigurieren
- Virtuelle Maschinen, Installationsabbilder, VM-Vorlagen hinzufügen und verwalten
Alle diese Aktionen werden im Folgenden behandelt, einige grob, einige detaillierter und mit Nuancen.
Zunächst würde ich empfehlen, diese Ergänzung zu lesen, die für viele nützlich sein könnte.
Ergänzung
1) Im Prinzip, wenn es notwendig ist, spricht nichts dagegen, vorher den KVM-Hypervisor auf den Knoten des Clusters mit den Paketen libvirt und qemu-kvm (oder qemu-kvm-ev) in der gewünschten Version zu installieren, obwohl er dies während der Bereitstellung des oVirt-Clusterknotens auch selbst tun kann.
Falls jedoch libvirt und qemu-kvm nicht die neueste Version installiert wurde, könnte folgende Fehlermeldung während der Bereitstellung der Hosted Engine angezeigt werden:
Fehler: nicht unterstützte Konfiguration: unbekannte CPU-Funktion: md-clearDas heißt, es muss eine libvirt mit Unterstützung für , die diese Richtlinie unterstützt:
<feature policy='require' name='md-clear'/>Wir installieren 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üfung der Unterstützung für 'md-clear':
virsh domcapabilities kvm | grep requireDanach kann die Installation der Hosted Engine fortgesetzt werden.
2) In oVirt 4.3 ist das Vorhandensein und die Verwendung einer Firewall firewalld eine zwingende Voraussetzung.
Wenn während der Bereitstellung der VM für die Hosted Engine dieser Fehler auftritt:
[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "firewalld muss aktiviert und aktiv sein, um die hosted-engine korrekt bereitzustellen. Bitte überprüfen Sie, beheben Sie dies entsprechend und stellen Sie erneut bereit.
"}
[ ERROR ] Fehler beim Ausführen der Phase 'Abschließen': Ausführen des ansible-playbook fehlgeschlagen
[https://bugzilla.redhat.com/show_bug.cgi?id=1608467Dann muss eine andere Firewall (falls 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-zonesBei der Installation des oVirt-Agenten auf einem neuen Host für den Cluster werden die erforderlichen Ports automatisch konfiguriert. firewalld Neustart des Hosts mit der darauf laufenden VM mit der Hosted Engine.
3) Neustart des Hosts mit einer auf ihm laufenden VM mit hosted engine.
Wie üblich, und auf Leitdokumente.
Die gesamte Verwaltung der hosted engine VM erfolgt NUR über den Befehl hosted-engine auf dem Host, auf dem sie läuft, über virsh man vergessen muss, ebenso wie die Tatsache, dass man sich über SSH mit dieser VM verbinden und den Befehl „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
Aktualisierungsstatus : 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
lokale_conf_timestamp : 1821
Host-Zeitstempel : 1821
Zusätzliche Metadaten (gültig zum Zeitstempel):
metadata_parse_version=1
metadata_feature_version=1
timestamp=1821 (Sa Nov 29 14:25:19 2019)
host-id=1
score=3400
vm_conf_refresh_time=1821 (Sa Nov 29 14:25:19 2019)
conf_on_shared_storage=True
maintenance=False
state=GlobalMaintenance
stopped=False
hosted-engine --vm-shutdownWir starten den Host mit dem hosted engine Agent neu und machen, was wir brauchen.
Nach dem Neustart überprüfen wir den Status der VM mit dem hosted engine:
hosted-engine --vm-statusWenn unsere VM mit hosted-engine nicht startet und wir ähnliche Fehler im Servicelogo sehen:
Fehler im Servicelog:
journalctl -u ovirt-ha-agent
...
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine FEHLER Konnte erforderliche Monitore nicht starten
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent FEHLER Rückverfolgung (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 den Monitor über ovirt-ha-broker nicht starten: [Errno 2] Datei oder Verzeichnis nicht gefunden, [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 FEHLER Versuche, den Agenten neu zu startenDann verbinden wir den Speicher und starten den Agenten neu:
hosted-engine --connect-storage
systemctl restart ovirt-ha-agent
systemctl status ovirt-ha-agent
hosted-engine --vm-start
hosted-engine --vm-statusNach dem Start der VM mit hosted-engine versetzen wir sie aus dem Wartungsmodus:
Verfahren zum Versetzen 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 aktuell : True
Hostname : host1.test.local
Host-ID : 1
Engine-Status : {"health": "gut", "vm": "läuft", "detail": "Läuft"}
Punktzahl : 3400
gestoppt : False
Lokale Wartung : False
crc32 : 6d1eb25f
lokale_conf_timestamp : 6222296
Host-Zeitstempel : 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
score=3400
vm_conf_refresh_time=6222296 (Fr 17. Jan 11:40:43 2020)
conf_on_shared_storage=True
wartung=False
zustand=EngineUp
gestoppt=False4) Löschen des hosted engine und aller damit verbundenen Dinge.
Manchmal ist es notwendig, den zuvor installierten hosted engine korrekt zu entfernen — siehe das Handbuch.
Führen Sie einfach den Befehl auf dem Host aus:
/usr/sbin/ovirt-hosted-engine-cleanupDanach entfernen wir die nicht benötigten Pakete, nachdem wir zuvor einige Konfigurationen gesichert haben, falls erforderlich:
yum autoremove ovirt* qemu* virt* libvirt* libguestfs Erstellung eines neuen Rechenzentrums
Referenzdokumentation — oVirt Administrationshandbuch.
Zuerst definieren wir, was ein Rechenzentrum (zitiere aus der Referenz) — ist eine logische Entität, die eine Menge von Ressourcen definiert, die in einer spezifischen Umgebung verwendet werden.
Ein Rechenzentrum ist eine Art Container, der aus besteht:
- 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, Images) in Form von Speicherbereichen (Storage Domains).
Ein Rechenzentrum kann mehrere Cluster umfassen, die aus mehreren Hosts bestehen, auf denen virtuelle Maschinen betrieben werden. Es kann auch mehrere mit ihm verbundene Speicherbereiche geben.
Es können mehrere Rechenzentren vorhanden sein, die unabhängig voneinander arbeiten. In oVirt gibt es eine Trennung von Befugnissen nach Rollen, und Berechtigungen können individuell sowohl auf Ebene des Rechenzentrums als auch auf dessen einzelne logische Elemente eingestellt werden.
Rechenzentren, oder Rechenzentren, wenn es mehrere gibt, werden von einer zentralen Verwaltungsconsole oder einem Portal aus verwaltet.
Um ein Rechenzentrum zu erstellen, gehen wir in das Verwaltungsportal und erstellen ein neues Rechenzentrum:
Compute >> Rechenzentren >> Neu
Da wir gemeinsamen Speicher auf einer SAN verwenden, muss der Speichertyp (Storage Type) Shared sein:
Screenshot mit dem Assistenten zur Erstellung eines Rechenzentrums
Bei der Installation einer virtuellen Maschine mit hosted-engine wird standardmäßig ein Rechenzentrum erstellt – Datacenter1, und bei Bedarf kann der Speichertyp (Storage Type) geändert werden.
Die Erstellung eines Rechenzentrums ist eine unkomplizierte Aufgabe ohne besondere Nuancen, und alle zusätzlichen Aktionen damit 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, und es muss ein separates Rechenzentrum für sie erstellt werden – d.h. jeder einzelne Host mit lokalem Speicher benötigt sein eigenes Rechenzentrum.
Erstellung eines neuen Clusters
Link zur Dokumentation – oVirt Administration Guide.
Ohne weitere Einzelheiten, Cluster – ist eine logische Gruppierung von Hosts, die einen gemeinsamen Speicherbereich haben (in Form von gemeinsamen Festplatten im SAN, wie in unserem Fall). Es ist auch wünschenswert, dass die Hosts im Cluster in der Hardware identisch sind und denselben Prozessor (Intel oder AMD) haben. Am besten ist es, wenn die Server im Cluster vollständig identisch sind.
Ein Cluster gehört zu einem Rechenzentrum (mit einem bestimmten Speichertyp – Local oder Geteilt), und alle Hosts müssen unbedingt zu einem Cluster gehören, abhängig davon, ob sie gemeinsamen Speicher haben oder nicht.
Bei der Installation einer virtuellen Maschine mit hosted-engine auf einem Host wird standardmäßig ein Rechenzentrum erstellt – Datacenter1, zusammen mit einem Cluster – Cluster1, und im weiteren Verlauf können dessen Parameter konfiguriert, zusätzliche Optionen aktiviert und Hosts hinzugefügt werden usw.
Wie gewohnt, um Details zu allen Cluster-Einstellungen zu erhalten, ist es ratsam, die offizielle Dokumentation zu Rate zu ziehen. Zu einigen Besonderheiten bei der Cluster-Konfiguration möchte ich nur hinzufügen, dass es ausreichend ist, nur die grundlegenden Parameter auf der Registerkarte zu konfigurieren, Allgemein.
Ich möchte die wichtigsten Parameter hervorheben:
- Prozessor-Typ – wird basierend darauf ausgewählt, welche Prozessoren auf den Hosts des Clusters installiert sind, von welchem Hersteller sie stammen und welcher Prozessor auf den Hosts der älteste ist, um entsprechend alle verfügbaren Prozessoranweisungen im Cluster zu nutzen.
- Switch-Typ – in unserem Cluster verwenden wir nur Linux Bridge, daher wählen wir diesen aus.
- Firewall-Typ – hier ist alles klar, das ist firewalld, das auf den Hosts aktiviert und konfiguriert sein muss.
Screenshot mit den Cluster-Parametern
Installation zusätzlicher Hosts in einer Self-Hosted Umgebung
in der Dokumentation.
Zusätzliche Hosts für die Self-Hosted Umgebung werden genauso hinzugefügt wie ein normaler Host, jedoch mit einem zusätzlichen Schritt zur Bereitstellung der VM mit hosted engine — Wählen Sie die Bereitstellungsaktion für die hosted engine >> Bereitstellung. Da dem zusätzlichen Host ebenfalls ein LUN für die VM mit hosted engine präsentiert werden muss, bedeutet dies, dass dieser Host bei Bedarf für die Bereitstellung der VM mit hosted engine genutzt werden kann.
Für eine hohe Verfügbarkeit wird dringend empfohlen, mindestens zwei Hosts bereitzustellen, auf denen die VM mit hosted engine platziert werden kann.
Auf dem zusätzlichen Host deaktivieren wir iptables (falls aktiviert) und aktivieren firewalld
systemctl stop iptables
systemctl disable iptables
systemctl enable firewalld
systemctl start firewalldWir installieren die erforderliche KVM-Version (falls notwendig):
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-clearWir richten die benötigten Repositories und den Installer für die hosted engine ein:
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-setupAls nächstes wechseln wir zur Konsole Open Virtualization Manager, fügen einen neuen Host hinzu und gehen Schritt für Schritt vor, wie in .
In der Folge sollten wir nach der Hinzufügung des zusätzlichen Hosts ein Bild in der Administrationskonsole erhalten, das ungefähr dem auf dem Screenshot entspricht.
Screenshot des Admin-Portals — Hosts
Der Host, auf dem die VM mit hosted-engine derzeit aktiv ist, hat eine goldene Krone und den Text „Running the Hosted Engine VM“, der Host, auf dem diese VM bei Bedarf gestartet werden kann – mit der 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 vom aktiven Host auf den Backup-Host migriert werden, um ihn zu warten.
Konfiguration des Power Managements / Fencing auf oVirt-Hosts
Links zur Dokumentation:
- Red Hat Virtualization 4.3 –> Technisches Referenzdokument ->
- oVirt Administrationshandbuch ->
Obwohl es so erscheinen mag, als wären der Host hinzugefügt und konfiguriert, ist dies nicht ganz korrekt.
Für einen reibungslosen Betrieb der Hosts und zur Identifizierung/Behebung von Ausfällen ist die Konfiguration des Power Managements / Fencing erforderlich.
Fencing, oder das Fencing – ist der Prozess des vorübergehenden Ausschlusses eines defekten oder fehlerhaften Hosts aus dem Cluster, während dem entweder die Dienste von oVirt auf diesem oder der Host selbst neu gestartet werden.
Alle Details zu den Definitionen und Parametern des Power Management / Fencing sind wie üblich in der Dokumentation zu finden. Ich werde lediglich ein Beispiel anführen, wie man diesen wichtigen Parameter für Dell R640-Server mit iDRAC 9 konfiguriert.
- Wir gehen im Administrationsportal hinein, klicken auf Compute >> Hosts wählen den Host aus.
- Wir klicken auf Bearbeiten.
- Wir klicken auf den Reiter Power Management.
- Setzen Sie das Häkchen neben der Option Enable Power Management.
- Setzen Sie das Häkchen neben der Option Kdump-Integration, damit der Host nicht in den Fencing-Modus wechselt, während der Kernel-Dump geschrieben wird.
Hinweis.
Nach der Aktivierung der Kdump-Integration auf einem bereits laufenden Host muss dieser gemäß der Vorgehensweise im oVirt Administrationshandbuch neu installiert werden – > -> Hosts neu installieren.
- Optional kann das Häkchen gesetzt werden bei Disable policy control of power management, wenn wir nicht möchten, dass die Stromverwaltung des Hosts durch die Cluster-Planungspolitik (Scheduling Policy) kontrolliert wird.
- Wir klicken auf die Taste (+), um ein neues Stromverwaltungsgerät hinzuzufügen, ein Eigenschaftenbearbeitungsfenster für den Agenten wird geöffnet.
Für iDRAC9 füllen wir die Felder aus:- Adresse – Adresse iDRAC9
- Benutzername / Passwort – entsprechend den Anmeldedaten für den Zugriff auf iDRAC9
- Typ — drac5
- vermerken Sicher
- fügen Sie die folgenden Optionen hinzu: cmd_prompt=>,login_timeout=30
Screenshot mit den Parametern „Power Management“ in den Host-Eigenschaften
Erstellung eines Speicherbereichs oder Storage Domains
Link zur Dokumentation – oVirt Administrationshandbuch, .
Speicherbereich, beziehungsweise ein Speicherbereich – ist ein zentraler Ort zum Speichern von Festplatten virtueller Maschinen, Installationsabbildern, Vorlagen und Snapshots.
Speicherbereiche können mit Rechenzentren verbunden werden, indem verschiedene Protokolle, Cluster- und Netzwerkdateisysteme verwendet werden.
oVirt bietet drei Arten von Speicherbereichen an:
- Datenbereich – für die Speicherung aller Daten, die mit virtuellen Maschinen (Festplatten, Vorlagen) verbunden sind. Datenbereich kann nicht zwischen verschiedenen Rechenzentren geteilt werden.
- ISO-Bereich (veralteter Typ des Speicherbereichs) – für die Speicherung von Installationsabbildern des Betriebssystems. ISO-Bereich kann zwischen verschiedenen Rechenzentren geteilt werden.
- Exportbereich (veralteter Typ des Speicherbereichs) – für die vorübergehende Speicherung von Abbildungen, die zwischen Rechenzentren verschoben werden.
In unserem speziellen Fall verwendet der Speicherbereich vom Typ Datenbereich das Fibre Channel-Protokoll (FCP), um sich mit LUNs auf dem SAN zu verbinden.
Aus Sicht von oVirt ist jeder virtuelle Datenträger, Snapshot oder Template beim Einsatz von Storage (FC oder iSCSI) eine logische Festplatte.
Blockgeräte werden auf den Clustern der Hosts zu einer Einheit mit Volume Group zusammengefasst und anschließend mit 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 vgs und lvs. Es ist selbstverständlich, dass alle Vorgänge mit solchen Festplatten nur über die oVirt-Konsole ausgeführt werden sollten, außer in besonderen Fällen.
Virtuelle Festplatten für VMs können zwei Typen haben - QCOW2 oder RAW. Die Festplatten können "dünn" oder "dick" sein. Snapshots werden immer als "dünn".
" erstellt. Die Verwaltung von Storage-Domains, oder Speichereinheiten, auf die über FC zugegriffen wird, ist recht logisch - für jede virtuelle Festplatte einer VM gibt es ein separates logisches Volume, das nur von einem Host beschreibbar ist. Bei FC-Verbindungen verwendet oVirt eine Art Cluster-LVM.
Virtuelle Maschinen, die sich in einer Storage-Unit befinden, können zwischen Hosts migriert werden, die demselben Cluster angehören.
Wie aus der Beschreibung hervorgeht, bezeichnet ein Cluster in oVirt, wie auch in VMware vSphere oder Hyper-V, im Grunde dasselbe – es handelt sich um eine logische Gruppierung von Hosts, die vorzugsweise eine ähnliche Hardware-Konfiguration aufweisen und einen gemeinsamen Speicher für die Festplatten virtueller Maschinen haben.
Lassen Sie uns direkt zur Erstellung einer Storage-Unit für Daten (VM-Festplatten) übergehen, da ohne diese der Datencenter nicht initialisiert werden kann.
Ich erinnere daran, dass alle den Clustern präsentierten LUNs auf dem Storage über den Befehl „multipath -ll».
Laut , gehen wir ins Portal, gehen zu Speicher >> Domänen -> New Domain und führen die Anweisungen aus dem Abschnitt „FCP-Speicher hinzufügen“ aus.
Nachdem der Assistent gestartet wurde, füllen wir die erforderlichen Felder aus:
- Name — Wir geben den Namen des Clusters an
- Domain Function — Daten
- Storage Type — Fibre Channel
- Host to Use — Wählen Sie den Host aus, auf dem die benötigte LUN verfügbar ist
Im LUN-Listing markieren wir die benötigte, klicken auf Hinzufügen und dann OK. Bei Bedarf können wir die zusätzlichen Parameter der Storage-Unit anpassen, indem wir auf Advanced Parameters.
klicken. Screenshot des Assistenten zur Hinzufügung einer „Storage-Domain“
Nach dem Abschluss der Assistentenarbeiten sollten wir eine neue Storage-Unit erhalten, und unser Datencenter sollte den Status UP, oder initialisiert, erreichen:
Screenshots des Datencenters und der darin enthaltenen Storage-Units:
Erstellung und Konfiguration von Netzwerken für virtuelle Maschinen
Link zur Dokumentation – oVirt Administrationshandbuch,
Netzwerke, oder Netzwerke – dienen zur Gruppierung logischer Netzwerke, die in der virtuellen Infrastruktur oVirt verwendet werden.
Für die Interaktion des Netzwerkadapters einer virtuellen Maschine mit dem physischen Adapter auf dem Host werden logische Schnittstellen vom Typ Linux Bridge verwendet.
Zur Gruppierung und Trennung des Verkehrs zwischen Netzwerken sind auf den Switches VLANs konfiguriert.
Bei der Erstellung 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, selbst wenn sie auf verschiedenen Knoten des Clusters arbeiten.
Die Vorabkonfiguration der Netzwerkadapter auf den Hosts für den Anschluss der virtuellen Maschinen musste in – logische Schnittstelle eingerichtet bond1, alle weiteren Netzwerkeinstellungen sollten nur über das Verwaltungsportal von oVirt vorgenommen werden.
Nach der Erstellung einer VM mit hosted-engine wurde neben der automatischen Erstellung des Rechenzentrums und des Clusters auch automatisch ein logisches Netzwerk zur Verwaltung unseres Clusters erstellt – ovritmgmt, an das diese VM angeschlossen wurde.
Wenn nötig, können die Einstellungen des logischen Netzwerks eingesehen ovritmgmt und angepasst werden, man sollte jedoch vorsichtig sein, um die Kontrolle über die Infrastruktur von oVirt nicht zu verlieren.
Einstellungen des logischen Netzwerks ovritmgmt
Um ein neues logisches Netzwerk für reguläre VMs zu erstellen, gehen wir im Verwaltungsportal zu Netzwerk >> Netzwerke >> Neu, und im Tab Allgemein fügen wir ein Netzwerk mit der benötigten VLAN-ID hinzu und setzen das Häkchen bei „VM-Netzwerk“, was bedeutet, dass es für die Zuordnung zu VMs verwendet werden kann.
Screenshot des neuen logischen Netzwerks VLAN32
Auf dem Tab Cluster, wir verbinden dieses Netzwerk mit unserem Cluster Cluster1.
Danach gehen wir zu Compute >> Hosts, wir gehen nacheinander zu jedem Host, dann zum Tab Netzwerkschnittstellen, und starten den Assistenten Hostnetzwerke einrichten, um das neue logische Netzwerk an die Hosts zu binden.
Screenshot des Assistenten „Hostnetzwerke einrichten“
Der oVirt-Agent wird alle erforderlichen Netzwerkeinstellungen auf dem Host automatisch vornehmen – VLAN und BRIDGE erstellen.
Beispiel für Konfigurationsdateien 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=yes
MTU=1500
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=no
cat ifcfg-bond1.432
# Generiert von 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
# Generiert von 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=noIch erinnere noch einmal daran, dass auf dem Cluster-Host NICHT NOTWENDIG im Voraus manuell Netzwerkschnittstellen zu erstellen 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 zur Bereitstellung einer virtuellen Maschine
Link zur Dokumentation – oVirt Administrationshandbuch, , Abschnitt Bilder hochladen in eine Datenspeicher-Domain.
Ohne ein Installationsabbild des Betriebssystems kann die virtuelle Maschine nicht installiert werden, obwohl dies natürlich kein Problem darstellt, wenn im Netzwerk beispielsweise mit bereits erstellten Abbilden.
In unserem Fall gibt es diese Möglichkeit nicht, deshalb 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 sie als veraltet angesehen, und daher können Abbilder jetzt direkt über das Administrationsportal in die Storage-Domain hochgeladen werden.
Im Administrationsportal gehen wir zu Speicher >> Festplatten >> Upload >> Start
Wir fügen unser Betriebssystemabbild als ISO-Datei hinzu, füllen alle Felder aus und klicken auf die Schaltfläche "Verbindung testen".
Screenshot des Assistenten zum Hinzufügen des Installationsabbilds
Wenn wir einen Fehler dieser Art erhalten:
Bild konnte aufgrund eines Netzwerkfehlers nicht auf die Festplatte d6d8fd10-c1e0-4f2d-af15-90f8e636dadc hochgeladen werden. Stellen Sie sicher, dass der Dienst ovirt-imageio-proxy installiert und konfiguriert ist und dass das CA-Zertifikat von ovirt-engine im Browser als vertrauenswürdige CA registriert ist. Das Zertifikat kann von https://ovirt.test.local/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA abgerufen werden.
müssen wir das oVirt-Zertifikat in "Vertrauenswürdige Stammzertifizierungsstellen„ (Trusted Root CA) auf der Administrations-Workstation hinzufügen, von der aus wir versuchen, das Abbild hochzuladen.
Nachdem das Zertifikat zu Trusted Root CA hinzugefügt wurde, klicken wir erneut auf "Verbindung testen", wir sollten erhalten:
Die Verbindung zum ovirt-imageio-proxy war erfolgreich.Nachdem die Aktion zum Hinzufügen des Zertifikats durchgeführt wurde, können wir versuchen, das ISO-Abbild erneut in die Storage-Domain hochzuladen.
Im Prinzip kann ein separates Storage-Domain mit dem Typ Data erstellt werden, um Abbilder und Vorlagen getrennt von den VM-Festplatten zu speichern, oder sogar sie im Storage-Domain für hosted engine zu speichern, aber das liegt im Ermessen des Administrators.
Screenshot mit ISO-Abbildern in der Storage-Domain für hosted engine
Erstellung einer virtuellen Maschine
Link zur Dokumentation:
oVirt Virtual Machine Management Guide –>
Nach dem Hochladen des Installations-Images mit dem Betriebssystem in oVirt kann man direkt mit der Erstellung der virtuellen Maschine beginnen. Es wurde viel Arbeit geleistet, aber wir befinden uns bereits in der finalen Phase, für die das Ganze gedacht war – um eine ausfallsichere Infrastruktur für das Hosting hochverfügbarer virtueller Maschinen zu erhalten. Und das Beste daran ist, dass alles vollkommen kostenlos ist – kein Cent wurde für den Erwerb von Softwarelizenzen ausgegeben.
Für die Erstellung einer virtuellen Maschine mit CentOS 7 muss ein Installations-Image des Betriebssystems hochgeladen werden.
Wir gehen ins Administrationsportal, navigieren zu Compute >> Virtuelle Maschinen, und starten den Assistenten zur Erstellung der VM. Wir füllen alle Parameter und Felder aus und klicken auf OK. Es ist sehr einfach, wenn man der Dokumentation folgt.
Als Beispiel nenne ich die grundlegenden und zusätzlichen Einstellungen für eine hochverfügbare VM, mit einer erstellten Festplatte, die mit dem Netzwerk verbunden ist, und die von einem Installations-Image bootet:
Screenshots der 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.
Dafür gehen wir über das Administrationsportal auf die Konsole dieser VM:
Screenshot der Einstellungen des Administrationsportals zum Verbinden mit der VM-Konsole
Um sich mit der VM-Konsole zu verbinden, muss die Konsole zunächst in den Eigenschaften der virtuellen Maschine konfiguriert werden.
Screenshot der VM-Einstellungen, Tab 'Konsole'
Zur Verbindung mit der VM-Konsole kann man beispielsweise .
verwenden. Um sich direkt im Browserfenster mit der VM-Konsole zu verbinden, müssen die Verbindungseinstellungen folgendermaßen sein:
Nach der Installation des Betriebssystems auf der VM ist es ratsam, den oVirt-Gast-Agenten zu installieren:
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.serviceSo wird die erstellte VM infolge unserer Maßnahmen hochverfügbar sein, d.h. im Falle eines Cluster-Knotenfehlers, auf dem sie ausgeführt wird, wird oVirt sie automatisch auf dem zweiten Knoten neu starten. Außerdem kann diese VM zwischen den Hosts des Clusters zur Wartung oder für andere Zwecke migriert werden.
Fazit
Ich hoffe, dieser Artikel hat vermittelt, dass oVirt ein durchaus vernünftiges Werkzeug zur Verwaltung virtueller Infrastrukturen ist, das sich nicht so schwer bereitstellen lässt – es ist wichtig, bestimmte Regeln und Anforderungen zu befolgen, die sowohl im Artikel als auch in der Dokumentation beschrieben sind.
Aufgrund des großen Umfangs des Artikels konnten viele Dinge nicht aufgenommen werden, wie schrittweise Anleitungen zu verschiedenen Meistern mit allen ausführlichen Erklärungen und Screenshots, lange Ausgaben bestimmter Befehle usw. Tatsächlich wäre es nötig gewesen, ein ganzes Buch zu schreiben, was nicht besonders sinnvoll ist, da ständig neue Softwareversionen mit Neuerungen und Änderungen erscheinen. Das Wichtigste ist, das Prinzip zu verstehen, wie alles zusammen funktioniert und einen allgemeinen Handlungsalgorithmus zur Erstellung einer ausfallsicheren Plattform zur Verwaltung von virtuellen Maschinen zu erhalten.
Obwohl wir die virtuelle Infrastruktur erstellt haben, müssen wir jetzt lernen, wie sie sowohl zwischen ihren einzelnen Elementen: Hosts, virtuellen Maschinen, internen Netzwerken als auch mit der Außenwelt interagiert.
Dieser Prozess ist eine der Hauptaufgaben eines System- oder Netzwerkadministrators, die im nächsten Artikel behandelt wird – über die Verwendung von virtuellen Routern VyOS in der ausfallsicheren Infrastruktur unseres Unternehmens (wie Sie erraten haben, werden sie als virtuelle Maschinen in unserem oVirt-Cluster betrieben).
Quelle: habr.com
