Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

30.05.1986

Lethargie gegenüber DV-Kapazitätsplanung:Gute Antwortzeit ist teuer - schlechte sehr teuer

Während die Befürworter von Kapazitäts-Management mit fast missionarischem Eifer für ihre jeweilige Methode kämpfen, zucken die Gegner entweder uninteressiert oder gar höhnisch mit den Schultern. Auch ist das Argument zu hören, daß man auftauchende Probleme jeweils einfach mit zusätzlicher Hardware erschlagen könne. Die Anwendersicht und einschlägige Lösungsansätze zeigt Ernst Pietschner, Software-Berater der ADV/ ORGA in Wilhelmshaven, im folgenden auf.

In der Tat gibt es eine Menge Gründe, sich nicht mit Kapazitäts-Management zu beschäftigen. So kann man mit dem "falschen Zeitpunkt" argumentieren und konstatieren, daß die Anlage derzeit "voIl" sei und darum demnächst einfach vergrößert werden müsse. Auf Überlegungen in Hinblick auf das Kapazitäts-Management könne insofern verzichtet werden. Nicht relevant ist das Thema auch für solche Benutzer die gerade eine neue Anlage installiert und damit - so die eigene Annahme - auch genügend Freiraum haben. Oft ist es aber auch einfach so, daß den Anwender der Schuh bei dringlichen Fragen - zum Beispiel die Umstellung seines Betriebssystems - drückt und er deshalb glaubt, keine Zeit zu haben, sich ausgerechnet jetzt mit Kapazitäts-Management auseinanderzusetzen.

Neben dem angeblich falschen Zeitpunkt wird auch die Furcht vor unrichtigen Ergebnissen durch Einführung von Kapazitäts-Management laut. Es wird beispielsweise argumentiert: Seit vielen Jahren plane ich die notwendigen Ressourcen exakt. Warum soll ich deshalb eine neue Methode einführen, die angeblich besser ist?" Oder es heißt: "Seitdem es in unserem RZ Systemprogrammierer gibt, rufen diese ständig nach neuen, immer teureren Werkzeugen zum Tunen und Überwachen der Systeme. Aber wenn man sie mal fragt, wie sich die zehn neuen IMS-(CICS, APL)Terminals auf das System auswirken werden, bekommt man nur ausweichende Antworten."

Schließlich und endlich kann das Thema Kapazitätsplanung auch als Ermessensfrage angesehen werden. Man glaubt also, daß man bei einer so komplexen Angelegenheit wie einer DV-Anlage eh nicht genau genug planen kann oder der Hersteller einem bei diesem Problem sowieso hilft.

Diese Liste ist keineswegs vollständig. Vor Jahren untersuchte ein renommiertes Marktforschungsunternehmen nordamerikanische Großanwender hinsichtlich ihres Kapazitäts-Managements und kam zu folgendem Ergebnis:

- Von 1500 befragten Usern zeichneten nur etwa 50 Prozent Performance-Meßdaten auf und nur 20 Prozent werteten sie regelmäßig aus.

- Von diesen 20 Prozent wiederum war nur ein Fünftel der Meinung, daß ihre Anlage optimal konfiguriert war und ihrem Preis entsprechend arbeite.

Da trotz aller widersprüchlichen Gründe kaum jemals ein Beteiligter die generelle Notwendigkeit von Planung bestreitet, soll im folgenden der Versuch unternommen werden, Kapazitäts-Management in seinen Elementen zu untersuchen.

Der Begriff Kapazitäts-Management wird denkbar unterschiedlich bewertet. Er wird als Sammelbegriff für den punktuellen Einsatz von Tuning-Software ebenso verwendet wie für die Philosophien über die Obergrenzen von Maschinenbelastungen. In fast allen Definitionen spielen geheimnisvolle drei- und vierbuchstabige Fachwortabkürzungen (zumeist aus der IBM-Terminologie) eine große Rolle, kaum wird jedoch über den eigentlichen Aspekt - nämlich Planung und Management - gesprochen. Weit verbreitet ist weiterhin die Meinung, daß Kapazitäts-Management eine Funktion der System-Programmierung ist. Doch auch hier muß man Zweifel anmelden.

