Tag: Infrastructure as a Service


Servicearten des Cloud Computing (Redux)

Im Cloud Computing existieren grundsätzlich drei verschiedene Arten Dienstleistungen bereitzustellen. Da diese aufeinander aufbauen, wird in diesem Zusammenhang auch von Schichten gesprochen. Anhand dieses Drei-Schichten Modells ergeben sich Möglichkeiten neue Geschäftsmodelle zu entwickeln.

Infrastructure-as-a-Service

Infrastructure-as-a-Service (IaaS) bildet die unterste Schicht des Cloud Computing Service-Modells. Sie ist die Grundlage und stellt die grundlegenden Dienste wie Speicherplatz und Rechenkapazität bereit. Hier wird die Basis-Infrastuktur wie Hardware für Server, Speicherplatz aber auch Router und Switches – mittels Virtualisierung – bereitgestellt. Die gesamte Infrastruktur ist so skaliert, dass sie in Zeiten von Spitzenlast dynamisch erweitert wird und somit unterschiedlichen Auslastungen angepasst werden kann. Bei IaaS ist der Drittanbieter lediglich für die Bereitstellung und Wartung der Hardware zuständig. Alle anderen benötigten Ressourcen wie z.B. das Betriebssystem, Anwendungen etc. obliegen dem Kunden.

Platform-as-a-Service

Platform-as-a-Service (PaaS) bildet die mittlere Schicht des Cloud Computing Service-Models und ist dafür zuständig, eine transparente Entwicklungsumgebung bereitzustellen. Dabei stellt der Drittanbieter eine Plattform zur Verfügung, auf der (Web)-Anwendungen entwickelt, getestet und gehostet werden können. Die Applikationen werden anschließend auf der Infrastruktur des Anbieters ausgeführt und nutzen dessen Ressourcen. Der vollständige Lebenszyklus einer Anwendung kann darüber vollständig verwaltet werden. Über APIs können die Dienste auf der Plattform des jeweiligen Anbieters angesprochen werden. Der Vorteil besteht darin, dass vor allem kleine Unternehmen ihre Entwicklungsinfrastruktur auf ein Minimum beschränken können. Sie benötigen lediglich einen Desktop-PC, einen Web-Browser, evtl. eine lokale IDE, eine Internetverbindung und ihr Wissen, um Anwendungen zu entwickeln. Der Rest obliegt dem Drittanbieter, der für die Infrastruktur (Betriebssystem, Webserver, Entwicklungsumgebung etc.) verantwortlich ist.

Software-as-a-Service

Software-as-a-Service (SaaS) ist die oberste Schicht des Cloud Computing Service-Modells. Sie stellt dem Anwender vollständige Anwendungen bereit. Dadurch kann sie als eine Art Distributionsmodell verstanden werden, bei dem die Nutzung von Software über das Internet von einem Drittanbieter angeboten wird. Der Drittanbieter übernimmt dabei u.a. Hosting und die Wartung der Software. Für den Anbieter besteht der Vorteil darin, dass nur eine Instanz einer Software auf den Servern bereitgestellt werden muss, welche unzählige Anwender gleichzeitig nutzen können. Wird die Software auf einen aktuellen Stand gebracht, genügt ein Update Vorgang an zentraler Stelle und die Software ist für alle Anwender gleichzeitig aktuallisiert. Der Vorteil für den Anwender besteht darin, dass lediglich – wie schon bei PaaS – nur ein Desktop-PC, ein Web-Browser und eine Internetverbindung ausreichen um z.B. Dienste wie E-Mail, Office Anwendungen oder sogar ERP-Systeme nutzen zu können. Die Anschaffung und Wartung großer Serverlandschaften bzw. Softwarepakete entfällt ebenso wie das Updaten der lokalen Anwendungen. Der Drittanbieter sorgt immer für einen aktuellen Stand der Software und stellt die gesamte Infrastruktur für das Hosting der Software bereit. Dazu gehören auch das Speichern von Dateien (Dokumenten) auf den Servern des Anbieters. Der Anbieter ist demnach für alle notwendigen Bereiche des Betriebs wie Verfügbarkeit, Backup, Redundanzen und auch die Stromversorgung verantwortlich.



T-Systems geht in die Cloud

