Kategorien
Tutorials

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
Kategorien
Grundlagen Services

Amazon Machine Images (AMI)

Eine Amazon EC2 Instanz kann auf Basis eines Amazon Machine Image (AMI) welches sich in Amazon EBS befindet oder eines AMI welches in Amazon S3 gespeichert ist gestartet werden. Dabei verwenden Instanzen, bei denen die AMIs in Amazon EBS gespeichert sind, EBS Volumes als Root Device (von wo gebooted wird). Dagegen nutzen Instanzen, deren AMIs in Amazon S3 abgelegt sind einen Instanzspeicher als das Root Device.

Die folgende Tabelle beschreibt die Unterschiede zwischen AMIs die in Amazon EBS abgelegt sind und AMIs die sich in Amazon S3 (Instanzspeicher) befinden.

Eigenschaften
Amazon EBS
Amazon S3 (Instanzspeicher)
Bootzeit Gewöhnlich weniger als 1 Minute. In der Regel weniger als 5 Minuten.
Größenbeschränkung 1 Terrabyte (TB) 10 Gigabyte (GB)
Speicherort Amazon EBS volume Instanzspeicher
Datenpersistenz Die Daten bleiben vorhanden, wenn die Instanz ausfällt und können gespeichert werden, wenn die Instanz beendet wird. Die Daten bleiben nur für die Lebensdauer der Instanz erhalten.
Erweiterung Der Instanz-Typ, Kernel, die RAM Disk und die Benuterdaten können geändert werden, während die Instanz gestoppt (angehalten) ist. Die Attribute einer Instanz sind für ihre Lebensdauer festgesetzt und können währenddessen nicht geändert werden.
Kosten Instanz Nutzung, Amazon EBS Volume Nutzung und Amazon EBS Snapshot Kosten zum Speichern der AMI. Instanz Nutzung und Amazon S3 Kosten zum Speichern der AMI.
AMI Erstellung / Bundling Verwendet einen einzigen Befehl / Anweisung Erfordert die Installation und die Nutzung der AMI Tools
Stoppen / Anhalten Kann in den Zustand „angehalten“ überführt werden, wenn eine Instanz nicht ausgeführt wird, aber in Amazon EBS gespeichert ist. Kann nicht gestoppt werden, Instanzen werden ausgeführt oder nicht.

Öffentliche AMIs können direkt über Amazon oder die Amazon EC2 Community bezogen werden. Öffentliche AMIs dienen als Basis und können dazu benutzt werden, um eigene maßgeschneidert AMIs zu erstellen.

Private AMIs sind AMIs die einem selbst gehören. Auf diese kann daher nur selbst bzw. von Leuten zugegriffen werden, denen man den Zugriff erlaubt hat.

Shared AMIs werden von Entwicklern erstellt und anderen Entwicklern für die Nutzung zur Verfügung gestellt.

Paid AMIs können von Entwicklern oder Unternehmen wie z.B. RedHat gekauft werden. Es existieren ebenfalls AMIs die an spezielle Serviceverträge gekoppelt sind.

Quelle

Kategorien
Tutorials

OpenNebula: Die Verwaltung virtueller Netzwerke

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:

  • Ein privates Netzwerk mit der virtuellen Bridge vbr0.
  • Ein Netzwerk inkl. Internetverbindung mit der virtuellen Bridge vbr1.

Definition eines virtuellen Netzwerks


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:

  • Statische: Definiert einen festen Satz von IP/MAC-Adressen Paaren
  • Klassen: Definiert ein Class X Netzwerk (z.B. Class A)

Virtuelle Netzwerke die von dem Benutzer oneadmin erstellt wurden, können von jedem anderen Benutzer ebenfalls verwendet werden.

Statische virtuelle Netzwerke

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:

  • NAME: Name des virtuellen Netzwerks
  • TYPE: In diesem Fall – Fixed
  • BRIDGE: Name der physikalischen Bridge des physikalischen Hosts, mit der die virtuelle Maschine eine Netzwerkverbindung aufbauen wird.
  • LEASES: Definition der IP-/MAC Paare. Sollte eine IP-Adresse definiert sein, aber keine Verknüpfung mit einer MAC-Adresse bestehen, wird OpenNebula das Paar automatisch mit der Regel MAC = MAC_PREFFIX:IP generieren. Zum Beispiel erhalten wir mit der IP-Adresse 10.0.0.1 und dem MAC_PEFFIX die MAC 00:16:0a:00:00:01.

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]

