Autor: Rene Buest

Rene Buest is Gartner Analyst covering Infrastructure Services & Digital Operations. Prior to that he was Director of Technology Research at Arago, Senior Analyst and Cloud Practice Lead at Crisp Research, Principal Analyst at New Age Disruption and member of the worldwide Gigaom Research Analyst Network. Rene is considered as top cloud computing analyst in Germany and one of the worldwide top analysts in this area. In addition, he is one of the world’s top cloud computing influencers and belongs to the top 100 cloud computing experts on Twitter and Google+. Since the mid-90s he is focused on the strategic use of information technology in businesses and the IT impact on our society as well as disruptive technologies.

Rene Buest is the author of numerous professional technology articles. He regularly writes for well-known IT publications like Computerwoche, CIO Magazin, LANline as well as Silicon.de and is cited in German and international media – including New York Times, Forbes Magazin, Handelsblatt, Frankfurter Allgemeine Zeitung, Wirtschaftswoche, Computerwoche, CIO, Manager Magazin and Harvard Business Manager. Furthermore Rene Buest is speaker and participant of experts rounds. He is founder of CloudUser.de and writes about cloud computing, IT infrastructure, technologies, management and strategies. He holds a diploma in computer engineering from the Hochschule Bremen (Dipl.-Informatiker (FH)) as well as a M.Sc. in IT-Management and Information Systems from the FHDW Paderborn.

Kategorien
News

Salesforce Chatter wird mobil

München, Mit Chatter Mobile bringt salesforce.com die Vorteile von Enterprise Social Networking auf mobile internetfähige Endgeräte. Die Social Media-Funktionen von Chatter Mobile erlauben es den Nutzern unternehmensintern von jedem Standort aus zusammenzuarbeiten und sich auszutauschen. In Echtzeit können Meldungen von (Team-) Kollegen oder Programmupdates verfolgt, Nachrichten verfasst und kommentiert, Dokumente und Bilder hochgeladen und der eigene Status aktualisiert werden. Damit schließt Chatter Mobile eine wichtige Kommunikationslücke im mobilen Arbeitsalltag, denn über E-Mails oder das Browsen im Internet war die mobile Zusammenarbeit in Echtzeit für Mitarbeiter bislang schwierig.

Salesforce Chatter stößt seit seiner Veröffentlichung im Juni dieses Jahres auf sehr positive Resonanz: Rund 20.000 Unternehmen weltweit setzen die Kollaboration-Anwendung aktuell schon ein. Zudem wurde Chatter bereits mehrfach für seine Innovationskraft ausgezeichnet.

Preise und Verfügbarkeit

  • Chatter Mobile für BlackBerry, iPad, iPhone und den neuen iPod touch werden voraussichtlich Ende 2010 verfügbar sein. Die Verfügbarkeit von Chatter Mobile for Android-Geräte ist derzeit für die erste Jahreshälfte 2011 geplant.
  • Salesforce Chatter und Salesforce Mobile sind Teil aller kostenpflichtigen Nutzungsrechte von Salesforce CRM und Force.com.

Weiterführende Informationen

Kategorien
Grundlagen

Das Konzept der AWS Netzwerksicherheit

Mit Amazon EC2 können Instanzen dynamisch hinzugefügt und entfernt werden. Diese Flexibilität kann die Konfiguration und Wartung der Firewall zunehmends erschweren, da Firewall-Regeln traditionell auf Basis von IP-Adressen, Subnetzbereiche oder DNS Hostnamen basieren.

Mit der Amazon EC2 Firewall werden Instanzen benutzerdefinierten Gruppen zugewiesen und für diese Gruppen dann Firewall Regeln definiert. Wird anschließend eine Instanz einer Gruppe hinzugefügt oder wieder entfernt, werden die entsprechenden Regeln der Gruppe für diese Instanz angewendet. Änderungen an den Regeln einer Gruppe werden automatisch für alle Mitglieder der Gruppe angewendet.

Security Groups

Eine Security Group definiert Firewall Regeln für die Instanzen. Diese Regeln legen fest, welcher eingehende Datenverkehr zur einer Instanz durchgelassen wird. Jeder weitere eingehende Datenverkehr wird geblockt und verworfen.

Die Regeln einer Security Group können jederzeit geändert werden. Neue Regeln werden automatisch für bereits ausgeführte Instanzen und Instanzen die in Zukunft gestartet werden, angewendet.

