Mesosphere hat das Datacenter-Betriebssystem Virtualisierung war gestern. DCOS taugt besser.

Autor / Redakteur: lic.rer.publ. Ariane Rüdiger / Ulrike Ostler

Betriebssyssteme sollen zukünftig ganze Umgebungen oder Rechenzentren automatisieren. Eines ist „DCOS“ von Mesosphere. Es basiert auf Apache MesOS, ist aber für den Unternehmenseinsatz optimiert. Ariane Rüdiger sprach mit Michael Hausenblas, Developer Evangelist bei Mesosphere, über Vor- und Nachteile, Anwendungsfelder und die Weiterentwicklung von DCOS.

Firma zum Thema

„MesOS bekommt nun Funktionen für Stateful-Anwendungen“, so Michael Hausenblas, Developer Evangelist bei Mesosphere.
„MesOS bekommt nun Funktionen für Stateful-Anwendungen“, so Michael Hausenblas, Developer Evangelist bei Mesosphere.
(Bild: Mesosphere)

Warum braucht man überhaupt Betriebssysteme für das ganze Rechenzentrum?

Michael Hausenblas: Es geht vor allem darum, schneller und flexibler zu werden. Für einen Entwickler sieht eine Umgebung unter DCOS aus wie ein Mainframe. Man muss sich nicht mehr um Netzwerke, Zuweisungen und so weiter kümmern, sondern greift darauf zu wie auf eine lokale Umgebung. Für Entwickler bedeutet das, dass sie sich auf die Business-Logik konzentrieren können statt auf Infrastrukturprozesse.

In welchem Umfeld setzt man so ein System am besten ein?

Michael Hausenblas: DCOS oder MesOS kommen für Startups oder Firmen mit hauptsächlich Cloud-nativen Applikationen in Betracht. Wir haben aber auch Kunden aus der Telekommunikation und dem Finanzbereich, die eine DCOS-Umgebung on premise betreiben.

Der andere Sektor ist Big Data und IoT, also Dinge wie Spark, Cassandra oder Kafka, wo es darum geht, schneller als bisher Daten-Pipelines aufzubauen oder Experimente durchführen zu können. Das dauert bei statischer Allokation der Maschinen zu lange, unter MesOs respektive DCOS ist aber alles dynamisch.

Wie kam es zur Entwicklung von DCOS?

Michael Hausenblas: MesOS wird schon einige Jahre lang von Internet-Startups wie Twitter, AirBNB und anderen eingesetzt. 2013 haben einige der MesOS-Entwickler darüber nachgedacht, auch eine Version als Produkt herauszubringen, und diese Idee dann realisiert.

Wie groß ist Ihr Unternehmen heute und wie verdienen Sie Ihr Geld?

Michael Hausenblas: Mesosphere hat in drei Finanzierungsrunden rund 48 Millionen Dollar Venture-Capital generiert und befindet sich in Privatbesitz. Wir sind rund 150 Mitarbeiter, vor allem im Silicon Valley, aber auch 30 in Hamburg, einige in Berlin und fünf bis zehn in New York. Unser Geld verdienen wir mit der kostenpflichtigen Enterprise-Version von MesOS, eben DCOS.

Es gibt vielleicht zwölf große Unternehmen weltweit, die das benutzen, etwa Verizon USA. Dazu kommen noch viele kleinere Firmen, die mit der kostenlosen Community-Edition in der Cloud arbeiten und zehn bis hundert Knoten betreiben.

Mit wem sehen Sie sich im Wettbewerb? Auch mit Herstellern von so genannter Composable Infrastructure, wie sie etwa HP mit Synergy herausgebracht hat, oder mit hyperkonvergenten Lösungen?

Michael Hausenblas: Zu den Produkten von HP kann ich nichts sagen, weil ich mich darüber nicht informiert habe, wobei wir eng mit dem Hersteller kooperieren. Hyperkonvergente Lösungen habe ich nie als unsere Konkurrenten betrachtet, ich finde, mit ihrem Konzept, alle Infrastrukturkomponenten in eine Hardware zu integrieren, tun sie fast das Gegenteil von DCOS. Am ehesten könnte man noch CentOS mit Tectonic oder auch Docker Inc. hinsichtlich des Umgangs mit Containern mit uns vergleichen, aber im Grunde sind wir einmalig.

Wieso?

Michael Hausenblas: CentOS hat sich auf Kubernetes als Framework oder Service festgelegt, für uns ist Kubernetes nur eines von 40 Frameworks, die wir unterstützen, und es werden immer mehr. Wir arbeiten diesbezüglich mit sehr vielen Partnern zusammen, zum Beispiel mit Cisco, das etwa das Search Framework für MesOS anbietet, oder mit Microsoft.

Auch verteilte Filesysteme oder Big-Data-Anwendungen gibt es als MesOS/DCOS-Framework. Unser System erledigt eigentlich auf Basis des MesOS-Linux-Kernel nur die Ressourcen-Abstraktion und bietet den Frameworks, die für die einzelnen Aufgaben zuständig sind, die nötigen Schnittstellen. Dieses Frameworks werden von uns zertifiziert, so dass sich Anwender auf eine gewisse Qualität verlassen können.

