Bei der Automation eines Rechenzentrums kommt es neben der ausführlichen Planungsphase unter Einbeziehung aller Betroffenen auf folgende entscheidende Punkte an:

Auswahl des geeigneten Produkts

- Erfüllen der funktionalen Anforderungen,

- Einhaltung des zugrundegelegten Standards,

- umfangreiche Herstellerunterstützung,

- Integrations- und Anschlußmöglichkeit an vorhandene oder neu zu beschaffende System-Monitore.

Implementierung des Produkts und der entwickelten Prozeduren

- Konsolmeldungen,

- Workload,

- Backup,

- Service-Level-Vereinbarungen.

Steuerung des Rechenzentrums von außen

- Schnittstelle Automation

- Remote-Steuerung,

- Sicherheitsanforderungen an die Remote-Steuerung.

In Diskussionen und Veröffentlichungen tauchen immer wieder Begriffe wie Unattended Operation, Verfügbarkeit, Service-Level-Definitionen, Performance- und Change-Management auf. Eckhard Bogner* geht auf diese Schlagworte ein und erklärt, warum RZ-Automation, die konsequent und umfassend durchgeführt wird, Auswirkungen auf alle diese Bereiche hat.

Folgende Gründe für eine Automation werden am häufigsten genannt:

1. Veränderte Aufgaben des RZ-Personals: Wenn Routineaufgaben wie Handling, Kontrolle oder Dokumentation weitgehend automatisiert sind, bleibt dem RZ-Personal mehr Zeit für wichtige Bereiche wie Performance-Engineering oder Benutzerservice. Das "Rechenzentrum ohne Menschen", wie es sich zum Beispiel die IBM für die weitere Zukunft auf ihre Fahnen geschrieben hat, bleibt wohl noch lange Utopie. Sinnvolle Ansätze sind jedoch schon erkennbar. Dies gilt insbesondere für die Nachtschicht, die bei intensiver Automation in sehr vielen Fällen heute ohne Personal gefahren werden kann.

2. Erhöhung der Verfügbarkeit: Durch Automation kann die Verfügbarkeit eines Rechensystems erhöht werden. Engpässe und Schwachstellen lassen sich bevor sie sich richtig auswirken, mit vom Menschen nicht zu erreichenden Reaktionszeiten beheben. Dadurch können Ausfallzeiten vermieden oder, zum Beispiel bei Ausfall ganzer Komponenten, erheblich reduziert werden.

3. Entlastung der Konsolbediener: Ein größeres Rechenzentrum erhält an einem durchschnittlichen Arbeitstag etwa 400 000 Meldungen auf den Konsolen. Es ist klar, daß Menschen mit der Verarbeitung dieser großen Datenmengen überfordert sind. Die Anzahl der vernachlässigbaren Meldungen ist recht hoch. Zudem erfordern viele Konsolmeldungen Aktionen, die ebenfalls automatisch erfolgen könnten. Eine Reduzierung der Konsolmeldungen auf das wirklich notwendige Maß muß das Ziel jeder Automation sein.

Hier spielt auch der "menschliche Faktor" eine Rolle. Je höher entwickelt ein Rechenzentrum und je abhängiger ein Unternehmen von dessen Leistung ist, desto größere Auswirkungen haben Probleme, die auf manuelle Fehlbedienung zurückzuführen sind. Sie kann weitestgehend vermieden werden, wenn Problemlösungen vorher im "streßfreien" Raum erstellt und im akuten Fall automatisch ausgeführt werden.

Welche Anforderungen eine RZ-Automation erfüllen soll, muß in der Planungsphase definiert werden. Diese eher banal klingende Forderung wird nach genauem Hinsehen sehr viel komplexer, als es zunächst den Anschein hat. So muß zum Beispiel festgestellt werden, welche Abläufe auf dem System überhaupt vorhanden sind (Bestandsaufnahme) und welche davon automatisiert werden sollen (Positivauswahl).

Unter "Abläufen" sind hier zunächst Systemstart (IPL) und Systemstop gemeint, dann aber auch die Workload (Started Tasks und Jobs), die Online-Aktivitäten (zum Beispiel IMS/VS, CICS und TSO) und die Konsolmeldungen. Hinzu kommen Aktionen, die in Problemfällen, zum Beispiel Systemengpässe oder gar -ausfälle, ablaufen sollen. All dies kann automatisiert werden, wenn die entsprechen den Werkzeuge sinnvoll zum Einsatz kommen.

