Schlagwort: featured

Vertrauen ist gut, Kontrolle ist besser! Das EuroCloud SaaS Star Audit.

Beitragsautor Von Rene Buest
Beitragsdatum Oktober 18, 2011
1 Kommentar zu Vertrauen ist gut, Kontrolle ist besser! Das EuroCloud SaaS Star Audit.

Im stetig wachsenden Cloud Computing Markt wird es immer schwieriger den Überblick zu behalten. Tagtäglich drängen mehr Anbieter auf den Markt, um ihre Services der Öffentlichkeit, insbesondere Unternehmen, schmackhaft zu machen. Software-as-a-Service Lösungen haben bzgl. der Marktpräsenz die Nase vorn. Im Vergleich zu den anderen Cloud Servicearten wie bspw. IaaS oder PaaS, sind diese relativ einfach umzusetzen, da die dafür benötigte Infrastruktur in der Regel von einem Infrastrukturdienstleister bezogen wird. So wird es für Unternehmen immer schwieriger den für sich richtigen Anbieter zu finden. Hinzu kommen die Transparenz und das damit verbundene Vertrauen zu dem Dienstleister. Die eigenen Daten werden schließlich nicht jedem anvertraut.

Der EuroCloud e.v. hat dazu speziell für SaaS Anbieter ein Zertifizierungsprogramm gestartet. Das sogenannte EuroCloud SaaS Star Audit soll jedem Unternehmen helfen, welches eine dezidierte SaaS Anwendung betreibt. Der Anwender soll damit im Umkehrschlus ein aussagefähiges Testat zur Auswahlentscheidung erhalten. Ziel des gesamten Audits ist für ein hohes Maß an Sicherheit und Transparenz für Anwender und Betreiber zu sorgen.

Der Inhalt des Audits umfasst das allgemeine Profil des Anbieters, die Verträge und Compliance sowie das Thema Datenschutz. Darüber hinaus werden die allgemeine Sicherheit, der Betrieb und die Infrastruktur sowie die Betriebsprozesse betrachtet. Abgerundet wird das Audit mit einem Blick auf die Anwendung selbst und dessen Implementierung.

Ingesamt vergibt das EuroCloud SaaS Star Audit je nach Erfüllung der Anforderungen 5 Sterne. So muss ein Anbieter für einen Stern mindestens die folgenden Bedingungen erfüllen:

Es handelt sich um ein im EU Handelsregister eingetragenes Unternehmen.

Der technische Betrieb der Anwendung erfolgt in einer für die Bereitstellung von webbasierten Diensten geeigneten Infrastruktur. Hierzu gehört:

abgeschlossener Bereich für die verwendeten Hardware-komponenten

Redundante Stromversorgung mit USV Betrieb für mindes-tens 20 Minuten

Redundante Internetanbindung

Zutrittskontrolle

Grundlegende Arealsicherheit

Die vertraglichen Vereinbarungen sind konform mit den Datenschutz-Anforderungen im Sinne des BDSG.

Es bestehen nachvollziehbare Kündigungsvereinbarungen.

Es bestehen eindeutige Vereinbarungen bezüglich der Kundendaten ohne Rückbehaltungsanspruch durch den Auftragnehmer.

Es bestehen vertraglich vereinbarte Regelungen mit dokumentierten Daten-Exportschnittstellen zur Rückgabe und Löschung von Kundendaten bei Beendigung des Vertragsverhältnisses.

Je nach Zertifizierungsstufe kommen immer mehr Bedingungen hinzu, wobei zunächst jeweils die Vorstufe erfüllt sein muss, bevor die nächste Stufe zertifiziert werden kann.

Stand heute wurden bereits zwei Unternehmen nach dem EuroCloud SaaS Star Audit zertifiziert. Die Pironet NDH Datacenter GmbH mit ihrer Anwendung „PIRONET Office Web Apps“ erhielt 5 Sterne. Die optivo GmbH mit ihrer Anwendung „optivo® broadmail“ 4 Sterne.

Mehr unter http://www.saas-audit.de

Schlagwörter featured

Analysen

Google vs. Microsoft: Der Kampf um die Vorherrschaft in der Business Cloud

Beitragsautor Von Rene Buest
Beitragsdatum August 5, 2011
Keine Kommentare zu Google vs. Microsoft: Der Kampf um die Vorherrschaft in der Business Cloud

Was mit dem Einstieg von Bing im Suchmaschinenmarkt und der anschließenden Einführung von StreetSide bei der Katalogisierung der Welt begann, weitet sich nun auch auf den Unternehmensbereich aus. Hatte Google mit Google Apps for Business auch hier das erste Produkt, zieht Microsoft nun mit Office 365 nach.

Es wird wahrscheinlich der spannendste Kampf in der Cloud überhaupt. Noch interessanter als bspw. Google vs. Apple oder Google vs. Facebook – der Kampf um die vorherschende Stellung in den Unternehmen, wenn es darum geht, welche Office und Collaboration Suite in Zukunft in der Cloud eingesetzt wird. Microsoft ist der Platzhirsch der lokalen Installation. Google hat sich von Beginn an auf die Nutzung von Cloud Applikationen konzentriert und bewegt sich mit seinen Google Apps for Business derzeit gezielt auf die Unternehmen zu. Das hat auch Microsoft erkannt und schickt im Gegenzug sein Office 365 ins Rennen.

