© Markus Feilner, CC-BY-SA 4.0

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 gilt als das Linux der Cloud, und beim Thema Enterprise-Linux denkt jeder Admin sofort an zwei Farben: Rot und Grün, Red Hat oder Suse. In Sachen Open Stack gibt es aber mehr Bewerber.

Den Anfang macht Suse

Der Artikel untersucht die fünf wichtigsten Open-Stack-Anbieter und unterzieht sie einem Vergleichstest. Zuerst stellt er Suse [1] und Red Hat [2] gegenüber, schildert dann den Ubuntu-Ansatz [3] und abschließend, was Mirantis [4] und HP Helion [5] anders machen wollen.

Wer Suse Cloud ausprobieren will, benötigt zunächst ein Benutzerkonto im Suse Customer Center. Die Registrierung dort ist etwas lästig, aber nicht vermeidbar. Der Account hat drei Funktionen: Da ist einmal die Registrierung des Test-Abos von Suse Cloud auf den Benutzer. Gleichzeitig schaltet dies den Zugriff auf die notwendigen Patches und Updates frei, dafür muss man den Rechner selbst im SCC anmelden. Funktion Nummer drei ist der Zugriff auf die Software selbst.

Drei ISO-Images

Die kommt in Form von drei ISO-Abbildern. Für den reinen Betrieb ist nur eines nötig. Die anderen beiden enthalten den Quelltext und die so genannten Debuginfo-Pakete. Beim Herunterladen der Software kann der Anwender einen Registrierungscode anfordern, was in den Labortests des Linux-Magazins leider nicht immer klappte. Da musste dann der Linux-Distributor aus Nürnberg einspringen und lieferte die fehlenden Daten.

Wer sich sowieso für den Kauf entschieden hat, erhält die Schlüssel über die üblichen Kanäle. Die ersten (notwendigen) Schritte zum Aufbau der eigenen Wolke mit Suse Cloud verliefen im weiteren Test erfreulich schmerzfrei und waren auch gut dokumentiert.

Red Hat vs. Suse

Das Vorgehen beim Marktführer Red Hat erscheint analog zu Suse. Zunächst ist ein gültiges Konto im Red-Hat-Kundenportal nötig, dem Quasi-Nachfolger des RHN (Red Hat Network). Auch hier dient dieses Konstrukt zum Herunterladen der Software, dem Zugriff auf Updates und Patches und natürlich der Registrierung des Software-Abos auf den Anwender. Anders als bei den Nürnbergern gibt es keine ISO-Abbilder mehr für die Open-Stack-Komponenten.

Ein entsprechend vorbereitetes RHEL 7 holt und installiert die Pakete über den eingebauten Paketmanager Yum. Der Red-Hat-Kundenaccount dient zum Freischalten der entsprechenden Softwareverzeichnisse (Repositories) beim Distributor. Natürlich muss der Rechner entsprechend bei Red Hat registriert sein. Ein Registrierungsschlüssel für das Testabo entfällt, beim Anfordern muss der Anwender sein Benutzerkonto bei Red Hat angeben. Die Zuordnung der Subskription übernehmen die Rothüte im Hintergrund. Das Vorgehen ist identisch zu dem Fall, wenn man das Red-Hat-Produkt ganz offiziell bestellt.

Mit einer bestehenden VMware-Infrastruktur ist der Test über eine bereits vorgefertigte Appliance möglich. In jedem Fall sind die ersten Schritte wie bei Suse gut und übersichtlich dokumentiert. Abhängig von den Vorkenntnissen kann der Start mit Red Hat Enterprise Linux Open Stack Platform (RHELOSP) vollkommen unterschiedlich verlaufen – für den Erfolg des Produkts ist gute Dokumentation unerlässlich. Das gelingt den Rothüten sowohl für die ersten Schritte wie auch bei den ausführlicheren Informationen für später. Red Hat beachtet dabei die Rollen innerhalb des Wolken-Betriebs: Da ist einmal der Endanwender, der Verwalter der Cloudsoftware und natürlich der Administrator an sich.

Unterschiede bei der Doku

Zudem unterscheidet man in Raleigh zwischen einer Produkt-Evaluierung und der Installation im Enterprise-Umfeld. Diese Unterscheidung schlägt sich auch in unterschiedlichen Dokumenten zur Installationsbeschreibung nieder. Zudem gibt es noch Anleitungen, wie man das Eval-Setup manuell durchführt. Dabei sind keine Open-Stack-relevanten Vorkenntnisse nötig. Ein kompletter Start auf der grünen Wiese ist also möglich. Wer schon entsprechendes Wissen hat, kann sich an der Wiederholung erfreuen oder die Kapitel überspringen. Wer unbedarft mit der Suse Cloud starten will, kann ebenfalls auf ausreichend Dokumentation zurückgreifen. Wie die Rothüte reflektiert auch der Linux-Distributor aus Nürnberg die verschiedenen Rollen innerhalb der Wolke.