Mit einer kostenlosen Testphase für bereits vorhandene Unternehmenskunden startet nun auch T-Systems als ein großes deutsches Unternehmen mit einem Infrastructure as a Service Angebot in die Cloud. Die Pilotphase beginnt noch im November 2010 und wird im Februar 2011 enden.

Mit diesem Angebot wird T-Systems in direkter Konkurrenz zu den Amazon Web Services stehen. Das könnte Erfolg versprechend sein, wird alleine die finanzielle Kraft von T-Systems betrachtet.

T-Systems stützt sich vor allem auf die oft diskutierten Bereiche Zugriffskontrolle, Datenschutz und Datensicherheit, sowie die Service Level Agreements (SLAs). Alles im Hinblick auf eine höchstmögliche Skalierbarkeit.

Alle Rechenzentren und damit sämtliche Daten des Kunden werden sich in Deutschland befinden und nach der ISO Sicherheitsnorm 27001 zertifiziert und können darüber hinaus ebenfalls von den Kunden selbst auditiert werden.



Erste Schritte mit der domainFACTORY “JiffyBox”

Nach der Vorstellung und weiteren Hintergrundinformationen zur domainFACTORY “JiffyBox”, gibt dieses Tutorial einen Einblick in das Innere. Dazu habe ich von der domainFACTORY GmbH einen kostenlosen Testzugang erhalten, für den ich mich auf diesem Wege bedanken möchte!

Erstellen einer JiffyBox

Zunächst melden wir uns dazu unter https://admin.jiffybox.de mit einem gültigen Benutzernamen und Passwort an, die wir unter https://www.jiffybox.de beantragen können.

Nach einer erfolgreichen Anmeldung werden wir im Control Panel begrüßt, wo wir im ersten Schritt mittels "Jetzt Trial-Server bestellen" einen kostenlosen Test der JiffyBox vornehmen können oder uns über "Neue JiffyBox erstellen" eine neue JiffyBox erzeugen. Wir wählen hier den zweiten Schritt.

Wir geben der neuen JiffyBox einen Namen, wählen einen Tarif, hier "CloudLevel 1 - mit 1 GB Arbeitsspeicher und 50 GB Festplatte für 0,02 € / Stunde" und eine Linux Distribution, hier "Ubuntu 10.04 LTS". Würden wir bereits über eine JiffyBox verfügen, hätten wir als Distribution ebenfalls ein Backup als Quelle angeben können.

Unter dem Punkt "Erweitert" können wir der JiffyBox ein selbst gewähltes Root Passwort zuweisen. Anschließend wählen wir "Erstellen".

Die JiffyBox wird nun automatisch im Hintergrund erzeugt. Statusinformationen zeigen dabei den aktuellen Vorgang!

Zurück im "Control Panel" sehen wir die erzeugte JiffyBox und können nun mittels "Konfigurieren" weitere Einstellungen vornehmen, die JiffyBox "Starten", "Einfrieren" oder wieder vollständig "Löschen".

Hinter dem Menüpunkt "Voreinstellungen" verbirgt sich das Schlüsselmanagement, wo wir mehrere SSH-Public-Keys eintragen können.

Über den Punkt "Alle Meldungen" gelangen wir in den Statusbereich. Hier erhalten wir detailliert alle Informationen zu allen Vorgängen innerhalb unseres Accounts.

Weitere Informationen

Über den Menüpunkt "Account" gelangen wir direkt zu den Stammdaten.

Weiterhin können wir über "Kundenservice" direkt elektronischen Kontakt zu dem domainFACTORY Support aufnehmen und erhalten einen historischen Überblick über alle bisherigen Anfragen.

Wir können zusätzlich über den Menüpunkt "Passwörter", unsere Passwörter für das JiffyBox Control Panel und dem Telefon Support eigenständig ändern. Zudem erhalten wir einen Überblick über alle bisher gestellten Rechnungen durch domainFACTORY über den Punkt "Rechnungen".

Der Menüpunkt "Verbräuche" gibt einen genauen Überblick zu den bisher entstandenen Kosten zu allen JiffyBoxen und dem verbrauchten Traffic.

Weiterhin erhalten wir einen detaillierten Überblick über die Nutzung jeder einzelnen, in unserem Account vorhandenen, JiffyBox.

Sowie vom derzeit verbrauchten Traffic.

Ein weiteres interessantes Feature ist die Möglichkeit zur Begrenzung der Kosten. Hier kann ein Betrag (in EUR) als Obergrenze eingetragen werden und die Folgeaktion, die stattfinden soll, wenn der Betrag erreicht wird.

