Eine Beispielkonfiguration für einen Cluster würde z.B. aus einem Load Balancer, drei Rails Applikations-Servern und einem Datenbankserver bestehen. Für den Start dieses Clusters ist anschließend Scalarium verantwortlich, indem es eine Verbindung zur Amazon Compute Cloud (EC2) herstellt und die entsprechenden Instanzen startet. Die Images werden geladen und der Scalarium Agent installiert.

Der Scalarium Agent wird auf jedem Server ausgeführt und ist über eine verschlüsselte Verbindung ständig mit Scalarium in kontakt. Webserver werden dabei automatisch mit Nginx konfiguriert, während Datenbankserver eine MySQL Installation erhalten. Nachdem der Scalarium Agent auf einer Instanz installiert wurde und das System konfiguriert hat, wird die Instanz als online markiert und kann durch den Cluster verwendet werden.

Scalarium bietet die folgenden vier Funktionen, die im Anschluß jeweils kurz vorgestellt werden.

• Auto Config
• Auto Healing
• Auto Scaling
• One Click Deploy

Auto Config

Mittels der Auto Configuration werden die Server automatisiert konfiguriert, indem die benötigte Software installiert und eingerichtet wird. Werden weitere Instanzen hinzugefügt, konfiguriert Scalarium automatisch die Anwendungen und den gesamten Cluster. Die einzigen Informationen die von Scalarium dazu benötigt werden sind die gewünschten Ubuntu Packages und Rubygems. Anschließend werden alle Pakete und Libraries auf jedem Server installiert und das zu jederzeit.

Weitere Informationen zu Auto Config sind HIER zu finden.

Auto Healing

Mit Auto Healing sorgt Scalarium dafür, dass die vorher festgelegten Services und Hosts des Cluster im Fehlerfall automatisch wiederhergestellt werden. Fällt z.B. ein Server aus, wird dieser durch Scalarium entfernt und in kurzer Zeit durch eine neue Instanz ersetzt, wodurch der gesamte Cluster automatisch neu konfiguriert wird.

Weitere Informationen zu Auto Healing sind HIER zu finden.

Auto-Scaling

Durch das Auto-Scaling können Schwellwerte festgelegt werden die dafür sorgen, dass entweder weitere Instanzen gestartet oder nicht mehr benötigte Instanzen beendet werden. Dazu überwacht Scalarium die CPU- und Arbeitspeicher-Auslastung, sowie die durchschnittliche Belastung jeder Instanz.

Weitere Informationen zu Auto Scaling sind HIER zu finden.

One Click Deploy

Mittels One Click Deploy können Anwendungen über den gesamten Cluster hinweg zu einem Zeitpunkt vollständig automatisiert verteilt, installiert und konfiguriert werden.

Weitere Informationen zu One Click Deploy sind HIER zu finden.

Demo Video

Preise

Quelle

• Scalarium

Die Grundlagen des Cluster Computing legte Gene Amdahl als Computerarchitekt bei IBM. In seinem 1967 veröffentlichten Paper zum Thema ’Parallel Processing’ stellte er folgende These auf, die auch als Amdahl’s Law bezeichnet wird und als Basis für Multiprozessor sowie Clustercomputer gilt.

Das Gesetz besagt, ’… wie sich der nicht parallelisierbare Anteil eines Programms auf die Gesamtrechenzeit auswirkt …’. Genauer bedeutet dies, dass die Geschwindigkeitszunahme in erster Linie durch den sequentiellen Anteil des Algorithmus beschränkt wird. Das ist darauf zurückzuführen, dass sich die Ausführungszeit nicht durch Parallelisierung verkleinern lässt.

Die ersten Ideen einen Computercluster aufzubauen stammen aus den Zeiten, in denen auch die ersten Computernetzwerke aufgebaut wurden. Der Grundgedanke zum Aufbau solcher Netzwerke bestand darin, Ressourcen in Form von Computersystemen untereinander zu verbinden und damit einen quasi Computercluster aufzubauen. Durch die Einführung der Paket vermittelnden Netzwerke im Jahre 1962 durch die Firma RAND, wurde auf dieser Grundlage 1969 das ARPANET Projekt gegründet. Dieses gilt als das erste Commodity-Netzwerk auf Basis eines Computercluster, in dem vier unterschiedliche Computercenter miteinander verbunden wurden. Jedes dieser vier Computercenter war für sich selbst wieder ein Computercluster, die aber nur autonom arbeiteten. Aus dem ARPANET wurde später das Internet, weshalb das Internet auch als die ’Mutter’ aller Computercluster gilt, aus dem Grund, das quasi alle Computerressourcen inkl. aller bereits bestehenden Cluster zusammengeschlossen werden können.

Ein Computercluster beschreibt also eine meist große Anzahl von einzelnen miteinander vernetzten Computern, die dazu verwendet werden einzelne Teilaufgaben, die zu einer Gesamtaufgabe gehören, parallel zu verarbeiten. Von außen betrachtet wirkt ein Computercluster wie ein einzelnes System. Die jeweiligen Knoten sind dabei untereinander über ein schnelles Netzwerk verbunden. Durch den Aufbau solcher Serverfarmen wird die Rechenkapazität und Verfügbarkeit deutlich gegenüber eines einzigen Computers erhöht. Vor allem die Ausfallsicherheit eines solchen Computercluster ist ein entscheidender Vorteil gegenüber einem einzelnen Computersystem. Fällt innerhalb eines Clusterverbunds ein einzelnes System aus, hat das keinen direkten Einfluss auf alle anderen beteiligten Systeme innerhalb des Clusters. Es wird damit also eine Redundanz erzielt. Computercluster können am besten für die Verarbeitung von Batch-Jobs eingesetzt werden, bei denen viele parallele Teilberechnungen durchgeführt werden. Handelt es sich bei der Verarbeitung jedoch um Teilaufgaben, die im hohen Maße synchronisiert werden müssen, sind Computercluster dafür nicht geeignet, da der Kommunikationsoverhead zwischen den einzelnen Systemen den Performancegewinn, der durch die parallele Verarbeitung entsteht, wieder relativiert.

Der erste kommerziell zu erwerbende Computercluster (ARCnet) wurde im Jahr 1977 von der Firma Datapoint vorgestellt. Mit dem so genannten VAXCluster für ihr
VAX-System hatte die Firma DEC im Jahr 1983 den ersten richtigen Erfolg im Bereich des kommerziellen Clustercomputing.

Arten von Computer Cluster

Das Ziel des Cluster Computing ist die Bereitstellung einer sehr hohen Rechenleistung bzw. einer besonders ausfallsicheren Rechnerumgebung. Von diesen Zielen ausgehend werden verschiedene Arten von Computercluster und dadurch auch deren Einsatzfeld definiert.

