Tag: OpenNebula


Professionelle Open-Source Lösungen für die eigene Cloud

Ich hatte vor längerer Zeit in dem Artikel "Die eigene Cloud bauen mit… – CloudWashing par excellence!" die leichtfertige Aussage eines Journalisten kritisiert, dass man auf einfache Weise eine eigene Cloud Umgebung aufbauen kann. Das dem so nicht ist und worauf zu achten ist, habe ich in dem Artikel ebenfalls erläutert. Dennoch existieren natürlich Lösungen, die dabei helfen, eine eigene Cloud aufzubauen. Tatsächlich gibt es derzeit aber nur fünf Open-Source Lösungen, die für den professionellen Aufbau von Cloud Computing Umgebungen eingesetzt werden sollten. Dazu gehören openQRM, Eucalyptus, OpenStack, CloudStack und OpenNebula.

Grundlegendes! Bitte lesen!

Viele Unternehmen entscheiden sich vermehrt für den Aufbau einer eigenen (Private) Cloud, um die Kontrolle über Ressourcen, Daten, Sicherheit usw. zu behalten. Richtig ist, dass eine eigene Cloud die Agilität eines Unternehmens verbessert und die Systeme bis zu einem gewissen Grad skalieren können. Allerdings sollte sich ein Unternehmen immer bewusst machen, das die Skalierbarkeit einer eigenen Cloud einem manuellen Prozess gleicht. Bei diesem muss in Echtzeit auf Ressourcenengpässe durch das eigene Personal reagiert werden, indem weitere Hardwarekomponenten in Form von Speicherplatz, Arbeitsspeicher oder Rechenleistung nachgerüstet werden. Für jede virtuelle Instanz wird schließlich auch die physikalische Hardware benötigt. Neben Hardware- und Softwareressourcen sind Tools zum Echtzeit-Monitoring der Umgebung daher unerlässlich.

Hardware, Hardware, Hardware

Eine eigene Cloud bedarf also Unmengen an physikalischen Ressourcen um den Wunsch nach Flexibilität und quasi unendlichen virtuellen Ressourcen zu befriedigen. Heißt im Umkehrschluß daher für Unternehmen mit einer eigenen Cloud: Investieren, das eigene Rechenzentrum umbauen und Cloud-fähig zu machen.

Es ist ein Irrglaube, wenn man denkt, dass der Aufbau einer eigenen Cloud impliziert, sich anschließend nicht mehr um die Hochverfügbarkeit der eigenen Infrastruktur (physikalische Maschinen, virtuelle Maschinen, Master-Slave-Replikation, Hot-Standby, etc.) kümmern zu müssen. Das macht dann ja schließlich die Cloud alleine.

Konfigurieren, Skripte, Intelligenz

Eine Cloud funktioniert nicht von alleine. Sie muss entwickelt und mit Intelligenz ausgestattet werden. Das gilt für den Aufbau einer Private Cloud genau so wie für die Nutzung eines Public Cloud Angebots (im Falle von IaaS). Dazu müssen Skripte geschrieben, womöglich Software neu entwickelt werden, die auf der Cloud verteilt läuft. Weiterhin ist es wichtig, die Whitepaper des Anbieter zu lesen, KnowHow(!) aufzubauen und zu verstehen, wie die Cloud arbeitet, um sie für die eigenen Bedürfnisse nutzen zu können. Eine weitere Möglichkeit besteht natürlich darin, sich (zusätzlich) von Profis beraten zu lassen. Das ist bei der Nutzung einer eigenen Cloud nicht anders. Wenn eine virtuelle Maschine A ein Problem hat, dann kann sie plötzlich nicht mehr erreichbar sein, wie jeder normale physikalische Server nun einmal auch. Nun könnte man denken: “Dann nehme ich als Backup für virtuelle Maschine A halt noch eine virtuelle Maschine B dazu!” Und dann? Man könnte nun denken, dass die virtuelle Maschine B automatisch die Aufgaben der virtuelle Maschine A übernimmt. So einfach ist das aber nicht! Skripte müssen vorab dafür sorgen, dass die virtuelle Maschine B die Aufgaben von virtuelle Maschine A übernehmen soll, wenn diese plötzlich nicht mehr erreichbar ist. Auch die virtuelle Maschine B muss dafür zunächst vorbereitet werden. Dazu kann z.B. der eigentliche (wichtige) Inhalt der virtuelle Maschine A inkl. aller Konfigurationen etc. in einem zentralen Speicher und nicht auf dem lokalen Speicher abgelegt werden. Anschließend muss ein Skript dafür sorgen, dass die virtuelle Maschine B automatisch mit den Konfigurationen und allen Daten aus dem lokalen Speicher hochgefahren wird, wenn die virtuelle Maschine A nicht mehr verfügbar ist.

Virtuelles Rechenzentrum

Die Cloud gibt uns im Bereich Infrastructure as a Service letztendlich nur die Möglichkeit, aus einem quasi unendlich großen Pool von Ressourcen die (unendliche) Anzahl an Ressourcen zu dem Zeitpunkt zu bekommen, wenn wir sie benötigen. Wir erhalten von der Cloud somit ein eigenes hochskalierbares virtuelles Rechenzentrum. Das bedeutet aber im Umkehrschluss für den Betreiber einer Cloud (Private, Public), dass er ebenfalls die Menge an physikalischen Ressourcen vorhalten muss, damit die angefragten virtuellen Ressourcen jederzeit bereitgestellt werden können und damit immer ausreichend Ressourcen für die Nutzer zur Verfügung stehen.


Open-Source Lösungen für den Aufbau einer eigenen Cloud


openQRM

openQRM ist eine Open Source Cloud Computing Plattform für die Verwaltung von Rechenzentren und skalierbaren IT-Infrastrukturen und ist aktuell in der Version 5.0 verfügbar. Mittels einer zentralen Managementkonsole kann die Administration von physikalischen Servern ebenso vorgenommen werden wie von virtuellen Maschinen, wodurch Rechenzentren voll automatisiert und höchst skalierbar betrieben werden können. Neben einer offenen API und einem SOAP Web Service für die nahtlose Integration der eigenen Geschäftsprozesse, unterstützt openQRM alle bekannten Virtualisierungstechnologien und bietet die Möglichkeit für transparente Migrationen von "P-to-V", "V-to-P" und "V-to-V".

openQRM verfügt des Weiteren über ein integriertes Storage-Management, mit dem anhand des Snapshot-Verfahrens Serversysteme dupliziert werden können. Die Snapshots ermöglichen eine dynamische Anpassung des Speicherplatzes, bieten einen persistenten Cloud-Speicher und erlauben ein Backup/Restore der Server sowie deren Versionierung.

Mit der "N-zu-1" Fail-Over Funktion steht mehreren Serversystemen ein einzelner Stand-By-Server zur Verfügung. Dabei spielt es keine Rolle, ob physikalische oder virtuelle Maschinen eingesetzt werden!

Benefits auf einem Blick

Virtualisierung

openQRM unterstützt alle gängigen Virtualisierungstechnologien darunter VMWare, Citrix XenServer und KVM und bietet die Möglichkeit der Migration von P-to-V-, V-to-P- und V-to-V für physikalische Server als auch virtuelle Maschinen.

Storage

openQRM verfügt über ein zentralisiertes Speichersystem mit integriertem Storage Management, welches alle bekannten Storage-Technologien unterstützt. Dazu gehören u.a. Netapp, Equallogic, NFS, iSCSI ZFS und proprietäre auf LVM basierende Storage-Typen, für eine flexible und schnelle Duplizierung von Serversystemen.

Zentrales Management

openQRM verschmilzt die Welt von Open Source mit der von kommerziellen Produkten. Mit einer zentralen Managementkonsole sind alle Funktionen zur Administration von Rechenzentren, System- und Service-Überwachung, Hochverfügbarkeit und automatisierter Bereitstellung vorhanden.

Funktionen

Hardware/Software Isolation

openQRM isoliert die Hardware (physikalische Server, virtuelle Maschinen) vollständig von der Software (Server Images). Dabei ist die eigentliche Hardware eine "Computing Resource" und kann dadurch jederzeit durch eine andere Hardware ersetzt werden, ohne dass die Software (Server Image) neu konfiguriert werden muss.

Unterstützung für verschiedene Virtualisierungs-Technologien

Mit VMWare, Xen, KVM und dem Citrix XenServer unterstützt openQRM eine viehlzahl an virtuellen Maschinen und kann dieses transparent verwalten und migrieren. Neben der System-Migration von physikalischen Servern zu virtuellen Maschinen (P-to-V) können Systeme ebenfalls von virtuellen Maschinen zu physikalischen Servern (V-to-P) migriert werden. Darüber hinaus besteht die Möglichkeit ein System von einer Virtualisierungstechnologie zu einer anderen Virtualisierungstechnologie (V-to-V) zu verschieben.

Vollautomatische Nagios-Konfiguration

openQRM unterstützt die vollautomatische Konfiguration von Nagios mittels "nmap2nagios-ng". Damit wird das gesamte openQRM Netzwerk analysiert und auf Basis der Informationen eine Nagios-Konfiguration erstellt. Anschließend werden alle Services auf allen Systemen überwacht.

Integriertes Storage-Management

openQRM organisiert die Serversysteme wie Dateien und nutzt zur Verwaltung moderne Storagesysteme anstatt lokaler Festplatten. Mittels Logical Volume Managern (LVM) und deren Snapshot-Verfahren können Server-Templates auf schnellen Wege dupliziert werden.

"Sollen z.B. 10 neue Server ausgerollt werden, kann so einfach ein bestehendes Server-Image 10 mal dupliziert und die "Clone" direkt zum Deployment bereitgestellt werden."

Mit diesem Konzept steht ein zentrales Backup/Restore sowie die Möglichkeit von Hot-Backups ohne Downtime zur Verfügung.

openQRM unterstützt folgende Storage-Typen:

  • NFS (NAS)
  • iSCSI (iSCSI SAN)
  • Aoe/Coraid (AOE SAN)
  • NetApp (iSCSI SAN)
  • Local-disk (Übertragung von Server-Images auf lokale Festplatten)
  • LVM-Nfs (NFS auf LVM2, erlaubt schnelles Cloning)
  • LVM-iSCSI (iSCSI auf LVM2, erlaubt schnelles Cloning)
  • LVM-Aoe (Aoe auf LVM2, erlaubt schnelles Cloning)
  • Equallogic (iSCSI SAN)
  • ZFS (iSCSI SAN)

Hochverfügbarkeit und "N-to-1"-Fail-Over!

Mit der "N-zu-1" Fail-Over Funktion steht mehreren Serversystemen ein einzelner Stand-By-Server zur Verfügung. Unabhängig davon, ob physikalische oder virtuelle Maschinen eingesetzt werden.

