2 Inhaltsverzeichnis

3 Abkürzungs-, Abbildungs- und Tabellenverzeichnis

3.1 Abbildungsverzeichnis

3.2 Tabellenverzeichnis

4 Hinführung zum Thema

Als Cloud Computing bezeichnet man die Möglichkeit IT-Ressourcen (Speicherkapazitäten, Rechenleistung, Software) über das Internet zu mieten. Der Anwender ist also nicht mehr gezwungen eine eigene IT-Infrastruktur zu betreiben und bereitzustellen. Gegenüber konventionellen Systemen bietet Cloud Computing erhebliche Kostenvorteile, da nur die tatsächlich in Anspruch genommenen Ressourcen bezahlt werden müssen (pay-as-you-go). E-Commerce Webseiten können somit unvorhergesehende oder schwer kalkulierbare Nachfragespitzen bewältigen.

Bei einer geschlossenen Shopping-Community (Shopping-Club) werden Artikel in bewusst kurz gehaltenen Zeiträumen an einen geschlossenen Nutzerkreis verkauft. In der Regel finden 3 bis 5 solcher Aktionen pro Woche statt. Die Nutzer werden mit Hilfe eines Newsletter über entsprechende Aktionen informiert. Damit alle potentiellen Käufer die gleichen Chancen haben, den beworbenen Artikel zu erstehen, wird die jeweilige Newsletter in einem sehr kurzen Zeitraum an alle registrierten Benutzer verschickt. Dadurch tritt eine konzentrierte Belastung der Web Server auf. Die Zugriffszahlen sind in den ersten 3 bis 5 Stunden nach Versand des Newsletter um den Faktor 6-10 höher, als die Grundlast.

Es stellt sich daher die Frage, inwiefern Cloud Computing geeignet ist, die eigene Infrastruktur so zu ergänzen, dass Lastspitzen dynamisch und flexibel bedient werden können. Dabei soll auch betrachtet werden, ob und inwiefern sich diese Lösung wirtschaftlich gegenüber dem klassischen Hosting rechnet.

5 Problemstellung

5.1 Analyse des Unternehmens

Beim dem betrachteten Unternehmen handelt es sich um eine geschlossene Shopping-Community. ^[1] Das Geschäftsmodell bietet Herstellern einen zusätzlichen Vertriebskanal um Überkapazitäten am Ende der Saison abzubauen ohne die Exklusivität der Marke zu verwässern. Dabei werden die Waren durch die Shopping-Communities in zeitlich begrenzten Aktionen Ihren Mitgliedern angeboten. Um die Mitglieder über aktuelle Aktionen zu benachrichtigen, erhalten diese regelmäßig Newsletter bzw. Benachrichtigungsemails. Im betrachteten Unternehmen werden diese Benachrichtigungen drei mal wöchentlich an alle Mitglieder versendet.

Um Enttäuschung bei den Kunden zu vermeiden, weil ein Produkt bereits beim Besuch des Shops ausverkauft ist, sieht das Konzept vor, die Benachrichtigungsemails in einem kurzen Zeitraum an alle Mitglieder zu versenden. Dieses Vorgehen erzeugt einen starken Anstieg der Serverlast innerhalb eines kurzen Zeitraums.

Im konkreten Fall werden die Benachrichtigungen Montag, Mittwoch und Freitag jeweils um neun Uhr am Morgen versendet. Innerhalb weniger Minuten steigt die Serverlast ca. um das sechsfache bis achtfache an. Nach ca. 4 Stunden ist die Last wieder auf das dreifache der Normallast gesunken und verringert sich dann kontinuierlich bis zum Ende des Tages.

5.2 Anforderungen des Unternehmens

5.2.1 Aktuelle Infrastruktur

Zum aktuellen Zeitpunkt mietet das Unternehmen zwei Server (nachfolgend als „xen01“ und „xen02“ bezeichnet) auf Monatsbasis an. Um Sicherheit und Flexibilität zu gewährleisten, werden alle Dienste getrennt betrieben und virtualisiert. Auf dem physischen Server befindet sich nur eine Gentoo Linux Installation die den Xen Hypervisor ^[2] zur Verfügung stellt. Jeweils eine virtuelle Maschine (Xen Domain Guest) stellt einen MySQL Server (nachfolgende „live-db“), einen Apache Webserver mit der eCommerce-Software (nachfolgend „live-magento“) und einen lighttpd Webserver (nachfolgend „static“), der nur statische Dateien an den Besucher ausliefert, zur Verfügung. Dabei benötigt der Apache Webserver mit der eCommerce-Software die meisten Ressourcen. In der nachfolgenden Tabelle ist die Ressourcenaufteilung noch einmal genauer dargestellt:

Tabelle 1: aktuelle Verteilung der physischen und virtuellen Maschinen

Von Varien, dem Entwickler der Magento eCommerce Software, wird ein Server mit 8 CPU Kernen und 16GB Arbeitsspeicher empfohlen. ^[3] In eigenen Tests hat sich herausgestellt, dass in Kombination mit Caching eine Konfiguration von 4 CPU Kernen und 16GB-24GB Arbeitsspeicher im vorliegenden Fall besser skaliert. Diese Konfiguration wird nachfolgend als Grundlage für die Planung der Infrastruktur und die Berechnung der Kosten dienen. Für die Anbindung des Servers sind 100Mbit/s ausreichend. Der Wartungsaufwand pro Frontend Server beträgt ca. zwei Stunden pro Monat, eine Stunde Wartung kostet 35€.

Abbildung 1: Aktueller Stand der Infrastruktur

Der monatliche Preis für einen Server beträgt 125€, darin enthalten sind fünf Terabyte Traffic, wovon ca. 100 Gigabyte benötigt werden. Zu Spitzenlastzeiten werden in einem Monat ca. 75 Gigabyte Traffic verbraucht, was ca. einem Gigabyte pro Stunde entspricht. Durch den Betreiber des Rechenzentrums wird ein 24/7 Support gewährleistet, es bestehen jedoch keine besonderen Vereinbarungen (Service Level Agreement) zu Reaktionszeiten und Fehlerbehebung.

Mit dieser Infrastruktur können aktuell noch alle Lastspitzen bedient werden. Bei weiterem Wachstum der Kundenbasis kann jedoch ein einzelner Server die Lastspitzen nicht mehr bedienen. Klassisch würden nun weitere Server angemietet und über Load-Balancing die Last auf diese verteilt.

5.2.2 Wachstumsanforderungen

Abbildung 2: Munin Graph - Apache Zugriffe pro Sekunde

Aus verschiedenen Lasttests bei der Erstkonfiguration der Plattform wurde der Wert von 16 Zugriffen pro Sekunde als Grenzwert für einen Magento Frontend Server ermittelt. Dabei wurden verschiedene Testszenarien erstellt und mittels Apache Bench ^[4] und Siege ^[5] getestet. Der Average-Case ^[6] wurde dabei auf Basis der Google Analytics Daten erstellt.

Tabelle 2: Testszenarien Lasttests

Zum aktuellen Zeitpunkt (Ende Juni 2011) finden im Grundlastbereich 2 Zugriffe pro Sekunde und im Spitzenlastbereich 12 Zugriffe pro Sekunde statt. Das entspricht einer Auslastung von 12% bzw. 75%. Auf Basis dieses Wachstums ergeben sich folgende Wachstumsanforderungen an die Infrastruktur innerhalb der nächsten 12 Monate:

Tabelle 3: Wachstumsprognose

Die Tabelle betrachtet die Serverauslastung zum Monatsende. Sobald die Grundlast 50% oder die Spitzenlast 90% übersteigen würde, wird ein weiterer Magento Frontend Server eingebunden. Somit ergibt sich Ende Juni 2012 eine Anzahl von 6 Magento Frontend Servern.

6 Konventionelles Hosting

6.1 Benötigte Infrastruktur

Abbildung 3: IT Infrastruktur Planung klassisch

Um dem Wachstum gerecht zu werden und einfach neue Server einbinden zu können, ist es notwendig die Infrastruktur umzugestalten. Dazu wird ein Load Balancer benötigt, der die Last dynamisch auf mehrere Systeme verteilen kann. Hinter dem Loadbalancer befinden sich die einzelnen Magento Frontend Server. Weiterhin werden ein MySQL Master Server, ein MySQL Slave Server, ein Shared Storage Server und ein CDN/Static Server in die Infrastruktur eingebunden. Ob die Magento Frontend Server klassische Server oder Cloud Instanzen sind, ist bei dieser Struktur unerheblich. Sowohl klassische Server also auch Cloud Instanzen können mit allen zur Verfügung gestellten Komponenten kommunizieren.

Ein Magento Frontend Server besteht aus einem Apache Webserver mit einer Magento eCommerce Installation. Der Datenbankzugriff erfolgt sowohl auf den MySQL Master Server als auch auf den MySQL Slave Server. Alle Schreiboperationen werden dabei auf dem MySQL Master Server ausgeführt, alle Leseverbindungen auf dem MySQL Slave Server. Die statischen Dateien wie JavaScript und CSS Dateien werden auf dem Shared Storage Server abgelegt und durch den CDN/Static Server von da abgerufen. Einige Bilder werden durch die eCommerce Software zur Laufzeit verkleinert und ebenfalls auf dem Shared Storage Server abgelegt.

