© choreograph, 123RF

Große Umgebungen wie Clouds stellen Anforderungen an das Netzwerk, die mit Lösungen auf Basis des Layer 2 nicht zu erfüllen sind. BGP springt im Layer 3 ein und sorgt für nahtlos skalierbare Netzwerke.

Große Virtualisierungs-Umgebungen haben die typischen kleinen Setups aus wenigen physischen Systemen verdrängt. Wo eine Firma früher ein paar physische Server angeschafft hatte, um eine Anwendung aufzusetzen, da landet heute der gesamte Workload neuer Setups in virtuellen Maschinen, die auf der Plattform eines Cloudanbieters laufen.

Nicht zuletzt ist für den Kunden die Time-to-Market für neue Setups in virtuellen Umgebungen viel kürzer: Das Bestellen von Hardware, das lästige Warten auf die Lieferung und den Einbau sowie die Zeit für die Inbetriebnahme entfallen. Auch für den Betreiber der Cloud ergeben sich daraus viele Vorteile: Virtualisierungs-Umgebungen wie Public Clouds sind deutlich uniformer als eine Vielzahl von Einzelsetups und lassen sich effizienter verwalten. Auch das Skalieren in die Breite gestaltet sich leichter, weil sich diese Plattformen fast nach Belieben erweitern lassen.

Die Änderungen wirken sich auch auf die Planung der IT-Umgebung aus. Früher entwarf man einzelne Setups, baute sie auf und betrieb sie, bis eine neue Lösung die alte ersetzte. Massiv skalierbare Umgebungen sind hingegen nicht nur auf die nächsten fünf Jahre ausgelegt, die Planung dafür reicht deutlich weiter in die Zukunft.

Hinzu kommt der Faktor Größe: Eine Cloudumgebung beginnt meist als Basis-Setup und wächst kontinuierlich, wenn der entsprechende Bedarf auf Nutzer-Seite vorhanden ist. Bei der Planung einer Public Cloud kennt der Planer die Zielgröße nicht und muss entsprechend umsichtig vorgehen. Unterläuft einem Unternehmen hier ein Fehler, hat das im Alltag später womöglich fatale Konsequenzen. Mit beträchtlichem Aufwand muss das Unternehmen dann Workarounds bauen, um die Fehler im Design der Lösung zu umschiffen.

Erinnert sei an die im Internet kursierende Grafik, die die Kosten für das Umgehen von Designfehlern in den verschiedenen Lebensphasen eines Setups beschreibt (Abbildung 1): Wird das Designproblem noch in der Designphase erkannt und beseitigt, halten sich die Mehrkosten in Grenzen. Fällt der Fehler erst auf, wenn die Plattform im produktiven Betrieb ist, multiplizieren sich die verursachten Kosten.

Abbildung 1: Je früher ein Designfehler beim Planen einer Plattform auffällt, desto billiger ist seine Korrektur.

Werkzeugkasten

Software-seitig steht Admins mittlerweile ein stattlicher Werkzeugkoffer zur Verfügung, um große Umgebungen zu bauen. Clouds wie Open Stack oder Container-basierte Lösungen wie Kubernetes sind gleich ab Werk auf Skalierbarkeit eingestellt. Hardware von der Stange, die ab Werk nicht direkt auf das Skalieren in die Breite ausgelegt ist, wird durch Software in vielen Fällen trotzdem in ein Scale-out-Setup integriert: Ceph etwa macht aus gewöhnlichen Servern skalierbare Objektspeicher, die zusammen problemlos eine Kapazität im Petabyte-Bereich bereitstellen können.

Beim Skalieren gibt es allerdings eine ganz besondere Herausforderung: das Netzwerk. Clouds wie Open Stack stellen an das logische Netz in der Umgebung wie auch an das physische Netz auf der Hardware-Seite Bedingungen, die mit konventionellen Netzwerk-Designs kaum lösbar sind. Während sich für die logischen Netzwerke Software Defined Networking (SDN) in mehreren Spielarten längst schon durchgesetzt hat, drückt auf der physischen Ebene der Schuh gewaltig – aus mehreren Gründen.

Konventionelle Baumstruktur

