Abo
  • Services:
Anzeige
Openstack ist ein Beispiel für eine Cloud-Lösung, mit der sich SDN sinnvoll und effektiv nutzbar machen lässt.
Openstack ist ein Beispiel für eine Cloud-Lösung, mit der sich SDN sinnvoll und effektiv nutzbar machen lässt. (Bild: Openstack)

Am konkreten Beispiel: Openstack

Besser verständlich ist die Idee hinter SDN und Open vSwitch anhand eines konkreten Beispiels. Openstack bietet sich an: Eine typische Openstack-Cloud enthält alle Faktoren, die SDN sinnvoll und effektiv nutzbar machen. Hier müssen Kunden ihre Netzwerke selbst verwalten können und gleichzeitig muss es möglich sein, eigene VMs mit der Außenwelt kommunizieren zu lassen und öffentliche IPs zu vergeben. Traffic verschiedener Kunden darf sich dabei keinesfalls behindern. Außerdem muss die Kommunikation von VMs, die zum gleichen Kundennetz gehören, auch dann funktionieren, wenn die VMs auf unterschiedlichen Computing-Hosts laufen. Damit VMs innerhalb von Kundennetzen überhaupt mitspielen können, bedarf es einer mit der Cloud integrierten Lösung für DHCP.

Anzeige

In fast allen Szenarien existieren in einer Openstack-Cloud mindestens zwei Arten von Server-Typen: Controller-Knoten betreiben alle Dienste, die für Openstack selbst relevant sind, und Hypervisor-Knoten beheimaten die VMs, die Kunden per API oder Webinterface starten. Zudem kümmert sich in Openstack ein eigener Dienst um das Thema SDN. Dieser heißt Neutron und besteht aus vielen Komponenten.

Die Neutron-API enthält die gesamte Konfiguration und dient als Anlaufstelle für Clients, die die SDN-Konfiguration verändern wollen. Sie läuft auf den Controller-Knoten. Auf allen Servern arbeitet im Default-Setup der Layer-2-Agent für Open vSwitch. Dieser richtet auf Basis der Konfiguration in der API auf jedem Host die lokalen virtuellen Switches so ein, dass virtuelle Maschinen dort andocken können. Er sorgt auch dafür, dass die GRE- oder auch VXLAN-Verbindung zwischen allen Hosts funktioniert. Im Grunde ist es also die Aufgabe des L2-Agents, Underlay und Overlay herzurichten. Daher rührt auch der Name: Der L2-Agent schafft den "virtuellen" Layer 2 nach dem OSI-Modell, also die virtuellen Switches, mit denen sich VMs anschließend verbinden.

Auf den Controllern ist außerdem der DHCP-Agent zu Hause: Weil die Controller zum Overlay gehören, kann auf ihnen für jedes Kundennetzwerk ein DHCP-Server laufen. In Openstack ist das in der Standardkonfiguration übrigens dnsmasq.

Internet per Network Namespace

Nicht zu vergessen sind auch die Layer-3-Agents. Sie versorgen Kunden-VMs mit Internet. Ihr Name ist wieder ein Verweis auf das OSI-Modell: Die L3-Agents legen die virtuellen Router an, über die VMs die Welt außerhalb des eigenen Netzwerks erreichen. Damit das funktioniert, definiert der Anbieter ein öffentliches Netz, das ins Internet geroutet ist. Kunden können anschließend ihre privaten Netze mit diesem öffentlichen Netz verbinden. Auf Systemebene der Controller ist die Verbindung zwischen Kunden- und Public-Netzwerken per Network Namespace realisiert. Das ist eine Art virtueller Netzwerk-Stack des Hosts, dessen virtuelle Netzwerkkarten außerhalb des Namespaces unsichtbar sind. Network Namespaces sind ein Kernel-Feature, das alle aktuellen Systeme bieten.

