TEC 131: Customer Stories: Management of Virtual SAP and SAP HANA LandscapesBob Goldsand – Staff Partner Architect – VMware

Agenda• What Is SAP HANA and Dynamic Tiering

• VMware/SAP Roadmap

– The Evolution of SAP HANA; Multi-Temperature Data Management

• Perspective and Performance

• SAP HANA Dynamic Tiering

– Sizing &Use Cases

• VMware Software Defined Data Center – SAP HANA “Run Simple”

– From Concept To Reality

• VMware Virtual Volumes

• VMware NSX

• VMware vRealize Operations Manager

• Conclusions - We Live In a Heterogeneous World

– Apply SDDC Concepts and Best Practices to Any Mission Critical Application or Database in SAP Landscape

2

Today Future Directions

Solution OverviewRequirements from our customers

Introducing SAP HANA dynamic tiering

• Manage data cost effectively, yet with desired performance based on SLAs

• Handle very large data sets – terabytes to petabytes

• Update and query all data seamlessly via HANA tables

• Application defines which data is “hot”, and which data is “warm”

• Native Big Data solution to handle a large percentage of enterprise data needs without Hadoop

SAP HANA

hot store

(in-memory)

SAP HANA warm

store

(dynamic tiering)

Extended table

(definition)

Extended table

(data)

Fast data movement and optimized push down

query processing

All data of extended table resides in warm store

SAP HANA Database System

Hot table

(definition/data)

• Hot Store

– Classic HANA tables

• Primary data image in memory

• DB algorithms optimized for in-memory data

• Persistence on disk to guarantee durability

• Warm Store

– Extended Tables

• Primary data image on disk

• Data processing using algorithms optimized for disk-based data

• Main memory used for caching and processing.

SAP HANA dynamic tieringMap data priorities to data management

Primary image in memory

Durability

Cache / Processing

Primary Image on

disk

SAP HANA

Dynamic Tiering

Hot data

Warm data

All in one

database

Hot Store Warm Store

RAM

SAP HANA dynamic tieringMap data priorities to data management – cont..

• Data in the database

– Different data temperatures

• Maximum access performanceHot data - always in memory

• Reduced access performance:Warm data - not (always) in memory

•

All part of the database’s data image

• Data moved out of the database

– Different data qualities

• Available for read accessBW Near-line storage

• Not accessible without IT processTraditional archive

•

Data is stored and managed outside of the application database

Data for daily reporting, other

high-priority data

Other data required to operate

the application

Hot

Warm

NLSData that is (normally) not updated, infrequently accessed

Traditional ArchiveData that‘s kept for legal reasons or similar

Externalize

SAP HANA Database System

Evolution of SAP HANA

SAP HANA Hardware Costs Evolution

8

Simplification

Multitenant Database

Containers (MDC)

&

Consolidation Via Virtualization

Solutions Today

HANA

Appliance

HANA

Tailored

Data

Center

Integration

(TDI)

HANA

VMware

vSphere

Compared To

Compared To

Compared To

Any DBMainframe

AIX PowerHP-UXSolaris

x86

SAP HANA Multi-Temperature Data Management

9

HOT

WARM

NLS

ARCHIVE

In DB:

• In-memory

• No restrictions; all features available

In DB:

• On disk

• No restrictions

External to DB:

Near-Line Storage

Read Access; No Updates

External to DB:

• Archive Storage

• No read access or updates

HANA column & row store

Warm store dynamic tiering

Non-active data concept

Near Line Storage

Traditional Archive

Priority & Data Volume

Price & Performance

Not All Data Must Reside in Memory – only for real-time access and use cases

Manage Your Memory Footprint – reduce costs

SAP HANA Platform: Evolving Hardware Requirements

10

Hot

WarmCold

vSphere 5.5

OS

SAP

HANA

Certified hardware

SAP HANA Service Pack 07All Data Resides In-Memory

SAP HANA Service Pack 08Multi-Temperature Data

SAP HANA Service Pack 09Dynamic Data Tiering

vSphere 5.5 vSphere 4/5

OS

SAP

HANA

OS

SAP IQ

NLS

Certified Hardware x86 Hardware

- Hot & Warm Data in-memory- Cold Data Managed by IQ

- BW SAP IQ Near Line Storage- Data on Disk- SAP HANA Extended Tables- Does not require Certified Hardware

Hot Warm

Cold

vSphere 5.5 vSphere 4/5

OS

SAP

HANA

ES

Host

