6 Minuten Lesezeit (1283 Worte)

Die Architektur des Oracle Linux Virtualization Managers (OLVM)

Mittwoch, 23. März 2022

Im ersten Blogartikel dieser Reihe (Der Oracle Linux Virtualization Manager im Überblick) wurde bereits ein grober Aufbau beschrieben und ein Schaubild zur Architektur des OLVM gezeigt. In diesem Artikel wird nun geklärt, über welche Webschnittstellen eine OLVM-Umgebung administriert wird und wie sie aufgebaut ist. Zum Aufbau zählen sowohl logische als auch physische Komponenten, sowie Software-Komponenten für die Virtualisierung.

Weboberflächen - drei webbasierte Portale

Der OLVM bietet drei webbasierte Portale, mit denen sich eine OLVM-Umgebung konfigurieren, verwalten und überwachen lässt. Das Administrations Portal, VM Portal und Cockpit Portal.

Das Administrations Portal ist die grafische Oberfläche des oVirt Engine Servers. Über diese Weboberfläche können Administratoren alle Elemente einer OLVM-Umgebung überwachen und verwalten. Zu diesen Aufgaben gehören:

Erstellung und Verwaltung der virtuellen Infrastruktur (Netzwerke, Speicherdomänen)
Installation und Verwaltung von Hosts
Erstellung und Verwaltung logischer Entitäten (Data Center, Cluster)
Erstellung und Verwaltung von virtuellen Maschinen
Benutzer- und Berechtigungsverwaltung

Die nachfolgende Abbildung zeigt das Dashboard des Administrationsportals, welches nach der Anmeldung angezeigt wird:

Über das leichtgewichtigere VM Portal lassen sich virtuelle Maschinen etwas einfacher erstellen, verwalten und überwachen. Es bietet dafür aber nicht alle Funktionen des Admin Portals. Die nachfolgende Abbildung zeigt die Startseite des VM Portals:

Das Cockpit Portal ist eine grafische Weboberfläche für Linux Server, die in erster Linie nichts mit dem OLVM zu tun hat. Anders als das Administrations Portal und das VM Portal, wird das Cockpit Portal bei der OLVM-Installation nicht mitinstalliert und muss manuell über die Kommandozeile auf jedem Host installiert werden. Das Portal lässt sich für die oVirt Engine entweder mit einem entsprechenden Plugin erweitern oder mit einem erweitertem Softwarepaket installieren. Mit dieser Erweiterung können dann auch OLVM-Komponenten überwacht werden. Über das Cockpit Portal können die Ressourcen eines KVM-Hosts überwacht und Verwaltungsaufgaben ausgeführt werden.

