Cloud Computing: Web-basierte dynamische IT-Services, 2. Auflage

Informatik im Fokus

Herausgeber: Prof. Dr. O. Günther Prof. Dr. W. Karl Prof. Dr. R. Lienhart Prof. Dr. K. Zeppenfeld

Informatik im Fokus

Weitere Titel der Reihe Informatik im Fokus: http://www.springer.com/series/7871

Christian Baun  Marcel Kunze  Jens Nimis  Stefan Tai

Cloud Computing Web-basierte dynamische IT-Services 2. Auflage

123

Christian Baun Karlsruhe Institute of Technology (KIT) Steinbuch Center for Computing Hermann-von-Helmoltz-Platz 1 76344 Eggenstein-Leopoldshafen Deutschland [email protected]

Prof. Dr. Jens Nimis Hochschule Karlsruhe Fakultät für Wirtschaftswissenschaften Moltkestr. 30 76133 Karlsruhe Deutschland [email protected]

Dr. Marcel Kunze Karlsruhe Institute of Technology (KIT) Steinbuch Center for Computing Hermann-von-Helmoltz-Platz 1 76344 Eggenstein-Leopoldshafen Deutschland [email protected]

Prof. Dr. Stefan Tai Karlsruhe Institute of Technology (KIT) & FZI Forschungszentrum Informatik Englerstr. 11 76131 Karlsruhe Deutschland [email protected]

ISSN 1865-4452 e-ISSN 1865-4460 ISBN 978-3-642-18435-2 e-ISBN 978-3-642-18436-9 DOI 10.1007/978-3-642-18436-9 Springer Heidelberg Dordrecht London New York Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. c Springer-Verlag Berlin Heidelberg 2010, 2011  Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Einbandentwurf: KuenkelLopka GmbH, Heidelberg Gedruckt auf säurefreiem Papier Springer ist Teil der Fachverlagsgruppe Springer Science+Business Media (www.springer.com)

Vorwort

Vorwort zur 2.Auflage Die Entwicklungen im Bereich des Cloud-Computing sind weiterhin sehr dynamisch. Aus diesem Grund haben wir uns entschlossen, nach nur knapp einem Jahr seit Erscheinen der 1. Auflage eine Aktualisierung und Ergänzung des Stoffes vorzunehmen. Die verschiedenen Kapitel des Buches wurden entsprechend überarbeitet und neue Technologien (u. a. Hadoop as a Service, Cloud Print, Cloud Gaming) und Produkte (u. a. Amazon RDS, Amazon VPC, Nimbus, OpenNebula, typhoonAE) aufgenommen. Karlsruhe Februar 2011

Christian Baun Marcel Kunze Jens Nimis Stefan Tai

v

vi

Vorwort

Vorwort zur 1.Auflage Cloud Computing ist in aller Munde: als neuartige Technologie, als nächste Generation des Internets, als fundamentale Veränderung der gesamten IT-Landschaft und als viel versprechende Chance für neue Geschäftsideen. Doch was steckt wirklich hinter dem Begriff? Die vielfältigen Standpunkte und Interessen der verschiedenen Stakeholder haben dazu geführt, dass das Thema Cloud Computing nicht sehr scharf umrissen erscheint. Unser Anliegen ist es, den häufig zitierten Nebel, der die Cloud umgibt, ein Stück weit zu lichten und so den Weg zu ebnen für einen erfolgreichen Einsatz und auch für weitergehende Forschungsarbeiten und neue Innovationen. In nur wenigen Monaten haben wir das mittlerweile sehr umfangreiche Material zum Thema Cloud Computing zusammengetragen und so verdichtet, dass es in eine Ausgabe der Serie Informatik im Fokus passt. Hilfreich waren hier unsere vielfältigen Kontakte zu Kollegen aus der Forschung und vor allem auch aus der Industrie. Sie haben uns mit einem nicht enden wollenden Strom von neuen Inputs versorgt und in zahlreichen Diskussionen geholfen, unser eigenes Bild auf die Materie zu schärfen. Wie die meisten disruptiven Technologien erfährt das Cloud Computing sehr unterschiedliche Einschätzungen, wenn es um Akzeptanz und Risikobewertung geht. Manche Unternehmen sind auf das dynamische Nutzen oder Anbieten von IT-Services noch nicht eingestellt – andere hingegen sind Vorreiter auf diesem Gebiet und erleben z. T. Erfolge, die Schlagzeilen machen. Dieses Buch soll dazu beitragen, Cloud Computing zunächst nüchtern zu studieren, um sich anschließend enthusiastisch den vielfältigen Herausforderungen und Chancen zu stellen. Die Tatsache, dass beim Cloud Computing technologische und wirtschaftliche Aspekte immer zusammen betrachtet werden müssen, führt dazu, dass wir mit unserem Buch interessante

Vorwort

vii

Einsichten für einen großen Leserkreis bieten können. Es richtet sich gleichermaßen an Studenten unserer Lehrveranstaltungen an der Universität Karlsruhe (TH) und an anderen Hochschulen, an interessierte Software-Ingenieure und an zukunftsorientierte Entscheidungsträger. Wir hoffen, dass das Buch auf der technischen Ebene reichhaltig und verständlich ist und dass es darüber hinaus auch in den Management-Etagen Gefallen finden wird. Wir wollen die Gelegenheit nutzen und allen danken, die zu der Erstellung dieses Buches beigetragen haben. Insbesondere danken wir Anja Langner und Bianca Pagliosa für die wertvolle Hilfe bei der Erstellung der Abbildungen, Matthias Bonn für das Korrekturlesen, sowie unseren Familien und Freunden für ihr Verständnis, die gemeinsame Freizeit wieder einmal zu opfern. Karlsruhe Juli 2009

Christian Baun Marcel Kunze Jens Nimis Stefan Tai

Inhaltsverzeichnis

1

Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Beschreibung der Thematik . . . . . . . . . . . . . . . . . 1.2 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 4 6

2

Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Virtualisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Vor- und Nachteile der Virtualisierung . . 2.1.2 Virtualisierungskonzepte . . . . . . . . . . . . . 2.2 Service-orientierte Architekturen . . . . . . . . . . . . 2.2.1 Eigenschaften von SOA . . . . . . . . . . . . . . 2.2.2 Implementierung einer SOA . . . . . . . . . . 2.3 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Interoperabilität . . . . . . . . . . . . . . . . . . . . 2.3.2 SOAP versus REST . . . . . . . . . . . . . . . . .

9 9 10 12 19 19 21 22 24 25

3

Cloud-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Public, Private und Hybrid Clouds . . . . . . . . . . . 3.2 Technische Landschaft der Cloud-Dienste . . . . . 3.3 Infrastructure as a Service . . . . . . . . . . . . . . . . . .

27 27 29 31 ix

x

Inhaltsverzeichnis

3.4 3.5 3.6 3.7 4

5

Platform as a Service . . . . . . . . . . . . . . . . . . . . . . Software as a Service . . . . . . . . . . . . . . . . . . . . . . Humans as a Service . . . . . . . . . . . . . . . . . . . . . . . Weitere Kategorien von Cloud-Diensten . . . . . .

35 37 39 41

Ausgewählte Cloud-Angebote . . . . . . . . . . . . . . . . . . 4.1 Amazon Web Services . . . . . . . . . . . . . . . . . . . . . 4.1.1 Amazon Elastic Compute Cloud (EC2) . 4.1.2 Amazon Simple Storage Service (S3) . . 4.1.3 Amazon Elastic Block Store (EBS) . . . . 4.1.4 Amazon Simple Queue Service (SQS) . . 4.1.5 Amazon SimpleDB . . . . . . . . . . . . . . . . . 4.1.6 Amazon Relational Database Service . . 4.1.7 Zusammenspiel der Amazon Web Services . . . . . . . . . . . . 4.2 Cloud-Dienste von Google . . . . . . . . . . . . . . . . . . 4.2.1 Google App Engine . . . . . . . . . . . . . . . . . 4.2.2 Google Storage . . . . . . . . . . . . . . . . . . . . . 4.2.3 Google Cloud Print . . . . . . . . . . . . . . . . . 4.3 Windows Azure . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Salesforce.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Cloud Gaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 Cloud-Betriebssysteme . . . . . . . . . . . . . . . . . . . . .

43 44 46 54 54 55 56 57

Cloud-Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Dienstgütevereinbarungen: Service Level Agreements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Lebenszyklus und Automatisierung . . . . . . . . . . 5.3 Management-Dienste und -Werkzeuge . . . . . . . . 5.3.1 Überwachung . . . . . . . . . . . . . . . . . . . . . . 5.3.2 Steuerung . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.3 Entwicklung . . . . . . . . . . . . . . . . . . . . . . . 5.4 Sicherheitsmanagement . . . . . . . . . . . . . . . . . . . . 5.5 Risikomanagement . . . . . . . . . . . . . . . . . . . . . . . .

73

59 61 61 64 65 66 68 70 71

73 75 76 76 77 83 85 87

Inhaltsverzeichnis

5.6

xi

Rechtskonformität . . . . . . . . . . . . . . . . . . . . . . . . .

88

6

Open Source Cloud-Schichtenmodell . . . . . . . . . . . . 6.1 Physische und Virtuelle Ressourcen . . . . . . . . . . 6.2 Eucalyptus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Architektur und Komponenten . . . . . . . . 6.3 OpenNebula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 Nimbus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5 CloudStack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6 OpenStack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.7 AppScale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.8 typhoonAE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.9 Apache Hadoop . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.9.1 MapReduce . . . . . . . . . . . . . . . . . . . . . . . . 6.9.2 Hadoop Distributed File System . . . . . . . 6.9.3 Pig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.9.4 Hive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.9.5 Hadoop as a Service . . . . . . . . . . . . . . . . . 6.10 Das OpenCirrusTM -Projekt . . . . . . . . . . . . . . . . . .

91 92 94 95 99 100 102 102 103 103 104 105 106 108 109 109 111

7

Wirtschaftliche Betrachtungen . . . . . . . . . . . . . . . . . 7.1 Anwendungsgebiete . . . . . . . . . . . . . . . . . . . . . . . 7.2 Bewertungsmodelle . . . . . . . . . . . . . . . . . . . . . . . . 7.2.1 Kostenmodelle . . . . . . . . . . . . . . . . . . . . . 7.2.2 TCO Framework . . . . . . . . . . . . . . . . . . . . 7.3 Geschäftsmodelle . . . . . . . . . . . . . . . . . . . . . . . . .

115 115 117 119 120 121

8

Chancen und Risiken . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1 Marktentwicklung . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Situative Bewertung . . . . . . . . . . . . . . . . . . . . . . . 8.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

125 125 126 128

xii

9

Inhaltsverzeichnis

Anhang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1 Bedienung von EC2 mit den Amazon Tools . . . . 9.2 Bedienung von EBS mit den Amazon Tools . . . 9.3 Bedienung von RDS mit den Amazon Tools . . . 9.4 Bedienung von S3 mit s3cmd . . . . . . . . . . . . . . . 9.5 Bedienung der Google App Engine . . . . . . . . . . . 9.6 Bedienung von AppScale . . . . . . . . . . . . . . . . . . . 9.7 Installation und Bedienung von Eucalyptus . . . . 9.8 Data Mining mit Amazon Elastic MapReduce . .

131 131 134 135 137 138 140 140 146

Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Sachverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Kapitel 1

Einleitung

Die Buchreihe Informatik im Fokus beschäftigt sich mit der Darstellung zeitnaher und gut verständlicher Einführungen in aktuelle Technologien. Dieses Buch will einen Überblick über Cloud Computing Architektur, Dienste und Anwendungen vermitteln, ohne Anspruch auf Vollständigkeit zu erheben. Ziel ist es, die Leserinnen und Leser auf einen einheitlichen Stand zu bringen und so eine gemeinsame Diskussionsgrundlage zu erreichen. Technische Vorkenntnisse sind dabei nicht erforderlich.

1.1 Beschreibung der Thematik Der Begriff Cloud Computing ist zurzeit in der Informationstechnik (IT) allgegenwärtig. Was verbirgt sich dahinter? Es gibt viele Interpretationen, aber keine standardisierte oder gar einheitliche Definition. Cloud Computing erlaubt die Bereitstellung und Nutzung von IT-Infrastruktur, von Plattformen und von Anwendungen aller Art als im Web elektronisch verfügbare Dienste. Der Begriff Cloud soll dabei andeuten, dass die Dienste von C. Baun et al., Cloud Computing, 2. Aufl., Informatik im Fokus, DOI 10.1007/978-3-642-18436-9_1, c Springer-Verlag Berlin Heidelberg 2011 

1

2

1 Einleitung

einem Anbieter im Internet (bzw. im Intranet eines größeren Unternehmens) erbracht werden. Die Nutzer der Cloud-Dienste können ihre eigenen Angebote wiederum selbst als Dienste im Internet bzw. Intranet anbieten. Cloud-Ressourcen sind in der Regel virtualisiert: Der CloudNutzer hat dadurch stets eine wunschgemäße, beliebige Sicht auf seine Infrastruktur und es gibt in diesem Fall keine systembedingten Abhängigkeiten oder Zwangsbedingungen für seine Anwendungen. Cloud-Dienste sind darüber hinaus dynamisch skalierbar: Wenn eine Anwendung zusätzliche Ressourcen benötigt, können diese sofort und ohne großen Aufwand automatisch dazu geschaltet werden. Entwickler mit innovativen Ideen für neue Internet-Anwendungen müssen so beispielsweise nicht länger vorab in Hardware investieren, um ein Unternehmen zu gründen. Sie können Ressourcen flexibel von einem Anbieter beziehen und sich auf die Umsetzung ihrer Geschäftsidee konzentrieren. Wenn die Nachfrage steigt, lässt sich die Infrastruktur weitgehend automatisch an die wachsenden Anforderungen anpassen. Cloud Computing folgt den Ideen des Utility Computing. Es wird immer die aktuell benötigte Menge an Ressourcen zur Verfügung gestellt und bezahlt. Wenn nichts genutzt wird, kostet es auch nichts. Cloud Computing hat somit eine wirtschaftliche Bedeutung, da signifikante Kostenersparnisse aufgrund der flexiblen Bereitstellung und Nutzung von Diensten möglich sind. Die vorgehaltenen abrufbaren Kapazitäten sind dabei sehr umfangreich, wodurch ein großer Skaleneffekt (Economy of Scale) mit einem sehr günstigen Preis/Leistungsverhältnis entsteht. Es gibt mittlerweile zahlreiche kommerzielle Anbieter wie z. B. Amazon, Google oder Microsoft. Deren Angebote unterscheiden sich jedoch in ihrer Art: Amazon bietet virtualisierte Ressourcen zur generischen Nutzung an, während die Clouds von Google und Microsoft das Hosting von Anwendungen erlauben. Alle aktuellen Angebote sind aber zugunsten eines Wett-

1.1 Beschreibung der Thematik

3

bewerbsvorteils proprietär und Standards existieren nicht, womit ein schneller Wechsel des Anbieters in der Regel nicht einfach möglich ist. Kritiker des Cloud Computing führen diese Gefahr des Vendor-Lockin neben möglichen Sicherheitsbedenken gerne ins Feld. Vor allem aus dem Kreis der etablierten IT-Manager und Abteilungsleiter wird zur Vorsicht gemahnt. Bei näherer Betrachtung scheint es hier aber in erster Linie sehr oft um die Sicherung historischer Besitzstände in den klassischen Rechenzentren zu gehen. Es sind daher zurzeit vor allem junge Unternehmen (Startups) ohne Abhängigkeiten dieser Art, die aus der neuen Technik Gewinn erzielen. Aber auch in etablierten Unternehmen, die sich dem Thema Cloud Computing stellen, bewirkt dessen Einsatz bereits nachhaltige Effizienzsteigerungen. Neben der Nutzung von Public Clouds etablieren sich hier unternehmensinterne Private Clouds. Aus der Sicht des Kunden ergibt sich eine Reihe von Möglichkeiten, produktiver und flexibler zu arbeiten: Durch die Wahrnehmung von Angeboten im Markt ist es dem Bezieher von IT-Diensten möglich, sich gegenüber dem klassischen statischen Rechenzentrumsbetrieb zu emanzipieren. Cloud Computing entwickelt dabei eine Kraft der schöpferischen Zerstörung und Altes wird durch Neues ersetzt [25, 8]. Das Corporate Executive Board (CEB) in Washington hat eine Studie vorgestellt, die auf einer Befragung von 200 Businessund IT-Führungskräften basiert [62]. Darin wird prognostiziert, dass in den nächsten Jahren die klassischen IT-Abteilungen große Teile ihrer Verantwortung an das Business-Management verlieren werden und als Folge dessen auf ein Viertel ihrer Personalstärke schrumpfen. Zentrale Treiber der Veränderung sind das Cloud Computing, Soziale Medien und die Zunahme der sogenannten Knowledge Worker (Wissens- oder Kopfarbeiter) – gepaart mit einer Unternehmens-IT, die ihre Effizienzpotenziale weitgehend ausgeschöpft hat. Mit dem Siegeszug immer stärker

4

1 Einleitung

spezialisierter Cloud-Dienste wird das Business-Management zunehmend in die Lage versetzt, ohne Beteiligung der internen IT-Abteilung und an ihr vorbei selbst IT-Lösungen einzukaufen. In gleicher Weise können sich die Knowledge Worker mit ihren smarten Endgeräten und sozialen Netzen Informationen zu IT-Systemen sowie die zugehörigen Services selbst besorgen. Damit ändert sich auch die Rolle des Leiters der ITAbteilung: Er wird entweder zum Leiter einer internen schlanken Querschnittsabteilung oder zum Einkäufer und Manager von externen Diensten. Das klassische Rechenzentrum wandelt sich in diesem Szenario zum IT-Servicezentrum.

1.2 Definition Obwohl es keine standardisierte, einheitliche Definition für Cloud Computing gibt, sind die grundlegenden Konzepte als auch die generellen Ziele des Cloud Computing unbestritten: Cloud Computing nutzt Virtualisierung und das moderne Web, um Ressourcen verschiedenster Art als elektronisch verfügbare Dienste dynamisch bereitzustellen. Die Dienste sollen dabei von mehreren Konsumenten verlässlich und skalierbar nutzbar sein, d. h. sowohl auf Abruf als auch nach Bedarf verfügbar sein. Aus der Sicht des Cloud-Anbieters impliziert dies in der Regel eine Multi-Mandanten Architektur und ein nutzungsabhängiges Abrechnungsmodell. Wir definieren Cloud Computing demnach wie folgt: Unter Ausnutzung virtualisierter Rechen- und Speicherressourcen und moderner Web-Technologien stellt Cloud Computing skalierbare, netzwerk-zentrierte, abstrahierte IT-Infrastrukturen, Plattformen und Anwendungen als on-demand Dienste zur Verfügung. Die Abrechnung dieser Dienste erfolgt nutzungsabhängig.

1.2 Definition

5

Diese Definition legt dabei nicht fest, ob die Dienste auf Basis eines verteilten Systems oder eines einzelnen leistungsstarken Servers, z. B. eines Mainframes, erbracht werden. Dies steht im Gegensatz zum Grid Computing, wo das System immer verteilt ist. In der Regel liegt auch Cloud-Diensten eine verteilte Infrastruktur zu Grunde, dessen Management jedoch ist typischerweise zentral (und proprietär) durch einen Anbieter bestimmt. Auch dies unterscheidet das Cloud Computing vom Grid Computing, wo verteilte Knoten in der Regel autonom sind. Eine ausführliche Diskussion findet sich in [30]. Entscheidend für das Cloud Computing ist zudem dessen wirtschaftliche Bedeutung. Eine konsequente Dienste-Orientierung sowie die Nutzung von Web-Standards und des Internet als integrierte Technologie- und Geschäftsplattform positionieren das Cloud Computing für Anwendungen verschiedenster Art. Dies beinhaltet insbesondere Web-Anwendungen und modulare Dienste in verteilten Geschäftsnetzwerken und Prozessketten. Eine viel zitierte Definition von Cloud Computing wurde vom Nationalen Institut für Standards und Technologie (NIST) in den USA erstellt [105]. Diese bestimmt fünf wesentliche Eigenschaften des Cloud Computing, drei verschiedene Klassen von Diensten und vier unterschiedliche Betriebsmodelle. Als wesentliche Eigenschaften werden benannt: • Diensterbringung auf Anforderung: Dienste sind auf Anforderung und selbständig von Konsumenten ohne erforderliche menschliche Interaktion mit dem Anbieter nutzbar. • Netzwerkbasierter Zugang: Dienste können netzwerkbasiert in Echtheit durch Verwendung von Standardtechnologien abgerufen werden. • Ressourcen Pooling: Ressourcen sind in Pools konsolidiert und erlauben eine parallele Diensterbringung für mehrere Nutzer (Mandanten), die dem tatsächlichen Bedarf eines jeden Nutzers angepasst ist.

6

1 Einleitung

• Elastizität: Ressourcen werden schnell und in verschiedenen, auch fein granularen Quantitäten, zur Verfügung gestellt und erlauben so die Skalierung von Systemen. Dem Nutzer gegenüber entsteht die Illusion unendlich verfügbarer Ressourcen. • Messbare Dienstqualität: Dienste sind quantitativ und qualitativ messbar, so dass eine nutzungsabhängige Abrechnung und Validierung der Dienstqualität gegeben ist. Die Klassen der Dienste und die Betriebsmodelle diskutieren wir in Kapitel 3.

1.3 Gliederung Dieses Buch beschäftigt sich zunächst mit den Grundlagen des Cloud Computing, mit Basistechnologien wie Virtualisierung und Web Services. Es schließt sich eine Diskussion der CloudArchitektur mit ihren Service-Bausteinen an. In den darauf folgenden Kapiteln geht es um ausgewählte Cloud-Angebote und Management-Werkzeuge. Insbesondere kommen hier auch Fra-

Abb. 1.1 Wegweiser zum Lesen des Buchs

1.3 Gliederung

7

gen nach Sicherheit und Datenschutz zur Sprache. Es folgt eine Betrachtung aktueller Open Source Entwicklungen wie z. B. Hadoop und Eucalyptus. Das OpenCirrusTM -Projekt von HP, Intel und Yahoo!, bei dem die Autoren als Entwicklungspartner beteiligt sind, greift diese Themen auf. Das Projekt untersucht Grundlagen der Cloud-Systeme und Cloud-Anwendungen. Es schließen sich wirtschaftliche Betrachtungen wie z. B. Kostenund Geschäftsmodelle an. Den Abschluss bildet eine situative Bewertung des Cloud-Marktes. Im Anhang sind einige praktische Beispiele zum Umgang mit Cloud-Ressourcen bzw. CloudAnwendungen aufgeführt und ein Glossar fasst die Definitionen der zentralen Begriffe zusammen. Der geneigte Leser wird das Buch mit Genuss vom Anfang bis zum Ende lesen. Die Kapitel sind aber so geschrieben, dass sie ohne Weiteres auch einzeln gelesen und verstanden werden können. Ein weniger technisch interessierter Leser kann das Kapitel 2 überspringen und sich in medias res begeben. Falls die Zeit knapp bemessen ist, gibt es einen Pfad, der sich eher an technischen Architekturfragen orientiert (Kapitel 1, 3, 5, 7, 8), und einen Pfad für eher wirtschaftswissenschaftlich interessierte Leser (Kapitel 1, 4, 6–8). Die verschiedenen Wege sind schematisch in Abbildung 1.1 aufgezeigt.

Kapitel 2

Grundlagen

Cloud Computing ist auch deshalb attraktiv, weil es die Komplexität der Informationstechnologie vor Nutzern und Entwicklern verbirgt. Man muss nicht im Einzelnen wissen, wie ein Dienst generiert wird und es ist die Aufgabe des Dienstleisters, eine entsprechende Abstraktionsschicht bereitzustellen. Dieses Kapitel gibt einen Überblick über Technologien, auf denen Cloud Computing basiert. Dabei handelt es sich um Virtualisierung, Serviceorientierte Architekturen (SOA) und Web Services.

2.1 Virtualisierung Die Virtualisierung von Ressourcen bildet die Grundlage der meisten Cloud-Architekturen. Das Konzept der Virtualisierung erlaubt eine abstrakte, logische Sicht auf physische Ressourcen und umfasst sowohl Server, Datenspeicher, Netzwerke als auch Software. Die zu Grunde liegende Idee ist, physische Ressourcen in Pools zusammenzufassen und gemeinsam zu verwalten. Aus diesen Ressourcen-Pools können dann nach Bedarf einzelC. Baun et al., Cloud Computing, 2. Aufl., Informatik im Fokus, DOI 10.1007/978-3-642-18436-9_2, c Springer-Verlag Berlin Heidelberg 2011 

9

10

2 Grundlagen

ne Anforderungen befriedigt werden. Es ist z. B. möglich, eine bestimmte Plattform für eine spezifische Anwendung dynamisch und passgenau in dem Augenblick zu generieren, wenn sie gebraucht wird. Statt einer realen Maschine kommt dabei eine virtuelle Maschine zum Einsatz.

2.1.1 Vor- und Nachteile der Virtualisierung Für den Betreiber von IT-Diensten bringt der Einsatz von Virtualisierungstechniken eine Reihe von Vorteilen [4]: • Ressourcen-Nutzung: Physische Server sind oft nur schwach ausgelastet, da man genügend Reserven zur Abdeckung von Lastspitzen einplant. Bei virtuellen Maschinen kann eine Lastsituation aus dem Ressourcen-Pool befriedigt werden. Der Kauf zusätzlicher Kapazitäten kann bei wachsenden Anforderungen verzögert oder vermieden werden. • Management: Die Verwaltung der Ressourcen in den Pools kann automatisiert werden. Virtuelle Maschinen können nach Bedarf automatisch erzeugt und konfiguriert werden. • Konsolidierung: Unterschiedliche Anwendungsklassen können auf einer geringeren Anzahl physischer Komponenten zusammengefasst werden. Neben der Server- und Speicherkonsolidierung können auch ganze Systemlandschaften, Daten und Datenbanken, Netzwerke und Desktops einbezogen werden. Konsolidierung führt zur Effizienzsteigerung und damit zur Kostensenkung. • Energieverbrauch: Die Versorgung mit Energie ist in großen Rechenzentren oft nicht mehr einfach zu realisieren und die Energiekosten zum Betrieb eines Servers übersteigen über die Lebensdauer gesehen inzwischen dessen Beschaffungs-

2.1 Virtualisierung

11

kosten. Die Konsolidierung reduziert die Zahl der physischen Komponenten. Dadurch sinken auch die Aufwendungen für die Energieversorgung. • Platzersparnis: Rechenzentrumsfläche ist knapp und teuer. Die Konsolidierung erbringt dieselbe Leistung auf weniger Stellfläche, und die kostspielige Erweiterung eines bestehenden Rechenzentrums kann u. U. vermieden werden. • Notfallplanung: Virtuelle Maschinen können zwischen verschiedenen Ressourcen-Pools verschoben werden. Man erreicht damit eine bessere Verfügbarkeit von Diensten und die Einhaltung von Dienstgütevereinbarungen (Service Level Agreements) ist einfacher. Hardware-bedingte Wartungsfenster können prinzipiell entfallen. Da die Anbieter von Cloud-Diensten sehr große Ressourcenzentren (IT-Fabriken) bauen, entsteht auf der Basis der Virtualisierung neben dem Größenvorteil zusätzlich eine stark verbesserte Kostensituation. Aus der Sicht des Kunden ergeben sich die folgenden Vorteile: • Dynamik: Anforderungen können passgenau und ohne Wartezeiten befriedigt werden. Im Fall von Engpässen stehen einer virtuellen Maschine zusätzliche Ressourcen zur Verfügung (z. B. Speicher, I/O-Leistung). • Verfügbarkeit: Dienste können hoch verfügbar und unterbrechungsfrei rund um die Uhr genutzt werden. Anwendungen können im Fall von Technologie-Upgrades im laufenden Betrieb migriert werden, da die Verschiebung virtueller Maschinen auf ein aktuelles System problemlos möglich ist. • Zugriff: Die Virtualisierungsschicht bewirkt eine Isolation der virtuellen Maschinen, sowohl voneinander als auch von der physischen Infrastruktur. Dadurch sind die virtuellen Systeme multi-mandantenfähig und es können über ein Rollenkonzept in sicherer Weise Managementfunktionalitäten an den Kunden delegiert werden. Kunden können IT-Leistungen

12

2 Grundlagen

über ein Portal in Selbstbedienung erwerben (Emanzipation des Kunden). Als Nachteil der Virtualisierung ist zu werten, dass der Betrieb der Abstraktionsschicht selbst Ressourcen benötigt. Die aktuellen Virtualisierungstechniken sind allerdings so weit ausgereift, dass sich dieser zusätzliche Aufwand in Grenzen hält: Durch das besonders effektive Zusammenspiel aktueller MulticoreSysteme mit Virtualisierungstechnik spielt dieser Leistungsverlust heutzutage nur noch eine untergeordnete Rolle. Im Hinblick auf die möglichen Einsparungen und die qualitativen Vorteile aus Sicht des Kunden lohnt sich daher der Einsatz der Virtualisierung in fast allen Fällen. Eine weitere Problematik ist, dass nach der Konsolidierungsphase zunächst mehr Systeme zu betreiben und zu verwalten sind: Neben den virtuellen Maschinen gibt es zusätzlich noch die physischen Infrastrukturen. Durch die automatische Verwaltung der Ressourcen mit ausgefeilten Management-Werkzeugen fällt die Bilanz hier aber in der Praxis wegen des sehr viel geringeren Personalaufwands sogar positiv aus.

2.1.2 Virtualisierungskonzepte Virtualisierung steht stellvertretend für eine Vielzahl unterschiedlicher Konzepte und Technologien. Diese unterscheiden sich in ihrer Implementierung, Praxisrelevanz und Einsatzhäufigkeit.

2.1 Virtualisierung

13

Abb. 2.1 Konzept der Betriebssystemvirtualisierung (Container)

2.1.2.1 Betriebssystemvirtualisierung Die Verwendung der Betriebssystemvirtualisierung oder Partitionierung (z. B. IBM LPARs) kann in Cloud-Umgebungen helfen, Sicherheits- und Vertraulichkeitsprobleme zu lösen, die ansonsten die Akzeptanz des Cloud-Ansatzes behindern würden. Bei dieser Form der Virtualisierung, die man auch als Container oder Jails bezeichnet, spielt das Host-Betriebssystem eine entscheidende Rolle. Hier laufen unter einem Betriebssystemkern mehrere voneinander abgeschottete, identische (siehe Abbildung 2.1) Systemumgebungen bzw. Laufzeitumgebungen. Nach außen treten die virtuellen Umgebungen wie eigenständige Systeme auf. Alle laufenden Anwendungen verwenden denselben Betriebssystemkern, sehen aber nur Prozesse, mit denen sie sich gemeinsam in einer virtuellen Umgebung befinden. Speziell Anbieter von Internet-Diensten, sogenannte Internet Service Provider, die (virtuelle) Root-Server anbieten, nut-

14

2 Grundlagen

zen gerne diese Art der Virtualisierung, da sie einen geringen Leistungsverlust und einen hohen Grad an Sicherheit bietet. Der Nachteil der Betriebssystemvirtualisierung ist die geringe Flexibilität, da ausschließlich mehrere unabhängige Instanzen desselben Betriebssystems und nicht verschiedene Betriebssysteme gleichzeitig eingesetzt werden können. Bekannte Vertreter der Betriebssystem-Virtualisierung sind die Containertechnologie von Sun Solaris, OpenVZ für Linux, Linux-VServer, FreeBSD Jails und Virtuozzo.

2.1.2.2 Plattformvirtualisierung Die Plattformvirtualisierung erlaubt die Ausführung beliebiger Betriebssysteme und Anwendungen in virtuellen Umgebungen. Es gibt zwei Modelle: Vollständige Virtualisierung und ParaVirtualisierung. Die Realisierung beider Lösungen geschieht auf der Basis eines Virtuellen Maschinen Monitors oder Hy-

Abb. 2.2 Typ-1 Hypervisor (Virtueller Maschinen Monitor)

2.1 Virtualisierung

15

pervisors. Der Hypervisor ist ein auf ein Minimum reduziertes Metabetriebssystem, das die Hardwareressourcen unter den Gastsystemen verteilt und die Zugriffe koordiniert. Ein Typ-1 Hypervisor setzt dabei direkt auf der Hardware auf, ein Typ-2 Hypervisor läuft auf einem herkömmlichen Basisbetriebssystem (Abbildung 2.2). Die vollständige Virtualisierung basiert auf der Simulation eines kompletten virtuellen Rechners mit virtuellen Ressourcen wie CPU, Hauptspeicher, Laufwerken, Netzwerkkarten, usw. inklusive eigenem BIOS. Da der Zugriff auf die wichtigsten Ressourcen wie Prozessor und Hauptspeicher durchgereicht wird, entspricht die Verarbeitungsgeschwindigkeit der Gast-Betriebssysteme fast der Geschwindigkeit, die ohne Virtualisierung zu erwarten wäre. Andere Komponenten wie Laufwerke und Netzwerkkarten werden emuliert. Dies führt zwar zu Leistungseinbußen, ermöglicht aber die Ausführung unveränderter Gast-Betriebssysteme. Bei der Para-Virtualisierung steht den Gastbetriebssystemen keine emulierte Hardwareebene zur Verfügung, sondern lediglich eine Anwendungsschnittstelle. Dies erfordert die Modifikation der Gast-Betriebssysteme, da alle direkten Hardwarezugriffe durch den entsprechenden Aufruf der Schnittstelle zum Hypervisor zu ersetzen sind. Man spricht auch von Hypercalls in Anlehnung an die Systemaufrufe (Systemcalls), mit denen Anwendungen Funktionen im Betriebssystemkern aufrufen können. Da bei diesem Ansatz das Gastsystem gewissermaßen aktiv an der Virtualisierung mitarbeitet, erreicht man speziell bei I/O-intensiven Anwendungen tendenziell höhere Durchsatzraten als bei der vollständigen Virtualisierung. Beispiele für die vollständige Virtualisierung sind Produkte von VMware [135] oder speziell für Linux die Kernel-based Virtual Machine (KVM). Bei der Para-Virtualisierung kommen unter Linux meist Xenbasierte Lösungen zum Einsatz [14], die insbesondere bei der Realisierung der Amazon Web Services eine Rolle spielen [50].

