OpenStack bietet Unternehmen eine erhöhte Portabilität zwischen unterschiedlichen Cloud-Anbietern und ist eine echte Alternative zu den Amazon Web Services. Internaps neuer Services wurde als Open Public Cloud getauft. Das Unternehmen hat bereits einen Cloud Storage Services auf Basis von OpenStack ausgerollt und hat das Angebot aus dem Stack nun erweitert. Die Open Public Cloud nutzt die Open Source Xen Cloud Plattform, mit ihrem gleichnamigen Hypervisor und unterstützt sowohl virtuelle Maschinen von Windows als auch Linux.

OpenStack hat die besten Chancen der Game Changer im Cloud Computing Markt für Public Cloud Angebote zu werden. Durch eine Menge von standardisierten APIs begegnet OpenStack dem Vendor Lock-in und erlaubt es Unternehmen auf einfachem Weg ihre Workloads zwischen der eigenen OpenStack Private Cloud und der OpenStack Public Cloud eines Anbieters zu verschieben.

Bei OpenStack handelt es sich um eine Open Source Cloud Plattform, die neben dem Betriebssystem ebenfalls Storage- und Netzwerkkomponenten mitbringt und von einer Vielzahl von Unternehmen unterstützt wird.

Optimierung der eigenen IT-Infrastruktur

Der Großteil aller Unternehmen verfügt über eine eigene, in der Regel komplexe IT-Infrastruktur, die es zu verwalten gilt, um den immer neuen und steigenden Anforderungen gerecht zu werden. Dadurch verlieren die meisten den Fokus auf die eigenen Kernkompetenzen, um sich mit genau diesen von ihren Mittbewerbern zu differenzieren und hieraus einen Vorteil zu erzielen.

Weiterhin werden enorme finanzielle und zeitliche Investitionen getätigt, um den Anforderungen an das laufende Geschäft durch das Verwalten, Vergrößern und Skalieren von Ressourcen und Kapazitäten zu erhöhen (Stichwort: Lastspitzen), wodurch sich die Produktivität z.B. für neue geschäftskritische Projekte verringert. An dieser Stelle dürfen ebenfalls nicht die Vorabinvestitionen vernachlässigt werden, die für den Aufbau der IT-Infrastruktur sowie den laufenden Betrieb/ Wartung vorgenommen werden müssen.

Mit dem Einsatz von Cloud Computing Lösungen z.B. durch das Outsourcing interner IT-Anwendungen oder die Nutzung von Cloud Storage können externe Ressourcen effektiv und bedarfsgerecht genutzt werden und die oben genannten Kosten lassen sich damit minimieren.

Content bereitstellen

Unternehmen stehen vor der Herausforderung, Inhalte wie Bilder, Videos oder sonstige Downloads auf Ihren Webseiten den Kunden hochperformant und zuverlässig bereitzustellen. Eine Möglichkeit dies zu realisieren, ist das Erhöhen des Durchsatzes sowie die Verringerung der Latenz innerhalb des Netzwerks.

Mittels eines Content Delivery Network (CDN) innerhalb einer Cloud Computing Infrastruktur, in welchem die Inhalte auf sogenannten Edge-Servern gespeichert werden und die sich in einem Rechenzentrum, das sich möglichst nah am Benutzer befindet, können Teile der oben genannten Anforderungen erfüllt werden. Zusätzlich können Algorithmen verwendet werden, welche die Inhalte zum Zeitpunkt der Anfrage auf die Server in der Nähe des Benutzers kopieren, wodurch die Leistung weiter erhöht wird.

Hosting von Anwendungen

Vor der Einführung des Software-as-a-Service Modells (SaaS) (abgesehen von den Application Service Providern – ASP) waren Unternehmen gezwungen eigene Infrastrukturen für die Nutzung und Bereitstellung lokaler Anwendungen aufzubauen und zu warten. Mit SaaS können diese Anwendungen nun online gehostet und verwendet werden. Die Vorteile ergeben sich auf der einen Seite durch Kosteneinsparungen auf Grund eines nutzungsabhängigen Abrechnungsmodells durch automatisierte Updates und Upgrades durch den Anbieter. Auf der anderen Seite ist eine gute Integration in die eigenen bestehenden Systeme ein Vorteil.

Anbieter von Software-as-a-Service basierten Anwendungen stehen vor der Herausforderung die kostspieligen und komplexen Infrastrukturen, die für das Hosting dieser Anwendungen benötigt werden, aufzubauen sowie skalierbar und hochperformat bereitszustellen. Zumal die Nachfrage durch die Kunden mittels eines Forecast schwierig anzuschätzen ist.

Bereitstellung von Medieninhalten

Wollen Unternehmen ihren Kunden Medieninhalte über das Internet bereitstellen, stehen sie vor der Herausforderung, Lastspitzen durch nicht kalkulierbare Anfragemengen zu unterschiedlichen Zeitpunkten zu bewältigen, die nicht überschaubar sind und teuer werden können. Anforderungen an die gesamte Infrastruktur betreffen hierbei die verfügbare Bandbreite, die Performance, den Speicherplatz und nicht zu vernachlässigen: Die Sicherheit. All das kann dazu führen, dass die ursprünglich geplanten Kosten deutlich höher ausfallen.

