Server-Virtualisierung mit Open-Source

Der Autor ist EMEA Business Unit Manager Cloud bei Red Hat. Der Anteil der virtualisierten Server in den Rechenzentren ist in den letzten fünf Jahren drastisch gestiegen. Marktforscher wie Gartner gehen davon aus, dass viele Unternehmen heute schon bis zu 50 Prozent ihrer Server virtualisiert haben. Dazu trägt auch die Leistungsfähigkeit aktueller Systeme bei. Server-CPUs erreichen heute Performance-Werte, die früher High-End-Unix-Systemen vorbehalten waren. Sie sind zudem deutlich preisgünstiger. Dies erklärt auch, warum immer mehr Unternehmen ihre Unix-Systeme durch leistungsfähige Server mit Linux ersetzen. Mit dafür verantwortlich ist die enorme Leistungs-explosion der x86er-Plattform. Die grundlegende Architektur wurde zur Basis aller Weiterentwicklungen und sorgt für Kompatibilität.

Eine für die Virtualisierung wichtige Eigenschaft ist das Prinzip der Privilegien-Level. Die insgesamt vier Levels, auch als Ringe oder Domains benannt, beschreiben die Sicherheitsstufen eines Prozesses, angeordnet in einer Hierarchie von Ring 0 (höchste Berechtigungsstufe) bis Ring 3. In Ring 0 läuft das Betriebs­system, mit direktem Zugriff auf die Hardware. Die Applikationen sind auf den Ring 3 mit der niedrigsten Berechtigungsstufe beschränkt. Ein Zugriff auf den Speicherbereich anderer Prozesse ist nicht möglich. Damit ist gewährleistet, dass Prozesse in Ring 3 auf keinen Fall Prozesse in Ring 0 oder auch andere Prozesse in Ring 3 beeinflussen können. Die Ringe 1 und 2 wurden historisch betrachtet von kommerziellen Betriebssystemen nicht verwendet. Überall dort, wo das Betriebssystem direkt auf der Hardware aufsetzt (bare metal), bietet dieses Modell aus dem Blickwinkel der Sicherheit eindeutige Vorteile, für die Virtua­lisierung jedoch ergeben sich daraus einige Herausforderungen. In einer virtualisierten Umgebung muss der Hypervisor im privilegierten Modus laufen, um die Hardware- und Systemfunktionen kontrollieren zu können. Die virtuellen Maschinen laufen mit einem Betriebssystem sowie emulierter Hardware in Ring 3. Das Betriebssystem geht davon aus, dass es in Ring 0 läuft und versucht, privilegierte Befehle auszuführen, die in dem Fall aber nicht zulässig sind. Viele Aktivitäten, die von Virtualisierungslösungen ausgeführt werden, befassen sich mit dem Thema, wie mit den nicht-privilegierten Betriebssystemen zu verfahren ist, die in einer virtuellen Maschine laufen. Virtualisierungslösungen verwenden dazu den Ring 1. Dabei wird der Betriebssystemkern aus Ring 0 in den Ring 1 verschoben, der Hypervisor residiert als über Ring 0 liegende Schicht und verwaltet einen oder mehrere in Ring 1 laufende Betriebssystemkerne. Lesen Sie auf der nächsten Seite: VMware: Binäre Übersetzung

Bei der «binären Übersetzung», einem Modus, den VMware einführte, läuft die virtuelle Maschine direkt auf der CPU. Sollen privilegierte Instruktionen ausgeführt werden, sorgt die CPU dafür, dass die Instruktionen vom Hypervisor bearbeitet werden können. Ist keine direkte Weiterleitung möglich, sorgt die binäre Übersetzung für eine entsprechende Aufbereitung der Befehlssequenzen. Das Betriebssystem merkt davon nichts und arbeitet auf dem Hypervisor im normalen Modus weiter. Technisch ist das Ganze aufwendig zu implementieren, führt aber dazu, dass VMware Gastbetriebssysteme mit nahezu nativer Performance ausführen kann.

Während sich die Emulation und die binäre Übersetzung darauf konzentrierten, wie die privilegierten Instruktionen in einer virtualisierten Maschine ausgeführt werden, verfolgt das Open-Source-Projekt Xen den Ansatz der Paravirtualisierung. Dazu wird ein Gastbetriebssystem so modifiziert, dass es in einer virtuellen Maschine laufen kann und ohne die Befehlsausführung in Ring 0 auskommt. Die Paravirtualisierung erfordert, dass der Hersteller des Betriebssystems die notwendigen Änderungen vornehmen muss. Beim Linux-Kernel fanden sie anfangs als Patches Eingang. Ab Version 2.6.23 stellt der Linux-Kernel die Möglichkeiten für den Betrieb mit einem beliebigen Hypervisor in Form sogenannter «paravirt ops» bereit. Eine wichtige Rolle spielt die erste Domäne, die von Xen gestartet wird. Sie ist privilegiert und übernimmt die Interaktion mit dem eigentlichen Hypervisor. Die privilegierte Domäne Dom0 kann andere Domänen starten, stoppen und verwalten. Dazu muss diese Verwaltungsfunktionalität in das Betriebssystem integriert werden, das in der Dom0 läuft. Jede virtuelle Maschine, auch als nicht-privilegierte Domain oder DomU bezeichnet, enthält beispielsweise einen modifizierten Linux-Kernel, der jedoch nicht direkt mit der Hardware, sondern mit dem Xen-Hypervisor kommuniziert. In diesem Fall läuft der Gast-Kernel in Ring 1, während sich die Benutzerdaten in Ring 3 befinden. Neben einigen anderen Betriebssystemen bietet beispielsweise Red Hat Enterprise Linux 5 einen als Xen-Host modifizierten Kernel an. Lesen Sie auf der nächsten Seite: KVM Hypervisor

