ONOS (Open Network Operating System)
ONOS (Open Network Operating System) ist ein Betriebssystem. Es wurde entwickelt, damit Service-Provider Carrier-Grade-SDNs (Software-defined Network) aufbauen zu können, die hohe Skalierbarkeit, Hochverfügbarkeit und hohe Performance bieten. In erster Linie ist es konzipiert, um den Bedürfnissen von Service-Providern gerecht zu werden. ONOS kann aber auch als SDN-Kontrollschicht (Control Plane) für Unternehmens- und Campus-Netzwerke (LAN) sowie Data-Center-Netzwerke dienen.
Das Open Networking Lab (ON.Lab) hat im Dezember 2014 den Quellcode von ONOS, der in Java geschrieben ist, an die Open Source Community übergeben. Im Oktober 2015 schloss sich das ONOS-Projekt der Linux Foundation als gemeinschaftliches Open-Source-Linux-Projekt an. Neue Versionen von ONOS erscheinen vierteljährlich im Februar, Mai, August und November. Sie werden alphabetisch nach einem Vogel benannt. Das ONOS-Logo ist ebenfalls ein Vogel. Die beiden ersten Versionen hießen Avocet und Blackbird. Wie die meisten Open-Source-Projekte gibt es auch von ONOS eine Seite bei GitHub, über die Mithelfer Änderungen am Code einreichen dürfen.
Zu den Service-Providern, die sich an der ONOS-Initiative beteiligen gehören AT&T, NTT Communications und SK Telecom. Weitere Firmen, die Code zu ONOS beisteuern sind Cisco, Ericsson, Intel, NEC, Ciena und Huawei. ON.Lab und ONOS-Partner haben für das Betriebssystem diverse Anwendungsfälle gefunden. Einer der bekanntesten ist CORD (Central Office Re-architected as a Datacenter) von ON-Lab. CORD wurde entwickelt, um die Hauptstellen von Telekommunikationsunternehmen skalierbarer und agiler zu machen. Sie können das mit Next-Generation Data Centern vergleichen. Die Transformation wird zum Beispiel mithilfe von virtuellen Netzwerkfunktionen (Virtual Network Functions, VNF) und Hardware am Standort der Kunden (Customer Premises Equipment, CPE) umgesetzt. ONOS ist eines der Open-Source-Software-Systeme, um CORD zu managen.
Wie ONOS funktioniert
Der Kern von ONOS basiert auf einer modularen Architektur. Im Gegensatz zu einem integrierten System verschwimmt die Aufteilung zwischen den Komponenten. Diese Modularität separiert die North-South-Workflows von den East-West-Workflows, erlaubt aber gleichzeitig eine einfachere Anpassung des gesamten Systems. Weil Service-Provider die Möglichkeit haben müssen, ihre Netzwerke zu skalieren, lässt sich der ONOS-Controller skalieren, um ein physisch verteiltes System an Geräten zu beherbergen. Auf diese Weise können Service-Provider neue Switches und Komponenten hinzufügen und stören dabei das restliche System nicht. Außerdem reduziert die verteilte Architektur Ausfälle im Netzwerk, weil identische Instanzen einen Ausfall kompensieren können. Das Resultat ist Hochverfügbarkeit oder High Availability.
Der Kern von ONOS ist verteilt und kann von jedem Netzwerk-Switching-Gerät erreicht werden. Der ONOS-Controller hingegen ist logisch zentralisiert. Die separaten Unterteilungen oder Instanzen in der kompletten ONOS-Architektur lassen sich aber von einem Gerät aus sichten oder Sie können von dort zugreifen. Für die allgemeine Systemsichtbarkeit und das Management stellt ONOS ein relativ unkompliziertes GUI zur Verfügung.
ONOS stellt Northbound- und Southbound-APIs (Application Program Interface) zur Verfügung, um Konfigurations- und Protokollsperren zu vermeiden. Für Northbound-Interaktionen verwendet ONOS sein Subsystem Intent Framework. Darüber können Anwendungen spezifizieren, was sie vom System benötigen. Ein Beispiel ist, dass eine Anwendung mehr Bandbreite braucht. Sobald eine Anwendung kommuniziert, was sie benötigt, reagiert das System mit der entsprechenden Konfiguration. ONOS ist so konzipiert, um einen Zustrom von geschätzt einer Million Anfragen von Anwendungen pro Sekunde verarbeiten zu können. Dieses Leistungsmerkmal ist der Garant für hohe Performance in Sachen Anfragen von Anwendungen und geringer Latenz. Genau das brauchen Service-Provider.
Jede ONOS-Instanz interagiert mit der Netzwerkumgebung und den Geräten durch ein Southbound-API, das mit den Komponenten auf unterer Ebene kommuniziert. Der Kern erkennt, welche Protokolle benutzt werden können, um mit dem Gerät zu kommunizieren. Das Southbound-API verwendet das Protokoll, um mit dem entsprechenden Gerät zu interagieren. Dieses API ist abstrahiert. Deswegen ist beeinflussen spezielle Protokolle wie zum Beispiel OpenFlow, NETCONF oder Kommandozeilenschnittstellen ONOS nicht.
ONOS im Vergleich mit OpenDaylight
OpenDaylight (ODL) ist ein ähnliches Open-Source-Projekt, das von der Linux Foundation ins Leben gerufen wurde. Sowohl ONOS als auch ODL haben ein modulares Design und ähnliche Ziele, um SDN zu fördern. Die zwei Projekte gehen allerdings verschieden an die Sache heran und auch die Unterstützer und Partner unterscheiden sich. ONOS ist in erster Linie für Netzwerke von Service-Providern gedacht und ODL richtet sich an das Netzwerk im Data Center. Das Ziel von ONOS ist außerdem, die allgemeine Performance des Netzwerks zu verbessern. ODL hingegen ist konzipiert, um herkömmliche Netzwerke mit SDN zu fusionieren.
Folgen Sie SearchNetworking.de auch auf Twitter, Google+, Xing und Facebook!