16

2 Grundlagen

2.1.2.3 Speichervirtualisierung Cloud-Systeme sollten auch den Speicher dynamisch skalierbar als Dienst anbieten. Die Speichervirtualisierung führt in diesem Bereich zu einer Reihe von Vorteilen. Bei der Speichervirtualisierung ist die grundlegende Idee, den Datenspeicher von den klassischen File-Servern zu trennen und die physischen Speicher in Pools zusammenzufassen. Aus diesen Pools bedienen Anwendungen dynamisch ihre Speicheranforderungen. Die Datentransfers laufen dabei über ein spezielles Speichernetzwerk (SAN) oder ein Firmennetzwerk (LAN). Bei Cloud-Angeboten stehen die Daten meist in Form von Web-Objekten zur Verfügung, die über das Internet abgerufen bzw. manipuliert werden können. Man schiebt zusätzlich eine abstrakte Verwaltungsschicht zwischen die Klienten und die Speicherlandschaft, um die Darstellung eines Datums von der physischen Speicherung zu entkoppeln. Es entstehen somit vielfältige Vorteile im Bezug auf das Daten-Management und die Skalierbarkeit des Zugriffs. Das zentrale Management führt auch zu einem günstigeren Betrieb der verteilten Speicher. Darüber hinaus ist es möglich, Datenspeicher verschiedener Kategorien in Speicherhierarchien zu organisieren (TierKonzept). Dadurch kann man ein automatisiertes LifecycleManagement für Datensätze realisieren, vom Tier-0 mit den höchsten Anforderungen im Hinblick auf Verfügbarkeit und Bandbreite, hin zu tieferen und preiswerteren Tier-Stufen mit entsprechend geringerer Dienstgüte. Die Daten können hierbei zwischen den Stufen ohne Beeinträchtigung des Dienstes migriert werden. Auch die Sicherung großer Datenmengen ist durch Snapshots ohne spezielles Backup-Fenster möglich. Ein weiterer Vorteil der Speichervirtualisierung ist die automatische Anlage und Verwaltung von verteilten Spiegeln zur Vermeidung von Dienstunterbrechungen bei Störungen. So legt z. B. Amazon

2.1 Virtualisierung

17

bei der Speicherung von Daten bis zu 3 Kopien in verschiedenen Rechenzentren an.

2.1.2.4 Netzwerkvirtualisierung Techniken wie Lastausgleich (engl. Load-Balancing) sind essenziell in Cloud-Umgebungen, da die angebotenen Dienste dynamisch skalierbar sein müssen. Die Ressourcen werden üblicherweise als Web-Objekte implementiert, und es empfiehlt sich in diesem Bereich daher der Einsatz der bei Web-Servern üblichen Verfahren: Dienste stehen über virtuelle IP-Adressen zur Verfügung, die über Cluster-Techniken sowohl Lastausgleich als auch eine automatische Ausfallbehandlung (engl. Failover) im Falle eines Fehlers realisieren. Durch die Weiterleitung von DNS-Requests ist darüber hinaus die Einblendung von CloudRessourcen im eigenen Internet-Namensraum des Kunden möglich. Ein weiterer Einsatzbereich der Netzwerkvirtualisierung ist die Verwendung virtueller lokaler Netze (VLAN) und virtueller Switches. Cloud-Ressourcen erscheinen in diesem Fall direkt im Netzwerk des Kunden. Interne Ressourcen können somit transparent durch externe Ressourcen ersetzt werden. Vorteile der VLAN-Technik sind: • Transparenz: Verteilt aufgestellte Geräte können in einem einzigen logischen Netz zusammengefasst werden. VLANs sind sehr nützlich bei der Konzeption der IT-Infrastruktur verteilter Standorte. • Sicherheit: Bestimmte, besonders zu schützende Systeme können in einem eigenen virtuellen Netz verborgen werden. Auf der anderen Seite entsteht durch VLANs ein erhöhter Aufwand bei der Netzwerkadministration und bei der Programmierung der aktiven Netzkomponenten (Switches u. ä.).

18

2 Grundlagen

2.1.2.5 Anwendungsvirtualisierung Bei der Anwendungsvirtualisierung handelt es sich um ein Software-Vertriebsmodell, bei dem Anwendungen zentral verwaltet und dem Kunden über ein Netzwerk angeboten werden. Die Vorteile der Anwendungsvirtualisierung im Vergleich zur traditionellen Software-Installation sind: • Einfachere Verwaltung • Automatisches Update- und Patch-Management • Kompatibilität: Alle Nutzer verwenden ein identisches Portfolio • Globale Verfügbarkeit Es gibt zwei unterschiedliche Verfahren zur Bereitstellung virtueller Anwendungen: • Hosted Application: Die Anwendung steht im Internet bereit und wird z. B. über ein Streaming-Protokoll zum Klienten transportiert. • Virtual Appliance: Die Anwendung kann heruntergeladen und auf dem eigenen Rechner betrieben werden. In diesem Fall stehen in einer virtuellen Umgebung alle zur Anwendung gehörenden Dateien und Komponenten bereit, die das Programm zur Ausführung benötigt. Die virtuelle Umgebung wirkt dabei wie ein Puffer zwischen Anwendung und Betriebssystem, wodurch Konflikte mit anderen Anwendungen oder Betriebssystemkomponenten vermieden werden. In CloudUmgebungen bildet die Anwendungsvirtualisierung eine wichtige Grundlage für das SaaS-Konzept (Software as a Service, s. u.) zur dynamischen Bereitstellung von Software-Komponenten.

2.2 Service-orientierte Architekturen

19

2.2 Service-orientierte Architekturen Neben der Virtualisierung sind Service-orientierte Architekturen und Web Services als fundamentale Voraussetzungen für das Cloud Computing zu verstehen. Service-orientierte Architekturen (SOA) sind Architekturen, deren Komponenten voneinander unabhängige Dienste (Services) sind. Diese können flexibel gebunden und orchestriert werden und sie können lose gekoppelt über Nachrichten kommunizieren. Das Cloud Computing realisiert virtualisierte IT-Infrastrukturen, Plattformen, und ganze Anwendungen als Dienste. Diese stehen zur Nutzung in Serviceorientierten Architekturen zur Verfügung. Im Fall von öffentlichen Clouds (Public Clouds, siehe Kapitel 3) werden die Dienste über das Internet auf Basis standardisierter Web-Protokolle und Schnittstellen angeboten. Hier hat sich der Einsatz von Web Services und RESTful Services bewährt. Die Nutzung von Web Services als Technologie ist dabei nicht zwingend für eine SOA.

2.2.1 Eigenschaften von SOA Bei SOA handelt es sich um einen Architekturstil, welcher das Anbieten und Nutzen von Diensten definiert. Die Dienste können nicht nur von Kunden, sondern wiederum auch von anderen Diensten und Anwendungen genutzt werden. Oft werden dabei die Dienste als Geschäftsprozesse orchestriert, d. h. ein Kunde legt die Aufrufe und den Datenaustausch mit verschiedenen Diensten in einer bestimmten Reihenfolge fest. Der Prozess kann dabei selbst wiederum als Dienst bereitgestellt werden. SOA verspricht somit, IT-Architekturen auf die Abstraktionsebene von Geschäftsprozessen zu heben bzw. einen einheitlichen

20

2 Grundlagen

Ansatz für die Beschreibung und Realisierung von Geschäftsprozessen durch IT-Dienste zu ermöglichen. Typische Eigenschaften einer SOA sind: • Sie besteht aus verteilten Komponenten, den Diensten. • Heterogene Dienstnutzer und Dienstanbieter sind plattformunabhängig miteinander interoperabel; unterschiedliche Programmiersprachen und Plattformen zur Implementierung einzelner Dienste sind möglich. • Dienste sind lose gekoppelt und werden dynamisch zur Laufzeit gebunden. Eine SOA erlaubt so dynamische Anpassungen, die lokale (aber nicht systemweite) Auswirkungen haben. Eine kurze und griffige Definition von Service-orientierten Architekturen wird in [13] gegeben: Unter einer SOA versteht man eine Systemarchitektur, die vielfältige, verschiedene und eventuell inkompatible Methoden oder Anwendungen als wieder verwendbare und offen zugreifbare Dienste

Dienstverzeichnis

Verweis auf Dienst

Dienst suchen und finden

Dienst veröffentlichen

Dienst binden

Dienst nutzen

Dienstnutzer Abb. 2.3 Beteiligte und Aktionen in einer SOA

Dienstanbieter

2.2 Service-orientierte Architekturen

21

repräsentiert und dadurch eine plattform- und sprachenunabhängige Nutzung und Wiederverwendung ermöglicht.

Abbildung 2.3 illustriert das grundlegende, theoretische Zusammenspiel von Dienstanbieter, Dienstnutzer, und Dienstverzeichnis für das dynamische Binden von Diensten zur Laufzeit. Ein Dienstnutzer kann einen passenden Dienst in einem Dienstverzeichnis suchen bzw. über einen Dienstvermittler (broker) erfahren. Wird ein passender Dienst gefunden bzw. vermittelt, erhält der Dienstnutzer eine Referenz (Adresse, Endpunkt), mit der er auf den Dienst zugreifen kann, d. h. Nachrichten austauschen kann. Abschließend kann der Dienst aufgerufen, also eine Nachricht geschickt werden. Der Dienstanbieter sendet eine Nachricht als Antwort zurück. In der Praxis wird oft auf das Dienstverzeichnis verzichtet, und Endpunkte werden direkt als Bestandteil von Nachrichten kommuniziert. Standards für Dienstverzeichnisse wie Universal Description, Discovery and Integration (UDDI) konnten sich nicht durchsetzen. Endpunkte direkt über Nachrichten zu verschicken, erlaubt eine sehr dynamische, zielorientierte Vermittlung und Bindung von Diensten zur Laufzeit.

2.2.2 Implementierung einer SOA Die Möglichkeiten, eine SOA zu implementieren sind vielfältig und basieren primär auf den Entscheidungen hinsichtlich der Kommunikation und Integration (Kopplung) zwischen Dienstanbieter und Dienstnutzer. Gängige Ansätze sind vor allem Web Services auf Basis von Web Service Description Language (WSDL) und Simple Object Access Protocol (SOAP), sowie RESTful Services. Die Integration der Dienste in einer SOA kann über Punktzu-Punkt-Verbindungen oder den Hub-and-Spoke-Ansatz erfol-

22

2 Grundlagen

gen. Die Punkt-zu-Punkt-Verbindung behandelt eine Verbindung zwischen Dienstanbieter und Dienstnutzer individuell. Hierfür muss der Dienstnutzer den Endpunkt des gewünschten Dienstes (IP-Adresse, URL) genau kennen. Die Dienstanfrage geht dann direkt an den betreffenden Dienstanbieter. Beim Hub-and-Spoke-Ansatz agiert ein Vermittler zwischen Dienstanbietern und Dienstnehmern. Der Dienstnutzer kennt hier die exakte Adresse des Dienstanbieters nicht. Für jeden Dienst existiert ein symbolischer Name. Bei diesem kann es sich z. B. um einen URI handeln. Der Vermittler trägt im SOAUmfeld den Namen Enterprise Service Bus (ESB). Seine Aufgabe beinhaltet das Routing, also die gesteuerte, zuverlässige Weiterleitung von Nachrichten zwischen den Diensten über verschiedene Systeme und unabhängig von den verwendeten Protokollen hinweg. Eine weitere Aufgabe ist die Transformation von Daten von einem Format in ein anderes Format. Dabei kann es sich im einfachsten Fall um die Anpassung von unterschiedlichen Datentypen zwischen 32-Bit und 64-Bit-Plattformen, aber auch um die Konvertierung zwischen unterschiedlichen XMLStandards handeln. Weitere Aufgaben sind die Verwaltung eines Dienstverzeichnisses und abhängig von der Implementierung die Orchestrierung der Nachrichten. In Abbildung 2.4 sind Punkt-zu-Punkt-Verbindungen dem Hub-and-Spoke-Ansatz mit ESB gegenübergestellt.

2.3 Web Services Im Gegensatz zu verteilten Systemen, die über lokale Netzwerke miteinander verbunden sind, integrieren verteilte Systeme beim Cloud Computing heterogene Ressourcen, die sich theoretisch an allen Punkten der Erde mit Internetanschluss befinden können. Verbindungen über das Internet führen im Gegensatz zu

2.3 Web Services

23

lokalen Netzwerken automatisch zu Problemen wie hohen Antwortzeiten, geringen Datenübertragungskapazitäten und potentiell unzuverlässigen Verbindungen. In solchen Umgebungen ist eine schwach gekoppelte, asynchrone und nachrichtenbasierte Kommunikation über Web Services empfehlenswert. Genau wie bei Service-orientierten Architekturen existiert für Web Services eine Vielzahl unterschiedlicher Definitionen. Die Web Services Architecture Working Group des W3C definiert Web Services wie folgt [137]: Ein Web Service ist eine durch einen URI eindeutige identifizierte Softwareanwendung, deren Schnittstellen als XML-Artefakte definiert, beschrieben und gefunden werden können. Ein Web Service unterstützt die direkte Interaktion mit anderen Softwareagenten durch XML-basierte Nachrichten, die über Internetprotokolle ausgetauscht werden.

Wohlstadter u. Tai [32] definieren Web Services als eine verteilte Middleware, die eine Maschine-zu-Maschine Kommunikation auf Basis von Web Protokollen ermöglicht. Web Services definieren sich dabei weniger über die genutzte Technologie, sondern vielmehr über deren intendierte Nutzung. Web Services propagieren einen kompositionellen Ansatz für die Anwendungsentwicklung. Funktionen können durch externe, verteilte Anwendung A

Anwendung B

Anwendung C

Anwendung A

Anwendung B

Anwendung C

Enterprise Service Bus (Routing, Transformation, Orchestrierung)

Anwendung D

Anwendung E

Anwendung F

Anwendung D

Anwendung E

Anwendung F

Abb. 2.4 Punkt-zu-Punkt-Verbindungen und Enterprise Service Bus

24

2 Grundlagen

Dienste in eine Anwendung eingebunden werden; auch können Legacy Systeme durch Web Services angesprochen werden.

2.3.1 Interoperabilität Web Services beschreiben Standards für die Formatierung von Nachrichten, für Dienste-Schnittstellen, und für die Bearbeitung von Nachrichten. Zwei populäre Ansätze sind SOAP/WSDLbasierte Web Services und RESTful (REpresentational State Transfer) Services. SOAP ist ein Messaging-Protokoll und WSDL (Web Services Description Language) eine Schnittstellenbeschreibungssprache. SOAP/WSDL-basierte Services haben demnach programmatische Schnittstellen. REST dagegen beschreibt einen Architekturstil, der auf HTTP aufbaut. RESTful Services werden lediglich über die uniforme HTTP-Schnittstelle angesprochen. Beide Ansätze identifizieren Dienste anhand von Uniform Resource Identifiers (URI). Web Services in ihrer Grundform beschreiben nur die Primitive, um Dokumente (Daten) zwischen Dienstnutzern und Dienstanbietern auszutauschen. Standards für transaktionale, verlässliche, sichere Dienste existieren für SOAP/WSDL. Die Web Services Platform Architecture (WS-*) beschreibt eine Menge modular komponierbarer Erweiterungen, die jeweils eine gewünschte Quality-of-Service Eigenschaft adressieren. Das gängigste Datenaustauschformat ist XML. Die Nutzung von XML ist bei SOAP/WSDL auch vorgeschrieben, und üblich bei RESTful Services. Die Konvertierung von XML Datenstrukturen in programmiersprachenspezifische Datenstrukturen erfolgt dabei durch standardisierte Mappings. Ein alternatives Datenaustauschformat ist JSON (JavaScript Object Notation), das insbesondere bei der Konsumierung von RESTful Services direkt im Web Browser durch JavaScript populär ist.

2.3 Web Services

25

Die Schnittstelle eines Web Services wird im Fall von SOAP/WSDL durch WSDL beschrieben. WSDL ist eine Erweiterung der XML Schema Spezifikation und beschreibt Web Services einerseits abstrakt anhand von Typen, Nachrichten, Operationen und Schnittstellen (port types), und andererseits durch protokollspezifische und konkrete, verfügbare Adressen (endpoints). Im Fall von REST werden die generischen HTTPMethoden (d. h. GET, PUT, POST, DELETE, etc.) anstelle spezifischer Operationen genutzt. REST baut somit direkt auf den Prinzipien des WWW auf und nutzt damit auch dessen Vorteile wie eine einfache Fehlerbehandlung durch standardisierte HTTP-Fehlercodes.

2.3.2 SOAP versus REST SOAP ist ein Messaging-Standard, der ein XML-basiertes Nachrichtenformat definiert, Bearbeitungsregeln für Nachrichten definiert, Konventionen beschreibt, und Abbildungen auf unterschiedliche Internet-Transportprotokolle (inklusive HTTP) erlaubt. SOAP-Nachrichten sind immer XML-Dokumente, die aus drei Teilen bestehen. In einem virtuellen Umschlag, dem SOAP Envelope, befinden sich zwei Elemente. Der optionale SOAP Header, in dem u. a. Informationen zum Routing und Sicherheitsinformationen (Authentifizierung und Autorisierung) enthalten sein können und der zwingend notwendige SOAP Body. Im Body-Element ist die eigentliche Nachricht untergebracht. Diese kann Informationen zum Datenaustausch, oder Anweisungen für einen entfernten Prozeduraufruf enthalten. SOAP baut auf dem Chain-of-Responsibility Pattern auf; eine Reihenfolge verteilter Schritte zur Abarbeitung einer SOAPMessage kann definiert werden. Somit ergeben sich auch in-

26

2 Grundlagen

teressante Optionen für Web Service Intermediaries bzw. zur Einbindung spezialisierter Middeware-Funktionen zur Unterstützung verschiedener Quality-of-Services der Web Services Platform Architecture. REST hingegen nutzt die Semantik von HTTP und schreibt somit eine zustandslose Kommunikation vor (d. h. der Server hält keine Zustandsinformation über den Client). Dadurch sind bei REST Punkt-zu-Punkt-Verbindungen gegeben, bei denen alle notwendigen Informationen in den Nachrichten selbst enkodiert werden. Dies vereinfacht beispielsweise die Interpositionierung von Caches oder die Replikation von Servern.

Kapitel 3

Cloud-Architektur

Die Betrachtung von Cloud-Architekturen kann aus zwei verschiedenen Perspektiven erfolgen – aus organisatorischer oder aus technischer Sicht. Die organisatorische Sicht, die im folgenden Abschnitt 3.1 dargestellt ist, unterscheidet nach einer Trennung der organisatorischen Einheiten von Benutzern und Anbietern, während sich die technische Sicht in Abschnitt 3.2 an funktionalen Eigenschaften orientiert. Damit entspricht die organisatorische Sicht dem Betriebsmodell und die technische Sicht den Klassen der Dienste aus der Definition des NIST [105], die in Abschnitt 1.2 vorgestellt wurde.

3.1 Public, Private und Hybrid Clouds Als Public Cloud (oder auch External Cloud) bezeichnet man alle Cloud-Angebote, bei denen die Anbieter und die potenziellen Benutzer nicht derselben organisatorischen Einheit angehören. Die Anbieter machen ihre Cloud öffentlich zugänglich und bieten meist ein Web-Portal, in dem die Benutzer in SelbstbedieC. Baun et al., Cloud Computing, 2. Aufl., Informatik im Fokus, DOI 10.1007/978-3-642-18436-9_3, c Springer-Verlag Berlin Heidelberg 2011 

27

28

3 Cloud-Architektur

nung die gewünschten Leistungsumfänge spezifizieren können. Dazu bedarf es in der Regel keines übergeordneten Rahmenvertrags, sondern die vertragliche Bindung wird im Rahmen der Leistungsspezifikation eingegangen. Die Abrechnung der Dienste erfolgt auf Basis der tatsächlich über die Zeit benutzten Ressourcen. Im Kontrast dazu steht die so genannte Private Cloud (oder auch Internal Cloud bzw. IntraCloud), bei der die Anbieter- und die Benutzerseite derselben organisatorischen Einheit angehören. Als Hauptargument für den Einsatz einer Private Cloud statt einer Public Cloud werden meist Sicherheitsgründe angeführt: In der Private Cloud bleibt die Kontrolle über die Daten beim Benutzer bzw. innerhalb dessen Organisation. So können nicht nur sensible Daten, wie z. B. Konstruktionspläne oder Produktionsdaten vermeintlich besser geschützt werden, sondern auch regulatorische Maßnahmen, z. B. bzgl. personenbezogener Daten im Gesundheitswesen, können eingehalten werden. Die Dienste einer Private Cloud werden zwar auf organisationseigenen Ressourcen betrieben, es wird zum Teil jedoch versucht, die gleichen technischen Schnittstellen wie in der Public

Abb. 3.1 Public Cloud, Private Cloud und Hybrid Cloud

3.2 Technische Landschaft der Cloud-Dienste

29

Cloud zu realisieren. So soll zum einen ermöglicht werden, die in der Public Cloud vorhandenen Werkzeuge auch in der Private Cloud zu benutzen und zum anderen die Option offen gehalten werden, zunächst für die Private Cloud entwickelte Anwendungen später in die Public Cloud skalieren zu können. In Szenarien, in denen Dienste aus der Public und Private Cloud zusammen benutzt werden, spricht man von einer Hybrid Cloud. In der Regel werden hier bestimmte Funktionalitäten oder Lastspitzen in die Public Cloud ausgelagert, während der Regelbetrieb über die privaten Ressourcen erfolgt. Dabei ist nach obiger Sicherheitsüberlegung natürlich abzuwägen, dass nur unkritische Funktionen bzw. Daten ausgelagert werden dürfen. Abbildung 3.1 zeigt, wie sich die drei beschriebenen Typen Public Cloud, Private Cloud und Hybrid Cloud zueinander positionieren.

3.2 Technische Landschaft der Cloud-Dienste Wie in den vorangegangenen Kapiteln beschrieben, ermöglicht Cloud Computing die Bereitstellung und Nutzung von verschiedenartigen IT-Infrastrukturen, Plattformen und Anwendungen als Web-Dienste. Entsprechend vielfältig und auf den ersten Blick heterogen ist die Landschaft der existierenden CloudDienste im Bezug auf deren Funktionalität und Zielsetzung. Auf Basis einer konzeptuellen Architektur wird im Folgenden eine Landkarte des Cloud Computing gezeichnet, die eine Kategorisierung von Cloud-Angeboten und Technologien erlaubt und innerhalb der Kategorien einen Vergleich der jeweiligen Instanzen. Auf diese Weise lassen sich z. B. die alternativen verfügbaren Cloud-Angebote oder komplementäre Techniken für einen bestimmten Anwendungsfall bestimmen und gegeneinander abwägen. Die Darstellung in diesem Abschnitt orientiert sich an [20].

30

3 Cloud-Architektur

Die Architektur beruht auf dem Grundmuster der Schichtung, bei dem die einzelnen Schichten wie gewöhnlich nach ihrem Abstraktionsgrad angeordnet sind. Dabei können die höheren abstrakteren Schichten die Dienste der tieferen konkreteren Schichten zu ihrer eigenen Dienstrealisierung benutzen. Die

Abb. 3.2 Cloud-Architektur Schichtenmodell

3.3 Infrastructure as a Service

31

Schichtung ist nicht streng, d. h. eine höhere Schicht kann die Dienste aller unterliegenden Schichten nutzen und nicht nur die der nächst tieferen Schicht. Die einzelnen Schichten werden über ihre Eigenschaften charakterisiert und zum Teil in weitere Subschichten unterteilt. Cloud-Dienste, die Dienste und Schnittstellen aufweisen, mit denen man sie in mehrere Schichten einordnen könnte, werden der höchsten möglichen Schicht zugeschlagen, weil dies meist die Schicht ist, mit der die potentiellen Benutzer primär adressiert werden. Die Einordnung erhebt keinen Anspruch auf Vollständigkeit, sondern kann in einem derart dynamischen Feld, wie es das Cloud Computing zur Zeit der Entstehung dieses Buches darstellt, immer nur eine Momentaufnahme der bekannten bzw. besonders archetypischen Cloud-Dienste sein. Die drei Hauptschichten, nach denen das resultierende Schichtenmodell in Abbildung 3.2 unterteilt wird, folgen dem everything-as-a-service-Paradigma (XaaS) mit den vier Hauptvertretern Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS) und Humans as a Service (HuaaS), die in den folgenden Abschnitten genauer definiert und illustriert werden.

3.3 Infrastructure as a Service In der IaaS-Schicht wird den Benutzern eine abstrahierte Sicht auf Hardware angeboten, d. h. auf Rechner, Massenspeicher, Netzwerke etc. Hierfür wird ihm in der Resource Set-Unterschicht (RS) eine Benutzerschnittstelle zur Verwaltung einer Menge von Ressourcen bereitgestellt, die ermöglicht, Teile davon für die eigene Verwendung zu allokieren. Typische Funktionalitäten an der Benutzerschnittstelle sind das Anlegen bzw. Beseitigen von Betriebssystem-Abbildern, die Skalierung von be-

32

3 Cloud-Architektur

anspruchten Kapazitäten oder die Definition von Netzwerktopologien. Die Schnittstelle bietet darüber hinaus die erforderlichen Funktionalitäten für den operativen Betrieb, wie z. B. das Starten und Stoppen der Betriebssystem-Instanzen. Die Angebote im Resource Set lassen sich noch weiter unterteilen in die Klasse des Physischen Ressourcen Sets (PRS), deren Vertreter auf einer proprietären physikalischen Hardware basieren und diese anbieten, und in die Klasse Virtuelles Ressourcen Set (VRS), die auf Virtualisierungstechnologien wie XEN [14] aufgebaut sind und damit auch virtuelle Instanzen zur Verfügung stellt. Beispiele für Cloud-Dienste in PRS sind Emulab [16] und iLO [15]. Zu den VRS Cloud Diensten zählen Amazon EC2 [40], Eucalyptus [22], Nimbus [17] und OpenNebula [26]. Auch wenn die VRS Dienste mit ihren vereinfachenden virtuellen Ressourcen weitaus häufiger anzutreffen sind, haben die PRS Dienste ihre Berechtigung, wenn z. B. aus Gründen der Stabilität, Performanz oder durch spezielle Hardware-Anforderungen die Indirektion durch einen Hypervisor vermieden werden soll, aber zugleich auf den Komfort und Funktionsumfang der Verwaltung der Cloud-Dienste nicht verzichtet werden soll. Neben der beschriebenen Resource Set-Unterschicht gehören auch die Infrastrukturdienste zur IaaS-Schicht. Im Unterschied zu den Resource Set-Angeboten haben die Infrastrukturdienste einen engeren Anwendungsfokus. So gibt es z. B. dedizierte Infrastrukturdienste für Berechnungsaufgaben (Hadoop MapReduce [97]), für Massenspeicher (Amazon S3 [46], Zumodrive [143], Dropbox [69]) oder für Netzwerke (OpenFlow [24]). Eine erweiterte und kommentierte Liste von IaaS Cloud-Diensten und Werkzeugen zeigt Tabelle 3.1.

Amazon Amazon Amazon Amazon Amazon Amazon AppNexus Bluelock Bluelock Cloud.com Dropbox Emulab ENKI Reservoir FlexiScale GoGrid GoGrid Google Google HP HP

Elastic Compute Cloud (EC2) Dynamo Simple Storage Service (S3) SimpleDB CloudFront SQS AppNexus Cloud Virtual Cloud Computing Virtual Recovery CloudStack Dropbox Cloud Storage Emulab Network Testbed Virtual Private Data Centers Open Nebula FlexiScale Cloud Computing Cloud Hosting Cloud Storage Google Big Table Google File System iLO Tycoon

Organisation Cloud-Dienst [40] [12] [46] [47] [36] [48] [57] [60] [60] [65] [69] [16] [73] [26] [76] [82] [82] [9] [89] [15] [126]

Referenz Virtuelle Server Speicherung von Schlüssel-Wert-Paaren Massenspeicher Datenbank as a Service (DaaS) Content Distribution Network (CDN) Nachrichten-Warteschlangen Virtuelle Server Virtuelle Server Wiederherstellung virtueller Server bei Störungen Open Source IaaS Massenspeicher Emulation logischer Netzwerke für Experimente Bedarfsgerechte Bereitstellung virtueller Rechenzentren Open Source virtuelle Server-Pools Virtuelle Server Virtuelle Server Massenspeicher Verteilter Speicher für strukturierte Daten Verteiltes Dateisystem Lights out management Markt-basierte Allokation von Cluster-Ressourcen

Beschreibung

Tabelle 3.1 Infrastructure as a Service Angebote und Werkzeuge

3.3 Infrastructure as a Service 33

Cloud-Dienst

Accelerator Connector BingoDisk Nimbus Storage Delivery Network OpenFlow OpenNebula Mosso Cloud Sites Mosso Cloud Storage Mosso Cloud Servers Skytap Virtual Lab Infinistructure flexIT Eucalyptus Zimory Public Cloud Market

Hybrid Cloud Storage Mongo DB

Organisation

Joyent Joyent Joyent University of Chicago Nirvanix Openflow OpenNebula Project Rackspace Rackspace Rackspace Skytap Terremark todo GmbH Eucalyptus Systems Zimory

Zumodrive 10gen

Tabelle 3.1 (Fortsetzung)

[143] [33]

[99] [99] [99] [108] [99] [109] [114] [120] [120] [120] [127] [131] [132] [74] [141]

Virtuelle Server Vorkonfigurierte virtuelle Server Massenspeicher Open Source IaaS Massenspeicher Lokale Netzwerksimulation Open Source IaaS Vorkonfigurierte virtuelle Server Massenspeicher Virtuelle Server Hybride Cloud-Testumgebungen Virtuelle Server Virtuelle Server Open Source Implementierung der AWS Verteilte Markt-basierte Allokation von IaaS-Ressourcen Massenspeicher Database for cloud storage

Referenz Beschreibung

34 3 Cloud-Architektur

3.4 Platform as a Service

35

3.4 Platform as a Service Die Cloud-Dienste in der PaaS-Schicht richten sich meist nicht an Endkunden sondern an Entwickler. Es sind dies Entwicklungsumgebungen – Programming Environments (PE) – und Laufzeitumgebungen – Execution Environments (EE) –, in denen sich eigene Software in einer bestimmten Programmiersprache entwickeln bzw. ausführen lässt. Typische Vertreter der Entwicklungsumgebungen sind das Django Framework [68] oder Sun Caroline [61]. Diese erweitern existierende Programmiersprachen z. B. durch Klassenbibliotheken mit einem bestimmten Anwendungsfokus. Die Ausführung der entstehenden Anwendung erfolgt in Laufzeitumgebungen, die von der jeweiligen Entwicklungsumgebung aus Projektsicht entkoppelt sind. Bekannte Vertreter der Cloud-basierten Laufzeitumgebungen sind Google App Engine [85], Azure von Microsoft [59] oder Reasonably Smart von Joyent [99]. Im Falle von Microsoft Windows Azure lassen sich eine ganze Reihe von Werkzeugen und verschiedene Programmiersprachen auf Basis der AzureUmgebung nutzen. Google App Engine unterstützt die Erstellung und Ausführung von Web-Anwendungen in den Sprachen Python und Java. Wie Dienste der verschiedenen Schichten der Architektur zusammenspielen bzw. aufeinander aufbauen können, zeigt sich exemplarisch am Beispiel der Entwicklungsumgebung AppScale [58], einer Open Source Re-Implementierung der Google App Engine. AppScale realisiert deren Funktionalität auf Basis des oben bereits erwähnten Infrastrukturdienstes Eucalyptus.

EdgePlatform Facebook Platform App Engine Azure

Windows SkyDrive SuiteFlex Force.com Project Caroline Zoho Creator

Akamai Facebook Google Microsoft

Microsoft NetSuite Salesforce Sun Zoho

Organisation Cloud-Dienste

[103] [106] [78] [61] [142]

[35] [75] [85] [59]

Content, Site, Application Delivery Umgebung für Anwendungen im sozialen Netzwerk Facebook Skalierbare Ausführungsumgebung für Web-Anwendungen Entwicklungs- und Ausführungsumgebung für Windows Anwendungen Plattform zum Datenabgleich zwischen heterogenen Endgeräten Werkzeug zur Geschäftsprozessentwicklung in NetSuite Entwicklung und Betrieb von Erweiterungen des Salesforce-CRM Entwicklung und Betrieb von verteilten Web-Anwendungen Entwicklung und Betrieb Datenbank-basierter Web-Anwendungen

Referenz Beschreibung

Tabelle 3.2 Platform as a Service Angebote und Werkzeuge

36 3 Cloud-Architektur

3.5 Software as a Service

37

Die Austauschbarkeit von Teilen des beschriebenen Schichtenmodells, die durch die Nachimplementierung in Open Source-Projekten entsteht, führt nicht nur zu technischen Alternativen, sondern mindert punktuell auch die häufig kritisierte Gefahr einer zu engen Bindung von Benutzern an bestimmte kommerzielle Cloud-Anbieter (sog. Vendor-Lock-In). In Tabelle 3.2 werden weitere PaaS-Angebote und Werkzeuge genannt und beschrieben.

3.5 Software as a Service Software-Anwendungen in der Cloud, die den Endkunden direkt adressieren, gehören zur SaaS-Schicht. Auf der Kundenseite entfällt in dieser Klasse die lokale Software-Installation und mithin auch die Bereitstellung der erforderlichen Ressourcen. Aus Perspektive der beschriebenen Cloud-Architektur kann das SaaSAngebot auf Basis eines Angebots in PaaS oder IaaS beim Anbieter entwickelt und betrieben werden. Innerhalb der SaaS-Angebote lässt sich unterscheiden zwischen Anwendungsdiensten, deren Funktionalität im Wesentlichen auf einer einzigen einfachen Anwendung basiert und vollwertigen komplexen Anwendungen (Applications). Ein Teil der Anwendungsdienste kann vom Endkunden direkt benutzt werden, wie dies z. B. bei Google Maps [90] der Fall ist. Andere Dienste stehen als Komponenten bereit, wie z. B. die Benutzerverwaltung von OpenID [113], oder die Integration sozialer Netzwerke in Anwendungen durch OpenSocial [115]. Die Verknüpfung solcher Anwendungsdienste kann durch gewöhnliche statische Einbindung geschehen oder durch die vergleichsweise leichtgewichtige und flexible Einbindung in sogenannten Mashups [6].

