Systemarchitektur WS1415

Aus Verteilte Systeme - Wiki
Wechseln zu: Navigation, Suche

Cloud Computing Project WS14/15

Aktuelles

Knoten

Logon für autmatix ist archsys, Pw wie gehabt

Server IP OS Connect URL
obelix.local.cs.hs-rm.de 10.18.62.126 ESXi 5.5
asterix.local.cs.hs-rm.de 10.18.62.127 ESXi 5.5
automatix.local.cs.hs-rm.de 10.18.62.128 KVM qemu+ssh://archsys@automatix.local.cs.hs-rm.de

VMs

Benutzer: sysarch bzw. root PW: (Knoten PW)

Server IP OS
vCenter 10.18.62.202 vCenter Appliance 5.5b
VM1 - Ubuntu Server 10.18.62.201 Ubuntu Server 14.04.01
pdvbuild - PDV Yocto Build Server 10.18.62.203 Ubuntu Server bassiert auf VM1

Dokumentation

Einleitung

Aufgabenstellung

Ziel des Projekts ist es, ein System zu entwerfen, das den reibungslosen Betrieb mehrerer Anwendungen ermöglicht. Dieser reibungsloser Betrieb ist dann ermöglicht, wenn die Service-Level-Agreements (SLAs) eingehalten werden. Dazu ist es notwendig, die Anwendungen zu überwachen (z.B. das Antwortzeitverhalten) und bei Engpässen entsprechend zu reagieren. Die detaillierte Beschreibung der genauen Parameter befindet sich im Abschnitt Stress Tool.

Für das Betreiben der Anwendung stehen mehrere Hosts zur Virtualisierung zur Verfügung. Diese Hosts sowie die darauf befindlichen virtuellen Maschinen (VMs), auf welchen die Anwendungen laufen, müssen ebenfalls durch das System überwacht werden. Dazu zählt beispielsweise die Prozessor- und Arbeitsspeicherauslastung. Stellt das System fest, dass ein SLA nicht eingehalten wird, so muss der entsprechende virtuelle Maschine die fehlenden Ressourcen zugeteilt werden. Stehen auf dem aktuellen Hosts nicht genügend Reserven zur Verfügung, so muss diese VM auf einen weniger beanspruchten Host migriert werden. Genaueres in Abschnitt Management Tool.

Für das Überwachen des Betriebs soll eine Monitoring-Oberfläche entwickelt werden, die die relevanten Daten der Hosts, virtuellen Maschinen und der Anwendungen aufzeigt. Genaueres im Abschnitt Management Tool -> Anzeige.

Für die Demonstration des Systems muss zudem eine zu überwachende Anwendung simuliert werden. Hierfür soll ein System zur Lastgenerierung erstellt werden, das es ermöglicht die relevanten Ressourcen des Systems auszureizen sowie Anwendungsparameter an die Verwaltungsanwendung zu übermitteln. Zum Einstellen der zu verbrauchenden Ressourcen soll ebenfalls eine Oberfläche erstellt werden. Genaueres im Abschnitt Stress Tool.

Beispiel:

  1. Anwendung A auf Host 1 mit kritischem SLA (CPU)
  2. System teilt der Anwendung mehr Rechenleistung zu (SLA OK)
  3. Anwendung B auf Host 1 mit kritischem SLA (CPU)
  4. System verfügt nicht über genügend freie Ressourcen
Eine Anwendung verfügt über nicht genutzte Ressourcen -> Ressourcen verlagern
Anwendung B auf anderen Host mitgrieren

Umgebung

vorhandene Umgebung

Für die Umsetzung des Projekts stehen drei Server zur Verfügung. Zwei der Server werden mit VMware ESXi 5.5 betrieben und verfügen über einen gemeinsamen iSCSI-Datenträger, auf dem sich die virtuellen Festplatten sowie die Konfigurationen der virtuellen Maschinen befinden. Die Anbindung an diese VMware-Umgebung erfolgt mittels der VMware Infrastructure API für Java (kurz: VI Java).

Der dritte Server wird mit der Virtualisierungstechnik Kernel-based Virtual Machine (KVM) betrieben. Die Anbindung an die Anwendung erfolgt hierbei mittels der Bibliothek libvirt.



Bibliotheken

Für die Kommunikation mit ESX- und KVM Hypervisors soll idealerweise ausschließlich libvirt als einheitliche Schnittstelle in der heterogenen Umgebung genutzt werden. Für die jeweiligen unterschiedlichen Umgebungen enthält libvirt passende Treiber, die leider nicht vollständig implementiert sind. Daher sind beispielsweise die KVM-API-Funktionen vollständig unterstützt, viele Teile der vSphere-API von wmWare aber nicht. Die direkte Verwendung der vSphere-API ist deswegen unvermeidlich, um die Anforderungen an das zu entwickelnde System zu erfüllen.

MAPE-K

MAPE-K-Loop

Da es sich bei dem zu erstellenden System um einen Regelkreis handelt, wird das MAPE-K Referenzmodell von IBM verwendet. Es besteht aus vier Phasen und einer zentralen Wissensbasis. Diese Wissensbasis beinhaltet die zum Aufrechterhalten des Systems notwendigen Regeln. Im Falle dieser Anwendung sind dort statische Regeln definiert, wie sich das System in welchen Situationen verhalten soll. Das Modell ermöglicht auch ein dynamisches Regelwerk, wodurch das System vergangene Entscheidungen miteinbeziehen kann.


Ablauf:

  1. Monitor:
    Das System ermittelt alle notwendigen Parameter der zu beobachtenden Umgebung. Hier werden die Parameter der Anwendungen, der virtuellen Maschinen sowie der Server auf denen die Hypervisor betrieben werden ausgelesen und an die nächste Phase weitergegeben.
  2. Analyze:
    In dieser Phase werden die durch die vorherige Schicht übergebenen Parameter analysiert. Dabei werden die verwendeten sowie die verfügbaren Ressourcen ausgewertet und nach Engpässen gesucht. Im wesentlichen wird hierbei darauf geachtet, dass die SLAs eingehalten werden und die Auslastung des Systems die in der zentralen Wissensbasis enthaltenen Regeln nicht verletzt. Diese Ergebnisse werden anschließend an die nächste Phase weitergegeben.
  3. Plan:
    In der dritten Phase werden Möglichkeiten gesucht, um die ermittelten Engpässe auszugleichen. Dabei kann es sich um die Zuteilung von Ressourcen an die virtuellen Maschinen handeln, sofern der aktuelle Knoten über genügend Reserven verfügt. Kann durch die Zuteilung keine Verbesserung erzielt werden, so kann in dieser Phase ebenfalls ein geeigneter Ausweichknoten ermittelt werden.
  4. Execute:
    In der Execute Phase werden die in der vorherigen Phase erstellten Pläne umgesetzt wodurch der Regelkreis geschlossen wird, da diese Umsetzung eine direkte Auswirkung auf die zu überwachende Umgebung hat. Diese Auswirkung wird im nächsten Schleifendurchlauf wieder durch das System wahrgenommen.

Architektur

Gesamtarchitektur

Zentrale Komponente des Systems ist das Management Tool mit der wichtigen Subkomponente "Daemon", die eine Schnittstelle für die Überwachung und Steuerung der KVM- und ESXI-Hypervisor darstellt. Die Aufgaben des Daemons teilen sich auf in Sammlung von Monitoringdaten und Managen von Knoten und deren virtueller Maschinen. Mit dem KVM-Hypervisor kommuniziert der Daemon mit Hilfe von libvirt, während die VMware vSphere API die Schnittstelle zu ESXI-Hypervisors ist. Über die Stress API können mit Hilfe des Stress GUI Lasten auf den einzelnen VMs erzeugt werden. Ebenso werden Statusinformationen über Anwendungen für das Management Tool bereitgestellt. Eine Benutzeroberfläche (Subkomponente "GUI" im Management Tool) stellt wichtige Systeminformationen über Knoten, VMs, Anwendungen und Aktionen grafisch dar.

