also, is job rules evaluation process/logic logged anywhere? I can't seem to find anything in appserver.log or any of the job servers instace logs and can't figure out why it picks different servers all the time
I have seen in our environment that for whatever reason it takes a few minutes for the Appserver to pick up the rules.
Have you given it some time before you tested your rules ?
Also can you post your exact rule, as ??GROUPS*?? seems a bit odd.
I'm going to follow your advice and wait a bit after restarting appservers and before trying to execute a job.
I was testing pretty much right away so maybe that's the problem besides these test servers are vms maybe a bit slow.
I was trying ??GROUPS*?? since ??NAME?? did not seem to work.
Ideally the rule I want to use is: (??NAME?? starts with "MYSERVER")
What I expect is that all jobs with target server names matching this rule to be executed on a specific appserver.
Is it correct assumption?
I'll let you know if wait works
unfortunately the wait did not make a difference. Maybe I'm doing something wrong.... can a rule (above) be used to select application server to use for a job based on target servers names?
What is your use case, what are you trying to ultimately accomplish? That way we can tell you if it's possible in BSA and what the best way of going about it would be.
Joe, OK, so:
each datacenter has 4 appservers.
(each one of the 4 app servers is configured as launcher,config,job server + 2 additional job server instances, and all job servers are configured with identical settings for max jobs and work items)
each datacenter has a large number of target servers. naming convention of the target servers allows to select them all by datacenter.
I want to execute all jobs targetting agents in a particular datacenter only on the 4 app servers in that datacenter.
I don't want to have separate jobs for each datacenter.
I expect I can create 2 job execution rules:
1)RULE DATACENTER1= (??NAME?? starts with "DATACENTER1"), and assigned servers are all DC1 job servers
2)RULE DATACENTER2= (??NAME?? starts with "DATACENTER2"), and assigned servers are all DC2 job servers
and then send a job to ALL targets and expect to see that DC1 targets will be serverd by DC1 job servers,
and DC2 targets will be served by DC2 servers.
can anybody confirm that when I choose ??NAME?? as criteria for job execution rule it means the name of the TARGET computer?
I assume so since the rule defnition dialog says "choose a Property, operator, and value to check on the TARGET"
1 of 1 people found this helpful
I think I understand what you mean. You always want certain appservers to run jobs only against servers in a specific datacenter.
But thinking about your situation, a Job Execution Rule is all about the JOB parameters (not the TARGET parameters) and what appservers to run those jobs against. Unless you duplicate jobs (one for each datacenter) I'm not sure how else you would go about that.
Let me see if I can get advice from another consultant/developer on how to go about this.
the job routing is done by job attribute, not by target attribute, so your jobs will need to target only servers in a particular data center. if the job meets the rule, it runs on that appserver, no matter 'where' the targets are. there is no way to create a routing rule based on the targets of the job - i mean what happens if the job has targets that meet multiple routing conditions ?
also - what is the connectivity between your appservers and database here ? which set of appservers is 'remote' from the database? (we do not support or recommend this)
i'm not sure i understand why you want to have separate appservers here - any perceived performance boost to having 'local' appservers is going to be lost in the appserver to db communcation going across a wan.
Thanks, this confirms my suspicion that these are not the Target server parameters
I'm creating these rules primarily for DR failover scenario.
In this scenario DB and Fileserver from DataCenter 1 are constanly replicated over to DataCenter2 but not used until failover. Current Intrastructure includes 4 app servers in DC1 and 4 app servers in DC2 (but DB and Fileserver being used is in DC1)
BMC designed the BCP/DR solution and recommmended that the a job excution rule be put in place to prevent any jobs from running on the 4 app servers in DC2 unless its a DR situation.
Based on your reply I guess the rationale is to prevent job servera talking to the database in a different datacenter?
I on the other hand thought that i might be a good idea to actually use the DC2 app servers even when not in DR situation as well but after yours and Joe's comments here it seems that the only solution would be to have that one rule to disable exection on all DC2 job servers completely until DR failover?
1 of 1 people found this helpful
what is the connectivity between DC1 and DC2 ?
you do not want to operate the appserver -> db connection across a wan - it's very chatty and poor connectivity will adversly affect performance. so if you need to fail to DC2 for some reason you should fail the whole infrastructure over, including the database and file server. you should not failover just the appservers or just the db/file server.
so your DR side should stay offline until the failure event, at which point you would break replication to the db/file server, bring those online and bring up the appservers in the DR.
then you have no need for job rules.
Connectivity between DC1 and DC2 is at least T3
Keeping all bladelogic components in DC2 down until DR was the original plan (and bringing them up only for service pack installations, etc) You last comment confirms that we should stick to that plan.
I never understood why it was recommended to keep app servers at DC2 down most of the time but after what you've just said it makes sense.