Um die JiffyBox über Skripte zu steuern, haben wir über den Menüpunkt "API-Zugriff" die Möglichkeit, einen API-Token zu erzeugen. Weitere Informationen für die Nutzung der API sind in der PDF-Datei "JiffyBox-API" zu finden.

Arbeiten mit der JiffyBox

Zurück im Control Panel wollen wir nun ein Blick hinter die Konfigurationsmöglichkeiten einer JiffyBox werfen. Wie wir sehen werden, stehen uns dazu viele Möglichkeiten zur Verfügung. Wir wählen dazu unter "Ihre JiffyBoxen" die Aktion "Konfigurieren".

Wir erhalten zunächst einen Überblick zu allen notwendigen Informationen, wie der aktuellen IP-Adresse und dem aktuellen Hostnamen, dem genutzten Tarif, dem verfügbaren Arbeitsspeicher und der Festplattengröße, sowie der für diese JiffyBox verwendeten Linux Distribution.

Über "Profile und Festplatten" können wir weitere Konfigurationen am System, der Festplattengröße und deren Zuordnung vornehmen.

Hinter "Netzwerk" verbergen sich weitere Informationen zu den IP und DNS Informationen. Hier haben wir die Möglichkeit den "Reverse-DNS" Namen zu ändern und eine weitere IP-Adresse zu bestellen.

Von jeder JiffyBox werden automatisch tägliche Backups erstellt. Dennoch haben wir die Option über den Menüpunkt "Backups" ein manuelles Backup zu starten, bzw. eigene Backup Pläne zu erstellen.

Über "Konsole und Recovery" steht uns der Zugriff mittels einer Web-Konsole und per SSH-Konsole zur Verfügung. Weiterhin kann ein Recovery-System aktiviert werden, um die JiffyBox im Notfallmodus zu starten.

Um die JiffyBox nun zu nutzen, wählen wir im Control Panel unter "Ihre JiffyBoxen" lediglich "Starten".

Mittels eines SSH-Clients, hier Putty, verbinden wir uns mit der JiffyBox. Die dazu benötigte IP-Adresse bzw. den DNS-Namen erhalten wir unter dem Menüpunkt "Netzwerk" in dem Konfigurationsbereich der JiffyBox.

Anschließend melden wir uns mit dem Benutzer "root" und dem von uns bei dem Erstellen der JiffyBox unter "Erweitert" gewählten Passwort an.

Damit sind wir mit unserer ersten eigenen JiffyBox verbunden.

Um die JiffyBox wieder zu beenden, wählen wir im Control Panel für die entsprechende JiffyBox "Stoppen".

Und dann "Herunterfahren".

Die JiffyBox wird anschließend automatisch heruntergefahren. Eine Statusmeldung informiert uns über den erfolgreichen Vorgang.

Die JiffyBox kann anschließend wieder angepasst, gestartet, eingefriert oder gelöscht werden.

Die Verbrauchsanzeige informiert uns darüber, dass für eine Gesamtdauer von 1:33:36 Stunden bisher 0,03 EUR entstanden sind.



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



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



Das Amazon EC2 Adressierungskonzept

Dieser Artikel beschreibt das Adressierungskonzept von Amazon EC2. Das beinhaltet die Arten von IP-Adressen, die für EC2 Instanzen zur Verfügung stehen.

Alle Amazon EC2 Instanzen erhalten während des Starts zwei IP Adressen zugewiesen. Eine private Adresse (RFC 1918) und eine öffentliche Adresse (public), die mittels Network Address Translation (NAT) direkt aufeinander abgebildet werden. Private Adressen sind nur innerhalb des Amazon EC2 Netzwerks erreichbar. Öffentliche Adressen hingegen sind aus dem Internet erreichbar.

Weiterhin stellt Amazon EC2 einen internen, sowie einen öffentlichen DNS Namen zur Verfügung, der jeweils der privaten bzw. öffentlichen IP-Adresse zugewiesen wird. Der interne DNS Name kann nur innerhalb des Amazon EC2 Netzwerk aufgelöst werden. Der interne DNS Name kann nur innerhalb des Amazon EC2 Netzwerk aufgelöst werden. Der öffentliche DNS Name hingegen löst die öffentliche IP-Adresse außerhalb des Amazon EC2 Netzwerks und die private IP-Adresse innerhalb des EC2 Netzwerks auf.

