customer sap hana virtualized: new options and a

Dr. Jan Teichmann, SAP HANA

March, 2017

SAP HANA Virtualized: New Options and a

Comparison to Multitenancy

Customer

© 2017 SAP SE or an SAP affiliate company. All rights reserved. 2Customer

Disclaimer

The information in this presentation is confidential and proprietary to SAP and may not be disclosed without the permission of

SAP. Except for your obligation to protect confidential information, this presentation is not subject to your license agreement or

any other service or subscription agreement with SAP. SAP has no obligation to pursue any course of business outlined in this

presentation or any related document, or to develop or release any functionality mentioned therein.

This presentation, or any related document and SAP's strategy and possible future developments, products and or platforms

directions and functionality are all subject to change and may be changed by SAP at any time for any reason without notice.

The information in this presentation is not a commitment, promise or legal obligation to deliver any material, code or functionality.

This presentation 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. This presentation is for informational

purposes and may not be incorporated into a contract. SAP assumes no responsibility for errors or omissions in this

presentation, except if such damages were caused by SAP’s intentional or gross negligence.

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.


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

Additional Options for Landscape Management

LVM / LaMa

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


Cloud / Virtualization 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

SW-defined

Data Center


Virtualization and multitenancy for SAP HANADeployment options view

1 – Dedicated 2 – HW Partitioning 3 – SW Hypervisor

Virtualization

4 – MCOD 5 – MCOS 6 – Multi-tenant

database containers

SAP HANA

OS + Hardware

DB

Schema

DB

Schema

Storage

SAP HANA

OS + Hardware

DB

Schema

SAP HANA

DB

Schema

Storage

OS + Hardware

Storage

SAP HANA

DB

Tenant

DB

Schema

DB

Tenant

DB

Schema

Storage

SAP HANA

OS +

Server

DB

Schema

SAP HANA

DB

Schema

OS +

Server

Storage

SAP HANA

Hardware

DB

Schema

SAP HANA

DB

Schema

VM + OS VM + OS

Hypervisor

Storage

Server Resources

Storage

OS + HW

Partition

OS + HW

Partition

SAP HANA

DB

Schema

SAP HANA

DB

Schema

App X App Y App X App Y App X App Y App X App Y App X App Y App X App Y

HANA Native HANA Virtualization & Partitioning HANA Multi-tenancy


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


Virtualization, MCOS, MDC, MCOD

HW Partitioning may host

Virtualization / Logical Partitioning

Virtualization may host MCOS

MCOS may host MDC

MDC may host MCOD (supported)

VM 1 or LPAR 1

VM 2 or LPAR 2

HANA 2HANA 1

Tenant 1

Tenant 2

Tenant 3 Schema

2

Schema

1

HW partition 1 HW partition 2

In current reality this would probably lead

to CPU or memory contention ( MCOS

+ MDC), but this might change in future

releases?

SAP HANA virtualizedSupport Status & Outlook


Virtualization technologies for SAP HANAOverview and Grouping

Virtualization technologies help increase SAP HANA infrastructure efficiency by providing a resource abstraction

layer that divides available hardware and software resources and enables running multiple SAP HANA workloads on

a single node or scale-out certified HANA systems.

Increased resource utilization comes at a price: When running HANA on a Hypervisor, there is an additional

overhead in the system’s performance (3% - 17+%, depending on the virt. technology and workload type)

Virtualization Technologies

Static Hardware partitioning Software-level (Hypervisor-server) virtualization

Physical HW can be partitioned into 2 or 4 parts “electronically,

statically” so that there are e. g. no more QPI links active

between them at runtime:

1. e.g. HPE nPARs, Fujitsu pPARs, and Lenovo X6 server

partitioning

Hypervisor server performs a complete simulation of the

underlying hardware. There 2 Hypervisor types:

1. Software virtualization as an abstraction and emulation of HW

resources at runtime, potentially enabling hodAdd, hotPlug etc.

capabilities, e. g. VMware vSphere, Huawei FusionSphere, XEN,

KVM…

2. Logical, firmware-level partitioning of HW (e.g. Hitachi LPARs

and IBM Power 8 LPARs)


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, multi-VM scenarios and for SAP BW, powered by SAP HANA,

