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

[ankitarora04]

In part one of this series, we explored how to achieve high availability for the SAP application layer using Windows Server Failover Clustering (WSFC) on Google Cloud Platform (GCP). Now, let's dive into the crucial aspect of database layer high availability, focusing on MS SQL Server's Always On Availability Groups.

Why database high availability is critical for SAP

Database is the heart of the SAP system, storing all your critical business data. Any disruption to the database can bring your entire SAP landscape to a halt. Always On Availability Groups provide a robust solution to ensure your database remains highly available and fault-tolerant, minimizing downtime and data loss.

Architecture overview (database layer focus)

This diagram highlights the key components for database high availability:

• Always On Availability Groups with synchronous commit: Always On Availability Groups is a powerful feature within MS SQL Server that enables high availability for databases. It allows you to create a synchronized replica of database on a separate server, ensuring data redundancy.

  SQL Server Enterprise's Always On Availability Groups (AG) feature enables database replication across multiple instances. This configuration provides failover protection at the database group level, eliminating the need for shared storage.

  • Windows Server Failover Clustering (WSFC): Always On Availability Groups are integrated with WSFC, providing a unified high availability solution for databases. WSFC manages the failover process for the Availability Group, ensuring a smooth transition to the Standby node in case of a failure.

    Clustered nodes are deployed in different zones GCP region provides protection against zone-level outages.

    • Automatic failover: If the primary database server or instance fails, the Availability Group in sync with the cluster setup ensures automatic failover to the standby. This ensures that SAP applications can continue accessing the database with minimal interruption. With the failover, load balancer ensures that the application requests are routed to the new primary.
    • Load balancer: The internal load balancer, plays a vital role in directing SAP application traffic to the appropriate database server. It uses a health checks probe port to determine which node in the WSFC cluster hosts the active SQL Server instance within the Availability Group. This ensures that application requests are always routed to the currently active (primary) database server.

Steps to set up database HA with Always On Availability Groups

1. Configure cluster settings:
   Ensure that the SQL Server instances are registered in WSFC.
   • Create a cluster role for the Availability Group.
   • Configure the cluster role to depend on the SQL Server instances and any other related resources.
2. Configure load balancer:
   • Configure the load balancer to monitor the health of the SQL Server instances in the Availability Group.
   • Use a health check probe to determine which node hosts the active SQL Server instance.
   • Ensure that the load balancer routes SAP application traffic to the active database server.
3. Enable Always On Availability Groups:
   
   • In SQL Server Configuration Manager, enable the Always On Availability Groups feature on both the primary and secondary SQL Server instances.
4. Create an Availability Group:
   
   • In SQL Server Management Studio, launch the New Availability Group Wizard.
   • Specify the Availability Group name and select the SAP database to be included.
   • Choose the synchronous commit mode for data protection.
   • Configure the primary and standby replicas, ensuring they reside on different WSFC nodes and in different zones.

By implementing Always On Availability Groups as described in this blog post, you can create a highly available and fault-tolerant database layer for your SAP environment on Google Cloud. This ensures business continuity and protects your critical SAP data from potential disruptions.

Key components

IP Address	IP Count	Component	Notes
Cluster IP address	1	WSFC Cluster	This is a virtual IP address that represents the entire WSFC cluster.
Load Balancer IP address	1	Load Balancer	This IP address is used for incoming traffic from SAP Application to Database
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.

Frequently asked question:

1. Can other supported shared storage solutions, besides a file share from a VM, be used for the witness?

   Yes, Google cloud supported shared storage solution can be used for file share.