Certified Hardware x86 Hardware

SAP IQ

NLS

- All Data Must Be In-Memory- Must Run on Certified Hardware

- Majority of Enterprise Data NOT in-memory- Hot Data for Real-Time Use Cases- Warm Data Extended Storage Host- BW Cold Data – IQ Near Line Storage

In General – Cloud & Virtualization Protects Against Changing Requirements

SAP HANA VMware Technology Roadmap (from 2014 to H2/2015+)

Single VM production

support

Complement deployment

options

Multi VM support (in CA)

GA

BWoH Scale-out support

(in CA)GA

Extend platform support

vSphere 6support

8 socket HW support

H1/2014 H2/2014 H1/2015 H2/2015+This is the current state of planning and may be changed by SAP at any time.

(CA) Controlled Availability - (GA) General Availability - (BWoH) SAP business Warehouse, powered by SAP HANA

• Today

• General support for SAP HANA on VMware vSphere 5.1 in non-production

• General support for single SAP HANA VMs on VMware vSphere 5.5in production:

– SAP Suite on HANA

– SAP Business Warehouse Powered By HANA

– SAP HANA Standalone

– vSphere 6.0 Test/Dev

• Controlled Availability for multi-VM and BW on HANA scale-out scenarios on VMware vSphere 5.5 in production

• On Roadmap

• Support of larger VMs (4 TB) and 8-socket hardware with VMware vSphere 6 in Production

• Support for Multi-VM and Scale-Out in GA

Perspective and Performance

Background Perspective/Performance

• Typical Virtual Machine Size:

– Applications 1 to 2 vCPUs/4 - 8 GB of RAM

– Databases 4 to 8 vCPUs/16 – 32 GB of RAM

• SAP HANA Extreme Performance/Sizing Requirements

• vSphere 5.5 Boundary Testing 64 vCPUs and 1TB of RAM

– Within ~10% of native performance at these extreme sizes

• Typical Certification/Validation Testing

– Apples to Apples Single VM Compared to Single Physical Instance

• Necessary for worst case performance guidance

– Apples to Oranges in The SDDC

• vSphere optimization through consolidation and workload management

– Physical Performance Is What It Is; Not True With SDDC

13

Validated/CertifiedPhysical to Virtual Delta

Pe

rce

nt

Delt

a

Databases

Virtual World (SDDC) Physical World

Real World

Example: 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

• Physical Performance Is What It Is

• SAP HANA on vSphere

– vSphere can reclaim idle CPU resources

– More efficient use of physical hardware

• VMware Workload Management

– SAP HANA “Prod 01” – Heavy EOQ processing

– SAP HANA “Prod 02” – Completed Processing

– vSphere Scheduler Can Redirect CPU resources to SAP HANA “PROD-1”

14

2TB 2x 512 Consolidated SAP HANA VMs

Reclaim/Redirect CPU Resources

2x 512GB SAP HANA Physical Appliances

Resources Cannot Be Reclaimed/Redirected

Consolidated Workloads Can Run “Faster Than Physical”

PROD 01EOM Processing

PROD 02Daily Reporting

Example: SAP HANA Dynamic Tiering Node

• Considerations when deploying SAP HANA

– SAP Guidance: SAP HANA & Dynamic TieringDeployments:• The distance between HANA hosts and Extended

Storage hosts should be as short as possible

• Avoid performance impact on distributed INSERTs, UPDATEs, or Queries

• Ideally, ES hosts should be placed inside the same rack as the HANA hosts

• VMware Goes One Better

– Co-location of SAP HANA Master Node and ES Host on same vSphere Host• Supported in production

– Co-location not supported for physical deployments

• Extremely Important Concept• Consider these principles for Dynamic Tiering or SAP

HANA Scale Out

• Any Latency Sensitive Workloads or MPP Architectures

SAP HANA Physical World

HANA HostES Host

SAP HANA Dynamic Tiering SAP HANA Scale Out

Example: SAP HANA Dynamic Tiering Node

• Practical Deployment of Physical HANA

– Adhere to DT or Scale Out Deployment Guidelines

• Move servers and or applications

• Re-cable servers/networks

• Talk to application owners

– Schedule Downtime

• etc,etc,etc..

• Practical Deployment of Virtual HANA

– Adhere to DT or Scale Out Deployment Guidelines

• Live Migration of exiting VM applications or databases

– No downtime

• Deploy on same physical or “closest” vSphere host

• Promise of the SDDC

– No downtime

