Big Data: Virtualized SAP HANA Performance,

Scalability and Best Practices

Bob Goldsand, VMware

Todd Muirhead, VMware

VAPP5591

#VAPP5591

2

Agenda

SAP/VMware Partnership

• Performance Validation of SAP HANA Running on vSphere 5.x

• Workloads Used and Test Results

SAP HANA on VMware: Benefits/ROI

• Virtualized HP AppSystems for SAP HANA

• Consolidation/Deployment of multiple HANA Test & Development Instances

• SAP Co-Innovation Lab

• SAP HANA using VMware Technologies:

• vMotion, Distributed Resource Scheduler (DRS), High Availability (HA)

3

HANA on vSphere Begins

SAP and VMware Partnership

• Both want HANA to run on vSphere

• Create team and assign resources to test

• Goal of achieving good performance

HANA on vSphere Project Begins

• Starts October 2011

• Determine performance profile of HANA on vSphere

• Correctness, Performance, Consistency, Scale

• Work together to develop best practices

• HANA on vSphere setup in both SAP and VMware labs

4

HANA and vSphere are Neighbors

5

State of HANA in Early 2012

HANA is an In-Memory DB

• Was code named NewDB

• Provides extreme performance improvements

HANA is a Hardware Appliance

• Preinstalled and configured by partner

HANA is sold by certified partners

• HP, IBM, Fujitsu, Hitachi, Cisco, Dell, and VCE

HANA is the Future for SAP

• HANA is strategic

• HANA is rapidly growing

6

HANA on vSphere 5.x Test Results Summary

No functional errors or issues after 18 months of testing

Performance observed to be within 10% of native

Profile of performance consistent with native

Scale of performance consistent with native

Workload vSphere 5.1

XS HANA VM

vSphere 5.1

M HANA VM

CBTR 6.5% 5.7%

SAP-H -7% -2.6%

BW-EML Throughput 4.5% 4.6%

BW-EML Response Time 9% 6.2%

Native vs Virtual HANA Performance Tests

Virtual Within 10% of Native in Tests Conducted

7

HANA on vSphere Testing Overview

Characterize the performance of HANA DB on vSphere 5.1 under

realistic workloads

2 configurations investigated on native and virtual

• XS HANA w/ 10 cores, 20 HTs, 128GB

• M HANA w/ 40 cores and 512GB

3 realistic workloads identified by SAP

• SAP-H based workload

• OLAP, DB Size=22GB, CPU Utilization > 95%

• CBTR from the Hasso Plattner Institute (HPI)

• Mixed OLAP & OLTP, DB Size=60GB, CPU Utilization > 85%

• Enhanced Mixed Load (BW-EML)

• Mixed OLAP Query Execution & Data Loading, DB Size=200 million records, CPU

Utilization ~ 80-90%

8

Testing: Hardware Configuration

HANA on vSphere Hardware

CPU (4 sockets) Intel Xeon E7-4870

@2.40GHz

Westmere-EX

w/ Hyper-Threading

Memory 1TB DDR3 1067MHz

DISK (SSD) 8x Crucial CT256M4 256GB 2.5in drives

RAID Intel 9265-8i RAID5 – OS partition

RAID0 – Data & Log

9

Testing: Software Configuration

VMware ESX-5.x

• Standard release builds, no special tuning

• Enable Hyper-Threading

• No CPU or memory over-commit

• Fit HANA within NUMA Nodes when possible

• (tests pinned VM vCPUS and native CPUs to NUMA node)

Guest OS

• SLES-11 SP2 (w/ default large pages)

• HANA 1.00.31.362930

• Generic HANA and HANA Studio

• VMXnet-3 vNIC

• 3 pvSCSI virtual controllers – OS, data, log

10

HANA on vSphere Testing Results – SAP-H

SAP-H Results

• XS was ~ 22 GB DB and M was ~75 GB DB

• 95% CPU Utilization

• Results Measured in Queries Per Hour (QPH)

• 30 Minute Test Runs

• XS