Der Kernel-based Virtual-Machine-Hypervisor (KVM) repräsentiert die neuste Entwicklung bei der Open-Source-Virtualisierung. So setzen Red Hat Enterprise Linux 6 und Red Hat Enterprise Virtualization 3.1 auf KVM. Auch die Open Virtualization Alliance, gegründet unter anderem von HP, IBM, Intel sowie Red Hat, will den Einsatz von KVM als Alternative zu VMware fördern. KVM nutzt die Hardware-Virtualisierungstechniken Intel VT-X sowie AMD-V und ist im Linux-Kernel 2.6.20 enthalten. In der KVM-Architektur ist eine virtuelle Maschine als regulärer Linux-Prozess implementiert, gesteuert durch den Scheduler. Da jede virtuelle CPU als regulärer Linux-Prozess erscheint, kann KVM von allen Features des Linux-Kernels profitieren. Die Geräte-Emulation übernimmt eine modifizierte Version von QEMU. Diese virtuelle Maschine stellt für vir­tualisierte Gastsysteme PCI-Bus, USB-Schnittstellen, Festplatten, Netzwerk- und Grafikkarten zur Verfügung. Da bei KVM eine virtuelle Maschine als Linux-Prozess implementiert ist, kann der Hypervisor auch die umfangreichen, in den Linux-Kernel integrierten Sicherheitsfunktionen von SELinux (Security Enhanced Linux) nutzen. SELinux wurde von der US-amerikanischen National Security Agency (NSA) entwickelt und verfügt über Sicherheitsfunktionen, wie sie im Militärbereich gefordert werden. KVM schafft damit die Grundlage, dass die Virtualisierung gleichzeitig von mehreren Anwendern auf dem gleichen Server genutzt werden kann. Die vir­tuellen Maschinen sind dabei mit der von der NSA entwickelten Mandatory-Access-Control-Technologie sicher voneinander abgeschirmt. Das sVirt-Projekt nutzt SELinux als Grundlage einer Infrastruktur, mit der Administratoren Regeln erstellen, um virtuelle Maschinen vor unerlaubten Zugriffen zu schützen. Bei der Frage, wie sicher KVM ist, sorgte vor einigen Jahren die Debatte, ob KVM ein Typ-1- oder ein Typ-2-Hypervisor (läuft im nicht-privilegierten Ring 3) ist, für einige Aufregung. Aufgrund seines Bare-Metal-Designs ist KVM ein Typ-1-Hypervisor, da zumindest Teile in Ring 0 mit den entsprechend hohen Sicherheitsstandards laufen. Auch VMware vSphere und Microsoft Hyper-V werden als Typ-1-Hypervisor eingestuft, verfügen aber nicht standardmässig über eine Mandatory-Access-Control-Isolation. Lesen Sie auf der nächsten Seite: Live-Migration virtueller Maschinen

Eine wichtige Anforderung an den Hypervisor ist die Live-Migration virtueller Maschinen von Host zu Host. Als integrierter Bestandteil von Red Hat Enterprise Virtualization 3.1 ermöglicht KVM, im laufenden Betrieb eine virtuelle Maschine von einem auf einen anderen Server zu verschieben. Die Netzwerk-verbindungen bleiben erhalten und die Applikationen laufen weiter. Hinsichtlich der Kernfunktionen kann es KVM unter dem Strich problemlos mit VMware aufnehmen, denn KVM beherrscht beispielsweise auch die «binäre Übersetzung» und kann daher Gast-Betriebssysteme mit einer sehr hohen Performance ausführen.

Hardware-gestützte Virtualisierung

Sowohl Intel als auch AMD haben mit Intel VT-X beziehungsweise AMD-V Befehlssatzerweiterungen der x86er-Architektur für die Hardware-
basierte Virtualisierung entwickelt. VT-X und AMD-V sind nicht kompatibel miteinander, arbeiten aber nach einem vergleichbaren Grundprinzip. Im Kern koordinieren beide Ansätze den direkten Speicherzugriff und ermöglichen in virtualisierten Systemen, insbesondere Grafik- und Netzwerktreibern, eine höhere Geschwindigkeit. VT-X bringt spürbare Vorteile bei Intel-Systemen, um unter Xen Dom0s, beispielsweise Windows in einem Gastsystem, zu betreiben, unter VMware Gastsysteme mit 64 Bit einzusetzen und um mit KVM zu virtualisieren. Intel VT-d ermöglicht PCI-Devices, mithilfe der bereitgestellten IOMMU (Input/Output Memory Mana­gement Unit, gibt es von Intel und AMD) direkt auf das Gastsystem zuzugreifen. Als Ergebnis kann eine Netzwerkkarte dediziert einem Gastsystem bereitgestellt werden. Dadurch lässt sich eine höhere Netzwerk-Performance als mit einer emulierten Netzwerkkarte erreichen.