Bei Clustersystemen wird grundsätzlich zwischen homogenen und heterogenen Clustern unterschieden. Homogene Cluster zeichnen sich dadurch aus, dass die jeweiligen Computer, die dem Cluster angehören, alle das gleiche Betriebssystem und die gleiche Hardware einsetzen. Computer, die zu einem heterogenen Cluster gehören, dürfen über unterschiedliche Betriebssysteme und Hardware verfügen.

Heutzutage werden drei Arten von Computercluster unterschieden und eingesetzt:

• Hochverfügbarkeit Cluster
  Hochverfügbarkeit Cluster werden verwendet die Verfügbarkeit zu steigern und für eine bessere Ausfallsicherheit zu sorgen. Aus diesem Grund darf die gesamte Hardware als auch die Software eines solchen Cluster in keinerWeise über einen Single-Point-of-Failure verfügen, da die Definition und der Zweck diesem widersprechen würde. Im Fehlerfall werden die Dienste von dem defekten Host des Cluster auf einen anderen Host automatisch übertragen. Einsatzgebiete solcher Clustersysteme sind Bereiche, in denen eine Ausfallzeit maximal einige Minuten pro Jahr erlaubt. Eine besondere Art von Hochverfügbarkeit Cluster sind die so genannten ’stretched Cluster’. In diesem Fall werden einzelne Hosts eines Cluster räumlich getrennt in verschiedene weit voneinander entfernte Rechenzentren untergebracht. Kommt es in einem der Rechenzentren zu einem nicht vorhersagbaren Problem, können die Hosts des anderen Rechenzentrums vollständig die Aufgaben übernehmen.
• Load-Balancing Cluster
  Load-Balancing Cluster werden dazu verwendet eine Lastverteilung auf mehrere Computer zu ermöglichen. Aus der Benutzersicht steht ihm nur eine zentrale Einheit gegenüber, die aber logisch gesehen aus mehreren vernetzten Systeme besteht. Um die Leistung des gesamten Cluster zu erhöhen, werden nicht die einzelnen Hosts für sich aufgerüstet, sondern ein zusätzlicher Host dem Cluster hinzugefügt. Einsatzbereiche sind Umgebungen, in denen die Anforderungen an die Rechenleistung extrem hoch sind.
• High Performance Computing Cluster
  High Performance Computing Cluster werden überwiegend dazu verwendet Berechnungsverfahren durchzuführen, wobei die Berechnungen auf mehrere Hosts verteilt werden. Hierbei werden zwei unterschiedliche Arten der Aufgabenverteilung unterschieden. Eine Möglichkeit besteht darin, die Aufgaben in unterschiedliche Pakete zu verteilen, die dann parallel auf mehreren Hosts ausgeführt werden. Die andere Variante wäre, die Aufgaben auf die einzelnen Hosts direkt zu verteilen. Einsatzgebiete der High Performance Computing Cluster liegen überwiegend in den wissenschaftlichen Bereichen, aber auch die Serverfarmen für das Rendern von 3D-Computergrafiken und Computeranimationen gehören zu dieser Art von Cluster.

Nachdem ich OpenNebula und die Funktionen bereits kurz vorgestellt habe, möchte ich – angeregt durch die Projekte auf der OpenNebula Webseite – die Einsatzmöglichkeiten auf Basis von vier Anwendungsbeispielen vorstellen. Dazu werde ich in den nächsten Tagen jedes Beispiel auf Grund der Menge und Übersichtlichkeit in einem eigenen Artikel behandeln.

Auch wenn sich diese Beispiele speziell auf OpenNebula beziehen, kann die Umsetzung dieser Ansätze ebenfalls mit anderen Cloud Infrastruktur Management Tools, wie z.B. openQRM erfolgen.

On-Demand Skalierung eines Computer Cluster

Mit OpenNebula können auf einem pyhsikalischen Cluster dynamisch mehrere virtuelle Cluster parallel betrieben werden. Dadurch können Ressourcen wie z.B. Rechenleistung on-Demand bereitgestellt werden, indem die Anzahl der verfügbaren Hosts mit den Bedürfnissen der Benutzer wächst. Da virtuelle Hosts weniger physikalische Ressourcen benötigen, kann ein Cluster dadurch optimiert und konsolidiert werden, da die Anzahl der tatsächlich vorhandenen physikalischen Systeme reduziert werden kann, was dazu führt, dass weniger räumlicher Platz, Strom, Kühlung und Administration erforderlich ist.

Die Zuweisung der physikalischen Ressourcen zu den virtuellen Hosts wird dabei dynamisch und abhängig von den Anforderungen (benötigte Ressourcen) von dem Virtual Machine Manager übernommen. Des Weiteren kann ein Cluster in mehrere Partitionen aufgeteilt werden, da die physikalischen Ressourcen eines Clusters genutzt werden können, um sie einem Host bereitzustellen, der mit einem (anderen) virtuellen Cluster verknüpft ist.

Dieses Beispiel zeigt, wie das Bereitstellen der Ressourcen von der eigentlichen Ausführung, auf einem speziellen Service Layer durch den Local Resource Manager (LRM) getrennt werden kann.

Architektur

Bereitstellung mit der Sun Grid Engine (SGE)

Zunächst muss das Netzwerk, wie in den Howtos [1] und [2] beschrieben, konfiguiert werden, um neue virtuelle SGE Hosts mit unterschiedlichen Namen zu erstellen.

Um das grundlegende Virtual Machine Image zu erstellen kann der Befehl xen-create-image benutzt, ein Image von einem frisch installiertes Betriebssystem verwendet oder ein bereits verwendetes Virtual Machine Image genutzt werden.

Zusätzlich muss der virtuelle SGE Host genau so konfiguriert werden wie der physikalische SGE Host (NFS, NIS, execd, etc.)

Dieses Image dient als Grundlage für alle neuen virtuellen SGE Hosts. Jeder virtuelle Hosts muss an einem eigenen Ort abgelegt werden. Hierzu existiert das zentrale Verzeichnis sgebase, dass alle Images beinhaltet. Für jedes Image wird anschließend ein eigenes Verzeichnis mit dem Namen des Images erstellt.

$ cp -R sgebase sgehost01

Nun muss ein neues Virtual Machine Template erstellt werden. (Es kann auch ein bereits bestehendes kopiert werden und angepasst werden.)

MEMORY=64
CPU=1
OS=[
kernel="/boot/vmlinuz-2.6.18-4-xen-amd64",
initrd="/boot/initrd.img-2.6.18-4-xen-amd64",
root="sda1",
boot="hd"]
DISK=[
source="/local/xen/domains/xen/domains/sgehost/disk.img",
target="sda1",
readonly=no]
DISK=[
source="/local/xen/domains/xen/domains/sgehost/swap.img",
target="sda2",
readonly=no]
NIC=[mac="00:16:3e:01:01:03"]

