Author: Rene Buest

Rene Buest is Gartner Analyst covering Infrastructure Services & Digital Operations. Prior to that he was Director of Technology Research at Arago, Senior Analyst and Cloud Practice Lead at Crisp Research, Principal Analyst at New Age Disruption and member of the worldwide Gigaom Research Analyst Network. Rene is considered as top cloud computing analyst in Germany and one of the worldwide top analysts in this area. In addition, he is one of the world’s top cloud computing influencers and belongs to the top 100 cloud computing experts on Twitter and Google+. Since the mid-90s he is focused on the strategic use of information technology in businesses and the IT impact on our society as well as disruptive technologies.

Rene Buest is the author of numerous professional technology articles. He regularly writes for well-known IT publications like Computerwoche, CIO Magazin, LANline as well as Silicon.de and is cited in German and international media – including New York Times, Forbes Magazin, Handelsblatt, Frankfurter Allgemeine Zeitung, Wirtschaftswoche, Computerwoche, CIO, Manager Magazin and Harvard Business Manager. Furthermore Rene Buest is speaker and participant of experts rounds. He is founder of CloudUser.de and writes about cloud computing, IT infrastructure, technologies, management and strategies. He holds a diploma in computer engineering from the Hochschule Bremen (Dipl.-Informatiker (FH)) as well as a M.Sc. in IT-Management and Information Systems from the FHDW Paderborn.

Categories
Analysen

Über Enterprise Clouds, Private Clouds und einem Sündenbock (CloudExpo Europe 2010) – Teil 1

Die Zeit ist reif für Enterprise Cloud Computing

Die CloudExpo Europe 2010 in Prag stand in diesem Jahr ganz im Zeichen des Enterprise Cloud Computing und dem Statement “The Time is Right for Enterprise Cloud Computing”. Und genau diese Thematik war für mich der positive Aspekt dieser Konferenz. Wurde in den vergangenen Monaten und Jahren auf der Definition “What is Cloud Computing” buchstäblich herumgeritten, wurde nun endlich dazu übergegangen den tatsächlichen Nutzen des Cloud Computing für das Business aufzuzeigen und Argumente sowie Lösungsansätze zu präsentieren.

Neben den viel diskutierten technischen Vorteilen des Cloud Computing gegenüber eines traditionellen Rechenzentrums, standen auf der CloudExpo auch die finanziellen Vorzüge im Vordergrund.

Investitionskosten und die Art der Ausgaben
In einem klassischen Rechenzentrum muss ein Unternehmen bzgl. der Hard- und Software Anschaffungen in Vorleistung gehen und weiterhin die gesamten Kapitalaufwendungen und die Kosten für den Betriebsaufwand übernehmen. Ein Cloud Computing Anbieter hingegen investiert gezielt in seine Infrastruktur, um diese als Dienstleistung anzubieten. Die Kapitalaufwendungen werden hier somit vom Unternehmen an den Cloud Anbieter abgegeben. Das Unternehmen zahlt daher nur die Kosten für den Betriebsaufwand, wenn diese anfallen.

Cash Flow und Operative Kosten
Wie bereits oben beschrieben, muss ein Unternehmen seine Server und die Software im Voraus anschaffen. Werden die Dienstleistungen von einem Anbieter aus der Cloud bezogen, entstehen nur dann Kosten, wenn der Dienst auch tatächlich verwendet wird. Hinsichtlich der operativen Kosten versucht ein Unternehmen ständig die Kosten für die Entwicklung, Bereitstellung, Wartung, etc. zu verringern. Dieser Aufwand entfällt durch den Bezug der Leistungen von einem Cloud Anbieter. In diesem Fall ist der Anbieter für den Lebenszyklus der Hardware-und Softwarekomponenten zuständig.

