IT-Systemmanagement mit regelbasierter, komplexer Eventverarbeitung am Beispiel der Business Logic Integration Platform Drools und des RHQ-Projektes

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Listings

Abkürzungsverzeichnis

1 Einleitung und Problemstellung
1.1 Allgemeine Anforderungen an das IT-Systemmanagement
1.2 Unternehmensweite Anforderungen an das IT-Systemmanagement
1.3 Untersuchungsperspektive
1.4 Forschungsfrage
1.5 Forschungslücke
1.6 Forschungsmethodik
1.6.1 Gang der Untersuchung
1.6.2 Benutzte Recherche-Tools
1.6.3 Keywords und Ausgangssetting der Recherche
1.7 Ziel der Arbeit
1.8 Aufbau der Arbeit

2 Historische Entwicklung und Stand der Forschung
2.1 Regelbasierte Lösungsansätze
2.2 Existierende Frameworks und Produkte für eventverarbeitende Systeme
2.3 Grundlagen des IT-Systemmanagements
2.3.1 OSI und ISO Management-Bereiche
2.3.1.1 Fehlermanagement (Fault Management)
2.3.1.2 Konfigurationsmanagement (Configuration Management)
2.3.1.3 Leistungsmanagement (Performance Management)
2.3.1.4 Sicherheitsmanagement (Security)
2.3.1.5 Abrechnungsmanagement (Accounting)
2.3.2 Standards im Bereich CEP
2.3.3 Ereignisbeziehungen und Abhängigkeiten von Systemereignissen
2.4 Das RHQ-Framework
2.5 Die Drools Plattform
2.5.1 Konzept und Funktionsweise der Drools Rules-Engine
2.5.2 Verarbeitung komplexer Events mit Drools Fusion
2.6 Motivation eines eventbasierten Lösungsansatzes
2.7 Abgrenzung eventorientierter zu imperativen Lösungsansätzen

3 Softwarearchitektur des Prototyps
3.1 Einführung und Ziele
3.2 Anforderungen der Eventverarbeitung im Prototyp
3.3 Lösungsstrategie für fachliche Anforderungen
3.4 Nichtfunktionale Anforderungen
3.5 Kopplung der Rules-Engine an vorhandene Systeme
3.6 Systemübersicht
3.7 Beispielhafter Ablauf einer Regelverarbeitung
3.8 Speicherung und Ausgabe der Ergebnisse
3.9 Anbindung der Rules-Engine zum RHQ-Framework

4 Performance Aspekte
4.1 Aufbau der Testumgebung
4.2 Vorgehensweise bei der Durchführung der Messungen
4.3 Messreihen der Gruppe 1
4.4 Testergebnisse
4.4.1 Messreihe 1
4.4.2 Messreihe 2
4.4.3 Messreihe 3
4.4.4 Weitere durchgeführte Messreihen der Gruppe 1
4.5 Messreihen der Gruppe 2
4.5.1 Messreihe 4
4.5.2 Messreihe 5
4.5.3 Messreihe 6
4.6 Diskussion der Messergebnisse
4.6.1 Messergebnisse Gruppe 1
4.6.2 Messergebnisse Gruppe 2
4.7 Handlungsempfehlungen

5 Kritische Beurteilung der eigenen Arbeit

6 Fazit und weiterer Forschungsbedarf

Anhang

Literatur- und Quellenverzeichnis

Abbildungsverzeichnis

Abbildung 1: Vertikale Informationslücken im Unternehmen

Abbildung 2: Klassifikation von Informationslagen

Abbildung 3: Die vier Hauptbereiche der Eventverarbeitung

Abbildung 4: RHQ-Systemübersicht.

Abbildung 5: Knotenelemente des ReteOO Algorithmus

Abbildung 6: ReteOO Graph aus Beispiel-Regel

Abbildung 7: Abstraktion von Ereignissen über mehrere Ebenen

Abbildung 8: Schematischer Aufbau eines Webshops

Abbildung 9: Fachobjekte mit verteilter Ablauflauflogik

Abbildung 10: Verarbeitung der Fachlogik mit zentraler Regelverarbeitung

Abbildung 11: Zusammenfassung von Events zu Correlation Units

Abbildung 12: Anbindung des Prototyps an den RHQ-Server

Abbildung 13: Komponenten des Prototyps

Abbildung 14: Aufbau des regelbasierten Systems

Abbildung 15: Schematischer Ablauf der Regelverarbeitung

Abbildung 16: CPU-Auslastung bei Messreihe 1

Abbildung 17: Java Heap-Speicherauslastung bei Messreihe 1

Abbildung 18: CPU-Auslastung bei Messreihe 2

Abbildung 19: Java Heap-Speicherauslastung bei Messreihe 2

Abbildung 20: Java Heap-Speicherauslastung bei Messreihe 3

