Vom Urvater „IBM VM“ zu moderner Virtualisierungssoftware

Kommentieren Drucken
Teil 3 von 19 aus der Serie "Virtualisierungstechniken"

Wenn wir jetzt zur Virtualisierung übergehen, wird Ihnen Teil 2 beim Verständnis sehr helfen. Virtualisierung ist nicht wirklich neu und am Urvater aller Virtualisierungssysteme, dem IBM VM, lässt sich schon Einiges verdeutlichen. Danach folgt ein Überblick über drei moderne Systeme.

Eines der ersten Virtualisierungskonzepte war das VM-Betriebssystem von IBM.

Konstruktiv gesehen passiert Folgendes: Man schreibt ein Programm, welches zunächst einmal den Status eines Anwendungsprogramms hat. Dieses Programm bildet die durch das Betriebssystem normalerweise erzeugte Oberfläche für die Bearbeitung von Laufzeitumgebungen, wie sie für die Ausführung von Anwendungsprogrammen erzeugt werden, in allen dafür wichtigen Einzelheiten getreu nach.

Dieses Programm ist eine virtuelle Maschine. Auf dieser virtuellen Maschine können dann Anwendungsprogramme genau so ablaufen, wie gewohnt: man erzeugt aus dem ausführfähigen Code mittels der weiter oben beschriebenen Zuordnungen eine Laufzeitumgebung, die wiederum auf Elementarprozesse abgebildet wird. Diese Elementarprozesse werden atzt aber nicht mehr durch vom Scheduler der physikalischen Maschine bereitgestellt, sondern von dem Teil des „VM-Programms“, welches einen Scheduler nachbildet.

Virtualisierung bedeutet also in jedem Falle die Erzeugung einer zusätzlichen Betriebssystemebene.

Das „VM-Programm“ ist seinerseits aus der Perspektive der physischen Maschine und dem auf dieser laufenden Betriebssystem zunächst einmal nichts anderes als ein normales Anwendungsprogramm. Es muss also eine Laufzeitumgebung bekommen, die durch die Bindung an reale anwendungsunterstützende Elementarprozesse implementiert wird. Das hat Vor- und Nachteile, wie wir noch sehen werden.

Sobald man verstanden hat, wie die einfache Virtualisierung funktioniert, kommen einige Bedenken auf:

  • Möglicher Leistungsverlust
    • CPU
    • RAM
    • I/O pro Sekunde, Latenz
    • Netzwerk
  • Offenheit
  • Management (Umfang, Kosten)
  • Sicherheit

Das VM von IBM wurde vor fast 30 Jahren eingeführt und in der Tat konnten z. B. Leistungsverluste nur dadurch kompensiert werden, dass man dem Betriebssystem einen immer größeren Anteil an der Gesamt-Systemleistung zur Verfügung stellte. Der IBM-Anwender der damaligen Zeit war durchaus bereit, ungefähr die Hälfte des Systems dafür zu opfern. Dennoch ließen sich schon durch diese elementare Virtualisierung in bestimmten Anwendungsfällen erhebliche Vorteile erzielen.

Der aktuelle Schwung bei der Virtualisierung kommt daher, dass die Hersteller moderner Virtualisierungssoftware genau diese Probleme aufgegriffen und (in Stufen) weitgehend gelöst haben. Gleichzeitig hat sich mit den Multi-Core-Systemen eine Rechnergeneration entwickelt, die dafür sehr gute Voraussetzungen mit sich bringt.

Beginnen wir einfach einmal mit der Offenheit.

Wie Sie gesehen haben, ist eine virtuelle Maschine ein Programm im Status eines Anwendungsprogramms. Dieses Programm kann man natürlich schreiben, wie man möchte, also kann es nicht nur ein bestimmtes Betriebssystem nachbilden, sondern unterschiedliche. Da das alles Anwendungsprogramme sind, können sie natürlich wie gewöhnliche Anwendungsprogramme koexistieren, siehe Bild 2.

Natürlich ist das zu schön, um wirklich wahr zu sein. Die Hersteller von Betriebssystemen waren in den vergangenen Jahrzehnten enorm fleißig darin, unmittelbare Durchgriffe des Betriebssystems auf reale Befehle der physikalischen Prozessoren zu erlauben. Dadurch wollten sie natürlich ihrer speziellen Betriebssystemvariante einen Vorsprung vor anderen geben. Gleichzeitig haben sie damit fleißig die Hardware Abstraction Layer durchlöchert bis hin zu deren völligem Wegfall. Das rächt sich jetzt fürchterlich. In der Vergangenheit waren wir gewohnt, dass es für einen physischen Rechner nur eine geringe Auswahl von möglichen Betriebssystemversionen gab. Das war eigentlich auch nicht wirklich ein Problem, weil man ja das Betriebssystem nicht dauernd wechselt. Anwendungen müssen für ein bestimmtes Betriebssystem oder eine kleine Auswahl von Varianten geschrieben werden, weil die Erzeugung der Laufzeitumgebungen ja von dem abhängig ist, was ein Betriebssystem bietet.