Jetzt muss noch der Pfad zu dem Image, dem Kernel, der Ramdisk etc. angepasst werden.

Zum Starten des neuen virtuellen Host benötigen wir folgenden Befehl:

$ onevm create

Um Aufgaben entgegen zu nehmen muss der neue Host mit SGE anschließend bekannt gemacht werden .

$ qconf -ah sgehost01
$ qconf -as sgehost01
$ qconf -se

Soll der neue Host einer Gruppe zugeordnet werden, benötigen wir folgenden Befehl:

$ qconf -mhgrp @allhosts

Quelle

• On-demand Scaling of Computing Clusters

Mittels einer zentralen Managementkonsole kann die Administration von physikalischen Servern ebenso vorgenommen werden wie von virtuellen Maschinen, wodurch Rechenzentren voll automatisiert und höchst skalierbar betrieben werden können.

Neben einer offenen API und einem SOAP Web Service für die nahtlose Integration der eigenen Geschäftsprozesse, unterstützt openQRM alle bekannten Virtualisierungstechnologien und bietet die Möglichkeit für transparente Migrationen von “P-to-V”, “V-to-P” und “V-to-V”.

openQRM verfügt des Weiteren über ein integriertes Storage-Management, mit dem anhand des Snapshot-Verfahrens Serversysteme dupliziert werden können. Die Snapshots ermöglichen eine dynamische Anpassung des Speicherplatzes, bieten einen persistenten Cloud-Speicher und erlauben ein Backup/Restore der Server sowie deren Versionierung.

Mit der “N-zu-1″ Fail-Over Funktion steht mehreren Serversystemen ein einzelner Stand-By-Server zur Verfügung. Dabei spielt es keine Rolle, ob physikalische oder virtuelle Maschinen eingesetzt werden!

Benefits auf einem Blick

• Virtualisierung
  openQRM unterstützt alle gängigen Virtualisierungstechnologien darunter VMWare, Citrix XenServer und KVM und bietet die Möglichkeit der Migration von P-to-V-, V-to-P- und V-to-V für physikalische Server als auch virtuelle Maschinen.
• Storage
  openQRM verfügt über ein zentralisiertes Speichersystem mit integriertem Storage Management, welches alle bekannten Storage-Technologien unterstützt. Dazu gehören u.a. Netapp, Equallogic, NFS, iSCSI ZFS und proprietäre auf LVM basierende Storage-Typen, für eine flexible und schnelle Duplizierung von Serversystemen.
• Zentrales Management
  openQRM verschmilzt die Welt von Open Source mit der von kommerziellen Produkten. Mit einer zentralen Managementkonsole sind alle Funktionen zur Administration von Rechenzentren, System- und Service-Überwachung, Hochverfügbarkeit und automatisierter Bereitstellung vorhanden.

Funktionen

• Hardware/Software Isolation
  openQRM isoliert die Hardware (physikalische Server, virtuelle Maschinen) vollständig von der Software (Server Images). Dabei ist die eigentliche Hardware eine “Computing Resource” und kann dadurch jederzeit durch eine andere Hardware ersetzt werden, ohne dass die Software (Server Image) neu konfiguriert werden muss.
• Unterstützung für verschiedene Virtualisierungs-Technologien
  Mit VMWare, Xen, KVM und dem Citrix XenServer unterstützt openQRM eine viehlzahl an virtuellen Maschinen und kann dieses transparent verwalten und migrieren. Neben der System-Migration von physikalischen Servern zu virtuellen Maschinen (P-to-V) können Systeme ebenfalls von virtuellen Maschinen zu physikalischen Servern (V-to-P) migriert werden. Darüber hinaus besteht die Möglichkeit ein System von einer Virtualisierungstechnologie zu einer anderen Virtualisierungstechnologie (V-to-V) zu verschieben.
• Vollautomatische Nagios-Konfiguration

  openQRM unterstützt die vollautomatische Konfiguration von Nagios mittels “nmap2nagios-ng”. Damit wird das gesamte openQRM Netzwerk analysiert und auf Basis der Informationen eine Nagios-Konfiguration erstellt. Anschließend werden alle Services auf allen Systemen überwacht.

• Integriertes Storage-Management
  openQRM organisiert die Serversysteme wie Dateien und nutzt zur Verwaltung moderne Storagesysteme anstatt lokaler Festplatten. Mittels Logical Volume Managern (LVM) und deren Snapshot-Verfahren können Server-Templates auf schnellen Wege dupliziert werden.

  “Sollen z.B. 10 neue Server ausgerollt werden, kann so einfach ein bestehendes Server-Image 10 mal dupliziert und die “Clone” direkt zum Deployment bereitgestellt werden.”

  Mit diesem Konzept steht ein zentrales Backup/Restore sowie die Möglichkeit von Hot-Backups ohne Downtime zur Verfügung.

  openQRM unterstützt folgende Storage-Typen:

  • NFS (NAS)
  • iSCSI (iSCSI SAN)
  • Aoe/Coraid (AOE SAN)
  • NetApp (iSCSI SAN)
  • Local-disk (Übertragung von Server-Images auf lokale Festplatten)
  • LVM-Nfs (NFS auf LVM2, erlaubt schnelles Cloning)
  • LVM-iSCSI (iSCSI auf LVM2, erlaubt schnelles Cloning)
  • LVM-Aoe (Aoe auf LVM2, erlaubt schnelles Cloning)
  • Equallogic (iSCSI SAN)
  • ZFS (iSCSI SAN)
• Hochverfügbarkeit und “N-to-1″-Fail-Over!
  Mit der “N-zu-1″ Fail-Over Funktion steht mehreren Serversystemen ein einzelner Stand-By-Server zur Verfügung. Unabhängig davon, ob physikalische oder virtuelle Maschinen eingesetzt werden.

  “Um zum Beispiel 10 hochverfügbare Spezialsysteme zu betreiben benötigt man normalerweise weitere 10 “Stand-By”-Systeme. Mit openQRM jedoch benötigt man nur einen einzigen “Stand-By”-Server, der im Fehlerfall eines der 10 Spezialsysteme benutzt wird. Das heißt, man kann 9 “stromfressende”, nicht ausgelastete Server einsparen. Perfekt für “Green IT”.

  Des Weiteren können physikalische Server virtuelle Maschinen als “Hot Stand-By” nutzen und lassen sich im Notfall in eine virtuelle Maschine migrieren.

• Fertige Server-Templates
  Mittels dem “Image-Shelf”-Plugin stellt openQRM bereits fertige Server Templates zur Verfügung. Dazu gehören Linux Distributionen wie Debian, Ubuntu, CentOS und openSuse. Des Weiteren können mit dem Plugin eigene Server Templates auf unterschiedliche Weise (lokal, http, https, ftp) bereitgestellt werden.