• Over multiple test runs Native and VM achieved nearly identical performance (QPH)

• Tests consistently show VM ~7% faster than native (could be resource mgmt effects)

• Medium

• Again over multiple test runs both the native and VM achieved similar performance

• The average throughput difference between native and virtual decreased by 4% with

respect to XS tests

SAP-H - QPH %Difference

XS HANA +7.0%

M HANA +2.6%

11

CBTR Detailed Results

CBTR Results

• 60 GB Database, “size” of 2 million

• 85% CPU Utilization

• Mix of 9 OLTP and 4 OLAP Queries – typical business operations

• XS

• Performance of CBTR mixed OLAP / OLTP test shows VM ~6% slower than native

• Medium

• Scaling from 10 to 40 cores, both virtual and native performance increased almost

linearly @ ~90% CPU load

• Performance difference remains at ~6%

Average RT (ms) %Difference

XS HANA 6.5%

M HANA 5.7%

12

Low Performance Variation = Consistent Performance

OLTP and OLAP have similar characteristics

13

BW-EML Results

Database of 200 million records

450 Users

Mixed Query Execution and Data Loading

CPU Utilization 80-90%

%Diff

XS Throughput (Dialog Steps / sec) 4.5%

XS Response Time (msec) 9.0%

M Throughput (Dialog Steps / sec) 4.6%

M Response Time (msec) 6.2%

14

BW-EML Detailed Results

0

5000

10000

15000

20000

25000

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41

Av

g R

es

po

ns

e T

ime

Dialogue Step

Response Time for Each Dialogue Step

VM LargePages

BM 450 Users 2nd Round

15

Medium BW-EML Testing Results

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

50000

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

Medium HANA VM vs BM BW-EML Individual Dialog Step Response Time

VM

BM

16

Testing Update with vSphere 5.1 Results

The isolated tests for all three workloads were run on vSphere 5.1

• Slight performance gain across all three workloads

• SAP-H VMs slightly better than native

• Results vs. native:

Linux kernel “transparent huge pages”

• Worth 3% - 4%

vSphere 5.0 vSphere 5.1

CBTR 9 % 6.5%

SAP-H -1% -7%

BW-EML Throughput 5 % 4.5%

BW-EML Response Time 10.5% 9%

17

HANA Performance Perspective

HANA Case Study

• Native only case study

• HANA used instead of traditional RBMS

• Westmere-EX with 64 GB RAM

• 1,800x improvement for a specific operation

• Gathers 600 data points from 336 million

• Traditional RBMS – several minutes

• HANA – 1 second

Potential of virtual HANA

• Theoretical application of 10% difference for virtual

• Result increases from 1 second to 1.1 seconds

• Big gains from using HANA are essentially the

same

Verification of SAP HANA Performance in the

Analysis of Massive Volumes of Data,

http://www.intel.com/content/dam/www/public/us

/en/documents/case-studies/performance-xeon-

e7-nomura-research-institute-data-analysis-

study.pdf, 2011

18

vMotion with HANA Lab Tests

Successfully Completed vMotion of 128GB and 256GB HANA VMs

• Move live running VM from one physical host to another physical host

• No interruption to DB or connected clients

• Lab tests done with mixed OLAP and OLTP workload running

• VM at approximately 85% utilization across 20 vCPUs

• 10G Ethernet required

• No noticeable or measureable impact on performance of test run

• Test run lasts for approximately 20 minutes

• Performed multiple vMotion migrations each test

• Each vMotion took approximately 2 to 5 minutes

19

HANA on vSphere Best Practices

No special tuning, just standard DB best practices

• Standard database best practices for vSphere

• Reserve memory

• Paravirtual vSCSI Disk Adapters

• Vmxnet3 virtual Network Adapters

• No CPU or Memory overcommitment

• Keep NUMA in Mind for CPU and RAM

Please see SAP Note 1788665 for SAP FAQ on HANA on vSphere

20

Current State of on HANA on vSphere

Test and Dev Support Statement from SAP in November 2012

