Ein Überblick über ausgewählte Tivoli-Produkte

Transkript

1 Ein Überblick über ausgewählte Tivoli-Produkte Eine Ausarbeitung im Rahmen des Hauptseminars Aspekte und Werkzeuge der DB-Administration und deren Automatisierung von Marcel Brückner

2 Inhaltsverzeichnis 1 Einleitung 3 2 Tivoli Monitoring for Databases (ITM) Grundidee Architekturübersicht Umsetzung Beteiligte Komponenten Situations und Reflexes Policies Resource Model Grundidee Logische Komponenten Aufbau in Workbench Dynamic Model Thresholds Events Parameters Logging Decision Tree Script Dependencies Beispiel eines Ressourcen-Modells Tivoli Enterprise Console (TEC) Architekturübersicht Adapter Configuration Facility Event Adapter Tivoli Event Integration Facility Tivoli Enterprise Console Gateway Tivoli NetView Event Server Event Database User Interface Server Event Console Kombination mit ITM Rule Sets Zusammenfassung 20 2

3 1 Einleitung Die IT-Infrastruktur, die in heutigen Businesssystemen verwendet wird, entwickelt sich ständig und mit rasantem Tempo fort. Die Verwendung von immer größeren und komplexeren Systemen stellt das betreuende Personal vor die schwierige Aufgabe, den Überblick zu behalten und auf eintretende Ereignisse schnell und sicher zu reagieren. Diverse Management-Tools sollen hier Abhilfe schaffen. Jedoch sind die Anforderungen an solche Tools in den letzten Jahren enorm gestiegen. Es reicht nicht mehr einfach nur, den Administrator auf auftretende Fehler hinzuweisen und diese eventuell reaktiv zu beseitigen. Statt dessen wird von heutigen Management-Tools erwartet, dass diese proaktiv handeln und eventuelle Fehlerquellen bereits im Keim ersticken. Diese Ausarbeitung soll einen Teil einer Produktfamilie vorstellen, welche solche oben beschriebenen Management-Tools bereitstellt. Es handelt sich um die Tivoli-Familie von IBM 1, welche diverse Management-Tools für Bereiche wie: Business Application, IT Mainframe Management, IT Process Management, IT Service Management, Security Management, Storage Management sowie Server, Network and Device Management bereitstellt [WiTiv06]. Dabei bedeutet Managment hier nicht nur eine Überwachung der Systeme, sondern beinhaltet auch wichtige Funktionen wie z.b.: das Verteilen von Software, das Inventarisieren von Systemen oder Datensicherungen. Im Fokus dieser Ausarbeitung stehen drei Tools zur Überwachung von Datenbanken und Automatisierung von Administrationsaufgaben. Namentlich wären das: Tivoli Monitoring for Databases, Tivoli Enterprise Console und der Tivoli Resource Model Builder. Dabei soll auf die Funktionsweise dieser Produkte eingegangen und die unterschiedlichen Ansätze zum Reagieren auf auftretende Probleme gezeigt werden. 1 Tivoli war ursprünglich ein eigenständiges Unternehmen mit Sitz in Austin (Texas), bevor es 1997 von IBM übernommen wurde [IBMTiv06]. 3

