- SAP Managed Tags:
Sometimes we forget integrations when we analyze availability requirements. A case I found many times is two business-critical solutions with all mechanisms to keep them up and running 7x24. But the middleware to integrate them is a stand-alone instance. So, in case the middleware fails the business-critical solutions are impacted.
So, when you are going to design the architecture, you need to take into account the availability requirements of your middleware solution. In this article, I tell how to implement high availability and Disaster Recovery in the Integration Suite.
High Availability
This is easy. SAP Integration Suite provides high availability by default based on multi-availability zone redundancy
How? SAP Business Technology Platform provides a Service URL to connect to the “active” Integration Suite tenant. In case of failure on the availability zone of the “active” Integration Suite tenant, the failover route is activated to another availability zone with a “stand-by” Integration Suite tenant.
This architecture allows SAP to grant 99,95% of SLA (check SAP Business Technology Platform Supplemental Terms and Conditions that override SAP Service Level Agreements for cloud services for SAP Business Technology Platform, both documents in SAP Trust Center).
Disaster Recovery
As the magnitude of a disaster is unpredictable, a region might not be restored in a reasonable time for your company and you may want to set a DR solution in place.
A Disaster Recovery architecture has additional costs because you need to replicate the Integration Suite in 2 regions (or more, depending on your requirements). It means you need,
- To activate a SAP Integration Suite tenant in all those regions
- To implement a Load Balancer to provide a failover route
Consider the governance too.
When you work in a high-availability scenario, Integration Suite manages internally the replication into the availability zones. If you deploy an iFlow or an API on SAP Integration Suite, it will be available on all the availability zones, so the failover is transparent.
But if you work in a disaster recovery scenario, the replication of iFlows, APIs, etc. is not done by SAP automatically. You need to manage this and keep all Integration Suite instances aligned. This is an extra effort in maintenance, but critical: in case of failover, if the Integration Suite instances are not aligned the integrations may fail.
Regular backup of the Integration Suite content is a good practice. Just in case you missed to replicate anything from the failed region.
In addition, consider,
- In the case of DR, all the processing messages in the failed region will fail. Depending on the integration scenario you can send the same message twice and generate duplicates, or receive a reply from a message that the sender application set as not sent (i.e. asynchronous integrations)
- SAP does not manage the Load Balancer, so SAP cannot provide an SLA because it depends on the SLA of the Load Balancer. If you decide to implement this architecture, you must consider the SLA for the Load Balancer. Otherwise, you may define a solution with worse SLA
High availability and Disaster Recovery with Edge Integration Cell
Edge Integration Cell is the SAP Integration Suite extension on-premises or IaaS for ground-to-ground integrations.
It runs on Kubernetes, so to implement high-availability or disaster recovery architectures we can find 2 scenarios:
- Kubernetes on-premises: Three worker nodes are required to provide high-availability
- Kubernetes as a platform: Offers several resiliency features. Multiple availability zones are provided for Kubernetes deployments. For a high availability setup with a minimum of three worker nodes, you require 3 availability zones
Installation prerequisites for SAP Edge Integration Cell are in SAP note 3247839. High availability requirements for Edge Integration Cell are at the SAP Help Portal for Integration Suite.
But do not forget that a productive implementation requires PostgreSQL and Redis Data Store out of Kubernetes. High availability and disaster recovery for these services must have dedicated solutions. Only if you use cloud platform offerings like Azure Database for PostgreSQL, or Amazon RDS for PostgreSQL you have high availability requirements fulfilled.
In case you want to implement disaster recovery is mandatory, for both scenarios the option is to have 2 Kubernetes with,
- An additional Edge Integration Cell instance on the same SAP Integration Suite tenant. Integration Suite Standard and Premium editions come with only one Edge Integration Cell instance, but you can get additional instances
- A Load Balancer to provide a failover route
Do not forget considerations about Disaster Recovery for Integration Suite applies to Edge Integration Cell: iflow replications, risk on duplicated messages, etc. Consider SLA also depends on the infrastructure supporting the architecture. In this case, your infrastructure (on-premise or on the hyperscaler of your choice).
Conclusions
SAP provides an SLA of 99,95% using Integration Suite or Edge Integration cell with no extra mechanisms.
Remember also that SAP provides HA based on availability zones, and data backups (as snapshots) are actively replicated between those availability zones. So even if one of the availability zones is impacted by a disaster, SAP can still restore the data from the other availability zones where the same data is consistently maintained.
It’s possible to implement DR mechanisms between regions but with extra effort to manage and maintain. You have to analyze if you need a Disaster Recovery. Otherwise, the business impact cost could be worse than implementing it!
Finally, always check the latest information in the SAP Help Portal and the most recent notes.
3 Comments
