Cloud Computing: Virtualisierungsklassen
Es gibt verschiedene Konzepte – oder Klassen – der Virtualisierung, die jeweils für ganz bestimmte Situationen geeignet sind.
Kai Hwang, Jack Dongarra, Geoffrey Fox
Dieser Artikel stammt aus dem Buch "Distributed and Cloud Computing: From Parallel Processing to the Internet of Things" (Syngress, ein Verlag von Elsevier)
Allgemein gibt es drei typische Klassen von VM (Virtual Machine)-Architekturen: Hypervisor, hostbasierte Virtualisierung und Para-Virtualisierung, die sich jeweils durch die Positionierung der Virtualisierungsebene unterscheiden. Der Hypervisor wird auch als Virtual Machine Monitor (VMM) bezeichnet.
Hypervisorarchitektur
Der Hypervisor unterstützt die Virtualisierung auf Hardwareebene auf Bare-Metal-Geräten wie CPUs, Speichermedien, Festplatten oder Netzwerkschnittstellen. Die Hypervisorsoftware befindet sich direkt zwischen der physischen Hardware und dem Betriebssystem. Diese Virtualisierungsebene wird als VMM oder Hypervisor bezeichnet.
Der Hypervisor stellt Hypercalls für die Gastbetriebssysteme und -anwendungen bereit. Ein Hypervisor kann über eine Microkernel-Architektur verfügen, wie etwa Microsoft Hyper-V. Er kann jedoch auch eine monolithische Hypervisorarchitektur aufweisen, wie etwa VMware ESX für die Servervirtualisierung.
Ein Microkernel-Hypervisor verfügt nur über die grundlegenden und unveränderlichen Funktionen (wie etwa Verwaltung physischen Speichers und Prozessorzeitplanung). Die Gerätetreiber und andere veränderliche Komponenten befinden sich außerhalb des Hypervisors. Ein monolithischer Hypervisor implementiert alle zuvor genannten Funktionen sowie die der Gerätetreiber.
Daher ist der Hypervisorcode eines Microkernel-Hypervisors geringer im Umfang als der eines monolithischen Hypervisors. Die Hauptaufgabe eines Hypervisors ist die Konvertierung physischer Geräte in virtuelle Ressourcen zur Verwendung durch die VM.
Die Xen-Architektur
Xen ist ein von der Universität Cambridge entwickeltes Open Source-Hypervisorprogramm. Die Kernkomponenten eines Xen-Systems sind der Hypervisor, der Kernel und die Anwendungen. Dabei ist die Organisation der drei Komponenten sehr wichtig.
Xen ist ein Microkernel-Hypervisor, bei dem die Richtlinien von dem Mechanismus getrennt sind. Der Xen-Hypervisor implementiert alle Mechanismen und überlässt das Management der Richtlinien Domain 0. Er enthält selbst keine Gerätetreiber. Er stellt lediglich einen Mechanismus bereit, mit dem ein Gastbetriebssystem direkt auf die physischen Geräte zugreifen kann.
Das Ergebnis ist, dass der Xen-Hypervisor eher klein gehalten werden kann. Xen stellt eine virtuelle Umgebung zwischen der Hardware und dem Betriebssystem bereit. Einige Anbieter entwickeln derzeit kommerzielle Xen-Hypervisoren, etwa Citrix XenServer und Oracle VM.
Wie bei anderen Virtualisierungssystemen können zahlreiche Gastbetriebssysteme auf dem Hypervisor ausgeführt werden. Dabei sind aber nicht alle Gastbetriebssysteme gleich, und eines davon kontrolliert die anderen. Das Gastbetriebssystem, das die anderen kontrolliert, wird als Domain 0 bezeichnet, die anderen als Domain U. Domain 0 ist ein privilegiertes Gastbetriebssystem von Xen. Es wird zum ersten Mal geladen, wenn Xen gestartet wird, ohne dass Dateisystemtreiber verfügbar sind. Domain 0 dient dem direkten Zugriff auf die Hardware und dem Management von Geräten. Eine der zentralen Funktionen von Domain 0 besteht daher darin, Hardwareressourcen für die Gastdomänen (die Domain U-Domänen) zuzuweisen.
Xen basiert beispielsweise auf Linux und hat die Sicherheitsebene C2. Seine Verwaltungs-VM heißt Domain 0 und verwaltet andere auf demselben Host implementierte VMs. Wenn Domain 0 angegriffen wird, kann ein Hacker damit das gesamte System kontrollieren.
Daher ist es erforderlich, im VM-System Sicherheitsrichtlinien zu verwenden, um die Sicherheit von Domain 0 zu verbessern. Mit Domain 0, das als VMM fungiert, können Benutzer VMs erstellen, kopieren, speichern, lesen, ändern, weitergeben, migrieren und zurückfahren – so einfach, als wären es Dateien. Leider führt dies auch zu Sicherheitsproblemen während des Softwarelebenszyklus und der Datenlebensdauer.
Man kann sich die "Lebenszeit" eines Computers als gerade Linie vorstellen. Der aktuelle Status ist ein Punkt, der sich während der Ausführung der Software monoton entlang dieser Linie bewegt. Während dieser Zeit nehmen Sie Konfigurationsänderungen vor, installieren Software und wenden Patches an.
In einer solchen Umgebung gleicht der VM-Status einem Baum: An jedem Punkt kann die Ausführung zu N verschiedenen Verzweigungen führen, wobei zu jedem Zeitpunkt an jedem Punkt dieses Baumes mehrere VM-Instanzen vorhanden sein können. VMs können zu früheren Zuständen ihrer Ausführung zurückkehren (etwa zur Korrektur von Konfigurationsfehlern) oder mehrfach von demselben Punkt aus erneut ausgeführt werden (etwa zur Verteilung dynamischer Inhalte oder zur Zirkulation eines "Live"-Systemabbilds).
Binäre Übersetzung mit vollständiger Virtualisierung
Abhängig von der jeweiligen Implementierungstechnologie kann man zwei Kategorien der Hardwarevirtualisierung unterscheiden: die vollständige und die hostbasierte Virtualisierung.
Die vollständige Virtualisierung muss das Hostbetriebssystem nicht modifizieren. Sie basiert auf binärer Übersetzung zur Erfassung und Virtualisierung der Ausführung bestimmter sensitiver, nicht virtualisierbarer Anweisungen. Die Gastbetriebssysteme und ihre Anwendungen bestehen aus nicht kritischen und kritischen Anweisungen.
In einem hostbasierten System werden ein Host- und ein Gastbetriebssystem verwendet. Zwischen dem Host- und dem Gastbetriebssystem wird eine Virtualisierungssoftwareebene eingerichtet.
Vollständige Virtualisierung
Bei der vollständigen Virtualisierung werden nicht kritische Anweisungen direkt auf der Hardware ausgeführt; kritische Anweisungen werden erkannt und durch Traps in der von der Software zu emulierenden VMM ersetzt. Sowohl das Hypervisor- als auch das VMM-Konzept gelten als vollständige Virtualisierung.
Warum werden nur kritische Anweisungen per Trap in die VMM übertragen? Der Grund dafür besteht darin, dass die binäre Übersetzung zu einem großen Leistungsoverhead führen kann. Nicht kritische Anweisungen kontrollieren keine Hardware und bedrohen nicht die Sicherheit des Systems, für kritische Anweisungen gilt dies jedoch sehr wohl. Daher kann die Ausführung nicht kritischer Anweisungen auf der Hardware nicht nur die Effizienz steigern, sondern auch die Sicherheit des Systems gewährleisten.
Dieses Konzept wird von VMware und von zahlreichen anderen Softwareunternehmen implementiert. Die VMM erfasst den Anweisungsstrom und identifiziert die privilegierten kontroll- und verhaltensabhängigen Anweisungen. Wenn diese identifiziert sind, werden sie per Trap in die VMM versetzt, die dann ihre Verhaltensweisen emuliert. Die bei dieser Emulierung verwendete Methode wird als binäre Übersetzung bezeichnet.
Daher kombiniert eine vollständige Virtualisierung die binäre Übersetzung und die direkte Ausführung. Das Gastbetriebssystem ist vollständig von der zugrunde liegenden Hardware getrennt. Folglich "weiß" das Gastbetriebssystem nicht, dass es virtualisiert wird.
Eine vollständige Virtualisierung bietet möglicherweise nicht die beste Leistung, da sie das recht zeitaufwändige Verfahren der binären Übersetzung verwendet. Die vollständige Virtualisierung E/A-intensiver Anwendungen stellt eine gewisse Herausforderung dar. Die binäre Übersetzung verwendet einen Codecache zur Speicherung übersetzter "Hot Instructions", um die Leistung zu verbessern, erhöht aber dabei die Speicherverwendung. Die Leistung einer vollständigen Virtualisierung auf einer x86-Architektur liegt typischerweise bei 80 bis 97 Prozent der Leistung des Hostcomputers.
Hostbasierte Virtualisierung
Eine alternative VM-Architektur besteht darin, dass über dem Hostbetriebssystem eine Virtualisierungsebene errichtet wird. Dieses Hostbetriebssystem ist nach wie vor für die Verwaltung der Hardware verantwortlich. Die Gastbetriebssysteme werden über der Virtualisierungsebene installiert und ausgeführt. Dedizierte Anwendungen können auf den VMs ausgeführt werden. Einige andere Anwendungen können auch direkt mit dem Hostbetriebssystem ausgeführt werden.
Eine solche hostbasierte Architektur bietet einige klare Vorteile. Zunächst kann der Benutzer diese VM-Architektur ohne Modifizierung des Hostbetriebssystems installieren. Die Virtualisierungssoftware kann sich auf das Hostbetriebssystem stützen, um Gerätetreiber und andere Low-Level-Dienste bereitzustellen. Dies vereinfacht die VM-Struktur und erleichtert ihre Bereitstellung.
Zweitens ist das hostbasierte Konzept für zahlreiche Hostcomputerkonfigurationen attraktiv. Im Vergleich zur Hypervisor/VMM-Architektur kann es sein, dass die Leistung einer hostbasierten Architektur ebenfalls eher niedrig ist. Wenn eine Anwendung Hardwarezugriff anfordert, betrifft dies vier Zuordnungsebenen, was zu erheblichen Leistungseinbußen führt. Wenn sich die ISA (Internet Security and Acceleration) eines Gastbetriebssystems von der der zugrunde liegenden Hardware unterscheidet, muss die binäre Übersetzung herangezogen werden. Obwohl die hostbasierte Architektur Flexibilität bietet, ist ihre Leistungsfähigkeit zu gering für die Praxis.
Para-Virtualisierung
Die Para-Virtualisierung muss das Gastbetriebssystem modifizieren. Eine para-virtualisierte VM stellt spezielle APIs bereit, die substanzielle Betriebssystemmodifizierungen in Benutzeranwendungen erfordern. Leistungseinbußen sind ein zentrales Problem virtualisierter Systeme. Niemand wird eine VM verwenden, wenn sie viel langsamer ist als ein physischer Computer.
Sie können die Virtualisierungsebene an verschiedenen Positionen des Softwarestacks einfügen. Die Para-Virtualisierung versucht jedoch, den Virtualisierungsoverhead zu reduzieren und die Leistung dadurch zu steigern, dass nur der Gastbetriebssystemkernel modifiziert wird. Wenn Gastbetriebssysteme para-virtualisiert werden, werden sie von einem intelligenten Compiler unterstützt, der die nicht virtualisierbaren Betriebssystemanweisungen durch Hypercalls ersetzt.
Ein herkömmlicher x86-Prozesse bietet vier Anweisungsausführungsringe, die Ringe 0, 1, 2 und 3. Je niedriger die Nummer des Rings, umso höher das Privileg der jeweiligen Anweisung für die Ausführung. Das Betriebssystem ist für die Verwaltung der Hardware und der in Ring 0 auszuführenden privilegierten Anweisungen zuständig, während Anwendungen auf Benutzerebene in Ring 3 ausgeführt werden. Das beste Beispiel für die Para-Virtualisierung ist eine kernelbasierte VM (KVM).
Wenn der x86-Prozessor virtualisiert wird, wird zwischen Hardware und Betriebssystem eine Virtualisierungsebene eingerichtet. Gemäß der x86-Ringdefinition sollte die Virtualisierungsebene auch in Ring 0 installiert werden. Verschiedene Anweisungen in Ring 0 könnten zu Problemen führen. Wenn der Gastbetriebssystemkernel jedoch für die Virtualisierung modifiziert wird, kann er nicht länger direkt auf der Hardware ausgeführt werden.
Obwohl die Para-Virtualisierung den Overhead reduziert, bringt sie andere Probleme mit sich. Zunächst gibt es Probleme mit Kompatibilität und Portabilität, da sie auch das nicht modifizierte Betriebssystem unterstützen muss. Zweitens sind die Kosten des Unterhalts para-virtualisierter Betriebssysteme hoch, da dafür tief greifende Betriebssystemkernel-Modifizierungen erforderlich sein können.
Und schließlich variieren die Leistungsvorteile der Para-Virtualisierung erheblich bei unterschiedlichen Arbeitsauslastungen. Im Vergleich zu der vollständigen Virtualisierung ist eine Para-Virtualisierung relativ einfach und praktisch. Das Hauptproblem bei der vollständigen Virtualisierung ist ihre geringe Leistung bei der binären Übersetzung. Die binäre Übersetzung lässt sich nur schwer beschleunigen. Daher verwenden viele Virtualisierungsprodukte die Para-Virtualisierungsarchitektur. Die verbreiteten Produkte Xen, KVM und VMware ESX sind gute Beispiele dafür.
KVM ist ein hardwareunterstütztes Para-Virtualisierungstool, das die Leistung erhöht und nicht modifizierte Betriebssysteme unterstützt, wie etwa Windows, Linux, Solaris und andere Unix-Varianten.
Dies ist ein Linux-Para-Virtualisierungssystem – Teil des Linux-Kernels, Version 2.6.20. Der vorhandene Linux-Kernel führt die Speicherverwaltung und die Zeitplanungsaktivitäten durch. KVM übernimmt den Rest, was diese Lösung einfacher macht als einen Hypervisor, der den gesamten Computer kontrolliert.
Anders als die vollständige Virtualisierungsstruktur, die privilegierte und sensible Anweisungen zur Laufzeit abfängt und emuliert, behandelt die Para-Virtualisierung diese Anweisungen in der Kompilierungsphase. Der Gastbetriebssystemkernel wird so modifiziert, dass die privilegierten und sensiblen Anweisungen durch Hypercalls auf dem Hypervisor oder der VMM ersetzt werden. Xen ist ein Beispiel für eine solche Para-Virtualisierungsarchitektur.
Die privilegierten Anweisungen werden durch Hypercalls an den Hypervisor implementiert. Nach dem Ersatz der Anweisungen durch Hypercalls emuliert das modifizierte Gastbetriebssystem die Verhaltensweise des ursprünglichen Gastbetriebssystems. In einem Unix-System gehört zu einem Systemaufruf ein Interrupt oder eine Dienstroutine. Die Hypercalls verwenden in Xen eine dedizierte Dienstroutine.
Diese unterschiedlichen Arten von Virtualisierungsarchitekturen haben jeweils eigene Stärken und Schwächen. Sie sollten diese jeweils eingehend untersuchen, um die Architektur zu finden, die für Ihre Umgebung am besten geeignet ist.
.jpg)
Kai Hwang ist Professor für Computertechnik an der University of Southern California und Gastprofessor an der Tsinghua-Universität in China. Er verfügt über einen Doktortitel in EECS der University of California, Berkeley. Er hat zahlreiche Publikationen in den Bereichen Computerarchitektur, digitale Arithmetik, parallele Verarbeitung, verteilte Systeme, Internetsicherheit und Cloud Computing veröffentlicht.
.jpg)
Jack Dongarra ist Distinguished Professor of Electrical Engineering and Computer Science an der University of Tennessee, Distinguished Research Staff im Oak Ridge National Laboratory und Turning Fellow an der University of Manchester. Dongarra hat Pionierarbeit auf dem Gebiet der Supercomputer-Benchmarks, der numerischen Analyse, der Linear-Algebra-Solver und des Hochleistungscomputings geleistet und auf diesen Gebieten zahlreiche Publikationen herausgebracht.
.jpg)
Geoffrey Fox ist Distinguished Professor of Informatics, Computing and Physics sowie Associate Dean of Graduate Studies and Research an der School of Informatics and Computing der Indiana University. Er verfügt über einen Doktorgrad der Cambridge University, Großbritannien. Fox ist besonders bekannt für seine zahlreichen Veröffentlichungen und umfassende Arbeit auf den Gebieten parallele Architektur, verteilte Programmierung, Grid-Computing, Webdienste und Internetanwendungen.
©2011 Elsevier Inc. Alle Rechte vorbehalten. Nachgedruckt mit Genehmigung von Syngress, einem Verlag von Elsevier. Copyright 2011. "Distributed and Cloud Computing: From Parallel Processing to the Internet of Things" von Kai Hwang, Jack Dongarra, Geoffrey Fox. Weitere Informationen zu diesem Titel und ähnlichen Büchern finden Sie auf elsevierdirect.com.