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.

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.

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

• Region and Availability Zone Concepts

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

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

• Instance Addressing Concepts

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

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

• Amazon Virtual Private Cloud Concepts

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.