Introduction
This blog is to write about the Idea to consume the high availability solution of SAP Cloud connector, where SAP ABAP application is calling the cloud services using RFC(Om-Premise to Cloud connectivity) using cloud connector.
With SAP cloud connector we have the high availability setup(Master – Shadow instances), which is more than enough for cloud to on-premise connections to have seamless connectivity, wherein calling the cloud services from on-premise we need additional setup to utilize the high availability setup, like some short of cluster or load balancers to identify and redirect the traffic always to master node.
Here we will discuss on using the Azure TCP load balancer between the SAP ABAP and SAP Cloud Connector and use TCP load balancer IP/FQDN in the SAP RFC connection.
Analysis based on various SAP Note, SAP community blogs and Microsoft learning blogs.
Pre-requisite
SAP cloud connector 2.15.0 (Master Role Check monitoring API) required as Master role check monitoring API is available with version 2.15.0 onwards. Azure TCP load balancer -> For traffic routing to master node based on the results of calling the Master Role Check monitoring API for the SAP cloud connector Nodes available in the backend pool using the health probes.
Custom HTTP/HTTPS health probe for Azure Load Balancer will be required to translate the result(true) of Master Role check API to http status code 200 for marking the master node as healthy to route all the traffic to master node.
Solution
Configure SAP Cloud Connector instance in high availability setup:Set up two SAP Cloud Connector instances: a Master instance and a Shadow instance, both should be configured.sapcc1 as master and sapcc2 as shadow instance
Ensure both instances are registered and operational, with the Shadow instance ready to take over if the Master becomes unavailable. Configure a service channel to be called by ABAP client RFC.
Target host used in the RFC will be the IP/FQDN of the TCP load balancer deployed in below steps. For our demo we used the instance as 85 on SAP RFC i.e. 3385 as service channel port
Deploy a TCP Load Balancer in Azure: Create a Standard TCP Load Balancer in Azure, which can distribute traffic based on the TCP connections to either the Master or the Shadow SCC instance. Assign a Frontend IP: Choose whether to use a public or private IP, depending on whether the load balancer needs to be accessible internally or externally. Set up a Backend Pool: Add both the Master and Shadow SCC instances (or the respective VMs hosting these instances) to the backend pool.
Set Up Health Probes for Failover: Create a HTTP health probe for monitoring the master SCC instances. Specify the custom URI/API to determine the master SCC instance (refer to custom health probe creation/configuration to consume the Master role check API available in SCC). Here we are using the custom API(Python API to consume SCC master role check API) hosted as service on the SCC VM’s.
Python sample code used and deployed as service and configured to start automatically-
from flask import Flask, jsonify
import requests
import logging
app = Flask(__name__)
# Configure logging
#logging.basicConfig(level=logging.DEBUG)
@app.route(‘/api/checkMasterRole’, methods=[‘GET’])
def check_master_role():
external_api_url = “https://<SAPCC hostname>:8443/exposed?action=hasMasterRole”
try:
response = requests.get(external_api_url, verify=False) # Set verify=True for production
response.raise_for_status() # Raise an error for bad HTTP responses
# Log the response content for debugging
#app.logger.debug(f”Response content: {response.content}”)
# Check if the response is a string representation of a boolean
response_text = response.text.strip().lower()
if response_text == ‘true’:
return jsonify({“status”: “healthy”}), 200 # Return 200 if master role is true
elif response_text == ‘false’:
return jsonify({“status”: “unhealthy”, “reason”: “Not master”}), 503 # Return 503 if not master
else:
#app.logger.error(“Response is not a recognized boolean”)
return jsonify({“status”: “error”, “message”: “Unexpected response format”}), 500
except requests.exceptions.HTTPError as http_err:
#app.logger.error(f”HTTP error occurred: {http_err}”)
return jsonify({“status”: “unhealthy”, “reason”: “HTTP error”}), 503
except Exception as e:
#app.logger.error(f”An error occurred: {str(e)}”)
return jsonify({“status”: “error”, “message”: “Internal Server Error”}), 500
if __name__ == ‘__main__’:
app.run(host=’0.0.0.0′, port=5000)Configure the probe with suitable intervals (e.g., 5 seconds) and a threshold for the number of consecutive failures (e.g., 2) to ensure quick failover. Define Load Balancing Rules: Configure a Load Balancing Rule to map incoming TCP traffic from the frontend IP to the backend pool. Set the rule to use the same port that the ABAP client RFC uses to connect to SCC 33<nr> where nr is the instance no. mentioned on the ABAP client RFC.
Test and Validate the Setup: Use Azure Monitor to track metrics and validate the health probe statuses.
Change the ABAP client RFC connection to use the fqdn/IP of the load balancer in hostname.Test the setup by accessing the service channel using the RFC connection from the ABAP client system. The TCP Load Balancer should direct traffic to the Master instance by default. Simulate a failure on the Master SCC instance to verify that the load balancer correctly routes traffic to the Shadow SCC instance.sapcc1 as shadow and sapcc2 as master.
Reference articles-
https://help.sap.com/docs/connectivity/sap-btp-connectivity-cf/configure-service-channel-for-rfc
https://d.dam.sap.com/a/QJYXmLy/RTI_Communcation_Setup_Guide_v.2.5.pdf?rc=67&inline=true
3439494 – IBP RTI – Cloud Connector high availability setup
https://help.sap.com/docs/connectivity/sap-btp-connectivity-cf/monitoring-apis
https://learn.microsoft.com/en-us/azure/load-balancer/
https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-custom-probe-overview
https://learn.microsoft.com/en-us/azure/load-balancer/create-custom-http-health-probe-howto
IntroductionThis blog is to write about the Idea to consume the high availability solution of SAP Cloud connector, where SAP ABAP application is calling the cloud services using RFC(Om-Premise to Cloud connectivity) using cloud connector.With SAP cloud connector we have the high availability setup(Master – Shadow instances), which is more than enough for cloud to on-premise connections to have seamless connectivity, wherein calling the cloud services from on-premise we need additional setup to utilize the high availability setup, like some short of cluster or load balancers to identify and redirect the traffic always to master node.Here we will discuss on using the Azure TCP load balancer between the SAP ABAP and SAP Cloud Connector and use TCP load balancer IP/FQDN in the SAP RFC connection.Analysis based on various SAP Note, SAP community blogs and Microsoft learning blogs.Pre-requisiteSAP cloud connector 2.15.0 (Master Role Check monitoring API) required as Master role check monitoring API is available with version 2.15.0 onwards. Azure TCP load balancer -> For traffic routing to master node based on the results of calling the Master Role Check monitoring API for the SAP cloud connector Nodes available in the backend pool using the health probes. Custom HTTP/HTTPS health probe for Azure Load Balancer will be required to translate the result(true) of Master Role check API to http status code 200 for marking the master node as healthy to route all the traffic to master node.Solution Configure SAP Cloud Connector instance in high availability setup:Set up two SAP Cloud Connector instances: a Master instance and a Shadow instance, both should be configured.sapcc1 as master and sapcc2 as shadow instance Ensure both instances are registered and operational, with the Shadow instance ready to take over if the Master becomes unavailable. Configure a service channel to be called by ABAP client RFC. Target host used in the RFC will be the IP/FQDN of the TCP load balancer deployed in below steps. For our demo we used the instance as 85 on SAP RFC i.e. 3385 as service channel portDeploy a TCP Load Balancer in Azure: Create a Standard TCP Load Balancer in Azure, which can distribute traffic based on the TCP connections to either the Master or the Shadow SCC instance. Assign a Frontend IP: Choose whether to use a public or private IP, depending on whether the load balancer needs to be accessible internally or externally. Set up a Backend Pool: Add both the Master and Shadow SCC instances (or the respective VMs hosting these instances) to the backend pool. Set Up Health Probes for Failover: Create a HTTP health probe for monitoring the master SCC instances. Specify the custom URI/API to determine the master SCC instance (refer to custom health probe creation/configuration to consume the Master role check API available in SCC). Here we are using the custom API(Python API to consume SCC master role check API) hosted as service on the SCC VM’s. Python sample code used and deployed as service and configured to start automatically-from flask import Flask, jsonify
import requests
import logging
app = Flask(__name__)
# Configure logging
#logging.basicConfig(level=logging.DEBUG)
@app.route(‘/api/checkMasterRole’, methods=[‘GET’])
def check_master_role():
external_api_url = “https://<SAPCC hostname>:8443/exposed?action=hasMasterRole”
try:
response = requests.get(external_api_url, verify=False) # Set verify=True for production
response.raise_for_status() # Raise an error for bad HTTP responses
# Log the response content for debugging
#app.logger.debug(f”Response content: {response.content}”)
# Check if the response is a string representation of a boolean
response_text = response.text.strip().lower()
if response_text == ‘true’:
return jsonify({“status”: “healthy”}), 200 # Return 200 if master role is true
elif response_text == ‘false’:
return jsonify({“status”: “unhealthy”, “reason”: “Not master”}), 503 # Return 503 if not master
else:
#app.logger.error(“Response is not a recognized boolean”)
return jsonify({“status”: “error”, “message”: “Unexpected response format”}), 500
except requests.exceptions.HTTPError as http_err:
#app.logger.error(f”HTTP error occurred: {http_err}”)
return jsonify({“status”: “unhealthy”, “reason”: “HTTP error”}), 503
except Exception as e:
#app.logger.error(f”An error occurred: {str(e)}”)
return jsonify({“status”: “error”, “message”: “Internal Server Error”}), 500
if __name__ == ‘__main__’:
app.run(host=’0.0.0.0′, port=5000)Configure the probe with suitable intervals (e.g., 5 seconds) and a threshold for the number of consecutive failures (e.g., 2) to ensure quick failover. Define Load Balancing Rules: Configure a Load Balancing Rule to map incoming TCP traffic from the frontend IP to the backend pool. Set the rule to use the same port that the ABAP client RFC uses to connect to SCC 33<nr> where nr is the instance no. mentioned on the ABAP client RFC. Test and Validate the Setup: Use Azure Monitor to track metrics and validate the health probe statuses. Change the ABAP client RFC connection to use the fqdn/IP of the load balancer in hostname.Test the setup by accessing the service channel using the RFC connection from the ABAP client system. The TCP Load Balancer should direct traffic to the Master instance by default. Simulate a failure on the Master SCC instance to verify that the load balancer correctly routes traffic to the Shadow SCC instance.sapcc1 as shadow and sapcc2 as master. Reference articles- https://help.sap.com/docs/connectivity/sap-btp-connectivity-cf/configure-service-channel-for-rfc https://d.dam.sap.com/a/QJYXmLy/RTI_Communcation_Setup_Guide_v.2.5.pdf?rc=67&inline=true3439494 – IBP RTI – Cloud Connector high availability setup https://help.sap.com/docs/connectivity/sap-btp-connectivity-cf/monitoring-apis https://help.sap.com/docs/connectivity/sap-btp-connectivity-cf/monitoring-apis#loiof6e7a7bc6af345d2a… https://learn.microsoft.com/en-us/azure/load-balancer/ https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-custom-probe-overview https://learn.microsoft.com/en-us/azure/load-balancer/create-custom-http-health-probe-howto Read More Technology Blogs by Members articles
#SAP
#SAPTechnologyblog