zige Firma am Markt „Pure Play Open Stack“ zu verbreiten. Gemeint war, dass das Open Stack von Mirantis tatsächlich weitestgehend ohne Secret Sauce aus-kam, während andere Hersteller an ihren Open-Stack-Distributionen nach Belieben herumpatchten. Was vom Linux-Kernel manchem Admin bereits leidlich bekannt ist, fand bei Open Stack nahtlos seine Fortsetzung. Stets ging die Entscheidung für eine fertige Open-Stack-Distribution mit einem klassischen Lock-in beim je-weiligen Hersteller einher. Zwar waren auch die Mirantis-Pakete zum Teil mit Patches versehen, Fakt ist aber, dass Mirantis’ Open Stack noch am ehesten mit den Vanilla-Quellen des Open-Stack-Projekts vergleichbar war. Weil man sich nicht auf das Deployment-Framework der eigenen Linux-Distribu-tion verlassen konnte, sprang Mirantis obendrein in die Bresche und entwickelte ein Deployment-Werkzeug: Fuel (Abbil-

dung 1). Mirantis stellte das Programm unter eine freie Lizenz, machte es so-gar zu einer Komponente im Big Tent der Open Stack Foundation und lud die Community ein, sich an dessen Entwick-lung zu beteiligen.Der Ehrlichkeit halber sei in diesem Zu-sammenhang aber erwähnt, dass weite Teile der Community Mirantis freilich trotzdem als ganz normalen Open-Stack-Distributor betrachteten. So war das Feedback auf Fuel und Mirantis Open Stack insgesamt eher zurückhaltend: Ver-einzelt steuerten externe Entwickler zwar Patches bei, in Summe erledigte Mirantis aber nach wie vor das Gros der Arbeit selbst. Was schade war, denn tatsäch-lich war Fuel bis zuletzt die bequemste und leichteste Art, an ein grundlegendes Open-Stack-Setup zu kommen.

Mirantis ist längst nicht mehr nur den eingefleischten Cloudentwicklern und Admins ein Begriff, das amerikanische Unternehmen kennen mittlerweile selbst jene, die sich mit der Cloud nur am Rande beschäftigen. Schließlich ist es dem Un-ternehmen gelungen, sich mit seinem Produkt Mirantis Open Stack neben den großen Linux-Anbietern wie Suse, Red Hat oder Canonical am Markt zu etablie-ren. Selbst Großaufträge wie die Einfüh-rung einer Cloud bei Volkswagen hat die

Firma den etablierten Herstellern vor der Nase weggeschnappt. Eigentlich, so mag es scheinen, ist in Sunnyvale in Kalifor-nien alles in Ordnung.Umso erstaunter war mancher Beobach-ter, als Mirantis Anfang April ein völlig neues Produkt – Mirantis Cloud Platform – an- und Mirantis Open Stack samt dem Installer Fuel [1] zugleich abkündigte. Was war geschehen? Stimmt Mirantis in den Chor jener ein, die Open Stack schon das Ende seiner Hoch-Zeit voraussagen, und orientiert sich um? Grund genug, sich die Mirantis Cloud Platform (MCP) und ihre Ziele genauer anzuschauen.

Open Stack ist mühsam

Die Ursachen für den vermeintlichen Gesinnungswandel bei Mirantis reichen weit in die Vergangenheit zurück. Lange Zeit hat Mirantis stolz behauptet, als ein-

Mirantis stampft seine Open-Stack-Distribution und das Deployment-Werkzeug Fuel ein und platziert in Zu-kunft einen hybriden Ansatz aus Open Stack und Kubernetes in die Auslage. Das Linux-Magazin hat sich die Mirantis Cloud Platform 1.0 genauer angesehen. Martin Loschwitz

Die neue Mirantis Cloud Platform 1.0 unter der Lupe

Administration im Angebot

Sysa

dm

in

80

ww

w.lin

ux-m

agaz

in.d

eM

CP

07/2

017

© M

ykol

a Ko

kary

ev, 1

23RF

Der Autor

Martin Gerhard Loschwitz

ist Head of Cloud bei der

Firma iNNOVO Cloud. Er be-

