OpenStack-Netzwerk: Neutron und OVN erklärt

Compute und Storage bekommen die Aufmerksamkeit, wenn von Private Clouds die Rede ist, doch beim Netzwerk entscheidet sich still, ob eine Cloud gelingt oder scheitert. In OpenStack ist das Netzwerk die Aufgabe von Neutron — dem Dienst, mit dem Mandanten ihre eigenen Netze, Router und Sicherheitsregeln über eine API anlegen, ohne je ein Ticket beim Netzwerkteam zu eröffnen. Hinter Neutron sitzt in modernen Deployments OVN: das Open-Virtual-Network-Backend, das diese logischen Anfragen in tatsächliche Weiterleitungsregeln über das ganze Rechenzentrum hinweg übersetzt. Zu verstehen, wie beide zusammenspielen, ist der Schlüssel zum Verständnis von Software-defined Networking in OpenStack.

Dieser Artikel zeigt, was Neutron leistet, warum OVN zu seinem Standard-Backend geworden ist und wie ein Paket tatsächlich seinen Weg von einer virtuellen Maschine zur anderen über die Fabric findet. Ziel ist ein mentales Modell, das trägt — ob Sie ein Deployment entwerfen oder es um zwei Uhr morgens debuggen.

Was Neutron wirklich bereitstellt

Neutron ist die Networking-as-a-Service-Schicht von OpenStack. Ihr ganzer Daseinszweck ist, jedem Mandanten die Fähigkeit zu geben, die benötigte Netzwerktopologie bei Bedarf und isoliert von jedem anderen Mandanten aufzubauen, der dieselbe physische Hardware teilt.

Über Neutron kann ein Mandant ein privates Netz anlegen, virtuelle Maschinen daran anschließen, einen Router hinzufügen, um andere Netze oder das Internet zu erreichen, Floating IPs zuweisen und Sicherheitsgruppen definieren, die als Firewall pro Instanz wirken. Entscheidend: Zwei Mandanten können denselben privaten Adressbereich nutzen — etwa 10.0.0.0/24 —, ohne je zu kollidieren, weil ihr Verkehr vollständig isoliert ist. Diese Isolation und der Self-Service lassen OpenStack sich wie eine Cloud anfühlen statt wie ein Haufen VMs an einem flachen LAN.

Das ML2-Plug-in-Modell

Neutron selbst ist bewusst eine dünne Abstraktion. Die eigentliche Arbeit, das Netzwerk zu programmieren, wird über das Modular-Layer-2-Framework (ML2) an ein Plug-in delegiert. ML2 trennt zwei Belange: den Netzwerktyp (den Mechanismus zur Verkehrsisolation, etwa VLAN, VXLAN oder Geneve-Overlays) und den Mechanismus-Treiber (die Technik, die die Weiterleitung tatsächlich umsetzt).

Dieses steckbare Design ist der Grund, warum sich das OpenStack-Netzwerk über die Jahre weiterentwickeln konnte, ohne die mandantenseitige API neu zu schreiben. Derselbe Neutron-API-Aufruf — ein Netz anlegen, einen Port anlegen — kann von sehr unterschiedlichen darunterliegenden Techniken bedient werden. Lange Zeit war der Standard-Mechanismus-Treiber Open vSwitch mit einer Reihe von Agenten. Der heutige Standard im modernen OpenStack ist OVN, und der Wechsel lohnt das Verständnis.

Warum OVN zum Standard wurde

Der frühere Open-vSwitch-Treiber stützte sich auf eine Sammlung von Python-Agenten auf jedem Knoten — ein L2-Agent, ein L3-Agent für das Routing, ein DHCP-Agent, ein Metadaten-Agent —, die sich über Neutron und die Nachrichten-Queue koordinierten. Es funktionierte, war aber betrieblich schwer: viele bewegliche Teile, Agenten, die aus dem Takt geraten konnten, und Routing, das durch dedizierte Netzknoten lief, die zu Engpässen und Single Points of Failure wurden.

OVN, innerhalb des Open-vSwitch-Projekts entwickelt, denkt das neu. Statt eines Schwarms von Python-Agenten bietet OVN eine kompakte, eigens gebaute Steuerungsebene in C, bei der ein Großteil der Intelligenz — Routing, DHCP, Sicherheitsregeln — in Open-vSwitch-Flows auf jedem Hypervisor hinuntergedrückt wird. Das Ergebnis sind weniger Komponenten, verteiltes Routing ohne zentralen Flaschenhals und eine sauberere Abbildung von logischer Absicht auf tatsächliche Flows. Für die meisten neuen Deployments ist OVN schlicht die besser konstruierte Wahl, weshalb es heute das Referenz-Backend ist.

Im Inneren der OVN-Architektur

OVN hat eine kleine Zahl klar definierter Bausteine, und sobald sie ineinandergreifen, ergibt das ganze System Sinn.

Die zwei Datenbanken

Im Herzen von OVN liegen zwei Datenbanken. Die Northbound-Datenbank hält die logische, absichtsbezogene Beschreibung des Netzes: logische Switches, logische Router, Ports und ACLs — im Wesentlichen eine direkte Übersetzung dessen, was Neutron angefordert hat. Die Southbound-Datenbank hält die physische Umsetzung: auf welchem Hypervisor jeder Port lebt und die logischen Flows, die das gewünschte Verhalten realisieren.

