SAP and SAP HANA on VMware

SAP Applications On vCloud Suite SAP Business Suite

Netweaver (ABAP +JAVA)

Traditional Databases

BW

ERP

CRM

SCM

ETC

vCloud Suite(vMotion, HA, SRM, DRS)

vSphere (ESX Cluster)

vCen

ter O

pera

tions

(P

erfo

rman

ce M

anag

emen

t and

Ana

lytic

)

VMw

are

Adm

O

S Ad

m

SAP

Basi

s DB

A

BOBJ

SAP HANA ®

SAP & VMware – Strategic Partnership Run SAP on VMware anywhere...simple •  Preferred strategic partnership since Sapphire, 2011

•  Entire SAP stack virtualized in production with VMware

•  Common certified Architecture – including SAP HANA in production on vSphere 5.5

•  Run in production with confidence

•  Run simple on VMware anywhere

•  Integrated with SAP global support network

On Premise

BA BW

Bus. Suite

3rd Party Apps

Hybrid Cloud

Daimler AG “AMG-Mercedes is now live in production with SAP HANA and VMware vSphere 5.5 with a 1TB memory configuration, accelerating our move to a software-defined data center,” said Reinhard Breyer, CIO, AMG. “We believe virtualized SAP HANA with VMware’s vSphere could be the key to our future, as we move to cut operational costs and simplify our data center operations.”

2

Introducing Production SAP HANA on vSphere 5.5

3

High Availability

>Automatically restart SAP HANA VMs to maximize uptime

APP

Automated Resource Allocation

>Easily manage peak analytic workloads

Automated Operations

Management

>Unify and manage SAP HANA with rest of

virtual datacenter

Capacity Planning and Optimization

>Live migrate SAP HANA databases across hosts

in minutes

Virtualization-Aware Security and Compliance

>Protect workloads; reduce downtime

through rapid issue resolution

Rapid Provisioning

>Deploy SAP HANA instances in hours

•  99.9%+ availability*

•  Zero downtime and zero data loss with vMotion, enabling business continuity without compromise

•  Automatically restart SAP HANA VMs to maximize uptime

Better Service Levels

•  Rapid provisioning: deploy within hours vs. days**

•  Template provisioning ensures consistency and scalability across environments

Faster Time-to-Value Lower TCO

•  Reduce CAPEX by 70% and OPEX by 56%***

•  Unify and manage SAP HANA with the rest of virtual data center

•  Greater utilization of existing resources and infrastructure

SAP HANA on vSphere 5.5 Delivers Material Value

*EMC IT, 02/14 EMC Perspective, H12853 ** EMC IT internal analysis, ***Taneja Group Research, 2014

SAP HANA Platform on VMware vCloud Suite

5

SAP HANA Platform P2V Delta

Supported/Certified

Sub-Capacity Licensing

SAP HANA Scale Up <10% YES N/A SAP ASE < 7% YES YES SAP IQ < 7% YES YES SAP Replication Server

< 5% YES YES

SAP SQL Anywhere < 5% YES YES

2.  Support

3.  Licensing

Differentiated Solution – Removing the 3 Major Barriers to Database Virtualization

Phase I Results Published 2012 – vSphere 5.0/1

Running SAP HANA on vSphere: -  No additional cost or licensed required -  It’s just another virtual machine

SAP benchmarks show physical to virtual delta is <10%. Performance not an issue.

SAP HANA Platform fully certified to run on vSphere. No requirement to reproduce on physical

Sub capacity licensing on cores/sockets in use. No need to license entire host – cloud model; pay-per-use.

1.  Performance

SAP HANA Production Support – General Availability

6

SAP HANA on vSphere Production Certification Certification Process

SAP HANA Production Support •  Scale up support (Up to 1TB) •  On-line service system note published

-  1995460 – SAP HANA on VMware in production

•  Supported on SUSE and RedHat Linux •  Requires certified hardware (same as physical) Supported VMware Technologies •  Live Migration vMotion •  Distributed Resource Scheduler (DRS)

–  DRS business rules •  High Availability (HA) (scale up only) •  Creation of SAP HANA Clones/Templates SAP/VMware Joint Support •  SAP will provide support for SAP HANA issues •  VMware takes ownership of performance issues