Finanzielle Risiken
Investitionen in ein eigenes Rechenzentrum werden zunächst immer im Voraus getroffen, wodurch ein Unternehmen allein dafür ein enormes finanzielles Risiko eingehen muss, ohne die Gewissheit zu besitzen, dass ein ROI dabei herauskommt. Werden die Dienste von einem Cloud Anbieter bezogen, verringert sich das finanzielle Risiko auf einen Zeithorizont von einem Monat, wodurch auch der ROI ebenfalls sehr zeitnah gemessen werden kann.

Trotz der immer wiederkehrenden Diskussion, dass es sich bei dem Nutzen von Cloud Computing lediglich um das verringern der Kosten handelt (“Cloud Value is only about Cost.”), wurde dieser Mythos mit dem Statement “Cloud Value is about Business Agility, Opportunities and Investment” entkräftet. Denn Cloud Computing bietet deutlich mehr Vorteile und Möglichkeiten, als nur das Variabilisieren der Kosten, sondern ermöglicht es ein Unternehmen sich deutlich flexibler und agiler aufzustellen.

Das bereits oben genannte Statement “The Time is Right for Enterprise Cloud Computing” wurde mit einer unabhängigen Studie, in der mehrere IT-Entscheider weltweit befragt wurden, weiterhin bekräftigt. Hier ein paar ausgewählte Fragen und Antworten:

Setzt Ihr Unternehmen Cloud Computing ein?

  • Ja: 51%
  • Nein: 49%

Auf welche Art und Weise setzt Ihr Unternehmen Cloud Computing Technologien ein?

  • Kombination von Cloud und Traditionell: 60,58%
  • Experimentell: 24,93%
  • Ausschließlich Cloud Technologie: 13,19%
  • keine Angaben: 1,3%

War das durchgeführte Cloud Computing Projekt erfolgreich?

  • Ja: 96,18%
  • Nein: 3,82%

Warum Unternehmen derzeit kein Cloud Computing einsetzen.

  • Es ist zu früh die internen Systeme abzulösen: 37%
  • Cloud Computing wird als eine praktikable Technologie Option gesehen: 42%
  • Beabsichtigung, Cloud Computing in den nächsten 12 Monaten einzusetzen: 21%

Top Gründe, warum ein Wechsel in die Cloud nicht in Frage kommt:

  • Sicherheit
  • Integration
  • Zuverlässigkeit
  • Datenschutz
  • Kosten
  • Vendor Lock-In
  • Skalierbarkeit
  • Rechtlich und Ethisch

Top Cloud Computing Einsatzszenarien:

  • Unternehmensanwendungen
  • Infrastructure as a Service
  • IT Management
  • Productivity Anwendungen
  • Anwendungen zur Kollaboration
  • Entwicklung / Deployment

Erwarten Sie, dass die Adaption von Cloud Computing dazu führt, neue Lieferanten an Ihr Unternehmen anzubinden?

  • Ja: 61,9%
  • Nein: 14,5%
  • keine Angaben: 22,6%

Wird Cloud Computing eine zusätzliche Komplexität in die gesamte Verwaltung von IT-Ressourcen bringen?

  • Ja: 26,9%
  • Nein: 54,9%
  • keine Angaben: 16,7%

Sind Sie der Meinung, dass Cloud Computing zu einer kleineren IT-Abteilung führen könnte?

  • Ja: 55,9%
  • Nein: 25,7%
  • keine Angaben: 16,9%

Zusammenfassend zeigt die Studie, dass über 96% aller Befragten ihre Cloud Computing Projekte erfolgreich umsetzen konnten und 72% die derzeit keine Cloud Technologie einsetzen, dem aber sehr positiv gegenüber eingestellt sind. Dagegen sehen 60% der Befragten Datenschutz, Integration und die Zuverlässigkeit als die zu lösenden Probleme des Cloud Computing, wobei 85% den Punkt Sicherheit derzeit als den Hauptfaktor ansehen, nicht in die Cloud zu wechseln.

Erfahren Sie Morgen im zweiten Teil, warum Cloud Computing der Sündenbock ist.

Categories
Services @de

ScaleUp Technologies kündigt sichere Cloud Storage Lösung mit deutschem Serverstandort an.

