Grundsätzliche Konstruktionsalternativen und Transaktionsverarbeitung

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

Es gibt eine Reihe grundsätzlicher Konstruktionsalternativen für Virtualisierungssoftware. Sie haben einen unmittelbaren Einfluss auf die Leistung. Betreiber haben normalerweise vor allem ein Interesse an einer schnellen Transaktionsverarbeitung. Wir werden zeigen, dass virtualisierte Systeme hier unabhängig von ihrer Grundkonstruktion einen massiven Vorteil gegenüber konventionellen Betriebssystemen haben.

Die heute durch Produkte materialisierten grundsätzlichen Konstruktionsalternativen sind:

  • Binäre Translation (VMware)
  • Paravirtualisierung (Xen)
  • Hardware-Integration (AMD, Intel)

Wie wir sehen werden, kann man sie auch grundsätzlich mischen. Hier muss zur Erklärung noch vorausgeschickt werden, dass es sich eingebürgert hat, die in einem Betriebssystem befindlichen und möglichen Elemente in eine Klassifizierung einzuordnen, die auch als Ring bezeichnet wird. Je geringer die Nummer eines Ringes ist, desto weiter liegt er „innen“. Je weiter er „innen“ liegt, desto unmittelbarer kann eine Komponente in ihm auf die Hardware zugreifen. Je unmittelbarer ein Hardware-Zugriff ist, desto schneller läuft es ab. Ursprünglich war das Ringmodell wie das ISO-Referenzmodell als harte Strukturierung gedacht: eine Komponente auf dem Ring n darf nur auf definierte Dienstleistungen einer Komponente im Ring n-1 zugreifen und ausschließlich Dienstleistungen erbringen, auf die eine Komponente im Ring n+1 zugreifen kann.

Das Ringmodell ist dazu gedacht, Sicherheitsfunktionen zu systematisieren. An jeden Funktionsaufruf kann man problemlos Rechte binden. Nur wer die entsprechenden Rechte hat, kann darauf hoffen, dass die durch diese Rechte geschützte Funktion auch für ihn ausgeführt wird.

Wie wir unsere Betriebssystementwickler aber kennen, haben sie auch das genau wie die HAL schnell zum Schweizer Käse gemacht und es gibt Übergriffe über mehrere Ringe hinweg. Darum gibt es auch bis zum heutigen Tage kein mathematisch beweisbar sicheres Betriebssystem, an dem man Mitte der 70er-Jahre kräftig geforscht hat (PSOS = Provable Secure Operating System)

VMware bevorzugt die sogenannte „binäre Translation“, siehe Bild 1. Über der Hardware sitzt direkt im Ring 0 die VM-Maschine, also der Hypervisor. Diese erzeugt auf dem Ring 1 die Gastbetriebssysteme, also die virtuellen Maschinen. Soweit ist die Welt noch in Ordnung. Anwendungen auf dem Ring 3 dürfen aber nicht nur auf die Gastbetriebssysteme im Ring 1 zugreifen, sondern auch direkt auf die Hardware. Dann werden sie natürlich schneller, aber die Struktur wird doch ziemlich durchlöchert. Der Ring 2 ist im Bild unbesetzt. Hier wird man in Zukunft Funktionen zur Systemsteuerung von außen und Sicherheitsfunktionen ansiedeln können.

Mit der sogenannten Paravirtualisierung geht Citrix noch einen Schritt weiter, siehe Bild 2. Der Hypervisor wird unmittelbar auf die Hardware gepackt, also unter den Ring 0. Damit wird er zur Hardware-Erweiterung, denn da sind normalerweise höchstens gerätenahe Treiber oder die HAL. Die virtuellen Maschinen werden durch paravirtuelle Gast-Betriebssysteme auf dem Ring 1 gebildet. Der Vorsatz „Para“ wird übrigens nirgendwo erklärt, es ist eher ein Werbegag, der irgendwie suggerieren soll, dass es sich um etwas ganz besonderes handelt. Wie auch immer können die Anwendungen auf Ring 3 ebenfalls unmittelbar auf die Hardware zugreifen. „Hypercalls“ auf die Virtualisierungsschicht ersetzen aber auch nicht virtualisierbare Betriebssystem-Instruktionen. Damit eröffnet Citrix die Perspektive, sich auf längere Sicht von dem direkten Durchgriff auf die Hardware zu verabschieden. Wohin das auf Dauer führt, werden wir dann sehen.