Current Certification •  Production use case vSphere 5.5

–  SAP HANA SP07 or greater – up to 4 sockets –  SAP HANA Multi VM – Controlled Availability –  Other VMs consolidation – Fully supported –  All use case – BW, Suite on HANA, & Side Cars

•  Non-Production use case vSphere 5.1 -  SAP HANA SP05 or greater – up to 8 sockets -  Multi-VM supported

After Initial Certification •  No lag – same release cycle as hardware vendors •  Deeper testing and integration of VMware vClould

Suite –  VMware vCenter Site Recovery Manager –  VMware vCloud Automation Center –  VMware vCenter Operations Management Suite –  VMware vCloud Director

2014 and Beyond Began 2013 Q3 – Announcement 4/28

SAP HANA on VMware: Multivm Support Controlled Availability

7

Straight Forward Application Process Customers interested in running multiple SAP HANA VMs on VMware vSphere 5.5 in production can apply for Controlled Availability of SAP HANA production support by sending an email to: sap_hana_tailored_data_center_integration@sap.com

This email should contain: 1.  High-level scenario description and timeline (e.g. planned Go-live date)

2.  Expected database size (compressed HANA DB size, number of users)

3.  Hardware spec (HW vendor, server t-shirt size) 4.  Planned HA/DR setup (if applicable) 5.  Contact details for further communication

All information given will be kept confidential and is only being used during the selection process. Once accepted, customer will get access to restricted SAP Note, officially stating SAP HANA support for the presented scenario.

SAP HANA Support Summary

8

Capability Supported in Production Supported in Test/Dev

HANA Scale up to 1TB of Memory Yes Yes

vCloud Suite Version 5.5 and above 5.1 and above

SAP HANA Version SP 07 and above SP 05 and above

vSphere vMotion Yes Yes

VMware HA Yes Yes

VMware DRS Yes Yes

Server Hardware Certified Appliances Certified Appliances

Storage Certified Appliances or TDI Certified Appliances or TDI

Scale Out Configuration No No

CPU Sockets per server Up to 4 (Intel E7 Westmere EX or Intel E7 v2 Ivy Bridge EX processor)

Up to 8

SAP HANA Sizing Deployment Considerations

9

Columnar and Row (Traditional) Database Stores •  Row Stores

–  Store logically related attributes of different types •  Sales Orders, Invoices, etc.

–  Insert/update to the row store –  Analytic queries reporting; unnecessary scans

•  Ex: Report/Query Amount and State –  Typically 20 attributes for every 2 of interest

•  Data Warehouses table 100’s of attributes wide

•  Column Stores – Fully Relational –  “Turns The Tables” on physical layer –  Logical Layer

•  Users view is same as row data stores –  Physically Layer

•  In-memory or on disk columnar •  Accesses only the attributes of interest

–  Optimized for analytics and Ad Hoc queries

10

Order # Last Name

Amount Item # ……State

1024 Smith $257.97 088-3X … … CA

1025 Jones $1,122.18 215-4B … … NJ

1026 Lee $655.43 113-22 … … NY

1027 James $919.22 003-44 … … AZ

Order # 1024 1025 1026 1027

Last Name Smith Jones Lee James

Amount $257.97 $1,122.18 $655.43

$919.22

Item # 088-3X 215-4B 113-22 033-44

… … … … …

…. … … … …

State CA NJ NY AZ

Row Store Table: Logical View and Physical Layer

Column Store Table: Physical Layer

Optimization: Tuning Traditional Analytic Databases (OLAP) •  DBAs Can Minimize Unnecessary Table Scans

–  Materialized View; Partitions (Optimization Objects) •  Tables which reside on disk; can contain own indices •  Pre-Joins; updateable manually, scheduled, triggers

–  Complex Subject and Management •  Varies by rdbms vendor •  Data Warehouses contain100’s of reports

–  Typically 30% - 90% of total size of database

•  Columnar Does Not Need Optimization Objects –  Works on Data Only –  Higher Degree of Compression

•  Ad hoc Queries –  Cannot be optimized; requires pre-knowledge –  Ad Hoc/Data Mining no problem for column stores

11

Column Store

Row Store

Base Table + Materialized Views + Indices

Base Table – Requires Data Only

