Mobile-Menu

Definition Was ist eine Spine-Leaf-Architektur?

Aktualisiert am 02.07.2026 Von Dipl.-Ing. (FH) Stefan Luber 5 min Lesedauer

Anbieter zum Thema

Die Spine-Leaf-Architektur kommt in modernen Rechenzentren zum Einsatz und besteht aus zwei Switching-Ebenen mit Spine- und Leaf-Switches. Sie stellt eine Alternative zu klassischen dreistufigen Netzwerkarchitekturen mit Core-, Aggregation- (Distribution-) und Access-Ebene dar. In der Spine-Leaf-Architektur sind die Leaf-Switches mit den Spine-Switches vollvermascht.

In einem Netzwerk mit Spine-Leaf-Architektur gibt es zwei Switching-Ebenen. Die Leaf-Switches sind mit allen Spine-Switches verbunden.(Bild:  ChatGPT / KI-generiert)
In einem Netzwerk mit Spine-Leaf-Architektur gibt es zwei Switching-Ebenen. Die Leaf-Switches sind mit allen Spine-Switches verbunden.
(Bild: ChatGPT / KI-generiert)

Die Spine-Leaf-Architektur ist eine Netzwerkarchitektur für moderne Rechenzentren, die eine hohe Skalierbarkeit, Leistung und Ausfallsicherheit bietet und als De-facto-Standard klassische dreistufige Modelle (Core, Aggregation bzw. Distribution und Access) weitgehend abgelöst hat. Sie besteht mit der Leaf- und der Spine-Ebene aus nur zwei Ebenen und bietet gegenüber klassischen dreistufigen Modellen zahlreiche Vorteile.

Die Switches der Leaf-Ebene bilden die Zugangsebene beziehungsweise den Access-Layer des Netzwerks. An ihnen sind beispielsweise die Server, Datenspeicher und andere Endsysteme angeschlossen. Die Spine-Switches zeichnen sich durch eine hohe Switching-Leistung aus und bilden das Hochgeschwindigkeits-Core-Netzwerk. An den Spine-Switches selbst sind keine Access-Systeme angeschlossen. Sie sind für das schnelle Switching der Daten zwischen den Leaf-Switches zuständig und mit diesen vollvermascht. Jeder Leaf-Switch besitzt eine Verbindung zu jedem Spine-Switch. Dadurch ist sichergestellt, dass bei der Kommunikation zwischen zwei Endpunkten maximal ein Spine-Switch involviert ist. Sind beide Endpunkte am gleichen Leaf-Switch angeschlossen, bleibt der Verkehr vollständig innerhalb der Leaf-Ebene. Direkte Verbindungen zwischen Leaf-Switches oder zwischen Spine-Switches existieren normalerweise nicht.

Spezielle Leaf-Switches können zusätzlich die Rolle eines Border-Leaf- oder eines Edge-Leaf-Switches annehmen. Diese stellen beispielsweise Verbindungen zu externen Netzwerken oder dem Internet her.

Die Kommunikation in einer Spine-Leaf-Architektur läuft üblicherweise folgendermaßen ab: Sendet ein Server Daten an einen anderen Server, werden diese zunächst an den lokalen Leaf-Switch übertragen. Von dort gelangen sie über einen Spine-Switch zum Ziel-Leaf-Switch und schließlich zum Zielsystem. Da alle Verbindungen gleichwertig sind, benötigen Datenpakete in der Regel stets die gleiche Anzahl von Netzwerk-Hops. Das sorgt für vorhersehbare Latenzen und eine gleichmäßige Lastverteilung.

