SDN vs. klassisches Netzwerk in der Private Cloud

Fragen Sie zwei erfahrene Netzwerktechniker, ob Software-defined Networking sich lohnt, und Sie erhalten oft zwei überzeugte, gegensätzliche Antworten. Der eine hat erlebt, wie SDN ein fragiles, von Hand konfiguriertes Netz in etwas verwandelt hat, das sich in Sekunden selbst bereitstellt. Der andere hat einen Ausfall entwirrt, der sich gerade deshalb länger diagnostizieren ließ, weil so viel Logik in Software-Abstraktionen steckte. Beide haben recht — und genau das macht dies zu einem interessanten Vergleich und nicht zu einer ausgemachten Sache.

Dieser Beitrag betrachtet ehrlich Software-defined Networking gegenüber klassischem, manuell konfiguriertem Netzwerk für die Private Cloud: was jeder Ansatz wirklich bedeutet, wo SDN sich auszahlt, wo es Komplexität erzeugt, die man vielleicht nicht will, und warum sich OVN als pragmatischer Mittelweg herausgebildet hat, auf dem heute viele Private Clouds laufen.

Was klassisches Netzwerk tatsächlich ist

In einem klassischen Netz lebt die Intelligenz in den Geräten. Jeder Switch und Router trifft seine eigenen Weiterleitungsentscheidungen und wird einzeln konfiguriert — oft von Hand, über eine Konsole oder SSH-Sitzung, in einer herstellerspezifischen Befehlssprache. VLANs, Access-Listen, Routing und QoS werden Gerät für Gerät angewendet. Dieses Modell ist ausgereift, gut verstanden und bemerkenswert robust: Das Netz leitet selbst dann weiter, wenn jedes Management-Werkzeug offline ist, weil jedes Gerät autonom arbeitet.

Seine Schwächen zeigen sich bei Skalierung und Tempo. Geräte einzeln zu konfigurieren ist langsam und fehleranfällig; eine einzige vertippte Access-Liste kann Verkehr verschlucken, und eine konsistente Richtlinienänderung über fünfzig Switches sind fünfzig Gelegenheiten, etwas falsch zu machen. Ein neues Mandantennetz bereitzustellen kann ein Ticket, ein Wartungsfenster und einen Techniker bedeuten, der mehrere Geräte anfasst. Wenn das Geschäft will, dass Netze so schnell erscheinen wie virtuelle Maschinen, wird die manuelle Konfiguration zum Engpass.

Was Software-defined Networking verändert

Die zentrale Idee von SDN ist, die Steuerebene — das Hirn, das entscheidet, wie Verkehr fließt — von der Datenebene zu trennen, die Pakete tatsächlich weiterleitet, und das gesamte Netz aus einem zentralen, programmierbaren Controller heraus zu steuern. Statt jedes Gerät zu konfigurieren, formulieren Sie Absichten gegenüber dem Controller (dieser Mandant erhält dieses isolierte Netz mit diesen Sicherheitsregeln), und er programmiert die darunterliegenden Geräte entsprechend.

Die Vorteile sind real. Netze werden API-gesteuert, lassen sich also per Software in Sekunden erstellen, ändern und löschen statt per Ticket in Tagen. Richtlinien werden zentral definiert und konsistent angewendet, was eine ganze Klasse von Konfigurationsdrift beseitigt. Und das Netz wird zu programmierbarer Infrastruktur, die Automatisierungswerkzeuge wie Terraform neben Compute und Storage verwalten können. Für eine Cloud-Plattform, in der Mandanten erwarten, isolierte Netze auf Abruf hochzuziehen, ist das keine nette Beigabe — es ist die gesamte Grundlage.

Wo SDN sich wirklich auszahlt

SDN verdient seinen Platz überall dort, wo Skalierung und Änderungsrate hoch sind. Mandantenfähigkeit ist der klarste Fall: Hunderten Mandanten je eigene isolierte virtuelle Netze mit eigenem Routing und eigenen Firewall-Regeln zu geben, ist mit manueller Konfiguration schlicht nicht praktikabel, für einen SDN-Controller aber Routine. Self-Service ist ein weiterer: Wenn Entwickler ein Netz über ein Portal oder eine API anfordern und es Augenblicke später existiert, leistet SDN im Hintergrund die Arbeit. Und Automatisierung im großen Maßstab — eine Sicherheitsrichtlinie über den gesamten Bestand auszurollen oder Mandantennetze als Teil eines Notfallwiederherstellungs-Runbooks neu aufzubauen — wird aus einer tagelangen Handarbeit zu einer code-getriebenen Operation.

Wo SDN Komplexität erzeugt, die man abwägen sollte

