sap netweaver sizing sap solutions on azure public cloud… · web view · 2016-03-20sap...

AuthorsCameron Gardiner, Principal Program Manager, Microsoft Azure CAT Goran Condric, Senior Premier Field Engineer, Microsoft SAP on Azure

Technical ReviewersJuergen Thomas, Principal Lead Program Manager, Microsoft Azure CATHermann Daeubler, Senior Program Manager, Microsoft Azure CATMark Weber, Principal Premier Field Engineering at MicrosoftSebastian Max Dusch, Software Engineer, Microsoft Azure CAT

i

SAP NetWeaver: Sizing SAP Solutions on Azure Public CloudThis document provides “T-shirt” sizing for 3-Tier SAP Solutions running on Azure. This document also discusses 2-Tier configurations for SAP solutions on Azure.Version: 1.1Date of Last Change: 20th March 2016

SAP NetWeaver: Sizing SAP Solutions on Azure Public Cloud

Contents1 Introduction......................................................................................................................

1.1 About This Document.........................................................................................................1.2 Who Should Read This Document......................................................................................1.3 How To Use This Document................................................................................................1.4 Background on SAP on Azure & Required Reading............................................................

2 Sizing on Azure.................................................................................................................2.1 Who Is Responsible For Sizing on Azure Public Cloud?.......................................................2.2 Database Management Systems (DBMS) Sizing on Azure.................................................2.3 SAP Application Server Sizing on Azure..............................................................................

3 Initial Generic Sizings.......................................................................................................3.1 Generic Sizing.....................................................................................................................

4 Generic Sizing – System Categories.................................................................................4.1 Category 1: 3-Tier Configuration, approximately 13,000 – 45,000 SAPS...........................4.2 Category 2: 3-Tier Configuration, approximately 45,000 – 90,000 SAPS...........................4.3 Category 3: 3-Tier Configuration, approximately 90,000 – 150,000 SAPS.........................4.4 Category 4: 3-Tier Configuration, approximately 150,000 - 250,000 SAPS........................

5 Azure Premium Storage for Database Servers................................................................6 Dynamic Resizing...........................................................................................................

6.1 Increasing System Sizing..................................................................................................6.1.1.........................................Up-sizing of SAP application servers (AS) via scale out116.1.2..........................................Up-sizing of SAP application servers (AS) via scale up136.1.3........................................................................Up-sizing of DBMS via scale up14

6.2 Decreasing System Sizing................................................................................................6.2.1......................................Down-sizing of SAP Application Servers (AS) via Scale-In186.2.2................................Down-sizing of SAP Application Servers (AS) via Scale-Down196.2.3.......................................Down-sizing of SAP DBMS VM RAM/CPU via Scale-Down21

6.3 Suspending Systems........................................................................................................7 Special Considerations for Very Large SAP Systems on Azure........................................

7.1 Premium Storage Design..................................................................................................7.2 Networking and vRSS.......................................................................................................7.3 Application Tier................................................................................................................7.4 High Availability...............................................................................................................7.5 Disaster Recovery............................................................................................................7.6 Comment, Feedback........................................................................................................

8 SAP on Azure Benchmarks & Sizing Guidance................................................................8.1 G/GS Series 3-Tier SAP Certified Benchmarks..................................................................8.2 2-Tier SAP Certified Benchmarks......................................................................................

9 General Sizing Guidance for SAP Components................................................................9.1 Common SAP Components...............................................................................................

Page of


9.1.1..........................................................................................ECC 6.0 Ehp 0 – 7289.1.2.....................................................................................................289.1.3.....................................................................................SAP Business Objects289.1.4.......................................................................................SAP Content Server289.1.5...............................................................................................SAP liveCache289.1.6..............................................................................................CTM Optimizer289.1.7....................................................................................SAP Solution Manager299.1.8.....................................................................SAP BI Java and Enterprise Portal299.1.9......................................................................................................299.1.10 SAP NetWeaver Gateway..................................................................................9.1.11 TREX..................................................................................................................9.1.12 MDM..................................................................................................................

10 Appendix: Recommended Resources & Links.................................................................

Page of


1 IntroductionThe 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 DocumentThis 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 DocumentCorrectly 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 DocumentSizing 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,

Page of

https://msdn.microsoft.com/en-us/library/azure/dn745892.aspx



1.4 Background on SAP on Azure & Required ReadingSAP 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 Serviceso SAP NetWeaver: Building a Microsoft Azure–based Disaster Recovery Solutiono 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