Windows Live Salesforce.com

[103] [125]

[115]

Microsoft Salesforce

OpenSocial

Google

[34] [77] [88] [90]

[113]

Photoshop Express eCloudManager SAP Edition Google Docs Google Maps API

Adobe fluidOps Google Google

Online Bildbearbeitung SAP Landscape as a Service Online Office Anwendungen Dienst zur Integration von Landkarten und geographischen Informationen Übergreifende Programmierschnittstelle zur Integration sozialer Netze in Anwendungen Verteiltes System zur Verwaltung systemübergreifender Benutzeridentitäten Online Office Anwendungen Erweiterbares CRM-System

Referenz Beschreibung

OpenID Foundation OpenID

Cloud-Dienste

Organisation

Tabelle 3.3 Software as a Service Angebote und Werkzeuge

38 3 Cloud-Architektur

3.6 Humans as a Service

39

Von wesentlich höherer Komplexität und größerem Funktionsumfang sind Anwendungen wie z. B. Google Docs [88], Microsoft Windows Live [103] oder das in Salesforce.com [125] zentrale CRM-System. An letzterem zeigt sich auch, wie sich eine vollwertige Anwendung durch weitere Anwendungsdienste noch aufwerten lässt und wie in diesem Fall die SaaS und die PaaS-Schicht zusammenspielen können: Salesforce.com bietet Drittanbietern eine Plattform auf der sie – auch kostenpflichtige – Anwendungsdienste entwickeln und betreiben können, die die Funktionalität des zentralen CRM-Systems erweitern und ergänzen. Weitere Anwendungen und Anwendungsdienste zeigt Tabelle 3.3.

3.6 Humans as a Service Die Schicht Humans as a Service (HuaaS) baut auf dem Cloud Computing Schichtenmodell auf. Dies illustriert, dass das Cloud-Paradigma nicht nur eingeschränkt auf IT-Dienste trägt, sondern auch auf Dienstleistungen der Ressource Mensch erweiterbar ist. Technisch eingebunden ist die menschliche Ressource von Interesse, weil sie bei bestimmten Fähigkeiten den Rechnersystemen überlegen ist. Bestimmte Aufgaben wie beispielsweise Übersetzungsdienste oder Design-Dienste, bei denen die Kreativität eine Rolle spielt, lassen sich damit besser erledigen. Innerhalb der HuaaS-Schicht ist das Crowdsourcing die dominierende Unterkategorie, bei dem eine Gruppe von menschlichen Ressourcen im Internet Aufgaben von unterschiedlicher Komplexität und variierendem Umfang für die Auftraggeber übernimmt. Ein Standardbeispiel für Crowdsourcing kommt erneut aus dem Hause Amazon: Der Amazon Mechanical Turk [44] bietet eine Schnittstelle, über die meist fein granulare

40

3 Cloud-Architektur

Aufgaben auf interessierte menschliche Ressourcen übertragen werden können, die dafür eine gleichermaßen kleine Entlohnung erhalten. Der Amazon Mechanical Turk erfüllt die Funktion eines Marktplatzes für Crowdsourcing-Angebote. Allerdings kann ein HuaaS-Angebot bislang nur dann eingestellt werden, wenn der Auftraggeber über einen Wohnsitz und eine Bankverbindung in den USA verfügt. Personen außerhalb der USA können das Angebot nur als Auftragnehmer nutzen. Typische Crowdsourcing-Aufgaben verlangen wenige oder keinerlei Vorkenntnisse und den Auftraggebern steht damit in der Cloud eine potenziell große Menge von dynamisch skalierbaren Arbeitskräften zur Erledigung ihrer Aufgaben zur Verfügung. Bei anderen Crowdsourcing-Angeboten profitieren z. B. alle Teilnehmer von bereitgestellten Artefakten, deren Qualität sich an den Urteilen der anderen Benutzern ablesen lässt. YouTube [140] ist ein typischer Vertreter für ein solches Angebot. Eine Aggregation von Vermutungen einzelner über die Zukunft betreiben die Prediction Markets, wie z. B. die IOWA Electronic Markets [7]. Basierend auf der Mehrheitsmeinung sagen sie den Ausgang von Wahlen oder auch Sportereignissen vorher. Ein weiteres interessantes Beispiel für Crowdsourcing ist die Untersuchung der britischen Zeitung The Guardian zum britischen Spesenskandal im Sommer 2009. Die Zeitung stellte über 450.000 Dokumente [96] mit Rechnungen online, damit die Leser diese betrachten und deren Relevanz bewerten konnten. Die von vielen Menschen geleistete Arbeit trug maßgeblich dazu bei, den Spesenskandal in kürzester Zeit aufzuarbeiten.

3.7 Weitere Kategorien von Cloud-Diensten

41

3.7 Weitere Kategorien von Cloud-Diensten Neben den etablierten Dienst-Kategorien IaaS, PaaS, SaaS und HuaaS existiert eine Vielzahl von Spezialdiensten, die teilweise darauf aufbauen. Einige Beispiele dafür sind: • High Performance Computing as a Service (HPCaaS). Das Ziel von HPCaaS ist es, Hochleistungsrechenleistung als Dienst verfügbar zu machen. Ein Fokus beim Hochleistungsrechnen ist die Minimierung der Latenzzeiten zwischen den verbunden Ressourcen sowie die Optimierung des Datendurchsatzes. Dazu ist es nötig, Instanzen in einer CloudInfrastruktur physisch nahe beieinander zu platzieren. Diese Rahmenbedingung kann z.B. durch die IaaS-Lösung OpenNebula erfüllt werden. Verschiedene Firmen bieten entsprechende Lösungen an: Amazon Cluster Compute Instances [38], Gridcore Gompute [93], Penguin Computing on Demand [119], Sabalcore HPC on Demand [123], UNIVA UD UniCloud [134]. • Landscape as a Service (LaaS). Komplexe und nicht oder nur eingeschränkt mandantenfähige Software wie SAP R3 wird als SaaS angeboten. Ein solches Angebot richtet sich an Unternehmen, die ihr gesamtes Rechenzentrum, inklusive Hardware, Software, Wartung und Bereitstellung auslagern möchten. Anbieter solcher Lösungen sind die Firmen fluid Operations [77] und Zimory [141].

Kapitel 4

Ausgewählte Cloud-Angebote

Im vorangegangenen Kapitel 3 wurde eine technische Architektur für Cloud-Dienste beschrieben und damit die Landschaft des Cloud Computing kartiert. Konkrete Cloud-Angebote kamen hierbei nur kurz zur Sprache. Unter anderem über die Angebote von Amazon, Google, Microsoft und Salesforce.com will das folgende Kapitel einen Überblick geben und deren Funktionsumfang und Anwendung vermitteln. Darüber hinaus soll dargestellt werden, wie man diese Cloud-Dienste benutzen kann. Die Auswahl fiel auf die genannten Angebote, weil sie zum einen einen hohen Bekanntheitsgrad genießen und zum anderen in ihrer jeweiligen Kategorie in der Cloud-Architektur eine prototypische Rolle spielen. Es ist an dieser Stelle aber unbedingt festzuhalten, dass das Feld des Cloud Computing bei weitem nicht nur aus diesen großen Mitspielern besteht. Insbesondere auch die Mittelständler und Start-Ups spielen mit ihren innovativen Entwicklungen eine wichtige Rolle. Dem wird unter anderem durch die Abschnitte über Cloud Gaming und CloudBetriebssysteme Rechnung getragen, die neuere Anwendungsklassen des Cloud Computing beschreiben.

C. Baun et al., Cloud Computing, 2. Aufl., Informatik im Fokus, DOI 10.1007/978-3-642-18436-9_4, c Springer-Verlag Berlin Heidelberg 2011 

43

44

4 Ausgewählte Cloud-Angebote

4.1 Amazon Web Services Amazon Web Services (AWS) [50] ist der Sammelbegriff für alle Cloud-Angebote der Firma Amazon. Das Cloud-Engagement des Unternehmens, das immer noch vorrangig als Händler von Waren über das Internet bekannt ist, lässt sich leicht begründen: Amazon muss IT-Ressourcen in einem erheblichem Umfang vorhalten, der sich am saisonalen Spitzenaufkommen – zur Weihnachtszeit und zum Erntedankfest, dem amerikanischen Thanksgiving Day – orientiert. Ein Großteil dieser Ressourcen liegt im Jahresverlauf jedoch brach. So entstand die Geschäftsidee, die freien Ressourcen gegen Entgelt in Zeiten schwacher Nutzung dritten zur Verfügung zu stellen. Gegenwärtig bietet Amazon die folgenden Cloud Dienste: • Amazon Elastic Compute Cloud (Amazon EC2) [40]: Mit Amazon EC2 kann der Benutzer über Web Services virtuelle Server verwalten, die in den Rechenzentren von Amazon für ihn ausgeführt werden. Mehr Details hierzu werden in Abschnitt 4.1.1 genannt. • Amazon Simple Storage Service (Amazon S3) [46]: Die Speicherung von großen Datenmengen in einem im Wesentlichen flach aufgebauten Massenspeicher erlaubt Amazon S3, auf das Abschnitt 4.1.2 weiter eingeht. • Der Amazon Elastic Block Store (EBS) [39] dient der dauerhaften (persistenten) Speicherung von Daten innerhalb von Instanzen. In Abschnitt 4.1.3 wird näher auf diesen Dienst eingegangen. • Amazon Simple Queue Service (Amazon SQS) [48]: Amazon SQS realisiert ein Benachrichtigungssystem auf der Basis von Nachrichten-Warteschlangen, in die eine schreibende Anwendung (Publisher) Nachrichten einstellen kann. Registrierte empfangende Anwendungen (Subscriber) können diese dann asynchron auslesen (Abschnitt 4.1.4). Mit Hilfe von

4.1 Amazon Web Services

•

•

•

•

•

•

45

SQS lassen sich auf einfache Weise skalierbare Anwendungen in der Cloud entwickeln (Abschnitt 4.1.7). Amazon SimpleDB [47]: Die Amazon SimpleDB ist eine Cloud-Datenbank, die ein einfaches Datenbankmodell umsetzt, das an ein abgespecktes relationales Datenbankmodell erinnert. Mehr Informationen hierzu siehe Abschnitt 4.1.5. Amazon Relational Database Service (RDS) [45]: Der Relational Database Service realisiert eine relationale MySQL Datenbank in der Amazon-Cloud auf Basis einer EC2 Datenbankinstanz. Amazon CloudFront [36]: Zur schnellen Auslieferung von Daten in Web-Anwendungen verwendet man häufig sogenannte Content Distribution Networks (CDN). Hier sind die Daten redundant und geographisch verteilt gespeichert. Die Benutzer bekommen die nachgefragten Daten vom jeweils für sie am besten geeigneten Knoten ausgeliefert. Amazon CloudFront realisiert ein Content Distribution Network als Aufsatz für Amazon S3. Amazon Elastic MapReduce [41]: Mit Amazon Elastic MapReduce lassen sich datenintensive Berechnungen über eine beliebige Anzahl von Amazon EC2-Instanzen verteilen und somit flexibel skalieren. Amazon Virtual Private Cloud (VPC) [49]: Über die VPC können EC2-Ressourcen innerhalb der AWS transparent in die vorhandene IT-Infrastruktur des Kunden integriert werden. Die Integration der externen Ressourcen in das Netzwerk des Kunden erfolgt über eine sichere, verschlüsselte VPNVerbindung und bietet so die Möglichkeit zum Aufbau einer Hybrid Cloud. Amazon berechnet für diesen Dienst die üblichen Preise zuzüglich der durch die VPN-Verbindung übertragenen Datenmenge. AWS Import/Export [52]: Auf den ersten Blick anachronistisch klingt das Angebot, die Übertragung sehr großer Datenmengen durch das Versenden physikalischer Datenträger auf

46

4 Ausgewählte Cloud-Angebote

dem Postweg zu erledigen. Da jedoch zahlreiche Praxisprobleme beim Netzwerktransfer großer Datenmengen existieren, ist der Postversand besonders im Bereich mehrerer Petabyte schneller, zuverlässiger und preiswerter als die Übertragung über das Internet. Falls keine sichere Netzwerkverbindung aufgebaut werden kann, hat das Versenden der Daten per Post auch Vorteile im Hinblick auf den Datenschutz. Die Daten werden verschlüsselt auf den Datenträgern abgelegt und es wird über ein Zertifikat der Eigentümer identifiziert. Nur der Inhaber des Zertifikats kann nach der Integration der Datenträger in den Rechenzentren von Amazon diese in Betrieb nehmen und die Daten nach Angabe des Schlüssels verarbeiten. Neben diesen Cloud-Angeboten, die offizielle Bestandteile der AWS sind, gibt es noch weitere Cloud-Dienste, die aber nur als abhängige Unterstützungs- oder Teilfunktionalitäten der obigen Angebote zu sehen sind. Auf diese soll an dieser Stelle nicht weiter eingegangen werden.

4.1.1 Amazon Elastic Compute Cloud (EC2) Die virtuellen Server in der Amazon Elastic Compute Cloud bilden das Herzstück der Amazon Web Services. Die folgenden Schritte sind notwendig, um einem solchen Server einzurichten und dauerhaft zu betreiben: • Auswahl der Region: Amazon bietet für die Dienste vier geographische Regionen an, in denen man Ressourcen zu unterschiedlichen Preisen nutzen kann. Bei den Regionen handelt es sich um: – US East =⇒ Virginia – US West =⇒ Kalifornien

4.1 Amazon Web Services

47

– EU East =⇒ Irland – Asia Pacific =⇒ Singapur • AMI-Auswahl: Die virtuellen Server werden aus Amazon Machine Images (AMI) erzeugt. Diese sind eine Art Blaupause für das Anlegen eines neuen virtuellen Servers. Amazon stellt vorgefertigte Images zur Verfügung, die sich in ihrem Betriebssystem und in den darauf installierten SoftwarePaketen unterscheiden. AMIs von Amazon gibt es z. B. für verschiedene UNIX-Derivate und auch für WindowsBetriebssysteme mit unterschiedlichen installierten Umgebungen z. B. für Web-Anwendungen. Neben Amazon stellt auch eine Reihe Drittanbieter, wie z. B. IBM, Oracle und Sun, AMIs mit eigenen Software-Paketen zur Verfügung. Auch die Endbenutzer können eigene Images zur späteren Wiederverwendung anfertigen. Es ist möglich, diese AMIs zu veröffentlichen und über eine Produkt-ID zu vermarkten (Paid Instances). Betriebssystem und installierte Software-Pakete sind die Hauptkriterien für die Auswahl eines geeigneten AMIs, die über ein eigenes Web-Portal mit Bewertungsfunktion auf den Web-Seiten der AWS erfolgen kann. • Auswahl der Ressourcenkonfiguration und Verfügbarkeitszone (Availability Zone): Eine weitere Vorüberlegung ist die Auswahl der richtigen Ressourcengröße für den gewünschten virtuellen Server. Die Ressourcenkonfigurationen unterscheiden sich nach der Leistungsfähigkeit des Prozessors und der Größe von Arbeits- und Plattenspeicher. Außerdem muss der Kunde eine Verfügbarkeitszone auswählen, in der der virtuelle Server laufen soll. Die verschiedenen oben genannten Regionen sind wiederum in Verfügbarkeitszonen unterteilt, die insofern voneinander unabhängig sind, dass sie sich keine kritischen Komponenten teilen und sie damit nicht gleichzeitig aus demselben Grund ausfallen können. Eine kluge Auswahl der Verfügbarkeitszone kann also zur Verringerung von La-

48

4 Ausgewählte Cloud-Angebote

tenzen und zu verbesserter Zuverlässigkeit bei redundant ausgelegten Servern führen. Die Region US East bietet vier Verfügbarkeitszonen, während die Regionen US West, EU East und Asia Pacific aktuell jeweils nur zwei Verfügbarkeitszonen beinhalten. • Schlüsselpaar generieren: Die Benutzer identifizieren sich gegenüber den genutzten Amazon EC2 Instanzen über ein sogenanntes Public-Key-Verfahren. Vor einer Erstbenutzung muss man folglich ein Paar aus öffentlichem und privatem Schlüssel generieren. Der öffentliche Schlüssel wird mit dem auch für die Abrechnung erforderlichen Amazon Benutzerkonto assoziiert und der private Schlüssel verbleibt in der Arbeitsumgebung des Benutzers. • Instanz starten: Mit den Parametern aus den obigen Vorüberlegungen lässt sich nun die gewünschte Instanz starten. Nach dem Startprozess erhält der entstandene virtuelle Server eine dynamisch zugewiesene öffentliche und eine private IPAdresse. Unter der öffentlichen Adresse ist der Rechner später aus dem Internet erreichbar, unter der privaten Adresse ist er für andere Instanzen in der Amazon Cloud sichtbar. Da sowohl die privaten als auch die öffentlichen Adressen dynamisch bei jedem Start einer Instanz neu vergeben werden, sind diese nicht für den dauerhaften Betrieb eines Servers geeignet, wenn dieser im Laufe seines Lebenszyklus wiederholt neu gestartet werden muss. Für diesen Fall bietet Amzon die statischen elastischen IP-Adressen, die – einmal reserviert – immer wieder den verschiedenen neuen Inkarnationen eines Servers zugewiesen sind. Die Elastic IPs lassen sich daher z. B. gut für DNS-Einträge verwenden. • Security Group definieren und konfigurieren: Aus Sicherheitsgründen sind neue Instanzen nach ihrer Entstehung nicht unmittelbar aus dem Internet zu erreichen. Vielmehr müssen sie einer Sicherheitsgruppe, einer sogenannten Security Group angehören, für die jeweils dieselben definierbaren

4.1 Amazon Web Services

49

Sicherheitseinstellungen gelten. Für solch eine Gruppe lässt sich beispielsweise auch der Zugang über die Secure Shell (SSH) auf dem entsprechenden Port 22 freischalten. Nun lässt sich der virtuelle Server mittels SSH erreichen, wobei zur Authentifizierung das Public-Key-Verfahren mit den oben generierten Schlüsseln zur Anwendung kommt. • Speicherung von Zuständen: Zustandsänderungen einer laufenden Instanz während ihres Betriebs sind nicht dauerhaft. Bei der Beendigung der Instanz gehen alle Änderungen verloren. Um auch über die Laufzeit eines virtuellen Servers hinaus Zustandsänderungen persistent zu machen, ist folglich der Zustand außerhalb der Instanz zu speichern. Für die Speicherung großer Mengen schwach strukturierter Daten kann man Amazon S3 verwenden, das jedoch für die typischen Dateisystemoperationen weniger geeignet ist. Hier kommt Amazon Elastic Block Store (EBS) zum Einsatz, das einen blockbasierten Zugriff auf ein Speichermedium erlaubt. Aus Sicht der EC2-Instanz lässt sich EBS wie eine externe Festplatte benutzen. Mit dem Befehlssatz von EBS lassen sich Speichervolumen anlegen, mit EC2-Instanzen verknüpfen, dort als Laufwerk anhängen und dann wie gewohnt benutzen. Nach dem geregelten Schließen und Abhängen des Volumens, z. B. beim Herunterfahren der Instanz, kann es wieder anderen neuen EC2-Instanzen zur Verfügung stehen. Die gleichzeitige Nutzung eines EBS-Volumens durch mehrere Instanzen ist jedoch nicht möglich. Ein besonders praktische Eigenschaft der Kombination von Amazon EBS und EC2 ist die Möglichkeit, nach Bedarf Momentaufnahmen des EBS-Zustandes (engl. Snapshots) zu erstellen und diese auf Amazon S3 zu sichern. • Erstellung eigener AMIs: Images, die auf die eigenen Bedürfnisse zurechtgeschnitten sind, lassen sich am einfachsten auf einem möglichst passenden vorkonfigurierten AMI aufbauen, das man zunächst wie oben beschrieben zusammen mit einem EBS-Volumen in Betrieb nimmt. Dort installiert man dann

50

4 Ausgewählte Cloud-Angebote

zunächst wie gewohnt die eigenen Erweiterungen. Durch eine Reihe spezieller Kommandos zum Bündeln des ursprünglichen Images mit den eigenen Anpassungen lässt sich das eigene Image erstellen und geschützt durch Zertifikate auf S3 speichern. Nach der Registrierung des Images ist die Verwendung der eigenen Instanzen von Amazon S3 aus möglich. • Werkzeugunterstützung: Alle oben beschriebenen Vorgänge lassen sich über Kommandozeilenbefehle ausführen. Wem dies zu umständlich ist, der kann mittlerweile auf eine Reihe von Werkzeugen zurückgreifen, die über die AWS-Homepage verfügbar sind. Hervorzuheben sind unter diesen Werkzeugen die AWS Management Console, das AWS Toolkit für die Entwicklungsumgebung Eclipse und der ElasticFox als Plugin für den Web Browser Firefox. Diese stellen jeweils abhängig vom adressierten Benutzerkreis bestimmte Teilmengen der Schnittstelle zu AWS auf komfortable Weise zur Verfügung (siehe Abschnitt 5.3 und Anhang 9). Die Kosten für den Betrieb von on-demand EC2-Instanzen ergeben sich aus mehreren Positionen: Der Preis für die eigentliche Instanz richtet sich nach deren Leistungsfähigkeit und wird stundenweise abgerechnet. Tabelle 4.1 zeigt den Preis pro Stunde in Dollar auf dem Stand vom Winter 2010 für Instanzen, die im Osten der USA laufen. Die Linux-Instanzen sind damit ca. 10 Prozent preiswerter, als die gleichen Instanzen in Europa. Die Größenangaben, die das Leistungsvermögen der Instanzen angeben, beziehen sich auf das Standardmaß EC2 Compute Unit (ECU) zusammen mit weiteren Eigenschaften des virtuellen Systems. Eine ECU ist äquivalent zur Rechenleistung einer 2007er AMD Opteron oder Intel Xeon CPU mit 1,0 bis 1,2 GHz Prozessortakt.

1,60 2,10

Quadruple Extra Large GPU Quadruple Extra Large

cc1.4xlarge cg1.4xlarge

Linux/UNIX

Cluster Compute On-Demand Instance

0,50 1,20 2,40

Extra Large Double Extra Large Quadruple Extra Large m2.xlarge m2.2xlarge m2.4xlarge

Linux/UNIX

High Memory On-Demand Instance

0,17 0,68

Medium Extra Large c1.medium c1.xlarge

Linux/UNIX

High CPU On-Demand Instance

0,085 0,34 0,68

Small (Default) Large Extra Large m1.small m1.large m1.xlarge

Linux/UNIX

Standard On-Demand Instance

0,02

Micro t1.micro

Linux/UNIX

Micro On-Demand Instance

Tabelle 4.1 Preise für Amazon EC2 on-Demand Instanzen (USD/Stunde)

Nicht verfügbar Nicht verfügbar

Windows

0,62 1,44 2,88

Windows

0,29 1,16

Windows

0,12 0,48 0,96

Windows

0,03

Windows

4.1 Amazon Web Services 51

52

4 Ausgewählte Cloud-Angebote

Eine Standard On-Demand Instance Small entspricht einem 32-bit Rechnersystem mit einem virtuellen Prozessorkern mit einer ECU, 1,7 GB Arbeitsspeicher und 160 GB Plattenspeicher. Am anderen Ende der Leistungsskala für universell einsetzbare Instanzen weist eine High Memory On-Demand Instance Quadruple Extra Large eine 64-bit Plattform mit 26 ECUs (jeweils 3,25 ECU verteilt auf 8 virtuelle Kerne), 68,4 GB Hauptspeicher und 1690 GB Festplatte aus. Die Cluster Compute Instanzen sind HPCaaS-Angebote von Amazon, die wegen ihrer Anbindung an 10 Gigabit Ethernet eine sehr hohe Eingabe-/Ausgabegeschwindigkeit haben. Solche Instanzen sind bislang ausschließlich in der Region US East und mit Linux verfügbar. Sie verfügen über je zwei Quad-Core Intel Xeon-X5570 Nehalem Prozessoren und 1690 GB Festplattenspeicher. Jede Cluster Compute On-Demand Instance GPU Quadruple Extra Large enthält zusätzlich zwei Nvidia TeslaM2050-Grafikeinheiten. Ausschließlich die beiden Instanzklassen m1.small und c1.medium verwenden Systeme mit einer 32-Bit Architektur. Alle übrigen Instanzklassen verwenden Systeme mit einer 64-Bit Architektur. Eine Ausnahme bildet die Instanzklasse t1.micro, die sowohl mit 32-Bit als auch 64-Bit Instanzen verwendet werden kann. Neben den stündlichen Betriebskosten, die zwischen dem Ein- und Ausschalten einer Instanz anfallen, geht auch der Datentransfer nach Volumen, die Verwendung einer dauerhaften Elastic IP nach Zeit und der benutzte Elastic Block Store nach Speichervolumen über die Zeit in die Gesamtkosten ein. Darüber hinaus können noch weitere kostenpflichtige Features hinzugebucht werden. Um angesichts des bereits recht komplexen Preismodells die potenziell entstehenden Kosten für den Benutzer besser einschätzbar zu machen, bietet Amazon auf der AWSHomepage ein Berechnungsformular an, das die monatlichen

4.1 Amazon Web Services

53

Kosten für eine gegebene Konfiguration und ein bestimmtes angenommenes Nutzungsprofil ausrechnet. Neben den dynamischen Instanzen bietet Amazon auch reservierte Instanzen für die Dauernutzung an. Diese können für die Dauer von einem oder drei Jahren angemietet werden. Die Kosten reduzieren sich dabei entsprechend. So fallen für eine Reserved Instance Small in Europa mit Linux insgesamt $ 227,5 pro Jahr ($ 350 für drei Jahre) an. Eine weitere Möglichkeit, den Preis für Instanzen zu senken, bieten die sogenannten Spot-Instanzen. Die Kunden haben hierbei die Möglichkeit, in einem Auktionsmodell auf nicht genutzte Amazon EC2-Kapazität zu bieten. Der Preis von Spot-Instanzen ist variabel und wird von Amazon in regelmässigen Abständen in Abhängigkeit von Angebot und Nachfrage festgelegt. Um SpotInstanzen zu verwenden, geben die Kunden unter Angabe des gewünschten Instanztyps, der Region und Anzahl der Instanzen einen Höchstpreis an, den sie je Instanz-Stunde bereit sind zu bezahlen. Solange eine ausreichende Anzahl an Spot-Instanzen zu einem günstigeren Preis verfügbar ist, wird der Auftrag ausgeführt und die Instanzen werden gestartet. Übersteigt der SpotPreis den gebotenen Höchstpreis, werden die Instanzen beendet. Fällt der Spot-Preis wieder unter den gebotenen Höchstpreis, werden die Instanzen automatisch neu gestartet. Eine Aktualisierung des Spot-Preises findet alle 30 Minuten statt. Dieses Angebot ist besonders interessant für Projekte aus Industrie und Forschung, die einen engen Kostenrahmen einhalten müssen und mit Laufzeitunterbrechungen umgehen können. Ein Beispiel für die Verwendung von Amazon EC2 findet sich in Anhang 9.1.

54

4 Ausgewählte Cloud-Angebote

4.1.2 Amazon Simple Storage Service (S3) Amazon S3 ist ein Massenspeicher in der Cloud mit einer sehr einfachen Speicherstruktur. Die gespeicherten bis zu 5 GB großen Web-Objekte liegen in sogenannten Buckets. Diese können nicht hierarchisch geschachtelt werden, sondern jedes WebObjekt ist direkt über seinen Bucket-Namen zusammen mit seinen Objekt-Namen identifizierbar. Folglich handelt es sich bei Amazon S3 nicht um ein herkömmliches Dateisystem, auch wenn es Werkzeuge und Cloud-Dienste von Drittanbietern gibt, die es erlauben, auf Speicher-Ressourcen in S3 wie auf entfernt liegende Festplatten zuzugreifen, wie z. B. JungleDisk [100]. Der Zugriff auf Amazon S3 erfolgt definitionsgemäß über Web Services und ist über eine SOAP oder eine REST API möglich. Letztere ist zu bevorzugen, besonders wenn der Umgang mit großen Objekten vorgesehen ist, da REST in der Regel mit diesen besser umgehen kann als SOAP. Wie bei EC2 stehen auch für S3 komfortable grafische Benutzerschnittstellen zur Verfügung, auf die Abschnitt 5.3 näher eingeht. Für den direkten Zugriff auf Amazon S3 von der Kommandozeile aus gibt es das Werkzeug s3cmd [121], dessen Funktionsweise in Anhang 9.4 illustriert wird.

4.1.3 Amazon Elastic Block Store (EBS) Mit dem Speicherdienst EBS können die Kunden innerhalb jeder Verfügbarkeitszone Datenspeicher, sogenannte Volumen (engl. Volumes) mit einer Größe von 1 GB bis 1 TB erzeugen. Ein neu erzeugtes EBS-Volumen verhält sich wie ein unformatiertes Block-Gerät. Ein EBS-Volumen kann ein beliebiges

4.1 Amazon Web Services

55

Dateisystem enthalten und verhält sich von der Bedienung gesehen genauso wie ein USB-Stick. Es ist zu beachten, dass ein EBS-Volumen immer nur an genau einer Instanz angehängt werden kann, die sich innerhalb der gleichen Verfügbarkeitszone befinden muss. Ein EBS-Volumen realisiert persistenten Speicher, d.h. nach dem Herunterfahren einer Instanz bleiben die Daten erhalten. Ein Beispiel für die Verwendung von Amazon EBS findet sich in Anhang 9.2.

4.1.4 Amazon Simple Queue Service (SQS) Die Nachrichtenwarteschlange SQS hat in der Palette der AWS Cloud-Angebote eine besondere Bedeutung, weil sie sich gut zur Skalierung von Anwendungen einsetzen lässt. Sender (Publisher) können in die Warteschlange Nachrichten einstellen, die dann registrierte Empfänger wieder auslesen und verarbeiten können. Zur Entkoppelung verschiedener Komponenten in einer Anwendung kann eine dienstnehmende Komponente ihre Arbeitsaufträge als Nachricht in die Warteschlange einstellen, von wo sie dienstgebende Komponenten abholen. Bei geschickter Programmierung lassen sich auf dem so definierten Pfad kritische Komponenten auf mehreren EC2-Instanzen parallel betreiben. So lassen sich Engpässe in bestimmten Komponenten auch noch zur Laufzeit flexibel beheben und die Gesamtleistung des Systems wird nicht mehr durch den Engpass bestimmt. Das Beispiel in Abschnitt 4.1.7 illustriert die resultierende Systemarchitektur. Die Schnittstelle zu SQS bietet die folgenden Dienste, die Nutzer in der Regel nicht direkt per Kommando aufrufen, sondern durch die entsprechenden Aufrufe von Web Services aus den verbundenen Komponenten.

56

4 Ausgewählte Cloud-Angebote

• CreateQueue: Anlegen einer Warteschlange im AWSBenutzerkontext • ListQueues: Aufzählung der existierenden Warteschlangen • DeleteQueue: Löschen einer Warteschlange • SendMessage: Einstellen einer Nachricht in eine Warteschlange • ReceiveMessage: Auslesen einer (oder mehrerer) Nachrichten aus einer Warteschlange • ChangeMessageVisibility: Dediziertes Einstellen der Sichtbarkeit einer gelesenen Nachricht für andere potenzielle Ausleser • DeleteMessage: Löschen einer gelesenen Nachricht • SetQueueAttributes: Einstellen von Attributen der Warteschlange, z. B. der Zeit zwischen zwei Leseoperationen auf dieselbe Nachricht • GetQueueAttributes: Auslesen von Attributen der Warteschlange, z. B. der Anzahl der aktuell in der Warteschlange befindlichen Nachrichten • AddPermission: Freigabe einer Warteschlange zum geteilten Zugriff aus mehreren Benutzerkontexten • RemovePermission: Widerrufen der Freigabe für andere Benutzerkontexte.

4.1.5 Amazon SimpleDB Die Amazon SimpleDB ist nicht auf komplexe Datenbankschemata oder transaktionale Eigenschaften ausgelegt, sondern auf einfach strukturierte, aber hoch zuverlässige Datenhaltung, die für ein breites Spektrum an Anwendungen als ausreichend erachtet wird. Die Aufgaben zur Administration und Optimierung der Datenbank sind dadurch auf ein Minimum reduziert. Für Anwendungen, die auf die Leistungsfähigkeit und den großen

4.1 Amazon Web Services

57

Funktionsumfang aktueller kommerzieller Relationaler Datenbanksysteme (RDBMS) angewiesen sind, wird auf Amazon RDS verwiesen (siehe Abschnitt 4.1.6). Entsprechend des eingeschränkten Funktionsumfangs der SimpleDB ist auch ihre Schnittstelle auf einige wenige einfache Web Service Aufrufe begrenzt. Dies soll zugleich zu einer einfachen Erlernbarkeit und Bedienbarkeit führen: • CreateDomain, ListDomains, DeleteDomain: Anlegen, Aufzählen bzw. Löschen von Domänen. Domänen entsprechen Tabellen im Relationalen Modell. In einem Befehl kann immer nur eine Domäne angesprochen werden. • DomainMetadata: Auslesen von Meta-Daten einer Domain, wie z. B. ihres aktuellen Speicherplatzbedarfs • PutAttributes: Hinzufügen oder Aktualisieren eines Datensatzes basierend auf einem Datensatzidentifikator und Attribut/Wert-Paaren • BatchPutAttributes: Gleichzeitiges Anstoßen mehrer Einfügeoperationen zur Performance-Erhöhung • DeleteAttributes: Löschen von Datensätzen, Attributen oder Werten • GetAttributes: Lesen eines identifizierten (Teil-)Datensatzes • Select: Anfrage an die Datenbank in SQL-ähnlicher Syntax jedoch ohne die übliche Anwendbarkeit auf mehrere Domänen (Join).

