Wandernde virtuelle Maschinen

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

Das „Aufräumen“ vieler kleinerer Server mit ihren Speichersystemen auf einige wenige leistungsfähige moderne Server und die Virtualisierung der „aufgeräumten“ Server ist ein wesentlicher Schritt auf dem Weg zu einem modernen Rechenzentrum. Doch damit sind die möglichen Vorzüge der Virtualisierung längst nicht ausgeschöpft. Das, was viele Betreiber noch mehr interessiert, sind Konzepte für Redundanz, Fehlertoleranz, Hochverfügbarkeit und flexible Lastverteilung. Dafür ist aber die Möglichkeit erforderlich, eine VM von einem physischen Server auf einen anderen bewegen zu können. Darüber hinaus ist die VM-Wanderung eine wichtige Grundlage für die zukünftige Skalierbarkeit der Leistungen eines RZs.

Ich möchte nochmal 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 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üchtigten „wandernden virtuellen Maschinen“.

Das dazu passende Produkt von VMware heißt sinnigerweise vMotion und ist in den Bildern 1, 2 und 3 zu sehen.

In Bild 1 sehen wir die Ausgangssituation. Auf dem linken Server sind drei virtuelle Maschinen. Sie sind alle mit dem virtuellen Ethernet Switch 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 den rechten Server, wie das in Bild 2 schematisch zum Ausdruck kommen soll. 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.

In Bild 3 sind sie auf dem Ziel-Server angekommen. Hierbei ist vor allem Folgendes ganz wichtig:

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.

Es gibt ein ähnliches Problem aus einer völlig anderen Ecke. Oftmals ist es nötig, völlig unterschiedliche Netzstrukturen miteinander zu verbinden und funktional zu verschachteln. Das tritt z. B. dann auf, wenn man normale Netze wie ein Ethernet über ein optisches Backbones zusammenschalten möchte. Die Problemstellung ist dann vergleichbar: wie schaffe ich es, den ggf. völlig anders arbeitenden Backbone so zu durchqueren, dass die Eigenschaften meiner Ethernet-Verbindung dabei erhalten bleiben und wie trenne ich in diesem Zusammenhang Forwarding und Kontrolle?

Dafür nimmt man oft MPLS.

MPLS, das Multiprotokoll Label Switching ist sozusagen eine standardisierte Variante des früher von Cisco vorgestellten Tag-Switchings. Es gibt hierbei einen Netzkern und eine Netzkante. An der Netzkante werden die Datenströme klassifiziert und gelabelt und im Kern passiert die Weiterleitung auf der Basis von Labeln anstatt auf der Basis von IP Adressen. Dadurch trennt man Forwarding und Kontrolle.

Im Betrieb sieht das dann so aus, dass existierende Routingprotokolle Erreichbarkeitsinformationen austauschen, und zwar im Rahmen eines normierten oder herstellerspezifischen Routing Protokolls. Das Label Distribution Protocol LDP tauscht dabei zusätzlich Label-Informationen aus. Damit wird eine logische Topologie für die Infrastruktur aufgebaut und jeder Knoten weiß, wie Datenströme eines Labels über das Netz geleitet werden können. Ein eingehender Link-Switch Router LSR an der Netzkante empfängt ein IP Paket, führt Layer-3 Services aus und versieht das Paket mit einem Label. Die Link-Switch-Router leiten die Pakete aufgrund der Labels weiter und der ausgehende Link-Switch-Router an der Netzkante entfernt das Label und liefert die Pakete aus.

Und genauso funktioniert auch die Wanderung virtueller Maschinen: sie werden mit einem standardisierten Vektor und dessen aktuellen Parametern getaggt. 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. Das haben sie auch 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.

Cisco und VMware verschleiern mit einem gewissen Recht auch ein paar letzte Geheimnisse der Wanderung, denn da hängen natürlich Patente dran. So ist es z. B. denkbar, „leere“ virtuelle Maschinen zu definieren und diese auch schon in die entsprechenden VLANs einzubinden. Sie würden einen Hypervisor nur unmerklich belasten, weil sie nur vorhanden sind, ohne etwas zu tun und letztlich nur eine schlafende Laufzeitumgebung darstellen. Das Ziel einer wandernden virtuellen Maschine könnte dann eine solche leere virtuelle Maschine sein. Die gewanderte VM könnte dann die leere VM mit all ihren Voreinstellungen sofort übernehmen. So würde ich es implementieren, wenn ich müsste.

Genauso spannend ist die Frage, was eigentlich passiert, wenn ein Server ganz plötzlich ausfällt und die auf ihm laufenden virtuellen Maschinen gar nicht mehr die Chance haben, zu wandern. Spontan fällt mir da nur die alte Lösung von Novell ein: man definiert auf einem Ersatzserver alles genau so wie auf dem aktuellen System. In kurzen Zeitabständen bringt man den Ersatzserver auf den jeweils neuesten Stand. Dann kann er im Falle eines Ausfalls sofort übernehmen. Auch dies wäre bei virtuellen Maschinen möglich, nämlich ebenfalls mit den leeren VMs.

Momentan schlagen sich die Hersteller aber noch mit Problemen herum, die im Wesentlichen hausgemacht sind. 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 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 nochmal 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. vMotion kommt von VMware und Cisco, es wird aber weitere Hersteller geben.

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

« Teil 5: VM-KommunikationTeil 7: Virtualisierung und Speichertechnologie »


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.

*

.