Wie ist DCOS im Detail aufgebaut?

"Im Grunde sind wir einmalig", sagt Michael Hausenblas, Developer Evangelist bei Mesosphere. Denn das leiste keine andere Technik.
"Im Grunde sind wir einmalig", sagt Michael Hausenblas, Developer Evangelist bei Mesosphere. Denn das leiste keine andere Technik.
(Bild: Mesosphere)

Michael Hausenblas: Der Linux-Core kann auf Bare Metal laufen oder auf einer virtuellen Maschine. Einzige Voraussetzung ist, dass die Hardware 64-Bit-Linux zulässt. Derzeit versucht die Entwickler-Community, MesOS auch auf Windows bereitzustellen, auf unserer Entwicklerkonferenz im September gab es einen Prototypen zu sehen. MesOS besteht ja eigentlich nur aus einem Scheduler und einem Executor, der die Tasks ausführt.

Im Detail stellen die Hardwaresysteme unter MesOS vier verschiedene Ressourcen bereit: CPU-Shares, Hauptspeicher, Disk und Ports, wobei der Administrator entscheiden kann, ob diese Ressourcen jeweils vollständig oder nur teilweise in die MesOS-Umgebung einfließen sollen. Zusätzlich gibt es so genannte Attribute, mit denen sich beispielsweise kommunizieren lässt, dass ein Knoten über SSD-Speicher verfügt.

MesOS-Agenten verwalten die lokalen Ressourcen, während der MesOS-Master die Infrastrukturparameter an den integrierten Scheduler gibt, der sie wiederum den darüber implementierten Frameworks mitteilt. Neben dem Scheduler des Masters bringt noch jedes Framework seinen Scheduler mit, der die Ressourcen verwaltet, die von MesOS vorher zugeteilt wurden. Dafür kann man Regeln formulieren, zum Beispiel, dass bestimmte Jobs nur auf Cores mit angeschlossenem SSD-Speicher zugreifen dürfen.

Inwieweit lassen sich externe Speichereinheiten, etwa eine Isilon oder eine 3Par, an ein System unter DCOS anschließen und gemeinsam mit dem Rest verwalten?

Michael Hausenblas: Die Implementierung kommt gerade in Gang, es gibt hierzu eine Kooperation mit EMC. Bisher verwaltete MesOS nur die genannten vier internen Ressourcen.

Vor einigen Monaten wurde nun ein Konzept für die Integration so genannter externer Ressourcen, beispielsweise Speichersysteme oder IP-VLANs, entwickelt. Breit umgesetzt ist das aber noch nicht, die ersten Implementierungen bewerkstelligen es noch mit Workarounds. Immerhin gibt es jetzt ein Design-Dokument, aber es muss sich erst noch zeigen, in welchen Anwendungsfällen und unter welchen Umständen das interessant ist.

Inwiefern ist es für Unternehmen überhaupt sinnvoll, auf eine DCOS-Umgebung umzusteigen, wenn sie funktionierende VMware-Rechenzentren betreiben? Man kann ja MesOS/DCOS auf VMs betreiben, wie Sie vorhin sagten, aber das ist doch eigentlich eine Dopplung.

Michael Hausenblas: Das ist im Prinzip richtig. Im Umgang mit den Unternehmen muss man eben berücksichtigen, dass sie ihre Investitionen schützen müssen. Natürlich sollen die nicht verloren gehen. Sie implementieren eine neue Lösung wie MesOS nur, wenn sie funktioniert und sich rechnet.

Die Kunden nutzen MesOS derzeit auf bestimmten Plattformen und mit begrenzten Zwecken, beispielsweise mit Marathon und Kubernetes, um monolithische Anwendungen auf Mikroservices umzubauen und so flexibler zu machen, im Big-Data-Sektor setzt man Lösungen wie Smart und Kafka ein.

Gibt es auch Anwendungen ans dem High-Performance-Computing?

Michael Hausenblas: Einige Frameworks unterstützen auch Aufgaben aus dem High Performance Computing, aber eigentlich hat das einen anderen Ansatz: Beim HPC geht es darum, möglichst viele Ressourcen zu bündeln, um eine große Aufgabe möglichst schnell zu erledigen, es geht also eher um eine grobkörnige Ressourcenbündelung. DCOS ermöglicht die parallele Nutzung derselben Ressourcen durch unterschiedliche Frameworks, um sie optimal auszulasten, mit Auslastungsgraden von 80, 90 Prozent. Die Ressourcen werden also viel feinkörniger verteilt.

Derzeit spricht alles von Mikroservices. Wird dabei nicht oft der Koordinierungs- und Steuerungsaufwand, den solche Services und die dazugehörigen Softwareprojekte erfordern, unterschätzt?

Michael Hausenblas: Im Mittelpunkt steht dabei tatsächlich im Moment die Idee, dass kleinere Teams schnell kleinere Softwareservices realisieren sollen. Im Grunde ist die ganze Technologie noch in einem sehr experimentellen Stadium, es gibt nur wenige bekannte Anwender, etwa Netflix, es muss sich also erst zeigen, ob das so funktioniert, wie sich viele erträumen. Im Übrigen ermöglicht DCOS zwar Microservices, ist aber natürlich kein Wundermittel.

Fehlerquellen beim Einsatz von DCOS

Wird das Netzwerk bei Mikroservices nicht automatisch zum Engpass, weil sie sich ständig koordinieren müssen?

Michael Hausenblas: Die meisten Rechenzentren sind heute on premise mit 10 Gigabit pro Sekunde vernetzt, manchmal noch schneller. Das reicht in der Regel.

Ortsübergreifend zwei RZ-Clouds mit DCOS zu einer Ressource zu vernetzen, indem man einen gemeinsamen Scheduler darüber legt und die beiden Rechenzentren mit je einem Agent ausstattet, und dann Mikroservice-Umgebungen dort laufen zu lassen, würde ich nicht empfehlen, höchstens in Konstellationen, in denen das zweite RZ als Ausfalllokation fungiert. Aber zu alledem gibt es noch zu wenige Erfahrungen.

Welche anderen Fehlerquellen gibt es in MesOS/DCOS-Umgebungen?

Michael Hausenblas: Man sollte bei der Cluster-Größe nicht übertreiben, um im Fehlerfall keine allzu große Fehlerdomain zu haben. Tatsächlich gibt es schon DCOS-Umgebungen mit Tausenden von Knoten, die aber meist in mehrere Cluster unterteilt sind. Eine andere Fehelrquelle sind Applikationen, die keine Ressourcenbegrenzung haben. Der MesOS-Kern ist zwar auf Ressourcenfairness ausgelegt, aber nicht jede Applikation setzt das um. Konformes Verhalten muss im Grunde in die Applikation hinein programmiert werden, wie beispielsweise bei „Google Borg“, der Cluster-Produktionsumgebung von Google.

Was heißt das für den Betrieb von Alt-Applikationen unter MesOS?

Michael Hausenblas: Der Administrator kann die Applikationen beispielsweise im Marathon-Framework durchaus mit Ressourcen-Restriktionen belegen und sollte das auch tun. Schließlich kann man etwa unter Marathon jedes beliebige Shell-Skript oder jede beliebige Java-Applikation ablaufen lassen, auch wenn das Fehler erzeugt.

Wie sicher ist DCOS?

Michael Hausenblas: SSL-Verschlüsselung on the Wire ist schon in MesOS realisiert. Viele MesOS-Systeme laufen in hochsicheren Umgebungen. Unsere kommerzielle Variante DCOS ist noch um andere Sicherheitsverfahren erweitert, sie unterstützt zum Beispiel Active Directory und LSAP.

Was bietet DCOS ansonsten mehr als MesOS?

Michael Hausenblas: Wir liefern eine komfortable Benutzerschnittstelle, die das gesamte Rechenzentrum mit seinen Komponenten zeigt. Wir haben eine Befehlszeile fürs Skripting, Logs und andere Jobs. Und wir haben zwei freie App-Stores mit Jason-Files auf Github, Multiverse und Universe. In Multiverse kann jeder Anwendungen hineinstellen, die in unserer Umgebung verfügbar sein sollen. Universe enthält die Anwendungen, die etwas stabiler sind und die wir getestet und zertifiziert haben.

Wie geht die Entwicklung weiter?

Michael Hausenblas: Apache MesOS befindet sich derzeit in Version 0.26, wird aber schon für Real-World-Anwendungen genutzt, so läuft Apples gesamte „Siri“-Lösung seit über einem Jahr auf MesOS. Ich glaube aber, dass Version 1 bald erreicht wird. Demnächst sollen Persistent Primitives für Stateful-Anwendungen dazukommen.

Bei ihnen müssen bestimmte Verarbeitungsschritte aus Konsistenzgründen gespeichert werden, bis die Transaktion entweder beendet oder abgebrochen wird, im letzteren Fall muss man das System auch zurücksetzen. Beispiele dafür sind Datenbanken. Außerdem verbessern diverse Funktionen das Networking, etwa durch IP-Adressen für Container.

Wo sehen Sie Datacenter-Betriebssysteme wie MesOS/DCOS in drei Jahren?

Michael Hausenblas: Das ist schwer zu sagen, aber sicher ist, dass die Verbreitung der Containertechnologie die Migration von virtuellen Maschinen auf Container zu beschleunigen. Schließlich macht inzwischen fast jeder was mit Containern. Dadurch wird man wohl auf Dauer erkennen, dass man virtuelle Maschinen in der klassischen Form eigentlich nicht braucht. Was das für bestimmte Workloads oder Anbieter bedeutet, kann ich nicht einschätzen. Dafür ist es einfach zu früh.

* Ariane Rüdiger ist freie Autorin und Fachjournalistin in München.

Artikelfiles und Artikellinks

(ID:43805891)