sap hana on planning guide ibm power systems & ibm system … · 2020. 10. 28. · sap hana on ibm...

SAP HANA on IBM Power Systems & IBM System Storage

IBM Deutschland Research & Development GmbH Created on July 8, 2014 – Version 0.0

Last modified on October 21, 2020 – Version 5.0 © Copyright IBM Corporation, 2020

Planning Guide

2

IBM Systems Solution for SAP HANA on POWER and IBM System Storage © Copyright IBM Corporation, 2020

Edition Notice and Version Information © Copyright IBM Corporation 2020. All Rights Reserved. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. All trademarks or registered trademarks mentioned herein are the property of their respective holders. IBM Corporation Systems and Technology Group Route 100 Somers, NY 10589 Edition Notice: this is version 5.0 of this document. Focus: SAP HANA Scale-up and Scale-out solutions Target:

- SAP HANA 2

- SAP HANA Platform Edition – SPS11 and above

- SAP HANA, version for IBM Power Systems architecture SPS 09 or SPS 10

Doc Version Changes 1.2 – 1.8 Changes documented up to version 2.1

1.9 – 2.5 Changes documented up to version 3.1

3.0 – 3.3 Changes documented up to version 4

4.0 – 4.2 Changes documented up to version 4.3

4.3 – 4.5 Changes documented up to version 4.6 4.6 (Nov/06/2019

Add additional Information about Migration (SAP Note updates) Re-emphasize relaxations based on SAP’s TDI 5 approach. LPM Mand SPLPAR. Full SMT 8 support for all core counts.

4.73 (July/08/2020

Adding “ServiceReport” to Support chapter (RAS setting validation + correction in Linux). New Sizing and Mapping chapter. Easier TDI5 planning workflow. First updates for: SPLPAR, vPMEM, vNIC exploitation. HWCCT Sunset.

5.0 New Layout, and SPLPAR

Note: Before using this information and the product it supports, be sure to read the general information under ”Copyrights and Trademarks” on page 55 as well as “Disclaimer and Special Notices” on page 56.

3


Preface Running SAP HANA on IBM Power Systems offers customers a consistent platform for their HANA-based and traditional applications, best-in-class performance, resilience for critical workloads, and most flexible infrastructure. Existing IT assets - servers, storage, as well as skills and operation procedures - can easily be (re-)used leveraging the SAP HANA Tailored Data Center (TDI) concept to its maximum.

About This Document This document is intended for architects and specialists planning a SAP HANA® on POWER® deployment. It describes the design considerations for hardware, networking, and software components of the SAP HANA on POWER solution stack. This guide does not replace existing SAP HANA documentation and sizing guides. It serves as a supplement to the existing SAP HANA documentation and SAP Sizing methods to provide specific guidance on how to meet all SAP requirements when running SAP HANA on IBM Power Systems™, IBM System Storage®, IBM PowerVM®, and Linux Operating System. It describes the requirements for LAN and external SAN topologies. For special topics, own documentation is maintained and referenced at the end. IBM processes and contacts are introduced which help to obtain a valid hardware mapping based on SAP sizing for SAP HANA.

IBM employees can access the ISICC SAP HANA on Power Systems Community (IBM only) for up-to-date materials complementary to this guide. The most recent document version can be downloaded from IBM TechDocs: http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102502 Feel free to provide feedback and change requests for this document via email to: [email protected].

https://w3-connections.ibm.com/communities/service/html/communitystart?communityUuid=e4d11bf2-8632-4a00-ba19-d767a98a2cf3http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102502

4


Table of Contents Edition Notice and Version Information .................................................................................................. 2

Preface ..................................................................................................................................................... 3

About This Document .............................................................................................................................. 3

Introduction ............................................................................................................................................. 8

The Planning Process ............................................................................................................................... 9

SAP Sizing for SAP HANA on POWER .....................................................................................................10

Introduction .......................................................................................................................................11

HANA Memory Sizing .....................................................................................................................11

HANA CPU Sizing ............................................................................................................................11

SAP HANA Sizing Types: Brownfield or Greenfield ........................................................................11

SAP HANA Sizing Cases: OLAP vs OLTP ..........................................................................................12

Summary SAP Sizing options .........................................................................................................12

SAP References and Notes for Sizing .............................................................................................13

Sizing Report Best Practices ...............................................................................................................13

Growth and Timeline of your Database ........................................................................................13

Brownfield OLAP Sizing (BW) .........................................................................................................13

Brownfield S/4 or Suite on HANA Sizing (with Sizing Report) .......................................................16

Greenfield S/4 or Suite on HANA Sizing (with HANA Quicksizer) ..................................................18

Greenfield BW Sizing with the SAP Quickiszer ..............................................................................21

Sizing related technologies ................................................................................................................22

SAP HANA Data Temperatures reduce the sizing result of CPU and Memory ..............................22

Native Storage Extension (NSE) Warm Store Configuration Rules ................................................23

Quick Reference: Get SAP HANA Sizing from SAP .............................................................................24

Links, References and Tools ...............................................................................................................24

Decide on Power and SAP features implemented to reduce Hardware or accelerate your workload 25

SAP HANA startup acceleration .........................................................................................................25

SAP HANA in Shared CPU Pools .........................................................................................................26

Introduction into Shared Processor Pools .....................................................................................26

SAP HANA Performance Observations ..........................................................................................27

Get to the right PowerVM SPLPAR settings for an SAP HANA LPAR .............................................28

Monitoring SAP HANA in Shared Pools .........................................................................................29

Eco System and Landscape aspects .......................................................................................................29

Mapping SAP Sizing Output to IBM Power Systems Configurations .....................................................29

SAP HANA deployment options and IBM Power Server ................................................................29

Quick Reference: Find valid IBM Power Systems options .............................................................33

Links, References and Tools ...........................................................................................................33

Mapping SAP I/O KPIs to a SAN Storage Design ................................................................................34

Planning Considerations for a valid Storage Type .........................................................................34

Background: SAP HANA filesystems and SAN storage...................................................................35

Additional Storage Sizing Considerations for Backup, DR and HA ................................................36

Additional Planning Considerations for SAP HANA scale-out installations ...................................36

5


Quick Reference: Find valid Storage Subsystem ...........................................................................37


SAP HANA Connectivity .....................................................................................................................37

Planning Considerations for Virtual IPs .........................................................................................38

Planning Considerations for VIOS I/O virtualization ......................................................................38

Planning Considerations: Single-Host SAP HANA (scale-up) .........................................................39

Planning Considerations Multi-Host SAP HANA (scale-out) ..........................................................40

Quick Reference: I/O Adapter Definition ......................................................................................41


Operating System ..................................................................................................................................41

Software and Operating System ....................................................................................................41

HWCCT validation (deprecated) ........................................................................................................41

SLES 11 considerations ......................................................................................................................41

SLES 12 and SLES 15 considerations ..................................................................................................42

RHEL considerations ..........................................................................................................................42

Quick Reference: OS Planning ...........................................................................................................42


File System .............................................................................................................................................43

Planning Considerations for XFS with Multi-pathing .........................................................................43

Planning Considerations for IBM Spectrum Scale .............................................................................43

Quick Reference: File System Definition ...........................................................................................43


Additional Considerations for Large OLTP Installations ........................................................................44

SAP HANA Software ...............................................................................................................................44

SAP HANA tuning ...............................................................................................................................44

How to check the PAM ......................................................................................................................44

Scale-out deployments ......................................................................................................................44

Quick Reference: SAP HANA Software. .............................................................................................44

Links, References, and Tools ..............................................................................................................44

Verification.............................................................................................................................................45

Support and Services .............................................................................................................................45

Getting help and information from the World Wide Web for IBM products ...................................45

Getting help and information for IBM Server and Storage mapping ................................................45

Standard Support Flow ......................................................................................................................45

IBM Services, Support and Operation offerings for SAP HANA on POWER ......................................46

Migration Support and Services ........................................................................................................46

Planning and Installation ...................................................................................................................47

IBM Total Solution Support ..............................................................................................................47

6


Planning for IBM Total Solution Support .......................................................................................48

ServiceReport Tool .........................................................................................................................48

Links, References and Tools: ..........................................................................................................49

Referenced documents ..........................................................................................................................49

Copyrights and Trademarks ...................................................................................................................54

Disclaimer and Special Notices ..............................................................................................................54

Copyrights and Trademarks ...................................................................................................................55

Disclaimer and Special Notices ..............................................................................................................56

COPYRIGHT LICENSE: .............................................................................................................................57

Figures Figure 1 SAP HANA on IBM Power Servers Planning Process.................................................................. 9

Figure 2: Brownfield HANA Memory Sizing ...........................................................................................11

Figure 3 Start the sizing report ..............................................................................................................13

Figure 4 general input parameters BW Sizing Report ...........................................................................14

Figure 5 BW Sizing report precision .......................................................................................................14

Figure 6 Customized Memory Configuration ........................................................................................14

Figure 7 Sample BW sizing report output ..............................................................................................15

Figure 8 CPU requirement Class M caused by Data load peaks ............................................................16

Figure 9 Start the S4/Business Suite Sizing Report ................................................................................16

Figure 10 Sample ERP Sizing Report output ..........................................................................................17

Figure 11 CPU consumption classic DB vs HANA for S4 ........................................................................17

Figure 12 SAP HANA Quicksizer Versions ..............................................................................................18

Figure 13 Create Quicksizer Project.......................................................................................................18

Figure 14 Quicksizer Protfolio - Select SAP Solution(s) .........................................................................19

Figure 15 Sample sizing Sales and Services ...........................................................................................20

Figure 16 Sample Quicksizer input for Sales and Services ....................................................................20

Figure 17 Sample Sales and Service SAPS ..............................................................................................20

Figure 18Sample Sales and Service Memory .........................................................................................20

Figure 19 Sample Sales and Service Growth output .............................................................................20

Figure 20 Select the solution to be sized ...............................................................................................21

Figure 21 Size the Appserver Tier by number of users ..........................................................................22

Figure 22 Impact of objects upload .......................................................................................................22

Figure 23 Advanced Data Store .............................................................................................................22

Figure 24 Quick Reference: "Get SAP HANA Sizing from SAP" ..............................................................24

Figure 25 Typical Example of Workload behavior in Shared Processor LPAR vs. Dedicated LPAR .......27

Figure 26 NMON LPAR utilization profiles (CPU user + system) of independent..................................27

Figure 27 PowerVM LPAR types ............................................................................................................30

Figure 28 SAP HANA Category and Features in eConfig ........................................................................31

Figure 29 Quick Reference: Mapping SAP Sizing Output to IBM Power Systems .................................33

Figure 30 Quick Reference: Find valid Storage Subsystem ...................................................................37

Figure 31 Standard Support ownership of SAP HANA and Hardware Stack .........................................45

Figure 32 Support Flow for HANA on Power Solution Stack .................................................................46

file://///Users/katharinaprobst/Box/ISICC%20Technical%20Enablement/Whitepapers/SAP%20HANA%20on%20Power%20Publications/Techdocs/Planning_Guide/SAP_HANA_on_Power-Planning_5.docx%23_Toc54169251

7


Figure 33 IBM Services for SAP HANA on POWER environments .........................................................48

Tables Table 1. Minimum Single-Host SAP HANA I/O connectivity for production (floor configuration as

required by SAP) ....................................................................................................................................39

Table 2. Minimum Multi-Host SAP HANA I/O connectivity per Server (floor configuration as required

by SAP) ...................................................................................................................................................40

8


Introduction SAP HANA comprises several functional modules whose core is the SAP in-memory database. These are deployed on top of a hardware and software stack, which should be planned according to this Planning Guide. Initially, SAP supported only the appliance delivery method for HANA in which certified hardware partners offer a HANA appliance. SAP HANA TDI (Tailored Data Center) opened the appliance deployment model to provide customers with more flexibility and choices. Customers can choose the matching IBM Power Server model - along with the best matching storage components from a large selection of suitable TDI-certified hardware. They may reuse existing hardware while keeping the operational processes for these. This possibility – or alternatively purchase of incremental special priced HANA Power Systems - significantly lowers the costs and allows for easier integration of SAP HANA based solutions in a customer data center. During introduction of SAP HANA or the transition of older solutions to e.g. S4/HANA the available POWER capacity can be easily be re-allocated to the growing HANA-driven workloads or installed on a partition using available capacity or Capacity Upgrade on Demand resources. The same applies, if customers transition AIX/IBM I environments to new Linux on Power platforms. SAP HANA on IBM Power Server has been introduced with TDI Phase 4 in 2015. Since then, the SAP solution portfolio of new (S/4HANA, BW/HANA), as well as many traditional Business Suite applications have become available. IBM Power Systems have been integral part of the SAP HANA 2.0 announcement in 2016, including all the new technology features coming with this new DB version. In September 2017 SAP SE announced TDI Phase 5. The most significant impact on platforms is the switch from rigid Core to Memory ratios (still documented as “reference configuration” by SAP) to a SAPS based sizing derived from the data footprint of HANA and targeted workload. Basically, this allows Power Systems to become more efficiently from a TCO aspect the more intensively sharing ad virtualization technologies are used. In 2019 SAP SE in collaboration with IBM supports now also the exploitation of Shared Pool LPARs, Virtual Persistent Memory and other acceleration and sharing technologies outlined later.

9


The Planning Process To give an overview of this documentation Figure 1 describes the structure of this paper:

Figure 1 SAP HANA on IBM Power Servers Planning Process

The orange part represents the initial SAP owned sizing process as described in chapter “Error! Reference source not found.”, which delivers information on the SAP HANA sizing methodologies and tools including Best Practices on creating reports in an iterative process

Eco-System and SAP Landscape planning

Identify and Layout Storage and Server System(s) configurations

Validate Configuration

Execute the SAP workload sizing (TDIv5)

Complete SAP HANA Quicksizer process

Apply SAP tools versus existing DB

Apply recommended Best Practices to optimize the Server utilization

OS System deployment

Start with the SAPS and Data-Footprint the Storage and Server mapping

HANA Installation

Refine your business needs based on available technologies of IBM and SAP

Determine Connectivity requirements and derive adapter requirements

SAP Sizing

Hardware and LPAR Mapping

Determine HANA LPAR size and IBM Power server model

10


matching best the actual business needs. Further, it helps to identify the appropriate planning resources provided by SAP. Since 2018, the black and white steps became important to ensure to meet the level of resiliency and performance while reducing the SAP HANA LPAR footprint. The blue parts refer to the IBM specific SAP HANA on POWER and IBM System Storage hardware mapping and layout steps. The green parts represent the Operating System (OS) and SAP HANA software setup described in chapter “Software and Operating System”. The grey box describes the validation. While before TDI5 there was a mandatory verification step this is now optional. Warnings and errors thrown by HWCCT and HCoT are indicators but not necessarily issues. In the meantime, the field has advanced validation tools to ensure a good start experience. Support channels, IBM service offering details and contacts are summarized in chapter “Support and Services”. IBM provides additional guides such as an Advanced Operation Guide, High Availability, IO Configurations and acceleration options etc. on SAP HANA on IBM Power Systems and IBM System Storage - Guides.

SAP Sizing for SAP HANA on POWER

SAP Sizing is a building block to translate SAP business requirements into physical and/or logical hardware. As a result of the sizing process, the HANA “sizing estimate” specifies vendor and platform independent SAP HANA system requirements. The SAP Sizing is an iterative process. Iterative means, that, after getting the first sizing result, more iterations of sizing, with corrected sizing input will improve the accuracy to the benefit of resource savings. What a SAP HANA sizing includes:

• The HANA DB Sizing process covers only the HANA database. • A HANA DB sizing result includes the memory, SAPS and disk capacity for a fully

dedicated deployment. • Platform in depended methodology

What a SAP HANA sizing does not include:

• It neither includes landscape (app-servers, pre-PROD stages), nor resiliency, nor sharing or virtualization aspects. This will be covered later.

• The mapping to an LPAR and/or Server

• IBM Power and Spectrum Storage specific

http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102502http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102502

11


Introduction

The following chapters provide an entry point to get a basic understanding of SAP Memory and CPU sizing in conjunction with different sizing types and workloads.

HANA Memory Sizing

System sizing for SAP HANA and its configuration is dominated by the physical memory demand of the HANA instance, respectively the amount of “hot” business data to be maintained in memory versus warm or cold data which remain on disk or other sources. Putting an iterative sizing approach followed by a customer specific landscape hardware mapping can hence reduce the HANA footprint dramatically. As a first, very rough starting point (followed by an iterative sizing approach), the compressed HANA data in-memory footprint is 1/4th of the uncompressed source business data. For internal processing and temporary work area a HANA system requires the same amount of physical memory, resulting in an estimated physical memory amount of ½ of uncompressed source SAP database size. With recent SAP and IBM innovations, in special Native Storage Extensions and the TDIv5 Workload sizing and the experiences resulting in Best Practices SAP and IBM provide as a Service the memory footprint must be reduced to the actual needs what is relevant for IaaS as well as on Premise deployments to save cost.

Figure 2: Brownfield HANA Memory Sizing

HANA CPU Sizing

Before the Tailored Data Integration Phase 5 a workload independent ratio between Cores and Memory was used anticipating constant worst case workloads. With the introduction of TDI Phase 5, HANA CPU sizing is customer workload-driven. To further reduce the footprint Shared Pool LPARs, NSE and Services are highly recommended to reduce cost.

SAP HANA Sizing Types: Brownfield or Greenfield

The first step in a sizing is to determine the right sizing methodology – Greenfield or Brownfield. In general, a Brownfield sizing is done based on an existing SAP installation on HANA or any DB (e.g. DB2, Oracle, …). A Brownfield sizing is always preferred as the sizing result is more accurate based on analyzing the existing system. This method applies to the following scenarios:

• plan a hardware upgrade

Source DB

LPAR

Work Area

Main Area

/hana/data /hana/log

https://www.sap.com/documents/2017/09/e6519450-d47c-0010-82c7-eda71af511fa.html

12


• change or migration of an existing HANA Instance. • migration from ANY DB to SAP HANA.

A Greenfield sizing is only to be used when having no SAP instance based on Any DB or HANA to collect data from. The sizing input is a quantity structure, based on a bundle of assumptions, or workload statistics.

Attention! Re-sizing any existing SAP System by a Greenfield approach is not allowed!

SAP HANA Sizing Cases: OLAP vs OLTP

Due to the different characteristics between OLAP and OLTP SAP has different sizing toolls. Typical OLTP Solutions are: ERP, SRM, CRM, SCM, EWM, Banking Services, S/4, Solution Manager, SAP Gateway Typical OLAP Solutions are: BW, CAR, BW/4, BO

Summary SAP Sizing options

Combining Green-/Brownfield and OLAP/OLTP, one of the following four scenarios apply.

Greenfield Sizing (former named Initial Sizing)

• New SAP workload and/or customer

Tools:

• SAP Quicksizer • SAP Sizing Guidelines • Sizing by Consultants/Customer/RFP

Brownfield Sizing (former named Migration or Upgrade Sizing)

1. Workload already on SAP, using Any DB 2. Migrate from Any DB to HANA DB 3. Upgrade an existing HANA System

Tools: • BW/4 Sizing Report • S/4 Sizing Report • Rules of thumb

Rule of Thumbs

Brownfield OLAP BW Sizing with Sizing Report (see SAP Note 2296290)

Brownfield OLTP ABAP on HANA Sizing Report S/4, SoH (see SAP Note 1872170)

13


SAP References and Notes for Sizing

The Sizing decision Tree, provided by SAP, is a perfect starting point to get started on SAP HANA Sizing: https://www.sap.com/about/benchmark/sizing/decision-tree.html?pdf-asset=aaa93b78-8f7c-0010-82c7-eda71af511fa&page=1

Sizing Report Best Practices

The next chapters will focus on how to feed the sizing tools correctly to retrieve a valid result. At the end mandatory SAP Notes and how to retrieve assistance are listed.

Growth and Timeline of your Database

Independ of the sizing type, a data timeline and growth per year factor must be determined as input to the Sizing Repots and the Quicksizer.

Note: IBM recommends using a timeline of 3 years and a minimum growth rate of 10%, per year.

Brownfield OLAP Sizing (BW)

Customers with existing SAP Business Warehouse implementations, now migrating to SAP HANA or having a SAP HANA to be upgraded, must run the SAP provided report within their existing system. SAP makes this step mandatory for customers running SAP solutions on traditional databases. This is accomplished by analyzing the existing SAP systems in terms of data sizes, characteristics and distribution of data objects, as well as the transaction history for these data sets.

The ABAP reports attached SAP-Note SAP Note 2296290 New BW Sizing Report must be installed and executed (The current report Version is 80, February 2020). At minimum BW-Sizing Report V2.59 or higher is strongly recommended. SAP and IBM recommend to always use the latest version.

Brownfield OLAP sample

Start the sizing report ABAP code in the background.

Note: It is mandatory to run the report under a typical load period.

Figure 3 Start the sizing report

Greenfield OLAP BW Sizing with HANA Quicksizer

Greenfield OLTP Solution Sizing with HANA Quicksizer

https://www.sap.com/about/benchmark/sizing/decision-tree.html?pdf-asset=aaa93b78-8f7c-0010-82c7-eda71af511fa&page=1https://www.sap.com/about/benchmark/sizing/decision-tree.html?pdf-asset=aaa93b78-8f7c-0010-82c7-eda71af511fa&page=1https://launchpad.support.sap.com/#/notes/2296290

14


The BW-Sizing Report (V2.59 and higher) has been extended to include a CPU capacity requirement estimation. The estimated CPU demand is reported in SAPS in addition to a memory calculation. For more details about BW CPU sizing: SAP Note 2502280 - Adding CPU requirements analysis to BW/4HANA sizing report

Major Input Parameters of the BW Sizing Report:

Figure 4 general input parameters BW Sizing Report

Note: Customers need to comply with the conditions outlined in SAP-Note 2502280 to activate the CPU analysis. Four parallel procs is the default. Higher numbers will result in higher CPU sizings.

Figure 5 BW Sizing report precision

In most cases a “Medium” Precision level is good enough. In samples taken there had been hardly differences between High and medium.

Figure 6 Customized Memory Configuration

Memory Configuration custom is the default for Power Server sizing as it allows to define this value to the actual need. The “predefined” match the appliance model sizes and are typically not used on Power. In order to start the iterative sizing process on possible starting point is to use ½ of uncompressed source SAP database size and then review the output and re-adjust if possible.

https://launchpad.support.sap.com/#/notes/0002502280

15


Note: SAP and IBM recommend to prefer scale-up over scale-out deployments in both cases – OLTP and OLAP. The maximum memory footprint for scale-up is documented in SAP Note 2188482 - SAP HANA on IBM Power Systems: Allowed Hardware.

In this example a node with a size of 800GB is defined. Depending on the DB Size the program runs between 10 minutes up to hours. Please forward the complete report to your IBM representative for review and hardware mapping assistance.

Result of the BW Sizing Report:

The report is provided in .rtf or .html file format inside the SAP system. The first page of the TDIv5 BW sizing report starts with the 2Minimum Memory Sizing Results” section.

Figure 7 Sample BW sizing report output

On the following pages of the BW Sizing Report the RSDDSTAT Analysis Details can be found. Two values are highlighted.

Data Load Peak vol: In below sample, the CPU requirement is caused by a high Data load peak, at February 17th. If this is an exceptional situation where a lower performance is acceptable re-taking the Sizing Report is the way to address this. CPU requirements: The CPU requirement class reflects the number of Queries, Dataload, CPU Utilization and the Quality of sizing relevant statistical Data. There are three classes: S, M and L. This class is put into the calculation of the physical cores. As a rule of thumb going from an L class to an S class requirement the core count is reduced by ¼. Hence, the selection of sizing report runtime is so important.

16


Figure 8 CPU requirement Class M caused by Data load peaks

The next step is to translate the SAPS value and the CPU requirement Class to physical cores. IBM can help you to analyze your Workload and the impact on the CPU requirement. IBM recommends to forward the complete sizing report to the IBM representative to determine based on the targeted Power Server Model the right CPU sizing which then has to undergo a mapping to the right LPAR configuration e.g. when using Spared pool LPARs.

Note: The entitlement of an LPAR in a shared processor pool is typically in the range of double-digit% range below to a dedicted(-donating) LPAR configuration.

For more details about the BW Sizing Report please read the documentation attached to SAP Note 2296290 New BW Sizing Report

Brownfield S/4 or Suite on HANA Sizing (with Sizing Report)

Customers with existing SAP Business Suite implementations must run the SAP provided report within their existing system. This is accomplished by analyzing the existing SAP systems in terms of data sizes, characteristics and distribution of data objects, as well as the transaction history for these data sets. For long running Business Suite/S4 applications data clean-up is an option, that must be decided on project level, depending on local regulations that will save memory and core values.

Customers must execute the ABAP report attached this SAP-Note: SAP Note 1872170 - Business Suite on HANA and S/4HANA sizing report (The current report Version is 80, February 2020).

Start the sizing report ABAP code in the background.

Note: It is mandatory to run the report under a typical load period.

Figure 9 Start the S4/Business Suite Sizing Report

Depending on the size of the database and computing resources the report runs between minutes and hours and does NOT provide SAPS but the Memory requirements.

https://launchpad.support.sap.com/#/notes/2296290https://launchpad.support.sap.com/#/notes/1872170/Ehttps://launchpad.support.sap.com/#/notes/1872170/Ehttps://launchpad.support.sap.com/#/notes/1872170/E

17


IBM recommends as a default to include a growth factor, for 3 years with a growth rate of 10% unless there are other indications. Use as with the BW Sizing Report the custom option to define the memory size of the LPAR to fit the actual needs.

Memory Sizing of S/4/BS Systems

As a starting point the “memory requirement for the initial installation” value must be used. In addition the “upgrade shadow instance” has to be added to the LPAR mapping. In the given Sample the LPAR Memory footprint is 1,669.7 GB what easily fits into a scale-up deployment.

Figure 10 Sample ERP Sizing Report output

CPU Sizing of S/4 HANA Systems

The S/4 Sizing Report does not include CPU Sizing by default. By SAP Note 1793345 Sizing for SAP Suite on HANA, SAP recommends to expect Factor 3 more of CPU requirement, for the database tier, than on Any DB. The Appserver CPU consumption remains stable for same workload.

Figure 11 CPU consumption classic DB vs HANA for S4

The database tier on traditional Business Suite systems consumes 20% of the total CPU consumption, roughly.

https://launchpad.support.sap.com/#/notes/0001793345

18


A HANA DB needs 3x the CPU resources than a traditional DB. The CPU sizing can be reduced by NSE and Data Clean-up. The server utilization can be further optimized during the Hardware Mapping by using SPLPARs.

CPU Upgrade Sizing of S/4 HANA App Servers

Before migrating to HANA, the Application Server should be upgraded to EHP 8 as per SAP recommendations (as of 7/2020). Requirement of additional CPU resources should be taken into account. IBM’s recommendations for CPU capacity upgrade factors (%) can be found in the ISICC Sizing Community (IBM or Business Partner accessible). Also the actual current usage of CPU capacity on the application servers should be looked at first and optimized.

Greenfield S/4 or Suite on HANA Sizing (with HANA Quicksizer)

The SAP Quicksizer method is dedicated for initial/green-field HANA sizing, only. It is a tool, owned by SAP and available on the SAP Webpages: https://www.sap.com/about/benchmark/sizing.quick-sizer.html (a valid S-User ID is required).

Figure 12 SAP HANA Quicksizer Versions

Sap provides three versions depending on where the Instance is going to be deployed:

• Hana Version: on-premise or IaaS deployments. • Classic Version: none HANA DBs on premise or IaaS. • S/4HANA Cloud Version: SAP HEC

The Quicksizer allows to create a Sizing Project and share the access with others, by sending Customer No. and Project Name.

Figure 13 Create Quicksizer Project

In this Picture the sample the Quicksizer Project “HOP-PLANNING-GUIDE-1” has been created. The Quicksizer covers all common Business Application Solutions. Hence, the more are

12345

https://w3-connections.ibm.com/communities/service/html/communitystart?communityUuid=4d96dfe7-b689-465c-896a-d7c6cad1621bhttps://w3-connections.ibm.com/communities/service/html/communitystart?communityUuid=4d96dfe7-b689-465c-896a-d7c6cad1621bhttps://www.sap.com/about/benchmark/sizing.quick-sizer.html

19


included the more complex the sizing input will be. In order to accomplish the task successfully the following is needed:

• A basic understanding of the application

• Identify all SAP Solutions used

• Define the Quantity Structure of the Workload (selected transactions, parallel users) • Team with SAP Solution Consultants and customer subject matter experts

Figure 14 Quicksizer Protfolio - Select SAP Solution(s)

User based vs Throughput based sizing

The Quicksizer works with two major sizing inputs.

1. User based: The Number of users, working concurrent active on the System at peek workload time (example: 1000 User working on ERP System).

2. Throughput based: The highest number of Transactions being processed within a defined timeframe (example: Creating 1 Mio Billing documents between 10-11 o’clock). Throughput and Transaction Based means the same.

If throughput and user based information is available, for example if large batch workload runs in parallel to active users, IBM recommends to create two reports: one user based and one throughput/transactions based. The sizing is at minimum the highest of both. In case the two workloads run in parallel the Sizing estimate will be above.

Data Tiering/Residence time in Memory

The longer data is kept in memory, the more memory will be needed over time. By default, the Quicksizer calculates a Residence time in Memory of 24 months. The Quicksizer allows to set residence times for each sizing position individually to get to a right memory sizing.

20


Sample sizing for 1000 Users in Sales and Service.

Figure 15 Sample sizing Sales and Services

The yellow bulb shows your current input region.

Figure 16 Sample Quicksizer input for Sales and Services

The sample sizing input is a total of 1000 Users, keeping the data 36 months in memory, and 48 months on disk (Aging). After pressing the “Check Input” and “Calculate result” buttons the sizing result is displayed.

Figure 17 Sample Sales and Service SAPS

The sample HANA DB needs 10.000 SAPS.

Figure 18Sample Sales and Service Memory

The sample HANA DB needs 362GB of Memory.

Figure 19 Sample Sales and Service Growth output

The sample HANA DB Memory requirement growths from 200 GB up to 360 GB after 3 years.

21


Learn more about the Quicksizer at the SAP HANA Academy

https://www.youtube.com/watch?v=9zWuNlwQGM4

More SAP Sizing Guidelines

Even the SAP Quicksizer does not cover every SAP Solution. Find more or detailed sizing guidelines at the SAP Sizing Homepage. https://www.sap.com/about/benchmark/sizing.html

Greenfield BW Sizing with the SAP Quickiszer

To do a BW/4 Greenfield Sizing the SAP HANA Quicksizer is to be used: https://www.sap.com/about/benchmark/sizing.quick-sizer.html#quick-sizer

Figure 20 Select the solution to be sized

Select the chapter Technology Platform and find SAP BW/4 HANA Sizing. Below you see the most common Sizing Questionnaire Tables for a BW Sizing shown in Figure 21 Size the Appserver Tier by number of users, Figure 22 Impact of objects upload and Figure 23 Advanced Data Store. “Table 2” is to size the App Server Tier by the number of users.

https://www.youtube.com/watch?v=9zWuNlwQGM4https://www.sap.com/about/benchmark/sizing.htmlhttps://www.sap.com/about/benchmark/sizing.quick-sizer.html#quick-sizer

22


Figure 21 Size the Appserver Tier by number of users

“Table 3” is to size the Impact of the Objects Upload on the HANA DB Tier

Figure 22 Impact of objects upload

Table 5 defines the Advanced DataStore and has Impact on the HANA DB Size and CPU

Figure 23 Advanced Data Store

After pressing the “Check Input” and “Calculate Result” Buttons the sizing output is generated. The next step is to choose the result level for the Software Components in the “All” tab.

The Quicksizer input above leads to an estimated HANA DB node size with a total Memory of 1.754.112 MB (1,7TB). The estimate for the CPU capacity of the HANA DB is 230.000 SAPS. (The CPU Sizing result at this Demo, is caused by a extreme Workload, entered for demo reason, only. In reality most of the systems performs perfect with half of the CPU capacity).

Sizing related technologies

SAP HANA Data Temperatures reduce the sizing result of CPU and Memory

In order to reduce the (expensive) in-memory footprint of business data, using the principle of data temperatures (hot/warm/cold) and sharing of resources. In many cases data temperatures refer to the concurrency of data for ongoing business transactions versus historical, i.e. report only, data. The latter are no more contained in the HANA core memory, but in different repositories depending on the implemented solution which can be:

- Native Storage Extension (NSE), leaving data on disk. It works for Aging as well replacing

Extension Nodes.

- Data Aging (retention periods of data can be specified in Quick Sizer, see S/4 Greenfield )

- Dynamic Tiering.

- SAP HANA BW Extension nodes.

The more data are offloaded from the “hot” data segment, the less resources are required for the

HANA nodes - at cost of higher access time for the warm and cold data sets.

23


Native Storage Extension (NSE) Warm Store Configuration Rules

NSE is an intelligent, HANA Native feature exploited today by selected business applications such as

S4 and BW. The candidates for NSE are per se all data which is aged or that can be put on a BW

Extension node.

It is the preferred warm store option for those SAP Applications supporting it as it gives highest

savings and the easiest way of operation by simply leaving data on disk that is iot used.

SAP today provides no sizing for NSE but a set of configuration rules and tooling:

• SAP Note 2771956 - SAP HANA Native Storage Extension 2.0 SPS 04 Functional Restrictions


• SAP HANA NSE Documentation July/2020:

https://www.sap.com/documents/2019/09/4475a0dd-637d-0010-87a3-c30de2ffd8ff.html

https://www.sap.com/documents/2019/09/4475a0dd-637d-0010-87a3-c30de2ffd8ff.htmlhttps://www.sap.com/documents/2019/09/4475a0dd-637d-0010-87a3-c30de2ffd8ff.html

24


Quick Reference: Get SAP HANA Sizing from SAP

Figure 24 Quick Reference: "Get SAP HANA Sizing from SAP"

Links, References and Tools

• Learn more about the Quicksizer at the SAP HANA Academy: https://www.youtube.com/watch?v=9zWuNlwQGM4

NSE:



• SAP HANA NSE Documentation July/2020: https://www.sap.com/documents/2019/09/4475a0dd-637d-0010-87a3-c30de2ffd8ff.html

More SAP Sizing Guidelines

• SAP Sizing Homepage: https://www.sap.com/about/benchmark/sizing.html • SAP Sizing Service Marketplace

• SAP HANA Sizing Decision Tree • SAP Note 2296290 New BW Sizing Report

• SAP Note 1872170 - Business Suite on HANA and S/4HANA sizing report

• SAP Quicksizer • SAP HANA Hardware Directory • SAP HANA Tailored Data Center Integration

Sizing Support • IBM Techline (IBM internal) • IBM Techline (Partnerworld)

IBM Only Material • IBM employees can find additional guidance at IBM SAP Sizing Community, the IBM

HANA on Power Community, IBM SAPS Capacity Tables (IBM internal)

Make yourself familiar with SAP HANA Sizing Decision Tree(see: „Links, References and Tools“ subchapter)

Complete SAP Quicksizer for Greenfield deployments or use the Sizing Report for Brown Filed sizings as per SAP Note for OLAP/OLTP.

Need support ?

contact your respective TechLine, FTSS and/or ATS team (see: „Links, References and Tools“ subchapter)

Quantified system requirements without server consolidation, PowerVM sharing benefits or desired Memory or Core savings

yes

https://www.youtube.com/watch?v=9zWuNlwQGM4https://www.sap.com/documents/2019/09/4475a0dd-637d-0010-87a3-c30de2ffd8ff.htmlhttps://www.sap.com/documents/2019/09/4475a0dd-637d-0010-87a3-c30de2ffd8ff.htmlhttps://www.sap.com/documents/2019/09/4475a0dd-637d-0010-87a3-c30de2ffd8ff.htmlhttps://www.sap.com/about/benchmark/sizing.htmlhttps://www.sap.com/about/benchmark/sizing.htmlhttps://www.sap.com/about/benchmark/sizing.html?pdf-asset=aaa93b78-8f7c-0010-82c7-eda71af511fa&page=1%20https://launchpad.support.sap.com/#/notes/2296290https://launchpad.support.sap.com/#/notes/1872170/Ehttps://launchpad.support.sap.com/#/notes/1872170/Ehttps://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN/power-systems.htmlhttps://www.sap.com/documents/2017/09/e6519450-d47c-0010-82c7-eda71af511fa.htmlhttps://prodpcbhrfaq03.w3-969.ibm.com/https://www.ibm.com/partnerworld/resources/sell/ibm-techline-overviewhttps://w3-connections.ibm.com/communities/service/html/communityview?communityUuid=4d96dfe7-b689-465c-896a-d7c6cad1621b#fullpageWidgetId=W6e989f97199e_4add_8d03_0cf3abf334e9&folder=60cb05a7-b3b1-4fc4-8f74-c34fa2689a52https://w3-connections.ibm.com/communities/service/html/communitystart?communityUuid=e4d11bf2-8632-4a00-ba19-d767a98a2cf3https://w3-connections.ibm.com/communities/service/html/communitystart?communityUuid=e4d11bf2-8632-4a00-ba19-d767a98a2cf3https://w3-connections.ibm.com/communities/service/html/communitystart?communityUuid=e8e3b159-92d8-48f8-a070-955264abefc3

25


Decide on Power and SAP features implemented to reduce Hardware or

accelerate your workload In 2019 IBM release a set of innovations allowing for up to 18 times faster SAP HANA restart times while maintaining virtualization and LPM capabilities, reducing the Core consumption by combining Shared Pools with SAP HANA NSE up to more than 30% and cut the memory footprint up to 50% by combining Services and SAP HANA features. These options added another dimension to the planning process helping to reduce the LPAR footprint. What was formerly a

Sizing -> LPAR mapping became an equation of

(SAP Sizing – benefits of new technologies) -> LPAR mapping.

Important is, that many technologies can or even should coexist. A collection of related documentation describing the innovations, compare options can be found here: http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102502 and in SAP Notes listed later.

SAP HANA startup acceleration

IBM provides a portfolio of different acceleration options and provided in 2019 a full documentation refresh on http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102502. Start with the document “Comparison of available Fast-Restart-Solutions on IBM Power for SAP HANA“ to be able to determine the differences. Assuming as a baseline a SVC backed by an older SSD based Storage subsystem connected to 4*8Gb/s Fiberchannel the following Info gives a thought about options and ranges discussed in the above technical guides. Highlevel Options: Faster Storage

IBM NVMe based SAN attached Storage Subsystems can accelerate a HANA Startup by a factor of 3x and more compared to older SSD based Storage backends.

Internal NVMe PCIe Cards Internal NVMe cards as used for H922 models accelerate up to 4,5x* read (link).

Rapid Cold Start Accelerates slow SAN by an NVMe cache up to 4,5x* (link).

SAP HANA Native Storage Extension HANA 2 SPS4 With SAP HANA NSE not only the memory footprint can be reduced but also startup time is accelerated by intentionally leave data on disk.

Temp-fs HANA 2 SPS4 Accelerates HANA restarts by >18x* (link).

Virtual Persistent Memory HANA 2 SPS4 Accelerates HANA and OS restarts by >17x* (link).

http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102502%202http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102502http://www-03.ibm.com/support/techdocs/atsmastr.nsf/002573f7000ac64286256c71006d2e0a/c32b40501f4f76c886257de0004fa1d4/$FILE/Overview%20on%20available%20read%20accelleration%20components%20on%20Power_V1.0.pdfhttp://www-03.ibm.com/support/techdocs/atsmastr.nsf/002573f7000ac64286256c71006d2e0a/c32b40501f4f76c886257de0004fa1d4/$FILE/Rapid-Cold-Start-on-Power-with-NVMe_V1.0.pdfhttp://www-03.ibm.com/support/techdocs/atsmastr.nsf/002573f7000ac64286256c71006d2e0a/c32b40501f4f76c886257de0004fa1d4/$FILE/vPMEM-SAPHANA-Whitepaper-Draft-V0.1.pdfhttp://www-03.ibm.com/support/techdocs/atsmastr.nsf/002573f7000ac64286256c71006d2e0a/c32b40501f4f76c886257de0004fa1d4/$FILE/vPMEM-SAPHANA-Whitepaper-Draft-V0.1.pdf

26


SAP HANA in Shared CPU Pools

SAP HANA on POWER system configurations must not only focus on the SAP HANA database instance itself, but also consider resources for SAP application servers and other systems running in the customer’s datacenters. Aggregating instance capacities and consolidating those with PowerVM will establish a more efficient usage of IBM Power Systems and at the same time it can provide a performance improvement by co-location in regard to communication and SPLPAR values covering CPU peaks better in a reasonably consolidated system.

The SAP Note defining the allowed configurations is: 2055470 - HANA on POWER Planning and Installation Specifics - Central Note.

Introduction into Shared Processor Pools Shared processor pools define virtual CPUs as the entity where the hypervisor can schedule a physical processor. Entitlement is a setting that defines how many cycles of a physical CPU are guaranteed to be made available to a virtual processor by the hypervisor. For example, an entitlement of 0.5 guarantees that a virtual CPU is getting scheduled to a physical CPU at least 50% within a given time window. As long as not all CPUs in the shared pool are used, the virtual processor may even get 100% of a given time window scheduled to a physical CPU. The total amount of configured entitlements can never exceed the physical CPUs available in a system. This allows the hypervisor to assign physical CPUs to the virtual processors for the configured entitlement always on the same NUMA nodes. Those NUMA nodes are also known as the home nodes of a Virtual CPU. For assignments of physical CPUs above the entitlement, the hypervisor tries to schedule to the home nodes as well, but this can’t be guaranteed.

Shared Processor Pool and SAP HANA

If a client is running shared processor pools with a proper sizing of the entitlement for SAP HANA, the database can make use of the internal NUMA optimizations. In most cases, performance is at least identical to a comparable setup with dedicated CPUs. Performance could be even better if more virtual CPUs are configured than in the dedicated case and overall system utilization isn’t too high (see Figure 25, below). Throughput performance in the shared pool with SAP HANA matches the performance expectation (red line) based on the entitlement—and often exceeds it.

27


Figure 25 Typical Example of Workload behavior in Shared Processor LPAR vs. Dedicated LPAR

The definition of more virtual CPUs in the shared LPAR compared to the dedicated LPAR allows it to make use of unused capacity in the shared pool for improved performance.

SAP HANA Performance Observations

SAP HANA workloads are rather spikey with short periods (seconds and less) of very high CPU utilization while processing parallelized queries, followed by longer periods of low utilization. The SAP HANA sizing targets best performance even at the workload peaks. As a result, many SAP HANA servers show a 10% to 20% CPU utilization as daily average. This characteristic pretty much accommodates the mechanism of a PowerVM shared processor pool with its highly dynamic resource management. In a shared pool the PowerVM hypervisor can switch CPU resources from an idle HANA system to another loaded system within milli-seconds. This means that shared pool LPARs can save compute resources by over-commitment. Performance impacts by a variable core-memory affinity between HANA in-memory data and processing cores are avoided by keeping the HANA CPUs and DIMMS on the identical socket, which is easy to accomplish by the PowerVM Home node

concept ensuring locality.

Figure 26 NMON LPAR utilization profiles (CPU user + system) of independent

28


Get to the right PowerVM SPLPAR settings for an SAP HANA LPAR

The combination of multiple LPARs with various workload types in a shared pool allows for capacity synergies, though, by dynamic load compensation among the applications. This is accomplished by parameterization of each LPAR per its application requirements. Following are few guidelines for production HANA DBs, more aggressive configurations should be chosen for none productive instances having a lower weight factor:

• The virtual processor count (vCPUs) should be the same as the sized physical CPU-capacity (SAPS, cores) allowing for the same degree of parallelism.

• For highest elasticity across LPARs in the shared pool all production HANA LPARs should run in uncapped mode.

• Customers can balance resource savings against tolerable performance impacts for their important transactions and jobs. As starting points, we see:

o At the time of initial setup, the entitlement of CPU resources, should be in the range of 75% for workload with critical SLAs

o From that starting point customers can gradually fine tune CPU characteristics (entitlement) while observing response time behavior. This can be performed iteratively without disrupting the affected applications.

• Lower entitlements ~50% are possible for SAP HANA LPARs. o Customers should individually balance the importance and constancy of

response and job run times with resource savings when reducing LPAR entitlements.

• Higher weighting factors are recommended for production systems over less performance critical systems.

• SAP HANA TDI5 workload categories for OLAP (large, medium small) do not necessarily correspond to higher or lower LPAR entitlements.

o Means, also “small” workloads can comprise of performance critical customer transactions, while there might be less critical response time SLAs for class “large” HANA workloads.

• Non-performance critical LPARs, e.g. running test or development systems, can have small entitlements and lower weighting factors.

• The memory per shared HANA LPAR is static and sized identical to dedicated environments.

• Newer versions of Linux are reporting the home nodes of virtual CPUs in Shared Processor Pools and HANA is able to use this information for its internal performance optimization. A user can check with the command “numactl –hardware” the NUMA topology based on the home nodes. If all CPUs are listed only on NUMA node 0 the following minimum kernels have to be used: SLES 12 SP3 with kernel => 4.4.120-94.17-default, SLES 15 or RedHat 7.6/8

• Regularly validate the CPU utilization (see next chapter). • Assuming a reasonable workload mix, the entitled CPU capacity of the pool will be

significantly less than the CPUs allocated for the identical mix to dedicated LPARs. This gives room for additional LPARs on this system thereby increasing overall CPU utilization and lowering TCO.

o For example, an average pool entitlement across all LPARs of 67%, provides spare resources of 33%, which can host additional workloads thus increasing overall server utilization and reducing TCO.

29


Monitoring SAP HANA in Shared Pools

On SAP HANA DB and application level the resource monitoring in shared processor LPARs uses the default SAP monitoring tools like saposcol and HANA Cockpit. Same is true for CIM-based external tools. No adaptions had to be made to the SAP tools and their interfaces. On LPAR level the physical consumption (%physc) refers to the core processing capacity currently used. The additional metric entitlement consumption (%entc) represents the processing capacity being used compared to the LPAR’s entitlement. Uncapped shared partitions can show an entitled capacity >100% if they access idle pool processors from other shared LPARs. Often the entitlement can be adjusted mentionable. The most common way to determine the best setting is to use nmon with a sampling interval of 5 seconds for a period of one week during a typical workload on ALL LPARS on the server’s shared pool.

Eco System and Landscape aspects

For TDI deployments there is a rich set of options. The corresponding IBM documents can be found on IBM Techdocs: http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102502

Mapping SAP Sizing Output to IBM Power Systems Configurations The server decision has to be made to fit the memory, CPU and I/O adapter requirements including the additional workload running on the same server. SAP HANA server planning comprises of three parts:

1) The size of the SAP HANA partition(s) =

SAP HANA Sizing (memory + SAPS) – “SPLPAR, NSE, NVMe, ….” + SLA requirements

2) Adapter/storage planning =

