Self priority

Self priority is a dynamic priority that changes depending on the following details:

• The status of the component
• The schedule status associated with the component (during or off schedule)

And one of the following three methods of self priority computation are as follows:

• Base priority (default)
• Cost

• Worst SLA state 
  
  Both the cost and the worst SLA state methods rely on the concept of down time. A component is considered down from a cost/SLA perspective when its status is greater than or equal to a specified value. This value is stored in the slot status of the BMC_DOWNTIME_STATUS_CONFIG BAROC table.

  Note

  Normally, only one instance of this table must ever exist. If several instances exist, the instance with the lowest status is used.

  
  
  Base priority method for self priority determination
  
  

Base priority method

Base priority is the default method for computing self priority. Self priority is determined by mapping the current base priority (depending on whether the component is on or off schedule) against the status value of the component.

Enabling the base priority method

The base priority method is enabled by default. To specify the base priority method if the default has been changed, modify MC_SM_COMPONENT class to set the SelfPriorityFunction slot to the value BASE_PRIORITY.

How the base priority method calculates priority

Each component has two base priority values, which are as follows:

• The High Demand Schedule priority, which is the priority assigned to the component during the peak hours of its schedule stored in the Priority slot
• The Off Schedule priority, which is the priority assigned to the component during the hours that are not critical for its operation stored in the PriorityOut slot

For example, if the component is a server that supports a business that is open from 8:00 A.M. to6:00 P.M., then the higher High Demand Schedule priority would be applied to the server during the hours that the business is open and the Off Schedule priority would be applied to the server when the business is closed (6:00 P.M. to 8:00 A.M.).

The base priority values are static priority values that act as a baseline to determine self priority.

Cost method

The cost method determines priority based on the actual cost of a component being down. Cost is a user-specified monetary value per unit of time--for example, $5.00US per second. The more money it costs for a component to be down, the higher priority that component will have.

Creating a BMC_COST_OF_DOWNTIME_PRIORITY_MAPPING instance

The cost model, concomitant cost values, and the mappings between cost values and the severity levels of the self_priorityvalue are user defined. The cost value is typically defined as cost per unit of time: for example, a value of 5 can indicate $5.00 per second of down time.

When you create an instance of BMC_COST_OF_DOWNTIME_PRIORITY_MAPPING, you specify the cost parameter as a data type REAL as shown:

BMC_PUBLISH_DATA_CLASS:
BMC_COST_OF_DOWNTIME_PRIORITY_MAPPING ISA BMC_SIM_DATA
DEFINES {
name: STRING, key=yes;
cost: REAL;
self_priority: MC_PRIORITY, key=yes;
};
END

Enabling the cost method

To enable the cost method, you must modify the following slots in the MC_SM_COMPONENT class:

• SelfPriorityFunction=COST
• SelfPriorityFunctionParam= name of the cost of downtime priority mapping group (a mapping group is made of a varying number of BMC_COST_OF_DOWNTIME_PRIORITY_MAPPING instances sharing the same name)

How the cost method calculates priority

Each component has two cost values which are as follows:

• The During Schedule cost, which is the cost assigned to the component during the peak hours of its schedule. This value is stored in the ImpactCostPerSec slot.
• The Off Schedule cost, which is the cost assigned to the component during the hours that are not critical for its operation. This value is stored in the ImpactCostPerSecOut slot.

Depending on whether the component is in the During Schedule or Off Schedule time frame, the cell copies one or the other of these values to the slot cost.

The cost method first checks to determine if the component is down as specified by the down time definition in BMC_DOWNTIME_STATUS.

If the cost status is less than the BMC_DOWNTIME_STATUS, then the component is not considered to be down, and its self priority is set the lowest priority ( PRIORITY_5 ). Otherwise, the BMC_COST_OF_DOWNTIME_PRIORITY_MAPPING table is used to determine the self_priority value as follows:

Let c be the cost of the component and n be the name of a mapping stored in the SelfPriorityFunctionParam slot of the component.

If there is an instance i in this table with

• name = n
• cost = cost~i~
• self_priority = priority~i~
• such that cost~i~ < c

and there is no other instance j with

• such that cost_j > cost_i and cost_j < c

then the self_priority of the component is set to priority_i.

If there is no such instance, the self_priority of the component is set to the lowest priority ( PRIORITY_5 ).

The status enumeration values for the cost method are stored in the BMC_DOWNTIME_STATUS_CONFIG table in the mc_sm_root.baroc file of each cell.

Cost method of priority determination

Cost method example

In this example, the SelfPriorityFunction of the component definition is set equal to COST and the name of the mapping value is test_cost.

BMC_System;
mc_udid=comp_r3_c2;
Name=comp_r3_c2;
SelfPriorityFunction=COST;
SelfPriorityFunctionParam=test_cost;
PriorityWatchdog=YES;
ImpactCostPerSec=5.0;
ImpactCostPerSecOut=1.0;
END

 This series of mapping table examples associate different cost values with corresponding self_priority values in ascending order, with 4 as the least severe and 1 as the most severe.