• vHANA supported on HANA certified hardware

• Virtual HANA appliances Shipping Now

• No Shared Storage Support

• No vMotion

• No DRS

• Single Instance HANA Support

• Scale Out HANA with shared storage not supported

Future

• Full production support

• Announced May 23 2013 (http://www.vmware.com/company/news/releases/vmw-sap-hybrid-cloud-

services-052113.html)

• Certification and Validation Project Underway

• COIL Lab Project

21

SAP HANA on VMware

Benefits/ROI

22

• Transient By Nature

• Many Peaks/Valleys;

Predictive

• End of Month/End of

Quarter/End of Year

Why Run Analytic Workloads on VMware?

Analytic Workloads Racks Of Hardware

• Big Iron; lots of servers

• Must Size for Peaks

• Large Cap-Ex

Virtual Infrastructure

• Virtualize Everything

• Adapts to Workloads

• vCloud Suite

• vCenter Operations Manager

23

The SAP Co-Innovation Lab enables partners and

customers to forge new ideas and new solutions taking an

ecosystem approach to innovation

COIL Delivers SAP Landscapes, Solution Architectures

and Platforms dynamically provisioned as private clouds

The result is an accelerated solution

time to market

Cloud

The SAP Co-Innovation Lab Experience

24

SAP Co-Innovation Lab Project Scope, High Level Timeline

Running SAP HANA on the VMware vCloud Suite Deployment,

Availability, and Intelligent Management

Proof Of Concept

SAP HANA on vSphere

Standard x86 Hardware

• Shared Storage Configuration

VMware vMotion, DRS, HA

Podcast April 18th

SAPPHIRE Demonstrations

Certified HP Hardware

Validate VMware Functionality

SAP HANA on vSphere Scale

Out testing

SAP /VMware/HP Webcast

• June 19th -over 300 attendees

Demo for VMWorld

Intelligent Management

• vCenter Operations Suite

SAP Business Suite on HANA

Disaster Recovery

• VMware Site Recovery Manager

Project Collateral

• Findings & White papers

• Podcasts

PHASE I (Complete) PHASE II PHASE III

2013 Feb. - May 2013 Q2 – Q3 2013 Q3 – Q4

25

Application enablement

BPC

• Successful POC on vHANA

• Shooting for November 2013 Go Live, fully

virtual

BW

• NLS implementation is a hard prereq

(2013)

• Considering vHANA, pending scale-out

support

vHANA Enablement

• Initially targeting single node deployments

(1 TB max)

• Supported through VMWare

• EMC IT to build on VMAX backend to

support existing DR solution (SRDF)

• vHANA expected to support BPC on HANA

project as well as CRM on HANA Build

phase

SAP

Go-Live

Roadmap Planning

• Mission Critical, OLTP support

CRM

• vHANA to support Build & Test phases

(2013/14)

• Avoid future re-work to HANA-specific Ensuring

that any HANA-specific developments are

Development considerations for R3

PS Go-Live

CRM

Go-Live

BW on HANA

Aug

Operational Data Mart (HANA as a ‘Side Car’)

Data replication from ECC

Sidecar

DB Platform

vHANA prototyping & enablement

Sybase IQ

(NLS) for BW

2012 2013 2014 2015

vHANA

BPC on HANA

vHANA

CRM on HANA (R3)

EMC IT: SAP vHANA Platform Roadmap

26

SAP/VMware Project: HANA on vSphere Certification Testing

Dedicated Hardware at SAP Waldorf

• Use for certification and regression testing

• Scale up and scale out clusters

• Certified hardware partners – IBM & VCE

Testing Configurations

• 1TB Single Node

• 4 x 512GB Scale Out Multi Node

• 4 x 256GB Scale Out Single Node (In-a-box)

Additional Testing Requirements

• VMware HA and vMotion validation

Target Completion Q4

• Release updated OSS Note

• Hardware to remain in Waldorf

IBM Scale UP Platform

VCE Scale Out Platform

27

