Tag: Grid Computing


Was ist Grid Computing?

Die Charakteristiken von Computercluster sind das Bereitstellen von reiner Rechnerleistung in einem lokalen begrenzten Bereich. Die nächste Herausforderung bestand also darin, die Rechenleistung nicht nur lokal, sondern auch global verfügbar zu machen und neben der Rechenleistung z.B. auch Daten und Applikationen bereitzustellen.

Mitte der 1990er wurde der Begriff des Metacomputing als Möglichkeit zur Erweiterung von Paralleler Datenverarbeitung und Custer Computing eingeführt. Die Idee bestand darin, große Computersysteme über WAN-Leitungen (Wide Area Network) miteinander zu verbinden. Im Jahr 1997 wurden erstmals zwei Supercomputer des High Performance Computing Center Stuttgart (HLRS) und des Pittsburgh Supercomputing Centre (PSC) miteinander verbunden. Trotz der Verfügbarkeit von hohen Bandbreiten innerhalb der nationalen und internationalen Forschungsnetzwerke scheiterte das Experiment auf Grund der Latenz.

Das Metacomputing bezieht sich aber lediglich nur auf Computer (Rechenleistung) im Allgemeinen. Ian Foster und Carl Kesselman stellten im Jahre 1999 ein neues erweitertes Konzept mit dem Namen Grid Computing vor, das neben Computer auch andere Arten von (IT-)Ressourcen wie Software, Datenbanken, Rechenleistung, Speicherplatz oder spezielle Hardware beinhalten und miteiander vernetzen kann. Der Begriff des Grid wird abgeleitet aus dem englischen Wort Electrical Power Grid (Deutsch: Stromnetz), dessen Idee darin besteht, die Ressourcen den Benutzern so zur Verfügung zu stellen, als wenn sie den Strom aus der Steckdose bekommen würden. Dabei verfügt das Grid über standardisierte Schnittstellen, über die der Benutzer seine Anfragen übermitteln kann und ihm die Ressourcen dann automatisiert zugeteilt werden. Die Ressourcen sind dabei über das Internet verteilt und können unterschiedlichen ’virtuellen’ Organisationen angehören. Anhand der Schnittstellen kann der Status der Ressourcen abgefragt und diese direkt angesprochen werden. Ein entscheidender Vorteil liegt darin, dass der geographische Ort an dem sich die Ressource befindet nicht mehr von Bedeutung ist - siehe Graphik. Auf Grund des beliebigen und weltweiten Zugriffs auf Ressourcen über das Internet gilt das Grid als Generalisierung des World Wide Web. Davon abgeleitet steht die Technologie des Grid Computing somit als die Basistechnologie für die Koordination und Verarbeitung organisationsübergreifender Geschäftsprozesse und den gemeinschaftlichen Austausch und die Nutzung von Ressourcen.

Das entscheidende Ziel des Grid Computings bestand also darin, Ressourcen gemeinschaftlich global zu nutzen sowie diese zu koordinieren und darüber hinaus gemeinsam Probleme institutionsübergreifend in dynamischen virtuellen Organisationen zu lösen. Genauer bedeutet dies, dass zu Beginn Formalitäten wie das Abrechnungsschema und die Zugangsrechte geklärt werden und anschließend der Zugriff auf die Ressourcen wie z.B. Rechnerleistung oder Anwendungen für die gemeinschaftliche Nutzung bereitgestellt werden. Der Begriff der virtuellen Organisation beschreibt in diesem Fall eine dynamische Allianz von Organisationen, die ein gemeinsames Interesse während der Nutzung des Grids vertreten.

Arten von Grid Computing

