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.
In this demo, we'll create two virtual machines, each running Oracle databases. One will be the primary and the other, the standby. Data Guard will be deployed as a high availability solution, and we'll end up failing over from the primary to the standby. All of this will be done using the Azure CLI through the Windows Azure SDK command prompt.
First off, we need to create a resource group, which I'll do using the az group create command, calling it oracle-rg and locating it in the westus. Next, I'll create an availability set with two fault domains and two update domains. Each virtual machine is deployed to the availability set, and I'm using an Oracle Linux image with a preinstalled Oracle 12 server instance. When Azure creates the VM, the ssh keys are automatically downloaded into a .ssh directory on my PC. I will rename the files so they won't be over-written when I create the second VM. Once the VM has been deployed, I'll grab the public IP address that I'll need to connect to the VM via ssh and put it in my local tnsnames file for my sqlplus connection. I'll repeat the process for the second VM. Now that the VMs exist, we need to allow access to port 1521 via a network security group rule. As well as the private network range, I'll add my local PC's IP address to source address prefixes. It's a case of rinse and repeat for the second machine's port access.
With the Infrastructure taken care of, let's log onto oraclevm1 and start setting up the database. So that's ssh using the downloaded key and public IP address from earlier. I'll change to the oracle user and create a database called cdb1. Once that's finished, I'll set the oracle home directory and sid variables. Then fire up a sqlplus session and check the archive log mode, and if not enabled, then enable it, along with force logging. We also need to create standby redo logs in line with the primary database redo logs.
Last but not least, turn on flashback and set standby file management to automatic before exiting the SQL session. We now need to verify the tnsnames and listener files. They don't exist, so I'll need to create them and enter the locations for the primary and standby databases. The listener file has an entry for the data guard manager. After creating those files, we can enable data guard broker via an SQL alter system statement and start the listener. That's us done on the primary server for the moment. Now ssh onto the standby server, create the tnsnames and listener files as we did on the primary machine, and start the listener.
Now we need to restore the primary database to the standby server. To do that from scratch, we need to create an initialization parameter file, create the appropriate directories, and a password file. Next, log into a sqlplus session and start the database using the parameter file. Using the RMAN tool, specify the primary as the target and the standby as the auxiliary, and then run the duplicate target database command. As on the primary VM, we need to enable the data guard broker.
Finally, we need to configure the data guard broker on the primary VM by logging into the data guard manager with the SYS account. First, create the configuration specifying cdb1 as the primary database, add cdb1_stby as the mirror, and enable the configuration. We can now try failing over to the standby database with the data guard manager command switch over. Switch over has succeeded, and the new primary is cdb1_standby.
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.