Google geht den Microsoft Weg

Microsofts Weg in die Unternehmen ging damals über die Heimanwender von Windows, Office und Outlook Produkten. Die Strategie ging auf. Wer auch am Abend mit den „bekannten“ Programmen aus Redmond arbeitet, hat es tagsüber bei der Arbeit leichter, da er sich damit auskennt. Auch die Empfehlungen für ein Produkt von Microsoft durch die Mitarbeiter war dadurch vorprogrammiert. Dasselbe galt für die Windows Server. Wenn ein Windows Betriebssystem so einfach zu bedienen und zu konfigurieren ist, dann kann ein Server schließlich nicht viel komplizierter sein. Damit konnten auch die Entscheider ins Boot geholt werden.

Googles Strategie könnte bzw. sollte ähnlich verlaufen. Schätzungsweise nutzen bereits 200 Millionen Nutzer weltweit Google Mail. Damit erhalten diese ebenfalls kostenlosen Zugriff auf die Produkte Google Calendar als auch Google Docs, neben Google Groups die drei Kernanwendungen der Google Apps for Business. Ideal, um potentielle Unternehmensanwender mit dem Google Gen zu infizieren und damit Google Apps for Business in den Unternehmen zu platzieren.

Google hat gegenüber Microsoft den Vorteil, dass Sie in der Cloud „geboren“ sind und darin „leben“. Microsoft hingegen ist erst „eingezogen“ und ist noch dabei (technologisch) seinen Platz zu finden. Microsofts Vorteil besteht eindeutig in seinen bestehenden Beziehungen zu den Unternehmenskunden. Weltweit nutzen schätzungsweise 80% der Unternehmen Produkte aus dem Hause Microsoft, darunter Windows, Office, Outlook und Exchange. Nicht zu vergessen weitere Produkte wie Dynamics CRM usw. Damit hat Microsoft einen enormen Vertrauensvorsprung gegenüber Google. Auch die Wechselkosten bspw. von einer On-Premise Exchange Installation hin zu Office 365 scheinen deutlich günstiger und einfacher, da die Schnittstellen auf beiden Seiten durch Microsoft spezifiziert sind. Hier muss jedoch fairerweise gesagt werden, dass Google über gute Migrationstools von unterschiedlichen Systemen hin zu Google Apps verfügt.

Googles Schwierigkeit besteht jedoch darin Vertrauen aufzubauen. Das Unternehmen aus Mountain View gilt immer noch als die alleinherrschende Datenkranke und ist zudem bei den meisten weiterhin „nur“ als eine Suchmaschine bekannt. Aber auch technologisch muss Google nachbessern. Wer aus der Windowswelt kommt, kennt die zentralen Ordnerstrukturen auf den Dateiservern. Die Ordnerstruktur unter Google Docs ist hier sehr unelegant gelöst. Es existiert kein zentraler Bereich, in dem die Nutzer ihre Daten allen zur Verfügung stellen können. Stattdessen erhalten andere Benutzer nur über persönliche Freigaben den Zugriff auf die Daten eines bestimmten Nutzers. Natürlich kann alles über die integrierte Suche gefunden werden, was auch zu Google passt, ist für den Unternehmenseinsatz jedoch sehr unpraktisch.

Die Mobile Cloud

Google hat insbesondere im wichtigen Unternehmensbereich der Mobile Cloud die Nase vorne. Die vollständige Integration von Google Apps (Google Mail, Google Kalender, Google Kontakte usw.) in Android, den Chrome Webbrowser und somit auch in den Chromebooks per sync bzw. push über eine drahtlose Internetverbindung (WLAN, 3G) ist ein entscheidener Vorteil gegenüber Microsoft.

Microsoft hat es seit jeher nicht geschafft ein gutes und stabiles Betriebssystem für mobile Endgeräte zu entwickeln und darüber hinaus eine nahtlose und gute Integration (sync) bspw. zu Outlook zu schaffen. Zudem muss alles per Active Sync vorgenommen werden, wozu das Endgerät an den lokalen Computer angeschlossen werden musste. Windows Phone 7 könnte möglicherweise ein erster guter Schritt sein.

Tipps für Google

Für Google gilt es in erster Linie Vertrauen zu schaffen und über den Schatten der Suchmaschine weiter hinauszukommen. Das Image der Datenkrake wird wahrscheinlich niemals vollständig verschwinden, aber über den Aufbau von Vertrauen zu den Unternehmen kann daran aber gearbeitet werden.

Darüber hinaus sollte die Strategie verfolgt werden, über den privaten Google Nutzer in die Unternehmen zu gelangen. Der gewöhnliche Mitarbeiter hat doch mehr Einfluss als gedacht.

