Hochschule der Medien Stuttgart Fakultät Druck und Medien Computer Science and Media. Master-Thesis. Automatische Skalierung mit Amazon Webservices

Größe: px
Ab Seite anzeigen:

Download "Hochschule der Medien Stuttgart Fakultät Druck und Medien Computer Science and Media. Master-Thesis. Automatische Skalierung mit Amazon Webservices"

Transkript

1 Hochschule der Medien Stuttgart Fakultät Druck und Medien Computer Science and Media Master-Thesis Automatische Skalierung mit Amazon Webservices zur Erlangung des akademischen Grades Master of Science Eingereicht von: Matrikelnummer: Eingereicht am: Volker Tietz Erstprüfer: Zweitprüfer: Prof. Dr. Simon Wiest Christian Feser (Master of Science)

2

3 Eidesstattliche Versicherung Hiermit versichere ich, Volker Tietz, an Eides Statt, dass ich die vorliege Masterarbeit mit dem Titel: Automatische Skalierung mit Amazon Webservices selbständig und ohne fremde Hilfe verfasst und keine anderen als die angegebenen Hilfsmittel benutzt habe. Die Stellen der Arbeit, die dem Wortlaut oder dem Sinn nach anderen Werken entnommen wurden, sind in jedem Fall unter Angabe der Quelle kenntlich gemacht. Die Arbeit ist noch nicht veröffentlicht oder in anderer Form als Prüfungsleistung vorgelegt worden. Ich habe die Bedeutung der eidesstattlichen Versicherung und die prüfungsrechtlichen Folgen ( 26 Abs. 2 Bachelor-SPO (6 Semester), 23 Abs. 2 Bachelor-SPO (7 Semester) bzw. 19 Abs. 2 Master-SPO der HdM) sowie die strafrechtlichen Folgen (gem. 156 StGB) einer unrichtigen oder unvollständigen eidesstattlichen Versicherung zur Kenntnis genommen. Stuttgart, den Volker Tietz i

4

5 Kurzfassung/Abstract Diese Masterthesis beschäftigt sich mit der Umsetzung einer Web-Anwung mit Amazon Web Services und die damit einhergehen Chancen und Besonderheiten die Cloud Computing bietet. Dabei liegt das Hauptaugenmerk auf den Auto Scaling Features die Amazon bereithält. In diesem Rahmen wird untersucht wie ein gegebener Anwungsfall am Besten umgesetzt werden kann, damit unabhängig von der Anzahl der Nutzer der Dienst mit gleichbleiber Performance betrieben werden kann. Die Evaluierung zeigt, dass sich zwar eine funktioniere Lösung für den Anwungsfall ergibt, diese jedoch für diesen speziellen Anwungsfall nicht die kosteneffizienteste Lösung darstellt. This master thesis is about the implementation of a web application with Amazon Web Services and all the characteristics and opportunities that come along with cloud computing. The focus is on the Auto Scaling features which are provided by Amazon. The studies include an evaluation of how a given use case can be implemented with a steady performance of the application, regardless of the amount of users which use the service at the same time. The evaluation shows a working solution for this specific use case, which is however not the most cost-efficient solution. iii

6

7 Abbildungsverzeichnis 1.1 Architektur-Entwurf Basistechnologien für Cloud-Computing nach [CM11] Nutzungsmodelle des Cloud Computing Zeitstrahl der Amazon Produkte aus [Vli11] Prozentualer Anteil aller Internetbesucher die amazon.com besuchen. Quelle: [Ale12b] Konzept der Regionen und Availablity Zones. [Ser12e] Funktionsweise des Auto Scaling AutoScaling Setup auf Basis der durchschnittlichen CPU Auslastung Fehlerhaftes Verhalten von CloudWatch währ dem zweiten Testdurchlauf für Ansatz Vergleich der Tests nach Dauer in Sekunden für 30 Jobs Hybride Lösung mit manueller Auslösung der Scaling Policies für Aufwärtsskalierung Vergleich der Tests nach Dauer in Sekunden für 30 Jobs v

8

9 Listings 1.1 Beispiel für die Package Parameter in der config.json Beispiel einer IAM Policy Output bei einem Worker Test mit 10 Jobs für einen Worker A.1 Setup Task mit dem Testdaten generiert werden A.2 Start Task mit dem Jobs eingestellt und überwacht werden A.3 Rake Task zum Erstellen und Löschen der AutoScaling Konfiguration 69 A.4 Klasse zur Steuerung der AutoScaling Konfiguration A.5 Rake Task zum Erstellen und Löschen der Hybriden AutoScaling Konfiguration A.6 Klasse zur Steuerung der Hybriden AutoScaling Konfiguration vii

10

11 Tabellenverzeichnis 3.1 Instanz-Typen bei EC Soll-Anzahl der aktiven Worker nach Anzahl anfaller Jobs bei hybrider Skalierung Fixe Kosten im Überblick Variable Kosten im Überblick Die Beispielkalkulation im Überblick ix

12

13 Inhaltsverzeichnis Eidesstattliche Versicherung Kurzfassung/Abstract i iii 1 Einleitung Ziel dieser Masterthesis Vorstellung des Projekts Konzeptioneller Ablauf beim Erstellen eines Builds Warum Amazon Webservices? Welche AWS Dienste kommen in Frage? Cloud-Computing Was ist Cloud-Computing? Nutzungsmodelle Liefermodelle Sicherheit und Datenschutz in der Cloud Cloud Computing für Entwickler Vermeidung von SPOFs Load-Balancing Datenbank-Skalierung CDN und geografische Verfügbarkeit Zusammenfassung Allgemeine Vorteile für Cloud-Nutzer Allgemeine Nachteile für Cloud-Nutzer Amazon Webservices Business Case aus Sicht von Amazon Generelle Konzepte bei AWS Zugriff über API Regionen und Availability Zones Preisgestaltung Sicherheit und Datenschutz Im Projekt verwete Dienste Simple Storage Service (S3) Simple Queue Service (SQS) CloudWatch xi

14 Inhaltsverzeichnis Elastic Compute Cloud (EC2) Ruby Gem aws-sdk Auto-Scaling AWS Tests für AutoScaling Testablauf Skalierungsansätze Ansatz 1: AutoScaling auf Basis der durchschnittlichen CPU- Auslastung Ansatz 2: AutoScaling auf Basis eingestellter Nachrichten die MessageQueue Ansatz 3: Hybrides AutoScaling mit manueller Auslösung von Scaling Policies Zusammenfassung Mögliche theoretische Lösung der Problematik Kostenplanung Fixkosten Variable Kosten Beispielkalkulation Lessons Learned und Fazit Lessons Learned Fazit A Listings 67 A.1 Worker Tests A.2 AutoScaling Ansatz A.3 HybridScaling Ansatz Literaturverzeichnis 83 xii

15 Kapitel 1 Einleitung Diese Arbeit ist die Thesis zur Erlangung des akademischen Grades des Master of Science im Studiengang Computer Science and Media der Hochschule der Medien Stuttgart. Entstanden ist diese Arbeit in Zusammenarbeit mit dem Unternehmen M-Way Solutions GmbH in Stuttgart. Als der damalige Google CEO Eric Schmidt im August 2009 auf der Search Engine Strategies Conference in einem Interview erstmalig von einem neuen Konzept, dem sogenannten Cloud-Computing sprach, begann ein Hype um dieses Wort der bis heute anhält. Schmidt beschrieb das Konzept damals mit den folgen Worten: What s interesting [now] is that there is an emergent new model, and you all are here because you are part of that new model. I don t think people have really understood how big this opportunity really is. It starts with the premise that the data services and architecture should be on servers. We call it cloud computing they should be in a cloud somewhere. And that if you have the right kind of browser or the right kind of access, it doesn t matter whether you have a PC or a Mac or a mobile phone or a BlackBerry or what have you or new devices still to be developed you can get access to the cloud. There are a number of companies that have benefited from that. Obviously, Google, Yahoo!, ebay, Amazon come to mind. The computation and the data and so forth are in the servers. Eric Schmidt [Sch06] Technisch gesehen handelt es sich beim Cloud Computing um kein neues Konzept. Genau genommen bedient es sich der bereits länger bekannten Client-Server Technologie. Der Client dient nur noch dazu Daten abzurufen und darzustellen. Aufgaben wie zum Beispiel Datenverarbeitung und -speicherung bleiben dem Server in der Wolke überlassen. Der Begriff der Cloud ist dabei pass gewählt, da zwar dem Endbenutzer möglicherweise bekannt ist in welchem Rechenzentrum sich der Server befindet, aber nicht unbedingt der Server selbst, auf dem sich die Daten befinden. Die geografischen und geopolitischen Umstände sind somit diffus wie eine Wolke. 1

16 1.1 Ziel dieser Masterthesis Der Zugriff auf die Daten und Anwungen in der Wolke findet in den meisten Fällen über den Browser statt. Währ die Aufgabe eines Browsers früher darin bestand, einfache HTML-Dokumente für den menschlichen Benutzer strukturiert und ästhetisch darzustellen, sind diese heute technologisch sehr stark ausgereift. Dank JavaScript lassen sich inzwischen Anwungen für den Browser erstellen, die einer installierbaren Desktop-Anwung in Bezug auf Bedienung, Animationen und Echtzeit-Verarbeitung in Nichts nachstehen. Währ sich für die Endbenutzer als Laien der Begriff Cloud mehr oder weniger als Synonym für das Internet eingebürgert hat, sind die Änderungen aus unternehmerischer Sicht geradezu revolutionär: Wer Cloud-Dienste verwet, zahlt nur tatsächlich genutzte Ressourcen und spart sich somit weitreiche Investitionen im Vorfeld. Anschaffungen für Hardware und IT-Fachkenntnisse in diesem Bereich müssen nur noch vom Cloud-Anbieter getätigt werden. 1.1 Ziel dieser Masterthesis Das Ziel dieser Masterthesis besteht darin, herauszufinden welche Möglichkeiten Cloud-Computing bietet und soll dokumentieren wie diese anhand eines Projektes genutzt werden können. Im Fokus steht dabei mit Amazon Web Services (AWS) einer der größten Cloud Anbieter, dessen Dienste und Infrastruktur die spätere Produktivumgebung für das Projekt sein sollen. Neben einer betriebswirtschaftlichen Betrachtung, sollen vor allem auch die technischen Hintergründe und Problemstellungen beleuchtet werden. Wie der Titel der Thesis bereits verrät, soll nicht nur die einfache Nutzung, sondern auch die automatische Skalierung der Infrastruktur implementiert und dokumentiert werden. Bei dem umzusetzen Projekt handelt es sich um eine Plattform, bei der Benutzer über ein Web-Interface sogenannte Long running jobs in Auftrag geben, also rechenintensive Aufgaben die bis zu mehreren Minuten dauern können. Je nach Anzahl der Benutzer kann die Last auf den Servern, und damit die Anzahl der benötigten Server, variieren. Um bei einer hohen Anzahl von gleichzeitigen Benutzern trotzdem eine zeitnahe Fertigstellung der Jobs zu gewährleisten, müssen automatisch und kurzfristig neue Server in die Infrastruktur eingebunden werden. AWS bietet für sämtliche zur Verfügung gestellten Dienste ein Application Programming Interface (API) zur Steuerung an. Damit wird die aktuelle Last der Server gemessen und anhand dieser Daten eine Skalierung vorgenommen. Der gesamte Skalierungsprozess soll dabei automatisiert sein und darf keinen manuellen Eingriff durch einen Administrator erfordern. Bei einer kurzzeitigen Lastspitze sollen die zuvor neu erworbenen Ressourcen nach einer angemessenen Zeit wieder freigegeben werden, um zu hohe Kosten zu vermeiden. 2

17 Kapitel 1 Einleitung Innerhalb der Infrastruktur sollen die sogenannten Worker, die Server auf denen die Jobs abgearbeitet werden, komplett austauschbar sein. Ein Ausfall eines Servers darf maximal eine kleine Verzögerung in der Abarbeitung bedeuten, jedoch keinen Datenverlust. Die mit diesen Anforderungen einhergehen Probleme und Fragestellungen sind ebenfalls ein fester Bestandteil der Thesis. Um zu gewährleisten, dass die Implementierung erfolgreich ist, wird zusätzlich noch ein Lasttest der Infrastruktur und der Konfiguration für AutoScaling durchgeführt. Anhand der Testergebnisse sollen Aussagen über die zu erwarten Kosten getroffen werden können. 1.2 Vorstellung des Projekts Wie bereits zuvor beschrieben soll eine Plattform für Long-running Jobs entwickelt werden. Bei diesen Jobs handelt es sich um Build-Prozesse für Android- und ios-anwungen, also die Umwandlung von Sourcecode und Ressourcen (wie Bildern) in eine ausführbare APK-/IPA-Datei. Leider ist es nach aktuellem Stand nicht möglich, bei Amazon Server auf Basis des OSX Betriebssystems zu betreiben. Aus diesem Grund ist vorerst nur die Implementierung des Build-Prozess für Android durchführbar. Um Builds von ios Anwungen zu erstellt, ist die Xcode Entwicklungsumgebung von Apple nötig, die bisher nur auf OSX Servern verfügbar ist. Die Build-Plattform soll ein fester Bestandteil des Open-Source Produktes The-M- Project (TMP) der Firma Panacoda GmbH, einer Partnerfirma der M-Way Solutions GmbH, sein. TMP ist ein client-seitiges cross-platform Framework für mobile Anwungen auf Basis von JavaScript, HTML und CSS. Das Framework bietet die Möglichkeit mobile Anwungen zu entwickeln, die dann auf mehreren mobilen Plattformen gleich funktionieren und aussehen. Neben dem Framework wird ein in Node.js geschriebenes Build-Tool namens Espresso mitgeliefert, welches z.b. zum Generieren einer App-Struktur dient oder einen lokalen Server zum Entwickeln bereitstellt. Espresso wird auch zum packaging der Anwungen verwet. Es erstellt mithilfe von Phonegap die nativen Android bzw. ios Anwungen. Die Anwung ist danach (auch offline) auf dem Gerät verfügbar und stellt die in HTML und JavaScript erstellten Views in einer nativen WebView-Komponente dar. Dieser Build-Prozess verlangt, dass der Entwickler auf seinem Computer die entsprechen Software Development Kit (SDK) für die jeweilige Plattform installiert hat. Das SDK für ios ist, wie bereits angesprochen, nur auf OSX Systemen verfügbar. Ein Entwickler der für alle Plattformen entwickeln möchte, braucht deswegen auf jeden Fall einen Computer mit OSX. Für Firmen die bisher zur Software-Entwicklung Linux oder Windows Rechner eingesetzt haben, fallen somit Anschaffungskosten für neue Computer an. 3

18 1.2 Vorstellung des Projekts Eine Lösung für dieses Problem sieht vor, einen Teil des Entwicklungsprozesses in die Cloud zu verlagern. Potentielle Entwickler, die das TMP Framework für die Entwicklung ihrer Apps nutzen, können dann ihren erstellten Sourcecode mithilfe des Web-Portals hochladen, dort entspreche Konfigurationen anlegen und mit einem Klick den Build-Prozess starten. Langfristig soll das Portal die komplette Entwicklung in der Cloud ermöglichen. Inklusive einer IDE im Browser und Source- Code-Management (SCM). Im Rahmen der Masterthesis wird allerdings nur das Erstellen der Builds realisiert Konzeptioneller Ablauf beim Erstellen eines Builds Der normale Entwicklungsprozess bei TMP Anwungen sieht vor, dass das auf Node.js basiere Build-Tool Espresso über das Terminal innerhalb des Projektordners aufgerufen wird. Espresso bietet mehrere Befehle an, die in der Dokumentation 1 nachgeschlagen werden können. Der Befehl zum Packaging von Anwungen ist espresso build der auch auf den Workern aufgerufen wird. Der Befehl erstellt innerhalb des Projektordners einen weiteren Ordner namens builds in dem die Builds abgelegt werden. Als Grundlage für die Build-Konfiguration dient die im Projektordner befindliche TMP Konfigurations-Datei config.json. Unter dem JSON- Schlüssel package sind die Konfigurationsparameter zu finden. Listing 1.1 zeigt ein Beispiel für die Build-Konfiguration. Listing 1.1: Beispiel für die Package Parameter in der config.json " package ": { " myiosconfig ": { " method ": " PhoneGap ", "os": " ios ", " sdk ": " iphonesimulator4.3", " package ": " com. tmp. twitter ", " activity ": " Twitter ", " mode ": " debug ", " plists ": { " PhoneGap ": { " ExternalHosts ": ["*"] } }, " autoscaleicon ": true } } Die Build-Konfigurationen werden im Vorfeld über das Portal angelegt und beim Einstellen eines Jobs in die Queue mit übergeben. Währ des Build-Prozesses wird eine package.log-datei erstellt. Diese Log-Datei enthält Informationen darüber, 1 overview 4

19 Kapitel 1 Einleitung wie der Build abgelaufen ist und gegebenenfalls Fehlermeldungen und deren Ursachen. Der Ablauf beim Erstellen von Builds sieht folgermaßen aus: Schritte die mit (W) gekennzeichnet sind, finden auf den Workern statt. Alle anderen auf dem Portal. 1. Registrierung des Benutzers. 2. Login des Benutzers. 3. Erstellung eines (leeren) Projekts. 4. Hochladen einer Zip-File mit TMP Quellcode in ein S3 Bucket. Das hochgeladene Projekt wird nicht auf Richtigkeit der Ordner- oder Projektstruktur geprüft. 5. Erstellen einer Konfiguration für ios oder Android. 6. Upload von Keystore (Android) oder Provisioning Profile (ios) bei Konfigurationserstellung. Diese Dateien enthalten Schlüssel oder Zertifikate zur Signierung der Anwung. 7. Benutzer startet Build-Prozess mit Klick auf Build -Button. 8. Job wird mit allen Parametern und einem Link auf eine Zip-File im S3 vom Dispatcher in eine Job-Queue gestellt (Amazon SQS). 9. Beim Einstellen des Jobs wird geprüft, wie die aktuelle Auslastung der Worker ist und gegebenenfalls neue Instanzen gestartet oder gestoppt. Das Stoppen von Instanzen muss eventuell als Cron-Job in bestimmten Zeitabständen ausgeführt werden. Die Umsetzung ist zu diesem Zeitpunkt noch unklar und wird detailliert in Abschnitt 4 vorgestellt. 10. (W) Worker pollen die Queue nach Jobs und arbeiten Tasks ab (siehe nächster Punkt). 11. (W) Download und Entpacken der Zip-Datei, des Keystores bzw. dem Provisioning Profile und Extrahierung der config.json. Sämtliche Daten aus der bestehen config.json werden ignoriert (inklusive der existieren Konfigurationen). 12. (W) Ausführung des entsprechen Espresso-Command über System-Call. Anschließ werden die Informationen über den Build, bei Erfolg auch der fertige Build, wieder an das Portal geschickt und sämtliche Job-Daten auf dem Worker werden gelöscht. 5

20 1.2 Vorstellung des Projekts 13. (W) Im Fehlerfall wird die package.log von Espresso anstelle des fertigen Builds hochgeladen. Trotzdem findet eine Löschung der Job-Daten auf dem Worker statt. Anschließ kann der Benutzer den fertigen Build herunterladen oder im Fehlerfall den Grund für den Fehler nachlesen und beheben. 14. Das Portal benachrichtigt den Nutzer (sofern dieser den Browser noch offen hat) über einen Ajax-Call, dass der Buildprozess fertig ist. Abbildung 1.1: Architektur-Entwurf 6

