What is SAP’s Business Suite on HANA (S4HANA)?

What is SAP’s S4HANA Vision?

Architecture, Sizing, and Capacity Planning Overview

Rick Speyer – Global Marketing for SAP on Cisco

Drew Iacone – Global Sales Strategy for SAP on Cisco

Saroj Mohapatra - Global Technical Strategy for SAP on Cisco

March 4, 2015

2© 2013-2014 Cisco and/or its affiliates. All rights reserved.

Safe Harbor Statement

The content and commentary in this presentation and associated webinar is intended to be accurate and directionally representative of SAP's Best Practices and Product Strategy. There is however a degree of subjectivity in any effort to interpret SAP from a sizing and capacity planning perspective.

Therefore, it is strongly encouraged to request a "HANA Technical Academy" Briefing and Workshop with SAP, Cisco, and your preferred Storage Vendor at the SAP Co-Innovation Lab (COIL) or the SAP Competency Center:

Spend 1-2 Days with true SAP Subject Matter Experts

Latest Product Roadmaps and Solution Planning with SAP and your End-to-End SAP Technology vendors

Hands-on with HANA (Several Technical Scenarios including HA/DR, Hadoop, ILM, and Security Integrations)

Locations: Palo Alto (California, USA), São Paulo (Brazil), Waldorf (Germany), Moscow (Russia), Bangalore (India), Shanghai (China), Singapore, and Tokyo (Japan).


1. What is SAP’s S4HANA Vision and Roadmap?Looking back on 4yrs of Innovation from SAP specifically focusing in on Data Aging and Data Virtualization

Explain why SAP’s S4HANA Vision requires Integrated Infrastructure and HANA via TDI

2. What is the Minimally-Disruptive Upgrade Path to S4HANA?There is a Technical Upgrade phase (Classic version) followed by a Functional Upgrade phase (Simple Version)

3. Cisco’s Architecture Vision and Simple Sizing for S4HANA Run Production, Non-Production, HANA, and Non-HANA workloads together with Logical Isolation – HANA via TDI

There are Hot, Warm, Cold plus Hadoop repositories in the SAP Landscape with Dependency and Adjacency Implications

4. Overview Cisco’s Compete Portfolio of Solutions for SAP and S4HANAShow SAP Experience on Cisco Build and Price portal – Solutions, Sample Configurations, Supporting Documentation

Today’s Agenda


Understanding SAP’s S4HANA Vision and Roadmap


SAP HANA is not a Database… it is the Core!

SAP is #1 in the

ERP ‘Suite’

Space


Why SAP’s S4HANA Vision requires Integrated InfrastructureA Closer Look at the ‘On-Premise’ portion of the S4HANA Architecture Requirements


S4HANA is not just Core… it is ‘Core plus Cloud’

Plan Build – IaaS Migrate Run – Classic

Plan Migrate Run – Simple*

Core plus Cloud enables SaaS-level process integrations – Simple XYZ, SuccessFactors, Ariba, Concur, etc.

The Technical Upgrade Phase…

The Functional Upgrade Phases...

* Leverage Existing On-Premise Cloud or Public Cloud for Promote to Production (SBX, Dev, QAS) *

* Deploy Production On-Premise (Annual Innovation) or via SaaS (Quarterly Innovation) *


A Closer Look at the ‘plus Cloud’ portion of the S4HANA Architecture Requirements

Why SAP’s Vision requires Integrated Infrastructure


A Closer Look• The Minimally Disruptive Upgrade Path from Classic to Simple

(S4HANA)


Understanding the Business Case and Drivers for S4HANAIt is all about enabling the Business with Real-time Visibility, Simplified Process, and Insight from Big Data/IOE


Three Options to generate the Real-time Views

Suite on HANA Sidecars & Accelerators EDW on HANA (BW plus Sidecars)

Mainly Scale-up with 80% of SoH-

classic DBs expected to be under 2TB

1TB of Table Data in HANA-Hot

Mainly Scale-out with 80%

of EDWs expected to be under 8TB

4TB of Table Data in HANA-Hot


Any DBAny DB

The Technical Upgrade Phase – Transactional/Suite Aspects only

Simple Suite

Versions (S4)

