D1.3 TIMaCS Gesamtarchitektur V2

Transkript

1 D1.3 TIMaCS Gesamtarchitektur V2 Arbeitspaket/Task: Fälligkeit: AP1/T1.2 M25 Abgabetermin: Verantwortlich: Versionsnummer/Status: Autoren: Interne Gutachter: HLRS Volk, Eugen Koudela, Daniela Lohrer, Marc Schwitalla, Jürgen Roland Schwarzkopf Matthias Schmidt Niels Fallenbeck Andreas Jeutter Erich Focht Koudela, Daniela Götz Isenmann / Abgeschlossen HLRS ZIH S+C S+C UMA UMA UMA NEC NEC ZIH S+C Vertraulichkeitsstatus Öffentlich Projektintern Sonstiges: X D1.3 TIMaCS Gesamtarchitektur V2 r342 1/

2 Version Datum Änderungen Autor Initialer Entwurf, basierend auf D1.2 Eugen Volk (HLRS) Einarbeitung der Partnerbeiträge Daniela Koudela (ZIH), Marc Lohrer(s+c), Jürgen Schwitalla (s+c) Einarbeitung der Partnerbeiträge Roland Schwarzkopf (UMA) Matthias Schmidt (UMA) Niels Fallenbeck (UMA) Ergänzung und Aktualisierung Eugen Volk Aktualisierung des Dokuments mit Partnerbeiträgen Alle Autoren Erstes Review Daniela Koudela (ZIH) Einarbeitung der Review-Kommentare Eugen Volk (HLRS) Zweites Review Götz Isenmann (S+C) Einarbeitung weiterer Review-Kommentare Daniela Koudela (ZIH) D1.3 TIMaCS Gesamtarchitektur V2 r342 2/

3 Inhaltsverzeichnis 1 Einleitung Architekturübersicht Grundkonzept Begriffe Monitoring-Daten Event und Event-Daten Policy und Regeln Konzept Management der Komplexität Bausteine der Architektur Struktur eines TIMaCS-Knotens Übersicht Monitoring Block Data-Collector Filter & Event-Generator Aggregator und Aggregation Storage Regressionstests Aufbau und Architektur Compliance-Tests Management-Block Event/Data-Handler Decision-Komponente und Entscheidungen Controller Controlled Execution Delegate Kommunikationsinfrastruktur Funktionsweise Topic-Format Wissensbasis Dynamische Partitionierung TIMaCS Illustrativer Ablauf Verteilung der TIMaCS Komponenten Illustrativer Ablauf Schnittstellen und Konfiguration der Komponenten Monitoring-Block Data-Collector Nachrichtenformat Topic-Format Interaktion mit anderen Komponenten Konfiguration...45 D1.3 TIMaCS Gesamtarchitektur V2 r342 3/

4 6.1.2 Filter & Event-Generator Beschreibung Schnittstelle Interaktion mit anderen Komponenten Konfiguration Aggregator Nachrichtenformat Topic-Format Interaktion mit anderen Komponenten Konfiguration Storage Nachrichtenformat Topic-Format Interaktion mit anderen Komponenten Konfiguration Regressiontests Schnittstellen Online-Regressionstest Offline-Regressionstest Regressionsanalyse Nachrichtenformat Topic-Format Steuerungsmöglichkeit Online-Regressionstest Offline-Regressionstest Regressionsanalyse Interaktion mit anderen Komponenten Online-Regressionstest Offline-Regressionstest Konfiguration Online-Regressionstests Offline-Regressionstests Compliance-Tests Schnittstellen Nachrichtenformat Topic-Format Steuerungsmöglichkeit Interaktion mit anderen Komponenten Konfiguration Management Block Schnittstellen Topics Nachrichtenformat Umsetzung als Rule-Engine...69 D1.3 TIMaCS Gesamtarchitektur V2 r342 4/

5 Beschreibung Konfiguration der Regelmaschine Umsetzung als Policy-Engine Beschreibung Konfiguration Delegate Topics Nachrichtenformat Interaktion mit anderen Komponenten Dynamische Partitionierung Topics Schnittstellen und Steuerung Konfiguration Referenzen...77 D1.3 TIMaCS Gesamtarchitektur V2 r342 5/

6 1 Einleitung Wie bereits in [DoW] angemerkt, erfordert die zunehmende Komplexität heutiger Rechenanlagen insbesondere im Hinblick auf Ressourcen mit einer Leistungsfähigkeit von mehreren Petaflops immer größeren Aufwand zur Administration. Bestehende Überwachungswerkzeuge wie z. B. Ganglia oder Nagios sind nicht für den Einsatz in sehr großen Rechensystemen konzipiert und zeigen nicht die notwendige Skalierbarkeit. Das Konzept, alle erkannten Probleme graphisch aufbereitet grundsätzlich an einen Administrator zu eskalieren, ist ebenfalls nicht mehr für einen Einsatz in den zukünftigen Petaflop-Systemen geeignet. Darüber hinaus werden keine spezifischen Maßnahmen zur präventiven Überwachung der Ressourcen durchgeführt. Ein weiteres bestehendes Problem ist die unzulängliche Steuermöglichkeit, welche ein aktives Eingreifen in eine Fehlersituation erlaubt. Das Ziel von TIMaCS ist, genau hier anzusetzen und die konzeptionellen Schwachpunkte bestehender Einzellösungen in einem kohärenten Gesamtkonzept zu überwinden [DoW]. Das Ziel dieses Dokuments ist die Beschreibung und Aktualisierung der TIMaCS- Gesamtarchitektur (Version 2) aufbauend auf [D1.2] und anderen relevanten Dokumenten. Die TIMaCS-Architektur definiert dabei Komponenten und Knoten aus denen das TIMaCS-Framework besteht. D1.3 TIMaCS Gesamtarchitektur V2 r342 6/

7 2 Architekturübersicht 2.1 Grundkonzept Wie bereits in der Vorhabensbeschreibung [DoW] beschrieben, ist das Ziel des TIMaCS-Projekts die Reduktion der Komplexität der manuellen Administration von Rechenanlagen durch Realisierung eines Frameworks zum intelligenten Management von Ressourcen (Rechenknoten) (auch) in sehr großer Rechenanlagen. Neben der Skalierbarkeit soll das TIMaCS-Framework folgende Eigenschaften aufweisen: Das TIMaCS-Framework soll neben der Benachrichtigung der Administratoren auch vorgegebene Maßnahmen, basierend auf den Techniken der Virtualisierung, der wissensbasierten Analyse und Bewertung von gesammelten Informationen, sowie der Definition von Metriken und Policies, automatisch ergreifen können. Darüber hinaus wird durch Datenanalyse unter Berücksichtigung früher gemessener Werte, Regressionstests genannt, und durch intensive regelmäßige Überprüfung von entsprechenden Werten auf präventive Maßnahmen vor dem Auftreten von Fehlern abgezielt. Das zu realisierende Framework wird dabei mit offenen Schnittstellen gestaltet, die eine Anbindung anderer relevanter Komponenten, wie beispielsweise SLA-Management, Accounting oder Benutzerverwaltung (z. B. user policies oder Priorität des Anwenders), ermöglicht. Der Entwurf der TIMaCS-Gesamtarchitektur basiert auf obigen Überlegungen. 2.2 Begriffe In diesem Dokument werden Begriffe verwendet die aus anderen Domänen und Kontexten entstammen. Um die verwendeten Begriffe zu verdeutlichen, werden sie kurz hier definiert: Monitoring-Daten Monitoring-Daten sind Informationen über den Zustand einer überwachten Entität (z. B. Ressource). Monitoring-Daten sind definiert als eine beliebige Informationsart mit einer Semantik, die durch eine standardisierte Beschreibung für jeden Typ der überwachten Entitäten festgelegt ist. Jede Form von Monitoring-Daten hat eine definierte Einheit (wie z. B. Kilobyte) und eine Bedeutung (freier Speicherplatz). Jedem Monitoring-Datum ist ein Zeitstempel zugewiesen, der auch Basis für die Selbstüberwachung ist (siehe auch [Genesys03]) Event und Event-Daten Ein Event-Datum ist ein spezieller Typ der Monitoring-Daten. Es repräsentiert ein Ereignis (engl. Event) das im System aufgetreten ist. Es kann sich dabei entweder um einen Event, das unmittelbar D1.3 TIMaCS Gesamtarchitektur V2 r342 7/

