Open Source im professionellen Einsatz
Linux-Magazin 04/2015
© Markus Feilner, BY-CC-SA 4.0

© Markus Feilner, BY-CC-SA 4.0

Open-Stack-Updates im Alltagstest: Ein Selbstversuch

Von Stapel zu Stapel

Bei Open Stack stapeln sich die Dienste hoch und mit ihnen die Abhängigkeiten. Vor allem Upgrades bereiten Admins Kopfzerbrechen: Ist es überhaupt möglich, Open Stack sinnvoll zu aktualisieren? Und wie verhalten sich die kommerziellen Open-Stack-Produkte? Das Linux-Magazin hat getestet.

1522

Im laufenden Betrieb ist Open Stack recht problemlos. Kritisch wird es erst in dem Moment, in dem ein Unternehmen von einer Version von Open Stack auf die nächste Version aufrüsten möchte. Die erscheinen gleich zweimal pro Jahr, und an Upgrade-Pfade hat die Community offenbar in der Vergangenheit wenige Gedanken verschwendet. Das Linux-Magazin hat den Versuch gemacht und sowohl ein selbst gestricktes Setup als auch die fertigen Lösungen der diversen Open-Stack-Distributionen Upgrades unterzogen. Am Ende stand vor allem eine Erkenntnis: Leicht geht anders.

Die Sinne schärfen

Um zu verstehen, warum Admins Angst vor Open-Stack-Updates haben, ist ein kleiner Ausflug in die Geschichte des Projekts hilfreich. So alt ist das Projekt ja noch gar nicht: Zum ersten Mal sinnvoll einsetzen ließ sich Open Stack Essex, die damalige Version 2012.1, und selbst die besaß noch diverse Ecken und Kanten. Interessanterweise ist Essex jene Version von Open Stack, die Ubuntu 12.04 als Default beilag, sodass sich Installationen mit dieser Open-Stack-Version bis heute regelmäßig finden.

Die Plattform bestand damals im Wesentlichen aus den Komponenten, die für den elementaren Betrieb nötig waren:

  • Keystone, der Authentifizierungsdienst
  • Nova, das virtuelle Maschinen verwaltet
  • Glance für die Imageverwaltung
  • Swift, der Open-Stack-Objektspeicher
  • Horizon, das Webinterface von Open Stack

Bekanntlich bildeten sich im Essex-Nachfolger Folsom noch zwei weitere Komponenten heraus, die beide aus Nova herausgelöst wurden: Quantum, das in Open Stack echte SDN-Funktionalität brachte, und Cinder, das zuvor als »nova-volume« die Verwaltung von dynamischen Blockspeichern für VMs in der Cloud leistete. Quantum heißt mittlerweile Neutron, ist aber immer noch der gleiche Dienst mit der selben Intention.

Die sieben Kernkomponenten sind heute: Keystone, Glance, Nova, Horizon, Neutron und Cinder sowie Swift, wenn der Admin einen Objektspeicher betreiben möchte. Die Kenntnis der Struktur ist wichtig, denn sie macht Blick auf das Wesentliche frei: Wer ein Update von einer Open-Stack-Version auf die nächste plant, sollte sich zunächst mit den Kernkomponenten befassen.

Nun ist es nicht so, als würde Open Stack der Nimbus einer ordentlich und sinnvoll zu aktualisierenden Lösung anhaften. Ganz im Gegenteil: Noch vor zwei Jahren hatten die Open-Stack-Entwickler kein größeres Problem damit, von einer Version zur nächsten die APIs ohne jede Vorwarnung durch neue Versionen zu ersetzen. Auch die Kommandos und die Parameter der Open-Stack-CLIs veränderten sich regelmäßig, freilich ohne dass jemand die Dokumentation angepasst hätte. So war ein Wartungsfenster zum Open-Stack-Upgrade für Admins ohne Staging-Setups im Grunde stets wie ein Sprung ins kalte Wasser.

Erfreulich ist, dass die Entwickler mittlerweile deutlich behutsamer bei der Einführung neuer Funktionen vorgehen. API-Versionen verschwinden nicht mehr einfach so aus Open Stack und die Einführung neuer API-Versionen wird über mehrere Versionen hinweg vorbereitet. Damit ein neues API in Open Stack ein altes ersetzen kann, muss das alte für mindestens eine Release ausdrücklich als "Deprecated" markiert sein.

Ähnlich verhält es sich bei den Kommandozeilen-Werkzeugen: Hier ersetzen die Entwickler entweder vorhandene Programme durch neue, die zeitgleich mit ihren Vorgängern installiert sein können. Oder sie dokumentieren die Änderungen so ausführlich, dass für Admins schnell ersichtlich ist, was nun anders funktioniert als vorher.

Heute besser in Schuss

