D2.1 Design der Monitoring, Regression und Compliance Tests Werkzeuge

Transkript

1 D2.1 Design der Monitoring, Regression und Compliance Tests Werkzeuge Arbeitspaket/Task: AP 2 Task 2.2 Fälligkeit: M12 Abgabetermin: Verantwortlich: Versionsnummer/Status: Autoren: ZIH Koudela, Daniela (DK) Mickler, Holger (HM) Focht, Erich (EF) Gordon, Minor (MG) 180 /Abgeschlossen ZIH ZIH NEC NEC Interne Gutachter: Volk, Eugen HLRS Vertraulichkeitsstatus Öffentlich Projektintern Sonstiges: X Version Datum Änderungen Autor Erste Gedanken DK Struktur soweit klar und einiger Text drin DK, HM Kapitel 3.2 Infrastruktur DK D2.1 Design der Monitor[...] Werkzeuge v180 1/

2 Infrastruktur DK, HM Regressionstests u. a. DK, HM Metriken, Schlüssel-Wert-Paare, Kommentare vom HLRS Kommunikationskanäle überarbeitet DK Kapitel 3 Grundlagen überarbeitet, noch einige TODOs drin, aber sollte aus inhaltlicher Sicht soweit passen. Einleitung Compliance-Tests-Kapitel soweit fertig. Einarbeitung von Kommentaren Schnittstellen in Kapitel 3 neu organisiert. HM Überarbeitung Kapitel 2 HM DK, HM DK, HM DK, HM Monitoring Framework Text, Kapitel 3. EF, MG Überarbeitung der Regressions- und Compliance-Tests Kleine Änderungen an Kapitel 3 EF Überarbeitung des Dokumentes DK HM, DK D2.1 Design der Monitor[...] Werkzeuge v180 2/

3 Inhaltsverzeichnis 1 Einleitung Grundlagen für Monitoring, Regressions- und Compliance-Tests Datenrepräsentation Metriken Schlüssel-Wert-Paare Infrastruktur Kommunikationskanäle Nachrichtenfluss Aufbau und Inhalt der Nachrichten Persistente Speicherung der Daten und deren Abfrage Schnittstellen Schnittstelle zum Monitoring Schnittstelle zum Batch-System Schnittstelle für Compliance-Tests Schnittstelle für Regressionstests Monitoring Publish / Subscribe Publisher Subscriber Broker API Publish/Subscribe und das Monitoring Framework Datenkollektoren Kommandos Verbraucher von Daten Implementation des Monitoring Frameworks Implementation von Datenkollektoren Kommandos Verbraucher von Monitoring-Daten Implementation der Broker Beispiel: Nachrichtenfluss im Monitoring Framework Design der Compliance-Tests Komponenten von Compliance-Tests Monitoring-Plugin Event-Generator Manager Design der Regressionstests Konfiguration von Regressionstests Ablauf eines Regressionstests Online-Regressionstest Offline-Regressionstest...20 D2.1 Design der Monitor[...] Werkzeuge v180 3/

4 5.3 Algorithmen für Regressionsanalysen Algorithmus lineare Regression Zusammenfassung/Fazit...23 D2.1 Design der Monitor[...] Werkzeuge v180 4/

5 1 Einleitung In diesem Dokument wird das Design für das Monitoring und für die Regressions- und Compliance-Tests erläutert. Dieses baut auf dem Konzept der Gesamtarchitektur, das in Dokument [D1.2] beschrieben ist, auf. Eine detaillierte Spezifikation der im Design vorgesehenen Schnittstellen und Datenformate wird im Dokument [TSD] TIMaCS Schnittstellen und Datenformate definiert. Kapitel 2 beschreibt die gemeinsamen Grundlagen von Monitoring, Regressions- und Compliance- Tests. Dabei geht es um die Darstellung der Daten, die Infrastruktur, zu der die Kommunikationskanäle gehören, auf denen die Daten zwischen den Computern ausgetauscht werden und um die Art und Weise, wie Daten persistent gespeichert werden können, so dass man sie bei Bedarf später abfragen kann. Auch die Schnittstellen werden in diesem Kapitel kurz skizziert. Kapitel 3 beschäftigt sich mit Monitoring. Hier wird vor allem dargestellt, wie die Daten von den Sensoren über ein Publish/Subscribe System an die Verbraucher der Daten weitergeleitet werden. In Kapitel 4 werden die Compliance-Tests beschrieben, indem auf die einzelnen Komponenten eingegangen wird, die man zur Durchführung eines Compliance-Tests braucht. Regressionstests sind das Thema von Kapitel 5. Hier wird deren Konfiguration und Ablauf geschildert. Des Weiteren wird eine Unterteilung in Online- und Offline-Regressionstests vorgenommen und die Unterschiede zwischen den beiden Arten erläutert. Anschließend werden die bereits implementierten Algorithmen zur Regressionsanalyse beschrieben. Kapitel 6 liefert eine kurze Zusammenfassung der wesentlichen Ergebnisse dieses Berichts. D2.1 Design der Monitor[...] Werkzeuge v180 5/

