D5.2 Ergebnisse der Evaluierung

Transkript

1 D5.2 Ergebnisse der Evaluierung Arbeitspaket/Task: AP 5 Task 5.2 Fälligkeit: M30 Abgabetermin: Verantwortlich: Versionsnummer/Status: Autoren: Interne Gutachter: NEC Jeutter, Andreas (AJ) Focht, Erich Lohrer, Marc Schwitalla, Jürgen Volk, Eugen Koudela, Daniela Belonozhka, Polina Schmidt, Matthias Schwarzkopf, Roland Volk, Eugen Schwarzkopf, Roland 471 Finale Version NEC NEC S&C S&C HLRS ZIH ZIH UMA UMA HLRS UMA Vertraulichkeitsstatus Öffentlich Projektintern Sonstiges: X Version Datum Änderungen Autor Erstellung AJ Aktualisierung des Dokuments Alle Autoren Review und Aktualisierung des Dokuments Alle Autoren D5.2 Ergebnisse der Evaluierung v471 1/

2 Inhaltsverzeichnis 1 Einleitung Komponenten des Systems Monitoring Block Channels Tools Importer Schnittstellen zu anderen Komponenten Testszenarien Aggregatoren Hostaggregator Groupaggregator Schnittstellen zu anderen Komponenten Testszenarien Metrik Datenbank Tools Schnittstellen zu anderen Komponenten Testszenarien Hierarchie Regressionstests Compliancetests Filter & Event Generator Schnittstellen zu anderen Komponenten Testszenarien Management Block Rule-Engine Policy-Engine Testszenarien Schnittstellen zu anderen Komponenten Delegate D5.2 Ergebnisse der Evaluierung v471 2/

3 4.3.1 Schnittstellen zu anderen Komponenten Testszenarien vmmanager Komponente zur dynamischen Partitionierung Schnittstellen zu anderen Komponenten Testszenarien Integrationstests der Prototypkomponenten Testszenario 1: Importer - Channel - Metrik Datenbanken Testszenario 2: Importer - Channel Aggregator Channel - Metrik Datenbank Testszenario 3: Metrik Datenbank - DirectRPC Testszenario 4: Hierarchie-Ebenen Testszenario 5: Regressiontest (ZIH) Online: Importer - Channel Regressiontest Offline: Metrik Datenbank DirectRPC Regressiontest Testszenario 6: Partitionierung des Systems Test-Szenario 7: Policy-Engine Test-Szenario 8: Test des TIMaCS-Frameworks Szenariobeschreibung Ergebnisse Zusammenfassung Referenzen D5.2 Ergebnisse der Evaluierung v471 3/

4 1 Einleitung In diesem Dokument werden die Ergebnisse der Evaluierung des ersten integrierten Prototypen von TIMaCS dargestellt. Nachdem die Funktionalität der einzelnen Komponenten sichergestellt wurde, soll nun deren Zusammenwirken (Integration) an Hand von Testszenarien evaluiert werden. Die TIMaCS-Software wird auf dem zur Verfügung stehenden Entwicklungssystem (TIMaCS Cluster bestehend aus sechs Knoten) getestet. Dieses (kleine) Cluster ist ausreichend um die Komponenten bzw. deren Zusammenwirken auf richtige Funktionalität zu testen. In der nächsten Version dieses Dokuments soll der Test des TIMaCS-Frameworks auf einem großen System (BW-Grid mit etwa 500 Knoten) vorgesehen. Auf diesem System soll die Skalierbarkeit getestet werden. Um den Test spezieller Funktionalitäten (wie VM-Management) abzudecken ist ein Test auf dem im Aufbau befindlichen Games-Cluster vorgesehen. Allerdings wird dieses Cluster erst Ende Juli 2011 zur Verfügung stehen. D5.2 Ergebnisse der Evaluierung v471 4/

5 2 Komponenten des Systems In der folgenden Abbildung 1 ist die Gesamtarchitektur des TIMaCS Systems und die Interaktion der einzelnen TIMaCS Knoten dargestellt, entsprechend der Beschreibung und Darstellung in [D1.2] und [D1.3]. Legende Kommando Daten, Nachrichten, Ereignisse, Reports Heartbeat Update... Nachrichten / Ereignisse / Reports TIMaCS Administrator Knoten Heartbeat... TIMaCS Knoten Kommando Aktualisierung der Wissensbasis Aktualisierung der Wissensbasis... Wissensbasis Regeln, Policies,.. Wissensbasis Regeln, Policies,.. Aktualisierung der Wissensbasis Kommando Nachrichten / Ereignisse / Reports Nachrichten / Ereignisse / Reports Kommando Aktualisierung der Wissensbasis... Wissensbasis Regeln, Policies,.. TIMaCS Knoten Heartbeat... Heartbeat TIMaCS Knoten... Wissensbasis Regeln, Policies,.. Kommando Daten Daten Kommando Kommando Daten Daten Kommando Heartbeat Heartbeat Delegate Sensor Sensor Überwachte Ressource 1 Sensor... Sensor Sensor Sensor Überwachte Ressource n... Delegate Delegate Sensor Sensor Überwachte Ressource 1 Sensor Rechenknoten Rechenknoten Rechenknoten Abbildung 1: Hierarchische Struktur des Gesamtsystems.... Sensor Sensor Sensor Überwachte Ressource n Rechenknoten Delegate Die logische Struktur eines TIMaCS Knoten, dargestellt in Abbildung 2, wird durch einen Monitoring- und einen Management Block gebildet. D5.2 Ergebnisse der Evaluierung v471 5/

