Vor kurzem haben wir Witsbits, einen „Private Cloud Management as a Service“ aus Schweden vorgestellt. Heute geht es darum, wie vorgegangen werden muss, um Witsbits im eigenen Rechenzentrum/ Serverraum nutzen zu können.
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.
Dieses Tutorial zeigt Schritt für Schritt, wie eine openQRM Cloud auf CentOS 5.5 so eingerichtet wird, dass damit anschließend physikalische Windows Systeme deployed werden können. Für dieses Tutorial werden dazu zwei physikalische Systeme benötigt.
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.
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”.
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.
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.
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]#
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:
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.
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:
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.
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:
Ein Cluster Node ist mit einem oder mehreren Netzwerken verbunden, mit denen die virtuellen Maschinen mittels der entsprechenden Brigdes kommunizieren. Für den Aufbau eines virtuellen Netzwerks wird lediglich der Name der Brigde benötigt, um mit den virtuellen Maschinen eine Verbindung herzustellen.
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.
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.
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.
