Die Nutzung von Layer-2-Kommunikation ohne Router als Vermittler kann verschiedene Gründe haben, darunter die folgenden:

• Einige Anwendungen nutzen nicht IP, sondern Ethernet ohne IP. Eine solche Anwendung benötigt eine Layer-2-Verbindung von Ende zu Ende. Beispiele gibt es in verschiedenen Bereichen. Fiber Channel over Ethernet (FCoE) ist als eine der Varianten für Storage-Kommunikation nicht IP-basierend. Gleiches gilt für einige Protokolle im Bereich industrieller Steuerung und Regelung einschließlich Gebäudeautomation.
• Manche IP-Applikationen nutzen Multicast IP statt Unicast IP. Die meisten IP-Netze (zum Beispiel das Internet) unterstützen keine Multicast-IP-Kommunikation. Es gibt daher Szenarien, in denen für Multicast-IP Layer-2-Netze genutzt werden.
• Der vielleicht häufigste Fall der Nutzung ausgedehnter Layer-2-Netze ist in Rechenzentren von Unternehmen zu finden. Seit ca. 20 Jahren sind in diesen RZs Cluster bzw. virtualisierte Umgebungen im Einsatz, die Layer-2-Kommunikation erfordern. Der Grund ist der Einsatz sogenannter virtueller IP-Adressen (VIP) für Server. Eine VIP ist von einzelnen physischen Servern unabhängig. Cluster- und Virtualisierungsmechanismen sorgen dafür, dass eine VIP von Hardware zu Hardware „wandern“ kann. Die „VIP-Mobilität“ löst das Problem, dass einige Anwendungen zusammenbrechen, wenn die IP-Adresse des zugehörigen Servers nicht mehr erreichbar ist.
• Eine weitere Motivation für ausgedehnte Layer-2-Netze ist organisatorischer Natur. Zum Beispiel wollen einige Unternehmen ihr Wide Area Network (WAN) einschließlich der Routing-Instanzen selbst betreiben. Sie mieten daher ein Layer-2-WAN. Ähnlich ist es bei einigen „Gewerken“ der Gebäudeautomation. Manche Betreiber in diesem Bereich fordern ausgedehnte Layer-2-Netze, weil sie diese schon immer für ihre Zwecke eingesetzt haben.

Es mag zusätzlich zu den oben genannten Fällen weitere Gründe für den Einsatz ausgedehnter Layer-2-Netze geben.

Die Cloud setzt Maßstäbe

Die aufgezählten Fälle der Nutzung ausgedehnter Layer-2-Netze gehen auf die Zeiten vor Cloud-Computing zurück. Mittlerweile hat die Cloud Maßstäbe gesetzt. Wir wissen, dass die Kommunikation in und mit großen Clouds auf IP basiert. Ferner wissen wir, dass der Standardweg für den Zugriff auf Software as a Service (SaaS) das Internet ist. Was Clouds als „Verlängerung des eigenen RZs“ (IaaS – Infrastructure as a Service) betrifft, kennen wir die Cloud-Standards auch: IP-Subnetze in großen Clouds erstrecken sich nicht über verschiedene Rechenzentren, sondern bleiben in aller Regel auf eine Availability Zone (AZ), d.h. ein RZ beschränkt. Damit kann eine VIP in der Cloud nicht vom RZ zum RZ „wandern“.

Kann man unter solchen Bedingungen überhaupt Hochverfügbarkeit realisieren? Ja, das ist möglich, indem die Anwendungen nicht mehr auf sogenannte feste „Sockets“ (Kombination aus TCP/UDP-Portnummer und IP-Adresse) aufsetzen. Ein prominentes Beispiel für die Unabhängigkeit von festen „Sockets“ sind moderne Webanwendungen. Der Web-Client, zum Beispiel ein Webbrowser, kommuniziert nicht mit einem festen „Socket“. Stattdessen nutzt der Web Client einen Uniform Resource Locator (URL), um die Webanwendung zu erreichen. Ein URL kann zwar als Server Locator eine IP-Adresse enthalten, sollte aber stattdessen lieber einen Fully Qualified Domaine Name (FQDN) nutzen, zum Beispiel www.comconsult.com. Im Rahmen des Domain Name System (DNS) führt das Gerät, auf dem der Browser läuft, eine sogenannte „Auflösung“ durch und erfährt, dass zu www.comconsult.com die IP-Adresse 185.21.102.156 gehört. Ändert sich die IP-Adresse von www.comconsult.com, stürzt der Browser nicht ab, sondern veranlasst nach einem Time-out eine neue DNS-Auflösung. Eine Protokollschicht oberhalb der Transport Layer sorgt dafür, dass der „Kontext“ für die Webanwendung erhalten bleibt. Diese Schicht wäre nach der Terminologie des Open Systems Interconnection (OSI) die „Session Layer“. Die „Sitzung“ geht nicht verloren, wenn die IP-Adressen der Endgeräte sich ändern, wie in der Abbildung 1 dargestellt.

Abbildung 1: Session Layer

Das gilt mittlerweile sogar auch für UC-Anwendungen. Im Zuge der Vorbereitung dieses Geleits habe ich das bei einer Microsoft-Teams-Session ausprobiert. Ich habe die Teams-Session unter Nutzung eines VPN-Tunnels aufgebaut und daran teilgenommen. Dann habe ich mitten in der Session den VPN-Tunnel abgebaut. Teams hat mir die Möglichkeit gegeben, wieder an der Session teilzunehmen, und dieses Mal ohne VPN-Tunnel, d.h. mit einer anderen IP-Adresse und über ganz andere Wege durch das Internet.