4 2 Tivoli Monitoring for Databases (ITM) In diesem Kapitel soll Tivoli Monitoring for Databases betrachtet werden. Dabei wird zum einen auf die Grundidee von ITM eingegangen, zum anderen wird erklärt, aus welchen Komponenten ITM besteht, wie diese zueinander in Beziehung stehen und wie die Informationsübermittelung vom zu überwachenden System bis hin zum Administrator erfolgt. 2.1 Grundidee IBM umschreibt den Grundgedanken von Tivoli Monitoring for Databases folgendermaßen [ITM61]: IBM Tivoli Monitoring for Databases soll Administratoren bei der Verwaltung krtischer Anwendungen unterstützen, indem es wichtige Systemressourcen proaktiv überwacht. Proaktiv bedeutet dabei, dass es nicht erst reagiert, wenn ein Fehler oder ein Engpass bereits eingetreten ist, sondern versucht Engpässe frühzeitig zu erkennen und rechtzeitig Entscheidungen zu treffen, um gar nicht erst gezwungen zu sein, Schadensreperatur betreiben zu müssen. Um dieses hohe Ziel zu erreichen, benutzt ITM das Ressourcen-Modell-Konzept, welches in Kapitel 3 genauer vorgestellt wird. Wichtig ist erst einmal nur, dass von dem Zielsystem permanent aktuelle Messwerte von diversen Ressourcen ermittelt und ausgewertet werden. Unter Ressourcen versteht man hier sowohl Hardwarekomponenten, wie z.b. verschiedene Speicher oder Prozessoren, als auch Anwendungen, die auf dem Zielsystem laufen. Die Auswertung geschieht dabei zum einen durch Vergleich mit festgelegten Schwellwerten, zum anderen durch Korrelation bestimmter auftretender Ereignisse. Auch Reaktionen können völlig unterschiedlich aussehen: von einfachen Benachrichtigungen bis hin zu komplexen Skripten, die viele Änderungen an den Parametern des Zielsystems vornehmen [ITM05]. 2.2 Architekturübersicht Abbildung 1 (aus [Bhe03]) beschreibt die allgemeine Architektur von IBM Tivoli Monitoring. ITM kann über die Einstellungen von Profile auf die zu überwachende Umgebung angepasst werden. Neben einigen wichtigen Informationen über das Zielsystem können hier auch diverse Views definiert werden, damit jeder Administrator einen individuellen Überblick über die Datenbank bzw. seinen Aufgabenbereich erhält. In der Workbench, welche Kernstück des Tivoli Resource Model Builders ist, werden Ressourcen-Modelle entworfen, erstellt und getestet. Ressourcen-Modelle dienen der Beschreibung einer zu überwachenden Ressource, hier werden bestimmte Schwellwerte festgelegt und es kann eingestellt werden, wann bei Schwellwertverletzungen eine entsprechende Information weitergereicht wird (mehr dazu in Kapitel 3). Die fertigen Ressourcen-Modelle werden dann an ITM übergeben, welches sie auf die entsprechenden Endknoten verteilt. Sobald die Ressourcen-Modelle auf ihren jeweiligen Endknoten installiert wurden, senden sie kontinuierlich aktuelle Daten über die zu überwachende Ressource zurück an ITM. Diese Daten können dann in Echtzeit auf der Web Health Console dargestellt werden. Außerdem ist es möglich, diese im Data Warehouse abzuspeichern, um statistische Untersuchungen durchzuführen. Die Tivoli Event Console bietet einerseits den 4

5 Abbildung 1: ITM Architekturübersicht Überblick über den aktuellen Systemzustand und außerdem werden hier alle eintretenden Ereignisse dargestellt und dem Admin wird ermöglicht auf diese zu reagieren. Abbildung 2: ITM Komponentenbeziehungen [ITM05] 2.3 Umsetzung Beteiligte Komponenten Auf dem Weg vom Endpunkt zum Administrator kann man die in Abbildung 2 dargestellten vier Komponenten unterscheiden [ITM05]: Tivoli Enterprise Portal Client Der Tivoli Enterprise Portal Client stellt ein javabasiertes Interface zur Überwachung eines Systems zur Verfügung. Dabei hat man die Wahl zwischen 5

6 einem Desktop- und einem Browsermode. Verschiedene Admins können über verschiedene Views Einfluss auf das zu überwachende System nehmen. Tivoli Enterprise Portal Server Alle Tivoli Enterprise Portal Clients sind mit dem Tivoli Enterprise Portal Server verbunden. Dieser stellt zum einen verschiedene Softwareservices zur Verfügung, die der Manipulation und Analyse von Daten dienen. Zum anderen findet hier auch die Sperrverwaltung für das Bearbeiten von aufgetretenen Problemen, um zu verhindern, dass mehrere Admins ungewollt das gleiche Problem bearbeiten. Tivoli Enterprise Monitoring Server Der Tivoli Enterprise Portal Server ist mit dem Tivoli Enterprise Monitoring Server verbunden. Dieser dient als Sammel- und Kontrollpunkt für sämtliche Alarme und Performancedaten, die durch die Tivoli Enterprise Monitoring Agents weitergereicht werden. Hier erfolgt auch die Korrelation der Daten, bevor sie an den Tivoli Enterprise Portal Server weitergereicht und von dort auf die entsprechenden Tivoli Enterprise Portal Clients verteilt werden. Tivoli Enterprise Monitoring Agents Die Tivoli Enterprise Monitoring Agents sind direkt auf dem zu überwachenden System installiert. Jeder dieser Agent sammelt permanent Daten über sein Zielsystem und reicht diese an den Tivoli Enterprise Monitoring Server. Außerdem vergleicht er die aktuellen Messwerte mit festgelegten Schwellwerten und sendet bei Überschreiten eine entsprechende Indikation. Solch eine Indikation nennt man in ITM Situation Situations und Reflexes Wie bereits eben angedeutet, beschreiben Situations bestimmte Zustände, in denen eine Schwellwertverletzung vorliegt. Im Normalfall ist das einmalige Überschreiten eines Schwellwertes noch nicht problematisch und wird meist nur durch einfache oder keine Reaktion beantwortet. Es ist möglich Situations miteinander zu korrelieren und dadurch komplexere Zustände zu beschreiben. Das Aufeinanderfolgen bestimmter Situations kann ein Event auslösen. Solch ein Event erscheint dann z.b. auf der Event Console eines Admins und wartet darauf, dass dieser sich darum kümmert. Es kann aber auch durch bestimmte Automatisierungen beantwortet werden. Eine Möglichkeit, wenn auch eine sehr einfache, auf Situations zu reagieren sind Reflexes. Dabei handelt es sich um einfache Befehle, wie z.b. das Erstellen eines Logfileeintrags, die Benachrichtigung eines Admins oder das Neusetzen eines Parameters. Allerdings erfolgt alles nach dem Fire and Forget Prinzip, d.h. es wird nicht geschaut, welchen Effekt die Reaktion hat. Dadurch kann es passieren, dass auf eine Situation immer wieder der gleiche Reflex erfolgt, sich der Zustand der Ressource aber nicht verbessert oder gar verschlechtert [ITM05] Policies Im Zuge der erweiterten Automatisierung stellt IBM Tivoli Monitoring for Databases Policies bereit. Diese ermöglichen es, auf ein eintretendes Event mit Activities zu antworten. Activities sind komplexe Ablaufpläne und Befehlsfolgen, mit denen es unter anderem möglich ist, Logfileeinträge auszuwerten, um damit z.b. Häufungen bestimmter Event zu bestimmten 6