Page of

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



2 Sizing on AzureSizing 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 supportedAs 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

Page of

https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-size-specs/





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 AzureThe 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 throughput2. Network performance in terms of volume throughput and latency3. Amount of physical RAM available for Data Buffers or Caches4. 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 AzureThe 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 MemoryThere 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 .

Page of


http://global.sap.com/campaigns/benchmark/assets/Cert15045.pdf



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.

Page of


3 Initial Generic SizingsSizing 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 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.Category 1 3-Tier Configuration

SAPS between 13,000 – 45,000Category 2 3-Tier Configuration



SAPS between 150,000 - 250,000

Page of


4 Generic Sizing – System Categories The following Generic Sizing categories have been developed for small and medium sized 3-Tier systems.It is generally recommended to deploy 3-Tier landscapes in the following situations:

1. Production systems (all except the very smallest systems)2. 3-Tier systems should be used when the sizing data is unclear or imprecise. 3-Tier

systems are considerably easier to troubleshoot performance problems. In addition, 3-Tier system application server tier is especially simple to scale up or down

3. If the SAPS for a single SAP system exceeds about 20,000 SAPS 3-Tier configurations are generally recommended

4. If the SAP system is required to be Highly Available, the system must be a 3-Tier design

The following chapters describe different configurations and their properties, as well as some typical use cases. Below, we describe the 4 different sizing categories in more detail.

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

1 x D12 or D12v2 VM DBMS Server: 4,650 SAPS or more Between 2 - 10 x D12 or D12v2 VM App Servers each with at least 4,650 SAPS Suitable for QAS systems Premium Storage recommended for systems over 20,000 SAPS and for Production

systems


1 x DS13 or DS13v2 VM DBMS Server: 9,300 SAPS or more Between 4 - 10 x D13 or D13v2 VM App Servers each with at least 9,300 SAPS Premium Storage (in combination with DS-Series VM) is generally recommended


1 x DS13 or GS3/GS4 VM DBMS Server: 9,300 SAPS or more Between 5 - 8 x D14 or D14v2 or larger VM App Servers each with at least 18,700

SAPS Premium Storage (in combination with DS-Series VM) is generally recommended. G-

Series DB server VMs require Premium Storage

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

1 x GS5 VM DBMS Server: 42,000 SAPS Between 5 - 10 x G4 or larger VM App Servers each with at least 22,680 SAPS Premium Storage is required for G-Series DB servers.

Page of


Note: Premium Storage is not required or beneficial for SAP application servers.In addition to these generic sizes, we provide sizing guidance for specific SAP application components in section 9 of this document. Be sure to evaluate both the generic sizing here and the application component sizing before determing the VM size you will select for your SAP solution.

Page of


5 Azure Premium Storage for Database ServersCustomer deployments and performance benchmarks have shown that as the SAPS requirement of a system approaches approximately 20,000 to 25,000 SAPS, disk performance becomes the major factor limiting scalability. Customer deployments, internal testing and benchmarks have shown that disk writes to the database transaction log is especially critical.

Important:In general, it is recommended to switch from conventional rotating disk Standard Storage to Azure SSD based Premium Storage as the SAPS value of a system exceeds about 20,000 – 25,000 SAPS Microsoft Azure supports two types of storages – Standard and Premium Storage. Standard Storage is based on rotating spindles drives, and Premium storage on SSD drives. Premium storage offers much higher throughput and lower I/O latency than standard storage. Azure Standard Storage has the following limitations:

A maximum of 500 IOPS per Azure Blob Object (in this case, an attached disk) A maximum of 20,000 IOPS total per Azure Storage Account

Azure Premium Storage has the following specifications There are 3 Premium Storage Disk types: P10, P20 and P30

Premium Storage Disk Type P10 P20 P30Disk size 128 GB 512 GB 1024 GB (1 TB)IOPS per disk 500 2300 5000

Throughput per disk100 MB per second *

150 MB per second *

200 MB per second *