4.1.6 Amazon Relational Database Service Der Amazon Relational Database Service (Amazon RDS) [45] ist ein Plattformdienst zum einfachen Einrichten, Betreiben und Skalieren einer relationalen Datenbank in der Cloud. Der Dienst stellt analog zum EC2-Betriebsmodell elastische Kapazi-

58

4 Ausgewählte Cloud-Angebote

täten zur Verfügung und erledigt gleichzeitig zeitraubende Datenbankverwaltungsaufgaben. Durch automatisierte DatenbankBackups sowie Snapshots bietet Amazon RDS einen sehr zuverlässigen Betrieb, indem man die Wiederherstellung einer Datenbankinstanz für jeden beliebigen Zeit- oder Wiederherstellungspunkt innerhalb des vereinbarten Aufbewahrungszeitraums vornehmen kann. Mit Amazon CloudWatch ist es möglich, die Auslastung der Rechen- und Speicherkapazitäten der Datenbankinstanzen zu überwachen und die zur Verfügung stehenden Ressourcen mit einem einfachen API-Aufruf nach Bedarf vertikal zu skalieren. Bei sehr anspruchsvollen vornehmlich lesenden Anwendungen erreicht man horizontale Skalierbarkeit durch die Einrichtung von Read-Replika-Instanzen. Ein entsprechendes Hochverfügbarkeits-Angebot erlaubt es, synchron replizierte Datenbankinstanzen ohne zusätzliche Kosten auch in mehreren Verfügbarkeitszonen bereitzustellen, um sich dadurch gegen Ausfälle an einem einzelnen Standort abzusichern. Es ist so auch möglich, Wartungsfenster zu verbergen, da RDS die Datenbankdienste transparent zwischen den Standorten umschaltet. Amazon RDS gewährt Zugriff auf sämtliche Funktionen einer MySQL-Datenbank, so dass die Migration existierender Anwendungen unter Beibehaltung der bevorzugten DatenbankWerkzeuge oder Programmiersprachen sehr einfach möglich ist. Wenn eine vorhandene Anwendung bereits eine MySQLDatenbank nutzt, kann man die Daten mittels mysqldump exportieren und anschließend in Amazon RDS wieder einlesen. Bei größeren Datenbanken ab ca. 1 Gigabyte empfiehlt es sich, zunächst ein Datenbankschema in Amazon RDS zu erstellen, die Daten in eine Flat-Datei zu konvertieren und dann über das mysqlimport-Dienstprogramm in die RDS-Instanz zu importieren. In gleicher Weise lassen sich Daten aus den Datenbankdiensten exportieren.

4.1 Amazon Web Services

59

Amazon RDS wählt die optimalen Konfigurationsparameter für Datenbankinstanzen aus und berücksichtigt dabei die Anforderungen an Rechenressourcen und Speicherkapazität. Es ist jedoch auch möglich, die Standardeinstellung über Konfigurationsverwaltungs-APIs zu ändern. Da es sich bei RDS um einen Plattformdienst handelt, ist der direkte Zugriff auf die Server mittels SSH zur Einstellung der Datenbankparameter nicht möglich. Amazon bietet zum Management der Datenbankdienste nicht nur Kommandozeilenwerkzeuge und Bibliotheken für verschiedene Programmiersprachen an [51], sondern auch eine komfortable Web-Konsole [53]. Ein Beispiel für die Verwendung von Amazon RDS findet sich in Anhang 9.3.

4.1.7 Zusammenspiel der Amazon Web Services Die verschiedenen AWS Dienste können sowohl einzeln als auch im Zusammenspiel bei der Anwendungsentwicklung verwendet werden. In [29] wird beispielhaft eine Anwendung beschrieben, die verschiedene AWS Dienste nutzt, um Suchanfragen auf Millionen von Web-Dokumenten auszuführen. Die unter dem Namen GrepTheWeb bekannte Anwendung ist bei Amazon in der Produktionsumgebung im Einsatz. In diesem Szenario (siehe Abbildung 4.1) arbeiten SQS, SimpleDB, EC2 und S3 zusammen. Eine Reihe von SQSWarteschlangen speichert sowohl eingehende Anfragen als auch Zwischenergebnisse, die bei der Verarbeitung der Anfragen entstehen. Dadurch ist die Phase der Verarbeitung vom Eingang entkoppelt. Suchanfragen sind als reguläre Ausdrücke formuliert, die als Nachrichten (launch message) in eine initiale SQSWarteschlange (launch queue) eingehen. Für jeden Verarbei-

60

4 Ausgewählte Cloud-Angebote Amazon SQS Billing Queue

Launch Queue

Monitor Queue

Launch Controller

Shutdown Queue

Monitor Controller

Controller

Shutdown Controller

Billing Controller

Get EC2 Info

Launch

Insert JobID Status

Billing Service

Ping Insert Amazon EC2 Info Shutdown

Check for results

Master M Slaves N Put File

Status DB

HDFS

Amazon Simple DB

Hadoop Cluster on Amazon EC2

Get File

Output

Input

Amazon S3

Abb. 4.1 Zusammenspiel der AWS am Beispiel GrepTheWeb (Quelle: Amazon)

tungsschritt gibt es eine Controller-Komponente (launch controller, monitor controller, shutdown controller, billing controller), die von einer Warteschlange liest und Ergebnisse in die nächste Warteschlange schreibt. Die Ausführung der Verarbeitungsschritte durch die Controller erfolgt somit asynchron und die Controller sind jeweils voneinander unabhängig. Die Controller verwenden SimpleDB, EC2 und S3. Ersteres wird für Statusinformationen, Logs, und Nutzerdaten für Anfragen benutzt. SimpleDB wird somit von jedem Controller angefragt und geschrieben. S3 dagegen wird zur Speicherung der zu untersuchenden Daten (Hunderte von Terabytes an Web-Dokumenten) und der Ergebnisse der Suchanfrage benutzt. Der Zugriff auf S3 erfolgt über ein Hadoop-Cluster aus EC2-

4.2 Cloud-Dienste von Google

61

Instanzen (siehe auch Abschnitt 6.9). Diese werden durch den launch controller angelegt, durch den monitor controller beobachtet, und durch den shutdown controller heruntergefahren. GrepTheWeb ist ein Beispiel einer modularen Anwendungsarchitektur, die Phasen von Bearbeitungsschritten vorsieht und diese durch Warteschlangen entkoppelt sowie durch unabhängige Controller-Komponenten steuert. Alle Komponenten sind leichtgewichtig und kommunizieren diensteorientiert über HTTP-Anfragen unter Nutzung der erweiterbaren Auszeichnungssprache XML (Extensible Markup Language). Die Architektur illustriert, wie verschiedene Basisdienste kombiniert werden können, um skalierbare Multi-Mandantensysteme zu entwickeln, die unterschiedliche Lastsituationen dynamisch bedienen und zudem auch Fehler wie beispielsweise Ausfälle einzelner Knoten tolerieren können.

4.2 Cloud-Dienste von Google Genau wie Amazon verfügt auch Google über eine breite Palette verschiedenartiger Cloud-Dienste, von denen einige ausgewählte im folgenden vorgestellt werden sollen.

4.2.1 Google App Engine Die Google App Engine [85] ist eine Platform as a Service mit Programmierumgebung, Werkzeugunterstützung und Ausführungsumgebung. Mit dieser Ausstattung lassen sich WebAnwendungen für die skalierbare Infrastruktur von Google entwickeln. Durch die Google App Engine können sich die Ersteller der Web-Anwendungen auf die Entwicklung der Anwendungs-

62

4 Ausgewählte Cloud-Angebote

funktionalität konzentrieren und müssen sich praktisch keine Sorgen um die Administration von Servern machen. Die Google App Engine bietet Umgebungen für die Programmiersprachen Python und Java an. Für diese Sprachen gibt es eine lokale Laufzeitumgebung, die während der Entwicklungsphase das probeweise Ausführen und Testen der selbstentwickelten Web-Anwendungen erlaubt. Hat die Anwendung den Produktivzustand erreicht, kann man sie auf die Google Infrastruktur übertragen und dort ausführen lassen. Die Web-Anwendung profitiert somit von den Zuverlässigkeits- und Skalierungstechnologien, die Google auch für seine eigenen Endprodukte wie die bekannte Suchmaschine oder die Online Office Suite Google Docs einsetzt. Im Rahmen privater Tests oder einfacher nichtkommerzieller Systeme ist das Angebot kostenfrei. Zusätzlich zu den üblichen Funktionen, die Java mit seinen Bibliotheken mitbringt, bietet die Plattform den Zugriff auf eine Reihe weiterer Dienste (im Sinne der Cloud-Architektur: Anwendungsdienste). Diese können z. T. über die Standardschnittstellen von Java angesprochen werden, um die Portabilität und Benutzbarkeit des entwickelten Codes auch außerhalb des App Engine Umfelds zu erleichtern: • Speicherung von Daten: Für die dauerhafte Speicherung von Daten verwendet die Google App Engine den sogenannten Datastore, eine Schema-lose objektorientierte Datenbank mit einer Anfrage-Engine und Zusicherung von Atomizität der Operationen. Der Datastore implementiert sowohl eine proprietäre Schnittstelle, aber auch die Standardschnittstellen Java Data Objects (JDO) und Java Persistence API (JPA). • Email-Integration: In die Web-Anwendungen lässt sich das Versenden und Empfangen von Emails über Google EmailKonten einbinden. Auch dieser Anwendungsdienst lässt sich analog über eine proprietäre Schnittstelle oder über ein Subset des standardisierten JavaMail-Interface verwenden.

4.2 Cloud-Dienste von Google

63

• Benutzerverwaltung: Zur Authentifizierung der Kunden der Web-Anwendung kommen Google-Konten zum Einsatz, für die es eine proprietäre Schnittstelle gibt. Die Benutzer können sich über eine Umleitung auf der Anmeldeseite von GoogleKonten anmelden. Ein rudimentäres Rechte-Management erlaubt es, einfache Benutzer und Administratoren zu unterscheiden, um den Zugriff auf geschützte Funktionen zu regeln. • Über die genannten Dienste hinaus existieren noch weitere, z. B. zur schnellen Zwischenspeicherung von Daten in einem Cache, zur Verknüpfung mit anderen Web-Anwendungen mittels HTTP(S) oder zum effizienten Bearbeiten von anzuzeigenden Abbildungen. Google App Engine unterstützt nicht nur Entwickler von WebAnwendungen durch die oben genannte lokale Laufzeitumgebung und die zugehörige Automatisierung der Übertragung und Einrichtung (engl. Deployment) auf den Google Servern. Es existieren darüber hinaus noch zahlreiche weitere Werkzeuge, wie z. B. das Google Plugin for Eclipse für die Entwicklung von Google Web Toolkit (GWT) Anwendungen. Auch in der Bepreisung der App Engine orientiert sich Google an den Bedürfnissen potenzieller Entwickler: es gibt ein kostenloses Freikontingent (engl. Quota) je Entwickler für CPU-Auslastung, Speicherbenutzung, Datentransfer etc., das tageweise ausgeschöpft werden kann und für Entwicklungssysteme und einfache WebAnwendungen in der Regel ausreichend ist. Falls absehbar über diese Grenzen hinaus Ressourcen benötigt werden, können diese kostenpflichtig hinzu erworben werden. Die Kosten für die kommerzielle Nutzung bewegen sich auf einem ähnlichen Niveau wie bei den Amazon Web Services. Die hohen Hürden, die sich durch die Verwendung proprietärer Technologien ergeben, sind zu Recht ein häufig genannter Kritikpunkt am Cloud Computing. Für viele Platform

64

4 Ausgewählte Cloud-Angebote

as a Service-Angebote ist die Wiederverwendbarkeit des Codes der entwickelten Anwendungen sehr eingeschränkt bis unmöglich. Der Anbieter der Web-Anwendung ist dauerhaft an den Betreiber des Cloud-Angebotes gebunden und damit auch an dessen Preisgestaltung und Dienstqualität. Für die Google App Engine gibt es mit AppScale [58] aber inzwischen eine kompatible quelloffene Plattform, die das Umziehen von WebAnwendungen in eine zu EC2 kompatible Private oder Public Cloud IaaS ermöglicht (Siehe auch Kapitel 6 und 9). Das Projekt, das von der University of California in Santa Barbara ausging, wird mittlerweile von Google selbst aktiv unterstützt. Eine weitere freie Re-Implementierung der Google App Engine ist typhoonAE, das den Betrieb von App Engine Anwendungen in beliebigen Linux-Umgebungen sowie unter Mac OS X ermöglicht.

4.2.2 Google Storage Der Speicherdienst Google Storage [92] ermöglicht das Speichern von Web-Objekten in den Datenzentren von Google. Der Zugriff erfolgt ebenso wie bei Amazon S3 über das RESTModell. Google Storage bietet dieselbe Funktionalität wie Amazon S3: Objekte werden in Buckets abgelegt, wobei ein Bucket keine weiteren Buckets enthalten kann. Ein Nutzer kann den Zugriff auf eigene Objekte und Buckets mit Hilfe einer Access Control List festgelegen. Das von Google angebotene Kommandozeilenwerkzeug GSUtil [94] ist in der Lage, sowohl mit Google Storage als auch mit Amazon S3 zu arbeiten. GSUtil erlaubt es, mit Hilfe eines Browsers eigene Buckets anzulegen, Objekte hochzuladen und die Zugriffsrechte zu administrieren.

4.2 Cloud-Dienste von Google

65

Der Dienst befindet sich aktuell (Stand November 2010) noch in der Entwicklungsphase und Google vergibt Zugangsdaten ausschließlich an Entwickler in den USA. Die Speicherung von Daten kostet pro Gigabyte $0,17/Monat. Das Hochladen von Daten kostet $0,10/Gigabyte und das Herunterladen kostet zwischen $0,15/Gigabyte und $0,30/Gigabyte (je nach Region). Für 1000 Anfragen via PUT, POST und LIST berechnet Google $0,01. Der gleiche Preis gilt für 10000 Anfragen via GET und HEAD.

4.2.3 Google Cloud Print Ein weiteres interessantes Konzept des Cloud Computing ist Google Cloud Print [87]. Der Dienst ermöglicht beliebigen Anwendungen, auf ebenso beliebigen Ausgabegeräten im Internet zu drucken. Das Thema besitzt insbesondere für mobile Endgeräte eine hohe Relevanz. Während moderne internetfähige Geräte wie Netbooks, Touchpads und Mobiltelefone eine immer stärkere Verbreitung finden, ist es oftmals schwierig oder gar unmöglich, einen lokalen Drucker einzurichten und zu verwenden. Das Fehlen geeigneter Druckertreiber, die teilweise sehr geringen Ressourcen der Geräte und die Vielfalt der verwendeten Betriebssysteme verstärken diese Problematik. Bei Google Cloud Print werden Druckaufträge an einen Dienst gesendet, der diese direkt an einen zu Cloud Print kompatiblen Netzwerkdrucker weiterleitet, wobei ein Autorisierungsbzw. Abrechnungsverfahren zum Einsatz kommt. Wenn ein Drucker mit dem Internet verbunden ist, kann der Dienst für eine weltweite Nutzung eingerichtet werden. Falls der Drucker inkompatibel zur Cloud Print Technologie ist, muss er mit einem Server verbunden werden, auf dem ein entsprechendes Vermittlungsprogramm (engl. Proxy) installiert wurde. Der Auftrag

66

4 Ausgewählte Cloud-Angebote

wird in diesem Fall mit Hilfe der beim Cloud Print Anbieter installierten Druckertreiber zunächst in eine kompatible Druckersprache aufbereitet und an den Server gesendet, der die aufbereiteten Druckaufträge anschließend an den ausgewählten Drucker weiterleitet. Es handelt sich bei Google Cloud Print um einen freien Standard, der von der Industrie ohne Auflagen implementiert werden kann. Viele Hersteller, darunter auch HP, bieten bereits eine Reihe kostengünstiger, kompatibler Drucker an. Die Entwicklung hat das Potenzial, dass sich eine breite Palette von Dienstleistungen um diese neue Technik entfalten könnte, die weit über den Ersatz des zentral verwalteten Betriebs von Druckaufträgen in Unternehmen und Universitäten hinausgehen. An Universitäten könnten Studierende in Zukunft ihre Vorlesungsskripten z.B. direkt vom Touchpad bei einem Dienstleister drucken und binden lassen, der aufgrund von Skaleneffekten inklusive kostenfreier Zustellung einen sehr günstigen Preis anbieten kann. Insbesondere auch die firmenübergreifende Verarbeitung von Massendrucksachen, Qualitätsdrucken usw. könnte mit Cloud Print aufgrund der einheitlichen Schnittstelle weitestgehend automatisiert und vereinfacht werden. Darüber hinaus rückt als neues Vertriebsmodell für Verlage die Aufstellung von Automaten in der Öffentlichkeit in greifbare Nähe, die gesteuert von einem Mobilgerät nach Bedarf beliebige elektronische Zeitschriften, Zeitungen oder Bücher drucken können.

4.3 Windows Azure Die Windows Azure Plattform [59] ist Microsofts Cloud Computing-Plattform zur Ausführung von Software in den Microsoft-Rechenzentren. Microsoft übernimmt dabei den Betrieb der Plattform und stellt Ressourcen mit einer 99,9% Verfügbarkeitszusage auf redundanten Systemen bereit.

4.3 Windows Azure

67

Die Windows Azure Platform umfasst einen Compute-Dienst zur Ausführung von Anwendungen, einen Storage-Dienst zur Speicherung von Daten sowie einen SQL-Dienst, der relationale Datenbanken hochverfügbar in der Cloud bereitstellt. Der Storage-Dienst ermöglicht die Speicherung von großen Objekten, die Textdaten oder Binärdaten enthalten können. Das darauf aufbauende Windows Azure Drive ermöglicht die Formatierung eines Binärdatenobjekts zur Verwendung als NTFS-Volumen. Ein Warteschlangendienst sorgt für einen zuverlässigen Nachrichtenaustausch zwischen den Komponenten. Der Dienst für virtuelle Netzwerke bildet schließlich die Grundlage für die transparente Kommunikation zwischen lokalen und fernen Ressourcen. Es können damit Windows Azure Dienste in ein lokales Active Directory integriert werden. Zusätzlich beinhaltet die Plattform die Windows Azure AppFabric, mit der sich herkömmliche eigene IT-Systeme und Cloud Anwendungen sicher verbinden lassen. Die Azure ServicePlatform bietet die Wahlmöglichkeit, Softwareprodukte entweder als Cloud-Dienste im Internet oder als Anwendungen im eigenen Rechenzentrum zu installieren. Man kann auch beide Möglichkeiten kombinieren, um eine flexibel skalierbare Hybrid Cloud zu realisieren. Web- und Business-Entwickler können dabei auf etablierte Werkzeuge wie Microsoft .NET, Visual Studio oder zahlreiche weitere kommerzielle und Open SourceWerkzeuge zurückgreifen. Es ist möglich, Anwendungen lokal zu entwickeln und zu testen, um sie anschließend in die Azure Cloud hochzuladen und zu veröffentlichen. Windows Azure sieht bei der Nutzung der Dienste drei verschiedene Rollen vor: • Die Web-Rolle unterstützt die Entwicklung und Ausführung von Web-Anwendungen mit Internet Information Server 7 • Die Worker-Rolle bietet Unterstützungsdienste für die WebRolle in z.B. Multi-Tier Anwendungen

68

4 Ausgewählte Cloud-Angebote

• Die VM-Rolle erlaubt die Ausführung einer virtuellen Maschine mit Windows Server 2008 R2, deren Abbild auf einer virtuellen Harddisk im Storage-Dienst abgelegt ist. In dieser Rolle ist auch die Vergabe von Privilegien sowie die Verwendung einer Remote Desktop-Verbindung vorgesehen. Das verbrauchsorientierte Bezahlmodell von Windows Azure basiert auf der tatsächlichen Ressourcennutzung, so dass man IT-Lösungen ohne Vorabinvestition in Hard- und Software bereitstellen und später einfach nach Bedarf neue Rechenleistung dazuschalten kann. Die Preisgestaltung orientiert sich dabei an den Modellen von Amazon oder Google (Siehe Tabelle 4.2). Tabelle 4.2 Preise für Windows Azure Compute Instanzen (USD/Stunde) Instanztyp

CPU

Memory

Disk

I/O

Kosten

Extra small Small Medium Large Extra Large

1.0 GHz 1.6 GHz 2x1.6 GHz 4x1.6 GHz 8x1.6 GHz

768 MB 1.75 GB 3.5 GB 7 GB 14 GB

20 GB 225 GB 490 GB 1000 GB 2040 GB

Low Moderate High High High

0,05 0,12 0,24 0,48 0,96

4.4 Salesforce.com Salesforce.com [125] ist einer der weltweit führenden CloudAnbieter für Software zur Kundenbeziehungsverwaltung (Customer Relationship Management, CRM). Im Sinne von Kapitel 3 ist Salesforce.com ein SaaS Angebot, das um ein Platform as a Service-Angebot ergänzt wurde, auf dem unabhängige Dritte ergänzende Software as a Service entwickeln und anbieten kön-

4.4 Salesforce.com

69

nen. Das Portfolio von Salesforce.com besteht aus den folgenden vier Hauptbestandteilen: • Im Mittelpunkt steht das CRM SaaS-Angebot namens Salesforce, das eine Web-basierte Lösung u. a. für die Bereiche Vertrieb, Marketing, Kundenservice und Partnermanagement bietet. Die zentrale Komponente ist für verschiedene Funktionsumfänge und Benutzeraufkommen in mehreren Bundles erhältlich und wird in der Regel monats- oder jahresweise gemietet. Als klassisches SaaS-Angebot läuft die multimandantenfähige Anwendung auf den Servern von Salesforce.com und erfordert keine lokale Installation. • Force.com [78] heißt das Angebot einer Platform as a Service, das es Kunden oder Drittanbietern (Independent Software Vendors, ISV) erlaubt, eigene Web-basierte Geschäftsanwendungen zu entwickeln und auf der salesforce.com Infrastruktur zu betreiben. Weitere technische Details zu Force.com sind weiter unten beschrieben. • Die auf Force.com entwickelten Geschäftsanwendungen können über den Marktplatz AppExchange [56] kostenlos oder gegen Miete vertrieben werden. Die Anwendungen sind über Force.com vorintegriert mit dem Salesforce.com CRM und ihre Funktionalität ist häufig komplementär zu diesem oder auf bestimmte Branchen abgestimmt. • Flankiert werden Force.com und Salesforce.com von jeweils einer organisierten Benutzergemeinde namens DeveloperForce [67] bzw. Salesforce.com Community [124], über die sich die Benutzer zum einen vernetzen und zum anderen professionelle Beratungsleistungen von Salesforce.com und seinen Partnern angeboten werden. Die Force.com Plattform bietet die Entwicklungswerkzeuge und Programmierumgebung, mit der sich beispielsweise die Anwendungslogik in der Java-ähnlichen Programmiersprache Apex entwickeln lässt. Ebenfalls zum Repertoire der Werkzeuge ge-

70

4 Ausgewählte Cloud-Angebote

hört die Unterstützung für die Entwicklung von Benutzerschnittstellen mit Visualforce, die Integration von Software-Testverfahren oder die Anbindung externer Web Services über eine eigene API. Das verfolgte Programmiermodell bei der Entwicklung eigener Web-Anwendungen hat einen stark datenzentrierten Ansatz: Die Entwicklung einer Anwendung beginnt in der Regel mit der Erstellung eines Objektmodells, das später die Anwendungsdaten beinhalten soll. Zu den Datenelementen lassen sich dann Constraints zur Verbesserung der Datenqualität definieren. Diese beiden ersten Schritte lassen sich ebenso wie die Definition von Workflows und Abnahmeprozessen über die Daten direkt aus der Entwicklungsumgebung heraus definieren. Die Programmiersprache Apex muss erst zum Einsatz kommen, wenn komplexere Anwendungslogik umgesetzt werden muss. Neben den genannten wesentlichen Arbeitsschritten zur Erfüllung von funktionalen und nicht-funktionalen Anforderungen helfen die Entwicklerwerkzeuge auch bei den organisatorischen Abläufen, die notwendig sind, um die entwickelte Anwendung zu packen und als Angebot für potenzielle Kunden zur Verfügung zu stellen. Beim Erlernen der Programmierung auf Force.com hilft umfangreiches Material in Form von Tutorials, Handbüchern, Referenzwerken und Code-Beispielen, das über die CommunityPortale im Web verfügbar ist.

4.5 Cloud Gaming Unter der Bezeichnung Cloud Gaming werden Angebote zusammengefasst, die es ermöglichen, High-End Videospiele auf LowEnd Geräten wie Fernsehgeräten, Computern mit schwacher Rechenleistung aber auch mobilen Endgeräten wie Tochpads und Mobiltelefonen verfügbar zu machen. Durch die Einführung der

4.6 Cloud-Betriebssysteme

71

3D-Fernsehgeräte steht neuerdings sogar eine Plattform für 3DSpiele bereit. Beim Cloud Gaming werden die Videospiele auf den leistungsfähigen Serverfarmen des Anbieters ausgeführt. Lediglich die Darstellung erfolgt auf den Zielgeräten und wird in Form eines komprimierten Videostroms übertragen. Benutzereingaben werden zum Anbieter gesendet und dort ausgewertet. Eine Grundvoraussetzung für die Nutzung von Cloud Gaming ist die Verfügbarkeit breitbandiger Internetverbindungen mit geringen Latenzen, um eine kurze Reaktionszeit sicherzustellen und den Spielfluss nicht zu unterbrechen. Positiv wirkt sich aus, dass bei Mehrbenutzer-Online-Spielen eine schnellere Interaktion zwischen den Teilnehmern möglich ist, wenn das Spielgeschehen zentral bei einem Anbieter abgehandelt wird. Die nötige Kompression des Videostroms führt allerdings zu einer optischen Qualitätsminderung. Cloud Gaming-Kunden haben den Vorteil, dass die Investition in eine Spielekonsole bzw. einen leistungsfähigen Computer und die zugehörigen Spiele entfällt. Statt dessen ergibt sich ein nutzungsabhängiger Betrag für die Dauer des Spiels. Für die Spielehersteller ergibt sich beim Cloud Gaming der positive Nebeneffekt, dass das Problem von Raubkopien wegfällt. Bekannte Anbieter von Cloud Gaming-Diensten sind OnLive [110], Gaikai [79] und Otoy [118].

4.6 Cloud-Betriebssysteme Die Angebote der sogenannten Web-Desktops werden auch als Cloud-Betriebssysteme bezeichnet. Ein bekanntes Produkt aus dieser Gruppe ist die Open Source-Lösung eyeOS [71]. Das Betriebssystem mit den installierten Anwendungen und Benutzerdaten läuft auf den Serverfarmen des Anbieters. Der Benutzer

72

4 Ausgewählte Cloud-Angebote

benötigt lediglich ein Endgerät mit Internetzugang und einem standardkonformen Browser. Auch wenn Produkte wie eyeOS als Cloud-Betriebssystem bezeichnet werden, ist der Begriff in den meisten Fällen doch irreführend. Denn für die Nutzung eines Cloud-Betriebssystems benötigt der Benutzer einen Rechner mit Browser und dafür auch ein zugrunde liegendes Betriebssystem. Das lokale Betriebssystem wird somit nicht ersetzt, sondern vielmehr ergänzt. Es werden ausschließlich die Benutzeranwendungen und -daten ausgelagert. Google Chrome OS [86] ist ein weiteres Angebot aus der Klasse der Cloud-Betriebssysteme: Auf einem auf das nötige Minimum reduzierten Linux Betriebssystem läuft ein Chrome Browser, mit dem man alle Google Web-Anwendungen effizient nutzen kann. Durch seinen geringen Ressourcenbedarf ist es möglich, dass Chrome OS selbst auf den kleinsten Netbooks, sogenannten Nettops lauffähig ist.

Kapitel 5

Cloud-Management

Sowohl beim Betrieb als auch bei der Nutzung von CloudDiensten ist die Einrichtung geeigneter Management-Verfahren unerlässlich. Leistungen müssen beschrieben, erbracht und abgerechnet werden. Um Skalierbarkeit und Zuverlässigkeit der Dienste zu erreichen, kommen automatisierte Prozesse zum Einsatz. Sicherheitsfragen und Risikobetrachtungen spielen insbesondere beim Auslagern von Diensten aus dem lokalen Kontext in die Public Cloud eine große Rolle. Dieses Kapitel beschäftigt sich mit den Aspekten des Cloud-Managements.

5.1 Dienstgütevereinbarungen: Service Level Agreements Bei einer Dienstgütevereinbarung (Service Level Agreement) handelt es sich um eine Vereinbarung über die Dienstgüte zwischen einem Dienstanbieter und einem Dienstnehmer. Diese Vereinbarung kann über einen Vertrag formal und rechtlich bindend getroffen werden oder aber informell, wenn verschiedene AbteiC. Baun et al., Cloud Computing, 2. Aufl., Informatik im Fokus, DOI 10.1007/978-3-642-18436-9_5, c Springer-Verlag Berlin Heidelberg 2011 

73

74

5 Cloud-Management

lungen eines Unternehmens die Dienste nutzen. Man spricht in diesem Fall dann von Operation Level Agreement (OLA). Das SLA beinhaltet auf der qualitativen Seite ein gemeinsames Verständnis über Sicherheit, Prioritäten, Verantwortlichkeiten, Garantien und Abrechnungsmodalitäten. Darüber hinaus spezifiziert das SLA messbare Größen wie Verfügbarkeit, Durchsatz, Reaktionszeiten u.ä. Von ihrer Natur sind SLAs dabei stets an der Ausgabe orientiert, d. h. sie sind immer aus der Sicht des Dienstnehmers formuliert. Ein Anbieter kann sich profilieren, indem er einen Dienst in besonderer Qualität oder besonders innovativer Weise erbringt. Aus der Geschäftsperspektive kann man die Qualität dabei in mehreren Stufen vereinbaren, z. B. Basic, Silber, Gold, Platin. Im Bereich des Cloud Computing sind SLAs interessant bei der Kontrolle der Ressourcenzuteilung und der dynamischen Ressourcennutzung. Es gibt dabei zwei Phasen, die für das Service Level Management eine Rolle spielen: • Vereinbarung der Leistung (Quality of Service) • Überwachung zur Laufzeit (Service Monitoring) Die Vereinbarung und Überwachung von spezifischen SLAs ist bei den aktuellen Cloud-Angeboten zurzeit nur in Ansätzen möglich, und die Angebote erfolgen in der Regel auf der Basis des Best Effort. Im Falle von Störungen oder Ausfällen gibt es dabei meist eine entsprechende Gutschrift. Die Entwicklungsaufgabe auf Seite der Cloud-Architektur besteht darin, in das Cloud-System eine Schicht einzufügen, welche die beiden Aspekte der Dienst-Vereinbarung und Überwachung behandelt. SLA@SOI [128] ist ein von der Europäischen Kommission im 7. Rahmenprogramm gefördertes Projekt, das die Aspekte von mehrstufigen SLAs in einem Markt mit konkurrierenden Angeboten untersucht.

5.2 Lebenszyklus und Automatisierung

75

5.2 Lebenszyklus und Automatisierung Jeder Cloud-Dienst durchläuft einen wohl definierten Lebenszyklus: Der Dienstanbieter definiert den Umfang und die Qualität der Dienste und beschreibt die Eigenschaften in einem DienstKatalog. Die Bezieher der Dienste wählen diese aus dem Katalog aus und instanzieren sie nach Bedarf, wobei SLAs zu berücksichtigen und zu überwachen sind. Am Ende der Nutzungsdauer werden die Dienst-Aufträge geschlossen, Dienst-Bausteine werden abgewickelt und Ressourcen werden zurückgesetzt. Eine Prozedur für die Verbrauchserfassung (engl. Accounting) summiert den Ressourcenverbrauch auf. Der aktuelle Status kann somit feingranular und zeitaufgelöst verfolgt werden. Die Abrechnung der entstandenen Kosten erfolgt entweder in regelmäßigen Abständen, oder beim Überschreiten einer bestimmten Schwelle. Die eingesetzten Verfahren zur Abrechnung (engl. Billing) basieren meist auf Kreditkarten. Bei manchen Anbietern wie z. B. Zimory ist auch die Bezahlung über Lastschriftverfahren bzw. Rechnungstellung möglich [141]. Die Bereitstellung von Diensten geschieht sehr häufig auf der Basis von sogenannten Ensembles. Ein Ensemble ist eine Gruppe gleichartiger, vollautomatisch verwalteter Ressourcen. Dieser Ansatz erlaubt die skalierbare Bereitstellung von Diensten bei nahezu konstantem Verwaltungsaufwand. Die Automatisierung umfasst dabei die folgenden Schritte: 1. 2. 3. 4.

Überwachung Analyse Planung Ausführung

Ein geeignetes Monitoring-Verfahren überwacht kontinuierlich die Dienstgüte, die Analysekomponente untersucht und bewertet die Ausgaben der Überwachungskomponente. Im Falle von

76

5 Cloud-Management

Störungen oder Abweichungen bei den vereinbarten Leistungsparametern wird aus einem zuvor definierten Portfolio ein geeigneter Prozess zur Beseitigung der Störung ausgewählt (Planung). Die ausführende Einheit setzt schließlich den Prozess um, indem sie z. B. für eine Anwendung oder Anforderung zusätzliche Ressourcen bereitstellt. Die zugehörigen Komponenten bilden einen Regelkreis, der zyklisch durchlaufen wird: Die Automatisierung von Prozessen ist eine wichtige Grundlage nahezu aller CloudArchitekturen, da damit dynamische Skalierbarkeit und Fehlertoleranz möglich ist.

5.3 Management-Dienste und -Werkzeuge Die Cloud-Anbieter offerieren für das Management ihrer Dienste eine reichhaltige Palette von Werkzeugen, die sowohl kommandozeilenbasiert sind als auch in Form von Web-Portalen zur Verfügung stehen. Aus der schier unendlichen Vielzahl von Lösungen werden im Folgenden für die verschiedenen Bereiche einige Werkzeuge exemplarisch vorgestellt.