schäftigt sich dort bevor-

zugt mit den Themen Dis-

tributed Storage, Software

Defined Networking und Open Stack.

Zu dem teils ausbleibenden Erfolg bei der Community mit Fuel kommt für Mirantis ein weiterer Faktor erschwerend hinzu: Der Hype rund um Open Stack ebbt seit einiger Zeit offenbar ab.

Absteigender Ast?

Das ist zunächst nicht verwunderlich: Über mehrere Jahre war Open Stack fast der Alleinunterhalter im Blätterwald, wenn es um Public Clouds abseits der großen Anbieter wie Amazon, Microsoft oder Google ging. Die Lösung hat andere Ansätze wie Eucalyptus vom Markt prak-tisch verdrängt. Eine gar nicht so kurze Weile schien es, als sei für Open Stack praktisch alles möglich. Viele der Unternehmen, die sich mit Open Stack beschäftigten, holten sich aber eine blutige Nase – zum Teil auch absehbar. Wer nur ein paar virtuelle Systeme ver-walten möchte, braucht dafür nicht zwin-gend Open Stack und auch keine Public Cloud. Mittlerweile existieren diverse Berichte enttäuschter Unternehmen, die Open Stack für genau solche Zwecke ein-setzten wollten – und entnervt aufgege-ben haben, als ihnen dessen Komplexität klar wurde (Abbildung 2).Am besten lässt sich der aktuelle Open-Stack-Status mit der Theorie des Hype Cycle von Gartner [2] erklären: Nach der Hype-Phase setzt jetzt aktuell die Desillusionierung ein. Insgesamt beschäf-tigen sich deutlich weniger Firmen mit der Lösung. Jene, die Open Stack die Treue halten oder die heute anfangen, sich mit dem Produkt einge-hend zu befassen, wissen – anders als die Unternehmen am Beginn des Hype – je-doch auch, worauf sie sich einlassen.Die Gefahr, dass sie ihre Open-Stack-Pro-jekte später einstamp-fen, ist daher deutlich geringer und die An-zahl der gescheiterten Open-Stack-Projekte wird abnehmen.

Vor diesem Hintergrund könnte Miran-tis sich eigentlich freuen, weil absehbar Open-Stack-Wissen und -Consulting wei-terhin ein begehrtes Gut sein werden. Aber in der Vergangenheit hat der Her-steller eben auch viel Umsatz mit jenen Kunden generiert, die bei Null anfingen und Hilfe beim Open-Stack-Einstieg such-ten. Die konnte man mit einer Kombina-tion aus Fuel, Mirantis Open Stack sowie Consulting und Training gut bedienen – fast egal, ob die Projekte später wieder eingestellt wurden. Weniger neue Open-Stack-Projekte be-deutet für Mirantis also konkret weniger Möglichkeiten, Umsatz zu generieren.

Wendet sich Mirantis nun ganz ande-ren Ansätzen zu, um mit ihnen, wie bei Open Stack, wieder auf der Welle des Hype Cycle zu surfen? Verschwindet das Open-Stack-Engagement von Mirantis in absehbarer Zeit komplett?Solchen Gedankenspielen erteilt Boris Renski eine Absage. Renski ist einer der Mirantis-Gründer und kümmert sich ak-tuell um das Marketing. Er stellt klar, dass über 90 Prozent des Mirantis-Umsat-zes direkt an das Thema Open Stack ge-koppelt sind. Glaubt man ihm, so ist die Mirantis Cloud Platform (MCP) nur eine logische Evolutionsstufe nach Open Stack Mirantis und Fuel, fast schon eine un-

81

ww

w.lin

ux-m

agaz

in.d

e

Sysa

dm

inM

CP

07/2

017

Abbildung 2: Open Stack ist ein komplexes Konstrukt, das aus diversen Komponenten besteht. Fuel von Mirantis half Unternehmen

bisher beim Open-Stack-Einstieg.

© K

en P

eppl

e

Abbildung 1: In Form von Fuel hat Mirantis ein Setup-Werkzeug für Open Stack am Markt etabliert, das leicht

zu bedienen ist. Nun verschwindet es wieder in der Versenkung.