and further workloads of OLAP-type scale-out scenarios

VMware vSphere 6.0

– In General Availability with SAP HANA SPS 09 or later for all deployment scenarios for non-production use

– In General Availability with SAP HANA SPS 11 / 12 (or later releases) for production single-VM use (HSW,

BDW) and multi-VM on full and half-sockets (HSW) use cases

VMware vSphere 6.5

– In General Availability with SAP HANA SPS 12 (or later releases) for production single-VM use

up to 4 TB of main memory (BDW)

Achievements of last 9 months in greenFor specific information and constraints see SAP Note 1788665 and notes linked therein.

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


SAP HANA virtualized 2/2Currently Supported Hypervisors / Logical Partitioning Technology

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 on full and half-sockets (HSW, BDW).

IBM PowerVM LPAR on IBM Power Systems for production use-cases

– In General Availability for single-VM and multi-VM scenarios with up to 8 LPARs on 1 server.

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 on certified 4-socket Huawei hardware.

Huawei FusionSphere 5.1 / 6.0 with SAP HANA SPS 10 / 11 (or later releases) for production and non-

production use cases

– In Controlled Availability for all use cases on Ivy Bridge and Haswell hardware up to 1 TB.

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

KVM with SAP HANA SPS 09 (or later releases) for non-production use casesAchievements of last 9 months in green

For specific information and constraints see SAP Note 1788665 and notes linked therein.



SAP HANA virtualizedPublic Benchmarks

Difference in BW-EML

throughput per hour

between native and

virtual SAP HANA

certified HP server was

approximately 12%

OLAP workload public Benchmark

Show performance characteristics of

SAP HANA on a particular platform in

a comparable manner

BW-EML

In transition phase to

New Benchmark “SAP BW, edition

for SAP HANA” (“BW4”)

Future

New Benchmark for “SAP BW, edition for SAP HANA”

Existing

BW-EML

Benchmarks on Ivy Bridge


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 Data Center

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 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 2013 to 2016+)

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

Further scenarios

Add variety

support for Hitachi LPAR

Support for Huawei FusionSphere 3.1

Support for Huawei FusionSphere 5.1 /

6.0

XEN/KVM non-production support

Further Hypervisors

2013 2014 2015 2016+

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 Availability for single node

deployments of SAP HANA on VMware

vSphere 6.0 in production and non-

production

• General Availability for all use cases for

SAP HANA on VMware vSphere 5.5

in production and non-production

• Controlled Availability for Hitachi LPAR

(single and multiple partitions) in production

• Controlled Availability for all use cases for

SAP HANA on Huawei FusionSphere 3.1 /

5.1 / 6.0 in production and non-production

• On Roadmap

Support for further scenarios

Support of further Hypervisors

SAP HANA Multitenant

Database Containers (MDC)MDC Support Status & Outlook


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) Multitenant 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 instance

App X

Schema Y

App Y

Tenant DB

HW

OS



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




SAP HANA multi-tenancy optionsSAP HANA Multitenant 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)


Copying and Moving Tenant Databases Between SystemsSPS 12 Enhancements

Manage your system landscape efficiently and respond flexibly to changing resource requirements

Uses SAP HANA system replication mechanisms

Copy and moved securely and conveniently with near-zero downtime

1. The tenant database is copied with all

of its data to a newly created tenant

database.

SAP HANA System

DB2DB1

SYSTEM

DB

SAP HANA System

DB3DB4

SYSTEM

DB

Replicate

CREATE DATABASE DB4 AS REPLICA

OF DB2 AT ‘host:port';


1. First the tenant database is copied

with all of its data to a newly created

tenant database in a target system.

2. Once all data has been successfully

transferred, the new tenant database

is started as a separate, independent

database.





SAP HANA System

DB1

SYSTEM

DB

SAP HANA System

DB3DB4

SYSTEM

DB

ALTER DATABASE DB4 FINALIZE

REPLICA;

DB2


1. First the tenant database is copied

with all of its data to a newly created

tenant database in a target system.

2. Once all data has been successfully

transferred, the new tenant database

is started as a separate, independent

database.

3. Moving a tenant to another system,