5.3.1 Überwachung Die periodische Erhebung von Leistungsdaten ist sowohl für den Cloud-Betreiber wichtig als auch für den Cloud-Nutzer zur Beurteilung der Dienstgüte. So sammelt z. B. CloudClimate die Leistungsdaten verschiedener Cloud-Dienstanbieter und publiziert sie auf einer Web-Seite [63]. Diese Daten umfassen Größen wie CPU, Speicherverbrauch und Festplattenzugriffe. Die Darstellung erfolgt als Diagramm für den vergangenen Monat. Auf diese Weise ist nicht nur ein direkter Leistungsvergleich ver-

5.3 Management-Dienste und -Werkzeuge

77

schiedener Anbieter möglich, sondern es können auch Störungen und Phasen mit ungewöhnlicher Last identifiziert werden. Bei Amazon CloudWatch handelt es sich um einen speziellen Dienste zum Monitoring der Leistung der Amazon Web Services [37]. CloudWatch ermöglicht den Einblick in die Ressourcen-Nutzung und zeigt die aktuelle Leistung und Zugriffsmuster. Der Dienst erhebt Daten für die CPU-Nutzung, Plattenzugriffe und Netzwerkverkehr. Um CloudWatch zu aktivieren, kann man den Dienst einer EC2-Instanz zuordnen. Die Verarbeitung der Monitoring-Daten erfolgt über das Web Service API oder über Kommandozeilenprozeduren.

5.3.2 Steuerung Amazon bietet zum Management der Infrastrukturdienste nicht nur einen Satz von Kommandozeilenwerkzeugen und Bibliotheken zur Verwendung mit verschiedenen Programmiersprachen an [51], sondern auch eine komfortable Web-Konsole [53] (Abbildung 5.1). Diese ermöglicht die Steuerung und Beobachtung der Dienste Amazon S3, Amazon EC2, Amazon Virtual Private Cloud, Amazon Elastic MapReduce, Amazon CloudFront, Amazon Relational Database Service und Amazon Simple Notification Service. Die Konsole bietet die folgenden Operationen für EC2: • Instanzen: Starten, Stoppen, Neustarten, Entfernen, Konsolenzugriff, Logfiles sichten • Images: Starten, Registrieren, Löschen, Zugriffsrechte setzen • Speicher: Anlegen, Löschen, Zuordnen, Lösen, Snapshots • Netzwerk: IP-Adressen verwalten • Struktur: Platzierungsgruppen und Lastverteilung verwalten • Sicherheit: Sicherheitsgruppen und Schlüssel verwalten

78

5 Cloud-Management

Abb. 5.1 Infrastruktur-Management mit der AWS Konsole

Die Ausführung der Management-Operationen ist dabei für die verschiedenen Verfügbarkeitszonen gesondert möglich. Neben den offiziellen EC2-Kommandozeilenwerkzeugen von Amazon existiert noch eine Vielzahl von freien Werkzeugen, um mit zu AWS kompatiblen Cloud-Diensten zu interagieren. Beispiele dafür sind s3cmd [121] und die Euca2ools von Eucalyptus. Eine alternative grafische Konsole steht als Open Source Plugin für den FireFox-Browser bereit: ElasticFox organisiert in ähnlicher Weise das Infrastruktur-Management [72]. Ein Vorteil von ElasticFox ist, dass damit nicht nur das Management einer Public Cloud auf Basis von EC2 möglich ist, sondern auch das Management einer Private Cloud auf der Basis von Eucalyptus. Ein Screenshot der ElasticFox-Konsole ist in Abbildung 5.2 zu sehen. Um den Amazon Speicherdienst S3 zu nutzen, stehen mehrere Lösungen zur Verfügung. Besonders interessant ist das

5.3 Management-Dienste und -Werkzeuge

79

Abb. 5.2 Infrastruktur-Management mit ElasticFox

FireFox-Plugin S3Fox Organizer [122]. Mit diesem Werkzeug kann ein Kunde • Daten hoch- und herunterladen, löschen, hierarchisch organisieren, • die Sichtbarkeit von Daten im Internet regeln (auch temporär), • Zugriffsrechte verwalten (insbesondere Access Control Lists einrichten) und • lokale Ordner automatisch mit S3 synchronisieren. Die Benutzerschnittstelle ähnelt einem herkömmlichen FTPKlienten (Abbildung 5.3). Die lokalen und die Cloud-Dateistrukturen werden in zwei Ansichten nebeneinander dargestellt, das Kopieren von Daten geschieht über simples Drag und Drop. Prinzipiell können die existierenden Werkzeuge zur Arbeit mit Cloud-Diensten drei Kategorien zugeordnet werden: • Online-Werkzeuge (Dienste) • Browser Plugins • Kommandozeilenwerkzeuge

80

5 Cloud-Management

Abb. 5.3 S3Fox Organizer für Speicherdienste

Zur Klasse der Online-Werkzeuge, die meist als Dienste realisiert sind, gehören beispielsweise die AWS Management Console [53] sowie ein entsprechendes Angebot von Ylastic [139]. Ein Nachteil dieser Lösungen ist, dass Kunden dem Anbieter des Werkzeugs im Hinblick auf Datenschutz und Datensicherheit vertrauen müssen, da die Zugangsdaten stets beim Provider gespeichert werden. Darüber hinaus kann die AWS Management Console ausschließlich mit Diensten zusammenarbeiten, die Teil der Amazon Web Services sind. Private Cloud Dienste sind davon ausgeschlossen. Ylastic unterstützt zurzeit lediglich die Amazon Web Services und Infrastrukturdienste auf der Basis von Eucalyptus. Browser Plugins wie ElasticFox und Hybridfox sind einerseits sehr funktional, setzen aber andererseits eine lokale Installation voraus und haben damit einen gewissen Wartungsaufwand. Es gibt bei Versionswechseln beim Serviceanbieter ein gewisses Risiko der Schnittstellenunverträglichkeit. Die Plugins können auch nicht mit alternativen Produkten wie Chrome, Opera, Safari, Internet Explorer, usw. verwendet werden.

5.3 Management-Dienste und -Werkzeuge

81

Abb. 5.4 KOALA Cloud Manager

Kommandozeilenwerkzeuge wie die EC2 API Tools von Amazon und die Euca2ools von Eucalyptus setzen ebenfalls eine lokale Installation voraus. Da sie keine grafische Oberfläche enthalten, ist ihre Benutzbarkeit eingeschränkt. Die EC2 API Tools arbeiten ebenso wie die anderen Werkzeuge von Amazon ausschließlich mit den AWS Public Cloud Diensten zusammen. Die Euca2ools können mit Public und Private Cloud Diensten interagieren, die zu den Amazon Web Services kompatibel sind. KOALA [101, 102] ist eine neue Lösung zur Steuerung von Cloud-Diensten, die die Einschränkungen der existierenden Werkzeuge vermeidet. Dabei handelt es sich um einen Softwaredienst, der zu AWS Schnittstellen kompatible Public und Private Cloud-Infrastrukturen steuern kann (Abbildung 5.4). Unterstützt werden Cloud-Dienste von Amazon, Eucalyptus, Nimbus und OpenNebula sowie das Management von Google Storage. Der Dienst selbst kann in der Google App Engine betrieben werden oder alternativ in einer dazu kompatiblen Private Cloud (AppScale und typhoonAE) laufen. KOALA ist unter einer Open Source Lizenz veröffentlicht.

Amazon

ElasticFox [72]

Eualyptus

Amazon

Google

M. Ludvig

Amazon

Euca2ools [74]

API-Tools [50]

GSUtil [94]

s3cmd [121]

AWS Toolkit [54]

Suchi

Ylastic

S3Fox [122]

Amazon

Ylastic [139]

KIT

Anbieter

AWS Console [53]

KOALA [101]

Name

Eclipse

Shell

Shell

Shell

Shell

Plug-in

Plug-in

SaaS

SaaS

SaaS

Design

Lizenz

Apache v2.0

GPLv2

Apache v2.0

Apache v2.0

BSD

proprietär

Apache v2.0

proprietär

proprietär

Apache v2.0

Tabelle 5.1 Cloud Management Werkzeuge

kostenfrei

kostenfrei

kostenfrei

kostenfrei

kostenfrei

kostenfrei

kostenfrei

$25/Monat

kostenfrei

kostenfrei

Kosten

ja

nein

nein

ja

ja

nein

ja

ja

ja

ja

EC2

nein

ja

ja

nein

nein

ja

nein

ja

ja

ja

S3

nein

nein

nein

ja

ja

nein

ja

ja

ja

ja

EBS

nein

nein

nein

ja

nein

nein

nein

ja

ja

ja

Eclipse

Installation

Installation

Installation

Installation

Firefox

Firefox

Browser

Browser

Browser

ELB Anforderungen

82 5 Cloud-Management

5.3 Management-Dienste und -Werkzeuge

83

5.3.3 Entwicklung In einer an Diensten orientierten Landschaft greifen Betrieb und Entwicklung oftmals eng ineinander. Neben den ManagementWerkzeugen spielen daher auch die Entwicklungswerkzeuge eine große Rolle. Als Beispiel für eine integrierte Cloud-Entwicklungs- und Managementumgebung soll Eclipse [70] dienen. Eclipse ist eine weit verbreitete Plattform zur Unterstützung der Anwendungsentwicklung. Es existieren zahlreiche Plugins für die verschiedensten Programmierumgebungen. So stellt z. B. das gEclipse-Projekt eine umfangreiche grafische Schnittstelle für Anwender, Entwickler und Betreiber von Grid- und CloudInfrastrukturen zur Verfügung [81]. Es gibt aber auch spezifische Erweiterungen für Amazon Web Services, wie z. B. das AWS Eclipse ToolKit [54], das es Entwicklern ermöglicht, verteilte und skalierbare Java-Anwendungen auf der Basis von TomcatContainern für Amazon EC2 zu entwickeln und zu testen (Abbildung 5.5). Daneben sind auch Werkzeuge für das Management von Sicherheitsgruppen, AMI-Bibliotheken, EC2-Instanzen und EBS-Speicher integriert. Eine weitere Möglichkeit zur Unterstützung der Cloud-Anwendungsentwicklung bietet Google mit dem Google Web Toolkit (GWT). Es handelt sich hierbei um ein Software Development Kit zur Entwicklung von Java- oder Python-Programmen für die App Engine Plattform [84]. Die Entwicklungsumgebung enthält neben dem GWT einen lokalen Webserver zum Austesten der Programme. Sobald die Anwendungen zufriedenstellend funktionieren, können sie in sogenannte WAR-Dateien paketiert und in die skalierbare Google-Infrastruktur geladen werden. Es gibt als Erweiterung des Software Development Kit auch ein Google Plugin für Eclipse zur interaktiven Entwicklung von GWT-Anwendungen in einer grafischen integrierten Entwicklungsumgebung [91].

84

5 Cloud-Management

Abb. 5.5 Amazon Web Service Plugin für Eclipse

Abb. 5.6 Google App Engine Plugin für Eclipse

Durch simples Drücken des App Engine Buttons können lokal entwickelte Programme zur Verwendung in der GoogleInfrastruktur veröffentlicht werden (Abbildung 5.6).

5.4 Sicherheitsmanagement

85

5.4 Sicherheitsmanagement Die Sicherheit umfasst sowohl den gesicherten Zugriff auf Ressourcen als auch Belange des Datenschutzes. Für das sogenannte Cloud Sourcing gibt es entsprechend einer Studie der Universität Berkeley keine die bisher angewendeten Maßnahmen übersteigenden besonderen Herausforderungen oder Probleme [1]. Es gelten im Bereich der Sicherheit prinzipiell dieselben Schutzziele wie sie auch beim Betrieb von Diensten in einem lokalen Rechenzentrum üblich sind [28]: • • • • • •

Vertraulichkeit Integrität Verfügbarkeit Authentizität Zurechenbarkeit Pseudonymität

Die Erfüllung dieser Schutzziele ist als Bestandteil des zwischen Dienstanbieter und -nehmer ausgehandelten SLA zu sehen. So erlaubt z. B. der Zimory Cloud-Marktplatz die Definition von SLAs zur Einstellung der gewünschten Sicherheitsanforderungen für Cloud-Dienste [141]. Die verschiedenen Kategorien von Cloud-Diensten besitzen dabei bedingt durch die Offenheit des Ansatzes verschiedene Charakteristiken: • IaaS: Größte Flexibilität, die Verantwortung für die Sicherheit liegt beim Kunden • PaaS: Mittlere Flexibilität, die Verantwortung für die Sicherheit liegt sowohl beim Kunden und als auch beim Anbieter • SaaS: Geringste Flexibilität, die Verantwortung für die Sicherheit liegt beim Anbieter Bei vielen Anbietern ist die Identität eines Kunden einfach durch die Zuordnung zu einer Kreditkartennummer festgelegt.

86

5 Cloud-Management

Hierdurch ist auch die problemlose Abrechnung der entstandenen Kosten sichergestellt. Durch Verwendung von Schlüsseln bzw. PKI-basierten Verfahren ist üblicherweise der Zugriff auf Ressourcen reguliert und es kann damit die unbefugte Nutzung verhindert werden. Die Verschlüsselung der Daten sowohl bei der Übertragung als auch der Speicherung stellt die Vertraulichkeit her. Hier ist zu beachten, dass die Ablage verschlüsselter Daten in der Cloud u. U. sogar sicherer ist als das Speichern unverschlüsselter Daten auf einem lokalen PC oder in einem Firmenrechenzentrum. Darüber hinaus zeichnen einige Anbieter über Auditing-Prozesse alle Aktionen im Umgang mit Ressourcen auf. Durch diese Art der Überwachung sind auch strengste gesetzliche Vorschriften einzuhalten. Für die Gewährleistung der Informationssicherheit spielt die Zertifizierung nach ISO/IEC 27001 bzw. SAS 70 in den USA die wichtigste Rolle. Hier werden Prozesse zur Herstellung und Überwachung der Sicherheit verbindlich festgelegt. Prominente Anbieter wie Amazon oder Microsoft haben ihre Ressourcenzentren entsprechend zertifiziert und können damit im Vergleich zu einem kleineren Unternehmensrechenzentrum einen höheren Sicherheitsstandard bieten. Es gibt Szenarien, bei denen das Auslagern von Aufgaben in die Cloud im Hinblick auf die Sicherheitsproblematik sogar Vorteile bietet: Wenn man mit externen Partnern in einem gemeinsamen Projekt zusammenarbeiten will, stellt die Firewall eines Unternehmens beim Aufsetzen der gemeinsamen Prozesse oftmals eine schier unüberwindliche Hürde dar. Wenn man diese Prozesse aber z. B. in die Amazon Cloud verlagert, kann man die Zugriffsregeln der Firewall selbständig so anpassen, dass alle Projektpartner problemlos zusammenarbeiten können, ohne die Sicherheitsrichtlinien der beteiligten Unternehmen zu kompromittieren. Ein umfassendes Kompendium zum Thema Cloud-Sicherheit hat die Cloud Security Alliance herausgegeben [66].

5.5 Risikomanagement

87

5.5 Risikomanagement Auch die Risikobetrachtungen unterscheiden sich beim Cloud Sourcing kaum von der klassischen Situation: Beim Auslagern von Daten besteht immer die Gefahr, dass der Zugriff bei Störungen des Diensts oder dem Bankrott eines Betreibers nicht mehr gegeben ist. Diese Problematik ist aber prinzipiell dieselbe wie beim Outsourcing und kann über die Vertragsgestaltung bzw. SLAs entsprechend geregelt werden. Zur Milderung des Problems kann man auch einen zweiten, unabhängigen Anbieter von Cloud-Diensten als Backup-Lösung hinzuziehen, der eine Kopie der geschäftskritischen Daten vorhält. Ein weiteres Risiko stellt die Abhängigkeit von proprietären Techniken und Schnittstellen der Anbieter dar (Gefahr des sogenannten Vendor-Lock-in): Hier ist das Problem am geringsten bei IaaS, und am größten bei PaaS und SaaS: Bei der Entwicklung eines Dienstes auf z. B. Google App Engine bindet man sich an die spezifische Google Infrastruktur und das Wechseln der Plattform kann entsprechend aufwändig und teuer sein. Hier ist anzumerken, dass auch beim Betrieb von Diensten im lokalen Rechenzentrum ähnliche Abhängigkeiten von SoftwareHerstellern, Plattformen und Infrastrukturen bestehen. Es hilft daher klassisches Wissen bei der Lösung des Problems: • Standardisierte Verfahren sollten nach Möglichkeit Vorrang vor einer proprietären Lösung haben. • Software sollte so entwickelt werden, dass sie möglichst plattformunabhängig ist. • Falls es unvermeidliche Abhängigkeiten gibt, sollten diese sauber gekapselt werden, um möglichst flexibel zu bleiben. Eine Wertung der Chancen und Risiken des Cloud Computing findet sich in Kapitel 8.

88

5 Cloud-Management

5.6 Rechtskonformität Das Angebot und die Nutzung von Cloud-Diensten darf nicht gegen Gesetze, gesellschaftliche Wertvorstellungen, Moral oder Ethik verstoßen. Dies ist durch die sogenannte Compliance sichergestellt. Nach gängiger Rechtsauffassung sind für das Cloud Computing dieselben Gesetze anzuwenden wie für die Miete (im Bezug auf bezahlte Dienste) oder die Leihe, falls es sich um unentgeltliche Leistungen handelt. Der Standort eines Cloud-Anbieters hat allerdings eine entscheidende Bedeutung für die Gesetze, die für die eingelagerten Daten gelten. Die Daten können zum gleichen Zeitpunkt an verschiedenen Orten auf der Welt repliziert sein und unterliegen somit womöglich unterschiedlichen Datenschutzgesetzen: Nach Artikel 4 der Europäischen Datenschutzrichtlinie gilt die nationale Datenschutzgesetzgebung des jeweiligen Landes [138]. Aus diesem Grund offeriert z. B. Amazon die Cloud-Dienste in unterschiedlichen Regionen für die USA, Europa und Asien, so dass es möglich ist, durch die Wahl der Zone einen geeigneten Rechtsraum für die Dienste festzulegen. Eine besondere Beachtung verdient in diesem Umfeld die Verarbeitung personenbezogener Daten. In Deutschland regelt insbesondere das Bundesdatenschutzgesetz (BDSG) den Umgang mit personenbezogenen Daten im nicht öffentlichen Bereich. Ergänzt wird das BDSG durch das Telemediengesetz (TMG), das Telekommunikationsgesetz (TKG) und das Sozialgesetzbuch (SGB). Nach dem BDSG bleibt der Cloud-Nutzer für die Verarbeitung der von ihm in die Cloud übertragenen Daten verantwortlich. Er muss prüfen, ob die technischen und organisatorischen Vorkehrungen des Anbieters zum Schutz der Daten ausreichen. Das TMG besagt, dass in Deutschland niedergelassene Dienstanbieter auch dann dem deutschen Recht unterliegen, wenn sie in-

5.6 Rechtskonformität

89

nerhalb des Geltungsbereichs der Richtlinie 2000/31/EG (europäischer Binnenmarkt) tätig sind [130]. Bei Datenverarbeitung außerhalb Europas ist sicherzustellen, dass ein angemessenes Datenschutzniveau besteht (z. B. Safe Harbor Abkommen in den USA). Die Auftragsdatenverarbeitung personenbezogener Daten in der Cloud erfordert bei Inanspruchnahme internationaler Ressourcen prinzipiell das schriftliche Einverständnis der betroffenen Personen. Sie ist aber aus rechtlicher Sicht dennoch immer statthaft, sobald der direkte Personenbezug durch Maßnahmen wie z. B. Verschlüsselung oder Anonymisierung der Daten aufgehoben wird.

Kapitel 6

Open Source Cloud-Schichtenmodell

Das Thema dieses Kapitels ist der Aufbau einer Cloud auf der Basis von Open Source-Komponenten. Es existiert bereits eine Vielzahl von Lösungen, die die Konstruktion einer CloudArchitektur erlauben. Es ist somit möglich, ein Open Source Cloud-Schichtenmodell (siehe Abbildung 6.1) zu entwerfen.

Abb. 6.1 OpenCirrus Open Source Cloud-Schichtenmodell

C. Baun et al., Cloud Computing, 2. Aufl., Informatik im Fokus, DOI 10.1007/978-3-642-18436-9_6, c Springer-Verlag Berlin Heidelberg 2011 

91

92

6 Open Source Cloud-Schichtenmodell

Der Entwurf umfasst nicht nur Komponenten für die Hardware- und Software-Infrastruktur, sondern auch Komponenten zur Etablierung von Anwendungsumgebungen. Das Schichtenmodell ist eine spezifische Ausprägung der in Kap. 3 dargestellten Cloud-Architektur: Die dort eingeführten IaaSKomponenten sind durch die Physischen Ressourcen Sets (PRS) zur Partitionierung der Infrastruktur repräsentiert, die SoftwareInfrastruktur umfasst Komponenten zur Verwaltung virtueller Maschinen und des Speichers, sowie Verfahren zur Überwachung und Steuerung der Infrastruktur. Die Schicht beinhaltet darüber hinaus auch Komponenten zur Job-Steuerung und für die Verbrauchserfassung (engl. Accounting) und Abrechnung (engl. Billing). Die PaaS-Komponenten bilden die FrameworkSchicht, die SaaS-Komponenten sind auf der Anwendungsebene zu finden. Im folgenden sollen einige der Komponenten des Entwurfs exemplarisch vorgestellt werden.

6.1 Physische und Virtuelle Ressourcen Die Wurzeln der IaaS-Komponenten liegen im EmulabProjekt [16], bei dem Mini-Rechenzentren für Systementwicklung zur Verfügung gestellt werden können. Auf der untersten Ebene organisiert man die Infrastruktur in Form von Physischen Ressourcen Sets (PRS). Ein PRS beinhaltet die für die Umsetzung einer Aufgabe nötigen Ressourcen wie CPUs, Speicher und Netzwerke. Ein virtuelles LAN verknüpft diese in einer gemeinsamen Domäne. Das Management der Domänen erfolgt über einen speziellen PRS-Dienst. Dieser kann die Ressourcen über das Netzwerk verwalten und gestattet es, Komponenten ein- und auszuschalten, System-Images auszurollen und die Infrastruktur zu überwachen. Ein Beispiel mit vier verschiedenen Domänen ist in Abbildung 6.2 gezeigt: Es gibt hier eine Domäne für Sys-

6.1 Physische und Virtuelle Ressourcen

93

Services Applications

Virtual cluster

Systems research

Virtual cluster

Tashi

NFS/HDFS storage services

Workload monitoring and trace collection services

PRS service

Abb. 6.2 Verschiedene Domänen auf einem Physischen Ressourcen Set

temforschung, eine für das Management virtueller Maschinen, sowie Domänen für Speicherdienste und Überwachung. Anwendungen, die auf virtuellen Clustern der zweiten Domäne laufen, nutzen diese Dienste. Die virtuellen Cluster bilden Virtuelle Ressourcen Sets (VRS). Beim Beispiel in Abbildung 6.2 handelt es sich um die Management-Suite Tashi, die Intel und Yahoo! zurzeit gemeinsam entwickeln. Tashi ist eine Lösung speziell für CloudRechenzentren, die massive Datenbestände im Internet bearbeiten müssen. Die grundlegende Idee ist, dass hierbei nicht nur CPU-Ressourcen einem Planungsprozess unterworfen sind, sondern darüber hinaus auch die verteilten Speicherressourcen. Das gemeinsame Scheduling von CPU und Datenspeicher erlaubt die Optimierung des Systems unter der Berücksichtigung des Energieverbrauchs [129].

94

6 Open Source Cloud-Schichtenmodell

Ein weiteres sehr populäres Managementsystem für virtuelle Ressourcen ist Eucalyptus, das im Folgenden beschrieben wird.

6.2 Eucalyptus Cloud-Infrastrukturen kommerzieller Anbieter wie Amazon EC2 und S3 und PaaS-Angebote wie Google App Engine bieten einen hohen Grad an Benutzbarkeit und sind zu geringen Kosten (teilweise sogar kostenfrei) nutzbar. In einigen Fällen ist es aber wünschenswert, eine private Cloud-Infrastruktur aufzubauen. Aspekte, bei denen eine private Cloud einer öffentlichen Cloud vorzuziehen ist, können spezielle Sicherheitsanforderungen oder das Speichern kritischer Unternehmensdaten sein. Auch der Aufbau eines internen Datenspiegels (RAID-0) ist denkbar, um die Verfügbarkeit einer Cloud-Infrastruktur bei einem kommerziellen Anbieter zu erhöhen. Eucalyptus [74] ist eine Abkürzung für Elastic Utility Computing Architecture for Linking Your Programs To Useful Systems. Die Entwicklung von Eucalyptus fand ursprünglich an der University of California in Santa Barbara (UCSB) statt. Die Weiterentwicklung erfolgt durch das Unternehmen Eucalyptus Systems. Eucalyptus ermöglicht den Aufbau und Betrieb einer eigenen IaaS Cloud-Infrastruktur. Die API von Eucalyptus ist kompatibel zu Amazon EC2, S3 und EBS [22]. Die SoftwareEntwicklung geschieht unter der BSD Lizenz und ist damit Open Source. Im Gegensatz zu Amazon EC2, das zur Virtualisierung ausschließlich Xen nutzt, kann Eucalyptus mit Xen und KVM (Kernel-based Virtual Machine) zusammenarbeiten. Voraussetzung für KVM ist, dass eine CPU mit Hardware-Virtualisierung (AMD-V bzw. Pacifica oder Intel VT-x bzw. Vanderpool) vorhanden ist. Eine Unterstützung für VMware vSphere/ESX/ESXi bietet die kommerziell verfügbare Enterprise Version, die

6.2 Eucalyptus

95

Abb. 6.3 Architektur und Komponenten von Eucalyptus

von Eucalyptus Systems angeboten wird. Die Integration der VMware-Unterstützung in die freie Version von Eucalyptus ist nicht geplant.

6.2.1 Architektur und Komponenten Die Eucalyptus-Infrastruktur besteht aus drei Komponenten (siehe Abbildung 6.3). Diese sind Cloud Controller (CLC), Cluster Controller (CC) und Node Controller (NC) [23]. Alle drei Komponenten sind als Web Services realisiert. Der NC muss auf jedem Knoten in der Cloud installiert sein, auf dem virtuelle Instanzen laufen sollen. Voraussetzung hier-

96

6 Open Source Cloud-Schichtenmodell

für ist ein funktionierender Xen Hypervisor oder KVM. Jeder NC sendet Informationen über den aktuellen Zustand der eigenen Ressourcen an den CC. Dieses sind Informationen über die Anzahl der virtuellen Prozessoren, den freien Hauptspeicher und den freien Festplattenspeicher. In jedem Cluster kümmert sich ein CC um die lastabhängige Verteilung (engl. Scheduling) der virtuellen Maschinen auf die NCs. Dieses geschieht mit Hilfe der Ressourceninformationen, die die NCs an den CC übermitteln. Eine weitere Aufgabe eines CC ist die Steuerung des privaten Netzwerks, über das der CC mit den NCs kommuniziert. Jeder CC sendet Informationen über den aktuellen Zustand der Ressourcen im eigenen Cluster. Für das Meta-Scheduling, also die Verteilung der virtuellen Maschinen zwischen den verbunden Clustern ist der CLC zuständig. Hierfür sammelt er die Ressourceninformationen, die die CCs an den CLC übermitteln. In jeder EucalyptusInfrastruktur muss exakt ein CLC aktiv sein. Der CLC ist der Zugriffspunkt in der Cloud, sowohl für die Anwender als auch für die Administratoren. Bei Eucalyptus-Infrastrukturen mit einer geringen Anzahl an physischen Servern, bietet es sich an, CLC und CC auf einem Server zu konsolidieren. Es ist notfalls auch möglich, alle drei Komponenten auf einem physischen Server zu betreiben. Zusätzlich enthält Eucalyptus zwei Speicherdienste: Walrus ist ein Speicherdienst für Web-Objekte, der kompatibel zur REST API von Amazon S3 ist. Zusätzlich existiert ein Speicherdienst mit der Bezeichnung Storage Controller (SC), dessen Funktionalität und API mit dem Dienst Amazon EBS identisch sind. Walrus und der SC können auf beliebigen Rechnern im Cluster ausgeführt werden. Eine Positionierung von Walrus und SC auf dem CLC ist bei kleineren und mittleren Installationen üblich.

6.2 Eucalyptus

97

Eucalyptus verwendet Walrus, um die Images abzulegen. Es ist darüber hinaus auch möglich, Walrus als eigenständigen Dienst unabhängig von Eucalyptus zu installieren und betreiben. Virtual Distributed Ethernet (VDE) erzeugt das private Netzwerk. Auf den Eucalyptus-Komponenten läuft hierfür ein virtueller VDE-Switch. Die Verbindungen zwischen den Switches sind mit virtuellen VDE-Kabeln realisiert. Durch das virtuelle Netzwerk ist garantiert, dass den virtuellen Maschinen in der innerhalb eines Clusters in der Cloud ein einheitliches Subnetz zur Verfügung steht [3]. In einer Eucalyptus Private Cloud sind die Bezeichner der Instanzklassen zu denen von Amazon EC2 identisch. Unterschiede bestehen aber bei den standardmäßig zugewiesenen Ressourcen. Siehe hierzu Tabellen 6.1 und 6.2. Die Ressourcenzuteilung der jeweiligen Instanzklassen innerhalb einer Eucalyptus Private Cloud kann konfiguriert werden. Es ist aber nicht vorgesehen, zusätzliche Instanzklassen zu definieren oder deren Namen zu ändern. Die neuen Instanzklassen bei den Amazon Web Services (dazu gehören die High-Memory Instances m2.2xlarge, m2.2xlarge und m2.4xlarge sowie die Micro Instances t1.micro) haben bei Eucalyptus noch keinen Eingang gefunden. In einer Eucalyptus-Cloud können alle Instanzklassen auf allen Knoten platziert werden. Folglich ist auch keine Ausprägung der Instanzklassen nach Architekturen möglich, so wie es bei Amazon EC2 gehandhabt wird. Bei EC2 stehen die beiden Instanzklassen m1.small und c1.medium ausschließlich Instanzen mit einer 32-Bit Architektur zur Verfügung während alle anderen Instanzen auf der 64-Bit Architektur basieren. Eine Ausnahme bildet die Instanzklasse t1.micro. Diese kann sowohl mit 32-Bit als auch 64-Bit Instanzen verwendet werden. In einer Eucalyptus-Cloud ist im Gegensatz dazu die Architektur aller Instanzklassen identisch.

98

6 Open Source Cloud-Schichtenmodell

Tabelle 6.1 Vergleich der Rechenleistung von Instanzklassen bei Eucalyptus und Amazon EC2 Kategorie

Eucalyptus

Amazon EC2

t1.micro m1.small m1.large m1.xlarge m2.xlarge m2.2xlarge m2.4xlarge c1.medium c1.xlarge cc1.4xlarge cg1.4xlarge

n.v. 1 virt. CPU 2 virt. CPUs 2 virt. CPUs n.v. n.v. n.v. 1 virt. CPU 4 virt. CPUs n.v. n.v.

1 virt. Core mit maximal 2 ECU 1 virt. Core mit 1 ECU 2 virt. Cores je 2 ECU ⇒ 4 ECU 4 virt. Cores je 2 ECU ⇒ 8 ECU 2 virt. Cores je 3,25 ECU ⇒ 6,5 ECU 4 virt. Cores je 3,25 ECU ⇒ 13 ECU 8 virt. Cores je 3,25 ECU ⇒ 26 ECU 2 virt. Cores je 2,5 ECU ⇒ 5 ECU 8 virt. Cores je 2,5 ECU ⇒ 20 ECU 8 Intel Xeon Nehalem Cores ⇒ 33.5 ECU 8 Intel Xeon Nehalem Cores ⇒ 33.5 ECU

Ein weiterer Unterschied zwischen Amazon Web Services und Eucalyptus betrifft die Leistungsfähigkeit der angebotenen CPU-Cores. Amazon verwendet bei der Definition der Rechenleistung die Metrik EC2 Compute Units (ECU). Eine EC2 Compute Unit ist bezüglich Rechenleistung vergleichbar mit einem 1,0–1,2 GHz Opteron oder Xeon aus dem Jahr 2007 oder mit einem 1,7 GHz Xeon Prozessor vom Frühjahr 2006 [42]. Bei den Amazon Web Services besitzen die virtuellen CPUCores bezüglich der verwendeten Instanzklasse eine unterschiedliche Leistungsfähigkeit. Dies ist darauf zurückzuführen, dass Amazon für das Provisionieren in den verschiedenen Instanzklassen unterschiedliche physische Hardware vorhält. Während in EC2 bei der Instanzklasse m1.small die Rechenleistung eines virtuellen CPU-Cores einer EC2 Compute Unit entspricht, hat bei den übrigen Standard Instanzen m1.small und m1.large jeder virtuelle Core die Rechenleistung von zwei EC2 Compute Units. Bei den High-Memory Instances m2.xlarge, m2.2xlarge und m2.4xlarge be-

6.3 OpenNebula

99

Tabelle 6.2 Vergleich des Hauptspeichers der Instanzklassen bei Eucalyptus und Amazon EC2 Kategorie

Eucalyptus

t1.micro m1.small m1.large m1.xlarge m2.xlarge m2.2xlarge m2.4xlarge c1.medium c1.xlarge cc1.4xlarge cg1.4xlarge

— 128 MB RAM 512 MB RAM 1 GB RAM — — — 256 MB RAM 2 GB RAM — —

Amazon EC2 613 MB RAM 1,7 GB RAM 7,5 GB RAM 15 GB RAM 17,1 GB RAM 34,2 GB RAM 68,4 GB RAM 1,7 GB RAM 7 GB RAM 23 GB RAM 22 GB RAM

sitzt jeder virtuelle Core die Rechenleistung von 3,25 EC2 Compute Units und bei den High-CPU Instances c1.medium und c1.xlarge 2,5 EC2 Compute Units. Die Cluster Compute Instanzen verfügen über je zwei Quad-Core Intel Xeon-X5570 Nehalem Prozessoren.

