Service orientiertes Rechenzentrum - doag.org · SAP HP Competence Center Service ... BBP EBP B2B...
Transcript of Service orientiertes Rechenzentrum - doag.org · SAP HP Competence Center Service ... BBP EBP B2B...
© 2006 Hewlett-Packard The information contained herein is subject to change without notice
Dr. Michael MissbachSAP HP Competence Center
Service orientiertes Rechenzentrum
adaptive virtualisierte Infrastrukturen für SAP
Wer ist ihr Sprecher?• Senior Consultant des SAP HP Competence Center in Walldorf,
verantwortlich für die Entwicklung von „best Practices“ für NetWeaver und mySAP Infrastrukturen
• Fokus auf Adaptiviät, Virtualisierung, Konsolidierung und Fehler-tolerante Infrastrukturen (daneben noch SAP Systembetrieb, ITIL & ITSM Netzwerke, System & Output Management.....auf Linux, Windows & Unix)
• Zuvor Leiter Werksmodernisierung und IT Superintendent Europa von ALCOA Chemicals sowie Projektleiter SAP Netze bei CompuNet.
“We ship three printers a second, we ship two PCs a second, we ship a server every 10 seconds, so our supply chain has to be continually moved. And if it's down for 10 seconds that's bad, because we've missed 30 printers, 20 PCs and one server. So we can't be down at all“
Mark Hurd, CEO Hewlett-Packard
SAP RUNS
ON HP
SAP & HP Partnerschaftüber 16 Jahre gemeinsamer Erfolg
1989 HP liefert R/3 Entwicklungsplattform1990 gemeinsames SAP HP Competence Center1991 HP Entwickler unterstützen R/3 Implementierung 1992 Erste R/3 Kunden produktiv auf HP-UX1993 > 100 Kunden auf HP, R/3 übertrifft R/2 1994 > 500 Kunden, erstes produktives NT von HP1996 >1.000 Kunden, erste gemischte UX/NT Inst. 1997 > 3.000 Kunden, erste fehlertolerante Lösungen 1998 > 4.500 Installationen1999 > 6.000 Installationen, erstes R/3 auf Linux, SAP
System Konsolidierung2000 > 7.000 Installationen, mySAP Infrastruktur Buch2001 >10.000 Installationen, PBO-Kernel, 2002 > 25.000 Installationen, CCMon, E-Xsid
> 1370 outsourced SAP Systems2003 > 35.000 Installationen, SAP Systembetrieb Buch
SAP HP Netweaver Competence center, 2004 > 40.000 Installationen, HP ITSM für SAP2005 adaptive Infrastrukturen für SAP
> 1700 outsourced SAP Systems2006 > 51.000 Installationen, Business Accelerator
2007 > 55.000, SOA discovery server, Duetappliance SAP auf Windows & Linux
© 2006 Hewlett-Packard The information contained herein is subject to change without notice
jenseits R/3 Enterprise -NetWeaver, ECC & SOA
Technischer Durchbruch
Gipfel der übertriebenenErwartungen
Tal derDeillusionierung
Bereich derproduktiven
Nutzung
Zeit
Virtualisierung und SOA – Märchen vonübermorgen? Der “Hype Zyklus”
IT Industrie hechelt den Trends hinterherLeichen im Keller bleiben liegen
Kleine Geschichte der Serviceorientierung
VMS
Client Server
open systems
KonsolidierungVirtualisierungopen source
SQL – damit Manager ihre Datenbank-abfragen selber schreiben können
Object orientierte Programmierung – damit die Entwickler die Abfragen die Manager wollen einfacher schreiben können
SOA – damit man sich nicht mehr um die Details der Abfragen kümmern muss sondern nur um den Geschäftsprozesse
Worin liegt der potentielle Nutzen von Web Services & SOA?
Mix aus Standard- und individuell programmierten Prozessen (Orchestrierung) erlaubt:
• Schnellere Implementierung und Anpassung von Prozessen
• Nutzung von Standard Geschäftsprozessen wo anders zu sein keinen Sinn macht mit individuellen Prozessen die einen Wettbewerbsvorteil bieten
75% Buy Packaged
Application
25%Build
typical Portfolio today: buy or make
Future Portfolio: best of both worlds
75% pre-packagedstandard solutions
25%Individual
Development
60% pre-packagedstandard solutions 10%
I.E.30%
composite applications
Funktionalität wichtiger als Technologie
Entschärfen des Spagats zwischen wettbewerbsgetriebener Individualität und kostengetriebener Standardisierung
Von R/3 zur Enterprise Service ArchitekturEntkoppelung von Process und Funktionalität
SAP Businessservices
IntegrationServices
„mySAP.com“
„newdimension“
„mySAP“
„Netweaver“
„integration“
„enjoy“
„ ESA“Enterprise Service Architecture
BI
ITS
CRMEP
Online Store
SFA
BI SRM XIR/3 4.7 SCM
R/3 3.1
R/3 4.0
R/3 4.5
R/3 4.6
APO
CCMS
EP
BC
Composite Applicationsvon SAP, Partnern oder individuell
BW
Workplace
BBP
EBP
B2B
HP ITSM (ITIL) & OpenView
• Betreibbarkeitsicherstellen
HP Mercury• Servicequalität
verbessern
HP Virtual Infrastruktur
• Betriebskosten senken
SolMgr
Source:Dr. Michael Missbach
HP/SAP Competence Center
SCM SRM CRM
MDM XIMI SSM
ECC
„ A1S“All-in-One SOA
The challenges of Enterprise SOA
Schlüsselfragen von SOA/ESA• Wie und wo sucht man eigentlich nach
Funktionalitäten?• Wie bestimmt man die notwendigen Ressourcen
für Enterprise/Web Services und wie budgetiert man sie?
• Wie sichert man die Konsistenz einer extrem verteilten Systemlandschaft?
• Wie wird die Verfügbarkeit von Enterprise/Web Services gesichert?
• Wie kann man den zusätzlichen Komplexitäts-level einer Enterprise Service Infrastruktur managen?
© 2006 Hewlett-Packard The information contained herein is subject to change without notice
preparing the infrastructure for NetWeaver & Enterprise SOA
SOA macht Unicode notwendig!
• R/3 Design als „single code page system“
• Single byte code pages sind limitiert auf 256 Schriftzeichen• Englisch: ~ 60 characters• “West Europäisch” : ~ 300 characters • Koreanisch: ~12.000 syllables• Mandarin: ~ 50.000 letters• Unicode ~ 90.000 characters
(and room for 1 Million more)
• Browser sind Unicode per default• Java gibt es nur als Unicode• XML gibt es nur als Unicode
• Unicode ist die Zukunft der SAP • (Default für alle Java Komponenten und ab ECC 6.0 auch für ABAP)
Änderungen des Ressourcen Bedarfs
R/3 Rel. 4.0 4.5 4.6C 4.7.1 4.7.2* ECC 5.0* ECC 6.0*
CPU +30% +20% +15% +5% +5-10% +5-10% +0-5%
Memory +30% +20% +20%(DB) +0-5%(DB) +0% +0% +0%+10%(App) +25%(App) +5-10% 5-10% +5-10%
Disk +10% +10% +10% +5-10% +0-5% +0-5% +0-5%
SAPnote 089305 0113795 0178616 517085 752532 778774 901070
* Unicode: ~ 35% mehr CPU, ~ 50% mehr Memory, ~ 35 – 70 % mehr Disk (abhängig von DB)
Praxis Erfahrung: Durch die Reorganisation beim Import / Export ergibt sich in vielen Fällen ein Reduktion des benötigten Plattenplatzes
Top 10 in SAP performance(source: http://www.sap.com/solutions/benchmark/index.epx)
SAPS
36.000
32.000
28000
24.000
20.000
16.000
12.000
8.000
4.000
0
Users
The highest SAPS number ever achieved
Why only ¼ of HP when Power
6 is so fast?
Pow
er6
AIX
/D
B2
Inte
gri
tyH
P-U
X /
Ora
cle
Pow
er5
AIX
DB2
Fujit
suSP
ARC
Sola
ris
Ora
Inte
gri
tyW
in/S
QL
Itani
umW
in/S
QL
SUN
Sparc
Sola
ris/
Ora
Itani
umW
in/S
QL
Fujit
suSP
ARC
Sola
ris
Ora Po
wer
5A
IX D
B2
0
5.000
10.000
15.000
20.000
25.000
30.000
35.000
0 16 32 48 64 80 96 112 128
cores
Ben
chm
ark
Use
r
SD ~ 2 secSD ~ 1 secrx6600 ~ 2 sec
Integrity auf HP-UX: lineare Skalierbarkeit(Quelle: offizielle Benchmarks und interne Messungen)
SAP auf Integrity in Europa
• Scalability• Reliability• Flexibility
Win
dow
sH
P-U
XLin
ux
Why HP Integrity?
• Price/performance• Reliability• Flexibility
Linux
Win
dow
sH
P-U
X
• Performance• Price• Multi-OSM
ulti
OSs
HEAD
• Scalability• Reliability• Flexibility
BMWBMW
Austrian Gov.
US Army (USAMITC)
BASF
SAP
More than 1650 reference
installations world wide
SAP & Itanium
“SAP customers can benefit immediately from improved performance and scalability in complex environments.
This proof point is a validation of SAP's immediate support of HP's Itanium based servers.”
Stephan RossiusSenior Vice President, SAP AG
•SAP ist Mitglied der Itanium Solutions Allianz
•SAP liefert NetWeaver und mySAP Lösungen für Itanium compiliert aus
•SAP implementiert die eigenen, internen ECC, BW und HR System auf HP Integrity Servern
•Microsoft nutzt 1.500 Integrity Server für die Entwicklung von Longhorn
SAP Installationen 2007:in total: 41.200 customers / 121.000 productive instances
AIX15%
Solaris11%
OS/3901%
OS/4003%
Linux2%
Windows42%
Other Unix1%
HP-UX17%
Tru643%
Operating SystemsDatabases
Informix2,74%
DB29,08%
Oracle65,82%
Sybase0,07%
MS SQL17,10%
MaxDB5,19%
Wie aufwendig ist der Umstieg?Einfach Xeon oder PA-Risc durch Itanium Rechner ersetzen,Daten bleiben auf der Platte und werden nicht angefasst!
• Umstieg von HP-UX von PA-RISC auf Itanium • Kein Daten Export/Import notwendig!• Fail over von PA-RISC auf Itanium unterstützt!
• Umstieg von 32-Bit Linux auf 64-bit Linux • Kein Daten Export/Import notwendig!
• Umstieg von a 32-Bit Windows auf 64-bit Windows• Kein Daten Export/Import notwendig!
• Migration von properitären UX (AIX, Solaris, Tru64)• Immer Daten Export/Import notwendig• (Für Tru64 auf HP-UX gibt es eine „Express Lösung)
for AIX, Solaris & true64:HP Smooth Transition Method
Ø Reducing downtime by a factor of 10 - 25- 300 (up to 500) GB/h instead of 100 GB/h- Including index rebuild and transfer of statistics
Ø High degree of automation & resilience - Risc mitigation- Reducing consulting effort - Reducing complexity
Ø DB reorganization inclusive (reduces DB size significantly)Ø Support via HP, OracleØ No migration key necessaryØ Hundreds of references
üdynamic processor resiliency
üüüSystem survives loss of a CPU
üdouble chip spare
üfull cache parity/ECC
üüüMemory spares
üüüüMemory SDEC
üdata bus error recovery/ECC
Xeon
üaddress bus parity protection
Capability OpteronXeon MPItanium
System Reliability Architecture
From a reliability standpoint Xeon and Opteron are equivalent to a bunch of disks (jbod) - Itanium is equivalent to a RAID Array
Gardner Group: due to missing ECC the SUN UE 10k reboots on average two
times a month
© 2006 Hewlett-Packard The information contained herein is subject to change without notice
HP Virtualization portfolio for SAP
The misunderstandings of virtualization
• virtualization is: “combining the maximum of flexibility with the necessary isolation”
• virtualization is NOT: “divide a big box into virtual boxes if the application didn't need it”
When somebody invent a new hammer suddenly every problem looks like a nail
Kaum zu glauben: mehrere SAP Systeme laufen gemeinsam auf einem Betriebssystem!1. Für alle mySAP und NetWeaver Lösungen auf Basis Web AS gilt:
• Wegen des Hardware abstraction layer (HAL) „sieht“ das Betriebssystem nicht die betriebswirtschaftliche Lösung sondern nur den Web AS und die Datenbankinstanz
• beide sind für alle Lösungen identisch, haben den selben Patch Level• Wegen downwards compatible kernel laufen sogar SAP Lösungen
mit unterschiedlicher Release zusammen
2. Unterstützt von SAP, HP, IBM, SUN, …..• SAP unterstützt sogar “multiple components – single database“
3. Kunden setzten es seit mehr als 7 Jahren produktiv ein• Bis hin zum Mix von Rel. 4.0 und 4.6, Rel 4.5 und 4.7,……
Genau dafür wurden Betriebssysteme entwickelt!
die zwei großen Fragen von Virtualisierung & Konsolidierung:
1. Ressource Isolation• Wie kann ich sicherstellen, das Performance Engpässe
nicht von einem SAP System auf andere übergreifen?
2. Security Isolation• Wie kann ich sicherstellen das Benutzer eines SAP
Systems unter keinen Umständen Zugriff auf Informationen in einem anderen SAP System haben?
Distributed versus central architecture
• Fixed DB : App ratio• Multiple OS instance need resources• DB App comunication cause Interupts
•Static load distribution
• Dynamic adapted DB : App ratio• Single OS instance resources• DB App Interprocess comunication•Dynamic load distribution
DB
CI*
App App
App App
App App
App
App
App
App App
App
App
App
App
DB
App
App
App
CI
App
App
CI
App
DBDB
AppAppCI*
App
The effect of „scale out“(real life measurement over 24h)
CPU Usage PZ1 05.06.07
0
10
20
30
40
50
60
70
80
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23ZR050050 (DB) zr051107 zr051108 zr051109 zr051110 zr051111 zr051112zr051158 zr051158 zr051159 zr051160 zr051161 zr051162 avg. (app server)
h
Night (batch) High load on DB,App idling around
Night (back-up) High load on DB And one App Svr
DB ServerApp Svr 1
App Svr 2App Svr 3
App Svr 4App Svr 5
App Svr 6App Svr 7
App Svr 8App Svr 9
App Svr 10App Svr 11
App Svr 12Avr. all App
day (dialog) High load onone single App Svr,
consolidated NetWeaver LandscapeMORE performance by
• Ideal load distribution DB-APP• Avoid latency and interrupts
Better utilization of system resources(Economics of scale)
• Leveraging “user peaks”• Better Buffer and Cache
Utilization LESS operation effortLESS maintenance fees Maximum flexibility at peak loadsOptimal utilization of system
resources • Leveraging “application peaks”• no round up syndrome
Maximized FlexibilityMinimized TCO
Possible with every database
BW AppBW DB
EP DBEP App
PI DBSSM
PI AppECC App MDM DB
ECC DB
MDM App
ICAP CPU`s
SRM AppSRM DB
The rounding-up syndromeSizing example for a mySAP Landscape:
ECC: 8.1 core rounded up to 10 core (5 sockets)BW: 5.2 core rounded up to 6 core (3 sockets)APO: 4.4 core rounded up to 6 core (3 sockets)CRM: 0.6 core rounded up to 2 core (1 sockets)SRM: 0.4 core rounded up to 2 core (1 sockets)EP: 2.1 core rounded up to 4 core (2 sockets)PI: 1.2 core rounded up to 2 core (1 sockets)
Scale up: 1 server, 11 dual core CPU in totalScale out: 7 server with 15 dual core CPU in total
max CPU load in relation to the number of CPU in a server
1Pw =
[ • - ] / [ ] × ( 1 - R ) + Rn!
(n × R)n
k!
(n × R)kn
k=•
This formula can be used to calculate the average load a system should not exceed in relation of the number of CPU’s for a given response time distribution:
max CPU for 1 secmax CPU for 2 secNumber CPU
83%89%1679%86%1276%84%1072%81%866%76%656%67%448%59%336%46%215%22%1
Consolidation is the business casebut:The concerns on Consolidation
1. Resource Isolation• How can I be sure that performance issues in one SAP
system does not hurt the others?
2. Security isolation• How can I be sure that users on one SAP system have
access to information's on other SAP systems?
Virtualization is the enabler!
HP virtual server environment (VSE) flexible resource management options for SAP consolidation
Best granularityBest isolation
Resource mgt. within a hard partition
HP v-parIntegrity VM
Resource mgt. within a operating system
HP PRMHP WLM
OS instance
OS instance
OS instance
OS instance
OS instanceSAP
system
SAPsystem
SAPsystem
SAPsystem
Resource mgt. within a SAP system
HP PRM & SGeSAP
OS instance
SAPSystem
Dialog
Dialog
Dialog
Batch
Batch
Batch
HP Superdome technology
OS partition
OS partition
OS partition
OS partition
Resource mgt. within a server
VSE Integrity Virtual MachinesJ unterschiedliche OS Patch Level möglichJ eigener SAPOSCOL per OSJ bis zu 20 Virtual Machines per coreJ bis zu 254 Virtual Machines per hard
partition / ServerJ 1 bis 4 virtuelle CPU’s pro VMJ Komplette Isolation von SAP / OS-
InstanzenJ Individuelle Reconfiguration und Reboot
möglichK Overhead durch Hypervisor (~ 8%)
Leistungsverluste durch shared I/O (~20 –30%), VM Version 3 mit dediziertem I/O
VM Host
SAP & Oracle
on UNIX
SAP & Oracle on Linux
SAP & Oracle on Windows
Bis zu 20 Guest OS (HP-UX, Linux, Windows) per core
HP virtual server environmentVmware HP SD Benchmark on Windows/SQLServer
• 2,070 SAPS (402 SD Users)• Average Response Time: 1.67 sec.• Windows Server 2003• VMware ESX Server 3.0.1
• 2 Virtual CPUs• 99% Virtual CPU Utilization
• BL460c• 2 procs/8 cores/8 threads• X5355 2.66 GHz (QC)• 32 GB Memory• 25% physical CPU Utilization
http://www.sap.com/benchmark
Vmware versus Integrity VM
Vmware; 1,00
Vmware; 1,87
Vmware; 3,43
Integrity VM; 1,97
Integrity VM; 3,86
Integrity VM; 1,00
0
1
2
3
4
1 2 3 4
Number of identical VMs with 2 Virtual CPUs
Scalab
ility Fa
ctor
VmwareIntegrity VM
HP - internal
SAP Certification Status for HP Integrity VM & VMware
* in case of an support issue the customer has to reproduce the error on a native system** a benchmark is a pre-condition for certification, but it does not replace the certification (which included a support agreement with Hardware vendors and VMware)
4
4
4
4
20
Max. virtual CPUs per single VM
Tolerated by SAP*
Tolerated by SAP*
Supported by HP
Supported by HP
Certified by SAP
Non-production
Benchmarked**GA pending
Tolerated*GA pending
Certification tests done
Certification tests done
Certified by SAP
Production
64 GB
64 GB
Physical Memory
Physical Memory
Physical Memory
Max. virtual Memory per single VM
LinuxVMware ESX Server
WindowsVMware ESX Server
WindowsHP Integrity VM
HP-UXHP Integrity VM
LinuxHP Integrity VM
GuestHost
Virtual Partitions & l-pars zero overhead virtualization
J Mehrere SAPOSCOL & verschiedene OS Patch Levels möglich
J Komplette Isolation von Anwendungs- und OS-Instanzen
J Pro CPU Granularität J Individuelle Reconfiguration
und Reboot möglich
Ermöglicht Konsolidierung von produktiven und nicht-produktiven Systemen auf einem Rechner
5678
CPU1234
25% SAP QA 3
15%SAP QA 2
60% SAP QA 1
25% SAP Prd 1
70% SAP Prod 3
5%SAPPrd 2
825%
SAP QA 315%SAP QA 2
60% SAP QA 1
CPU1234567
25% SAP Prd 1
70% SAP Prod 3
5%SAPPrd 2
VSE Process resource partitioning
Garantierte Leistung für konsolidierte mySAP SystemeLimits können dynamisch geändert werden (ohne reboot)
CPU1234
25% SAP Sys 3
15%SAP Sys 2
60% SAP Sys 1
CPU1234
25% SAP Sys 1
70% SAP Sys 3
5%SAPSys 2
HP Resource Manager
J dynamische Zuteilung der verfügbaren CPU & I/O Leistung auf mehrere SAP Systeme in %.
J Transparent für Anwendung (erweiterter Zeitscheibenalgorithmus)
K Nur eine OS Instanz und damit auch nur ein SAPOSCOL
VSE Work-process management innerhalb einer Web AS Instanz HP ServiceGuard extension für SAP
Dynamische Änderung der Ressourcen-verteilung zwischen Dialog und Batch ProzessenL In einem SAP System kann man
einen Dialog zu einem Batch WorkProzess machen, aber nicht deren Last-verhalten beeinflussen
J Mit dem VSE Workload management Toolkit kann die Verteilung der CPU Zyklen auf Batch und Dialog Prozesse im laufenden Betrieb geändert werden
Dialog
Dialog
Dialog
Batch
Batch
BatchDialog
Dialog
Dialog
Batch
Batch
BatchDialog
Dialog
Dialog
Batch
Batch
Batch
Was ist mit dem Hauptspeicher ?
F Der Hauptspeicher eines SAP Systems kann mit OS Virtualisierungmethoden nicht beeinflußt werden!
L Der von einem SAP System allokierte Hauptspeicher kann nur durch rebooten geändert werden.
J Ein neuer SAP Profile Parameter ermöglicht es SAP Instanzen aktuell nicht genutzte Teile des extended Memory an das Betriebssystem zurückzugeben ("disclaim"), so das es von anderen SAP Anwendungen verwendet werden kann.
J signifikante Verbesserung in der Nutzung des physikalischen Hauptspeichers für das extended Memory der SAP Instanzen
J Verfügbar ab• HP-UX 11i v2 on Itanium oder PA-RISC • 4.6D Patch Level 2088, 6.40 Patch Level 81, 7.00 Patch Level 14
• Implementation beschrieben in SAPnotes 724140 und 735566
Using the New “disclaim”-Feature
Memory “disclaim” enabled
Dynamic SGA
reallocation
RAM
Oracle‘s Dynamic SGA feature
OraSID1SGA: 32GB
OraSID2SGA: 32GB
OraSID1SGA: 48GB
OraSID1: SGA_MAX_SIZE = 96 GBOraSID2: SGA_MAX_SIZE = 96 GB
OraSID1: SGA_TARGET = 32GBOraSID2: SGA_TARGET = 32GB
OraSID2: SGA_TARGET = 16GBOraSID1: SGA_TARGET = 48GB
OraSID2SGA: 16GB
Buffer cache
Sharedpool
Largepool Large
pool
Sharedpool
Buffer cache
Buffer cache
Largepool
Sharedpool
Pagefile
96GB 96GB
SGAs
SGAsRAM
SGAs
vPar dynamic memory migration &Oracle Dynamic SGA
OraSID1SGA: 32GB
Buffer cache
Largepool
Sharedpool
SGA
RAM
Processspace
vpar1
OraSID2SGA: 32GB
Buffer cache
Largepool
Sharedpool
SGA
RAM
Processspace
vpar2
OraSID1SGA: 48GB
Buffer cache
Largepool
Sharedpool
SGA
RAM
Processspace
vpar1
OraSID2SGA: 16GB
Buffer cache
Largepool
Sharedpool
SGA
RAM
Processspace
vpar2
OraSID2: SGA_TARGET = 16GBvpar2: vparmodify –d <memory>vpar1: vparmodify –a <memory>OraSID1; SGA_TARGET = 48GB
Accounting and monitoring of virtualized SAP Infrastructures
SAPS
• Tracking of configuration changes (changes of Partition size (CPU, Memory, disk space), activation / deactivation of CPU and Servers, move of a complete SAP system in-between Server)
• Meassurement of “consumed” Resources(kiloSAPShours, IOPS, Memory, disk space) for virtualized and consolidated environments
• Analyze the system response on transaction load (graphical View and correlations, for example number of user versus CPU load or SAPS, Memory and IOPS; ....)
SAPS-O-Metera Web Service for Reporting of resource consumption and configuration changes for adaptive SAP Systems
SAPS-O-Metera Web Service with mutual benefit
• Accounting to business units based on measurement of consumed Resources(kiloSAPShours, IOPS, memory, disk space) for virtualized and consolidated environments
• Documentation of the actual system configuration• Improvement of Quality of the sizing process by
analysis of the system response to changes of transaction load
• Enablement of SOA sizing• Comparison with Peer Group
SAPS-O-Meter web service architecture
Customer Datacenter SAP HP Competence Center
xmlmessage
xmlreport
Peer group
Database
SAPS-O-MeterAnalyse Machine
Monatlich
täglich
Service Manager
SAPS-O-Meter web agent
BW
MeasureWare
CCMSCRM CCMS
ERP CCMS
SAPS-O-Meter report (example)
| 6002.0008/26/2007---13:50| 690.0008/24/2007---00:40| 1.3508/24/2007---10:35
| 008/26/2007---13:50| 6546.0008/26/2007---11:05| 837.0008/26/2007---10:00| 1.6508/26/2007---11:40
| 208/26/2007---13:35| 6550.3008/24/2007---00:50| 840.0008/26/2007---09:10| 2.1008/26/2007---09:10
UsersRAMIOPSSAPS
Top 3
0,28Average User:
6016,76Average RAM:
634,24Average IOPS:
26,48Used kIOPSh:
0,04Used kSAPSh:
SidID: TDO
SAPS-O-Meter –comparision with peer group
Number of User
Resp
onse
tim
e
Transactions
DB
grow
th ra
te
Number of User
Tran
sact
ions
Transactions
Use
d SA
PS, M
em, I
OPS
SAPS-O-Meterein Web Service von dem alle profitieren
• Leistungsverrechnung aufgrund der tatsächlich „verbrauchten“ Ressourcen (SAPS, Mem, Plattenplatz, IPOS) auch für virtualisierte und konsolidierte Systemlandschaften
• Erkennen der Ursache – Wirkungszusammenhänge bei Konfigurationsänderungen
• Verbesserung des Sizing Prozesses durch Analyse der realen Systemantwort auf wechselnde Transaktionslasten
• Dokumentation der aktuellen Systemkonfigurationen• Vergleich mit Peer Group
Praxisbeispiel: SAP University Competence Center Magdeburg
• Mehr als 40.000 Benutzer • Mehr als 130 Institutionen• Mehr als 100 SAP Instanzen • Server-Farm mit 135 Servern
und 85 TB Storage• Weltweite Referenz für SAP &
HP in Forschung und LehreKlassischer Ansatz: „1 Server per SAP Instanz“ führt zu:L Verschwendung von HardwareressourcenL Hoher Betriebsaufwand und -kosten
Praktische Erfahrung mit HP VSE
• Konsolidierung von 135 auf 8 Server ist machbar• Drastische Reduktion der zu administrierenden Instanzen• Wesentlich mehr Mandanten per Instanz
• Virtualisierung aller Systeme• Keine fixe Zuordnung von SAP Systemen und Server Hardware• Lastabhängige re-allocation der Hardware für SAP Systeme
Effektivere Ressourcennutzung:Ø Verringerter Bedarf an RechenzentrumsflächeØ Verringerter Energieverbrauch, weniger KühlleistungØ Verringerte administrative Kosten (6 Admins für > 40.000 Users)Ø Kosteneinsparungen von ca. 30% (konservativ gerechnet)Ø Return on Investment (ROI) 53%http://www.hcc.uni-magdeburg.de/ssi/public/hcc/about.shtml
SAP RUNS BEST
ON HP