the original tenant is deleted after

takeover completion.





SAP HANA System

DB1

SYSTEM

DB

SAP HANA System

DB3DB4

SYSTEM

DB

ALTER DATABASE DB4 FINALIZE

REPLICA DROP SOURCE DATABASE;

DB2


Copying and Moving Tenant Databases Between Systems

Important Note:

Because copy/move tenant uses SAP HANA system replication mechanisms

– For the time being system replication and copy/move tenant cannot run in parallel

When copy/move shall be used HSR must be inactive, otherwise one has to stay with backup/restore for

tenant copy purpose (plan to solve the issue in 2017)


Cross-Tenant Database Access

SELECT * FROM schema1.table1 AS tab1, db2.schema2.table2 as tab2

WHERE tab2.column2 = “excelsior”

Cross-tenant database access works as with a special type of SQL access, e.g.:

SQL views

Scripted and graphical calculation views

Procedures

Synonyms

Object types that can access remote DB objects

Schemas

Row store and column store tables (not including virtual tables)

SQL views (not including monitoring views)

Graphical calculation viewsif they only use supported object types as data sources

if they don’t use procedure-based analytic privileges

Synonyms

Object types that can be accessed on remote DBs


Cross-Tenant Database Access – Restrictions

These objects cannot reference remote tenant database objects (in other tenant DBs):

Hierarchy views

Analytic views

Attribute views

These remote tenant database objects cannot be accessed in a SELECT query:

Virtual tables

Sequences

Monitoring views

Triggers

Indexes

Attribute views and analytic views need to be converted to calculation views in order to use remote tenant database objects

Cross-database DDL statements are not supported

DML statements other than SELECT are not supported


SAP HANA virtualized and Dynamic TieringGeneral conditions and constraints

Considerations when deploying SAP HANA

SAP Guidance: SAP HANA & Dynamic Tiering Deployments

The distance between SAP HANA nodes and Extended Storage nodes

should be as short as possible (ideally, inside the same rack)

Co-location is not supported, neither on 1 physical server nor inside 1 VM – but

running HANA in a 1 VM together with DT on a physical server is supported

Potential VMware benefits

Co-location of SAP HANA node and ES node on same vSphere Host

(see above)

Current support status

SAP HANA virtualized with DT is currently not supported in production

SAP is planning to provide virtualization partners with a “self-validation” test package

SAP HANA with Dynamic Tiering


SAP HANA Federation capabilities

MDC SDA (incl. MCOS)

Cross-tenant Cross-database

SQL: tenant as schema qualifier SQL: DB as virtual table

SAP HANA tenant to tenant SAP HANA + 10 sources

Read-only Read + write

No consistent read across tenants

(databases)

No consistent read across databases, no

common write transactions

No data caching or replication Data caching

Fast but no “large result sets“ Medium fast (no “large result sets“)

SAP HANA Query optimizer knows MDC SAP HANA Query optimizer knows SDA (limited)


Comparing Cross Access ScenariosMCOD vs MDC/cross-tenant access vs Smart Data Access

SAP HANA Instance

Tenant DBTenant DB

Schema X

App X

Schema Y

App Y

HW

OS

Multitenant Database Containers,


See SAP Note 2096000

SAP HANA Instance

App X App Y

HW

OS


one Database (MCOD)

See Notes 1661202 + 1826100

Database

Schema X Schema Y

Criteria Cross-schema accessMCOD

Cross-tenant accessMDC

Smart Data AccessMDC/Single DB

Query Features Full SQL functionality available Restrictions for cross tenant access

apply (see documentation)

Restrictions for smart data access

apply (see documentation)

DB Query Optimization

(Engines = Database query

processing engines)

Engines perform database-wide

query optimization.

Schemas share same database

Engines perform tenant-wide query

optimization with some extensions.

Schemas are on different tenants

Engines perform query optimization

on the respective DB (+ limited

across DBs). Schemas are on

different DBs

Required Modelling Effort SQL optimization done by single

database for cross-schema

queries,

i.e. also mediocre SQL code

performs well.

2-Layer access:

Schema.Table

Knowledge and consideration of

modelling restrictions needed.

Better SQL code has significant