Management Tool

Das Management Toll besteht aus zwei Teilprojekten - der Anzeige, welches die relevanten Informationen in einer Monitoring-Oberfläche aufzeigt und der Steuerung, das die Anwendungs- und Systemparameter überwacht und die Ressourcen entsprechend verteilt.

GUI

GUI

Die grafische Benutzeroberfläche stellt folgende Informationen dar:

  • Anwendungen
    • Status
    • CPU: Auslastung
    • RAM: Genutzt
  • Knoten
    • Hardwarekonfiguration
    • Auslastung
    • Anzahl VMs
  • VMs
    • vCore - Anzahl und Auslastung
    • RAM
    • Platten/Netzwerk IO
    • Software Infos

Daemon

Aufgaben

  • Recherche XEN vs KVM
  • Bereitstellen von Monitoring Daten
    • Liste mit möglichen Knoten
    • Die jeweiligen VMs der Knoten
  • Konfiguration des Tools
    • Knoten hinzufügen (VM und KVM) mittels XML Datei
    • Regeln definieren über XML Datei
  • Managen der VM's und ihrer Knoten
    • Anwenden der Regeln unter Hilfe des Monitors
    • Loggen in eigenem simplem Format und Bereitstellung mittels RMI Aufruf

Usecases

Konfiguration & Recherche

KVM vs XEN
Name Firma Lizenz Hypervisor Virtualisierungs Typen Architekturen Management Hostsysteme Gastsysteme
XEN Xen.org OpenSource Bare Metal, ohne CPU Virtualisierungsfeatures Hardware Assisted Virtualization , Paravirtualization x86, x64 Migrationen (Live, VM, Storage), Performance Metrics, High Availability, Maintenance Mode, VM Cloning CentOS, Debian Sarge, Fedora, Free BSD, Gentoo, openSUSE, SUSE Linux, Ubuntu Linux, Windows, Solaris, BSD, FreeBSD
KVM Red Hat OpenSource Hosted (Type 2), Prozess in Ring 3, Benötigt CPU Virtualisierung Full Virtualization, Paravirtualization x86, x64, Power Migrationen (Live, VM, Storage), Performance Metrics CentOS, Fedora, Red Hat Linux, Ubuntu Linux, Windows, Solaris, BSD, FreeBSD, MS-DOS

Quellen:


Vorteile von KVM gegenüber XEN in Bezug auf unser Projekt:

Migration

