ONL, ONIE und P4 Drei Bausteine zum Aufbau moderner Layer 3 Switche

Kommentieren Drucken

Was sich zunächst nach einer Amerikanischen Sportliga, einer ostasiatischen Gottheit und einem veralteten CPU Typ anhört, ist ein noch relativ junger Trend im Netzwerkumfeld.

Wer heute einen PC oder einen Server in Betrieb nimmt, der stellt sich zunächst einmal die Frage: welches Betriebssystem wähle ich aus? Diese Frage ist von verschiedenen Faktoren abhängig. Zum einen hängt die Auswahl an den genutzten Anwendungen, die im Nachgang installiert werden sollen, aber auch von persönlichen Vorlieben ab. So hat sich im privaten wie im betrieblichen Umfeld Microsoft Windows in all seinen Varianten als Betriebssystem für PC und Serversysteme etabliert. Das liegt natürlich ursächlich an der großen Auswahl von Anwendungen, die hierfür zur Verfügung stehen. Im Server Umfeld sehen wir parallel eine starke Verbreitung von Linux Distributionen, die ebenfalls ihren berechtigten Platz als Serverbetriebssystem einnehmen.

Diese Art der Infrastrukturbereitstellung hat sowohl Vor- als auch Nachteile. Betrachten wir dazu einen Gegenentwurf wie ihn Apple verfolgt. Durch die Kopplung der Hardware an das Betriebssystem – in diesem Fall MacOS – kann durchaus eine optimierte Lösung zur Verfügung gestellt werden, aber zu dem Preis, dass aufgrund der geringeren Marktverbreitung nicht jede Anwendung zur Verfügung steht. Dies bedeutet für den Nutzer: Er hat die Wahl zwischen einer flexiblen Lösung, die weniger Hardware optimiert ist oder einem hardware-optimierten System, welches im Zweifelsfall weniger flexibel ist.

Dies bringt uns nun zu dem eigentlichen Anliegen dieses Artikels. Die eingangs geschilderte Situation der freien Wahl des Betriebssystems galt eben bisher nur für Server und PC Systeme. Im Netzwerkumfeld wurden solche Diskussionen jedoch nie geführt – bis heute. Denn seit ein paar Jahren gibt es Softwareunternehmen wie BigSwitch oder Cumulus, die sich auf die Entwicklung eines Netzwerkbetriebssystems für Switche und Router spezialisiert haben. Die daraus resultierenden Lösungen geben einem jetzt die Möglichkeit, auch Router und Switche mit alternativen, flexiblen Betriebssystemen auszurüsten. Voraussetzung ist jedoch, dass die bekannten und etablierten Enterprise Netzwerkausrüster die Möglichkeit schaffen, solche Alternativen auch nutzen zu dürfen, was Stand heute eher die Ausnahme als die Regel ist.

Neben diesen kommerziellen Switch-OS Alternativen hat sich seit 2014 noch eine weitere Variante am Markt manifestiert: das ONL.

ONL steht für Open Network Linux und stellt eine Quellcode-offene Möglichkeit dar, einen Switch mit einem Betriebssystem zu versorgen. Die zugrunde liegende Linux Distribution basiert auf Debian 7 (Wheezy), allerdings wurden gravierende Änderungen vorgenommen, da eine grundlegende Anpassung an die verwendete Switch-Hardware notwendig wurde. Als Beispiel sei hier nur die Verwendung von Switch ASICs und SFP’s genannt, die so in klassischen PC Systemen nicht zum Einsatz kommen.

Grundvoraussetzung, dass solche OS-Varianten – egal ob quelloffen oder kommerziell – genutzt werden können, ist natürlich die Verfügbarkeit von Hardware Produkten. Diese „Boxen“, gerne auch „White Label Switch“ genannt, basieren auf „open standard, bare-metal hardware“. Dieser Markt, der laut Gartner im Jahr 2020 rund 22% der Data Center Infrastrukturen ausmacht, war bisher ein geschlossener Kosmos mit Herstellern wie Accton/EdgeCore, Alpha Networks, Penguin oder Quanta. Allerdings gibt es auch in diesem Feld zunehmend Bewegung, indem bekannte Enterprise Akteure wie Dell (ehemals Force10), HPE, Mellanox oder Arista vorstoßen.