Each Azure VM has a specific limit on IOPS and I/O volume throughput. A DS14 VM has 50,000 IOPS and a GS5 VM has 80,000 for example. More details can be found in the following links: https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-size-specs/https://azure.microsoft.com/en-us/documentation/articles/storage-premium-storage-preview-portal/Disk IO throughput can be further increased by aggregating multiple Standard or Premium disks into a single logical disk using Windows Storage Spaces or Linux MDADM. Premium Storage Accounts do not have a limit of 20,000 IOPS per Storage Account.Care should be taken to ensure the IOPS and Bandwidth limits of a particular VM are sufficient for the workload.Azure Premium Storage is useful for DBMS workloads such as SQL Server, Oracle, Hana or MaxDB. liveCache, TREX and certain other standalone SAP engines can benefit from Premium Storage.ABAP or Java application servers usually do not benefit from Premium Storage as these VMs do not generate a lot of disk IO.The SAP on Azure documentation in Note 2015553 - SAP on Microsoft Azure Support prerequisites provides more guidance on the optimal design of disk systems

Page of



https://azure.microsoft.com/en-us/documentation/articles/storage-premium-storage-preview-portal/

https://azure.microsoft.com/en-us/documentation/articles/storage-premium-storage-preview-portal/



Important: Migrating DBMS VM from a Standard to a Premium Storage account or vice versa will cause downtime of the DBMS server VM, which will cause downtime of the whole SAP system. Therefore, you want to select your storage type carefully before deployment in order to avoid a performance problem and an unplanned downtime.

Page of


6 Dynamic ResizingThere are two main components of an SAP systems:

SAP application servers DBMS

SAP application servers are running different processes, mainly serving SAP users and SAP background processes.

6.1 Increasing System Sizing 6.1.1 Up-sizing of SAP application servers (AS) via scale outAs new users are added to an SAP application server, after a certain point the performance will degrade. New workload will cause the performance of the application server to decrease as it is too busy serving current logged on users. In extreme cases the application server will appear to hang.The solution to this problem is:

1. Configure SAP Load Balancing for Interactive (GUI) Logon, RFC, Batch, Update and Printing

2. Deploy multiple SAP application serverThe SAP Logon Load Balancing mechanism will automatically balance new workload to application servers with lower utilization. Microsoft Azure adds another possibility to improve performance and lower costs via Azure Auto Scaling.Auto Scale feature can be used as follows:

1. A fixed number of SAP application servers can be deployed and installed – for example 12 x D13 VMs each with one SAP application server instance installed and configured with 50 work processes

2. The total SAP application server resources is: 12 VMs * 1 application server instances * 50 work processes each = 600 work processes

3. After installation of the 12 VMs 8 are shutdown as the current workload does not require all the 600 work processes. Azure is a pay-per-use platform therefore the compute costs drop from 12 VMs to 4 VMs (plus a tiny cost for storage which is so small it can be considered almost $0)

4. Azure Autoscale is configure to scale up by a given number of VMs (example: 1 or 2) when the CPU threshold on the 4 running VMs exceeds a certain percentage.

5. As the workload increases, additional VMs startup automaticallyIn addition, add in the SAP AS instance profile following profile parameter into the default.pfl:Autostart = 1

This will ensure automatic start of SAP application server, after the VM is started. Care must be taken when deploying the Autostart parameter as detailed in Chapter 11.5 of the SAP NetWeaver on Azure Virtual Machines – Planning and Implementation Guide. Autostart should be removed before starting SAP Upgrades or similar activities or when troubleshooting a SAP system

Page of




Picture 1: Scale Out of SAP Application Server - Initial StateIn this demonstration, SAP workload is based on interactive user workload, that is running on two SAP Application Servers running on two Azure VMs (same principle can be applied on SAP batch, RFC and update workload). SAP user workload is automatically balanced by logon (SMLG), batch or update groups You can scale out SAP Application Server in the following ways:

Manually start new Application Servers on a new VM Enable Azure Autoscale in Azure for automatically scale out the SAP Application Server

Picture 2: Scale Out of SAP Application Server – End State after the scale out

Page of


Enable Azure Auto scale in Azure for scale out of AS – for example on 70 % CPU threshold VM with SAP app server will start.

6.1.2 Up-sizing of SAP application servers (AS) via scale upScale-up of the SAP Application Server is also an option to increase SAP Application Server SAPS. Scale up means that you do not add a new SAP AS running on a new VM, but you increase the RAM/CPU of an existing VM where an SAP Application Server is running. In this way the SAP Application Server will have more compute power, and will be able to process more users.Scaling up an SAP Application Server involves the following steps:

1. Stop the SAP Application Server2. Shutdown the Windows Operating System3. In Azure Portal or PowerShell increase the VM SKU. For example, from D11 to D124. Start the VM

