MP-WS13-01

Aus Verteilte Systeme - Wiki
Wechseln zu: Navigation, Suche

Beschreibung

Heutzutage ist Cloud Computing in aller Munde. Eine Cloud besteht aus vielen virtuellen Maschinen (VMs), die auf physikalischen Servern (PMs) laufen. Die meisten Anwendungen, die auf einer Cloud laufen, lassen sich effizient skalieren. Das heißt, wenn eine Anwendung an die Grenze ihrer Belastbarkeit kommt, kann einfach eine neue VM mit dem gleichen Programm gestartet werden, um die Last aufzuteilen. Dies ist die einfachste Möglichkeit, um Service Level Agreements (SLA), welche die Qualität des Services beschreibt (z.B. Antwortzeiten, Reaktionszeiten, Ausfallzeiten, usw.) einzuhalten, ohne dabei händisch eingreifen zu müssen.
Viele Anwendungen skalieren aber nicht sehr gut oder gar nicht, wenn sich z.B. eine langsame Datenbank mit vielen Transaktionen dahinter befindet oder das System nicht zustandslos ist. Wenn dies der Fall ist, muss der Computer (oder die VM) mehr Ressourcen erhalten, damit die Anwendung skalieren kann. Dies kann man mit einer VM im laufenden Betrieb erledigen, ohne die VM ausschalten zu müssen. Damit aber die VMs richtig auf den PMs verteilt und damit die VMs richtig konfiguriert werden, wird ein Programm benötigt, welches diese Aufgaben automatisiert ausführt.

Projektaufgabe

Ziel dieses Projekts ist es, virtuelle Maschinen automatisch managen zu können.
Dies soll mithilfe der SLAs geschehen, welche für eine bestimmte Middleware vorgegeben sind.
Mithilfe der MAPE-K Loop sollen die Parameter der VM (CPU/RAM/IO) so optimiert werden, dass die Middleware ihre SLAs einhält.
Dabei erhalten die VMs nur so viele Ressourcen wie sie auch tatsächlich benötigen, sodass möglichst viele VMs gleichzeitig auf einen physikalischen Rechner laufen können.

Literatur

Der Literaturabschnitt ist in drei Abschnitte unterteilt.
Im ersten Abschnitt befindet sich die Zusammenfassung der Literaturrecherche, welche zu diesem Thema erstellt wurde.
Der zweite Abschnitt besteht aus Benutzerhandbüchern und Dokumentation der Software, welche später eingesetzt wird.
Der dritte Abschnitt beinhaltet die wissenschaftliche Literatur zu diesem Thema.

Zusammenfassung

Bei der Zusammenfassung handelt es sich um den derzeitigen Stand der Technik (State of the Art) für das Management von VMs. Es wird erläutert, welche Ziele beim Managen verfolgt werden und welche Werte beim Management von VMs überwacht werden müssen.
Danach wird auf die Probleme eingegangen, die beim Management von VMs auftreten können bzw. vermieden werden sollten. Der restliche Teil der Zusammenfassung beschäftigt sich mit den Lösungsansätzen der verschiedenen Papers, welche im dritten Abschnitt aufgelistet sind.

Die Zusammenfassung kann über den nachfolgenden Link heruntergeladen werden.
Download: State of the Art

Handbücher und Dokumentation

Wissenschaftliche Literatur

Masterarbeit: Marinescu, Dan
Design and Evaluation of Self-Management Approaches for Virtual Machine-Based Environments
Download

Paper: A VM-based Resource Management Method Using Statistics
Stichworte: Management der VM Ressourcen mit Statistiken, Reduzierung von überbelegten Ressourcen auf heterogenen Systemen
Download

Paper: Dynamic Placement of Virtual Machines for Managing SLA Violations
Stichworte: Reduzierung der SLA Verletzungen, Vorhersagemethode um VMs zu migrieren, Periodischer Workload
Download

Paper: Energy-efficient and SLA-Aware Management of IaaS Clouds
Stichworte: Minimierung des Energieverbrauchs, First Fit, Monte Carlo, Vector Packing
Download

Paper: Performance and Power Management for Cloud Infrastructures
Stichworte: Minimierung des Energieverbrauchs, SLA Verstöße minimieren
Download

Paper: Self-Adaptive and Resource-Efficient SLA Enactment for Cloud Computing Infrastructures
Stichworte: Managen mit MAPE-K, Rekonfigurieren mit Schwellenwerten
Download

Paper: The Right Tool for the Job: Switching Data Centre Management Strategies at Runtime
Stichworte: Dynamisches Wechseln der Strategie, Energieeffizient arbeiten, Einhaltung der SLAs
Download

Paper: VM Provisioning Method to Improve the Profit and SLA Violation of Cloud Service Providers
Stichworte: Einhaltung von SLAs, Erstellen von VMs bei mehreren Clouds mit mehreren Schwellwerten
Download

Paper: Vertical scaling for prioritized VMs provisioning
Stichworte: Priorisierung von VMs, NUR CPU, Vorhersage und Skalierung, getestet mit RUBiS Webserver
Download

Paper: Network-aware migration control and scheduling of differentiated virtual machine workloads
Stichworte: Netzwerkauslastung bei Migrationen von VMs, Scheduling bei mehreren Migrationen
Download

Paper: Optimizing Resource allocation while handling SLA violations in Cloud Computing platforms
Stichworte: Onlinevariante des Bin-packing, NUR CPU, Migration
Download

Paper: A multi-objective approach to virtual machine management in datacenters
Stichworte: Management anhand von SLAs, Stromverbrauch und Hitzeentwicklung, Migration
Download

Paper: Autonomic virtual resource management for service hosting platforms
Stichworte: Constraint Programming, Verteilung und Einstellung der VMs als Constraint Satisfaction Problem
Download

Paper: Multi-objective Virtual Machine Placement in Virtualized Data Center Environments
Stichworte: grouping genetic algorithm (GGA), Fuzzybewertung, Migration anhand von Leistung, Stromverbrauch und Wärmeentwicklung
Download

Paper: Enhancing virtual environments with QoS aware resource management
Stichworte: Anpassen des CPUs Shedulers um VMs zu managen, NUR CPU
Download

Paper: Allocating Compute and Network Resources Under Management Objectives in Large-Scale Clouds
Stichworte: Verteilung der VMs, Energieeffizent, gleiche Verteilung an die VMs ?, Einhaltung der Service Klasse,
Algorithmus "power of two random choices" zum Starten, Dynamisches Plazieren mit einem "generic and scalable gossip protocol"
Download

Umgebung

In diesem Abschnitt wird auf die Umgebung eingegangen, welche für das Projekt eingesetzt wird.
Dabei werden auch die Schritte aufgelistet, welche zum Einrichten der Umgebung ausgeführt werden müssen.

Server

Die verwendeten Server für dieses Projekt sind zwei Dell PowerEdge Server.
Man kann über den iDRAC (integrated Dell Remote Access Controller) aus dem Netzwerk direkt auf die Server zugreifen.
Die Server haben folgende Eigenschaften:

Server I Server II
Name miraculix automatix
Prozessor 2x Intel Xeon E5-2430 2.2GHz mit 6 Kernen + HT 1x Intel Xeon E5-2430 2.2GHz mit 6 Kernen + HT
Prozessorfähigkeiten HyperThreading, Virtualization Technology, Execute Disable, Turbomodus, ECC HyperThreading, Virtualization Technology, Execute Disable, Turbomodus, ECC
Arbeitsspeicher 48GB DDR3 1333MHz 48GB DDR3 1333MHz
Festplatten 1TB SAS (6Gbps) in Raid 1 6TB SAS (6Gbps) in Raid 1
Netzwerk 2x Intel(R) Gigabit
2x Broadcom Gigabit Ethernet
2x Intel(R) Gigabit
2x Broadcom Gigabit Ethernet

Zusätzlich zu den Raid 1 Festplatten in den Servern, wurde noch an eine 500GB große Netzwerkfestplatte über iSCSI an beide Server angebunden. Dadurch ist es möglich, dass die VMs mithilfe von vMotion während des laufenden Beriebs migriert werden können. (Live-Migration)

VMware ESXi

Als Hypervisor wird VMware vSphere ESXi eingesetzt.
Da auf den Servern noch kein Hypervisor vorhanden ist, muss auf beiden Server ESXi noch installiert werden.

Installation

Der Server besitzt kein eigenes CD/DVD Laufwerk, deshalb erfolgt die Installation des VMware vSphere ESXi über das iDRAC. Dafür muss man in einem Browser die Adresse des iDRAC aufrufen, sich dort mit einem gültigen Account anmelden und danach die Konsole des iDRAC aufrufen. Die Konsole ist eine Anwendung, welche in Java geschrieben ist. Es ist also nicht möglich, auf den Server zuzugreifen, wenn keine Java Runtime Environment auf dem Rechner vorhanden ist.
Wenn die Konsole erfolgreich eine Verbindung zum Server aufgebaut hat, kann man eine CD/DVD oder ein ISO Image auf dem Server einbinden. Dazu öffnet man den Reiter Virtueller Datenträger der Konsole. Da das Installationsmedium in diesem Fall ein ISO Image ist, wird es über Images hinzufügen eingebunden. Damit der Server von diesem Image booten kann, muss das ISO Image noch Zugeordnet werden. Dies geschieht durch das Auswählen der Funktion Zugeordnet an dem ISO Image.


Der Installationsvorgang des VMware vSphere ESXi Servers ist selbsterklärend. Es muss lediglich die Festplatte angeben werden, auf der sich dann das ESXi installiert.
Nach der Installation des Hypervisors kommt man auf den Hauptbildschirm des ESXi. Die Änderung der Einstellungen erfolgt mittels der Taste F2. Der Standard Login des Administrators lautet root und das Passwort ist nicht gesetzt.
Damit der Server von draußen erreichbar ist, müssen die Netzwerkeinstellungen angepasst werden. Da der DHCP Server keine richtige IP-Adresse vergibt, bekommt der Server seine alte (feste) IP-Adresse zugewiesen. Mithilfe des Netzwerktests kann überprüft werden, ob die Netzwerkeinstellungen in Ordnung sind. Dabei können aber nur die Intel(R) Gigabit Netzwerkadaper benutzt werden, die zwei Broadcom Gigabit Ethernet werden von ESXi nicht erkannt.


Über Datei->OVF-Vorlage bereitstellen kann die VMware vCenter Server Appliance auf deinen ESXi Server übertragen werden. Die vCenter Server Appliance wird benötigt, um mehrere ESXi Server gleichzeitig zu verwalten. Die Vorlage der vCenter Server Appliance beinhaltet die allgemeinen Einstellungen für die VM wie z.B. die Anzahl der CPUs, die Größe des Arbeitsspeichers oder die Größe der Festplatte. Nachdem die vCenter Server Appliance auf dem ESXi Server erfolgreich erstellt wurde, kann sie gestartet werden.
Nachdem die VM hochgefahren ist, werden auf der Konsole die nachfolgenden nächsten Schritte angezeit. Zum Konfigurieren der vCenter Server Appliance muss man mit einem Webbrowser auf die HTTPS-Adresse des Servers, mit dem Port 5480 gehen. (Im VS-Labor wurde diese Funktion nur mit dem Browser Chromium getestet. Mit dem Browser Firefox erscheint nur eine Fehlerseite).
Nach der Konfiguration des vCenter Server Appliance kann man entweder über die Webschnittstelle oder wie gewohnt über den VSphere Client zugreifen. Unter Verwaltung->Lizenzierung können die Lizenzen der ESXi Server eingetragen werden. Die Server können nun zur vCenter Server Appliance hinzugefügt werden. Dabei werden die Lizenzen den Servern zugeordnet.

Einrichten von vMotion

Um vMotion aktivieren zu können, müssen alle ESXi Server einen Zugriff auf eine gemeinsame Festplatte haben. Dadurch ist es möglich, die VMs von einem Host auf einen anderen Host zu migrieren während die VMs noch aktiviert ist (Live-Migration oder vMotion). Wenn die unterschiedlichen ESXi Server über keine gemeinsame Festplatte verfügen, können die VMs nur migriert werden, wenn sie vorher ausgeschaltet wurden. Aus diesem Grund muss die bereitgestellte 500GB iSCSI Festplatte an die beiden Server angebunden werden.

Hinzufügen der iSCSI Festplatte
Die folgenden Schritte müssen bei beiden Server getätigt werden, damit beide Zugriff auf die iSCSI Festplatte erhalten:

1. Man öffnet im vSphere Client die Netzwerkkonfiguration auf dem ESXi Server und klickt auf Netzwerk hinzufügen.
2. Im Assistenten wählt man ein VMkernel-Netzwerk und danach die Netzwerkkarte aus, welche sich in dem Netzwerk mit dem iSCSI befindet.
3. Danach gibt man dem Netzwerk einen Namen (hier VMkernel - iSCSI) und wählt den Netzwerktyp (IP oder IP und IPv6) aus.
4. In dem nachfolgenden Dialog muss die IP-Adresse und die Netzwerkmaske eingetragen werden, welche man vorher von einem Laboringenieur erhalten hat.
5. Der neu erstellte vSphere Standard-Switch erscheint nun in den Netzwerkeinstellungen. 6. Nachdem das neue Netzwerk hinzugefügt wurde, muss zur Ansicht "Speicheradapter-Konfiguration" gewechselt werden. Hier klicken wir auf Hinzufügen und erstellen einen neuen iSCSI Software Adapter.
7. Bei dem Assistenten wählen wir das neu erstellte Netzwerk aus, welches damit die iSCSI-Port-Bindung aktiviert bekommt.
8. Danach wird unter dem Reiter "Dynamische Erkennung" die iSCSI-Festplatte mithilfe der IP und des Ports hinzugefügt. Die benötigten CHAP-Anmeldedaten erhalten wir wieder von den Laboringenieuren.
9. Nachdem die iSCSI-Festplatte hinzugefügt wurde, muss sie noch in VMFSS formatiert werden, damit sie von den ESXi Servern benutzt werden kann. Diese Abfrage erscheint aber nur auf dem Server, welcher die Festplatte als erstes zugewiesen bekommt. Der zweite Server erkennt das vorhandene VMFSS und bindet die Festplatte sofort ein.