Das Feature Migration ist eine für uns entscheidende Möglichkeit auf einen Anstieg der Last reagieren zu können. Last über I/O und Netzwerk ließen sich in unserem Szenario nicht anders kompensieren und wir wollten keine speziellen Anforderungen an die virtuellen Maschinen/Anwendungen stellen. Die Live Migration zeichnet sich hierbei durch eine sehr geringe Beeinträchtigung der virtuellen Maschine aus. Das zu verschiebende System bleibt so lange aktiv, bis es erfolgreich auf das Zielsystem migriert wurde. Dazu gehört auch ein Großteil des RAM. Erst wenn beides erfolgreich übertragen wurde, wird die VM auf dem Quellknoten ausgeschaltet und eine Delta-Synchronisierung überträgt stattgefundene Änderungen im RAM. Dadurch gelingt innerhalb kürzester Zeit eine VM zwischen zwei Knoten zu migrieren, ohne dass die Anwendungen start beeinträchtigt werden. In unserem Fall innerhalb weniger Hundert Millisekunden.

  • Versuch VMware auf KVM zu migrieren
    Wir hatten zuerst angenommen, eine live Migration mittels libvirt, wäre "einfach" möglich. Grundvoraussetzung für ein solches Unterfangen ist ein gemeinsames Dateisystem. Da wir VMware bereits initial den gesamten RAID5 zugewiesen hatten, mussten wir eine Möglichkeit finden auf VMFS über Linux zugreifen zu können. VMFS kam hierfür infrage. Nach der Einrichtung von iSCSI und VMFS auf unserem KVM Knoten stellten wir jedoch fest, dass es nur lesenden Zugriff bot. Zu diesem Zeitpunkt wussten wir bereits, dass nur eine einfache Migration generell unterstützt wird. Es machte auch keinen Sinn mehr den RAID5 auf ein NFS umzustellen, auf das VMware und KVM beide zugreifen könnten, da eine einfache Migration für uns uninteressant war und wir unser VMware System neu konfigurieren und den NFS Knoten erst einrichten müssten.
  • Zugriff über Linux auf VMFS Dateisystem mittels vmfs-tools (http://glandium.org/projects/vmfs-tools/). Nur Lesezugriff.
  • Migration VMware - KVM
KVM Inbetriebnahme
Remote Ausführung des virt-manager Tools

Die generelle Installation des KVM Knoten auf einem CentOS 7 ging dank [Anleitung] schnell von Statten. CentOS bietet bereits libvirt in seiner Packetverwaltung und lässt sich mittels YUM installieren. Angeschlossen an den Knoten ist, ein weiteres 6 TB großes RAID5, von dem 500 GB für unseren KVM Storage Pool reserviert wurden. Das Management läuft über eine VMware Extension Karte, über die ein Zugang zum Terminal und Aufgaben wie Neustart/Herunterfahren/... möglich sein sollte. Bei keinem von uns verwendeten OS war es jedoch möglich, diese virtuelle Konsole, zu verwenden. Windows/Linux unterschiedliche Java Versionen... Somit mussten wir uns auf den SSH Server verlassen, was bei der Einrichtung des Netzwerks für die virtuellen Maschinen Komplikationen verursachte.

Schwierigkeiten:

  • libvirt und der Socket
    Die erste Inbetriebnahme von libvirt lokal auf dem System funktionierte einwandfrei. Als wir dann jedoch VMs einrichten und die Verbindung mit unserem Daemon herstellen wollten kam zu einem merkwürdigen Verhalten seitens des libvirt Daemon. Nach der Dokumentation sollte unser, dafür angelegter Benutzer, kvm Zugriff auf den Socket des Daemon haben. Es erschien jedoch jedes Mal eine Fehlermeldung bezüglich fehlender Berechtigung. Darauf haben wir entsprechend alle Berechtigungen und die korrekte Gruppenzugehörigkeit überprüft (Dateisystem, Policykit), ohne Erfolg. Lokal war ein Zugriff mittels Root möglich, extern ging nichts. Nicht einmal root hatte Zugriff, der von allen Berechtigungen laut Doku ausgeschlossen sein sollte und immer funktionieren müsste. Durch einen Beitrag in einem Forum erfuhren wir dann, dass es unter Umständen nötig sein kann, den Socket direkt in der URL anzugeben:
    ?socket=/var/run/libvirt/libvirt-sock
    Da es nötig wurde eine angepasste URL zu nutzen, um sich mit dem KVM-Knoten über libvirt zu verbinden, konnte das Tool virt-manager nicht genutzt werden. virt-manager ist ein Tool zum Erstellen und verwalten von VMs unter KVM und XEN, allerdings generiert dieses Tool die Verbindungs-URL zum Knoten selbst. Daher konnte das Tool nicht remote genutzt werden. Ein Workaround hierfür ist es das Tool remote über das Protokoll X11, welches über SSH vermittelt werden kann, auszuführen. Dabei verbindet sich der virt-manager lokal mit dem KVM-Knoten. Um diese Workaround umzusetzen musste ein X-Server auf dem KVM-Knoten installiert und eingerichtet werden.
  • VM Netzwerk
    Default sind eingerichtete Maschinen auf dem KVM Knoten von außerhalb nicht zu erreichen bzw. durch ein NAT geschützt. Wir entschlossen uns das Verhalten ähnlich wie bei den VMware Maschinen umzusetzen. Dort wurde ein neues Netzwerk konfiguriert, welches im Endeffekt eine Bridge darstellte. Nach der Lösung des Proxy Problems konnten wir dann die entsprechenden bridge Tools installieren und auf dem Host OS eine Bridge (virbr0) mit dem virtuellen Netzwerkadapter (p2p1) über den der Host an das Hochschulnetzwerk angeschlossen ist erzeugen. Dieser neue Bridge Adapter konnte dann der VM KVM Konfiguration hinzugefügt werden. Die IP Konfiguration erfolgte dann über das jeweilige Gast System. Dabei war es äußerst unpraktisch, dass wir kaum Erfahrungen mit der korrekten Einrichtung einer Bridge unter CentOS hatten und die virtuelle Konsole des KVM Systems nicht funktionierte.
  • Hochschul-Proxy
    Während des Projekts kam es zu einer Veränderung im Hochschulnetzwerk. Plötzlich funktionierte der uns genannte Proxy: Proxy:8080 nicht mehr. Nach Umstellung auf den neuen/alten? Proxy.cs.hs-rm.de:8080 kam es in unseren Ubuntu Packetverwaltungen zu Problemen. Der Proxy verbot trotz korrekter Konfiguration des apt-get ein Update. Wir mussten manuell die Quellen erneut hinzufügen, um das Problem zu lösen.

Architektur

Der Daemon besteht im Wesentlichen aus drei Services: Dem Log-Service, dem SLA-Service und dem VM-Service. Diese besitzen die folgenden Aufgaben:

Log-Service

Um die getroffenen Entscheidungen des Daemon später nachvollziehen zu können implementierten wir einen Logservice auf Basis des Singleton Patterns. Dieser speichert Log Informationen in einer lokalen SQLite Datenbank.

SLA-Service

Der SLA-Service ist für das Einhalten der SLAs verantwortlich. Zunächst setzt er die benötigten Zuordnungen in seinem Startup. Hierbei werden die Applikationen ihren VMs und SLAs zugeordnet.

Zudem gehört zu seinen Aufgaben das umsetzten von Maßnahmen falls eine SLA verletzt wird. Somit ist er für die Phasen Analyse, Plan und Execute im MAPKE-K Loop verantwortlich. Die Phasen werden in der Methode planAndAct() umgesetzt. Hier wird zu nächst getestet ob die Applikationen ihre SLA verletzten. Ist dies der Fall, wird ausgewertet welche bzw. ob Ressourcen der VM auf der die Applikation läuft zugeteilt werden können. Ist dies nicht der Fall, so wird getestet, ob eine Migration sinnvoll ist.

VM-Service

Der VM-Service ist für das Updaten der Daten verantwortlich. Somit über nimmt er die Monitoring Phase im MAPE-K Loop. Um die Daten abzuholen, kommuniziert er mit den Hypervisorn und den Applikationen.

Umsetzung MAPE-K Loop

Bei der Umsetzung des Daemons wurde ein MAPE-K Loop implementiert, der die Daten der Applikationen, Hypervisor Knoten sowie der genutzten VMs nutzt, um sicher zustellen das SLAs eingehalten werden. Falls eine Applikation ihre SLA verletzt, greift der Daemon ein, indem er weitere Ressourcen einer VM zuteilt oder eine VM auf einen anderen Knoten migriert (siehe Abschnitt Usecases). Die Wissensbasis des Daemons ist statisch, d.h., der Regelkreis kann anhand von in der Vergangenheit getroffenen Entscheidungen nicht lernen. Diese besteht aus einer XML-Datei, die die Regeln der SLAs beinhaltet und dem Wissen, über die noch zur Vergnügung stehenden Ressourcen, welches über die jeweiligen Hypervisor abgefragt wird. Die einzelnen Phasen wurden wie folgt implementiert.

Monitoring
Monitoring

Für das Erfassen der Daten kommuniziert der Daemon über seinen VM-Service mit den Applikationen sowie dem vCenter der ESXi-Knoten und dem KVM-Hypervisor. Die Kommunikation mit dem vCenter und dem KVM-Hypervisor werden dabei vom VM-Service direkt über die jeweilige Schnittstelle vollzogen. Die Daten der Applikationen werden währenddessen periodisch von Threads empfangen, indem sie mit den Applikationen kommunizieren. Dabei existiert pro Applikation ein Thread. Der VM-Service setzt die Applikationsdaten mit den temporär anliegenden Daten der Threads in jeder Monitoring Phase.

Analyse & Planning
Analyse & Planning

In dieser Phase ist nur der Daemon involviert. Der SLA-Service des Daemons überprüft ob SLAs verletzt werden und welche Maßnahmen in Fall einer Verletzung durchgeführt werden. Hierbei spielen die Ressourcen, die einer VM maximal zugewiesen bekommen kann, sowie die Last der Knoten eine Rolle. Z.B. wenn eine VM ihre maximalen Ressourcen zugewiesen bekommen hat, wird getestet ob es möglich ist sie auf einen anderen Knoten, zu migrieren (derzeit nur zwischen den beiden ESXi-Knoten). Hierbei wird getestet, ob der andere Knoten durch die Migration, nicht zu sehr belastet wird.

Execute
Execute

In dieser Phase führt der SLA-Service seinen Plan aus hierzu kommuniziert er mit dem vCenter und dem KVM-Knoten und weißt einer VM mehrere Ressourcen zu oder migriert sie ggf.

Stress Tool

Andreas Werner, Daniel Mierswa

Besprechung

  • GUI ist Client
  • Load-Producer sind kleine Server
  • CPU Load über eine Berechnung und Schlafenlegen zwischen den Berechnungen
  • Memory-Load über realloc(2)
  • I/O-Load durch feste Werte (in Bezug auf SAS/S-ATA-Platten)
  • Netzwerk-Load über feste Werte für Pakete

Zunächst wurde im Team über ein mögliches Layout des GUI gesprochen und dieses später mit QtDesigner in die Tat umgesetzt. Da bei der Verwendung von QtDesigner viele Dinge doch ausprogrammiert werden müssen, hat sich der Entwickler dazu entschlossen, die generierte Form-Datei (.ui) und den Quellcode nur als Anhaltspunkt zu nehmen und die Komponenten nicht generieren zu lassen, sondern selbst einzubinden.

Architektur

Gesamtarchitektur des Stress Tools

In der Architektur findet man eine Anwendung auf dem Client, welche auf einem beliebigen Linux-System ausführen kann. Die Stress Tool Server werden auf den einzelnen VMs deployed und kommunizieren über TCP/IP mit dem Client-GUI. Das Kommunikationsprotokoll wird eigenhändig entwickelt und enthält Nachrichten, welche angeben, welche Art der Last auf den Stress Daemons (Servern) erzeugt werden sollen. Es wird eine API entwickelt, so dass GUI und auch das Management Tool in der Lage sind, die einzelnen Daemons zur aktuellen Auslastung abzufragen.

Recherche über vorhandene Stress-Test-Komponenten

Um so wenig wie möglich Load-Producer selbst zu schreiben, sollten vorhandene und etablierte Programme genutzt werden oder zumindest die Technologie betrachtet werden, womit Load produziert wird. Diese sollten aber die gewünschten Anforderungen an das Stress-Test-Tool in Bezug auf Granularität und Steuerung bereitstellen. Für die Entwicklung des Stress-Test-Tools wurden folgende Programme betrachtet:

GUI

Bei der Modellierung wurde Gebrauch von der Signaling-Architecture von Qt gemacht und diese jeweils eine Schicht weiter oben abstrahiert (vgl. Exceptions). So wird ein Slider ein `generateLoad`-Signal generieren und das Hauptfenster nutzt dieses Signal für sich selbst (es wird mit einem Hauptfenster-internem Slot verbunden) und generiert selbst ein `generateLoad`-Signal, welches zusätzlich Informationen bereitstellt, für was Load generiert werden soll. Die VMs werden in Tabs angezeigt und können bei Bedarf hinzugefügt oder entfernt werden. Hat der Benutzer seine Einstellungen vorgenommen, kann er den aktuellen Stand speichern (das Format ist derzeit noch nicht festgelegt) und nach einem Neustart der Applikation eingelesen werden. Um eine VM hinzuzufügen, wird nur die Eingabe eines Namens und der IP und Port des Stress Tool-Servers verlangt.

Stress - Tools

Entwickelt von Andreas Werner

Libarys / Methoden für System Monitoring

Recherche über Libaray oder Methoden für das VM Client Monitoring zum Generieren von Kennzahlen (CPU Last, Speicherauslastung, ...):

  • SNMP Daemon: Daemon für SNMP Protokoll zugriff auf alle System relevante Daten über SNMP
  • proc Interface: Linux proc Interface für zugriff auf alle System relevante Daten

Ergebnis:

SNMP Deamon ist für "schnelles" Regeln ungeeignet da Werte im Minuten Takt aktualisiert werden. Weiter sind die ausgelesenen Werte über den Aktualisierungszeitraum gemittelt. Deswegen wird ein direktes Auslesen der Werte aus dem Betriebssystem erforderlich. Das Statistik Module Proc Interface ist ebenfalls gemittelt über den Zeitraum der Letzten Abgefragte. Werte könnten in kurzen Zeiträumen abgefragt werden.

Architektur

Detail Architektur des Stress Tools

Dass Stress Tool besteht aus sieben Teilen:

  • Port: Dieser Teil stellt den Betriebssystem Abhängigkeiten Teil des Stress Tools da. Dieser fragt alle Kennzahlen vom Betriebsystem ab und stellt sie über "Geter- Funktionen" zu Verfügung.
  • Info: Der Info Teil fragt in einem regelmäßigen Zyklus über die "Geter - Funktionen" des Port Teiles alle Kennzahlen ab und speichert diese in einer globalen Datenstruktur. Dies ist nötig, da die Betriebssysteme alle statistischen Kennzahlen als gemittelter Wert über eine gewisse Zeit Verfügung stellen.
  • Server: Der Server besitzt zwei aufgaben zum einen stellt der Server über die Stress API den Clients alle Kennzahlen zu Verfügung. Diese ruft er zyklisch ab und sendet sie an alle Clients. Die zweite Aufgabe ist es auf Anfragen zu lauschen, die von den Clients kommen und dieses dann an die Stress Controller zu verteilen.
  • CPU: CPU ist ein Stress Controller. Dieser hat die Aufgabe den angeforderten CPU Load zu generieren.
  • Mem: Mem ist ein weiterer Stress Contoller. Dieser soll eine bestimmte Anzahl von Bytes im RAM Speicher reservieren.
  • IO: IO soll einen bestimmte IO Auslastung generieren. Um eine Kennzahl zu erzeugen, wird dem IO-Teil noch eine bestimmte größe in Bytes übermittelt.Dem Info Teil wird daraufhin übermittelt, wie viel Zeit benötigt worden ist, um die angeforderte Datenmanege auf die Platte zu schreiben.
  • Net: Das Net Modul ist vom verfahren dem IO-Teil sehr ähnlich nur soll eine Netzauslastung zwischen zwei Stress Tools erzeugt werden. Hierbei übernimmt ein Stress Tool die Rolle eines Server und das andre Stress Tool die Rolle eines Clients.

CPU Lastgenerierung

Die Eingangswerte für die CPU-Lastgenerierung sind:

  • CPU Load in Prozent
  • Anzahl von Threads die die Last generieren

Diese Werte erhält der CPU Teil von dem Server.

Der CPU Lastgenerator besteht aus zwei Komponenten. Die Worker Threads, die die Last generieren und den Contoller Thread, der diese steuert. Der Cotollerthread schläft so lange keine neuen Werte angefordert werden.

Die CPU-Lastgenerierung erfolgt in zwei Abschnitte:

  • Planen der CPU Zeiten der einzelne Threads
  • Umsetzen der CPU Zeiten

Die Planphase besteht aus zwei abschnitten

  1. Erzeugung der angeforderten Threads, falls weniger als bereits erzeugte Threads angefordert sind, werden die überflüssigen Threads beendet.
  2. Einstellen der Sleeptime um Mithilfe der Threads Last zu generieren.

Nach dem Planen wird ein weiterer Thread gestartet, der den Controller ersetzen soll. Dies verhindert das durch das schlafen Legen des Contollers die CPU Last nicht sinkt. Wie bereits erwähnt, legt sich der Controller Thread nach der Planphase wieder schlafen, um zu verhindern, dass der Controller nicht gegen die Gegenmaßnahmen des Hypervisor arbeitet.

Das Einstellen der Sleeptime erfolgt in zwei Schritte:

  1. ermitteln der aktuellen Auslastung
    1. wenn kleiner als angefordert verringere Sleeptime
    2. wenn größer als angefordert vergrößere Sleeptime
  2. Einstellen der Sleeptime bei allen Threads ---

Die Größe des verringere und vergrößere ist dabei abhängig, um wie viel Prozent der aktuelle Wert von dem angeforderten Wert abweicht. Derzeit sind zwei Stufen implementiert. Wenn der Wert innerhalb von 10 % des Angeforderten Wert lieft, wird die Sleeptime um Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle 10 \mu s} verringert/vergrößert. Falls der Abstand größer ist, um Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle 100 \mu s} .

