Overview
We are happy to share with the SAP on Azure community a concept to automate your SAP system start / stop in Azure.
This concept as introduced in this blog has all the necessary parts (including PaaS Azure automation runtime environment, scripts, and runbooks, tagging process etc.) in a public GitHub repository that enables you to adapt functionality like:
- Start / Stop your SAP systems, DBMSs, and VMs.
- SAP application servers
- If you use managed disks (Premium and Standard), you can decide to convert them to Standard during the stop procedure, and to Premium during the start procedure.
This way you achieve cost savings both on the compute and on the storage side!
SAP systems stop and SAP application servers stop is specially designed for a graceful shutdown, allowing SAP users and batch jobs to finish. This way you can minimize the SAP system or the SAP application server’s downtime impact. The approach is similar on the DBMS side.
To further enhance the user experience, you can consume this functionality using a cool SAP Azure Power App . For more information you can check a great blog of Martin Pankraz - Hey, SAP Systems! My PowerApp says Freeze! But only if you’re done yet .
This solution is the product of a joint effort of the SAP on Azure CAT Team (Cloud Advisory Team) andthe SAP on Azure FastTrack Team (Robert Biro and Martin Pankraz).
Solution Capabilities
In details, with this solution you can do the following:
- Start / Stop a complete SAP NetWeaver Central System on Linux or Windows, and the VM.
The typical scenario here is a non prod SAP systems. - Start / Stop of a complete SAP NetWeaver Distributed System on Linux or Windows and VMs.
The typical scenario here is a non prod SAP systems.
Here you have:- One DBMS VM (HA is currently not implemented)
- One ASCS/SCS or DVEBMGS VM (HA is currently not implemented)
- One or more SAP application servers
- It is assumed that SAPMNT file share is located on SAP ASCS or DVEBMGS VM.
- In a distributed SAP landscape, you can deploy your SAP instances across multiple VMs, and those VMs can be placed in different Azure resources groups.
- In a distributed SAP landscape, the SAP application instances (application server and SAP ASCS/SCS instance) can be on Windows and DBMS on Linux (this is so called heterogenous landscape), for DBMS that support such scenario for example SAP HANA, Oracle, IBM DB2, SAP Sybase and SAP MaxDB.
- On the DBMS side, starting, stopping, getting the status of DBMS itself is implemented for:
- SAP HANA DB
- Microsoft SQL Server DB
- Currently, starting, stopping and getting the status of DBMS is NOT implemented for Oracle, IBM DB2, Sybase and MaxDB DBMSs.
You can use the solution with these DBMSs, but you need to make sure that:- DBMS is configured to automatically start with OS start.
- SAP system in startup procedure start first DBMS (which is default SAP start order in SAP instance profile)
Although we did not test with all these DBMSs, the expectation is that this approach will work.
- Start / Stop Standalone HANA system and VM
- Start / Stop SAP Application Server(s) and VM(s)
This functionality can be used for SAP application servers scale out -scale in process.
One meaningful scenario for production SAP systems is that you, as an SAP system administrator, identify upcomming peaks in the system load (for example Black Friday or Year-End close), where you know in advance how many SAPS / application servers you would need to meet the additional load requirements, and for how long. Then you can either schedule start / stop or manually start/stop a number of already prepared SAP application servers, that will cover the load peak. - Converting the disks from Premium to Standard managed disks during the stop process, and the other way around during the start process to reduce the storage costs.
- Start / Stop actions can be executed manually, or can be scheduled.
PaaS Solution Architecture
The solution is using Azure automation account PaaS as an automation platform to execute the SAP shutdown/startup jobs.
Runbooks are written in PowerShell. A PowerShell module SAPAzurePowerShellModules is used by all runbooks. These runbooks and the module are stored in PowerShell Gallery, and are easy to import.
Information about the SAP landscape and instances are stored in VM Tags. VM tagging can be done either manually or even better - using prepared tag runbooks.
<sid>adm password is needed on Windows OS and is stored securely in the Credentials area of the Azure automation account.
Secure assets in Azure Automation include credentials, certificates, connections, and encrypted variables. These assets are encrypted and stored in Azure Automation using a unique key that is generated for each Automation account. Azure Automation stores the key in the system-managed Key Vault.
The Starting and Stopping of:
- An SAP system and an SAP Application server is implemented using scripts (calling SAP sapcontrol executable).
- An SAP HANA DB is implemented using scripts (calling SAP sapcontrol executable).
- SQL Server DB start / stop / monitoring is implemented using scripts (calling SAP Host Agent executable).
- All scripts are executed at OS level, in a secure way via Azure VM agent.
- All SAP system and DBMS start / stop / monitor scrips are generated on the fly during the runtime, therefore there is no need to store them anywhere.
Soft / Graceful Shutdown of SAP System, Application Servers, and DBMS
SAP System and SAP Application Servers
The stopping of the SAP system or SAP application server will be done using an SAP soft shutdown or graceful shutdown procedure, within a specified timeout. The SAP soft shutdown is handling gracefully SAP processes, users, etc. within the specified downtime time, during the stop of the whole SAP system or one SAP application server.
Users will get a popup to log off, SAP application instance(s) will not be considered for scheduling from the different logon groups (users, batch, RFC, etc.), the procedure will wait for SAP batch jobs to complete (until the specified timeout is reached). This functionality is implemented in the SAP kernel.
INFO: You can specify the value for SAP soft shutdown time as a parameter. The default value is 300.
DBMS Shutdown
For SAP HANA and SQL Server, DB soft shutdown is also implemented, which will gracefully stop these DBMS, so DB will have time to flush consistently all content from memory to storage and stop all DB processes.
User Interface Possibilities
A user can trigger start / stop in two ways:
- using Azure Automation account portal UI
- or via modern SAP Azure Power App, which can be consumed in a browser, smart phones or Teams:
For more information you can check a great blog of Martin Pankraz - Hey, SAP Systems! My PowerApp says Freeze! But only if you’re done yet.
The SAP PowerApp application is fully integrated with backend start / stop functionality with Azure automation account. It will automatically collect information on all available SAP SIDs (via SAPSID tag) and offer Start / Stop / SAP system status functionality!
Cost Optimization Potential
Cost Savings on Compute for non-Productive SAP Systems
The non-production SAP systems, like dev, test, demo, training etc., typically do not run 24/7. Lets assume you would run them 8 hours per day, Monday through Friday. This means you run and pay for each VM 8 hours x 5 days = 40 hours. The rest of the time of 128 hours per week you don't need to pay, which translates into approximatelly 76 % of savings on compute!
Cost Savings on Compute for Productive SAP Systems
Productive SAP system run typically 24/7 and you never completely shut them down. Still, there is a huge potential for savings in the SAP application layer. The SAP application layer constitutes the largest portion of SAPS in an SAP system.
INFO: SAP Application Performance Standard (SAPS) is a hardware-independent unit of measurement that describes the performance of a system configuration in the SAP environment. It is derived from the Sales and Distribution (SD) benchmark, where 100 SAPS is defined as 2,000 fully business processed order line items per hour. SAPS is an SAP measure of compute process power.
In an on-premises environment, an SAP system is often oversized, so that it can process the required peak loads. But the reality is, these peaks are rare (maybe few days in 3 months). Most of the time such systems are underutilized. I’ve seen prod systems that have 5 – 10 % of total CPU utilization most of the time.
In the cloud we have the possibility to run only what we need, and pay for what we used – hence, the SAP application servers’ layer is a perfect candidate to bring down the cost for SAP productive systems!
Here, this solution offers jobs to start / stop an SAP application server and VMs. It is using a soft shut down, allowing SAP users and processes enough time to complete.
Cost Savings on Storage
If you use Premium storage, there is an opportunity for cost savings, by converting such managed storage to standard, while the system is not running.
Let’s say you need to use Premium storage (especially for the DBMS layer) to get a good SAP performance during the runtime. But once the SAP system (and VMs) is stopped, if you choose to convert the disks from Premium to Standard disks, you will pay much less on the storage during the time the system and the VMs are stopped.
During the start procedure, you can decide to convert the disks back to premium, to have good performance while the SAP systems are running , and only pay for the more expensive Premium storage, while the system is running.
For example, if the SAP system would run 8 hours x 5 days = 40 hours, and the SAP system is stopped for 128 hours per week, that means that 128 hours per week, you will not pay the price for Premium storage, but the reduced price for Standard storage.
For example, price of 1 TB P30 disk approximately 2 times higher than 1 TB S30 Standard HDD disk. For above mentioned scenario, savings on 1 TB managed disk would be approximately 54 %!
For the exact updated pricing for managed disks, check here.
Cost of Azure Automation Account PaaS Service
The cost of using Azure automaton service is extremely low. Billing for jobs is based on the number of job run time minutes, used in the month. And for watchers, billing is based on the number of hours used in a month. Charges for process automation are incurred whenever a job or watcher runs. You will be billed only for minutes/hours that exceed the free included units (500 min for free). If you exceed the monthly free limit of 500 min, you will pay per minute €0.002/minute.
Let’s say one SAP system start or stop takes on average 15 minutes. And let’s assume you scheduled your SAP system to start every morning from Monday to Friday and stop in the evening as well. That will be 10 executions per week, and 40 per month for one SAP system.
This means that in 500 free minutes you can execute 33 start or stop procedures for free.
Everything extra you need to pay. For one start or stop (of 15 min), you would pay 15 min * €0.002 = €0.03. And for 40 start / stop of ONE SAP system you would pay € 1.2 per month!
For uptodate pricing, you can check here.
Solution Cost of Azure Automation Account Management
Often, when you use a solution which offers you specific functionality, you need to manage it as well, learn it, etc. All this generates additional costs, which can be quite high.
As Azure automation account is a PaaS service, you have here ZERO management costs!
Plus, it is easy to set it up and use it.
Documentation and Scrips
All documentation and scripts can be found here on GitHub. All job scripts and SAP on Azure PowerShell Module is available on PowerShell Gallery.