© M

iran

tis

zu ermöglichen. Welche Komponenten kommen dabei zum Einsatz?

Open Stack und Kubernetes

Zunächst gehört zum Lieferumfang der Mirantis Cloud Platform eine vollstän-dige Open-Stack-Distribution. Die besteht aus den Kernkomponenten, die für den Betrieb der Cloud zwingend notwendig sind, sowie einigen Zusatzdiensten aus dem Big Tent. Man darf annehmen, dass die technische Basis für diesen Teil der MCP wohl die alte Mirantis-Open-Stack-Distribution gewesen ist. Mit Kubernetes verhält es sich ganz ähn-lich: Auch der von Kubernetes selbst zur Verfügung gestellte Funktionsumfang ist Teil der MCP. Während Kubernetes in sich einigermaßen komplett ist und nur wenige externe Zusatzdienste braucht, sieht die Sache bei Open Stack anders aus: Es lässt sich bekanntlich mit einer Reihe zusätzlicher Komponenten kom-binieren. Mirantis macht bei MCP von dieser Möglichkeit regen Gebrauch.

SDN mit Open Contrail

In Sachen Software Defined Networking setzt MCP nicht etwa auf Open Vswitch, das bei der Open-Stack-SDN-Komponente Neutron eigentlich der Standard ist. Wer die MCP benutzt, landet stattdessen bei Open Contrail [3] von Juniper. Das ist durchaus bemerkenswert, denn Open Contrail ist deutlich komplexer als Open

Vswitch. Dafür gilt es allerdings auch als deutlich fortgeschrittener hinsichtlich der eigenen Architektur und der unterstütz-ten Protokolle.Zur Erinnerung: Open Vswitch funktio-niert auf Basis eines Kernelmoduls, das auf den Hosts virtuelle Switches unter-stützt. Mittels GRE- oder VxLAN-Tunneln führt Open Vswitch die Trennung von Traffic auf der Systemebene durch, sodass Kunden den Traffic anderer Kunden in ih-ren VMs niemals zu Gesicht bekommen. Weil die Open-Vswitch-Instanzen auf den einzelnen Hosts voneinander aber nichts wissen, produziert Open Vswitch viel Overhead-Traffic, zum Beispiel für ARP zwischen VMs, die auf unterschiedlichen Hosts laufen. Open Contrail ist effizienter: Auch das Produkt von Juniper hat ein eigenes Ker-nelmodul. Im Hintergrund werkelt aber eine zentrale Datenbank, die sich den ak-tuellen Host einzelner VMs merkt. Sucht eine VM eine andere, fängt ein eigens zu diesem Zweck auf jedem Host beheima-teter Agent die jeweiligen ARP-Requests ab und beantwortet sie selbst. Den Over-head reduziert das deutlich. Auch die Anbindung an die Außenwelt hat Open Contrail besser gelöst als Open Vswitch: Protokolle wie MPLS und BGP sind in Open Contrail integriert, um externe Kon-nektivität herzustellen.Doch hat die Medaille eine zweite Seite: Open Contrail ist viel komplexer als Open Vswitch. Bessere Performance und die Option, besser in die Breite zu skalieren, erkauft man sich letztlich also durch ein deutlich umfassenderes Setup. Contrail selbst besteht aus beinahe genau so vie-len Komponenten wie die gesamte Open-Stack-Umgebung. Dass es Mirantis gelungen ist, Contrail als Werkzeug in seinen Cloud-Werkzeug-koffer zu packen, ist also durchaus eine beachtliche Engineering-Leistung. Hier zahlt sich ein Zukauf der jüngeren Fir-mengeschichte aus: Im September 2016 übernahm Mirantis nämlich TCP Cloud, das sich auf die Arbeit mit Open Contrail spezialisiert hatte.

SDS mit Ceph

Fast schon zu erwarten war hingegen Mirantis’ Entscheidung, weiterhin auf Ceph [4] als Lösung für Software Defi-

abdingbare Konsequenz. Um das nach-zuvollziehen zu können, ist ein etwas genauerer Blick auf die Mirantis Cloud Platform notwendig.

