This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
Accept
Reject
Preferences
Log in to ask a question
Get hands-on experience with 20+ free Google Cloud products and $300 in free credit for new customers.
Log in to ask a question

SAP High availability with Windows on Google Cloud Platform : part 1

Posted on 11-15-2024 11:43 AM
and filed in cloud-community-blog
ankitarora04
Staff

This two-part series focuses on achieving high availability for your SAP deployments on Google Cloud Platform (GCP) using Windows Server Failover Clustering (WSFC). In part one, we'll delve into the intricacies of ensuring SAP application layer high availability. Part two will cover database high availability with a focus on MS SQL Server's Always On Availability Groups, so be sure to check that out as well!

Why high availability matters for SAP

SAP systems are mission-critical for many organizations, as they were designed to manage core business processes. Any service disruption can have a ripple effect, impacting productivity, revenue, and reputation. A robust high-availability setup ensures your SAP applications remain accessible, minimizing downtime and ensuring business continuity.

Architecture overview (application layer focus)

This diagram illustrates the key components for SAP application layer HA:

image1.png

  • Windows Server Failover Clustering (WSFC): At the heart of high availability solution lies Windows Server Failover Clustering (WSFC). This technology provides the mechanism for detecting failures in your SAP application environment and automatically switching over to a redundant server. Think of it as a safety net that ensures your critical SAP applications remain accessible even if a server or component malfunctions.
  • Failure detection: WSFC constantly monitors the health of the clustered servers and resources of ASCS/ERS application. It uses various methods like heartbeat signals and resource checks to quickly identify any failures.
  • Automatic failover: If a failure is detected, WSFC automatically initiates a failover process. This involves transferring the clustered resources (ASCS/ERS) from the failed server to a healthy server in the cluster.
  • Increased availability: WSFC helps increase the overall availability of SAP systems by providing redundancy. If one server goes down, another is ready to take over, ensuring business continuity
  • Load balancing: To ensure high availability and efficient resource utilization, L4 (Layer 4) network passthrough load balancer is used. This load balancer intelligently routes incoming requests to the appropriate WSFC node based on the health and status of the ASCS instance.

The load balancer utilizes a health check probe port to determine which node in the WSFC cluster is currently running the active ASCS instance. WSFC ensures that this probe port is only active on the cluster node where the ASCS instance is running. By monitoring this probe port, the load balancer can accurately identify the active ASCS node and direct incoming requests to that node.

  • Shared storage solution: Provides consistent and accessible storage for SAP system data, ensuring data integrity and availability across all nodes.
  • Quorum: Ensures the cluster has a majority of nodes online to prevent data corruption during failover. A file share witness in a separate zone provides the quorum vote in the configuration.
  • Multiple zones: Distributing resources across different zones within a region enhances availability and protects against zone-level outages.

Steps to set up application layer HA

  1. Provisioning infrastructure:
    • Create Windows Server VMs in multiple zones within a GCP region.
    • Set up a highly available shared storage solution (e.g., Google Cloud Filestore, NetApp Cloud Volumes).
    • Configure a file share witness in a separate zone for quorum.
  2. Configuring Windows Server Failover Clustering:
    • Install the Failover Clustering feature on all participating Windows VMs.
    • Create a new cluster and add the VMs as nodes.
    • Configure the cluster network and storage settings.
  3. Setting up the load balancer:
    1. Create a load balancer in GCP and configure it as virtual IP addresses in Cluster for ASCS.
    2. Define health checks to monitor the active ASCS node of cluster
    3. Create A-record for load balancer IP that will be used for ASCS installation as a virtual hostname
  4. Installing and clustering SAP ASCS/ERS:
    • Install the ASCS/ERS instances on the cluster nodes.
    • Configure them as a clustered resource within WSFC.
  5. Deploying SAP application servers:
    • Install the SAP application server instances on the provisioned VMs.
    • Configure them to connect to the clustered ASCS instances.
  6. Testing Failover:
    • Simulate different failure scenarios to validate the HA setup.
    • Verify that the system automatically fails over to the redundant node and that SAP applications remain accessible.

Key components:

IP address planning

Proper IP address planning is essential for a successful high-availability SAP deployment on Google Cloud. Here's a breakdown of the minimum IP addresses required for our architecture:

IP Address IP Count Component Notes
Cluster IP address 1 WSFC Cluster This IP address represents the entire WSFC cluster.
Load Balancer IP address 1 Load Balancer This IP address is used for incoming SAP traffic and is typically configured as an A-record in Active Directory, pointing to the active ASCS/ERS instance.
Clustered VM IP addresses 3 (minimum) Clustered Windows VMs Each VM in the cluster (2 for ASCS/ERS and application servers + 1 for file share witness) requires its own unique IP address for communication.
Application Server IP addresses 1 per server Application Servers Each application server instance requires a dedicated IP address.

File system structure layout

MS Windows Drive Mount Storage Type
C:\program Files(X86) Local Balanced PD
D:\usr\sap Local Balanced PD
\\example\sapmnt SMB Supported Shared Storage Solution
\\example\trans SMB Supported Shared Storage Solution

Note :- This architecture works with Enqueue Replication Server 1 only.

Dive Deeper with Part2 Database High Availability with MS SQL Server's Always On Availability Groups

This blog post explored how to achieve high availability for the SAP application layer in a GCP environment. However, a truly resilient SAP landscape also requires high availability for the database layer, which was not covered in this post.

In Part 2, we'll focus on High Availability Setup of MS SQL Servers with Always On Availability Groups

Ready to complete your HA strategy?

Head over to Part 2: https://www.googlecloudcommunity.com/gc/blogs/blogworkflowpage/blog-id/cloud-community-blog/article-...

1 0 830
Article Labels