Der ADMIN 05/13 wirft einen Blick auf die frei verfügbaren Cloud-Frameworks von Eucalyptus über OpenNebula bis OpenStack. Gute Aussichten für skalierbare ... (mehr)

Netzwerkverwaltung: Neutron

Wer sich mit OpenStack auseinandersetzt, landet früher oder später auch bei Neutron ( Abbildung 2 ). Die Komponente genießt nicht den besten Ruf und steht im Verdacht, übermäßig kompliziert zu sein – das liegt allerdings viel weniger an Neutron selbst als an seinen umfassenden Aufgaben: Es kümmert sich darum, dass in einer OpenStack-Umgebung das Netzwerk so funktioniert, wie es soll.

Abbildung 2: Beim Starten einer VM kann der Kunde sich – Neutron sei Dank – aussuchen, zu welchem virtuellen Netz die VM eine Verbindung haben soll.

Das Thema Netzwerk-Virtualisierung wird gern unterschätzt. Typische Netzwerk-Topologien sind eher statisch: Es herrscht eine meist sternförmige Struktur. Bestimmten Kunden sind bestimmte Ports zugewiesen und untereinander sind Kunden voneinander über VLANs getrennt. In Cloud-Umgebungen funktioniert dieses System nicht mehr: Einerseits ist nicht vorhersagbar, auf welchem Computing-Knoten die VM eines Kunden gestartet wird, andererseits skaliert eine solche Lösung auch nicht. Die Antwort auf dieses Problem ist Software Defined Networking, kurz SDN, das im Grunde ein einfaches Ziel hat: Switches sind bloß noch Blech, VLANs & Co. sind nicht länger in Gebrauch und alles, was mit dem Netzwerk zu tun hat, wird über Software innerhalb der Umgebung kontrolliert. Die bekannteste SDN-Lösung ist OpenFlow [4] mit dem dazugehörigen Frontend Open vSwitch [5] . Und Neutron bildet das OpenStack-Gegenstück, nämlich den Teil, der aus OpenStack heraus auf die Konfiguration von Open vSwitch (oder die eines anderen SDN-Stacks) direkten Einfluss nimmt ( Abbildung 4 ). De facto lässt sich mit Neutron ein komplettes Netz virtualisieren, ohne die Konfiguration einzelner Switches anzufassen – über verschiedene Plugins ist es aber auch möglich, Switch-Konfigurationen direkt aus OpenStack heraus zu bearbeiten.

Abbildung 4: Neutron baut im Hintergrund in der Standardkonfiguration sowohl auf OpenFlow als auch auf Open vSwitch auf.

Wie OpenStack ist nämlich auch Neutron [6] modular aufgebaut; die API wird durch ein Plugin für eine spezifische SDN-Technik (beispielsweise das bereits erwähnte Open vSwitch) aufgebohrt, zu jedem Plugin gehört auf der Seite der Computing-Knoten ein entsprechender Agent, der die SDN-Befehle des Plugins umsetzt.

Die generischen Agents für DHCP und L3 erfüllen beide spezielle Aufgaben: Ersterer sorgt dafür, dass VMs beim Starten von Tenants IPs per DHCP bekommen, letzterer schafft eine Verbindung zum Internet für die laufenden VMs. Auf die Spitze getrieben ist es mit Neutron möglich, dass sich jeder Kunde innerhalb seiner Cloud eine eigene Netzwerk-Topologie baut. Die Netzwerke von Kunden dürfen dabei durchaus auch überlappende IP-Bereiche nutzen, der Fantasie sind letztlich kaum Grenzen gesetzt. Der Nachteil dieser enormen Funktionsvielfalt ist freilich, dass es einiges Vorwissen zu Themen wie der Funktionsweise von Software Defined Networks braucht, um zu verstehen, was Neutron eigentlich tut – und um den Fehler zu finden, wenn etwas einmal nicht so funktioniert, wie es soll.

Übrigens: Wer sich in der Vergangenheit bereits mit OpenStack beschäftigt hat, kennt diese Komponente vielleicht noch unter ihrem alten Namen, Quantum ( Abbildung 3 ). So hieß Neutron bis einschließlich OpenStack 2013.1, bis ein Streit um Namensrechte in den USA zur Umbenennung in Neutron führte.

Abbildung 3: Neben dem Dashboard bieten auch die einzelnen Client-Tools auf der Kommandozeile die Möglichkeit, die einzelnen Komponenten zu bedienen.

VM-Verwaltung: Nova

Die bisher vorgestellten Komponenten erledigen im Rahmen einer Cloud die wichtige Vorarbeit, um virtuelle Maschinen laufen zu lassen. Nova [7] ( Abbildung 5 ) kommt quasi als Exekutive innerhalb einer OpenStack-Cloud hinzu: Nova zeichnet für das Starten und Stoppen von virtuellen Maschinen sowie für die Verwaltung der zur Verfügung stehenden Hypervisor-Knoten verantwortlich. Weist der Nutzer die OpenStack-Cloud an, eine virtuelle Maschine zu starten, so erledigt Nova stets das Gros der Arbeit: Es schaut bei Keystone nach, ob der Benutzer überhaupt eine VM starten darf, weist Glance an, eine Kopie des Images auf dem Hypervisor anzulegen und zwingt Neutron, eine IP für die neue VM herauszurücken. Ist all das passiert, startet Nova selbst die VM auf dem Hypervisor-Knoten und erlaubt es anschließend auch, sie herunterzufahren, zu löschen oder auf einen anderen Host umzuziehen. Auch Nova besteht aus mehreren Teilen: neben einer API namens Nova-API ist es vor allem die Nova-Compute-Komponente, die auf den Hypervisor-Knoten die Arbeit erledigt. Andere Komponenten erfüllen spezifische Aufgaben: »nova-scheduler« beispielsweise findet anhand der Konfiguration und seiner Informationen über vorhandene Hypervisor-Knoten heraus, auf welchem Hypervisor die neue VM überhaupt zu starten ist.

Abbildung 5: Nova besteht aus vielen einzelnen Komponenten, dazu gehören der Scheduler oder nova-compute.

Dabei hat Nova übrigens keineswegs das Rad neu erfunden: Kommt es zusammen mit Libvirt und KVM auf Linux-Servern zum Einsatz, setzt es auf die Funktionen von Libvirt und baut so auf eine erprobte Technologie, anstatt eigene Methoden zum Starten und Stoppen von VMs zu implementieren. Ähnliches gilt für andere Hypervisor-Implementierungen, von denen Nova mittlerweile einen ganzen Reigen unterstützt: Neben KVM gehören beispielsweise Xen, Microsoft Hyper-V und auch VMware zu den Zielplattformen.

Ähnliche Artikel

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