DMM204 – Virtualization and Multi-Tenancy for SAP HANA€¦ · a dedicated share of SAP HANA instance data, configuration, user management and properties. ... • one or more SAP

Public

DMM204 – Virtualization and

Multi-Tenancy for SAP HANA

© 2015 SAP SE or an SAP affiliate company. All rights reserved. 2Public

Speakers

Las Vegas, Oct 19 - 23

Zora Caklovic

Barcelona, Nov 10 - 12

Jan Teichmann


Disclaimer

This presentation outlines our general product direction and should not be relied on in making a

purchase decision. This presentation is not subject to your license agreement or any other agreement

with SAP. SAP has no obligation to pursue any course of business outlined in this presentation or to

develop or release any functionality mentioned in this presentation. This presentation and SAP's

strategy and possible future developments are subject to change and may be changed by SAP at any

time for any reason without notice. This document is provided without a warranty of any kind, either

express or implied, including but not limited to, the implied warranties of merchantability, fitness for a

particular purpose, or non-infringement. SAP assumes no responsibility for errors or omissions in this

document, except if such damages were caused by SAP intentionally or grossly negligent.


Agenda

SAP HANA virtualization and multi-tenancy options

High-Level Overview

SAP HANA virtualized

Support Status & Outlook

SAP HANA multitenant database containers

MDC Support Status & Outlook

SAP HANA further multi-tenancy options

Hardware Partitioning, MCOS, MCOD Support Status & Outlook

Public

SAP HANA virtualization and

multi-tenancy optionsHigh-Level Overview


Virtualization and multitenancy for SAP HANAConcepts

“Within a multi-tenant architecture, a software application is designed to provide

every tenant a dedicated share of an instance including its data, configuration, user

management, tenant individual functionality and its properties.”

“A viable alternative is to use virtualization technology to host multiple isolated

instances of an application on one or more servers, enabling each customer

application to appear to run on a separate virtual machine”

Source: http://en.wikipedia.org/wiki/Multitenancy


SAP HANA virtualization / multi-tenancy options Introduction

• “SAP HANA virtualized” is a deployment option to abstract IT resources (simulating the existence of

hardware and creating several “virtual machines” (VMs) to host multiple operating systems and HANA

instances on a single server) and optimize infrastructure resource utilization.

• It can be compared to several lower-level technologies for HW partitioning of single physical servers into a

number of distinct smaller partitions that behave and perform like completely separate servers.

• SAP HANA also supports Multi-tenant Database Containers (MDC) where every database tenant represents

a dedicated share of SAP HANA instance data, configuration, user management and properties.

• Another viable alternative is the use of the Multiple Components on One System (MCOS) deployment

variant to host multiple isolated SAP HANA instances on one server.

• All 4 options are means to optimize HW efficiency and reduce TCO. Therefore, all of these deployment

options will be compared in this presentation.

• A validation process for virtualization / partitioning technologies has been established to determine all

necessary constraints and best practices and to ensure supportability and minimum performance requirements

for running SAP HANA in such environments.


Terminology

IT Virtualization Private Cloud Public Cloud Hybrid Cloud

Abstraction of IT

Resources

Provisioned for a

Single Organization

Provisioned for

Open Use

Composition of

Distinct Infrastructures

Bare Metal

Classic Setup for

Best Performance


SAP HANA Deployment Scenarios

On-Premise

Bare-Metal single Server

Scale-Out / HA & DR cluster

Tailored setup (storage, network, compute)

Cloud / Managed Service / Hosting

SAP HANA Cloud Platform

SAP HANA Enterprise Cloud

SAP HANA developer edition / Cloud Appliance Library

/ SAP HANA BYOL / SAP HANA One

Scalability

single instance

scale-out cluster

HW Access

bare metal

virtualized

HW Stack Setup

appliance

tailored

Location

on-premise

hosted

public cloud

Openness

Private(managed) cloud

3rd party publiccloud

Multi-Tenancy

Classic

Virtual

Partitioned

MCOS

MDC

Combine nearly every option w/ every other option

Private CloudMulti-Tenancy Setup

Virtualized / Partitioned with VMware / xPAR


SAP HANA virtualization / multi-tenancy optionsVertical View

• e.g. SAP NW AS ClientsApplication

• e.g. SAP HANA DB ContainersDatabase

• e.g. Linux ContainersOperating System

• e.g. Hypervisor / VMsVirtualization

