Vorbereitung

Zunächst benötigen wir einen oder mehrere “leere” physikalische Systeme (64bit) als Host für die virtuelle Infrastruktur sowie einen Desktop Computer inkl. Webbrowser, mit dem die webbasierte Management Konsole genutzt werden kann.

Der physikalische Server sollte mindestens über einen 64 bit x86 Prozessor mit Intel VT oder AMD-V Technologie verfügen sowie ein CD-ROM, DVD-ROM oder USB-Ports, um darüber die Installation mittels des Witsbits ISO zu ermöglichen. Der Arbeitsspeicher sollte eine Mindestgröße von 1GB RAM besitzen und die Festplatte sollte nicht zu klein ausfallen, da hier die virtuellen Festplatten und Snapshots der virtuellen Maschinen gespeichert werden.

Weiterhin benötigen wir eine für DHCP konfigurierte Netzwerkumgebung inkl. einer aktiven Internetverbindung. Der DHCP-Server wird IP Adressen für die physikalischen Hosts als auch die virtuellen Maschinen bereitstellen müssen. Jeder physikalische Host benötigt zudem eine Vielzahl an IP Adressen, je nach Anzahl der virtuellen Maschinen, die auf ihm laufen sollen.

Für die Verwaltung der GoCloud Infrastruktur wird ein gewöhnlicher Desktop PC mit Windows, Linux oder Mac Betriebssystem oder ein Smartphone benötigt. Die Managementoberfläche unterstützt derzeit den Internet Explorer 7 und 8, Firefox, Chrome/Chromium und Safari.

Installation und Einrichtung von Go Cloud

Als erstes benötigen wir einen Go Cloud Account. Nach der erfolgreichen Registrierung laden wir uns das ISO Image (ca. 180 MB) herunter und entpacken es.

Nun erstellen wir uns aus dem ISO Image entweder eine bootbare CD/DVD oder einen USB-Stick. Anschließend starten wir den physikalischen Server mit dem ISO Image. Voraussetzung hierfür ist, dass der Server via eines DHCP Servers IP Adressen empfangen kann und das eine aktive Internetverbindung besteht. Der physikalische Host wird sich nun automatisch mit dem Go Cloud Management System verbinden. Nach dem Bootvorgang kann die CD/DVD oder der USB-Stick entfernt werden und dieselbe Prozedur kann mit dem nächsten physikalischen Server erfolgen.

Das zuvor heruntergeladene ISO Image ist mit einer persönlichen Account-ID gekennzeichnet, wodurch alle Server die mit dem ISO Image gebootet werden automatisch an dem Go Cloud Management System dieses Accounts registriert werden. Nachdem das Host System vollständig gebooted wurde, erscheint es auf der Management Konsole in der Weboberfläche. Der physikalische Server ist nun soweit vorbereitet, um virtuelle Maschinen zu starten.

Verwaltung der physikalischen Server und virtuellen Maschinen

Um einen physikalischen Server zu konfigurieren klicken wir in der Web Konsole zunächst auf “Physical Servers”. Hier sollte nun ein neuer Server mit einem Datum sowie einem Timestamp zu sehen sein. Hier wählen wir nun “New Server” und anschließend “Initiate Disks”. Das kann einen Moment dauern. Das darauf folgende Pop-Up bestätigen wir. Go Cloud sucht nun die größte Festplatte, entfernt von dieser alle Partitionen und erstellt eine Große. Wir müssen nun ein paar Mal aktualisieren (F5) bis der “Update Repo (Repository)” Button aktiv ist. Nachdem die Festplatte initialisiert ist, sollte auch die Queue leer sein. Wir klicken anschließen den “Update Repo (Repository)” Button.

Die Public Images von Go Cloud werden nun heruntergeladen und extrahiert. Abhängig von der Internetverbindung kann dieses bis zu 15 Minten dauern. Nach Beendigung wird dieser Job aus der Queue verschwinden.

Um eine erste virtuelle Maschine (VM) auf dem physikalischen Host zu erstellen, geben wir der VM als erstes einen Namen und hinterlegen für das Image ein Passwort. Als nächstes wählen wir ein Image bzw. Gast Betriebssystem und entscheiden uns für die Anzahl an CPUs sowie die Größe des zuzuweisenden Arbeitsspeichers. Mit dem klick auf den Button “Power On” wird ein neues VM Image erstellt, welches unten angezeigt wird. Der Status des Image sollte grün (OK) sein sowie die VM eine zugewiesene IP Adresse haben.

Per Remote Desktop, dem Administrator Passwort und dem Image Passwort der erstellten VM kann die VM nun gestartet werden. Für die Anmeldung benötigen wir hier das Passwort des VM Image und nicht das Passwort für die Anmeldung an Go Gloud.

Quelle: Witsbits

1 physikalisches System (Nicht für den produktiven Einsatz empfohlen)

Dies ist die einfachste mögliche Konfiguration. Dabei werden der CLC/Walrus/CC/SC und NC alle gemeinsam auf einer einzigen Maschine betrieben. Diese Konfiguration unterscheidet sich nicht von allen anderen möglichen. Der einzige Unterschied besteht darin, dass der Netzwerkverkehr hierbei nicht durch das lokale Netzwerk übertragen wird.

1. Maschine A: CLC/Walrus/CC/SC/NC

Beispiel Konfiguration (für ein bestehendes LAN)

Netzwerk Konfiguration:

• Netzwerk: 192.168.1.0/24
• DHCP und DNS Server: 192.168.1.2
• UEC Server: 192.168.1.4
• /etc/network/interfaces auf dem UEC Server

iface eth0 inet manual

auto br0
iface br0 inet static
    address 192.168.1.4
    netmask 255.255.255.0
    network 192.168.1.0
    broadcast 192.168.1.255
    gateway 192.168.1.2
    # dns-* options are implemented by the resolvconf package, if installed
    # these are google's dns servers
    dns-nameservers 8.8.8.8 8.8.4.4
    # this setting could be "local" if you all your local hosts
    #  were named something like a.localdomain b.localdomain c.localdomain etc
    dns-search localdomain
    bridge_ports eth0
    bridge_fd 9
    bridge_hello 2
    bridge_maxage 12
    bridge_stp off

• /etc/eucalyptus/eucalyptus.conf – wichtige Einträge:

VNET_PUBINTERFACE="br0" # must match the br definition above
VNET_PRIVINTERFACE="br0" # must match the br definition above
VNET_MODE="MANAGED-NOVLAN"
VNET_SUBNET="172.19.0.0" # ips from this range are bound to $VNET_PRIVINTERFACE:priv
VNET_NETMASK="255.255.0.0"
VNET_DNS="192.168.1.2" # what DNS server nodes are given
# v - should be ips on the LAN, not in use anywhere, and excluded from the DHCP server
VNET_PUBLICIPS="192.168.1.100-192.168.1.110"

Sollten das Netzwerk nach der Konfiguration nicht starten helfen die folgenden Befehle beim Korrigieren.

sudo stop eucalyptus CLEAN=1
sudo /etc/init.d/eucalyptus-nc stop
# fix the config file here
sudo start eucalyptus CLEAN=1
sudo /etc/init.d/eucalyptus-nc start

Der Parameter CLEAN sorgt dafür, dass sich das Netzwerk nicht bei jedem Neustart resetet. Es sollte darauf geachtet werden, dass kein System auf die ETH0 Schnittstelle gebunden ist. Um sicherzugehen, dass man mit einer sauberen Konfiguration arbeiten kann, ist ein Neustart des gesamten Systems. Wurde die PRIV Schnittstelle falsch konfiguriert, werden die Nodes ihre DHCP-Antworten von dem LAN-DHCP-Server anstelle des privaten CC-DHCP-Server erhalten.

Mindestens 2 physikalische Systeme

Bei dieser Konfiguration werden alle Verwaltungskomponenten für den Benutzer wie CLC und Walrus, sowie die Verwaltungskomponenten für das Backend wie der CC und SC auf einer gemeinsamen Maschine installiert. Der NC für das Hosting der virtuellen Maschinen erhält eine eigene physikalische Maschine.

1. Maschine A: CLC/Walrus/CC/SC
2. Maschine B: NC
3. (weitere NCs…)

Mindestens 3 physikalische Systeme

Bei dieser Konfiguration werden die Verwaltungskomponenten für den Benutzer wie CLC und Walrus auf eine physikalische Maschine, sowie die Verwaltungskomponenten für das Backend wie der CC und SC auf einer weiteren zweiten Maschine installiert. Der NC für das Hosting der virtuellen Maschinen wird auf eine dritte physikalische Maschine installiert.

1. Maschine A: CLC/Walrus
2. Maschine B: CC/SC
3. Maschine C: NC
4. (weitere NCs…)

Mindestens 4 physikalische Systeme

Bei dieser Konfiguration erhalten der CLC und Walrus jeweils eine eigene physikalische Maschine. Auf die dritte Maschine werden der CC und SC installiert. Für den NC wird eine vierte physikalische Maschine eingesetzt.

1. Maschine A: CLC
2. Maschine B: Walrus
3. Maschine C: CC/SC
4. Maschine D: NC
5. (weitere NCs…)

Mindestens 5 physikalische Systeme

Für diese Konfiguration werden der CLC und der Walrus auf einer gemeinsamen Maschine konfiguriert. Auf eine dritte Maschine werden der CC1 sowie der SC1 installiert. Für den NC1 kommt eine eigene Maschine zum Einsatz. Um die Performance der Cloud zu erhöhen und die Last besser zu verteilen, werden auf einer vierten Maschine ein CC2 und ein SC2 konfiguriert. Auf eine fünfte Maschine wird ein NC2 installiert, der anschließend seine Ressourcen von dem CC2 und SC2 erhält.

1. Maschine A: CLC/Walrus
2. Maschine B: CC1/SC1
3. Maschine C: NC1
4. Maschine D: CC2/SC2
5. Maschine E: NC2
6. (weitere CCs/SCs/NCs…)

Quelle: UECTopologies

1. Los geht es mit einer neuen CentOS 5.5 Installation

Während der Installation des Systems nehmen wir eine manuelle Partitionierung vor und erstellen 3 Partitionen:

1. primary ext3 mounted at / (the rootfs)
2. primary swap
3. primary “lvm” (wird zum Speichern des Server-Image benötigt)

An dieser Stelle ist es wichtig zu beachten, ein benutzerspezifisches Partitionsschema zu wählen und eine dedizierte Partition zu erstellen, auf der später die Server-Images gespeichert werden. (/dev/hda3). Bei der Paketauswahl selektieren wird zudem das “Gnome Desktop Environment”. Weitere Software wird nicht benötigt.

Wichtig: SELinux und die Firewall müssen deaktiviert werden!

Wenn die Installation abgeschlossen ist, starten wir das System neu und melden uns an.

Die folgende Konsolenausgabe zeigt die exakte CentOS Version. Alle Konsolenbefehle in diesem Tutorial werden des Weiteren mit “root” ausgeführt.

[root@cloud ~]# lsb_release -a
LSB Version: :core-3.1-ia32:core-3.1-noarch:graphics-3.1-ia32:graphics-3.1-noarch
Distributor ID: CentOS
Description: CentOS release 5.5 (Final)
Release: 5.5
Codename: Final
[root@cloud ~]#

