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

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

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“

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

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)

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

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

CPU-Usage

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?)

Beispiele aus Ganglia

Ganglia (2)

Ganglia (3)

Nmon (interaktiv)

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

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

SAP runs best on POWER

PowerPoint

Fragen? Fragen!