6.1.1 Einbindung von Cloud Instanzen

Abbildung 4: IT Infrastruktur Planung klassisch + Cloud

Die Magento Frontend Server 2-x kann man nun durch konventionelle Hostingmethoden oder als Cloud Instanz bereitstellen. Ein Cloud Instanz muss ebenfalls 4 CPUs und 16GB - 24GB RAM bereitstellen. Weiterhin sollte es möglich sein, eine beliebige, frei konfigurierbare Linux Installation betrieben zu können. Die Linux Installation muss frei wählbar sein um den Administrationsaufwand möglichst gering zu halten, es kann die gleiche Installation wie beim konventionellen Hosting verwendet werden.

Durch die Einbindung der Cloud Instanzen, welche nur von 8 Uhr bis 14 Uhr gestartet werden, verändert sich die Grundlast der klassischen Server im Vergleich zum reinen klassischen Hosting.

Tabelle 4: Wachstumsprognose unter Berücksichtigung der Cloud Infrastruktur

6.2 Anforderungen an Cloud Instanzen

Eine Cloud Instanz soll einen Magento Frontend Server ersetzen, daher muss die Hardware die gleichen Anforderungen erfüllen. Eine Cloud Instanz benötigt 4 CPU Kerne und 16 GB – 24 GB Arbeitsspeicher. Weiterhin muss die Anbindung eine Datentransferrate von 100Mbit/s oder höher gewährleisten. Das Rechenzentrum des Anbieters sollte sich in Deutschland oder im EU Raum befinden weil niedrige Latenzzeiten durch die ständige Kommunikation mit der Datenbank erforderlich sind.

7 Cloud Computing

Abbildung 5: Shared Hosting
Quelle: clouDevice (Interphase Corporate Office)

Abbildung 6: Virtual Hosting
Quelle: clouDevice (Interphase Corporate Office)

Abbildung 7: Dedicated Hosting
Quelle: clouDevice (Interphase Corporate Office)

Aus Nutzersicht hat das konventionelle Hosting aber einige entscheidene Nachteile. So enststehen für den Kunden auch Kosten, wenn der Server kaum oder gar nicht genutzt wird. Des Weiteren ist das konventionelle Hosting nicht flexible genug, wenn es um die Erweiterung der bestehenden Infrastruktur geht. In den letzten Jahren hat sich ein Trend um das sogenannte Cloud Computing entwickelt, welches immer mehr an Bedeutung gewinnt.

7.1 Grundlagen

"Cloud Computing umfasst On-Demand-Infrastruktur (Rechner, Speicher, Netze) und On-Demand-Software (Betriebssysteme, Anwendungen, Middleware, Management- Entwiclungs-Tools), die jeweils dynamisch an die Erfordernisse von geschäftsprozessen angepasst werden kann." (Quelle: Saugatuck Technology) Dabei lässt sich Cloud Computing in unterschiedliche Dienste und Modelle kategorisieren.

7.2 Cloud Services

Man gliedert Cloud Computing in verschiedene technische und organisatorische Arten. Das National Institute for Standards and Technology (NIST) veröffentlichte 2009 hierzu entsprechende Definitionen [2], die weitesgehend Akzeptanz gefunden haben. Man unterscheidet demnach in drei Modelle: Infrastructure-as-a-Service (folgend "IaaS"), Platform-as-a-Service (folgend "PaaS") und Software-as-a-Service (folgend "SaaS").

Abbildung 8: Cloud Services (IaaS, PaaS, Saas)
Quelle: Microsoft (The Economics of the Cloud)

Infrastructure-as-Service (IaaS) stellt die unterste Schicht im Cloud Computing dar und bietet Rechenleistung (CPU, RAM), Speicherkapazitäten, Betriebssysteme und Netzwerkinfrastrukturen bereit. Dem Kunden werden hierbei typischerweise virtuelle Maschinen angeboten. Diese On-demand Lösung steht dem konventionellen Kaufen bzw. Mieten von Rechnerinfrastrukturen (dedicated server) gegenüber. Ein weiterer wesentlicher Vorteil von IaaS liegt in der hohen Skalierbarkeit der Ressourcen. Weitere Recheninstanzen können ohne Aufwand hinzugeschaltet werden. Brachliegende Kapazitäten können sofort wieder freigegeben werden. Zu den bekanntesten Vertretern/Produkten zählen Amazon EC2, Microsoft Windows Azure , Akamai NetStorage .