Die eigentlich spannende Frage ist jedoch: Warum sollte ich zum Beispiel meinen Cisco Switch von seinem CatOS, IOS oder NX-OS befreien? Der Grund hierfür liegt in der Forderung nach Flexibilisierung.

Das erste, was den meisten Netzwerkern beim Begriff Flexibilisierung einfällt, ist SDN: Software Defined Networking, also die dynamische Steuerung und Erkennung von Datenströmen bzw. Anwendungen, in Abhängigkeit von ihrer Priorität und der bereitgestellten Netzinfrastruktur (Bandbreite, Delay, Paketloss, usw.)

Diese Sichtweise ist jedoch zu kurz gegriffen. Durch die Nutzung eines Linux Kernels als Grundlage einer Software Architektur sind flexibel steuerbare Anwendungen oder Dienste auf einem Netzwerkknoten keine Utopie mehr. Ein Beispiel für eine solche Vorgehensweise wäre die Implementierung einer Firewall oder eines Session Border Controllers auf der vorhandenen Switch-Hardware, ohne Änderungen an der physikalischen Struktur vornehmen zu müssen.

Jetzt wir der ein oder andere Leser einwenden, dass dies ja heute schon mittels NFV (Network Function Virtualization) möglich ist, indem man Produkte wie VMware, Microsoft Hyper-V oder KVM hierfür heranzieht. Dabei verkennen sie aber die Situation, dass diese Lösungen zum einen nur im Rechenzentrum zum Einsatz kommen und eben immer den Server als Host, nutzen um Netzwerkdienste anbieten zu können. Der Ansatz mit ONL als Basis zielt aber auf ein anderes Einsatzfeld, dort, wo kein Server zur Verfügung steht, um Netzwerkservices zu erbringen. Das trifft in erster Linie natürlich die großen Netzprovider oder aber auch die Anbieter von (Hyperscale) Rechenzentren, die eine Vielzahl von Netzwerkknoten betreiben, ohne dabei auf die klassischen Virtualisierungsprodukte aufzusetzen.

Hier sollen mittels des Linuxkernels Services zur Verfügung gestellt werden, ohne Änderungen an der Netzwerkhardware vornehmen zu müssen. Im Grunde ist der dahinterstehende Gedanke, Netzwerkfunktionen wieder aus der Overlay-Welt der Virtualisierung zurück in die Netzwerkwelt zu holen, ohne dabei die Switch Infrastruktur durch Serverhosts zu ergänzen.

Die Entwicklung von ONL ist dabei in einem größeren Kontext zu betrachten. Im Jahr 2011 haben sich führende Anbieter der IT Industrie zusammengeschlossen, um das Open Compute Project (OCP) zu starten. Mitglieder sind u.a.: Facebook, Intel, Nokia, Google, Apple, Microsoft, Seagate Technology, Dell, Rackspace, Ericsson, Cisco, Juniper Networks, Goldman Sachs, Fidelity, Lenovo und die Bank of America.

Ziel des Projektes ist es, ein effizientes Design zu entwickeln, welches wenn immer möglich auf standardisierten, offenen Schnittstellen bezüglich der verwendeten Soft- und Hardware Architekturen beruht. Das Konzept orientiert sich dabei an Lösungen für das Rechenzentrum, also Storage, Server und Netzwerk. Dies beinhaltet z.B. Lösungen, die sich CPU-seitig an Intel/AMD oder ARM Infrastrukturen orientieren oder eben auf der Softwareseite Linux als Betriebssystem Basis einsetzen. Als Beispiel sollen hier die Datacenter Infrastrukturen von Facebook dienen, die zu 100% OCP konform sind.