21 Kapitel 1 Einleitung 1.3 Warum Amazon Webservices? Die Nutzung einer statisch-gemieteten Infrastruktur auf monatlicher Basis bei einem Hosting-Service kommt für die Nutzung nicht in Frage. Lastspitzen bezüglich der Nutzeranzahl sollen dynamisch abgefangen werden, weshalb kurzfristig und vor allem automatisch neue Server oder Komponenten bereit gestellt werden müssten. Die Anforderung und Einrichtung neuer Komponenten würde bei einem normalen Hosting-Service zu viel Zeit in Anspruch nehmen. Darüberhinaus sind die Vertragslaufzeiten bei einem klassischen Hoster meistens auf einen längeren Zeitraum ausgelegt und damit zu unflexibel. Eine vollständige Evaluation aller bekannten Cloud-Dienste ist nicht die Fragestellung dieser Thesis. Aus diesem Grund wird hier nicht auf die Vor- und Nachteile gegenüber anderer Dienste eingegangen, sondern kurz die wichtigsten Features von AWS aufgelistet. Freie Auswahl der Betriebssysteme und -versionen für die EC2- Server: Derzeit befinden sich über 1000 Amazon Machine Image (AMI) auf Amazons offizieller Seite 2 für gemeinsam genutzte AMIs (shared AMIs). Neben der Möglichkeit bereits vorhandene AMIs zu nutzen können diese auch selbst erstellt werden. Oft sind die Images bereits für einen bestimmten Zweck ideal vorkonfiguriert (Hosting eines CMS, Blogs, etc.) und müssen nur noch an die eigenen Bedürfnisse angepasst werden. Mehr Informationen zu AMIs sind in Abschnitt zu finden. Große Auswahl an Diensten: Zum aktuellen Zeitpunkt stehen 27 verschiedene Dienste zur Auswahl 3. Diese reichen von Datenverarbeitung und -speicherung sowie Netzwerkdiensten über Verwaltung der Infrastruktur bis zur Abwicklung von Zahlungen. API zur Steuerung der Infrastruktur mit der bevorzugten Skript- oder Programmiersprache. Sämtliche Dienste und Funktionen können über ein API angesteuert werden. Auto-Scaling erlaubt bei Bedarf eine automatische Erweiterung oder Verkleinerung der aktuellen Infrastruktur, je nach aktueller Auslastung der Server. Availability Zones sind regionale Bereiche, in denen die Infrastruktur genutzt werden kann. Amazon bietet Rechenzentren in Europa, Asien und Amerika an. Diese Verfügbarkeits-Zonen sind ihrerseits nochmal unterteilt (z.b. eu-west-1a, eu-west-1b,... ), so dass bei Ausfall einer Zone eine andere Zone weiterhin funktionsfähig ist. 2 https://aws.amazon.com/amis 3 7

22 1.3 Warum Amazon Webservices? Welche AWS Dienste kommen in Frage? Für die Implementierung werden hauptsächlich die folgen AWS-Dienste genutzt: Elastic Compute Cloud (EC2) stellt die Rechenkapazität, also Server für die Anwung selbst und die Worker zur Verfügung. Simple Queue Service (SQS) dient als Message-Queue zum asynchronen Verarbeiten der Build-Jobs. Simple Storage Service (S3) wird zur Speicherung aller beteiligten Daten verwet: Den Quellcode des Projekts von dem der Build erstellt werden soll, benötigte Keystores bzw. Signierungs-Zertifikate und den fertigen Build selbst. CloudWatch überwacht die gesamte Infrastruktur und stellt Metriken zur Auslastung zur Verfügung. Bei zu hoher oder geringer Auslastung müssen automatisch entspreche Änderungen an der Infrastruktur vorgenommen werden. 8

23 Kapitel 2 Cloud-Computing 2.1 Was ist Cloud-Computing? Eine offizielle Definition des Begriffs Cloud-Computing gibt es zum aktuellen Zeitpunkt nicht. Währ der Begriff des Cloud-Computing für Endnutzer vor allem eine Metapher für das Internet darstellt, gibt es auch mehrere gute Definitionen unter anderem vom Bundesamt für Sicherheit in der Informationstechnik (BSI), National Institute of Standards and Technology (NIST) und dem BITKOM Branchenverband: Cloud Computing bezeichnet das dynamisch an den Bedarf angepasste Anbieten, Nutzen und Abrechnen von IT-Dienstleistungen über ein Netz. Angebot und Nutzung dieser Dienstleistungen erfolgen dabei ausschließlich über definierte technische Schnittstellen und Protokolle. Die Spannbreite der im Rahmen von Cloud Computing angebotenen Dienstleistungen umfasst das komplette Spektrum der Informationstechnik und beinhaltet unter anderem Infrastruktur (z. B. Rechenleistung, Speicherplatz), Plattformen und Software. BSI [Inf12] Cloud computing is a model for enabling ubiquitous, convenient, ondemand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. NIST [PM11] Cloud Computing ist eine Form der bedarfsgerechten und flexiblen Nutzung von IT-Leistungen. Diese werden in Echtzeit als Service über das Internet bereitgestellt und nach Nutzung abgerechnet. Damit ermöglicht Cloud Computing den Nutzern eine Umverteilung von Investitions- zu Betriebsaufwand. BITKOM [BI09] 9

24 2.1 Was ist Cloud-Computing? Alle der oben genannten Definitionen sind richtig. Hauptbestandteile des Cloud- Computing sind die flexible Nutzung von IT-Ressourcen, die Abrechnung nach tatsächlicher Nutzung und die Möglichkeit der Anforderung von Ressourcen in Echtzeit. Unterschiedlichste Dienste und Produkte werden über das World Wide Web einem Benutzer zur Verfügung gestellt. Ursprünglich wurde der Begriff der Cloud von Telekommunikationsunternehmen aus den 90er Jahren dazu verwet um einzelne Services wie Router, Hubs oder Switches in einem Paket anzubieten. Auch in der IT stellt die Cloud die Zusammenfassung mehrerer Produkte dar, ohne dass der Benutzer sich um die Aufrechterhaltung oder dem Zusammenspiel der einzelnen Komponenten kümmern muss. In [CM11] werden die Basistechnologien aus denen sich Cloud-Computing zusammensetzt, wie folgt zusammengefasst: Breitband-Internet stellt die Grundlage für das Nutzen von Ressourcen dar, da diese immer auf Servern zur Verfügung gestellt werden und ohne schnelle Internetanschlüsse die Angebote gar nicht verfügbar wären. Hochleistungsserver in Form von Großrechnern ermöglichen die Nutzung von Rechenleistung um Applikationen für Benutzer in Echtzeit zur Verfügung zu stellen. Durch Virtualisierung wird ebenfalls ermöglicht, nicht genutzte Rechenleistung auf Großrechnern zu vermieten. Virtualisierung sorgt dafür, dass mehrere Benutzer gleichzeitig völlig unabhängig voneinander auf derselben Hardware arbeiten können. Dabei wird gewährleistet, dass sich Sicherheit und Individualität der einzelnen Nutzer nicht untereinander beeinträchtigen. Die hierbei vorgenommene Trennung von Rechenleistung und Speicherplatz ist rein logisch und nicht physisch. Browser wie Apple Safari, Mozilla Firefox, Google Chrome oder Opera sind die zentrale Laufzeitumgebung mit der Anwer die Software über das Internet nutzen. Es ist keine vorherige Installation oder Konfiguration von zusätzlicher Software nötig. Interaktives Web 2.0 ist die Grundlage um ein Bedienkonzept ähnlich wie bei Desktop-Anwungen zu schaffen. Das Abrufen von Informationen aus dem Internet basiert auf dem Request-Response Konzept, angeforderte Seiten werden also immer komplett neu gerert. Technologien wie Ajax (Javascript) und HTML5 bieten Möglichkeiten um Anwungen so zu gestalten, dass interaktives Arbeiten in Echtzeit zumindest vom Bedienkonzept genauso möglich ist, wie bei Desktopanwungen. Mobile Endgeräte und mobiles Internet geben Benutzern die Möglichkeit an (fast) allen Orten die Angebote aus der Cloud zu nutzen. 10

25 Kapitel 2 Cloud-Computing Abbildung 2.1: Basistechnologien für Cloud-Computing nach [CM11] Das NIST beschreibt in [PM11] die grundlegen Charakteristika des Cloud-Computing wie folgt (übersetzt ins Deutsche): On-demand self service. Ein Konsument kann, eigenständig und ohne menschliche Interaktion mit dem Service Provider, Rechenleistungen in Form von CPU-Stunden oder Netzwerk-Speicher bereitstellen lassen. Zugriff über Breitband-Netzwerke. Alle Leistungen sind über das Netzwerk verfügbar und werden über standardisierte Mechanismen zugreifbar gemacht, die die Nutzung über heterogene Thin oder Thick Clients begünstigen. Bündelung von Ressourcen. Die Rechenleistungen des Providers werden gebündelt über ein Multi-Tenant-Modell mehreren Konsumenten zur Verfügung gestellt. Die physischen und virtuellen Ressourcen werden dabei dynamisch zugewiesen, je nach Bedarf der Konsumenten. Es gibt eine gewisse Unabhängigkeit was den Standort betrifft, bei der der Konsument normalerweise keine Kontrolle oder Kenntnis darüber hat, wo sich die zur Verfügung gestellten Ressourcen befinden. Möglicherweise ist der ungefähre Standort auf einem höheren Abstraktionslevel bekannt (Land, Staat oder Rechenzentrum). Beispiele für Ressourcen sind Speicherplatz, Verarbeitungskapazitäten, Speicherkapazität oder Bandbreite im Netzwerk. Kurzfristige Elastizität. Alle Leistungen können elastisch in Anspruch genommen oder freigegeben werden, in manchen Fällen vollautomatisch um kurzfristig mit den Anforderungen auf- und abwärts zu skalieren. Für den 11

26 2.1 Was ist Cloud-Computing? Konsumenten erscheinen die verfügbaren Leistungen meistens als unbegrenzt und können in jeder Menge zu jeder Zeit in Anspruch genommen werden. Überwachte Dienste. Cloud systeme kontrollieren und optimieren die Ressourcen-Nutzung anhand von Messungen die, abhängig vom Typ des Dienstes, einen bestimmte Abstraktionslevel bieten (zum Beispiel Speicherplatz, Verarbeitungskapazität, Bandbreite und aktive Benutzer-Accounts). Ressourcen-Nutzung kann überwacht, kontrolliert und ausgewertet werden, um Transparenz zu den verweten Diensten für Anbieter und Nutzer zu schaffen Nutzungsmodelle Im Cloud-Computing gibt es unterschiedliche Nutzungsmodelle, die sich darin unterscheiden auf welcher Schicht eine Dienstleistung den Kunden zur Verfügung gestellt wird. Die Nutzungsmodelle sind Software-as-a-Service (SaaS), Platform-as-a- Service (PaaS) und Infrastructur-as-a-Service (IaaS). Abbildung 2.2: Nutzungsmodelle des Cloud Computing Software-as-a-Service Bei SaaS wird dem Kunden eine fertige Software angeboten, die nicht mehr auf einem Rechner installiert oder konfiguriert werden muss, sondern komplett über das Internet verfügbar gemacht wird. In vielen Fällen geschieht dies über den Browser der eine Bedienungsoberfläche bereit stellt. Neben dem Zugriff über den Browser gibt es noch die Möglichkeit Daten und Funktionalitäten über Schnittstellen (z.b. im XML- oder JSON-Format) abrufbar zu machen. Dadurch kann Software auch 12

27 Kapitel 2 Cloud-Computing über Thin-Clients wie z.b. mobile Anwungen genutzt werden. Das bedeutet, dass die Daten weiterhin auf der Infrastruktur des Anbieters liegen und die Anwung nur für die Darstellung verwet wird. Der Betreiber der Anwung ist im Gegensatz zum Kunden verantwortlich für das Management der darunterliegen Infrastruktur und Software (Server, Netzwerk, Software, Storage). Die SaaS-Anwung wird in der Regel von mehreren Kunden gleichzeitig verwet und unterliegt nur einer logischen Trennung zwischen den Kunden. Als Kunde ist die Anwung in Echtzeit verfügbar, in den meisten Fällen ist keine direkte menschliche Interaktion zwischen Anbieter und Kunde nötig um einen Dienst oder eine Software zu nutzen: Der Kunde meldet sich über das Internet beim Dienst an und kann die Software direkt nutzen. Beispiele für aktuelle SaaS-Awungen sind Google Apps 1 (Office Anwungen), salesforce.com (Customer-Relationship-Management) aber auch weniger verbreitete Konzepte wie das Cloud-Gaming (z.b. onlive.com). Beim Cloud-Gaming werden aktuell erhältliche Spieletitel anhand von Streaming Technologien über den Browser spielbar gemacht. Die Anschaffung teurer Spiele-Hardware durch Endbenutzer fällt dadurch weg Platform-as-a-Service PaaS richtet sich im Gegensatz zu SaaS nicht an den Endnutzer selbst, sondern vor allem an Entwickler, die ihre Anwungen in der Cloud betreiben wollen. Dafür stellt der Anbieter fertige Laufzeitumgebungen für diese Applikationen zur Verfügung, wie zum Beispiel Applikationsserver, Datenbanken, Tools, Bibliotheken und weitere Komponenten. Der Entwickler hat dann die Möglichkeit seine Anwungen auf die Server zu verteilen und teilweise noch kleinere Anpassungen an der Konfiguration der Laufzeitumgebung zu machen. Der Vorteil für den Entwickler liegt darin, dass er sich nicht um die Aufrecherhaltung und Sicherheit der Infrastruktur kümmern muss. Bei manchen Diensten, wie z.b. Heroku, gibt es sogar Mechanismen, die bei steiger Auslastung der Komponenten automatisch skalieren und mehr Leistung zur Verfügung stellen [Her12]. PaaS bietet sich vor allem für Start-Ups an, die mit einer bestimmten Software-Idee den schnellen Markteinstieg suchen. Aufgrund der jungen Unternehmensgeschichte und geringem Budget verfügen Start-Ups häufig über wenig IT-Kompetenz im Bereich des Infrastruktur-Managements. Auch bei PaaS Angeboten wird wieder nur eine Mietnutzung berechnet und das Kaufen und Einrichten der eigenen Plattform fällt weg [CM11]

28 2.1 Was ist Cloud-Computing? Als Nachteil fällt die Abhängigkeit vom Anbieter stark ins Gewicht. Falls die entwickelte Software bestimmte Abhängigkeiten bei der Programmiersprache oder der Benutzung externer Bibliotheken oder Programme hat, kann dies durchaus zum Problem werden, falls der Anbieter diese Komponenten nicht standardmäßig anbietet. Die Nutzung eines PaaS Angebotes kann deswegen die Flexibilität bei der Software-Entwicklung einschränken und sollte unbedingt bereits bei der Planung eines Projektes in Betracht gezogen und evaluiert werden. PaaS-Anbieter sind zum Beispiel Google App Engine 2 Heroku 3 (Ruby, Node.js, Clojure, Java, Python, Scala). (Java, Python, Go) oder Infrastructure-as-a-Service Wie der Name schon sagt, wird bei IaaS Infrastruktur in Form von Rechenleistung, Speicherplatz oder Netzwerken angeboten. Die Thematik dieser Thesis befasst sich fast ausschließlich mit IaaS und dessen bekanntestem Anbieter Amazon. Dort kann neben einer großen Anzahl Dienste auch Rechenleistung in Form von EC2- Instanzen und Speicherplatz (S3) gemietet werden. Als Kunde muss man sich auch bei IaaS nicht um die Aufrechterhaltung der Infrastruktur kümmern und bezahlt nur tatsächlich genutzte Ressourcen, wie z.b. in Anspruch genommene CPU-Zeit oder hoch- und heruntergeladene Daten Liefermodelle Es existieren vier verschiedene Möglichkeiten wie Clouds den Anwern oder Kunden zur Verfügung gestellt werden können. Diese unterschieden sich vor allem durch die Art, wo und mit wem die Cloud betrieben wird Private Cloud Eine Private Cloud wird, wie der Name schon sagt, einem Konsumenten exklusiv zur Verfügung gestellt. Das verringert die Problematik mit dem Datenschutz und der Datensicherheit, da sich die Cloud häufig im selben Netzwerk wie die Endbenutzer befindet. Die Infrastruktur kann dabei sowohl vom Konsumenten selbst aber auch von Dritten betrieben und verwaltet werden. Die Abgrenzung zum normalen Betrieb von EDV-Systemen ist relativ fließ, da auch moderne Softwaresysteme über Browser zu bedienen sind und von IT-Abteilungen gehostet und betrieben werden [CM11] (S. 18). 2 https://developers.google.com/appengine/ 3 14

29 Kapitel 2 Cloud-Computing Public Cloud Die Public Cloud ist wirklich öffentlich und steht jedem Benutzer oder Unternehmen über das Internet zur Verfügung. Innerhalb einer Public Cloud wird noch zwischen der Exclusive Cloud und der Open Cloud unterschieden. Bei der Exclusive Cloud wird ein Vertrag zwischen Anbieter und Kunde vereinbart und beide Seiten kennen sich. Bei der Open Cloud ist das nicht der Fall. Hier wird im Vorfeld keine vertragliche Abmachung über die Entwicklung eines Dienstes geschlossen und die Leistung wird nur in Form eines Service-Level-Agreement (SLA) festgeschrieben. Die Dienste müssen aufgrund der hohen Anzahl potentieller Nutzer anbieterseitig vollautomatisch ablaufen [CM11] (S. 19) Community Cloud Eine Community Cloud entsteht, wenn sich mehrere Firmen oder Betreiber dazu entscheiden ihre Private Clouds zusammenschließen Hybrid Cloud Die Hybrid Cloud kann aus allen der oben genannten Clouds bestehen. So könnte zum Beispiel der Datenspeicher mit sensiblen Geschäftsdaten des Kunden in einer Private Cloud betrieben werden, währ die Rechenleistung aus einer Community Cloud bezogen wird und in der Public Cloud eine Software nach SaaS-Modell genutzt wird. 15

30 2.2 Sicherheit und Datenschutz in der Cloud 2.2 Sicherheit und Datenschutz in der Cloud Seit Cloud-Computing den Massenmarkt erreicht hat, gibt es ein Thema das regelmäßig in der Presse präsent ist und Unternehmen, vor allem bei potentiellen Nutzern, immer noch bemüht sind eine Vertrauensbasis zu schaffen: Die Sicherheit und den Schutz der Daten, die in Cloud-Diensten gespeichert werden. In dem Moment in dem private Nutzer oder Unternehmen SaaS-Dienste in der Cloud nutzen, werden dort Daten gespeichert. Diese Daten enthalten in der Regel private oder geschäftliche Informationen, die vor nicht authorisierten Zugriffen oder Verlust geschützt werden müssen. Die Datensicherheit dient dazu die Integrität, Verfügbarkeit und Authentizität aller Daten zu gewährleisten; hierzu zählen insbesondere die klassischen Aufgaben der IT-Sicherheit, nämlich das Sicherstellen der Funktionalität von Hard- und Software, unter anderem durch Nutzung und Wartung geeigneter Sicherheitstechniken sowie durch Vorsorge, die eine Weiterführung des Betriebs nach Störungen gestattet [CM11]. Je nachdem welches Nutzungsmodell genutzt wird, ist entweder der Anbieter (SaaS) für die Einhaltung der Datensicherheit zuständig oder der Nutzer der Dienste selbst, der vielleicht über die Nutzung von PaaS oder IaaS Diensten eigenständig Anwungen für Dritte zur Verfügung stellt. Der Datenschutz dient dazu, personenbezogene Daten vor dem Missbrauch Dritter zu schützen. Die Thematik ist gerade heute im Internet ein sehr pikantes Thema: Bei vielen Internetnutzern ist kein ausgeprägtes Bewußtsein darüber vorhanden, wie man am Besten mit seinen eigenen Daten umgehen sollte. Soziale Netzwerke wie Facebook ermuntern Benutzer dazu, ihre persönlichen Daten zu veröffentlichen und erschweren es teilweise sogar, über eine regelmäßige Änderung der Datenschutzeinstellungen, seine Daten nur einem bestimmten Nutzerkreis ( Freunde ) zur Verfügung zu stellen. Die Folge sind soziale Konflikte (Stalking, Mobbing, Kriminalität) die durch unachtsamen Umgang mit persönlichen Daten entstehen. Anderen Unternehmen wie z.b. Google wird vorgeworfen als Datenkrake so viele Informationen wie möglich über Internetnutzer zu sammeln sogar ohne dass diese sich tatsächlich darüber bewußt sind. Ein gutes Beispiel dafür ist der Dienst Google Mail. Regelmäßig erscheinen bei der Nutzung des Programms Werbebanner, die Dinge bewerben die in direktem Zusammenhang mit dem Inhalt empfangener oder verseter s stehen. Bei der Datenhaltung in der Cloud ergeben sich fünf W-Fragen [CM11] S. 50ff: Welche Daten werden gespeichert? Wie bereits angesprochen gibt es Firmen wie Google, die Daten nicht nur speichern, sondern auch auswerten. Dadurch ergeben sich Korrelationen, die wiederum anderweitig (z.b. Werbung) genutzt oder auch an Dritte verkauft werden. 16

