![\"Microsoft](\"https:\/\/www.microsoft.com\/insidetrack\/blog\/uploads\/prod\/2021\/10\/ms-digital-technical-stories-300x112.png\")
At Microsoft, we use SAP enterprise resource management software to run our mission-critical business functions like finance and human resources.<\/p>\nAt Microsoft, we use SAP enterprise resource management software to run our mission-critical business functions like finance and human resources.<\/p>\n
In an on-premises model, physical computing resources are costly and may go unused. But by moving our SAP systems to Microsoft Azure, we avoid maintaining unused resources\u2014we scale our systems up and down for current and short-term needs. By doing this, we\u2019ve fine-tuned our capacity management processes for lower costs, and more agility, scalability, and flexibility.<\/p>\n
Like many enterprises, our company uses SAP\u2014the enterprise resource planning (ERP) software solution\u2014to run\u00a0most of\u00a0our business operations. We\u2019re running SAP on Microsoft Azure, the preferred platform for SAP and the optimal platform for digital transformation.<\/p>\n
We\u2019ve optimized our SAP on Microsoft Azure environment to gain business and operational benefits that make our SAP instance agile, efficient, and able to grow and change with our business needs.<\/p>\n
Optimizing our Microsoft Azure environment has allowed us to:<\/p>\n
As of 2018, Microsoft\u2019s instance of SAP is 100 percent migrated to Microsoft Azure.<\/a> By optimizing SAP on Azure, we\u2019re positioning our SAP environment to grow and change with our business needs. Additionally, we\u2019re positioned to lead our digital transformation and empower everyone in our organization to achieve more. Azure makes SAP better.<\/p>\n [Discover how we\u2019re protecting Microsoft\u2019s SAP workload with Microsoft Sentinel<\/a>. | Learn how Microsoft moved its SAP workload to the cloud<\/a>. | Find out how we\u2019re transforming how we monitor our SAP instance with Microsoft Azure<\/a>.]<\/em><\/p>\n Each SAP system or app in our overall SAP landscape uses servers and hardware, computing resources (like CPU and memory), and storage resources. Each system also has separate environments, like sandbox and production. The resources required to run SAP can be costly in an on-premises model, where you have physical or virtualized servers that often go unused.<\/p>\n Consider a typical on-premises system.<\/p>\n The IT industry often sizes on-premises servers and storage infrastructure for the next three to five years, based on the expected maximum utilization and workload during the life span of an asset. But often, the full capacity of the hardware isn\u2019t used outside of peak periods\u2014or isn\u2019t needed at all. Maintaining these\u00a0on-premises\u00a0systems is costly.<\/p>\n With Microsoft Azure, we avoid infrastructure underutilization and overprovisioning. We quickly and easily scale up and scale down our SAP systems for current and short-term needs, not for maximum load over the next three to five years.<\/p>\n By\u00a0managing capacity\u00a0and sizing our SAP systems\u00a0on\u00a0Microsoft Azure, we\u2019ve experienced improvements in several areas:<\/p>\n Optimizing involves calculating our hardware requirements like CPU resources, storage space, memory, input\/output (I\/O), and network bandwidth.<\/p>\n When we optimize, we size for today. We assess our infrastructure, resources, and costs, and then size our systems as small as possible. We also ensure that sufficient space to run business processes without causing performance issues during expected events like product releases or quarterly financial reporting.<\/p>\n This capability provides us with the ability to optimize our storage and computing power, giving us flexibility and on-demand agility.<\/p>\n Sizing is an ongoing task because your load, business requirements, and behavior patterns can change at any time. The following are some considerations and tips, based on the process that we use:<\/p>\n We used two common strategies for sizing SAP systems, each in a different way and at different points in the optimization process.<\/p>\n We used the SAP Quick Sizer at the start of our optimization process because it had a simple, web-based interface and it allowed us to prepare our sizing strategies from the start.<\/p>\n We used reference sizing\u00a0later, after we determined some context around our virtual-machine sizing and could provide virtual machines in Microsoft Azure for reference.<\/p>\n If you don\u2019t yet have systems or workloads in Microsoft Azure, start with SAP Quick Sizer\u2014it\u2019s an online app that guides you on sizing requirements, based on your business needs.<\/p>\n Quick Sizer is helpful for capacity and budget planning. The app has a questionnaire where you indicate the number of SAP users, how many transactions you expect, and other details.<\/p>\n The SAP system\u00a0recommends a number for the SAP Application Performance Standard (SAPS), a measurement of processing requirements\u00a0that you need, such as for a database server.<\/p>\n If the recommended number is 80,000, you\u00a0need to leverage\u00a0servers with SAPS that add up to 80,000.<\/p>\n You can find more information about SAPS for Azure virtual machines in\u00a0SAP Note #1928533 SAP Applications on Azure: Supported Products and Azure VM types\u00a0(SAP logon required).<\/a><\/p>\n You should keep a few considerations in mind when you\u2019re using SAP Quick Sizer.<\/p>\n There can be customization and variations of SAP systems, depending on business processes, which could change system behavior. Or you might have capabilities enabled for new SAP deployments or custom code for which no Quick Sizer exists.<\/p>\n Also, in the past, hardware vendors guided customers on the servers that they needed and how to install them. With Azure, customers make their own decisions\u2014for example, how to grow storage as data volume grows, or how to adjust CPU compute resources.<\/p>\n After systems\u00a0are live\u00a0in Microsoft Azure, reference sizing is the recommended method. With this approach, you\u00a0need to\u00a0look at the performance of systems you\u2019ve already moved to Azure that\u00a0have a\u00a0similar\u00a0load\u00a0to the systems that you want to move.<\/p>\n This comparison helps you estimate your sizing requirements\u00a0accurately.\u00a0For example, if\u00a0you have an on-premises system that you want to move to Microsoft Azure, and it\u2019s three times larger than one of the systems that you already have on Azure, adjust the sizing based on systems you\u2019ve already deployed in Azure, and then deploy the new system.<\/p>\n If it turns out that your estimate wasn\u2019t accurate, it\u2019s much easier and quicker to adjust CPU and memory resources in Microsoft Azure\u00a0than\u00a0on-premises,\u00a0by\u00a0switching to\u00a0a different virtual machine size. Adjusting the database on-premises is more difficult because you might need to buy servers with more CPU and memory.<\/p>\n For on-premises, you\u00a0must\u00a0look at what you have, add a buffer, and consider the additional load that you\u2019ll have in the next few years.<\/p>\n When we integrate SAP with Windows Server and SQL Server, our main considerations are cost of ownership and low complexity. When you plan your integration and reference architecture, make sure that the technical landscape is easy and cost effective. With business-critical systems, it\u2019s difficult to scale when you have an architecture whose maintenance requires highly skilled individuals, or when there are emergencies where you need business continuity.<\/p>\n For easy administration and operations, we use the same app design in all SAP production systems. We only adjust VM sizes and\u00a0numbers based on the system-specific\u00a0requirements.<\/p>\n Also, to avoid issues for customers who run SAP workloads on Azure, Microsoft certifies only certain Microsoft Azure VM types. These VMs must meet memory, CPU, and ratio requirements, and they must support defined throughputs. To learn more about Azure\u00a0VM types certified for SAP, review\u00a0SAP certifications and confi<\/a>g<\/a>urations runnin<\/a>g\u00a0<\/a>on Microsoft Azure<\/a>.<\/a><\/p>\n The graphic below shows\u00a0the Microsoft\u00a0SAP ERP\/ECC production system in Microsoft Azure. By moving to Azure, we\u2019ve gained agility and scalability on the SAP Application layer.<\/p>\n We can scale\u00a0the SAP Application layer\u00a0up and down by increasing and decreasing the size and number of the VMs. The design and architecture have high-availability measures against single points of failure.<\/p>\n So, if we need to update Windows Server or Microsoft SQL Server, perform infrastructure maintenance, or make other system changes, it doesn\u2019t require much,\u00a0if any,\u00a0downtime. We implement infrastructure in Azure for our production systems with standard SAP, SQL Server,\u00a0SAP HANA, Windows Server, and SUSE Linux high-availability features.<\/p>\n To ensure high availability, we are leveraging Microsoft Azure Availability Zones: We distribute our VMs in multiple zones. The graphic above includes an example of how we use Azure Availability Zones. If a problem arises in one zone, the system is still available.<\/p>\n All single points of failure are secured with clustering: Windows Server Failover Cluster for the Windows operating system and Pacemaker cluster for SUSE Linux. For databases, we use SQL Server Always On and SAP HANA System Replication (HSR). The databases are configured for a synchronous commit on both local HA nodes (no data loss occurs, and automatic failover is\u00a0possible) and an asynchronous commit to the remote disaster recovery node.\u00a0If an issue arises with the main database server, SAP will automatically reconnect to the local high availability node.<\/p>\n Because we can use the secondary database, we can upgrade software and SQL Server, roll back to previous releases, and do automatic failovers with no or minimal risk.<\/p>\n For scalability and high availability of the SAP application layer, multiple SAP app server instances are assigned to SAP redundancy features such as logon groups and batch server groups. Those app server instances are configured on different Microsoft Azure virtual machines to ensure high availability. SAP automatically dispatches the workload to multiple app-server instances per the group definitions. If an app server instance isn\u2019t available, business processes can still run via other SAP app server instances that are part of the same group.<\/p>\n The scale-out logic of SAP app server instances is also used for rolling maintenance. We remove one virtual machine, and the SAP app server instances running on it, from the SAP system without affecting production. After we finish our work, we add back the virtual machine, and the SAP system automatically uses the instances again. If high load occurs and we need to scale out, we add\u00a0additional\u00a0virtual machines to our SAP systems.<\/p>\n To ensure that\u00a0VM\u00a0costs are managed, we\u2019ve established new policies for\u00a0nonproduction SAP\u00a0systems:\u00a0Default setting for a system is that\u2019s\u00a0unavailable. Users can start systems on demand by using a\u00a0snooze\u00a0application build on top of Microsoft Power Apps.<\/p>\n The system will be available for 12 hours and then automatically shut down\u00a0again unless\u00a0the availability time was extended.\u00a0Additionally, systems that are used regularly are\u00a0assigned\u00a0to a fixed availability schedule. For example, the schedule might be:\u00a0Systems\u00a0will be shut down Friday evening and started again on Monday morning\u00a0without user interaction.\u00a0In the event that the system is needed over the weekend, users can start the system\u00a0by using the snooze application<\/a>.<\/p>\n Moving SAP systems to Microsoft Azure enabled\u00a0easy integration with various Microsoft Azure Monitor services for\u00a0enhanced telemetry and monitoring.\u00a0We approached\u00a0telemetry by using a\u00a0multilayer concept:\u00a01) SAP Business Process layer, 2) SAP Application Foundational layer, 3) SAP Infrastructure layer, and 4) SAP Surrounding API layer.<\/p>\n Microsoft Azure\u00a0Log Analytics\u00a0offers many standard metrics for the\u00a0SAP Infrastructure layer,\u00a0and it\u2019s easy to integrate\u00a0with\u00a0SAP\u00a0to collect custom metrics from\u00a0the Application Foundational layer.<\/p>\n Implementing telemetry for the SAP business process and API layers is relatively challenging because doing so requires\u00a0custom development. We use\u00a0tools in the\u00a0ABAP SDK<\/a>\u00a0to integrate and export data from SAP to\u00a0Microsoft Azure Monitor Application Insights.<\/p>\n Learn more about end-to-end telemetry for SAP on Microsoft Azure<\/a> and find out additional information about how Microsoft\u2019s internal SAP workload has received a telemetry boost from Microsoft Azure<\/a>.<\/p>\n We keep learning and iterating as we optimize SAP for Microsoft Azure in our environment. Here are some important lessons that we\u2019ve learned:<\/p>\n We\u2019re excited about the decreased costs and increased agility that we\u2019ve experienced so far in optimizing SAP for Microsoft Azure. In the future, we plan to share more lessons that we learn as we move forward with post-migration improvements.<\/p>\n For information on designing a migration initiative, review Strategies for migrating SAP systems to Microsoft Azure<\/a>. Our future plans include:<\/p>\n At Microsoft, we use SAP enterprise resource management software to run our mission-critical business functions like finance and human resources. In an on-premises model, physical computing resources are costly and may go unused. But by moving our SAP systems to Microsoft Azure, we avoid maintaining unused resources\u2014we scale our systems up and down for current […]<\/p>\n","protected":false},"author":133,"featured_media":11702,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"_hide_featured_on_single":false,"_show_featured_caption_on_single":true,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false},"version":2}},"categories":[1],"tags":[115,188,95],"coauthors":[646],"class_list":["post-8948","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized","tag-microsoft-azure","tag-sap","tag-security","program-microsoft-digital-technical-stories","m-blog-post"],"jetpack_publicize_connections":[],"yoast_head":"\nSAP at Microsoft<\/h2>\n
Capacity management offers a boost<\/h2>\n
\n
What does optimizing involve?<\/h2>\n
Tips for sizing<\/h2>\n
\n
It\u2019s easy to add capacity later\u00a0and\u00a0resize before business processes change or before new processes go live in the environment. Autoscaling up and out brings additional\u00a0benefits because\u00a0it\u2019s an automatic response to current conditions and usage patterns.<\/div>\nDesigning for easy scale-up also includes configuring the SAP HANA database and the SAP instances to dynamically adjust\u00a0the\u00a0amount of memory used or number of work processes depending on available resources in the virtual machine (VM).\u00a0Keep the instance design simple: One SAP instance per VM.<\/div>\n<\/li>\nHere is an example of\u00a0how we\u2019re using this feature:\u00a0For our archiving system, we used Microsoft Azure Standard Storage and small virtual machines. When we loaded data into the system, we temporarily doubled the memory and CPU, and added Microsoft Azure Premium Storage for log file drives in the database.<\/div>\nTo save costs, after we loaded the data, we made the virtual machine smaller again and removed the premium storage drives.<\/div>\n<\/li>\nAlso consider identifying test systems and potentially even some production systems for snoozing. Create a snooze schedule and provide key personnel with the ability to un-snooze systems on demand.<\/div>\nIf you have a separate business-continuity system and you snooze hardware for it, you pay only for storage, not for compute consumption. Also, consider using the smallest size feasible. If there\u2019s a disaster, resize to a bigger size before you start the production system, such as the database server, for business continuity.<\/div>\n<\/li>\nStrategies for sizing SAP systems<\/h2>\n
SAP Quick Sizer<\/h3>\n
Reference sizing<\/h3>\n
Technical considerations<\/h2>\n
Technical implementation and technical capabilities<\/h2>\n
![\"Illustration](\"https:\/\/www.microsoft.com\/insidetrack\/blog\/uploads\/prod\/2023\/05\/8241-SAP-BW-HANA-production-system.png\")
High availability and scalability<\/h3>\n
Rolling maintenance<\/h3>\n
Automated shutdown of\u00a0SAP systems<\/h3>\n
Telemetry and monitoring using Microsoft Azure Monitor<\/h3>\n
![\"Key](\"https:\/\/www.microsoft.com\/insidetrack\/blog\/uploads\/prod\/2021\/10\/key-takeaways-300x74.png\")
<\/h2>\n\n
\n
\n
![\"Related](\"https:\/\/www.microsoft.com\/insidetrack\/blog\/uploads\/prod\/2021\/10\/related_links-300x81.png\")
<\/p>\n\n