Hard- und Softwarekapazitätsbedarf zu planen, ist kein einfaches Unterfangen. Viele unserer Großanwender befassen sich damit - meist in Verbindung mit Aufgaben wie Performanceüberwachung, Tuning und so weiter. Unsere Benutzervereinigung hat hierfür eigens eine Task-Group eingerichtet: häufig zum Einsatz kommen hier Monitore unterschiedlicher Art.
Monitorsysteme geben aber meist nur Aufschluß über den Ist-Zustand. Man gewinnt Erkenntnisse über Engpässe und Basisdaten für Optimierungsaktivitäten - zum Beispiel für eine bessere Verteilung der Dateien auf die verfügbaren Laufwerke. Für die Kapazitätsplanung kann man das Vorhandensein von Reserven erkennen - aber reichen sie aus?
Besser als Hard- oder Softwaremonitore scheinen für die Kapazitätsplanung Simulationssysteme geeignet zu sein, die es erlauben, bei jedem Analyselauf Hard- und Softwaremodifikationen zu spezifizieren, um sich so an die optimale Hard- und Softwareumgebung "heranzutasten".
Physikalische Abbildung
So setzten wir zum Beispiel mehrfach mit Erfolg unser Simulationssystem "Cuesta" ein, bei dem die Testkonfiguration mit einem Treibersystem gekoppelt wird, das die spezifizierte Last simuliert. Entscheidend bei Cuesta ist, daß das geplante DFÜ-Leitungsnetz auch physikalisch abgebildet wird, Testsystem und Treibersystem werden mit entsprechend vielen DFÜ-Leitungen hardwaremäßig gekoppelt.
Damit sind die ansonsten schwer "in den Griff" zu bekommenden Bedingungen hinsichtlich Leitungsverhalten, Warteschlangen-Probleme und so weiter hardwaremäßig und real in die Simulation einbezogen.
In einem Fall konnten wir zum Beispiel mit Hilfe von Cuesta exakte Aussagen über den erforderlichen Kapazitätsbedarf für ein geplantes Online-System mit mehreren hundert Terminals ermitteln, indem bei den einzelnen Testläufen ständig Veränderungen an der Hardwarekonfiguration sowie Varianten der Tuningparameter zum Zuge kamen. Von besonderem Vorteil war, daß die Applikation bereits programmiert war.
Schätzprobleme
Damit war ein Problem der Kapazitätsplanung nur zum Teil bewältigt: die Spezifikation des auf die Zukunft projizierten Kapazitätsbedarfs. Hier interessieren im wesentlichen zwei Problemkreise: quantitative und qualitative Bezugsgrößen. Die quantitativen (nämlich exakte Mengengerüste wie Anzahl der Bewegung, Verteilung auf Spitzenzeiten und so weiter) stellen aus Anwendersicht oft ein größeres Problem dar, als man zunächst vermuten könnte.
Vielfach ist man nicht in der Lage, dazu auch nur annähernde Angaben zu machen, oder es stellt - sich im nachhinein heraus, daß eminente Abweichungen von vorgegebenen Planungszahlen aufgetreten sind. Insbesondere ist dies bei der Planung von Applikationen festzustellen, wo man oft nicht weiß, wie sich die Sache anlassen wird, oder wo man den Appetit der einmal auf den Geschmack gebrachten Anwender am Terminal unterschätzt.
Die Spezifikation der qualitativen Bedingungen, etwa die CPU-Belastung durch eine Terminaltransaktion, läßt sich meist nur analytisch ermitteln, es sei denn, daß wie im zitierten Beispiel bereits fertige Programme vorliegen. Ein guter Ansatz ist hier die Erstellung von synthetischen Programmen, die beispielsweise 15 Plattenzugriffe, 180 Additionen und so weiter für eine Transaktion simulieren.
Sporadischer Bedarf
Auch Benchmarks sind ein geeignetes Mittel, sofern es gelingt, die geplanten Bedingungen in den Benchmark-Spezifikationen unterzubringen, was vielfach kaum der Fall ist. Die Problematik der Spezifikation - Basiswert für eine langfristige Kapazitätsplanung - führt auch an die Grenzen der Planbarkeit.
Lassen sich zum Beispiel Plattenspeicherkapazitäten noch relativ einfach planen, indem für den wachsenden Speicherbedarf der Datenbank die erfahrungsgemäß zuverlässigen Zuwachsraten herangezogen. werden, so ist es kaum machbar, den CPU-Bedarf für sporadisch auftretende Applikationswünsche der EDV-Nutzer zu planen.
Ein plötzlich auftretender Markttrend, eine Fusion oder die Entdeckung der Techniker, daß es mit Timesharing-Fortran viel leichter und kostengünstiger geht, zwingt dann häufig zu kurzfristigem Kapazitätsanbau, es sei denn, man plant Reserven von Anfang an ein. Gut beraten ist jeder Anwender, dessen System über ein hohes Maß an Flexibilität verfügt und dessen Hersteller kurze Lieferzeiten anbieten kann.
Stufenweise von 1 bis 8,5
Unser Großsystem DPS 8 hat sich speziell hinsichtlich der Flexibilität hervorragend bewährt: Es kann sowohl innerhalb der vier Modelle als auch in bezug auf die Multiprocessingfähigkeit - bis zu vier Prozessoren sind in einem System konfigurierbar - vor Ort aufgebaut werden. Dies. bedeutet eine Leistungsbandbreite von Faktor 1 bis zu Faktor 8,5. Ein Anwender, der zur Kapazitätserweiterung gezwungen ist, braucht sein gekauftes System nicht in den Keller zu stellen, um das nächsthöhere Modell zu installieren. Wir bauen das System im Felde auf die erforderliche Leistungsstufe aus.
*Josef Fischer ist bei der Kölner Honeywell Bull AG im Bereich Marketing für die Großkundenbetreuung zuständig.