Nichts davon ist umsonst, und das Gegenteil zu behaupten ist der Weg, auf dem SDN-Projekte enttäuschen. Ein zentraler Controller ist mächtig, aber auch eine kritische Abhängigkeit; er muss hochverfügbar ausgelegt sein, denn wenn das Hirn des Netzes ins Straucheln gerät, sind die Folgen weitreichend. Auch die Fehlersuche ändert ihren Charakter — statt eine Switch-Konfiguration zu lesen, verfolgt man Absichten durch Schichten aus Abstraktion, virtuellen Switches und Tunneln, was andere Fähigkeiten und bessere Werkzeuge verlangt. Es gibt eine echte Lernkurve, und ein kleines, statisches Netz mit einer Handvoll Switches und seltenen Änderungen holt die Investition vielleicht nie herein. Das ehrliche Fazit lautet: SDN ist nicht automatisch besser; es ist besser, wenn Umfang und Tempo der Änderungen seinen Mehraufwand rechtfertigen.

OVN: der pragmatische Mittelweg

Genau hier passt OVN — Open Virtual Network — hinein, und deshalb ist es für Private Clouds zum Standard geworden. OVN ist ein quelloffenes SDN-System auf Basis von Open vSwitch. Es liefert die software-definierten Fähigkeiten, die für eine Cloud am wichtigsten sind — logische Switches, logische Router, verteilte Firewalls und Overlay-Netze —, ohne dass man sich auf den proprietären Controller und die Hardware eines einzigen Herstellers festlegen muss.

Logische Netze, entkoppelt von der physischen Verkabelung

Die eigentliche Eleganz von OVN besteht darin, dass Mandanten logische Netze definieren können — Switches und Router, die in Software existieren —, die dann als Overlays (typischerweise mit derselben VXLAN-/Geneve-Kapselung, die eine Leaf-Spine-Fabric ohnehin spricht) über das physische Netz darunter realisiert werden. Mandanten erhalten die gewünschte Isolation und den Self-Service; Betreiber behalten eine saubere Trennung zwischen den logischen Netzen, die Kunden sehen, und den physischen Pfaden, die Pakete tatsächlich nehmen. Entscheidend ist, dass OVN einen Großteil der Arbeit auf jeden Hypervisor verteilt, statt alles durch eine zentrale Box zu leiten, was den Ost-West-Verkehr schnell hält und einen einzelnen Engpass vermeidet.

SDN und klassisches Netz schließen sich nicht aus

Die Gegenüberstellung von SDN und klassischem Netzwerk ist etwas irreführend, denn die besten Private Clouds nutzen beides an seinem richtigen Platz. Das physische Underlay — die Leaf-Spine-Fabric aus Switches — wird weiterhin mit klassischer, robuster Netzwerkdisziplin konfiguriert und betrieben, zunehmend mit Automatisierung, um es konsistent zu halten. Das mandantenseitige Overlay, in dem Netze auf Abruf erscheinen und verschwinden müssen, ist software-definiert. Jede Schicht tut, was sie gut kann: Das Underlay liefert schnellen, zuverlässigen, vorhersehbaren Transport, und das SDN-Overlay liefert Flexibilität und Isolation darüber.

Genau so wird eine moderne OpenStack-Cloud gebaut. Der Netzwerkdienst Neutron stellt die API und das Self-Service-Erlebnis bereit, während OVN das logische Switching und Routing darunter umsetzt — alles getragen von einer physischen Fabric, die auf Durchsatz und Ausfallsicherheit ausgelegt ist. Das Ergebnis verbindet die Agilität von SDN mit der Verlässlichkeit eines gut gebauten klassischen Netzes.

Den richtigen Ansatz wählen

Für eine Private Cloud ist die praktische Antwort selten alles-oder-nichts. Sie wollen eine solide, klassisch konstruierte physische Fabric und ein software-definiertes Overlay für das Mandantennetz, mit OVN als offener, mandantenfähiger Engine, die beides verbindet. Rein manuelles Netzwerk kann den Self-Service und die Mandantenfähigkeit nicht liefern, die eine Cloud verlangt; ein schwergewichtiger proprietärer SDN-Stack kann sie liefern, aber um den Preis von Lock-in und Komplexität. OVN trifft genau die Mitte.

Bei clouditiv bauen wir souveräne, OpenStack-basierte Private Clouds nach exakt diesem Modell — OVN-gesteuertes Mandantennetz über einer Arista-Leaf-Spine-Fabric —, sodass Kunden Netze auf Abruf und isoliert erhalten, ohne Kontrolle oder Transparenz abzugeben. Wer tiefer in den OpenStack-Teil dieses Bildes einsteigen möchte: Unsere Erklärung zu Neutron und OVN passt natürlich zur Designphilosophie hinter unserer On-Premise-Private-Cloud. Das Ziel ist durchgängig dasselbe: Automatisierung, wo sie hilft, Robustheit, wo es darauf ankommt, und kein Lock-in, den Sie nicht selbst gewählt haben.