Loading article…
ハードウェアプラットフォームインターフェース（HPI ）は、コンピュータシステムのプラットフォーム管理のためのアプリケーションプログラミングインターフェース（API）を定義するオープン仕様です。このAPIは、プロセッサに組み込まれた温度センサーや電圧センサーの読み取り、ハードウェアレジスタの設定、モデル番号やシリアル番号などのシステムインベントリ情報へのアクセス、システムファームウェアのアップグレードやシステム障害の診断といったより複雑な処理など、様々なタスクをサポートします。
HPIは、耐障害性とモジュール性を備えた高可用性コンピュータシステムでの使用を想定して設計されています。これらのシステムは通常、自動障害検出機能とハードウェア冗長性を備えており、継続的なサービス可用性を提供します。高可用性アプリケーションで使用されるハードウェアプラットフォームに共通するその他の機能としては、オンラインでの保守性や、ホットスワップ可能なモジュールによるアップグレード性などが挙げられます。
HPI仕様は、サービス可用性フォーラム（SAフォーラム）によって開発・公開され、一般に無料で提供されています。
HPI仕様の開発における主要な動機の一つは、1990年代後半から2000年代初頭にかけて、モジュール型コンピュータハードウェアプラットフォームと市販既製品（COTS）システムが登場したことである。これには、 CompactPCIプラットフォーム、そして後にPCI Industrial Computer Manufacturers Group （PICMG）によって標準化されたAdvancedTCAおよびMicroTCA（xTCA）プラットフォームが含まれる。これらのプラットフォームには、インテリジェントプラットフォーム管理インターフェース（IPMI）に基づくハードウェア管理インフラストラクチャが組み込まれている。同時に、HPやIBMといった大手エンタープライズベンダーも、モジュール型システムやブレード型システムを開発していた。
HPI仕様の必要性は、2000年に数ヶ月にわたりオープンアーキテクチャ技術を用いた高可用性コンピュータシステムの構築に関する問題を議論した「High Availability Forum」と呼ばれる業界団体によって最初に認識されました。この団体は2001年初頭に「オープンアーキテクチャ高可用性ソリューションの提供」というホワイトペーパーを発表しました。この取り組みから発展し、インテル社はUniversal Chassis Management Interface（UCMI）という標準ハードウェアプラットフォーム管理APIを定義するプロジェクトを開始しました。この取り組みは新たに設立されたSA Forumコンソーシアムに移管され、2002年10月にHardware Platform Interfaceとして公開されました。オリジナルのHPI仕様であるSAI-HPI-A.01.01は、SA Forumが最初に公開した仕様です。
2002年以降、HPI仕様の改訂版が複数公開されています。さらに、Simple Network Management Protocol（SNMP）を介したHPI実装へのアクセスに関する仕様、およびAdvancedTCAおよびMicroTCAプラットフォーム上でのHPIの使用方法を記述した仕様も作成されています。表1には、SA ForumがHPIファミリーで公開したすべての仕様が一覧表示されています。
HPI仕様とアプリケーションインターフェース仕様（AIS）は、SA Forum内で別々に開発されました。どちらも最高レベルのサービス可用性に必要な機能に対応することを目的としていますが、それぞれ独立して使用できます。AIS仕様は、ハードウェアプラットフォーム管理を実装しない高可用性クラスタリングミドルウェアに実装して使用でき、HPI仕様はプラットフォームプロバイダーが実装し、他のSA Forum管理ミドルウェアを使用せずにアプリケーションまたは管理プログラムから直接使用できます。
AIS仕様とHPI仕様の主な共通点は、AISプラットフォーム管理サービス（PLM）にあります。PLMサービスは、対象となるハードウェアプラットフォーム上で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 (ベンダー固有) コントロールには、管理対象エンティティによって実装固有の方法で使用される可能性のあるデータ ブロックを送信できます。
インベントリデータリポジトリは、ハードウェアエンティティの識別情報や構成情報を報告または設定するために使用されます。通常、モデル番号、シリアル番号、基本構成データなどの項目は、ハードウェアエンティティのROMまたはフラッシュメモリに保存されます。これらの情報は、HPIインベントリデータリポジトリを介して読み取り、場合によっては更新することができます。
ウォッチドッグタイマーは、高可用性システムにおいて専用ハードウェアを用いて実装されることが多いデバイスです。これらのデバイスは、プログラムによるリセットが行われない場合、一定時間経過後にエンティティを自動的に中断、リセット、または電源再投入するように設定されています。ウォッチドッグタイマーの目的は、障害検出メカニズムを提供することです。HPIウォッチドッグタイマー管理機器は、このようなハードウェアメカニズムと連携するように設計されています。IPMIウォッチドッグタイマーをモデルに開発されています。
アニュンシエーターは、ハードウェアプラットフォーム上のアラーム表示機能と連携するために使用される論理的な管理機器です。LED、可聴アラート、テキスト表示パネルなど、さまざまなアラーム表示ハードウェアがさまざまなハードウェアプラットフォームで使用されているため、プラットフォームに依存しない方法でアラーム情報を表示するアプリケーションプログラムを作成することは困難です。HPIアニュンシエーター管理機器は、アラーム情報をHPI実装または基盤となる管理インフラストラクチャに伝達するための抽象的なインターフェースを提供し、HPI実装または基盤となる管理インフラストラクチャは、その情報を特定のプラットフォームに表示するための適切なアクションを実行できます。
DIMIは、さまざまなハードウェア上でオンラインまたはオフラインの診断ファームウェアやソフトウェアの実行を調整するために使用される論理管理ツールです。DIMIは、診断の実行によるサービスへの影響を示す情報をHPIユーザープログラムに提供し、診断プログラムの開始、停止、および実行状況の監視を行うための共通インターフェースを提供します。この機能はHPIに統合されており、障害状態の自動診断と修復の標準化、およびオンラインサービス対応を支援します。
FUMIは、プログラマブルハードウェアエンティティへのファームウェアアップデートのインストールをサポートするために使用される論理管理ツールです。フィールドアップグレード可能なファームウェアを搭載したハードウェアエンティティの場合、FUMIは現在インストールされているファームウェアのバージョンに関する情報を提供し、ロードする新しいバージョンを識別し、必要に応じてバックアップや以前のバージョンへのロールバックを含むアップグレードプロセスを調整するための標準インターフェースを提供します。
上記で説明した一連の管理ツールに加えて、HPIリソースは最大4つの追加管理機能を提供する場合があります。これらのリソースレベルの機能は、基本的に特別な管理ツールであり、リソースがサポートする各タイプの管理ツールは最大1つまでです。特定のリソースがこれらの追加機能を提供するかどうか、またそれらがどのエンティティに適用されるかは、HPIユーザーがアクセスできるリソースのデータレコードに記載されています。そのレコードには単一のエンティティパスが定義されているため、これらの機能が存在する場合、いずれも同じエンティティに適用されます。
ユーザープログラムは、ドメインとのセッションを開くことで、HPIベースのプラットフォーム管理にアクセスします。ユーザープログラムは、ドメイン識別子を指定して特定のドメインとのセッションを開くこともできますし、より一般的な方法として、デフォルトのドメインとのセッションを開くこともできます。セッションが確立されると、ユーザープログラムはさまざまなドメインレベルの機能にアクセスしたり、現在ドメインのメンバーとしてリストされているリソースにアクセスしたりできます。セッションは現在ドメインのメンバーであるリソースへのアクセスのみを許可するため、HPI実装では、各ドメインのメンバーとなるリソースを制限したり、それらのドメインとのセッションを確立できるユーザーを制限したりすることで、ユーザーアクセス制御を強制できます。
ドメインの最も重要な機能の1つは、リソース存在テーブル（RPT）を介して、ドメインに属するすべてのリソースに関する情報を提供することです。2つ目のテーブルであるドメイン参照テーブル（DRT）は、追加のセッションを開くことでアクセスできる他のHPIドメインに関する情報を提供します。
HPIインターフェースは、ユーザープログラムがハードウェアプラットフォームの異常状態を把握するために使用できる、ドメインレベルの3つのサービスを提供します。その中で最も重要なのは、イベント管理サービスです。ユーザーは、開いているセッションでドメインからイベントを転送するように要求できます。ドメインに属するリソースによって監視されているハードウェアエンティティに重大なイベントが発生すると、イベントメッセージが生成され、そのような要求を行ったすべての開いているセッションにキューイングされます。このメカニズムにより、ユーザープログラムは、ステータスを継続的にポーリングすることなく、管理対象プラットフォームの変更を把握できます。イベントはドメインイベントログに保存され、後で履歴分析のために取得することもできます。最後に、ドメインアラームテーブルはユーザープログラムからアクセスでき、ドメインに属するリソースに存在する現在のアラーム状態を報告します。
HPI仕様の重要な特徴の一つは、管理対象プラットフォームにおける動的な再構成、すなわちホットスワップ操作の処理方法です。ホットスワップとは、稼働中のプラットフォームにハードウェアコンポーネントを追加または削除できる機能を指します。HPIでは、ホットスワップ可能なハードウェアエンティティをフィールド交換可能ユニット（FRU）と呼びます。特にAdvancedTCAのようなシステムアーキテクチャでは、FRUには独自のプラットフォーム管理コントローラが含まれていることがよくあります。そのため、FRUをホットスワップすると、管理対象となるハードウェアエンティティのセットと、その管理に利用できるインフラストラクチャの両方を同時に変更できます。
HPIのホットスワップ管理アプローチは、ハードウェアエンティティの追加または削除をドメイン内のリソースの追加または削除によってモデル化することで、この点を反映しています。FRUに管理コントローラが含まれていない場合、リソースには管理機能が割り当てられない可能性がありますが、それでもシステム内でのFRUの存在を報告するために使用されます。一方、FRUに管理コントローラが含まれている場合、ドメインに追加されたリソースは、新しい管理機器やその他の機能をホストし、HPIユーザーが利用できるようにします。
FRUに関連付けられたリソースは、常に5つのホットスワップ状態のいずれかになります。これらの状態は、HPIユーザーが読み取ることができます。状態は、「存在しない」、「非アクティブ」、「挿入保留中」、「アクティブ」、「抽出保留中」です。「存在しない」状態は、リソースによって実際に報告されることはありません。これは、FRUがシステムに存在しない場合、リソースはどのドメインのメンバーとしても存在すべきではないためです。他の4つの状態は、完全に動作しているかどうかにかかわらず、システムに物理的に存在するFRUに適用されます。リソースが新しいホットスワップ状態に変化すると、イベント通知を要求したユーザープログラムにHPIイベントが送信されます。
ホットスワップ可能なFRUをモデル化するHPIリソースは、アンマネージドホットスワップまたはマネージドホットスワップのいずれかをサポートするように構成できます。アンマネージドホットスワップをサポートするリソースは、現在のホットスワップ状態を報告しますが、ユーザーはFRUのホットスワップ操作を制御できません。リソースがマネージドホットスワップをサポートする場合、ユーザープログラムはHPI実装および基盤となるプラットフォーム管理インフラストラクチャと連携して、新しく追加されたFRUを統合したり、システムから削除されるFRUを非アクティブ化したりするために必要なアクションを調整できます。
SAフォーラムの目標は、仕様の新しいバージョンが以前のバージョンとの下位互換性を維持することです。HPI仕様の場合、これは、特定のバージョンのHPI実装で動作するように作成されたユーザープログラムが、仕様のより新しいバージョンをサポートするHPI実装でも変更なしで動作し続けることを意味します。この目標は、SAI-HPI-B.01.01仕様以降に公開されたHPI仕様で達成されています。「B」シリーズのHPI仕様は、SAI-HPI-A.01.01仕様との下位互換性はありません。
HPI仕様の後方互換性を実現するために、いくつかの戦略が採用されています。a ) HPI仕様の以前のバージョンで定義された関数は、関数プロトタイプを変更せずに後のバージョンに含まれています。廃止された関数は保持されますが、新しいユーザープログラムでは使用すべきではないというアドバイスが仕様に含まれています。b ) 既存のプログラムで使用が必須でない限り、新しい関数はHPI仕様の新しいバージョンに追加できます。c ) ハードウェアエンティティタイプ、センサータイプなどのデータを報告するさまざまな列挙型は、HPI仕様でオープンエンドとして宣言されています。HPI関数が返す可能性のあるエラー戻りコードのリストもオープンエンドとして宣言されています。HPI仕様の新しいバージョンでは、既存の列挙値を削除または変更することはありませんが、オープンエンドの列挙型に新しい値を追加する場合があります。ユーザープログラムは、現在定義されていない値を受け入れ、「有効だが未定義」として扱う必要があります。こうすることで、列挙に新しい値が定義されている可能性がある、より新しいバージョンの HPI 仕様に基づいて構築された実装で使用された場合でも、プログラムは引き続き動作することができます。 d) HPI 関数からユーザーに渡されるデータ構造は、HPI 仕様の新しいバージョンで長さが増したり、以前のバージョンで定義されたデータの形式を変更したりすることはできません。ただし、ビット フィールドで以前は定義されていなかったビットは、HPI 仕様の新しいバージョンで定義することができ、共用体の未使用領域を使用することもできます。ただし、新しいビットや未使用領域の新しい使用を認識しないプログラムが正しく動作し続けることが条件です。 e) ユーザーから HPI 関数に渡されるデータ構造は、HPI 仕様の新しいバージョンで変更することができます。ただし、変更は、以前に定義された構造を渡す既存のプログラムが正しく動作し続けるように行われる必要があります。
HPIはAdvancedTCAシステムで広く使用されているため、SA Forumは2006年1月にSAIM-HPI-B.01.01-ATCAというマッピング仕様を公開しました。この仕様の目的は、HPI管理インターフェースの実装者に対し、この複雑なシステムアーキテクチャをHPIでモデル化する推奨方法を示すことです。2010年2月には、このマッピングを改訂し、MicroTCAシステムにも拡張した新しいマッピング仕様、SAIM-HPI-B.03.02-xTCAが公開されました。
HPIからxTCAへのマッピング仕様は、単一のHPIドメイン内でxTCAプラットフォームの管理性をHPI上で表現する方法を定義します。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仕様の実装は数多く開発されており、中でもAdvancedTCAコンピュータシステムやその他の高可用性コンピュータプラットフォームを構築するプラットフォームベンダーによるものが特に注目されています。ほとんどの実装では、HPIアプリケーションプログラミングインターフェース自体は、アプリケーションプログラムにリンクされたライブラリを通じて提供されます。このライブラリモジュールは通常、デーモンプロセスとして実行されるHPIサーバーと通信し、HPIサーバーはHPIドメインとリソースの機能を実行し、必要に応じて基盤となる管理インフラストラクチャと通信します。
HPIの実装のいくつかは、 Wayback Machineに2010年2月27日にアーカイブされたOpenHPIと呼ばれるHPI仕様のオープンソース実装に基づいています。OpenHPIは、図6に示す一般的な設計に従っており、アプリケーションプログラムとリンクするライブラリモジュールと、ライブラリモジュールが通信するデーモンモジュールが含まれています。OpenHPIデーモンプロセスは、さまざまなプラットフォーム管理インフラストラクチャとの下流通信を処理する1つ以上のプラグインモジュールと統合するように設計されています。
SA Forum実装レジストリは、SA Forum仕様の実装を登録し、一般に公開するためのプロセスです。実装の登録に会員資格は必要ありません。登録に成功した実装は、「Service Availability Forum登録済み」と呼ばれることがあります。