OpenNebula – Open-Source-Datacenter-Virtualisierung

© pitris, 123RF

Griff zu den Sternen

OpenNebula ist eine Enterprise-Cloud-Management-Plattform, die 2005 aus einem EU-Forschungsprojekt hervorgegangen ist. Damit ist sie bereits länger am Markt als viele vergleichbare Produkte. Mit der aktuellen Version 4.2 (Codename Flame) präsentiert sie sich seit Juli 2013 in neuem Gewand.
Der ADMIN 05/13 wirft einen Blick auf die frei verfügbaren Cloud-Frameworks von Eucalyptus über OpenNebula bis OpenStack. Gute Aussichten für skalierbare ... (mehr)

OpenNebula [1] selbst trennt die vorhandenen Cloud-Lösungen in die beiden Einsatzbereiche Infrastructure Provisioning und Datacenter Virtualizsation [2] und sieht sich selbst im letztgenannten Bereich. Diese Einteilung erlaubt auch eine klare Positionierung im Vergleich zu anderen Lösungen, worauf der Artikel noch eingehen wird.

Was ist OpenNebula?

OpenNebula greift zur Bereitstellung von Ressourcen auf verschiedene etablierte Subsysteme in den Bereichen Virtualisierung, Networking und Storage zurück. Dies ist bereits ein signifikanter Unterschied zu Alternativlösungen wie OpenStack und Eucalyptus. Diese favorisieren nämlich eigene Konzepte – am Beispiel von Storage und OpenStack via Swift.

Alle diese Subsysteme [Abbildung 1] werden über einen zentralen Daemon ( »oned« ) miteinander verbunden. Zusammen mit einem Benutzer- und Rollenkonzept werden diese Komponenten über Command Line Interfaces und das Web-Interface bereitgestellt. Die Bedienung der Hosts und VMs ist dadurch unabhängig vom eingesetzten Subsystem und erlaubt eine transparente Steuerung von Xen, KVM und VMware. Auch ein gemischter Betrieb dieser Hypervisor ist möglich – OpenNebula abstrahiert dabei von den jeweils verfügbaren Komponenten mithilfe eines einheitlichen Interfaces. Genau in dieser transparenten Verbindung unterschiedlichster Komponenten steckt die Stärke von OpenNebula: seine hohe Integrationsfähigkeit.

Abbildung 1: OpenNebula setzt auf existierende Virtualisierungs-Netzwerk- und Storage-Lösungen, die ein zentraler Daemon integriert.

Aufbau

Ein wichtiges Merkmal von OpenNebula ist der Schwerpunkt auf Rechenzentrumsvirtualisierung mit bestehender Infrastruktur. Wichtige Voraussetzung dafür ist die Unterstützung einer Vielzahl an Infrastrukturkomponenten und deren dynamische Verwendung.

Besonders gut erkennt man das an den sogenannten Datastores. Deren Grundidee ist simpel: Während beispielsweise ein Testsystem jederzeit wieder aus dem zentralen Image Repository auf einen Hypervisor kopiert werden kann, ist bei einem DB-Server die Wiederherstellung der letzten Laufzeitumgebung notwendig. Die innerhalb einer OpenNebula-Installation mehrfach konfigurierbare Definition von Datastores bietet die Möglichkeit, sich diesen unterschiedlichen Lebenszyklen anzupassen. So kann ein persistentes Image auf einem NFS-Volume beheimatet sein und ein volatiles Image wird zum Startzeitpunkt auf den eingesetzten Hypervisor kopiert.

Der Konfigurations- und der Monitoringstack sind innerhalb von OpenNebula vollständig getrennt. Ein klarer Workflow stellt Compute-Ressourcen bereit und überwacht in der Folge die Verfügbarkeit. Ein Ausfall des OpenNebula-Cores hat dabei keinerlei Auswirkung auf den Runtime-Status der jeweiligen Instanzen, da Kommandos nur im Bedarfsfall abgesetzt werden.

Zur Überwachung selbst dienen abhängig vom Hypervisor lokale Kommandos. So pollt der Core regelmässig alle aktiven Hypervisor und prüft, ob die konfigurierten Systeme noch aktiv sind. Sollte das nicht der Fall sein, werden sie neu gestartet.

Durch die Überwachung von Hypervisor-Ressourcen wie Memory und CPU wird eine Vielzahl von Systemen im Fehlerfall schnell umverteilt und neu gestartet. Typischerweise werden bei Ausfall eines Hypervisors die betroffenen Systeme so schnell verteilt, dass ein Nagios- oder Icinga-System im Standardintervall keinen Alarm schlägt. Lediglich der Ausfall des Hypervisors soll natürlich für Aufmerksamkeit sorgen.

Selfmanagement und Überwachung der Ressourcen sind ein wichtiger Bestandteil von OpenNebula und im Vergleich zu anderen Produkten bereits sehr detailliert und variabel verwendbar. Über ein Hook-System können darüber hinaus noch an allen erdenklichen Stellen Custom-Skripte ausgeführt werden. Mit der Auto-Scaling-Implementierung OneFlow können ab Version 4.2 auch Abhängigkeiten über Systemgrenzen hinweg definiert und überwacht werden. Aber dazu später mehr.

Ä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