Warum Layer 2?

Kommentieren Drucken

Angesichts der Herausforderungen, vor die der Trend zu Layer 2 in Rechenzentren die IT-Verantwortlichen in Unternehmen stellt, ist eine Diskussion um die Frage entbrannt, wie es zu diesem Trend kommen konnte, nachdem sich die Entwicklung der unternehmensinternen Netze jahrelang am durch und durch Layer-3-strukturierten Internet ein Beispiel genommen hatte.

Häufig wird der Bedarf an großen Layer-2-Domänen in Rechenzentren und sogar zwischen verschiedenen RZ-Standorten mit einem Schlagwort assoziiert: vMotion, als dem vom Hersteller VMware entwickelten Verfahren für die Verlagerung von virtuellen Maschinen (VMs). Dabei gerät oft in Vergessenheit, dass die Notwendigkeit Switch- oder gar Standort-übergreifender Layer-2-Strukturen in RZs viel älter als vMotion ist. Schon die in den 1990er Jahren oder um die Jahrtausendwende entwickelten Clustermechanismen der Hersteller HP (MC Service Guard für HP-UX), IBM (HACMP für AIX), Microsoft (Windows Cluster) und Sun (Sun Cluster Service) erforderten den Anschluss der Clusterknoten an die gleiche Layer-2-Domäne, denn bei der Verlagerung eines Dienstes von einem zum anderen Clusterknoten musste die IP-Adresse „mitgenommen“ werden, was nur innerhalb einer Layer-2-Domäne möglich ist. Nur ein IBM Mainframe Cluster stellte keine solche Forderung, denn die sogenannte Virtuelle IP-Adresse (VIP) befand und befindet sich hinter Routing-Instanzen im Mainframe-Verbund selbst. Dafür brauchte und braucht man für einen standortübergreifenden Mainframe-Verbund den sogenannten Channel Link (CL), der die Netzplaner mit noch größeren Herausforderungen konfrontiert als eine Layer-2-Verbindung (der IBM Support für den CL ist sogar auf bestimmte Fabrikate optischer Multiplexer beschränkt).

Auch Adapter-Teaming-Mechanismen, die nur in einer durchgängigen Layer-2-Domäne funktionieren, sind älter als vMotion. Der Schwenk von einem Adapter auf den anderen unter Beibehaltung der IP-Adresse ist nur in einer Layer-2-Domäne möglich. Sind die beiden Adapter an zwei verschiedene Switches angeschlossen, muss sich die Layer-2-Domäne über beide Switches erstrecken.

Aber warum wird die Layer-2-Forderung immer wieder mit vMotion in Verbindung gebracht? Dies ist vor allem darauf zurückzuführen, dass mit vMotion sozusagen die „freie Fahrt für freie VMs“ eingeführt werden kann, während die älteren Clusterverfahren in der Regel nur zwei physikalische Maschinen vorsahen, zwischen denen eine Punkt-zu-Punkt-Layer-2-Verbindung eingerichtet werden musste. Letztere ist kein sehr großes Problem: Man richte nur die standardisierte Link Aggregation Group (LAG) zwischen zwei Switches ein, die über verschiedene Glasfasernpaare miteinander verbunden sind, und schon hat man eine Switch-übergreifende Layer-2-Domäne. Aber wird aus einem Dual-Cluster ein ganzer Verbund von Virtualisierungshosts, die an verschiedene Switches im RZ angeschlossen sind, und will man VMs so beweglich halten, dass sie automatisch oder manuell gesteuert von jedem zu jedem anderen Host wandern, ohne eine neue IP-Adresse zu erhalten, braucht man Layer-2-Strukturen, die sich in der Regel auf mehr als zwei Switches erstrecken. Hier enden die Möglichkeiten von Standard-LAG. Beliebige Vermaschungen von Layer-2-Instanzen waren jahrelang nur unter Anwendung des Spanning Tree Protocol (STP) als der einzigen standardisierten Methode zur Konfiguration von Layer-2-Netzen ohne Single Point of Failure möglich.

Mit Berechtigung wird nun nicht selten die Frage gestellt, warum wandernde VMs ihre IP-Adresse „mitnehmen“ müssen. Es gehört zum Basiswissen jedes Netzadministrators, dass jede moderne Anwendung das Domain Name System (DNS) zur Zuordnung von IP-Adressen zu DNS-Namen nutzen sollte, dass sich IP-Konfigurationen unter Anwendung des Dynamic Host Configuration Protocol (DHCP) automatisch bewerkstelligen lassen und dass sichere automatische Abgleichmethoden zwischen der DHCP- und der DNS-Datenbasis möglich sind. Was hindert also die Hersteller daran, Methoden für die VM-Wanderung zu entwickeln, bei denen nach jeder Verlagerung einer VM diese per DHCP eine neue IP-Adresse bekommt und zum Beispiel unter Anwendung von Secure Dynamic DNS den zuständigen DNS-Server von ihrer neuen IP-Adresse in Kenntnis setzt? Wenn die VM ein Server ist, mit dem eine Anwendung auf einem anderen Gerät kommuniziert, sollte doch eine klug konzipierte Anwendung von sich aus auf die Idee kommen, unter Anwendung von DNS die neue IP-Adresse des Servers zu finden.

Und genau hier sind wir am Kern des Problems angekommen: Wie verhalten sich Anwendungen, wenn sich IP-Adressen der Maschinen, mit denen sie kommunizieren, ändern?

