Abo
  • Services:

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.

Stellenmarkt
  1. Universität Passau, Passau
  2. Rodenstock GmbH, München

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 
  1.  
  2. 1
  3. 2
  4. 3
  5. 4
  6.  


Anzeige
Top-Angebote
  1. (PCGH-Note 1,6 - Bestnote!)
  2. (u. a. ROG Rapture GT-AC5300 + Black Ops 4 für 303,20€ + Versand statt 345€ im Vergleich, RT...
  3. 79,90€ + Versand (Bestpreis!)
  4. (u. a. GTA V für 16,82€ und The Elder Scrolls Online: Morrowind für 8,99€)

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...


Folgen Sie uns
       


Sony Xperia XZ3 - Hands on (Ifa 2018)

Das neue Xperia XZ3 von Sony kommt mit Oberklasse-Hardware und interessanten Funktionen, die dem Nutzer den Alltag erleichtern können. Außerdem hat das Gerät einen OLED-Bildschirm, eine Premiere bei einem Smartphone von Sony.

Sony Xperia XZ3 - Hands on (Ifa 2018) Video aufrufen
Zahlen mit Smartphones im Alltagstest: Sparkassenkunden müssen nicht auf Google Pay neidisch sein
Zahlen mit Smartphones im Alltagstest
Sparkassenkunden müssen nicht auf Google Pay neidisch sein

In Deutschland gibt es mittlerweile mehrere Möglichkeiten, drahtlos mit dem Smartphone zu bezahlen. Wir haben Google Pay mit der Sparkassen-App Mobiles Bezahlen verglichen und festgestellt: In der Handhabung gleichen sich die Apps zwar, doch in den Details gibt es einige Unterschiede.
Ein Test von Tobias Költzsch

  1. Smartphone Auch Volksbanken führen mobiles Bezahlen ein
  2. Bezahldienst ausprobiert Google Pay startet in Deutschland mit vier Finanzdiensten

Grafikkarten: Das kann Nvidias Turing-Architektur
Grafikkarten
Das kann Nvidias Turing-Architektur

Zwei Jahre nach Pascal folgt Turing: Die GPU-Architektur führt Tensor-Cores und RT-Kerne für Spieler ein. Die Geforce RTX haben mächtige Shader-Einheiten, große Caches sowie GDDR6-Videospeicher für Raytracing, für Deep-Learning-Kantenglättung und für mehr Leistung.
Ein Bericht von Marc Sauter

  1. Tesla T4 Nvidia bringt Googles Cloud auf Turing
  2. Battlefield 5 mit Raytracing Wenn sich der Gegner in unserem Rücken spiegelt
  3. Nvidia Turing Geforce RTX 2080 rechnet 50 Prozent schneller

Network Slicing: 5G gefährdet die Netzneutralität - oder etwa nicht?
Network Slicing
5G gefährdet die Netzneutralität - oder etwa nicht?

Ein Digitalexperte warnt vor einem "deutlichen Spannungsverhältnis" zwischen der technischen Basis des kommenden Mobilfunkstandards 5G und dem Prinzip des offenen Internets. Die Bundesnetzagentur gibt dagegen vorläufig Entwarnung.
Ein Bericht von Stefan Krempl

  1. T-Mobile US Deutsche Telekom gibt 3,5 Milliarden US-Dollar für 5G aus
  2. Ericsson Swisscom errichtet standardisiertes 5G-Netz in Burgdorf
  3. Masterplan Digitalisierung Niedersachsen will flächendeckende Glasfaserinfrastruktur

    •  /