Row to Column Store: Does The Total Databases Size Matter? •  No Indices, Materialized, Partitions

–  Inserts/Updates faster –  Faster data loads

•  No Dropping/Regeneration –  Indexes, temporary tables –  Reduces time to query

•  Phantom results

•  Do You Need DBAs? Of Course… –  Frees up DBA for strategic planning/projects

•  Fundamentals of Columnar Data Stores –  Before Sizing

•  Reduces overall size of database •  Higher degree of compression •  Significantly less maintenance

12

Row Store

Base Table + Materialized Views + Indices

The Question is NOT How Big is My Data Warehouse?

The Question is How Much Data is in My Data Warehouse?

? SAP Sizing Tools Can Determine That Answer

Controlled Availability

Sizing - SAP HANA Scale Up for vSphere •  Use SAP HANA Specific Tools (same as physical)

–  The Criteria for sizing RAM Consists of: •  Memory sizing for column store (compressed data) •  Memory sizing for row store •  Memory sizing for runtime objects

–  The Total RAM determines if SAP HANA is a candidate for virtualization

•  Ex: SAP QuickSizer for SAP HANA: –  If Total RAM <=1TB then Deploy on vSphere

•  SAP ABAP Based Sizing –  SAP Preferred method, much more accurate –  Non-active Data Concept

•  Hot, Warm, Cold

–  SAP HANA with >1TB of RAM can be virtualized

Hot

Warm

Cold

-  No different than physical -  Total RAM <=1TB then OK to virtualize -  Total RAM >1TB Use ABAP Based Sizing

SAP HANA QuickSizer

ABAP Based Sizing SAP HANA Non-Active Data Concept

In-memory; with runtime objects

In-memory; no runtime objects

Data can reside on disk

0

500

1000

1500

2000

2500

3000

3500

Load 1 Power Throughput Power (DQP)

Throughput (DQP)

VMDK Multiwriter

RDM SCSI Sharing

Physical

Timing Comparison (16 Cores)

SAP IQ: Strategic to HANA •  SAP IQ

–  Columnar; shared everything –  Scale up/out architecture –  Mature product – large install base –  Many VMware customers in production

•  Complimentary to SAP HANA –  In the moment business decisions;

historical data –  SP08 – SAP HANA extended tables –  SAP IQ, ASE, and SAP HANA Synchronized Service

Packs

•  SAP IQ 15.4 validation testing –  Standard x86 servers –  EMC® VNX® 5700 FC Unified Storage System –  300GB single node and multiplex –  vMotion < 3 minutes under load

14

SAP IQ MultiPlex (Scale Out)

Data Discovery (Data Scientists)

Application Models

(Biz Analysts)

Reports/Dashboards (BI Programmers/End Users)

SAP IQ Logical Server 1 Logical Server

2 Logical Server 3

High Speed Interconnect

Administration (DBAs)

Load, Prepare, Mine, Report in a workflow • Heavy Parallelization • Worlkload isolation via elastic logical servers • Collaboration through shared storage • Unique in the industry for quick time to value for end users

SAP IQ For Warm/Cold Data Management •  SAP HANA Real-Time

–  Cutting edge, in-memory platform –  Transact/analyze in real-time

•  IQ Warm/Cold Data Management –  SAP HANA SP08 & IQ 16 –  IQ as NLS for SAP BW –  IQ as ILM for SAP ERP –  Extended storage for SAP BW on HANA

•  Future Public Roadmap – Dynamic Tiering –  Common installer –  Single licensing model –  Optimized query processing –  Unified backup/restore

SAP HANA Dynamic Tiering

SAP HANA Hot Data

Warm Cold

+

Expand SAP HANA capacity with warm/cold data in extended store (SAP HANA warm store) Tight integration between SAP HANA hot store and SAP HANA warm store for optimal performance

SAP HANA Extended Storage - Scaling Beyond 1TB on vSphere •  SAP HANA Extended Storage

–  Query and update data seamlessly –  Scales to terabytes or petabytes –  Workload defines Hot/Cold data

•  Transparent to Application or User –  Intelligent placement of data

•  Cost Effective Scaling vCloud Suite –  Terabyte or Petabyte scaling of cold/warm data –  Standard x86 servers –  Must use SAP sizing guidelines

