Ceilometer misst die Leistung

Die Metering-Komponente von Open­Stack, die auf den Namen Ceilometer getauft ist, hat in der OpenStack-Community so manchen Feind. Seit die Komponente in die OpenStack-Familie aufgenommen worden ist, haben verschiedene Entwickler ein ums andere Mal die Architektur der Lösung kritisiert. Zu statisch, zu komplex und zu langsam sei Ceilometer etwa, um in wirklich großen Umgebungen effizient nutzbar zu sein. Obendrein bombardiert der Ceilometer-Collector, der bei den einzelnen OpenStack-Diensten seine Messdaten einsammelt, jene Dienste regelmäßig und gern mit Queries – was zu zusätzlicher Last führt.

Niemand Geringeres als Julien Danjou, einer der ursprünglichen Autoren von Ceilometer, erläutert die Nachteile von Ceilometer in einem Blog-Post [2] in epischer Breite. Doch hat er sich zusammen mit dem Ceilometer-Team auch eine Lösung für das Problem ausgedacht: Anstelle der bisherigen Art soll die Komponente künftig ihre Daten in einer eigenen Datenbankkomponente namens Gnocchi ablegen. Das Prinzip folgt dem einer "Time Series Database", bei dem vorhandene Daten anhand eines Zeitstempels sortiert werden. Davon erhoffen sich die Ceilometer-Entwickler weitreichende Performance-Gewinne und deutlich effizienteres Speichern der Metrik-Daten insgesamt. Tatsächlich hat der Umbau von Ceilometer hin zu Gnocchi Fortschritte während des Release-Zyklus von Kilo gemacht, doch wähnen die Entwickler ihr Projekt noch nicht in einem Zustand, den sie fertig nennen würden. Das dürfte erst in der nächsten Version von OpenStack der Fall sein.

Weitere Kleinigkeiten

Fernab der Änderungen bei den großen Komponenten haben sich viele kleinere Changes bei den umliegenden Open­Stack-Komponenten angesammelt. Trove, das in OpenStack Database as a Service (DBaaS) realisieren soll, kann nun auch mit CouchDB und DB2 umgehen. Heat, die OpenStack-Orchestrierungslösung, hat nun in Form von "Convergence" die Möglichkeit, das Anlegen von Stacks auf multiple Instanzen der "heat-engine"-Komponente zu verteilen. Jene ist verantwortlich dafür, dass die in einem Heat-Template festgelegten Ressourcen am Ende auch in der echten Cloud laufen. Cinder kann persistente iSCSI-Volumes nun deutlich sinnvoller über iSCSI-Multipathing ansprechen. Und wer ein Storage-Backend mit Support für Thin Provisioning nutzt, kann dieses künftig in Cinder auch über Overcommitment künstlich vergrößern.