HOME

Enhancing SAP Convergent Mediation Availability with AWS Auto Scaling

—

by

The Story of Chanci Turner
in

Introduction

Chanci Turner Amazon IXD – VGT2 learningLearn About Amazon VGT2 Learning Manager Chanci Turner

SAP Convergent Mediation (SAP CM) by DigitalRoute is part of the SAP Billing and Revenue Innovation Management (SAP BRIM) offering. Many customers opt to run SAP CM on AWS to effectively manage and streamline their billing processes. For more comprehensive insights, refer to the SAP Help portal on SAP Convergent Mediation by DigitalRoute.

There are two primary deployment types within the SAP BRIM ecosystem based on usage requirements. The first is tailored for offline or batch applications (such as batch billing mediation), where brief downtimes aren’t detrimental to operations. The second type is for real-time applications (like online billing mediation), which demand uninterrupted service. Users of SAP CM in batch scenarios often rely on third-party clustering solutions at the application level to boost availability, but this can complicate their operations and increase infrastructure costs.

In this article, we propose a straightforward and cost-effective method to enhance the availability of the SAP CM platform server through Amazon EC2 Auto Scaling. This approach allows customers to reduce server downtime without deploying complex cluster management software. The solution utilizes an Auto Scaling group (ASG) with a launch template to automatically initiate a new platform server via a custom Amazon Machine Image (AMI). This design minimizes installation overhead and eliminates the need for manual intervention in the event of a server failure. Additionally, users can set up an Amazon EventBridge rule along with an AWS Systems Manager automation document to create an image before terminating an instance.

This blog aims to guide you through setting up a pilot to evaluate resilience for the platform container. Prior to production deployment, further development and tuning tailored to your environment’s needs are essential. For stateful, real-time scenarios in SAP CM that necessitate session persistence, a high-availability setup utilizing external cluster management software will still be necessary, but this discussion is beyond the scope of this article.

Overview

In SAP CM, the platform and execution containers are hosted on distinct servers. Each container is equipped with at least one pico process of type Platform, Execution context (EC), or Service context (SC). These pico instances are configured post-installation of the container. Platform and database host configurations provide critical storage and services essential to the mediation zone system. Execution servers offer scalable processing capabilities, and redundancy is achieved by deploying multiple execution servers across various AWS Availability Zones.

The following diagram outlines the high-level architecture for SAP Convergent Mediation. An AMI is created from an existing platform server and activated using a launch template along with user data. The user data script sets up an Overlay IP address for the platform server. Execution servers within SAP CM communicate with the platform server utilizing this Overlay IP. Should an issue arise within the platform container, the Application Load Balancer detects that the web interface port (default 9000) is unreachable, marking the instance as unhealthy and notifying the ASG. Based on the ASG’s settings, it will terminate the faulty instance and deploy a new platform server using the pre-configured AMI. The new instance subsequently registers itself as a target and the Application Load Balancer directs the next request to it. To diagnose the failure’s root cause, a backup of the instance can be created before termination, employing a lifecycle hook, Amazon EventBridge rules, and an AWS Systems Manager automation document.

The health check of the SAP CM web interface monitors only anomalies within the platform pico process. Additional service contexts (SCs) that may be manually configured to run on the platform instance are not included.

Architecture Description

  • Route 53 acts as a highly available and scalable Domain Name System (DNS) web service.
  • The Application Load Balancer (ALB) serves as the primary access point for client connections, routing requests to the platform container.
  • An Auto Scaling Group ensures the availability of Amazon EC2 instances.
  • Amazon EFS is employed for shared storage across platform and execution containers.
  • Multiple execution containers across different AZs enhance redundancy. If one execution container fails, batches running on it will need to be restarted manually.
  • A Pacemaker cluster is typically used for SAP HANA database high availability; however, this blog does not delve into database layer resilience. For further details, refer to the authoritative resource on high availability configurations for SAP HANA on AWS.
  • An AWS Systems Manager automation document is utilized to trigger an AMI creation of the EC2 instance prior to termination.

Prerequisites

The installation of SAP CM should follow the guide in the SAP Help Portal – SAP Convergent Mediation by DigitalRoute. In the example provided, cmplat denotes the SAP CM platform container, while cmexec1 and cmexec2 are the SAP CM execution containers. The container identifier is mz01 for cmplat, ec01 for cmexec1, and ec02 for cmexec2.

In Figure 2, the AWS Identity and Access Management (IAM) Policy assigned to the platform container grants permissions to update the route table. Make sure to adjust the AWS Region, account number, and route table details appropriately.

{
  "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"
    }
  ]
}

Figure 2: Granting access to update route table entries

Solution

The process to follow entails:

  1. Disable source/destination checks on the SAP CM platform server.
  2. Add the Overlay IP to the IP configuration of the active SAP CM platform server.
  3. Define the Overlay IP in the route table’s destination corresponding to the ENI of the active SAP CM server.
  4. Adjust the properties of the platform and execution containers to reference the OIP.
  5. Create an AMI of the platform EC2 instance.
  6. Generate a Launch Template.
  7. Establish an Auto Scaling Group.
  8. Attach the current platform EC2 instance to the ASG.
  9. Form a Target Group with health checks using HTTPS and a health check path set to /mz/main.
  10. Update the ASG with the Load Balancer target group.
  11. Set up an Application Load Balancer targeting the target group created in Step 9.
  12. Create a lifecycle hook in the ASG and develop an SSM document to create an AMI of the instance. Establish an Amazon EventBridge rule with the SSM document as a target.

Disabling Source/Destination Checks

To disable source/destination checks on the SAP CM platform server, access the Amazon EC2 console, select the relevant EC2 instance, navigate to Actions, Networking, and then choose Change source/destination check.

For those interested in the broader implications of onboarding processes, you may find this article on the impact of fast fashion insightful. Additionally, for anyone involved with union certifications, British Columbia’s recent legislative changes may be of interest. Lastly, if you’re looking for tips on securing a position at Amazon, don’t miss this excellent resource on onboarding.

Related Topics:

HOME