Private Adressen (RFC 1918)

Alle Amazon EC2-Instanzen erhalten eine private Adresse per DHCP zugewiesen. Die Adressbereiche sind in RFC 1918 definiert und können nur innerhalb des Amazon EC2 Netzwerks gerouted werden. Die privaten IP-Adressen werden für die Kommunikation zwischen den jeweiligen Instanzen verwendet.

Die private Adresse ist mit einer Instanz solange verknüpft, bis diese Instanz wieder beendet wird. Anschließend wird die Adresse wieder an Amazon EC2 zurückgegeben und kann dann erneut an eine andere Instanz vergeben werden.

Es sollte darauf geachtet werden, dass immer die internen Adressen verwendet werden, wenn zwischen Amazon EC2 Instanzen kommuniziert wird. Damit ist sichergestellt, dass der Datenverkehr immer mit der höchsten Bandbreite übertragen wird und die Latenz innerhalb des Amazon EC2 Netzwerks so gering wie möglich ist.

Interner DNS Name

Jede Instanz verfügt über einen internen DNS Namen, der zu der entsprechenden privaten IP-Adresse der Instanz innerhalb des Amazon EC2 Netzwerks aufgelöst wird. Der interne DNS Name wird nicht ausserhalb von Amazon EC2 aufgelöst.

Öffentliche Adressen

Während des Starts wird eine öffentliche Adresse einer EC2 Instanz mittels Network Address Translation (NAT) zugewiesen. Die öffentliche Adresse ist mit einer Instanz solange verknüpft, bis diese Instanz wieder beendet wird oder durch eine Elastic IP-Address ausgetauscht wird.

Kommunizieren Instanzen mit anderen Instanzen über ihre öffentliche IP Adresse entstehen zusätzliche Kosten, basierend auf regionalen oder dem Internet Datenverkehr, je nachdem ob sich die Instanzen in der selben Region befinden.

Öffentlicher DNS Name

Jede Instanz verfügt über einen externen DNS Namen, der zu der entsprechenden öffentlichen IP-Adresse der Instanz ausserhalb des Amazon EC2 Netzwerks und von innerhalb des EC2 Netzwerks aufgelöst wird.

Quelle




Der Amazon EC2 Instanzspeicher

Jede Instanz verfügt über eine festen Speicherplatz, auf dem Daten gespeichert werden können. Dieser wird im EC2 Kontext als Instanzspeicher bezeichnet und ist nicht als permanente Speicherlösung gedacht.

Wird eine Instanz neu gestartet, bleiben die Daten auf dem Instanzspeicher bestehen. Wird die Instanz higegen beendet, gestoppt oder ein Fehler tritt auf, dann sind die Daten verloren.

Für den Einsatz einer dauerhaften Speicherlösung empfiehlt Amazon daher Amazon Elastic Block Store.

Sollte Amazon EBS nicht eingesetzt werden, sollten wichtige Daten auf Amazon S3 gesichert werden.

Speicherort

Wo sich der Speicher auf den jeweiligen Instanz Typen befindet, kann der folgenden Tabelle entnommen werden.

Ort
Beschreibung
/dev/sda1 Auf allen Linux/Unix Instanz Typen als root (/) formatiert und gemounted. Auf allen Windows Instanz Typen als C:\ formatiert und gemounted.
/dev/sda2 oder xvdb (Windows) Auf allen m1.small und c1.medium Instanzen als /mnt formatiert und gemounted. Auf allen small Windows Instanzen formatiert und gemounted.
/dev/sda3 Auf allen m1.small und c1.medium Instanzen für Linux/Unix Instanz Typen als /swap formatiert und gemounted. Für Windows Instanzen nicht verfügbar.
/dev/sdb oderr xvdb (Windows) Auf allen m1.large, m1.xlarge, c1.xlarge, m2.xlarge, m2.2xlarge, und m2.4xlarge Instanzen für Linux/Unix Instanz Typen als /mnt formatiert und gemounted. Für alle m1.large, m1.xlarge, c1.xlarge, m2.xlarge, und m2.2xlarge Windows Instanzen formatiert und gemounted.
/dev/sdc oder xvdc (Windows) Verfügbar auf m1.large, m1.xlarge und c1.xlarge Linux/Unix Instanzen. Auf m1.large, m1.xlarge, c1.xlarge und m2.4xlarge Windows Instanzen formatiert und gemounted.
/dev/sdd or xvdd (Windows) Verfügbar auf m1.xlarge und c1.xlarge Linux/UNIX Instanzen. Auf m1.xlarge und c1.xlarge Windows Instanzen formatiert und gemounted.
/dev/sde or xvde (Windows) Verfügbar auf m1.xlarge und c1.xlarge Linux/Unix Instanzen. Auf m1.xlarge und c1.xlarge Windows Instanzen formatiert und gemounted.

