Implementing HA SAP NetWeaver with AnyDB on Azure VMs (part 2)
To read part 1 please click here
Add registry entries on both cluster nodes of the SAP ASCS-SCS instance
Path |
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters |
Variable
name |
KeepAliveTime |
Variable
type |
REG_DWORD
(Decimal) |
Value |
120000 |
Path |
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters |
Variable
name |
KeepAliveTime |
Variable
type |
REG_DWORD
(Decimal) |
Value |
120000 |
You have to restart both the cluster nodes to apply the changes.
Set up a Windows Server failover cluster for SAP ASCS-SCS instance
It involves the following tasks:
- Add cluster nodes to the cluster.
- Configure Cloud witness
Add cluster nodes to the cluster
You have to set up the failover cluster by using the Failover Cluster Manager:
- In the Failover Cluster Manager, select Create Cluster, and then add only the name of the first cluster.
- Enter the network name (virtual host name) of the cluster.
- After successfully creating the cluster, you have to run a validation test.
- At this point you can ignore the warnings about disks and should not worry about having a quorum.
- Bring the cluster virtual host name online.
- Now you can add the second cluster node.
Configure cloud witness
- You can't use a Blob storage account for a Cloud Witness.
- You can't use Azure Premium Storage for a Cloud Witness.
- For replication, select Locally-redundant Storage (LRS) because the Failover Clustering uses the blob file as the arbitration point, which in turn also requires some consistency guarantees while reading the data.
Note- No extra steps are required for the configuration necessary for the URL as the endpoint is generated automatically by Cloud Witness resource.
Configure failover parameters
After successfully installing the Windows Failover Clusters, you should change some thresholds, so that they can adapt to the conditions in Azure for failover detection. If you assume that your two VMs consisting teh cluster configuration for ASCS/SCS are in the same subnet, then you can easily change the following parameters to these values:
- SameSubNetDelay = 2000
- SameSubNetThreshold = 15
- RoutingHistoryLength = 30
Although all these settings are resilient enough, but they can also offer failover that is fast enough in real error conditions on a SAP atmosphere or in a node or VM failure.
To read part 1 please click here
Comments
Post a Comment