Cameron Gardiner, Principal Program Manager, Microsoft Azure CAT

Authors

Goran Condric, Senior Premier Field Engineer, Microsoft SAP on Azure

Technical Reviewers

Juergen Thomas, Principal Lead Program Manager, Microsoft Azure CAT

Hermann Daeubler, Senior Program Manager, Microsoft Azure CAT
Mark Weber, Principal Premier Field Engineering at Microsoft

Sebastian Max Dusch, Software Engineer, Microsoft Azure CAT

SAP NetWeaver: Sizing SAP Solutions on Azure Public Cloud

Contents

1 Introduction 4

1.1 About This Document 4

1.2 Who Should Read This Document 4

1.3 How To Use This Document 4

1.4 Background on SAP on Azure & Required Reading 5

2 Sizing on Azure 6

2.1 Who Is Responsible For Sizing on Azure Public Cloud? 7

2.2 Database Management Systems (DBMS) Sizing on Azure 7

2.3 SAP Application Server Sizing on Azure 7

3 Initial Generic Sizings 8

3.1 Generic Sizing 8

4 Generic Sizing – System Categories 9

4.1 Category 1: 3-Tier Configuration, approximately 13,000 – 45,000 SAPS 9

4.2 Category 2: 3-Tier Configuration, approximately 45,000 – 90,000 SAPS 9

4.3 Category 3: 3-Tier Configuration, approximately 90,000 – 150,000 SAPS 9

4.4 Category 4: 3-Tier Configuration, approximately 150,000 - 250,000 SAPS 9

5 Azure Premium Storage for Database Servers 10

6 Dynamic Resizing 11

6.1 Increasing System Sizing 11

6.1.1 Up-sizing of SAP application servers (AS) via scale out 11

6.1.2 Up-sizing of SAP application servers (AS) via scale up 13

6.1.3 Up-sizing of DBMS via scale up 14

6.2 Decreasing System Sizing 18

6.2.1 Down-sizing of SAP Application Servers (AS) via Scale-In 18

6.2.2 Down-sizing of SAP Application Servers (AS) via Scale-Down 19

6.2.3 Down-sizing of SAP DBMS VM RAM/CPU via Scale-Down 21

6.3 Suspending Systems 22

7 Special Considerations for Very Large SAP Systems on Azure 23

7.1 Premium Storage Design 23

7.2 Networking and vRSS 24

7.3 Application Tier 24

7.4 High Availability 25

7.5 Disaster Recovery 25

7.6 Comment, Feedback 25

8 SAP on Azure Benchmarks & Sizing Guidance 26

8.1 G/GS Series 3-Tier SAP Certified Benchmarks 26

8.2 2-Tier SAP Certified Benchmarks 27

9 General Sizing Guidance for SAP Components 28

9.1 Common SAP Components 28

9.1.1 ECC 6.0 Ehp 0 – 7 28

9.1.2 SAP ASCS 28

9.1.3 SAP Business Objects 28

9.1.4 SAP Content Server 28

9.1.5 SAP liveCache 28

9.1.6 CTM Optimizer 28

9.1.7 SAP Solution Manager 29

9.1.8 SAP BI Java and Enterprise Portal 29

9.1.9 SAP XI/PI 29

9.1.10 SAP NetWeaver Gateway 29

9.1.11 TREX 29

9.1.12 MDM 29

10 Appendix: Recommended Resources & Links 30

Page 10 of 31

SAP NetWeaver: Sizing SAP Solutions on Azure Public Cloud

1 Introduction

The performance capabilities of the Azure Public Cloud Platform can meet the requirements of even some of the largest and most demanding SAP systems. 3-Tier SAP Benchmarks of close to 250,000 SAPS have been proven and certified on Azure GS series VMs.

As with on-premises deployments, care must be taken to appropriately match the Azure Cloud Infrastructure to the SAP Workload to produce good consistent performance. This document details the important sizing concepts specific to Azure Cloud platforms.

1.1 About This Document

This document should be followed when transferring existing SAP systems from on-premises to Azure or when deploying new SAP systems on Azure.

1.2 Who Should Read This Document

Correctly sizing SAP systems is perhaps one of the more challenging tasks and requires significant skills and experience. It is therefore recommended that only those who already have experience in sizing on-premises systems perform sizing on Azure.

The audience for this document is technical project managers, lead NetWeaver consultants and SAP database administrators

1.3 How To Use This Document

