Transaktionsverarbeitung, VM-Kommunikation und wandernde virtuelle Maschinen

Anbieter zum Thema

Vitel GmbH

ComConsult Akademie

ComConsult Beratung und Planung GmbH

Exchange Mailboxen mit VMware verwalten

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 acht virtuelle Maschinen gebracht werden, die jede für sich 2.000 schwer beschäftigte Mailboxnutzer versorgt, insgesamt also 16.000 Benutzer auf einem Server.

Die 2008er Variante VMware Hypervisor ESX in vSphere kann anspruchsvolle Workloads z.B. durch folgende Verbesserungen realisieren:

• Skalierbarkeit der virtuellen Maschine auf vier 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.

VM-Kommunikation und wandernde virtuelle Maschinen

Der Hersteller VMware hat eine genaue Vorstellung von der Zukunft, siehe Bild 3. Dabei gibt es 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 vSphere ist man der Sache auch 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 dazu auch Bild 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 nur 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 nur in ausgesuchten Fällen oder in speziellen 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 handhaben.

Man musste hier 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.

Hierzu bauen wir 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.

Kommunikation auf der Ebene der Elementarprozesse

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 erzeugt 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 via Ethernet-Paketen, was sie alle können. 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 virtuellen 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 dazu Bild 6.

weiter mit: Kommunikation über den Hypervisor

(ID:2050069)