Quelle



Amazon Machine Images (AMI)

Eine Amazon EC2 Instanz kann auf Basis eines Amazon Machine Image (AMI) welches sich in Amazon EBS befindet oder eines AMI welches in Amazon S3 gespeichert ist gestartet werden. Dabei verwenden Instanzen, bei denen die AMIs in Amazon EBS gespeichert sind, EBS Volumes als Root Device (von wo gebooted wird). Dagegen nutzen Instanzen, deren AMIs in Amazon S3 abgelegt sind einen Instanzspeicher als das Root Device.

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

Eigenschaften
Amazon EBS
Amazon S3 (Instanzspeicher)
Bootzeit Gewöhnlich weniger als 1 Minute. In der Regel weniger als 5 Minuten.
Größenbeschränkung 1 Terrabyte (TB) 10 Gigabyte (GB)
Speicherort Amazon EBS volume Instanzspeicher
Datenpersistenz Die Daten bleiben vorhanden, wenn die Instanz ausfällt und können gespeichert werden, wenn die Instanz beendet wird. Die Daten bleiben nur für die Lebensdauer der Instanz erhalten.
Erweiterung Der Instanz-Typ, Kernel, die RAM Disk und die Benuterdaten können geändert werden, während die Instanz gestoppt (angehalten) ist. Die Attribute einer Instanz sind für ihre Lebensdauer festgesetzt und können währenddessen nicht geändert werden.
Kosten Instanz Nutzung, Amazon EBS Volume Nutzung und Amazon EBS Snapshot Kosten zum Speichern der AMI. Instanz Nutzung und Amazon S3 Kosten zum Speichern der AMI.
AMI Erstellung / Bundling Verwendet einen einzigen Befehl / Anweisung Erfordert die Installation und die Nutzung der AMI Tools
Stoppen / Anhalten Kann in den Zustand "angehalten" überführt werden, wenn eine Instanz nicht ausgeführt wird, aber in Amazon EBS gespeichert ist. Kann nicht gestoppt werden, Instanzen werden ausgeführt oder nicht.

Ö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



Der Amazon EC2 Workflow

Die folgende Graphik verdeutlicht den grundsätzlichen Ablauf zum Verwenden von Amazon EC2.

  • 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 mit Ubuntu Images (erste Schritte)

Dieser Artikel beschreibt die Nutzung der offiziellen Ubuntu Images unter Amazon EC2.

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

Continue reading “Amazon EC2 mit Ubuntu Images (erste Schritte)” »



Das Konzept der Amazon Virtual Private Cloud

Bei der Amazon Virtual Private Cloud (VPC) handelt es sich um eine sichere und lückelose Integrationsmöglichkeit zwischen der bereits vorhandenen IT Infrastruktur eines Unternehmens und der Amazon Cloud und dient zum Aufbau einer Hybrid Cloud. Mit Amazon VPC können Unternehmen ihre existierende Infrastruktur mit speziell isolierten AWS Ressourcen mittel eines Virtual Private Network (VPN) verbinden, um damit die Verwaltungsmögklichkeiten wie die Bereiche Sicherheit, Firewall und Intrusion Dection für die AWS Ressourcen zu erweitern.

Um die Amazon Virtual Private Cloud zu nutzen, muss zunächst der IP-Adressraum für die VPC festgelegt werden. Die IP-Adressen innerhalb dieses Adressraums sind privat und bilden ein Netzwerk das mittels paketbasierten Routing von anderen Netzwerken inkl. dem Internet vollständig isoliert ist.

Als nächstes müssen Subnetze erstellt werden, welche Segmente eines VPC IP-Adressraums sind. Damit können die Amazon EC2 Instanzen innerhalb des VPC separiert und sicher betrieben werden. Existiert mehr als ein Subnetz in einem VPC, werden diese mittels eines logischen Routers sternförmig (Stern-Topologie) miteinander verbunden.