– No re-cabling or reconfiguration necessary

SAP HANA Physical World

HANA HostES Host

SAP HANA on vSphere

SAP HANA Sizing & Dynamic TieringUse Cases

SAP BW Powered By HANA on vSphere • ES Host Candidates Tables

– Corporate Memory

– Write-Optimized Data Store Object (DSO)

– Persistent Staging Area

– Up to 20% to 40% of Total BW

• SP09 up to 20%

• SP10 up to 40%

• Future 70% of Total BW

• ES Host ROI

– Smaller in-memory footprint

– Standard x86 Servers

• HANA & ES Consolidation

– Support on vSphere

– Not Supported in Physical World

– vMotion Supported

18

SAP HANA BW System

Staging Corporate Memory Data Mart

SAP HANA Database

infoCubeWrite-Optimized

DSOData Source

Warm Store Hot Store

FACT TABLE

DATA

PSA TABLE

Data ACTIVE TABLE

Data

vSphere 5.5vSphere 5.x

OS

Worker Host

OS

ES Host

Certified hardwareCertified or Standard x86 Hardware

vMotion

Sizing: SAP BW Memory Footprint Reduction

NLS: Assumptions

Initial BW Footprint 10Tb (uncompressed raw data)

System is migrated to BW on HANA (7x compression)

Environment has been live for 5 years

All EDW data >2 years moved to NLS

All Datamart data > 2 years moved to NLS

5%25%

30%

40%Staging Layer (PSA)

Corporate Memory

EDW Layer

Architected Datamart(Reporting Layer)

Example Outcomes:

• HANA Migration + NLS implementation

• 10TB to 5.8Tb

• HANA Migration + Dynamic Tiering + NLS

• 10TB to 2.8Tb

• Licensing and Hardware Savings

• Less memory

• DT & NLS SAP IQ runs on x86 standard servers

• vSphere 5.5 -1TB artificial boundary

NLS & Dynamic Tiering: Assumptions

Initial BW Footprint 10Tb (uncompressed raw data)

System is migrated to BW on HANA (7x compression)

Environment has been live for 5 years

All EDW data >2 years moved to NLS

All Datamart data > 2 years moved to NLS

Entire corporate memory & PSA moved to columnar disk with

Dynamic Tiering

Example SAP BW Data Distribution

SAP HANA With Dynamic Tiering Use Cases

• Native SAP HANA Use Cases

– Non SAP Applications

– Lots of custom application development

• Selecting HANA as the database

• Sizing Guidance and Guidelines

– Leverage Mulit-Temperature Data Management

– HANA Worker Node to ES Host Ratios

• 64GB – 512 GB HANA: 1:4

• >512 GB HANA - <2TB HANA: 1:8

– 10GB NIC Node to Node

– 8 GB – 16 GB of RAM per physical core

– Data Throughput #Cores * 50-100 MB/s per core

• Can get quite complex

20

vSphere 5.5

Certified Hardware x86 Hardware

SAP 1TB

HANA

SAP 1TB

HANA

SAP 1TB

HANA

SAP 1TB

HANA

vSphere 5.x

HANA 8TB

ES Host

HANA 8TB

ES Host

HANA 8TB

ES Host

HANA 8TB

ES Host

SAP HANA Custom Application

Example: 9TB SAP HANA Databases

SAP IQ: Disk-backed Columnar Store

21

0

500

1000

1500

2000

2500

3000

3500

Load 1 Power Throughput Power(DQP)

Throughput(DQP)

VMDK Multiwriter

RDM SCSI Sharing

Physical

• SAP IQ

- Columnar; shared everything

- Scale up/out architecture

- Mature product – large install base

- Many VMware customers in production

• Complimentary to SAP HANA- SAP IQ, ASE, and SAP HANA

Synchronized Service Packs

• SAP IQ 15.4/16.0 validation testing (2013)- Standard x86 servers

- EMC® VNX® 5700 FC Unified Storage System

- 300GB single node and multiplex

- vMotion < 3 minutes under load

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

Timing Comparison (16 Cores)

SAP Business Suite on SAP ASE

• SAP ASE Certified to Run Business Suite- ASE 15.7 Certified in 2012

- Almost 10,000 installs

- License saving ~31%

- Hardware savings; requires 29% less processing power

- #1 Sales and Distribution Benchmark (SD) Results on 2, 4, 8 socket x86 Linux

• SAP Business Suite on ASE on VMware- Customer reference: Canadian Pacific Rail