Es können bis zu 100 Security Groups erstellt werden.

Gruppen – Mitgliedschaft

Nachdem eine AMI Instanz gestartet wurde, kann diese beliebig vielen Security Groups zugeordnet werden.

Wurde bisher keine Security Group definiert, wird die Instanz automatisch der „default“ Group zugewiesen. Standardmäßig erlaubt diese Security Group den gesamten Datenverkehr aller Mitglieder dieser Gruppe und verwirft den Datenverkehr von anderen Gruppen und IP-Adressen. Die Regeln für die „default“ Group können den eigenen Anforderungen entsprechend angepasst werden.

Gruppen – Zugriffsrechte

Die Zugriffsrechte werden auf Basis von Quellen definiert. Dabei können die Quellen entweder benammte Security Groups oder IP-Adressen sein. Für CIDR basierte Regeln können zusätzlich das Protokoll und ein Port Bereich definiert werden.

Quelle

Kategorien
Kommentar

Cloud Computing ist der Sündenbock!

Wird Cloud Computing von dem Standpunkt der Sicherheit heraus mit einem einzigen Wort definiert, sind sich viele Protagonisten einig. Cloud Computing is a scapegoat, zu deutsch Sündenbock, Prügelknabe oder Buhmann.

Zurückzuführen ist diese Definition auf in vielen Fällen schlechte Medienberichte über vermeintliche Probleme aus dem Cloud Computing Bereich. Das Sidekick Disaster im vergangenen Jahr z.B. hat dem Cloud Computing damit einen Bärendienst erwiesen.

Allerdings sind wir uns alle einig, dass es sich bei dem Sidekick Disaster nicht um ein Cloud Computing Problem, sondern Probleme andersartiger Natur gehandelt hat. Aber wie die Medienlandschaft nun einmal funktioniert, geht es darum Leser zu erreichen, und viele Leser erhält man schließlich durch Überschriften die einen Thriller dahinter vermuten lassen. Ergo: Bevor man über Problematiken die mit Cloud Computing in Zusammenhang stehen könnten urteilt, sollte man sich über den tatsächlichen Hintergrund und über den Author und dessen Expertise informieren.

Sind wir mal ehrlich, sind Daten die sich in unserem Einflussbereich, wie z.B. dem eigenen Rechner oder dem Rechenzentrum wirklich sicherer als in der Cloud? Wissen IT Beauftragte tatsächlich, was sich auf den Firmen PCs/ Laptops lokal befindet? Dabei rede ich nicht von den Daten, sondern von der dort durch den Anwender installierten Software etc.. Und sind wir ehrlich, wie oft werden z.B. mobile Endgeräte gestohlen! Zählen wir allein diese Punkte – und es gibt noch wesentlich mehr – zusammen, sind traditionelle Systeme bzw. Lösungen nicht sicherer als Lösungen auf Basis von Cloud Computing!

Wie kann also Cloud Computing dem IT-Leiter bzw. IT-Sicherheitsbeauftragten dabei helfen ihre Umgebung hinsichtlich der Beschädigung von Daten, dem Diebstahl oder Verlust von sensiblen Daten, vor unberechtigtem Zugriff, der Compliance und der System-Verfügbarkeit schützen?

Zunächst sollte natürlich das Geschäftsmodell überprüft werden. Es macht keinen Sinn die Cloud zu adaptieren, wenn dadurch möglicherweise kein Nutzen entsteht. Bei Cloud Computing Technologien handelt es sich um moderne Architekturen, die den aktuellen Standards entsprechen und somit bzgl. den klassischen Sicherheitsproblemen sensibilisiert sind. Dennoch sollte die Sicherheit beim Aufbau oder der Adaption einer Cloud an erster Stelle stehen! Eine Cloud ist und sollte immer so konstruiert sein, dass sie u.a. den rechtlichen regionalen und globalen Rahmenbedinungen entspricht und weiterhin strategisch verteilt organisiert ist. Das bedeutet, dass die Daten nicht nur an einem einzigen Ort zentral gespeichert sind, sondern über mehrere Standorte hinweg repliziert werden.

Werden u.a. diese Eigenschaften beim Design einer eigenen Cloud bzw. bei der Entscheidung zur Adaption einer Cloud berücksichtigt, erhöht das Cloud Computing durch seine Zuverlässigkeit und Skalierbarkeit ganzheitlich die Sicherheit.

Kategorien
Events