Um sich mit der VPC zu verbinden, wird eine VPN Verbindung benötigt, die als VPN Tunnel zwischen der VPC und dem Rechenzentrum, dem Heimnetzwerk oder jeder anderen Co-Location dient. Dazu muss das eigene bestehende Netzwerk so konfiguriert werden, dass jeglicher VPC Datenverkehr zu dem Gateway geroutet wird, welches das Ende der VPN Verbindung darstellt.

Mit einer aktiven VPN Verbindung können anschließend Amazon EC2 Instanzen in einem VPC subnetz starten. Mit den entsprechenden Sicherheitsrichtlinen ist diese Instanz dann ebenfalls im eigenen Netzwerk sichtbar und kann von dort aus wie eine "lokale" Instanz genutzt werden.

VPC basierter Datenverkehr der für das Internet bestimmt ist, wird zunächst automatisch über das VPN in das eigene Netzwerk gerouted. Dort kann dieser von bereits vorhandenen Sicherheitssystemen, wie Firewalls, Intrusion Detection Systemen untersucht werden, bevor die Daten in das Internet weitergeleitet werden. Das ist dann besonders sinnvoll, wenn spezielle Hardware- und Softwaresysteme eingesetzt werden, um bestimmte Sicherheitsrichtlinien zu erfüllen.

Quelle



Die Amazon S3 Konsole

Mit der Amazon S3 Konsole hat Amazon seine AWS Management Console erweitert. Wie schon von den bisherigen Konsolen, wie z.B. der für EC2 bekannt, handelt es sich um eine Weboberfläche, mit der sämtliche Amazon S3 Ressourcen verwaltet werden können. Dazu gehören das Erstellen neuer Buckets sowie das Hochladen von Objekten.

Um die Amazon S3 Konsole zu nutzen, reicht es aus sich mit seinem AWS Benutzeraccount und dem dazugehörigen Passwort anzumelden. Die Access Key ID und der Secrect Access Key werden nicht benötigt, diese werden automatisch durch AWS im Hintergrund geladen.

Damit integriert die AWS Management Console mit Amazon S3, Amazon EC2, Amazon CloudFront, Amazon Elastic MapReduce und Amazon RDS nun fünf Services an einer zentralen Stelle.

Mit der Amazon S3 Konsole können weiterhin Ordner angelegt, sowie Objekte der Öffentlichkeit zugänglich gemacht werden. Ordner und Objekte die mit S3 Tools von einem Drittanbieter erstellt wurden, können mit der Konsole ebenfalls bearbeitet werden.

Die Amazon S3 Konsole ist unter http://console.aws.amazon.com/s3 zu finden.



UEC: Zusammenstellen von Images für Ubuntu 9.10

Dieser Artikel beschreibt das Vorgehen (Bundling) für das Erstellen und die Registrierung von VM Images mit dem UEC Cloud Controller für Ubuntu 9.10. Dazu benötigen wir ein Image, dass von den Daily Builds heruntergeladen werden kann, verknüpfen alles miteinander und laden es in unsere Ubuntu Cloud.

1. Um den Vorgang von der Kommandozeile aus zu starten nutzen wird die folgenden Befehle. Hierbei wird automatisch ein UEC Image heruntergeladen.

TIMESTAMP=$(date +%Y%m%d%H%M%S)
RELEASE=karmic
ARCH=amd64 # Or this might be i386
[ $ARCH = "amd64" ] && IARCH=x86_64 || IARCH=i386
UEC_IMG=$RELEASE-server-uec-$ARCH
URL=http://uec-images.ubuntu.com/$RELEASE/current/
[ ! -e $UEC_IMG.tar.gz ] && wget $URL/$UEC_IMG.tar.gz # This may take a bit, depending on your connectivity

2. Als nächstes muss alles verpackt, hochgeladen und registriert werden. In dem Package cloud-utils befindet sich das Tool uec-publish-tarball. Mit diesem können die oben genannten Aktionen in einem Schritt durchgeführt werden. Weiterhin ist in den cloud-utils das Tool uec-publish-image vorhanden. Mit diesem kann direkt mit einem ungepackten Image gearbeitet werden.

uec-publish-tarball ${UEC_IMG}.tar.gz "${RELEASE}-${TIMESTAMP}" "${ARCH}"