Übliche Netzwerk-Layouts funktionieren in massiv skalierenden Umgebungen nicht. Die Gründe sind schnell erläutert: Plant ein Unternehmen das Netzwerk für ein klassisches Einzelsetup, ist die maximale Zielgröße bekannt und liegt meist bei einer überschaubaren Anzahl an Servern. Dabei kommt oft ein Layout auf Basis einer Baumstruktur zum Einsatz (Abbildung 2): An einem oder zwei zentralen Switches schließt der Admin alle Server an – oder weitere Switches, falls die Anzahl der Ports eines Switch nicht ausreicht. Zusammen ergeben die Switches und die Netzwerkkarten in den Servern ein großes, physisches Segment auf der OSI-Ebene 2 (Layer 2).

Abbildung 2: Klassische Netzwerk-Architekturen folgen einer Baumstruktur. Für Scale-out-Plattformen eignet sich dieser Ansatz aber nicht.

Falls noch mehr Ports benötigt werden, setzt sich die Switch-Kaskade auf den darunterliegenden Switch-Ebenen fort, was aber Nachteile mit sich bringt. Einerseits bekommt es der Admin früher oder später mit dem Spanning Tree Protocol (STP) zu tun – manch leidgeprüfter Netzwerker kann ein Lied davon singen. Andererseits kommt bei den letzten Gliedern einer solchen Kaskade nur noch ein Bruchteil der Performance an, die der Hauptswitch eigentlich liefern könnte.

In massiv skalierbaren Umgebungen fällt die zentrale Grundannahme weg, die das Fundament für den beschriebenen Baumansatz darstellt – hier ist nämlich die Zielgröße völlig unklar. Ein neuer Kunde könnte ad hoc 600 virtuelle Maschinen starten wollen. Je nach Konfiguration heißt das für den Anbieter, dass er praktisch über Nacht Dutzende Server ins Rack bringen muss, weil der Kunde sich sonst eben bei Amazon, Microsoft oder Google einmietet.

Die Gesamtzahl benötigter Ports ist für den Planer des Setups mithin keine feste Größe, mit der er rechnen kann. Wenn mit einem Male Dutzende Server ihren Weg ins Rechenzentrum finden, muss die Netzwerk-Infrastruktur im gleichen Maß mitwachsen. Mit baumartigen Setups und Switch-Kaskaden ist das nicht zu machen.

Überdies gerät der Admin noch aus einer anderen Ecke unter Beschuss: Es ist keineswegs sicher, dass er drei Jahre nach dem ursprünglichen Setup die gleiche Netzwerk-Hardware noch kaufen kann, auf die er anfangs gesetzt hat. Selbst bei Geräten desselben Herstellers ist auch nicht garantiert, dass spätere Modelle mit ihren Vorgängern wirklich kompatibel sind. Ausführliche Tests sind in solchen Scale-out-Fällen also genauso notwendig wie in den Fällen, in denen der Admin betagte Netzwerk-Hardware durch neue, potentere Teile austauscht.

Muss er bei einem späteren Scale-out aus irgendwelchen Gründen auf die Geräte anderer Hersteller setzen, droht der Super-GAU: Zwar sind alle relevanten Protokolle in Sachen Netzwerk eigentlich komplett standardisiert. Aber wer je versucht hat, Jumbo-Frames mit Geräten von unterschiedlichen Herstellern zu kombinieren, der weiß: Das Schöne an Standards ist, dass es so viele davon gibt.

Was tun?

Auf den Punkt gebracht stellt sich dem Admin die Frage, wie er sein Netz so konstruiert, dass es auch in zehn oder mehr Jahren noch in die Breite skalieren kann – dabei aber trotzdem nicht unwartbar wird. Beinahe automatisch kommt einem das Bild vom Wald in den Sinn, den man vor lauter Bäumen nicht sieht. Denn die Konstruktion riesiger Computernetzwerke ist ja eigentlich ein gelöstes Problem, die notwendige Technik existiert seit Jahrzehnten. Das Internet ist schließlich auch nur ein riesiges zusammenhängendes Netz, das sich in etliche physische Segmente aufteilt.

