

We are using Azure Fencing Agent (which restarts a failed node via the Azure APIs) for setting up fencing in the pacemaker cluster. We recommend you refer to this blog to understand concepts and requirements in detail. This blog post will assume that you are familiar with general concepts of setting up the communication layer of SUSE HA pacemaker cluster solution. High-Availability setup for SAP solutions is technically complex activity and has several pre-requisites to be met before actual cluster configuration. Refer to below table for the details of the reference setup: Hostname SAP Content Server is running on both the VMs (Virtual Machines) in non-cluster drive and piggybacking on the MaxDB Virtual IP so that ECC or S/4HANA connects to the appropriate content server. Virtual IP for connecting MaxDB database is defined in Azure Internal Load Balancer (ILB) and it will be attached to the active node of the cluster resources. Overall concept for this setup is that MaxDB database which is using Azure NetApp Files (ANF) as storage platform for data and log volumes is part of SUSE HA Cluster and it can failover between primary and secondary VM (virtual machines). Its connected with ECC OR S/4HANA environment in Microsoft Azure. Reference architecture for SAP Content Server & MaxDB database in Microsoft Azure is shown below. This blog can be used as reference for deployment of HA (High Availability) environment and not intended to cover other aspects of system design like infra, network, security, and performance. With SUSE High Availability Extension (HAE), we can manage MaxDB database resources and build an automated, highly available solution. Application layer is managed by the SAP’s sapcontrol service. In this blog, we are using SAP MaxDB database as the storage layer. The storage layer could either be a file system or MaxDB database. The SAP Content Server consists of an application layer and a storage layer. This includes identifying its single points of failure and building a resilient system spread across Availability Set or Availability Zones. To match the Availability SLA for the SAP Content Server with that of the OLTP systems on Microsoft Azure, we must understand the architecture of SAP Content Server.

Also, MaxDB database can be replaced with File System as SAP content server repository which is not covered in this blog. Though we are using SUSE High Availability Extension tool set (pacemaker) for this blog, similar set up can also be achieved for Red Hat Enterprise Linux based systems.

It uses SUSE High Availability Extension tool set (Pacemaker) for the cluster solution. In this blog, we will provide steps to configure Highly available SAP Content Server 7.53 with MaxDB database version 7.9 on SUSE Linux in Microsoft Azure Cloud using Azure NetApp Files (ANF) as storage platform for database.