Technologisch und organisatorisch muss Google Docs unbedingt nachgebessert werden. Das Nichtvorhandensein einer zentralen Ordnerstruktur führt zu einer schlechten Übersicht der Daten, da sich diese überall und bei jedem Benutzer, der zu der Google Apps Domain gehört, befinden können. Wir haben uns bisher so geholfen, dass wir bei einem Benutzer die Ordnerstruktur aufgebaut haben in der alle anderen Nutzer neue Ordner und Dokumente ablegen. Das ist jedoch sehr unpraktisch. Die Idee für den Privatbereich ist gut, um einem Freund mal eben schnell nur eine bestimmte Datei freizugeben. Für den Einsatz im Unternehmen, ist dieses Vorgehen aber nicht praktikabel. Vermutlich handelt es sich dabei um eine Funktion, die aus den Versionen für den privaten Einsatz einfach übernommen wurden. Es sollte daher zwar private Bereiche geben, aber ebenfalls einen zentralen Ort, auf denen alle Benutzer zugreifen können ohne das vorher Freigaben etc. erstellt werden müssen.

Die Angst bzgl. des Datenschutzes, der Datensicherheit und der Compliance ist den Köpfen der Entscheider weiterhin sehr hoch angesiedelt. Insbesondere der Zugriff von Regierungen und staatlichen Behörden auf die Unternehmensdaten ist ein Knock-Out Kriterium. Google muss sich hier eindeutig davon distanzieren, jemals den Zugriff durch staatliche Organe usw. auf die Daten zu gewähren und dieses seinen Kunden vertraglich zusichern. Dieses kann durch politische Vorgaben, wie bspw. dem Patriot Act oder einem Abkommen zwischen zwei Staaten jedoch erschwert werden. Im zweiten Fall wird bspw. geregelt, dass ein Staat A einem anderen Staat B im Verdachtsfall die Daten aushändigen muss. Und das gilt ebenfalls unabhängig davon, ob es sich bei dem Unternehmen um einen Cloud Computing Anbieter handelt oder ob sich die Daten auf einem Server im eigenen Rechenzentrum befinden.

Darüber hinaus könnten die Google Apps for Business als On-Premise Lösunge für die Unternehmen angeboten werden, die über eine Private Cloud verfügen und ihre Daten nicht aus der Hand geben wollen, dürfen oder können.

Tipps für Microsoft

Microsoft hat auf Grund der aktuellen Präsenz im On-Premise Geschäft die besseren Karten. Jedoch war die Aussage, Regierungen und stattlichen Behörden auf Anfrage ggf. den Zugriff auf die Daten zu gewähren, ein schwerwiegender Fehler, wodurch das Vertrauen in Microsoft gesunken ist. Zumindest zeigen das die Diskussionen vergangener Tage, zu denen sogar die Cloud Infrastrukturanbieter keine konkrete Stellung beziehen wollen.

Insbesondere in dem Bereich der Mobile Cloud muss Microsoft kräftig investieren und Boden gut machen. Die Mobilität und der Wunsch auf die Daten und Anwendungen zu jeder Zeit und an jedem Ort zuzugreifen wird weiter steigen. Hier muss ein Umdenken stattfinden. Einen Chromebook Clone auf Basis von Windows zu entwickeln wird da nicht ausreichen.

Fazit

Der Kampf um den Bereich für Unternehmensanwendungen in der Cloud hat erst begonnen und es bleibt weiter spannend. Speziell Microsofts Aussage, mit den Regierungen zusammenarbeiten zu wollen, könnte Google das Stück Vertrauen verschaffen das für den Einsatz von Google Apps im Unternehmen notwendig ist.

Es bleibt zudem interessant zu sehen, wie sich das Windows Phone 7 und die Integration der Office 365 Cloud Services entwickeln werden, damit Microsoft auch hier Boden gut machen kann.

Alles in allem stehen hier zwei Unternehmen mit ihren Produkten gegenüber, die es beide verdient hätten, in den Unternehmen eingesetzt zu werden – am Ende entscheidet jedoch die jeweilige Cloud Strategie.

Schlagwörter Bing, Cloud Kampf, CloudWar, Exchange, featured, GMail, Google, Google Apps, Google Apps for Business, Google Cloud, Google vs. Microsoft, Microsoft, Microsoft Cloud, Microsoft Office 365, Office, Office 365, Outlook, StreetSide, StreetView

Tutorials

Einrichtung einer openQRM Cloud mit KVM auf Ubuntu Lucid Lynx

Beitragsautor Von Rene Buest
Beitragsdatum August 4, 2010
2 Kommentare zu Einrichtung einer openQRM Cloud mit KVM auf Ubuntu Lucid Lynx

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.

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

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

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

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

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

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

2. Vorbereiten des Netzwerks

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. Vorbereiten der Datenbank

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

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

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

5. Vorbereiten von KVM

Dafür installieren wir das „kvm“ Package.

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

6. Installation von openQRM

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

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

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

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

Wir wechseln in das src/ Verzeichnis.

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

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

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

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

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

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

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

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

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

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

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

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

7. Konfiguration von openQRM

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

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. Vorbereiten der Server-Images

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

cloud
dhcpd
image-shelf
kvm
lvm-storage
tftpd

Anschließend wechseln wir nach Base >> Components >> Create >> Storage. Dort erstellen wir einen neuen Speicher vom Typ „Lvm Storage Server (NFS)“ 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 „lvm-nfs“ Storage Server.

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

Nun erstellen wir ein neues Volume mit dem Namen „ubuntu64“ und einer Größe von 5000 MB.

Im Anschluss erstellen wir ein weiteres Volume mit dem Namen „debian64“ und einer Größe von 5000 MB.

