Categories
Kommentar

Die eigene Cloud bauen mit… – CloudWashing par excellence!

“Die eigene Cloud bauen mit xyz…” Als ich diese Überschrift gelesen habe, bin ich fast aus allen Wolken gefallen! In dem Artikel werden zwei Produkte vorgestellt, mit denen man seine “eigene Cloud” aufbauen kann.

Kurz gesagt: Den Leuten wird damit suggeriert, eine Private Cloud im Wohnzimmer aufbauen zu können. Gut, meine Frage ist aber nun, wie die Skalierbarkeit, Hochverfügbarkeit usw. gewährleistet wird?

Nehmen wir ein einfaches Beispiel. Ein Anwender hört vom Thema Cloud Computing. Sehr sicher, da die Daten durch die Cloud hochverfügbar sind. Jede Menge Speicherplatz, weil die Cloud skalierbar ist usw. Der Nutzer lädt sich also die in dem Artikel besagte Software herunter, installiert und konfiguriert diese und speichert seine möglicherweise wichtigen Daten darauf ab.

Szenario 1: Der Nutzer merkt nach einiger Zeit, dass nicht mehr ausreichend Speicherplatz vorhanden ist. Nutzer: “Cloud Computing ist ja echt xxx! Ich dachte das wäre skalierbar?!” Ja, aber dafür wird auch demensprechend Speicherplatz in Form von Hardware, also Festplatten benötigt.

Szenario 2: Der Nutzer merkt nach einer Weile, das Daten verschwinden und plötzlich ist kein Zugriff auf die “Cloud” mehr möglich. Nutzer: “Cloud Computing ist echt xxx! Ich dachte die Cloud ist hochverfügbar?!” Ja, ist sie auch. Aber dafür benötige ich mehr als nur ein System und das im besten Fall, an unterschiedlichen Standorten, verteilt.

Wir sehen also, dass es nicht ohne weiteres möglich ist, sich eine Private Cloud im eigenen Wohnzimmer aufzubauen! Genauso verhält es sich, wenn die Software bzw. “Private Cloud” auf einem(!) Server bei einem Webhoster genutzt werden soll. Ein Server reicht da nun einmal nicht aus. Aber leider unterstützen Softwarelösungen wie BDrive und ownCloud diese Problematik, indem sie CloudWashing betreiben und suggerieren, dass jeder seine eigene Cloud betreiben kann.

Aber so einfach scheint es dann auch wieder nicht zu sein:

Owncloud installieren
Suche Unterstützung bei der Installation von owncloud (owncloud.org/).
1blu Server vorhanden und so weit eingerichtet, allerdings komme ich an der Fehlermeldung “MDB2_Schema Error: schema parse error: Parser error: File could not be opened. – Unknown” nicht weiter!
Bitte nur Festpreis Angebote.
Bitte nur anbieten wenn Erfahrung mit owncloud vorhanden ist.

siehe: http://www.twago.de/project/Owncloud-installieren/8670

Da wundern mich auch solche Anfragen nicht, die ich öfters per Facebook bekomme:

Hey, sag mal du bist doch hier der Cloud experte. Ich möchte meine eigene Homecloud einrichten. Es sollte so einfach sein wie dropbox nur das mein Storage zu Hause auf einem Windows Home Server liegt. Nun bin ich auf der Suche nach einer App fürs iphone, einem Programm für Windows OS und vielleicht für windows mobile 6.5. Hast du eine idee oder einen vorschlag wie sowas realisierbar ist? Dropbox ist zwar schon super aber ich hab es gern wenn meine Daten bei mir zu Hause bleiben. Server ist eh immer an.

Cloud ist ja ein weiter Begriff und ich denke wenn ich von überall von jedem System auf meine Daten zugreifen möchte die zu Hause auf meinem Storage abgelegt sind und sicher aufbewahrt nennt sich das Cloud oder?
Dropbox ist ja schon nahezu perfekt, allerdings liegen dabei meine Gesamten Daten bei einem Provider im Netz. Da ist die wahrscheinlichkeit höher das der mal angegriffen wird als mein Home Server…
Darum möchte ich keine Daten online Stellen bei einem Dienstleister.
Ich habe letztens den Begriff Owncloud zugeworfen bekommen. Sagt dir das was?