Während der Zusammenhang zwischen den ersten Begriffen leicht einzusehen ist - je mehr Jobs pro Zeiteinheit, desto größer muß der Rechner sein - , sind die beiden nächsten Begriffe noch nicht so sehr im Bewußtsein der Verantwortlichen verankert. Deshalb an dieser Stelle einige Erläuterungen: Unter Service-Level versteht man das erreichte oder angestrebte Zeitverhalten eines Computers, also der notwendigen Zeitspanne zwischen Aufgabenstellung und Ergebnis-Präsentation. Für einen Online-Dialog ist dies die Zeitspanne vom Drücken der Eingabetaste bis zum Empfangen des Bildschirminhaltes, bei der Stapelverarbeitung betrachten wir die Zeit zwischen Einlesen eines Jobs und der Beendigung der Listenausgabe. Wenn die EDV-Abteilung ein solches Zeitverhalten mit dem Endbenutzer abspricht und vereinbart, spricht man von einem SLA (service level agreement).

Grundsätzlich wäre nahezu jeder Service-Level zu erreichen, wenn nicht an jedem Service-Level ein unterschiedlich großes Preisschild hängen würde! Ein Computer wird also um so teurer, je leistungsfähiger er ist (oder sein soll). Es wäre nun aber falsch anzunehmen, daß nur die DV-Kosten eine Rolle spielen.

Leider gibt es noch eine zweite Kostenkurve, welche "Benutzerkosten" genannt werden kann. Je leistungsfähiger eine DV-Anlage ist, desto größeren Nutzen kann ein Unternehmen aus ihr ziehen, und umgekehrt.

Während die DV-Kosten relativ einfach zu erfassen sind, wird es bei der Beurteilung der Benutzerkosten schwieriger. In einer kleinen Broschüre (The Economic Value of Rapid Response Time) versucht IBM unter verschiedenen Aspekten den kostenmäßigen Vorteil von extrem geringen Antwortzeiten zu belegen. Trotz der klar erkennbaren Absicht des Herstellers ist der Gedankengang der quantitativen Erfassung der Kosten für jede einzelne Transaktion hilfreich.

Ist es wirklich zu revolutionär, daß in der DV endlich Planungsgröße und Methoden eingeführt werden sollen, die jeder mittelmäßige REFA-Fachmann seit Jahrzehnten

verwendet? Würde man einen REFA-Fachmann befragen, welche Methoden er für die Kapazitätsplanung einer teuren Werkzeugmaschine verwendet, und würde dieser antworten, daß er sich ausschließlich auf Erfahrungswerte und Daumenregeln stütze, so würde in fast jedem Unternehmen der Karriere-Pfad dieses "Spezialisten" einen steilen Knick nach unten nehmen. Nur im Bereich der Kapazitätsplanung von DV-Anlagen können sich bis heute Spezialisten tummeln, die mit Begriffen wie "happy values", "golden values", "experience", "rules of thumb" (über den Daumen gepeilt) arbeiten! Dies sollte sich ändern.

Im Kapazitäts-Management sind sowohl reagierende Aktivitäten als auch agierende Aktivitäten enthalten. Beim ersteren müssen die folgenden drei Gesichtspunkte berücksichtigt werden:

- Aufbau einer geordneten Sicht vom gegenwärtigen System und Aussage über den augenblicklichen oder vorherigen Workload.

- Analyse der gegenwärtigen Leistungsfähigkeit (Performance).

- Analyse und Beseitigung von gegenwärtigen Engpässen.

Im Rahmen der agierenden Aktivitäten müssen die Projektionen auf den - zu erwartenden Workload,

- die Vorhersage des zu erwartenden Systemverhaltens,

- die Vorhersage von potentiellen Engpässen und

- die Überprüfung von geplanten Maschinenkonfigurationen

gelenkt werden.