Auch ihre Tools unter der Haube haben die Open-Stack-Entwickler besser im Griff als vor zwei Jahren. Besonders gut merken Admins das an den Schemata der Dienste, die MySQL betreffen. Die meisten Open-Stack-Dienste sind im Hintergrund an MySQL angebunden, um dort ihre eigenen Metadaten abzulegen. Zwischen zwei Open-Stack-Versionen ändert sich da so einiges, indem Tabellen vorhandene Spalten verlieren oder neue Spalten hinzubekommen.

Es wäre aber unpraktikabel, dem Admin das händische Pflegen der MySQL-Datenbanken als regelmäßige Aufgabe umzuhängen. Deshalb kommt jede Kernkomponente von Open Stack, die von dem Problem betroffenen ist, mit einem eigenen Werkzeug. Merkt der jeweilige Dienst beim ersten Start nach dem Update, dass das vorhandene Datenbankschema zu einer älteren Version gehört, tritt er ein Update der Datenbank in MySQL eigenhändig an. Danach läuft er weiter, als sei nichts gewesen.

Trotz aller Prozessverbesserungen bleibt ein Open-Stack-Update problematisch und voller Fallstricke, in denen sich Admins verheddern. Am Ende weist jedes Open-Stack-Setup spezifische Eigenheiten auf, die nicht zum Lieferumfang der eigenen Distribution gehören. Besonders oft finden sich etwa lokale Modifikationen beim Neutron-Netzwerkstack. Nicht alle Hersteller von SDN-Lösungen haben ihren Code nämlich bereits in Neutron integriert. Wer zum Beispiel Open Contrail mit Juniper-Hardware einsetzt, braucht dafür ein externes Neutron-Plugin des Herstellers.

Andere Beispiele für lokale Modifikationen sind Storage-Treiber, die nicht Bestandteil von Open Stack Cinder sind. Alle Anbieter von Open-Stack-Distributionen betrachten bei ihren Upgrade-Zyklen lediglich das Standardsetup. Wenn eine Vorgängerversion sich problemlos aus der Defaultkonfiguration auf die nächste Version bringen lässt, gilt der Test des Upgrade als bestanden. Für Admins ist es deshalb von großer Bedeutung, vor einem Upgrade eine Liste zu führen: Welche Komponenten gehören zum Setup, sind aber nicht offizieller Teil des Release-Zyklus? Welche Komponenten sind an das Setup angehäkelt? Sind Automatisierungen angeflanscht (Kasten "Automatisiertes Update").

Automatisiertes Update

Wenn Admins sich mit Open Stack beschäftigen, interessieren sie sich früher oder später für eine der verfügbaren Automatisierungslösungen. Zwar ist ein alleinstehendes Setup mit wenigen Knoten noch halbwegs erträglich mit der Hand zu pflegen. Doch produktive Setups mit Dutzenden Computing-Knoten sind ein anderes Kaliber; hier ist Automatisierung unumgänglich.

Schwankende Qualität

Die Integration von Open Stack in Automatisierer wie Puppet oder Chef schwankt in ihrer Qualität erheblich (Abbildung 1). Hier zeigt sich, dass Open Stack ein Community-Projekt ist: Einzelne Facetten deckt die Lösung dann ab, wenn es Hersteller gibt, die sich für ein Thema speziell interessieren. Genau jene investieren dann Geld, um Entwickler für die Arbeit an einem Aspekt zu bezahlen. Die Open-Stack-Puppet-Module sind dafür ein hervorragendes Beispiel, denn diese sponsert seit Jahren ein französisches Unternehmen.

Abbildung 1: Automatisierte Setups setzen intelligente Updatestrategien voraus. Dabei helfen Puppet und Chef.

Das bedeutet jedoch nicht automatisch, dass die Module zu jedem Zeitpunkt in einem guten Zustand wären. Fast noch schlimmer ist jedoch, dass die Open-Stack-Module für Puppet bis zur aktuellen Version ein gutes Beispiel für mangelnde Upgrade-Fähigkeit waren. Beim Update von einer Open-Stack-Version zur nächsten ändern sich unter Umständen Konfigurationsparameter oder es kommen Optionen hinzu, für die neue Puppet-Module notwendig sind. Den Wechsel von Icehouse zu Juno haben die Puppet-Open-Stack-Entwickler aber richtig gut hingekriegt: Site-Manifeste, die für Icehouse gültig waren, brauchten für Juno-Support höchstens kleine Änderungen.

Ähnliches gilt für Chef: Seit Suse und Dell die Chef-Integration merklich vorantreiben, lässt sich Open Stack damit brauchbar deployen. Auch hier ist im Falle eines Upgrade aber das Warten auf neue Cookbooks normal – und wie im Puppet-Beispiel gibt es regelmäßig nervige Kinderkrankheiten.