Nun betrachten wir in diesem Artikel speziell die Auswirkungen auf unsere Datennetze. Um also den Blick noch einmal auf ONL zu werfen, hier ein paar grundsätzliche Funktionen bzw. Module, die bei ONL zum Einsatz kommen.

Beginnen wir mit dem generischen Aufbau eines ONL basierten Switchsystems.(siehe Bild 1)

Wie man unschwer erkennen kann, orientiert sich der Aufbau an einer ganz allgemeinen Struktur, wie sie auch in der Serverwelt genutzt wird. Erst im Detail erkennt man dann, welche speziellen Funktionen gefordert werden. (siehe Bild 2)

Die besonderen Erweiterungen sind zum einen spezielle Hardware Treiber und SDKs, die auf die Switch ASICs, z.B. von Broadcom, abgestimmt sind, welche im Allgemeinen nicht der Offenheit des Quellcodes unterliegen. Diese bilden neben der ONL Distribution und den damit verbundenen Plattform APIs die Softwarebasis unseres Switches. Darauf aufbauend schließen sich die gewünschten Anwendungen an. Diese können – wie der Sensor Daemon – Bestandteile der Distribution sein oder aber auch durch zusätzliche Softwarepakete wie Quagga oder Xorp (eXtensible Open Router Platform) abgebildet werden, welche die eigentliche Layer 3 Funktionalitäten wie IPv4/v6, OSPF, IS-IS, BGPv4 oder auch RIP bereitstellen.

Optional wäre natürlich auch vorstellbar, dass bei ausreichender CPU- und Speicherausstattung des Switches mittels Virtualisierung Dienste auf diesen Switchsystemen temporär gestartet werden können, die z.B. bei Serverausfällen deren Funktion übernehmen können.

Der entscheidende Punkt ist jedoch, dass durch die Verwendung eines Linux Betriebssystems auf dem Netzwerkknoten dieser sich administrativ genauso behandeln lässt wie ein Server. Dies bedeutet: alle Tools, die ich zur Verwaltung meiner Linux Systeme nutze, kann ich jetzt auch für meine Netzinfrastruktur einsetzen. Die bisherige Vorgehensweise über CLI Scripte, die auf die Befehlsstruktur des verwendeten Switch-Systems beruhen, oder die Nutzung spezieller APIs, die vom Hersteller zur Verfügung gestellt werden, entfällt. Gerade in heterogenen Umgebungen erleichtert dieser Umstand die Administration der Infrastruktur.

Auf Seiten des Netzwerkadministrators erfordert dies natürlich ein Umdenken. Er muss sich nun mit neuen Techniken einer zentralisierten, SDN basierten Konfiguration vertraut machen und vielleicht eine neue Scriptsprache wie Ruby, Pearl oder P4 lernen, um seiner Arbeit nachkommen zu können. Aber ist dies ein Nachteil? Sicher nicht. Wer heute schon Produkte verschiedener Hersteller oder Produktlinien im Einsatz hat, muss sich auch jetzt schon auf die unterschiedlichen CLI Befehle der einzelnen Systeme einstellen und muss ebenso mit verschieden Elementmanagern, Web GUIs und APIs im Zweifelsfall klarkommen. Hier würde am Ende sogar eine Vereinfachung eintreten und damit auch ein verringertes Fehleraufkommen, eine schnellere Bereitstellung und ein effizienteres Toubleshooting einhergehen.

Die spannende Frage an dieser Stelle ist jedoch, ob sich diese Sichtweise am Markt etablieren kann. Sollten etablierte Hersteller wie Cisco, Extreme oder Juniper ein Interesse daran haben, im Markt der Rechzentrumsbetreiber oder der großen Netzprovider mitzumischen, müssen sie ihre Produkte dahin gehend öffnen. Ob dies aber auch dazu führt, dass im Enterprise Markt ebenfalls solche Produkte eingeführt werden, ist im Moment eher fraglich, da ja mit dieser Umstellung ein Teil der Kundenbindung wegfällt, da sich Netzwerk Know How jetzt überall gleich anwenden lässt.