31 Kapitel 2 Cloud-Computing Wo sind die Daten zu finden? Im Gegensatz zu einem lokalen Umfeld, bei dem bekannt ist auf welchem Server sich welche Daten genau befinden, ist dies in der Cloud nicht möglich. Meistens sind bei Cloud Infrastrukturen wenn überhaupt nur das Rechenzentrum spezifizierbar in welchem die Daten liegen. Bei weltweit verteilten Clustern ist das allerdings nicht möglich. Bei einer Anfrage wird aufgrund der Herkunft dynamisch entschieden welche Rechner an der Auslieferung beteiligt sind. Wenn der geopolitische Standort von großer Bedeutung ist, sollte unbedingt beim Anbieter in Erfahrung gebracht werden wo die Daten genau abgelegt werden. Wie sind die Daten abgelegt? Gerade bei unternehmenskritischen Daten die vor Industriespionage geschützt werden müssen, ist es wichtig wie die Daten abgelegt werden. Wie werden die Daten bei Multi Tenancy-Architekturen so abgelegt, dass die einzelnen Kundenbestände voneinander getrennt sind? Gibt es Verschlüsselungsmechanismen die bei eventuellem Datiebstahl trotzdem die Unbenutzbarkeit der Daten gewährleisten? Was passiert mit gelöschten Daten? Wer hat Zugriff auf die Daten? Der Zugriff auf Daten in der Cloud geschieht in den meisten Fällen über die Internetverbindung. Wenn die Daten auf dem Server nicht ausreich durch Authorisierungs- und Authentifizierungsmaßnahmen geschützt werden, kann theoretisch jeder Internetnutzer die Daten abrufen. Wann kann auf die Daten zugegriffen werden? Die Verfügbarkeit der Daten muss zu nahezu jedem Zeitpunkt gewährleistet werden. Wer bei Google Docs online eine Präsentation erstellt, die er anschließ bei einem wichtigen Kundentermin vorstellen möchte nur um dann festzustellen, dass der Docs Dienst sich gerade im Wartungsmodus befindet, wird sicherlich nie wieder auf den Dienst zurückgreifen. Bei Systemausfällen oder bereits erwähnten Wartungsfenstern muss der Anbieter den Betrieb aufrechterhalten. Die Verfügbarkeit eines Dienstes wird in der Regel in einem SLA vertraglich zugesichert. 17

32 2.3 Cloud Computing für Entwickler 2.3 Cloud Computing für Entwickler Als Software-Entwickler gibt es mehrere Eigenheiten auf die man achten sollte, wenn man für die Cloud entwickelt. Die Vorgehensweisen bei der Entwicklung sind vor allem in Bezug auf die Skalierbarkeit einer Anwung wichtig. Sie richten sich an Entwickler die ihre Software über PaaS oder IaaS Anbieter den Endkunden zur Verfügung stellen möchten Vermeidung von SPOFs Ein Kernelement der Cloud ist die Vernetzung verteilter Systeme in Form von mehreren Komponenten. Eine klassische Webanwung besteht fast immer aus drei Teilen: Webserver zum Ausliefern von gecachten Inhalten oder Load-Balancing auf darunterliege Applikationsserver Applikationsserver auf denen die Anwung selbst betrieben wird Datenbanken zur Speicherung von Daten Falls eines dieser Elemente ausfällt, ist bei einer schlechten Architektur das ganze System nicht funktionsfähig und es existieren ein oder mehrere Single-Point- Of-Failure (SPOF). Um einen SPOF in einer Cloud-Struktur zu vermeiden, ist es wichtig, dass jede zentrale Komponente ausfallsicher verfügbar gemacht wird. Das bedeutet, dass z.b. Datenbanken oder Caches auf denen von mehreren anderen Komponenten aus zugegriffen wird, mehrfach vorhanden sein müssen damit bei einem Ausfall einer Instanz die zweite Instanz den laufen Betrieb aufrecht erhält. In der Regel sind dezentrale Komponenten wie Webserver oder Applikationsserver aus Skalierungsgründen grundsätzlich mehrfach vorhanden. Deswegen betrifft die Vermeidung von SPOFs vor allem die Komponenten die einen Zustand des Systems in Form von Daten speichern. Das trifft nicht auf alle Komponenten zu, so sollten zum Beispiel Applikationsserver so implementiert werden, dass dort höchstens temporäre Daten gespeichert werden, die im Falle eines Verlustes der Instanz keine negativen Auswirkungen auf den Zustand der Cloud haben. Ein gutes Beispiel dafür sind Session-Daten eines Users. Diese Daten sollten in einer zentralen Datenbank oder einem Cache gespeichert werden, auf den alle Applikationsserver in der Infrastruktur Zugriff haben. Ein weiteres Beispiel ist die Speicherung von User-Uploads. Im Normalfall werden hochgeladene Dateien direkt auf dem Applikationsserver gespeichert. Falls dieser Server ausfällt, wären auch die hochgeladenen Daten weg. Die Lösung ist die Speicherung an einem zentralen Ort wie z.b. Amazons Storage Service (S3). Dort speichern alle Applikationsinstanzen ihre Daten und rufen sie auch wieder ab. 18

33 Kapitel 2 Cloud-Computing Load-Balancing Jede der drei zuvor genannten Komponenten kann und sollte in mehrfacher Ausführung vorhanden sein. Das wird nicht nur durch eine Ausfallsicherheit bedingt, sondern kann auch bei einer hohen Last auf die gesamte Infrastruktur durch die Performance begründet sein. Jeder Server kann trotz starker Hardware an seine Grenzen kommen und nicht mehr in der Lage sein die Zugriffe zu bewältigen. Es müssen also weitere Komponenten einer Art zur Verfügung gestellt werden. Diesen Vorgang nennt man horizontale Skalierung die im Gegensatz zur vertikalen Skalierung steht, also der Aufrüstung eines Server mit besserer und schnellerer Hardware. Um bei einer horizontalen Skalierung die Last auf mehrere Komponenten zu verteilen muss eine Last-Verteilung (Load-Balancing) gemacht werden. Bei Web- und Applikationsservern wird meistens der Web-Server dazu verwet im Round-Robin-Verfahren (also abwechselnd) die Zugriffe auf die Applikationsserver zu verteilen. Damit wird eine möglichst gleichmäßige Verteilung der Zugriffe gewährleistet. Wichtig hierbei ist vor allen Dingen, dass kein Zustand auf den einzelnen Applikationsserver gespeichert wird, da es durchaus möglich ist, dass ein User bei jedem Request auf einem anderen Applikationsserver landet. Alternativ dazu gibt es die Möglichkeit der Sticky-Sessions also das Festkleben eines Users an einen bestimmten Applikationsserver, der ausschließlich von dieser Instanz bedient wird. Grundsätzlich darf dem User nicht bekannt sein auf welchem Applikationsserver er sich gerade befindet oder ob ein auslastungsbedingter Wechsel auf einen anderen Server statt gefunden hat Datenbank-Skalierung Die Skalierung einer Datenbank gehört zu den kritischsten Komponenten. Hier werden Daten abgelegt, die gleichzeitigen Manipulationen und Abrufen unterliegen und deswegen zu jedem Zeitpunkt einen konsistenten Zustand haben müssen. Dafür werden die sogenannten Transaktionen verwet. Transaktionen sind mehrere Programmschritte die zu einem logischen Schritt zusammengefasst werden. Dabei muss jeder dieser einzelnen Schritte erfolgreich ausgeführt werden. Im Fehlerfall werden alle Schritte innerhalb einer Transaktion wieder rückgängig gemacht. Transaktionen unterliegen dem ACID-Prinzip: Atomicity: Jeder Schritt einer Transaktion läuft entweder ganz durch oder gar nicht. Im Fehlerfall muss die Datenbank den Zustand vor der Transaktion haben. Egal um welche Art von Fehler es sich handelt. Consistency: Jede Transaktion muss die Datenbank in einem konsistenten Zustand belassen. Eine Transaktion muss sämtlichen Bedingungen für valide Daten (z.b. Constraints) erfüllen. 19

34 2.3 Cloud Computing für Entwickler Isolation: Gleichzeitig laufe Transaktionen laufen ab, ohne sich gegenseitig zu beeinträchtigen. Durability: Sämtliche Änderungen, die durch eine Transaktion vorgenommen wurden, sind zum Abschluss der Transaktion persistent gespeichert. Um bei einer Skalierung weiterhin dem ACID-Prinzip gerecht zu werden, gibt es mehrere Möglichkeiten: Zum einen gibt es die asychrone Replikation einer Datenbank bei der Schreiboperationen weiterhin auf eine als Master bezeichnete Instanz getätigt werden. Für Read-Operationen werden mehrere Slaves zur Verfügung gestellt, welche die eigentlich aufwändigen und teuren Datenabfragen machen. Der Zustand des Masters wird nach jeder Schreiboperation automatisch an die Slaves weitergegeben. Dabei entsteht eine sehr geringe Verzögerung die in Kauf genommen werden muss. Auf Applikationsseite muss lediglich für die unterschiedlichen Operationen der entspreche Server angesprochen werden. Eine andere Möglichkeit ist das sogenannte Sharding einer Datenbank. Beim Sharding werden Daten in logisch trennbare Bereiche aufgeteilt. Ein Beispiel dafür wäre die Auftrennung von Kundaten nach geografischen Standpunkten: Im Fall einer Kundatenbank werden einfach alle Daten von Kunden aus dem asiatischen Markt auf eine Datenbank in einem asiatischen Rechenzentrum gespeichert. Kundaten aus den USA werden auf einem anderen Server in den USA gespeichert. Voraussetzung für diese Aufteilung ist allerdings, dass die Daten aus den unterschiedlichen Datenbanken nicht miteinander korreliert werden müssen. Dies wäre nur über Umwege (zum Beispiel dritte Schnittstellen) und aus Zeitgründen nicht in Echtzeit möglich CDN und geografische Verfügbarkeit Gerade bei Anwungen die global verfügbar sein sollen, ist die geografische Lage der Server für die Zugriffsgeschwindigkeit ausschlaggeb. Für Kunden aus Asien kann die Benutzung einer Webanwung, die in Europa gehostet ist und dadurch sehr hohe Latenzen vorweist, eine starke Beeinträchtigung auf die User- Experience darstellen. Aus diesem Grund ermöglichen Cloud-Anbieter die Nutzung ihrer Dienste in mehreren Rechenzentren, die auf der ganzen Welt verteilt sind. Alle Produkte können in unterschiedlichen Regionen in Anspruch genommen werden und der Endnutzer wird je nach seiner geografischen Lage auf die Dienste in der Region in seiner Nähe geleitet. Es sollte bereits bei der Planung eines Projektes untersucht werden, für welchen geografischen Markt man seine Anwung zur Verfügung stellt und entspreche Maßnahmen in die Projektplanung mit einfließen lassen. 20

35 Kapitel 2 Cloud-Computing Eine weitere Maßnahme, um Zugriffszeiten geografischen Ursprungs gering zu halten oder Lastspitzen abzufangen, ist ein sogenanntes Content Delivery Network (CDN). Bei einem CDN werden statische oder dynamische Inhalte automatisch an unterschiedlichen Orten als Cache vorgehalten und leiten den Request eines Endkunden an den ihm am nächsten liegen Cache weiter. Ein CDN eignet sich vor allem für größere Dateien (sogenannte Assets) wie zum Beispiel Bilder, Javascript, Videos oder andere binäre Dateien. 21

36 2.4 Zusammenfassung 2.4 Zusammenfassung Allgemeine Vorteile für Cloud-Nutzer Keine Investitionskosten im Vorfeld: Durch die Abrechnung nur tatsächlich genutzter Ressourcen müssen im Vorfeld von Projekten keine hohen Beträge in die Infrastruktur für das Projekt investiert werden. Dadurch wird das Risiko vor allem für kleine Unternehmen und Start-Ups stark minimiert, da diese in der Regel auf Investoren angewiesen sind und nur ein sehr eingeschränktes Budget zur Verfügung haben. IT-Kompetenz nur in ausreichem Maße nötig: Die Cloud Infrastruktur wird vom Anbieter der Dienste aufrecht erhalten. Gerade in verteilten Systemen die über das Internet dem Kunden verfügbar gemacht werden sollen, sind zum Beispiel Sicherheit und Hochverfügbarkeit sehr wichtige Themen. Um Systeme sicher und hochverfügbar zu machen, benötigt ein Unternehmen gut ausgebildetes Fachpersonal. Gerade am heutigen IT-Arbeitsmarkt herrscht laut BITKOM ein Fachkräftemangel durch den Unternehmen in ihrer Geschäftstätigkeit stark gebremst werden [BIT12a]. Dadurch ist es vor allem als neues und kleines Unternehmen schwierig an gutes Fachpersonal zu kommen. Durch die Nutzung von Cloud-Diensten müssen nicht zwing Fachkräfte für die Aufrechterhaltung der eigenen Infrastruktur eingestellt werden. Flexible und skalierbare Nutzung von Ressourcen: Bei der Nutzung von SaaS- oder PaaS-Diensten muss sich der Kunde keine Gedanken um Skalierung machen. Das System skaliert entweder vollautomatisch oder der Anbieter kümmert sich um den Ausbau der Infrastruktur selbst. Bei PaaS- Angeboten gibt es zum Beispiel Möglichkeiten wie man seine, zur Verfügung gestellte Infrastruktur, automatisch über ein API überwachen lässt und bei steiger Auslastung automatisiert zusätzliche Infrastruktur in Echtzeit anfordert. In der Regel ist somit ein System innerhalb von Minuten auf Lastspitzen angepasst. Schneller Marktzugang für Innovationen: Das Aufbauen und Konfigurieren von Infrastruktur oder Laufzeitumgebungen erfordert in der Regel einen hohen Zeitaufwand. Durch die Nutzung von Cloud-Diensten kann dieser Aufwand eingespart werden und die schnellere Produkteinführungszeit kann gerade bei zeitkritischen Geschäftsideen über den Erfolg oder Misserfolg eines ganzen Unternehmens entscheiden. Support und Service: Bei Cloud-Anbietern herrscht oft ein starker Konkurrenz- Kampf. Um Kunden stärker zu binden, sind diese Anbieter stets bemüht sehr gute Support- und Serviceleistungen anzubieten. 22

37 Kapitel 2 Cloud-Computing Allgemeine Nachteile für Cloud-Nutzer Abhängigkeit vom Anbieter: Bei Nutzung eines SaaS-Dienstes zum Beispiel, ist der Kunde auf die Features angewiesen die der Anbieter zur Verfügung stellt. Sollte der Kunde spezifische Anpassungen wünschen, sind diese nur möglich, falls der Anbieter entweder eine Möglichkeit anbietet maßgeschneiderte Änderungen am System für diesen einen Kunden vorzunehmen oder dass der Anbieter die Änderung für gut befindet und allen Kunden gleichermaßen anbietet. Für PaaS und SaaS Dienste gilt natürlich das Gleiche. Hinzu kommt, dass im Falle einer Insolvenz des Anbieters der Kunde im schlimmsten Fall seine Daten oder Infrastruktur verliert. Datensicherheit und Datenschutz oft fraglich: Der größte Kritikpunkt der Cloud-Dienste liegt darin, dass der Nutzer nicht mehr Herr seiner Daten ist. Der Nutzer hat nur bedingten Einfluß darauf, wo seine Daten abgelegt wurden und muss sich auf die Bemühungen des Anbieters verlassen die Daten vor fremden Zugriffen zu schützen. In Bezug auf die Datenhaltung sollten fünf W-Fragen gestellt werden: [CM11] S. 50ff Welche Daten werden gespeichert? Wo sind die Daten zu finden? Wie sind die Daten abgelegt? Wer hat Zugriff auf die Daten? Wann kann auf die Daten zugegriffen werden? 23

38

39 Kapitel 3 Amazon Webservices Als Amazon Ende der 90er Jahre mit ihrem Onlineshop die ersten Erfolge erzielte, hatte das Unternehmen vor allem Probleme mit dem Aufbau ihrer Infrastruktur als Monolithisches System. Dabei sind alle Komponenten stark miteinander verwoben, also nicht eigenständig nutzbar und damit sehr schwer zu skalieren. Zusätzlich wollte Amazon Drittentwicklern ein API zu ihrem Shop zur Verfügung stellen. [Vli11] Die einfachste Lösung dieses Problems war es, die Infrastruktur in kleinere Komponenten aufzuteilen, die möglichst wenige Abhängigkeit zueinander aufweisen. Vorbild für die neue Architektur waren Spezifikationen wie Common Object Request Broker Architecture (CORBA) die zur Übermittlung von Objekten innerhalb verteilter Systeme dienen. Somit entstand 2004 das erste Produkt von AWS der Amazon Simple Queue Service, kurz SQS. SQS ist eine Message Queue zur asynchronen Übertragung von textuellen Daten. Der Dienst selbst wird noch genauer in Abschnitt 3.3 beschrieben. Amazon nutzte den Dienst als Puffer zwischen den Komponenten um zum Beispiel Bestellungen in Stoßzeiten abzuwickeln. So konnten sämtliche Bestellungen in der Queue zwischengespeichert werden bis die Anzahl der Bestellungen wieder abnimmt und die Komponente zum Abarbeiten der Bestellungen wieder Kapazitäten hat. [Vli11] Ein weiteres Problem bei Amazon war der ständig wachse Bedarf an neuer Speicherkapazität. Aus diesem Grund wurde 2006 der Amazon Simple Storage Service (S3) vorgestellt. S3 ist darauf ausgelegt eine unbegrenzte Anzahl an Dateien von einer maximalen Größe bis 5 Terabytes zu speichern. Dabei wird eine Verfügbarkeit der Daten von 99.9% per SLA 1 garantiert. Das entspricht einer maximalen Downtime von 10.1 Minuten pro Woche. Allerdings wären währ einer Downtime die Daten nur vorübergeh nicht erreichbar. Darüberhinaus garantiert Amazon eine Haltbarkeit von %, also maximal den Verlust einer Datei von Dateien die pro Jahr gespeichert werden sollen. [Vli11] Obwohl S3 von Amazon selbst als revolutionärster Dienst angesehen wird, hat EC2 die wahrscheinlich größten Auswirkungen auf das Cloud Computing gehabt. Be

40 3.1 Business Case aus Sicht von Amazon vor EC2 eingeführt wurde, gab es den Begriff IaaS noch gar nicht. Obwohl die Virtualisierung mehrerer Betriebssystem-Instanzen auf einer Hardware bereits existierte, war die stundenbasierte Nutzung und Abrechnung von Rechenleistung bis zur Einführung von EC gänzlich unbekannt. Amazon führte diesen Dienst ein, weil die Teams von Software-Entwicklern, die für die einzelnen Komponenten von Amazon zuständig waren, nun auch für ihre Komponenten eine eigene Infrastruktur aufbauen und betreiben sollten. Ein zentrales Team, dass sich nur für die Aufrechterhaltung von Infrastruktur innerhalb eines Projektes kümmert, gab es bei Amazon nicht. [Vli11] In den folgen Jahren folgten immer mehr Dienste wie z.b. SimpleDB, Relational Database Service (RDS) oder Elastic Load Balancer (ELB) die das bisherige Angebot ergänzten und optimierten. Zum heutigen Zeitpunkt sind es insgesamt 27 Dienste die Amazon anbietet und das Angebot wird ständig erweitert. Abbildung 3.1: Zeitstrahl der Amazon Produkte aus [Vli11] 3.1 Business Case aus Sicht von Amazon Einer der Gründe warum Amazon seine Dienste in Form von AWS auch der breiten Öfffentlichkeit anbietet, ist die Vermietung überschüssiger Kapazitäten. Das amerikanische Portal amazon.com des Amazon Shop wird laut dem Internet Informationsdienst Alexa[Ale12b] täglich von 5% aller Internetnutzer aufgerufen. Damit befindet sich amazon.com auf Platz 10 der weltweit am meisten besuchten Internetseiten. Das dadurch entstehe Traffic-Aufkommen ist enorm: ca. 4,4 Millionen eindeutige Benutzer surfen laut website.org[ale12a] täglich auf amazon.com. Die nötige Infrastruktur um bei diesem Ansturm die Dienste aufrecht zu erhalten umfasst mehrere Rechenzentren. Besonders das Weihnachtsgeschäft beschert einen Traffic-Zuwachs auf bis zu 8,5% Ende 2011 (siehe 3.2). Also enorme Lastspitzen die jedes Jahr weiter wachsen 26