6 Legende Kommando, Query Daten Nachrichten, Events, Reports Heartbeat Rule/Policy Update TIMaCS Knoten Monitoring Block Data Data Query Events Data Heartbeat Kommando Management Block Kommando Events, Reports Heartbeat Heartbeat Kommando Wissensbasis Regeln, Policies,.. Sensor Sensor Sensor Überwachte Ressource 1 Abbildung 2: Struktur eines TIMaCS Knotens.... Delegate Sensor Sensor Sensor Überwachte Ressource n Delegate Im Folgenden werden kurz die bereits aus [D1.2] und [D1.3] bekannten Komponenten und deren Schnittstellen zu anderen Komponenten beschrieben. 3 Monitoring Block Der Monitoring Block setzt sich aus den Komponenten Channel, Importer, Metrik Datenbank und Aggregatoren zusammen. Das essentielle Datenformat für den Datenaustausch in TIMaCS ist das sogenannte Metrik Objekt. Dabei handelt es sich um eine Datenstruktur, die Key-Value-Pairs beinhaltet. Als Keys werden ausschließlich Strings verwendet, wohingegen Values jeden beliebigen Datentyp annehmen können. Die Anzahl und die Namen der Keys in einer Metrik sind beliebig, wobei die folgenden Keys immer vorhanden sein müssen. name value source host time Key Name der Metrik Wert des Datums Bemerkung Ursprung der Metrik (i. Allg. Name der Applikation) Name des Knotens, für den diese Metrik gilt Zeitpunkt (in Sekunden seit ) für den der Wert Gültigkeit hat D5.2 Ergebnisse der Evaluierung v471 6/

7 Da die gesamte Software, die für den Monitoring Block von TIMaCS entwickelt wurde in der Programmiersprache Python implementiert wurde, werden Metriken i. Allg. auch in der Python Notation dargestellt. Dies erlaubt die einfache Lesbarkeit und ermöglicht die Erzeugung eines Python-Objektes mittels der eval() Funktion. Hier ein Beispiel für ein Metrikobjekt, welches aus einem Datensatz des Gangliaimporters erzeugt wurde. Metric(name=u'load_fifteen', tmax=950, type_=u'float', value=0.0, tn=77l, source=u'gmond', host=u'n105', time= l, units=u' ', dmax=0) Alle Komponenten des Monitoring Blocks werden über einen Daemonprozess (htimacsd) gestartet. htimacsd startet dabei entsprechend der Hierarchiestruktur (siehe folgende Kapitel) des Systems die entsprechenden Komponenten. Der Daemon wird hierbei mittels Konfigurationsdateien und Kommandozeilenoptionen gesteuert. Um eine Übersicht der verfügbaren Optionen zu erhalten, kann htimacsd mit dem Argument --help gestartet werden. 3.1 Channels Die TIMaCS zugrunde liegende Kommunikationsschicht wird durch ein Publish / Subscribe System mit einem AMQP Server gebildet. Die Schnittstelle zu AMQP wird durch sogenannte Channels abstrahiert und optimiert. Befinden sich Publisher und Subscriber einer Nachricht auf demselben Knoten, so kann der aufwändige Transport über AMQP durch die Abstraktionsschicht zu einem lokalen Funktionsaufruf abgekürzt werden. Zur Adressierung wird ein sogenannter Topic verwendet, der sich wie folgt zusammensetzt: <nodename>.<source>.<metrikname> Beispiel: n101.gmond.load_one Die Verwendung von Wildcards ist möglich. So adressiert das folgende Beispiel z.b. alle Metriken, die von Knoten n101 bereitgestellt werden. n101.*.* Channel sind für die Kommunikation der einzelnen Komponenten essentiell und bilden daher das gemeinsame Bindeglied. Über Channels werden ausschließlich Metriken des oben beschriebenen Formates transportiert. Ein Channel wird durch eine URL spezifiziert, welche dem folgenden Schema folgt: scheme://username:password@hostname.domain/channelname Hierbei kann scheme die Werte amqp, local oder pika annehmen. AMQP benutzt im Normalfall die D5.2 Ergebnisse der Evaluierung v471 7/

8 Werte guest:guest für username und password. Im Wesentlichen werden zur Kommunikation über einen Channel die Funktionen publish(), subscribe() und notify_callback() benötigt. Diese bilden somit die Hauptschnittstelle zwischen den Komponenten im Monitoring Block. Über diese Schnittstelle werden Daten im eben beschriebenen Metrikformat ausgetauscht Tools Für Debug- und Testzwecke wurde ein Werkzeug (channel_dumper.py) entwickelt, welches erlaubt, die über einen Channel verschickten Metrikdaten zu monitoren. Der channel_dumper.py kann dabei auch in einem raw-modus benutzt werden, in dem nicht nur die Nutzlast, sondern die gesamte AMQP Nachricht ausgegeben wird. Usage: channel_dumper.py [options] Options: -h, --help show this help message and exit --channel=channel URL of channel to listen to --raw Dump raw AMQP messages --topic=topic topic to subscribe, default matches all topics Zusätzlich zu den Metrikdaten gibt der channel_dumper.py auch noch eine kurze Statistik über die Anzahl der empfangenen Metriken aus. 3.2 Importer Importer sammelt die Daten der unterschiedlichen Sensoren ein und stellt sie dem TIMaCS System in aufbereiteter Form als Metriken zur Verfügung. Es stehen Importerklassen für die Sensoren Ganglia, Nagios und Collectd zur Verfügung. Zur Konfiguration ist eine Datei mit den Definitionen der Importer auf der htimacsd Kommandozeile über die Option --conf-importer=path/file anzugeben. Hier eine Beispielkonfiguration, die jeweils eine Instanz der oben aufgeführten Importer startet. [importers] GangliaXMLMetric 1 = host_name=localhost:only_group=<false>:only_self=<false> NagiosStatusLog = url="ssh://myname@nagios/var/log/nagios/status.log" SocketTxt 1 = port_or_path="10000" Schnittstellen zu anderen Komponenten Zum einen werden die Daten von den unterschiedlichen Sensoren gelesen, aufbereitet, d.h. in ein einheitliches Format (Metric) gepackt, und über die publish() Funktion anderen Komponenten zur Verfügung gestellt. D5.2 Ergebnisse der Evaluierung v471 8/