Die Anwendungen verhalten sich unterschiedlich, je nachdem, ob sie eine sogenannte Session Layer (entsprechend der Schicht 5 im OSI-Modell) nutzen oder nicht. Die Session Layer ist dafür zuständig, die Anwendung von der Transportadresse auf der Schicht 4 unabhängig zu machen. Vielleicht haben Sie mal erlebt, wie Ihr Mobilfunkbetreiber in ein laufendes, aber kurzzeitig unterbrochenes Telefongespräch eine Nachricht wie „Ihre Verbindung wird gehalten“ einspielt. Das kann zum Beispiel bei einem Zellenwechsel passieren. Die Kommunikation wird anschließend über einen völlig anderen Weg geführt, aber eine Intelligenz hat die Information über das Telefongespräch gehalten und stellt die Verbindung auf den unteren Schichten wieder her. Ein anderes Beispiel: Sie sitzen im Zug, und Ihr Microsoft-Outlook-Client kommuniziert über Funk mit dem MS-Exchange-Server Ihres Unternehmens. Die Funkverbindung bricht ab, und Outlook meldet sich mit der Meldung, dass die Kommunikation mit dem Server gestört sei und eine Wiederaufnahme der Kommunikation später versucht werde. Sie brauchen weder das Telefongespräch noch Ihren Outlook Client neu zu starten. Eine Intelligenz entsprechend der Funktion der Session Layer tut das für Sie.

Leider funktionieren nicht alle Applikationen so. Der von mir genutzte Online-Banking-Dienst zum Beispiel reagiert auf jede Unterbrechung der Netzverbindung mit dem Abbruch der Session. Nach dem Aufbau einer neuen Session hebt die Bank den pädagogischen Zeigefinger:

Nebenbei bemerkt: Wenn die Anwendung schon auf kurzzeitige Netzunterbrechungen, mit denen jede Anwendung leben sollte, mit solchen Meldungen reagiert, darf man sich nicht wundern, wenn die Sicherheitswarnungen von den meisten Anwendern ignoriert werden. Die wirklich wichtigen Sicherheitsmeldungen gehen dann in der Flut unnötiger Nachrichten unter.

Aber jetzt zurück zur Diskussion der unterschiedlichen Verhaltensweisen der Anwendungen. Vielleicht ist es aus Sicherheitsgründen sinnvoll, dass eine Session für Online Banking bei Netzproblemen abgebaut wird. Hinsichtlich Benutzerfreundlichkeit gibt es aber einen Unterschied zwischen dem aufrecht erhaltenen Telefongespräch sowie der automatisch wiederhergestellten Outlook-Session einerseits und dem überempfindlichen Online Banking andererseits.

Es gibt noch viele Anwendungen, die „Socket-basierend“ programmiert worden sind. Ein Socket ist in der IP-Welt per definitionem die Kombination aus IP-Adresse und Portnummer, in der Regel TCP-Portnummer. Wenn einer solchen Anwendung der Socket unter den Füßen weggerissen wird, funktioniert sie nicht mehr und bricht ab. Schlimm ist die Auswirkung auf solche Anwendungen, die dann inkonsistente Datenbestände zurücklassen. Gegen gelegentlich neu aufzubauende Sessions haben die meisten Anwender nichts einzuwenden, gegen korrumpierte Daten schon.

Deshalb brauchen Netzbetreiber, vor allem RZ-Netzbetreiber, immer sogenannte Wartungsfenster, wenn sie aus bestimmten Gründen Teile eines Netzes temporär außer Betrieb nehmen müssen (zum Beispiel um nach einem Software Update die Netzkomponenten neu zu booten). Der Infrastrukturbetreiber kann bei laufenden Anwendungen das Netz nicht ohne Weiteres außer Betrieb nehmen, denn auf manche Applikationen kann sich dies verheerend auswirken, bis hin zu korrumpierten Daten. So müssen Wartungsfenster mühsam mit vielen Abteilungen und Verantwortlichen für Applikationen abgestimmt werden.

Das ist für viele Infrastrukturbetreiber ein Ärgernis. Jede Migration, jede Umstellung ist langwierig und schwierig, weil man lange auf die Erlaubnis dafür und das ersehnte Wartungsfenster warten muss.

Mit der Servervirtualisierung kam aber ein Hoffnungsschimmer auf: es wäre doch verlockend, VMs bewegen zu können, ohne dass die Anwendungen dies mitbekommen. Dann könnte man die Infrastruktur auch im laufenden Betrieb warten. Man verlagere die VMs auf einen Teil der Infrastruktur, „räume“ den anderen Teil und kann letzteren vorübergehend außer Betrieb nehmen und „bearbeiten“.

Hier schließt sich der Kreis: der Netzbetreiber will ein wartungsfreundliches Netz, das erfordert die transparente Beweglichkeit von VMs, was aber bei manchen Anwendungen nur funktioniert, wenn die VMs ihre jeweilige IP-Adresse mitnehmen. Also muss der Netzbetreiber Layer-2-Strukturen im RZ aufbauen.

Zu Spanning-Tree-Zeiten handelte man sich dafür viele Nachteile ein, vor allem den Nachteil eines eigentlich schon immer unberechenbaren Protokolls, dessen Fehlfunktion sofort die ganze große Layer-2-Domäne (also das ganze RZ) außer Gefecht setzen konnte. Das muss heute nicht mehr sein, da die meisten führenden Hersteller von Netzkomponenten zumindest Multi-Chassis Link Aggregation (MC-LAG) unterstützen und damit ein im Vergleich zu Spanning Tree wesentlich robusteres, berechenbareres und schneller reagierendes Verfahren anwendbar ist.

MC-LAG löst natürlich nicht alle Probleme eines RZ-Netzbetreibers und lässt viele Fragen offen, vor allem im unvermeidlichen Zusammenspiel mit Layer 3. Das aber ist eine andere Geschichte.

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

*

.