Diese Schritte sind nur dann notwendig, wenn nicht das Tool uec-publish-tarball verwendet wird!

1. Entpacken des UEC Image Tarball

[ ! -e $UEC_IMG.img ] && tar -S -xzf $UEC_IMG.tar.gz

2. Zusammenstellen des Kernels

BUCKET_KERNEL="k-$TIMESTAMP"
UEC_KERNEL=$UEC_IMG-vmlinuz-virtual
euca-bundle-image -i $UEC_KERNEL -r $IARCH --kernel true
euca-upload-bundle -b $BUCKET_KERNEL -m /tmp/$UEC_KERNEL.manifest.xml
EKI=$(euca-register $BUCKET_KERNEL/$UEC_KERNEL.manifest.xml | grep "^IMAGE" | awk '{print $2}') && echo $EKI

3. Zusammenstellen der initrd (Wird nur benötigt, wenn keine Ramdisk vorhanden ist)

BUCKET_INITRD="r-$TIMESTAMP"
UEC_INITRD=$UEC_IMG-initrd-virtual
euca-bundle-image -i $UEC_INITRD -r $IARCH --ramdisk true
euca-upload-bundle -b $BUCKET_INITRD -m /tmp/$UEC_INITRD.manifest.xml
ERI=$(euca-register $BUCKET_INITRD/$UEC_INITRD.manifest.xml | grep "^IMAGE" | awk '{print $2}') && echo $ERI

4. Zusammenstellen des Images

BUCKET_IMAGE="i-$TIMESTAMP"
UEC_IMG=$RELEASE-server-uec-$ARCH
euca-bundle-image -i $UEC_IMG.img -r $IARCH --kernel $EKI ${ERI:+--ramdisk ${ERI}} # This will take a long time (~10m)
euca-upload-bundle -b $BUCKET_IMAGE -m /tmp/$UEC_IMG.img.manifest.xml
EMI=$(euca-register $BUCKET_IMAGE/$UEC_IMG.img.manifest.xml | grep "^IMAGE" | awk '{print $2}') && echo $EMI

3. Damit ist der Kernel und das Image in unsere Ubuntu Cloud (Eucalyptus) hochgeladen worden und kann nun genutzt werden.

euca-describe-images

Wir sollten einen registrierten Kernel sowie ein Image sehen, die als "available" markiert sind.

Mit dem anschließenden Befehl können wir das überprüfen.

Quelle



Eucalyptus: Erstellen eines Image aus einem ISO (Xen)

Dieser Artikel beschreibt, wie mittels Xen und dem ISO Image eines Gast Betriebssystems das installiert werden soll, ein Root Dateiystem für Eucalyptus erstellt wird.

Voraussetzung

  • Hardware Virtualisierung Unterstützung auf dem System (Hardware-assisted virtualization)
  • Funktionsfähige Xen Umgebung (domU muss gestartet werden können)

Continue reading “Eucalyptus: Erstellen eines Image aus einem ISO (Xen)” »




Einrichten einer Para-virtualisierten Netzwerkschnittstelle in Eucalyptus

Dieser Artikel beschreibt das Einrichten einer Para-virtualisierten Netzwerkschnittstelle unter Eucalyptus. Die folgenden Anweisungen gelten für eine KVM basierte Eucalyptus Installation.

Für ein auf Xen basiertes Eucalyptus System muss die unten aufgeführte Datei gen_libvirt_xml entsprechend geändert werden. Continue reading “Einrichten einer Para-virtualisierten Netzwerkschnittstelle in Eucalyptus” »



Eucalyptus: Installation eines Tomcat in ein vorhandenes Image

Dieser Artikel beschreibt die Installation eines Tomcat Servlet Container in ein bereits vorhandenes Ubuntu Image.

Dafür muss zunächst das Image gemounted werden.

losetup /dev/loop5 root.img
mount /dev/loop5 temp-mnt

Im Anschluß muss ein JDK sowie ein Tomcat heruntergeladen und in das /opt Verzeichnis des Images gespeichert werden. Continue reading “Eucalyptus: Installation eines Tomcat in ein vorhandenes Image” »



UEC: Zusammenstellen von Images für Ubuntu 10.04

Dieser Artikel beschreibt das Vorgehen (Bundling) für das Erstellen und die Registrierung von VM Images mit dem UEC Cloud Controller für Ubuntu 10.04 LTS. Dazu benötigen wir ein Image, dass von den Daily Builds heruntergeladen werden kann, verknüpfen alles miteinander und laden es in unsere Ubuntu Cloud.

