Ausgabe Januar 2023

Auch wenn die Diskussion über die Vor- und Nachteile von Layer-2-Ethernet-Verbindungen zwischen verschiedenen Rechenzentren (RZ) nicht neu ist, flammt sie in Projekten immer wieder auf. Wer diese Diskussion für erledigt hält, wird bei Einbindung in ein Vorhaben für RZ-Standort-Redundanz eines Besseren belehrt. Wie schon seit 20 Jahren wird in solchen Fällen oft darüber gestritten, ob Hochverfügbarkeit für Cluster, deren Knoten auf verschiedene RZ verteilt sind, Layer-2-Netze erfordert, die sich über die verschiedenen RZ-Standorte erstrecken. Da immer mehr Organisationen Standort-Redundanz für Rechenzentren realisieren müssen, wird die Frage in unserer Projektarbeit immer wieder auf die Agenda gesetzt. Was ist der Stand dazu?

Cloud-Betreiber machen es vor: Es geht auch ohne

Wer sich mit Infrastructure as a Service (IaaS) in großen Public Clouds näher beschäftigt hat, weiß, dass die von Betreibern solcher Clouds bereitgestellten IP-Subnetze in der Regel auf eine Availability Zone (AZ), d.h. auf einen RZ-Standort, begrenzt sind. Sieht eine Architektur vor, dass bei Ausfall einer AZ in einer anderen AZ Ressourcen für eine hochverfügbar ausgelegte Anwendung genutzt werden müssen, geht der Wechsel von einer zur anderen AZ mit dem Wechsel der IP-Adressen der genutzten Instanzen einher. Je nach Architektur ist sogar ein Wechsel von einer zur anderen Cloud-Region denkbar. Oft wird dazu das Domain Name System (DNS) so konfiguriert, dass darüber die Abbildung desselben Fully-Qualified Domain Name (FQDN) zu IP-Adressen in verschiedenen Cloud-Rechenzentren möglich ist.

Warum wird dennoch Layer 2 gefordert?

Trotz der bekannten Cloud-Erfahrungen ticken die Uhren in OnPrem-Rechenzentren anders. Um das zu verstehen, muss man einen Blick auf die historische Entwicklung der in Rechenzentren für Hochverfügbarkeit genutzten Mechanismen werfen.

Als sich vor ca. 20 Jahren die Kombination aus Ethernet und dem Internet Protocol (IP) in den meisten Rechenzentren durchsetzte, wurde die Kombination aus dem Transmission Control Protocol (TCP) und IP zur Basis der meisten Datenanwendungen. Der TCP/IP-Protokoll-Stack wurde in den 1970er Jahren so konzipiert, dass Anwendungen direkt auf TCP aufsetzten. Die Schnittstelle dafür heißt Socket. Über einen Socket ist ein Prozess auf einer Maschine erreichbar. Die Socket-Adresse besteht aus der IP-Adresse der Maschine und einer Portnummer, meistens TCP-Portnummer.

Somit wurden viele Client-Server-Anwendungen in der IP-Welt so konzipiert, dass der Client über die Kombination aus IP-Adresse und Portnummer die Anwendung auf dem Server erreichte. Die Erreichbarkeit der Server-IP-Adresse war somit für die Anwendung essenziell.

Daher wurden viele Hochverfügbarkeitsmechanismen für Server so konzipiert, dass ein Cluster aus mehreren Servern unabhängig von der Verfügbarkeit einzelner Server-Maschinen immer über eine Virtuelle IP-Adresse (VIP oder VIPA) erreichbar war, sobald mindestens ein Knoten des Clusters funktionierte. In den 1990er Jahren entstanden die Cluster-Architekturen unter Unix und Windows, die so arbeiteten. Später kam die nach demselben Modell konzipierte Hochverfügbarkeit (High Availability, HA) in virtualisierten Serverumgebungen, insbesondere von VMware, hinzu.

