VM-Kommunikation

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

Der Hersteller VMware hat eine genaue Vorstellung von der Zukunft: Es 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.

Bild 1 zeigt die Vision. Bei den praktischen Problemen steht vor allem die Kommunikation im Vordergrund.

Hinsichtlich der Kommunikation sind folgende Aspekte von Belang:

  • Kommunikation der VMs auf einer physischen Maschine untereinander und mit den lokalen Betriebsmitteln der physischen Maschine
  • Kommunikation von VMs auf einer physischen Maschine mit der Außenwelt
    • I/O
    • Speicher
  • Kommunikation der VMs mit VMs auf anderen physischen Maschinen
  • Wanderung von VMs von einer physischen Maschine auf eine andere.

Es gibt hier eine mit vielen Einzelheiten behaftete Entwicklung über die letzten Jahre. Den neuesten Stand und die aktuellen Diskussionen kann man aber nur dann verstehen, wenn man auch die „Vorgänger“ kennt.

Wir beginnen daher mit folgenden Bereichen:

  • Kommunikation mit IPC
  • Virtuelle Ethernet-Switches
    • Gehostete virtuelle Ethernet-Switches
    • Virtuelle Ethernet-Switches auf Hypervisor-Ebene
    • Kommunikation mit der Außenwelt
  • Übergreifende virtuelle Switches
  • Beispiel Cisco Nexus 1000 V
  • Wandernde virtuelle Maschinen für
    • Lastverteilung
    • Unterbrechungsfreier Betrieb

Andere, aktuelle Entwicklungen werden wir in späteren Folgen gesondert behandeln.

Nochmal: 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 2

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 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 handeln.

Der einzige IPC-Mechanismus, der zu mindestens im Bereich der HPC-Cluster erfolgreich standardisiert und implementiert wurde, ist RDMA (Remote Direct Memory Access). Er ist aber eng mit der Übertragungstechnik Infiniband verwoben, die im Umfeld normaler Corporate Networks eher selten vorkommt. Außerdem gibt es natürlich noch viele herstellerspezifische IPC-Mechanismen.

Man musste hier neue Wege finden. So ist z. B. Ethernet ist 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 3.

Wir bauen 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, die von den virtuellen Maschinen zur Unterstützung der auf den VMs arbeitenden Anwendungen, die also die virtuellen Laufzeitumgebungen breitstellen, kommunizieren. 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 über Ethernet-Pakete, 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 4

Ein Hypervisor hat die grundsätzliche Möglichkeit der Realisierung der Kommunikation zwischen den virtuellen Maschinen, auch für unterschiedliche Gastsysteme. Wenigstens Microsoft hat das auch im entsprechenden Fundamentaldiagramm Bild 15(*Verweis auf Bild 8 aus Kapitel 3*) als VMBus aufgegriffen, aber das können alle Hersteller. 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 bekommt der virtuelle Switch auch einen fast direkten Zugriff zum HBA und damit zur Kommunikation nach draußen, siehe Bild 5.

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. Das behandeln wir aber später.

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 z. B. IEEE 802.1 und 802.3-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 ich n 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 Bild 6.

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 Bild 6 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 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, wie wir in der nächsten Folge sehen werden.

« Teil 4: Grundsätzliche Konstruktionsalternativen und TransaktionsverarbeitungTeil 6: Wandernde virtuelle Maschinen »


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.

*

.