Netzwerk-Grundlagen – Rechenzentrumsnetze im Umbruch, Teil 4 Transaktionsverarbeitung und VM-Kommunikation in virtuellen Systemen

Autor / Redakteur: Dr. Franz-Joachim Kauffels / Dipl.-Ing. (FH) Andreas Donner

Am Beispiel der Transaktionsverarbeitung kann man sehr schön zeigen, inwiefern virtualisierte Systeme nicht nur konventionelle Systeme „nachmachen“ können, sondern diesen gegenüber auch konstruktionsbedingt erhebliche Vorzüge haben. Ein weiterer spannender Punkt ist die Kommunikation virtueller Maschinen – vor allem vor dem Hintergrund wandernder Systeme.

Firmen zum Thema

So stellt sich VMware die Virtualisierung vor.
So stellt sich VMware die Virtualisierung vor.
( Archiv: Vogel Business Media )

In einem klassischen Betriebssystem unterliegt die Verarbeitung von Transaktionen, z.B. Datenbanktransaktionen, einem langen Weg, den man in Bild 1 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 Prozess. 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.

Bildergalerie
Bildergalerie mit 8 Bildern

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 diesen 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 Abbildung 2.

weiter mit: Transaktionsverarbeitung im virtualisierten Betriebssystem

Transaktionsverarbeitung im virtualisierten Betriebssystem