High Performance Computing

Die Verarbeitung großer Datenmengen für die eine hohe Rechenleistung benötigt wird, ist in den vergangenen Jahren stark angestiegen. Davon betroffen sind vor allem Unternehmen aus den Bereichen der Medizintechnik, Finanzdienstleitungen und Medien.

Für einzelne rechenintensive Projekte werden die Kapazitäten der Infrastrukturen oftmals stark erweitert, da die bestehende Infrastruktur nicht leistungsfähig genug ist. Im schlimmsten Fall stehen zusätzlich nicht ausreichend finanzielle Mittel und Zeit zur Verfügung, um die Infrastruktur gemäß den Anforderungen anzupassen. Hinzu kommt der Aufwand zur Errichtung und dem Erweitern der Serverumgebungen und der damit verbundenen Beschaffung und Bereitstellung der Hard- und Software. Das Gewährleisten einer hohen Verfügbarkeit darf ebenso wenig vernachlässigt werden wie die Sicherheit der gesamten Umgebung. Weiterhin muss die Infrastruktur verwaltet werden (u.a. Zuweisung des Speichers, Konfiguration der Batchprozesse, etc.), um den Geschäftszweck zu erfüllen, was implizit dazu führt, dass die Mitarbeiter dementsprechend fortgebildet und verwaltet werden müssen.

Eine weitere Herausforderung ist die Verwaltung und Neuzuordung der Ressourcen nach dem erfolgreichen Beenden eines Projekts. Werden die verfügbaren Ressourcen nicht umgehend neuen Projekten oder Aufgaben zugewiesen, sind diese ungenutzt und verursachen Kosten ohne einen Wertbeitrag zu leisten.

Mittels Cloud Computing können die Problematiken der oben genannten Punkte minimiert werden und Ressourcen für Projekte aus dem Bereich des High Performance Computing (HPC) bzw. Parallel Computing bedarfsgerecht und kosteneffizient bezogen werden.

Externe E-Commerce Lösungen

Im Bereich des E-Commerce verfügen die meisten Unternehmen nicht über die Kernkompetenzen, um in ihren Anwendungen die notwendigen Eigenschaften für einen ganzheitlichen Handelsprozess zu etablieren. Dazu gehören der gesamte Zahlungsverkehr, die Auftragsverwaltung, das Kommissionieren und Verpacken der Artikel sowie den Versand zum Kunden. Weiterhin muss die gesamte IT-Infrastruktur auf die E-Commerce Lösung abgestimmt sein, um die Bearbeitung der Kundenanfragen zuverlässig und sicher abzuwickeln und ebenfalls auf saisonale bzw. unerwartete Lastspitzen durch schwankende Anfragen flexibel zu reagieren.

Zahlreiche Cloud Computing Anbieter stellen E-Commerce Lösungen bereit, wodurch Unternehmen auf den Aufbau und die Verwaltung einer eigenen Plattform verzichten können und sich damit auf ihre Kernkompentenzen und ihre Kunden konzentrieren können.

Webcrawler

Informationen sind im Internet weit verteilt und unorganisiert, wodurch für das Suchen, Abfragen, Verteilen und Organisieren dieser Daten hohe Anforderungen hinsichtlich der Verarbeitung und dem Speichern gestellt werden. Weiterhin werden moderne Algorithmen benötigt, mit denen diese Daten manipuliert, indiziert und die Anfragen der Benutzer beantwortet werden können. Der ständige Wandel innerhalb des Internets verstärkt zudem die Situation, exakt die Informationen zu finden, die gesucht wurden.

Mit Cloud Computing steht im Prinzip jedem die Möglichkeit bzgl. Speicherplatz und Rechenleistung zur Verfügung, um einen eigenen Webcrawler zu entwickeln. Dazu müssen Dinge beachtet werden, die auch von der Infrastruktur eines Cloud Computing Anbieters erfüllt werden müssen, auf welcher der Webcrawler dann ggf. ausgeführt wird.

Datenspeicherung und Datenbackup

Eine der größten Herausforderungen für Unternehmen ist die stetige Zunahme der zu speichernden Daten, welche die Verwaltungsaufgaben immer komplexer und kostspieliger werden lässt. Nicht nur auf Grund dieser Situation wird die Gewährleistung des Datenschutzes und der Datenverfügbarkeit immer wichtiger. Cloud Storage für das Speichern und Backup der Daten ist hierfür ein idealer Ansatz, wenn gewisse Punkte beachtet werden.
Ein Cloud Storage hat bspw. in erster Linie den Vorteil, dass der genutzte Speicherplatz automatisch mit den Bedürfnissen mitwächst. Werden heute 10GB, morgen aber 100GB benötigt, stellt das kein Problem dar und es müssen dafür keine eigenen Investitionen in neue Speichersysteme getätigt werden.
Zudem stehen alle Daten an einer zentralen Stelle bereit, wodurch alle Mitarbeiter von jedem beliebigen Ort aus einen gemeinsamen Zugriff auf exakt denselben Datenbestand erhalten und damit die Zusammenarbeit deutlich verbessert wird.