7 Zeitpunkten festzustellen. Außerdem können viele Aktionen parallel und ressourcenübergreifend erfolgen, was bei den Reflexes nicht möglich war. Der wichtigste Vorteil von Policies gegenüber einfachen Reflexes ist jedoch, dass jede Actvity eine Rückmeldung seitens der Ressource auslöst, wodurch erkannt werden kann, welchen Einfluss die Activity auf die Ressource hatte. Danach kann dann weiter entschieden werden, ob weitere Activities folgen sollten oder ob es eventuell doch besser wäre, einen Admin zu benachrichtigen [ITM05]. 7

8 3 Resource Model In diesem Kapitel wird auf die Ressourcen-Modelle eingegangen, welche der Beschreibung des zu überwachenden Systems dienen. Es wird das Grundkonzept vorgestellt, danach wird auf die Komponenten eines jeden Ressourcen-Modells eingegangen und wie diese in der Workbench, welche zum erstellen und verändern von Ressourcen-Modellen dient, dargestellt werden. Ein abschließendes Beispiel zeigt dann, wie ein Ressourcen-Modell für DB2 aussehen kann. 3.1 Grundidee Tivoli Monitoring for Databases funktioniert nach dem Resource Model Concept. Ein Ressourcen- Modell besteht aus zwei Teilen: zum einen dem Dynamic Model und zum anderen dem Reference Model. Dabei wird das Common Information Model (CIM), ein objektorientierter Ansatz, um die Informationen über die zu managende Umgebung darzustellen, benutzt. CIM ist dabei eine anbieter- und plattformunabhängige Managementschnittstelle für verteilte Systeme und stellt ein Datenmodel zur Verfügung, um die Managementinformationen und Funktionen in einem Softwaresystem zu beschreiben [WiCIM06]. Für weiterführende Informationen zum CIM sei auf die Homepage der The Distributed Management Task Force, Inc. verwiesen [DMTF06]. Das Dynamic Model benutzt CIM-Klassen und CIM-Eigenschaften, um Ressourcen und Kennziffern dieser darzustellen. Außerdem werden Methoden bereitgestellt, die Zugriffe auf die Ressource beschreiben. Das Reference Model ist eine Entscheidungsprozedur (meist mit Java Script oder Visual Basic gecoded), welche: An Hand bestimmter Richtlinien und Schwellwerte aus dem Dynamic Model den Status der Ressource überwacht. Bei Überschreiten der Schwellwerte die Ursache des Problems lokalisiert. Versucht das Problem zu beheben. Entsprechende Performance-Daten in einer Log-Datei aufzeichnet. Mit dem Reference Model werden die kritischen Pfade der Datenbank beschrieben und es wird der aktuelle Zustand mit vordefinierten Werten verglichen, um bei Abweichungen vordefinierte Entscheidungen einzuleiten. Für jedes Problem wird ein seperates Ressourcen-Modell erzeugt, welches die besten Vorgehensweisen beinhaltet, um ein wohldefiniertes Problem zu finden und zu behandeln [Lanf03]. 3.2 Logische Komponenten Abbildung 3 (aus [Bhe03]) stellt den logischen Aufbau eines Ressourcen-Modells dar. Die wesentlichen Komponenten sind dabei: thresholds cycle time 8