Aktivieren von vMotion
Nachdem die beiden Server eine gemeinsame Festplatte besitzen, kann daraufhin das vMotion aktiviert werden. Ohne vMotion funktioniert keine Migration, weder die Live-Migration noch eine Cold-Migration. Die Aktivierung von vMotion erfolgt in der Netzwerkkonfiguration des vSphere Standard-Switches. Es muss ein Netzwerk ausgewählt werden, in dem sich alle Server befinden. Dies ist bei unserer Konfiguration bei beiden Netzwerken der Fall. Es wurde das erste Netzwerk gewählt, da dieses Netzwerk nicht den Datenverkehr der iSCSI-Festplatte beeinflusst. Unter Einstellungen -> Management Network -> Bearbeiten muss nun die Funktion vMotion aktiviert werden. Wenn nun eine Migration in Auftrag gegeben wird, wird sie über diese Netzwerkkarte gesendet.

Erstellen einer VM

Um den ESXi Server einfacher administrieren zu können, wird der vSphere Client auf einem Windows Rechner installiert. Mit dem vSphere Client können neue virtuelle Maschinen auf dem Server angelegt werden. Die Konfiguration der VMs erfolgt auch über den vSphere Client. Das Interface dazu erinnert an den VMware Player. Zusätzlich gibt es einen Reiter Ressourcen, in diesen Reiter können Reservierungen und Grenzwerte der einzelnen Ressourcen für die VM vorgenommen werden.

Die einzelnen Reservierungen/Grenzwerte sind:

CPU
Reservierung und Grenzwert der CPU-Frequenz in MHz.
Der maximale Reservierungswert hängt von der Geschwindigkeit und der Anzahl an CPUs ab, die der VM zugewiesen wurden.
Die reservierten MHz werden der VM garantiert und die VM kann nicht über höhere MHz verfügen als im Grenzwert angegeben.
Zusätzlich kann man über die Option Anteile die Priorität der VM für den Scheduler setzen.
RAM
Reservierung/Grenzwert des RAMs in MB.
Dies garantiert der VM, dass der reservierte RAM zur Verfügung steht. Die VM kann nicht mehr RAM bekommen als im Grenzwert angegeben.
Festplatte
Einschrenkung der Festplattenzugriffe der VM in IOPs.
Hier kann der Grenzwert für die Festplattenzugriffe eingestellt werden. Jede Festplatte kann einzeln eingestellt werden.

Ausserdem können hier auch ISO Images in die VM als virtuelle CD/DVD eingebunden werden. Mithilfe der Konsole kann man sich die Ausgaben der VM anzeigen lassen. Die Installation einer VM läuft genau so ab, wie die Installation eines normalen Rechners.
Bei der Erstellung der VM muss als Gastbetriebssystem Anderes 2.6x Linux-System (64-Bit) ausgewählt werden, auch wenn das Beriebsystem später mit einem 3.x Kernel läuft. Wenn korrekterweise Anderes Linux-System (64-Bit) ausgewählt wird, ist die Hotplugfunktion von CPU und RAM nicht vorhanden.
Als Betriebssystem wird Debian 7 (wheezy) auf den VMs installiert. Dafür wird die Netzinstallations-CD als Image in die VM eingebunden und ohne Netzwerk installiert. Nach der Installation sind nur die nötigsten Programme auf der VM installiert. (vi, nano, top, usw...)
Um Zugriff auf das Internet zu erhalten, muss nach der Installation der Proxy-Server eingestellt werden. Der folgenden Befehl:

export http_proxy="http://proxy.vs.cs.hs-rm.de:3128/"

stellt den HTTP-Proxy ein und ermöglicht es, mit der Paketverwaltung neue Software zu installieren.

libvirt

Um die benötigten Messdaten aus den VMs zu bekommen und die verschiedenen VMs managen zu können, sollte die Bibliothek libvirt eingesetzt werden.
Libvirt ist sehr bekannt und wird auch in der Paketverwaltung von Debian angeboten. Das Paket libvirt-dev enthält libvirt in der Version 1.1.2-3. Das Paket wurde allerdings ohne die VMWare ESX Unterstützung kompiliert, sodass es für unseren Zweck nicht benutzt werden kann.

libvirt kompilieren

Da die Version von libvirt nicht aus der Paketverwaltung genommen werden kann, muss eine Version aus den Quellen gebaut werden. Die aktuelle Version von libvirt ist 1.1.3-2 und befindet sich auf der Homepage zum Download.
Nach dem Herunterladen und Entpacken des Archives müssen noch Abhängigkeiten installiert werden, dies geschieht mit

apt-get install gcc make libxml2-dev libdevmapper-dev libcurl4-openssl-dev python-dev libnl-dev

Danach kann libvirt konfiguriert werden, damit es ESXi unterstützt:

./configure --with-esx --prefix=/opt

Am Ende der Konfiguration werden die einzelnen Systeme aufgelistet:

configure: Configuration summary
configure: =====================
configure:
configure: Drivers
configure:
configure:       Xen: yes
configure:      QEMU: yes
configure:       UML: yes
configure:    OpenVZ: yes
configure:    VMware: yes
configure:      VBox: yes
configure:    XenAPI: no
configure:  xenlight: no
configure:       LXC: yes
configure:      PHYP: yes
configure:       ESX: yes
configure:   Hyper-V: no
configure: Parallels: yes
configure:      Test: yes
configure:    Remote: yes
configure:   Network: yes
configure:  Libvirtd: yes
configure: Interface: no
configure:   macvtap: yes
configure:  virtport: yes

Hier sieht man, dass ESX und VMware aktiviert wurde. Nun muss libvirt nur noch gebaut werden:

make 
sudo make install

Da libvirt im /opt Verzeichnis installiert wurde, muss der Pfad noch dem Linker übergeben werden. Ansonsten würde der Aufruf des später kompilierten Programmes nicht erfolgreich sein.

export LD_LIBRARY_PATH=/opt/lib:$LD_LIBRARY_PATH

Programme mit libvirt schreiben