Abbildung 21: Knowledge-Base Antwortzeiten

Abbildung 22: CPU-Auslastung bei Messreihe 6

Abbildung 23: Java Heap-Speicherauslastung bei Messreihe 6

Tabellenverzeichnis

Tabelle 1: Forschungsmethodik der Arbeit

Tabelle 2: Geschichtliche Entwicklung der Computersysteme

Tabelle 3: Anwendungsbereiche von Eventverarbeitung

Tabelle 4: Herstellerübersicht Softwarelösungen für eventverarbeitende Systeme

Tabelle 5: Open-Source Lösungen für eventverarbeitende Systeme

Tabelle 6: Komponenten der Drools Plattform

Tabelle 7: Begriffe der Rules-Engine und des ReteOO Algorithmus

Tabelle 8: Anwendungsfälle und Status des Beispiel Webshops

Tabelle 9: Begriffe im Zusammenhang mit JMS

Tabelle 10: Aufteilung der Messgruppen

Tabelle 11: Rahmenbedingungen der Tests

Tabelle 12: Ergebnisse der Messreihe 1

Tabelle 13: Ergebnisse der Messreihe 2

Tabelle 14: Ergebnisse der Messreihe 3

Tabelle 15: Ergebnisse der Messreihe 5

Tabelle 16: Ergebnisse der Messreihe 6

Tabelle 17: Deklarativer vs. Imperativer Lösungsansatz

Tabelle 18: Verwendete Testumgebung

Listings

Listing 1: Formaler Aufbau einer Regel

Listing 2: Beispiel-Regel mit Condition

Listing 3: Pseudo-Code Beispiel einer Alarm-Gruppe

Listing 4: Pseudo-Code Beispiel der Definition von neuen Alarmen

Listing 5: Pseudo-Code Beispiel von Alarm-Gruppen Definitionen

Listing 6: Erstellen komplexer Regeln mit logischen Events

Listing 7: Instanz-Variablen der EventComposite Klasse

Listing 8: Beispiel für eine DSL-Datei

Listing 9: Anwendung der DSL-Datei in einer DRL-Datei

Listing 10: Regel für die funktionalen Anforderungen 1 und 2

Listing 11: JUnit-Test für funktionale und nichtfunktionale Anforderungen

Listing 12: Regel mit inkrementell steigender Anzahl von UND-Verknüpfungen

Listing 13: Prototyp in JMS-Umgebung mit JMS-Consumer Tool

Listing 14: Die Spring XML-Konfiguration für die JMS-Umgebung

Listing 15: Der verwendete JUnit-Test für die JMS-Umgebung

Listing 16: Regel mit globaler Variablen zur Ergebnis-Speicherung

Listing 17: Die ActiveMQ JMS-Provider Konfiguration des JMS-Tests

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung und Problemstellung

Effiziente Unternehmensstrukturen mit den damit verbundenen Anforderungen der agilen Anpassung an sich ständig verändernde Rahmenbedingungen, sind entscheidende Faktoren für den Erfolg eines Unternehmens. Märkte und deren Teilnehmer ändern sich, es gibt bspw. neue gesetzliche Rahmenbedingungen, auf die Unternehmen und deren IT angemessen reagieren müssen. Abläufe in der realen Welt werden hierbei oft durch Geschäftsprozesse als Softwarelösung umgesetzt. Der IT kommt so eine entscheidende Bedeutung bei der Umsetzung der unternehmerischen Herausforderungen und Ziele zu.^[1]

Immer komplexer werdende Geschäftsprozesse auf der einen Seite, fordern anpassungsfähige IT-Infrastrukturen und Unternehmensarchitekturen auf der anderen Seite. Bei gleichzeitig knapper werdenden Personalressourcen führt dies u.a. zu steigendem Bedarf des Einsatzes automatisierter Management-Plattformen zur Überwachung der eingesetzten IT-Lösungen.^[2]

IT-Systemmanagement hilft, bei der Lösung des Problems vielfältige Abhängigkeiten zwischen den Systemen darzustellen und auftretende Probleme zu melden. IT ist in vielen Anwendungsbereichen die Basis für die Umsetzung von Geschäftsprozessen und hat somit einen starken Einfluss auf die Umsetzung unternehmerischer Ziele. Störungen im IT-Betrieb sind u.a. mit hohen finanziellen Risiken für ein Unternehmen verbunden. Ein proaktiver Ansatz des IT-Systemmanagements hilft Systemausfälle zu vermeiden, oder Schwachpunkte aufzudecken, bevor Auswirkungen auf den Produktivbetrieb entstehen. Besonders wichtig wird dies, wenn es vertragliche Verpflichtungen zur Einhaltung von genau spezifizierten Service-Verfügbarkeiten, sog. Service Level Agreements (SLA), im Rahmen einer vertraglichen Erfüllung von Leistungen beim Service Level Management (SLM) gibt.^[3]