Grundsätzlich sind Spine-Leaf-Architekturen auf dem Layer 2 (Switching) und Layer 3 (Routing) realisierbar. Die Links zwischen der Spine- und der Leaf-Ebene können daher geroutet oder geswitcht sein. Im Gegensatz zu einfachen Spanning-Tree-Topologien in reinen Layer-2-Netzen, in denen einzelne Verbindungen zur Vermeidung von Netzwerkschleifen keine Daten übertragen und sich in einem logischen Blocking-Status befinden, sind in der Spine-Leaf-Architektur alle Verbindungen weiterleitend. Der Spanning-Tree-Algorithmus ist in der Regel durch andere Algorithmen wie das Shortest Path Bridging (SPB) ersetzt.

Ein weiterer Layer-2-Algorithmus, der in Spine-Leaf-Architekturen zum Einsatz kommen kann, ist TRILL (Transparent Interconnection of Lots of Links). Beide Protokolle sorgen in geswitchten Umgebungen dafür, dass die Endpunkte schleifenfrei auf dem jeweils kürzesten Weg erreichbar sind. Sie verwenden für die Wegberechnung zum Beispiel den SPF-Algorithmus (Shortest Path First). Das Spanning-Tree-Protokoll ist für die Spine-Leaf-Architektur und für hochskalierende Fabrics ineffizient, da es grundsätzlich keine parallelen Pfade berücksichtigen kann. Algorithmen wie TRILL und SPB ermöglichen eine intelligente Wegfindung und sorgen für die benötigte Performance. Sowohl TRILL als auch SPB können im Gegensatz zum Spanning-Tree-Protokoll Multipfade und eine größere Anzahl von Netzknoten bedienen. SPB ist im IEEE-Standard 802.1aq und TRILL in den RFCs 6325 und 6326 definiert.

Moderne Spine-Leaf-Netze nutzen aber in der Regel L3-Routing oder EVPN-Overlay-Techniken (Ethernet Virtual Private Network) und routen jeden Link. Hierfür kommen Routing-Protokolle der Schicht 3 wie OSPF (Open Shortest Path First), IS-IS (Intermediate System to Intermediate System) oder BGP (Border Gateway Protocol) zum Einsatz. Sie finden ebenfalls den kürzesten Weg zum Ziel und verhindern die Bildung von Routing-Schleifen. Dieser Ansatz ist sinnvoll, wenn ein Netzwerk-Overlay oder eine Netzwerkvirtualisierungstechnologie wie VXLAN (Virtual eXtensible Local Area Network) verwendet wird. In den L3-basierten Spine-Leaf-Fabrics erfolgt die Lastverteilung typischerweise über Equal-Cost Multi-Path (ECMP).

Warum die Spine-Leaf-Architektur die klassische dreistufige Ebenenarchitektur größtenteils abgelöst hat

Lange Zeit dominierten in Rechenzentren Netzwerktopologien mit Core-, Aggregation- (Distribution-) und Access-Ebene. Access-Switches stellten die Verbindungen zu den Servern her und die Aggregation- oder Distribution-Switches die redundanten Verbindungen zu den Access-Switches. Core-Switches sorgten für den schnellen Transport zwischen den Aggregation-Switches.

In heutigen Rechenzentren ist man aber zunehmend zur Spine-Leaf-Architektur übergegangen. Ein wichtiger Treiber für diese Entwicklung ist die Veränderung der Datenflüsse in modernen Rechenzentren. Dominierte früher so genannter Nord-Süd-Verkehr, bei dem die Daten überwiegend zwischen Client-Systemen und den Servern ausgetauscht wurden und von externen Systemen ins Rechenzentrum und wieder zurück flossen, ist heute sehr viel Querverkehr, also Ost-West-Verkehr, zu beobachten. Die Daten fließen beispielsweise aufgrund zunehmender Virtualisierung und der Verbreitung von Cloud- und Container-Infrastrukturen auf internen Rechenzentrumsverbindungen von einem Serversystem zu einem anderen Serversystem. Das lässt sich dadurch erklären, dass moderne cloudnative, virtualisierte oder containerisierte Anwendungen auf mehrere Server oder virtuelle Maschinen verteilte Funktionskomponenten besitzen.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu Netzwerktechnik, IP-Kommunikation und UCC

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

