Overview: High availability for SAP applications on IBM Power Virtual Server running Red Hat Enterprise Linux

Use this information to understand high availability options for SAP HANA and SAP application workloads on IBM® Power® Virtual Server.

Use the following information to learn how to implement high availability solutions for SAP systems on Power Virtual Server instances.

SAP system architecture

The main components of an SAP system are as follows.

SAP HANA system

The SAP HANA system hosts the tenant database that stores data for SAP applications.

SAP application server

SAP application servers provide the functional components of an SAP S/4HANA or other SAP application solution. All customization and application data is stored in the tenant database of the SAP HANA system.

An SAP application system is installed and configured as a single unit. It consists of the following application instances.

  • One ABAP System Central Services instance (ASCS instance)

    • Each SAP application system includes one ASCS instance, which contains a message server and an enqueue server.

  • One or more application server instances (AS instances)

    • The primary application server (PAS) is the first AS instance that is installed for an ABAP system.
    • Additional AS instances are called additional application servers (AAS).

Both the application server instances and the ASCS instance require read and write access to a shared file system.

Shared file system

The shared file system is typically exported from a Network File System (NFS) server and mounted on all AS instances.

Figure 1 shows the technical components of an SAP system.

Figure 1. Technical components for SAP systems
Technical components for SAP systems

SAP high availability solution considerations

To ensure high availability, install application servers redundantly. Deploy at least two application servers (PAS and AAS) and configure logon groups for load balancing. If an application server fails, all active user sessions on that instance are ended. Users must log in again, and load balancing redirects them to another running application server.

Other technical components, including the SAP HANA database, ASCS instance, and shared file system, are single points of failure and require protection.

SAP HANA system protection

To protect an SAP HANA system, deploy a second SAP HANA instance on a separate virtual server, enable SAP HANA system replication, and use high availability (HA) cluster software for automated failover. The solution depends on the recovery time objective (RTO).

Table 1 summarizes the solution scenarios and their typical recovery time objectives.

High availability solution variations for SAP HANA
Scenario Typical RTO Comment
Performance Optimized A few minutes This scenario is used by default unless specific requirements apply.
Active/Active (read enabled) A few minutes In an Active/Active (read enabled) configuration, SAP HANA system replication enables read access to database content on the secondary system.
Cost Optimized A few dozen minutes In a cost-optimized configuration, a nonproduction SAP HANA system runs on the secondary node during normal operation. Hardware resources are shared between the nonproduction system and the replication secondary. Memory consumption is reduced by disabling the column table data preload. During the failover process, the nonproduction instance is stopped before the node takes over the production workload. This approach increases takeover time compared to a performance-optimized configuration.

SAP ASCS instance protection

To protect the ASCS instance, deploy an Enqueue Replication Server (ERS) instance on a separate virtual server and use HA cluster software for automated failover.

Install the ASCS and ERS instances on a shared disk that is attached to both servers or on an NFS file system.

The enqueue server in the ASCS instance manages the lock table, while the ERS maintains a replicated copy in its memory. If the enqueue server is restarted, the lock table is rebuilt from the ERS copy, preserving all locks.

A restart of the message server is sufficient because no data needs to be retained.

Shared file system protection

To protect the shared file system, create File storage shares for VPC. File Storage for IBM Cloud® File Storage for VPC is designed for high availability and offers profiles for zonal and regional deployments. Mount the file system on your Power Virtual Server instances by following the steps in Accessing file storage shares for VPC.

Overview of high availability clusters

An HA cluster uses virtual server instances to provide high availability for an SAP system. Critical SAP components run on multiple instances within the cluster.

HA cluster software does not eliminate downtime completely. However, it automates failover processes to help maintain service continuity and reduce disruption.

In a nonclustered deployment, a failure of a critical component or its underlying virtual server instance causes a complete SAP system outage. An administrator must diagnose the issue, fix it, and restart the failed component.

In an HA cluster, the software automatically detects hardware or software faults. When a fault occurs, the cluster restarts the affected component on a healthy virtual server instance. This process is known as failover. It occurs automatically without administrator intervention and can reduce recovery time compared to manual recovery procedures.

Key components in an HA cluster