• e.g. Logical / HW PartitionsServer

• e.g. Storage LUNsStorage


Schema X

SAP HANA Instance

App X

Schema Y

App Y

HW

OS

Database

Multiple Components,

one Database (MCOD)

Schema X

Database

SAP HANA Instance

App X

Schema Y

App Y

Database

SAP HANA Instance

Hypervisor

HW

OS OS

Multiple Components / Instances,

one System (MCOS, Virtualization) Multi-tenant Database Containers,

one HANA Instance (MDC)

SAP HANA virtualization / multi-tenancy optionsHorizontal View

See Notes 1661202 + 1826100 See SAP Notes 1788665 + 1681092 See SAP Note 2096000

Schema X

Tenant DB

SAP HANA MDC enabled Instance

App X

Schema Y

App Y

Tenant DB

HW

OS

https://service.sap.com/sap/support/notes/1661202


http://service.sap.com/sap/support/notes/1788665




SAP HANA Virtualization – Some StatisticsUsage and Scenarios

• Single-Node SAP HANA virtualized deployments are in GA: No statistics – Probably hundreds

• Multi-VM / Scale-out

“Controlled Availability”

Program for SAP HANA

virtualized on VMware

deployments, see table

• MCOS for production use in GA since June 2015: No statistics – A lot of interest

• MDC in GA since Nov 2014: No statistics – A lot of interest, first few live customers

# of customers Europe / US Scenario

Controlled Availability 75 39 / 21

6 B1

2 BPC

23 BW / mixed

28 Suite

16 In Clarification

• thereof live 11 6 / 3

• thereof 1 TB and plans

for > 1 TB

11

Public

SAP HANA virtualizedSupport Status & Outlook


SAP HANA virtualized 1/2Currently supported hypervisors / Logical partitioning technology

• VMware vSphere 5.1 with SAP HANA SPS 05 or later for non-production use cases

• VMware vSphere 5.5 with SAP HANA SPS 07 or later for production and non-production use cases

• In General Availability for single-VM scenarios.

See SAP Note 1995460 for specific information and constraints

• In Controlled Availability for multi-VM scenarios.

See SAP Note 2024433 for specific information and constraints. Note, that access to this SAP Note is restricted to customers participating in the controlled availability phase.

• In Controlled Availability for SAP BW, powered by SAP HANA, and further workloads of OLAP-type scale-out scenarios.

See SAP Note 2157587 for specific information and constraints.Note, that access to this SAP Note is restricted to customers participating in the controlled availability phase.

• VMware vSphere 6.0 with SAP HANA SPS 09 or later for non-production use cases

• Hitachi LPAR 2.0 with SAP HANA SPS 07 or later for production and non-production use cases

• In Controlled Availability for single- and multi-VM scenarios.

See SAP Note 2063057 for specific information and constraints. Note, that access to this SAP Note is restricted to customers participating in the controlled availability phase.






SAP HANA virtualized 2/2Currently Supported Hypervisors

• Huawei FusionSphere 3.1 with SAP HANA SPS 09 (or later releases) for production and non-production

use cases

• In Controlled Availability for single-VM scenarios.

See SAP Note 2186187 for specific information and constraints

• XEN with SAP HANA SPS 09 (or later releases) for non-production use cases



SAP HANA virtualizedRestrictions

The following general constraints and conditions do apply while running SAP HANA virtualized:

• Configuration and overall setup complies with the current version of the "SAP HANA Guidelines for being virtualized" and

the vendor specific best practice documents for running SAP HANA in a virtualized environment on corresponding

hypervisor.

• Each SAP HANA instance / virtual machine needs to be sized according to the existing SAP HANA sizing guidelines and

corresponding hypervisor vendor recommendations. CPU and memory over-provisioning must not be used.

• Beside "SAP BW, powered by SAP HANA in scale-out", the maximum size of a virtual SAP HANA instances is limited by

the maximum size the hypervisor supports per virtual machine and the application dependent core-to-memory ratios.

• The SAP HANA system setup needs to be done by an SAP HANA certified engineer, on SAP HANA certified hardware,

and successfully verified with the SAP HANA hardware configuration check tool (HWCCT, SAP HANA Tailored Datacenter

Integration option). Alternatively, the system can be delivered pre-configured with hypervisor and SAP HANA software

installed by SAP HANA hardware partner (SAP HANA appliance option).