Platform-as-a-Service (PaaS) stellt die zweite Schicht im Cloud Computing dar und bietet Entwicklern eine Laufzeitumgebung für ihre Programme an. Die Umgebung versteckt dabei die zugrundeliegende Infrastruktur hinter Services und Schnittstellen. Dies ermöglicht ein hohes Maß an Konzentration auf die Entwicklung der eigenen Anwendung und spart die Wartung einer eigenen Serverinfrastruktur oder virtuellen Maschine ein. Zu den Angeboten dieses Modells zählen App Server, APIs, Development Tools, Datenbanken und Message Queues. Typische Vertreter/Produkte in diesem Segment sind Google AppEngine, Saleforce Force.com und LongJump.

Software-as-a-Service (SaaS) stellt die oberste Schicht im Cloud Computing dar und bietet zugleich das höchste Abstraktionslevel. Bei diesem Modell stellt der Anbieter Software zur Verfügung und ist selbst verantwortlich für die Wartung und Administration. Der Kunde nutzt diese Anwendung über das Internet, ohne sie jedoch zu kaufen. Primäre Anwendungsbereiche sind CRM, ERP, Collaboration und Office. Bekannte Vertreter mit ihren Produkten sind Google Mail, Google Docs, Microsoft Office 365, Dropbox und Evernote. SaaS ist in den letzten Jahren besonders im Consumer Markt populär geworden. Mittlerweile wird dieses Modell aber auch verstärkt vom Mittelstand nachgefragt.

Neben den drei Servicemodellen SaaS, PaaS und IaaS hat das National Institute for Standards and Technology (NIST) noch vier Liefermodelle [3] definiert: Public Cloud, Private Cloud, Hybrid Cloud und Community Cloud.

Public Cloud (öffentliche Rechenwolke) beschreibt die öffentliche Bereitstellung von Diensten über das Internet. Die angebotenen Ressouren können von beliebigen Personen und Unternehmen genutzt werden. Die hierzu notwendige Infrastruktur steht außerhalb des Unternehmens, wodurch die Anwender normalerweise kein Wissen darüber haben, wo genau ihre Daten gelagert sind.

Private Cloud (private Rechenwolke oder auch Unternehmens-Cloud) beschreibt die Bereitstellung von Diensten auf unternehmenseigener Infrastruktur. Die Infrastruktur kann sich innerhalb eines Unternehmens befinden oder extern in einem Data Center gehostet werden.

Community Cloud (gemeinschaftliche Rechenwolke) ist vergleichbar mit der Public Cloud, wobei der Nutzerkreis hier stärker eingegrenzt wird. Oft schließen sich hierfür Organisationen, Behörden oder Unternehmen einer Branche zusammen und bilden eine gemeinsame Rechenwolke.

Hybrid Cloud ist die parallele Nutzung von zwei unterschiedlichen Liefermodellen (meistens Private und Public Cloud).

7.3 Cloud Service Auswahl

Um den genannten Anforderungen gerecht zu werden, ist das IaaS-Modell zu wählen. Damit erhält das Unternehmen die Möglichkeit ihre eigenen bestehenden Images/VMs ohne größeren Migrationsaufwand in der "Rechenwolke" zu nutzen. Als Liefermodell ist die Public Cloud zu wählen, da die Inhalte öffentlich bereitgestellt werden und die Cloud Instanz der dynamischen Erweiterung des bestehenden konventionellen Hostings des Mangento-Servers dient. Demzufolge ist der Markt auf entsprechende Anbieter zu analysieren, die Public IaaS anbieten.

8 Cloud Anbieter

Abbildung 9: Cloud Services Anbieter im deutschen Markt 2011
Quelle: Experton Group 2011

Für IT Entscheider ist es eine Herausforderung aus der Vielzahl an Cloud Computing-Definitionen, Technologiekomponenten und Anwendungsszenarien, sowie der noch relativ frühen Marktphase die Angebote der Hersteller richtig einzuschätzen und zu bewerten. Durch das intensive Marketing der Hersteller und die Unschärfe der Darstellung der Produkte, herrscht eine Intransparenz am Markt. Als Entscheidungsgrundlage für das Unternehmen dient eine unabhängige Studie der Experton Group, die alle relevanten Hersteller anhand ihres Portfolios, sowie ihrer Strategie, Marktpräsenz und Wettbewerbsstärke profiliert und positioniert.