8 von der überwachten Entität ausgelöst wurde (z. B. Job-Queue ist leer) oder um ein künstlich erzeugtes Event, das ein Ergebnis der Verarbeitung von Monitoring-Daten ist (z. B. Überwachungskomponente meldet, dass die CPU-Auslastung 90 % übersteigt), handeln. Im Falle einer künstlichen Event-Erzeugung bedeutet dies, dass die ursprüngliche Information mit zusätzlichen Meta-Daten angereichert wurde, wie z. B. mit der Klassifikation und mit zugewiesener Dringlichkeit (vgl. [Genesys03]). Ein Beispiel hierfür wäre: Monitoring-Datum: disk space usage = 90 %. Dies kann in ein Event transformiert werden: Event: Event-Name = Disk_Almost_Full, Dringlichkeit = Warning, text = 'disc almost full!', disk space usage = 90 %, Source = nodexy Die Umwandlung von Monitoring-Daten in ein Event kann mit Hilfe von Regeln erfolgen, wie z. B.: if (disk space usage > 85 %) then trigger new Event (Event-Name = Disk_Almost_Full, text = 'disc almost full!', disk space usage = 90 %) Dringlichkeit = Warning, Die Umwandlung vom Monitoring-Daten in ein Event stellt den ersten Schritt der Fehlererkennung dar es identifiziert ein Problem, das auf einen Fehler hindeutet. Im nächsten Schritt erfolgt dann eine automatisierte Behandlung des Events mit Hilfe von vordefinierten Policies und Regeln Policy und Regeln Eine Policy ist eine Spezifikation, die das Verhalten des Systems festlegt. Ein Policy kann durch eine Policy-Sprache oder durch eine Menge von Regeln definiert werden. Policies und Regeln dienen in TIMaCS zur Erkennung und Behandlung von Fehlern. Eine Fehlerbehandlung resultiert in einer Folge von Aktionen, die den Fehler beheben sollen. Regeln, als eine der Möglichkeiten zur Definition von Policy, können die Form (Event, Conditions, Actions, Priorität) haben: Event ein bestimmtes Ereignis. Conditions bestimmte Bedingungen (z. B. boolesche Ausdrücke). Actions eine Folge von Aktionen bzw. Entscheidungen, die ausgelöst werden, wenn das bestimmte Event eingetreten ist und alle Bedingungen erfüllt sind. Priorität legt die Priorität einer Regel fest, um Regel-Konflikte 1 aufzulösen. Im 1 Regel-Konflikte entstehen dann, wenn die Auswahl einer Regel in einer Policy, aufgrund des aufgetretenen Events und erfüllten Bedingungen, nicht eindeutig ist. Dies ist dann der Fall, wenn mehre Regeln mit den gleichen Bedingungen und Events innerhalb der selben Policy definiert sind. D1.3 TIMaCS Gesamtarchitektur V2 r342 8/

9 Konfliktfall wird die Regel mit der höchsten Priorität ausgewählt. Eine Regel zur Behandlung des Events Disc_Almost_Full kann an Ponder2 [Twidle08] angelehnt illustrativ wie folgt aussehen: Event: Disk_Almost_Full; Condition: [reserve_harddisk_available == true] Action: [nodexy.mount (reserve_harddisk), GUI.alert_Admin(<Source>: disc almost full!, disk space usage = 90 %; ActionDone = Mounted Reserveharddisk )] Die Regel wird nur dann ausgeführt wenn das Event Disk_Almost_Full auftritt. Dabei wird zunächst überprüft, ob Reservekapazitäten verfügbar sind. Ist dies der Fall, so soll eine Reservefestplatte an den Problem-Knoten angebunden werden, um den Speichermangel zu kompensieren. Gleichzeitig wird eine Nachricht mit der Problembeschreibung und getroffener Entscheidung an den Administrator verschickt. Neben dem Policy-basierten Ansatz zur Fehlererkennung und Behandlung kann auch ein auf Semantik-Reasoning basierter Ansatz zur Fehlererkennung und Fehlerbehandlung verwendet werden. Dabei übernimmt eine Inferenz-Logik die Auswertung der Monitoring-Daten und Events und trifft durch das logische Schlussfolgern Entscheidungen darüber, wie aufgetretene Fehler behandelt werden sollen. Der Unterschied zwischen den beiden Ansätzen besteht darin, dass das Wissen zur Behandlung von Fehlern in Policy-basierten Systemen durch Regeln (mit konkreten Aktionen zur Folge) ausgedrückt wird, während das Wissen in Semantik-Reasoning Systemen durch Fakten und Axiome 2 dargestellt wird. 2.3 Konzept Wie bereits in der Vorhabensbeschreibung [DoW] angemerkt, beruht die Realisierung von TIMaCS auf einem hierarchischen Konzept (siehe auch [Wesner2010]), wie in Abbildung 1 dargestellt. Abbildung 2 und Abbildung 3 veranschaulichen die Hierarchien in TIMaCS. 2 Ein Axiom ist eine logische Schlussfolgerungs-Regel. Im Gegensatz zu Policy-basierten Systemen hat eine Schlussfolgerungs-Regel nicht immer Aktionen zur Folge. D1.3 TIMaCS Gesamtarchitektur V2 r342 9/

