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)
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.
Stand: 08.12.2025
Es ist für uns eine Selbstverständlichkeit, dass wir verantwortungsvoll mit Ihren personenbezogenen Daten umgehen. Sofern wir personenbezogene Daten von Ihnen erheben, verarbeiten wir diese unter Beachtung der geltenden Datenschutzvorschriften. Detaillierte Informationen finden Sie in unserer Datenschutzerklärung.
Einwilligung in die Verwendung von Daten zu Werbezwecken
Ich bin damit einverstanden, dass die Vogel IT-Medien GmbH, Max-Josef-Metzger-Straße 21, 86157 Augsburg, einschließlich aller mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen (im weiteren: Vogel Communications Group) meine E-Mail-Adresse für die Zusendung von Newslettern und Werbung nutzt. Auflistungen der jeweils zugehörigen Unternehmen können hier abgerufen werden.
Der Newsletterinhalt erstreckt sich dabei auf Produkte und Dienstleistungen aller zuvor genannten Unternehmen, darunter beispielsweise Fachzeitschriften und Fachbücher, Veranstaltungen und Messen sowie veranstaltungsbezogene Produkte und Dienstleistungen, Print- und Digital-Mediaangebote und Services wie weitere (redaktionelle) Newsletter, Gewinnspiele, Lead-Kampagnen, Marktforschung im Online- und Offline-Bereich, fachspezifische Webportale und E-Learning-Angebote. Wenn auch meine persönliche Telefonnummer erhoben wurde, darf diese für die Unterbreitung von Angeboten der vorgenannten Produkte und Dienstleistungen der vorgenannten Unternehmen und Marktforschung genutzt werden.
Meine Einwilligung umfasst zudem die Verarbeitung meiner E-Mail-Adresse und Telefonnummer für den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern wie z.B. LinkedIN, Google und Meta. Hierfür darf die Vogel Communications Group die genannten Daten gehasht an Werbepartner übermitteln, die diese Daten dann nutzen, um feststellen zu können, ob ich ebenfalls Mitglied auf den besagten Werbepartnerportalen bin. Die Vogel Communications Group nutzt diese Funktion zu Zwecken des Retargeting (Upselling, Crossselling und Kundenbindung), der Generierung von sog. Lookalike Audiences zur Neukundengewinnung und als Ausschlussgrundlage für laufende Werbekampagnen. Weitere Informationen kann ich dem Abschnitt „Datenabgleich zu Marketingzwecken“ in der Datenschutzerklärung entnehmen.
Falls ich im Internet auf Portalen der Vogel Communications Group einschließlich deren mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen geschützte Inhalte abrufe, muss ich mich mit weiteren Daten für den Zugang zu diesen Inhalten registrieren. Im Gegenzug für diesen gebührenlosen Zugang zu redaktionellen Inhalten dürfen meine Daten im Sinne dieser Einwilligung für die hier genannten Zwecke verwendet werden. Dies gilt nicht für den Datenabgleich zu Marketingzwecken.
Recht auf Widerruf
Mir ist bewusst, dass ich diese Einwilligung jederzeit für die Zukunft widerrufen kann. Durch meinen Widerruf wird die Rechtmäßigkeit der aufgrund meiner Einwilligung bis zum Widerruf erfolgten Verarbeitung nicht berührt. Um meinen Widerruf zu erklären, kann ich als eine Möglichkeit das unter https://contact.vogel.de abrufbare Kontaktformular nutzen. Sofern ich einzelne von mir abonnierte Newsletter nicht mehr erhalten möchte, kann ich darüber hinaus auch den am Ende eines Newsletters eingebundenen Abmeldelink anklicken. Weitere Informationen zu meinem Widerrufsrecht und dessen Ausübung sowie zu den Folgen meines Widerrufs finde ich in der Datenschutzerklärung.
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.