VMworld 2013 Bob Goldsand, VMware Todd Muirhead, VMware Learn more about VMworld and register at http://www.vmworld.com/index.jspa?src=socmed-vmworld-slideshare

1. Big Data: Virtualized SAP HANA Performance,
Scalability and Best Practices
Bob Goldsand, VMware
Todd Muirhead, VMware
VAPP5591
#VAPP5591

2. 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. 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. 4
HANA and vSphere are Neighbors

5. 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. 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. 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. 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. 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. 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. 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. 12
Low Performance Variation = Consistent Performance
OLTP and OLAP have similar characteristics

13. 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. 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
AvgResponseTime
Dialogue Step
Response Time for Each Dialogue Step
VM LargePages
BM 450 Users 2nd Round

15. 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. 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. 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. 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. 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. 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. 21
SAP HANA on VMware
Benefits/ROI

22. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
Crystal
Reports VM
Other VMs
SAP HANA 90% of CPU/Memory Resources
VMware Shares - CPU/Memory

38. 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. 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. 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. 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

42. THANK YOU

44. Big Data: Virtualized SAP HANA Performance,
Scalability and Practices
Bob Goldsand, VMware
Todd Muirhead, VMware
VAPP5591
#VAPP5591