HANA In-Memory plus Data Aging optionsAny DB

Classic Netweaver Front-end

New SAP UX (Fiori/Lumira)

Classic Suite

Modules

on

Netweaver

Back-end

One Major OS/DB

Migration (DMO)

One Major

App Migration

(Functional++)

Classic Suite

Modules

on

Netweaver

Back-end

Basic Application

LCM (SUM)

(Technical)


A Closer Look at User Access to SAP – Classic vs Simple


HANA Fully Integrated Database

HANA On-Disk (Warm)*

The Functional Upgrade Phase – Transactional/Suite Aspects Only

HANA In-Memory (Hot)

S4

Module-1

S4

Module-2

S4

Module-3

N+1 S4

Modules

Transactional

with ‘Next Gen

ILM’

Simple DB

Schemas with

Common Tables

Combined Technical and Functional Upgrade Scope

One HANA Instance per Module

* Denotes Limited ‘Data Aging’ Capabilities Today

* SAP Best Practice is still classic archiving (via the ADK) for OLTP/Transactional

One Single Global Instance of HANA for the entire S4 Suite

Transactional – OLTP/OLAP combo


What is the difference between the SAP Suite on HANA

as we know it today and SAP S4HANA?

• The SAP Suite on HANA was just a migration of the SAP Suite from Any DB

to HANA database.

• The SAP S4HANA is a complete new version of SAP Suite, which has been

re-written with streamlined code and simplified data model, totally based on

the new paradigms from SAP HANA.

Real benefits:

Reduced data footprint – highly compressed data, less tables

Higher table throughput – fewer table updates, less locking, faster processing

More Flexible – complexity is reduced as indices and aggregates are removed


What is the objective of S4HANA according to Hasso

All Business Applications are moving back into one single system:

• Complexity: SAP customers have complained for a VERY long time about

constantly growing System Landscape requirements. Any application outside

of ERP/ECC meant new server requirements, new instances, and middleware

connectivity such as SAP PI or non SAP.

• Bringing this back into one system is a relief for users.

• SAP has promised to push quarterly updates and innovations for S4 going

forward.

• Except for B2B connectivity use, PI/XI systems will retire. SAP-to-SAP

internal Integration can be addressed with out PI/XI.

• Simple Finance is already available; Simple Logistics will follow in 2015.

• We are anxiously waiting for SAP to shed more light on the details of what is

coming and when.


With and Without Aggregates and Indices according to Hasso



Reduction in size, dramatically faster:

• The new HANA Database Architecture allows for a massive reduction of

aggregation layers that were required in the past to store interim values.

• Code can also be cleaned up since no data aggregation layers need to be

managed. Designing S4 was an opportunity to finally get rid of old, crusted

structures from ERP.

• SAP did a table clean up. For example the very old Material Master Database

Tables from R/2 times (MARA, …) are finally no longer around, only views on

the data. The result is dramatically higher speeds and a 1:10 reduction in

Data Footprint.

• Imagine - a 1 Terabyte SAP Database is down to 100 GB.


Data Reduction According To Hasso



• No other database anymore - besides HANA

• In the Cloud - or not, customer decides:

• SAP will offer S4 HANA as a full cloud-based option (no IT infrastructure

needed) or as a private cloud (you build and run your own cloud

environment in-house). And then there is a combination as a hybrid

cloud.

• Ease of consumption: Perhaps that’s an old dream come true for SAP users

who criticized and battled SAP for its rigid UI for a very long time. Fiori -

meanwhile free of charge - is a welcome new start for Information Workers,

a lot cleaner and much more in line with today’s standards of consuming

information.


Future Of S4HANA


Near-line Storage (NLS/Cold)

HANA Fully Integrated Database

HANA On-Disk (Warm)*

A Closer Look at the End-to-End Application Architecture for S4HANA


S4

Module-1

S4

Module-2

S4

Module-3

N+1 S4

Modules

* Denotes Limited ‘Data Aging’ Capabilities Today

* SAP Best Practice is still classic archiving (via the ADK) for OLTP/Transactional

Consolidated Scale-up Deployment (still under 2-3TB)

Start Small & Stay Small via Data Aging

HANA Enterprise Data Warehouse


S4

Sidecars