In klassischen dreistufigen Architekturen entstehen bei einem hohen Anteil an Querverkehr schnell Engpässe. Die Anzahl der Hops und der an der Kommunikation beteiligten Switches und damit auch die Latenzzeiten steigen signifikant. Ost-West-Verkehr erfordert für eine optimale Leistung aber Verkehrsflüsse mit geringer Latenz. Diese Anforderung erfüllt die Spine-Leaf-Architektur wesentlich besser. Sie kommt mit Ost-West-Verkehr besser zurecht und begrenzt die Anzahl der Hops. Der Datenverkehr zwischen den Serversystemen fließt immer über die gleiche Anzahl an Switches, was die Latenzzeiten vorhersehbar macht.

Darüber hinaus verbessert sich auch die Übertragungskapazität des Netzwerks, da keine Protokolle wie STP mit deaktivierten Links mehr erforderlich sind und Datenverkehr gleichmäßig über redundante Pfade zwischen den Switches verteilt werden kann.

Auch hinsichtlich der Skalierbarkeit und der Ausfallsicherheit ergeben sich bei einer Spine-Leaf-Architektur Vorteile. Zur Erhöhung der Kapazität können einfach zusätzliche Spine-Switches hinzugefügt und mit jedem Leaf-Switch verbunden werden. Die Anzahl der Leaf-Switches lässt sich so nahtlos erweitern, ohne dass komplexe Umstrukturierungen des Netzwerks und dadurch verursachte Ausfallzeiten damit verbunden sind. Allerdings ist die Architektur nur bis zu einer gewissen Größe gut skalierbar. Die Anzahl der benötigten Verbindungen wächst mit der Anzahl an Switches. Wird beispielsweise nur ein einzelner Spine-Switch hinzugefügt, muss auf jedem Leaf-Switch ein neuer Link zu diesem bereitgestellt werden.

Ein weiterer Vorteil dieser Architektur ist die hohe Redundanz. Fällt eine Verbindung oder ein Spine-Switch aus, stehen weitere Möglichkeiten zur Verfügung, das gewünschte Ziel zu erreichen. Intelligente Link- oder Routing-Protokolle sorgen dafür, dass die jeweils kürzeste, schleifenfreie Verbindung automatisch berechnet und schnell bereitgestellt werden kann.

Mögliche Nachteile und Herausforderungen von Spine-Leaf-Architekturen

Den zahlreichen Vorteilen der Spine-Leaf-Architektur stehen auch einige Nachteile und Herausforderungen gegenüber, wie:

  • höhere technische und betriebliche Komplexität
  • Notwendigkeit einer sorgfältigen Planung der Portkapazitäten
  • Bedarf an fortgeschrittenem Fachwissen für Routing-Protokolle und Overlay-Netzwerke
  • Bedarf an leistungsfähigen Management-Tools
  • hohe Anzahl notwendiger Kabelverbindungen aufgrund der Vollvermaschung
  • zunehmender Aufwand der Verkabelung und Dokumentation
  • Begrenzung der Skalierbarkeit durch die begrenzte Portanzahl der Switches und der möglichen Anzahl an Inter-Switch-Links

Typische Einsatzbereiche von Spine-Leaf-Architekturen

Typische Einsatzbereiche von Spine-Leaf-Architekturen sind Anwendungsfälle mit hohen internen Datenströmen und viel Ost-West-Datenverkehr, für die eine Hochgeschwindigkeitsdatenübertragung mit vorhersehbarer Leistung erforderlich ist. Solche Anforderungen bestehen beispielsweise in hyperkonvergenten Infrastrukturen, in Cloud-Infrastrukturen, in High-Performance-Computing-Umgebungen, in virtualisierten Rechenzentrumsumgebungen oder bei containerisierten Microservices und KI- oder ML-Workloads.

(ID:45280575)