Die Offenheit im Rahmen der Virtualisierung ist auch heute davon abhängig, inwieweit die durch die VM-Programme nachgebildeten Betriebssysteme in ihrem Leben als „echte“ Betriebssysteme die HAL durchlöchert haben. Im Rahmen der VM-Programmierung kann man manche dieser Löcher zurückbilden, aber nicht immer alle. Es ergibt sich dann das Problem, wie man mit diesen unmittelbaren Durchgriffen umgeht, aber dazu später mehr.

Kommen wir zunächst zu anderen Aspekten. Das VM-Programm ist ja eigentlich nichts weiter als ein Anwendungsprogramm, also kann es auch rein theoretisch mit anderen Anwendungsprogrammen koexistieren. Wird das so realisiert, spricht man von einer gehosteten Lösung, siehe Bild 3.

Bei Versuchen hat sich gezeigt, dass das keine gute Lösung ist. IBM VM konnte auch in diesem Modus benutzt werden, aber die Gesamtleistung ist sehr unbefriedigend. Virtuelle Maschinen und normale Anwendungsprogramme behindern sich gegenseitig, weil sich das Profil, mit dem eine virtuelle Maschine einen physischen Rechner beschäftigt, doch sehr von dem einer normalen Anwendung unterscheidet.

Der Durchbruch der Virtualisierung mit modernen Konzepten basiert auf der Einführung eines sog. Hypervisors.

Da wir eben so schön tief in die Funktionen eines Betriebssystems eingestiegen sind, lässt sich der Hypervisor, der vielen als unverständliche Komponente erscheint, von der man eigentlich nur weiß, dass sie orange ist :-), leicht erklären:

Der Hypervisor ist ein spezialisierter Scheduler. Das von ihm erzeugte System der Elementarprozesse ist auf die Unterstützung der Laufzeitumgebungen der virtuellen Maschinen optimiert. Er unterstützt ausschließlich virtuelle Maschinen.

Wir haben gesehen, dass ein normaler Scheduler anwendungsunterstützende und systemunterstützende Elementarprozesse erzeugt. Das macht der Hypervisor auch, aber er erzeugt diese zwei Arten Elementarprozesse in Gruppen, und zwar eine Gruppe für jede virtuelle Maschine. Das wäre weiter nicht aufregend, aber die dadurch entstehende zweistufige Verwaltungsstuktur für Elementarprozesse ist wesentlich flexibler als die bei einem gewöhnlichen Scheduler übliche flache Organisation.

Stehen dem Hypervisor mehrere Prozessoren oder Cores zur Verfügung, kann er dieses System dazu nutzen, die Gruppen sehr elegant auf die parallel arbeitenden Cores abzubilden. Hierfür kann er verschiedene Strategien anwenden und sogar mischen. Die Elementarprozesse zweier virtueller Maschinen haben nichts miteinander zu tun und erfüllen so die notwendige Voraussetzung für die Parallelisierung.

Auch für einen Hypervisor benötigen wir eine Steuerung. Also gibt es auf einem entsprechenden System noch eine Service-Konsole, an die weitere Funktionen, wie z. B. Clustering-Services angegliedert werden können. Das sehen wir in Bild 4.

Frühe Hypervisor-Varianten haben sich für die Realisierung ihrer Funktionen noch der vorhandenen Scheduler bedient, wie das in der Bild 4 noch zu sehen ist. Das führt aber nicht zu der gewünschten Leistung, weil z. B. die Bildung der Prozessgruppen für die virtuellen Maschinen und andere Funktionen dazu führen, dass bei Beibehaltung des alten Schedulers nicht nur durch den Hypervisor wieder eine neue Schicht eingeführt wird, sondern auch keine wirkliche Eleganz bei der zweistufigen Prozessverwaltung erreicht werden konnte.

Konsequenterweise ersetzt der Hypervisor in modernen Systemen die alte Struktur aus Scheduler und Elementarprozessen vollständig. Damit wird er zum neuen zentralen Element in einer Systemumgebung, die die Virtualisierung unterstützt.

Normale Anwendungen können jetzt ausschließlich auf virtuellen Maschinen laufen und nicht mehr auf dem alten Scheduler-System. Lediglich für die Unterstützung der Steuerungsfunktionen muss ein kleiner Rest vom alten System bewahrt bleiben.

