© Chiramanas Jutidharabongse, 123RF
Dells OS 10 ist ein auf Linux basierendes Betriebssystem für Netzwerkhardware, das Admins aus dem Würgegriff der etablierten Netzwerkhersteller befreien soll. Worum es dabei geht, wie das System funktioniert und was OS 10 alles kann – ein Überblick.
Dell sorgte Anfang 2016 für Furore, als der – eher für seine Server- und Desktopsysteme bekannte – Hersteller ein Betriebssystem für Netzwerkswitches namens OS 10 http://1 präsentierte. Zwar liefen Switches von Dell auch bisher schon auf Basis des schlicht OS genannten Betriebssystems, aber OS 10 geht in vielerlei Hinsicht weiter – anders als seine Vorgänger basiert OS 10 auf Linux. Zudem liefert Dell das Betriebssystem expressis verbis mit dem Versprechen der Entkopplung: OS 10 soll nicht nur auf Geräten von Dell funktionieren, sondern auch auf generischer Netzwerkhardware.
Anders als proprietäre Switch-Betriebssysteme bietet OS 10 außerdem offene APIs und macht aus Switches normale Linux-Server, die sich in großen Umgebungen wie ihre Serverkollegen verwalten lassen sollen. Das Linux-Magazin schaut genauer hin: Was verspricht Dell sich von OS 10? Wodurch unterscheidet sich das Betriebssystem von klassischer Switch-Firmware? Und wie hoch sind Dells Marktchancen?
Marktanalyse
Um zu verstehen, warum ein offenes Switch-Betriebssystem wie OS 10 so viel Aufsehen erregt, hilft ein Blick auf den Markt für Netzwerkinfrastruktur. Der steht nicht gerade im Verdacht, flexibel und schnelllebig zu sein: Über Jahrzehnte haben ihn sich nur wenige Unternehmen untereinander aufgeteilt, allen voran Juniper und Cisco.
Meist ist die Entscheidung für die Netzwerkhardware eines Herstellers die Entscheidung für eine lange Partnerschaft. Wer sein Rechenzentrum durchgehend mit Hardware eines Herstellers ausgestattet hat, kommt von ihr nur schwer wieder weg. Aus mehreren Gründen: Zwar gibt es Standards für praktisch alle gängigen Netzwerkprotokolle und Netzwerktechnologien, doch trotzdem ist es im Alltag nicht problemlos möglich, Netzwerkhardware zweier Anbieter miteinander zu kombinieren. Wer schon einmal versucht hat, Jumbo-Frames zwischen Switches unterschiedlicher Hersteller zu nutzen, kennt das Problem.
Hinzu kommt, dass ein Netzwerkadmin nicht automatisch Geräte anderer Anbieter administrieren kann, für die er nicht geschult ist. Wer etwa mit Cisco-Switchen umgehen kann, kann nicht automatisch auch Juniper-Hardware bedienen. Reine Linux-Admins sind in Sachen Netzwerkhardware aus eben diesen Gründen meist ohnehin sofort raus. In moderne Devops-Konzepte integrieren sich Switches deshalb nur schwer: Meinst pflegen Unternehmen ihre Konfiguration fernab vom Rest der Installation.
Das Quasi-Monopol der etablierten Hersteller ist in vieler Hinsicht ein Problem. Neben dem fehlenden Druck auf die Feature-Entwicklung und der Lock-in-Problematik behindert es insbesondere den Wettbewerb: Neuen Unternehmen fällt es schwer, mit eigener Netzwerkhardware Fuß zu fassen und eine kritische Größe zu erreichen. Mellanox ist dafür ein gutes Beispiel: Im Infiniband-Markt ist das israelische Unternehmen selbst praktisch der unangefochtene Marktführer – die Ethernet-Sparte der Firma, die einige äußerst interessante Produkte hervorbringt, ist hingegen vielen Netzwerkern völlig unbekannt.
Zudem behindern Switches mit proprietärer Software die Entwicklung zusätzlicher Funktionen: Drittanbieter können mit eigenen Produkten nicht einfach an vorhandene Geräte andocken, weil offene Standards und Schnittstellen fehlen. Entsprechende Kooperationen lassen Juniper & Co. sich teuer bezahlen.
Vermehrt sind in den letzten Jahren aber auch Anzeichen dafür zu erkennen, dass sich das Monopol der etablierten Hersteller langsam auflöst. Maßgeblich dafür ist auch das Thema Cloud Computing und dort insbesondere das Software Defined Networking: Viel Funktionalität, die früher vornehmlich im Switch – also in echter Netzwerkhardware – implementiert war, ist heute in Software umgesetzt.
Das Monopol brechen
Diese Software muss keinesfalls zwingend auf den Netzwerkgeräten etwa des Cloudsetups laufen: In Open Stack-Clouds sind Switches im Normfall zu doofem Eisen degradiert, das nur Pakete zwischen einzelnen Ports empfängt und zustellt. Das ist übrigens nicht Design-bedingt: Denn moderne Switches sind auch nichts anderes als kleine Server mit sehr vielen Netzwerkanschlüssen.
Damit das klappt, muss die Firmware des Switch aber modular und offen sein. Genau hier scheitert die Theorie oft an der Praxis: Denn proprietäre Betriebssysteme sind gerade keine offenen Systeme. Modifikationen an der Firmware der Geräte können nur in dem Umfang stattfinden, den der Hersteller einräumt.
Dass es auch anders geht, zeigt Cumulus [2]: Das Betriebssystem für Switches lässt sich auf der Whitelabel-Hardware diverser Anbieter installieren und bietet neben einem echten Linux-Kern und einer Distribution auf Basis von Debian auch offene APIs. Die Idee des Netzwerkswitch als einfachem Server wird hier Realität. Mellanox setzt bei seinen Ethernet-Produkten deshalb auf eine Kooperation mit Cumulus: Diverse Mellanox-Geräte lassen sich mit installiertem Cumulus bestellen. Weil skalierbare Setups stetig an Bedeutung gewinnen, hat der Markt offener Netzwerkinfrastruktur ein riesiges Potenzial.
Dells OS 10 ist ein Cumulus-Konkurrent
Genau hier schließt sich der Kreis zu OS 10: Dell schlägt damit in die gleiche Kerbe und möchte ein Betriebssystem für Switches im Markt etablieren, das sich ebenfalls auf der Hardware anderer Hersteller nutzen lässt und offene Schnittstellen bietet. Letztlich ist OS 10 also Dells manifestierter Anspruch, vom großen Cloud-Netzwerkmarkt ein ordentliches Stück abzubekommen.
OS 10 macht es in vielerlei Hinsicht so ähnlich wie Cumulus: Das System beruht im Kern auf Linux und folgt den Regeln des SAI – Switch Abstraction Interface ist ein Standard, den Dell, Mellanox, Facebook, Intel und Broadcom im Rahmen der Open-Compute-Initiative gemeinsam erarbeitet haben.
In den vergangenen Monaten hat Dells Marketing für OS 10 ordentlich getrommelt – eingedenk der vielen Gemeinsamkeiten mit Cumulus stellt sich freilich die Frage, was OS 10 tatsächlich kann, was es besser kann als Cumulus und wo noch Verbesserungspotenzial besteht.
Brücke zwischen Hard- und Software
Das Switch Abstraction Interface ist wichtig, um die Idee hinter freien Betriebssystemen für Switches zu verstehen. Grundsätzlich stehen die Hersteller von Netzwerkhardware vor der Herausforderung, der Software auf Switches irgendwie Zugriff auf die Netzwerkhardware zu bieten, die in den handelsüblichen Geräten eingebaut ist. Wie bei jeder Netzwerkkarte sind auch in klassischer Netzwerkhardware Netzwerk-Chipsätze verbaut: Wenige Hersteller – etwa Mellanox – fertigen ihr Silikon selbst, die meisten Anbieter setzen auf fertige Chips, etwa von Broadcom.
Damit ein Betriebssystem Hardware nutzen kann, redet es typischerweise mit dessen Firmware. Das ist der springende Punkt: Damit Standard-Betriebssysteme wie Linux die Netzwerkhardware eines Switch ansprechen und nutzen können, muss der Hersteller dafür sorgen, dass eben jene Betriebssysteme über eine definierte Schnittstelle Zugriff auf die Firmware des verbauten Chipsatzes bekommen.
Bei klassischer Netzwerkhardware sieht sich der Admin hier einem monolithischen Block gegenüber: Direkt auf dem Gerät läuft die Software des Herstellers, die über die proprietäre Firmware des jeweiligen Chipsatzes direkt mit der Hardware kommuniziert. Der Nutzer hat auf Art und Umfang der Schnittstellen, die die Switch-Software anbietet, keinen Einfluss. Das SAI dagegen setzt bei der Firmware des Chipsatzes des Switch an. Wenn die Switch-Firmware ein standardisiertes Interface hat, kann auf dem Switch selbst jede Software laufen – also zum Beispiel auch ein ganz normaler Linux-Kern, der über die SAI-Schicht direkt auf den Chipsatz zugreift.
Dell hat bei OS 10 genau diesen Weg eingeschlagen. Zwischen Hardware und der Software, die der Endanwender sieht, liegt eine Abstraktionsschicht auf Basis der SAI-Spezifikation. Diese kommuniziert nach unten mit der Hardware und exponiert nach oben standardisierte Schnittstellen, etwa im Beispiel Linux durch das Generieren von Netlink-Events in Richtung Kernel (Abbildung 1), wenn ein neues Gerät angeschlossen wird. Auf dieser Abstraktion läuft ein normaler Linux-Kernel in Version 3.16, der obendrein eine Schnittstelle für die Switch-Firmware – also das SAI – ins System durchschleift.
Abbildung 1: Die NPU (Network Processing Unit) ist Teil der SAI-Schnittstelle und exponiert zur Linux-Seite hin normale Netzwerkschnittstellen und Netlink-Ereignisse.
Auf Basis dieses Setups ist es dem Admin überlassen, wie er die Switch-Konfiguration bewerkstelligt: Er kann die Systemressourcen der laufenden Linux-Instanz entweder wie gewohnt nutzen und zusätzliche Netzwerkdienste verwenden, oder er setzt auf Dells Control Plane Service (CPS): Das ist ein objektorientiertes Framework, das direkt auf die SAI-Schicht zugreift (Abbildung 2) und einer klassischen Herstellerlösung nahe kommt.
Abbildung 2: Die Architekturübersicht von OS 10 zeigt deutlich, dass SAI der zentrale Dreh- und Angelpunkt der Plattform ist. Er ermöglicht Linux und CPS.
Dell selbst wird für CPS verschiedene Module anbieten, die Funktionalitäten wie L2-Netzwerk und L3-Routing enthalten, also fertige Lösungen darstellen. Der wichtige Punkt dabei ist: Wer CPS nicht nutzen will, darf auf Basis des Standard-Linux-Systems vergleichbare Funktionen auch selbst implementieren. Zugleich bedeutet dieser Ansatz natürlich auch, dass OS 10 nicht nur auf Dell-Switches laufen muss. Jeder Switch, der den SAI-Standard umsetzt, sollte sich mit OS 10 betreiben lassen.
Dell stellt im Handbuch zur Open Edition von OS 10 allerdings gleich am Anfang klar, dass die Kombination aktuell nur auf einigen Switches von Dell offiziell unterstützt wird. Ob ein Dell-Switch OS 10 offiziell unterstützt, lässt sich laut Dell am schnellsten über die Produktseite des jeweiligen Geräts auf der Dell-Homepage herausfinden.
Konkret: Debian als Basis
Dell bietet OS 10 in Form mehrerer Module an, die ineinandergreifen. Die Open Edition umfasst den Kern des Linux-Betriebssystems: Auf dem Switch läuft dieses Basismodul (Abbildung 3) und bietet ein funktionierendes Standard-Linux. Dell bewirbt OS 10 als unmodifiziertes Debian Jessie, sodass dem Admin auf seinem Switch anschließend Linux 3.16 zur Verfügung steht.
Abbildung 3: OS 10 ist grundsätzlich modular aufgebaut: Das Grundpaket steht frei zur Verfügung; Erweiterungen oder CPS-Module werden separat erhältlich sein.
Der SSH-Login auf dem Switch führt nach der OS-10-Installation zu einer ganz normalen Linux-Shell. Schon dieser Umstand ist für die Nutzer bemerkenswert: Wer die CLIs von Cisco oder Juniper durchdringen möchte, hat eine steile Lernkurve vor sich. Ein Linux-basierter Switch mit normaler Shell lässt sich indes auch von normalen Linux-Admins administrieren, weil die ganze gewohnte Umgebung zur Verfügung steht.
Der Aufruf von »ip a« macht das deutlich: Durch die SAI-Abstraktion sieht der Admin auf dem OS-10-Switch sämtliche Ports des Switch als konfigurierbare Netzwerkinterfaces. Von hier aus hangelt er sich nach Belieben weiter. Weil es sich um ein Debian-System handelt, lässt sich zum Beispiel per »apt-get« neue Software installieren.
Dadurch eröffnen sich alle Möglichkeiten, die auch auf einem normalen Linux-Server verfügbar sind. Beispielsweise in Sachen Monitoring: SNMP-Unterstützung lässt sich per »snmpd« wie gewohnt einrichten, auch Traffic-Statistiken pro Port, etwa per RRD, sind so problemlos möglich. Wirklich schlagkräftig wird das reine Linux auf dem Switch allerdings erst, wenn es um typische Netzwerkfunktionalität geht: Mittels BGP wird aus einem Layer-2-Switch problemlos ein Layer-3-Router.
Layer-3-Routing für Cloud-Setups
Diese Art des Setups ist besonders bei Cloudanbietern beliebt. Die Idee: Anstelle von simplem Switching im Layer 2 fungiert der Switch als Router, um Pakete auf Layer-3-Ebene zuzustellen. Dazu laufen sowohl auf dem Switch als auch auf allen angeschlossenen Hosts BGP-Daemons, zum Beispiel Quagga oder Bird. Jeder Host ist über zwei Netzwerkkarten an zwei unterschiedliche Switches angebunden und verkündet Routen zu seiner Haupt-IP über jene Links.
Diese Lösung bildet Hochverfügbarkeit also nicht über Bonding ab und umgeht dabei Probleme, die beim Bonding etwa dann entstehen, wenn spezifische Offloading-Features (zum Beispiel für VXLan) zum Einsatz kommen. Zudem fungieren die Switches auf diese Weise als Router und es lassen sich auf der Switch-Ebene auch Hosts in unterschiedlichen Netzen problemlos miteinander verbinden.
Das ist zum Beispiel in solchen Fällen sehr praktisch, wenn Clouds auf mehrere Standorte verteilt sind und unterschiedliche lokale Netze nutzen: Dank des L3-Routings bedarf es in solchen Konstrukten keiner zentralen Router mehr (Abbildung 4). Obendrein fügt sich diese Art des Routings deutlich besser in typische Leaf-Spine-Netzwerkarchitekturen ein, wie sie aus Gründen der Skalierbarkeit in Clouds allgemein üblich sind: Im Falle des Ausfalls eines Routers erneuert sich das gesamte BGP-Setup dann automatisch so, dass nur funktionierende Pfade übrig bleiben und defekte automatisch wegfallen.
Abbildung 4: Eine Leaf-Spine-Architektur lässt sich auf OS 10 mit Bordmitteln und etwa Quagga realisieren.
Zwar lässt sich ein solches Setup wahlweise auch mit der proprietären Firmware diverser Hersteller abbilden, doch dafür werden meist saftige Zusatzgebühren fällig. Diese Kosten wiederum machen die Lösung insgesamt schnell unattraktiv. OS 10 löst diese Aufgabe weitaus besser: Quagga oder Bird lassen sich problemlos installieren und jeweils mit einer eigenen Konfigurationsdatei betreiben – der Routing-Teil des Setups ist damit dann schon auf der Switch-Ebene umgesetzt.
Automatisierung problemlos
Ein weiteres großes Problem für moderne Workflows ist die bei klassischer Netzwerkhardware oft anzutreffende statische Konfiguration. Regelmäßig gibt es bei der Hardware etablierter Hersteller nur ein CLI oder eine vom Anbieter spezifizierte, proprietäre Schnittstelle für das Einspielen einer neuen Konfiguration. Mit den typischen Devops-Workflows der Gegenwart lassen sich diese allerdings nur schwer in Einklang bringen: Hier gilt eher die Annahme, dass sich jeder Server zu jedem Zeitpunkt automatisiert und aus der Ferne neu- oder umkonfigurieren lassen muss. Mit einem Standard-Linux wie bei OS 10 ist das hingegen sehr leicht: Egal ob Puppet, Chef oder Ansible – Switches mit OS 10 lassen sich aus den gängigen Automatisierungslösungen heraus völlig problemlos bearbeiten.
Dell hebt dies in der technischen Beschreibung des OS-10-Base-Moduls [3] auch explizit hervor. Denkbar sind damit sogar Workflows, bei denen der neue Switch nach der Installation im Rack automatisiert installiert wird, ohne dass ein Admin sich überhaupt einloggt oder sonstwie händisch eingreift. Das ist mit althergebrachter Netzwerkhardware kaum zu realisieren. Dell erfüllt an dieser Stelle sein Versprechen des universellen Switch-Betriebssystems, das sich in Devops-Workflows einfügt, bis zum letzten i-Punkt.
Cloudsoftware läuft auch
Gerade weil Switches Server mit vielen Netzwerkkarten sind, ist es sogar denkbar, Cloudkomponenten nicht länger auf einzelnen Servern zu betreiben, sondern direkt auf den Switches selbst. Alle gängigen Cloudansätze sehen so genannte Netzwerkknoten vor; diese versorgen VMs in der Cloud mit Netz nach außen und kümmern sich um VXLan-Tunneling und Pakettrennung. Bisher ist es in Cloudumgebungen Usus, diese Aufgaben wahlweise mit auf den Hosts abzuwickeln, die die VMs betreiben – oder eigene Netzwerkknoten zu bauen, die keine andere Aufgabe haben.
Theoretisch hindert Admins schon jetzt nichts daran, auf einem Switch mit entsprechenden Ressourcen – besonders RAM und CPU sind ein Thema – die Netzwerkkomponenten etwa von Open Stack zu installieren und zu betreiben. Durchgesetzt haben sich solche Setups bisher aber noch nicht – wohl auch, weil die gängigen SDN-Lösungen für Clouds wie Open Stack von dem Mehr an Information auf den Switches kaum sinnvoll Gebrauch machen können.
Dank Lösungen wie Cumulus oder OS 10 von Dell ist es aber nur eine Frage der Zeit, bis die SDN-Hersteller generische Switches als Zielplattform identifizieren und entsprechende Funktionalität in ihre Lösungen integrieren. OS 10 ist für Setups dieser Art jedenfalls gewappnet.
CPS für den klassischen Weg
Dell sieht OS 10 freilich nicht nur als Switch-Betriebssystem für Firmen, die maximale Flexibilität bei der Verwaltung ihrer Netzwerkhardware wollen. OS 10 soll stattdessen ein universelles System werden, das die Wahl zwischen Flexibilität und Lösungen von der Stange bietet. Der Control Plane Service ist Teil dieses Konzepts: Es handelt sich um eine Programmier-Schnittstelle, über die Dell Module nachrüstet und die so die Funktionalität des Switch erhöht. Die ist zwar auch auf Basis des Linux-Systems von OS 10 realisiert, sie hat im Hintergrund allerdings auch direkten Zugriff auf den SAI-Layer.
Dells schöne, dynamische Welt bekommt hier zumindest kleine Risse, denn verschiedene wichtige Features der Switch-Hardware lassen sich nur per CPS- Schnittstelle konfigurieren, nicht aber über die Linux-Kommandozeile. Dazu gehören Port-Monitoring auf Hardware-Ebene, QoS oder ACLs. Immerhin: Dell hat eine ausführliche Dokumentation zu CPS und dem zugehörenden API veröffentlicht und mit vielen Beispielen gespickt. Obendrein existieren Bindings für die wichtigste Skriptsprache Python. Wer eines der CPS-only-Features nutzen will, kann dies über die CPS-Schnittstelle also auch tun, ohne Geld an Dell zu überweisen (Abbildung 5).
Abbildung 5: Für CPS steht eine Python-Integration bereit, sodass sich aus Python-Skripten wie hier die MAC-Tabelle des Switch auslesen lässt.
Klar ist, dass dies kaum Dells Absicht gewesen sein dürfte: Denn CPS richtet sich spezifisch an jene Unternehmen, die L2- oder L3-Funktionen wollen, ohne sich um die konkrete Umsetzung auf dem Switch zu kümmern. CPS ist auch Dells Antwort auf die Frage, wie Dritthersteller ihre Produkte fit für den Einsatz auf OS-10-Switches machen können – indem sie CPS nutzen und ihre Systemanfragen über das dortige API abwickeln.
Die ersten Versionen von OS 10 schneiden im direkten Vergleich mit Konkurrenzprodukten wie Cumulus allerdings schlecht ab, weil sie noch nicht alle Features der Konkurrenz unterstützen. Auf Basis von CPS dürfte Dell aber versuchen, diesen Feature-Vorsprung einzuholen.
Was hat Open Networking von OS 10?
Apropos Cumulus: Interessant an der Veröffentlichung von OS 10 ist auch die Tatsache, dass Dell in Form von OS 10 einen direkten Konkurrenten zum Cumulus-Betriebssystem für Switche anbietet, ohne die existierende Partnerschaft mit Cumulus aufzukündigen. Schon bisher war es nämlich durchaus möglich, Dell-Switche ohne Dell-OS zu bekommen: Dell liefert eigene Switches auch mit Cumulus als Betriebssystem aus.
Bis jetzt hat Dell dies stets als Teil seiner Open-Networking-Bemühungen vermarktet: Der Open Networking Foundation gehören praktisch alle großen Hersteller von Netzwerkhardware an, darunter eben auch Dell. Gemeinsam arbeiten sie im Rahmen des ONF an dem Ziel, Software Defined Networking zu standardisieren und dessen Verbreitung zu erhöhen.
In einer separaten FAQ zum Thema OS 10 stellt Dell klar, dass das System als Ergänzung und Erweiterung der Dell-ONF-Strategie zu verstehen ist und die bestehende Cumulus-Partnerschaft nicht beeinträchtigt. Trotz des großen Marketing-Tamtam Anfang 2016 ist die Anzahl der Switches, die OS 10 unterstützen, noch gering. Wer OS 10 will, kann es bei Dell nicht vorinstalliert kaufen, sondern muss OS 10 auf einem kompatiblen Gerät nachinstallieren. Das OS-10-Angebot von Dell hinkt dem Cumulus-Angebot damit hinterher. Solange Dell diese Probleme nicht beseitigt, wäre es unklug, Cumulus den Laufpass zu geben.
Klar ist aber auch, dass das langfristig nicht Dells Anspruch sein kann. Eine Zeit lang wird der Hersteller seinen Kunden wohl die Wahl zwischen OS 10 und Cumulus lassen, zumindest so lange, bis eine Feature-Parität gegeben ist. Danach müsste es spannend werden.
Fazit: Das Problem ist das Umparken im Kopf
Dell demonstriert mit OS 10, wohin es in Sachen Netz in einem Devops-geprägten Umfeld geht. Den Netzwerk-Dinosauriern – allen voran Juniper und Cisco – ist das ebenfalls längst aufgefallen. Juniper etwa versucht aktuell, Junos auch als Betriebssystem für andere Hardware zu etablieren. Verglichen mit den Bemühungen von Dell wirkt das jedoch wie der verzweifelte Versuch, das Pferd von hinten her aufzuzäumen.
Bei OS 10 geht es nämlich gar nicht so sehr um die Zielplattform, auf der das Betriebssystem am Ende läuft. Viel wichtiger ist seine innere Struktur. Und Dells Ansatz könnte radikaler kaum sein: Weg von geschlossenen und proprietären Lösungen – hin zu einer offenen Plattform, die Admins sich mit Standardwerkzeugen so einrichten können, wie sie sie brauchen.
Dieser Ansatz ist so radikal, dass er gerade für jene Unternehmen eine mentale Hürde darstellt, die klassisches Netzwerken auf Basis eines speziellen Herstellers lange gewohnt sind. Wer sich jahrelang auf Juniper konzentriert oder die Zertifikate seiner Cisco-Schulungen stolz über dem Schreibtisch hängen hat, tut sich anfänglich schwer damit, dass ein Switch bloß noch ein normaler Linux-Server ist, der so konfiguriert wird, wie alle anderen Geräte auch.
Allzu nahe liegt dann der Denkfehler, dass spezifisches Netzwerkwissen dadurch entwertet würde. Dabei ist tatsächlich das Gegenteil der Fall: Die Komplexität von Netzwerksetups wird gerade im Kontext mit Software Defined Networking steigen.