Was liegt also näher, als die bereits vorhandene Technik auf das lokale Netz sinngemäß anzuwenden? Dieser Artikel beschreibt, wie Admins mit den Hilfsmitteln des Layer 3 ein fast beliebig skalierbares Netzwerk für ihre Umgebung konstruieren, das auch in ferner Zukunft alle Anforderungen erfüllt. Er basiert zum Teil auf der technischen Arbeit großer Firmen wie Google und Facebook, die schon vor Jahren entsprechende Designkonzepte umsetzten. Dorther kommt auch der Name für solche Netzwerk-Layouts: IP Fabrics.

Layer-3-Basics

Die Unterschiede in Planung und Umsetzung sind zwischen reinen Layer-2-Netzen und Layer-3-Netzen gewaltig. Zunächst geht eine zentrale Grundannahme über Bord, die für L2-Netze essenziell ist. Dort beruht das Netzwerk auf der Annahme, dass jeder Host Mitglied desselben Netzwerksegments ist. Die direkte Verbindung zwischen zwei Hosts geschieht in der Layer-2-Welt mit Hilfe von ARP. Ein Netzwerkdesign auf Basis des Layer 3 ist dagegen nicht mehr darauf angewiesen, dass sich alle Server im selben physischen Netzwerksegment befinden. Eine Kernfunktion von Layer 3 ist das Routing.

Solange es irgendeinen physischen Kommunikationspfad zwischen zwei Hosts gibt, funktioniert die Kommunikation über den Layer 3. Und zwar auch dann, wenn sich die betroffenen Hosts in unterschiedlichen Layer-2-Segmenten befinden. Das Border Gateway Protocol (BGP) & Co. machen es möglich. Allerdings: Im direkten Vergleich mit Layer-2-Netzwerken bedingt das IP-Fabrics-Prinzip zusätzliche Komponenten an diversen Stellen des Setups. Wofür sind diese gut? Ein Blick unter die Haube hilft, die Details von IP Fabrics zu verstehen – der Bedarf an zusätzlichen Werkzeugen im Setup ergibt sich dann fast automatisch.

Die Details

Klar ist: Auch ein Netzwerk auf Layer-3-Basis nutzt den Layer 2, doch geht es von anderen Grundvoraussetzungen aus. Ein Host kann im Rahmen eines Netzwerks grundsätzlich mit unterschiedlichen Zielen sprechen: Einerseits kann er die Server, die im selben Netzwerksegment liegen, direkt erreichen. Zwei Server am selben Switch finden sich per ARP und tauschen dann die gewünschte Kommunikation aus. Will ein Host mit einem Server außerhalb seines Netzwerksegments kommunizieren, geht das nur über den Layer 3 des OSI-Modells: IPv4 ist das gängigste Beispiel.

Die Kommunikationsquelle kennt ihre eigene IP-Adresse sowie die Adresse eines anderen Servers im selben Netz, der ihre Pakete an den Zielrechner weiterleitet (Gateway). IP Fabrics, die auf Basis von OSI-Layer 3 funktionieren, machen sich genau diese Eigenschaft zu Nutze: Hier ist die Grundannahme einfach, dass jeder andere Host nur über ein Gateway zu erreichen ist. Die Kommunikation mit anderen Servern geht in einem solchen Setup also über ein Gateway.

Damit das Prinzip funktioniert, muss jeder Server wissen, wie er die anderen Server des Setups erreicht. Hier kommt BGP ins Spiel: Jeder Host, der Bestandteil von IP Fabrics ist, gibt per BGP-Protokoll bekannt, über welche Routen er zu erreichen ist. Auch die verbauten Switches spielen eine wichtige Rolle: Sie bilden das BGP-Gegenstück zu den einzelnen Servern und verteilen die von diesen erlernten Routen über das gesamte Setup. So ist jeder Host der Installation in der Lage, mit jedem anderen Host über den OSI-Layer 3 und die Switches als Gateways zu kommunizieren. Pakete, die an Server außerhalb des Setups gerichtet sind – etwa Internet-Traffic –, gehen über ebenfalls per BGP erlernte Routen den Weg über externe Gateways.

Für IP Fabric sind also drei Komponenten nötig: Ein externes Gateway für die Kommunikation mit der Außenwelt, ein schlauer Switch sowie ein ebenso schlauer Knoten, der seine Routing-Informationen per BGP preisgibt. Weil BGP ein standardisiertes Protokoll ist, lässt sich ein solches Setup auf viele Weisen mit unterschiedlichen Komponenten bauen. Das folgende Beispiel ist eine Möglichkeit der Umsetzung – konkrete Hardwarebeispiele folgen später.