In Deutschland betriebene Storage Lösung für nur 0,10 € / GB pro Monat – Günstiger als Amazon S3

(Berlin, Deutschland – 30. Juni 2010) ScaleUp geht mit einer in Deutschland betriebenen sicheren Cloud Storage Lösung an den Markt. Die Lösung ähnelt dem S3 von Amazon und wird im ScaleUp Cloud Rechenzentrum in Berlin gehostet. Dieses neue Angebotsspektrum ermöglicht es den Kunden von ScaleUp von den niedrigen Kosten und der Flexibilität des Cloud Storage zu profitieren, das sogar mit dem bekannten S3 API kompatibel ist, ohne dass jedoch die Daten Deutschland je verlassen. Zugleich genießen die Kunden den Komfort eines Providers mit deutschem Standort.

Als erster Cloud Computing Provider, der in Deutschland an den Markt geht, versteht ScaleUp Technologies das Bedürfnis deutscher Kunden nach Privatsphäre und Sicherheit besser als die meisten im Ausland ansässigen Anbieter. Im Verlauf des vergangenen Jahres hat das Unternehmen während des Aufbaus seines Cloud-Dienstleistungsangebotes daran gearbeitet, eine vollständige Einhaltung des Bundesdatenschutzgesetzes bzw. BDSG zu gewährleisten.

In dem Bestreben eine neue Vertrauensbasis beim Thema Cloud Computing und Cloud Storage zu schaffen, wird ScaleUp mit Sicherheitsexperten zusammenarbeiten, um die Einhaltung aller Vorgaben zum Thema Privatsphäre und Sicherheit zu gewährleisten. Laut Scott Sanchez, Fachmann zum Thema Privatsphäre und Sicherheit im Cloud Computing, müssen “Unternehmen, denen Sicherheit, Privatsphäre und Compliance wichtig sind, einen Provider finden, der nicht nur Behauptungen anstellt oder schlicht sagt “Vertrauen Sie uns”, sondern der wirklich die erforderliche Transparenz bietet, die nicht nur die Prüfer zufrieden stellt, sondern auch Sie selbst nachts ruhig schlafen lässt”. Herr Sanchez geht noch weiter und erklärt: “Letztlich liegt die Verantwortung für eine sichere und rechtskonforme Datenspeicherung in den Händen der Datenbesitzer und nicht in denen der Cloud Provider. Allerdings werden jene Provider langfristig am Erfolgreichsten sein, die mit ihren Kunden beim Thema Sicherheit und Compliance Hand in Hand arbeiten – und damit die Cloud Plattform unter der selben Prämisse und mit gemeinsamen Zielsetzungen aufbauen und betreiben.”

ScaleUp hat über mehrere Monate hinweg Speichertechnologien von Providern überprüft, bevor die Entscheidung auf Scality fiel, dem Entwickler von hoch skalierbarer Objektspeichersoftware für Email- und Cloud Storage Anwendungen.

“Das Technik- und Expertenteam von Scality gab uns das gute Gefühl, dass wir mit ihnen den Sicherheitsanforderungen für unser Speicherangebot gerecht werden können”, sagt Christoph Streit, CTO & Mitbegründer von ScaleUp. „Und diese Partnerschaft erlaubt uns zudem die ScaleUp Storage Lösung für nur 0,10 € pro GB pro Monat ** anzubieten – günstiger sogar als Amazon S3 mit einem vergleichbaren Service.“

Für weitere Informationen besuchen Sie bitte http://lp.scaleupcloud.com/secure-cloud-storage-de.

** exkl. 19% MwSt.

Über ScaleUp

ScaleUp Technologies ist ein Cloud Computing Provider, der äußerst flexible öffentliche, private und hybride Cloud Infrastrukturen für expandierende Unternehmen anbietet. ScaleUp hat seinen Standort in Deutschland – mit Augenmerk auf die Bedürfnisse deutscher und europäischer Kunden – und bietet eine globale Infrastruktur, die mittels eines globalen Cloud Netzwerks skaliert wird. www.scaleupcloud.com