Nun wechseln wir nach Base >> Components >> Create >> Image und erstellen Images aus den eben erstellten Volumes. Im ersten Schritt wählen wir den Storage Server auf dem die Images physikalisch gespeichert sind.

Anschließend geben wir dem Image einen Namen (in diesem Beispiel „ubuntu64“) und wählen das „ubuntu64“ Volume als das Root-Device.

Dieses wiederholen wir für ein weiteres Image und geben diesem den Namen „debian64“ und wählen das „debian64“ Volume als das Root-Device.

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

Auf der Konsole erhalten wir folgende Ausgabe:

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.

Hier erhalten wir nun eine liste von verfügbaren Server Templates. Wir wählen das „Ubuntu x86_64“ und klicken auf „get“.

Nun wählen wir das Image zu dem die Server Templates hinzugefügt werden sollen. Wir nehmen das „ubuntu64“ Image, dass wir vorhin erstellt haben und klicken „put“.

Image-Shelf verarbeitet nun die Anfrage im Hintergrund. Dabei werden die ausgewählten Server Templates heruntergeladen und auf dem Storage Server entpackt. Der gesamte Vorgang nimmt ein wenig Zeit in Anspruch.

Derselbe Vorgang muss für das „debian64“ Image ebenfalls vorgenommen werden.

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

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

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

9. Erstellen eines KVM Host

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

Wir geben der neuen Appliance einen Namen (in diesem Beispiel „kvm-host“), setzen den „resource-type“ auf „KVM Host“ und speichern.

Die Liste der Appliances sieht nach dem Erstellen der „kvm-host“ Appliance wie folgt aus.

10. Konfiguration der openQRM Cloud

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

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

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

Der folgende Screenshot zeigt die Hauptseite zur Konfiguration der Cloud.

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 „Ubuntu64“ Kernel Produkt.

Diesen Schritt wiederholen wir, um ein „Debian64“ Kernel Produkt zu erstellen.

Im Anschluss erstellen wir ein „KVM VM“ Virtualisierung Produkt.

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 „ubuntu64“ und „debian64“ 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.

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

Als Cloud Administrator kann man sich mit jedem beliebigen Cloud Benutzer anmelden, indem man auf den Namen des Cloud Benutzers klickt.

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.

11. Nutzen der openQRM Cloud

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

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

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

matt@cloud:~$ vncviewer localhost:1

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

Die openQRM Cloud schickt dem Cloud Benutzer automatisch eine E-Mail, in der die IP-Adresse und alle Anmeldeinformationen enthalten sind.

Wir können uns nun anmelden und mit der Cloud Appliance arbeiten.

12. Die nächsten Schritte

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

Quelle

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

Schlagwörter Einrichtung einer openQRM Cloud mit KVM auf Ubuntu Lucid Lynx, featured, openQRM, openQRM Cloud

Services

Die 11 besten Open Source Cloud Computing Projekte 2009

Beitragsautor Von Rene Buest
Beitragsdatum Januar 27, 2010
Keine Kommentare zu Die 11 besten Open Source Cloud Computing Projekte 2009

Auf Basis von John Willis’s Cloud Computing Awards 2009 – „The Cloudies“, hat Mark Hinkle seine Top 11 Open Source Cloud Computing Projekte 2009 ausgewählt. Da ich Open Source und Cloud Computing für unzertrennlich halte, stelle ich die Projekte – Chef, collectd, Eucalyptus, OpenNebula, openQRM, Puppet, RabbitMQ, Zenoss, Bitnami, ECP und Ubuntu Enterprise Cloud jeweils kurz vor.

Chef

Bei Chef handelt es sich um ein Integrations-Framework für das Konfigurationsmanagement aller Arten von IT Infrastrukturen, aber speziell für die Bereitstellung von Cloud Umgebungen. Dazu wird mittels eines Quellcodes beschrieben, wie jeder Teil der Infrastruktur aufgebaut werden soll. Diese Infrastrukturbeschreibung wird anschließend einem Server zugeordnet. Das Ergebnis ist eine voll automatisierte Infrastruktur.

Webseite: http://wiki.opscode.com/display/chef/Home

collectd

collectd ist ein Daemon, der Statistiken der System-Performance sammelt und sie in RRD-Dateien speichert. Der Daemon verfügt über eine Plugin Architektur, die es erlaubt Informationen von einer Vielzahl von Diensten und Servern wie Apache, memcache und Linux-VServer zu sammeln. collectd ist damit die Ideale Erweiterung für bereits vorhandene System Management-Tools.

Webseite: http://collectd.org

Eucalyptus

Eucalyptus steht für „Elastic Utility Computing Architecture Linking Your Programs To Useful Systems“ und dient zum Erstellen einer Cloud Computing Infrastruktur auf Cluster Systeme. Die aktuelle Schnittstelle ist mit den Schnittstellen von Amazon EC2, S3 und EBS kompatible. Die Infrastruktur ist allerdings dafür gedacht, mehrere Client-Schnittstellen unterstützen. Eucalyptus basiert auf gängigen Linux-Tools und grundlegenden Web-Service-Technologien, die eine einfache Installation und Wartung ermöglichen.

Ich habe Eucalyptus bereits vor kurzem ausführlich vorgestellt. Der Artikel kann HIER nachgelesen werden.