"Um zum Beispiel 10 hochverfügbare Spezialsysteme zu betreiben benötigt man normalerweise weitere 10 "Stand-By"-Systeme. Mit openQRM jedoch benötigt man nur einen einzigen "Stand-By"-Server, der im Fehlerfall eines der 10 Spezialsysteme benutzt wird. Das heißt, man kann 9 "stromfressende", nicht ausgelastete Server einsparen. Perfekt für "Green IT".

Des Weiteren können physikalische Server virtuelle Maschinen als "Hot Stand-By" nutzen und lassen sich im Notfall in eine virtuelle Maschine migrieren.

Fertige Server-Templates

Mittels dem "Image-Shelf"-Plugin stellt openQRM bereits fertige Server Templates zur Verfügung. Dazu gehören Linux Distributionen wie Debian, Ubuntu, CentOS und openSuse. Des Weiteren können mit dem Plugin eigene Server Templates auf unterschiedliche Weise (lokal, http, https, ftp) bereitgestellt werden.

Unterstützung verschiedenster Deployment-Methoden

Mit openQRM können Server von jeder Art von Storage gestartet werden. Zusätzlich können die Server Templates von einem Storage-Typ zu einem anderen übertragen werden, dabei kann noch entschieden werden, ob die Server Templates auf einem physikalischen Server oder in einer virtuellen Maschine gestartet werden sollen.

Unterstützung verschiedener OS-Distributionen

Es stehen bereits vor-konfigurierte openQRM-Server Pakete für Debian, Ubuntu und CentOS zur Verfügung. Ein openQRM-Server kann aber alle gängigen Linux Distributionen verwalten.

Cloud-Selector

Mit dem Cloud-Selector kann der Cloud Administrator seine Cloud Produkte wie z.B. Prozessoren, Speicher, Festplattengröße oder den Typ der virtuellen Maschine auswählen und deren Preise festlegen.

Kostenrechner im Cloud-Portal

Die Cloud-Computing-Unit (CCU) kann einer regulären Währung (z.b. USD oder Euro) zugewiesen werden. Mit dem Kostenrechner werden die stündlichen, täglichen und monatlichen verbrauchten Kosten für eine Cloud Appliance berechnet.

Private Cloud Images

Mit der "Private Cloud Image"-Funktion können Cloud Benutzer eigene Server Templates anlegen und verwalten.

Volle SSL-Unterstützung

Der openQRM-Server arbeitet in einem vollständig SSL-verschlüsselten Bereich und unterstützt verschiedene Serverarchitekturen wie i386 und x86_64.

Ich möchte hier noch anmerken, dass es sich bei der openQRM Enterprise um einen deutschen Anbieter aus dem Bereich des Cloud Computing handelt!


Eucalyptus

Beim Elastic Utility Computing Architecture for Linking Your Programs To Useful Systems (Eucalyptus) handelt es sich um eine Open Source Software Infrastruktur zum Aufbau von skalierbaren Utility Computing bzw. Cloud Computing Umgebungen für spezielle Clustersysteme oder einfachen miteinander verbundenen Arbeitsplatzrechnern.

Eucalyptus wurde als ein Forschungsprojekt am Computer Science department an der University of California Santa Barbara entwickelt und wird mittlerweile von der Eucalyptus Systems Inc. vermarktet. Die Software wird aber weiterhin als Open Source Projekt gepflegt und weiterentwickelt. Die Eucalyptus Systems Inc. bietet darüber hinaus lediglich weitere Dienstleitungen und Produkte sowie einen professionellen Support rund um Eucalyptus an.

Folgende Funktionen stellt Eucalyptus bereit:

  • Kompatibilität mit den Schnittstellen zu Amazon EC2 und S3 (SOAP und REST).
  • Unterstützung aller Virtual Machines die auf einem Xen Hypervisor oder einer KVM ausgeführt werden.
  • Administrationstools für die System- und Benutzerverwaltung.
  • Die Möglichkeit mehrere Cluster für eine Cloud zu konfigurieren, wobei jeder einzelne Cluster über eine private interne IP-Adresse verfügt.

Architektur

Eucalyptus besteht aus fünf zusammenarbeitenden Hauptkomponenten um den angeforderten Cloud Service bereit zu stellen. Die Kommunikation zwischen den Komponenten erfolgt über gesicherte SOAP Nachrichten mittels WS-Security.

Cloud Controller (CLC)

Der Cloud Controller dient innerhalb einer Eucalyptus Cloud als Hauptkomponente für die Verwaltung des gesamten Systems und stellt den Administratoren und Benutzern einen zentralen Zugriffspunkt bereit. Die Kommunikation aller Clients mit dem Eucalyptus System erfolgt ausschließlich nur über den Cloud Controller anhand der auf SOAP oder REST basierenden API. Der Cloud Controller ist dafür zuständig, alle Anfragen zu der richtigen Komponente weiterzuleiten, diese zu sammeln und die Antwort der Komponente anschließend wieder zu dem Client zurück zu senden. Der Cloud Controller ist somit die öffentliche Schnittstelle einer Eucalyptus Cloud.

Cluster Controller (CC)

Der Cluster Controller ist innerhalb des Eucalyptus Systems für die Verwaltung des virtuellen Netzwerks zuständig. Der Cloud Controller erhält alle Anfragen auf Basis seiner SOAP oder REST Schnittstellen. Der Cloud Controller erhält alle Informationen über die vorhandenen Node Controllers des Eucalyptus Systems und ist für die Kontrolle des Lebenszyklus jedes einzelnen verantwortlich. Er leitet alle Anfragen an die Node Controller mit verfügbaren Ressourcen weiter um damit virtuelle Instanzen zu starten.

Node Controller (NC)

Ein Node Controller steuert das Betriebssystem und den zugehörigen Hypervisor eines Rechners (Node) im Eucalyptus System. Auf jeder physikalischen Maschine die eine durch den Cluster Controller instantiierte virtuelle Instanz auf Grund einer Anfrage beherbergt, muss eine Instanz eines Node Controller vorhanden sein.

Walrus (W)

Walrus ist für die Zugriffsverwaltung auf den Speicherdienst innerhalb eines Eucalyptus Systems zuständig. Walrus erhält die Anfragen über seine SOAP oder REST Schnittstelle.

Storage Controller (SC)

Der Storage Controller verwaltet den Speicherdienst innerhalb eines Eucalyptus Systems und verfügt über eine Schnittstelle zu Amazon's S3 Dienst. Der Storage Controller arbeit in Verbindung mit Walrus und wird für die Speicherung und den Zugriff auf die Images der Virtual Machines, die Kernel Images, die RAM Disk Images und die Daten der Benutzer verwendet. Die Images der Virtual Machines können rein privat oder öffentlich zugänglich gemacht werden und können dabei komprimiert und verschlüsselt gespeichert werden. Die Images werden lediglich entschlüsselt, wenn ein Node eine neue virtuelle Instanz starten muss und dazu einen Zugriff auf das Image benötigt.

Das Clustersystem

Ein Eucalyptus System vereint und verwaltet Ressourcen von Single-Cluster als auch Multi-Cluster Systemen. Dabei besteht ein Cluster aus einer Gruppe von Rechnern, die alle mit dem selben LAN verbunden sind. Zu jedem Cluster kann wiederum einer aber auch mehrere Node Controller gehören, die für die Verwaltung der Instantiierung und Beendigung der virtuellen Instanzen verantwortlich sind.

Ein Single-Cluster besteht aus mindestens zwei Maschinen. Auf dem einen werden der Cluster Controller, der Storage Controller und der Cloud Controller ausgeführt, auf dem anderen der Node Controller. Diese Art der Konfiguration ist vor allem für Experimente und schnelle Konfigurationen geeignet. Die dargestellte Konfiguration könnte ebenfalls auf einer einzigen Maschine implementiert werden. Allerdings ist dafür eine äußerst leistungsstarke Hardware notwendig!

Bei einem Multi-Cluster wird jede Komponente (CC, SC, NC, und CLC) auf einer separaten Maschine ausgeführt. Dies sollte die bevorzugte Art und Weise sein das Eucalyptus System zu konfigurieren, wenn damit ernsthaft gearbeitet werden soll. Mit einem Multi-Cluster kann zudem die Performance erhöht werden, indem einem Controller die passende Maschine zugewiesen wird. Zum Beispiel sollte der Cloud Controller auf einer Maschine mit einer schnellen CPU ausgeführt werden. Im Allgemeinen bringt die Entscheidung für einen Multi-Cluster eine höhere Verfügbarkeit, sowie eine bessere Lastverteilung und eine optimierte Verteilung der Ressourcen über alle Cluster. Das Clusterkonzept ist vergleichbar mit dem Konzept der Verfügbarkeitszonen der Amazon EC2. Dabei werden die Ressourcen über mehrere Verfügbarkeitszonen hinweg verteilt, damit ein Fehler in einer Zone nicht die Anwendung beeinträchtigt.

Eucalyptus und die Ubuntu Enterprise Cloud

Bei der Ubuntu Enterprise Cloud (UEC) handelt es sich um eine Open Source Initiative von Ubuntu, um auf eine einfachere Art und Weise skalierbare Cloud Infrastrukturen auf Basis von Eucalyptus bereitzustellen und diese zu konfigurieren.

Mit der Ubuntu Enterprise Cloud können Public Clouds erstellt werden, welche Amazon's EC2 infrastructure nutzen. Es können damit aber genau so gut Private Clouds entwickelt werden, die auf der eigenen Infrastruktur im eigenen Rechenzentrum hinter der eigenen Firewall gehostet werden.

Vorteile von Eucalyptus

Bei Eucalyptus handelt es sich um eine Umgebung für Cloud Services, mit der Public Clouds auf Amazon's EC2 Infrastruktur bzw. Private Clouds im hauseigenen Rechenzentrum erstellt werden können. Die grundlegenden Vorteile sollen hier noch einmal kurz aufgeführt werden:

  • Open Source und Entwicklung
    Eucalyptus wurde geschaffen, um die Kommunikation und Forschung von Cloud Computing Plattformen zu fördern. Der Quellcode ist frei verfügbar, was es ermöglicht die Plattform so zu erweitern, damit sie den eigenen Anforderungen entspricht. Eucalyptus wird zunehmend weiterentwickelt. Darüber hinaus ist die Aufnahme und Integration von Funktionswünschen und Verbesserungsvorschlägen sehr schnell.
  • Community
    Eucalyptus verfügt über eine große Community die gerne bereit ist einander zu helfen. Über die Foren kann schnell Kontakt zu anderen Benutzern aufgenommen und Hilfe bezogen werden.
  • Public Cloud
    Eucalyptus funktioniert einwandfrei auf Amazon's EC2 Framework und kann damit als Public Cloud eingesetzt werden.
  • Private Cloud
    Eucalyptus kann auf der eigenen Infrastruktur im eigenen Rechenzentrum hinter der eigenen Firewall als Private Cloud eingesetzt werden. Dadurch ist die Kontrolle bzgl. der Sicherheit und der gesamten Umgebung in der eigenen Hand.
  • Portabilität
    Auf Grund der Kompatibilität von Eucalyptus mit Amazon's EC2 API sowie der Flexibilität von Eucalyptus, können Anwendungen ohne großen Aufwand von einer Cloud in die andere migriert werden. Darüber hinaus besteht die Möglichkeit des Aufbaus von Hybrid Clouds, indem eine Private Cloud mit einer Public Cloud erweitert bzw. kombiniert wird.
  • Qualitativ durch Tests
    Durch den Einsatz von Eucalyptus in Ubuntu's Enterprise Cloud findet tagtäglich ein weltweiter realer Test auf Basis von mehr als tausend Server-Instanzen statt.
  • Kommerzieller Support
    Neben den Foren der Eucalyptus Community kann natürlich auch auf einen kommerziellen Support zurückgegriffen werden.