To run critical application components on multiple cluster nodes, the following elements typically play a role in enabling high availability:

Shared storage
Cluster nodes require access to the same storage. During failover, another node can start the failed component because it can access the required files and data.
Service IP address
Client nodes communicate with the application component through a fixed service IP address, which is assigned to the node where the component is running.
Resource agents
A resource agent abstracts cluster management for the application component. It defines the logic for starting, stopping, and monitoring the component.

Cluster monitoring and fault detection

An HA cluster uses a heartbeat mechanism to monitor node health and status.

The cluster software must prevent a split-brain scenario, which occurs when all heartbeat communication fails while nodes remain active. In this situation, multiple nodes might incorrectly assume that they are active and start duplicate resources, causing data corruption.

Quorum and node isolation

Quorum determines whether nodes can safely continue operating and managing resources. Nodes that do not have quorum must be stopped or isolated to prevent a split-brain scenario.

Fencing mechanisms

Fencing isolates nodes without quorum or when a resource cannot be stopped normally, ensuring the resource can start safely on another node. Two common fencing methods include:

Power fencing

A fence_agent controls power devices, hardware management consoles, or hypervisor APIs to forcibly power off or restart a node. Powering off the node ensures it cannot access shared resources.

Power fencing provides reliable isolation and ensures that the node is powered off. Control occurs at the hardware level, independent of the operating system or cluster software state. However, power cycling takes time, and configuring fence agents requires a more complex setup.

SBD (STONITH Block Device) poison-pill fencing

A shared storage device is accessible to all nodes. Nodes write a poison pill to the disk to signal another node to shut down.

The sbd daemon on the target node reads the poison pill and triggers a restart or shutdown. A watchdog is required for this method. If the sbd daemon hangs and fails to read the poison pill, it also fails to reset the watchdog timer. When the timer expires, the watchdog restarts the node.

Overview of Linux high availability cluster on Power Virtual Server

Cluster nodes in Power Virtual Server can run in a single workspace within one zone or across two workspaces in different zones.

The network architecture depends on the deployment model. In a single workspace, one subnet can span all cluster nodes. However, Power Virtual Server does not allow a subnet to span multiple workspaces. As a result, the traditional IPaddr2 resource agent cannot be used to assign a fixed service IP across workspaces.

The resource agents powervs-move-ip and powervs-subnet manage additional subnets or network routes when cluster nodes are distributed across multiple workspaces.

Table 2 compares high availability cluster configurations for single-workspace and multizone region deployments.

Comparison of HA cluster configurations for single-workspace and multizone region deployments
Configuration Single workspace Multizone region
Shared block storage Power Virtual Server volumes Not applicable
Shared file storage File storage shares for VPC (zonal) File storage shares for VPC (regional)
Fencing agent fence_ibm_powervs (one agent) fence_ibm_powervs (one agent per workspace)
Shared storage for SBD fencing Power Virtual Server volumes iSCSI volumes on VPC VSIs
Service IP resource agent ipaddr2 (recommended), powervs_move_ip powervs_move_ip (recommended), powervs_subnet

The following figures illustrate the architecture of a highly available SAP system.

SAP Web Dispatcher serves as a reverse proxy for HTTP(S) requests to the SAP system. Two SAP Web Dispatchers run in parallel in IBM Cloud® Virtual Private Clouds behind an IBM Cloud® Load Balancer. IBM Cloud® Transit Gateway interconnects the IBM Cloud VPC with resources in Power Virtual Server workspaces. Business users access the SAP system through the Load Balancer and SAP Web Dispatchers.

Figure 2 shows a high availability setup with the SAP system that is installed in a single Power Virtual Server workspace.

At least two application servers run on virtual server instances within the Power Virtual Server workspace. Instance directories for the application servers are stored on Power Virtual Server volumes or a zonal file storage share.

Two Power Virtual Server instances form a cluster for ASCS and ERS. ASCS and ERS instance directories are stored on a zonal file storage share. The ipaddr2 resource agent manages virtual IP addresses for ASCS and ERS.

Another two Power Virtual Server instances form a cluster for SAP HANA. SAP HANA runs on both instances with system replication configured. SAP HANA storage is stored on Power Virtual Server volumes. The ipaddr2 resource agent manages the virtual IP for the SAP HANA primary.