Neben einer Installationsanleitung finden sich Dokumente für die Administratoren der Suse Cloud und für die Endanwender. Dabei kann der Benutzer zwischen HTML, PDF oder dem freien E-Book-Format EPUB wählen. Open-Stack-Vorkenntnisse sind zwar hilfreich, aber nicht nötig, Suse holt den Benutzer beim Stand null ab. Kenner der Szene sehen sich mit Redundanzen zur Open-Stack-Dokumentation konfrontiert, es ist aber sehr angenehm, wenn alle notwendigen Informationen an einem Platz vorliegen. Ein Verweis auf die entsprechenden Hilfe-Seiten von Open Stack könnte hier eher verwirrend wirken.

Die Releasezyklen von Open Stack sind eine Herausforderung für die klassischen Enterprise-Distributoren. Hier stehen sechs Monate Releasezyklus einer Distributions-Laufzeit von zehn und mehr Jahren gegenüber. Der Linux-Distributor passt sich mit seiner Cloudlösung dem Open-Stack-Projekt an. Version 3 – basierend auf Havana – kam im Februar 2014 heraus und fällt ein Jahr später aus dem Support. Die aktuelle Variante 4 basiert auf Icehouse und gilt bis Ende August 2015 als unterstützt. Danach kommt Suse Cloud 5 zum Zuge, deren Unterbau Open Stack Kilo sein wird.

Die minimalistische Version von Suse Cloud erfordert drei Rechner (siehe Abschnitt über die Installation). Die verbundenen Kosten betragen gut 11  000 Euro pro Jahr. Enthalten ist der so genannte Prioritätssupport. Suse gewährt hier Unterstützung zu jeder Tages- und Nachtzeit mit einer Antwortgarantie innerhalb von einer Stunde. Die Abos für den darunterliegenden Suse Linux Enterprise Server sind ebenfalls enthalten. Beim Schreiben es Artikels entspricht dies einer gültigen Subskription für SLES 11 SP3.

Für zusätzliche Rechner muss der Benutzer wieder in die Tasche greifen. Für jeden so genannten Controller sind 3000 Euro und pro Compute-Rechner knapp 1000 Euro nötig. Für Letztere rechnet Suse pro CPU-Paar auf einem physischen Server ab. Dazu kommen noch die Kosten für das zugrunde liegende Betriebssystem. Dabei spielt es keine Rolle, ob KVM oder Microsoft Hyper-V den Hypervisor macht. Für die Integration in eine VMware-Umgebung ist mindestens Version 5.1 des V-Center nötig.

Weil keine Wolke ohne entsprechende Kapazitäten für die Datenablage funktioniert, greift, wer komplett grün bleiben will, auf das neue Produkt Suse Storage Server [6] zurück. Das ist natürlich nicht kostenfrei. Zum gegenwärtigen Zeitpunkt stehen für 6000 Euro 36 TByte im Raum.

Verwirrung um rote Preise

Die deutlich unterschiedlichen Releasezyklen des hauseigenen Enterprise-Linux und der Open-Stack-Versionen bei Red Hat sind genauso vorhanden wie bei Freunden des Chamäleons. Als dieser Artikel entstand, war Version 5 von Red Hat Enterprise Linux Open Stack Platform (RHELOSP, Icehouse-basiert) noch aktuell und Nummer 6 (mit Open Stack Juno) kam gerade heraus.

Momentan sieht es so aus, als würden die Rothüte versuchen die zeitlichen Support-Lücken zwischen ihrer Open-Stack-Distribution und dem Enterprise-Linux zu verkleinern. RHELOSP in Variante 3 (basierend auf Grizzly) erhielt der Kunde mit einem Jahr Unterstützung in Produktion. Die Nachfolgeversion, mit Havana-Fundament, hatte schon 18 Monate im Angebot. Für Version 5 kann man ganze drei Jahre Unterstützung bekommen. Zum gegenwärtigen Zeitpunkt ist damit also Ende Juni 2017 Schluss.

Das ist recht lange, wenn man bedenkt, dass Open Stack zu diesem Zeitpunkt schon fünf Versionen weiter sein wird. Welche Dienstleistung im Detail enthalten ist, hängt von der konkreten Vereinbarung mit Red Hat ab. Im einfachsten Fall, also etwa für eine Evaluierung, ist nur ein Rechner nötig. Auf der Betriebssystem-Seite empfiehlt sich Red Hat Enterprise Linux 7 als guter Unterbau. Prinzipiell ist auch Version 6.5 denkbar, aber nicht zukunftsorientiert.

Ein gültiges Abo für die RHEL Open Stack Platform enthält auch die Berechtigungen, das darunterliegende hauseigene Enterprise-Linux zu pflegen. Die Frage, was die Cloud aus dem Hause Red Hat kostet, ist offenbar nicht einfach zu beantworten.

Die Rothut-Variante von Open Stack ist “nur” eine Komponente von RHCI – der Red Hat Cloud Infrastructure. Zusätzlich soll der Kunde auch die Virtualisierung (RHEV), Systemverwaltung (Satellite) und Cloudmanagement (Cloudforms) kaufen. Die Preissituation scheint so kompliziert, dass selbst Red Hat eigenen Blogbeiträgen im Internet widerspricht, die von Preisen ab 3000 Euro schreiben, und auch auf beharrliche Anfragen wortreich zu schweigen versteht und keinen einzigen Preis zu Papier bringt.