Open Nebula

OpenNebula ist ein Open Source Virtual Infrastructure Manager mit dem aus vorhandenen Rechenzentren jede Art von Cloud Computing Umgebung aufgebaut und bereitgestellt werden kann. In erster Linie dient OpenNebula als Tool zur Verwaltung der virtualisierten Infrastruktur des eigenen Rechenzentrums bzw. der eigenen Cluster, also der eigenen Private Cloud.

Darüber hinaus ist OpenNebula in der Lage Hybrid Clouds aufzubauen, also die eigene lokale Infrastruktur mit einer Public Cloud Infrastruktur zu verbinden/kombinieren, um die Skalierbarkeit der eigenen Umgebung noch weiter zu erhöhen. OpenNebula verfügt zusätzlich über spezielle Schnittstellen für die Verwaltung von virtuellen Maschinen, Speicherplatz und des Netzwerks von Public Clouds.

Funktionen

Private Cloud Computing

  • Internal Interfaces for Administrators and Users
    Mit einer Unix ähnlichen Kommandozeile und einer XML-RPC API kann der Lebenszyklus der virtuellen Maschinen und physikalischen Server verwaltet werden. Weitere Administrationsmöglichkeiten bietet die libvirt API.
  • Steuerung
    Die Verwaltung der Arbeitslast und Zuweisung der Ressourcen kann nach bestimmten Regeln wie z.B. der aktuellen Auslastung automatisch vorgenommen werden. Des Weiteren wird der Haizea VM-based lease manager unterstützt
  • Virtualisierungsmanagement
    Es existieren Konnektoren für Xen, KVM und VMware, sowie einem generischen libvirt Konnektor für weitere Virtual Machine Manager. Die Unterstützung von Virtual Box ist in Planung.
  • Image Management
    Es sind Funktionen für den Transfer und das Clonen von Virtual Machine Images vorhanden.
  • Netzwerk Management
    Es lassen sich isolierte virtuelle Netze festlegen um virtuelle Maschinen miteinander zu verbinden.
  • Service Management
    Unterstützung von Multi Tier Services bestehend aus Gruppen von miteinander verbundenen virtuellen Maschinen und deren Auto Konfiguration während des Boot Vorgangs.
  • Sicherheit
    Die Verwaltung der Benutzer wird durch den Administrator der Infrastruktur vorgenommen.
  • Fehlertoleranz
    Eine persistente Datenbank dient zum Speichern aller Informationen der Hosts und virtuellen Maschinen.
  • Skalierbarkeit
    Tests zeigten bisher, das OpenNebula mehrere hundert Server und virtuelle Maschinen verwalten kann.
  • Installation
    Die Installation erfolgt auf einem UNIX Cluster Front-End ohne das weitere Services benötigt werden. OpenNebula wird mit Ubuntu 9.04 (Jaunty Jackalope) ausgeliefert.
  • Flexibilität und Erweiterbarkeit
    Die Architektur, Schnittstellen und Komponenten sind offen, flexibel und erweiterbar. Dadurch kann OpenNebula mit jedem aktuellen Produkt aus dem Bereich Virtualisierung, Cloud Computing oder Management Tool für Rechenzentren integriert werden.

Hybrid Cloud Computing

  • Cloud Plugins
    Konnektoren für Amazon EC2 und ElasticHosts.
  • Zusammenschluss
    Unterstützung für den gleichzeitigen Zugriff auf mehrere Remote-Clouds.
  • Erweiterbarkeit
    Modulare Konzepte für die Entwicklung neuer Konnektoren.

Public Cloud Computing

  • Cloud Schnittstellen für Benutzer
    Implementierung einer Teilmenge der Amazon EC2 Query API und der OGF OCCI API
  • Erweiterbarkeit
    Die OpenNebula Cloud API ermöglicht die Implementierung neuer/weiterer Cloud Schnittstellen.

OpenStack

OpenStack ist ein weltweites Gemeinschaftsprojekt von Entwicklern und Cloud Computing Spezialisten, die das Ziel verfolgen eine Open Source Plattform für den Aufbau von Public und Private Clouds zu entwickeln. Das Projekt wurde initial von der Nasa und Rackspace gegründet und will Anbietern von Cloud Infrastrukturen ein Werkzeug in die Hand geben, mit dem sie unterschiedliche Arten von Clouds ohne großen Aufwand auf Standard Hardwarekomponenten aufbauen und bereitstellen können.

Der gesamte OpenStack Quellcode ist frei verfügbar und unterliegt der Apache 2.0 Lizenz. Dadurch ist jeder in der Lage auf dieser Basis seine eigene Cloud zu entwickeln und ebenfalls Verbesserungen in das Projekt zurückfließen zu lassen. Der Open Source Ansatz des Projekts soll zudem die Entwicklung von Standards im Bereich des Cloud Computing weiter fördern, Kunden die Angst vor einem Vendor Lock-in nehmen und ein Ecosystem für Cloud Anbieter schaffen.

OpenStack besteht derzeit aus insgesamt sechs Kernkompenten und wird stetig weiterentwickelt. OpenStack Compute, OpenStack Object Storage und OpenStack Image Service, OpenStack Identity, OpenStack Dashboard und OpenStack Networking.

Man muss sich allerdings darüber im Klaren sein, dass es sich bei OpenStack um kein fertiges Produkt handelt, das sofort einsatzfähig ist, sondern um einzelne Teilprojekte die selbst ineinander integriert und für die eigenen Bedürfnisse angepasst werden müssen. Es gibt aber mittlerweile fertige OpenStack Installationsroutinen von Mitgliedern des OpenStack Projekts.

OpenStack Compute

OpenStack Compute dient dem Aufbau, Bereitstellen und Verwalten von großen Virtual Machine Clustern, um auf dieser Basis eine redundante und skalierbare Cloud Computing Plattform zu errichten. Dazu stellt OpenStack Compute diverse Kontrollfunktionen und APIs zur Verfügung, mit denen Instanzen ausgeführt und Netzwerke verwaltet werden sowie die Zugriffe der Nutzer auf die Ressourcen gesteuert werden können. OpenStack Compute unterstützt zudem eine große Anzahl von Hardwarekonfigurationen und sieben Hypervisor.

OpenStack Compute kann bspw. Anbietern dabei helfen Infrastructure Cloud Services bereitzustellen oder IT-Abteilungen ermöglichen ihren internen Kunden und Projekten Ressourcen bei Bedarf zur Verfügung zu stellen. Zudem können große Datenmengen (Big Data) mit Tools wie Hadoop verarbeitet werden oder Web Anwendungen entsprechend ihrer Ressourcenbedürnisse bedient werden.

OpenStack Object Storage

Mit OpenStack Object Storage können auf Basis von standardisierten Servern redundante und skalierbare Object Storage Cluster mit einer Größe von bis zu 1 Petabyte aufgebaut werden. Dabei handelt es sich nicht um ein Dateisystem und ist nicht für das Speichern von Echtzeitdaten ausgelegt, sondern für das langfristige Speichern von statischen Daten gedacht, die bei Bedarf abgerufen oder aktualisiert werden können. Gute Anwendungsbeispiele für OpenStack Object Storage sind das Speichern von Virtual Machine Images, Photos, E-Mails, Backupdaten oder Archivierung. Da der Object Storage dezentral verwaltet wird, verfügt er über eine hohe Skalierbarkeit, Redundanz und Beständigkeit der Daten.

Die OpenStack Software sorgt dafür, dass die Daten auf mehrere Speicherbereiche im Rechenzentrum geschrieben werden, um damit die Datenreplikation und Integrität innerhalb des Clusters sicherzustellen. Die Storage Cluster skalieren dabei horizontal, indem weitere Knoten bei Bedarf hinzugefügt werden. Sollte ein Knoten ausfallen, sorgt OpenStack dafür, dass die Daten von einem aktive Knoten repliziert werden.

OpenStack Object Storage kann von Anbietern genutzt werden, um einen eigenen Cloud Storage bereizustellen oder die Server Images von OpenStack Compute zu speichern. Weitere Anwendungsfälle wären Dokumentenspeicher, eine Back-End Lösung für Microsoft SharePoint, eine Archivierungsplattform für Logdateien oder für Daten mit langen Aufbewahrungsfristen oder einfach nur zum Speichern von Bildern für Webseiten.

OpenStack Image Service

Der OpenStack Image Service hilft bei der Suche, Registrierung und dem Bereitstellen von virtuellen Maschinen Images. Dazu bietet der Image Service eine API mit einer Standard REST Schnittstelle, mit der Informationen über das VM Image abgefragt werden können, welches in unterschiedlichen Back-Ends abgelegt sein kann, darunter OpenStack Object Storage. Clients können über den Service neue VM Images registrieren, Informationen über öffentlich verfügbare Images abfragen und über eine Bibliothek ebenfalls darauf zugreifen.

Der OpenStack Image Service unterstützt eine Vielzahl an VM Formaten für private und öffentliche Images, darunter Raw, Machine (kernel/ramdisk, z.B. AMI), VHD (Hyper-V), VDI (VirtualBox), qcow2 (Qemu/KVM), VMDK (VMWare) und OVF (VMWare).

OpenStack Identity

Der OpenStack Identity Service stellt eine zentrale Authentifizierung über alle OpenStack Projekte bereit und integriert sich in vorhandene Authentifizierungs-Systeme.

OpenStack Dashboard

Das OpenStack Dashboard ermöglicht Administratoren und Anwendern den Zugang und die Bereitstellung von Cloud-basierten Ressourcen durch ein Self-Service Portal.

OpenStack Networking

OpenStack Networking ist ein skalierbares und API basierendes System für die Verwaltung von Netzwerken und IP-Adressen.


CloudStack