Anhand des folgendem Quellcodes wird verdeutlicht, wie ein C-Programm mit der libvirt Bibliothek geschrieben werden kann.

 1 #include <stdio.h>
 2 #include <stdlib.h>
 3 #include <libvirt/libvirt.h>
 4 #include <string.h>
 5 
 6 int main(int argc, char *argv[])
 7 {
 8  virConnectPtr conn;
 9  int i, ret;
10  int numDomains;
11  int *activeDomains;
12  virDomainPtr dom;
13  /* Open a new connection to the vSphere Server and select the ESX host miraculix. */
14  conn = virConnectOpenAuth("vpx://10.18.48.228/Management/miraculix.vs.cs.hs-rm.de/?no_verify=1", virConnectAuthPtrDefault, 0);
15  if (conn == NULL) {
16         fprintf(stderr, "Failed to open connection to ESX on 10.18.48.228\n");
17         return 1;
18  }
19  /* Get the number of activated VMs */
20  numDomains = virConnectNumOfDomains(conn);
21  activeDomains = malloc(sizeof(int) * numDomains);
22  numDomains = virConnectListDomains(conn, activeDomains, numDomains);
23 
24  /* Print the VM ID and the VM name */
25  printf("Active domain IDs, Name:\n");
26  for (i = 0 ; i < numDomains ; i++) {
27   printf(" %d,", activeDomains[i]);
28   dom = virDomainLookupByID(conn, activeDomains[i]);
29   printf(" %s\n", virDomainGetName(dom));
30  }
31  free(activeDomains);
32 
33  /* Change the Memorylimit of the last VM to 1 GB */
34  ret = virDomainSetMemory(dom,1024000);
35 
36  if (ret){
37         fprintf(stderr, "Failed to change RAM limit.\n");
38         return 1;
39  }
40 
41  return 0;
42 }

In Zeile 3 wird libvirt eingebunden, sodass die Funktionen aus der Bibliothek benutzt werden können.
Zeile 14 öffnet eine neue Verbindung zu dem vSphere Server und wählt den ESX Server miraculix aus. Der Parameter ?no_verify=1 aus der URL überspringt die Zertifikatsüberprüfung der SSL Verbindung und der Parameter virConnectAuthPtrDefault erzeugt eine Passwortabfrage auf der Konsole, sobald das Programm gestartet wurde.
Die nachfolgenden Zeilen fragen den vSphere Server nach allen laufenden VMs und geben die ID und den Namen der VM aus. Zusätzlich wird das Limit des RAMs auf der letzten ausgegebenen VM auf 1024 MB gesetzt.

Zum Kompilieren der Datei muss dann folgender Befehl ausgeführt werden:

gcc -g -Wall -I/opt/include main.c -o libvirtProgram -L/opt/lib -lvirt

Nach dem Ausführen des libvirtProgram kommt die Aufforderung für den Benutzernamen und das Passwort.

Nachteile von libvirt

Der ESX-Support von libvirt ist anscheinend nicht so gut, wie bei anderen Hypervisor. Während der Tests sind des Öfteren Speicherzugriffsfehler und Fehler beim Aufruf von free() aufgetreten. Diese Fehler treten sporadisch in den Bibliotheken libxml2 und libvirt auf und verhindern dadurch den fehlerfreien Ablauf des erstellten Programmes.

Zusätzlich dazu sind nicht alle Funktionen in den ESX-Treibern von libvirt implementiert. Deshalb kommen bei manchen Funktionsaufrufen Fehlermeldungen z.B.:

virDomainGetHostname - error : this function is not supported by the connection driver: virDomainGetHostname
virDomainMemoryStats - Domain error : this function is not supported by the connection driver: virDomainMemoryStats
virDomainSetMemoryFlags - error : this function is not supported by the connection driver: virDomainSetMemoryFlags
virDomainSetMaxMemory - ESX Driver error : Requested operation is not valid: Domain is not powered off

Deshalb können die Limits der Netzwerke und die der Festplatten nicht von libvirt gesetzt oder gelesen werden, da die Funktionen dafür nicht in libvirt implementiert sind.

vSphere Management SDK

Das vSphere Management SDK beinhaltet unter anderem das vSphere Web Services SDK.
Das vSphere Web Services SDK bietet die Möglichkeit den Webservice des vSphere Servers über die SOAP-Schnittstelle zu verwenden. Mithilfe der WSDL-Datei können die clientseitigen Schnittstellen generiert werden.
Das SDK beinhaltet weiterhin noch Beispiele in Java (JAX-WS) und C#. Diese Beispiele zeigen, wie man mithilfe der erstellen Bibliothek auf den vSphere Server zugreifen kann.

Einrichtung

Nachdem das vSphere Web Services SDK in der Version 5.0.0 heruntergeladen wurde, muss es entpackt werden.
Nach dem Entpacken müssen folgende Umgebungsvariablen gesetzt werden:

JAVAHOME 
Der Pfad zur aktuellen JRE.
CLASSPATH 
Der Pfad zur Beispieldatei samples.jar und vim25.jar (Wird nur für die Beispiele benötigt).
VMKEYSTORE 
Der Datei, welche den Keystore enthält.

Um den Keystore für den vSphere Server zu erstellen, muss man sich mit SSH auf den vSphere Server verbinden. Auf dem Server gibt es die Zertifikats-Datei rui.crt im Verzeichnis /etc/vmware/ssl/. Dieses Zertifikat wird mit SCP auf den Arbeitsrechner kopiert und mit dem Befehl:

keytool -import -file rui.crt -alias vSphere -keystore vmware.keystore

ein neuer Keystore mit dem Namen vmware.keystore angelegt.

Verwendung des SDK

Um das vSphere Web Services SDK in einer eigenen Anwendung verwenden zu können, muss die vim25.jar Bibliotheksdatei zum Build-Path hinzugefügt werden. Danach können alle Aufrufe an den Webservice von dem eigenen Programm aus getätigt werden.

Dokumentation zum Aufsetzen der Umgebung
Developer's Setup Guide
Hilfe bei der Entwicklung
Programming Guide
API Dokumentation
vSphere API Reference

Das nachfolgende Beispiel zeigt, wie man mithilfe des vSphere SDK die gewünschten Informationen der PMs erhalten kann.
Beispiel:

228 public List<ManagedObject> collectPM() throws RuntimeFaultFaultMsg,
229 			InvalidPropertyFaultMsg {
230 		LinkedList<ManagedObject> result = new LinkedList<ManagedObject>();
231 		LinkedList<String> list = new LinkedList<String>();
232 
233                 //Needed values of the system
234 		list.add("summary.hardware.uuid");
235 		list.add("summary.hardware.memorySize");
236 		list.add("summary.hardware.cpuMhz");
237 		list.add("summary.hardware.numCpuCores");
238 		list.add("summary.quickStats.overallCpuUsage");
239 		list.add("summary.quickStats.overallMemoryUsage");
240 		list.add("summary.config.name");
241 		list.add("summary.host");
242 		list.add("config.network.portgroup");
243 		list.add("configManager.networkSystem");
244 
245                 //Collect "HostSystem", which means PM
246 		RetrieveResult props = collectFromvSphere("HostSystem", list);
247 		PM host = null;
248 		if (props != null) {
249                         //Retrive the PM data from the vSphere
250 			for (ObjectContent oc : props.getObjects()) {
251                                 //The list of the requestet properties
252 				List<DynamicProperty> dps = oc.getPropSet();
253                                 //Add the PM to the list
254 				if (host != null && !result.contains(host)) {
255 					result.add(host);
256 				}
257                                 //If the list isn't empty
258 				if (dps != null) {
259 					host = new PM();
260                                         //The requested values of the PM
261 					for (DynamicProperty dp : dps) {
262                                                 //Switch over the name (Java 1.7)
263 						switch (dp.getName()) {
264 						case "summary.hardware.uuid":
265 							host.setUuid((String) dp.getVal());
266 							break;
267 						case "summary.hardware.cpuMhz":
268 							host.setCpuMhz((Integer) dp.getVal());
269 							break;
270 						case "summary.hardware.memorySize":
271 							host.setRamSize((Long) dp.getVal());
272 							break;
273 						case "summary.hardware.numCpuCores":
274 							host.setCpuCores((Short) dp.getVal());
275 							break;
276 						case "summary.quickStats.overallCpuUsage":
277 							host.setCpuUsage((int) dp.getVal());
278 							break;
279 						case "summary.quickStats.overallMemoryUsage":
280 							host.setRamUsage((int) dp.getVal());
281 							break;
282 						case "summary.config.name":
283 							host.setName((String) dp.getVal());
284 							break;
285 						case "summary.host":
286 							host.setMor((ManagedObjectReference) dp.getVal());
287 							break;
288 						case "config.network.portgroup":
289 							ArrayOfHostPortGroup ahpg = (ArrayOfHostPortGroup) dp
290 									.getVal();
291 							for (HostPortGroup hpg : ahpg.getHostPortGroup()) {
292                                                                 //The network is always on vSwitch0
293 								if (hpg.getVswitch().equals(
294 										"key-vim.host.VirtualSwitch-vSwitch0")) {
295                                                                         //Ignore the management and the iSCSI network
296 									if (!(hpg.getKey()
297 									    .equals("key-vim.host.PortGroup-Management Network")
298 									    || hpg.getKey()
299 									    .equals("key-vim.host.PortGroup-VMkernel - iSCSI"))) {
300 										host.getPortGroup().add(hpg);
301 									}
302 								}
303 							}
304 							break;
305 						case "configManager.networkSystem":
306 							host.setNetworkSystem((ManagedObjectReference) dp.getVal());
307 							break;
308 
309 						default:
310 							System.out.println(dp.getName() + " = " + dp.getVal().toString());
311 						}
312 
313 					}
314 
315 				}
316 			}
317 		}
318 		if (host != null && !result.contains(host)) {
319 			result.add(host);
320 		}
321 
322 		return result;
323 	}

Collector.java

Das nächste Beispiel zeigt, wie man die Limits der VMs setzten kann. Dafür muss allerdings die ManagedObjectReference der VM vorhanden sein. Diese bekommen wir vom vSphere Webservice.

38 	public static void setCPULimit(VM vm, Long limit)
39 			throws ConcurrentAccessFaultMsg, DuplicateNameFaultMsg,
40 			FileFaultFaultMsg, InsufficientResourcesFaultFaultMsg,
41 			InvalidDatastoreFaultMsg, InvalidNameFaultMsg,
42 			InvalidStateFaultMsg, RuntimeFaultFaultMsg, TaskInProgressFaultMsg,
43 			VmConfigFaultFaultMsg {
44                 //Create a new spezification for the VM
45 		VirtualMachineConfigSpec spec = new VirtualMachineConfigSpec();
46                 //Create a new allocation for a ressource
47 		ResourceAllocationInfo info = new ResourceAllocationInfo();
48                 //Set the new limit
49 		info.setLimit(limit);
50                 //Set the limit to the CPU
51 		spec.setCpuAllocation(info);
52                 //Get the object reference of the VM
53 		ManagedObjectReference mof = vm.getMor();
54                 //Invoke the soap operation to reconfigure the VM
55 		Connection.getVimPort().reconfigVMTask(mof, spec);
56 	}

Manage.java

SNMP

Damit man die benötigten Messwerte auch innerhalb der VM abfragen kann, wird in der VM über den Paketmanager ein SNMP-Daemon installiert. Der Befehl dafür lautet:

apt-get install snmpd

Damit man später über das Netzwerk SNMP Anfragen an das System senden kann, muss die Konfigurationsdatei des SNMP-Daemon angepasst werden. Die Konfigurationsdatei befindet sich unter /etc/snmp/snmpd.conf.

#  Listen for connections from the local system only
#agentAddress  udp:127.0.0.1:161
#  Listen for connections on all interfaces (both IPv4 *and* IPv6)
agentAddress udp:161,udp6:[::1]:161

Zusätzlich wird noch ein neuen Nutzer angelegt, um die für SNMPv3 hinzugefügte ACL benutzen zu können.

createUser ESXManagment  MD5 "Managment12345" DES
rouser   ESXManagment

Nach dem Neustart des SNMP-Daemon kann man nun von jedem Rechner im Netzwerk auf den SNMP Dienst zugreifen. Falls der Rechner sich über eine VPN-Verbindung an das Netzwerk angeschlossen ist, werden die UDP-Pakete nicht weitergeroutet. In diesem Fall kann man das SNMP über das TCP-Protokoll laufen lassen, welches fehlerfrei über die VPN-Verbindung geroutet wird. Die Einstellung in der /etc/snmp/snmpd.conf dafür lautet:

agentAddress udp:161,udp6:[::1]:161,tcp:161

Die OIDs, welche für das Management der VMs abgefragt werden, sind aktuell:

.1.3.6.1.4.1.2021.11.11.0         UCD-SNMP-MIB::ssCpuIdle.0 = INTEGER: 98
.1.3.6.1.4.1.2021.4.5.0           UCD-SNMP-MIB::memTotalReal.0 = INTEGER: 1027024 kB
.1.3.6.1.4.1.2021.4.6.0           UCD-SNMP-MIB::memAvailReal.0 = INTEGER: 700420 kB
.1.3.6.1.4.1.2021.13.15.1.1.2.2   UCD-DISKIO-MIB::diskIODevice.2 = STRING: sda
.1.3.6.1.4.1.2021.13.15.1.1.5.2   UCD-DISKIO-MIB::diskIOReads.2 = Counter32: 223808
.1.3.6.1.4.1.2021.13.15.1.1.6.2   UCD-DISKIO-MIB::diskIOWrites.2 = Counter32: 315247
.1.3.6.1.2.1.31.1.1.1.1.2         IF-MIB::ifName.2 = STRING: eth0
.1.3.6.1.2.1.31.1.1.1.10.2        IF-MIB::ifHCOutOctets.2 = Counter64: 3258467

SNMP auf ESXi 5

Wenn man mit SNMPv3 Anfragen an einen ESXi Server abschicken will, benötigt man auch hier einen Benutzer. Ob dieser sich dann authentifizieren oder eine verschlüsselte Übertragung benutzen muss stellt man mit den folgenden Befehlen ein:

esxcli system snmp set --authentication MD5
esxcli system snmp set --privacy none

Um danach einen Benutzer anlegen zu können, muss zuerst ein Hash erzeugt werden, welcher für die Authentifizierung benötigt wird. Der Befehl dazu lautet:

esxcli system snmp hash -A Management1234567890 --raw-secret

Als Ergebnis bekommt man den gewünschten Hash:

  Authhash: 977ea1965fec5b7fadaa1636fdd8bea2
  Privhash:

Mit diesem Hash kann man nun einen neuen Benutzer anlegen.