Klassifiziertes virtuelles Netzwerk

Diese Art von virtuellen Netzwerk benötigt u.a. einen festgelegten IP-Adressblock und weitere folgende Informationen:

  • NAME: Name des virtuellen Netzwerks.
  • TYPE: In diesem Fall – Ranged.
  • BRIDGE: Name der physikalischen Bridge.
  • NETWORK_ADDRESS: IP-Adressblock
  • NETWORK_SIZE: Anzahl der Hosts die sich in diesem Netzwerk befinden dürfen. Das kann über eine Zahl oder über die Netzwerk Klasse A, B oder C definiert werden.

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.

Hinzufügen und Löschen virtueller Netzwerke


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.

Leasing


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.

Leasing innerhalb der virtuellen Maschine


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.

  • Die IP-Adresse von der MAC Adresse mittels der Standardmethode erhalten.
  • Mithilfe des CONTEXT Attribut.

Eine virtuelle Maschine konfigurieren um das Leasing zu nutzen

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.

  • Kopieren des Skript $ONE_LOCATION/share/scripts/vmcontext.sh in das Verzeichnis /etc/init.d.
  • Ausführen des Skripts während des Bootvorgangs bevor ein Netzwerkdienst gestartet wird – z.B. Runlevel 2.
$ 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.

Quelle

  • Managing Virtual Networks 1.4
Kategorien
Videos

Video-Podcast: Adaption von Cloud Computing Modellen

Brian Boruff – VP von CSC – erläutert in diesem Video-Podcast die Adaption von Cloud Computing Modellen.

via YouTube
via CloudSlamEvent

Kategorien
Analysen

Klassischer Fall für den Einsatz von Cloud Computing (ZDF – WM 2010)

Heute haben wir es wieder einmal Live miterlebt. Ein klassisches Szenario, wo Cloud Computing hätte helfen können. Das ZDF übertrug das WM Spiel Deutschland gegen Serbien ab 13:30 Uhr, also zu einer Uhrzeit wo die Vielzahl der Menschen in Deutschland arbeiten muss.

Parallel zur Fernsehübertragung existiert(e) ganz modern ebenfalls ein Live Stream, erreichbar über die Internetseite des ZDF – http://zdf.de. Die Vorberichte des Spiels wurden stabil übertragen. Es wurde nicht einmal der Eindruck vermittelt, einen Internet Stream zu sehen. Doch bereits während der Nationalhymnen zeigte sich grausames!

.

ERROR

The requested URL could not be retrieved


While trying to retrieve the URL: http://www.zdf.de

The following error was encountered:

  • Unable to forward this request at this time.

Footprint 4.6/FPMCP
Generated Fri, 18 Jun 2010 11:46:18 GMT by 4.23.38.126 (Footprint 4.6/FPMCP)

.

Heißt, die Systeme sind auf Grund zu vieler Anfragen überlastet, wodurch eine Antwort nicht möglich ist!

Das hätte nicht passieren müssen! Durch den Einsatz von Cloud Computing Technologien hätten hier präventive Maßnahmen ergriffen werden können, indem auf eine automatische Skalierbarkeit der Infrastruktur und Systeme geachtet worden wäre. Ausreichend Zeit war vorhanden, eine Fußball Weltmeisterschaft steht schließlich nicht plötzlich vor der Tür.

Weitere Informationen gibt es z.B. unter Autoscaling und Cloud Computing Nutzen: Bereitstellung von Medieninhalte.

Kategorien
Tutorials

Eucalyptus: Die Größe von Images ändern (Variante 2)

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.

Kategorien
Grundlagen Services

Der Amazon EC2 Workflow