9 3.2.2 Testszenarien Die Funktion der Importer inklusive Schnittstelle wird unter anderem durch das in Kapitel 6 beschriebene Testszenario 1 getestet. 3.3 Aggregatoren Aggregatoren abstrahieren die gesammelten Monitoringdaten (Metrik) zur Bildung von Durchschnittswerten und Aggregaten. Abhängig vom Anwendungsfall können Metriken eines einzelnen Knotens, wie z.b. Berechnung der durchschnittlichen CPU Temperatur auf einem Knoten, oder einer Gruppe, z.b. Bildung der mittleren Last aller Gruppenknoten, konfiguriert werden. Aggregatoren werden in einer Datei konfiguriert, welche dem Daemon htimcsd über den Parameter --conf-aggregator=path/file übergeben wird Hostaggregator Ein Beispiel für einen einfachen Hostaggregator, welcher die drei Zustände OK, WARNING und CRITICAL annehmen kann. [aggregator_preset ThreeStateNumeric] base_class = HostSimpleStateAggregator state_ok = OK state_warning = WARNING state_critical = CRITICAL cond_ok = ((metric.value < arg_warn) and (arg_warn <= arg_crit)) or ((metric.value > arg_warn) and (arg_warn > arg_crit)) cond_warning = ((arg_warn <= metric.value < arg_crit) or (arg_crit < metric.value <= arg_warn)) cond_critical = ((metric.value >= arg_crit) and (arg_warn <= arg_crit)) or ((metric.value <= arg_crit) and (arg_warn > arg_crit)) max_age = Groupaggregator Beispiel für einen Gruppenaggregator, der aus der Metrik mit dem Namen load_one die Summe (Zeile 2) und den Durchschnitt (Zeile 3) der Knoten in der zugehörigen Gruppe bildet und als neue Metrik mit dem Namen grpsumc_load_one bzw. grpavgc_load_one veröffentlicht. [aggregate] load_one as grpsumc_load_one = GroupSumCycle:max_age=<30> load_one as grpavgc_load_one = GroupAvgCycle:max_age=<30> cpu_num as grpsumc_cpu_num = GroupSumCycle:max_age=<30> cpu_num as grpmax_cpu_num = GroupMax # demo for preset aggregator: warning if load_one exceeds 2, critical if it exceeds 5 load_one as overload_state = ThreeStateNumeric:arg_warn=<0.1>:arg_crit=<5.0> overload_state as grp_overload_state = GroupTristateCycle:max_age=<130> Schnittstellen zu anderen Komponenten Aggregatoren erhalten Metrikdaten aus dem Publish/Subscribe System indem sie bestimmte Topics D5.2 Ergebnisse der Evaluierung v471 9/

10 abonnieren. Die erhaltenen Metriken werden mit Hilfe der konfigurierten Methoden aggregiert und mit neuem Topic den entsprechenden Komponenten (i. Allg. auf Gruppenmaster Knoten) wieder über das Publish/Subscribe System zur Verfügung gestellt Testszenarien Aggregatoren sind die elementaren Komponenten, die Daten aus Gruppen entsprechend der Hierarchie an Gruppenmaster weiterleiten. Daher sind sie in nahezu allen Testszenarien involviert (von trivialen Hierarchien mit nur einem Level abgesehen). Die Funktionalität und Interaktion mit anderen Komponenten kann deshalb mit dem in Kapitel 6 beschriebenen Testszenario 2 sichergestellt werden. 3.4 Metrik Datenbank Die Aufgabe der Metrik Datenbank ist das Speichern der gesammelten Sensordaten im Metrikformat. Gleichzeitig bietet die Metrik Datenbank eine Abfrageschnittstelle, die es ermöglicht gespeicherte Metriken abzufragen (Query). Die resultierenden Metriken können entsprechend eines Zeitintervalls und eines Wertebereiches ( where-clause ) gefiltert werden. Die Metrik Datenbank kann als verteiltes System betrachtet werden. D.h. auf allen als Gruppenmaster (weitere Informationen dazu im Kapitel Hierarchie) aktiven Knoten wird von htimacsd automatisch eine Instanz erzeugt. Diese Instanz speichert jeweils die Daten der zugehörigen Gruppenknoten. Die Datenbank stellt eine RPC (Remote Procedure Call) Schnittstelle zur Verfügung welche zur Abfrage der Daten (Query) benutzt werden kann. Für diese Schnittstelle existiert ein Kommandozeilentool (Beschreibung im folgenden Kapitel). Es sind die folgenden Methoden via RPC registriert und können abgefragt werden. Die Ergebnisse eines RPC Aufrufs werden in Python Notation wiedergegeben, d.h. sie können über eine eval() Operation wieder in Objekte gewandelt werden. dbsetoffline(group_path): Setzt die Instanz der Datenbank in den offline Modus. Im offline Modus wird kein sog. Commit durchgeführt. Die Datenbank speichert jedoch die empfangenen Metriken im Speicher. Diese Funktion dient der Synchronisation zwischen zwei Datenbankinstanzen. dbsetonline(group_path): Setzt die Datenbank zurück in den online Modus und speichert alle Metriken, die gepuffert wurden. gethostnames(group_path): Listet alle Knotennamen, für die Metriken gespeichert sind. getlastmetricsbyhostname(group_path, host_name): Gibt ein Objekt vom Typ MetricSet zurück.ein MetricSet ist eine Liste, die Metriken eines bestimmten Knotens beinhaltet. getlastmetricbymetricname(group_path, host_name, metric_name): Gibt eine Metrik spezifiziert durch host_name und metric_name zurück. Diese Metrik enthält die aktuellsten (die letzten gespeicherten) Wert (value) und Zeit (time) Attribute. D5.2 Ergebnisse der Evaluierung v471 10/

