Die Kontrolle der gegenwärtigen und die realistische Abschätzung der künftigen

CPU-Auslastung - auf diese klassischen Aufgaben läßt sich das Thema

Kapazitätsmanagement (KM) nach Ansicht von Erhard Mühe* nicht mehr

reduzieren. Der Autor gibt praktische Hinweise zum KM und beschreibt, welche

Aufgaben Performance Management und Kapazitätsplanung als Teilbereiche

haben. Interessenten erhalten Kriterien, mit denen sie ihr eigenes Instrumentarium kritisch überprüfen können.

Zeit ist Geld

Bezogen auf den DV-Bereich heißt das: Perrormance-Engpässe kann man entweder mit einem größeren Speicherangebot oder aber mit geeigneten Softwareprodukten erweitern. Welche Entscheidung der Anwender auch trifft - Geld kosten sie beide.

Am Rande: Was Performance so alles bedeutet*

Auslastung: Als Auslastung bezeichnet man die relative oder prozentuale Beschäftigung eines DV-Systems oder eines seiner Teile oder eines Leistungssystems in bezug auf die insgesamt mögliche Beschäftigung.

Betriebsleistung: Die Betriebsleistung ist in starkem Maße abhängig von der Art des Rechners selbst, besonders von der Betriebsart und der Tatsache, daß der Rechner mehr als ein Programm abarbeiten kann.

Durchsatz: Die in absoluten Werten angegebene Menge von Zeichen, Daten oder Bildpunkten, die ein Betriebsmittel in einer bestimmten Zeit verarbeiten kann oder tatsächlich verarbeitet.

Was mit Performance so alles zusammenhängt*

Leistungsgarantie: Der aus der rechtlichen Verpflichtungen Verkäufers für die Funktionstüchtigkeit einer verkauften Ware oder Dienstleistung abgeleitete Anspruch des Käufers bei Mängeln und Fehlern bestimmte Rechte gelind zu machen.

Leistungsbewertung: Die Leistung, die von einer Maschine erbracht wird und nicht direkt am Markt verkauft werden kann, weil sie nur eine Zwischenstufe zu einem Endprodukt ist, kann nur auf Grund der durch sie verursachten Kosten beurteilt werden. Dies führt beim Einsatz von Rechnern, die im innerbetrieblichen Prozeß zur Unterstützung von Entscheidungen und von administrativen Aufgaben eingesetzt werden, insofern zu Komplikationen, als beim Vergleich unterschiedlicher Systeme mit unterschiedlichen Leistungen ein reiner Kosten-Kosten-Vergleich meist nicht möglich ist.

Leistungsbeschreibung: Die im Ramen eines Pflichtenheftes dargestellten einzelnen Aufgaben, für die ein Rechner eingesetzt werden soll. Je präziser die Leistungsbeschreibung erfolgt, um so besser kann entschieden werden, ob ein bestimmter Rechner beziehungsweise Software die Leistungen übernehmen und ausführen kann. Die Leistungsbeschreibung gehört zu den ersten Schritten der Systementwicklung.

Die DV durchlebt bekanntlich seit einiger Zeit immer kürzere Lebenszyklen von Hard und Software. Immer mehr Produkte drängen auf den Markt. Technische Neuerungen, manchmal veraltete Technik unter neuem Namen oder Konzeptionen, die so neu sind, daß sie erst in einigen Jahren das halten, was sie heute schon versprechen, sorgen dafür, daß sich die Amortisationszeiten für DV-Investitionen verringern.

Für Unsicherheit in den Unternehmen sorgen unter anderem neue VAX-Großrechner von DEC, die IBM-Systeme 9370, AS/400, ES/9000, veränderte Netzwerkstrukturen, schnellere Platten mit gigantischem Speichervolumen, DASD Arrays, Roboter, Escon, DF...Produkte, ESA, PR/SM, MLPF, MDF und nicht zuletzt Sysplex mit Cross System Communication Facility (XCF), Sysplex Timer und Stand-alone Shared Storage.

Eine exakte, transparente und vor allem qualitätsgesicherte Steuerung und Überwachung sowie eine sorgfältige Planung der Investitionen wird immer notwendiger - die Lösung heißt: Kapazitätsmanagement. Der DV-Verantwortliche wird auf die Frage, was er unter diesem Begriff versteht, fast immer antworten:

- die regelmäßige Kontrolle der momentanen CPU-Auslastung,

- das rechtzeitige Abschätzen der zukünftigen CPU-Auslastung.

"Bei Problemen wird neue Hardware gekauft"

Weil er sich auf dieses Wissen verläßt, reicht dem DV-Chef vor der Hardware-Aufstockung (verändertes Budget, RZ-Übernahme, Zuwachs bei den Datenbanktransaktionen etc.) zur Information oft eine einzige Studie - und die entsteht in der Regel mit Unterstützung des Hardwareherstellers. Zweifelsohne ist heute das Interesse an Fragen des Kapazitätsmanagements erheblich gewachsen.

Weil das KM früher in erster Linie auf Maßnahmen im Bereich "Tuning" beschränkt wurde, zeigten sich schnell die Grenzen von kurzfristigen Maßnahmen. Ein gezieltes KM kam selten zustande. So sind noch heute viele Installationen deutlich überkonfiguriert. Die Verantwortlichen "planen" kurzfristig: Bei Problemen wird einfach neue Hardware gekauft.

Dazu zwei Beispiele, die Insidern nicht ganz unbekannt sein dürften: In einem namhaften Unternehmen, ausgerüstet mit einer großen DV-Anlage, beschließt die Planungsgruppe, ein Tool für das KM zu testen Die ersten Ergebnisse zeigen deutlich eine Überkonfiguration an - vor allem im Bereich Zentral- und Erweiterungsspeicher. Weitere Tests bestätigen die ersten Ergebnisse. Das Resultat: Statt bekannte Überkapazitäten abzubauen, um laufende Kosten zu sparen, statt den Planungsprozeß im Unternehmen zu revidieren und Kontrollmechanismen zu institutionalisieren, um zu qualitätsgesicherten Aussagen zu kommen, will man in den nächsten Jahren in die Konfiguration "hineinwachsen".

Im zweiten Fall sollte eine neue Anwendung eingeführt werden. Es handelte sich um ein strategisches Produkt. Die Einführung war vom Management und den Fachabteilungen zeitlich exakt geplant und alle Mitarbeiter waren gut geschult. Der Einsatz der Anwendung zeigte sehr schnell, daß die vorhandenen Ressourcen bei weitem nicht ausreichten. In kürzester Zeit wurde für ungeplante, also nicht budgetierte, 1,8 Millionen Mark ein neuer Rechner installiert. Die Methode der Kapazitätsplanung hat sich in diesem Unternehmen bis heute nicht geändert. Die folgenden Ausführungen sind zwar fachlich im Bereich der IBM und PCMer-Welt angesiedelt, doch sind die Ausführungen zum KM für andere DV-Systeme, ob von DEC, Siemens oder Unisys etc., ebenfalls gültig.

Die DV ist heute der Dienstleister für das Gesamtunternehmen. Das angebotene Produkt ist "Service". Ziel der Datenverarbeitung ist, diesen Service unter Berücksichtigung von Qualität, Kosten und Unternehmenszielen zur Verfügung zu stellen. Die dafür benötigten, einsetzbaren Ressourcen sind Hardware, Software, Information und Personal. Die Aufgabe des KM ist die Organisation eines möglichst perfekten Einsatzes dieser Ressoursen.

KM wird unterteilt in Performance-Management (P.M) und Kapazitätsplanung (KP). PM hat folgende Aufgaben:

- Performance-Daten sammeln (SMF, RMF, Monitore für DB2, CICS, IMS etc.),

- Analysieren und verstehen der aktuellen Workloads,

- Analysieren und Verstehen der aktuellen Konfiguration,

- den aktuellen Ressourcenverbrauch feststellen,

- freie Kapazitäten (Spielraum) aufzeigen,

- Optimieren beziehungsweise Tunen der Workloads,

- Optimieren beziehungsweise Tunen der Konfiguration,

- Aufzeigen von Bottlenecks und/oder Überkapazitäten (letzteres geschieht allerdings selten),

- Verstehen des Verhaltens von Lasten (Workloads wie I SO, DB2, CICS, IMS etc.) und ihrer Dynamik, die häufig unterschätzt wird (bei der Neueinführung eines Produktes ist der Anwender noch unbeholfen, das heißt, sein Bedarf an Service ist relativ klein - nach der Einarbeitungsphase wird sich sein Ressourcenverbrauch vervielfachen),

- Performance-Daten als Historie abspeichern,