N+1 S4

Sidecars

SAP BW on HANA(Corporate Record)

Trigger-based

(as needed)

Native DTPs/ETLs

(‘Suite-level)

(required)

Future-Proofed Scale-out Deployment (Scale Fast)

Leverage Data Virtualization & Data Aging

Transactional – OLTP/OLAP combo Analytics - OLAP


SAP first introduced their EDW Concept and Data Virtualization Strategy in 2011 – 4yrs ago = Not New!

Smart Data Access and Federated QueriesDynamic ETL/DTP vs Batch


Today - A Closer Look at SAP’s Data Virtualization StrategyThis is the EDW (BW with Sidecars) plus Smart Data Access (SDA) plus Federated Queries plus Native/Traditional ETL

*Rules - SAP owns the definition of and specifications for “HANA, “Production”, “Appliance”, and “Tailored Data Center Integration” or TDI*

Smart Data Access via HANA Studio Modeler(Create Custom & Query Views from SAP Reuse Views including Non-HANA ‘Virtual Tables’)

Federated / Intelligent Queries EngineDynamically split and execute the Queries for Optimal performance with and without Data Movement/ETL


Today - A Closer Look at Data Aging OptionsHANA ‘In-Memory’ (Hot) vs HANA ‘On-Disk’ (Warm) vs Cold (Near-line Storage, Archiving)

Next Generation ILM is for Transactional - Suite on HANA (SoH)(One Client-side Connection | One DB Backup – this is one logical DB vs two)

NLS is for Analytics - BW on HANA(One Client-side Connection | Two DB Backups)


A Closer Look• Cisco’s Vision for SAP S4HANA – Run Production, Non-Production,

HANA, and Non-HANA together with Logical Isolation via TDI

• Sizing for HANA and Non-HANA Workloads


SAP’s S4HANA Vision Requires Integrated Infrastructure…… Run SAP on UCS Integrated Infrastructure with HANA via TDI

SAP Production (Analytics on HANA)

• 4+ Node Scale-out Cluster

SAP Production (Suite on HANA)

• 2+ Node Scale-up HA Cluster

SAP Production (Non-HANA)

• SAP and SAP Related Workloads

Non-SAP Related Workloads

• VDI, SharePoint, Exchange, etc.

Storage Pools for HANA Persistence

Run Production, Non-Production, HANA, and Non-HANA workloads together with Logical Isolation

Aggregation and Out-of-Band Management for SAP

(Cisco Nexus and UCS Fabric*)

Hadoop – 8 Node Cluster

SAP Non-Production Landscapes

Shared Storage

Non-HANA


SAP on UCS Integrated InfrastructureCisco Validated Designs (CVDs) with NetApp (FlexPod), EMC (vBlock/VCE), and IBM (VersaStack)

• Tested for Hardware Interoperability• Compute and Network Fabric from Cisco

• Storage from NetApp, EMC, IBM, and soon Nimble

• Hypervisors from VMware, Microsoft, and Red Hat

• Forward and Backward compatibility promise

• Detailed Documentation and Design Guides• Foundation CVDs (IaaS level) for FlexPod, VSPEX, VersaStack

• Extension CVDs (IaaS level) for Advanced Security and Secure Enclaves

• Extension CVDs (IaaS level) for Disaster Recovery or ‘Workload Mobility’

• Additional SAP Documentation and Testing• Extension CVDs (PaaS level) for SAP HANA via TDI (replacing Whitepapers)

• Additional Documentation: Best Practices, Technical Whitepapers, and ‘How

to’ implement Guides Storage, VMWare, etc… on UCS

• Reference Configurations (Small, Medium, Large) for Simple Sizing

• End-to-End Solution Support from Cisco!• Compute, Network, Third Party Storage

• Bare Metal OS, Through the Hypervisor, Into the Guest OS

SAP’s ‘S4HANA’ Vision runs Best

on UCS Integrated Infrastructure

Cisco is #1 in WW

Blade PerformanceOur 95+ WW Application Benchmark

Results are 6+ at a time every time

Intel introduces a new CPU

Equals #1 in SAPS‘SAPS’ is SAP’s proprietary

Benchmark Metric