Bitte, Finger weg von BDrive oder ownCloud, wenn man eine CLOUD bauen möchte. Damit kann mit einfachen Mitteln keine eigene Private Cloud aufgebaut werden!

Wenn jemand wirklich eine Cloud aufbauen möchte, sollte er sich lieber, openQRM, Eucalyptus bzw. die Ubuntu Enterprise Cloud anschauen und dabei bitte einen Blick auf die Voraussetzungen bzw. die notwendigen Topologien werfen.

Update: Mittlerweile gibt es auch einen Artikel über professionelle Open-Source Lösungen für die eigene Cloud.


Bildquelle: http://www.hightechdad.com

Categories
Tutorials @de

Ubuntu Enterprise Cloud Topologien

Eine Ubuntu Enterprise Cloud kann aus zwei, bzw. bis zu hunderten oder sogar tausenden physikalischen bestehen. Es ist daher wichtig, die möglichen Topologien zu verstehen, die auf Basis der vorhandenen physikalischen Maschinen aufzubauen sind.

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

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

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

Beispiel Konfiguration (für ein bestehendes LAN)

Netzwerk Konfiguration:

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

auto br0
iface br0 inet static
    address 192.168.1.4
    netmask 255.255.255.0
    network 192.168.1.0
    broadcast 192.168.1.255
    gateway 192.168.1.2
    # dns-* options are implemented by the resolvconf package, if installed
    # these are google's dns servers
    dns-nameservers 8.8.8.8 8.8.4.4
    # this setting could be "local" if you all your local hosts
    #  were named something like a.localdomain b.localdomain c.localdomain etc
    dns-search localdomain
    bridge_ports eth0
    bridge_fd 9
    bridge_hello 2
    bridge_maxage 12
    bridge_stp off
  • /etc/eucalyptus/eucalyptus.conf – wichtige Einträge:
VNET_PUBINTERFACE="br0" # must match the br definition above
VNET_PRIVINTERFACE="br0" # must match the br definition above
VNET_MODE="MANAGED-NOVLAN"
VNET_SUBNET="172.19.0.0" # ips from this range are bound to $VNET_PRIVINTERFACE:priv
VNET_NETMASK="255.255.0.0"
VNET_DNS="192.168.1.2" # what DNS server nodes are given
# v - should be ips on the LAN, not in use anywhere, and excluded from the DHCP server
VNET_PUBLICIPS="192.168.1.100-192.168.1.110"

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

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

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

Mindestens 2 physikalische Systeme

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

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

Mindestens 3 physikalische Systeme

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

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

Mindestens 4 physikalische Systeme

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

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

Mindestens 5 physikalische Systeme

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

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

Quelle: UECTopologies

Categories
News

openQRM integriert Ubuntu Enterprise Cloud, Amazon EC2 und Eucalyptus

Gesponsert durch die openQRM Enterprise, veröffentlicht das openQRM project ein neues Plugin, das Hybrid Cloud Computing ermöglicht.

Mit dem Plugin erhalten openQRM Nutzer nun die Möglichkeit, ihre selbst verwalteten Systeme transparent und vollautomatisiert zwischen Private und Public Clouds zu migrieren. Das Importieren bereits vorhandener Cloud Instanzen aus der Ubuntu Enterprise Cloud (UEC), Amazon EC2 oder Eucalyptus kann damit ohne großen Aufwand erfolgen. Dasselbe gilt ebenso für den Export der Systeme aus der openQRM Cloud heraus. Cloud Transparenz! Über die graphische Web Oberfläche können alle dafür benötigten Schritte der Migration durchgeführt werden. Damit können dem eigenen Rechenzentrum nach Bedarf externe Ressourcen von Public Cloud Anbietern hinzugefügt werden.

Durch die Nutzung einer agilen Privat zu Public oder Public zu Private Migration, kann damit kontrolliert werden, welche Daten und Dienste in einem sicheren Bereich bereitgestellt werden sollen. Somit können sensible Systeme innerhalb des eigenen Rechenzentrums betrieben und alle weiteren ressourcenintensiven Systeme zu Cloud Anbietern verlagert werden.

Ein Überblick über die neuen Funktionen zeigt das Video am Ende dieses Artikels.

Für alle die einen tieferen Einblick in eine Hybrid Cloud Lösung haben möchten, stellt openQRM Enterprise ein detailliert beschriebenes How to auf ihren Webseiten zur Verfügung. Dieses kann hier heruntergeladen werden.

