Cloud Computing Web-basierte dynamische IT-Services

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

123

Christian Baun Dr. Marcel Kunze Karlsruhe Institute of Technology (KIT) Hermann-von-Helmoltz-Platz 1 76344 Eggenstein-Leopoldshafen [email protected] [email protected] Prof. Dr. Stefan Tai Karlsruhe Institute of Technology (KIT) & FZI Forschungszentrum Informatik Englerstr. 11 76131 Karlsruhe [email protected]

Dr. Jens Nimis FZI Forschungszentrum Informatik Haid-und-Neu-Straße 10–14 76131 Karlsruhe [email protected] Herausgeber: Prof. Dr. O. Günther Humboldt Universität zu Berlin Prof. Dr. W. Karl Universität Karlsruhe (TH) Prof. Dr. R. Lienhart Universität Augsburg Prof. Dr. K. Zeppenfeld Hochschule Hamm-Lippstadt

ISSN 1865-4452 e-ISSN 1865-4460 ISBN 978-3-642-01593-9 e-ISBN 978-3-642-01594-6 DOI 10.1007/978-3-642-01594-6 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. © Springer-Verlag Berlin Heidelberg 2010 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. Text und Abbildungen wurden mit größter Sorgfalt erarbeitet. Verlag und Autor können jedoch für eventuell verbliebene fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Satz und Herstellung: le-tex publishing services GmbH, Leipzig Einbandentwurf: KünkelLopka Werbeagentur, Heidelberg Gedruckt auf säurefreiem Papier Springer ist Teil der Fachverlagsgruppe Springer Science+Business Media (www.springer.de)

Vorwort

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

v

vi

Vorwort

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 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 Proof-Reading, sowie unseren Familien und Freunden für ihr Verständnis, die gemeinsame Freizeit wieder einmal zu opfern. Kalsruhe 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 3 4

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 . . . . . . . . . . . . . . . . .

7 7 8 10 16 17 19 21 22 23

3

Cloud-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Public, Private und Hybrid Clouds . . . . . . . . . . . 3.2 Technische Landschaft der Cloud Services . . . .

25 25 27 vii

viii

Inhaltsverzeichnis

3.3 3.4 3.5 3.6

Infrastructure as a Service . . . . . . . . . . . . . . . . . . Platform as a Service . . . . . . . . . . . . . . . . . . . . . . Software as a Service . . . . . . . . . . . . . . . . . . . . . . Human as a Service . . . . . . . . . . . . . . . . . . . . . . . .

29 33 35 37

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 Simple Queue Service (SQS) . . 4.1.4 Amazon SimpleDB . . . . . . . . . . . . . . . . . 4.1.5 Zusammenspiel der Amazon Web Services . . . . . . . . . . . . 4.2 Google App Engine . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Salesforce.com . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39 40 41 47 48 49

5

Cloud Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Service Level Agreements . . . . . . . . . . . . . . . . . . 5.2 Service-Lebenszyklus und Automatisierung . . . 5.3 Management-Dienste und Werkzeuge . . . . . . . . . 5.3.1 Überwachung . . . . . . . . . . . . . . . . . . . . . . 5.3.2 Steuerung . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.3 Entwicklung . . . . . . . . . . . . . . . . . . . . . . . 5.4 Sicherheit und Risikomanagement . . . . . . . . . . .

59 59 61 62 62 63 65 67

6

OpenSource Cloud Stack . . . . . . . . . . . . . . . . . . . . . . 6.1 Physische und Virtuelle Ressourcen . . . . . . . . . . 6.2 Eucalyptus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Architektur und Komponenten . . . . . . . . 6.3 Apache Hadoop . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.1 MapReduce . . . . . . . . . . . . . . . . . . . . . . . . 6.3.2 Hadoop Distributed File System . . . . . . . 6.3.3 Pig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71 72 74 74 76 77 79 80

4

50 52 55

Inhaltsverzeichnis

ix

6.3.4 Hive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.5 Hadoop as a Service . . . . . . . . . . . . . . . . . 6.4 Das OpenCirrusTM-Projekt . . . . . . . . . . . . . . . . . .

81 82 83

7

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

87 87 89 91 92 92

8

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

95 95 96 98

9

Anhang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 9.1 Installation und Bedienung von Eucalyptus . . . . 99 9.2 Data Mining mit Amazon Elastic MapReduce . . 105

Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Sachverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

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 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 einem Provider im Internet Baun C., Kunze M., Nimis J., Tai S., Cloud Computing DOI 10.1007/978-3-642-01594-6, © Springer 2010

1

2

1 Einleitung

(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 auch 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 in Hardware investieren, um ein Unternehmen zu gründen. Sie können Ressourcen flexibel von einem Provider beziehen und sich auf die Umsetzung ihrer Geschäftsidee konzentrieren. Wenn die Nachfrage steigt, passt sich die Infrastruktur automatisch an die wachsenden Anforderungen an. 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 gerechnet wird, kostet es auch nichts. Cloud Computing hat somit eine wirtschaftliche Bedeutung. Signifikante Kostenersparnisse sind aufgrund der flexiblen Bereitstellung und Nutzung von Diensten möglich. Die abrufbaren Kapazitäten sind dabei sehr umfangreich. Dadurch entsteht eine große Economy of Scale mit einem sehr günstigen Preis/Leistungsverhältnis. Es gibt mittlerweile zahlreiche kommerzielle Anbieter wie z. B. Amazon, Google oder Microsoft. Die 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 Wettbe-

1.2 Definition

3

werbsvorteils 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 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 die Anwendung des Cloud Computing 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 [6, 24].

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

4

1 Einleitung

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.

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 [27]. 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.

1.3 Gliederung Das Buch beschäftigt sich zunächst mit den Grundlagen des Cloud Computing, mit Basistechnologien wie Virtualisierung

1.3 Gliederung

5

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 Fragen 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

Abb. 1.1 Wegweiser zum Lesen des Buchs

6

1 Einleitung

das Kap. 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 (Kap. 1, 3, 5, 7, 8), und einen Pfad für eher wirtschaftswissenschaftlich interessierte Leser (Kap. 1, 4, 6–8). Die verschiedenen Wege sind schematisch in Abb. 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 einzelne Anforderungen befriedigt werden. Es ist z. B. möglich, eine Baun C., Kunze M., Nimis J., Tai S., Cloud Computing DOI 10.1007/978-3-642-01594-6, © Springer 2010

7

8

2 Grundlagen

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 [3]: • 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 zu 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 Beschaffungskosten. Die Konsolidierung reduziert die Zahl der physischen Komponenten. Dadurch sinken auch die Aufwendungen für die Energieversorgung.

2.1 Virtualisierung

9

• 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 Service Level Agreements ist einfacher. Hardware-bedingte Wartungsfenster können prinzipiell entfallen. Da Cloud Service Provider sehr große Ressourcenzentren (ITFabriken) 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 über ein Portal in Selbstbedienung erwerben (Emanzipation des Kunden).

10

2 Grundlagen

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 virtuelle 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.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.

2.1 Virtualisierung

11

Abb. 2.1 Konzept der Betriebssystemvirtualisierung (Container)

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 Abb. 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 Internet Service Provider, die (virtuelle) Root-Server anbieten, nutzen 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. Bekann-

12

2 Grundlagen

te Vertreter der Betriebssystem-Virtualisierung sind die Containertechnologie von Sun Solaris, OpenVZ für Linux, LinuxVServer, 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 Hypervisors. 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 (Abb. 2.2).

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

2.1 Virtualisierung

13

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 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 [105] oder speziell für Linux die Kernel-based Virtual Machine (KVM). Bei der ParaVirtualisierung kommen unter Linux meist Xen-basierte Lösungen zum Einsatz [30], die insbesondere bei der Realisierung der Amazon Web Services eine Rolle spielen [43]. 2.1.2.3 Speichervirtualisierung Cloud-Systeme sollten auch den Speicher dynamisch skalierbar als Service anbieten. Die Speichervirtualisierung führt in diesem

14

2 Grundlagen

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 geringeren Service Levels. Die Daten können hierbei zwischen den Stufen ohne Beeinträchtigung des Service 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 Service-Unterbrechungen bei Störungen. So legt z. B. Amazon bei der Speicherung von Daten bis zu 3 Kopien in verschiedenen Rechenzentren an.

2.1 Virtualisierung

15

2.1.2.4 Netzwerkvirtualisierung Techniken wie 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: Services stehen über virtuelle IP-Adressen zur Verfügung, die über Cluster-Techniken sowohl Load-Balancing als auch automatisches Failover im Falle eines Fehlers realisieren. Durch die Weiterleitung von DNS-Requests ist darüber hinaus die Einblendung von Cloud-Ressourcen 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 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. ä.). 2.1.2.5 Anwendungsvirtualisierung Bei der Anwendungsvirtualisierung handelt es sich um ein Software-Vertriebsmodell, bei dem Anwendungen zentral ver-

16

2 Grundlagen

waltet 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) zur dynamischen Bereitstellung von Software-Komponenten.

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 Architektu-

2.2 Service-orientierte Architekturen

17