9 occurences und holes Interface zur Datensammlung auf dem zu überwachenden System Das Zusammenspiel dieser soll im folgenden erklärt werden. Jedes Ressourcen-Modell besitzt einen oder mehrere Thresholds. In bestimmten Zeitabständen (Cycle Time) wird der aktuel- Abbildung 3: Logische Komponenten des Resource Models le Messwert mit dem Schwellwert verglichen, sollte es dabei zu einer Schwellwertverletzung kommen, wird eine Indikation ausgelöst. Dabei deutet die Grafik auch an, dass es möglich ist, mehrere Thresholds zu verbinden und eine Indikation erst zu starten, wenn mehrere Schwellwerte verletzt wurden. Das Auftreten bzw. Nichtauftreten einer Indikation wird durch occurences und holes dargestellt (mehr dazu in Abschnitt 3.3.3). Über ein Interface ermittelt das Ressourcen-Modell aktuelle Daten von der zu überwachenden Ressource und kann auch mittels Scripten Parameter an der Ressource verändern. Zum Zugriff auf Systemressourcen dient dabei meist Windows Management Instrumentation (WMI). Sobald sich bestimmte Indikationen häufen, wird von dem Ressourcen-Modelle aus ein Event an ITM bzw. TEC gesendet. Außerdem sieht man auf der Abbildung noch den Tivoli Desktop, mit dem sich grob Parameter über die zu überwachende Umgebung setzen lassen, sowie die Workbench, in der die Ressourcen-Modelle erstellt werden. 9

10 3.3 Aufbau in Workbench Sowohl IBM Tivoli Monitoring for Databases, als auch IBM Tivoli Enterprise Console liefern den Resource Model Builder mit. Kernstück des Resource Model Builders ist die Workbench. Jedes Ressourcen-Modell wird hier, in folgende Komponenten zerlegt, dargestellt [Bhe03]: Dynamic Model Reference Model Thresholds Events Parameters Logging Dependencies Decision tree script Nachfolgend sollen diese Komponenten näher beschrieben werden Dynamic Model Das Dynamic Model ist das Kernelement eines jeden Ressourcen-Modells. In ihm wird genau festgelegt, welche Ressourcen überwacht werden, ihre Eigenschaften und welche Form der Datensammlung benutzt werden soll. Es beinhaltet eine Reihe an vordefinierten CIM-Klassen, welche den Status jeder Ressource beschreiben. Wobei man sich hier unter einer Klasse eine Liste von möglichen Eigenschaften für eine bestimmte Ressource vorstellen muss. In der Workbench werden alle verfügbaren CIM-Klassen dargestellt. Wenn eine benötigte Ressource von keiner der vorhandenen Klassen beschrieben wird, ist es möglich diese selbst hinzuzufügen. Das folgende Code-Beispiel stellt ein Dynamic Model einer Festplatte dar [Bhe03]: Dynamic Model section <<DATA_INFO>> Svc.DefineClass "CIM", "TMW_PhysicalDisk", "ROOT\CIMV2:TMW_PhysicalDisk", "","AvgDiskSecXfer, PercentDiskWriteTime,AvgDiskBytesXfer,DiskXfersSec, PercentDiskReadTime,AvgDiskReadQLength, DiskReadBytesSec,DiskReadsSec,DiskBytesSec, CurrentDiskQLength,AvgDiskQLength,PercentDiskTime, AvgDiskWriteQLength,DiskWritesSec [...] <<\DATA_INFO>> Der Name des Modells ist: PhysicalDisk und es wird die entsprechende CIM-Klasse TMW PhysicalDisk benutzt. Danach folgt eine Aufzählung der Eigenschaften der Festplatte. Diese beinhaltet Speicherangaben, Zugriffszeiten, Datenübertragungszeiten, Schreib- und Lesegeschwindigkeiten und noch einige weitere wichtige Information, die es ermöglichen, die Ressource sehr detailliert zu beschreiben. 10

11 3.3.2 Thresholds In jedem Ressourcen-Modell werden ein oder mehrere Schwellwerte festgelegt. Sie definieren den Bereich innerhalb dessen die Ressource wie gewünscht arbeitet bzw. normal ausgelastet ist. Sollte dieser Bereich verlassen werden, wird eine Indikation gestartet, das heißt, das System wird auf dieses Fehlverhalten hingewiesen. Im Normalfall erfolgt hier noch keine Reaktion, da das einmalige Überschreiten eines Schwellwertes noch nicht auf einen größeren Systemfehler hinweisen muss. Abbildung 4: Beispielhafter zeitlicher Verlauf eines Messwertes Events Als Event bezeichnet man einen Statuswechsel einer Ressource. Dies ist z.b. der Fall, wenn mehrfach bestimmte Schwellwerte überschritten wurden und dadurch der Ressourcen-Status abnormal oder problematisch wird. In der Workbench wird unterschieden zwischen einem Event und einer Indikation. Dabei ist ein Event eine Ansammlung von zuvor aufgetretenen Indikationen und meist Auslöser mehrerer eingreifender Aktionen. Die Überwachungen werden in bestimmte Kontrollzyklen aufgeteilt. Kontrollzyklen, in denen Indikatoren auftreten, werden als occurences bezeichnet. Wenn keine Indikatoren auftreten, bezeichnet man den Zyklus als hole. Dadurch lässt sich relativ genau beschreiben, wann der Zustand einer Ressource normal ist, wann er abnormal ist oder wann er sich nach mehreren Schwellwertverletzungen wieder in einem normalen Zustand befindet. In Abbildung 4 (aus [Bhe03]) wird der zeitliche Verlauf eines Messwertes betrachtet. Man sieht, dass diese Messung in bestimmte Kontrollzyklen eingeteilt ist und man erkennt auch den Schwellwert. Die Messwerte überschreiten den Schwellwert mehrfach, jedoch fallen sie danach für einen kompletten Kontrollzyklus wieder in den normalen Bereich zurück. Jede Überschreitung löst eine Indikaton aus. Obwohl zwischen jedem Indikator ein hole liegt, werden hier die Überschreitungen mitgezählt, da in diesem Beispiel der Zähler der Überschreitungen erst wieder auf null gesetzt wird, wenn zwei holes unmittelbar hintereinander auftreten. Also über zwei aufeinander folgende Kontrollzyklen keine Schwellwertverletzung vorliegt. Dieser Fall tritt am Ende der Grafik ein. 11

