Tag: UEC

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
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: 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.