SAP HANA IQ Extended Storage

HANA Native Table

HANA Native Table

SAP HANA

SAP IQ

vSphere 5.5 vSphere 5.x

OS

SAP HANA

OS

SAP IQ

X86 Hardware

OS

SAP IQ

Certified hardware

Queries & Updates are Initiated Via

HANA

OS

SAP IQ

SAP HANA Tailored Data Center Integration (TDI) •  SAP HANA Server with customer’s preferred

storage solution –  Same BOM as the certified appliance

without storage –  Move towards “Open SAP HANA”

•  Utilize existing infrastructure investment –  Easier and more cost-effective migration

to SAP HANA –  SAP provided hardware verification tool

•  Run SAP HANA on vCloud Suite –  Near native performance; meet KPI’s –  Leverage VMware technologies

•  vMotion, DRS, HA

–  OSS note updated to include VMware

17

Application

Appliance Model

Database

Operation System

Virtualization

Server

Network

Storage Storage

SAP HANA Server

SAP HANA Server

SAP HANA Server

Virtualization

SAP HANA TDI Model

Server

Network

Storage Enterprise Storage

SAP HANA Server

SAP HANA Server

SAP HANA Server

Shared Network

SAP HANA on VMware Best Practices

18

SAP HANA on vSphere Best Practices Overview •  SAP HANA on vSphere – It just Runs!

–  Phase I Performance Testing: •  All performance results were out of the box; no special tuning required

–  For the most part SAP HANA follows general published vSphere Best Practices for databases –  Documented General Best Practices and SAP HANA Optimizations

•  Most Support Issues Occur at Storage Layer –  Minimized with in-memory databases

•  SAP HANA on vSphere Best Practices Guide and More: –  www.vmware/go/sap-hana

Set Memory Reservations for SAP HANA Virtual Machines •  Managing Memory Resources for Virtual Machines

–  Limits: are the maximum amount of resources a virtual machine can use

–  Shares: proportional allocation of resources when virtual machines are competing for Memory

–  Reservations: a guarantee of resources for a virtual machine •  Used for SAP HANA – Predictable performance; Guaranteed SLA •  Fully Isolated, Independent, Secure SAP HANA Databases •  Different from SAP HANA Multi-SID

•  Enable Reserve All Guest Memory Setting –  Linked to the virtual machine memory configuration –  Memory reservation is immediately readjusted when the

•  Memory reservation is automatically increased/decreased

–  With SAP HANA – won’t forget to adjust reservations when “Reserve All Guest Memory” is enabled (Check Box)

20

Configuring Paravirtual SCSI Controllers •  Paravirtual SCSI (PVSCSI) controllers

–  High performance storage controllers •  Greater throughput •  Lower CPU utilization

–  Suited for high-performance storage environments –  Use PVSCI for Data and Log devices –  Can be used for OS/Executable – not bootable from SAN

•  Setting SCSI Controller Type –  For both vSphere Web Client and vSphere Client

•  Change type to – VMware Paravirtual

–  Check support matrix for use of Paravirtual SCSI adapters •  KB Article 1010398

21

VMware vSphere Web Client

VMware vSphere Client

Use VMware VMXNET3 Adapter Type/ Virtual Distributed Switch •  VMXNET Optimized Performance in a Virtual Machine

–  Operating system vendors do not provide built-in drivers for this card

–  Must install VMware Tools to have a driver for VMXNET

•  When Creating Ethernet Adapters –  Use VMXNET3 Adapter Types Change to “VMware Paravirtual”

•  Virtual Distributed Switch (vDS) or Virtual Standard Switch (vSS) –  vSS resides on single host; vDS centrally managed across all hosts –  vDS simplifies management of complex environments (SAP)

•  Shape and manage traffic; isolate database, application, backup servers

–  vDS Aligns with SAP TDI Enterprise Network Beta

22

VMware vSphere Web Client

VMware vSphere Client

Selection Optimal IO Schedulers; Transparent Huge Pages •  Linux IO Schedulers

–  Choosing IO scheduler – NOOP, CFQ, or Deadline –  Use NOOP Scheduler

•  Reduce I/O latency and increase •  Reduce CPU time spent re-ordering I/O requests

–  Work with system admin to change and make permanent