Zudem sehen wir weitere offene Punkte, wenn wir einen Blick auf die Switch ASICs Auswahl werfen, die seitens ONL unterstützt werden. Hier werden aktuell nur diverse Broadcom Varianten (Tomahawk+, Trident2+, Qumran, Jericho, Helix4 u.a.) sowie der Mellanox Chip „Spectrum“ unterstützt.

Sämtliche Intel (Fulcrum) ASICs bleiben genauso außen vor wie diverse Eigenentwicklungen z.B. von Cisco.

Sollten Sie sich jetzt dennoch entscheiden und einen Switch kaufen, der ohne eigenes Betriebssystem vertrieben wird, stellt sich für Sie im direkten Anschluss die Frage: Wie installiere ich denn ein Netzwerk OS, wie ONL, Cumulus oder BigSwitch auf diesem Gerät?

Nun, auch hierauf hat das Open Compute Project eine Antwort: ONIE.

ONIE steht für „Open Network Install Environment“ und wurde 2012 von Cumulus Network ins Leben gerufen. Seit 2013 ist es Teil der OCP Initiative. Das dahinter liegende Verfahren ähnelt sehr stark dem eines Bootloader für unterschiedliche Betriebssysteme, allerdings erweitert um grundlegende Verfahren, um das interne „Switch Management Subsysteme“, in dem solche Dienste wie serielle Schnittstellen, unterschiedliche CPU Architekturen oder auch „out-of-band“ Netzwerkanschlüsse zusammen geschlossen sind, ansprechen zu können. (siehe Bild 3)

Es handelt sich im Endeffekt um einen Bootloader mit einer kleinen Linux-basierten OS Erweiterung sowie dem BusyBox Tool Set.

Der ONIE „Bootloader“ ist heute in aller Regel integraler Bestandteil eines „white Label“ oder „bare-metal“ Switches und hat sich als de facto Standard im Markt etabliert. Beim ersten Systemstart lädt der Boot Loader (BIOS) des Switches das im Flash Speicher hinterlegte ONIE.

  • Start des Low Level Boot Loader (BIOS)
  •  Laden von ONIE aus dem Flash Speicher

 

  • ONIE Linux OS mit BusyBox
  • Konfiguration des Mgmt Ethernet Port
  • Auffinden des Installers über das Netzwerk

 

  • Zusätzliche Boot Optionen
  • Download der Linux Installation
  • Installation auf die interne HDD/SSD

Der hier vorgestellte Vorgang ist nur bei der Erst-Installation oder bei einem Wechsel des Network OS notwendig. (siehe Bild 4)

Bei einem Re-Boot des Switch Systems wird direkt das auf der Festplatte gespeicherte Betriebssystem geladen. (siehe Bild 5)

  • Start des Low Level Boot Loader (BIOS)
  • Laden des Network OS direkt von der HDD/SSD

 

  • ONIE liegt weiterhin im Flash Speicher (ungenutzt)
  • Verwendung für un-install / re-install

 

  • Konfiguration der Switch ASICs
  • Bereitstellung der Netzwerkprotokolle
  • Bereitstellung z.B. der CLI

Zum Auffinden des Installation Images stehen ONIE eine Reihe von Methoden zur Verfügung. Diese sind u.a.:

  • Statische Konfiguration des Boot Loaders
  • Lokal angeschlossener Speicher (USB Stick bzw. HDD/SSD)
  • Mittels DHCPv4 oder v6
  • IPv4 / IPv6 link local neighbors
  • mDNS / DNS-SD
  • PXE