11 getlastseen(group_path, host_name): Zeigt die last_seen und age Werte eines Knotens an. getmetricnames(group_path, host_name): Listet alle Namen (name) von Metriken, die für einen bestimmten Knoten (host_name) gespeichert sind. getrecordsbymetricname(group_path, host_name, metric_name, start_s, end_s, nsteps, step_s): Gibt eine Liste (list) zurück, die Objekte vom Typ Record beinhaltet. Jeder Record besitzt zwei Attribute: time_ns (Zeit in 10E-9 Sekunden) und value (Wert). Das Argument start_s in Sekunden gibt den frühesten Zeitpunkt an, ab dem Records geliefert werden. end_s (in Sekunden) gibt den Endzeitpunkt an. Mit step_s lässt sich die Anzahl der zurückgelieferten Objekte beeinflussen. getsummary(group_path, path): Gibt ein directory Listing eines Pfads innerhalb der serialisierten Datenbank aus. gettimeseriestype(group_path, host_name, metric_name): Gibt einen String zurück, der den Typ der Metrik beinhaltet. Dies kann RRD (nummerische Typen, wie Float, Integer,...) oder LOG (String) sein. findwheremetric(group_path, metric_name, metric_attr, condition, value, recurse=false): Gibt Knotennamen und Metriken zurück, für welche das angegebene Metrikattribut (metric_attr) die Bedingung (condition) für den Wert (value) erfüllt. Dies Methode ist auf Geschwindigkeit optimiert und durchsucht nur Metriken, die sich im Speicher befinden, d.h. Metriken, die bereits auf Festplatte gespeichert sind werden nicht berücksichtigt. Wenn recurse auf true gesetzt wird, dann werden alle auf einem niedrigeren Level liegenden und zum gegenwärtigen Ast gehörenden Datenbankinstanzen ebenfalls durchsucht. hierarchygroupnames(group_path): Hilfsfunktion, welche alle Gruppenpfade (group_path) in der Hierarchie auflistet, die Kinder des angegebenen group_path Parameters sind. Mit dieser Funktion ist es möglich sich den Hierarchiepfad von der Wurzel aus zu erschließen. getdbinstances(): Listet alle Datenbankinstanzen auf, die auf diesem Knoten aktiv sind. Gibt eine Liste von Gruppenpfaden (group_path) zurück, für die der Knoten ein Gruppenmaster ist. Abfragen der Datenbank, welche über die RPC Schnittstelle erfolgen, haben die allg. Form: python src/timacs/direct_rpc_client.py <node> <method> <group_path> Node entspricht dem Knotennamen. Method ist eine der obigen Methoden. Group_path spezifiziert den Gruppenpfad, für den Informationen angefragt werden. Sollte der angefragte Gruppenpfad nicht in der Datenbank des Knotens, an den der RPC gerichtet wurde, vorhanden sein, so leitet der Knoten diese Anfrage automatisch an den entsprechenden Knoten weiter. Informationen darüber, auf welchem Knoten die Metriken mit dem angefragten Gruppenpfad vorhanden sind, entnimmt der Knoten dem Hierarchieobjekt. D5.2 Ergebnisse der Evaluierung v471 11/

12 3.4.1 Tools Es existiert ein Kommandozeilentool mit dem alle registrierten RPCs aufgerufen werden können. Somit ist es auch möglich, die die Metrik Datenbank abzufragen. Hierzu ein Beispiel. python src/timacs/direct_rpc_client.py n102 getlastmetricsbyhostname /g1 [Metric(name='cpufreq', value= , source='collectd', host='n102', time= , type='cpufreq'), Metric(name='echo', value=3.0, source='collectd', host='deepsky', time= , type='absolute'), Metric(name='log', value='5', source='collectd', host='n102', time= , output='uc_update: Value too old: name = n102/echo-absolute/absolute-value; value time = ; last cache update = ;')] Schnittstellen zu anderen Komponenten Die Datenbank tritt aktiv nur als Datensenke (Subscriber) im System in Erscheinung und hat daher nur eine Schnittstelle zum Publish / Subscribe System. Zur Abfrage der Datenbank ist eine RPC (Remote Procedure Call) Schnittstelle implementiert, für die ein einfacher Client (direct_rpc_client.py) zur Verfügung steht. Diese Schnittstelle kann auch von anderen Komponenten benutzt werden Testszenarien Die Abfrage (Query) der Datenbank wird im Testszenario 3 getestet. 3.5 Hierarchie Die Hierarchie wird durch Knoten (hosts, compute nodes) und Gruppen gebildet. Gruppen können weitere Gruppen und Knoten beinhalten. Daraus kann ein baumartiger Graph gebildet werden. Die Kommunikation der Monitoringkomponenten über das Publish/Subscribe System erfolgt dann entlang der Kanten des Graphen. Die Position der Knoten innerhalb des Baumes wird durch deren Pfad von der Wurzel aus den über die jeweiligen Gruppen gebildet, deren Namen mit einem Schrägstrich / verkettet werden (in Anlehnung zu bekannten Dateisystempfaden). Das folgende Beispiel zeigt die Konfiguration der Hierarchie auf dem HLRS Entwicklungssystem, welches aus sechs Knoten besteht, die in zwei Gruppen mit Namen g1 und g2 aufgeteilt sind. Der Knoten n101 fungiert als Masterknoten auf dem obersten Level (dieses Level / diese Gruppe wird als universe oder abgekürzt / bezeichnet). D5.2 Ergebnisse der Evaluierung v471 12/

