why does the job depend on the appserver? it targets the appserver? why ?
Bill, our environments run in a clustered set of machines, which change based on which set is "active". We have jobs which we want to execute on the active app servers, and would like a way so set these up so that the job will route to only the active hosts.
When we failed over recently, many of our jobs failed because their targets were pointing to servers which were no longer active (or available). Since I am collecting metrics and performing maintenance functions on all of our active app servers/hosts, it does not work if we allow BSA to execute a job on any available job server.
So you don't mean BSA Appserver?
For your clustered systems, shouldn't you be targeting execution against the cluster name in this case (so that it follow the failover)?
if you are talking about bsa appservers can you clarify what these jobs are doing? for example - to run some blcli commands you don't need to target an appserver - it can be a type 2 nsh job w/ no targets.
there's no straightforward way to use an EO to do what you want. it would make more sense to use a server property. dump a list of all appservers, find the active ones (eg, the completestatusreport will have which ones are up or down) and set a property you base the smart group on.
Why don't you target against blfs (127.0.0.1, loopback for your File Server mounted on all the AppServer)?
Santhosh, using blfs as a single target runs the job on only one app server. Consider a use case of one of my benchmark jobs, which capture elapsed time and response for standard tasks - on each job server, which give us performance trending reports via Splunk. I need to be able to have this execute on all the job servers no matter which cluster set is active.
Bill, I am working with Rob S, who suggested considering EO, and also using a server property to use in a smart server group as criteria. We thought since EO had the ability to use external logic (eg, scripts) to give us what I think of as "calculated fields" we could have something that either provides a list of active job servers, or "marks" each of the primary/secondary job servers property value as being "active" or "inactive"... the goal is a dynamic solution which would work in each of our three "failover cluster" environments.
there's a lot of different ways to do this:
if you use the EO, the only real way to link that to a smart group would be to use that in a component discovery job (eo in the template) and then you can use the TEMPLATE* property in the server smart group. but, that won't exclude invalid components (eg, the offline appservers) so that won't work very well.
if you were on 8.6+ you could use the new 'persist' function in a compliance job where you run a command and dump it into a custom property class that can be linked to the server class.
depending how you are kicking things off you could do a type 2 nsh script and loop, have your script figure out what's offline and online w/ some blcli or something and then nexec, or blcli to run another job against the online ones.
or the server property thing i mentioned before.
you could also use a compliance job w/ auto-remediation. if the EO gives certain output then deploy X. that may not work if the targets are actually unreachable (via rscd) though.
OK michael. Then, it may be worth querying against the BSA Database tables and identify the AppServers in the current environment?
1. Identify the environment/DB I am currently connected to.
blasadmin -a show data all
2. Query against that DB and identify all the active AppServers
How will that help here?
So, Michael can use those list of AppServers as targets or to collect the reports.
Actually, I worked with Michael and am bit aware of what he is working on. So, I just want wait for Michael's response if this approach helps him.
Given the limited scope of the failover sensitive jobs, I'm inclined to keep things simple, and have something that might run when an app/job server starts (or even daily, at worst) which queries active servers and (re)creates the static server groups for each failover environment.