Filter
Top Products
High Availability Software for the Intel
®
NetStructure
TM
ZT 4901 Technical Product Specification 19
Introduction
The design of the application should be made as portable as possible. This requires that the design
be implemented in a modular approach that isolates the system management requirements from the
host application. This division of responsibilities can be achieved through a layered
implementation. See Chapter 3, “Host Application Software” for more information.
In addition to taking a modular approach, the application designer should recognize the importance
of producing a hardened application. A hardened application must at least provide a capable
logging mechanism that allows for application faults to be reconstructed and corrected. It should
also adhere to good coding practices such as validating all input parameters and return statuses. A
more proactive approach is to implement fault recovery mechanisms. This could include the
capturing of faults and the isolation of faulted application components.
2.3.2 System Management
System management is the mechanism by which system configuration and fault characteristics are
established, insuring system health is maintained. In the Intel
®
Redundant Host architecture there
are extensive sets of APIs that provide the developer with a fine level of control of the platform.
The API described in Chapter 6, “Redundant Host API” deals with the management of redundant
hosts that reside in a single chassis. In order to manage such a configuration, a number of function
calls are required so that predetermined default actions can be prescribed depending on the desired
switchover strategy. The required functions are based on the Hot Swap Infrastructure Interface
Specification, PICMG 2.12, specifically in the Redundant Host API chapter. The supplied APIs
provide the following abilities:
• Enumerate the hosts, domains, and slots in the system
• Get information about devices in slots
• Initiate domain switchovers among hosts
• Enable and disable notifications regarding switchover operations
• Specify actions that result from hardware-initiated alarms and control notifications about
alarms.
Chassis management is achieved using the IPMI infrastructure. The IPMI interface exposes the
embedded monitoring devices such as temperature and voltage sensors. Currently there is no
industry standard API for managing IPMI devices, primarily because the devices that are used may
vary significantly between chassis configurations. Since the drivers supplied for use in the
Redundant Host architecture are operating system dependant, the interfaces used to access the
IPMI devices are not necessarily portable between the supported operating systems.
The supplied Hot Swap API provides a mechanism to identify the topology and Hot Swap state
within a specified chassis. By using this API the system management application is able to identify
which slots are populated and the power states of the occupying boards. There are additional APIs
that allow for simulated backplane peripheral insertion and extraction. In addition, this API
provides for notification of Hot Swap events.
The Slot Control Interface is independent of the Redundant Host driver. This separation of
functionality is designed to allow for slot control functionality in a chassis without full hot swap or
redundant host capabilities. The Slot Control API is based on the PICMG 2.12 High Availability
Slot Control Interface functions. It interacts with the Slot Control Driver to create IPMI messages
through which a finer granularity of board control can be achieved then was found in previous
generations of High Availability systems. Using the Slot Control API the application can retrieve
information regarding “Board Present Detection”, “Board Healthy”, and “Board Reset” capability.