Je nachdem wie die Ressourcen miteinander vernetzt sind und um was für ein Anwendungsszenario es sich handelt, können Grids in unterschiedliche Arten unterteilt werden. Nachfolgend werden fünf unterschiedliche Arten betrachtet.

  • Compute Grids
    Compute Grids werden verwendet um einem Benutzer Rechnerleistung bzw. Rechnerkapazität, die ihm in seiner eigenen Umgebung nicht zur Verfügung stehen, verteilt bereitzustellen. Das Bereitstellen kann hierbei eine derzeit nicht verwendete Ressource - z.B. eine Workstation außerhalb der Geschäftszeiten sein, oder aber auch ein Hochleistungclustersystem.
  • Data Grids
    Data Grids werden eingesetzt um große verteilte Datenmengen gemeinsam zu Nutzen und diese zu verarbeiten. Dabei wird eine sogenannte Data-Federation, eine organisationübergreifende Sicht auf alle Daten, die beispielsweise einem Projekt zugewiesen sind, definiert. Bei so einer Data-Federation handelt es sich um ein dezentral verwaltetes System, bei dem derjenige, der die Daten in dieser Umgebung zur Verfügung stellt auch die uneingeschränkte Kontrolle über diese Daten behält.
  • Application Grids
    Application Grids waren der erste Ansatz um virtuelle Organisationen zu etablieren und damit die organisationsübergreifende gemeinsame Nutzung von Ressourcen voranzutreiben. Die Betreiber der Grids sollten dadurch eine höhere Auslastung und die Benutzer ein besseres Angebot erfahren. Themen, die innerhalb dieses Grids auftreten, sind sichere und schnelle Datenverbindungen, Authentifikationen, Authorisierungen und Single-Sign-On sowie Accounting und Abbrechnungsmöglichkeiten.
  • Resource Grids
    Resource Grids sind die Erweiterung der Application Grids. Diese definieren ein Rollenmodell, in dem eindeutig zwischen einem Grid Benutzer, einem Grid Provider und einem Resource Provider unterschieden wird. Die Hierarchie ist logisch geordnert. Ein Grid Benutzer verwendet die Grid Infrastruktur des Grid Provider um die dort vorhandenen Ressourcen des Resource Providers zu nutzen. Für den Grid Benutzer unterscheidet sich die Funktionalität des Application- und des Resource Grids nicht. Das Konzept der beiden hat aber einen gravierenden Unterschied. Application Grids werden vertikal integriert, was bedeutet dass der Bedarf an Fremdleistungen sehr gering gehalten wird und die Komponenten individuell hinzugefügt werden. Dagegen müssen bei einem Resource Grid alle Schnittstellen definiert und offen gelegt werden, da jeder Ressource Provider über die Spezifikation der Grid Infrastruktur des Grid Providers informiert sein muss um dort ggf. seine Ressourcen anbieten zu können.
  • Service Grids
    Ein Service Grid verbindet das Konzept der Serviceorientierung mit der Technik der Resource Grids. Ein Service wird in diesem Zusammenhang als ein Bündel von mehreren Komponenten betrachtet, von dem jede einzelne Komponente wiederum als Utility von einem anderen Resource Provider zur Verfügung gestellt wird. In dieser Form des Grids existiert eine übergeordnete Form des Grid Providers, der so genannte Grid Service Provider, der im direkten Kontakt mit den Grid Benutzern steht und ihnen einen Komplettservice anbietet. Das bedeutet, dass der Grid Benutzer nicht darüber informiert ist, welcher Resource Provider ihm welche Ressource bereitstellt.


Skalierung eines Cluster mit Amazon EC2

Dieses Beispiel zeigt welche Komponenten erstellt und konfiguriert werden müssen, um einen Mini Cluster innerhalb eines privaten Netzwerks unter der Verwendung von NIS und NFS aufzubauen. Zusätzlich werden externe Amazon EC2 Nodes per VPN mit dem Server verbunden und am Ende der Cluster mittels der Sun Grid Engine (SGE) aufgebaut.

Architektur

Folgende technische Voraussetzungen werden benötigt:

  • Das private Netzwerk darf nur über ein VPN erreichbar sein, damit die Nodes die sich darin befinden vollständig isoliert sind.
  • Der Server muss NFS, NIS und VPN unterstützen.
  • Die internen Nodes müssen den NFS und NIS Dienst automatisch vom Server starten.
  • Die externen Nodes sind von Amazon EC2.
  • Die externen Nodes müssen automatisch eine Verbindung in das VPN aufbauen und den NFS und NIS Dienst vom Server starten.

