Kapitel 3

3. Tivoli Management Environment (Überblick)

Zunächst ein kleiner Überblick über den Aufbau und die Struktur von Tivoli und einen kleinen Einblick in die Möglichkeiten, die sich mit Tivoli bieten, außerdem eine kurze Beschreibung der wichtigsten Elemente und Komponenten.

3.1 Aufbau und Organisation

Der wichtigste Bestandteil von Tivoli ist der zentrale Systemmanagement Server. Dieser Server bildet die zentrale Schaltstelle des gesamten Systems. Das dort installierte "Tivoli Management Framework" (TMF) bedient alle angeschlossenen Clients und löst alle erforderlichen Aktionen aus.

In einer Umgebung können auch jederzeit mehrere Server gleichzeitig arbeiten. Diese sogenannten TMR-Server (Tivoli Management Region Server) können jeweils andere Clients steuern, so daß die Last gleichmäßig verteilt werden kann.

Bedient wird das System über den sogenannten "Tivoli Desktop". Dieses Programm ist die Schnittstelle zum Server, von hier aus können nahezu alle Funktionen des TME ausgeführt und konfiguriert werden.

Abbildung 1: Der Tivoli Desktop

Alternativ ist aber auch eine komplette Bedienung über Kommandozeilen-Befehle (Comand Line Interface, CLI) möglich, was sich auch ideal für die Automatisierung durch Perl- und Shell-Scripte nutzen läßt.

Auf dem Desktop, der ähnlich dem Windows Arbeitsplatz in einer hierarchischen Struktur organisiert ist, sind alle Funktionen des Servers sichtbar. Alle in Tivoli eingebundenen Computer (d.h. Clients und Server) erscheinen dort als ein eigenes Symbol.

Eine Gruppierung ist ähnlich einer Ordnerstruktur in sogenannten "Policy Regions" möglich, wodurch eine einfache Zusammenfassung von Rechnern in Gruppen möglich ist.

Alle weiteren Funktionen, wie etwa Remote Control und Inventory, erscheinen ebenfalls als Symbol auf dem Desktop und lassen sich entweder per Menü oder per Drag & Drop auslösen und konfigurieren.

Um einen Rechner in Tivoli einbinden zu können, muß dort lokal ein zusätzlicher Dienst installiert werden, der sogenannte "TME Agent". Über diesen Agenten stellt der Server die Verbindung zu den Clients her.

Zur Installation eines Clients stehen zwei verschiedene Varianten zur Verfügung: "PC-Managed Node" und "Managed Node". Ersterer ist die Standardinstallation für Office-PCs, er ermöglicht die Grundfunktionen wie etwa Remote Control, Softwareverteilung und Inventarisierung. Will man den Rechner zusätzlich aber noch überwachen, ist eine Installation als "Managed Node" notwendig.

3.2 Administration und Sicherheitseinrichtungen

Jeder Anwender, der mit Tivoli arbeiten will, muß dort als Tivoli-Administrator angelegt werden. Aufgrund dieser individuellen Anlage von Benutzern ist es möglich, die Sicherheitsrichtlinien für jeden Administrator getrennt anzulegen. Man kann also den Zugang für jeden Anwender einzeln auf bestimmte Bereiche oder Policy Regions beschränken, oder ihm nur Zugang zu bestimmten Funktionen gestatten. Im Gegensatz dazu bieten manche Produkte den Zugang nur auf Paßwortebene an, wodurch natürlich der Mißbrauch der Funktionen um so gefährlicher wird. Die Vor-Ort-Betreuer sollen wirklich nur Zugriff auf die PCs ihrer eigenen Abteilung haben, sonst muß alles gesperrt sein.

So dürfen beispielsweise manche Anwender zwar einen Rechner per Remote Control steuern, der Zugang auf die Inventarisierungsdaten kann aber verwehrt werden. Ebenso gibt es auch verschiedene Benutzerstufen, vom normalen "User" über den "Admin" bis hin zum "Super-" und "Senior-" Administrator.

3.3 Remote Control

Die Remote Control Funktionalität kann grob in drei Bereiche unterteilt werden: Controlling, Monitoring und Reboot.

Abbildung 2: Startdialog für Remote Control

Ersteres meint die komplette Steuerung des fremden Rechners über den eigenen Bildschirm und die eigene Tastatur; Monitoring ist die reine Beobachtung des anderen Rechners ohne Eingriffsmöglichkeiten; mit der Reboot-Funktion kann man einen Rechner jederzeit neu starten.

Die entsprechenden Rechte vorausgesetzt kann der Administrator jederzeit zwischen den Funktionen Monitoring und Controlling umschalten.

Aber auch der Anwender, der vor dem kontrollierten Rechner sitzt, hat jederzeit die Möglichkeit, die Überwachung umzuschalten oder die Verbindung komplett zu unterbrechen.

3.4 Softwareverteilung