Picture 3: Scale Up of SAP Application Server - Initial State

Page of


Picture 4: Scale Up of SAP Application ServerWe increased the size of VM2 where an SAP Application Server is running. Now VM2 has more RAM/CPU resources to process additional user load.

Important:Changing the size of an Azure VM will cause the VM to restart. Scaling up SAP application resources may result in an interruption of services to SAP users and/or SAP processes because the SAP Application Server is also restarted. Typically, the administrator would need to reconfigure the logon, batch and update groups to prevent new workload. Once there is no activity on this server it can be safely resized and restarted and then added back to the logon group. To reduce administrative effort, it is recommended to scale out with new additional SAP application servers.

6.1.3 Up-sizing of DBMS via scale upGenerally speaking, DBMS is a scale up scenario. Resources that are crucial for DBMS performance are:

1. Disk IO performance in terms of latency and volume throughput2. Network performance in terms of volume throughput and latency3. Amount of physical RAM available for Data Buffers or Caches4. Aggregate CPU performance (the total combined performance of all of the processors)

Page of


6.1.3.1 Up-sizing of standalone SAP DBMS VM

Picture 5: Scale Up of RAM and CPU of SAP DBMS Server – Initial and End State

Important:Scaling up the SAP DBMS server will result in short downtime of the DBMS and the whole SAP system, because the DBMS VM needs to be restarted. There are two approaches to handle resizing a DB virtual machine:

1. Before you change the Azure VM DB size stop the SAP system2. Use DBMS level High Availability technologies (such as SQL AlwaysOn or Oracle

DataGuard) to move the DB workload from the VM that needs to be resized to a standby VM. In such a scenario it is not required to stop the SAP application. It is usually recommended to do a failover when there is little activity in the SAP system

In general, it is recommended to switch to Premium Storage for VM sizes larger than D13 and is mandatory for GS Series. Note that switching from D13 to DS13 (the VM Size that supports Premium Storage) requires downtime. AlwaysOn configurations are impacted. If a system is likely to require Premium Storage, it is generally recommended to deploy Premium Storage initially rather than trying to switch from Standard Storage to Premium Storage at a later date.https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-sql-server-use-premium-storage/

6.1.3.2 Up-sizing of clustered SAP DBMS VM In your deployment, you might have a high availability DBMS setting, where the DBMS is protected with failover cluster solution. An example would be SQL Server AlwaysOn with Windows Failover Cluster. You can use this setting to scale up very fast and with less downtime in compare with DBMS running on standalone Azure VM. In the flowing example, we have two nodes cluster that protects the DBMS. The DBMS is running on cluster node 1, and cluster node 2 is passive stand by node.

Page of

https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-sql-server-use-premium-storage/

https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-sql-server-use-premium-storage/


Picture 6: Scale Up of RAM and CPU of clustered SAP DBMS Server – Initial State

A condition might occur where there is need to increase RAM/CPU , e.g., , e.g. the DBMS RAM/CPU utilization reaches 70 %.. In order to reduce the downtime of DBMS and whole SAP system, we can

1. Resize cluster node 2 VM (which will cause VM reboot)If the DBMS uses some software replication technology to replicate DBMS files (like for example in SQL Server AlwaysOn), after VM is rebooted, we have to wait for some time that DBMS changes are replicated and are in sync on both cluster nodes.

2. Now we can execute DBMS failover to the already resized second cluster node VM

Picture 7: resizing of passive cluster node and failover of DBMS cluster

Page of


The DBMS is now running on resized VM.

Picture 8: DBMS is scaled up and running on resized VM

We can now resize cluster node 1 VM as well, which is in passive cluster node.

Picture 9: resizing of first cluster node 1

Page of


Important:Using a DBMS HA solution for DBMS scale-up, we can drastically reduce SAP system downtime in compare to standalone DBMS VM resize, as DBMS failover process is much faster than VM resize.

6.2 Decreasing System SizingThere are different approaches to free unused resources and to lower the cost of running your SAP systems. The following chapters describe how you can reduce costs and resource usage for SAP Application Server and DBMS servers.

6.2.1 Down-sizing of SAP Application Servers (AS) via Scale-InWhen the peak time is over, the current SAP application server load is reduced, which results in lower RAM and CPU utilization of the Azure VMs. The following picture shows three SAP ASs running on three VMs with utilization of 40%, 20% and 10%, e.g. with average utilization of 23.33 %.