Auf Basis dieser Anforderungen werden 3 Images benötigt.

  • 2 Xen Images - einen Server und einen internen Node
  • 1 Amazon Machine Image (AMI) von Amazon EC2 mit derselben Konfiguration wie der interne Node.

Die Konfigurationen sehen in diesem Beispiel wie folgt aus:

Server

  • Private IP-Adresse: eth0 10.1.1.99
  • Öffentliche IP-Adresse: eth1 147.96.1.100
  • Hostname: oneserver

Xen Node (lokal)

  • Private IP-Adresse: eth0 10.1.1.55
  • Hostname: local01

Amazon EC2 Node (IP-Adress Bereich: 10.1.1.100 bis 10.1.1.254)

  • VPN IP-Adresse: tap0 10.1.1.100 (wird durch den VPN Server vergeben)
  • Öffentliche IP-Adresse: eth0 - wird automatisch von Amazon vergeben
  • Hostname: workernode0

Konfiguration

Konfiguration der Images

Nun wird eine Kopie des Image erstellt und die /etc/hostname und /etc/network/interfaces für den Server (oneserver) editiert. Eine weitere Kopie des Image dient als Node, die oben genannten Dateien müssen für diesen ebenfalls angepasst werden. Nach dem unmount der Images werden diese mit Xen gestartet. Für die Konfiguration von NFS und NIS helfen die beiden nachfolgend verlinkten Howtos.

Bei der Konfiguration des VPN Server ist darauf zu achten, dass alle Clients die Zertifikate doppelt verwenden können. Das liegt daran, da keine separaten Amazon EC2 Instanzen erstellt werden sollen und es sich bei den EC2 Instanzen daher um dieselben handelt. Dazu muss in der Konfigurationsdatei von OpenVPN /etc/openvpn/server.conf in Zeilt "duplicate-cn" eingefügt werden. Die Konfiguration von OpenVPN findet nur auf dem Server statt. Eine Howto für die Konfiguration von OpenVPN ist unter dem folgenden Link zu finden.

Für das Erstellen eines Amazon Machine Images wird der Befehl bundle benötigt, dazu kann der lokale Node genutzt werden. Weiterhin muss der VPN Client und die Sun Grid Engine installiert und konfiguriert werden. Auf dem schnellsten Wege sollte das funktionieren, indem eine Kopie des lokalen Node erstellt und konfiguriert wird, anschließend wird es mit dem Befehl ec2-bundle-image gebündelt.

Während des Boot-Vorgangs wird nun noch ein Skript benötigt, in welchem der IP-Adressbereich von OpenVPN für die Amazon EC2 Instanzen von 10.1.1.100 bis 10.1.1.254 reserviert wird. die Konfiguration erfolgt in der /etc/hosts auf dem Server (oneserver).

EC2 Konfiguration mit OpenNebula

Nach der Konfiguration werden nun die Templates benötigt, um die Maschinen zu starten. Für alle lokalen Maschinen wie den oneserver und die Nodes wird jeweils ein Template benötigt, für die EC2 Maschinen reicht ein Template aus.

clouduser@machine:bin$ ec2-describe-images
IMAGE ami-e4a94d8d one-w2/image.manifest.xml 587384515363 available private i386 machine
IMAGE ami-cdb054a4 sge-dolphin/image.manifest.xml 587384515363 available private i386 machine
IMAGE ami-d8b753b1 sge-parrot/image.manifest.xml 587384515363 available private i386 machine
IMAGE ami-dcb054b5 sge-squirrel/image.manifest.xml 587384515363 available private i386 machine

Auf Basis des Images "ami-dcb054b5" wird das EC2 Template erstellt.

CPU=1

MEMORY=1700