Offizieller Teaser des CloudCamp Hamburg 2010 ist online.

Der offizielle Teaser des CloudCamp Hamburg 2010 wurde gestern veröffentlicht. Als offizieller Media Partner ist dieser ebenfalls auf CloudUser | Ξxpert zu sehen.

Weitere Informationen gibt es auf http://cloudcamp-hamburg.de.

Kategorien
Analysen

Cloud Computing und seine finanziellen Vorteile

Neben den viel diskutierten technischen Vorteilen des Cloud Computing gegenüber eines traditionellen Rechenzentrums, stehen natürlich auch die finanziellen Vorzüge im Vordergrund.

Investitionskosten und die Art der Ausgaben
In einem klassischen Rechenzentrum muss ein Unternehmen bzgl. der Hard- und Software Anschaffungen in Vorleistung gehen und weiterhin die gesamten Kapitalaufwendungen und die Kosten für den Betriebsaufwand übernehmen. Ein Cloud Computing Anbieter hingegen investiert gezielt in seine Infrastruktur, um diese als Dienstleistung anzubieten. Die Kapitalaufwendungen werden hier somit vom Unternehmen an den Cloud Anbieter abgegeben. Das Unternehmen zahlt daher nur die Kosten für den Betriebsaufwand, wenn diese anfallen.

Cash Flow und Operative Kosten
Wie bereits oben beschrieben, muss ein Unternehmen seine Server und die Software im Voraus anschaffen. Werden die Dienstleistungen von einem Anbieter aus der Cloud bezogen, entstehen nur dann Kosten, wenn der Dienst auch tatächlich verwendet wird. Hinsichtlich der operativen Kosten versucht ein Unternehmen ständig die Kosten für die Entwicklung, Bereitstellung, Wartung, etc. zu verringern. Dieser Aufwand entfällt durch den Bezug der Leistungen von einem Cloud Anbieter. In diesem Fall ist der Anbieter für den Lebenszyklus der Hardware-und Softwarekomponenten zuständig.

Finanzielle Risiken
Investitionen in ein eigenes Rechenzentrum werden zunächst immer im Voraus getroffen, wodurch ein Unternehmen allein dafür ein enormes finanzielles Risiko eingehen muss, ohne die Gewissheit zu besitzen, dass ein ROI dabei herauskommt. Werden die Dienste von einem Cloud Anbieter bezogen, verringert sich das finanzielle Risiko auf einen Zeithorizont von einem Monat, wodurch auch der ROI ebenfalls sehr zeitnah gemessen werden kann.

Trotz der immer wiederkehrenden Diskussion, dass es sich bei dem Nutzen von Cloud Computing lediglich um das verringern der Kosten handelt (“Cloud Value is only about Cost.”), wird dieser Mythos mit dem Statement “Cloud Value is about Business Agility, Opportunities and Investment” entkräftet. Denn Cloud Computing bietet deutlich mehr Vorteile und Möglichkeiten, als nur das Variabilisieren der Kosten, sondern ermöglicht es ein Unternehmen sich deutlich flexibler und agiler aufzustellen.

Kategorien
Grundlagen Services

Was bei der Nutzung von EC2 Instanzen zu beachten ist

Nachdem eine AMI gestartet wurde steht eine sogenannte Instanz bereit, die sich im Status „running“ befindet. Eine Instanz die zentrale Komponente, wenn es darum geht, in der Amazon Cloud Daten zu verarbeiten. Dazu stellt Amazon mehrere unterschiedliche Instanz Typen für unterschiedliche Einsatzszenarien zur Verfügung.

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

Kategorien
News

Anerkennung für salesforce.com

Anerkennung für salesforce.com

Auszeichnungen als Leader im Gartner Magic Quadrant und als eines der 100 am schnellsten wachsenden Unternehmen (Fortune)

München – Gute Nachrichten für salesforce.com: das Unternehmen wurde von Gartner im Führungsquadranten für Sales Force Automation positioniert. Nummer 4 wurde das Unternehmen bei der FORTUNE’s Liste der „100 Fastest-Growing Companies“.

Ein Leader ist für Gartner ein Unternehmen mit einer klaren, den Markt definierenden Vision, wie Technologie den Top Sales Executives helfen kann, ihre Ziele zu erreichen. Leader verfügen über die Produkte und Services, diese Vision umzusetzen, und sie können auf solide Geschäftsergebnisse in Form von Umsatz und Gewinn verweisen. Sie haben signifikante und erfolgreiche Implementierungen bei Kunden in Nordamerika, EMEA und Asia/Pacific in vielen Branchen für mehr als 500 Anwender.