• Unterstützung verschiedenster Deployment-Methoden
  Mit openQRM können Server von jeder Art von Storage gestartet werden. Zusätzlich können die Server Templates von einem Storage-Typ zu einem anderen übertragen werden, dabei kann noch entschieden werden, ob die Server Templates auf einem physikalischen Server oder in einer virtuellen Maschine gestartet werden sollen.
• Unterstützung verschiedener OS-Distributionen
  Es stehen bereits vor-konfigurierte openQRM-Server Pakete für Debian, Ubuntu und CentOS zur Verfügung. Ein openQRM-Server kann aber alle gängigen Linux Distributionen verwalten.
• Cloud-Selector
  Mit dem Cloud-Selector kann der Cloud Administrator seine Cloud Produkte wie z.B. Prozessoren, Speicher, Festplattengröße oder den Typ der virtuellen Maschine auswählen und deren Preise festlegen.
• Kostenrechner im Cloud-Portal
  Die Cloud-Computing-Unit (CCU) kann einer regulären Währung (z.b. USD oder Euro) zugewiesen werden. Mit dem Kostenrechner werden die stündlichen, täglichen und monatlichen verbrauchten Kosten für eine Cloud Appliance berechnet.
• Private Cloud Images
  Mit der “Private Cloud Image”-Funktion können Cloud Benutzer eigene Server Templates anlegen und verwalten.
• Volle SSL-Unterstützung
  Der openQRM-Server arbeitet in einem vollständig SSL-verschlüsselten Bereich und unterstützt verschiedene Serverarchitekturen wie i386 und x86_64.

Auszeichnungen

• Am 20. October 2009 gewann openQRM den “Open-Source Cloud Computing Slam” beim CloudCamp München.
• Auf den Devopsdays 2009 in Gent wurde eine Übersicht zu aktuellen Cloud-Technologien erstellt, bei der sich openQRM gegenüber den anderen Anbietern mit einer überzeugenden Vielfalt präsentiert.
• openQRM wurde von John Willis mit dessen Cloud Computing Awards 2009 – “The Cloudies” in der Kategorie “Best David vs. Goliath Cloud Vendor” ausgezeichnet.

Preise

• openQRM ist Open Source und unterliegt der GPL (GNU General Public License).

Support

• Die openQRM Enterprise ist der Hauptsponsor von openQRM. Das Team um CEO Matthias Rechenburg, CTO Christoph Moeller und Vertriebs- und Marketing-Direktor Andre Westbunk weist langjährige Erfahrungen für das flexible, konsistente und transparente Betreiben von Rechenzentren und bietet professionelle Services zu openQRM um damit die Gesamtbetriebskosten (TCO) von IT-Abteilungen zu senken.
• Ich möchte hier noch anmerken, dass es sich bei der openQRM Enterprise um einen deutschen Anbieter aus dem Bereich des Cloud Computing handelt!

Quelle

openQRM
openQRM Enterprise

Autor: Tom White

Beschreibung:
“Hadoop: The Definitive Guide helps you harness the power of your data. Ideal for processing large datasets, the Apache Hadoop framework is an open source implementation of the MapReduce algorithm on which Google built its empire. This comprehensive resource demonstrates how to use Hadoop to build reliable, scalable, distributed systems: programmers will find details for analyzing large datasets, and administrators will learn how to set up and run Hadoop clusters.

Complete with case studies that illustrate how Hadoop solves specific problems, this book helps you:

• Use the Hadoop Distributed File System (HDFS) for storing large datasets, and run distributed computations over those datasets using MapReduce
• Become familiar with Hadoop’s data and I/O building blocks for compression, data integrity, serialization, and persistence
• Discover common pitfalls and advanced features for writing real-world MapReduce programs
• Design, build, and administer a dedicated Hadoop cluster, or run Hadoop in the cloud
• Use Pig, a high-level query language for large-scale data processing
• Take advantage of HBase, Hadoop’s database for structured and semi-structured data
• Learn ZooKeeper, a toolkit of coordination primitives for building distributed systems

”

Bestellmöglichkeit: Amazon

Cover:

via YouTube

Ziel dieses Tutorials

Dieses Tutorial beschreibt die Installation, Konfiguration und Registierung, sowie weitere Schritte für die Arbeit mit einer grundlegenden Eucalyptus Einrichtung. Am Ende haben wir eine Cloud mit einem “Front-End” Controller und einem Knoten, auf dem mehrere Instanzen von Virtual Machines ausgeführt werden können, vollständig eingerichtet. Siehe dazu die Schritte 1 – 3.

In den Schritten 4 – 6 lernen wir die ersten Schritte für die Einrichtung einer Private Cloud und wie diese z.B. mit der RightScale Cloud Management Platform verbunden werden kann.

• Schritt 1: Die Voraussetzungen
• Schritt 2: Installation & Konfiguration
• Schritt 3: Registrierung der Eucalyptus Komponenten
• Schritt 4: Erster Login
• Schritt 5: Erstellen eines Virtual Machine Image
• Schritt 6: Starten eines Images

1. Schritt: Die Voraussetzungen

Das Eucalyptus System hat drei grundlegende Bestandteile:

• eucalyptus-cloud: Beinhaltet den Cloud Controller (Front-End Services) und das Walrus Speichersystem.

• eucalyptus-cc : Beinhaltet den Cluster Controller der für das virtuelle Netzwerk zuständig ist.

• eucalyptus-nc: Beinhaltet den Node Controller zur Verwaltung der einzelnen Knoten, der mit der KVM (Kernel basierende Virtual Machine) kommuniziert und die jeweiligen Virtual Machines verwaltet.

Eine einfache Eucalyptus Umgebung besteht aus zwei Systemen, einem Front-End und einem Node. Das Front-End ist für eucalyptus-cloud und eucalyptus-cc zuständig. In einer komplexeren Umgebung mit mehreren Systemen können/ sollten die oben genannten Teile des Front-Ends voneinander getrennt betrieben werden. Da die Kommunikation vollständig über das Netzwerk erfolgt, ist diese Separierung einfach vorzunehmen.

Das folgende Diagramm zeigt einen einfachen Aufbau einer Eucalyptus Umgebung:

Vor der Installation der Pakete gibt es ein paar Voraussetzungen die erfüllt sein müssen, damit am Ende ein voll funktionsfähiges Eucalyptus System vorhanden ist. Zunächst muss das Front-End in der Lage sein E-Mails zu verschicken. Die Administrations-Tools von Eucalyptus nutzen E-Mails um den Administrator zu benachrichtigen, das er die Anmeldeinformationen von Benutzern prüfen muss. Dazu sollte Postfix installiert werden und als ‘mailhost’ der ‘localhost’ eingetragen werden (z.B. als Eintrag in die /etc/hosts).

