Highly available SAP with Db2 on IBM Cloud VPC
Many organizations run SAP applications by using an IBM Cloud Db2 database to support the SAP instance. This pattern describes a highly available implementation of both SAP and Db2 to deliver a resilient solution to meet an organization's business needs.
SAP systems are often mission-critical for the organizations that use them. Providing a highly available SAP Application Server offers minimal benefit unless the underlying database - IBM Db2 in this case - is also made highly available. The architecture for this pattern provides a highly available database layer, which underpins a highly available application server layer running within IBM Cloud® Virtual Private Cloud.
Architecture diagram
The following diagram shows the high level reference architecture for this pattern:
Users access the IBM Cloud® environment by using a Virtual Private Network (VP) across the Internet or a private Direct Link connection.
Administrative access to the environment is recommended by using a bastion host. This access provides a secure access point for systems management activities. Bastion hosts can also provide session logging for audit purposes, allowing all management activities to be securely logged. If an incident or problem occurs, there is a record of what actions were performed that caused the issue.
As was briefly described, the underlying IBM Db2 database is made highly available by using multiple database server nodes. If there is a failure of the primary database server, a secondary backup server is available to take over the primary's workload. The cluster of nodes is managed by the IBM Db2 integrated Pacemaker cluster management software. This monitors the health of the environment and responds to incidents by managing the failover of the database from one node to another.
The SAP application server instances run in a separate Pacemaker-managed cluster. Similar to the database cluster, Pacemaker manages the failover of the SAP components from one node to another following a failure.
Design concepts
The following diagram shows the infrastructure and software stack for the solution:
This diagram shows how the various components of the pattern deliver high availability.
-
IBM Db2 database data is replicated from the primary database server to the secondary backup database server by using an IBM Db2 component called high availability disaster recovery (HADR).
-
Users and applications including SAP access the databases through the IP address of the database service. This is deployed as a virtual IP (VIP) address. Pacemaker manages the failover of this VIP between the database servers when a failover occurs.
-
Two key SAP components in the SAP instance are available, the ABAP SAP Central Services (ASCS) and Enqueue Replication Server (ERS). Just as Db2 uses its HADR component to replicate data between the servers in its Pacemaker cluster, SAP uses a technique that is called Enqueue Replication to do the same.
-
SAP applications also access the SAP application server and ASCS through a virtual IP address that can move between systems when failures occur. Pacemaker manages the movement of the virtual IPs for both ASCS and ERS as required.
Review the design considerations and architecture decisions for the following aspects and domains:
- Compute: Virtual servers or bare metal servers
- Storage: Primary storage
- Networking: Enterprise connectivity, load balancing, and Domain Name Services(DNS)
- Application platforms: Enterprise applications
- Resiliency: High availability
- Service management: Management and orchestration
Design choices
Cluster management software
Various different solutions are available that provide cluster management, both open source and proprietary. This pattern uses the open source Pacemaker software to manage the cluster resources for the SAP applications and the IBM Db2 integrated Pacemaker to manage the Db2 resources, controlling and orchestrating the failover and failback of resources when the cluster configuration changes as cluster nodes leave and rejoin the cluster.
Other solutions from the open source community or from other commercial organizations are also available. Check out the open source projects websites or the documentation that is provided by commercial organizations for more information on how these can be incorporated within this architecture.
Storage options
The pattern uses two key storage options. IBM Cloud provides VPC File Storage. This can be used to provide a shared file system that is accessed by the SAP application server nodes within the Pacemaker cluster.
Block storage for the database instances, both primary and secondary, is delivered through IBM Cloud® Bare Metal Servers for Virtual Private Cloud if VSIs are used as database servers. If the decision is made to use Bare Metal Servers for VPC, this storage can be provided by solid-state drives within the physical server. This offers faster performance than VPC Block Storage that is accessed across the network.
Application server nodes
Two options are available for application server nodes, virtual servers (VSIs) or Bare Metal Servers. There are many different VSI profiles that can be chosen to best meet the compute and memory requirements of the application that are run within the environment. SAP must support these VSI profiles.
Database server nodes
Two options are available for database server nodes, virtual servers (VSIs), or Bare Metal Servers. There are many different VSI profiles that can be chosen to best meet the compute and memory requirements of the database.
Requirements
The following table outlines the requirements that are addressed in this architecture.
| Aspect | Requirements |
|---|---|
| Compute | Provide properly isolated compute resources with adequate compute capacity for the applications. |
| Storage | Provide storage that meets the application server and database performance requirements. |
| Networking | Deploy workloads in an isolated environment and enforce information flow policies. Provide secure, encrypted connectivity to the cloud’s private network for management purposes. Distribute incoming application requests across available compute resources. Support failover of the application and database to alternative servers if a planned or unplanned outage occurs. Provide private DNS resolution to support use of hostnames instead of IP addresses and support cluster failover. |
| Security | Ensure that all operator actions are run securely through a bastion host. Protect the boundaries of the application against denial-of-service and application-layer attacks. Encrypt all application data in transit and at rest to protect it from unauthorized disclosure. Encrypt all backup data to protect it from unauthorized disclosure. Encrypt all security data (operational and audit logs) to protect from unauthorized disclosure. Encrypt all data by using customer-managed keys to meet regulatory compliance requirements for additional security and customer control. Protect secrets through their entire lifecycle and secure them using access control measures. |
| Resiliency | Support application availability targets and business continuity policies. Ensure availability of the application if a planned and unplanned outage occurs. Provide highly available compute, storage, network, and other cloud services to handle application load and performance requirements. Backup application data to enable recovery if an unplanned outage occurs. Provide highly available storage for security data such as logs and backup data. Automate recovery tasks to minimize downtime. |
| Service management | Monitor system and application health metrics and logs to detect issues that might impact the availability of the application. Generate alerts and notifications about issues that might impact the availability of applications to trigger appropriate responses to minimize downtime. Monitor audit logs to track changes and detect potential security problems. Provide a mechanism to identify and send notifications about issues that are found in audit logs. |
Components
The following table outlines the products or services that are used in the architecture for each aspect:
| Aspects | Architecture component | How the component is used |
|---|---|---|
| Compute | Virtual Servers for VPC | Application server and database Server nodes |
| Bare Metal Servers for VPC | Application server and database server nodes (option) | |
| Storage | VPC File Storage | File storage used by SAP Application Servers |
| VPC Block Storage | File storage used by Db2 Database Servers | |
| Networking | Virtual Private Endpoint (VPE) | For private network access to Cloud Services, for example, Key Protect, IAM, and so on. |
| Public gateway | For secure client access to the high-performance computing (HPC) environment over the Internet | |
| Direct Link | For private, dedicated connectivity between on-premises and cloud HPC resources | |
| Security | Identity and Access Management | Identity and Access Management |
| Key protect or Hyper Protect Crypto Services | Hardware security module (HSM) and Key Management Service | |
| Secrets Manager | Certificate and secrets management | |
| Resiliency | Pacemaker | The Pacemaker software manages failures of application or database server nodes by managing failover to a surviving cluster node (VSI or bare metal) |
| Service Management | IBM Cloud monitoring | Operational monitoring |
| IBM Cloud Logs | For all IBM Cloud related Logs | |
| Event Routing | For all IBM Cloud events |