ovn-northd und die Controller

Ein Daemon namens ovn-northd sitzt zwischen den beiden Datenbanken und übersetzt das logische Northbound-Modell fortlaufend in die physischen Southbound-Flows. Auf jedem Hypervisor liest ein ovn-controller-Prozess die Southbound-Datenbank und programmiert die lokale Open-vSwitch-Instanz entsprechend. Die Kette ist elegant: Neutron schreibt die Absicht, ovn-northd kompiliert sie, und der Controller jedes Knotens setzt sie lokal durch.

Einem Paket über die Fabric folgen

Konzepte bleiben besser hängen, wenn man einen echten Pfad nachzeichnet. Stellen Sie sich VM-A auf Hypervisor 1 vor, die ein Paket an VM-B auf Hypervisor 2 sendet, beide im selben Mandantennetz.

VM-A gibt das Paket an ihre virtuelle NIC, die mit der lokalen Open-vSwitch-Bridge verbunden ist. Die dortigen OVN-Flows, von ovn-controller programmiert, erkennen das Ziel als logischen Port, der auf Hypervisor 2 lebt. Statt den rohen Frame zu senden, kapselt OVS ihn in einen Geneve-Overlay-Tunnel — das Mandantenpaket wird in einen Header gewickelt, der es über das physische Underlay-Netz zu Hypervisor 2 trägt. Bei der Ankunft entfernt das empfangende OVS den Tunnel-Header, identifiziert den richtigen logischen Port, wendet etwaige Sicherheitsgruppenregeln an und liefert das Paket an VM-B. Die beiden virtuellen Maschinen verhalten sich, als teilten sie sich einen einfachen Switch, während die Fabric darunter gekapselten Verkehr zwischen physischen Hosts beförderte. Sicherheitsgruppen und Routing werden direkt am Quell- und Zielhost angewendet — genau deshalb vermeidet OVN den zentralen Netzknoten-Flaschenhals des älteren Modells.

Overlays, Underlays und die Leaf-Spine-Fabric

Dieser Geneve-Tunnel ist das Overlay; das physische Netz, auf dem er reitet, ist das Underlay. Diese Trennung ist die wichtigste Einzelidee modernen Rechenzentrumsnetzwerks. Das Underlay — typischerweise eine Leaf-Spine-Fabric aus Hochgeschwindigkeits-Switches in einem gerouteten Design — muss nur Pakete zwischen den IP-Adressen der Hypervisoren effizient und zuverlässig bewegen. Es muss nichts über Mandanten, virtuelle Netze oder den Aufenthaltsort einer VM wissen.

Die gesamte mandantenspezifische Komplexität lebt im Overlay, von OVN programmiert. Genau das lässt eine Private Cloud skalieren: Sie können dem Underlay Racks und Hypervisoren hinzufügen, ohne Mandantennetze umzukonfigurieren, und Mandanten können Netze frei hochfahren und abbauen, ohne dass jemand einen physischen Switch anfasst. Die Overlay-Underlay-Trennung ist auch der Grund, warum sich Techniken wie BGP EVPN/VXLAN auf der Fabric-Ebene so natürlich mit OVN-Overlays darüber paaren.

OVN-Netzwerk im Produktivbetrieb

Ein paar Realitäten zählen, sobald dies Produktivverkehr trägt. Die Geneve-Kapselung verursacht Overhead, daher lohnt es sich, Jumbo Frames im Underlay zu konfigurieren, um Fragmentierung zu vermeiden. Die OVN-Datenbanken sind wichtiger Zustand und profitieren von einer geclusterten, hochverfügbaren Konfiguration. Und verteiltes Routing bedeutet, so groß die Verbesserung ist, dass sich die Fehlersuche vom Inspizieren eines zentralen Netzknotens zum Nachvollziehen von Flows über viele Hypervisoren verlagert — gute Beobachtbarkeit mit Prometheus und Grafana zahlt sich hier rasch aus.

Hier verdient sich auch eine verwaltete Plattform ihr Geld. Bei clouditiv betreiben wir OpenStack 2025.2 mit Neutron und OVN als Netzwerkrückgrat einer souveränen Private Cloud, auf einer Leaf-Spine-Fabric aus Arista-Switches, wobei das Datenbank-Clustering, die Overlay-Abstimmung und das Monitoring als Teil des Service übernommen werden. Mandanten erhalten sauberes Self-Service-Networking; die beträchtlichen betrieblichen Details darunter sind die Vollzeitaufgabe eines anderen.

Alles zusammenführen

Die Eleganz des OpenStack-Netzwerks liegt in der Schichtung. Neutron gibt Mandanten eine einfache Self-Service-API. ML2 hält diese API stabil, während sich die Umsetzung darunter weiterentwickelt. OVN kompiliert die Mandantenabsicht in verteilte Flows und trägt den Verkehr über Geneve-Overlays. Und eine saubere Underlay-Fabric bewegt die gekapselten Pakete, ohne sie je verstehen zu müssen. Sobald Sie ein Paket von einer virtuellen NIC über einen Overlay-Tunnel quer durch die Fabric und in eine andere VM nachzeichnen können, hört Software-defined Networking auf, eine Blackbox zu sein — und genau dieses Verständnis lässt Sie ein Private-Cloud-Netz entwerfen, skalieren und ihm vertrauen.