Die Konfiguration der Hosts

Entscheidend für IP Fabrics ist zunächst, dass jeder einzelne Host des Setups BGP beherrscht, de facto also selbst zum Router wird. BGP basiert auf der Idee von Routing-Announcements: Über ein solches Announcement gibt ein Host im BGP-Protokoll an, welche Zielnetzwerke über ihn zu erreichen sind.

Damit das klappt, müssen für jeden teilnehmenden Host zumindest ein lokales Netzwerk sowie eine lokale IP-Adresse definiert sein, die über dieses lokale Netz erreichbar ist – das ist die IP-Adresse, über die andere Hosts später mit dem jeweiligen Server kommunizieren. Im Fachjargon hat sich für jene Netze, die meist nur vier IP-Adressen haben (Subnetzmaske »/30«) und den lokalen IPv4-Adressräumen entnommen sind, die Bezeichnung Transfernetz (Transfer Network) etabliert.

Die Ziel-IP – streng genommen auch ein eigenes Netzwerk mit einer IP-Adresse, also der Subnetzmaske »/32« – liegt auf irgendeiner Netzwerk-Schnittstelle des Servers, etwa auf der Loopback-Schnittstelle »lo«. Der Server verkündet per BGP, dass das Netzwerk mit der Ziel-IP über das beschriebene Transfernetz zu erreichen ist. Dabei hat der Admin die Wahl zwischen zwei BGP-Lösungen, die sich flächendeckend für Linux durchgesetzt haben: das Urgestein Quagga [1] oder das leichtfüßigere Bird ([2], Abbildung 3). Auf welche der beiden Lösungen ein Admin setzt, ist nicht zuletzt eine Frage des persönlichen Geschmacks. Sowohl Quagga als auch Bird lassen sich mit den gängigen Automatisierungslösungen problemlos ausrollen.

Abbildung 3: Bird ist eine leichtgewichtige Alternative zu Quagga.

Die Architektur der Dienste unterscheidet sich aber deutlich: Quagga besteht aus mehreren Komponenten und einer interaktiven BGP-Shell, mit der sich direkt Befehle an den Dienst senden lassen. Bird bietet zwar auch ein CLI-Werkzeug, um eine laufende Instanz des Dienstes abzufragen (»birdrc«), ist in Summe jedoch deutlich weniger komplex. Für IP Fabrics eignen sich beide Dienste, weil dabei nur die absoluten BGP-Basiskommandos zum Einsatz kommen. Wer bisher mit keinem der beiden Dienste gearbeitet hat, findet mit Bird aber wohl den schnelleren Einstieg.

Redundanz spielt in einem solchen Setup eine große Rolle – und sie ist mit BGP problemlos zu realisieren. Denn die Anzahl der Transfernetze pro Host ist nicht beschränkt: Pro physischem Netzwerkport definiert der Admin im besten Fall ein solches Transfernetz. Der Server verkündet dann per BGP genau so viele Pfade zur Ziel-IP in das Netzwerk, wie konfigurierte Ports vorhanden sind. Das ist schlau und effizient, dank dieses Setups lassen sich nämlich die Netzwerk-Interfacekarten (NICs) ohne Einschränkung gleichzeitig nutzen, wenn sie funktionieren. Geht eine NIC kaputt, entfällt automatisch das BGP-Announcement des jeweiligen Pfades – es bleibt nur der andere, noch funktionierende Pfad übrig.

Mit Hilfe des Switch

Wie beschrieben basiert BGP auf dem Prinzip, dass Router über eben jenes Protokoll Routing-Informationen über die Hosts im Netzwerk austauschen. Damit das dargestellte Schema in der Praxis funktioniert, ist also auch die tatkräftige Mithilfe des Switch notwendig: Er muss selbst BGP sprechen, außerdem dient er den Hosts als Peering-Partner für das BGP-Protokoll.