Event Driven Architecture (EDA) und Complex Event Processing (CEP) stellen konzeptionelle Ansätze dar, bei denen Ereignisse (Events) ein zentrales Element der Software Architektur bilden. Diese Arbeit betrachtet Chancen, Herausforderungen und Risiken eventverarbeitender Lösungsansätze bei Unternehmensanwendungen. Schwerpunkt der Arbeit sind die Möglichkeiten von CEP im Rahmen des IT-Systemmanagement und die Integrationsmöglichkeiten in Software-Lösungen, dargestellt am Beispiel des RHQ-Frameworks.^[4]

1.1 Allgemeine Anforderungen an das IT-Systemmanagement

IT-Systeme und IT-Systemmanagement werden in dieser Arbeit wie folgt definiert:

Definition 1: IT-System^[5]

„Ein IT-System ist ein technisches System, bei dem technische Einrichtungen wie Hardware (z.B. Rechner, Übertragungsleitungen, Drucker), Software (Programme) sowie Daten, explizite Informationen und Methoden/Verfahren zu deren Verarbeitung, die Systemelemente bilden.“

Definition 2: IT-Systemmanagement^[6]

IT-Systemmanagement umfasst alle Verwaltungs- und Durchführungsaufgaben mit dem Ziel, einen störungsfreien Betrieb, eine optimale Leistung und Zusammenarbeit aller beteiligter Komponenten eines IT-Systems sicherzustellen.

Beim produktiven Einsatz eines Softwaresystems sind neben der Einhaltung von SLAs u.a. die Überwachung von Leistung und Effizienz der eingesetzten Systeme wichtige Funktionen einer IT-Systemmanagement-Lösung. Das in der Arbeit vorgestellte RHQ-Projekt unterstützt den zuverlässigen Betrieb von Softwaresystemen. Es ermöglicht eine weitreichende Überwachung, Protokollierung sowie proaktives Management der laufenden Anwendungen, Services und der dazugehörigen Systeme. Ausfallzeiten in produktiven Systemen können neben finanziellen Verlusten auch rechtliche Folgen haben und wirken sich negativ auf die Reputation des Serviceanbieters aus. Durch professionell geplantes IT-Systemmanagement können potentielle Ausfälle frühzeitig erkannt und vermieden werden. Problematisch ist die Abbildung von IT-Systemparametern wie z.B. Antwortzeit, Verfügbarkeit oder CPU-Last auf ihre tatsächliche Auswirkung auf die operativen Geschäftsprozesse, da hier ein Zusammenhang zwischen den IT-Parametern und dem/den betroffenen Geschäftsprozess(en) nicht direkt erkennbar ist.^[7] Ein Lösungsansatz für dieses Problem kann CEP sein. Im weiteren Verlauf dieser Arbeit werden einerseits der Stand der Technik am Beispiel der Open Source Projekte RHQ und Drools aufgezeigt und andererseits die erweiterten Möglichkeiten einer Integration von CEP in das RHQ-Framework konzeptionell erarbeitet. Teil dieser Arbeit ist ein Prototyp, der als Proof of Concept eine spätere Implementierung der Arbeitsergebnisse in das RHQ-Projekt evaluiert.

1.2 Unternehmensweite Anforderungen an das IT-Systemmanagement

In der Gesamtbetrachtung an die Anforderung einer Informationsbereitstellung in Unternehmen, kommt es zu vertikalen Informationslücken (Information lat. „informare“ = „Gestalt geben“), die Luckham im Rahmen seiner grundlegenden Forschungen im Bereich CEP aufzeigt.^[8] Dies verhindert eine durchgehende Verarbeitung von aufgetretenen System-Ereignissen zwischen den Anwendungsebenen. IT-Management, Abteilungsleiter, Vorstände, haben einen unterschiedlichen Informationsbedarf, der von den IT-Systemen abgedeckt werden muss. Für unterschiedliche Management-Ebenen sind benötigte Informationen also differenziert zu betrachten. Es werden bspw. für die Ebenen „Business and Operations“, „Applikations“ und „Middleware and Network“ unterschiedliche Informationen benötigt, die vom Unternehmensnetzwerk im Enterprise IT-Layer zur Verfügung gestellt werden müssen. Ereignisgesteuerte Systeme können hierbei den geforderten Informations- bzw. Wissensbedarf nur dann decken, wenn bei perfekter Informationslage alle notwendigen Informationen im Enterprise IT-Layer zur Verfügung gestellt werden können. In der Praxis ist dies jedoch bei vielen Unternehmen nicht der Fall, da historisch gewachsene Infrastrukturen bspw. mit isolierten „Insellösungen“ vorhanden sind. Es ist eine imperfekte Informationslage vorhanden. Dies bedeutet, die notwendigen Informationen zur Weiterverarbeitung sind nicht in nicht ausreichender Form vorhanden.