Das Plugin steht bereits auf der Seite des openQRM project unter http://sourceforge.net/projects/openqrm zum Download bereit.

Categories
Tutorials @de

Der Ubuntu VM-Builder

Der Ubuntu VM-Builder kann dafür genutzt werden um eine benutzerdefinierte Virtuelle Maschinen zu erstellen. Es lassen sich damit schnell und automatisiert Testumgebungen aufsetzen. Softwareentwickler haben zudem die Möglichkeit, die Erstellung der Virtuellen Maschine in den Build Prozess ihrer Anwendung zu integrieren.

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

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

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

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

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

Der allgemeine Befehl lautet:

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

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

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

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

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

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

Der ubuntu-vm-builder in Verbindung mit libvirt

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

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

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

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

virsh -c qemu:///system start ubuntu

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

Quelle

  • ubuntu-vm-builder
Categories
Tutorials @de

UEC: Zusammenstellen von Images für Ubuntu 9.10

Dieser Artikel beschreibt das Vorgehen (Bundling) für das Erstellen und die Registrierung von VM Images mit dem UEC Cloud Controller für Ubuntu 9.10. Dazu benötigen wir ein Image, dass von den Daily Builds heruntergeladen werden kann, verknüpfen alles miteinander und laden es in unsere Ubuntu Cloud.

1. Um den Vorgang von der Kommandozeile aus zu starten nutzen wird die folgenden Befehle. Hierbei wird automatisch ein UEC Image heruntergeladen.

TIMESTAMP=$(date +%Y%m%d%H%M%S)
RELEASE=karmic
ARCH=amd64 # Or this might be i386
[ $ARCH = "amd64" ] && IARCH=x86_64 || IARCH=i386
UEC_IMG=$RELEASE-server-uec-$ARCH
URL=http://uec-images.ubuntu.com/$RELEASE/current/
[ ! -e $UEC_IMG.tar.gz ] && wget $URL/$UEC_IMG.tar.gz # This may take a bit, depending on your connectivity

2. Als nächstes muss alles verpackt, hochgeladen und registriert werden. In dem Package cloud-utils befindet sich das Tool uec-publish-tarball. Mit diesem können die oben genannten Aktionen in einem Schritt durchgeführt werden. Weiterhin ist in den cloud-utils das Tool uec-publish-image vorhanden. Mit diesem kann direkt mit einem ungepackten Image gearbeitet werden.

uec-publish-tarball ${UEC_IMG}.tar.gz "${RELEASE}-${TIMESTAMP}" "${ARCH}"

Diese Schritte sind nur dann notwendig, wenn nicht das Tool uec-publish-tarball verwendet wird!

1. Entpacken des UEC Image Tarball

[ ! -e $UEC_IMG.img ] && tar -S -xzf $UEC_IMG.tar.gz

2. Zusammenstellen des Kernels

BUCKET_KERNEL="k-$TIMESTAMP"
UEC_KERNEL=$UEC_IMG-vmlinuz-virtual
euca-bundle-image -i $UEC_KERNEL -r $IARCH --kernel true
euca-upload-bundle -b $BUCKET_KERNEL -m /tmp/$UEC_KERNEL.manifest.xml
EKI=$(euca-register $BUCKET_KERNEL/$UEC_KERNEL.manifest.xml | grep "^IMAGE" | awk '{print $2}') && echo $EKI

3. Zusammenstellen der initrd (Wird nur benötigt, wenn keine Ramdisk vorhanden ist)

BUCKET_INITRD="r-$TIMESTAMP"
UEC_INITRD=$UEC_IMG-initrd-virtual
euca-bundle-image -i $UEC_INITRD -r $IARCH --ramdisk true
euca-upload-bundle -b $BUCKET_INITRD -m /tmp/$UEC_INITRD.manifest.xml
ERI=$(euca-register $BUCKET_INITRD/$UEC_INITRD.manifest.xml | grep "^IMAGE" | awk '{print $2}') && echo $ERI

4. Zusammenstellen des Images