Cisco is Ranked #1 in Integrated InfrastructureBy Gartner and in Market Traction (IDC) with THOUSANDS of successful deployments and satisfied customers


Cisco offers a Complete Portfolio for HANA – Appliance & TDI Scale-up to 8-socket before you Scale-out | Analytics at 2+TB | Transactional/Suite (SoH) at 6TB

C460 M4

(2-4s Appliance Workhorse. 80+% SoH)

B200 M3/M4*

(2s TDI Workhorse on Intel E5 – 80+% SoH)

B460 M4

(4s TDI Workhorse for SoH and Scale-out)

C880 M4

(8s Analytics Workhorse)

(~10% of SoH-classic)

Then Scale-out!

Scale-up80+% of SoH-classic

fits into 2-4 socket

Compute Nodes

Analytics80+% fits into 2-7TB

Clusters (1-8 Nodes)

* NEW! Mainly for HANA via TDI, Cisco also certified the

B260M4 (2s x E7) and the C220/C240M4 (2s x E5)

Single-Node EDW

Architecture only

advised for low/slow

growth scenarios


Understanding Data Migration and Sizing - HANA

Scale-up | Single-Node

Today (256GB - 6TB Nodes)

OLAP/OLTP ComboScale up at 256+GB/Socket*

Transactional/SoH OnlyScale-up at 512+GB/Socket*

Scale-out | HANA Cluster

Today (512GB, 1+TB, or 2+TB Nodes)*

Analytics to ~16 active nodes**(6-10 active nodes per TDI Storage Array)

Suite on Scale-out (3 x 6TB)(Better Option vs NUMA issues at >8-socket)

Compression Factors

~4x for Transactional or Suite on HANA

~7x for Analytics or EDW/BW on HANA

Results in Estimated Table Data Only(HANA Node Size is Table Data x ~2)

*Contact SAP/See SAP Note 1903576: Max-out the Node Memory Option (Ivy Bridge v2)*

**See SAP Note 1702409: Why SAP recommends 3+ Nodes from the Start for BW on HANA**


Understanding Data Migration and Sizing - HANA

Anatomy of a HANA NodeHANA requires a 20% Buffer for Overhead plus

additional RAM for other DB activity

~50% available for Compressed Customer

Table Data (ie: Table Data x 2 = Node Size)


Understanding Memory & Persistence in HANA


Understanding Memory & Persistence for EDW/BW on HANA

Three (3+) Active Nodes from the Start with all Nodes configured

identically on the same Network/SAN

Standby is HOT without own persistence(Multiple Failover/Standby Nodes are allowed in Cluster)

Scale-out failover in ~4 minutes (best case)See SAP Note 1702409


Near-line Storage (NLS/Cold)HANA On-Disk (Warm)

A Closer Look at the COMPUTE requirements for S4HANA

2-6TB 2-6TB HA 1+TB 1+TB 1+TB N+1

128-768GB 128-768GB HA 128-768GB 128-768GB HA

256-768GB 256-768GB 256-768GB 256-768GB N+1 Cluster Global Spare

Classic Netweaver (Front-end,

Back-end, PO, SoH-classic, etc.) Any DBsNew SAP Presentation

(Fiori, Lumira, XS, etc.)

Add-ons/Bolt-ons (GRC, BPC,

SLT, BOBJ, 3rd Party, etc.)

Unified Fabric12+x 10G FCoE Northbound

Plus 10G FCoE East/West

10G FCoE to HANA VMs

Default UCS VM Density

4 VMs ~10G FCoE

8 VMs ~5G FCoE


How much HANA Memory does your

SAP Module Require?

Estimated Source

DB (3yrs)

Compression

Factor (Net**)

Conservative

(HANA @ Table Data x 2)

Optimistic


Estimated Warm/Cold DB

(50% compression)

Data Aging Assumption: No Data Aging. All Hot 30% Hot, 70% Warm/Cold Oldest 70% to Disk

Uncompressed Transactional DB to 'Suite on HANA'

1TB DB growing at 10% 1,300 4 650 195 455

2TB DB growing at 10% 2,600 4 1,300 390 910

3TB DB growing at 10% 3,900 4 1,950 585 1,365

5TB DB growing at 10% 6,500 4 3,250 975 2,275