Ein wichtiger Punkt in der Planungsphase ist das Einbeziehen aller betroffenen Personen.

Dazu gehören neben dem Rechenzentrumspersonal auch die Betreuer der einzelnen Produktgruppen (Datenbanken, Online-Monitore, Programmentwickler, Netzwerk etc.). Weiterhin muß überlegt werden, ob im Rahmen dieses Projekts auch auf externes Fachpersonal zurückgegriffen werden soll.

Die gesamte Automation eines Rechenzentrums stellt also eine relativ komplexe Aufgabe dar. Deshalb sollte der jeweilige Hersteller seinem Kunden bei der Implementierung des Werkzeugs zur Seite stehen. Nur so kann eine schnelle und kompetente Einweisung in das Produkt erfolgen und ein umfassender Know-how-Transfer stattfinden. Dies verkürzt die Zeit von der Installation des Produkts bis zum Einsatz der kompletten Automation in der Produktion erheblich.

In der Planungsphase muß auch die Frage nach Schnittstellen der Automation zu bereits vorhandenen Verfahren abgeklärt werden. Hier ist zum Beispiel zu untersuchen, inwieweit sich ein Job-Steuerungssystem oder ein Change-Management-Produkt einbeziehen lassen. Wichtig ist, daß eine integrationsfähige Lösung gewählt wird, die mit bereits vorhandenen Standardprodukten uneingeschränkt verträglich ist.

Hier stellt sich auch die Frage, ob gewisse "Exoten" in bestimmten Bereichen der RZ-Software nicht einer Standardlösung Platz machen sollten, um Schnittstellenproblemen aus dem Weg zu gehen. IBMs Systemview scheint in diesem Zusammenhang eine zukunftsweisende Strategie zu sein.

Um eine Automationslösung zu einem allumfassenden Konzept zu machen, ist es notwendig, neben den Konsolmeldungen noch weitere Indikatoren des Systemzustands zu nutzen. Nur so können auch solche Systemengpässe, die sich nicht in Konsolmeldungen ausdrücken, aber unbedingt eines Eingriffs bedürfen, automatisch behoben werden. Dazu lassen sich vorhandene oder neu zu beschaffende System-Monitore verwenden - natürlich unter dem Aspekt der Integrierbarkeit in das Gesamtkonzept.

Systemengpässe in einem frühen Stadium erkennen

Über die Beschaffung von (weiteren) System-Monitoren sollte daher in der Planungsphase nachgedacht und entschieden werden. Letztlich muß das Automationswerkzeug so universell einsetzbar sein, daß alle Komponenten ihres jeweiligen Systems unterstützt werden. Dazu gehören neben dem Betriebssystem (MVS, VM) das Online-System (TSO, CICS, IMS) und weitere Subsysteme (JES, VTAM etc.). Die problemlose Anbindung der Remote-Steuerung des Rechenzentrums an die Automation ist eine Selbstverständlichkeit.

Die Unterdrückung und Bearbeitung von Konsolmeldungen ist meist der erste Schritt in einem Automationsprojekt. Dazu muß das Automationsprodukt in der Lage sein, auftretende Meldungen nach Kennung, Inhalt und Struktur zu analysieren. Schließlich muß es anhand des Ergebnisses die gewünschten Maßnahmen ergreifen: Unterdrückung der Meldung, Umleiten auf andere Konsolen,

Verändern nach Inhalt und Form oder Ergreifen einer geeigneten Maßnahme.

Ein zentraler Anspruch an ein Automationswerkzeug ist die Möglichkeit, sich über die in der eigenen Systemumgebung vorhandenen Meldungen anhand von Statistiken zu informieren. Die Statistiken, meist in Tabellenform, müssen eine Auswahl der gewünschten Meldungen zulassen, die dann an das Tool übergeben werden können. Dieses Werkzeug führt anschließend selbständig die erforderlichen Einrichtungen im System durch (Programmgenerator).