Figure 2. SAP on Power Virtual Server HA architecture overview
SAP on Power Virtual Server HA architecture overview

Figure 3 shows a high availability setup with the SAP system that is deployed across two zones in a multizone region.

Redundant application servers run on virtual server instances in both Power Virtual Server workspaces. Application server instance directories are stored on Power Virtual Server volumes or a regional file storage share.

Two Power Virtual Server instances across the workspaces form a cluster for ASCS and ERS. Their instance directories are stored on a regional file storage share. The powervs-move-ip resource agent manages static routes and virtual IP addresses for ASCS and ERS.

Another two Power Virtual Server instances form a cluster for SAP HANA. SAP HANA runs on both instances with system replication configured. SAP HANA uses Power Virtual Server volumes for storage. The powervs-move-ip resource agent manages static routes and the virtual IP for the SAP HANA primary.

Figure 3. SAP on Power Virtual Server HA architecture overview
SAP on Power Virtual Server HA architecture overview

High availability network considerations

High availability strategies for SAP solutions on IBM Power Virtual Server differ between single-zone and multizone deployments.

A single-zone deployment typically offers lower latency and faster failover times because all components are in the same zone. However, it is more vulnerable to zone-level infrastructure failures.

A multizone deployment distributes resources across separate zones. This design improves resilience against zone-specific outages, but it also introduces additional networking considerations that are addressed by specialized resource agents.

When you deploy SAP application servers in a multizone environment, running them in both zones can introduce latency between the application servers and the active database server. To reduce this impact, use an active-passive deployment and colocate active application servers with the active SAP HANA database instance.

IP failover in multizone environments

In IBM Power Virtual Server, subnets are associated with a single workspace and do not span multiple workspaces. Therefore, standard Linux resource agents such as ipaddr2 cannot provide service IP failover across workspaces.

Maintaining connectivity between IBM Cloud VPC and another Power Virtual Server workspace in a multizone region requires additional configuration.

IBM provides custom resource agents to enable IP failover and maintain connectivity in these scenarios.

Resource agent: powervs-move-ip

This resource agent manages failover by assigning an overlay IP address as an alias to the virtual server instance (VSI) and updating static routes during takeover.

During a takeover event, the powervs-move-ip resource agent updates predefined static routes in IBM Power Virtual Server and assigns an overlay IP address as an IP alias to the virtual server instance.

The following figures illustrate this scenario in an SAP HANA system replication cluster.

  • Two virtual server instances (VSIs) are deployed in separate workspaces.
  • A private subnet is created in each workspace.
  • The instances form a two-node RHEL High Availability Add-On cluster.
  • SAP HANA is installed on both instances, and SAP HANA system replication is configured.
  • A cluster resource for the overlay IP address is configured with the powervs-move-ip resource agent.

Overlay IP characteristics

  • The overlay IP is outside all CIDR subnet ranges in the environment.
  • It is not assigned to a network interface during deployment.
  • At run time, the resource agent configures the overlay IP address as an IP alias on a VSI network adapter.
  • A static route is configured in each workspace:
    • The destination of each static route is the overlay IP address.
    • The next hop for each route is the primary IP address of its respective VSI.
    • The resource agent enables the route to the VSI hosting the SAP HANA primary and disables the route to the VSI hosting the SAP HANA secondary.

Overlay IP normal operation

  • The overlay IP address is configured as an alias on VSI-1 in workspace 1.
  • In workspace 1, the static route with the overlay IP address as the destination and the next hop set to VSI-1's primary IP address is enabled.
  • In workspace 2, the static route with the same destination and the next hop set to VSI-2's primary IP address is disabled.
  • The SAP HANA primary instance runs on VSI-1.
  • The SAP HANA secondary instance runs on VSI-2.

Figure 4. SAP HANA on Power Virtual Server in multizone region HA overview
SAP HANA on Power Virtual Server in multizone region HA overview