Aufgrund der Anforderungen des Unternehmens, werden nur Anbieter betrachtet, die am deutschen Markt Public IaaS anbieten. Als Entscheidungshilfe soll die folgende Abbildung aus dem Cloud Vendor Benchmark 2011 dienen, die die Anbieter in vier Quadranten unterteilt: 1. Leader, 2. Product-Challenger, 3. Follower und 4. Market-Challenger. Leader verfügen über ein hohes attraktives Produkt- und Service Angebot sowie eine ausgeprägte starke Markt- und Wettbewerbsposition. In Produkt Challenger sind Anbieter, die die Anforderungen der Unternehmen überdurchschnittlich gut abdecken, jedoch noch über keine ausreichende Marktpräsenz verfügen. Bei Market Challenger sind die Anbieter zwar schon auf dem Markt etabliert, verfügen jedoch noch über kein attraktives Portfolio. Followern mangelt es noch an ausgereiften Produkten und Services und sind noch nicht hinreichend am Markt etabliert ^[7].

Abbildung 10: Cloud Services - Public IaaS
Quelle: Experton Group 2011

8.1 Auswahl der Cloud Anbieter

Auf Grundlage des Cloud Vendor Benchmarks 2011 und eigener Recherchen ergibt sich folgendes Ranking aus 13 Anbietern. Obgleich Jiffybox nicht in der Studie der Experton Group aufgeführt wird, ist der Anbieter trotz allem im Ranking vertreten. Jiffybox ist ein Tochterunternehmen der domainFACTORY, einer der größten Webhoster in Deutschland und bietet ein attraktives Portfolio.

Legende für Tabelle 5

Tabelle 5: Bewertung der Anbieter

Obwohl die Angebote von 1&1 (CloudDynamicServer), Host Europe (Virtual Server) und Strato (Virtual Linux Server) als Cloud Computing vermarktet werden, handelt es sich dabei um konventionelle Hosting Angebote (Dedicated Server und Virtual Private Server). Bei Google (AppEngine) und Salesforce (Force.com) handelt es sich primär um PaaS-Lösungen, die zur Entwicklung von Applikationen dienen. Mit Microsoft (Windows Azure) lassen sich ausschließlich Windows Betriebssysteme in der Rechenwolke nutzen. BT (Virtual Data Centre) erfüllt nicht die Hardwareanforderungen und bei NTT (OpSource) befindet sich der Gerichtsstand nicht in Deutschland.

Hingegen haben sich folgende Anbieter mit ihren Produkten im Ranking hervorgehoben und erfüllen alle gesetzten Anforderungen: Amazon (EC2), Fujitsu (Plain Virtual Server), IBM (Smart Business Cloud), Jiffybox (CloudServer On Demand) und Nionex (Hosting On-Demand).

Zur Ermittlung der Preise der verschiedenen Anbieter, muss zunächst der Preis pro Woche errechnet werden. Folgende Angaben werden dabei herangezogen: Die VM soll dreimal die Woche von jeweils 08:00 bis 14:00 Uhr in Betrieb genommen werden. Dies entspricht eine Laufzeit von 18 Stunden pro Woche. Alle Preise der Anbieter beziehen sich auf dem Stand vom 29.06.2011. Gemäß der Vorgabe des Unternehmens liegt der Internettraffic der VM bei 1 GigaByte (GB) pro Stunde, die sich in 0,1 GB eingehend (IN) und 0,9 GB ausgehend (OUT) aufteilen. Insgesamt fallen somit pro Woche 18 GB an. Für die Berechnung des Internettraffics wird folgende Formel herangezogen:
Preis für Internettraffic = 1 * stundenpreis + 0.1 * IN + 0,9 * OUT

8.2 Berechnung der Kosten der Cloud Anbieter

8.2.1 Kosten Amazon

Für die Berechnung des wöchentlichen Preises des Anbieters Amazon, wird das Produkt Hi-Memory On-Demand Instances – Double Extra Large mit 32 GB RAM, 4 CPU für den Standort EU – Irland gewählt, um die Anforderungen zu erfüllen. Für die Linux/Unix Benutzung wird ein Stundensatz von 1,14USD berechnet ^[8]. Da die Preise von Amazon in Dollar angeben sind, wird der Kurs von 1USD = 0,6931EUR vom Stand 29.06.2011 herangezogen, um die Preise in Euro auszugeben.
Preis pro Woche: = 1,14USD * 18h = 20,52USD = 14,2228EUR