12 Was dieses Beispiel veranschaulichen sollte, ist, dass man sehr genau definieren kann, wann ein Event ausgelöst wird, um unnötige Fehlalarme zu vermeiden Parameters Während Schwellwerte nur numerische Werte annehmen dürfen, kann man mit Hilfe von Parametern auch Zahlenlisten oder Stringwerte benutzen und dadurch das Ressourcen-Modell noch detailierter beschreiben Logging Wie der Name schon verrät ist es hier möglich zu definieren, welche Informationen in einer Logdatei gespeichert werden sollen. Auch hier ist es möglich, sehr detailiert zu beschreiben, welche Informationen den Nutzer interessieren und damit in die Logdatei gespeichert werden sollen Decision Tree Script Im Decision Tree Script wird der Algorithmus beschrieben, der den gesamten Überwachungsprozess steuert. Die verwendete Sprache hierbei ist entweder Visual Basic oder Java Script. Außerdem werden hier mögliche Aktionen als Folge von auftretenden Events festgelegt. Die Workbench erstellt diesen Code automatisch in Echtzeit, während der Benutzer seine Einstellungen bezüglich der Schwellwerte, Event usw. trifft. Allerdings ist es auch hier wieder möglich, eigenen Code einzubinden. Dabei ist zu beachten, dass man sich an die vorgegebene Struktur hält. Mehr dazu finden Sie in [Bhe03]. Das nachfolgende Codebeispiel (aus [Bhe03]) zeigt den Aufbau eines Decision Tree Scripts. In der Thresholds section wird festgelegt, welcher Schwellwert betrachtet werden soll. Die Event definition section definiert die möglichen Events, die gestartet werden. In dem dritten Bereich erfolgt die eigentliche Verknüpfung zwischen den Schwellwerten und den Events, indem gesagt wird, wie auf Schwellwertverletzungen reagiert wird. Thresholds section <<THRESHOLDS_INFO>> Svc.DefineThreshold "Thr_Avail_le", <<\THRESHOLDS_INFO>> ##### omission ##### Event definition section <<EVENTS_INFO>> Svc.DefineEvent "Ev_TMW_Memory_Avail_is_equal_or_too_low", "Avail,LowerBound", " RELPATH" <<\EVENTS_INFO>> ##### omission ##### If (curavail <= Svc.GetThreshold("Thr_Avail_le") ) Then Svc.SetMapNumElement(hPropTable,"LowerBound", Svc.GetThreshold("Thr_Avail_le")), Svc.SendEventEx "Ev_TMW_Memory_Avail_is_equal_or_too_low" End If 12

13 3.3.7 Dependencies Es kann vorkommen, dass auf einem Endknoten, auf dem ein Ressourcen-Modell laufen soll, bestimmte Dateien (z.b. Treiber, andere Ressourcen-Modelle,...), welche zur Erstellung und den Betrieb des Ressourcen-Modells benötigt werden, nicht vorhanden sind. Mit Hilfe der Dependencies ist es möglich, solche Abhängigkeiten zu definieren. Entsprechende Dateien werden dann immer zusammen mit dem Ressourcen-Modell weitergereicht. 3.4 Beispiel eines Ressourcen-Modells Nachfolgend wird beispielhaft das Ressourcen-Modell DB2 Locks and Deadlocks vorgestellt (aus [Dar02]). Dieses ist eines der vielen Ressourcen-Modelle, die bereits fertig mit IBM Tivoli Monitoring for Databases mitgeliefert werden. Wie der Name bereits erahnen lässt, werden hier Sperren und vor allem Deadlocks überwacht. Das Auftreten eines Deadlocks zwingt das System die Ausführung bestimmter Transaktionen zu stoppen und mindestens eine Transaktion per Roll Back zurückzusetzen, was die Effektivität der Datenbank stark beeinträchtigt. Wobei hier nicht einzeln auftretende Deadlocks das Problem sind, sondern eine Regelmässigkeit in der Häufung von Deadlocks erkannt und darauf reagiert werden soll. Das DB2 Locks and Deadlocks Ressourcen-Modell überwacht dabei folgende Daten: Die durchschnittliche Zahl von Sperren, die von jeder aktuell laufenden Anwendung gehalten wird. Die Anzahl der Sperr- bzw. Deadlockeskalationen, die in der Datenbank während des letzten Überwachungsintervall aufgetreten sind. Wie oft eine Anfrage auf Sperre nicht gewährt wurde und statt dessen während des Überwachungsintervalls als timed out geführt wurde. Der Prozentsatz an Rollbacks, die durch einen Deadlock verursacht wurden, während des letzten Überwachungsintervalls. Die Anzahl der Sperr- bzw. Deadlockeskalationen, die für eine Anwendung während des Überwachungsintervalls auftraten. Der Prozentsatz an Rollbacks, die insgesamt durch einen Deadlock verursacht wurden. Der Prozentsatz an Speicher, der in der Sperrliste von der Datenbank oder der Anwendung belegt wird. Die durchschnittliche Anzahl von Sperreskalationen pro Verbindung. Weiterhin folgen hier die vom Ressourcen-Modell bereitgestellten Indikatoren, die durch das Überschreiten bestimmter Schwellwerte aufgerufen werden: Application Deadlocks too high Average Lock Escalations Per Connection too high Average Locks Held Per Application too high Deadlocks Delta too high Lock Escalations by an Application too high 13

