Fachartikel

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

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
7.06.2021/dr/ln/Max Lessel

Nachrichten

Zerto für Kubernetes erhältlich [21.04.2021]

Zerto hat die Verfügbarkeit von Zerto for Kubernetes (Z4K) bekanntgegeben und eine Vorschau auf Zerto 9.0 präsentiert. Z4K wendet Zertos Continuous-Data-Protection-Technologie auf containerisierte Anwendungen an und soll damit eine neue Sichtweise für die Sicherung und Notfallwiederherstellung von Anwendungen und Daten über Infrastrukturen in Cloud- und On-Premises hinweg bieten. [mehr]

Dell trennt sich von VMware [15.04.2021]

Nach gut 17 Jahren wird VMware offenbar wieder zu einem eigenständigen Unternehmen. Dell, das knapp 81 Prozent an VMware hält, will sich im vierten Quartal dieses Jahres von seiner Beteiligung trennen. Dadurch hofft das Unternehmen auf knapp 10 Milliarden US-Dollar, um so unter anderem bestehende Schulden zu tilgen. [mehr]

Tipps & Tools

EGroupware 21.1 erschienen [4.06.2021]

Die EGroupware GmbH veröffentlicht Version 21.1 ihrer gleichnamigen Open-Source-Groupware. Diese verfügt über neue Kompenten wie ein Kanban-Modul oder eine Firewall und eine verbesserte Telefonie-Integration. [mehr]

Stehhilfe fürs Smartphone [23.05.2021]

Es dominiert den Berufsalltag immer mehr und gibt auch äußerlich keinen Anlass, es am Arbeitsplatz zu verstecken: Das Smartphone sollten Sie jederzeit bestens greif- und sichtbar am Schreibtisch positionieren und mit ihm quasi auf Augenhöhe agieren! [mehr]

Buchbesprechung

Noch analog oder lebst du schon?

von Rolf Drechsler und Jannis Stoppe

Anzeigen