BMC_COST_OF_DOWNTIME_PRIORITY_MAPPING;
name=test_cost;
cost=1;
self_priority=PRIORITY_4;
END
END
BMC_COST_OF_DOWNTIME_PRIORITY_MAPPING;
name=test_cost;
cost=2;
self_priority=PRIORITY_3;
END
END
BMC_COST_OF_DOWNTIME_PRIORITY_MAPPING;
name=test_cost;
cost=5;
self_priority=PRIORITY_2;
END
END
BMC_COST_OF_DOWNTIME_PRIORITY_MAPPING;
name=test_cost;
cost=10;
self_priority=PRIORITY_1;
END

Based on the sample test_cost mapping table, if the status is UNAVAILABLE (or at least greater than or equal to the BMC_DOWNTIME_STATUS ) then, the following information is observed:

• During schedule, the cost is 5.0 and self_priority maps to PRIORITY_2.
• Off schedule, the cost is 1.0 and self_priority maps to PRIORITY_4.

Worst SLA state method

The worst SLA state method determines priority based on the Service Level Agreement (SLA) for a component. Each SLA is tracked separately within a specified time period, such as daily or weekly. The SLA states are rolled up for the specified period, and the worst SLA state is given priority. The rolled up SLA states are stored in the sla_rollup_status slot. Possible SLA states are as follows:

• NO_SLAS
• COMPLIANT
• AT_RISK
• BREACHED

The SLA state for each component is assigned by BMC Service Level Management.

Creating a BMC_WORST_SLA_STATE_PRIORITY_MAPPING instance

When you create an instance of the BMC_WORST_SLA_STATE_PRIORITY_MAPPING, you specify the sla_state slot as belonging to the enumeration type MC_SM_SLM_SLA_STATUS as shown:

MC_PUBLISH_DATA_CLASS:
BMC_WORST_SLA_STATE_PRIORITY_MAPPING ISA BMC_SIM_DATA
DEFINES {
name: STRING, key=yes;
sla_state: MC_SM_SLM_SLA_STATUS;
self_priority: MC_PRIORITY, key=yes;
};
END

The enumeration MC_SM_SLM_SLA_STATUS is defined as follows:

ENUMERATION MC_SM_SLM_SLA_STATUS
0 NO_SLAS
10 COMPLIANT
20 AT_RISK
30 BREACHED
END

Enabling the worst SLA state method

To enable the worst SLA state method, you must modify the following slots in the MC_SM_COMPONENT class:

• SelfPriorityFunction=WORST_SLA_STATE
• SelfPriorityFunctionParam= name of the worst SLA state priority mapping group (A mapping group is made up of a varying number of BMC_WORST_SLA_STATE_PRIORITY_MAPPING instances sharing the same name.)

How the worst SLA state method calculates priority

To use the worst SLA state method to determine priority of a component, set its SelfPriorityFunction slot to the value WORST_SLA_STATE.

The worst SLA state method first determines whether the component is down according to the down time definition in BMC_DOWNTIME_STATUS_CONFIG.

If the worst SLA state status is less than the BMC_DOWNTIME_STATUS, then the component is not considered to be down, and its self priority is set the lowest priority ( PRIORITY_5 ). Otherwise, the BMC_WORST_SLA_STATE_PRIORITY_MAPPING BAROC table is used to determine the self_priority value as follows:

Let s be the value stored in the sla_rollup_status slot of the component and n be the name of a mapping stored in the SelfPriorityFunctionParam slot of the component.

If there is an instance i in this table with

• name = n
• sla_state = s
• self_priority = p

then, the self_priority of the component is set to p.

If there is no such instance, the self_priority of the component is set to the lowest priority ( PRIORITY_5 ).

The status enumeration values for the worst SLA state method are stored in the BMC_DOWNTIME_STATUS_CONFIG table in the mc_sm_root.baroc file of each cell.

 Worst SLA method of priority determination

Worst SLA state method example

 This series of mapping table examples associates different sla_state values with corresponding self_priority values arranged in ascending order. In this example, 5 is the least severe and 2 indicates a greater severity.

BMC_WORST_SLA_STATE_PRIORITY_MAPPING;
name=test_sla;
sla_state=NO_SLAS;
self_priority=PRIORITY_5;
END
END
BMC_WORST_SLA_STATE_PRIORITY_MAPPING;
name=test_sla;
sla_state=COMPLIANT;
self_priority=PRIORITY_5;
END
END
BMC_WORST_SLA_STATE_PRIORITY_MAPPING;
name=test_sla;
sla_state=AT_RISK;
self_priority=PRIORITY_2;
END
END
BMC_WORST_SLA_STATE_PRIORITY_MAPPING;
name=test_sla;
sla_state=BREACHED;
self_priority=PRIORITY_1;
END

In this example, the SelfPriorityFunction of the component definition is set equal to WORST_SLA_STATE and the name of the mapping value is test_sla.

BMC_System;
mc_udid=compx;
Name=compx;
SelfPriorityFunction=WORST_SLA_STATE;
SelfPriorityFunctionParam=test_sla
PriorityWatchdog=YES;
END