Video Screencast Help

capability to call preonline/postonline external scripts as res-grp attributes

Created: 27 Apr 2010 • Updated: 04 Aug 2010 | 7 comments
martin2176's picture
3 Agree
0 Disagree
+3 3 Votes
Login to vote
Status: Reviewed

Preonline and PostOnline are the most common used triggers.

I know triggers exists to call preonline scripts etc..but it would be very handy if VCS resource group has an attribute to call external scripts just like triggers

This doesnt mean we should take out the trigger capability associated with resource group state changes..they can continue to exist
But add new attribute associated with resource group or even resource to call external script  as preonline and postonline
for eg new attributes to resource group:
Preonline script "xxx"
Postonline script "yyy"

many customers I have worked with need to call some pre or post scripts as part of bringing up a resource group or resource.

Integrating and testing triggers is an overkill in most situations. A simple attribute associated with Res grp or Resource  would come in very handy

For instance: IP agent
we have a case where we have multiple vlans on cluster node. I need to swing the default gateway of the node from one gateway addr to another so as to eliminate asymetric routing issues.
This is usually the case when you have QA server running as hot standby for prod services. QA and Prod would be on different VLANs.So when Prod services are failed over ( VCS shutting down QA automatically ) the def-router address on server need to change from QA gateway to Prod gateway.
I could do this by trigger but testing is a pain.
IF an attribute exists in resource group or resource, for calling an external script as preonline or postonline, situations like this will be very easy to implement

Comments 7 CommentsJump to latest comment

martin2176's picture

since the script attributes are resource group specific, there is no need to test extensively as in triggers.Because it would affect only that particular res group.

When you are using triggers you need to parse  out resource group, sys name etc to decide which resource group should have the script executed
But adding as group attribute means you call that script only when a state change happens for that Resgroup only

Login to vote
AHerr's picture

Hi Martin,

I think you have an interesting idea but if you are looking to execute a script when a resource comes online, you can implement an application agent that would validate if the conditions you are looking for exist and then run your script or just implement the resstatechange trigger.  If this does not work for you, please let me know and we can discuss it further.


Login to vote
martin2176's picture

Triggers have always been an option. But when you implement a new VCS cluster or define a new Rg group, testing is a major task.
Having a trigger means more testing because the any resource group with preonline=1 is affected. So thorough testing have to be done to make sure no unintended groups are affected .

I agree with your idea of having an application resource defined as parent or child as the case may be. But overall it is an overkill.
Many applications need a script to be kicked off and dont need all the capabilities of application agent.
Both the trigger and application resource will meet the need. But it will be very convenient if there is an attribute postscript and prescript defined as part of resource group which can be supplied with the post and pre script names and VCS engine can call them.
Having it this way will greatly reduce the amount of testing that need to happen compared to having it done via trigger because now I need to worry only about the singe resource group I am testing and since it is a group specific attrib I am sure no other groups will be affected.

Login to vote
AHerr's picture

I agree, all clusters should be fully tested to ensure the expected behaivoris the result of several scenarios.
My thought with the application agent is that it could be written to be generic enough to test for the condition you are putting in place or just validate that a touched file exists.
The onlining of the agent can be specific to the needed commands (setting the default route, changing a local setting, doing whatever script you would like it to do local and specific to each node in the cluster and specific to each service group).  If you would like each node in the cluster to change a speficic variable, you could run a unique command per service group.  This also allows you to tie in the script to where it is needed.  When all of the IP resources come online and you want to change the default gateway, you do not need to wait for a trigger to be run after the service group is online, you run the command next and then move on to the following resource.

The nice thing with the application resource is that you can run the script to validate that it does what you would like it to do, and then when it is ready, you can define an Application resource with that same script.  In your case, it would seem to be easier than a Trigger.
What do you think?

Login to vote
martin2176's picture

Couldnt agree with you more here with Application agent. As I said app agent and trigger will meet all the requirement of having pre and post scripts.
some cases simplicity is warranted. Adding an app resource doesnt make things complex, but every resource will have an C++ agent thread or perl script which will be running.
there are situations in which adding an app resouce makes real sense , but in certain other situations to kick off a simple script adding an app resource is over kill..

for instance I recently deployed a VCS cluster where the node share Prod and QA on different subnets. Depending on which service runs on the cluster node I needed to swing the def gateway from prod to qa and vice versa. All I needed was  to run a route delete and route add command. And there is no way that route add/delete command will fail. I have a 10 line script which will delete the def gw, add a new def gw.
I evaluated both options of having trigger and adding an app resource. trigger was overkill . so ended up in having an app resouce defined which did the job. But if I had an option of passing the script as a resource group attribute I would have gone with that option only.

in the same case I wanted to out put a message to /etc/issue and motd file to specify if the server is running QA or Prod so that users loging can see which service is running on the nodes.  in simple scenarios like this having a post/pre script attribute is defenitely helpful.

Login to vote
AHerr's picture

I wanted to let you know that we are coming out with a new type of monitoring framework in our 5.1 SP1 release, which is due out in a few months from now.
It is called Asynchronous Monitoring Framework and it reduces the CPU requirements for monitoring agents dramatically.  As we get closer to the release date, we will be adding additional documentation around the new framework. 

For your environment and the suggestion in this thread, we will determine what necessary changes would be need to implement it and prioritize it appropriately.

Thanks for your suggestion.

Login to vote
mikebounds's picture

I agree with martin2176's suggestion and let me give the reasons why and how I think it should be implemented.

Sometimes, before or after a resource onlines, you need to run a custom script.  If this resource has the online routine built into the agent, like Oracle, as oppose to Weblogic which has a "StartProgram" attribute, then you cannot modify the Oracle agent code to run your script and if the Oracle resource is in the middle of a service group then you cannot use a preonline or postonline trigger.

Now as has been mentioned you can use an Application resource to do this, but if you use this argument, then preonline and postonline triggers are not required as you set-up application resources at the bottom and top of your servicegroup.  The reason against Application resources, is that it is more work and overkill for what is required.  A resource needs an online, offline and monitor entry points,so if you just want to call a script you have to fudge this and you call script in StartProrgam of Application agent, and then touch a lock  file.  Then monitor checks lock file exists and offline removes lock file.  So you have to create this framework to deal with lockfiles and this creates extra overhead (although is not much overhead) for monitoring lock file.  "Asynchronous Monitoring Framework" does not help as this helps in monitoring processes, and this is the point, there is no process to monitor, you have a custom monitorProgram which checks lock file exists.

I think it should be implemented as a generic resource attribute mike "Critical" and "Enabled" attributes so it is available to all resources and not implemented on a resource by resource basis.  So the new attributes could be called:

PreScript: Script to call before resource onlines

PostScript: Script to call after resource onlines

These scripts should be passed arguments like trigger scripts are - i.e resource name, service group name and system, so the script can use these if required so that if you have more than one resource calling this script, you can make it generic.


UK Symantec Consultant in VCS, GCO, SF, VVR, VxAT on Solaris, AIX, HP-ux, Linux & Windows

If this post has answered your question then please click on "Mark as solution" link below

Login to vote