OpenStack Neutron als Beispiel für eine SDN-Implementierung

Evgeniya Uvarova, 1123RF

Maschen knüpfen

Im Fahrwasser der Cloud bahnen sich Technologien wie OpenFlow und Open vSwitch den Weg zu einer breiten Nutzerbasis. OpenStack Neutron zeigt, wie brauchbares SDN aussehen kann.
ADMIN 03/14 stellt Erste-Hilfe-Tipps zu Windows-Rettung, Backup und Recovery bei Datenbanken vor und verrät wie man Linux-Systeme vollständig sichert und ... (mehr)

Wer sich in den letzten Monaten mit der IT-Szene beschäftigt hat, der trifft neben der allgegenwärtigen Wolke immer häufiger auch auf andere Themen, die quasi im Rahmen der Cloud groß werden. Eines davon ist Software Defined Networking, kurz SDN. Hinter diesem etwas sperrigen Begriff verbirgt sich eine relativ simple Idee: Statische Netzwerkkonfigurationen, wie sie in IT-Setups typischerweise zur Anwendung kommen, funktionieren in Clouds mehr schlecht als recht, verhindern manchmal sogar, dass sich die Cloud-Software effektiv nutzen lässt. Indem die gesamte Netzwerkkonfiguration per Software definiert wird, lassen sich Einschränkungen umgehen, die aus der Verknüpfung der Konfiguration mit physischen Geräten herrühren. SDN ist derweil nicht die einzige Technik, bei der Software Hardware ablöst: Auch das Software Defined Storage ist derzeit im Aufwind.

Implizite Netzwerk-Annahmen

Um die Motivation hinter Software Defined Networking gerade im Kontext von OpenStack oder jeder anderen Cloud-Umgebung zu verstehen, hält man sich zuerst vor Augen, welche impliziten Annahmen im Hinblick auf IT-Netzwerke meist von vornherein vorhanden sind. Drei Faktoren spielen eine Rolle:

  • Klassische Netzwerke müssen nicht besonders gut in die Breite skalieren – oft haben sogar einzelne Kunden ihre eigenen Switche, auch wenn sie diese selbst nicht wirklich auslasten können.
  • Klassische Netzwerke unterliegen einer zentralen Verwaltung: der Anbieter nimmt auf Zuruf des Kunden spezifische Konfigurationsänderungen vor, sodass der Kunde das nicht selbst machen muss.
  • Klassische Netzwerke sind in der Entwicklung ihrer Größe und des generierten Traffics vorhersagbar, sodass eine langfristige Planung möglich ist.

Zusammen haben diese drei Annahmen zu typischen Netzwerk-Designs in der IT geführt. Einzelne Kunden haben entweder ihren eigenen Switch oder sind – zur Gewährleistung von Sicherheit – in einem separaten VLAN am Switch untergebracht. Mehrere vorhandene Switche sind gegebenenfalls sternförmig konfiguriert, die zentrale Verwaltung erfolgt durch den Anbieter, wobei die Planung der einzelnen Netzwerktopologien durchaus den jeweiligen Kunden überlassen sein kann.

Reality-Check

Für Clouds funktioniert keine der drei Annahmen. Das geht schon damit los, dass in einer Cloud alle Hypervisor-Hosts zwangsläufig gleichberechtigt sein sollten, damit jeder Hypervisor-Host die VMs jedes Kunden betreiben kann; ein solches System macht auch VLANs sehr unkomfortabel. Überdies wollen Anbieter durch die Installation einer Cloud-Software dafür sorgen, dass Kunden sich in Form eines Service-Portals selbst die Dienste buchen können, die sie brauchen. Ein neuer Kunde muss also in der Lage sein, sich anzumelden und sofort in der eigenen Netzwerkumgebung VMs zu starten, ohne dass dafür das Eingreifen eines Admins notwendig ist. Diese Anforderung kegelt VLANs endgültig aus dem Spiel. Schließlich ist die Entwicklung von Cloud-Netzwerken praktisch kaum sinnvoll vorhersagbar. Denn ein neuer Kunde, der etliche Terabyte Traffic pro Monat produziert, kann sich jederzeit anmelden, ohne das vorher anzukündigen – der Cloud-Anbieter tut gut daran, auf solche Szenarien vorbereitet zu sein.

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023