esxcli system snmp set --users ESX/977ea1965fec5b7fadaa1636fdd8bea2/-/auth

Danach muss der SNMP-Daemon gestartet werden. Dies kann über die Weboberfläche geschehen.
Die Option dafür steht unter Verwalten->Einstellungen->Sicherheitsprofil->Dienste->Bearbeiten

Der SNMP-Dienst auf den ESXi Servern bietet kein RMON der virtuellen Switches an. Die vitrtuellen Switches werden nur als Netzwerk-Interface dargestellt und haben daher die Darstellung der IF-MIB (OID .1.3.6.1.2.1.31.1.1.1).

Ansatz

Für das Management der VMs werden die Limits des Hypervisors benutzt. Dabei kann man jeder Ressource (CPU, RAM, Festplatten-I/O, Netzwerk-I/O) einer VM ein maximales Limit geben. Der Hypervisor erhöht die Ressource einer VM nicht mehr, wenn diese das Limit erreicht hat.
Beispiel (Festplatten IOPs Limit. Getestet mit fio):

Limit von 100 I/O-Operationen pro Sekunde
Jobs: 1 (f=1): [M] [100.0% done] [188K/212K /s] [47 /53  iops] [eta 00m:00s]
Limit von 500 I/O-Operationen pro Sekunde
Jobs: 1 (f=1): [M] [100.0% done] [1092K/908K /s] [273 /227  iops] [eta 00m:00s]
Ohne Limit (747 I/O-Operationen pro Sekunde / Das Limit des iSCSI)
Jobs: 1 (f=1): [M] [100.0% done] [1456K/1532K /s] [364 /383  iops] [eta 00m:00s]

Management der VMs

Für das Management der VMs müssen folgende Informationen, über den Webservice oder SNMP, für PMs und VMs abrufbar sein:

CPU Auslastung in %       
CPU Auslastung in MHz   
RAM Auslastung in %    
RAM Auslastung in MB  
IOPs der Festplatte  (Nur über SNMP der VM)  
Auslastung des Netzwerks (Nur über SNMP der VM)

Um die Limits der VMs einstellen zu können, müssen folgende Funktionen implementiert sein:

CPU Limit setzen
RAM Limit setzen
IOPs Limit setzen
Netzwerk Limit setzen
Livemigration von VMs


Da es sich bei der eingesetzten Lizenz des ESXi Servers um die Enterprise Version handelt, sind laut der Preislisten folgende Features nicht enthalten:

  • Distributed Switch™
  • Storage DRS™ and Profile-Driven Storage
  • I/O Controls (Network and Storage) and SR-IOV
  • Host Profiles and Auto Deploy
  • Flash Read Cache
  • App HA

Gerade der Distributed Switch und die I/O Controls sind interessante Features. Leider kann man auf beide Features während des Master-Projekts nicht zugreifen. Deshalb ist es nur möglich, die gesamten IOPs der Festplatte auszulesen und zu limitieren und zusätzlich den ausgehenden Netzwerkverkehr zu limitieren. Mithilfe der Features wäre es möglich, feinere Einstellungen einfacher vorzunehmen.

ActiveMQ

Die Anwendung, welche auf den VMs läuft und überwacht wird, ist Apache ActiveMQ in der Version 5.9.0.
ActiveMQ ist ein in Java implementierter Nachrichtenserver, welcher verschiedene Protokolle unterstützt. In dieser Umgebung wird er als MQTT Broker eingesetzt, um Nachrichten in einem Publish/Subscribe Pattern an die abonnierten Dienste weiterleitet.

Apache ActiveMQ kann hier heruntergeladen werden.

Nach dem Entpacken des Archives kann eine neue Konfigurationsdatei mit dem folgenden Befehl angelegt werden:

 ./bin/activemq setup /home/fabian/.activemqrc

Diese Konfigurationsdatei wird automatisch verwendet, wenn man ActiveMQ mit den folgenden Befehl startet:

./bin/activemq start


Standardmäßig sind bei ActiveMQ mehrere Protokolle aktiviert. Da wir aber für dieses Projekt nur MQTT benötigen, deaktivieren wir die übrigen Protokolle in der ./conf/activemq.xml Datei:

111         <transportConnectors>
112             <!-- DOS protection, limit concurrent connections to 1000 and frame size to 100MB -->
113         <!--
114             <transportConnector name="openwire" uri="tcp://0.0.0.0:61616?maximumConnections=1000&amp;wireFormat.maxFrameSize=104857600"/>
115             <transportConnector name="amqp" uri="amqp://0.0.0.0:5672?maximumConnections=1000&amp;wireFormat.maxFrameSize=104857600"/>
116             <transportConnector name="stomp" uri="stomp://0.0.0.0:61613?maximumConnections=1000&amp;wireFormat.maxFrameSize=104857600"/>
117             <transportConnector name="mqtt" uri="mqtt://0.0.0.0:1883?maximumConnections=1000&amp;wireFormat.maxFrameSize=104857600"/>
118             <transportConnector name="ws" uri="ws://0.0.0.0:61614?maximumConnections=1000&amp;wireFormat.maxFrameSize=104857600"/>
119         -->
120             <transportConnector name="mqtt" uri="mqtt://0.0.0.0:1883?maximumConnections=1000&amp;wireFormat.maxFrameSize=104857600"/>
121         </transportConnectors>


Damit man von extern auf den JMX-Dienst zugreifen kann, müssen an verschiedenen Dateien Änderungen vorgenommen werden:
./conf/activemq.xml
Wird dafür benötigt, dass ActiveMQ keinen eigenen JMX-Dienst erstellt sondern den JMX-Dienst der JVM benutzt.

70         <managementContext>
71             <managementContext createConnector="false"/>
72         </managementContext>


./conf/
Ohne die Einschränkung startet der Server nicht.

chmod 600 jmx.*


~/.activmqrc
Setzt den JMX Port auf 1099 und legt die Benutzer- und Passwortdatei fest.

140 ACTIVEMQ_SUNJMX_START="-Dcom.sun.management.jmxremote.port=1099"
141 ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START -Dcom.sun.management.jmxremote.password.file=${ACTIVEMQ_CONF}/jmx.password"
142 ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START -Dcom.sun.management.jmxremote.access.file=${ACTIVEMQ_CONF}/jmx.access"
143 ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START -Dcom.sun.management.jmxremote.ssl=false"
144 #ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START -Dcom.sun.management.jmxremote"


152 Sorgt dafür, dass das Script den ActiveMQ Broker sauber herunterfahren kann.
153 ACTIVEMQ_SUNJMX_CONTROL="--jmxurl service:jmx:rmi:///jndi/rmi://10.18.48.227:1099/jmxrmi --jmxuser admin --jmxpassword activemq"
154 #ACTIVEMQ_SUNJMX_CONTROL=""


/etc/hosts
Wenn in der hosts-Datei der Name der VM mit 127.0.0.1 aufgelöst wird, kann man von extern nicht auf den JMX-Dienst zugreifen. Deshalb muss hier die externe IP-Adresse stehen.

10.18.48.227    Debian-VM.vs.cs.hs-rm.de        Debian-VM