Auf dem Node auf welchem von Eucalyptus die Virtual Machines ausgeführt werden, muss die erste Netzwerkschnittstelle als Bridge (BR0) konfiguriert werden. Sie dazu (Ubuntu Server Guide Bridging – in Englisch). Dieser Bridge fügt Eucalyptus für jede vorhandene Virtual Machine eine virtuelle Netzwerkschnittstelle (Virtual Network Interfaces) hinzu, bevor die Netzwerkverbindung einer Virtual Machine aktiviert wird.

Des Weiteren benötigt Eucalyptus einen DHCP Server der automatisch IP-Adressen vergibt. Ab dem Zeitpunkt wo die Virtual Machines über die Bridge mit dem lokalen Netzwerk verbunden sind, führen sie ihren lokalen DHCP Client aus, um eine IP-Adresse zu erhalten.

Auf jedem Host der einen Eucalyptus Client nutzt, sollten die Amazon Elastic Compute Cloud (EC2) API und AMI Tools installiert werden. Dafür wird folgendes benötigt:

http://s3.amazonaws.com/ec2-downloads/ec2-api-tools-1.3-30349.zip
http://s3.amazonaws.com/ec2-downloads/ec2-ami-tools-1.3-26357.zip

Damit die ec2-ami-tools einwandfrei funktionieren müssen zusätzlich die Pakete ruby, libopenssl-ruby und curl installiert werden.

Für den Zugriff der EC2-ami-Tools auf die Meta-Daten (wie z.b. EC2-bundle-vol), muss folgender Eintrag vorgenommen werden. Bei der CC_IP handelt es sich um die IP-Adresse des Rechners auf dem Eucalyptus-cc ausgeführt wird.

vi ec2ami/lib/ec2/amitools/instance-data.rb
(set META_DATA_URL="http://:8773/latest/meta-data")

• Ports: Um auf Eucalyptus auch hinter einer Firewall zugreifen zu können muss der Port 8773 geöffnet werden. Das ist z.B. dann der Fall, wenn sich die EC2- und AMI-Tools sowie die Eucalyptus Cloud auf unterschiedlichen Seiten der Firewall befinden. Wenn das Eucalyptus System mit einer Cloud Management Platform verbunden werden soll, müssen zusätzlich die Ports 8773 und 8443 geöffnet werden.

Schritt 2: Installation & Konfiguration

Zuerst werden die eucalyptus-cloud und eucalyptus-cc Pakete auf der Front-End Machine installiert.

sudo apt-get install eucalyptus-cloud eucalyptus-cc

Anschließend erfolgt die Installation des eucalyptus-nc Pakets auf jedem Node.

sudo apt-get install eucalyptus-nc

Am Ende wird der eucalyptus-nc Service auf dem Node gestoppt und die /etc/eucalyptus/eucalyptus.conf editiert. In der eucalyptus.conf erhält die Bridge den Namen der ersten Netzwerkschnittstelle. Danach wird der eucalyptus-nc Service wieder gestartet.

Die oben beschriebenen Schritte können wie folgt umgesetzt werden:

sudo /etc/init.d/eucalyptus-nc stop
sudo vi /etc/eucalyptus/eucalyptus.conf
(set VNET_BRIDGE="br0")
sudo /etc/init.d/eucalyptus-nc start

Das folgende Diagramm zeigt, wie die Umgebung danach aussehen sollte:

Das Netzwerk sollte außerdem so konfiguriert werden, dass der IPv4 Datenverkehr von den IPv6 Ports weitergeleitet wird, da das Eucalyptus Web-Frontend standardmäßig IPv6 verwendet.

sudo vi /etc/sysctl.conf
(uncomment net.ipv4.ip_forward=1)
sudo sysctl -p

Schritt 3: Registrierung der Eucalyptus Komponenten

Eucalyptus setzt voraus, das jeder Node innerhalb des Systems zu einem Cluster gehört. Ein Cluster wiederum gehört zu einer Cloud. Auf jedem Node wird eine Kopie von eucalyptus-nc ausgeführt. Genauso muss auf jedem Cluster eine Kopie von eucalytpus-cc ausgeführt werden. In unserem Beispiel wird der eucalytpus-cc auf der selben Maschine ausgeführt wie der Cloud Controller (eucalyptus-clc). Diese Komponenten müssen sich vor dem Start des Systems nun gegenseitig registrieren.

Für die Registrierung eines Cluster wird der folgende Befehl benötigt:

sudo euca_conf -addcluster localhost

Dabei entspricht dem Namen des Clusters, den die Benutzer sehen werden. Es handelt sich dabei um einen reinen logischen Namen, der nur lokal zu Eucalyptus gehört und mit einer Verfügbarkeitszone übereinstimmt, wie sie bei den Client-Tools angezeigt wird.

Um nun einen Node bei einem Cluster zu registrieren, ist der folgende Befehl notwendig.

sudo euca_conf -addnode

Später können weitere Nodes – auf denen eine Kopie von eucalyptus-nc ausgeführt wird – hinzugefügt werden, indem der obige Befehl erneut für jeden Node ausgeführt wird.

Schritt 4: Erster Login

Nach dem ersten Start von Eucalyptus muss die Administrationsumgebung der Cloud eingerichtet werden. Dazu öffnen wir im Webbrowser folgende UR:

https://[front-end-ip-address]:8443

Mit den Standardzugangsdaten Benutzername: admin und Passwort: admin erfolgt die erste Anmeldung, bei der das Passwort geändert werden muss. Nun folgen wir den Anweisungen auf dem Bildschirm. Ist die Konfiguration abgeschlossen klicken wir auf den Reiter credentials und anschließend auf Download Certificate.

Wichtig ist hierbei zu beachten, dass wir eine sichere Verbindung nutzen, also “https” anstatt “http”. Wir erhalten eine Warnung auf Grund des Sicherheitszertifikats. Dafür müssen wir eine Ausnahme eintragen, um die Seite sehen zu können. Wird für diese Seite keine Ausnahme eingetragen, kann die Konfigurationsseite von Eucalyptus nicht angezeigt werden.

Jetzt müssen wir mittels X.509 Zertifikaten die EC2 API und AMI Tools auf unserem Server wie folgt einrichten.

mkdir ~/.euca
cd ~/.euca
mv ~/Desktop/euca2-admin-x509.zip ~/.euca
unzip euca2-admin-x509.zip


Die Installation kann mittels eines Skripts (ec2toolsinstall.sh) wie folgt durchgeführt werden.