6.3 OpenNebula OpenNebula [114] ist ebenso wie Eucalyptus eine IaaS-Lösung zur Konstruktion einer Private Cloud. Als Virtualisierungsansätze werden der Xen Hypervisor, KVM und VMware vSphere unterstützt. OpenNebula ermöglicht es im Gegensatz zu Eucalyptus, Instanzen auf den angeschlossenen Knoten im laufenden Betrieb zu verschieben. In OpenNebula ist allerdings bislang nur eine rudimentäre Unterstützung für die EC2 SOAP und EC2 Query API integriert. Es ist möglich, eine Liste der Images und Instan-

100

6 Open Source Cloud-Schichtenmodell

zen auszugeben, sowie Instanzen zu starten, neu starten und beenden. Es besteht ferner die Möglichkeit, Ressourcen in Amazon EC2 über OpenNebula zu steuern. Ein Alleinstellungsmerkmal von OpenNebula ist die Möglichkeit, Knoten zu gruppieren. Somit wird der Aufbau von Hochleistungsrechnen als Dienst – High Performance Computing as a Service (HPCaaS) – ermöglicht. Im Gegensatz zu Eucalyptus und Nimbus enthält OpenNebula keinen zur API von S3 oder EBS kompatiblen Speicherdienst. OpenNebula ist unter einer Open Source Lizenz verfügbar.

6.4 Nimbus Nimbus [17] ist eine Private Cloud IaaS-Lösung, die von der Globus Alliance entwickelt wird. Als Virtualisierungslösungen unterstützt Nimbus den Xen Hypervisor und KVM. Für das Scheduling der virtuellen Maschinen kann Nimbus auf Systeme wie das Portable Batch System (PBS) oder die Sun Grid Engine (SGE) zurückgreifen. In Nimbus ist eine rudimentäre Unterstützung für die EC2 SOAP und EC2 Query API integriert. Benutzer können damit eine Liste der Images und Instanzen ausgeben lassen. Instanzen können gestartet, neu gestartet und beendet werden. Es ist auch möglich, Schlüsselpaare zu erzeugen. Es ist möglich, über ein Backend Ressourcen der Amazon Web Services anzusprechen. Seit Version 2.5 enthält Nimbus den Speicherdienst Cumulus, dessen Schnittstelle zur S3 REST API kompatibel ist. Nimbus verwendet Cumulus, um die Images abzulegen. Es ist möglich Cumulus separat ohne Nimbus zu installieren und zu betreiben. Einen zu EBS kompatiblen Speicherdienst enthält Nimbus nicht. Nimbus ist unter einer Open Source Lizenz verfügbar.

Apache v2.0

Apache v2.0

Nimbus

OpenStack

Apache v2.0

OpenNebula

GPL v3

GPL v3

Eucalyptus

CloudStack

Lizenz

Name

OpenStack, AWS

CloudStack, AWS

WSRF, AWS

OCCI, AWS

AWS

Schnittstelle

ja

teilweise

teilweise

teilweise

ja

EC2

nein

nein

teilweise

nein

ja

S3

Tabelle 6.3 Vergleich der quelloffenen Virtuellen Ressourcen Sets

nein

nein

nein

nein

ja

EBS

VirtualBox, UML

KVM, Xen,

VMware

KVM, Xen,

KVM, Xen

VMware, VirtualBox

KVM, Xen,

VMware

KVM, Xen,

Hypervisor

nein

ja

nein

nein

ja

Enterprise

6.4 Nimbus 101

102

6 Open Source Cloud-Schichtenmodell

6.5 CloudStack Eine weitere Private Cloud IaaS Lösung ist CloudStack [65], eine Entwicklung des Unternehmens Cloud.com in Zusammenarbeit mit Rackspace. Als Virtualisierungsansätze werden der Xen Hypervisor, KVM und VMware vSphere unterstützt. Die Architektur umfasst zwei Komponenten, den Management-Server und die Rechenknoten (engl. Compute-Nodes). Der ManagementServer stellt den Administratoren und Benutzern eine WebOberfläche zur Verfügung. Weitere Aufgaben des ManagementServers sind die Steuerung und das Management der Ressourcen bei der Verteilung der Instanzen auf die Rechenknoten. Die Software existiert in einer Community Version, Enterprise Edition und Service Provider Edition. Ausschließlich die Community Version ist als Open Source Lizenz verfügbar. Tabelle 6.3 zeigt eine Übersicht über die bekanntesten Open Source Lösungen zur Realisierung von Virtuellen Ressourcen Sets.

6.6 OpenStack Die Nasa und Rackspace etablierten im Sommer 2010 das Open Source-Projekt OpenStack [117]. Viele namhafte Unternehmen unterstützen OpenStack, unter anderem AMD, Intel, Dell und Cloud.com. OpenStack stellt auf der Basis von CloudStack die Komponenten Compute und Object Storage bereit. Der Compute-Dienst erlaubt die Verwaltung großer Gruppen virtueller Server; der Objektspeicher stellt redundante, skalierbare Speicher zur Verfügung. Microsoft kündigte an, die Software OpenStack an die Virtualisierungstechnologie Hyper-V anzu-

6.8 typhoonAE

103

passen. Dabei ist das Ziel, in Cloud-Systemen Windows- und Open Source-Programme parallel nutzen zu können.

6.7 AppScale AppScale [58] bietet eine Re-Implementierung der Funktionalität und der Schnittstellen der Google App Engine als Open Source. Die Entwicklung erfolgt an der University of California in Santa Barbara. Zu Google App Engine kompatible Anwendungen können mit AppScale innerhalb einer Private Cloud (Eucalyptus) oder innerhalb einer Public Cloud (EC2) betrieben und getestet werden. AppScale kann auch direkt auf dem XenHypervisor ohne Zuhilfenahme einer IaaS zum Einsatz kommen. AppScale unterstützt Python- und Java-Anwendungen und emuliert die Google-Infrastrukturdienste Datastore, Memcache, XMPP, Mail und Authentifizierung.

6.8 typhoonAE TyphoonAE [133] ist eine weitere als Open Source veröffentlichte Re-Implementierung der Google App Engine. Auch hier können Entwickler zu Google App Engine kompatible Anwendungen lokal ausführen. Im Gegensatz zu AppScale harmoniert typhoonAE mit jeder Linux-Umgebung sowie mit Mac OS X. Somit ist die Verwendung nicht nur in Private und Public Clouds, sondern auch in virtuellen Maschinen möglich. Ein weiterer Unterschied zu AppScale ist, dass typhoonAE ausschließlich in Python entwickelte Anwendungen unterstützt. Die Software basiert auf dem App Engine SDK sowie populären Open Source Paketen wie NGINX, Apache2, MySQL, memca-

104

6 Open Source Cloud-Schichtenmodell

ched und RabbitMQ. Diese bilden die Basis zur Emulation der Google-Infrastruktur-Dienste.

6.9 Apache Hadoop Hadoop [31] ist eine Open Source Software-Plattform, mit der sich in einfacher Weise sehr große Datenmengen in einem Rechnerverbund verarbeiten und analysieren lassen. Mögliche Einsatzfelder von Hadoop sind z. B. Web-Indexierung, Data Mining, Logdaten-Analysen, Maschinelles Lernen, Finanzanalysen, wissenschaftliche Simulationen oder Forschung im Bereich der Bioinformatik. Das Hadoop-System besitzt die folgenden Eigenschaften: • Skalierbarkeit: Datenmengen im Umfang von mehreren Petabytes können verarbeitet werden, verteilt auf mehrere tausend Knoten eines Rechnerverbunds. • Effizienz: Parallele Datenverarbeitung erlaubt die schnelle Prozessierung auf Basis eines verteilten Dateisystems. • Zuverlässigkeit: Es können mehrere Kopien der Daten angelegt und verwaltet werden. Bei Ausfall eines Cluster-Knotens wird der Workflow selbständig neu organisiert. Dies ermöglicht eine automatische Korrektur bei Störungen. Beim Design von Hadoop steht die Skalierbarkeit zu ClusterGrößen von bis zu 10 000 Knoten im Vordergrund. Das größte Hadoop-Cluster bei Yahoo! umfasst zurzeit 32 000 Cores in 4 000 Knoten und es werden dort 16 Petabytes an Daten gespeichert und verarbeitet. Die Analyse und Sortierung eines ein Petabyte großen Datensatzes dauert auf diesem Cluster etwa 16 Stunden.

6.9 Apache Hadoop

105

Die Firma Cloudera paketiert das Hadoop-System und es stehen verschiedene Hadoop-Distributionen im Internet als Download bereit [64].

6.9.1 MapReduce Hadoop implementiert das MapReduce-Programmiermodell, das auch in der Suchmaschine und den Anwendungen von Google eine große Rolle spielt [11]. Obwohl das Modell auf der massiv parallelen Verarbeitung von Daten aufsetzt, hat es funktionale Wurzeln. Es sind prinzipiell zwei Funktionen zu implementieren: • Map-Funktion: Liest Schlüssel/Wert-Paare ein und generiert daraus in der Ausgabe als Zwischenergebnis jeweils neue Schlüssel/Wert-Paare.

Compute Cluster HDFS Block 1

Data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data

HDFS Block 1

Map HDFS Block 1

Data

HDFS Block 2

Map HDFS Block 2

Reduce

HDFS Block 2

Map

data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data

HDFS Block 3 HDFS Block 3 HDFS Block 3

Abb. 6.4 MapReduce-Programmiermodell auf der Basis eines verteilten Dateisystems (HDFS)

106

6 Open Source Cloud-Schichtenmodell

• Reduce-Funktion: Liest alle Zwischenergebnisse, gruppiert diese nach Schlüsseln und generiert daraus jeweils eine aggregierte Ausgabe für jeden Schlüssel. Üblicherweise speichern die Prozeduren dabei die Ergebnisse der einzelnen Schritte in Listen oder Warteschlangen. Als Beispiel möge das Erfassen des Wortschatzes in einer Sammlung von Texten dienen (siehe auch Beispiel im Anhang): Die Map-Funktion extrahiert hier die einzelnen Wörter aus den Texten, die Reduce-Funktion liest diese ein, zählt das Auftreten der Wörter und legt das Ergebnis in einer Liste ab. Bei der Parallelverarbeitung verteilt Hadoop die Texte oder Textfragmente auf die Knoten eines Rechnerverbunds. Die Map-Knoten verarbeiten die ihnen zugeteilten Fragmente und geben jeweils die einzelnen Wörter aus. Diese Ausgaben stehen über ein verteiltes Dateisystem allen Knoten zur Verfügung. Die Reduce-Knoten lesen anschließend die Wortlisten ein und zählen die Wörter. Da das Zählen erst dann beginnen kann, sobald alle Wörter durch die Map-Funktion verarbeitet sind, kann hier ein Engpass entstehen. Der Ablauf von MapReduce in einem Hadoop-Cluster ist schematisch in Abbildung 6.4 gezeigt.

6.9.2 Hadoop Distributed File System Um die MapReduce-Funktionen robust und skalierbar zu implementieren, ist ein hochverfügbares und leistungsfähiges Dateisystem nötig. Hadoop verwendet zur Verarbeitung der Daten ein spezielles verteiltes Dateisystem, das Hadoop Distributed File System (HDFS). Die Architektur basiert auf einem Masterknoten (Namenode), der eine große Zahl von Datenknoten verwaltet. Der Masterknoten bearbeitet externe Datenanfragen, organisiert die Ablage von Dateien und speichert alle Metadaten zur Be-

6.9 Apache Hadoop

107

schreibung des Systemstatus. Die Zahl der Dateien, die man im HDFS ablegen kann, ist in der Praxis durch die Hauptspeicherausstattung des Masterknotens limitiert, da sich aus Gründen der Performanz alle Daten im Speichercache befinden sollten. Systeme mit mehren hundert Millionen Dateien sollten mit aktueller Hardware zu realisieren sein. Hadoop splittet die Dateien und verteilt die Fragmente auf mehrere Datenblöcke im Cluster, wodurch der parallele Zugriff möglich ist. Zusätzlich legt HDFS zur Steigerung der Zuverlässigkeit und der Zugriffsgeschwindigkeit mehrfache Kopien der Datenblöcke im Rechnerverbund ab. Eine optionale Prüfsummenbildung stellt dabei die Integrität der Daten sicher: Die Feststellung einer potenziellen Datenkorruption ist dadurch möglich und ein Lesevorgang kann in diesem Fall auf einen alternativen, intakten Block umgeleitet werden. Da der Masterknoten einen Single-Point-of-Failure darstellt, ist es vorgesehen, diesen zu replizieren. Im Unterschied zu den weit verbreiteten RAID-Systemen kommt bei HDFS ein flaches Speichermodell zum Einsatz. Dies geschieht im Hinblick auf die Fehlertoleranz: Falls eine Speicherplatte ausfällt, findet die Wiederherstellung (engl. Rebuild) statt, die neue verteilte Kopien der betroffenen Blöcke anlegt. Es ist wichtig, die Wiederherstellungszeit des Systems möglichst kurz zu halten, um das Risiko eines Datenverlusts aufgrund von Mehrfachfehlern auf ein Minimum zu reduzieren. HDFS benötigt bei Ausfall einer Terabyte-Festplatte nur ca. eine halbe Stunde, um eine Wiederherstellung durchzuführen (zum Vergleich: Bei RAID kann dies systembedingt mehrere Tage dauern). Falls ein Datenknoten oder gar ein ganzes Rack ausfällt, delegiert der Masterknoten die entsprechenden Teilaufgaben sofort neu. Aufgaben werden im Verbund nach Möglichkeit immer dort ausgeführt, wo die Daten lokalisiert sind. Datenzugriffe über das Netzwerk werden aus Effizienzgründen nach Möglichkeit ver-

108

6 Open Source Cloud-Schichtenmodell

mieden. Als Kriterium dafür gibt es eine Distanzfunktion, die die Kosten des Zugriffs beschreibt: Die Distanz ist bei Zugriffen auf demselben Knoten am geringsten, vergrößert sich bei Zugriffen im selben Rack und wächst entsprechend mit dem Abstand im Netzwerk.

6.9.3 Pig Es gibt im Umfeld von Apache Hadoop eine Plattform mit dem Namen Pig [31]. Es handelt sich dabei um eine spezielle High-Level Programmierumgebung zur Formulierung von Datenanalysen (Pig Latin). Diese Umgebung ist mit einer passenden Infrastruktur zur Durchführung von Analysen gekoppelt. Pig-Programme zeichnen sich dadurch aus, dass sich ihre Struktur hervorragend zur Parallelisierung eignet. Die Plattform umfasst insbesondere auch einen Compiler, der Sequenzen von MapReduce-Programmen für Hadoop erstellt. Die Programmiersprache hat die folgenden Eigenschaften: • Einfachheit: Unterstützung von sowohl nebenläufigen als auch parallelen Anwendungen. Komplexe gekoppelte Systeme werden als Datenfluss-Sequenzen umgesetzt. • Optimierung: Die Ausführung von Aufgaben wird automatisch optimiert. Der Programmierer kann sich auf die Semantik des Programms konzentrieren. • Erweiterbarkeit: Benutzer können ihre eigenen Funktionalitäten einbringen und damit domänenspezifische Probleme lösen. Der Einsatz von Pig lohnt sich vor allem dort, wo die Stapelverarbeitung großer Datenmengen eine Rolle spielt. Pig eignet sich weniger für Umgebungen, wo nur kleine Subsets von größeren Datenmengen zu verarbeiten sind.

6.9 Apache Hadoop

109

6.9.4 Hive Hive ist eine Data-Warehouse Anwendung (zentrales Datenlager), die auf Hadoop [98] aufsetzt. Hive ermöglicht die Analyse von großen strukturierten Datensätzen im Hadoop Dateisystem auf der Basis einer Abfragesprache mit dem Namen QL. Diese ist von SQL abgeleitet und ermöglicht so die Übertragung existierender Datenbankanwendungen auf die Hadoop-Plattform. Interessant ist hier vor allem die Möglichkeit, Datenbankabfragen mit dem MapReduce-Programmiermodell zu kombinieren.

6.9.5 Hadoop as a Service Die Installation und der Betrieb eines Hadoop-Clusters sind mit einem nicht unerheblichen Aufwand verbunden, der sich u. U. bei sporadischer Nutzung nicht lohnt. Es gibt daher aktuell mehrere Ansätze, um Hadoop auch als Cloud-Dienst anzubieten. Insbesondere ist hier Amazon Elastic MapReduce [41] hervorzuheben, welches als Bestandteil der Amazon Web Services zur Verfügung steht. Amazon Elastic MapReduce basiert auf EC2 und kann Cluster von nahezu beliebiger Größe nach aktuellem Bedarf bereitstellen. Das verteilte Dateisystem von Hadoop arbeitet dabei mit dem S3-Service zusammen (siehe Abbildung 6.5). Der Dienst Elastic MapReduce funktioniert folgendermaßen: 1. Der Nutzer lädt seine Daten und das Map- und ReduceExecutable nach S3 2. Elastic MapReduce generiert und startet ein EC2 HadoopCluster (Master + Slaves) 3. Hadoop erzeugt einen Jobflow, der Daten von S3 aufs Cluster verteilt und prozessiert

110 1

6 Open Source Cloud-Schichtenmodell Request 2

Your host

Elastic MapReduce

Response

Master

5

Slave

3 4 Slave

Slave

Slave EC2 cluster

Abb. 6.5 Amazon Elastic MapReduce (Quelle: Amazon)

4. Die Ergebnisse werden nach dem Prozessieren nach S3 kopiert 5. Benachrichtigung am Ende des Jobs: Der Nutzer holt die Ergebnisse von S3 ab Man kann Amazon Elastic MapReduce sowohl programmatisch über die Kommandozeile steuern, als auch grafisch über eine Web-Konsole [53]. Ein Beispiel für die Verwendung von Elastic MapReduce ist im Anhang gegeben. Es gibt neben Elastic MapReduce eine weitere Möglichkeit, Hadoop als flexiblen Dienst im Rahmen der Amazon Web Services zu nutzen: Es lässt sich in der Amazon-Infrastruktur ein eigenes Hadoop-Cluster in einer dem Problem angemessenen Größe instanzieren. Dieses kann auf der Basis eines vorgefertigten Amazon Machine Images für Hadoop geschehen, welches Cloudera als Public AMI bei den Amazon Web Services bereitstellt.

6.10 Das OpenCirrusTM -Projekt

111

6.10 Das OpenCirrusTM -Projekt Das OpenCirrusTM -Projekt hat zum Ziel, ein internationales Cloud Computing Testbett zur Unterstützung der Open Source Cloud-Systemforschung aufzubauen und zu betreiben [2]. Die Firmen HP, Intel und Yahoo! haben das Projekt im Juli 2008 gestartet, zusammen mit den akademischen Partnern IDA1 , KIT2 und UIUC3 . Das Konsortium umfasst seit 2010 auch ETRI4 , MIMOS5 , RAS6 , CESGA7 , CMU8 , CERCS9 sowie China Mobile und China Telecom. Die Partner betreiben föderierte Ressourcenzentren und stellen jeweils bis zu 1024 CPU-Cores und bis zu 1 Petabyte Datenspeicher bereit. Die Aktivitäten umfassen sowohl Entwicklungen auf der Infrastrukturebene, der Plattformebene als auch auf der Anwendungsebene (siehe Kapitel 3). Im Unterschied zu anderen Cloud-Umgebungen wie Google App Engine oder Amazon Web Services gestattet OpenCirrusTM den Wissenschaftlern und Entwicklern vollen Zugriff auf alle Systemressourcen. Hierdurch ist die Weiterentwicklung des Open Source CloudSchichtenmodells möglich. Alle Nutzer des Systems müssen sich über das Portal [111] des Projekts registrieren. Im Portal sind nicht nur generelle Informationen über das Projekt verfügbar, sondern man kann dort

1 2 3 4 5 6 7 8 9

Infocom Development Authority, Singapur Karlsruhe Institute of Technology, Deutschland University of Illinois Urbana Champaign, USA Electronics and Telecommunications Research Institute, Südkorea Malaysian Institute for Microelectronic Systems, Malaysia Russian Academy of Sciences, Russland Centro de Supercomputacion Galicia, Spanien Carnegie Mellon University, USA GeorgiaTech, USA

112

6 Open Source Cloud-Schichtenmodell

auch die Nutzung von Ressourcen zur Durchführung von Forschungsarbeiten beantragen. Um ein über mehrere Standorte verteiltes Cloud-System zu betreiben, ist die Einrichtung von übergreifenden gemeinsamen Diensten erforderlich. Diese globalen Basisdienste sind • Identitätsmanagement: Das Identitätsmanagement bildet die Grundlage, alle Aktivitäten einem Benutzerprofil zuzuordnen. Es ist dabei wünschenswert, dass einheitliche Benutzerprofile bei den verteilten Standorten verfügbar sind (Single Sign-On). Dies geschieht auf der Basis der SSH PublicKey-Authentifizierung [116]. Der öffentliche Schlüssel eines RSA-Schlüsselpaars verbleibt bei der Ressource, der Nutzer überträgt den privaten Schlüssel über eine sichere Verbindung. Unter Verwendung des privaten Schlüssels kann ein Klient dann die verteilten Ressourcen ansprechen, nachdem der Betreiber am jeweiligen Standort den öffentlichen Schlüssel registriert hat. Das in OpenCirrusTM angewendete Verfahren kommt in ähnlicher Weise auch bei den Amazon Web Services zum Einsatz. • Monitoring: Die Überwachung der verteilten Ressourcen bildet als weiterer globaler Dienst die Basis für das Management der verteilten Infrastruktur und hilft bei der Lokalisierung und Behebung von Störungen. OpenCirrusTM realisiert die Überwachung mit dem Open Source-Produkt Ganglia [80]. Ganglia erhebt die Informationen über den Zustand und die Nutzung von Ressourcen für jede Komponente und führt sie hierarchisch zusammen. Die Betreiber installieren zu diesem Zweck einen Dämonprozess, der den Ressourcenstatus und die zugehörigen Informationen als XML-Streams an einen zentralen Web-Server weiterleitet, der diese sammelt und konsolidiert [112]. Ausgehend von dieser Grundlage steht die Entwicklung und Einführung weiterer globaler Dienste an: Es handelt sich hier um

6.10 Das OpenCirrusTM -Projekt

113

Dienste für die gemeinsame Datenhaltung und die verteilte Anwendungsentwicklung. Die Partner betreiben im Projekt die Weiterentwicklung der zuvor diskutierten Open Source-Komponenten wie PRS, VRS, Hadoop und Tashi. Es ist ein weiteres Ziel, offene Probleme der Cloud-Systemforschung anzugehen wie z. B. • • • •

Standardisierung von Schnittstellen Sicherheitstechniken Dynamische Verlagerung von Arbeitslasten (Cloud Bursting) Umsetzung von Dienstgütevereinbarungen (Service Level Agreements)

Es ist insbesondere möglich, in der Testumgebung groß angelegte Skalierungstests durchzuführen und neue Cloud-Anwendungsbereiche zu erschließen. So untersucht man im KIT den Einsatz von Cloud-Techniken im Umfeld des Hochleistungsrechnens. Hier ist die Idee, die dynamischen Eigenschaften des Cloud Computing auch bei der Bearbeitung rechenintensiver paralleler Anwendungen zu nutzen und einen entsprechenden elastischen Dienst zu entwerfen (High Performance Computing as a Service, HPCaaS). Die besondere Herausforderung im Systembereich besteht bei der Bereitstellung von Ensembles eng gekoppelter CPU-Ressourcen sowie bei der Virtualisierung der Hochgeschwindigkeitsvernetzung auf der Basis von Infiniband. Auf der Seite der Plattform sind die folgenden Fragestellungen zu bearbeiten: • Entwicklung eines Scheduling-Dienstes • Entwicklung von MPI-Diensten • Management von Software-Lizenzen Weiterführende Informationen über OpenCirrusTM finden sich auf der Homepage des Projekts [111].

Kapitel 7

Wirtschaftliche Betrachtungen

Als entscheidender Erfolgsfaktor für das Cloud Computing wird oft dessen wirtschaftliche Bedeutung angeführt. Mit Cloud Computing wird das Potenzial verbunden, die individuelle Nutzung bzw. Bereitstellung von IT-Ressourcen in einzelnen Unternehmen als auch die IT-Industrie in ihrer Gesamtheit grundlegend und nachhaltig zu verändern. Drastische Zeitersparnisse und geringere Risiken und Hürden in der Einführung neuer Anwendungen, sowie signifikante Kostenersparnisse allgemein in der Durchführung von IT-Projekten, werden dabei oft als die wesentlichen Vorteile des Cloud Computing benannt. Dieses Kapitel vermittelt einen Überblick über Anwendungen des Cloud Computing und die damit verbundenen ökonomischen Aspekte und Fragestellungen.

7.1 Anwendungsgebiete Frühe Anwendungen des Cloud Computing waren Web-Anwendungen, die Unternehmen mit begrenzter IT-Infrastruktur entwiC. Baun et al., Cloud Computing, 2. Aufl., Informatik im Fokus, DOI 10.1007/978-3-642-18436-9_7, c Springer-Verlag Berlin Heidelberg 2011 

115

116

7 Wirtschaftliche Betrachtungen

ckelten. Prominente Beispiele hierfür sind das TimesMachineProjekt der New York Times [107] oder die Videodienste der Firma Animoto [55]. In beiden Fällen kamen öffentliche CloudDienste zum Einsatz, um über eine flexibel skalierbare Infrastruktur mit geringen Einstiegshürden zu geringen Kosten zu verfügen. Das Projekt TimesMachine war motiviert durch die Aufgabe, sechs Millionen Artikel des Archivs der New York Times als PDF-Dateien Lesern im Web zur Verfügung zu stellen. Konventionelle Ansätze zur Generierung der PDF-Dateien aus den Scans der Artikel im TIFF-Format erwiesen sich als sehr zeitund kostenaufwändig; bei einem Volumen von vier Terabyte an Daten wären neue Server anzuschaffen gewesen und das Projekt hätte mehrere Monate in Anspruch genommen. Stattdessen konnte unter Nutzung öffentlicher Cloud-Dienste der gesamte Artikelbestand in nur drei Tagen zu einem Bruchteil der Kosten realisiert werden. Im Fall von Animoto wurden Cloud-Dienste zur Bewältigung von einer unerwartet hohen Nachfrage durch Endnutzer eingesetzt. Animoto bietet Videodienste über das Web an; Endnutzer erhalten nach Hochladen von Musik- und Bilddateien ein animiertes Video. Nach einer Vernetzung von Animoto mit dem sozialen Netzwerk Facebook.com erfuhr Animoto einen unerwartet schnellen, dramatischen Anwuchs in der Nachfrage: stündlich registrierten sich bis zu 25 000 neue Nutzer, und binnen kurzer Zeit gab es bereits mehr als 250 000 neue Nutzer. Zur Bewältigung der Nachfrage an Videodiensten war in etwa das 100-fache der zuvor genutzten IT-Infrastruktur nötig: 3 500 Server mussten in nur drei Tagen hinzugefügt werden. Um solche Anfragen überhaupt und zudem zeitnah zu bedienen wurde der Einsatz öffentlicher Cloud-Dienste nötig. Auch ging die Nachfrage später zurück, und die Nutzung der Cloud-Dienste konnte entsprechend einfach und kostengünstig heruntergefahren werden.

7.2 Bewertungsmodelle

117

Die Frage, ob sich Cloud Computing für ein Unternehmen bzw. für eine Anwendung lohnt oder nicht, kann nicht pauschal beantwortet werden, sondern muss in Abhängigkeit der Eigenschaften und Ziele der Anwendungen untersucht werden. Die Beispiele TimesMachine und Animoto beschreiben zwei unterschiedliche Anwendungsklassen: Bei TimesMachine handelt es sich um einen einmaligen Batch-Job; bei Animoto handelt es sich um ein kontinuierliches, aber dynamisch variables Nachfrageverhalten. In beiden Fällen sind enorme Skalierungsbedürfnisse vorhanden, und die Aufgaben lassen sich in beiden Fällen sehr gut parallelisieren. Grundsätzlich sind Cloud-Angebote nicht auf bestimmte Anwendungen beschränkt. Im Prinzip lässt sich jede Anwendung in einer Cloud-Umgebung ausführen bzw. mit Cloud-Diensten kombinieren. Die Gründe für eine Nutzung variieren entsprechend; von einmaligen, temporären Bedürfnissen über die (auch regelmäßige) Abwicklung von schwer vorhersagbaren (u. U. extremen) Lastspitzen bis hin zum Management saisonaler Nachfrage-Effekte oder auch das Outsourcing von Funktionalität und Diensten an Dritte allgemein. Cloud-Dienste können dabei sowohl für Testzwecke als auch für Produktionsumgebungen sinnvoll sein. Die Nutzung einer oder mehrerer Cloud-Dienste kann dabei für den Endnutzer durch ein Unternehmen verborgen sein, wie im Fall von Animoto, oder auch direkt sichtbar sein, wie im Fall von Office-Anwendungen im Web.

7.2 Bewertungsmodelle Durch die dynamische Anpassung von IT-Ressourcen im Cloud Computing und einer verbrauchsabhängigen Abrechnung der Ressourcen können Fixkosten reduziert und in operative Kosten umgewandelt werden. Nutzungsabhängige Abrechnungsmodel-

118

7 Wirtschaftliche Betrachtungen

le (pay as you go) basieren auf der zeitverteilten, tatsächlichen Nutzung von Ressourcen. Dies steht im Gegensatz zu einem Anschaffungs- oder Leasing-Modell, wo Ressourcen auf Dauer gekauft bzw. über einen fixen Zeitraum (der Vertragslaufzeit) angemietet und abgerechnet werden, unabhängig von der tatsächlichen Nutzung. Der Vorteil nutzungsabhängiger Abrechnungsmodelle liegt in der damit verbundenen Elastizität (aus Anwendungs- und aus Unternehmenssicht) und Reduzierung des Risikos, zu viele Ressourcen zur Verfügung zu haben (overprovisioning) und nicht ausreichend zu nutzen (underutilization) bzw. zu wenige Ressourcen zur Verfügung zu haben (underprovisioning) und erhöhte Lasten nicht bedienen zu können (saturation). Elastizität beschreibt die Eigenschaft, Ressourcen feingranular und in sehr kurzen Zeitspannen von Minuten (und nicht Wochen oder Monaten) hinzuzufügen bzw. zu entfernen, und somit den tatsächlichen Bedürfnissen einer Anwendung besser gerecht zu werden. In der Praxis ist overprovisioning und underutilization in Rechenzentren der Regelfall und eine optimale Auslastung ist kaum möglich. Ein unerwartet hoher zusätzlicher Bedarf an Ressourcen kann dennoch nicht zügig unterstützt werden, und der umgekehrte Fall eines unerwarteten Rückgangs des Bedarfs erhöht nur den Grad der underutilization. Die finanziellen Folgen sind nicht unerheblich. Hinzu kommt, dass der Ressourcenbedarf oft nicht verlässlich vorhersagbar und planbar ist. Viele Anwendungen im modernen elektronischen Handel (engl. e-Commerce) erleben einen stark schwankenden Bedarf, der nicht nur saisonal bedingt ist, sondern auch durch temporäre Trends und Effekte (beispielsweise ausgelöst durch soziale Netzwerke) bedeutend beeinflusst werden kann.

7.2 Bewertungsmodelle

119

7.2.1 Kostenmodelle Für die Bewertung von Cloud-Diensten aus wirtschaftlicher Sicht können Kostenmodelle genutzt werden. Vergleichende Kostenrechnungen stellen dabei die Kosten der tatsächlichen Nutzung von Cloud-Angeboten (z. B. in Stunden und ServerEinheiten) den Kosten eines Rechenzentrums (bzw. einer ITInfrastruktur, die selbst angeschafft und gewartet wird) gegenüber. Ein sehr einfaches Modell wird von [1] vorgeschlagen: hier werden die Kosten eines Cloud-Dienstes mit den Kosten eines Rechenzentrums verglichen, wobei die durchschnittliche Auslastung des Rechenzentrums faktorisiert wird und die Annahme besteht, dass der Ertrag des Kunden proportional zu der Anzahl der jeweils genutzten Stunden ist. Dabei ist zu beachten, dass ein Rechenzentrum immer eine fixe Kapazität besitzt, wogegen (öffentliche) Cloud-Dienste theoretisch eine nach oben offene Kapazitätsgrenze aufweisen. Die Kosten für ein Rechenzentrum sind vielfältig, da neben den Anschaffungskosten für Rechner auch operative Kosten wie Energie (insbesondere für die Kühlung der Rechner), Mietund Grundstückskosten, oder auch Personalkosten für die Systemadministration berücksichtigt werden müssen. Dabei sind es vor allem die Energiekosten, die den größten Anteil an den Total Cost of Ownership (TCO) ausmachen. Eine effektive Nutzung von Energie ist in großen Rechenzentren leichter möglich als in kleinen. Große Rechenzentren können durch geringere Einkaufspreise für Energie oder auch durch Verteilung und Auslagerung in Gegenden mit geringeren Energiekosten deutliche Kosteneinsparungen realisieren. Sie haben außerdem den Vorteil, deutlich geringere Einkaufspreise für Hardware zu erzielen und hohe Investitionskosten beispielsweise für Ausfall- und Datensicherheit tätigen zu können. Ei-

120

7 Wirtschaftliche Betrachtungen

ne Studie von Microsoft sieht dementsprechend für kleine Rechenzentren einzelner Unternehmen Nachteile und prognostiziert langfristig eine zunehmende Entwicklung hin zur multimandantenbasierten Nutzung sehr großer Rechenzentren [104]. Derzeit entstehen weltweit Rechenzentren von bisher unerreichter Größenordnung, die enorm große Flächen belegen und Investitionen von mehreren hunderten von Millionen US-Dollar darstellen. Globale Rechenzentren werden mehr als 100 000 Server umfassen und können so die TCO pro Server dramatisch senken. Für Organisationen mit einer Anzahl von weniger als 100 Servern, so die Studie, werden sich die Kosten nicht rechnen. Für Organisationen mit ca. 1 000 Servern werden die Kosten für eine private Cloud im Vergleich zur Nutzung einer öffentlichen Cloud in ca. 10-facher Höhe liegen. Auch für den Konsumenten bedarf die Berechnung der Kosten für einen Cloud-Dienst einer genaueren Betrachtung. Aktuelle Cloud-Angebote unterscheiden beispielsweise Kosten für die Bereitstellung der Rechen- oder Speichereinheit (im Fall von IaaS) von Kosten für die Interaktion mit den Ressourcen, d. h. der Anzahl der Aufrufe oder der Größe der Daten, die über das Internet transferiert werden. Die Bestimmung der Kosten ist demzufolge sehr von den Eigenschaften und Anforderungen der Anwendung abhängig.