•  Transparent Huge Pages (THP) Support –  Increase Translation Lookaside Buffer efficiency –  Can provide 10% performance boost –  SLES SP 2 – default configuration THP is enabled –  Work with sys admin to make sure this is the default behavior –  SAP OSS Note provides guidance on when to use THP

23

# cat /sys/block/sda/queue/scheduler [noop] cfq deadline

Check IO :Scheduler In Brackets

# cat /sys/kernel/mm/transparent_hugepage/enabled [always] madvise never

Check THP: Policy In Brackets

vSphere Low Latency Setting & Guest Memory Pre-Allocation •  vSphere 5.5 New Per-VM feature called Latency Sensitivity

–  Allows virtual machines to exclusively own physical cores –  Avoiding overhead related to CPU scheduling and contention –  Positive Performance Impact for SAP HANA

•  Set Latency Sensitivity to “HIGH”; with vSphere Web Client •  vSphere Client – add sched.cpu.latencySensitivity = HIGH to .vmx file

–  Caution Not always right choice

•  vSphere Guest Memory Pre Allocation –  Further reduce latency by memory pre-allocation upon startup of

virtual machine –  SAP HANA pre-allocates and manages its memory pool –  Add following lines to the .vmx file to enable pre-allocation

•  sched.mem.prealloc = “TRUE” •  sched.swap.vmxSwapEnabled = “FALSE”

24

Guest Memory Pre-Allocation

vSphere Latency Sensitivity

NUMA, CPU Affinity, Hyper-threading •  No Over-commitment of CPU resources for SAP HANA production VMs •  SAP HANA has been found to perform optimally with virtual NUMA that

reflects the physical NUMA –  Default behavior of vSphere –  Additional step of using CPU affinity to pin virtual NUMA nodes to physical NUMA nodes improves

performance by preventing any virtual NUMA node migration to different physical NUMA nodes

•  vCPUs and Hyper-threading –  Hyper-threading adds a logical thread to each physical core which increases performance by up to 20% –  Best Practice is to have HT enabled –  With HT enabled each Physical Core = 2 logical threads (example – Host with 40 cores has 80 threads) –  vCPU = logical thread –  Important to consider when sizing VMs for HANA and determining how many vCPUs per vNUMA node –  See VMware Best Practices for SAP HANA on vSphere for details.

25

SAP HANA on VMware vSphere Best Practices Guide

•  All the best practices are covered in detail in the best practices guide •  http://www.vmware.com/files/pdf/SAP_HANA_on_vmware_vSphere_best_practices_guide.pdf

26

SAP HANA on vSphere Rapid Deployment and Workload Management

Rapid Deployment of SAP HANA Databases •  VMware Templates and 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

•  Ex: SAP HANA Template –  Rapid deployment

•  Optimized SLES Environment •  rpms, OSS notes, kernel parameters

–  SAP Unified Installer •  SAP HANA, SAP HANA Studio, Life Cycle Manager, Application

Function Library (AFL), SAP HANA Database Client –  SAP HANA Customer Proof of Concepts

•  Use of VMware Templates for Multi-VM CA Study •  Some customer slots remain

•  Complex Environment: SAP Blueprints –  BluePrinting & Provisioning SAP Using vCloud Automation

Center and Applications Director •  SAPaaS - Session ID MGT1559

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 and maintain SAP HANA clusters:

•  Compliance •  Attach Host Profiles in SAP HANA Cluster •  Edit Host Profile and update cluster

•  Complete Rapid provisioning solution –  VMware templates – SAP HANA VMs –  VMware host profiles – SAP HANA Hosts

Mission Critical: Zero Downtime Migrations •  VMware vMotion

–  Move running virtual machines across ESXi Server

•  Live Migrate SAP HANA Databases –  Zero downtime maintenance –  Migrate live databases –  Little impact to users

•  Critical For In-Memory Databases –  Preserves the entire state of memory –  Avoid a database – loses temp tables, computations

•  VMware vMotion – All or Nothing –  Like an atomic transaction; completes or does not

complete –  Does not leave VM in phantom state

Live SAP HANA Database Migrations

vMotion

SAP HANA In-Memory State Pool (Free)

Code & Stack

Temporary Computations

Column Tables

Row Tables

System Tables

Used Memory SAP HANA