CloudStack wurde ursprünglich von Cloud.com entwickelt. Nach der Übernahme durch Citrix Systems im Jahr 2011 wurde Citrix zum Hauptsponsor von CloudStack. Die Open-Source Cloud Plattform basiert auf Java und hilft beim Aufbau und der Verwaltung von skalierbaren Infrastrukturen. Zu den aktuell unterstützten Hypervisorn gehören VMware, Oracle VM, KVM, XenServer und die Xen Cloud Platform. Neben einer eigenen RESTful API implementiert CloudStack ebenfalls die Amazon EC2 und S3 APIs sowie VMwares vCloud API. Die Cloud-Infrastruktur kann entweder über die Web-Oberfläche, einer Kommandozeile oder die API konfiguriert und verwaltet werden.

CloudStack besteht aus fünf Kernkomponenten. Der Compute Controller verwaltet die Rechenleistung, der Network Controller steuert das virtuelle Netzwerk und der Storage Controller ist für die Speicherverwaltung des BlockStorage zuständig. Alle drei Komponenten haben direkten Kontakt mit der physikalische Hardware. Auf diesen Komponenten setzt die CloudStack Orchestration Engine auf, die für den Aufbau, die Steuerung und Verwaltung der CloudStack Infrastruktur verantwortlich ist. Über der Orchestration Engine befindet sich als letzte Komponente die CloudStack API, die mit der Web-Oberfläche, Kommandozeile oder über REST interagiert und die Befehle an die Orchestration Engine weitergibt.

Citrix Systems ist nicht das einzige bekannte Unternehmen, was CloudStack unterstützt. Weitere Supporter des CloudStack Projekts sind RightScale, PuppetLabs, Juniper Networks, Enstratus, TrendMicro, Intel und Equinix.


Bildquelle: ©Gerd Altmann / PIXELIO



Der KOALA Cloud Manager

Derzeit existieren drei unterschiedliche Arten bzw. Tools wie Cloud Computing Infrastrukturen gesteuert und verwaltet werden können, SaaS-Lösungen, Browser Plugins und Kommandozeilentools. Diese haben je nach Einsatzgebiet ihre Vor- und Nachteile.

So ist die AWS Management Console sehr proprietär und kann ausschließlich dazu genutzt werden, um die AWS Infrastruktur zu verwalten. Angebote wie bspw. Rightscale, Enstratus und Ylastic sind kostenpflichtig zu nutzen und unterstützen darüber hinaus nicht alle Cloud Infrastrukturen am Markt. Hinzu kommt, dass bei diesen Drittanbietern sämtliche Zugangsdaten für den Zugriff auf die Cloud Infrastrukturen hinterlegt werden müssen, was das Vertrauen in den Anbieter voraussetzt.

Betrachten wir die Browser Plugins, existieren derzeit nur wenig nennenswerte, wie bspw. Elasticfox oder Hybridfox, die jedoch ausschließlich für den Firefox verfügbar sind. Darüber hinaus muss hier eine lokale Installation erfolgen, die regelmäßigen Updates unterzogen werden muss, wenn sich Eigenschaften an der zu verwaltenden Cloud Infrastruktur vorgenommen ändern.

Die letzte Kategorie sind die Kommandozeilentools. Die EC2 API Tools unterstützen lediglich die AWS Cloud. Die Euca2ools der Eucalyptus Cloud hingegen bereits sich selbst und die AWS Cloud API. Auch hier ist eine lokale Installation erforderlich und die Administration per Kommandozeile ist heutzutage auch nicht mehr jedermanns Sache!

Eine mögliche Lösung?

Der KOALA (Karlsruhe Open Application (for) cLoud Administration) Cloud Manager möchte bei allen oben genannten Problemen Abhilfe verschaffen. Dabei handelt es sich um einen Cloud Service, der IaaS Nutzern dabei helfen soll, Amazon Web Services (AWS) kompatible Cloud Services und Cloud Infrastrukturen zentralisiert zu verwalten. Dazu unterstützt KOALA die AWS Public Cloud Services sowie die Private Cloud Infrastrukturen Eucalyptus, Nimbus und OpenNebula. Darüber hinaus werden die Cloud Storage Services von Google und Host Europe unterstützt. (Anmerkung der Redaktion: Da der Host Europe Cloud Storage auf der Cloud Storage Technology von Scality basiert, sollte KOALA ebenfalls weitere Cloud Storage Services unterstützen.)

KOALAs ist in der Lage mit Cloud Services zu kommunizieren, welche die APIs der Elastic Compute Cloud (EC2), des Simple Storage Service (S3), des Elastic Block Store (EBS) und des Elastic Load Balancing (ELB) implementieren. Der Benutzer kann mit KOALA Instanzen starten, stoppen und monitoren sowie Volumes und Elastic IP Addresses verwalten. Darüber hinaus können Buckets in Amazon S3, S3-kompatiblen Storage Services wie Walrus und Google Storage erstellt und gelöscht werden. Die Verwaltung ist hier vergleichbar mit dem S3Fox oder dem Google Storage Manager.

Der KOALA Cloud Manager selbst wurde als Service in Python für die Google App Engine entwickelt und kann entweder auf der App Engine direkt (Public Cloud) oder als Private Cloud Variante innerhalb eines App Engine kompatiblen Dienstes wie AppScale oder typhoonAE betrieben werden. AppScale als auch typhoonAE können dabei entweder innerhalb einer Public Cloud wie Amazon EC2 oder einer Private Cloud wie Eucalyptus genutzt werden, um bspw. Sicherheits- und Datenschutz-Bedenken vorzubeugen.

Der KOALA Cloud Manager kann kostenlose genutzt werden. Der Quellcode steht unter der Apache License, Version 2.0. und ist somit Open Source.

Weitere Infos unter http://koalacloud.appspot.com.



OpenNebula: Der Aufbau einer Private Cloud

Was ist eine Private Cloud?

Das Ziel einer Private Cloud besteht nicht darin, der Öffentlichkeit eine Schnittstelle zur Cloud zur Verfügung zu stellen. um damit eigene Kapazitäten über der Internet anzubieten. Es geht vielmehr darum, seinen eigenen lokalen Nutzern eine flexible und agile private Infrastruktur bereitzustellen, in der die genutzten Services virtualisiert innerhalb eines selbst administrierten Bereich ausgeführt werden, um die Belastung effizient aufzuteilen. Die virtuelle Infrastruktur-Schnittstelle von OpenNebula stellt den Administratoren Funktionen für die Virtualisierung, die Netzwerkverwaltung, die Konfiguration von Images und physischen Ressourcen, das Management, sowie dem Monitoring und dem Accounting.

Die Sicht des Benutzers

Mit einer OpenNebula Private Cloud steht Nutzern der Infrastruktur eine elastische Plattform zum schnellen Bereitstellen und Skalieren von Services bereit, um den dynamischen Anforderungen gerecht zu werden. Die virtuelle Infrastruktur-Schnittstelle bietet folgenden Möglichkeiten, um Services auf virtuellen Maschinen zu hosten, bereitzustellen, sowie zu kontrollieren und zu überwachen.

  • Kommandozeile
  • XML-RPC API
  • Libvirt Virtualization API inkl. Management Tools

Die folgenden Beispiele zeigen die Funktionalität, die von der OpenNebula Kommandozeile bereitgestellt wird, um eine Private Cloud zu verwalten.

Zunächst überprüfen wir den Host und den physikalischen Cluster:

$ onehost list
 HID NAME                      RVM   TCPU   FCPU   ACPU    TMEM    FMEM STAT
   0 host01                      0    800    800    800 8194468 7867604   on
   1 host02                      0    800    797    800 8387584 1438720   on

Anschließend kann mittels onevm eine virtuelle Maschine an OpenNebula übertragen werden. Dazu wird als erstes ein Template einer virtuellen Maschine benötigt, aus dem ein Image erstellt wird. Das Image wird in dem Verzeichnis /opt/nebula/images abgelegt.

CPU    = 0.5
MEMORY = 128
OS     = [
  kernel   = "/boot/vmlinuz-2.6.18-4-xen-amd64",
  initrd   = "/boot/initrd.img-2.6.18-4-xen-amd64",
  root     = "sda1" ]
DISK   = [
  source   = "/opt/nebula/images/disk.img",
  target   = "sda1",
  readonly = "no" ]
DISK   = [
  type     = "swap",
  size     = 1024,
  target   = "sdb"]
NIC    = [ NETWORK = "Public VLAN" ]

Nachdem die virtuelle Maschine z.B. bzgl. der CPU und des Arbeitsspeichers auf die eigenen Bedürfnisse angepasst wurde, kann diese übertragen werden.

$ onevm submit myfirstVM.template

Nach dem Übertragen der virtuellen Maschine erhalten wir eine ID, mit welcher die virtuelle Maschine identifiziert werden kann, um diese zu überwachen und zu steuern. Die ID erhalten wir mit dem folgenden Befehl:

$ onevm list
  ID     USER     NAME STAT CPU     MEM        HOSTNAME        TIME
   0 oneadmin    one-0 runn   0   65536          host01  00 0:00:02

Das Feld STAT beschreibt den aktuellen Status der virtuellen Maschine. Befindet sich dieser im Status runn, ist die virtuelle Maschine online und wird ausgeführt. Abhängig davon, wie das Image konfiguriert wurde, haben wir Kenntnis von der IP-Adresse, wodurch wir uns auf der virtuellen Maschine anmelden können.

Um eine Migration durchzuführen, verwenden wir erneut den onevm Befehl. Wenn wir z.B. die virtuelle Maschine (VID=0) nach host02 (HID=1) übertragen wollen, nutzen wir:

$ onevm livemigrate 0 1

Damit wird die virtuelle Maschine von host01 nach host02 übertragen. Der Befehl onevm list sollte eine ähnliche Ausgabe der Folgenden anzeigen:

$ onevm list
  ID     USER     NAME STAT CPU     MEM        HOSTNAME        TIME
   0 oneadmin    one-0 runn   0   65536          host02  00 0:00:06

Wie das System funktioniert

OpenNebula - Eigenschaften

  • Verwaltung virtueller Netzwerke: Virtuelle Netzwerke verbinden die einzelnen virtuellen Maschinen.
  • Erstellen virtueller Maschinen: Die Beschreibung jeder einzelnen virtuellen Maschine wird der Datenbank hinzugefügt.
  • Bereitstellen virtueller Maschinen: Der Scheduler entscheided auf Basis von Richtlinien, wo eine virtuelle Maschine ausgeführt wird.
  • Verwaltung virtueller Maschinen Images: Vor dem Ausführen werden die virtuellen Maschinen Images zu dem Host übertragen und SWAP Disk Images erstellt. Nach dem Ausführen werden die virtuellen Maschinen Images in das Repository zurückkopiert.
  • Verwaltung gestarteter virtueller Maschinen: Virtuelle Maschinen werden gestartet und der aktuelle Status periodisch abgefragt. Zudem können die virtuellen Maschinen heruntergefahren, angehalten, gestopped und migriert werden.

