Red Hat Virtualization: Best Practices (1)

Lesezeit
2 Minuten
Bis jetzt gelesen

Red Hat Virtualization: Best Practices (1)

07.06.2021 - 00:00
Veröffentlicht in:
Mit "Red Hat Virtualization" bietet Red Hat eine konkurrenzfähige und kostengünstige Alternative zu VMwares vSphere-Plattform an. Spätestens seit der Version 4 stellt die quelloffene Lösung eine zuverlässige Enterprise-Virtualization-Plattform dar, die den Vergleich mit der Konkurrenz nicht scheuen braucht. In diesem Workshop stellen wir die Plattform vor. Im ersten Teil gehen wir auf die Grundlagen von RHV ein und erklären die architektonischen Unterschiede zu vCenter.
Anfang 2000 revolutionierte VMware die Art und Weise, wie Unternehmen ihre Server einsetzen. Bis dahin brauchte es für jeden Dienst auch einen eigenen physischen Server. Mit dem Siegeszug von VMware ESX und vSphere änderte sich der Betrieb in den Rechenzentren dramatisch. An die Stelle verschieden konfigurierter Maschinen für die unterschiedlichen Dienste traten Rechen-Cluster mit Shared Storage und Virtualisierung. Doch an der Basistechnologie für Enterprise-Virtualisierung gibt es kaum noch etwas zu verbessern. So wenden sich viele Softwarehersteller neuen Technologien wie Scale-out-Virtualisierung und natürlich Containern zu. Selbst VMware hat auf seiner jährlichen Hausmesse VMworld angekündigt, den ESXi-Hypervisor ab Version 6.7 nur noch mit Bugfixes, aber keinen neuen Features mehr zu versehen. VMware will hier künftig ebenfalls auf Containertechnologien setzen, was jedoch schwerfallen dürfte, da das Unternehmen zwar über einen eigenen Hypervisor, aber kein eigenes Betriebssystem verfügt.

Für Anwender gibt es in der Zwischenzeit eine Reihe von Optionen bei der Wahl der Virtualisierungsplattform. Technologisch ist vSphere aufgrund der hohen Verbreitung und langen Entwicklungszeit weiterhin die erste Wahl. Es gibt Unmengen Drittanbieter-Software für VMware und ausreichend geschulte Spezialisten für den Betrieb.

Allerdings stehen die technischen Funktionen der Plattform heute in Kontrast zu den Lizenzkosten. VMwares "Enterprise License Agreements" bieten Anwendern zwar ein stark vergünstigtes Einsteigerpaket – aber nach drei Jahren erfolgt ein böses Erwachen beim Lizenz-Renewal. Unternehmen mit einem hohen Anteil an Windows-Servern in der IT ziehen daher immer häufiger Hyper-V als Ausweichlösung in Betracht – und sei es nur, um die parallel dazu arbeitende vSphere-Umgebung zu verkleinern und damit die Lizenzkosten zu drücken.

Parallel bietet Red Hat mit der "Red Hat Virtualization" kurz "RHV" eine auf Open Source basierende Lösung, die spätestens mit der Version 4 auch die nötige Stabilität liefert und sich sehr einfach Handhaben lässt. RHV offeriert alle üblichen Enterprise-Virtualization-Funktionen wie VM und Storage-Live-Migration oder Failover. Nur eine Fault-Tolerance-Option fehlt, aber die kommt in der Praxis ohnehin eher selten zum Einsatz. RHV hat dabei bis zur aktuellen Version 4.2 einen durchaus längeren und teils holprigen Weg hinter sich.

Am Anfang war KVM
RHV (Anfangs "Red Hat Enterprise Virtualization", RHEV) entwickelte sich aus der 2008 zugekauften israelischen Softwareschmiede Qumvranet. Die hatte den Open-Source-Hypervisor KVM als Alternative zu Xen oder ESX entwickelt und damit für Aufsehen in der Open-Source-Community gesorgt. Das kernel.org-Team akzeptierte die KVM-Technologie rasch und fügte sie bereits 2007 dem offiziellen Linux-Kernel hinzu, sodass KVM auf allen Linux-Derivaten seit der Kernel-Version 2.6.20 zur Verfügung steht.

Qumvranet verfolgte mit KVM aber eigene Ziele. Das Unternehmen wollte ursprünglich eine Windows-Desktop-Virtualisierungslösung im Markt etablieren. Neben KVM als Open-Source-Hypervisor auf Linux entwickelte Qumvranet dazu ein Open-Source-Remote-Desktop-Protokoll "Spice" als Alternative zu RDP, VNC oder Nomachine. Nach der Übernahme geriet diese Funktion – obwohl sie bis heute in RHV steckt – aber ein wenig ins Hintertreffen. Red Hat hatte Qumvranet hauptsächlich deswegen gekauft, um ein Wörtchen im beliebten Server-Virtualisierungsmarkt mitreden zu können. Vor lauter Eile, einen Teil dieses Virtualisierungsmarkts zu ergattern, beging Red Hat aber einen folgenschweren Fehler: Es brachte 2010 die Version RHEV 2.2 auf den Markt. Das Produkt war zum einen unfertig und fehlerbehaftet und hatte zum anderen eine für Red-Hat-Anwender schwer zu akzeptierenden Komponente. Der zentrale Managementserver lief als .NET-Applikation auf Windows Server 2008. Wer also RHEV verwenden wollte, musste dazu einen Windows Server 2008 aufsetzen und verwalten.


Bild 1: Das Dashboard verschafft dem Administrator einen Überblick über die komplette RHV-Umgebung.

Erst mit RHEV 3.0 im Jahr 2012 fiel der Windows-Server als zentrale Komponente weg. Allerdings sorgte auch hier die Eile der Entwicklung für etliche Nachteile. Für RHEV 3.0 hatte Red Hat den .NET-Code von RHEV 2.2 nach Java auf Jboss konvertiert. Frühe Releases des RHEV-3-Managers hatten mit Performance-, Datenbank- und Ressourcenproblemen zu kämpfen. Insider bezeichnen daher die Version 3.4 aus dem Jahr 2014 als die erste richtig stabile RHEV-Version. Mit dem nunmehr umbenannten RHV 4 präsentierte Red Hat 2016 eine deutlich verbesserte Version des RHV-Managers, die mit weniger Ressourcen als ihre Vorgänger auskommt und flotter arbeitet. Die aktuelle Version 4.2 wartet zudem mit weiteren UI-Verbesserungen auf.



Seite 1 von 2 Nächste Seite >>


dr/ln/Max Lessel

Ä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.