41 Kapitel 3 Amazon Webservices und garantiert auftreten. Die letzte Pressemeldung in der Amazon Statistiken zum Weihnachstgeschäft veröffentlicht hat, stammt aus dem Jahr 2010 [ama10]: Am 29. November 2010 wurden weltweit insgesamt mehr als 13,7 Millionen Produkte über die Amazon Webseiten bestellt das sind über 158 Produkte pro Sekunde. Am 13. Dezember 2010, dem Spitzentag der deutschsprachigen Amazon Website wurden mehr als 2,1 Millionen Produkte bestellt über 24 Artikel pro Sekunde. Und das sind nur die Statistiken zu tatsächlich bestellten Artikeln. Die Anzahl der Benutzerzugriffe dürfte diese Anzahl um einige Faktoren übersteigen. Abbildung 3.2: Prozentualer Anteil aller Internetbesucher die amazon.com besuchen. Quelle: [Ale12b] Das Problem das sich hieraus ergibt, ist dass Amazon trotzdem das ganze Jahr über eine Infrastruktur betreiben muss, die in der Lage ist die maximalen Zugriffe (Requests) abhandeln kann. In Zeiten wo die Auslastung geringer ausfällt, liegen große Teile dieser Infrastruktur brach. Die Virtualisierung als Bestandteil des Cloud-Computing ermöglicht die Vermietung dieser überschüssigen Kapazitäten. Die Großrechner müssen also nicht als Ganzes vermietet werden sondern können durch Virtualisierung in mehrere kleine, logisch getrennte Server aufgeteilt werden und werden dann von vielen Kunden verwet, die sich die Gesamtkapazität aufteilen. Die horren Kosten die durch den Betrieb großer Serverfarmen entstehen, können dann durch die Einnahmen aus der Vermietung mitgetragen werden. 27

42 3.2 Generelle Konzepte bei AWS 3.2 Generelle Konzepte bei AWS Zugriff über API Sämtliche AWS Dienste werden über ein API gesteuert. Die Nutzung dieses APIs kann auf mehrere Arten erfolgen: Direkter Zugriff auf Representational State Transfer (REST)/Query API: Das REST API besteht aus HTTP oder HTTPS Requests die in Verbindung mit einem HTTP Verb (z.b. GET, POST oder DELETE) und einem Uniform Resource Identifier (URI) eine Aktion oder Operation spezifizieren, die ausgeführt werden soll. Manche Dienste, wie zum Beispiel EC2, verwen das sogenannte Query API, welches zwar sehr ähnlich zu REST ist, aber den Prinzipien von REST nicht vollständig gerecht wird. Der Nachteil bei der direkten Nuztung des APIs ist, dass innerhalb der Anwungen viele Details behandelt werden müssen, wie zum Beispiel Verhalten im Fehlerfall und das Signieren der Requests aus Sicherheitsgründen. Beim Signieren der Requests wird für jeden Request eine digitale Signatur anhand einer Hash-Funktion erstellt. Als Eingabe für diese Hash-Funktion dient der Text des Requests und der geheime Zugriffsschlüssel den man als AWS Kunde von Amazon zur Verfügung gestellt bekommt. Auf der Gegenseite wird dasselbe gemacht und die Signatur anschließ verglichen. Bei identischer Signatur ist eine Manipulation des Requests ausgeschlossen.[ser12g] Nutzung der AWS Management Console: AWS stellt ein einfaches und intuitiv nutzbares Web-Interface zur Verfügung welches Zugriff auf alle Funktionen und Dienste bietet. So können Dienste manuell gesteuert, effektiv genutzt (Upload von Dateien in ein S3 Bucket) oder auch ausgewertet werden (Darstellung von CloudWatch Metriken) [Ser12d]. Die Management Console nutzt im Hintergrund selbst das REST-Interface des APIs. Zuhilfenahme eines SDKs: Amazon bietet für mehrere Programmiersprachen und Plattformen fertige SDKs an, die als Open-Source auch auf Github 2 vorliegen. Folge Plattformen/Programmiersprachen werden unterstützt: Android ios Java PHP.NET 2 https://github.com/amazonwebservices 28

43 Kapitel 3 Amazon Webservices Ruby Im Rahmen des Projektes wird das Ruby SDK zum Einsatz kommen. Mehr dazu in Abschnitt 3.4. Der Vorteil der SDKs liegt darin, dass grundlege Dinge wie Fehlermanagement und Sicherheit bereits durch das SDK gewährleistet werden. Über das SDK müssen nur noch Methodenaufrufe gemacht und der jeweilige Rückgabewert verarbeitet werden. Der Nachteil ist, dass in der Regel eine gewisse Zeit vergeht bis neue Features von AWS ihren Weg in die SDKs finden und auch darüber nutzbar sind. Command-Line Tools: Für jeden Dienst können sogenannte Command- Line Tools heruntergeladen werden. Dabei handelt es sich um ausführbare Dateien, die über die Kommandozeile (Windows) oder ein(e) Terminal/Shell (Unix) ausgeführt werden können. Dafür ist lediglich ein installiertes Java Runtime Environment und das Setzen einiger Umgebungsvariablen für Zugangsschlüssel nötig. Eclipse Toolkit: Eclipse Anwer können das Eclipse Toolkit von AWS benutzen. Das Toolkit enthält bereits das SDK für Java und ermöglicht die Entwicklung von Anwungen die das Java SDK nutzen. Mit dem AWS Explorer als Bestandteil des Toolkits kann die Infrastruktur bei AWS administriert werden. So gibt es Graphical User Interface (GUI)s um S3, SimpleDB und EC2 innerhalb von Eclipse zu steuern. Ein weiterer Anwungsfall ist das Entwickeln, Debugging und Deployment von Java Web-Anwungen zu Elastic Beanstalk. Elastic Beanstalk ist ein Application-Container für Webanwungen der den Benutzern Deployment und Skalierbarkeit erleichtern soll Regionen und Availability Zones Fast alle AWS-Dienste können in Rechenzentren aus unterschiedlichen Regionen und Availability Zones genutzt werden. Die Regionen sind über die ganze Welt zerstreut und geben Entwicklern die Möglichkeit ihre Infrastruktur in den Bereichen der Welt zu betreiben, die für potentielle Kunden am nächsten ist, um somit netzwerkbedingte Latenzen möglichst gering zu halten. Die Auswahl einer bestimmten Region könnte auch rechtlicher Natur sein, um gesetzlichen Bedingungen für das Projekt gerecht zu werden. Jede Region arbeitet völlig unabhängig zu anderen Regionen. Die folgen Regionen bietet AWS derzeit an: US East (Northern Virginia) US West (Oregon) US West (Northern California) 29

44 3.2 Generelle Konzepte bei AWS EU (Ireland) Asia Pacific (Singapore) Asia Pacific (Tokyo) South America (Sao Paulo) Gerade bei Nutzung des APIs ist darauf zu achten, dass man für die jeweiligen Regionen spezifische Endpoints bei der AWS Konfiguration angeben muss. Eine Übersicht der Regionen und Endpoints ist auf [Ser12f] zu finden. Innerhalb der Regionen gibt es mehrere Availability Zones, die alle isoliert voneinander sind und sich im Fehlerfall nicht gegenseitig beeinträchtigen. Die Zones innerhalb einer Region sind über ein Netzwerk mit niedrigen Latenzen verbunden. Um eine Anwungen ausfallsicher zu gestalten, sollten unbedingt mehrere Availability Zones in Anspruch genommen werden um SPOFs zu vermeiden, falls eine Zone durch äußere Einflüsse (Stromausfälle, Katastrophen, Erdbeben etc.) ausfallen sollte. Abbildung 3.3: Konzept der Regionen und Availablity Zones. [Ser12e] 30

45 Kapitel 3 Amazon Webservices Preisgestaltung Für die Nutzung der AWS-Dienste gibt es keine monatliche oder allgemeine Nutzungsgebühr, es müssen nur tatsächlich genutzte Ressourcen bezahlt werden. AWS verzichtet standardmäßig auf eine vertragliche Mindestnutzung, alle Produkte können sofort genutzt und direkt wieder freigegeben werden ohne langfristige vertragliche Bindung. Investitionen im Vorfeld fallen dadurch weg. Je nachdem welcher Dienst verwet wird, gibt es mehrere Dimensionen in denen abgerechnet wird: Betriebsdauer (EC2, ELB, CPU Stunden) Instanzen (EC2, RDS, IP-Adressen) Rechenkapazität (EC2, Schnellere Hardware kostet mehr) Storage (S3, EC2, Größe der gespeicherten Daten) Datentransfer (S3, CloudFront, EC2, ausgeher Traffic) Anzahl Requests (S3, CloudFront) Eine genauere Preisaufstellung für die im Projekt verweten Dienste wird in den Abschnitten 3.3 und 4.4 vorgestellt. Neben On-Demand Nutzung von Ressourcen bietet AWS auch Preisvergünstigungen an, wenn man dauerhafte Rechenleistung benötigt. Dafür können sogenannte Reserved Instances oder Spot Instances in Anspruch genommen werden. Bei der Anschaffung einer Reserved Instance wird eine einmalige Zahlung berechnet. Im Gegenzug wird die stündliche Nutzungsgebühr verringert. Als Nutzungszeiträume können 1-Jahres- oder 3-Jahresverträge abgeschlossen werden. Je länger der Zeitraum ist, desto geringer ist die stündliche Nutzungsgebühr. Mit den Spot Instances bietet AWS die Möglichkeit für flexible Nutzer billiger an Rechenkapazitäten zu kommen. Hierbei werden nicht genutzte EC2-Kapazitäten zu einem sich regelmäßig ändernden Preis angeboten. Als Nutzer definiert man einen Preis den man bereit ist zu zahlen. Solange dieser Preis über dem aktuellen Spot-Preis ist, werden die Instanzen ausgeführt. Der Preis der Spot-Instanzen variiert je nach Angebot und Nachfrage und ändert sich damit regelmäßig. Für Neukunden bietet AWS das sogenannte AWS Free Usage Tier an. Damit können neu angemeldete Benutzer innerhalb des ersten Jahres monatlich ein bestimmtes Kontingent an Ressourcen kostenfrei nutzen. Die meisten Dienste wie z.b. EC2, S3, ELB, SQS und RDS verfügen über ein solches Nutzungskontingent. Die kostenlos zur Verfügung gestellten Ressourcen reichen auf jeden Fall um die Dienste und Infrastruktur ausgiebig zu testen. Eine genaue Aufstellung, welche Dienste mit welchen Limitierung über das Free Usage Tier verfügbar sind, ist auf [Ser12c] zu sehen. 31

46 3.2 Generelle Konzepte bei AWS Sicherheit und Datenschutz Um Sicherheit und Datenschutz zu garantieren, bietet Amazon unter dem Namen Identity and Access Management (IAM) eine Reihe von Funktionen an, um den Zugriff auf AWS Dienste und Ressourcen feingranular zu steuern. Bei IAM können Benutzer, Benutzergruppen und Rollen erstellt werden, die mit Rechten ausgestattet werden können. Diese Rechte werden über sogenannte Policies definiert. Jeder Benutzer, Rolle oder Gruppe kann mehrere Policies zugewiesen bekommen. Eine Policy besteht immer aus einem Effect (Allow oder Deny), einem Dienst, Aktionen auf diesen Dienst (Äquivalent zu API-Aufrufen) und einem Amazon Ressource Name (ARN), der die genaue Ressource innerhalb eines Dienstes eindeutig spezifiziert. Diese Ressource könnte zum Beispiel eine EC2 Instanz sein oder ein S3 Bucket. Eine Policy kann am einfachsten über die Management Console definiert werden. Ein Wizard ermöglicht die geführte Definition einer Policy in Form eines Formulars, bei dem die möglichen Werte ausgewählt werden können. Policies werden als JavaScript Object Notation (JSON) Datei definiert. Ein Beispiel einer Policy die alle Zugangsrechte auf zwei S3 Buckets definiert, ist in Listing 3.1 zu sehen. { } Listing 3.1: Beispiel einer IAM Policy " Statement ": [ { " Sid ": " Stmt ", " Action ": [ "s3 :*" ], " Effect ": " Allow ", " Resource ": [ " arn : aws :s3 ::: espresso - theater - dev /*", " arn : aws :s3 ::: espresso - theater - prod /*" ] } ] Für den sicheren Zugriff auf das API können für Benutzer Anmeldedaten (Security Credentials) in Form eines Schlüssels generiert werden, mit denen der Benutzer beim Aufruf eines API-Calls authentifiziert wird. Dieser Schlüssel besteht aus einer Schlüssel-ID und dem geheimen Zugangsschlüssel selbst. Der geheime Zugangsschlüssel ist nur einmalig direkt nach der Erstellung der Zugangsdaten abrufbar und sollte sicher aufbewahrt werden. 32

47 Kapitel 3 Amazon Webservices Für EC2 gibt es zwei weitere Sicherheitskonzepte: Um mit Secure Shell (SSH) auf EC2 Instanzen zu zugreifen kann ein Schlüsselpaar (Keypair) generiert werden, das den Zugriff nach dem Private-/Public-Key- Verfahren absichert. Beim Erstellen einer Instanz muss ein Keypair angegeben werden. Der Public Key dieses Keypairs wird dann automatisch auf der Instanz hinterlegt. Damit haben alle Besitzer des zugehörigen Private-Keys (.pem Datei) die Möglichkeit sich per SSH auf den Server zu verbinden. Mit Security Groups wird sichergestellt dass nur ausgewählter Netzwerkverkehr auf eine Instanz zugelassen wird. Dabei fungiert eine Security Group als Firewall bei der eingestellt werden kann, welches Protokoll auf welchem Port und von welcher IP-Adresse aus, Daten an die Instanz schicken kann. Innerhalb einer Security Group können mehrere Instanzen untergebracht sein, die keinen Regeln bezüglich des Netzwerktraffics untereinander unterliegen. Standardmäßig ist eingeher Datenverkehr von überall aus erlaubt. 33

48 3.3 Im Projekt verwete Dienste 3.3 Im Projekt verwete Dienste Simple Storage Service (S3) Mit S3 kann eine unbegrenzte Anzahl an Dateien mit einer Größe bis zu 5 Terrabyte gespeichert werden. Die Daten können über sogenannte Buckets strukturiert werden. Innerhalb eines Buckets können beliebig Ordner wie in einem Dateisystem erstellt werden. Über Zugriffsrechte kann detailliert geregelt werden, wie auf ein Bucket zugegriffen wird. Neben der Beschränkung auf bestimmte Nutzer oder Nutzergruppen, kann auch der Zugriff auf das Bucket selbst reglementiert werden. Schreib- und Leserechte können sowohl auf das Bucket selbst, als auch auf die verfügbaren Rechte gesetzt werden. Ein Bucket ist von außen über eine URL erreichbar, z.b.: Alle darin liegen Dateien und Ordner können direkt über die URL mit dem entsprechen Pfad angesprochen werden: Aufgrund dieser Struktur ist es sogar möglich komplette statische Webseiten in Form von HTML-, CSS-, JS- und Bild-Dateien auszuliefern. Eine entspreche Option befindet sich in den Einstellungen eines Buckets. Weitere Features von S3 sind detailliertes Logging über Zugriffe, Benachrichtigungen im Fehlerfall und Lifecycle-Management für gespeicherte Objekte. Beim Lifecycle-Management können Regeln für Objekte definiert werden, die beim Eintritt das Objekt selbständig löschen. Laut [Ser12a] basiert S3 auf zwei unterschiedlichen Konsistenzmodellen aus der Welt der verteilten Systeme: Buckets in der US Region basieren auf eventual consistency, alle anderen Regionen auf read-after-write consistency. Auf [Swi09] wird Konsistenz als ein wichtiges Konzept in der Datenspeicherung beschrieben: Es definiert, dass Änderungen die auf ein System angewet werden, sofort und ab Millisekunde 1 nach dem Commit für alle Teilnehmer sichtbar sind. Eventual consistency schwächt dieses Verhalten ein bisschen ab: Es erlaubt einen zeitlichen Versatz zwischen dem Zeitpunkt an dem Daten an den Datenspeicher übermittelt (commit) werden bis zu dem Zeitpunkt an dem die Daten für Andere ebenfalls sichtbar sind. Eine Änderung an den Daten könnte also eine Millisekunde später sichtbar sein, aber auch 500ms oder 1000ms später. Schlusslich wird die Änderung aber für alle sichtbar sein. Allerdings gibt es theoretisch keine Grenze wie lange man warten muss, bis die Daten sichtbar sind [Swi09]. Daher auch 34

49 Kapitel 3 Amazon Webservices der Name eventual consistency, der übersetzt etwa schlussliche Konsistenz bedeutet. Im Gegensatz dazu steht das Konzept der read-after-write consistency bei dem neue Daten tatsächlich direkt für alle sichtbar sind. Dabei sollte beachtet werden, dass es sich nicht um vollständige Konsistenz handelt. Lediglich neue Daten sind sofort sichtbar. Es gilt nicht für Änderungen und Löschung bereits existierer Daten. Der Vorteil bei diesem Ansatz ist, dass zumindest bei neuen Daten keine applikationsseitigen Vorkehrungen in Form einer geplanten Verzögerung nötig sind. Für S3 gibt es sogar Programme für FUSE-basiere Dateisysteme 3 mit denen es möglich ist, Buckets über das Dateisystem einzubinden. Aufgrund der oben genannten Konsistenzmodelle ist die Benutzung der Dateisysteme allerdings fehleranfällig. Der Preis für S3 berechnet sich aus drei Dimensionen: Die Menge der gespeicherten Daten: 0,125$ pro GB für den ersten Terrabyte bis zu 0,055$ ab 5000 TB. Art und Anzahl der Requests: 0,01$ pro GET Requests, 0,01$ pro PUT, COPY, POST oder LIST Requests Ausgeher Traffic: Kostenlos bis zum ersten GB. Bis 10 TB 0.120$ pro GB. Der Preis pro GB wird auch weniger je höher der Traffic ist Simple Queue Service (SQS) Amazon bietet mit SQS eine hoch-skalierbare und verlässliche Messagequeue an, in der Nachrichten zur späteren Verarbeitung gespeichert werden können. Eine Messagequeue wird vor allem zur asychnronen Verarbeitung von Informationen genutzt. Dabei dient sie als Zwischenspeicher zwischen verschiedenen Komponenten. Die Nachrichten können im Textformat bis zu einer Größe von 64 KB gespeichert werden. Wenn eine Nachricht von einer Komponente empfangen wird, wird diese gesperrt und ist unsichtbar für andere Komponenten bis die Verarbeitung der Nachricht als erfolgreich zurückgemeldet wird. Sollte die Verarbeitung fehlschlagen, wird die Sperre nach einer kurzen Zeit wieder aufgehoben und die Nachricht ist wieder sichtbar. Aufgrund der verteilten Architektur von SQS ist das Einhalten einer Reihenfolge beim Einstellen und Verarbeiten von Nachrichten leider nicht gegeben (First- In-First-Out (FIFO)). Welche Nachricht zuerst verarbeitet wird, ist dem Zufall überlassen. Die Nutzung von SQS kostet 0,01$ für Anfragen

50 3.3 Im Projekt verwete Dienste CloudWatch CloudWatch ermöglicht die Überwachung (Monitoring) einiger AWS Dienste. Für jeden dieser Dienste werden Zahlen über die Nutzung und den Zustand des Dienstes erstellt und abrufbar gemacht. Damit können Entwickler und Administratoren jederzeit den Ressourcenverbrauch, die Performance und den Status ihrer Anwungen überwachen und gegebenenfalls Maßnahmen treffen, um einen reibungslosen Betriebsablauf zu gewährleisten. Neben dem Abrufen von Nutzungsdaten gibt es die Möglichkeit Alarme für Ressourcen zu erstellen, die ausgelöst werden wenn ein definierter Schwellwert für eine Statistik bzw. Metrik über- oder unterschritten wird. Darüberhinaus können selbst gesammelte Daten als Metriken bei CloudWatch hochgeladen und abrufbar gemacht werden. Es hat sich heraussgestellt, dass Amazon derzeit für EC2 Instanzen keine Option anbietet den Arbeitsspeicher oder die Festplattenkapazität zu überwachen. Das ist laut [For12] (Antwort 6) dem Umstand geschuldet, dass die Messung von Arbeitsspeicher und Festplattenkapazität nur über das Betriebssystem realisiert werden kann. Sämtliche Messungen werden derzeit allerdings ohne Zuhilfenahme des laufen Betriebssystems der Instanz erstellt. Dies ist vor allem nötig, da nicht unbedingt AWS kompatible Betriebssysteme auf den AMIs installiert werden. In diesem Fall könnte die manuelle Messung der genannten Ressourcen Abhilfe schaffen. Die Ergebnisse der manuellen Messungen könnten dann über benutzerdefinierte Metriken bei CloudWatch abrufbar gemacht werden. Um Statistiken abzurufen müssen folge Parameter definiert werden: Namespace, z.b. AWS/EC2 Metrik, z.b. CPUUtilization oder DatabaseConnections (Optional) Dimension, meistens ein Ressourcenname z.b. InstanceId = i-345a74b1 oder DBInstanceIdentifier = appdb. Innerhalb dieser Dimension werden die Daten dann aggregiert. Zeitraum (Start- und Enddatum) Art der Statistik (Durchschnitt, Maximum, Minimum, Summe, Sample) Der Rückgabewert für einen API-Call zum Abruf von Statistiken beim aws-sdk Ruby Gem ist ein Hash, der als Key einen Zeitstempel hat und als Value den tatsächlich Wert, der zu diesem Zeitpunkt aufgezeichnet wurde. In der Regel werden die Daten über die Dienste im 5-Minuten Takt gesammelt und aggregiert. Für EC2-Instanzen gibt es noch die Möglichkeit eine detailliertes Monitoring zu aktivieren. Damit stehen Nutzungsdaten im Minutentakt zur Verfügung. Die Preise für 36

