Higher Availability for R/3 Under Windows NT

Clusters provide better database- and applications-server functionality. Clustering has been around for years on platforms such as VMS and Unix, but it's relatively new to NT. NT cluster nodes share access to data and communicate on a private network via a cluster protocol that is mostly based on common protocols such as TCP/IP and NetBEUI. All clients communicate with the virtual cluster without addressing a specific server. Because existing clustering solutions for NT ha ve been proprietary, Microsoft's Wolfpack aims at standardizing clustering under NT. It uses a series of APIs to separate applications from hardware components.

Wolfpack phase 1, released early this year, is restricted to two cluster nodes and is based on NT Server 4.x. Phase 2, slated for release in 1998, will include a n extension to 16 nodes and expanded functionality on the basis of NT Server 5.x.

R/3 includes an internal load-distribution and redundancy concept. However, the R/3 server services that manage file sharing and interprocess communications (IPC)--as well as the DBMS and the SAP Central Instance (CI) containing lock-manager and message services--can exist only once on a network. That's why these single points of failure need to be secured via clustering.

The DBMS and the CI are usually the major components of a cluster. This means that despite clustering, the R/3 database, which usually comprises several hundred gigabytes, exists only once. How ever, in the future, DBMS replication mechanisms may reside inside the cluster.

The implementation of the DBMS and the CI inside the cluster allows for several scenarios in case of failure, the only restrictions being a uniform OS in the cluster, which is relevant for mixed Unix/NT environments, and the maximum number of two NT cluster nodes.

In a typical NT failover scenario (see the figure "R/3 in the Cluster" ), the DBMS and the CI may be located on cluster node 1. The second cluster node may operate as an applications server. In case of the failure of cluster node 1, all server services (DBMS and R/3 services for the CI) must be shifted to cluster node 2 (switch over).

However, because coexistence of the applications-server functionality and the CI is not possible on one cluster node , the applications server must be stopped beforehand. Users working on this applications server have to log on to an external applications server (ASE) or automatically be requested to r econnect to the CI. The latter assumes that the corresponding user interaction processes have been configured on the CI. This means that R/3 enables reconnections of the front end to the applications server as well as of the ASE to the CI and the CI to the DBMS. (The latter two depend on the corresponding functions of the DBMS Networking Transport Mechanism such as Oracle SQL Net.)

---

R/3 in the Cluster

illustration_link (38 Kbytes)

The type of failover scenario depends on user requirements and performance of cluster nodes.