I often hear questions like the following question asked in various forums:
How do i send an e-mail whenever a resource group fails over? How do i automate tweaking of this configuration file just before my application is started by SunCluster?
All of these can be considered a variant of the following question: "How do i run my own custom script to do this custom task just before/after a given resource/group starts?"
As people already familiar with SunCluster would know, this calls for an Agent
and SunCluster does have tools such as the Sun Cluster Agent Builder GUI
and the Generic Data Service ( GDS
) model (supported by scdsbuilder as well), for such things. Those tools are focussed more towards "applications", with the notion that there would be a set of user level daemon/processes running which would constitute the applications.
Dealing with different types of applications is a rather complex topic in itself, for today's blog, let me quickly get to a very basic approach i would like to introduce today. The approach consists of a few very simple steps.
- Create a script, which would do the specific action you want to do. Such as
logger -p user.notice Start script called with $\*
Note the "exit 0" at the end, whenever SunCluster framework calls your script, this tells the SC framework that the start operation was successful Replace syslog command with whatever it is that you wanted to do.
Let us say you name this script as startmyscagent.
- Create a script which would do the STOP action for whatever you did in the start script. If there is no need for this, skip this step. We would use /bin/true for the STOP action.
- Install your scripts in a specific location on all cluster nodes. suggest a location in /opt, such as /opt/myscagent.
- Create a Resource Type Registration (RTR) file for your agent. Call it "myscagent.rtr". It would look like the following (cut and paste into your favourite editor).
RESOURCE_TYPE = "myscagent";
This is it! Your "Agent development" is done! Now you can use SunCluster admin commands to register this resource type and create resource of this type. For example.
- scrgadm -at myscagent -f /opt/myscagent/myscagent.rtr
- scrgadm -ag RG1
- scrgadm -og RG1
- scrgadm -aj myresource1 -g RG1 -t myscagent
- scswitch -ej myresource1
Now the start script you implemented would be called everytime the RG is starting. Sometimes it is desirable to have the start script of myscagent to be called \*just before\* another existing resource on the cluster. For example, to make sure your start script is always called BEFORE a resource named "resource2" is started:
- scrgadm -c -j resource2 -y Resource_dependencies=myresource1
To be sure, this approach is very primitive. It does not differentiate between difference resources of the same resource type. The action taken is exactly the same, regardless of how many different resources you create of type "myscagent". Sure, you can create another agent call "myotherscagent" or whatever, but if the actions taken by the two RTs are very similar, it becomes cumbersome to maintain. Additionally, there is no notion of resource properties or resource monitoring, nor does it show you how to implement more advanced methods like VALIDATE and MONITOR_CHECK etc.
For simple tasks, this approach gets the job done though, and in the process you get a first hand understanding of how SunCluster Resource Group Manager (RGM) calls methods on resource type implementations.
For a deep dive into this, check out the on the Sun Cluster Agent Developer Guide
on the Sun Docs site.
Senior Software Engineer, SunCluster Engineering