51 Kapitel 3 Amazon Webservices detailliertes Monitoring liegen pro Instanz bei 3,50$ im Monat. Pro Alarm werden 0,10$ fällig und pro benutzdefinierter Metrik 0,50$. Alle 1000 API-Calls fallen zusätzlich 0,01$ an. Eine detailliertere Beschreibung zu CloudWatch Alarmen ist in Abschnitt zu finden Elastic Compute Cloud (EC2) Mit EC2 kann innerhalb kürzester Zeit Rechenleistung in Form von virtuellen Maschinen in Anspruch genommen werden. Der Dienst zielt darauf ab, mit wenig Aufwand neue Server für Webapplikationen zur Verfügung zu stellen, die nach wenigen Minuten vollständig einsatzbereit sind. Über das API können die Maschinen entsprech konfiguriert und mit Zugangsrechten ausgestattet werden. Dafür wird zuerst ein AMI mit dem entsprechen Betriebssystem (Windows oder Linux) ausgewählt, die Hardware auf der die Instanz laufen soll und die Anzahl der Instanzen selbst. Der Zugriff auf die Instanzen wird über ein Schlüsselpaar gesteuert das im Vorfeld angelegt werden muss. Der Public Key wird auf dem Server hinterlegt. Nachdem der Benutzer den Private Key lokal auf seinem Computer abgelegt hat, kann auf den Server per SSH zugegriffen werden. Die Tabelle 3.1 zeigt die derzeit verfügbaren Instanz-Typen. Name CPU Einheiten CPU Kerne Arbeitsspeicher t1.micro Bis zu 2 ECUs MB m1.small 1 ECU GB c1.medium 5 ECUs GB m1.medium 2 ECUs GB m1.large 4 ECUs GB m1.xlarge 8 ECUs 4 15 GB m2.xlarge 6.5 ECUs GB m2.2xlarge 13 ECUs GB m2.4xlarge 26 ECUs GB c1.xlarge 20 ECUs 8 7 GB hi1.4xlarge 35 ECUs GB Tabelle 3.1: Instanz-Typen bei EC2 37

52 3.3 Im Projekt verwete Dienste Eine EC2 Compute Unit (ECU) ist eine Maßeinheit für CPU-Leistung. Sie wurde eingeführt um, trotz regelmäßiger Weiterentwicklung der CPUs durch die Industrie, eine allgemein gültige Aussage über die Rechenleistung einer CPU zu treffen. Eine ECU bietet die Kapazität eines 1,0- bis 1,2-Ghz Opteron- oder Xeon-Prozessors von EC2 bietet die Basis für weitere Dienste die mit EC2 angeboten werden, dazu gehören CloudWatch, AMI, Virtual Private Cloud (VPC), Elastic Block Store (EBS) und natürlich AutoScaling. Die ersten beiden werden noch in den entsprechen Abschnitten näher beleuchtet Amazon Machine Image (AMI) Ein AMI ist ein Abbild eines vorkonfigurierten Betriebssystems und dient als Grundlage einer EC2 Instanz. AMIs können öffentlich gemacht werden und anderen Nutzern zur Verfügung gestellt werden. Jedes AMI verfügt über eine eindeutige globale ID die beim Erzeugen einer neuen EC2 Instanz angegeben werden kann. Amazon selbst bietet auf seiner Seite 4 derzeit ca AMIs an die verwet werden können. AMIs stellen nicht nur installierte Betriebssysteme dar, sondern auch den aktuellen Stand der Installation. So können AMIs angeboten werden, die neben dem Betriebssystem auch bereits mit einem komplett vorkonfigurierten Softwarestack für das Betreiben von Anwungen abrufbar sind. Das Bereitstellen von Images für virtuelle Maschinen ist inzwischen sogar als Geschäftsfeld etabliert. Die Firma Bit- Nami [bit12b] bietet neben EC2 Images auch Images für Virtualbox, VMWare und AWS an, die für das Betreiben unterschiedlichster Anwungen geeignet sind. Der Installations- und Konfigurationsaufwand beim Betreiben eines Blogs, CMS oder Ähnlichem wird dabei auf ein Minimum reduziert. Die AMIs sind auch Grundlage für Auto Scaling. Neue Instanzen sollten immer mit dem aktuellsten AMI eines Servers gestartet werden um zu vermeiden, dass einige Instanzen mit einem alten Softwarestand betrieben werden. Dafür sollte ein spezieller Deployment-Prozess definiert werden der bei einer Softwareaktualisierung ein neues AMI erstellt und alle vorhandenen Server mit dem neuen AMI startet Virtual Private Cloud (VPC) Mit VPC können Instanzen in einem Netzwerk betrieben werden, das mit einem internen Firmennetzwerk verbunden werden kann. Die Konfiguration dieses virtuellen Netzwerkes kann komplett an die eigene Netzwerkstruktur angepasst werden. 4 https://aws.amazon.com/amis 38

53 Kapitel 3 Amazon Webservices Inklusive eines eigenen IP-Adressbereichs, Erstellung von Subnetzen und Konfiguration von Routentabellen und Netzwerk-Gateways. Eine sichere VPN-Verbindung ermöglicht die Kommunikation zwischen dem Unternehmensrechenzentrum und dem VPC, damit die AWS-Cloud als Erweiterung des Rechenzentrums genutzt werden kann. Neben den normalen EC2 Kosten entstehen dafür 0,05 $ pro VPN- Verbindungsstunde an [Ser12b] Elastic Block Store (EBS) Bei EBS handelt es sich um Datenträger die von EC2 Instanzen eingehängt werden können. Damit können Daten außerhalb und unabhängig von der Laufzeit einer Instanz gespeichert werden. Das ist vor allem wichtig wenn bei einer Instanz größere Daten, zum Beispiel in Form einer Datenbank, gespeichert werden müssen. Im Gegensatz zu einem EBS Volume sind alle Daten einer Instanz in dem Moment verloren, wenn die Instanz terminiert wird (sofern das Image der Instanz nicht als AMI gespeichert wurde). Die Eigenschaften von EBS im Überblick: Einer EC2 Instanz können mehrere EBS Volumes eingehängt werden, dagegen kann ein EBS nur von einer Instanz gleichzeitig verwet werden. Die Größe kann von 1 GB bis 1 TB gewählt werden. Die Datenträger verhalten sich wie rohe, unformatierte Block-Geräte und können mit jedem Dateisystem formatiert werden. Instanzen und EBS Volumes müssen sich in der selben Availability Zone befinden. Innerhalb der Zone werden die Datenträger repliziert und damit ausfallsicher betrieben. Snapshots ermöglichen das Backup von bestimmten Zeitpunkten, die dann als Grundlage für weitere EBS Volumes dienen. Mit CloudWatch kann der Zustand eines Volumes überwacht werden. Für EBS Volumes können Snapshots erstellt werden. Diese Snapshots beinhalten den Stand eines EBS Volumes zu einem bestimmten Zeitpunkt und können als Grundlage für weitere EBS Volumes genutzt werden. Für die Nutzung von EBS Volumes fallen Kosten an, die durch den verbrauchten Speicherplatz (Storage) abgerechnet werden Auto Scaling Auto Scaling ermöglicht es, automatisiert Änderungen an der Infrastruktur vorzunehmen falls die Auslastung kurzfristig steigt oder fällt. Dafür können Bedingungen definiert werden, die das zusätzliche Bereitstellen oder Entfernen von EC2 Instanzen 39

54 3.3 Im Projekt verwete Dienste auslösen. So kann bei vielen Zugriffen zeitnah eine Überlastung der Server behoben werden oder die Anzahl der Server verringert werden, falls die Zugriffszahlen sinken und diese nicht ausgelastet sind. Auto Scaling eignet sich hervorrag um Lastspitzen abzufangen oder Kosten einzusparen wenn die Infrastruktur nicht vollständig genutzt wird. Um Bedingungen zu definieren, die eine Änderung an der Infrastruktur auslösen, werden Metriken vom CloudWatch Dienst verwet. Auto Scaling Konfigurationen können derzeit nur über das API definiert und nur teilweise über die Management Console eingesehen bzw. modifiziert werden (zum Beispiel Alarme). Eine Auto Scaling Konfiguration hat folge Bestandteile: Launch Configuration: Zu Anfang wird eine Launch Configuration erstellt, die die Art der EC2 Instanz definiert. Zur Erstellung werden Parameter wie AMI, den Instanz-Typ (Hardware-Konfiguration) und weitere Optionen wie Security Groups oder das Keypair für den SSH-Zugriff festgelegt. Launch Configurations können nur erstellt und nicht nachträglich modifiziert werden. Auto Scaling Group: Die Instanzen werden in einer Auto Scaling Group zusammengefasst. In dieser Gruppe wird definiert welche Launch Configuration zum Einsatz kommen soll, in welchen Availability Zones die Instanzen erstellt werden sollen und die Anzahl der Instanzen (Minimum und Maximum). Es stehen weitere Optionen zur Verfügung um zum Beispiel einen Load Balancer zu definieren, bei dem die automatisch bereitgestellten Instanzen eingehängt werden sollen. Oder die Möglichkeit eine Abklingzeit zu definieren, bevor eine erneute Skalierung vorgenommen wird. Das Zusammenfassen der Instanzen als Gruppe dient auch dazu, um Metriken über mehrere Instanzen zu erstellen. Ein klassisches Beispiel für eine Skalierungsmetrik wäre die CPU-Auslastung: in den meisten Fällen wird eine Skalierung vorgenommen, wenn die Applikationsserver innerhalb der Infrastruktur eine zu hohe CPU-Auslastung haben. Mit Hilfe der Auto Scaling Group lässt sich eine durchschnittliche CPU-Auslastung aller beteiligten Server innerhalb der Gruppe berechnen (wird als CloudWatch-Metrik zur Verfügung gestellt). Diese durchschnittliche Auslastung aller Server dient als Maß für das Bereitstellen oder Herunterfahren von Instanzen. Scaling policies: Innerhalb einer Auto Scaling Group können Scaling policies definiert werden. Scaling policies definieren Aktionen, die auf einer Auto Scaling Group ausgeführt werden sollen. Die Parameter für eine Policy sind: Typ der Anpassung (ChangeInCapacity, ExactCapacity, PercentChangeInCapacity) und ein Wert, der bestimmt wieviele Instanzen hinzugefügt oder entfernt werden sollen. In der Regel werden zwei Policies definiert: eine die beschreibt was passiert wenn hochskaliert (Scale Up) wird und eine die definiert was passiert wenn die Server nicht ausgelastet sind (Scale down). 40

55 Kapitel 3 Amazon Webservices CloudWatch Alarms: Die Überwachung der Infrastruktur wird über den CloudWatch Dienst realisiert. Innerhalb von CloudWatch ist es möglich Alarme zu definieren die bei Über- oder Unterschreitung von bestimmten Werten bei Metriken eine Aktion auslösen. Eine Aktion kann dabei entweder eine Auto Scaling Policy sein oder eine Policy eines Simple Notification Service (SNS) Topics. SNS ist ein weiterer Dienst von AWS der Nachrichten in Form von HTTP-Requests, s, SMS oder SQS Messages verschickt. Ein Alarm setzt sich unter anderem aus folgen Elementen zusammen (mit Beispielen): Auszuführe Aktion Name der Metrik zum Beispiel CPUUtilization. Dimension: der Name der Auto Scaling Group oder Name der SQS Queue. Einheit: Prozent (CPU-Auslastung) oder Anzahl (SQS Nachrichten). Statistik: Durchschnitt (CPU) oder Summe (Anzahl SQS Nachrichten). Schwellwert (Threshold): z.b. 70% CPU Auslastung oder 10 Nachrichten in der Queue. Vergleichsoperator: GreaterThanThreshold oder LessThanOrEqualToThreshold. Zeitraum in Sekunden in dem eine Statistik/Metrik abgerufen wird. Anzahl Evaluationen: Wie oft Daten mit dem Schwellenwert verglichen werden, bevor eine Aktion ausgelöst wird. Ein Alarm hat unterschiedliche Zustände: ALARM, OK und INSUFFICIENT DATA. Der Normalzustand ist OK. Wenn ein Alarm ausgelöst wird, wird in ALARM gewechselt. Wenn ein Fehler beim Evaluieren der Daten auftritt befindet der Alarm sich im Zustand INSUFFICIENT DATA. Sobald eine angegebene Metrik währ aller Evaluationszeitpunkte über oder unter dem gegebenen Schwellwert für eine Metrik ist, wird die entspreche Aktion ausgeführt. Für die Nutzung von Auto Scaling werden keine zusätzlichen Kosten berechnet. Es fallen lediglich Gebühren für die Nutzung von CloudWatch an, falls detailliertes Monitoring für EC2 Instanzen aktiviert ist oder Alarme eingerichtet und genutzt werden. Die Abbildung 3.4 verdeutlicht die Funktionsweise von Auto Scaling. 41

56 3.3 Im Projekt verwete Dienste Abbildung 3.4: Funktionsweise des Auto Scaling 42

57 Kapitel 3 Amazon Webservices 3.4 Ruby Gem aws-sdk Da das umzusetze Projekt in Ruby mit dem Ruby on Rails Framework geschrieben wird, wird auch bei der Nutzung des APIs auf das Ruby Gem aws-sdk zurückgegriffen. Das Gem selbst ist Open Source und kann auf Github 5 heruntergeladen werden. Die Weiterentwicklung des Gems scheint sehr aktiv vorangetrieben zu werden. Die Wahrscheinlichkeit, dass zukünftige Änderungen am AWS API ihren Weg nicht in das SDK für Ruby finden, ist also sehr gering. Aktuell unterstützt das SDK alle derzeit angebotenen API Funktionen. Die Nutzung des SDKs ist teilweise auch auf den Gebrauch mit einer Ruby on Rails Anwung abgestimmt. Bei der Konfiguration der Zugangsdaten (Key-ID und Secret Access Key) für das API wird automatisch nach einer config.yml Datei gesucht, welche die erforderlichen Informationen enthält. Auch die Nutzung eines Object Relational Mapping (ORM) auf Basis von SimpleDB als Ersatz für Rails eigenes ORM-Tool ist möglich. Insgesamt ist das SDK hervorrag auf das Sprachpotential von Ruby angepasst. 5 https://github.com/amazonwebservices/aws-sdk-for-ruby 43

58

59 Kapitel 4 Auto-Scaling AWS Ein grober Ablauf beim Erstellen der Builds wird bereits in Abschnitt der Einleitung beschrieben. Als zentrale Komponente dient eine Ruby on Rails Anwung, bei der sich Benutzer registrieren können und dort ihren Source-Code hochladen und entspreche Build-Konfigurationen verwalten können. Die Skalierung dieser Web-Anwung ist nicht Bestandteil dieser Thesis und kann über herkömmliches Auto-Scaling über die CPU-Auslastung realisiert werden. Projektund build-spezifische Daten werden in einer MySQL Datenbank auf dem App-Server gespeichert. Dateien wie fertige Builds und Source-Code werden in einem S3 Bucket abgelegt. Worker-Instanzen beziehen ihre Informationen über zu erledige Jobs aus einer SQS Messagequeue die als zentrale Ablage für Jobs dient. S3 und SQS werden bereits durch Amazon als skalierbar und hochverfügbar angeboten. Die eigentliche Herausforderung liegt beim Skalieren der Worker-Instanzen, entsprech der Anzahl von zu bearbeiten Jobs. Eine Anforderung für das Projekt ist es, dass unabhängig von der Anzahl der derzeit eingestellten Jobs, die Abarbeitung selbiger immer nur so kurz wie nur möglich dauert. Die Erstellung eines Builds dauert, je nach Größe des Projekts, ungefähr Sekunden. Währ dieser Zeit hat die Worker-Instanz eine konstante CPU-Auslastung von 100%. Daraus ergibt sich, dass der Worker nur dann effizient arbeitet, wenn nur ein Build gleichzeitig pro Instanz ausgeführt wird. Damit oben genannte Anforderung erfüllt ist, muss das Auto-Scaling so implementiert werden, dass sehr zeitnah neue Worker-Instanzen zur Verfügung stehen wenn eine größere Menge von Jobs in der Queue auf Abarbeitung wartet. Der Zeitraum bis einer neuer Worker voll einsatzbereit ist, liegt bei ca. 20 Sekunden. Danach ist das Betriebssystem hochgefahren und das auf dem Worker befindliche Skript zum Pollen nach Jobs ist gestartet worden. Standardmäßig soll immer ein Worker dauerhaft in Betrieb sein und auf Jobs warten. In dem Fall, dass zu einem Zeitpunkt mehrere Jobs eingestellt werden, müssen neue Instanzen bereitgestellt werden. Es fällt also eine zusätzliche Aufwärmzeit von 20 Sekunden für neue Worker an. Für die Erfüllung der Anforderungen muss gewährleistet werden, dass innerhalb kürzester Zeit die Infrastruktur so aufgestockt wird, dass entweder genüg Worker bereit stehen falls eine größere Menge an Jobs ansteht oder 45

60 bei einer Leerlaufzeit Worker-Instanzen aus Kostengründen heruntergefahren werden. 46

61 Kapitel 4 Auto-Scaling AWS 4.1 Tests für AutoScaling Ursprünglich war geplant, das Testen des AutoScaling über ein Load-Testing Tool wie JMeter zu machen. JMeter ist in Java geschrieben und ermöglicht das Performancetesting von Web-Anwungen. Dabei werden die Anwungen vor allem auf ihr Verhalten hinsichtlich der durchschnittlichen Antwortzeit getestet. Mit JMeter lassen sich Requests definieren, die dann in einer bestimmten zeitlichen Abfolge, vor allem gleichzeitig, an die Web-Anwung geschickt werden. Dabei werden Daten gesammelt die Aufschluss darüber geben, wie viele gleichzeitige Anfragen die Anwung bearbeiten kann und trotzdem noch eine vertretbare Antwortzeit einhält. Im Verlauf des hier behandelten Projektes hat sich diese Methode allerdings als nicht sinnvoll bewiesen. Die Architektur der Anwung sieht vor, dass beim Einstellen von Jobs die Daten zuerst in einer SQS Queue zwischengespeichert werden. Das Messen mit JMeter würde lediglich den Teil der Anwung testen, bei dem per Request ein Job eingestellt wird und anschließ die Daten für diesen Job in die Queue geschrieben werden. Die daraus entstehen Testdaten würden zwar Aufschluss darüber geben, wie gut die Rails Anwung antwortet, aber nicht wie schnell die Jobs abgearbeitet werden. Aus diesem Grund wurde entschieden, ein eigenes Skript zu schreiben, welches auf der Rails Anwung direkt im Code Jobs in die SQS einstellt und anschließ misst, wie lange es dauert bis ein Job abgearbeitet wird. Das Skript ist ebenfalls in Ruby geschrieben und wird als eine Sammlung von Rake-Tasks implementiert. Rake ist ein Build-Tool für Ruby das Ähnlichkeiten zu make aufweist. Im Rahmen einer Rails-Anwung wird Rake meist dafür verwet, um zum Beispiel Migrationen auf der Datenbank oder Tests für eine Anwung laufen zu lassen. Ein großer Vorteil von Rake ist, dass man vor der Ausführung eines Tasks die Laufzeitumgebung aus der Rails Anwung laden kann. Damit stehen sämtliche Klassen und Daten aus der Anwung zur Verfügung und können instanziiert bzw. abgerufen werden. In dem Rakefile werden zwei Tasks definiert: Der Task setup (Listing A.1) erstellt beim Aufrufen eine einstellbare Anzahl von Projekten und Build-Konfigurationen die einem Benutzer zugeordnet werden. Inklusive Upload des Source-Codes und der entsprechen Keystores um den Android-Build zu signieren. Der zweite Task start startet den eigentlichen Test (Listing A.2). Dabei werden für alle erstellten Build-Konfigurationen die entsprechen Jobs für die Worker generiert und in die SQS Queue abgelegt. Anschließ wird die Zeit gemessen, wie lange es dauert bis ein Job erledigt ist. Die Überprüfung läuft so lange bis alle Jobs abgearbeitet wurden. Beide Tasks werden in einer Datei namens worker_tests.rake unter dem Ordner lib/tasks/ innerhalb des Rails Projektes abgelegt. Der Aufruf der Tasks findet dann auf dem App-Server im Projekt-Root der Rails-Anwung mit dem Befehl 47

