1. Home
  2. Training Library
  3. Microsoft Azure
  4. Courses
  5. Designing and Building HADR for SAP Workloads on Azure

Pacemaker Configuration

Contents

keyboard_tab
Introduction & Overview
1
Introduction
PREVIEW1m 27s
2
Overview
PREVIEW3m 42s
Course Summary
12
Summary
2m 56s
Start course
Overview
Difficulty
Intermediate
Duration
53m
Students
56
Ratings
5/5
starstarstarstarstar
Description

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.

Learning Objectives

  • 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

Intended Audience

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.

Prerequisites

To get the most out of this course, you should be familiar with Azure, Azure CLI, SAP, SQL Server, and STONITH.

Transcript

Pacemaker, the Linux high availability clustering solution, can be deployed on SUSE Linux Enterprise Server or Red Hat Server.  When deploying a fencing agent to halt and restart failed nodes, you have two options. Use a STONITH Block device, known as an SBD device or Azure Fence Agent. There are pros and cons for both, but it mainly comes down to what you know and are comfortable with. SBD devices will require the deployment of additional VM's, one per machine, ideally three, but they can service more than one cluster. Alternately Azure Fence Agent requires no extra VM's, but it is not something that you will have used outside of Azure, funnily enough. I won't go into setting up SBD devices as it's not specific to Azure, but if you go down that path, remember to make the network route between the SBD device VMs and the cluster nodes as direct as possible with the lowest latency.   

Azure Fence Agent needs to be installed on each VM in the Pacemaker cluster and uses the Azure API to monitor cluster nodes' health, stopping and restarting failed ones. Making calls to the core Azure API requires the agent to authenticate with the appropriate permissions using a service principal. Let's see how we can do that.

About the Author
Students
20984
Courses
51
Learning Paths
9

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.