EC2=[ AMI="ami-dcb054b5", KEYPAIR="gsg-keypair", ELASTICIP="75.101.155.97", INSTANCETYPE="m1.small", AUTHORIZED_PORTS="22-25"]

REQUIREMENTS = 'HOSTNAME = "ec2"'

Deployment und Tests

Um den Test zu starten muss zunächst OpenNebula gestartet und der EC2 Host hinzugefügt werden.

clouduser@machine:one$ one start
oned and scheduler started
lgonzalez@machine:one$ onehost create ec2 im_ec2 vmm_ec2
lgonzalez@machine:one$ onehost list
HID NAME RVM TCPU FCPU ACPU TMEM FMEM STAT
0 ec2 0 0 100 on

Als nächstes wird die EC2 Instanz gestartet.

clouduser@machine:one$ onevm create ec2.template
ID: 0

Die virtuelle Maschine wird später automatisch auf Amazon EC2 bereitgestellt.

clouduser@machine:one$ onevm list
ID NAME STAT CPU MEM HOSTNAME TIME
0 one-0 pend 0 0 00 00:00:05
lgonzalez@machine:one$ onevm list
ID NAME STAT CPU MEM HOSTNAME TIME
0 one-0 boot 0 0 ec2 00 00:00:15

Mittels onevm show id können alle Informationen eingesehen werden.

clouduser@machine:one$ onevm show 0
VID : 0
AID : -1
TID : -1
UID : 0
STATE : ACTIVE
LCM STATE : RUNNING
DEPLOY ID : i-1d04d674
MEMORY : 0
CPU : 0
PRIORITY : -2147483648
RESCHEDULE : 0
LAST RESCHEDULE: 0
LAST POLL : 1216647834
START TIME : 07/21 15:42:47
STOP TIME : 01/01 01:00:00
NET TX : 0
NET RX : 0

....: Template :....
CPU : 1
EC2 : AMI=ami-dcb054b5,AUTHORIZED_PORTS=22-25,ELASTICIP=75.101.155.97,INSTANCETYPE=m1.small,KEYPAIR=gsg-keypair
IP : ec2-75-101-155-97.compute-1.amazonaws.com
MEMORY : 1700
NAME : one-0
REQUIREMENTS : HOSTNAME = "ec2"

In diesem Beispiel ist die EC2 Instanz über die Adresse ec2-75-101-155-97.compute-1.amazonaws.com zu erreichen.

Nun muss geprüft werden, ob alle virtuellen Maschinen im Cluster gestartet sind. Es existiert eine lokale virtuelle Maschine auf Basis von Xen (local01) und eine von Amazon EC2 (workernode0).

oneserver:~# qstat -f
queuename qtype used/tot. load_avg arch states
----------------------------------------------------------------------------
all.q@local01 BIP 0/1 0.05 lx24-x86
----------------------------------------------------------------------------
all.q@workernode0 BIP 0/1 0.04 lx24-x86
----------------------------------------------------------------------------

Um den Cluster zu testen können ein paar Jobs mittels qsub an die Sun Grid Engine geschickt werden.

oneserver:~# qsub test_1.sh; qsub test_2.sh;

Nun ist zu sehen, welche Jobs im Hybrid Cluster geplant und gestartet sind.


clouduser@oneserver:~$ qstat -f
queuename qtype used/tot. load_avg arch states
----------------------------------------------------------------------------
all.q@local01 BIP 0/1 0.02 lx24-x86
----------------------------------------------------------------------------
all.q@workernode0 BIP 0/1 0.01 lx24-x86
----------------------------------------------------------------------------
############################################################################
- PENDING JOBS - PENDING JOBS - PENDING JOBS - PENDING JOBS - PENDING JOBS
############################################################################
1180 0.00000 test_1.sh clouduser qw 07/21/2008 15:26:09 1
1181 0.00000 test_2.sh clouduser qw 07/21/2008 15:26:09 1

