|
Networks & Infrastructure
SA Forum Interface Specifications
An Introduction
by Asif Naseem
The following article is a special addition to Telecommunications Magazine’s online coverage on the activities in the SAF (Service Availability Forum).
The Service Availability Forum (SA Forum) (www.saforum.org) is a vendor consortium dedicated to developing and promoting interface specifications that enable independent software vendors to develop standards-based service availability middleware. The consortium has provided two key sets of specifications to date. The first one, termed Hardware Platform Interface (HPI), defines a hardware abstraction layer that facilitates a user application to manage a given hardware platform using a standard interface. The second set of interface specifications, termed Application Interface Specification (AIS), establishes a standards-based abstraction layer between the service availability middleware and the application. In early 2006, the SA Forum released the latest versions of the two sets of specifications under a unifying architecture [1]. The SA Forum has also released an HPI-to-AdvancedTCA Mapping Specification to assist the developers of HPI services on ATCA platforms. To illustrate the use and importance of SA Forum specifications, consider the abstract view of a highly available system depicted in Figure 1. The implementation of the specifications provides three key benefits:
The ability to discover, monitor and manage the hardware resources in the underlying platform in a manner that is hardware agnostic. This is accomplished through the implementation of services specified by HPI. This results in the portability of the HPI-compliant service availability middleware across different hardware platforms that implement HPI services.
Portability of applications developed using AIS across multiple AIS compliant service availability middleware.And, finally, standardized access to management capabilities of HPI and AIS services.
Here is a quick update on the latest release of the interface specifications.
The Hardware Platform Interface Specification (HPI)
The HPI capabilities can be categorized in three broad areas.
· Discovery of different hardware resources
· Monitoring the state of such resources
· Management of these resources so appropriate actions can be taken in case of failure
Discovery
HPI allows user applications to discover and enumerate the set of hardware resources present within the system along with the set of management capabilities those elements possess. HPI enables discovery and monitoring of real-time dynamic information of all the configured hardware resources e.g., compute cards, networking boards, fans, power supplies, etc. The HPI service collects and maintains inventory management information about various hardware entities which typically includes information such as the manufacturer ID, product name, product version, serial number, etc. This information can then be used by the service availability middleware to manage the platform resources and apply appropriate availability management policies.Monitoring
The HPI service includes detailed mechanisms to monitor the health and performance of various hardware resources. The notification and logging capabilities provide a mechanism to monitor, communicate, and log various events occurring in the system. Key examples include sensor events that identify the change in the state of a sensor, such as a temperature or a voltage gauge exceeding or dropping below one of its pre-defined thresholds; hot swap events that identify a change in the hot swap state of a field replaceable unit; resource failure events that identify whether a resource has failed, has been restored to a healthy state, or has been added to the system.
Management
Manageable hardware resources – termed as HPI entities – generally have one or more management instruments associated with them. Some key examples include sensors, controls, watchdog timers, and annunciators. Sensors provide information on an HPI entity through the measurement of a critical hardware entity attribute, such as a voltage sensor or a temperature sensor. As the state of sensors change, HPI will also send event notifications to all subscribing applications identifying the change in sensor state, such as a voltage or temperature sensor exceeding a critical threshold. Controls provide read/write access to control devices associated with hardware entities such as LEDs, dry contact closures, LCD display, audible alarm indicators, etc. Controls allow an HPI user application to customize the manner in which information such as alarms are communicated to the system administrator. Watchdog timers provide mechanisms to monitor the health of a system by ensuring that critical aspects of the system are progressing well, e.g., BIOS operations or the loading of the operating system. Annunciators provide abstracted controls that can have a set of alarm conditions associated with them. The annunciators ensure that the alarms are properly annunciated through the platform’s and the entity’s alarm indicators.
The Application Interface Specification (AIS)
The current release of AIS consists of an availability management framework and eight distinct services that form the basis of service availability middleware that can be used in developing and deploying highly available systems and services. Please see the following brief introductions.
Availability Management Framework (AMF)
This is the software entity that coordinates redundant resources to eliminate single points of failure in a cluster. It provides a consistent view of one logical system that comprises a number of nodes. each of which hosts various resources in a distributed computing environment.
Information Model Management (IMM)
This service provides a consistent mechanism to represent various system components in an information system model, and provides a way to access and manage them. The IMM performs administrative operations on components in the system model as well as operations for interrogating the state of the various components represented in the system model.
Cluster Membership (CMS)
This service provides a bookkeeping function that maintains up-to-date cluster membership information as the nodes enter or leave the system. Applications register callback functions with CMS to receive current cluster membership notifications as changes occur in the cluster configuration.
Checkpointing (CKPT)
This service provides the capability to record and retain dynamic state information that can be used by a redundant resource to seamlessly resume the service provided by the failed resource. It provides a facility for processes to record checkpoint data incrementally. In the event of a failure such checkpoint data can be retrieved, and execution can be resumed using the state recorded before the failure.
Event (EVT)
In a highly available system, it is critical that the numerous events generated within the system are quickly and efficiently communicated to other relevant system components. The event service provides such a mechanism for applications to subscribe to receive events as and when they occur. The EVT also provides a mechanism where multiple publishers can communicate with multiple subscribers over event channels.
Messaging (MSG)
This service provides efficient mechanism for communicating a wide variety of information such as application state information, event and error notifications, fault management information, etc. The messaging service provides an effective way for distributed components to efficiently communicate and coordinate their activities within a cluster.
Logging (LOG)
This service enables network/system administrators - or automated facilities - to review current and historical logged information to trouble shoot issues such as mis-configurations, network disconnects and unavailable resources. An SA Forum compliant ecosystem assumes the AIS LOG service, or some functionally equivalent service is available for use by service availability applications as well as other AIS services.
Notification (NTF)
The NTF service provides a means by which applications running in the cluster can send notifications related to system events that can be received by interested entities that have subscribed to receive such notifications. One of the typical subscribers would be the LOG service which maintains consolidated view of a cluster-wide system event log.
Lock (LCK)
The lock service provides a distributed lock management capability that resolves potential conflict that may arise when processes running on different nodes within a cluster might attempt to access a shared resource at the same time. This service provides entities -- called lock resources -- that are used to synchronize access to shared resources between different processes.
In conclusion
This concludes a very brief overview of the SA Forum and what functionality is being addressed by the specifications published to date. It should be noted that HPI is already a commercial success. Since its initial release in November of 2004, there have been two versions of HPI implemented in commercial products. Some of the platform providers that are implementing HPI include but are not limited to Motorola, Intel, RadiSys, Kontron, Augmentix, Performance Technologies, Continuous Computing and IBM. Some of the middleware providers who are currently implementing to HPI include but are not limited to GoAhead Software, OpenClovis and Wind River. Although a younger specification, AIS is gaining much traction in the industry since the latest release in January of 2006. Providers such as GoAhead Software, Motorola and OpenClovis have working implementations currently available. The SA Forum will release the next version of the specifications in January 2007.
Dr. Asif Naseem is the President, Service Availability Forum and Chief Operating Officer, GoAhead Software
|