Eierlegende Wollmilchsau

Beim Scrollen durch die Dokumentation des Produkts taucht regelmäßig ein Name auf, der besonders Docker-Fans längst ge-läufig sein dürfte: Kubernetes (Abbildung

3). Tatsächlich gilt Kubernetes aktuell gewissermaßen als Nachfolger von Open Stack in Sachen IT-Hype. Frei nach dem Motto: Wer etwas auf sich hält, beschäf-tigt sich mit Containern, mit Docker und auf jeden Fall mit Kubernetes – Googles Werkzeug, um Docker-Container effizient in einem großen Pool von Servern zu ver-walten. Gleichzeitig redet die MCP-Doku aber auch durchweg von Open Stack. Da fragt sich mancher Admin: Ja, was gilt denn jetzt?Bei genauem Hinsehen entpuppt sich die Mirantis Cloud Platform als der klassische Versuch für eine eierlegende Wollmilch-sau. Sowohl Open Stack als auch Kuber-netes sind Teil der Lösung. Das erklärte Ziel ist, dass Anwender über die immer gleichen Schnittstellen fast nach Belieben virtuelle Maschinen (in Open Stack) oder aber Container (in Kubernetes) per API-Befehl starten können. Damit das funk-tioniert, kombiniert Mirantis unter der Haube einen Haufen verschiedener Lö-sungen, um dem potenziellen Nutzer das aus Mirantis-Sicht beste Cloude rlebnis

Sysa

dm

in

82

ww

w.lin

ux-m

agaz

in.d

eM

CP

07/2

017

Abbildung 3: Kubernetes gehört genauso zur Mirantis Cloud Platform wie Open Stack, das Produkt kann also

sowohl VMs als auch Container verwalten. (Grafik: Wikipedia)

© W

ikip

edia

erweitert Kubernetes um eine Vielzahl von Features: Neben der Möglichkeit, BGP mit der Außenwelt ohne Overlay-Netzwerk zu sprechen, gehört dazu auch eine Policy-Engine, über die der Admin Netzwerkregeln definiert und erzwingt. Salopp ließe sich die Policy-Engine von Calico als Gegenstück zu den in Open Stack zum Lieferumfang gehörenden Security Groups auffassen. Für die Mirantis Cloud Platform weicht der Hersteller von einem Mantra ab, das ihm früher noch heilig war: In der MCP finden sich sehr wohl Mirantis-eigene Komponenten. Nur zum Besten der Nutzer, wie man eifrig beteuert: Drive-train und Stacklight sollen lediglich dem Admin das Leben erleichtern.

Drivetrain

In Form von Drivetrain nimmt Mirantis das leidige Thema Deployment sowie Lifecycle-Management ins Visier. Wer

Open Stack schon mal ausgerollt hat, weiß um dessen Komplexität. Die Prob-leme gehen bereits los, bevor eine Open-Stack-Komponente überhaupt irgendwo installiert ist: Wie lässt sich ein – bei Clouds naturgemäß riesiger – Park von Servern verwalten? Wie erhalten die ein-zelnen Systeme ihr Betriebssystem und wer kümmert sich darum, dass wich-tige (Security-)Updates den Weg auf die Systeme finden? Drivetrain nimmt sich dieser Aufgaben in MCP an. Warum Mirantis hier das Rad unbedingt neu erfinden musste, statt auf eines der bestehenden Deployment-Systeme für Open Stack und Kubernetes zu setzen, erschließt sich erst bei genauerem Hinse-hen: Auf Basis von Salt und Reclass hat der Hersteller nämlich ein Framework gebaut, das zusätzlich zum typischen Lifecycle-Management auch ein Change-Management bietet. Salt Stack sorgt ei-nerseits für das Deployment der Dienste auf der Hardware. Auf der anderen Seite

ned Storage in MCP zu setzen. Mit Ceph hat man bei Mirantis schließlich Erfah-rung: Fuel war bereits in der Lage, einen kompletten Ceph-Cluster per Mausklick einzurichten. Hinzu kommt, dass sich Ceph mittlerweile zum Quasi-Standard in Sachen Objektspeicher mit verteilter Ablage entwickelt hat: Kaum eine Open-Stack-Cloud setzt nicht darauf. Nicht ohne Grund: In Sachen Robustheit ge-hört Ceph zur Gruppe der zuverlässigsten Storage-Lösungen überhaupt.