ren (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 Kap. 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 Applikationen 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 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 Pro-

18

2 Grundlagen

grammiersprachen 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 [9] gegeben: Unter einer SOA versteht man eine Systemarchitektur, die vielfältige, verschiedene und eventuell inkompatible Methoden oder Applikationen als wieder verwendbare und offen zugreifbare Dienste 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

Abb. 2.3 Beteiligte und Aktionen in einer SOA

2.2 Service-orientierte Architekturen

19

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 erfolgen. 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.

20

2 Grundlagen

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 Abb. 2.4 sind Punkt-zu-Punkt-Verbindungen dem Huband-Spoke-Ansatz mit ESB gegenübergestellt.

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

2.3 Web Services

21

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 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 [107]: 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 [29] 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 Dienste in eine Anwendung eingebunden werden; auch können Legacy Systeme durch Web Services angesprochen werden.

22

2 Grundlagen

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 Services anhand von Uniform Resource Identifiers (URI). Web Services in ihrer Grundform beschreiben nur die Primitiven, um Dokumente (Daten) zwischen Kunden und Servern 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 Qualityof-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 eine Popularität erfährt. 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

2.3 Web Services

23

und Schnittstellen (port types), und andererseits durch protokollspezifische und konkrete, verfügbare Adressen (endpoints). Im Fall von REST werden die generischen HTTP Methoden (d. h. GET, PUT, POST, DELETE, etc.) anstelle spezieller 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. Zum einen der virtuelle Umschlag, der SOAP Envelope. Dieser enthält zwei Elemente. Den optionalen SOAP Header, in dem u. a. Informationen zum Routing und Sicherheitsinformationen (Authentifizierung und Autorisierung) enthalten sein können und den zwingend notwendigen 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 interessante Optionen für Web Service Intermediaries bzw. zur Einbindung spezialisierter Middeware-Funktionen zur Unterstützung verschiedener Quality-of-Services der Web Services Platform Architecture.

24

2 Grundlagen

REST dagegen 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 Abschn. 3.1 dargestellt ist, unterscheidet nach einer Trennung der organisatorischen Einheiten von Benutzern und Anbietern, während sich die technische Sicht in Abschn. 3.2 an funktionalen Eigenschaften orientiert.

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 Selbstbedienung die gewünschten Leistungsumfänge spezifizieren können. Dazu bedarf es in der Regel keines übergeordneten RahmenverBaun C., Kunze M., Nimis J., Tai S., Cloud Computing DOI 10.1007/978-3-642-01594-6, © Springer 2010

25

26

3 Cloud-Architektur

trags, 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.

BenutzerOrganisation A

Private Cloud BenutzerOrganisation B

Private Cloud

AnbieterOrganisation E

AnbieterOrganisation C Hybrid Cloud

Public Cloud

AnbieterOrganisation D

Abb. 3.1 Public Cloud, Private Cloud und Hybrid Cloud

3.2 Technische Landschaft der Cloud Services

27

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 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 Services 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 Cloud Services 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 ver-

28

3 Cloud-Architektur

fü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 [17]. 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öhe-

Human as a Service (HuaaS) Crowdsourcing Soware as a Service (SaaS) Applicaons Applicaons Services Plaorm as a Service (PaaS) Programming Environment (PE) Execuon Environment (EE) Infrastructure as a Service (IaaS) Infrastructure Services (IS) Resource Set (RS) Virtual Resource Set (VRS)

Abb. 3.2 Cloud Architecture Stack

Physical Resource Set (PRS)

3.3 Infrastructure as a Service

29

ren abstrakteren Schichten die Dienste der tieferen konkreteren Schichten zu ihrer eigenen Dienstrealisierung benutzen, müssen dies aber nicht. Die 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 Services, 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 Services sein. Die drei Hauptschichten, nach denen der resultierende Stack in Abb. 3.2 unterteilt wird, folgen dem everything-as-a-serviceParadigma (XaaS) mit den vier Hauptvertretern Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS) und Human 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 Funktio-

30

3 Cloud-Architektur

nalitäten an der Benutzerschnittstelle sind das Anlegen bzw. Beseitigen von Betriebssystem-Abbildern, die Skalierung von beanspruchten Kapazitäten oder die Definition von Netzwerktopologien. Die primäre Service-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 Physical Resource Set (PRS), deren Vertreter auf einer proprietären physikalischen Hardware basieren und diese anbieten, und in die Klasse Virtual Resource Set (VRS), die auf Virtualisierungstechnologien wie XEN [30] aufgebaut sind und damit auch virtuelle Instanzen zur Verfügung stellt. Beispiele für Cloud Services in PRS sind Emulab [12] und iLO [11]. Zu den VRS Cloud Services zählen Amazon EC2 [34], Eucalyptus [13], Nimbus [21] und OpenNebula [20]. Auch wenn die VRS Services mit ihren vereinfachenden virtuellen Ressourcen weitaus häufiger anzutreffen sind, haben die PRS Services ihre Berechtigung, wenn z. B. aus Gründen der Stabilität, Performance oder durch spezielle Hardware-Anforderungen die Indirektion durch einen Hypervisor vermieden werden soll, aber zugleich auf den Komfort und Funktionsumfang der Cloud Service-Verwaltung nicht verzichtet werden soll. Neben der beschriebenen Resource Set-Unterschicht gehören auch die Infrastructure Services zur IaaS-Schicht. Im Unterschied zu den Resource Set-Angeboten haben die Infrastructure Services einen engeren Anwendungsfokus. So gibt es z. B. dedizierte Infrastructure Services für Berechnungsaufgaben (Hadoop MapReduce [80]), für Massenspeicher (Amazon S3 [39], Zumodrive [111], Dropbox [59]) oder für Netzwerke (OpenFlow [23]). Eine erweiterte und kommentierte Liste von IaaS Cloud Services und Werkzeugen zeigt Tabelle 3.1.

Cloud Service

Elastic Compute Cloud (EC2) Dynamo Simple Storage Service (S3) SimpleDB CloudFront SQS AppNexus Cloud Virtual Cloud Computing Virtual Recovery 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

Amazon Amazon Amazon Amazon Amazon Amazon AppNexus Bluelock Bluelock Dropbox Emulab ENKI

Reservoir FlexiScale GoGrid GoGrid Google Google HP HP

[20] [65] [75] [75] [7] [73] [11] [98]

[34] [10] [39] [40] [33] [41] [47] [51] [51] [59] [12] [63]

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 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 31

Virtuelle Server Vorkonfigurierte virtuelle Server Massenspeicher Massenspeicher Lokale Netzwerksimulation Vorkonfigurierte virtuelle Server Massenspeicher Virtuelle Server Hybride Cloud-Testumgebungen Virtuelle Server Open SourceToolkit zur IaaS Cloud auf Cluster-Basis Virtuelle Server Open Source Implementierung von Amazons EC2 Verteilte Markt-basierte Allokation von IaaS-Ressourcen Massenspeicher Database for cloud storage Web Applikations-Server for cloud deployments

[82] [82] [82] [82] [89] [93] [93] [93] [99] [103] [21] [104] [64] [109] [111] [31] [31]

Joyent Joyent Joyent Nirvanix Openflow Rackspace Rackspace Rackspace Skytap Terremark Globus todo GmbH UCSB Zimory Zumodrive 10gen 10gen

Accelerator Connector BingoDisk Storage Delivery Network OpenFlow Mosso Cloud Sites Mosso Cloud Storage Mosso Cloud Servers Skytap Virtual Lab Infinistructure Nimbus flexIT Eucalyptus Zimory Public Cloud Market Hybrid Cloud Storage Mongo DB Babble Application Server

Referenz Beschreibung

Organisation Cloud Service

Tabelle 3.1 (Fortsetzung)

32 3 Cloud-Architektur

3.4 Platform as a Service

33

3.4 Platform as a Service Die Cloud Services in der PaaS-Schicht richten sich meist nicht an Endbenutzer sondern an Entwickler. Diesen werden in den Unterschichten Programming Environments (PE) und Execution Environments (EE) Umgebungen angeboten, in denen sich eigene Software in einer bestimmten Programmiersprache entwickeln bzw. ausführen lässt. Typische Vertreter der Programming Environments sind das Django Framework [58] oder Sun Caroline [52]. Diese erweitern existierende Programmiersprachen z. B. durch Klassenbibliotheken mit einem bestimmten Anwendungsfokus. Die Ausführung der entstehenden Applikation erfolgt in Laufzeitumgebungen, die vom jeweiligen Programming Environment aus Projektsicht entkoppelt sind. Bekannte Vertreter der Cloud Execution Environments sind Google App Engine [76], Azure von Microsoft [50] oder Reasonably Smart von Joyent [82]. An diesen Beispielen wird deutlich, dass die Execution Environments häufig mindestens ein eigenes Programming Environment mitbringen. Im Falle von Microsoft Azure lässt sich eine ganze Reihe von Werkzeugen und alternativen Programmiersprachen auf Basis der AzureUmbebung ausführen und auch Google App Engine lässt sich in mehreren Sprachen programmieren. Wie Vertreter der verschiedenen Schichten der Architektur zusammenspielen bzw. aufeinander aufbauen können, zeigt sich schön am Beispiel des Programming Environments AppScale [46], bei dem es sich um eine Open Source-Implementierung der Google App Engine handelt. AppScale realisiert dessen Funktionalität auf Basis des oben bereits erwähnten VRS-Vertreters Eucalyptus. Die Austauschbarkeit von Teilen des beschriebenen Stacks, die durch die Nachimplementierung in Open Source-Projekten entsteht, führt nicht nur zu technischen Alternativen, sondern mindert punktuell auch die häufig kritisier-

Zoho

Microsoft NetSuite Salesforce Sun

Live Mesh SuiteFlex Force.com Project Caroline Zoho Creator

EdgePlatform Facebook Platform App Engine Azure

Akamai Facebook

Google Microsoft

Cloud Service

Organisation

[110]

[86] [88] [67] [52]

[76] [50]

[32] [84]

Referenz

Entwicklung und Betrieb Datenbank-basierter Web-Applikationen

Content, Site, Application Delivery Werkzeuge und Umgebung für Applikationen im sozialen Netzwerk Facebook Skalierbare Ausführungsumgebung für Web-Applikationen Entwicklungs- und Ausführungsumgebung für Microsoft Applikationen 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-Applikationen

Beschreibung

Tabelle 3.2 Platform as a Service Angebote und Werkzeuge

34 3 Cloud-Architektur

3.5 Software as a Service

35

te 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 Provider entwickelt und betrieben werden. Innerhalb der SaaS-Angebote lässt sich unterscheiden zwischen Anwendungsdiensten (Application Services), deren Funktionalität im Wesentlichen auf einer einzigen einfachen Applikation basiert und vollwertigen komplexen Anwendungen (Applications). Ein Teil der Application Services kann vom Endnutzer direkt benutzt werden, wie dies z. B. bei Google Maps [74] der Fall ist. Andere Services stiften erst durch eine Verknüpfung überhaupt Sinn für den Endnutzer, wie z. B. die Benutzerverwaltung von OpenID [92], oder die Einbindung sozialer Netzwerke in Applikationen durch OpenSocial [79]. Die Verknüpfung solcher Application Services kann durch gewöhnliche statische Einbindung geschehen oder durch die vergleichsweise leichtgewichtige und flexible Einbindung in sogenannten Service Mashups [19]. Von wesentlich höherer Komplexität und größerem Funktionsumfang sind die Applications, wie z. B. Google Docs [71], Microsoft Office Live [85] oder das in Salesforce.com [97] zentrale CRM-System. An letzterem zeigt sich auch, wie sich ei-

[92] [85] [97]

OpenID

Office Live Salesforce.com

OpenID Foundation Microsoft Salesforce

Google

Google Google [79]

[71] [74]

[66]

eCloudManager SAP Edition Google Docs Google Maps API OpenSocial

fluidOps

Referenz

Cloud Service

Organisation

Online Office Suite Application Service zur Integration von Landkarten und geographischen Informationen Übergreifende Programmierschnittstelle zur Integration Sozialer Netze in Applikationen Verteiltes System zur Verwaltung systemübergreifender Benutzeridentitäten Online Office Suite Erweiterbares CRM-System

SAP Landscape as a Service

Beschreibung

Tabelle 3.3 Software as a Service Angebote und Werkzeuge

36 3 Cloud-Architektur

3.6 Human as a Service

37

ne vollwertige Applikation durch weitere Application Services 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 – Application Services entwickeln und betreiben können, die die Funktionalität des zentralen CRM-Systems erweitern und ergänzen. Weitere Applikationen und Application Services zeigt Tabelle 3.3.