10 Aktualisierung der Wissensbasis Kommando Heartbeat Nachrichten, Ereignisse, Reports Management Block Wissensbasis Policies,... Aktualisierung der Wissensbasis Kommando Heartbeat Nachrichten, Ereignisse, Reports Management Block Kommando Wissensbasis Regeln, Policies,... Daten Daten Kommando Sensor Sensor Delegate Überwachte Ressource Delegate Externe Entität mit Einflussmöglichkeit auf die überwachte Ressource Abbildung 1: Hierarchisches Management Konzept [Wesner2010] Zunächst wird eine zu überwachende Ressource instrumentalisiert, indem darauf Sensoren und Delegates installiert werden. Sensoren liefern Informationen zur Erfassung des internen Zustands der Ressource. Delegates bieten die Möglichkeit, auf der Ressource bestimmte Maßnahmen in Form von unterstützten Befehlen oder Skripten auszuführen. Dieser Schritt realisiert einen unmittelbaren Zugriff auf den internen Zustand der Ressource. Der indirekte Zugriff auf die Ressource kann mit Hilfe von Delegates erfolgen, die nicht direkt in der überwachten Ressource integriert sind, sondern an anderen Ressourcen oder Teilsystemen angesiedelt sind, jedoch Aktionen ausführen können, die eine Auswirkung auf die überwachte Ressource haben. So kann beispielsweise das Entfernen eines Knotens XY aus dem Ressource-Pool eines Job-Schedulers eine Auswirkung (es werden keine Jobs auf dem Knoten ausgeführt) auf den Knoten XY haben, obwohl die Aktion auf dem Job-Scheduler ausgeführt wurde. In ähnlicher Weise können Monitoring-Daten bzw. Event-Daten auch indirekt erhoben werden. So kann beispielsweise eine Abfrage des Job-Schedulers den Status des Knoten XY liefern. Die Daten (Monitoring-Daten oder Event-Daten) werden nun in regelmäßigen oder unregelmäßigen Abständen verschickt oder abgefragt und dienen einem TIMaCS-Knoten, in dem der Management-Block D1.3 TIMaCS Gesamtarchitektur V2 r342 10/

11 integriert ist, als Basis für eine Entscheidung über mögliche Maßnahmen. Solche Sensoren können mit Standardkomponenten wie Ganglia oder Nagios realisiert sein, aber auch komplette Neuentwicklungen enthalten. Die Heterogenität von Sensoren kann dabei durch ein homogenes Informations- und Kommunikationsmodell im Datenaustausch mit dem Management-Block versteckt werden und erlaubt auch die Erweiterung des Systems durch weitere Sensoren durch Dritte. Neben den Monitoring-Daten, werden von jedem Knoten (TIMaCS-Knoten, Rechenknoten oder Administrator-Knoten) Heartbeats an den übergeordneten Knoten oder Reserveknoten versendet, um den Zustand des Knotens zu erfassen. Die Erzeugung eines Heartbeats kann beispielsweise zwischen zwei Simulationen bzw. Jobs erfolgen. Die Entscheidung auf Basis der gesammelten Werte und Heartbeats kann durch Anwendung von vordefinierten Regeln oder Policies erfolgen. Eine Regel definiert Entscheidungen, die in Abhängigkeit von den gesammelten Werten und eingetretenen Ereignissen ausgewählt werden. Alternativ dazu kann eine Entscheidung auch durch Semantik-Reasoning (vgl. Kapitel 2.2.3) getroffen werden. Eine Entscheidung entspricht einer Reaktion des Systems auf das erfasste Fehlverhalten und enthält Aktionen bzw. Kommandos zur Behebung des Fehlverhaltens. Die Umsetzung der Entscheidung, in Abbildung 1 als Kommando gekennzeichnet, erfolgt mit Hilfe eines Delegate, das entweder direkten Zugriff auf die überwachte Ressource hat (z. B. zum Neustart eines Prozesses) oder aber in einer anderen Form Einflussmöglichkeiten besitzt. Dies könnte zum Beispiel eine TIMaCS-Komponente für die dynamische Partitionierung sein, welche beispielsweise die Rechenknoten mit den unterschiedlichen VM-Images beschreibt/verwaltet. Andererseits kann dies auch eine aus anderen Systemen, wie z. B. Lemon [Lemon04], entnommene und mit einem Standardinterface versehene Komponente sein. Der erste Management-Block, der auch nah an der Ressource operieren sollte, muss Entscheidungen schnell und ohne große Belastung für das System treffen können. Beispiele für Aufgaben auf dieser Ebene können das Erkennen von Hardwarefehlern oder systemnahen Diensten, wie der Ausfall eines SSH-Daemons, sein und der darauf folgenden Entscheidung, den ausgefallenen Dienst neu zu starten. Alle getroffenen Entscheidungen (z. B. Neustart des SSH-Daemons) werden stets an die höhere Managementebene in Form von Reports (Nachrichten) oder Events berichtet und dort ebenfalls bewertet. Wurde beispielsweise der Neustart mehrfach vergeblich versucht, erfolgt eine Aktualisierung der Wissensbasis (Aufgabe des Neustart-Versuches) und das Einleiten von weiterführenden Untersuchungen. Dies könnte beispielsweise sein, den Knoten in den Wartungsmodus zu setzen und intensiven Tests zu unterziehen. Diese Hierarchie kann prinzipiell beliebig erweitert werden. Die Hierarchie könnte nun für alle Systeme eines Zentrums bis hin zur Ebene von SLA Management (entspricht der Grid-Ebene in Abbildung 4) erweitert werden. Da der Fokus von TIMaCS jedoch klar in der Realisierung einer Lösung für das Management von sehr großen Rechensystemen (eines Rechenzentrums) liegt entspricht dies den ersten 2 bis 3 Ebenen in Abbildung 4. Für ein hierarchisch strukturiertes System wäre es sicher naheliegend, lokale Blöcke zu realisieren, welche dann jeweils von einem gemeinsamen Block gesteuert werden. Die Umsetzung von TIMaCS kann damit durch eine baumartige Struktur konkretisiert werden, wie in Abbildung 2 dargestellt. Dabei wird unterschieden zwischen: Ressourcen bzw. Rechenknoten, auf welchen die Rechenjobs/Simulationen ausgeführt D1.3 TIMaCS Gesamtarchitektur V2 r342 11/

12 werden. TIMaCS-Knoten, auf denen die TIMaCS-Komponenten fürs intelligente Management und ggf. Monitoring installiert sind. Administrator Knoten. Dieser liegt auf der höchsten Ebene und ermöglicht einem Administrator die Verwaltung der Rechenressourcen und des TIMaCS-Frameworks. Der Administrator-Knoten bietet Tools und webbasierte grafische Oberflächen, die es einem Administrator erleichtern, das TIMaCS-Framework, sowie von ihm überwachte Knoten zu verwalten, überwachen und administrieren. Wie bereits erwähnt, kann in TIMaCS eine Entscheidung auf Basis vordefinierter Regeln und Policies 3 getroffen werden. Hierzu werden die Policies und Regeln von einem Administrator vordefiniert und in einer Wissensbasis abgelegt. Die Wissensbasis enthält neben den Policies und Regeln auch Monitoring-Profile, Inventar-Listen und eine Konfiguration des TIMaCS-Frameworks. Eine detaillierte Beschreibung der Wissensbasis erfolgt in Kapitel 3.6. Wie in Abbildung 2 zu sehen ist, ist die Wissensbasis an den TIMaCS- Administrator-Knoten angegliedert. Der Inhalt der Wissensbasis wird von Administrator-Knoten auf die unterliegenden TIMaCS-Knoten verteilt, in der Abbildung als Aktualisierung dargestellt. Die tatsächliche Hierarchiegröße des Systems ist abhängig von der Anzahl der zu überwachenden und zu verwaltenden Knoten. In einem Rechenzentrum könnte die Hierarchiegröße (in Bezug zu Abbildung 2) 3 bis 4 Ebenen umfassen: Knoten, Teil-Cluster, Cluster, Rechenzentrum. Dies wird in Abbildung 3 veranschaulicht. 3 Eine Policy ist eine Spezifikation, die das Verhalten des Systems festlegt. Eine Policy kann durch eine Policy- Sprache oder durch eine Menge von Regeln definiert sein. D1.3 TIMaCS Gesamtarchitektur V2 r342 12/

