Privileg für Hypervisor

Der Hypervisor selbst läuft im privilegierten Modus. Anders sieht es aus, wenn nicht-quelloffene Systeme unter Xen zu virtualisieren sind. Da hier keine Modifikation der Treiber möglich ist, ist der Einsatz spezieller CPU-Architekturen (VT-X/AMD-V) nicht zu vermeiden. Die bei Xen eingesetzte Technologie ist allerdings nicht mehr State of the Art, was sich unter anderem auch dadurch bestätigt, dass der Code für den Hypervisor es trotz seiner langen Anlaufzeit nicht in den offiziellen Linux-Kernel geschafft hat. Distributoren, die Xen in ihrem Portfolio haben, müssen also mindestens immer zwei unterschiedliche Kernelvarianten herausbringen.

KVM ist ein Hypervisor der dritten Generation und mittlerweile der De-facto-Standard bei quelloffenen Virtualisierungslösungen im Linux-Umfeld. Dass KVM sehr schnell die Aufnahme in den offiziellen Linux-Kernel geschafft hat, liegt nicht nur an dessen ausgezeichneter Codequalität, sondern auch daran, dass KVM alle aktuellen Virtualisierungstechnologien, beispielsweise IOMMU (sicheres PCI-Pass-Through), KSM (Shared Memory Management) und Virt IO (paravirtualisierte IO-Treiber) unterstützt.

So ausgestattet laufen virtuelle Betriebssystem-Instanzen mit fast nativer Performance. Dafür benötigt KVM jedoch aktuelle CPU-Generationen mit Virtualisierungs-Funktion (VT-X/AMD-V). Die virtuellen Maschinen in diesem Artikel laufen alle unter dem KVM-Hypervisor. Aktuelle Enterprise-Lösungen zur Virtualisierung von Servern und Desktops [3] basieren ebenfalls auf KVM.

Setup und Software

Das hier vorgestellte Beispiel arbeitet mit den beiden physischen Knoten »host1« und »host2« . Auf beiden kommt als Betriebssystem Red Hat Enterprise Linux 5 (RHEL5) zum Einsatz, jedoch funktionieren alle Beispiele auch auf aktuellen Fedora-Systemen. Auf beiden Hosts ist jeweils eine virtuelle KVM-System-Instanz (»vm1« , »vm2« ) installiert. Diese Systeme laufen unter Fedora, der Aufbau funktioniert aber auch mit jedem anderen Betriebssystem, das der KVM-Hypervisor unterstützt [4].

Abbildung 3: Jeder KVM-Host verwaltet eine gewisse Anzahl von virtuellen Systemen. Deren Überwachung ist Aufgabe des Clustermanagers.

Das Testlabor verzichtete auf die Installation weiterer virtueller Maschinen, um das Setup nicht unnötig komplex zu gestalten. Je nach Hardware-Ausstattung kann ein physischer Host natürlich eine Vielzahl virtueller Instanzen aufnehmen. Als Backend für die virtuellen Maschinen kommen Cluster-fähige logische Laufwerke (CLVM) zum Einsatz – diese sind auf den Clusterhosts statisch einzubinden. Ein iSCSI-Server (Internet Small Computer System Interface) dient als Storage-Backend. Dies ist eine kostengünstige Alternative zu herkömmlichen SAN-Lösungen mit Fibre Channel, die bei heutigen Netzwerkbandbreiten hohe Performance gewährleistet.

Als Clustermanager kommt die Red-Hat-eigene Cluster Suite (RHCS) zum Einsatz. Sie enthält alle notwendigen Komponenten zum Betrieb eines HA-Clusters. Neben dem auf Open AIS (Application Interface Specification) basierenden Clustermanager »cman« kümmert sich das Cluster Configuration System »ccs« um eine einheitliche Konfiguration der einzelnen Knoten. Fencing-Agenten sind für ausgefallene Knoten zuständig, der Ressource-Manager »rgmanager« für die eigentlichen HA-Services, in diesem Fall die virtuellen Maschinen-Instanzen. Zum Einbinden eines gemeinsam genutzen Speichers kommt der bereits angesprochene Cluster Logical Volume Manager (CLVM) zum Einsatz.