7.5TB DB growing at 10% 9,750 4 4,875 1,463 3,413

10TB DB growing at 10% 13,000 4 6,500 1,950 4,550 Note that most SoH requirements under 1.5TB can fit into Intel E5 Blades (20+% lower TCO, 50% less space vs E7 Blades) OpenText is typically 3-4x compression

Fits into 2-socket Intel E5 Haswell Blade

Showing Optimistic HOT via ADK - not Warm/NLS

*Sizing for HANA 'In-Memory' (HOT)* Sizing for HOT with Warm/Cold

Fits into 4-socket Single-Node (no Scale-out) Optimize into a 3+ Node HANA Scale-out Cluster

A Closer Look at the TRANSACTIONAL (Suite on HANA) SIZING requirements

Process Steps – Transactional (Suite on HANA) or OLTP

1. Uncompressed Source DB Size including a 3yr Growth factor

2. Divide by SAP HANA Compression Factor ~4x = Estimated Table Data

3. Multiply by SAP HANA Overhead Factor ~2x = Estimated Node Size

4. Include or Exclude Data Aging Assumption ~70% not HOT

5. Factor in Consolidated Simple/S4 Sizing at +50% compression for HOT

6. If Step 3 or 5 result is larger than 1TB, then vHANA is not an option


A Closer Look at the ANALYTICS (EDW-BW on HANA) SIZING requirements

Process Steps – Analytics (EDW-BW on HANA) or OLAP1. Uncompressed Source DB Size including a 3yr Growth factor

2. Divide by SAP HANA Compression Factor ~7x = Estimated Table Data

3. Multiply by SAP HANA Overhead Factor ~2x = Estimated Node Size

4. Include or Exclude Data Aging Assumption ~70% not HOT

- If you are growing at 25% YTY, then it is realistically 50-75% of the EDW that is HOT

5. If Step 3 result is larger than 1TB, then vHANA is not an option

- Scale-out Clustering is targeted for a 1.5+TB node size, vHANA not currently supported

How much HANA Memory does your

SAP Module Require?

Estimated Source

DB (3yrs)

Compression

Factor (Net**)

Conservative


Optimistic


Estimated Warm/Cold DB

(50% compression)

Data Aging Assumption: No Data Aging. All Hot 30% Hot, 70% Warm/Cold Oldest 70% to Disk

Uncompressed Analytic DB to 'BW/EDW on HANA'

3TB DB growing at 25% 5,250 7 1,500 450 1,838

5TB DB growing at 25% 8,750 7 2,500 750 3,063

7.5TB DB growing at 25% 13,125 7 3,750 1,125 4,594

10TB DB growing at 25% 17,500 7 5,000 1,500 6,125

12.5TB DB growing at 25% 21,875 7 6,250 1,875 7,656

15TB DB growing at 25% 26,250 7 7,500 2,250 9,188

20TB DB growing at 25% 35,000 7 10,000 3,000 12,250 Note that most TDI Certified Arrays can only support 8-10 Active Nodes Sybase IQ (or HANA On-Disk) is typically 3-4x compression

Fits into 2-socket Intel E5 Haswell Blade

Showing Optimistic HOT into Warm/NLS - not ADK

*Sizing for HANA 'In-Memory' (HOT)* Sizing for HOT with Warm/Cold

Fits into 4-socket Single-Node (no Scale-out) Optimize into a 3+ Node HANA Scale-out Cluster


Memory-based Sizing for Normal (5% for Hypervisor, 35% for Peak) 128GB 256GB 512GB 768GB

20GB RAM per VM with Swap 4.0 7.9 15.8 23.7





* Oversubscription of the avai lable Server memory (RAM) in Production SAP deployments i s not a Best Practice and should be avoided

SAPS-based Sizing for Normal (10% for Hypervisor, 35% for Peak) 30k SAPs 40K SAPS 60k SAPS 80k SAPS

2,500 SAPS to a VM 7.0 9.4 14.0 18.7

5,000 SAPS to a VM 3.5 4.7 7.0 9.4

7,500 SAPS to a VM 2.3 3.1 4.7 6.2

10,000 SAPS to a VM 1.8 2.3 3.5 4.7