Regelmäßig erscheinen neue Updates, neue Programmversionen und Service Packs. Ständig gibt es neue Treiberversionen und Bug Fixes. Immer wieder gibt es komplett neue Programme. Für einen reibungslosen Betrieb in einem derart großen Netzwerk, wie es im Regensburger BMW Werk existiert, muß natürlich dafür gesorgt werden, daß alle Rechner mit einem annähernd gleichen Versionsstand arbeiten, denn oft sind die verschiedenen Versionen ein und desselben Produkts zueinander nicht 100-prozentig kompatibel und speziell in Netzwerken mit einem hohen Kommunikationsaufkommen via E-Mail machen sich diese Unterschiede bemerkbar.

Wenn beispielsweise ein Anwender seine Dokumente in Microsoft Office 97 erstellt und diese dann mit dem BMW-internen Mail-System verschickt, ist mit Sicherheit eine Menge Ärger vorprogrammiert, da die meisten Empfänger mit der Datei nichts anfangen können (Werksweites Standardprodukt ist Microsoft Office 95).

Es muß also dafür gesorgt werden, daß ein einheitlicher Installationsstandard existiert. Bisher mußten die Programme alle vor Ort und von Hand installiert werden, bei über 1500 PC natürlich eine Menge Arbeit. Und speziell bei größeren Updates (beispielsweise beim Umstieg von Microsoft Office 4.x auf Microsoft Office 95) muß diese Umstellung so schnell wie möglich vonstatten gehen, damit ein reibungsloser Datenaustausch gewährleistet ist.

Für diese Problematik gibt es in Tivoli die Möglichkeit, Programme mittels "Software Distribution" oder "Softwareverteilung" von einer zentralen Stelle aus zu installieren. Dazu müssen die Programme in ein sogenanntes "FilePack" umgewandelt und in den Tivoli Server eingebunden werden.

Ist dies geschehen, kann die Installation der Software auf den Clients vom "Tivoli Desktop" aus per Drag & Drop erledigt werden.

Um das Netzwerk nicht zu überlasten ist auch die Möglichkeit gegeben, diese Verteilung mittels eines Schedulers zu einem bestimmten Zeitpunkt auszuführen. Die aktuelle Version des Tivoli Framework bietet leider noch keine Möglichkeit, Software automatisch beim Einschalten des Clients auf diesen Rechner aufzuspielen. Dies wird voraussichtlich in der nächsten Version implementierbar sein, bei der beim Anmelden eines Rechners ein Skript gestartet werden kann, das diese und andere Aufgaben erledigen kann.

Außerdem kann über ein Repeater-Konzept das Netzwerk stark entlastet werden. Dabei wird beispielsweise in jedem Subnetz ein Rechner als Repeater definiert. Bei der Verteilung kopiert der Server zunächst die Pakete auf die repeater und erst diese übertragen es weiter auf die Clients.

3.5 Inventarisierung

Mit der Inventarisierung hat man die Möglichkeit, alle in das TME eingebundenen Rechner (d.h. Clients und Server, mit allen Betriebssystemen) in einer Oracle-Datenbank zu katalogisieren.

Mitprotokolliert werden bei der Inventarisierung sowohl Hardware als auch Software, das Spektrum reicht dabei vom installierten Prozessor über Grafikkarten und Arbeitsspeicher bis hin zu einzelnen Softwareprodukten. Eine Abfrage der Daten ist dann in eingeschränkter Form für einen schnellen Überblick direkt über den Tivoli Desktop möglich oder aber per SQL direkt aus der Datenbank heraus.

Beim Scannen der Software kann genau eingeschränkt werden, was eingelesen werden soll. Man kann entweder alle Dateien mit einer speziellen Endung einlesen (beispielsweise alle EXE oder COM Dateien), oder man kann nur bestimmte Produkte überprüfen. Letzteres verwendet einfach den Dateinamen des Programms zur Identifizierung, eine Zuordnung zur Versionsnummer ist dann anhand der Dateigröße möglich.

Diese Möglichkeit ist natürlich sehr zeitaufwendig, da zunächst eine umfangreiche Tabelle mit allen möglichen Programmen und Versionen angelegt werden muß. Andererseits wird dadurch aber die Datenbank und das Netzwerk sehr stark entlastet, da keine so großen Datenmengen über das Netzwerk übertragen werden müssen. Vor allem bei einer Inventarisierung von über 1500 Rechnern macht sich dies natürlich stark bemerkbar.

Da bei Tivoli alle Systeme miteinander zusammenarbeiten können, kann hier beispielsweise die Inventarisierung direkt mit der Softwareverteilung gekoppelt werden und so die Software nur auf bestimmten Rechnern installiert werden, die aus einer Abfrage der Inventardaten hervorgehen. Verbindet man diese Funktionalität mit dem automatischen Start eines Skripts, was, wie schon erwähnt, erst in der nächsten Tivoli Version möglich ist, so steht einem werksweiten Update nichts mehr im Wege, da auch ausgeschaltete Rechner das Update nachholen, sobald sie das nächste mal gestartet werden.