Wie immer kommt die Anfrage nach einer Transaktionsbearbeitung über den HBA von außen. Der Scheduler (also hier 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 diese 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 multiplen kleineren virtuellen Maschinen abgebildet werden, um den Durchsatz des physikalischen Servers zu maximieren. Exchange kann so z.B. auf acht virtuelle Maschinen gebracht werden, die jede für sich 2.000 schwerbeschäftigte Mailboxnutzer versorgt, insgesamt also 16.000 Benutzer auf einem Server.

Die 2008er Variante VMware Hypervisor ESX in vSphere kann anspruchsvolle Workloads zudem 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

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

weiter mit: VM-Kommunikation und wandernde virtuelle Maschinen

VM-Kommunikation und wandernde virtuelle Maschinen

Der Hersteller VMware hat eine genaue Vorstellung von der Zukunft, siehe Abbildung 3. Darin gibt eine virtuelle Infrastruktur, die alle möglichen Hardwarekomponenten vereinigt und allen Anwendungen vermöge virtueller Maschinen den Zugriff darauf erlaubt. Das hat natürlich durchaus seinen Charme und mit der später zu besprechenden vShpere sind sie der Sache schon ziemlich nahe gekommen.

Auf dem Weg dorthin sind allerdings noch einige praktische Probleme zu lösen. Hier steht vor allem die Kommunikation im Vordergrund. Grob kann man folgende Bereiche angeben, auf denen sich das abspielt:

  • Kommunikation mit IPC
  • Virtuelle Ethernet-Switches
  • Übergreifende virtuelle Switches
  • Wandernde virtuelle Maschinen

Sie sehen also, es geht um drei Aspekte: die Kommunikation virtueller Maschinen auf einem Rechner, die Kommunikation virtueller Maschinen über Systemgrenzen hinweg und die Erweiterung der Kommunikation auf den Aspekt des Wechsels einer gesamten virtuellen Maschine von einem Rechner auf einen anderen.

Jedes Betriebssystem bietet die Möglichkeit der Interprozesskommunikation IPC, siehe Abbildung 4.

Alle virtuellen Maschinen befinden sich auf dem gleichen Ring. Also können sie auch die für diesen Ring vorgesehene IPC benutzen. Leider gibt es hier in der Praxis eine Reihe deutlicher Grenzen. IPC funktioniert am besten bei gleichen oder nah verwandten Betriebssystemen. Zwischen unterschiedlichen Betriebssystemen, und die virtuellen Maschinen auf einer physikalischen Maschine können ja unterschiedlich sein, funktioniert IPC mitunter gar nicht oder schlecht. IPC-Standards haben sich in der Vergangenheit kaum durchsetzen können, es gab ja auch keinen zwingenden Grund für ihre Einführung. IPC kann damit nur in ausgesuchten Fällen oder in speziell zusammenhängenden Universen physikalische Systemgrenzen überschreiten.

Zusammenfassend bedeutet das: IPC ist nicht wirklich ein allgemeingültiges Konzept und ein Hypervisor wird immer Probleme haben, heterogene IPC-Anforderungen zu hanhaben.

Man musste also neue Wege finden. So ist z.B. Ethernet allgemeingültig und standardisiert, der überwiegende Teil der Anwendungen und Betriebssysteme kann mit Ethernet-Paketen arbeiten und kommunizieren.

Also ist es doch naheliegend, den virtuellen Maschinen einfach einen ebenfalls virtuellen Ethernet-Switch zu spendieren. Die Grundidee zeigen wir in Bild 5.

weiter mit: Die Grundidee eines virtuellen Ethernet Switches

Die Grundidee eines virtuellen Ethernet Switches

Wir bauen hierfür eine virtuelle Maschine auf, die als einzige Anwendung eine Software hat, die einen Ethernet-Switch nachbildet. In allen Virtualisierungskonzepten gibt es die Möglichkeit der Kommunikation zwischen den virtuellen Maschinen vermöge des Schedulers, denn, wie wir uns erinnern, gibt es eine Kommunikation zwischen den Elementarprozessen. Diese ist einheitlich und auf das System beschränkt.

Im Grunde genommen wird durch diese Konstruktion das Problem elegant verlagert und damit gelöst. Die allen virtuellen Maschinen grundsätzlich zur Verfügung stehende Kommunikation auf der Ebene der Elementarprozesse ist nicht mit einem allgemeinen IPC-Konzept zu verwechseln. Beim IPC-Konzept würden diejenigen Prozesse kommunizieren, die von den virtuellen Maschinen zur Unterstützung der auf den VMs arbeitenden Anwendungen zur Verfügung gestellt werden. Das ist wie schon dargestellt problematisch und z.B. zwischen einer Windows-VM und einer Unix-VM fast unmöglich. Also kommunizieren nicht die Virtuellen Maschinen, sondern die auf ihnen befindlichen Anwendungen mittels Ethernet-Paketen, was sie alle können. Denn im Rahmen eines Virtualisierungskonzeptes wird ja neben z.B. einer Speicherschnittstelle auch eine Schnittstelle zur Ethernet-Kommunikation bereitgestellt, und zwar von einem virtuellen systemunterstützenden Elementarprozess.

Dieser wird wie alle anderen Elementarprozesse einer vrtuellen Maschine durch einen realen systemunterstützenden Elementarprozess implementiert. Daher steht ihm in diesem Zusammenhang auch die Kommunikation der realen Elementarprozesse zur Verfügung.

Was wir bisher beschrieben haben, war die Implementierung eines virtuellen Ethernet-Switches auf einem gehosteten System. Das ist zwar möglich, aber unpraktisch, denn es gibt ja die Hypervisoren.

Da ein Hypervisor ohnehin massiv auf die physikalischen Prozessoren und Geräte zugreift, kann man den virtuellen Ethernet-Switch besser hier ansiedeln. Er benutzt dann zwar im Grunde immer noch das grade beschriebene Kommunikationskonzept, ist aber durch die engere Integration in den Hypervisor näher an der Hardware; siehe Abbildung 6.

Ein Hypervisor hat grundsätzlich die Möglichkeit, die Kommunikation zwischen den virtuellen Maschinen, auch für unterschiedliche Gastsysteme, zu realisieren. Er hat aber keine Oberfläche, die sich so bedienen lässt wie die eines Switches. Also muss der virtuelle Ethernet Switch als Ergänzung des Hypervisors, und zwar implementiert auf dessen Ebene, gesehen werden. Dadurch erhält der virtuelle Switch einen fast direkten Zugriff auf den HBA und damit die direkte Möglichkeit der Kommunikation nach draußen; siehe Abbildung 7.

Speicherkommunikation

Wir haben das hier bisher mit Ethernet-Paketen erklärt. Es gibt aber noch eine weitere wichtige Kommunikationsart: den Speicherverkehr. In anspruchsvolleren Umgebungen mit Storage Area Networks gibt es hier den Fibre Channel. Führende Hersteller in diesem Bereich, wie Brocade, lassen natürlich die virtuellen Maschinen nicht im Regen stehen sondern bieten ebenfalls vergleichbare Lösungen an.

Virtuelle Switches können mit den gleichen Merkmalen ausgestattet werden wie ihre physikalischen Brüder. Man kann also z.B. VLANs bilden, um die Kommunikation nur auf bestimmte virtuelle Maschinen zu beschränken oder eine Priorisierung vorsehen, um bestimmte Verkehrsflüsse bevorzugt behandeln zu können. Da virtuelle Switches reine Software sind, kann man natürlich alle relevanten bestehenden Standards implementieren und in Zukunft neue Standards leicht integrieren. Lediglich ihre Leistung lässt sich nicht wie üblich in Schnittstellenanzahl multipliziert mit Schnittstellenleistung beschreiben, denn sie hängt einzig und alleine vom Hypervisor und seinen Möglichkeiten in der Multi-Core-Umgebung ab.

Da ein virtueller Ethernet Switch einen Zugriff zum HBA hat, kommen wir über ihn endlich dazu, virtuelle Maschinen systemübergreifend verbinden zu können. Dazu müssen die betroffenen HBAs lediglich an eine vorhandene Ethernet-Infrastruktur angeschlossen werden, siehe Abb. 8

In einem Zuge wird damit das physikalische Netz ebenfalls virtualisiert, denn die virtuellen Maschinen können die physikalischen Systemgrenzen nicht sehen und „denken“, dass sie über eine virtuelle Ethernet-Struktur miteinander verbunden sind. Das wäre in Abb. 8 der dicke graue Doppelpfeil.

Der Nexus 1000 V von Cisco Systems ist ein virtueller Ethernet-Switch. Er wurde von Cisco und VMware gemeinsam entwickelt. Mit entsprechenden Supervisor-Modulen lässt er sich genauso steuern wie ein physikalischer Switch. Es gibt von Cisco ein Video dazu, wo man sehen kann, wie einfach das ist. So kann man z.B. leicht und mit wenigen Klicks VLANs definieren und virtuelle Maschinen in diese VLANs einbinden.

Aber damit sind die wirklichen Fähigkeiten dieses Virtuellen Switches längst nicht erschöpft.

weiter mit: Herausforderung wandernde Maschinen

Herausforderung wandernde Maschinen

Ich möchte hier noch mal einen Satz vom Anfang dieser Darstellungen wiederholen:

Die Virtualisierung kann kurz so charakterisiert werden, dass sie die bisher unflexiblen physikalischen Maschinen mit ihrer normalerweise recht starren Zuordnung zwischen Maschinen und Anwendungen flexibilisiert und so ein System schafft, in dem man (virtuelle) Maschinen mit ihren assoziierten Anwendungen relativ freizügig über die physischen Maschinen zuordnen und bewegen kann.

Nur die Möglichkeit zur Bewegung der Virtuellen Maschinen über physikalische Systemgrenzen hinaus bringt uns in die Dimension der freizügigen Lastverteilung und erheblich verbesserten Möglichkeiten bei der Disaster Recovery.

So entstehen die berühmt-berüchigten „wandernden virtuellen Maschinen“.

Das dazu passende Produkt von VMware heißt sinnigerweise VMotion.

Auf einem Server seien drei virtuelle Maschinen. Sie sind alle mit dem virtuellen EthernetSwitch verbunden und besitzen auch jeweils eigene Zuordnungen zu VLANs. Sinn des Ganzen ist in diesem Falle nicht die Lastverlagerung, sondern die Unterstützung eines unterbrechungsfreien Betriebs. Durch die Aktivierung von VMotion wandern die virtuellen Maschinen auf einen anderen Server. Die virtuellen Maschinen sind kompakter als man vielleicht glaubt. Deshalb dauert ihre Übertragung auf einen anderen Server nicht lange, schon gar nicht, wenn die HBAs und das physikalische Ethernet 10 GbE unterstützen.

Bei einer Wanderung nehmen die Virtuellen Maschinen alle ihre Eigenschaften, z.B. die Einbindung in ein VLAN oder eine Priorisierung einfach mit.

Alles andere wäre auch fatal, denn dann müssten sie ja noch neu konfiguriert werden, bevor sie wieder arbeiten können. Das würde dem Ansatz der Unterstützung eines unterbrechungsfreien Systems widersprechen. Es sei noch bemerkt, dass die Server natürlich nicht nebeneinander stehen müssen, um eine Wanderung zu unterstützen, sondern lediglich Ethernet-HBAs besitzen müssen, die durch ein praktisch beliebiges Ethernet verbunden werden können.

Wie schafft man es nun, dass die virtuellen Maschinen ihre Eigenschaften mitnehmen können? Nun, die Anzahl möglicher Eigenschaften ist begrenzt und kann im Grunde genommen durch einen standardisierten Vektor beschrieben werden, in den lediglich die aktuellen Parameter eingetragen werden müssen.

Für die Wanderung werden VMs mit einem standardisierten Vektor und dessen aktuellen Parametern getagt. So weiß der Hypervisor auf dem Zielserver ganz genau, was er zu tun hat.

Bleibt noch die Frage, wie das physikalische Ethernet darauf reagiert, dass die virtuellen Maschinen von einem Server verschwinden und auf einem anderen Server wieder auftauchen. Doch auch das hat man ganz elegant gelöst. Virtuelle Maschinen sind immer in VLANs eingebunden. Die gegenüber einem physikalischen Netz wesentliche charakterisierende Eigenschaft ist also keine MAC-Adresse oder virtuelle MAC-Adresse, sondern die Zugehörigkeit zu einem VLAN. Und das ist ja grade eine Eigenschaft, die sie bei der Wanderung mitnehmen.

Momentan schlagen sich die Hersteller aber noch mit hausgemachten Problemen herum. Ich hatte schon mehrfach bemängelt, dass die HAL ganz fehlt bzw. heftig durchlöchert ist. Das hat jetzt unmittelbar zur Folge, dass die virtuellen Maschinen wegen der bestehenden Hardware-Abhängigkeiten nicht auf beliebige Server wandern können. So ist bspw. eine Wanderung von einem Intel-Server auf einen AMD-Server zum Zeitpunkt der Manuskripterstellung fast unmöglich und selbst innerhalb der Intel-Server ist sie abhängig vom zugrundeliegenden Prozessor. Wenn die Zielmaschine nicht eine fast perfekte Kopie der Quellmaschine ist, kann es zu Problemen kommen. Da müssen sie also noch dran basteln. Das geht aber nicht ohne die Hilfe der Hardware-Hersteller.

Fassen wir zusammen

Zunächst einmal erschienen die wandernden Virtuellen Maschinen merkwürdig. Man kann damit aber viel machen, wenn es funktioniert:

  • Schneller Lastausgleich
  • Unterbrechungsfreier Betrieb oder wenigstens
  • Schnelles Wiederaufsetzen nach Server-Ausfall

Noch funktioniert VMotion nur eingeschränkt, man kann nur zwischen bestimmten Intel-Prozessoren wechseln und nicht zwischen Intel und AMD. Aber das ist nur vorübergehend, die HW-Hersteller arbeiten auch daran.

Alles in allem sind die wandernden virtuellen Maschinen aber ein faszinierendes Konzept, welches die Möglichkeiten der Virtualisierung erst richtig zur Entfaltung bringt.

Weiter mit Teil 5

Zurück zu Teil 3