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.2System 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
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.
High Availability Software for the Intel® NetStructureTM ZT 4901 Technical Product Specification | 19 |