3.6 Human as a Service Die Schicht Human as a Service (HuaaS) baut auf dem Cloud Computing Stack auf. Dies illustriert, dass das Cloud-Paradigma nicht nur eingeschränkt auf IT-Services 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 [38] bietet eine Schnittstelle, über die meist feingranulare Aufgaben auf interessierte menschliche Ressourcen übertragen werden können, die dafür eine gleichermaßen kleine Entlohnung erhalten. Typische 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 Erledi-

38

3 Cloud-Architektur

gung ihrer Aufgaben zur Verfügung. Bei anderen CrowdsourcingAngeboten profitieren z. B. alle Teilnehmer von bereitgestellten Artefakten, deren Qualität sich an den Urteilen der anderen Benutzern ablesen lässt. YouTube [108] 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 [5]. Basierend auf der Mehrheitsmeinung sagen sie den Ausgang von Wahlen oder auch Sportereignissen vorher.

Kapitel 4

Ausgewählte Cloud-Angebote

Im vorangegangenen Kap. 3 wurde eine technische Architektur für Cloud Services beschrieben und damit die Landschaft des Cloud Computing kartiert. Die einzelnen Cloud Services kamen hierbei nur kurz zur Sprache. Für die Cloud Services Amazon Web Services, Google App Engine und Salesforce.com will das folgende Kapitel einen Überblick geben und deren Funktionsumfang vermitteln. Darüber hinaus soll dargestellt werden, wie man diese Cloud Services benutzen kann. Die Auswahl fiel auf die genannten Angebote, weil sie zum einen eine hohe Präsenz 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.

Baun C., Kunze M., Nimis J., Tai S., Cloud Computing DOI 10.1007/978-3-642-01594-6, © Springer 2010

39

40

4 Ausgewählte Cloud-Angebote

4.1 Amazon Web Services Amazon Web Services (AWS) [43] ist der Sammelbegriff für alle Cloud-Angebote der Firma Amazon. Das Cloud-Engagement des Unternehmens, das immer noch vorrangig als Online-Shop bekannt ist, lässt sich leicht begründen: Amazon muss ITRessourcen in einem erheblichem Umfang vorhalten, der sich am saisonalen Spitzenaufkommen – zur Weihnachtszeit und zum 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 Services: • Amazon Elastic Compute Cloud (Amazon EC2) [34]: 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 Abschn. 4.1.1 genannt. • Amazon Simple Storage Service (Amazon S3) [39]: Die Speicherung von großen Datenmengen in einem im Wesentlichen flach aufgebauten Massenspeicher erlaubt Amazon S3, auf das Abschn. 4.1.2 weiter eingeht. • Amazon Simple Queue Service (Amazon SQS) [41]: Amazon SQS realisiert ein Messaging-System von NachrichtenWarteschlangen, in die schreibende Applikationen (Publisher) Nachrichten einstellen können. Registrierte empfangende Applikationen (Subscriber) können diese dann asynchron auslesen (Abschn. 4.1.3). Mit Hilfe von SQS lassen sich einfach skalierbare Applikationen in der Cloud entwickeln (Abschn. 4.1.5). • Amazon SimpleDB [40]: Die Amazon SimpleDB ist eine Cloud-Datenbank, die ein einfaches Datenbankmodell um-

4.1 Amazon Web Services

41

setzt, das an ein abgespecktes relationales Datenbankmodell erinnert. Mehr Informationen hierzu siehe Abschn. 4.1.4. • Amazon CloudFront [33]: Zur schnellen Auslieferung von Daten in Web-Applikationen verwendet man häufig 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 [35]: Mit Amazon Elastic MapReduce lassen sich datenintensive Berechnungen über eine beliebige Anzahl von Amazon EC2 Instanzen verteilen und somit flexibel skalieren. • AWS Import/Export [36]: Auf den ersten Blick anachronistisch klingt das Angebot, die Übertragung sehr großer Datenmengen durch das Versenden physikalischer Datenträger auf dem Postweg zu erledigen. Es existieren jedoch zahlreiche Praxisprobleme mit derart großen Datenmengen, dass der Postversand schneller, zuverlässiger und preiswerter ist als die Übertragung über das Internet. Neben diesen Cloud-Angeboten, die offizielle Bestandteile der AWS sind, gibt es noch weitere Cloud Services, 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

42

4 Ausgewählte Cloud-Angebote

Schritte sind notwendig um einem solchen Server einzurichten und dauerhaft zu betreiben: • 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 hierfür vorgefertigte Images zur Verfügung, die sich in ihrem Betriebssystem und in den darauf installierten Software-Paketen 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-Applikationen. 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 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 Arbeitsund Plattenspeicher. Außerdem muss man eine sog. Availability Zone auswählen, in der der virtuelle Server laufen soll. Die Ressourcen von Amazon sind in mehrere Regionen eingeteilt und die Regionen wiederum in die Availability Zones. Die Availability Zones sind insofern voneinander unabhängig, dass sie sich keine kritischen Komponenten teilen und sie damit nicht gleichzeitig aus demselben Grund ausfallen

4.1 Amazon Web Services

43

können. Eine kluge Auswahl der Availability Zone kann also zur Verringerung von Latenzen und zu verbesserter Zuverlässigkeit bei redundant ausgelegten Servern führen. • Schlüsselpaar generieren: Die Benutzer identifizieren sich gegenüber den genutzten Amazon EC2 Instanzen über ein 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 öfters neu gestartet werden muss. Für diesen Fall bietet Amzon die statischen Elastic IPs, 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 Security Group angehören, für die jeweils dieselben definierbaren Sicherheitseinstellungen gelten. Für solch eine Gruppe lässt sich beispielsweise auch der Zugang über

44

4 Ausgewählte Cloud-Angebote

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 EC2Instanz 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 EC2Instanzen 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 zunächst wie gewohnt die eigenen Erweiterungen. Durch ei-

4.1 Amazon Web Services

45

ne 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 Abschn. 5.3). 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 Sommer 2009 für Instanzen, die in Europa laufen. Diese Instanzen sind ca. 10 Prozent teurer als die gleichen Instanzen in den USA. 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. 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 weist eine

46

4 Ausgewählte Cloud-Angebote

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

Linux/UNIX

Windows

Small (Default) Large Extra Large

0,11 0,44 0,88

0,135 0,54 1,08

High CPU On-Demand Instance

Linux/UNIX

Windows

Medium Extra Large

0,22 0,88

0,32 1,28

High CPU On-Demand Instance Extra Large eine 64-bit Plattform mit 20 ECUs (jeweils 2,5 ECU verteilt auf 8 virtuelle Kerne), 7 GB Hauptspeicher und 1690 GB Festplatte aus. 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 Kosten für eine gegebene Konfiguration und ein bestimmtes angenommenes Nutzungsprofil ausrechnet. Neben den dynamischen Instanzen bietet Amazon neuerdings 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 insgesamt $ 325 pro Jahr ($ 500 für drei Jahre) an.

4.1 Amazon Web Services

47

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 Buckets. Diese können nicht hierarchisch geschachtelt werden, sondern jedes Web-Objekt ist direkt über seinen Bucket-Namen zusammen mit seinen ObjektNamen identifizierbar. Folglich handelt es sich bei Amazon S3 nicht um ein herkömmliches Dateisystem, auch wenn es Werkzeuge und Cloud Services von Drittanbietern gibt, die es erlauben, auf Speicher-Ressourcen in S3 wie auf entfernt liegende Festplatten zuzugreifen, wie z. B. JungleDisk [83]. 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 Abschn. 5.3 näher eingeht. Für den direkten Zugriff auf Amazon S3 von der Kommandozeile aus gibt es das Werkzeug s3cmd [94], an dem die Funktionalität der API illustriert werden soll. Folgende Funktionen sind unter anderem durch s3cmd realisiert: • Anlegen von Buckets s3cmd mb s3://Bucket • Hochladen von Objekten in einen Bucket s3cmd put LokaleDatei s3://Bucket/EntfernteDatei • Auslesen von Meta-Daten z. B. Bucketinhalten s3cmd ls s3://Bucket • Herunterladen von Objekten aus einem Bucket s3cmd get s3://Bucket/EntfernteDatei LokaleDatei

48

4 Ausgewählte Cloud-Angebote

• Löschen von Dateien s3cmd del s3://Bucket/EntfernteDatei • Löschen von (leeren) Buckets s3cmd rb s3://Bucket

4.1.3 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 Applikationen 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 verschiedender Komponenten in einer Applikation kann eine Dienst nehmende Komponente ihre Arbeitsaufträge als Nachricht in die Warteschlange einstellen, von wo sie Dienst gebende 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 Abschn. 4.1.5 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 Web Service-Aufrufe aus den verbundenen Komponenten. Daher werden an dieser Stelle auch keine Kommandozeilenbefehle angegeben. • • • •

CreateQueue: Anlegen einer Queue im AWS-Benutzerkontext ListQueues: Aufzählung der existierenden Queues DeleteQueue: Löschen einer Queue SendMessage: Einstellen einer Nachricht in eine Queue

4.1 Amazon Web Services

49

• ReceiveMessage: Auslesen einer (oder mehrerer) Nachrichten aus einer Queue • ChangeMessageVisibility: Dediziertes Einstellen der Sichtbarkeit einer gelesenen Nachricht für andere potenzielle Ausleser • DeleteMessage: Löschen einer gelesenen Nachricht • SetQueueAttributes: Einstellen von Attributen der Queue, z. B. der Zeit zwischen zwei Leseoperationen auf dieselbe Nachricht • GetQueueAttributes: Auslesen von Attributen der Queue, z. B. der Anzahl der aktuell in der Queue befindlichen Nachrichten • AddPermission: Freigabe einer Queue zum geteilten Zugriff aus mehreren Benutzerkontexten • RemovePermission: Widerrufen der Freigabe für andere Benutzerkontexte.

4.1.4 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 Funktionsumfang aktueller kommerzieller Relationaler Datenbanksysteme (RDBMS) angewiesen sind, wird auf die Möglichkeit verwiesen, eine solche Datenbank auf einer EC2-Instanz zu installieren. Entsprechend des eingeschränkten Funktionsumfangs der SimpleDB ist auch ihre Schnittstelle auf einige wenige einfa-

50

4 Ausgewählte Cloud-Angebote

che 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.5 Zusammenspiel der Amazon Web Services Die verschiedenen AWS Dienste können sowohl einzeln als auch im Zusammenspiel bei der Anwendungsentwicklung verwendet werden. In [26] 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 Abb. 4.1) arbeiten SQS, SimpleDB, EC2 und S3 zusammen. Eine Reihe von SQS-Queues speichert

4.1 Amazon Web Services

51

Amazon SQS Billing Queue

Launch Queue

Shutdown Queue

Monitor Queue

Launch Controller

Insert JobID Status

Shutdown Controller

Monitor Controller

