Introduction & Overview
Designing and Building an HADR for SAP Workloads
The course is part of this learning path
High availability and disaster recovery are key to ensuring reliable business continuity. While SAP workloads are mainly confined to Azure's infrastructure layer, it is still possible to utilize many Azure functions and features to enhance system reliability with relatively little effort. This course looks at when, where, and how to use Azure's built-in infrastructure redundancy to improve system resiliency and how various database high availability options are supported.
- Understand the key aspects of high availability and disaster recovery
- Learn about availability and availability zones
- Learn about Azure Site Recovery and how to implement it through the Azure portal
- Learn how to set up an internal load balancer in the context of SAP workloads
- Understand the Azure support options for Pacemaker and STONITH
- Learn how to implement Data Guard mirroring via the Azure CLI
- Set up Windows Failover Cluster and SQL Server Always On through the Azure portal
This course is intended for anyone who wants to use Azure's built-in infrastructure redundancy to enhance the reliability and resiliancy of their SAP workloads.
To get the most out of this course, you should be familiar with Azure, Azure CLI, SAP, SQL Server, and STONITH.
While the mechanics of data backup and replication is highly dependent on the type of database, strategies boil down to two basic options: synchronized real-time replication and asynchronous replication. Asynchronous is itself a continuum that varies from being very close to synchronous to replication hours out of step. In an ideal world, we would like to have a completely up-to-date copy of our data sitting on another server so that there would be no data loss in the event of a database failure for any reason. Apart from cost, which is always a significant factor, we come up against distance, latency, and network speed as the limiting factors. Synchronous replication is practical within a data center but doesn't help if the whole data center goes down. Synchronous replication isn't practical between geographic regions but does afford the greatest protection to localized outages. When replicating to other regions, you must take into account data sovereignty implications. Depending on what legal obligations you have, replicating to another region might not be possible, or the allowed region is geographically remote. One scenario is to configure a highly available synchronous solution between data centers in an availability zone, with asynchronous replication to another Azure region. The synchronized mirror or mirrors act as read-only databases where read requests are routed to reduce the load on the primary database. The asynchronous data in the other region is the fallback position in the event of a primary region failure.
Hallam is a software architect with over 20 years experience across a wide range of industries. He began his software career as a Delphi/Interbase disciple but changed his allegiance to Microsoft with its deep and broad ecosystem. While Hallam has designed and crafted custom software utilizing web, mobile and desktop technologies, good quality reliable data is the key to a successful solution. The challenge of quickly turning data into useful information for digestion by humans and machines has led Hallam to specialize in database design and process automation. Showing customers how leverage new technology to change and improve their business processes is one of the key drivers keeping Hallam coming back to the keyboard.