Was ist ein Aktiv-Aktiv Rechenzentrum und wieso brauche ich ein solches?
Viele Organisationen haben mehrere Rechenzentren, die sie für Lastenteilung (Load Sharing) und Notfallvorsorge (Disaster Recovery) verwenden. Dabei stehen zwei unterschiedliche Setups zur Auswahl: Aktiv/Backup und Aktiv/Aktiv. Bei einem Aktiv/Backup-Setup wird nur eines der Rechenzentren aktiv genutzt, während das andere als betriebsbereiter Ersatz (Warm Standby) oder als verfügbarer aber noch nicht betriebsbereiter Ersatz (Cold Standby) dient. Bei einem Aktiv/Aktiv-Setup können alle Rechenzentren gleichzeitig aktiv sein.
Eine weitere Möglichkeit ist eine hybride Architektur, bei der ein Subset der Arbeitslast in jedem der Rechenzentren abgearbeitet wird, aber keine der Arbeitslasten in mehreren Rechenzentren gleichzeitig. Aus der Perspektive der Arbeitslast sind die Rechenzentren Aktiv/Backup konfiguriert, aber alle voll ausgenutzt. Ein solches Setup vereinfacht die Applikationsarchitektur oder die Anforderungen an die Infrastruktur.
Was ist VXLAN und was ist EVPN? Sind die beiden Technologien unabhängig voneinander oder werden sie immer in Kombination verwendet?
Bei VXLAN handelt es sich um eine einfache Enkapsulierung der Ethernet-Datenebene (Data Plane) über IP, die es ermöglicht, Ethernet-Datenverkehr über IP-Netzwerke zu transportieren. Es wird gewöhnlich verwendet, um in grossen Rechenzentren und in privaten und öffentlichen Clouds Overlays für virtuelle Netzwerke zu implementieren.
EVPN ist eine Kontrollebene (Control Plane) für Layer 2- und Layer 3-Netzwerke. Sie ist ähnlich der gutbekannten MPLS/VPN-Kontrollebene, verfügt aber zusätzlich noch über Unterstützung für Layer 2 (MAC-Adressen) und Layer 3 (IPv4- und IPv6-Adressen und Prefixes). EVPN versucht Kontrollebenen-Protokolle zu vereinen und ermöglicht dies in der Praxis umzusetzen.
Welche Vorteile bietet EVPN, die bei Verwendung von einem nativen Ethernet-Netzwerk ohne zusätzlichem VXLAN-Overlay nicht zur Verfügung stehen?
Bei herkömmlichen Ethernet-Lösungen bestehen zwei Herausforderungen. Die erste ist die Stabilität, welche u.a. durch das Spanning Tree Protocol beeinträchtigt werden kann. Die zweite ist die Skalierbarkeit, da jeder Switch jede MAC-Adresse im Netzwerk kennen und sehen können muss.
Gleich wie VPLS, PBB, TRILL, SPB etc verbessert VXLAN die Skalierbarkeit von Ethernet, da die MAC-Adressen der Kunden im Kerntransportnetzwerk (Transport Core Network) nicht sichtbar sind.
Im Vergleich zu den meisten anderen Lösungen erhöht VXLAN auch die Netzwerkstabilität, da das Kerntransportnetzwerk durchgetestete IP Transport- und IP-Routingprotokolle verwendet.
EVPN ist dabei das "Tüpfelchen auf dem i": Es verbessert die Bereitstellung von VXLAN- oder MPLS-Diensten, indem es das in traditionellen Ethernet-Netzwerken verwendete dynamische Lernen von MAC-Adressen durch ein deterministisches Kontrollebenen-Protokoll – BGP – ersetzt. Das Border Gateway Protocol (BGP) ist auch im globalen Internet das weitverbreitetste und deshalb auch das am meisten getestete.
Was sind die Limitationen und Nachteile der Verwendung von VXLAN und EVPN?
Die Implementierung von VXLAN in Hardware ist immer noch deutlich teurer als die Implementierung von einfachem Ethernet-Switching oder 802.1ad (Q-in-Q). Hardware, die VXLAN unterstützt ist deshalb teurer als einfachere Switches.
Bei EVPN handelt es sich um ein komplexes Kontrollebenen-Protokoll, das auf BGP basiert. Es benötigt eine gut funktionierende Netzwerkunterlage für den IP Transport. Deshalb ist es schwieriger zu verstehen und zu implementieren als einfachere VLAN-basierende Lösungen.
Welche Anbieter haben VXLAN und EVPN im Angebot? Sind die Implementierungen voll interoperabel?
eder einzelne Anbieter von Switches für Rechenzentren (darunter Arista, Cisco, Cumulus, Extreme, und Juniper) haben ihre in der Vergangenheit mit Eigenlob überschütteten proprietären Lösungen aufgegeben (darunter FabricPath, DFA, VCS Fabric, IRF…) und VXLAN-Enkapsulierung in Kombination mit einer EVPN-Kontrollebene implementiert.
Unglücklicherweise gibt es für EVPN viele Optionen und die Anbieter implementierten unterschiedliche Untermengen dieser Optionen. Das Resultat ist das SIP der virtuellen Netzwerke. Wie bei SIP und den Interoperabilitätsproblemen zwischen verschiedenen VoIP-Produkten verschiedener Anbieter gibt es auch bei EVPN massive Interoperabilitätsprobleme. Die Anbieter behaupten zwar, dass ihre Produkte interoperabel sind. Sie nehmen auch an Testanlässen teil, um das zu beweisen. In der Realität der Praxis zeigen sich aber immer noch viele Wege wie es schieflaufen kann. Zum Beispiel können sich die Anbieter selbst bei einfachen Dingen wie der einheitlichen Wahl des Routing Protokolls für das darunterliegende Netzwerk (Underlay Network) und der einheitlichen Verwendung von BGP im übergelagerten Netzwerk (Overlay Network) nicht einigen. Jeder Anbieter verwendet und vermarktet einen leicht unterschiedlichen Ansatz, was für Netzwerkarchitekten ein Albtraum ist.
Ist die Implementierung unkompliziert oder kann etwas schieflaufen?
Wir kombinieren ein schwierig zu lösendes Problem (Bridging in massivem Umfang) mit einem komplexen Protokoll (BGP), das oft mit einer Code-Basis implementiert wird, die für einen anderen Bereich entwickelt wurde, nämlich Internet Routing mit BGP oder MPLS/VPN. Die Anzahl der Dinge, die da schieflaufen kann ist nahezu unüberschaubar. Dazu tragen auch subtile Hardwareprobleme und Software-Bugs bei. Akzentuiert wird das, wenn man versucht eine Architektur zu verwenden, die nicht dem entspricht, was der Anbieter glaubt der einzig richtige Weg zu sein.
Was sind die wichtigsten Dinge, die man beachten muss, wenn man eine Rechenzentrumslösung mit VXLAN und EVPN implementieren will?
Wie immer sollte man mit den wichtigen einfachen Fragen beginnen:
- Welches Problem versuche ich zu lösen?
- Muss ich es wirklich lösen, oder würde die Umgestaltung eines anderen Teils des Systems (z.B. die Applikationsarchitektur) ein besseres Gesamtresultat ergeben?
- Welche Möglichkeiten stehen zur Lösung des Problems zur Verfügung?
Angenommen Sie müssen ein umfangreiches virtuelles Ethernet-Netzwerk bauen, das sich über eines oder mehrere Rechenzentren erstreckt, so könnte VXLAN besser sein als die Alternativen.
Als nächstes gilt es herauszufinden, ob man VXLAN in Hardware (auf Top-of-Rack (Tor) Switches, der Ansatz den Anbieter von Switches für Rechenzentren verwendet wird) implementieren will, oder in Software (in Hypervisors, der Ansatz, der von VMware, Microsoft, Juniper Contrail, vielen OpenStack-Implementierungen und den meisten grossen Public Cloud-Anbietern verwendet wird). Dieses Dilemma war Thema des letztjährigen Workshops «VMware NSX, Cisco ACI or EVPN».
Stellt sich heraus, dass VXLAN am besten in Hardware implementiert wird – beispielsweise aufgrund einer grösseren Anzahl nicht-virtualisierter Server – so muss man sich entscheiden ob es nicht besser ist, statische, eventuell mit einfacher Automation erweiterte Konfigurationen zu verwenden, oder ob man EVPN verwendet.
Man sollte dabei immer im Kopf behalten, dass bei EVPN Interoperabilität eine grosse Herausforderung ist. Die Verwendung von Produkten unterschiedlicher Anbieter innerhalb einer Fabric ist keine gute Idee. Oft ist es besser, kleinere Pods (eigenständige Einheiten von Rechenkapazität, Speicher und Virtualisierung) zu erstellen und diese mit traditionellen Technologien wie IP Routing oder VLANs zu verbinden.
Zum Schluss, aber eminent wichtig: Obwohl EVPN Kontrollebene in Kombination mit VXLAN fortlaufend stabiler wird, ist es noch keine solide, äusserst zuverlässige Technologie. Deshalb ist ausgiebiges Testen Pflicht.
Dieses Interview wurde am 30. November 2018 auf Inside-IT publiziert. Die englische Version ist auf Ivan Pepelnjak's Blog auf IPspace.net zu finden.