Web-Hosting

Unternehmen haben unterschiedliche Lösungsansätze, um das Web-Hosting ihrer Webseite zu betreiben. Zunächst besteht die Möglichkeit ein eigens Rechenzentrum aufzubauen und zu betreiben. Weiterhin kann ein Drittanbieter damit beauftragt werden, die Webseite auf seine dafür dedizierten Servern zu hosten und zu verwalten. Der letzte Ansatz ist die Nutzung Cloud Computing basierter Lösungen.

Egal welcher Ansatz nun verfolgt wird, ist es für Unternehmen unabdingbar eine Infrastruktur auszuwählen, die ihnen eine größtmögliche Sicherheit, Zuverlässigkeit und Performance bietet. Unabhängig davon rücken die Kosten, also fixe Kosten und variable Kosten, immer weiter in den Fokus und betreffen jedes Unternehmen jeder Größe. Zudem ist in den letzten Jahren der Wunsch nach Flexibilität immer weiter gestiegen um die Kosten transparenter im Blick zu behalten.

Cloud Computing Lösungen geben Unternehmen hierbei die Chance ihre Vorabinvestitionen zu verringern und damit Kapital zu sparen. Ein weiterer Vorteil einer Cloud Lösung besteht in der Skalierbarkeit in beide Richtungen. Steigt die Auslastung an, können die Ressourcen nach oben skaliert werden. Nimmt die Auslastung wieder ab, werden die überschüssigen Ressourcen wieder freigegeben. In beiden Fällen entstehen nur Kosten für die Ressourcen, die auch tatsächlich genutzt werden.

Private Cloud

In einer Private Cloud betreiben Unternehmen ihre eigenen Rechenzentren und nutzen ihre Dienste nur für Ihre eigenen (geschäftlichen) Zwecke innerhalb ihrer eigenen privaten Netze. Die Nutzung durch die Öffentlichkeit kommt hier nicht in Frage. Die Datensicherheit, ‘Corporate Governance’ und Zuverlässigkeit liegen damit in ihrem eigenen Einflussbereich. Aus diesem Grund werden Private Clouds nur indirekt zum Cloud Computing gezählt. Hier werden lediglich die Ideen und Konzepte adaptiert.

Public Cloud

In einer Public Cloud werden Rechenkapazität, Speicherplatz etc. gegen eine Nutzungsgebühr oder kostenlos der Öffentlichkeit zur Verfügung gestellt. Die Aufgaben, die ein Unternehmen in der Private Cloud übernimmt, werden in der Public Cloud dann von einem Drittanbieter übernommen. Dazu gehören z.B. der Kauf und die Wartung der Server. Die Aufgaben und Services von unterschiedlichen Kunden werden dabei auf derselben Infrastruktur gemeinsam gehostet und verarbeitet. Ein einzelner Kunde hat keine Kenntnis darüber, wessen Dienste ebenfalls auf derselben Infrastruktur gespeichert und verarbeitet werden.

Hybrid Cloud

Eine Hybrid Cloud stellt eine Kombination aus einer Private und einer Public Cloud dar. Dabei verfügen Unternehmen zwar über ihre eigene Private Cloud, verwenden aber zusätzlich Dienste aus der Public Cloud von externen Anbietern. Die Attraktivität besteht vor allem darin, dass der externe Anbieter bei Bedarf schneller und kostengünstiger die benötigte Infrastruktur erhöhen bzw. verkleinern kann. Die Dienste werden so in die Private Cloud integriert, dass der Endanwender nicht merkt, dass er eigentlich woanders arbeitet.

Virtual Private Cloud

In der jüngsten Vergangenheit hat sich eine neue Art des Cloud Computing herauskristallisiert, die Virtual Private Cloud. Dabei handelt es sich wie schon bei der Hybrid Cloud um eine Kombination aus einer Public Cloud und einer Private Cloud. Der Unterschied besteht jedoch darin, dass ein Public Cloud Anbieter für den Kunden einen dedizierten (virtuellen) Bereich im Rechenzentrum des Anbieters bereitstellt. Hier kann der Kunde anschließend sein eigenes virtuelles Rechenzentrum nach Private Cloud Gesichtspunkten (Datenschutz, Datensicherheit und Compliance) aber unter den Bedingungen einer Public Cloud (Skalierbarkeit, Verfügbarkeit, Flexibilität und Pay per use) aufbauen. Eine Verbindung der Virtual Private Cloud mit dem eigenen Rechenzentrum ist ebenfalls möglich.

Bei den Potentialen handelt es sich bspw. um Kosten – Wandel von fixen zu variablen Kosten, eine bessere Ressourcenallokation, Flexibilität, Agilität, Ortsunabhängigkeit – dadurch flexibleres Recruiting von Leuten auf der ganzen Welt, Bsp. 37Signals). Wichtig ist, dass sich Unternehmen darüber jedoch im klaren sind, dass Cloud Computing Anbieter einem nicht die Arbeit vollständig abnehmen und das der Weg in die Cloud gut durchdacht und geplant werden muss. Das Unternehmen muss sich zunächst selber kennen und analysieren und schauen wo es Potentiale für Cloud Computing sieht.