OpenNebula Private Cloud - Die wichtigsten Komponeten

  • Hypervisor: Der Virtualisierungsmanager - auf den Ressourcen des Clusters installiert, die OpenNebula für die Verwaltung der virtuellen Maschinen vorgesehen hat.
  • Virtual Infrastructure Manager: Zentrale Verwaltungseinheit zum Steuern und Überwachen der virtuellen Maschinen und Ressourcen. Unterstützt weiterhin die Verwaltung der virtuellen Netzwerke, das Life-Cycle Management der virtuellen Maschinen, das Management der virtuellen Maschinen Images sowie die Fehlertoleranz.
  • Scheduler: Verwaltung der Richtlinien für die virtuellen Maschinen hinsichtlich der gleichmäßigen Verteilung der Last, Server Konsolidierung, Zugehörigkeit, Reservierung der Kapazitäten und SLAs

Quelle

  • Building a Private Cloud


OpenNebula: Der Aufbau einer Public Cloud

Was ist eine Public Cloud?

Eine Public Cloud ist die Erweiterung einer Private Cloud, die eine RESTful Cloud Schnittstelle bereitstellt. Cloud Schnittstellen können sowohl zu einer Private als auch zu einer Hybrid Cloud hinzugefügt werden, um z.B. Partnern oder extern Benutzer den Zugriff auf die eigene Infrastruktur zu ermöglichen, oder um eigene Überkapazitäten zu verkaufen. Somit ist eine lokale Cloud Lösung das natürliche Back-End für eine Public Cloud.

Die Sicht des Benutzers

Die folgenden Schittstellen stellen eine einfache Möglichkeit für das Remote Management von Cloud Ressourcen dar.

  • EC2 Query subset
  • RESERVOIR Cloud Interface und OGF OCCI

Benutzer haben die Möglichkeit, Befehle zu verwenden, welche die Funktionalität der Amazon EC2 Services abbilden. Mit drei einfachen Befehlen kann ein bereits vorinstalliertes Betriebssystem (als vorhandene .img Datei) in der Cloud gestartet werden.

Zunächst muss das Image hochgeladen werden:

$ ./econe-upload /images/gentoo.img
Success: ImageId 872ce740-5904-012c-08e0-0017f231be96

Nachdem das Image in das OpenNebula Repository hochgeladen wurde, muss dieses für die Nutzung in der Cloud registriert werden:

$ ./econe-register 872ce740-5904-012c-08e0-0017f231be96
Success: ImageId 872ce740-5904-012c-08e0-0017f231be96

Anschließend kann das registrierte Image in der Cloud gestartet und ausgeführt werden:

$ ./econe-run-instances -H 872ce740-5904-012c-08e0-0017f231be96
Owner       ImageId                                InstanceId InstanceType
------------------------------------------------------------------------------
helen       872ce740-5904-012c-08e0-0017f231be96   15         m1.small

Weiterhin kann die ausgeführte Instanz überwacht werden:

$ ./econe-describe-instances  -H
Owner       Id    ImageId                               State         IP              Type
------------------------------------------------------------------------------------------------------------
helen       15    872ce740-5904-012c-08e0-0017f231be96  pending       147.96.80.33    m1.small  

Wie das System funktioniert

Es müssen keine Änderung an der Funktionsweise von OpenNebula vorgenommen werden, um Cloud Schnittstellen bereitzustellen. Benutzer können sich mit der Infrastruktur verbinden, indem sie eine Private oder Public Cloud Schnittstelle verwenden.

Quelle

  • Building a Public Cloud


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




Installation einer Private Cloud mit OpenNebula

Dieser Artikel beschreibt das Einrichten einer Private Cloud mit OpenNebula auf Ubuntu. Die Infrastruktur besteht dabei aus drei physikalischen Maschinen. Einem Front-End und zwei Nodes, auf denen die virtuellen Maschinen ausgeführt werden. Auf den Nodes muss zusätzlich eine Bridge konfiguriert werden, damit die virtuellen Maschinen das lokale Netzwerk erreichen können. Für das Einrichten der Brigde siehe den Bereich Bridging.

Installation

Auf dem System für das Front-End installieren wir OpenNebula mit folgendem Befehl:

sudo apt-get install opennebula

Für jeden Node installieren wir den OpenNebula-Node:

sudo apt-get install opennebula-node

Um später die SSH Schlüssel zu kopieren, benötigt der oneadmin (wird von OpenNebula erstellt) ein Passwort. Dazu führen wir auf jeder Maschine folgenden Befehl aus:

sudo passwd oneadmin

Nachfolgend müssen die Namen für node01 und node02 entsprechend der eigenen Installation angepasst werden.

Nun kopieren wir den SSH Schlüssel des oneadmin auf jeden Node und in die Datei authorized_keys des Front-Ends.

sudo scp /var/lib/one/.ssh/id_rsa.pub oneadmin@node01:/var/lib/one/.ssh/authorized_keys
sudo scp /var/lib/one/.ssh/id_rsa.pub oneadmin@node02:/var/lib/one/.ssh/authorized_keys
sudo sh -c "cat /var/lib/one/.ssh/id_rsa.pub >> /var/lib/one/.ssh/authorized_keys"

Der SSH Schlüssel jedes Nodes muss in die Liste der bekannten Hosts unter /etc/ssh/ssh_known_hosts auf dem Front-End hinzugefügt werden. Nun muss die SSH Session beendet werden und der SSH Schlüssel von ~/.ssh/known_hosts nach /etc/ssh/ssh_known_hosts kopiert werden.

sudo sh -c "ssh-keygen -f .ssh/known_hosts -F node01 1>> /etc/ssh/ssh_known_hosts"
sudo sh -c "ssh-keygen -f .ssh/known_hosts -F node02 1>> /etc/ssh/ssh_known_hosts"

Diese Schritte erlauben dem oneadmin SCP ohne ein Passwort oder manuellen Eingriff zu nutzen, um eine Image auf den Nodes bereitzustellen.

Auf dem Front-End muss ein Verzeichnis zum Speichern der Images für die virtuellen Maschinen erstellt und dem oneadmin Zugriff auf das Verzeichnis gegeben werden.

sudo mkdir /var/lib/one/images
sudo chown oneadmin /var/lib/one/images/

Nun kann eine virtuelle Maschine in das Verzeichnis /var/lib/one/images kopiert werden.

Eine virtuelle Maschine auf Basis von Ubuntu kann mit dem vmbuilder erstellt werden, siehe dazu JeOS and vmbuilder.

Konfiguration

Der OpenNebula Cluster kann nun konfiguriert werden. Weiterhin können virtuelle Maschinen dem Cluster hinzugefügt werden.

Auf dem Front-End geben wir dazu folgenden Befehl ein:

onehost create node01 im_kvm vmm_kvm tm_ssh
onehost create node02 im_kvm vmm_kvm tm_ssh

Als nächstes erstellen wir eine Template-Datei mit dem Namen vnet01.template für das virtuelle Netzwerk:

NAME = "LAN"
TYPE = RANGED
BRIDGE = br0
NETWORK_SIZE = C
NETWORK_ADDRESS = 192.168.0.0

Die NETWORK_ADDRESS sollte dem eigenen lokalen Netzwerk entsprechen.

Mit dem onevnet Befehl fügen wir das virtuelle Netzwerk OpenNebula hinzu:

onevnet create vnet01.template

Jetzt erstellen wir eine Template-Datei für eine virtuelle Maschine mit dem Namen vm01.template:

NAME = vm01

CPU = 0.5
MEMORY = 512

OS = [ BOOT = hd ]

DISK = [
source = "/var/lib/one/images/vm01.qcow2",
target = "hda",
readonly = "no" ]

NIC = [ NETWORK="LAN" ]

GRAPHICS = [type="vnc",listen="127.0.0.1",port="-1"]

Mit dem Befehl onevm starten wir die virtuelle Maschine:

onevm submit vm01.template

Mit dem Befehl onevm list können wir weitere Informationen über die gestarteten virtuellen Maschinen abfragen. Mit dem Befehl onevm show vm01 erhalten wir detaillierte Informationen zu einer bestimmten virtuellen Maschine.

Quelle



Eigenschaften einer Cloud Platform

Ich habe bisher einige Cloud Computing Plattformen, darunter openQRM, OpenNebula oder OpenECP vorgestellt und ein paar weitere werden noch folgen. Daher erläutere ich in diesem Artikel die grundsätzlichen Eigenschaften die eine Cloud Plattform (meiner Meinung nach) hat bzw. haben sollte.

1. Zunächst sollten ausreichend virtualisierte Serverressourcen zur Verfügung stehen. Weiterhin müssen, (vor allem dann) wenn sich mehrere Kunden auf einem System befinden, jedem Kunden diese virtualisierten Serverressourcen garantiert werden und die einzelnen virtuellen Instanzen isoliert und damit vollständig von einander getrennt betrieben werden.

2. Zum Bereitstellen von umfangreichen Enterprise-Class-Services wie z.B. hohe Verfügbarkeit, Systemwiederherstellungen nach Datenverlusten, automatische Skalierung während Lastspitzen und Ressourcenoptimierungen muss eine große (unbegrenzte) Menge an virtualisierten Serverressourcen vorhanden sein.

3. Für ein zustandsbehaftetes Lifecycle Management, wozu Snapshots, schnelles Cloning (duplizieren) und eine dynamische Versorgung mit Ressourcen über große Server Infrastrukturen gehören, wird ein virtualisierter Cloud Speicher benötigt.

4. Für die Anpassung der virtuellen Topologie - durch das Hinzufügen weiterer Netzwerkfunktionen für Sicherheit, Routing, Load Balancing, Application Firewalls, Protokol Optimierung, etc. in den OSI Schichten 3 bis 7 - und die Möglichkeit die jeweiligen (Teil)-Netzwerke auf Multi-Kunden Systemen zu isolieren und Ressourcen zu garantieren, werden virtuelle Netzwerk Ressourcen benötigt.

5. Es müssen umfangreiche und offene APIs zur Kontrolle sämtlicher Ressourcen vorhanden sein, damit Cloud Computing Anbieter ihren Kunden die vollständige Kontrolle über deren privaten virtuellen Rechenzentren anbieten können.

6. Die Cloud Plattform muss für allen gängigen Virtualisierungs-Plattformen vollständige Kompatibilität bieten und jede virtuelle Maschine unterstützen, um u.a. einen Vendor Lock-in zu vermeiden. Des Weiteren müssen Funktionen für die Migration von virtuellen Maschinen zwischen unterschiedlichen Virtualisierungs-Technologien (P2V, V2P und V2V) vorhanden sein.

7. Zu guter letzt sollte die Cloud Plattform auf Open Source basieren, um eine größtmögliche Kompatibilität zu allen möglichen Clouds aufzuweisen und um einfach adaptiert und angenommen zu werden.



Die Xen Cloud Platform

