GUUG-Frühjahrfachgespräche Ressourcen- und Performance- Management für SAP auf Power-Systemen Jochen Hein 13.03.2009.

Präsentation zum Thema: "GUUG-Frühjahrfachgespräche Ressourcen- und Performance- Management für SAP auf Power-Systemen Jochen Hein 13.03.2009."—  Präsentation transkript:

1 GUUG-Frühjahrfachgespräche Ressourcen- und Performance- Management für SAP auf Power-Systemen Jochen Hein jochen@jochen.org 13.03.2009

2 Agenda ● Hintergrund ● Anforderungen von SAP-Systemen ● Virtualisierung auf Power-Systemen ● Nutzung von Virtualisierung ● Naives Monitoring ● Sinnvolles Monitoring ● Fazit

3 Hintergrund ● Outsourcing-Vereinbarungen ● Bereitstellung von SAP-Leistung (SAPSe) ● Baseline (Mehr- bzw. Minderleistung) ● Dynamische Zuordnung von SAN-Storage, Hauptspeicher und CPU-Ressourcen Zukunft: ● Notfall-RZ ● dynamische Verlagerung ● „Adaptive Computing“

4 Anforderungen von SAP- Systemen ● Viele Benutzer = Viel CPU und viel Speicher ● Java-Instanzen benötigen viel Speicher ● Memory für Datenbank, Puffer und Work-Prozesse ● Storage oft im Terabyte-Bereich ● Backup-Laufzeiten ● Genügend CPU-Leistung: 4x1GHz und 8x500MHz sind nicht gleich

5 Virtualisierung auf Power- Systemen ● LPARs: Logical Partitions auf einem Blech ● Kein Micro-Partitioning ● Keine VIO-Server, sondern physische LAN- und FC-Adapter ● Relation: eine CPU hat 8-16 GB RAM ● Box mit 16 CPUs hat n SAPSe – eine CPU wird mit n/16 SAPSen bewertet; Anpassung in 0,1 CPU-Schritten (auch 0,01 möglich) ● minimale/maximale Grenzen für dynamische Änderungen korrekt setzen (Memory, CPU) ● CPU-Pooling (nur ganze CPUs)

6 Nutzung von Virtualisierung ● Online-Anpassung von CPU und Hauptspeicher in vordefinierten Grenzen ● Gemeinsame dynamisch Nutzung des CPU-Pools (nicht benötigte Leistung steht anderen LPARs zur Verfügung) ● Nicht alle LPARs nehmen am Pooling teil ● Auf Power5-Systemen: Dummy-LPAR zum Steuern der SAPSe-Pools ● Zukunft: SAN Volume Controller, LVM mit SAN-Platten

7 Naives Monitoring ● In einer LPAR sind virtuelle CPUs definiert ● Virtuelle CPUs hier gleich physische CPUs in der Box ● SAP/Xandria: aktuelle CPU-Last in Relation zur Anzahl virtueller CPUs ● Auslastung ist „sehr niedrig“, auch wenn die „entitled capacity“ ausgeschöpft ist ● „entitled capacity“ mit topas, nmon oder vmstat sichtbar – aber nur als Snapshot

8 CPU-Usage

9 Sinnvolles Monitoring ● SAN-Storage (Dateisysteme, Datenbanken) wie gehabt ● Memory nur in Bezug auf jeweilige LPAR ● CPU-Last relativ zur „entitled capacity“ (Paßt der Wert der vorgesehen Kapazität zur abgeforderten Last?) ● Auslastung des CPU-Pools durch alle LPARs (Reicht die Leistung der Box noch für die LPARs?)

10 Beispiele aus Ganglia

11 Ganglia (2)

12 Ganglia (3)

13 Nmon (interaktiv)

14 Steuerungs-Möglichkeiten ● Lastverteilung im SAP (Zentral- und Dialog-Instanzen, Logon-Groups, Jobsteuerung) ● Langläufer bzw. Ressourcen-Fresser in betriebsarme Zeiten verlagern ● Performance-Analyse: Anpassungen von Anwendungen und SQL-Statements ● Arbeitsweise der Anwender bei Riesen-Queries hinterfragen ● Zuschalten/Wegnehmen von CPUs und damit Speicher ● SAPS-neutral: SAP-System in bestehende LPAR zusätzlich installieren

15 Fazit ● Nicht alle Virtualisierungs-Features sind für SAP-Systeme sinnvoll ● Definition der Messgrößen notwendig ● Monitoring der Messgrößen ● Verfahren bei Über-/Unterschreiten von Grenzwerte in Abstimmung mit dem Kunden ● Überblick: Ganglia (Grafische Auswertung, Konsolidierung mittels RR-Datenbanken, Trendanalyse) ● Detail-Analysen: nmon-Auswertung je Tag

16 SAP runs best on POWER

17 PowerPoint

18 Fragen? Fragen!