Der Glaubenskrieg

Wir haben in der Cloud im Prinzip dieselbe Situation wie wir sie schon in der Vergangenheit gesehen haben. In jedem Bereich gibt es einen Glaubenskrieg, welche Technologie oder welcher Ansatz der Bessere ist. So kennen wir den Krieg zwischen Microsoft und Linux oder aktuell zwischen dem iPhone und Android. In der Cloud haben wir den Krieg der unterschiedlichen Deploymentmodels wie der Private/ Public/ Virtual Private und Hybrid Cloud. Aber anders wie bspw. beim Kampf zwischen Apple und Android, wo hier zwischen der coolen Marke Apple mit seinem verschlossenen iOS System und dem offenen Ansatz von Android argumentiert wird, geht es beim Cloud Computing argumentativ in erster linie um die Themen Datenschutz, Datensicherheit und Compliance.

Es geht um den Use Case

Fakt ist allerdings, dass alles vom gegenwärtigen Use Case abhängt. Denn es gibt nicht die gute oder schlechte Cloud. Betrachten wir einmal die unterschiedlichen Cloud Deployment Ansätze:

Private Cloud
Ich bin kein Gegner der Private Cloud. Ich finde die Adopation der Konzepte und Methoden des Cloud Computing für das eigene Rechenzentrum durchaus interessant. Es besteht dadurch die Möglichkeit, die interne IT deutlich flexibler zu gestalten und seinen internen Kunden und Projekten die Ressourcen on Demand bereitzustellen, wodurch sich die Resourcenallokation verbessert und die Abrechnung ebenfalls genauer wird.

Dennoch sollte ein Unternehmen sich überlegen, ob es tatsächlich Sinn macht eine Private Cloud im eigenen Rechenzentrum aufzubauen. Warum? Mit der Private Cloud hat man die Probleme des klassischen Rechenzentrum Betriebs plus die Komplexität der Private Cloud. Hinzu kommen die Kosten für die Hardware/ Software/ Lizenzen sowie die Fortbildung des Personals. Cloud Computing dient nun einmal dazu, sich auf die eigenen Kernkompetenzen zu konzentrieren. Das schafft man mit einer Private Cloud jedoch nicht!

Public Cloud
Die Public Cloud hilft z.B. Entwicklern mit einer coolen Idee, kostengünstig an dafür benötigte Ressourcen zu gelangen. Die für das Projekt benötigte Infrastruktur wächst mit den Anforderungen der Entwickler und der eigentlichen Software. Dann sind natürlich Webapplikationen dafür bestens geeignet. In den vergangenen Monaten und Jahren sind auf Basis der Public Clouds viele tolle und neue Anwendungen und Geschäftsmodelle entstanden. Aber auch Graphikdesigner sollten sich überlegen, ob sie sich für das Rendern ihrer Videos lieber einen Apple Xserver holen oder doch lieber eine performante Instanz in der Cloud starten. Und auch für andere Bereiche in denen der Datenschutz eine nicht so hohe Bedeutung hat (je nach land in dem der Provider sitzt) sind ausreichend Potentiale vorhanden.

Virtual Private Cloud
Die Virtual Private Cloud verbindet das Beste aus den Welten der Public Cloud und der Private Cloud. Hier sehe ich in Zukunft mehr Produktivsysteme als z.B. in der Public Cloud. Sie ist besonders für Unternehmen interessant, denen verhandelbare SLAs und ein höherer Service wichtig sind. Die Anbieter von Virtual Private Clouds bieten darüber hinaus eine bessere Unterstützung bei der Verwaltung der virtuellen Infrastruktur, was unter anderem auch daran liegt, dass innerhalb einer Public Cloud ein sehr hohes Maß an Standardisierung herrscht. In einer Virtual Private Cloud erhält man dagegen die Möglichkeit für mehr Customization.

Hybrid Cloud
Wird mittelfristig das gängigste Cloud Deploymentmodel werden. Unternehmen stocken darüber bei Bedarf ihre Ressourcen auf, wenn diese benötigt werden und geben Sie im Anschluss wieder zurück. Damit werden Services (nicht nur IaaS sondern auch SaaS und PaaS) in die eigene Unternehmens IT adoptiert. Für die Adaption ist natürlich keine eigene Private Cloud erforderlich, aber ein Cloud Managementsystem, das für die Verwaltung und das Monitoring der einzelnen Services wichtig ist.

Beim Cloud Computing geht es um Selbstverantwortung

Unabhängig davon welches Cloud Deploymentmodel am Ende genutzt wird, ist die Eigenverantwortung ein wichtiges Thema! Ein Nutzer darf nicht die gesamte Verantwortung auf die Seite des Anbieters schieben, wenn es darum geht, die Cloud zu nutzen. Natürlich ist der Anbieter für die Infrastruktur verantwortlich, aber das Unternehmen was die Cloud nutzen möchte muss zunächst seine Hausaufgaben machen. Man sollte als Kunden mit dem Anbieter zusammenarbeiten und ggf. den ersten Schritt machen. Sollte er keine Reaktion zeigen, ist er definitiv der falsche Anbieter für mich. Im Falle der Virtual Private Cloud sollte ich als Kunde Einfluss auf das Design meiner virtuellen Infrastruktur nehmen können und mit dem Anbieter zusammen eine Strategie erarbeiten. Denn das ist genau die Kernkompentenz des Anbieters!

