Ulrich Materne ist Leiter Kommerzielle Datenverarbeitung, Rechenzentrum Schering AG,
Berlin
Fast ausschließlich als Instrument zum Trouble Shooting wurde Tuning zu Beginn der 80er Jahre Tuning verwendet. Inzwischen ist auch aufgrund größerer Kapazitäten - ein Wandel hinsichtlich Trenderkennung und vorbeugender Einleitung von Maßnahmen eingetreten. Daneben spielt die aktuelle Erkennung von Engpaßursachen nach wie vor eine Rolle, nur haben sich die Schwerpunkte verschoben.
In der kommerziellen Datenverarbeitung der Schering AG werden seit Jahren Tuning-Instrumente eingesetzt. Das Rechenzentrum wickelt über zwei Zentralrechner (IBM 3090-200 und Comparex 7/90-2) alle Großanwendungen des betrieblichen Rechnungswesens, des Vertriebes, der Produktion wie auch der Internen Verwaltung ab. Zentrale Datenbestände werden als Stammdaten ausschließlich auf diesen Rechnern geführt.
Zur Vorverarbeitung von produktionsnahen Anwendungen werden in zwei großen Werken wie auch zentral in Berlin Systeme IBM /38 eingesetzt. Zwischen den Zentralrechnern und den "Standortrechner" genannten Systemen /38 finden periodische Datenaustausche und Durchgriffe auf die Stammdaten der Zentralrechner statt.
Ein umfangreiches DFÜ-Netz zwischen den Produktions- und Vertriebsstandorten im Bundesgebiet einerseits und der Hauptverwaltung mit Produktionsbetrieben in Berlin andererseits soll sicherstellen, daß alle Mitarbeiter einen gleich guten Service erhalten.
Damit sind wir beim Thema: Es muß vermieden werden, daß dieser Service nicht analog einer "Sägezahnkurve" - mit guten Antwortzeiten unmittelbar nach einer Kapazitätsaufstockung und im Zeitverlauf schlechter werdenden, bis zu unzumutbaren "Wartezeiten" verläuft. Dazu dienen die heute bei Schering eingesetzten Beobachtungs-, Änderungs- und Maßnahmen-Tools, ohne die ein kontinuierlicher Serviceverlauf kaum zu gewährleisten ist.
Bei den im folgenden beschriebenen Tuning-Instrumenten handelt es sich um Software, mit deren Hilfe entweder im laufenden Betrieb Analysen durchgeführt oder aufgezeichnete Systemzustände nachträglich ausgewertet werden können. Nicht näher eingegangen wird auf Software, die bei uns zur reinen Aufzeichnung von Problemfällen benutzt wird wie NPDA. Solche Aufzeichnungen und Auswertungen hängen natürlich auch mit der Beseitigung von Engpaßsituationen zusammen, die jedoch nicht systembedingt, sondern eher technischer Natur sind.
Mit Hilfe des Standardsystems RMF werden tägliche Auswertungen über die gesamte Onlinezeit mit den typischen Systemparametern wie Wait Time Percentage, CPU Busy, Channel Path Activity, I/O Queuing, Response-Zeiten von Platten, Paging/Swapping oder CSA-Auslastung gefahren. Zusätzlich werden die über SMF-Sätze erfaßten Daten durch "Plan IV" und "Jars" ausgewertet. PIan IV besitzt den großen Vorteil, neben Vergangenheitsauswertungen auch Zukunftsprognosen erstellen und diese grafisch aufbereiten zu können.
Mit RMF, Plan IV und Jars werden zur täglichen Grobanalyse des Betriebsgeschehens des vergangenen Tages wie auch des abgelaufenen Monatsintervalls Reports gezogen. Von besonderer Wichtigkeit sind dabei die aufgelisteten 30 Jobs mit dem größten Ressourcenverbrauch wie CPU, Paging-Rate und Hauptspeicherbedarf. Ein Systemprogrammierer sieht (fast) täglich die Reports durch, betrachtet aufgrund seiner Erfahrung kritische Größen und erkennt auf diese Weise sehr schnell Trends wie auch Einzelprobleme. Trends (zum Beispiel CPU- und Kanalauslastung) gehen monatlich/ quartalsweise in Bedarfsanalysen ein. Damit soll sichergestellt werden, daß Beschaffungsmaßnahmen rechtzeitig eingeleitet werden.
Bei auftretenden Problemen wird das sogenannte Feintuning durchgeführt. Dabei werden feinere Intervalle in der Regel über die Hauptbelastungszeit ausgewertet. Für Vergangenheitsbetrachtungen wird "Epilog" hinzugezogen, mit dessen Hilfe SMF-Sätze und eigene, in einer Datenbank gesammelte Daten ausgewertet werden. Exception Reports lassen Rückschlüsse auf Problemverursacher innerhalb des definierten Zeitintervalles zu. Der große Vorteil dieses Hilfsmittels liegt darin, daß gleiche Zeitintervalle über verschiedene Vergangenheitsperioden sehr schnell miteinander verglichen werden können.
Handelt es sich dagegen um die Analyse des gegenwärtigen Geschehens, ist dieses mit Hilfe des Instrumentes Omegamon möglich. Mit Omegamon/MVS lassen sich beliebige Bedingungen oder Umstände definieren, deren Überschreitung auf dem Eingangsbild bereits angezeigt wird. Damit werden bei dem ständig mitlaufenden Omegamon/MVS Ausnahmen- und Problemsituationen sofort sichtbar.
Tiefergehende Analysen lassen Rückschlüsse auf die wirklichen Verursacher zu: Welcher Job, welche Task ist Auslöser für "Hänger"; eine bestimmte Platte ist besonders busy; die Zentraleinheit ist nicht verfügbar wegen eines besonders CPU-intensiven Jobs etc.
Besonders hervorzuheben ist die Funktionsfähigkeit von Omegamon/MVS im Problemfall, unabhängig von Systemkomponenten, außer dem Betriebssystem selbst. Ist das VTAM nicht mehr aktiv, sind trotzdem Bildschirmein/-ausgaben möglich; sind die Systemkonsolen ausgefallen, können andere Bildschirme über Omegamon definiert werden.
Diese Software zeigt im Operating auf beiden MVS-Systemen den Systemzustand im Zeitintervall von fünf Sekunden an. In der operatorfreien Nachtschicht werden im 60-Sekunden-Rhythmus Systemstati aufgezeichnet und gespeichert, um im Problemfall nachträglich nach der Ursache suchen zu können.
Mit Hilfe dieses Instruments wird neben dem oben beschriebenen Trouble Shooting auch ein Großteil des Systemtuning betrieben, da Omegamon mit aktuellen Daten arbeitet und die wirkliche Systemumgebung nur durch tatsächliche aktuelle Statusbeobachtung erkennbar ist. Will man die Laufzeiten bestimmter Jobs beobachten und schlüssige, Durchlaufverbesserungen erreichen, ist es notwendig, auch die Umgebung zu begutachten, um festzustellen, welche sonstigen Jobs und Tasks im System welche Ressourcenverbräuche verursachen.
Die Ergebnisse der Systembeobachtung führen zu kurz- oder mittelfristigen Maßnahmen, von denen folgende typisch sind:
- Bei Antwortzeitproblemen, die auf ungünstige I/O-Belastung zurückzuführen sind, werden entweder Fragmentierungen von Dateien beseitigt, Dateien verlegt oder ganze Platten in einen anderen Plattenstrang eingebunden.
- Bei Paging-Problemen können Page Data Sets besser verteilt oder ein als Paging-Platte eingesetzter elektronischer Speicher den Zentralrechnern anders zugeordnet werden. Auf diese Weise sind Lastspitzen über längere Zeit abzufangen, ohne den Hauptspeicher erweitern zu müssen.
Bei hoher CPU-Auslastung während der Online-Zeit und parallel abgewickelten Batchjobs kann man überlegen, CPU-intensive Batchjobs in die Nacht zu verlegen etc.
Alle diese Maßnahmen enden jedoch an Kapazitätsgrenzen. Sind Engpässe auf fehlende Kapazität zurückzuführen, ist mit Tuning-Software lediglich festzustellen, welche Systemteile zu "Flaschenhälsen" geworden sind. Dauerhafte Abhilfe kann dann nur noch durch sofortige Beschaffungsmaßnahmen erreicht werden. Um diese Situation zu vermeiden, ist es unbedingt wichtig, Trends mit Hilfe von Analyse- und Tuning-Instrumenten rechtzeitig zu erkennen.
Zur Beobachtung und zum Tuning des CICS-Systems verwenden wir ausschließlich Omegamon/CICS. Dieses wird zur Zeit nur im Problemfall zugeschaltet und ist auch dann funktionsfähig, wenn das CICS nicht mehr zur Verfügung steht. Ermöglicht wird dieses dadurch, daß die meisten Teile von Omegamon/CICS in einem separaten Adreßraum außerhalb des CICS arbeiten und mit Hilfe von Cross-Memory-Services die spezifischen CICS-Parameter analysiert werden können.
Eine typische Anfrage, die beim Nutzerservice (User Help Desk) gestellt werden kann, bezieht sich auf, schlechte Antwortzeiten des laufenden Tages. Der Mitarbeiter im Nutzerservice schaltet dann das Omegamon/CICS ein, erfährt über die erste Bildschirmanzeige das Überschreiten von Schwellenwerten (reale Hauptspeicher-Nutzung, hohe I/O-Raten etc.) und sieht die Transaktionen der letzten zehn und 30 Minuten. Dabei werden als Globalaussage beispielsweise Wartebedingungen angezeigt, die jedoch noch keine Aussage über die Antwortzeit selbst zulassen.
Die sich dann anschließende Anzeige von Transaktionsgruppen (diese stellen einen Ausschnitt aus dem CICS dar) läßt schon eher Rückschlüsse zu, beispielsweise auf I/O-Zugriffe. Prinzipiell gehört aber zu einer wirklichen Beurteilung auch eine Grundkenntnis über die Anwendung. Daher nehmen Mitarbeiter der Systemprogrammierung und des User-Help-Desks auch an Anwendungsschulungen über wichtige Anwendungssysteme teil. Dies hilft bei
der Beurteilung "normaler" oder "anomaler" Betriebszustände einer Anwendung.
Netspy als wirksames Instrument
Das Instrument des CICS-Tuning wird neben obigen Tagesproblemen grundsätzlich bei Einführung neuer Anwendungen verwendet. Hier können Engpässe am ehesten auftreten, Speichergrößen, Zugriffsbedingungen etc. sinnvoll angepaßt und somit die Abwicklungen optimal eingestellt werden. Besonders wichtige Anwendungen werden im Antwortzeitverhalten dann täglich beobachtet, um bei sich andeutenden Problemen tätig werden zu können.
"Netspy" ist das jüngste, bei Schering eingesetzte Meß- und Tuning-Instrument, um reale Antwortzeiten bis zum Terminal sowie Leitungsauslastungen zu beobachten. Als Problem stellte sich bei der Auswahl eines Monitors zur Messung realer Antwortzeiten der Betrieb des bei Schering eingesetzten Multi-Session-Managers TPX heraus.
Unter TPX werden bei den meisten Softwarepaketen alle Transaktionen innerhalb einer Session gemeinsam gemessen, es wird nicht mehr zwischen einzelnen Nutzeranwendungen unterschieden. Gerade diese Trennung war uns aber wichtig. Zur Zeit der Systemauswahl 1987 erfüllte nur Netspy diese Anforderung.
Netspy liefert Antwortzeitaussagen, die pro Anwendung nach Rechner- und Netz-Anteil aufgesplittet werden können. Um Ursachen und Trends zu erkennen, wurden Schwellenwerte definiert, bei deren Überschreitung Ausnahmereports gedruckt werden. Dazu gehören zum Beispiel
- mittlere, Antwortzeiten über zwei Sekunden;
- maximale Antwortzeiten über 20 Sekunden;
- mittlere Leitungsauslastungen über 20 Prozent;
- maximale Leitungsauslastungen über 30 Prozent.
Der Einsatz dieses Instruments hat sich als ausgesprochen wirkungsvoll für die Analyse des Datennetzes und die Maßnahmenplanung herausgestellt. Bei einigen der von zentraler Seite als gut eingeschätzten Anwendungen stellte sich sogar heraus, daß diese unter Mitberücksichtigung der gesamten Netzzeiten teilweise besonders schlecht bedient wurden und die Nutzer sich nur an diese Situation gewöhnt hatten. Netspy wird auch bei Tagesproblemen als Analyseinstrument eingesetzt.
Oberste Zielrichtung für das Rechenzentrum ist die Servicequalität. Ohne wirkungsvolle Tuning-Instrumente ist dieses Ziel nicht annähernd zu erreichen, denn zur Servicequalität gehört nicht nur schnelles Reagieren, sondern auch rechtzeitiges Agieren. Somit ist die regelmäßige Beobachtung der Kapazitätsverbräuche eine unerläßliche Notwendigkeit zur rechtzeitigen Einleitung von Beschaffungsmaßnahmen. Auch diese kontinuierliche maschinelle Erweiterung ist ein wichtiger Gradmesser der Servicequalität.
Leider gibt es heute noch keine Tuning-Instrumente, die nahtlos ineinandergreifen und die bei Schering gestellten Anforderungen abdecken. Damit ergeben sich bei unterschiedlichen Softwareprodukten zwangsläufig Überschneidungen, die wir im täglichen Gebrauch unterdrücken. Im Ergebnis verwenden wir ein Instrumentarium, welches die wirkungsvollsten Ausschnitte zur Verfügung stellt. Der Vorteil dieser Vorgehensweise liegt sicherlich in der präzisen Information, schnellen Ursachenermittlung und somit der Möglichkeit zur sofortigen Abhilfe.
Erkauft wird der relativ störungsfreie Betrieb mit höheren Lizenzgebühren, höherem System-Overhead sowie umfangreichem Handling- und Pflegeaufwand. Wo zwischen Service und Aufwand jeder Betrieb die sinnvolle Grenze zieht, hängt ausschließlich von den Anforderungen ab sowie nicht zuletzt von den Mitarbeitern.