Alle für einen

Wie bereits erwähnt, ist auch die Rothut-Version von Open Stack ausgesprochen gut dokumentiert. Dies gilt ebenso für die Installation. Dort findet sich sogar ein separater Eintrag für die Evaluierungsinstallation. Dessen Detailtiefe ist aber nicht unbedingt nötig. Die unter [2] hinterlegte Dokumentation reicht in vielen Fällen völlig aus. Die Rothüte listen vier Anforderungen auf: eine RHEL-7-Installations-DVD, eine Netzwerkverbindung ins Internet, einen Rechner und zirka 30 bis 45 Minuten Zeit.

Den Installationsprozess selbst unterteilt Red Hat in sechs Abschnitte. Den Anfang macht die Versorgung des Rechners mit RHEL 7. Danach registriert der Anwender das System im Kundenportal. Im dritten Schritt entfernt er die nicht benötigten Softwareverzeichnisse aus der Yum-Konfiguration. Danach erfolgt die Installation von ein paar Hilfswerkzeugen für den Paketmanager, die Justierung der Repository-Einträge und schließlich die Installation der verfügbaren Patches und Updates. Je nach Umfang der Software vergeht hier schon mal etwas Zeit. Im nächsten Schritt klemmt der Benutzer den Networkmanager ab und startet das System neu. Der letzte Schritt beinhaltet die gesamte Magie und ist in der Ausführung erschreckend unspektakulär (siehe Abbildung 1).

Abbildung 1: Installation von Open Stack in einem Rutsch – dank Packstack.

Im Hintergrund werkelt hier das auf Puppet aufsetzende Packstack ([6], auch auf der DELUG-DVD). Die Option »–allinone« erlaubt das Aufsetzen in einem Rutsch, ohne Vorüberlegungen über den zu verwendenden Platz oder das geplante Netzwerksetup. Was Einsteigern hilft, macht es aber auch erfahrenen Open-Stack-Admins einfacher: Sie können mit Packstack mehrere Rechner konfigurieren und die vorkonfigurierten Standardwerte den eigenen Bedürfnissen anpassen. Für ganz Hartgesottene gibt es sogar eine Anleitung, das Setup komplett manuell zu erledigen.

So oder so sieht sich der Benutzer am Ende einem Anmeldebildschirm (siehe Abbildung 2) gegenüber und kann loslegen. Fans des Zugangs per Shell sollten einen Blick in die Dateien »/root/keystonerc_admin« und »/root/keystonerc_demo« werfen. Dank weiterer Angebote wie dem “Red Hat Enterprise Linux Open Stack Platform Installer” oder eines mitgelieferten Cirr-OS-Image [8] ist die “rote” Installation ein erfreuliches Nicht-Ereignis, gerade angesichts des komplexen Open-Stack-Stacks.

Abbildung 2: Künftige Open-Stack-Rechner nach Red-Hat-Art warten auf ihre finale Installation.

Vorarbeiter

Der Red Hat Enterprise Linux Open Stack Platform Installer ist gewissermaßen eine Schaltzentrale zum Ausrollen von Open Stack oder nur seiner Komponenten. Im Hintergrund ist wiederum Puppet, tatkräftig unterstützt von Foreman, am Werkeln. Auf dem Admin-Server läuft ein PXE-Dienst, der die Clients bootet. (In den Labortests kämpfte das Linux-Magazin allerdings mit dem unter [9] beschriebenen Fehler.)

Darüber hinaus sollte der künftige Cloudadmin die Dokumentation ausführlich studieren, bevor es losgeht. Einmal getroffene Entscheidungen und Konfigurationen lassen sich später nicht immer korrigieren. Auch eine Live-Variante steht bereit, unklar erscheint allerdings, ob diese Methode auch mit dem RHEL-7-Unterbau eine Option bleibt. Die Festplatteninstallation fiel im Test durch intensive Nachinstallationen verschiedener Softwarepakete auf, besser verträglich scheint es, wenn der Anwender »yum -y install rhel-osp-installer« aufruft. Schließlich induziert dieses Kommando schon die spätere Verwendung als Server für das RHEL-OPS-Kontrollzentrum.

Die Benutzung des Red Hat Enterprise Linux Open Stack Platform Installer ist weitgehend intuitiv. Nach dem PXE-Boot eines Servers, findet man diesen unter »Discovered hosts« (Abbildung 2). Der nächste Schritt ist die Ausstattung mit einem Basisbetriebssystem und der Konfiguration über Puppet-Module.

Brecheisen

Wie zu Red Hat beschreibt auch Suse die Installation der Cloud sehr ausführlich und detailliert. Allerdings sind für den ersten Start ein paar Überlegungen mehr notwendig. So erwartet die grüne Cloud mindestens drei Rechner für eine Infrastruktur. Das Open-Stack-Kontrollzentrum läuft dabei separat von Compute- und/oder Storage-Knoten. Diese Trennung ist eher künstlich und für die ersten Schritte eigentlich unnötig. Der dritte Rechner ist der Admin-Server. Er hat zwei Funktionen: als PXE-Bootserver zum Installieren von SLES auf den künftigen Open-Stack-Rechnern und als Crowbar-Master.