Memory Pool

VMware Distributed Resource Scheduler (DRS) •  Distributed Resource Scheduler (DRS)

–  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

•  DRS Automation Levels –  Manual – recommend initial placement

and migrations –  Partially automated – initial placement

automated; recommend migrations –  Fully automated – automated placement

and migrations

Automated SAP HANA Management Infrastructure Abstraction

Dynamic Resource

Scheduling

DRS Affinity Rules – Automated Management of SAP HANA VMs •  Use Affinity Rule to Prevent Migrations

–  Non-certified servers –  Resulting in unsupported configurations

•  DRS Rule Creation –  Host DRS Groups

•  Contains only the hosts vm can run on

–  VM DRS Groups •  Group types of VM:

–  SAP HANA Group – all HANA VMs –  Other SAP VMs – ASE, SAP Application Servers

–  SAP HANA DRS Affinity Rule •  Contains Host Group & VM Group •  SAP HANA VM can only run on certified hosts

32

DRS Anti-Affinity Rules – Automated Management Continued.. •  Exclusive Resource Rights

–  Separate SAP HANA VMs –  Evacuate VMs other that SAP HANA

•  DRS Anti-Affinity Rules –  Only 1 SAP HANA VM per host

•  All resources to single HANA VM

–  No other VMs on cluster •  All other VMs to standard x86 host group

•  Useful For Managing Peaks and Spikes –  End of Month, Quarter, Year

33

Analytics: Transient and Temporal Workloads •  Many Peaks Valleys – End of Month, Quarter, Year

–  Resources locked into physical servers •  Cannot be reclaimed; regardless of usage characteristics •  Wasted idle resources after EOM, EOQ, EOY

•  SAP HANA –  Highly efficient in-memory processing –  Orders of magnitude faster than traditional databases

•  SAP HANA on vSphere –  SAP HANA databases can reclaim idle CPU resources –  More efficient use of physical hardware

•  VMware Workload Management –  SAP HANA “Prod-1” – heavy EOQ processing –  SAP HANA “Prod-2” – completed EOQ –  Redirect CPU resources to SAP HANA “PROD-1”

•  Consolidated workloads “Faster Than Physical”

34

“Prod-1”

SAP HANA

vSphere 5.5

“Prod-2”

SAP HANA

1TB Certified Server

2x 510GB SAP HANA Databases

“Prod-1”

SAP HANA

“Prod-2”

SAP HANA

SAP HANA Appliance 512GB

SAP HANA Appliance 512GB

SAP HANA Multi-VM Reclaim/Redirect CPU Resources

SAP HANA Physical Resources Cannot Be Reclaimed / Redirected

VMware vCenter Operations MP for SAP HANA – Overview •  Exposes SAP HANA related performance, health,

and availability metrics within vC Ops •  Includes out-of-the-box dashboards,

supermetrics, metrics, and metrics collections for SAP HANA

•  Provides visibility into SAP HANA workloads running on VMware vSphere, bare-metal, and cloud-based deployments

Benefits

Overview

•  Enables end-to-end views of SAP HANA, underlying compute resources, and storage

•  Gain enterprise-wide visibility into SAP HANA workloads

•  Greatly reduce troubleshooting times, and simplify security & compliance management

•  vMotion SAP HANA – vCenter Operations Suite BlueMedora Performance Dashboards

SAP HANA integration with vCenter Operations delivers automated correlation of performance, health, and availability data for SAP HANA workloads

Demo

Migrate Live Databases with Zero Downtime

36

vMotion •  Moves live running SAP HANA databases

from one certified host to another

•  Eliminates downtime from planned server maintenance

•  Maintains entire memory state, data, temporary tables, statistics

•  All or nothing migration-does not leave virtual machines in phantom state

•  No user impact

Live SAP HANA Database Migrations Infrastructure Abstraction

vMotion

Automatically Balance Workloads Across Hosts

37

Distributed Resource Scheduler (DRS) •  Scales and manages computing

resources without service disruption •  Automatically balances workloads

across hosts •  Use DRS rules to prevent SAP

HANA migrations to non-certified hosts

•  Maintains response times and service levels

Automated SAP HANA Management Infrastructure Abstraction

Dynamic Resource

Scheduling