Billing Controller

Get EC2 Info

Launch

Controller

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)

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 SQS-Queue (launch queue) eingehen. Für jeden Verarbeitungsschritt gibt es eine ControllerKomponente (launch controller, monitor controller, shutdown controller, billing controller), die von einer Queue liest und Ergebnisse in die nächste Queue 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

52

4 Ausgewählte Cloud-Angebote

Anfragen benutzt. SimpleDB wird somit von jedem Controller angefragt und geschrieben. S3 dagegen wird zur Speicherung der zu untersuchenden Daten (Hunderte von Terabytes an WebDokumenten) und der Ergebnisse der Suchanfrage benutzt. Der Zugriff auf S3 erfolgt über ein Hadoop-Cluster aus EC2 Instanzen (siehe auch Abschn. 6.3). 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 Queues entkoppelt sowie durch unabhängige Controller-Komponenten steuert. Alle Komponenten sind leichtgewichtig und kommunizieren Dienste orientiert über HTTPAnfragen unter Nutzung von XML. 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 Google App Engine Die Google App Engine [76] ist ein umfassendes Platform as a Service-Angebot mit Programmierumgebung, Werkzeugunterstützung und Ausführungsumgebung. Mit dieser Ausstattung lassen sich Web-Applikationen für die skalierbare Infrastruktur von Google entwickeln. Durch Google App Engine können sich die Ersteller der Web-Applikation auf die Entwicklung der Anwendungsfunktionalität konzentrieren und müssen sich praktisch keine Sorgen um die Administration von Servern machen. Zum Zeitpunkt der Erstellung dieses Buches bietet die Google App Engine Umgebungen für die Programmiersprachen

4.2 Google App Engine

53

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 WebApplikationen erlaubt. Hat die Anwendung den Produktivzustand erreicht, kann man sie auf die Google Infrastruktur übertragen und dort ausführen lassen. Die Web-Applikation 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 Services (im Sinne der Cloud-Architektur: Application Services). 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 Datastore, eine Schema-lose objektorientierte Datenbank mit einer AnfrageEngine 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-Applikationen lässt sich das Versenden und Empfangen von Emails über Google EmailAccounts einbinden. Auch dieser Application Service lässt sich analog über eine proprietäre Schnittstelle oder über ein Subset des standardisierten JavaMail-Interface verwenden. • Benutzeraccount-Dienste: Zur Authentifizierung der Benutzer der Web-Applikation kommen Google Accounts zum Ein-

54

4 Ausgewählte Cloud-Angebote

satz, für die es eine proprietäre Schnittstelle gibt. Die Benutzer können sich über eine Umleitung auf der Anmeldeseite von Google Accounts anmelden. Ein rudimentäres RechteManagement erlaubt es, einfache Benutzer und Administratoren zu unterscheiden, um den Zugriff auf geschützte Funktionen zu regeln. • Über die genannten Services hinaus existieren noch weitere, z. B. zur schnellen Zwischenspeicherung von Daten in einem Cache, zur Verknüpfung mit anderen Web-Applikationen mittels HTTP(S) oder zum effizienten Bearbeiten von anzuzeigenden Abbildungen. Im Moment ist der Zugriff auf die Google Data Services wie z. B. Google Calendar, Docs oder Picasa noch eingeschränkt auf die Programmiersprache Python. Google App Engine unterstützt nicht nur Entwickler von WebApplikationen durch die oben genannte lokale Laufzeitumgebung und die zugehörige Automatisierung des Deployments 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) Applikationen. Auch in der Bepreisung der App Engine orientiert sich Google an den Bedürfnissen potenzieller Entwickler: es gibt ein kostenloses Freikontingent (Quota) je Entwickler für CPUAuslastung, Speicherbenutzung, Datentransfer etc., das tageweise ausgeschöpft werden kann und für Entwicklungssysteme und einfache Web-Anwendungen 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 genann-

4.3 Salesforce.com

55

ter Kritikpunkt am Cloud Computing. Für viele Platform as a Service-Angebote ist die Wiederverwendbarkeit des Codes der entwickelten Applikationen sehr eingeschränkt bis unmöglich. Der Anbieter der Web-Applikation ist damit dauerhaft an den Betreiber des Cloud-Angebotes gebunden und damit auch an dessen Preisgestaltung und Service Qualität. Für die Google App Engine gibt es mit AppScale [46] aber inzwischen eine kompatible quelloffene Plattform, die das Umziehen von WebApplikationen, auf eine private Cloud mit eigenen Ressourcen auf Basis der IaaS-Technologie Eucalyptus [13] ermöglicht (Siehe auch Kap. 6 und 9). Das Projekt, das von der University of California Santa Barbara ausging, wird mittlerweile von Google selbst aktiv unterstützt.

4.3 Salesforce.com Salesforce.com [97] ist einer der weltweit führenden Cloud-Anbieter für Software zur Kundenbeziehungsverwaltung (Customer Relationship Management, CRM). Im Sinne von Kap. 3 ist Salesforce.com ein SaaS Angebot, das um ein Platform as a Service-Angebot ergänzt wurde, auf dem unabhängige Drittanbieter ergänzende Software as a Service entwickeln können. 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 multimandan-

56

4 Ausgewählte Cloud-Angebote

tenfähige Anwendung auf den Servern von Salesforce.com und erfordert keine lokale Installation. • Force.com [67] heißt ein Platform as a Service-Angebot, 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 [45] 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 [57] bzw. Salesforce.com Community [96], über die sich die Benutzer zum einen vernetzen und zum anderen professionelle Beratungsleistungen von Salesforce.com und seinen Partnern anbieten. 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 gehö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 Applikationen hat einen stark datenzentrierten Ansatz: Die Entwicklung einer Anwendung beginnt in der Regel mit der Erstellung eines Objektmodells, das später die Anwen-

4.3 Salesforce.com

57

dungsdaten 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 Applikationslogik 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 Applikation 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.

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 Management.

5.1 Service Level Agreements Bei einem Service Level Agreement (SLA) handelt es sich um eine Vereinbarung über die Dienstgüte zwischen einem Dienstanbieter und einem Klienten. Diese Vereinbarung kann über einen Vertrag formal und rechtlich bindend getroffen werden oder aber informell, wenn verschiedene Abteilungen eines Unternehmens Baun C., Kunze M., Nimis J., Tai S., Cloud Computing DOI 10.1007/978-3-642-01594-6, © Springer 2010

59

60

5 Cloud Management

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 Klienten 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 Service-Vereinbarung und Überwachung behandelt. Ein aktuelles, von der Europäischen Kommission im 7. Rahmenprogramm gefördertes Projekt untersucht die Aspekte von mehrstufigen SLAs in einem Markt mit konkurrierenden Angeboten [100].

5.2 Service-Lebenszyklus und Automatisierung

61

5.2 Service-Lebenszyklus und Automatisierung Jeder Cloud Service durchläuft einen wohl definierten Lebenszyklus: Der Dienstanbieter definiert den Umfang und die Qualität der Dienste und beschreibt die Eigenschaften in einem ServiceKatalog. 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 Service-Aufträge geschlossen, Service-Bausteine werden abgewickelt und Ressourcen werden zurückgesetzt. Eine Accounting-Prozedur 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 BillingVerfahren basieren meist auf Kreditkarten. Bei manchen Anbietern wie z. B. Zimory ist auch die Bezahlung über Lastschriftverfahren bzw. Rechnungstellung möglich [109]. Die Bereitstellung von Diensten geschieht sehr häufig auf der Basis von 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

62

5 Cloud Management

Abweichungen oder Störungen 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 Services 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 Service Provider und publiziert sie auf einer Web-Seite [53]. Diese Daten umfassen Größen wie CPU, Memory und Disk-Zugriffe. Die Darstellung erfolgt als Diagramm für den vergangenen Monat. Auf diese Weise ist nicht nur ein direkter Leistungsvergleich verschiedener Anbie-

5.3 Management-Dienste und Werkzeuge

63

ter 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 Service zum Monitoring der Leistung der Amazon Web Services [55]. 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 Service einer EC2-Instanz zuordnen. Die Verarbeitung der Monitoring-Daten erfolgt über das Webservice-API oder über Kommandozeilenprozeduren.

5.3.2 Steuerung Amazon bietet zum Management der Infrastrukturdienste nicht nur einen Satz von Kommandozeilenwerkzeugen an [49], sondern auch eine komfortable Web-Konsole [48]. Diese ermöglicht die Steuerung von Amazon EC2 und Amazon Elastic MapReduce. Die EC2-Konsole unterstützt die folgenden Operationen: • Instanzen: Starten, Stoppen, Reboot, Konsolenzugriff, Logfiles sichten • Images: Starten, Registrieren, Löschen, Zugriffsrechte setzen • Speicher: Anlegen, Löschen, Zuordnen, Snapshots generieren • Netzwerk: IP-Adressen verwalten • Sicherheit: Sicherheitsgruppen und Schlüssel verwalten Die Ausführung der Management-Operationen ist dabei für die verschiedenen Verfügbarkeitszonen gesondert möglich. Eine alternative grafische Konsole steht als OpenSourcePlugin für den FireFox-Browser bereit: ElasticFox organisiert in

64

5 Cloud Management

Abb. 5.1 Infrastruktur-Management mit ElasticFox

ähnlicher Weise das Infrastruktur-Management [61]. 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 Abb. 5.1 zu sehen. Um den Amazon Speicherdienst S3 zu nutzen, stehen mehrere Lösungen zur Verfügung. Besonders interessant ist das FireFox-Plugin S3Fox Organizer [95]. Mit diesem kann man • Daten hoch- und herunterladen, löschen, hierarchisch organisieren, • 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 (Abb. 5.2). Die lokalen und die Cloud-Dateistrukturen

5.3 Management-Dienste und Werkzeuge

65

Abb. 5.2 S3Fox Organizer für Speicherdienste

werden in zwei Ansichten nebeneinander dargestellt, das Kopieren von Daten geschieht über simples Drag und Drop.

5.3.3 Entwicklung In einer Service-orientierten Landschaft greifen Betrieb und Entwicklung oftmals eng ineinander. Neben den ManagementWergzeugen spielen daher auch die Entwicklungswerkzeuge eine große Rolle. Als Beispiel für eine integrierte Cloud-Entwicklungs- und Managementumgebung soll Eclipse [60] 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 Cloud-Infrastrukturen zur Verfügung [72]. Es gibt aber auch

66

5 Cloud Management

Abb. 5.3 Amazon Web Service Plugin für Eclipse

spezifische Erweiterungen für Amazon Web Services, wie z. B. das AWS Eclipse ToolKit [42], das es Entwicklern ermöglicht, verteilte und skalierbare Java-Anwendungen auf der Basis von Tomcat-Containern für Amazon EC2 zu entwickeln und zu testen (Abb. 5.3). Daneben sind auch Werkzeuge für das Management von Sicherheitsgruppen, AMI-Bibliotheken, EC2Instanzen 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 [69]. Die Entwicklungsumgebung enthält neben dem GWT einen lokalen Webserver zum Austesten der Programme. Sobald die Anwendungen zufriedenstellend funktionieren, können sie in WAR-Files paketiert und in