Um sich für die Liste von Fortune zu qualifizieren muss ein Unternehmen einige strenge Kriterien erfüllen und wird dann nach seiner Umsatzwachstumsrate, seinem EPS-Anstieg und seinem auf drei Jahre gesehenen Gesamtumsatz (gemessen bis zum 30. Juni 2010) bewertet.

Kategorien
Grundlagen Services

Das Konzept hinter den AWS Regionen und Verfügbarkeitszonen

Amazon EC2 bietet die Möglichkeit, Instanzen über mehrere Standorte zu verteilen. Dabei sind die Standorte in Verfügbarkeitszonen (Availability Zones) und Regionen aufgeteilt. Die Regionen sind verstreut und befinden sich in getrennten geographischen Gebieten wie den USA und Europa. Verfügbarkeitszonen sind verschiedene Standorte innerhalb einer Region, die so konstruiert sind, dass sie isoliert betrieben werden und von Fehlern in anderen Verfügbarkeitszonen nicht betroffen sind. Dazu bieten sie eine kostengünstige Konnektivität mit einer geringen Netzwerklatenz zu anderen Verfügbarkeitszonen in der gleichen Region.

Durch das Starten von Instanzen in separaten Regionen, können Web Anwendungen so konstruiert werden, dass sich diese geographisch in der Nähe von bestimmten Kunden befinden und rechtlichen oder anderen Anforderungen gerecht werden.

Weiterhin werden Anwendungen vor dem Ausfall eines einzelnen Standorts geschützt, indem Instanzen in separaten Verfügbarkeitszonen ausgeführt werden.

Die folgende Graphik zeigt eine Darstellung der Amazon EC2 Regionen und Verfügbarkeitszonen. Jede Region ist völlig unabhängig. Jede Verfügbarkeitszone ist vollständig isoliert, aber durch Netzwerkverbindungen mit einer geringen Latenz mit anderen Verfügbarkeitszonen verbunden.

Regionen

Amazon EC2 verfügt über mehrere Regionen, wodurch EC2 Instanzen an den Standorten ausgeführt werden können, die den eigenen Anforderungen entsprechen. Um z.B. als nicht europäisches Unternehmen Kunden in Europa Dienstleistungen anzubieten und zudem den dort gesetzlichen Anforderungen gerecht zu werden, können die EC2 Instanzen in einer Verfügbarkeitszone der Region Europa ausgeführt werden.

Jede Amazon EC2 Region ist so konstruiert, dass sie vollständig isoliert von allen anderen Amazon EC2 Regionen betrieben wird. Damit wird die größtmögliche Unabhängigkeit und Stabilität erzielt und macht den Ort einer jeden EC2 Ressource eindeutig.

Um Instanzen zu starten oder mit diesen zu arbeiten, muss zunächst die korrekte URL eines Endpunkts einer Region definiert werden. Soll z.B. eine Instanz in der Region US-East (Standard Region) betrieben werden, wird als Endpunkt URL ec2.us-east-1.amazonaws.com verwendet.

In der folgenden Tabelle sind alle Regionen mit ihren zugehörigen Endpunkten dargestellt.

Region Endpoint
US-East (Northern Virginia) Region ec2.us-east-1.amazonaws.com
US-West (Northern California) Region ec2.us-west-1.amazonaws.com
EU (Ireland) Region ec2.eu-west-1.amazonaws.com
Asia Pacific (Singapore) Region ec2.ap-southeast-1.amazonaws.com

Verfügbarkeitszonen

Fehler können auftreten, die Auswirkungen auf die Verfügbarkeit von Instanzen haben, die sich an dem gleichen Standort befinden. Auch wenn das ziemlich selten vorkommt – wenn alle Amazon EC2 Instanzen an einem einzigen Standort gehostet werden, der von einer Störung betroffen ist, sind diese Instanzen nicht mehr verfügbar.

Sind z.B. Instanzen über drei Verfügbarkeitszonen verteilt und eine dieser Instanzen fällt aus, kann eine Anwendung zu konzipiert werden, dass die Instanzen in den übrigen Verfügbarkeitszonen die Anfragen automatisch entgegennehmen und verarbeiten.

Quelle