Picture 10: Scale-In of SAP Application Server - Initial StateThe current SAP AS load can be run and distributed on two VMs, therefore we can shut down the VM with SAP AS3 and in this way reduce the costs.

Page of


Picture 11: Scale-In of SAP Application Server - End State

Important:It is not recommended to use Azure Autoscale for scale-in downsizing of SAP application server, as shutting down a VM will not execute soft shutdown of an SAP AS, e.g. it will not wait for SAP users to log off and will not wait for SAP batch processes to stop. Typically, the administrator would need to remove SAP AS from the logon, RFC, batch and update groups to prevent new workload. Once there is no activity on this server, e.g. the load is drained from SAP AS, it can be safely execute manually shutdown process of SAP AS.

6.2.2 Down-sizing of SAP Application Servers (AS) via Scale-DownAnother way to downsize SAP application servers is to reduce the size of the Azure VM where the SAP AS is running on. In the example below, the utilization of the VM where SAP AS2 is running is 20%, so 80% of RAM and CPU resources are wasted.

Page of


Picture 12: Scale Down of SAP Application Server - Initial StateTherefore, it would make sense to reduce the size of SAP AS2 VM.

Picture 13: Scale Down of SAP AS2 Application Server - End State

Page of


Important:Changing the size of an Azure VM will cause the VM to restart. Scaling up SAP application resources may result in an interruption of services to users because the SAP Application Server is also restarted. Typically, the administrator would need to reconfigure the logon, RFC, batch and update groups to prevent new workload. Once there is no activity on this server it can be safely resized and restarted and then added back to the logon group.

6.2.3 Down-sizing of SAP DBMS VM RAM/CPU via Scale-DownAs already mentioned, performance of most DBMS can only be changed vertically; meaning if there is a need to reduce RAM and CPU amount, VM size could be decreased.

6.2.3.1 Down-sizing of standalone SAP DBMS VM

Picture 14: Scale Down of DBMS Server – Initial and End State

Important:Scaling down an SAP DBMS server will involve restarting the DB VMThere are two approaches to handle resizing a DB virtual machine:

1. Before you change the Azure VM DB size stop the SAP system2. Use DBMS level High Availability technologies (such as SQL AlwaysOn or Oracle

DataGuard) to move the DB workload from the VM that needs to be resized to a standby VM. In such a scenario it is not required to stop the SAP application. It is usually recommended to do a failover when there is little activity in the SAP system

6.2.3.2 Down-sizing of clustered SAP DBMS VM In your deployment, you might have a high availability DBMS setting, where DBMS is protected with failover cluster solution. You can use this solution to reduce the downtime during the resizing process, in a same way as described in chapter Up-sizing of clustered SAP DBMS VM.

Page of


6.3 Suspending SystemsSAP customers may require temporary project landscapes or clones of SAP systems for training or testing. Most commonly these landscapes are used for several months during a project and are then no longer needed. When testing or training are finished, the Azure resources can be shut down and will no longer be charged (other than storage which is very low cost). With the Azure platform the following process can be followed:

1. Provision Azure resources such as VMs, network and storage2. Using the SAP System Copy Guide perform a copy of the source systems3. Upload backups and exports to Azure using AzCopy4. Using the SAP System Copy Guide perform target system installation5. Perform post processing6. Use SAP systems for project, demo, testing or upgrade testing7. After the project, testing or upgrade is complete, shutdown the Azure resources.

Compute resources (VMs) are no longer charged and only storage is paid for (which is low cost)

When systems are needed again the Compute resources can be restarted. If required, the databases can be refreshed with the most up to date copy of production or TDMS source.

Page of


7 Special Considerations for Very Large SAP Systems on Azure

When deploying an individual SAP Component that exceeds 100,000 SAPS it is recommended to review some additional factors.Before proceeding it is necessary to clearly define what the term “SAP System” means in relation to SAP Sizing and to identify what the limiting factors are for Sizing SAP applications.

Term Meaning Example Limiting Factor on Sizing

SAP DB Server Instance

SAPS value for a DB server dedicated for only one SAP Component

Typically 10%-20% of the total Component SAPS

Yes

SAP App Server Instance

SAPS value of the APP server(s) for one SAP Component

Typically 80%-90% of the total Component SAPS

No, SAP application server tier can scale out horizontally very effectively by adding addition servers

SAP Component

SAP Software Solution SAP ECC 6.0, SAP BI, SAP PI, Content Server, LiveCache, BWA