Egal was eine Plattform zur Automatisierung nutzt: Wenn das Update von einer Open-Stack-Version auf die nächste ansteht, sind Puppet oder Chef stets erste Wahl. Idealerweise unterstützt die gesamte Automatisierungs-Infrastruktur die neue Open-Stack-Version bereits vor der Installation der ersten neuen Pakete.

Im Selbstversuch hat sich das Linux-Magazin zunächst mit dem Upgrade einer Ubuntu-Cloud (Abbildung 2) beschäftigt, wobei "Ubuntu-Cloud" in diesem Falle nicht das Produkt bezeichnet. Gemeint ist eine Cloud aus Ubuntu-Installationen, die mit den Open-Stack-Paketen der Distribution ausgestattet sind. Komponenten wie MaaS und Juju haben beim Vorgang also keine Rolle gespielt, wenigstens MaaS wäre als Komponente aber sowieso außen vor. Denn MaaS kümmert sich ja vor allen Dingen um das Deployment von Blech.

Abbildung 2: Ubuntu ist in Sachen Upgrades sehr unkompliziert, auch weil Canonical Upgrades testet.

Nachdem die Tester die Infrastruktur zunächst in einen Upgrade-fähigen Zustand versetzt hatten, folgte die Aktualisierung der Puppet-Manifeste auf dem Puppet-Master. Es hat sich als sinnvoll herausgestellt, alle durch Puppet induzierten Änderungen vor dem eigentlichen Open-Stack-Upgrade auf den Rechnern zu deployen.

Im Falle von »nova-compute« , also der Computing-Komponente von Nova, führte das zwar zum Absturz sämtlicher Instanzen innerhalb des gesamten Clusters. Das war allerdings zu verschmerzen, denn auch dann, wenn »nova-compute« abstürzt, laufen die zunächst durch jenen Dienst gestarteten VMs weiter. Der Absturz von »nova-compute« führt also nicht zu einer Downtime, die der Kunde bemerkt. Ähnliches gilt auch für alle anderen Open-Stack-Komponenten in gleicher Weise.

Im Anschluss an das Deployment der Konfigurationsänderungen folgt ein sehr unspektakuläres »apt-get dist-upgrade« auf allen Hosts. Zuvor hatten die Tester sichergestellt, dass die Paketquellen in »/etc/apt/sources.list.d« Einträge für die nächste Open-Stack-Version enthielten. Spezifisch also für das Juno-Repository des Ubuntu-Server-Teams.

Insgesamt hat das Upgrade dieser Konstellation deutlich weniger Reibereien verursacht, als die Tester im Vorfeld erwartet hatten (Abbildung 2). Am Ende des Vorgangs stand eine Open-Stack-Cloud in der Juno-Version, die ihren Dienst zuverlässig wie ihre Vorgängerin verrichtete. Der Vollständigkeit halber sei angemerkt, dass das Testsetup auf zehn Knoten beschränkt war. Ob das Upgrade von Hunderten oder gar Tausenden Knoten ähnlich reibungslos verläuft, lässt sich daraus freilich noch nicht ablesen. Offenkundige Gründe, daran zu zweifeln, zeigten sich jedoch beim Test nicht.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 4 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Suse stellt OpenStack Cloud 5 vor

    Mit einer Namensänderung geht die Version 5 der vormals als Suse Cloud bekannte Suse Open Stack Cloud einher.

  • Open-Stack-Workshop

    Dass Open Stack in aller Munde ist, bedeutet nicht, dass es überall installiert ist. Die für eigene Anwendungsfälle richtigen Komponenten auszuwählen und das Setup des Stapels erweisen sich als hochkomplex. Mit diesem Artikel startet ein dreiteiliger Workshop, der Admins fit für die Open-Stack-Praxis macht.

  • Test

    Mehrere Hersteller versprechen Open-Stack-Lösungen fürs Enterprise. Das Linux-Magazin hat einen genaueren Blick auf die On-Premise-Angebote von Red Hat, Suse, Ubuntu, Mirantis und HP geworfen. Die haben vieles gemeinsam, aber auch einige Unterschiede.

  • Open Stack Juno

    Open Stack will im ganz großen Geschäft mitspielen und muss deshalb liefern. Die neue Version 2014.2 alias Juno räumt auf und leistet Modellpflege – von einer großen Neuerung abgesehen: Ironic, das Baremetal-Deployment-Tool, das wohl auf dem Sprung zur offiziellen Komponente ist.

  • Open Stack

    Auf dem Höhepunkt des Hype versprechen die Anbieter von Open-Stack-Produkten potenziellen Kunden eine eierlegende Wollmilchsau – doch geliefert wird meist nur eine lahme Ente.

comments powered by Disqus

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.