62 4.1 Tests für AutoScaling rake worker_tests:setup RAILS_ENV=production statt. Die Umgebungsvariable RAILS_ENV wird für den Aufruf auf production gesetzt, damit die Tasks auf die Daten aus der Produktions-Datenbank zugreifen. Ein Beispielhafter Output für den Aufruf von worker_tests:start ist in Listing 4.1 zu sehen. Listing 4.1: Output bei einem Worker Test mit 10 Jobs für einen Worker [ : 51: 33] todostest8 : SUCCESS after 46 seconds [ : 52: 18] todostest1 : SUCCESS after 92 seconds [ : 52: 49] todostest2 : SUCCESS after 122 seconds [ : 52: 50] todostest9 : SUCCESS after 123 seconds [ : 53: 18] todostest5 : SUCCESS after 151 seconds [ : 53: 19] todostest6 : SUCCESS after 152 seconds [ : 53: 23] todostest4 : SUCCESS after 156 seconds [ : 54: 09] todostest10 : SUCCESS after 202 seconds [ : 54: 53] todostest7 : SUCCESS after 246 seconds [ : 55: 38] todostest3 : SUCCESS after 291 seconds Testablauf Jeder Skalierungsansatz wird denselben Testbedingungen unterliegen. Dazu werden 30 Jobs zeitgleich zur Bearbeitung eingestellt. Anschließ wird überwacht wie lange die Abarbeitung der einzelnen Jobs dauert und die gesamte Dauer aufgezeichnet. Währ dem Test wird manuell über die AWS Management Console geschaut, wann die einzelnen Skalierungsaktionen ausgelöst werden. 48

63 Kapitel 4 Auto-Scaling AWS 4.2 Skalierungsansätze Die Architektur des Systems wurde so entworfen, dass die zentrale Rails Anwung keinerlei Kenntnisse über die Anzahl der Worker haben muss, um eine lose Kopplung der Komponenten zu gewährleisten. Aus diesem Grund werden sämtliche Job-Informationen in der SQS Messagequeue zwischengespeichert und nicht direkt von der Plattform an die Worker-Instanzen geschickt. Ein solches Vorgehen würde ein Management der Worker-Instanzen von der Plattform aus voraussetzen. Bei höherem Benutzeraufkommen auf der Plattform könnte es allerdings dazu kommen, dass mehrere App-Server zur Verfügung gestellt werden müssten. Das würde bedeuten, dass nur eine dieser Instanzen das Management der Worker-Instanzen übernehmen muss oder dass eine weitere Komponente geschaffen werden muss, die sich nur um die Verwaltung der Worker kümmert. Um die Rails Anwung selbst skalierbar zu halten, wird dieser Ansatz vorerst nicht verfolgt. Die tatsächliche Umsetzung sieht vor, dass das Skript zum Abarbeiten von Jobs auf dem Worker bereits beim Starten des Systems automatische gestartet wird und anfängt nach Jobs zu pollen. Dem Worker ist dabei der Ort der Queue, das S3 Bucket und der Ort der Rails Anwung bekannt. Das sind die Informationen, die nötig sind um Jobs abzuarbeiten und der Plattform zu melden, dass Jobs erfolgreich abgearbeitet wurden. Im Fall einer Skalierung der Rails-Anwung würde ein Load-Balancer vor mehrere App-Instanzen geschaltet werden, auf den die Worker ihre Informationen schicken würden. Andersherum dagegen ist der Ort oder die Anzahl der Worker den App-Servern nicht bekannt, da diese Informationen ständig variieren können. Es reicht also eine EC2 Instanz mit einem vorgefertigten Worker-Image zu starten, damit der Worker automatisch seiner Aufgabe nach geht. In den folgen Abschnitten wird auf mehrere Skalierungsansätze eingegangen Ansatz 1: AutoScaling auf Basis der durchschnittlichen CPU-Auslastung Der herkömmliche Ansatz beim Skalieren von Applikationsservern sieht vor, die aktuelle CPU-Auslastung aller beteiligten Server zu messen und anhand des durchschnittlichen Wertes neue Instanzen hochzufahren oder bei geringer Auslastung Instanzen herunterzufahren. Als Indikator für die Auslastung wird die durchschnittliche CPU-Auslastung aller EC2 Instanzen innerhalb einer AutoScaling Group verwet. Anhand eines Schwellwertes werden pro Messintervall neue Instanzen hinzugefügt (Scaling Policy mit ChangeInCapacity +-1). Im nächsten Messintervall ist dann, bei gleichbleibem Traffic, die durchschnittliche Auslastung geringer und die Infrastruktur befindet sich im Idealzustand. 49

64 4.2 Skalierungsansätze Die Problematik bei der Skalierung von Worker-Instanzen liegt in erster Linie daran, dass die CPU-Auslastung bei der Bearbeitung eines Jobs direkt bei 100% liegt. Damit würde sogar bei der Abarbeitung von nur 1-2 Jobs sofort eine Scaling Aktion ausgelöst werden. Unnötiges Hochfahren von Instanzen wäre die Folge. Ein Problem wäre auch der Downscale: Er würde nur statt finden, wenn tatsächlich keine Jobs abzuarbeiten wären und selbst dann würde nur eine Instanz pro Messintervall heruntergefahren werden. Die Ineffizienz dieses Ansatzes widerspricht dem Ansatz des AutoScaling völlig und stellt sich als nicht geeignet für die vorliege Problematik heraus. Ein weiteres Problem ergibt sich dadurch, dass die Anzahl der Instanzen pro Messintervall (eine Minute) immer nur um 1 erhöht werden würde. Die Anzahl der Jobs, die insgesamt auf Abarbeitung warten, würde nicht berücksichtigt werden. In Abbildung 4.1 ist der Aufbau für den Skalierungsansatz auf Basis der durchschnittlichen CPU Auslastung beschrieben: Die Worker laufen in einer AutoScaling Group mit mindestens einer Instanz und einem definierten Maximum. Jede Minute wird per CloudWatch die durchschnittliche CPU-Auslastung der Instanzen innerhalb der AutoScaling Group gemessen. Zwei Alarme sorgen dafür, dass eine Aktion ausgelöst wird, falls die CPU-Auslastung über oder unter einen gewissen Schwellwert steigt/sinkt. Die Alarme lösen dann die entsprechen Scaling Policies aus, die laufe Instanzen aus der AutoScaling Group entfernen oder neue Instanzen hinzufügen Ansatz 2: AutoScaling auf Basis eingestellter Nachrichten die MessageQueue Das Hauptproblem im ersten Ansatz wird durch eine falsch gewählte Metrik verursacht. Ausschlaggeb für eine Skalierungsaktion sollte statt der CPU-Auslastung die Anzahl der Jobs in der SQS Queue sein. Als Indikator würde sich die Metrik NumberOfMessagesSent für SQS besser eignen. Die Metrik gibt Aufschluss darüber, wie viele Jobs zu einem Zeitpunkt in die Queue eingestellt wurden. Anhand dieser Anzahl lässt sich darauf schließen wie viele Worker Instanzen notwig sind, um das Arbeitsaufkommen zu bewältigen. Eine Upscale-/Downscale Aktion würde ausgelöst werden, wenn eine bestimmte Anzahl von Jobs in die Queue eingestellt wird. Es würden Alarme für die Anzahl der benötigten Worker erstellt werden, die bei bestimmter Anzahl von Jobs dafür sorgen, dass mehr Worker bereitstehen. Bei diesem Ansatz entstehen neue Probleme: Zum einen liegt der Monitoring-Intervall für SQS bei 5 Minuten. Die Informationen darüber, wie viele Jobs tatsächlich eingestellt wurden, wird somit 50

65 Kapitel 4 Auto-Scaling AWS Abbildung 4.1: AutoScaling Setup auf Basis der durchschnittlichen CPU Auslastung nur alle 5 Minuten aktualisiert. Ein kostenpflichtiges Monitoring auf Minutenbasis wie bei EC2 Instanzen ist nicht verfügbar. Der damit entstehe Zeitraum zum Auslösen von Alarmen ist zu hoch um neue Worker-Instanzen effizient bereit zu stellen. Ein potentieller Lösungsansatz für das Problem wären die Custom Metrics. Wie bereits kurz in Abschnitt beschrieben, gibt es für CloudWatch die Möglichkeit eigene Metriken zu erstellen. Dafür muss nur ein API-Call mit einem Metrik-Namespace, dem Namen der Metrik selbst und einem Wert auf das CloudWatch API gemacht werden. Diese Daten sind dann, genauso wie die anderen Metriken, über CloudWatch abrufbar. Allerdings stellte sich währ der Implementierung heraus, dass die gesammelten Daten mit einer Verzögerung von 15 Minuten abrufbar sind. Damit stellte sich auch das Erstellen einer eigenen Metrik als ungeeignet heraus. Ein weiteres neues Problem war die neue Metrik. NumberOfMessagesSent gibt Auskunft darüber, wie viele neue Jobs zu einem Zeitpunkt in die Queue gestellt wurden. Das stellte sich nach der Implementierung als ungünstig heraus: Die Anzahl neuer Jobs würde regelmäßig eine neue Skalierungsaktion auslösen, obwohl vielleicht schon genüg Instanzen existieren, die das neue 51

66 4.2 Skalierungsansätze Arbeitsaufkommen bereits bewältigen könnten. Eine dafür besser geeignete Metrik ist ApproximateNumberOfMessagesVisible. Diese Metrik beschreibt zu einem Zeitpunkt, wie viele Nachrichten in der Queue auf Abarbeitung warten und bisher noch von keinem Worker abgeholt wurden. Hinzu kommt, dass die Anzahl der bereits existieren Worker nicht in der Entscheidungsfindung, ob ein Alarm ausgelöst wird, mit einbezogen wird. Theoretisch müsste vor der Auslösung eines Alarms festgestellt werden, ob die aktiven Worker in der Lage sind die Anzahl der Jobs in der Queue in einem zufriedenstellen Zeitraum abzuarbeiten. Der entspreche Quellcode der Ruby Klasse AutoScaling ist in Listing A.4 zu finden. Dort wird bereits auf die geeignetere Metrik mit ApproximateNumberOf- MessagesVisible zurückgegriffen. Aufgerufen wird die Klasse aus einem Rake Task (Listing A.3). Der Rake Task dient nur zum einmaligen Setup der AutoScaling Konfiguration und der Option zum Löschen der selbigen. Weiterhin bleibt das Problem bestehen, dass die Scaling Policies die Anzahl der Worker in einem Monitoring-Intervall nur um eine Instanz erhöhen oder verringern. Die Lösung dafür wäre es, die Policies so anzupassen, dass immer eine genau Anzahl von Instanzen in der AutoScaling Group existiert. Dafür würde bei der Definition einer Scaling Policy der Parameter adjustment type auf ExactCapacity mit dem entsprechen Soll-Wert der aktiven Instanzen gesetzt Testergebnisse für Ansatz 2 Für den Test wurden drei Testdurchläufe durchgeführt: Test 1: Dauer: 1174 Sekunden, Beteiligte Worker: 2 Im ersten Durchlauf wurden im Vorfeld keine Jobs in die Queue hinzugefügt. Aus diesem Grund setzt erfolgreiches Monitoring erst 11 Minuten nach Testbeginn ein. Bis dahin zeigen die Alarme INSUFFICIENT DATA an. Vermutlich werden die CloudWatch-Daten nur aktuell gehalten, wenn regelmäßig Daten zu einer Metrik gesammelt werden können. Wurden länger keine Daten gesammelt, ist ein gewisser Zeitraum nötig bis die Daten dann als Grundlage für einen Alarm verwet werden können. Nachdem die Daten 11 Minuten nach Testbeginn verfügbar sind, wird der einzige Alarm währ des Testzeitraums ausgelöst. Anschließ wird bei neuen Monitoring-Intervallen keine neue Skalierungsaktion ausgelöst, weil die Alarme melden, dass vor kurzem erst eine Skalierung vorgenommen wurde. Test 2: Dauer: 1533 Sekunden, Beteiligte Worker: 1 Im zweiten Test wurde versucht die Cooldown-Zeit für Skalierungsaktionen zu entfernen bzw. zu verringern. Als Messperiode für die SQS Metrik wird 60 Sekunden 52

67 Kapitel 4 Auto-Scaling AWS statt 300 Sekunden eingestellt. Obwohl währ des Tests durchgeh Daten für die Alarme vorhanden sind, zeigt CloudWatch an, dass nicht genüg Daten für das Auslösen der Alarme zur Verfügung stehen. Ein Screenshot (Abbildung 4.2) zeigt die fehlerhafte Meldung. Es ist gut zu sehen, dass entspreche Daten für die Alarme in den unteren beiden Diagrammen im Bild auf jeden Fall vorhanden sind. Als Folge des Bugs werden keinerlei zusätzliche Worker-Instanzen hochgefahren. Abbildung 4.2: Fehlerhaftes Verhalten von CloudWatch währ dem zweiten Testdurchlauf für Ansatz 2 Test 3: Dauer: 1143 Sekunden, Beteiligte Worker: 3-4 Währ des dritten Testdurchlaufs scheinen die Alarme wieder einwandfrei zu funktionieren. Die Skalierung funktioniert und bis Ende des Tests werden drei Worker-Instanzen hochgefahren. Theoretisch müssten wesentlich mehr Worker hochgefahren werden, allerdings verhindert der Cooldown-Timer für die Scaling Policy das weitere Skalieren. Nach Ende der Tests wird aufgrund verspäteter Monitoring- Daten noch eine weitere vierte Worker-Instanz hochgefahren obwohl diese gar nicht nötig wäre. Erkenntnisse der Testdurchläufe: Die interessanteste Beobachtung ist, dass sich die Dauer zur Abarbeitung der Jobs bei Testdurchlauf 1 und Test 3 kaum unterscheiden, obwohl ein Worker mehr bei der Abarbeitung beteiligt ist. Offensichtlich ist das gestaffelte Hochfahren der Instanzen sehr ineffizient. Würden in einem Realfall tatsächlich 30 Jobs gleichzeitig bearbeitet werden müssen, wäre die Wartezeit für den letzten Job bei 20 Minuten. Dieser Zeitraum ist viel zu hoch und entspricht in keinster Weise den Anforderungen für das 53

68 4.2 Skalierungsansätze Projekt. Abbildung 4.3 zeigt die Dauer für die Abarbeitung der Jobs im Vergleich zwischen den Tests. Abbildung 4.3: Vergleich der Tests nach Dauer in Sekunden für 30 Jobs Ansatz 3: Hybrides AutoScaling mit manueller Auslösung von Scaling Policies Aus den bereits erkannten Problemen ergibt sich folger Idealfall: Für jede Anzahl von (sichtbaren) Jobs in der Queue wird bis zu einem Maximum definiert, wie viele Worker für die Abarbeitung dieser Anzahl bereitstehen müssen. Die Anzahl der sichtbaren Nachrichten wird dabei nicht aus CloudWatch Monitoring-Daten gewonnen, sondern direkt bei SQS über einen API-Call abgefragt, damit der Wert tatsächlich in Echtzeit verfügbar ist. Währ eines Monitoring- Intervalls, wird dieser Soll-Wert mit dem Ist-Wert, also der Anzahl der aktuell vorhandenen Worker, verglichen. Gegebenenfalls wird die Anzahl der Worker erhöht oder verringert. Bei einem festgelegten Maximum von sechs gleichzeitig laufen Workern ergeben sich beispielsweise sechs Policies, die alle die ExactCapacity einer Scaling Group auf die Soll-Anzahl der Worker setzen. Dieser Ansatz ist allerdings mit den herkömmlichen CloudWatch Alarmen nicht umsetzbar, da die Anzahl der vorhandenen Instanzen nicht als Parameter eines Alarms festgelegt werden kann. Die funktioniere aber ineffziente Lösung dieses Problems wäre der dritte Ansatz: Eine hybride Lösung bei der das Hochfahren von Instanzen manuell entschieden wird und das Herunterfahren weiterhin über einen CloudWatch Alarm aus- 54

69 Kapitel 4 Auto-Scaling AWS gelöst wird. Ein selbstgeschriebenes Skript wird über einen Cronjob jede Minute ausgeführt und überprüft die Anzahl der Jobs mit der ApproximateNumberOfMessagesVisible Metrik für die SQS Queue. Gleichzeitig wird die aktuelle Anzahl der aktiven Worker in der AutoScaling Group abgefragt. Wenn die Anzahl der Jobs größer ist als das definierte Maximum für die derzeit laufen Worker-Instanzen, werden über das API neue Instanzen in der AutoScaling Group hochgefahren. Im nächsten manuellen Monitoring-Intervall sollte bei gleichbleiber Anzahl von Jobs die Anzahl der Instanzen als ausreich befunden werden und keine neue Skalierungsaktion ausgelöst werden. Abbildung 4.4 zeigt die beteiligten Komponenten und deren Zusammenspiel miteinander. Das Herunterfahren von Instanzen (Downscale) bei geringer Auslastung wird weiterhin über einen Alarm realisiert der ausgelöst wird, wenn über einen Zeitraum von 15 Minuten hinweg die Anzahl der abzuarbeiten Jobs 0 beträgt. Dieses Vorgehen ist zwar sehr ineffizient, kann aber nicht anders realisiert werden. Die Problematik beim Downscale ist bei allen Ansätzen ähnlich: Es ist keiner Komponente bekannt, welche Worker-Instanzen zu einem Zeitpunkt mit der Abarbeitung eines Jobs beschäftigt sind. Würde man den Zeitraum für eine Downscale-Aktion kürzer setzen, wäre die Gefahr zu hoch, dass aufgrund einer geringen Job-Anzahl Instanzen heruntergefahren werden, obwohl die betreffen Instanzen gerade Jobs bearbeiten. Der Build-Prozess würde durch den Shutdown unterbrochen werden und würde nicht erfolgreich zu Ende geführt. In dem Fall, dass regelmäßig neue Jobs anfallen, würde also nie ein Downscale der Worker-Instanzen statt finden. Der Quellcode zur Klasse ManualScaling befindet sich in Listing A.6. Auch hier gibt es wieder einen Rake-Task (Listing A.5) für Setup und Löschen der Konfiguration. Der Task ms:monitor übernimmt das Monitoring im Minutentakt und wird manuell auf dem Applikationsserver aufgerufen. Der Ansatz funktioniert wie beschrieben, erweist sich allerdings als relativ ineffzient bezüglich der Entscheidung zum Herunterfahren von Instanzen betrifft. Das Problem ist, dass nicht selektiv bestimmte Instanzen heruntergefahren werden können, die aktuell keinen Job ausführen. Um Fehler bei der Bearbeitung von Jobs zu vermeiden muss immer sicher gestellt werden, dass kein Worker in der AutoScaling Group mehr mit der Ausführung eines Jobs beschäftigt ist. Dieses Vorgehen könnte nur entschärft werden, indem man eine zentrale Komponente bereitstellt, die Informationen darüber bereit hält, welche Instanzen einen Job bearbeiten. 55

70 4.2 Skalierungsansätze Abbildung 4.4: Hybride Lösung mit manueller Auslösung der Scaling Policies für Aufwärtsskalierung Testergebnisse für Ansatz 3 Für den hybriden Skalierungsansatz funktioniert bereits der erste Testablauf wie erwartet. Für die 30 Jobs wird direkt innerhalb des ersten Monitoring-Intervalls das definierte Maximum an Worker hochgefahren. Das Monitoring ist so konfiguriert, dass aus Kostengründen vorerst eine maximale Anzahl an sechs Worker-Instanzen zur Abarbeitung verwet werden soll. Ab einer Gesamtzahl von 18 Jobs werden alle Worker hochgefahren. Das entspricht ungefähr einem Pensum von 3 Jobs pro Worker. Unter 18 Jobs sieht die Konfiguration folgermaßen aus: 56