SAP TDI/Ethernet sizing + VIOS + SLA requirements 3) The size of the IBM Power Server running multiple partitions next to HANA

= workload consolidation + VIOS

Note: There is no linkage between SAP HANA scale-up/scale-out and the IBM Power E- and S-class models. Both – E- and S-class models – can be used for SAP HANA scale-up and scale-out installations.

SAP HANA deployment options and IBM Power Server

For SAP HANA scale-up (single SAP HANA node) all resources must fit into a single POWER server or an LPAR running on it. Multiple single-node HANA databases and other workloads can be consolidated on a single server.

http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102502

30


A shared pool should be used for all LPARs including SAP HANA production instances where possible. SAP Note 2230704 - SAP HANA on IBM Power Systems with multiple - LPARs per physical host documents supported LPAR configurations.

Figure 27 PowerVM LPAR types

For production HANA partitions, there is a window defined by a minimum (SAP Note 2055470) and maximum LPAR configuration (SAP Note 2188482 - 24TB as of 7/2020). Within this window any Partition size can be chosen. In scale-out multiple of these LPARs are used which can reside in a single or spread across multiple IBM Power Servers each with the maximum size of a scale-up HANA LPAR. For SAP HANA scale-out (multi-node) the inter-node network communication and the host auto failover architecture (shared disk vs. shared filesystem) must be considered when planning the servers. On IBM Power Systems, SAP HANA scale-out setups can comprise of multiple LPARs residing on a single server or spanning multiple servers. Power Systems hosting HANA scale-out partitions can also run additional LPARs with other HANA or non-HANA workloads.