13 Abbildung 3: Aufteilung der Knoten mittels Gruppen, die eine Hierarchie bilden. Die Knoten sind in der Abbildung nicht nur mit ihrem Knotennamen, sondern mit der kompletten Gruppenpfadangabe bezeichnet. Diese Hierarchie muss beim Start von htimacsd mit der Option --hierarchy-cfg=<path/file> wie folgt angegeben werden. /n101 m:/ /g1/n102 m:/g1 /g1/n103 /g2/n104 m:/g2 /g2/n105 /g2/n106 Datenbankinstanzen und Aggregatoren werden von htimacsd automatisch anhand dieser Information auf allen Gruppenmastern, d.h.in diesem Fall auf n104, n102 und n101 gestartet. Sensordaten der Knoten n106, n105 werden dann in der Datenbank auf n104, Daten von n103 in der Datenbank auf n102 gespeichert. Die auf n102 und n104 laufenden Aggregatoren verwenden diese Metriken um wiederum Metriken zu erzeugen, die dann entlang der Kanten des Graphen D5.2 Ergebnisse der Evaluierung v471 13/

14 kommuniziert werden und in der Datenbank von n101 gespeichert werden. 3.6 Regressionstests Regressionstests analysieren den zeitlichen Verlauf von Monitoring-Daten. Durch den Vergleich mit früher gemessenen Werten können Performance-Verluste bemerkt werden, bevor es zu einem Ausfall der entsprechenden Komponente kommt. Dazu wird ein geeigneter Algorithmus auf eine konfigurierbare Menge von Daten angewendet. Dieser Vorgang wird im Folgenden als Regressionsanalyse bezeichnet. Das Ergebnis der Regressionsanalyse stellt das Resultat des Regressionstests dar. TIMaCS unterscheidet zwischen Online- und Offline-Regressionstests. Erstere werden nach ihrer Konfiguration regelmäßig von TIMaCS durchgeführt und greifen bei der Analyse nur auf die Daten der jüngsten Vergangenheit zurück. Diese bekommen sie direkt aus dem Publish/Subscribe-System und sie behalten die Daten in ihrem Arbeitsspeicher. Nur wenn TIMaCS neu gestartet wird und der Arbeitsspeicher noch leer ist, holen sie sich die Daten aus der Datenbank um gleich beim ersten Eintreffen eines Monitoringwertes der gewählten Metrik einen Regressionstest durchführen zu können. Im Gegensatz dazu werden Offline-Regressionstests nur auf Anfrage durchgeführt. Diese holen sich die Daten aus der Metrik Datenbank. Der Offline-Regressionstest hat den Vorteil, dass man das Zeitintervall, über das sich der Regressionstest erstrecken soll, frei wählen kann und bietet sogar eine Mittelungsroutine, um bei einer großen Menge an Daten lediglich die Mittelwerte älterer Daten zu berücksichtigen. Je nach Komplexität der gewählten Regressionsanalyse kann dies die Berechnung beschleunigen. Ein Online-Regressionstest abonniert die Metrik, deren Verlauf er analysieren soll. Er hält die letzten N Werte dieser Metrik im Speicher und jedes Mal, wenn ein neuer Wert dieser Metrik ankommt, wird das neue Ergebnis des Regressionstests berechnet. Abhängig vom eingesetzten Algorithmus kann die Berechnung sehr aufwendig sein, daher wird innerhalb des konfigurierten Zeitintervalls T die Berechnung nur einmal vorgenommen. Bei der Initialisierung, zum Beispiel beim Start von TIMaCS, liest ein Online-Regressionstest die letzten N 1 Werte seiner Metrik aus der Datenbank in seinen Zwischenspeicher, um beim nächsten Eintreffen eines Messwerts sofort einen neuen Wert ausgeben zu können. Online-Regressionstests laufen nur auf Master-Knoten. Es werden nur die Metriken analysiert, die von Rechnern kommen, für die dieser Knoten der Master-Knoten ist. Läuft TIMaCS auf allen Master-Knoten, so wird jeder konfigurierte Regressionstest genau auf einem Knoten des Clusters durchgeführt werden. Ein Offline-Regressionstest berechnet die Regressionswerte für die gewählte Metrik über einen bestimmten Zeitraum, der beim Aufruf des Tests angegeben wird. 3.7 Compliancetests Um Compliance-Tests durchzuführen, müssen diese zunächst konfiguriert werden. Dazu ruft man D5.2 Ergebnisse der Evaluierung v471 14/