In diesem Artikel stelle ich die Xen Cloud Platform (XCP) vor, die im August 2009 erstmals veröffentlicht wurde. Dabei handelt es sich um eine Initiative, mit der eine vollständige Open Source Lösung auf Basis einer von der Industrie unterstützenden API für Cloud Anbieter zur Verfügung stehen soll. Mit einer XCP Infrastruktur sollen andere Open Source Projekte wie z.B. Eucalyptus, Convirture, OpenNebula, OpenXenCenter, Xen VNC Proxy, und Nimbus in der Lage sein den Xen Hypervisor besser nutzen zu können, in dem die neue API speziell auf das Cloud Computing ausgerichtet ist.

Die Xen Cloud Platform versteht sich als eine Kombination der Eigenschaften der Xen Virtualisierung Platform (Mobilität, Offenheit, Isolation und der Möglichkeit mehrere Instanzen parallelen auszuführen) mit neuen und verbesserten Speicher-, Sicherheits- und Netzwerk- Virtualisierungstechnologien. Damit soll eine Vielzahl von virtuellen Infrastruktur Cloud Services angeboten werden können. Darüber hinaus werden Anforderungen bzgl. der Sicherheit, Verfügbarkeit, Performance und Isolation von Hybrid Clouds erfüllt.

Aktuelle Funktionen

  • Xen 3.4.1
  • Linux 2.6.27 Kernel
  • Windows PV Treiber, Microsoft Zertifiziert
  • XAPI Enterprise-class Management Tool Stack
    • Lebenszyklus einer virtuellen Maschine: Live Snapshots, Checkpoint, Migration
    • Ressourcen Pools: Sichere Neuverteilung (Live), Autokonfiguration, DR
    • Host Konfiguration: Flexibles Speichermanagement, Netzwerkbetrieb, Power Management
    • Verfolgen von Ereignissen: Fortschritt, Benachrichtigung
    • Sichere Kommunikation durch SSL
    • Möglichkeit für Upgrades und Patching
    • Überwachung und Benachrichtung bzgl. der Perfomance in Echtzeit
  • Unterstützung von Single-Root I/O Virtualization
  • Installation des Host per CD-ROM und Netzwerk
  • Vollständige "xe" Kommandozeile und Web Service API
  • Openvswitch
  • Fehlertoleranz (Marathon FT products)
  • VNC Console Proxy und Web Front-End
  • Unabhängiges Front-End

Roadmap für XCP 1.0

  • VSwitch Integration
    Mehrere Nutzer einer Netzwerkinfrastruktur; Übernahme der Firewall- und Routingregeln von migrierten virtuellen Maschinen; Flexible Überwachung des Datenverkehrs von virtuellen Ports
  • Netchannel 2 Integration
    Verbesserung der Skalierbarkeit der Xen Vernetzung auf größeren Systemen; Beschleunigung des Datenverkehrs zwischen virtuellen Maschinen
  • Single-Root I/O Virtualization (SR-IVO) Vernetzung
    Xen unterstützt bereits SR-IVO Netzwerkkarten, allerdings müssen diese noch manuell konfiguriert werden.
  • Starten der Gast Systeme von SR-IOV Host-Bus-Adapters (HBAs)
  • Libvirt bindings
  • Native Unterstützung für das Open Virtualization Format (OVF)
  • DMTF (Distributed Management Task Force) Standards für Virtualisierung und Cloud
  • Intelligente Fehlerbehebung um die Auswirkungen von Hardware-Fehlern zu minimieren
  • Unterstützung von Web-basierten Management mehrere Nutzer für unterschiedliche Anbieter wie z.B. Eucalyptus, Enomaly oder OpenNebula
  • Verbesserung der Skalierbarkeit des Managements für die Verwaltung von mehr als 1.000 Xen-Hosts
  • Zusammenschluss von günstigen lokalen Speicher durch die Integration von DRDB und Parallax
  • Oracle Cluster File System 2 (ocfs2) Integration

Quelle

Xen Cloud Platform



Skalierung eines Cluster mit Amazon EC2

Dieses Beispiel zeigt welche Komponenten erstellt und konfiguriert werden müssen, um einen Mini Cluster innerhalb eines privaten Netzwerks unter der Verwendung von NIS und NFS aufzubauen. Zusätzlich werden externe Amazon EC2 Nodes per VPN mit dem Server verbunden und am Ende der Cluster mittels der Sun Grid Engine (SGE) aufgebaut.

Architektur

Folgende technische Voraussetzungen werden benötigt:

  • Das private Netzwerk darf nur über ein VPN erreichbar sein, damit die Nodes die sich darin befinden vollständig isoliert sind.
  • Der Server muss NFS, NIS und VPN unterstützen.
  • Die internen Nodes müssen den NFS und NIS Dienst automatisch vom Server starten.
  • Die externen Nodes sind von Amazon EC2.
  • Die externen Nodes müssen automatisch eine Verbindung in das VPN aufbauen und den NFS und NIS Dienst vom Server starten.

Auf Basis dieser Anforderungen werden 3 Images benötigt.

  • 2 Xen Images - einen Server und einen internen Node
  • 1 Amazon Machine Image (AMI) von Amazon EC2 mit derselben Konfiguration wie der interne Node.

Die Konfigurationen sehen in diesem Beispiel wie folgt aus:

Server

  • Private IP-Adresse: eth0 10.1.1.99
  • Öffentliche IP-Adresse: eth1 147.96.1.100
  • Hostname: oneserver

Xen Node (lokal)

  • Private IP-Adresse: eth0 10.1.1.55
  • Hostname: local01

Amazon EC2 Node (IP-Adress Bereich: 10.1.1.100 bis 10.1.1.254)

  • VPN IP-Adresse: tap0 10.1.1.100 (wird durch den VPN Server vergeben)
  • Öffentliche IP-Adresse: eth0 - wird automatisch von Amazon vergeben
  • Hostname: workernode0

Konfiguration

Konfiguration der Images

Nun wird eine Kopie des Image erstellt und die /etc/hostname und /etc/network/interfaces für den Server (oneserver) editiert. Eine weitere Kopie des Image dient als Node, die oben genannten Dateien müssen für diesen ebenfalls angepasst werden. Nach dem unmount der Images werden diese mit Xen gestartet. Für die Konfiguration von NFS und NIS helfen die beiden nachfolgend verlinkten Howtos.

Bei der Konfiguration des VPN Server ist darauf zu achten, dass alle Clients die Zertifikate doppelt verwenden können. Das liegt daran, da keine separaten Amazon EC2 Instanzen erstellt werden sollen und es sich bei den EC2 Instanzen daher um dieselben handelt. Dazu muss in der Konfigurationsdatei von OpenVPN /etc/openvpn/server.conf in Zeilt "duplicate-cn" eingefügt werden. Die Konfiguration von OpenVPN findet nur auf dem Server statt. Eine Howto für die Konfiguration von OpenVPN ist unter dem folgenden Link zu finden.

Für das Erstellen eines Amazon Machine Images wird der Befehl bundle benötigt, dazu kann der lokale Node genutzt werden. Weiterhin muss der VPN Client und die Sun Grid Engine installiert und konfiguriert werden. Auf dem schnellsten Wege sollte das funktionieren, indem eine Kopie des lokalen Node erstellt und konfiguriert wird, anschließend wird es mit dem Befehl ec2-bundle-image gebündelt.

Während des Boot-Vorgangs wird nun noch ein Skript benötigt, in welchem der IP-Adressbereich von OpenVPN für die Amazon EC2 Instanzen von 10.1.1.100 bis 10.1.1.254 reserviert wird. die Konfiguration erfolgt in der /etc/hosts auf dem Server (oneserver).

EC2 Konfiguration mit OpenNebula

Nach der Konfiguration werden nun die Templates benötigt, um die Maschinen zu starten. Für alle lokalen Maschinen wie den oneserver und die Nodes wird jeweils ein Template benötigt, für die EC2 Maschinen reicht ein Template aus.

clouduser@machine:bin$ ec2-describe-images
IMAGE ami-e4a94d8d one-w2/image.manifest.xml 587384515363 available private i386 machine
IMAGE ami-cdb054a4 sge-dolphin/image.manifest.xml 587384515363 available private i386 machine
IMAGE ami-d8b753b1 sge-parrot/image.manifest.xml 587384515363 available private i386 machine
IMAGE ami-dcb054b5 sge-squirrel/image.manifest.xml 587384515363 available private i386 machine

Auf Basis des Images "ami-dcb054b5" wird das EC2 Template erstellt.

CPU=1

MEMORY=1700

EC2=[ AMI="ami-dcb054b5", KEYPAIR="gsg-keypair", ELASTICIP="75.101.155.97", INSTANCETYPE="m1.small", AUTHORIZED_PORTS="22-25"]

REQUIREMENTS = 'HOSTNAME = "ec2"'

Deployment und Tests

Um den Test zu starten muss zunächst OpenNebula gestartet und der EC2 Host hinzugefügt werden.

clouduser@machine:one$ one start
oned and scheduler started
lgonzalez@machine:one$ onehost create ec2 im_ec2 vmm_ec2
lgonzalez@machine:one$ onehost list
HID NAME RVM TCPU FCPU ACPU TMEM FMEM STAT
0 ec2 0 0 100 on

Als nächstes wird die EC2 Instanz gestartet.

clouduser@machine:one$ onevm create ec2.template
ID: 0

Die virtuelle Maschine wird später automatisch auf Amazon EC2 bereitgestellt.

clouduser@machine:one$ onevm list
ID NAME STAT CPU MEM HOSTNAME TIME
0 one-0 pend 0 0 00 00:00:05
lgonzalez@machine:one$ onevm list
ID NAME STAT CPU MEM HOSTNAME TIME
0 one-0 boot 0 0 ec2 00 00:00:15

Mittels onevm show id können alle Informationen eingesehen werden.

clouduser@machine:one$ onevm show 0
VID : 0
AID : -1
TID : -1
UID : 0
STATE : ACTIVE
LCM STATE : RUNNING
DEPLOY ID : i-1d04d674
MEMORY : 0
CPU : 0
PRIORITY : -2147483648
RESCHEDULE : 0
LAST RESCHEDULE: 0
LAST POLL : 1216647834
START TIME : 07/21 15:42:47
STOP TIME : 01/01 01:00:00
NET TX : 0
NET RX : 0

....: Template :....
CPU : 1
EC2 : AMI=ami-dcb054b5,AUTHORIZED_PORTS=22-25,ELASTICIP=75.101.155.97,INSTANCETYPE=m1.small,KEYPAIR=gsg-keypair
IP : ec2-75-101-155-97.compute-1.amazonaws.com
MEMORY : 1700
NAME : one-0
REQUIREMENTS : HOSTNAME = "ec2"

In diesem Beispiel ist die EC2 Instanz über die Adresse ec2-75-101-155-97.compute-1.amazonaws.com zu erreichen.

Nun muss geprüft werden, ob alle virtuellen Maschinen im Cluster gestartet sind. Es existiert eine lokale virtuelle Maschine auf Basis von Xen (local01) und eine von Amazon EC2 (workernode0).