Overlay IP after a takeover

  • The overlay IP address is configured as an alias on VSI-2 in workspace 2.
  • In workspace 2, the static route with the overlay IP address as the destination and the next hop set to VSI-2's primary IP address is enabled.
  • In workspace 1, the static route with the same destination and the next hop set to VSI-1's primary IP address is disabled.
  • The SAP HANA primary instance runs on VSI-2.
  • The SAP HANA secondary instance runs on VSI-1.

Figure 5. SAP HANA on Power Virtual Server in multizone region HA takeover
SAP HANA on Power Virtual Server in multizone region HA takeover

Resource agent: powervs-subnet

During a takeover event, the powervs-subnet resource agent moves the entire subnet, including the virtual IP address, from one workspace to another.

The following figures illustrate this scenario in an SAP HANA system replication cluster.

Two virtual server instances are deployed in separate workspaces, each with its own subnet:

  • SAP HANA is installed on both VSIs, and SAP HANA system replication is configured.
  • The two virtual server instances form a two-node high availability cluster, each using its own subnet.
  • A cluster resource that uses the powervs-subnet resource agent is configured for Subnet 3 and IP address 3.
  • SAP HANA database clients use IP address 3 to connect to the database.

Move subnet characteristics

The resource agent automatically creates the subnet in the workspace hosting the SAP HANA primary instance.

  • Configure the subnet CIDR range to avoid overlap with existing subnets.
  • Use a minimal CIDR range; only IP address 3 and the gateway IP are allocated in Subnet 3.
  • Ensure that the subnet does not already exist in either workspace.

Move subnet normal operation

  • Subnet 3 is created in workspace 1.
  • Subnet 3 is attached to VSI-1.
  • IP address 3 is configured on VSI-1.
  • The SAP HANA primary instance is active on VSI-1.
  • The SAP HANA secondary instance is active on VSI-2.

Figure 6. SAP HANA on Power Virtual Server in multizone region HA overview
SAP HANA on Power Virtual Server in multizone region HA overview

Move subnet after a takeover

  • Subnet 3 is created in workspace 2.
  • Subnet 3 is attached to VSI-2.
  • IP address 3 is configured on VSI-2.
  • The SAP HANA primary instance is active on VSI-2.
  • The SAP HANA secondary instance is active on VSI-1.

Figure 7. SAP HANA on Power Virtual Server in multizone region HA takeover
SAP HANA on Power Virtual Server in multizone region HA takeover

To enable these resource agents to manage Power Cloud resources, you must configure authentication.

Agent authentication with the Power Cloud API

The resource agents use the IBM Power Cloud API to manage the resources that they control. They use the API to complete the following tasks:

  • Get status information.
  • Create or delete objects.
  • Trigger configuration updates.

You enable the authentication of the resource and fencing agents with the IBM Power Cloud API by using the following method:

  • API key Use a Service ID and API Key. Create a Service ID in IBM Cloud® Identity and Access Management and generate an API key for it. Assign the required IBM Power Cloud API permissions to the Service ID, and then configure or store the API key on the Power Virtual Server instance. The instance uses the API key to authenticate with the IBM Power Cloud API endpoints.

SAP application server considerations in a multizone region

Active-active deployment
SAP application servers are distributed across two workspaces in different zones. At least two application servers run in separate workspaces. Redundant virtual server instances for SAP Central Services (CS) and the SAP HANA database system are deployed in both workspaces. Only one CS instance and one SAP HANA primary node are active at a time. This deployment provides redundancy at the application layer.
Active-passive deployment
SAP application servers are active in only one of the two workspaces at a time. Application servers in the passive workspace are pre-provisioned but remain powered off until failover. As in the active-active deployment, CS and SAP HANA are deployed in both workspaces, but only one CS instance and one primary node are active at a time. This deployment provides better performance during normal operation but increases the recovery time objective during failover. The application servers must start during failover.

SAP HANA disaster recovery scenarios

To provide extra protection for the database, replicate the SAP HANA system to a third system in a different region by using SAP HANA system replication. Select one of the following topologies based on your requirements.

  • SAP HANA multitier system replication

    Multitier system replication chains multiple systems together to provide a higher level of availability.

  • SAP HANA multitarget system replication

    Multitarget system replication enables primary and secondary systems to replicate changes to multiple targets.

High availability cluster setup references

Table 3 provides links to documentation for configuring high availability clusters.