 |
ハードウェア・プラットフォーム・インターフェース（HPI ）は、コンピュータシステムのプラットフォーム管理のためのアプリケーション・プログラミング・インターフェース（API）を定義するオープン仕様です。このAPIは、プロセッサに内蔵された温度センサーや電圧センサーの読み取り、ハードウェアレジスタの設定、モデル番号やシリアル番号などのシステムインベントリ情報へのアクセス、システムファームウェアのアップグレードやシステム障害の診断といったより複雑なアクティビティの実行といったタスクをサポートします。
HPIは、フォールトトレラントかつモジュール型の高可用性コンピュータシステムでの使用を目的として設計されています。これらのシステムは通常、自動障害検出機能とハードウェア冗長性を備えており、継続的なサービス可用性を提供します。高可用性アプリケーションに使用されるハードウェアプラットフォームに共通する追加機能としては、オンライン保守機能やホットスワップ可能なモジュールによるアップグレード機能などがあります。
HPI 仕様は、Service Availability Forum (SA Forum) によって開発および公開されており、一般に無料で公開されています。
歴史
HPI仕様策定の主な動機は、1990年代後半から2000年代初頭にかけて登場したモジュラー型コンピュータハードウェアプラットフォームと市販（COTS）システムでした。これにはCompactPCIプラットフォーム、そして後にPCI Industrial Computer Manufacturers Group （PICMG）によって標準化されたAdvancedTCAおよびMicroTCA（xTCA）プラットフォームが含まれます。これらのプラットフォームには、 Intelligent Platform Management Interface （IPMI）に基づくハードウェア管理インフラストラクチャが搭載されています。同時に、HPやIBMなどの大手エンタープライズベンダーもモジュラー型およびブレード型システムを開発しました。
HPI仕様の必要性は、「High Availability Forum」と呼ばれる業界団体によって初めて認識されました。この団体は2000年に数ヶ月にわたり会合を開き、オープンアーキテクチャ技術を用いた高可用性コンピュータシステムの構築に関する問題について議論しました。この団体は2001年初頭にホワイトペーパー「Providing Open Architecture High Availability Solutions（オープンアーキテクチャによる高可用性ソリューションの提供）」を発表しました。この活動から発展し、 Intel社はUniversal Chassis Management Interface（UCMI）という標準的なハードウェアプラットフォーム管理APIを定義するプロジェクトを開始しました。この作業は新たに設立されたSA Forumコンソーシアムに移行され、2002年10月にHardware Platform Interfaceとして公開されました。最初のHPI仕様であるSAI-HPI-A.01.01は、SA Forumによって公開された最初の仕様でした。
2002年以降、HPI仕様は何度か更新されてきました。さらに、 SNMP（ Simple Network Management Protocol）経由でHPI実装にアクセスするための仕様や、AdvancedTCAおよびMicroTCAプラットフォームにおけるHPIの使用法を記述した仕様も作成されています。表1は、SAフォーラムがHPIファミリーに関して公開しているすべての仕様の一覧です。
| 仕様ラベル | 発行日 | 注記 |
|---|---|---|
| SAI-HPI-A.01.01 | 2002年10月7日 | オリジナルHPI仕様 |
| SAI-HPI-B.01.01 | 2004年5月3日 | HPI基本仕様の大幅な改訂。元の仕様における実装とユーザビリティの問題を解決しました。 |
| SAI-HPI-SNMP-B.01.01 | 2004年5月3日 | HPI実装にアクセスするためのSNMP MIB |
| SAI-HPI-B.02.01 | 2006年1月18日 | 基本HPI仕様のマイナーリビジョン。FUMI、DIMI、負荷管理機能が追加されました。 |
| SAIM-HPI-B.01.01-ATCA | 2006年1月18日 | HPIからAdvancedTCAへのマッピング仕様 |
| SAI-HPI-B.03.01 | 2008年10月21日 | HPI基本仕様のマイナーリビジョン。FUMIの機能強化、いくつかの新しいAPI関数 |
| SAI-HPI-B.03.02 | 2009年11月20日 | 基本HPI仕様のマイナー修正 |
| SAIM-HPI-B.03.02-xTCA | 2010年2月19日 | AdvancedTCAマッピング仕様の大幅な改訂。AdvancedTCAに加え、MicroTCAプラットフォームのマッピングも含まれています。 |
HPI仕様とアプリケーション・インターフェース仕様（AIS）は、SAフォーラム内で別々に開発されています。どちらも最高レベルのサービス可用性に必要な機能に対応することを目的としていますが、それぞれ独立して使用できます。AIS仕様は、ハードウェア・プラットフォーム管理を実装していない高可用性クラスタリング・ミドルウェアに実装して使用できます。一方、HPI仕様はプラットフォーム・プロバイダーが実装し、他のSAフォーラム管理ミドルウェアを使用することなく、アプリケーションまたは管理プログラムで直接使用できます。
AIS仕様とHPI仕様の主な共通点は、AISプラットフォーム管理サービス（PLM）にあります。PLMサービスは、対象となるハードウェアプラットフォーム上でHPI仕様を実装することでハードウェアプラットフォーム管理が提供されることを前提として定義されています。
HPIアーキテクチャ
HPI仕様は、ハードウェアプラットフォームにどのようなプラットフォーム管理機能が搭載されるべきかを規定したり、想定したりするものではありません。むしろ、あらゆる機能をモデル化する汎用的で一貫性のある方法を提供し、ユーザーアプリケーションプログラムが利用可能なプラットフォーム管理機能の詳細を学習するための手段を提供します。
HPI は、ハードウェア プラットフォームの管理機能をリソースのセットにまとめます。各リソースは、ハードウェア プラットフォームの各部を監視および制御できる管理インストルメントのセットをホストします。管理インストルメントは、温度センサーや電圧センサー、構成レジスタ、表示要素など、プラットフォームに組み込まれた管理コンポーネントを抽象化したり、ファームウェアのアップグレードや診断の実行といった管理機能へのインターフェースを提供したりします。これらの管理インストルメントは、ユーザー アプリケーションからアクセスできるリソース データ レコード(RDR) に記述されており、これによりアプリケーションは各リソースの構成と機能を検出できます。
HPIリソースは抽象的な構造ですが、通常はハードウェアプラットフォーム内の個々の管理コントローラの管理機能をモデル化するために使用されます。例えば、AdvancedTCA（ATCA）プラットフォームでは、各コンピューティングブレードには通常、そのブレードに関連するハードウェア管理タスクを担当するIPMI管理コントローラ（IPMC）が含まれます。ATCAプラットフォームのHPIインターフェースには、通常、各IPMCに対応するリソースが含まれます。
HPI のリソースはドメインに編成されます。多くの場合、HPI 実装ではすべてのリソースに対して 1 つのドメインのみが実装されますが、必要に応じてシステムを複数のドメインに分割することも可能です。例えば、一部のモジュラーシステムでは、様々なモジュールが異なるユーザーによって所有および管理される場合があります。HPI ではこれに対応するため、特定のユーザーが所有するモジュールの管理に使用されるすべてのリソースを単一のドメインに配置し、そのユーザーにはそのドメインへのアクセス権のみを付与することができます。
HPIユーザープログラムは、特定のHPIドメインとのセッションを開くことで、プラットフォーム管理インフラストラクチャにアクセスします。このセッションが確立されると、ユーザープログラムは様々なHPI関数呼び出しを行い、そのドメイン、または現在そのドメインのメンバーとなっているリソースに関する情報を照会または更新できます。
HPI管理機器はドメインとリソースによって構成され、アドレス指定されますが、これらの管理機器によって管理されるハードウェアコンポーネントは、各管理機器に関連付けられたRDRで個別に識別されます。HPI内の物理ハードウェアコンポーネントはエンティティと呼ばれ、エンティティパスで識別されます。エンティティパスには複数の要素が含まれており、最初の要素はハードウェアエンティティが包含エンティティ内のどこに配置されているかを示し、2番目の要素はそのエンティティがより大きなコンテナ内のどこに配置されているかを示します。例えば、複数のラックにまたがるシステム内のシャーシの冗長電源は、POWER_SUPPLY.2、SUBRACK.3、RACK.1というエンティティパスを持つ場合があります。
各管理機器は特定のエンティティパスに関連付けられているため、1つのHPIリソースで複数のエンティティのプラットフォーム管理を処理できます。また、1つのエンティティを複数のHPIリソースで管理することも可能です。HPIリソースと管理対象のハードウェアエンティティを自由に組み合わせることができるという点は、一見混乱を招くかもしれませんが、HPIアーキテクチャの重要な機能です。これは、単一のハードウェアエンティティのインバンド管理要素とアウトオブバンド管理要素の両方を含む複雑な管理インフラストラクチャや、ある機器上の管理コントローラが別の機器の管理を提供するシステムをモデル化できるためです。
経営ツール
HPIリソースは、一連の管理機器をホストする場合があります。各管理機器は、ハードウェアエンティティの特定の側面を監視または制御する機能をモデル化します。各リソース内のRDRセットは、そのリソースがホストする管理機器を記述し、監視または制御の対象に関する情報も含みます。
プラットフォーム管理インフラストラクチャの様々な機能をモデル化するために使用できる管理機器は7種類あります。最初の4つ（センサー、コントロール、インベントリデータリポジトリ、ウォッチドッグタイマー）は基本的な管理機器であり、通常は個別のプラットフォーム管理機能にマッピングされます。残りの3つ（アナンシエータ、DIMI、FUMI）はより複雑で、プラットフォーム管理インフラストラクチャが提供できる論理機能をカプセル化します。
センサー
センサーは、エンティティの特定の側面を監視する機能をモデル化するために使用されます。HPIセンサーはIPMIセンサーをモデル化したものです。
HPIセンサーは、監視対象のハードウェアに関するステータス情報を、イベントステートと呼ばれる最大15ビットのセットを通じて報告します。各イベントステートは個別にアサートまたはデアサートすることができ、イベントステートが変化すると、非同期イベントが生成されてHPIユーザーに報告されます。各イベントステートの解釈は、定義されたセンサーカテゴリ（しきい値、パフォーマンス、プレゼンス、重大度など）に応じて異なる場合もあれば、特定のセンサーに固有の場合もあります。しきい値カテゴリのセンサーには、追加の機能があります。しきい値センサーは、監視対象の値が設定可能なしきい値を超えた場合または下回った場合に報告します。基準値からのどちらの方向への逸脱についても、最大3つの上限しきい値と3つの下限しきい値を定義できます。
HPIセンサーは、イベントステートを介して監視対象ハードウェアの状態を報告するだけでなく、「センサー読み取り値」と呼ばれる値も報告できます。センサー読み取り値は、監視対象の現在の値を適切な単位でスケール化して反映します。センサー読み取り値は、整数値、浮動小数点値、または最大32バイトの任意のデータブロックのいずれかです。
コントロール
コントロールは、エンティティの特定の側面を更新する機能をモデル化するために使用されます。HPIでは複数の種類のコントロールが定義されており、更新時に使用できるデータのタイプによって異なります。デジタルコントロールは、オン/オフ、またはパルスオン/オフが可能です。アナログコントロールとディスクリートコントロールは32ビット値に設定できます。ストリームコントロールとテキストコントロールには、LEDの点滅、ビープ音の鳴動、コントロールパネルへのデータ表示を制御するために、大量のデータを渡すことができます。OEM（ベンダー固有）コントロールには、管理対象エンティティによって実装固有の方法で使用できるデータブロックを送信できます。
インベントリデータリポジトリ（IDR）
インベントリデータリポジトリは、ハードウェアエンティティの識別情報および構成情報を報告または設定するために使用されます。通常、モデル番号、シリアル番号、基本構成データなどの項目は、ハードウェアエンティティのROMまたはフラッシュメモリに保存されます。これらの情報は、HPIインベントリデータリポジトリを介して読み取り、場合によっては更新できます。
ウォッチドッグタイマー
ウォッチドッグタイマーは、高可用性システムにおいて特殊なハードウェアを用いて実装されることが多いデバイスです。これらのデバイスは、プログラムによってリセットされない限り、一定時間後にエンティティを自動的に中断、リセット、または電源投入し直すように設定されます。ウォッチドッグタイマーデバイスの目的は、障害検出メカニズムを提供することです。HPIウォッチドッグタイマー管理インストルメントは、この種のハードウェアメカニズムとインターフェースするように設計されています。これは、IPMIウォッチドッグタイマーを非常に忠実にモデル化しています。
アナウンサー
アナンシエータは、ハードウェア・プラットフォーム上のアラーム表示機能とのインターフェースとして使用される論理的な管理機器です。LED、音声アラート、テキスト表示パネルなど、多種多様なアラーム表示ハードウェアが様々なハードウェア・プラットフォームで使用されるため、プラットフォームに依存しない方法でアラーム情報を表示するアプリケーション・プログラムを作成することは困難です。HPIアナンシエータ管理機器は、アラーム情報をHPI実装または基盤となる管理インフラストラクチャに伝達するための抽象インターフェースを提供します。これにより、HPI実装または基盤となる管理インフラストラクチャは、特定のプラットフォーム上でその情報を表示するための適切なアクションを実行できます。
診断イニシエーター管理機器（DIMI）
DIMIは、様々なハードウェアエンティティ上でオンラインまたはオフラインの診断ファームウェアまたはソフトウェアの実行を調整するために用いられる論理管理ツールです。DIMIは、診断実行によるサービスへの影響を示す情報をHPIユーザープログラムに提供し、診断プログラムの実行を開始、停止、監視するための共通インターフェースを提供します。この機能はHPIに統合されており、障害状態の自動診断と修復を標準化し、オンライン保守をサポートします。
ファームウェア アップグレード管理ツール (FUMI)
FUMIは、プログラム可能なハードウェアエンティティへのファームウェアアップデートのインストールをサポートするために使用される論理管理ツールです。フィールドアップグレード可能なファームウェアを含むハードウェアエンティティの場合、FUMIは現在インストールされているファームウェアバージョンに関する情報を提供し、ロードする新しいバージョンを識別し、必要に応じてバックアップや以前のバージョンへのロールバックを含むアップグレードプロセスを調整するための標準インターフェースを提供します。
リソースレベルの機能
前述の管理ツールセットに加えて、HPIリソースは最大4つの追加管理機能も提供できます。これらのリソースレベルの機能は本質的に特別な管理ツールであり、リソースによってサポートされる管理ツールの種類はそれぞれ最大1つです。特定のリソースがこれらの様々な機能を提供するかどうか、およびそれらがどのエンティティに適用されるかは、HPIユーザーがリソースに対してアクセスできるデータレコードに記述されています。このレコードには単一のエンティティパスが定義されているため、これらの機能が存在する場合、それらは同じエンティティに適用されます。
- リソース レベルの電源管理機能は、指定されたエンティティの電源をオンまたはオフにする特殊なコントロールとして機能します。
- リソース レベルのリセット機能は、指定されたエンティティでハード リセットまたはソフト リセット操作を実行したり、サポートされている場合はリセット信号をアサート状態に保持してエンティティが動作しないようにする特殊なコントロールとして機能します。
- リソース レベルのロード管理機能は、指定されたエンティティのブートストラップ プログラムとインターフェイスして、ブートストラップ操作の実行時にどのオペレーティング システムまたはその他のソフトウェアをロードする必要があるかを識別する特殊なコントロールとして機能します。
- リソース レベルの構成管理機能は、HPI ユーザーがリソースに対して、センサーのしきい値レベルなどの構成情報を永続ストレージ メディアに保存したり、永続ストレージ メディアから復元したりするように指示する方法を提供します。
ドメイン関数
ユーザープログラムは、ドメインとのセッションを開くことで、HPIベースのプラットフォーム管理にアクセスします。ユーザープログラムは、ドメイン識別子を指定して特定のドメインとのセッションを開くことも、より一般的には、デフォルトのドメインとのセッションを開くこともできます。セッションが確立されると、ユーザープログラムはさまざまなドメインレベルの機能にアクセスしたり、現在ドメインのメンバーとしてリストされているリソースにアクセスしたりできるようになります。セッションでアクセスできるのは、現在ドメインのメンバーであるリソースのみであるため、HPI実装では、各ドメインのメンバーとなるリソースを制限し、それらのドメインとのセッションを確立できるユーザーを制限することで、ユーザーアクセス制御を実施できます。
ドメインの最も重要な機能の一つは、リソースプレゼンステーブル（RPT）を介して、ドメインのメンバーであるすべてのリソースに関する情報を提供することです。もう一つのテーブルであるドメインリファレンステーブル（DRT）は、追加のセッションを開くことでアクセスできる他のHPIドメインに関する情報を提供します。
HPI インターフェースはドメイン レベルで 3 つのサービスを提供しており、ユーザー プログラムはこれを使用してハードウェア プラットフォームの例外的な状態についての最新情報を入手できます。 最も重要なのはイベント管理サービスです。ユーザーは、開いているセッションでドメインからイベントを転送するよう要求できます。ドメインのメンバーであるリソースによって監視されているハードウェア エンティティに重要なイベントが発生すると、イベント メッセージが生成され、そのような要求を行ったすべての開いているセッションのキューに入れられます。このメカニズムにより、ユーザー プログラムは、継続的にステータスをポーリングしなくても、管理対象プラットフォームの変更についての最新情報を入手できます。イベントはドメイン イベント ログに保存され、後で取得して履歴分析を行うこともできます。最後に、ユーザー プログラムからアクセスできるドメイン アラーム テーブルは、ドメインのメンバーであるリソースに存在する現在のアラーム状態を報告します。
ホットスワップ管理
HPI仕様の重要な特徴は、管理対象プラットフォームにおける動的再構成、つまりホットスワップ処理の処理方法です。ホットスワップとは、稼働中のプラットフォームでハードウェアコンポーネントを追加または削除する機能を指します。HPIでは、ホットスワップ可能なハードウェアエンティティをフィールド交換可能ユニット（FRU）と呼びます。多くの場合、特にAdvancedTCAのようなシステムアーキテクチャでは、FRUに独自のプラットフォーム管理コントローラーが搭載されています。そのため、FRUのホットスワップは、管理対象となるハードウェアエンティティのセットと、その管理に利用可能なインフラストラクチャの両方を同時に変更する可能性があります。
HPIのホットスワップ管理アプローチは、ドメイン内のリソースの追加または削除によってハードウェアエンティティの追加または削除をモデル化することで、これを反映しています。FRUに独自の管理コントローラーが含まれていない場合、リソースには管理機能が割り当てられていない可能性がありますが、それでもシステム内のFRUの存在を報告するために使用されます。一方、FRUに管理コントローラーが含まれている場合、ドメインに追加されたリソースは新しい管理機器やその他の機能をホストし、HPIユーザーがそれらを利用できるようになります。
FRUに関連付けられたリソースは、常に5つのホットスワップ状態（Not Present、Inactive、Insertion Pending、Active、Extraction Pending）のいずれかの状態にあり、HPIユーザーが読み取り可能です。Not Present状態は、リソースによって実際に報告されることはありません。これは、FRUがシステムに存在しない場合、リソースはどのドメインのメンバーとしても存在すべきではないためです。他の4つの状態は、FRUが完全に動作しているかどうかに関係なく、システムに物理的に存在するFRUに適用されます。リソースが新しいホットスワップ状態に変化すると、イベント通知を要求したユーザープログラムにHPIイベントが送信されます。
ホットスワップ対応FRUをモデル化するHPIリソースは、非管理型ホットスワップまたは管理型ホットスワップのいずれかをサポートするように構成できます。非管理型ホットスワップをサポートするリソースは、現在のホットスワップ状態を報告しますが、ユーザーはFRUのホットスワップ操作を制御することはできません。リソースが管理型ホットスワップをサポートする場合、ユーザープログラムはHPI実装および基盤となるプラットフォーム管理インフラストラクチャと連携して、新しく追加されたFRUを統合するために必要なアクション、またはシステムから取り外されるFRUを非アクティブ化するために必要なアクションを調整できます。
下位互換性
SAフォーラムの目標は、仕様の新バージョンが以前のバージョンとの後方互換性を維持することです。HPI仕様の場合、これは、特定のバージョンのHPI実装で動作するように作成されたユーザープログラムが、その仕様のより新しいバージョンをサポートするHPI実装でも変更なく動作し続けることを意味します。この目標は、SAI-HPI-B.01.01仕様以降に公開されたHPI仕様によって達成されています。HPI仕様の「B」シリーズは、SAI-HPI-A.01.01仕様との後方互換性はありません。
HPI 仕様の下位互換性を実現するために、いくつかの戦略が採用されています。 a) 以前のバージョンの HPI 仕様で定義された関数は、関数プロトタイプを変更することなく、後のバージョンに含まれています。廃止された関数は保持されますが、新しいユーザー プログラムでは使用しないよう仕様にアドバイスが含まれています。 b) 既存のプログラムでその使用が要求されない限り、新しい関数は HPI 仕様の新しいバージョンに追加できます。 c) ハードウェア エンティティ タイプ、センサー タイプなどのデータを報告するさまざまな列挙は、HPI 仕様でオープンエンドとして宣言されています。HPI 関数が返す可能性のあるエラー戻りコードのリストもオープンエンドとして宣言されています。新しいバージョンの HPI 仕様では、既存の列挙値は削除または変更されませんが、オープンエンド列挙に新しい値が追加されることがあります。ユーザー プログラムでは、現在定義されていない値を受け入れ、「有効だが未定義」として扱う必要があります。そうすることで、プログラムは、列挙体の新しい値が定義されている可能性のある、新しいバージョンの HPI 仕様に合わせて構築された実装で使用する場合でも、引き続き動作します。 d) HPI 関数からユーザーに渡されるデータ構造は、新しいバージョンの HPI 仕様では長さが大きくならず、以前のバージョンで定義されたデータの形式も変更されません。ただし、新しいビットや未使用スペースの新しい使用を認識しないプログラムが正しく動作し続ける限り、ビット フィールド内の以前に未定義のビットが新しいバージョンの HPI 仕様で定義され、共用体内の未使用スペースが使用される場合があります。 e) ユーザーから HPI 関数に渡されるデータ構造は、以前に定義された構造を渡す既存のプログラムが正しく動作し続けるような方法で変更される限り、新しいバージョンの HPI 仕様で変更される可能性があります。
HPI から xTCA へのマッピング仕様
HPIはAdvancedTCAシステムで広く使用されているため、SAフォーラムは2006年1月にSAIM-HPI-B.01.01-ATCAというマッピング仕様を公開しました。この仕様の目的は、HPI管理インターフェースの実装者に対し、この複雑なシステムアーキテクチャをHPIでモデル化するための推奨方法に関するガイダンスを提供することです。2010年2月には、このマッピングを改訂し、MicroTCAシステムに拡張した新しいマッピング仕様SAIM-HPI-B.03.02-xTCAが公開されました。
HPIからxTCAへのマッピング仕様は、単一のHPIドメインにおいて、HPIにおけるxTCAプラットフォームの管理性を表現する方法を定義します。xTCAシステムコンポーネントのエンティティパス命名が指定され、これらのプラットフォームで利用可能なプラットフォーム管理情報と制御機能を反映する管理ツールが定義されています。
マッピング仕様では、xTCAシャーシ、シェルフマネージャ、キャリアマネージャ、およびその他のFRUのリソースも定義されています。仕様のオリジナルバージョンでは、シャーシ内またはFRUを収容する可能性のあるキャリアカード上のすべての「スロット」に対してリソースが定義され、必須とされていました。2010年に公開された更新版では、これらのスロットリソースはオプションになりました。
HPIからxTCAへのマッピング仕様は、2つの対象者を対象としています。1つ目は、HPIインターフェースをAdvancedTCAまたはMicroTCAプラットフォームに組み込みたいプラットフォーム開発者です。この仕様は、システムをモデリングするためのテンプレートを提供します。
2つ目の対象者は、複数のAdvancedTCAまたはMicroTCAプラットフォームにまたがる移植可能なアプリケーションまたはミドルウェアプログラムを作成したいHPIユーザーです。ただし、xTCAと他のハードウェアプラットフォームアーキテクチャの両方に移植可能なプログラムを提供したいHPIユーザーは、必ずしもHPIからxTCAへのマッピング仕様を参照する必要はありません。これは、HPIからxTCAへのマッピング仕様に準拠したHPI実装が、標準HPIインターフェースを介して検出および使用可能な方法で基本的なプラットフォーム管理機能を提供するためです。xTCAプラットフォーム固有の一部のプラットフォーム管理機能は、マッピング仕様を参照しないと使用できませんが、ほとんどの汎用HPIユーザーアプリケーションではこれらの機能は無視しても問題ありません。
HPI実装
HPI仕様は、AdvancedTCAコンピュータシステムやその他の高可用性コンピュータプラットフォームを構築するプラットフォームベンダーを中心に、広く普及している実装がいくつか開発されています。ほとんどの実装では、HPIアプリケーション・プログラム・インターフェース自体は、アプリケーションプログラムにリンクされたライブラリを通じて提供されます。このライブラリモジュールは通常、デーモンプロセスとして実行されるHPIサーバーと通信します。HPIサーバーはHPIドメインおよびリソースの機能を実行し、必要に応じて基盤となる管理インフラストラクチャと通信します。
いくつかのHPI実装は、OpenHPI（Wayback Machineに2010年2月27日にアーカイブ）と呼ばれるHPI仕様のオープンソース実装に基づいています。OpenHPIも図6に示す基本設計に従っており、アプリケーションプログラムとリンクするライブラリモジュールと、ライブラリモジュールが通信するデーモンモジュールで構成されています。OpenHPIデーモンプロセスは、1つ以上のプラグインモジュールと統合するように設計されており、プラグインモジュールは様々なプラットフォーム管理インフラストラクチャとの下流通信を処理します。
SAフォーラム実装レジストリは、SAフォーラム仕様の実装を登録し、公開できるようにするプロセスです。実装の登録にメンバーシップは必須ではありません。登録が完了した実装は、「サービス可用性フォーラム登録済み」と呼ばれる場合があります。
参照
参照
参考文献
外部リンク
