“Adopt, adapt and become adept at optimising your cloud investment”
Hosting SAP workloads on Microsoft Azure has accelerated over the past three years as companies look to reduce cost of ownership of IT systems and increase flexibility, efficiency and run as lean as possible.
Whilst the cost of hosting with any public cloud provider will generally be less than hosting on-premises, we still need to keep a watchful eye on the incurred costs to ensure we’re not over-spending, and are living up to the expectations of the business case that was initially put forward to our peers.
This article summarises the important aspects and shows how these capabilities could be supplemented with Azure Automation and/or SAP Landscape Management cloud connectivity and automation.
For an SAP on Azure deployment, note 1928533 provides comprehensive details of the SAP supported products and VM types. The components that influence the pricing of the solution generally boil down to:
- Virtual Machines (VM)
- Data Ingress & Egress
Pay As You Go (PAYG)
There are a number of factors affecting how Microsoft charge their customers for consuming the various cloud resources, the majority of which are based on the “Pay as You Go” (PAYG) model; you only pay for what you consume, in the same way we pay for our electricity, for example.
In this model, virtual machines are charged per “running” minute. By this we mean, the VM has been “allocated” resources (CPU/RAM) and is ready for the host operating system to be booted. If the host operating system were to never boot, we would still be charged as the VM is “allocated”. Consequently, when we shut down the operating system and have no intention to restart it, we need to “deallocate” the VM to stop being charged for consuming the associated CPU/RAM.
If we’re not diligent, this can result in high consumption charges for some of the larger M-Series VMs that are required to support SAP HANA, for example. We need to be mindful of this and look to deallocate VMs when no longer required.
Purchasing Azure Reserved Instances (RI) help you save money on your compute spend by committing to a one-year or three-year plan. This commitment allows you to have discounted prices on the resources you use. Using RI can significantly reduce compute costs by up to 72% on pay-as-you-go prices and you can pay for a reservation up-front or monthly to spread the cost.
RI is probably going to work out cost-effective for production systems that most likely have a requirement to be available 24×7 for the majority of the year. But what about non-production systems? SAP projects by their nature tend to have peaks and troughs in the usage of the various non-production environments. For example, testing cycles might occur infrequently and only at strategic times in a project life cycle. It would therefore make sense to shut down the involved SAP systems and deallocate the hosting VMs to reduce Azure spend.
There comes a point where PAYG is more cost-effective than RI. A very quick ROM analysis of a typical D8v3-series VM used to host an SAP application server shows how reducing the uptime of the VM from 24 hours per day per month, to 16 hours per day on weekdays only, makes PAYG more attractive.
Once your SAP workload has been operating in Azure for a period that encapsulates all of your business processes, it would be advisable to gather as much information regarding resource consumption of the virtual machines in your SAP estate to see if there are opportunities to adjust the VM type.
For example, based on your sizing exercise and resulting SAPS requirement, you deployed a VM type with 8 vCPUs and 32GB RAM (e.g. D8s_v3) for a number of SAP instances. Over time, you notice the actual CPU usage falls below the predicted requirement but wish to keep the assigned SAP memory the same. In this case, you could choose to change the VM type to one with 4 vCPUs and 32GB RAM (e.g. E4as_v4) and take advantage of a lower consumption cost, currently equating to around 25% saving (for a UK South deployment).
Selective Disk Backup Support on Azure Backups
One of our customers had been taking daily Azure VM backups to the Azure Backup vault. This included VMs that hosted database systems, whose data was being backed-up using database methods, thus causing duplication and higher than expected costs.
Until recently, Azure Backup only supported backing up all the disks in a VM together using the Azure VM backup solution; there was no possibility to exclude certain disks, e.g. the database data and log disks.
In late January 2020, Microsoft announced selective disk backup support for Azure Backup, specifically to address this – https://azure.microsoft.com/is-is/updates/excludediskpreview/.
We have included the excluded disk functionality on a recent SAP on Azure migration project resulting in substantial backup storage savings.
The Azure Advisor is a personalised service that continuously collects data to help you follow best practices to optimize your Azure deployments. Recommendations should be reviewed on a regular basis because there may be a cost saving opportunity presented – one that you may not have considered. For example, if a VM is over-sized or under-utilised, why not consider changing the VM type as discussed above in “VM Right-Sizing”?
Here is an example of the recommendations presented by the Azure Advisor (with sensitive cost saving data redacted):
Of the above, the first recommendation is yielding the biggest saving – buy virtual machine reserved instances, which we discussed further previously in the section above, but in essence, listen to the advisor!
A comprehensive overview of the Microsoft Azure Advisor is available in the Microsoft Documentation – https://docs.microsoft.com/en-us/azure/advisor/advisor-overview.
SAP Landscape Management Scheduling
With the SAP Landscape Management (LaMa) tool, it’s possible to perform operations, such as stop and start, on various elements in your SAP estate – e.g. instances, databases, hosts and custom instances. It is also possible to schedule (automate) these operations at times when your technical teams are not working – e.g. out of working hours and weekends.
With the introduction of SAP LaMa 3.0, SAP introduced cloud connectivity to public cloud providers through “Cloud Manager” definitions. One of the supported Cloud Managers from SAP is Microsoft Azure. The setup of which is described in note 2343511 – Microsoft Azure connector for SAP Landscape Management (LaMa).
Of the supported operations included with this cloud connectivity, we have the ability to activate (allocate) and deactivate (deallocate) Azure virtual machines, and include these operations into a LaMa schedule. As previously mentioned, a virtual machine that is deallocated incurs no compute cost. Therefore, including a power-off of the virtual machine hosting SAP into a shutdown schedule, will reduce the virtual machine running costs. This is very attractive option for non-production systems.
SAP Landscape Management Shutdown including Storage Savings
With SAP Landscape Management 3.0 SP11, SAP introduced an additional option on the “Cloud Managers” configuration – “Change Storage Type to save costs”. This enables you to save costs by changing the storage type of from Managed Disks to “Standard” whilst the VM is deallocated.
Not only will you save on compute whilst VMs are deallocated, but the storage costs of disks attached to the deallocated VMs is switched from “Premium” to “Standard”; a further operating cost is realised. This may not be a huge saving but every little counts – for example, in the West Europe region, the cost of a Standard SSD disks (E-series) is approximately 50% cheaper than the equivalent Premium SSD disk (P-series).
Azure Automation for SAP
If you don’t own an SAP Landscape Management Enterprise Edition license, you now have the option to use Azure Automation to automate the stop/start of SAP systems. By deploying a series of Powershell Scripts and Automation Runbooks, you can manage when your SAP systems and hosting VMs are running to control your Pay-As-You-Go consumption costs.
Whilst hosting SAP workload in Azure is a very interesting and attractive, once you’re there you need to be mindful of the ongoing costs and look to achieve further savings with the tools, experience and information that’s out there. This is something we now offer in our new “SAP on Azure: Run” service.