Kann man in einigen DV-Betrieben Elemente aus der ersten Gruppe noch relativ häufig finden, so sind gegenwärtig die Chancen, Elemente aus dem zweiten genannten Feld zu finden, denkbar gering.

Im Hinblick auf die eigene Kapazitätsplanung sollte sich der Anwender eine Reihe von Fragen stellen:

- Wie groß ist die gegenwärtige Systemkapazität?

- Was wird von der gegenwärtig installierten Kapazität genutzt?

- Welche zusätzlichen Arbeiten können vom Rechner übernommen werden, bevor der Service-Level unter das gewünschte Maß absinkt? Sind überhaupt Service-Levels definiert?

- Welche Veränderungen können das System verbessern?

- Welche quantifizierbaren Auswirkungen haben diese Veränderungen auf den Service-Level?

- Wann müssen wir unser System verändern?

- Wie werden sich geplante Neuanwendungen auf das System auswirken?

Alle Systemkomponenten, die gegenwärtig oder zukünftig an einer Veränderung des Antwortzeitverhaltens beteiligt sind, bedürfen der Planung. Als Komponenten kommen nicht nur Einzelteile der Hardware, sondern auch des Workloads in Betracht wie Rechnerkomplexe, Leitungsnetz und Veränderung der Arbeitslasten.

Die These ist zwingend, weil "GIeichgewicht" nicht zeitweise zu erreichen ist; es muß ständig bewahrt werden. Dies ist bitter, weil es Aufwand und Investition - auch im Personalbereich - bedeutet. Einer der Gründe für das Versagen konventioneller DV-Planung ist im punktuellen Einsatz der Methoden zu sehen. Lediglich anläßlich der Finanzplanungsphasen machen sich DV-Manager gelegentlich Gedanken über vorhandene und notwendige Ressourcen. Da sich aber der Service-Level und auch die arbeitsmäßigen Anforderungen an den Rechner ständig verändern, muß Kapazitäts-Management durchgeführt werden.

Von der Notwendigkeit der Rechnerplanung ist ein großer Teil der Manager überzeugt. Viele Manager kennen zumindest gegenwärtige Auslastungszahlen der wichtigsten Rechnerkomponenten, über deren Aussagefähigkeit noch zu reden sein wird. Auch im Bereich der Leitungsplanung sind zumindest bei den Netzwerk-Koordinatoren größerer Installationen Auslastungswerte bekannt. Im Bereich der Abschätzungen zukünftiger Anwendungen dagegen konnten nur Aussagen über die eigene Hilflosigkeit oder Zorn über mangelnde Bereitschaft "anderer", Daten bereitzustellen, angetroffen werden. Dabei stehen alle notwendigen Informationen - zugegebenerweise an unterschiedlichen

Stellen der Organisationen - dem Kapazitäts-Management zur Verfügung. Was generell fehlt, ist die Normung all dieser Daten zwecks maschineller Auswertung. Dieser Mangel an genormten Einzelinformationen zur Erlangung von zukunftsorientierten Planwerten wird erst dann spürbar, wenn die Performance-Krise eingetreten ist.

Das zu erwartende Systemverhalten vorherzusagen, ist unbedingt notwendig. Bisher wurden jedoch nur Forderungen und keine Ansätze zur Erfüllung der Forderungen aufgezeigt. Anhand einer kurzen Beschreibung der gegenwärtig bekannten Methoden soll deshalb versucht werden, die Spreu vom Weizen der Methoden zu trennen.

- Der Benchmark

Der Benchmark ist die große Stunde der Experten. Sie analysieren den gegenwärtig benutzten Rechner und dessen Workload. Sie definieren die repräsentativen Lastanteile, schätzen den zukünftigen Workload, definieren die zukünftige Maschinen-Konfiguration, suchen ein Rechenzentrum mit ähnlicher Konfiguration, transferieren Programme, Daten und Systeme, bauen Transaktions-Driver, "fahren" den Benchmark, messen, regeln, bestimmen, schließen Betrachtungen ein und aus und bekommen zum Schluß ein Ergebnis, welches sagt: "Es geht" oder "Es geht nicht". Da aber immer noch ein Unsicherheitsgrad beim Management besteht, werden alle geschätzten Ressourcen noch einmal verdoppelt und den Lieferanten freut's!