15 das Programm do_compliancetest auf dem Administratorknoten mit folgendem Befehl auf: python bin/do_compliancetest.py config-file-compliancetest config/settings_compliancetest.conf Dieses Programm bietet die Möglichkeit, sich eine Liste aller verfügbaren Sensoren und Benchmarks anzeigen zu lassen, damit man die auswählen kann, die man für den Compliancetest benötigt. Hat man einen Compliancetest konfiguriert, so kann man die Konfiguration speichern, um ihn auch nach einem Neustart des Programms wieder aufrufen oder ggf. ändern zu können. Man kann so viele verschiedene Compliancetests konfigurieren, wie man möchte. Jeder konfigurierte Compliancetest kann beliebig oft durchgeführt werden. Compliance-Tests werden jedoch nur auf Anfrage durchgeführt. Damit Compliance-Tests erfolgreich durchgeführt werden können, muss auf jedem TIMaCS- Knoten eine Regelmaschine und ein TIMaCS-Daemon laufen. Die Regelmaschine muss Regeln enthalten, die die vom Compliance-Test generierten Metriken auswerten und Events generieren, die eine boolsche Interpretation des Ergebnisses und eventuelle Fehlermeldungen enthalten. Der TIMaCS-Daemon startet ein Delegate, das die Kommandos zum Abfragen der Sensoren in Befehle umwandelt, sowie die Durchführung der Benchmarks startet. Ferner startet er auch einen Aggregator, der die Events der Regelmaschine einsammelt und als aggregierte Nachricht an den Administratorknoten sendet, auf dem wiederum ein Aggregator läuft, der aus den aggregierten Nachrichten der TIMaCS-Knoten ein Gesamtergebnis des Compliance-Tests generiert. Zusätzlich zu den erwähnten Komponenten wurde ein Timer implementiert. Dieser ist nötig, um zu wissen, wann ein Compliance-Test beendet ist. Der Timer tritt an zwei Stellen in Erscheinung. Zum einen wird bei jeder Sensorabfrage und jeder Benchmarkdurchführung ein Timer gestartet. Liegt bei Ablauf des Timers kein Ergebnis des betreffenden Sensors oder Benchmarks vor, so wird die Abfrage/Durchführung abgebrochen und der daraufhin generierten Metrik wird als Fehlermeldung mitgegeben, dass der Timeout erreicht wurde bevor ein Ergebnis vorlag. Die Länge des Timeouts lässt sich für jeden Sensor oder Benchmark eines Compliance-Tests separat konfigurieren. Des Weiteren ist der Aggregator auf dem Administratorknoten mit einem Timer ausgestattet. Dessen Timer läuft mindestens so lange wie der längste Timer der von diesem Compliance-Test abgefragten Sensoren/durchgeführten Benchmarks plus eine konfigurierbare Zeitdauer. Liegen nach Ablauf des Timers nicht von allen involvierten TIMaCS-Knoten aggregierte Ergebnisse vor, so wird das bis zu diesem Zeitpunkt vorliegende Ergebnis dem Nutzer angezeigt sowie die Nachricht, welche Knoten bis jetzt kein Ergebnis gesendet haben. 3.8 Filter & Event Generator Der Filter & Event Generator filtert und evaluiert die gesammelten Monitoring-Daten um festzustellen, ob sie auf einen Fehler hindeuten. Im Falle einer Fehlererkennung, wird ein Event generiert und an den Management Block weitergeleitet. Der Filter & Event Generator ist durch eine Regelmaschine realisiert, die entsprechend der konfigurierten Regeln auf eingehende Nachrichten reagiert. Zum Testen der Regelmaschine existiert ein Testframework, in das eigene Tests einfach integriert werden können. Jeder Test wird dabei D5.2 Ergebnisse der Evaluierung v471 15/

16 durch eine Nachricht initialisiert, und es wird überprüft, ob innerhalb einer konfigurierten Zeitspanne eine Systemantwort, die wiederum als Nachricht vorliegen muss, eintrifft. Wie die erwartete Antwort aussehen muss, wird in den jeweiligen Tests formuliert. Getestet wird damit: Die Basisfunktionalität der Regelmaschine: Die Bausteine, die zur Formulierung der Regeln zur Verfügung stehen, werden in Tests auf korrekte Funktionalität überprüft. Die Performance: Durch das Testframework wird sichergestellt, dass das erwartete Ergebnis (wiederum eine Nachricht) innerhalb der im Test konfigurierten Zeit erreicht wird. Die Funktionalität der konfigurierten Regeln: Diese Tests prüfen nicht die Regelmaschine an sich, sondern stellen sicher, dass die konfigurierten Regeln sich wie erwartet verhalten. Dadurch wird nicht nur die Korrektheit der Konfiguration gesichert, die Tests dienen auch der Dokumentation der Regeln, weil in ihnen sowohl der erwartete Input als auch das Ergebnis beschrieben wird. In dem Testframework wird für jeden Test eine Triggernachricht an die Regelmaschine geschickt. Diese Nachricht initialisiert das Testframework und beschreibt außerdem, wie die erwartete Ergebnisnachricht aussehen soll und bis wann sie spätestens eintreffen muss. Wenn diese eintrifft, wird die im Test konfigurierte Erfolgsbedingung ausgewertet und entsprechend eine Erfolgs- oder Fehlernachricht als Testergebnis erzeugt. Falls die Antwort zu spät kommt oder ausbleibt, wird ebenfalls eine entsprechende Fehlernachricht als Testresultat verschickt. So wird sichergestellt, dass auch das Ausbleiben einer Antwort als Fehler erkannt wird. Durch dieses allgemeine Testframework ist es auch möglich, Tests über mehrere Regelmaschinen hinweg auszuführen. So kann z.b. durchaus in einem Test, der auf einer bestimmten Regelmaschine angestoßen wird, das erwartete Ergebnis von einer anderen Regelmaschine sichergestellt werden. Angestoßen werden die Tests entweder einzeln oder gebündelt aus dem graphischen Editor. Die Testresultate werden in der graphischen Oberfläche tabellarisch dargestellt Schnittstellen zu anderen Komponenten Der Filter & Event Generator ist durch Regeln in der Regelmaschine umgesetzt, damit sind die Schnittstellen zu den anderen Komponenten durch ein- und ausgehende Nachrichten realisiert. In direktem Kontakt zum Filter & Event Generator stehen die Monitoringkomponente, die Regressions- und Compliancetests und die Policy Engine. Die Funktionalität der konfigurierten Regeln wird mit dem Testframework getestet. Da das Zusammenwirken mit den anderen Komponenten wiederum durch Regeln beschrieben ist, kann dadurch auch die komplette Interaktion mit den Partnerkomponenten getestet werden Testszenarien Im Moment existieren die folgenden Tests: D5.2 Ergebnisse der Evaluierung v471 16/