Running Multiple SAP HANA Database on a Single Host

SAP Co-Innovation Lab Project

• Hewlett Packard chosen as strategic partner

• HP AppSystems for SAP HANA

Single Server Consolidation

• Fully Isolated, Independent, and Secure HANA

Test and Development Database

• Mixed SAP HANA T-Shirt Sizes

• Up to 2TB available per vSphere host (5.5 - 4TB)

HP AppSystems for SAP HANA

• Example: Single DL980 – 1TB – 8x Intel x86 E7

• Max of 8 X-Small HANA Instances

• ~800K hardware savings

• Max of 4 Small HANA Instances

• ~200K hardware savings

VMware vSphere

X-Small

SAP HANA instance

Small

SAP HANA instance

X-Small

SAP HANA instance

X-Small

SAP HANA instance

Multiple

Small

And/Or

X-Small

HANA

Instances

Reduce

Test & Development

Costs

28

ROI: Rapid Deployment of SAP HANA Instances

VMware Templates & Clones

• A clone is a copy of a virtual machine

• A template is a master copy of a

virtual machine

• Used to create many clones

HP AppSystems for SAP HANA

• Based on HP ProLiant servers

• Quickly deploy

• Up to 16 test and development instances

of SAP HANA

• HP AppSystems include preconfigured

SAP HANA VMware templates

29

ROI: Rapid Deployment of SAP HANA Hosts

VMware Host Profiles

• Enables you to establish consistent host configurations

• Automated compliance checks

• Reducing errors caused by misconfigurations

SAP HANA

• Consistent host configuration critical to performance

• Check & maintain compliance for SAP HANA Clusters:

• Scale Up or Scale Out

Complete & Rapid Provisioning Solution

• VMware Templates – HANA VMs

• VMware Host Profiles – HANA Hosts

30

Mission Critical: Ensuring Zero Downtime For SAP HANA

VMware vMotion

• Move running virtual machines across

ESXi Server

• Mature and stable VMware Technology

Tool For Database Administrators

• Zero downtime maintenance

• Migrate live databases

• Little impact to users

The Point Is

• How would a dba do this

without vMotion?

• Without vMotion; significant downtime

• And at what cost to the business?

Live SAP HANA Database Migrations

Infrastructure Abstraction

VMotion™

31

vMotion: So Important to Mission Critical In-Memory Databases

vMotion of SAP HANA In-Memory

• Preserves the state of memory

• Query processing continues

• Slight performance hit during vMotion

• Minutes 250GB vHANA instance

Contrast Restart of HANA Physical

• Downtime; Query/Transactions abort

• HANA does lazy restart loads

system tables

• Then column/row tables

Column Tables

Row Tables

Temporary

Computations

System Tables

Code & Stack

In-Memory State

Used

Memory

SAP HANA

Memory

Pool

Pool (Free)

32

VMware Distributed Resource Scheduled (DRS)

Distributed Resource Scheduler

• Align IT infrastructure with

business goals

• Dynamic allocation of

compute resources

Managing SAP HANA Databases

• Database workloads are

both dynamic and transient

• Directs compute resources

where needed

• Maintain database response

times and SLA’s

Automated SAP HANA Management

Infrastructure Abstraction

Dynamic Resource

Scheduling

33

SAP HANA: Automation Levels and DRS Rules

DRS Automation Levels

• Manual – recommend initial

placement and migrations

• Partially Automated – Initial

placement automated; recommend

migrations

• Fully Automated – automated

placement and migrations

SAP HANA: Powerful DRS

Rules

• Affinity Rules

• HANA runs only on certified hardware

• Anti-Affinity Rules

• Single HANA instance per host

• Migrate non HANA VMs for End of

Month Processing from host(s)

34

VMware High Availability (HA) and SAP HANA

Easy To Configure

• No coding required

• Classic database restart solution

Prioritize SAP HANA Database

• Set VM restart priority.

• Example

• HANA Prod = High

• HANA Test = Medium

• HANA Dev = Low

• Flexible HA management

35

