Tuesday May 26, 2009

SAP on Solaris Cluster

Solaris Cluster comes bundled with rich support for numerous software applications.

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.

Prasad Dharmavaram
Solaris Cluster Engineering

Monday Jun 11, 2007

On the Road to Open-Source Cluster Code!

To those of you who have been following Sun's software strategy, it should come as no surprise that we've been thinking about open-sourcing Sun Cluster. As the first (public) step in this direction, I've recently proposed an HA Clusters community on opensolaris.org. You can read the initial post here, and find the whole discussion in the June archives here.

To quote from my community proposal email:

Sun Microsystems will contribute to the community the source code for
Solaris Cluster, Sun's commercial HA Cluster product group, under the
name “Open High Availability Cluster.” This contribution will start at
the time of community formation with the Sun Cluster Agents source for a
wide portfolio of applications.

Stay tuned for more details!

Nick Solter
Solaris Cluster Development

Tuesday Nov 14, 2006

Sun Cluster Data Services

Sun Cluster software provides the framework and API required to make applications highly available on Solaris OS. The software application, designed for solaris, does not have to be modified to use Sun Cluster API. Instead, you write an agent which acts as the interface between Sun Cluster core software and the application. Sun Cluster comes bundled with a rich portfolio of agents, also called data services, which make applications highly available on Sun Cluster software. These agents, designed and developed by the Sun Cluster Engineering team, have undergone rigourous testing by the internal Quality Assurance engineers.

Agents for the the following software products are available in Sun Cluster 3.1 and the upcoming Sun Cluster 3.2 releases. The following list is not in any particular order:

Oracle Database
Sybase ASE
Oracle's Siebel CRM (server and gateway)
BEA WebLogic Server
NFS Server (SC 3.2 supports the latest NFS V4)
Apache Web Server
Sun Java ES Web Server
Sun Java ES Application Server
Sun Java ES Message Queue Broker
Solaris DHCP
Oracle E-Business Suite
Oracle Application Server
Apache Tomcat
SWIFTAlliance Access
SWIFTAlliance Gateway
IBM WebSphere MQ
Sun N1 Grid Engine
Sun N1 Service Provisioning system
SAP Web Application Server
SAP liveCache
MaxDB (previously called SAP DB)

In some cases I might not have listed the actual name of the product, as listed in the product manuals of the ISV. Please check with the ISV for the exact product name. The above list is provided to give you a high-level view of the rich application support on Sun Cluster software. If you want more details on how to configure and administer the agents for the above applications, please refer to the Data Service administration guides available at:

Sun Cluster 3.1 8/05 Software Collection for Solaris OS

As you can see, the list is very long. In addition to the agents from Sun Cluster Engineering, some internal Sun product groups and ISVs have agents for Sun Cluster software. IBM has designed and developed agents for some components of the IBM Informix and IBM DB2 product family. Symantec supports a Sun Cluster agent for Veritas NetBackup. The Sun Java ES Directory Server, Sun Java ES Messaging Server, and Sun Java ES Calender Server groups have written agents for Sun Cluster software which are bundled with the respective products.

If your application is not in the above list, then there is nothing to worry about. It is very easy to write an agent for Sun Cluster software by using the Data Service Development tools available in the product.

You need to first check  if your application can be made highly available on Sun Cluster software. This chapter in the Sun Cluster Data Services Developer's Guide lists everything you need to verify your application's cluster readiness. Most of the applications can be integrated with Sun Cluster software right out of the box. Sometimes you might have to enhance the application a little bit to be able to integrate with Sun Cluster software. Once the application is ready for integration, use the Sun Cluster Agent Builder to generate an agent for you. The Sun Cluster Agent Builder not only generates the code for you but also generates the Makefiles to compile the code and build a nice Solaris package. This generated package can be easily installed by using the pkgadd utility.

If you do not want to write a seperate agent for your application, you can use the Generic Data Service (GDS) agent to make your application HA on Sun Cluster software. Generic Data Service, as the name suggests, is a generic agent designed by Sun Cluster Engineering. GDS takes as an input, scripts to start, stop, validate, and probe an application. Instead of writing a separate agent for your application, you just write scripts to start, stop, validate, and probe your application and supply these scripts as extension properties to the GDS resource at the time of creation.

You can refer to the Sun Cluster Data Services Developer's Guide and the Sun Cluster Concepts Guide for further details.

Prasad Dharmavaram
Sun Cluster Engineering


Oracle Solaris Cluster Engineering Blog


« July 2016