- Reporting des IST-Zustandes durch Grafik und Tabellen bis in das Management.

Kapazitätsplanung dagegen soll im wesentlichen folgende Fragen beantworten:

- Warum werden Ressourcen verbraucht?

- Welche Ressourcen benötigen wir in Zukunft?

- Wie wird sich der Rechner bei veränderten projektierten Lastzielen verhalten?

- Wie könnte dann die neue DV-Umgebung aussehen?

- Welche Alternativen gibt es? - Wie werden dann die Antwortzeiten sein?

- Welche Kosten werden entstehen?

Die Frage, welchen Einfluß neue Anwendungen auf das bestehende System haben, wird oft nicht ernst genug genommen Häufig sagt der Anbieter eine viel zu geringe zusätzliche Belastung voraus. Bei im Hause entstandenen Programmen wird nicht selten unterschätzt, daß ein Programmierer, Datenbankadministrator etc. häufig keine Möglichkeiten hat, die Effizienz seines Produktes zu testen.

Wenn die freien Ressourcen nicht ausreichen, dann können die Gründe in mangelhafter Hardware-Ausstattung liegen, oder das Design des neuen Produktes ist nicht optimal. Das wiederum hat zur Folge, daß entweder ein Re-Design erfolgen muß, was zeitaufwendig, kostspielig und nicht nur bei strategisch wichtigen Produkten wenig wünschenwert ist, oder es wird "nur" der Geldbeutel strapaziert - ein Beispiel hierfür wurde bereits erwähnt.

In Deutschland ist ein Fall bekannt, wo der damals verantwortliche Manager dankbar war, daß ihm vor Einsatz der Software neben den Empfehlungen des Hardwareherstellers auch detaillierte Planungsunterlagen - erstellt mit dem SW-Produkt "Crystal" - vorlagen. Das Design der Anwendungen konnte optimal auf vorhandene und anzuschaffende Hardware abgestimmt werden. Die Ersparnis wird auf etwa 10 Millionen Mark geschätzt.

Anforderungen an das installierte System

Folgende Fragen sollen den Leser dazu anregen, kritisch über das Instrumentarium im eigenen Hause nachzudenken:

- Wieviel Speicher wird beim Einsatz von ESA benötigt?

- Wo liegt das CPU-Limit?

- Wie würde die Nutzung von "Hyperspase" die Antwortzeiten verbessern?

- Wie verbessert sich das I/0-Verhalten, wenn die neue Glasfasertechnik eingesetzt wird?

- Kann eine kleinere preiswertere CPU die aktuelle Last ohne signifikante Verluste in der Performance handhaben?

- Wie muß das Backup-RZ aussehen?

- Welche Vorteile ergeben sich, wenn die vorhandene CPU über PRISM in eine Produktions- und Testmaschine konfiguriert wird?

- Welchen Einfluß auf CPU-Last und Speicherausnutzung wird eine neue CICS-Applikation haben?

- Welche Antwortzeit kann dann für TSO erwartet werden? - Wie wirken sich Cache-Einflüsse aus?

- Welcher Cache-Controller ist optimal für die Konfiguration?

- Wie groß sollte der Cache-Speicher sein?

- Um wieviel Prozent können die IMS-Transaktionen noch gesteigert werden?

- Kann aus Kostengründen der Austausch der CPU um sechs Monate verzögert werden? - Reicht eventuell statt einer neuen CPU eine Speichererweiterung?

- Wie muß bei meiner Konfiguration das Verhältnis von Zentral- zu Erweiterungsspeicher sein?

- Können ohne große Performance-Verluste weitere Filialen an das Netzwerk angeschlossen werden?

- Inwieweit verbessert sich die Antwortzeit für die Außenstellen, wenn die Leitungsgeschwindigkeit erhöht wird?

Ziel des KM ist zu agieren, immer einen Überblick über den Ist-Zustand zu haben sowie zu wissen, welche Anforderungen in Zukunft an das System gestellt werden und welche Veränderungen (einschließlich der möglichen Alternativen) zu welchem Zeitpunkt vorgenommen werden müssen Unter Kapazitätsmanagement fallt nicht das Reagieren, das Aktivwerden, wenn das Kind schon in den Brunnen gefallen ist.

Der Anwender will den optimalen Service