Über Scality

Scality hat eine hoch skalierbare Speicherungsplattform entwickelt, die eine deutlich einfachere Anwendungsimplementierung zu einem Bruchteil der Kosten konventioneller Speicherungen ermöglicht. Als Software-Lösung kann Scality sowohl für Email-Lösungen von Kabel- oder Telekommunikationsanbieter eingesetzt werden oder auch als System, das Cloud Storage Dienstleistungen für Hostinganbieter oder andere speicherintensive Dienstleistungen ermöglicht und ausbaut. Die Produkte von Scality werden direkt an Internetanbieter, Kabel-, Festnetz- und Mobilfunkbetreiber sowie Hostingfirmen verkauft und über Mehrwert-Vertriebswege abgesetzt. Weitere Informationen finden Sie unter www.scality.com

Categories
Videos

Video-Podcast: Die finanziellen Aspekte des Cloud Computing

Andy Brown – Managing Director der Bank Of America, Inc, erläutert in diesem Video-Podcast die finanziellen Aspekte des Cloud Computing.

via YouTube
via CloudSlamEvent

Categories
Grundlagen Services @de

Der Amazon EC2 Instanzspeicher

Jede Instanz verfügt über eine festen Speicherplatz, auf dem Daten gespeichert werden können. Dieser wird im EC2 Kontext als Instanzspeicher bezeichnet und ist nicht als permanente Speicherlösung gedacht.

Wird eine Instanz neu gestartet, bleiben die Daten auf dem Instanzspeicher bestehen. Wird die Instanz higegen beendet, gestoppt oder ein Fehler tritt auf, dann sind die Daten verloren.

Für den Einsatz einer dauerhaften Speicherlösung empfiehlt Amazon daher Amazon Elastic Block Store.

Sollte Amazon EBS nicht eingesetzt werden, sollten wichtige Daten auf Amazon S3 gesichert werden.

Speicherort

Wo sich der Speicher auf den jeweiligen Instanz Typen befindet, kann der folgenden Tabelle entnommen werden.

Ort
Beschreibung
/dev/sda1 Auf allen Linux/Unix Instanz Typen als root (/) formatiert und gemounted. Auf allen Windows Instanz Typen als C: formatiert und gemounted.
/dev/sda2 oder xvdb (Windows) Auf allen m1.small und c1.medium Instanzen als /mnt formatiert und gemounted. Auf allen small Windows Instanzen formatiert und gemounted.
/dev/sda3 Auf allen m1.small und c1.medium Instanzen für Linux/Unix Instanz Typen als /swap formatiert und gemounted. Für Windows Instanzen nicht verfügbar.
/dev/sdb oderr xvdb (Windows) Auf allen m1.large, m1.xlarge, c1.xlarge, m2.xlarge, m2.2xlarge, und m2.4xlarge Instanzen für Linux/Unix Instanz Typen als /mnt formatiert und gemounted. Für alle m1.large, m1.xlarge, c1.xlarge, m2.xlarge, und m2.2xlarge Windows Instanzen formatiert und gemounted.
/dev/sdc oder xvdc (Windows) Verfügbar auf m1.large, m1.xlarge und c1.xlarge Linux/Unix Instanzen. Auf m1.large, m1.xlarge, c1.xlarge und m2.4xlarge Windows Instanzen formatiert und gemounted.
/dev/sdd or xvdd (Windows) Verfügbar auf m1.xlarge und c1.xlarge Linux/UNIX Instanzen. Auf m1.xlarge und c1.xlarge Windows Instanzen formatiert und gemounted.
/dev/sde or xvde (Windows) Verfügbar auf m1.xlarge und c1.xlarge Linux/Unix Instanzen. Auf m1.xlarge und c1.xlarge Windows Instanzen formatiert und gemounted.

Quelle

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
Grundlagen Services @de

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

Categories
Tutorials @de

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
Categories
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

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

Categories
Tutorials @de

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.

Continue reading “Eucalyptus: Die Größe von Images ändern (Variante 2)”