• Nested virtualization (running a hypervisors within another hypervisor stack) is not supported by SAP.

Customers may, however, run virtualized applications on physically separated hardware partitions.


SAP HANA virtualizedControlled Availability Application Process

• Customers interested in running …

• multiple SAP HANA VMs on VMware vSphere 5.5 in production

• SAP BW, powered by SAP HANA on VMware vSphere 5.5. in scale-out and production

• one or more SAP HANA VMs on Hitachi LPAR 2.0 in production

… can apply for Controlled Availability of SAP HANA production support by sending an email to:

[email protected]

• This email should contain…

• High-level scenario description and timeline (e.g. planned Go-live date)

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

• Hardware spec (HW vendor, server t-shirt size),

• Planned HA/DR setup (if applicable),

• Contact details (if possible incl. SAP account number) for further communication

All information provided will be kept confidential and is only used during the selection process. Once accepted, customers will

receive the usual SAP HANA support as also provided for non virtualized environments for the presented scenario.


SAP HANA virtualizedHigh Availability Options for VMware vSphere

High Availability solution Native Hypervisor HA + SAP HANA AUTORESTART feature

In-Guest Cluster withStorage Replication

In-Guest Cluster withSAP HANA System Replication

SAP HANA host auto-failover (Standby VM)

Scenario Description Standard VM HA solution,

based on shared file system and/or storage replication.

Cluster manager handles take over to secondary site.Data replication between primary and secondary site by storage replication.

Cluster manager handles take over to secondary site. Data replication between primary and secondary site is done by SAP HANA system replication, however.

SAP HANA Standby VM to take

automatically over the role of another SAP HANA VM, in case of a

detected failure.

Operating system failures Yes Yes Yes Yes

Hardware failures Yes Yes Yes Yes

Application failures Yes* Yes Yes Yes

IP Redirect / DNS update Not necessary Handled by In-Guest Cluster Manager

Handled by In-Guest Cluster Manager

Handled by SAP HANA Client

RTO Medium(crash recovery of DB)

Medium(crash recovery of DB)

Shortest

(IP redirect)

Medium(crash recovery of DB)

RPO 0 0 0 (synchronous)>0 (asynchronous)

0

Remarks: Suitable also for disaster tolerant (DT) solution, in conjunction with storage replication and e.g. VMware Site Recovery Manager for site failover

2nd cluster node shall not reside on same physical host

Possible cluster manager includes SUSE HA; HP Service Guard, SAP LVM, VMware Site Recovery manager, …

Alternative to VM HA / DT solution, leveraging SAP HANA system replication to achieve possible lower RTO.

SAP HANA host auto-failover is currently limited to those hardware vendors, which have tested their SAP HANA Storage Connector API or STONITH setup with corresponding hypervisor.

* Standard VMware HA combined with SAP HANA Auto-Restart watchdog running inside a VM to monitor SAP HANA application status and triggers an SAP HANA process restart. OS and HW failures will get handled by

VMware HA.


SAP HANA virtualizedTechnology 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

Add variety

support for Hitachi LPAR

Support for Huawei

FusionSphere 3.1

XEN non-production

support

Further Hypervisors

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

in production and non-production

• Controlled Availability for multi-VM and

BW on HANA / OLAP scale-out scenarios

on VMware vSphere 5.5 in production

• Controlled Availability for Hitachi LPAR

(single and multiple partitions) in production

and Huawei FusionSphere 3.1

• On Roadmap

Support of larger VMs (4 TB, SoH) and 8-

socket hardware with VMware vSphere 6

Support for Multi-VM and Scale-Out in GA

Support of further Hypervisors

Public

SAP HANA multitenant

database containersMDC Support Status & Outlook


Schema X

SAP HANA Instance

App X

Schema Y

App Y

HW

OS

Database


one Database (MCOD)

Schema X

Database

SAP HANA Instance

App X

Schema Y

App Y

Database

SAP HANA Instance

Hypervisor

HW

OS OS






Schema X

Tenant DB


App X

Schema Y

App Y

Tenant DB

HW

OS







SAP HANA multi-tenancy optionsSAP HANA Multi-tenant Database Containers (MDC)

Multitenant Database Containers provide strong isolation capabilities

– Each tenant database has its own database admin and end users,

database catalog, repository, persistence, backups, traces and logs

– Tenants Memory and CPU consumption can be configured independently

– Integration with SAP HANA data center operation procedures,