Ist ein Network Namespace mit einem externen Netzwerk verbunden, gibt es darin sowohl ein Interface mit öffentlicher IP als auch eines mit einer IP aus dem Kundennetz, das im Hintergrund an Open vSwitch andockt. SNAT-Regeln (Source Network Address Translation, also IP-Masquerading) innerhalb des Namespaces bieten VMs die Möglichkeit, mit der Außenwelt zu kommunizieren. Soll eine VM über eine öffentliche IP erreichbar sein, wird diese IP im Network Namespace aktiviert und per DNAT (Destination Network Address Translation, also gezielte Paket-Weiterleitungen) an die private IP der VM durchgereicht, der sie zugewiesen ist. Der Clou: Anwendungen, die in einem Network Namespace gestartet werden, können diesen nicht verlassen. So sorgt Openstack dafür, dass Traffic von unterschiedlichen Kunden nicht kollidiert, selbst wenn diese öffentliche IPs aus den gleichen Netzen verwenden.

Übrigens: DNAT für die Erreichbarkeit per öffentlicher IP-Adresse führt zwar in regelmäßigen Abständen zu Verwunderung, ergibt im SDN-Kontext aber Sinn. Die Idee dahinter ist, einen Pool von IPs zu haben, aus dem sich Kunden nach Bedarf bedienen können. Denkbar wäre theoretisch auch, einzelnen VMs IPs fix zuzuweisen. Allerdings wissen vermutlich nicht alle Kunden, wie sie in ihren VMs überhaupt eine IP einrichten. Zudem verstößt das Prinzip, Kunden statische IPs seitens des Anbieters fest zuzuweisen, gegen das Gebot der maximalen Skalierbarkeit. Denn niemandem ist geholfen, wenn ein Kunde IP-Adressen bezahlen muss, die er eigentlich gar nicht braucht.

Das "Floating-IP"-Prinzip löst dieses Problem, indem es Kunden die Option gibt, einzelne IPs bei Bedarf zu reservieren oder wieder freizugeben. Verwalten lässt sich das in der Cloud aber nur dann ordentlich, wenn das gesamte Handling öffentlicher IP-Adressen auf der SDN-Ebene und außerhalb der VMs passiert. Obendrein ermöglicht das Floating-IP-Prinzip auch die einfache Migration von öffentlichen IPs hin zu neuen VMs. Das kann besonders bei Updates hilfreich sein: Wer ein neues MySQL ausrollen möchte, kann eine neue VM mit entsprechender Datenbank und passendem Datenstand im Hintergrund vorbereiten und am Tag der Migration einfach die IP auf die neue VM umstellen.

Das beschriebene Setup ist ein guter Beweis für die Möglichkeiten, die SDN in Clouds bietet. Denn Kunden können in diesem Konstrukt virtuelle Netze nach Gutdünken anlegen und mit der Außenwelt verbinden. Traffic verschiedener Kunden ist strikt voneinander getrennt, ohne dass es auf Hardware-Ebene kompliziert wird. Nach dem anfänglichen Setup entsteht für den Anbieter nur bei Updates oder Wartungsarbeiten Aufwand; im Alltag muss er sich mit dem Thema Kundennetze nicht weiter befassen.

  • Open vSwitch ist eine offene Implementation von Openflow, die den Betrieb einer Control Plane auf einem normalen Server ermöglicht. (Bild: Openflow-Projekt)
  • Open vSwitch legt auf den SDN-Hosts virtuelle Switches an, deren Konfiguration mittels "ovs-vsctl show" einsehbar ist. (Screenshot: Martin Loschwitz)
  • Das Ziel eines SDN-Setups besteht darin, Kunden die Verwendung von Netzwerk in einer Cloud vollständig selbst zu überlassen. (Screenshot: Martin Loschwitz)
  • Kommerzielle Lösungen wie Midonet von Midokura bieten erheblichen Mehrwert gegenüber einer reinen Open vSwitch-Installation. (Bild: Midokura)
Das Ziel eines SDN-Setups besteht darin, Kunden die Verwendung von Netzwerk in einer Cloud vollständig selbst zu überlassen. (Screenshot: Martin Loschwitz)
 Das Zauberwort heißt EntkopplungKommerzielle Lösungen bieten mehr Funktionalität 

eye home zur Startseite
quasides 04. Apr 2016

Lol Hetzner :) naja billig issa Ansonsten kann man auch mal bei Rackspace und consorten...