Die bevorzugte Methode zur Übertragung des Images ist mittels HTTP, da hiermit auch große Datenmengen robust und fehlerfrei übermittelt werden können. Alternativ steht jedoch auch die Verwendung von TFTP zur Verfügung.

Neben den beiden vorgestellten OCP Initiativen hat sich in den letzten drei Jahre eine weitere Entwicklung aufgetan: Das Projekt P4.

P4 steht für “Programming Protocol-Independent Packet Processors”. Dies ist eine Programmiersprache und Laufzeitumgebung für (Soft)Switche, Firewalls, Loadbalancer und Router, welche als Weiterentwicklung des OpenFlow Verfahrens angesehen werden kann.

Ziel des Projektes ist es, eine protokoll-, wie auch hardwareunabhängige Programmierumgebung zu realisieren.

Hardwareunabhängig dahingehend, dass man diese sowohl auf allgemeinen CPUs (x86, ARM), FPGAs (Field Programmable Gate Array), SoC (System on a Chip), Netzwerk Prozessoren oder klassischen Switch ASICs anwenden kann.

In der Vergangenheit wurden Switch-Chips durch geschlossene, feste und proprietäre APIs gesteuert. Eine feste API, die für den genutzten Chip geschrieben wurde, deckte alle Anforderungen ab, und es gab wenig oder keine Notwendigkeit, die API im Laufe der Zeit zu erweitern. Darüber hinaus verbieten NDAs und Lizenzvereinbarungen häufig das Teilen der API mit anderen, was es unmöglich macht, dass nur eine API verwendet wird, um Switch-ASICs von verschiedenen Chipherstellern zu steuern. Infolgedessen ist es schwierig, neue Protokolle und Funktionen hinzuzufügen.

Um aus dieser Zwangswelt auszubrechen, hat man für P4 einen völlig anderen Weg eingeschlagen.

Der P4 Ansatz besagt daher: Es werden keine vordefinierten Protokolle implementiert, sondern es kann je nach Bedarf das Headerformat und die damit verbundenen Position und Länge der einzelnen Felder frei programmiert werden. Sollten sich also im Laufe der Zeit Änderungen oder Erweiterungen in einem Headerformat ergeben, so können diese nachträglich angepasst werden.

Die Sprache verfügt daher über fünf Bestandteile um die geforderte Flexibilität zu gewährleisten:

  • Headers
    Header-Definitionen beschreiben Paketformate und stellen Namen für die Felder innerhalb des Pakets bereit. Die Sprache erlaubt benutzerdefinierte Headernamen und Felder beliebiger Länge, obwohl viele Headerdefinitionen weitverbreitete Protokollnamen und Feldbreiten verwenden. Zum Beispiel könnte eine 802.3- Ethernet-Headerdefinition „Ethernet“ genannt werden. Sie aus einem 48-Bit-Feld namens „dest“, gefolgt von einem 48-Bit- „src“ -Feld, gefolgt von einem 16-Bit- „Typ“ -Feld. Die Namen in einer Headerdefinition werden später im P4-Programm verwendet, um auf diese Felder zu verweisen
  • Parsers
    Der P4-Parser ist ein endlicher Automat, der einen eingehenden Byte-Stream durchkämmt und Header basierend auf dem programmierten Analyse-Graphen extrahiert. Ein einfaches Beispiel wäre ein Parser, der die Ethernet-Quell- und -Ziel- und -Typfelder extrahiert und dann eine weitere Extraktion basierend auf dem Wert im Typfeld durchführt
  • Tables
    P4-Tabellen enthalten den Status, der zum Weiterleiten von Paketen verwendet wird. Tabellen bestehen aus Suchschlüsseln und einem entsprechenden Satz von Aktionen und deren Parametern. Ein einfaches Beispiel könnte sein, einen Satz von Ziel-MAC-Adressen als Nachschlagschlüssel zu speichern, und die entsprechende Aktion könnte den Ausgangsport auf dem Switch setzen und/oder einen Zähler inkrementieren. Tabellen und ihre zugeordneten Aktionen werden fast immer hintereinander verkettet, um die vollständige Paketweiterleitungslogik zu realisieren
  • Actions
    Aktionen in P4 beschreiben Paketfeld- und Metadatenmanipulationen. Im Kontext von P4 sind Metadaten Informationen über ein Paket, das nicht direkt von dem Parser abgeleitet ist, wie der Eingangs-Port, an dem das Frame angekommen ist. Eine Beispielaktion hierfür könnten lauten: „Reduziere das IPv4-TTL-Feld um eins“ oder „Kopiere die MAC-Adresse aus der Ausgabetabelle in den ausgehenden Paketheader.“ P4 definiert Standardmetadaten, die von allen Zielen bereitgestellt werden müssen sowie zielspezifische Metadaten, die vom Programmierer für bestimmte Ziele zur Verfügung gestellt werden
  • Control Flow
    Der Control Flow in P4 bestimmt die relative Sequenz von Tabellen und ermöglicht die bedingte Ausführung von Tabellen basierend auf if/then/else-Konstruktionen [1]