Die folgende Graphik verdeutlicht den grundsätzlichen Ablauf zum Verwenden von Amazon EC2.

  • 1. Zunächst wird ein AMI (Amazon Machine Image) von Grund auf neu, oder auf Basis eines bereits vorhandenen AMIs erstellt. Dieser Vorgang ist optional, da Instanzen aus bereits vorhandenen AMIs gestartet werden können, ohne diese vorab zu verändern.
  • 2. Für ein AMI das einen lokalen Instanzspeicher für sein Root Device verwendet, muss der Prozess zum bundlen und registrieren des AMIs erfolgen. Für ein AMI hingegen, dass ein Amazon EBS Volume verwendet, reicht es aus, den create Image Befehl auf einer bereits gestarteten Instanz auszuführen. Amazon EC2 gibt anschließend eine AMI ID zurück, wodurch auf Basis des AMI so viele Instanzen wie gewünscht gestartet werden können.
  • 3. Starten einer oder mehrerer Instanzen eines AMI.
  • 4. Verwalten und verwenden der Instanzen als wären es gewöhnliche Server.

Quelle

Kategorien
Tutorials

Amazon EC2 mit Ubuntu Images (erste Schritte)

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.

  • Erstellen eines Amazon Web Services Account
  • Konfigurieren der Keys
  • Installation der Amazon EC2 API Tools
  • Instanziierung der Images
  • Konfiguration der Instanz
Kategorien
Grundlagen Services

Das Konzept der Amazon Virtual Private Cloud

Bei der Amazon Virtual Private Cloud (VPC) handelt es sich um eine sichere und lückelose Integrationsmöglichkeit zwischen der bereits vorhandenen IT Infrastruktur eines Unternehmens und der Amazon Cloud und dient zum Aufbau einer Hybrid Cloud. Mit Amazon VPC können Unternehmen ihre existierende Infrastruktur mit speziell isolierten AWS Ressourcen mittel eines Virtual Private Network (VPN) verbinden, um damit die Verwaltungsmögklichkeiten wie die Bereiche Sicherheit, Firewall und Intrusion Dection für die AWS Ressourcen zu erweitern.

Um die Amazon Virtual Private Cloud zu nutzen, muss zunächst der IP-Adressraum für die VPC festgelegt werden. Die IP-Adressen innerhalb dieses Adressraums sind privat und bilden ein Netzwerk das mittels paketbasierten Routing von anderen Netzwerken inkl. dem Internet vollständig isoliert ist.

Als nächstes müssen Subnetze erstellt werden, welche Segmente eines VPC IP-Adressraums sind. Damit können die Amazon EC2 Instanzen innerhalb des VPC separiert und sicher betrieben werden. Existiert mehr als ein Subnetz in einem VPC, werden diese mittels eines logischen Routers sternförmig (Stern-Topologie) miteinander verbunden.

Um sich mit der VPC zu verbinden, wird eine VPN Verbindung benötigt, die als VPN Tunnel zwischen der VPC und dem Rechenzentrum, dem Heimnetzwerk oder jeder anderen Co-Location dient. Dazu muss das eigene bestehende Netzwerk so konfiguriert werden, dass jeglicher VPC Datenverkehr zu dem Gateway geroutet wird, welches das Ende der VPN Verbindung darstellt.

Mit einer aktiven VPN Verbindung können anschließend Amazon EC2 Instanzen in einem VPC subnetz starten. Mit den entsprechenden Sicherheitsrichtlinen ist diese Instanz dann ebenfalls im eigenen Netzwerk sichtbar und kann von dort aus wie eine „lokale“ Instanz genutzt werden.

VPC basierter Datenverkehr der für das Internet bestimmt ist, wird zunächst automatisch über das VPN in das eigene Netzwerk gerouted. Dort kann dieser von bereits vorhandenen Sicherheitssystemen, wie Firewalls, Intrusion Detection Systemen untersucht werden, bevor die Daten in das Internet weitergeleitet werden. Das ist dann besonders sinnvoll, wenn spezielle Hardware- und Softwaresysteme eingesetzt werden, um bestimmte Sicherheitsrichtlinien zu erfüllen.

Quelle

Kategorien
Videos

Video-Podcast: Migration von Anwendungen in die Cloud

Hal Stern – VP VON SUNOracle – erläutert in diesem Video-Podcast, wie die Migration von Anwendungen in die Cloud erfolgt.

via YouTube
via CloudSlamEvent