clouduser@oneserver:~$ qstat -f
queuename qtype used/tot. load_avg arch states
----------------------------------------------------------------------------
all.q@local01 BIP 1/1 0.02 lx24-x86
1181 0.55500 test_2.sh clouduser r 07/21/2008 15:26:20 1
----------------------------------------------------------------------------
all.q@workernode0 BIP 1/1 0.07 lx24-x86
1180 0.55500 test_1.sh clouduser r 07/21/2008 15:26:20 1
----------------------------------------------------------------------------

Es können beliebig viele externe Amazon EC2 Instanzen automatisch zum Cluster als Nodes hinzugefügt werden und damit die Skalierbarkeit dynamisch erhöht werden.

Quelle



Skalierung von Web-Servern auf Amazon EC2

Dieses Beispiel zeigt, wie eine skalierbare Web Anwendung auf einer virtuellen Infrastruktur bereitgestellt wird. Um dies zu erreichen wird ein Load Balancer als Master Node für diese Web Anwendung eingesetzt. Hinter dem Load Balancer werden Slave Nodes eingesetzt, die über eine Kopie dieser Web Anwendung verfügen, für den Fall, dass eine Anfrage zu ihnen weitergeleitet wird. Die Leistung (Anfragen pro Sekunde) der Web Anwendung kann durch das Starten oder Herunterfahren von virtuellen Instanzen, die als Nodes des Load Balancer dienen, dynamisch erhöht oder verringert werden.

Ein Teil dieses Beispiels zeigt, wie Remote Nodes (Amazon EC2) eingesetzt werden, wenn die lokale Infrastruktur (auf Basis von Xen) ausgelastet ist.

Architektur

Folgende Komponenten werden für den Aufbau der virtuellen Infrastruktur genutzt:

  • Ein NGinx Server als Load Balancer - zur Aufteilung der Anfragen an die Webserver.
  • Mehrere NGinx Server als Webserver (die einzelnen Nodes des Load Balancer), die jeweils auf einer virtuellen Maschine ausgeführt werden.

Mit den folgenden Eigenschaften:

  • Die virtuellen Maschinen, auf welchen die Webserver ausgeführt werden, können sich lokal (auf dem Xen Hypervisor innerhalb der lokalen Infrastruktur) oder remote (auf Amazon EC2 Instanten) befinden.
  • Die Verwaltung (Monitoring, Deployment, Miration, ...) der virtuellen Maschinen wird mit OpenNebula vorgenommen.

Die obere Graphik beschreibt folgende Eigenschaften:

  • Die grünen Pfeile stehen für Web-Anfragen durch die Web-Clients an den Load Balancer.
  • Die roten Pfeile sind die Anfragen der Web-Clients, die von dem Load Balancer an die Webserver weitergeleitet werden.
  • Die orangen Pfeile stehen für das Monitoring und der Verwaltung durch den Virtual Machine Manager (OpenNebula).

Durch das dynamische Bereitstellen und Hinzufügen weiterer virtueller Webserver zu dem Load Balancer, verfügt diese Infrastruktur über eine hohe Fehlertoleranz, Verfügbarkeit und Skalierbarkeit. Darüber hinaus unterstützt die (virtuelle) Infrastruktur zwei unterschiedliche Virtualisierungs-Technologien (Xen und Amazon EC2), wodurch eine Erweiterung der lokalen Infrastruktur durch eine externe Infrastruktur möglich ist.

Konfiguration
Zunächst muss OpenNebula für das Deployment der virtuellen Infrastruktur konfiguriert werden. Weiterhin muss NGinx auf die Systeme installiert werden, die später den Load Balancer und die Webserver beherbergen sollen. Das Vorgehen dazu ist in dem folgenden Howto beschrieben.

Für die Konfiguration des Load Balancer gelten dieselben Schritte wie in dem oben genannten Howto. Als Konfigurationsdatei kann die nachfolgend aufgeführte genutzt werden. Hier ist der Host definiert, der als Load Balancer verwendet wird und welche Auswahlmethode (round-robin, gewichtet) genutzt werden soll.


clouduser@machine:one$ vim nginx.conf

