Geographically dispersed cluster configuration for SAP on Windows / SQL Server
Our competitors often mention to our customer base, that it is not possible running a SAP environment on the Windows / SQL Server platform, which is distributed over two different datacenters with high availability or disaster recovery functionality.
This article describes different possibilities to run SAP systems on a dual datacenter strategy with HA/DR separated over two locations.
Geographically Dispersed Cluster
The Microsoft Windows Server Failover Cluster Functionality (WSFC) software allows you to configure your SAP system to run on at least two WSFC nodes (servers). In the event of hardware or software problems on one node, the cluster resources fail over automatically from one node to the other. If you need to maintain one WSFC node, you can manually switch the cluster resources to the other WSFC node and temporarily operate it there until maintenance work is finished. This mechanism is called failover and allows the system to function normally so avoiding unplanned system downtime.
The following picture shows the standard implementation of SAP running on Windows / SQL on a WSFC cluster.
As shown in the picture, Microsoft WSFC is only working with one shared storage unit per default.
WSFC does not provide a software mechanism for replicating application data from one site to another.
A geographically dispersed cluster requires multiple storage arrays, at least one in each site, to ensure that in the event of failure at one site, the remaining site will have local copies of the data. In addition, the nodes of a geographic cluster are connected to storage in such a way that when there is a failure at one site or a failure in communication between sites, the functioning nodes can still connect to storage at their own site.
In order to enable a fast failover on a secondary site in case a catastrophic event occurs, a synchronous copy of the file system in use by the SAP application side the DBMS side has to be maintained on each site. This block-level replication can be achieved with hardware or software-based replication.
Hardware-based replication
With this method, the complete replication task is done at the storage level (see picture below).
The advantage of this solution is that it works completely independent from the application. However, as the replication is performed by the storage controller, the SAN storage devices have to be from the same vendor and there is a high bandwidth requirement for the replication. Additionally, software components from the storage vendors are required to enable the Windows cluster to appropriately use this configuration. Examples of storage based replication providers are:
- EMC with SRDF and SRDF/CE
- HP Storage Works Business Copy EVA and CLX
- NetApp MetroCluster with SyncMirror
- IBM GDPS with PPRC
To avoid the usage of the additional software inside the Windows cluster, new storage virtualization technology can be used to replicate and present the data to all the server nodes in the cluster independent from their location (see picture below).
Examples for such storage virtualization products are:
- Falconstore
- IBM SVC
- HP SVSP
Software-based replication
In case of a software based replication solution, we need to separate between the DB and the SAP application layer; because different functionalities need to be used.
On the database backend the SQL Server database mirroring functionality is used to replicate the data from the primary location to the second datacenter. With this method, any change on the active side is copied over the network to the secondary side and replicated there.
For the SAP application part the SAPMNT share with all related data needs to be keeping in sync over the two locations. This could be done by using the WSFC functionality in addition of a software replication tool for this specific LUN.
This requires the use of a software product which is not part of the initial cluster setup. While these software components increase the implementation cost, the advantage is that different storage devices can be used. It is even possible to have SAN storage on one side and a Direct Attached Storage (DAS) on the other side. Examples of vendors for software-based replication products include:
- NSI Double-Take
- Legato RepliStor
- Symantec Storage Replicator
- SteelEye DataKeeper
- Neverfail ClusterProtector
The solution based on software replication is totally independent of the storage layer as shown in the following picture:
All these solutions are used by various customers for running their productive SAP systems in a high availability environment.
The latest implementation projects show a clear trend towards the storage replication technology. This reduces the complexity of the implementation (e.g.: no 3rd party software or additional software inside the Microsoft cluster) and provide a independency from the physical SAN layout underneath the storage virtualization.
Comments
Anonymous
October 26, 2010
Guido, You say "configure your SAP system to run on at least two WSFC nodes (servers)." Do you know if SAP supports more than a 2-node cluster for the SAP portion of the install? Also, what versions of SAP (if any) support more than two nodes as I can only find documentation that says they support a 2-node cluster only. We have a customer who wants to do this but are fearful that SAP will not support them. - Thanks!Anonymous
October 26, 2010
Excellent article, thank you! Can you clarify one thing. As far as I can tell from the SAP documentation, SAP only supports a 2-node cluster (see page 19) "The (A)SCS instance must be installed and configured to run on two MSCS nodes in one MSCS cluster." www.sdn.sap.com/.../e0b8cd93-f1e9-2910-c186-86bfff3dac63 Am I reading this wrong or is there newer guidance to suggest that you might be able to deploy 3 or 4 node clusters geographically dispersed? If so, can you provide pointers to that documentation on the SAP web site?