Open Source Data Center Virtualisierung mit OpenNebula

Nebel gelichtet

,
Dem Buzzword Cloud geht es so wie IPv6: Jeder spricht darüber, aber praktische Erfahrungen sind bislang noch Mangelware. Stattdessen klebt das Etikett als Marketinggag auf allen möglichen und unmöglichen Produkten. Dieser Beitrag leistet handfeste Hilfe beim Einstieg in die Cloud mit OpenNebula.
Mit E-Mail-Diensten muss sich jeder Administrator früher oder später einmal beschäftigen. Das zur CeBIT erscheinende ADMIN 02/2012 gibt dazu Praxis-Tipps und ... (mehr)

Die Entwicklung vieler am Markt verfügbarer Cloud-Lösungen läuft bereits seit mehr als sieben Jahren und hat teils Hervorragendes zuwege gebracht. Das hier vorgestellte Framework OpenNebula [1] dürfte neben Eucalyptus und OpenStack, genauer dessen Computing-Stack Nova, wohl das populärste Framework für Rechenzentrumsvirtualisierung sein. Das Toolkit, das seit Mitte Januar in der Version 3.2 erhältlich ist, wird von einem großen Team und der Untersütztung des kommerziellen Spin-offs C12G Labs weiterentwickelt.

Der signifikanteste Unterschied zwischen OpenNebula und den anderen Frameworks ist sicherlich die Tatsache, dass sich OpenNebula mehr als Toolkit denn als All-in-One-Lösung versteht. Genau darin liegt aber auch sein Charme. Für die kommenden Versionen [2] stehen aktuell vor allem eine bessere EC2-Integration und die Optimerung der Self-Service-Console auf der To-do-Liste der Entwickler.

Gerade im gewachsenen heterogenen Rechenzentrumsumfeld kann man so gut wie nie auf der grünen Wiese ganz neu beginnen. Storage- und Virtualisierungskomponenten sind oft schon etabliert und der Umgang mit ihnen vertraut. Was fehlt ist die übergreifende Steuerung und Verwaltung dieser Komponenten in einer Private-Cloud-Lösung. Der Wunsch, externe Ressourcen (etwa von Amazon) zur Abfederung von Spitzen im Stil einer Hybrid-Cloud einzubinden, kommt meist ohnehin erst viel später.

Integration

OpenNebula ging im Jahre 2005 aus einem Forschungsprojekt hervor und wird seitdem von der Europäischen Union gefördert. Zur Bereitstellung von Ressourcen greift es auf verschiedene Subsysteme wie den Virtualization Stack, Networking, Storage, Hosts, oder die Einträge für Benutzer und Gruppen zurück und verbindet die entsprechenden Komponenten über diverse Command Line Interfaces oder ein Web-Interface mit dem Namen Sunstone.

Die Bedienung der Host- und VM-Komponenten ist unabhängig vom eingesetzten Subsystem und erlaubt eine transparente Steuerung von Xen-, KVM-, oder VMware-Systemen. Auch ein gemischter Betrieb von entsprechenden Hypervisoren ist möglich. Open Nebula macht die verfügbaren Kernkomponenten durch Interfaces nutzbar. Genau in dieser transparenten Verbindung unterschiedlichster Komponenten ( Abbildung 1 ) steckt die Stärke von Open Nebula und somit auch die hohe Integrationsfähigkeit.

Abbildung 1: Open Nebula kann unterschiedliche Cloud-Komponenten auch über Herstellergrenzen hinweg integrieren.

In Abhängigkeit von den eingesetzten Komponenten gestaltet sich die Installation mehr oder weniger komplex und erlaubt daher keine wirkliche Standard-Installation. Deshalb besteht die recht ausführliche Anwenderdokumentation aus verschiedenen Implementierungsbeispielen mit diversen Storage- und Virtualisierungsplattformen.

Im Grunde setzt sich eine Installation aber immer aus der Einrichtung folgender vier Komponenten zusammen:

  • Front-End
  • Hosts
  • Image Repository & Storage
  • Networking

Architektur

Das Front-End bildet mit dem Management-Dameon ( »oned« ), den entsprechenden APIs und dem Webinterface ( »sunstone« ) die Steuereinheit der Cloud-Installation. Auf den eigentlichen Virtualisierungshosts muss mit der Ausnahme von Ruby keine spezifische Software installiert werden, jedoch sollte der SSH-Zugriff auf alle beteiligten Hosts möglich sein, um später Statusdaten abzurufen oder gegebenenfalls Images zu übertragen.

Diese Images sammelt ein Repository, das seinerseits in der Regel von einem verteilten Filesystem beherbergt wird, damit Features wie Live-Migration möglich sind und im Falle eines Host-Ausfalls kein Redeploy des Images notwendig ist. Im Gegensatz zu einigen anderen Frameworks ist bei OpenNebula ein verteiltes Filesystem allerdings nicht zwingend erforderlich, und Images können bei Start des Systems aus dem genannten Repostitory auf das eigentliche Zielsystem geclont werden.

Abbildung 2 zeigt einen entsprechenden Aufbau unter Verwendung eines zentralen NFS-Volumes, was einen schnellen Aufbau der Umgebung ermöglicht, jedoch gewisse Durchsatzbeschränkungen aufgrund des Protkoll-Overheads mit sich bringt. Die Netzwerkanbindung wird mithilfe von Bridges hergestellt, die idealerweise unter gleichen Namen auf allen Hosts zu Verfügung stehen. Hier lohnt es sich, von Anfang an entsprechende Namenskonventionen im Blick zu haben, damit sich die erhoffte Migration einer VM bei Ausfall eines Hosts nicht als problematisch erweist.

Abbildung 2: Ein Shared Filesystem eignet sich besonders, um die Image Repositories von Open Nebula zu beherbergen.

Die Installation [3] der Komponenten kann über entsprechende Distributionspakete für CentOS oder Open Suse oder aus den Sourcen [4] erfolgen und ist auf der Projektseite sehr ausführlich beschrieben. Nach Einspielen der notwendigen Pakete und Anlage des Open- Nebula-Users »oneadmin« , ist noch der entsprechende SSH-Key zu generieren und zu verteilen und fertig. Wenn alles richtig gemacht wurde, sollte ein Start von OpenNebula mit dem Befehl

# one start

erfolgreich und der Zugriff auf den Daemon unter Verwendung des CLI möglich sein.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023