11 Replies Latest reply on Jul 8, 2016 1:44 PM by michael huttner

    Extended Objects and Server Smartgroups

    Rob Slattery

      Can an extended object be used as a criteria to populate a server smartgroup?


      Issue:  We have a job that we're running (NSH script) and the depends on a BladeLogic App/File server.  If the target has been "taken out" of BladeLogic due to failover, we have to manually point to another server to run the job.

        • 1. Re: Extended Objects and Server Smartgroups
          Bill Robinson

          why does the job depend on the appserver?  it targets the appserver?  why ?

          • 2. Re: Extended Objects and Server Smartgroups

            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.

            • 3. Re: Extended Objects and Server Smartgroups
              Jim Wilson

              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)?

              • 4. Re: Extended Objects and Server Smartgroups
                Bill Robinson

                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.

                • 5. Re: Extended Objects and Server Smartgroups
                  Santhosh Kurimilla

                  Why don't you target against blfs (, loopback for your File Server mounted on all the AppServer)?

                  • 6. Re: Extended Objects and Server Smartgroups

                    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.

                    • 7. Re: Extended Objects and Server Smartgroups
                      Bill Robinson

                      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.

                      • 8. Re: Extended Objects and Server Smartgroups
                        Santhosh Kurimilla

                        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

                        • 9. Re: Extended Objects and Server Smartgroups
                          Bill Robinson

                          How will that help here?

                          • 10. Re: Extended Objects and Server Smartgroups
                            Santhosh Kurimilla

                            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.

                            • 11. Re: Extended Objects and Server Smartgroups

                              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.