Darüber hinaus sollte jedes Unternehmen über ein Risikomanagementsystem verfügen, dass auf Gefahrenpotentiale aufmerksam macht. Wenn ich bspw. als ein produzierendes Unternehmen tätig bin, habe ich auch mehr als nur einen Lieferanten, für den Fall das mein primärer Lieferant ausfällt.

Der Weg in die Cloud

Es gibt nicht exakt DEN weg in die Cloud, aber es gibt logische Dinge die man berücksichtigen sollte.

Haben Sie eine Strategie und denken Sie über Ihre Governance nach. Ein Problem der Cloud besteht darin, dass sie zum ausprobieren verlockt. Und plötzlich ist man drin und nutzt möglicherweise ungewollt mehrere Services, die nicht in die IT-Strategie passen. Darüber hinaus sollten man sich überlegen, was man mit und in der Cloud machen möchte und was man davon erwartet. Als nächstes gilt es eigene Kriterien aufzustellen die aufzeigen, was man vom Cloud Computing Anbieter erwartet. Im Anschluss müssen die Bereich im Unternehmen identifiziert werden, die in die Cloud gehen können, gefolgt von der Suche nach den für das Unternehmen benötigten Services. Das bedeutet, dass das Unternehmen gründlich analysiert werden muss. Weiterhin ist eine offene Kommunikation zur und innerhalb der IT-Abteilung sehr wichtig!

Design for Failure!

Wenn Sie die Cloud nutzen wollen, sollten Sie eines beachten: Design for Failure!. Die Nutzung von IaaS meint in erster Linie, dass der Provider “nur” Ressourcen zur Verfügung stellt, mit denen ich mir ein eigenes virtuelles, skalierbares Rechenzentrum aufbauen kann. Ich merke immer wieder, dass dieses Verständnis fehlt. Bei einer Virtual Private Cloud sieht das etwas anders aus, da hier der Service mehr im Vordergrund steht. Bei einer Virtual Private Cloud sollte man daher mit dem Anbieter zusammen ein Design entwickeln. Unabhängig von Public Cloud oder Virtual Private Cloud ist es allerdings wichtig sich mit der Cloud die man nutzt detailliert auszukennen hat.

Bzgl. des Design for Failure sollte man daher grundsätzlich darauf achten, keinen Single Point of Failure zu schaffen. Und vor allem immer davon ausgehen, dass zu jedem Zeitpunkt etwas schiefgehen kann. Das Ziel muss daher darin bestehen, das die Anwendung zu jederzeit funktioniert, auch dann wenn die darunter liegende Hardware bzw. Infrastruktur ein Problem hat.

Multivendor Cloud Strategie

In Bezug auf das Design for Failure Prinzip sollte man sich ebenfalls Gedanken über eine Multivendor Cloud Strategie machen. Dies gilt nicht nur für IaaS sondern ebenfalls für SaaS und PaaS und bedeutet, dass man sich nicht nur auf einen Anbieter konzentriert, sondern seine Services/ Instanzen über mehrere Anbieter hinweg verteilt. Man kann sich dafür zunächst einen primären Anbieter suchen und parallel dazu bei weiteren Anbietern Vorbereitungen treffen. Falls es bei dem primären Anbieter zu einem Problem kommt, kann dann automatisiert umgeswitched werden. Neben der dadurch noch höheren Ausfallsicherheit beugt man damit ebenfalls einem Vendor Lock-in vor und macht sich Gedanken über das grundsätzliche und portable Design der virtuellen Infrastruktur.

Fazit

Cloud Computing hat für jedes Unternehmen Potentiale. Unabhängig von einer Private/ Public/ Virtual Private oder Hybrid Cloud oder IaaS, SaaS, PaaS. Es gilt letztendlich die passende Lösung für sein Unternehmen zu finden und zu schauen wo Cloud Computing helfen kann. Das heißt zunächst das Unternehmen zu analysieren, zu kennen und zu verstehen und die Bedürfnisse und Anforderungen zu definieren. Im Anschluß muss eine Cloud Strategie entwickelt und danach selbstverantwortlich gehandelt werden. Denn Cloud Computing ist nun einmal kein Allheilmittel!

Für die bestmögliche Nutzung von Amazon EC2 Instanzen sollten folgende Hinweise beachtet werden:

• Wichtige und langfristig benötigte Daten sollten nicht auf dem lokalen Instanzspeicher abgelegt werden.
  Wenn eine Instanz ausfallen sollte, sind die Daten auf dem lokalen Speicher nicht mehr vorhanden. Das kann umgangen werden, indem eine Replikationsstrategie angewendet wird, bei der die Daten über mehrere Instanzen repliziert werden. Weiterhin kann Amazon S3 oder Amazon EBS für das dauerhafte Speichern von Daten verwendet werden.

• Erstellen von Images die regelmäßig für eine bestimmte Aufgabe benötigt werden.
  Für den Einsatz von Web Anwendungen wird z.B. ein Image für Datenbank Instanzen und ein weiteres für Web Server Instanzen erstellt.