14 Lock Escalations Delta too high Lock Timeouts Delta too high Percent Deadlock Rollbacks too high Percent Lock List Used By An Application too high Percent Lock List Used in a database too high Außerdem gibt es eine Liste, in der verzeichnet ist, wie auf einen auftretenden Indikator reagiert wird. Im Falle der Average Locks Held Per Application too high Indikation würde z.b. die folgende Nachricht ausgegeben werden: The Average Locks Held Per Application on DB2 Database <db2database>, Instance <db2instance>, Node <db2node> is <AvgLocksHeld>, which is higher than <UpperBound>. Es wird beschrieben, um was für einen Fehler es sich handelt, warum er aufgetreten ist und wo er aufgetreten ist. Wie bereits in Abschnitt 2.1 erwähnt, ist es auch möglich komplexere Anweisungen ausführen zu lassen. Dies wird vor allem bei kritischen Ereignissen wie zum Beispiel nach einer Percent Deadlock Rollbacks too high Indikation getan. 14

15 4 Tivoli Enterprise Console (TEC) 4.1 Architekturübersicht Dieser Abschnitt beschäftigt sich mit dem Aufbau der Tivoli Enterprise Console. Dabei soll auf die wichtigsten Komponenten näher eingegangen werden, Abbildung 5 (aus [TEC39]) zeigt die Beziehungen zwischen diesen. Abbildung 5: TEC Architekturübersicht Adapter Configuration Facility Das Adapter Configuration Facility bietet eine grafische Oberfläche, um Tivoli Management Environment (TME) Adapter zu konfigurieren und zu verteilen. Es lassen sich Profile für verschiedene Adapter erstellen und damit bestimmte Konfigurations- und Distributionseinstellungen treffen. Dadurch ist es möglich, ganz zentral Änderungen in der Konfiguration zu treffen und diese sofort an alle betreffenden Endknoten zu verteilen [TEC39]. 15

16 4.1.2 Event Adapter Ein Event Adapter ist ein Prozess, der auf dem gleichen System läuft, wie eine zu überwachende Quelle und diese auf das Vorkommen bestimmter Ereignisse überwacht. Quellen sind hier zum einen Anwendungen und zum anderen Systemressourcen. Ein Event Adapter ist für jede Ressource bzw. Anwendung nötig, die durch die Enterprise Console überwacht werden soll. Wenn der Event Adapter eine Information von seiner Quelle erhält, passt er das Format dieser Information an einen bestimmten Standard an und reicht diese Information weiter an den Event Server, damit dieser die Information interpretieren und darauf reagieren kann. Natürlich ist es auch hier möglich, sehr genau einzustellen, welche Informationen weitergereicht und welche einfach ignoriert werden. Tivoli liefert bereits Event Adapter für die meisten Quellen mit und durch Einsatz des Tivoli Event Integration Facility ist es möglich, eigene Event Adapter zu erzeugen. Des weiteren kann der Adapter Ereignisse auch zwischenspeichern z.b. für den Fall, dass keine Verbindung zum Event Server besteht [TEC39] Tivoli Event Integration Facility Wie bereits in Abschnitt erwähnt, ermöglicht dieses Tool eine Erweiterung der möglichen zu überwachenden Ereignisse und Systemressourcen, durch ds Erstellen neuer Event Adapter. Es ist zum einen möglich, eigene Event Adapter zu erzeugen, die exakt den Bedürfnissen und Wünschen des jeweiligen Administrators bzw. der jeweiligen Systemumgebung entsprechen, gleichzeitig kann man aber auch vorhandene Event Adapter modifizieren [TEC39] Tivoli Enterprise Console Gateway Die Tivoli Enterprise Console Gateway erhält Ereignisse von TME- und Nicht-TME-Adaptern und reicht diese an den betreffenden Event Server weiter. Tivoli Enterprise Console Gateway bietet dabei folgende Vorteile [TEC39]: Bessere Performance für den Event Server, da Tivoli Enterprise Console Gateway Ereignisse erst bündelt, bevor sie weitergereicht werden und dadurch weniger Traffic entsteht. Einfaches Einrichten von Adaptern bzw. Updates für diese in den Endpunkten mit Hilfe der Profile aus der Adapter Configuration Facility. Entlastung des Event Servers, da Aufgaben wie Event Correlation und Filterung näher an der Quelle durchgeführt werden Tivoli NetView Tivoli NetView überwacht den Status aller Netzwerkkomponenten, filtert automatisch netzwerkbetreffende Ereignisse und reicht diese entsprechend weiter [TEC39]. Da es üblich ist, dass es in größeren Firmen eigene Administratoren zur Betreuung des Netzwerks gibt, ermöglicht dieses Herausfiltern an Informationen eine bessere Aufgabenverteilung. Außerdem bietet Netview einen Echtzeitüberblick über das gesamte Netzwerk. Dadurch lassen Ausfälle oder Engpässe in der Netzwerkinfrastruktur erkennen und beseitigen Event Server Der Event Server dient der zentralen Verarbeitung von Ereignissen in einer verteilten Umgebung. Er bekommt Informationen zu Ereignissen von allen beteiligten System und hält die Event Database aktu- 16