Der Internettrafficpreis von Amazon beträgt für IN 0,100USD pro GB und bei OUT sind die ersten 1 GB frei danach kosten bis zu 10 TB kostet es 0,150USD pro GB. Es ergibt sich folgende Berechnung für den Internettrafficpreis pro Woche:
Preis für Internettraffic = 0,1IN * 18h * 0,100USD + ((0,9OUT * 18h) − 1GB) * 0,150USD = 2,46USD = 1,705026EUR
Kosten gesamt pro Woche = 14,2228EUR + 1,705026EUR = 15,93EUR

8.2.2 Kosten Fujitsu

Beim Anbieter Fujitsu wird das Produkt Plain Virtual Server mit der Konfiguration 16 GB RAM, 4 CPU und mind. 100 GB HDD. Der Stundensatz beträgt 2,15EUR (siehe Futjitsu Angebot).

Der wöchentliche Preis beträgt = 2,15EUR * 18h = 38,70EUR

8.2.3 Kosten IBM

Bei IBM wird die Smart Business Cloud 64 Bit Konfiguration Gold mit 8 CPU, 16 GB RAM, 1024 GB Instanz Speicher ausgewählt. Der Preis für nicht-reservierte Kapazitäten pro Stunde beträgt 0,692EURnetto. Das sind 0,82348EUR brutto. Hinzu kommt der Internettraffic bei 0,13EUR pro GB bis 10 TB ^[9].
Das ergibt einen Gesamtpreis pro Woche = 0,82348EUR * 18h + 0,13EUR * 18h = 17,16EUR

8.2.4 Kosten Jiffybox

Um den Anforderungen gerecht zu werden, wird für den Anbieter Jiffybox das Produkt Cloud Level 5 mit 16 GB RAM, 4 CPU und 600 GB Festplatte gewählt. Für die aktive Nutzung der VM werden 0,25EUR pro Stunde und bei inaktiver Nutzung 0,04EUR veranschlagt. Die ersten 1000 GB sind bei Jiffybox im Preis mit inbegriffen ^[10]. Da das Unternehmen insgesamt 77,94 GB Internettraffic im Monat verbraucht, wird der Internettraffic nicht in die Preisberechnung mit einfließen.

Es ergibt sich somit ein Preis pro Woche = 0,25EUR * 18h + 0,04EUR * 150h = 10,50EUR

8.2.5 Kosten Nionex

Für den Anbieter Nionex wird das Produkt XL Instance mit 16 GB RAM, 4 CPU und 200 GB Storage gewählt. Der Stundenpreis beträgt 0,45EUR und der Internettrafficpreis liegt bei 0,15EUR pro GB.

Der wöchentliche Preis beträgt = 0,45EUR * 18h + 0,15EUR / GB * 18GB = 10,80EUR

8.2.6 Kosten Übersicht

Um den Preis pro Monat auszurechnen, wird der Faktor 4,33 (52KW/12 Monate) zum Wochenpreis multipliziert. Zusätzlich wird beim Anbieter Fujitsu die monatliche Pauschale von 229,30 € zum wöchentlichen Preis dazu addiert und im ersten Monat wird die einmalige Pauschale von 645 € im Monatsgesamtpreis dazugerechnet.

Tabelle 6: Kostenvergleich der Anbieter

8.3 Entscheidung für einen Cloud Anbieter

In der Wertetabelle erfüllt Fujitsu zwar die meisten Anforderungen und ist einer der Führenden am Markt, allerdings ist an den Gesamtkosten erkennbar, dass Fujitsu der teuerste Anbieter ist. Deshalbt kommt Fujitsu als Anbieter für das Unternehmen aus wirtschaftlichen Gründen nicht in Frage. Ebenfalls fallen Amazon und IBM weg, da sie anhand der Gesamtkosten teurer sind als Jiffybox und Nionex. Ein weiterer Grund ist, dass Amazons Rechenzentrum sich nicht in Deutschland befindet. IBM bietet hingegen nur eine Betriebssystemauswahl zwischen RedHat und Suse Linux an. Die eingeschränkte Betriebssystemwahl wäre ökonomisch nachteilig für das Unternehmen. Denn die internen Wartungskosten des Unternehmens würden sich erhöhen. Bei Updates der Softwarepakete und Betriebssystemkomponenten greift hierbei nicht der Standardworkflow. Die internen Wartungs- und Administrationskosten wären mindestens doppelt so hoch als bei einer frei wählbaren individuellen Linux Distribution. Übrig bleiben Jiffybox und Nionex. Beide liegen in der gleichen Preisspanne und erfüllen auch alle Anforderungen. Folglich ist laut dem Ranking Jiffybox die erste Wahl und Nionex die zweite Wahl für das Unternehmen.