Die Administration einer OLVM-Umgebung ist über die Kommandozeile nicht direkt möglich. Es wird lediglich ermöglicht die Engine zu steuern (Starten, Stoppen, Wartungsmodus, Backup/Restore, ...). Des Weiteren können virtuelle Maschinen, die sich auf einem entsprechenden Host befinden, mit dem Kommandozeilen-Tool virsh (https://libvirt.org/manpages/virsh.html) erstellt, gelöscht, gestartet, gestoppt und verwaltet werden.

Systemarchitektur - logische und physische Komponenten

In diesem Abschnitt gehe ich auf die Systemarchitektur ein, die aus verschiedenen logischen und physischen Komponenten besteht.

Dieses Schaubild zeigt einen beispielhaften Aufbau einer OLVM-Umgebung mit einem Data Center, zwei Clustern und insgesamt drei Hosts:

Der Kern des OLVM ist die oVirt Engine. Diese ist eine auf JBoss basierende Java-Anwendung, die einen Webservice für das Admin und VM Portal ausführt und eine zentrale Verwaltung für die Virtualisierung bietet. Die Engine kommuniziert mit VDSM-Diensten (Virtual Desktop and Server Manager), die als Deamons auf den einzelnen KVM-Hosts ausgeführt werden. Der VDSM-Dienst ist im Auftrag der Engine für sämtliche Aufgaben zum Verwalten eines KVM-Hosts zuständig:

Verwalten des KVM-Hosts
Erstellen, Bereitstellen, Starten, Stoppen, Migrieren und Überwachen von virtuellen Maschinen
Verwalten logischer Netzwerke
Verwalten von virtuellen Festplatten und Storage-Domains
Konfigurieren & Verwalten von Hochverfügbarkeit für Cluster, Hosts und virtuelle Maschinen

Die Engine ist in der Lage ein oder mehrere Data Center zu verwalten. Ein Data Center ist eine logische Einheit für alle physischen und logischen Ressourcen einer Umgebung und besteht aus einem oder mehreren Clustern. Ein Cluster ist eine logische Gruppierung bzw. Zusammenfassung von physischen Hosts, die die selben Speicherdomänen gemeinsam verwenden. Eine Speicherdomäne kann nicht von mehreren Clustern verwendet werden. Des Weiteren müssen alle Hosts eines Clusters über denselben CPU-Typ (Intel/AMD) verfügen. KVM-Hosts sind physische Computer (Bare-metal Server) auf denen der KVM-Hypervisor verwendet wird, um virtuelle Maschinen zu hosten.

Virtuelle Maschinen können nach eigenen Spezifikationen erstellt oder von vorhandenen Templates geklont werden. Es ist auch möglich eine OVA-Datei (Open Virtual Appliance) zu importieren. Durch Snapshots lassen sich Live-Aufnahmen einer virtuellen Maschine erstellen.

Eine Storage Domain, oder auch Speicherdomäne genannt, ist eine Sammlung von Images (ISO-Files, Templates, virtuellen Maschinen und Snapshots), die von einem Cluster verwendet werden. Virtuelle Maschinen derselben Speicherdomäne, können zwischen Hosts desselben Clusters migriert werden. Die genauen Speicherorte für Storage Domains können Blockgeräte (SAN - iSCSI, Fibre Channel) oder Dateisysteme (NAS - NFS, Gluster) sein.

Hostarchitektur des OVLM

Nachdem wir die Systemarchitektur einer OLVM-Umgebung betrachtet haben, werde ich hier auf die Hostarchitektur eingehen, also die einzelnen Komponenten eines Hosts und deren Zusammenhang.

Auf jedem KVM-Host wird ein Host-Agent als Daemon ausgeführt. Es handelt sich dabei um den VDSM-Dienst (Virtual Desktop and Server Manager), der mit der Engine kommuniziert. Die folgenden Aufgaben werden vom Host-Agent erledigt:

Verwalten/Überwachen von physischen Ressourcen (Speicher, Netzwerk)
Verwalten/Überwachen der virtuellen Maschinen eines Hosts
Informationen für Protokolle und Statistiken sammeln

Der libvirt-Dienst wird ebenfalls als Daemon auf KVM-Hosts ausgeführt. Dieser Dienst bietet eine API zur Verwaltung verschiedener Hypervisor (einschließlich KVM). VDSM verwendet libvirt, um den gesamten Lebenszyklus virtueller Maschinen und ihrer virtuellen Geräte auf dem Host zu verwalten und Statistiken über diese zu sammeln.

Mit QEMU (Quick Emulator) kann KVM zu einem vollständigen Hypervisor werden, indem die Hardware für die virtuellen Maschinen wie CPU, Speicher, Netzwerk und Festplattengeräte emuliert wird. Mit KVM kann QEMU Code in der virtuellen Maschine direkt auf der Host-CPU ausführen. Dadurch kann das Betriebssystem einer virtuellen Maschine ohne abstrahierende Schnittstellen direkt auf die Ressourcen des Hosts zugreifen.

Guest Agents werden innerhalb einer virtuellen Maschine ausgeführt, um der Engine Informationen zur Ressourcen-Auslastung zur Verfügung zu stellen. Die Kommunikation wird dabei über eine virtualisierte serielle Verbindung abgewickelt. Der Guest Agent stellt folgende Informationen bereit:

Informationen, Benachrichtigungen und Aktionen zwischen der Engine und dem Gast
Name, Betriebssystem, IP-Adressen und weitere Details
Netzwerk- und RAM-Nutzung
Installierte Anwendungen

Bereitstellung der Engine - standalone oder self-hosted

Zum Schluss gehe ich auf die Möglichkeiten ein, mit denen sich der OLVM bereitstellen lässt. Die Bereitstellung der Engines kann auf zwei verschiedene Arten umgesetzt werden.

Wird die Engine auf einem beliebigen und unabhängigen Linux-Host installiert, wird sie als standalone Engine bezeichnet. Alternativ kann die Engine innerhalb der OLVM-Umgebung in einer virtuellen Maschine ausgeführt werden. Diese Bereitstellung wird dann als self-hosted Engine bezeichnet.

Eine standalone Engine wird auf einem separaten Host bereitgestellt und ausgeführt. Eine Migration der Engine ist in diesem Fall nicht möglich. Bei dieser Variante ist die Engine nicht hochverfügbar, da der entsprechende Host ausfallen könnte. Dadurch kann es zu ungeplanten Ausfällen der OLVM-Umgebung kommen. Laufende virtuelle Maschinen bleiben dabei unberührt und können nur noch über das Kommandozeilentool virsh verwaltet werden. Ohne den OLVM können diese jedoch nicht automatisch neugestartet oder migriert werden.

Eine self-hosted Engine ist der standalone Engine sehr ähnlich. Der Unterschied liegt darin, dass eine self-hosted Engine innerhalb einer virtuellen Maschine auf einem beliebigen KVM-Host der Umgebung ausgeführt wird. Da die Engine in einer virtuellen Maschine und nicht direkt auf physischer Hardware ausgeführt wird, benötigt eine self-hosted Engine weniger physische Ressourcen. Die Engine kann so konfiguriert werden, dass sie hochverfügbar ist. Wenn der Host, auf dem die Engine ausgeführt wird, in den Wartungsmodus wechselt oder komplett ausfällt, wird die virtuelle Maschine mitsamt der Engine auf einen anderen Host in der Umgebung migriert. Um die Hochverfügbarkeit für die Engine auf diese Weise umsetzen zu können, sind mindestens zwei KVM-Hosts erforderlich, die die Engine ausführen können.

Die nachfolgende Abbildung zeigt eine beispielhafte OLVM-Umgebung mit einer self-hosted Engine. In einem Fehlerfall, wird die Engine auf den nächstbesten Host (Host 2 oder Host 3) migriert.

Ausblick auf die weitere Artikel zum Thema

Im dritten Artikel dieser Reihe werde ich erklären, wie die Lizenzierung von Oracle-Datenbanken durch CPU-Pinning/Hard Partitioning optimiert werden kann, um Lizenzkosten einzusparen. Im vierten und letzten Artikel handelt es sich schließlich um Hochverfügbarkeit mit dem Oracle Linux Virtualization Manager.

Haben Sie weiteres Interesse oder Fragen zum Oracle Linux Virtualization Manager? Sprechen Sie uns gerne an!

Hier finden Sie alle Teile der Reihe

Teil 1: Der Oracle Linux Virtualization Manager im Überblick