17 ell. Für jedes eintreffende Ereignis erzeugt der Event Server einen Eintrag in der Datenbank und entscheidet dann anhand bestimmter Regeln, ob er bestimmte vordefinierte Aktionen einleiten soll oder anders mit dem Ereignis verfahren soll. Sollte z.b. menschliches Eingreifen erforderlich sein, so informiert er den entsprechenden Administrator. Dieser erledigt dann die entsprechenden Aufgabe und informiert den Event Server, wenn das Problem behoben ist [TEC39] Event Database Es ist offensichtlich, dass bei der Überwachung sämtlicher IT-Infrastruktur eines Unternehmens, riesige Datenmengen anfallen. Tivoli Enterprise Console benutzt ein externes Relationales Datenbankmanagmentsystem, um diese Unmengen an Ereignisdaten zu verwalten [TEC39]. Abbildung 6: Kombination von TEC mit ITM User Interface Server Der User Interface (UI) Server dient der Kommunikation zwischen den Event Consoles und dem Event Server. Er verhindert auch, dass verschiedene Event Consoles auf das gleiche Ereignis reagieren. Außerdem updatet er automatisch den Status bestimmter Ereignisse. Diverse Befehle ermöglichen es einem Administrator, die Eigenschaften bestimmter Ereignisse zu ändern, Ereignisse bestimmten Ereignissgruppen zuzuordnen oder eine Nachricht an den Administrator zu schicken [TEC39] Event Console Die Event Console bietet eine grafische Oberfläche, die es Administratoren erlaubt, bestimmte Ereignisse zu betrachten und darauf zu reagieren. Es werden zwei Versionen dieser Konsole bereitgestellt: die etwas mächtigere Javaversion und die Webversion. Es ist möglich, verschiedene Views zu definieren, so dass jedem Admin nur die Ereignisse zugeteilt werden, die ihn auch betreffen [TEC39]. 4.2 Kombination mit ITM In Abbildung 6 (aus [ITM05]) wird gezeigt an welchen Stellen TEC mit ITM kombiniert werden kann bzw. eingreifend wirkt. Der TEC Event Server erhält Informationen über entstandene Events von dem ITM Monitoring Server, dieser wirkt also wie ein Console Gateway (siehe Abschnitt 4.1.4). Nach dem Auswerten dieser Events verteilt der TEC Event Server entsprechende Benachrichtigungen 17

