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
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