Yes

SAP “System” SAP Application Components all belonging to one SID or “System ID”. A three letter code

“PRD” or “BWP” are examples of SID. A ERP system might have ECC 6.0 (DB & app) as well as a Content Server

Yes, a single SAP System has maximum limits

SAP Environment

All SAP Components belonging to a common function in a Landscape

Development, Test, DR, Training and Production are common examples

No, there is no theoretical limit on how large an Environment can be as an Environment can be made up of many SAP Components

SAP Landscape

All SAP Environments and all auxiliary support systems such as SAP Router, Firewalls, non-SAP utilities such as Automated Testing/Load Generation tools

No, there is no theoretical limit on how large an Landscape can be as an Landscape can be made up of many SAP Components and Environments

When designing a sizing solution, the total aggregated SAPS of an Environment or Landscape are not relevant or useful to consider. If the total production Environment SAPS were 600,000 and the total SAP Landscape was 1,000,000 SAPS no reliable sizing characteristics can be deduced from this information.Accurate sizing can only be calculated from knowing the current Database and Application server SAPS for a single SAP Component. The topics below require additional consideration when any single SAP application component exceeds 100,000 SAPS.

Page of


7.1 Premium Storage DesignDifferent DBMS platforms handle persistent and temporary storage a little differently. It is recommended to discuss the storage design with an experienced consultant who is familiar with the specific DBMS.The list below is general guidance only:

1. Premium Storage is recommended for most customers with systems larger than 20,000 SAPS or DB sizes larger than 500GB (compressed DB size)

2. Transaction Logs should be on their own dedicated Premium Storage disk3. Use Windows Storage Spaces or Linux MDADM to increase the IO and throughput for

database files 4. Some databases such as SQL Server have simple and straight forward storage

designs. Other DBMS that still utilize tablespaces such as Oracle or DB2 are more complex and more difficult to balance IO

5. Windows Storage Spaces or Linux MDADM can be used to aggregate multiple disks into one large volume

6. Database temporary areas such as the SQL Server tempdb or Oracle PSAPTEMP can usually be co-located with data files. The log file for the SQL Server tempdb can be stored on the same disk as the SAP database log file. Some databases support putting temp files onto D:\ (non persistent)

7. Care must be taken to select an Azure VM SKU that has an IO throughput capacity greater than or equal to the theoretical capacity of all the provisioned disks. For example small Azure VMs may not have enough capacity to fully leverage multiple P30 disks

7.2 Networking and vRSSWindows Server 2012 R2 and higher guest VMs should be deployed as they support vRSS. This technology balances network processing across available processors. Other operating systems may only leverage one or two processors out of all the available processors for network processing.More details on vRSS can be found here: https://technet.microsoft.com/en-us/library/dn383582.aspxhttp://blogs.technet.com/b/networking/archive/2013/07/31/drive-up-networking-performance-for-your-most-demanding-workloads-with-virtual-rss.aspx World Record SAP Sales and Distribution Standard Application Benchmark for SAP cloud deployments released using Azure IaaS VMs

7.3 Application TierReview SAP Note 1612283 - Hardware Configuration Standards and Guidance for details on how to size SAP application servers. In general, the following statements are true:

1. SAP application servers scale out exceptionally well and near linear scalability is seen in test conditions

2. The scalability of a single SAP instance is impacted by the number of work processes and the workload applied. Therefore, we recommend smaller but multiple SAP instances. An optimum point to think about splitting instances is when 40-50 work processes are required to run the workload applied to an instance

3. It is therefore recommended to create many application servers each with 40-50 work processes. You’ll need to configure PHYS_MEMSIZE, if required.

Page of


http://blogs.msdn.com/b/saponsqlserver/archive/2015/10/05/world-record-sap-sales-and-distribution-standard-application-benchmark-for-sap-cloud-deployments-released-using-azure-iaas-vms.aspx

http://blogs.msdn.com/b/saponsqlserver/archive/2015/10/05/world-record-sap-sales-and-distribution-standard-application-benchmark-for-sap-cloud-deployments-released-using-azure-iaas-vms.aspx

http://blogs.technet.com/b/networking/archive/2013/07/31/drive-up-networking-performance-for-your-most-demanding-workloads-with-virtual-rss.aspx

http://blogs.technet.com/b/networking/archive/2013/07/31/drive-up-networking-performance-for-your-most-demanding-workloads-with-virtual-rss.aspx

