Die (R)Evolution der Rechenzentren; Teil 5 Transaktionsverarbeitung, VM-Kommunikation und wandernde virtuelle Maschinen

Am Beispiel der Transaktionsverarbeitung kann man sehr schön zeigen, inwiefern virtualisierte Systeme nicht nur konventionelle Systeme „nachmachen“ können, sondern auch wie diese ihre konstruktionsbedingten Vorteile ausspielen. Ein weiterer spannender Punkt ist die Kommunikation virtueller Maschinen – mit besonderem Augenmerk auf deren Wanderung, die Grundlage für attraktive Hochverfügbarkeitskonzepte der Virtualisierung ist.

Anbieter zum Thema

Dell GmbH

Lenovo Global Technology Germany GmbH

Southern Tech GmbH

ComConsult Akademie

ComConsult Beratung und Planung GmbH

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; im Bild dunkelblau.

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 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 Parallelelisierung 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 2.

Wie immer kommt die Anfrage nach einer Transaktionsbearbeitung über den HBA von außen. Der Scheduler (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.

Virtualisierung: Multi-Core tut not

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.

weiter mit: Exchange Mailboxen mit VMware verwalten

(ID:2050069)