SAP on Azure: Top 10 FAQs about snoozing (part-time running)
Cloud computing, such as SAP on Azure, offers incredible flexibility; pay for only what you need and nothing else. So why not shut down your SAP systems, or parts of them, when you are not using them? Some call it snoozing, others part-time running. You can even go as far as auto-scaling if you have several application servers with varying load. Almost every SAP customer talks about doing this before moving to the cloud. However, SAP Azure snoozing is not quite as simple as it seems.
In this blog post, Robert MacDonald – Innovation and Technology Manager at Absoft, answers the 10 most frequently asked questions about snoozing:
- Does SAP on Azure snoozing make financial sense?
- Do I save all the Azure consumption costs associated with an SAP system by snoozing?
- What about on-demand without a schedule?
- Can I snooze part of an SAP system, or respond dynamically to user load?
- Is there any risk my SAP system won’t come back?
- Will part-time running cause any stability problems or data corruption?
- Will part-time running have any functional consequences?
- Background jobs usually run at night in our system, what happens to those if it is offline?
- Can you use part-time running with SAP BW?
- What about backups, when do they run?
- How do you actually do part time running of SAP in Azure?
Does SAP on Azure snoozing make financial sense?
There are different ways to pay for Virtual Machines in Azure. Pay-as-you-go (PAYG) is default. An hourly price is billed for every hour a Virtual Machine is running. Alternatively, a reserved instance (RI) needs a commitment for one year or three years, that is paid monthly or in advance.
A one-year RI commitment can save around 40% over the PAYG price, and on a three-year commitment the savings are over 60%. Reserved instances are priced for 24/7 operation of a virtual machine size for the entire term. If there is no machine running, nothing is saved.
So, part time running only saves cost with PAYG. Understanding if part-time running PAYG is better than RI is simple. If you snooze less than 40% of the time, it is cheaper to reserve for one year. Even if snoozing up to 60% of the time, it is still cheaper to reserve for three years.
If the machine is running more than about sixty hours a week, it is cheaper to reserve it for three years. Sixty hours a week might mean 6.30am till 6.30pm every week-day. That covers one time zone, but an overseas office or support partner will soon extend the necessary running hours.
Do I save all the Azure consumption costs associated with an SAP system by snoozing?
No. Azure charges for running a Virtual Machine and for storage and backups. Costs are saved when a PAYG Virtual Machine is shut down. On the other hand, storage and backup costs continue. Often, less than half the hourly Azure consumption for an SAP system is saved by snoozing.
If the SAP system is seldom used, automation can move the deployed resources to more cost-effective storage when not in use. This saves greater proportion of the cost. At Absoft we use Ansible to deploy SAP systems from a backup stored in cost-effective Azure Blob Storage.
Redeploying is a step beyond SAP Azure snoozing. It is more comparable to putting an archive copy of the SAP system into cold storage. Typically, it takes a few hours to fully rebuild an SAP system from a cold-storage backup (when fully automated). In comparison, it only a few minutes to start a snoozed system.
What about on-demand without a schedule?
For very quiet systems it is often best to let the users request the machine comes online when needed, without any set schedule. On-demand saves far more than scheduled running and is often more convenient, too.
You must manage the budget if users start it up more than expected. Additionally, housekeeping and backups must run with a frequency that matches how the system is being used. This potentially means delaying a shutdown for a backup to finish.
On-demand running needs a good user interface that is secure and robust for the end-users. The user interface can be the trickiest part to deliver.
Can I snooze part of an SAP system, or respond dynamically to user load?
Cost-saving comes from shutting down and deallocating a Virtual Machine in Azure. This means usually an entire SAP system is snoozed. Auto-scaling is starting and stopping individual application servers.
Auto-scaling is the holy grail of cloud flexibility, and it can be done with SAP on Azure with some important caveats. There must be high user load to have multiple application servers in the first place. If the SAP system currently runs on one server, auto-scaling will not work without resizing and a new architecture, if at all.
There must also be significant variation in load. A sufficiently large spike is required by at least one entire server more than baseline. That spike must last less than 40% of the total time to stay below the cost of reserving the instances.
Some SAP landscapes do have a suitable load pattern. Amongst our customers we have an exam board with five thousand temporary markers who log in to download their payslip on the same day each year. Another manufactures greetings cards, with somewhat of a seasonal peak around Christmas.
At Absoft we use Avantra to give us real-time insight into the SAP systems we support, and trigger automations for self-healing and automated support activities. We can trigger the start-up of an application server based on load metrics, then later trigger the removal as the load decreases.
For a truly cloud native experience, you should scale without having a server already built. By using an automated deployment of an application server using Ansible and triggering deployment from load monitoring, we can auto-scale without any snoozed resources or storage cost.
Is there any risk my SAP system won’t come back?
Yes! Temporarily at least. Azure is well-resourced. However, cases of shortages of specific virtual machines happen. You may find capacity does not exist to start your machine at the time you need it.
Thankfully, the phenomenon is very rare. Inevitably it makes the mainstream news when it does happen, as it did in early 2020 after the sudden shift to online working. It is normally possible to work round it by switching to a different virtual machine family temporarily, or using a different region.
At Absoft we have had multiple customers using part-time running on multiple SAP systems. This includes the UK South and North Europe, with HANA and non-HANA databases, and we have never seen one fail to start due to Azure capacity issues.
Will part-time running cause any stability problems or data corruption?
No, but you need to do more than shutting down the Virtual Machine in Azure to keep your SAP system safe. It is vital to stop and start the SAP software and database cleanly first to avoid risks of data corruption or other problems.
An automation tool that shuts down SAP and the database in the correct order, before connecting to Azure to shut down the Azure virtual machine is the best way to handle this.
Will part-time running have any functional consequences?
It is possible for part-time running such as SAP Azure snoozing to impact functionality. This is not usually done in production landscapes, so any impact should be considered with respect to testing and development work.
Dependencies between interconnected products can cause issues. For example, SRM often doesn’t run properly if not connected to ERP. A Gateway, PI or BW system might be partially disabled if S/4HANA or ERP is down.
You need to consider what must logically be up together, started and stopped in the correct order, and build groups of systems to start and stop as a unit.
Background jobs usually run at night in our system, what happens to those if it is offline?
Background jobs in SAP are often configured with a ‘No Start After’ time that will prevent jobs from starting if they were due to run whilst SAP was offline. Any job that is running when the system is shutdown will be cancelled. Changing background job schedules is a vital part of safely snoozing SAP systems.
Before we set up any part-time running for a customer landscape at Absoft, we review job schedules carefully. Any jobs scheduled are checked so that they either run when the system comes online, or on a schedule for when it is online. Function and technical teams must collaborate for this to be trouble-free.
Can you use part-time running with SAP BW?
Yes, but data loads can be a challenge. It is not unusual to see twelve-hour runtimes on BW data loads which is impossible if the system is not even online for that long.
Sometimes the cost-saving from part-time running creates a business case for optimising BW data loads. Our development team have delivered some incredible improvements by analysing the performance of custom extractors and recommending improvements. This includes the source system or in BW itself.
In a worst case, with any optimisation avenues exhausted, BW and any source systems may not be suitable candidates for part-time running.  Development systems that run part-time whilst quality assurances runs in reserved instances so data loads can be tested, is not uncommon.
What about backups, when do they run?
Part time running creates opportunities for backups. If SAP is cleanly shutdown each day and the Virtual Machine stopped in Azure, you can make a very clean snapshot with Azure Backup for Virtual Machines.
Part time running could allow Azure Backup to be the only backup solution in use. So, you can add database backup licensing to the list of cost savings, subject to appropriate testing.
Any kind of traditional database backup will need to run whilst the system is online. Scheduling is important and optimising for runtime might be needed.
Every SAP system database I’ve seen in Azure has been able to back up at a rate of 3 hours per terabyte, and usually a lot faster. Look to optimise with parallelism and an end-to-end evaluation of the configuration.
So how do you actually do part time running of SAP in Azure?
You need to connect to a lot of things. It is vital to stop and start the SAP software and database cleanly to avoid data corruption or other problems. To realize any cost saving, the Virtual Machine must have a deallocated status in Azure, which means you need to connect to Azure APIs too.
The user interface for triggering the stop and start must be secure, and any scheduling reliable. My own first attempts at rolling my own snoozing system revealed a potentially expensive problem. If the automation fails, the machine could run longer than expected and run up a significant bill. A snoozing system is a safety critical device from a Finance Director’s perspective.
To make a part-time SAP system that is safe, robust and delivers a cost-saving, requirements to consider are:
- Connecting to SAP to start and stop cleanly
- Connecting to the database to start and stop it cleanly
- A user interface that is flexible, secure and intuitive
- Connecting to Azure to deallocate the Virtual Machine and realise a cost-saving
- Monitor that backups and any other important maintenance activities are running
- Monitor the machine is not online more than expected
- Track usage of the virtual machine against budget
A scripting language of choice is usually the first port of call, with integration to the SAPControl webservices. Ideally you could integrate with some existing monitoring software. Microsoft have published some example code for a PowerApp too.
Â
Absoft and SAP on Azure: A holistic approach
As with any successful initiative, the technicalities are not the entire story. Agreeing requirements that deliver a cost saving is a cross-functional exercise. All involved must understand the implications on functionality.
Building robust automation for SAP in Azure needs a lot of work. I know this from experience. I’ve been lucky to be able to work on this at scale with return on my efforts. A number of customers and SAP systems have seen improvement. Additionally, our excellent partners in Microsoft and Avantra have been key in achieving this.
Today, Absoft provides fully monitored and managed on-demand stop and start to our managed service customers as standard. We have invested in the tools and processes that meet all the requirements.Â
[View our solution brief here to learn more about our SAP Managed Service offering]
It’s fantastic delivering an instant bottom-line saving on Azure consumption from day one of a new service starting. It hasn’t surprised me that the SAP on Azure Stop/Start capability has been one of the most well-used and popular features of our managed service support product.