Nutzt man nun die in den 1990ern entwickelten HA-Mechanismen für Server-Cluster auch für die Realisierung von RZ-Standortredundanz, braucht man eine Netzumgebung, in der dieselbe virtuelle IP-Adresse von einem zum anderen RZ verlagert werden kann.

Auch in anderen Bereichen wie bei Firewalls, Load-Balancern und DNS/DHCP-Servern wurden Designs mit virtuellen IP-Adressen entwickelt, die von einer Maschine zur anderen wechseln können. Selbst First Hop Redundancy (FHR) bei Routern nutzt oft eine solche virtuelle IP-Adresse. Cisco machte in den 1990ern mit HSRP (Hot Standby Router Protocol) den Anfang. Andere Netzhersteller übernahmen mit Virtual Router Redundancy Protocol (VRRP) dasselbe Konzept.

So war die Vorgabe an viele Designer und Betreiber von RZ-Netzen klar: IP-Subnetze und die ihnen zugrunde liegenden Layer-2-Segmente wurden RZ-übergreifend gemacht, damit Cluster-Mechanismen für Server, Storage, Firewalls, Load Balancer etc. auch RZ-übergreifend funktionierten.

Nachteile von Layer 2

Die Protokollschicht, die als Layer 2 bekannt ist, wurde für wörtlich zu nehmende lokale Netze konzipiert. Das bekannteste Beispiel ist Ethernet, in dem Adressen der Schicht Medium Access Control (MAC) genutzt werden. Anders als der IP-Adressraum ist der MAC-Adressraum flach, d.h. die Zusammenfassung von Geräten zu Subnetzen, wie bei IP üblich, ist mit MAC-Adressen nicht möglich. MAC-Adressen werden häufig einem Stück Hardware zugeordnet. So arbeiten Ethernet-Switches mit MAC-Adresstabellen, die mittels „Learning“ gefüllt werden. Empfängt ein Switch auf einem Port einen Ethernet Frame, trägt der Switch die Sender-MAC-Adresse in dem Frame in seine Adresstabelle ein und ordnet die Adresse dem betreffenden Port zu. Frames, in dessen Empfänger-Feld diese Adresse erscheint, können so gezielt zum passenden Port weitergeleitet werden. Empfängt der Switch einen Frame, dessen Ziel-MAC-Adresse unbekannt ist, wird der Frame an alle Ports weitergeleitet, d.h. „geflutet“. Gleiches gilt für Broadcasts und Multicasts. Das Verfahren heißt deshalb „Flooding and Learning“.

Flooding und Learning ist nicht beliebig skalierbar. Auch wenn in den drei Jahrzehnten seit der Erfindung von Ethernet Bridges (die standardisierte Bezeichnung von Layer-2-Switches) die Switch-Hardware um Größenordnungen leistungsfähiger geworden ist, sind die Größe der Adresstabellen und auch die Suchgeschwindigkeit in solchen Tabellen endlich.

Hinzu kommt, dass die Flutung sowohl die Switches als auch die angeschlossenen Endgeräte wesentlich stärker belastet als die gezielte Weiterleitung von einem zu genau einem anderen Port. Ferner kann in einem flachen Layer-2-Netz jedes Gerät eine IP-Adresse aus dem diesem Netz zugeordneten IP-Subnetz „an sich reißen“, was Tür und Tor sowohl für Manipulation als auch für Störungen durch gedoppelte IP-Adressen öffnet.

Auch First Hop Redundancy auf Basis virtueller IP-Adressen hat ihre Tücken. Die aktive Routing-Instanz, welche die virtuelle IP-Adresse bedient, ist zur selben Zeit in der Regel einem Gerät zugeordnet. Befindet sich dieses Gerät aus der Sicht eines Endgeräts im entfernten Rechenzentrum, müssen alle an andere Netze gerichteten Pakete zunächst zum Remote-RZ gesendet werden.