cd ~/.euca
# Eucalyptus is not compatible with the newer ec2tools so we will
# install and remove them to insure all dependencies get installed
sudo apt-get install ec2-api-tools ec2-ami-tools
sudo apt-get remove ec2-api-tools ec2-ami-tools
wget http://s3.amazonaws.com/ec2-downloads/ec2-api-tools-1.3-30349.zip
unzip ec2-api-tools-1.3-30349.zip
mv ec2-api-tools-1.3-30349 ec2
wget http://s3.amazonaws.com/ec2-downloads/ec2-ami-tools-1.3-26357.zip
unzip ec2-ami-tools-1.3-26357.zip
mv ec2-ami-tools-1.3-26357 ec2ami
echo 'export JAVA_HOME=/usr' >> eucarc
echo 'export EC2_HOME=~/.euca/ec2' >> eucarc
echo 'export EC2_AMITOOL_HOME=~/.euca/ec2ami' >> eucarc
echo 'export PATH=$PATH:$EC2_HOME/bin:$EC2_AMITOOL_HOME/bin' >> eucarc


Vergabe der Zugriffsrechte:

chmod +x ec2toolsinstall.sh


Das Skript sollte die Datei eucarc erzeugt haben, die noch noch ge-sourced werden muss.

source ~/.euca/eucarc


Optional: Registrierung bei RightScale

RightScale bietet eine Cloud-Management-Plattform für den Einsatz mit Eucalyptus. Diese Cloud Management Software wird als Service innerhalb der Amazon Web Services ausgeführt und muss daher die Möglichkeit haben, mit dem Eucalyptus Cloud Controller (eucalyptus-clc) der hinter einer Firewall steht, zu kommunizieren.

Daher müssen die Ports 8443 und 8773 (Richtung > Internet) geöffnet werden, damit RightScale mit der Eucalyptus Cloud kommunizieren kann.

Um unsere Eucalyptus Cloud bei RightScale zu registrieren, folgen wir den Anweisungen in der unten verlinkten Anleitung:

• Registrieren der Eucalyptus Cloud bei RightScale.

Schritt 5: Erstellen eines Virtual Machine Image

Mit dem vmbuilder können wird ein Virtual Machine Image erstellen, das mit Eucalyptus gestartet werden kann.

Zunächst erstellen wir eine Datei mit dem Namen part, in der die Größe, der Typ und der Mountpunkt der Virtual Machine beschrieben ist:

root 400
/mnt/ephemeral 0 /dev/sda2
swap 1 /dev/sda3

Anschließend erstellen wir eine Skriptdatei mit dem Namen firstboot. Dieses Skript wird ausgeführt wenn das Image das erste Mal in Eucalyptus gestartet wird und installiert dabei einen SSH Daemon.

apt-get -y install openssh-server

Nun erstellen wir ein Image mit dem vmbuilder und übergeben beim Aufruf die beiden Skripte als Parameter.

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

Mit Hilfe der EC2 API Tools packen und registrieren wir abschließend den Kernel, die Ramdisk und das Image.

mkdir kernel
ec2-bundle-image -i /boot/vmlinuz-2.6.28-11-generic -d ./kernel --kernel true
ec2-upload-bundle -b kernel -m ./kernel/vmlinuz-2.6.28-11-generic.manifest.xml
EKI=`ec2-register kernel/vmlinuz-2.6.28-11-generic.manifest.xml | awk '{print $2}'`
echo $EKI


mkdir ramdisk
ec2-bundle-image -i /boot/initrd.img-2.6.28-11-generic -d ./ramdisk --ramdisk true
ec2-upload-bundle -b ramdisk -m ramdisk/initrd.img-2.6.28-11-generic.manifest.xml
ERI=`ec2-register ramdisk/initrd.img-2.6.28-11-generic.manifest.xml | awk '{print $2}'`
echo $ERI


mkdir image
ec2-bundle-image -i ubuntu-xen/root.img -d ./image --kernel $EKI --ramdisk $ERI
ec2-upload-bundle -b image -m ./image/root.img.manifest.xml
EMI=`ec2-register image/root.img.manifest.xml | awk '{print $2}'`
echo $EMI


Der Kernel, die Ramdisk und das Image sind nun in der Eucalyptus Cloud und können dort genutzt werden.

Zur Bestätigung geben wir folgenden Befehl ein:

ec2-describe-images

Die Ausgabe sollte nun einen registrierten Kernel, Ramdisk und Image anzeigen, die als “available” gekennzeichnet sind.

Schritt 6: Starten eines Images

Bevor eine Instanz eines Image gestartet wird, müssen wir ein Schlüsselpaar (SSH Key) erstellen um uns nach dem Start als Root anmelden zu können. Der Schlüssel wird gespeichert, daher muss dieser Schritt nur einmal durchgeführt werden.

ec2-add-keypair mykey > ~/.euca/mykey.priv
chmod 0600 ~/.euca/mykey.priv

Falls wir unseren Key mal vergessen sollten, können wir uns mittels ec2-describe-keypairs eine Liste aller erstellten und auf dem System gespeicherten Schlüssel anzeigen lassen.

Nun können wir Instanzen von unserem registrierten Image wie folgt erstellen.

ec2-run-instances $EMI -k mykey

Während des ersten Starts einer Instanz erstellt das System einen Cache für das Image aus welchem die Instanz erstellt wird. Da die Images in der Regel sehr groß sind, kann dieser Vorgang etwas dauern.

Der aktuelle Status der Instanz kann mit folgendem Befehl abgefragt werden.

ec2-describe-instances

Die Ausgabe zeigt die aktuellen Informationen und den Status der Instanz. Während des ersten Starts sollte sich die Instanz im Status “pending” befinden. Ist die Instanz gestartet, sollte der Status auf “running” wechseln. Nachdem die Instanz über DHCP eine IP-Adresse erhalten hat können wir uns mittels des oben generierten SSH Keys mit der Instanz verbinden.

ssh -i ~/.euca/mykey.priv root@

Die Umgebung der Eucalyptus Cloud sollte nun diesem Diagramm entsprechen.

Weitere Informationen

• Log Dateien: /var/log/eucalyptus
• Konfigurationsdateien: /etc/eucalyptus
• Init Skripte: /etc/init.d/eucalyptus-cc, /etc/init.d/eucalytpus-cloud und /etc/init.d/eucalytpus-nc
• Datenbank: /var/lib/eucalyptus/db
• Neustart (Anmerkung): Bei einem Neustart wird Eucalyptus nicht automatisch neu gestartet. Die Services müssen daher manuell geladen werden.
• Umgebung (Anmerkung): Bevor der Client gestartet wird, sollten die Quellen unter ~/.euca/eucarc ge-sourced werden.

Quellen

Eucalyptus-Jaunty

Funktionsweise

Erstellen der Seite und hochladen der Daten
• Die Infrastruktur zum Hosten einer Webseite kann innerhalb von fünf Minuten erstellt werden. Konfigurationen für das Load Balancing, Clustering und redundantes Speichern der Daten wird automatisch durch das Rackspace übernommen.