7.2.2 TCO Framework Aktuell wird in Praxis und anwendungsorientierter Forschung an eine Reihe von Kostenrechnungsmodellen und Entscheidungsunterstützungssystemen gearbeitet. Ein Beispiel für ein speziell für das Cloud Computing entwickeltes TCO (Total Cost of Ownership) Framework wird in [18] vorgestellt. Ausgehend von einer qualitativen Analyse der Anwendung (business scenario)

7.3 Geschäftsmodelle

121

wird eine quantitative Kostenanalyse im zweiten Schritt durchgeführt, die die Kosten eines Cloud-Dienstes den Kosten einer Referenzarchitektur gegenüberstellt und über einen Vergleich der Opportunitätskosten zu einer Bewertung kommt. Abbildung 7.1 illustriert die verschiedenen Schritte zur Kostenbestimmung, die jeweils durch entsprechende Werkzeuge unterstützt werden können. Zuerst wird ein Modell der Anwendung mit allen relevanten Anforderungen und Eigenschaften erstellt. Die qualitativen Anforderungen und Eigenschaften werden später für die Auswahl und Gewichtung von Faktoren in der quantitativen Kostenanalyse genutzt. Als einfachstes Werkzeug kann eine Matrix erstellt werden, die verfügbare Cloud-Dienste und alternative Architekturen in den Reihen, und die verschiedenen Anforderungen und Eigenschaften in den Spalten aufführt. Die Matrix kann dann wie ein Fragenkatalog (bzw. eine Checkliste) evaluiert werden. In [21] wird der Gedanke weiterentwickelt hin zu einem Entscheidungsunterstützungssystem, das Konsumenten hilft, verschiedene Kriterien, Anforderungen und Präferenzen unterschiedlicher Natur, von technischen, ökonomischen oder auch rechtlichen Aspekten, miteinander systematisch in Beziehung zu setzen und so schrittweise über die Nutzung bzw. Ablehnung eines Cloud-Angebotes zu entscheiden.

7.3 Geschäftsmodelle Im Cloud Computing sind neue Geschäftsmodelle zu beobachten, die je nach Platzierung der Dienstangebote im Cloud Computing Schichtenmodell variieren. Dabei spielt die Dynamik des Internet als eine sich kontinuierliche verändernde Technologie-, Geschäfts- und Kollaborationsplattform eine zentrale Rolle. Die Akzeptanz und Popularität des Internets in allen

122

Abb. 7.1 TCO Framework

7 Wirtschaftliche Betrachtungen

7.3 Geschäftsmodelle

123

Aspekten des Lebens und der Wirtschaft führt zu vielen neuartigen IT-basierten Diensten in einer Dienstleistungsgesellschaft. Im IaaS-Bereich erlauben offene Cloud-Architekturen beispielsweise das Zuschalten einer Menge von Diensten von Drittanbietern und bilden damit die Basis eines Ökosystems von Mehrwert bietenden Anbietern, zum Beispiel für die Überwachung (engl. Monitoring) und Management von CloudAnwendungen. Hier sind Markt- und Geschäftsmodelle im Kontext der Kombination von Cloud-Diensten unterschiedlicher Anbieter zu beobachten. Im PaaS und SaaS-Bereich dagegen finden sich oft auch Geschäftsmodelle, die vor allem durch einen einzelnen Anbieter geprägt sind. Software-plus-Services-Strategien, wie beispielsweise durch Microsoft verfolgt, verbinden das klassische Lizenzbasierte Software-Geschäft mit der Flexibilität und den Vorteilen von Cloud-Diensten im Internet. So lassen sich zum einen on-premise Software-Produkte um Dienste im Internet ergänzen, oder auch ganzheitlich durch on-demand Lösungen ersetzen.

Kapitel 8

Chancen und Risiken

Cloud Computing ist ein sehr junges und dynamisches Gebiet, das durch eine sehr aktive Industrie geprägt wird. Sowohl auf Anbieterseite als auch auf Konsumentenseite beschäftigt sich heute so gut wie jedes Unternehmen und auch der öffentliche Sektor mit Cloud Computing. Insbesondere US-amerikanische Firmen wie Amazon, Google oder Microsoft prägen derzeit den Markt von Cloud-Diensten. Aber auch viele kleinere Unternehmen entwickeln ein großes Engagement auf diesem Gebiet. Cloud Computing ist ohne Zweifel eine Disruptive Technology und hat das Potenzial, unser Verständnis über die Bereitstellung und die Nutzung von IT-Diensten grundlegend und nachhaltig zu ändern, in der Wirkung womöglich vergleichbar mit der Einführung des Personalcomputers vor 25 Jahren.

8.1 Marktentwicklung Ein reichhaltiges Ökosystem von Cloud-Diensten und Anbietern existiert bereits. Unterschiedlichste Dienste können C. Baun et al., Cloud Computing, 2. Aufl., Informatik im Fokus, DOI 10.1007/978-3-642-18436-9_8, c Springer-Verlag Berlin Heidelberg 2011 

125

126

8 Chancen und Risiken

entwickelt, getestet, und betrieben werden. Es handelt sich dabei einerseits um kommerzielle Angebote in Public Clouds im Bereich Infrastruktur, Plattform und Anwendung. Andererseits ist die Einrichtung von Private Clouds durch Produkte wie z. B. VMware vSphere [136] oder Open Source-Entwicklungen wie Eucalyptus [74] und Hadoop möglich. Hierdurch entsteht eine dynamische Landschaft, in der man in nicht allzu ferner Zukunft Dienste zwischen den öffentlichen und privaten Quellen transparent komponieren und orchestrieren kann. Es ergeben sich dadurch vielfältige Möglichkeiten, sowohl die Dienstgüte als auch die Kosten dynamisch zu optimieren.

8.2 Situative Bewertung Cloud Computing bietet eine Vielzahl von Chancen, birgt aber auch einige Risiken. Zum einen stellt die Vielzahl von CloudAngeboten Entwickler und Nutzer vor die schwierige Aufgabe, aus den teilweise sehr unterschiedlichen Angeboten einen passenden Dienst auszuwählen. Zum anderen existieren Bedenken im Umfeld der Sicherheit und Vertraulichkeit von Daten, sowie des Vendor-Lock-In. Hier ist zu beachten, dass durch die Verschlüsselung von Daten ein gewünschtes Maß an Sicherheit hergestellt werden kann: Verschlüsselte Daten in der Cloud sind u. U. sogar sicherer als unverschlüsselte Daten im eigenen Rechenzentrum. Im Bezug auf den Vendor-Lock-In lässt sich feststellen, dass der Zugriff auf die Daten durch entsprechende vertragliche Vereinbarungen zwischen den Geschäftspartnern geregelt werden kann. Amazon bietet z. B. entsprechende Importund Exportdienste für großvolumige Datensätze an.

Engpässe bzgl. Datentransfer Schlechte Vorhersagbarkeit der Leistungsfähigkeit (Performance) Skalierbarer persistenter Speicherplatz Fehler in großen, verteilten Systemen Schnelles Skalieren

Reputation und Haftpflicht

Software Lizenzen

4 5

9

10

a

Nutzung mehrerer Cloud-Anbieter zur Sicherstellung der Dienste-Kontinuität Standardisierung der Schnittstellen (API) Einsatz von Datenverschlüsselung, virtuellen Netzwerken (VLAN) und Firewalls. Einhaltung nationaler Gesetze durch geographische Datenhaltung Versand von Festplatten durch Dritte (z. B. FedEx, UPS)a Bessere Unterstützung virtueller Maschinen. Einsatz von Flash-Speicher Entwicklung skalierbarer Speicherplatz-Technologien Entwicklung von Debuggern für verteilte Maschinen Entwicklung automatischer Skalierungswerkzeuge, basierend auf Machine Learning. Ressourcen- und kostenbewusstes Nutzer- und Anbieterverhalten Einsatz von Dienstleistungen Dritter, wie z. B. für vertrauenswürdige Emails Nutzungsbezogene Lizenzen (Pay-for-use). Verkauf von Software und Diensten im Paket

Chancen

Dies ist bereits gängige Praxis, wie in Abschnitt 4.1 beschrieben.

Lock-In der Daten Vertraulichkeit und Nachvollziehbarkeit der Daten

2 3

6 7 8

Verfügbarkeit der Dienste

1

Risiken

Tabelle 8.1 Risiken und Chancen des Cloud Computing (Auswahl)

8.2 Situative Bewertung 127

128

8 Chancen und Risiken

Armbrust et al. [1] nennen zehn Risiken, die zugleich auch Chancen sind, für die Adoption und das Wachstum von Cloud Computing (siehe Tabelle 8.1). Die Liste beinhaltet Fragen nach der Verfügbarkeit der Dienste und anderer Qualitätseigenschaften, des Daten Lock-In und potenzieller Performanz-, Skalierbarkeit-, und Fehlerbehandlungsprobleme. Für die identifizierten Risiken sind Lösungen denkbar, auch wenn diese z. T. noch Gegenstand der aktuellen Forschung sind. Für eine weitergehende Diskussion dieser Risiken und Chancen wird auf [1] verwiesen. Bereits heute zeichnet sich ab, dass beispielsweise in Fragen der Sicherheit technologische Fortschritte erzielt werden, auch rechtliche Fragen Berücksichtigung finden, und sich zudem die Einstellung und Wahrnehmung von Konsumenten hin zu einem größeren Vertrauen in Cloud-Technologien entwickelt.

8.3 Fazit Von der ökonomischen Seite betrachtet ist Cloud Computing mittlerweile einer der stärksten Wachstumsmärkte in der ITBranche: Laut Gartner betrug der Umsatz mit Cloud-Diensten im Jahr 2009 bereits 56 Milliarden Dollar; die Analysten von Meryll Lynch sagen für 2011 weltweit sogar ein Marktvolumen von bis zu 160 Milliarden Dollar voraus. Unter diesen Umständen ist es sinnvoll, dass sich EDV-Leiter und IT-Manager weiterhin kontinuierlich mit dem innovativen Thema Cloud Computing auseinandersetzen und ihre IT-Landschaften entsprechend ertüchtigen. Cloud Computing ist und bleibt offensichtlich ein spannendes und viel versprechendes Thema. Die Autoren hoffen, dass es ihnen gelungen ist, mit diesem kleinen Kompendium einen kurz-

8.3 Fazit

129

en und prägnanten Überblick über die aktuellen Entwicklungen, Techniken und Trends zu vermitteln.

Kapitel 9

Anhang

Im vorliegenden Anhang sollen abschließend einige CloudAngebote mit ihren verfügbaren einfachen Werkzeugen praxisnah vorgestellt werden, um dem geneigten Leser einen schnellen Einstieg in erste eigene Fingerübungen in der Cloud zu ermöglichen.

9.1 Bedienung von EC2 mit den Amazon Tools Die folgenden Kommandos erklären die typischen Arbeitsschritte in EC2 mit den EC2-Kommandozeilenwerkzeugen von Amazon [43]. Zuerst muss ein Schlüsselpaar in der gewünschten Region existieren. Diese Schlüssel können jederzeit kontrolliert und wieder gelöscht werden. • Schlüsselpaar geheim in der Region eu-west-1 erzeugen ec2-add-keypair geheim --region eu-west-1 • Schlüsselpaare kontrollieren ec2-describe-keypairs --region eu-west-1 C. Baun et al., Cloud Computing, 2. Aufl., Informatik im Fokus, DOI 10.1007/978-3-642-18436-9_9, c Springer-Verlag Berlin Heidelberg 2011 

131

132

9 Anhang

• Schlüsselpaar löschen ec2-delete-keypair geheim --region eu-west-1 Für unterschiedliche Anwendungen der EC2 empfiehlt sich die Einrichtung und Nutzung eigener Sicherheitsgruppen (Security Groups). Jede dieser Sicherheitsgruppen kann unterschiedliche Firewalleinstellungen haben und so die Erfordernisse an Offenheit und Sicherheit berücksichtigen. • Sicherheitsgruppe gruppe_west mit der Beschreibung Eine neue Gruppe in der Region eu-west-1 erzeugen ec2-add-group gruppe_west --region eu-west-1 -d "Eine neue Gruppe" • Port 80 über TCP für die Sicherheitsgruppe öffnen ec2-authorize gruppe_west -P tcp -p 80 • Firewallregeln der Sicherheitsgruppe kontrollieren ec2-describe-group gruppe_west --region eu-west-1 • Sicherheitsgruppe löschen ec2-delete-group gruppe_west --region eu-west-1 Die folgenden Kommandos demonstrieren die typische Arbeit mit Images und Instanzen. Dabei handelt es sich um das Kontrollieren und Starten von Images und das Kontrollieren, Stoppen, Starten und Entfernen von Instanzen. • Alle Images in der Region eu-west-1 ausgeben, deren Besitzer Amazon selbst ist ec2-describe-images -o amazon --region eu-west-1 • Zwei Instanzen vom Image ami-13042f67 in der Region eu-west-1 in der Verfügbarkeitszone eu-west-1a

9.1 Bedienung von EC2 mit den Amazon Tools

• • • •

133

mit dem Schlüsselpaar geheim und der Instanzklasse m1.small in der Sicherheitsgruppe gruppe_west erzeugen ec2-run-instances ami-13042f67 --region eu-west-1 -z eu-west-1a -k geheim -g gruppe_west -n 2 -t m1.small Instanzen in der Region eu-west-1 kontrollieren ec2-describe-instances --region eu-west-1 Instanz i-f1e1a786 stoppen ec2-stop-instances i-f1e1a786 --region eu-west-1 Instanz starten ec2-start-instances i-f1e1a786 --region eu-west-1 Instanz entfernen ec2-terminate-instances i-f1e1a786 --region eu-west-1

Der private und der öffentliche DNS-Name jeder Instanz wird beim Start derselben dynamisch generiert. Für eine sinnvolle Nutzung der EC2-Ressourcen ist aber häufig notwendig, dass eine feste IP-Adresse zur Verfügung steht. Dieses wird von Amazon mit den elastischen IP-Adressen ermöglich. • Eine neue elastische IP-Adresse in der Region eu-west-1 erzeugen ec2-allocate-address --region eu-west-1 • Elastische IP-Adressen kontrollieren ec2-describe-addresses --region eu-west-1 • Elastische IP-Adresse 79.125.121.3 an die Instanz i-f1e1a786 anhängen ec2-associate-address 79.125.121.3

134

9 Anhang

-i i-f1e1a786 --region eu-west-1 • Elastische IP-Adresse lösen ec2-disassociate-address 79.125.121.3 --region eu-west-1 • Elastische IP-Adresse freigeben ec2-release-address 79.125.121.3 --region eu-west-1

9.2 Bedienung von EBS mit den Amazon Tools Die folgenden Kommandos aus den EC2-Kommandozeilenwerkzeugen von Amazon geben die typischen Arbeitsschritte mit EBS-Volumes wieder. Dabei handelt es sich um das Erzeugen, Kontrollieren, Anhängen, Lösen und Löschen von Volumes. • Ein 1 GB großes Volume innerhalb der Region eu-west-1 in der Verfügbarkeitszone eu-west-1b erzeugen ec2-create-volume --size 1 --region eu-west-1 -z eu-west-1b • Volumes in der Region eu-west-1 kontrollieren ec2-describe-volumes --region eu-west-1 • Volume vol-e466838d mit der Instanz i-58859c2c und der Geräte-ID /dev/sdf verknüpfen ec2-attach-volume vol-e466838d --region eu-west-1 -i i-58859c2c -d /dev/sdf • In der Instanz mit dem Volume arbeiten mkdir /mnt/ebsvolume1 yes | mkfs.ext3 /dev/sdf

9.3 Bedienung von RDS mit den Amazon Tools

135

mount /dev/sdf /mnt/ebsvolume1 umount /mnt/ebsvolume1 • Volume von der Instanz lösen ec2-detach-volume vol-e466838d --region eu-west-1 -i i-58859c2c • Volume löschen ec2-delete-volume vol-e466838d --region eu-west-1 Es besteht auch die Möglichkeit, von EBS-Volumes so genannte Snapshots zu erzeugen und diese zu einem späteren Zeitpunkt wieder in Form eines neuen Volumes nutzbar zu machen • Snapshot vom Volume vol-e466838d erzeugen ec2-create-snapshot vol-e466838d --region eu-west-1 • Status des Snapshots snap-820de2eb erfahren ec2-describe-snapshots snap-820de2eb --region eu-west-1 • Volume aus dem Snapshot erzeugen ec2-create-volume --snapshot snap-820de2eb --region eu-west-1 -z eu-west-1b

9.3 Bedienung von RDS mit den Amazon Tools Die folgenden Kommandos aus den RDS-Kommandozeilenwerkzeugen von Amazon [51] illustrieren den Umgang mit dem Relational Database Service: • Eine RDS-Instanz mit Namen mydb vom Instanztyp db.m1.large mit 20 Gigabyte Größe anlegen

136

9 Anhang

rds-create-db-instance --engine mysql5.1 --db-instance-identifier mydb --db-instance-class db.m1.large --allocated-storage 20 --master-username dbroot --master-user-password dbpass • Status der Instanz anzeigen rds-describe-db-instances • Zugriff gewähren für bestimmte IP-Adressbereiche (CIDR Notation) rds-authorize-db-security-group-ingress default --cidr-ip 0.0.0.0/0

• Man kann die RDS-Instanz nun mit Werkzeugen oder Programmen nutzen, um z.B. eine mysql-Datenbank zu importieren und dann interaktiv damit zu arbeiten mysql -h mydb.cpjgp4subzas.us-east-1.rds.amazonaws.com -u dbroot --password=dbpass

mysql>CREATE DATABASE world; mysql>USE world; mysql>SOURCE world.sql; mysql>SELECT * FROM ‘world‘. City LIMIT 0, 100;

mysql>quit • Falls mehr Speicherplatz benötigt wird, kann man die Instanz dynamisch vergrößern rds-modify-db-instance mydb --apply-immediately -s 50 • Snapshot mit Namen mySnapshot anlegen rds-create-db-snapshot mydb -s mySnapshot • Snapshot löschen rds-delete-db-snapshot mySnapshot • Instanz löschen, ohne die Daten in einem finalen Snapshot aufzubewahren rds-delete-db-instance mydb --skip-final-snapshot

9.4 Bedienung von S3 mit s3cmd

137

• Falls man die Datenbank noch einmal benötigt, sollte allerdings ein finaler Snapshot angelegt werden rds-delete-db-instance mydb --final-db-snapshot-identifier myWorldDatabase

• Von einem Snapshot kann man die Datenbank zu einem späteren Zeitpunkt wieder instanzieren rds-restore-db-instance-from-db-snapshot mydb --db-snapshot-identifier myWorldDatabase

9.4 Bedienung von S3 mit s3cmd Ein hilfreiches Werkzeug zur Arbeit mit Amazon S3 auf der Kommandozeile ist s3cmd. • Konfiguration der Zugangsdaten s3cmd --configure • Liste der eigenen Buckets ausgeben s3cmd ls • Anlegen von Buckets s3cmd mb s3://Bucket • Hochladen von Objekten in einen Bucket s3cmd put LokaleDatei s3://Bucket/EntfernteDatei • Inhalts eines Buckets auslesen s3cmd ls s3://Bucket • Herunterladen von Objekten aus einem Bucket s3cmd get s3://Bucket/EntfernteDatei LokaleDatei • Löschen von Objekten aus einem Bucket s3cmd del s3://Bucket/EntfernteDatei • Löschen eines (leeren) Buckets s3cmd rb s3://Bucket

138

9 Anhang

Die Konfiguration von s3cmd wird in der Datei .s3cfg gespeichert. Soll eine alternative Konfiguration verwendet werden, kann dieses auf der Kommandozeile mit der Option -c s3cfg.alternativ angegeben werden.

9.5 Bedienung der Google App Engine In der Google App Engine kann jeder Nutzer bis zu 10 Anwendungen haben. Auf der App Engine WebSite [83] können neue Namen für Anwendungen reserviert werden, wobei allerdings zu beachten ist, dass der Anwendungsname eindeutig sein muss, also innerhalb der App Engine nur einmal vorkommen darf. Die Anwendungen innerhalb der Google App Engine sind unter der folgenden Adresse erreichbar: http://.appspot.com Alle relevanten Informationen zu den eigenen Anwendungen hält das so genannte Dashboard [83] vor. Von jeder Anwendung können mehrere Versionen hochgeladen sein und jede dieser Versionen ist direkt erreichbar, was den Entwicklungsprozess unterstützt: http://<#>.latest..appspot.com Für die Entwicklung und den Betrieb eigener Anwendungen ist ein beliebiger Browser und das App Engine SDK [84] für Python oder Java notwendig. Das SDK ist für die Betriebssysteme Linux/UNIX, Max OS X und Windows verfügbar. Zusätzlich existiert noch das Google Plugin for Eclipse [91]. Die App Engine unterstützt ausschließlich Python 2.5 und Java 6. Die folgenden Schritte demonstrieren die Entwicklung und den Betrieb einer einfachen Python Anwendung aus der Linux Kommandozeile heraus.

9.5 Bedienung der Google App Engine

139

• Kontrolle der Versionsnummer von Python python --version • Installation des App Engine SDK unzip google_appengine_1.3.1.zip export PATH=$PATH:~/google_appengine appcfg.py -h • Verzeichnis für die Anwendung erzeugen mkdir gae-beispiel cd gae-beispiel • Konfigurationsdatei app.yaml anlegen application: gae-beispiel version: 1 api_version: 1 runtime: python

• • • • •

handlers: - url: .* script: main.py Mini-Anwendung in main.py erstellen #!/usr/bin/env python print ’Hallo Welt’ Anwendung mit dem Entwicklungs-Server im App Engine SDK starten dev_appserver.py gae-beispiel/ Anwendung im Web-Browser testen mit der URL http://localhost:8080 Anwendung in die App Engine übertragen appcfg.py --passin --email=<email> update gae-beispiel/ Logdaten der Anwendung anfordern appcfg.py --passin --email=<email> request_logs gae-beispiel/ logs.txt

140

9 Anhang

9.6 Bedienung von AppScale Die AppScale-Tools sind eine Sammlung von Ruby-Skripten, mit denen die AppScale Private Cloud PaaS gesteuert wird. • SSH-Schlüssel für die Instanzen erstellen appscale-add-keypair • Instanzen der AppScale Private Cloud starten appscale-run-instances • Status aller Instanzen kontrollieren appscale-describe-instances • Anwendung auf die Instanzen hochladen appscale-upload-app. • Administrator-Passwort setzen appscale-reset-pwd • Anwendung von den Instanzen entfernen appscale-remove-app • Instanzen der AppScale Private Cloud stoppen appscale-terminate-instances

9.7 Installation und Bedienung von Eucalyptus Die Installation von Eucalyptus ist mit Hilfe von Binärpaketen oder aus den Quellen möglich und auf den Web-Seiten [74] des Projekts detailliert beschrieben. Es empfiehlt sich, die aktuellste Version von Ubuntu Server zu verwenden, da diese bereits alle Eucalyptus-Pakete enthält und die Installation somit schnell möglich ist. Für die Steuerung der Eucalyptus CloudInfrastruktur werden die Euca2ools der Eucalyptus-Distribution installiert. Alternativ ist es auch möglich, die EC2-Kommandozeilenwerkzeuge von Amazon zu verwenden.

9.7 Installation und Bedienung von Eucalyptus

141

Von Eucalyptus erreichbare Ressourcen gibt das Kommando euca-describe-availability-zones verbose aus. Es wird die Anzahl der existierenden und der freien Ressourcen ausgegeben. fünf Kategorien virtueller Maschinen mit unterschiedlicher Leistungsfähigkeit hinsichtlich Rechenleistung, Hauptspeicher und Festplattenkapazität sind definiert. Bei den fünf Kategorien handelt es sich im Einzelnen um: • • • • •

Small Instance (m1.small) High-CPU Medium Instance (c1.medium) Large Instance (m1.large) Extra Large Instance (m1.xlarge) High-CPU Extra Large Instance (c1.xlarge)

Angezeigt werden auch die verbunden NCs und der Name des Clusters. Die Bezeichner der Kategorien sind bei Eucalyptus und Amazon EC2 identisch. Unterschiede bestehen aber bei den in den Instanzklassen zugewiesenen Ressourcen. Siehe hierzu Tabellen 6.1 und 6.2. Im Unterschied zu Amazon AWS kann die Ressourcenzuteilung innerhalb einer Eucalyptus Private Cloud in den verschiedenen Instanzklassen frei festgelegt werden. Es ist aber nicht möglich, weitere Instanzklassen zu definieren, oder deren Namen zu ändern. Um virtuelle Maschinen (Instanzen) in der Cloud zu starten, muss zuvor mindestens ein Dateisystem mit einem installierten Betriebssystem, ein Kernel und eventuell eine Ramdisk im Eucalyptus-System als Image registriert werden. Dieses geschieht mit den Kommandos euca-bundle-image, euca-upload-bundle und euca-register. Bei der Registrierung erhalten die Dateisystem/Kernel/Ramdisk Images eindeutige Bezeichner namens Eucalyptus Machine Images (emi-xxxxxxxx), Eucalyptus Kernel Images (eki-xxxxxxxx) und Eucalyptus Ramdisk Images (eri-xxxxxxxx). Eine Übersicht über die installierten

142

9 Anhang

Dateisystem/Kernel/Ramdisk Images liefert das Kommando euca-describe-images. Bevor man die virtuellen Maschinen instanziert, sollte ein Schlüsselpaar generiert werden, mit dem man später auf die Ressource zugreifen kann. Der private Schlüssel wird nach Aufruf des Kommandos euca-add-keypair zurückgegeben und zur weiteren Verwendung in einer lokalen Datei gespeichert: # euca-add-keypair mykey > mykey.private Der neue private Schlüssel wird anschließend vor unbefugten Zugriffen geschützt: # chmod 0600 mykey.private Die zur Verfügung stehenden Schlüssel können mit dem Kommando euca-describe-keypairs aufgelistet werden: # euca-describe-keypairs KEYPAIR mykey 33:da:6e:13:96:e6:f7: 3b:b7:34:a6:28:ba:2f:64:ab:83:70:ef:70

ram 384 768 1280 2048 2048

disk 4 6 10 16 16

# euca-bundle-image -i initrd.img --ramdisk true # euca-upload-bundle -b rambucket -m /tmp/initrd.img.manifest.xml # euca-register rambucket/initrd.img.manifest.xml IMAGE eri-E76C1849

Ramdisk registrieren

# euca-bundle-image -i vmlinuz --kernel true # euca-upload-bundle -b kernelbucket -m /tmp/vmlinuz.manifest.xml # euca-register kernelbucket/vmlinuz.manifest.xml IMAGE eki-803516F2

Kernel Image registrieren

# euca-describe-availability-zones verbose AVAILABILITYZONE SCC_Cloud 141.52.167.65 AVAILABILITYZONE |- vm types free / max cpu AVAILABILITYZONE |- m1.small 0026 / 0032 1 AVAILABILITYZONE |- c1.medium 0026 / 0032 1 AVAILABILITYZONE |- m1.large 0025 / 0030 1 AVAILABILITYZONE |- m1.xlarge 0022 / 0024 1 AVAILABILITYZONE |- c1.xlarge 0012 / 0015 2

Freie Ressourcen und verfügbare Kategorien von Instanzen

9.7 Installation und Bedienung von Eucalyptus 143

# euca-describe-images IMAGE emi-8D1F1369 imagebucket/ubuntu.img.manifest.xml admin available public x86_64 machine IMAGE eki-803516F2 kernelbucket/vmlinuz.manifest.xml admin available public x86_64 kernel IMAGE eri-E76C1849 rambucket/initrd.img.manifest.xml admin available public x86_64 ramdisk

Übersicht über die installierten Dateisystem/Kernel/Ramdisk Images ausgeben

# euca-bundle-image -i ubuntu.img --kernel eki-803516F2 --ramdisk eri-E76C1849 # euca-upload-bundle -b imagebucket -m /tmp/ubuntu.img.manifest.xml # euca-register imagebucket/ubuntu.img.manifest.xml IMAGE emi-8D1F1369

Betriebssystem Image (Dateisystem) registrieren

144 9 Anhang

admin emi-8D1F1369 0 SCC_Cloud admin emi-8D1F1369 0 SCC_Cloud

default 141.2.3.160 m1.small eki-803516F2 default 141.2.3.161 m1.small eki-803516F2

# euca-terminate-instances i-4901084F i-463B08BE

Beide Instanzen beenden

# euca-describe-instances RESERVATION r-3DDE07D9 INSTANCE i-4901084F running mykey 2010-09-01T13:54:28.917Z RESERVATION r-42FA0732 INSTANCE i-463B08BE running mykey 2010-09-01T13:54:28.917Z

Übersicht über die laufenden Instanzen

eri-E76C1849

141.2.3.161

eri-E76C1849

141.2.3.160

# euca-run-instances emi-8D1F1369 --kernel eki-803516F2 --ramdisk eri-E76C1849 -k mykey -n 2 -t m1.small

Zwei Instanzen starten

9.7 Installation und Bedienung von Eucalyptus 145

146

9 Anhang

Die Images werden anschließend in Form von Instanzen mit dem Kommando euca-run-instances gestartet. Sind mehr Ressourcen nötig als in der einfachsten Kategorie (m1.small) zur Verfügung stehen, kann beim Starten einfach eine höherwertige Instanzklasse gewählt werden (z. B. m1.large). Im nebenstehend gezeigten Beispiel werden zwei Instanzen des zuvor registrieren Debian 5.0 Images mit Kernel 2.6.26 und der passenden Ramdisk erzeugt. Es wird vereinbart, dass mit dem Schlüssel mykey auf die Instanzen zugegriffen werden kann. Die Instanzen können mit dem Kommando euca-describe-instances beobachtet werden. Jede Instanz hat eine IP-Adresse sowie eine eindeutige Instanznummer (i-xxxxxxxx). Man kann sich per Secure Shell mit dem beim Starten angegebenen Schlüssel direkt bei einer virtuellen Maschine anmelden: # ssh -i mykey.private 141.52.166.160 Das Kommando euca-terminate-instances beendet eine oder mehrere Instanzen. Die hier vorgestellten Kommandozeilenwerkzeuge helfen bei der Automatisierung von Aufgaben und sind eher für den Systemadministrator gedacht. Für einfachere Anwendungen gibt es auch Werkzeuge mit grafischen Nutzerschnittstellen wie z.B. ElasticFox [72].

9.8 Data Mining mit Amazon Elastic MapReduce Das MapReduce-Programmiermodell kann sehr elegant bei der Lösung von statistischen Problemen im Zusammenhang mit umfangreichen Datensammlungen eingesetzt werden. Als Beispiel möge die folgende einfache Fragestellung dienen:

9.8 Data Mining mit Amazon Elastic MapReduce

147

• Wie groß ist der Wortschatz in Goethes Faust (Teil 1 und Teil 2)? • Welches Wort kommt dort am häufigsten vor? • Wer ist der meistgenannte Akteur? Die Aufgabe soll mit der Amazon Elastic MapReduce Konsole [53] gelöst werden, wie in Kapitel 6 beschrieben. Dazu sind 3 Schritte nötig: 1. Upload Data to Amazon S3 Bucket: Zunächst werden die Goethe-Texte benötigt. Man findet diese beim GutenbergProjekt [95] und kann sie von dort als ASCII-Datei herunterladen. Die Texte müssen als Eingabe zu Amazon S3 übertragen und in einem gemeinsamen Wörterbuch (engl. Directory) gespeichert werden (z. B. mit S3Fox in /input). 2. Create a Job Flow on Amazon Elastic Map Reduce: Nach dem Drücken des Schaltfläche mit der Aufschrift Generate new Job Flow kann man die Eigenschaften des Jobs spezifizieren. • Define Job Flow: Eingabe eines Namens für den Job Flow (z. B Goethe) und • Auswahl der Word Count (Streaming) Anwendung • Specify Parameters: Lokation der Eingabe- und Ausgabe-Directory (z. B. /input, /output); Mapper: wordSplitter.py Reducer: aggregate • Configure EC2 Instances: Festlegen von Zahl und Größe der Ressourcen • Review: Kontrolle der Einstellungen Anschließend kann der Job Flow erzeugt und durchgeführt werden (Create Job Flow). Nach einigen Minuten für das Setup wird das WordCount Example mit den Goethe-Texten

148

9 Anhang

ausgeführt. Die Mapping-Funktion läuft parallel auf den spezifizierten EC2-Instanzen. Sie splittet die Texte in jeder Datei und gibt diese in Form von Listen aus. Die Wortlisten werden von den ebenfalls parallel laufenden ReducerKnoten ausgewertet und dann jeweils als Listen in dem in ausgewählten S3-Ausgabeverzeichnis abgelegt (part-00000, part-00001, . . . ). 3. Get Results from Amazon S3 Bucket: Die Ergebnisse können entweder mit einer EC2-Instanz direkt in der Amazon Cloud weiterverarbeitet werden, oder sie können auf eine lokale Maschine heruntergeladen werden. Dies funktioniert entweder mit S3Fox oder für freigegebene Dateien auch über die Kommandozeile: # wget -r http://<Bucket>.s3.amazonaws.com

Die Teilergebnisse der Reducer müssen noch zusammengefasst und alphanumerisch sortiert werden: # cat output/part-* | awk ’{print $2, $1}’ | sort -n -r > Ergebnis

Nun können die eingangs gestellten Fragen beantwortet werden: Wie groß ist der Wortschatz in Goethes Faust (Teil 1 und Teil 2)? # wc Ergebnis 13054 26108

147109 Ergebnis