- Die Trendberechnung

Der heutige Standard in der Erstellung von Aussagen über das zukünftige Verhalten eines Rechners ist die Trendanalyse. Man versteht darunter die Aufzeichnung der Belastungswerte einer Systemkomponente und die statistische Auswertung solcher

Datensammlungen. Über einen längeren Zeitraum hinweg werden die Belastungswerte einer Systemkomponente aufgezeichnet und die Durchschnittswerte für die Zukunft "hochgerechnet". Sobald sich dieser Wert einer sogenannten "maximalen Auslastungslinie" nähert, wird auf einen Engpaß geschlossen und dieser durch neue Hardware "beseitigt".

Unglücklicherweise hat diese Methode aber einige Nachteile:

- Der Ansatz für eine maximale Belastungsgrenze ist abhängig vom jeweiligen "Guru", der sie publiziert. Es existieren mindestens sechs unterschiedliche Belastungsobergrenzen (Guru-Linien) für eine "sinnvolle" Rechnerauslastung. Schon kleinere Änderungen an dieser Linie können bei flach verlaufenden Trendlinien große Differenzen für die geplanten

Installationstermine neuer Hardware ergeben.

- Das Systemverhalten (response time) ist keineswegs abhängig von der Verlaufslinie der Belastung einer einzelnen Komponente, sondern von einem sehr komplexen Zusammenspiel sehr vieler solcher Komponenten. Eine sinnvolle Interpretation einer Trendanalyse wäre also nur im Zusammenhang vieler Einzel-Trends (CPU, Kanäle, Laufwerke und Leitungen) möglich.

Bei der Trendanalyse wird davon ausgegangen, daß die starke Benutzung einer Komponente vom Kapazitätsstandpunkt etwas Schlechtes ist, eine fast unbenutzte Komponente dagegen etwas Gutes. Dies bedeutet doch aber, den Wirtschaftlichkeitsgedanken auf den Kopf zu stellen! Oder ist der ausgeschaltete Rechner die beste Lösung?

- Die Trendanalyse ist die institutionalisierte Anwendung der "Planung über den Daumen", da jene "Guru-Linien" nichts anders sind als Annahmen für ein gutes oder schlechtes Systemverhalten.

Trotz dieser negativen Kritik über die Trendanalyse sollen aus Vollständigkeitsgründen drei sinnvolle Anwendungen der statistischen Trendanalyse aufgeführt werden.

- Es ist durchaus sinnvoll, den Workload eines Rechners statistisch zu erfassen und ihn für die Zukunft abzuschätzen. - Durch die Erfassung von Belastungswerten wird das Optimieren eines Systems vereinfacht, weil durch einfache Auswertungen entstandene Engpässe nachträglich aufgezeigt werden. Dadurch kann das Tunen erleichtert werden.

- Eine Vielzahl von Belastungsdaten, sinnvoll miteinander verknüpft, ermöglicht dem Planer die Erstellung eines Belastungsprofils, welches Auskunft über Spitzenbelastungen geben kann.

Abgesehen von letzteren Punkten gibt es keinen sinnvollen Einsatz von Belastungsgrad-Auswertungen und deren Trends, wenn das Ziel des Kapazitäts-Managements eine Vorhersage und Planbarkeit des Service-Levels sein soll. Neben den technischen Argumenten sollte es einem Kapazitätsplaner schwerfallen, beim Management dafür Verständnis zu finden, warum ein Block-Multiplexer-Kanal nur zu rund 30 Prozent ausgelastet werden darf, wenn er doch zu 100 Prozent bezahlt werden muß .

- Die Modell-Rechnung