oneserver:~# qstat -f
queuename qtype used/tot. load_avg arch states
----------------------------------------------------------------------------
all.q@local01 BIP 0/1 0.05 lx24-x86
----------------------------------------------------------------------------
all.q@workernode0 BIP 0/1 0.04 lx24-x86
----------------------------------------------------------------------------

Um den Cluster zu testen können ein paar Jobs mittels qsub an die Sun Grid Engine geschickt werden.

oneserver:~# qsub test_1.sh; qsub test_2.sh;

Nun ist zu sehen, welche Jobs im Hybrid Cluster geplant und gestartet sind.


clouduser@oneserver:~$ qstat -f
queuename qtype used/tot. load_avg arch states
----------------------------------------------------------------------------
all.q@local01 BIP 0/1 0.02 lx24-x86
----------------------------------------------------------------------------
all.q@workernode0 BIP 0/1 0.01 lx24-x86
----------------------------------------------------------------------------
############################################################################
- PENDING JOBS - PENDING JOBS - PENDING JOBS - PENDING JOBS - PENDING JOBS
############################################################################
1180 0.00000 test_1.sh clouduser qw 07/21/2008 15:26:09 1
1181 0.00000 test_2.sh clouduser qw 07/21/2008 15:26:09 1

clouduser@oneserver:~$ qstat -f
queuename qtype used/tot. load_avg arch states
----------------------------------------------------------------------------
all.q@local01 BIP 1/1 0.02 lx24-x86
1181 0.55500 test_2.sh clouduser r 07/21/2008 15:26:20 1
----------------------------------------------------------------------------
all.q@workernode0 BIP 1/1 0.07 lx24-x86
1180 0.55500 test_1.sh clouduser r 07/21/2008 15:26:20 1
----------------------------------------------------------------------------

Es können beliebig viele externe Amazon EC2 Instanzen automatisch zum Cluster als Nodes hinzugefügt werden und damit die Skalierbarkeit dynamisch erhöht werden.

Quelle



Skalierung von Web-Servern auf Amazon EC2

Dieses Beispiel zeigt, wie eine skalierbare Web Anwendung auf einer virtuellen Infrastruktur bereitgestellt wird. Um dies zu erreichen wird ein Load Balancer als Master Node für diese Web Anwendung eingesetzt. Hinter dem Load Balancer werden Slave Nodes eingesetzt, die über eine Kopie dieser Web Anwendung verfügen, für den Fall, dass eine Anfrage zu ihnen weitergeleitet wird. Die Leistung (Anfragen pro Sekunde) der Web Anwendung kann durch das Starten oder Herunterfahren von virtuellen Instanzen, die als Nodes des Load Balancer dienen, dynamisch erhöht oder verringert werden.

Ein Teil dieses Beispiels zeigt, wie Remote Nodes (Amazon EC2) eingesetzt werden, wenn die lokale Infrastruktur (auf Basis von Xen) ausgelastet ist.

Architektur

Folgende Komponenten werden für den Aufbau der virtuellen Infrastruktur genutzt:

  • Ein NGinx Server als Load Balancer - zur Aufteilung der Anfragen an die Webserver.
  • Mehrere NGinx Server als Webserver (die einzelnen Nodes des Load Balancer), die jeweils auf einer virtuellen Maschine ausgeführt werden.

Mit den folgenden Eigenschaften:

  • Die virtuellen Maschinen, auf welchen die Webserver ausgeführt werden, können sich lokal (auf dem Xen Hypervisor innerhalb der lokalen Infrastruktur) oder remote (auf Amazon EC2 Instanten) befinden.
  • Die Verwaltung (Monitoring, Deployment, Miration, ...) der virtuellen Maschinen wird mit OpenNebula vorgenommen.

Die obere Graphik beschreibt folgende Eigenschaften:

  • Die grünen Pfeile stehen für Web-Anfragen durch die Web-Clients an den Load Balancer.
  • Die roten Pfeile sind die Anfragen der Web-Clients, die von dem Load Balancer an die Webserver weitergeleitet werden.
  • Die orangen Pfeile stehen für das Monitoring und der Verwaltung durch den Virtual Machine Manager (OpenNebula).

Durch das dynamische Bereitstellen und Hinzufügen weiterer virtueller Webserver zu dem Load Balancer, verfügt diese Infrastruktur über eine hohe Fehlertoleranz, Verfügbarkeit und Skalierbarkeit. Darüber hinaus unterstützt die (virtuelle) Infrastruktur zwei unterschiedliche Virtualisierungs-Technologien (Xen und Amazon EC2), wodurch eine Erweiterung der lokalen Infrastruktur durch eine externe Infrastruktur möglich ist.

Konfiguration
Zunächst muss OpenNebula für das Deployment der virtuellen Infrastruktur konfiguriert werden. Weiterhin muss NGinx auf die Systeme installiert werden, die später den Load Balancer und die Webserver beherbergen sollen. Das Vorgehen dazu ist in dem folgenden Howto beschrieben.

Für die Konfiguration des Load Balancer gelten dieselben Schritte wie in dem oben genannten Howto. Als Konfigurationsdatei kann die nachfolgend aufgeführte genutzt werden. Hier ist der Host definiert, der als Load Balancer verwendet wird und welche Auswahlmethode (round-robin, gewichtet) genutzt werden soll.


clouduser@machine:one$ vim nginx.conf

user www-data;
worker_processes 1;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
access_log /var/log/nginx/access.log;
sendfile on;
keepalive_timeout 65;
tcp_nodelay on;
gzip on;
server {
listen 80;
server_name localhost;
access_log /var/log/nginx/localhost.access.log;
location / {
proxy_pass http://one_loadbalancer;
}
}
upstream one_loadbalancer {
server 10.1.1.11:80 ;
server 10.1.1.22:80 ;
server 10.1.1.33:80 ;
server 10.1.1.44:80 ;
}
}

Im Bereich upstream der Konfigurationsdatei werden die virtuellen Webserver definiert, auf welche die Anfragen für den Lastausgleich aufgeteilt werden. Hier müssen ggf. weitere virtuelle Webserver hinzugefügt werden.

In diesem Beispiel haben die Webserver die IP-Adressen 10.1.1.11, 10.1.1.22, 10.1.1.33 und 10.1.1.44. Damit können also vier Nodes verwendet werden.

Der Load Balancer verfügt über:

  • eine private IP-Adresse für die Kommunikation mit den Nodes im privaten Netzwerks. (in diesem Beispiel 10.1.1.99)
  • eine öffentliche IP-Adresse für die Kommunikation mit den Web-Clients und den Amazon EC2 Instanzen.

Die Amazon EC2 haben öffentliche IP Adressen und kommunizieren mit OpenNebula und dem Load Balancer über das Internet.

Um OpenNebula für die Kommunikation mit Amazon EC2 zu konfigurieren und die Instanzen mit NGinx bereitzustellen sind folgende Schritte notwendig.

Jetzt können die Templates für die lokalen und remote Machinen erstellt werden.

Für den Load Balancer wird folgendes Template verwendet:

clouduser@machine:one$ cat xen.loadbalancer
CPU = 0.5
MEMORY = 128
OS = [kernel="/boot/vmlinuz",initrd= "/boot/initrd",root="sda1" ]
DISK = [source="/images/loadbalancer.disk",target="sda",readonly="no"]

Die lokalen Maschinen verwenden diese Templates:

clouduser@machine:one$ cat xen.local01
CPU = 0.5
MEMORY = 128
OS = [kernel="/boot/vmlinuz",initrd= "/boot/initrd",root="sda1" ]
DISK = [source="/images/local01.disk",target="sda",readonly="no"]

Die Pfade zu den Images und dem Kernel müssen entsprechend der eigenen Umgebung angepasst werden. Aus den Images können beliebig viele Klone für die lokalen Nodes erstellt werden.

Die folgenden Templates werden für die remote Maschinen (Amazon EC2) verwendet.

clouduser@machine:one$ cat ec2.template
CPU=1
MEMORY=1700
EC2=[
AMI="ami-yao044b1",
KEYPAIR="gsg-keypair",
INSTANCETYPE="m1.small",
AUTHORIZED_PORTS="22-25"
]
REQUIREMENTS = 'HOSTNAME = "ec2"'

Die Parameter AMI Identifier, Key-Pair, Memory etc. müssen entsprechend der eigenen Umgebung angepasst werden.

Deployment und Test

Jetzt wird der virtuelle Cluster initialisiert. Zunächst wird der OpenNebula Daemon gestartet und mit dem onehost Befehl eine Host in die Liste der Ressourcen aufgenommen.

clouduser@machine:one$ one start
oned and scheduler started
clouduser@machine:one$ onehost create ec2 im_ec2 vmm_ec2
clouduser@machine:one$ onehost create ursa03 im_xen vmm_xen

Anschließend werden die virtuellen Maschinen mit dem onevm Befehl erstellt.

clouduser@machine:one$ onevm create xen.loadbalancer
ID: 0
clouduser@machine:one$ onevm create xen.local01
ID: 1
clouduser@machine:one$ onevm create xen.local02
ID: 2
clouduser@machine:one$ onevm create xen.local03
ID: 3
clouduser@machine:one$ onevm create xen.local04
ID: 4
clouduser@machine:one$ onevm create ec2.template
ID: 5
clouduser@machine:one$ onevm create ec2.template
ID: 6
clouduser@machine:one$ onevm create ec2.template
ID: 7
clouduser@machine:one$ onevm create ec2.template
ID: 8

Mit dem onevm Befehl kann anschließend der Status der Instanzen überprüft werden.

clouduser@machine:one$ onevm list
ID NAME STAT CPU MEM HOSTNAME TIME
0 one-0 runn 12 512 ursa03 00 00:01:15
1 one-1 runn 8 512 ursa03 00 00:01:11
2 one-2 runn 10 512 ursa03 00 00:01:10
3 one-3 runn 11 512 ursa03 00 00:01:02
4 one-4 runn 23 512 ursa03 00 00:00:51
5 one-5 runn 0 512 ec2 00 00:00:48
6 one-6 runn 0 512 ec2 00 00:00:48
7 one-7 runn 0 512 ec2 00 00:00:45
8 one-7 runn 0 512 ec2 00 00:00:43

Nachdem alle virtuellen Maschinen gestartet sind, kann der Load Balancer die Anfragen der Webclients annehmen. Nun muss noch für jede virtuelle Maschine die IP-Adresse in die /etc/nginx/nginx.conf eingetragen werden. Darüber wird dem NGinx Load Balancer mitgeteilt welcher Node bereit ist.

Die Leistung der Webanwendung kann durch das Hinzufügen weiterer lokaler oder Amazon EC2 Nodes mittels xen.localXX oder ec2.template und der Aktualisierung der Load Balancer Konfigurationsdatei erhöht werden.