SAP HANA on vSphere: Symantec ApplicationHA

Mission Critical Availability

• VMware HA – protects against

hardware and OS protection

failures

• Symantec Application HA –

protects application components

• Works with vMotion, DRS

SAP vHANA Database

• Symantec ApplicationHA

• Many preconfigured templates

• zNeed to create custom template for

vHANA

vSphere 5.5

• vHANA affinity & anti-affinity rules

now recognized as part of HA

failover

36

SAP HANA Test and Development – Over Commitment

SAP HANA Complex Analytics

• Complex queries – 20 or 30 pages long

• Debugging nightmare; hours to days

Separate SAP HANA Instance for

Developers

• Work on unique static data sets

• Debug – insure correct results are

returned

Exception to Memory/CPU

Reservations Best Practices

• Memory/CPU can be over provisioned

because absolute speed in not a

concern

• Increase productivity by “speeding”

development/debug processes

SAP HANA Studio

Achieve Higher Consolidation Ratios

&

Increased ROI

37

Maximizing Use of Hardware: CPU/Memory Reservations/Limits

VMware Resource Management

• CPU/Memory Reservations

• Guarantee allocation for a virtual Machine

• Regardless of VM activity; static allocation

• CPU/Memory Shares

• Proportional resource allocation; dynamic

Analytic Transient Workloads

• Characterize activity of SAP HANA

• Scenario: SAP HANA receives 90% of available resources but what happens if HANA becomes less active?

• With Reservations no change

• With Shares and over commitment other VMs can utilize resources

Additional ROI – Running HANA on VMware

HANA VM

Other VMs

HANA VM

BOBJ VM

CrystalReports VM

Other VMs

SAP HANA 90% of CPU/Memory Resources

VMware Shares - CPU/Memory

38

SAP HANA Scale Out and High Availability

SAP HANA Physical High

Availability

• Requires standby server

• Idle resources used only on failover

Physical HA is N+1 Architecture

• 3+1 can tolerate a single node failure

HANA

Node 1

HANA

Node 3

HANA

Node 2

HANA

Standby

SAP HANA vCloud Suite HA

• Does not require standby server or

idle resources

• In cloud architecture migrate virtual

machines upon failure; provision

resources on demand

• Substantial cost savings

VMware vCenter Operations

VMware vSphere

HANA

Node 1

HANA

Node 2

VMware vSphere

HANA

Node 3

Test &

Dev

VMware vSphere

ASE SAP

Fully Utilize Hardware; Reduced Costs

39

VMware vCenter Operations Suite

Analyze: HANA Workloads

• Determine when and where analytic

peaks and valleys are occurring?

Forecast: HANA Usage Patterns

• Proactively deploy and redeploy

resources as needed to HANA and

other SAP applications

Plan: SAP HANA Live Migrations

• Migrate HANA and other applications

using vMotion and Distributed

Resource Scheduler (DRS)

Once SAP HANA is Virtualized…

HANA HANA Sybase

ASE Sybase IQ

vCenter Operations Suite:

SAP Real-Time Data Platform

40

Conclusions

SAP HANA on VMware

• Performance is not an issue

SAP Co-Innovation Lab

• Powerful partnership of SAP, EMC, VCE, HP

• Delivering ROI and Innovative solutions to market

• Leveraging VMware technologies with SAP HANA

• Validation of vMotion, DRS, HA, Templates

• SAP HANA/VMware Demos - VMwareTV

• Upcoming Phases

• SAP HANA Scale Out testing

• SAP Business Suite on Powered by HANA

Follow Project Progress on the SAP Community Network

41

Other VMware Activities Related to This Session

Group Discussions:

VAPP1003-GD, VAPP1008-GD, VAPP1009-GD

SAP with Girish or Mohan Potheri or Vas Mitra

VAPP5591

THANK YOU

Big Data: Virtualized SAP HANA Performance,

Scalability and Practices

Bob Goldsand, VMware

Todd Muirhead, VMware

VAPP5591

#VAPP5591