Hardware-Anforderungen für Admin- und Kontroll-Rechner beschreibt die Dokumentation sehr detailliert. Besondere Aufmerksamkeit sollte der künftige Cloudadmin auf die Netzwerk-Konfiguration legen. Die erweist sich bei Suse als deutlich komplexer als bei Red Hat. Nicht weniger als fünf Subnets muss der Admin im Auge behalten (Abbildung 3), dazu kommt, dass die gewählte Konfiguration später nicht mehr veränderbar ist. Gute Planung ist notwendig, Korrekturen funktionieren nur über einen kompletten Neuanfang.

Abbildung 3: Die Netzwerk-Konfiguration bei Suse Cloud erfordert vorausschauende Planung.

Das Austüfteln der Netzwerk-Konfiguration scheint das A und O bei der Installation der Suse Cloud. Dazu gehört auch das Aufsetzen der Softwareverzeichnisse. In der einfachsten Variante übernimmt der Admin-Rechner die Rolle eines SMT-Servers (Subscription Management Server, [10]). Andernfalls ist die Konfiguration eines so genannten Bastion-Hosts fast unerlässlich. Danach wird es aber recht simpel: Der Admin startet einfach die entsprechenden Rechner, die über den Admin-Server ihr Betriebssystem erhalten und anschließend auf weitere Anweisungen warten.

An dieser Stelle kommt Crowbar ins Spiel. Über so genannte Barclamps konfiguriert der Anwender die Rechner, die zur Suse Cloud gehören, die Reihenfolge ist dabei wichtig. Hier enthält die Dokumentation einen kleinen Fehler: Das Aufsetzen von Rabbit MQ muss vor dem Setup von Keystone erfolgen. Glücklicherweise ist die Software schlauer als die Dokumentation und gibt dem Anwender die richtigen Anweisungen (Abbildung 4).

Abbildung 4: Erst muss Rabbit MQ laufen, bevor Keystone an der Reihe ist.

Ansonsten verläuft das Aufsetzen der Open-Stack-Cloud nach Chamäleon-Art exakt so, wie es die Installationsanweisungen vorgeben. In der Minimalversion sind am Ende die genannten drei Rechner installiert und warten auf ihren Einsatz. Die Tests in den Labors des Linux-Magazins zeigten keine Auffälligkeiten. Jede weitere Kontrolle erfolgt über die Kontrollinstanz: Gibt der Anwender den Servernamen als URL im Browser ein, baut sich ein von Suse angepasster Anmeldebildschirm auf, der seine Open-Stack-Verwandtschaft in keiner Weise leugnet. Wer lieber auf der Kommandozeile arbeitet, findet die notwendigen Shellvariablen unter »/root/.openrc« hinterlegt.

Schmerzfreie Installationen

Abgesehen von den bei Suse nötigen Netzwerk-Überlegungen und der Tatsache, dass der grüne Stapel mehr als einen Rechner erwartet, läuft die Installation von Suse Cloud schmerzfrei ab. Nur mit laufenden Barclamps gibt es Probleme, wer aber die Verwaltung seiner Server auch über Crowbar erledigt, hat neue Chancen für Synergieeffekte.

Suse Cloud basiert auf der Open-Stack-Release Icehouse und verzichtet so auf aktuellere Features etwa von Juno. Weil es in fast allen größeren IT-Landschaften bereits eine Hypervisor-Infrastruktur oder zumindest eine entsprechende Strategie gibt, passt sich das Chamäleon hier gut ein: KVM, VMware, Hyper-V und Xen unterstützt Suse out of the Box. Während LBaaS (Load Balancing as a Service) und FWaaS (Fire Wall as a Service) aktiviert und unterstützt sind, ist Trove (DBaaS, Database as a Service) nur als Technologie-Vorschau enthalten.

Voll unterstützt wird nun auch Ceph (Firefly), der Anwender kann während der Installation der grünen Cloud gleich einen Ceph-Verbund aufsetzen. Die entsprechenden Crowbar-Barclamps sind vorhanden und entsprechend dokumentiert. Natürlich funktioniert auch die Integration einer vorhandenen Installation. Auffällig: In der Standardkonfiguration von Suse Cloud sind nicht alle Komponenten-APIs in der höchstmöglichen Version freigeschaltet, beispielsweise Nova und Cinder.

Open Stack aus dem Hause Red Hat basiert ebenfalls auf Icehouse. Anders als bei Suse ist Trove voll unterstützt. Als Technologie-Vorschau liegt Sahara (Big Data mit Hadoop) bereits bei. Auf der Hypervisor-Seite ist die rote Variante etwas schmaler aufgestellt. Hier kann der Anwender nur zwischen KVM und VMware wählen. Bei Ersterem spielt es eine Rolle, welche RHEL-Version auf dem Host läuft. In der aktuellen Version 7 sind die Betriebssysteme von Microsoft nicht zertifiziert.

