Sizing von SAP-Systemen - SAP-Hefte

2 Sizing-Methoden
Re-Sizing
Grundvoraussetzung für ein Re-Sizing ist, dass sich nur
das Durchsatz-/Benutzervolumen ändert, nicht aber die
Funktionalität. Mithilfe der aktuellen Lastsituation und
der neuen Information können Sie einfach mit dem Dreisatz
den zukünftigen Bedarf ermitteln.
Ein typisches Re-Sizing fi ndet bei Systemkonsolidierungen
oder im sogenannten Phased Rollout statt, in dem
die Kunden ihre neue Software in Phasen in den verschiedenen
Landesgesellschaften installieren.
Re-Sizing eines Produktivsystems
Auf der Grundlage des obigen Beispiels (siehe Kasten
oben, Beispiel für die Analyse eines Produktivsystems)
könnte ein Re-Sizing folgendermaßen aussehen: Zu
den 1 567 defi nierten Benutzern sollen noch 200 hinzukommen.
Unter der Annahme, dass das Verhältnis
von bekannten zu aktiven Usern bei den neuen Benutzern
identisch ist, und dass sie auch das Gleiche tun
werden wie die bisherigen, kann man folgende Rechnungen
aufstellen:
� Aktive Benutzer
Das Verhältnis zwischen 200 und 1 567 ist 12 %,
woraus folgt, dass die Zahl der aktiven Benutzer
wahrscheinlich auch um 12 % steigen wird.
� CPU-Datenbankserver
34 % + 12 % entsprechen 34 % × 1.12 = 38,1 %
38 % Auslastung für einen Datenbankserver sind
ausreichend. Viele Kunden planen eine Zielauslastung
des Datenbankservers von 25 bis 50 %.
� CPU-Applikationsserver
56 % + 12 % entsprechen 56 % × 1.12 = 62,7 %
62,7 % Auslastung können die Applikationsserver
gut verkraften. Jedoch planen viele Kunden eine
Zielauslastung der Applikationsserver von ca. 30
bis 50 %, weshalb man über eine Erweiterung zumindest
nachdenken könnte.
� Hauptspeicher
26 GB (von 32): 26 GB × 1.12 = ~ 29 GB
29 GB von 32 GB allokiertem Speicher könnten
knapp werden. Es wäre also ratsam, die Speicherkapazität
zu erweitern.
16 © Galileo Press 2007. Alle Rechte vorbehalten.
�
Datenbankplatz
7 GB Wachstum entsprechen 7 GB × 1.12 = 8 GB im
Monat
Derzeit werden 312 GB von 512 GB verwendet.
Wenn die Datenbank um 96 GB (8 GB × 12 Monate)
im Jahr wächst, könnte es in recht kurzer
Zeit zu Engpässen kommen. Hier sollte also ebenfalls
aufgestockt werden.
Delta Sizing
Da die Bedingung beim Delta Sizing ist, dass neue Funktionalität
zu bestehender Applikationssoftware hinzugefügt
wird, ist das Vorgehen analog zum initialen Sizing,
nur dass die Sizing-Ergebnisse auf die aktuelle Auslastung
gerechnet werden.
Es gibt jedoch eine Besonderheit, die Sie berücksichtigen
sollten: Die Standard-Sizing-Regeln von SAP geben
den CPU-Bedarf in SAPS an sowie auf eine Zielauslastung
von 65 %. Wie wir in Abschnitt 9.2, SAP Application Performance
Standard, zeigen, hat jede Hardwarekonfi guration
im SAP-Umfeld ihren eigenen SAPS-Wert, den die
Hardwarehersteller jederzeit und für jedes Release angeben
können. Mithilfe dieser Information (zur Verfügung
stehende SAPS, Software-Release, CPU-Auslastung, neue
SAPS) können Sie leicht mit dem Dreisatz errechnen, ob
die Hardware ausreichen wird.
Delta Sizing eines Produktivsystems
Der Kunde von oben hat ein Sizing für eine neue
Anwendung erstellt. Das Sizing besagt, dass diese
Anwendung 1 200 SAPS benötigen wird (240 Datenbank-SAPS
und 960 Applikations-SAPS). Das einfache
Vorgehen ist nun, die SAPS-Werte zu addieren und
dann die Zielauslastung zu bestimmen.
Die vorhandene Hardware ist folgendermaßen bewertet:
� Datenbankserver 4 000 SAPS, die zwei Applikationsserver
mit je 2 800 SAPS
� derzeitiger Netto-SAPS-Verbrauch bei der Datenbank
ist 1 360 SAPS (34 % von 4 000 SAPS), und
auf der Applikationsebene 3 700 SAPS (56 % von
5 600 SAPS)