https://technet.microsoft.com/en-us/library/dn383582.aspx


4. Autoscale can be used to automatically increase the number of application servers under peak load

5. SAP application servers do not benefit from or require Premium Storage6. Do not use SAP application servers as file or print servers, even for the SAP application

itself. These functions should be performed by dedicated servers

Page of


7.4 High AvailabilityPlease review the SAP on Azure documentation for the latest information on High Availability.In general, a highly available solution should protect the following layers:

1. Database layer: DBMS level replication technologies such as SQL Server AlwaysOn or Oracle DataGuard are recommended

2. SAP Single Points of Failure – SAP ASCS: review the latest SAP on Azure documentation3. SAP Application Server: this layer is not a SPOF and therefore should be protected by

simply having multiple SAP application servers4. Network connectivity from the data center to customer network: The Site-2-Site VPN

and ExpressRoute links and the customer WAN is a critical service to protect. A complete failure of the customer network would mean a total loss of service. Azure solutions such as RemoteApp (which can run over public internet) is one mitigation against this risk

7.5 Disaster RecoveryAzure Site Recovery provides a comprehensive suite of tools to protect against the total loss of a customer, hoster or Azure datacenter. SAP systems can be replicated to another continent. Azure Site Recovery also provides scripting and automation to ensure the correct startup timing and sequencing (such as starting Active Directory first and starting DBMS servers before SAP application servers)

7.6 Comment, FeedbackIf you have comments, feedback on Azure sizing for large systems please contact Microsoft at this email address:[email protected]

Page of

mailto:[email protected]


8 SAP on Azure Benchmarks & Sizing GuidanceThe latest available SAP Benchmarks for both 2-Tier and 3-Tier systems are always published here: http://global.sap.com/campaigns/benchmark/appbm_cloud.epxIn addition, the benchmarks and certified SAP VM types are also listed in SAP Note 1928533 SAP Applications on Azure: Supported Products and Azure VM types (SAP Service Marketplace user ID is required)It is recommended to review these links because the information is frequently updated as new VM types and Benchmarks are released. A brief summary of the Benchmarks as of November 2015 is detailed below for readers who may not have access to Service Marketplace.Full disclosure of all SAP benchmark data can be found at this website

8.1 G/GS Series 3-Tier SAP Certified Benchmarks The Azure GS4 VM with one GS2 for the Message Server and 7 G5 VMs for SAP application servers can deliver 45,000 users and nearly 250,000 SAPS. This capacity is normally considered to be enough for the majority of customers.

VM Type VM Size SAPS Certification Link & Full Disclosure

A5 2 CPU, 14 GB 12,000A6 4 CPU, 28 GB 25,000A7 8 CPU, 56 GB 50,000GS1 2 CPU, 28 GB 38,415 2015042

GS2 4 CPU, 56 GB 78,620 2015043

GS3 8 CPU, 112 GB 137,520 2015044

GS4 16 CPU, 224 GB 247,880 2015045

Page of





http://global.sap.com/campaigns/benchmark/appbm_cloud.epx



http://global.sap.com/campaigns/benchmark/appbm_cloud.epx


8.2 2-Tier SAP Certified Benchmarks The Azure GS5 VM has benchmarked more than 40,000 SAPS in 2-Tier configuration.

VM Type VM Size SAPS Certification Link & Full Disclosure

A5 2 CPU, 14 GB 1,500A6 4 CPU, 28 GB 3,000A7 8 CPU, 56 GB 6,000A8/A10 8 CPU, 56 GB 11,000A9/A11 16 CPU, 112 GB 22,000 2014039

D11/DS11 2 CPU, 14 GB 2,325D12/DS12 4 CPU, 28 GB 4,650D13/DS13 8 CPU, 56 GB 9,300 2014039

D14/DS14 16 CPU, 112 GB 18,600 2014040

GS1 2 CPU, 28 GB 3,580 2015046

GS2 4 CPU, 56 GB 6,900 2015047

GS3 8 CPU, 112 GB 11,870 2015048

GS4 16 CPU, 224 GB 22,680 2015049

GS5 32 CPU, 448 GB 41,670 2015038

Page of










9 General Sizing Guidance for SAP ComponentsThe following is general guidance based on experience deploying SAP applications on Azure. Different SAP applications have very different workload characteristics and requirements. In the section below the properties of different SAP applications are characterized with respect to CPU, memory, network and disk IO characteristics.Example 1: CTM Optimizer and TREX quite CPU thread centric, but does not consume too much memory Example 2: liveCache is quite memory and CPU intensive and can also benefit from Premium Storage