Auf der Storage-Seite ist die Unterstützung von Gluster natürlich keine große Überraschung, die kommerzielle Variante erwartet gar den Red Hat Storage Server [11], auch die Integration von Inktank Ceph Enterprise (ICE, [12]) ist nur die logische Konsequenz der Übernahme von Inktank durch den Distributor. Wie Suse hat auch Red Hat die APIs für Nova und Cinder nicht in der höchstmöglichen Version aktiviert.

Erster: Ubuntu!

So unwahrscheinlich das heute scheinen mag: Canonical war der erste große Distributor bei Open Stack. Das geschah ganz und gar nicht zufällig, sondern auf Anordnung von ganz oben: Mark Shuttleworth selbst beschloss, dass sich Ubuntu ab sofort Open Stack verschreiben würde, und zwar schon Anfang 2012. Mancher Beobachter zeigte sich damals sehr verwundert. Denn bis zu Shuttleworths plötzlichem Sinneswandel war das zwischenzeitlich von HP aufgekaufte Eucalyptus in Sachen Cloud Computing bei Ubuntu gesetzt. Ab Version 12.04 lieferte Ubuntu nicht nur Open Stack Essex aus, sondern bot auch kommerziellen Support für Open Stack im Rahmen des Distributionssupports an.

Canonical und Ubuntu haben unter diesem Schritt freilich gelitten, denn Open Stack war 2012 weit von der Qualität entfernt, die die Plattform heute bietet. Aus Shuttleworths Sicht hat sich der Schritt trotzdem gelohnt: Das Kalkül, Open Stack langfristig an Canonical und Ubuntu zu binden, ist mehr als aufgegangen. Kaum eine Anleitung zu Open Stack im Netz setzt auf andere Distributionskombinationen als auf die jeweils neuesten Ubuntu-Variante (Abbildung 5), für die Canonical selbst Open-Stack-Pakete bietet.

Abbildung 5: Das Open Stack von Ubuntu ist im besten Sinne originär, es orientiert sich eng an dem, was Open Stack selbst liefert.

Bis heute nutzt Open Stack für sein Bugtracking Launchpad, bekanntlich ein Canonical-Produkt, bis heute ist Ubuntu auch die Distribution, für die wenige Stunden nach der Release einer neuen Open-Stack-Version bereits Pakete bereitstehen. Das bringt zwangsläufig mit sich, dass die Kombination aus Ubuntu und Open Stack für Admins auch die größte Flexibilität beinhaltet.

Das drückt sich schon in den Möglichkeiten aus, die sich Admins für den Betrieb von Open Stack auf Ubuntu bieten. Einerseits bietet Canonical von Anfang an Open-Stack-Pakete für die aktuelle wie auch für die letzte unterstützte LTS-Version an. Für Ubuntu 12.04 wie für 14.04 stehen also jeweils Pakete der aktuellen Open-Stack-Version bereit. Ubuntu hat für diese Pakete Mitglieder im Server-Team abgestellt, die sich nur um die Open-Stack-Integration kümmern. Die Website des Server-Teams liefert die Information, welche Open-Stack-Version für Ubuntu noch unterstützt ist.

Doch wäre Canonical nicht Canonical, gäbe es nicht auch Ubuntu Cloud. Im Grunde hat Ubuntu Cloud dabei nichts anderes als die jeweils letzte LTS-Ausgabe als Grundlage, die über Zusatzkomponenten die Installation und Benutzung von Open Stack möglich macht. Der große Unterschied zur Selbstbauvariante ist hier tatsächlich nur, dass Ubuntu die Integration mitliefert, um die ein Admin sich andernfalls selber kümmern müsste. Eine fertige Integration dieser Art birgt freilich Vor- wie Nachteile, der Test wird das später im Detail beweisen.

Ubuntu-Schnellstart mit Devstack

Bis heute ist die Kombination aus einer klassischen LTS-Installation und den Ubuntu-Open-Stack-Paketen für Admins vermutlich die schnellste Methode, an eine solide Open-Stack-Basis zu kommen. Canonical hat sich zum Ziel gesetzt, seine Pakete so nah wie möglich an den Originalen zu halten, die Open Stack selbst veröffentlicht. Nur ein Ubuntu-typisches Theme für das Dashboard (Abbildung 6) liefert Canonical mit. Aber wenn Admins das Paket »openstack-dashboard-ubuntu-theme« vom System werfen, ist auch dieser Spuk vorbei.

Abbildung 6: So sieht das Dashboard in Ubuntu 14.04 ab Werk aus.

Der Nachteil am Open Stack vom Hersteller: Die gesamte Integration bleibt am Admin hängen, zum Beispiel auch die Konfiguration der einzelnen Dienste. Zum Lernen mag das beim ersten Mal nützlich sein, aber produktiv einsetzbar ist das so nicht. Vermutlich ist das Deployment-Tool Devstack ([13], auf der DELUG-DVD) auch deshalb so beliebt, weil es ein sauberes Open Stack aus der Taufe hebt, es aber gleich mit Konfigurationsdateien ausstattet.

