Cloud Stack

Seit ein paar Wochen flimmert die neue Werbung der Telekom über den Äther. Dort ist die Rede von “der Telekom-Cloud”, mit dessen Hilfe man seine Videos von jedem beliebigen Gerät in “die Cloud” laden und von dort anschauen kann.

Mit der Einführung des iOS von Apple gibt es nun auch dort für jeden Konsumenten sichtbar “die Cloud” – namentlich iCloud. Kollegen aus dem Büro verwenden nun schlagartig den Begriff “die Cloud” und das zunehmend inflationär – seitdem sie ein Update für ihr iPhone geladen haben.

Der Ausfall eines Switch bei RIM in Irland und die damit verbundenen Einschränkungen beim Black-Berry Dienst waren plötzlich auch ein Problem, das durch “die Cloud” verursacht wurde.

Woher kommt dieser plötzliche Anstieg der Präsenz in den Medien? Positiv kann dabei sicherlich vermerkt werden, dass das Cloud Computing entgültig im Markt angekommen zu sein scheint. Was damit aber anscheinend auch zwangsläufg einher geht, ist die unscharfe Betrachtung, was es mit Cloud Computing eigentlich auf sich hat bzw. was Cloud Computing ist und was es nicht ist.

Die Telekom-Cloud ist ein Web-basierter Speicherdienst, den es in dieser Form schon seit Jahren gibt. Die iCloud von Apple ist eine gelungende Weiterentwicklung von MobileMe – ein Dienst, der bei seinem Start im Jahre 2008 noch nichts mit dem Cloud Computing zu tun hatte und es aus Sicht des Autors auch heute noch nicht hat. Schlussendlich wäre der Switch bei RIM auch dann ausgefallen, wenn es das Cloud Computing gar nicht geben würde. Single-Points-Of-Failure sind so alt, wie das Konzept der zentralisierten IT-Infrastruktur.

Nachdem in der Cloud Computing-Community nach den ersten Jahren der Buzzwords mittlerweile die sachliche und forschungsorientierte Diskussion beginnt, bedeutet “die Cloud” im Consumer-Bereich leider wieder einen Rückschritt. Bleibt abzuwarten ob das Thema wieder auf eine sachliche Ebene zurückfindet, oder wir uns daran gewöhnen müssen, dass nun jeder “die Cloud” für sich entdeckt hat.

Nachdem wir bereits im Juni über VMwares PaaS-Strategie berichtet haben, gibt es nun Neuigkeiten um das neuste Kind in VMwares PaaS-Familie – CloudFoundry.

Grafik: VMware Blog

Mit “Micro Cloud Foundry” kommt die offene Laufzeitumgebung nun in Form in einer einzelnen VM, die auf nahezu jedem beliebigen Rechner (Windows, Linux und Mac OS mit VMware Workstation, VMware Player und VMware Fusion) ausgeführt werden kann – so zum Beispiel auf dem Notebook des Softwareentwicklers. Damit sollen Anwendung noch leichter und kostengünstiger für die Cloud entwickelt werden können, da eine Überführung von Micro Cloud Foundry (z.B. lokale Entwicklung) zum regulären Cloud Foundry (z.B. Test, Betrieb) einfach möglich ist.

Konkret unterstützt eine Micro Cloud Foundry VM bei der Entwicklung von Java, Ruby on Rails/Sinatra und Node.JS. Datenbank-Services wie  MySQL, MongoDB und Redis sind ebenfalls vorkonfiguriert vorhanden – die Unterstützung für weitere Frameworks, Datenbanken und Messaging-Dienste sind in Arbeit. Die Integration in die Eclipse-basierte Entwicklungsumgebung STS (Spring Source Toolsuite) rundet die Entwicklerunterstützung ab.

Um sich davon zu überzeugen, dass es sich bei Cloud Foundry nicht nur um eine technische Spielerei handelt, sondern dass es bereits große Verwendung findet, kann man sich hier eine Liste von Anwendungen ansehen, die bereits auf Basis von Cloud Foundry laufen.

Klassische Datenbanken

Abseits der immer beliebter werdenden Dokumenten-orientierten Datenbanken für nicht oder wenig strukturierte Inhalte (S3, CouchDB etc.) gibt es auch Cloud Services für klassische relationale Datenbanken. Amazon zum Beispiel unterstützt mit seinem Dienst RDS MySQL und Oracle Datenbanken. Microsoft setzt mit SQL Azure auf die hauseigene SQL Server Technologie. Salesforce offeriert mit database.com ebenfalls eine relationale Datenbank – schweigt sich über die verwendete Technologie auf der offiziellen Seite jedoch aus. Diese Datenbanktechnologien sind ausgereift und werden in nahezu allen Unternehmen verwenden, die Daten verarbeiten. Doch können sind diese Datenbanken wirklich von den Vorteilen des Cloud Computings profitieren?

Problemfelder

Die Nutzung von Datenbanken, die als Service durch einen Cloud Provider wie Amazon oder Microsoft zur Verfügung gestellt werden, ist in vielen Szenarien nur schwer zu realisieren:

1. Isolation
   Datenbanken stehen selten für sich alleine, sonder interagieren stets mit anderen Systemen. Entschließt man sich nicht dazu alle Systeme in die Cloud zu übertragen, so entstehen hybride Architekturen.
2. Latenz
   Soll nun also eine Datenbank in die Cloud verlagert werden, müssen bestehende Anwendungen, die bisher mit ihr kommunizieren, auch weiterhin auf sie zugreifen können. Durch die Portierung zu einem Cloud Provider entstehen dabei aber enorme Unterschiede bei der Zugriffszeit. Die Zeit, die Datenpakte von einem lokalen Applikationsserver zu einer entfernten Cloud-Datenbank benötigen, ist deutlich größer als im rein lokalen Szenario. Auch wenn, wie in diesem Beispiel, der Applikationsserver nicht mehr lokal sondern bei einem anderen Cloud Provider betrieben wird, entstehen je nach Entfernung und Anbindung der beiden Provider ebenfalls Latenzen. Somit bleibt also kaum eine andere Wahl, außer neben der Datenbank auch alle von ihr abhängigen Server ebenfalls in die Cloud zu migrieren.
3. Sicherheit
   Erfolgt die Datenübertragung nicht mehr ausschließlich im eigenen Rechenzentrum oder innerhalb der Infrastruktur eines Cloud Providers, muss die Verbindung zwischen Datenbank und auf sie zugreifenden Servers verschlüsselt sein. Ein essentielles Feature, dass bei den eingangs genannten Diensten mittlerweile jedoch zum Standard gehört.
4. Datenmigration
   Die Portierung einer bestehenden Datenbank zu einem Cloud Provider kann sich aufgrund der bereits beschrieben Faktoren als kompliziert erweisen. Hinzu kommt jedoch noch die Datenmigration. Die Übertragung lokaler Daten über das Internet zu einem Cloud Provider kann auch bei einer schnellen Datenanbindung zu einer langwierigen Aufgabe werden. Besonders für Datenmengen im GB oder TB Bereich spricht man hier nicht mehr von Stunden, sondern vielmehr von Tagen und Wochen. Anbieter wie Amazon versuchen diesem Problem mit einem Send-In-Service zu entgegnen, der das Einschicken von Datenträgern ermöglicht.

In Anbetracht der aufgezeigten Probleme scheint eine hybride Architektur, bei der Datenbank- und Applikationsserver bei unterschiedlichen Cloud Providern oder an unterschiedlichen Standorten betrieben werden, wenig sinnvoll. Hat man jedoch die Entscheidung getroffen eine relationale Datenbank aus der Cloud zu nutzen, offenbaren sich neue Hürden, die es zu nehmen gilt.

Warum Datenbanken besondere Cloud Service sind

Diese Hürden erkennt man besonders gut daran, wenn man versucht die häufig zitierten Vorteile der Cloud auf Datenbanken zu übertragen.

1. Skalierbarkeit/Elastizität
   Eine Datenbank kann die gleichen Skalierungsanforderungen haben, wie beispielsweise ein Webserver. Greifen viele Anwender auf die Datenbank zu, so sollte die zugrunde liegende Hardware möglichst skalieren, so dass die Datenbank auch bei Zugriffsspitzen möglichst performant bleibt (horizontale Skalierung). Im Gegensatz zu einem Webserver benötigt eine Datenbank jedoch im Laufe ihres Lebenszyklus kontinuierlich mehr Speicher (vertikale Skalierung). Neben den herkömmlichen Skalierungsverfahren (manuell, Schedules, Lastdiagnosen) müssen auch zusätzliche Mechanismen vorhanden sein, die ein fortlaufendes Wachstum der Datenbank ermöglicht – ohne das durch den Nutzer aktiv eingegriffen werden muss. Der Zustand, dass z.B. Datenbanken bei Amazon RDS nicht mehr erreichbar sind, wenn sie ihre (beim Setup festgelegte oder manuell zugewiesene) Größe ausgeschöpft haben, ist kaum akzeptabel.
2. Fehlertolleranz
   Was mit cleveren Diensten wie Scalarium begann, wird zunehmend von den Cloud Providern für ihre typischen IaaS übernommen. Das zusammenschalten von mehreren Nodes zu Clustern hat besonders im Bereich Auto/Self-Healing und Failover vieles an Konfigurationsaufwand dem Anwender abgenommen. Eine Übertragung dieser Konzepte auf relationale Datenbanken mit ihren cleveren Clusterring- und Replikationsmechanismen ist wünschenswert.
3. Abrechnung
   Auch wenn relationale Datenbanken mit modernen Key-Value-Datenbanken vielleicht nicht viel gemein haben, so geht es im Wesentlichen doch immer um das Speichern von Daten. Verwunderlich ist dabei, dass man z.B. bei Amazon für den S3 nach GB bezahlt und bei RDS nach Instanz und GB (die Kosten für Traffic und I/O bleiben hier außen vor). Dieser Instanz-Gedanke entstammt dabei sicherlich den horizontalen Skalierungsmöglichekeiten, die sich nach den typischen Instanzklassen von Amazon richtet – nachvollziehbar erscheint er aus Servicesicht nicht, geht es doch eigentlich nur um den Speicherplatz von Daten. Hier sind andere Anbieter wie Microsoft SQL Azure oder database.com bereits weiter.