9.1 Common SAP Components 9.1.1 ECC 6.0 Ehp 0 – 7SAP ECC has such a very wide usage profile depending on the modules used that it is difficult to give general guidance. Here is the minimal guidance we can provide:

DBMS VM: Sizing of the database server should be based on the database SAPS value and the corresponding Azure VM benchmark. Premium Storage would be recommended for most production ECC 6.0 systems. Most customers deploy on DS12 or larger VMs

SAP Application Server VMs:o SAP Basis 7.0 to 7.31 (Kernel 7.22 based) a single SAP application server can

run on a D11 or larger VMo SAP Basis 7.4 and higher (Kernel 7.40 or higher)- 7.40 kernels require more

memory. D12 recommended as minimum for SAP application server for Production systems. D11 could be too small for larger productive 7.4 kernel based systems

9.1.2 SAP ASCSIt is recommended to deploy the SAP ASCS on the smallest certified Azure VM. The SAP ASCS does not consume CPU, network, disk IO or network to any large extent. It is recommended to deploy ASCS clusters on D11 or A5 VMs

9.1.3 SAP Business ObjectsSAP Business Objects: Most customers deploy the DBMS layer on D12 and the CMS runs on D11 or D12

9.1.4 SAP Content ServerA MaxDB database and IIS form a Content Server solution. Typically, the workload on Content Server is low therefore D12 can be used for the MaxDB instance. D11 VMs can be used for the IIS component. In most cases Premium Storage is not needed.

9.1.5 SAP liveCacheSAP liveCache 7.9 and above is certified and supported on Azure. liveCache is CPU, RAM and disk IO intensive, therefore SAP liveCache has to run on an dedicated Azure VM. Production SAP liveCache systems should be deployed on DS13 or larger. Large liveCache systems can be deployed on GS series VMs up to 32 processors and 448GB RAM. Premium storage is recommended for large liveCache systems. Large liveCache systems may require VM sizes DS14 or GS4 and above.

Page of


9.1.6 CTM OptimizerCTM Optimizer is highly dependent on CPU thread performance. The CTM Optimizer can use a lot of RAM and can be parallelized to some extent. D12 VMs for production systems can be considered for CTM1640509 - FAQ about the setup of SCM Optimizer

9.1.7 SAP Solution ManagerSAP Solution Manager resource requirements are highly dependent on functionalities deployed. If many of the Solution Manager functionalities are activated, then Solution Manager could run on D12 or higher for the database tier and several D11 for the application servers.

9.1.8 SAP BI Java and Enterprise PortalThe database workload for BI Java and Enterprise Portal is typically very low. A D11 or D12 is typically large enough. Large Enterprise Portal systems have many Java servers scaled out on D11.

9.1.9 SAP XI/PIThe database workload for a double stack ABAP+Java PI system is typically low. D11 or D12 is typically enough for the DBMS layer. If a large number of messages are processed, then it is recommended to scale out the application tier on D11 or D12 VMs.

9.1.10 SAP NetWeaver Gateway SAP NetWeaver Gateway is commonly placed in cloud environments to provide HTML5 rendering for external applications. The DB server is typically D12 and multiple D11 SAP application servers.

9.1.11 TREXLarge TREX implementations will benefit from faster CPU, more thread performance and Premium Storage. Azure DS series are recommended. Smaller GS VMs could be used as well

9.1.12 MDMThe SAP MDM product will be replaced and the current product is at end of life. SAP therefore do not support MDM on public cloud environments. Please send a message to BC-OP-NT-AZR

Page of



10Appendix: Recommended Resources & Links1409608 - Virtualization on Windows 1492000 - General Support Statement for Virtual Environments 1928533 - SAP Applications on Azure: Supported Products and Azure VM types 2178632 - Key Monitoring Metrics for SAP on Microsoft Azure 1380654 - SAP support in public cloud environments 2035875 - SAP on Microsoft Azure: Necessary Adaption of your SAP License 1999351 - Troubleshooting Enhanced Azure Monitoring for SAP 2015553 - SAP on Microsoft Azure: Support prerequisites Azure VM types and properties https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-size-specs/

Page of










sap netweaver sizing sap solutions on azure public cloud… · web view · 2016-03-20sap...

Documents