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