Automatische Skalierung
• Die Daten der Webseiten werden automatisch und ohne Eingriff des Benutzers auf speziellen Clustersystemen gespeichert. Das bedeutet, dass die Performance mit den Anfragen der Benutzer wächst und eine Überlastung der Webseite nicht stattfindet.

Technologie

Betriebssysteme
• Die Infrastruktur hinter Cloud Sites besteht aus einer Vielzahl von Linux und Windows Servern, wobei jeder Cluster speziell auf das Betriebssystem abgestimmt ist. Vor Überlastungen schützen u.a. Load Balancing Mechanismen die bei Bedarf die Anfragen automatisch verteilen. Für jede Webseite oder einzelne Seite einer Webseite kann auf Linux oder Windows zurückgegriffen werden. Neben Standardsoftware wie WordPress, Drupal oder .NETNuke besteht ebenfalls die Möglichkeit eigene proprietäre Software auf den System zu installieren.

Load Balancing
• Die Daten der Webseiten und Anwendungen werden auf eine Vielzahl von Servern verteilt und mittels Load Balancing findet anschließend die Verteilung der Anfragen auf die Server statt. Fällt z.B. ein Server aus, übernimmt automatisch ein anderer Server seine Aufgabe und beantwortet die Anfrage, wodurch der Benutzer gar nicht bemerkt das ein technisches Problem vorliegt. Ein weiterer Vorteil besteht im Skalieren der Webseiten-Performanz. In Momenten, z.B. während eines Fernsehberichts in dem über die Webseite berichtet wird, sind die meisten Webseiten (vielmehr die Server auf denen sich die Webseiten befinden) auf Grund von zu vielen Anfragen überlastet und die Anfragen werden nicht mehr beantwortet. Der Sinn und Zweck des Fernsehberichts ist damit gescheitert, denn die meisten Benutzer werden nicht wiederkommen, wenn Sie merken, dass sie kein Angebot vorfinden. Durch das Load Balancing werden die Anfragen in solchen Momenten automatisch auf mehrere Server verteilt und die Antwortzeiten der Webseiten verhalten sich wie an “normalen” Tagen.

Linux
• Debian + Red Hat Enterprise
• PHP v5.2MySQL v5
• Apache v1.3 + v2.
• 2Perl v5.8
• Mod Rewrite Enabled

Windows
• Windows 2008 Server
• .NET v2, v3, & v3.5 SP1
• IIS 7
• MS SQL 2008

Verwaltung
• Web-Interface für die Verwaltung
• Secure File Transfer (SFTP)
• Master FTP Account und weitere
• Starten von Cron Jobs, Zugriffsverwaltung und entpacken von Dateien

DNS
• White-label Nameserver
• Online DNS Verwaltung
• Private-label Nameserver
• Eigener DNS-Server (optional)

Preise

Alle Preise sind hier zu finden: Rackspace Cloud Files Preise

Quelle

[1] Rackspace Cloud – Cloud Sites
[2] Graphik: Rackspace Cloud – Cloud Sites (1)
[3] Graphik: Rackspace Cloud – Cloud Sites (2)
[4] Graphik: Rackspace Cloud – Cloud Sites (3)
[5] Graphik: Rackspace Cloud – Cloud Sites (4)

Durch das Hinzufügen und Starten von Serverinstanzen innerhalb von Minuten kann die verwendete Infrastruktur in kurzer Zeit je nach den aktuellen Anforderungen skaliert werden. Ist die Last hoch, werden mehr Instanzen hinzugefügt, nimmt die Last wieder ab, werden die nicht mehr benötigten Kapazitäten entfernt.

Da nur für die Ressourcen bezahlt wird, die auch tatsächlich verwendet werden, erhält man dadurch eine bessere Kosteneffizienz. Der Normalfall besteht in der Anschaffung eigener überdimensionierter Systeme, die im Gesamtdurchschnitt nur zu 20% ausgelastet sind. Die restlichen 80% werden nur während Spitzenlasten genutzt und verursachen sonst nur unnötige Kosten.

Amazon EC2 Funktionsweise

Die virtuelle Umgebung von Amazon EC2 wird mittels einer Webservice Schnittstelle angesprochen, über die auf Serverinstanzen mit einer vielzahl unterschiedlicher Betriebssysteme zugegriffen werden kann. Die Betriebssysteme können wie eigene “lokale” Betriebssysteme mit Software erweitert und können ebenfalls mit Zugriffsberechtigungen konfiguriert werden.

[2]

Eine einfache Vorgehensweise

• Auswahl und Start eines bereits vor-konfigurierten Images (Vorlage). Alternativ kann auch ein eigenes Amazon Machine Image (AMI) erstellt werden. Dieses beinhaltet dann eigene Anwendungen, Bibliotheken, Daten und Konfigurationen.
• Konfiguration der Sicherheitseinstellungen und des Netzwerkzugriffs auf die jeweilige EC2 Instanz.
• Auswahl des Instanz Typs und des Betriebssystems.
• Festlegen des Orts, wo die Server ausgeführt werden sollen (USA, Europa, …).
• Festlegen einer statischen IP-Adresse.
• Hinzufügen von Speicherplatz.

Leistungen im Überblick

• Elastisch: Rechnerkapazität kann je nach Bedarf innerhalb von Minuten vergrößert und verkleinert werden. Dabei kann man einen aber auch tausend Server Instanzen gleichzeitg nutzen, die mittels der Web Service API angesprochen werden und automatisch skalieren.
• Vollständige Kontrolle: Für jede Server Instanz besteht vollständiger Root-Zugriff.
• Flexibilität: Man kann zwischen mehreren Instanzen Typen, Betriebssystemen und Software-Pakete wählen. Die Serverhardware kann so konfiguriert werden, dass der Speicher, die CPU, und die Größe der Boot-Partition, optimal für das Betriebssystem und die Anwendung ausgelegt sind.
• Amazon Web Services: Vollständige Unterstützung und Integration mit den anderen Amazon Web Services wie Amazon Simple Storage Service (Amazon S3), Amazon SimpleDB und Amazon Simple Queue Service (Amazon SQS).
• Zuverlässig: Das Service Level Agreement von Amazon EC2 besagt 99,95% Verfügbarkeit für jede Amazon EC2 Region.
• Sicherheit: Amazon EC2 stellt folgende Sicherheitsfunktionen bereit:

  • Über die Webservice Schnittstelle kann eine Firewall für den Zugriff auf die jeweilige Instanz und zwischen einzelnen Instanzen/ Gruppen von Instanzen konfiguriert werden.
  • Mittels der Amazon Virtual Private Cloud (Amazon VPC) können die Instanzen in einen eigenen (privaten) IP-Adressbereich verlagert werden. Darüber hinaus kann über die (haus)-eigene Infrastruktur mit einem IPSec VPN auf diese Instanzen in der Amazon Cloud zugegriffen werden.