Mem Lastgenerierung

Die Eingangswerte für die Mem Lastgenerierung sind:

  • Größe des die alloziert werden soll

Genauso wie im CPU-Teil werden die Daten vom Server angefragt.

Die angefordert RAM-Speicher Auslassung wird über den Systemcall malloc vom Betriebssystem angefordert und anschließend mit einem Wert befühlt. Das Befüllen ist nötig um den Speicherbereich als Aktiv zu markieren. So das Betriebssystem die nötigen Verdrängungsalgorithmen benutzt. Das Betriebssystem Linux wartet zum Beispiel mit der Verdrängung von Speicher solange der angefordert Speicherplatz verwendet wird.

IO Lastgenerierung

Dieser Abschnitt befasst sich mit der IO-Lastgenerierung. Diese wurde nie implementiert, da nur ein SAN zur Verfügung stand und eine Lastumverteilung keine Veränderung, der IO Last auf den Platten verursachte hätte.

Die Idee in der IO-Lastgenerierung bestand darin mithilfe der statistischen Werte des Betriebssystems eine vom Client angeforderte spezifische Last zu generieren. Weiter sollte die Zeit gemessen werden die es benötigt eine angeforderte Dateigröße auf die Platte zu schreiben.

Net Lastgenerierung

In diesem Abschnitt wird die Netzwerk Lastgenerierung beschrieben. Diese wurde wegen der schwierigen Reglung seitens des Hyperviser auch nicht implementiert.