5.4 Sicherheit und Risikomanagement

67

Abb. 5.4 Google App Engine Plugin für Eclipse

die skalierbare Google-Infrastruktur geladen werden. Es gibt als Erweiterung des Software Development Kit auch das Google Plugin für Eclipse zur interaktiven Entwicklung von GWTAnwendungen in einer grafischen integrierten Entwicklungsumgebung [77]. Durch simples Drücken des App Engine Buttons können lokal entwickelte Programme zur Verwendung in der Google-Infrastruktur veröffentlicht werden (Abb. 5.4).

5.4 Sicherheit und Risikomanagement Die Sicherheit umfasst sowohl den sicheren Zugriff auf Ressourcen als auch Belange des Datenschutzes. Für das sog. Cloud Sourcing gelten im Bereich der Sicherheit prinzipiell dieselben Regeln wie sie auch beim Betrieb von Diensten in einem lokalen Rechenzentrum üblich sind: Die Sicherheit ist als Bestandteil des zwischen Provider und Klienten ausgehandelten SLA zu se-

68

5 Cloud Management

hen. So erlaubt z. B. der Zimory Cloud-Marktplatz die Definition von SLAs zur Einstellung der gewünschten Sicherheitsanforderungen für Cloud Services [109]. Die verschiedenen Service Delivery Modelle 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 Provider • SaaS: Geringste Flexibilität, die Verantwortung für die Sicherheit liegt beim Provider Bei vielen Anbietern ist die Identität eines Kunden einfach durch die Zuordnung zu einer Kreditkartennummer festgelegt. 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 Provider über Auditing-Prozesse alle Aktionen im Umgang mit Ressourcen auf. Durch diese Art der Überwachung sind auch strengste gesetzliche Vorschriften einzuhalten. Ein umfassendes Kompendium zum Thema Cloud-Sicherheit hat die Cloud Security Alliance herausgegeben [56]. 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 gemeinsa-

5.4 Sicherheit und Risikomanagement

69

