Spine-Leaf vs. 3-Tier: Welches Rechenzentrumsnetz gewinnt?

Zwei Jahrzehnte lang war das kanonische Bild eines Rechenzentrumsnetzes eine Pyramide. Server hängten unten an Access-Switches, diese führten in der Mitte zu Aggregations-Switches, und ganz oben band ein Paar Core-Switches alles zusammen. Dieses Drei-Schichten-Modell war sinnvoll, gut verstanden und passte zu den Verkehrsmustern seiner Zeit. Dann änderten sich die Workloads, und die Pyramide begann zu ächzen.

Heute werden die meisten neuen Rechenzentren stattdessen als Spine-Leaf-Fabric gebaut. Die Frage für alle, die Infrastruktur planen oder erneuern, lautet nicht mehr, ob Spine-Leaf modern ist — das ist es offensichtlich —, sondern ob es für die eigenen Workloads wirklich gewinnt und wo das ältere Modell noch seinen Platz hat. Dieser Beitrag vergleicht beide direkt entlang der Dimensionen, die wirklich zählen: Latenz, Skalierbarkeit, Ausfallsicherheit und Kosten.

Wie das Drei-Schichten-Modell funktioniert

Das klassische Design staffelt drei Ebenen. Die Access-Schicht verbindet Server. Die Aggregations- oder Distributionsschicht bündelt diese Access-Switches und erzwingt meist die Layer-2/Layer-3-Grenzen, die Sicherheitsrichtlinien und das VLAN-Routing. Die Core-Schicht stellt den Hochgeschwindigkeitstransit zwischen den Aggregationsblöcken und nach draußen bereit. Redundanz entsteht durch paarweise Geräte und Querverbindungen, und das Spanning Tree Protocol hält die dadurch entstehenden Schleifen in Schach, indem es redundante Pfade blockiert.

Genau dieses letzte Detail ist die Achillesferse des Modells. Um schleifenfrei zu bleiben, deaktiviert Spanning Tree Verbindungen, die sonst Verkehr tragen könnten. Man kauft zwei Uplinks und nutzt einen. Schlimmer noch: Verkehr zwischen zwei Servern an unterschiedlichen Access-Switches muss häufig zur Aggregations- oder Core-Schicht hinauf und wieder hinunter — mehrere Hops, von denen jeder Latenz hinzufügt und teure Core-Bandbreite verbraucht.

Wie Spine-Leaf funktioniert

Spine-Leaf flacht die Pyramide auf zwei Schichten ab. Jeder Leaf-Switch (an dem Server hängen) ist mit jedem Spine-Switch verbunden, und die Spines verbinden sich mit nichts außer Leaves. Es gibt keine direkte Leaf-zu-Leaf- oder Spine-zu-Spine-Verbindung. Die Folge ist einfach, aber wirkungsvoll: Jeder Server ist von jedem anderen Server genau zwei Hops entfernt — hinauf zu einem Spine und hinunter zu einem Leaf —, egal wo in der Fabric er sitzt.

Weil jeder Leaf einen Pfad zu jedem Spine hat, sind alle Uplinks gleichzeitig aktiv. Equal-Cost-Multipath-Routing verteilt den Verkehr darauf, statt redundante Verbindungen zu blockieren. Spanning Tree verschwindet aus dem Kern des Designs und wird durch ein geroutetes Underlay (meist BGP) mit einem darüberliegenden EVPN/VXLAN-Overlay für Mandantennetze ersetzt. Die Fabric verhält sich weniger wie ein Baum und mehr wie ein gleichförmiges, vorhersehbares Geflecht.

Latenz und das Ost-West-Problem

Der wichtigste Grund für den Wandel ist die geänderte Verkehrsrichtung. In der Drei-Schichten-Ära war der meiste Verkehr Nord-Süd: Nutzer, die Server erreichen. Moderne Workloads werden von Ost-West-Verkehr dominiert — Server, die mit Servern sprechen. Microservices rufen sich ständig gegenseitig auf, verteilte Datenbanken replizieren, Storage-Cluster gleichen sich neu aus, und virtuelle Maschinen migrieren live zwischen Hosts.

In einem Drei-Schichten-Netz kann Ost-West-Verkehr zwischen weit entfernten Access-Switches fünf oder mehr Hops durchlaufen und an überbuchten Aggregations-Links zum Engpass werden. Bei Spine-Leaf sind es für denselben Verkehr stets zwei Hops mit konstanter, vorhersehbarer Latenz. Für latenzempfindliche Workloads — etwa ein Datenbank-Cluster, der über Racks hinweg synchronisiert, oder ein Ceph-Storage-Pool beim Rebalancing — ist diese Konstanz kein Luxus, sondern der Unterschied zwischen erfüllten und verfehlten Leistungszielen.

Skalierbarkeit: wachsen ohne Komplettumbau

