Kategorien
Management

Pinterest macht die Amazon Cloud für den eigenen Erfolg verantwortlich

Pinterest ist seit dem Start zu einem der Lieblinge im Internet geworden und hat ein beachtliches Wachstum zu verzeichnen. Ryan Park, Operations Engineer bei Pinterest, führt diesen Erfolg auf die Skalierbarkeit des Cloud Computing, genauer den Amazon Web Services zurück. Ohne Cloud Computing wäre der Erfolg von Pinterest nicht möglich gewesen, so Park kürzlich auf dem Amazon Web Services Summit in New York.

Pinterest ist eine Online Pinnwand. Es handelt sich dabei um einen Service der es erlaubt, Dinge zu sammeln und zu organisieren, die für jemanden von besonderem Interesse sind. Zudem können diese Dinge von anderen Nutzern auf der Pinnwand angeschaut werden.

Pinterest macht die Amazon Cloud für den eigenen Erfolg verantwortlich

Die Cloud hat es Pinterest ermöglicht, effizient zu arbeiten und kostengünstig zu experimentieren. Zudem konnte die Webseite sehr schnell wachsen, während sich nur ein sehr kleines Team um die Wartung kümmern musste. Im Dezember beschäftigte Pinterest insgesamt nur 12 Mitarbeiter. Laut der Rating Agentur ComScore konnte Pinterest im Monat März fast 18 Millionen Besucher gewinnen, eine 50-prozentige Steigerung gegenüber dem Vormonat. Die Webseite gehört demnach zu einer der am schnellsten wachsenden Webseiten in der Geschichte des Webs.

Pinterest setzt bei seinem Service auf Amazon S3 und Amazon EC2. Dabei ist die Nutzung von S3 seit dem letzten August um den Faktor 10 gestiegen. EC2 im selben Zeitraum um den Faktor 3. In Zahlen bedeutet das in etwa 80 Millionen Objekte die in Amazon S3 gespeichert sind, was ca. 410 Terabyte an Nutzerdaten entspricht.

Nach Park, wäre dies mit einem eigenen Rechenzentrum niemals möglich gewesen. Zunächst hätte das einen riesen Aufwand in Bezug auf die Kapazitätsplanungen bedeutet und die Hardware hätte noch bestellt und selbst installiert werden müssen. Zudem wäre Pinterest nicht in der Lage gewesen so schnell zu skalieren.

Aktuell nutzt Pinterest ca. 150 EC2 Instanzen, um damit die Kern Services bereitzustellen. Diese sind in Python geschrieben. Zudem setzt Pinterest auf das Django Framework. Der Traffic wird über die Instanzen mit Hilfe von Amazon ELB (Elastic Load Balancer) verteilt. Weitere 90 EC2 Instanten werden für das Caching eingesetzt und noch einmal 35 Instanzen für interne Zwecke.

Im Hintergrund der Anwendungen laufen etwa 70 Master-Datenbanken auf EC2 sowie eine Reihe von Backup-Datenbanken, die sich in verschiedenen Regionen auf der ganzen Welt befinden, um für die Redundanz zu sorgen.

Um seinen Nutzern Daten in Echtzeit zu liefern, sind die Datenbank-Tabellen über mehrere Server hinweg verteilt. Wenn ein Datenbankserver mehr als 50 Prozent Last fährt, wird die Hälfte des Inhalts auf einen anderen Server verschoben. Dieser Prozess wird auch als Sharding bezeichnet. Im vergangenen November nutzte Pinterest acht Master-Slave-Datenbank-Paare. Heute sind es schon 64 Paare.

Ein weiterer Vorteil, der Pinterest entgegenkommt, ist das pay-as-you-go Modell. Da Pinterest bei AWS nur für die Ressourcen bezahlt die sie benötigen, konnte Kapital gespart werden. Der meiste Datenverkehr entsteht in den USA während den Nachmittags-und Abendstunden. Mit Amazon Autoscaling fügt Pinterest in diesen Zeiträumen entsprechend mehr Instanzen hinzu, um die Anfragen zu bewältigen. In der Nacht werden die Instanzen dann wieder entfernt.

Mit diesem Ansatz ist Pinterest in der Lage, die Anzahl der Server die sie in der Nacht verwenden, um rund 40 Prozent zu reduzieren. Da Amazon pro Stunde abrechnet, führt diese Reduktion zu Kosteneinsparungen. Während der Lastspitzen, zahlt Pinterest etwa 52 US-Dollar pro Stunde für Amazon EC2. In den frühen Morgenstunden liegen die Kosten dann bei 15 US-Dollar pro Stunde.

Das pay-as-you-go Modell lässt Pinterest ebenfalls neue Services testen, ohne dafür langfristig in eigene Serverhardware- oder software zu investieren. Ein gelungenes Experiment war, laut Park, die Nutzung von Amazon Elastic Map Reduce, Amazons Hadoop-basierten Service für die Datenanalyse.

Fazit

Pinterest ist nur ein gutes Beispiel dafür, wie Cloud Computing dabei unterstützt neue Geschäftsmodelle mit einem minimalen Ressourcen- und Kapitalaufwand zu realisieren und im Erfolgsfall für die entsprechende Flexibilität und Skalierbarkeit zu sorgen.

Kategorien
News

DotCloud erweitert sein PaaS um vertikale Skalierung

Der Platform-as-a-Service Anbieter DotCloud erweitert sein PaaS Angebot um eine typische Infrastructure-as-a-Service Eigenschaft, der vertikalen Skalierung.

Im Normalfall skalieren PaaS Anbieter nur horizontal. In diesem Fall können die Nutzer ihren Code und den Traffic über mehrere Server verteilen und weitere Server hinzufügen, wenn die Last es erfordert.

Jedoch sind nicht alle Bereiche einer Anwendung in der Lage auf diesem Weg zu skalieren. So müssen z.B. Datenbanken vertikal skalieren wenn die Datenmenge steigt. Um vertikal zu skalieren, werden die Systeme mit mehr Arbeitsspeicher und Rechenleistung erweitert und nicht mit Servern.

Nicht jeder PaaS Anbieter unterstützt Datenbanken, daher ist die vertikale Skalierung für sie nicht von besonderer Bedeutung. Jedoch werden auch diese Anbieter in Zukunft nicht mehr um dieses Thema herumkommen. Kunden verlangen immer mehr Kontrolle wie sie es von IaaS Angeboten gewohnt sind. So kann ein AWS Nutzer z.B. eigenständig mehr RAM und Rechenleistung hinzufügen und sich zudem Bibliotheken und Softwareversionen selbst aussuchen, die er einsetzen möchte. Ein gewöhnliches PaaS Angebot bietet diese granulare Kontrolle nicht, muss es zwangsläufig aber auch nicht! Jedoch entwickelt sich auch der PaaS Markt stetig fort.


Bildquelle: http://www.cisco.com

Kategorien
Tutorials

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

Kategorien
Tutorials

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

Kategorien
Tutorials

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