Set User-Defined Rules

•  Anti-affinity rules -  Single instance per host -  Migrate non-SAP HANA virtual

machines for end of month processing from host(s)

•  Affinity rules -  Runs only on certified hardware

38

Deploy Instances and Hosts Rapidly

39

•  Automatically deploys additional hosts using a master host profile

•  Eliminates need for specialized scripts •  Maintains consistent service levels •  Protects against unauthorized

changed parameters using host profile compliance checks

Deliver Highest Levels of Uptime

40

High Availability (HA) •  Monitors hosts and virtual

machines to detect system failures

•  Automatically restarts virtual machines on other certified hosts when outage is detected

•  Ability to set virtual machine restart priority

Increase Productivity

41

•  Runs multiple databases on a single certified host

•  Maintains service levels for overprovisioned CPUs –  Sets memory reservations

•  Speed development and debug processes

Deployment Considerations and Options

42 CONFIDENTIAL

SAP HANA: Relevant vSphere Maximums

43

Deployment considerations scale up or SAP HANA on VMware

VMware vSphere ESX 4.1 5.0 5.1 5.5

Virtual CPUs Per VM 8 32 64 64

RAM Per VM 255GB 1TB 1TB 1TB

Logical Cores Per ESX Host 320 2048 2048 4096

RAM Per ESX Host 1 TB 2TB 2TB 4TB

Virtual Disk Size 2TB 2TB 2TB 64TB

Virtual Disks Per VM 60 60 60 60

SAP HANA Scale Up Model on VMware

44

Reducing IT footprints – consolidation of SAP HANA databases •  Fully isolated, secure, and encapsulated •  Not SAP HANA Multi SID – can guarantee resources with vSphere •  Right sizing – mixed HANA T-shirt sizes •  ROI – purchase large server rather than multiple smaller server •  vSphere 5.5 – 4 TB per host

Flexible SAP HANA T-Shirt Sizes 1TB 512GB 256GB 128GB

vSphere 5.5

HANA

SLES

HANA

SLES

HANA

SLES

HANA

SLES

Consolidate 1TB SAP HANA VMs 1TB 1TB 1TB 512GB

vSphere 5.5

HANA

SLES

HANA

SLES

HANA

SLES

HANA

SLES

Sizing — SAP HANA Scale Up for vSphere •  Use SAP HANA Specific Tools (same as physical)

–  The Criteria for sizing RAM Consists of: •  Memory sizing for column store (compressed data) •  Memory sizing for row store •  Memory sizing for runtime objects

–  The Total RAM determines if SAP HANA is a candidate for virtualization

•  Ex: SAP QuickSizer for SAP HANA: –  If Total RAM <=1TB then Deploy on vSphere

•  Ex: SAP ABAP Based Sizing –  SAP Preferred method, much more accurate –  Non-active Data Concept

•  Hot, Warm, Cold –  SAP HANA with >1TB of RAM can be virtualized

•  Ex: Disk sizing –  Log = 1 x RAM –  Disk Persistence = 4 x RAM

Hot

Warm

Cold

ABAP Based Sizing SAP HANA Non-Active Data Concept

Data can reside on disk

In-memory; no runtime objects

In-memory; with runtime objects

SAP HANA QuickSizer •  No different than physical •  Total RAM <=1TB then OK to virtualize •  Total RAM >1TB Use ABAP Based Sizing

•  SAP HANA Server with customer’s preferred storage solution -  Same BOM as the certified appliance

without storage -  Move towards “Open SAP HANA”

•  Utilize existing infrastructure investment -  Easier and more cost-effective migration

to SAP HANA -  SAP provided hardware verification tool

•  Run SAP HANA on vCloud Suite -  Near native performance; meet KPI’s -  Leverage VMware technologies

•  vMotion, DRS, HA -  OSS note updated to include VMware

SAP HANA Tailored Data Center Integration (TDI)

46

Application

Appliance delivery approach

Database

Operation System

Virtualization

Server

Network

Storage Storage

SAP HANA Serve

r

SAP HANA Serve

r

SAP HANA Server

Virtualization

SAP HANA tailored data center integration

Server

Network

Storage Enterprise Storage

SAP HANA Serve

r

SAP HANA Serve

r

SAP HANA Server

Shared Network