13 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 Rechenknoten Rechenknoten Abbildung 2: Hierarchische Struktur in TIMaCS... Delegate Delegate Sensor Sensor Überwachte Ressource 1 Sensor Rechenknoten... Sensor Sensor Sensor Überwachte Ressource n Rechenknoten Delegate 2.4 Management der Komplexität In diesem Kapitel beschreiben wir die Bedeutung und Begründung des in Kapitel 2.3 beschriebenen TIMaCS-Konzepts. Die Anordnung der TIMaCS-Knoten in einem logischen Baum, wie in Abbildung 2 und Abbildung 3 zu sehen, dient zur Handhabung der Komplexität 4 hinsichtlich der Überwachung, Administration und Verwaltung von Ressourcen in großen Rechenanlagen. Durch lokale Fehlerbehandlung (lokales Management) kann jeder TIMaCS Knoten, unabhängig von den anderen Knoten der gleichen Ebene, Entscheidungen zur Fehlerbehebung treffen, die dann von der übergeordneten Ebene ggf. revidiert werden können. 4 Komplexität in TIMaCS bezieht sich auf das Administrieren und Verwalten einer großen Menge von Ressourcen. Daraus leiten sich die Hauptanforderungen an das TIMaCS-Framework ab: Skalierbarkeit und Handhabung unterschiedlicher Ressourcen. D1.3 TIMaCS Gesamtarchitektur V2 r342 13/

14 Die einzelnen Ebenen in dem logischen Baum entsprechen dabei den Abstraktions- und Aggregationsebenen. Eine Aggregation von Monitoring-Daten kann beispielsweise durch Bildung von Durchschnittswerten oder Korrelationswerten 5 erreicht werden. Eine Abstraktion kann durch Berechnung von Systemzuständen auf unterschiedlichen Hierarchieebenen (Knoten, Teil-Cluster, Cluster, Rechenzentrum etc.) gebildet werden. Kapitel beschreibt detailliert die Aggregations- und Abstraktionsbildung. Legend KB Knowledgebase with Policies, Rules... Event, Report, Heartbeat Command, Updates KB Admin Node Event, Command, Report, Updates Heartbeat Event, Report, Heartbeat MM Node... MM Node... KB KB KB Command, Updates MM Node Organization Level 3 Cluster Level 2 Event, Report, Heartbeat Command, Updates Event, Report, Heartbeat Command, Updates Event, Report, Heartbeat Command, Updates KB MM Node... KB MM Node... KB MM Node Node-Group Level 1 Data, Heartbeat Command Command Data, Heartbeat Command Data, Heartbeat Sensors Delegate Computing Node... Abbildung 3: Hierarchien in TIMaCS Sensors Delegate Computing Node... Sensors Delegate Computing Node Ressource Node Level 0 Im Folgenden untersuchen wir, wie die Handhabbarkeit der Komplexität in TIMaCS erreicht werden kann. Buttom-Up View: Monitoring Aspekt: Die Abstraktions- und Aggregationsebenen reduzieren den Informationsfluss an Monitoring-Daten zum Administrator des Systems, gleichzeitig aber, 5 Der Korrelationswert ist ein dimensionsloses Maß für den Grad des linearen Zusammenhangs zwischen zwei Werten. (Vgl. [Wikipedia]) D1.3 TIMaCS Gesamtarchitektur V2 r342 14/

15 erhöhen sie den Informationswert auf wenige notwendige und wichtige Informationen, wie z. B. den Operationsstatus eines Knoten, (Teil)Clusters, Clusters,... Management Aspekt: Die Beherrschung der Komplexität bzw. Skalierbarkeit in TIMaCS wird erzielt durch Bildung von hierarchisch angeordneten, aufeinander aufbauenden Reaktionszyklen 6 unterschiedlicher Reaktionszeiten (wenige Millisekunden auf der untersten Ebene bis mehrere Minuten auf der obersten Ebene). Ein Reaktionszyklus in TIMaCS besteht dabei aus folgenden Schritten: 1. Erfassung von Monitoring-Daten, Event-Daten oder künstlichen Events: Auf der untersten Ebene werden Monitoring-Daten bzw. Event-Daten erfasst und nach der Bildung von künstlichen Events (durch Interpretation und Bewertung) an das Management der ersten Ebene weitergeleitet. Eine getroffene Entscheidung der ersten Ebene wird an die übergeordnete Ebene stets in Form von Reports bzw. Events verschickt. 2. Evaluation der Monitoring-Daten bzw. Monitoring-Events zur Fehlererkennung. Im Falle einer Fehlererkennung, wird ein Event erzeugt und mit Meta-Daten erweitert. 3. Alle Events werden hinsichtlich ihrer Dringlichkeit untersucht und in Abhängigkeit davon in ein Decision-Request umgewandelt. Das Decision- Request signalisiert, dass eine Entscheidung zur Behandlung eine Fehler-Events erforderlich ist. 4. Treffen einer Entscheidung: Das Treffen einer Entscheidung erfolgt durch Anwendung von Regeln zur Behandlung des Decision-Request -Events. Eine Entscheidung wird im Normalfall von einem Management-Block einer Ebene getroffen. In diesem Fall hat eine Regel konkrete Aktionen zur Folge, die auf dem Knoten ausgeführt werden sollen. Für den seltenen Fall, dass nicht ausreichend Information zur Entscheidungsfindung vorliegt, kann eine Entscheidungsanfrage ( Decision-Request ) an die übergeordnete Ebene propagiert werden. In diesem Fall wird eine Regel ein (neues) Event generieren, und an den übergeordneten Management-Block senden. 5. Umwandlung einer Entscheidung in ein Ressourcen-abhängiges konkretes Kommando. 6. Ausführung des Kommandos auf dem Knoten. 7. Erstellung eines Reports für die übergeordnete Ebene über das aufgetretene Event und getroffene Entscheidung(en). 8. Revidieren einer Entscheidung - Intervention (nächsthöhere Ebene): 6 Ein Reaktionszyklus besteht im Allgemeinen aus den folgenden Phasen: 1 - Wahrnehmung der Umwelt; 2 - Analyse/Interpretation der Daten; 3 - Planung und Auswahl der Aktionen als Reaktion auf den erfassten Umweltzustand; 4 - Ausführen der Aktionen D1.3 TIMaCS Gesamtarchitektur V2 r342 15/