Das verfolgte Ziel ist demnach eine Standardisierung der Administration und der Konfiguration von Netzwerkelementen. Um dies zu erreichen, muss also eine allgemeinverbindliche API existieren, welche nun mittels P4 eingeführt wurde.

Die Einführung von P4 ist jedoch nicht der erste Versuch einer Standardisierung. In der Vergangenheit wurden schon mehrere Versuche unternommen, geschlossene APIs durch offene Schnittstellen zu ersetzen. Der erste war OpenFlow, welcher vor etwa zehn Jahren eingeführt wurde und es einem SDN Controller ermöglichte, Switche verschiedener Hersteller über eine offene API zu steuern. Jedoch wurde OpenFlow für einige bestimmte, häufig auftretende Anwendungsfälle und mit einem festen Funktionsumfang entwickelt. Mit der Zeit mussten man jedoch lernen, dass es schwierig ist, OpenFlow weiter zu entwickeln, da dies mehr Unterstützung für Protokolle, Anwendungen und Funktionalität erfordert, welche jedoch nicht wirklich vorhanden ist.

Zu Beginn der OpenFlow Entwicklung stand z. B. ein Auswerten und Vergleichen („Matching“) auf nur zwölf Header-Feldern zur Verfügung. Diese sind in der Zwischenzeit auf über fünfundvierzig angewachsen, was sich jedoch in Anbetracht des Entwicklungszeitraums von über zehn Jahren als sehr bescheiden ausnimmt.

Ein weiterer Mangel von OpenFlow besteht darin, dass es keine ausreichende Anzahl von Aktionen bereitstellt, die nach einem „Match“ ausgeführt werden können. Hinzu kommt, dass unterschiedliche Switch-ASICs die verschiedenen Aktionen auf verschiedene Arten implementieren.

Jeder, der sich OpenFlow genauer anschaut, wird daher zustimmen, dass es nicht für eine schnell wachsende Erweiterung gedacht und infolgedessen ziemlich unhandlich geworden ist.

OpenFlow leidet darunter, dass es sehr komplex, schwer zu erweitern und in seinem Verhalten mehrdeutig ist.

Eine weitere Entwicklung in diesem Umfeld ist seit 2015 SAI (Switch Abstraction Interface). Es wurde eingeführt, um ein ähnliches Problem wie OpenFlow zu lösen, aber für Netzwerke, bei dem die Control Plane lokal auf dem Switch liegt. Wie OpenFlow kann SAI zur Steuerung von Switches verwendet werden, die auf verschiedenen Switch-ASICs basieren. Aber SAI ist wie OpenFlow eine relativ feste API, die im Laufe der Zeit immer komplexer wird. Dabei ist es aktuell noch unklar, ob zukünftige Erweiterungen standardisiert oder proprietär sein werden. Zudem ist bisher nicht geklärt, wie ein Switch mittels SAI über einen SDN Controller gesteuert werden kann.