ActiveMQ selbst kompilieren

Wenn man Änderungen an ActiveMQ vornehmen möchte, wie z.B. eine Änderung des Verhaltens der Counter, muss der ActiveMQ-Quellcode angepasst werden. Der Quellcode von ActiveMQ befindet sich in einem GIT Repository auf GitHub. Um den Quellcode herunterzuladen, legt man einen lokalen Clone mit

git clone https://github.com/apache/activemq.git

an.
Die einzelnen Releases von ActiveMQ sind mit tags versehen, welche man unter anderem auf der GitHub-Webseite einsehen kann. Das Kompilieren des aktuellen Trunks funktioniert selten. Um zu einem bestimmten Tag zu wechseln, wird folgender Befehl ausgeführt:

git checkout tags/activemq-5.9.0

Durch diesen Befehl wechselt GIT die Dateien in den Tag activemq-5.9.0.

Um ActiveMQ zu kompilieren, muss Apache Maven vorhanden sein. ActiveMQ 5.9.0 benötigt die Version 3.0.5 von Maven, mit der neueren Version 3.1.1 kommt es beim Kompilieren zu Fehler, welche das Kompilieren abbrechen lassen. Um ActiveMQ schnell kompilieren zu lassen, können die Tests übersprungen werden. Der Befehl dazu lautet:

mvn clean install -Dmaven.test.skip=true

Wenn sich der Rechner hinter einen Proxy-Server befindet kann es dazu führen, dass Maven keine Pakete aus dem Internet herunterladen kann. Um einen Proxy in Maven einzutragen, muss die Datei settings.xml im Verzeichnis ~/.m2/ angelegt werden. Der Inhalt der Datei lautet für die Hochschule ist folgender:

 1 <settings>
 2   <proxies>
 3    <proxy>
 4       <active>true</active>
 5       <protocol>http</protocol>
 6       <host>proxy.vs.cs.hs-rm.de</host>
 7       <port>3128</port>
 8     </proxy>
 9   </proxies>
10 </settings>

JMX

Das Managen einer laufenden ActiveMQ Anwendung erfolgt über die JMX-Schnittstelle. Der benötigte Port (1099) und der Benutzer (admin) wurden, wie bereits gezeigt, beim Starten gesetzt. Um ActiveMQ manuell zu managen, kann das Programm jConsole verwendet werden. jConsole befindet sich bei jeder JDK-Installation im bin Verzeichnis. Damit das spätere Programm zum automatischen Managen die Werte auslesen und die Funktionen ausführen kann, muss das Programm mit dem JMX-Agent kommunizieren können.
Der folgende Beispiel-Javacode liest den Wert eines Counters aus und ruft danach die Resetfunktion auf:

 1 public static void readAndReset() throws InstanceNotFoundException,
 2 			MBeanException, ReflectionException, IOException,
 3 			MalformedObjectNameException, AttributeNotFoundException {
 4                 /* Connect to 10.18.48.227 at port 1099 */
 5 		JMXServiceURL url = new JMXServiceURL(
 6 				"service:jmx:rmi:///jndi/rmi://10.18.48.227:1099/jmxrmi");
 7                 /* Username and password */
 8 		String[] creds = { "admin", "activemq" };
 9 		Map<String, Object> env = new HashMap<String, Object>();
10 		env.put(JMXConnector.CREDENTIALS, creds);
11 		JMXConnector jmxc = JMXConnectorFactory.connect(url, env);
12 
13                 /* Connection to the MBean Server */
14 		MBeanServerConnection conn = jmxc.getMBeanServerConnection();
15 
16 		/* Get the MBean for the MQTT topic /topic/event 
17                  * The Broker name localhost was written on the console while starting ActiveMQ
18                  */
19 		ObjectName activeMQ = new ObjectName(
20 				"org.apache.activemq:type=Broker,brokerName=localhost,destinationType=Topic,destinationName=.topic.event");
21 
22                 /* Get the value of the attribute AverageEnqueueTime */
23 		Object result = conn.getAttribute(activeMQ, "AverageEnqueueTime");
24 		System.out.println("Result: " + result);
25 
26                 /* Reset all statistics of the Topic */
27 		conn.invoke(activeMQ, "resetStatistics", null, null);
28 
29                 /* Get the value of the attribute AverageEnqueueTime */
30 		result = conn.getAttribute(activeMQ, "AverageEnqueueTime");
31 		System.out.println("Result after reset: " + result);
32 	}

Die Konsolenausgabe des Programmes lautet:

Result: 1153.5316140020072
Result after reset: 0.0

Es wurde der aktuelle Wert ausgelesen und danach die Resetfunktion aufgerufen.

ActiveMQ und MQTT Nachforschungen

ActiveMQ bezieht sich bei Queue und Topic-Zeiten immer auf die gesamte Lebensdauer.
DestinationView.java

1 public double getAverageEnqueueTime() {
2         return destination.getDestinationStatistics().getProcessTime().getAverageTime();
3 }

BaseDestination.java

1 protected final DestinationStatistics destinationStatistics = new DestinationStatistics();

DestinationStatistics.java

1 protected TimeStatisticImpl processTime;

TimeStatisticImpl.java

1 public synchronized double getAverageTime() {
2         if (count == 0) {
3             return 0;
4         }
5         double d = totalTime;
6         return d / count;
7 }



MQTT besitzt keine Priorisierung von Nachrichten in einer Queue. Auch in der Spezifikation von MQTT V3.1 wird dies nicht erwähnt. Das Nachrichtenformat besitzt kein Bit, welches eine Priorisierung erlaubt.

Finale Projektumgebung

Die folgende Umgebung wurde für das Projekt verwendet:

Implementierungsumgebung
Software Management Schnittstelle
Server VMware ESXi 5.0 vSphere SOAP Webservice
VM Debian 7 SNMP
Anwendung ActiveMQ JMX

Über die drei Management-Schnittstellen können die für das Management benötigten Werte ausgelesen werden. Auch um die angepassten Werte schreiben zu können, werden die Management-Schnittstellen des vSphere Webservice und von JMX verwendet. Dabei können die Limits der einzelnen VM über den Webservice gesetzt oder es können die VMs untereinander migriert werden. Mithilfe von JMX kann z.B. der Garbage Collector der JVM gestartet werden, um nicht mehr benötigten Arbeitsspeicher freizugeben.

Intervalle der ausgelesenen Werte

In der folgenden Tabelle werden die Intervalle angezeigt, in der die Werte aktualisiert werden. Wenn es sich dabei nicht um das gewöhnliche Intervall handelt, wird dieses in Klammern angegeben.

Webservice SNMP JMX
CPU-Auslastung 5 s (20 s) 3 5 s (60 s) 2
RAM-Auslastung 5 s (20 s) 3 1 s
Netzwerk-Auslastung 1 s (15 s) 1
Festplatten-Auslastung 1 s
Anwendungsauslastung 1 s