Der Net Lastgenerator besteht aus zwei Komponenten. Einem Server der eine UDP Schnittstelle Zugverfügung stellt an dem Daten übermittelt werden können und dem Client, der sich an ein Server verbinden kann und Daten an den Server über UDP senden kann.

Server

Der Server besteht aus zwei Threads ein Empfangsthread und einem Sendethread. Der Empfangsthread wartet auf eine Anfrage von einer der Clients. Weiter nimmt er alle TCP-Verbindungen entgegen und speichert sie ab. Der Sende Thread sendet alle Information zyklisch an alle Client. Die Informationen werden von dem Info Part abgefragt.

Der Empfangsthread enthält ein Parser für das Stress API Protokoll dieser Parser ruft eine Callback Funktion auf um die Anwendung über eine Anfrage zu informieren.

Info

Der Info Teil stellt eine Schnittstelle zum dem Port Teil da. Er ruft in einem Festen zyklisch über die Port Schnittstelle ab.

Port

Die Port Schnittstelle definiert Funktionen die alle statistischen Informationen abrufen sollen. Sie werden für jedes Betriebssystem implementiert.

Die Schnittstelle ist wie folgt aufgebaut:

 int32_t getSystemInfo(char *info);
 uint64_t getMemMax();
 uint64_t getIoMax();
 float getCPULoad();
 uint64_t getMemLoad();
 uint64_t getIoLoad();
 uint64_t getNetloadUp();
 uint64_t getNetloadDown();

Linux Port

Der derzeit einzige Port ist der Port für den Linux Kernel. Dieser benutzt die proc Statistik Schnittstelle um die Daten für das Stress Tool zur Verfügung zu stellen.

getSystemInfo

getSystemInfo gibt einen Version String zurück. Unter Linux wird hier der Inhalt des proc Attributes "/proc/version" zurückgeben. Ein Beispiel:

 Linux version 3.8.0-35-generic (buildd@roseapple) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) ) 
 #50-Ubuntu SMP Tue Dec 3 01:24:59 UTC 2013 

getMemMax

getMemMax gibt die maximale verführbare RAM Speicher Kapazität aus. Diese wird aus dem proc Attribute "/proc/meminfo" ausgelesen. Für getMemMax wird das Feld MemTotal zurückgeben in dem das Attribute geparsed wird. Beispiel Aufbau des Attributes "/proc/meminfo":

 MemTotal: 3957688 kB 
 MemFree:          478720 kB
 Buffers:           62192 kB
 Cached:           872036 kB
 SwapCached:        92868 kB
 Active:          2169028 kB
 Inactive:        1086264 kB
 Active(anon):    1835396 kB
 Inactive(anon):   819312 kB
 Active(file):     333632 kB
 Inactive(file):   266952 kB
 Unevictable:        3816 kB
 Mlocked:            3816 kB
 SwapTotal:        498684 kB
 SwapFree:           8100 kB
 Dirty:               192 kB
 Writeback:             0 kB
 AnonPages:       2232152 kB
 Mapped:           140140 kB
 Shmem:            331180 kB
 Slab:             111816 kB
 SReclaimable:      68224 kB
 SUnreclaim:        43592 kB
 KernelStack:        4944 kB
 PageTables:        42504 kB
 NFS_Unstable:          0 kB
 Bounce:                0 kB
 WritebackTmp:          0 kB
 CommitLimit:     2477528 kB
 Committed_AS:    6731480 kB
 VmallocTotal:   34359738367 kB
 VmallocUsed:      347316 kB
 VmallocChunk:   34359386992 kB
 HardwareCorrupted:     0 kB
 AnonHugePages:         0 kB
 HugePages_Total:       0
 HugePages_Free:        0
 HugePages_Rsvd:        0
 HugePages_Surp:        0
 Hugepagesize:       2048 kB
 DirectMap4k:      137216 kB
 DirectMap2M:     3973120 kB

getMemLoad

Für getMemLoad wird MemTotal und MemFree aus "/proc/meminfo" ausgelesen und voneinander abgezogen.

getIoMax

IO Max kann unter linux nicht ermittelt werden deswegen wird UINT64_MAX zurückgeben.

getCPULoad Um die aktuelle CPU-Auslastung zu ermitteln muss das proc Attribute /proc/stat ausgewertet werden.

Beispiel Aufbau des /proc/stat Attributes:

 cpu  12774419 17312 2899002 34624778 1011818 229 40755 0 0 0
 cpu0 4153394 7069 945112 29026640 988700 180 12472 0 0 0
 cpu1 2318338 3269 549837 1918517 8197 49 23892 0 0 0
 cpu2 4169534 3768 885105 1740194 10826 0 2676 0 0 0
 cpu3 2133151 3204 518947 1939425 4094 0 1714 0 0 0
 intr 416936403 18 589139 0 0 0 0 [... lots more numbers ...]
 ctxt 1339247777
 btime 1422820091
 processes 167485
 procs_running 1
 procs_blocked 0
 softirq 249601655 48 63842778 676649 667648 6589705 48 21922114 46976046 382549 108544070

Dieses Interface liefert verschieden Kernel Statistiken neben der Zeit die CPU in den verschieden Stadien verbringt liefert das Attribute Informationen über die Anzahl der interrutps und weitere Statistiken.

Um die CPU Last zu brechen sind die cpu Zeilen wichtig. Die erste Zeile gibt eine Zusammenfassung aller CPUs Zeiten an. Die Zeilen cpu0, cpu1, ... geben die Zeiten auf den einzeln CPUs an.

Aufbau einer Zeile ist:[1]

  • <Lable>: cpu, cpu0, cpu1
  • user: Verbrauchte Zeit als normaler Prozess im User Mode
  • nice: Verbrauchte Zeit als wichtigeren Prozess im User Mode
  • system: Verbrauchte Zeit im Kernel
  • idle: Verbrauchte Zeit im Idle Task(offiziell: twiddling thumbs)
  • iowait: Verbrauchte Zeit auf IO Anfragen zu warten
  • irq: Verbrauchte Zeit in Interrupt Service Routinen
  • softirq: Verbrauchte Zeit in Software Interrutpts
  • steal: Verbrauchte Zeit mit unfreiwilliges Warten(Nicht genauer definiert)
  • guest: Verbrauchte Zeit in einer Virtuellen Maschine verbracht wurde
  • guest_nice: Verbrauchte Zeit in einer wichtigeren virtuellen Maschine verbracht wurde

Um die CPU-Auslastung zu berechnen, muss in einem festen Zyklus die Zeiten abgerufen werden. Zur Brechung der Last benötigt man die Zeiten der vorhergehe Berechnung. Die CPU Last lässt sich dann wie folgt berechnen:

Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle \text{aktive_time}=(\text{stat.user} - \text{old_stat.user}) + (\text{stat.system} - \text{old_stat.system}) + (\text{stat.iowait} - \text{old_stat.iowait})}

Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle \text{total_time} = \text{active_time} + (\text{stat.idle} - \text{old_stat.idle})}

Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle \text{cpu_load} = \frac{\text{active_time} \cdot 100}{\text{total_time}}}

getIoLoad

Die IO Load wird aus den Platten Statistiken ausgelesen. Diese ist im sysfs Filesystem unter "/sys/block/<block dev name>/stat" abgelegt.

Beispiel Ausgabe:[2]