• Überwachen des Zustands der Instanzen
  Das kann z.B. mit Amazon CloudWatch vorgenommen werden.

• Die Firewall Regeln von Amazon EC2 sollten so restriktiv wie möglich sein.
  Es sollten zunächst nur die Berechtigungen vergeben werden, die auch tatsächlich benötigt werden. Weiterhin sollten für alle Instanzen mit unterschiedlichen Sicherheitsanforderungen separate Security Groups erstellt werden. Es sollten ggf. zusätzliche Sicherheitsmaßnahmen innerhalb einer Instanz getroffen werden, z.B. der Einsatz der eigenen Firewall. Für den SSH Zugriff auf eine bestimmte Instanz sollte eine Bastion Group erstellt werden, die ausschließlich einen externen Login erlaubt. Alle weiteren Instanzen sollten einer Security Group zugewiesen werden die einen externen Login verbietet.

Quelle

• Instance Usage

Ein AWS Account ist auf 100 EBS Volumes oder in der Summe auf eine Volume Gesamtspeichergröße von 20 Terrabyte begrenzt. Dabei beträgt die maximale Größe eines Volumes 1 Terrabyte. Jedes EBS Volume kann jeder EC2 Instanz innerhalb derselben Verfügbarkeitszone hinzugefügt werden.

Mit Amazon EBS können Snapshots (Backups) der EBS Volumes erstellt und auf Amazon S3 gespeichert werden. Diese Snapshots können als Ausgangspunkt für neue EBS Volumes genutzt werden und schützen die Daten langfristig. Weiterhin können Snapshots mit bestimmten Benutzern geteilt oder öffentlich verfügbar gemacht werden.

Amazon EBS Volumes verfügen über folgende Eigenschaften:

• Speichern ausserhalb der Instanz
• Persistenz jenseits der Lebensdauer von Instanzen
• Hohe Verfügbarkeit und Zuverlässigkeit
• Hinzufügen und Entfernen der Volumes für bereits ausgeführte Instanzen
• Darstellung als ein eigenes Gerät innerhalb der Instanz

Amazon EBS Snapshots verfügen über folgende Eigenschaften:

• Erfassung des aktuellen Zustands eines Volumes
• Datensicherung
• Instanziierung neuer Volumes, die den exakten Inhalt eines Snapshots beinhalten

Amazon EBS Anwendungsfälle

---

Fehlertoleranz

Amazon EBS ist so konstruiert, dass jede Instanz zu einem Speichervolumen hinzugefügt werden kann. Fällt eine Instanz auf Grund eines Fehlers aus, löst sich das EBS Volume automatisch mit den intakten Daten von der Instanz. Anschließend kann das Volume zu einer neuen Instanz hinzugefügt werden und der Wiederherstellungprozess beginnen.

Erklärung

• 1. Eine Amazon EC2 Instanz ist mit einem EBS Volume verbunden. Die Instanz fällt aus, bzw. Probleme treten auf.
• 2. Zur Wiederherstellung muss das EBS Volume nun von der Instanz gelöst werden. Das kann auch automatisch durch das EBS Volume erfolgen. Anschließend wird eine neue Instanz gestartet und das Volume dieser neuen Instanz hinzugefügt.
• 3. Für denn Fall das ein Amazon EBS Volume ausfällt, kann eines neues EBS Volume auf Basis des jüngsten Snapshots des Volumes erstellen, dass ausgefallen ist.

Neue Volumes auf Basis von Snapshots erstellen

Amazon EBS Snapshots ermöglichen den schnellen Einsatz neuer Volumes, indem ein bereits vorhandener Snapshot als Ausgangspunkt für diese neuen Volumes dient.

Erklärung

• 1. Es wird ein Web-Service mit einer großen Datenmenge verwendet.
• 2. Wenn die Daten fertig sind, kann ein Snapshot des Volumes in Amazon S3 zur langfristigen Datensicherung gespeichert werden.
• 3. Wenn der Datenverkehr und Ressourcenverbrauch ansteigt, kann aus dem Snapshot ein neues Volume erstellt, eine neue Instanz gestartet und anschließend dieser neuen Instanz das neue Volume hinzugefügt werden.
• 4. Wenn sich der Datenverkehr wieder verringert, können eine oder mehrere Amazon EC2 Instanzen heruntergefahren und ihre EBS Volumes gelöscht werden.

Datenpersistenz

EBS Volumes existieren unabhängig von den aktuell vorhandenen Instanzen und bleiben solange vorhanden, bis sie explizit gelöscht werden. Das ermöglicht das Speichern von Daten, ohne dass eine Instanz gestartet sein muss.

Erklärung

• 1. In regelmäßigen Abständen wird eine Instanz zur Batchverarbeitung von großen und wachsenden Datenmengen ausgeführt.
• 2. Am Ende der Verarbeitung wird die EC2 Instanz beendet. Das EBS Volume wird aber weiterhin ausgeführt.
• 3. Werden die Daten das nächste Mal verarbeitet, wird eine neue EC2 Instanz gestartet und dem bereits vorhandenen EBS Volume hinzugefügt.