Abbildung in dieser Leseprobe nicht enthalten

In Anlehnung an: Luckham, D. (2002), S. 49.

Abbildung 1: Vertikale Informationslücken im Unternehmen

Neben regelbasierten Ansätzen sind imperfekte Informationen Gegenstand weitreichender Forschungen bspw. in den Bereichen:^[9]

- wahrscheinlichkeitsbasierte Ansätze
- Fuzzy-basierte Ansätze
- Evidenztheorie
- Default-Schließen

Bei der Evaluierung des Prototyps wird von perfekten Informationslagen bei der Eventverarbeitung ausgegangen.

Abbildung in dieser Leseprobe nicht enthalten

In Anlehnung an: Büttner, R. (2011), S. 131.

Abbildung 2: Klassifikation von Informationslagen

In dieser Arbeit sind u.a. die Begriffe Information, Wissen und Ereignisse (Events) von zentraler Bedeutung. Der Informationsbegriff hat trotz seiner zentralen Bedeutung in der Informatik, unterschiedliche Definitionen. Beim Informationsbegriff wird i.W. zwischen drei Ebenen unterschieden:^[10]

1. Syntaktische Ebene: Ausschließliche Betrachtung der Zeichen und ihrer binären Kodierungen (bspw. Bitfolgen)
2. Semantische Ebene: Zusätzliche Berücksichtigung der Bedeutung der Zeichen
3. Anwendungsbezogene Ebene: Weitere Berücksichtigung der Zeichenbenutzer (Anwender) und des Zwecks der Information.

Im Rahmen dieser Arbeit werden die Begriffe Wissen und Ereignisse (Events) im Sinne der folgenden Definition verwendet:

Definition 3: Wissen^[11]

Unter Wissen sind Aussagen zu Ereignissen, Zuständen und die damit verbundenen Zuordnungen zu bestimmten Werten (Wahrheitswerte, Wahrscheinlichkeitswerte) zu verstehen. Entscheidungsorientiertes Wissen wird mit Informationen beschrieben.

1.3 Untersuchungsperspektive

Schwerpunkt dieser Arbeit ist die Integrationsmöglichkeit von CEP in IT-Systemmanagement Plattformen. Das theoretische Konzept wird als eventbasierter Prototyp beispielhaft umgesetzt und evaluiert. Fokus ist hierbei das IT-Systemmanagement von Infrastruktur, Services und Möglichkeiten der Anwendungen mit ereignisgesteuerter komplexer Verarbeitung von Regeln (Rules). Integrationsmöglichkeiten in vorhandene IT-Systemmanagementlösungen werden im Prototyp stellvertretend anhand des RHQ-Frameworks als existierende Open Source Lösung evaluiert.^[12] Komponenten der Business Logic Integration Platform Drools dienen hierbei als Rules-Engine für die Eventverarbeitung.^[13]

1.4 Forschungsfrage

Ausgehend von den Anforderungen an das IT-Systemmanagement ist die Forschungsfrage dieser Arbeit:

- Können IT-Systeme in einem komplexen Umfeld mit der IT-Systemmanagement Plattform RHQ, in Verbindung mit komplexer Eventverarbeitung, effizient gemanagt werden?

1.5 Forschungslücke

Derzeit ist keine komplexe Eventverarbeitung im RHQ-Framework implementiert. Es ist bspw. nicht möglich, verschiedenartige Events aus unterschiedlichen Event-Quellen (Ressourcen) mit den dazugehörigen Metriken zu vergleichen. Außerdem besteht keine Möglichkeit einer Alarmgenerierung bei mehrfachem Auftreten bestimmter Ereigniskombinationen. Auch eine Verwaltung von zuständigen Alarmempfängern z.B. aus einem Schichtplan ist derzeit nicht möglich. Bei erfolgreicher Evaluierung ist geplant, CEP als Lösungsansatz für diese fehlenden Leistungsmerkmale in das RHQ-Framework zu integrieren. Folgende Begriffe werden im weiteren Verlauf gemäß Definitionen verwendet:

Definition 4: Ereignis, Event^[14]

Ein Ereignis (Event) ist alles, was im IT-System geschieht oder als geschehen betrachtet wird.

Definition 5: Komplexe Events^[15]

Ein komplexes Event ist ein Event, dass eine Abstraktion von anderen Events ist und diese als seine Mitglieder betrachtet.

Definition 6: Komplexe Eventverarbeitung (CEP)^[16]

CEP sind softwaretechnische Berechnungen, die Operationen mit komplexen Events ausführen. Die Berechnungen beinhalten Lesen, Erzeugen, Umwandeln oder das Abstrahieren von Events.

Definition 7: Metriken^[17]

Metriken im RHQ-Framework sind Informationen über den Zustand einer im System bekannten Ressource. Es werden folgende Metriken unterschieden:

- Numeric metrics: Numerische Werte
- Traits: Beschreibende Informationen.
- Response times: Antwortzeiten.

1.6 Forschungsmethodik

Die Arbeit wird im Design Science Ansatz, mit Erstellung und Evaluierung eines Prototyps in Laborumgebung umgesetzt.^[18]

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Forschungsmethodik der Arbeit

1.6.1 Gang der Untersuchung

- Literaturrecherche in Journalen
- Internetrecherche
- Projektdokumentationen der verwendeten Frameworks
- Ergänzungen durch Expertendiskussionen mit Dipl.-Inform. Heiko W. Rupp, einem führenden Entwickler des RHQ-Frameworks^[19]

1.6.2 Benutzte Recherche-Tools

- Google Scholar^[20]
- Springerlink^[21]
- ACM^[22]
- Base-Search^[23]

1.6.3 Keywords und Ausgangssetting der Recherche

- IT-Systemmanagement, Systemmanagement, IT-Systems management
- Application Performance Management
- Complex Event Processing
- CEP
- Rule-Based Event Processing
- Rule-Based Complex Event Processing
- Rule-Based Validation Framework
- Event-Condition-Expectation
- Event-Driven Business Process Management
- Event Processing Language
- Event-Correlation
- Drools
- RHQ

Gesamtspektrum der Recherche: Theorie und Praxisbezug

1.7 Ziel der Arbeit

Diese Arbeit soll zeigen, dass CEP im Rahmen des IT-Systemmanagement konzeptionell und in praktischer Anwendung effizient möglich ist. Der Prototyp dient als Grundlage einer Implementierung zur Erweiterung des RHQ-Framworks bzgl. der in Kap 1.5 festgestellten Forschungslücke.

1.8 Aufbau der Arbeit

Die Arbeit ist in sechs Kapitel gegliedert. Die Formulierung von Problemstellung, unternehmensweite Anforderungen, Forschungsansatz, Forschungsfrage, Forschungsmethodik, sowie die Skizzierung des Aufbaus und Ziel der Arbeit erfolgen im ersten Kapitel. Um das Forschungsgebiet der regelbasierten, komplexen Eventverarbeitung in einem größeren Zusammenhang darzustellen, enthält Kapitel zwei ein Überblick über die historische Entwicklung der Eventverarbeitung und des IT-Systemmanagements. Hierbei werden Grundlagen der Eventverarbeitung, sowie der Stand der Forschung und existierende Standards aufgezeigt. In Kapitel drei werden die Konzepte und Lösungsansätze des Prototyps sowie die im Rahmen der Evaluierung verwendeten Frameworks erläutert. Theoretische Grundlagen zu Konzept und Funktionsweise der Verarbeitung komplexer Events in Verbindung mit fachlichen und nichtfunktionalen Anforderungen schließen dieses Kapitel ab. In Kapitel vier werden Performance Aspekte betrachtet. Die verfolgte Lösungsstrategie wird anhand von Messreihen evaluiert und diskutiert. Abschließend werden hier mögliche Lösungsstrategien zur Performanceoptimierung und Schlussfolgerungen aufgezeigt. Kapitel fünf enthält die kritische Beurteilung der eigenen Arbeit. Ein Fazit und erkannter weiterer Forschungsbedarf schließen die Arbeit in Kapitel sechs ab.

2 Historische Entwicklung und Stand der Forschung

Beginnend mit den 1960er Jahren des letzten Jahrhunderts ist eine deutliche Steigerung der Komplexität der Verteilung und Vernetzung von IT mit einem heute vorhandenen Trend zum „Ubiquitous Computing“ erkennbar. Aus der geschichtlichen Entwicklung von Einzelsystemen zu komplexen Vernetzungen folgt steigender automatisierter Integrations- und Managementbedarf der vorhandenen IT-Systemlandschaften.

Abbildung in dieser Leseprobe nicht enthalten

In Anlehnung an: Aier, S. (2006), S. 20 ff.

Tabelle 2: Geschichtliche Entwicklung der Computersysteme

Im weiteren Verlauf werden regelbasierte Lösungsansätze des IT-Systemmanagement als eine Möglichkeit des IT-Systemmanagement dargestellt.

2.1 Regelbasierte Lösungsansätze

Erste Implementierungen eventbasierter Verarbeitungen waren schon ab den 1960er Jahren vorhanden.^[24] Für die Eventverarbeitung haben sich vier Hauptbereiche über einen Betrachtungszeitraum von fünfzig Jahren entwickelt:

- Discret Event Simulation
- Network Management und Business Activity Monitoring
- Active Data Bases
- Middleware/SOA

In dieser Arbeit liegt der Schwerpunkt in den Bereichen Network Development und Business Activity Monitoring.

Abbildung in dieser Leseprobe nicht enthalten