5144421   388755 177025874 50962956  1136771  1500382 126098582 78691924        0 15572804 129663356

Aufbau des Attributes:

  • Anzahl der abgeschlossenen Lesevorgänge
  • Anzahl der abgeschlossenen Lesevorgänge die zusammengefasst worden sind
  • Anzahl der Sektoren die gelesen worden sind
  • Zeit die auf Lesen aufgewendet worden ist
  • Anzahl der abgeschlossenen Schreibvorgänge
  • Anzahl der abgeschlossenen Schreibvorgänge die zusammengefasst worden sind
  • Anzahl der Sektoren die geschrieben worden sind
  • Zeit die auf Schreiben aufgewendet worden ist
  • Anzahl der aktuellen schreib / Lesevorgänge
  • Zeit die als Letztes aufgewendet worden ist
  • Zähler, der bei jeden Vorgang hochgezählt wird.

Um die Anzahl der Bytes pro Sekunde zu berechnen, muss weiter eine Zeitbasis verwendet werden. Hierfür eignet sich das Attribute /proc/uptime. Dies ist die Ticks, die seit dem Hochfahren gezählt worden sind. Diese kann man dann ein eine Zeitbasis in Sekunden umrechnen in dem man den wert durch die Konstante _SC_CLK_TCK teilt.

Die Anzahl der Sektoren pro Sekunden wird dann wie folgt berechnet:

Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle \text{sektor_time} = \frac{\text{stat.r_sectors} - \text{old_io_stat.r_sectors}}{(\text{uptime}-\text{old_uptime}) * \text{hz}}}

Um die Anzahl der Bytes zu ermitteln, muss lediglich

Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle bytes_time = \frac{\text{sektor_time}}{2}\cdot 1024 }

ausgerechnet werden. getNetloadUp und getNetloadDown wird genauso berechnet das Interface hierfür ist unter /sys/class/net/<dev>/statistics/rx_bytes abgelegt.

Kommunikationsdaten

Für das Empfangen und Senden von Load- und Systeminformationen, wurde eine Datenstruktur entworfen, die über TCP/IP an die Server gesendet wird. Bei der Kommunikation wird zunächst immer erst ein Header-Paket gesendet, welches eine Version, den Typ des Folge-Pakets (oder der folgenden Pakete) und die Anzahl der Pakete gesendet wird. Dadurch, dass der Typ der folgenden Pakete nur einmal spezifiziert wird, ist es nur möglich Pakete vom gleichen Typ mehrmals hintereinander zu senden (z.B. Header + 3 * Paket A).

Version 1

Es gibt 3 Pakettypen in der ersten Version des Protokolls:

  1. System-Informationen
  2. Load-Informationen
  3. Load-Anforderungen