user www-data;
worker_processes 1;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
access_log /var/log/nginx/access.log;
sendfile on;
keepalive_timeout 65;
tcp_nodelay on;
gzip on;
server {
listen 80;
server_name localhost;
access_log /var/log/nginx/localhost.access.log;
location / {
proxy_pass http://one_loadbalancer;
}
}
upstream one_loadbalancer {
server 10.1.1.11:80 ;
server 10.1.1.22:80 ;
server 10.1.1.33:80 ;
server 10.1.1.44:80 ;
}
}

Im Bereich upstream der Konfigurationsdatei werden die virtuellen Webserver definiert, auf welche die Anfragen für den Lastausgleich aufgeteilt werden. Hier müssen ggf. weitere virtuelle Webserver hinzugefügt werden.

In diesem Beispiel haben die Webserver die IP-Adressen 10.1.1.11, 10.1.1.22, 10.1.1.33 und 10.1.1.44. Damit können also vier Nodes verwendet werden.

Der Load Balancer verfügt über:

  • eine private IP-Adresse für die Kommunikation mit den Nodes im privaten Netzwerks. (in diesem Beispiel 10.1.1.99)
  • eine öffentliche IP-Adresse für die Kommunikation mit den Web-Clients und den Amazon EC2 Instanzen.

Die Amazon EC2 haben öffentliche IP Adressen und kommunizieren mit OpenNebula und dem Load Balancer über das Internet.

Um OpenNebula für die Kommunikation mit Amazon EC2 zu konfigurieren und die Instanzen mit NGinx bereitzustellen sind folgende Schritte notwendig.

Jetzt können die Templates für die lokalen und remote Machinen erstellt werden.

Für den Load Balancer wird folgendes Template verwendet:

clouduser@machine:one$ cat xen.loadbalancer
CPU = 0.5
MEMORY = 128
OS = [kernel="/boot/vmlinuz",initrd= "/boot/initrd",root="sda1" ]
DISK = [source="/images/loadbalancer.disk",target="sda",readonly="no"]

Die lokalen Maschinen verwenden diese Templates:

clouduser@machine:one$ cat xen.local01
CPU = 0.5
MEMORY = 128
OS = [kernel="/boot/vmlinuz",initrd= "/boot/initrd",root="sda1" ]
DISK = [source="/images/local01.disk",target="sda",readonly="no"]

Die Pfade zu den Images und dem Kernel müssen entsprechend der eigenen Umgebung angepasst werden. Aus den Images können beliebig viele Klone für die lokalen Nodes erstellt werden.

Die folgenden Templates werden für die remote Maschinen (Amazon EC2) verwendet.

clouduser@machine:one$ cat ec2.template
CPU=1
MEMORY=1700
EC2=[
AMI="ami-yao044b1",
KEYPAIR="gsg-keypair",
INSTANCETYPE="m1.small",
AUTHORIZED_PORTS="22-25"
]
REQUIREMENTS = 'HOSTNAME = "ec2"'

Die Parameter AMI Identifier, Key-Pair, Memory etc. müssen entsprechend der eigenen Umgebung angepasst werden.

Deployment und Test

Jetzt wird der virtuelle Cluster initialisiert. Zunächst wird der OpenNebula Daemon gestartet und mit dem onehost Befehl eine Host in die Liste der Ressourcen aufgenommen.

clouduser@machine:one$ one start
oned and scheduler started
clouduser@machine:one$ onehost create ec2 im_ec2 vmm_ec2
clouduser@machine:one$ onehost create ursa03 im_xen vmm_xen

Anschließend werden die virtuellen Maschinen mit dem onevm Befehl erstellt.

clouduser@machine:one$ onevm create xen.loadbalancer
ID: 0
clouduser@machine:one$ onevm create xen.local01
ID: 1
clouduser@machine:one$ onevm create xen.local02
ID: 2
clouduser@machine:one$ onevm create xen.local03
ID: 3
clouduser@machine:one$ onevm create xen.local04
ID: 4
clouduser@machine:one$ onevm create ec2.template
ID: 5
clouduser@machine:one$ onevm create ec2.template
ID: 6
clouduser@machine:one$ onevm create ec2.template
ID: 7
clouduser@machine:one$ onevm create ec2.template
ID: 8