17 Funktionalität der Regelmaschine: sendmessagetest: Test des Elements SendMessage zur Regelerstellung configwritertest: Test des Elements ConfigurationWriter zur Regelerstellung iteratortest: Test der Elemente Container Store Reader und Container Store Writer zur Regelerstellung typeconversiontest: Stellt sicher, dass innerhalb der Regelmaschine die Typkonvertierung (z.b. String->Float) korrekt funktioniert Spezifische Regeltests: normalizetest: Test, der die Funktionalität der Normierungsregel für eingehende Nagiosnachrichten prüft. 4 Management Block Die Aufgabe des Management-Blocks ist es, Entscheidungen zur Behandlung von Fehlern, welche durch Events identifiziert werden, zu treffen. Empfängt der Management-Block ein Event, das auf einen Fehler hindeutet, trifft er eine Entscheidung, wie der Fehler behandelt werden soll. Die Entscheidungen werden dann in Kommandos umgewandelt und auf Ressourcen mittels Delegates ausgeführt. Die Umsetzung der Komponenten des Management-Blocks erfolgt in Abhängigkeit vom Hierarchie-Level mit Hilfe der Rule-Engine (Level 1) und der Policy-Engine (Level 2 und höher). Die Rule-Engine ist auf Level 1 angesiedelt und ist zuständig für das Ausführen einfacher, meistens auf Schwellwertüberwachung basierenden Regeln. Sie besitzt eine vereinfachte Form des Event/Data-Handlers, der nur für das Empfangen und Weiterleiten der Nachrichten (Events) zuständig ist, und des Decision-Makers, der auf Basis vordefinierter Regeln die Auswertung der empfangenen Nachrichten (Events) durchführt und Entscheidungen in Form von Kommando-Nachrichten trifft. Die Policy-Engine ist auf Level 2 und höher angesiedelt und ist für die Evaluation komplexer Events oder Reports zuständig, die eine Auswertung der komplexen System- Zustände und Abfrage der semantischen Datenbanken erfordern. Sie besitzt den vollen Umfang der in [D1.3] Abschnitt 3.3 beschriebenen Funktionalität des Management-Blocks. 4.1 Rule-Engine Der Definition der Testszenarien und der Test der Rule-Engine erfolgt in der gleichen Weise wie in Kapitel 3.8 beschreiben, da der Filter&Event-Generator mit Hilfe der Rule-Engine umgesetzt wird. 4.2 Policy-Engine Der Test der Policy-Engine erfolgt durch Vorbelegung der Wissensbasis mit vordefinierten Werten D5.2 Ergebnisse der Evaluierung v471 17/

18 und durch Erzeugung der zu verarbeitenden Event-Nachrichten, die eine Reaktion des Managementblocks in Form einer Aktion-Nachricht oder Event-Nachricht bewirkten. Damit kann getestet werden: Die Funktionalität der Policy-Engine: Zum Testen der Funktionalität der Policy-Engine sind mehrere Testfunktionen in die Policy-Engine eingebaut, die die Wissensbasis mit den vordefinierten Zustands-Werten der überwachten Ressourcen belegen und vordefinierte Event-Nachrichten erzeugen. Die erzeugten Event-Nachrichten werden von allen Komponenten der Policy-Engine verarbeitet. Dabei werden in jedem Verarbeitungsschritt die Zwischenergebnisse angezeigt, welche eine Übersicht über Inhalt und Änderung der Wissensbasis sowie die getroffenen Entscheidungen liefern. Da jeder Entscheidungsschritt mit den erwarteten Ergebnissen verglichen werden kann, lässt sich damit auch die Funktionalität der konfigurierten Policies und Regeln überprüfen. Als Ergebnis der Entscheidung des Management Blocks wird eine Nachricht generiert und am Bildschirm ausgegeben, welche mit der erwarteten Soll-Nachricht verglichen werden kann. Funktionalität der Schnittstellen: Zum Testen der Funktionalität der Schnittstellen, welche die Policy-Engine an den Message-Bus anbindet, werden Event-Nachrichten erzeugt und über den Message-Bus versendet. Die Policy-Engine verarbeitet diese Nachrichten in der oben erwähnten Weise und erzeugt Antwort-Nachrichten, welche über den Message- Busversendet werden. Die versendeten Nachrichten werden mit einem Client ausgegeben. Die Performance: Zur Messung der Verarbeitungsgeschwindigkeit der Policy-Engine kann die Zeit pro Verarbeitung einer Nachricht, von der Einspeisung der Nachricht bis zur Erzeugung der Ergebnisse, gestoppt werden. Hierzu ist in der Policy-Engine eine Zeitstopp- Funktion eingebaut. Des weiteren kann auch die Zeit für die Verarbeitung mehrerer Nachrichten gemessen werden Testszenarien Zustandsänderung, -propagierung und Erzeugung der Kommando-Nachricht Die Wissensbasis der Policy-Engine wird zunächst mit den modellierten Abhängigkeiten zwischen den unterschiedlichen Ressourcen/Services als auch mit den vordefinierten Zustands-Werten belegt. Anschließend wird eine Test-Event-Nachricht in den Message-Bus eingespeist, die einen kritischen Fehler-Event in einer der abhängigen Ressource enthält. In jedem Verarbeitungsschritt wird die Auswirkung des Events auf die abhängigen Ressourcen und damit auf den gesamten Zustand der Granularität (Knoten, Gruppe, Cluster...) überwacht. Das Ergebnis wird mit den erwarteten Werten verglichen. Schließlich erzeugt der Management Block eine neue Event-Nachricht, die eine Änderung des Gesamtzustands an die nächst höhere Management Block signalisiert. Gleichzeitig werden Kommando-Nachrichten erzeugt und an betroffene Delegates verschickt. Im zweiten Durchlauf wird eine neue Test-Event-Nachricht erzeugt, die zwar eine Zustandsänderung der kritischen Ressource enthält, jedoch keine Änderung des Gesamt-Zustands bewirkt. Damit soll die Event-Unterdrückung des Systems getestet werden. Die Ausführung der Testszenarien für die Policy-Engine ist in Kapitel 5.7 beschreiben. D5.2 Ergebnisse der Evaluierung v471 18/