Eine Eingabe per Hand ist bei der Menge der zu behandelnden Meldungen indiskutabel und höchstens im Einzelfall zweckmäßig. Eine bereits vorgenommene Unterdrückung von Meldungen über das MPF-Member sollte unverzüglich und ohne Aufwand in das Automationswerkzeug übernommen werden können. Ein Werkzeug das dies nicht kann, wird besonders bei den Systemprogrammierern auf wenig Akzeptanz stoßen.

Mit Workload ist hier die Menge der Jobs und Started Tasks gemeint, die auf einem Rechensystem aktiv sein sollen. In der ersten Phase kommt es darauf an, den Systemstart so weit zu automatisieren, daß nach dem IPL nur noch über das Command-Member der SYS1.PARMLIB das Automationswerkzeug gestartet wird, das anschließend sämtliche Ressourcen ohne weiteren Eingriff von außen hochfährt.

Trotzdem müssen natürlich Eingriffsmöglichkeiten bleiben, wenn aus betrieblichen Gründen nur ein geringer Teil der sonst verwendeten Workload benötigt wird, zum Beispiel im Testfall. Nach dem Start des Gesamtsystems geht es um die Überwachung der Workload. Ein unbeabsichtigter Stop eines Adreßraums muß vom Automationswerkzeug sofort bemerkt werden Anschließend werden Maßnahmen eingeleitet, um den Adreßraum wieder verfügbar zu machen (Recovery).

In diesen Bereich fällt neben der Verfügbarkeit der Workload die Verfügbarkeit des Rechensystems und seiner Subsysteme als Ganzes. Hier reicht es nicht mehr aus, sich auf die Auswertung von Konsolmeldungen zu beschränken. Moderne System-Monitore bieten bekanntermaßen sehr viel weiterreichende Möglichkeiten, Systemengpässe bereits in einem frühen Stadium zu erkennen. Anhand dieser Indikatoren kann sich ein Automationswerkzeug zum frühestmöglichen Zeitpunkt über die Art und die Ursache eines Problems informieren und Gegenmaßnahmen ergreifen.

Dieser Aspekt ist wichtig, wenn zum Beispiel ein Systemabsturz durch einen entsprechenden Eingriff hätte vermieden werden können, der Systembediener aber aus Mangel an Konzentration oder Erfahrung die erforderlichen Gegenmaßnahmen nicht ergreifen konnte. Und dabei hätte ein Automations-Tool durch das Canceln einer Task, die im Begriff war, einen CSA-Überlauf zu verursachen, natürlich alles bereinigen können.

Auch Probleme, die nicht durch eine spezifische, vorprogrammierte Lösung aus der Welt geschafft werden können, sind durch Einsatz eines Automationswerkzeugs einfacher zu lösen: Die Analyse findet bereits im Vorfeld statt, der Operator bekommt anschließend Hinweise auf die mögliche Fehlerursache und entsprechende Lösungsvorschläge. Der Zeitaufwand wird so erheblich vermindert.

Paßwortschutz und automatischer Rückruf

Ein wichtiger Aspekt der Automation ist die Möglichkeit, das Rechenzentrum zu festgelegten Zeiten ohne Operator zu betreiben. Über bestimmte Zeiträume, etwa Nacht- oder Wochenendschichten, ohne Personal zu fahren ist heute schon möglich und wird auch vielerorts praktiziert. Das Automationswerkzeug muß jedoch in der Lage sein, Fehlersituationen zu bearbeiten und bei Problemen, die nicht mit der vorhandenen Ablauflogik behoben werden können, den entsprechenden Spezialisten zu benachrichtigen.

Dies geschieht vorzugsweise über Cityruf oder Eurocall. Idealerweise sollte der alarmierte Mitarbeiter zuhause einen Anschluß an den Großrechner haben, der ihm alle Möglichkeiten bietet, die er auch im Rechenzentrum am Terminal beziehungsweise an der Systemkonsole hat. Dieser Zugang schließt insbesondere die Timesharing Option (TSO) ein

Es muß jedoch auch ein IPL möglich sein, damit bei schwerwiegenden Fehlern das System gestoppt und wieder gestartet werden kann. Wichtig beim Remote-PC ist, daß ein Sicherheitssystem die unberechtigte Benutzung wirksam verhindert, also mindestens Paßwort-Schutz und automatischer Rückruf nach Verbindungsaufnahme mit dem Host gewährleistet sind. Beispiel in dem Zeitraum aus, in der bestimmte Anwendungen zur Verfügung stehen (zum Beispiel werktags von 8.00 bis 18.00 Uhr), oder - was sehr häufig geschieht - in der durchschnittlichen Antwortzeit von TSO, CICS- oder IMS-Anwendungen.