Die Hardware-Hersteller sehen das schließlich noch etwas anders, siehe Bild 3. Man hat erkannt, dass Virtualisierungskonzepte an manchen Stellen wirklich den Zugriff auf die Hardware benötigen, wir haben im nächsten Abschnitt ein Beispiel dafür. Also besinnt man sich auf die Wurzeln des Ringkonzeptes und führt zwei Modi ein: einen Root Mode und einen Non-Root Mode. Für beide Modi gibt es eine Reihe von Sicherheitsvoraussetzungen, die vor allem den Root Mode schützen. Alle Komponenten in den bisherigen Ringen kommen in den Non-Root Mode, die Virtualisierungssoftware gehört aber zusammen mit der Hardware zur Root. Hier sehen wir sofort einen Zusammenhang zur Konstruktion von Microsoft in Bild 15 (*Das ist ein Verweis auf Bild 8 des Kapitels 3), die Sie eigentlich nur um 90 Grad nach links kippen müssen. Es gibt nach wie vor eine direkte Ausführung von Requests aus einer Benutzer-Anwendung. Sie sind aber jetzt durch die Trennung zwischen den Modi besser abzugrenzen. Betriebssystem-Requests gehen an die VM-Maschine ohne binäreTranslation oder Paravirtualisierung.

Die hier geschilderten Alternativen können sich noch weiterentwickeln und es kann für keine Alternative ein Leistungsvorsprung alleine aus der Konstruktion hergeleitet werden. Die Sicherheit innerhalb eines solchen Betriebssystems mit virtuellen Maschinen ist ein wesentliches Spezialthema, welches ich aber hier aus Gründen der Übersichtlichkeit nicht behandeln möchte.

Kommen wir stattdessen zur Transaktionsverarbeitung.

In einem klassischen Betriebssystem unterliegt die Verarbeitung von Transaktionen, z. B. Datenbanktransaktionen, einem langen Weg, den man in Bild 4 sieht.

Die Anfrage für eine Transaktion kommt üblicherweise von außen, also z. B. über den HBA ins System. Der Scheduler muss dafür einen systemunterstützenden Elementarprozess bereitstellen, der die Kommunikation behandeln kann. Dazu muss es einen Systemprozess geben, dessen Laufzeitumgebung an den systemunterstützenden Elementarprozess angebunden wird. Das ist im Bild der dunkelblaue. Die eigentliche Transaktion wird aber durch eine Transaktionsanwendung unterstützt. Deren Laufzeitumgebung muss ebenfalls vom Dispatcher gebunden werden, und zwar an einen anwendungsunterstützenden Elementarprozess, der dazu ebenfalls vom Scheduler bereitgestellt wird Für eine einzige Transaktion benötigen wir also wenigstens zwei Elementarprozesse, zwei Laufzeitumgebungen und zwei Prozesse auf der Anwendungsebene. Der Vereinfachung halber gehen wir davon aus, dass letztere via ihrer Laufzeitumgebungen kommunizieren können. Eine IPC für die Ebene der Laufzeitumgebungen ist eigentlich auf allen modernen Systemen Standard. Ist dann der Anwendungsprozess, der die Transaktionsanwendung unterstützt, endlich fertig, muss das Ergebnis vom Systemprozess an den HBA zur Ausgabe an den Initiator der Transaktion übergeben werden. Das wäre ja alles nicht so schlimm, aber alle diese Vorgänge müssen nacheinander ablaufen und die Transaktionsverarbeitung ist erst dann komplett, wenn das Ergebnis ausgegeben wurde.

