Service Availability
TM
Forum
Application Interface Specification
Availability Management Framework SAI-AIS-AMF-B.04.01
This specification was reissued on September 30, 2011 under the Artistic License 2.0.
The technical contents and the version remain the same as in the original specification.
.
.
1
5
10
15
20
25
30
35
40
Service Availability
TM
Application Interface Specification
Legal Notice
SERVICE AVAILABILITY™ FORUM SPECIFICATION LICENSE AGREEMENT
The Service Availability™ Forum Application Interface Specification (the "Package") found at the URL
http://www.saforum.org is generally made available by the Service Availability Forum (the "Copyright Holder") for use in developing products
that are compatible with the standards provided in the Specification. The terms and conditions which govern the use of the Package are covered
by the Artistic License 2.0 of the Perl Foundation, which is reproduced here.
The Artistic License 2.0
Copyright (c) 2000-2006, The Perl Foundation.
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
Preamble
This license establishes the terms under which a given free software Package may be copied, modified, distributed, and/or redistributed.
The intent is that the Copyright Holder maintains some artistic control over the development of that Package while still keeping the Package
available as open source and free software.
You are always permitted to make arrangements wholly outside of this license directly with the Copyright Holder of a given Package. If the
terms of this license do not permit the full use that you propose to make of the Package, you should contact the Copyright Holder and seek a
different licensing arrangement.
Definitions
"Copyright Holder" means the individual(s) or organization(s) named in the copyright notice for the entire Package.
"Contributor" means any party that has contributed code or other material to the Package, in accordance with the Copyright Holder's
procedures.
"You" and "your" means any person who would like to copy, distribute, or modify the Package.
"Package" means the collection of files distributed by the Copyright Holder, and derivatives of that collection and/or of those files. A given
Package may consist of either the Standard Version, or a Modified Version.
"Distribute" means providing a copy of the Package or making it accessible to anyone else, or in the case of a company or organization, to
others outside of your company or organization.
"Distributor Fee" means any fee that you charge for Distributing this Package or providing support for this Package to another party. It does not
mean licensing fees.
"Standard Version" refers to the Package if it has not been modified, or has been modified only in ways explicitly requested by the Copyright
Holder.
"Modified Version" means the Package, if it has been changed, and such changes were not explicitly requested by the Copyright Holder.
"Original License" means this Artistic License as Distributed with the Standard Version of the Package, in its current version or as it may be
modified by The Perl Foundation in the future.
"Source" form means the source code, documentation source, and configuration files for the Package.
"Compiled" form means the compiled bytecode, object code, binary, or any other form resulting from mechanical transformation or translation of
the Source form.
Permission for Use and Modification Without Distribution
(1) You are permitted to use the Standard Version and create and use Modified Versions for any purpose without restriction, provided that you
do not Distribute the Modified Version.
Permissions for Redistribution of the Standard Version
(2) You may Distribute verbatim copies of the Source form of the Standard Version of this Package in any medium without restriction, either
gratis or for a Distributor Fee, provided that you duplicate all of the original copyright notices and associated disclaimers. At your discretion,
such verbatim copies may or may not include a Compiled form of the Package.
(3) You may apply any bug fixes, portability changes, and other modifications made available from the Copyright Holder. The resulting
Package will still be considered the Standard Version, and as such will be subject to the Original License.
Distribution of Modified Versions of the Package as Source
(4) You may Distribute your Modified Version as Source (either gratis or for a Distributor Fee, and with or without a Compiled form of the
Modified Version) provided that you clearly document how it differs from the Standard Version, including, but not limited to, documenting any
non-standard features, executables, or modules, and provided that you do at least ONE of the following:
(a) make the Modified Version available to the Copyright Holder of the Standard Version, under the Original License, so that the Copyright
Holder may include your modifications in the Standard Version.
4 SAI-AIS-AMF-B.04.01 AIS Specification
1
5
10
15
20
25
30
35
40
Service Availability
TM
Application Interface Specification
Legal Notice
(b) ensure that installation of your Modified Version does not prevent the user installing or running the Standard Version. In addition, the
Modified Version must bear a name that is different from the name of the Standard Version.
(c) allow anyone who receives a copy of the Modified Version to make the Source form of the Modified Version available to others under
(i) the Original License or
(ii) a license that permits the licensee to freely copy, modify and redistribute the Modified Version using the same licensing terms that
apply to the copy that the licensee received, and requires that the Source form of the Modified Version, and of any works derived from it, be
made freely available in that license fees are prohibited but Distributor Fees are allowed.
Distribution of Compiled Forms of the Standard Version or Modified Versions without the Source
(5) You may Distribute Compiled forms of the Standard Version without the Source, provided that you include complete instructions on how to
get the Source of the Standard Version. Such instructions must be valid at the time of your distribution. If these instructions, at any time while
you are carrying out such distribution, become invalid, you must provide new instructions on demand or cease further distribution.
If you provide valid instructions or cease distribution within thirty days after you become aware that the instructions are invalid, then you do not
forfeit any of your rights under this license.
(6) You may Distribute a Modified Version in Compiled form without the Source, provided that you comply with Section 4 with respect to the
Source of the Modified Version.
Aggregating or Linking the Package
(7) You may aggregate the Package (either the Standard Version or Modified Version) with other packages and Distribute the resulting
aggregation provided that you do not charge a licensing fee for the Package. Distributor Fees are permitted, and licensing fees for other
components in the aggregation are permitted. The terms of this license apply to the use and Distribution of the Standard or Modified Versions as
included in the aggregation.
(8) You are permitted to link Modified and Standard Versions with other works, to embed the Package in a larger work of your own, or to build
stand-alone binary or bytecode versions of applications that include the Package, and Distribute the result without restriction, provided the
result does not expose a direct interface to the Package.
Items That are Not Considered Part of a Modified Version
(9) Works (including, but not limited to, modules and scripts) that merely extend or make use of the Package, do not, by themselves, cause the
Package to be a Modified Version. In addition, such works are not considered parts of the Package itself, and are not subject to the terms of this
license.
General Provisions
(10) Any use, modification, and distribution of the Standard or Modified Versions is governed by this Artistic License. By using, modifying or
distributing the Package, you accept this license. Do not use, modify, or distribute the Package, if you do not accept this license.
(11) If your Modified Version has been derived from a Modified Version made by someone other than you, you are nevertheless required to
ensure that your Modified Version complies with the requirements of this license.
(12) This license does not grant you the right to use any trademark, service mark, tradename, or logo of the Copyright Holder.
(13) This license includes the non-exclusive, worldwide, free-of-charge patent license to make, have made, use, offer to sell, sell, import and
otherwise transfer the Package with respect to any patent claims licensable by the Copyright Holder that are necessarily infringed by the
Package. If you institute patent litigation (including a cross-claim or counterclaim) against any party alleging that the Package constitutes direct
or contributory patent infringement, then this Artistic License to you shall terminate on the date that such litigation is filed.
(14) Disclaimer of Warranty:
THE PACKAGE IS PROVIDED BY THE COPYRIGHT HOLDER AND CONTRIBUTORS "AS IS' AND WITHOUT ANY EXPRESS OR
IMPLIED WARRANTIES. THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-
INFRINGEMENT ARE DISCLAIMED TO THE EXTENT PERMITTED BY YOUR LOCAL LAW. UNLESS REQUIRED BY LAW, NO
COPYRIGHT HOLDER OR CONTRIBUTOR WILL BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL
DAMAGES ARISING IN ANY WAY OUT OF THE USE OF THE PACKAGE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Service Availability
TM
Application Interface Specification
Table of Contents
1
5
10
15
20
25
30
35
40
Table of Contents
Availability Management Framework
1 Document Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.1 Document Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.2 AIS Documents Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3.1 New Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
1.3.2 Clarifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
1.3.3 Deleted Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
1.3.4 Other Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
1.3.5 Superseded and Superseding Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
1.3.6 Changes in Return Values of API and Administrative Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
1.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.5 How to Provide Feedback on the Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.6 How to Join the Service Availability™ Forum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.7 Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.7.1 Member Companies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
1.7.2 Press Materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.1 Overview of the Availability Management Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3 System Description and System Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1 Logical Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.1.1 Cluster and Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
3.1.1.1 AMF Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
3.1.1.2 AMF Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
3.1.2 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
3.1.2.1 SA-Aware Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
3.1.2.1.1 Container and Contained Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
3.1.2.2 Non-SA-Aware Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
3.1.2.2.1 External Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
3.1.2.2.2 Non-Proxied, Non-SA-Aware Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
3.1.2.2.3 Integration and Usage of Non-SA-Aware Local Components . . . . . . . . . . . . . . . . . . . . . . . . .47
3.1.2.3 Proxy and Proxied Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
3.1.2.4 Component Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
3.1.2.5 Component Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50
3.1.3 Component Service Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50
3.1.3.1 Component Service Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
3.1.4 Service Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
3.1.4.1 Service Unit Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
3.1.5 Service Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
3.1.5.1 Service Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
3.1.6 Service Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
6 SAI-AIS-AMF-B.04.01 AIS Specification
Service Availability
TM
Application Interface Specification
Table of Contents
1
5
10
15
20
25
30
35
40
3.1.6.1 Service Group Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
3.1.7 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
3.1.7.1 Application Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
3.1.8 Protection Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
3.1.9 Mapping of Service Units to Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
3.1.10 Service Unit Instantiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
3.1.11 Illustration of Logical Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
3.2 State Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.2.1 Service Unit States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
3.2.1.1 Presence State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
3.2.1.2 Administrative State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
3.2.1.3 Operational State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
3.2.1.4 Readiness State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
3.2.1.5 HA State of a Service Unit for a Service Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67
3.2.1.6 HA Readiness State of a Service Unit per Service Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69
3.2.2 Component States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71
3.2.2.1 Presence State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71
3.2.2.2 Operational State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
3.2.2.3 Readiness State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
3.2.2.4 HA State of a Component per Component Service Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
3.2.2.5 HA Readiness State of a Component for a Component Service Instance . . . . . . . . . . . . . . . . . . . . . . . . .84
3.2.3 Service Instance States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
3.2.3.1 Administrative State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
3.2.3.2 Assignment State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88
3.2.4 Component Service Instance States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
3.2.5 Service Group States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
3.2.6 Node States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
3.2.6.1 Administrative State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
3.2.6.2 Operational State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91
3.2.7 Application States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
3.2.8 Cluster States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
3.2.9 Summary of States Supported for the Logical Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94
3.3 Fail-Over and Switch-Over . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
3.4 Possible Combinations of States for Service Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
3.4.1 Combined States for Pre-Instantiable Service Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98
3.4.2 Combined States for Non-Pre-Instantiable Service Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103
3.5 Component Capability Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
3.6 Service Group Redundancy Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
3.6.1 Common Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .110
3.6.1.1 Common Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .110
3.6.1.2 Initiation of the Auto-Adjust Procedure for a Service Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113
3.6.1.3 AMF Node Capacity Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114
3.6.1.3.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117
3.6.1.4 Considerations when Configuring Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120
3.6.2 2N Redundancy Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122
3.6.2.1 Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122
3.6.2.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122
Service Availability
TM
Application Interface Specification
Table of Contents
1
5
10
15
20
25
30
35
40
3.6.2.3 SI Assignments and Failure Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123
3.6.2.3.1 Failure of the Active Service Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123
3.6.2.3.2 Failure of the Standby Service Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123
3.6.2.3.3 Auto-Adjust Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123
3.6.2.3.4 Cluster Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124
3.6.2.3.5 Role of the List of Ordered Service Units in Assignments and Instantiations . . . . . . . . . . . .124
3.6.2.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125
3.6.2.5 UML Diagram of the 2N Redundancy Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131
3.6.3 N+M Redundancy Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132
3.6.3.1 Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132
3.6.3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
3.6.3.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135
3.6.3.4 SI Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137
3.6.3.4.1 Reduction Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
3.6.3.5 Examples for Service Unit Fail-Over . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144
3.6.3.5.1 Handling of a Node Failure when Spare Service Units Exist . . . . . . . . . . . . . . . . . . . . . . . . .144
3.6.3.5.2 Handling of a Node Failure when no Spare Service Units Exist . . . . . . . . . . . . . . . . . . . . . .145
3.6.3.6 Example of Auto-Adjust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146
3.6.3.7 UML Diagram of the N+M Redundancy Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148
3.6.4 N-Way Redundancy Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .149
3.6.4.1 Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .149
3.6.4.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .150
3.6.4.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151
3.6.4.4 SI Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152
3.6.4.4.1 Reduction Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154
3.6.4.5 Failure Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156
3.6.4.6 Example of Auto-Adjust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .158
3.6.4.7 UML Diagram of the N-Way Redundancy Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159
3.6.5 N-Way Active Redundancy Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160
3.6.5.1 Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160
3.6.5.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161
3.6.5.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162
3.6.5.4 SI Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163
3.6.5.4.1 Reduction Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .165
3.6.5.5 Failure Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168
3.6.5.5.1 Example for Failure Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168
3.6.5.6 Example of Auto-Adjust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172
3.6.5.7 UML Diagram of the N-Way Active Redundancy Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .174
3.6.6 No-Redundancy Redundancy Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175
3.6.6.1 Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175
3.6.6.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .176
3.6.6.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177
3.6.6.4 SI Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177
3.6.6.4.1 Reduction Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178
3.6.6.5 Failure Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179
3.6.6.6 Example of Auto-Adjust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .180
3.6.6.7 UML Diagram of the No-Redundancy Redundancy Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181
3.6.7 The Effect of Administrative Operations on Service Instance Assignments . . . . . . . . . . . . . . . . . . .182
3.6.7.1 Locking a Service Unit or a Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182
8 SAI-AIS-AMF-B.04.01 AIS Specification
Service Availability
TM
Application Interface Specification
Table of Contents
1
5
10
15
20
25
30
35
40
3.6.7.2 Unlocking a Service Unit, a Service Group, or a Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .183
3.7 Component Capability Model and Service Group Redundancy Model . . . . . . . . . . . . . . . . . . . . 184
3.8 Dependencies Among SIs, Component Service Instances, and Components . . . . . . . . . . . . . . . 185
3.8.1 Dependencies Among Service Instances and Component Service Instances . . . . . . . . . . . . . . . . . . .185
3.8.1.1 Dependencies Among SIs when Assigning a Service Unit Active for a Service Instance . . . . . . . . . . .185
3.8.1.2 Impact of Disabling a Service Instance on the Dependent Service Instances . . . . . . . . . . . . . . . . . . . . .186
3.8.1.3 Dependencies Among Component Service Instances of the same Service Instance . . . . . . . . . . . . . . .186
3.8.2 Dependencies Among Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .187
3.9 Approaches for Integrating Legacy Software or Hardware Entities . . . . . . . . . . . . . . . . . . . . . . . 189
3.10 Component Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
3.11 Error Detection, Recovery, Repair, and Escalation Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
3.11.1 Basic Notions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .191
3.11.1.1 Error Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .191
3.11.1.2 Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .191
3.11.1.3 Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192
3.11.1.3.1 Restart Recovery Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193
3.11.1.3.2 Fail-Over Recovery Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .194
3.11.1.3.3 Application Restart Recovery Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .197
3.11.1.3.4 Cluster Reset Recovery Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .197
3.11.1.4 Repair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .197
3.11.1.4.1 Recovery and Associated Repair Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .199
3.11.1.4.2 Restrictions to Auto-Repair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200
3.11.1.5 Recovery Escalation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201
3.11.2 Recovery Escalation Policy of the Availability Management Framework . . . . . . . . . . . . . . . . . . . .201
3.11.2.1 Recommended Recovery Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201
3.11.2.2 Escalations of Levels 1 and 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202
3.11.2.3 Escalation of Level 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205
4 Local Component Life Cycle Management Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
4.1 Common Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
4.2 Configuring the Pathname of CLC-CLI Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
4.3 CLC-CLI Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
4.4 Configuring CLC-CLI Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
4.5 Exit Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
4.6 INSTANTIATE Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
4.7 TERMINATE Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
4.8 CLEANUP Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
4.9 AM_START Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
4.10 AM_STOP Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
4.11 Usage of CLC-CLI Commands Based on the Component Category . . . . . . . . . . . . . . . . . . . . . 216
5 Proxied Components Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
5.1 Properties of Proxy and Proxied Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
5.2 Life Cycle Management of Proxied Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
5.3 Proxy Component Failure Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Service Availability
TM
Application Interface Specification
Table of Contents
1
5
10
15
20
25
30
35
40
6 Contained Components Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
6.1 Overview of Container and Contained Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
6.1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .221
6.1.2 Component Category . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .221
6.1.3 Multiple Components per Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .221
6.1.4 Life Cycle Management of Contained Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .221
6.1.5 Container and Contained Components in Service Units and Service Groups . . . . . . . . . . . . . . . . . .221
6.1.6 Redundancy Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .222
6.1.7 Administrative Operations and Container and Contained Components . . . . . . . . . . . . . . . . . . . . . . .223
6.1.8 Failure Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .223
6.2 Life Cycle Management of Contained Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
6.2.1 Container CSI and Its Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .224
6.2.2 Assignment of the Container CSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .224
6.2.3 Life Cycle Callbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .225
6.3 Failure Handling for Container and Contained Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
6.4 Proxied and Contained Components: Similarities and Differences . . . . . . . . . . . . . . . . . . . . . . . 227
7 Availability Management Framework API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
7.1 Availability Management Framework Model for the APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
7.1.1 Callback Semantics and Component Registration and Unregistration . . . . . . . . . . . . . . . . . . . . . . . .230
7.1.2 Component Healthcheck Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .232
7.1.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .232
7.1.2.2 Variants of Healthchecks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233
7.1.2.3 Starting and Stopping Healthchecks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233
7.1.2.4 Healthcheck Configuration Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233
7.1.2.4.1 Role of Period and Maximum-Duration in Framework-Invoked Healthchecks . . . . . . . . . . .235
7.1.2.4.2 Role of Period in Component-Invoked Healthchecks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .236
7.1.2.4.3 Modification of Healthcheck Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .237
7.1.3 Component Service Instance Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .237
7.1.4 Component Life Cycle Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .238
7.1.5 Protection Group Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .238
7.1.6 Error Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .238
7.1.7 Correlation of Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .239
7.1.8 Component Response to Framework Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .239
7.1.9 API Usage Illustrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .240
7.2 Unavailability of the AMF API on a Non-Member Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
7.2.1 A Member Node Leaves or Rejoins the Cluster Membership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243
7.2.2 Guidelines for Availability Management Framework Implementers . . . . . . . . . . . . . . . . . . . . . . . . .244
7.3 Include File and Library Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
7.4 Type Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
7.4.1 SaAmfHandleT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .245
7.4.2 Component Process Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .245
7.4.2.1 SaAmfPmErrorsT Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .246
7.4.2.2 SaAmfPmStopQualifierT Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .246
7.4.3 Component Healthcheck Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .246
10 SAI-AIS-AMF-B.04.01 AIS Specification
Service Availability
TM
Application Interface Specification
Table of Contents
1
5
10
15
20
25
30
35
40
7.4.3.1 SaAmfHealthcheckInvocationT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .246
7.4.3.2 SaAmfHealthcheckKeyT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .247
7.4.4 Types for State Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .247
7.4.4.1 HA State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .247
7.4.4.2 Readiness State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .247
7.4.4.3 Presence State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .248
7.4.4.4 Operational State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .248
7.4.4.5 Administrative State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .248
7.4.4.6 Assignment State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .249
7.4.4.7 HA Readiness State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .249
7.4.4.8 Proxy Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .249
7.4.4.9 All Defined States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .250
7.4.5 Component Service Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .250
7.4.5.1 SaAmfCSIFlagsT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .250
7.4.5.2 SaAmfCSITransitionDescriptorT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .251
7.4.5.3 SaAmfCSIStateDescriptorT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .252
7.4.5.4 SaAmfCSIAttributeListT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .253
7.4.5.5 SaAmfCSIDescriptorT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .254
7.4.6 Types for Protection Group Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .255
7.4.6.1 SaAmfProtectionGroupMemberT_4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .255
7.4.6.2 SaAmfProtectionGroupChangesT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .255
7.4.6.3 SaAmfProtectionGroupNotificationT_4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .256
7.4.6.4 SaAmfProtectionGroupNotificationBufferT_4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .256
7.4.7 SaAmfRecommendedRecoveryT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .257
7.4.8 SaAmfCompCategoryT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .258
7.4.9 SaAmfRedundancyModelT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260
7.4.10 SaAmfCompCapabilityModelT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260
7.4.11 Notifications-Related Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .261
7.4.11.1 SaAmfNotificationMinorIdT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .261
7.4.11.2 SaAmfAdditionalInfoIdT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .262
7.4.12 SaAmfCallbacksT_4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .263
7.5 Library Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
7.5.1 saAmfInitialize_4() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .264
7.5.2 saAmfSelectionObjectGet() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .267
7.5.3 saAmfDispatch() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .268
7.5.4 saAmfFinalize() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .270
7.6 Component Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
7.6.1 saAmfComponentRegister() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .272
7.6.2 saAmfComponentNameGet() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .276
7.7 Passive Monitoring of Processes of a Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
7.7.1 saAmfPmStart_3() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .278
7.7.2 saAmfPmStop() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .280
7.8 Component Health Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
7.8.1 saAmfHealthcheckStart() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .283
7.8.2 SaAmfHealthcheckCallbackT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .286
7.8.3 saAmfHealthcheckConfirm() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .288
7.8.4 saAmfHealthcheckStop() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .291
AIS Specification SAI-AIS-AMF-B.04.01 11
Service Availability
TM
Application Interface Specification
Table of Contents
1
5
10
15
20
25
30
35
40
7.9 Component Service Instance Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
7.9.1 saAmfHAStateGet() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .293
7.9.2 SaAmfCSISetCallbackT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .295
7.9.3 SaAmfCSIRemoveCallbackT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .298
7.9.4 saAmfCSIQuiescingComplete() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .300
7.9.5 saAmfHAReadinessStateSet() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .303
7.10 Component Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
7.10.1 SaAmfComponentTerminateCallbackT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .307
7.10.2 SaAmfProxiedComponentInstantiateCallbackT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .309
7.10.3 SaAmfProxiedComponentCleanupCallbackT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .311
7.10.4 SaAmfContainedComponentInstantiateCallbackT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .312
7.10.5 SaAmfContainedComponentCleanupCallbackT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .314
7.11 Protection Group Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
7.11.1 saAmfProtectionGroupTrack_4() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .316
7.11.2 SaAmfProtectionGroupTrackCallbackT_4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .319
7.11.3 saAmfProtectionGroupTrackStop() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .322
7.11.4 saAmfProtectionGroupNotificationFree_4() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .323
7.12 Error Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
7.12.1 saAmfComponentErrorReport_4() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .325
7.12.2 saAmfComponentErrorClear_4() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .327
7.12.3 saAmfCorrelationIdsGet() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .330
7.13 Component Response to Framework Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
7.13.1 saAmfResponse_4() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .333
8 AMF UML Information Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
8.1 Use of Entity Types in the AMF UML Information Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
8.2 Notes on the Conventions Used in UML Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
8.3 DN Formats for Availability Management Framework UML Classes . . . . . . . . . . . . . . . . . . . . . 339
8.4 AMF Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
8.5 Availability Management Framework Instances and Types View . . . . . . . . . . . . . . . . . . . . . . . . 342
8.6 Availability Management Framework Instances View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
8.7 AMF Cluster, Node, and Node-Related Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
8.8 Application Classes Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
8.9 Service Group Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
8.10 Service Unit Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
8.11 Service Instance Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
8.12 Component Service Instance Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
8.13 Component and Component Types Class Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
8.13.1 Component Type Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .358
8.13.2 Component Classes Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .360
8.14 AMF Global Component Attributes and Healthcheck Classes . . . . . . . . . . . . . . . . . . . . . . . . . 362
9 Administration API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
12 SAI-AIS-AMF-B.04.01 AIS Specification
Service Availability
TM
Application Interface Specification
Table of Contents
1
5
10
15
20
25
30
35
40
9.1 Availability Management Framework Administration API Model . . . . . . . . . . . . . . . . . . . . . . . 365
9.2 Include File and Library Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
9.3 Type Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
9.3.1 SaAmfAdminOperationIdT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .367
9.4 Availability Management Framework Administration API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
9.4.1 Administrative State Modification Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .368
9.4.2 SA_AMF_ADMIN_UNLOCK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .370
9.4.3 SA_AMF_ADMIN_LOCK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .372
9.4.4 SA_AMF_ADMIN_LOCK_INSTANTIATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .375
9.4.5 SA_AMF_ADMIN_UNLOCK_INSTANTIATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .378
9.4.6 SA_AMF_ADMIN_SHUTDOWN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .380
9.4.7 SA_AMF_ADMIN_RESTART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .383
9.4.8 SA_AMF_ADMIN_SI_SWAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .386
9.4.9 SA_AMF_ADMIN_SG_ADJUST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .389
9.4.10 SA_AMF_ADMIN_REPAIRED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .391
9.4.11 SA_AMF_ADMIN_EAM_START . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .393
9.4.12 SA_AMF_ADMIN_EAM_STOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .395
9.5 Summary of Administrative Operation Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
10 Basic Operational Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
10.1 Administrative Shutdown of a Service Instance in a 2N Case . . . . . . . . . . . . . . . . . . . . . . . . . . 399
10.2 Administrative Shutdown of a Service Unit in a 2N Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
10.3 Administrative Shutdown of a Service Unit for the N-Way Model . . . . . . . . . . . . . . . . . . . . . . 402
10.4 Administrative Lock of a Service Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
10.5 Administrative Lock of a Service Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
10.6 A Simple Fail-Over . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
10.7 Administrative Shutdown of an SI Having a Container CSI . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
10.8 Administrative Lock of an SI Having a Container CSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
10.9 Administrative Lock of a Service Unit with a Container Component . . . . . . . . . . . . . . . . . . . . 411
10.10 Restart of a Container Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
11 Alarms and Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
11.1 Setting Common Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
11.2 Availability Management Framework Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
11.2.1 Availability Management Framework Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .419
11.2.1.1 Component Instantiation Failed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .419
11.2.1.2 Component Cleanup Failed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .421
11.2.1.3 Cluster Reset Triggered by a Component Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .423
11.2.1.4 Service Instance Unassigned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .425
11.2.1.5 Proxy Status of a Component Changed to Unproxied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .427
11.2.2 Availability Management Framework State Change Notifications . . . . . . . . . . . . . . . . . . . . . . . . .428
11.2.2.1 Administrative State Change Notify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .428
11.2.2.2 Operational State Change Notify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .429
11.2.2.3 Presence State Change Notify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .430
AIS Specification SAI-AIS-AMF-B.04.01 13
Service Availability
TM
Application Interface Specification
Table of Contents
1
5
10
15
20
25
30
35
40
11.2.2.4 HA State Change Notify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .431
11.2.2.5 HA Readiness State Change Notify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .432
11.2.2.6 SI Assignment State Change Notify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .433
11.2.2.7 Proxy Status of a Component Changed to Proxied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .434
11.2.3 Availability Management Framework Notifications of Miscellaneous Type . . . . . . . . . . . . . . . . . .435
11.2.3.1 Error Report Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .435
11.2.3.2 Error Clear Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .437
Appendix A Implementation of CLC Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Appendix B API Functions and Registered Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
Appendix C Example for Proxy/Proxied Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Appendix D Interaction with CLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Index of Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
AIS Specification SAI-AIS-AMF-B.04.01 15
1
5
10
15
20
25
30
35
40
Service Availability
TM
Interface Specification
List of Figures
List of Figures
Figure 1: Availability Management Framework Logical Entities and Their Relations . . . . . . . . . . . . . . 37
Figure 2: Elements of the System Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Figure 3: State Diagram of the HA State of an SA-Aware Component for a CSI . . . . . . . . . . . . . . . . . 83
Figure 4: State Transitions for Pre-Instantiable Service Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Figure 5: State Transitions for Non-Pre-Instantiable Service Units . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Figure 6: Example 1 for Node Capacity Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Figure 7: Example 2 for Node Capacity Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Figure 8: Example of the 2N Redundancy Model: Two Service Units on Different Nodes . . . . . . . . . 125
Figure 9: Example of the 2N RM. Two SUs on Different Nodes, Fault Has Occurred . . . . . . . . . . . . 126
Figure 10: Example of the 2N Redundancy Model: Two Service Units on the Same Node . . . . . . . . . 127
Figure 11: Example of the 2N RM: Two SUs on the Same Node, Fault Has Occurred . . . . . . . . . . . . 128
Figure 12: Example of the 2N RM: One Node Provides Standby SUs for Several Service Groups . . . 129
Figure 13: Example of the 2N RM: Each Node Has an Active and a Standby Service Unit . . . . . . . . 130
Figure 14: UML Diagram for the 2N Redundancy Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Figure 15: Example of the N+1 Redundancy Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Figure 16: Example of the N+M Redundancy Model, Where N = 3 and M = 2 . . . . . . . . . . . . . . . . . . 135
Figure 17: UML Diagram of the N+M Redundancy Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Figure 18: Example of the N-Way Redundancy Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Figure 19: UML Diagram of the N-Way Redundancy Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Figure 20: Example of the N-Way Active Redundancy Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Figure 21: UML Diagram of the N-Way Active Redundancy Model . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Figure 22: Example of the No-Redundancy Redundancy Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Figure 23: UML Diagram of the No-Redundancy Redundancy Model . . . . . . . . . . . . . . . . . . . . . . . . 181
Figure 24: SA-Aware Component Consisting of a Single Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Figure 25: SA-Aware Component Consisting of Multiple Processes . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Figure 26: A Single-Process Proxy Component and Two Proxied Components . . . . . . . . . . . . . . . . . 242
Figure 27: 3- Cluster View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Figure 28: 3.1- AMF Instances and Types View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Figure 29: 3.2- AMF Instances View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Figure 30: 3.3- AMF Cluster, Node, and Node-Related Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Figure 31: 3.4- AMF Application Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Figure 32: 3.5- AMF SG Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Figure 33: 3.6- AMF SU Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Figure 34: 3.7- AMF SI Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Figure 35: 3.8- AMF CSI Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Figure 36: 3.9b- AMF Component Type Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Figure 37: 3.9a- AMF Component Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Figure 38: 3.9c- AMF Global Component Attributes and Healthcheck Classes . . . . . . . . . . . . . . . . . . 363
Figure 39: Administrative States and Related Operations for AMF Entities . . . . . . . . . . . . . . . . . . . . 369
Figure 40: Administrative Shutdown of a Service Instance for the 2N Case . . . . . . . . . . . . . . . . . . . . 400
Figure 41: Administrative Shutdown of a Service Unit for the 2N Case . . . . . . . . . . . . . . . . . . . . . . . 401
16 SAI-AIS-AMF-B.04.01 AIS Specification
1
5
10
15
20
25
30
35
40
Service Availability
TM
Interface Specification
List of Figures
Figure 42: Administrative Shutdown of a Service Unit for the N-Way Case . . . . . . . . . . . . . . . . . . . . 403
Figure 43: Administrative Lock of a Service Instance for the 2N Case . . . . . . . . . . . . . . . . . . . . . . . . 404
Figure 44: Administrative Lock of a Service Unit for the 2N Case . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Figure 45: Fail-Over Scenario for a Service Group with the 2N Redundancy Model . . . . . . . . . . . . . 406
Figure 46: Scenario for Shutting Down a Service Instance Having a Container CSI . . . . . . . . . . . . . . 408
Figure 47: Administrative Shutdown of a Service Instance Having a Container CSI . . . . . . . . . . . . . . 409
Figure 48: Administrative Lock of a Service Instance Having a Container CSI . . . . . . . . . . . . . . . . . . 410
Figure 49: Scenario for Locking a Service Unit Containing a Container Component . . . . . . . . . . . . . 412
Figure 50: Administrative Lock of a Service Unit Containing a Container Component . . . . . . . . . . . 413
Figure 51: Restart of a Container Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
AIS Specification SAI-AIS-AMF-B.04.01 17
1
5
10
15
20
25
30
35
40
Service Availability
TM
Interface Specification
List of Tables
List of Tables
Table 1: Superseded Functions and Type Definitions in Version B.04.01. . . . . . . . . . . . . . . . . . . . . . . . 29
Table 2: Changes in Return Values of API and Administrative Functions . . . . . . . . . . . . . . . . . . . . . . . 30
Table 3: Component Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Table 4: Service Unit’s Readiness State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Table 5: Presence State of Components of a Service Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Table 6: Component’s Readiness State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Table 7: HA State of Component/Component Service Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Table 8: Application Developer View for Pre-Instantiable Components. . . . . . . . . . . . . . . . . . . . . . . . . 84
Table 9: Application Developer View for Non-Pre-Instantiable Components. . . . . . . . . . . . . . . . . . . . . 84
Table 10: Combinations of States for a Component. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Table 11: Preferred Number of Active and Standby Assignments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Table 12: Summary of States Supported for the Logical Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Table 13: Combined Administrative States for the Service Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Table 14: Combined States for Pre-Instantiable Service Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Table 15: Combined States for Non-Pre-Instantiable Service Units . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Table 16: Component Capability Model and Service Group Redundancy Model . . . . . . . . . . . . . . . . . 184
Table 17: Recovery and Associated Automatic Repair Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Table 18: Levels of Escalation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Table 19: Usage of CLC-CLI Commands Based on the Component Category . . . . . . . . . . . . . . . . . . . 216
Table 20: Possible Combinations of Values in SaAmfCompCategoryT . . . . . . . . . . . . . . . . . . . . . . . . 259
Table 21: DN Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Table 22: Summary: Applicability of Administrative Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Table 23: Component Instantiation Failed Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
Table 24: Component Cleanup Failed Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
Table 25: Cluster Reset Triggered by a Component Failure Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
Table 26: Service Instance Unassigned Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
Table 27: Proxy Status of a Component Changed to Unproxied Alarm . . . . . . . . . . . . . . . . . . . . . . . . 427
Table 28: Administrative State Change Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
Table 29: Operational State Change Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Table 30: Presence State Change Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Table 31: HA State Change Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Table 32: HA Readiness State Change Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Table 33: SI Assignment State Change Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Table 34: Proxy Status of a Component Changed to Proxied Notification . . . . . . . . . . . . . . . . . . . . . . 434
Table 35: Error Report Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Table 36: Error Clear Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Table 37: Implementation of CLC Operations for Each Component Category . . . . . . . . . . . . . . . . . . . 439
Table 38: API Functions and Registered Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
AIS Specification SAI-AIS-AMF-B.04.01 Chapter 1 19
Service Availability
TM
Application Interface Specification
Document Introduction
1
5
10
15
20
25
30
35
40
1 Document Introduction
1.1 Document Purpose
This document defines the Availability Management Framework of the Application
Interface Specification (AIS) of the Service Availability
TM
Forum (SA Forum). It is
intended for use by implementers of the Application Interface Specification and by
application developers who would use the Application Interface Specification to
develop applications that must be highly available. The AIS is defined in the C pro-
gramming language and requires substantial knowledge of the C programming lan-
guage.
Typically, the Service Availability
TM
Forum Application Interface Specification will be
used in conjunction with the Service Availability
TM
Forum Hardware Platform
Interface Specification (HPI).
1.2 AIS Documents Organization
The Application Interface Specification is organized into several volumes. For a list of
all Application Interface Specification documents, refer to the SA Forum Overview
document [1].
1.3 History
Previous releases of the Availability Management Framework specification:
(1) SAI-AIS-AMF-A.01.01
(2) SAI-AIS-AMF-B.01.01
(3) SAI-AIS-AMF-B.02.01
(4) SAI-AIS-AMF-B.03.01
This section presents the changes of the current release, SAI-AIS-AMF-B.04.01, with
respect to the SAI-AIS-AMF-B.03.01 release. Editorial changes that do not change
semantics or syntax of the described interfaces are not mentioned.
20 SAI-AIS-AMF-B.04.01 Section 1.3.1 AIS Specification
Service Availability
TM
Application Interface Specification
Document Introduction
1
5
10
15
20
25
30
35
40
1.3.1 New Topics
⇒
The HA readiness state of a service unit for a service instance and the HA readi-
ness state of a component for a component service instance have been intro-
duced. The main changes to the specification due to this topic are:
•
The HA readiness state of a service unit for a service instance and the HA
readiness state of a component for a component service instance have been
introduced in Section 3.2.1.6 and Section 3.2.2.5, respectively. Due to the lat-
ter change, Section 3.2.2.4
can reject a CSI assignment. Table 12 in Section 3.2.9 has also been updated
accordingly.
•
The SaAmfHaReadinessStateT type has been introduced in
Section 7.4.4.7, and this extension induced a change to Section 7.4.4.9.
•
As the HA readiness state of a component for a component service instance
is reflected in the protection group track functions, the structures defined in
Section 7.4.6.1, Section 7.4.6.2 (only the description), Section 7.4.6.3, and
Section 7.4.6.4 have also been affected. As a consequence, superseding
structures SaAmfProtectionGroupMemberT_4 (Section 7.4.6.1),
SaAmfProtectionGroupNotificationT_4 (Section 7.4.6.3), and
SaAmfProtectionGroupNotificationBufferT_4 (Section 7.4.6.4)
have been introduced.
As a consequence of the previous changes, superseding functions
SaAmfProtectionGroupTrack_4(),
SaAmfProtectionGroupTrackCallbackT_4, and
saAmfProtectionGroupNotificationFree_4(), which are described
in Section 7.11.1, Section 7.11.2, and Section 7.11.4, respectively, have also
been introduced.
•
The SaAmfCSISetCallbackT function (see Section 7.9.2) has been
extended, so that the component can return the new value
SA_AIS_ERR_NOT_READY in the error parameter when replying to the call-
back to indicate that the component cannot assume the HA state specified by
haState for the given component service instance.
•
The sentence “SA_AMF_TARGET_ALL is always set for components that sup-
port only the “x_active_or_y_standby” capability model” has been removed
from the description of the SaAmfCSIRemoveCallbackT function of the
B.03.01 version (this section is now Section 7.9.2).
•
The saAmfHAReadinessStateSet() function (see Section 7.9.5) has
been introduced to enable a component to set its HA readiness state for com-
ponent service instances.
AIS Specification SAI-AIS-AMF-B.04.01 Section 1.3.1 21
Service Availability
TM
Application Interface Specification
Document Introduction
1
5
10
15
20
25
30
35
40
•
Two minor changes have been made to the
saAmfProtectionGroupTrack_4() function (see Section 7.11.1) to track
changes of the HA readiness state.
•
The runtime attributes saAmfSISUHAReadinessState and
saAmfCSICompHAReadinessState have been added to the object classes
SaAmfSIAssignment (see FIGURE 34 in Section 8.11) and
SaAmfCSIAssignment (see FIGURE 35 in Section 8.12), respectively. The
definitions of these two object classes have been updated accordingly.
•
state of a service unit for an assigned service instance changes. Refer to the
new Section 11.2.2.5.
⇒
Active or standby assignments of service instances to service units hosted by an
AMF node impose a certain load on the AMF node in terms of resources like
memory or computing power. In certain cases, AMF nodes having limited capac-
ity for these resources can be overloaded due to these assignments. The Avail-
ability Management Framework specification has been extended to provide
configuration attributes to help the Availability Management Framework avoiding
to overload an AMF node with more service instance assignments that the AMF
node can handle. The main changes induced by this topic to the specification
are:
•
The description of the “ordered list of SIs” in Section 3.6.1.1 has been
changed to state that the rank of an SI is now global to the cluster.
•
Section 3.6.1.3 has been introduced; it contains the main changes and pro-
vides examples.
•
Section 3.6.1.4 has been introduced to provide some guidelines for a system
architect to configure re
the Availability Management Framework.
•
The saAmfNodeCapacity configuration attribute has been added to the
SaAmfNode object class (see FIGURE 30 in Section 8.7).
•
The configuration attributes saAmfSIActiveWeight and
saAmfSIStandbyWeight have been added to the SaAmfSI object class
(see FIGURE 34 in Section 8.11). Default values for the latter two attributes
have been defined by the saAmfSvcDefActiveWeight and
saAmfSvcDefStandbyWeight attributes in the SaAmfSvcType object
class, shown also in FIGURE 34.
22 SAI-AIS-AMF-B.04.01 Section 1.3.1 AIS Specification
Service Availability
TM
Application Interface Specification
Document Introduction
1
5
10
15
20
25
30
35
40
⇒
To support correlation Ids, the following main changes have been made:
•
An overview of the Availability Management Framework’s handling of correla-
tion ids is presented in the new Section 7.1.7 on page 239.
•
The SA_AMF_AI_RECOMMENDED_RECOVERY and
SA_AMF_AI_APPLIED_RECOVERY values have been added to the
SaAmfAdditionalInfoIdT enum (see Section 7.4.11.2 on page 262).
•
The correlationIds parameter has been added to the superseding func-
tions saAmfComponentErrorReport_4(),
saAmfComponentErrorClear_4(), and saAmfResponse_4(), which
are described in Section7.12.1onpage325, Section 7.12.2 on page 327,
and on Section 7.13.1 on page 333, respectively.
•
The saAmfCorrelationIdsGet() function has been defined (see
Section 7.12.3 on page 330).
•
New notifications have been specified. Refer to Section 11.2.3 on page 435.
⇒
To align the Availability Management Framework specification with the Platform
Management Service (abbreviated as PLM, see [5]), the following modifications
have been made:
•
The notion of physical node has been replaced by the notion of PLM execu-
tion environment. This replacement induced adaptations in the definition of
AMF node and AMF Cluster, see Section 3.1.1.1 on page 38 and
Section 3.1.1.2 on page 39, respectively. Additionally, the definitions of local
and external resources as well as the definitions of local and external compo-
nents have been adapted (see Section 3.1.2).
•
The description of the “node failfast” recovery action in Section 3.11.1.3.2 has
been adapted.
•
The interactions between the Availability Management Framework and the
Cluster Membership Service have been described in the new
Appendix D on page 445, which also contains references to PLM.
⇒
The SaAmfNotificationMinorIdT type (see Section7.4.11.1onpage261)
has been introduced to define the minorId field of notifications produced by the
Availability Management Framework. The descriptions of the notifications in
Section 11.2 refer to this type.
AIS Specification SAI-AIS-AMF-B.04.01 Section 1.3.2 23
Service Availability
TM
Application Interface Specification
Document Introduction
1
5
10
15
20
25
30
35
40
1.3.2 Clarifications
⇒
In Section 3.2.1.4, it is clarified that pre-instantiable service units may be instan-
tiated while they are out-of-service.
⇒
Section 3.2.2.2 adds one more case to the list of component failures detected by
the Availability Management Framework, namely when
saAmfProxiedComponentInstantiateCallback() or
saAmfContainedComponentInstantiateCallback() function returns
with an error.
⇒
Text has been added to Section 3.2.9 to clarify the interdependency between the
states of components and the states of their containing service unit.
⇒
The role of the ordered list of service units in assignments and instantiations has
been clarified (see Section 3.6.2.3.5).
⇒
The description of repair in the B.03.01 version of the Availability Management
Framework concentrated mainly on the SA_AMF_ADMIN_REPAIRED administra-
tive operation, and the usage of the saAmfComponentErrorClear() function
as a possible way to perform a repair action was not always mentioned. The
B.04.01 version of the specification extends the description of repair to appropri-
ately refer to the saAmfComponentErrorClear_4() function as follows:
•
References to the saAmfComponentErrorClear_4() function have been
added to Section 3.4.1 and to Section 3.11.1.4 (repair).
•
References to the extended Section 3.11.1.4 have been added to Section 4.6
(INSTANTIATE command) and Section 4.8 (CLEANUP command).
•
The description section of the saAmfComponentErrorClear_4() function
in Section 7.12.2 has been extended.
⇒
In Section 6.3, it is clarified that if a contained component fails, it is the task of
the container component to report an error on the failed component.
⇒
This version of the Availability Management Framework specification clarifies
that the registered process for a proxied component may differ from the regis-
tered process for the proxy component. This clarification affects Section 7.1.1,
Section 7.6.1, Section 7.10.2, and Section 7.10.3.
⇒
The interpretation of the SA_AMF_CSI_STILL_ACTIVE value in
Section 7.4.5.2 has been clarified.
⇒
In the description of the saAmfInitialize
_4
() function in
Section 7.5.1 on page 264, it is clarified that the handle amfHandle is finalized
when the Availability Management Framework detects the death of the invoking
process.
⇒
Section 9.4.2 up to Section 9.4.6 specify the administrative states that the logical
entities must have as a precondition to apply the corresponding administrative
operations.
24 SAI-AIS-AMF-B.04.01 Section 1.3.3 AIS Specification
Service Availability
TM
Application Interface Specification
Document Introduction
1
5
10
15
20
25
30
35
40
1.3.3 Deleted Topics
⇒
The saAmfComponentUnregister() function has been removed, as the
unregistration of a component is now implicitly done by the Availability Manage-
ment Framework. The term “unregistered process” has also been removed.
These deletions implied several changes to the document. In particular, it is
stated now that if a proxied component fails, it is the task of its proxy to report an
error on the failed component.
⇒
According to SA Forum directives, AIS Services and Frameworks shall only gen-
erate alarms for situations that require an explicit intervention by an external
agent or operator, provided that the corrective measures to be taken are well
defined. Based on these directives, it was decided to remove the "service
impaired” alarm from the Availability Management Framework B.04.01 version.
SA Forum does not mandate that Availability Management Framework imple-
mentations which also support the B.03.01 version must generate the "service
impaired” alarm for the B.03.01 version.
1.3.4 Other Changes
⇒
The definition of the term regular SA-aware component was changed to apply
only to those components that only have the SA_AWARE flag set, that is, a regu-
lar SA-aware component cannot be a proxy component. For this purpose, the
definition of this term in Section 3.1.2.1 was changed. Additionally, Table 3 and
Table 20 were adapted, and the term regular SA-aware component was used
accordingly in Chapter 10.
⇒
In Section 3.1.2.1.1, it is stated that a process of a contained component must
also belong to its associated container component.
⇒
The definition of instantiable service unit has been extended, and the description
of the reduction procedure has been clarified. See Section 3.6.1.1.
⇒
In Section 3.6.6.1 on the no-redundancy redundancy model, it is explained that
the Availability Management Framework can recover from faults by failing over
the active assignment to a spare service unit.
⇒
As the saAmfSGNumPrefAssignedSUs attribute is not defined for the no-
redundancy redundancy model, the sentence “Note that the preferred number of
assigned service units is equal to the number of configured SIs plus one spare
service unit." on the configuration of this redundancy model has been removed
(the corresponding section in this version is Section 3.6.6.3).
AIS Specification SAI-AIS-AMF-B.04.01 Section 1.3.4 25
Service Availability
TM
Application Interface Specification
Document Introduction
1
5
10
15
20
25
30
35
40
⇒
In Section 7.2.1, it is explained that when the Availability Management Frame-
work detects that a CLM node has unexpectedly left the cluster, the Availability
Management Framework abruptly terminates the components hosted by the
AMF node that is mapped to this CLM node. This modification led also to a
change in the explanation contained in Appendix A regarding when to invoke the
saAmfProxiedComponentCleanupCallback() callback or to execute the
CLEANUP command.
⇒
The one by one assignment of component service instances to a component and
the one by one removal of such assignments from a component with an
x_active_or_y_standby capability model are now allowed. Modifications have
Section 7.4.5.1
function in Section 7.9.3.
⇒
In Section 7.4.8, a typo in the name of the saAmfCompCategoryT type defini-
tion has been corrected, as it should be SaAmfCompCategoryT. Similar
changes were made for SaAmfRedundancyModelT in Section 7.4.9 and for
SaAmfCompCapabilityModelT in Section 7.4.10. Additonally, in
Section 7.4.9, the SA_AMF_N-WAY_REDUNDANCY-MODEL name has been cor-
rected to SA_AMF_N_WAY_REDUNDANCY_MODEL.
⇒
Also in Section 7.4.8, a value for
SA_AMF_COMP_PROXIED_NPI
was introduced as
a category value for proxied, non-pre-instantiable components. This addition
implied modifications in Table 20 in the same section. A clarification was also
included to explain the possible category values for pre-instantiable and non-
pre-instantiable components.
A further clarification regarding pre-instantiable and non-pre-instantiable compo-
nents has been added to Section 8.13.1 on the SaAmfCtCsType association
class.
⇒
The sentence “On return from the saAmfResponse() function, the Availability
Management Framework removes all service instances associated with the
component and the component terminates.” was removed from the description
of the SaAmfComponentTerminateCallbackT function (see Section 7.10.1
in this document), as this sentence is not always true.
⇒
Version B.03.01 of this specification stated in the description of the
SaAmfProxiedComponentInstantiateCallbackT callback function that
the invoked proxy component must have previously registered the proxied com-
ponent with the Availability Management Framework. This statement is not true;
the correct sequence of operations was already described in the example for
pre-instantiable components in Appendix C.
26 SAI-AIS-AMF-B.04.01 Section 1.3.4 AIS Specification
Service Availability
TM
Application Interface Specification
Document Introduction
1
5
10
15
20
25
30
35
40
The pertinent correction applies to the
SaAmfProxiedComponentInstantiateCallbackT function
(see Section 7.10.2) and to the SaAmfCSISetCallbackT function
(see Section 7.9.2
the invoked process must register a non-pre-instantiable proxied component
before it responds to this callback request.
In the process of making these changes, the descriptions of several functions
involving proxied or contained components have been extended to specify for
which errors and for which component (proxy or proxied, container or contained)
the recovery policy applies.
•
saAmfHealthcheckStart() (see Section 7.8.1).
•
SaAmfHealthcheckCallbackT (see Section 7.8.2).
•
saAmfHealthcheckConfirm() (see Section 7.8.3).
•
SaAmfCSISetCallbackT (see Section 7.9.2).
•
SaAmfCSIRemovedCallbackT (see Section 7.9.3).
•
SaAmfComponentTerminateCallbackT (see Section 7.10.1).
•
SaAmfProxiedComponentInstantiateCallbackT (see Section 7.10.2).
•
SaAmfProxiedComponentCleanupCallbackT (see Section 7.10.3).
•
SaAmfContainedComponentInstantiateCallbackT (see
Section 7.10.4).
•
SaAmfContainedComponentCleanupCallbackT (see Section 7.10.5).
This correction induced also the following modifications:
•
The descriptions of several functions called by a component have been
extended such that the sentences also apply when a proxy or container com-
ponent performs the particular actions on itself and on the proxied or con-
tained components, respectively. Similar changes were made also for
callback functions.
•
Textual modifications have also been made in the description of several func-
tions to use the text “the registered process” instead of “a registered process”,
as at most one registered process exists for a component.
•
The last paragraph in Section 4.8 on the CLEANUP command has been
extended to clarify that the explanation also applies to all contained compo-
nents if the affected component is a container component.
•
A paragraph in Section 5.2 has been extended to clarify the type of the
affected proxied component (pre-instantiable or non-pre-instantiable).
AIS Specification SAI-AIS-AMF-B.04.01 Section 1.3.4 27
Service Availability
TM
Application Interface Specification
Document Introduction
1
5
10
15
20
25
30
35
40
•
A paragraph in Section 5.3 clarifies that an already instantiated proxied com-
ponent need not be reinstantiated if the a new proxy takes over the task of
controlling the proxied component.
•
The description of the saAmfComponentRegister() function in
Section 7.6.1 specifies additional cases when this function is called.
•
Section 7.8.1 on the saAmfHealthcheckStart() function clarifies to which
component the invoking process must belong and when the Availability Man-
agement Framework automatically stops a healthcheck. Additionally, this sec-
tion clarifies the conditions to start a healthcheck for a proxied component.
•
Section 7.8.2 on the SaAmfHealthcheckCallbackT function clarifies that
this callback is called on the same process that started the healthcheck oper-
ation by invoking the saAmfHealthcheckStart() function.
•
Section 7.8.3 on the saAmfHealthcheckConfirm() function clarifies that
the invoking process must be the same process that started the healthcheck
operation by invoking the saAmfHealthcheckStart() function.
•
Section 7.9.4 on the saAmfCSIQuiescingComplete() function clarifies
that the component that was requested to quiesce was the component identi-
fied by the name referred to by the compName parameter in the corresponding
invocation of the saAmfCSISetCallback() callback function. If the error
parameter is set to SA_AIS_ERR_FAILED_OPERATION, the Availability Man-
agement Framework must engage the configured recovery policy for the com-
ponent referred to by the compName parameter in the corresponding
saAmfCSISetCallback() callback function.
⇒
The following typos have been corrected in Tab l e 21 on DN formats:
•
Object class SaAmfSGType: safSgType instead of SafSgType.
•
Object class SaAmfSU: safSg instead of safSG.
•
Object class SaAmfSutCompType: safSuType instead of SafSuType.
•
Object class SaAmfSUType: safSuType instead of SafSuType.
⇒
rected.
⇒
The configuration attributes saAmfAppType, saAmfSGType, saAmfSUType,
saAmfSvcType, saAmfCSType, and saAmfCompType, shown in the UML dia-
grams in Chapter 8, have been made writable.
28 SAI-AIS-AMF-B.04.01 Section 1.3.5 AIS Specification
Service Availability
TM
Application Interface Specification
Document Introduction
1
5
10
15
20
25
30
35
40
⇒
In FIGURE 28 in Section 8.5, to align with other similar associations like the one
between the SaAmfSUType and SaAmfCompType classes, the shared aggrega-
tions between the SaAmfAppType and SaAmfSGType classes and between the
SaAmfSGType and SaAmfSUType classes have been changed to associations
that are navigable only in one direction.
Additionally, the multiplicity between the SaAmfHealthcheck and
SaAmfHealthcheckType classes (at the latter end) has been changed to 1.
⇒
In the SaAmfComp class, which is described in Section8.13.2onpage360, the
following changes have been made:
•
to correct typos in the preceding version, the term 'Comp' has been dropped
from the default values of the following attributes, as they refer to the appro-
priate attributes of the SaAmfCompGlobalAttributes class, described in
Section8.14onpage362:
•
saAmfCompNumMaxInstantiateWithoutDelay,
•
saAmfCompNumMaxInstantiateWithDelay,
•
saAmfCompNumMaxAmStartAttempts, and
•
saAmfCompNumMaxAmStopAttempts;
•
to align the terminate operation with the cleanup and instantiate operations,
which have just one timeout attribute, regardless of whether the operation is
invoked by a CLC-CLI or by a callback call, the
saAmfCompTerminateCallbackTimeout attribute has been dropped. The
saAmfCompTerminateTimeout attribute applies now to both ways of invok-
ing the operation, and the name of its default value has been changed to
saAmfCtDefCallbackTimeout to reflect that components are typically ter-
minated by invoking the callback call. Note also that a typo in this latter name
(“TimeOut” instead of “Timeout”) has been corrected in the component type
class diagram in Section 8.13.1 on page 358.
⇒
In Section 9.3.1, a typo in the name of the saAmfAdminOperationIdT type
definition has been corrected, as it should be SaAmfAdminOperationIdT.
⇒
In Section 9.4.6 and Section 9.5
SA_AMF_ADMIN_SHUTDOWN and not SA_AMF_ADMIN_SHUT_DOWN.
⇒
The SaAmfProtectionGroupNotificationFree_4() function has been
included in Table 38 in Appendix B.
1.3.5 Superseded and Superseding Functions
The Availability Management Framework defines for the version B.04.01 new func-
tions and new type definitions to replace functions and type definitions of the version
B.03.01. The list of replaced functions and type definitions in alphabetic order is pre-
sented in Table 1.
AIS Specification SAI-AIS-AMF-B.04.01 Section 1.3.5 29
Service Availability
TM
Application Interface Specification
Document Introduction
1
5
10
15
20
25
30
35
40
The superseded functions and type definitions are no longer supported in version
B.04.01, and no description is provided for them in this document. The names of the
superseding functions and type definitions are obtained by adding “_4” to the respec-
tive names of the B.03.01 version or by replacing “_n” (where n is a number < =3) by
“_4” if the superseded functions or type definitions had already “_n” at the end of their
names. Regarding the support of backward compatibility in SA Forum AIS,
refer to [2].
Table 1 Superseded Functions and Type Definitions in Version B.04.01
Functions and Type Definitions of Version B.03.01 no
Longer Supported in B.04.01
SaAmfCallbacksT_3
saAmfComponentErrorClear()
saAmfComponentErrorReport()
saAmfComponentUnregister
1
()
1. As an exception, this function has not been superseded; instead, it has
been only removed, as the unregistration is implicitly done by the Avail-
ability Management Framework.
saAmfInitialize_3()
SaAmfProtectionGroupMemberT
SaAmfProtectionGroupNotificationBufferT
SaAmfProtectionGroupNotificationFree()
SaAmfProtectionGroupNotificationT
SaAmfProtectionGroupTrack()
SaAmfProtectionGroupTrackCallbackT
SaAmfResponse()
30 SAI-AIS-AMF-B.04.01 Section 1.3.6 AIS Specification
Service Availability
TM
Application Interface Specification
Document Introduction
1
5
10
15
20
25
30
35
40
1.3.6 Changes in Return Values of API and Administrative Functions
The following table applies only to functions that have not been superseded.
Table 2 Changes in Return Values of API and Administrative Functions
Function Return Value
Change
Type
All administrative operations described in Chapter 9 SA_AIS_ERR_TIMEOUT
SA_AIS_ERR_NO_MEMORY
new
SA_AMF_ADMIN_SI_SWAP
administrative operation SA_AIS_ERR_BAD_OPERATION extended
saAmfComponentRegister()
SA_AIS_ERR_INIT changed
SaAmfContainedComponentInstantiate
CallbackT
1
SA_AIS_ERR_TRY_AGAIN
SA_AIS_OK
extended
saAmfCSIQuiescingComplete()
SA_AIS_ERR_NOT_EXIST new
SaAmfCSISetCallbackT
1
1. Actually, this callback function does not return any value. The value shown in the second column is the value set
in the error parameter when the invoked process responds to the callback function by invoking the
saAmfResponse_4() function.
SA_AIS_ERR_NOT_READY new
saAmfHealthcheckStart()
SA_AIS_ERR_NOT_EXIST extended
saAmfPmStart_3()
2
2. This return value should have been added in the Availability Management Framework B.03.01 specification to this
function.
SA_AIS_ERR_VERSION new
SaAmfProxiedComponentInstantiate
CallbackT
1
SA_AIS_ERR_TRY_AGAIN extended
AIS Specification SAI-AIS-AMF-B.04.01 Section 1.4 31
Service Availability
TM
Application Interface Specification
Document Introduction
1
5
10
15
20
25
30
35
40
1.4 References
The following documents contain information that is relevant to specification:
[1] Service Availability
TM
Forum, Service Availability Interface, Overview,
SAI-Overview-B.05.01
[2] Service Availability
TM
Forum, Service Availability Interface, C Programming
Model, SAI-AIS-CPROG-B.05.01
[3] Service Availability
TM
Forum, Application Interface Specification, Notification
Service, SAI-AIS-NTF-A.03.01
[4] Service Availability
TM
Forum, Application Interface Specification, Cluster Mem-
bership Service, SAI-AIS-CLM-B.04.01
[5] Service Availability
TM
Forum, Application Interface Specification, Platform Man-
agement Service, SAI-AIS-PLM-A.01.01
[6] Service Availability
TM
Forum, Application Interface Specification, Information
Model Management Service, SAI-AIS-IMM-A.03.01
[7] Service Availability
TM
Forum, Information Model in XML Metadata Interchange
(XMI) v2.1 format, SAI-IM-XMI-A.04.01.xml.zip
[8] Service Availability
TM
Forum, Application Interface Specification, Software Man-
agement Service, SAI-AIS-SMF-A.01.01
[9] CCITT Recommendation X.731 | ISO/IEC 10164-2, State Management Function
[10] CCITT Recommendation X.733 | ISO/IEC 10164-4, Alarm Reporting Function
[11] IETF RFC 2253 (http://www.ietf.org/rfc/rfc2253.txt).
[12] IETF RFC 2045 (http://www.ietf.org/rfc/rfc2045.txt).
References to these documents are made by putting the number of the document in
brackets.
1.5 How to Provide Feedback on the Specification
If you have a question or comment about this specification, you may submit feedback
online by following the links provided for this purpose on the Service Availability™
Forum Web site (http://www.saforum.org).
You can also sign up to receive information updates on the Forum or the Specifica-
tion.
32 SAI-AIS-AMF-B.04.01 Section 1.6 AIS Specification
Service Availability
TM
Application Interface Specification
Document Introduction
1
5
10
15
20
25
30
35
40
1.6 How to Join the Service Availability™ Forum
The Promoter Members of the Forum require that all organizations wishing to partici-
pate in the Forum complete a membership application. Once completed, a represen-
tative of the Service Availability™ Forum will contact you to discuss your membership
in the Forum. The Service Availability™ Forum Membership Application can be com-
pleted online by following the pertinent links provided on the SA Forum Web site
(http://www.saforum.org).
You can also submit information requests online. Information requests are generally
responded to within three business days.
1.7 Additional Information
1.7.1 Member Companies
A list of the Service Availability™ Forum member companies can be viewed online by
using the links provided on the SA Forum Web site (http://www.saforum.org).
1.7.2 Press Materials
The Service Availability™ Forum has available a variety of downloadable resource
materials, including the Forum Press Kit, graphics, and press contact information.
Visit this area often for the latest press releases from the Service Availability™ Forum
and its member companies by following the pertinent links provided on the SA Forum
Web site (http://www.saforum.org).
AIS Specification SAI-AIS-AMF-B.04.01 Chapter 2 33
Service Availability
TM
Application Interface Specification
Overview
1
5
10
15
20
25
30
35
40
2 Overview
This specification defines the Availability Management Framework within the Applica-
tion Interface Specification (AIS).
2.1 Overview of the Availability Management Framework
The Availability Management Framework (sometimes also called the AM Framework
or simply the Framework) is the software entity that enables service availability by
coordinating other software entities within a cluster.
The Availability Management Framework provides a view of one logical cluster that
consists of a number of cluster nodes. These nodes host various resources in a dis-
tributed computing environment.
The Availability Management Framework provides a set of APIs to enable highly
available applications. In addition to component registration and life cycle manage-
ment, it includes functions for error reporting and health monitoring. The Availability
Management Framework also assigns active or standby workloads to the compo-
nents of an application as a function of component state and system configuration.
The Availability Management Framework configuration allows prioritization of
resources and provides for a variety of redundancy models. The Availability Manage-
ment Framework also provides APIs for components to track the assignment of work
or so-called component service instances among the set of components protecting
the same component service instance.
AIS Specification SAI-AIS-AMF-B.04.01 Chapter 3 35
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
3 System Description and System Model
This chapter presents the system description and the system model used by the SA
Forum Application Interface Specification (AIS) of the Availability Management
Framework (AMF).
An application that is managed by the Availability Management Framework to provide
high levels of service availability must be structured into logical entities according to
the model expected by the Framework. Furthermore, it must implement the state
models and callback interfaces that allow the Framework to drive workload manage-
ment, availability, and state management.
they are described:
•
Logical entities managed by the Availability Management Framework
(Section 3.1)
•
States and state models applicable to the relevant logical entities (Section 3.2
and Section 3.4)
•
Fail-over and switch-over of service instances (Section 3.3)
•
Component capability model (Section 3.5)
•
Redundancy models supported by the Availability Management Framework
(Section 3.6)
•
Interactions between the component capability model and the redundancy mod-
els (Section 3.7)
•
Dependencies among different entities (Section 3.8)
•
Approaches for integrating legacy software and hardware entities in the frame-
work (Section 3.9)
•
Component monitoring (Section 3.10)
•
Error detection, recovery, repair, and escalation policy (Section 3.11)
Note:
The description of the Availability Management Framework configuration pro-
vides the pertinent attribute names, the names of object classes containing
these attributes, and the sections containing the respective UML diagrams.
Additional details on type, multiplicity, and values of these attributes are given
in Chapter 8 and [7].
It is recommended to first read the entire Chapter 3 to fully understand the
Availability Management Framework configuration described in these refer-
ences.
Most entities of the Availability Management Specification have types, which
are used to facilitate the configuration and for software management pur-
36 SAI-AIS-AMF-B.04.01 Chapter 3 AIS Specification
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
poses. These types are shortly described in a subsection of the sections
describing the corresponding entities. Additional details are provided in
Chapter 8 and [7].
AIS Specification SAI-AIS-AMF-B.04.01 Section 3.1 37
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
3.1 Logical Entities
The Availability Management Framework uses an abstract system model to represent
the resources under its control. This abstract model consists of various logical enti-
ties that are depicted in the UML diagram shown in FIGURE 1.
FIGURE 1 Availability Management Framework Logical Entities and Their Relations
Proxy Component
ComponentService Instance
SA-aware Component
Non_SA-aware Component
Service Instance
Container Component
Contained Component
External Component
External Service UnitLocal Service Unit
Local Component
CLM Cluster
Component
AMF Node
AMF
Cluster
Service Group
Service Unit
CLM Node
Application
{incomplete, overlapping}
ProxiesExternal
0..*
1
Protects
0..*
0..1
0..* Assigned to 0..*
Assigned to0..* 0..*
0..*
1
Proxies
0..*
0..1
Hosted on
0..*
1
0..*
1
0..*
1
0..*
1
0..*
1
0..*
1
0..*
1
Maps on
1 0..1
Maps on
0..1 0..1
0..*1
Contains
0..*
1
0..*
1
38 SAI-AIS-AMF-B.04.01 Section 3.1.1 AIS Specification
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
Aggregation relationships in FIGURE 1 have multiplicities of '0..*' to account for situa-
temporarily empty.
Each logical entity of the system model is identified by a unique name.
All logical entities, their attributes, relationships, and mapping to the resources they
represent are typically preconfigured and stored in a configuration repository.
Dynamic modification of the system model is not precluded. The modeling and orga-
nization of this configuration information is described in Chapter 8. The access and
modification of this configuration reposito
interface of the IMM Service ([6]). It is assumed that the Availability Management
Framework obtains the cluster configuration from the configuration repository and is
notified of any changes.
The Availability Management Framework provides no API function to notify compo-
nents about changes in the configuration repository.
3.1.1 Cluster and Nodes
Note:
In the remainder of this document, the terms “CLM node”, “CLM cluster”, “AMF
node”, and “AMF cluster” will be used as synonyms to Cluster Membership
node and cluster and Availability Management Framework node and cluster,
respectively.
3.1.1.1 AMF Nodes
The AMF node is a logical entity that represents a complete inventory of all Availabil-
ity Management Framework entities on a CLM node (which is defined in [4]).
As shown in the UML diagram in Section 8.4, a CLM node can host at most one AMF
node, and a PLM E
xecution Environment (abbreviated as EE, see the Platform Man-
agement Service specification [5]) can host at most one CLM node. These one-to-
one relationships between an AMF node, its CLM node, and the CLM node’s PLM
execution environment are administratively configured.
The configuration of an AMF node is valid even if
(a) no CLM node is mapped to the AMF node, or
(b) a CLM node is mapped to the AMF node, but the mapped CLM node is not in
the cluster membership.
AIS Specification SAI-AIS-AMF-B.04.01 Section 3.1.1.2 39
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
However, in both cases (a) and (b), the AMF node cannot be used to provide service,
and none of the Availability Management Framework logical entities configured to be
hosted by the AMF node can be instantiated.
An AMF node is also a logical entity whose various states are managed by the Avail-
ability Management Framework. Availability Management Framework administrative
operations are defined for such nodes.
For a complete list of the attributes that are configured for an AMF node, refer to the
description of the SaAmfNode UML class in Section 8.7 on page 344.
As there is a one-to-one association between an AMF node, its CLM node, and the
PLM execution environment that hosts the CLM node, some notations have been
adopted to make this specification more readable:
•
Throughout the specification, when the word "node" is used without an explicit
qualification, it means "AMF node".
•
If "node” is used in the context of "joining the cluster", and "leaving the cluster", it
actually means "the hosting CLM node". For example, the sentence fragment
“when a node joins the cluster” should be interpreted as “when the CLM node
hosting the AMF node joins the cluster”.
•
The reference to “the PLM execution environment that hosts an AMF node” actu-
ally means “the PLM execution environment that hosts the CLM node hosting
the AMF node.
•
The term "node reboot" should be interpreted as "a restart administrative opera-
AMF node”.
3.1.1.2 AMF Cluster
The complete set of AMF nodes in the Availability Management Framework configu-
ration defines the AMF cluster. For the relationship between the entities AMF cluster
and CLM cluster, refer to the UML diagram in Section 8.4. Note that though the AMF
cluster and the CLM cluster (defined in [4]) have a close relationship, they are not
the same:
•
It is possible that some AMF nodes may be mapped to some CLM nodes by con-
figuration (see the saAmfNodeClmNode attribute of the SaAmfNode object
class, shown in Section 8.7), whereas other AMF nodes are not mapped to con-
figured CLM nodes, and thus do not provide service.
•
During the life-span of the cluster, modifications may be made to the mapping of
the AMF node to the CLM node.
40 SAI-AIS-AMF-B.04.01 Section 3.1.1.2 AIS Specification
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
•
There may be nodes in the CLM cluster that are not meant to run software con-
trolled by the Availability Management Framework. Thus, in a fully configured
system, the CLM cluster may contain more nodes than the AMF cluster; in this
case, the AMF cluster will be a proper subset of the CLM cluster.
The administrator is responsible for specifying the configuration for mapping AMF
nodes to CLM nodes.
The AMF cluster is one of the entities that are under the Availability Management
Framework’s control, and its administrative state is managed by the Availability Man-
agement Framework (see Section 3.2.8). The Availability Management Framework
defines certain administrative operations for the AMF cluster.
The Availability Management Framework knows the association of its nodes to the
hosting PLM execution environments and shall use this association to initiate opera-
tions such as restarting the hosting PLM execution environment during recovery
operations.
If a CLM node hosting an AMF node leaves the cluster membership, the CLM node is
cleaned by the Availability Management Framework in the sense that no process
belonging to AMF logical entities is left over on that node (see also Section 7.2.1 and
Appendix D). Only persistent Availability Management Framework information will be
available again when the node rejoins the cluster membership.
The Availability Management Framework can force a node to reboot while engaging
certain recovery and repair mechanisms. During the reboot, the node leaves the clus-
ter membership and rejoins it after successful initialization.
In contrast, the restart of an AMF node (see also Section 9.4.7) will only stop and
start entities under the Availability Management Framework’s control, without any
impact on the cluster membership. The restart of the AMF cluster (see also
Section 9.4.7) will restart all AMF nodes and will not affect the cluster membership.
On the other hand, a cluster reset (see Section 7.4.7) restarts all PLM execution
environments associated with all AMF nodes of the cluster, whereby the correspond-
ing PLM execution environments are first terminated befo
tiated again.
In the remainder of this specification, cluster start or startup is synonymous to the
start of Availability Management Framework. The cluster start creates and instanti-
ates the Availability Management Framework logical entities based on the Availability
Management Framework configuration.
AIS Specification SAI-AIS-AMF-B.04.01 Section 3.1.2 41
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
Applications to be made highly available are supposed to be configured in the Avail-
ability Management Framework configuration. Each application is configured to be
hosted in one or more AMF nodes within the AMF cluster.
As there is a one-to-one association between an AMF cluster and its CLM cluster,
some notations have been adopted to make the specification more readable:
•
Throughout the specification, when the word "cluster" is used without an explicit
qualification, it means "AMF cluster".
•
If "cluster” is used in the context of "joining the cluster", and "leaving the cluster",
it actually means "the associated CLM cluster". For example, the sentence frag-
ment “when a node joins the cluster” should be interpreted as “when the CLM
node associated with the AMF node joins the CLM cluster”.
3.1.2 Components
A component is the logical entity that represents a set of resources to the Availability
Management Framework. The resources represented by the component encapsulate
specific application functionality. This set of resources can include hardware
resources, software resources, or a combination of the two.
A component is the smallest logical entity on which the Availability Management
Framework performs error detection and isolation, recovery, and repair. When decid-
ing what is to be included in a component, the following two rules should be taken into
account:
•
The scope of a component must be small enough, so that a failure of the compo-
nent has as little impact as possible on the services provided by the cluster.
•
The component should include all functions that cannot be clearly separated for
error containment or isolation purposes.
The Availability Management Framework associates the following states to a compo-
nent: presence, operational, readiness, and HA. For more information on component
states, refer to Section 3.2.2.
Resources that are contained—from a fault containment perspective—within the
PLM execution environment hosting an AMF node are called local resources. This
means that if the PLM execution environment fails, all of its local resources become
inoperable. Local resources can be either software abstractions implemented by pro-
grams running within the PLM execution environment, or hardware equipment exclu-
sively associated with the PLM execution environment (such as I/O devices).
42 SAI-AIS-AMF-B.04.01 Section 3.1.2 AIS Specification
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
All other resources are called external resources. For example, an intelligent I/O
board in a blade chassis that is not dependent on a particular PLM execution environ-
ment to operate can be modeled as an external resource. A resource that is con-
tained within a PLM execution environment hosting no AMF node is also modeled as
node.
The Availability Management Framework was primarily designed to manage local
resources but it can also manage external resources. Unlike the case of local
resources, the Availability Management Framework has little direct control over exter-
nal resources. This difference justifies the distinction between two broad categories
of components:
•
Local component: a local component represents a subset of the local
resources contained within the PLM execution environment hosting the AMF
node.
•
External component: an external component represents a set of external
resources.
Section 3.1.2.1 up to Section 3.1.2.5 describe how the Availability Management
Framework manages local and external components. The information provided
includes:
•
the notion of component category to distinguish components with different
properties and different behavior. Two main categories of components are
defined: Service Availability (SA)-aware (see Section 3.1.2.1) and non-SA-aware
components (see Section 3.1.2.2);
•
the notion of container and contained SA-aware components
(see Section 3.1.2.1.1);
•
the concepts of SA-aware proxy and non-SA-aware proxied components (see
Section 3.1.2.3);
•
the description of the component life cycle (see Section 3.1.2.4);
•
the notion of component type (see Section 3.1.2.5).
AIS Specification SAI-AIS-AMF-B.04.01 Section 3.1.2.1 43
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
3.1.2.1 SA-Aware Components
High levels of service availability can only be attained if errors are detected and iso-
lated, a recovery is performed, and failed entities repaired efficiently. Faster error
recovery is possible if components have been
specific workload assignments and recovery policies. Such components must be so
designed that the Availability Management Framework can dynamically assign them
workloads and choose the role in which the component will operate for each specific
workload.
Only local components that are under the direct control of the Availability Manage-
ment Framework can have such a high level of integration with this framework. Such
components are termed SA-aware components.
Each SA-aware component includes at least one process that is linked to the Avail-
ability Management Framework library. One of these processes registers the compo-
nent with the Availability Management Framework by invoking the
saAmfComponentRegister() API function. This process, called the registered
process for the component (for its definition, see Section 7.1.1) provides to the Avail-
ability Management Framework references to the availability control functions it
implements. These control functions are implemented as callbacks.
Throughout the life of the component, the Availability Management Framework uses
these control functions to direct the component execution by, for example:
•
assigning workloads to the component,
•
removing workloads from the component,
•
and assigning the HA state to the component for each workload.
The registered process for a component executes the availability management
requests it receives from these control functions and conveys such requests to other
processes and to the hardware equipment of the local component, where necessary.
The registered process for a component may also provide the Availability Manage-
ment Framework with feedback on its readiness to take an assignment for a particu-
lar workload.
Most control functions of the component can only be provided by the registered pro-
cess; however, some control functions, such as healthcheck control functions, can be
provided by any process of the component. The description of each API function pre-
sented in Chapter 7 explicitly mentions when the function is restricted to a registered
44 SAI-AIS-AMF-B.04.01 Section 3.1.2.1.1 AIS Specification
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
process for a component. Additionally, Appendix B contains a table showing which
API or callback is restricted to registered processes for a component.
An SA-aware component has the following properties:
•
its life cycle is directly controlled by the Availability Management Framework;
•
each of its processes must exclusively belong to the component.
Note that container and contained components (which are discussed in
Section 3.1.2.1.1) do not share all of the preceding properties.
When the context does not make the distinction apparent, the term regular SA-aware
component is used to refer to an SA-aware component that is not contained in
another component and does not implement any management function for assisting
the Availability Management Framework in handling other components (such as
proxy, container).
Legacy software, which runs on a node, and which was not initially designed as an
SA-aware component can be converted to be SA-aware by adding a new process.
This process acts as the registered process for the component, receives all manage-
ment requests from the Availability Management Framework and converts them into
specific actions on the legacy software using existing administration interfaces spe-
cific to the legacy software.
3.1.2.1.1 Container and Contained Components
This section describes the particular properties of container and contained compo-
nents. As other features of container and contained components are described in
other sections of this and other chapters, Chapter 6 summarizes the corresponding
information and also provides additional information.
Purpose
The concept of container and contained components allows the Availability Man-
agement Framework to integrate components that are not executed directly by the
operating system, but rather in a controlled environment running on top of the operat-
ing system. Widespread environments are runtime environments, virtual machines,
or component frameworks.
AIS Specification SAI-AIS-AMF-B.04.01 Section 3.1.2.1.1 45
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
Properties of Container Components
•
The main task of the container component is to cooperate with the Availability
Management Framework to handle the life cycle of contained components. The
following definitions are used in this explanation and throughout this document:
⇒
The container component that handles the life cycle of a contained compo-
nent in cooperation with the Availability Management Framework is termed
the associated container component to the contained component.
⇒
Conversely, a contained component whose life cycle is handled by a con-
tainer component in cooperation with the Availability Management Framework
is termed an associated contained component to the container component.
⇒
For ease of expression when referring to a contained component, the term
collocated contained component is used to refer to a contained component
that has the same associated container component.
Which actions are performed by the associated container component and by the
Availability Management Framework for handling the life cycle of a contained
component is explained in detail in Section 6.2.
The interactions between contained components and the associated container
to implement the life cycle of the contained components are not defined by the
Availability Management Framework specification.
•
A single container component can be the associated container component of
various contained components.
•
A container component and all its associated contained components must reside
on the same AMF node.
•
The life cycle of a container component is directly controlled by the Availability
Management Framework.
•
The termination of a container component (for instance, in case of a failure of the
component) implies the termination of all associated contained components (see
also Section 6.3). In this sense, a container component “contains” the associ-
ated contained component.
•
A process belonging to a container component can also belong to its associated
contained components.
46 SAI-AIS-AMF-B.04.01 Section 3.1.2.2 AIS Specification
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
Properties of Contained Components
•
ment Framework in cooperation with the associated container component (see
also Section 6.2).
•
The termination of a contained component does not imply the termination of
either the associated container component or of the collocated contained com-
ponents (see also Section 6.3).
•
A process belonging to a contained component belongs also to its associated
container component and may also belong to some of its collocated contained
components.
3.1.2.2 Non-SA-Aware Components
Components that do not register directly with the Availability Management Frame-
work are called non-SA-aware components. However, such components may have
processes linked with the Availability Management Framework Library.
Typically, non-SA-aware components are registered with the Availability Manage-
ment Framework by dedicated SA-aware components that act as proxies between
the Availability Management Framework and the non-SA-aware components. These
dedicated SA-aware components are called proxy components. The components
for which a proxy component mediates are called proxied components. Proxy and
proxied components are explained in more detail in Section 3.1.2.3.
3.1.2.2.1 External Components
To keep maximum flexibility in the way external resources interact with nodes, which
is often device-dependent or proprietary, the Availability Management Framework
does not interact directly with external components and manages external compo-
nents always as proxied components.
3.1.2.2.2 Non-Proxied, Non-SA-Aware Components
The Availability Management Framework supports both proxied and non-proxied,
non-SA-aware local components. For non-proxied, non-SA-aware local components,
the role of the Availability Management Framework is limited to the management of
the component life cycle. The Availability Management Framework instantiates a
non-proxied, non-SA-aware component when the component needs to provide a ser-
vice and terminates this component when the component must stop providing the
service. Processes of a local non-SA-Aware component must exclusively belong to
that component.
AIS Specification SAI-AIS-AMF-B.04.01 Section 3.1.2.2.3 47
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
3.1.2.2.3 Integration and Usage of Non-SA-Aware Local Components
Application developers are encouraged to design applications that will run on nodes
as a set of SA-aware components registered directly with the Availability Manage-
ment Framework; however, non-SA-aware local components may be used instead for
the following reasons:
•
Some system resources such as networking resources or storage resources are
implemented by the operating environment, and their activation or deactivation is
usually performed by running administrative command line interfaces. No actual
process is needed to implement these resources, and requiring the implementa-
•
For components representing only local hardware resources, making these com-
ponents SA-aware components with a registering process adds unnecessary
complexity.
•
Existing clustering products support looser execution models than the execution
model of SA-aware components. For these products, the integration between
the applications and the clustering middleware is minimal: the clustering middle-
ware is only responsible for starting, stopping, and monitoring applications, but
does not expose APIs for finer-grained control of the application in terms of
workload and availability management.
It is important to facilitate the migration of third party products from these existing
clustering products to products providing the Availability Management Frame-
work interfaces without requiring the transformation of these third party products
into SA-aware components.
•
Some complex applications such as databases or application servers already
provide their own availability management for their various building blocks.
When moving these applications under the Availability Management Frame-
work’s control, different functions can be modeled as separate components;
however, some controlling entity within
between the Availability Management Framework and the individual compo-
nents. The concept of the proxy component can be used in this case as an inter-
position layer between the Availability Management Framework and all other
components of the application.
48 SAI-AIS-AMF-B.04.01 Section 3.1.2.3 AIS Specification
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
3.1.2.3 Proxy and Proxied Components
The Availability Management Framework uses the availability control functions regis-
tered by a proxy component to control the proxy component and the proxied compo-
nents for which the proxy component mediates.
The proxy component is an SA-aware component that is responsible for conveying
requests made by the Availability Management Framework to its proxied compo-
nents. A contained component must not be a proxy component.
The interactions between proxied components and their proxy component are private
and not defined by this specification.
The Availability Management Framework determines the proxied components for
which a proxy component is responsible when the proxy component registers with the
framework, based on configuration and other factors like availability of components in
the cluster. The Availability Management Framework conveys this decision to the
proxy component by assigning it a workload in the form of a component service
instance (for the definition of component service instance, see Section 3.1.3).
ment Framework; however, the proxied components are independent components as
far as the Availability Management Framework is concerned. As such, if a proxy com-
ponent fails, or an entity containing it is prevented by the administrator from providing
service, another component (usually the component acting as standby to the failed
proxy component) can register the proxied component again. This new proxy compo-
nent assumes then the mediation for the failed component without affecting the ser-
vice provided by the proxied component. If no proxy component is available to take
over the mediation service for the proxied component, the Availability Management
Framework loses control of the proxied component and becomes unaware of whether
the proxied component is providing service.
As various other features of proxy and proxied components are described in various
sections of this and other chapters, Chapter 5 summarizes the information on all
these features and also provides additional information. However, for convenience of
the reader, the following notes list some key features:
•
A single proxy component can mediate between the Availability Management
Framework and multiple proxied components.
•
the proxy component can be different from that of its proxied components.
AIS Specification SAI-AIS-AMF-B.04.01 Section 3.1.2.4 49
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
•
The Availability Management Framework does not consider the failure of the
proxied component to be the failure of the proxy component. Similarly, the failure
of the proxy component does not indicate a failure of the proxied components
(see Section 5.3).
•
No process of a proxied component registers with the Availability Management
Framework. A proxied component is registered by a process of the proxy com-
ponent ’proxying’ this proxied component.
•
The process of the proxy component registered for a proxied component medi-
ates all the interactions between the Availability Management Framework and
the proxied component it is registered for.
•
One process of a proxy component registers the proxy component itself. The
same or another process of the proxy component may register a proxied compo-
nent whenever the proxy component is ’proxying’ this proxied component.
3.1.2.4 Component Life Cycle
The Availability Management Framework directly controls the life cycle of non-prox-
ied, local components through a set of command line interfaces that must be pro-
vided by each component.
The Availability Management Framework indirectly controls the life cycle of proxied
components through their proxies. However, command line interfaces may also be
cycle of local proxied components.
For information about command line interfaces for the local component life cycle
management, refer to Chapter 4.
The Availability Management Framework distinguishes between two categories of
components in its life cycle management:
•
pre-instantiable components: such components have the ability to stay idle
when they get instantiated by the Availability Management Framework. They
start to provide a particular service only when instructed to do so (directly or indi-
rectly) by the Availability Management Framework. The Availability Management
Framework can speed up recovery and repair actions by keeping a certain num-
ber of pre-instantiated components, which can then take over faster the work of
failed components. All SA-aware components are pre-instantiable components.
•
non-pre-instantiable components: such components provide service as soon
as they are instantiated. Hence, the Availability Management Framework cannot
instantiate them in advance as spare entities. All non-proxied, non-SA-aware
components are non-pre-instantiable components.
50 SAI-AIS-AMF-B.04.01 Section 3.1.2.5 AIS Specification
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
The following table shows the various component categories and subcategories.
3.1.2.5 Component Type
The Availability Management Framework supports the notion of a component type.
A component type represents a particular version of the software or hardware imple-
mentation which is used to construct components. All component
share the attribute values defined in the component type configuration. Some of the
attribute values may be overridden, and some of them may be extended in the com-
ponent configuration.
Details on the configuration of a component type and of a component are provided in
Section 8.13 on page 358 and in [7].
3.1.3 Component Service Instance
A component service instance (CSI) represents the workload that the Availability
Management Framework can dynamically assign to a component. High availability
(HA) states are assigned to a component on behalf of its component service
instances. The Availability Management Framework chooses the HA state of a com-
ponent for each particular component service instance, as described in
Section 3.2.2.4. To help AMF to make this choice more comprehensive, some com-
ponents may provide information on their readiness to assume a particular compo-
nent service instance (see Section 3.2.2.5).
Table 3 Component Categories
Locality HA Awareness Proxy Property Life Cycle Management
local regular SA-aware non-proxy pre-instantiable
local (SA-aware) proxy proxy pre-instantiable
local (SA-aware) container proxy or non-proxy pre-instantiable
local (SA-aware) contained non-proxy pre-instantiable
local non-SA-aware non-proxied non-pre-instantiable
local non-SA-aware proxied pre-instantiable or
non-pre-instantiable
external non-SA-aware proxied pre-instantiable or
non-pre-instantiable
AIS Specification SAI-AIS-AMF-B.04.01 Section 3.1.3 51
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
Each component service instance has a set of attributes (name/value pairs), which
characterize the workload assigned to the component. Several attributes with the
same name may appear in the set of attributes of a component service instance, thus
providing support for multivalued attributes. These attributes are not used by the
Availability Management Framework and are just passed to the components.
The Availability Management Framework supports the notion of proxy CSI. A proxy
CSI represents the special workload of ’proxying’ a proxied component.
A proxied component must be configured with the proxy CSI that provides ’proxying’.
The Availability Management Framework configuration specifies to which proxy com-
ponents this proxy CSI can be assigned.
Note that a proxy component can be configured to have multiple CSI assignments,
one or more for handling proxied components and others for providing other services.
In terms of functionality, there is no difference between a proxy CSI corresponding to
the workload of ’proxying’ proxied components and CSI assignments corresponding
to the workload of other services.
The Availability Management Framework supports the notion of container CSI. A
container CSI represents the special workload of managing the life cycle of contained
components.
A contained component must be configured with the container CSI. The Availability
Management Framework determines, based on its configuration, the container com-
ponents to which this container CSI is assigned. Which of these container compo-
The container CSI can contain information to be passed by the associated container
component to the corresponding contained component. How this information is
passed is a private interface between container and contained components.
Note that a container component can be configured to have multiple CSI assign-
ments, one or more
for handling contained components, and others for providing
other services. In terms of functionality and syntax, there is no difference between a
container CSI used to determine the associated container component and other CSIs
corresponding to the workload of other services.
52 SAI-AIS-AMF-B.04.01 Section 3.1.3.1 AIS Specification
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
3.1.3.1 Component Service Type
The Availability Management Framework supports the notion of component service
type.
The component service type is the generalization of similar component service
instances (that is, similar workloads) that are seen by the Availability Management
Framework as equivalent and handled in the same manner. The configuration of a
component indicates which component service types the component supports. These
component service types must be chosen from the set of component service types
supported by the component type to which the component belongs.
The component service type defines the list of the attribute names for all component
service instances belonging to the type.
Details on the configuration of a component service type and of a component service
instance are provided in Section 8.12 on page 356 and in [7].
3.1.4 Service Unit
A service unit (SU) is a logical entity that aggregates a set of components combining
their individual functionalities to provide a higher level service. Aggregating compo-
nents into a logical entity managed by the Availability Management Framework as a
single unit provides system administrators with a simplified, coarser-grained view.
Most administrative operations apply to service units as opposed to individual compo-
nents.
A service unit can contain any number of components, but a particular component
can be configured in only one service unit. The components that constitute a service
unit can be developed in isolation, and a component developer might be unaware of
which components constitute a service unit. The service units are defined at deploy-
ment time.
As a component is always en
ment Framework's perspective, the service unit is the unit of redundancy in the sense
that it is the smallest logical entity that can be instantiated in a redundant manner
The Availability Management Framework associates presence, administrative, opera-
tional, readiness, and HA states to service units (latter on behalf of service
instances). Each of these states, with the exception of the administrative state, repre-
sents an aggregated view of the corresponding state of each component within the
service unit. The rules applied to obtain these aggregated states are specific to each
state and are described in Section 3.2.
AIS Specification SAI-AIS-AMF-B.04.01 Section 3.1.4.1 53
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
Local components and external components cannot be mixed within a service unit.
The Availability Management Framework distinguishes between local service units
and external service units. Local service units can contain only local components
(they are collocated on the same node). External service units can contain only exter-
nal components. The external components represent resources that are external to
the cluster.
A proxy component and its non-pre-instantiable proxied component can reside in the
same or in different service units; however, a proxy component and its pre-instantia-
ble proxied component must not reside in the same service unit in order to prevent
cyclic dependencies during the instantiation of the service unit. If the proxy and prox-
reside on different nodes.
In a service unit, contained components must not be mixed with components of other
categories. The rationale for this decision is explained in Section 6.1.5.
All contained components in a service unit must have the same associated container
component, and this association is achieved by the usage of a single container CSI
(see also Section 6.2).
A service unit that contains at least one pre-instantiable component is called a pre-
instantiable service unit; otherwise, it is called a non-pre-instantiable service
unit.
3.1.4.1 Service Unit Type
The Availability Management Framework supports the notion of a service unit type.
The service unit type defines a list of component types and, for each component type,
the number of components that a service unit of this type may accommodate. A ser-
vice unit of a given type may only consist of components of the component types from
that list, and the number of these components must be within the range specified for
the component type. All service units of the same type share the attribute values
defined in the service unit type configuration. Some of the attribute values may be
overridden in the service unit configuration.
All service units of the same type can be assigned service instances derived from the
same set of service types.
Details on the configuration of a service unit type and of a service unit are provided in
Section 8.10 on page 350 and in [7].
54 SAI-AIS-AMF-B.04.01 Section 3.1.5 AIS Specification
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
3.1.5 Service Instances
In the same way as components are aggregated into service units, the Availability
Management Framework supports the aggregation of component service instances
into a logical entity called a service instance (SI). A service instance aggregates all
component service instances to be assigned to the individual components of the ser-
vice unit in order for the service unit to provide a particular service.
A service instance can contain multiple component service instances, but a particular
component service instance can be configured in only one service instance.
A service instance represents a single workload assigned to the entire service unit.
When a service unit is available to provide service (in-service readiness state, see
Section 3.2.1.4), the Availability Management Framework can assign HA states to the
service unit for one or more service instances. When a service unit becomes unavail-
able to provide service (out-of-service readiness state), the Availability Management
Framework removes all service instances from the service unit. A service unit might
be available to provide service but not have any assigned service instance.
The Availability Management Framework assigns a service instance to a service unit
programmatically by assigning each individual component service instance of the ser-
vice instance to a specific component within the service unit.
The assignment of the component service instances of a service instance to the com-
ponents of a service unit takes into account the type of component service instance
supported by each component. A component service instance can be assigned to a
given component only if the component configuration indicates that the component
supports this particular type of component service instance, the component configu-
ration permits the assignment of at least one more component service instance of this
type, and the component is ready to assume (it did not indicate otherwise) the work-
load associated with the component service instance. When a service instance con-
not dictate how, within the service unit, the Availability Management Framework
assigns them to the components that support this particular type. This choice is
implementation-defined.
The number of component service instances aggregated into a service instance may
differ from the number of components aggregated into the service unit to which the
service instance is assigned. Some components may be left without any component
service instance assignment whereas other components may have several compo-
nent service instances assigned to them.
AIS Specification SAI-AIS-AMF-B.04.01 Section 3.1.5.1 55
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
3.1.5.1 Service Type
The Availability Management Framework supports the notion of a service type.
The service type defines a list of component service types of which a service instance
may be composed. The service type also defines for each component service type
the number of component service instances that a service instance of the given type
may aggregate. All service instances of the same type share the attribute values
defined in the service type configuration.
Details on the configuration of a service type and of a service instance are provided in
Section8.11onpage353 and in [7].
3.1.6 Service Groups
To ensure service availability in case of component failures, the Availability Manage-
ment Framework manages redundant service units.
A service group (SG) is a logical entity that groups one or more service units in order
to provide service availability for a particular set of service instances. Any service unit
of the service group must be able to take an assignment for any service instance of
this set. Furthermore, to participate in a service group, all components in the service
unit must support the capabilities required for the redundancy model defined for the
service group.
The redundancy model defines how the service units in the service group are used to
provide service availability. For details about service group redundancy models, refer
to Section 3.6.
Note:
For readability purposes, and if the context permits, this document uses
expressions like “the components of a service group“ to mean “the compo-
nents of service units participating in the service group”.
3.1.6.1 Service Group Type
The Availability Management Framework supports the notion of a service group
type.
The service group type is a generalization of similar service groups that follow the
same redundancy model, provide similar availability, and are composed of units of
the same service unit types. All service unit types defi
must be capable of supporting a common set of service types. All service groups of
the same type share the attribute values defined in the service group type configura-
tion. Some of the attribute values may be overridden in the service group configura-
tion.
Details on the configuration of a service group type and of a service group are pro-
vided in Section 8.9 on page 348 and in [7].
56 SAI-AIS-AMF-B.04.01 Section 3.1.7 AIS Specification
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
3.1.7 Application
An application is a logical entity that contains one or more service groups. An appli-
cation combines the individual functionalities of the constituent service groups to pro-
vide a higher level service.
This aggregation provides the Availability Management Framework with a further
scope for fault isolation and fault recovery.
From a software administration point of view, this grouping into application reflects
the set of service units and their components, which are delivered as a consistent set
of software packages, which results in tighter dependency with respect to their
upgrade.
An application can contain any number of service groups, but a given service group
can be configured in only one application.
Dependencies amongst service instances (described in Section 3.8.1 on page 185)
are more common amongst service instances belonging to the application than
amongst service instances of different applications.
3.1.7.1 Application Type
The Availability Management Framework supports the notion of an application type.
An application type defines a list of service group types, which implies that an appli-
cation of the given type must be composed of service groups of types from that list.
All applications of the same type share the attribute values defined in the application
type configuration.
Details on the configuration of an application type and of an application are provided
in Section 8.8 on page 346 and in [7].
3.1.8 Protection Groups
A protection group for a specific component service instance is the group of compo-
nents to which the component service instance has been assigned. The name of a
protection group is the name of the component service instance that it protects.
A protection group is a dynamic entity, which changes when component service
instances are assigned to components or removed from components.
AIS Specification SAI-AIS-AMF-B.04.01 Section 3.1.9 57
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
3.1.9 Mapping of Service Units to Nodes
Service groups and service units have an optional node group configuration
attribute. A node group just contains a list of nodes.
Service units have an optional configuration attribute
(saAmfSUHostNodeOrNodeGroup in the SaAmfSU object class, shown in
Section 8.10), which can either represent a node or a node group. The service unit
can only be instantiated on the node (if a node is specified) or on one of the nodes of
the node group (if a node group is configured).
The Availability Management Framework maps each service unit onto a node at the
time the service unit is introduced to the cluster (that is, at cluster startup or when the
service unit is added to the configuration), and this mapping persists until the service
unit is removed from the configuration, or the cluster is restarted. In other words, the
When the Availability Management Framework decides to instantiate a local service
unit in accordance with the pertinent redundancy model, it performs the following
checks:
1.
If a node is configured for the service unit, the service unit will be instantiated on
this node.
2.
If instead a node group is configured for the service unit, the Availability Manage-
ment Framework selects a node from the node group using an implementation-
specific policy to instantiate the service unit on this node.
3.
If no node or node group is configured for the service unit, the Availability Man-
agement Framework checks whether a node group is configured for the service
group (saAmfSGSuHostNodeGroup attribute in the SaAmfSG object class,
shown in Section 8.9).
4.
If a node group is configured for the service group, the Availability Management
Framework selects a node from the node group using an implementation-specific
policy to instantiate the service unit on this node.
5.
If no node group is configured for the service group, the Availability Management
Framework selects any node using an implementation-specific policy to instanti-
If node groups are configured for both the service units of a service group and the
service group, the nodes contained in the node group for the service unit can only be
a subset of the nodes contained in the node group for the service group. If a node is
configured for a service unit, it must be a member of the node group for the service
group, if configured.
58 SAI-AIS-AMF-B.04.01 Section 3.1.10 AIS Specification
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
It is an error to define the saAmfSUHostNodeOrNodeGroup attribute for an external
service unit. It is also an error to define the saAmfSGSuHostNodeGroup attribute if a
service group contains only external service units.
Section 6.1.5 provides additional rules on the configuration of node and node groups
for service units containing contained components and for the service groups contain-
ing these service units, so that this configuration aligns with the configuration of
nodes and node groups for service units containing container components and for the
service groups containing these service units.
3.1.10 Service Unit Instantiation
When the Availability Management Framework instantiates a pre-instantiable service
unit, it:
•
runs the INSTANTIATE command (see Section 4.6) for SA-aware components
(excluding contained components),
•
invokes the saAmfContainedComponentInstantiateCallback() call-
back (see Section 7.10.4
tained component of the service unit,
•
invokes the saAmfProxiedComponentInstantiateCallback() callback
(see Section 7.10.2) of the proxies of all pre-instantiable proxied components of
the service unit,
•
and performs no action for non-pre-instantiable components. Such components
are instantiated during the assignment of service instances to the service unit
(see Section 3.2.2.4 on page 77).
When the Availability Management Framework instantiates a non-pre-instantiable
service unit, it:
•
invokes the saAmfCSISetCallback() callback (see Section 7.9.2) of the
proxies of all proxied components of the service unit and
•
runs the INSTANTIATE command (see Section 4.6) for all non-proxied compo-
nents.
Note that this processing creates an implicit inter-service unit dependency, as the
Availability Management Framework needs to instantiate the service units containing
proxy components (and sometimes even assign them an active HA state for a service
instance) before the instantiation of service units containing proxied components can
be successfully completed.
AIS Specification SAI-AIS-AMF-B.04.01 Section 3.1.11 59
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
3.1.11 Illustration of Logical Entities
The example in FIGURE 2 shows two service groups, SG1 and SG2. SG1 supports a
single service instance (A) and SG2 supports two service instances (B and C).
On behalf of service instance A, service unit S1 is assigned the active HA state and
service unit S2 the standby HA state.
Each of the service units S1 and S2 contains two components. The component ser-
vice instance A1 is assigned to the components C1 and C3, and the component ser-
vice instance A2 is assigned to the components C2 and C4. Two protection groups
A1 and A2 are created, with protection group A1 containing components C1 and C3
the protection group
Thus, protection group A1
instance A1.
On behalf of service instance B, service unit S3 is assigned the active HA state and
service unit S5 the standby HA state. Similarly, on behalf of service instance C, ser-
vice unit S4 is assigned the active HA state and service unit S5 the standby HA state.
Each of these service units contains a single component (C5, C6, C7). Thus, while
components C5 and C6 are assigned the active HA state for only single component
service instances (B1 and C1, respectively), component C7 is assigned the standby
HA state for two component service inst
(B1 and C1) are created, with protection group B1 containing components C5 and C7
and protection group C1 containing components C6 and C7.
60 SAI-AIS-AMF-B.04.01 Section 3.1.11 AIS Specification
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
FIGURE 2 Elements of the System Model
Node W
Service Unit S3
C5
Node U
Service Unit S1
C1
C2
Node V
Service Unit S2
C3
C4
Node X
CSI A1
CSI A2
Service
Instance A
CSI B1
Service
Instance B
CSI C1
Service
Instance C
PG A1
PG A2
PG B1
PG C1
active
active
active
standby
standby
standby
Service Group SG1
Service Unit S4
C6
Service Unit S5
C7
Service Group SG2
AIS Specification SAI-AIS-AMF-B.04.01 Section 3.2 61
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
3.2 State Models
The following sections describe the different states associated with service units,
components, service instances, component service instances, service groups, appli-
cations, and nodes. The Availability Management Framework API provides state
management only for components and component service instances by using a sub-
set of the states described in the following subsections. The other states included in
the state model are relevant for System Management as well as for a clear definition
and extension of this specification.
3.2.1 Service Unit States
In some cases when describing the properties and states of service units, references
are made to properties and states of a node or cluster containing it. For readability
reasons, it is not always mentioned that these references, obviously, only apply to
local service units and are to be ignored for external service units.
3.2.1.1 Presence State
The presence state is supported at the service unit and component levels and
reflects the component life cycle. It takes one of the following values:
•
uninstantiated
•
instantiating
•
instantiated
•
terminating
•
restarting
•
instantiation-failed
•
termination-failed
Note that the presence state of a service unit is described in this section in terms of
the presence state of its constituent components, which is explained in detail in
Section 3.2.2.1.
62 SAI-AIS-AMF-B.04.01 Section 3.2.1.1 AIS Specification
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
When all components are uninstantiated, the service unit is uninstantiated. When
the first component moves to instantiating, the service unit also becomes instantiat-
ing.
When all pre-instantiable components of a service unit enter the instantiated state,
the service unit becomes instantiated.
A non-pre-instantiable service unit is instantiated if it has successfully been assigned
the active HA state on behalf of a service instance (see Section 3.2.1.5). Note that a
non-pre-instantiable service unit may be assigned one and only one service instance.
If, after all possible retries, a component cannot be instantiated, the presence state of
the component is set to instantiation-failed, and the presence state of the service unit
is also set to instantiation-failed. If some components are already instantiated when
the service unit enters the instantiation-failed state, the Availability Management
Framework terminates them. These components will enter either the uninstantiated
state if they are successfully terminated or the termination-failed state if the Availabil-
ity Management Framework was unable to terminate them correctly (refer also to
Section 4.7 and Section 4.8).
When the first component of an already instantiated service unit becomes terminat-
ing, the service unit becomes terminating. If the Availability Management Frame-
work fails to terminate a component, the presence state of the component is set to
termination-failed and the presence state of the service unit is also set to termina-
tion-failed.
When all components enter the restarting state, the service unit become restarting.
However, if only some components are restarting, the service unit is still instantiated.
The management of the presence state of a pre-instantiable service unit is very simi-
lar to what was previously described for a non-pre-instantiable service unit, except
that a pre-instantiable service unit becomes instantiated or terminating based only on
the presence state of its pre-instantiable components; when all pre-instantiable com-
ponents within a pre-instantiable service unit are instantiated, the service unit
becomes instantiated. If any errors occur when instantiating any of the constituent
components of the service unit, the presence state of the service unit becomes
instantiation-failed. Similarly,
components of the service unit, its presence state becomes termination-failed.
AIS Specification SAI-AIS-AMF-B.04.01 Section 3.2.1.2 63
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
3.2.1.2 Administrative State
The administrative state of a service unit is an extension of the administrative state
proposed by the ITU X.731 state management model ([9]). The administrative state of
a service unit can be set by the system administrator.
The administrative state of a service unit as well as the administrative states of the
service group (see Section 3.2.5), the node (see Section 3.2.6.1), the application
containing it (see Section 3.2.7), and the cluster (see Section 3.2.8) enable the Avail-
ability Management Framework to determine whether the service unit is administra-
tively allowed to provide service.
Valid values for the administrative state of a service unit are:
•
unlocked: the service unit has not been directly prohibited from taking service
instance assignments by the administrator.
•
locked: the administrator has prevented the service unit from taking service
instance assignments.
•
locked-instantiation: the administrator has prevented the service unit from
being instantiated by the Availability Management Framework; the service unit is
then not instantiable.
•
shutting-down: the administrator has prevented the service unit from taking
new service instance assignments and requested that existing service instance
assignments be gracefully removed. When all service instances assigned to the
service unit have finally been removed, its administrative state becomes locked.
The administrative state of a service unit is one of the states that determine the readi-
ness state (see Section 3.2.1.4) of that service unit.
The administrative state of a service unit is persistent even when all nodes within the
cluster are rebooted.
The administrative state of a service unit is not directly exposed to components by the
Availability Management Framework, but rather only indirectly, as the readiness state
has an impact on component service instance assignments.
3.2.1.3 Operational State
The operational state of the service unit reflects its error status. Valid values for the
operational state of a service unit are:
•
enabled: the operational state of a service unit transitions from disabled to
enabled when a successful repair action has been performed on the service unit
(see Section 3.11.1.4).
64 SAI-AIS-AMF-B.04.01 Section 3.2.1.4 AIS Specification
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
•
disabled: the operational state of a service unit transitions to disabled if a com-
ponent of the service unit has transitioned to the disabled state and the Availabil-
ity Management Framework has taken a recovery action at the level of the entire
service unit.
It is the Availability Management Framework that determines the value for the opera-
tional state of a service unit.
A service unit is enabled when the node containing this service unit joins the cluster
for the first time. It is set to disabled when a fail-over recovery is executed within its
scope, or if its presence state is set to instantiation-failed or termination-failed. After a
successful repair, it is set again to enabled by the entity performing the repair (Avail-
ability Management Framework or other entity). An administrative operation is pro-
vided to clear the disabled state of a service unit, so that an entity other than the
Availability Management Framework can perform the repair and declare the service
unit repaired. When a restart recovery is executed in the scope of a service unit, the
restart is considered as an instantaneous, combined recovery and repair action;
therefore, the operational state of the service unit remains enabled in such cases.
The operational state of the service unit is also re-evaluated whenever the opera-
tional state of one of its components transitions from disabled to enabled as a result
of clearing an error condition (see Section 7.12.2).
3.2.1.4 Readiness State
The operational, administrative, and presence states of a service unit, the operational
state of its containing node, and the administrative states of its containing node, ser-
vice group, application, and the cluster are combined into another state, called the
readiness state of a service unit. This state indicates if a serv
take service instance assignments from an administrative and health status view-
point. This state is used by Availability Management Framework to decide whether a
service unit is eligible to receive service instance assignments.
The readiness state of a service unit is not directly exposed to components by the
Availability Management Framework, but rather only indirectly, as the readiness state
has an impact on component service instance assignments.
AIS Specification SAI-AIS-AMF-B.04.01 Section 3.2.1.4 65
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
Valid values for the readiness state of a service unit are:
⇒
out-of-service
The readiness state of a non-pre-instantiable service unit is out-of-service if
one or more of the following conditions are met:
•
its operational state or the operational state of its containing node is dis-
abled;
•
its administrative state or the administrative state of its containing service
group, AMF node, application, or the cluster is either locked or locked-
instantiation;
•
the CLM node to which the containing AMF node is
ber.
The readiness state of a pre-instantiable service unit is out-of-service if
•
any of the preceding conditions that cause a non-pre-instantiable service
unit to become out-of-service is true,
•
or its presence state is neither instantiated nor restarting,
•
or the service unit contains contained components, and their configured
container CSI is not assigned active or quiescing to any container compo-
nent on the node that contains the service unit.
When the readiness state of a service unit is out-of-service, no new service
instance can be assigned to it. If service instances are already assigned to the
service unit at the time when the service unit enters the out-of-service state, they
are transferred to other service units (if possible) and removed.
Note that in some cases, pre-instantiable service units may be instantiated while
they are out-of-service. However, non-pre-instantiable service units are termi-
nated when they transition to the out-of-service readiness state.
⇒
in-service
The readiness state of a non-pre-instantiable service unit is in-service if all of
the following conditions are met:
•
its operational state and the operational state of its containing node is
enabled;
•
its administrative state and the administrative states of its containing ser-
vice group, AMF node, application, and the cluster are unlocked;
•
the CLM node to which the containing AMF node is mapped is a member
node.
66 SAI-AIS-AMF-B.04.01 Section 3.2.1.4 AIS Specification
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
The readiness state of a pre-instantiable service unit is in-service if
•
all of the preceding conditions that cause a non-pre-instantiable service
unit to become in-service are true,
•
and its presence state is either instantiated or restarting,
•
and the configured container CSI of all contained components of the ser-
vice unit is assigned active to at least one container component on the
node that contains the service unit.
When a service unit is in the in-service readiness state, it is eligible for service
instance assignments; however, it is possible that it has not yet been assigned
any service instance.
⇒
stopping
The readiness state of a service unit is stopping if all of the following conditions
are met:
•
its operational state and the operational state of its containing node is
enabled,
•
none of the administrative states of itself, the containing service group,
AMF node, application, CLM node, or the cluster is locked or locked-instan-
tiation,
•
at least one of the administrative states of itself, the containing service
group, AMF node, application, CLM node, or the cluster is shutting-down,
or the container component which is handling the life cycle of contained
components of the service unit has the quiescing HA state for the container
CSI of the contained components, and
•
the CLM node to which the containing AMF node is mapped is a member
node.
When a service unit is in the stopping state, no service instance can be assigned
to it, but already assigned service instances are not removed until the service
unit's components indicate to do so.
Table 4 shows how a pre-instantiable service unit's readiness state is derived from
the operational state, the presence state, and the administrative states of itself, and
the administrative states of its enclosing AMF node, service group, application, and
AMF cluster. The same table applies to non-pre-instantiable service units by ignoring
the “Service Unit’s Presence State column and assuming that the containing CLM
node is in the cluster membership in the first two rows and regardless of whether the
CLM node is or not in the cluster membership for the third row.
AIS Specification SAI-AIS-AMF-B.04.01 Section 3.2.1.5 67
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
3.2.1.5 HA State of a Service Unit for a Service Instance
When a service instance is assigned to a service unit, the Availability Management
Framework assigns an HA state to the service unit for that service instance. The HA
state takes one of the following values:
•
active: the service unit is currently responsible for providing the service charac-
terized by this service instance.
•
standby: the service unit acts as a standby for the service characterized by this
service instance.
•
quiescing: the service unit that had previously an active HA state for this service
instance is in the process of quiescing its activity related to this service instance.
In accordance with the semantics of the shutdown administrative operations, the
quiescing is performed by rejecting new users of the service characterized by
this service instance while still providing the service to existing users until they
all terminate using it. When no user is left for that service, the components of the
service unit indicate that fact to the Availability Management Framework, which
transitions the HA state to quiesced.
The quiescing HA state is assigned as a consequence of a shutdown administra-
tive operation.
•
quiesced: the service unit that had previously an active or quiescing HA state
for this service instance has now quiesced its activity related to this service
instance, and the Availability Management Framework can safely assign the
active HA state for this service instance to another service unit.
Table 4 Service Unit’s Readiness State
Cluster’s
Administrat
ive State
Application’s
Administrativ
e State
Service
Unit’s
Administr
ative
State
Service
Group’s
Administr
ative
State
AMF
Node’s
Administr
ative
State
AMF
Node’s
Operatio
nal State
Service
Unit’s
Operatio
nal State
Service
Unit’s
Presence
State
Service
Unit’s
Readiness
State
unlocked unlocked unlocked unlocked unlocked enabled enabled instantiated
or
restarting.
in-service
One or more columns contain the shutting-down state, and none is
locked or locked-instantiation.
enabled enabled instantiated,
instantiating,
terminating,
or
restarting
stopping
All other combinations of locked/locked-instantiation/unlocked/shutting-down, enabled/disabled and any pres-
ence state.
out-of-ser-
vice
68 SAI-AIS-AMF-B.04.01 Section 3.2.1.5 AIS Specification
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
The quiesced state is assigned in the context of switch-over situations (for a
description of switch-over, refer to Section 3.3).
Note:
At any point of time, a service unit may have multiple service instance assign-
ments.
The service units do not have an HA state of their own. They are assigned HA states
on behalf of service instances.
Note:
In the remainder of the document, the usage of the terminology “active or
standby service units”, without mentioni
vice instances the service unit has been assigned a particular HA state, will
be deemed legal when the context makes it obvious. This terminology is
mostly applicable in scenarios in which all service instances assigned to a
particular service unit share the same HA state and the service unit is incapa-
ble of sustaining a mix of HA states for the assigned service instances.
For simplicity of expression, the term active assignment of/for a service instance
(or simply active assignment if the context makes it clear which service instance is
meant) is used to mean the assignment of the active HA state to a service unit for this
service instance. Similar terms are also used for the other HA states, such as
standby assignment.
Taking into consideration the configuration of each service group (list of service
instances, list of service units, redundancy model attributes, and so on) and the cur-
rent value of the administrative and operational states of their service units and ser-
vice instances, the Availability Management Framework dynamically assigns the HA
state to the service units for the various service instances. Section 3.6 describes how
these assignments are performed for the various redundancy models.
Though some aspects differ from one redundancy model to another, some rules
apply to all redundancy models:
•
The overall goal of the Availability Management Framework is to keep as many
active assignments as requested by the configuration for all service instances
(which are administratively unlocked). If a service unit that is active for a service
instance goes out-of-service, the Availability Management Framework automati-
cally assigns the active HA state to a service unit that is already standby for the
service instance if there is one.
•
In the absence of administrative operations or error recovery actions being per-
formed, only active and (possibly) standby HA states are assigned to the service
units for particular service instances.
AIS Specification SAI-AIS-AMF-B.04.01 Section 3.2.1.6 69
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
3.2.1.6 HA Readiness State of a Service Unit per Service Instance
The HA readiness state of a service unit for a service instance is the aggregation
of the various HA readiness states of the components included in the service unit for
the component service instances included in the service instance. This state reflects
the ability of the service unit to assume the active or the standby assignments for the
service instance. This state further qualifies the readiness state of a service unit with
respect to each particular service instance protected by the service group. The Avail-
ability Management Framework can use this state and the readiness state to decide
which service unit is most appropriate for an HA state assignment. For details about
the HA readiness state of a component for a component service instance, refer to
Section 3.2.2.5.
The HA readiness state of a service unit for a service instance can take the following
values:
•
ready-for-assignment - The Availability Management Framework sets this state
to a service unit for a service instance if for each component service instance of
the service instance there is at least one component in the service unit with an
HA readiness state set to ready-for-assignment, so that the component service
instance can be assigned to the component. The service unit can take assign-
ments in any HA state for the service instance. If this value is set when the ser-
vice unit is not assigned or assigned standby for the service instance, the
Availability Management Framework must evaluate whether the service unit
should be assigned the affected service instance or whether the standby assign-
ment should be changed to an active assignment based on the overall status
and redundancy model of the containing service group and also on whether the
redundancy requirements of the service instance are being met.
•
ready-for-active-degraded - The Availability Management Framework sets this
state to a service unit for a service instance if
•
there is at least one component service instance in the service instance for
which there is no component in the service unit with an HA readiness state set
to ready-for-assignment, so that the component service instance can be
assigned to the component, but there is at least one component in the service
unit with an HA readiness state set to ready-for-active-degraded to which the
component service instance can be assigned, and
•
for each other component service instance of the service instance, there is at
at least one component in the service unit with an HA readiness state set to
ready-for-assignment or ready-for-active-degraded, so that the component
service instance can be assigned to the component.
70 SAI-AIS-AMF-B.04.01 Section 3.2.1.6 AIS Specification
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
This state indicates that the Availability Management Framework should avoid
assigning to the service unit the active HA state for the service instance,
because the service unit is not yet ready for it, and the active assignment would
have a negative impact on the quality of the service being provided.
If this value is set when the service unit is assigned or being assigned active or
quiescing for the service instance, the Availability Management Framework must
attempt to reassign the service instance to another service unit whose HA readi-
ness state is set to ready-for-assignment for this service instance. However, if
this value is set when the service unit is assigned or being assigned standby or
quiesced for the service instance, the assignment is not affected.
If this value is set when the service instance is not assigned to the service unit,
the Availability Management Framework must evaluate whether the service unit
should be assigned standby for the affected service instance based on the over-
all status and redundancy model of the containing service group and also on
whether the redundancy requirements of the service instance are being met.
•
not-ready-for-active - The Availability Management Framework sets this state
to a service unit for a service instance if
•
there is at least one component service instance in the service instance for
which there is no component in the service unit with an HA readiness state set
to ready-for-assignment or ready-for-active-degraded, so that the component
service instance can be assigned to the component, but there is at least one
component in the service unit with an HA readiness state set to not-ready-for-
active to which the component serv
•
for each other component service instance of the service instance, there is at
at least one component in the service unit with an HA readiness state set to
ready-for-assignment, ready-for-active-degraded, or not-ready-for-active, so
that the component service instance can be assigned to the component.
This state indicates that the Availability Management Framework must not
assign to the service unit any of the HA states active or quiescing for a service
instance.
If this value is set when the service unit is assigned or being assigned active or
quiescing for the service instance, the Availability Management Framework must
remove the assignment or change it to standby. However, if this value is set
when the service unit is assigned or being assigned standby or quiesced for the
service instance, the assignment is not affected.
AIS Specification SAI-AIS-AMF-B.04.01 Section 3.2.2 71
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
If this value is set when the service instance is not assigned to the service unit,
the Availability Management Framework must evaluate whether the service unit
should be assigned standby for the affected service instance based on the over-
all status and redundancy model of the containing service group and on whether
the redundancy requirements of the service instance are being met.
•
not-ready-for-assignment - The Availability Management Framework sets this
state to a service unit for a service instance if, at least for one of the component
service instance of the service instance, there is no component in the service
unit with an HA readiness state set to ready-for-assignment, ready-for-active-
degraded, or not-ready-for-active, so that the component service instance can
be assigned to the component.
This state indicates that the Availability Management Framework must not
assign this service instance to the service unit.
If this value is set when the service instance is assigned or being assigned to the
service unit, the Availability Management Framework must remove the assign-
ment.
3.2.2 Component States
The overall state of a component is a combination of a number of underlying states. A
description of these underlying states is given in the next sections.
Note:
No restriction exists in the applicability of various states of a component and
their values described in the following subsections to proxied components.
However, if the status of a proxied component changes to unproxied (typi-
cally, when its proxy component fails, and no proxy can be engaged to “proxy”
the proxied component), the values for various states of this proxied compo-
nent reflect the last know value of the corresponding states before its status
became unproxied.
3.2.2.1 Presence State
The presence state of a component reflects the component life cycle. It takes one of
the following values:
•
uninstantiated
•
instantiating
•
instantiated
•
terminating
•
restarting
•
instantiation-failed
•
termination-failed
72 SAI-AIS-AMF-B.04.01 Section 3.2.2.1 AIS Specification
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
The presence state of a component is set to instantiating
agement Framework invokes
•
the saAmfProxiedComponentInstantiateCallback() function (see
Section 7.10.2), or
•
the saAmfContainedComponentInstantiateCallback() function (see
Section 7.10.4), or
•
the saAmfCSISetCallback() function (see Section 7.9.2), or
•
when it executes the INSTANTIATE CLC-CLI command (see Section 4.6),
as applicable according to Table 37 on page 439, to instantiate the component.
The presence state of a component is set to instantiated when the INSTANTIATE
CLC-CLI command returns successfully (only for non-proxied, non-SA-aware compo-
nents) or the component is registered successfully with the Availability Management
Framework (for SA-aware or proxied components).
If, after all possible retries, a component cannot be instantiated, the presence state of
the component is set to instantiation-failed.
The following actions set the presence state of a component to terminating:
•
The Availability Management Framework invokes the
•
SaAmfComponentTerminateCallbackT function (see Section 7.10.1),
•
or the saAmfCSIRemoveCallback() function (see Section 7.9.3),
•
or it executes the TERMINATE CLC-CLI function (see Section 4.7),
as applicable according to Table 37 on page 439, to terminate the component
gracefully.
•
The Availability Management Framework abruptly terminates the component by
using one of the following interfaces, as applicable according to
Table37onpage439:
•
by executing the CLEANUP CLC-CLI command (see Section 4.8),
•
or by invoking the saAmfContainedComponentCleanupCallback()
(see Section 7.10.5),
•
or by invoking the saAmfProxiedComponentCleanupCallback() (see
Section 7.10.3).
A component will enter the uninstantiated state if it is successfully terminated or
cleaned up; it enters the termination-failed state if the cleanup operation fails.
AIS Specification SAI-AIS-AMF-B.04.01 Section 3.2.2.1 73
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
If an instantiated component fails, the Availability Management Framework will
make an attempt to restart the component, provided that restart is allowed for the
component.
A component is restarted by the Availability Management Framework in the context of
error recovery and repair actions (for details, see Section 3.11) or in the context of a
restart administrative operation (for details, see Section 9.4.7). Restarting a compo-
nent means first terminating it and then instantiating it again (see Section 3.11.1.2).
Two different actions shall be undertaken by the Availability Management Framework
regarding the component service instances assigned to a component when the com-
ponent restart is needed:
•
Keep the component service instances assigned to the component while the
component is restarted. This action is typically performed when it is faster to
restart the component than to reassign the component service instances to
another component. In this case, the presence state of the component is set to
restarting while the component is being terminated and until it is instantiated
again (or a failure occurs). Internally, in this particular scenario, the Availability
Management Framework withdraws and reassigns exactly the same HA state on
behalf of all component service instances to the component as was assigned to
the component for various component service instances before the restart pro-
cedure, without evaluating the various criteria that the Availability Management
Framework would normally assess before making such an assignment.
•
Reassign the component service instances currently assigned to the component
to another component before terminating/instantiating the component. In this
case, the presence state of the component is not set to restarting but transitions
through the other presence state values (typically in the absence of failures: ter-
minating, uninstantiated, instantiating, and then instantiated) as the component
is terminated and instantiated again.
The choice between these two policies is based on the
saAmfCompDisableRestart configuration attribute of each component (see the
SaAmfComp object class in Section 8.13.2).
When a node leaves the cluster, the Availability Management Framework sets the
presence state of all components included on that node to uninstantiated, except for
components that are in the instantiation-failed or termination-failed state.
74 SAI-AIS-AMF-B.04.01 Section 3.2.2.1 AIS Specification
Service Availability
TM
Application Interface Specification
System Description and System Model
1
5
10
15
20
25
30
35
40
Table 5 shows the possible presence states of the components of a service unit for
each valid presence state of the service unit:.
Table 5 Presence State of Components of a Service Unit
Service Unit Included Components
uninstantiated uninstantiated
instantiating uninstantiated
instantiating
instantiated
restarting
instantiated instantiated
restarting
terminating terminating
instantiated
restarting
uninstantiated
restarting restarting
instantiation-failed instantiation-failed
uninstantiated
instantiated
terminating
termination-failed
termination-failed instantiated
terminating
termination-failed
uninstantiated