vMotion zwischen redundanten Rechenzentren

Kommentieren Drucken

Netzwerkvirtualisierung ist einer der aktuellen Trends im modernen Rechenzentrum. Die zugrundeliegende Architektur setzt auf Overlay-Strukturen auf, die durch Tunnelprotokolle wie VXLAN (siehe VXLAN (Virtual eXtensible LAN) – VMwares neuster Draft), NVGRE, STT oder SPB (IEEE 802.1Qaq – siehe auch Shortest Path Bridging vs. TRILL – Ein Vergleich) aufgebaut werden.

Trotz des Hypes um Netzwerkvirtualisierung – VMware führt dies übrigens unter dem Begriff SDDC (Software Defined Datacenter), wohl auch, um den nächsten Modebegriff „software-defined“ ebenfalls unterzubringen – kann man sich nicht des Eindrucks erwehren, dass vielerorts händeringend Einsatzszenarien für diese Techniken gesucht werden.

Die Vorteile von Netzwerkvirtualisierung sind weitgehend bekannt:

  • automatische Provisionierung ganzer Netzwerksegmente (z. B. Multi-Tier-Strukturen für Webanwendungen),
  • Integration von Netzwerkdiensten wie Routing, Firewalling, DHCP etc.,
  • Mandantenfähigkeit, d. h. Trennung der Netzsegmente und Nutzung gleicher Netzwerkadressen (MAC, IP, VLANs),
  • Konnektivität innerhalb des virtualisierten Segments, auch über Grenzen des physischen Netzwerks hinweg.

Die ersten drei Punkte adressieren offensichtlich mehr oder weniger „große“ Rechenzentren. Wo bleiben aber kleine bis mittlere Rechenzentren? Wo liegt der Nutzen, wenn ich keine automatische Provisionierung und keine Mandantenfähigkeit brauche?

Eines der häufig diskutierten Einsatzszenarien für Netzwerkvirtualisierung ist daher der Wunsch, vMotion (oder Live Migration, XenMotion etc.) über RZ-Grenzen hinweg einsetzen zu können – quasi Netzwerkvirtualisierung als Mittel zur Verbesserung der Verfügbarkeit.

Um virtuelle Maschinen während ihres Betriebs zwischen zwei Rechenzentren verschieben zu können, müssen natürliche einige Voraussetzungen erfüllt sein:

  • zumindest nahe verwandte Prozessorarchitekturen auf dem Quell- und Ziel-Host,
  • keine „Virtualisierungsspezialitäten“ (z. B. verhindert die Konfiguration von direktem Hardware-Zugriff in der Regel das Verschieben virtueller Maschinen),
  • genügend Bandbreite und genügend freie Kapazität auf der Leitung zwischen den Rechenzentren,
  • von der neuen Lokation muss weiterhin performant auf die virtuellen Festplatten zugegriffen werden können (Das heißt, dass unter Umständen die Festplatten mit verschoben werden müssen (Storage vMotion, Spiegelung des Storage o. ä.).) und
  • Layer-2-Konnektivität zwischen Quell- und Ziel-Host.

Die vier ersten Punkte liegen auf der Hand und können durch geeignete Infrastrukturmaßnahmen umgesetzt werden, der zu guter Letzt entscheidende Punkt ist aber, dass sich der verschobene virtuelle Server in der Regel (also wenn keine RZ-übergreifende Layer-2-Domäne vorliegt) in einem neuen IP-Subnetz befindet und damit eben nicht mehr ohne weiteres erreichbar ist.
Netzwerkvirtualisierung löst auch dieses letzte Problem – zumindest theoretisch.

In der Praxis muss man aber sehr genau wissen, was man da tut. Einfach eine Overlay-Lösung über das bestehende Netzsegment zu stülpen, kann leicht im Desaster enden.
Schauen Sie sich hierzu Bild 1 an: zwei Rechenzentren A und B, zwei IP-Subnetze (blau und rot) und diverse Server. Außerdem erfordert die eingesetzte Anwendung eine Kommunikationsverbindung zwischen VM-1 im blauen und VM-2 im roten Subnetz. Das Routing zwischen blau und rot wird über einen dedizierten Router oder Layer-3-Switch im Rechenzentrum A erledigt. Solange sich jetzt VM-1 im Rechenzentrum A befindet, passiert nichts Spektakuläres: Die Pakete laufen von VM-1 zum Router ins rote Subnetz, von dort durch den roten Layer-2-Tunnel ins RZ B zu VM-2.

Falls aber die virtuelle Maschine VM-1 ins Rechenzentrum B verschoben wird, ändert sich das Bild: Da die Routing-Instanz nach wie vor im Rechenzentrum A steht, müssen alle Pakete erst durch einen blauen Tunnel zurück ins RZ A, dort werden sie ins rote Subnetz geroutet und dann müssen sie durch einen roten Tunnel zum zweiten Mal über die WAN-Strecke ins RZ B – im Englischen nennt man das „traffic trombone“.

Das ist offensichtlich nicht gerade das Gelbe vom Ei. Und das bleibt auch dann ungünstig, wenn es sich in dem Beispiel nicht um zwei getrennte Rechenzentren, sondern nur um zwei unterschiedliche Racks in unterschiedlichen Subnetzen handelt.

Jetzt kann man lang und breit diskutieren, wo hier der Fehler liegt und wie man dieses Problem löst. Der typische Netzwerker neigt an dieser Stelle dazu in seiner alten Lösungskiste zu kramen. Das Ergebnis hiervon sind dann auch eben auch hardware- und kostenlastige Vorschläge wie LISP oder irgendwelche abenteuerlichen Erweiterungen auf Basis von VRRP, GLBP o. ä.

Das eigentliche Problem in dem hier betrachteten Fall liegt aber aus meiner Sicht in einer Fehlkonfiguration der virtualisierten Umgebung! Wenn die Kommunikationsbeziehung zwischen VM-1 und VM-2 zur Anwendung gehört, dann ist auch das Routing zwischen den beiden virtuellen Servern und damit eine geeignete Routing-Instanz integraler Bestandteil des zu virtualisierenden Subnetzes. Wenn Sie das von Anfang an berücksichtigen, ergibt sich eine Lösung des Problems fast von selbst. Eine einfache Möglichkeit wäre beispielsweise, auch die Routing-Instanz zu virtualisieren und zusammen mit VM-1 zu verschieben.

Aber wie oben erwähnt: Einfach eine Umgebung mit virtualisierten Servern um eine Tunnellösung zu erweitern, führt Sie nicht weiter.

zugeordnete Kategorien: Data Center, 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.

*

.