Der Hypervisor profitiert natürlich davon, dass er eine in hohem Grade standardisierte Umgebung unterstützen kann, die ausschließlich durch die für die virtuellen Maschinen notwendigen Laufzeitumgebungen gebildet wird. Die Gesamtkonstruktion sehen wir in Bild 5 am Beispiel VMware.

In der Bild 5 sehen Sie keine HAL mehr. Das liegt daran, dass ein Hypervisor die Hardware-Abstraktion erheblich durchlöchert und ggf. in hohem Maße auf spezielle Funktionen der realen Prozessoren zugreift. Prozessor-Hersteller wie Intel oder AMD sind aber zurzeit auch besonders fleißig darin, speziell für die Hypervisoren besondere Funktionen bereitzustellen. Davon lernen wir gleich noch einige kennen. Die Hersteller sehen in einer Virtualisierungssoftware die wichtigste Möglichkeit zur bequemen und effizienten Nutzung ihrer Multi-Core Architekturen.

Ein weiterer Hersteller von Virtualisierungssoftware ist Citrix. Hier sehen wir uns einmal ein Originalbild des Herstellers an (Bild 6). Auf diesem Bild nennen sie ihren Hypervisor noch Virtual Machine Monitor und das Ganze läuft offensichtlich mit Linux als Basis-Betriebssystem.

Was mir an diesem Bild besonders gut gefällt, ist die Darstellung in einer Orientierung an das Prozessmodell, welches ja die Realität widerspiegelt. Man sieht u.a. Treiber für NICs, Platten und Speicher. Das sind systemunterstützende Elementarprozesse einer virtuellen Maschine. Man sieht auch gut die Steuerungskomponente (VM Server Desktop) als einzige Anwendung im klassischen Sinne. Ale anderen Anwendungen laufen auf den virtuellen Maschinen.

Das nächste, neuere Bild des gleichen Herstellers (Bild 7) ist schon aggressiver, was den Mitbewerb angeht. Hier nennen sie den Hypervisor beim Namen und stellen aber weitere Komponenten in den Vordergrund, und zwar zur Storage und Network Virtualization. Diese haben offensichtlich ungestörten direkten Zugriff auf die Hardware. Man hat bei Citrix schon früh erkannt, dass sich ohne einen derartigen direkten Zugriff keine wirkliche Leistung erzeugen lässt.

Storage und Network Virtualization sind weitere essentielle Themenbereiche, die wir zunächst zurückstellen und später im Rahmen einer systematischen Behandlung aufgreifen.

Citrix stellt auch heraus, dass sie virtuelle Maschinen erzeugen, die sich gegenüber Anwendungen wie Linux-, Solaris- oder Windows-Server verhalten.

Natürlich darf auch Microsoft nicht fehlen. Man hat zunächst den Eindruck, dass sie das Thema etwas langsamer angehen als die Hauptkonkurrenten VMware und Citrix. Wie in Bild 8 zu sehen, haben sie eine andere Struktur auf dem Hypervisor, die aus verschiedenen Partitionen besteht, von denen eine eine Root sein muss. Alle diese Partitionen sind durch einen sog. VMBus verbunden. Das ist ein virtueller Bus für die virtuellen Maschinen. Wir werden gleich noch andere Konzepte für die Kommunikation virtueller Maschinen sehen. Die Clients können verschiedener Natur sein und als virtuelle Maschinen Windows oder ein anderes Betriebssystem nachbilden. Zum Zeitpunkt der Manuskripterstellung ist das Konzept Microsofts nicht wirklich zu bewerten, weil sie es langsamer entwickeln, was aber am Ende ja nichts heißt.

Wenn Sie diese Darstellungen bis zum Ende durchgearbeitet haben, werden Sie in der Lage sein, die aktuellen Tests der Hauptkontrahenten zu verstehen und den Entwicklungsfortschritt einzuordnen, denn die Produkte aller Hersteller sind in permanenter Entwicklung.

Hinweis: In 2011 erreicht VMware mit seinen Produkten einen Marktanteil von bis zu 90%. Das ist eine Tatsache, die sich auch wieder ändern kann. Da die Produkte von VMware daher in der überwiegenden Mehrzahl der Rechenzentren eingesetzt werden, werden in dieser Serie primär Beispiele oder weitere Erläuterungen aus dem Spektrum dieses Herstellers verwendet, weil das eben auch die überwiegende Zahl der Leser betrifft.

« Teil 2: Prozesse in klassischen BetriebssystemumgebungenTeil 4: Grundsätzliche Konstruktionsalternativen und Transaktionsverarbeitung »


zugeordnete Kategorien: Virtualisierung
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.