Konstantin Emelyanov - Fotolia

F

Ersetzen Link-State-Protokolle BGP für Data Center Fabrics?

Laut IETF nutzen immer mehr Betreiber von Data Centern modifizierte Link-State-Protokolle für Data Center Fabrics in Large-Scale-Umgebungen. Was steckt hinter der Entwicklung?

Wenn Sie über das Design von Data Centern auf dem Laufenden sind, wissen Sie sicher, dass die meisten Fabrics in Large-Scale-Infrastrukturen – im Hyperscale- oder Web-Scale-Maßstab – das Border Gateway Protocol (BGP) als primäres Routing-Protokoll für ihre Data Center Fabrics verwenden. Beispiele hierfür sind etwa RFC 7938 und die Beschreibung des Data Center Fabric von LinkedIn. Falls Sie die Hype-Meldungen verfolgen, sind Sie wahrscheinlich überzeugt, dass viele der Netzwerkbetreiber stattdessen ein reines Software-defined Network (SDN) für diese Data Center Fabrics anpeilen.

Stimmt das wirklich? Vier kürzlich von der Internet Engineering Task Force (IETF) veröffentlichte Entwürfe deuten eine andere Entwicklung bei Data Center Fabrics an: der Einsatz modifizierter Link-State-Protokolle für Large-Scale-Architekturen von Data-Center-Netzwerken.

  • Routing in Fat Trees beschreibt eine Reihe von Änderungen für das IS-IS-Routing-Protokoll (Intermediate System to Intermediate System), insbesondere Anpassungen, die bewirken, dass IS-IS mehr wie ein Distanzvektorprotokoll arbeitet und nur eine minimale Menge an Informationen zu den Leaf-Routern (auch Top-of-Rack- oder ToR-Router genannt) in einer Large-Scale Fabric gesendet wird.
  • IS-IS Routing for Spine-Leaf Topology beschreibt mehrere Änderungen am IS-IS-Protokoll, so dass ein Router bekannt geben kann, dass er mit Hosts oder Servern verbunden ist. Mit anderen Worten: Der Advertising Router ist ein ToR-Switch in einem Data Center Fabric. Weiter sieht der Entwurf die Bekanntgabe minimaler Informationen an ToR-Switches vor – speziell einer nur geringen Informationsmenge hinsichtlich der Topologie und eine Standardroute.
  • Openfabric stellt etliche neue Mechanismen vor, durch die ein Router in einem fünfstufigen, oder größeren, Fabric einer Spine-and-Leaf-Architektur seinen Standort innerhalb des Fabrics bestimmen kann, um die automatische Konfiguration zu unterstützen. Darüber hinaus sind einige Flooding-Optimierungen enthalten, die es IS-IS ermöglichen, die Flooding-Last in einer hochgradig vermaschten Large-Scale-Topologie – besonders einer Spine-and-Leaf-Topologie – zu reduzieren.
  • BGP-Shortest Path First beschreibt ein System, das im BGP durch Data Center Fabrics übertragene Link-State-Informationen nutzt, um den besten Pfad durch das Netzwerk zu berechnen, anstatt des sonst standardmäßig verwendeten Best-Path-Algorithmus von BGP.

Was ist an Link-State-Protokollen so besonders?

Warum das plötzliche Interesse der IETF an etwas anderem als BGP- und SDN-Optionen? Der Hauptgrund scheint zu sein, dass Betreiber von Hyperscale- und Web-Scale-Infrastrukturen der Auffassung sind, dass alleiniges SDN nicht der einzige – oder möglicherweise beste – Weg ist, um die Entwicklung in Large-Scale-Umgebungen voranzutreiben. Keiner dieser Betreiber scheint entschlossen, SDN-Technologien komplett aufzugeben. Vielmehr sind sie offenbar daran interessiert, SDN mit traditionelleren Ansätzen zu kombinieren, um eine Art Mischform zu erhalten, die man vielleicht am besten als programmierbares Netzwerk bezeichnen könnte. Dahinter steht die Idee, ein vereinfachtes verteiltes Routing-Protokoll mit einem SDN-artigen Design zu verknüpfen und auf diese Weise zwei sehr unterschiedliche Arten von Problemen zu lösen.