Webseite: http://open.eucalyptus.com

OpenNebula

Mit OpenNebula kann jegliche Art von Cloud Umgebung aufgebaut werden. Darüber hinaus können damit virtuelle Infrastrukturen in einem Rechenzentrum oder einem Cluster verwaltet werden, oder eine lokale Infrastruktur mit einer Public Cloud Infratruktur verbunden und kombiniert werden, um damit hoch skalierbare Hosting Umgebungen zu entwickeln. OpenNebula unterstützt ebenfalls Public Clouds, indem Schnittstellen zur Verfügung stehen mit denen virtuelle Machinen, Speichersysteme und das Netzwerk verwaltet werden können.

Webseite: http://www.opennebula.org

openQRM

openQRM ist eine Open Source Lösung zur Verwaltung und dem automatisierten und skalierbaren Betrieb von Rechenzentren- und Cloud-Computing-Plattformen. Die Administration der physikalischen Server und der virtuellen Maschinen erfolgt dabei in einer übergreifenden zentralen Managementkonsole. Mit einer Snapshot-Funktion können Serversysteme dupliziert und Backup/Restore, sowie Server-Versionierung und eine dynamische Anpassung des Speicherplatzes vorgenommen werden.

Webseite: http://www.openqrm.com

Puppet

Puppet ist ein Model-Driven Open Source-Framework für den automatisierten Aufbau und die Konfiguration von Servern. Mit Puppet können administrative Aufgaben wie z.B. das Hinzufügen von Benutzern, die Installation von Software oder die Aktualisierung der Serverkonfiguration auf vielen unterschiedlichen Arten von Systemen vorgenommen werden. Der Clou hierbei ist allerdings, dass immer derselbe Code verwendet werden kann, obgleich die Systeme auf völlig unterschiedlichen Betriebssystemen laufen.

Webseite: http://reductivelabs.com/products/puppet

RabbitMQ

RabbitMQ is ein Enterprise Messaging System welches auf dem AMQP Standard aufsetzt. AMQP ist ein Standard, mit dem Middleware Systeme, untereinander Nachrichten austauschen können.

Webseite: http://www.rabbitmq.com

Zenoss

Zenoss dient zur Überwachung der Amazon Web Services und vielen weiteren Arten von Cloud Computing Umgebungen und virtuellen Infrastrukturen.

Webseite: http://community.zenoss.org/index.jspa

Bitnami

Bitnami vereinfacht die Bereitstellung von Web Anwendungen, sowohl virtuell als auch in einer Cloud. Jeder BitNami Stack beinhaltet eine Anwendung, die mit jeder von ihr benötigten Software so ausgestattet ist um vollständig ausgeführt zu werden. BitNami Stacks sind kostenlos als gewöhnliche Installationsroutinen, virtuelle Machine Images und Cloud Templates erhältlich. Systeme die z.B. BitNami Anwendungen verwenden sind u.a. Drupal, Joomla!, WordPress, SugarCRM, Alfresco, Redmine und Subversion.

Webseite: http://www.bitnami.org

Enomaly’s Elastic Computing Platform (ECP)

ECP ist eine programmierbare virtuelle Cloud Infrastruktur für kleine, mittlere und große Unternehmen. Es unterstützt beim Design, Bereitstellen und Verwalten von virtuellen Anwendungen innerhalb einer Cloud. Weitere Funktionen sind die automatische Skalierung von virtuellen Maschinen, Load Balancing, Systemanalysse, sowie die Konfiguration und Optimierung der Cloud Kapazitäten.

Webseite: http://src.enomaly.com

Ubuntu Enterprise Cloud

Die Ubuntu Enterprise Cloud (UEC) ist in der Ubuntu Server Edition enthalten und beinhaltet eine Vielzahl an Open Source Projekten wie z.B. Eucalyptus. Anwendern steht damit die Möglichkeit offen eine eigene Private Cloud aufzusetzen.

Ein Tutorial zum Einrichten einer eigenen Private Cloud mit der Ubuntu Enterprise Cloud habe ich gestern HIER veröffentlicht.

Webseite: http://www.ubuntu.com/cloud

Quelle

Mark Hinkle
John Willis

Tutorials

Erste Schritte mit der Ubuntu Enterprise Cloud

Beitragsautor Von Rene Buest
Beitragsdatum Januar 26, 2010
3 Kommentare zu Erste Schritte mit der Ubuntu Enterprise Cloud

Das Eucalyptus System kann auf viele unterschiedliche Umgebungen beliebig angepasst werden. Diese Installations-Anleitung zeigt die Einrichtung einer Privat Cloud auf Basis von Eucalyptus mit der Ubuntu Enterprise Cloud.

Ziel dieses Tutorials

Dieses Tutorial beschreibt die Installation, Konfiguration und Registierung, sowie weitere Schritte für die Arbeit mit einer grundlegenden Eucalyptus Einrichtung. Am Ende haben wir eine Cloud mit einem „Front-End“ Controller und einem Knoten, auf dem mehrere Instanzen von Virtual Machines ausgeführt werden können, vollständig eingerichtet. Siehe dazu die Schritte 1 – 3.