It's all in the Cloud! Cloud Computing Grundlagen

It's all in the Cloud! Cloud Computing Grundlagen It's all in the Cloud! Cloud Computing Grundlagen Folie: 1/25 Agenda Einleitung - Cloud Computing Begriffe Überblick - Wer bietet was? Der Weg zur Private Cloud Einblick - RRZK und Cloud Computing Anmerkung

Mehr

Stefan Kusiek BFW-Leipzig

Stefan Kusiek BFW-Leipzig Stefan Kusiek BFW-Leipzig Schnellere Geräte (CPU, HDD, RAM, ) Mehrere Geräte (CPU, HDD, RAM, ) Mehrere Geräte (Rechner, Server, ) Cluster Preiswerter????? Mindestgröße Installation Konfiguration Wartung

Mehr

Gliederung. Was ist Cloud Computing Charakteristiken Virtualisierung Cloud Service Modelle Sicherheit Amazon EC2 OnLive Vorteile und Kritik

Gliederung. Was ist Cloud Computing Charakteristiken Virtualisierung Cloud Service Modelle Sicherheit Amazon EC2 OnLive Vorteile und Kritik Cloud Computing Gliederung Was ist Cloud Computing Charakteristiken Virtualisierung Cloud Service Modelle Sicherheit Amazon EC2 OnLive Vorteile und Kritik 2 Bisher Programme und Daten sind lokal beim Anwender

Mehr

Cloud Computing Technologien. Maxim Schnjakin 16. April 2013

Cloud Computing Technologien. Maxim Schnjakin 16. April 2013 Cloud Computing Technologien Maxim Schnjakin 16. April 2013 Agenda 1 Cloud Computing Technologien Worum geht s? Seminarthemen Was soll gemacht werden? Organisation Wie soll s ablaufen? Definition of Cloud

Mehr

Der Begriff Cloud. Eine Spurensuche. Patric Hafner 29.06.2012. geops

Der Begriff Cloud. Eine Spurensuche. Patric Hafner 29.06.2012. geops Der Begriff Cloud Eine Spurensuche Patric Hafner geops 29.06.2012 Motivation Der größte Hype der IT-Branche Hype heißt sowohl Rummel als auch Schwindel slashdot.org The cloud represents a foundational

Mehr

Vertrags- und Lizenzfragen im Rahmen des Cloud Computing LES Arbeitsgruppenmeeting 13. Mai 2011

Vertrags- und Lizenzfragen im Rahmen des Cloud Computing LES Arbeitsgruppenmeeting 13. Mai 2011 Vertrags- und Lizenzfragen im Rahmen des Cloud Computing LES Arbeitsgruppenmeeting 13. Mai 2011 Heymann & Partners Übersicht Erscheinungsformen des Cloud Computing Vertragsgestaltung beim Cloud Computing

Mehr

Sind Cloud Apps der nächste Hype?

Sind Cloud Apps der nächste Hype? Java Forum Stuttgart 2012 Sind Cloud Apps der nächste Hype? Tillmann Schall Stuttgart, 5. Juli 2012 : Agenda Was sind Cloud Apps? Einordnung / Vergleich mit bestehenden Cloud Konzepten Live Demo Aufbau

Mehr

Magento goes into the cloud Cloud Computing für Magento. Referent: Boris Lokschin, CEO

Magento goes into the cloud Cloud Computing für Magento. Referent: Boris Lokschin, CEO Magento goes into the cloud Cloud Computing für Magento Referent: Boris Lokschin, CEO Agenda Über symmetrics Unsere Schwerpunkte Cloud Computing Hype oder Realität? Warum Cloud Computing? Warum Cloud für

Mehr

Secure Cloud - "In-the-Cloud-Sicherheit"

Secure Cloud - In-the-Cloud-Sicherheit Secure Cloud - "In-the-Cloud-Sicherheit" Christian Klein Senior Sales Engineer Trend Micro Deutschland GmbH Copyright 2009 Trend Micro Inc. Virtualisierung nimmt zu 16.000.000 14.000.000 Absatz virtualisierter

Mehr

Cloud Computing. ITA Tech Talk, Oberursel, 28.09.2010. Nicholas Dille IT-Architekt, sepago GmbH

Cloud Computing. ITA Tech Talk, Oberursel, 28.09.2010. Nicholas Dille IT-Architekt, sepago GmbH Cloud Computing ITA Tech Talk, Oberursel, 28.09.2010 Nicholas Dille IT-Architekt, sepago GmbH Wer ist Nicholas Dille? IT-Architekt bei der sepago Strategieberatung Technische Konzeption Kernkompetenzen

Mehr

Grenzen und Möglichkeiten. Senatsverwaltung für Inneres und Sport Verfassungsschutz Bereich: Wirtschaftsschutz René K.

Grenzen und Möglichkeiten. Senatsverwaltung für Inneres und Sport Verfassungsschutz Bereich: Wirtschaftsschutz René K. Grenzen und Möglichkeiten Senatsverwaltung für Inneres und Sport Verfassungsschutz Bereich: Wirtschaftsschutz René K. 1 Agenda Definition Architektur Durchgängigkeit der Technologien Risiken Pro Contra

Mehr

Cloud Computing. D o m i n i c R e u t e r 19.07.2011. Softwarearchitekturen

Cloud Computing. D o m i n i c R e u t e r 19.07.2011. Softwarearchitekturen Cloud Computing D o m i n i c R e u t e r 19.07.2011 1 Seminar: Dozent: Softwarearchitekturen Benedikt Meurer GLIEDERUNG Grundlagen Servervirtualisierung Netzwerkvirtualisierung Storagevirtualisierung

Mehr

Anforderungen an Cloud- Rechenzentren

Anforderungen an Cloud- Rechenzentren Anforderungen an Cloud- Rechenzentren Student der Wirtscha3sinforma6k an der Universität zu Köln 1 Vorstellung Oktober 2009 bis September 2012 Bachelorstudium der Wirtscha3sinforma6k an der Wirtscha3s-

Mehr

Azure und die Cloud. Proseminar Objektorientiertes Programmieren mit.net und C# Simon Pigat. Institut für Informatik Software & Systems Engineering

Azure und die Cloud. Proseminar Objektorientiertes Programmieren mit.net und C# Simon Pigat. Institut für Informatik Software & Systems Engineering Azure und die Cloud Proseminar Objektorientiertes Programmieren mit.net und C# Simon Pigat Institut für Informatik Software & Systems Engineering Agenda Was heißt Cloud? IaaS? PaaS? SaaS? Woraus besteht

Mehr

MailStore Service Provider Edition (SPE)

MailStore Service Provider Edition (SPE) MailStore Solutions MailStore Service Provider Edition (SPE) E-Mail-Archivierung für Service Provider Mit Hilfe der MailStore Service Provider Edition können Sie Ihren Kunden moderne E-Mail-Archivierung

Mehr

Eine Taxonomie und Bewertung von Cloud Computing Diensten aus Entwicklersicht

Eine Taxonomie und Bewertung von Cloud Computing Diensten aus Entwicklersicht Eine Taxonomie und Bewertung von Cloud Computing Diensten aus Entwicklersicht Universität der Bundeswehr München Mario Golling und Michael Kretzschmar Fakultät für Informatik E-Mail: mario.golling@unibw.de

Mehr

Die Microsoft Cloud OS-Vision

Die Microsoft Cloud OS-Vision Die Microsoft Cloud OS-Vision 29-01-2014, itnetx/marcel Zehner Seit Oktober 2013 steht Microsoft mit dem neuen Betriebssystem Microsoft Windows Server 2012 R2 am Start. Aus Sicht von vielen Unternehmen

Mehr

Open Source als de-facto Standard bei Swisscom Cloud Services

Open Source als de-facto Standard bei Swisscom Cloud Services Open Source als de-facto Standard bei Swisscom Cloud Services Dr. Marcus Brunner Head of Standardization Strategy and Innovation Swisscom marcus.brunner@swisscom.com Viele Clouds, viele Trends, viele Technologien

Mehr

Der Cloud-Dienst Windows Azure

Der Cloud-Dienst Windows Azure Der Cloud-Dienst Windows Azure Master-Seminar Cloud Computing Wintersemester 2013/2014 Sven Friedrichs 07.02.2014 Sven Friedrichs Der Cloud-Dienst Windows Azure 2 Gliederung Einleitung Aufbau und Angebot

Mehr

Prototypvortrag. Exploiting Cloud and Infrastructure as a Service (IaaS) Solutions for Online Game Service Provisioning. Projektseminar WS 2009/10

Prototypvortrag. Exploiting Cloud and Infrastructure as a Service (IaaS) Solutions for Online Game Service Provisioning. Projektseminar WS 2009/10 Prototypvortrag Exploiting Cloud and Infrastructure as a Service (IaaS) Solutions for Online Game Service Provisioning Projektseminar WS 2009/10 Eugen Fot, Sebastian Kenter, Michael Surmann AG Parallele

Mehr

Was ist die Cloud? CCW interner Vortrag für Themenabend Erstellt: Mai 2012, Heiko Ehmsen Dauer: ca. 30 Minuten. Inhalt

Was ist die Cloud? CCW interner Vortrag für Themenabend Erstellt: Mai 2012, Heiko Ehmsen Dauer: ca. 30 Minuten. Inhalt Was ist die Cloud? CCW interner Vortrag für Themenabend Erstellt: Mai 2012, Heiko Ehmsen Dauer: ca. 30 Minuten Inhalt 1. Einführung Geschichte 2. Grundidee der Cloud-Technik (Virtualisierung, Skalierbarkeit,

Mehr

Aufbau von Cloud-Infrastrukturen mit Eucalyptus

Aufbau von Cloud-Infrastrukturen mit Eucalyptus Michael Stapelberg Cloud-Computing Seminar Universität Heidelberg SS2009 1/34 Aufbau von Cloud-Infrastrukturen mit Eucalyptus Michael Stapelberg Universität Heidelberg Stapelberg@stud.uni-heidelberg.de

Mehr

Cloud Computing Services. oder: Internet der der Dienste. Prof. Dr. Martin Michelson

Cloud Computing Services. oder: Internet der der Dienste. Prof. Dr. Martin Michelson Cloud Computing Services oder: Internet der der Dienste Prof. Dr. Martin Michelson Cloud Cloud Computing: Definitionen Cloud Computing ist eine Form der bedarfsgerechten und flexiblen Nutzung von IT-Dienstleistungen.

Mehr

Aufbau eigener Cloud-Infrastrukturen mit Eucalyptus Hochschule Mannheim

Aufbau eigener Cloud-Infrastrukturen mit Eucalyptus Hochschule Mannheim Andreas Ries Cloud-Computing Seminar Hochschule Mannheim WS0910 1/26 Aufbau eigener Cloud-Infrastrukturen mit Eucalyptus Hochschule Mannheim Andreas Ries Fakultät für Informatik Hochschule Mannheim ries.andreas@web.de

Mehr

synergetic AG Open House 2012 Ihr Unternehmen in der Wolke - Cloud Lösungen von synergetic

synergetic AG Open House 2012 Ihr Unternehmen in der Wolke - Cloud Lösungen von synergetic synergetic AG Open House 2012 Ihr Unternehmen in der Wolke - Cloud Lösungen von synergetic Markus Krämer Vorsitzender des Vorstandes der synergetic AG Verantwortlich für Strategie und Finanzen der synergetic

Mehr

RAC auf Sun Cluster 3.0

RAC auf Sun Cluster 3.0 RAC auf Sun Cluster 3.0 Schlüsselworte RAC, OPS, Sun Cluster, Performance, Availability Zusammenfassung Oracle hat mit dem Real Application Cluster (RAC) aus einer Hochverfügbarkeitslösung eine Höchstverfügbarkeitslösung

Mehr

Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim

Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim Sven Hartlieb Cloud-Computing Seminar Hochschule Mannheim WS0910 1/23 Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim Sven Hartlieb Fakultät für Informatik Hochschule

Mehr

Hochverfügbar, skalierbar und sicher in. der Public Cloud

Hochverfügbar, skalierbar und sicher in. der Public Cloud Hochverfügbar, skalierbar und sicher in der Public Cloud Thomas Bachmann CIO @ Mambu GmbH Twitter: @thobach Anwendungsbeispiel Core Banking System Verwaltung von Kunden, Konten, Transaktionen Buchhaltung,

Mehr

RECHTLICHE ASPEKTE BEIM CLOUD COMPUTING Technik-Evolution bringt Business-Revolution

RECHTLICHE ASPEKTE BEIM CLOUD COMPUTING Technik-Evolution bringt Business-Revolution RECHTLICHE ASPEKTE BEIM CLOUD COMPUTING Technik-Evolution bringt Business-Revolution Dr. Johannes Juranek, Partner bei CMS Reich-Rohrwig Hainz Rechtsanwälte GmbH Ebendorferstraße 3, 1010 Wien WS 2011 1.

Mehr

Architekturen mobiler Multi Plattform Apps

Architekturen mobiler Multi Plattform Apps Architekturen mobiler Multi Plattform Apps Wolfgang Maison & Felix Willnecker 06. Dezember 2011 1 Warum Multi- Plattform- Architekturen? Markt. Apps für Smartphones gehören zum Standardinventar jeder guten

Mehr

Migration einer bestehenden Umgebung in eine private Cloud mit OpenStack

Migration einer bestehenden Umgebung in eine private Cloud mit OpenStack Migration einer bestehenden Umgebung in eine private Cloud mit OpenStack CeBIT 2014 14. März 2014 André Nähring Cloud Computing Solution Architect naehring@b1-systems.de - Linux/Open Source Consulting,

Mehr

dynamic cloud @ internet4you Christoph Streit Technology Evangelist, internet4you 30. Oktober 2012

dynamic cloud @ internet4you Christoph Streit Technology Evangelist, internet4you 30. Oktober 2012 dynamic cloud @ internet4you Christoph Streit Technology Evangelist, internet4you 30. Oktober 2012 vorstellung Christoph Streit Über 15 Jahre Erfahrung in der IT Branche Co-Founder und früherer CTO der

Mehr

Datenschutzgerechtes CloudComputing -Risiken und Empfehlungen -

Datenschutzgerechtes CloudComputing -Risiken und Empfehlungen - Datenschutzgerechtes CloudComputing -Risiken und Empfehlungen - Dr. Thomas Reinke Die Landesbeauftragte für den Datenschutz und für das Recht auf Akteneinsicht Brandenburg (Bereich Technik und Organisation)

Mehr

Mythen des Cloud Computing

Mythen des Cloud Computing Mythen des Cloud Computing Prof. Dr. Peter Buxmann Fachgebiet Wirtschaftsinformatik Software Business & Information Management Technische Universität Darmstadt 12.09.2012 IT-Business meets Science Prof.

Mehr

Die wichtigsten Funktionen von Red Hat Storage Server 2.0 im Überblick:

Die wichtigsten Funktionen von Red Hat Storage Server 2.0 im Überblick: Red Hat Storage Server Die wichtigsten Funktionen von Red Hat Storage Server 2.0 im Überblick: Offene Software Lösung für Storage Ansprache über einen globalen Namensraum Betrachtet Storage als einen virtualisierten

Mehr

Peter Garlock Manager Cloud Computing Austria. Cloud Computing. Heiter statt wolkig. 2011 IBM Corporation

Peter Garlock Manager Cloud Computing Austria. Cloud Computing. Heiter statt wolkig. 2011 IBM Corporation Peter Garlock Manager Cloud Computing Austria Cloud Computing Heiter statt wolkig 1 Was passiert in Europa in 2011? Eine Markteinschätzung Quelle: IDC European Cloud Top 10 predictions, January 2011 2

Mehr

GIS in der Cloud: Beispiele von ESRI und con terra

GIS in der Cloud: Beispiele von ESRI und con terra GIS in der Cloud: Beispiele von ESRI und con terra Dr. Matthias Bluhm ESRI Deutschland GmbH 9. März 2011, Darmstadt 2 ESRI Deutschland GmbH, 2011 GmbH 2010 ESRI Unternehmensgruppe (in Deutschland und der

Mehr

Windows Azure Ihre Plattform für professionelles Cloud Computing

Windows Azure Ihre Plattform für professionelles Cloud Computing Windows Azure Ihre Plattform für professionelles Cloud Computing Eine Plattform für Hochverfügbarkeit und maximale Flexibilität und ein Partner, der diese Möglichkeiten für Sie ausschöpft! Microsoft bietet

Mehr

GoGrid Hochschule Mannheim

GoGrid Hochschule Mannheim Christoph Eikermann GoGrid Hochschule Mannheim WS0910 1/25 GoGrid Hochschule Mannheim Christoph Eikermann Fakultät für Informatik Hochschule Mannheim c.eikermann@googlemail.com 11.12.2009 Christoph Eikermann

Mehr

Die Spezialisten für innovative Lösungen im Bereich Document Output Management

Die Spezialisten für innovative Lösungen im Bereich Document Output Management Die Spezialisten für innovative Lösungen im Bereich Document Output Management Agenda Wer ist Rasterpunkt Einführung Software as a Service Hat SaaS Marktpotential? SaaS im Document Output Management: Konvertierung

Mehr

Cloud Computing: Hype oder Chance auch. für den Mittelstand?

Cloud Computing: Hype oder Chance auch. für den Mittelstand? Prof. Dr.-Ing. Rainer Schmidt HTW Aalen Wirtschaftsinformatik Überblick Was ist Cloud-Computing und wieso ist es für Unternehmen wichtig? Wie können Unternehmen mit Hilfe einer Cloud- Computing-Strategie

Mehr

Cloud Computing Chancen für KMU

Cloud Computing Chancen für KMU Cloud Computing Chancen für KMU Sascha A. Peters Cluster Manager IT FOR WORK 31. Oktober 2012 Cloud Computing Worüber reden alle? Fragen zum Thema Cloud Was ist Cloud Computing und wofür wird es genutzt?

Mehr

Cloud Computing. Chancen und Risiken aus technischer und unternehmerischer Sicht. von Christian Metzger, Thorsten Reitz, Juan Villar. 1.

Cloud Computing. Chancen und Risiken aus technischer und unternehmerischer Sicht. von Christian Metzger, Thorsten Reitz, Juan Villar. 1. Cloud Computing Chancen und Risiken aus technischer und unternehmerischer Sicht von Christian Metzger, Thorsten Reitz, Juan Villar 1. Auflage Hanser München 2011 Verlag C.H. Beck im Internet: www.beck.de

Mehr

Die EBCONT Unternehmensgruppe.

Die EBCONT Unternehmensgruppe. 1200 Wien, Handelskai 94-96 Johannes Litschauer, Alex Deles IT-Infrastruktur IT-Betrieb (managed Services) Cloud / Elastizität 1200 Wien, Handelskai 94-96 Johannes Litschauer, Alex Deles Enterprise Solutions

Mehr

Managed VPSv3 Was ist neu?

Managed VPSv3 Was ist neu? Managed VPSv3 Was ist neu? Copyright 2006 VERIO Europe Seite 1 1 EINFÜHRUNG 3 1.1 Inhalt 3 2 WAS IST NEU? 4 2.1 Speicherplatz 4 2.2 Betriebssystem 4 2.3 Dateisystem 4 2.4 Wichtige Services 5 2.5 Programme

Mehr

Die Cloud, die alles anders macht. Die 6 Grundzüge der Swisscom Cloud

Die Cloud, die alles anders macht. Die 6 Grundzüge der Swisscom Cloud Die Cloud, die alles anders macht. Die 6 Grundzüge der Swisscom Cloud Viele Clouds, viele Trends, viele Technologien Kommunikation Private Apps Prozesse Austausch Speicher Big Data Business Virtual Datacenter

Mehr

CC: Herausforderungen Konsequenzen & Aufgaben

CC: Herausforderungen Konsequenzen & Aufgaben KOGIS CC: Herausforderungen Konsequenzen & Aufgaben Aus 5 Jahren Erfahrung geo.admin.ch SATW 10.9.2014 Hanspeter Christ & David Oesch KOGIS CC: Herausforderungen Konsequenzen & Aufgaben Aus 5 Jahren Erfahrung

Mehr

Content Management Systeme

Content Management Systeme Content Management Systeme Ein Vergleich unter besonderer Berücksichtigung von CoreMedia und TYPO3 Bachelorthesis im Kooperativen Bachelor Studiengang Informatik (KoSI) der Fachhochschule Darmstadt University

Mehr

Handbuch für Android 1.5

Handbuch für Android 1.5 Handbuch für Android 1.5 1 Inhaltsverzeichnis 1 Leistungsumfang... 3 1.1 Über Boxcryptor Classic... 3 1.2 Über dieses Handbuch... 3 2. Installation... 5 3. Grundfunktionen... 5 3.1 Einrichtung von Boxcryptor

Mehr

Flug in die Wolke. Instrumentenflug in die Cloud mit Unic. Wallisellen, 25. Januar 2012. Christoph Camenisch

Flug in die Wolke. Instrumentenflug in die Cloud mit Unic. Wallisellen, 25. Januar 2012. Christoph Camenisch Flug in die Wolke Instrumentenflug in die Cloud mit Unic Wallisellen, 25. Januar 2012 Christoph Camenisch Flug in die Wolke Hosting by Unic Unic - Seite 2 Flug in die Wolke Cloud Computing in a nutshell

Mehr

Public und Private Cloud-Dienste mit KOALA komfortabel steuern

Public und Private Cloud-Dienste mit KOALA komfortabel steuern Public und Private Cloud-Dienste mit KOALA komfortabel steuern ix CeBIT Forum 2011 Christian Baun, Marcel Kunze 4. März 2011 STEINBUCH CENTRE FOR COMPUTING (SCC) KIT Universität des Landes Baden-Württemberg

Mehr

Cloud Computing mit mathematischen Anwendungen

Cloud Computing mit mathematischen Anwendungen Cloud Computing mit mathematischen Anwendungen Vorlesung SoSe 2009 Dr. Marcel Kunze Karlsruhe Institute of Technology (KIT) Steinbuch Centre for Computing (SCC) KIT the cooperation of Forschungszentrum

Mehr

Linux Server in der eigenen Cloud

Linux Server in der eigenen Cloud SÜD IT AG World of IT Linux Server in der eigenen Cloud Infrastructure as a Service (IaaS) Michael Hojnacki, ProtoSoft AG Quellen: SUSE Cloud 4 Präsentation (Thore Bahr) Diverse Veröffentlichungen Stahlgruberring

Mehr

Platform as a Service (PaaS) 15.01.2010 Prof. Dr. Ch. Reich

Platform as a Service (PaaS) 15.01.2010 Prof. Dr. Ch. Reich Platform as a Service (PaaS) 15.01.2010 Prof. Dr. Ch. Reich Cloud Computing Deployment Typen: Private cloud Besitzt das Unternehmen Community cloud Gemeinsame Nutzung durch Gemeinschaft Public cloud Öffentliche

Mehr

Cloud-Provider im Vergleich. Markus Knittig @mknittig

Cloud-Provider im Vergleich. Markus Knittig @mknittig Cloud-Provider im Vergleich Markus Knittig @mknittig As Amazon accumulated more and more services, the productivity levels in producing innovation and value were dropping primarily because the engineers

Mehr

AJAX SSL- Wizard Referenz

AJAX SSL- Wizard Referenz AJAX SSL- Wizard Referenz Version 1.0.2+ - 04.04.2011 Präambel Die vorliegende Dokumentation beschreibt den AJAX basierten SSL- Wizard der CertCenter AG. Der SSL- Wizard kann mit wenigen Handgriffen nahtlos

Mehr

Christian Metzger Thorsten Reitz Juan Villar. Cloud Computing. Chancen und Risiken aus technischer und unternehmerischer Sicht HANSER

Christian Metzger Thorsten Reitz Juan Villar. Cloud Computing. Chancen und Risiken aus technischer und unternehmerischer Sicht HANSER Christian Metzger Thorsten Reitz Juan Villar Cloud Computing Chancen und Risiken aus technischer und unternehmerischer Sicht HANSER Inhalt Vorwort, XI 1 Ist die Zukunft schon da? 1 1.1 Allgemeine Definition

Mehr

MICROSOFTS CLOUD STRATEGIE

MICROSOFTS CLOUD STRATEGIE MICROSOFTS CLOUD STRATEGIE Sebastian Weber Head of Technical Evangelism Developer Platform & Strategy Group Microsoft Deutschland GmbH Slide 1 WAS IST CLOUD COMPUTING? Art der Bereitstellung von IT-Leistung

Mehr

JEAF Cloud Plattform Der Workspace aus der Cloud

JEAF Cloud Plattform Der Workspace aus der Cloud JEAF Cloud Plattform Der Workspace aus der Cloud Juni 2014 : Aktuelle Situation Heutige Insellösungen bringen dem Nutzer keinen Mehrwert Nutzer sind mobil Dateien und Applikationen sind über Anbieter und

Mehr

Technologiepolitische Aktionslinie des BMWi zum Internet der Dienste

Technologiepolitische Aktionslinie des BMWi zum Internet der Dienste Innovationspolitik, Informationsgesellschaft, Telekommunikation Technologiepolitische Aktionslinie des BMWi zum Internet der Dienste Dr. Andreas Goerdeler, Referatsleiter Entwicklung konvergenter IKT www.bmwi.de

Mehr

Eine App, viele Plattformen

Eine App, viele Plattformen Eine App, viele Plattformen Anwendungsentwicklung für Mobile Heiko Lewandowski 23.04.2013 EINLEITUNG Festlegung App-Strategie: Welche Ziele möchte ich erreichen? Die Vielzahl der Plattformen und Geräte(hersteller)

Mehr

Smartphone Entwicklung mit Android und Java

Smartphone Entwicklung mit Android und Java Smartphone Entwicklung mit Android und Java predic8 GmbH Moltkestr. 40 53173 Bonn Tel: (0228)5552576-0 www.predic8.de info@predic8.de Was ist Android Offene Plattform für mobile Geräte Software Kompletter

Mehr

Clouds. Erwartungen der Nutzer. Wolkig bis Heiter. (c) 2013, Peter Sturm, Universität Trier. Er ist verwöhnt! Er ist nicht dankbar!

Clouds. Erwartungen der Nutzer. Wolkig bis Heiter. (c) 2013, Peter Sturm, Universität Trier. Er ist verwöhnt! Er ist nicht dankbar! Clouds Wolkig bis Heiter Erwartungen der Nutzer Er ist verwöhnt! Verfügbarkeit Viele Anwendungen Intuitive Interfaces Hohe Leistung Er ist nicht dankbar! Mehr! Mehr! Mehr! Moore 1 Erwartungen der Entwickler

Mehr

Cloud Computing mit OpenStack

Cloud Computing mit OpenStack Cloud Computing mit OpenStack B1 Systems GmbH http://www.b1-systems.de Cloud Computing Cloud Computing Servicemodelle Software as a Service (SaaS) Platform as a Service (PaaS) Infrastructure as a Service

Mehr

Cloud! dotnet Usergroup Berlin. Sein oder nicht sein!?! Robert Eichenseer robert.eichenseer@conplement.de

Cloud! dotnet Usergroup Berlin. Sein oder nicht sein!?! Robert Eichenseer robert.eichenseer@conplement.de dotnet Usergroup Berlin Cloud! Sein oder nicht sein!?! Robert Eichenseer robert.eichenseer@conplement.de conplement AG Südwestpark 92 90449 Nürnberg http://www.conplement.de/roberteichenseer.html 1 conplement

Mehr

Beim Kunden wahrgenommene Qualität von IT-Services Ein wichtiger Faktor in der Beschaffung von Cloud Services

Beim Kunden wahrgenommene Qualität von IT-Services Ein wichtiger Faktor in der Beschaffung von Cloud Services Beim Kunden wahrgenommene Qualität von IT-Services Ein wichtiger Faktor in der Beschaffung von Cloud Services BICCnet Arbeitskreistreffen "IT-Services" am 14. November bei fortiss Jan Wollersheim fortiss

Mehr

There the client goes

There the client goes There the client goes Fritz Fritz Woodtli Woodtli BCD-SINTRAG AG 8301 8301 Glattzentrum Glattzentrum Sofort verfügbar Überall erreichbar Intelligent verwaltet Sicher Günstige Kosten Citrix Access Infrastructure

Mehr

Sicherheitsanalyse von Private Clouds

Sicherheitsanalyse von Private Clouds Sicherheitsanalyse von Private Clouds Alex Didier Essoh und Dr. Clemens Doubrava Bundesamt für Sicherheit in der Informationstechnik 12. Deutscher IT-Sicherheitskongress 2011 Bonn, 10.05.2011 Agenda Einleitung

Mehr

MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP)

MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP) MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP) Oliver Steinhauer Markus Urban.mobile PROFI Mobile Business Agenda MOBILE ENTERPRISE APPLICATION PLATFORM AGENDA 01 Mobile Enterprise Application Platform