• Kostengünstig:

  • On-Demand Instanzen: Bei On-Demand Instanzen zahlt man nur für die Rechnerkapazität die tatsächlich genutzt wird. Die Abbrechnung erfolg dabei pro Stunde ohne langfristige Verpflichtungen einzugehen. Dadurch entfällt die Überdimensionierung der Serverlandschaft um Lastspitzen auszugleichen.
  • Reservierte Instanzen: Instanzen können für eine niedrige, einmalige Zahlung pro Instanz reserviert werden. Im Gegenzug erhält man einen Rabatt auf die Nutzungsgebühr (Stundenpreis) für diese Instanz. Anschließend ist diese Instanz ohne weitere Verpflichtungen reserviert und kann wie gewohnt genutzt werden.
  • Spot Instanzen: Hier bietet man auf ungenutzte Amazon EC2 Kapazitäten. Dazu teilt man Amazon mit, welche EC2 Instanz man gerne haben möchte und was man bereit ist dafür zu bezahlen. Anhand von Angebot und Nachfrage wird ein Spot-Preis ermittelt.

[3]

Funktionen

• Amazon Elastic Block Store
  Amazon Elastic Block Store (EBS) dienen zur dauerhaften Speicherung der Amazon EC2-Instanzen. Neben aktiven können auch Instanzen gespeichert werden, die gerade nicht verwendet werden. Die Volumes können als Boot Partition für EC2-Instanzen verwendet werden oder direkt an eine bereits gestartete EC2-Instanz angeschlossen werden. Die EBS-Volumes werden automatisch in eine einfache Verfügbarkeitszone repliziert und ein Snapshot kann zusätzlich in Amazons S3 Dienst abgelegt werden. Dieser Snapshot wird dann über mehrere Verfügbarkeitszonen verteilt. Ein Snapshot kann, wenn gewünscht, als Ausgangspunkt für einen neuen Amazon EBS dienen.

• Mehrere Standorte
  Amazon EC2 Instanzen können an mehreren Standorten verteilt werden. Die Standorte sind dabei in Regionen und Verfügbarkeitszonen aufgeteilt. Verfügbarkeitszonen sind unterschiedliche Orte, die entwickelt wurden, um von Fehlern in anderen Verfügbarkeitszonen nicht betroffen zu sein. Zudem haben unterschiedliche Verfügbarkeitszonen unterschiedliche Latenzzeiten in einer Region. Durch den Einsatz von separaten Verfügbarkeitszonen wird eine Anwendung von Ausfällen an einzelnen Standorten nicht betroffen. Die einzelnen Verfügbarkeitszonen sind geografisch in verschiedenen Orten und Ländern verteilten. Dazu gehören derzeit der Osten der USA (Northern Virginia), der Westen der USA (Northern California) und Europa (Irland).
• Elastische IP-Adressen
  Elastische IP-Adressen sind statische IP-Adressen die für dynamisches Cloud Computing entwickelt wurden. Diese IP-Adresse ist mit dem AWS-Account und nicht mit einer konkreten Instanz verknüpft. Im Fehlerfall einer Instanz wird die IP-Adresse des betroffenen Servers auf einen funktionieren Server neu gemapped.
• Amazon Virtual Private Cloud
  Mit der Virtual Private Cloud die EC2-Instanzen innerhalb der Amazon Cloud in das eigenen Firmennetz eingebunden werden. Sie fungieren dann im Prinzip als lokal vorhandene Server und können auf andere Systeme zugreifen, genau so wie auf sie zugegriffen werden kann.
• Amazon CloudWatch
  Wird HIER beschrieben.
• Auto Scaling
  Wird HIER beschrieben.
• Elastic Load Balancing
  Wird HIER beschrieben.

Typen von Instanzen

Standard Instanzen

• Small Instance: 1.7 GB Arbeitsspeicher, 1 EC2 Prozessor, 160 GB Speicherplatz, 32-bit Plattform
• Large Instance: 7.5 GB Arbeitsspeicher, 4 EC2 Prozessoren, 850 GB Speicherplatz, 64-bit Plattform
• Extra Large Instance:15 GB Arbeitsspeicher, 8 EC2 Prozessoren, 1690 GB Speicherplatz, 64-bit Plattform

High-Memory Instanzen

• High-Memory Double Extra Large Instance: 34.2 GB Arbeitsspeicher, 13 EC2 Prozessoren, 850 GB Speicherplatz, 64-bit Plattform
• High-Memory Quadruple Extra Large Instance: 68.4 GB Arbeitsspeicher, 26 EC2 Prozessoren, 1690 GB Speicherplatz, 64-bit Plattform

High-CPU Instanzen

• High-CPU Medium Instance: 1.7 GB Arbeitsspeicher, 5 EC2 Prozessoren, 350 GB Speicherplatz, 32-bit Plattform
• High-CPU Extra Large Instance: 7 GB Arbeitsspeicher, 20 EC2 Prozessoren, 1690 GB Speicherplatz, 64-bit Plattform

EC2 Prozessor: Ein EC2 Prozessor ist mit mit einem 1.0-1.2 GHz 2007 Opteron bzw. 2007 Xeon Prozessor vergleichbar.

Betriebssysteme und Software

Betriebssysteme

Folgende vorkonfigurierte Amazon Machine Images (AMI) stehen zur Verfügung:

• Red Hat Enterprise Linux
• Windows Server 2003/2008
• Oracle Enterprise Linux
• OpenSolaris
• openSUSE Linux
• Ubuntu Linux
• Fedora
• Gentoo Linux
• Debian

Des Weiteren können vorkonfigurierte AMIs inkl. vorinstallierter Software genutzt werden. Folgende Softwarelösungen stehen zur Verfügung:

Datenbanken

• IBM DB2
• IBM Informix Dynamic Server
• Microsoft SQL Server Standard 2005
• MySQL Enterprise
• Oracle Database 11g

Batch-Verarbeitung

• Hadoop
• Condor
• Open MPI

Web Hosting

• Apache HTTP
• IIS/Asp.Net
• IBM Lotus Web Content Management
• IBM WebSphere Portal Server

Anwendungsentwicklung

• IBM sMash
• JBoss Enterprise Application Platform
• Ruby on Rails

Applikationserver

• IBM WebSphere Application Server
• Java Application Server
• Oracle WebLogic Server

Video Encoding & Streaming

• Wowza Media Server Pro
• Windows Media Server

Preise

Alle Preise für

• Datentransfer
• Amazon Elastic Block Store
• Elastic IP Addresses
• Amazon CloudWatch
• Elastic Load Balancing

sind hier zu finden: Amazon EC2 Preise

Quellen:

[1] Amazon EC2
[2] Graphik: Amazon EC2 (1)
[3] Graphik: Amazon EC2 (2)