In Anlehnung an: Luckham, D. (2012a), S. 3.

Abbildung 3: Die vier Hauptbereiche der Eventverarbeitung

Richtungsweisend für die Entwicklung von komplexer Eventverarbeitung war das von David Luckham zwischen 1990 und 2000 an der Stanford University geleitete Forschungsprojekt RAPIDE. Kernfunktionalität des Projektes ist eine auf Events basierende Simulation. Aus RAPIDE entstanden die ersten Experimente mit CEP. Einsatzgebiet waren weitgehend das Monitoring „kleiner“ Kommunikationssysteme sowie sicherheitstechnische Auswertungen von Bedrohungsszenarien im IT-Layer einer großen Universität.^[25]

Mittlerweile haben sich CEP und ereignisgesteuerte Architekturen (EDA) als eigenständige Fachgebiete der Informatik etabliert. Hierbei wird i.W. zwischen folgenden Anwendungsbereichen unterschieden:^[26]

Abbildung in dieser Leseprobe nicht enthalten

In Anlehnung an Bruns, R., Dunkel, J. (2010), S. 9 ff.

Tabelle 3: Anwendungsbereiche von Eventverarbeitung

In dieser Arbeit werden die Anwendungsbereiche Computer-Netzwerke und Softwarearchitektur weiter betrachtet und Integrationsmöglichkeiten in IT-Systemmanagement-Plattformern am Beispiel des RHQ-Projektes evaluiert.

2.2 Existierende Frameworks und Produkte für eventverarbeitende Systeme

Der Markt für Softwarelösungen für eventverarbeitende Systeme wird zwischen kommerziellen und nicht kommerziellen Open-Source Lösungen aufgeteilt.

Wesentliche, bekannte Produkte und Hersteller kommerzieller Lösungen sind:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4: Herstellerübersicht Softwarelösungen für eventverarbeitende Systeme

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 5: Open-Source Lösungen für eventverarbeitende Systeme

Im Rahmen dieser Arbeit wurde das Drools-Framework für die Erstellung des Prototyps verwendet.

2.3 Grundlagen des IT-Systemmanagements

IT-Systemmanagement ist ein Teilbereich einer unternehmensweiten Lösungsstrategie zum Verwalten der IT-Systemlandschaft. Hierzu werden im folgenden Abschnitt die dazugehörigen OSI/ISO Management-Bereiche näher erläutert.

2.3.1 OSI und ISO Management-Bereiche

1989 wurde eine genauere Definition des Begriffes „Netzwerkmanagement“ als Teilmenge von IT-Systemmanagement, von der ISO und der IEC im OSI Managementmodell festgelegt. Grundsätzlich wird hierbei zwischen passiven (beobachtenden) Aufgaben bei der Netzwerküberwachung und aktiven (beeinflussenden) Aufgaben bei der Netzwerkkonfiguration unterschieden. Im OSI werden die Funktionalitäten des Netzwerkmanagements im Standard ISO/IEC 10040 festgelegt. Es sind folgende Bereiche vorhanden:^[27]

- Fehlermanagement (Fault Management)
- Konfigurationsmanagement (Configuration)
- Abrechnungsmanagement (Accounting)
- Leistungsmanagement (Performance)
- Sicherheitsmanagement (Security)

Bekannt ist dieses Modell auch als „FCAPS“, gemäß den ersten Buchstaben der englischen Übersetzung der fünf Management-Bereiche. Für diese Arbeit sind i.W. die Bereiche Konfigurations-, Fehler- und Performancemanagement im Kontext des IT-Systemmanagement relevant.

2.3.1.1 Fehlermanagement (Fault Management)

Ziel des Fehlermanagements ist es, auftretende Fehler frühzeitig zu erkennen, zu isolieren und zu beheben. Bei der Eventverarbeitung besteht die Herausforderung darin, unstrukturierte Daten (Events) zu korrelieren. Erst hierdurch entsteht eine Bedeutung im Kontext, um daraus auszuwertende Eigenschaften wie Verfügbarkeit, Performance, Fehlerstatus, oder andere Systemzustände abzuleiten.^[28] Ebenso muss bei einem auftretenden Fehler bspw. ein möglicherweise daraus resultierender Folgefehler erkannt und isoliert werden (Root Cause Analysis). Fällt z.B. bei einem Ethernet Switch ein Port aus, sind ein an diesem Port angeschlossener Server und dessen Services evtl. nicht mehr im Netzwerk erreichbar. Der am Switch angeschlossene Server und dessen Services selbst sind hierbei ja nicht fehlerhaft. Diese Fehlerkonstellation muss von der Management-Applikation erkannt und weitergemeldet werden, um die eigentliche Fehlerursache (den sog. Root Cause) effizient zu ermitteln und im Rahmen einer Alarmierung weiterzuleiten und zu protokollieren.

2.3.1.2 Konfigurationsmanagement (Configuration Management)

