Among the many software applications supported by Solaris Cluster 3.2 01/09 is support for the SAP NetWeaver stack which Prasad Dharmavaram discusses in a recent blog post.

The blogger explains that Solaris Cluster 3.2 HA SAP Web Application Server agents now support SAP 7.1 on Solaris 10 SPARC and X64, adding that patches are required for both Solaris 10 SPARC and X64, in particular for the following Resource Types (RTs): SUNW.sapenq; SUNW.saprepl; SUNW.sapscs; and SUNW.sapwebas. The SAP agent RTs SUNW.sap_ci_v2 and SUNW.sap_as_v2 do not support SAP 7.1 version, he notes. All SAP Agents are supported in global containers and zone nodes (SC 3.2 support for containers), he points out.

According to the blog, Solaris Cluster software can be used to improve the availability of SAP components running on Solaris OS. Because Solaris Cluster uses redundant components to protect against any planned or unplanned downtime, there is no single point of failure in the entire stack, Dharmavaram writes.

Furthermore, Solaris Cluster provides HA agents for SAP CI (Central Instance), SAP Enqueue Server, Replica Server, Message Server, Web Application Servers, SAP MaxDB and SAP LiveCache. These Agents support the following SAP installations: a) ABAP only, b) Java only and c) ABAP and Java combined.

The blog asserts that one of the strengths and key features of Solaris Cluster is the support for multiple flavors of dependencies and affinities between applications, referring readers to a blog by Marty Rattner that explains this capability in detail.

Dharmavaram also comments on the role played by dependencies and affinities involved in having Solaris Cluster make the SAP Enqueue Server and Replication Server highly available. For High Availability, he explains, the Enqueue Server and the Replica Server must run on different nodes. "If the node running the Enqueue Server goes down then the Enqueue Server must be started on the node where Replica Server is running. When the Enqueue Server starts, the replication table, stored on the replication server, is transferred to the standalone Enqueue Server and the new lock table is created from it. After the Enqueue Server has started, the Replica Server must be failed over to another node in the cluster to continue replication of the lock table."

Pursuing this line of thought, the blog explains that this can be easily accomplished in Solaris Cluster by setting a weak positive affinity between the Enqueue Server and the Replica Server and a strong negative affinity between the Replica Server and the Enqueue Server. Dharmavaram writes that the weak positive affinity ensures that the Enqueue Server failover to the node running the Replica Server, while the Strong Negative affinity ensures that the Replica Server never runs on the same node as the Enqueue Server. He clarifies his explanation with a diagram.

The blog goes on to discuss the dependencies, which also play a very critical role: A dependency between SAP resource and a database resource ensures that the database is started first before SAP servers are started. Also, a resource dependency between Enqueue resource and a Replica resource ensures that the latter is started only after the Enqueue Server is online.

More Information

Sun Cluster Data Services Planning and Administration Guide for Solaris OS

Solaris Cluster 3.2 Second Update Release - Version 3.2 1/09

Using Zone Clusters in Solaris Cluster 3.2 Update 2 [...read more...]

		fullsource
Print Email Current Profile Archive Blog Generate newsletter