Die beiden Modelle skalieren sehr unterschiedlich. Ein Drei-Schichten-Netz zu erweitern bedeutet oft, den Core aufzurüsten, weil der gesamte Verkehr zwischen den Blöcken durch ihn fließt. Core-Upgrades sind teuer, störend und kommen meist als ein großes, riskantes Projekt.

Spine-Leaf skaliert horizontal. Mehr Serverports nötig? Einen Leaf hinzufügen. Mehr Bandbreite zwischen den Leaves? Einen Spine hinzufügen — und weil jeder Leaf mit jedem Spine verbunden ist, verteilt sich die neue Kapazität gleichmäßig über die gesamte Fabric. Wachstum wird zu einer Folge kleiner, schrittweiser, risikoarmer Erweiterungen statt eines periodischen Komplettumbaus. Die praktische Obergrenze ist die Portzahl der Spines, und mit modernen Switches hoher Dichte liegt diese Grenze hoch genug für sehr große Deployments — und lässt sich bei echtem Bedarf mit einer Super-Spine-Ebene weiter anheben.

Ausfallsicherheit und Fehlerverhalten

Bei der Ausfallsicherheit wird der Unterschied greifbar. In einem Spanning-Tree-Netz löst eine Topologieänderung — eine ausgefallene Verbindung, ein neu gestarteter Switch — eine Rekonvergenz aus, die Sekunden dauern kann und während der Verkehr pausieren kann. Und weil manche Verbindungen per Design blockiert sind, läuft man mit weniger nutzbarer Kapazität, als man bezahlt hat.

In einer Spine-Leaf-Fabric entfernt der Ausfall eines Spines in einem Design mit vier Spines etwa ein Viertel der Bandbreite zwischen den Leaves — und sonst nichts; das Routing konvergiert einfach in deutlich unter einer Sekunde über die verbleibenden Spines, und kein Server verliert die Verbindung. Es gibt keinen Single Point of Failure, der das Netz kippen könnte, und jede Verbindung verdient ihren Platz. Für eine Plattform, die Hochverfügbarkeit liefern soll, ist dieses sanfte Degradieren genau das gewünschte Verhalten.

Wo Drei-Schichten weiterhin sinnvoll ist

All das heißt nicht, dass Drei-Schichten überall überholt ist. Für ein kleines Büronetz, einen Campus mit überwiegend Nord-Süd-Verkehr oder eine Umgebung mit überschaubarer, statischer Serverzahl kann ein klassisches Design völlig ausreichen und günstiger aufzubauen sein. Spine-Leaf bringt eine gewisse Grundkomplexität mit — man betreibt ein Routing-Protokoll und ein Overlay —, die sich erst auszahlt, wenn Skalierung, Ost-West-Verkehr oder strenge Verfügbarkeitsziele sie rechtfertigen. Die ehrliche Antwort lautet: Die richtige Topologie hängt vom Verkehr ab, nicht von der Mode.

Eine kurze Entscheidungshilfe

Wählen Sie Spine-Leaf, wenn Ost-West-Verkehr dominiert, wenn Sie Wachstum erwarten, wenn Sie Mandantenisolation brauchen oder wenn Ausfallzeit wirklich teuer ist — also für nahezu jede Private Cloud oder Virtualisierungsplattform. Tendieren Sie zu Drei-Schichten, wenn die Umgebung klein und stabil ist, der Verkehr überwiegend Nord-Süd fließt und betriebliche Einfachheit über Skalierbarkeit steht. Viele Organisationen betreiben beides: Spine-Leaf im Rechenzentrum, ein einfacheres Design am Campus-Rand.

Das Fazit für die Private Cloud

Für die Workloads, die eine moderne Private Cloud ausmachen — virtuelle Maschinen, Container, verteilter Storage und das ständige Ost-West-Geplauder zwischen ihnen — gewinnt Spine-Leaf klar. Die vorhersehbare Zwei-Hop-Latenz, die horizontale Skalierbarkeit und das sanfte Fehlerverhalten decken sich nahezu perfekt mit dem, was eine Virtualisierungsplattform von ihrem Netz verlangt. Das Drei-Schichten-Modell wurde für eine andere Verkehrsära gebaut, und das merkt man.

Deshalb werden On-Premise-Private-Clouds auf Leaf-Spine-Fabrics statt auf altgedienten Hierarchien gebaut. Bei clouditiv setzen wir auf Arista-Leaf-Spine-Netze, gerade weil die Topologie Mandanten-Workloads konstante Leistung gibt und Kapazität Switch für Switch wachsen lässt. Eine Netzwerkarchitektur zu wählen heißt, die Decke und den Boden für alles festzulegen, was darauf aufbaut — und für die Private Cloud hebt Spine-Leaf die Decke an und hält den Boden stabil.