DYNAMISCHE AUSWAHL VON CLOUD-DIENSTLEISTUNGEN ANHAND NICHTFUNKTIONALER EIGENSCHAFTEN

Transkript

1 Fakultät für Informatik Medienformatik, Institut für Systemarchitektur, Professur Rechnernetze Bakkalaureatsarbeit DYNAMISCHE AUSWAHL VON CLOUD-DIENSTLEISTUNGEN ANHAND NICHTFUNKTIONALER EIGENSCHAFTEN Christopher Szabó Mat.-Nr.: Betreut durch: Dr.-Ing. Josef Spillner Eingereicht am 31. Dezember 2011

2 2

3 ERKLÄRUNG Ich erkläre, dass ich die vorliegende Arbeit selbständig, unter Angabe aller Zitate und nur unter Verwendung der angegebenen Literatur und Hilfsmittel angefertigt habe. Dresden, 31. Dezember

4 4

5 TECH N ISCH E UNIVERSITAT DRESDEN Fakultät Informatik, lnstitut für Systemarchitektur, Lehrstuhl Rechnernetze AUFGABENSTELLUNG FÜR DIE BACHELORARBEIT Name, Vorname: Studiengang: Matr.-Nr.: Thema: Szabo, Christopher Medieninformatik Dynamische Auswahl von Cloud-Dienstleistungen anhand n ichtfu nktionaler Eigenschaften ZIELSTELLUNG Ziel der Arbeit ist es, einen Middleware-Dienst zu erstellen, welcher von beliebigen Software-Agenten zur Bereitstellung passend skalierter Cloud-Dienstleistungen genutzt werden kann. Beispielsweise können so Datenproduzenten mit geringen Speicher- und Verarbeitungsressourcen, wie Sensoren oder Roboter, einen passenden Speicherdienst oder eine Dienstausführungsplattform,,in der Cloud" beantragen. Die Auswahl soll dabei Allokations- und Rekonfigurationsmethoden gä ngiger Clouda nbieter u nterstützen und anha nd eines nichtfunktionalen Kriteriums wie dem Preis der angebotenen Dienste eine für den Agenten günstige oder gar opti male Auswahl treffen. Die Konzepte sollen anhand eines (simulierten) Roboters in einer Cloud-Umgebung validiert werden, welcher mit wechselnden Datenmengen den Einsatz und Nutzen eines deraftigen Middleware-Dienstes nachvollziehbar verdeutlicht, SCHWERPU N KTE. Motivation durch kurzen Überblick über Verfahren zur Nutzung von Clouds. Konzeption eines Middleware-Dienstes mit Dreischichtenarchitektur. Validierung unter Nutzung eines Agenten und eines Dienstverzeichnisses. Bewertung der entwickelten Lösung Betreuer: Ve ra ntwo rtl i che r H ochsc h u I I e h rer: lnstitut: Lehrstuhl: Beginn am: Einzureichen am: Dr.-lng. Josef Spillner Prof. Dr. rer, nat. habil, Dr. h. c. Alexander Schill I nstitut fü r Systema rchitektu r Rechnernetze 0t_ ,11 Unterschrift des ve ra ntwo rtl iche n H ochsch u I I eh re rs Verteiler: 1 x Prüfungsamt, 1 x HSL, 1 x Betreuer, 1 x Student 5

6 6

7 INHALTSVERZEICHNIS 1 Einleitung Motivation Stand der Forschung Diese Arbeit Architekturen Cloud Computing Beispiel eines Clouddienstleisters Tools zum Cloudmanagement Webservices Skalierung in der Cloud Skalierung von Rechenleistung RightScale Algorithmus Autoregressives Modell erster Ordnung (AR1) Lineare Regression Skalierung von Cloudspeicher Dynamischer Arbeitsspeicher in der Virtualisierung Skalierung über Schwellenwertberechnung

8 4 Preis von Cloudspeicher als nicht-funktionale Eigenschaft Preismodelle Nutzungsgenau Paketpreis Kostenfunktionen Funktionsentwicklung aus Preismodellen Entwicklung einer Minimalkostenfunktion Nutzungsbasiert Paketpreis Hybrid Implementierung Architekturübersicht Agentenprototyp mit Webservice Schnittstelle Middleware mit Cloud-Webservice Datenbank für Benutzerdaten Benutzerauthentifikation API Beschreibung Dynamisches Dienstverzeichnis Deltacloud als Cloud-Anbindung Installation REST API Besonderheiten unter Windows Vergleichbare Projekte Validierung Anmerkungen zu Clouddiensten Limitationen von Deltacloud I Abbildungsverzeichnis 53 II Bibliographie 55 8 Inhaltsverzeichnis

9 1 EINLEITUNG 1.1 MOTIVATION Die stetig steigende Flut von Daten und der Wunsch nach omnipräsenter Verfügbarkeit von Informationen im Alltag stellen die Informationstechnik vor neue Aufgaben. Um diesen Anforderungen gerecht zu werden, war es notwendig geeignete Technologien einzuführen, ein Ansatz ist der des Cloud Computing. Eine abstrahierte IT-Infrastruktur als Wolke bezeichnet, die Dienste, Datenspeicher, Rechenleistung oder Kommunikationsinfrastruktur dynamisch über ein Netzwerk zur Verfügung stellt. Das Gesamtsystem stellt sich für den Benutzer transparent und entfernt dar. Entgegen der klassischen Sicht der IT, dass Infrastrukturen nur physisch teilbar sind, setzt Cloud Computing auf Virtualisierung und virtuelle Komponenten, abstrahiert aus physischen Ressourcen. Es existieren verschiedene Ansätze zum Thema Virtualisierung. Einerseits kann ein physisches Laufwerk, wie eine Festplatte, in kleinere Einheiten aufgeteilt und diese einzeln verfügbar gemacht werden. Andererseits lässt sich auch ein Plattenverbund aus mehreren Festplatten zu einer verbinden. Dadurch wird der Anschein erweckt ein Laufwerk wäre Physisch obwohl dieses als Virtuelles angeboten wird. Solche Techniken und Abstraktionen bilden die Grundlage für Cloud Computing Dienste, welche infrastrukturelle Ressourcen, wie z.b. Speicherplatz bereitstellen. Kleinstgeräte, Sensoren und Roboter besitzen häufig nur eingeschränkte Hardwareressourcen um ihre Aufgaben vollständig erfüllen zu können. Dies resultiert aus Bestrebungen wie Gewichtsreduktions, Stromverbrauchs- oder Größenminimierung. Somit werden solche Geräte hauptsächlich eingesetzt um Informationen zu sammeln oder auszugeben. Die Verarbeitung der gesammelten Daten kann jedoch bauartbedingt nicht immer lokal erfolgen, das ist beispielsweise bei Sensoren der Fall. Die erfassten Daten werden zur Weiterverarbeitung oder langfristigen Speicherung an eine externe Einheit geschickt. Sensoren produzieren zum Teil sehr große Datenmengen wie z.b. bei der globalen Wetteraufzeichnung. Dabei stoßen genutzte Speichermedien bzw. lokaler Speicher schnell an ihre Kapazitätsgrenzen. Dadurch werden externe Speicher mit anpassungsfähiger Speicherkapazität erforderlich. Für diesen Zweck sind Cloud-Lösungen prädestiniert, da diese technologiebedingt eine hohe Skalierbarkeit und Flexibilität bieten. So lassen sich z.b. Daten bei Clouddiensten wie Amazon S3 oder Adrive im Web speichern, wodurch ein weltweiter Zugriff z.b. zur Weiterverarbeitung möglich wird. 9

10 Im Zusammenhang mit Cloud Computing ist Skalierbarkeit ein zentrales Thema, denn ein wichtiger Vorteil von Clouddiensten im Bereich von Infrastruktur, Rechenleistung oder Speicherplatz ist, die transparente Verfügbarkeit der Ressourcen. Das bedeutet für einen Bedarf an Massenspeicher, dass es sowohl möglich ist sich für ein Paket mit einer festen Speichergröße als auch für eine bedarfsbedingte Speichermenge zu entscheiden. So ist es z.b. möglich ein Paket von 150 GB zu einem Festpreis zu mieten oder die tatsächlich genutzte Speicherplatzmenge in Rechnung gestellt zu bekommen. Gerade bei schwankenden Anforderungen sind solche Angebote von großem Interesse. Neben funktionalen, klar definierten Anforderungen an IT-Systeme, welche eine konkrete Reaktion B auf ein Ereignis A erwarten, existieren meist auch nicht- funktionale Eigenschaften die von Bedeutung sind. Diese können zum Beispiel die Reaktionszeit einer Anfrage betreffen. Nicht-funktionale Eigenschaften im Kontext von Cloud Computing können Zuverlässigkeit, Erreichbarkeit, Reaktionszeit, Skalierbarkeit oder die Kosten für Dienstnutzungen sein. Hier ist von Interesse, wie eine Auswahl von Cloud-Dienstleistern erfolgen kann anhand nicht-funktionaler Eigenschaften.[RR06] Bei Echtzeitsystemen sind minimale Anwortzeiten als nicht-funktionale Eigenschaft von besonderem Interesse. Auch Sprach- oder Videokommunikation sowie Onlinespiele profitieren von Diensten mit schnellen Reaktionszeiten. In Unternehmen ist die maximale Verfügbarkeit von Diensten für Geschäftsprozesse essentiell, damit z.b. Unternehmensziele erreicht werden können. In Kooperationen mit Partnern oder bei Zulieferern könnten Vertragsstrafen im Falle der Nichterfüllung fällig werden. Desweiteren sollten Kosten für Dienste vergleichbar und planbar sein, damit der Etat optimal ausgenutzt oder frühzeitig aufgestockt werden kann. 1.2 STAND DER FORSCHUNG Diverse Arbeiten beschäftigen sich mit dem Thema Skalierung in Zusammenhang mit Clouddiensten. Ein Beispiel dafür ist die Arbeit von Vaquero, Rodero-Merino und Buyya Dynamically Scaling Applications in the Cloud. Dabei werden Themen wie Serverskalierung, Netzwerkskalierung und Skalierung von Plattformen diskutiert [VRMB11]. Gulati, Shanmuganathan und Holler befassen sich in Cloud-Scale Resource Management: Challenges and Techniques mit einigen der wichtigsten Fragen zum Aufbau von cloudbasierten und skalierbaren Ressourcenmanagement-Systemen, sowie Techniken zum Umgang mit diesen Systemen [GSHA11]. In Scaling Into The Cloud von Kupferman, Silverman, Jara und Browne werden Algorithmen vorgestellt um Ressourcen zu skalieren und in einem Bewertungssystem eingeordnet, um deren Güte zu vergleichen [KSJB09]. Weitere Arbeiten von Lim, Babu, Chase und Parek beschäftigen sich mit Automatisierung bzw. Skalierung im Kontext von Cloud Computing [LBCP09, LBC10]. In Dynamic Resource Allocation for Shared Data Centers Using Online Measurements wird ein Framework vorgestellt, welches auf Grundlage der Historie zukünftige Arbeitslast voraussagt und dynamisch Serverressourcen anfordert [CGS03]. Der Schwerpunkt der Forschung zum Thema Skalierung im Zusammenhang mit Cloud Computing lag in der Vergangenheit eher im Bereich der Compute-Clouds. Bei Skalierung von Cloudspeicher hingegen besteht Nachholbedarf. Durch Vergrößerung oder Verkleinerung eines Systems, kann eine Skalierung notwendig werden, wenn z.b. die vorhandenen Betriebsmittel nicht mehr ausreichen oder sich Leerkapazitäten anhäufen. Im Zusammenhang damit sollten auch ökonomische Gesichtspunkte berücksichtigt werden. In der Regel ändern sich mit einer Skalierung eines Systems auch dessen Kosten. Einen erheblichen Kostenfaktor in Unternehmen stellt die IT dar. Neben Personalkosten sind auch der Betrieb von Servern und die Datenspeicherung kostenintensive Komponenten. Zur Kostenberechnung bietet beispielsweise die Plattform Business-Cloud.de den TCO-Kalkulator der Experton Group für den Betrieb von Geschäftsanwendungen an. Dort lassen sich über diverse Parameter, wie Server und Speicherplatzbedarf und voraussichtliche Wachstumsraten 10 Kapitel 1 Einleitung

