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:
Some usefule links talking about the whole HA type and its availabilities
http://help.sap.com/saphelp_nw73ehp1/helpdata/en/45/237d7e9f9b4002e10000000a155369/content.htm
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).
No comments:
Post a Comment