Einige nicht gerade als optimal zu bezeichnende Redundanzmechanismen für Layer-2-Netze taten ihr Übriges, um in solchen Netzen Probleme zu verursachen. Bekanntestes Beispiel hierfür ist das Spanning Tree Protocol (STP), das nicht sehr skalierbar und robust ist. So setzen viele Netzbetreiber auf Alternativen zu STP, insbesondere Multi-Chassis Link Aggregation (MC-LAG). Doch auch MC-LAG ist angesichts des damit verbundenen Konfigurationsaufwands begrenzt skalierbar.

Lösen Overlays alle Probleme?

Um den mit klassischen Layer-2-Netzen verbundenen Problemen aus dem Weg zu gehen und gleichzeitig die Bildung von Layer-2-Strukturen zum Beispiel für RZ-Standortredundanz zu ermöglichen, setzen die meisten führenden Switch-Hersteller auf sogenannte Overlays. Ein Overlay ist ein logisches Netz, meistens realisiert mittels Encapsulation. Das Paket wird mit einem zweiten Header versehen, z.B. einem IP-Header. So kann ein Layer-2-Overlay auf Basis eines IP-Netzes gebildet werden. Das Encapsulation-Format kann VXLAN sein, wie von den meisten Switch-Herstellern unterstützt, oder auch GENEVE, wie bei VMware NSX.

Die Konfiguration von Overlays ist nicht trivial, selbst wenn es weitgehend automatisiert wird, wie es mit einer intelligenten (zentralen oder verteilten) Control Plane (Steuerungsebene) möglich ist. Overlays machen die Netze nicht gerade einfacher. Ferner handelt es sich bei der Overlay-Bildung um die Verlagerung der Probleme von der physischen in die logische Welt. Der Layer-2-Adressraum bleibt flach, und das Layer-2-Switching bleibt chaotisch. Hinzu kommt, dass mit Ausnahme von Ethernet Virtual Private Network (EVPN) und Shortest Path Bridging (SPB) alle Control Planes für Overlay-Bildung proprietär sind. Selbst EVPN und SPB werden in der Regel nur in homogenen Umgebungen mit Komponenten desselben Herstellers genutzt.

Nachteile der Begrenzung jedes IP-Subnetzes auf nur ein RZ

Trotz der Nachteile und Herausforderungen, die mit Layer 2 zwischen verschiedenen Rechenzentren einhergehen, ist in vielen RZ-Verbund-Netzen genau das im Einsatz. Der Grund ist, dass bei Ausfall eines RZ-Standorts ein anderer dessen Funktionen übernehmen soll, ohne dass ein manuelles Eingreifen erforderlich wird. Ohne Layer-2-Verbindungen zwischen den Rechenzentren geht der Ausfall eines Standorts damit einher, dass die diesem Standort und ausschließlich diesem Standort zugewiesenen IP-Subnetze nicht mehr erreichbar sind. Folglich können etablierte Umschaltmechanismen wie zum Beispiel VMware vSphere HA nicht genutzt werden. Eine virtuelle Maschine (VM), die im verbliebenen RZ die Funktion einer VM im ausgefallenen RZ übernehmen soll, muss einerseits mit dem Data Store der nicht mehr verfügbaren VM verbunden werden und andererseits möglichst unter dem DNS-Namen der ausgefallenen VM erreichbar sein. Ersteres bedeutet Arbeit für die Server- und Storage-Administratoren, Letzteres Arbeit für die DNS-Verantwortlichen. Eine Automatisierung dieser Arbeitsschritte ist prinzipiell möglich, erfordert jedoch eine sorgfältige Planung und unter Umständen auch Tools wie Load Balancer, die nicht für jede Applikation funktionieren.

Fazit

Um auf die Frage im Titel dieses Beitrags zurückzukommen: Ob man zwischen Rechenzentren Layer-2-Verbindungen braucht, hängt von mehreren Faktoren ab. Dazu zählen sowohl Architekturmerkmale von Applikationen als auch das Know-how, die Tool-Ausstattung, die Präferenzen und die Organisation der involvierten Gruppen, d.h. der Teams für Server, Storage, Virtualisierung, Netz, Firewalls, Load Balancer und Netzdienste wie DNS.