8.4 Datenschutz

Was den Datenschutz betrifft, ist der hierbei der deutsche Gesetzgeber recht explizit. Nach §11 BSDG Auftragsdatenverarbeitung: "Werden personenbezogene Daten im Auftrag durch andere Stellen erhoben, verarbeitet oder genutzt, ist der Auftraggeber für die Einhaltung der Vorschriften dieses Gesetztes und des Datenschutzes verantwortlich" ^[11]. Es bedarf einer Einverständniserklärung von jener betroffenen Person zur Verarbeitung der Daten durch Dritte ^[12]. Selbst nach einer Freigabe ist der Cloud Nutzer uneingeschränkt für den Datenschutz verantwortlich. Bem Unternehmen werden die Kundendaten nur auf dem Datenbankserver abgelegt, dieser kommuniziert über eine VPN Verbindung mit den Magento Servern. Es werden also keinerlei Kundendaten auf fremden Systemen gespeichert. Da die Virtuellen Appliances komplett selbst verwaltet werden (Installation Betriebssystem, Installation Patches, Firewall), ergeben sich bezüglich der Sicherheit die selben Voraussetzung wie beim "klassischen" Anmieten eines Dedicated Servers oder eines Co-Location (Serverhousing) Platzes in einem Rechenzentrum. Der einzige Unterschied im Vergleich zum klassischen Hosting ergibt sich in der schnellen Skalierbarkeit. Dies ist aber nicht Datenschutz- oder Sicherheitsrelevant.

9 Zusammenfassung

9.1 Fazit

Es ist absehbar, dass das Unternehmen die in der Zukunft auftretenden Lastspitzen nicht mehr weiter bedienen kann. Demzufolge muss ein Konzept erarbeitet werden, wie man die Grundlast und die Lastspitzen zukünftig abfangen kann. Hier bieten sich generell drei Möglichkeiten an:
- Erweiterung der bestehenden Infrastruktur durch konventionelles Hosting
- Erweiterung der bestehenden Infrastruktur durch Cloud Computing
- Vollständige Auslagerung in die Rechenwolke

Die Anmietung von klassischen Servern bietet sich für die Bedienung der Grundlast an. Die Lastspitzen lassen sich am besten mit Hilfe von Cloud Instanzen abfangen.

Es hat sich gezeigt, dass Cloud Computing kostengünstiger, effizienter und flexibler ist. Es stellt sich daher die Frage, ob sich eine vollständige Auslagerung in die Rechenwolke nicht rechnen würde. Aus rein finanzieller Sicht wäre dies sehr rentabel und ein logischer Schritt. Dagegen sprechen aber datenschutzrechtliche Bedenken. Für die vollständige Nutzung von Cloud Computing müsste das Unternehmen auch die Kundendaten auslagern. Der Zugriff durch Dritte auf die sensiblen Daten wäre somit nicht mehr sicher geschützt. Noch mangelt es generell in Deutschland an ausreichenden Standards und Regularien zur sicheren Verarbeitung sensibler Daten in der Rechenwolke.

9.2 Kritische Auseinandersetzung

Neben der Wahl des geeigneten Anbieters/Produktes, sind auch die Service Level Agreements (SLA) zu beachten. Ein SLA ist ein Vertrag zwischen Auftraggeber und Dienstleister über Art und Umfang der zu erbringenden Leistungen. Ziel eines SLA ist es dem Kunden die zugesicherten Leistungseigenschaften, wie etwa Leistungsumfang, Reaktionszeit und Priorität der Bearbeitung, transparent zu gestalten ^[13]. Zum Beispiel beschreibt der Anbieter im SLA über die Verfügbarkeit von Internetzugängen. Die Verfügbarkeit für den Dienst wird im Regelfall in Prozent angegeben. Eine Verfügbarkeit von 99,95% kann aussagen, dass im Falle eines Ausfalles der Dienst nicht länger als 5 Minuten erreichbar sein darf^[14]. Jedoch können jederzeit Hardware, Netzwerkgeräte, Stromversorgung oder die entsprechende Klimatisierung ausfallen^[15]. Als Beispiel sei hier der Ausfall von Amazons Elastic Cloud Service (EC2) im April 2011 zu nennen. Obwohl Amazon eine Verfügbarkeit von 99,95% zusichert^[16], hielten die Infrastrukturausfälle bei Amazon und die damit verbunden Beeinträchtigungen 4 Tage an (21.04. - 24.04.2011). Ein kleiner Teil der Daten ging unwiederbringlich verloren^[17]. Viele Anbieter stellen ihre Ressourcen über mehrere Standorte in der Welt zur Verfügung, das soll dem Kunden Ausfallsicherheit gewährleisten. Obwohl der Cloudanbieter in der Wolke Redudanz und Backup zusichert, ist es zu empfehlen bei der Planung vom Einsatz von Clouddiensten ein fehlertolerantes Design einzuplanen^[18]. Denn im Falle eines Ausfalles ist es möglich, dass die Dienste für einen längeren Zeitraum nicht erreichbar sind. So sollte ein zweiter Anbieter angemietet werden um dynamisch die Ressourcen wechseln zu können. Ein weiterer Punkt sind Sicherheitsfragen. Der Nutzer übergibt die Verantwortung in die Hand des Anbieters, dass die Daten sicher in der Cloud liegen und vor Dritten geschützt sind. Um Ausfälle zu bewältigen und um die Verfügbarkeit gewährleisten zu können wird empfohlen, dass das Unternehmen einen 2. Cloudanbieter anmietet. Der Load Balancer ist in der Lage im Falle eines Ausfalles von einem Anbieter auf den anderen Anbieter zu wechseln - somit ist die Verfügbarkeit gewährleistet. In diesem Falle wäre das der Anbieter Nionex. Nionex liegt im preislichen Rahmen wie Jiffybox und erfüllt die Anforderungen.