Ihm kommen im Setup zwei zentrale Funktionen zu: Einerseits sammelt er die eingehenden BGP-Announcements der mit ihm verbundenen Server und pflegt eine zentrale Routingtabelle, die er allen anderen Routern des Netzes – Hosts wie anderen Switches – bereitstellt. Andererseits dient der Switch als echter Router: Die einzelnen Hosts senden Pakete an die Adresse, die sie vom BGP-Gateway kennen und die in diesem Fall quasi das Default-Gateway ist. Dafür ist die zweite nutzbare IP-Adresse des Transfernetzes gut, die auf dem Switch für den jeweiligen Port konfiguriert ist. Der Switch ändert für diese Pakete anhand der Routing-Informationen die Ziel-MAC-Adresse, reduziert ihre TTL um 1 und leitet sie zum Zielrechner weiter.

Eine Sonderrolle nimmt externer Traffic ein, im konkreten Fall also jener, der nicht an eines der lokalen Transfernetze gerichtet ist. Den leiten die Switches per BGP direkt an eigens für diesen Zweck betriebene Gateways weiter – die deshalb auch Border-Gateways heißen. Anders als in einer klassischen Baumarchitektur kann es von diesen in der IP Fabrics beliebig viele geben. Ihren Weg finden die Pakete letztlich aufgrund der Routing-Informationen aus BGP und nicht auf Basis des vorhandenen L2-Netzes.

Was für Border-Gateways gilt, gilt übrigens auch für die Anzahl von Switches im Setup: An jeden existierenden Switch lassen sich jederzeit zusätzliche Switches anschließen, die sich danach nahtlos in das bestehende BGP-Setup integrieren. Das wäre zwar unorthodox, aber technisch ohne Nachteile möglich. Die Praxis sieht in der Regel anders aus: Im Folgenden geht der Artikel deshalb auf Best Practices ein und gibt dabei auch konkrete Beispiele für nutzbare Hardware.

Top of Rack, Core, Leaf, Spine

Alternative Begriffe für IP-Fabrics-Designs, wie das hier vorgestellte, gibt es viele: Hersteller reden gerne von einer Leaf-Spine-Architektur oder von Top-of-Rack-Switches und Core-Switches. Gemeint ist fast immer dasselbe: Gut geplant lassen sich mit IP Fabrics deutlich größere Portzahlen sowie echte Skalierbarkeit erreichen. Dabei hat es sich eingebürgert, zunächst jedem Rack einen eigenen Switch zu spendieren. Oft werden diese ganz oben im Rack montiert, daher die Bezeichnung “Top of Rack”.

Die Kreuzverkabelung mehrerer Racks bietet sich an: Bei zwei nebeneinanderstehenden Racks, die jeweils einen Mellanox SN2410-Switch (48 mal 25-GBit/s-Thernet) haben, könnte man etwa die Server in den Racks einerseits mit dem ToR-Switch im selben Rack und außerdem mit dem ToR-Switch im Rack nebenan verbinden, um Redundanz zu erreichen. Wenn die 48 Ports dafür nicht reichen, lassen sich auch mehrere dieser Geräte verbauen.

Für die Switch-Ebene darüber braucht es potentere Hardware: Hier kommt der Mellanox SN2700 in Frage, der 32 echte 100-GBit/s-Ethernet-Ports bietet (Abbildung 4) – die sich über Break-out-Kabel auch noch aufteilen lassen. Indem der Admin die ToR-Switches aus verschiedenen Racks mit einem oder mehreren Core-Switches dieses Modells verbindet, versorgt er die einzelnen Racks mit starken Uplinks. Die Core-Switches sind schließlich auch jene, die direkt mit den Core-Routern hin zum Internet verbunden werden und so externe Konnektivität ermöglichen.

Abbildung 4: Der Mellanox SN2700 bietet 32 echte 100-GBit/s-Ethernet-Ports und eignet sich als Core-Switch, mit dem sich viele Top-of-Rack-Switches verbinden.

Ein so geplantes Setup ist maximal flexibel: Zusätzliche Racks lassen sich an die bestehenden Core-Switches jederzeit anbinden. Gehen bei diesen die Ports aus, kann der Admin auch einen zusätzlichen Core-Switch hinzufügen. Wer will, kann im laufenden Betrieb auch eine dritte Switch-Ebene einziehen: Gerade vor dem Hintergrund der in absehbarer Zeit verfügbaren 200-GBit/s-Ethernet-Switches könnte das eine lohnenswerte Alternative sein. Fest steht: Solange irgendeine physische Verbindung von einem neuen Switch hin zum existierenden Switchnetz verfügbar ist, lassen sich neue Switches ohne Querelen dazustecken.