In diesen Fällen werden Schwellwerte vereinbart - zum Beispiel 95 Prozent aller Antworten müssen innerhalb von einer Sekunde erfolgen. Ohne Schwellwerte kann eine Service-Level-Vereinbarung nicht überwacht werden. Performance Management ist nun die Überwachung dieser Service-Level-Vereinbarungen mit dem Ziel, sie jederzeit einzuhalten beziehungsweise bei Verschlechterung des Service-Levels sofort Maßnahmen zu ergreifen. Im Rahmen der Automation muß das Performance Management

weitgehend automatisch erfolgen.

Dazu werden die vereinbarten Schwellwerte durch das Automationswerkzeug überwacht. Geeignete Methoden sind hier System-Monitore, zu denen entsprechende Schnittstellen vorhanden sein müssen. Eine Überschreitung der Schwellwerte wird vom Automationswerkzeug sofort festgestellt und analysiert.

Aufgrund dieser Informationen kann das Automationswerkzeug den Service Level wieder auf das geforderte Maß anheben, indem zum Beispiel ein Job mit hoher Priorität, der als Ursache erkannt wurde, zunächst aus der Verarbeitung genommen wird ("swap out"). Nach der Aktion wird weiter überwacht, ob der Eingriff Erfolg hatte oder ob zusätzliche Maßnahmen durchgeführt werden müssen.

Der Ausfall des Rechenzentrums eines Dienstleistungsunternehmens hat immense Folgen, insbesondere bezüglich Kosten und Kundenzufriedenheit. Ein Automationswerkzeug muß hier die entscheidende Softwarelösung bieten können. Den Ausfall von Softwarekomponenten hatten wir im Abschnitt Workload behandelt.

Nach Ausfall oder "abend" einer Started Task oder eines Batch Jobs wird automatisch ein Recovery durchgeführt, das bis hin zum Start der Ressource auf einem anderen Rechner führen kann. Dies läßt sich natürlich auch beim Ausfall eines ganzen Rechners durchführen: Das Automationswerkzeug überwacht die Verfügbarkeit der vorhandenen Rechner und startet bei Ausfall eines Systems die notwendige Workload auf einem anderen vorher festgelegten Rechner. Die entsprechenden VTAM-Verbindungen werden automatisch umgestellt, die Produktion kann auf dem anderen Rechner weiterlaufen.

Möglichst umfangreiche Beispielbibliothek

Viele der bisher vorgestellten Problematiken können durch Standardlösungen, die an die Installationsbesonderheiten angepaßt sind, bewältigt werden. Es ist daher sehr wichtig, daß der Hersteller des Automationswerkzeugs eine möglichst umfangreiche Beispielbibliothek mitliefert, die vorgefertigte Routinen für die verschiedensten Bereiche enthält. Ebenso wichtig ist die Prozedursprache, in der Automationsroutinen geschrieben werden müssen.

Eine Standardsprache wie Rexx sollte unbedingt verfügbar sein, um den Lernaufwand gering zu halten. Eine eigene Sprache hat so verwandt wie möglich mit dem Standard eines jeden MVS-Rechenzentrums, TSO CLIST, zu sein. Bei der schnellen Implementierung des Automationsprodukts sind integrierte Programmgeneratoren von unschätzbarem Vorteil. Dadurch können schnell über eine komfortable Oberfläche, zum Beispiel ISPF, die notwendigen Daten und Parameter eingegeben werden, woraus anschließend der Code generiert wird, der vom Automationswerkzeug verarbeitet werden kann.

Dies betrifft insbesondere die Message Automation sowie die Ressourcen-Überwachung, weil hier die ersten Schritte gemacht werden - ohne große Einarbeitungszeit. Wichtig ist zudem der Service, der es ermöglicht, mit Hilfe von Systemspezialisten schnell zu einem Erfolg bei der Automation des Rechensystems zu kommen.

* Eckhard Bogner, Vertriebsbeauftragter der Candle GmbH, München