housekeeping, backups (full and/or on tenant level), etc.

Multitenant Database Containers share one SID and Revision

– Shared installation of database system software

– Tenant databases are identified by name or port

– SAP HANA system replication covers whole system (Sys. DB and tenants)

– Additive sizing for all tenant database

Targeting MCOS-like on premise and SAP HANA Cloud

scenarios with reasonable amount of tenant

databases per system.

Application

SAP HANA System

Tenant DB

Application

Tenant DB

System DB

Cloud-affine SAP HANA MDC capabilities

Elasticity (shrink and grow tenants, move tenants)

Security (Separation of provider and customer)

Optimized for many small tenants (footprint reduction)


Customer’s View

SAP HANA multitenant database containers

Cloud usage

Scenario: many “equal” tenants on SAP HANA in a

shared system approach

Pilot: HCP, 2 scenarios in Roll-out

MCOS-like usage

Scenario: multiple SAP Applications on MDC tenants –

MCOS-like approach

– Typical setup: Tenant 1/2: BW + ERP

– Alternative setup: Tenant 1/2/3: BW Dev / QA / Prod

– See SAP Note 2121768



MDC vs. Workload ManagementDifferentiation

Workload Management

• Automated balancing between complex and long running queries vs. simple & short running ones

• Allow for HW resource consumption limits (CPUs, threads, memory) per instance / per DB user

• Privileged processing in Emergency Support Mode (through separate connection to the SAP start service)

SAP HANA Multi-tenant DB Containers

• Strong isolation capabilities between tenants and to system tenant

• Lower TCO, single software stack, easy instantiation, central configuration & administration

• Allow for HW resource consumption limits (CPUs, threads, memory) available per tenant

• Performance optimized federation / tenant access comparable to cross-schema access

• Future direction: Copy and move tenant provide enhanced flexibility in landscape management

Also available for

MCOS

=



Today Future DirectionPlanned Innovation

Planned InnovationsSAP HANA multitenant database containers (MDC)

Multiple tenant DBs in one SAP HANA system

• Individual and isolated databases

• Central topology: one HANA version, one HA/DR setup

Isolation

• Separate data files, distinct schemas and users,

individual encryption keys

• Option for extended tenant isolation (distinct OS users)

• Individual backup and recovery available

Cross-database access

• Based on SQL (read only)

• Several distinct object types available

• Explicit configuration including user mapping

• Multi-layered authorization scheme

Resource Management

• Resource control at the tenant DB level

• Concurrency control, core binding and memory allocation

GUI support for MDC

• SAP HANA Cockpit: basic functionality

• SAP Database Control Center: initial integration

Continuous Improvement

• Ensure maximum robustness

• Further application adoption

Cloud operations

• Easy/fast copy and move of tenant databases (internal

pilot focus)

GUI support for MDC

• Continuous extension of HANA Cockpit

Manage landscape

• Easy/fast copy and move of tenant databases

Cross-database access

• Extend functionality in general (e.g. beyond read)

Resource Management

• Advanced functionality for dynamic workload

management at the tenant DB level

• Easier, comprehensive administrator user experience,

including analytical support

Extend admin UI support

• SAP HANA Cockpit

• SAP Database Control Center

License management

• Individual tenant licenses

Lean tenant DB

• Reduce memory footprint as much as possible

Cloud operations

• Continuous improvement in regards to industrial-

strength cloud operational capabilities

Public

SAP HANA additional

multi-tenancy options Hardware Partitioning, MCOS, MCOD Support Status & Outlook


Schema X

SAP HANA Instance

App X

Schema Y

App Y

HW

OS

Database


one Database (MCOD)

Schema X

Database

SAP HANA Instance

App X

Schema Y

App Y

Database

SAP HANA Instance

Hypervisor

HW

OS OS






Schema X

Tenant DB


App X

Schema Y

App Y

Tenant DB

HW

OS







SAP HANA multi-tenancy optionsCurrently Supported HW Partitioning Technology & built-in capabilities

• Currently supported HW partitioning technology for running SAP HANA are:

• General support for HP nPartitions in context of HP CS 900 with Superdome X servers

for production and non-production use cases.

See SAP Note 2103848 for more specific information and constraints.

• General support for Fujitsu physical partitioning with PRIMEQUEST 2400 E/L and PRIMEQUEST 2800 E/L

for production and non-production use cases

See SAP Note 2111714 for more specific information and constraints.