19 4.2.2 Schnittstellen zu anderen Komponenten Durch die Anbindung der Policy-Engine an den Message-Bus sind Schnittstellen zu den anderen Komponenten durch ein- und ausgehende Nachrichten realisiert. In direktem Kontakt zur Policy-Engine stehen die Rule-Engine, Filter&Event-Generator, die Regressions- und Compliancetests sie erzeugen Event-Nachrichten die von der Policy-Engine weiterverarbeitet werden. Der Delegate (siehe Kapitel 4.3) konsumiert die von der Policy-Engine erzeugten Kommando-Nachrichten und ist für das Ausführen der Entscheidungen zuständig. Wie bereits in Kapitel erwähnt, kann das Zusammenwirken mit allen Komponenten durch Regeln in der Rule-Engine beschrieben werden, dadurch kann auch die komplette Interaktion mit allen Partnerkomponenten getestet werden. 4.3 Delegate Der Delegate ist die Schnittstelle zwischen Management-Block und den verwalteten Systemen bzw. Komponenten zur Verwaltung der Systeme. Aus diesem Grund müssen beide Seiten des Delegate, also die Kommunikation mit den übrigen Komponenten des Management-Blocks und die Kommunikation mit den verwalteten Systemen, getestet werden. Für den Delegate zum Management virtueller Maschinen existieren sowohl ein spezieller Test- Client, der den Management-Block simuliert, als auch ein Dummy des eigentlichen vmmanager. Auf diese Weise können beide Seiten individuell getestet werden. Der Test-Client kann die benötigten Nachrichten erzeugen, über die sämtliche Aktionen der Komponente zur Verwaltung virtueller Maschinen ausgelöst werden können. Der Dummy simuliert den echten vmmanager und ermöglicht ein sehr schnelles Testen des Zusammenspiels mit den übrigen Komponenten, da keine Verzögerung durch das tatsächliche Ausführen der Aktionen auftritt. Eine Untersuchung der Performance des Delegate ist aufgrund seiner Funktion als reiner Vermittler nicht notwendig Schnittstellen zu anderen Komponenten Ein Delegate ist an den Nachrichtenbus angeschlossen. Damit sind die Schnittstellen zu den anderen Komponenten durch ein- und ausgehende Nachrichten realisiert. In direktem Kontakt zum Delegate steht lediglich die Policy Engine. Ein Test des Delegate kann folglich dadurch erfolgen, dass die Policy Engine Nachrichten an den Delegate schickt, die zur Ausführung von Kommandos führen. Die Schnittstelle zur Policy Engine kann weiterhin mit dem Test-Client getestet werden Testszenarien Es bietet sich an, den Delegate zum Management virtueller Maschinen zusammen mit dem vmmanager zu testen. Ein möglicher Testablauf ist in Testszenario 6 beschrieben. D5.2 Ergebnisse der Evaluierung v471 19/

20 4.4 vmmanager Komponente zur dynamischen Partitionierung Der vmmanager ist für die dynamische Partitionierung des Systems zuständig. Er ist indirekt über den zugehörigen Delegate an das Gesamtsystem angebunden. Die Kommunikation zwischen Delegate und vmmanager erfolgt hierbei über XML-RPC. Für den vmmanager existiert ein Client, mit dem die komplette Funktionalität getestet werden kann. Der Client kommuniziert über die XML-RPC Schnittstelle direkt mit dem vmmanager. Dieser Client entspricht in seiner Verwendung dem Test-Client des Delegate, so dass ein Test relativ einfach möglich ist. Da die Geschwindigkeit des vmmanager zu großen Teilen vom eingesetzten System abhängig ist (gemeinsamer Speicher vs. lokaler Speicher, Netzwerkbandbreite), ist ein Geschwindigkeitstest des vmmanager schwierig, da die (leicht zu messende) Gesamtausführungszeit einer Aktion nicht eindeutig dem vmmanager bzw. dem verwendeten System zugeordnet werden kann. Weiterhin beträgt die Zeit, die zum Ausführen von vmmanager- Aktionen (z.b. Migration von virtuellen Maschinen) benötigt wird, in der Regel ein vielfaches von der Zeit, die intern zum Veranlassen der Aktion benötigt wird Schnittstellen zu anderen Komponenten Der vmmanager ist nicht an den Nachrichtenbus angeschlossen. Er besitzt eine XML-RPC Schnittstelle, über die die angebotenen Aktionen ausgelöst werden können. Die Anbindung an den Nachrichtenbus erfolgt über den zugehörigen Delegate. In direktem Kontakt zum vmmanager steht lediglich der Delegate. Ein Test des vmmanager sollte daher in Kombination mit dem zugehörigen Delegate erfolgen Testszenarien Es bietet sich an, den vmmanager zusammen mit dem Delegate zum Management virtueller Maschinen zu Testen. Ein möglicher Testablauf ist in Testszenario 6 beschrieben. 5 Integrationstests der Prototypkomponenten Ziel der Evaluierung des Gesamtsystems ist es die Übereinstimmung des TIMaCS Prototypen mit den in [D1.1] beschriebenen Use-Cases darzulegen. Hierzu wurden einige Testszenarien und Testfälle definiert, welche im folgenden Abschnitt zu finden sind. Die Tests wurden so ausgelegt, dass alle vorhandenen Komponenten und Schnittstellen in den Tests eingebunden sind. Da die unterschiedlichen Komponenten des Gesamtsystems von unterschiedlichen Projektpartnern entwickelt wurden, ist das besondere Augenmerk bei den Tests auf die richtige Bereitstellung der Daten an den jeweiligen Schnittstellen gerichtet. 5.1 Testszenario 1: Importer - Channel - Metrik Datenbanken Der erste unmittelbar zusammenhängende Datenfluss erstreckt sich von der Datenquelle (dem Sensor), welche vom entsprechenden Importer ausgelesen wird über die Erstellung eines D5.2 Ergebnisse der Evaluierung v471 20/