Aufgabe des Konfigurationsmanagement ist es, die beteiligten Systeme zu identifizieren, Daten von ihnen zu ermitteln, Daten zur Verfügung zu stellen, sowie Kontrolle über sie auszuüben. Typische Beispiele hierfür sind:

- Die eindeutige Zuweisung von Namen für verwaltete Objekte und Objektgruppen
- Konfiguration der Systeme
- Bedarfsorientierte Ermittlung von Informationen über das System und seinen aktuellen Zustand
- Entgegennahme von Meldungen über Zustandsänderungen und Fehlersituationen

2.3.1.3 Leistungsmanagement (Performance Management)

Das Leistungsmanagement beschäftigt sich mit der Auslastung eines Systems. Hierbei wird neben den aktuellen Auslastungswerten auch eine Historie über die Verfügbarkeit erstellt. Damit ergeben sich weitere Möglichkeiten, um Abweichungen von Sollzuständen zu erkennen, oder Vorhersagen über zukünftige Verfügbarkeiten zu erstellen. Leistungsmanagement erlaubt also die Erweiterung vom rein reaktiven IT-Systemmanagement hin zum proaktiven IT-Systemmanagement.

2.3.1.4 Sicherheitsmanagement (Security)

Sicherheit ist ein zentraler Aspekt in Datennetzen. Nahezu alle Geschäftsvorfälle hängen direkt oder indirekt von der Netzwerkinfrastruktur ab. Beim Sicherheitsmanagement stehen die Faktoren Zugangskontrolle, Abschirmung von der Außenwelt, sowie Verschlüsselung der Daten im Vordergrund. Das Sicherheitsmanagement beinhaltet vorrangig die Überwachung und das Einrichten und Abbauen von Sicherheitsmechanismen, sowie die Identifizierung und Protokollierung von Sicherheitsverstößen.

2.3.1.5 Abrechnungsmanagement (Accounting)

Das Abrechnungsmanagement definiert die Verarbeitung und Verwaltung anfallender Abrechnungsdaten, da Netzwerkressourcen i.A. nicht kostenlos zur Verfügung gestellt werden. Im Fall von Internet Service Providern ist dies die Berechnung für den Zugang der Kunden zum Internet und je nach Abrechnungsmodell, evtl. ein Mengenvolumen. Bei Firmen-Netzen kann die Abrechnung nach Kostenstellen des Betriebes aufgeteilt werden. Ein wichtiger Aspekt beim Abrechnungsmanagement ist in allen Anwendungsfällen die Nachvollziehbarkeit der erhobenen Gebühren, dies wird durch das Abspeichern der relevanten Daten z.B. in einem Datenbank-System erreicht.

2.3.2 Standards im Bereich CEP

Die am Markt verfügbaren kommerziellen und Open-Source Lösungen verwendenden derzeit proprietäre Event Processing Languages (EPLs) und APIs. Aktuell werden jedoch Standardisierungen in diesen Bereichen vorangetrieben.^[29] Wesentliche Standardisierungsarbeiten sind hierbei:

- Die Java Rule Engine, spezifiziert im JSR 94^[30]
- Das Rule Interchange Format als Austauschformat für Regeln^[31]
- Die Regelsprache RuleML^[32]

Drools unterstützt in seiner Implementierung JSR 94 mit einem eigenen Modus, der allerdings gegenüber der proprietären Implementierung einen eingeschränkten Funktionsumfang hat.^[33] Für Regeldefinitionen mit RuleML die in der von Drools verwendeten proprietären Sprache „DRL“ verwendet werden können, gibt es mittlerweile einen Konverter „RuleML2DroolsTranslator“ der als Open-Source Projekt verfügbar ist.^[34] Die Verwendung einer standardisierten Regelsprache wie RuleML ist eine wichtige Voraussetzung für Investitionsschutz und Wiederverwendbarkeit bei einem potentiellen Wechsel der verwendeten Rules-Engine. Fehlende Standards stellen derzeit noch ein großes Hindernis für den verbreiterten Einsatz von CEP in Projekten dar.^[35]

2.3.3 Ereignisbeziehungen und Abhängigkeiten von Systemereignissen

Einzelne Events besitzen meistens keine ausreichende Information, um Bedeutung für einen zu signalisierenden Zustand einer Systemressource innerhalb der IT-Systemmanagement Anwendung zu haben. Die Feingranularität einzelner Events muss zu anderen Events in Beziehung gesetzt werden, um in diesem größeren Kontext Bedeutung für die Auswertung zu haben. Luckham und Schulte unterscheiden hierbei anhand der folgenden Kriterien:

“ Relationships between events: Events are related by time, causality, abstraction and other relationships. Time and causality impose partial orderings upon events.”^[36]

Zeitliche Zusammenhänge:

