Seite 2 - Red Hat Virtualization: Best Practices (1)

Lesezeit
3 Minuten
Bis jetzt gelesen

Seite 2 - Red Hat Virtualization: Best Practices (1)

07.06.2021 - 00:00
Veröffentlicht in:
RHV-Architektur im Vergleich zu vCenter
Das zentrale Element einer Enterprise-Virtualisierung mit RHV ist der Managementserver, kurz RHV-M. RHV-M läuft als Java-Applikation auf dem Web-Application-Server Jboss und lagert die Konfiguration in einer PostgreSQL-Datenbank. Neben zwei Web-UIs (Admin und User) offeriert RHV-M auch eine Rest-API und eine CLI. Als Hypervisoren steuert RHVM entweder Server mit einem vollwertigen RHEL 7.x oder einer abgespeckten RHEL-Version RHV-H. Auf einem vollen RHEL können parallel zum Hypervisor andere Dienste laufen. Der RHV-H-Knoten betreibt nur virtuelle Maschinen. Eine Lösung mit RHV-H-Knoten kommt den Anwender günstiger, weil er für diese Knoten nur eine RHV-Subscription, aber keine zusätzliche RHEL-Subscription benötigt. Daher sind Setups mit RHV-H-Nodes heute bevorzugt im Einsatz. Im Übrigen gibt es bei RHV keine Lizenzen mit unterschiedlichem Funktionsumfang.

Der Kunde abonniert eine RHV-Subscription pro Hypervisor, stets mit vollem Funktionsumfang. Auf den Nodes arbeitet KVM als Hypervisor, mit QEMU für die Peripherievirtualisierung und libvirt als lokaler VMManager. Den libvirt-Dienst selbst steuert der vdsm-Daemon, der die Kommunikation zwischen Hypervisor und RHVM übernimmt.

Das Konzept ist vergleichbar mit einem vCenter-Server, jedoch gibt es ein paar grundlegende Unterschiede der Architekturen. Eine vSphere-Umgebung lagert diverse Informationen zur Umgebung sowohl im vCenter-Server als auch auf den angebundenen Hypervisoren. Fällt der vCenter-Server selbst aus, kann der Administrator ihn relativ problemlos gegen einen Neuen ersetzen, da vCenter die Informationen zu VMs, Clustern und Netzwerken von den Nodes zurückliest. Ausgenommen davon sind einige Informationen wie die Konfiguration der Distributed vSwitches. Ebenso kann eine vSphere-Umgebung auch ohne laufenden vCenter-Server ausgefallene VMs per Failover auf andere Nodes übernehmen. Die dazu nötige Technologie steckt im ESXi-Host selbst, nicht im Manager. Das funktioniert in kleineren vSphere-Umgebungen recht gut, kann in sehr großen Setups aber zu Problemen führen.

RHV arbeitet etwas anders. Der einzelne Hypervisor ist relativ "dumm" und alle relevanten Daten lagern in der Datenbank des RHV-M-Knotens. Zudem ist der RHV-Manager für den Failover der VMs zuständig. Das hat auf der einen Seite Vorteile, denn ein zentraler "Master" kann keine Split-Brain-Probleme bei der Entscheidung über die Failover-Regeln bekommen. Fehlt der RHV-M-Knoten allerdings, gibt es gar keinen VM-Failover.

Daher sollten Systemverwalter die Datenbank des RHV-M regelmäßig sichern, da ein Verlust der Datenbank größere Reparaturarbeiten mit sich bringt. Bei RHV kann der Admin nicht einfach einen neuen RHV-M aufsetzen und die Konfiguration von den Hypervisor-Knoten importieren. Aus diesem Grund war es bei RHV auch lange Zeit nicht möglich, den RHV-Manager selbst als VM auf der eigenen Plattform zu betreiben. Erst die mit 3.4 eingeführte Funktion der "Hosted Engine" macht das möglich. Dabei läuft der RHV-Manager selbst als eine Art privilegierte VM. Einige ausgewählte Hypervisor-Nodes machen diese VM über das Cluster-Managementtool "Pacemaker" hochverfügbar.

Beim Ausfall eines einzelnen Hypervisors sorgt dann das Hosted-Engine-Management dafür, dass zunächst der RHV-M-Knoten neu startet. Steht dieser wieder zur Verfügung, kümmert er sich im Anschluss um den Failover aller anderen VMs.

Grundlage Shared Storage
Eine wesentliche Rolle bei der Enterprise-Virtualisierung spielt der Shared Storage, denn ohne ihn ist ein schneller VM-Failover gar nicht möglich. Wie vSphere unterstützt RHV dazu grundsätzlich Block-Storage mit Fibre Channel (FC), Shared-SAS oder iSCSI sowie NFS als Shared Filesystem. Prinzipiell kann RHV mit allen Posix-konformen verteilten Dateisystemen arbeiten, wie GFS2 oder GlusterFS. Ebenso offeriert Red Hat mit RHHI (Red Hat Hyperconverged Infrastructure) eine dem vSAN vergleichbare Technologie für den Hyperconverged-Betrieb von Software-defined Storage und Virtualisierung auf denselben Rechenknoten. Hierbei kombiniert Red Hat das verteilte Dateisystem GlusterFS mit RHV – dazu später mehr.

