© 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