9.3 Ausblick/ Entwicklung

Abbildung 11: Infrastructure-as-a-Service (To-Do)
Quelle: CloudTimes [1]

Um Public IaaS nutzen zu können, muss als erstes eine virtuelle Maschine eingerichtet werden. Dieser Schritt entfällt in diesem Beispiel, da der Magento Server bereits als VM vorliegt. Das Image kann direkt auf den entsprechenden Speicher des IaaS-Anbieters hochgeladen werden. Anschließend erfolgt die Konfiguration und entsprechende Freigabe für die Verteilung. Auch müssen die Zeiten für das hoch- und herunterfahren der VM konfiguriert werden. Zum Schluss muss der Load Balancer konfiguriert werden.

Zwecks Ausfallsicherheit empfiehlt es sich zukünftig noch weitere Cloud Instanzen bei einem zweiten Anbieter einzurichten. Diese können dynamisch gestartet werden, wenn beispielsweise Probleme oder Ausfälle beim ersten Anbieter auftreten. Hierfür muss der Load Balancer entsprechend konfiguiert werden.

10 Fußnoten

1. ↑ Vgl. Shopping-Community
2. ↑ Vgl. Xen: Xen Hypervisor
3. ↑ Vgl. Magento Inc.: Magento Performance Whitepaper
4. ↑ Apache Bench
5. ↑ Siege
6. ↑ Vgl. Wikipedia Artikel zu Zeitkomplexität
7. ↑ Vgl. Experton Group (2011)
8. ↑ Vgl. Amazon (2011b)
9. ↑ Vgl. IBM (2011b)
10. ↑ Vgl. Jiffybox (2011b)
11. ↑ Vgl. Bundesministerium für Justiz (2011)
12. ↑ Vgl. Feilner, Gantikow (2011a)
13. ↑ Vgl. Wikipedia (2011b)
14. ↑ Vgl. Trautmann (2011)
15. ↑ Vgl. Feilner, Gantikow (2011b)
16. ↑ Vgl. Amazon (2011c)
17. ↑ Vgl. Heise (2011)
18. ↑ Vgl. Feilner, Gantikow (2011b)

11 Literatur- und Quellenverzeichnis

12 Ehrenwörtliche Erklärung

Hiermit versichere ich, dass die vorliegende Arbeit von mir selbstständig und ohne unerlaubte Hilfe angefertigt worden ist, insbesondere dass ich alle Stellen, die wörtlich oder annähernd wörtlich aus Veröffentlichungen entnommen sind, durch Zitate als solche gekennzeichnet habe. Ich versichere auch, dass die von mir eingereichte schriftliche Version mit der digitalen Version übereinstimmt. Weiterhin erkläre ich, dass die Arbeit in gleicher oder ähnlicher Form noch kei- ner anderen Prüfungsbehörde vorgelegen hat. Ich erkläre mich damit einver- standen/nicht einverstanden, dass die Arbeit der Öffentlichkeit zugänglich ge- macht wird. Ich erkläre mich damit einverstanden, dass die Digitalversion dieser Arbeit zwecks Plagiatsprüfung auf die Server externer Anbieter hoch geladen werden darf. Die Plagiatsprüfung stellt keine Zurverfügungstellung für die Öffentlichkeit dar.