Mit dem onevm Befehl kann anschließend der Status der Instanzen überprüft werden.

clouduser@machine:one$ onevm list
ID NAME STAT CPU MEM HOSTNAME TIME
0 one-0 runn 12 512 ursa03 00 00:01:15
1 one-1 runn 8 512 ursa03 00 00:01:11
2 one-2 runn 10 512 ursa03 00 00:01:10
3 one-3 runn 11 512 ursa03 00 00:01:02
4 one-4 runn 23 512 ursa03 00 00:00:51
5 one-5 runn 0 512 ec2 00 00:00:48
6 one-6 runn 0 512 ec2 00 00:00:48
7 one-7 runn 0 512 ec2 00 00:00:45
8 one-7 runn 0 512 ec2 00 00:00:43

Nachdem alle virtuellen Maschinen gestartet sind, kann der Load Balancer die Anfragen der Webclients annehmen. Nun muss noch für jede virtuelle Maschine die IP-Adresse in die /etc/nginx/nginx.conf eingetragen werden. Darüber wird dem NGinx Load Balancer mitgeteilt welcher Node bereit ist.

Die Leistung der Webanwendung kann durch das Hinzufügen weiterer lokaler oder Amazon EC2 Nodes mittels xen.localXX oder ec2.template und der Aktualisierung der Load Balancer Konfigurationsdatei erhöht werden.

Das Hinzufügen kann durch die Entwicklung eines Service Managers automatisiert werden.

Quelle



On-Demand Infrastruktur für virtuelle Labore

OpenNebula kann dazu genutzt werden um virtuelle Labore bereitzustellen. Dabei erhält jeder Student Zugriff auf eine eigene "virtuelle" Infrastruktur, die nur er verwalten kann. Bei der Infrastruktur kann es sich um ein einzelnes System oder ein vollständig verteiltes System handeln. Hierbei kapselt die virtuelle Maschine die Installation für einen Kurs.

Architektur

Aufbau & Bereitstellung

Um das virtuelle Labor bereitzustellen muss zunächst das Netzwerk, wie in den Howtos [1] und [2] beschrieben, konfiguiert werden.

Als nächstes muss ein Master Image erstellt werden. Dieses wird als Basis benutzt um die virtuellen Maschinen für eine Sitzung zu erstellen. In diesem Image muss sämtliche Software, für die späteren virtuellen Hosts des Labor, installiert sein. Aus dem Master Image können anschließend Instanzen von virtuellen Maschinen erstellt werden, indem von der Masterdatei jeweils eine Kopie erstellt wird.

Sobald die Master Virtual Machine konfiguriert ist, kann diese repliziert und als Virtual Machine Template für alle Instanz verwendet werden.

Dabei ist zu beachten, dass sich jede virtuelle Maschine in zwei Dingen voneinander unterscheiden muss:

  • Der Pfad zu dem Image, um die virtuelle Maschine zu mounten.
  • Die MAC-Adresse, da jede virtuelle Maschine eine eigene IP-Adresse benötigt.

Angenommen es sollen 10 virtuelle Computer für ein Labor erstellt werden. Dazu werden 10 unterschiedliche Kopien der Master Virtual Machine und 10 unterschiedliche Virtual Machine Templates benötigt. Die Templates könnten z.B. mit dem Namen VMachineXX.template - wobei XX den Zahlen 1 bis 10 entspricht - bezeichnet werden.

Um die virtuellen Maschinen zu starten wird der Befehl onevm mit folgenden Parametern benötigt.

$ onevm create VMachineXX.template

Dieser Befehl muss 10 mal wiederholt werden, wobei der Platzhalter XX durch die Zahlen 1 bis 10 ersetzt wird. Die IP-Adresse der virtuellen Maschine erhält man entsprechend der Netzwerk-Konfiguration.