BUCKET_IMAGE="i-$TIMESTAMP"
UEC_IMG=$RELEASE-server-uec-$ARCH
euca-bundle-image -i $UEC_IMG.img -r $IARCH --kernel $EKI ${ERI:+--ramdisk ${ERI}} # This will take a long time (~10m)
euca-upload-bundle -b $BUCKET_IMAGE -m /tmp/$UEC_IMG.img.manifest.xml
EMI=$(euca-register $BUCKET_IMAGE/$UEC_IMG.img.manifest.xml | grep "^IMAGE" | awk '{print $2}') && echo $EMI

3. Damit ist der Kernel und das Image in unsere Ubuntu Cloud (Eucalyptus) hochgeladen worden und kann nun genutzt werden.

euca-describe-images

Wir sollten einen registrierten Kernel sowie ein Image sehen, die als “available” markiert sind.

Mit dem anschließenden Befehl können wir das überprüfen.

Quelle

Categories
Tutorials @de

UEC: Zusammenstellen von Images für Ubuntu 10.04

Dieser Artikel beschreibt das Vorgehen (Bundling) für das Erstellen und die Registrierung von VM Images mit dem UEC Cloud Controller für Ubuntu 10.04 LTS. Dazu benötigen wir ein Image, dass von den Daily Builds heruntergeladen werden kann, verknüpfen alles miteinander und laden es in unsere Ubuntu Cloud.

Um den Vorgang von der Kommandozeile aus zu starten nutzen wird die folgenden Befehle. Hierbei wird automatisch ein UEC Image heruntergeladen und bereitgestellt.

TIMESTAMP=$(date +%Y%m%d%H%M%S)
RELEASE=lucid
ARCH=amd64 # Or this might be i386
[ $ARCH = "amd64" ] && IARCH=x86_64 || IARCH=i386
UEC_IMG=$RELEASE-server-uec-$ARCH
URL=http://uec-images.ubuntu.com/$RELEASE/current/
[ ! -e $UEC_IMG.tar.gz ] && wget $URL/$UEC_IMG.tar.gz
uec-publish-tarball $UEC_IMG.tar.gz $RELEASE-$TIMESTAMP

Damit ist der Kernel und das Image in unsere Ubuntu Cloud (Eucalyptus) hochgeladen worden und kann nun genutzt werden.

Mit dem anschließenden Befehl können wir das überprüfen.

euca-describe-images

Wir sollten einen registrierten Kernel sowie ein Image sehen, die als “available” markiert sind.

Quelle

Categories
Tutorials @de

UEC: Erstellen eines eigenen Image

Dieses Tutorial beschreibt das Erstellen von Images für die Ubuntu Enterprise Cloud mit Hilfe des vmbuilder utility. Dieses Image ist generisch und kann für jede Eucalyptus Cloud genutzt werden.

Zunächst erstellen wir eine Beschreibung zu einer Partition, hier mit dem Namen “part”. Diese beinhaltet die Größe, den Typ sowie den Mountpoint der Partition unserer VM.

$ cat > part <

Im nächsten Schritt wird ein einfaches Skript mit dem Namen "firstboot" (entspricht ebenfalls dem Dateinamen) erstellt. Dieses wird das erste Mal ausgeführt, wenn das Image innerhalb von Eucalyptus gestartet wird um einen SSH Daemon zu installieren.

$ cat >firstboot <

Nun kann mit dem vmbuilder das Image erstellt werden. Dazu wird als Parameter das vorher erstellte Skript "firstboot" mit übergeben.

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

Als nächstes müssen wir einen Kernel, eine Ramdisk und natürlich das Image "bundlen", registieren und hochladen. Dazu verwenden wir die EC2 API Tools.

mkdir kernel
euca-bundle-image --image /boot/vmlinuz-$(uname -r)
--destination ./kernel --kernel true
euca-upload-bundle --bucket kernel
--manifest ./kernel/vmlinuz-$(uname -r).manifest.xml
EKI=`euca-register kernel/vmlinuz-$(uname -r).manifest.xml | awk '{print $2}'`
echo $EKI

mkdir ramdisk
sudo sh -c 'grep -q acpiphp /etc/initramfs-tools/modules ||
printf "#acpiphp needed for ebsnacpiphpn" > /etc/initramfs-tools/modules'
sudo mkinitramfs -o ./ramdisk/initrd.img-$(uname -r)
euca-bundle-image --image ./ramdisk/initrd.img-$(uname -r)
--destination ./ramdisk --ramdisk true
euca-upload-bundle --bucket ramdisk
--manifest ramdisk/initrd.img-$(uname -r).manifest.xml
ERI=`euca-register ramdisk/initrd.img-$(uname -r).manifest.xml | awk '{print $2}'`
echo $ERI