Sizing is only one part of the overall process of designing and implementing an SAP Landscape. This document does not describe critical topics such as High Availability and Disaster Recovery in detail. These topics are addressed in the SAP on Azure documentation for Virtual Machines and the DBMS guides.

It is recommended to develop an Excel spreadsheet or Visio diagram that depicts the SAP Landscape. In the initial solution design, the focus may be on topics such as: the number of non-production environments (sandbox, dev, qa); High Availability’ or Disaster Recovery. The size of the Azure VMs, the storage type and other sizing factors can be left as blank “place-holders” initially. After reading this document the reader should attempt to match the sizing requirements to the available Azure VMs and storage SKUs.

Sizing is an ongoing process and should be regularly reviewed and adjusted. The Azure Public Cloud platform allows customers to dynamically increase resources (to cater for increased demand) or decrease resources (to save money). It is recommended to review utilization on infrastructure about every 3 months to determine if the Azure resources provisioned match the demand from the SAP workload.

Where there is considerable uncertainty about the exact sizing requirements, the Azure platform allows several strategies that are difficult or impossible with traditional on-premises or hosted solutions. For example, if during a new SAP deployment there is a lack of sizing inputs for the SAP Quicksizer tool (business documents, users, data volumes, transactions per day etc.) then an SAP on Azure deployment can be significantly oversized for Go Live. In the weeks and months after Go Live the utilization of the infrastructure can be monitored, reviewed and downsized to reduce costs.This allows tremendous flexibility with your hardware and costs as well as ensuring your system is stable. The advantage in the Azure case is that you can ensure you GoLive with enough resources to avoid a resource shortage and then reduce later if needed. With an on-premises deployment, you are typically locked into the hardware a system is deployed on, even if it’s too large,

1.4 Background on SAP on Azure & Required Reading

SAP on Azure documentation must be read before reading this document. Do not proceed reading this document until the following documentation has been read:

· From MSDN:

o SAP NetWeaver on Microsoft Azure Virtual Machine Services - Deployment Guide

o DBMS Deployment Guide for SAP on Microsoft Azure Virtual Machine Services

o SAP NetWeaver: Building a Microsoft Azure–based Disaster Recovery Solution

o Clustering SAP ASCS Instance using Windows Server Failover Cluster on Azure with SIOS DataKeeper

· Note 1928533 SAP Applications on Azure: Supported Products and Azure VM types

· Note 2015553 SAP on Microsoft Azure: Support Prerequisites

· Note 1999351 Enhanced Azure Monitoring for SAP

· Note 2178632 Key Monitoring Metrics for SAP on Microsoft Azure

· Note 1409604 Virtualization on Windows: Enhanced Monitoring

2 Sizing on Azure

Sizing SAP solutions on Azure introduces several important concepts that significantly differ from traditional on-premises or hosted solutions. One of the most important differences between on-premises sizing and Azure sizing is the ability to dynamically resize on demand. Traditional sizing required consultants and system administrators to purchase hardware infrastructure that was sufficient generally for the next 3-5 years. This approach has some problems and limitations:

1. Senior management typically has an expectation that hardware investments will last between 3 to 5 years. However, during this time requirements and scenarios from businesses may change significantly. The ability to forecast requirements up to 5 years in the future is also very difficult

2. Technologies like Virtualization did offer the capability to change hardware resources available within a VM (even doing so dynamically) but only within the limit up to the maximum resources of the underlying hardware. Unless virtualization farm deployments were truly at Hyper-scale, this theoretical capability was seldom realized

3. Ad Hoc requests from Functional or Business teams for clone systems/copies of production for testing Support Packs/Upgrade or new business functionality sometimes require a lot of VMs and sometimes a great deal of storage. Often the infrastructure resources (VMs, storage and auxiliary capabilities like Backup/Restore) are either not available or not available in the timeframes required

4. Because of the above factors, often the purchase of hardware infrastructure needs to be many orders of magnitude larger than the actual sizing requirements during Year 1. This is due to the uncertainty and risk around a relatively static infrastructure resource. SAP and Datacenter teams typically need to include a very large buffer in their on-premises sizing calculations. This is not required on Azure deployments.

One additional differentiator between most on-premises solutions and Azure is the ability to bill Infrastructure per minute and cross charge this from IT cost centers back to business cost centers. Often this is particularly useful for diversified conglomerates that run separate business units under one shared IT department.

The reader of this document should be familiar with the following concepts:

1. Not all Azure VM types are supported for running SAP applications. SAP requires a certain ratio of CPU to memory and other properties

2. The certified Azure VM types are documented in SAP Note 1928533 SAP Applications on Azure: Supported Products and Azure VM types

3. A detailed description of each VM is documented here: https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-size-specs/

Dynamic sizing in Azure allows VMs, storage and other features like Backup, Disaster Recovery and networking to be adjusted near instantaneously. This is particularly true with the Azure Resource Manager, or ARM (IaaS v2) where VM resizing from any VM SKU to any other VM SKU is fully supported

As of November 2015, the largest Azure VM SKU certified for SAP is the GS5 with 32 CPUs and 448GB RAM. The GS series configurations have benchmarked close to 250,000 SAPS in 3-tier configurations and in excess of 40,000 SAPS in 2-tier configurations.

Typically, we would recommend either D12 or D13 for SAP application servers for large 3-tier production systems. The SAP application server layer has demonstrated better scale out performance on all operating systems and infrastructures therefore it is generally recommended to add additional VMs with additional instance(s) rather than use of larger VM SKUs. Review SAP Note 1612283 - Hardware Configuration Standards and Guidance for details on how to size SAP application servers

2.1 Who Is Responsible For Sizing on Azure Public Cloud?

It is recommended to work with an SAP Technology Partner or System Integrator with qualified SAP NetWeaver consultants. In general customers should engage an SAP NetWeaver consultant to develop or confirm SAP on Azure sizing. Only customers with internal SAP teams with considerable sizing experience should develop their SAP on Azure sizing without external assistance.

Sizing should be performed by a consultant that has successfully completed sizing solutions for on-premises systems in the past.

2.2 Database Management Systems (DBMS) Sizing on Azure

The performance of a DBMS is largely determined by four variables, assuming all other factors are held constant:

1. Disk IO performance in terms of latency and volume throughput

2. Network performance in terms of volume throughput and latency

3. Amount of physical RAM available for Data Buffers or Caches

4. Aggregate CPU performance (the total combined performance of all of the processors)

There are other factors, but the above four factors account for the majority of the performance constraints on most DBMS due to infrastructure. While it’s rarer for the network to be critical these days, the other three components are observed often as severe bottlenecks due to insufficient sizing. The performance of most DBMS can only be increased vertically; meaning that performance can only be increased by scaling up some or all of the parameters. An exception to this might be scale out technologies, although scale-out technologies usually add considerable expense and complexity in operations to a solution and so far have very limited adoption in the SAP space.

At the time of writing in October 2015 the largest Azure VM SKU certified for SAP is the GS5 with 32 CPU and 448GB RAM. GS Series configurations have benchmarked close 250,000 SAPS in 3-tier configurations (http://global.sap.com/campaigns/benchmark/assets/Cert15045.pdf ).

2.3 SAP Application Server Sizing on Azure

The performance of an SAP ABAP Application is largely determined by two parameters assuming all other factors are held constant:

1. CPU performance per thread (the individual performance of a single processor)

2. Amount of physical RAM available for SAP buffers (such as PXA, Table, Nametab) and Extended Memory

There are other factors such as network throughput to the database VM, but the above two parameters account for the majority of the performance constraints on most SAP systems due to infrastructure.

Unlike DBMS software the SAP ABAP kernel is not multi-threaded and will run on only one processor thread on all Operating Systems supported by SAP. It is strongly recommended to read SAP Note 1612283 - Hardware Configuration Standards and Guidance.

For SAP ABAP kernel it is also strongly recommended to use high performance optimized SAP kernel for Windows, which offers up to 20% better performance compared to previous versions of SAP kernels, as described in the SAP note 1357244 - High Performance SAP Kernel for Windows .

The SAP Java application server is multi-threaded but scale out performance far exceeds scale up performance.

3 Initial Generic Sizings

Traditional sizing required consultants and system administrators to purchase and acquire hardware infrastructure that was generally sufficient for the next 3-5 years.

Azure infrastructure can be dynamically changed and therefore smaller systems can be built using generic “T-shirt” sizes. Larger systems must still follow the normal processes and procedures for sizing and involve the hardware vendor which, in the case of Azure, is Microsoft.

3.1 Generic Sizing

Many SAP systems are relatively small or medium sized and do not require details of complex sizing. This is particularly true on Microsoft Azure as it is very simple to increase or decrease sizing.

To simplify the sizing process four sizing categories are proposed for small and medium 3-Tier systems.