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

Cloudinitiative GAIA-X wächst [10.09.2021]

GAIA-X, die europäische Initiative zum Aufbau einer leistungsfähigen und sicheren Dateninfrastruktur, wächst. Erst vor kurzem haben sich mit Commerzbank, Deutsche Bahn und Software AG drei Konzerne aus Deutschland dem Projekt angeschlossen. Die Notwendigkeit einer europäischen Cloudalternative scheint immer mehr Unternehmen, unabhängig von Größe und Branche, bewusst zu werden. [mehr]

NAS-Anwendungen in der AWS-Cloud [10.09.2021]

Der Dienst "Amazon FSx für NetApp ONTAP" ist ab sofort weltweit verfügbar. Mit dem AWS-nativen Managed Service basierend auf NetApp ONTAP-Software lassen sich erstmals komplette, vollständig gemanagte NetApp ONTAP-Dateisysteme in der Cloud launchen und betreiben. [mehr]

Tipps & Tools

Mitarbeiter wollen wieder öfter ins Büro [21.09.2021]

Die Präsenzkultur neigt sich ihrem Ende zu und die Vorstellung, nach Corona wieder fünf Tage in der Woche ins Büro zu gehen, ist für viele Menschen undenkbar geworden. Durch die Pandemie ist aber ebenso klar geworden, dass auch ein rein virtueller Austausch nicht des Rätsels Lösung ist. Eine Studie zu Meeting-Trends zeigt nun, dass die Deutschen ihre Kollegen vermissen und mit der Qualität von virtuellen Konferenzen unzufrieden sind. [mehr]

Die größten Aufreger bei Videokonferenzen [7.09.2021]

Videokonferenzen haben sich im beruflichen Umfeld fest etabliert. Auch wenn die Technik meist keine Rätsel mehr aufgibt: In Sachen richtiges Benehmen im Online-Meeting herrscht offenbar noch Nachholbedarf. Laut einer aktuellen Umfrage von ClickMeeting wünschen sich viele Anwender klare Benimmregeln. Fast ein Drittel ist zudem der Meinung, dass Teilnehmer in Online-Meetings eher gute Manieren vermissen lassen als bei persönlichen Meetings – und sei es auch nur eine adäquate Verabschiedung. [mehr]

Buchbesprechung

Windows 10 Power-Tipps

von Günter Born

Anzeigen