Bei der Anbindung des Block-Storage unterscheiden sich vSphere und RHV. vSphere arbeitet grundsätzlich mit seinem eigenen Cluster-Dateisystem VMFS. Auf ein solches verzichtet RHV gänzlich. Anstelle des Dateisystems setzt RHV einfach auf den unter Linux weit verbreiteten Logical-Volume-Manager LVM2. Damit dieser auch im Cluster funktioniert, übernimmt jeweils ein Hypervisor-Knoten die Rolle des sogenannten "Storage Pool Managers" (SPM), der dann alle Einstellungen und Modifikationen an der Speicherkonfiguration vornimmt.


Bild 2: Der New-Virtual-Machine-Dialog des Web-Admin-Tools erstellt leere virtuelle Maschinen oder klont VMs
aus zuvor bereitgestellten Templates.

Der Vorteil der LVM-Architektur bei RHV liegt darin, dass der Zugriff zum Shared Storage ohne den Zwischen-Layer eines Cluster-Dateisystems arbeitet und daher schnellere Speicherzugriffe für VMs ermöglicht. Allerdings muss der SPM alle Storage-Verwaltungsaufgaben erledigen und kann in großen Installationen zum Flaschenhals werden.

Optional kann RHV auch mit Shared-Storage-Technologien der Scale-out-Virtualisierungsplattform OpenStack arbeiten. Dazu bindet der Administrator seine RHV-Installation an bestehende Glance- und Cinder-Dienste an. Diese Services sollten aus Performancegründen jedoch nicht als primärer Storage für Enterprise-VMs dienen. Vielmehr hilft die Integration von RHV und OpenStack dabei, bestehende Enterprise-VMs sanft auf eine OpenStack-Plattform zu migrieren – oder im Gegenzug VMs von OpenStack in RHV zu importieren. Die Storage-Live-Migration der VM-Disks von File- zu Block-Storage oder umgekehrt arbeitet ohne Probleme.

Seite 1: Am Anfang war KVM
Seite 2: Vergleich zu vCenter


Im zweiten Teil des Workshops wenden wir uns nach einem kurzen Blick auf mögliche Netzwerkvarianten der Installation von RHV zu. Im dritten Teil erklären wir, was beim laufenden Betrieb von RHV wichtig ist und stellen eine hyperkonvergente Variante für kleine Umgebungen vor.

<< Vorherige Seite Seite 2 von 2


dr/ln/Max Lessel

[1] www.ovirt.org

Ähnliche Beiträge

Azure mit lokalen Netzen verbinden (3)

Azure bietet vielfältige Möglichkeiten, um Ressourcen in der Cloud mit lokalen Netzwerken zu verbinden. Dazu gehören auch Sicherheitsmechanismen und Loadbalancer, die den Datenverkehr zwischen Cloud und lokalem Rechenzentrum nicht nur zur Verfügung stellen, sondern absichern und hochverfügbar konfigurieren. IT-Administrator zeigt die Wege auf, um die Cloudumgebung mit dem lokalen Netzwerk zu verbinden. Im dritten und letzten Teil der Workshopserie zeigen wir, wie Sie virtuelle Firewalls hochziehen.

Azure mit lokalen Netzen verbinden (2)

Azure bietet vielfältige Möglichkeiten, um Ressourcen in der Cloud mit lokalen Netzwerken zu verbinden. Dazu gehören auch Sicherheitsmechanismen und Loadbalancer, die den Datenverkehr zwischen Cloud und lokalem Rechenzentrum nicht nur zur Verfügung stellen, sondern absichern und hochverfügbar konfigurieren. IT-Administrator zeigt die Wege auf, um die Cloudumgebung mit dem lokalen Netzwerk zu verbinden. Im zweiten Teil binden wir den Connection Broker an und erklären, was es mit dem Cloud Witness auf sich hat.

Azure mit lokalen Netzen verbinden (1)

Azure bietet vielfältige Möglichkeiten, um Ressourcen in der Cloud mit lokalen Netzwerken zu verbinden. Dazu gehören auch Sicherheitsmechanismen und Loadbalancer, die den Datenverkehr zwischen Cloud und lokalem Rechenzentrum nicht nur zur Verfügung stellen, sondern absichern und hochverfügbar konfigurieren. IT-Administrator zeigt die Wege auf, um die Cloudumgebung mit dem lokalen Netzwerk zu verbinden. Im ersten Teil der Workshopserie schildern wir das Prinzip virtueller Netzwerke.