Und das sogar ohne Downtime: Wird etwa ein Switch kurzzeitig abgeschaltet, damit ihn ein stärkeres Modell ersetzen kann, dann bleiben die übrigen BGP-Routen davon unberührt und das Netz funktioniert weiter normal. Auch das Hinzufügen zusätzlicher Switch-Ebenen geschieht im laufenden Betrieb, ohne dass ein Wartungsfenster nötig wäre.

Tricky Bit: Die Switches

Dass der Artikel gleich zweimal Switches der Spectrum-Serie von Mellanox erwähnt, ist übrigens kein Zufall. Denn die haben ein Feature, das im IP-Fabrics-Kontext besonders relevant ist: Auf ihnen lässt sich Cumulus Linux betreiben, also eine Spezialversion von Debian GNU/Linux, die für den Betrieb auf Netzwerkgeräten besonders angepasst ist.

Mit allen angenehmen Vorteilen: Wer auf den Hosts BGP per Quagga oder Bird realisiert, kann das auf Cumulus-Switches genauso handhaben (Abbildung 5). Quagga gehört zum Lieferumfang, Bird lässt sich per »apt-get« nachinstallieren, wobei der Hersteller für diese Komponente den Support jedoch verweigert. Und so lassen sich die Switches dank Debian auch nahtlos in eine vorhandene Automatisierungslösung integrieren: Der Switch bekommt dabei seine Konfiguration genauso etwa per Ansible wie die anderen Hosts des Setups.

Abbildung 5: Cumulus auf Switches bringt viele Vorteile: Hier hantiert der Admin mit einem echten Linux, auf dem etwa jeder Port ein eigenes Interface ist.

Freilich lässt sich ein IP-Fabrics-Setup wie das beschriebene auch mit der Netzwerk-Hardware anderer Hersteller und ohne Cumulus-Linux aufbauen. Bei Cisco und Juniper, den Platzhirschen der Branche, ist der Wunsch, aus den Switches der Firma Router zu machen, ebenfalls angekommen. Beide Betriebssysteme, NX-OS sowie Junos OS, bieten entsprechende Features. Für die wird aber meist eine teure Zusatzlizenz fällig. Hinzu kommt, dass sich NX-OS und Junos OS nicht ganz so leicht in vorhandene Automatisierungsumgebungen integrieren lassen. Wer wählen kann, sollte Cumulus also zumindest evaluieren.

Für Cumulus spricht auch: Wenn die Switches im Netz nur noch einfache Server mit Linux sind, lassen diese sich von einem guten Systemadministrator verwalten, anders als bei Cisco oder Juniper ist kein Spezialist notwendig. In gewisser Weise treiben IP Fabrics damit auch den Wandel in der IT von Spezialisten hin zu Allroundern an. Sysadmins ohne Netzwerk-Vorkenntnisse haben aber viel Büffelei vor sich, denn BGP ist durchaus komplex. Grundsätzlich gilt jedoch: Wer BGP unter Linux nutzen kann, kommt mit Cumulus, Bird oder Quagga zurecht.

Bestehende Setups

Das hier beschriebene Netzwerkdesign ist auch für schon existierende Setups interessant, die unter den Nachteilen des Baum-Layouts leiden. Denn das Setup auf BGP-Basis lässt sich auch nachträglich problemlos einführen. Dafür braucht es nicht sehr viel mehr als beispielsweise den Einbau zusätzlicher Netzwerkkarten in bestehende Server, die dann per BGP bespielt werden.

Zudem lassen sich auf Wunsch mit BGP separate Netzwerke verbinden, die zuvor nicht miteinander kommunizieren konnten. Dafür mag es historische Gründe gegeben haben, die sich auf diese Weise gut überwinden lassen. Gerade in solchen historisch gewachsenen Setups finden sich nämlich regelmäßig Netzwerkinseln, die Veränderungen an der zentralen Infrastruktur wie den Core-Routern verhindern. Eine IP-Fabrics-Lösung hilft dann zuverlässig weiter.