11 die zukünftigen Kosten für den Betrieb errechnen ( Abbildung 1.1: TCO-Kalkulator von business-cloud.de, beispielhaft ausgefüllt Die zur Berechnung eingegebenen Zahlen sind lediglich ein fiktives Beispiel um die Funktionalität des Kalkulators zu demonstrieren. Aus den erfassten Daten werden schließlich die Kosten für ein Gesamtsystem errechnet. Es erfolgt eine Gegenüberstellung der Kosten im Falle des Eigenbetriebs und einer entsprechenden Cloud-Lösung. Abbildung 1.2: TCO-Kalkulator von business-cloud.de, Ergebnis Die Ergebnisausgabe ist sehr allgemein gehalten und nicht sehr detailliert, so lassen sich einzelne Kostenstellen nicht identifizieren und auch die Art und Weise der Berechnung bleibt unklar. Zudem werden keine konkreten Angaben über Anbieter oder deren Kosten für Dienste gemacht. Bei diesem Kalkulator fehlt die nötige Transparenz, um ihn zur Unterstützung oder Entscheidungsfindung heranzuziehen. 1.2 Stand der Forschung 11

12 Aus all diesen Punkten erwächst der Wunsch nach einer Lösung, Speicher automatisch zu skalieren und dynamisch Cloudspeicherdienste auswählen zu können. Als Entscheidungsgrundlage dafür können nicht-funktionale Eigenschaften, wie Speicherplatzauslastung und der Preis für Speicher dienen. 1.3 DIESE ARBEIT Dem Namen dieser Arbeit entsprechend Dynamische Auswahl von Cloud-Dienstleistungen anhand nicht-funktionaler Eigenschaften wird es im Rahmen dieser Bakkalaureatsarbeit um den Zusammenhang zwischen Dienstleistungen im Kontext von Cloud Computing und nicht-funktionalen Eigenschaften gehen. Als Abgrenzung wird sich hierbei auf Speicherdienstleister beschränkt. Dabei lassen sich für die Kostenmodelle der Dienstanbieter spezifische Kostenfunktionen entwickeln und mathematisch definieren. Dies ermöglicht eine Vergleichbarkeit der Anbieter und mittels zusätzlicher Nebenbedingungen kann für ein bestimmtes Szenario ein Optimum errechnet werden. Außerdem wird durch eine mathematische Funktion eine Verarbeitung in einem Softwaresystem möglich. Diese kann durch eine Logik und folglich eine automatisierte Auswahl bzw. Empfehlung erfolgen. In Abschnitt 2 werden die in dieser Arbeit verwendeten Technologien und Grundbegriffe erläutert. Die beiden zentralen Begriffe Cloud Computing und Webservices werden hier eingeführt. Der 3. Abschnitt befasst sich mit Skalierungsverfahren zur Skalierung von Rechenleistung oder Servern im allgemeinen und Skalierung von Speicherplatz. Verschiedene Algorithmen werden vorgestellt. Der in diesem Abschnitt vorgeschlagene Algorithmus zur Skalierung von Cloudspeicher mittels Schwellenwertberechnung, findet Verwendung im entwickelten Prototypen. Im darauf folgenden Kapitel wird die nicht-funktionale Eigenschaft, Kosten für Cloudspeicher, betrachtet. Hier werden verschiedene Preismodelle der Dienstanbieter vorgestellt und daraus spezifische Kostenfunktionen abgeleitet. Außerdem wird in einem beispielhaften Vergleich eine Minimalkostenfunktion aufgestellt. Im 5. Teil der Arbeit wird die Implementierung des Systemprototypen beschrieben, ein Agentenprototyp mit Webschnittstelle und eine Middelware mit Logik zur Cloudskalierung und zur Dienstanbieterauswahl. Deltacloud wird als plattformübergreifende Variante zur Cloudanbindung vorgestellt. Im letzten Kapitel erfolgt die Validierung des Systemszenarios, welches mit dem Prototypen umgesetzt wurde. Das Szenario, ein Agent in Form eines einfachen Webservices soll Daten in der Cloud speichern können. Dieser ruft einen weiteren Webservice auf, welcher die Auswahl eines geeigneten Dienstes übernimmt. Die Wahl des Anbieters erfolgt dabei anforderungsspezifisch durch eine Logik. Dabei soll der Dienst die nicht-funktionalen Eigenschaften, die Auslastung des Speicherplatzes und den Preis für den Speicher bzw. die entstehenden Kosten für die Entscheidungsfindung berücksichtigen. 12 Kapitel 1 Einleitung

13 2 ARCHITEKTUREN 2.1 CLOUD COMPUTING Die Wolke (englisch cloud ) bezeichnet in der IT-Landschaft einen Ansatz für eine abstrahierte IT-Infrastruktur, dazu gehört die Nutzung von Datenspeichern, Netzwerk- und Rechenkapazität sowie Softwaresystemen. Das Besondere dabei ist, dass Nutzer Leistungen nach jeweiligem aktuellen Bedarf nutzen können und sich dieser stets dynamisch an die aktuellen Anforderungen anpassen lässt [AFG + 09, S.4]. Aus Sicht des Nutzers lässt sich die Cloud nach privaten sowie öffentlichen Clouds unterscheiden. Private Clouds sind z.b. Strukturen in Unternehmensnetzwerken die Dienste für die Mitarbeiter bereitstellen, sowohl für die Arbeit im Unternehmen vor Ort als auch über einen entfernten Zugriff via Virtual Private Network (VPN). Öffentliche Clouddienste beschreiben Dienste die für jedermann nutzbar sind wie Amazon AWS oder Microsoft Azure beispielsweise. Desweiteren existieren Communitycloudplattformen wie die Eucalyptus Open Source Platform ( Dort können nach der Anmeldung die angebotenen Ressourcen zusammen mit den anderen Mitgliedern der Gemeinschaft im Rahmen der Nutzungsvereinbarung unbegrenzt und unentgeltlich genutzt werden [AFG + 09, S.1-2,S.4]. Clouddienste bieten diverse Vorteile gegenüber eigenen Inhouse-Lösungen. Beispielsweise lässt sich Rechenleistung dynamisch nach den jeweiligen Anforderungen für ein Online-Shopping-System einer Website nach den eigenen Anforderungen skalieren. Im operativen Betrieb lassen durchschnittliche Lastanforderungen meist gut abschätzen und händeln. Wenn jedoch ein besonderes Promotionangebot in einem Onlineshop verfügbar ist oder beispielsweise eine Onlineeinschreibung für die Sportkurse des nächsten Semesters an einer Hochschule stattfindet, können diese gehäuften Anfragen ein System in die Knie zwingen und die Seite ist vorübergehend für manche Nutzer unerreichbar machen. Die Nutzung von Clouddiensten kann dabei helfen eine nahezu maximale Verfügbarkeit zu erreichen und die Kosten dabei optimal zu halten. Technisch können Clouddienste in drei Arten unterschieden werden, Infrastructure-as-a-Service (IaaS), Plattform-as-a-Service (PaaS), Software-as-a-Service (SaaS). Diese bedienen verschiedene Nutzergruppen und unterscheiden sich auch in ihren Anwendungsfällen bzw ihrer Beschaffenheit [AFG + 09, S.4][Xaa11]. 13

14 Vergleich: Infrastructure-as-a-Service, Plattform-as-a-Service und Software-as-a-Service Infrastructure-as-a-Service Plattform-as-a-Service Software-as-a-Service Anwendungsfälle Recheneinheiten, Laufzeitumgebungen, Softwaresysteme wie Speichersysteme, Anwendungsserver o.ä. wie z.b: CRM oder Datenbanken ERP-Anwendungen Dienstanbieter- Amazon EC2 & S3 & RDS, Microsoft Azure, Microsoft beispiele Rackspace Cloud Servers Google App Engine Office Web Apps, & Cloud Files Really Simple Systems Nutzertypen Systementwickler Anwendungsentwickler Endbenutzer In Abbildung 2.1 wird dargestellt, welche Freiheitsgrade Clouddienste je nach Abstraktionsniveau bieten. Mit abnehmenden Freiheitsgraden sinkt auch der Aufwand Ressourcen zu verwalten. Dies reicht von der traditionellen IT mit dem größten Administrationsaufwand bis zu Software-as-a-Service Diensten die komplette Endbenutzeranwendungen anbieten [Xaa11]. Abbildung 2.1: Vergleich: IaaS, PaaS und SaaS (Quelle: Microsoft, The Economics of the Cloud, 2010, S.11, Abb.17 [HY10]) Wie in der Abbildung 2.1 dargestellt und auch aus der Tabelle Vergleich: Infrastructure-as-a-Service, Plattform-as-a-Service und Software-as-a-Service ersichtlich, bieten IaaS-Diensterleister Netzwerk-, Speicher- und Serverressourcen in ihren Diensten an. Anhand der blauen Einfärbungen in der Grafik sind die durch den Nutzer zu verwaltenden Elemente oder Ressourcen dargestellt. Die grauen Markierungen hingegen entsprechen den Bereichen, welche durch die Dienstanbieter der Cloud bereitgestellt werden. IaaS-Dienste die Recheneinheiten abstrahieren bzw. Rechenleistung anbieten, werden auch als Compute Cloud bezeichnet. Analog werden Dienste für Cloudspeicher auch Storage Cloud genannt. 14 Kapitel 2 Architekturen

15 2.1.1 Beispiel eines Clouddienstleisters Ein Beispiel für einen IaaS-Dienstanbieter ist Amazon mit der Plattform Amazon Web Services (AWS, Diese bietet eine Vielzahl von Clouddiensten an. Der Webservice Amazon Elastic Compute-Cloud (EC2) stellt beispielsweise Rechenkapazität zur Verfügung und Amazon Simple Storage Service (S3) Speicherplatz. Die Berechnung der Kosten von EC2 erfolgt nach stündlicher Nutzung der Ressourcen [AFG + 09, S.5]. Die On-Demand Nutzung bezeichnet den Gebrauch auf Anfrage und bietet eine flexible Nutzung nach Bedarf ohne im Vorfeld Ressourcen reservieren zu müssen oder eine Grundgebühr zu bezahlen. Amazon EC2 bietet drei verschiedene Preismodelle für Rechenkapazitäten an: On-Demand Instances, Reserved Instances und Spot Instances. Reserved Instances (reservierte Instanzen) beschreibt einen Typ bei dem Instanzen im Vorfeld gebucht werden und eine Grundgebühr fällig wird unabhängig von der tatsächlichen Nutzung. Im Vergleich zum Typ On-Demand ist der resultierende Preis pro Rechenstunde niedriger. Das Preismodell der Spot Instances unterliegt stetigen Schwankungen, da sich die Preise fortlaufend ändern. Der Grund dafür ist, dass bei Spot Instanzen auf ungenutzte EC2 Ressourcen geboten wird. Das bedeutet zum Ausführen einer Instanz wird das Modell der Spot Instanz gewählt und ein Maximalpreis, den der Nutzer gewillt ist für die Ausführung zu zahlen. Liegt der Gebotspreis über dem des aktuellen Spotpreises arbeitet die Instanz, umgekehrt sobald der aktuelle Spotpreis diesen überschreitet stoppt das System die Ausführung. Auszug Preisliste EC2, Region EU, Linux/UNIX-Nutzung (Stand: :02 CET) Typ Small (Standard) Large Extra Large Standard On-Demand Instances $ 0,095 pro Stunde $ 0,38 pro Stunde $ 0,76 pro Stunde Standard Reserved Instances $ 0,04 pro Stunde $ 0,16 pro Stunde $ 0,32 pro Stunde 1 Jahr Laufzeit (Grundgebühr) $ 227,50 $ 910 $ Jahre Laufzeit (Grundgebühr) $ 350 $ 1400 $ 2800 Standard Spot Instances $ 0,03 pro Stunde $ 0,144 pro Stunde $ 0,24 pro Stunde Neben den drei Preismodellen existieren auch verschiedene Instanztypen. Diese unterscheiden sich durch ihre Leistungsfähigkeit. So sind z.b. Arbeitsspeicher und Massenspeicher in unterschiedlicher Größe und Recheneinheiten mit differierendem Leistungsspektrum ausgelegt. Auszug Instanztypen EC2 ( Instanztyp Small Large Extra Large RAM 1,7 GB 7,5 GB 15 GB Recheneinheit 1 EC2 Compute Unit 4 EC2 Compute Units 8 EC2 Compute Units (Compute Unit (1 virtueller Kern (2 virtuelle Kerne (4 virtuelle Kerne = CU) mit 1 EC2-CU) mit je 2 EC2-CUs) mit je 2 EC2-CUs) Instanzspeicher 160 GB 850 GB GB Plattformtyp 32 Bit 64 Bit 64 Bit E/A Leistung Mittel Hoch Hoch API-Name m1.small m1.large m1.xlarge 2.1 Cloud Computing 15

16 2.1.2 Tools zum Cloudmanagement Ein sehr vielseitiges GUI-basiertes Tool für Windows Betriebssysteme zum Managen von S3 Storage Accounts stellt der CloudBerry Explorer ( dar. Der Aufbau entspricht einem klassischen Filemanager in Zwei-Fenster-Optik. Dieser ist sowohl als Freeware wie auch als PRO Version erhältlich. Es erfolgt eine breite Unterstützung von Anbietern, welche eine S3 kompatible API anbieten. Für OpenStack basierte Systeme oder Rackspace Cloud Files ist ebenfalls ein Produkt in der Entwicklung. Desweiteren existieren auch CloudBerry Explorer für Microsoft Azure Blob Storage und Google Storage. Ein GUI-basiertes Plugin für Mozilla Firefox zum Verwalten von Ressourcen, der Amazon EC2 oder Eucalyptus Accounts ist ElasticFox ( Aus Kompatibilitätsgründen ist es erforderlich Firefox 4.0 zu verwenden. Zusätzlich existiert auch ein Projekt, ElasticFox EC2Tag ( welches eine modifizierte Version darstellt. Diese ist sowohl als Firefox Plugin als auch als eigenständiges Programm für Windows erhältlich. 2.2 WEBSERVICES Webservices sind Dienste die Funktionalität kapseln und einem Nutzer zur Verfügung stellen. Diese Software-Anwendungen werden über Netzwerke, wie das Internet oder auch Intranet publiziert und können an einem bestimmten Endpunkt,in Form einer URL angesprochen werden. Dabei kann von einem Webservice bzw. dessen Dienstanbieter, eine Beschreibung der Funktionalität sowie der Art und Weise der Nutzung in Form einer Dienstbeschreibung veröffentlicht werden. Ein Dienst ist häufig auch in Dienstverzeichnissen registriert und seine Dienstbeschreibung dort hinterlegt [MEH08]. Speziell im Architekturparadigma der Service Orientierten Architektur (SOA) spielen Webservices als Grundlage für ein verteiltes System ein wichtige Rolle. Die Verwendung von Webservices unterscheidet sich grundsätzlich von komponentenbasierten Systemen, da Dienste in sich abgeschlossen sind und somit eigenständig genutzt werden können. Dies ermöglicht die Wiederverwendung eines Dienstes in einem neuen Kontext. Langfristig kann ein System aus Webservices den Aufwand bei der Entwicklung von Systemerweiterungen deutlich reduzieren, da auf schon bestehende Dienste zurückgegriffen werden kann. Ein weiterer Vorteil ist die Verwendung eines einheitlichen Nachrichtenaustauschformats [MEH08]. Eine typische Implementierungsform stellt die Verwendung der Universal Description, Discovery and Integration (UDDI, als Verzeichnisdienst, die Dienstbeschreibung in der Web Services Description Language (WSDL, und zum Nachrichtenaustausch das Simple Object Access Protocol (SOAP, dar. SOAP biete eine Beschreibungssprache für den Nachrichtenaustausch, welcher auf XML-basierten Nachrichten erfolgt. Davon unabhängig ist das verwendete Transportprotokoll und kann je nach Anforderung unterschiedlich gewählt werden z.b. HTTP, SMTP oder auch FTP. Weitere Möglichkeiten zur Kommunikation mit Webservices bietet zum einen die Implementation des Remote Procedure Call (RPC) Konzepts, desweiteren der REpresentational State Transfer (REST) auch als RESTful Webservice bekannt. Letzterer bildet die Grundlage der in dieser Arbeit verwendeten und implementierten Webservices. REST ist ein De-facto-Standard ohne offizielle Verabschiedung durch ein Konsortium wie z.b. das World Wide Web Consortium (W3C, Der Ansatz dabei ist die Verwendung der bestehenden Standards Uniform Resource Locators (URL, und des Transportsprotokolls HyperText Transfer Protokoll (HTTP, Mit den HTTP-Methoden lässt sich typische 16 Kapitel 2 Architekturen

17 CRUD-Funktionalität (Kurzwort für: Create, Read, Update and Delete) bei der Objekt- bzw. Ressourcenmanipulation erzeugen [Rod08, S.1-4]. HTTP Methode GET PUT POST DELETE HEAD OPTIONS HTTP Methoden im REST Kontext Verwendung Anforderung einer Ressource Erzeugen einer neuen Ressource und Senden von Daten zum Server ähnelt PUT, kann auch zur Änderung einer Ressource genutzt werden oder sonstiger Funktionalität Löschen der angegebenen Ressource ähnelt GET, liefert jedoch nur Metadaten (nur HTTP-Header) ohne Body Liefert eine Liste der verfügbaren Methoden Als Beispiel einer solchen REST-Anfrage auf ein Bucket mybucket des Webservice Amazon S3 mit der HTTP-Methode OPTIONS liefert den HTTP-Status 405, die Methode ist nicht erlaubt und verweist auf die Zulässigkeit von POST, GET, DELETE, HEAD und PUT: ANFRAGE (OPTIONS Host: mybucket.s3.amazonaws.com Date: Sun, 13 Nov :28:00 GMT ANTWORT (Status: 405 Method Not Allowed) Date: Sun, 13 Nov :28:31 GMT x-amz-request-id: B31026B40248D67A Transfer-Encoding: chunked x-amz-id-2: djhisvgk58t7vsenylddbz0vfdrl27vdjtadms9vl5qdzd3n/hvwb24ycymrewyo Server: AmazonS3 Allow: POST, GET, DELETE, HEAD, PUT Content-Type: application/xml <?xml version= 1.0 encoding= UTF-8?> <Error> <Code>MethodNotAllowed</Code> <Message>The specified method is not allowed against this resource.</message> <ResourceType>BUCKET</ResourceType> <Method>OPTIONS</Method> <RequestId>B31026B40248D67A</RequestId> <HostId>dJHIsVgK58t7vSENylddBZ0vFDRL27VdjtadMS9vl5Qdzd3N/hvwb24YcYmrewYo</HostId> </Error> Bei einem RESTful Webservice wird dessen Schnittstellenbeschreibung mittels einer WADL-Datei publiziert. Diese ist in der Web Application Description Language (WADL, geschrieben und repräsentiert eine XML-Datei die dem XML-Schema (wadl.xsd) des W3C entspricht. Um neben Dateien und Streaminginhalten auch Daten innerhalb der HTTP Nachrichten zu transportieren, existieren verschiedene Ansätze. Häufig werden diese in Form von XML oder über die JavaScript Object Notation (JSON, strukturiert, auch einfacher HTML-Output ist möglich. Als Beispiel lässt sich der Webservice IPInfoDB, der eine geografische Lokalisation von IP Adressen anbietet, heranziehen. Zum Beispiel Für die IP Adresse wird Deutschland als Herkunft ermittelt, die Ausgabe bei diesem Webservice kann je nach Wunsch: raw (HTML), json oder xml sein. 2.2 Webservices 17

18 IPInfoDB RESTful Webservice - IP Lokalisation - Formate: RAW Output, JSON, XML ( RAW JSON XML (text/html) (text/json) (text/xml) <?xml version= 1.0 encoding= UTF-8?> { <Response> OK; statuscode : OK, <statuscode>ok</statuscode> ; statusmessage :, <statusmessage></statusmessage> ; ipaddress : , <ipaddress> </ipaddress> DE; countrycode : DE, <countrycode>de</countrycode> GERMANY countryname : GERMANY <countryname>germany</countryname> } </Response> 18 Kapitel 2 Architekturen

19 3 SKALIERUNG IN DER CLOUD Skalierung in der Cloud oder auch Cloud Scaling, enthält Mechanismen, Ideen und Ressourcen die durch Clouddienste angeboten werden. Diese Dienste zu Nutzen oder Dritten zur Verfügung zu stellen und zum Anfragezeitpunkt in der gewünschten Menge und Güte anzubieten entspricht dem Cloudgedanken. Das bedeutet auf entstehende Lastanforderungen reagieren zu können durch das Bereitstellen von Ressourcen. Dabei kann es von Vorteil sein Vorhersagen treffen zu können, um im Vorfeld später benötigte Betriebsmittel zu reservieren und damit Lastspitzen zu bedienen. Letzteres kann auch auf Grund von Anlaufzeiten bis zur Verfügbarkeit einer Ressource notwendig sein. Das Thema Skalierung ist ein zentraler Gedanke im Bereich des Cloudcomputing, da Ressourcen teilbar, gar abzählbar vorhanden sind und genau dosiert verwendet werden können. Gerade im Bereich der Compute-Clouds besteht deshalb das Interesse und die Notwendigkeit Rechenkapazität je nach Anforderung zur Verfügung zu stellen. Damit verbunden ist die Notwendigkeit des Vorhandenseins von Verfahren in Form von Algorithmen, welche die Skalieroperationen steuern. Eine Auswahl von Verfahren sollen hier vorgestellt werden. 3.1 SKALIERUNG VON RECHENLEISTUNG In ihrer Publikation Scaling into the Cloud stellen Kupferman, Silverman, Jara und Browne drei Verfahren zur Skalierung von Rechenleistung vor. Diese sollen in den folgenden Abschnitten betrachtet werden RightScale Algorithmus Der RightScale Algorithmus bietet eine sehr einfache Möglichkeit zur Skalierung von Systemen oder Recheneinheiten. Dabei sind für die einzelnen Systemeinheiten bestimmte Schwellenwertintervalle festgelegt in denen sich im Normalfall die Auslastung bewegen sollte. Beispielsweise wäre eine Prozessorenauslastung von 30 bis 70 Prozent eines einzelnen Rechners denkbar. Sobald diese unter oder überschritten wird, votiert dieser Rechner für ein Verkleinerung oder Vergrößerung des Gesamtsystems. Nachdem beispielsweise die Auslastung eines Rechners 70% übersteigt, plädiert dieser als Teil des Gesamtsystems für eine Aufstockung der Ressourcen. Sobald die Mehrheit der Rechner in demokratischer Art und Weise 19

20 für eine Skalierung in eine bestimmte Richtung abgestimmt hat, skaliert das Gesamtsystem. Neue Ressourcen werden vergeben bzw. eingespart. Danach müssen die an dieser Skalierung beteiligten Systeme eine vordefinierte zeitliche Zwangspause einlegen, ehe sie wieder votieren dürfen. Dies verhindert ein zu häufiges Anpassen der Systemgrö ße und vermeidet unnötigen Overhead [KSJB09, S.4]. Aufgrund der Funktionsweise dieser Skalierungsmethode ist der Algorithmus stark reaktiv in seiner Anpassungsform, weil lediglich auf kurzfristige Laständerungen reagiert wird. Dieses Verfahren ist in seiner Konsequenz kaum prädiktiv, da nur die zeitnahe Vergangenheit betrachtet wird [KSJB09, S.5] Autoregressives Modell erster Ordnung (AR1) Die Nutzung des AR1 ermöglicht eine Vorhersage des zukünftigen Lastaufkommenens, unter Betrachtung der Verlaufshistorie. Dies geschieht durch Einteilung in Intervalle gleicher Größe. Hierzu werden die vergangenen Intervalle anhand einer bestimmten Eigenschaft (z.b. durchschnittliche Anfragen pro Sekunde) untersucht [KSJB09, S.4][CGS03]. Die Grundlage bildet ein in der Statistik verwendetes Spezialverfahren zur Regressionanalyse, das Autoregressive Modell. a i... Intervall N h... Anzahl der Intervalle der Verlaufshistorie N a... Anzahl der Vorhersageintervalle a i mit (1 i N h )... Intervalle der Verlaufshistorie a i mit (N h < i N h + N a)... Intervalle der Vorhersageintervalle e i... Rauschkonstante, hier 0 Formel zu Berechnung der Vorhersageintervalle (a i ) mittels AR1 a i+1 = a avg + ρ(1) (a i a avg) + e i zugehörige Autokorrelationsfunktion ρ(l) = 1 N a+n N a+n h l h l i=2 (a i a avg) (a i l a avg) σ 2 h Daraus lässt sich ein kleines Beispiel konstruieren z.b. mit zwei Vergangenheitsintervallen und einem Vorhersageintervall. Dabei soll die zu betrachtende Eigenschaft im Intervall eins den Wert 4 und im Intervall zwei den Wert 6 annehmen, gesucht ist somit der Wert für a 3 des dritten Intervalls. N h = 2, N a = 1, e 2 = 0, a 1 = 4, a 2 = 6 gesucht: a 3 a avg = = 5 Berechnung des Vorhersageintervalls a 3 mittels AR1 a 3 = a avg + ρ(1) (a 2 a avg) + e 2 = (6 5) + 0 = 5 zugehörige Autokorrelationsfunktion erster Ordnung (a ρ(1) = i a avg) (a i 1 a avg) 1 N a+n h 1 N a+n h 1 i=2 σ 2 h = (a 2 a avg) (a 1 a avg) 1 2 = 1 2 (6 5) (4 6) 1 = 0 20 Kapitel 3 Skalierung in der Cloud

21 Da dieses Verfahren auch Ereignisse der Vergangenheit in die Berechnung mit einbezieht, sind Vorhersagen für die Zukunft möglich bzw. können so berechnet werden. Das bedeutet, dass diese Methode prädiktiv und nicht reaktiv ist Lineare Regression Dieser Skalierungsmechanismus ist beschrieben über ein mathematisches Standardverfahren zur Parameterschätzung. Dabei wird eine Ausgleichsgerade bestimmt. Solch eine Gerade lässt sich über die Methode der kleinsten Quadrate errechnen [BG07, S.50]. Diese wird über eine Menge von Messpunkten berechnet. Durch die ermittelte Gerade lassen sich zukünftige Werte vorhersagen [KSJB09, S.4-5]. 3.2 SKALIERUNG VON CLOUDSPEICHER In diesem Abschnitt wird eine Variante zur Skalierung von Speicher vorgestellt, dies ist Microsofts Technologie Hyper-V Dynamic Memory. Eine ähnliche Idee wird später verwendet für einen Algorithmus zur Skalierung von Cloudspeicher Dynamischer Arbeitsspeicher in der Virtualisierung Microsoft Hyper-V stellt eine Virtualisierungsplattform für Microsoft Gast-Betriebssysteme im Serverbereich wie z.b. Windows Server 2003 x64 oder Clientbereich Windows XP SP2 und einige weitere ausgewählte Gast-Systeme wie z.b. Red Hat Enterprise Linux 5.3 dar [HVD11b]. Dabei kann der Windows Server 2008 mit der Komponente Hyper-V erweitert werden oder als eigenständige Variante als Hyper-V Server unabhängig von einem Betriebssystem betrieben werden. Hyper-V ist ein so genannter Hypervisor, eine Grundumgebung für Virtuelle Maschinen. Aufsetzend auf solch einen Hypervisor lassen sich virtuelle Maschinen betreiben und diese bekommen vordefinierte Ressourcen aus dem Hardwarepool der durch den Hypervisor verwaltet wird, zur Nutzung zu gewiesen [Hyp11, HY10]. Virtuelle Maschinen sind demnach strukturell einem realen Rechner gleich, jedoch stellen sie nur eine Abstraktion eines Computers dar. PCs, die als virtuelle Maschine existieren, werden virtuelle PCs genannt. Hypervisoren können laut der Publikation von IBM [Cor05] in zwei Arten unterschieden werden. Typ-1 setzt ähnlich einem Betriebssystem direkt auf der Hardware auf. Beim Typ-2 erfolgt die Installation auf einem bestehenden Betriebssystem. Dadurch werden auch die Treiber von diesem Hypervisor benutzt, um die angeschlossenen Geräten bzw. die darunter liegende Hardware anzusteuern. Abbildung 3.1: System mit Typ-1 Hypervisor 3.2 Skalierung von Cloudspeicher 21

22 Abbildung 3.2: System mit Typ-2 Hypervisor Zum Beispiel wäre eine Typ-1 Installation denkbar auf einem System mit sechs Recheneinheiten bzw. Prozessorkernen und dem Bedarf von vier Maschinen, jeder dieser Maschinen jeweils eine Recheneinheit zuzuweisen. Die verbliebenen zwei sind bis auf weiteres ungenutzt und stehen für die zukünftige Nutzung bereit. Diese Art von Splitting der Hardware wird als Virtualisierung bezeichnet. Damit lassen sich Hardwareressourcen, die auf den ersten Blick als unteilbar erscheinen, aufteilen. Der Sinn eines solchen Vorgehens im Bereich des Cloudcomputings kann beispielsweise sein um Kundenwünschen gerecht zu werden. Häufig wird eine konkrete Menge an Rechenkapazität oder Rechnerhardware angefragt und diese muss somit nicht in physischer Form verfügbar sein. Bei der Vergabe von Arbeitsspeicherressourcen für eine virtuelle Maschine, gibt es zwei Möglichkeiten zur Auswahl. Zum einen, eine feste zugewiesene Menge an nutzbarem Arbeitsspeicher. Zum anderen lässt sich optional auch zusätzlich dynamischer Speicher vergeben, dieser kann beim Hypervisor angefordert werden. Das bedeutet, dass ein System mit zehn Gigabyte Arbeitsspeicher z.b. für 4 virtuelle PCs jeweils zwei Gigabyte zugewiesen wird und darüber hinaus noch ein weiteres Gigabyte dynamisch nachgefordert werden kann. Diese Technik wird bei Microsoft Hyper-V Dynamic Memory genannt [HVD11a, HVD11b]. Dafür lässt sich ein Auslastungsgrad voreinstellen ab dem zusätzlicher Speicher angefragt wird, z.b. ab 80% Auslastung. Dann wird falls verfügbar, der zusätzliche Speicher zur Nutzung freigegeben und später wenn er nicht mehr benötigt wird an den Hypervisor zurückgegeben Skalierung über Schwellenwertberechnung Da Bedarfsänderungen bei Speicherplatz häufig einer geringeren Volatilität unterliegen als das bei Rechenkapazität der Fall ist, lassen sich Algorithmen für die Skalierung von Massenspeicher für Compute-Clouds nicht eins zu eins übertragen. Die Idee von Microsofts Hyper-V Dynamic Memory Technologie (vgl. Abschnitt 3.1.1) in Zusammenhang mit dem Rightscale Algorithmus (vgl. Abschnitt 3.2.1) lässt sich erweitern und daraus eine Funktion für die Skalierung von Speicherplatz realisieren. Eine Anpassung wird durch über- oder unterschreiten von Schwellenwerten ausgelöst. Die Vorgehensweise ist dabei folgende, der aktuell belegte Speicherplatz und die verfügbare Maximalgröße werden ins Verhältnis gesetzt. Daraus wird der Prozentsatz für die aktuelle Speicherbelegung errechnet. Dieser Wert sollte sich in einem vordefinierten Intervall für die Auslastung bewegen. Die Intervallgrenzen stellen dabei die Schwellenwerte dar. Sollte sich die Auslastung außerhalb der Intervallgrenzen befinden, wird eine Skalierung eingeleitet. Falls die aktuelle Auslastung kleiner ist als die untere Intervallgrenze bzw. wird der Schwellenwert für die Minimalauslastung unterschritten, soll eine Verkleinerung des Gesamtspeichers erfolgen. Analog 22 Kapitel 3 Skalierung in der Cloud

23 dazu erfolgt eine Vergrößerung und damit der zusätzliche Bedarf an Speicher, sobald der Schwellenwert für die Maximalauslastung überschritten wurde. Als günstige Konfiguration hat sich dabei 80% als obere Schranke und 30% als untere Schranke erwiesen. Das bedeutet, dass über einer Nutzung von 80% ein Skaliervorgang gestartet wird um die absolute Speicherplatzmenge zu vergrößern. Eine Verkleinerung der absoluten Gesamtspeichermenge wird notwendig, wenn die vordefinierte untere Schranke von 30% unterschritten wird. Diese verwendeten Größen resultieren aus Erfahrungswerten. Um einer Häufung von Skaliervorgängen aus dem Weg zu gehen, haben sich diese Werte als günstig erwiesen. Desweiteren ist ein Skalierungsfaktor von Interesse um den sich der Speicherplatz ändert. Es können für den jeweiligen Faktor unterschiedliche Größen, sowohl für die Vergrößerungs- (scale_fac_dn) als auch die Verkleinerungsoperation (scale_fac_up) verwenden werden. In diesem Beispiel erfolgt jedoch eine Anpassung um jeweils 40%. Bei der Wahl der Skalierungsfaktoren ist zu beachten, dass eine Abhänigkeit zwischen der Anzahl an Skaliervorgängen und den Faktoren besteht. So können zu kleine Werte zu einer Häufung von Skalierungen führen. BEISPIEL untere Schranke, thres_lo = 0.3 (30%) obere Schranke, thres_hi = 0.8 (80%) Skalierungsfaktor (runter), scale_fac_dn = = 0.6 Skalierungsfaktor (hoch), scale_fac_up = = Fall Gesamtspeichergröße, size_max = 100 GB belegte Speichermenge, size_used = 60 GB Verhältnis, ratio = size_max / size_used = 60 / 100 = 0.6 (60%) keine Skalierung notwendig, da thres_lo <ratio <thres_hi 2. Fall Gesamtspeichergröße, size_max = 100 GB belegte Speichermenge, size_used = 85 GB Verhältnis, ratio = size_max / size_used = 85 / 100 = 0.85 (85%) Skalierung notwendig, da thres_lo <ratio >thres_hi, Speicher vergrößern neue Gesamtspeichergröße, size_max * scale_fac_up = 100 GB * 1.4 = 140 GB 3. Fall Gesamtspeichergröße, size_max = 200 GB belegte Speichermenge, size_used = 50 GB Verhältnis, ratio = size_max / size_used = 50 / 200 = 0.25 (25%) Skalierung notwendig, da thres_lo >ratio <thres_hi, Speicher verkleinern neue Gesamtspeichergröße, size_max * scale_fac_dn = 200 GB * 0.6 = 120 GB So lässt sich der Algorithmus in allgemeiner Form mit seinen Parametern und Bedingungen wie folgt festhalten: 3.2 Skalierung von Cloudspeicher 23

24 Parameter: Gesamtspeichergröße, size_max belegter Speicherplatz, size_used untere Schranke, thres_lo obere Schranke, thres_hi Prozentsatz für Verkleinerung, perc_dn Prozentsatz für Vergrößerung, perc_up Hilfsgrößen: Auslastungsverhältnis, ratio = size_max / size_used untere Schranke, thres_lo obere Schranke, thres_hi Skalierungsfaktor für Verkleinerung, scale_fac_dn Skalierungsfaktor für Vergrößerung, scale_fac_up Bedingungen: keine Skalierung, da thres_lo <ratio <thres_hi Speichervergrößerung, da thres_lo <ratio >thres_hi Speicherverkleinerung, da thres_lo >ratio <thres_hi Resultat: neue Gesamtspeichergröße, size_max * scale_fac Funktion als Pseudocode: scale_fac = 1; scale_fac_dn = 1 + perc_dn; scale_fac_up = 1 + perc_up; if (thres_lo <ratio) && (ratio >thres_hi) scale_fac = scale_fac_up; if (thres_lo >ratio) && (ratio <thres_hi) scale_fac = scale_fac_dn; return size_max * scale_fac; 24 Kapitel 3 Skalierung in der Cloud

25 4 PREIS VON CLOUDSPEICHER ALS NICHT-FUNKTIONALE EIGENSCHAFT 4.1 PREISMODELLE Nutzungsgenau Bei einer nutzungsgenauen Abrechnung im Kontext von Cloud Computing spricht man auch häufig von Pay-as-you-go oder Pay-per-use Angeboten [AFG + 09, S.4-5]. Dabei werden die genutzten Einheiten einer Ressource über den Nutzungszeitraum und die Menge exakt abgerechnet, vergleichbar mit einer Stromrechnung. Bei Cloudspeicher erfolgt die Abbrechnung pro Gigabyte und auf einen Tag genau wie im folgenden Beispiel veranschaulicht. Der schon einmal in Abschnitt erwähnte Dienst zur Datenspeicherung Amazon S3 ist in zwei Preismodellen verfügbar, die Standard-Speichermethode und die Reduced Redundancy Storage (RRS). Diese unterscheiden sich in ihrer jeweiligen Datensicherheit durch die Auslegung der Redundanz. Generell ist im Vergleich zu einer einfachen Speicherung, auf nur einem Datenträger, eine zusätzliche Replikation bei beiden Modellen vorhanden. So ist bei RSS eine Objektzuverlässigkeit von 99,99% angestrebt und eine gespeicherte Datei wird an einem Standort redundant abgelegt. Zusätzlich wird bei der Standard-Speichermethode aber eine an den S3 Webservice gesandte Datei mehrfach an verschiedenen Standorten und dort zusätzlich redundant abgelegt. Dies ergibt eine Objektzuverlässigkeit von 99, % über ein Jahr. ( 25

26 Auszug Preisliste S3, Region EU (Stand: ) Standard-Speichermethode Reduced Redundancy Storage Objektzuverlässigkeit pro Jahr 99, % 99,99% Verfügbarkeit pro Jahr 99,99% 99,99% Speichervolumen Bis 1 TB pro Monat $ 0,140 pro GB $ 0,093 pro GB Ab 1 TB - 50 TB pro Monat $ 0,125 pro GB $ 0,083 pro GB Ab 50 TB TB pro Monat $ 0,110 pro GB $ 0,073 pro GB Ab 500 TB - 1 PB pro Monat $ 0,095 pro GB $ 0,063 pro GB Ab 1 PB - 5 PB $ 0,080 pro GB $ 0,053 pro GB Über 5 TB pro Monat $ 0,055 pro GB $ 0,037 pro GB Bei einer Objektzuverlässigkeit von 99.99% ergibt sich ein zu erwartender Verlust pro Jahr von 0.01% (1/10000, da nach Definition 1% = 1/100) also von einem Objekt pro Objekte pro Jahr oder eins von 1000 in 10 Jahren oder eins von 100 in 100 Jahren. Da die Preisliste in verschiedene Preisklassen eingeteilt ist und beim überschreiten der festgelegten Grenzen ein neuer Tarif je Gigabyte gilt, muss der Gesamtpreis für die Speichervolumen stufenweise berechnet werden. Für ein Speichervolumen von 3 TB, welches einen Monat lang gespeichert wird, lautet die Rechnung wie folgt: Speichervolumen in Preisstufe I (bis 1 TB): 1 TB = 1024 GB Speichervolumen in Preisstufe II (ab 1-50 TB): 2 TB = 2048 GB Standard-Speichermethode: 1024 GB x $ 0,140/GB/Monat = $ 143,36/Monat GB x $ 0,125/GB/Monat = $ 256,00/Monat = $ 399,36 pro Monat Reduced Redundancy Storage: 1024 GB x $ 0,093/GB/Monat = $ 95,23/Monat GB x $ 0,083/GB/Monat = $ 169,98/Monat = $ 265,21 pro Monat Weitere Kosten können für die Anzahl der getätigten Anfragen auf den Dienst sowie das genutzte Datenübertragungsvolumen von und zum Speicherdienst entstehen. Parallel zu S3 existieren diverse Anbieter, welche mit einer kompatiblen S3 Programmierschnittstelle (API, Application Programming Interface), um Marktanteile werben. Zu diesen Diensten gehören Dunkel Cloud Storage, Hosteurope Cloud Storage, Connectria Cloud Storage, Seeweb Object Storage Cloud oder Eucalyptus Walrus Paketpreis Bei den klassischen Paketpreismodellen handelt es sich um ein Angebot bei dem eine vordefinierte Menge an Gütern zu einem Festpreis erworben werden können. Der Nutzungsrahmen ist durch eine Obergrenze beschränkt, dadurch können keine unerwünschten 26 Kapitel 4 Preis von Cloudspeicher als nicht-funktionale Eigenschaft

27 Mehrkosten entstehen. Solche zu einem Festpreis angeboten Speicherplatzkontingente werden von verschiedenen Anbietern wie z.b. Strato HiDrive, Sugarsync oder Adrive angeboten. Häufiger Nachteil dieser Dienste ist, dass sie nur rudimentären Service bieten, dies drückt sich in fehlender oder nur einfacher Redundanz bei der Datensicherheit aus. Oft werden aber auch zusätzliche Backupservices angeboten über Daten-Snapshots oder ähnliche Mechanismen. Diese können automatisch oder manuell erfolgen (z.b. bei HiDrive), allerdings wird dadurch der nutzbare Speicherplatz eingeschränkt, da die Backups (Snapshots) augenscheinlich an dem selben virtuellen Speicherort liegen. Das stellt im eigentlichen Sinne keine tatsächliche Datensicherung gegen einen Systemausfall dar, sondern eher eine Option zu Wiederherstellbarkeit der eigenen Daten auf Grund ungewollter Veränderungen. Möglich ist natürlich auch, dass diese Daten auf einem anderen z.b. physischen Laufwerk liegen und nur virtualisiert als dasselbe angezeigt werden. Dieser Gedanke ist berechtigt, da die eigentlichen Sicherungsdateien nicht in der genutzten Verzeichnisstruktur auftauchen, sondern über eine Managementkonsole online verwaltet werden können. Dort ist es auch möglich Wiederherstellungspunkte zu löschen. Außerdem wird dort auch der durch Sicherungen genutzte, mit Nutzdaten belegte und der noch verfügbare Speicherplatz angezeigt. Ein wichtiger Aspekt dabei ist, dass der Preis pro Einheit also z.b. pro GB im Vergleich zu anderen Anbietern mit elastischer Nutzung (Pay As You Go), günstiger ist. So ergeben sich bei der Nutzung etwa von Amazon S3, welches eine sehr hohe Objektzuverlässigkeit bietet von 99, % pro Jahr und somit deutlich höhere Preise pro Gigabyte als z.b. bei SugarSync. Dieser wirbt mit einer Zertifizierung nach Statement on Auditing Standards No. 70 (SAS 70, und Data stored redundantly in carrier-grade (SAS 70, Type II) ( Dabei werden allerdings keine konkreten Aussagen über die Dienstgüte getroffen, was eine fehlende Transparenz darstellt und somit eine Verunsicherung für den Kunden bedeuten kann. Eine mögliche Erklärung für die günstigeren Preise könnte somit die geringere Ausfallsicherheit darstellen. Außerdem spielt die Größe eines Anbieters eine wichtige Rolle, da sich Gemeinkosten mit steigender Anzahl von angebotenen und verkauften Gütern auf ein Minimum reduzieren lassen. Vergleich von S3 und SugarSync (Stand: Dezember 2011) Preis 30 GB 60 GB 100 GB 250 GB 500 GB Amazon S3 monatlich, kumuliert $4,20 $8,40 $14,00 $35,00, $70,00 pro GB $0,14 $0,14 $0,14 $0,14 $0,14 SugarSync monatlicher Paketpreis $4,99 $9,99 $14,99 $24,99 $39,99 pro GB $0,17 $0,17 $0,15 $0,10 $0,08 Abbildung 4.1: Vergleich von S3 und SugarSync (Stand: Dezember 2011) Da dieses Modell eine Beschränkung des nutzbaren Gesamtspeichers durch eine feste Obergrenze aufweist, sind eigene Skalierungsmaßnahmen erforderlich um die 4.1 Preismodelle 27

28 Paketgrößenabhängigkeit zu lösen. Dabei wäre es denkbar bei zusätzlichem Bedarf in ein größeres Paket zu wechseln, einen anderen Anbieter zu nutzen oder gar komplett zu migrieren. Die folgende Tabelle zeigt zwei Anbieter (Adrive und SugarSync) im Vergleich und veranschaulicht die verfügbaren Paketgrößen, den monatlichen Paketpreis sowie den errechneten Preis pro Gigabyte (GB). Vergleich von Adrive und SugarSync (Stand: Dezember 2011) Preis 30 GB 50 GB 60 GB 100 GB 250 GB 500 GB Adrive monatlich - $6,95 - $13,95 $33,95 $66,95 pro GB - $0,14 - $0,14 $0,14 $0,13 SugarSync monatlich $4,99 - $9,99 $14,99 $24,99 $39,99 pro GB $0,17 - $0,17 $0,15 $0,10 $0,08 Abbildung 4.2: Vergleich von Adrive und SugarSync (Stand: Dezember 2011) Ein Beispiel für ein solches Szenario kann einfach veranschaulicht werden. Dabei wird das bereits vorgestellte Skalierungsverfahren mittels Schwellenwertberechnung (vgl ) verwendet, mit den Parametern für Verkleinerung <40% und Vergrößerung >80% der Auslastung, sowie einem einheitlichen Skalierungfaktor um jeweils 0,4 (40% der Maximalgröße) für die Speicherplatzgrößenänderung. Das zugrundeliegende Beispielszenario geht von einem momentan vorhandenen Speicherkontingent von 250 GB bei SugarSync zu $24,99 aus. Außerdem soll der Fakt gelten, dass bereits 210 GB belegt sind, was einer Auslastung von 84% entspricht (210 von 250 [GB]). Der Skalierungsfaktor ist, da es sich um eine Vergrößerung des Speichers handelt 1,4 (1 + 0,4). Somit ist das neue Gesamtspeichervolumen wie folgt zu berechnen 250 GB * 1,4 = 350 GB also eine Vergrößerung um 100 GB. Da es im Programm von SugarSync keinen 350 GB Tarif gibt, ist nur die Buchung eines zusätzlichen Paketes bei einem der beiden Anbieter möglich. Die Kosten dafür sind aus der Tabelle ersichtlich, einmal 100 GB bei SugarSync zu $14,99 bzw. bei Adrive zu $13,95. Damit ist klar, das Adrive vorzuziehen ist. Das Gesamtspeichervolumen von 350 GB ist somit nun verteilt auf SugarSync mit 250 GB und Adrive mit 100 GB. Die Gesamtkosten betragen nun $38,94 bei einem durchschnittlichen Preis pro GB von $0,11. Aus wirtschaftlicher Sicht nicht 100%-ig sinnvoll und vom Algorithmus abweichend, wäre es allerdings auch denkbar den SugarSync Tarif zu behalten und zu vergrößern auf 500 GB zu $39,99. Dies erscheint nach der Betrachtung der Einzelkosten am ökonomischsten, es ergeben sich zwar anfänglich Mehrkosten von $1,05, allerdings reduziert sich der Preis pro Gigabyte um 27% auf $0,08. Die Paketgröße von nun 500 GB ist für den Fall, dass in Zukunft mit steigendem Datenvolumen gerechnet wird, optimal gewählt. Da der verwendete Skalierungsalgorithmus allerdings nur reaktiv und nicht prädiktiv agiert, existieren keine Informationen für eine solche Vorhersage. 28 Kapitel 4 Preis von Cloudspeicher als nicht-funktionale Eigenschaft

29 4.2 KOSTENFUNKTIONEN Um eine Entscheidung über die Wahl eines konkreten und möglichst optimalen Anbieters zu einem bestimmten Zeitpunkt unter gegebenen Rahmenbedingungen treffen zu können, kann das aufstellen einer allgemeinen Kostenfunktion helfen. Dieser Ansatz ist bekannt aus der Betriebswirtschaft genauer der Kosten- und Leistungsrechnung. Dabei lassen sich im allgemeinen zwei Kostenarten festhalten, zum einen die variablen Kosten und zum anderen die Fixkosten. Diese bilden in der Summe eine Kostenfunktion ab. Bei der Berechnung der Kosten für Cloudstorage Anbieter sind eine Vielzahl an verschiedene Kosten zu betrachten. Zum einen einmalige Kosten für die Bereitstellung oder Anmeldung bei einem Dienstanbieter für einen Dienst oder ein Paket. Dann natürlich je nach Preismodell entweder der Festpreis für ein Paket oder im Falle einer nutzungsgenauen Abrechnung, den Preis pro Einheit. fixe Kosten: Paketpreis Bereitstellungskosten (einmalig) variable Kosten: Kosten pro Einheit [GB] Transferkosten Kosten für Abfragen Es ist für die Vergleichbarkeit von Vorteil den Paketpreis anhand der Größe, in den Preis pro Einheit umzurechnen bzw. den Preis pro Einheit bei nutzungsgenauer Abrechnung mit der Paketgröße des Vergleichsangebots zu multiplizieren. Je nach Verwendungszweck kann die eine oder andere Methode nützlicher sein für den Vergleich bzw. mehr Aussagekraft besitzen. Somit lassen sich diese Kosten entweder als Fixkosten oder als variable Kosten klassifizieren, das ist abhängig davon, ob der Definitionsbereich stetig (z.b. pro Gigabyte) oder unstetig (z.b. Stufen in Paketgröße) ist Funktionsentwicklung aus Preismodellen Beispielhaft sollen nun die Kostenfunktionen für drei Cloudspeicherdienstleister dargestellt werden. Es werden hierbei nur die reinen Kosten pro Gigabyte Speicherplatz betrachtet ohne zusätzliche Fixkosten und an der y-achse als Preis in US-Dollar ($) abgetragen. Den Definitionsbereich bildet der Speicher in Gigabyte, dieser ist an der x-achse in Form der Paketgrößen abgetragen. Die Kostenfunktionen werden nur im stetigen Intervall größer null bis einschließlich 500 Gigabyte betrachtet, das geschieht aus Gründen der Übersichtlichkeit und Vergleichbarkeit. Die Funktionen für Adrive und SugarSync sind unstetige Stufenfunktionen, da auf Grund der Paketgrößenabhängigkeit jeweils das Paket mit einer Speichersplatzgröße in der Höhe des Speicherplatzbedarfs oder das nächst größere genutzt werden muss, um die Anforderungen zu befriedigen. Die beiden Funktionen haben als Grundlage die Tabelle mit den Preisen in Vergleich von Adrive und SugarSync. Bei Amazon S3 ist dies nicht der Fall. Die Kostenfunktion ist eine lineare Funktion, da der Preis pro Gigabyte konstant bei $0,14 liegt bis einschließlich 1000 GB (vgl. Tabelle Auszug Preisliste S3, Region EU in 4.1.1). 4.2 Kostenfunktionen 29

30 Abbildung 4.3: Kosten für Nutzung von Adrive, SugarSync und S3 Kostenfunktionen für Adrive, f(x) mit x = ]0;500]: 6, 95 : x 50 13, 95 : (x > 50) (x 100) f(x) = 33, 95 : (x > 100) (x 250) 66, 95 : (x > 250) (x 500) (4.1) Kostenfunktionen für SugarSync, g(x) mit x = ]0;500]: g(x) = 4, 99 : x 30 9, 99 : (x > 30) (x 60) 14, 99 : (x > 60) (x 100) 24, 99 : (x > 100) (x 250) 39, 99 : (x > 250) (x 500) (4.2) Kostenfunktionen für Amazon S3, h(x) mit x = ]0;500]: h(x) = 0, 14 x (4.3) Gemessen an den festen Paketgrößen von Adrive bzw. SugarSync läßt sich mittels Umrechnung auch der nominale Preis pro Gigabyte errechnen. Dies soll nur einmal als Vergleich zu S3 dienen. An der x-achse ist jeweils die Speichergröße pro Gigabyte abgetragen und an der y-achse der nominale Preis pro Gigabyte. Wie zu erwarten ist die Funktion für S3 vollständig konstant und liegt bei $0,14. Die anderen beiden Funktionen Verhalten sich unstetig fallend, haben Sprungstellen jeweils an den Paketgrenzen und tendieren gegen eine untere Schranke. 30 Kapitel 4 Preis von Cloudspeicher als nicht-funktionale Eigenschaft

31 Abbildung 4.4: Preis pro Gigabyte für Adrive, SugarSync und S Entwicklung einer Minimalkostenfunktion Nun stellt sich die Frage der Wirtschaftlichkeit, welche Funktion oder welcher Anbieter bzw. welche Kombination ist am günstigsten. Diese Aufgabe ist ein Optimierungsproblem im Sinne der Statistik. Im konkreten Fall wird das Minimum gesucht nämlich der kleinste Preis. Das bedeutet, um diese Fragestellung zu beantworten, muss das Minimum aus den Funktionswerten der Kostenfunktionen f(x), g(x) und h(x) an der gewünschten Stelle x errechnet werden. Die gesuchte Minimalkostenfunktion ist m(x). m(x) = min(f(x); g(x); h(x)) f(x) : (f(x) < g(x)) (f(x) < h(x)) = g(x) : (g(x) < f(x)) (g(x) < h(x)) h(x) : (h(x) < f(x)) (h(x) < g(x)) (4.4) Grafisch dargestellt ist dies am Beispiel aus Abbildung 4.3 eine Funktion k(x), deren Verlauf in Abbildung 4.5 grau gekennzeichnet und eine Kombination aus den Funktionen f(x), g(x) und h(x) ist. Konkreter ergibt sich durch Einsetzen der Funktionen f(x), g(x) und h(x) in die Funktion m(x) die Minimalkostenfunktion k(x), dargestellt als Funktion in (4.5). 4.2 Kostenfunktionen 31

32 Abbildung 4.5: Minimalkosten aus Adrive, SugarSync und S3 k(x) = = h(x) : x < 50 f(x) : x = 50 h(x) : (x > 50) (x < 100) f(x) : x = 100 h(x) : (x > 100) (x < 178) g(x) : (x 178) (x 250) h(x) : (x > 250) (x < 286) g(x) : (x 286) (x 500) 0, 14 x : x < 50 6, 95 : x = 50 0, 14 x : (x > 50) (x < 100) 13, 95 : x = 100 0, 14 x : (x > 100) (x < 178) 24, 99 : (x 178) (x 250) 0, 14 x : (x > 250) (x < 286) 39, 99 : (x 286) (x 500) (4.5) Im Allgemeinen lässt sich festhalten, dass die optimale Kostenfunktion für n Anbieter sich aus dem Minimum der Funktionswerte der n Kostenfunktionen an der gesuchten Stelle x ergibt. Dabei lassen sich also drei maschinell zu verarbeitende Kostenfunktionen aufstellen, entsprechend des jeweiligen Kostenmodells. In einer realen Geschäftsumgebung sind desweiteren die Kosten für den Datenstrom zum und vom Anbieter eines Speicherdienstes zu betrachten. Im Falle einer Migration, dem Wechsel zu einem anderen Anbieter und dem damit verbundenen Überspielen der Daten, können erhebliche Kosten entstehen. Dies kann zum Beispiel bedeuten, dass S3 Kunden, die zu SugarSync wechseln möchten (siehe Abbildung 4.5), erst wechseln sollten, wenn ein weiter anwachsender oder gleich bleibender Bedarf an Speicherplatz über 250 GB zu erwarten ist. Grund dafür sind Migrationkosten, dabei liegt der Preis pro Gigabyte im Bereich von 178 bis 250 GB bei SugarSync unter dem von S3. Allerdings ist ein Wechsel auch schon bei einer Größe von 178 GB zu empfehlen, da S3 ab 178 GB eigentlich nur noch im Bereich von 250 GB bis 268 GB 32 Kapitel 4 Preis von Cloudspeicher als nicht-funktionale Eigenschaft

33 vorteilhafter ist und in allen anderen Fällen SugarSync preiswerter. Ebenfalls von Interesse kann es sein ein Lösung für eine Preisobergrenze und/oder eine Mindestspeichermenge zu finden Nutzungsbasiert Zu einem nutzungsbasierten Kostenmodell lässt sich diese Funktion aufstellen in Form einer Kombination aus linearen Funktionen. Die einzelnen Teilfunktionen sind jeweils in einem bestimmten Intervall gültig und bilden zusammen die Kostenfunktion des Dienstes. Für Amazon S3 lässt sich diese in (4.6) aus der Tabelle Auszug Preisliste S3, Region EU aus Abschnitt wie folgt aufstellen und kann schließlich zu (4.7) verallgemeinert werden als k N (x). Dabei ist a i ein Faktor, welcher dem Preis pro Speichereinheit (Gigabyte) entspricht und i i eine Intervallgrenze für die Gültigkeit der Teilfunktion. s(x) = 0, 14 x : (x > 0) (x 1000) 0, 125 x : (x > 1000) (x 50000) 0, 11 x : (x > 50000) (x ) 0, 095 x : (x > 50000) (x ) 0, 08 x : (x > ) (x ) 0, 055 x : (x > ) (4.6) k N (x) = a 1 x : (x > 0) (x i 1 ) a 2 x : (x > i 1 ) (x i 2 )... a i x : (x > i i 1 ) (x i i )... a n x : (x > i n 1 ) (x i n ) (4.7) Paketpreis Für Paketpreismodelle ist am Beispiel von SugarSync in (4.2) dargestellt wie eine Kostenfunktion aussehen kann. Auch diese ist zusammengesetzt aus Teilfunktionen und lässt sich verallgemeinert in (4.8) als k P (x) aufschreiben. Dabei ist eine dem Paketpreis entsprechende Konstante k i vorhanden und eine Intervallgrenze i i für die Gültigkeit der Teilfunktion. k P (x) = k 1 : (x > 0) (x i 1 ) k 2 : (x > i 1 ) (x i 2 )... k i x : (x > i i 1 ) (x i i )... k n x : (x > i n 1 ) (x i n ) (4.8) Hybrid Ein hybrides Kostenmodell wäre auch denkbar, nämlich z.b. eine Kombination von Paketpreis und Pay-Per-Use. Dabei könnten bis zu einer gewissen Obergrenze Speicherpaket zu 4.2 Kostenfunktionen 33

34 Pauschalpreisen angeboten werden und darüber hinaus die Abrechnung nutzungsgenau nach Einheiten erfolgen. So wäre ein Dienst sowohl für Privatkunden mit kleinen Speicherpaketen und günstigen Konditionen ebenso attraktiv wie für Geschäftskunden mit größerem Speicherbedarf und dem Wunsch nach höherer Flexibilität. Leider konnte während der Recherchen kein entsprechender Anbieter als Beispiel gefunden werden. Für diesen Fall wäre eine Kostenfunktion k H (x) denkbar, so dass eine Kombination aus einer k N (x) und einer k P (x) Funktion entsteht (4.9). Das bedeutet bis zu einer bestimmten Grenze (i) gilt eine Abrechnung per Paketpreis und darüber hinaus wird nutzungsbasiert abgerechnet. k H (x) = { kp (x) : (x > 0) (x i) k N (x) : (x > i) (4.9) 34 Kapitel 4 Preis von Cloudspeicher als nicht-funktionale Eigenschaft

35 5 IMPLEMENTIERUNG 5.1 ARCHITEKTURÜBERSICHT Das im Rahmen dieser Bakkalaureatsarbeit zu implementierende Anwendungsszenario umfasst eine Reihe von Schnittstellen und Komponenten, die in diesem Abschnitt erläutert werden sollen. Das System lässt sich in zwei Hauptbestandteile zerlegen, zum einen in den Roboterprototyp, welcher die Daten generiert und als zweiten in eine Mittelschicht, die den Nachrichtenaustausch abwickelt sowie die Anwendungslogik zur Speicherallokation und -skalierung in der Cloud kapselt. Dazu gehört auch eine einfache Web-Benutzeroberfläche über Metriken der Dienstnutzung und eine Datenbank für die Benutzerverwaltung, die aus Gründen der prototypischen Umsetzung des Gesamtsystems nicht in die Cloud ausgelagert ist. Das Anwendungsszenario ist nach dem Architekturansatz der Service Orientierten Architektur als verteiltes System entwickelt. Die dafür zu implementierenden Dienste sind als REST-Webservices ausgelegt. Nach dem REpresentational State Transfer (REST) Architekturstil wird zur Datenübermittlung das Hypertext Transfer Protokoll (HTTP) genutzt und dessen dedizierte Methodik zur Beschreibung serverseitig auszuführender Funktionalität. Die Webservicesimplementierungen erfolgen in der Programmiersprache Java unter zur Hilfenahme des Jersey Frameworks, einer Referenzimplementierung der Java API for RESTful Web Services (JAX-RS) und der Java Persistence API (JPA). Die Schnittstellendefinitionen und Dienstbeschreibungen sind durch die Web Application Description Language (WADL) realisiert und publiziert. Als Applicationserver kommt der Oracle GlassFish Server zum Einsatz auf dem als Web Archiv (*.war) gepackt die Webserviceschnittstelle des Roboterprototyps sowie der Cloud-Webservice deployed wird. Zur Kapselung der Anwendungslogik werden Enterprise Java Beans (EJB) Komponenten genutzt [RSB04]. Die Umsetzung der graphischen Web-Benutzeroberfläche (Web-GUI) erfolgt im Rahmen des Java Server Faces (JSF) Framework. Als Datenbank zur Verwaltung der Benutzerdaten wird die integrierte JavaDB genutzt. Um dynamisch Cloud Dienste zu binden wird ein entferntes Dienstverzeichnis verwendet (ConQo). Für eine einheitliche REST Schnittstelle zu den Systemen der einzelnen Storage-Cloud-Anbieter wird das Ruby-basierte Deltacloud ( als Abstraktionsschicht verwendet. Als weitere Schicht ist die Persistenzschicht zu nennen, welche durch die Dienste der Cloudspeicheranbieter abstrahiert wird. 35

36 Abbildung 5.1: Architekturübersicht 5.2 AGENTENPROTOTYP MIT WEBSERVICE SCHNITTSTELLE Die erstellte Schnittstelle (AgentProtoREST) bietet die Möglichkeit eine Anzahl von Dateien an einen REST Webservice Entrypoint zu schicken. Dabei ist eine einfache Methode sendfilesbycount implementiert. Damit lassen sich aus einem lokalen Verzeichnis Dateien an einen Service versenden. Mit dem folgenden HTTP-GET Aufruf und zugeordneten Queryparametern lässt sich anweisen, dass die zwei aktuellsten also zuletzt hinzugefügten Dateien (Queryparameter: count=2) an einen REST Webservice (Queryparameter: to) zuschicken sind. Zusätzlich sind Benutzername Max und Passwort Muster angegeben. Zu verwenden ist die HTTP-POST Methode für den Aufruf des Entrypoints und das Speicherbucket als Queryparameter folder angegeben ist hier mybuck3t_9. GET &password=muster&method=post&folder=mybuck3t_9 &to= Die zugehörige WADL Datei ist wie folgt dargestellt: <?xml version= 1.0 encoding= UTF-8 standalone= yes?> <application xmlns= > <doc xmlns:jersey= jersey:generatedby= Jersey: /14/ :36 PM /> <resources base= > 36 Kapitel 5 Implementierung

37 <resource path= > <resource path= /send > <method id= sendfilesbycount name= POST > <request> <param xmlns:xs= name= count style= query type= xs:int default= 0 /> <param xmlns:xs= name= to style= query type= xs:string default= /> <param xmlns:xs= name= folder style= query type= xs:string default= /> <param xmlns:xs= name= username style= query type= xs:string default= /> <param xmlns:xs= name= password style= query type= xs:string default= /> <param xmlns:xs= name= method style= query type= xs:string default= POST /> </request> <response> <representation mediatype= text/html /> </response> </method> </resource> </resource> </resources> </application> 5.3 MIDDLEWARE MIT CLOUD-WEBSERVICE Dieser Teil ist der zentrale Teil des Anwendungsszenarios mit der REST Schnittstelle für Blobstorage zur Deltacloud API (BlobstorageFacade). Die Logik zur Auswahl der Cloudanbieter sowie der Mechanismus zur Cloudskalierung. Eine SQL Datenbank für die Benutzerauthentifikation, die Anmeldedaten der Cloudzugänge der Nutzer und Speicherplatzauslastungen Datenbank für Benutzerdaten Die Datenbank umfasst vier Tabellen: Users, Users_Groups, Clouds und Users_Clouds. Die Tabelle Users besteht aus den Spalten ID (Primärschlüssel), USERNAME und PASSWORD_MD5. Die Tabelle Users_Groups besitzt ID (Primärschlüssel), GROUPNAME und USERNAME (Fremdschlüssel aus der Tabelle Users). Diese beiden Tabellen werden für die Authentifizierung am Webservice verwendet. Ein Benutzer hat einen Benutzernamen, ein Passwort und gehört einer oder mehreren Gruppen an. Die Tabelle Clouds umfasst die Cloudanbieter und die Entrypoints ihrer Services, also die URLs unter denen diese erreichbar sind. Die zugehörigen Spalten in der Tabelle Clouds sind ID (Primärschlüssel), NAME und ENTRYPOINT. Der Tabelle Users_Clouds besitzt die Spalten ID (Primärschlüssel), ACCOUNT, PASSWORD_MD5, PRICE, BYTES_MAX, BYTES_USED und die Fremdschlüssel C_ID (ID aus Clouds) und U_USERNAME (USERNAME aus Users). Einem Benutzer können hier ein oder mehrere Cloudaccounts zugeordnet werden, die Anmeldedaten dieser sind hinterlegt sowie der genutzte Speicherplatz und dessen Gesamtgröße in Bytes sowie die Kosten. Als Datenbankmanagementsystem kommt hier Apache Derby, auch bekannt als embedded 5.3 Middleware mit Cloud-Webservice 37

38 Java DB, zum Einsatz. Zu beachten ist dabei, dass der Name für das benutzte Schema mit dem Accountnamen der Datenbank übereinstimmt und eventuell auch dieses als Standard-Schema ausgewählt ist, da es sonst bei Zugriffen im Zusammenhang mit der JPA zu Fehlern kommt, so dass nicht auf die Daten zugegriffen werden kann. Die Wahl fiel auf Apache Derby, da dieser in der Entwicklungsumgebung der Netbeans IDE bereits integriert ist und kaum zusätzlicher Konfiguration bedarf. Apache Derby wird im Zusammenhang mit dem Java Development Kit (JDK) als integrierte Datenbank automatisch installiert. Das SQL-Skript zum erzeugen der Datenbankstruktur könnte folgendermaßen aussehen: CREATE TABLE CLOUDS (ID INTEGER NOT NULL, NAME VARCHAR(64) NOT NULL, ENTRYPOINT VARCHAR(255) NOT NULL, PRIMARY KEY (ID)); CREATE TABLE USERS (USERNAME VARCHAR(64) NOT NULL, PASSWORD_MD5 VARCHAR(64) NOT NULL, ID INTEGER NOT NULL, PRIMARY KEY (USERNAME)); CREATE TABLE USERS_CLOUDS (ID INTEGER NOT NULL, ACCOUNT VARCHAR(64), PASSWORD_MD5 VARCHAR(64), PRICE DECIMAL(7, 2) DEFAULT 0.00 NOT NULL, BYTES_MAX BIGINT DEFAULT 0 NOT NULL, BYTES_USED BIGINT DEFAULT 0 NOT NULL, C_ID INTEGER NOT NULL, U_USERNAME VARCHAR(64) NOT NULL, PRIMARY KEY (ID)); CREATE TABLE USERS_GROUPS (ID INTEGER NOT NULL, GROUPNAME VARCHAR(64), USERNAME VARCHAR(64) NOT NULL, PRIMARY KEY (ID)); Benutzerauthentifikation Ein Mechanismus zur Benutzerauthentifikation für HTTP-Anfragen ist durch den Glassfish-Server bereitgestellt und muss per Konfiguration auf die vorhandene Datenbank angepasst werden. Dafür muss die Glassfish Administrations Console aufgerufen werden unter Unter Allgemeine Aufgaben kann der folgende Pfad aufgerufen werden: Konfigurationen > server-config (o.ä.) > Sicherheit > Bereiche. Hier muss ein neuer Bereich (englisch realm ) beispielsweise userauthn für die zukünftige Authentifikation angelegt werden und dafür die Klasse mit dem Klassennamen com.sun.enterprise.security.auth.realm.jdbc.jdbcrealm zugewiesen werden. Abschließend sind diverse Parameter, klassenspezifische Eigenschaften, wie z.b. JDNI-Name der Datenbankresource oder Datenbankbenutzer/-passwort zu setzen, dies kann wie folgt aussehen: 38 Kapitel 5 Implementierung

39 Klassenspezifische Eigenschaften JAAS-Kontext: jdbcrealm JNDI: samplederby Benutzertabelle: USERS Benutzernamenspalte: USERNAME Passwortspalte: PASSWORD_MD5 Gruppentabelle: USERS_GROUPS Gruppennamenspalte: GROUPNAME Gruppen zuordnen: Datenbankbenutzer: APP Datenbankpasswort: 123 Digest-Algorithmus: MD5 Codierung: Hex Zeichensatz: Durch die Angabe eines Digest-Algorithmus (kryptographische Hashfunktion), in diesem Beispiel wird der Message-Digest Algorithm 5 (MD5) verwendet. Es müssen in der Datenbank in der zugeordenten Passwortspalte (hier PASSWORD_MD5) keine Klartestpasswörter gespeichert werden, sondern lediglich die Hashes derer. Weitere Möglichkeiten sind z.b. der Secure Hash Algorithm (SHA), die Verwendung von SHA-25 wird empfohlen, da dieser mittlerweile der vordefinierte Digest-Algorithmus des Glassfish-Servers ist, falls keine Eingabe an dieser Stelle getätigt wird. Desweiteren sind Konfigurationen in der web.xml des Servers erforderlich. Hier können konkrete Aussagen über die zu sichernden Bereiche anhand von HTTP-Request-Methoden und URL-Pfaden getroffen werden. Der folgende Auszug aus der web.xml Konfiguration zeigt, dass der URL Bereich /upload/* für das GET, POST, HEAD, PUT, OPTIONS, TRACE und DELETE Request gesichert ist und somit eine Authentifikation erfordert. In diesem Fall ist die HTTP-Basic-Authentification eingestellt, außerdem erhalten nur Benutzer mit dem Rollennamen USERS Zugriff. <security-constraint> <display-name>upload</display-name> <web-resource-collection> <web-resource-name>upload</web-resource-name> <description/> <url-pattern>/upload/*</url-pattern> <http-method>get</http-method> <http-method>post</http-method> <http-method>head</http-method> <http-method>put</http-method> <http-method>options</http-method> <http-method>trace</http-method> <http-method>delete</http-method> </web-resource-collection> <auth-constraint> <description>has to be a USER</description> <role-name>users</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>basic</auth-method> <realm-name>userauthn</realm-name> </login-config> <security-role> 5.3 Middleware mit Cloud-Webservice 39

40 <description/> <role-name>users</role-name> </security-role> Zusätzlich ist es nun notwendig das Security-Role-Mapping der glassfish-web.xml zu erweitern um den Rollennamen USERS. An dieser Stelle erfolgt die Verknüpfung zum Gruppennamen USERS welcher in der korrespondierenden Datenbanktabelle (hier Users_Groups ) angelegt werden sollte. Jeder Benutzer der somit laut Datenbank Mitglied der Gruppe USERS ist erhält Zugriff auf die zuvor definierten Ressourcen. <security-role-mapping> <role-name>users</group-name> <group-name>users</group-name> </security-role-mapping> Per kann die Spezifikation der Zugriffsrechte auf Ressourcen erfolgen. Eine in Verbindung mit dem Typ javax.ws.rs.core.securitycontext erzeugt zur Laufzeit einen Sicherheits-Kontext woraus sich z.b. der authentifizierte Nutzer an Hand seines Namens identifizieren lässt. Die Implementation könnte wie folgt aussehen: import upload public class UploadService SecurityContext security; public UploadService() /name USERS }) public Response getusername() { return Response.ok(security.getUserPrincipal().getName()).build(); } Die implementierte Middleware besitzt ebenfalls eine mit dem Jersey-Framework erstellte REST-Schnittstelle. Diese ist eine Abstraktion der Deltacloud API und beschränkt sich auf die Blobstorage Funktionalität. Die Ressourcen sind unter dem Pfad /CloudMiddlewareREST/upload/ zusammengefasst und ein Einblick in die zugehörige WADL Schnittstellendefinition: 40 Kapitel 5 Implementierung

41 <?xml version= 1.0 encoding= UTF-8 standalone= yes?> <application xmlns= > <doc xmlns:jersey= jersey:generatedby= Jersey: /14/ :36 PM /> <resources base= > <resource path= upload > <method id= getuserfolders name= GET > [..] </method> [..] </resource> </resources> </application> Für den Zugriff auf die Ressourcen des Pfades /CloudMiddlewareREST/upload/ und der davon abgeleiteten Pfade wird bei einer HTTP-Anfrage die HTTP-Basis-Authentifizierung benötigt. Für diese Identitätsprüfung wird der Benutzername und Passwort mit einem Doppelpunkt : zu einer Zeichenkette konkatiniert und das Resultat Base64 kodiert ( Das kodierte Ergebnis wird schließlich im Header der HTTP-Anfrage eingefügt. Für einen Benutzer Max mit dem Passwort MuSt3rm4nn kann ein HTTP-Header wie folgt aussehen: GET CloudMiddlewareREST/upload/ HTTP/1.1 Host: localhost:8080 Authorization: Basic TWF4Ok11U3Qzcm00bm4= API Beschreibung Die Ressourcenpfade der Schnittstelle sind wie folgt beschrieben, der Hauptpfad /CloudMiddlewareREST/upload/ und optional ein oder zwei zusätzliche Pfadparameter. Der erste spezifiziert den Namen bzw. die ID eines Cloud-Buckets und der zweite den Namen bzw. die ID eines Binary Large OBject (Blob), ein Objekt welches Daten enthält. Mittels verschiedener HTTP-Methoden können auf den URLs verschiedene Funktionalitäten ausgeführt werden. 5.3 Middleware mit Cloud-Webservice 41

42 HTTP URL Pfad- Beschreibung Methode parameter GET upload/ alle Nutzerbuckets abrufen GET upload/{folder} folder alle Elemente des Nutzerbuckets {folder} abrufen POST upload/{folder} folder neues Bucket mit Namen {folder} erstellen DELETE upload/{folder} folder Bucket mit dem Namen {folder} löschen GET upload/{folder}/{filename} folder, Blob mit dem Namen {filename} filename POST upload/{folder}/{filename} folder, filename DELETE upload/{folder}/{filename} folder, filename abrufen neues Blob mit dem Namen {filename} im Bucket {folder} erstellen und Inhalt senden Blob mit dem Namen {filename} aus Bucket {folder} löschen Die Funktionen sind angelehnt an den Blobstorage Teil der Deltacloud API und stellt quasi eine Fassade dazu dar. Zusätzlich ist das Auslesen des belegten Speicherplatzes von Buckets bzw. Blobs verfügbar Dynamisches Dienstverzeichnis Als Verzeichnisdienst kann ConQo ein an der TU Dresden entwickeltes Projekt eingesetzt werden. Es bietet die Möglichkeit Webservices zu suchen und auszuwählen unter Einbeziehung von Kontextsensitivität und QoS-Anforderungen (Quality Of Service). Dabei sind als Anfrageparameter sowohl Informationen zum Kontext des zu suchenden Webservices als auch zur Sicherung der Servicequalität nicht-funktionaler Eigenschaften anzugeben. Das System liefert dann auf Grundlage beider Informationen die geeigneten Dienste. 5.4 DELTACLOUD ALS CLOUD-ANBINDUNG Deltacloud ist eine abstrakte Cloud-Schnittstelle auf Basis einer REST (Representational State Transfer) API, welche eine homogene Schnittstelle zu diversen Cloudanbietern ermöglicht. Das Projekt wird von der Apache Incubator Plattform ( unterstützt und bereitgestellt. Über proprietäre Treiber werden die nativen Anbieter APIs auf die REST API von Deltacloud gemappt. Unterstützte Clouddienstleister sind z.b. Amazon EC2, OpenNebula oder GoGrid für Anbieter von Rechenkapazität bzw. Eucalyptus Walrus, Microsoft Azure oder Rackspace CloudFiles Datenspeicherung. 42 Kapitel 5 Implementierung

43 Deltacloud Treiberunterstützung ( Anbieter Computedienst Speicherdienst Amazon ja (EC2) ja (S3) Eucalyptus ja ja (Walrus) IBM ja (SBC) - GoGrid ja - Google - geplant (Storage) OpenNebula ja - Rackspace ja (Cloud Servers) ja (Cloud Files) RHEV-M ja - RimuHosting ja - Terremark ja - vsphere geplant - Das Projekt befindet sich noch in der Entwicklung und ist zur Zeit (Stand: Oktober 2011) in der Version verfügbar. Dennoch ist eine umfangreiche API Spezifikation und Funktionalität bereits vorhanden ( Die API umfasst den Zugriff auf zwei wichtige Bereiche des Cloud Computings, die Rechen- und Speicherressourcen. Es existieren Schnittstellen für die Bereiche der Verwaltung von Realms, Hardware Profilen, Images, Instanzen, Keys, Firewalls, Adressen und Lastverteilern für Rechenclouds. Im Kontext der Speicherclouds sind die Bereiche Speichervolumes, Speicherabbilder und Blob Speicherung bereits abgedeckt. Ein klarer Vorteil von Deltacloud ist, dass es zwar in Ruby entwickelt wird, sich aber in seiner Verwendung plattformunabhängig präsentiert und sowohl auf Linux als auch auf Windows-Systemen lauffähig ist. Die Auslegung als RESTful Webservice macht dies möglich. Neben der standardmäßig angebotenen Treiberunterstützung für ausgewählte Anbieter, lassen sich auch eigene Erweiterungen schreiben und das System somit individuell erweitern Installation Zur Installation von Deltacloud (deltacloud-core) unter Linux gibt es zwei Möglichkeiten. Zum einen über die in Linux Distributionen häufig integrierte RPM Paketverwaltung ( Die Installation überprüft und aktualisiert sämtliche Abhängigkeiten von deltacloud-core zu Programmen oder Bibliotheken und stellt diese automatisch bereit. Diese Installation ist aktuell nur unter der Linux Distribution Fedora ( ab Version 14 verfügbar. In Abbildung 5.2 ist das Suchergebnis für den Suchbegriff deltacloud, die korrespondierenden RPMs dargestellt ( Als weitere Möglichkeit zur Installation z.b. auf anderen Distributionen muss deltacloud-core welches als RubyGem verfügbar ist, zusammen mit seinen Abhängigkeiten manuell installiert werden. Dies kann über den System integrierten Paketmanager erfolgen. Es sollte die Verfügbarkeit von folgenden Paketen sichergestellt werden: ruby, ruby-devel, gem (RubyGems), gcc-c++, libxml2, libxml2-devel, libxslt, libxslt-devel, rake. Dies kann über das Systemterminal bzw. Console mit einen Paketmanager der Wahl wie yum oder apt-get folgendermaßen erfolgen: $ sudo yum install ruby bzw. 5.4 Deltacloud als Cloud-Anbindung 43

44 Abbildung 5.2: RPM Suchergebnis von pbone.net $ sudo apt-get install ruby Weiterhin sind die folgenden Pakete zu installieren, wenn noch nicht auf dem System verfügbar. $ sudo yum install ruby-devel $ sudo yum install gcc-c++ $ sudo yum install libxml2 libxml2-devel $ sudo yum install libxslt libxslt-devel Schließlich das RubyGem rake, welches eine Art make ( für die Ruby Umgebung darstellt. Zum Abschlußwird deltacloud-core, welches den eigentlichen Deltacloud Server darstellt, installiert. $ sudo gem install rake $ sudo gem install deltacloud-core Damit sind alle Abhängigkeiten von Deltacloud und der Server über deltacloud-core installiert. Der Server kann mit einem Treiber über den Schalter -i (hier z.b. EC2 für die Eucalyptus Umgebung) gestartet werden. Zusätzlich kann optional die IP-Adresse über den Schalter -r (hier z.b ), die Standardadresse ist localhost) auf welche der Server hören soll angegeben werden. Optional ist desweiteren der Port über den Schalter -P einstellbar auf dem der Server läuft, der Standardport ist Der Server kann nun mit dem Befehl deltacloudd und den beschriebenen Schaltern über das Systemterminal gestartet werden. Somit ist der Server gestartet (Abbildung 5.3) und voll funktionsfähig. Nun können Aufrufe über einen Webbrowser oder ein REST-Plugin für diesen gestartet werden. Verfügbare Plugins sind für Mozilla Firefox z.b. REST Client for Firefox oder für Google Chrome z.b. Simple REST Client oder auch der crest Client (Abbildung 5.4). Letzterer bietet im Vergleich den größten 44 Kapitel 5 Implementierung

45 Abbildung 5.3: Deltacloud Server Startup im Fedora-Terminal Funktionsumfang, ist sehr intuitiv in der Bedienung und benutzerfreundlich. Eingegebene URLs und HTTP-Header-Parameter werden in einer Historie gespeichert. Diese lassen sich bei Gelegenheit wieder aufrufen und einfügen. crest Client bietet mittels automatischer Vervollständigung auch Hilfestellung bei den URL Eingaben. Abbildung 5.4: Chrome REST Plugin: crest Client mit Deltacloud Anfrage REST API Um eine Anfrage über die verfügbaren Images zum Starten einer Instanz zu erhalten lässt sich beispielhaft eine REST-Anfrage wie folgt beschreiben: GET /api/images?owner_id= &architecture=x86_64&format=xml HTTP/ Deltacloud als Cloud-Anbindung 45

46 Authorization: Basic AU1J3UB2121Afd1DdyQWxLaTYTmJMNF4zTXBoRGdhMDh2 RUw5ZDAN9zVXVa== User-Agent: curl/ (i386-redhat-linux-gnu) Host: localhost:3001 Accept: */* [Quelle: Dabei wird über HTTP-Methode GET hier eine URL aufgerufen und mit GET-Parametern ergänzt. Als Parameter sind eine Benutzer ID, die Einschränkung der Ergebnisliste auf 64Bit-Architektur Images und als Rückgabeformat eine XML-Datei angegeben. Die Authentifikationsinformationen werden als Headerinformationen in Form der HTTP-Basic-Authentication mitgesendet. Der Zielrechner in diesem Fall ist eine lokale Instanz an Port Als Antwort sind alle MIME-Typen akzeptiert, allerdings wurde schon eine Einschränkung mittels URL-Parameter vorgenommen (Rückgabeformat: XML). Die Serverantwort für eine erfolgreiche Anfrage mit einer Instanz in der Ergebnisliste im XML Format könnte folgendermaßen aussehen: HTTP/ OK Content-Type: application/xml Content-Length: 1971 <?xml version= 1.0 encoding= utf-8?> <images> <image href= id= ami-eea35787 > <name>sles-10-sp3-v1.00.x86_64</name> <owner_id> </owner_id> <description>suse Linux Enterprise Server 10 Service Pack 3 for x86_64 (v1.00) </description> <architecture>x86_64</architecture> <state></state> <actions> <link href= method= post rel= create_instance /> </actions> </image> </images> [Quelle: Die Deltacloud API bietet für den Bereich Blobstorage eine Reihe an Funktionen an. Typische Funktionen sind dabei das Erstellen, Löschen von Blobs und Buckets, sowie das Auflisten des Bucketinhalts oder das Abrufen eines Blobinhalts. Zusätzlich gibt es die Möglichkeit benutzerdefinierte Metadaten zu Blobs zu speichern. 46 Kapitel 5 Implementierung

47 Deltacloud API für Blobstorage ( HTTP Pfad- Methode URL parameter Funktion GET /api/buckets Liste von Buckets GET /api/buckets/:id id Blobliste für Bucket POST /api/buckets Bucket erstellen DELETE /api/buckets/:id id Bucket mit ID :id löschen GET /api/buckets/:bucket_id/:blob_id bucket_id, Blobmetadaten anfordern blob_id GET /api/buckets/:bucket_id/:blob_id/ bucket_id, Blobinhalt abrufen content blob_id PUT /api/buckets/:bucket_id/:blob_id bucket_id, Blob hochladen blob_id POST /api/buckets/:bucket_id bucket_id Blob und Metadaten hochladen DELETE /api/buckets/:bucket_id/:blob_id bucket_id, Blob mit ID :blob_id löschen blob_id HEAD /api/buckets/:bucket_id/:blob_id bucket_id, blob_id die benutzerdefinierten Metadaten anfordern POST /api/buckets/:bucket_id/:blob_id bucket_id, benutzerdefinierten Metadaten blob_id zu Blob speichern :id & :bucket_id sind Platzhalter für die konkrete Bucket-ID, vgl. :blob_id für Blob-ID Die API weist in der aktuellen Version Einschränkungen im Umgang mit Verzeichnisstrukturen auf. So lassen sich zwar Inhalte abrufen, die sich nicht im Hauptverzeichnis des Buckets befinden über die Pfadadressierung (z.b GET../my_bucket/folder1/blob1/content), allerdings gib es nicht die Möglichkeit einen folder2 zu erstellen und dann in diesen oder auch in den folder1 Inhalte hochzuladen. Das bedeutet es kann nur in das Hauptverzeichnis des Buckets ein Blob gespeichert werden. Ein Manko stellt die fehlende Möglichkeit dar, über die API Informationen zur Größe des belegten Speicherplatzes von Buckets oder den enthaltenen Objekten (Blobs) zu beziehen. Für die einzelnen Blobs ist es lediglich möglich aus den Metadaten die Content-Length auszulesen, was der Größe der Nutzdaten des Blobs in Bytes entspricht Besonderheiten unter Windows Bei der Installation unter Windows-System ist die Funktionalität von Deltacloud nicht zu 100% gegeben. Getestet wurde mit einer Windows 7 Professional 64Bit Installation. Prinzipiell ist die Abfolge der Installationsschritte die selbe wie bei einem Linux-System, allerdings mit anderen und natürlich zum Teil mit Windows angepassten Versionen einzelner, benötigter Komponenten. Hier eine Kurzanleitung: Ruby für Windows ( - Download unter - Addon: Development Kit Download unter Deltacloud als Cloud-Anbindung 47

48 Installationdetails libxml2 & libxslt für Windows ( - Download unter ftp://ftp.zlatkovic.com/libxml/libxml win32.zip ftp://ftp.zlatkovic.com/libxml/libxslt win32.zip - Extrahieren und Systempfadvariable ($PATH) anpassen <Extraktionspfad>\libxml win32\bin und <Extraktionspfad>\libxslt win32\bin zu $PATH hinzufügen RubyGems installieren über die Systemconsole (cmd.exe) gem install rake gem install eventmachine pre gem install thin gem install deltacloud-core Ab dieser Stelle lässt sich Deltacloud mit der bekannten Syntax z.b. deltacloudd -i ec2 starten. Doch schon kurz nach dem Start tritt ein Fehler auf und die Ausführung wird unterbrochen. Grund ist der fehlende Syslog Dienst unter Windows-Systemen, welcher normalerweise zu Protokollierungszwecken im Unix Kontext genutzt wird. Dies lässt sich durch einen Eingriff in die Datei rack_syslog.rb umgehen. Dabei wird die Logging-Funktionalität außer Kraft gesetzt, indem folgende Auskommentierungen (# am Zeilenanfang) vorgenommen werden und quasi nur noch die Funktionsrümpfe stehenbleiben, dies geschieht aus Kompatibilitätszwecken. Das Einbinden von syslog und der Zugriff auf die wird so verhindert. Der Dateipfad ist: <RUBY_BASE_DIR>\lib\ruby\gems\1.9.1\gems\deltacloud-core-0.4.1\lib\sinatra\rack_syslog.rb # require syslog require lib/sinatra/body_proxy class SyslogFile < File end [..] def initialize = Syslog.open($0, Syslog::LOG_PID Syslog::LOG_LOCAL5) end def write(string) if string.strip.length > 0 return string.chars.count end def info(msg) end def err(msg) end alias :warning :err 48 Kapitel 5 Implementierung

49 Mit den genannten Anpassungen, kann somit auch auf einem Windows-System ein Deltacloud-Server operieren. Die Funktionalität wurde stichprobenartig überprüft und hat keine weiteren Probleme ergeben. Für den vollständigen Funktionsumfang kann die Logging-Funktionalität auch anderweitig realisiert werden, wenn darauf Wert gelegt wird. SysLog-Implementationen für Windows sind von verschiedenen Herstellern erhältlich WinSyslog ( Kiwi Syslog ( oder das Sourceforge-Projekt syslog-win32 ( Vergleichbare Projekte Ein ähnliches Konzept wie es Deltacloud verfolgt, nämlich verschiedene Speicherdienste oder Dateisysteme in einer API zu abstrahieren, wird auch in den Projekten jclouds und FUSE versucht zu realisieren. Bei Letzterem ist der Projektname eine Kurzform für Filesystem in USErspace. Es handelt sich dabei um eine besondere Erweiterung für Systeme mit Linuxkernel, die es ermöglicht Dateisystem relevante Operation bzw. gesamte Dateisysteme als Nutzerprogramm zu implementieren ( FUSE makes it possible to implement a filesystem in a userspace program. Features include: simple yet comprehensive API, secure mounting by non-root users, support for 2.4 and 2.6 Linux kernels, multi-threaded operation. etc... [Fus11] Die Implementation von Fuse erfolgte in C. Erweiterungstreiber für eigene Dateisysteme sind möglich und standardmäßig existiert schon eine breite Unterstützung durch verschiedene Treiber, die auf der Grundlage von Fuse basieren. Einige interessante Beispiele sind: SMB for Fuse ( zum Einbinden und Nutzen von Netzwerkfreigaben oder FlickerFS ( als Schnittstelle zum Bilderdienst Flickr. Ein sehr vielfältig nutzbarer Treiber für Cloudspeicherdienste stellt s2ql dar ( Laut Projektbeschreibung S3QL is a file system that stores all its data online using storage services like Google Storage, Amazon S3 or OpenStack [S3Q11] sollen sowohl Google Storage sowie Amazon S3 und OpenStack basierte Dienste unterstützt werden. In der Benutzerdokumentation lässt sich nachlesen, wie ein Zugriff auf Google Storage bzw. Amazon S3 zu erfolgen hat ( Besonderheit ist bei S3 die Abgrenzung, dass der Reduced Redundancy Storage Modus des Dienstes nicht unterstützt wird. Da eine S3-kompatible API (vgl. Abschnitt auf Seite 26) auch von diversen Speicherdienstlern angeboten wird, wurde auch in S3QL die Möglichkeit des Zugriffs auf diese Dienste realisiert. Eine Manko von Fuse ist seine Plattformabhängigkeit, da es nur auf Linux-basierten Systeme lauffähig ist. Für Java Projekte stellt jclouds eine Alternative für eine einheitliche API zum Ansprechen von Clouddiensten zur Verfügung. Eine ganze Reihe von Anbieter wird unterstützt darunter Amazon, Rackspace, Microsoft Azure und Eucalyptus. Eine Liste der unterstützten Anbieter befindet sich unter Selbst Deltacloud als eigenständige Abstraktionsschicht ist aufgeführt. Die Verwendung von jclouds erfolgt durch Einbinden der benötigten Paketbibliotheken in den Quellcode des Projekts und Aufrufen der entsprechenden Objektmethoden. Durch die Realisierung in Java ist eine Plattformunabhängigkeit zwar gegeben, aber die Funktionalität ist direkt an das jeweilige Projekt gebunden indem es genutzt wird. Deltacloud bietet sowohl die Möglichkeit auf verschiedenen Plattformen als eigenständiger Server somit als abgeschlossener Dienst lauffähig zu sein, unabhängig von dem Projekt für welches es gebraucht wird. Somit ist es auch für verschiedene Dienste oder Projekte universell einsetzbar im Gegensatz zu jcloud. Auch Fuse scheitert im Vergleich an der Plattformunabhängigkeit, jedoch ist es global auf einem System unabhängig nutzbar. 5.4 Deltacloud als Cloud-Anbindung 49

50 50 Kapitel 5 Implementierung

51 6 VALIDIERUNG Wie das im ersten Kapitel schon beschriebene Anwendungsszenario soll der erstellte Prototyp einen Agenten beinhalten, der Daten extern in der Cloud speichern soll. In diesem Fall soll es der Roboter Nao ( sein, welcher mit seiner Kamera Fotoaufnahmen macht und in einem Verzeichnis zwischenspeichert. Beispielhaft dafür ist ein Prototyp in Form einer Webservices erstellt worden. Dabei werden Dateien, hier Bilder an einen angegeben Endpunkt eines weiteren Webservices gesendet. Dieser ist in diesem Szenario Teil einer Middleware mit Benutzerverwaltung und Anbindung an verschiedene Cloudspeicherdienst. Eine Abstraktionsschicht sorgt für eine einheitliche Schnittstelle zu verschiedenen Clouddienstleistern. In der Abbildung 6.1 ist dieser Prototyp als Bestandteil eines Gesamtsystems mit aufgeführt. Abbildung 6.1: ResUbic Demo - flexcloud.eu (Quelle: Dr.-Ing. Josef Spillner, TU Dresden) Die angesprochene Middleware beinhaltet auch Mechanismen zur Skalierung von Cloudspeicher eines Nutzers. Der in Abschnitt beschriebene Algorithmus zur Skalierung durch Schwellenwertberechnung bildet die Grundlage der im Prototypen implementierten Skalierungslogik. Über die in 4.2 aufgestellten Kostenfunktionen wird die nicht-funktionale Eigenschaft Preis für Cloudspeicher bzw. die sich daraus ergebenden Kosten für die Nutzung des Dienstes formalisiert. Durch diese Art der funktionalen Beschreibung ist es möglich, die ursprünglich nicht-funktionale Eigenschaft durch eine Logik automatisiert zu verarbeiten. Für den 51