12,500 SAPS to a VM 1.4 1.9 2.8 3.7

15,000 SAPS to a VM 1.2 1.6 2.3 3.1

* Use Normal Usage Assumptions to determine SAPS-based s izing not Peak Usage. Best Practice i s to reserve 35% for Peak usage

Estimated VM Density per Node. UCS brings 40+GB/s to a Blade with QoS (active/active, non-blocking)

Estimated VM Density per Node. UCS brings 40+GB/s to a Blade with QoS (active/active, non-blocking)

Memory available in UCS Blade

Maximum SAPS available in UCS Blade

A Closer Look at the VIRTUALIZED SAP SIZING requirements

Process Steps – SAP into a Virtualized Environment (includes vHANA)1. Determine the Memory Reservation (with swap) for your Typical App/OS Workload

2. Capture the SAPS requirements for each of your main SAP (non-HANA) Workloads

3. Most Production Deployments will have under 8 VMs per Active Node (RAM and vCPU are usually the

gating factor in Virtualized SAP deployments – not raw SAPS available per Node)

4. Larger Workloads (by SAPS and/or RAM) will have 1-2 VMs per Active Node (ie: vHANA)

5. Select a Common Node Size (Total SAPS and RAM) for your VM Cluster

- Rather than buying nodes with vastly different raw SAPS and RAM capabilities, deploy EQUALLY

configured nodes as it allows for Global Sparing and easier redistribution of VMs

OverheadBare Metal Nodes have been

reduced by these Amounts in the VM

Density per Node figures shown

Hypervisors

RAM is 5% while SAPS is 10%

Normal vs Peak

35% of Available Resources are

reserved for Peak Usage

B200 M413-82k SAPS per 2-socket Node

Based in Intel E5 Haswell CPUs

Available RAM per Node

(based on 24 DIMM slots)

768GB via 32GB DIMMs

1.5TB via 64GB DIMMs


Why run SAP on Cisco UCS

Cisco Offers a Complete Portfolio for SAP HANA

The SAP Experience Page on Cisco’s Build & Price Portal - Everything for S4HANA


1. Risk Mitigated, Most Easily Deployed & Supported Option

2. Cisco is a leader in HANA via TDI - Investment Protection

3. Best-of-Breed Products plus Best-in-Suite Solutions

4. Great Alignment and Shared Vision with SAP

Why run SAP on UCS Integrated Infrastructure?

Cisco enables your Business, powered by SAP, to

Run at the Speed of the Network!


Cisco offers a Complete Portfolio for HANA – Appliance & TDI Scale-up to 8-socket before you Scale-out | Analytics at 2+TB | Transactional/Suite (SoH) at 6TB

C460 M4

(2-4s Appliance Workhorse. 80+% SoH)

B200 M3/M4*

(2s TDI Workhorse on Intel E5 – 80+% SoH)

B460 M4

(4s TDI Workhorse for SoH and Scale-out)

C880 M4

(8s Analytics Workhorse)

(~10% of SoH-classic)

Then Scale-out!

Scale-up80+% of SoH-classic

fits into 2-4 socket

Compute Nodes

Analytics80+% fits into 2-7TB

Clusters (1-8 Nodes)

* NEW! Mainly for HANA via TDI, Cisco also certified the

B260M4 (2s x E7) and the C220/C240M4 (2s x E5)

Single-Node EDW

Architecture only

advised for low/slow

growth scenarios


SAP Experience on Cisco Build & Price

One-Stop Shop for the ‘How to’, ‘How Much’, and ‘Who Else’ Questions


www.cisco.com/go/sap

• Main Landing Page for SAP on UCS

• Links to SAP page on Cisco Build & Price

buildprice.cisco.com (click on SAP)

• Featured Promotions, Certified HANA Configurations, Real-World Reference Configurations (including Third Party Storage)

• Full listing of the Customer Success Stories for SAP on UCS Integrated Infrastructure (on FlexPod, on vBlock, etc…).

• Aggregated and Organized information about the Cisco Validated Designs (CVDs) for SAP

www.cisco.com/go/ucs

• More information on Cisco UCS

http://www.cisco.com/go/sap

http://www.cisco.com/go/ucs

Thank you.