Schlussbemerkung

Die hier dargestellten Gedanken erheben natürlich keinen Anspruch auf Vollständigkeit, aber sie haben vielleicht zumindest ein Gefühl dafür vermittelt welche Probleme noch zu nehmen und welche Wünsche noch offen sind, um relationale Datenbank erfolgreich in der Cloud zu platzieren. In Anbetracht des hart umkämpften Marktes kann man als Anwender nur darauf hoffen, dass die entsprechenden Cloud Provider dem Bereich Database as a Servie bald wieder mehr Aufmerksamkeit widmen werden, um sich durch neue Features von ihren Wettbewerbern abzugrenzen.

Nach der Sommerpause gibt es wieder einen neuen Blogpost bei Cloud Stack.

Für ein aktuelles Kundenprojekt (Individualentwicklung – J2EE/Swing Web-Application) haben wir mit Hilfe des Free Usage Tier der AWS ein kostenloses Testsystem mit Tomcat 7 und MySQL-Datenbank für unseren Kunden erstellt. Da die spätere Produktionsumgebung eine MSSQL-Datenbank vorsieht und wir die Anwendungsentwicklung lokal ebenfalls aus Kostengründen gegen eine MySQL-Datenbank vorgenommen haben, bestand nun der Bedarf nach einem ausgiebigen Kompatibilitätstest der Anwendung und damit verbunden die Migration von einer MySQL-Datenbank zu einer MSSQL-Datenbank. Im Folgenden schildern wir unsere Erfahrungen aus der Migration von MySQL hinzu MSSQL.

Microsoft SQL Azure

Um unserem Kunden eine preisgünstige und flexible MSSQL-Datenbank zur Verfügung stellen zu können, die darüber hinaus für uns in der aktuellen Phase der Anwendungsentwicklung den administrativen Aufwand gering hält, haben wir uns für die relationale Cloud-Datenbank „SQL Azure“ von Mircosoft entschieden – Alternative relationale Cloud-Datenbanken, wie beispielsweise Amazons RDS kamen aufgrund der expliziten Anforderung an eine MSSQL-Datenbank nicht in Frage.

Ausgangspunkt der Migration war eine MySQL-Datenbank. Die ausgesprochen gute und in diesem Fall auch kostenlose Toolunterstützung auf Seiten von Microsoft bescherte im Hinblick auf die Migration schnelle Erfolge. Mit Hilfe des “SQL Server Migration Assistent” (SSMA) konnte somit die bestehende MySQL-Datenbank im Hinblick auf die Migration zu Microsoft SQL Azure auf Inkompatibilitäten untersucht, ihr Datenbankschema konvertiert und abschließend die enthaltenen Daten zur neuen Datenbank migriert werden. Eine lesenswerte Hilfestellung findet sich hierfür bei MSDN.

Mit großer Freude konnten wir feststellen, dass der sprachliche Funktionsumfang von Microsoft SQL Azure mittlerweile einem handelsüblichen MSSQL-Server in der 2008er Version in (fast) nichts mehr nachsteht. Auch die Konvertierung des MySQL-Datenbankschema (22 Tabellen mit entsprechenden Foreign-Key-Constraints) brachte keine Kompatibilitätsprobleme zum Vorschein.

Nach der erfolgten Migration der Datenbank war es dank der Verwendung eines entsprechenden Perstistenz-Frameworks (hier: Hibernate) in der zu entwickelnden Anwendung nur noch erforderlich die Datenbankparameter von der MySQL-Datenbank auf die MSSQL-Datenbank bei Microsoft SQL Azure umzustellen. Abgesehen von den höheren Zugriffszeiten im Vergleich zur zuvor lokalen MySQL-Datenbank gab es mit der Umstellung auf die Cloud-Datenbank keine Einbußen an Funktionalität oder Kompatibilität.

Es bleibt somit festzuhalten, dass Microsoft SQL Azure in der Vergangenheit große Fortschritte gemacht hat und die Cloud-Datenbank mittlerweile sehr gut in die Produktpalette der Entwicklungs- und Administrationstools von Microsoft integriert ist. Auch die Web-basierte Verwaltungskonsole der Cloud-Datenbank hat nach einem Update im neuen Silverlight-Gewand einen größeren Funktionsumfang erhalten. Einzig die Usability scheint an der einen oder anderen Stelle noch ausbaufähig zu sein.

Open Cloud ist eine Initiative, die laut heise die Interoperabilitätin der Cloud fördern will. Ziel ist es die rechtlichen Rahmenbedingungen für die Anforderungen an eine Open Cloud zu definieren und somit die Grundlage für Cloud-Services zur Verfügung zu stellen. Geleitet wirde die Initiative von einem Team aus Direktoren, darunter Noirin Plunkett Executive Vice President der Apache Software Foundation, Rick Clark Principal Engineer für das Cloud Computing bei Cisco Systems oder auch Thomas Uhl Gründer der Cloud-Initiative Deutsche Wolke.