MLAG & Netzredundanz für eine Fabric ohne Ausfallzeit

In jeder Infrastruktur lauert eine leise Frage: Was passiert, wenn etwas kaputtgeht? Nicht ob, sondern wann. Irgendwann braucht ein Switch ein Firmware-Update, ein Netzteil fällt aus, ein Transceiver verstummt, jemand stolpert über ein Kabel. Das Kennzeichen eines gut entworfenen Rechenzentrumsnetzes ist nicht, dass solche Ereignisse nie eintreten — sondern dass niemand sie bemerkt, wenn sie eintreten.

Netzredundanz ist die Disziplin, Single Points of Failure zu beseitigen, damit die Fabric auch beim Ausfall einzelner Komponenten weiterleitet. An der Access-Schicht, wo Server auf das Netz treffen, ist die zentrale Technik dafür MLAG — Multi-Chassis Link Aggregation. Dieser Beitrag erklärt, wie MLAG funktioniert, wie es mit einer redundanten Fabric zusammenspielt und was tatsächlich überlebt, wenn ein Switch ausfällt.

Der Single Point of Failure, den man sich nicht leisten kann

Betrachten Sie die einfachste denkbare Serveranbindung: eine NIC, ein Kabel, ein Switch. Sie funktioniert tadellos — bis dieser Switch für ein Update neu startet und jeder daran hängende Server gleichzeitig offline geht. Für eine Private Cloud mit Dutzenden virtuellen Maschinen pro Host kann der Ausfall eines einzelnen Top-of-Rack-Switches ein ganzes Rack voller Workloads lahmlegen. Das ist nicht hypothetisch; das ist ein Wartungsfenster am Dienstag, das schiefgelaufen ist.

Der erste Reflex ist, einen zweiten Switch und ein zweites Kabel zu ergänzen. Doch verbindet man einen Server naiv mit zwei Switches, entsteht eine Schleife, und klassische Layer-2-Netze beantworten Schleifen mit Spanning Tree, das eine der beiden Verbindungen blockiert. Man erhält Redundanz, die bis zum Ausfall ungenutzt bleibt, verschwendet die Hälfte der Access-Bandbreite und erbt die langsame Rekonvergenz von Spanning Tree. MLAG existiert, um Ihnen den zweiten Switch ohne diesen Kompromiss zu geben.

Was MLAG tatsächlich tut

MLAG lässt zwei physische Switches gegenüber einem nachgelagerten Gerät auftreten, als wären sie ein einziger logischer Switch. Ein Server verbindet je eine Leitung zu jedem der beiden Switches und bündelt sie zu einer logischen Schnittstelle (einem LAG bzw. Port-Channel). Aus Sicht des Servers gibt es nur eine gebündelte Verbindung mit der kombinierten Geschwindigkeit beider Leitungen. Aus Sicht des Netzes sind beide Leitungen gleichzeitig aktiv und leiten weiter — es gibt kein blockiertes Standby.

Die beiden Switches koordinieren sich über eine dedizierte Verbindung, meist Peer-Link oder Inter-Switch-Link genannt, samt eines Keepalive-Pfads, über den jeder Partner erkennt, ob der andere noch lebt. Sie synchronisieren ihre MAC-Adresstabellen und den ARP-Zustand, sodass Verkehr unabhängig davon, auf welchem Switch er eintrifft, korrekt weitergeleitet wird. Der Server weiß nicht und braucht nicht zu wissen, dass zwei eigenständige Geräte beteiligt sind — und genau das ist der Sinn.

Dual-Homed-Server in der Praxis

Dieses Muster — ein Server mit je einer Leitung zu zwei Top-of-Rack-Switches — heißt Dual-Homing und ist das Fundament einer ausfallsicheren Access-Schicht. Die beiden Switches bilden ein MLAG-Paar; jeder Server im Rack bündelt über beide. Das Bündel lässt sich aktiv-aktiv konfigurieren (per LACP), sodass im Normalbetrieb beide Leitungen Verkehr tragen — das verdoppelt die nutzbare Bandbreite, während die Redundanz praktisch kostenlos ist. Sie bezahlen kein untätiges Backup; Sie nutzen alles, was Sie gekauft haben, und die Reservekapazität wird erst zur Reserve, wenn etwas ausfällt.

Ein Durchgang durch die Ausfallszenarien

Theorie beruhigt; entscheidend ist das Verhalten im Fehlerfall. Gehen wir die Ereignisse durch, die in einem dual-homed, MLAG-geschützten Rack wirklich passieren.

Ein Switch startet für ein Update neu

Sie müssen die Firmware eines der beiden Top-of-Rack-Switches patchen. Während er heruntergeht, erkennt das Bündel jedes Servers, dass eine seiner beiden Leitungen weg ist, und verlagert den gesamten Verkehr auf die verbleibende Leitung — typischerweise innerhalb von Millisekunden, weit schneller als jede Spanning-Tree-Rekonvergenz. Der Durchsatz pro Server sinkt auf den einer einzelnen Leitung, doch die Verbindung bricht nie ab. Der Switch startet neu, tritt dem MLAG-Paar wieder bei, synchronisiert den Zustand, und die Bündel gleichen sich neu aus. Keine VM hat ein relevantes Paket verloren; kein Workload ging offline. Genau dieses Szenario rechtfertigt das gesamte Design.

