Introduction - Microsoft



4572001628775SAP 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 201600SAP 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 20165940425457200457200804672000AuthorsCameron Gardiner, Principal Program Manager, Microsoft Azure CAT Goran Condric, Senior Premier Field Engineer, Microsoft SAP on AzureTechnical 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 CATContents TOC \o "1-3" \h \z \u 1Introduction PAGEREF _Toc436728757 \h 41.1About This Document PAGEREF _Toc436728758 \h 41.2Who Should Read This Document PAGEREF _Toc436728759 \h 41.3How To Use This Document PAGEREF _Toc436728760 \h 41.4Background on SAP on Azure & Required Reading PAGEREF _Toc436728761 \h 52Sizing on Azure PAGEREF _Toc436728762 \h 62.1Who Is Responsible For Sizing on Azure Public Cloud? PAGEREF _Toc436728763 \h 72.2Database Management Systems (DBMS) Sizing on Azure PAGEREF _Toc436728764 \h 72.3SAP Application Server Sizing on Azure PAGEREF _Toc436728765 \h 73Initial Generic Sizings PAGEREF _Toc436728766 \h 83.1Generic Sizing PAGEREF _Toc436728767 \h 84Generic Sizing – System Categories PAGEREF _Toc436728768 \h 94.1Category 1: 3-Tier Configuration, approximately 13,000 – 45,000 SAPS PAGEREF _Toc436728769 \h 94.2Category 2: 3-Tier Configuration, approximately 45,000 – 90,000 SAPS PAGEREF _Toc436728770 \h 94.3Category 3: 3-Tier Configuration, approximately 90,000 – 150,000 SAPS PAGEREF _Toc436728771 \h 94.4Category 4: 3-Tier Configuration, approximately 150,000 - 250,000 SAPS PAGEREF _Toc436728772 \h 95Azure Premium Storage for Database Servers PAGEREF _Toc436728773 \h 106Dynamic Resizing PAGEREF _Toc436728774 \h 116.1Increasing System Sizing PAGEREF _Toc436728775 \h 116.1.1Up-sizing of SAP application servers (AS) via scale out PAGEREF _Toc436728776 \h 116.1.2Up-sizing of SAP application servers (AS) via scale up PAGEREF _Toc436728777 \h 136.1.3Up-sizing of DBMS via scale up PAGEREF _Toc436728778 \h 146.2Decreasing System Sizing PAGEREF _Toc436728779 \h 186.2.1Down-sizing of SAP Application Servers (AS) via Scale-In PAGEREF _Toc436728780 \h 186.2.2Down-sizing of SAP Application Servers (AS) via Scale-Down PAGEREF _Toc436728781 \h 196.2.3Down-sizing of SAP DBMS VM RAM/CPU via Scale-Down PAGEREF _Toc436728782 \h 216.3Suspending Systems PAGEREF _Toc436728783 \h 227Special Considerations for Very Large SAP Systems on Azure PAGEREF _Toc436728784 \h 237.1Premium Storage Design PAGEREF _Toc436728785 \h 237.2Networking and vRSS PAGEREF _Toc436728786 \h 247.3Application Tier PAGEREF _Toc436728787 \h 247.4High Availability PAGEREF _Toc436728788 \h 257.5Disaster Recovery PAGEREF _Toc436728789 \h 257.6Comment, Feedback PAGEREF _Toc436728790 \h 258SAP on Azure Benchmarks & Sizing Guidance PAGEREF _Toc436728791 \h 268.1G/GS Series 3-Tier SAP Certified Benchmarks PAGEREF _Toc436728792 \h 268.22-Tier SAP Certified Benchmarks PAGEREF _Toc436728793 \h 279General Sizing Guidance for SAP Components PAGEREF _Toc436728794 \h 289.1Common SAP Components PAGEREF _Toc436728795 \h 289.1.1ECC 6.0 Ehp 0 – 7 PAGEREF _Toc436728796 \h 289.1.2SAP ASCS PAGEREF _Toc436728797 \h 289.1.3SAP Business Objects PAGEREF _Toc436728798 \h 289.1.4SAP Content Server PAGEREF _Toc436728799 \h 289.1.5SAP liveCache PAGEREF _Toc436728800 \h 289.1.6CTM Optimizer PAGEREF _Toc436728801 \h 289.1.7SAP Solution Manager PAGEREF _Toc436728802 \h 299.1.8SAP BI Java and Enterprise Portal PAGEREF _Toc436728803 \h 299.1.9SAP XI/PI PAGEREF _Toc436728804 \h 299.1.10SAP NetWeaver Gateway PAGEREF _Toc436728805 \h 299.1.11TREX PAGEREF _Toc436728806 \h 299.1.12MDM PAGEREF _Toc436728807 \h 2910Appendix: Recommended Resources & Links PAGEREF _Toc436728808 \h 30IntroductionThe 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.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.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 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,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:SAP NetWeaver on Microsoft Azure Virtual Machine Services - Deployment Guide DBMS Deployment Guide for SAP on Microsoft Azure Virtual Machine ServicesSAP NetWeaver: Building a Microsoft Azure–based Disaster Recovery SolutionClustering SAP ASCS Instance using Windows Server Failover Cluster on Azure with SIOS DataKeeperNote 1928533SAP Applications on Azure: Supported Products and Azure VM typesNote 2015553SAP on Microsoft Azure: Support PrerequisitesNote 1999351Enhanced Azure Monitoring for SAPNote 2178632Key Monitoring Metrics for SAP on Microsoft AzureNote 1409604 Virtualization on Windows: Enhanced MonitoringSizing 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: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 difficultTechnologies 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 realizedAd 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 requiredBecause 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:Not all Azure VM types are supported for running SAP applications. SAP requires a certain ratio of CPU to memory and other propertiesThe certified Azure VM types are documented in SAP Note 1928533SAP Applications on Azure: Supported Products and Azure VM types A detailed description of each VM is documented here: 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 SKUs. Review SAP Note 1612283 - Hardware Configuration Standards and Guidance for details on how to size SAP application servers 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.Database Management Systems (DBMS) Sizing on AzureThe performance of a DBMS is largely determined by four variables, assuming all other factors are held constant:Disk IO performance in terms of latency and volume throughputNetwork performance in terms of volume throughput and latencyAmount of physical RAM available for Data Buffers or CachesAggregate 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 ( ).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:CPU performance per thread (the individual performance of a single processor)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.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. 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.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 45,000 – 90,000Category 3 3-Tier Configuration SAPS between 90,000 – 150,000Category 4 3-Tier ConfigurationSAPS between 150,000 - 250,000Generic 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:Production systems (all except the very smallest systems)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 downIf the SAPS for a single SAP system exceeds about 20,000 SAPS 3-Tier configurations are generally recommendedIf the SAP system is required to be Highly Available, the system must be a 3-Tier designThe 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.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 SAPSSuitable for QAS systemsPremium Storage recommended for systems over 20,000 SAPS and for Production systemsCategory 2: 3-Tier Configuration, approximately 45,000 – 90,000 SAPS 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 SAPSPremium Storage (in combination with DS-Series VM) is generally recommended Category 3: 3-Tier Configuration, approximately 90,000 – 150,000 SAPS 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 SAPSPremium Storage (in combination with DS-Series VM) is generally recommended.? G-Series DB server VMs require Premium Storage Category 4: 3-Tier Configuration, approximately 150,000 - 250,000 SAPS 1 x GS5 VM DBMS Server: 42,000 SAPSBetween 5 - 10 x G4 or larger VM App Servers each with at least ?22,680 SAPSPremium Storage is required for G-Series DB servers.? 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.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 AccountAzure Premium Storage has the following specificationsThere are 3 Premium Storage Disk types: P10, P20 and P30 Premium Storage Disk TypeP10P20P30Disk size128 GB512 GB1024 GB (1 TB)IOPS per disk50023005000Throughput 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: 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 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.Dynamic ResizingThere are two main components of an SAP systems:SAP application serversDBMS SAP application servers are running different processes, mainly serving SAP users and SAP background processes.Increasing System Sizing 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:Configure SAP Load Balancing for Interactive (GUI) Logon, RFC, Batch, Update and PrintingDeploy 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: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 The total SAP application server resources is: 12 VMs * 1 application server instances * 50 work processes each = 600 work processes 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)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. As the workload increases, additional VMs startup automaticallyIn addition, add in the SAP AS instance profile following profile parameter into the default.pfl:Autostart = 1This 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 systemPicture SEQ Picture \* ARABIC 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 VMEnable Azure Autoscale in Azure for automatically scale out the SAP Application ServerPicture SEQ Picture \* ARABIC 2: Scale Out of SAP Application Server – End State after the scale outEnable Azure Auto scale in Azure for scale out of AS – for example on 70 % CPU threshold VM with SAP app server will start. 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:Stop the SAP Application ServerShutdown the Windows Operating SystemIn Azure Portal or PowerShell increase the VM SKU. For example, from D11 to D12Start the VMPicture SEQ Picture \* ARABIC 3: Scale Up of SAP Application Server - Initial StatePicture SEQ Picture \* ARABIC 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.Up-sizing of DBMS via scale upGenerally speaking, DBMS is a scale up scenario. Resources that are crucial for DBMS performance are:Disk IO performance in terms of latency and volume throughputNetwork performance in terms of volume throughput and latencyAmount of physical RAM available for Data Buffers or CachesAggregate CPU performance (the total combined performance of all of the processors)Up-sizing of standalone SAP DBMS VM Picture SEQ Picture \* ARABIC 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:Before you change the Azure VM DB size stop the SAP systemUse 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 systemIn 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. 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. Picture SEQ Picture \* ARABIC 6: Scale Up of RAM and CPU of clustered SAP DBMS Server – Initial StateA 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 canResize 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. Now we can execute DBMS failover to the already resized second cluster node VM Picture SEQ Picture \* ARABIC 7: resizing of passive cluster node and failover of DBMS cluster The DBMS is now running on resized VM. Picture SEQ Picture \* ARABIC 8: DBMS is scaled up and running on resized VMWe can now resize cluster node 1 VM as well, which is in passive cluster node. Picture SEQ Picture \* ARABIC 9: resizing of first cluster node 1 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. 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.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 SEQ Picture \* ARABIC 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.Picture SEQ Picture \* ARABIC 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. 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. Picture SEQ Picture \* ARABIC 12: Scale Down of SAP Application Server - Initial StateTherefore, it would make sense to reduce the size of SAP AS2 VM.Picture SEQ Picture \* ARABIC 13: Scale Down of SAP AS2 Application Server - End State 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. 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.Down-sizing of standalone SAP DBMS VM Picture SEQ Picture \* ARABIC 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:Before you change the Azure VM DB size stop the SAP systemUse 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 systemDown-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.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:Provision Azure resources such as VMs, network and storageUsing the SAP System Copy Guide perform a copy of the source systemsUpload backups and exports to Azure using AzCopyUsing the SAP System Copy Guide perform target system installationPerform post processingUse SAP systems for project, demo, testing or upgrade testingAfter 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.Special Considerations for Very Large SAP Systems on AzureWhen 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.TermMeaning ExampleLimiting Factor on Sizing SAP DB Server InstanceSAPS value for a DB server dedicated for only one SAP ComponentTypically 10%-20% of the total Component SAPSYesSAP App Server InstanceSAPS value of the APP server(s) for one SAP ComponentTypically 80%-90% of the total Component SAPS No, SAP application server tier can scale out horizontally very effectively by adding addition serversSAP ComponentSAP Software Solution SAP ECC 6.0, SAP BI, SAP PI, Content Server, LiveCache, BWA YesSAP “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 limitsSAP EnvironmentAll 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 ComponentsSAP Landscape All SAP Environments and all auxiliary support systems such as SAP Router, Firewalls, non-SAP utilities such as Automated Testing/Load Generation toolsNo, there is no theoretical limit on how large an Landscape can be as an Landscape can be made up of many SAP Components and EnvironmentsWhen 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. 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:Premium Storage is recommended for most customers with systems larger than 20,000 SAPS or DB sizes larger than 500GB (compressed DB size) Transaction Logs should be on their own dedicated Premium Storage diskUse Windows Storage Spaces or Linux MDADM to increase the IO and throughput for database files 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 IOWindows Storage Spaces or Linux MDADM can be used to aggregate multiple disks into one large volume 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) 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 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: World Record SAP Sales and Distribution Standard Application Benchmark for SAP cloud deployments released using Azure IaaS VMsApplication 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:SAP application servers scale out exceptionally well and near linear scalability is seen in test conditionsThe 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 instanceIt is therefore recommended to create many application servers each with 40-50 work processes. You’ll need to configure PHYS_MEMSIZE, if required. Autoscale can be used to automatically increase the number of application servers under peak loadSAP application servers do not benefit from or require Premium StorageDo not use SAP application servers as file or print servers, even for the SAP application itself. These functions should be performed by dedicated serversHigh 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:Database layer: DBMS level replication technologies such as SQL Server AlwaysOn or Oracle DataGuard are recommendedSAP Single Points of Failure – SAP ASCS: review the latest SAP on Azure documentationSAP Application Server: this layer is not a SPOF and therefore should be protected by simply having multiple SAP application serversNetwork 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 riskDisaster 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)Comment, FeedbackIf you have comments, feedback on Azure sizing for large systems please contact Microsoft at this email address:saponazuresizing@ SAP on Azure Benchmarks & Sizing GuidanceThe latest available SAP Benchmarks for both 2-Tier and 3-Tier systems are always published here: addition, the benchmarks and certified SAP VM types are also listed in SAP Note 1928533SAP 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 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 TypeVM SizeSAPS Certification Link & Full Disclosure A52 CPU, 14 GB12,000A64 CPU, 28 GB25,000A78 CPU, 56 GB50,000GS12 CPU, 28 GB38,4152015042GS24 CPU, 56 GB78,6202015043GS38 CPU, 112 GB137,5202015044GS416 CPU, 224 GB247,88020150452-Tier SAP Certified Benchmarks The Azure GS5 VM has benchmarked more than 40,000 SAPS in 2-Tier configuration. VM TypeVM SizeSAPS Certification Link & Full Disclosure A52 CPU, 14 GB1,500A64 CPU, 28 GB3,000A78 CPU, 56 GB6,000A8/A108 CPU, 56 GB11,000A9/A1116 CPU, 112 GB22,0002014039D11/DS112 CPU, 14 GB2,325D12/DS124 CPU, 28 GB4,650D13/DS138 CPU, 56 GB9,3002014039D14/DS1416 CPU, 112 GB18,6002014040GS12 CPU, 28 GB3,5802015046GS24 CPU, 56 GB6,9002015047GS38 CPU, 112 GB11,8702015048GS416 CPU, 224 GB22,6802015049GS532 CPU, 448 GB41,6702015038General 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 Common SAP Components 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 VMsSAP Application Server VMs:SAP Basis 7.0 to 7.31 (Kernel 7.22 based) a single SAP application server can run on a D11 or larger VMSAP 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 systemsSAP 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 VMsSAP Business ObjectsSAP Business Objects: Most customers deploy the DBMS layer on D12 and the CMS runs on D11 or D12SAP 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.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.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 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.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.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.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.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 wellMDMThe 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-AZRAppendix: 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 ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download