Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

On/Off agent or perhaps trigger

Created: 02 Dec 2012 | 8 comments
Ivo Kovac's picture

Hello,

I encountered following problem: my customer's application is integrated in VCS (running on linux) - in one of many service groups (SGs). The application is in VCS implemented via Application agent type of resource - it contains scripts for bringing it online/offline/clean action as well as monitoring. After some time it was found out that the customer does not require and need monitoring and cleaning actions at all. The only thing he expects from VCS is to bring the application resource online (or offline) when the whole SG is going online (offline).

I am considering how to achieve this. Is it possible to leave out monitoring and clean action from application resource? Is there any other available type of resource (agent) which could do just this? Or should I look for postonline trigger script? If the option is trigger script I would like to see some example. There will be more such applications running on different nodes.

Thanks in advance for your opinions/tips.

i.

Comments 8 CommentsJump to latest comment

Venkata Reddy Chappavarapu's picture

The monitor is compulsory for all VCS agents. You can disable monitor. However you can disable clean for Application resource by NOT configuring CleanProgram attribute.

There is no other agent in VCS which can do On and Off without monitor. For your requirement trigger would best approach.

 

Hope this helps!

-Venkat

Venkata Reddy Chappavarapu,

Sr. Manager,

Information Availability Group (VCS),

Symantec Corporation

===========================

PS: If you are happy with the answer provided, please mark the post as sol

Ivo Kovac's picture

Hello Venkat, thank you for your quick reply. I am little bit confused from your answer. You mean it's not possible to disable monitor attribute - I must specify one. Correct?

Then probably I have only option to specify postonline and postoffline for every application running in three different SGs. The only trouble is I am not sure how to do that?

Obviously I should put postonline/offline scripts here: /opt/VRTSvcs/bin/triggers. The scripts which are launching/shutting down the customer application are usual shell scripts. In postonline/offline triggers I will need to differentiate which server it is and also which SG is it.

i.

Venkata Reddy Chappavarapu's picture

Sorry for that. I meant, it is not possible to diable monitor functionality for any agent. The attributes used for monitor functionality for Application agent are MonitorProcesses/PidFIles/MonitorProgram.

Sample triggers are present in the /opt/VRTSvcs/bin/sample_triggers directory. You can copy the sample triggers and modify them to invoke your shell scripts based on the service group.

 

Venkat.

 

 

 

Venkata Reddy Chappavarapu,

Sr. Manager,

Information Availability Group (VCS),

Symantec Corporation

===========================

PS: If you are happy with the answer provided, please mark the post as sol

mikebounds's picture

Just to clarify some points here:

If you don't specify CleanProgram in application, then if you have used MonitorProcesses or PidFiles, then VCS will still clean (kill)  these processes

You can't disable the monitor for an agent, but you can disable monitor for an application - what I mean is that you can specify the MonitorProgram attribute and NOT use MonitorProcesses and PidFiles and in your code you don't have to Monitor your application and you can monitor a lock file instead - for example:

 

App_Name=$2
LOCKFILE=/tmp/.{$App_Name}.DO_NOT_REMOVE
case "$1" in
start)
    touch $LOCKFILE
    # code to start app $App_name
stop)
    # code to stop app $App_name
    rm $LOCKFILE
    ;;
monitor)
    if [ -a $LOCKFILE ]
    then
        exit 110
    else
        exit 100
    fi ;;
*) 
    echo "Usage: $0 {start|stop|monitor} app_name lock_file
    exit 1
    ;;
esac 
 
So if you called this file app.sh and put it in /opt/VRTSvcs/bin, then you configure your app like:
Application app1 (
  StartProgram = "/opt/VRTSvcs/bin/app.sh start app1"
  StopProgram = "/opt/VRTSvcs/bin/app.sh stop app1"
  MonitorProgram = "/opt/VRTSvcs/bin/app.sh monitor app1"
)

 

So this has no clean, and VCS knows nothing about the application so cannot clean it.  But your customers main concern is probably that VCS does not interfere by cleaning resource, but IF the application resource has no dependent resources, you might at well do a proper monitor in the code above as this tells you the state of the App and then if you make the resource non-critical, if the App is down there is no clean to call and non-critical means service group does not fault, so basically in this config, VCS informs you app is down, but takes no action, which is probably what the customer wants so I would remove creation and removal of lock files and replace monitor code above with:

 

monitor)
# code to start app $App_name
    if $App_name is UP
    then
        exit 110
    else
        exit 100
    fi ;;
 
If you are considering using postonline, then I presume your app resource has no dependencies and is at the top of the dependency tree, but for resources that DO have dependencies, even if resource is non-critical, then if resource faults, then it brings down the resources above it, so if you don't want VCS to take action, there are some SERVICE GROUP attributes to stop cleaning resources - see extracts from VCS admin guide:
 
ManageFaults
Specifies if VCS manages resource failures within the service
group by calling the Clean function for the resources. This
attribute can take the following values.
NONE—VCS does not call the Clean function for any resource in
the group. User intervention is required to handle resource
faults.
 
And this is quite often use with the following attribute if the resource is not at the top of the tree
FaultPropagation
Specifies if VCS should propagate the fault up to parent
resources and take the entire service group offline when a
resource faults.
The value 1 indicates that when a resource faults, VCS fails over
the service group, if the group’s AutoFailOver attribute is set to 1.
If The value 0 indicates that when a resource faults, VCS does not
take other resources offline, regardless of the value of the
Critical attribute. The service group does not fail over on
resource fault.

 

 

However, as these are service group attributes, not resource attributes, they are generally used for Test/Dev service groups were you don't want VCS to take action for ANY resource.  Asssuming you want VCS to react to other resource failures (Diskgroup, Mount, IP), then you would need to put resources in another dependent service group to use ManageFaults and FaultPropagation attributes.

 

You can use postonline and postoffline and the code in a postonline will look something like:
sys=$1
sg=$2
If $sg app1
then start app1
If $sg app2
then start app2

or if you have used good naming conventions for service group then:

app=`echo $sg  | sed -e expression`
start $app

Mike

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

Ivo Kovac's picture

Thank you Mike,

basically customer wants VCS only to start or stop the application using its scripts. If the application fail, the application team should take care and handle it, not VCS. The only VCS's task should be to switch the application on or off when asked to do so. I was advising customer against it, but its customer's decision and he's paying my lunch.

I think the easiest solution here will be just to set the CleanProgram to empty quotes ("") and to apply the MonitorProgram as you are suggesting - touching some empty hidden file when the application resource is coming up and removing it when going down.

Thanks very much for your effort and time.

I appreciate it a lot!!!

ivo

mikebounds's picture

If you actually monitor app in code, then although VCS won't run clean (as you haven't defined one and VCS doesn't know processes to clean itself), then I THINK VCS may run offline, so you may have to just touch a file, rather than actually monitor, but it is worth trying to actually monitor app and see if VCS calls offline - it is doesn't then you can have VCS know the state of the app without interfering when it goes down.

Mike

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

Soumya Sakha Tripathy's picture

Another approach (though not a very clean one) can be to set a very large MonitorInterval value.

So, effectively monitor will rarely be called.

Just a thought...

 

Thanks!

Soumya.

mikebounds's picture

Another unclean approach is to set a very large ToleranceLimit - but the problem with this and setting large MonitorInterval is if the Application agent dies as when VCS restarts it, I am pretty sure the resource faults.

Mike 

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