- Seeing a 30% improvement in productivity

- Smaller IT footprint of the virtualized landscape delivering performance improvements

• SAP ASE 16 Launched 4/2/14- Up to 64 cores/vCPUs excellent scalability on VMware

- New component integration services to SAP HANA

- Full ASE database encryption

- Pathway to SAP HANA; investment protection

Best Practices

“We were able to convert everything —

our integrated SAP ASE database, SAP

applications, the entire operation — in

one weekend,”

– Mike Redeker CIO recalls.

The Software-Defined Data Center

SAP HANA In The Software-Defined Data Center

Transform storage by aligning it with app demands

Managementtools give wayto automation

Expand virtual compute to all

applications

Virtualize the network for speed

and efficiency

24

SAP HANA Compute Tier

SAP HANA Scale Up or Out SAP HANA Clones/Templates/

Host Profiles/Blueprints

SAP HANA Multi-Temperature Data

The Software-Defined Data Center - Storage

Transform storage by aligning it with app demands

25

SAP HANA Multi-Temperature Data Management IS Software Defined Storage

Multi-temperature Data Management Perfectly Aligns With VMware SDDC

Multi-Temperature Storage Options with SAP HANA

Data TemperatureProduct Feature/

Integration optionTechnology Sample Use Cases

SAP BW

on HANA

SAP Business

Suite on HANA

SAP HANA

NativeData in the context of Temperature Possible actions

HotSAP HANA

In-MemorySAP HANA in-Memory

Ideal for real-time analytics/streaming

data e.g.

Stock tick data streamed into SAP

HANA for immediate price fluctuation

analysis and trading actions

Hot data = Active/ operationally-relevant

data stored within HANA memory. Hot data is

frequently accessed and has higher

performance requirements.

Write, Read, Update, Delete

warmSAP HANA

Dynamic Tiering

Tightly Integrated disk-based

columnar technology

Big Data/Petascale extension - Best

suited for data which does not require

high speed RAM processing

e.g. Historical stock price data stored

in HANA extended tables for trend

analysis and portfolio management

(1) (2)

Warm data = = Active data Integral to the

operation of the platform. Warm data may be

older and not queried often, but is still online

and available for update.

Write, Read, Update, Delete

cold

Data Aging Tightly Integrated disk-based

columnar technology

Financial accounting data which is

closed/cleared and older than three

years

3 Data which is closed/cleared and is moved to

cold partitions on disk

Write, Read, Delete

Near-line Storage

(NLS)Separate disk-based storage

Older data stored in DSOs/Infocubes.

The concept is partition the data in

time-slices. Excellent Data

compression

Ready only data stored which is infrequently

accessed

Traditional usage includes

Write/Read. Planned support

in BW 7.40 SP11 for

exceptional inserts, updates

and deletes for NLS will be

supported for SP9/SP10.

Please see Notes section

frozenData Archiving

(ADK)

Separate disk/file-based

storage

Data which is traditionally retained

to fulfill statutory/legal requirements.

Excellent data compression. This

functionality is complemented with

SAP ILM which is used to manage the

lifecycle of data from inception in the

DB to final destruction from the

hardware

Read only/infrequently accessed

Write, Read

Destroy function available

using SAP Information

Lifecycle Management (ILM)

• General available Currently not available Not planned To be evaluated

1 Early shipment available for SAP BW 7.4; General availability planned Q4/2014

2 General availability with limited scope planned Q4/2014

3 For selected business objects

SDDC – Transform Storage By Aligning With App DemandsVMware Virtual Volumes

SAP HANA Extended Storage/NLS Host Sizing

– Storage throughout: 50 MB/s/core to 800 MB/s

– Disk types: 2-3 spinning disks/core or ~0.4 SSD disks / core

– Log Volume Size = 10 x volume of maximal daily data changes

– RLV size = At least 8 GB x number of CPU cores in DT compute node

– 8 GB – 16 GB of RAM per physical core

– 0.5 – 1.5 physical CPU cores per query

27

SAP HANA Storage KPIsToday Infrastructure Centric Model

• Static pre-allocation of shared storage container (LUN)

• Data services tied to storage container

• Vendor specific management

✖ Long provisioning cycles

✖ Overprovisioning of resources

✖ Management Complexity

App-Centric Automation

• Dynamic delivery of storage service levels when needed

• Fine control of data services at the VM level

• Common management across heterogeneous devices

• Virtual disks are natively represented on arrays