Die Möglichkeit, komplexe Zusammenhänge modellhaft zu erfassen und durch Veränderungen am Modell Auskunft über reale Gegebenheiten zu bekommen, ist nicht neu. Seit vielen Jahren untersuchen Automobil-Hersteller und die Flugzeug-Industrie neue Prototypen ihrer Produkte im verkleinerten Maßstab in Windkanälen. Durch Speicherung und Auswertung großer Mengen von Meßdaten im Computer optimieren sie neue Konstruktionen und bestimmen deren Verhalten. Ähnlich komplex sind die Probleme der Finanzplaner großer Unternehmungen. Auch hier werden die Parameter des Finanzgebarens modellhaft erfaßt, und durch DV-gestützte Berechnungen kann dann die mittel- oder langfristige Liquidität eines Unternehmens vorhergesagt werden. Alle Anwendungen von Modell-Rechnungen haben eines gemeinsam: Umfangreiche Datenbestände werden mittels intelligenter Programmsysteme in Aussagen über zukünftige Verhaltensmuster umgesetzt. Bedauerlicherweise ist die gleiche Methode in der Planung der DV noch heiß umstritten, obwohl die DV mit ihrer Leistungsfähigkeit die Modellrechnung für die anderen Abteilungen erst ermöglichte, und obwohl ähnliche Methoden und Werkzeuge zur Planung von EDV-Anlagen seit fast einem Jahrzehnt vorhanden sind.

Bei der Modellierung von DV-Anlagen benutzt man die vom Hersteller gelieferte Standard-Software zur Messung der Rechner-Komponenten. Die gelieferten Last- und Konfigurationsdaten werden zur automatischen Erstellung eines Modells benutzt, welches den Ist-Zustand der Maschine und den von ihr verarbeiteten Workload beschreibt. An diesem Modell können jetzt Veränderungen durchgeführt werden, welche zukünftige-Situationen beschreiben. Die Modellberechnung liefert dann neben den obligatorischen Belastungswerten aller Rechnerkomponenten auch das zu erwartende Antwortzeitverhalten des Rechners. Damit wären die Hauptkriterien erfüllt, die Jürgen Beust (Insotec Consult) in seinem Artikel "Bausteine für ein effizientes Kapazitäts-Management" in der COMPUTERWOCHE vom 1. November 1985 fordert.

Die hier geschilderte Methode gilt sowohl für die Planung des Rechners wie auch für angeschlossene Leitungsnetze. Beide Komponenten liefern Meßdaten. Bei der Bewertung neuer Anwendungen, das heißt in der Abschätzung notwendiger Hardware-Ressourcen für noch nicht realisierte Neuanwendungen gelten andere Verfahren.

Es wäre schon viel erreicht, wenn sich das DV-Management dergestalt sensibilisieren ließe, daß die Notwendigkeit eines aktiven, in die Zukunft gerichteten Kapazitäts-Managements erkannt würde. Kapazitäts-Management ist in erster Linie ein Problem des Managements und nicht ein Problem der "Kapazitäten", erst recht nicht eine statistische Überprüfung von Ressourcen-Füllungsgraden. Kapazitäts-Management sollte immer Responsezeit-orientiert sein, damit nicht eines Tages aus dem Antwortzeit-Problem ein Akzeptanz-Problem entsteht.

These 1:

Kapazitäts-Management ist eine Methode zum Erreichen beziehungsweise Erhalten der Balance zwischen Computer-Hardware, Arbeitslast, gewünschtem Service-Level und Kosten.

These 2:

Erfolgreiches Kapazitäts-Management ist eine Methode zur Planung und Eihaltung eines gewünschten Service-Levels unter Berücksichtigung der DV-Kosten und der Benutzerkosten. These 3:

Kapazitäts-Management ist keine punktuelle oder einmalige Tätigkeit, sondern eine ständige sich wiederholende Funktion im Ablauf des DV-Betriebes, gleichzusetzen mit anderen Tätigkeiten wie Programmierung oder Datenbank-Administration.

These 4:

Die teuerste Hardware ist die in der Performance-Krise beschaffte. Es gilt die generelle Aussage: Zeit ist Geld - gute Antwortzeit ist teuer - schlechte Antwortzeit ist sehr teuer. These 5:

Kapazitäts-Management muß sich ausschließlich mit Spitzenbelastungen beschäftigen.