Nun reicht es aus, dem Seminarteilnehmer einen Benutzernamen, ein Passwort und die IP-Adresse der virtuellen Maschine mitzuteilen.

Quelle



On-Demand Skalierung eines Computer 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



Erste Schritte mit der Ubuntu Enterprise Cloud

Das Eucalyptus System kann auf viele unterschiedliche Umgebungen beliebig angepasst werden. Diese Installations-Anleitung zeigt die Einrichtung einer Privat Cloud auf Basis von Eucalyptus mit der Ubuntu Enterprise Cloud.

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



Rackspace – Cloud Sites

Das Cloud Sites [1] Angebot von Rackspace gehört zu dem Bereich der klassischen Webhosting Angebote, wie man sie von jedem üblichen Anbieter kennt. Es dient zum Bereitstellen von statischen Webseiten, Weblogs wie z.B. Wordpress, Portalen wie Drupal, Joomla und DotNetNuke, Webshops oder Seiten für Marketing und Werbekampagnen. Der Zusatznutzen hebt sich von dem klassischen Webhosting dadurch ab, das die die Systeme auf denen sich die Webseiten befinden bei Bedarf automatisch skalieren und dadurch auch vor saisonalen Überlastungen geschützt sind.

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.


[2]

    Linux

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


[3]

    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


[4]

    DNS

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


[5]

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)



Was ist Cloud Computing?

Geschichte

Die grundlegenden Ideen und Konzepte des Cloud Computing reichen bis in die 1960er zurück. Schon damals hatte Prof. John McCarthy die Idee entwickelt Rechenleistung und Anwendungen als Utility der Öffentlichkeit gegen eine Nutzungsgebühr bereitzustellen. Dass der Durchbruch erst heute bevorsteht, hängt mit den technischen Voraussetzungen zusammen, die zur damaligen Zeit einfach noch nicht gegeben waren.

Kurz zusammengefasst beginnt die Entwicklung zum heutigen Cloud Computing in den 1960er mit dem Utility Computing, dessen Idee darin besteht, IT-Dienste und Rechenleistung nach Verbrauch abzurechnen. Dazu gesellten sich die Application Service Provider (ASP), die als Dienstleister über eine Datenverbindung Anwendungssoftware wie z.B. ein CRM-System (Customer Relationship Management) anbieten, das von einem Kunden gegen eine Nutzungsgebühr gemietet werden kann. Die oben bereits angesprochenen Probleme führten dazu, dass der Hype wieder abnahm und erst um 2000 herum unter dem neuen Namen Software as a Service (SaaS) wieder aufgenommen wurde. In den 1990er kam die Idee des Grid Computings auf, das als ein Ersatz für Supercomputer verstanden werden kann, indem verteilte Rechnerleistung nach Bedarf bezogen wird.

Cloud Computing - Historische Entwicklung

Der serviceorientierte Ansatz aus dem Bereich des Utility Computing und den Bereichen der ASP/ SaaS + dem technischen Ansatz des Grid Computings ergeben in der Summe das, was wir heute unter Cloud Computing verstehen.

Definition

Cloud Computing symbolisiert den service- und anwendungsorientierten Trend der heutigen Informationstechnologie, bei dem verteilte und hoch skalierbare Infrastrukturen über das Internet von einem oder mehreren Providern adaptiert werden können und Anwendungen und Dienste an jedem Ort und zu jeder Zeit verfügbar sind.

Erwartungen

Unternehmen können durch den Einsatz von Cloud Computing ihre IT-Gesamtausgaben deutlich reduzieren und die Qualität, Sicherheit aber vor allem ihre Arbeitsabläufe messbar steigern. Cloud Computing Anbieter können Skaleneffekte nutzen, indem sie ihre Kosten über eine große Anzahl von Kunden verteilen und haben damit die Möglichkeit die Investitionen in den Betrieb und die Sicherheit (Daten- und Zugangssicherheit) ihrer Rechenzentren im Vergleich zu herkömmlichen Rechenzentrums Betreibern zu erhöhen.