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.
Abbildung 1: Switch Architektur 1
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 Abbildung 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 Abbildung 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.
Abbildung 2: Switch Architektur 2
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.
Abbildung 3: Switch Architektur 3
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.
Abbildung 4: Boot Workflow 1
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 Abbildung 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
Abbildung 5: Boot Workflow 2
Der hier vorgestellte Vorgang ist nur bei der Erst-Installation oder bei einem Wechsel des Network OS notwendig. (siehe Abbildung 4)
Bei einem Re-Boot des Switch Systems wird direkt das auf der Festplatte gespeicherte Betriebssystem geladen. (siehe Abbildung 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