In den Schritten 4 – 6 lernen wir die ersten Schritte für die Einrichtung einer Private Cloud und wie diese z.B. mit der RightScale Cloud Management Platform verbunden werden kann.

Schritt 1: Die Voraussetzungen
Schritt 2: Installation & Konfiguration
Schritt 3: Registrierung der Eucalyptus Komponenten
Schritt 4: Erster Login
Schritt 5: Erstellen eines Virtual Machine Image
Schritt 6: Starten eines Images

1. Schritt: Die Voraussetzungen

Das Eucalyptus System hat drei grundlegende Bestandteile:

eucalyptus-cloud: Beinhaltet den Cloud Controller (Front-End Services) und das Walrus Speichersystem.

eucalyptus-cc : Beinhaltet den Cluster Controller der für das virtuelle Netzwerk zuständig ist.

eucalyptus-nc: Beinhaltet den Node Controller zur Verwaltung der einzelnen Knoten, der mit der KVM (Kernel basierende Virtual Machine) kommuniziert und die jeweiligen Virtual Machines verwaltet.

Eine einfache Eucalyptus Umgebung besteht aus zwei Systemen, einem Front-End und einem Node. Das Front-End ist für eucalyptus-cloud und eucalyptus-cc zuständig. In einer komplexeren Umgebung mit mehreren Systemen können/ sollten die oben genannten Teile des Front-Ends voneinander getrennt betrieben werden. Da die Kommunikation vollständig über das Netzwerk erfolgt, ist diese Separierung einfach vorzunehmen.

Das folgende Diagramm zeigt einen einfachen Aufbau einer Eucalyptus Umgebung:

Vor der Installation der Pakete gibt es ein paar Voraussetzungen die erfüllt sein müssen, damit am Ende ein voll funktionsfähiges Eucalyptus System vorhanden ist. Zunächst muss das Front-End in der Lage sein E-Mails zu verschicken. Die Administrations-Tools von Eucalyptus nutzen E-Mails um den Administrator zu benachrichtigen, das er die Anmeldeinformationen von Benutzern prüfen muss. Dazu sollte Postfix installiert werden und als ‚mailhost‘ der ‚localhost‘ eingetragen werden (z.B. als Eintrag in die /etc/hosts).

Auf dem Node auf welchem von Eucalyptus die Virtual Machines ausgeführt werden, muss die erste Netzwerkschnittstelle als Bridge (BR0) konfiguriert werden. Sie dazu (Ubuntu Server Guide Bridging – in Englisch). Dieser Bridge fügt Eucalyptus für jede vorhandene Virtual Machine eine virtuelle Netzwerkschnittstelle (Virtual Network Interfaces) hinzu, bevor die Netzwerkverbindung einer Virtual Machine aktiviert wird.

Des Weiteren benötigt Eucalyptus einen DHCP Server der automatisch IP-Adressen vergibt. Ab dem Zeitpunkt wo die Virtual Machines über die Bridge mit dem lokalen Netzwerk verbunden sind, führen sie ihren lokalen DHCP Client aus, um eine IP-Adresse zu erhalten.

Auf jedem Host der einen Eucalyptus Client nutzt, sollten die Amazon Elastic Compute Cloud (EC2) API und AMI Tools installiert werden. Dafür wird folgendes benötigt:

http://s3.amazonaws.com/ec2-downloads/ec2-api-tools-1.3-30349.zip
http://s3.amazonaws.com/ec2-downloads/ec2-ami-tools-1.3-26357.zip

Damit die ec2-ami-tools einwandfrei funktionieren müssen zusätzlich die Pakete ruby, libopenssl-ruby und curl installiert werden.

Für den Zugriff der EC2-ami-Tools auf die Meta-Daten (wie z.b. EC2-bundle-vol), muss folgender Eintrag vorgenommen werden. Bei der CC_IP handelt es sich um die IP-Adresse des Rechners auf dem Eucalyptus-cc ausgeführt wird.

vi ec2ami/lib/ec2/amitools/instance-data.rb (set META_DATA_URL="http://:8773/latest/meta-data")

Ports: Um auf Eucalyptus auch hinter einer Firewall zugreifen zu können muss der Port 8773 geöffnet werden. Das ist z.B. dann der Fall, wenn sich die EC2- und AMI-Tools sowie die Eucalyptus Cloud auf unterschiedlichen Seiten der Firewall befinden. Wenn das Eucalyptus System mit einer Cloud Management Platform verbunden werden soll, müssen zusätzlich die Ports 8773 und 8443 geöffnet werden.

Schritt 2: Installation & Konfiguration

Zuerst werden die eucalyptus-cloud und eucalyptus-cc Pakete auf der Front-End Machine installiert.

sudo apt-get install eucalyptus-cloud eucalyptus-cc

Anschließend erfolgt die Installation des eucalyptus-nc Pakets auf jedem Node.

sudo apt-get install eucalyptus-nc

Am Ende wird der eucalyptus-nc Service auf dem Node gestoppt und die /etc/eucalyptus/eucalyptus.conf editiert. In der eucalyptus.conf erhält die Bridge den Namen der ersten Netzwerkschnittstelle. Danach wird der eucalyptus-nc Service wieder gestartet.

Die oben beschriebenen Schritte können wie folgt umgesetzt werden:

sudo /etc/init.d/eucalyptus-nc stop sudo vi /etc/eucalyptus/eucalyptus.conf (set VNET_BRIDGE="br0") sudo /etc/init.d/eucalyptus-nc start

Das folgende Diagramm zeigt, wie die Umgebung danach aussehen sollte:

Das Netzwerk sollte außerdem so konfiguriert werden, dass der IPv4 Datenverkehr von den IPv6 Ports weitergeleitet wird, da das Eucalyptus Web-Frontend standardmäßig IPv6 verwendet.

sudo vi /etc/sysctl.conf (uncomment net.ipv4.ip_forward=1) sudo sysctl -p

Schritt 3: Registrierung der Eucalyptus Komponenten

Eucalyptus setzt voraus, das jeder Node innerhalb des Systems zu einem Cluster gehört. Ein Cluster wiederum gehört zu einer Cloud. Auf jedem Node wird eine Kopie von eucalyptus-nc ausgeführt. Genauso muss auf jedem Cluster eine Kopie von eucalytpus-cc ausgeführt werden. In unserem Beispiel wird der eucalytpus-cc auf der selben Maschine ausgeführt wie der Cloud Controller (eucalyptus-clc). Diese Komponenten müssen sich vor dem Start des Systems nun gegenseitig registrieren.

Für die Registrierung eines Cluster wird der folgende Befehl benötigt:

sudo euca_conf -addcluster localhost

Dabei entspricht dem Namen des Clusters, den die Benutzer sehen werden. Es handelt sich dabei um einen reinen logischen Namen, der nur lokal zu Eucalyptus gehört und mit einer Verfügbarkeitszone übereinstimmt, wie sie bei den Client-Tools angezeigt wird.

Um nun einen Node bei einem Cluster zu registrieren, ist der folgende Befehl notwendig.

sudo euca_conf -addnode

Später können weitere Nodes – auf denen eine Kopie von eucalyptus-nc ausgeführt wird – hinzugefügt werden, indem der obige Befehl erneut für jeden Node ausgeführt wird.

Schritt 4: Erster Login

Nach dem ersten Start von Eucalyptus muss die Administrationsumgebung der Cloud eingerichtet werden. Dazu öffnen wir im Webbrowser folgende UR:

https://[front-end-ip-address]:8443

Mit den Standardzugangsdaten Benutzername: admin und Passwort: admin erfolgt die erste Anmeldung, bei der das Passwort geändert werden muss. Nun folgen wir den Anweisungen auf dem Bildschirm. Ist die Konfiguration abgeschlossen klicken wir auf den Reiter credentials und anschließend auf Download Certificate.

Wichtig ist hierbei zu beachten, dass wir eine sichere Verbindung nutzen, also „https“ anstatt „http“. Wir erhalten eine Warnung auf Grund des Sicherheitszertifikats. Dafür müssen wir eine Ausnahme eintragen, um die Seite sehen zu können. Wird für diese Seite keine Ausnahme eingetragen, kann die Konfigurationsseite von Eucalyptus nicht angezeigt werden.

Jetzt müssen wir mittels X.509 Zertifikaten die EC2 API und AMI Tools auf unserem Server wie folgt einrichten.

mkdir ~/.euca cd ~/.euca mv ~/Desktop/euca2-admin-x509.zip ~/.euca unzip euca2-admin-x509.zip

Die Installation kann mittels eines Skripts (ec2toolsinstall.sh) wie folgt durchgeführt werden.

cd ~/.euca # Eucalyptus is not compatible with the newer ec2tools so we will # install and remove them to insure all dependencies get installed sudo apt-get install ec2-api-tools ec2-ami-tools sudo apt-get remove ec2-api-tools ec2-ami-tools wget http://s3.amazonaws.com/ec2-downloads/ec2-api-tools-1.3-30349.zip unzip ec2-api-tools-1.3-30349.zip mv ec2-api-tools-1.3-30349 ec2 wget http://s3.amazonaws.com/ec2-downloads/ec2-ami-tools-1.3-26357.zip unzip ec2-ami-tools-1.3-26357.zip mv ec2-ami-tools-1.3-26357 ec2ami echo 'export JAVA_HOME=/usr' >> eucarc echo 'export EC2_HOME=~/.euca/ec2' >> eucarc echo 'export EC2_AMITOOL_HOME=~/.euca/ec2ami' >> eucarc echo 'export PATH=$PATH:$EC2_HOME/bin:$EC2_AMITOOL_HOME/bin' >> eucarc

Vergabe der Zugriffsrechte:

chmod +x ec2toolsinstall.sh

Das Skript sollte die Datei eucarc erzeugt haben, die noch noch ge-sourced werden muss.

source ~/.euca/eucarc

Optional: Registrierung bei RightScale

RightScale bietet eine Cloud-Management-Plattform für den Einsatz mit Eucalyptus. Diese Cloud Management Software wird als Service innerhalb der Amazon Web Services ausgeführt und muss daher die Möglichkeit haben, mit dem Eucalyptus Cloud Controller (eucalyptus-clc) der hinter einer Firewall steht, zu kommunizieren.

Daher müssen die Ports 8443 und 8773 (Richtung > Internet) geöffnet werden, damit RightScale mit der Eucalyptus Cloud kommunizieren kann.