• Enables VM granular storage operations using array-based data services

Rapid provisioning

No overprovisioning of

resources

Simple Change

Management

Virtual Volumes

Storage Containers

Policy Driven

SAP HANA Examples

vSphere Virtual Volumes Architecture and Components

vSphere

Virtual Volumes

28

SAN / NAS

Vendor Provider (VASA)

Control

Path

Control

Path

Storage Policies

Access

Capacity

Published Capabilities

Snapshot

Replication

Deduplication

QoS

Virtual Datastore

Storage

Admin

VI Admin

VVOLs

Data

PathProtocol Endpoint PE

Supported vSphere Features

• SPBM

• Thin Provisioning

• Linked Clones

• Native Snapshots

• Protocols: NFS3, iSCSI, FC, FCoE

• View Storage Accelerator (CBRC)

• vMotion

• SvMotion

• DRS

• XvMotion

• vSphere SDK (VC APIs)

• VDPA/VDP

• View

• vRealize Operations

• vRealize Automation

• Stateless / Host Profiles

Creating Storage Containers/Profiles for SAP HANA

• Worked with Hitachi Storage & VI Admins

– Created Capabilities Spreadsheet• Entire SAP HANA Data Lifecycle

– SAP HANA

– DT – Extended Storage Host

– Near-Line Storage IQ

– Archiving

• Translated Complex Storage KPIs

– Virtual Volume Storage Containers

– Virtual Volume Storage Profiles

• Rapid Deployment

– Created SAP HANA VM• 512GB to 1TB

– Using 1 or More Profiles• SAP HANA, DT, NLS, Archiving

• Future Co-Logo White Paper and Reference Architecture

29

Storage Container Creation: SAP HANA DT and NLS Tier

• Hitachi Command Suite -> SBPM Tab –> Create Storage Container & Define Profiles

30

Create VM Storage Policies SAP HANA Data/Log File

31

• vSphere Web Client -> Polices and Profiles –> Create Storage Policy & Add Capabilities

Create New SAP HANA DT VM Using VVOLS Policies With Hitachi Storage

• vSphere Web Client -> New VM -> Select VM Storage Policy

• VM Will Be Provisioned on Storage Container that matches Selected Policy

32

The Software-Defined Data Center - Networking

33

Virtualize the network for speed

and efficiency

SAP HANA Scale Up or Out

SAP HANA Consists of Multi Network Zones or Tiers

SDDC – Virtualize Network For Speed and Efficiency

High Level Simplified SAP HANA Network Topology

• Client Zone

– SQL Client Communication

– Web browser or a mobile application (HTTP/S protocol)

• Internal Zone

– Scale out over multiple hosts; distributed SAP HANA system

– System Replication Network

• Secondary system to persist the same data and logs as on the primary system

– Storage Replication Network

• Transparent to SAP HANA: the storage mirroring synchronously or asynchronously

• Storage Zone

– HANA Persistent Storage – FC, NAS, Clustering

• Dynamic Tiering Zone

– SAP HANA Warm Data Management

• All Network Zones or Tiers

– Different network and security requirements

34

SAP HANA Network Zones/Tiers

NSX Overview, Architecture, and Components

Cloud Consumption • Self Service Portal

• vCloud Automation Center, OpenStack, Custom

Data Plane

NSX Edge

ESXi Hypervisor Kernel Modules

Distributed Services

• High – Performance Data Plane

• Scale-out Distributed Forwarding Model

Management Plane

NSX Manager

• Single configuration portal

• REST API entry-point

Control Plane

NSX Controller

• Manages Logical networks

• Control-Plane Protocol

• Separation of Control and Data Plane

FirewallDistributed

Logical RouterLogical

Switch

Lo

gic

al N

etw

ork

Ph

ysic

al

Netw

ork

…

…

SAP HANA Client Zone/Tier

• SAP Client Requirements

– All clients must be able to access all hosts in distributed system

– Separate Application Server Network and Other SAP HANA Client Network - Plus HA

• Micro Segmentation

• Dynamic scalability as more clients are added

• Different security requirements

• Load Balancing – Statement routing, Connection Selection, and Command splitting

– Dynamic east –west network traffic balancing

– External communications with SAP HANA servers

• Initiated by a web browser or a mobile application use the HTTP/S protocol to access SAP HANA Extended Application Services

• Multi-functional - firewall, load balancer, and VPN device.

36

VM VM VM VM VM VM

Logical Switch 1 Logical Switch 2

DSR Router

