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.
Die Agenda des CloudCamp Hamburg, welches am September 17th 2010 stattfindet, ist online.
| 17:00 | Registration & Networking |
| 17:45 | Welcome Note |
| 17:50 | Key Note by Chris Boos |
| 18:15 | Lightning Talks – Part 1 |
| Business / Benefit
Security / Data Privacy |
|
| 18:45 | Break |
| 19:00 | Lightning Talks – Part 2 |
|
Security / Data Privacy
Infrastructure / Services Open Source / Science |
|
| 19:30 | Unpanel |
| 20:00 | Break |
| 20:30 | Workshops |
| 22:00 | Workshops Nitty Gritty |
| 23:00 | Networking |
| 24:00 | End |
Nach meiner kürzlich leidvollen Erfahrung mit Google Docs, konnte ich das Problem analysieren und glücklicherweise selber beheben.
Lese dazu bitte “Ohnmächtig in der Cloud!” auf meinem privaten Blog by René -:- NET.
Google Docs ist so aufgebaut, dass jeder Benutzer über einen Bereich “Meine Ordner” verfügt, in welchem er beliebig Ordner und Dateien für andere Benutzer freigeben kann. Diese freigegeben Ordner sind unter dem Bereich “Für mich freigegebene Ordner” bei dem anderen Benutzer zu finden. Und genau hier lag das Problem.
Derzeit arbeiten wir mit 2 Benutzern in dem System. Aus Gründen der einheitlichen Struktur haben wir uns (wie man es aus Betriebssystemen wie Linux, Mac und Windows kennt) eine Ordnerstruktur angelegt, in welcher wir beide arbeiten. Diese Ordnerstruktur wurde bei dem Benutzer A angelegt (da ein zentraler Ablageort für beide Benutzer fehlt) und ist beispielhaft wie folgt aufgebaut:
[Ordnerstruktur bei Benutzer A]
Alle Ordner und die darin enthaltenen Dateien sind gegenseitig freigegeben.
Genau diese Struktur scheint Google bzw. Benutzer B (mir) das Genick gebrochen zu haben. Im Gegenzug hat nämlich Benutzer A unterhalb der Ordnerstruktur von Benutzer B keine Ordner/ Dateien angelegt und freigegeben, wodurch die oben beschriebenen Probleme bei ihm nicht aufgetreten sind.
Nachdem alle Ordner/ Dateien die von Benutzer B unterhalb der Ordnerstruktur von Benutzer A angelegt und freigegeben wurden, wieder in die Ordnerstruktur von Benutzer B verschoben wurden, waren die Probleme verschwunden.
Ergo: Ablage der Ordner und Dateien im eigenen Bereich und nur für andere Benutzer freigeben. Keine wilden Ordnerstrukturen, wie ich sie oben beschrieben habe, aufbauen!
Ich sehe hier ein enormes Problem im Freigabe- und Rechtesystem von Google Docs.
Die Idee, Ordner und Dateien in einem eigenen Bereich zu halten und ggf. für andere Benutzer freizugeben ist für die “normale” Version von Google Docs sehr praktikabel einzusetzen und hilft dabei untereinander in getrennten Google Accounts zusammenzuarbeiten.
Für die Unternehmensversion Google Apps, wo Benutzer innerhalb einer geschlossenen Domain arbeiten, muss Google an dieser Stelle deutlich nachbessern. Ein zentraler Speicherplatz für Ordner und Dateien ist hier ein sinnvollerer, effektiverer, aber vor allem praktikablerer Ansatz, da die Daten so zentral organisiert aufzufinden sind und nicht verstreut in den Bereichen unterschiedlicher Mitarbeiter liegen! Das führt zu einer besseren und einheitlichen Struktur, denn mittels “Suchen” möchte ich nicht jeden Tag arbeiten. Zudem bedenke man alleine nur den Fall, dass ein Mitarbeiter ausscheiden sollte. Eine in dieser Konstellation nicht ganz einfache Situation.
Die Zusammenhänge sind ein wenig kompliziert zu erklären und in diesem Zuge auch zu verstehen, machte aber die Analyse und Lösung ebenfalls nicht einfach!
Amazon ist mit seinen Amazon Web Services (AWS) derzeit der Player im Cloud Computing Markt. Was wir bereits erahnt haben bzw. wussten, haben die Analysten Brian Pitz und Brian Fitzgerald von der UBS nun anhand von Zahlen bestätigt.
Die beiden gehen davon aus, dass AWS im Jahr 2010 etwa einen Umsatz von 500 Millionen US Dollar generieren und diesen im Jahr 2011 auf 750 Millionen US Dollar erhöhen wird. Bis zum Jahr 2014 wird ein Umsatz in der Höhe von 2,54 Milliarden US Dollar erwartet.
Weiterhin wird davon ausgegangen, dass der Gesamtmarkt für AWS-Dienste zwischen 5 Milliarden und 6 Milliarden US Dollar im Jahr 2010 und schließlich bis zu 15 Milliarden und 20 Milliarden US Dollar im Jahr 2014 wachsen wird.
Eine unabhängige Studie des Cloud ICT zeigt, dass Cloud Computing in den Unternehmen angekommen ist. Die Kernfragen der Studie, in der mehr als 200 IT-Entscheider befragt wurden, kommen zu folgendem Ergebnis.
Setzt Ihr Unternehmen Cloud Computing ein?
Auf welche Art und Weise setzt Ihr Unternehmen Cloud Computing Technologien ein?
War das durchgeführte Cloud Computing Projekt erfolgreich?
Warum Unternehmen derzeit kein Cloud Computing einsetzen.
Top Gründe, warum ein Wechsel in die Cloud nicht in Frage kommt:
Top Cloud Computing Einsatzszenarien:
Erwarten Sie, dass die Adaption von Cloud Computing dazu führt, neue Lieferanten an Ihr Unternehmen anzubinden?
Wird Cloud Computing eine zusätzliche Komplexität in die gesamte Verwaltung von IT-Ressourcen bringen?
Sind Sie der Meinung, dass Cloud Computing zu einer kleineren IT-Abteilung führen könnte?
Zusammenfassend zeigt die Studie, dass über 96% aller Befragten ihre Cloud Computing Projekte erfolgreich umsetzen konnten und 72% die derzeit keine Cloud Technologie einsetzen, dem aber sehr positiv gegenüber eingestellt sind. Dagegen sehen 60% der Befragten Datenschutz, Integration und die Zuverlässigkeit als die zu lösenden Probleme des Cloud Computing, wobei 85% den Punkt Sicherheit derzeit als den Hauptfaktor ansehen, nicht in die Cloud zu wechseln.
Standardmäßig erhalten alle Amazon EC2 Instanzen zwei IP Adressen wenn sie gestartet werden. Eine private Adresse (RFC 1918) und eine öffentliche Adresse, die mit der privaten Adresse mittels Network Address Translation (NAT) verknüpft wird.
Sollte Dynamic DNS eingesetzt werden, um einen vorhandenen DNS Namen auf eine öffentliche IP-Adresse einer neuen Instanz abzubilden kann es bis zu 24 Stunden dauern, bis die IP Adresse im Internet bekannt ist. Das kann dazu führen, dass neue Instanzen noch keinen Datenverkehr empfangen, während bereits beendete Instanzen noch weitere Anfragen erhalten.
Diese Problematik umgeht Amazon EC2 mit den Elastic IP Addresses. Elastic IP Addresses sind statische IP-Adressen die für dynamisches Cloud Computing entwickelt wurden. Die Adressen werden einem AWS Account und nicht einer bestimmten Instanz zugeordnet. Jede Adresse die mit einem AWS Account verbunden ist, bleibt es auch solange, bis die Adresse wieder explizit freigegeben wird. Im Gegensatz zu herkömmlichen statischen IP-Adressen verbergen Elastic IP Addresses auftretende Fehler von Instanzen oder Verfügbarkeitszonen, indem die öffentliche IP-Adresse schnell einer anderen Instanz des AWS Accounts zugewiesen werden kann.
Es kann nur eine Elastic IP Address mit einer Instanz zur Zeit verknüpft werden. Wird eine Elastic IP Address mit einer Instanz verknüpft, wird die öffentliche IP Adresse der Instanz wieder für den öffentlichen IP-Adressen Pool von Amazon EC2 freigegeben. Wird die Elastic IP Address wieder von der Instanz gelöst, erhält die Instanz innerhalb von ein paar Minuten automatisch eine neue öffentliche IP-Adresse.
Im folgenden Bild sind die Web Server über Elastic IP Addresses mit dem Internet und über ihre privaten Adressen mit den Datenbankservern verbunden.
Der Administrator hat sich entschieden, einen Web Server durch einen größeren Instanz Typ zu ersetzen. Dazu startet er eine neue Instanz mit einem größeren Instanz Typ (1). Anschließend löst er eine Elastic IP Address von einer bereits gestarteten Instanz (2). Nun verknüpft er die Elastic IP Address mit der neuen Instanz (3) und beendet die alte Instanz (4).
Elastic IP Addresses die nicht mit einer Instanz verknüpft sind, werden stündlich berechnet. Dagegen sind Elastic IP Addresses die mit einer Instanz verbunden sind kostenlos.
Quelle
Dieses Tutorial dient als Schritt für Schritt Anleitung zur Einrichtung einer openQRM Cloud auf einem Ubuntu 10.04 Lucid Lynx und der KVM Virtualisierungstechnologie. Benötigt wird dafür ein physikalisches System, auf welchem VT (Virtualization Technology) aktiviert ist.
Während der Installation des Systems nehmen wir eine manuelle Partitionierung vor und erstellen 3 Partitionen:
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
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:~$
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:~$
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.
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:~$
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.
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.
Als Nächstes müssen wir die folgenden Plugins aktivieren und starten:
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.
Nun müssen wir openQRM die virtualisierten Hosts mitteilen. Dazu gehen wir nach Base >> Appliances >> Create und wählen “openQRM Server” als “resource”.
Nun wechseln wir nach Plugins >> Cloud >> Configuration >> Main Config und konfigurieren die folgenden Punkte:
Für alle weiteren Konfigurationspunkte können die Standardwerte genommen werden. Speichern nicht vergessen!
Der folgende Screenshot zeigt die Hauptseite zur Konfiguration der 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.
Beim Einsatz von Cloud Computing gilt es rechtliche Fragen zu klären. Sind die wichtigsten allerdings bekannt und können diese beantwortet werden, steht dem rechtlich sicheren Einsatz von Cloud Computing nichts mehr im Weg.
In einer Public Cloud haben die Benutzer nicht mehr die vollständige Kontrolle und den Überblick, wo ihre Daten tatsächlich gespeichert sind. Wo allerdings keine Kontrolle herrscht, kann auch nicht gesteuert werden. Die nicht mehr vorhandene Hoheit der Daten führt in diesem Fall zu rechtlichen Problemen. Hier sollte zunächst der Ansatz verfolgt werden, keine personenbezogenen Daten in die Cloud zu verlagern, da diese nicht den deutschen Datenschutzbestimmungen unterliegen. Werden allerdings doch personenbezogene Daten in der Cloud gespeichert, muss hier in jeden Fall die Zustimmung aller betroffenen Personen vorliegen.
Des Weiteren kann der Speicherort der Daten auf eine bestimmte Region festgelegt werden. In diesem Fall werden die Daten z.B. ausschließlich in Deutschland gespeichert, wodurch automatisch die deutschen Datenschutzbestimmungen gelten. Dabei sollte vorher natürlich vertraglich festgehalten werden, dass die Daten ausschließlich in dieser bestimmten Region abgelegt werden und nicht über mehrere verteilt sind.
Eine mögliche “Lücke” erhalten Cloud Anbieter mittels des Paragraphen 11 des Bundesdatenschutzgesetzes (BDSG). Dieser regelt die sogenannte Auftragsdatenverarbeitung. Dabei erhält der Cloud Anbieter durch den Auftrag seines Kunden das Recht die personenbezogenen Daten zu verarbeiten. Das impliziert natürlich, dass eine Verarbeitung der Daten nur dann vorgenommen werden darf, wenn der Kunde explizit die Rechte für das Erheben, Nutzen und Verarbeiten hat. Das ganze funktioniert natürlich nur, wenn der Kunde auch der Herr dieser Daten ist, also volle Kontrolle darüber hat. Allerdings spricht dieses genau gegen den eigentlichen (organisatorischen) Sinn und Hintergrund des Cloud Computing, da die in diesem Modell Daten per se überall verteilt gespeichert sind. Hinzu kommt, dass die Auftragsdatenverarbeitung nur im Wirtschaftsraum der europäischen Union (EU) so umgesetzt werden kann. Außerhalb der EU gelten andere Gesetzt zur Verarbeitung personenbezogener Daten.
Weiterhin ist zu beachten, dass die Daten in der Cloud verschlüsselt gespeichert sind, aber im Falle der Verarbeitung entschlüsselt werden müssen. Hier müssen noch technische Lösungen gefunden werden. Abgesehen davon müssen Anbieter von Cloud Services, speziell für Angebote in Deutschland das BDSG und hier insbesondere den Paragraph 9 beachten. In diesem sind alle Anforderungen festgehalten, die benötigt werden, um die technischen und organisatorischen Vorschriften des BDSG einzuhalten. Dazu gehört ebenfalls, wie der physische Zutritt, der Zugriff, die Eingabe und die Weitergabe der Daten nach Datenschutz- und Compliance spezifischen Vorgaben zu erfolgen hat.
Wichtig bei der Verlagerung der Infrastruktur in die Cloud sind – nicht nur rein rechtlich – die Leistungsübergabepunkte. An diesen Punkten wird u.a. die Verfügbarkeit eines genutzten Services festgelegt und gemessen. Hier gilt es also mittels eines Service Level Agreement (SLA) vertraglich festzulegen, welche Pflichten ein Cloud Anbieter gegenüber seinen Kunden zu erfüllen hat. Dazu gehören u.a. das Vorhandensein von Notfallplänen, die Verfügbarkeit der Services, aber auch die Möglichkeit für den Kunden, die im Vertrag festgehaltenen Pflichten mittels eines Audits zu überprüfen. SLAs sollten hinsichtlich der Art des spezifischen Services definiert werden, realistisch messbar sein und vor allem die tatsächlichen Leistungsanforderungen reflektieren. Für den Fall, das ein Service Level nicht eingehalten wird, müssen entsprechende (hohe) Strafzahlungen für den Cloud Anbieter vorgesehen werden.
München – Facebook hat für das Management seiner wachsenden Vertriebsaktivitäten die CRM-Lösung Sales Cloud von salesforce.com ausgewählt. Der Social Networking Anbieter stand vor der Entscheidung, das eigene System weiter auszubauen oder eine komplett neue Lösung einzusetzen. Die Vorteile eines webbasierten Ansatzes haben überzeugt: Durch die schnelle Implementierung und die hohe Skalierbarkeit kann die Cloud Computing Lösung mühelos mit der rasanten Wachstumsgeschwindigkeit eines Unternehmens wie Facebook Schritt halten. Das neue CRM-System wird bei allen Vertriebsteams sowie für das Management der Entwicklerpartnerschaften eingesetzt, um komplexe Workflows und Freigabeprozesse zu automatisieren.
Kommentare:
Sheryl Sandberg, Chief Operations Officer bei Facebook: „Facebook und salesforce.com teilen eine Vision: Wir wollen Menschen dabei unterstützen, miteinander in Kontakt zu treten und Informationen effizienter auszutauschen. Das Cloud Computing Modell von salesforce.com passt perfekt zu uns. Mit unserer derzeitigen Wachstumskurve und den zukünftigen Vertriebszielen brauchen wir ein Produkt, das mit uns mit wachsen kann.“
Marc Benioff, Gründer und CEO von salesforce.com: „Facebook schließt sich den Tausenden von Unternehmen an, die ihre Vertriebsaktivitäten bereits in der Cloud verwalten. Damit können sich Vertriebsverantwortliche auf das Wachstum des Unternehmens konzentrieren, anstatt auf die Bedienung von Hard- und Software.“
Bei AppLogic handelt es sich um eine vorgefertigte Cloud Computing Plattform, auf der verteilte Anwendungen skalierbar ausgeführt werden können. Mittels AppLogic können Cloud Angebote und Utility Computing Services für transaktionale sowie Streaming Anwendungen im eigenen Rechenzentrum betrieben werden.
Auf Grund der Transparenz und Herstellerunabhängigkeit ist AppLogic zu den gängigen Betriebsystemen, Middlewares und Web Anwendungen kompatibel, wodurch eine Vielzahl von vorhandener Infrastruktursoftware, Middleware und Anwendungen unverändert genutzt werden können.
Mit AppLogic kann eine vollständig verteilte Anwendung (N-tier) oder Service in eine logische Einheit zusammengefasst und anschließend wie ein einziges System verwaltet werden. Dazu erfasst und arbeitet AppLogic auf der logischen Struktur der Anwendung. Dieser Ansatz ermöglicht zudem das Zusammenstellen, das Deployment, das Monitoring, die Steuerung und die Fehlersuche visuell mittels eines Webbrowsers.
Jede Anwendung beinhaltet alles was sie benötigt, um innerhalb eines Grids von Commodity-Servern ausgeführt zu werden, wie z.B. die Infrastrukturkomponenten (Firewalls, Loadbalancer, Netzwerkkonfiguration, etc.) bis hin zur Anwendungslogik, Web- und Datenbankservers, inkl. dem Anwendungscode und der Anwendungsdaten. Tools für das Monitoring und Messen gehören des Weiteren ebenso dazu wie vorbereitete operative Funktionen wie z.B. Backup-Scheduler und SLA Richtlinien.
Aus den oben beschriebenen Gründen können auf AppLogic ausgeführte Anwendungen von einer geringen Anzahl von Servern auf mehrere Hundert skaliert werden. Dazu kommt die Möglichkeit der On-Demand Replizierung und das mehrfache Deployment auf dem selben Grid oder über mehrere Standorte hinweg, ohne Code Änderungen vorzunehmen.
Paketieren von Anwendungen zur on-Demand Bereitstellung
Mit AppLogic können mehrere Instanzen bereits vorgefertigter Web Anwendungen ausgeführt werden, wodurch on-Demand Anwendungen wie CRM, E-Mail oder VoIP PBX schnellt bereitgestellt werden können.
Hierzu können für jeden Kunden eine gewünschte Anwendung mit einer IP-Adresse und den benötigten Hardware Ressourcen ohne manuellen Eingriff konfiguriert und in kurzer Zeit zur Verfügung gestellt werden.
Anwendungsbereitstellung auf einer vorgefertigten Infrastruktur
Web Anwendungen können ohne den notwendigen Konfigurationsaufwand der Server und der Infrastruktur skalierbar bereitgestellt werden. Dazu wird eine Standard Infrastruktur aus einem Katalog ausgewählt, die benötigten HTML Dateien, Skripte, und Datenbanken auf ein logisches Volume kopiert und die Anwendung gestartet.
Weiterhin kann der Deploymentvorgang über Skripte in den Build-Vorgang intergriert werden, wodurch alle vorgenommen Änderung automatisch über das gesamte Grid verteilt werden, wenn der Code neu generiert wird.
Skalierung ohne den Aufbau eines mandantenfähigen Systems
SaaS Anwendungen haben den Anspruch voneinander getrennt betrieben zu werden, so das maximal nur Benutzer aus der selben Organisation den Zugriff auf dieselben Daten erhalten. Nutzer anderer Organisationen dürfen dagegen keinen Einblick auf die Anwendung und Daten haben, auch wenn sich diese logisch auf dem selben System befinden.
Innerhalb von AppLogic erhält jede Anwendung ihre eigene separierte Infrastruktur wie Datenbanken, Applikationsserver etc., wodurch der oben genannte Anspruch erfüllt und Ausfälle in Systemen eines Kunden nicht die Systeme anderer Kunden beeinflussen.
Entwicklung neuer Web Anwendungen
AppLogic bietet die Möglichkeit (neue) Anwendungen mit exakt derselben Infrastruktur (Middleware / Systemkonfiguration) zu testen, wie sie auch später in der Produktion eingesetzt wird. Dazu kann die Anwendung weiterhin in einer Sandbox auf einem einzigen Server betrieben, oder über das gesamte verfügbare Grid verteilt werden, um die Last unter Echtzeitbedingungen zu testen.
Aufbau einer N-Tier Anwendungsinfrastruktur
Mit Hilfe des AppLogic Visual Infrastructure Editor können komplex und verteilte Infrastrukturen skizziert, aufgebaut und repliziert werden. Dazu steht ein Katalog unterschiedlicher virtueller Appliances zur Verfügung, mit dem die Systeme visuell konfiguriert und Fehler identifiziert werden.
Weiterhin können oft und bereits vorkonfigurierte Subsysteme wie z.B. Datenbankcluster oder Applikationsserver Cluster für viele unterschiedliche Anwendungen mehrfach verwendet werden.
Neben dem Monitoring System, mit welchem visuell u.a. die aktuelle Last dargestellt werden kann, besteht ebenfalls der Zugriff per SSH auf jede vorhandene Appliance. Abgerundet werden die Funktionen mit der Möglichkeit eine Art Snapshot von dem aktuellen Stand einer Applikation vorzunehmen, um im Bedarfsfall einen Rollback zurück zu diesem Stand durchzuführen.
Alle Utility Computing Benutzern haben gemein, dass Online-Dienste ihre Hauptgeschäft sind. Dabei wirkt sich die Skalierbarkeit und die Kosten ihrer Infrastruktur unmittelbar auf die Bruttomarge und die Fähigkeit aus zu wachsen.
IT Outsourcer die auf SaaS und Online Services fokusiert sind
Unternehmen die Internet Service Provider dabei unterstützen, Online Anwendungen anzubieten und dabei serviceorientiert und skalierbar zu agieren.
Managed Hosting Provider
Unternehmen deren Schwerpunkt im Bereich Datacenter Operations liegt, können ihre bereits vorhandenen Hosting-Angebote mittels vorgefertigten Umgebungen erweitern.
Software-as-a-service (SaaS) Anbieter
Software as a Service Anbieter die regelmäßig neue Web Anwendungen entwickeln, können ihre Go-To-Market Kosten sowie den Time-To-Market reduzieren.
Web 2.0 Unternehmen
Unternehmen im Web 2.0 Umfeld können ihre Online Services skalierbar anbieten, so dass auch in lastintensiven Zeiten ihre Angebote performant zur Verfügung stehen.
Virtual Appliances
Innerhalb von AppLogic werden IT-Infrastrukur Komponenten wie Firewalls, Load Balancer, Server und SANs als bereits vorab integrierte und vorab getestete Virtual Appliances abgebildet. Dabei wird jede Appliance in ihrer eigenen virtualisierten Umgebung ausgeführt. Sie startet ihr eigenes Linux System und erscheint gegenüber der auf der Appliance laufenden Software wie ein physikalischer Server. Neben der bereits vorhandenen Open Source Infrastruktur Software wie Fedora Linux, Apache, MySQL JBoss etc., können die Appliances auf die eigenen Bedürfnisse angepasst bzw. von Grund auf neu aufgesetzt werden.
“Einweg” Infrastruktur
Die Infrastruktur wird graphisch zusammengesetzt und als Teil einer Anwendung innerhalb von AppLogic gespeichert. Dabei kann die Infrastruktur im wesentlichen als “Einweg” Komponente bezeichnet werden, da sie auf dem Grid instanziiert wird wenn die Anwendung ausgeführt wird, die Wartung solange erfolgt, bis die Anwendung sie benötigt und entsorgt wird, wenn sich die Anwendung beendet.
Vorgefertigte verteilte Anwendungen
AppLogic verpackt den gesamten Code, die dazugehörigen Daten, sowie die Infrastruktur die zum Ausführen einer skalierbaren Web Anwendung benötigt werden in eine logische Einheit. Diese Einheit kann anschließend gestartet, gestoppt, verwaltet, kopiert oder in ein anderes Grid exportiert werden, ohne eine Änderung daran vornehmen zu müssen.
Zentrale Verwaltung
AppLogic fügt mehrere Commodity Server in ein skalierbares Grid zusammen, das mittels eines Browser oder einer Kommandozeile wie ein einzelnes System verwaltet wird. Zu den Verwaltungsmöglichkeiten gehören Dinge wie das Hinzufügen und Entfernen von Servern “on the fly”, also während das Grid weiterhin ausgeführt wird, die Überwachung der Hardware, das Verwalten von Benutzerdaten, Neustart der Server, Installation von Software, erstellen virtueller Appliances, Systembackups, Reparatur defekter Speichervolumes oder das Prüfen der Logs.
Skalierung von Anwendungen
Anwendungen auf Basis von AppLogic sind vollständig virtualisiert und können von einer kleinen Anzahl von Servern auf viele skaliert werden.
Überwachung der Operationen
AppLogic verfügt über ein Monitoring System, welches völlig transparent zu den Operationen der Web Anwendungen auf dem Grid agiert. Das System kombiniert die Hardware-Infomationen zur Laufzeit, die Informationen der virtuellen Infrastruktur sowie die Informationen der Anwendungen und macht diese über eine graphische Oberfläche verfügbar. Dabei können die System Ressourcen auf Basis der Anwendungen, der virtuellen Appliances/Server oder dem Netzwerkverkehr, sowie diversen Parametern bekannter Softwareinstallation wie Apache oder MySQL überwacht werden.
Hohe Verfügbarkeit
Zur Erhöhung der Verfügbarkeit bietet AppLogic neben der Spiegelung der gespeicherten Daten über mehrere Server hinweg die Möglichkeit einzelne Systeme wiederherzustellen. Weiterhin können zwei identische Instanzen einer Anwendung auf dem selben Grid oder in verschiedenen Rechenzentren parallel betrieben werden, um auf Basis von “Hot Standby” den Ausfall der Anwendung abzufangen und damit die Verfügbarkeit zu erhöhen.
Überwachung der Ressourcen
AppLogic verfügt über ein integriertes System zur Überwachung der Ressourcen, die von jeder Anwendung genutzt werden. Dazu werden alle Events im Lebenszyklus einer Anwendung verfolgt und protokolliert, um den Ressourcenbedarf wie die Anzahl an Speicher, Prozessorleistung und Bandbreite zu ermitteln, die einer Anwendung zu dem Zeitpunkt des Events zugewiesen waren. Die Protokollierung kann weiterhin dazu genutzt werden, um ein Abrechnungssystem mit Daten zu versorgen und einen Kunden damit exakt die Ressourcen zu berechnen, die er benötigt hat.
Automation und Integration
AppLogic verfügt über eine umfangreiche Kommandozeile inkl. Skripting Funktion und der Möglichkeit zur Anbindung an weitere Management Systeme für Rechenzentren. Auf Basis der Skripte können logische Bedingungen definiert werden, die z.B. den Start, Neustart oder das Beenden von Anwendungen und Appliances hervorrufen.
Ausführen bestehender Anwendungen
Nahezu alle bestehenden Multi-Tier-Anwendung auf Basis von Linux können auf AppLogic ausgeführt werden.
AppLogic stellt eine auf AJAX basierende graphische Web-Oberfläche bereit, mit der die gesamte Infrastruktur Umgebung konzipiert und überwacht werden kann.
Die vier folgenden Komponenten bilden das Herzstück von AppLogic und werden durch Screenshots anschließend illustiert.
Auf die Kommandozeile wird mittels einer Browser basierten Shell zugegriffen. Diese bietet die vollständige Kontrolle über die Anwendungen und Appliances. Dazu gehören das Starten und Stoppen, sowie das reparieren von Volumes oder die Migration von Anwendungen zwischen einzelnen Rechenzentren.
Quelle
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 folgenden Schittstellen stellen eine einfache Möglichkeit für das Remote Management von Cloud Ressourcen dar.
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
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.