2. Vorbereiten des Netzwerks

Nun bearbeiten wir die /etc/sysconfig/network-scripts/ifcfg-eth0 und tragen eine statische, private IP-Adresse ein. (In diesem Beispiel: 192.168.88.6)

[root@cloud network-scripts]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
HWADDR=00:02:b3:a0:d3:12
ONBOOT=yes
DHCP_HOSTNAME=cloud
IPADDR=192.168.88.6
NETMASK=255.255.255.0
GATEWAY=192.168.88.1
TYPE=Ethernet
[root@cloud network-scripts]#

Um die Änderungen zu übernehmen, starten wir das Netzwerk neu.

[root@cloud network-scripts]# /etc/init.d/network restart
Shutting down interface eth0: [ OK ]
Shutting down loopback interface: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface eth0:
[ OK ]
[root@cloud network-scripts]#

Nun hinterlegen wir die statische IP-Adresse (in unserem Fall “192.168.88.6″) und den Hostname (in unserem Fall “cloud”) in der /etc/hosts. Der Hostname darf hierbei nicht in der ersten Zeile zusammen mit 127.0.0.1 stehen!

[root@cloud ~]# cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost
192.168.88.6 cloud
::1 localhost6.localdomain6 localhost6
[root@cloud ~]#

3. Vorbereiten des Speicherplatz für die Server-Images

Nun bereiten wir die dedizierte Partition so vor, dass sie zusammen mit lvm genutzt werden kann. Anschließend erstellen wir eine Logical Volume Group “vol”.

[root@cloud ~]# pvcreate /dev/hda3
Physical volume "/dev/hda3" successfully created
[root@cloud ~]# vgcreate vol /dev/hda3
Volume group "vol" successfully created
[root@cloud ~]# vgs
VG #PV #LV #SN Attr VSize VFree
vol 1 0 0 wz--n- 186.22G 186.22G
[root@cloud ~]#

4. Installation des Enterprise iSCSI Target

Seitdem CentOS das “ietd” (Enterprise iSCSI Target) nicht mehr als Standard RPM Paket unterstützt, müssen wir dieses nun aus den Sourcen erstellen.

[root@cloud ~]# yum -y install kernel-devel openssl-devel gcc rpm-build
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
.... 
Complete!
[root@cloud ~]#

Wir erstellen ein ietd Verzeichnis und laden und entpacken die letzte iscsi-target-[version].tar.gz Version von http://iscsitarget.sourceforge.net

[root@cloud ~]# mkdir ietd
[root@cloud ~]# cd ietd/
[root@cloud ietd]# wget http://sourceforge.net/projects/iscsitarget/files/iscsitarget/1.4.20.1/iscsitarget-1.4.20.1.tar.gz/
.... 
2002-06-10 20:41:12 (245 KB/s) - `iscsitarget-1.4.20.1.tar.gz' saved [137487/137487]
[root@cloud ietd]# tar -xzf iscsitarget-1.4.20.1.tar.gz
[root@cloud ietd]# cd iscsitarget-1.4.20.1

Kompilieren:

[root@cloud iscsitarget-1.4.20.1]# make
Applying Patch compat-2.6.32.patch
patching file kernel/conn.c
Applying Patch compat-2.6.31.patch
.... 
CC [M] /root/ietd/iscsitarget-1.4.20.1/kernel/seq_list.o
LD [M] /root/ietd/iscsitarget-1.4.20.1/kernel/iscsi_trgt.o
Building modules, stage 2.
MODPOST
CC /root/ietd/iscsitarget-1.4.20.1/kernel/iscsi_trgt.mod.o
LD [M] /root/ietd/iscsitarget-1.4.20.1/kernel/iscsi_trgt.ko
make[1]: Leaving directory `/usr/src/kernels/2.6.18-194.3.1.el5-i686'

Installieren:

[root@cloud iscsitarget-1.4.20.1]# make install
`usr/ietd' -> `/usr/sbin/ietd'
`usr/ietadm' -> `/usr/sbin/ietadm'
`etc/initd/initd.redhat' -> `/etc/init.d/iscsi-target'
install: creating directory `/etc/iet'
`etc/ietd.conf' -> `/etc/iet/ietd.conf'
`etc/initiators.allow' -> `/etc/iet/initiators.allow'
`etc/targets.allow' -> `/etc/iet/targets.allow'
`doc/manpages/ietadm.8' -> `/usr/share/man/man8/ietadm.8'
`doc/manpages/ietd.8' -> `/usr/share/man/man8/ietd.8'
`doc/manpages/ietd.conf.5' -> `/usr/share/man/man5/ietd.conf.5'
install: creating directory `/usr/share/doc/iscsitarget'
`ChangeLog' -> `/usr/share/doc/iscsitarget/ChangeLog'
`COPYING' -> `/usr/share/doc/iscsitarget/COPYING'
`RELEASE_NOTES' -> `/usr/share/doc/iscsitarget/RELEASE_NOTES'
`README' -> `/usr/share/doc/iscsitarget/README'
`README.vmware' -> `/usr/share/doc/iscsitarget/README.vmware'
`README.initiators' -> `/usr/share/doc/iscsitarget/README.initiators'
`kernel/iscsi_trgt.ko' -> `/lib/modules/2.6.18-194.3.1.el5/extra/iscsi/iscsi_trgt.ko'
Running depmod
[root@cloud iscsitarget-1.4.20.1]#

Verlinken den Ablageort der ietd.conf Konfigurationsdatei.

[root@cloud ~]# mv /etc/iet/ietd.conf /etc/iet/ietd.conf.org
[root@cloud ~]# > /etc/ietd.conf
[root@cloud ~]# ln -s /etc/ietd.conf /etc/iet/ietd.conf
[root@cloud ~]#

Und starten das iSCSI-Target:

[root@cloud ~]# /etc/init.d/iscsi-target start
Starting iSCSI Target: [ OK ]
[root@cloud ~]#

5. Vorbereiten der Datenbank

Als Datenbank für den openQRM Server nutzen wir das Package “mysql-server”.

[root@cloud ~]# yum -y install mysql-server
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
.... 
Complete!
[root@cloud ~]#

Nach der Installation starten wir den mysqld service.

[root@cloud ~]# /etc/init.d/mysqld start
Initializing MySQL database: Installing MySQL system tables...
100521 14:44:53 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
100521 14:44:53 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
OK
Filling help tables...
100521 14:44:53 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
100521 14:44:53 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
OK
To start mysqld at boot time you have to copy
support-files/mysql.server to the right place for your system
PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER !
To do so, start the server, then issue the following commands:
/usr/bin/mysqladmin -u root password 'new-password'
/usr/bin/mysqladmin -u root -h cloud password 'new-password'
Alternatively you can run:
/usr/bin/mysql_secure_installation
which will also give you the option of removing the test
databases and anonymous user created by default. This is
strongly recommended for production servers.
See the manual for more instructions.
You can start the MySQL daemon with:
cd /usr ; /usr/bin/mysqld_safe &
You can test the MySQL daemon with mysql-test-run.pl
cd mysql-test ; perl mysql-test-run.pl
Please report any problems with the /usr/bin/mysqlbug script!
The latest information about MySQL is available on the web at

http://www.mysql.com

Support MySQL by buying support/licenses at http://shop.mysql.com
[ OK ]
Starting MySQL: [ OK ]
[root@cloud ~]#

Nun prüfen wir, dass wir uns mit der Datenbank verbinden können.

[root@cloud ~]# mysql
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 2
Server version: 5.0.77 Source distribution
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql> quit
Bye
[root@cloud ~]#

Und fügen mysqld zu den init Startskripten mittels chkconfig hinzu.

[root@cloud bin]# chkconfig --add mysqld
[root@cloud bin]# chkconfig mysqld on
[root@cloud bin]# chkconfig --list mysqld
mysqld 0:off 1:off 2:on 3:on 4:on 5:on 6:off
[root@cloud bin]#

6. Installation von openQRM

openQRM wird in diesem Tutorial aus den Sourcen erstellt. Diese sind in dem Subversion Repository des openQRM Projects verfügbar. Für die Installation sind hier lediglich ein Subversion Client und “make” notwendig. Diese sollten also installiert werden.

[root@cloud ~]# yum -y install subversion
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
.... 
Complete!
[root@cloud ~]#

Nun müssen die openQRM Sourcen aus dem SVN Repository ausgecheckt werden.

[root@cloud ~]# svn co https://openqrm.svn.sourceforge.net/svnroot/openqrm openqrm
.... 
A openqrm/trunk/src/rpm/README
A openqrm/trunk/src/rpm/openqrm-entire.spec
A openqrm/branches
A openqrm/tags
Checked out revision 1996.
[root@cloud ~]#

Wir wechseln in das src/ Verzeichnis.

[root@cloud ~]# cd openqrm/trunk/src/
[root@cloud src]#

Anschließend führen wir “make” aus. Dafür wird eine funktionsfähige Internetverbindung benötigt. Sollte dieses nicht der Fall sein, können die Sourcen auch von http://sourceforge.net/projects/openqrm/files/openQRM-4.6/source/openqrm-thirdparty-cache.tgz/download heruntergeladen werden. Diese müssen danach in das Home-Verzeichnis entpackt werden.

[root@cloud src]# make
.... 
[root@cloud src]#

Alle Ergebnisse der Kompilierung werden vom openQRM-Build System automatisch gecached. Um sicherzustellen, dass alle Komponenten richtig erstellt wurden, kann “make” einfach erneut ausgeführt werden.

