High Availability for SAP Edge Integration Cell on Red Hat OpenShift

Part of: SAP Edge Integration Cell on Red Hat OpenShift

This article covers the Red Hat OpenShift platform high-availability topology for SAP Edge Integration Cell (EIC). SAP's documentation is authoritative for EIC application HA configuration and SAP support boundaries — see the SAP links throughout.

Table of Contents

• Overview
• Terminology Alignment: SAP Multi-AZ and OpenShift Availability Zones
• SAP Application Requirements
• On-Premises OCP Across Sites and Zones
• Deployment Scenarios
• ARO and ROSA Platform Considerations
• Dependencies and Validation

Overview

This guide describes high availability (HA) architecture for SAP Edge Integration Cell (EIC) on Red Hat OpenShift. HA requires a resilient OpenShift platform, EIC HA configuration, and highly available database and data-store services. Refer to the SAP and Red Hat documentation linked below for supported versions and configurations.

HA within one site can protect against component failures. This article focuses on the requirements for extending that resilience across independent zones or sites within one OpenShift cluster.

Terminology Alignment: SAP Multi-AZ and OpenShift Availability Zones

SAP and Red Hat use different terms for related concepts:

Note — "stretched cluster": Here, stretched OpenShift cluster refers to one OpenShift cluster spanning multiple sites. The illustrative multisite topology in this article uses three zones, with EIC worker capacity in each zone, and must meet both the SAP application requirements and the OpenShift multisite requirements.

SAP Application Requirements

SAP's High Availability guidance specifies three availability zones for EIC Multi-AZ. Plan EIC worker capacity across all three zones, and follow that guidance for the required control-plane and worker node counts.

Configure both SAP settings where applicable:

1. Enable High Availability Mode when adding the Edge Node.
2. Enable Multi-AZ Support when deploying the EIC solution on workers distributed across zones, following SAP's documented procedure. Plan this before deployment: SAP states that this property cannot be changed after the initial deployment.

Check SAP's PAM, SAP Note 3247839 — Prerequisites for installing SAP Integration Suite Edge Integration Cell (SAP account required), and the ELM supported-platform matrix for the current list of supported platforms and version combinations. A platform being listed does not by itself establish support for every storage or multi-site application topology.

On-Premises OCP Across Sites and Zones

For on-premises deployments, Red Hat's guidance for clusters that span data centers strongly recommends keeping an OpenShift cluster within a data center. Consider a cluster spanning data centers only after validating the applicable network, storage, quorum, and application requirements, including behavior during failures and maintenance. See the subscription-only multi-site deployment KB for more detail.

Where these requirements cannot be met, evaluate separate OpenShift clusters per site and a disaster-recovery strategy against the required recovery time and acceptable data loss. Cross-cluster recovery for EIC requires an application-specific recovery procedure aligned with SAP's recovery guidance and validated end to end; it is outside this article's scope.

For a proposed multisite cluster, document shared power, cooling, networking, and storage dependencies between the zones or sites. Reserve sufficient capacity in the surviving zones or sites to run workloads after a failure, and follow the platform-specific installation guidance. Validate the following requirements for your release:

• etcd and network performance: validate peer latency and disk I/O against the recommended etcd practices. Include jitter, packet loss, API performance under load, and any third quorum site in the assessment; network RTT alone is insufficient.
• Storage and application limits: storage backends and EIC can impose tighter latency limits than the control plane. For synchronous replication, apply the selected storage backend's requirements as well as those of OpenShift (see Dependencies and Validation).
• Control-plane layout: for a three-member control plane designed to tolerate loss of any one site, place one control-plane / etcd member in each of three sites (1 + 1 + 1). The surviving members must retain connectivity and quorum.

Scope and recovery: This guide covers availability within one OpenShift cluster, including site-failure tolerance where the topology supports it. HA does not replace backups or a disaster-recovery plan. Recovery from failures beyond the cluster's designed tolerance is outside this article's scope; follow the applicable OpenShift backup and recovery procedures and SAP EIC emergency recovery guidance.

Deployment Scenarios

All scenarios below must meet the SAP application requirements and the dependency and validation requirements. The on-premises multisite example is conditional on the platform requirements above.

Figure 1. Illustrative on-premises OCP HA topology across three independent failure domains, subject to validation of the SAP application and OpenShift multisite requirements.

ARO and ROSA Platform Considerations

Azure Red Hat OpenShift (ARO) and Red Hat OpenShift Service on AWS (ROSA) are managed OpenShift offerings. Check the following deployment details:

• ARO standard architecture: provisions three control-plane nodes and at least three workers, distributing both roles across zones when the region supports AZs. Regions without AZ support use a single machine set per role. See the ARO service definition and Azure availability zones.
• ROSA Classic: a multi-AZ cluster distributes its control plane across three AZs, but workers can still occupy only one AZ. Verify worker distribution independently. See Red Hat's ROSA architecture comparison.
• ROSA with HCP: each worker machine pool occupies one AZ; use multiple pools to cover the required worker zones. See the ROSA architecture comparison and ROSA with HCP deployment guidance.

Dependencies and Validation

Use SAP's setup planning guidance and OpenShift installation guidance for EIC to verify the following dependencies:

• Message Service HA: SAP enables Message Service replication as part of HA configuration; see SAP's persistence guidance. Validate replica placement, service availability, and message durability for the intended zone or site failure. Volume replication alone does not establish these application guarantees.
• Persistent volumes: Follow Note 3247839 for Message Service storage requirements. Evaluate volume topology, attachment, and recovery behavior together with application replica placement; a zonal volume may remain unavailable during an outage while a service continues through a surviving replica. See OpenShift persistent storage and, for NetApp, the Trident guidance for EIC.
• External database and data store: Configure the SAP-supported services for the intended failure coverage, including their replication, endpoint failover, and recovery procedures. Validate these dependencies independently of Message Service and persistent-volume availability.
• Traffic: Make DNS, load balancers, ingress/gateways, firewalls, and network paths resilient. Preserve the original client IP where SAP client-IP filtering requires it. Review the support scope and restrictions of OpenShift Routes for EIC before choosing that exposure method.
• Operations and security: Include registry access, certificates/secrets, monitoring, and logging in the design. OpenShift offers integrated platform operations and documented EIC integrations for monitoring and logging. Establish network isolation and TLS according to the deployment's requirements.
• HA validation: Test pod/node failure, loss of each intended zone/site, network partition, external-service failover, and planned maintenance. Record control-plane quorum, integration endpoint availability, message behavior, data integrity, surviving capacity, and the duration of service interruptions. HA does not establish a universal zero-downtime or zero-data-loss guarantee.

Define operational responsibilities before testing: