Clouds braucht offene Standards

Noch immer ist bei Cloud Computing vieles in Bewegung. Standards haben sich bisher aber noch keine etabliert. Jeder Betreiber und auch sehr viele proprietär ausgerichtete Techniklieferanten folgen ihren eigenen Vorstellungen, wie eine Cloud aus Applikationssicht angesteuert, betrieben und veraltet werden sollte. Beispiele dafür sind die in den letzten Jahren entstandenen öffentlichen Clouds wie Amazon Elastic Compute Cloud (EC2), Amazon Simple Storage Service (S3) oder JiffyBox. In den USA kommen Anbieter wie GoGrid, Rackspace und Terremark dazu.

Das Angebot öffentlicher Clouds wird ergänzt durch die vielen von Unternehmen implementierten privaten Clouds, bei denen Applikationen und Computing Services über das eigene LAN/WAN bereitgestellt werden. In den USA betreiben Unternehmen bereits Dutzende von Clouds, in Deutschland dagegen befinden sich viele Organisationen noch im Experimentierstadium und nur wenige haben die ersten privaten Clouds tatsächlich im produktiven Betrieb. Reicht die Leistungsfähigkeit der internen Clouds nicht mehr aus, wäre es wünschenswert, zusätzliche Ressourcen öffentlicher Clouds nutzen zu können. Was lange Zeit fehlte, war die Verknüpfung beider Welten.

Für unabhängige Softwarehersteller ist dies eine beachtliche Herausforderung, denn sie müssen bereits bei der Entwicklung einer Anwendung entscheiden, in welcher der bestehenden Clouds ihre Software laufen soll. Das Erscheinen jeder neuen Cloud mit eigenem API verursacht zusätzlichen Aufwand. Es gibt daher gute Gründe für eine konsistente, standardisierte Cloud-Computing-API. Red Hat entschloss sich daher im Herbst 2009, diese Lücke mit dem Open-Source-Projekt Deltacloud zu schließen, das sowohl ein einheitliches Interface definiert als auch Adapter für die wichtigsten öffentlichen und privaten Clouds implementiert. Damit wird der Aufwand, neu erscheinende Clouds zu unterstützen, von den Applikationen hin zu Deltacloud verschoben.

Im Frühjahr 2010 hat Red Hat die bis dahin fertiggestellte Deltacloud-Schnittstelle mit allem dazugehörigem Code zur weiteren Bearbeitung an den Incubator der Apache Software Foundation übergeben. Das Projekt wird seitdem dort unter der Bezeichnung Apache Deltacloud fortgeführt, was die Herstellerunabhängigkeit sichert. Ebenso wie andere Apache-Projekte wird auch Deltacloud von einer Vielzahl von Beteiligten aus unterschiedlichen Unternehmen und Organisationen weiterentwickelt, die sich den Prinzipien offener Softwarelizenzen und einer benutzergesteuerten Innovation verpflichtet haben.

Kommunikation via REST-Schnittstelle

Die Datenkommunikation im Deltacloud-API erfolgt über die REST-Schnittstelle zu einem Deltacloud-Server, der ebenfalls über ein REST-Interface verfügt. Um die Benutzung der REST-Schnittstelle zu vereinfachen, stellt das Deltacloud-Projekt sowohl ein CLI-Tool (Command Line Tool) als auch Client-Bibliotheken in Ruby, Java, C und Python zur Verfügung.

Neben Deltacloud gibt es weitere Open-Source-Projekte, die Cloud-Abstraktions-APIs entwickeln. Zu nennen sind hier jclouds, libcloud, boto und fog. All diese Bibliotheken sind jedoch jeweils an eine bestimmte Programmiersprache gebunden: jclouds an Java, libcloud und boto an Python und fog an Ruby. Es handelt sich immer um sprachspezifische Libraries. Deltacloud ist dagegen sprachunabhängig und das einzige Cloud-Abstraktions-API, das sich als Web-Service nutzen lässt. Der Vorteil: Durch den Einsatz vorhandener und weit verbreiteter Standards wie HTTP und XML entsteht eine offene Architektur, die unabhängig von den verwendeten Plattformen und Programmiersprachen ist.

Da das Deltacloud-API als Web-Service statt als Bibliothek realisiert ist, lässt sich der Deltacloud-Server in einer von zwei Grundkonfigurationen betreiben: Entweder nahe am Benutzer, beispielsweise auf einem lokalen Rechner beziehungsweise im LAN, oder nahe am nativen API des Cloud-Anbieters – letzteres ist besonders für private Clouds von Interesse. Anbieter können Deltacloud natürlich auch direkt als ihr einziges Interface bereitstellen.

Der Deltacloud-Server selbst ist mit dem Ruby-Framework Sinatra programmiert. Intern besteht der Server-Code aus zwei großen Bereichen: Der erste generische Teil widmet sich den für einen Web-Service typischen Aufgaben, wie das Entgegennehmen und Deserialisieren von HTTP-Requests und dem Formatieren der Responses. Den zweiten Teil bilden die unterschiedlichen Treiber für verschiedene Clouds: Amazon EC2, vCloud, Azure etc. Beide Teile sind über eine einfache interne Schnittstelle miteinander verbunden, was es ermöglicht, Treiber für neue Cloud-APIs ohne allzu tief gehendes Wissen des eigentlichen Servers zu erstellen. Erfahrungen zufolge lässt sich ein neuer Treiber innerhalb weniger Tage implementieren.

In einem vereinfachten Ablauf startet ein Client einen Request via REST-Interface an den Server. Anschließend leitet der Treiber im Deltacloud-Server die Anfrage an die dedizierte Cloud weiter. Der Server ist stateless, es werden keine Zustands- oder Sitzungsinformationen gespeichert. Stattdessen sendet der Client die für die jeweils gewählte Cloud benötigten Zugangsinformationen mittels des Headers für Basic HTTP Authentication mit jedem Request mit. Wurden bisher die anzusprechende Cloud und deren API-URL beim Start des Deltacloud-Servers festgelegt, wird es mit der nächsten Version von Deltacloud möglich sein, beides über zusätzliche HTTP Request Headers auszuwählen. Damit ist es möglich, beliebig viele Clouds mit demselben Deltacloud-Server zu benutzen.

Definition einer Basisschnittstelle

Deltacloud vermeidet das Problem des kleinsten gemeinsamen Nenners, indem es eine Basisschnittstelle definiert, die von allen Treibern unterstützt wird. Hinzu kommen treiberspezifische Erweiterungen, deren Unterstützung durch einen bestimmten Treiber vom Client durch einfache Mechanismen entdeckt werden kann. Das Ziel dabei ist, dass Clients niemals wissen müssen, mit welcher Cloud sie via Deltacloud verbunden sind, sondern alle Fragen über Cloud-spezifische Unterschiede mittels detaillierter Hinweise in den Responses des Deltacloud-Servers entdecken können.

Das API verfügt über genau einen Single Entrypoint, was als Best Practice in der REST-Welt gilt. Das XML-Dokument, das unter der URL des Entrypoints zu erreichen ist, enthält umfangreiche Informationen über alle Ressourcen, die über den Deltacloud-Server verfügbar sind. Diese umfassen Images, Instances, Realms, Hardwareprofile etc.

Neben URLs zum Auflisten jeder dieser Ressource-Collections enthält das XML-Dokument auch Hinweise über treiberspezifische Erweiterungen. Clients erhalten zum Beispiel einen Hinweis, ob und mit welchem Mechanismus die jeweils verwendete Cloud es erlaubt, benutzerdefinierte Daten in neue VM-Instanzen bei deren Start zu injizieren. Diese Operation ist zum Personalisieren neuer Instanzen enorm wichtig. Sie wird aber leider nicht von allen Cloud-Providern unterstützt, und von denen, die sie unterstützen, in völlig unterschiedlicher Weise angeboten.

Lifecycle einer Cloud

Von Cloud zu Cloud unterscheiden sich die verschiedenen Stati, die eine virtuelle Maschine während ihres Lifecycles durchläuft. Differenzen gibt es nicht nur in der Benennung von logisch äquivalenten Zuständen und Operationen, sondern auch in der Anzahl und Abfolge der Zustände. Deltacloud stellt Clients daher ein vereinheitlichtes Modell des Cloud-spezifischen Lifecycles in Form eines endlichen Automaten zur Verfügung. Darin werden nicht nur Namensunterschiede nivelliert, sondern ein Client kann auch erkennen, welche Operationen abgearbeitet werden müssen, um zum Beispiel eine momentan laufende virtuelle Maschine anzuhalten und zu löschen.

Auch wenn der generelle Lifecycle einer Cloud bekannt ist, ist es im Allgemeinen schwierig zu ermitteln, welche Operationen, wie Pause, Stop etc., auf einer virtuellen Maschine ausgeführt werden dürfen. Dazu müssen viele, zum Teil cloudinterne, Attribute berücksichtigt werden, beispielsweise Permissions. Deltacloud erleichtert Clients hier das Leben, indem es bei jeder virtuellen Maschine mit angibt, welche Operationen ausgeführt werden dürfen, zum Beispiel wie der momentane Benutzer eine virtuelle Maschine anhalten kann.

Die Realm innerhalb einer Cloud bezeichnet einen abgegrenzten Bereich, der über bestimmte Ressourcen verfügt. Jeder Cloud-Provider definiert diesen Bereich individuell. In einigen Fällen repräsentiert eine Realm unterschiedliche Rechenzentren, Regionen oder auch nur Ressourcen-Pools innerhalb eines einzelnen Rechenzentrums. Ein Cloud-Provider kann beispielsweise darauf bestehen, dass sich alle Ressourcen, die zusammenarbeiten sollen, innerhalb der Realm befinden. Dies gilt etwa für Speichersysteme, die nur unter dieser Bedingung mit Instances verbunden sein können.

Auch bei der Größe der zur Verfügung stehenden virtuellen Maschinen gibt es Unterschiede zwischen den Clouds. Die Angebote unterscheiden sich nicht nur hinsichtlich der Anzahl virtueller CPUs, der Größe des Hauptspeichers und des lokalen Plattenspeichers, sondern auch darin, ob der Benutzer nur virtuelle Maschinen aus einer Liste fester Größen anlegen kann, oder ob es möglich ist, manche der Parameter für die Größe zu ändern. Zum Beispiel mag ein Anbieter nur virtuelle Maschinen mit 1 GB RAM anbieten, während ein anderer es erlaubt, beim Anlegen der VM die Größe des Hauptspeichers zwischen 1 GB und 8 GB in Schritten von 512 MB zu variieren.

Das Deltacloud-API bildet diese unterschiedlichen Möglichkeiten durch Hardwareprofile ab, so dass Clients den vollen Umfang der möglichen VM-Größen sowie aller Parameter, die vom Benutzer beeinflusst werden können, erhalten. Damit müssen Clients nicht wissen, wie genau eine spezifische Cloud die Größe einer neuen VM festlegt, sondern müssen nur das Deltacloud-Modell verstehen.

Ausblick

Wie im Open-Source-Bereich üblich, wird Apache Deltacloud kontinuierlich von einer aktiven Community weiterentwickelt. Ein Thema ist beispielsweise die Unterstützung Cloud-orientierter Speichersysteme wie S3 und CloudFiles. Einen weiteren Schwerpunkt bildet die Erstellung von zusätzlichen Treibern, insbesondere für vCloud, Red Hat Enterprise Virtualization Manager (RHEV-M) und Google Storage.

Erweiterungen werden so gestaltet, dass sie vollständig rückwärts kompatibel sind, damit auch alte Clients problemlos mit neueren Servern kommunizieren können. Diese API-Stabilität umfasst nicht nur die Parameter der HTTP Requests und das XML-Format der Responses, sondern auch Aspekte wie die Fehlercodes und -meldungen, die vom API gemeldet werden.

Deltacloud kommt gegenwärtig in mehreren Projekten zum Einsatz, unter anderem in Red Hats Cloud Engine, SteamCannon und Eclipse. Cloud Engine ist damit befasst, einen Cloudbroker, natürlich in Open Source, zu implementieren. Dabei wird sowohl die Sicht auf die virtuelle Cloud jedes Benutzers als auch die Kommunikation mit den zugrundeliegenden Clouds über das Deltacloud-API abgewickelt. SteamCannon erstellt die Werkzeuge, die nötig sind, um eine eigene Platform-as-a-Service-Cloud für Java- und Ruby-Anwendungen zu betreiben.

Innerhalb des Eclipse-Projekts schließlich werden Plug-ins entwickelt, die das Verwalten von virtuellen Maschinen in Clouds aus Eclipse heraus erleichtern, so dass Entwickler auch komplexe Anwendungsszenarien und -architekturen einfach mit ein paar Mausklicks realisieren können. (ue)