6 2 Grundlagen für Monitoring, Regressions- und Compliance- Tests In diesem Kapitel geht es um die Grundlagen, die Monitoring, Compliance- und Regressionstests gemeinsam haben. Dies sind zum einen die Metriken, die angefordert oder weiterverarbeitet werden, zum anderen ist es die Infrastruktur, die nötig ist, um Daten und Nachrichten im System auszutauschen und zu speichern. Ferner werden in diesem Kapitel auch die erforderlichen Schnittstellen kurz skizziert. 2.1 Datenrepräsentation Alle Daten, die vom Monitoring und von Regressions- und Compliance-Tests erzeugt werden, müssen in einer generischen Form in TIMaCS vorliegen, damit das System alle Informationen gleichermaßen für Entscheidungen, bspw. über auszuführende Aktionen, verwenden kann. Die Form der Daten wird in Metriken beschrieben und die verschiedenen generierten Daten werden in einem einheitlichen Format als Schlüssel-Wert-Paare in TIMaCS eingespeist Metriken Eine Metrik ist die Beschreibung einer Datenquelle, deren Werte mit TIMaCS aufgezeichnet werden. In einer Metrik wird definiert, von welchem Typ die gesammelten Daten sind und in welcher Einheit die Daten gespeichert werden. Jede Metrik hat einen eindeutigen Namen, unter dem die Daten zugeordnet werden. Die genaue Definition einer Metrik, wie sie in TIMaCS zum Einsatz kommt, ist im Dokument [TSD] beschrieben. Eine aggregierte Metrik ist eine Kombination verschiedener Messwerte. Um eine aggregierte Metrik zu erhalten, werden einzelne Messwerte analysiert und danach mit bestimmten anderen Messwerten (bzw. deren Resultat nach einer Analyse) so kombiniert, dass eine neue Metrik entsteht Schlüssel-Wert-Paare Auf Basis der definierten Metriken werden die von Plugins gesammelten Daten als Paket von Schlüssel-Wert-Paaren in TIMaCS weiterverarbeitet. Die in einem Paket zusammengefassten Schlüssel-Wert-Paare beschreiben genau einen Monitoring-Wert. Ein Paket muss immer den Zeitstempel der Messung, eine Kennung für den Knoten, die Metrik und die Datenquelle, sowie den eigentlichen Monitoring-Wert enthalten. Die Einbeziehung einer Kennung der Datenquelle erlaubt die Erfassung mehrerer gleichartiger Werte so kann zum Beispiel ein Sensor zur Messung der Prozessortemperatur alle Prozessoren eines Knotens mit derselben Metrik aufnehmen. Die von TIMaCS verwendeten Schlüsselbezeichnungen und der Aufbau eines Pakets bezüglich notwendiger Schlüssel-Wert-Paare sind im Dokument [TSD] spezifiziert. D2.1 Design der Monitor[...] Werkzeuge v180 6/

7 2.2 Infrastruktur Tools for Intelligent System Management of Die Infrastruktur von TIMaCS ermöglicht ein Austauschen von Daten, Nachrichten und Kommandos zwischen den einzelnen Komponenten von TIMaCS, sowohl innerhalb eines Knotens als auch zwischen verschiedenen Knoten, sowie deren Speicherung Kommunikationskanäle Kommunikationskanäle werden dazu gebraucht, um die Monitoring-Daten, sowie Sensorwerte für Regressions- und Compliance-Tests als auch deren Ergebnisse zu den Stellen weiterzuleiten, an denen sie gespeichert und/oder weiterverarbeitet werden. Dazu ist es häufig notwendig, die Informationen von einem Knoten zu einem oder mehreren Knoten der benachbarten Ebene in der TIMaCS- Hierarchie zu schicken. Dies geschieht mit einem Publish/Subscribe System, das auf dem Standard AMQP basiert Nachrichtenfluss Der Data-Collector sammelt die Monitoring-Daten. Dabei werden Pull-Sensoren abgefragt und Push-Sensoren liefern ihre Daten. Die Daten werden zum einen im Storage gespeichert und zum anderen an den Filter & Event Generator weitergeleitet. Der Filter & Event Generator analysiert die Daten und meldet Fehler in Form von Events. Diese werden an den Management-Block geschickt. Dort empfängt sie der Event/Data Handler, welcher empfangene Events und Reports zum einen zur Bildung von Statistiken zwischenspeichert und zum anderen untersucht. Stellt der Event/Data Handler einen Fehler fest, so wird die Decision-Komponente benachrichtigt und entscheidet, was zur Fehlerbehebung getan werden soll. Diese kann einerseits wiederum ein Event generieren, andererseits aber auch einen Befehl zur Reaktion auf den eingetretenen Fehlerfall. Im letzteren Fall wird zusätzlich ein Report generiert, damit die nächsthöhere Ebene, die üblicherweise mehr Informationen hat, weiß, was passiert ist und Entscheidungen gegebenenfalls korrigieren kann Aufbau und Inhalt der Nachrichten Der Aufbau und Inhalt der Nachrichten sind im Dokument [TSD] beschrieben Persistente Speicherung der Daten und deren Abfrage Da das Ergebnis von Performance-Messungen mit früheren Messwerten verglichen wird, ist es wichtig, aktuelle Monitoring-Daten, Events, sowie die Ergebnisse der Regressions- und Compliance-Tests für spätere Abfragen zu speichern. Als Speichermedium eignet sich eine Round-Robin Datenbank, die auf allen TIMaCS-Knoten installiert werden kann. Um die Größe der Datenbank in einem vernünftigen Rahmen zu halten, aber dennoch auf Monitoring-Werte, die schon weiter zurück liegen, zugreifen zu können, gibt es die Möglichkeit, für Daten, die ein bestimmtes Alter erreicht haben, nur Mittelwerte und/oder Maxima bzw. Minima zu speichern. Dabei ist das Alter, ab welchem nicht mehr alle Details gespeichert werden, konfigurierbar, damit TIMaCS sich an die unterschiedlichen Bedürfnisse verschiedener Rechenzentren anpassen lässt. D2.1 Design der Monitor[...] Werkzeuge v180 7/