Das Hinzufügen kann durch die Entwicklung eines Service Managers automatisiert werden.

Quelle



On-Demand Infrastruktur für virtuelle Labore

OpenNebula kann dazu genutzt werden um virtuelle Labore bereitzustellen. Dabei erhält jeder Student Zugriff auf eine eigene "virtuelle" Infrastruktur, die nur er verwalten kann. Bei der Infrastruktur kann es sich um ein einzelnes System oder ein vollständig verteiltes System handeln. Hierbei kapselt die virtuelle Maschine die Installation für einen Kurs.

Architektur

Aufbau & Bereitstellung

Um das virtuelle Labor bereitzustellen muss zunächst das Netzwerk, wie in den Howtos [1] und [2] beschrieben, konfiguiert werden.

Als nächstes muss ein Master Image erstellt werden. Dieses wird als Basis benutzt um die virtuellen Maschinen für eine Sitzung zu erstellen. In diesem Image muss sämtliche Software, für die späteren virtuellen Hosts des Labor, installiert sein. Aus dem Master Image können anschließend Instanzen von virtuellen Maschinen erstellt werden, indem von der Masterdatei jeweils eine Kopie erstellt wird.

Sobald die Master Virtual Machine konfiguriert ist, kann diese repliziert und als Virtual Machine Template für alle Instanz verwendet werden.

Dabei ist zu beachten, dass sich jede virtuelle Maschine in zwei Dingen voneinander unterscheiden muss:

  • Der Pfad zu dem Image, um die virtuelle Maschine zu mounten.
  • Die MAC-Adresse, da jede virtuelle Maschine eine eigene IP-Adresse benötigt.

Angenommen es sollen 10 virtuelle Computer für ein Labor erstellt werden. Dazu werden 10 unterschiedliche Kopien der Master Virtual Machine und 10 unterschiedliche Virtual Machine Templates benötigt. Die Templates könnten z.B. mit dem Namen VMachineXX.template - wobei XX den Zahlen 1 bis 10 entspricht - bezeichnet werden.

Um die virtuellen Maschinen zu starten wird der Befehl onevm mit folgenden Parametern benötigt.

$ onevm create VMachineXX.template

Dieser Befehl muss 10 mal wiederholt werden, wobei der Platzhalter XX durch die Zahlen 1 bis 10 ersetzt wird. Die IP-Adresse der virtuellen Maschine erhält man entsprechend der Netzwerk-Konfiguration.

Nun reicht es aus, dem Seminarteilnehmer einen Benutzernamen, ein Passwort und die IP-Adresse der virtuellen Maschine mitzuteilen.

Quelle



On-Demand Skalierung eines Computer Cluster

Nachdem ich OpenNebula und die Funktionen bereits kurz vorgestellt habe, möchte ich - angeregt durch die Projekte auf der OpenNebula Webseite - die Einsatzmöglichkeiten auf Basis von vier Anwendungsbeispielen vorstellen. Dazu werde ich in den nächsten Tagen jedes Beispiel auf Grund der Menge und Übersichtlichkeit in einem eigenen Artikel behandeln.

Auch wenn sich diese Beispiele speziell auf OpenNebula beziehen, kann die Umsetzung dieser Ansätze ebenfalls mit anderen Cloud Infrastruktur Management Tools, wie z.B. openQRM erfolgen.

On-Demand Skalierung eines Computer Cluster

Mit OpenNebula können auf einem pyhsikalischen Cluster dynamisch mehrere virtuelle Cluster parallel betrieben werden. Dadurch können Ressourcen wie z.B. Rechenleistung on-Demand bereitgestellt werden, indem die Anzahl der verfügbaren Hosts mit den Bedürfnissen der Benutzer wächst. Da virtuelle Hosts weniger physikalische Ressourcen benötigen, kann ein Cluster dadurch optimiert und konsolidiert werden, da die Anzahl der tatsächlich vorhandenen physikalischen Systeme reduziert werden kann, was dazu führt, dass weniger räumlicher Platz, Strom, Kühlung und Administration erforderlich ist.

Die Zuweisung der physikalischen Ressourcen zu den virtuellen Hosts wird dabei dynamisch und abhängig von den Anforderungen (benötigte Ressourcen) von dem Virtual Machine Manager übernommen. Des Weiteren kann ein Cluster in mehrere Partitionen aufgeteilt werden, da die physikalischen Ressourcen eines Clusters genutzt werden können, um sie einem Host bereitzustellen, der mit einem (anderen) virtuellen Cluster verknüpft ist.

Dieses Beispiel zeigt, wie das Bereitstellen der Ressourcen von der eigentlichen Ausführung, auf einem speziellen Service Layer durch den Local Resource Manager (LRM) getrennt werden kann.

Architektur

Bereitstellung mit der Sun Grid Engine (SGE)

Zunächst muss das Netzwerk, wie in den Howtos [1] und [2] beschrieben, konfiguiert werden, um neue virtuelle SGE Hosts mit unterschiedlichen Namen zu erstellen.

Um das grundlegende Virtual Machine Image zu erstellen kann der Befehl xen-create-image benutzt, ein Image von einem frisch installiertes Betriebssystem verwendet oder ein bereits verwendetes Virtual Machine Image genutzt werden.

Zusätzlich muss der virtuelle SGE Host genau so konfiguriert werden wie der physikalische SGE Host (NFS, NIS, execd, etc.)

Dieses Image dient als Grundlage für alle neuen virtuellen SGE Hosts. Jeder virtuelle Hosts muss an einem eigenen Ort abgelegt werden. Hierzu existiert das zentrale Verzeichnis sgebase, dass alle Images beinhaltet. Für jedes Image wird anschließend ein eigenes Verzeichnis mit dem Namen des Images erstellt.

$ cp -R sgebase sgehost01

Nun muss ein neues Virtual Machine Template erstellt werden. (Es kann auch ein bereits bestehendes kopiert werden und angepasst werden.)

MEMORY=64
CPU=1
OS=[
kernel="/boot/vmlinuz-2.6.18-4-xen-amd64",
initrd="/boot/initrd.img-2.6.18-4-xen-amd64",
root="sda1",
boot="hd"]
DISK=[
source="/local/xen/domains/xen/domains/sgehost/disk.img",
target="sda1",
readonly=no]
DISK=[
source="/local/xen/domains/xen/domains/sgehost/swap.img",
target="sda2",
readonly=no]
NIC=[mac="00:16:3e:01:01:03"]

Jetzt muss noch der Pfad zu dem Image, dem Kernel, der Ramdisk etc. angepasst werden.

Zum Starten des neuen virtuellen Host benötigen wir folgenden Befehl:

$ onevm create

Um Aufgaben entgegen zu nehmen muss der neue Host mit SGE anschließend bekannt gemacht werden .

$ qconf -ah sgehost01
$ qconf -as sgehost01
$ qconf -se

Soll der neue Host einer Gruppe zugeordnet werden, benötigen wir folgenden Befehl:

$ qconf -mhgrp @allhosts

Quelle



OpenNebula

OpenNebula ist ein Open Source Virtual Infrastructure Manager mit dem aus vorhandenen Rechenzentren jede Art von Cloud Computing Umgebung aufgebaut und bereitgestellt werden kann. In erster Linie dient OpenNebula als Tool zur Verwaltung der virtualisierten Infrastruktur des eigenen Rechenzentrums bzw. der eigenen Cluster, also der eigenen Private Cloud.

Darüber hinaus ist OpenNebula in der Lage Hybrid Clouds aufzubauen, also die eigene lokale Infrastruktur mit einer Public Cloud Infrastruktur zu verbinden/kombinieren, um die Skalierbarkeit der eigenen Umgebung noch weiter zu erhöhen. OpenNebula verfügt zusätzlich über spezielle Schnittstellen für die Verwaltung von virtuellen Maschinen, Speicherplatz und des Netzwerks von Public Clouds.

Funktionen

    Private Cloud Computing >> Virtual Infrastructure Management

    • Internal Interfaces for Administrators and Users
      Mit einer Unix ähnlichen Kommandozeile und einer XML-RPC API kann der Lebenszyklus der virtuellen Maschinen und physikalischen Server verwaltet werden. Weitere Administrationsmöglichkeiten bietet die libvirt API.
    • Steuerung
      Die Verwaltung der Arbeitslast und Zuweisung der Ressourcen kann nach bestimmten Regeln wie z.B. der aktuellen Auslastung automatisch vorgenommen werden. Des Weiteren wird der Haizea VM-based lease manager unterstützt
    • Virtualisierungsmanagement
      Es existieren Konnektoren für Xen, KVM und VMware, sowie einem generischen libvirt Konnektor für weitere Virtual Machine Manager. Die Unterstützung von Virtual Box ist in Planung.
    • Image Management
      Es sind Funktionen für den Transfer und das Clonen von Virtual Machine Images vorhanden.
    • Netzwerk Management
      Es lassen sich isolierte virtuelle Netze festlegen um virtuelle Maschinen miteinander zu verbinden.
    • Service Management
      Unterstützung von Multi Tier Services bestehend aus Gruppen von miteinander verbundenen virtuellen Maschinen und deren Auto Konfiguration während des Boot Vorgangs.
    • Sicherheit
      Die Verwaltung der Benutzer wird durch den Administrator der Infrastruktur vorgenommen.
    • Fehlertoleranz
      Eine persistente Datenbank dient zum Speichern aller Informationen der Hosts und virtuellen Maschinen.
    • Skalierbarkeit
      Tests zeigten bisher, das OpenNebula mehrere hundert Server und virtuelle Maschinen verwalten kann.
    • Installation
      Die Installation erfolgt auf einem UNIX Cluster Front-End ohne das weitere Services benötigt werden. OpenNebula wird mit Ubuntu 9.04 (Jaunty Jackalope) ausgeliefert.
    • Flexibilität und Erweiterbarkeit
      Die Architektur, Schnittstellen und Komponenten sind offen, flexibel und erweiterbar. Dadurch kann OpenNebula mit jedem aktuellen Produkt aus dem Bereich Virtualisierung, Cloud Computing oder Management Tool für Rechenzentren integriert werden.
    • Hybrid Cloud Computing

      • Cloud Plugins
        Konnektoren für Amazon EC2 und ElasticHosts.
      • Zusammenschluss
        Unterstützung für den gleichzeitigen Zugriff auf mehrere Remote-Clouds.
      • Erweiterbarkeit
        Modulare Konzepte für die Entwicklung neuer Konnektoren.

      Public Cloud Computing >> Cloud Interfaces

      • Cloud Schnittstellen für Benutzer
        Implementierung einer Teilmenge der Amazon EC2 Query API und der OGF OCCI API
      • Erweiterbarkeit
        Die OpenNebula Cloud API ermöglicht die Implementierung neuer/weiterer Cloud Schnittstellen.

    Seminare und Forschung

    Quelle



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