- Hierbei kann anhand von Zeitstempeln (Timestamps) ausgewertet werden, ob Event-A sich zeitlich vor oder nach Event-B oder anderen Events ereignet hat.

Kausale Zusammenhänge:

- Es kann entschieden werden, ob ein Event ursächlich einem anderen Event vorausgeht, oder für das Auftreten eines Events eine notwendige Bedingung ist. Verursacht Event-A ein Event-B ist die Voraussetzung für das Vorhandensein von Event-B das Event-A.

Fachliche Korrelation:

- Die Zuordnung von Events erfolgt aufgrund fachlicher Zusammenhänge, die im System durch Regeln spezifiziert werden können.

Diese Ereignisbeziehungen und Möglichkeiten der Abhängigkeiten zwischen Events stellen wichtige konzeptionelle Möglichkeiten für IT-Systemmanagement Applikationen dar und werden im Prototyp beispielhaft umgesetzt.

2.4 Das RHQ-Framework

RHQ ist ein Open-Source Framework für IT-Systemmanagement. Es beinhaltet eine Server/Agenten Architektur, die mit einem Plugin Konzept erweiterbare und integrierte Systemmanagement-Funktionen für verschiedenste Produkte und Plattformen bietet.^[37]

RHQ beinhaltet die folgenden Kernfunktionen:

- Automatische Erkennung von überwachten Ressourcen
- Monitoring von Ressource-Metriken, Logdateien, oder anderen Event-Quellen
- Konfiguration der überwachten Ressourcen
- Deployment von Software-Artefakten auf überwachte Maschinen
- Erkennung von Änderungen im Filesystem
- Logische Gruppierung von Ressourcen
- Alarmierung bei Fehlerzuständen

RHQ wurde mit dem Hintergrund der flexiblen Erweiterbarkeit konzipiert. Es besteht aus einem zentralen Server, oder einem Cluster von Servern und Agenten, die auf den überwachten Maschinen (sog. Plattformen in RHQ-Terminologie) laufen. Eine zentrale Datenbank persistiert alle notwenden Informationen wie z.B. Inventar, gesammelte Metriken, zeitgesteuerte Aufrufe von Befehlen und Alarmdefinitionen.

Die Interaktion des Benutzers mit dem Server erfolgt über eine Grafische Benutzeroberfläche (GUI), oder alternativ über Kommandozeile (CLI) oder HTTP-REST Zugriff.

[...]

^[1] Vgl. Bruns, R., Dunkel, J. (2010), S 3.

^[2] Vgl. Aier, S. (2006), S.1.

^[3] Vgl. Häusler, O. (2012), S. 48.

^[4] Vgl. rhq.org (2012a), o.S.

^[5] Aier, S. (2006), S. 18.

^[6] Vgl.Häusler, O. (2012), S. 71-72.

^[7] Vgl. Häusler, O. (2012), S. 56.

^[8] Vgl Luckham, D. (2002), S. 49.

^[9] Vgl. Büttner, R. (2011), S. 131 ff.

^[10] Vgl. Büttner, R. (2011), S. 126 ff.

^[11] Vgl. Büttner, R. (2011), S. 126.

^[12] Vgl. rhq.org (2012a), o.S.

^[13] Vgl. drools.org (2012a), o.S.

^[14] Vgl. ep-ts.com (2012), o.S.

^[15] Vgl. ep-ts.com (2012), o.S.

^[16] Vgl. ep-ts.com (2012), o.S.

^[17] Vgl. red.hat.com (2012a), S.4.

^[18] Vgl. Hevner, A. R., et al. (2004), S. 75-105.

^[19] Die Ergebnisse der Diskussion sind in rhq.org (2012c) eingeflossen und waren Grundlage für die Implementierung des Prototyps.

^[20] google.de (2012), o.S.

^[21] springerlink.com (2012a), o.S.

^[22] acm.org (2012a), o.S.

^[23] base.net (2012), o.S.

^[24] Vgl. Starke, G. (2011), S. 204-205.

^[25] Vgl. Luckham, D. (2002), S. xviii.

^[26] Vgl. Bruns, R., Dunkel, J. (2010), S. 9ff.

^[27] Vgl. Clemm, A. (2006), S. 131 ff.

^[28] Vgl. Luckham, D. (2002), S. 104 ff.

^[29] Vgl. Bruns, R., Dunkel, J. (2010), S. 223-224.

^[30] Vgl. jcp.org (2012), o.S.

^[31] Vgl. w3c.org (2012), o.S.

^[32] Vgl. ruleml.org (2012), o.S.

^[33] Vgl. drools.org (2012b), S. 229 ff.

^[34] Vgl. codehaus.org (2012), o.S.

^[35] Vgl. Bruns, R., Dunkel, J. (2010), S. 223.

^[36] ep-ts.com (2012), S.19.

^[37] Vgl. rhq.org (2012a), o.S.