Cloud Shaping

Mit zunehmender Größe einer Cloud-Umgebung sind auch Abhängigkeiten zu Nutzern, Standorten und Fähigkeiten der eingesetzten Systeme zu berücksichtigen. OpenNebula verfügt hier mit Gruppen, virtuellen Datacenters (kurz VDC) und Zones über drei Basiskonzepte.

Gruppen erlauben es, Systeme mit gleichartigen Fähigkeiten zu logischen Einheiten zusammenzuschließen. Damit können Voraussetzungen für den Betrieb bestimmter Systeme definiert und solche mit Zugriff auf die gleiche Teilinfrastruktur wie Datastore, VLANs und Hypervisor zusammengefasst werden. So lässt sich zum Beispiel ein KVM-System auf einem GlusterFS-Storage natürlich nur auf Servern mit KVM-Hypervisor und GlusterFS-Zugriff betreiben. Gruppen stellen sicher, dass genau diese Voraussetzungen auch erfüllt sind.

Wenn eine Sammlung von Ressourcen einer Anzahl Benutzer oder auch einem Kunden zur Verfügung gestellt werden soll, ohne dass Gruppen zum Einsatz kommen, dann ist die Verwendung von VDC die Lösung. Beliebige Ressourcen können zu virtuellen Rechenzentren zusammengefasst und über ACLs berechtigt werden. Diese zonenübergreifenden Zusammenschlüsse bieten neben der Isolation von Noisy Neighbors und der Teilzuordnung von Ressourcen auch eine sehr gute Basis für Individualabrechnung von Ressourcen. Auch die Unterteilung aller Ressourcen in individuelle Private Clouds lässt sich einfach mit VDCs lösen.

Als drittes Teilkonzept für den Zusammenschluss großer Installationen bietet OpenNebula Zones. Zones (oZones) ermöglichen die zentrale Überwachung und Konfiguration individueller OpenNebula-Einzelinstallationen. Dies erlaubt die vollständige Isolation einzelner Bereiche über die Versionsgrenzen hinweg und die gleichzeitige zentrale Steuerung der Umgebung.

Diese Trennung kann das Applikationsprofil, aber auch den Standort oder Kunden berücksichtigen. Auch wenn man eine Vielzahl von OpenNebula-Installationen zusammenfasst, ist eine unabhängige Steuerung der Einzelsysteme möglich. Somit ist die maximale Freiheit in der jeweiligen Einzelumgebung bei gleichzeitiger zentraler Zusammenfassung und Überwachung gewährleistet.

Neues in Version 4.2

Bereits mit der Version 4.0 haben viele neue Features in OpenNebula Einzug gehalten. Gerade im Bereich der Virtualisierungsschicht bietet OpenNebula mit Features wie Realtime Snapshots und Capacity Resizing nun alles, um auch mit kommerziellen Lösungen auf Augenhöhe zu agieren. Die bereits angesprochene Neuerung der Weboberfläche ist sicherlich die auffälligste Veränderung und verbindet nun die früher getrennten Sichten für Admin und Self Service in einer Oberfläche.

Besonders erwähnenswert sind die beiden neuen Komponenten OpenNebula Gate und OpenNebula Flow. Gate ermöglicht es dem Anwender, mithilfe eines Sicherheits-Tokens Informationen zwischen VMs und OpenNebula auszutauschen. Eine bei Template-Erzeugung erstellte URL kann so Applikationsmetriken an OpenNebula übergeben und mit Hilfe von Sunstone visualisieren. Ein Beispiel wäre, die aktiven Connections eines virtualisierten Loadbalancers in regelmässigen Abständen an OpenNebula zu übergeben.

Sinnvoll ist die anschließende Verarbeitung dieser Informationen mit der neuen Komponente Flow. Die früher als AppFlow verfügbare Erweiterung ist seit 4.2 fester Bestandteil und wurde im Rahmen der Übernahme stark erweitert. Mit Hilfe von Flow lassen sich statische, aber auch dynamische Regeln auf Basis von OpenNebula-Gate-Werten ausführen.

Hier trennt OpenNebula in sogenannte Scheduled Policies und Elasticity Policies ( Abbildung 3 ). Scheduled Policies erlauben, wie der Name bereits vermuten lässt, die zeitgesteuerte Veränderung von Ressourcen-Pools. So können Applikationsserver in der Nacht oder am Wochenende nach statischen Regeln heruntergefahren werden, wenn deren Leistung nicht benötigt wird.

Abbildung 3: OpenNebula kennt sogenannte Schedulded und Elasticity Policies für die automatische Anpassung der Ressourcen.

Elasticity Policies können nach Regeln und unter Berücksichtigung von Gate-Werten Änderungen an Pools vornehmen. Nach Definition von Minimal- und Maximalgröße eines Pools werden regelgesteuert virtuelle Maschinen gestartet oder heruntergefahren. Unter Verwendung von Expressions und Period-Regeln lassen sich dann in variablen Intervallen die verfügbaren Ressourcen ändern.

Listing 1 zeigt die Verwendung einer dynamischen Regel auf Basis der Connections. Die per OpenNebula Gate übermittelte Anzahl aktiver Connections wird geprüft und führt in der ersten Teilregel nach dreifacher Überschreitung zum Start zweier neuer Systeme. Die zweite Teilregel erlaubt die Reduzierung des Pools, wenn sich die Connections um einen bestimmten Prozentsatz verringern.

01 {
02   "name": "ONE-SCALE",
03   "deployment": "none",
04   "roles": [
05     {
06       "name": "appserver",
07       "cardinality": 2,
08       "vm_template": 0,
09
10       "min_vms" : 5,
11       "max_vms" : 10,
12
13       "elasticity_policies" : [
14         {
15           // +2 VMs when the exp. is true for 3 times in a row,
16           // separated by 10 seconds
17           "expression" : "CONNECTION > 2000",
18
19           "type" : "CHANGE",
20           "adjust" : 2,
21
22           "period_number" : 3,
23           "period" : 10
24         },
25         {
26           // -10 percent VMs when the exp. is true.
27           // If 10 percent is less than 2, -2 VMs.
28           "expression" : "CONNECTION < 2000",
29
30           "type" : "PERCENTAGE_CHANGE",
31           "adjust" : -10,
32           "min_adjust_step" : 2
33         }
34       ]
35     }
36   ]
37 }

Durch Verbindung von dynamischen Applikatonsinformationen mit den Möglichkeiten des OpenNebula-Kerns sind dem Management komplexerer Applikationsszenarien keinerlei Grenzen gesetzt. Die Syntax ist selbsterklärend und Regeln sind in kurzer Zeit für vielfältige Szenarien verwendbar. Damit erfüllt OpenNebula eine wichtige Anforderungen von Applikationsbetreibern und erlaubt die bedarfsgerechte Ressourcenzuweisung. Da OpenNebula auch über eine Schnittstelle zu AWS verfügt, können auch Systeme in Richtung AWS als Hybrid-Cloud-Modell ausgelagert werden.