Wer ein Original-LTS mit den Open-Stack-Paketen von Ubuntu kombiniert, kann aber wenigstens auf die Puppet-Module für die Open-Stack-Teile ausweiche. Dann steht zwar immer noch das Schreiben eines Site-Manifests auf dem Plan, aber dafür erhält der Admin ein reproduzierbares Setup. Gar nicht vorgesehen sind in dieser Variante Themen wie Hochverfügbarkeit. Immerhin liefert Ubuntu einige der benötigten Werkzeuge wie MaaS (Metal as a Service, Canonicals Bare-Metal-Deployment) kostenlos. In Form von Juju steht auch ein eigenes Deployment-Werkzeug bereit, das ähnliche Aufgaben erfüllt wie Puppet oder Chef.

Ubuntu Cloud

Es stellt sich die Frage, ob es wirklich sinnvoll ist, ein sauberes Ubuntu zu nehmen und es dann mittels MaaS, Open Stack, Juju und anderen Komponente aufzupeppeln – wenn man das ganze auch fertig kaufen kann. Denn Ubuntu Cloud ist genau das: Ein fertiges Open Stack aus der Dose, also eine Open-Stack-Distribution, so wie Red Hat und Suse sie ebenfalls bereitstellen.

Der große Unterschied zwischen jenen und Ubuntu ist also zuerst die Tatsache, dass Ubuntu die Open-Stack-Pakete auch separat bereitstellt und der Admin basteln kann, wenn er möchte. Möchte er nicht, greift er zu Ubuntu Cloud und erhält ein vergleichbares Ergebnis. Die Ubuntu Cloud besteht im Wesentlichen aus vier Komponenten: Dem letzten Ubuntu LTS, MaaS, Juju sowie Landscape, dem zentralen Management-Werkzeug, über das Ubuntu auch den Distributionssupport abwickelt.

Anders als bei Suse oder Red Hat kommt Ubuntu Cloud bislang nicht als fertige CD. Stattdessen gibt Ubuntu per Anleitung bekannt, wie Admins am schnellsten zu ihrer Cloud kommen. Das funktionierte im Test zwar sehr gut, wirkt allerdings nicht gerade Enterprise-tauglich. Es dürfte nur eine Frage der Zeit sein, bis Canonical das Produkt auf CDs oder USB-Sticks verteilt und einen bunten Installer dazuheftet, der im Anschluss alles noch einfacher macht.

Allerdings müsste die Firma dann auch die HA-Frage lösen, denn mehr als eine FAQ gibt es dazu bisher nicht. Preislich orientiert sich Canonical auf jeden Fall am oberen Ende, schlägt doch schon das kleinste Paket mit bis zu 100 Rechnern mit mehr als 80 000 Euro zu Buche.

Das Drumherum

Was viele Admins gar nicht wissen: Ubuntu bietet einen ganzen Strauß von Dienstleistungen rund um Open Stack an. Hinter Boot Stack etwa verbirgt sich das Angebot von Canonical, für den Nutzer eine Open-Stack-Cloud zu hosten. Der Kunde übernimmt dann eine schlüsselfertige Cloud, die Rechner dazu sind gemietet. Es entstehen also keine Investmentkosten für Hardware, doch hat der Kunde keine Möglichkeit, physisch an seine Datenträger heranzukommen.

Wer sich für Open-Stack-Training interessiert, ist ebenfalls bei Canonical richtig: Die Orange Box [14] ist ein Micro-Cluster, der aus zehn Intel-NUCs und entsprechender Zusatzhardware besteht. Ubuntu vermarktet den Kasten als portable Mini-Cloud, auf der bei Trainings mehrere Kursteilnehmer eine eigene Cloud hochziehen können. Warum dazu drei virtuelle Maschinen innerhalb von Virtualbox nicht ausreichen sollen, erklärt Ubuntu nicht. In den Augen der Redaktion ist die Orange Box eher ein Marketinggag, aber immerhin ein gelungener. Den Open-Stack-Trainings von Canonical eilt ein guter Ruf voraus, sodass Admins hier wenig falsch machen.

Mirantis

Anders als die ersten Produkte ist Mirantis keine Linux-Distribution, es hat auch nicht die jahrelange Erfahrung, die die drei anderen auszeichnet. Dennoch ist Mirantis ziemlich genau am Anfang des Open-Stack-Hype entstanden und dann mit Open Stack gewachsen. Anfangs als Trainingsanbieter aktiv, verdient Mirantis bis heute einen großen Teil seines Geldes, indem es Trainings in allen Teilen der Welt veranstaltet. Die Firma will ein großer Player in Sachen Open Stack sein und dabei den etablierten Unternehmen zumindest ein Stück des großen Open-Stack-Kuchens wegnehmen.

Mit Training allein wäre das unmöglich, zumal alle Distributoren selbst Trainings für ihre Open-Stack-Produkte bieten. Mirantis setzte 2013 deshalb an der Stelle an, die Admins damals noch die meisten Schmerzen bereitete: Der Open-Stack-Installation. Wer sich Anfang 2013 eine Open-Stack-Cloud bauen wollte, musste seine Konfiguration am CLI anpassen. Mirantis entwickelte daraufhin Fuel (Abbildung 7), und der Name ist Programm: Fuel soll der Kraftstoff sein, der eine Cloud auf Basis von Red Hat, Centos oder Ubuntu zum Leben erweckt.

