Dieses Tutorial beschreibt wie ein offizielles Amazon EC2 Image mit dem VMBuilder deployed wird.
Für alle Ubuntu Versionen ab Karmic Koala (9.10) sind fertige Pakete vorhanden.
Dieses Tutorial beschreibt, wie man den Amazon S3 Webservice zusammen mit einer eigenen (Sub)-Domain nutzen kann. Also im Prinzip durch das verwenden einer eigenen Subdomain die Nutzung von Amazon S3 verschleiert.
Immer wenn eine Datei zu Amazon S3 hochgeladen wird, bekommen wir eine URL, um Zugriff auf diese zu erhalten. Dabei werden zwei unterschiedliche Schreibweisen verwendet, die wie folgt aussehen:
und
Wie man erkennt, wird der Name des Buckets im ersten Beispiel als Teil des Dateipfads genutzt, im zweiten Beispiel als Teil des Domain Namen. Diese beiden URLs sind identisch und verweisen auf dieselbe Datei.
Um nun eine Subdomain so zu konfigurieren, dass diese auf Amazon S3 verweist, muss zunächst ein Bucket mit exakt dem Namen der Subdomain erstellt werden. Wollen wir z.B. eine Subdomain mit dem Namen http://Meine-S3-Dateien.clouduser.de auf Amazon S3 verweisen lassen, erstellen wir einen Bucket mit exakt dem Namen Meine-S3-Dateien.clouduser.de.
Also nochmal zusammengefasst:
Als nächstes muss bei unserem Web Hoster das DNS konfiguriert werden. Dazu legen wir einen neuen CNAME an, der auf Amazon S3 verweist.
Das sieht dann wie folgt aus:
Die Art wie ein CNAME erstellt wird, ist von Anbieter zu Anbieter unterschiedlich.
Wenn die Konfiguration abgeschlossen wurde, kann auf alle Dateien unter http://Meine-S3-Dateien.clouduser.de mittels http://Meine-S3-Dateien.clouduser.de/dateiname.ext zugegriffen werden.
Es können natürlich beliebig viele Subdomains für Amazon S3 nach dem oben beschriebenen Schema angelegt werden.
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
Ein Cluster Node ist mit einem oder mehreren Netzwerken verbunden, mit denen die virtuellen Maschinen mittels der entsprechenden Brigdes kommunizieren. Für den Aufbau eines virtuellen Netzwerks wird lediglich der Name der Brigde benötigt, um mit den virtuellen Maschinen eine Verbindung herzustellen.
Dieser Artikel beschreibt, wie virtuelle Netzwerke innerhalb von OpenNebula erstellt und genutzt werden können. Die folgenden Beispiele gehen dabei davon aus, dass die Cluster Nodes mit zwei physikalischen Netzwerken verbunden sind. Folgende Konstellation besteht:
OpenNebula ermöglicht die Erstellung von virtuellen Netzwerken, indem diese auf die physikalischen aufgesetzt und mit ihnen verbunden werden. Alle virtuellen Netzwerke teilen sich einen Standardwert für die MAC-Präfix, welcher in der Datei oned.conf konfiguriert wird.
In OpenNebula existieren zwei Arten von virtuellen Netzwerken:
Virtuelle Netzwerke die von dem Benutzer oneadmin erstellt wurden, können von jedem anderen Benutzer ebenfalls verwendet werden.
Ein statisches Netzwerk besteht aus einem Satz von IP-Adressen, die MAC Adressen zugeordnet sind. Dieses geschieht in einer gewöhnlichen Textdatei.
Für die Definition eines statischen Netzwerks werden die vier folgenden Informationen benötigt:
Um ein statisches virtuelles Netzwerk mit dem Namen „Public“ und den öffentlichen IP Adressen für die virtuellen Maschinen zu erstellen reicht der Inhalt der folgenden Datei.
NAME = "Public"
TYPE = FIXED
#Auf Grund der Internetverbindung muss das Netzwerk an "virdr1" gebunden werden.
BRIDGE = vbr1
LEASES = [IP=130.10.0.1, MAC=50:20:20:20:20:20]
LEASES = [IP=130.10.0.2, MAC=50:20:20:20:20:21]
LEASES = [IP=130.10.0.3]
LEASES = [IP=130.10.0.4]
Diese Art von virtuellen Netzwerk benötigt u.a. einen festgelegten IP-Adressblock und weitere folgende Informationen:
Das folgende Beispiel zeigt die Definition eines solchen Netzwerktyps.
NAME = "Red LAN"
TYPE = RANGED
# Hier nutzen wir das physikalische private Netzwerk des Cluster
BRIDGE = vbr0
NETWORK_SIZE = C
NETWORK_ADDRESS = 192.168.0.0
Die Standardwerte für die NETWORK_SIZE können der oned.conf entnommen werden.
Sobald ein Template für ein virtuelles Netzwerk definiert wurde, kann der onevnet Befehl genutzt werden um dieses zu erstellen.
Um die beiden oben genannten Netzwerke zu erstellen fügen wir die jeweiligen Definitionen in die zwei unterschiedliche Dateien mit den Namen public.net und red.net und führen folgenden Befehl aus.
$ onevnet -v create public.net
$ onevnet -v create red.net
Mittels onevnet kann innerhalb von OpenNebula ebenfalls nach verfügbaren virtuellen Netzwerken gesucht werden.
$ onevnet list
NID USER NAME TYPE BRIDGE #LEASES
2 oneadmin Public Fixed vbr1 0
3 oneadmin Red LAN Ranged vbr0 0
Dabei steht USER für den Eigentümer des Netzwerks und #LEASES für die Anzahl von IP-MAC Adressen die einer virtuellen Maschine aus diesem Netzwerk zugwiesen sind.
Um eine virtuelles Netzwerk zu entfernen wird der Befehl onevnet delete verwendet. Um die oben genannten Netzwerke zu löschen verwenden wir:
$onevnet delete 2
$onevnet delete 'Red LAN'
Mittels onevnet show können die vergebenen IP-Adressen innerhalb eines Netzwerks angezeigt werden.
Das Leasing einer virtuellen Maschine aus einem virtuellen Netzwerk wird vorgenommen, indem der Name des virtuellen Netzwerks für das Attribute NIC angegeben wird.
Um ein virtuelle Maschine mit zwei Netzwerkschnittstellen zu definieren, bei der eine Schnittstelle mit Red LAN und die andere mit Public verbunden ist muss das Template um folgenden Eintrag erweitert werden.
NIC=[NETWORK="Public"]
NIC=[NETWORK="Red LAN"]
Es kann ebenfalls eine bestimmte Adresse angefragt werden, indem zusätzlich die IP oder MAC-Adresse dem Attribute hinzugefügt wird.
NIC=[NETWORK="Red LAN", IP=192.168.0.3]
Ist die virtuelle Maschine übertragen wurde, schaut OpenNebula in den virtuellen Netzwerken Public und Red LAN nach verfügbaren IP-Adressen. Mit dem Befehl onevm show können anschließend Informationen über die virtuelle Maschine und das Netzwerk ausgegeben werden.
$ onevm show 12
VIRTUAL MACHINE 12 INFORMATION
ID : 12
NAME : server
STATE : PENDING
LCM_STATE : LCM_INIT
START TIME : 07/15 15:30:53
END TIME : -
DEPLOY ID: : -
VIRTUAL MACHINE TEMPLATE
NAME=server
NIC=[
BRIDGE=vbr1,
IP=130.10.0.1,
MAC=50:20:20:20:20:20,
NETWORK=Public,
VNID=5 ]
NIC=[
BRIDGE=eth0,
IP=192.168.0.1,
MAC=00:03:c0:a8:00:01,
NETWORK=Red LAN,
VNID=4 ]
VMID=12
Nun kann mit dem Befehl onevnet list die Leasing Informationen und weitere Details zu den virtuellen Netzwerken angezeigt werden.
$ onevnet list
NID USER NAME TYPE BRIDGE #LEASES
2 onedmin Red LAN Ranged vbr0 1
3 oneamdin Public Fixed vbr1 1
Achtung!!! Nicht in jedem Netzwerk ist das Leasing aktiviert.
$ onevnet show 4
VIRTUAL NETWORK 4 INFORMATION
ID: : 4
UID: : 0
VIRTUAL NETWORK TEMPLATE
BRIDGE=eth0
NAME=Red LAN
NETWORK_ADDRESS=192.168.0.0
NETWORK_SIZE=C
TYPE=RANGED
LEASES INFORMATION
LEASE=[ IP=192.168.0.1, MAC=00:03:c0:a8:00:01, USED=1, VID=12 ]
Die IP 192.168.0.1 wird von der virtuellen Maschine 12 verwendet.
Ein Hypervisor kann eine bestimmte MAC Adresse mit einer virtuellen Netzwerschnittstelle verknüpfen. Virtuelle Maschinen hingegen müssen eine erhalten. Es existiert eine Reihe von Möglichkeiten dieses mit OpenNebula zu realisieren.
Mit OpenNebula kann die IP-Adresse aus der MAC-Adresse mittels der MAC_PREFFIX:IP Regel angeleitet werden. Um dieses zu erreichen, existiert für Debian basierte Systeme ein Skript und kann ebenfalls für andere Distributionen genutzt werden, siehe dazu dev.opennebula.org.
Um die virtuelle Maschine dafür zu konfigurieren sind folgende Schritte notwendig.
$ ln /etc/init.d/vmcontext.sh /etc/rc2.d/S01vmcontext.sh
Während des Bootvorgangs führt die virtuelle Maschine das Skript aus, scanned alle verfügbaren Netzwerkschnittstellen und identifiziert deren MAC-Adressen. Weiterhin wird die MAC mit der IP-Adresse verknüpft und eine Schnittstelle unter /etc/network/interfaces erstellt, um sicherzustellen dass die IP Adresse der entsprechende Schnittstelle richtig zugewiesen wird.
Dieser Artikel beschreibt das Ändern der Größe eines bereits vorhandenen Images.
Situation: Aktuell befindet sich ein Image mit dem Namen „old.img“ in der Cloud und wird dort verwendet. Es wird aber ein 4 Gigabyte großes Image benötigt.
Zunächst wird Speicherplatz für das neue Image erstellt.
Dieser Artikel beschreibt die Nutzung der offiziellen Ubuntu Images unter Amazon EC2.
Um die Ubuntu Server Edition unter den Amazon Web Services auszuführen, sind folgende Schritte notwendig.
Dieser Artikel beschreibt, wie mittels KVM und dem ISO Image eines Gast Betriebssystems das installiert werden soll, ein Root Dateiystem für Eucalyptus erstellt wird.
Voraussetzung
Dieser Artikel beschreibt das Ändern der Größe eines bereits vorhandenen Images.
$ sudo fsck.ext3 -f IMAGE
$ sudo resize2fs IMAGE SIZE
Dabei handelt es sich bei „IMAGE“ um den Namen der Image Datei und „SIZE“ um die neue Größe der Datei. Hier muss darauf geachtet werden, dass ein G für GB – Gigabyte hinter der Größe steht.
Um z.B. die Größe des Image „ubuntu-9.04-i386.img“ auf 8 Gigabyte zu ändern nutzen wir den Befehl:
$ sudo fsck.ext3 -f ubuntu-9.04-i386.img
$ sudo resize2fs ubuntu-9.04-i386.img 8G
Nun kann mit dem Befehl „euca-upload-image“ das veränderte Image in die Eucalyptus Cloud hochgeladen und ausgeführt werden.
Sollte Eucalyptus so konfiguriert sein, dass die maximale Imagegröße 20 Gigabyte beträgt, sollte der Befehl „df -h“ eine ähnliche Ausgabe erzeugen.
/dev/sda1 8G /
/dev/sda2 11G /mnt
Quelle
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
Dieser Artikel beschreibt, wie mittels Xen und dem ISO Image eines Gast Betriebssystems das installiert werden soll, ein Root Dateiystem für Eucalyptus erstellt wird.
Voraussetzung