Extrawürste auch bei Kubernetes

Ganz ohne externe Komponenten belässt es Mirantis auch bei Kubernetes nicht. Auch hier ergänzt der Hersteller eine ex-terne SDN-Lösung: Calico [5] kümmert sich im Container-Teil der Plattform da-rum, dass Container auf Wunsch mit an-deren Containern sowie mit der Außen-welt Daten austauschen können. Calico

83

ww

w.lin

ux-m

agaz

in.d

e

Sysa

dm

inM

CP

07/2

017

kümmert sich ein Gespann aus Git, Gerrit sowie Jenkins darum, dass Änderungen an der Plattform in protokollierter, über-prüfter Weise möglich sind. Sogar an die Optik hat man gedacht: Dem Admin steht ein GUI zur Seite, über das er Änderungen selektiv genehmigen oder zurückweisen darf. Weil die gesamte Konfiguration der Umgebung in Form von Code vorliegt, lässt sich so jede be-liebige Änderung durchführen.

Der Blick fürs Detail

Laufende Installationen von Open Stack oder Kubernetes sind zwar schön, sie sind aber nur die halbe Miete. Wenn das Setup einmal steht, ist der Admin auf fortlaufende Metrikdaten angewiesen, die Auskunft über den Zustand der Plattform geben. Für den Betreiber der Plattform ist etwa die Information elementar, wann die nächste Ausbaustufe der Hardware ansteht. Gleichzeitig will der Admin auch erfahren, wenn auf einem Host des Set-ups etwas schiefgeht, das händisches Eingreifen erfordert. Besonders das Thema Logging ist ein neuralgischer Punkt: Bei Dutzenden oder Hunderten Hosts ist die Menge der anfallenden Logmeldungen pro Sekunde – und gerade bei Open Stack – so groß, dass sie manuell nicht mehr zu bewälti-gen ist. Lösungen wie Logstash und Ki-bana lösen in Kombination das Problem. Ihr Setup ist aber aufwändig. Ähnliches gilt für den Themenkom-plex Monitoring, Alerting und Trending

versorgen, die regel-mäßig einzuspielen sind.Bei erfahrenen Open-Stack-Admins löst die-ser Ansatz sicherlich Interesse aus, denn große Updates, bei de-nen die Open-Stack-Komponenten auf die nächste Major-Version gehoben werden, sind oft genug ein Horror-szenario. Nicht selten gehen diese Updates zumindest teilweise schief: Am Ende steht dann eine halb ka-putte Cloud, die nur

noch durch mühsame Handarbeit zu re-animieren ist. Andere Unternehmen wählen gleich einen anderen Ansatz und bauen eine zweite Cloud mit neuer Software zur ers-ten Cloud parallel auf, um anschließend die Daten mühsam zu migrieren. Viel besser als das erste Szenario ist das al-lerdings auch nicht.Bis Redaktionsschluss war allerdings nicht nachvollziehbar, ob das System, das Mirantis sich ausgedacht hat, zuverlässig funktioniert. Wenn es der Firma aber ge-lingt, Open-Stack- und (in deutlich klei-nerem Umfang) Kubernetes-Updates den Schrecken zu nehmen, wäre auch das eine beachtliche technische Leistung.

Das Vertriebsmodell: Mieten statt kaufen

Klar scheint bisher: Mirantis gelingt in Form der Mirantis Cloud Platform ein Meisterstück. Die Kombination vie-ler verschiedener Dienste unter einer Haube, auf die Nutzer über definierte APIs zugreifen, nötigt auch den in der Community vorhandenen Mirantis-Kriti-kern Respekt ab. Dabei soll nicht in Ver-gessenheit geraten, dass der ausführende Admin es noch immer mit einer großen Anzahl loser Teile zu tun hat, die viel Fachwissen voraussetzen.Auch für dieses Problem hat Mirantis allerdings eine Lösung, denn anders als noch Mirantis Open Stack und Fuel kann man die Mirantis Cloud Platform nicht einfach kaufen und selbst installieren.

