This post has been republished via RSS; it originally appeared at: Microsoft Tech Community - Latest Blogs - .
Introduction
For mission critical SAP workloads running on Azure, deployment across Availability Zones is one of the commonly used architectures to provide resiliency against datacenter failures within a region. When using Availability Zones for SAP deployments there are 2 types of architectures possible
- Active/Active – SAP application servers are active and evenly distributed across the two or three zones.
- Active/Passive – SAP application servers are active on the Zone where database is active. On the Zone where the database is Passive (standby), the application servers are built but shutdown.
Our documentation here provides clear guidance on choosing the best possible architecture based on the requirements and location.
Scenario
The reference architecture for Active/Passive deployment is as per below.
In the above scenario, all Application servers are active in Zone 1 where database is active. Application servers in Zone 2 are in passive mode (shutdown). When the database fails over to the second Zone (either due to complete Zonal outage or VM failure or manual switchover) application servers need to be switched from Zone 1 to Zone 2 i.e. app servers on Zone 2 need to be started and app servers on Zone 1 need to be shutdown gracefully. In this blog we will look into how this can be done in an automated way in Azure, along with sample scripts/runbooks for database running on Linux pacemaker cluster.
Approach
In order to achieve the switch as described above, we need 2 things
- Alerting mechanism which is capable of triggering actions when database failover occurs.
- Automation Runbook to start SAP app servers in Zone 2 and gracefully shutdown SAP app servers in Zone 1.
Alerting Mechanism
- Pacemaker alert agent - Pacemaker Alert agents is one of the possible trigger mechanism if your database is running on a Linux pacemaker cluster. Alert agents can be configured to trigger external action when a cluster event occurs like a node failure, resource starting/stopping etc. Similar to resource agents, alert agents rely on external scripts to handle the actions. Cluster will simply call the scripts in the specified path and pass information about the event in the form of environment variables. Simple alert agent can be added to a cluster as ‘crm configure alert <alertname> <path to script>’. Refer the Pacemaker cluster documentation for more details about Alert agents.
- Azure Monitor for SAP – Azure Monitor for SAP solutions which is in Public Preview is a great option to monitor your SAP deployments on Azure out of the box and utilize the native capabilities of Azure Monitor Infrastructure for notifications, alert actions, integration with other ITSM tools etc. Azure Monitor for SAP has multiple providers one of which High Availability Cluster (Pacemaker) provider can be used to monitor your HANA and SCS/ERS pacemaker cluster. The inbuilt alert template "Cluster Primary Node switched" can be used to trigger actions when a failover happens.
SAP Application Server Switchover
Azure Automation Runbooks are a great way to create event-based automation to respond to issues. Automation runbook can be triggered directly from Alert action with Azure Monitor or using webhooks. When using webhook it is highly recommended to secure it using Private Endpoint and restrict public access . In our scenario the runbook will do the following
- Will be triggered by an Alert Action group in case Azure Monitor for SAP is used for alerting or via a webhook in case of Pacemaker alert agent.
- From the alert it is determined which is the newly promoted zone and the newly demoted zone.
- Get the list of application servers in each of the Zones.
- Start application servers in the Promoted Zone.
- Stop application servers (using soft shutdown) in Zone 1 (Demoted Zone). Soft Shutdown function provides a graceful shutdown mechanism for your SAP application servers. See here for further details Soft Shutdown in SAP Application Server - SAP Help Portal
If you would like to run some checks before step4, you could add an approval workflow before Step 4 is carried out. This can be done by setting up a simple Logic app to display a Team's adaptive card or email workflow or raising incidents directly into a ticketing system of your choice.
For starting and stopping application servers you could leverage the wonderful Start-Stop Automation framework in github. The runbook sample provided below makes use of this framework for Start/Stop of SAP application servers.
Implementation
Detailed implementation steps along with scripts are available here SAP-on-Azure-AppServers-Avzone-Failover
Conclusion
In this blog we saw one of the possible approaches for automated switching of SAP Application servers in an Active/Passive setup of SAP deployment across Zones. The approach and the runbooks can also be tweaked for Active/Active scenario to handle the case of complete Zone failure to ensure that minimum number of application servers are always active across the zones.