8 Um eine gute Skalierbarkeit zu erhalten, speichert jeder TIMaCS-Knoten von Schicht 1 die Daten der Rechenknoten für die er zuständig ist in seiner Round-Robin Datenbank. Aus Gründen der Fehlertoleranz sollen die Daten jedoch redundant gespeichert werden. Dabei liegt das Hauptaugenmerk auf der Wiederherstellbarkeit der Daten, weniger auf der ständigen Verfügbarkeit, wobei eine einfache Redundanz als ausreichend erachtet wird. Damit die Daten auch bei einer kaputten Festplatte nicht verloren sind, werden die Daten zwischen den Knoten der ersten Schicht gespiegelt. Eine Möglichkeit wäre, dass jeweils zwei TIMaCS-Knoten sich gegenseitig spiegeln. Dies setzt jedoch eine gerade Anzahl TIMaCS-Knoten in der ersten Schicht voraus. Eine andere Möglichkeit, die nicht eine bestimmte Knotenanzahl voraussetzt, wäre, die Spiegelung in einer ringförmigen Anordnung vorzunehmen, d. h. Knoten n spiegelt seine Daten auf Knoten n+1 und Knoten n max spiegelt seine Daten auf Knoten 0. So könnte ein TIMaCS-Knoten die ankommenden AMQP-Nachrichten aus der Data Queue an den Knoten, der ihn spiegelt, weiterleiten. Da die Wahrscheinlichkeit, dass zwei Festplatten gleichzeitig ausfallen, zwar sehr gering, aber immer noch größer als Null ist, kann man TIMaCS auch so konfigurieren, dass die Daten auf mehrere Knoten gespiegelt werden. Dies erzeugt jedoch mehr Last im Netzwerk und der Speicherverbrauch auf den TIMaCS-Knoten der ersten Schicht steigt. Analoges gilt für die TIMaCS-Knoten der Schicht n. Diese speichern die aggregierten Daten der TI- MaCS-Knoten von Schicht n-1, für die sie zuständig sind und die des TIMaCS-Knotens der gleichen Schicht, den sie spiegeln. Sobald die Daten gespeichert sind, lassen sie sich durch den Administrator abrufen. Dieses Kommando wird vom TIMaCS-Administratorknoten nach unten an die Knoten der Schicht n geleitet. Dabei kann der Administrator durch einen Filter auswählen, welche Daten er sehen möchte. Bei der Menge der Daten, die TIMaCS speichert, ist dies empfehlenswert. So können einerseits die Ist-Werte (aktuellste Daten der Datenbank) abgefragt werden um z. B. genauere Informationen zu einem aktuellen Problem zu bekommen. Andererseits können auch historische Daten eines beliebigen Zeitintervalls der gespeicherten Daten abgefragt werden. Dies kann z. B. dann erforderlich sein, wenn ein Problem mehrfach aufgetreten ist und man untersuchen möchte, ob sich das Problem in den Monitoring-Daten vor seinem Auftreten bereits ankündigt. Im Filter lässt sich nicht nur das Zeitintervall, aus dem man die Daten sehen möchte, einstellen, sondern auch, ob man nur die Daten von bestimmten Knoten angezeigt haben möchte und welche Metriken angezeigt werden sollen. Neben der Abfragemöglichkeit Zeige mir die Daten der Knoten A, B, C,... im Zeitintervall von t 1 bis t 2 und zwar bin ich an den Metriken x, y,... interessiert. gibt es noch die Möglichkeit, sich alle Knoten eines Zeitintervalls anzeigen zu lassen, die ein bestimmtes Kriterium erfüllen. Ein Beispiel hierfür ist: Zeige mir alle Knoten an, die im Zeitintervall von t 1 bis t 2 mindestens 1 GB Swap belegt haben. 2.3 Schnittstellen TIMaCS definiert eine Reihe von Schnittstellen, die beispielsweise dazu dienen, (Mess-)Daten aus unterschiedlichen Quellen in einheitlicher Form in TIMaCS weiterverarbeiten und Management- Funktionalitäten verschiedener Systeme zur Steuerung benutzen zu können. Für dieses Dokument sind insbesondere die Schnittstelle für Compliance-Tests, die Schnittstelle für Regressionstests und die Schnittstelle für das Monitoring-System von Interesse, wobei die Schnittstelle für das Monito- D2.1 Design der Monitor[...] Werkzeuge v180 8/

9 ring-system auch eine Schnittstelle zum Batch-System beinhaltet. Für diese Schnittstellen können Erweiterungen sogenannte Plugins geschrieben werden, um die Funktionalität von TIMaCS an die unterschiedlichen Bedürfnisse der einzelnen Rechenzentren anzupassen. Im Folgenden werden diese Schnittstellen skizziert. Die vollständigen Definitionen aller von TI- MaCS angebotenen Schnittstellen werden in [TSD] fortlaufend aktualisiert Schnittstelle zum Monitoring Die Schnittstelle zum Monitoring dient dazu, neue Sensoren und Monitoring Systeme als Plugins einzubinden. Diese Schnittstelle wird durch die Art und Weise definiert, wie Daten in das Publish/Subscribe-System eingelesen werden Schnittstelle zum Batch-System Die Schnittstelle zum Batch-System erfüllt zwei Funktionen. Sie erlaubt nicht nur das Monitoring des Batch-Systems, sondern durch sie ist es auch möglich, Einstellungen am Batch-System zu ändern (z. B. Knoten aus dem Batch-Betrieb entfernen oder eine Queue zu starten). Da letzteres eine Aufgabe des Managements ist, soll an dieser Stelle nur auf das Monitoring des Batch-Systems eingegangen werden. Will man Informationen, wie Anzahl der Jobs pro Queue, welche Jobs laufen auf welchem Knoten oder akzeptieren die Queues Jobs und werden diese auf die Knoten verteilt auch als regelmäßig aktualisierte Monitoring-Werte beobachten/aufzeichnen, so muss TIMaCS in der Lage sein, mit dem verwendeten Batch-System zu kommunizieren. Dazu wird das Batch-System über eine Schnittstelle eingebunden. Dies ermöglicht, je nach verwendetem Batch-System unterschiedliche Plugins zu laden und für noch nicht unterstützte Batch-Systeme eigene Erweiterungen zu schreiben. Der Vorteil einer solchen Schnittstelle ist, dass sie die Programmierung von Monitoring-Plugins erlaubt, die nur gegen diese Schnittstelle programmiert werden müssen. Dadurch sinkt der Aufwand bei der Integration neuer Batch-Systeme, da nur die Schnittstelle zu diesem Batch-System programmiert werden muss und nicht zusätzlich noch eine Reihe von Monitoring-Plugins. Da die unterschiedlichen Batch-Systeme hinsichtlich ihres Funktionsumfangs differieren, muss die Schnittstelle so gestaltet sein, dass es eine Abfragemöglichkeit gibt, welche Funktionen das gewählte Batch-System zur Verfügung stellt. Dies hat den Vorteil, dass man in der Auswahl des Batch-Systems nicht eingeschränkt ist und auch spezielle Funktionen einzelner Batch-Systeme genutzt werden können, um einen Mehrwert bezüglich der Verwaltung mittels TIMaCS zu realisieren Schnittstelle für Compliance-Tests Der Compliance-Test nutzt die Schnittstelle zu den Monitoring-Plugins. Diese Schnittstelle muss jedoch die Möglichkeit bieten, Monitoring-Werte auch zwischenzeitlich abfragen zu können, damit sie für Compliance-Tests verwendbar ist. Des Weiteren ermöglicht die Schnittstelle für Compliance- Tests auch das Erstellen von Sensoren, die nur auf Anfrage ausgelesen werden. D2.1 Design der Monitor[...] Werkzeuge v180 9/