3.6 Überwachungs- und Reaktionsmöglichkeiten

Der umfangreichste und auch komplexeste Teil des Systems ist die Möglichkeit zur Überwachung von Systemen mit sogenannten "Sentries" oder "Monitoren" (nicht zu verwechseln mit Remote Monitoring). Mitgeliefert werden mit Tivoli bereits zahlreiche Monitore für unterschiedlichste Überwachungen. Dazu gehören beispielsweise:

• Dateisysteme, Festplatten oder einzelne Dateien
• Programme und Prozesse, Daemonprozesse (Unix) und Dienste (Windows)
• Netzwerkaktivitäten und Auslastungen (z.B. Load Average)
• Verfügbarkeit (Heartbeat, ping)

Abbildung 3: Liste diverser Überwachungsskripte

Mit Hilfe dieser Monitore kann bereits ein großer Teil der notwendigen Überwachung erledigt werden. Falls das aber nicht ausreicht, kann jederzeit ein beliebiges Skript in einer beliebigen Programmiersprache zusätzlich als Überwachung herangezogen werden.

Diese Monitore können sehr umfangreich parametrisiert werden und es können spezielle Reaktionen mit angegeben werden. Dazu gehört unter anderem:

• Senden einer Nachricht an ein Tivoli-internes Notice-Board
• Öffnen eines PopUp-Fensters auf dem Tivoli Desktop eines Administrators
• Versenden einer E-Mail
• Ausführen eines Programms auf einem beliebigen Rechner
• Protokollieren des Fehlers in einer Logdatei

3.7 Tivoli Enterprise Console

Die Tivoli Enterprise Console, oder auch kurz "T/EC", ist ein weiteres zentrales Element im Tivoli System. Die T/EC ist eine zentrale Auflaufstelle für aufgetretene Fehler und Events.

Jedesmal, wenn ein Überwachungsmonitor anschlägt, kann automatisch ein Event in der T/EC erzeugt werden. Hier können die Fehler dann priorisiert und weitere Aktionen unabhängig vom Monitor selbst eingeleitet werden.

Ein weiterer wichtiger Aspekt ist hier die Definition von sogenannten Korrelationen, d.h. die Einstufung eines Events kann von anderen Events oder Eventgruppen abhängig gemacht werden.

Wenn beispielsweise das System bemerkt, daß ein Router in einem Subnetz ausgefallen ist, kann daraus automatisch abgeleitet werden, daß die im Subnetzt befindlichen Server ebenfalls nicht erreichbar sind. Ohne diese Korrelation würden sowohl Netzwerkbetreuer für den Router als auch Systemadministrator alarmiert, obwohl eigentlich nur das Netzwerk betroffen ist. Bei einer richtigen Konfiguration wird aber nur der Netzwerkadministrator alarmiert und der Server-Administrator erhält lediglich eine Hinweismeldung. So weiß er dann, daß sein Server zwar nicht erreichbar ist, aber der Server selbst daran nicht schuld ist.

In Verbindung mit der T/EC gibt es noch andere Überwachungsmöglichkeiten, die mit Hilfe von Monitoren nicht so einfach lösbar wären. Für die Enterprise Console gibt es spezielle Adapterprogramme, die Logdateien aller Art auswerten können.

Beispielsweise gibt es bereits einige Adapter zum Auslesen der "AIX Error Log" oder der "Windows NT Ereignisanzeige".

3.8 Zusammenfassung

Die oben genannten Elemente bilden nur einen Teil des Funktionsumfangs des TME ab. Aber selbst an diesem stark vereinfachten Überblick kann man mit Sicherheit die Fülle und Komplexität des gesamten Systems erkennen.

Wie bereits angedeutet arbeiten alle Elemente und Komponenten in Tivoli direkt zusammen. So kann ein Überwachungsmonitor jederzeit einen Event in der T/EC erzeugen, oder für die Softwareverteilung kann man auf die Daten des Inventory zugreifen.

Noch weiter geht das Ganze, wenn man andere Zusatzprodukte einbindet, wie etwa NetView 6000 von IBM, ein Tool zum Netzwerkmanagement. Dann kann man beispielsweise die Softwareverteilung so steuern, daß nur maximal 20% der Netzwerklast dadurch belegt werden dürfen.

Aufgrund dieser Komplexität muß der zentrale Administrator auf jeden Fall einen Großteil seiner Zeit für die Konfiguration der einzelnen Komponenten einplanen. Kein System funktioniert von alleine und erst eine richtig durchgeführte und geplante Konfiguration kann alle gegebenen Möglichkeiten voll ausnutzen.

Alle Komponenten arbeiten zwar auch einzeln und unabhängig voneinander, aber erst durch die Zusammenarbeit der Produkte wird der Aufbau und Betrieb eines Systemmanagement Systems so interessant.