Welches Wort kommt dort am häufigsten vor? # head Ergebnis 2099 und 1556 die 1514 ich 1469 der

9.8 Data Mining mit Amazon Elastic MapReduce

1004 das 975 zu 954 nicht 856 ein 850 ist 804 sich Wer ist der meistgenannte Akteur? # grep mephisto Ergebnis 471 mephistopheles 1 mephisto # grep faust Ergebnis 396 faust 5 fauste 3 fausten 2 faustus 2 faustens 1 teufelsfaust 1 raeuberfaust 1 fausts # grep gret Ergebnis 38 gretchen 3 gretchens 1 margretlein 1 gretelchen 1 gretel

149

Glossar

Amazon Online-Versandhaus und Anbieter von Web-Diensten mit starker Präsenz im Umfeld des Cloud Computing. Erreichbar unter http://www.amazon.de App Engine Programmierumgebung für die Google Infrastruktur zur Entwicklung von Web-Anwendungen in Python oder Java. AppScale Freie Private Cloud Implementierung der Google App Engine. AWS Amazon Web Services. Sammlung verschiedener CloudComputing Web-Dienste von Amazon. Azure Windows Azure Platform. PaaS von Microsoft. Cluster Gruppe eng miteinander vernetzter Computer, die gemeinsam verwaltet und genutzt werden. Cloud Bereitstellung skalierbarer IT-Services in Form von Web-Diensten mit verbrauchsabhängiger Abrechnung. Cloudera Freie, einfach zu installierende Hadoop-Distribution. C. Baun et al., Cloud Computing, 2. Aufl., Informatik im Fokus, DOI 10.1007/978-3-642-18436-9, c Springer-Verlag Berlin Heidelberg 2011 

151

152

Glossar

CloudStack Freie Private Cloud IaaS der Firma Cloud.com mit einer zu EC2 kompatiblen Schnittstelle. Cloud Gaming Dienst um High-End Videospiele auf Low-End Geräten wie Fernsehern, älteren PCs/MACs und mobilen Endgeräten wie Smart Phones unter Verwendung von Cloud Computing verfügbar zu machen. Cloud Print Drucken aus der Cloud heraus. Bei diesem Konzept der Firma Google werden Druckjobs von möglicherweise mobilen Endgeräten direkt oder über einen konvertierenden Proxy an einen Drucker im Internet gesendet. CRM Customer Relationship Management. Unterstützt die Kommunikation mit Kunden. Gewährleistet standardisierte Arbeitsvorgänge im Bezug auf Marketing, Vertrieb und Kundendienst. Crowdsourcing Siehe Humans as a Service (Huaas). Cumulus Freier Private Cloud Speicherdienst für Web-Objekte mit einer zu S3 kompatiblen Schnittstelle. Teil von Nimbus. Dienst Siehe Web-Dienst. EBS Amazon Elastic Block Store. Stellt blockorientierten Speicher für die virtuellen EC2-Server bereit. EC2 Amazon Elastic Compute Cloud. Ein Web-Dienst, der den Betrieb virtueller Instanzen auf den Servern von Amazon ermöglicht. Elastic Ressourcen können feingranular und innerhalb von Minuten hinzugefügt bzw. entfernt werden, um den tatsächlichen Bedürfnissen einer Anwendung gerecht zu werden. Emulator Funktionelle Nachbildung der kompletten Hardware eines Computer-Systems. Anwendungen oder Betriebssysteme

Glossar

153

für eine andere Hardwarearchitektur können unverändert betrieben werden. Eucalyptus Freie Implementierung der Amazon Web Services EC2, S3, EBS. Grid Technik zur Integration und gemeinsamen, ortsunabhängigen Verwendung von verteilten heterogenen Ressourcen. Google Storage Auf Web Services basierender Speicherdienst zur Speicherung von Web-Objekten. Hadoop Plattform zum Arbeiten mit datenintensiven Programmen auf der Basis von MapReduce. Apache Projekt, vorangetrieben durch Yahoo! Der Name stammt von einem gelben Spielzeugelefanten des Chef-Entwicklers Doug Cutting. Hive Data-Warehouse Anwendung (zentrales Datenlager) auf der Basis von Hadoop. HPCaaS High Performance Computing as a Service. Hochleistungsrechnen als Dienst. HuaaS Humans as a Service. Prinzip des Crowdsourcing Die menschliche Kreativität wird als Ressource angeboten. Hybrid Cloud Kombination aus Public und Private Clouds. Hypervisor Metabetriebssystem, das bei der Virtualisierung die Hardware-Ressourcen unter den Gastsystemen verteilt und die Zugriffe koordiniert. IaaS Infrastructure as a Service. Implementiert eine abstrakte Sicht auf die Hardware, um virtuelle IT-Komponenten in einer Cloud anzubieten. LaaS Landscape as a Service. Einsatz komplexer und nicht oder nur eingeschränkt mandantenfähiger Software wie SAP R3 als SaaS.

154

Glossar

(Multi-)Mandantenfähigkeit Fähigkeit, mehrere Mandanten (Kunden) auf demselben Server oder demselben SoftwareSystem zu bedienen, ohne dass die Mandaten gegenseitigen Einblick in ihre Daten und Anwendungen haben. MapReduce Programmiermodell zur parallelen Datenanalyse. Der Algorithmus wurde 2004 von Google veröffentlicht. Multi-tenancy Siehe Mandantenfähigkeit. Nimbus Freie Private Cloud IaaS mit einer zu EC2 kompatiblen Schnittstelle, die auf der Grid-Middleware Globus 4 basiert. OpenNebula Freie Private Cloud IaaS mit einer zu EC2 kompatiblen Schnittstelle. Open Source Software, deren Quelltext öffentlich zugänglich ist und die einer von der Open Source Initiative (OSI) anerkannten Open Source Lizenz unterliegt, die Weiterentwicklungen fördert. Para-Virtualisierung Virtualisierungstechnik, bei der den Gast-Betriebssystemen eine Anwendungsschnittstelle zur Verfügung steht. Eine Modifikation der Gast-Betriebssysteme ist erforderlich, da alle direkten Systemzugriffe durch den entsprechenden Aufruf der Schnittstelle zum Hypervisor ersetzt werden müssen. PaaS Platform as a Service. Virtuelle Ausführungsumgebung für Anwendungen, die es ermöglicht transparent zu skalieren. Die Abrechnung erfolgt nach Ressourcenverbrauch und Nutzungsdauer. Pig Programmierumgebung mit optimierendem Compiler für MapReduce auf Hadoop. Die zugehörige Programmiersprache ist Pig Latin.

Glossar

155

Private Cloud Cloud-Dienste werden innerhalb eines Unternehmens betrieben (inhouse). Public Cloud Cloud-Dienste werden von einem externen Cloud-Anbieter betrieben. RDS Relational Database Service. Dieser Service von Amazon ermöglicht die Einrichtung und den Betrieb einer relationalen Datenbank. REST Representational State Transfer. Architekturstil auf Basis des World Wide Webs. S3 Amazon Simple Storage Service. Auf Web Services basierender Speicherdienst zur Speicherung von Web-Objekten. SaaS Software as a Service. Software wird von einem Anbieter betrieben und kann über das Internet genutzt werden. Abrechnung erfolgt nach Nutzungsdauer. SDC Secure Data Connector. Anwendungen innerhalb der App Engine können in die eigene Infrastruktur eingebunden werden. Service Siehe Web-Dienst. SimpleDB Verteiltes Datenbanksystem in AWS, das ein einfaches relationales Datenbank-Modell bereitstellt. SLA Service Level Agreement. Vereinbarung über die Dienstgüte. SOA Service-orientierte Architektur. Eine auf Diensten basierende technische, organisatorische, und geschäftliche Architektur. SOAP Simple Object Access Protocol. Messaging Standard zur Kommunikation in vernetzten Systemen.

156

Glossar

SQS Simple Queue Service. Ein Messaging Service in AWS, der eine einfache Nachrichten-Warteschlange zur Verfügung stellt. TCO Total Cost of Ownership. Gesamtkosten eines Dienstes. typhoonAE Freie Private Cloud Implementierung der Google App Engine. URI Uniform Resource Identifier. Zeichenfolge zur einheitlichen Bezeichnung einer Ressource. Walrus Freier Private Cloud Speicherdienst für Web-Objekte mit einer zu S3 kompatiblen Schnittstelle. Teil von Eucalyptus. Web-Dienst bzw. Web-Service Ein Web Service ist ein durch einen URI eindeutige identifizierte Software-Anwendung, deren Schnittstellen als XML-Artefakte definiert, beschrieben und gefunden werden können. Ein Web Service unterstützt die direkte Interaktion mit anderen Software-Agenten durch XML-basierte Nachrichten, die über Internetprotokolle ausgetauscht werden. Virtualisierung Abstraktionsschicht zwischen Diensten und IT-Infrastruktur. VPC Virtual Private Cloud. Möglichkeit der Integration von EC2-Ressourcen innerhalb der AWS in die vorhandene ITInfrastruktur über verschlüsselte VPN-Verbindung. XML Extensible Markup Language. Standardisierte Sprache zur Darstellung hierarchisch strukturierter Informationen in Form von Textdaten.

Literaturverzeichnis

Literatur 1. Armbrust M, Fox A, Griffith R, Joseph A, Katz R, Konwinski A, Lee G, Patterson D, Rabkin A, Stoica I, and Zaharia M. Above the Clouds: A Berkeley View of Cloud Computing. Technical Report No. UCB/EECS-2009-28. Electrical Engineering and Computer Sciences. University of California at Berkeley. USA. 2009 2. Avetisyan A, Campbell R, Gupta I, Heath M, Ko S, Ganger G, Kozuch M, O’Hallaron D, Kunze M, Kwan T, Lai K, Lyons M, Milojicic D, Lee HY, Soh YC, Ming NK, Luke JY, Namgoong H. Open Cirrus: A Global Cloud Computing Testbed. IEEE Computer, Vol 43, No 4, pp. 42–50, 2010. 3. Baun C und Kunze M. Infrastrukturen für Clouds mit Eucalyptus selbst aufbauen. iX 4/2009. S.128–130. Heise Zeitschriften Verlag 4. Baun C, Kunze M und Ludwig T. Servervirtualisierung. InformatikSpektrum 3/2009. S.197–205 5. Bengel G, Baun C, Kunze M und Stucky K-U. Masterkurs Parallele und Verteilte Systeme. Grundlagen und Programmierung von Multicoreprozessoren, Multiprozessoren, Cluster und Grid. Vieweg und Teubner, Wiesbaden. 2008 6. Benslimane D, Dustdar S, and Sheth A. Services Mashups: The New Generation of Web Applications. IEEE Internet Computing.

157

158

7.

8. 9.

10. 11. 12.

13. 14.

15. 16.

17. 18.

19.

20.

Literaturverzeichnis http://dx.doi.org/10.1109/MIC.2008.110. IEEE Educational Activities Department. Piscataway. NJ. USA Berg J, Forsythe R, Nelson F, and Rietz T. Results from a dozen years of election futures markets research. Handbook of Experimental Economic Results. 2001 Carr N. The Big Switch. Rewiring the World, from Edison to Google. W.W.Norton. 2008 Chang F, Dean J, Ghemawat S, Hsieh WC, Wallach DA, Burrows M, Chandra T, Fikes A und Gruber RE. Bigtable: A Distributed Storage System for Structured Data. Symposium on Operating System Design and Implementation. 2006 Chisnall D. The Definitive Guide to the Xen Hypervisor. Prentice Hall. USA. 2008 Dean J and Ghemawat S. MapReduce: Simplified Data Processing on Large Clusters. OSDI2004. San Franzisko. 2004. DeCandia G, Hastorun D, Jampani M, Kakulapati G, Lakshman A, Pilchin A, Sivasubramanian S, Vosshall P, and Vogels W. Dynamo: Amazon’s Highly Available Key-Value Store. ACM Symposium on Operating Systems Principles. 2007 Dostal W, Jeckle M, Melzer I und Zengler B. Service-orientierte Architekturen mit Web Services. Spektrum. 2005 Dragovic B, Fraser K, Hand S, Harris T, Ho A, Pratt I, Warfield A, Barham P, and Neugebauer R. Xen and the Art of Virtualization. Proc. ACM Symposium on Operating Systems Principles. 2003 HP Integrated Lights-Out 2 User Guide. HP Hibler M, Ricci R, Stoller L, Duerig J, Guruprasad S, Stack T, Webb K, and Lepreau J. Large-scale Virtualization in the Emulab Network Testbed. Proceedings of the 2008 USENIX Annual Technical Conference. 2008 Keahey K and Freeman T. Contextualization: Providing One-Click Virtual Clusters. eScience 2008 Klems M, Nimis J, and Tai S. Do Clouds Compute? A Framework for Estimating the Value of Cloud Computing. Proc. 7th Workshop of e-Business (WeB 2008). Springer LNBIP Lai K, Rasmusson L, Adar E, Sorkin S, Zhang L, and Huberman BA. Tycoon: an Implemention of a Distributed Market-Based Resource Allocation System. Multiagent and Grid Systems. 2005 Lenk A, Sandholm T, Klems M, Nimis J, and Tai S. What’s inside the Cloud? An Architectural Map of the Cloud Landscape. ICSE 2009 Workshop on Software Engineering Challenges of Cloud Computing. 2009

Literaturverzeichnis

159

21. Menzel M, Schönherr M, Nimis J, and Tai S. (MC2 )2 : A Generic Decision-Making Framework and its Application to Cloud Computing. Proc. International Conference on Cloud Computing and Virtualization. 2010 22. Nurmi D, Wolski R, Grzegorczyk C, Obertelli G, Soman S, Youseff L, and Zagorodnov D. The Eucalyptus Open-source Cloud-computing System. Oktober 2008 23. Nurmi D, Wolski R, Grzegorczyk C, Obertelli G, Soman S, Youseff L, and Zagorodnov D. Eucalyptus: A Technical Report on an Elastic Utility Computing Archietcture Linking Your Programs to Useful Systems. August 2008 24. McKeown N, Anderson T, Balakrishnan H, Parulkar G, Peterson L, Rexford J, Shenker S, and Turner J. OpenFlow: Enabling Innovation in College Networks. 2008 25. Schäfer A. Die Kraft der schöpferischen Zerstörung. Campus. 2008 26. Sotomayor B, Montero RS, Llorente IM, and Foster I. Capacity Leasing in Cloud Systems using the OpenNebula Engine. CCA08: Cloud Computing and its Applications. 2008 27. Sprang H, Benk T, Zdrzalek J, und Dehner R. Xen. Virtualisierung unter Linux. Open Source Press. München. 2007 28. Streitberger W, Ruppel A. Cloud Computing Sicherheit - Schutzziele.Taxonomie.Marktübersicht, FhG SIT Sept. 2009 29. Varia J. Cloud Architectures, White Paper, Amazon. 2009 30. Wang L. Virtual environments for Grid computing. Universitätsverlag Karlsruhe. 2009 31. White T. Hadoop – The Definite Guide. O’Reilly Verlag. 2009 32. Wohlstadter E und Tai S. Web Services. Reference Entry. Encyclopedia of Database Systems (EDBS). Springer. 2009

Online-Quellen 33. 10gen: Scalable High Performance Data Storage for Web Applications http://www.10gen.com 34. Adobe Photoshop Express https://www.photoshop.com 35. EdgePlatform http://www.akamai.com/en/html/technology/edgeplatform.html 36. Amazon CloudFront http://aws.amazon.com/cloudfront/

160

Literaturverzeichnis

37. Amazon CloudWatch http://aws.amazon.com/cloudwatch/ 38. Amazon Cluster Compute Instances http://aws.amazon.com/ec2/hpc-applications/ 39. Amazon Elastic Block Store (EBS) http://aws.amazon.com/ebs/ 40. Amazon Elastic Compute Cloud (EC2) http://aws.amazon.com/ec2/ 41. Amazon Elastic Map Reduce http://aws.amazon.com/elasticmapreduce/ 42. Amazon EC2 Instance Types http://aws.amazon.com/ec2/instance-types/ 43. Amazon Elastic Compute Cloud. Getting Started Guide http://docs.amazonwebservices.com/AWSEC2/latest/GettingStartedGuide/

44. Amazon Mechanical Turk (MTurk) http://www.mturk.com 45. Amazon Relational Database Service http://aws.amazon.com/rds/ 46. Amazon Simple Storage Service (S3) http://aws.amazon.com/s3/ 47. Amazon SimpleDB http://aws.amazon.com/simpledb/ 48. Amazon Simple Queue Service (SQS) http://aws.amazon.com/sqs/ 49. Amazon Virtual Private Cloud (VPC) http://aws.amazon.com/vpc/ 50. Amazon Web Services (AWS) http://aws.amazon.com 51. Amazon Web Services Developer Tools http://aws.amazon.com/developertools/ 52. Amazon Web Services Import/Export http://aws.amazon.com/importexport/ 53. Amazon Web Services Management Console http://console.aws.amazon.com 54. Amazon Web Services Toolkit for Eclipse http://aws.amazon.com/eclipse/ 55. Animoto http://animoto.com 56. AppExchange http://sites.force.com/appexchange/home 57. AppNexus Cloud http://www.appnexus.com

Literaturverzeichnis

161

58. Chandra Krintz: Appscale – An open-source research framework for execution of Google AppEngine applications and investigation of scalable cloud computing fabrics http://www.cs.ucsb.edu/~ckrintz/abstracts/appscale.html 59. Azure Services Platform http://www.microsoft.com/azure/ 60. Bluelock http://www.bluelock.com 61. Project Caroline http://research.sun.com/projects/caroline 62. The Future of Corporate IT, Corporate Executive Board, 2010 http://www.executiveboard.com/it/pdf/The_Future_of_Corporate_IT.pdf 63. Cloud Hosting and Cloud Storage Performance Dashboard http://www.cloudclimate.com 64. Cloudera http://www.cloudera.com 65. CloudStack http://www.cloud.com 66. Security Guidance for Critical Areas of Focus in Cloud Computing, Cloud Security Alliance, 2009 http://www.cloudsecurityalliance.org/guidance/csaguide.pdf 67. DeveloperForce http://developer.force.com 68. Django Web Framework http://www.djangoproject.com 69. Dropbox https://www.dropbox.com 70. Eclipse http://www.eclipse.org 71. eyeOS http://www.eyeos.org 72. ElasticFox: Firefox Extension for Amazon EC2 http://sourceforge.net/projects/elasticfox/ 73. ENKI: Virtual Private Datacenters http://www.enkiconsulting.net/virtual-private-data-centers/ 74. Eucalyptus http://open.eucalyptus.com 75. Facebook Platform http://developers.facebook.com 76. FlexiScale Cloud Computing http://www.flexiscale.com

162

Literaturverzeichnis

77. fluidOps eCloudManager http://www.fluidops.com/ecloudmanager.html 78. Force.com http://www.salesforce.com/de/platform/ 79. Gaikai http://www.gaikai.com 80. Ganglia Monitoring System http://ganglia.info 81. gEclipse http://www.geclipse.org 82. GoGrid Cloud Hosting http://www.gogrid.com 83. Google App Engine http://appengine.google.com 84. Google App Engine SDK http://code.google.com/intl/de/appengine/downloads.html 85. Google Apps http://www.google.com/apps/ 86. Google Chrome OS http://www.chromium.org/chromium-os 87. Google Cloud Print http://code.google.com/apis/cloudprint/ 88. Google Docs http://docs.google.com 89. The Google File System http://labs.google.com/papers/gfs.html 90. Google Maps API http://code.google.com/apis/maps/ 91. Google Plugin for Eclipse http://code.google.com/intl/de/appengine/docs/java/tools/eclipse.html 92. Google Storage http://code.google.com/apis/storage/ 93. Gridcore Gompute http://www.gridcore.se/ondemand-com/ 94. GSUtil http://code.google.com/intl/en/apis/storage/docs/gsutil.html 95. Projekt Gutenberg http://www.gutenberg.org 96. Guardian: Investigate your MP’s expenses http://mps-expenses.guardian.co.uk 97. Hadoop Homepage http://hadoop.apache.org

Literaturverzeichnis

163

98. Hive! http://hadoop.apache.org/hive/ 99. Joyent Reasonably Smart ttp://www.joyent.com 100. JungleDisk http://www.jungledisk.com 101. KOALA http://koalacloud.appspot.com 102. KOALA Cloud Manager http://code.google.com/p/koalacloud/ 103. Microsoft Windows Live http://explore.live.com/ 104. Microsoft – The Economics of the Cloud http://www.microsoft.com/presspass/presskits/cloud/docs/TheEconomics-of-the-Cloud.pdf 105. National Institute of Standards and Technology: Cloud Computing http://csrc.nist.gov/groups/SNS/cloud-computing/ 106. NetSuite SuiteFlex http://www.netsuite.com 107. New York Times Archives + Amazon Web Services = TimesMachine http://open.blogs.nytimes.com/2008/05/21/the-new-york-timesarchives-amazon-web-services-timesmachine/ 108. Nimbus http://www.nimbusproject.org 109. Nirvanix Storage Delivery Network http://www.nirvanix.com 110. OnLive – Cloud Gaming Service http://www.onlive.com 111. OpenCirrusTM http://opencirrus.org 112. OpenCirrusTM (Global) Monitoring https://opencirrus.org/content/global-monitoring/ 113. OpenId http://www.openid.net 114. OpenNebula http://www.opennebula.org 115. OpenSocial API http://code.google.com/apis/opensocial/ 116. OpenSSH http://www.openssh.com 117. OpenStack http://www.openstack.org/

164

Literaturverzeichnis

118. Otoy http://www.otoy.com 119. Penguin Computing on Demand http://www.penguincomputing.com 120. Rackspace Managed Hosting http://www.rackspace.com 121. Michal Ludvig, s3cmd: S3-Client für die Kommandozeile http://s3tools.org/s3cmd/ 122. S3Fox Organizer(S3Fox) http://www.s3fox.net 123. Sabalcore HPC on Demand http://www.sabalcore.com 124. Salesforce Community http://www.salesforce.com/community/ 125. Salesforce CRM http://www.salesforce.com/de/crm/ 126. Thomas Sandholm, Hadoop User Group Presentation http://tycoon.hpl.hp.com/~tycoon/grid/HadoopUserGroupSept08.ppt 127. Skytab Virtual Lab http://www.skytap.com 128. SLA@SOI: Empowering the Service Industry with SLA-aware Infrastructures http://sla-at-soi.eu 129. Tashi: Cloud Computing on Big Data http://www.pittsburgh.intel-research.net/projects/tashi/ 130. Bundesministerium der Justiz; Telemediengesetz http://bundesrecht.juris.de/tmg/ 131. Terremark Infinistructure http://www.terremark.com/services/managed-hosting.aspx 132. todo flexIT http://www.todo.de/Produkte/flexIT.php 133. TyphoonAE http://code.google.com/p/typhoonae/ 134. UNIVA UD UniCloud http://www.univaud.com 135. VMware http://www.vmware.com 136. VMware vSphere http://www.vmware.com/products/vsphere/ 137. Web Services Architecture Requirements. W3C Working Draft 29 April 2002 http://www.w3.org/TR/2002/WD-wsa-reqs-20020429

Literaturverzeichnis

165

138. World Privacy Forum: Privacy in the Clouds: Risks to Privacy and Confidentiality from Cloud Computing http://www.worldprivacyforum.org 139. Ylastic http://www.ylastic.com 140. YouTube http://www.youtube.com 141. Zimory Public Cloud Marktplatz http://www.zimory.de 142. Zoho Creator http://www.zoho.com 143. ZumoDrive – Hybrid Cloud Speicher http://zumodrive.com

Sachverzeichnis

Abrechnung, 75, 92 Accounting, 75, 92 Amazon Web Services, 15, 43, 44, 77, 81, 83, 109–112 AMI, 47 Availability Zone, 47 AWS Zusammenspiel, 59 CloudFront, 45, 77 CloudWatch, 58, 77 Cluster Compute Instances, 41 EBS, 44, 49, 54, 94, 96, 134 EC2, 32, 44, 46, 77, 94, 131 EC2 Compute Unit, 50 Elastic Block Store, 49, 52, 54, 96, 134 Elastic Compute Cloud, 44, 46, 94, 131 Elastic MapReduce, 45, 77, 109, 147 Job Flow, 147 Import/Export, 45 Machine Image, 47 Management Console, 80

Management Konsole, 59, 77, 82 Mechanical Turk, 39 RDS, 57, 77, 135 Relational Database Service, 45, 57, 135 S3, 32, 44, 54, 77, 78, 94, 96, 100, 109, 137 Security Group, 48 Simple Queue Service, 55 Simple Queuing Service, 44 Simple Storage Service, 54, 78, 94, 96, 100, 137 SimpleDB, 33, 45, 56 SNS, 77 Spot Instanzen, 53 SQS, 33, 44, 55 Steuerung, 77 Storage Service, 44 Verfügbarkeitszone, 47 Virtual Private Cloud, 45, 77 Animoto, 116 AppNexus, 33 AppScale, 81, 103, 140 167

168 Auditing, 86 Auftragsdatenverarbeitung, 89 Authentizität, 85 Automatisierung, 75 Azure, 35, 66 Best Effort, 74 Betriebssystemkern, 13 Billing, 75, 92 Bioinformatik, 104 Bucket, 54, 137 Cloud Computing, 1, 6 Compliance, 88 Rechtskonformität, 88 Abrechnungsmodelle, 118 Adoption, 128 Anbieter, 2, 27, 87, 125 Angebote, 43 Anwendungsgebiete, 115 Architektur, 27 Basistechnologien, 6 Benutzer, 27 Betriebssysteme, 71 Bewertung, 126 Chancen, 125 Cloud Bursting, 113 Cloud Gaming, 70 Cloud Print, 65 Cloud Sourcing, 85, 87 Dienstanbieter, 75 Dienste, 2, 29, 41, 75, 125 Entwicklung, 83 External Cloud, 27 Geschäftsmodelle, 121 Hybrid Cloud, 29, 67 Kostenmodelle, 119 Management, 73, 76 Management-Dienste, 76 Marktentwicklung, 125 Marktplatz, 85

Sachverzeichnis Private Cloud, 3, 28, 29, 78, 80, 81, 94, 97, 99, 100, 102, 103, 126, 140, 141 Programmierung, 83 Provider, 2, 87, 125 Public Cloud, 3, 19, 27–29, 73, 78, 81, 94, 103, 126 Rechenzentren, 93 Risiken, 125 Risikomanagement, 87 Schichten, 31 Schichtenmodell, 29 Security Alliance, 86 Sicherheit, 85 Überwachung, 76 Wachstum, 128 Weitere Cloud-Dienste, 41 Wirtschaftliche Betrachtungen, 115 Cloudera, 105, 110 CloudFront, 33 CloudStack, 102 CRM, 39, 68 Cumulus, 100 Data Mining, 104 Datenanalyse, 108 Datenschutz, 88 Dienst, 1 Dienstgüte, 75 Dienstgütevereinbarung, 73 Disruptive Technology, 125 Django, 35 Dropbox, 32 EBS-Volume, 54, 134 EC2-Kommandozeilenwerkzeuge, 78, 131, 134, 140 EC2-Programmierung, 77 ElasticFox, 78, 80, 82, 146 Elastizität, 118

Sachverzeichnis Emulab, 32, 92 Ensembles, 113 Enterprise Service Bus, 22 Euca2ools, 78, 81, 82, 140 Eucalyptus, 7, 32, 34, 35, 78, 81, 94, 140 Architektur, 95 Bedienung, 140 Cloud Controller, 95 Cluster Controller, 95 Dateisystem Image, 141 Euca2ools, 78, 81, 82, 140 Infrastruktur, 95 Installation, 140 Instanzen, 146 Instanznummer, 146 Kernel Image, 141 Komponenten, 95 Node Controller, 95 Ramdisk Image, 141 Ressourcen, 141 Schlüsselpaar, 142 Storage Controller, 96 Walrus, 96 Execution Environment, 35 Extensible Markup Language, 61 External Cloud, 27 eyeOS, 71 Facebook, 116 Fehlertoleranz, 76 Finanzanalysen, 104 FlexiScale, 33 fluid Operations, 41 Force.com, 69, 70 Gaikai, 71 Ganglia, 112 Geschäftsmodelle, 121 GoGrid, 33

169 Google App Engine, 35, 43, 61, 64, 81, 87, 94, 103, 111, 138 Google Docs, 39, 62 Google Maps, 37 Google Storage, 64, 81 Google Web Toolkit, 63 GrepTheWeb, 59 Grid Computing, 5 Gridcore Gompute, 41 Grundstückskosten, 119 GSUtil, 64, 82 Hadoop, 7, 32, 104, 126 Hadoop as a Service, 109 Hadoop Distributed File System, 106 High Performance Computing, 113 Hive, 109 Hochleistungsrechnen, 113 HPCaaS, 41, 100, 113 HTTP, 24 HuaaS, 31, 39, 41 Hub-and-Spoke, 22 Humans as a Service, 31, 39 Hybrid Cloud, 29, 67 Hybridfox, 80 Hyper-V, 102 Hypercall, 15 Hypervisor, 15 IaaS, 31, 32, 37, 41, 64, 85, 87, 92 Identitätsmanagement, 112 iLO, 32, 33 Infiniband, 113 Infrastructure as a Service, 31 Integrität, 85 IOWA Electronic Markets, 40 ISO 27001, 86 IT-Servicezentrum, 4

170 Jails, 13 Joyent, 34, 35 JungleDisk, 54 Kernel-based Virtual Machine, 15, 94, 96, 99, 100, 102 Knowledge Worker, 3 KOALA, 81, 82 LaaS, 41 Lebenszyklus, 75 Linux-VServer, 14 Logdaten-Analysen, 104 Map-Funktion, 105 MapReduce, 32, 45, 77, 105, 106, 108, 146 Maschinelles Lernen, 104 Mashup, 37 Microsoft Office Live, 39 Monitoring, 112 MPI, 113 Multi-Mandantensysteme, 4, 11, 61, 69

Sachverzeichnis OpenVZ, 14 Operation Level Agreement, 74 Otoy, 71 overprovisioning, 118 PaaS, 31, 35, 37, 39, 41, 68, 85, 87, 92, 94, 123, 140 pay as you go, 118 Penguin Computing on Demand, 41 Personalcomputer, 125 Personalkosten, 119 Physisches Ressourcen Set, 32, 92, 93 Pig, 108 Platform as a Service, 31 Private Cloud, 3, 28, 29, 78, 80, 81, 94, 97, 99, 100, 102, 103, 126, 140, 141 Programming Environment, 35 Pseudonymität, 85 Public Cloud, 3, 19, 27–29, 73, 78, 81, 94, 103, 126 Quality of Service, 74

New York Times, 116 Nimbus, 32, 81, 100 OLA, 74 on-demand, 123 on-premise, 123 OnLive, 71 Open Source CloudSchichtenmodell, 91 OpenCirrusTM , 7 OpenID, 37 OpenNebula, 32, 81, 99 OpenSocial, 37 OpenStack, 102 Compute, 102 Object Storage, 102

Raubkopien, 71 RDS-Kommandozeilenwerkzeuge, 59, 135 Rechtsauffassung, 88 Reduce-Funktion, 106 Resource Set, 31 REST, 19, 21, 24, 54 s3cmd, 54, 78, 82, 137 S3Fox, 79, 82 SaaS, 18, 31, 37, 39, 41, 68, 85, 87, 92, 123 Sabalcore HPC on Demand, 41 Safe Harbor, 89

Sachverzeichnis Salesforce.com, 39, 43, 68, 69 SAS 70, 86 saturation, 118 Scheduling, 113 Service Level Agreement, 73, 113 Service Level Management, 74 Service Monitoring, 74 Service-Katalog, 75 Service-Lebenszyklus, 75 Service-orientierte Architekturen, 19 Sicherheitstechniken, 113 Single Sign-On, 112 Skalierbarkeit, 76 SLA, 73–75, 85, 87 Snapshots, 135 SOAP, 21, 24, 54 SOAP Body, 25 SOAP Envelope, 25 SOAP Header, 25 SOAP Nachricht, 25 Software as a Service, 31 Software-Lizenzen, 113 Software-plus-Services, 123 Soziale Medien, 3 Speicherdienst, 54, 78, 80, 93, 96, 100 Standardisierung, 113 Systemaufruf, 15 Systemcall, 15 Tashi, 93 Thematik, 1 TimesMachine, 116 Total Cost of Ownership, 120 Tycoon, 33 typhoonAE, 64, 81, 103 UDDI, 21 underprovisioning, 118 underutilization, 118

171 Uniform Resource Identifier, 23, 24 UNIVA UD UniCloud, 41 Utility Computing, 2 Vendor-Lock-In, 37, 87, 126 Verbrauchserfassung, 75, 92 Verfügbarkeit, 85 Verschlüsselung, 89 Vertraulichkeit, 85 Virtual Distributed Ethernet, 97 Virtual Private Cloud, 45 Virtualisierung Anwendungsvirtualisierung, 18 Betriebssystemvirtualisierung, 13 Container, 13, 14 Gast-Betriebssystem, 15 Hypercall, 15 Hypervisor, 14, 15 Nachteile, 12 Netzwerkvirtualisierung, 17 Para-Virtualisierung, 15 Plattformvirtualisierung, 14 Speichervirtualisierung, 16 Virtualisierung, 2, 6, 9, 10, 12, 14 Virtuelle Maschine, 10 VMM, 14 Vorteile, 10 Virtuelles Ressourcen Set, 32, 93 Virtuozzo, 14 VMware, 94, 99, 102 ESX, 94 vSphere, 94, 126 Volume, 54, 134 Walrus, 96 Web Protokolle, 19 Web Services, 19 Web-Indexierung, 104

172 Windows Azure, 35, 66 Active Directory, 67 App Fabric, 67 Compute, 67 Drive, 67 Queue, 67 Rolle, 67 SQL, 67 Storage, 67 wissenschaftliche Simulationen, 104 WSDL, 21, 24

Sachverzeichnis XaaS, 31 Xen, 15, 32, 94, 96, 99, 100, 102, 103 XML, 22, 23, 61 Ylastic, 80, 82 YouTube, 40 Zimory, 34, 41, 75, 85 Zumodrive, 32 Zurechenbarkeit, 85