Das System-Informationen Paket enthält einen Identifier für das verbundene System (z.B. die Ausgabe von `uname -a` auf einem Linux-OS, sowie die maximale CPU- und Speicherauslastung, so dass der UI-Teil der Anwendung für den Benutzer sichtbar machen kann, wieviele Resourcen die Maschine derzeit bereitstellt. Das Paket für die Load-Information, enthält jeweils Angaben über die derzeitige Auslastung in angebrachten Einheiten (z.B. CPU-Auslastung in %, I/O-Auslastung in Bytes/s, usw.). Das Paket, welches die Load-Anforderungen (Client zu Server-Information) verschickt, enthält zusätzlich zu den Load-Informationen eine Angabe darüber, wieviele Threads auf der VM benutzt werden sollen.

Version 2

Gleicher Aufbau wie in Version 2 es wurden Kennzahlen hinzugefügt (Zeit zum Schreiben der IO und Netzwerk Nachrichten).

Version 3

Aufteilen Pakettypen in kleinere Pakte. Pakete jetzt nach Type sortiert. Vor einer Nachricht wird ein Header gesendet um zu erkennen, wie viele Pakete folgen. Reihenfolge der Pakte ist nicht definiert. Ein Paket Type wird anhand den ersten 32 Bit erkannt. Gesendet wird die ganze Sturktur inclusive Padding Bits

  • System Informationen.
  • Basic Informationen: CPU Load, Speicherauslasstung
  • IO Informationen: IO Load, Größe der zu schreiben Datei, Zeit, die benötigt wird, um eine Datei zu schreiben
  • Net Up Informationen: Net Load, Net Größe, Zeit, die benötigt wird, eine Paket mit der Größe zu senden
  • Net Down Informationen: Net Load, Net Größe, Zeit, die benötigt wird, eine Paket mit der Größe zu empfangen
  • Weiter Strukturen für Befehle an das Stress tool

Version 4

Wichtigste Änderung: Befehl und Informationstype vereinigt. Ein Paket zum Stresstool ist immer ein Befehl und vom Stress Tool eine Information. Um Padding Bit zu vermeiden, wird die minimal Größe für ein Paketinhalt auf 32 Bit erhöht.

Version 5

Da weiterhin bit existieren, wird jetzt jeder Inhalt einzeln gesendet. Die Padding Bits führten zu Probleme beim Parsen unter Java.

Fazit

Einschränkungen durch libvirt
Die ursprüngliche Idee die Bibliothek libvirt als "Allzweckwaffe" zu benutzen konnte nicht umgesetzt werden, weshalb zusätzlich die VI API genutzt werden musste. Für die Feststellung und Lösung dieses Problems wurde viel Zeit investiert, da hierdurch die Wahl der Programmiersprache umgestellt werden musste. Diese Umstellung war erforderlich, da die VMware Infrastructure API hauptsächlich für Java und .NET zur Verfügung stand. Die bis zu diesem Zeitpunkt erstellen Softwarekomponenten konnte daher nicht mehr genutzt werden.
Heterogene Live-Migration
Eine Hauptaugenmerk des zu entwickelnden Systems bestand darin, das zur Laufzeit heterogene Migrieren von virtuellen Maschinen zu ermöglichen. Dies könnte aufgrund fehlender Unterstützung nicht umgesetzt werden. Die einzige Möglichkeit eine Migration durchzuführen hätte dazu geführt, dass die entsprechende Anwendung hätte angehalten werden müssen. Die gesamte virtuellen Maschine hätte pausiert und anschließend auf einen anderen Datenträger kopiert werden müssen. Zusätzlich wäre es notwendig gewesen, den aktuellen Inhalt des Arbeitsspeicher auf die neue Zielumgebung zu übertragen. Dieser Ablauf hätte im Vergleich zur Live-Migration einen erheblich gesteigerten Zeitaufwand dargestellt und ist dadurch für die Lösung nicht relevant.
Eingeschränkte Ressourcenzuteilung
Da die Hypervisor nur bedingt Ressourcen Zuteilung im Betrieb zulassen, war es nicht möglich alle Szenarien der erdachten Regelung umzusetzen. Ein Beispiel hierfür ist, das es nicht möglich ist die Frequenz, einer CPU zu beeinflussen oder Ressourcen zu entfernen.
Variable Lastgenerierung
Projektmanagement
Einige Probleme bei der Umsetzung des Projekts waren darin begründet, dass kein Teamleiter bestimmt wurde. Dadurch kam es zu Problemen bei der Kommunikation der beiden Teams, wodurch es zur späten Zusammenführung der Teilprojekte kam. Weiterhin wurde der Aufwand der einzelnen Teilgebiete falsch eingeschätzt, wodurch es anfänglich zu unverhältnismäßigem Aufwand bei einigen Teilnehmern gekommen ist.
Zeitaufwand
Unabhängig von der eigentlichen Aufgabenstellung, verwendeten wir einen Großteil unserer Zeit für die korrekte Konfiguration unserer Hypervisor Umgebung und dabei aufgetretene Probleme. Dazu kam dann die eigentliche Verwendung der libvirt und VMware API, welche alles andere als glatt lief.
Lernerfolg in den folgenden Gebieten
Regelalgorithmen
Systemintegration
CentOS Konfiguration (Bridge, KVM Install/Konfig, Paketverwaltung, iSCSI)
virsh Verwaltung (Wie erstellt man Maschinen, Storage Pools, Konfiguration)
VMware Verwaltung
GUI Entwicklung
RMI

HOWTOs

Zenon Repository

  • GitLab SSH key hinzufügen
    • GitLab -> Profile -> SSH Keys
    • Aktuellen Key einfügen (cat ~/.ssh/id_rsa.pub) oder neuen erstellen (ssh-keygen -t rsa) und dann einfügen
  • Projekt auschecken
    • in das gewünschte Verzeichnis wechseln
    • git clone git@zenon.cs.hs-rm.de:marcel.b.kneib/systemarchitektur.git

libvirt Installation

Die folgende Installationsanleitung bezieht sich auf libvirt-1.2.10:

Folgende Pakete werden u.a. von libvirt benötigt und können mit "pkg-config --list-all | grep <lib_name>" geprüft bzw dem Paketmanager nachinstalliert werden:

  • libxml2-dev
  • libdevmapper-dev
  • libpciaccess-dev
  • libnl-3-dev
  • libnl-route-3-dev
  • libcurl4-gnutls-dev
  1. $ gunzip -c libvirt-x.x.x.tar.gz | tar xvf -
  2. $ cd libvirt-x.x.x
  3. $ ./configure --prefix=<libvirt_installationsverzeichnis> --with-esx --with-storage-iscsi
  4. $ make
  5. $ sudo make install


Anpassung für libvirt-1.2.11:

  1. $ gunzip -c lloyd-yajl-2.1.0-0-ga0ecdde.tar.gz | tar xvf -
  2. $ cd lloyd-yajl-2.1.0-0-ga0ecdde
  3. $ ./configure
  4. $ make
  5. $ sudo make install

Zeitpläne

Aufgabenverteilung

Name Zugehörigkeit
Zoor Management Tool
Reininger Management Tool
Preussner Management Tool
Kneib Management Tool
Werner Stress Tool
Mierswa Stress Tool


Andreas Zoor

Datum Stunden Tätigkeit
31.10. 4 Teambesprechung, ESXi Installation
02.11. 4 Installation libvirt => Probleme beim compilieren.
04.11. 4 Installation libvirt => Probleme gefixed.
07.11. 6 Recherche libvirt => Migration und Support KVM
09.11. 1 Struktur der Präsentation
10.11. 2 VM Ware Tools auf VM1-Ubuntu-Server installiert.
10.11. 5 Einarbeitung libvirt => Entwicklung Migrationstool
11.11. 6 Einrichten vMotion & Einarbeitung libvirt => Fertig stellen Migrationstool
14.11. 3 Teambesprechung
21.11. 2 Teambesprechung: ManagementTool => Interfaces & weiteres vorgehen
25.11. 6 Präsentation: Besprechung und Folien bearbeitet
28.11. 2 Besprechung Struktur und Ist-Zustand Deamon.
29.11. 7 Architektur Deamon umstrukturiert. => Speicherfehler in der vm weiter untersuchen.
08.12. 4 KVM Knoten über Deamon XML-RPC Fehler => Fehler untersucht.
12.12. 3 Bekannte Fehler untersucht und beseitigt.
12.12. 5 Weiter Daten aus KVM und ESXi Konten ausgelesen. Code für die Migration vorbereitet.
15.12. 3 Recherche VM Migration ESXi zu KVM.
29.12. 5 Recherche VM Migration ESXi zu KVM.
31.12. 3 Recherche VM Migration ESXi zu KVM, Einrichten virt-manager + XServer auf KVM node.
02.01. 5 Recherche VM Migration ESXi zu KVM, Implementierung und von vcores & memory verändern.
03.01. 6 Implementierung und von vcores & memory veränder => Brauch nur die verbindung zum vCenter.
04.01. 4 Datenstruktur verändert da nur ein Connect zum vCenter benötigt wird.
07.01. 3 VMware Java Zugriff umgestellt auf vCenter.
11.01. 9 Datenstruktur verändert. Migration Esxi Knoten. SLA Verarbeitung + Applications mapping. used Memory auslesen.
13.01. 4 Implementierung Planning und Execute. Anpassung der Datenstrukturen aufgrund neuer update Strategie.
18.01 8 Synchronisierung der Daten, Verbindung zu den Stress-Tool Serven, Keine Kopien mehr von Listen. Inbetriebnahme der Services: VM & SLA
19.01 2 Einrichten von ssh auf KVM-VMs
21.01 4 Verbinden des Deamon und des Stress-Tools
23.01 8 Config umgeschrieben, Applikationsdaten synchronisiert, stress-tool auf VM's integriert, Log Einträge generiert, stress-tool bugs reported.
25.01 3 Kommunikation mit dem stress-tool aktualisiert. (Protokoll-Version 5)
26.01 6 Systemtest.
26.01 3 Folien für die Präsentation.
27.01 9 Review Folien,Folien für die Präsentation angepasst, letzte Verbesserungen.
01.02 5 Doku.
02.02 2 Doku.
03.02 2 Doku.
10.02 2 Doku.

Andreas Werner

Datum Stunden Tätigkeit
04.11. 2 Besprechung mit Hr. Mierswa bezüglich Architektur der Stress-Test-Anwendung, Zeitplan erstellen
09.11. 3 Tests mit SNMP Deamon und /proc/stat interface für Regelkreis
12.11. 2 Definition Komunikation Header
15.11. 3 Implementirung des Last Generators angefangen
23.11 1 Kenzahlen des Last Generators in Protokoll aufgenommen
25.11 1 Erstellung der Forlien
01.01 2 Recherche + Implementirung CPU Auslasstung auslesen
01.01 1 Recherche IO Auslasstung auslesen
02.01 5 Recherche + Implementirung IO Auslasstung auslesen
03.01 2 Recherche + Implementirung Net Auslasstung auslesen
04.01 5 Implementirung und Test CPU Last generator
11.01 5 Fertischstellung und Test CPU Last generator implemenation und Test Protokoll Parser
13.01 7 Implementirung Testsystem für Server + Test Protokoll Parser
14.01 1 Protokoll Tests
18.01 1 Anpassung des Buidsystems
20.01 5 Implementirung Speicherstress
22.01 1 Hinzufügen von Destiantion IP Addr
23.01 5 Entfernung von Padding Bits aus dem Protokoll + Tests
26.01 5 Tests + Verbesserungen
27.01 1 Pressenation Vorbereitung
10.02 5 Doku
11.02 8 Doku

Jonas Reininger

Datum Stunden Tätigkeit
31.10. 4 Teambesprechung, ESXi Installation
04.11. 4 Installation libvirt mit ESX Treiber und erster Connect zu Hypervisor
06.11. 3 libvirt Tests
09.11. 4 libvirt virsh Kommandos, Details ESX-Treiber
12.11. 3 vSphere Web API Dokumentation gelesen
13.11. 6 vSphere Web API Dokumentation gelesen, Client-Stubs für C++ generiert
14.11. 6 Besprechung Präsentation und Architektur, GUI
16.11. 4 GUI
22.11. 3 GUI
24.11. 4 GUI
25.11. 8 Präsentation, Teambesprechung, GUI
03.12. 3 Präsentation
10.12. 2 Teambesprechung
12.12. 2 Beseitigung kleinerer Fehler in der GUI
14.12. 4 Beseitigung kleinerer Fehler in der GUI, Dokumentation
16.12. 3 GUI Detailansicht, Test der Anzeige mit zufälligen Werten
20.12. 2 Dokumentation (Struktur, genauere Beschreibung (Aufgabenstellung, Umgebung))
29.12. 2 GUI Interface Änderungen angepasst
05.01. 3 GUI
06.01. 5 WMware vSphere API Dokumentation
11.01. 3 WMware vSphere API Dokumentation (Performance Counter)
13.01. 2 WMware vSphere API Beispiele (Performance Counter)
18.01. 2 VM/Knoten RAM auslesen - erste Erfolge
23.01. 4 Fehler behoben, libvirtd Einstellungen (qemu+ssh://...)
24.01. 3 Präsentation angepasst
26.01. 6 Systemtest, Präsentation und kleine Fehler beseitigt
27.01. 7 Präsentation Vorbereitungen
02.02. 1 Dokumentation
03.02. 1 Dokumentation

Markus Preußner

Datum Stunden Tätigkeit
31.10. 4 Teambesprechung, ESXi Installation
7.11. 8 Teambesprechung, libVirt unter Windows, Linux einrichten, Example laufen lassen
9.11. 1 Teambesprechung (Präsentation)
11.11. 3 Untersuchung KVM oder XEN, Test Installation von KVM auf CentOS
11.11. 1 libVirt API eingelesen
14.11. 4 Teambesprechung, ESXI mit Java ansprechen, libVirt mit Java, libVirt.dll für Windows
19.11. 2 Remote Management für Knoten 3
21.11. 3 Teambesprechung, Implementierung des Daemon (XML Reader, ESXI, Interfaces)
25.11. 3 Besprechung der Präsentation
25.11. 4 Erstellen der Präsentation
26.11. 2 Implementierung Daemon
29.11. 2 KVM Server eingerichtet (libVirt, qemu, iscsi fehlt noch)
02.12. 2 Präsentationsbesprechung, Anpassungen
03.12. 2 Untersuchen des JVM Errors
10.12. 1 Problembehebung: Remotezugang zu KVM - Ungelöst
11.12. 3 Problembehebung: Remotezugang zu KVM - Trotz scheinbar korrekter Konfiguration remote nicht möglich
12.12. 5 Problembehebung: Remotezugang zu KVM/ESX über libVirt - Gelöst
13.12. 3 Lokaler KVM Storage Pool eingerichtet.
15.12. 2 VMware zu KVM migrieren
17.12. 2 VMware vmfs
31.12. 5 VMware zu KVM Migration, KVM ISCSI Konfiguration für vmfs-fuse, Netwzerk-Einstellungen für KVM
02.01. 5 VMware zu KVM Migration Stand notiert, Umsetzung von CPU Takt/Core, Neubau von libvirt 1.2.11 und esxi java api
03.01. 2 VMware Java API connect über vCenter, Administration von VMs
07.01. 4 VMware Java Zugriff umgestellt auf vCenter und Vorbereitung für das Entfernen von libVirt getroffen
11.01. 7 Umbau des Service + SLA Integration
13.01. 6 Bridge für KVM erfolgreich eingerichtet + KVM guest config angepasst
18.01. 8 Fehlersuche für KVM Gäste, Einbau von Logging
19.01. 6 Versuch der Anbindung des Stress Tools, KVM Gäste fertig eingerichtet
21.01. 2 Stress Tool Anbindung
23.01. 10 Stress Tool Anbindung, Stress Tool Deployment, Gäste Konfiguriert, Log erweitert, Umbau Daemon für Stress Tool
26.01. 6 Systemtest, Präsentation und kleine Fehler beseitigt
26.01. 3 Präsentation Folien
27.01. 8 Präsentation Folien
04.02. 3 Dokumentation
10.02. 2 Dokumentation

Daniel Mierswa

Zeitplan von Daniel Mierswa

Marcel Kneib

Datum Stunden Tätigkeit
31.10. 4 Teambesprechung, ESXi Installation
01.11. 5 Asterix iSCSI, VM1, Repository Konfiguration
03.11. 4 Obelix, VM1 Konfiguration, Wiki Einrichtung, vCenter Appliance
04.11. 4 vCenter eingerichtet, Cluster erstellt, Hosts hinzugefügt, C-Beispiel: libVirt Verbindungsaufbau zum Host
09.11. 3 Struktur der Präsentation, libVirt Einarbeitung
10.11. 2 Mangement Lib Grundstruktur
11.11. 4 weiterarbeiten an Mangement Lib, Präsentationsstruktur
13.11. 3 Qt Einarbeitung, Planung
14.11. 6 Besprechung Präsentation und Architektur, GUI
16.11. 4 GUI
21.11. 4 Teambesprechung, GUI
22.11. 2 GUI
24.11. 6 Präsentation, GUI
25.11. 8 Präsentation, Teambesprechung, GUI (Daten, Anzeige via Thread, kontinuierliche Aktualisierung)
01.12. 3 Präsentation, GUI
02.12. 2 Präsentation
09.12. 5 Datenhaltung in der Oberfläche
12.12. 2 Beseitigung kleinerer Fehler in der GUI
14.12. 4 Beseitigung kleinerer Fehler in der GUI, Dokumentation, kleinere Anpassungen (Graph verschönert, flüssigere Anzeige)
16.12. 3 Actionlistener und Eventhandling in der Detailansicht
20.12. 2 Dokumentation (Struktur, genauere Beschreibung (Aufgabenstellung, Umgebung))
31.12. 2 GUI Interface Änderungen angepasst
4.01. 2 GUI
6.01. 5 GUI & Deamon Zusammenführung, Problembehebung
11.01. 5 GUI & Deamon Zusammenführung, Node und VMs integriert
12.01. 3 GUI & Deamon Zusammenführung, Datenhaltung angepasst, Fehler beseitigt
13.01. 5 Fehler beseitigt, RMI Problem (Objektkopien) beseitigt, GUI Komponenten angepasst
18.01. 4 VM Daten eingebunden, Sync Probleme beseitigt
21.01. 3 GUI Interface korrigiert, Probleme behoben
23.01. 5 Anwendung und Log eingebunden
24.01. 3 Präsentation angelegt & angepasst, GUI Fehler beseitigt
25.01. 2 Präsentation, Organisatorisches (Notebook vorbereitet für die Probe)
26.01. 6 Systemtest, Präsentation und kleine Fehler beseitigt
27.01. 7 Präsentation Vorbereitungen
01.02. 2 Dokumentation
03.02. 3 Dokumentation
10.02. 2 Teambesprechung, Dokumentation

Links

Name Link Beschreibung
Repository https://zenon.cs.hs-rm.de/marcel.b.kneib/systemarchitektur/tree/master zenon git
libVirt http://libvirt.org/ libvirt Wiki, Doku, ...
libVirt 1.2.10 Source http://libvirt.org/sources/libvirt-1.2.10.tar.gz.asc libVirt Version fürs Projekt
vSphere Web Client https://10.18.62.202:9443/vsphere-client/ Konfigurationsoberfläche
KVM Remote https://automatix-mgmt.vs.cs.hs-rm.de KVM Remote Managment für Knoten 3 (automatix), User: sysarch, Pw: (Knoten Pw)
  1. [Kernel Dokumentation: Documentation/filesystems/proc.txt]
  2. [[1]]