impact on performance.

3-Layer access:

DBName.Schema.Table

Knowledge and consideration of

modelling restrictions needed.

Better SQL code has significant

impact on performance.

Access through virtual table model

Data Transfer Cost Low:

Memory and processes shared,

less impact of huge result sets

Medium:

HANA internal network protocol

and separate processes,

larger impact of huge result sets

High:

Remote SQL connection, external

network and separate processes,

largest impact of huge result sets

System Operations and

Data Isolation

SQL authorization,

full database backup,

less flavoured resource mgmt.

Tenant isolation,

backup per tenant,

more resource mgmt. options

DB isolation,

backup per DB,

more resource mgmt. options





Tenant size Do not overprovision, size as the sum of single non-MDC systems

Keep tenants on single host as long as possible, do not artificially scale out (inside an MDC)

Use allocation limits and start with max-concurrency to avoid resource contention (remark:

tenant restart required for pinning)

Follow the application scale-out recommendations

ERP may run on an OLAP sized system!

BW will not run on an OLTP sized system!

Workloads The sizing CPU / mem needs to adhere the more dominant application for a homogenous MDC

cluster (in case OLAP workload is in the game it needs to adhere to OLAP configuration)

For BW Scale-out: “protect” the master node CPU / mem size against competing workload, e.g. put

BW master nodes together or utilize CPU pinning

Cross-tenant access with “large result sets” needs high network bandwidth (try to keep these

operations tenant-local)

MDC Scale-out Rules


MDC scale-out patternsPossible Setups, Benefits to be Assessed

Combine scaled-out BW systems with extension nodes. Being on the safe side.

node 6node 1 node 2 node 3 node 4 node 5

Master

BW 1Worker 1

BW 2

Worker 1

BW 1Master

BW 2

Worker 2

BW1

node 7

MDC

Worker 2

BW 2

Worker 3

BW1

Stand by

node 8


MDC scale-out patternsPossible Setups, Benefits to be Assessed

Data marts as individual tenants. Data mart as individual tenant. Combined

with another tenant (application)

node 1 node 2 node 3

ERP

Data

Mart 1

MDC

Standby

Data

Mart 2

node 1 node 2 node 3

ERP

Data

Mart

MDC

Standby



Today (Recent SPS12) Planned Q4/2016Planned Q3/2016 Planned 2017

MDC: Multitenant Database ContainersProduct road map overview - key themes and capabilities

Continuous Improvement

Ensure maximum robustness

Further application adoption

Cloud operations

Easy copy and move of tenant databases with near

zero downtime (command line version)

Tenant awareness in hdbuserstore

GUI Support for MDC

Continuous extension of SAP HANA Cockpit

Cross-Database Access

Auditing for cross-database queries

Workload class mapping for cross-database queries

No HANA platform shipment in Q3/2016 Backup & Recovery

Recover single db backup to tenant database

BACKINT support for tenant copy

Migration Support/Rolling Upgrade

Convert an active single db HSR setup into an MDC

setup

Administration/UI Support

Optimized copy/move for trusted environments (no

need for certificates)

Miscellaneous

SQL commands for kill tenant

MDC to become default setting

Manage Landscapes/Cloud Operations

GUI support copy and move of tenant databases

Flexible tenant provisioning, renaming

Recovery based on storage snapshots

Keep backup history when adding/removing services

with persistency

Re-register tenant databases after system db

disaster recovery

Enhanced operations for configuration, alerts, AFLs

Tenant isolation down the stack: OS, I/O, encryption

Reduce tenant memory footprint as much as

possible

Cross-Database Access

Extend functionality and supportability (RPC, …)

Resource Management

Advanced functionality for dynamic workload

management at the tenant DB level

Extend Admin UI Support

SAP HANA Cockpit MDC Administration

SAP HANA Cockpit MDC Landscape View

License Management

Individual tenant licenses

Status of Q4 2016

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

Multiple Components / Instances,

one System (MCOS, Virtualization) Multitenant Database Containers,


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 instance

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.

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

for production and non-production use cases

– General support for Lenovo FlexNode partitions in context of Lenovo x3950 X6 servers for production and

non-production use cases.

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.