mkdir image
euca-bundle-image --image ubuntu-xen/root.img
--destination ./image --kernel $EKI --ramdisk $ERI
euca-upload-bundle --bucket image --manifest ./image/root.img.manifest.xml
EMI=`euca-register image/root.img.manifest.xml | awk '{print $2}'`
echo $EMI

Die Shell Variablen in dem obigen Code Beispiel werden dazu benötigt, um die anschließende Instalaltion zu testen. Nun sollte der Kernel, die Ramdisk und das Image in Eucalyptus hochgeladen worden und betriebsbereit sein. Um das zu überprüfen nutzen wir den folgenden Befehl.

euca-describe-images

Wir sollten einen registierten Kernel, eine Ramdisk und das Image sehen, wobei alle als "available" gekennzeichnet sind.

Quelle

Categories
Tutorials @de

UEC: Einsatz des Storage Controller

Dieser Artikel beschreibt, wie die Funktionen des Eucalyptus Storage Controller (SC) innerhalb der Ubuntu Enterprise Cloud (UEC) verwendet werden kann. Der Storage Controller ist vergleichbar mit den Amazon Elastic Block Storage (EBS). Mit diesem können Block Devices wie z.B. virtuelle Festplatten von virtuellen Maschinen (Images) gemounted werden. Die Daten werden dabei außerhalb der virtuellen Maschine (VM) gespeichert und sind dabei unabhängig von dem aktuellen Status dieser VM. Das bedeutet, dass die Daten weiterhin persitent gespeichert beliben, auch wenn die virtuelle Maschine beendet wird.

Wurde die Ubuntu Enterprise Cloud mit einer CD installiert und existiert eine separate physikalische Netzwerkschnittstelle, mit der das Front-End mit den Eucalyptus Node Controllers (NCs) verbunden wird, muss sichergestellt sein, dass der Storage Controller das Private Network Interface verwendet.

Mit Hilfe der Weboberfläche kann diese Konfiguration unter Configuration -> Clusters -> Storage Controller vorgenommen werden. Dabei muss darauf geachtet werden, dass die IP-Adresse welche unter Host eingetragen ist zu dem private Interface gehört und das es sich bei diesem Interface auch um das physikalische Interface zu dem privaten Netzwerk handelt.

Für die Konfiguration mittels der Kommandozeile werden die folgenden Befehle verwendet.

sudo euca_conf --deregister-sc

sudo euca_conf --register-sc

Wichtig! Alle Volumes die vor der Ausführung des obigen Befehls erstellt wurden, werden anschließend nicht mehr funktionieren und sollten mit nachfolgendem Befehl entfernt werden.

Arbeiten mit dem Storage Controller

Das Erstellen von Volumes

Zum Erstellen eines Eucalyptus Storage Controller Volumes nutzen wir den Befehl

euca-create-volume -s 1 -z myzone

Dabei entspricht -s die Größe in GB und -z den Namen der UEC Verfügbarkeitszone.

Mit dem Befehl

euca-describe-availability-zones

wird der Name des UEC Storage Controller Volumes ausgegeben.

VOLUME vol-xxxxxxxx

Das Benutzen von Volumes

Um ein Volume einer bereits gestarteten Instanz hinzuzufügen nutzen wir den Befehl

euca-attach-volume -i i-xxxxxxxx -d /dev/sdb vol-xxxxxxxx

Wobei -i den Identifier der Instanz und -d dem Namen des Endgerätes entspricht, dass dem Storage Controller Volume zugewiesen werden soll.

Mit dem Befehl

euca-describe-volumes

erhalten wir detaillierte Informationen zu den gemounteten Volumes.

VOLUME vol-xxxxxxxx 1 myzone in-use 2009-10-23T14:41:47.375Z
ATTACHMENT vol-xxxxxxxx i-xxxxxxxx /dev/sdb 2009-10-23T14:42:10.274Z

Anschließend sollte das hinzugefügte Endgerät im Verzeichnis /dev der Instanz vorhanden sein. Anschließend sollten wir in der Lage sein mittels