quasides 04. Apr 2016

OP wünscht sich einen Stillstand in der Entwicklung damit er mit seinem begrenztem Wissen...

Proctrap 03. Apr 2016

der gute arbeitet, wie sehr gut sichtbar unten bei syseleven ist daher selber...



Anzeige

Stellenmarkt
  1. OSRAM GmbH, Garching bei München
  2. WITTUR Gruppe, Wiedenzhausen
  3. DATAGROUP Köln GmbH, Köln
  4. über Ratbacher GmbH, Köln


Anzeige
Top-Angebote
  1. (u. a. London Has Fallen, The Imitation Game, Lone Survivor, Olympus Has Fallen)
  2. (u. a. Der Hobbit 3, Der Polarexpress, Ice Age, Pan, Life of Pi)
  3. (u. a. 96 Hours Taken 3 6,97€, London Has Fallen 9,97€, Homefront 7,49€, Riddick 7,49€)

Folgen Sie uns
       


  1. Red Star OS

    Sicherheitslücke in Nordkoreas Staats-Linux

  2. Elektroauto

    Porsche will 20.000 Elektrosportwagen pro Jahr verkaufen

  3. TV-Kabelnetz

    Tele Columbus will Marken abschaffen

  4. Barrierefreiheit

    Microsofts KI hilft Blinden in Office

  5. AdvanceTV

    Tele Columbus führt neue Set-Top-Box für 4K vor

  6. Oculus Touch im Test

    Tolle Tracking-Controller für begrenzte Roomscale-Erfahrung

  7. 3D Xpoint

    Intels Optane-SSDs erscheinen nicht mehr 2016

  8. Webprogrammierung

    PHP 7.1 erweitert Nullen und das Nichts

  9. VSS Unity

    Virgin Galactic testet neues Raketenflugzeug

  10. Google, Apple und Mailaccounts

    Zwei-Faktor-Authentifizierung richtig nutzen



Haben wir etwas übersehen?

E-Mail an news@golem.de


Anzeige
Robot Operating System: Was Bratwurst-Bot und autonome Autos gemeinsam haben
Robot Operating System
Was Bratwurst-Bot und autonome Autos gemeinsam haben
  1. Roboterarm Dobot M1 - der Industrieroboter für daheim
  2. Roboter Laundroid faltet die Wäsche
  3. Fahrbare Roboter Japanische Firmen arbeiten an Transformers

Super Mario Bros. (1985): Fahrt ab auf den Bruder!
Super Mario Bros. (1985)
Fahrt ab auf den Bruder!
  1. Quake (1996) Urknall für Mouselook, Mods und moderne 3D-Grafik
  2. NES Classic Mini im Vergleichstest Technischer K.o.-Sieg für die Original-Hardware

HPE: Was The Machine ist und was nicht
HPE
Was The Machine ist und was nicht
  1. IaaS und PaaS Suse bekommt Cloudtechnik von HPE und wird Lieblings-Linux
  2. Memory-Driven Computing HPE zeigt Prototyp von The Machine
  3. Micro Focus HP Enterprise verkauft Software für 2,5 Milliarden Dollar

  1. Android Smartphones für 2nd Factor Auth

    Questor | 06:26

  2. Induktiv laden gehört verboten

    B.I.G | 05:26

  3. Re: Oder aber er kostet gar nichts

    Moe479 | 05:12

  4. Re: Download Link für Red Star OS 3.0 Desktop

    Moe479 | 05:06

  5. Re: Nächste Stufe ...

    Moe479 | 04:51


  1. 17:25

  2. 17:06

  3. 16:53

  4. 16:15

  5. 16:02

  6. 16:00

  7. 15:00

  8. 14:14


  1. Themen
  2. A
  3. B
  4. C
  5. D
  6. E
  7. F
  8. G
  9. H
  10. I
  11. J
  12. K
  13. L
  14. M
  15. N
  16. O
  17. P
  18. Q
  19. R
  20. S
  21. T
  22. U
  23. V
  24. W
  25. X
  26. Y
  27. Z
  28. #
 
    •  / 
    Zum Artikel