For specific information and constraints see SAP Note 1788665 and notes linked therein.





How to choose a multi-tenancy technology that best fits your

needs?There are several things that customers should consider before determining which

virtualization 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 already bring nice partitioning capabilities “out-of-the-box”

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

– Federation needs: MDC has lower performance penalty than SDA / MCOS and Virtualization. MDC only allows read access.

Database size, scalability and use case requirements – There are several restrictions with respect to size and scenarios for the different Hypervisor products certified for SAP HANA

– Hypervisors currently have a minimum VM / LPAR size (8 cores). MDC allows smaller tenants. MCOD allows smaller footprints (schemas).

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 multitenant 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 requires

specific considerations to find a compromise.


Comparison MCOS/MDC/LPAR/Virtualization

MCOS SAP HANA

multitenant 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 4TB

E.g., Max VMware

vSphere 6.0 size is 4TB

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.

Additional Options for

Landscape Management“SAP Landscape Virtualization Management” (SAP LVM) “SAP Landscape Management” (SAP LaMa)


Additional Options for Landscape Management

Why ??

[Old name]: SAP Landscape Virtualization Management (SAP LVM)

// Our customers thought SAP LVM:

# is just another Virtualization Manager, e.g. vCenter (nope!)

# can only manage a virtualized SAP landscape (nope!)

It is an SAP Landscape Management solution that can manage all types of environments

(physical, virtualized, private cloud, public cloud or hybrid)

[New name]: SAP Landscape Management (SAP LaMa)


SAP Landscape Management (SAP LaMa)Making SAP landscape management easier

SAP Applications

S/4HANA | CRM | ERP | BW | SCM

Operating System and Database

RHEL | Windows | AIX | HANA | DB2

IT Infrastructure

Virtualization | Storage | Network | Server

DEV QAS PRD

On-Premise | Cloud | Hybrid

3rd

Pa

rty T

oo

ls

no

n-S

AP

Ap

ps

SAP Landscape Management SAP Landscape Management is an

automation and orchestration solution

to simplify automate centralize the

management of your SAP landscapes

Simplify landscape management and

standardize SAP operations

Automate repetitive, time-consuming

tasks and orchestrate to your needs

Centralize landscape operations and

gain landscape-wide visibility


SAP Landscape Management 3.0 Managing SAP landscapes powered by SAP HANA

Managing SAP Landscapes powered by SAP HANA

Centralized SAP Landscape

Management and Control

• Landscape-wide visibility with advance

dashboards and landscape visualization

• Mass-operations on landscape with

built-in support for system dependencies

• Visualize disaster recovery relationships

for SAP HANA

• Scheduling engine and template based

execution for operations

• Integration with native tools like SAP

HANA Cockpit and DB Control Center

Automation for Advance

System Operations

• End-to-end automation for system clone,

copy, rename and refresh operations

including post-copy automation

• Accelerate SAP BW to SAP HANA

migration projects via special task lists

• Manage and provision SAP HANA

systems deployed in the cloud (AWS

and OpenStack cloud environments)

• Manage and provision multitenant

database container (MDC) systems

nZDM* Maintenance and System

Replication Support

• End-to-end automation for SAP HANA

system replication setup

• End-to-end automation for SAP HANA

takeover and failback procedures

• Near zero downtime takeover procedure

for planned downtime scenarios

• Near zero downtime maintenance for

SAP HANA primary and secondary sites

(SAP HANA upgrades, OS upgrades or

hardware maintenance)

* Near Zero Downtime (nZDM)


Tools for managing SAP HANA systems and landscapesWhich tool to use, for what..

Native Tools for SAP HANA Database Administration

SAP Landscape Management

Use it for: Near zero downtime for SAP HANA maintenance,

automation for advanced operations and automated failback

procedure

• Central automated landscape management solution

• Runs on SAP NetWeaver AS for Java

SAP Solution Manager

Use it for: End-to-end root cause analysis and unified

alert inbox for entire landscape and for business

process reporting

• Central alerting and monitoring infrastructure

• Runs on SAP NetWeaver AS for ABAP

SAP HANA Cockpit

Use it for: Core administration and detailed monitoring of SAP

HANA databases at both individual and landscape levels