Um unsere Eucalyptus Cloud bei RightScale zu registrieren, folgen wir den Anweisungen in der unten verlinkten Anleitung:

Registrieren der Eucalyptus Cloud bei RightScale.

Schritt 5: Erstellen eines Virtual Machine Image

Mit dem vmbuilder können wird ein Virtual Machine Image erstellen, das mit Eucalyptus gestartet werden kann.

Zunächst erstellen wir eine Datei mit dem Namen part, in der die Größe, der Typ und der Mountpunkt der Virtual Machine beschrieben ist:

root 400 /mnt/ephemeral 0 /dev/sda2 swap 1 /dev/sda3

Anschließend erstellen wir eine Skriptdatei mit dem Namen firstboot. Dieses Skript wird ausgeführt wenn das Image das erste Mal in Eucalyptus gestartet wird und installiert dabei einen SSH Daemon.

apt-get -y install openssh-server

Nun erstellen wir ein Image mit dem vmbuilder und übergeben beim Aufruf die beiden Skripte als Parameter.

sudo vmbuilder xen ubuntu --part ./part --firstboot ./firstboot

Mit Hilfe der EC2 API Tools packen und registrieren wir abschließend den Kernel, die Ramdisk und das Image.

mkdir kernel ec2-bundle-image -i /boot/vmlinuz-2.6.28-11-generic -d ./kernel --kernel true ec2-upload-bundle -b kernel -m ./kernel/vmlinuz-2.6.28-11-generic.manifest.xml EKI=`ec2-register kernel/vmlinuz-2.6.28-11-generic.manifest.xml | awk '{print $2}'` echo $EKI

mkdir ramdisk ec2-bundle-image -i /boot/initrd.img-2.6.28-11-generic -d ./ramdisk --ramdisk true ec2-upload-bundle -b ramdisk -m ramdisk/initrd.img-2.6.28-11-generic.manifest.xml ERI=`ec2-register ramdisk/initrd.img-2.6.28-11-generic.manifest.xml | awk '{print $2}'` echo $ERI

mkdir image ec2-bundle-image -i ubuntu-xen/root.img -d ./image --kernel $EKI --ramdisk $ERI ec2-upload-bundle -b image -m ./image/root.img.manifest.xml EMI=`ec2-register image/root.img.manifest.xml | awk '{print $2}'` echo $EMI

Der Kernel, die Ramdisk und das Image sind nun in der Eucalyptus Cloud und können dort genutzt werden.

Zur Bestätigung geben wir folgenden Befehl ein:

ec2-describe-images

Die Ausgabe sollte nun einen registrierten Kernel, Ramdisk und Image anzeigen, die als „available“ gekennzeichnet sind.

Schritt 6: Starten eines Images

Bevor eine Instanz eines Image gestartet wird, müssen wir ein Schlüsselpaar (SSH Key) erstellen um uns nach dem Start als Root anmelden zu können. Der Schlüssel wird gespeichert, daher muss dieser Schritt nur einmal durchgeführt werden.

ec2-add-keypair mykey > ~/.euca/mykey.priv chmod 0600 ~/.euca/mykey.priv

Falls wir unseren Key mal vergessen sollten, können wir uns mittels ec2-describe-keypairs eine Liste aller erstellten und auf dem System gespeicherten Schlüssel anzeigen lassen.

Nun können wir Instanzen von unserem registrierten Image wie folgt erstellen.

ec2-run-instances $EMI -k mykey

Während des ersten Starts einer Instanz erstellt das System einen Cache für das Image aus welchem die Instanz erstellt wird. Da die Images in der Regel sehr groß sind, kann dieser Vorgang etwas dauern.

Der aktuelle Status der Instanz kann mit folgendem Befehl abgefragt werden.

ec2-describe-instances

Die Ausgabe zeigt die aktuellen Informationen und den Status der Instanz. Während des ersten Starts sollte sich die Instanz im Status „pending“ befinden. Ist die Instanz gestartet, sollte der Status auf „running“ wechseln. Nachdem die Instanz über DHCP eine IP-Adresse erhalten hat können wir uns mittels des oben generierten SSH Keys mit der Instanz verbinden.

ssh -i ~/.euca/mykey.priv root@

Die Umgebung der Eucalyptus Cloud sollte nun diesem Diagramm entsprechen.

Weitere Informationen

Log Dateien: /var/log/eucalyptus
Konfigurationsdateien: /etc/eucalyptus
Init Skripte: /etc/init.d/eucalyptus-cc, /etc/init.d/eucalytpus-cloud und /etc/init.d/eucalytpus-nc
Datenbank: /var/lib/eucalyptus/db
Neustart (Anmerkung): Bei einem Neustart wird Eucalyptus nicht automatisch neu gestartet. Die Services müssen daher manuell geladen werden.
Umgebung (Anmerkung): Bevor der Client gestartet wird, sollten die Quellen unter ~/.euca/eucarc ge-sourced werden.

Quellen

Eucalyptus-Jaunty

Schlagwörter Cloud, Cloud Computing, Cluster, Cluster Computing, Eucalyptus, featured, Grid Computing, IaaS, Infrastructure, Infrastructure as a Service, Private Cloud, Public Cloud, Rechenzentrum, Technology, Ubuntu, Ubuntu Enterprise Cloud