3 of 3 people found this helpful
You can do pretty what you need here with a combination of settings like the ones you mention. There's several combinations here as you have seen so will need to work through them. The easy first one is HasImpact - you need to set this to Yes every time to ensure the impact analysis will use these relationships.
Next one to look at is ImpactComputationalModel which applies to regular CIs as opposed to relationships. Pretty sure the allowed values are STANDARD, CLUSTER, WEIGHTED CLUSTER. You should look at the BMC docs to confirm these are right values, and also to confirm what I'm going to explain from memory here
So, STANDARD means that the CI will have it's impact assessed simply as a direct result of the incoming provider relationships. i.e. if a relationship exists to this CI from another, and it 'has impact' set to Yes, then it will have the status for impact purposes set the same as the provider. e.g. if the provider CI is unavailable, the impacted CI is seen as unavailable. If there are multiple providers, the status is set as the 'worst' of the providers.
CLUSTER means that the impact assessment will be based on a simple calculation based on the number of providers (not just their status as above). The calculation says that if 50% of the providers are unavailable, then the CI itself becomes unavailable. Less than 50% then it's OK. So if the CI is set as CLUSTER, and has 3 provider relationships, then one provider failing is 1/3 = 33% so all ok. 2 failing is 2/3 so 66%, NOT alright, and obviously 3 failing is 3/3 so 100% and also unavailable.
WEIGHTED CLUSTER is smarter, in that it allows you to use the ImpactWeight attribute on the relationships, to provide more 'weight' in the calculation than the simpler model above. So in the CLUSTER example above, if we set the ImpactWeight for the first provider relationship to 40, and the other two to 10, then the total weights for all providers is 40+10+10=60. If the first provider rel. propagates an impact, it will be calculated as 40/60 = 66%, so the impact means the related CI is unavailable. But if one (or even both) of the other two propagate impact, then the calculation is 10/60 (or 20/60) which is say 17% or 33% (roughly and hence the related CI is still OK. This approach is useful when there are multiple providers, and some have a greater contribution to the status of the consumer CI than others.
So in your case of 4 provider app servers, you could probably use CLUSTER or WEIGHTED and get the right result. With cluster, 2 of 4 is not >50% (it's = 50%) so will probably work.
Carey you rule. This is probably the magic. ImpactComputationalModel
I will check this further and test if it works as requested
THANKS A LOT