• In addition MCOS and MCOD deployment options …… may also be considered to achieve multi-tenant like environments.

See SAP Note 1681092 (also in production for single-host / scale-up) and SAP Note 1661202 for specific

information and constraints.






Comparison MCOS/MDC/LPAR/Virtualization

MCOS SAP HANA multi-

tenant DB containers

HW-based

partitioning

SW level

virtualization

Strategy Best performance Best performance Thin additional layer Fully virtualized

datacenter?

Performance Overhead Low Low Medium “High” (relative to MDC)

HW resource management SAP HANA internal SAP HANA internal Firmware Hypervisor

Workload Isolation Application level Application Level OS level OS level

Shared SAP HANA binaries No Yes No No

Shared OS Yes Yes No No

HA support Yes Yes Yes Yes

HW vendor independent Yes Yes No Yes

Max. instance size Unlimited Unlimited E.g., Max Hitachi

LPAR v2 size is 1.5TB

E.g., Max VMware

vSphere 5.5 size is 1TB

All technologies create resource abstraction to divide the available hardware resources to enable running multiple

SAP HANA workloads on a single node or scale-out SAP HANA system. However, there are a few differences.


Further Information

Related SAP TechEd sessions:

DMM161 - SAP Hana multitenant Database Containers

DMM 204 – Virtualization and Multitenancy for SAP HANA

ITM 101 – Planning and Architecting an SAP HANA System Landscape

ITM107 – Tools for SAP HANA Operations

ITM361 – SAP HANA Operations – Advanced

SEC161 – Configuring and managing SAP HANA security

SEC200 – Security in Different SAP HANA Scenarios: Safeguarding Access and Data

SAP Public Web

SAP HANA Virtualized – Central Note https://service.sap.com/sap/support/notes/1788665

SAP HANA Hypervisor – Technology Roadmap http://scn.sap.com/docs/DOC-60329

SAP HANA certified HW http://global.sap.com/community/ebook/2014-09-02-hana-hardware/enEN/appliances.html

SAP HANA HW Configuration Check Tool and corresponding thresholds https://service.sap.com/sap/support/notes/1943937

SAP HANA Guidelines for SAP HANA running virtualized http://scn.sap.com/docs/DOC-60312


http://scn.sap.com/docs/DOC-60329

http://global.sap.com/community/ebook/2014-09-02-hana-hardware/enEN/appliances.html


http://scn.sap.com/docs/DOC-60312


SAP TechEd OnlineContinue your SAP TechEd education after the event!

http://sapteched.com/online

Access replays of keynotes, Demo Jam, SAP TechEd live interviews, select lecture sessions, and more!

Hands-on replays

http://sapteched.com/online

32© 2015 SAP SE or an SAP affiliate company. All rights reserved.

FeedbackPlease complete your session evaluation for

DMM204



Thank you

Contact information:

Dr. Jan Teichmann, Senior Director SAP HANA Product & Strategy

Zora Caklovic, Senior Director SAP HANA Product & Strategy

[email protected]

[email protected]

[email protected]

mailto:[email protected]



Public

Additional Material


Virtualization and multitenancy for SAP HANA

The Why?

Virtualization and multi-tenancy technologies help companies maximize physical resources by enabling IT

to share physical CPU, RAM, and I/O resources.

SAP HANA customers can leverage these technologies to enable running of multiple workloads on one or

more HANA servers, resulting in more efficient use of underlying infrastructure and lower TCO.

Virtualization and multi-tenancy are not competitive technologies, they do different things and are

considered complimentary offerings.

Definitions

SAP HANA Virtualization approach is a viable alternative to native HANA multi-tenancy

whearas 3rd party virtualization/partitioning technologies are leveraged to host multiple isolated SAP

HANA instances on one or more servers, enabling each database instance to appear as if running on a

separate machine.

SAP HANA multi-tenancy capabilities provide built-in multi-tenancy support,

whereas every database tenant represents a dedicated share of an SAP HANA instance data,

configuration, user management and properties.


Virtualization technologies for SAP HANAOverview & Grouping

3rd party virtualization technologies help increase SAP HANA infrastructure efficiency:

A resource abstraction layer divides available hardware and software resources and enables running multiple SAP HANA

workloads on a single node or scale-out certified HANA systems

Based on where a resource abstraction layer is created, virtualization technologies can be grouped as follows:

Virtualization Technologies

Hardware Partitioning Software Virtualization