Note: SAP HANA scale-up should be preferred over scale-out, since it is less complex plus more resource efficient and typically provides better performance.

Planning for SAP HANA System Replication IBM published a two Redbooks describing the pro and cons of the large variety of HANA System Replication modes. Also consider for which option the targeted Cluster Manager has the predefined scripting as this provides best integration, robustness and support. For in depth information please contact your cluster Vendor what typically is SLES HAE and RHEL Pacemaker. To optimize TCO according to SLA criteria, you must differentiate between mission critical production and less critical non-production SAP HANA database servers (SAP Note 2055470 - HANA on POWER Planning and Installation Specifics - Central Note). Selecting the best suited Power System materials:

Power Server Hardware

PowerVM Hypervisor

Dedicated/Donating

LPAR

SharedPool LPAR

SharedPoolLPAR

Shared Processor Pool

Shared Pool LPAR

Shared Pool LPAR

Shared Pool LPAR

Shared Pool LPAR

Shared Pool LPAR

Shared Pool LPAR

Virtual Shared Processor Pool n

Virtual Shared Processor Pool 1

HANA production/none production systems, ApplicationServers, optimizer, ...HANA Production

(1)/10/25/(40)Gb/s Ethernet adapters

SR-IOV capable. (8)/16/32Gb/s FC adapters