Abbildung 7: Dreh- und Angelpunkt von Mirantis Open-Source-Bemühungen ist der Open-Stack-Installer Fuel, der unter anderem auch Healthchecking erledigt.

Über alle Grenzen

Der wichtigste Unterschied zwischen Red Hat, Ubuntu, Suse und Mirantis ist also, dass Mirantis sich als Anbieter über die Grenzen von Distributionen hinweg versteht und seine Dienste sowohl auf Red Hat oder kompatiblen Systemen wie auch auf Ubuntu anbietet. Wer mehr Geld einwirft, erhält obendrein den zur Open-Stack-Distribution passenden Support. Der Hersteller wirbt offensiv damit, dass Mirantis die einzige Open-Stack-Distribution ohne Lock-in sei, also ohne Herstellerbindung. Das ist freilich Unsinn: Zwar binden Kunden sich nicht an Canonical oder Red Hat, aber dafür selbstverständlich an Mirantis.

Denn damit die Fuel-Magie funktioniert, steuert Mirantis eigene Open-Stack-Pakete bei, die Fuel auf Ubuntu oder Red Hat automatisch installiert. Die basieren zwar zum Teil auf jenen Paketen, die die Hersteller selbst anbieten – sind jedoch im Detail bisweilen anders und im Zweifelsfall inkompatibel. Wohlgemerkt: Es macht keinen Unterschied, an wen er sich bindet – solange dem Admin klar ist, dass er sich an irgendein Unternehmen definitiv binden muss, wenn er Open Stack einsetzen will.

Alles so schön bunt hier

Mirantis hat bei Fuel einiges richtig gemacht. Das Werkzeug steht mitsamt der Quellen öffentlich zur Verfügung und wird als Community-Projekt innerhalb des Open-Stack-Projektes entwickelt. Wer will, darf also mitmachen. Dabei ist das erste und oberste Ziel stets, Open Stack leicht installierbar zu machen, sodass jeder Admin schnell zu einem lauffähigen Open Stack kommt.

Unter der Haube setzt Fuel auf viele Komponenten, die bereits aus anderen Projekten bekannt sind. Um das Konfigurationsmanagement innerhalb einer Fuel-Cloud kümmert sich zum Beispiel Puppet. Als Herz ihrer Lösung bezeichnen die Mirantis-Entwickler Nailgun: Die Komponente mit dem mehr als unglücklich gewählten Namen ist im ersten Schritt ein Restful-API, das in Python implementiert ist. Nailgun ist gewissermaßen das Werkzeug, das in Fuel Befehle von außen entgegennimmt und auf der anderen Seite die Prozesse anstößt, um die Umsetzung jener Befehle in Open Stack zu gewährleisten.

Freilich gehört zu Fuel auch ein Webinterface, das die wichtigen Funktionen unter einer einheitlichen Oberfläche in Nutzerrichtung exponiert. Dabei ist das Fuel-Webinterface im Hintergrund direkt an Nailgun gekoppelt. Hier leistet Mirantis ausgezeichnete Arbeit. Denn das Webinterface ist übersichtlich und dennoch so flexibel, dass alle wichtigen Hebel und Schalter bereitstehen. Auch nach der Installation lässt Fuel den Admin nicht im Stich und bietet ein paar zusätzliche Funktionen an, beispielsweise einen Healthcheck für die Dienste rund um Open Stack.

Eigene Plugin-Schnittstelle

Zu Fuel gehört auch ein Plugin-Layer, über den sich von außen Funktionalität nachrüsten lässt. Das ist Mirantis’ Einladung an andere Hersteller, ihre Produkte mit Fuel zu integrieren. Netzwerkhersteller können Fuel so etwa in die Lage versetzen, direkt mit den eigenen Geräten zu kommunizieren. Cisco und Juniper haben von diesen Möglichkeiten schon Gebrauch gemacht. Ähnliches gilt für Storage: Hier ist Ceph ein herausragendes Beispiel für die Anbindung externer Speicherarten.

Interessant ist gewiss auch die Zertifizierung, die Mirantis den nachgerüsteten Plugins auf Wunsch zukommen lässt. Das Zertifikat ist der offizielle Segen dafür, dass ein Plugin technisch sauber umgesetzt ist und die versprochene Leistung liefert. Insgesamt hinterlässt Fuel einen positiven Eindruck.

Ein durchaus pikantes Detail am Rande ist, dass auch Red Hat noch immer offiziell als Mirantis-Investor geführt wird, obwohl das Unternehmen mittlerweile selbst massiv im Open-Stack-Markt investiert hat. Die geänderte Strategie der Rothüte konterte Mirantis mit Hilfe von Canonical. Mittlerweile haben sich die Wogen etwas geglättet, aber Freunde werden Mirantis und Red Hat wohl nicht mehr. Dabei haben die beiden Anbieter eines gemeinsam: Auch Mirantis wollte trotz beharrlicher Nachfragen keine Referenzpreise nennen.

HP Helion