Ein einzelnes Kabel oder ein Transceiver fällt aus

Der Ausfall einer einzelnen Leitung ist der sanfteste Fall. Das Bündel läuft schlicht auf seinem verbleibenden Mitglied weiter, und ein Alarm wird ausgelöst, damit eine Technikerin den defekten Transceiver in Ruhe tauschen kann. Der Wirkungsbereich ist die Bandbreite einer Leitung auf einem Server — ohne Ausfallzeit.

Der Peer-Link selbst fällt aus

Der heiklere Fall ist der Verlust der Verbindung zwischen den beiden MLAG-Partnern, während beide Switches noch leben. Schlecht behandelt droht ein Split-Brain, bei dem beide Switches glauben, das Sagen zu haben. Deshalb ist der Keepalive-Pfad wichtig: Er erlaubt den Partnern, einen toten Partner von einem durchtrennten Peer-Link zu unterscheiden. Ein gut umgesetztes MLAG nutzt dieses Signal, um einen Partner maßgeblich zu halten und die verwaisten Ports am anderen abzuschalten, sodass doppelter oder geschleifter Verkehr vermieden wird. Es ist das Szenario, das man vor dem Go-live testen muss, nicht danach.

Redundanz bis hinauf in die Fabric

MLAG schützt den Access-Rand, doch Ausfallsicherheit muss sich durch das gesamte Netz ziehen. In einer Spine-Leaf-Fabric ist die Redundanz oberhalb der Leaves strukturell: Jeder Leaf ist mit mehreren Spines verbunden, und Equal-Cost-Multipath-Routing verteilt den Verkehr über alle. Fällt ein Spine aus, konvergiert das Routing in Sekundenbruchteilen über die übrigen, ohne dass ein Server betroffen ist. Die Leaves liefern also Intra-Rack-Redundanz per MLAG, und die Spine-Schicht liefert Inter-Rack-Redundanz per ECMP. Zusammen bedeutet das: Es gibt kein einzelnes Gerät, dessen Ausfall das Netz teilen könnte.

Strom und Verkabelung verdienen dieselbe Sorgfalt. Doppelte Netzteile aus unabhängigen Einspeisungen, die beiden Mitglieder eines MLAG-Paars an getrennten Stromkreisen und diversitäre Kabelwege stellen sicher, dass ein Fehler vor dem Switch die sorgfältig eingebaute Redundanz nicht zunichtemacht. Redundanz ist nur so stark wie ihre am wenigsten redundante Abhängigkeit.

Für das Wartungsfenster entwerfen

Der eigentliche Gewinn dieser Architektur ist betriebliche Freiheit. Wenn man jeden einzelnen Switch ohne Ausfallzeit neu starten kann, hört Patchen auf, ein gefürchtetes Ereignis zu später Stunde zu sein, und wird Routine. Man aktualisiert einen Partner, prüft die Gesundheit und aktualisiert dann den anderen. Die Kapazitätsplanung sollte das berücksichtigen: Dimensionieren Sie die Fabric so, dass der Betrieb auf N-1 Geräten während der Wartung den Produktionsverkehr bequem trägt, denn für einen Teil jedes Updates läuft man bewusst degradiert. Ein Design, das seine Ziele nur erreicht, wenn alles läuft, ist nicht wirklich hochverfügbar.

Null Ausfallzeit in Reichweite bringen

Netzwerke ohne Ausfallzeit sind keine Magie; sie sind das kumulierte Ergebnis davon, auf jeder Ebene Single Points of Failure zu beseitigen — dual-homed Server, gebündelt über ein MLAG-Paar, mehrere Spines per ECMP verknüpft, redundanter Strom und die betriebliche Disziplin, diese Redundanz auch zu nutzen. Gut gemacht, leitet das Netz durch Switch-Neustarts, defekte Transceiver und tote Netzteile hindurch weiter, und die Workloads darüber spüren nichts.

Fabrics mit dieser Art von Ausfallsicherheit zu entwerfen, gehört zum Kern unserer Arbeit bei clouditiv. Als autorisierter Arista-Networks-Reseller bauen wir Leaf-Spine-Netze mit MLAG-geschütztem Access und redundanten Spines unter souveränen, OpenStack-basierten Private Clouds, sodass geplante Wartung und ungeplante Ausfälle gleichermaßen für die Plattform unsichtbar bleiben. Das Ziel ist leicht gesagt und schwer zu konstruieren: ein Netz, in dem die Antwort auf die Frage, was passiert, wenn etwas kaputtgeht, zuverlässig lautet — nichts, was Sie bemerken werden.