Das agierende System setzt in einem Unternehmen allerdings Kompetenz, Kommunikation Kooperationsbereitschaft, Know-how und die geeigneten Verfahren voraus. "Das magische Dreieck" (siehe Abbildung 1) zeigt die Aufgabe des KM, unternehmensspezifische Möglichkeiten unter Berücksichtigung der Anwenderansprüche bei den jeweils vorhandenen Ressourcen zu prüfen. Der Anwender erhebt den Anspruch auf einen optimalen Service, das Management möchte diesen Service mit möglichst geringen Kosten leisten, und die DV-Abteilung muß sich fragen, wie sie beiden Ansprüchen gerecht werden kann. Ziel des Kapazitätsmanagements ist also die rechtzeitige Bereitstellung der notwendigen Ressourcen zur Gewährleistung des definierten Services, wobei die Kosten angemessen sein müssen.

Service ist nur in Form von "Service Level" beziehungsweise "Service-Level-Vereinbarungen" ein Maßstab für die Qualität einer DV-Dienstleistung Unter Service Level ist die Zeiteinheit zu verstehen, die vom Start einer Transaktion beziehungsweise eines Jobs bis zum Ende vergeht (Antwortzeit) oder die Anzahl von Transaktionen (Jobs), die in einem gewissen Zeitintervall ausgeführt werden (Durchsatz) Service-Level-Vereinbarungen sind entsprechende Vereinbarungen zwischen Anwendern und der DV.

Service Level sind stets vorhanden

Typische Service Level sind:

- triviale TSO-Antwortzeit < 0,4 sec;

- durchschnittliche Antwortzeit für Datenbankabfragen < 2 sec;

- pro Programmierer 15 Compiler-Läufe pro Tag;

- Fertigstellen sämtlicher Listen bis morgens um 7.30 Uhr.

Service Level sind selten explizit oder gar schriftlich vereinbart. Trotzdem existieren sie unausgesprochen in jedem Unternehmen und werden regelmäßig von der Systemprogrammierung oder den Mitarbeitern im Berichtswesen kontrolliert.

Kapazitätsplanung reduziert sich in der Praxis oft auf die Betrachtung der Anzahl von MIPS, die ein Rechner leistet. Es ist müßig, darüber zu diskutieren, was dieser Leistungsmaßstab wirklich wert ist. Andere Performance-Einflüsse werden ignoriert. So gehen Simulationsprodukte von Hardwareherstellern von einer optimalen I/O-Konfiguration aus. Dabei wird vorausgesetzt, daß das vorhandene I/O-Subsystem konstanten Service Iiefert.

Bei vielen Beratungsprojekten hat sich jedoch herausgestellt, daß mehr als 70 Prozent der Probleme in der I/O-Konfiguration liegen. Der Einfluß des Netzwerks wird genauso häufig ignoriert. Kosten für Hard- und Software werden in der Regel diskutiert, während Leitungskosten oder Kosten, die durch schlechtes Netzwerkdesign entstehen, einfach hingenommen werden.

Im Bereich der KP sollten notwendigerweise folgende Performance-Einflüsse in die Planung einfließen:

1. CPU: Entscheidende Faktoren für die Leistung einer CPU sind die Anzahl der Prozessoren (Synchronisationsverluste bei mehr als einem Prozessor) und die Rechnergeschwindigkeit, die Menge der Operationen also, die der Rechner in einer bestimmten Zeiteinheit erledigen kann.

2. Speicher: Seit durch erweiterte Adressierungsmöglichkeiten größere Zentral- und seit einiger Zeit auch Erweiterungsspeicher (ZS, ES) installiert werden können, lassen sich viele Probleme, die im I/O-Subsystem gelegen haben, durch Speichererweiterungen aus dem Weg räumen. Durch eine Kosten-Nutzen-Analyse sollte allerdings sorgfältig abgewogen werden, ob der verbesserte Service den höheren Preis für ZS und ES rechtfertigt.

I/0-Subsystem kann Probleme verursachen

Speichermodellierung mit anungs-Tools ist seit einiger Zeit mit den Produkten "Best/l-MVS" und "Best/l-VM" möglich. Diese Produkte waren die ersten am Markt, die zuverlässige Aussagen trafen. Noch wichtiger wird die Speichermodellierung in Sysplex-Umgebungen, wenn - gesteuert über den Sysplex-Timer - der ES von mehreren Systemen verwaltet werden kann.

