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)

SDN zur Hilfe

Die Motivation hinter dem Einsatz von Software Defined Networking ist für die meisten Unternehmen, dass sich mit SDN-Umgebungen die genannten Nachteile klassischer Netzwerke umgehen lassen. Das wichtigste Wort im SDN-Kontext ist Entkopplung: Komponenten der Netzwerk-Infrastruktur – besonders die Switche – verlieren dabei alle Management-Aufgaben.

Praktisch betrifft das vor allem VLANs: Switche nutzen keine VLANs mehr, sondern werden zu bloßen Packet-Forwardern ohne spezifische Zusatzaufgabe. Aus der Sicht des Switches befinden sich alle angeschlossenen Hypervisor-Hosts auf der gleichen Ebene, etwaige Sicherheitsvorkehrungen wickelt die SDN-Software selbst ab. Auch ist die SDN-Implementierung verantwortlich dafür, die Netzwerktopologien der in der Cloud vorhandenen Nutzer voneinander zu trennen und den Nutzern zugleich die Möglichkeit zu geben, ihre Netzwerke selbst zu verwalten. Grundlage für dieses System ist freilich, dass die SDN-Technologie sowie die verwendete Cloud-Umgebung grundsätzlich eng miteinander verbunden und integriert sind.

Ein vorzügliches Beispiel für diese Art der Implementierung ist Neutron, die zentrale SDN-Komponente von OpenStack. Neutron kümmert sich im OpenStack-Kontext um alles, was irgendwie mit Netzwerken zu tun hat, also um die Netzwerktopologien einzelner Cloud-Kunden genauso wie um die Verbindung der VMs untereinander im Hintergrund. Auch DHCP- und Routing-Dienste fallen in den Aufgabenbereich der Netzwerkkomponente. Schon aus dieser Beschreibung ist ersichtlich, dass Neutron sehr komplex ist und nicht zufällig ist Neutron auch jene Komponente, die für künftige OpenStack-Admins mit Abstand am schwersten zu durchblicken ist.

Der Neutron-Server

Grundsätzlich ist Neutron modular aufgebaut und das in mehrfacher Hinsicht. Den Anfang macht der Neutron-Server: Er ist quasi das Hirn der Lösung und im Hintergrund dafür verantwortlich, die Netzwerkkonfiguration zu speichern. Er ist auch die erste Anlaufstelle für alle anderen Neutron-Komponenten auf den anderen Hosts innerhalb der Cloud – wollen diese eine Ãnderung am Netzwerk vornehmen, so geht das nur durch den Neutron-Server. Für sich genommen ist die Komponente freilich nutzlos, denn ohne eine spezifische Netzwerktechnologie erfüllt sie keinen Zweck.

An dieser Stelle kommen die Plugins ins Spiel, die sich im Neutron-Server laden lassen ( Abbildung 1 ). Ein Plugin erweitert den Neutron-Server um die Fähigkeit, ganz konkrete Handlungsanweisungen für eine spezifische SDN-Technologie zu erzeugen. Das Plugin ist auch der Teil des Neutron-Servers, der die spezifischen Einträge für die Netzwerkkonfiguration im Hintergrund in einer Datenbank anlegt.

Abbildung 1: Der Neutron-Server lädt ein Plugin, das verantwortlich dafür ist, die Datenbank im Hintergrund zu verwalten – verräterische Spuren von OVS finden sich im Beispiel (Open vSwitch).

Standardmäßig setzt Neutron auf Open vSwitch, aber es existieren viele Plugins für andere SDN-Technologien, beispielsweise für VMWares NXS [1] – eine Liste von unterstützten Plugins findet sich unter [2] . Aktuelle Neutron-Versionen erlauben es sogar, über das sogenannte Multi-Layer-Framework mehrere Plugins zur gleichen Zeit zu betreiben. Das Plugin läuft zusammen mit dem Server in der Regel auf dem Host, der innerhalb der Cloud als »Cloud-Controller« designiert ist.

Den Cloud-Controller zeichnet eine spezifische Eigenschaft aus: Er selbst betreibt keine virtuellen Maschinen, sondern ist nur eine Instanz, die alle anderen Cloud-Rechner steuert und kontrolliert. Das stellt das System vor ein simples Problem: Wie kommen Netzwerkanweisungen vom Cloud-Controller auf die Knoten innerhalb der Wolke, damit sie dort wie gewünscht funktionieren?

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