Boosting SAP Convergent Mediation Availability with AWS Auto Scaling

Published on 28 JUN 2024

In Elastic Load Balancing, SAP on AWS, Technical How-to

Introduction

SAP Convergent Mediation (SAP CM) by DigitalRoute is a component of the SAP Billing and Revenue Innovation Management (SAP BRIM) solution. Organizations utilize SAP CM on AWS to manage and streamline their billing processes. For further information, visit the SAP Help portal – SAP Convergent Mediation by DigitalRoute.

SAP BRIM solutions can be deployed in two ways based on their usage. The first type is for offline or batch applications (e.g., batch billing mediation), where short downtimes are permissible. The second type is for real-time applications (e.g., online billing mediation), which require uninterrupted service. Customers utilizing SAP CM in a batch setting often resort to third-party clustering solutions at the application layer to ensure higher availability. However, this approach can complicate operations and elevate infrastructure support costs.

In this post, we introduce a more straightforward and cost-effective solution to enhance the availability of an SAP CM platform server using Amazon EC2 Auto Scaling. This solution allows customers to reduce downtime without relying on complex cluster management software at the application level. It employs an Auto Scaling group (ASG) combined with a launch template to deploy a new platform server via a custom Amazon Machine Image (AMI). This design minimizes the installation footprint and eliminates manual intervention in the event of a server failure. As an optional feature, customers may utilize an Amazon EventBridge rule and an AWS Systems Manager automation document to create an image before instance termination.

This blog will guide you on setting up a pilot to test the resilience of the platform container. Note that further development and tuning are crucial before deploying this in a production environment. Additionally, for stateful, real-time scenarios in SAP CM that require session persistence, a high-availability setup using external cluster management software is still necessary but is beyond the scope of this post.

Overview

In SAP CM, platform and execution containers are installed on separate hosts. Each container is equipped with at least one pico process of either Platform, Execution context (EC), or Service context (SC). These pico instances are generally configured post-installation. The platform and database host configurations provide essential storage and services for the mediation zone system, while execution servers deliver scalable processing capacity; redundancy is achieved by having multiple execution servers across different AWS Availability Zones.

The following diagram illustrates the high-level architecture for SAP Convergent Mediation. An AMI is created from an existing platform server and launched using a launch template along with user data. The user data script sets up an Overlay IP address assigned to the platform server. Execution servers in SAP CM communicate with the platform server through this Overlay IP. If a problem arises in the platform container, the Application Load Balancer identifies that the web interface port (default 9000) is unreachable and flags the instance as unhealthy. The ASG, reacting to this status, will terminate the faulty instance and initiate a new platform server based on the configured AMI. The new instance then registers itself as a target instance, allowing the Application Load Balancer to direct subsequent requests to it. To investigate the cause of the failure, a backup of the instance can be obtained before termination using a lifecycle hook, Amazon EventBridge rules, and an AWS Systems Manager automation document.

Architecture Description

Route 53 is a highly available and scalable Domain Name System (DNS) web service.
The Application Load Balancer (ALB) acts as a single point of contact for client connections, directing requests to the platform container.
Auto Scaling Group maintains the availability of Amazon EC2 instances.
Amazon EFS is employed for SAP CM storage that is shared across platform and execution containers.
Multiple execution containers in various Availability Zones bolster redundancy. In case of failure, batches running in those containers will need to be restarted manually.
A Pacemaker cluster is typically used for high availability of the SAP HANA database; however, this blog does not cover database resilience requirements. For more information, refer to the SAP HANA on AWS High Availability Configuration Guide for SLES and RHEL.
An AWS Systems Manager automation document is utilized to trigger an AMI creation of the EC2 instance prior to termination.

Prerequisites

SAP CM installation must follow the guidelines outlined in the SAP Help Portal – SAP Convergent Mediation by DigitalRoute. In the example below, “cmplat” represents the SAP CM platform container, while “cmexec1” and “cmexec2” denote the execution containers. The container names are “mz01” for cmplat, “ec01” for cmexec1, and “ec02” for cmexec2.

In Figure 2, we see the AWS Identity and Access Management (IAM) Policy assigned to the platform container, granting it permission to update the route table. Be sure to replace the AWS Region, account number, and route table details accordingly.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:ReplaceRoute",
      "Resource": "arn:aws:ec2:<AWS Region>:<VPC-Account-Number>:route-table/rtb-xxxxxxxxxxxxxxxxx"
    },
    {
      "Effect": "Allow",
      "Action": "ec2:DescribeRouteTables",
      "Resource": "arn:aws:ec2:<AWS Region>:<VPC-Account-Number>:route-table/rtb-xxxxxxxxxxxxxxxxx"
    }
  ]
}

Solution

The deployment process is as follows:

Disable source/destination checks on the SAP CM platform server.
Add the Overlay IP to the IP configuration of the active SAP CM platform server.
Define the destination of the Overlay IP in the route table as the ENI of the active SAP CM server.
Adjust the properties of the platform and execution containers to reference the OIP.
Create an AMI of the platform EC2 instance.
Establish a Launch Template.
Set up an Auto Scaling Group.
Attach the existing platform EC2 instance to the ASG.
Create a Target Group with an HTTPS health check and set the health check path as /mz/main.
Update the ASG with the Load Balancer target group.
Create an Application Load Balancer, targeting the group established in Step 9.
Set up a lifecycle hook in the ASG along with an SSM document to generate an AMI of the instance. Create an Amazon EventBridge rule and designate the SSM document as a target for the rule.

To begin, ensure source/destination checks are disabled on the SAP CM platform server. In the Amazon EC2 console, select the EC2 instance for the SAP CM platform, navigate to Actions, Networking, and choose Change source/destination check.

For those interested in online courses, you can find more information here.

For job seekers, this is an excellent resource.

Summary

In conclusion, enhancing the availability of your SAP Convergent Mediation platform using AWS Auto Scaling can be achieved effectively while reducing operational complexity. This solution is particularly beneficial for organizations looking to streamline their billing processes without incurring the additional costs associated with clustering solutions.