History
The AIS is part of the Service Availability Interfaces (SAI) of the SA Forum. The original specifications, released on April 14, 2003, were the Availability Management Framework (AMF), the Cluster Membership Service (CLM) and four other utility services (Checkpoint, Event, Message, Lock). Additional services were added in subsequent releases. * Release 3 (January 18, 2006) added the first set of management services: Log, Notification and Information Model Management (IMM). * Release 4 (February 27, 2007) extended the utility services with Timer and Naming. * Release 5 (October 16, 2007) extended the management services with Security and added the Software Management Framework. * Release 6 (October 21, 2008) added the Platform Management Service to close the gap between AIS and HPI ( Hardware Platform Interface). AIS consists of 12 services and two frameworks. The services are classified into three functional groups - AIS Platform Services, basic AIS Management Services, and general AIS Utility Services - in addition to the AIS Frameworks. Initially, the APIs were defined in theService dependencies
The different services and frameworks of the interface specifications have been designed to bePlatform services
The Platform Management Service (PLM) provides a logical view of the hardware and the low-level software of the system. Low-level software in this sense comprises the operating system and virtualization layers that provide execution environments for all kinds of software. The main logical entities implemented by PLM are : * Hardware Element (HE) - A hardware element is a logical entity that represents any kind of hardware entity, which can be, for instance, a chassis, a CPU blade, or an I/O device. Typically, all Field Replaceable Units (FRUs) are modeled as hardware elements. * Execution Environment (EE) - An execution environment is a logical entity that represents an environment capable of running some software programs. For example, a CPU blade or anManagement services
The various entities implemented by the AIS services (e.g. execution environments, checkpoints, components, etc.) are represented as managed objects in the SA Forum Information Model (IM), which can be seen as a configuration management database. The managed objects are instances of object classes defined by the relevant AIS service specification, which defines the class attributes and administrative operations. The administrative operations specified for the object classes represent operations that can be performed on the entities represented by the objects, e.g. locking a service unit or exporting the contents of the IM in XML format. The objects in the IM are stored in a tree hierarchy where an object can have, at most, one parent object and any number of child objects. The logical entities represented by the objects in the IM are not generally implemented by the IMM Service itself; instead, user applications and the AIS Services, such as the Checkpoint Service or the Availability Management Framework provide their implementation. Therefore, these are called object implementers (OI). For management purposes, all AIS services expose their implemented entities as managed objects through the IMM service. There are two categories of objects and attributes in the IM: runtime and configuration. Runtime objects and attributes reflect the current state of the entities they represent – they are of ''descriptive'' nature. In contrast, configuration objects and attributes are ''prescriptive'' as for management applications – or object managers (OM) – they are the means to provide input to the object implementers on what entities they need to implement. Configuration objects may include both configuration and runtime attributes while runtime objects may include only runtime attributes. Administrative operations may be defined on both object categories. Accordingly, the IMM Service exposes a “ southbound” interface – the IMM-OI API – to object implementers and a “Log
The log service is intended for event logging, that is, for collecting cluster-wide, function-based (as opposed to implementation specific) information about the system, which is suited for system administrators or automated tools. The Log Service enables applications to express and write log records through log streams that lead to particular output destinations, such as a named file. Once at the output destination, a log record is subject to output formatting rules, which are configurable and public. The logging application does not need to be aware of any of these aspects (e.g. the destination file location, file rotation or formatting, etc.) as the Log Service handles them based on the current settings for the targeted log stream. Since the output format is public, third party tools can read these log files. Four types of log streams are specified: ''alarm'' (ITU X.733 and ITU X.736 based log records), ''notification'' (ITU X.730 and ITU X.731 based log records), ''system'' and ''application''. The application type is used by applications to define application-specific log streams. There is exactly one predefined log stream for each of the alarm, notification, and system log stream types in an SA Forum cluster. User applications are allowed to use any of the predefined streams or create new application-specific log streams.Notification
The notification service is - to a great degree - based on theSecurity
The security service provides mechanisms that can be used by AIS Services toFrameworks
Availability Management Framework
The Availability Management Framework is the enabler ofSoftware Management Framework
An SA Forum compliant system can be characterized by its deployment configuration, which consists of the software deployed in the system along with all configured software entities. The deployment configuration constitutes an essential part of the information model managed by the IMM Service. The Software Management Framework (SMF) maintains the part of the information model that describes the software available for, and deployed in, the cluster. But the main purpose of SMF is enabling the evolution of a live system by orchestrating the migration from one deployment configuration to another. In SMF terms, this migration process is called an upgrade campaign. The Software Management Framework defines an XML schema to be used to specify an upgrade campaign. An SMF implementation migrates the system from one deployment configuration to a new desired one based on such an XML file, which is essentially aUtility Services
Checkpoint
The Checkpoint Service provides a facility for processes to recordEvents
The Event Service is a publish/subscribe multipoint-to-multipoint communication mechanism that is based on the concept of event channels: one or more publishers communicate asynchronously with one or more anonymous subscribers by using events over an event channel. Event channels are cluster-wide named entities that provide best effort delivery of events. Publishers can also be subscribers on the same event channel. Events consist of a standard header and zero or more bytes of published event data. The Event Service API does not impose a specific layout for the published event data. When a process subscribes on an event channel to receive published events, it specifies the filters to apply on the published events. Events are only delivered to the process if they satisfy the provided filters.Locks
The Lock Service is a distributed lock service, which is intended for use in a cluster where processes in different nodes might compete with each other for access to a shared resource. For them, the Lock Service provides entities called lock resources, which in turn, application processes use to coordinate access to those shared resources. The Lock Service provides a simple lock model supporting one locking mode for exclusive access and another one for shared access. The locks provided by the Lock Service are non-recursive. Thus, claiming one lock does not implicitly claim another lock; rather, each lock must be claimed individually.Messages
The Message Service specifies APIs for a cluster-wide inter-process communicationsystem. The communication is based on message queues identified by a logical name. Any number of processes can send messages to a message queue, but one process at a time at most can open it for receiving. The single message queue thus supports point-to-point or multi-point-to-point communication patterns. Processes sending messages to a message queue are unaware of the identity of the receiving process; therefore, the process that was originally receiving these messages may have been replaced by another process during aNaming
The Naming Service provides a mechanism by which human-friendly names are associated with (‘bound to’) objects, so that these objects can be looked up given their names. The objects typically represent service access points, communication end-points and other resources that provide some sort of service. The Naming Service imposes neither a specific layout nor a convention on either the names (Timers
The Timer Service provides a mechanism by which client processes can set timers and be notified when a timer expires. A timer is a logical object that is dynamically created and represents its expiry time as either an absolute time or duration from the current time. The Timer Service provides two types of timers: single event timers and periodic timers. Single event timers will expire once and are deleted after notification. Periodic timers will expire each time a specified duration is reached, and the process is notified about the expirations. Periodic timers have to be explicitly deleted by invoking a timer deletion function.Programming model
All the AIS services share the same programming model. The same naming conventions, standard predefined types and constants, API semantics, library life cycle control, etc. are used throughout the specification. The SA Forum Application Interface occurs between aBackward compatibility
To achieve backward compatibility when evolving the AIS specification, it follows a number of rules: * A function or type definition never changes for a specific SA Forum release. * Changes in a function or type definition (adding a new argument to a function, adding a new field to a data structure) force the definition of a new function or type name. A new function or type name is built from the original name in the previous version with a suffix indicating the version where the function/type changed (for instance, saAmfComponentRegister_3()). * As an exception to the previous rule, new enum values, flag values, or union fields can be added to an existing enum, flag, or union type without changing the type name, as long as the size of the enum, flag, or union type does not change. * AIS implementers must ensure that they respect the version numbers provided by the application when it initializes the library and do not expose new enum values to applications using older versions. * AIS implementers must also ensure that they respect the version numbers provided by the application when the library is initialized, with regard to new or modified error codes and do not expose error codes that only apply to functions in the most recent version of the specification to applications written to an older version of the specification. As an example, consider a majorVersion Vx of a given service that includes a function f(), and assume that f() had to be modified in a newer majorVersion Vy (Vy > Vx), which led to the introduction of the f_y() variant that now replaces f() in Vy. Considering an AIS implementation that supports both versions Vx and Vy, a process can initialize the library specifying either Vx or Vy: * if the process initializes a library handle with Vx, this handle does not provide access to functions that have been introduced in versions newer than Vx. In particular, this handle will not enable the process to successfully invoke f_y() * if the process initializes a library handle with Vy, this handle does not provide access to a function introduced in versions older than Vy and then replaced by a newer variant of the same function. In particular, this handle will not enable the process to successfully invoke f(). Note, however, that a process may initialize the library multiple times each time with the version appropriate to the functionality it intends to obtain. The specification document of an AIS Service for Vy only includes the latest variant of a function or type definition supported by Vy. Specification releases are versioned as:Implementation Registry
The SA Forum Implementation Registry is a process that enables implementations of the SA Forum specifications to be registered and made publicly available. Membership is not required to register implementations. Implementations that have been successfully registered may be referred to as “Service Availability Forum Registered”.See also
* Service Availability Forum * OpenSAFExternal links