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.

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
  

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!