(MAT): Lösungen wie Prometheus oder Influx DB mit Sensu und Grafana existie-ren, sind in der Handhabung aber recht kompliziert (Abbildung 4).Bei der Mirantis Cloud Platform bekommt der Admin das Wunschlos-glücklich-Paket: Stacklight heißt die Komponente, die unter der Haube viele Lösungen zum perfekten Helfer für das Operationsteam machen soll. Ein eigener Dienst holt von den Hosts die relevanten Logdateien ab und kippt sie danach in die Kombi aus Elasticsearch und Kibana (Abbildung 5), wo der Admin auf sie zugreift. Influx DB sowie Grafana kümmern sich im Gespann um das Sammeln und An-zeigen von Metrikdaten, sodass das Ope-rationsteam weiß, was auf der eigenen Plattform gerade los ist. Und falls mal was schiefgeht, steht Sensu bereit: Es überwacht auf Basis einer Standardkonfi-guration die Komponenten der MCP und schlägt Alarm. De facto befreit Mirantis den Admin also von drei elementaren Problemen mit ei-nem Schlag. Hier bietet das Produkt ech-ten Mehrwert: Wollte der Admin nämlich ein vergleichbares Setup händisch bauen, wäre er damit einige Zeit beschäftigt.

Lieber in kleinen Schritten

Gebetsmühlenartig weist Mirantis darauf hin, dass sich MCP in einem sehr zentra-len Punkt von anderen Cloudprodukten unterscheidet: Anstelle der großen Up-dates will Mirantis die MCP-Installatio-nen kontinuierlich mit kleinen Updates

Sysa

dm

in

84

ww

w.lin

ux-m

agaz

in.d

eM

CP

07/2

017

Abbildung 4: Grafana im Gespann mit der Influx DB bietet eine große Vielzahl an verschiedenen Metriken und Graphen, die alle visuell

Auskunft über den Zustand und die Performance der Cloud geben.

© O

pen

stac

k

Mirantis hat sich ein besonderes Ver-triebsmodell für die MCP überlegt. Die Marschrichtung gibt erneut Boris Renski vor: Dieser hatte bei der Vorstel-lung der MCP die nicht ganz abwegige These aufgestellt, dass die meisten Un-ternehmen in einer Open-Stack- oder Kubernetes-Installation nur ein notwen-diges Übel sehen, ein Mittel zum Zweck. Eigentlich sei ja die große Flexibilität das Objekt der Begierde, die Open Stack und Kubernetes hin zur Nutzer-Seite böten. Wenn ein Unternehmen diese Vorteile an die Kundschaft durchreichen wolle, müsse es einfach eine eigene Plattform betreiben – obwohl es das eigentlich gar nicht will.Nobel wie man im Hause Mirantis nun mal ist, springt man mit der MCP den gebeutelten Firmen zur Seite: In den ers-ten zwölf Monaten nach dem Setup ei-ner MCP-Plattform betreibt Mirantis diese quasi im Kundenauftrag selbst – ob der Kunde das will oder nicht. Nach frühes-tens zwölf Monaten besteht die Option, das Setup an den Kunden mit allen Kom-ponenten zu übergeben. Süffisant merkt man bei Mirantis an, dass man die zwölf Monate auch abseits der Plattform sehr sinnvoll nutze: So könne man das Operationsteam, das die Umge-bung irgendwann selbst betreiben soll, in Sachen Devops schulen, um dort so viel Wissen wie nötig aufzubauen.Doch lässt sich diese Vertriebsart auch aus einer anderen Perspektive betrachten: Dann stellt man deutlich weniger char-mant fest, dass Mirantis Cloud Platform in erster Linie wohl als Produkt konzipiert ist, das die Professional Services von Mi-rantis unters Volk bringen soll. Denn die zwölf Monate Händchenhalten lässt Mi-rantis sich ebenso bezahlen wie etwaige Schulungen in dieser Zeit. Das muss nicht automatisch und unter allen Umständen schlecht sein. Wer die Vorteile von Open Stack und Kubernetes nutzen möchte, ohne sich den Betrieb der Plattform dafür aufzubürden, der ist mit der Cloud Platform sicher nicht schlecht bedient. Leider rückt Mirantis Preise für seine Software und Dienstleistungen nur auf konkrete Anfragen heraus. Aus die-sem Grund muss diese Information jeder selbst einholen.Die Abkündigung von Mirantis Open Stack und Fuel führt naturgemäß dazu,