Als Hewlett-Packard im September 2014 den Kauf von Eucalyptus bekannt gab, erstaunte dies die Cloudcommunity. Denn eigentlich hatte HP sich sehr frühzeitig auf Open Stack eingeschossen. Community-Beteiligung inklusive: Kaum eine Open-Stack-Konferenz vergeht, ohne dass HP offiziell dabei wäre, meist sogar als Sponsor. Auch bei den Open-Stack-Design-Summits ist HP mittlerweile ein echte Größe.

Neben der öffentlichen Hosted Cloud, die HP selbst betreibt (siehe den Artikel zu den Hosted-Open-Stack-Produkten), steht Helion auch als Download-Image zur Verfügung. Die Community-Variante ist kostenlos zu haben, kommt aber natürlich ohne jede Form von Support daher. Die kommerzielle Version von Helion führt Support im Gepäck und richtet sich an größere Unternehmen.

Umfassend

Im Konzept folgt HP eher Suse oder Red Hat: Das Image eignet sich nahezu perfekt dafür, eine Open-Stack-Cloud aus dem Boden zu stampfen. Freilich umfasst das mehr als die bloße Open-Stack-Installation: Als Hardwarehersteller liegt HP auch das Thema Hardware am Herzen, Bare-Metal-Deployment spielt also durchaus eine Rolle. Triple-O [15], das Open Stack nicht nur als Virtualisierungslayer nutzt, sondern auch die Hardwareknoten einer Wolke mit Open Stack verwaltet, kommt unmittelbar von HP selbst.

Der technische Überblick zu Helion offenbart, dass Setups eher klassischen Deployment-Mantras folgen. Für eine Minimal-Installation setzt der Hersteller mindestens acht Knoten voraus, ein weiterer Server ist der Seed-Host, also der Cloudcontroller. Er soll laut HP auf Ubuntu 14.04 laufen. Ubuntu-Admins tun sich im Zweifelsfall also mit Helion leichter als Admins, die RPM-basierte Distributionen gewöhnt sind.

Wenn der Seed-Node läuft, folgt Helion den Begriffen aus Triple-O: Die Hardware läuft als Undercloud. Die Overcloud wiederum folgt einer klassischen Architektur, wie sie auch von Red Hat oder Suse bekannt ist: Zu HA-Zwecken gibt es zwei Controller, die anderen Hosts spielen innerhalb der Installation im weiteren Verlauf die Hypervisoren, auf denen Kunden-VMs laufen.

Sehr spezifisch

Insgesamt darf das aber nicht darüber hinwegtäuschen, dass Helion sich von anderen Open-Stack-Produkten merklich unterscheidet. Das ist aber nicht automatisch gut oder schlecht – HP hat in Triple-O bereits einige Arbeit investiert, und die Lösung hat durchaus ihre Stärken. Denn anders als bei Suse, Red Hat und Ubuntu, wo Bare-Metal-Deployment stets eine Dreingabe zum normalen Open Stack ist, gehört diese Komponente bei HP fest zum Design der Plattform.

Aus Nutzersicht unterscheidet sich die Overcloud gar nicht so sehr von den Umsetzungen der anderen Hersteller. Freilich: Wie bei Red Hat, Suse und Ubuntu kommt auch das Horizon (Abbildung 8) von HP Helion mit einem eigenen Theme. Doch wer Horizon bedienen kann, bekommt das auch bei allen anderen Systemen hin.

Abbildung 8: Horizon in der Ausfertigung von Helion unterscheidet sich beim ersten Anblick lediglich durch seine Farben von einem normalen Horizon.

Es lohnt sich beim Evaluieren von Open-Stack-Lösungen, Helion eine Chance zu geben. Besonders für Unternehmen, bei denen HP sowieso schon der Haus- und Hoflieferant für Hardware ist, bringt die Undercloud von Triple-O nämlich überaus angenehme Zusatzfunktionen wie das automatische Bios-Update über alle Cloudknoten hinweg. Und Helion ist günstig: Support-Pakete fangen bereits bei wenigen Tausend Euro (etwa 1500 Euro pro Server) an.

Fazit und Ausblick

Ubuntu tritt als der Platzhirsch in Sachen Open Stack an. Stolz verweist Canonical darauf, dass 55 Prozent aller Open-Stack-Deployments in freier Wildbahn auf Ubuntu basieren. Wer einen schnellen Start haben möchte, greift zu Ubuntu Cloud und kann innerhalb weniger Stunden loslegen. Die Linux-Veteranen Suse und Red Hat bündeln ihr Open-Stack-Angebot mit anderen Produkten beziehungsweise betten sie in das vorhandene Portfolio ein. Der Start ist bei den Rothüten etwas einfacher als bei Suse. Früher oder später landet man aber bei recht vergleichbarer Hardware-Infrastruktur. Am Ende könnte sogar die Vorliebe für Puppet beziehungsweise Chef den Ausschlag für die Open-Stack-Distribution der Wahl geben. Dabei lohnt sich auch der Blick über den Distributions-Tellerrand zu Mirantis und HP.

Übrigens: Alle Links zu den zahlreichen in diesem Artikel angesprochenen Tools und Softwareprojekten (insgesamt mehr als 60) finden sich auf Linux-Magazin Online Plus [16]. (mfe)