Providing Open Architecture High Availability Solutions

It also allows for the determination of how modifying (disabling, changing, adding, etc.) a

component affects the other components within the system.

• Logical Dependencies – As discussed in Section 4.0, system components may also have

dependencies beyond the traditional physical dependencies. For example, an application on a

system CPU card may depend on a database located on a separate CPU card. These

dependencies are often represented using a dual-connected digraph (directional graph) in

which each component is linked to every other component upon which it depends, and each

component is linked to every component that depends on it. The system model contains

sufficient information to be able to understand and track these complex dependencies.

• Service Groups of Redundant Components – The system model should support the ability

to represent groups of redundant components as logical services called service groups. A

service group corresponds to the ISO term ‘protected group.’ The system model maintains the

redundancy policy and the operational role (active, standby or spare) of each component

according to the component’s state and the policy of the redundancy group (i.e., N+1, 2N,

N+M, etc.). An example of a service group is the power to the chassis. Multiple power

supplies work together to ensure uninterrupted power. These supplies are grouped together for

management purposes because they are interchangeable and provide the same service. While

other components in the system may depend on power being available, they do not depend on

any individual power supply being operational. Therefore, other system components depend

on the power service group, which logically represents the individual power supply

components.

5.3.3 Approach

Before system deployment, an architecture, which encompasses the appropriate fault domains and

redundancy model, is first developed and is implemented as the system model. Active and standby

components are configured per the requirements of the system model. Component dependency

information is also placed into the system model.

When the system boots up, the actual system component population is created. System components

are automatically detected and added to the population census. As the system operates, the system

is continuously monitored. The actual system component population is updated to reflect any

additions, changes, or deletions to the population of system components.

Dependency relationships between the system components are continuously monitored. Changes

(additions, deletions, or modifications) to a component, which has a dependency relationship with

another component, must consider the effects on the dependent component before executing the

change operation.

The system model also provides methods to control the configuration of the system components.

Within this capability is the ability to select the appropriate component to succeed as the primary

when performing a switchover. This switchover capability is discussed in Section 6.0 as part of

Fault Management.

5.3.4 Techniques

• Determining Actual System Component Population (Auto-detection). This technique

determines what components are in the system. It allows for the isolation of system

components that are not required for the service. Components added to system (hot-

swap/software installation) can be automatically detected and identified before components

are enabled. Automatic detection and identification occurs similarly for component removal.