Neuerungen im Havana-Release von OpenStack

foodandmore, 123RF

Cuba Libre

Im Oktober war sie fällig, die Havana-Release von OpenStack, die die erfolgreiche Geschichte der Cloud-Umgebung fortschreiben soll. Hat sie das Zeug dazu oder handelt es sich um einen Rohrkrepierer? Dieser Beitrag wirft einen ersten Blick auf die wichtigsten Neuheiten.
Termine planen, Nachrichten austauschen, Kundendaten verwalten, am besten auch vom Smartphone aus. Das alles und noch viel mehr sollen moderne ... (mehr)

Wer dem OpenStack-Projekt beim Entwickeln zuschaut, könnte fast neidisch werden: Das Projekt versteht es ausgezeichnet, den selbst auferlegten Zeitplan fast sklavisch zu befolgen. Pünktlich im Oktober erschien OpenStack 2013.2 alias Havana. Wer das letzte Release »Grizzly« aufmerksam verfolgt hat, weiß: Grizzly war eigentlich ein Maintenance-Release für die Vorgänger-Version Folsom (2012.2), das maßgeblich dazu diente, in Folsom eingeführte Funktionen zu stabilisieren und auszubauen. Das Release galt als wenig innovativ, was manchem OpenStack-Admin aber so schlecht gar nicht gefallen haben dürfte. Denn das Update von Essex auf Folsom ein halbes Jahr zuvor hatte mehr Scherben produziert, als es dem OpenStack-Projekt lieb sein konnte. Die Modell-Pflege in Grizzly hob sich davon wohltuend ab. Nun also Havana – handelt es sich um ein weiteres Wartungs-Release oder haben die Entwickler diesmal mehr Mut bewiesen und tatsächlich neue Funktionen eingebaut? Der folgende Test sieht genauer hin und zeigt, was OpenStack Havana ausmacht.

Metering mit Ceilometer

Dass sich in Havana mehr verändert hat als zwischen Folsom und Grizzly, fällt bereits durch die beiden neuen Komponenten auf, die in Havana zum OpenStack-Kern gehören: Ceilometer und Heat. Dabei ist anzunehmen, dass Ceilometer im Alltag des OpenStack-Cloud-Anbieters in absehbarer Zeit deutlich mehr Relevanz zukommen wird als Heat. Denn in Form von Ceilometer hat erstmals eine umfassende Metering-Lösung Einzug gehalten, die genaue Statistiken über die genutzten Ressourcen einzelner Kunden bietet.

Dabei ist es keineswegs so, dass das Thema Metering in OpenStack bis dato völlig unbeachtet gewesen wäre. Denn die Computing-Komponente Nova konnte bereits in früheren Versionen grundlegende Statistiken zur Nutzung durch einzelne Tenants anlegen. Allerdings waren die gewonnenen Daten im Anschluss lediglich über das Dashboard – also das OpenStack-Web-Interface – überhaupt auslesbar. Überdies waren auch die messbaren Parameter auf grundlegende Werte beschränkt. Für Cloud-Anbieter ist das ein Problem: Das deutsche Recht verlangt von Anbietern nämlich, dass diese für On-Demand-Dienste detaillierte und notfalls gerichtsverwertbare Nachweise darüber liefern, welche Dienste ein Kunde tatsächlich in Anspruch genommen hat. Wenn eben solche Nachweise fehlen, können Kunden gegebenenfalls die Rechnung beanstanden und der Anbieter bleibt auf seinen Kosten sitzen. Viele Cloud-Anbieter in Deutschland sind mittlerweile allein aufgrund dieser Tatsache auf die pauschalen Flatrate-Angebote ausgewichen, geben so aber natürlich einen großen Teil der Flexibilität auf, die eine Cloud eigentlich bietet.

Mit Ceilometer soll in OpenStack nun alles besser werden. Der Dienst ist nicht neu, er hat den OpenStack-typischen Weg durchlaufen, war also zuerst ein externes Projekt. Kurz vor der Grizzly-Release wurde er dann zur »Integrated Component« , was zwar noch nicht dem Status einer völlig integrierten Kernkomponente gleichkommt, aber die Vorbereitungsstufe dazu ist. In Havana machen die Ceilometer-Entwickler ernst: Nun ist Ceilometer offizielle Core-Komponente und somit reif für den echten Cloud-Alltag.

Metering-Technik

Ceilometer (Abbildung 1) setzt unter der Haube auf das schon erprobte Design einer modularen Grundstruktur, die viele OpenStack-Komponenten nutzen. Der zentrale Dreh- und Angelpunkt der Lösung ist eine Datenbank, ab Werk empfehlen die Ceilometer-Entwickler MongoDB. Auch MySQL und PostgreSQL sowie HBASE unterstützt Ceilometer aber ausdrücklich. Zur Datenbank gehört der Ceilometer Collector, der die Nutzungsdaten der verschiedenen OpenStack-Dienste in die Datenbank schreibt. Jedoch organisiert sich der Collector diese Daten nicht selbst, er lagert die Aufgabe stattdessen an sogenannte Agents aus. Diese lassen sich über Konfigurationseinträge mit den anderen OpenStack-Komponenten verbinden, Nova, Neutron & Co zeichnen Nutzungsdaten dann regelmäßig auf, um sie über die Agents an den Collector weiterzugeben. Schließlich sorgt die Ceilometer-API dafür, dass das für OpenStack obligatorische ReSTful-Interface zur Verfügung steht, über das sich externe Anwendungen mit dem Dienst verbinden und dessen Informationen auslesen können.

Abbildung 1: Ceilometer ist OpenStacks künftige Metering-Lösung, die auch Billing-Applikationen zulässt. Eine fertige Billing-Lösung fehlt derzeit aber noch.

Ceilometer ist für sich genommen freilich noch keine Billing-Lösung. Denn der Dienst ist nicht darauf ausgelegt, die gesammelten Daten direkt im Anschluss weiterzuverarbeiten – darauf haben sich die Entwickler des Dienstes nach langen Diskussionen verständigt. Ceilomter ist eine reine Metering-Applikation, die ihre Daten grundsätzlich für jegliche anderen Dienste anbieten kann. Damit aus Metering Billing wird, fehlt also noch eine Anwendungen, die Ceilometer-Daten entsprechend nutzt.

Ein vielversprechender Ansatz zur Lösung dieses Problems ist der noch im Alpha-Stadium befindliche BillingStack [1], der genau diese Aufgabe wahrnehmen soll. Wer schon eine eigene Billing-Lösung hat, kann die über die ReSTful-API von Ceilometer aber gegebenenfalls auch selbst an OpenStack anbinden, wenn ein bisschen Handarbeit kein Problem ist. Belohnt werden Unternehmen dann mit der Möglichkeit, jeden auch noch so unscheinbaren Wert aufzuzeichnen, etwa die Zahl der VMs eines Kunden oder die Zahl der Netzwerkpakete, die dieser verbraucht hat. Oder die Zahl der Volumes und deren Gesamtgröße. Die Zahl der aktiven Images, die Zahl der genutzten Floating-IP-Adressen und viele andere Labels bietet Ceilometer beim Messen an. In Form von Ceilometer erhalten mit OpenStack betriebene Clouds jedenfalls ein überaus mächtiges Tool für statistische Betrachtungen.

Ä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