[root@cloud src]# make
Checking requirements for the compilation phase
openqrm-server requires: make, gcc, portmap, rsync, zlib-devel, wget, tar, bzip2, unzip, patch
found make installed
found gcc installed
found portmap installed
found rsync installed
found zlib-devel installed
found wget installed
found tar installed
found bzip2 installed
found unzip installed
found patch installed
openqrm-plugin-aoe-storage requires:
openqrm-plugin-aws requires:
openqrm-plugin-citrix requires:
openqrm-plugin-cloud requires:
openqrm-plugin-collectd requires:
openqrm-plugin-dhcpd requires:
openqrm-plugin-dns requires:
openqrm-plugin-equallogic-storage requires:
openqrm-plugin-highavailability requires:
openqrm-plugin-image-shelf requires:
openqrm-plugin-iscsi-storage requires:
openqrm-plugin-kvm requires:
openqrm-plugin-kvm-storage requires:
openqrm-plugin-linux-vserver requires:
openqrm-plugin-linuxcoe requires:
openqrm-plugin-local-server requires:
openqrm-plugin-local-storage requires:
openqrm-plugin-lvm-storage requires:
openqrm-plugin-nagios2 requires:
openqrm-plugin-nagios3 requires:
openqrm-plugin-netapp-storage requires:
openqrm-plugin-nfs-storage requires:
openqrm-plugin-puppet requires:
openqrm-plugin-sanboot-storage requires:
openqrm-plugin-solx86 requires:
openqrm-plugin-sshterm requires:
openqrm-plugin-tftpd requires:
openqrm-plugin-tmpfs-storage requires:
openqrm-plugin-vbox requires:
openqrm-plugin-vmware-esx requires:
openqrm-plugin-vmware-server requires:
openqrm-plugin-vmware-server2 requires:
openqrm-plugin-windows requires:
openqrm-plugin-xen requires:
openqrm-plugin-xen-storage requires:
openqrm-plugin-zabbix requires:
openqrm-plugin-zfs-storage requires:
Checking for required components to compile openQRM finished successfully
if [ -d ./thirdparty ]; then mkdir -p ../buildtmp; cp -aR ./thirdparty/* ../buildtmp/; fi
-> found component gpxe (undionly.kpxe.0.9.9.tgz) already downloaded
-> found component kvm-nic-bios (kvm-nic-bios-1.1.tgz) already downloaded
-> found component openqrm-client.windows (openQRM-Client-4.6.1-setup.exe) already downloaded
-> found component sshterm-component (openqrm-plugin-sshterm-components-1.0.tgz) already downloaded
Creating the default initrd-template
-> found component busybox (busybox-1.14.2.tar.bz2) already downloaded
-> Found busybox-1.14.2/_install/bin/busybox already in the build-cache
-> Skipping compilation, taking the ready built component from the cache
-> found component pciutils (pciutils-3.1.4.tar.gz) already downloaded
-> Found pciutils-3.1.4/pcimodules already in the build-cache
-> Skipping compilation, taking the ready built component from the cache
-> found component dropbear (dropbear-0.52.tar.gz) already downloaded
-> Found dropbear-0.52/dropbear already in the build-cache
-> Skipping compilation, taking the ready built component from the cache
Adding /sbin/portmap to default initrd-template
Adding /sbin/rpc.statd to default initrd-template
Adding /bin/bash to default initrd-template
Adding /usr/bin/rsync to default initrd-template
Adding /usr/bin/wget to default initrd-template
Adding /sbin/modprobe to default initrd-template
Adding /sbin/depmod to default initrd-template
Adding /sbin/insmod to default initrd-template
Adding /sbin/lsmod to default initrd-template
Adding /sbin/mke2fs to default initrd-template
Adding /sbin/sfdisk to default initrd-template
Adding /sbin/udevd to default initrd-template
Adding /lib/udev/vol_id to default initrd-template
-> found component gpxe (undionly.kpxe.0.9.9.tgz) already downloaded
-> found component kvm-nic-bios (kvm-nic-bios-1.1.tgz) already downloaded
-> found component openqrm-client.windows (openQRM-Client-4.6.1-setup.exe) already downloaded
-> found component sshterm-component (openqrm-plugin-sshterm-components-1.0.tgz) already downloaded
-> found component adodb (adodb498.tgz) already downloaded
-> found component jquery (jquery-1.3.2.tgz) already downloaded
-> found component js-interface (interface_1.2.zip) already downloaded
-> found component openqrm-client.centos.i386 (openqrm-client.4.6.1.centos.i386.tgz) already downloaded
-> found component openqrm-client.centos.x86_64 (openqrm-client.4.6.1.centos.x86_64.tgz) already downloaded
-> found component openqrm-client.debian.i386 (openqrm-client.4.6.1.debian.i386.tgz) already downloaded
-> found component openqrm-client.debian.x86_64 (openqrm-client.4.6.1.debian.x86_64.tgz) already downloaded
-> found component openqrm-client.ubuntu.i386 (openqrm-client.4.6.1.ubuntu.i386.tgz) already downloaded
-> found component openqrm-client.ubuntu.x86_64 (openqrm-client.4.6.1.ubuntu.x86_64.tgz) already downloaded
-> found component openqrm-initrd-template.centos.i386 (openqrm-initrd-template.4.6.1.centos.i386.tgz) already downloaded
-> found component openqrm-initrd-template.centos.x86_64 (openqrm-initrd-template.4.6.1.centos.x86_64.tgz) already download
-> found component openqrm-initrd-template.debian.i386 (openqrm-initrd-template.4.6.1.debian.i386.tgz) already downloaded
-> found component openqrm-initrd-template.debian.x86_64 (openqrm-initrd-template.4.6.1.debian.x86_64.tgz) already download
-> found component openqrm-initrd-template.ubuntu.i386 (openqrm-initrd-template.4.6.1.ubuntu.i386.tgz) already downloaded
-> found component openqrm-initrd-template.ubuntu.x86_64 (openqrm-initrd-template.4.6.1.ubuntu.x86_64.tgz) already download
[root@cloud src]#

Nun führen wir “make install” aus.

[root@cloud src]# make install
include/
include/openqrm-plugin-local-storage-functions
bin/
.... 
Creating the openqrm-client boot-service package
[root@cloud src]#

Am Ende initialisieren und starten wir openQRM mittels “sudo make start”.

[root@cloud src]# make start
Checking the requirements for RedHat based systems ...
openqrm-server requires: httpd, php, php-mysql, php-soap, mysql, syslinux, screen, procmail, openssl
-> found httpd installed
NOTICE: Trying to automatically install php ...
Loaded plugins: fastestmirror
.... 
Checking for required components finished successfully
Starting httpd: httpd: Could not reliably determine the server's fully qualified domain name, using 192.168.88.6 for Server
[ OK ]
First startup detected. Running initialization.
Looking for syslinux/pxelinux.0...found: /usr/lib/syslinux/pxelinux.0
Creating custom apache config.../etc/httpd/conf.d/openqrm-httpd.conf
Checking /usr/share/openqrm/etc/openqrm-server.conf for OP[ OK ]B_PROTOCOL=https..Reloading httpd:
Adding password for user openqrm
Initializing dropbear...
Will output 1024 bit rsa secret key to '/usr/share/openqrm/etc/dropbear/dropbear_rsa_host_key'
Generating key, this may take a while...
Public key portion is:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgmOa49UMeOPqid06cR96yfRD/SQ98J1REpLKyyJ518iFFQyGKb9j2quZD+8FfKYt6rgFgS6
kGw95qJf6lqYc/rIH5ezcl4bVCn0Zo9pQkTyF496+iAp6AbPOX9KfBivu+5KWc7sfxOiDWGErPhzTGSkvjxwDAu2PkXAvTjUHMhhXxLk= root@cloud
Fingerprint: md5 de:cc:34:cb:2b:e5:b1:3d:50:dd:cc:f0:b5:ca:e9:e5
Adding public key to /root/.ssh/authorized_keys...
Starting the openQRM-server ver. 4.6.
Initialization complete. Please configure your openQRM Server at: http://192.168.88.6/openqrm/
-> User: openqrm -> Password: openqrm
[root@cloud src]#

“make start” führt zusätzlich eine Check-Routine aus, die überprüft, dass alle Abhängigkeiten für die Einwandfreie Nutzung von openQRM vorhanden sind. Ggf. nicht vorhandene Pakete werden automatisch installiert.

Während des ersten Starts wird der openQRM Server initialisiert. Nachdem openQRM vollständig installiert wurde, kann nun die Konfiguration mittels der Weboberfläche vorgenommen werden.

7. Konfiguration von openQRM

Wir melden uns am openQRM Server per http://ip-adresse/openqrm an. Der Benutzer und das Passwort sind jeweils “openqrm”. Nach der Konfiguration sollten diese Daten geändert werden.

Als erstes wählen wir als Netzwerkkarte die Bridge Schnittstelle für das openQRM Management.

Als Datenbank für das openQRM Backend wählen wir “myslq”.

Anschließend konfigurieren wir die Verbindungsinformationen für die Datenbank.

openQRM ist nun vollständig konfiguriert.

Wir werden automatisch zum Datacenter Dashboard weitergeleitet.

8. Erstellen eines Windows Image

Mit dem Plugin-Manager müssen wir als nächstes die folgenden Plugins aktivieren und starten:

• dhcpd
• tftpd
• sanboot-storage
• windows
• cloud

Anschließend wechseln wir nach Base >> Components >> Create >> Storage. Dort erstellen wir einen neuen Speicher vom Typ “Sanboot-Storage (iSCSI)” und wählen den openQRM Server als Ressource.

Wir geben dem Storage Server einen Namen und speichern diesen.

Die Liste der verfügbaren Speicher sind nun wie folgt aus.

Wir klicken auf den “Mgmt” Button des neu erstellten “sanboot” Storage Server.

Hier wählen wir die Volume Group “vol”.

Nun erstellen wir ein neues Volume mit dem Namen “windowsxp″. Die Größe muss etwas größer sein als die der lokalen Festplatte des Systems, das verwendet wird, um das Image zu erstellen.

In unserem Tutorial verwenden wir eine 40 GB große lokale Festplatte, um ein Windows System zu installieren und zu einem LUN auf ein iSCSI-Target zu übertragen. Das Volume das wir erstellen hat eine Größe von 41GB und ist damit ein wenig Größer als die eigentliche physikalische Festplatte.

Mittels der Konsole würden wir wie folgt vorgehen:

[root@cloud ~]# lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
windowsxp vol -wi-ao 40.04G
[root@cloud ~]# cat /etc/ietd.conf
Target windowsxp:windowsxp
Lun 0 Path=/dev/mapper/vol-windowsxp,Type=fileio
[root@cloud ~]#

Installation von Windows auf der lokalen Festplatte des zweiten Systems

In diesem Tutorial verwenden wir Windows XP Professional und nutzen exakt die GPXE Anweisungen von http://etherboot.org/wiki/sanboot/winxp. Wir nutzen dazu eine frische Windows Installation und nehmen keine Partitionierung der Festplatte vor.

Achtung:

Es wird “Install local + Transfer to iSCSI Lun” verwendet, da Windows XP es nicht unterstützt, direkt auf einem iSCSI-Target installiert zu werden. Neuere Windows Version wie bspw. Windows 7 können dagegen direkt auf einem iSCSI-Target installiert werden, siehe dazu http://etherboot.org/wiki/sanboot/iscsi_install

Nachdem Windows installiert wurde, fügen wir die “iSCSI Boot” Unterstützung hinzu. Dazu gehen wir auf die Webseite http://etherboot.org/wiki/sanboot/winnt_iscsi und laden dort die für Windows passende “Initiator 2.x boot-buildxxx-arch/lang.exe” herunter. In unserem Fall i386/X86 EN.

Wir speichern die Datei auf unserem Desktop.

Wir führen die Datei aus und folgen den Anweisungen.

Nun laden wir den Windows SAN Boot Configuration Driver von http://etherboot.org/wiki/sanboot/winnt_sanbootconf herunter.

Die ZIp-Datei beinhaltet den SAN Boot Treiber. Wir entpacken den Inhalt auf unseren Desktop.

Nun starten wir den sanbootconf Installer und folgen den Anweisungen.

Damit ist die Installation abgeschlossen.

Übertragen des Festplatteninhalts mittels nc

Um den Inhalt der lokalen Festplatte des Windows Systems auf das iSCSI LUN auf dem “Sanboot” Storage Server zu übertragen, nutzen wir “nc” und “dd”. Weitere Informationen hierzu sind unter http://solutions.unixsherpa.com/2009/08/10/remote-mirroring-using-nc-and-dd zu finden.

Nach der Windows Installation starten wir das System neu und konfigurieren den Systemstart im BIOS so, dass das System vom Netzwerk aus (pxe-boot) gestartet werden kann. Anschließend wird das System nun innerhalb von openQRM als neue “idle” Ressource vom Typ “Physical System” gestartet.

Wenn sich das System im Status “idle” befindet müssen wir die folgenden Schritte vornehmen, um den Festplatteninhalt des physikalischen Windows Systems auf das iSCSI LUN zu übertragen:

1. Starten eines nc Listener auf dem logischen Windows Volume

[root@cloud ~]# ls /dev/mapper/vol-windowsxp
/dev/mapper/vol-windowsxp
[root@cloud ~]# nc -l 12345 | dd of=/dev/mapper/vol-windowsxp
# this command won't return but listen on port 12345 to submit data
# which it reads bitwise from the network port to /dev/mapper/vol-windowsxp

2. Mittels des “openqrm login” Befehl anmelden
Here the syntax of the “openqrm login” comand:

/usr/share/openqrm/bin/openqrm login -i [ip-address-of-the-idle-resource-withe-the-windows-installed-on-local-disk]

[root@cloud ~]# cd /usr/share/openqrm/bin/
[root@cloud bin]# ./openqrm login -i 192.168.88.251
Login to resource 192.168.88.251 ...
Host '192.168.88.251' key accepted unconditionally.
(fingerprint md5 ff:5f:e7:60:ae:14:74:4a:39:15:8c:a6:62:98:73:0b)
bash-3.2#

Wir müssen hierbei beachten, dass die Shell in diesem Fall über keine PATH Umgebung verfügt. Die Befehle müssen daher unter der Angabe des vollständigen Pfads ausgeführt werden.

Der folgende Befehl dient dazu, die lokale Festplatte der Windows Installation zu identifizieren.

bash-3.2# cat /proc/partitions
major minor #blocks name
8 0 39082680 sda
8 1 39070048 sda1
bash-3.2# /sbin/fdisk -l /dev/sda
Disk /dev/sda: 40.0 GB, 40020664320 bytes
255 heads, 63 sectors/track, 4865 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 4864 39070048+ 7 HPFS/NTFS
bash-3.2#

3. dd und nc gemeinsam nutzen

Um den Festplatteninhalt remote auf das logische Volume zu übertragen, nutzen wir die Kombination von dd und nc.

bash-3.2#
bash-3.2# dd if=/dev/sda | nc 192.168.88.6 12345

Abhängig von der Größe der Festplatte und der Geschwindigkeit des Netzwerks, kann dieser Vorgang ein Weile dauern.

Auf dem openQRM Server kann der Befehl “kill -USR1 [pid-of-dd-process]” genutzt werden, um zu sehen, wie viele Bytes dd bereits übertragen hat.

..
78165360+0 records in
78165360+0 records out
40020664320 bytes (40 GB) copied, 6322.11 seconds, 6.3 MB/s
[root@cloud ~]#

Nun führen für “sync” aus, um sicherzustellen, dass alle Bits auf das logische Volume übertragen wurden.

[root@cloud ~]# sync
[root@cloud ~]#

9. Vorbereiten des Windows Image

Wir schalten die Ressource die sich im Zustand “idle” befindet herunter (die Windows Installation auf der lokalen Festplatte), entfernen die Festplatte und starten sie über das Netzwerk neu.

Es sollte darauf geachtet werden, das die Bootreihenfolge auf “Network Boot only” steht.

Wenn das System neu gestartet ist und sich im Status “idle” befindet, erstellen wir erneut in logisches “Image” in openQRM.

Wir wechseln dazu nach Base >> Components >> Create >> Image und wählen den “Sanboot” Storage Server.

Anschließend geben wir dem Image einen Namen und wählen das “windowsxp″ Volume als das Root-Device.

Die Liste der verfügbaren Images sind nun wie folgt aus.

Nun erstellen wir eine “Appliance”. Dazu wechseln wir zu Base >> Appliance >> Create und wählen die Ressource “idle”.

Wir nennen die “Appliance” windowsxp, wählen den “default” kernel und das “windowsxp” Image und speichern die Appliance.

Wir starten die “Appliance”.

Das folgende Video auf YouTube zeigt den Systemstart des Windows Systems von dem iSCSI Storage Server.

Das Windows Image ist damit nun deployed und funktionsfähig. Nun müssen wir das Image so konfigurieren, damit es mittels openQRM verwaltet werden kann.

Dazu erstellen wir auf dem Windows Image im ersten Schritt einen Windows Benutzer mit dem Namen “root”.

Als nächstes muss der openQRM Client auf dem Windows Image installiert werden. Dazu öffnen wir einen Web-Browser und melden uns an den openQRM Server an.

Anschließend gehen wir zu Plugins >> Deployment >> Windows >> About

Hier laden wir den Windows openQRM-Client herunter.

Wir starten die openQRM-Client Installationsroutine und folgen den Anweisungen.

Now please run “gpedit.msc” and add the permission to “remote shutdown” to user “root”.

Wichtig: Sollte die Windows Firewall aktiviert sein, muss der TCP Port 22 geöffnet werden.

10. openQRM Cloud Konfiguration

Nun wechseln wir nach Plugins >> Cloud >> Configuration >> Main Config und konfigurieren die folgenden Punkte:

• cloud_admin_email > eine valide E-Mail Adresse
• auto_provision → true
• external_portal_url → (optional) externe URL zu einem Cloud Portal
• request_physical_systems → false
• auto_give_ccus → 100
• show_disk_resize → (optional) true
• show_private_image → true
• cloud_currency → (optional) auf US oder Euro setzen
• cloud_1000_ccus → Wie viele 1000 CCUs wie viel US/Euro entsprechen

Für alle weiteren Konfigurationspunkte können die Standardwerte genommen werden. Speichern nicht vergessen!

Der folgende Screenshot zeigt die Hauptseite zur Konfiguration der Cloud.

Als nächstes müssen die Cloud Produkte mittels des “Cloud-Selector” konfiguriert werden.

Dazu gehen wir nach Plugins >> Cloud >> Configuration >> Products >> Kernel und erstellen ein neues “Windows” Kernel Produkt.

Das sieht dann wie im folgenden Screenshot aus.

Nun erstellen wir ein “Memory” Produkt. Dieses muss den exakt verfügbaren Speicher aufweisen, das auf dem zweiten physikalischen System verfügbar ist. (Das System, welches das Windows Image deployed.) In diesem Tutorial verwenden wir ein System mit 3008 MB physikalischen Arbeitsspeicher. Dieser muss entsprechend angepasst werden.

Das sieht dann wie im folgenden Screenshot aus.

Nun erstellen wir ein “Physical System”.

Das sieht dann wie im folgenden Screenshot aus.

Der nächste Schritt besteht darin, der Cloud mitzuteilen, welche Images den Cloud Benutzern angezeigt werden sollen. Dazu wechseln wir nach Plugins >> Cloud >> Configuration >> Private Images und wählen in den Checkboxen “All” für das “windowsxp ” Image.

Nun erstellen wir einen oder mehrere Cloud Benutzer. Hierfür gehen wir nach Plugins >> Cloud >> User und fügen einen neuen Benutzer inkl. einer gültigen E-Mail Adresse hinzu. Als Cloud Administrator kann man sich mit jedem beliebigen Cloud Benutzer anmelden, indem man auf den Namen des Cloud Benutzers klickt.

Die Liste der Cloud Benutzer sieht im Anschluss wie folgt aus.

Das openQRM Portal sieht nach einem erfolgreichen Login dann wie folgt aus.

Wir klicken auf den 2ten Tab mit dem Namen “Visual Cloud Designer”.

Der Virtual Cloud Designer zeigt alle verfügbaren Komponenten innerhalb der Cloud an. Mittels Drag and Drop kann nun eine eigene Cloud Appliance konstruiert werden.

Anschließend sollten die Kosten (stündlich, täglich, moantlich) für die Appliance betrachtet werden.

Mit einem einzigen Klick kann die Appliance der Cloud hinzugefügt werden.

Für das Cloud Deployment erstellt openQRM automatisch ein LVM Snapshot für das ursprüngliche Windows Image. Das bedeutet, dass es sich bei der (remote) Festplatte des Windows Image eigentlich um ein LVM Snapshot handelt. Im Storage Manager ist das Cloud Volume daher mit einem “s” (Snapshot) gekennzeichnet.

Auf der Konsole verwendet man dazu den folgenden Befehl:

[root@cloud ~]# lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
2.cloud_1_1_ vol swi-ao 19.53G windowsxp 0.06
windowsxp vol owi-ao 40.04G
[root@cloud ~]#

Lizenzen:
Wichtig! Für das Deployment jedes einzelnen Windows Image ist eine entsprechende und gültige Windows Lizenz erforderlich.

11. Die nächsten Schritte

• Verwenden von Sanboot-Storage inkl. AOE Deployment
• Separierung des Storage, Hypvervisors und openQRM auf dedizierte Systeme
• openQRM Server als Hochverfügbarkeitslösung
• Hinzufügen weiterer virtualisierter Hosts unterschiedlichen Typs
• Hinzufügen von physikalischen Systemen
• Hinzufügen von weiteren Storage Systemen
• Aktivieren des automatischen Monitorings
• IP- und Netzwerkmanagement
• Cloud-Billing
• Cloud Integration / SOAP WebService

Quelle

• Howto: Setup openQRM Cloud deploying physical Windows Systems on CentOS 5.5

Erstellen einer JiffyBox

Zunächst melden wir uns dazu unter https://admin.jiffybox.de mit einem gültigen Benutzernamen und Passwort an, die wir unter https://www.jiffybox.de beantragen können.

Nach einer erfolgreichen Anmeldung werden wir im Control Panel begrüßt, wo wir im ersten Schritt mittels “Jetzt Trial-Server bestellen” einen kostenlosen Test der JiffyBox vornehmen können oder uns über “Neue JiffyBox erstellen” eine neue JiffyBox erzeugen. Wir wählen hier den zweiten Schritt.

Wir geben der neuen JiffyBox einen Namen, wählen einen Tarif, hier “CloudLevel 1 – mit 1 GB Arbeitsspeicher und 50 GB Festplatte für 0,02 € / Stunde” und eine Linux Distribution, hier “Ubuntu 10.04 LTS”. Würden wir bereits über eine JiffyBox verfügen, hätten wir als Distribution ebenfalls ein Backup als Quelle angeben können.

Unter dem Punkt “Erweitert” können wir der JiffyBox ein selbst gewähltes Root Passwort zuweisen. Anschließend wählen wir “Erstellen”.

Die JiffyBox wird nun automatisch im Hintergrund erzeugt. Statusinformationen zeigen dabei den aktuellen Vorgang!

Zurück im “Control Panel” sehen wir die erzeugte JiffyBox und können nun mittels “Konfigurieren” weitere Einstellungen vornehmen, die JiffyBox “Starten”, “Einfrieren” oder wieder vollständig “Löschen”.

Hinter dem Menüpunkt “Voreinstellungen” verbirgt sich das Schlüsselmanagement, wo wir mehrere SSH-Public-Keys eintragen können.

Über den Punkt “Alle Meldungen” gelangen wir in den Statusbereich. Hier erhalten wir detailliert alle Informationen zu allen Vorgängen innerhalb unseres Accounts.

Weitere Informationen

Über den Menüpunkt “Account” gelangen wir direkt zu den Stammdaten.

Weiterhin können wir über “Kundenservice” direkt elektronischen Kontakt zu dem domainFACTORY Support aufnehmen und erhalten einen historischen Überblick über alle bisherigen Anfragen.

Wir können zusätzlich über den Menüpunkt “Passwörter”, unsere Passwörter für das JiffyBox Control Panel und dem Telefon Support eigenständig ändern. Zudem erhalten wir einen Überblick über alle bisher gestellten Rechnungen durch domainFACTORY über den Punkt “Rechnungen”.

Der Menüpunkt “Verbräuche” gibt einen genauen Überblick zu den bisher entstandenen Kosten zu allen JiffyBoxen und dem verbrauchten Traffic.

Weiterhin erhalten wir einen detaillierten Überblick über die Nutzung jeder einzelnen, in unserem Account vorhandenen, JiffyBox.

Sowie vom derzeit verbrauchten Traffic.

Ein weiteres interessantes Feature ist die Möglichkeit zur Begrenzung der Kosten. Hier kann ein Betrag (in EUR) als Obergrenze eingetragen werden und die Folgeaktion, die stattfinden soll, wenn der Betrag erreicht wird.

Um die JiffyBox über Skripte zu steuern, haben wir über den Menüpunkt “API-Zugriff” die Möglichkeit, einen API-Token zu erzeugen. Weitere Informationen für die Nutzung der API sind in der PDF-Datei “JiffyBox-API” zu finden.

Arbeiten mit der JiffyBox

Zurück im Control Panel wollen wir nun ein Blick hinter die Konfigurationsmöglichkeiten einer JiffyBox werfen. Wie wir sehen werden, stehen uns dazu viele Möglichkeiten zur Verfügung. Wir wählen dazu unter “Ihre JiffyBoxen” die Aktion “Konfigurieren”.

Wir erhalten zunächst einen Überblick zu allen notwendigen Informationen, wie der aktuellen IP-Adresse und dem aktuellen Hostnamen, dem genutzten Tarif, dem verfügbaren Arbeitsspeicher und der Festplattengröße, sowie der für diese JiffyBox verwendeten Linux Distribution.

Über “Profile und Festplatten” können wir weitere Konfigurationen am System, der Festplattengröße und deren Zuordnung vornehmen.

Hinter “Netzwerk” verbergen sich weitere Informationen zu den IP und DNS Informationen. Hier haben wir die Möglichkeit den “Reverse-DNS” Namen zu ändern und eine weitere IP-Adresse zu bestellen.

Von jeder JiffyBox werden automatisch tägliche Backups erstellt. Dennoch haben wir die Option über den Menüpunkt “Backups” ein manuelles Backup zu starten, bzw. eigene Backup Pläne zu erstellen.

Über “Konsole und Recovery” steht uns der Zugriff mittels einer Web-Konsole und per SSH-Konsole zur Verfügung. Weiterhin kann ein Recovery-System aktiviert werden, um die JiffyBox im Notfallmodus zu starten.

Um die JiffyBox nun zu nutzen, wählen wir im Control Panel unter “Ihre JiffyBoxen” lediglich “Starten”.

Mittels eines SSH-Clients, hier Putty, verbinden wir uns mit der JiffyBox. Die dazu benötigte IP-Adresse bzw. den DNS-Namen erhalten wir unter dem Menüpunkt “Netzwerk” in dem Konfigurationsbereich der JiffyBox.

Anschließend melden wir uns mit dem Benutzer “root” und dem von uns bei dem Erstellen der JiffyBox unter “Erweitert” gewählten Passwort an.

Damit sind wir mit unserer ersten eigenen JiffyBox verbunden.

Um die JiffyBox wieder zu beenden, wählen wir im Control Panel für die entsprechende JiffyBox “Stoppen”.

Und dann “Herunterfahren”.

Die JiffyBox wird anschließend automatisch heruntergefahren. Eine Statusmeldung informiert uns über den erfolgreichen Vorgang.

Die JiffyBox kann anschließend wieder angepasst, gestartet, eingefriert oder gelöscht werden.

Die Verbrauchsanzeige informiert uns darüber, dass für eine Gesamtdauer von 1:33:36 Stunden bisher 0,03 EUR entstanden sind.

1. Los geht es mit einer neuen Ubuntu Lucid Linux Installation

Während der Installation des Systems nehmen wir eine manuelle Partitionierung vor und erstellen 3 Partitionen:

• 1 – primary ext4 mounted at / (the rootfs)
• 2 – primary swap
• 3 – primary “nicht verwenden” (wird zum Speichern des Server-Image benötigt)

An dieser Stelle ist es wichtig zu beachten, ein benutzerspezifisches Partitionsschema zu wählen und eine dedizierte Partition zu erstellen, auf der später die Server-Images gespeichert werden. Diese Partition wird dann als “do not use” markiert.

Wenn die Installation abgeschlossen ist, starten wir das System neu und melden uns an. Wurde zu beginn die Ubuntu-Server Version installiert muss zusätzlich das “ubuntu-desktop” package installiert werden.

matt@cloud:~$ sudo apt-get install ubuntu-desktop

2. Vorbereiten des Netzwerks

Zunächst installieren wir die “bridge-utils”.

matt@cloud:~$ sudo apt-get install bridge-utils
Reading package lists... Done
Building dependency tree
...
Setting up bridge-utils (1.4-5ubuntu2) ...
matt@cloud:~$

Anschließend editieren wir “/etc/network/interfaces” und richten eine Bridge mit einer statischen, privaten IP-Adresse ein.

matt@cloud:~$ sudo /etc/init.d/networking restart
* Reconfiguring network interfaces...
Waiting for br0 to get ready (MAXWAIT is 2 seconds).
ssh stop/waiting
ssh start/running, process 2864
matt@cloud:~$

Wir führen den Befehl “brctl show” aus und überprüfen damit die Netzwerkkonfiguration.

matt@cloud:~$ brctl show
bridge name bridge id STP enabled interfaces
br0 8000.002215be747a no eth0
matt@cloud:~$

Nun hinterlegen wir die statische IP-Adresse (in unserem Fall “192.168.88.3″) und den Hostname (in unserem Fall “cloud”) in der /etc/hosts. Der Hostname darf hierbei nicht in der ersten Zeile zusammen mit 127.0.0.1 stehen!

matt@cloud:~$ cat /etc/hosts
127.0.0.1 localhost
192.168.88.3 cloud.openqrm cloud
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
matt@cloud:~$

3. Vorbereiten des Speicherplatz für die Server-Images

Wir installieren lvm2, nfs-kernel-server, iscsi-target und vblade.

matt@cloud:~$ sudo apt-get install lvm2 nfs-kernel-server iscsitarget vblade
Reading package lists... Done
Building dependency tree
...
ldconfig deferred processing now taking place
Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-2.6.32-21-server
matt@cloud:~$

Nun bereiten wir die dedizierte Partition aus Schritt 1 so vor, dass sie zusammen mit lvm genutzt werden kann. Anschließend erstellen wir eine Logical Volume Group “vol”.

matt@cloud:~$ sudo pvcreate /dev/sda3
Physical volume "/dev/sda3" successfully created
matt@cloud:~$ sudo pvs
PV VG Fmt Attr PSize PFree
/dev/sda3 lvm2 -- 186.23g 186.23g
matt@cloud:~$ sudo vgcreate vol /dev/sda3
Volume group "vol" successfully created
matt@cloud:~$ sudo vgs
VG #PV #LV #SN Attr VSize VFree
vol 1 0 0 wz--n- 186.22g 186.22g
matt@cloud:~$

Wir editieren /etc/default/iscsitarget und konfigurieren “iscsitarget” so, dass es während des Bootvorgangs startet.

matt@cloud:~$ cat /etc/default/iscsitarget
ISCSITARGET_ENABLE=true
matt@cloud:~$

Nun starten wir “iscsitarget” und die “nfs-kernel-server” Services.

matt@cloud:~$ sudo /etc/init.d/iscsitarget start
* Starting iSCSI enterprise target service
matt@cloud:~$

matt@cloud:~$ sudo /etc/init.d/nfs-kernel-server start
* Exporting directories for NFS kernel daemon...
* Starting NFS kernel daemon
matt@cloud:~$

4. Vorbereiten der Datenbank

Als Datenbank für den openQRM Server nutzen wir das Package “mysql-server”.

matt@cloud:~$ sudo apt-get install -y mysql-server
Reading package lists... Done
Building dependency tree
...
Setting up mysql-server (5.1.41-3ubuntu12) ...
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
matt@cloud:~$

Aus Gründen der Einfachheit wird in diesem Beispiel das MySQL Passwort leer gelassen.

5. Vorbereiten von KVM

Dafür installieren wir das “kvm” Package.

matt@cloud:~$ sudo apt-get install -y kvm
Reading package lists... Done
Building dependency tree
.....
Setting up qemu-kvm (0.12.3+noroms-0ubuntu9) ...
qemu-kvm start/running
Setting up kvm (1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9) ...
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
matt@cloud:~$

6. Installation von openQRM

openQRM wird in diesem Tutorial aus den Sourcen erstellt. Diese sind in dem Subversion Repository des openQRM Projects verfügbar. Für die Installation sind hier lediglich ein Subversion Client und “make” notwendig. Diese sollten also installiert werden.

matt@cloud:~$ sudo apt-get install -y subversion make
Reading package lists... Done
Building dependency tree
...
Setting up subversion (1.6.6dfsg-2ubuntu1) ...
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
matt@cloud:~$

Nun müssen die openQRM Sourcen aus dem SVN Repository ausgecheckt werden.

matt@cloud:~$ svn co https://openqrm.svn.sourceforge.net/svnroot/openqrm openqrm
....
matt@cloud:~$

Wir wechseln in das src/ Verzeichnis.

matt@cloud:~$ cd openqrm/trunk/src/
matt@cloud:~/openqrm/trunk/src$

Anschließend führen wir “make” aus. Dafür wird eine funktionsfähige Internetverbindung benötigt. Sollte dieses nicht der Fall sein, können die Sourcen auch von http://sourceforge.net/projects/openqrm/files/openQRM-4.6/source/openqrm-thirdparty-cache.tgz/download heruntergeladen werden. Diese müssen danach in das Home-Verzeichnis entpackt werden.

matt@cloud:~/openqrm/trunk/src$ make
....

Alle Ergebnisse der Kompilierung werden vom openQRM-Build System automatisch gecached. Um sicherzustellen, dass alle Komponenten richtig erstellt wurden, kann “make” einfach erneut ausgeführt werden.

matt@cloud:~/openqrm/trunk/src$ make
Checking requirements for the compilation phase
openqrm-server requires: make, gcc, portmap, rsync, zlib1g-dev, wget, tar, bzip2, unzip, wget, netbase, patch
found make installed
found gcc installed
found portmap installed
found rsync installed
found zlib1g-dev installed
found wget installed
found tar installed
found bzip2 installed
found unzip installed
found wget installed
found netbase installed
found patch installed
openqrm-plugin-aoe-storage requires:
openqrm-plugin-aws requires:
openqrm-plugin-citrix requires:
openqrm-plugin-cloud requires:
openqrm-plugin-collectd requires:
openqrm-plugin-dhcpd requires:
openqrm-plugin-dns requires:
openqrm-plugin-equallogic-storage requires:
openqrm-plugin-highavailability requires:
openqrm-plugin-image-shelf requires:
openqrm-plugin-iscsi-storage requires:
openqrm-plugin-kvm requires:
openqrm-plugin-kvm-storage requires:
openqrm-plugin-linux-vserver requires:
openqrm-plugin-linuxcoe requires:
openqrm-plugin-local-server requires:
openqrm-plugin-local-storage requires:
openqrm-plugin-lvm-storage requires:
openqrm-plugin-nagios2 requires:
openqrm-plugin-nagios3 requires:
openqrm-plugin-netapp-storage requires:
openqrm-plugin-nfs-storage requires:
openqrm-plugin-puppet requires:
openqrm-plugin-sanboot-storage requires:
openqrm-plugin-solx86 requires:
openqrm-plugin-sshterm requires:
openqrm-plugin-tftpd requires:
openqrm-plugin-tmpfs-storage requires:
openqrm-plugin-vbox requires:
openqrm-plugin-vmware-esx requires:
openqrm-plugin-vmware-server requires:
openqrm-plugin-vmware-server2 requires:
openqrm-plugin-windows requires:
openqrm-plugin-xen requires:
openqrm-plugin-xen-storage requires:
openqrm-plugin-zabbix requires:
openqrm-plugin-zfs-storage requires:
Checking for required components to compile openQRM finished successfully
if [ -d ./thirdparty ]; then mkdir -p ../buildtmp; cp -aR ./thirdparty/* ../buildtmp/; fi
-> found component kvm-nic-bios (kvm-nic-bios-1.1.tgz) already downloaded
-> found component gpxe (undionly.kpxe.0.9.9.tgz) already downloaded
-> found component sshterm-component (openqrm-plugin-sshterm-components-1.0.tgz) already downloaded
-> found component openqrm-client.windows (openQRM-Client-4.6.1-setup.exe) already downloaded
Creating the default initrd-template
-> found component busybox (busybox-1.14.2.tar.bz2) already downloaded
-> Found busybox-1.14.2/_install/bin/busybox already in the build-cache
-> Skipping compilation, taking the ready built component from the cache
-> found component pciutils (pciutils-3.1.4.tar.gz) already downloaded
-> Found pciutils-3.1.4/pcimodules already in the build-cache
-> Skipping compilation, taking the ready built component from the cache
-> found component dropbear (dropbear-0.52.tar.gz) already downloaded
-> Found dropbear-0.52/dropbear already in the build-cache
-> Skipping compilation, taking the ready built component from the cache
/lib64/ld-2.11.1.so /lib64/ld-linux-x86-64.so.2
Adding /sbin/portmap to default initrd-template
Adding /sbin/rpc.statd to default initrd-template
Adding /bin/bash to default initrd-template
Adding /usr/bin/rsync to default initrd-template
Adding /usr/bin/wget to default initrd-template
Adding /sbin/modprobe to default initrd-template
Adding /sbin/depmod to default initrd-template
Adding /sbin/insmod to default initrd-template
Adding /sbin/lsmod to default initrd-template
Adding /sbin/mke2fs to default initrd-template
Adding /sbin/sfdisk to default initrd-template
Adding /sbin/udevd to default initrd-template
Adding /sbin/blkid to default initrd-template
/lib64/libnss_files-2.11.1.so /lib64/libnss_files.so.2
-> found component jquery (jquery-1.3.2.tgz) already downloaded
-> found component js-interface (interface_1.2.zip) already downloaded
-> found component openqrm-client.centos.i386 (openqrm-client.4.6.1.centos.i386.tgz) already downloaded
-> found component openqrm-client.centos.x86_64 (openqrm-client.4.6.1.centos.x86_64.tgz) already downloaded
-> found component openqrm-client.debian.i386 (openqrm-client.4.6.1.debian.i386.tgz) already downloaded
-> found component openqrm-client.debian.x86_64 (openqrm-client.4.6.1.debian.x86_64.tgz) already downloaded
-> found component openqrm-client.ubuntu.i386 (openqrm-client.4.6.1.ubuntu.i386.tgz) already downloaded
-> found component openqrm-client.ubuntu.x86_64 (openqrm-client.4.6.1.ubuntu.x86_64.tgz) already downloaded
-> found component openqrm-initrd-template.centos.i386 (openqrm-initrd-template.4.6.1.centos.i386.tgz) already downloaded
-> found component openqrm-initrd-template.centos.x86_64 (openqrm-initrd-template.4.6.1.centos.x86_64.tgz) already download
-> found component openqrm-initrd-template.debian.i386 (openqrm-initrd-template.4.6.1.debian.i386.tgz) already downloaded
-> found component openqrm-initrd-template.debian.x86_64 (openqrm-initrd-template.4.6.1.debian.x86_64.tgz) already download
-> found component openqrm-initrd-template.ubuntu.i386 (openqrm-initrd-template.4.6.1.ubuntu.i386.tgz) already downloaded
-> found component openqrm-initrd-template.ubuntu.x86_64 (openqrm-initrd-template.4.6.1.ubuntu.x86_64.tgz) already download
-> found component kvm-nic-bios (kvm-nic-bios-1.1.tgz) already downloaded
-> found component gpxe (undionly.kpxe.0.9.9.tgz) already downloaded
-> found component sshterm-component (openqrm-plugin-sshterm-components-1.0.tgz) already downloaded
-> found component openqrm-client.windows (openQRM-Client-4.6.1-setup.exe) already downloaded
matt@cloud:~/openqrm/trunk/src$

Nun führen wir “sudo make install” aus.

matt@cloud:~/openqrm/trunk/src$ sudo make install
Creating the openqrm-client boot-service package
include/
include/openqrm-plugin-kvm-functions
.... further install output
sbin/
sbin/openqrm-kvm-storage-monitord
matt@cloud:~/openqrm/trunk/src$

Am Ende initialisieren und starten wir openQRM mittels “sudo make start”.

matt@cloud:~/openqrm/trunk/src$ sudo make start
.... runtime dependency check, automatic install additional requirements
...
openqrm-plugin-xen requires: , screen
-> found screen installed
openqrm-plugin-xen-storage requires: , screen
-> found screen installed
openqrm-plugin-zabbix requires:
openqrm-plugin-zfs-storage requires: , open-iscsi
-> found open-iscsi installed
Checking for required components finished successfully
First startup detected. Running initialization.

Adding system startup for /etc/init.d/openqrm ...
/etc/rc0.d/K24openqrm -> ../init.d/openqrm
/etc/rc1.d/K24openqrm -> ../init.d/openqrm
/etc/rc6.d/K24openqrm -> ../init.d/openqrm
/etc/rc2.d/S98openqrm -> ../init.d/openqrm
/etc/rc3.d/S98openqrm -> ../init.d/openqrm
/etc/rc4.d/S98openqrm -> ../init.d/openqrm
/etc/rc5.d/S98openqrm -> ../init.d/openqrm
Looking for syslinux/pxelinux.0...found: /usr/lib/syslinux/pxelinux.0
Creating custom apache config.../etc/apache2/conf.d/openqrm-httpd.conf
Checking /usr/share/openqrm/etc/openqrm-server.conf for OPENQRM_WEB_PROTOCOL=https.. * Reloading web server config apache2
Adding password for user openqrm
Initializing dropbear...
Will output 1024 bit rsa secret key to '/usr/share/openqrm/etc/dropbear/dropbear_rsa_host_key'
Generating key, this may take a while...
Public key portion is:
ssh-rsa xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxroot@cloud
Fingerprint: md5 28:46:66:b4:b7:59:b6:28:70:ec:2b:6f:16:4a:dd:70
Adding public key to /root/.ssh/authorized_keys...
Starting the openQRM-server ver. 4.6.
Initialization complete. Please configure your openQRM Server at: http://[server-ip-address]/openqrm/
-> User: openqrm -> Password: openqrm
matt@cloud:~/openqrm/trunk/src$

“make start” führt zusätzlich eine Check-Routine aus, die überprüft, dass alle Abhängigkeiten für die Einwandfreie Nutzung von openQRM vorhanden sind. Ggf. nicht vorhandene Pakete werden automatisch installiert.

Während des ersten Starts wird der openQRM Server initialisiert. Nachdem openQRM vollständig installiert wurde, kann nun die Konfiguration mittels der Weboberfläche vorgenommen werden.

7. Konfiguration von openQRM

Wir melden uns am openQRM Server per http://localhost/openqrm an. Der Benutzer und das Passwort sind jeweils “openqrm”. Nach der Konfiguration sollten diese Daten geändert werden.

8. Vorbereiten der Server-Images

Als Nächstes müssen wir die folgenden Plugins aktivieren und starten:

• cloud
• dhcpd
• image-shelf
• kvm
• lvm-storage
• tftpd

matt@cloud:~$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 38543848 3470824 33115088 10% /
none 1523376 324 1523052 1% /dev
none 1528204 200 1528004 1% /dev/shm
none 1528204 164 1528040 1% /var/run
none 1528204 0 1528204 0% /var/lock
none 1528204 0 1528204 0% /lib/init/rw
none 38543848 3470824 33115088 10% /var/lib/ureadahead/debugfs
/dev/mapper/vol-ubuntu64
5039616 141212 4642404 3% /vol/ubuntu64
/dev/mapper/vol-debian64
5039616 141212 4642404 3% /vol/debian64
matt@cloud:~$ sudo exportfs
/vol/ubuntu64 192.168.88.3
/vol/debian64 192.168.88.3
matt@cloud:~$ ls /vol/ubuntu64/
lost+found
matt@cloud:~$ ls /vol/debian64/
lost+found
matt@cloud:~$

Mittels des “image-shelf” Plugin werden die weiterhin noch leeren Images mit dem Root Dateisystem befüllt.

Dazu gehen wir nach Plugins >> Deployment >> Image-Shelf >> Import und wählen das “openqrm-enterprise” Image-Shelf.

Nachdem Image-Shelf die Verarbeitung abgeschlossen hat, erhalten wir folgende Konsolenausgabe:

matt@cloud:~$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 38543848 3552184 33033728 10% /
none 1523376 324 1523052 1% /dev
none 1528204 200 1528004 1% /dev/shm
none 1528204 164 1528040 1% /var/run
none 1528204 0 1528204 0% /var/lock
none 1528204 0 1528204 0% /lib/init/rw
none 38543848 3552184 33033728 10% /var/lib/ureadahead/debugfs
/dev/mapper/vol-ubuntu64
5039616 1144532 3639084 24% /vol/ubuntu64
/dev/mapper/vol-debian64
5039616 1084104 3699512 23% /vol/debian64
matt@cloud:~$ sudo exportfs
/vol/ubuntu64 192.168.88.3
/vol/debian64 192.168.88.3
matt@cloud:~$ ls /vol/ubuntu64/
bin cdrom etc initrd.img lib64 media opt root selinux sys usr vmlinuz
boot dev home lib lost+found mnt proc sbin srv tmp var
matt@cloud:~$ ls /vol/debian64/
bin cdrom emul home lib lib64 media opt root selinux sys usr vmlinuz
boot dev etc initrd.img lib32 lost+found mnt proc sbin srv tmp var
matt@cloud:~$

Beide Images sind nun mit einem validen Root Dateisystem befüllt. Die Konfiguration der openQRM Cloud kann nun fortgeführt werden.

9. Erstellen eines KVM Host

Nun müssen wir openQRM die virtualisierten Hosts mitteilen. Dazu gehen wir nach Base >> Appliances >> Create und wählen “openQRM Server” als “resource”.

10. Konfiguration der openQRM Cloud

Nun wechseln wir nach Plugins >> Cloud >> Configuration >> Main Config und konfigurieren die folgenden Punkte:

• cloud_admin_email > eine valide E-Mail Adresse
• auto_provision → true
• external_portal_url → (optional) externe URL zu einem Cloud Portal
• request_physical_systems → false
• auto_give_ccus → 100
• show_disk_resize → (optional) true
• show_private_image → true
• cloud_currency → (optional) auf US oder Euro setzen
• cloud_1000_ccus → Wie viele 1000 CCUs wie viel US/Euro entsprechen

Für alle weiteren Konfigurationspunkte können die Standardwerte genommen werden. Speichern nicht vergessen!

Der folgende Screenshot zeigt die Hauptseite zur Konfiguration der Cloud.

11. Nutzen der openQRM Cloud

Um Zugriff auf die “KVM VM” Konsole zu erhalten, muss das “xtightvncviewer” Package installiert werden.

matt@cloud:~$ sudo apt-get install xtightvncviewer
Reading package lists... Done
...
Setting up xtightvncviewer (1.3.9-6) ...
update-alternatives: using /usr/bin/xtightvncviewer to provide /usr/bin/vncviewer (vncviewer) in auto mode.
matt@cloud:~$

Um sich per VNC an der ersten Cloud Appliance (KVM VM) anzumelden nutzen wir den folgenden Befehl.

matt@cloud:~$ vncviewer localhost:1

Der folgende Screenshot zeigt den Bootvorgang der Cloud Appliance in einer KVM VM.

12. Die nächsten Schritte

• Separierung des Storage, Hypvervisors und openQRM auf dedizierte Systeme
• openQRM Server als Hochverfügbarkeitslösung
• Hinzufügen weiterer virtualisierter Hosts unterschiedlichen Typs (XEN, VMwAre, etc.)
• Hinzufügen von physikalischen Systemen
• Hinzufügen von weiteren Storage Systemen
• Aktivieren des automatischen Monitorings
• IP- und Netzwerkmanagement
• Cloud-Billing
• Cloud Integration / SOAP WebService

Quelle

• HowTo: Setup your own openQRM Cloud with KVM on Ubuntu Lucid Lynx

Eine Public Cloud ist die Erweiterung einer Private Cloud, die eine RESTful Cloud Schnittstelle bereitstellt. Cloud Schnittstellen können sowohl zu einer Private als auch zu einer Hybrid Cloud hinzugefügt werden, um z.B. Partnern oder extern Benutzer den Zugriff auf die eigene Infrastruktur zu ermöglichen, oder um eigene Überkapazitäten zu verkaufen. Somit ist eine lokale Cloud Lösung das natürliche Back-End für eine Public Cloud.

Die Sicht des Benutzers

Die folgenden Schittstellen stellen eine einfache Möglichkeit für das Remote Management von Cloud Ressourcen dar.

• EC2 Query subset
• RESERVOIR Cloud Interface und OGF OCCI

Benutzer haben die Möglichkeit, Befehle zu verwenden, welche die Funktionalität der Amazon EC2 Services abbilden. Mit drei einfachen Befehlen kann ein bereits vorinstalliertes Betriebssystem (als vorhandene .img Datei) in der Cloud gestartet werden.

Zunächst muss das Image hochgeladen werden:

$ ./econe-upload /images/gentoo.img
Success: ImageId 872ce740-5904-012c-08e0-0017f231be96

Nachdem das Image in das OpenNebula Repository hochgeladen wurde, muss dieses für die Nutzung in der Cloud registriert werden:

$ ./econe-register 872ce740-5904-012c-08e0-0017f231be96
Success: ImageId 872ce740-5904-012c-08e0-0017f231be96

Anschließend kann das registrierte Image in der Cloud gestartet und ausgeführt werden:

$ ./econe-run-instances -H 872ce740-5904-012c-08e0-0017f231be96
Owner       ImageId                                InstanceId InstanceType
------------------------------------------------------------------------------
helen       872ce740-5904-012c-08e0-0017f231be96   15         m1.small

Weiterhin kann die ausgeführte Instanz überwacht werden:

$ ./econe-describe-instances  -H
Owner       Id    ImageId                               State         IP              Type
------------------------------------------------------------------------------------------------------------
helen       15    872ce740-5904-012c-08e0-0017f231be96  pending       147.96.80.33    m1.small  

Wie das System funktioniert

Es müssen keine Änderung an der Funktionsweise von OpenNebula vorgenommen werden, um Cloud Schnittstellen bereitzustellen. Benutzer können sich mit der Infrastruktur verbinden, indem sie eine Private oder Public Cloud Schnittstelle verwenden.

Quelle

• Building a Public Cloud

Installation

---

Installation auf Karmic Koala (9.10) und späteren Versionen

Für alle Ubuntu Versionen ab Karmic Koala (9.10) sind fertige Pakete vorhanden.

apt-get install python-vm-builder-ec2

Installation auf früheren Versionen

Für frühere Versionen müssen die notwendigen Tools installiert werden, um den VMBuilder zu erstellen und diesen zu nutzen.

sudo apt-get install bzr cdbs python-all-dev python-epydoc \
  kvm debootstrap parted kpartx ubuntu-keyring             \
  dpkg-dev python-boto python-cheetah ec2-ami-tools        \
  devscripts build-essential

Laden der EC2-Änderungen die an dem VMBuilder ggf. vorgenommen wurden.

sbzr branch lp:~zulcss/vmbuilder/vmbuilder-intrepid-ec2

Laden der EC2 Skripte die für die Konfiguration während des ersten Starts und der ersten Benutzeranmeldung für das Image benötigt werden.

bzr branch lp:~zulcss/ec2-scripts/trunk zulcss-ec2-scripts

Erstellen des VMBuilder Package.

(cd vmbuilder-chuck; debuild -uc -us)

Installation der Debs.

sudo dpkg -i                \
  python-vm-builder_*.deb   \
  python-vm-builder-ec2*.deb

Erstellen einer virtuellen Maschine

---

Mit dem folgenden Befehl wird automatisch ein Image erstellt, ge-bundled und hochgeladen.

sudo vmbuilder xen ubuntu --suite={hardy,intrepid,karmic} --ec2 \
  --ec2-cert=                  \
  --ec2-key=                    \
  --ec2-access-key=                     \
  --ec2-secret-key=                     \
  --ec2-user=                             \
  --ec2-bucket=                        \
  --ec2-prefix=                                \
  --ec2-version="Beschreibung des EC2 Image"              \
  --firstboot=/usr/share/doc/python-vm-builder-ec2/examples/ec2-firstboot.sh            \
  --part=/usr/share/doc/python-vm-builder-ec2/examples/ec2-< arch >-part-file.txt         \
  --debug

Beim Einsatz eines früheren Ubuntu Release müssen die Skripte unter /usr/share/doc/python-vm-builder-ec2/examples mit den Skripten von zulcss-ec2-scripts (siehe oben) ersetzt werden.

Quelle

• EC2Vmbuilder

Immer wenn eine Datei zu Amazon S3 hochgeladen wird, bekommen wir eine URL, um Zugriff auf diese zu erhalten. Dabei werden zwei unterschiedliche Schreibweisen verwendet, die wie folgt aussehen:

• http://s3.amazonaws.com/bucket_name/dateiname.ext

und

• http://bucket_name.s3.amazonaws.com/dateiname.ext

Wie man erkennt, wird der Name des Buckets im ersten Beispiel als Teil des Dateipfads genutzt, im zweiten Beispiel als Teil des Domain Namen. Diese beiden URLs sind identisch und verweisen auf dieselbe Datei.

Um nun eine Subdomain so zu konfigurieren, dass diese auf Amazon S3 verweist, muss zunächst ein Bucket mit exakt dem Namen der Subdomain erstellt werden. Wollen wir z.B. eine Subdomain mit dem Namen http://Meine-S3-Dateien.clouduser.de auf Amazon S3 verweisen lassen, erstellen wir einen Bucket mit exakt dem Namen Meine-S3-Dateien.clouduser.de.

Also nochmal zusammengefasst:

• Name der Subdomain: http://Meine-S3-Dateien.clouduser.de
• Name des Buckets: Meine-S3-Dateien.clouduser.de

Als nächstes muss bei unserem Web Hoster das DNS konfiguriert werden. Dazu legen wir einen neuen CNAME an, der auf Amazon S3 verweist.

Das sieht dann wie folgt aus:

• Subdomain: http://Meine-S3-Dateien.clouduser.de
• Zeigt auf: CNAME
• Wert: Meine-S3-Dateien.clouduser.de.s3.amazonaws.com

Die Art wie ein CNAME erstellt wird, ist von Anbieter zu Anbieter unterschiedlich.

Wenn die Konfiguration abgeschlossen wurde, kann auf alle Dateien unter http://Meine-S3-Dateien.clouduser.de mittels http://Meine-S3-Dateien.clouduser.de/dateiname.ext zugegriffen werden.

Es können natürlich beliebig viele Subdomains für Amazon S3 nach dem oben beschriebenen Schema angelegt werden.

Durch den Einsatz eines lokalen Mirror benötigt der gesamte Erstellungsprozess einer Virtuellen Maschine nur ca. 2 Minuten.

Zum Erstellen einer benutzerdefinierten Virtuellen Maschine gehen wir wie folgt vor:

sudo ubuntu-vm-builder kvm hardy --addpkg vim


Damit erstellen wir ein KVM Image und fügen diesem automatisch das VIM Package hinzu. Das Stanard-Image der virtuellen Maschine ist KVM. Weiterhin werden aber auch xen, vmw6, vbox und qemu Images als Optionen unterstützt.

Achtung!!! Der VM-Builder lädt während des Vorgangs alle benötigten Daten und Abhängigkeiten, die für die Erstellung des Images notwendig sind, aus dem entsprechenden Ubuntu Repository.

Der allgemeine Befehl lautet:

sudo ubuntu-vm-builder < hypervisor > < distro > --addpkg

Durch das Hinzufügen der Option –addpkg kann das Image mit einer beliebigen Anzahl von Applikationen erweitert werden.

sudo ubuntu-vm-builder kvm hardy --addpkg vim --addpkg screen --mem 256


Durch die Option –mem 256 wird der Arbeitsspeicher der virtuellen Maschine vergrößert. Die Standardgröße beträgt 128MB

Im Anschluß der Erstellung des Images muss noch die Installation der weiteren hinzugefügten Packages bestätigt werden. Nach dem gesamten Vorgang existiert ein neues Verzeichnis mit dem Namen der Distribution, z.B. ubuntu-vm-hardy-i386 oder ubuntu-vm-hardy-amd64. Innerhalb des Verzeichnis befindet sich das virtuelle Maschinen Image – im Falle von KVM mit dem Namen root.qcow2, im Falle von Xen mit dem Namen root.iso und jeweils einem Shell Skript, um die virtuelle Maschine zu starten.

Weitere Informationen können der ubuntu-vm-builder man page entnommen werden.

Der ubuntu-vm-builder in Verbindung mit libvirt

Durch die Kombination des ubuntu-vm-builder und libvirt steht eine Umgebung zur Verfügung mit der ebenfalls virtuelle Maschinen erstellt und verwaltet werden können.

Mittels der Option –libvirt < uri > werden neu erstellte virtuelle Maschinen automatisch zu einer libvirt Domain hinzugefügt werden.

sudo ubuntu-vm-builder kvm hardy --addpkg vim --mem 256 --libvirt qemu:///system


Im Anschluß kann mittels virsh die virtuelle Maschine gestartet werden.

virsh -c qemu:///system start ubuntu


Dabei ist der Standardname einer virtuellen Maschine ubuntu. Dieser kann mit der Option –hostname geändert werden.

Quelle

• ubuntu-vm-builder

Dieser Artikel beschreibt, wie virtuelle Netzwerke innerhalb von OpenNebula erstellt und genutzt werden können. Die folgenden Beispiele gehen dabei davon aus, dass die Cluster Nodes mit zwei physikalischen Netzwerken verbunden sind. Folgende Konstellation besteht:

• Ein privates Netzwerk mit der virtuellen Bridge vbr0.
• Ein Netzwerk inkl. Internetverbindung mit der virtuellen Bridge vbr1.

Definition eines virtuellen Netzwerks

---

OpenNebula ermöglicht die Erstellung von virtuellen Netzwerken, indem diese auf die physikalischen aufgesetzt und mit ihnen verbunden werden. Alle virtuellen Netzwerke teilen sich einen Standardwert für die MAC-Präfix, welcher in der Datei oned.conf konfiguriert wird.

In OpenNebula existieren zwei Arten von virtuellen Netzwerken:

• Statische: Definiert einen festen Satz von IP/MAC-Adressen Paaren
• Klassen: Definiert ein Class X Netzwerk (z.B. Class A)

Virtuelle Netzwerke die von dem Benutzer oneadmin erstellt wurden, können von jedem anderen Benutzer ebenfalls verwendet werden.

Statische virtuelle Netzwerke

Ein statisches Netzwerk besteht aus einem Satz von IP-Adressen, die MAC Adressen zugeordnet sind. Dieses geschieht in einer gewöhnlichen Textdatei.

Für die Definition eines statischen Netzwerks werden die vier folgenden Informationen benötigt:

• NAME: Name des virtuellen Netzwerks
• TYPE: In diesem Fall – Fixed
• BRIDGE: Name der physikalischen Bridge des physikalischen Hosts, mit der die virtuelle Maschine eine Netzwerkverbindung aufbauen wird.
• LEASES: Definition der IP-/MAC Paare. Sollte eine IP-Adresse definiert sein, aber keine Verknüpfung mit einer MAC-Adresse bestehen, wird OpenNebula das Paar automatisch mit der Regel MAC = MAC_PREFFIX:IP generieren. Zum Beispiel erhalten wir mit der IP-Adresse 10.0.0.1 und dem MAC_PEFFIX die MAC 00:16:0a:00:00:01.

Um ein statisches virtuelles Netzwerk mit dem Namen “Public” und den öffentlichen IP Adressen für die virtuellen Maschinen zu erstellen reicht der Inhalt der folgenden Datei.

NAME = "Public"
TYPE = FIXED

#Auf Grund der Internetverbindung muss das Netzwerk an "virdr1" gebunden werden.
BRIDGE = vbr1

LEASES = [IP=130.10.0.1, MAC=50:20:20:20:20:20]
LEASES = [IP=130.10.0.2, MAC=50:20:20:20:20:21]
LEASES = [IP=130.10.0.3]
LEASES = [IP=130.10.0.4]

Klassifiziertes virtuelles Netzwerk

Diese Art von virtuellen Netzwerk benötigt u.a. einen festgelegten IP-Adressblock und weitere folgende Informationen:

• NAME: Name des virtuellen Netzwerks.
• TYPE: In diesem Fall – Ranged.
• BRIDGE: Name der physikalischen Bridge.
• NETWORK_ADDRESS: IP-Adressblock
• NETWORK_SIZE: Anzahl der Hosts die sich in diesem Netzwerk befinden dürfen. Das kann über eine Zahl oder über die Netzwerk Klasse A, B oder C definiert werden.

Das folgende Beispiel zeigt die Definition eines solchen Netzwerktyps.

NAME = "Red LAN"
TYPE = RANGED

# Hier nutzen wir das physikalische private Netzwerk des Cluster
BRIDGE = vbr0

NETWORK_SIZE    = C
NETWORK_ADDRESS = 192.168.0.0

Die Standardwerte für die NETWORK_SIZE können der oned.conf entnommen werden.

Hinzufügen und Löschen virtueller Netzwerke

---

Sobald ein Template für ein virtuelles Netzwerk definiert wurde, kann der onevnet Befehl genutzt werden um dieses zu erstellen.

Um die beiden oben genannten Netzwerke zu erstellen fügen wir die jeweiligen Definitionen in die zwei unterschiedliche Dateien mit den Namen public.net und red.net und führen folgenden Befehl aus.

$ onevnet -v create public.net
$ onevnet -v create red.net

Mittels onevnet kann innerhalb von OpenNebula ebenfalls nach verfügbaren virtuellen Netzwerken gesucht werden.

$ onevnet list
 NID USER     NAME              TYPE BRIDGE #LEASES
   2 oneadmin Public           Fixed   vbr1       0
   3 oneadmin Red LAN         Ranged   vbr0       0

Dabei steht USER für den Eigentümer des Netzwerks und #LEASES für die Anzahl von IP-MAC Adressen die einer virtuellen Maschine aus diesem Netzwerk zugwiesen sind.

Um eine virtuelles Netzwerk zu entfernen wird der Befehl onevnet delete verwendet. Um die oben genannten Netzwerke zu löschen verwenden wir:

$onevnet delete 2
$onevnet delete 'Red LAN'

Mittels onevnet show können die vergebenen IP-Adressen innerhalb eines Netzwerks angezeigt werden.

Leasing

---

Das Leasing einer virtuellen Maschine aus einem virtuellen Netzwerk wird vorgenommen, indem der Name des virtuellen Netzwerks für das Attribute NIC angegeben wird.

Um ein virtuelle Maschine mit zwei Netzwerkschnittstellen zu definieren, bei der eine Schnittstelle mit Red LAN und die andere mit Public verbunden ist muss das Template um folgenden Eintrag erweitert werden.

NIC=[NETWORK="Public"]
NIC=[NETWORK="Red LAN"]

Es kann ebenfalls eine bestimmte Adresse angefragt werden, indem zusätzlich die IP oder MAC-Adresse dem Attribute hinzugefügt wird.

NIC=[NETWORK="Red LAN", IP=192.168.0.3]

Ist die virtuelle Maschine übertragen wurde, schaut OpenNebula in den virtuellen Netzwerken Public und Red LAN nach verfügbaren IP-Adressen. Mit dem Befehl onevm show können anschließend Informationen über die virtuelle Maschine und das Netzwerk ausgegeben werden.

$ onevm show 12
VIRTUAL MACHINE 12 INFORMATION
ID             : 12
NAME           : server
STATE          : PENDING
LCM_STATE      : LCM_INIT
START TIME     : 07/15 15:30:53
END TIME       : -
DEPLOY ID:     : -

VIRTUAL MACHINE TEMPLATE
NAME=server
NIC=[
  BRIDGE=vbr1,
  IP=130.10.0.1,
  MAC=50:20:20:20:20:20,
  NETWORK=Public,
  VNID=5 ]
NIC=[
  BRIDGE=eth0,
  IP=192.168.0.1,
  MAC=00:03:c0:a8:00:01,
  NETWORK=Red LAN,
  VNID=4 ]
VMID=12

Nun kann mit dem Befehl onevnet list die Leasing Informationen und weitere Details zu den virtuellen Netzwerken angezeigt werden.

$ onevnet list
 NID USER     NAME              TYPE BRIDGE #LEASES
   2 onedmin  Red LAN         Ranged   vbr0       1
   3 oneamdin Public           Fixed   vbr1       1

Achtung!!! Nicht in jedem Netzwerk ist das Leasing aktiviert.

$ onevnet show 4
VIRTUAL NETWORK 4 INFORMATION
ID:       : 4
UID:      : 0

VIRTUAL NETWORK TEMPLATE
BRIDGE=eth0
NAME=Red LAN
NETWORK_ADDRESS=192.168.0.0
NETWORK_SIZE=C
TYPE=RANGED

LEASES INFORMATION
LEASE=[ IP=192.168.0.1, MAC=00:03:c0:a8:00:01, USED=1, VID=12 ]

Die IP 192.168.0.1 wird von der virtuellen Maschine 12 verwendet.

Leasing innerhalb der virtuellen Maschine

---

Ein Hypervisor kann eine bestimmte MAC Adresse mit einer virtuellen Netzwerschnittstelle verknüpfen. Virtuelle Maschinen hingegen müssen eine erhalten. Es existiert eine Reihe von Möglichkeiten dieses mit OpenNebula zu realisieren.

• Die IP-Adresse von der MAC Adresse mittels der Standardmethode erhalten.
• Mithilfe des CONTEXT Attribut.

Eine virtuelle Maschine konfigurieren um das Leasing zu nutzen

Mit OpenNebula kann die IP-Adresse aus der MAC-Adresse mittels der MAC_PREFFIX:IP Regel angeleitet werden. Um dieses zu erreichen, existiert für Debian basierte Systeme ein Skript und kann ebenfalls für andere Distributionen genutzt werden, siehe dazu dev.opennebula.org.

Um die virtuelle Maschine dafür zu konfigurieren sind folgende Schritte notwendig.

• Kopieren des Skript $ONE_LOCATION/share/scripts/vmcontext.sh in das Verzeichnis /etc/init.d.
• Ausführen des Skripts während des Bootvorgangs bevor ein Netzwerkdienst gestartet wird – z.B. Runlevel 2.

$ ln /etc/init.d/vmcontext.sh /etc/rc2.d/S01vmcontext.sh

Während des Bootvorgangs führt die virtuelle Maschine das Skript aus, scanned alle verfügbaren Netzwerkschnittstellen und identifiziert deren MAC-Adressen. Weiterhin wird die MAC mit der IP-Adresse verknüpft und eine Schnittstelle unter /etc/network/interfaces erstellt, um sicherzustellen dass die IP Adresse der entsprechende Schnittstelle richtig zugewiesen wird.

Quelle

• Managing Virtual Networks 1.4 ]]> http://clouduser.de/tutorials/opennebula-die-verwaltung-virtueller-netzwerke-5482/feed 0