• Core administration of SAP HANA systems

• Web-based HTML5 user interface

• Runs on SAP HANA XS Advanced

Future

Direction


SAP HANA StudioSAP DB Control Center


SAP Landscape ManagementRelease plan

2014 2015 2016 2017


2.0Planned end of

maintenance

Dec-2015

GARamp-up

GA

GAContinuous improvements delivered in 20152.1

3.0

Ramp-up


Try SAP LaMa 3.0 in the cloud

Try SAP LaMa 3.0 in the cloud

with SAP CAL!!

+ Get quick hands-on experience with SAP LaMa 3.0

solution in the cloud (deploy & use within minutes..)

+ Comes with pre-configured demo scenarios and

descriptions to get you started

https://cal.sap.com

Link to SAP CAL FAQ page on SAP

Community Network to help you get started:

http://scn.sap.com/docs/DOC-33673i

Thank youContact information:

Dr. Jan Teichmann

Senior Director

Dietmar-Hopp Allee 16

Walldorf

[email protected]

mailto:[email protected]


© 2017 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


© 2017 SAP SE oder ein SAP-Konzernunternehmen.

Alle Rechte vorbehalten.

Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher Form auch immer, ohne die ausdrückliche schriftliche

Genehmigung durch SAP SE oder ein SAP-Konzernunternehmen nicht gestattet.

SAP und andere in diesem Dokument erwähnte Produkte und Dienstleistungen von SAP sowie die dazugehörigen Logos sind Marken oder eingetragene Marken der

SAP SE (oder von einem SAP-Konzernunternehmen) in Deutschland und verschiedenen anderen Ländern weltweit.

Weitere Hinweise und Informationen zum Markenrecht finden Sie unter http://global.sap.com/corporate-de/legal/copyright/index.epx.

Die von SAP SE oder deren Vertriebsfirmen angebotenen Softwareprodukte können Softwarekomponenten auch anderer Softwarehersteller enthalten.

Produkte können länderspezifische Unterschiede aufweisen.

Die vorliegenden Unterlagen werden von der SAP SE oder einem SAP-Konzernunternehmen bereitgestellt und dienen ausschließlich zu Informationszwecken.

Die SAP SE oder ihre Konzernunternehmen übernehmen keinerlei Haftung oder Gewährleistung für Fehler oder Unvollständigkeiten in dieser Publikation.

Die SAP SE oder ein SAP-Konzernunternehmen steht lediglich für Produkte und Dienstleistungen nach der Maßgabe ein, die in der Vereinbarung über die jeweiligen

Produkte und Dienstleistungen ausdrücklich geregelt ist. Keine der hierin enthaltenen Informationen ist als zusätzliche Garantie zu interpretieren.

Insbesondere sind die SAP SE oder ihre Konzernunternehmen in keiner Weise verpflichtet, in dieser Publikation oder einer zugehörigen Präsentation dargestellte

Geschäftsabläufe zu verfolgen oder hierin wiedergegebene Funktionen zu entwickeln oder zu veröffentlichen. Diese Publikation oder eine zugehörige Präsentation,

die Strategie und etwaige künftige Entwicklungen, Produkte und/oder Plattformen der SAP SE oder ihrer Konzernunternehmen können von der SAP SE oder ihren

Konzernunternehmen jederzeit und ohne Angabe von Gründen unangekündigt geändert werden.

Die in dieser Publikation enthaltenen Informationen stellen keine Zusage, kein Versprechen und keine rechtliche Verpflichtung zur Lieferung von Material, Code oder

Funktionen dar. Sämtliche vorausschauenden Aussagen unterliegen unterschiedlichen Risiken und Unsicherheiten, durch die die tatsächlichen Ergebnisse von den

Erwartungen abweichen können. Die vorausschauenden Aussagen geben die Sicht zu dem Zeitpunkt wieder, zu dem sie getätigt wurden. Dem Leser wird empfohlen,

diesen Aussagen kein übertriebenes Vertrauen zu schenken und sich bei Kaufentscheidungen nicht auf sie zu stützen.

http://global.sap.com/corporate-de/legal/copyright/index.epx

customer sap hana virtualized: new options and a

Documents