Auf Basis dieses Vorgehens können die Daten nur mit den Ressourcen auf unbestimmte Zeit verarbeitet und gespeichert werden, die auch tatsächlich benötigt werden.

Root Partition

EBS Volumes können als Root Device (Partition) für Linux und Windows Instanzen verwendet werden. Dadurch besteht die Möglichkeit Root Partitionen mit der Größe von bis zu 1 Terrabyte zu nutzen.

Weiterhin kann das EBS Volume (als Root Partition) von einer anderen Instanz gemounted werden, falls eine Instanz ausfällt.

Die Größe der Partition kann während des Startvorgangs mittels Block Device Mapping geändert werden.

Erklärung

• 1. Ein vorhandenes AMI ist in Amazon EBS gespeichert. Es Änderungen daran vorgenommen und ein neues AMI erstellt.
• 2. Falls die Größe der Root Partition nicht mehr ausreicht, wird die Instanz gestoppt und mit einem größeren EBS Volume neu gestartet.
• 3. Falls eine Instanz ausfallen sollte, wird eine neue Instanz gestartet und die Root Partition (EBS Volume) der ausgefallenen Instanz gemounted.

Große Datenmengen

Amazon EBS bietet größere Volumes als Amazon EC2 Instanzen. Jedes EBS Volume kann bis zu einem Terrabyte groß sein.

Quelle

• Amazon Elastic Block Store

Installation

---

Installation auf Karmic Koala (9.10) und späteren Versionen

Für alle Ubuntu Versionen ab Karmic Koala (9.10) sind fertige Pakete vorhanden.

apt-get install python-vm-builder-ec2

Installation auf früheren Versionen

Für frühere Versionen müssen die notwendigen Tools installiert werden, um den VMBuilder zu erstellen und diesen zu nutzen.

sudo apt-get install bzr cdbs python-all-dev python-epydoc \
  kvm debootstrap parted kpartx ubuntu-keyring             \
  dpkg-dev python-boto python-cheetah ec2-ami-tools        \
  devscripts build-essential

Laden der EC2-Änderungen die an dem VMBuilder ggf. vorgenommen wurden.

sbzr branch lp:~zulcss/vmbuilder/vmbuilder-intrepid-ec2

Laden der EC2 Skripte die für die Konfiguration während des ersten Starts und der ersten Benutzeranmeldung für das Image benötigt werden.

bzr branch lp:~zulcss/ec2-scripts/trunk zulcss-ec2-scripts

Erstellen des VMBuilder Package.

(cd vmbuilder-chuck; debuild -uc -us)

Installation der Debs.

sudo dpkg -i                \
  python-vm-builder_*.deb   \
  python-vm-builder-ec2*.deb

Erstellen einer virtuellen Maschine

---

Mit dem folgenden Befehl wird automatisch ein Image erstellt, ge-bundled und hochgeladen.

sudo vmbuilder xen ubuntu --suite={hardy,intrepid,karmic} --ec2 \
  --ec2-cert=                  \
  --ec2-key=                    \
  --ec2-access-key=                     \
  --ec2-secret-key=                     \
  --ec2-user=                             \
  --ec2-bucket=                        \
  --ec2-prefix=                                \
  --ec2-version="Beschreibung des EC2 Image"              \
  --firstboot=/usr/share/doc/python-vm-builder-ec2/examples/ec2-firstboot.sh            \
  --part=/usr/share/doc/python-vm-builder-ec2/examples/ec2-< arch >-part-file.txt         \
  --debug

Beim Einsatz eines früheren Ubuntu Release müssen die Skripte unter /usr/share/doc/python-vm-builder-ec2/examples mit den Skripten von zulcss-ec2-scripts (siehe oben) ersetzt werden.

Quelle

• EC2Vmbuilder

Die folgende Tabelle beschreibt die Unterschiede zwischen AMIs die in Amazon EBS abgelegt sind und AMIs die sich in Amazon S3 (Instanzspeicher) befinden.

Öffentliche AMIs können direkt über Amazon oder die Amazon EC2 Community bezogen werden. Öffentliche AMIs dienen als Basis und können dazu benutzt werden, um eigene maßgeschneidert AMIs zu erstellen.

Private AMIs sind AMIs die einem selbst gehören. Auf diese kann daher nur selbst bzw. von Leuten zugegriffen werden, denen man den Zugriff erlaubt hat.

Shared AMIs werden von Entwicklern erstellt und anderen Entwicklern für die Nutzung zur Verfügung gestellt.

Paid AMIs können von Entwicklern oder Unternehmen wie z.B. RedHat gekauft werden. Es existieren ebenfalls AMIs die an spezielle Serviceverträge gekoppelt sind.

Quelle

• AMI Basics

