Show TOC

Windows Server Failover ClusteringLocate this document in the navigation structure

Use

The high-availability configuration with Windows Server Failover Clustering is the standard failover solution for the SAP system running on Windows. In this configuration, the SAP system is installed on two or more nodes of a cluster. Under normal operation, the (ABAP) central services ((A)SCS) instance runs on one node and the database on the other node of the cluster. If one of the nodes fails, the affected (A)SCS or database instance is automatically moved to the other node, so preventing downtime. The failover mechanism is enabled by the failover cluster software and a cluster-aware version of the database management system (DBMS).

Note

“(A)SCS” means either the ABAP central services instance (ASCS) or the Java central services instance (SCS).

The main advantage of Windows Server Failover Clustering is that it improves the availability of the system and safeguards it against failure and unplanned downtime.

The cluster is normally fully transparent to clients accessing the Windows Server Failover Cluster. However, there might be a delay in the event of failure due to failure.

Note

For more information about SAP support for Windows Server Failover Clustering, see the installation guide for your SAP product at:

http://service.sap.com/instguidesNWInformation published on SAP site

Figure 1: Windows Server Failover Clustering Configuration
Features

With Windows Server Failover Clustering, SAP uses a standard high-availability solution for the SAP system on all supported hardware platforms. Automatic failover occurs rapidly without manual intervention, so you lose no time manually working out the cause of the problem and deciding how to fix it.

Activities

During the operation of an high-availability SAP system on Windows, the Windows Server Failover Clustering software monitors the system for failure and fails over services in the event of a failure. Both monitoring and failover occurs automatically, that is, without operator intervention. However, the system administrator is still responsible for solving the problem that led to failure (for example, replacing faulty hardware components).