dass Plattformen, die jene Komponen-ten aktuell nutzen, sich Alternativen überlegen müssen. Das Unternehmen verspricht diesen Kunden einen Migra-tionspfad von Mirantis Open Stack hin zur MCP – auch dabei dürfte es sich al-lerdings um kundenspezifische Projekte handeln, die zusätzliche Kosten hervor-rufen. Ein Jahr Galgenfrist hat Miran-tis Open Stack ohnehin noch, bevor die Firma ihm das Licht ganz abdreht.

Fazit

Technisch ist die Mirantis Cloud Platform bemerkenswert. Der Hersteller hat alle relevanten Werkzeuge in einen Koffer ge-packt: Open Stack bildet mit Kubernetes den Kern der Plattform und ermöglicht es Unternehmen, virtuelle Maschinen und Container über offene, sauber dokumen-tierte APIs zu kombinieren. Weil ein Open Stack oder ein Kuberne-tes allein noch nicht glücklich machen, enthält der Werkzeugkoffer zusätzliche Komponenten: Ceph als Allroundlösung für verteilten Storage, Open Contrail als fortschrittliche SDN-Lösung für Open Stack und Calico als Netzwerk-Allzweck-waffe bei Kubernetes. Auch die alltäglichen Sorgen der Adminis-tratoren nimmt man in Sunnyvale ernst: Der auf Salt basierende und direkt mit einem Kommandozeilen-Interface ver-sehene Deployment-Mechanismus deckt das Thema Lifecycle-Management gut ab. Dank Kibana, Elasticsearch, Influx DB und vielen weiteren Komponenten weiß der ausführende Admin außerdem zu je-

der Zeit, was in seiner Cloud gerade los ist. Hätte Mirantis diesen Werkzeugkoffer samt Dokumentation in dieser Form zum Kauf angeboten, hätte das so manchem Manager von Red Hat oder Suse mögli-cherweise den Angstschweiß auf die Stirn getrieben.Stattdessen bedingt Mirantis es sich aus, den Werkzeugkoffer selbst zu liefern und Arbeiten mit den darin vorhande-nen Werkzeugen zumindest am Anfang selbst zu erledigen – gegen Aufpreis. Das kann funktionieren: Gelingt es dem Un-ternehmen, genug Kunden zu finden, die eine Cloud wollen, ohne sich um deren Administration zu kümmern, dürfte das Produkt zum Erfolg werden.Weniger erfreut sind vermutlich jene Kunden, die bisher Mirantis Open Stack nutzen. Ihnen steht eine Migration noch völlig unbekannten Ausmaßes ins Haus, bei der Mirantis natürlich gerne behilf-lich ist – vorausgesetzt die Kohle stimmt, versteht sich. Als einziger Anbieter ei-ner freien Open-Stack-Distribution mit funktionierenden Open-Stack-Paketen, die ohne Aufpreis zu beziehen sind, ver-bleibt damit nach heutigem Stand nur noch Canonical. (jcb) n

Infos

[1] Fuel: [https:// www. mirantis. com/ software/

openstack/ fuel]

[2] Gartner Hype Cycle:

[https:// en. wikipedia. org/ wiki/ Hype_cycle]

[3] Contrail: [https:// www. opencontrail. org]

[4] Ceph: [https:// www. ceph. com]

[5] Calico: [https:// www. projectcalico. org]

85

ww

w.lin

ux-m

agaz

in.d

e

Sysa

dm

inM

CP

07/2

017

Abbildung 5: Die gut eingespielte Kombination aus Kibana und Elasticsearch ermöglicht es unter anderem,

die Logs von Open-Stack-Diensten effizient zu verwalten.

© O

pen

Stac

k