Physically segments a server, by taking

a single large server and separating it

into isolated, logical partitions that

behave and perform like completely

separate servers.

Failures of one partition do not influence

other partition – online maintenance

enabled

Hypervisor server abstracts processor,

memory, storage and networking resources

into multiple virtual machines that run

unmodified operating systems and applications

Server hardware resources are divided into

multiple partitions, which appear as

independent “bare metal” servers resulting in

increased utilization and a reduction in

licensing costs.


Virtualization technologies supported with SAP HANA

SAP HANA provides support for a number of different 3rd party virtualization technologies to enable

sharing of infrastructure resources, improve efficiency and lower TCO cost.

An SAP validation process for virtualization (also called “hypervisor”) technologies has been established to

determine all necessary constraints and best practices and to ensure supportability and minimum performance

requirements for running SAP HANA in such environments.

Hypervisor (Virtual Machine Manager)

A program that creates a resource abstraction layer to divide

available hardware and software resources and enable

running multiple SAP HANA workloads on a single node or

scale-out certified HANA systems.

So far, the following virtualization technologies have been validated for SAP HANA:

Software virtualization technologies

VMware vSphere 5.5 ESX hypervisor , Huawei FusionSphere 3.1

Hardware partitioning

Hitachi LPAR, HP nPAR, Fujitsu pPAR, IBM Power LPAR


SAP HANA multitenancyOverview of native HANA multi-tenancy capabilities

SAP HANA built-in multi-tenancy capabilities provide customers with additional deployment options to allow for

greater sharing of hardware resources by running multiple applications on one or more HANA servers.

Prior to SPS 9 release, SAP provided restricted support for multi-tenant database deployments via multiple

components, one database (MCOD), and multiple components, one system (MCOS) deployment models.

SAP HANA multi-tenant database capabilities (MDC) introduced with SPS 9 release provide a full production

support for running multiple SAP applications within a multitenant HANA database hosted by scale-up/scale-out

HANA appliance.

“MCOD” Multiple Components in one Database

Multiple SAP applications residing within a single HANA

database hosted by scale-up/scale-out HANA appliance

“MCOS” Multiple Components in one System

Multiple SAP applications within respective multiple HANA

databases hosted by scale-up/scale-out HANA appliance

“MDC” Multitenant Database ContainersMultiple SAP applications within a multitenant HANA

database hosted by scale-up/scale-out HANA appliance


Schema X

SAP HANA Instance

App X

Schema Y

App Y

HW

OS

Database


one Database (MCOD)

Schema X

Database

SAP HANA Instance

App X

Schema Y

App Y

Database

SAP HANA Instance

Hypervisor

HW

OS OS




Virtualization and multitenancy for SAP HANAHorizontal View


Schema X

Tenant DB


App X

Schema Y

App Y

Tenant DB

HW

OS

“MCOD”

Multiple Components on one Database

1 x HANA host server

1 x HANA DB

n x DB schema

n x Applications

Prod. usage for white listed scenarios allowed

Sample scenario: SAP ERP together with SAP

Fraud Mgmt.

“MCOS”, Virtualization

Multiple App Components/ Virtual Machines on one

System


n x HANA DB

n x DB schema

n x Applications

Restricted production support provided

Sample scenario: DEV and QA system on one

HANA host server.

“MDC”, Multi-tenant database containers

Multiple App Components on one System


n x HANA DB

n x DB schema

n x Applications

Full production support provided

Sample scenario: DEV and QA system on one HANA host

server.







Virtualization for SAP HANACurrent Status (Intel x86 platforms)

Single HANA VMIn Controlled Availability

SAP Note 2063057*

SAP Note 2024433*

SAP Note 1995460

SAP HANA on VMware

vSphere 5.5 /ESXi

HP CS900 nPAR

Fujitsu PRIMEQUEST 2800 E/L pPAR

Single/Multi SAP HANA host server partitionsIn General Availability

HP nPAR supported configs.:

Scale up: 2 or 4 nPartitions with 4 sockets (3TB/2TB/1TB,

2 nPartitions with 8 sockets (6TB/4TB/2TB) or

2 nPartitions with 4 sockets + 1 nPartition with 8 sockets

Fujitsu pPAR supported configs.:

Scale up: max 4 pPAR partitions with 8s, 6TB each,

running in parallel on a certified PQ2800 HANA host server

SAP Note 2157587*

SAP Note 2103848

SAP Note 211714

- For single SAP HANA virtual machine on

a single certified SAP HANA host server

Single HANA VM in General Availability

- For multiple SAP HANA virtual machines

on a single certified SAP HANA host server

Multi HANA VM in Controlled Availability

Single/Multi BWoH VM in Controlled Availability

- For SAP Business Warehouse on SAP

HANA scale-out configurations in virtualized

environment

Scale-up scenarios support

Scale-out scenarios support

Software Virtualization Hardware Partitioning

Virtualization for SAP HANA

SAP HANA on Hitachi

LPAR 2.0SAP HANA on Huawei

FusionSphere 3.1


Single/Multi HANA VMIn Controlled Availability

- For single or multiple

SAP HANA virtual machines on a

single certified Hitachi server

hosting HANA virtual machine(s)


- For single or multiple

SAP HANA virtual machines on a

single certified Huawei server

hosting HANA virtual machine(s)


HP nPAR supported configs.:

8 socket (2TB/1TB) SAP Note 2103848

Scale-out scenarios support

SAP Note 2186187*

https://websmp130.sap-ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/sno/ui_entry/entry.htm?param=69765F6D6F64653D3030312669765F7361706E6F7465735F6E756D6265723D3231303338343826




How to choose virtualization technology that best fit your needs?

There are several things that customers should consider before determining which virtualziation

technology may be the best fit for their needs:

Do you already have a preferred technology/hardware vendor?

– Many customers have already standardized their Data Center operations on VMware technologies

– Hardware partitioning technologies have limited support by a couple of SAP partners for specific HW models (e.g. HP CS900, Fujitsu PQ2800…)

Workload performance requirements

– Hardware partitioning technologies typically have lower performance penalty than VMware software-level server virtualization

Database size, scalability and use case requirements

– Virtualized HANA is currently supported only on smaller, 2 and 4 socket HANA systems, in scale up scenarios; also has limitations regarding the

maximum HANA VM size supported; mulitple node, scale out deployments on VMware vSphere are supported only for SAP BWoH use case.

Isolation and security requirements

– Both, virtualization and partitioning offer isolation and security at the OS-level; For tenant-based isolation and security at the database level,

customers should use SAP HANA native multi-tenant database containers (MDC) capability

Since these requirements may often represent conflicting goals, the universal approach for

efficient infrastructure sharing is hard to reach. Each use case scenario typically require specific

considerations to find a compromise.


Virtualization for SAP HANATechnology 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

Add variety

support for Hitachi LPAR

Support for Huawei

FusionSphere 3.1

XEN non-production

support

Further Hypervisors

H1/2014 H2/2014 H1/2015 H2/2015+


(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.5

in production and non-production

• Controlled Availability for multi-VM and

BW on HANA / OLAP scale-out scenarios

on VMware vSphere 5.5 in production

• Controlled Availability for Hitachi LPAR

(single and multiple partitions) in production

and Huawei FusionSphere 3.1

• On Roadmap

Support of larger VMs (> 1TB) and 8-socket

HANA servers with VMware vSphere 6

Support for Multi-VM and Scale-Out in GA


SAP HANA multitenancy

• Since SPS 09 the SAP HANA platform provides built-in Multi-tenant Database Container (MDC) support

…

… to separate workload within a single SAP HANA database installation.

See SAP Note 2096000 for specific information and constraints.

• In addition MCOS and MCOD deployment options …

… may also be considered to achieve multi-tenant like environments.

See SAP Note 1681092 (also in production for single-host / scale-up) and SAP Note 1661202 for specific

information and constraints.

Our focus for today: SAP HANA Multi-tenant Database Container (MDC) capability …MDC





SAP HANA multitenant database containers - Concept

Multitenant Database Containers provide strong isolation

capabilities

Each tenant database has its own database admin and end users, database catalog,

repository, persistence, backups, traces and logs

Tenants Memory and CPU consumption can be configured independently

Integration with SAP HANA data center operation procedures, housekeeping,

backups (full and/or on tenant level), etc.

Multitenant Database Containers share one SID and Revision

Shared installation of database system software

Tenant databases are identified by name or port

SAP HANA system replication covers whole system (Sys. DB and tenants)

Additive sizing for all tenant database

Targeting MCOS-like on premise and SAP HANA cloud platform

scenarios with a reasonable number of tenant databases per

system.

Application

SAP HANA System

Tenant DB

Application

Tenant DB

System DB


SAP HANA multitenant database containers - Concept

New administration layer containing a System database

• Landscape topology information

• System-wide parameter settings

• Focal point for complete backup of all databases

• Resource management for all tenant DBs (CPU, memory, etc)

0 to n tenant databases

Individual backup/restore of tenant database

One database software version for a SAP HANA system (all

tenant databases and system database)

HA/DR setting covers whole SAP HANA system: all tenants are

included in a HA/DR scenario

AS ABAP

Connect to:

HAN.DB’A’

SAP HANA

SID: HAN

HAN.DB A

Any Application

Connect to:

HAN.<port>

HAN.DB B

HAN.SystemDB


SAP HANA multitenant database containers User and Administration Layers

SAP HANA

Schemas ABC, ….

Monitoring Information Database A

Configuration Database A

Schemas XYZ, …

Monitoring Information Database B

Configuration Database B

System DB

Monitoring Information – Overall System

Cumulated Database Information (Union)

Overall System Configuration

System Administrator

Tenant DB “A” Tenant DB “B”

Administrator DB B

Users on DB B

Roles & Authorization

Administrator DB A

Users on DB A

Roles & Authorization


SAP HANA System

Scale-out scenario with SAP HANA multitenant database containersExample 1

Tenant databases can

spread over multiple

nodes (hosts) in

scale-out systems

Example:

If host 2 goes down, the

standby host becomes

active. The tenant DBs

normally running on host

2 will become active on

the standby host

System DB

(standby)System DB

Tenant DB B

Tenant DB A.2

System DB

(standby)

Tenant DB A.1

HOST 1 HOST 3 HOST 2 Standby (HOST 4)

System DB

(standby)


SAP HANA System

Scale-out scenario with SAP HANA multitenant database containersExample 2

Tenant databases can

spread over multiple

nodes (hosts) in

scale-out systems

Note: contention for resources may

occur. Sizing and pro-active

administrator resource allocations

(parameter settings) may be required

to maintain expected performance

Example:

If host 2 goes down, the

standby host becomes

active. The tenant DBs

normally running on host

2 will become active on

the standby host

Tenant DB A.3

Tenant DB B.1

System DB

(standby)System DB

Tenant DB C

Tenant DB B.2

Tenant DB A.2

System DB

(standby)

Tenant DB D

Tenant DB A.1

HOST 1 HOST 3 HOST 2 Standby (HOST 4)

System DB

(standby)


Cross-DB queries with SAP HANA multitenant database containers

SAP HANA System

Tenant DB B

Tenant DB A

Scan

Scan

Join

ScanScan

Tenant DB C

Scan

HOST 1 HOST 2

Cross-database

queries (federation)

are supported in SQL

engine and

Calculation engine.

SPS09: Read-only


MDC vs. Virtualization

Considerations and tradeoffs

Database Size

• Virtualization is usually limited in size and supported scenarios (e.g. 1 TB for vSphere 5.5; in general no-scale out as of today)

• MDC supports any size and scenario

Isolation

• MDC creates isolation between tenants -inside one DBMS

• Virtualization & Partitioning offers isolation down to OS-level

Performance

• MDC can handle HW resource management on database level (SQL)

• Virtualization can only balance workload without application knowledge (outside / black-box view)

DC Strategy

• Virtualization adds another technology layer which may required licenses and knowledge.

• A virtual SAP HANA system may however also just plug-in into an existing and fully virtualized datacenter.

MDC: SAP HANA Multi-tenant database containers


© 2015 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company.

SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate

company) in Germany and other countries. Please see http://global12.sap.com/corporate-en/legal/copyright/index.epx for additional trademark information and notices.

Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors.

National product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP SE or its

affiliated companies shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP SE or SAP affiliate company products and

services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as

constituting an additional warranty.

In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop

or release any functionality mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future

developments, products, and/or platform directions and functionality are all subject to change and may be changed by SAP SE or its affiliated companies at any time

for any reason without notice. The information in this document is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. All forward-

looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are cautioned not to place

undue reliance on these forward-looking statements, which speak only as of their dates, and they should not be relied upon in making purchasing decisions.

http://global12.sap.com/corporate-en/legal/copyright/index.epx

Documents

DMM204 – Virtualization and Multi-Tenancy for SAP HANA€¦ · a dedicated share of SAP HANA instance data, configuration, user management and properties. ... • one or more SAP