10 2.3.3 Schnittstelle für Regressionstests Tools for Intelligent System Management of Aufgrund seines Designs besitzt ein Regressionstest mehrere Schnittstellen. Schnittstelle zum Publish/Subscribe System: Ein Online-Regressionstest (siehe Kap ) ist ein Verbraucher von Monitoring-Daten und nutzt somit die selbe Schnittstelle zum Publish/Subscribe System wie auch die anderen Verbraucher (siehe Kap. 3.1). Schnittstelle zur Datenbank: Ein Offline-Regressionstest (siehe Kap ) holt sich seine Daten aus der Datenbank und nutzt somit die Schnittstelle zur Datenbank. Die Schnittstelle zur Regressionsanalyse ist als offene Schnittstelle gestaltet, um Nutzern/Entwicklern die Möglichkeit zu geben, weitere Algorithmen für Regressionsanalysen zu implementieren. An dieser Stelle wird ein Datenarray mit Zeitstempel-Wert-Paaren übergeben. Für das Ergebnis eines Regressionstests wird die selbe Schnittstelle verwendet wie für die Weiterverarbeitung von klassischen Monitoring-Werten. D2.1 Design der Monitor[...] Werkzeuge v180 10/

11 3 Monitoring In diesem Kapitel wird auf Basis von [D1.2] das Design des Monitoring Frameworks zusammen mit der zur Kommunikation verwendeten Publish/Subscribe Architektur beschrieben. Im ersten Abschnitt beschreiben und motivieren wir die Nutzung der Publish/Subscribe Architektur und deren Grundkomponenten. Der darauf folgende Abschnitt 3.2 erklärt wie die einzelnen Komponenten des Monitoring Frameworks auf die Publish/Subscribe Architektur abgebildet werden. Abschnitt 3.3 beschreibt die konkrete Implementation des Monitoring Prototyps in Python. Der letzte Abschnitt widmet sich dem Nachrichtenfluss durch das Framework am Beispiel des Prototyps. 3.1 Publish / Subscribe Das Monitoring Framework benutzt ein Topic-basiertes Publish/Subscribe System [EPT03a] zum Datentransport. In solchen Systemen senden Publisher Nachrichten (Events) an Broker über durch URIs eindeutig identifizierbare Datenkanäle (Named Channels, Topics). Die URIs der Datenkanäle werden von Subscribern benutzt, um bei Brokern nur Nachrichten bestimmter Topics zu abonnieren. Broker leiten Nachrichten an andere Broker weiter, die interessierte (abonnierte) Subscriber haben. Die Stärke von Publish/Subscribe Systemen ist die zeitliche und räumliche Entkopplung von Datenerzeugern und Datenverbrauchern, die strikt asynchron kommunizieren, was Skalierbarkeit und Fehlertoleranz zur Folge hat. Die folgenden Abschnitte erläutern die Funktionen der einzelnen Komponenten Publisher Publisher sind die aktiven Quellen aller im System transportierter Daten. Beim Versenden einer Nachricht an einen Broker erwartet und bekommt der Publisher keine unmittelbare Rückmeldung über den Erfolg der Zustellung oder Weiterleitung der Nachricht an Subscriber. Aus diesem Grund muss der Publisher weder dauerhaft mit dem Broker in Verbindung stehen noch permanent laufen, und kann somit ein separates externes Programm sein, das einfach periodisch oder aperiodisch aufgerufen wird. Die inherente Asynchronie des Publish/Subscribe Programmiermodells hat zur Folge, dass man damit keine synchronen RPCs (Remote Procedure Calls) im üblichen Sinne implementieren kann. Pull Mechanismen sind in einem solchen System ebenfalls nicht direkt programmierbar, da diese, wie RPCs, auf synchronem Austauschen von Anfragen und Antworten basieren. Im Publish/Subscribe Modell muss man stattdessen die Kopplung von Anfrage und dazugehöriger Antwort asynchron emulieren, zum Beispiel durch das Abonnieren eines temporären Rückkanals oder durch implizite Antworten, bei denen der Anfragende die Antwort aus der Änderung im normalen Nachrichtenstrom des Angefragten erkennt. Diese Nachteile in der synchronen Programmierung kompensiert das Publish/Subscribe Modell durch viele Vorteile wie: eine mögliche Garantie von Nachrichtenauslieferung (und damit Fehlertoleranz), Pufferung von Nachrichten an Brokern, die temporäre Netzwerkausfälle kompensiert, etc. D2.1 Design der Monitor[...] Werkzeuge v180 11/