https://launchpad.support.sap.com/#/notes/ 2230704/Ehttps://launchpad.support.sap.com/#/solutions/r/?type=note&route=notes&pos=0&p=%7B%22note%22%3A%222055470%22%7D&searchTerm=HANA%20on%20power%20Central%20Note&filters=[]&sorter=scorehttps://launchpad.support.sap.com/#/notes/2055470/Ehttps://launchpad.support.sap.com/#/notes/2055470/E

31


• SAP HANA Hardware Directory listing the supported Power Systems and their allowed core

counts only models showing up here can be used for production HANA databases

• The Power Systems Facts and Features on Sales Support Information (IBM only) (SSI) or

similar documents provide detailed IBM Power Systems specifications(for example POWER8

Facts and Features or POWER9 Facts and Features(IBM only).

• Linux only server models are available and can be an alternative at a compelling price. The

same applies to Integrated Facility for Linux (IFL) specialty processors which are dedicated to

run Linux operating systems only in the E-Class models. For the E-class models these allow

tailoring IFL memory to host a SAP HANA DB.

• Within IBM eConfig a server category for “HANA models” is available. These differ from the

general Power Systems in the way that they include on HANA tracking feature code and

preselect the “Linux for SAP” distributions as default OS. These are mandatory for both SLES

12, and RHEL 7 running production HANA instances, since they include the technical and

support extensions required for mission critical HANA systems.

Also special priced HANA servers become available in this eConfig server category.

Figure 28 SAP HANA Category and Features in eConfig

Planning Considerations for Power Systems Memory Capacity

The memory size for the SAP HANA production partition is defined by the SAP sizing output. In exceptional cases customers can request individual adaptions of the common limits at SAP SE. This is a post-sales effort (i.e., cannot be applied to initial sizing), since it requires an operational HANA on POWER systems to be analyzed first. SAP Note 1903576 - SAP HANA DB: additional main memory in exceptional cases describes the details for this process. PowerVM AME (Advanced Memory Expansion) and AMS (Advanced Memory Sharing) are NOT supported for SAP HANA database partitions. In the overall context such as considering the Application servers on AIX a good memory saving can be achieved on those LPARs using AME. The rules of thumb given by SAP can be found in the attachment in SAP Note 2296290

https://w3-03.sso.ibm.com/sales/support/index_en_US.htmlhttps://w3-03.sso.ibm.com/sales/support/ShowDoc.wss?docid=POB03046USEN&node=&ftext=Power8%20Facts%20and%20Features&sort=date&sno=rating&showDetails=show&hitsize=25&offset=0&fromdate=&todate=&filtermessage=&option=&searchin=entiredoc&isw=&sw=&swv=&l=&s=desc&campaign=https://w3-03.sso.ibm.com/sales/support/ShowDoc.wss?docid=POB03046USEN&node=&ftext=Power8%20Facts%20and%20Features&sort=date&sno=rating&showDetails=show&hitsize=25&offset=0&fromdate=&todate=&filtermessage=&option=&searchin=entiredoc&isw=&sw=&swv=&l=&s=desc&campaign=https://w3-03.ibm.com/sales/support/ShowDoc.wss?docid=68014368USEN&node=&ftext=Power9%20Facts%20and%20Features&sort=date&sno=rating&showDetails=show&hitsize=25&offset=0&fromdate=&todate=&filtermessage=&option=&searchin=title&isw=&sw=&swv=&l=&s=desc&campaign=https://launchpad.support.sap.com/#/notes/1903576/Ehttps://launchpad.support.sap.com/#/notes/1903576/Ehttps://launchpad.support.sap.com/#/notes/2296290

32


Planning Considerations for Power Systems CPU Capacity

Starting with TDI Phase 5 the required core count is defined based on SAPS compared to earlier CTM (Core to Memory) ratios. The tools and process has been described above in the “HANA Sizing” chapter. With the introduction of SAP HANA 2.0, the default deployment mode has changed to MDC (multi-tenant database containers). A single or multiple HANA databases reside within a single HANA system. One implication is that the tenants can dynamically share memory and CPU resources more efficiently compared to LPAR or VM boundaries. Details are described the PDFs attached to

- SAP Note 2104291 FAQ - SAP HANA multitenant database containers

- SAP Note 2096000 SAP HANA multitenant database containers - Additional Information

SMT8 is the recommended multi-threading mode. It changes for HANA OLTP-type workloads, if the system/LPAR holds many cores, spanning 8 times of threads. SAP Note 2188482 documents the threshold and target SMT level.

Virtualization / LPARs performance related considerations

SAP HANA is highly optimized for the underlying hardware in order to achieve its superior performance. Those optimizations include sophisticated algorithms using specific processor features (like vector facilities) as well as exploiting the underlying cache and memory structures. Hence, the partitions on IBM Power Systems should be created in a specific manner to allow for the best performance. The following is a set of recommendations to achieve a good partition layout for SAP HANA:

• SAP HANA benefits especially on larger systems from an even distribution of compute power

across the LPAR. PowerVM will automatically achieve this, when the number of processors is

the same for each socket.

• The LPAR layout can be verified with the command numactl --hardware (OS command) and

should show the same number of processors for each NUMA node along with an even

distribution of memory.

• When dynamic operations are planned (such as CoD or LPM), the NUMA layout has to be

ensured at the target, if the HANA instance needs to provide the same performance as

before.

• Servers with multiple partitions, which have been created and deleted over time, PowerVM

might not be able to achieve the best partition layout immediately. In this case, you can use

DPO (Dynamic Platform Optimizer) to change the partition placements. This can be done on-

line without down-time of the SAP HANA system.

• To provide the best performance experience, the higher frequency core option of a server

model should be preferred.

Relaxed conditions for all none-production LPARs apply as of SAP Note 2055470 - HANA on POWER Planning and Installation Specifics - Central Note.

Planning Considerations for Power Systems I/O Adapter Capacity

Please see chapter “SAP HANA Connectivity” to ensure the server provides sufficient adapter slots.

https://launchpad.support.sap.com/#/notes/2104291https://launchpad.support.sap.com/#/notes/2096000https://launchpad.support.sap.com/#/notes/2055470/Ehttps://launchpad.support.sap.com/#/notes/2055470/E

33


When using VIOS ensure an appropriate resource planning for these LPARs as a minimum of 10Gb Ethernet cards is required. More details on VIOS is provided in chapter “SAP HANA Connectivity”.

Quick Reference: Find valid IBM Power Systems options

Figure 29 Quick Reference: Mapping SAP Sizing Output to IBM Power Systems

Links, References and Tools

ISICC SAPS Capacity Tables for Power Systems (IBM only): Use the table to identify systems and number of cores. The SAPS tables are maintained as an Excel-sheet and are valid for all OSs running on Power Systems. They are only accessible for IBM employees. BPs should contact IBM TechLine for support. This is identical to sizing systems for other SAP workloads. Refer to the IBM Power Systems Facts and Features for detailed system specifications (IBM only):

• POWER8 Facts and Features , POWER9 Facts and Features (IBM only)

• Sales Support Information (IBM only)

• Certified and Supported SAP HANA Hardware Directory – IBM Power Server

Please check SAP Note 2055470 - HANA on POWER Planning and Installation Specifics - Central Note for relaxations for non-production systems.

Note: Additional processors and memory are required for Virtual I/O server partitions (VIOS) and PHYP. Power Hypervisor (PHYP) also uses memory – at a max of 8% of total server memory. Do not under estimate VIOS sizing as it can hurt SAP HANA performance when requiring high Ethernet throughput.

Quantified system requirements

available from SAP HANA Sizing

Indentify IBM Power Server options providing enough memory as sized by SAP

(see POWER Systems Facts & Features or SSI for Server details.

Verify that only SAP HANA approved Power Hardware as of SAP Note 2133369 is used)

Verify SAPS requirements can be met

(see: ISICC SAPS Capacity Tables for Power

Systems for LINUX)

Ensure later the Server can also

fulfill all I/O Adapter Requirements

List of valid IBM Power Servers available.

Add additional requirements for

additional workload

(e.g. VIOS, Appserver, ...)

FOR PRODUCTION: partition is sized accordingly

to SAP Note 2188482

core/memory ratio available

SAPS available

yes

yes

Will the LPAR be used for SAP HANA production LPARs?

yes

For none-production partitions

relaxed Storage, Server, core and

memory requirements apply.

No (all non-prod HANA LPARs)

no

no

https://w3-connections.ibm.com/communities/service/html/communityoverview?communityUuid=e8e3b159-92d8-48f8-a070-955264abefc3#fullpageWidgetId=W0a495369baff_48f5_a614_852c0d13219ehttp://repository.techline.ibm.com/systemx/contact/contact/https://w3-03.sso.ibm.com/sales/support/ShowDoc.wss?docid=POB03046USEN&node=&ftext=Power8%20Facts%20and%20Features&sort=date&sno=rating&showDetails=show&hitsize=25&offset=0&fromdate=&todate=&filtermessage=&option=&searchin=entiredoc&isw=&sw=&swv=&l=&s=desc&campaign=https://w3-03.ibm.com/sales/support/ShowDoc.wss?docid=68014368USEN&node=&ftext=Power9%20Facts%20and%20Features&sort=date&sno=rating&showDetails=show&hitsize=25&offset=0&fromdate=&todate=&filtermessage=&option=&searchin=title&isw=&sw=&swv=&l=&s=desc&campaign=https://w3-03.sso.ibm.com/sales/support/index_en_US.htmlhttp://global.sap.com/community/ebook/2014-09-02-hana-hardware/enEN/power-systems.htmlhttps://launchpad.support.sap.com/#/notes/2055470/E

34


Mapping SAP I/O KPIs to a SAN Storage Design

External and internal disks can be used. External disk subsystems must be SAP HANA TDI certified. The sizing output of the Quick Sizer is not specific enough. The SAP HANA Server Installation Guide, the SAP HANA TDI – Storage Requirements Guide, along with the result of the SAP HANA Quick Sizer gives a good understanding of the volume requirements of storage. SAP HANA database performance depends on processing everything in memory. Hence the ongoing load and store operation are reduced to initial loads from disk at first access of data and writes of log files and save-points. To improve cold start, additional NVMe cards can be used to speed-up the start by factors: Technical white paper--Optimizing Quality of Service with SAP HANA on Power Rapid Cold Start The requirements introduced by the SAP HANA I/O characteristics for the file system and the underlying storage have four planning objectives:

• Start-up time:

Starting an SAP HANA Database from the stored content on disk requires read performance

during startup. Also consider other cases such as failovers to a standby node using SAP

HANA auto-host-failover or SAP HANA System replication.

• Database Persistency:

To provide persistency, data and log content is written regularly to disk. This requires low

latency for log volumes. SAP also offers to hold multiple versions of the data area, multiply

the storage requirements if used.

• Backup:

SAP HANA provides different options to backup data. Check with your Backup Vendor for

options provided.

• Data Protection:

This can be achieved using SAP HANA or Storage mechanisms (see page 36).

To optimize TCO according to SLA criteria, one must differentiate between mission critical production and less critical non-production SAP HANA database servers.

Planning Considerations for a valid Storage Type

Storage selection and deployment options:

1. Storage systems having passed the TDI certification (SAP Certified Enterprise Storage

Hardware for SAP HANA web-site for IBM).

2. Ensure appropriate multipath drivers are installed in the targeted Linux Operating system

supporting the desired technology (e.g. NPIV).

3. The end-to-end setup up to the server comprising of filesystem, operating system, server,

network and storage needs to be tested with the SAP HANA Hardware Configuration Check

Tool “HWCCT” before installing SAP HANA.

4. Storage subsystems can be attached either natively or via a storage virtualization layer like

IBM Spectrum Virtualize (formerly known as IBM SAN Volume Controller, SVC).

5. Redundant SAN attachments via virtual (VIOS) or dedicated Fibre Channel (FC) adapters are

possible. The usage of vSCSI technology is not recommended as SAP HANA auto host-failover

will not work on such disk attachments.

http://help.sap.com/hana_platform#section2http://help.sap.com/hana_platform#section2http://scn.sap.com/docs/DOC-62595https://www.ibm.com/common/ssi/cgi-bin/ssialias?htmlfid=POW03190USEN&https://www.ibm.com/common/ssi/cgi-bin/ssialias?htmlfid=POW03190USEN&http://global.sap.com/community/ebook/2014-09-02-hana-hardware/enEN/enterprise-storage.html#categories=certified%2CInternational%20Business%20Machines%20Corporationhttp://global.sap.com/community/ebook/2014-09-02-hana-hardware/enEN/enterprise-storage.html#categories=certified%2CInternational%20Business%20Machines%20Corporationhttp://global.sap.com/community/ebook/2014-09-02-hana-hardware/enEN/enterprise-storage.html#categories=certified%2CInternational%20Business%20Machines%20Corporation

35


6. To accellerate startup times internal NVMe drives can be used as described in the “Rapid

Cold Start” Documentation https://www.ibm.com/common/ssi/cgi-

bin/ssialias?htmlfid=POS03155USEN.

Use the following SAP documents as a starting point: SAP HANA TDI – Storage Requirements and SAP HANA Server Installation Guide.

IBM developed the SAPmagic - Storage Sizing Tool for SAP landscapes (IBM only), which can be used to verify or outline options complementing the SAP HANA Quick Sizer across IBM storage technologies for the SAP HANA data, log and shared filesystems. It includes a special method for optimizing SAP HANA file placement and I/O bandwidth leveraging a balanced blend of HDDs and SSDs/Flash. See the IBM System Storage Architecture and Configuration Guide for SAP HANA TDI on TechDocs for a detailed description of SAPmagic methods.

Note: Be aware that the mapping of the SAP sizing output and the following planning steps identify a larger disk space requirement than the sizing provided by the SAP HANA Quick Sizer and the SAP HANA TDI – Storage Requirements paper, based on the desired backup, advanced performance and resiliency capabilities. However, the baseline requirements are identical to all vendors as they are provided by SAP. Note: Attempting to compress data at the storage level, that is already compressed at the application level, does not save any space and can have a significant performance impact.

Background: SAP HANA filesystems and SAN storage

The SAP HANA storage capacity requirements consist of several elements with different characteristics:

• SAP HANA install directory and /usr/sap

local directory

• SAP HANA shared

A shared filesystem spanning all SAP HANA nodes belonging to the same system. It holds the

SAP HANA executables, configuration files and work directories. It can reside on NFS or IBM

spectrum Scale which can be served by SAN or a FILER option.

• SAP HANA data

Performance relevant for RTO on startup (mainly read). Needs to fulfill the minimum Storage

KPIs validated by HWCCT. Runs a supported Filesystem for SAP HANA as documented by SAP

Note 2055470 - HANA on POWER Planning and Installation Specifics - Central Note.

Compared to SAP HANA shared filesystems SAP is more restrictive. FILERS must be TDI

certified and the combination of Filesystem and Storage Backend must be verified

accordingly to SAP Note 2055470 - HANA on POWER Planning and Installation Specifics -

Central Note.

• SAP HANA log

Benefits from low latency I/O characteristics (mainly write). Needs to fulfill the minimum

Storage KPIs validated by HWCCT Runs a supported Filesystem for SAP HANA as documented

by SAP Note 2055470 - HANA on POWER Planning and Installation Specifics - Central Note.

Compared to SAP HANA shared filesystems SAP is more restrictive. FILERS must be TDI

certified and the combination of Filesystem and Storage Backend must be verified

accordingly to SAP Note 2055470 - HANA on POWER Planning and Installation Specifics -

Central Note.

• The Operating System

http://scn.sap.com/docs/DOC-62595http://help.sap.com/hana_platform#section2http://w3.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS4555http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102347http://scn.sap.com/docs/DOC-62595http://scn.sap.com/docs/DOC-62595https://launchpad.support.sap.com/#/notes/2055470/Ehttps://launchpad.support.sap.com/#/notes/2055470/Ehttps://launchpad.support.sap.com/#/notes/2055470/Ehttps://launchpad.support.sap.com/#/notes/2055470/Ehttps://launchpad.support.sap.com/#/notes/2055470/Ehttp

sap hana on planning guide ibm power systems & ibm system … · 2020. 10. 28. · sap hana on ibm...

Documents