Impact analysis
Resilient models and impact calculations
For resilience calculations related to impact analysis, you can use the logical entities in BMC Helix CMDB (CMDB) to segregate different resilience clusters. Additionally, you can use the ImpactReporting field in CMDB for resilience calculations. The values for the ImpactReporting field are:
- All (default value)
- None
- Degraded
- LoS (Loss of Service)
- LoS-Direct
- Ring (only for Ring relationships)
The following graphic explains a simple switch resource network model:
You can use the following formula to calculate a single resilient relationship:
The formula handles relationships when they are resilient, that is, when the target CI has multiple matching relationships that are Marked as Resilient (Resilient = "Yes"). The resilient formula calculates each resilient relationship, before working out the final impact on the CI. After all the resilient relationships are calculated, the final impact weight of the target is the sum of the resilient relationship weights.
Example
- Logical Resource POWER #1 has 4x resilient CIs reporting to it:
- The Three Phase L1 has resilient relationship (Relationship #1) with the weight as 35%.
- The Three Phase L3 has resilient relationship (Relationship #2) with the weight as 35%.
- The Diesel Gen has resilient relationship (Relationship #3) with the weight as 20%.
- The Battery has resilient relationship (Relationship #4) with the weight as 10%.
- Assuming the following scenario:
- The Three Phase L1 is 100% impacted.
- The Three Phase L3 does not have an existing impact.
- The Diesel Gen is already impacted at 25%.
- The Battery does not have an existing impact.
Calculation
To calculate the impact for POWER #1, the following calculations are performed:
Relationship | Calculation based on the formula | Result | Overall impact on Power # 1 Logical Resource |
---|---|---|---|
Relationship 1 | (35 / (10 + 20 + 35 + 35)) * 100 | 35% | Add the values of the Result column: Impact to POWER #1: 35% |
Relationship 2 | (35 / (10 + 20 + 35 + 35)) * 0 | 0% | |
Relationship 3 | NA* *Do not calculate because the existing impact weight does not meet the ImpactReporting: LoS threshold. | 0% | |
Relationship 4 | (10 / (10 + 20 + 35 + 35)) * 0 | 0% |
Samples
Sample | Graphical representation |
---|---|
100% impact to Ethernet #1
| |
60% impact to Ethernet #1
| |
100% impact to Ethernet #1 and Ethernet #2
|
Grid models
A grid is formed when all the CIs (resources) in the grid have impact relationships with every other CI in the grid.
Because all the resources impact each other in a resilient manner, you can also use a logical resource to calculate the resiliency values.
Resource to Logical Grid relationships
If the relationships have the values as Resilient: Yes and ImpactWeight: 100, then a 100% impact to Resource #1 would result in a 25% impact to the Logical GRID Resource by using resilient formula calculation.
Ring models
Impact Rings (often implemented through Ring Protection Links or RPL) are common in large networks, especially that are related to resiliency. Rings provide a choice of alternative routes for a CI to reach another CI.
The following graphic represents a simple ring model:
A ring is always denoted by relationships and by setting the following attributes:
- RPLReachableName: <Name>
- ImpactReporting: Ring
When you perform an impact analysis, the system checks if the CI that is currently being evaluated has a ring relationship. The system also checks the source-destination of all the ring relationships where the value of the RPLReachableName attribute matches the RPLTargetName CI attribute to see if there is a valid (not impacted) route back to the CI with that name.
Rules
The following operations are performed when a relationship with ImpactReporting: Ring is encountered during an impact.
- Ring Rule #1—Any relationship where the source.instanceId node and the RPLTargetName attribute matches the RPLReachableName attribute relationships is ignored, that is, the resource is its own target. For example, if Resource #1 is impacted, the reporting an impact on the Resource #1 >> Resource #8 and Resource #1 >> Resource #2 relationships is ignored.
- Ring Rule #2—Each relationship is only processed once as per the ring node.
Examples
Resource #1—100% impacted
Resource | Type | Level (%) | Formula |
---|---|---|---|
Resource #1 | Direct | 100% |
|
Resource #2 | Direct | 0% |
|
Resource #3 | Indirect | 0% |
|
Resource #4 | Indirect | 0% |
|
Resource #5 | Indirect | 0% |
|
Resource #6 | Indirect | 0% |
|
Resource #7 | Indirect | 0% |
|
Resource #8 | Indirect | 0% |
|
Resource #5—100% impacted
Resource | Type | Level (%) | Formula |
---|---|---|---|
Resource #5 | Direct | 100% |
|
Resource #1 | Indirect | 0% |
|
Resource #2 | Indirect | 0% |
|
Resource #3 | Indirect | 0% |
|
Resource #4 | Indirect | 0% |
|
Resource #6 | Indirect | 0% |
|
Resource #7 | Indirect | 0% |
|
Resource #8 | Indirect | 0% |
|
Resource #5—100% impacted and Resource #7—50% degraded
Resource | Type | Level (%) | Formula |
---|---|---|---|
Resource #5 | Direct | 100% |
|
Resource #7 | Direct | 50% |
|
Resource #1 | Indirect | 0% |
|
Resource #2 | Indirect | 0% |
|
Resource #3 | Indirect | 0% |
|
Resource #4 | Indirect | 0% |
|
Resource #6 | Indirect | 50% |
|
Resource #8 | Indirect | 0% |
|
Non-resilient models and impact calculations
Use the following formula for non-resilient models to calculate the impact:
Examples
Source Impact Weight | Relationship Weight | Calculation based on the formula | Result (%) |
---|---|---|---|
100 | 50 | (100 * 50) / 100 | 50% |
50 | 50 | (50 * 50) / 100 | 25% |
25 | 50 | (25 * 50) / 100 | 12.5% |
75 | 25 | (75 * 25) / 100 | 18.75% |
Highest wins scenario
If a particular CI has multiple inbound impacts that are not resilient, then the impact analysis will apply the highest wins option.
Examples
Relationship #1 | Relationship #2 | Calculation |
---|---|---|
|
| If the impact to Resource #3 from Relationship #1 is 50% and the impact to Resource #3 from Relationship #2 is 80%, then Resource #3 is marked as 80% impacted (highest value). |
Duplicate relationships
For impact analysis, a duplicate relationship is determined as an enabled impact relationship entry with matching Source.InstanceId, Destination.InstanceId, and RPLReachableName.
In Ring networks, you can have multiple relationships with the same Source and Destination IDs. For example, if a CI is dependent on multiple services, there will be different values in the RPLReachableName field, but with the same Source and Destination IDs on the ring.
A duplicate relationship is handled only by using the impact relationship with the highest impact weight or the first entry if the weights match.
For example, consider the following 2x relationships:
Relationships | Source.InstanceId | Destination.InstanceId | RPLReachableName | ImpactWeight | Resilient | ImpactReporting |
---|---|---|---|---|---|---|
Relationship #1 | Resource #1 | Resource #2 | null | 70 | Yes | LoS |
Relationship #2 | Resource #1 | Resource #2 | null | 50 | Yes | Degraded |
In this example, only Relationship #1 is used as it has the highest impact weight out of the duplicate relationships. Also, the settings of Relationship #2 and above for Resilient and ImpactReporting are also ignored, which might not be the expected result.