Und genau hier setzt P4 an. Es soll die bisherigen Lösungsansätze ergänzen und für ein homogeneres Ganzes sorgen. Dazu haben sich innerhalb des P4 Projektes zwei Strömungen gebildet. Die eine ist die reine Programmiersprache und die andere erarbeitet eine benötigte Laufzeitumgebung.

Abbildung 6 zeigt die Funktionsweise anhand einer lokalen Control Plane auf einem Switch. Das Programm „tor.p4“ stellt das Pipelining auf dem Switch ASIC bzw. Prozessor dar. Dieses Programm wurde von Google programmiert und wird auf den Data Center Switchen in den Google Rechenzentren eingesetzt.

Alternativ kann natürlich auch eine Zentrale Control Plane in Form eines SDN Controllers genutzt werden. Hierbei werden zwischen den P4 Laufzeitumgebungen die gewünschten Flowtables ausgetauscht. (siehe Bild 7)

Da beide im Namen „P4“ enthalten, sollte zunächst geklärt werden, wo die Unterschiede liegen, da sie getrennte Open-Source-Projekte sind.

Die Programmiersprache P4 definiert, wie ein Switch Pakete verarbeitet. Im Wesentlichen gibt P4 die Switch-Pipeline an:

  • Auf welche Felder wird gefiltert bzw. werden Werte überprüft
  • Welche Aktionen sollen im Anschluss ausgeführt werden
  • In welcher Reihenfolge werden die „Matches“ und Aktionen ausgeführt

Die P4-Sprache kann verwendet werden, um das Verhalten eines Netzwerkknotens zu definieren. Sie stellt eine logische Abstraktion dar, wie ein programmierbarer Switch Pakete verarbeiten soll. Zum Beispiel kann die Sprache P4 verwendet werden, um Switch-Chips zu programmieren und dem Kernel mitzuteilen, wie Pakete in Open vSwitch zu verarbeiten sind.

P4 Runtime ist eine API zur Steuerung von Switches, deren Verhalten bereits in der Sprache P4 festgelegt wurde, unabhängig davon, ob der Switch fest, halbprogrammierbar oder vollständig programmierbar ist. Die Laufzeitumgebung stellt somit die Bindung an andere Prozesse dar wie dem Routing, der Firewall oder dem Loadbalancer.

Die hier geschilderten Technologien sind, zugegeben, noch eine recht junge Entwicklungen, was jedoch nicht bedeutet, dass sie nicht angewendet werden. Sowohl die Rechenzentren von Google als auch von Facebook basieren auf den geschilderten Verfahren. Google nutzt sehr intensive ONL und P4, um seine Infrastrukturen zu steuern und zu administrieren. Betriebssysteme wie FBOSS (Facebook Open Switch System), Cumulus oder BigSwitch basieren auf einem Standard Linux Kernel.

Letztendlich geht es bei den vorgestellten Verfahren um eine Vereinfachung und Automatisierung des Netzwerkes. IMAC (Install, Move, Add & Change) Verfahren sollen beschleunigt werden. Die Bereitstellung einer Ressource, egal ob Server, Storage oder NVF Dienst, soll mit der Eingabe „eines“ Parametersatzes komplett realisiert werden können, ohne dass – wie so oft – mehrere Fachabteilungen involviert sind, um die einzelnen Arbeitsschritte umzusetzen.

Welche weiteren Entwicklungen die Zukunft unserer Switche bestimmen, werden wir auf unserem diesjährigen Netzwerk Forum im April in Königswinter intensiv betrachten. So werden wir neben den hier gezeigten Verfahren auch einen neue SDN Controller Ansatz genauer analysieren. Seien Sie also dabei, um auch in Zukunft strategisch richtige Entscheidungen treffen zu können.

zugeordnete Kategorien: Archiv
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.