16 Wie bereits angedeutet, sind Reaktionszyklen in TIMaCS hierarchisch aufgebaut. Der von der untergeordneten Ebene empfangene Report mit der dokumentierten Entscheidung kann revidiert werden beispielsweise dann, wenn die Häufigkeit der Reports bestimmten Typs zunimmt in dem eine neue Entscheidung getroffen wird und an die untergeordnete Ebene gesendet wird. Eine Entscheidung kann auch die Wissensbasis des untergeordneten Management Blocks mit neuen Regeln aktualisieren. Der beschriebene Reaktionszyklus zur Behandlung von Fehlern stellt eine hierarchische aufeinander aufbauende Autonomie 7 des Systems sicher: es werden immer lokale Entscheidungen getroffen und ausgeführt, die dann von der übergeordneten Ebene revidiert werden können. Dies ermöglicht, unabhängig von der Anzahl der Hierarchien, schnell auf aufgetretene Ereignisse zu reagieren, bietet aber gleichzeitig eine Möglichkeit, bereits getroffene Entscheidungen zu revidieren. Top-Down View: Management Aspekt: Die Administration von sehr großen Rechensystemen erfordert zur Beherrschung der Komplexität eine Möglichkeit zur raschen Änderung des gesamten Systemverhaltens hinsichtlich der Fehlerbehandlung und der dynamischen Partitionierung. Notwendig ist dies beispielsweise durch Vorgabe oder Änderung von SLAs, Kundenbeziehungen oder Accounting & Billing (vgl. Abbildung 4). Aus diesem Grund kann das TIMaCS-Framework durch Aktualisierung von Regeln schnell an neue Situationen angepasst werden. Durch potentielle Einbettung von Informationen auf der Ebene von SLAs, Kundenbeziehungen und Accounting & Billing kann das TIMaCS Framework um neue Policies erweitert werden, welche diese Informationen zur besseren Fehlerbehandlung und Partitionierung des Systems automatisiert ausnutzen. Dies liegt aber nicht im Fokus von TIMaCS (vgl. Abbildung 4). Abbildung 4: TIMaCS Kontext und Fokus 7 Autonomie ist die Fähigkeit des Systems, selbständig auf eingetretene Ereignisse zu reagieren. D1.3 TIMaCS Gesamtarchitektur V2 r342 16/

17 3 Bausteine der Architektur Das Konzept zur Strukturierung eines TIMaCS-Knotens basiert auf der folgenden Zielsetzung: Entwicklung eines skalierbaren, offenen, modular aufgebauten Systems, a) das eine einfache Integration vieler existierender Werkzeuge (oder deren Teil-Komponenten) ermöglicht (wie z. B. Ganglia, Nagios,...). b) das durch Modularisierung an möglichst viele unterschiedliche Bedürfnisse der Administratoren bzw. Anforderungen der Rechenzentren, Cluster,... angepasst werden kann. c) das möglichst wenig Overhead für das Monitoring und Management der Ressourcen sowie des TIMaCS-Frameworks erfordert. Dies bezieht sich zum einen auf die Rechenlast, die unmittelbar durch das Monitoring und Management erzeugt wird, und zum anderen auf die Netzwerk-Last, die durch Abfragen der Monitoring-Daten und durch Interaktion zwischen den Management-Blöcken unterschiedlicher Ebenen entsteht. Die folgenden Unterkapitel beschreiben die Bausteine der TIMaCS-Architektur. Sie beinhaltet die Struktur und Komponenten eines TIMaCS-Knotens, die Kommunikationsinfrastruktur und die Wissensbasis. 3.1 Struktur eines TIMaCS-Knotens Übersicht Wie in D1.1 und in Kapitel 2.3 angedeutet, setzt sich die grobe logische Struktur eines TIMaCS- Knotens aus Monitoring-Block und Management-Block zusammen (vgl. Abbildung 5). Für den Zugriff auf den internen Zustand der Ressource werden an der Ressource Sensoren angebracht, welche Monitoring-Daten erheben und dem Monitoring-Block zur Verfügung stellen. Um Aktionen auf der Ressource ausführen zu können, werden Delegates in der Ressource installiert. Delegates bilden eine Schnittstelle, die es ermöglicht, Ressourcen auf einheitliche Weise anzusprechen und darauf Kommandos auszuführen. Neben dem direktem Zugriff auf bestimmte Ressourcen kann der Zugriff auch indirekt über andere Systeme oder Ressourcen erfolgen. D1.3 TIMaCS Gesamtarchitektur V2 r342 17/

18 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... Delegate Abbildung 5: Grobstruktur eines TIMaCS-Knotens Sensor Sensor Sensor Überwachte Ressource n Delegate Monitoring Block Wie bereits in D1.1 beschrieben und in Kapitel 2.3 angedeutet, ist die Aufgabe des Monitoring- Blocks Daten (Monitoring-Daten oder Event-Daten) aus verschiedenen Quellen wie beispielsweise Knoten, Switches oder Sensoren zu sammeln. Darüber hinaus kann der Monitoring-Block die Daten filtern, aggregieren, speichern oder mit historischen Daten aus einer Datenbank verknüpfen, um neue Metriken zu erzeugen. Als Ergebnis der Datenanalyse kann der Monitoring-Block Events auslösen, die auf Fehler hindeuten können. Events werden anschließend von dem Management-Block weiterverarbeitet. Eine detaillierte Beschreibung der Komponenten des Monitoring-Blocks erfolgt in Kapitel 3.2. Management Block Wie bereits in D1.1 und in Kapitel 2.3 beschrieben, ist die Aufgabe des Management-Blocks Entscheidungen zur Behandlung von Fehlern, welche durch Events identifiziert werden, zu treffen. Hierzu empfängt der Management-Block ein Event, das auf einen Fehler hindeutet und trifft Entscheidungen darüber, wie der Fehler behandelt werden soll. Die Entscheidungen werden dann in Kommandos umgewandelt und auf Ressourcen mittels Delegates ausgeführt. Eine detaillierte Beschreibung der Komponenten des Management-Blocks erfolgt in Kapitel Monitoring Block Wie in Abbildung 6 zu sehen ist, ist der Monitoring-Block in die folgenden logischen Komponenten unterteilt: D1.3 TIMaCS Gesamtarchitektur V2 r342 18/

19 Der Data-Collector sammelt die Monitoring-Daten aus den verschiedenen Quellen und verschickt sie als Nachrichten über den Metrics-Kanal des Publish/Subscribe-Systems, in Abbildung 6 Message Bus genannt. Der Filter & Event-Generator (in Abbildung 6 Event-Generator genannt) filtert und evaluiert die Monitoring-Daten aus dem Metrics-Kanal, um festzustellen, ob sie auf einen Fehler hindeuten. Im Falle einer Fehlererkennung, wird ein Event generiert und an den Management-Block weitergeleitet. Die Komponente kann auch so konfiguriert werden, dass sie unabhängig vom Fehlerfall nur für bestimmte Daten-Quellen (wie z. B. für Compliance- Tests) Events generiert und an den Management-Block weiterleitet. Der Aggregator aggregiert und abstrahiert gesammelte Monitoring-Daten zur Bildung von Durchschnittswerten und Aggregaten. Die Storage-Komponente speichert die über den Metrics-Kanal empfangenen Monitoring- Daten, wobei die Werte nach Rechnername und Metrikname sortiert werden, und erlaubt dem Benutzer spezifische Abfragen durchzuführen. Compliance-Tests prüfen, ob das System bestimmten Anforderungen entspricht. Sie werden nur auf Anfrage durchgeführt. Regressionstests analysieren historische Daten, um Hinweise zu bekommen, welche Komponenten ausfallgefährdet sein könnten. Die Kopplung zwischen den Komponenten erfolgt über einen Message-Bus, welcher durch ein AMQP basiertes Publish/Subscribe System realisiert wird. Die nachfolgenden Unterkapitel geben eine detaillierte Beschreibung der aufgeführten Komponenten. D1.3 TIMaCS Gesamtarchitektur V2 r342 19/