Mehr

Cross-Platform Apps mit HTML5/JS/CSS/PhoneGap

Cross-Platform Apps mit HTML5/JS/CSS/PhoneGap Cross-Platform Apps mit HTML5/JS/CSS/PhoneGap Proseminar Objektorientiertes Programmieren mit.net und C# Florian Schulz Institut für Informatik Software & Systems Engineering Einführung Was hat Cross-Plattform

Mehr

Bin ich fit für myconvento?

Bin ich fit für myconvento? Bin ich fit für myconvento? Sie planen den Einsatz unserer innovativen Kommunikationslösung myconvento und fragen sich gerade, ob Ihr Rechner die Anforderungen erfüllt? Hier erfahren Sie mehr. Inhalt Was

Mehr

Was ist Windows Azure? (Stand Juni 2012)

Was ist Windows Azure? (Stand Juni 2012) Was ist Windows Azure? (Stand Juni 2012) Windows Azure Microsofts Cloud Plattform zu Erstellung, Betrieb und Skalierung eigener Cloud-basierter Anwendungen Cloud Services Laufzeitumgebung, Speicher, Datenbank,

Mehr

App Entwicklung mit Hilfe von Phonegap. Web Advanced II - SS 2012 Jennifer Beckmann

App Entwicklung mit Hilfe von Phonegap. Web Advanced II - SS 2012 Jennifer Beckmann App Entwicklung mit Hilfe von Phonegap Web Advanced II - SS 2012 Jennifer Beckmann http://www.focus.de/digital/internet/netzoekonomie-blog/smartphone-googles-android-laeuft-konkurrenz-in-deutschland-davon_aid_723544.html

Mehr

MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP)

MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP) MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP) Oliver Steinhauer.mobile PROFI Mobile Business Agenda MOBILE ENTERPRISE APPLICATION PLATFORM AGENDA 01 Mobile Enterprise Application Platform 02 PROFI News

Mehr

Klein Computer System AG. Portrait

Klein Computer System AG. Portrait Klein Computer System AG Portrait Die Klein Computer System AG wurde 1986 durch Wolfgang Klein mit Sitz in Dübendorf gegründet. Die Geschäftstätigkeiten haben sich über die Jahre stark verändert und wurden

Mehr

Kurzanleitung - XVA Provider unter Mac OSX 10

Kurzanleitung - XVA Provider unter Mac OSX 10 Kurzanleitung - XVA Provider unter Mac OSX 10 Installation und Bedienung- Inhalt Allgemeine Hinweise:... 1 Kapitel 1 Installation und Konfiguration... 2 Schritt 1: Java SE Development Kit 6 installieren:...

Mehr

Anforderungen an Cloud Computing-Modelle

Anforderungen an Cloud Computing-Modelle Anforderungen an Cloud Computing-Modelle Rechtsanwalt Martin Kuhr, LL.M. 26.11.2010 6. Darmstädter Informationsrechtstag oder: zwischen Wolkenhimmel und Haftungshölle F.A.Z. Wer steht vor Ihnen? - Rechtsanwalt

Mehr

Cloud Computing mit der Windows Azure Platform

Cloud Computing mit der Windows Azure Platform Cloud Computing mit der Windows Azure Platform Ein Überblick Holger Sirtl Architect Developer Platform & Strategy Group Microsoft Deutschland GmbH http://blogs.msdn.com/hsirtl Wahlfreiheit bei Anwendungen

Mehr

Cloud-Computing - Überblick

Cloud-Computing - Überblick Cloud-Computing - Überblick alois.schuette@h-da.de Alois Schütte 24. November 2014 1 / 20 Inhaltsverzeichnis 1 Was ist Cloud-Computing Warum beschäftigt man sich mit Cloud Computing? 2 Aufbau der Veranstaltung

Mehr

Session Storage im Zend Server Cluster Manager

Session Storage im Zend Server Cluster Manager Session Storage im Zend Server Cluster Manager Jan Burkl System Engineer, Zend Technologies Agenda Einführung in Zend Server und ZSCM Überblick über PHP Sessions Zend Session Clustering Session Hochverfügbarkeit

Mehr

Sind Privacy und Compliance im Cloud Computing möglich?

Sind Privacy und Compliance im Cloud Computing möglich? Sind und Compliance im Cloud Computing möglich? Ina Schiering Ostfalia Hochschule für angewandte Wissenschaften Markus Hansen Unabhängiges Landeszentrum für Datenschutz www.ostfalie.de Wolfenbüttel, Germany

Mehr

Automatisierte Akzeptanztests für ios-apps. Sven Günther it-agile GmbH

Automatisierte Akzeptanztests für ios-apps. Sven Günther it-agile GmbH Automatisierte Akzeptanztests für ios-apps Sven Günther it-agile GmbH Wer entwickelt native Apps? Wer testet die Apps selbst? Wer hat externe Testdienstleister? Wer hat Unit-Tests? Wer hat Akzeptanztests?

Mehr

IT-Security on Cloud Computing

IT-Security on Cloud Computing Abbildung 1: IT-Sicherheit des Cloud Computing Name, Vorname: Ebert, Philipp Geb.: 23.06.1993 Studiengang: Angewandte Informatik, 3. FS Beruf: IT-Systemelektroniker Abgabedatum: 08.12.2014 Kurzfassung

Mehr

Information Systems & Semantic Web University of Koblenz Landau, Germany. Cloud Computing. Steffen Staab

<is web> Information Systems & Semantic Web University of Koblenz Landau, Germany. Cloud Computing. Steffen Staab Information Systems & Semantic Web University of Koblenz Landau, Germany Cloud Computing Cloud Computing if you do not have Cloud Computing in your business proposal you do not get VC funding. P. Miraglia@Austin,

Mehr

VIEWER EVOLUTION VOM APPLET ZUM JADICE WEB TOOLKIT: KUNDENBEISPIEL LEVIGO SOLUTIONS DAY 24.10.2013, 11:15 11:45 F. STEHLING CENIT ECM

VIEWER EVOLUTION VOM APPLET ZUM JADICE WEB TOOLKIT: KUNDENBEISPIEL LEVIGO SOLUTIONS DAY 24.10.2013, 11:15 11:45 F. STEHLING CENIT ECM VIEWER EVOLUTION VOM APPLET ZUM JADICE WEB TOOLKIT: KUNDENBEISPIEL LEVIGO SOLUTIONS DAY 24.10.2013, 11:15 11:45 F. STEHLING CENIT ECM VIEWER EVOLUTION 2 PROJEKTABLAUF Technische Evaluierung Gründe für

Mehr

Microsoft Azure: Ein Überblick für Entwickler. Malte Lantin Technical Evangelist, Developer Experience & Evangelism (DX) Microsoft Deutschland GmbH

Microsoft Azure: Ein Überblick für Entwickler. Malte Lantin Technical Evangelist, Developer Experience & Evangelism (DX) Microsoft Deutschland GmbH Microsoft Azure: Ein Überblick für Entwickler Malte Lantin Technical Evangelist, Developer Experience & Evangelism (DX) Microsoft Deutschland GmbH Moderne Softwareentwicklung Microsoft Azure unterstützt

Mehr

TELEKOM CLOUD COMPUTING. NEUE PERSPEKTIVEN. Dietrich Canel Telekom Deutschland GmbH 03/2013 1

TELEKOM CLOUD COMPUTING. NEUE PERSPEKTIVEN. Dietrich Canel Telekom Deutschland GmbH 03/2013 1 TELEKOM CLOUD COMPUTING. NEUE PERSPEKTIVEN. Dietrich Canel Telekom Deutschland GmbH 03/2013 1 DIE TELEKOM-STRATEGIE: TELCO PLUS. 2 AKTUELLE BEISPIELE FÜR CLOUD SERVICES. Benutzer Profile Musik, Fotos,

Mehr

Medienkompetenz, Grafik und DTP

Medienkompetenz, Grafik und DTP VO 340381 Informationsdesign; Medienkompetenz, Grafik und DTP Zentrum für Translationswissenschaft Letztes Mal sprachen wir über: Computer Aufbau Software Was ist Software? Software Soft im Sinne von weich/veränderbar

Mehr

Managed Cloud Services

Managed Cloud Services Managed Cloud Services Autor.: Monika Olschewski Whitepaper Version: 1.0 Erstellt am: 14.07.2010 ADACOR Hosting GmbH Kaiserleistrasse 51 63067 Offenbach am Main info@adacor.com www.adacor.com Cloud Services

Mehr

Unternehmen-IT sicher in der Public Cloud

Unternehmen-IT sicher in der Public Cloud Unternehmen-IT sicher in der Public Cloud Safely doing your private business in public David Treanor Team Lead Infrastructure Microsoft Certified Systems Engineer (MCSE) Microsoft Certified Systems Administrator

Mehr

Mobile Backend in der

Mobile Backend in der Mobile Backend in der Cloud Azure Mobile Services / Websites / Active Directory / Kontext Auth Back-Office Mobile Users Push Data Website DevOps Social Networks Logic Others TFS online Windows Azure Mobile

Mehr

Virtualisierung im Rechenzentrum

Virtualisierung im Rechenzentrum in wenigen Minuten geht es los Virtualisierung im Rechenzentrum Der erste Schritt auf dem Weg in die Cloud KEIN VOIP, nur Tel: 030 / 7261 76245 Sitzungsnr.: *6385* Virtualisierung im Rechenzentrum Der

Mehr

Hybride Cloud Datacenters

Hybride Cloud Datacenters Hybride Cloud Datacenters Enterprise und KMU Kunden Daniel Jossen Geschäftsführer (CEO) dipl. Ing. Informatik FH, MAS IT Network Amanox Solutions Unsere Vision Wir planen und implementieren für unsere

Mehr

Integration mobiler Endgeräte in Medizinprodukte und Medizintechnik-nahe Produkte

Integration mobiler Endgeräte in Medizinprodukte und Medizintechnik-nahe Produkte Integration mobiler Endgeräte in Medizinprodukte und Medizintechnik-nahe Produkte Agenda Problemstellung Medizinprodukt App Grundlagen Szenarien (Problemstellungen und Lösungsansätze) 03.06.2013 2 Innovationen

Mehr

Hardware- und Software-Anforderungen IBeeS.ERP

Hardware- und Software-Anforderungen IBeeS.ERP Hardware- und Software-Anforderungen IBeeS.ERP IBeeS GmbH Stand 08.2015 www.ibees.de Seite 1 von 8 Inhalt 1 Hardware-Anforderungen für eine IBeeS.ERP - Applikation... 3 1.1 Server... 3 1.1.1 Allgemeines

Mehr

Multi-Device Applikationen aus der Swisscom Cloud. Lukas Lehmann

Multi-Device Applikationen aus der Swisscom Cloud. Lukas Lehmann Multi-Device Applikationen aus der Swisscom Cloud Lukas Lehmann Agenda Welcome Swisscom Cloud -> PaaS Get ready for the Championship Use Cases Be a Champion Q&A Swiss made so beständig wie Swisscom selbst

Mehr

Dateisysteme und Datenverwaltung in der Cloud

Dateisysteme und Datenverwaltung in der Cloud Dateisysteme und Datenverwaltung in der Cloud Sebastian Fischer Master-Seminar Cloud Computing - WS 2013/14 Institut für Telematik, Universität zu Lübeck Dateisysteme und Datenverwaltung in der Cloud 1

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

Web-Performance-Optimierung - Websites auf Speed SEO Barbecue - DIWISH - Kiel - 01. August 2012. Timo Heinrich t.heinrich@online-werbung.

Web-Performance-Optimierung - Websites auf Speed SEO Barbecue - DIWISH - Kiel - 01. August 2012. Timo Heinrich t.heinrich@online-werbung. SEO Barbecue Web-Performance-Optimierung - DIWISH - Kiel - 01. August 2012 - Websites auf Speed 1 2 Kinder 1 Frau 41 Jahre jung Seit 1996 autodidaktischer Onliner Schwerpunkte: Suchmaschinenoptimierung

Mehr