Netzwerk-Grundlagen – Rechenzentrumsnetze im Umbruch, Teil 4
Transaktionsverarbeitung und VM-Kommunikation in virtuellen Systemen
01.07.2010 | Autor / Redakteur: Dr. Franz-Joachim Kauffels / 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.
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.
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
Weiterbildung für IT-Profis
Inhalt des Artikels:
- Seite 1: Transaktionsverarbeitung und VM-Kommunikation in virtuellen Systemen
- Seite 2: Transaktionsverarbeitung im virtualisierten Betriebssystem
- Seite 3: VM-Kommunikation und wandernde virtuelle Maschinen
- Seite 4: Die Grundidee eines virtuellen Ethernet Switches
- Seite 5: Herausforderung wandernde Maschinen
Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 2045843)
Sehr geehrte Leserinnen und Leser,