men 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. 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 Cloud Provider 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 Provider dar (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 Software-Herstellern, 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.

70

5 Cloud Management

• 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.

Kapitel 6

OpenSource Cloud Stack

Das Thema dieses Kapitels ist der Aufbau einer Cloud auf der Basis von OpenSource-Komponenten. Es existiert bereits eine Vielzahl von Lösungen, die die Konstruktion einer CloudArchitektur erlauben. Es ist somit möglich, einen OpenSource Cloud Stack zu entwerfen (Abb. 6.1). Der Entwurf umfasst nicht nur Komponenten für die Hardware- und Software-Infrastruktur, sondern auch Komponenten zur Etablierung von Anwendungsumgebungen. Der Stack ist eine spezifische Ausprägung der in Kap. 3 dargestellten Cloud-Architektur: Die dort eingeführten IaaS-Komponenten sind durch die Physischen Ressource Sets (PRS) zur Partitionierung der Infrastruktur repräsentiert, die Software-Infrastruktur 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 das Accounting und Billing. Die PaaS-Komponenten bilden die Framework-Schicht, die SaaS-Komponenten sind auf der Anwendungsebene zu finden. Im folgenden sollen einige der Komponenten des Entwurfs exemplarisch vorgestellt werden. Baun C., Kunze M., Nimis J., Tai S., Cloud Computing DOI 10.1007/978-3-642-01594-6, © Springer 2010

71

72

6 OpenSource Cloud Stack

Anwendung

Framework (Pig, Hadoop, Mahout)

Software Infrastruktur VM Mgmt Acct & Billing (Tycoon)

Storage Mgmt

(HDFS, KFS, Gluster, (Eucalyptus, Enomalism, Lustre, PVFS, MooseFS, Tashi, Reservoir, HBase, Hypertable) Nimbus, oVirt)

Monitoring (Ganglia, Nagios, Zenoss, MON, Moara)

Job Scheduling (Maui/Torque)

Hardware Infrastruktur (PRS, Emulab)

Abb. 6.1 OpenCirrus OpenSource Cloud Stack

6.1 Physische und Virtuelle Ressourcen Die Wurzeln der IaaS-Komponenten liegen im Emulab-Projekt [12], 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 Ressource 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 Abb. 6.2 gezeigt: Es gibt hier eine Domäne für Systemforschung, eine für das Management virtueller Maschinen, so-

6.1 Physische und Virtuelle Ressourcen

73

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

wie 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 Ressource Sets (VRS). Beim Beispiel in Abb. 6.2 handelt es sich um die ManagementSuite Tashi, die Intel und Yahoo! zurzeit gemeinsam entwickeln. Tashi ist eine Lösung speziell für Cloud-Rechenzentren, 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 [102]. Ein weiteres sehr populäres Managementsystem für virtuelle Ressourcen ist Eucalyptus, das im Folgenden beschrieben wird.

74

6 OpenSource Cloud Stack

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 ein so genanntes private Cloud einem öffentlichen (public) 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 [64] ist eine Abkürzung für Elastic Utility Computing Architecture for Linking Your Programs To Useful Systems. Die Entwicklung von Eucalyptus findet an der University of California (UCSB) statt. Eucalyptus ermöglicht den Aufbau und Betrieb einer eigenen IaaS Cloud-Infrastruktur. Die API von Eucalyptus ist kompatibel zu Amazon EC2, S3 und EBS [13]. Die Software-Entwicklung geschieht unter der BSD Lizenz und ist damit OpenSource. 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 HardwareVirtualisierung (AMD-V bzw. Pacifica oder Intel VT-x bzw. Vanderpool) vorhanden ist. Eine Unterstützung für VMwareProdukte ist in naher Zukunft geplant.

6.2.1 Architektur und Komponenten Die Eucalyptus-Infrastruktur besteht aus drei Komponenten (siehe Abb. 6.3). Diese sind Cloud Controller (CLC), Cluster Con-

6.2 Eucalyptus

75 EC2 und S3 Schnittstelle Client-side API Translator

Cloud Controller

Walrus (S3)

DB

Öffentliches Netzwerk

Cluster Controller

Cluster Controller

Privates Netzwerk

Privates Netzwerk

...

Node Controller

Node Controller

Node Controller

Node Controller

Node Controller

Node Controller

Node Controller

Node Controller

Node Controller

Node Controller

Node Controller

Node Controller

Node Controller

Node Controller

Node Controller

Node Controller

Node Controller

Node Controller

...

Abb. 6.3 Architektur und Komponenten von Eucalyptus

troller (CC) und Node Controller (NC) [14]. 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 hierfü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

76

6 OpenSource Cloud Stack

Anzahl der virtuellen Prozessoren, den freien Hauptspeicher und den freien Festplattenspeicher. In jedem Cluster kümmert sich ein CC um die lastabhängige Verteilung (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. 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 [2].

6.3 Apache Hadoop Hadoop ist eine OpenSource Software-Plattform, mit der sich in einfacher Weise sehr große Datenmengen in einem Rech-

6.3 Apache Hadoop

77

nerverbund verarbeiten und analysieren lassen [28]. Mögliche Einsatzfelder von Hadoop sind z. B. Web-Indexing, Data Mining, Logfile-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 Filesystems. • 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. Die Firma Cloudera paketiert das Hadoop-System und es stehen verschiedene Hadoop-Distributionen im Internet als Download bereit [54].

6.3.1 MapReduce Hadoop implementiert das MapReduce-Programmiermodell, das auch in der Suchmaschine und den Anwendungen von Google eine große Rolle spielt [18]. Obwohl das Modell auf der massiv

78

6 OpenSource Cloud Stack

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. • 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 MapFunktion 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 Parallel-

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

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

Map HDFS Block 3 HDFS Block 3 HDFS Block 3

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

6.3 Apache Hadoop

79

verarbeitung 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 Filesystem 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 Abb. 6.4 gezeigt.

6.3.2 Hadoop Distributed File System Um die MapReduce-Funktionen robust und skalierbar zu implementieren, ist ein hochverfügbares und performantes Filesystem nötig. Hadoop verwendet zur Verarbeitung der Daten ein spezielles verteiltes Filesystem, 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 Files und speichert alle Metadaten zur Beschreibung des Systemstatus. Die Zahl der Files, die man im HDFS ablegen kann, ist in der Praxis durch die Hauptspeicherausstattung des Masterknotens limitiert, da sich aus Performance-Gründen alle Daten im Memory Cache befinden sollten. Systeme mit mehren hundert Millionen Files sollten mit aktueller Hardware zu realisieren sein. Hadoop splittet die Files 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

80

6 OpenSource Cloud Stack

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 ein sog. Rebuild statt, der neue verteilte Kopien der betroffenen Blöcke anlegt. Es ist wichtig, die Rebuild-Zeit 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 einen Rebuild 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 vermieden. 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.3.3 Pig Es gibt im Umfeld von Apache Hadoop eine Plattform mit dem Namen Pig [28]. Es handelt sich dabei um eine spezielle High-Level Programmierumgebung zur Formulierung von

6.3 Apache Hadoop

81

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.3.4 Hive Hive ist eine Data Warehouse Anwendung, die auf Hadoop [81] aufsetzt. Hive ermöglicht die Analyse von großen strukturierten Datensätzen im Hadoop Filesystem 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 MapReduceProgrammiermodell zu kombinieren.

82

6 OpenSource Cloud Stack

6.3.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 Service anzubieten. Insbesondere ist hier Amazon Elastic MapReduce [62] hervorzuheben, welches als Bestandteil der Amazon Web Services zur Verfügung steht. Amazon Elastic MapReduce basiert auf EC2 und kann Cluster auf nahezu beliebiger Skala nach aktuellem Bedarf bereitstellen. Das verteilte Filesystem von Hadoop arbeitet dabei mit dem S3-Service zusammen (siehe Abb. 6.5). Der Elastic MapReduce-Service 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 C Slaves) 3. Hadoop erzeugt einen Jobflow, der Daten von S3 aufs Cluster verteilt und prozessiert 4. Die Ergebnisse werden nach dem Prozessieren nach S3 kopiert 5. Benachrichtigung am Job-Ende: 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 [48]. 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 Service im Rahmen der Amazon Web Services zu nutzen: Es ist möglich, in der Amazon-Infrastruktur ein eigenes Hadoop-Cluster in einer dem Problem angemessenen Größe zu instanzieren. Dieses kann auf der Basis eines vorge-

6.4 Das OpenCirrusTM -Projekt 1

83

Request 2

Your host

Master

Elastic MapReduce

Response

5

Slave

3 4 Slave

Slave

Slave

EC2 cluster

Abb. 6.5 Amazon Elastic MapReduce (Quelle: Amazon)

fertigten Amazon Machine Images für Hadoop geschehen, welches Cloudera als Public AMI bei den Amazon Web Services bereitstellt.

6.4 Das OpenCirrusTM -Projekt Die Firmen HP, Intel und Yahoo! haben das OpenCirrusTMProjekt im Juli 2008 gestartet, zusammen mit den akademischen Partnern Infocom Development Authority Singapore Karlsruhe Institute of Technology (KIT) und University of Illinois Urbana Champaign (UIUC). Die Partner betreiben föderierte Ressourcenzentren zur Unterstützung der OpenSource Cloud-Systemforschung und stellen jeweils bis zu 1024 CPUCores sowie bis zu 1 Petabyte Speicher bereit. Die Aktivitäten umfassen sowohl Entwicklungen auf der Infrastrukturebene,

84

6 OpenSource Cloud Stack

der Plattformebene als auch auf der Anwendungsebene (siehe auch Kap. 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 OpenSource Cloud Stacks möglich [22]. Alle Nutzer des Systems müssen sich über das Portal [91] des Projekts registrieren. Im Portal sind nicht nur generelle Informationen über das Projekt verfügbar, sondern man kann dort 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 [101]. 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

6.4 Das OpenCirrusTM -Projekt

85

realisiert die Überwachung mit dem OpenSource-Produkt Ganglia [68]. 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 XMLStreams an einen zentralen Web-Server weiterleitet, der diese sammelt und konsolidiert [87]. Ausgehend von dieser Grundlage steht die Entwicklung und Einführung weiterer globaler Dienste an: Es handelt sich hier um Dienste für die gemeinsame Datenhaltung und die verteilte Anwendungsentwicklung. Die Partner betreiben im Projekt die Weiterentwicklung der zuvor diskutierten OpenSource-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 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.

86

6 OpenSource Cloud Stack

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 [91].

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 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 und insbesondere von Testprojekten, 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 entwiBaun C., Kunze M., Nimis J., Tai S., Cloud Computing DOI 10.1007/978-3-642-01594-6, © Springer 2010

87

88

7 Wirtschaftliche Betrachtungen

ckelten. Prominente Beispiele hierfür sind das TimesMachineProjekt der New York Times [90] oder die Videodienste der Firma Animoto [44]. 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 das Bedürfnis, sechs Millionen Artikel des gesamten New York Times Archivs seit 1851 als PDF-Dateien im Web-Lesern zur Verfügung zu stellen. Konventionelle Ansätze zur Generierung von PDFDateien aus den Scans der Artikel im TIFF-Format erwiesen sich als sehr zeit- und kostenaufwändig; bei einem Volumen von vier Terabyte von 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. Um solche Anfragen überhaupt und zudem zeitgemäß 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

89

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, z. B. in der Filmindustrie. 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

90

7 Wirtschaftliche Betrachtungen

Ressourcen können Fixkosten reduziert und in operative Kosten umgewandelt werden. Nutzungsabhängige Abrechnungsmodelle (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 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

91

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 operationale Kosten wie Strom und Energie (insbesondere für die Kühlung der Rechner), Miet- und Grundstückskosten, oder auch Personalkosten für die Systemadministration berücksichtigt werden müssen. Auch bedarf die Berechnung der Kosten für einen CloudDienst 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.

92

7 Wirtschaftliche Betrachtungen

7.2.2 TCO Framework Ein speziell für das Cloud Computing entwickeltes TCO (Total Cost of Ownership) Framework wird in [15] vorgestellt. Ausgehend von einer qualitativen Analyse der Anwendung (business scenario) 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 eine Checkliste evaluiert werden.

7.3 Geschäftsmodelle Im Cloud Computing sind neue Geschäftsmodelle zu beobachten, die je nach Platzierung der Service-Angebote im Cloud Computing Stack 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 Aspekten des Lebens und der Wirtschaft führt zu vielen neuartigen IT-basierten Diensten in einer Dienstleistungsgesellschaft.

7.3 Geschäftsmodelle

Abb. 7.1 TCO Framework

93

94

7 Wirtschaftliche Betrachtungen

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 Providern, zum Beispiel für das Monitoring und Management von Cloud-Anwendungen. Hier sind Marktund Geschäftsmodelle im Kontext der Kombination von CloudDiensten 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 Lizenz-basierte 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 Forschungsgebiet, das durch eine sehr aktive Industrie geprägt wird. Sowohl große, traditionsreiche Firmen wie die IBM, HP, oder SAP, als auch jüngere Unternehmen wie Google und Amazon, sowie 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 ITServices grundlegend 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 Providern existiert bereits. Unterschiedlichste Services können entwickelt, getestet, und betrieben werden. Es handelt sich dabei einerseits um kommerzielle Public Cloud-Angebote im Bereich der InfraBaun C., Kunze M., Nimis J., Tai S., Cloud Computing DOI 10.1007/978-3-642-01594-6, © Springer 2010

95

96

8 Chancen und Risiken

struktur, der Plattform und der Anwendung. Andererseits ist die Einrichtung von Private Clouds durch Produkte wie z. B. VMware vSphere [106] oder OpenSource-Entwicklungen wie Eucalyptus [64] 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 Service Levels 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. neuerdings entsprechende Import- und Exportdienste für großvolumige Datensätze an. 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-,

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 97

98

8 Chancen und Risiken

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.

8.3 Fazit Von der ökonomischen Seite betrachtet ist Cloud Computing mittlerweile einer der stärksten Wachstumsmärkte in der ITBranche: Laut Gartner beträgt der Umsatz mit Cloud Services 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 CIOs und IT-Manager rechtzeitig mit dem innovativen Thema Cloud Computing auseinandersetzen und ihre IT-Landschaften entsprechend ertüchtigen. Zugleich sind viele weiterführende, technologische Entwicklungen zu beobachten, wie beispielsweise Google Chrome OS. Dieses für 2010 angekündigte, leichtgewichtige Open SourceBetriebssystem verzichtet im Gegensatz zu klassischen Betriebssystemen weitestgehend auf lokale Anwendungen. Diese werden durch Cloud-Dienste ersetzt [70]. 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 kurzen und prägnanten Überblick über die aktuellen Entwicklungen, Techniken und Trends zu vermitteln.

Kapitel 9

Anhang

9.1 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 [64] von Eucalyptus detailliert beschrieben. Für die Steuerung der Eucalyptus Cloud-Infrastruktur werden die EC2-Kommandozeilenwerkzeuge von Amazon installiert. Von Eucalyptus erreichbare Ressourcen gibt das Kommando ec2-describe-availability-zones verbose aus. Es wird die Anzahl der existierenden und der freien Ressourcen ausgegeben. 5 Kategorien virtueller Maschinen mit unterschiedlicher Leistungsfähigkeit hinsichtlich Rechenleistung, Hauptspeicher und Festplattenkapazität sind definiert. Bei den 5 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)

Baun C., Kunze M., Nimis J., Tai S., Cloud Computing DOI 10.1007/978-3-642-01594-6, © Springer 2010

99

# ec2-describe-availability-zones verbose AVAILABILITYZONE Cluster1 iwrcgblade11 AVAILABILITYZONE |- vm types free / max cpu ram disk AVAILABILITYZONE |- m1.small 0019 / 0024 1 128 10 AVAILABILITYZONE |- c1.medium 0019 / 0024 1 256 10 AVAILABILITYZONE |- m1.large 0008 / 0012 2 512 10 AVAILABILITYZONE |- m1.xlarge 0008 / 0012 2 1024 20 AVAILABILITYZONE |- c1.xlarge 0002 / 0006 4 2048 20 AVAILABILITYZONE |- iwrcgblade11 certs[cc=false,nc=false] @ Thu May 28 11:04:24 AVAILABILITYZONE |- iwrcgblade12 certs[cc=false,nc=false] @ Thu May 28 11:04:24 AVAILABILITYZONE |- iwrcgblade13 certs[cc=false,nc=false] @ Thu May 28 11:04:24 AVAILABILITYZONE |- iwrcgblade30 certs[cc=false,nc=false] @ Thu May 28 11:04:24

Freie Ressourcen und verfügbare Kategorien von Instanzen

CEST 2009

CEST 2009

CEST 2009

CEST 2009

100 9 Anhang

9.1 Installation und Bedienung von Eucalyptus

101

Tabelle 9.1 Rechenleistung der Instanzen bei Eucalyptus und Amazon EC2 Kategorie

CPU (Eucalyptus)

CPU (Amazon EC2)

m1.small c1.medium m1.large m1.xlarge c1.xlarge

1 virtual CPU 1 virtual CPU 2 virtual CPUs 2 virtual CPUs 4 virtual CPUs

1 EC2 Compute Unit 5 EC2 Compute Unit 8 EC2 Compute Units 4 EC2 Compute Units 20 EC2 Compute Units

Tabelle 9.2 Hauptspeicher der Instanzen bei Eucalyptus und Amazon EC2 Kategorie

CPU (Eucalyptus)

CPU (Amazon EC2)

m1.small c1.medium m1.large m1.xlarge c1.xlarge

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

1,7 GB RAM 1,7 GB RAM 7,5 GB RAM 15 GB RAM 7 GB RAM

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 standardmäßig zugewiesenen Ressourcen. Siehe hierzu Tabellen 9.1 und 9.2. Amazon kalkuliert die Rechenleistung mit EC2 Compute Units. Eine EC2 Compute Unit ist bezüglich der 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 [37]. Um virtuelle Maschinen (Instanzen) in der Cloud zu starten, muss zuvor mindestens ein Dateisystem mit einem installierten Betriebssystem, ein Kernel und eventuell eine Ramdisk bei Eucalyptus als Image registriert werden. Dieses geschieht mit den Kommandos ec2-bundle-image, ec2-upload-bundle und ec2-register.

# ec2-describe-images IMAGE emi-1DE4116D debian5/debian5.img.manifest.xml admin available public x86_64 machine IMAGE eki-791612FF kernel26/vmlinuz-2.6.26.manifest.xml admin available public x86_64 kernel IMAGE eri-CFBE1450 ramdisk26/initrd.img-2.6.26.manifest.xml admin available public x86_64 ramdisk

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

# ec2-bundle-image -i debian5.img # ec2-upload-bundle -b image-debian5 -m /tmp/debian5.img.manifest.xml # ec2-register image-debian5/debian5.img.manifest.xml

Betriebssystem Image (Dateisystem) registrieren

# ec2-bundle-image -i /boot/initrd.img-2.6.26 --ramdisk true # ec2-upload-bundle -b ramdisk26 -m /tmp/initrd.img-2.6.26.manifest.xml # ec2-register ramdisk26/initrd.img-2.6.26.manifest.xml

Ramdisk registrieren

# ec2-bundle-image -i /boot/vmlinuz-2.6.26 --kernel true # ec2-upload-bundle -b kernel26 -m /tmp/vmlinuz-2.6.26.manifest.xml # ec2-register kernel26/vmlinuz-2.6.26.manifest.xml

Kernel Image registrieren

102 9 Anhang

9.1 Installation und Bedienung von Eucalyptus

103

Bei der Registrierung erhalten die Dateisystem/Kernel/Ramdisk Images eindeutige Bezeichner, die so genannten Eucalyptus Machine Images (emi-xxxxxxxx), Eucalyptus Kernel Images (eki-xxxxxxxx) und Eucalyptus Ramdisk Images (eri-xxxxxxxx). Eine Übersicht über die installierten Dateisystem/Kernel/Ramdisk Images liefert das Kommando ec2describe-images. Bevor man die virtuellen Maschinen startet, sollte ein Schlüsselpaar generiert werden, damit man später auf die Ressource zugreifen kann. Der private Schlüssel wird nach Aufruf des Kommandos ec2-add-keypair zurückgegeben und zur weiteren Verwendung in einem File gespeichert: # ec2-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 ec2-describe-keypairs aufgelistet werden: # ec2-describe-keypairs KEYPAIR mykey 33:da:6e:13:96:e6:f7:3b: b7:34:a6:28:ba:2f:64:ab:83:70:ef:70 Die Images werden anschließend in Form von Instanzen mit dem Kommando ec2-run-instances gestartet. Sind mehr Ressourcen als in der einfachsten Kategorie (m1.small) nötig, kann beim Starten einer Instanz einfach eine höherwertige 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 Maschine zugegriffen werden kann.

default 0.0.0.0 141.52.166.160 m1.small eri-CFBE1450 default 0.0.0.0 141.52.166.161 m1.small eri-CFBE1450

Beide Instanzen beenden

admin emi-1DE4116D 0 eki-791612FF admin emi-1DE4116D 0 eki-791612FF

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

# ec2-describe-instances RESERVATION r-3DDE07D9 INSTANCE i-4901084F running mykey 2009-05-13T13:50:37+0000 RESERVATION r-42FA0732 INSTANCE i-463B08BE running mykey 2009-05-13T13:50:10+0000

Übersicht über die laufenden Instanzen

# ec2-run-instances emi-1DE4116D --kernel eki-791612FF --ramdisk eri-CFBE1450 -k mykey -n 2 -t m1.small

Zwei Instanzen starten

104 9 Anhang

9.2 Data Mining mit Amazon Elastic MapReduce

105

Wurden Instanzen gestartet, können diese mit dem Kommando ec2-describe-instances beobachtet werden. Jede Instanz hat eine IP-Adresse und eine eindeutige Instanznummer (i-xxxxxxxx). Man kann sich per Secure Shell mit dem beim Starten angegebenen Schlüssel auf einer virtuellen Maschine anmelden: # ssh -i mykey.private 141.52.166.160 Das Kommando ec2-terminate-instances beendet eine oder mehrere Instanzen. Die hier vorgestellten EC2-Kommandozeilenwerkzeuge gehören zu den am häufigsten benötigten Kommandos. Einfacher als über die Kommandozeilenwerkzeuge ist die Steuerung mit Hilfe grafischer Werkzeuge wie ElasticFox [61].

9.2 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: • 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 [48] gelöst werden, wie in Kap. 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 Gutenberg-

106

9 Anhang

Projekt [78] und kann sie von dort als ASCII-Files herunterladen. Die Texte müssen als Eingabe zu Amazon S3 übertragen und in einem gemeinsamen Directory gespeichert werden (z. B. mit S3Fox in /input). 2. Create a Job Flow on Amazon Elastic Map Reduce: Nach dem Drücken des Buttons 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 AusgabeDirectory (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 ausgeführt. Die Mapping-Funktion läuft parallel auf den spezifizierten EC2-Instanzen. Sie splittet die Texte in jedem File und gibt diese in Form von Listen aus. Die Wortlisten werden von den ebenfalls parallel laufenden Reducer-Knoten 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

9.2 Data Mining mit Amazon Elastic MapReduce

107

entweder mit S3Fox oder für freigegebene Files 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 1004 das 975 zu 954 nicht 856 ein 850 ist 804 sich Wer ist der meistgenannte Akteur? # grep mephisto Ergebnis 471 mephistopheles 1 mephisto

108

# 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

9 Anhang

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. Baun C und Kunze M. Infrastrukturen für Clouds mit Eucalyptus selbst aufbauen. iX 4/2009. S.128–130. Heise Zeitschriften Verlag 3. Baun C, Kunze M und Ludwig T. Servervirtualisierung. InformatikSpektrum 3/2009. S.197–205 4. 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 5. 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 6. Carr N. The Big Switch. Rewiring the World, from Edison to Google. W.W.Norton. 2008 7. 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

109

110

Literaturverzeichnis

8. Chisnall D. The Definitive Guide to the Xen Hypervisor. Prentice Hall. USA. 2008 9. Dostal W, Jeckle M, Melzer I und Zengler B. Service-orientierte Architekturen mit Web Services. Spektrum. 2005 10. 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 11. HP Integrated Lights-Out 2 User Guide. HP 12. 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 13. Nurmi D, Wolski R, Grzegorczyk C, Obertelli G, Soman S, Youseff L, and Zagorodnov D. The Eucalyptus Open-source Cloud-computing System. Oktober 2008 14. 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 15. 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 16. 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 17. 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 18. Dean J and Ghemawat S. MapReduce: Simplified Data Processing on Large Clusters. OSDI2004. San Franzisko. 2004. 19. Benslimane D, Dustdar S, and Sheth A. Services Mashups: The New Generation of Web Applications. IEEE Internet Computing. http://dx.doi.org/10.1109/MIC.2008.110. IEEE Educational Activities Department. Piscataway. NJ. USA 20. 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

Literaturverzeichnis

111

21. Keahey K and Freeman T. Contextualization: Providing One-Click Virtual Clusters. eScience 2008 22. Campbell R, Gupta I, Heath M, Ko S, Kozuch M, Kunze M, Kwan T, Lai K, Lee HY, Lyons M, Milojicic D, O’Hallaron D, and Soh YC. Open CirrusTM Cloud Computing Testbed: Federated Data Centers for Open Source Systems and Services Research. HotCloud09. San Diego. Juni 2009 23. McKeown N, Anderson T, Balakrishnan H, Parulkar G, Peterson L, Rexford J, Shenker S, and Turner J. OpenFlow: Enabling Innovation in College Networks. 2008 24. Schäfer A. Die Kraft der schöpferischen Zerstörung. Campus. 2008 25. Sprang H, Benk T, Zdrzalek J, und Dehner R. Xen. Virtualisierung unter Linux. Open Source Press. München. 2007 26. Varia J. Cloud Architectures, White Paper, Amazon. 2009 27. Wang L. Virtual environments for Grid computing. Universitätsverlag Karlsruhe. 2009 28. White T. Hadoop – The Definite Guide. O’Reilly Verlag. 2009 29. Wohlstadter E und Tai S. Web Services. Reference Entry. Encyclopedia of Database Systems (EDBS). Springer. 2009 30. 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

Online-Quellen 31. Scalable High Performance Data Storage for Web Applications http://www.10gen.com 32. EdgePlatform http://www.akamai.com/en/html/technology/edgeplatform.html 33. Amazon CloudFront http://aws.amazon.com/cloudfront/ 34. Amazon Elastic Compute Cloud (Amazon EC2) http://aws.amazon.com/ec2/ 35. Amazon Elastic Map Reduce http://aws.amazon.com/elasticmapreduce/ 36. AWS Import/Export http://aws.amazon.com/importexport/

112

Literaturverzeichnis

37. Amazon EC2 Instance Types http://aws.amazon.com/ec2/instance-types/ 38. Amazon Mechanical Turk http://www.mturk.com 39. Amazon Simple Storage Service (Amazon S3) http://aws.amazon.com/s3/ 40. Amazon SimpleDB http://aws.amazon.com/simpledb/ 41. Amazon Simple Queue Service (Amazon SQS) http://aws.amazon.com/sqs/ 42. AWS Toolkit for Eclipse http://aws.amazon.com/eclipse/ 43. Amazon Webservices Homepage http://aws.amazon.com 44. Animoto http://animoto.com 45. AppExchange http://sites.force.com/appexchange/home 46. 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 47. AppNexus Cloud http://www.appnexus.com 48. AWS Management Console http://console.aws.amazon.com 49. Amazon Elastic Compute Cloud. Getting Started Guide http://docs. amazonwebservices.com/AWSEC2/latest/GettingStartedGuide/ 50. Azure Services Platform http://www.microsoft.com/azure/ 51. Bluelock http://www.bluelock.com 52. Project Caroline http://research.sun.com/projects/caroline 53. Cloud Hosting and Cloud Storage Performance Dashboard http://www.cloudclimate.com 54. Cloudera http://www.cloudera.com 55. Amazon CloudWatch http://aws.amazon.com/cloudwatch/

Literaturverzeichnis

113

56. Security Guidance for Critical Areas of Focus in Cloud Computing, Cloud Security Alliance, 2009 http://www.cloudsecurityalliance.org/guidance/csaguide.pdf 57. DeveloperForce http://developer.force.com 58. Django Web Framework http://www.djangoproject.com 59. Secure backup, sync and sharing made easy http://www.getdropbox.com 60. Eclipse http://www.eclipse.org 61. Firefox Extension for Amazon EC2 http://sourceforge.net/projects/elasticfox/ 62. Amazon Elastic MapReduce http://aws.amazon.com/elasticmapreduce/ 63. Virtual Private Datacenters http://www.enkiconsulting.net/virtual-private-data-centers/ 64. Eucalyptus: Elastic Utility Computing Architecture for Linking Your Programs To Useful Systems http://open.eucalyptus.com 65. FlexiScale Cloud Computing http://www.flexiscale.com 66. fluidOps eCloudManager http://www.fluidops.com/ecloudmanager.html 67. Force http://www.salesforce.com/de/platform/ 68. Ganglia Monitoring System http://ganglia.info 69. Google App Engine SDK http://code.google.com/intl/de/appengine/downloads.html 70. Introducing the Google Chrome OS http://googleblog.blogspot.com/2009/07/introducing-google-chromeos.html 71. Google Docs http://docs.google.com 72. g-Eclipse http://www.geclipse.org 73. The Google File System http://labs.google.com/papers/gfs.html

114

Literaturverzeichnis

74. Google Maps API http://code.google.com/apis/maps/ 75. GoGrid Cloud Hosting http://www.gogrid.com 76. Google Apps Engine http://www.google.com/apps/ 77. Google Plugin for Eclipse http://code.google.com/intl/de/appengine/docs/java/tools/eclipse.html 78. Projekt Gutenberg http://www.gutenberg.org 79. OpenSocial API http://code.google.com/apis/opensocial/ 80. Hadoop Homepage http://hadoop.apache.org 81. Hive! http://hadoop.apache.org/hive/ 82. Reasonably Smart ttp://www.joyent.com 83. Reliable online backup and storage powered by Amazon S3 and Rackspace http://www.jungledisk.com 84. Facebook Platform http://developers.facebook.com 85. Office Live http://www.officelive.com 86. Live Mesh https://www.mesh.com 87. OpenCirrusTM (Global) Monitoring https://opencirrus.org/content/global-monitoring/ 88. SuiteFlex http://www.netsuite.com 89. Storage Delivery Network http://www.nirvanix.com 90. New York Times Archives + Amazon Web Services = TimesMachine http://open.blogs.nytimes.com/2008/05/21/the-new-york-timesarchives-amazon-web-services-timesmachine/ 91. OpenCirrusTM http://opencirrus.org 92. OpenId http://www.openid.net

Literaturverzeichnis

115

93. Rackspace Managed Hosting http://www.rackspace.com 94. Michal Ludvig, s3cmd: command line S3 client http://s3tools.org/s3cmd/ 95. S3Fox Organizer(S3Fox) http://www.s3fox.net 96. Salesforce Community http://www.salesforce.com/community/ 97. Salesforce CRM http://www.salesforce.com/de/crm/ 98. Thomas Sandholm, Hadoop User Group Presentation http://tycoon.hpl.hp.com/ tycoon/grid/HadoopUserGroupSept08.ppt 99. Skytab Virtual Lab http://www.skytap.com 100. Empowering the Service Industry with SLA-aware Infrastructures http://sla-at-soi.eu 101. OpenSSH http://www.openssh.com 102. Tashi: Cloud Computing on Big Data http://www.pittsburgh.intel-research.net/projects/tashi/ 103. Infinistructure http://www.terremark.com/services/managed-hosting.aspx 104. flexIT – Mehr Flexibiltät für Ihr IT Business mit flexIT von todo http://www.todo.de/Produkte/flexIT.php 105. VMware http://www.VMware.com 106. VMware vSphere http://www.vmware.com/products/vsphere/ 107. Web Services Architecture Requirements. W3C Working Draft 29 April 2002 http://www.w3.org/TR/2002/WD-wsa-reqs-20020429 108. YouTube http://www.youtube.com 109. Zimory Public Cloud Market http://www.zimory.de 110. Zoho Creator http://www.zoho.com 111. Hybrid Cloud storage for all your documents and media http://zumodrive.com

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 Implementierung der Google App Engine auf Basis von Eucalyptus. AWS Amazon Web Services. Sammlung verschiedener CloudComputing Web-Dienste von Amazon. Cluster Gruppe eng miteinander vernetzter Computer, die gemeinsam verwaltet und genutzt werden. Cloud Bereitstellung skalierbarer IT-Services in Form von WebDiensten mit verbrauchsabhängiger Abrechnung. 117

118

Glossar

CRM Customer Relationship Management. Unterstützt die Kommunikation mit Kunden. Gewährleistet standardisierte Arbeitsvorgänge im Bezug auf Marketing, Vertrieb und Kundendienst. 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 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. 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 auf der Basis von Hadoop. Hybrid Cloud Kombination aus Public und Private Clouds.

Glossar

119

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. (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. 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.

120

Glossar

Private Cloud Cloud-Dienste werden innerhalb eines Unternehmens betrieben (inhouse). Public Cloud Cloud-Dienste werden von einem externen Cloud-Anbieter betrieben. 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. 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. 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. URI Uniform Resource Identifier. Zeichenfolge zur einheitlichen Bezeichnung einer Ressource.

Glossar

121

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. XML Extensible Markup Language. Standardisierte Sprache zur Darstellung hierarchisch strukturierter Informationen in Form von Textdaten.

Sachverzeichnis

A Accounting 61 Amazon Web Services 39, 40, 63, 84 Elastic MapReduce 105 AMI 42 Availability Zone 42 AWS Zusammenspiel 50 CloudFront 41 CloudWatch 63 EBS 44, 74 EC2 30, 40, 41, 63, 74 EC2 Compute Unit 45 Elastic Block Store 44, 46 Elastic Compute Cloud 40, 41 Elastic MapReduce 41, 63, 82 Job Flow 106 Import/Export 41 Machine Image 42 Mechanical Turk 37 S3 30, 40, 47, 64, 74, 82

Security Group 43 Simple Queue Service 48 Simple Queuing Service 40 Simple Storage Service 47 SimpleDB 31, 40, 49 SQS 31, 40, 48 Steuerung 63 Storage Service 40 Web-Konsole 63 Animoto 88 AppNexus 31 Automatisierung 61 Azure 33 B Best Effort 60 Betriebssystemkern Bioinformatik 77 Bucket 47

11

123

124 C Cloud Bursting 85 Cloud Computing Abrechnungsmodelle 90 Adoption 96 Anbieter 25 Angebote 39 Anwendungsgebiete 87 Architektur 25 Benutzer 25 Bewertung 96 Chancen 95 Cloud Computing 1, 4 Cloud Dienste 2, 95 Cloud Management 59, 62 Cloud Provider 69 Cloud Security Alliance 68 Cloud Service 61 Cloud Services 27, 39 Cloud Sourcing 67, 69 Dienstanbieter 61 Entwicklung 65 External Cloud 25 Geschäftsmodelle 92 Hybrid Cloud 27 Kostenmodelle 91 Management-Dienste 62 Marktentwicklung 95 Private Cloud 3, 26 Programmierung 65 Provider 95 Public Cloud 3, 25 Risiken 95 Risikomanagement 67 Schichten 29 Sicherheit 67 Überwachung 62 Vendor-Lock-in 69

Sachverzeichnis Wachstum 96 Wirtschaftliche Betrachtungen 87 Cloudera 77, 83 CloudFront 31 CRM 35 Customer Relationship Management 55 D Data Mining 77 Datenanalyse 81 Dienst 1 Dienstgüte 61 Disruptive Technology Django 33 Dropbox 30

95

E EC2-Kommandozeilenwerkzeuge 63, 99 ElasticFox 63, 105 Elastizität 90 Emulab 30, 72 Ensembles 85 Enterprise Service Bus 20 Eucalyptus 5, 30, 32, 33, 55, 74, 99 Architektur 74 Bedienung 99 Cloud Controller 74 Cluster Controller 75 Dateisystem Image 103 Infrastruktur 74 Installation 99 Instanzen 103 Instanznummer 105

Sachverzeichnis Kernel Image 103 Komponenten 74 Node Controller 75 Ramdisk Image 103 Ressourcen 99 Schlüsselpaar 103 Execution Environment 33 External Cloud 25 F Facebook 88 Fehlertoleranz 62 Finanzanalysen 77 FlexiScale 31 Force.com 56, 57 G Ganglia 85 Geschäftsmodelle 92 GoGrid 31 Google App Engine 33, 39, 52, 55, 69, 74, 84 Google Calendar 54 Google Chrome OS 98 Google Docs 35, 53, 54 Google Maps 35 Google Web Toolkit 54 GrepTheWeb 50 Grid Computing 4 Grundstückskosten 91 H Hadoop 5, 30, 77, 96 Hadoop as a Service 82 Hadoop Distributed File System 79

125 High Performance Computing Hive 81 Hochleistungsrechnen 85 HPCaaS 85 HTTP 22 HuaaS 29, 37 Hub-and-Spoke 20 Human as a Service 29 Hybrid Cloud 27 Hypercall 13 Hypervisor 12 I IaaS 29, 30, 55, 68, 69, 71 Identitätsmanagement 84 iLO 30, 31 Infiniband 85 Infrastructure as a Service 29 IOWA Electronic Markets 38 J Jails 11 Joyent 32, 33 JungleDisk 47 K Kernel-based Virtual Machine 13, 74 L Lebenszyklus 61 Linux-VServer 12 Logfile-Analysen 77 M Map-Funktion

78

85

126

Sachverzeichnis

MapReduce 30, 41, 77, 79, 81, 105 Maschinelles Lernen 77 Microsoft Office Live 35 Monitoring 84 MPI 86

Programming Environment Public Cloud 25, 74, 95

N

R

New York Times Nimbus 30, 32

88

O OLA 60 on-demand 94 on-premise 94 OpenCirrusTM 5 OpenID 35 OpenNebula 30 OpenSocial 35 OpenSource Cloud Stack 71 OpenVZ 12 Operation Level Agreement 60 overprovisioning 90 P PaaS 29, 33, 55, 68, 69, 71 pay as you go 90 Personalcomputer 95 Personalkosten 91 Physical Resource Set 30 Physisches Ressource Set 72 Picasa 54 Pig 80 Platform as a Service 29 Private Cloud 26, 74, 96

33

Q Quality of Service

60

Reduce-Funktion 78 Resource Set 29 REST 17, 19, 22, 47 S s3cmd 47 S3Fox 64 SaaS 29, 35, 55, 68, 69, 71 Salesforce.com 35, 39, 55, 56 saturation 90 Scheduling 86 Service Delivery Modelle 68 Service Level Agreement 59, 85 Service Level Management 60 Service Mashups 35 Service Monitoring 60 Service-Katalog 61 Service-Lebenszyklus 61 Service-orientierte Architekturen 16 Sicherheitstechniken 85 Single Sign-On 84 Skalierbarkeit 62 SLA 59 SOAP 19, 22, 47 SOAP Body 23 SOAP Envelope 23 SOAP Header 23 SOAP Nachricht 23

Sachverzeichnis

127

Software as a Service 29 Software-Lizenzen 86 Software-plus-Services 94 Standardisierung 85 Systemcall 13 T Tashi 73 Thematik 1 TimesMachine 88 Total Cost of Ownership Tycoon 31

92

Plattformvirtualisierung 12 SaaS 16 Speichervirtualisierung 13 Virtualisierung 2, 4, 7, 8, 10, 11 Virtuelle Maschine 8 Virtueller Maschinen Monitor 12 Vorteile 8 Virtuelles Ressource Set 73 Virtuozzo 12 VMware vSphere 96

U

W

UDDI 19 underprovisioning 90 underutilization 90 Uniform Resource Identifier 21, 22 Utility Computing 2

Web Protokolle 17 Web Services 17 Web-Indexing 77 wissenschaftliche Simulationen 77 WSDL 19, 22

V Vendor-Lock-In 35, 96 Virtual Distributed Ethernet 76 Virtualisierung Anwendungsvirtualisierung 15 Betriebssystemvirtualisierung 10 Container 11, 12 Gast-Betriebssystem 13 Hypercall 13 Hypervisor 12 Nachteile 10 Netzwerkvirtualisierung 15 Para-Virtualisierung 13

X XaaS 29 Xen 13, 30, 74 XML 20, 21 Y YouTube

38

Z Zimory 32, 61, 68 Zumodrive 30