Dabei geht es in beiden Fällen um ein verteiltes Protokoll. Der wichtigste Vorteil eines Link-State-Routing-Protokolls ist seit jeher dessen Fähigkeit, eine vollständige Ansicht der Netzwerktopologie zu erstellen. Zwar kann auch Controller-basiertes SDN eine komplette Ansicht der Netzwerktopologie liefern, doch der Prozess ist weniger dynamisch und wird unter Umständen durch ernsthafte Geschwindigkeitsprobleme bei Skalierung und Konvergenz behindert. Der Einsatz von Link-State-Protokollen für die Erkennung der zugrunde liegenden Topologie nutzt die vorhandenen Protokolle und die bereits gewonnene Erfahrung, um einen Teil der Probleme rund um die Control Plane zu lösen.

Warum nicht natives BGP, ohne Erweiterungen zur Übertragung von Link-State-Informationen? Obwohl BGP sich in vielen Large-Scale-Architekturen von Data-Center-Netzwerken bewährt hat, handelt es sich bei BGP um ein Pfadvektorprotokoll, das nativ keine Informationen über die Fabric-Topologie zur Verfügung stellt – daher die vorgeschlagenen Erweiterungen für die Übermittlung von Link-State-Informationen in BGP sowie der Ansatz, anhand dieser Informationen die kürzesten Pfade durch das Netzwerk zu bestimmen.

Zudem glauben einige Techniker, BGP sei viel zu aufwendig. Es ist ein Protokoll, das dazu ausgelegt ist, mehrere Systeme miteinander zu verbinden, wobei der Schwerpunkt auf Richtlinien statt auf Erreichbarkeit liegt. BGP-Implementierungen umfassen in der Regel Hunderttausende von Codezeilen, tendieren also dazu, äußerst komplex zu sein. Sogar in Data Center Fabrics, die nicht viele dieser Funktionen nutzen, ist der Code immer noch verfügbar und läuft auf Fabric-Routern.

Warum IS-IS?

Drei der oben erwähnten Vorschläge basieren auf IS-IS – Link-State-Protokolle, die in heutigen Data Centern nicht in großem Maßstab verwendet werden. Allerdings lässt sich IS-IS sehr gut ohne Modifizierungen skalieren und arbeitet auch gut mit schlanken Implementierungen zusammen. IS-IS läuft nativ über Ethernet, was die Komplexität der Konfiguration verringert, da selbst für die Link-Local-Adressierung bei Fabric-Übertragungen keine Notwendigkeit besteht.

Bedeuten diese Entwürfe die Abkehr von BGP bei Data Center Fabrics in Large-Scale-Umgebungen? Sie scheinen eher ein Schritt in Richtung Vereinfachung der Control Plane zu sein. Es ist wahrscheinlich, dass ein Protokoll alleine nicht jedes Problem in Large-Scale-Rechenzentren lösen kann. Die aktuelle Entwicklung geht dahin, die Funktionalität unter mehreren einfacheren Protokollen aufzuteilen.

Auch wer außerhalb von Hyperscale- und Web-Scale-Umgebungen arbeitet, sollte diese Entwürfe im Auge behalten. Denn sie könnten verraten, wie es mit den Control Planes von Data Centern in Large-Scale-Architekturen weitergeht. Vielleicht ist dies sogar das eigentliche Ergebnis der Arbeit, die in SDNs geflossen ist.

Folgen Sie SearchNetworking.de auch auf Twitter, Google+, Xing und Facebook!

Nächste Schritte

Netzwerkdesigns für dynamisches Routing

Wird für ein Netzwerk-Virtualisierungs-Overlay eine neue Topologie benötigt?

Essential Guide: Grundlagen zu Software-defined Networking

Artikel wurde zuletzt im Oktober 2017 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Software Defined Networking (SDN)

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchDataCenter.de

SearchEnterpriseSoftware.de

Close