SAP on Solaris Cluster
By dlnprasad on May 26, 2009
Solaris Cluster comes bundled with rich support for numerous software
Follow the link to see a list of all the Solaris Cluster Agents available in the latest release of Solaris Cluster - SC 3.2 01/09.
For most of these applications the latest versions are supported. In this blog I specifically want to highlight the latest support
for the SAP NetWeaver stack and highlight some key features provided by Solaris Cluster to make SAP highly available on
Solaris Cluster 3.2 HA SAP Web Application Server agents now support SAP 7.1 on S10 SPARC and X64. You will need
patch# 126062-06 or later for S10 SPARC or patch# 126063-07 or later for S10 X64. This patch is required for the following
Resource Types (RTs) - SUNW.sapenq, SUNW.saprepl, SUNW.sapscs, SUNW.sapwebas. The SAP agent RTs SUNW.sap_ci_v2
and SUNW.sap_as_v2 do not support SAP 7.1 version.
All SAP Agents are supported in global containers and zone nodes (SC 3.2 support for containers).
Solaris Cluster software can be used to improve the availability of SAP components running on Solaris OS. Solaris Cluster uses
redundant components to protect against any planned or unplanned downtime - eliminating any single point of failure in the entire
stack. 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. The Agents support the following SAP installations a) ABAP only,
b) JAVA only and c) ABAP and JAVA combined.
One of the strengths and key features of Solaris Cluster is the support for multiple flavors of dependencies and affinities
between applications. Refer to the blog by Marty Rattner where he explained this in detail.
You can always refer to the "Sun Cluster Data Services Planning and Administration Guide for Solaris OS" where this topic is
explained in depth with examples.
When making the SAP Enqueue Server and Replication Server highly available in Solaris Cluster, the dependencies and affinities
play a very important role. For High Availability, 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.
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. The weak positive affinity ensures that the
Enqueue Server failsover to the node running the Replica Server. The Strong Negative affinity ensures that the Replica Server never
runs on the same node as the Enqueue Server. Check out the following diagram to understand this clearly.
In addition to affinities, dependencies 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 latter is started only after the Enqueue Server is online.
As you can see, Solaris Cluster provides several options to make SAP highly available on Solaris. In this blog I highlighted only a few.
Please refer to the Solaris Cluster HA for SAP agents administration guide for additional configuration examples.
Solaris Cluster Engineering