sudo fdisk /dev/sdb

mit dem Volume zu arbeiten. Dieses also zu partitionieren, formatieren, zu mounten und das Volume so zu nutzen, als wäre es wie ein physikalisches Endgerät vorhanden und an unserer Instanz angeschlossen.

Quelle

Categories
Grundlagen

Ubuntu Enterprise Cloud Terminologie

Bei dem Einsatz der Ubuntu Enterprise Cloud (UEC) wird eine eigene Terminologie verwendet, die für das Verständnis und dem Umgang doch wichtig ist. Dieses Glossar fasst alle notwendigen Begriffe und ihre Bedeutung zusammen.

Cloud
Ein Verbund von physikalischen Maschinen, die mit Hilfe von virtuellen Maschinen Rechnerressourcen dynamisch bereitstellen und “wieder einsammeln”.

Cloud Controller (CLC)
Komponente von Eucalyptus die eine Weboberfläche (HTTPS Server auf Port 8443) bereitstellt und die Amazon EC2 API implementiert. Es sollte maximal einen Cloud Controller für eine UEC Installation geben. Der CLC wird durch das Ubuntu Package eucalyptus-cloud zur Verfügung gestellt.

Cluster
Ein Verbund von Nodes, die einem Cluster Controller zugeordnet sind. Dabei kann es mehr als einen Cluster in einer UEC Installation geben. Cluster bestehen in einigen Fällen aus physikalisch räumlich voneinander getrennten Nodes.

Cluster Controller (CC)
Eine Eucalyptus Komponente die für die Verwaltung der Node Ressourcen zuständig ist. Der CC wird durch das Ubuntu Package eucalyptus-cc zur Verfügung gestellt.

EBS
Elastic Block Storage

EC2 – Elastic Compute Cloud
Amazons Public Cloud Computing Angebot auf Basis von virtuellen Servern, bei dem die Abrechnung pro Stunde bzw. pro Gigabyte erfolgt.

EKI
Eucalyptus Kernel Image

EMI
Eucalyptus Machine Image

ERI
Eucalyptus Ramdisk Image

Eucalyptus
Elastic Utility Computing Architecture for Linking Your Programs To Useful Systems.
Bei Eucalyptus handelt es sich um ein Open Source Projekt, welches ursprüglich an der University of California in Santa Barbara entwickelt wurde und mittlerweile durch Eucalyptus Systems unterstützt wird.

Front-end
Ein oder mehrere physikalische Server, auf denen die Eucalytpus Komponenten (cloud, walrus, storage controller, cluster controller) ausgeführt werden.

Node
Bei einem Node handelt es sich um eine phyiskalische Maschine, die in der Lage ist virtuelle Maschinen und einen Node Controller auszuführen. Innerhalb von Ubuntu bedeutet dies, dass eine CPU die VT Erweiterung unterstützt und den KVM Hypervisor ausführen kann.

Node Controller (NC)
Eine Eucalyptus Komponente die auf den Nodes ausgeführt wird, welche die virtuellen Maschinen beherbergen die wiederum der Cloud zugeordnet sind. Der NC wird durch das Ubuntu Package eucalyptus-nc zur Verfügung gestellt.

S3 – Simple Storage Service
Amazons Public Cloud Computing Angebot für das Speichern der EC2- und anderer Daten, bei dem die Abrechnung pro Gigabyte erfolgt.

Storage Controller (SC)
Eine Eucalyptus Komponente die zur Verwaltung des dynamic block storage services (EBS) dient. Jeder Cluster innerhalb einer Eucalyptus Installation kann seinen eigenen Storage Controller besitzen. Der SC wird durch das Ubuntu Package eucalyptus-sc zur Verfügung gestellt.

UEC
Ubuntu Enterprise Cloud
Ubuntu’s Cloud Computing Lösung auf der Basis von Eucalyptus.

VM
Virtual Machine

VT
Virtualization Technology
Moderne CPUs unterstützen diese Funktion, um die Arbeit (das Hosting) mit den virtuellen Maschinen zu beschleunigen.

Walrus
Eine Eucalyptus Komponente welche die Amazon S3 API implementiert und dafür benötigt wird, die Images der virtuellen Maschinen, sowie die Daten der Benutzer in S3 Buckets mittels put/get zu speichern.

Categories
Services @de

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