12 3.1.2 Subscriber Tools for Intelligent System Management of Subscriber sind die passiven Senken für die Nachrichten und Daten die im Publish/Subscribe System ausgetauscht werden. Sie empfangen Nachrichten auf einem oder mehreren Kanälen von genau einem Broker Broker Broker nehmen Nachrichten auf bestimmten Kanälen von Publishern in Empfang und liefern diese an Subscriber aus, die die entsprechenden Kanäle abonniert haben. Systeme können um einen einzigen zentralen Broker aufgebaut werden, oder um ein logisches Netzwerk von miteinander gekoppelten Brokern, die ein Overlay-Network bilden [PB03]. Die Topologie des Overlay-Networks wird bestimmt durch die abonnierten Kanäle, da nur diese Nachrichten transportieren. Sie sollte der physikalischen Topologie und Hierarchie des Clusters nah kommen API Broker präsentieren eine sehr simple API: publish(event) : für Publisher, subscribe(topic) : für Subscriber, wie in [PEKS07] beschrieben. Die Auslieferung der Nachrichten an die Subscriber kann via push erfolgen, durch den Aufruf einer notify(event) Methode auf dem Subscriber durch einen RPC-artigen Mechanismus, oder durch pull von Subscriber Seite, was etwa einem synchronen poll_events() RPC Aufruf der Subscriber auf dem Broker entspricht. Diese einfache API kann in verschiedenen Arten erweitert und optimiert werden, so könnten zum Beispiel Publisher ihre Absicht, auf bestimmten Kanälen Nachrichten zu verschicken, ankündigen, was sowohl das Broker-Routing als auch die Abonnements der Subscriber beeinflussen könnte. 3.2 Publish/Subscribe und das Monitoring Framework Datenkollektoren Datenkollektoren sind die wichtigsten Publisher im Monitoring Framework. Sie sammeln Daten von spezifischen Quellen (zum Beispiel: Temperatursensoren oder Load des Knotens oder des Batch Systems). Dies kann sowohl aktiv geschehen, durch Abfrage der Datenquellen, oder passiv durch Empfang von Benachrichtigungen einer Datenquelle (zum Beispiel über SMTP). Die Daten werden anschließend an den Broker als Nachricht über einen vereinbarten Kanal geschickt. Datenkollektoren können autonome Agenten sein, die kontinuierlich Daten sammeln und publizieren, oder könnten von einem externen Programm getriggert werden (bspw. mittels cron Jobs). Sie können jedoch nicht direkt Daten durch pull an einen Interessenten liefern. D2.1 Design der Monitor[...] Werkzeuge v180 12/

