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
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
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
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
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.
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
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
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