Rene Buest is Gartner Analyst covering Infrastructure Services & Digital Operations. Prior to that he was Director of Technology Research at Arago, Senior Analyst and Cloud Practice Lead at Crisp Research, Principal Analyst at New Age Disruption and member of the worldwide Gigaom Research Analyst Network. Rene is considered as top cloud computing analyst in Germany and one of the worldwide top analysts in this area. In addition, he is one of the world’s top cloud computing influencers and belongs to the top 100 cloud computing experts on Twitter and Google+. Since the mid-90s he is focused on the strategic use of information technology in businesses and the IT impact on our society as well as disruptive technologies.
Rene Buest is the author of numerous professional technology articles. He regularly writes for well-known IT publications like Computerwoche, CIO Magazin, LANline as well as Silicon.de and is cited in German and international media – including New York Times, Forbes Magazin, Handelsblatt, Frankfurter Allgemeine Zeitung, Wirtschaftswoche, Computerwoche, CIO, Manager Magazin and Harvard Business Manager. Furthermore Rene Buest is speaker and participant of experts rounds. He is founder of CloudUser.de and writes about cloud computing, IT infrastructure, technologies, management and strategies. He holds a diploma in computer engineering from the Hochschule Bremen (Dipl.-Informatiker (FH)) as well as a M.Sc. in IT-Management and Information Systems from the FHDW Paderborn.
Eine Ubuntu Enterprise Cloud kann aus zwei, bzw. bis zu hunderten oder sogar tausenden physikalischen bestehen. Es ist daher wichtig, die möglichen Topologien zu verstehen, die auf Basis der vorhandenen physikalischen Maschinen aufzubauen sind.
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
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.
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.
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.
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.
Cloud Computing bringt finanzielle Vorteile, definitiv! Für Nutzer, genau so wie für Anbieter von Public Cloud Services.
Anbieter sollten jedoch zwei Dinge beachten. Für bspw. einen Anbieter wie die Amazon Web Services (AWS) lohnt sich das Cloud Computing Modell nur, wenn zwei Fälle vorhanden sind: Das eine sind die “Economies of Scale” (Skaleneffekte) und das zweite “Eine Gleichverteilung der Kunden”.
Economies of Scale: Ein Anbieter benötigt viele Kunden, damit die Infrastruktur so gut ausgelastet wird, damit sich die Investitionen lohnen.
Eine Gleichverteilung der Kunden: AWS Kunden verteilen sich auf die unterschiedlichsten Branchen mit den unterschiedlichsten Kerngeschäften. Es wäre für AWS fatal, nur Kunden aus einem Branchenzweig, bspw. aus dem Bereich der Webshops, zu haben. Man könnte davon ausgehen, dass in diesem bestimmten Fall die AWS Infrastruktur zu Weihnachten zusammenbrechen würde. Im schlimmsten Fall würde sogar der Amazon Webshop davon betroffen sein. Wobei wir uns ziemlich sicher sein können, dass Amazon sich die eine oder andere Ressource reserviert hat. 😉
Der “Trick” besteht also darin, u.a. die Lasten immer gleichmäßig über die Zeit zu verteilen und bspw. nicht viele hoch performante Jobs von mehrere Kunden zur selben Zeit auszuführen zu lassen.
Was also nicht passieren darf ist, dass Kunde A, B, C, D, E und Kunde F Ressourcen hungrige Jobs parallel ausführen wollen. Es wäre dagegen besser wenn die Infrastruktur immer gleichmäßig durch die Kunden innerhalb der 24h eines Tages belastet wird.
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:
Mit Appforce, Siteforce, VMforce, ISVforce und Heroku hat salesforce.com fünf neue Cloud Plattform Services für die Erstellung von Cloud 2-Apps vorgestellt. Force.com 2 beseitigt dabei Hardware- und Softwarekomplexität und ermöglicht Unternehmen und ISVs, Anwendungsentwicklungsprojekte zu beschleunigen.
Appforce – Kollaborative Apps für verschiedene Abteilungen
Appforce hilft Unternehmen leistungsfähige und skalierbare Apps für alle Abteilungen zu erstellen. Nutzer können Formulare anlegen, Reports anpassen, Unternehmensprozesse visuell abbilden und gleichzeitig sicher stellen, dass diese messbar und prüffähig sind. Und sie können über Salesforce Chatter zusammenarbeiten.
Siteforce – Pixelgenaue Erstellung von Webseiten ohne Code
Die Erstellung von Webseiten ist oft langwierig und mühsam und fordert kontinuierlich neue Landing Pages, Produkte und Kampagnen. Zusätzlich stehen Entwickler heute vor der Herausforderung, soziale, mobile und Echtzeit-Funktionen zu integrieren. Siteforce gibt Anwendern die Werkzeuge an die Hand, um einfache Änderungen vornehmen zu können. Web-Entwickler haben die Möglichkeit, schnell leistungsstarke Seiten zu liefern. Siteforce macht es einfach, in Echtzeit Seiten zu entwerfen, Inhalte zu verwalten und vorgefertigte Komponenten wiederzuverwenden.
VMforce – Der Weg für Java-Entwickler in die Cloud
VMforce, die salesforce.com-Partnerschaft mit VMware, ermöglicht es 6 Millionen Java-Entwicklern, ihre bestehende Java-Expertise sowie die Vorteile des Cloud Computings einzusetzen und neue, mobile und soziale Echtzeit-Anwendungen für Unternehmen in der Cloud zu erstellen. Mit VMforce können Entwickler ihre Java-Anwendungen direkt auf Force.com laufen lassen, die beliebten Java-Entwicklungsumgebungen Spring Framework und Eclipse IDE nutzen und offene Standards, wie zum Beispiel JPA für die Entwicklung von Javaanwendungen für Unternehmen verwenden. VMforce ist derzeit für ausgewählte Kunden als Beta-Programm verfügbar.
Heroku – Die Ruby Cloud Application-Plattform
Heroku ist die führende Ruby Platform-as-a-service, die von Beginn an in einer offenen Umgebung erstellt wurde, um die Vorteile der Programmiersprache nutzen zu können. Ruby ist die führende Sprache für die Erstellung einer neuen Generation von Apps. Diese sind sozial, kollaborativ und ermöglichen Echtzeit-Zugang zu Informationen über mobile Endgeräte. Heroku ist heute Grundlage für mehr als 105.000 Apps.
ISVforce – Ermöglicht ISVs die Erstellung und Bereitstellung von multi-tenant Cloud-Apps
ISVforce bietet ISVs umfassende Services für Anwendungsentwicklung, Tests und Bereitstellung, automatische Upgrade-Möglichkeiten, den AppExchange-Marktplatz für Cloud Apps sowie eine Echtzeit-Konsole zur Überwachung der Nutzung durch Kunden. ISVforce legt all diese Services hinter jede ISV App. Führende ISVs wie Blackboard, BMC und CA nutzen ISVforce um Anwendungen zu erstellen und zu liefern.
Mit RemedyForce veröffentlichen Salesforce.com und BMC gemeinsam webbasiertes IT Management-Tool. RemedyForce ist eine IT Service Management-Suite mit konsolidierten Service Desk-Funktionen, deren Leistungen für die Nutzer von Cloud-Lösungen optimiert wurden.
Eigenschaften von RemedyForce
Für Kunden von salesforce.com und BMC optimierte IT Service Management-Suite, die zentrale Service Desk-Funktionen mit Change Management-,
Amazon hat die Größenbeschränkung einzelner Objekte von Amazon S3 erhöht. Konnte ein Objekt vormals eine maximale Größe von 5 Gigabyte betragen, besteht nun die Möglichkeit ein einzelnes Objekt in der maximalen Größe von 5 Terrabyte in die Amazon Cloud hochzuladen.
Damit können nun hochauflösende Videos, große Backup Dateien, wissenschaftliche Auswertungen oder andere große Datenmengen innerhalb von Amazon S3 gespeichert und referenziert werden.
Um Objekte größer 5 Gigabyte zu speichern, empfiehlt Amazon die Nutzung der “Multipart Upload” Funktion, mit der Uploads parallel vorgenommen werden können.
Mit Database.com (http://www.database.com) bringt salesforce.com die weltweit erste für Cloud Computing konzipierte Datenbank für Unternehmen auf den Markt. Database.com unterstützt sämtliche Programmiersprachen, Plattformen und Endgeräte. Database.com wird als eigenständiges salesforce.com-Produkt angeboten. Database.com unterstützt die Entwicklung der IT-Industrie hin zu mobilen Applikationen und Datenmodellen für soziale Funktionalitäten sowie für Push-Dienste. Mit dem neuen webbasierten Datenbanksystem können sich Entwickler voll auf die Programmierung konzentrieren anstatt sich mit Wartung von Datenbanken und Hardware zu beschäftigen. Dabei kombiniert Database.com die besten Eigenschaften von Datenbanken für Geschäftsanwendungen (z.B. User Management, Sicherheit bis auf Feldebene, Trigger, gespeicherte Prozeduren, Authentifizierung und leistungsfähige APIs) mit den Vorteilen von Cloud Computing.
Vorteile von Database.com gegenüber klassischen Client/Server-Datenbanken
Database.com ist offen. Ob Anwendungen für kleine Nutzergruppen oder skalierbare Lösungen, auf die hunderttausende User gleichzeitig zugreifen: Entwickler können ihre Applikationen in Java, C#, Ruby, PHP und anderen Programmiersprachen schreiben und auf jeder Plattform betreiben, egal ob Force.com, VMforce, Amazon EC2, Google AppEngine Heroku oder Microsoft Azure. Die Anwendungen laufen auf jedem Engerät wie z.B. Android Phone, Blackberry, iPad oder iPhone und rufen die Schnittstellen von Database.com sicher über das Internet auf.
Database.com ist bewährt und sicher. Database.com profitiert von der Sicherheit der weltweiten Serviceinfrastruktur von salesforce.com, die SSL, Single-Sign On, Identitätsprüfung und Anti-Phishing-Tools umfasst. Zudem bietet sie sicheren Zugang durch vielfältige nutzer- und rollenspezifische Einstellmöglichkeiten sowie Datensicherheit bis auf Feldebene. Database.com wurden einige der strengsten Sicherheitszertifizierungen der Branche verliehen, wie zum Beispiel ISO 27001, SAS 70 Type II und SysTrust.
Database.com ist nicht nur die Datenbank, auf der sämtliche Services von salesforce.com laufen, sondern mit mehr als 20 Milliarden Datensätzen und über 25 Milliarden Transaktionen pro Quartal auch auch eine der größten Unternehmensdatenbanken weltweit.
Eigenschaften von Database.com
Relationale Datensicherung mit Tabellen, Bezügen, zahlreichen Feldtypen, Triggern, gespeicherten Prozeduren, Abfragesprache und Enterprise Search
Speicherung von Dateien wie Dokumente, Videos, Bilder etc.
SOAP und REST APIs für einfachen Zugriff auf die Database.com-Daten
Datenmodell für soziale Funktionalitäten. Database.com umfasst ein vorgefertigtes Datenmodell für verbesserte Zusammenarbeit, das Feeds, Nutzerprofile und Statusaktualisierungen unterstützt sowie ein Modell, mit dem es möglich ist, Datenbankeinträgen zu folgen. Zudem enthält Database.com APIs für die Interaktion mit den sozialen Komponenten der Datenmodelle. Entwickler können so beispielsweise Follower für Datenbankeinträge festlegen oder Datenfeeds anfordern, um Aktualisierungen in Echtzeit darzustellen.
Automatische Anpassung. Database.com unterstützt die Skalierung von Anwendungen über das Internet. Umfasst sind automatische Anpassungen, Upgrades, Remote-Datensicherung und -replikation sowie das automatische Anlegen von Umgebungen für Entwicklung, Tests und Schulungen.
Identitäten und Authentifizierung. Der Zugriff auf Database.com kann über oAuth oder SAML gesteuert werden. Die von Database.com unterstützten Funktionen für die Nutzerverwaltung umfassen Identitäten/Profile und Authentifizierung.
Sicherheit bis auf Feldebene. Point & Click-Werkzeuge erlauben es, den Datenzugriff bis auf Feldebene zu definieren. Die regelgesteuerte Filterlogik kann für sämtliche Datenbankabfragen von Anwendungen, die auf Basis von Database.com entwickelt wurden, genutzt werden.
Leistungsfähige Enterprise Search Dienste in Database.com erlauben eine Volltextsuche, die automatisch die Sicherheitsregeln des Unternehmens berücksichtigt.
Werkzeuge. Database.com enthält eine neue Entwicklerkonsole und ETL-Werkzeuge. Zudem stellt salesforce.com auf www.database.com eine Reihe von Entwickler Toolkits zur Verfügung, die die Anwendungsentwicklung beschleunigen. Diese umfassen Java, .NET, Ruby, PHP, iOS, Android, Google AppEngine, Google Data, Microsoft Azure, Amazon Web Services, Facebook, Twitter sowie Adobe Flash/Flex.
Preise und Verfügbarkeit
Aktuell ist die allgemeine Verfügbarkeit von Database.com für 2011 geplant.
Die Einstiegsnutzung von Database.com wird voraussichtlich kostenlos sein. Für grundlegende Database.com-Leistungen wie Datenbankzugriff, die Speicherung von Dateien und die automatische Wartung sind die folgenden Preisstaffelungen vorgesehen
Kostenlos für 3 Nutzer und bis zu 100.000 Datenbankeinträge und 50.000 Tranksaktionen/Monat
10 Euro für je 100.000 weitere Datenbankeinträge
10 Euro für je 150.000 weitere Transaktionen
Database.com Enterprise Services werden 10 Euro/User pro Monat kosten und Nutzeridentitäten, Authentifizierung und Kontrolle des Datenbankzugriffs auf Feldebene umfassen. Sowohl die allgemeine Verfügbarkeit als auch die angegebenen Preise können Änderungen unterliegen. Kunden sollten ihre Kaufentscheidungen auf aktuell verfügbare Produkteigenschaften gründen.
Mit Chatter Free stellt salesforce.com seinen Kunden eine neue, kostenlose Version von Salesforce Chatter zur Verfügung. Bei Chatter handelt es sich um eine Kollaborations-Applikation und -Plattform für Unternehmen. Mit Funktionen wie Profilen, Statusaktualisierungen und Echtzeit-Benachrichtigungen können Mitarbeiter auf Chatter nicht nur Personen folgen – vergleichbar Facebook und Twitter -, sondern auch Dokumenten, Geschäftsprozessen und Anwendungsdaten.
Mit Hilfe des von Facebook bekannten viralen Einladungsmodells kann jeder Mitarbeiter seine Kollegen zur Zusammenarbeit in Salesforce Chatter einladen, selbst wenn sie noch keine salesforce.com-Nutzer sind. Chatter Free beschleunigt so die Verbreitung sozialer Kollaboration im gesamten Unternehmen. Da Chatter auf der Force.com-Plattform aufsetzt, ist zugleich sichergestellt, dass die Mitarbeiter nur die Informationen einsehen können, für die sie autorisiert sind.
Chatter Free bietet unternehmensweit soziale Kollaborationsfunktionen, wie
Profile
Statusaktualisierungen
Echtzeit-Benachrichtigungen
Das Teilen von Daten
Gruppen
Filter
Einladungen
Chatter Desktop
Chatter Mobile
Salesforce Chatter bringt bestehenden salesforce.com-Kunden den Vorteil der Social Collaboration-Technologie. Mit Chatter Plus können Unternehmen diese Funktionen auch für zusätzliche Mitarbeiter, die die salesforce.com-Lösungen nicht nutzen, verfügbar machen. Zudem können die Anwender mit Chatter Plus auch Accounts, Kontakten, Dashboards, Reports, Kalendern und Aktivitäten folgen sowie benutzerspezifische Objekte oder die Chatter API nutzen.
Bei Amazon Route 53 handelt es sich um einen hochverfügbaren und skalierbaren DNS (Domain Name System) Web Service. Route 53 verbindet Nutzeranfragen effektiver mit einer Infrastruktur die sich innerhalb der Amazon Web Services (AWS) befindet, wie bspw. einer Amazon Elastic Compute Cloud (Amazon EC2) Instanz, einem Amazon Elastic Load Balancer oder einem Amazon Simple Storage Service (Amazon S3) Bucket. Route 53 kann darüber hinaus ebenfalls dazu verwendet werden, um Nutzer zu einer Infrastruktur ausserhalb von AWS zu routen.
Route 53 löst DNS Anfragen mit einer geringen Latenz auf, indem ein globales Netzwerk von DNS Servern genutzt wird. Anfragen an eine Domain werden automatisch an den nächstgelegenen DNS Server weitergleitet und damit mit der best möglichen Performanz beantwortet. Route 53 stellt eine Web Service Schnittstelle bereit, über die Public DNS Einträge erstellt und verwaltet werden können und ist vollständig in alle bereits vorhandenen Amazon Web Services integriert. Zum Beispiel kann durch die Nutzung des AWS Identity and Access Management (IAM) in Kombination mit Route 53 bestimmt werden, wer Änderungen an den DNS Einträgen vornehmen kann.
Für die Nutzung von Route 53 müssen, wie bei alle anderen Amazon Web Services, keine langen Vertragslaufzeiten eingegangen oder Mindestumsätze generiert werden. Die Abrechnung erfolgt pro Domain, die mit dem Service verwaltet wird und pro Abfrage, die von Route 53 beantwortet wird.
…, im Gegenteil, es schafft zunächst Probleme! Vor allem dann, wenn man selber als Anbieter Cloud Computing Services bereitstellen möchte.
Es ist ein Irrglaube, wenn man denkt, dass der Aufbau einer Private Cloud impliziert, sich anschließend nicht mehr um die Hochverfügbarkeit der eigenen Infrastruktur (physikalische Maschinen, virtuelle Maschinen, Master-Slave-Replikation, Hot-Standby, etc.) kümmern zu müssen. Das macht dann ja schließlich die Cloud alleine.
Achtung!!! Die Cloud bereitet einem (Private) Cloud Betreiber beim Aufbau zunächst mehr Probleme als man denkt.
Eine Cloud funktioniert nicht von alleine. Sie muss entwickelt und mit Intelligenz ausgestattet werden. Das gilt für den Aufbau einer Private Cloud genau so wie für die Nutzung eines Public Cloud Angebots (im Falle von IaaS). Dazu müssen Skripte geschrieben, womöglich Software neu entwickelt werden, die auf der Cloud verteilt läuft. Weiterhin ist es wichtig, die Whitepaper des jeweiligen Anbieter zu lesen, KnowHow(!) aufzubauen und zu verstehen, wie die Cloud arbeitet, um sie für die eigenen Bedürfnisse nutzen zu können. Eine weitere Möglichkeit besteht natürlich darin, sich (zusätzlich) von Profis beraten zu lassen.
Das ist bspw. bei der Nutzung des Public Cloud Angebots der Amazon Web Services auch nicht anders. Wenn eine Instanz A ein Problem hat, dann kann sie plötzlich nicht mehr erreichbar sein, wie jeder normale physikalische Server nun einmal auch. Nun könnte man denken: “Dann nehme ich als Backup für Instanz A halt noch eine Instanz B dazu!” Und dann? Man könnte nun denken, dass die Instanz B automatisch die Aufgaben der Instanz A übernimmt. So einfach ist das aber nicht!
Skripte etc. müssen vorab dafür sorgen, dass die Instanz B die Aufgaben von Instanz A übernehmen soll, wenn diese plötzlich nicht mehr erreichbar ist. Auch die Instanz B muss dafür zunächst vorbereitet werden.
Dazu kann z.B. der eigentliche (wichtige) Inhalt der Instanz A inkl. aller Konfigurationen etc. in ein EBS (Elastic Block Store) und nicht auf dem lokalen Instanzspeicher gespeichert werden. Anschließend muss ein Skript dafür sorgen, dass die Instanz B automatisch mit den Konfigurationen und allen Daten aus dem EBS hochgefahren wird, wenn die Instanz A nicht mehr verfügbar ist.
Die Cloud gibt uns im Bereich Infrastructure as a Service letztendlich nur die Möglichkeit, aus einem quasi unendlich großen Pool von Ressourcen die (unendliche) Anzahl an Ressourcen zu dem Zeitpunkt zu bekommen, wenn wir sie benötigen. Wir erhalten von dem Anbieter somit ein eigenes hochskalierbares virtuelles Rechenzentrum. Das bedeutet aber im Umkehrschluss für den Betreiber einer Cloud (Private, Public), dass er ebenfalls die Menge an physikalischen Ressourcen vorhalten muss, damit die angefragten virtuellen Ressourcen jederzeit bereitgestellt werden können und damit immer ausreichend Ressourcen für die Nutzer zur Verfügung stehen.