Die großen Cloud-Anbieter müssen keine Rücksicht auf alte Socket-basierende Applikationen nehmen. Sie gehen davon aus, dass eine moderne Anwendung eine Webapplikation ist. Dies bedeutet, dass auf der User-Seite immer ein Web-Client zum Einsatz kommt. Das muss nicht unbedingt ein normaler Webbrowser sein. Auch ein UC-Client kann im Netz ausschließlich als Web-Client in Erscheinung treten. Ein moderner Client verhält sich so wie ein moderner Webbrowser, d.h. er „hält“ den Kontext von Anwendungen, auch wenn sich die eigene oder die IP-Adresse des Web-Servers ändert.

In einer modernen Cloud erfolgt der Schwenk von einem zum anderen RZ nicht dadurch, dass die VIP wandert. Stattdessen gibt es Load-Balancing-Mechanismen, die Last auf verschiedene Instanzen verteilen. Diese Instanzen können auf verschiedene Rechenzentren (Availability Zones) verteilt werden.

Werden Layer-2-Netze durch Layer-3-Netze abgelöst?

Sobald ein RZ nur noch moderne Webanwendungen bedienen muss, kann die RZ-Infrastruktur so konzipiert werden wie in der Cloud. Damit entfällt eine der Hauptmotivationen für ausgedehnte Layer-2-Netze in Rechenzentren.
VIP-Wanderung ist aber wie erwähnt nicht die einzige Motivation für ausgedehnte Layer-2-Netze in RZs. Es bleibt noch die Frage, ob man für die Kommunikation zwischen Server und Storage etwas anderes als ein IP-Netz braucht:

• Fiber Channel (FC) in nativer Form nutzt nicht Ethernet, sondern separate Switches und Verbindungen. Insofern kommt FC ohne ausgedehntes Layer-2-Ethernet aus.
• FCoE benötigt Layer-2-Ethernet. Wer sich für FCoE entscheidet, braucht aber nicht nur ausgedehnte Layer-2-Netze, sondern auch besondere Switches. Diese müssen nicht nur Layer-2-Redundanzmechanismen, sondern auch verlustfreie Ethernet-Kommunikation unterstützen.

FC und FCoE sind aber nicht die einzigen nutzbaren Protokolle für die Kommunikation zwischen Server und Storage. Neben den IP-Protokollen iSCSI und NFS gibt es noch verteilte Storage-Ansätze, die Speicherobjekte auf verschiedene Virtualisierungshosts verteilen. Die Instanz, die für Speichervirtualisierung zuständig ist, unterstützt dabei Hochverfügbarkeit dadurch, dass ein RAID-1-ähnlicher Mechanismus für die Datenreplikation sorgt. Fällt ein physischer Host oder eine Speichereinheit aus, erfolgt eine automatische Umschaltung auf einen anderen Knoten. Die gesamte Speicherkommunikation ist dabei IP-basierend.

Wenn eine Anwendung IP nicht nutzen kann, müssen dafür Layer-2-Verbindungen genutzt werden. Auch wenn dies in der RZ-Infrastruktur nicht notwendig sein sollte, kann es außerhalb von Rechenzentren Nicht-IP-Anwendungen geben. Ein Beispiel ist Building Automation and Control Networks (BACnet). Wenn Komponenten in einem Gebäude nicht die IP-Variante, sondern nur die auf Ethernet basierende Version von BACnet nutzen, benötigen sie Layer-2-Verbindungen.

Layer-2-Verbindungen können auch über Layer-3-Netze vermittelt werden. Das dafür genutzte Verfahren heißt „Tunneling“ bzw. „Encapsulation“. Dabei versieht ein Tunnelende einen Layer-2-Rahmen mit einem IP-Header und sendet ihn zum anderen Tunnelende.

Eine Herausforderung dabei sind Redundanzmechanismen. Diese sind in reinen Layer-3-Netzen in Form von Routing-Mechanismen standardisiert und haben sich bewährt. In Layer-2-Netzen benötigt man eigene Redundanzmechanismen, die im Vergleich zu Layer-3-Mechanismen weniger skalierbar und robust sind. Sie werden mit Layer-2-Tunneling durch Layer-3-Netze auch noch komplexer.

Insofern sollte man jede Anforderung, aus der die Notwendigkeit von Layer-2-Verbindungen resultiert, auf den Prüfstand stellen. Dies gilt insbesondere für Fälle der rein organisatorisch motivierten Bildung von Layer-2-Netzen. Oft stellt es sich heraus, dass eine bestimmte Anwendung auch über ein Layer-3-Netz funktioniert, wenn man sie anders konfiguriert. Natürlich lässt sich ein IP-Endgerät einfacher konfigurieren, wenn man nur die IP-Adresse konfiguriert und durch eine entsprechende Subnetzmaske dafür sorgt, dass die Endgeräte alle direkt miteinander kommunizieren. Dann entfällt eben die Einstellung der Default-Router-Adresse auf dem Endgerät. Aber diese Vereinfachung der Konfiguration an einer Stelle kann Probleme für das gesamte Netz verursachen:

• Kombinierte Layer-3- und Layer-2-Netze sind komplexer als reine Layer-3-Netze.
• Layer-2-Redundanzmechanismen sind in der Regel nicht so robust wie ihre Layer-3-Pendants.
• Layer-2-Netze sind nicht so skalierbar wie IP-Netze.
• Weitere Nachteile können dadurch entstehen, dass im Netz herstellerspezifische Layer-2-Mechanismen zum Einsatz kommen und damit Abhängigkeit von einzelnen Herstellern verursachen.

Die Abwägung von Layer-2- gegen Layer-3-Netze ist im RZ, Campus und Gebäude erforderlich. Deshalb haben wir diese Gegenüberstellung auf die Agenda unseres Netzwerk Kongresses im März 2020 gesetzt.