3. I/O-Subsystem: Dieses ist bei kritischer Performance am häufigsten der Verursacher von Problemen. Schnellerer Zugriff auf Platten, neue Techniken im Bereich der Kanäle, schnellere Übertragungsraten sowie der Einsatz von Cache oder Solid State haben vieles verbessert. Vergleicht man aber die technologische Entwicklung in diesem Bereich mit den gleichzeitigen Fortschritten bei den Rechnern, so wird deutlich, daß die Technologiesprünge bei Rechnern erheblich signifikanter sind.

4. Netzwerk: Der Einfluß des Netzes auf die Gesamt-Performance ist häufig nicht bekannt oder wird einfach ignoriert. Erst wenn die Antwortzeit aufgeschlüsselt wird in Host- und Netzwerkkomponente, zeigt sich der Einfluß. Entscheidende Faktoren sind hier unter anderem Übertragungsprotokoll, Leitungsgeschwindigkeit, Komplexität des Datenverkehrs, Netzwerk-Topologie, geografische Distanz und Übertragungstechnik.

5. Software: Das Verhalten der Software und damit der Workloads hängt natürlich vom eingesetzten Produkt, seinem Design und dem Betriebssystem des Rechners ab. Wer ein Betriebssystem wie ESA einsetzt, sollte auch möglichst viele seiner Funktionen nutzen. Hier tun sich noch alle SW-Anbieter schwer. Selbst die neuesten Releases von Produkten wie DB2 nutzen nur einen Bruchteil der vorhandenen Möglichkeiten.

Die Entwicklung der Software hängt gegenüber der technischen Entwicklung weit zurück. Die Performance selbstgeschriebener Programme ist abhängig von "freischaffenden Künstlern": dem Programmierer und dem Datenbankdesigner. Obwohl gerade hier ein Kontroll- und Planungstool vonnöten wäre, wird nur in den seltensten Fällen ein derartiges Werkzeug akzeptiert. Es scheitert fast immer an der schroffen Ablehnung der Betroffenen, die den sicherlich zu erwartenden Mehraufwand und eine mögliche Kontrolle scheuen. Genau hier versagt das DV-Management.

Die beiden bekanntesten Verfahren zur Kapazitätsplanung sind die Einhaltung von Daumenregeln und die Trendanalyse beziehungsweise die lineare Projektion. Das erste Verfahren hat den Nachteil, daß kein Hardwarehersteller offiziell Daumenregeln für Rechner und deren Betriebssysteme bekannt gibt. Software-Anbieter neigen oft dazu, einen sehr schmalen Daumen zu haben - es heißt dann, der Overhead sei fast gleich null.

Benchmarks sind sehr zeitaufwendig

Die lineare Projektion hat den gravierenden Nachteil, daß DV-Systeme sich niemals linear verhalten. Weitere KP-Methoden sind die analytische Modellierung nach der Warteschlangentheorie, die Simulation und das Benchmarking. Benchmarks sind in Vorbereitung und Ablauf sehr zeitaufwendig. Sie werden beim Hersteller und damit nur auf seinem Equipment durchgeführt.

Für die Simulation gibt es zur Zeit genau ein Produkt eines Hardware- beziehungsweise Softwareherstellers. Auch hier wird die Simulation außer Haus und mit der Hard- und Software des Herstellers durchgeführt. Die letztgenannten Methoden versetzen den Kapazitätsplaner nicht in die Lage, das Gerät eines PCMers zu testen oder zu simulieren. Analytische Modellierung wird inhouse durchgeführt, mit der Möglichkeit, Hardware aller Hersteller in den Modellen darzustellen. Der Aufwand für Trendig und Analytische Modellierung ist identisch, die Ergebnisse der Modellierung aber erheblich exakter. Dagegen ist der Aufwand für eine Simulation erheblich größer, die Ergebnisse maximal genauso exakt wie bei der Analytischen Modellierung.

Beim Kapazitätsmanagement ist wichtig, daß alle Komponenten berücksichtigt werden. Der Einfluß von Netzwerk und neuen Applikationen darf nicht übersehen werden, die Speicherung der relevanten Daten sollte zwecks Historienbetrachtung erfolgen. Ist über das Netz ein von seinem Design und seiner Arbeitsweise her unterschiedlicher Rechner angeschlossen, so sollte dieser in einer Gesamtbetrachtung nicht fehlen (siehe Abbildung 2).