20 Abbildung 6: Monitoring-Block Data-Collector Die Aufgabe des Data-Collectors (vgl. Abbildung 7) ist es, die Daten (Monitoring-Daten oder Event-Daten) aus verschiedenen Quellen, wie beispielsweise Knoten, Switches oder Sensoren, zu sammeln. D1.3 TIMaCS Gesamtarchitektur V2 r342 20/

21 Data-Collector Gatherer Data Monitoring tool Plugins e.g. Ganglia... Monitoring tool Plugins e.g. Nagios Data - Queue Data Data Data Data Data Data Data TIMaCS Communication Infrastructure Sensor Sensor Sensor Sensor Sensor Sensor Überwachte Ressource 1 Delegate... Abbildung 7: Data-Collector Überwachte Ressource n Delegate Monitoring-Daten bestehen hauptsächlich aus Metriken. Der Data-Collector verhält sich dabei entweder passiv, d. h. die Quellen schicken die Daten von sich aus zum Data-Collector (Push- Methode, z. B. Collectd), oder aktiv, d. h. der Data-Collector fragt die Daten explizit bei den Quellen ab (Pull-Methode, z. B. Ganglia gmond). Denkbar wäre auch eine Monitoring-Abfrage in eine Jobbeschreibung umzuwandeln und auf allen Knoten gleichzeitig ausführen zu lassen. Die Schnittstelle zwischen dem Data-Collector und Datenquellen ist offen. Dies bedeutet, dass der Data-Collector die Natur der Daten, wie zum Beispiel Temperatur oder Anzahl der CPUs, nicht selbst verstehen muss, sondern nur ein einheitliches Format, wie beispielsweise Schlüssel-Wert- Paare. Alle Metriken werden folglich gleichartig behandelt [D1.1]. Die Anpassung der Daten an das Schlüssel-Wert-Format wird in den Monitoring-Tool-Plugins vorgenommen. Wie in Abbildung 7 zu sehen, erfolgt die Erfassung der Daten mit Hilfe existierender Monitoring- Tools wie z. B. Ganglia, Nagios oder Collectd. Dies wird durch Plugins realisiert, die es ermöglichen, verschiedene existierende Monitoring-Tools wie die oben genannten, aber auch Eigenentwicklungen, in TIMaCS zu integrieren. Hierzu sind auf der überwachten Ressource Sensoren installiert, die als Quelle der Daten (Monitoring-Daten/Event-Daten) dienen. Diese Sensoren liefern im Push-Prinzip Daten an das entsprechende Plugin des Data-Collectors, oder werden von den Plugins des Data-Collector abgefragt (Pull-Prinzip). Die Plugins leiten dann die Daten an den Gatherer (Teilkomponente des Data-Collectors) weiter, wo sie, falls erforderlich, um D1.3 TIMaCS Gesamtarchitektur V2 r342 21/

22 Meta-Daten, wie zum Beispiel Name der Quelle oder Zeitstempel, erweitert werden um ein Standardformat für alle Metriken zu erreichen. Wie bereits erwähnt, werden die erhobenen Daten zunächst in einer Daten-Queue gesammelt und anschließend an weitere Komponenten des Monitoring-Blocks verteilt. Die Kopplung zwischen den Komponenten ist dabei flexibel aufgebaut und basiert auf dem Publish/Subscribe-Prinzip Filter & Event-Generator Die Aufgabe des Filter & Event-Generators ist es, die gesammelten Monitoring-Daten zu filtern und zu evaluieren, um festzustellen, ob sie auf einen Fehler hindeuten. Hierzu werden die gesammelten Messwerte mit den vordefinierten Sollwerten verglichen. Wird eine Abweichung festgestellt, so wird dies als Fehler interpretiert. Im Falle einer Fehlererkennung wird ein Fehler-Event generiert. Ein Event kann auch benutzerspezifisch ausgelöst werden, wenn es sich um Daten handelt, die dem vorgegebenen Typ/Filter (z. B. bestimmter Metrik-Name) entsprechen. Das erzeugte Event wird anschließend um Meta-Daten erweitert, welche beispielsweise den Zeitpunkt, die Quelle (z. B. Knoten-ID), den Typ (Software, Hardware, Service, ) und die Dringlichkeit (z. B. reguläre Aktualisierung, OK, Warnung, Fehler, Ausfall, Wartung notwendig) des Events beschreiben. Alle erzeugten Events werden mittels Messaging-Bus an den Management-Block verschickt, wo sie weiterverarbeitet werden. Der Filter & Event-Generator ist als Regelmaschine mit frei konfigurierbaren Regeln implementiert. Typischerweise läuft auf jedem TIMaCS-Knoten eine eigene Regelmaschine mit einem eigenen Regelsatz. Die Regelmaschine ist als AMQP-Client an den Message-Bus (AMQP- Broker) angeschlossen. Sie verarbeitet Nachrichten, die sie vom AMQP-Broker erhält und erzeugt gegebenenfalls neue Nachrichten, die sie an beliebige AMQP-Broker verschicken kann. Die Verarbeitung erfolgt entsprechend dem konfigurierten Regelsatz. Insbesondere können die oben erwähnten Fehler-Events durch diese Nachrichten realisiert werden. Die Beschreibung der Schnittstellen und der Konfiguration des Filter & Event-Generators erfolgt in Kapitel auf Seite Aggregator und Aggregation Die Aggregator-Komponente dient zum Aggregieren und Abstrahieren der Monitoring-Daten untergeordneter Knoten und zur Weiterleitung der aggregierten Daten an einen übergeordneten Knoten. Die Art der Aggregation (Summe, Durchschnitt, Systemzustandsbildung,...) und der Umfang der weitergeleiteten Daten (ggf. auch lokale Speicherung oder Verwerfen der Daten) ist dabei über ein Aggregations-Profil einstellbar, das über Befehle dynamisch angepasst werden kann. Um den Informationsfluss an Daten von den untergeordneten Knoten zu reduzieren, ist es notwendig, die erhobenen Monitoring-Daten miteinander in Beziehung zu setzen, um damit bewertende Zustände (der Ressourcen, des Knotens, Teil-Clusters, Cluster ) zu bilden. Die Bildung eines Zustands erfolgt dabei nach dem vordefinierten Aggregationsprofil. D1.3 TIMaCS Gesamtarchitektur V2 r342 22/