1 nmpset -v3 -lauthNoPriv -uESXManagment -AManagment12345 127.0.0.1 1.3.6.1.4.1.8072.1.5.3.1.2.1.3.6.1.2.1.2.2 i 1
2 OID .1.3.6.1.4.1.2021.11.53.0
3 Ändern der /etc/vmware/hostd/config.xml, Zeile: 583 zu <collectionInterval> 5 </collectionInterval>

Paralleles auslesen der SNMP Daten

Das sequenzielle Abfragen der VMs über SNMP funktioniert mit den Standardparametern ohne Probleme. Erst als die Abfragen parallel mit Threads ausgeführt wurden zeigte sich, dass nur eine Anfrage beantwortet wurde. Die restlichen SNMP Anfragen hatten einen Timeout, welcher auch nach dem erhöhen der Timeoutzeit auf 20 Sekunden auftrat. Die benutzte SNMP-Bibliothek, ist SNMP4J und laut Angaben der Entwickler für eine Multi-Threaded Anwendung geeignet. Nach langer Recherche stellte sich heraus, dass die Engine-ID der VMs dieselben waren, da die VMs geklont wurden. In der snmpd.conf muss folgender Eintrag ergänzt werden, damit alle VMs eine unterschiedliche Engine-ID bekommen:

engineIDType 3

Durch den Parameter 3 wird zur Generierung der Engine-ID die MAC-Adresse des eth0 Interfaces benutzt. Dadurch ist sichergestellt, dass jede VM eine eigene Engine-ID hat. Der Parameter 1 und 2 für die Verwendung der IP-Adresse als Zufallsparameter für die Engine-ID funktioniert nicht wie erwartet. Die Engine-ID der VMs bleiben die gleiche, obwohl die IP-Adressen unterschiedlich sind. Und damit gibt es einen sofortigen Timeout der parallelen Anfrage.

Implementierung

Zum Managen des Systems wurde ein Programm entwickelt, welches die benötigten Werte des Systems ausliest und die Parameter der VMs anpasst. Dieses Programm ist in Java 1.7 geschrieben. Die folgenden Bibliotheken werden zum Managen verwendet:

  • snmp4j-2.2.4.jar (SNMP)
  • vim25.jar (Webservice)

JMX benötigt keine externe Bibliothek. Alle Dateien befindet sich schon im Java 1.7 JRE/JDK.

Der Ablauf des Programms ist wie folgt:

1. Rufe die Daten über den Aufbau der PMs und VMs mithilfe des Webservice ab
2. Hole die aktuellen Werte für die PMs und VMs (Webservice, SNMP, JMX)
3. Prüfe auf eine Grenzwertüberschreitung für jede PM und VM
4. Wenn eine VM einen Grenzwert überschritten hat, erhöhe/verringere die Ressource
5. Wenn eine PM den Grenzwert überschritten hat, migriere eine VM
6. Warte X Sekunden
7. Springe zu Punkt 2.
Weiter unten befindet sich auch ein Sequenzdiagramm zum Ablauf.


Die ausgelesenen Werte werden für jede VM/PM gespeichert, sodass man auch einen Vergleich über einen längeren Zeitraum anstellen kann. Die Werte werden in den Unterklassen der IntervalData-Klasse gepeichert. Jeder Type (VM, PM, ActiveMQ) besitzt eine eigene IntervalXXData-Klasse. Außerdem werden die IntervalData-Klassen dafür benötigt, aus den Counter-Angaben der SNMP-Abfragen die gewünschten Werte zu errechnen. Dafür wird die Differenz der Counter von der letzten Abfrage mit dem Counter der aktuellen Anfrage gebildet. Diese Differenz wird durch die Länge des Intervalls geteilt, um den Wert pro Sekunde herauszufinden. Der dadurch entstandene Wert ist dann allerdings nur noch Mittelwert der letzten X Sekunden.

Über den Webservice des vSphere Servers können die Limits der VMs geändert oder gesetzt werden, sobald der Schwellwert über- oder unterschritten wurde. Dafür muss man sich bei dem Webservice mit einem Account authentifizieren, welcher über ausreichend Rechte verfügt. Nach dem erfolgreichen Anmelden können die einzelnen Funktionen des Webservices ausgeführt werden. Um eine VM oder eine PM konfigurieren zu können, benötigt man die ManagedObjectReference (MOR), welche wir als Antwort der ersten Anfrage (Hole die Daten über den Aufbau der PMs und VMs) erhalten haben. Mithilfe der MOR können dann die Methoden zum Managen aufgerufen werden, dies sind die Methoden ReconfigVM_Task,MigrateVM_Task,UpdatePortGroup und AddPortGroup.

In der prototypischen Entwicklung ist noch keine MAPE-K Loop implementiert. Das Management der VMs erfolgt über zwei definierte Schwellwerte. Wenn der erste Schwellwert unterschritten wurde, benötigt die VM nicht mehr so viele Ressourcen und das Limit wird heruntergesetzt. Wenn der zweite Schwellwert überschritten wurde, benötigt die VM mehr Ressourcen und das Limit wird erhöht. Das Erhöhen des Limits ist nur dann erfolgsversprechend, wenn die VM genügend Ressourcen bei der Erstellung zugewiesen bekommen hat. Nach der Änderung eines Limits erfolgt in den nächsten 15 Sekunden keine weitere Änderung. Dies dient dazu die Auswirkungen der Änderung zu betrachten.


Daten:
Das Programm enthält insgesamt 17 Java-Klassen und besteht aus 2425 Zeilen.
Das neu Konfigurieren von Limits dauert bis zu 1 Sekunde.
Das Migrieren von VMs im laufenden Betrieb dauert bis zu 6 Sekunden.



Last:
Auf einer VM läuft der MQTT-Broker ActiveMQ, welche gemanagt werden soll. Auf den restlichen VMs läuft jeweils eine Last-Anwendung. Diese Last-Anwendung meldet sich als MQTT-Client bei ActiveMQ an und lässt sich alle Nachrichten zustellen, die von den anderen Last-Anwendungen an den ActiveMQ-Broker gesendet wurden. Jede Last-Anwendungen senden in unterschiedlichen Zeitintervallen mehrere Nachrichten an den Broker, sodass dieser ausgelastet wird. Eine Übersicht über den Aufbau zeigt das Bild Finale Umgebung.


Aufwand

Der Arbeitsaufwand des Master-Projekts ist laut Modulhandbuch 450 Stunden. Diese Zeit wird in 4 Kategorien aufgeteilt: Literaturstudium und Einarbeitung, Praktische Tätigkeit, Ausarbeitung und Präsentation, Vor- und Nachbereitung. Die Zeiten für die Vor- und Nachbereitung wurden nicht protokolliert, denn es gab jede Woche eine Projektbesprechung, welche diese Kategorie automatisch ausfüllt.

Für die restlichen 3 Kategorien sind die Daten in der folgenden Tabelle zusammengefasst:

Geplant Verwendet
Literaturstudium, Einarbeitung 90 Stunden 90 Stunden
Praktische Tätigkeit 240 Stunden 254,5 Stunden
Ausarbeitung und Präsentation 90 Stunden 93,5 Stunden
Vor- und Nachbereitung 30 Stunden 30 Stunden
450 Stunden 468 Stunden