18 oder zu lösende Aufgaben an die ITM Portal Clients, wo dann die zuständigen Admins, wie gewohnt, reagieren können. Der wesentliche Vorteil hierbei ist die mächtigere Korrelationengine von TEC gegenüber ITM. Außerdem ermöglicht diese zentrale Auswertung zusammen mit anderen Systemteilen (andere Server, Netzwerkkomponenten, usw.) eine viel genauere Fehlerlokation. Der ITM Portal Server wird bei der Verwendung von TEC nicht zwingend überflüssig, z.b. könnte man den TEC Event Server nur bestimmte Events auswerten lassen und andere Events wie gewohnt komplett innerhalb von ITM belassen. Abbildung 7: Codebeispiel Rule Set 4.3 Rule Sets In ITM erfolgte die Eventauswertung mittels Reflexes und Policies, TEC benutzt hierfür Rule Sets. Mit Hilfe von Rule Sets sind wesentliche komplexere Korrelationen möglich. Da TEC nicht nur zur Überwachung einer Datenbank, sondern einer kompletten IT-Infrastruktur gedacht ist, können Auswertungen über verschiedenste Systemkomponenten erfolgen (Netzwerk, Energieversorgung, diverse andere Applikationen, usw.). Außerdem ermöglichen Rule Sets das Auswerten von Logfile-Informationen und zeitbasiertes Auswerten, das heißt z.b. es wird sehr genau geschaut, wie schnell sich eine Reaktion auswirkt. Allgemein sind viel komplexere Reaktionen möglich, parallel auf vielen verschiedenen Systemen bzw. Anwendungen. Rule Sets sind prologbasiert, das Beispiel in Abbildung 7 (aus [RulDev03]) zeigt den groben Aufbau einer Rule. Zu Beginn wird der Rule Type und der Rule Name festgelegt. Beim Rule Type handelt es sich um eine grobe Einordnung, um welche Art von Rule es sich handelt, denkbar sind z.b. Correlation Rules, Cleanup Rules (zum beseitigen unwichtiger Events)oder Change Rules (verändern Event Eigenschaften). Mehr zu den verschiedenen Rule Types finden 18

19 Sie in [RulDev03]. Im Descripton -Teil erfolgt eine kurze Verbale Beschreibung, wozu diese Rule dient. Der Eventfilter beschreibt genau, welche Ereignisse alles Beachtung finden sollen. Dabei werden zum einen die Eventklasse und zum anderen die genauen Eventattribute unterschieden. Sollten die Eventattribute den entsprechenden Wert annehmen, wird mit der beschriebenen Action reagiert. 19

20 ITM TEC Reflexes Policies Rule Sets einfache Reaktionen (z.b. Benachrichtigungen) Komplexe Reaktionen Auswerten des Effektes einer Reaktion Korrelieren mit Events aus Logdateien Korrelieren mit Events anderer Systeme Eskalationsbehandlung Trouble Ticket Support Zusammenfassung Tabelle 1: Vergleich Reflexes, Policies und Rule Sets Diese Ausarbeitung sollte gezeigt haben, dass eine Kombination von IBM Tivoli Monitoring for Databases und IBM Tivoli Enterprise Console ein mächtiges Werkzeug zum Überwachen einer Datenbank darstellt. Dem Administrator werden viele Routineaufgaben abgenommen und ihm bleibt dadurch mehr Zeit für andere Aufgaben. In Tabelle 1 sollen noch einmal die wesentlichen Vorzüge der Reaktionsmöglichkeiten auf ein Event dargestellt werden. Trotzdem bleibt noch viel Spielraum für Verbesserungen und weitere Automationen, wie vor allem durch die anderen Vorträge gezeigt wurde, die mögliche Theorien vorgestellt hatten. 20

21 Literatur [Bhe03] T. Bhe, K. Inayama, C. Lister, M. Parlione and M. Vesich, IBM Tivoli Monitoring Version Creating Resource Models and Providers, Redbooks (ibm.com/redbooks), August [Dar02] B. Darmawan, B. Jacob, E. Manoel, E. Rahim and B. S. Shamshabad, IBM Tivoli Monitoring for Databases: DB2 - An Overview, Redbooks Paper (ibm.com/redbooks), October 30, [DMTF06] [EvCor06] [Guc06] [IBMTEC06] [IBMTiv06] [ITM02] [ITM05] [ITM61] [Lanf03] [RulDev03] [TEC39] [WiCIM06] [WiTiv06] The Distributed Management Task Force, Inc., URL: Events Correlation - Correlation with the Tivoli Enterprise Console, events correlation.shtml.htm V. Gucer, C. Beganskas, A. Godoy, D. A. Perpetua, A. Shaheen, J. Shamroski and J. Willis, Certification Guide Series: IBM Tivoli Monitoring V6.1, Redbooks (ibm.com/redbooks), February IBM - Tivoli Enterprise Console URL: DE/products/ D106133T04676R57.html IBM - Tivoli Website - Overview, URL: IBM Tivoli Monitoring for Databases: DB2 - Reference Guide Version 5.1.0, First Edition (September 2002) IBM Tivoli Monitoring User s Guide Version 6.1.0, November Plattformübergreifende Überwachung und Verwaltung kritischer Ressourcen und Messwerte über eine zentrale Konsole - IBM Tivoli Monitoring, Version 6.1, ibm.com/tivoli. G. Lanfranchi, P. Della Peruta, A. Perrone and D. Calvanese, Toward a new landscape of systems management in an autonomic computing environment, IBM SYSTEMS JOURNAL, VOL 42, NO 1, 2003, pp IBM Tivoli Enterprise Console Rule Developer s Guide Version 3.9, August 2003 IBM Tivoli Enterprise Console User s Guide Version 3.9, August Wikipedia.de - Common Information Model URL: Information Model Wikipedia.de - Tivoli (IBM), URL: (IBM) 21