Für die Mai-Ausgabe hat sich IT-Administrator den Schwerpunkt 'Messaging & Collaboration' auf die Fahnen geschrieben. Lesen Sie darin, wie Sie die Open ... (mehr)

Interaktiv virtualisieren

Auch OpenStack Nova bekommt einige neue Funktionen spendiert, davon ist die “Callback-API” wohl die bedeutsamste. Die Nova-API hatte bis dato maßgeblich die Funktion, das Starten oder Stoppen einer virtuellen Maschine zu ermöglichen. Nach dem Start der VM war Novas Arbeit erledigt – jedenfalls ermöglicht es Nova bis dato nicht, auch nach dem Start einer VM direkt mit den virtuellen Systemen zu kommunizieren oder Veränderungen daran vorzunehmen. Das ist unpraktisch, wenn der IT-Verantwortliche etwa möchte, dass seine virtuelle Maschine mehr als nur einen Netzwerkanschluss hat und dass die beiden Netzwerkports auch noch in unterschiedlichen privaten Netzen beheimatet sein sollen. Dies bedeutete bisher stets einen Reboot.

 

 Die “Callback-API” löst dieses Problem, indem sie anderen Komponenten in OpenStack das nachträgliche Ändern der Konfiguration einer VM erlaubt. Das genannte Beispiel der Netzwerkports ist ein Szenario, denkbar wäre aber auch, dass von einer VM ein Snapshot in Cinder zu erstellen ist: Nova würde in diesem Falle auf Zuruf des Admins Cinder Bescheid geben und danach blockieren, damit sich die VM nicht zum “Moving Target” entwickelt. Sobald Cinder fertig ist, sendet es eine entsprechende Nachricht an Nova, das weiß, dass es die Blockade nun beenden kann. Die Callback-API verdeutlicht den OpenStack-Trend, die einzelnen Komponenten immer stärker miteinander zu verweben und interaktiver zu implementieren. Der tatsächliche Nutzen dieser Tendenz ist bis dato nur zu erahnen. In Icehouse hält ein solches Feature jedenfalls zum ersten Mal Einzug in OpenStack.

IPv6 und SDN in Neutron

Ziemlich viele Neuerungen erhält erwartungsgemäß OpenStack Neutron. Die für Software Defined Networking (SDN) zuständige Komponente ist berühmt, weil sie viele SDN-Funktionen sinnvoll implementiert. Gleichzeitig ist sie aber auch berüchtigt, besonders bei Cloud-Neulingen: Die Lernkurve ist immens, und viele bekannte Netzwerk-Konventionen wirft Neutron kurzerhand über den Haufen. Viele Cloud-Admins dürften vom regen Treiben bei Neutron also nicht sehr begeistert sein, denn mehr Funktionalität bringt zwangsläufig auch mehr Komplexität.

 

 In Icehouse stand offenbar das Thema IPv6 auf der Tagesordnung. Bis dato war die IPv6-Unterstützung praktisch nicht vorhanden; das ist nun anders: Neutron wird IPv6-Netzwerke in Zukunft so verwenden können, wie es bei IPv4-Netzwerken schon bisher der Fall war. Über Routing Advertisement wird es ebenso möglich sein, virtuelle Maschinen direkt mit einer IPv6-Adresse anzubinden. Die Neutron-Entwickler räumen damit ein großes Hindernis insbesondere für Unternehmen aus dem Weg: Weil schon jetzt absehbar ist, dass IPv6 ein immer wichtigeres Thema werden wird, haben einige Unternehmen IPv6-Fähigkeit als “Must Have”-Feature für Software fesgelegt. Ein Werkzeug, das diese Bedingung nicht erfüllt, hat also keine Chance. In Zukunft wird fehlende IPv6-Unterstützung aber wenigstens für OpenStack kein Problem mehr sein.

 

 Wer die Technik von Neutron bereits kennt, muss für Icehouse zumindest zum Teil umdenken: Dafür sorgt die zweite große Neuerung in der SDN-Komponente. Denn mit OpenStack Icehouse gilt das alte Open vSwitch-Modul offiziell als “deprecated”; im Juno-Release, das Icehouse im Oktober folgen wird, dürfte es gänzlich fehlen. Ausschlaggebend dafür sind Veränderungen, die sich bereits in der vorherigen Version Havana angekündigt haben: Dort erstellten die Neutron-Entwickler ein neues Framework, das letztlich aus einer ganz ähnlichen Motivation entstanden ist wie das gesamte Oslo-Projekt: Es geht darum, Code-Redundanzen zu verhindern. Früher implementierte praktisch jedes Modul seine eigenen Grundfunktionen; dass es dabei zu einigen doppelten Umsetzungen kam, leuchtet ein. Das “Modular Layer 2”-Framework umgeht dieses Problem, in dem es über eine API Grundfunktionen anbietet, die sich sämtliche Module zunutze machen können. In Havana war die Mehrzahl der Neutron-Module bereits auf ML2 portiert, in Icehouse gehen die Entwickler nun konsequent vor und bereiten die Entfernung des Nicht-ML2-Plug-Ins für Open vSwitch vor. Fast schon grotesk mutet es hingegen an, dass der Netzwerk-Opa “nova-netwrk” trotz mehrmaliger Ankündigung auch in Icehouse noch nicht “deprecated” sein wird; die Entwickler rechnen derzeit damit, dass die aus Urzeiten mitgeschleppte und Neutron hoffnungslos unterlegene Implementation noch mindestens 12 bis 18 Monate Teil von OpenStack sein wird.

 

 Icehouse ist auch die erste OpenStack-Version, in der der Neutron-Dienst rudimentäre Unterstützung für “Regions” hat. Regions kommen in OpenStack bis dato zum Einsatz, um einzelne Computer anhand von spezifischen, zuvor festgelegten Eigenschaften logisch zusammenzufassen. Neutron ignoriert die Region-Zugehörigkeit von Diensten bis dato aber vollständig. Mit Icehouse bietet sich für einzelne Ports in Neutron wenigstens die Möglichkeit, ein “Region”-Flag in die Datenbank zu schreiben, anhand dessen sich die Region eines Ports sicher ablesen lässt.

Bild 2: In Icehouse wurde die Docker-Integration in OpenStack weiter ausgebaut

Nicht zuletzt haben viele Neutron-Plug-Ins ein Makeover erhalten oder feiern den offiziellen Einzug in Neutron. Dazu gehört ein Brocade-ML2-Plug-In genauso wie ein Plug-In für Bigswitch. Open Daylight spricht Neutron in 2014.1 obendrein – für SDN-Admins steht also wieder Büffelei an.

 

 Viele der Veränderungen in Neutron und Nova bedingen Anpassungen in Horizon, dem Webinterface oder “Dashboard”. Hier haben die Dashboard-Entwickler klar auf Kontinuität gesetzt: Für Features, die in Havana bereits vorhanden waren, bringt das Icehouse-Dashboard weitergehende Funktionalität. Das VPNaaS-Plug-In erhält ebenso ein Update; in Horizon lassen sich nun außerdem die “Flavors”, also vorkonfigurierte Profile für VM-Hardware, besser editieren.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
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

Google+

Ausgabe /2019