Kategorien
Analysen

Wir brauchen eine transparente Cloud!

Stellen wir uns das folgende Szenario vor:

Wir haben unsere IT Infrastruktur erfolgreich in die Cloud eines Anbieters migriert. Alles bestens, wir sagen uns: „Super, alles funktioniert einwandfrei! Wir senken unsere Kosten. Unsere Infrastruktur ist nun so skalierbar, dass sie unseren Anforderungen immer gerecht wird. Uns stehen immer die aktuellen Software Versionen zur Verfügung und wir können von jedem Ort unabhängig von den lokalen Systemen miteinander kollaborieren.“

Was machen wir aber, falls wir uns nun doch dazu entscheiden wieder in das eigene Rechenzentrum zurückzukehren oder den Cloud Anbieter zu wechseln, weil dieser z.B. günstiger ist? Oder gehen wir noch einen Schritt weiter. Wie können wir unsere gesamten Geschäftsprozesse in der Cloud über mehrere Anbieter hinweg verteilt abbilden? Stellen wir uns vor, dass ein Anbieter den Prozess A verarbeitet, ein weiterer den Prozess B. Ein dritter Anbieter verarbeitet den Prozess C und nutzt dabei die Prozesse A und B. Oder wir verwenden eine Vielzahl voneinander unabhängiger Services von unterschiedlichen Anbietern und integrieren diese zu einem einzigen Service. Wir wir sehen, sind der Komplexität keine Grenzen gesetzt. Ein vermeintlich einfacheres Beispiel: Unsere Daten sind bei dem Anbieter A gespeichert und ein Anbieter B soll diese Daten verarbeiten.

Ist das möglich?

Ein weiterhin sehr kritischer Punkt des Cloud Computing ist das Fehlen von Standards. Jeder Anbieter verwendet unterschiedliche Technologien und kocht innerhalb seiner Infrastruktur seine eigene Suppe. Die meisten Anbieter versuchen in der Regel mittels des gefürchteten Vendor-Lockin ihre Kunden „an sich zu binden“. Denn leider haben es bisher die Wenigsten verstanden, Kunden über guten Service und weitere Dienstleistungen von sich abhängig zu machen.

Aus diesem Grund ist jede Beziehung zwischen einem Anbieter und seinem Kunden anders und eine anbieterübergreifende Zusammenarbeit – die für einen Kunden in vielen Fällen unerlässlich ist – kann nicht stattfinden.

Wir brauchen eine transparente Cloud!

Ein möglicher Ansatz wäre libcloud (http://libcloud.org). Dabei handelt es sich um eine Standard Bibliothek u.a. für Anbieter wie Amazon, Rackspace oder Slicehost, die eine einheitliche API bereitstellt. Sie ist in Python implementiert und kostenlos (Apache License 2.0) zu nutzen, um mit unterschiedlichen Cloud Anbietern zu kommunizieren.

libcloud

Allerdings ist die libcloud Bibliothek nur ein Ansatz. Wir müssen, wenn wir von Cloud Standards reden, uns auf eine noch wesentlich tieferer Ebene begeben. Was ich damit sagen will ist, dass ein Cloud Anbieter sich selber in die Pflicht nehmen muss und seine Schnittstellen so offen und sorgfältig zu dokumentieren, dass ein Wechsel oder eine Integration unterschiedlicher Services, Prozesse etc. zwischen verschiedenen Anbietern ohne weiteres möglich ist.

Ein Kunde muss mit einem guten Gefühl seine Daten, Prozesse etc. zu einem Cloud Anbieter auslagern, weil er sich sicher sein kann über diese frei zu verfügen und einen Wechsel sowie eine Integration sorgenfrei vornehmen zu können.

Kategorien
Grundlagen Services

Das Konzept des Amazon Elastic Block Store

Der Amazon Elastic Block Store (Amazon EBS) ist eine spezielle Speicherart, die speziell für Amazon EC2 Instanzen konstruiert wurde. Mit Amazon EBS können Volumes erstellt werden, die von Amazon EC2 Instanzen wie externe Geräte eingebunden (gemounted) werden können. Amazon EBS Volumes verhalten sich wie unformatierte externe Block-Devices. Sie können durch den Benutzer benamt werden und stellen eine Block-Device-Schnittstelle bereit. EBS Volumes können mit einem Dateisystem ausgestattet oder wie ein gewöhnliches Block-Device genutzt werden.

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