• 1. Zunächst wird ein AMI (Amazon Machine Image) von Grund auf neu, oder auf Basis eines bereits vorhandenen AMIs erstellt. Dieser Vorgang ist optional, da Instanzen aus bereits vorhandenen AMIs gestartet werden können, ohne diese vorab zu verändern.
• 2. Für ein AMI das einen lokalen Instanzspeicher für sein Root Device verwendet, muss der Prozess zum bundlen und registrieren des AMIs erfolgen. Für ein AMI hingegen, dass ein Amazon EBS Volume verwendet, reicht es aus, den create Image Befehl auf einer bereits gestarteten Instanz auszuführen. Amazon EC2 gibt anschließend eine AMI ID zurück, wodurch auf Basis des AMI so viele Instanzen wie gewünscht gestartet werden können.
• 3. Starten einer oder mehrerer Instanzen eines AMI.
• 4. Verwalten und verwenden der Instanzen als wären es gewöhnliche Server.

Quelle

• Amazon EC2 Flow

Um die Ubuntu Server Edition unter den Amazon Web Services auszuführen, sind folgende Schritte notwendig.

• Erstellen eines Amazon Web Services Account
• Konfigurieren der Keys
• Installation der Amazon EC2 API Tools
• Instanziierung der Images
• Konfiguration der Instanz

Erstellen des Amazon Account

• 1. Die Seite http://aws.amazon.com aufrufen und “Jetzt anmelden” wählen. Anschließen mit einem vorhandenen Account anmelden oder einen neuen erstellen.
• 2. Die Seite http://aws.amazon.com/ec2 aufrufen und “Anmelden für EC2″ wählen.
• 3. Am Ende der Anmeldung muss mittels “Create a New X.509 Certificate” ein Zertifikat erstellt werden. Sollte man bereits über ein X.509 Zertifikat verfügen, kann nur dieses heruntergeladen werden, der Private Key allerdings nicht!

Sollte man den Private Key “verlegt” haben, muss ein neues X.509 Zertifikat generiert werden.

• Erstellen des neuen Zertifikat.
• Herunterladen des Private Key und des neuen Zertifikat.
• Notieren der AWS Account ID. Unter http://aws.amazon.com/ec2 >> “Konto” >> “Kontoaktivität” >> rechts oben “XXXX-XXXX-XXXX”

Um später erneut ein X.509 Zertifikat zu erstellen folgt man dem Weg “Konto” >> “Sicherheitsnachweise” >> “Access Credentials” >> Reiter “X.509 Certificate” >> “Create a new Certificate”. Anschließend muss der Private Key und das Zertifikat wieder heruntergeladen werden.

Die Ubuntu Images

Folgende Unbuntu Versionen sind als AMIs vorhanden:

• (i) = instance
• (e) = ebs

Auf Eric Hammond’s Webseite Alestic.com können weitere inoffizielle AMIs (8.04 Hardy, 9.04 Jaunty) heruntergeladen werden.

Installation der Amazon EC2 API Tools

Zunächst sollte sichergestellt werden, dass Multiverse Repositories konfiguriert sind.

Anschließend wird das folgende Kommando ausgeführt:

sudo apt-get install ec2-api-tools

Als nächstes müssen die folgenden Umgebungsvariablen für die eigene Shell gesetzt werden. Dazu werden die folgenden Zeilen in die ~/.bashrc eingetragen, wenn die Bash die bevorzugte Shell ist.

export EC2_PRIVATE_KEY=$HOME//pk-XXXXXXXXXXXXXXXXXXXXXXXXXXXX.pem
export EC2_CERT=$HOME//cert-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.pem
export JAVA_HOME=/usr/lib/jvm/java-6-openjdk/

Die oben vorgenommen Anpassungen können mit dem folgenden Befehl überprüft werden.

ec2-describe-images -o self -o amazon

Um öffentliche AMIs zu nutzen muss zuerst ein SSH Key generiert werden. Mit dem folgenden Befehl wird ein SSH Schlüsselpaar (Keypair) erstellt und der Private Key automatisch in die Datei mit dem Namen ec2-keypair lokal gespeichert.

ec2-add-keypair ec2-keypair > ec2-keypair.pem

Weiterhin müssen die Zugriffsrechte der erstellen Datei 600 betragen.

chmod 600 ec2-keypair.pem

Verwenden der Ubuntu Images

Auf die Images und die Kernel kann öffentlich zugegriffen werden, daher ist keine Registierung notwendig.

Um ein 32 bit Image zu verwenden, nutzen wir den folgenden Befehl:

ec2-run-instances ami-xxxxx -k ec2-keypair

Um ein 64 bit Image zu verwenden, nutzen wir den folgenden Befehl:

ec2-run-instances ami-xxxxx -k ec2-keypair -t c1.xlarge

Dabei handelt es sich in beiden Fällen bei ami-xxxxx um die jeweilige AMI ID aus der oben aufgeführten Tabelle, sowie bei -t um den Typ des Images.

Um den status einer Instanz auszugeben benötigen wir den folgenden Befehl:

ec2-describe-instances

Um SSH Zugriff auf den Port 22 zu gestatten wird folgender Befehl benötigt.

ec2-authorize default -p 22

Um sich an der Instanz anzumelden nutzen wir diesen Befehl.

ssh -i /path/to/ec2-keypair.pem ubuntu@

Den external-host-name erhält man über den Befehl ec2-describe-instances.

Die Instanz beendet man am Ende mit dem folgenden Befehl.

ec2-terminate-instances 

Quelle

• EC2StartersGuide