13 3.2.2 Kommandos Tools for Intelligent System Management of Externe Prozesse sollen auszuführende Befehle ins Monitoring System publizieren können, die asynchron ausgeführt werden. Diese sollten zum Beispiel die Konfiguration der Datenkollektoren ändern können, zum Beispiel die Zeitintervalle der Datensammlung ändern. Ebenso könnten von Subscribern Kommandos angenommen werden, die auf dem Knoten als UNIX Befehle auszuführen wären, es ist vorstellbar, dass so eine Komponente die Publish/Subscribe Infrastruktur des Monitoring Systems nutzt, aber streng genommen gehört die Ausführung von UNIX Kommandos zu Administrationszwecken nicht zum Monitoring System. In jedem Fall muss die Ausführung von Kommandos der asynchronen Natur des Publish/Subscribe Systems angepasst werden Verbraucher von Daten Im Monitoring Framework sind Subscriber die Verbraucher der Nachrichten, die Broker zur Verfügung stellen. Diese sind zum Beispiel: round-robin Datenbanken für historische Daten, User-Interfaces die Monitoring-Daten in Echtzeit darstellen, Aggregator-Prozesse die Monitoring-Daten kontinuierlich beobachten und daraus neue Daten generieren, die wiederum im Monitoring Framework publiziert werden. Publisher können gleichzeitig auch Subscriber sein, so wie Datenkollektoren, die Monitoring Metriken publizieren, aber auch Subscriber auf einem Kommando Kanal sind, oder Aggregatoren, die Subscriber sind für bestimmte Monitoring-Daten, aber selbst auch neue Monitoring-Daten erzeugen und an Broker senden. Broker sind im Monitoring Framework hingegen unabhängige Prozesse die immer vorhanden sein müssen, in etwa so wie Router in einem Netzwerk. Komponenten im Monitoring Framework können zusätzlich zum asynchronen Interface des gesamten Publish/Subscribe Systems ein synchrones Interface implementieren, zum Beispiel kann die round-robin Datenbank ein synchrones Interface zur Datenabfrage implementieren, dieses sollte allerdings strikt für Punkt-zu-Punkt Client-Server Anwendungen gelten, und nicht mit der Asynchronie des Monitoring Frameworks interferieren. 3.3 Implementation des Monitoring Frameworks Der aktuelle Prototyp des Monitoring Frameworks ist in der Programmiersprache Python implementiert [ Der Hauptvorteil der Sprache ist, dass sie schnelles Prototyping und die Implementation experimentellen Codes einfach macht. Python erlaubt das dynamische Laden und neu Laden von Programmmodulen zur Laufzeit, besitzt eine umfangreiche Standardbibliothek und wird gepflegt und entwickelt von einer großen Community von Entwicklern Implementation von Datenkollektoren Datenkollektoren für verschiedene Quellen sind implementiert als Python Module, die als Plugins dynamisch zur Laufzeit geladen werden. Damit das Plugin mit TIMaCS zusammen funktioniert, ist genau ein Interface das zum Message Channel wichtig. Datenkollektoren können nur aus einem Sensor bestehen oder einen Zugang zu einem Dienst darstellen, der wiederum tausende Sensoren hat. Mehrere Kollektoren können in einem Prozess laufen und periodisch zeitgesteuert aktiviert werden um Daten zu sammeln und zu publizieren. Die Zielkanäle für die Nachrichten eines Daten- D2.1 Design der Monitor[...] Werkzeuge v180 13/

14 kollektors werden in einer Konfigurationsdatei angegeben. Datenkollektoren können Kommando- Kanäle abonnieren um Konfigurationsbefehle zu empfangen Kommandos Kommandos können als Teil einer GUI oder als Command Line Tools implementiert werden. In der Regel werden sie eine Nachricht publizieren und eventuell auf die Auswirkung dieser Nachricht warten (siehe Diskussion über die Emulation synchroner Kommandos) Verbraucher von Monitoring-Daten Wie die Datenkollektoren werden Datenverbraucher auch als Module/Plugins implementiert, die aus ihrer Konfigurationsdatei die zu abonnierenden Kanäle herauslesen. So konfiguriert sich die in Python implementierte round-robin Datenbank als Subscriber zu bestimmten Monitoring-Daten, empfängt die entsprechenden Nachrichten und speichert sie im Dateisystem. Weitere Verbraucher von Monitoring-Nachrichten sind: Aggregatoren die bestimmte Monitoring-Nachrichten abonnieren und daraus neue Metriken als neue Nachrichten erzeugen. Aggregatoren sind somit Subscriber auf einen bestimmten Teil des Namensraumes der Metrik-Kanäle, und Publisher für die aggregierten Metriken. Filter und Event-Generatoren sind ein Sonderfall der Aggregatoren. Wie Aggregatoren abonnieren sie einen oder mehrere Metrik-Kanäle und verfolgen deren Datenstrom, bloß die neu erzeugten Metriken sind speziell und werden als seltene Ereignisse interpretiert, auf die das automatische Management Framework reagieren muss. Technisch gibt es keine Unterscheidung zwischen Monitoring-Metriken oder Ereignissen, beide können dieselben Publish/Subscribe Mechanismen nutzen Implementation der Broker Es gibt eine Vielzahl von Implementationen des Publish/Subscribe Konzepts. Die von uns zur Zeit favorisierte Variante ist AMQP (Advanced Message Queueing Protocol) [ die Publishern und Subscribern, die auf verschiedenen Rechnern laufen erlaubt, zu kommunizieren. AMQP implementiert die publish(), subscribe() und notify() Operationen und transportiert Nachrichten als binäre Blobs, ist also agnostisch bezüglich deren Inhalt und Format. In dem aktuellen Prototyp werden Python Objekte mit Hilfe von JSON [ als Nachrichten serialisiert. Als Optimierung können Publisher und Subscriber, die im selben Prozess laufen (also in der selben Python Instanz geladen sind), Nachrichten über einen prozessinternen Broker austauschen, der nur Zeiger auf die Nachrichten zwischen Publisher und Subscriber austauscht. Die prozessweise Entkopplung der Publisher und Subscriber ist im Konzept immer noch vorgesehen, und wird später vorgenommen. Das konkrete on-wire Format der Nachrichten ist leicht austauschbar und ebenfalls optimierbar, einerseits bezüglich Kompatibilität, andererseits bezüglich Performance. Die AMQP-Broker-Architektur [AMQP-0.10] zeigt die notwendige Skalierbarkeit, wie von Marsh et. al in [MSPP09] analysiert und beschrieben, und bringt die notwendige Zuverlässigkeit und Feh- D2.1 Design der Monitor[...] Werkzeuge v180 14/

15 lertoleranz. Diese Schlüssel-Eigenschaften (Skalierbarkeit, Zuverlässigkeit und Fehlertoleranz) der AMQP-Architektur stellen sicher, dass die Monitoring Komponente die angestrebte Skalierbarkeit, Robustheit und Hochverfügbarkeit erreicht. Die Topologie baut sich im Overlay Netzwerk automatisch auf und zwar durch die Abonnenten und die named channels. Dadurch fließen Nachrichten nur dorthin, wo sie gebraucht werden. Eine natürliche Wahl der Hierarchie in einem solchen Setup wäre die Abbildung der physikalischen Topologie: normale Rechenknoten haben Datenkollektoren und einen AMQP-Broker, Daten-Verbraucher auf Administrationsknoten, die zum Beispiel in jedem Rack vorhanden sein könnten, abonnieren Nachrichten der Rechenknoten des eigenen Racks und bekommen von diesen Nachrichten zugesandt. Aus Redundanzgründen könnte ein benachbarter Administrationsknoten dieselben Kanäle abonnieren. Administrationsknoten auf höherer Ebene abonnieren bloß Nachrichten der Rack-Administrationsknoten. 3.4 Beispiel: Nachrichtenfluss im Monitoring Framework In diesem Abschnitt beschreiben wir ein System, in dem Daten von einem Ganglia Monitoring System [ gesammelt werden, über einen vereinbarten Kanal ins Monitoring Framework publiziert werden, ihr zeitlicher Verlauf in einer Datenbank gespeichert wird, und später über ein Kommandozeilen-Tool abgefragt werden kann. Das System besteht aus folgenden Komponenten: Ein Ganglia Datenkollektor, der periodisch Ganglia's gmetad Dämon pollt (eine zusätzliche aperiodische Abfrage wäre auch denkbar) und neue Metrik-Werte aus den XML Daten herausliest und über publish() diese Metriken in Form von JSON-serialisierten Objekten an einen AMQP Broker über einen TCP Socket schickt. Ein AMQP Broker, der Nachrichten empfängt und diese an die Datenbank-Komponente sendet. Eine Datenbank, die den zeitlichen Verlauf der Metrikdaten speichert, eine notify(event) Operation dem dazugelinkten AMQP Brokercode bietet, und Nachrichten, die über diese Operation ankommen, verarbeitet, indem sie sie in eine Datei speichert. Ein Kommandozeilen Tool, das synchron die Datenbank nach dem zeitlichen Verlauf von Metriken in bestimmten Zeitintervallen abfragen kann, in etwa ähnlich rrdtool [ Die Nutzung des Publish/Subscribe Systems erlaubt eine einfache und bequeme Entkopplung der einzelnen Komponenten, wobei alle Nachrichten durch den AMQP Broker geleitet werden. Dies erlaubt getrennte Entwicklung, Separierung der Komponenten im Fehlerfall und eine simple Art Datenredundanz zu implementieren: durch das Hinzufügen einer zusätzlichen Datenbank als Subscriber. D2.1 Design der Monitor[...] Werkzeuge v180 15/

16 4 Design der Compliance-Tests Monitoring läuft autonom nach dem Bottom-up-Prinzip ab, d. h. die Sensoren der Monitoring-Plugins liefern periodisch Messwerte (push) oder werden periodisch abgefragt (pull). Diese Messwerte werden dann an einen Broker übermittelt (publish). Der Event-Generator bekommt als Subscriber jeden Messwert, prüft ihn zum Beispiel hinsichtlich Überschreitung eines Schwellwerts und generiert im Falle eines Überschreitens ein oder mehrere Events. Im Gegensatz dazu sind Compliance-Tests Top-down-Prozesse, die jedes Mal explizit aus der Management-Ebene gestartet werden. Ein Compliance-Test ermittelt zu einem willkürlichen Zeitpunkt den aktuellen Zustand (eines Teils) des Systems, damit in Abhängigkeit des Ergebnisses eine oder mehrere Aktionen ausgelöst werden können. Die Daten, die von Compliance-Tests zur Auswertung angefordert werden, lassen sich wie Monitoring-Daten als Metriken beschreiben und die Gewinnung der Daten ist auf ähnliche Weise möglich, daher wird die Infrastruktur des Monitorings als Basis für Compliance-Tests genutzt. 4.1 Komponenten von Compliance-Tests An der Durchführung eines Compliance-Tests sind mehrere Komponenten beteiligt, deren Aufgaben und Zusammenspiel nachfolgend erklärt werden Monitoring-Plugin Die Sensoren des Monitorings liefern die Messdaten, die von einem Compliance-Test ausgewertet werden. Klassisches Monitoring erfasst für gewöhnlich nur in einem festgelegten Intervall die Werte der Sensoren, was für die Top-down-Arbeitsweise von Compliance-Tests jedoch unter Umständen unzureichend ist nämlich dann, wenn das Monitoring-Intervall relativ groß ist, denn ein Compliance-Test soll den aktuellen Status des Systems bewerten. Daher enthält die Schnittstelle zu Monitoring-Plugins in TIMaCS die Möglichkeit, Sensorwerte zwischenzeitlich abfragen zu können. Dies ist nicht gleichzusetzen mit einer Pull-Abfrage von Sensordaten, vielmehr wird dem Monitoring-Plugin mittels eines Kommandos mitgeteilt, dass der aktuelle Wert eines bestimmten Sensors ausgegeben werden soll. Dieser Wert wird dann auf dem gewöhnlichen Weg über das Messaging- System verteilt. Zusammen mit der Anfrage nach dem aktuellen Sensorwert wird ein Time-out festgelegt, das angibt, wie lange der Empfänger bereit ist, auf den Wert zu warten. Das asynchrone Vorgehen in Verbindung mit einem Time-out bietet zwei Vorteile: 1. Es können auch Push-Sensoren für Compliance-Tests verwendet werden, wenn das Monitoring-Intervall klein genug ist und das Monitoring-Plugin die aktuellen Werte der Sensoren zwischenspeichert. Abhängig davon, wann der letzte Messwert des jeweiligen Sensors eingetroffen ist, kann entweder der gespeicherte Wert für den Compliance-Test ausgegeben werden oder das Monitoring-Plugin wartet auf den nächsten Messwert, wenn er voraussichtlich innerhalb des Time-outs kommen wird. 2. Im Fall von Pull-Sensoren kann das Monitoring-Plugin entscheiden, ob es eine zusätzliche Abfrage des Sensors außerhalb des festgelegten Intervalls durchführt (was zusätzlichen Overhead durch das Monitoring bedeutet) oder bis zum nächsten regulären Abfragezeitpunkt wartet, sofern dieser innerhalb des Time-outs liegt. D2.1 Design der Monitor[...] Werkzeuge v180 16/

17 Der erste Punkt hat eine Einschränkung der Auswahl von Sensoren für Compliance-Tests zur Folge es können nur jene verwendet werden, deren Monitoring-Intervall kleiner als das Doppelte des Time-outs ist. Unter Umständen ist diese Einschränkung zu restriktiv und unnötig, wenn auch ein älterer Sensorwert für den Compliance-Test genügt. Diese Information kann bei dem Kommando an das Monitoring-Plugin mitgegeben werden, so dass der Sensorwert von der letzten Messung für den Compliance-Test ausgegeben wird. Die Schnittstelle ermöglicht auch das Erstellen von Sensoren, die nur auf Anfrage ausgelesen werden und zur Generierung ihrer Messwerte ressourcenintensive Prozesse starten, zum Beispiel einen Benchmark. Die vom oben erwähnten Kommando angeforderten Messwerte werden auf dem gewöhnlichen Weg in TIMaCS eingespeist, das heißt sie werden genau wie alle anderen Monitoring-Daten über die Data Queue verteilt, worüber sie an alle Subscriber verteilt werden Event-Generator Die zweite Komponente, die bei einem Compliance-Test beteiligt ist, ist ein Event-Generator. Dieser ist Teil des Filter & Event Generators. Der Filter & Event Generator gliedert sich in mehrere Teile. Diejenigen Teile, die für die Filterung und das Generieren von Events der Daten des klassischen Monitorings zuständig sind, sind immer aktiv, filtern die eintreffenden Monitoring-Werte, und generieren bei speziellen Anlässen, wie z. B. im Fehlerfall, Events. Dies ist für Compliance-Tests nicht ausreichend, da hier immer die Information über den Monitoring-Wert weitergeleitet werden muss, weil vom Ergebnis des Compliance-Tests weitere Aktionen abhängen. Deswegen werden für die Durchführung eines Compliance-Tests Teile des Event-Generators aktiviert, die jeweils nur auf das Eintreffen eines Monitoring-Wertes warten, d. h. jeder dieser Teile abonniert eine Metrik, die durch den Compliance-Test ausgewertet wird. Sobald der Wert dieser Metrik da ist, wird ein Event generiert bzw. wenn nach Ablauf des Time-outs kein Messwert eingetroffen ist, wird auch ein Event generiert. Danach schalten sie sich wieder ab und werden erst bei der Durchführung des nächsten Compliance-Tests auf diesen Metriken wieder mittels eines Kommandos aktiviert, so dass nicht zu jedem vom Monitoring erfassten Messwert dieser Metriken weiter Events generiert werden. Der Inhalt der Events, die bei der Durchführung von Compliance-Tests generiert werden, ist eine boolesche Interpretation des Messwertes und enthält nach Bedarf noch weitere Details. Kam innerhalb des Time-outs kein Messwert an, so enthält das Event die Nachricht, dass kein Messwert eingetroffen ist. An der Durchführung von Compliance-Tests können Event-Generatoren mehrerer TIMaCS-Knoten beteiligt sein. Dies ist dann der Fall, wenn die Monitoring-Werte von unterschiedlichen Rechenknoten sind, die nicht alle von demselben TIMaCS-Knoten verwaltet werden Manager Die dritte Komponente eines Compliance-Tests befindet sich im Management-Block und ist für die Steuerung verantwortlich. Hier wird der Compliance-Test manuell oder durch einen Aktionsplan gestartet, indem die Kommandos zur Aktivierung der Event-Generatoren und die Befehle zur Abfrage D2.1 Design der Monitor[...] Werkzeuge v180 17/

18 der für diesen Compliance-Test ausgewählten Monitoring-Sensoren über die Command-Queue verteilt werden. Danach wird gewartet, bis entweder alle erwarteten Events eingetroffen sind oder das Time-out erreicht wurde. Wenn das Time-out erreicht wurde, wird ein Event zu dem Fehler generiert, das von TIMaCS weiter behandelt werden kann. Im anderen Fall werden die generierten Events ausgewertet und zu einem Gesamtergebnis des Compliance-Tests kombiniert. Dieses Ergebnis wird wiederum als Event verbreitet, um davon abhängige Prozesse starten zu können. D2.1 Design der Monitor[...] Werkzeuge v180 18/

19 5 Design der Regressionstests Ein Regressionstest analysiert den Verlauf der Messwerte einer Metrik, um Indikatoren für abnormes Verhalten zu finden. 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 und wird in Form einer Metrik in TIMaCS publiziert, so dass die im TIMaCS-Framework vorhandenen Methoden zur Auswertung und Fehlererkennung diese Werte einbeziehen können. 5.1 Konfiguration von Regressionstests Das Verhalten eines Regressionstests, welcher von TIMaCS durchgeführt werden soll, ist durch seine Konfiguration festgelegt, die folgende Eigenschaften beinhaltet: Wahl einer Regressionsanalyse für die Berechnung Anzahl (N) der Messwerte, auf denen die Regressionsanalyse arbeiten soll Zeitintervall (T) als Limit für die Neuberechnung bei Online-Regressionstests Wahl der Metrik für Eingabedaten Definition der Ausgabemetrik Wahl der Schranke, ab wann abnormes Verhalten vorliegt 5.2 Ablauf eines Regressionstests Es gibt zwei unterschiedliche Varianten, wie Regressionstests ausgelöst werden. Online-Regressionstests berechnen ihr neues Ergebnis beim Eintreffen eines neuen Wertes der zugeordneten Metrik. Offline-Regressionstests werden manuell durch den Administrator oder anhand eines Aktionsplans von TIMaCS gestartet Online-Regressionstest 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 TI- MaCS, 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. D2.1 Design der Monitor[...] Werkzeuge v180 19/

20 5.2.2 Offline-Regressionstest Tools for Intelligent System Management of Ein Offline-Regressionstest berechnet die Regressionswerte über der gewählten Metrik für einen bestimmten Zeitraum, der beim Aufruf des Tests angegeben wird. Um dem Administrator jedoch ein funktionales Werkzeug zur Performance-Analyse zur Verfügung zu stellen, reicht die alleinige Angabe eines Zeitintervalls nicht aus. So ist zum Beispiel der Fall denkbar, dass der Performance-Verlust einer Komponente sehr langsam vonstatten geht, so dass Performance-Verluste nur entdeckt werden können, wenn sich der Regressionstest über einen längeren Zeitraum - z. B. mehrere Monate erstreckt. Wurden von dieser Komponente in diesem Zeitraum regelmäßig Monitoring-Daten aufgezeichnet, so sind die vorhandenen Daten zu zahlreich, als dass der Regressionstest seine Analyse in angemessener Zeit durchführen könnte. Deswegen sind hier in Abweichung zu Kap. 5.1 folgende Angaben zu machen: Wahl einer Regressionsanalyse für die Berechnung. Angabe von zwei Zeitpunkten t 0 und t 1 innerhalb derer die Messwerte liegen, die für den Regressionstest herangezogen werden sollen. Angabe eines Zeitpunktes t 2 mit t 0 t 2 t 1. t 2 gibt hierbei an, dass alle Daten zwischen t 0 und t 2 gemittelt werden und im Bereich t 2 bis t 1 werden alle Daten ohne Mittelwertbildung verwendet. Ist t 2 = t 0 wird keine Mittelwertbildung durchgeführt und bei t 2 = t 1 werden nur gemittelte Daten für die Regressionsanalyse verwendet. Zeitintervall Δt. Dies gibt das Zeitintervall für die Mittelwertbildung an. Idealerweise ist t 2 - t 0 ein Vielfaches von Δt. Wahl der Metrik für Eingabedaten. Definition der Ausgabemetrik. Hier ist es sinnvoll eine neue Metrik zu definieren, damit nicht versehentlich Daten der Online-Regressionstests, die möglicherweise einen identischen Zeitstempel haben, überschrieben werden. Es ist zu prüfen, wie lange es dauert, Daten aus der Datenbank auszulesen. Sollte dies sehr viel Zeit und Ressourcen brauchen, so könnte es durch aus sinnvoll sein, ein weiteres Zeitintervall zu definieren. Aus diesem Zeitintervall würden dann alle Daten der betreffenden Metrik in den Hauptspeicher kopiert werden, damit der Administrator auf verschiedenen Untermengen dieser Daten Regressionstests ausführen kann und so die Stabilität des Ergebnisses des Regressionstests bzgl. Veränderung der Parameter überprüfen kann. Will man mehrere Regressionstests hintereinander weg auf sich überschneidenden Datenmengen machen, so kann es durchaus schneller sein, erst alle Daten in den Hauptspeicher einzulesen anstatt jedes mal die Datenbank abzufragen. Aufgrund seines Designs ist die Definition des Zeitstempels eines Offline-Regressionstests nicht offensichtlich. Einerseits wird er in der Gegenwart durchgeführt, andererseits kann er sich über Werte erstrecken, die ausschließlich in der Vergangenheit gemessen wurden. Da der Zeitstempel bei Online-Regressionstests gleich dem Zeitstempel des jüngsten Eingabewertes ist, wird auch bei Offline-Regressionstests der Zeitstempel des jüngsten Eingabewertes als Zeitstempel des Ergebnisses genommen, auch wenn dieser bereits weit in der Vergangenheit liegt. D2.1 Design der Monitor[...] Werkzeuge v180 20/