SSL ClientL3 Network

Applications Network Connectivity to Physical Networks

SAP HANA Internal DB Zone/Tier

• SAP Recommendations

– 10 Gbit/s Non-Blocking Switches Required

• SAP BW internode

• Storage Replication Network

• System Replication Network

• Dynamic Tiering Extended Host

– Requires separate network interface cards for a private network

• using separate IP addresses and ports

– System Replication across Data Centers

• Consider bandwidth, latency, and packet loss

– Distributed system – different traffic patterns

• Each index server is assigned to one server

• Can assign different tables to different hosts

• Can replicate tables to multiple hosts

37

ES

HostBW CRM

Client Zone DB Zone

HANA

Node

HANA

Node

Micro-segmentation – Multi-Tier Network Design

L3 Network

HANA

Node

HANA

Node

SAP HANASystem Replication

SAP HANA System Replication- (L2/L3 Network)Network Segmentation- Workload & Traffic Isolation

Transit Switch

Control Cluster

Control Center

NSX Manager

PerimeterGateway

SAP HANA Storage Zone/Tier

• SAP Recommendations

– The required bandwidth for the storage network

• ≥ 10 GbE for Ethernet for NAS

• ≥ 8 GbE for Fibre Channel in SANs.

– Separate networks for

• Database – logs and data files

• Database Backups

– SAP HANA NFS network for the shared directory

• 10GbE network

– All Networks Should be Fully Redundant

– Key Point: Micro-Segmentation and Multi-Tenant Applications

• If application is multi-tenant why virtualize?

– VMs are fully isolated. Optimized and secure – multiple OS’s

– Mobile across hosts or data centers – with firewall rules

– In physical world apps are bound to the server and rules

38

Storage Zone

Backup

Server

L3 Network

Remote Backup

HANA Node

Data/Log Shared

ES Host

Data/Log Shared

SAP HANA Node and ES Host- Data/Log Files FC; Shared NFSDatabase Backup - To Backup Server or Cloud

Transit

Control Cluster

Control Center

NSX Manager

PerimeterGateway

Distributed Router

FC FCNFS NFS FC

Backup

Data/Log

The Software-Defined Data Center – Compute

39

Expand virtual compute to all

applications

SAP HANA Data Mem/vCPUs

Right Sizing SAP HANA Landscapes

vRealize SAP HANA Plug-In - BlueMedora

40

• Exposes SAP HANA related performance, health, and

availability metrics within vRealize

• Includes out-of-the-box dashboards, supermetrics, metrics,

and metrics collections for SAP HANA

• Provides visibility into SAP HANA workloads running on

VMware vSphere 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 managementSAP HANA integration with vRealize delivers automated correlation

of performance, health, and availability data for SAP HANA

databases

BlueMedora Management Plug-In

SAP HANA vRealize w Blue Medora Plug-In

• SAP HANA Sizing

– Quick Sizer

– Evolving: SAP sizing much more precise

• VMware vRealize Right Sizing

– SAP HANA BlueMedora Plug-In

– Monitor memory and vCPU utilization

– Add/Delete resources

• Underutilized – Deploy more HANA

• Over utilized – SAP HANA unleased

– Workload management – vMotion/DRS

• Determine Consolidation Ratios

– No over commitment and actual usage characteristics

• Monitoring Absolute Must

– Optimal Architecture – too many choices

– Scale Up, Scale Out, Dynamic Teiring, NLS, Data Againg

41

Monitored CPU and Memory utilization during performance testing

Consistent Memory Overhead SAP HANA on vSphere

Peak Disk Usage and Latencies

The Software-Defined Data Center – Putting It All Together

42

Rapid Provisioning – Network, Compute, Storage

Managementtools give wayto automation

SAP HANA Clones/Templates/Host Profiles/Blueprints

Conclusions

• VMware & SAP Going In The Same Strategic Direction

– SAP HANA on vSphere – Most efficient price performance deployment model

– SAP planned innovation towards standard x86

– Reduced Complexity with the VMware Software Defined Data Center

• Now Is The Time For SAP HANA and The SDDC

– SAP lowered cost barriers - multi-temperature data management, dynamic tiering, near-line storage

– SAP HANA “Run Simple”

• Virtual Volumes

– Storage Abstraction

• NSX

– Network Abstraction

• vRealize Operations

– SAP HANA Blue Medora Management Pack

• Rapid Provisioning

– Templates, Clones, Blueprints

– Public or Private Clouds

43