Da der Scheduler nur eine begrenzte Menge von Elementar-Prozessen hat und von diese zu einer Zeit ja auch nur einer laufen kann, kann eine zeitlich folgende Transaktion erst dann ausgeführt werden, wenn die aktuelle Transaktion vollständig abgeschlossen ist.

Das kann natürlich dazu führen, dass die Transaktionsverarbeitung insgesamt langsam wird. Dummerweise fallen Transaktionen unter diejenigen Anwendungen, die an und für sich sehr klein sind. Daher können sie eine mögliche Parallelisierung z. B. durch mehrere Cores nicht nutzen. Es macht aber auch keinen Sinn, mehr Laufzeitumgebungen für die Transaktionsanwendung zu konstruieren, weil zu einer Zeit eben doch nur ein Elementarprozess tatsächlich laufen kann. Das ist ein ziemliches Dilemma.

Hier kann die Virtualisierung ihre wahren Stärken ausspielen, siehe Bild 5.

Wie immer kommt die Anfrage nach einer Transaktionsbearbeitung über den HBA von außen. Der Scheduler (also heute der Hypervisor) stellt einen Elementarprozess bereit, der die Anfrage abfängt und an eine virtuelle Maschine weitergibt, die als Anwendung das Programm hat, welches die Transaktionsverarbeitung durchführt und dafür eine entsprechende Laufzeitumgebung bereitstellt.

Dadurch ist die Transaktion aber von der physikalischen Maschine zunächst einmal verschwunden. Es entsteht somit die einzigartige Möglichkeit, mit dem Beginn der Bearbeitung der nächsten Transaktionsanfrage bereits anzufangen bevor die vorhergehende Transaktion fertig ist. Damit das funktioniert, muss die nächste Transaktionsanfrage auf eine andere virtuelle Maschine gebracht werden.

Bei nur einem Prozessor oder Core bringt das natürlich gar nichts, im Gegenteil, es entsteht nur noch mehr Overhead. Da aber ein Hypervisor wie bereits dargestellt, mehrere Cores ansprechen und beschäftigen kann, erzielen wir durch die Parallelisierung endlich einen Geschwindigkeitsvorteil bei der Transaktionsverarbeitung.

Historisch gesehen war das der größte Vorzug des alten VM von IBM. Auch hier gab es schon bis zu vier Prozessoren und trotz des enormen Overheads durch die archaische Konstruktion der virtuellen Maschinen konnte man schon damals damit die Transaktionsverarbeitung erheblich beschleunigen.

Betrachten wir ein aktuelleres Leistungsbeispiel. Exchange Mailboxen können mit VMware auf multiple kleinere virtuelle Maschinen abgebildet werden um den Durchsatz des physikalischen Servers zu maximieren. Exchange kann z. B. auf 8 virtuelle Maschinen gebracht werden, die jede für sich 2000 schwerbeschäftigte Mailboxnutzer versorgt, insgesamt also 16.000 Benutzer auf einem Server.

Die neue Variante VMware Hypervisor ESX (in vSphere, kommt später) kann anspruchsvolle Workloads z. B. durch folgende Verbesserungen realisieren:

  • Skalierbarkeit der virtuellen Maschine auf 4 virtuelle CPUs und 64 GB Speicher
  • Disk-I/O-Skalierbarkeit bis hin zu 100.000 IOPS
  • Netzwerk-I/O bis hin zu 9 Gbit/s

Das ist jetzt nur ein Beispiel aus 2008, mittlerweile kalter Kaffee, zeigt aber ein wesentliches Merkmal, nämlich den Vorteil bei möglicher Parallelisierung, sehr deutlich.

Statt weiterer Beispiele kommen wir jetzt zum nächsten Block, der Kommunikation. Das was dort passiert, hat naturgemäß wesentliche Auswirkungen auf das Netz.

« Teil 3: Vom Urvater „IBM VM“ zu moderner VirtualisierungssoftwareTeil 5: VM-Kommunikation »


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.

*

.