Um den Vorgang von der Kommandozeile aus zu starten nutzen wird die folgenden Befehle. Hierbei wird automatisch ein UEC Image heruntergeladen und bereitgestellt.

TIMESTAMP=$(date +%Y%m%d%H%M%S)
RELEASE=lucid
ARCH=amd64 # Or this might be i386
[ $ARCH = "amd64" ] && IARCH=x86_64 || IARCH=i386
UEC_IMG=$RELEASE-server-uec-$ARCH
URL=http://uec-images.ubuntu.com/$RELEASE/current/
[ ! -e $UEC_IMG.tar.gz ] && wget $URL/$UEC_IMG.tar.gz
uec-publish-tarball $UEC_IMG.tar.gz $RELEASE-$TIMESTAMP

Damit ist der Kernel und das Image in unsere Ubuntu Cloud (Eucalyptus) hochgeladen worden und kann nun genutzt werden.

Mit dem anschließenden Befehl können wir das überprüfen.

euca-describe-images

Wir sollten einen registrierten Kernel sowie ein Image sehen, die als "available" markiert sind.

Quelle



UEC: Erstellen eines eigenen Image

Dieses Tutorial beschreibt das Erstellen von Images für die Ubuntu Enterprise Cloud mit Hilfe des vmbuilder utility. Dieses Image ist generisch und kann für jede Eucalyptus Cloud genutzt werden.

Zunächst erstellen wir eine Beschreibung zu einer Partition, hier mit dem Namen "part". Diese beinhaltet die Größe, den Typ sowie den Mountpoint der Partition unserer VM.

$ cat > part <

Im nächsten Schritt wird ein einfaches Skript mit dem Namen "firstboot" (entspricht ebenfalls dem Dateinamen) erstellt. Dieses wird das erste Mal ausgeführt, wenn das Image innerhalb von Eucalyptus gestartet wird um einen SSH Daemon zu installieren.

$ cat >firstboot <

Nun kann mit dem vmbuilder das Image erstellt werden. Dazu wird als Parameter das vorher erstellte Skript "firstboot" mit übergeben.

sudo vmbuilder xen ubuntu --part ./part --firstboot ./firstboot

Als nächstes müssen wir einen Kernel, eine Ramdisk und natürlich das Image "bundlen", registieren und hochladen. Dazu verwenden wir die EC2 API Tools.

mkdir kernel
euca-bundle-image --image /boot/vmlinuz-$(uname -r) \
--destination ./kernel --kernel true
euca-upload-bundle --bucket kernel \
--manifest ./kernel/vmlinuz-$(uname -r).manifest.xml
EKI=`euca-register kernel/vmlinuz-$(uname -r).manifest.xml | awk '{print $2}'`
echo $EKI

mkdir ramdisk
sudo sh -c 'grep -q acpiphp /etc/initramfs-tools/modules ||
printf "#acpiphp needed for ebs\nacpiphp\n" > /etc/initramfs-tools/modules'
sudo mkinitramfs -o ./ramdisk/initrd.img-$(uname -r)
euca-bundle-image --image ./ramdisk/initrd.img-$(uname -r) \
--destination ./ramdisk --ramdisk true
euca-upload-bundle --bucket ramdisk \
--manifest ramdisk/initrd.img-$(uname -r).manifest.xml
ERI=`euca-register ramdisk/initrd.img-$(uname -r).manifest.xml | awk '{print $2}'`
echo $ERI

mkdir image
euca-bundle-image --image ubuntu-xen/root.img \
--destination ./image --kernel $EKI --ramdisk $ERI
euca-upload-bundle --bucket image --manifest ./image/root.img.manifest.xml
EMI=`euca-register image/root.img.manifest.xml | awk '{print $2}'`
echo $EMI

Die Shell Variablen in dem obigen Code Beispiel werden dazu benötigt, um die anschließende Instalaltion zu testen. Nun sollte der Kernel, die Ramdisk und das Image in Eucalyptus hochgeladen worden und betriebsbereit sein. Um das zu überprüfen nutzen wir den folgenden Befehl.

euca-describe-images

Wir sollten einen registierten Kernel, eine Ramdisk und das Image sehen, wobei alle als "available" gekennzeichnet sind.

Quelle