23 Die Aggregationsprofile für die Bildung eines operationalen Zustands können dabei wie folgt definiert sein: Knoten/Ressource-Ebene Für die Evaluierung eines Knotenzustands ist die Information über die Konfiguration des Knotens erforderlich. Eine Knotenkonfiguration kann dabei beschreiben: Maximal zulässige Monitoring-Werte der essentiellen Ressource-Komponenten sowie deren Relevanz für den Betrieb der Ressource (z. B. ausgedrückt in einem Abhängigkeitsgraph). Beispielsweise darf im normalen Betrieb die CPU-Temperatur 90 Grad Celsius nicht überschreiten. Aufzählung von Diensten, die für den Betrieb des Knotens notwendig sind, sowie ggf. ihre Abhängigkeit untereinander. Beispielsweise ist ein MPI-Dienst von dem Netzwerk-Dienst abhängig. Die Aggregationsbildung kann dann durch Evaluierung boolescher Ausdrücke erfolgen, deren Variablen sind die Zustände der einzelnen Dienste bzw. Teil-Ressourcen. Gruppierung/Teil-Cluster-Ebene Für die Evaluierung eines Gruppen-Zustands ist, analog zum Knoten, eine Konfiguration der Gruppe erforderlich. Eine Konfiguration kann dabei eine Aufzählung von Knoten und Diensten enthalten, die für den Betrieb des Teil-Clusters notwendig sind, sowie deren Abhängigkeit. Beispielsweise kann durch den Ausfall eines Netzwerk-Switches keine Kommunikation zwischen den Knoten stattfinden. Damit ist der Teil-Cluster nicht operational. Cluster-Ebene Für die Evaluierung eines Cluster-Zustands ist, analog zur Teil-Cluster-Zustandsbildung, eine Konfiguration des Clusters erforderlich. Eine Konfiguration kann dabei eine Aufzählung von Teil- Clustern, Knoten und Diensten enthalten, die für den Betrieb des Clusters notwendig sind, sowie ggf. deren Abhängigkeit. Beispielsweise kann durch den Ausfalls eines Job-Queueing-Dienstes kein Job an die Knoten in einem Cluster versendet und ausgeführt werden. Rechenzentrum-Ebene Der Zustand eines Rechenzentrums kann dabei, in Analogie zu der Cluster-Ebene, in Abhängigkeit von den Zuständen der vorhandenen Cluster berechnet werden. Die Beschreibung der Schnittstellen und der Konfiguration des Aggregators erfolgt in Kapitel auf Seite Storage Die Aufgabe der Storage-Komponente ist das Speichern der gesammelten Daten in geeigneten Datenbanken. Gleichzeitig bietet die Storage-Komponente eine Abfrageschnittstelle (API) an, die es ermöglicht, gespeicherte Monitoring-Daten aus der Datenbank anhand unterschiedlicher Kriterien, wie z. B. Hostname, Metrikname usw., abzufragen. D1.3 TIMaCS Gesamtarchitektur V2 r342 23/

24 Die Beschreibung der Schnittstellen und der Konfiguration der Storage-Komponente erfolgt in Kapitel auf Seite Regressionstests Regressionstests analysieren historische Daten, um ausfallgefährdete Systemkomponenten zu identifizieren Aufbau und Architektur TIMaCS unterscheidet zwischen Online- und Offline-Regressionstests. Erstere werden nach ihrer Konfiguration regelmäßig von TIMaCS durchgeführt und greifen bei der Analyse der Daten nur auf die Daten der jüngsten Vergangenheit zurück. Diese bekommen sie aus den aktuellen Monitoring- Daten über das 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. Abbildung 8 veranschaulicht die Funktionsweise eines Online-Regressionstests: Abbildung 8: Prinzip eines Online-Regressionstests Wird TIMaCS gestartet, so wird die Datei, in der die Online-Regressionstests konfiguriert sind D1.3 TIMaCS Gesamtarchitektur V2 r342 24/

25 gelesen und die einzelnen Online-Regressionstests werden erstellt (Abb. 8, rechts unten). Zum Start wird der Arbeitsspeicher eines Online-Regressionstests mit Daten aus dem Storage gefüllt. Ferner subscribt sich der Online-Regressionstest auf dem Daten-Kanal und erhält so aktuelle Werte der Metrik, die er auswertet. Jedes mal, wenn es an der Zeit ist, die Daten zu analysieren, werden die n aktuellsten Daten der Regressionsanalyse übergeben. Diese lädt den in der Konfigurationsdatei angegebenen Algorithmus, welcher dann das Ergebnis berechnet. Dieses Ergebnis wird als Metrik im Daten-Kanal publiziert, von wo aus es zum Storage und zum Filter & Event-Generator weitergeleitet wird. Im Gegensatz dazu werden Offline-Regressionstests nur auf Anfrage durchgeführt. 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 bei den älteren Daten nur Mittelwerte zu berücksichtigen. Je nach Komplexität der gewählten Regressionsanalyse kann dies die Berechnung beschleunigen. Abbildung 9 veranschaulicht die Funktionsweise eines Offline-Regressionstests: Abbildung 9: Prinzip eines Offline-Regressionstests Hier wird die Konfiguration über ein User-Interface eingegeben. Daraufhin holt sich der Offline- Regressionstest die erforderlichen Daten aus dem Storage, mittelt die Daten, falls gewünscht, und D1.3 TIMaCS Gesamtarchitektur V2 r342 25/

26 übergibt sie der Regressionsanalyse. Diese lädt den gewünschten Algorithmus, welcher dann das Ergebnis berechnet. Dieses wird mit den zur Berechnung benutzten Daten auf dem User-Interface angezeigt. Die Beschreibung der Schnittstellen und der Konfiguration der Regressionstests erfolgt in Kapitel auf Seite Compliance-Tests Compliance-Tests überprüfen, ob das untersuchte System bestimmte Anforderungen erfüllt. Konkret bedeutet dies, dass Soll-Werte mit Ist-Werten verglichen werden und eine Abweichung einen Fehler darstellt. Auf diese Weise kann festgestellt werden, ob sich das System im gewünschten Zustand befindet. Im Unterschied zum Monitoring überprüfen Compliance-Tests Werte, die sich nur selten ändern, wie z. B. Firmware- oder Software-Versionen, die Größe des Hauptspeichers oder das Vorhandensein von Programmbibliotheken. Zusätzlich sind Compliance-Tests dazu geeignet, um größere Tests, wie z. B. Benchmarks zu starten. Compliance-Tests bestehen aus einem Programm do_compliancetest.py, das unabhängig vom timacsd gestartet wird. Der TIMaCS-Daemon muss jedoch laufen, da in diesem die Delegates gestartet werden, die für die Abfrage der Sensoren verantwortlich sind. Das Programm do_compliancetest.py ruft zuerst eine Kommandozeilen-orientierte Benutzerschnittstelle auf. Diese stellt ein Menü an Funktionen bereit, welche es erlauben, Compliance-Tests zu konfigurieren, zu ändern, sich eine Liste aller konfigurierten Compliance-Tests anzeigen zu lassen, sich eine Liste aller zur Verfügung stehenden Benchmarks und Sensoren anzeigen zu lassen und natürlich gibt es dort auch eine Funktion zum Durchführen von Compliance-Tests. Bei der Durchführung eines Compliance-Tests wird für jeden Sensor und jeden Benchmark der vom Compliance-Test abgefragt werden soll, pro abzufragendem Knoten eine Nachricht mit den entsprechenden Informationen erzeugt und über das Publish/Subscribe-System verschickt. Das Delegate auf dem Master-Knoten des Zielknotens empfängt die Nachricht und fragt den entsprechenden Sensor auf dem Zielknoten per ssh ab. Das Ergebnis wird als Metrik in den Metrik- Kanal gesteckt und an den Storage, sowie den Filter & Event-Generator weitergeleitet. Die Ergebnisse werden in jeder Hierarchieebene zusammengesammelt und aggregiert, so dass auf dem Top-Knoten nur eine Nachricht ankommt, die mitteilt, wieviel Prozent der Ergebnisse ok waren. Ferner bieten Compliance-Tests auch die Möglichkeit, Benchmarks als Jobs dem Batch-System zu übergeben und sie auf diese Weise auf den Rechenknoten ausführen zu lassen. Die Beschreibung der Schnittstellen und der Konfiguration des Compliance-Tests erfolgt in Kapitel auf Seite Management-Block Der Management-Block, wie in Abbildung 10 zu sehen, kann in die folgenden logischen Komponenten unterteilt werden: Der Event/Data-Handler ist zuständig für das Empfangen, Evaluieren und Weiterleiten D1.3 TIMaCS Gesamtarchitektur V2 r342 26/

27 von Reports/Events und den darin enthaltenen Daten an die lokale Decision-Komponente. Hierzu werden die empfangenen Events/Reports auf ihre Dringlichkeit untersucht und ggf. reduziert 8. Die Decision-Komponente evaluiert empfangene Events/Reports, welche auf Fehler hindeuten und trifft Entscheidungen zur Fehlerbehandlung, unter Anwendung von Policies und Regeln. Der Controller wandelt die Entscheidungen in Kommandos um und sendet diese an die entsprechenden Knoten. Die Controlled-Komponente empfängt Kommandos von dem übergeordneten Management Block und leitet sie nach der Authentifizierung und Autorisierung an die adressierte Komponente, wie zum Beispiel die Execution-Komponente, weiter. Die Execution-Komponente wandelt Kommandos in ressourcenspezifische Befehle um und führt sie aus. Eine detaillierte Beschreibung der Komponenten des Management-Blocks erfolgt in den nachfolgenden Teilkapiteln. Die Beschreibung der Schnittstellen der Komponenten des Management-Blocks erfolgt in Kapitel 6.2 auf Seite Event-Reduktion dient zur Reduktion einer Menge zusammenhängender Events auf ein ggf. komplexes Event. D1.3 TIMaCS Gesamtarchitektur V2 r342 27/

28 TIMaCS Communication Infrastructure Data, Event, Reports Queue Command -Queue Legende Events, Reports Management Block Component Message Exchange Interaction with Rule/Policy/ Repository Context Builder Event/Data Handler Events, Reports Wissensbasis Update Controlled Command Re-Director Command Heartbeat Generator Decision (Policy based) Decision Request Decision Execution Map Commands to node specific execution instructions Categorization, Evaluation Decision Request Decision Controller Command Data, Events, Reports Decision Request Decision Request Queue Decision Queue Decision Map Decisions to Commands Command Data, Event, Reports Queue Abbildung 10: Management-Block Reported Decisions, Events, Data TIMaCS Communication Infrastructure Command -Queue Command Message(s) Event/Data-Handler Der Event/Data-Handler (vgl. Abbildung 11) dient als eine Schnittstelle für den Empfang von Reports, Events und darin enthaltenen Daten (Monitoring-Daten oder Event-Daten). Die Daten kommen von dem lokalen Monitoring-Block oder von den Management-Blöcken der untergeordneten Knoten. Die Komponente ist zuständig für das Empfangen, Kategorisieren, Evaluieren und Weiterleiten von Events oder Reports an die lokale Decision-Komponente. Die empfangenen Reports, Events und die darin enthaltenen Daten (Monitoring-Daten oder Event- Daten) werden zunächst von Categorization & Evaluation-Teilkomponente aus der Empfangs- Queue ausgelesen. Alle empfangene Events und Reports 9 werden gespeichert, um später zur Bestimmung der 9 Ein Report besteht aus getroffener Entscheidung und allen Informationen (Events und Bedingungen) die für das D1.3 TIMaCS Gesamtarchitektur V2 r342 28/

29 Häufigkeit 10 herangezogen werden zu können. Im nächsten Schritt werden Events oder Reports auf ihre Kategorie hin untersucht bzw. evaluiert. Die Evaluierung erfolgt anhand von Informationen, Policies und Regeln, wie sie in der Wissensbasis definiert sind. Eine Kategorisierung dient zur Festlegung des Event-Typs (z. B. Hardware-Event, Service-Event, komplexes Event, atomares Event,...) und wie hoch dessen Dringlichkeit (Informationsupdate, regulärer Status, Warnung, Fehler, kritischer Fehler, Ausfall einer Komponente, Ausfalls eines Systems, Wartung erforderlich,...) ist. Eine Evaluierung kann beispielsweise durch Korrelation mehrerer zusammenhängender Events Unregelmäßigkeiten bzw. Probleme erkennen und anschließend eine entsprechende Kategorisierung des komplexen Events bilden. Des Weiteren kann durch Evaluierung einer Menge zusammenhängender Events eine Reduzierung der Events auf einen ggf. komplexen Event erzielt werden. So kann beispielsweise durch Evaluierung mehrerer Fehler-Events, denen eine gemeinsame Ursache zugrunde liegt, das Event identifiziert werden, das am wahrscheinlichsten der Fehler-Ursache entspricht. Anhand von Regeln kann die festgestellte Häufigkeit 11 dazu verwendet werden die Dringlichkeit des Events/Reports zu steigern und damit zu eskalieren. So kann eine erhöhte Häufigkeit von beispielsweise 20 regulären Reports eines bestimmten Typs, die in einer Zeitspanne von 5 Minuten empfangen wurden, dazu führen, die Dringlichkeit von regulär auf Warnung zu steigern. Anhand der Kategorisierung und Evaluierung kann festgestellt werden: a) ob eine Menge von Events oder Reports zu einem (ggf. komplexen) Event/Report reduziert werden kann. b) ob das Event oder der Report aufgrund der Dringlichkeit ignoriert werden kann. c) ob das Event oder der Report aufgrund seiner Dringlichkeit einem Fehlerfall entspricht und eine Entscheidung der Decision-Komponente erfordert. In diesem Fall wird das Event/der Report an die Decision-Komponente übergeben. Dabei wird das Event oder der Report in ein Decision-Request transformiert und in die Decision-Request- Queue eingefügt. Die Priorität 12 des Decision-Requests wird dabei anhand der Kategorisierung und Dringlichkeit festgelegt. Treffen dieser Entscheidung notwendig waren. 10 Damit ist die Häufigkeit (Anzahl pro Zeitperiode) des Auftretens des Events bzw. des Reports gemeint. 11 Damit ist die Häufigkeit (Anzahl pro Zeitperiode) des Auftretens des Events bzw. des Reports gemeint. 12 Eine Priorisierung weist den einzelnen Events bzw. Decision-Requests Prioritäten zu, um kritische Events bzw Decision-Requests möglichst schnell behandeln zu können. D1.3 TIMaCS Gesamtarchitektur V2 r342 29/