(57)【特許請求の範囲】
【請求項１】
管理プロセッサと、
プロセッサと、
を有し、
前記管理プロセッサが、
他の情報処理装置内のハードウエアへのアクセスの要求を、前記管理プロセッサと前記他の情報処理装置における管理プロセッサとの通信用の伝送路である第１の伝送路を使用して前記他の情報処理装置に転送することができない場合、前記要求を前記プロセッサに出力し、
前記プロセッサが、
前記管理プロセッサから受け取った前記要求を、前記プロセッサと前記他の情報処理装置におけるプロセッサとの通信用の伝送路である第２の伝送路を使用して、前記他の情報処理装置に転送する
ことを特徴とする情報処理装置。
【請求項２】
前記情報処理装置内のハードウエアへのアクセスを行う処理部
をさらに有し、
前記管理プロセッサは、
前記情報処理装置内のハードウエアへのアクセスの要求を、前記処理部に出力し、
前記プロセッサは、
前記他の情報処理装置から前記情報処理装置内のハードウエアへのアクセスの要求を受信した場合、当該要求を前記処理部に出力し、
前記処理部は、
前記情報処理装置内のハードウエアへのアクセスの要求を前記管理プロセッサ又は前記プロセッサから受け取った場合、当該要求に基づき、前記情報処理装置内のハードウエアへのアクセスを行い、
前記情報処理装置内のハードウエアへのアクセスの要求に対する応答を生成し、前記要求の出力元に出力する
ことを特徴とする請求項１記載の情報処理装置。
【請求項３】
前記他の情報処理装置における管理プロセッサの状態を示す情報を記憶する記憶装置
をさらに有し、
前記管理プロセッサは、
前記第１の伝送路を介して前記他の情報処理装置における管理プロセッサと通信を行うことにより、前記他の情報処理装置における管理プロセッサの状態を特定し、
特定された前記状態に基づき、前記記憶装置に記憶された情報を更新する
ことを特徴とする請求項１又は２記載の情報処理装置。
【請求項４】
前記プロセッサは、
前記要求に対する応答を前記他の情報処理装置から前記第２の伝送路を介して受信した場合、前記応答を前記管理プロセッサに出力する
ことを特徴とする請求項１乃至３のいずれか１つ記載の情報処理装置。
【請求項５】
管理プロセッサとプロセッサとを有するコンピュータにより実行される制御方法であって、
前記管理プロセッサが、他の情報処理装置内のハードウエアへのアクセスの要求を、前記管理プロセッサと前記他の情報処理装置における管理プロセッサとの通信用の伝送路である第１の伝送路を使用して前記他の情報処理装置に転送することができない場合、前記要求を前記プロセッサに出力し、
前記プロセッサが、前記管理プロセッサから受け取った前記要求を、前記プロセッサと前記他の情報処理装置におけるプロセッサとの通信用の伝送路である第２の伝送路を使用して、前記他の情報処理装置に転送する
処理を実行する制御方法。
【請求項６】
第１の管理プロセッサと第１のプロセッサとを有する第１の情報処理装置と、
第２の管理プロセッサと第２のプロセッサとを有する第２の情報処理装置と、
を有し、
前記第１の管理プロセッサが、
前記第２の情報処理装置内のハードウエアへのアクセスの要求を、前記第１の管理プロセッサと前記第２の管理プロセッサとの通信用の伝送路である第１の伝送路を使用して前記第２の情報処理装置に転送することができない場合、前記要求を前記第１のプロセッサに出力し、
前記第１のプロセッサが、
前記第１の管理プロセッサから受け取った前記要求を、前記第１のプロセッサと前記第２のプロセッサとの通信用の伝送路である第２の伝送路を使用して、前記第２の情報処理装置に転送する
ことを特徴とする情報処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータシステム内のハードウエアの監視及び制御技術に関する。
【背景技術】
【０００２】
コンピュータシステムには、コンピュータシステム内のハードウエアを監視及び制御するための機構（以下、管理機構と呼ぶ）が設けられる。このような管理機構の一例として、サービスプロセッサが知られている。サービスプロセッサは、ＣＰＵ（Central Processing Unit）及びメモリ等を含む独立した処理ユニットであり、コンピュータシステム内の種々の部品（例えば、サービス提供用のＣＰＵ、メモリ、ＨＤＤ（Hard Disk Drive）或いはＳＳＤ（Solid State Drive）、冷却ファン、及び温度センサ等）の監視及び制御を行う。
【０００３】
上記のような管理機構は、コンピュータシステム内のハードウエアの異常を検出すると、ハードウエアの再起動を実行したり、コンピュータシステムの管理者による対処を促すためにアラームを出力する等の処理を行う。従って、管理機構がダウンすると、ハードウエアの異常に対処することができなくなり、最悪の場合にはコンピュータシステムが停止する。このような事態が生じないようにするためには、管理機構の可用性を高め、管理機構による処理が停止しないようにすることが好ましい。
【０００４】
可用性の向上に関する技術として、冗長化が知られている。冗長化とは、コンピュータシステムにおける機器やネットワークの障害に備え、予備の部品等を追加して多重化を図ることである。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開昭６０−７４１００号公報
【特許文献２】特開平８−１２５６２２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかし、冗長化を行うのが好ましくない場合が存在する。例えば、ビルディングブロック方式によって構築されたコンピュータシステムについては、可用性の向上を目的として管理機構の冗長化を行うのは適切ではない。
【０００７】
ビルディングブロック方式とは、各々が単一のコンピュータとして動作することができる複数の筐体を連結することで１台のコンピュータシステムを構築する技術である。ビルディングブロック方式においては、各筐体に管理機構が搭載される場合がある。従って、ビルディングブロック方式によって構築されたコンピュータシステムについて、各筐体における管理機構の冗長化、及び、筐体間の接続の冗長化等を行うと、コスト及び実装面積（或いは筐体のサイズ）が現実的ではなくなる。
【０００８】
従って、本発明の目的は、１つの側面では、コンピュータシステム内のハードウエアを監視及び制御する機構の可用性を向上するための技術を提供することである。
【課題を解決するための手段】
【０００９】
本発明に係る情報処理装置は、管理プロセッサと、プロセッサとを有する。そして、上で述べた管理プロセッサが、他の情報処理装置内のハードウエアへのアクセスの要求を、管理プロセッサと他の情報処理装置における管理プロセッサとの通信用の伝送路である第１の伝送路を使用して他の情報処理装置に転送することができない場合、要求をプロセッサに出力し、プロセッサが、管理プロセッサから受け取った要求を、プロセッサと他の情報処理装置におけるプロセッサとの通信用の伝送路である第２の伝送路を使用して、他の情報処理装置に転送する。
【発明の効果】
【００１０】
１つの側面では、コンピュータシステム内のハードウエアを監視及び制御する機構の可用性を向上できるようになる。
【図面の簡単な説明】
【００１１】
【図１】図１は、本実施の形態におけるコンピュータシステムの概要を示す図である。
【図２】図２は、ソフトウエアの機能ブロック図である。
【図３】図３は、ファームウエアの機能ブロック図である。
【図４】図４は、転送テーブルの一例を示す図である。
【図５】図５は、エージェント及びファームウエアの状態遷移図である。
【図６】図６は、イベントと状態との関係を示す図である。
【図７】図７は、ディスクリプタの構造の一例を示す図である。
【図８】図８は、ディスクリプタにおけるデータ部の一例を示す図である。
【図９】図９は、ファームウエアに異常が発生していない場合におけるハードウエアの監視及び制御について説明するための図である。
【図１０】図１０は、ファームウエアに異常が発生した場合におけるハードウエアの監視及び制御について説明するための図である。
【図１１】図１１は、ファームウエアに異常が発生していない場合におけるハードウエアの監視及び制御のシーケンス図である。
【図１２】図１２は、ファームウエアに異常が発生した場合におけるハードウエアの監視及び制御のシーケンス図である。
【図１３】図１３は、マスタのファームウエアにより生成された要求を転送する処理の処理フローを示す図である。
【図１４】図１４は、マスタのファームウエアにより生成された要求を転送する処理の処理フローを示す図である。
【図１５】図１５は、ハードウエアへのアクセスの要求を生成したマスタのファームウエアが実行する処理の処理フローを示す図である。
【図１６】図１６は、要求のフォーマットの一例を示す図である。
【図１７】図１７は、実際に転送される要求の一例を示す図である。
【図１８】図１８は、転送フレームを受信したエージェントが実行する処理の処理フローを示す図である。
【図１９】図１９は、応答のフォーマットの一例を示す図である。
【図２０】図２０は、実際に転送される応答の一例を示す図である。
【図２１】図２１は、要求を受け取った処理部が実行する処理の処理フローを示す図である。
【図２２】図２２は、アクセス処理の処理フローを示す図である。
【図２３】図２３は、ディスクリプタ制御処理の処理フローを示す図である。
【図２４】図２４は、応答を受け取ったファームウエアによる転送処理の処理フローを示す図である。
【図２５】図２５は、コマンドキューの構造の一例を示す図である。
【図２６】図２６は、要求を受信したエージェントがコマンドキューを用いて実行する処理の処理フローを示す図である。
【図２７】図２７は、応答を受信したエージェントがコマンドキューを用いて実行する処理の処理フローを示す図である。
【図２８】図２８は、転送テーブルの内容が変化した際にエージェントが実行する処理の処理フローを示す図である。
【発明を実施するための形態】
【００１２】
図１に、本実施の形態におけるコンピュータシステムの概要を示す。本実施の形態におけるコンピュータシステムは、筐体＃０乃至＃Ｎ（Ｎは自然数）を連結することにより実現される。図１においては、紙面の都合上筐体の数は２であるが、数に限定は無い。
【００１３】
筐体＃０は、論理ドメイン（仮想マシンとも呼ばれる）用ハードウエア２００と、ＦＰＧＡ（Field Programmable Gate Array）３００と、サービスプロセッサ４００と、共通ハードウエア６００とを有する。
【００１４】
論理ドメイン用ハードウエア２００は、ＣＰＵ２０１と、メモリ２０２と、Ｉ／Ｏ（Input Output）２０３とを有する。論理ドメイン用ハードウエア２００は、他の筐体（例えば筐体＃１）における論理ドメイン用ハードウエア（例えば論理ドメイン用ハードウエア２１０）に、専用の伝送路７０１（例えばバス）によって接続される。
【００１５】
ソフトウエア１００は、論理ドメイン用ハードウエア２００におけるＣＰＵ２０１により実行され、図２に示すような各種機能を実現する。具体的には、ソフトウエア１００の実行により、アプリケーション１０１と、ＯＳ（Operating System）１０２と、例えばハイパバイザ（Hypervisor）である仮想化ソフトウエア１０３とが実現される。仮想化ソフトウエア１０３は、エージェント１０４を含む。エージェント１０４は、転送部１０４１と、状態通知部１０４２とを含む。転送部１０４１は、転送フレーム（本実施の形態においては、要求及び応答）を転送する処理を実行する。状態通知部１０４２は、エージェントの状態に関する情報を他の筐体のエージェントとの間で交換し、メモリ２０２に格納された転送テーブルを更新する。
【００１６】
図１の説明に戻り、ＦＰＧＡ３００は、メモリ３０１と、処理部３０２とを有する。メモリ３０１には、ハードウエア（例えば、論理ドメイン用ハードウエア２００或いは共通ハードウエア６００）にアクセスする際に使用される命令及び制御データが、ディスクリプタとしてファームウエア５００及びエージェント１０４によって格納される。処理部３０２は、メモリ３０１に格納されたディスクリプタに基づき、ハードウエアに対するアクセスを行う。ＦＰＧＡ３００は、他の筐体（例えば筐体＃１）におけるＦＰＧＡ（例えばＦＰＧＡ３１０）に、専用の伝送路７０２（例えばバス）によって接続される。また、ＦＰＧＡ３００は、論理ドメイン用ハードウエア２００、サービスプロセッサ４００、及び共通ハードウエア６００にバスによって接続される。
【００１７】
サービスプロセッサ４００は、ＣＰＵ４０１と、メモリ４０２と、Ｉ／Ｏ（Input Output）４０３とを有する。サービスプロセッサ４００は、他の筐体（例えば筐体＃１）におけるサービスプロセッサ（例えばサービスプロセッサ４１０）に、専用の伝送路７０３（例えばバス）によって接続される。
【００１８】
ファームウエア５００は、サービスプロセッサ４００におけるＣＰＵ４０１により実行され、図３に示すような各種機能を実現する。具体的には、ファームウエア５００の実行により、第１処理部５０１と、第２処理部５０２とが実現される。第１処理部５０１は、複数の筐体におけるハードウエアを監視及び制御するための要求を出力する処理等を実行する。第２処理部５０２は、ファームウエアの状態に関する情報を他の筐体におけるファームウエアとの間で交換し、メモリ４０２に格納された転送テーブルを更新する。なお、本実施の形態においては、複数の筐体のうちいずれかの筐体におけるファームウエアがマスタのファームウエアとなり、残りの筐体におけるファームウエアがスレーブのファームウエアとなる。マスタのファームウエアは、マスタのファームウエアが実行される筐体内のハードウエアだけでなく、スレーブのファームウエアが実行される筐体内のハードウエアの監視及び制御をも行う。詳細については後述する。
【００１９】
共通ハードウエア６００は、ＰＳＵ（Power Supply Unit）６０１と、ファン６０２とを有する。ＰＳＵ６０１は、筐体＃０内のハードウエアに電力を供給する。ファン６０２は、送風によって筐体＃０の冷却を行う。
【００２０】
図４に、メモリ２０２に格納される転送テーブル及びメモリ４０２に格納される転送テーブルの一例を示す。図４の例では、筐体番号と、エージェント１０４の状態を表す情報と、ファームウエア５００の状態を表す情報と、タイムアウトまでの時間を表す情報とが格納される。状態通知部１０４２は、メモリ２０２に格納される転送テーブルを更新するとともに、エージェントの状態に関する情報を第２処理部５０２に通知する。第２処理部５０２は、メモリ４０２に格納される転送テーブルを更新するとともに、ファームウエアの状態に関する情報を状態通知部１０４２に通知する。これにより、メモリ２０２に格納される転送テーブルの内容とメモリ４０２に格納される転送テーブルの内容とが同じになる。
【００２１】
図５に、エージェント１０４及びファームウエア５００の状態遷移図を示す。図５に示したように、エージェント１０４及びファームウエア５００の状態には、稼働と、通信異常と、起動と、シャットダウンと、停止とが有る。これらの状態は、図６に示したイベントを契機として他の状態に遷移する。例えば、元の状態が停止である場合においてイベント「起動開始」が発生（例えば、管理者により起動指示が入力された）場合、状態は停止から起動に遷移する。また、例えば、元の状態が稼働である場合においてイベント「通信不可」が発生（例えば、通信経路に異常が発生した）場合、状態は稼働から通信異常に遷移する。
【００２２】
図７に、メモリ３０１に格納されるディスクリプタの構造の一例を示す。図７に示すように、ディスクリプタは、命令部と、データ部とを含む。命令部は、バスタイプ（すなわちプロトコル）を表す情報と、命令と、制御データの位置を表すデータオフセットとを含む。１つの命令についてのデータ長は１６バイトである。データ部は、１６バイト以下の制御データを含む。命令部におけるデータオフセットを参照することによって、データ部における制御データにアクセスすることができる。
【００２３】
図８に、ディスクリプタにおけるデータ部のフォーマット一例を示す。図８においては、Ｉ２Ｃ（Inter-Integrated Circuit）の読み出し命令及び書き込み命令についてのフォーマットと、ＧＰＩＯ（General Purpose Input/Output）の読み出し命令についてのフォーマットと、ＧＰＩＯの書き込み命令についてのフォーマットと、ＲＡＷ（Read After Write）の読み出し命令についてのフォーマットと、ＲＡＷの書き込み命令についてのフォーマットとが示されている。Ｉ２Ｃの読み出し命令及び書き込み命令については、データ部は、コントローラ番号と、アドレスと、データ長と、データ（但し、書き込みの場合のみ）とを含む。ＧＰＩＯ（General Purpose Input/Output）の読み出し命令については、データ部は、アドレスオフセットと、バイトマスクとを含む。ＧＰＩＯの書き込み命令については、データ部は、アドレスオフセットと、バイトマスクと、データ（但し、データ長は８バイト以下）とを含む。ＲＡＷの読み出し命令については、データ部は、アドレスオフセットと、データ長とを含む。ＲＡＷの書き込み命令については、データ部は、アドレスオフセットと、データ長と、データとを含む。
【００２４】
なお、筐体＃１のハードウエア構成は筐体＃０のハードウエア構成と同じであるので、筐体＃１のハードウエア構成についての説明は省略する。また、筐体＃１のソフトウエア１１０及びファームウエア５１０の機能は筐体＃０のソフトウエア１００及びファームウエア５００の機能と同じであるので、筐体＃１のソフトウエア１１０及びファームウエア５１０の機能についての説明は省略する。
【００２５】
次に、図９乃至図１４を用いて、本実施の形態におけるコンピュータシステムにおいて行われる処理の概要について説明する。ここでは、筐体＃０のファームウエア５００がマスタのファームウエアであり、筐体＃１のファームウエア５１０がスレーブのファームウエアであるとする。
【００２６】
図９に示した模式図を用いて、ファームウエアに異常が発生していない場合におけるハードウエアの監視及び制御について説明する。ファームウエア５００は、ファームウエア５１０に対し、筐体＃１内のハードウエアへのアクセスの要求を送信する。この際、利用される伝送路は伝送路７０３である。要求を受信したファームウエア５１０は、処理部３１２にハードウエアへのアクセスを実行させる。ファームウエア５１０は、処理部３１２による筐体＃１内のハードウエアへのアクセスが完了すると、要求に対する応答をファームウエア５００に伝送路７０３を介して送信する。このように、いずれのファームウエアにも異常が発生していなければファームウエア間の通信経路である伝送路７０３を利用してハードウエアへのアクセスが行われる。
【００２７】
図１０に示した模式図を用いて、ファームウエアに異常が発生した場合におけるハードウエアの監視及び制御について説明する。ファームウエア５００は、ファームウエア５１０に異常が発生し伝送路７０３を利用できないことを確認すると、筐体＃１内のハードウエアへのアクセスの要求を論理ドメイン（具体的には、エージェント１０４）に出力する。論理ドメインは、ファームウエア５００から要求を受け取ると、伝送路７０１を介して筐体＃１の論理ドメインに転送する。筐体＃１の論理ドメインは、筐体＃０から要求を受信すると、処理部３１２にハードウエアへのアクセスを実行させる。筐体＃１の論理ドメインは、処理部３１２による筐体＃１内のハードウエアへのアクセスが完了すると、要求に対する応答を筐体＃０の論理ドメインに伝送路７０１を介して送信する。筐体＃０の論理ドメインは、筐体＃１から応答を受信すると、ファームウエア５００に出力する。このように、いずれかのファームウエアに異常が発生した場合には、ファームウエア間の通信経路である伝送路７０３を利用せず、迂回経路である伝送路７０１を利用してハードウエアへのアクセスを行う。
【００２８】
図１１に、ファームウエアに異常が発生していない場合におけるハードウエアの監視及び制御のシーケンス図を示す。マスタのファームウエア５００は、ハードウエアへのアクセスの要求（以下、実行要求と呼ぶ）をスレーブのファームウエア５１０に伝送路７０３を介して送信する。スレーブのファームウエア５１０は、実行要求をマスタのファームウエア５００から受信すると、実行要求に基づき、処理部３１２に実行指示を出力する。実行指示を受け付けた処理部３１２は、ハードウエアへのアクセスを実行し、ハードウエアへのアクセスが完了したことを示す応答（以下、完了応答と呼ぶ）をスレーブのファームウエア５１０に出力する。スレーブのファームウエア５１０は、完了応答を処理部３１２から受け取ると、伝送路７０３を介してマスタのファームウエア５００に転送する。
【００２９】
マスタのファームウエア５００は、完了応答をスレーブのファームウエア５１０から受信した後、ハードウエアアクセスの結果の要求（以下、結果要求と呼ぶ）をスレーブのファームウエア５１０に送信する。スレーブのファームウエア５１０は、結果要求を受信すると、結果要求に基づき、実行指示を処理部３１２に出力する。実行指示を受け付けた処理部３１２は、ハードウエアへのアクセスの結果を表す応答（以下、結果応答と呼ぶ）を生成し、スレーブのファームウエア５１０に出力する。スレーブのファームウエア５１０は、結果応答を処理部３１２から受け取ると、伝送路７０３を介してマスタのファームウエア５００に転送する。
【００３０】
図１２に、ファームウエアに異常が発生した場合におけるハードウエアの監視及び制御のシーケンス図を示す。マスタのファームウエア５００は、ファームウエア５１０に異常が発生し伝送路７０３を利用できないことを検出すると、実行要求を筐体＃０のエージェント１０４に出力する。筐体＃０のエージェント１０４は、実行要求をファームウエア５００から受け取ると、伝送路７０１を介して筐体＃１のエージェントに転送する。筐体＃１のエージェントは、実行要求に基づき、実行指示を処理部３１２に出力する。実行指示を受け付けた処理部３１２は、ハードウエアへのアクセスを実行し、完了応答を筐体＃１のエージェントに出力する。筐体＃１のエージェントは、完了応答を処理部３１２から受け取ると、伝送路７０１を介して筐体＃０のエージェント１０４に転送する。筐体＃０のエージェント１０４は、完了応答を筐体＃１から受信すると、マスタのファームウエア５００に転送する。
【００３１】
マスタのファームウエア５００は、完了応答を筐体＃０のエージェント１０４から受信した後、ハードウエアアクセスの結果の要求（以下、結果要求と呼ぶ）を筐体＃０のエージェント１０４に送信する。筐体＃０のエージェント１０４は、結果要求をファームウエア５００から受け取ると、伝送路７０１を介して筐体＃１のエージェントに転送する。筐体＃１のエージェントは、結果要求に基づき、実行指示を処理部３１２に出力する。実行指示を受け付けた処理部３１２は、結果応答を生成し、結果応答を筐体＃１のエージェントに出力する。筐体＃１のエージェントは、結果応答を処理部３１２から受け取ると、伝送路７０１を介して筐体＃０のエージェント１０４に転送する。筐体＃０のエージェント１０４は、結果応答を筐体＃１から受信すると、マスタのファームウエア５００に転送する。
【００３２】
図１３及び図１４を用いて、マスタのファームウエアにより生成された要求の転送について説明する。まず、筐体＃０におけるマスタのファームウエア５００は、ハードウエアへのアクセスの要求を生成する（図１３：ステップＳ１３０１）。
【００３３】
ファームウエア５００は、生成された要求が自筐体宛であるか判断する（ステップＳ１３０２）。生成された要求が自筐体宛である場合（ステップＳ１３０２：Ｙｅｓルート）、処理は端子Ａを介して図１４のステップＳ１４０１に移行する。
【００３４】
一方、生成された要求が自筐体宛ではない場合（ステップＳ１３０２：Ｎｏルート）、ファームウエア５００は、メモリ４０２に格納された転送テーブルに基づき、他筐体（ここでは、宛先の筐体である筐体＃１）のファームウエアが稼働しているか判断する（ステップＳ１３０３）。
【００３５】
他筐体のファームウエアが稼働している場合（ステップＳ１３０３：Ｙｅｓルート）、ファームウエア５００は、要求を伝送路７０３を使用して筐体＃１に転送する（ステップＳ１３０４）。筐体＃１のファームウエア５１０は、筐体＃０から要求を受信する（ステップＳ１３０５）。処理は端子Ｂを介して図１４のステップＳ１４０４に移行する。
【００３６】
一方、他筐体のファームウエアが稼働していない場合（ステップＳ１３０３：Ｎｏルート）、ファームウエア５００は、エージェント１０４に要求を出力する。そして、エージェント１０４は、ファームウエア５００から受け取った要求を筐体＃１のエージェントに伝送路７０１を使用して転送する（ステップＳ１３０６）。筐体＃１のエージェントは、筐体＃０から要求を受信する（ステップＳ１３０７）。処理は端子Ｃを介して図１４のステップＳ１４０６に移行する。
【００３７】
端子Ａ以降の説明に移行し、ファームウエア５００は、要求に含まれる命令及び制御データ等をメモリ３０１にディスクリプタとして書き込む（ステップＳ１４０１）。また、ファームウエア５００は、実行指示を処理部３０２に出力する（ステップＳ１４０２）。これに応じ、処理部３０２は、メモリ３０１からディスクリプタを読み出し、ディスクリプタに基づきハードウエアへのアクセスを行う（ステップＳ１４０３）。
【００３８】
端子Ｂ以降の説明に移行し、ファームウエア５１０は、要求に含まれる命令及び制御データ等をメモリ３１１にディスクリプタとして書き込む（ステップＳ１４０４）。また、ファームウエア５１０は、実行指示を処理部３１２に出力する（ステップＳ１４０５）。これに応じ、処理部３１２は、メモリ３１１からディスクリプタを読み出し、ディスクリプタに基づきハードウエアへのアクセスを行う（ステップＳ１４０８）。
【００３９】
端子Ｃ以降の説明に移行し、エージェントは、要求に含まれる命令及び制御データ等をメモリ３１１にディスクリプタとして書き込む（ステップＳ１４０６）。また、エージェントは、実行指示を処理部３１２に出力する（ステップＳ１４０７）。これに応じ、処理部３１２は、メモリ３１１からディスクリプタを読み出し、ディスクリプタに基づきハードウエアへのアクセスを行う（ステップＳ１４０８）。
【００４０】
以上述べたように、いずれかの筐体でファームウエアが停止し、ファームウエア間の伝送路を使用できない場合には、論理ドメイン間の伝送路を利用してその筐体のハードウエアにアクセスできる。これにより、ファームウエアによるハードウエアの監視及び制御の可用性を高めることができるようになる。
【００４１】
また、要求をマスタファームウエアが生成するので、エージェントは要求の生成を担当せず、要求の転送を担当すればよい。これにより、ハードウエアが改版されたとしても、エージェントに対する改変は不要になるので、論理ドメインにより提供される顧客サービスに影響が及ぶことがない。
【００４２】
また、ハードウエアへの最終的なアクセスを処理部が担当するので、何らかの理由によって論理ドメインが停止したとしても、ハードウエアの監視及び制御を停止せずに済む。
【００４３】
また、ファームウエアに異常が発生したか否かに関わらず、ハードウエアへの最終的なアクセスを処理部が担当するので、経路制御の共通化及び転送処理の簡素化を実現することができる。
【００４４】
次に、図１５乃至図２８を用いて、本実施の形態におけるコンピュータシステムにおいて行われる処理を詳細に説明する。まず、図１５乃至図１７を用いて、ハードウエアへのアクセスの要求を生成したマスタのファームウエア５００が実行する処理について説明する。
【００４５】
ファームウエア５００における第１処理部５０１は、要求に含まれる情報（具体的には、要求先筐体番号）に基づき、要求の転送先が自筐体であるか判断する（図１５：ステップＳ１）。
【００４６】
図１６に、要求のフォーマットの一例を示す。図１６の例では、最初の１６バイトに、要求元筐体番号のフィールドと、要求元ノード種別のフィールドと、要求先筐体番号のフィールドと、要求先ノード種別のフィールドと、要求元時刻（ここでは、要求が生成された時刻）のフィールドと、要求シーケンス番号のフィールドと、命令数のフィールドとが含まれる。次の１６バイトは、応答に関する情報が設定されるフィールドであるので、ここでは０が設定される。３３バイト目以降は、８バイト毎に、バスタイプ（すなわちプロトコル）及び命令と、制御データサイズと、制御データオフセットとが設定される。そして、例えば命令数がＮ（Ｎは自然数）である場合、８Ｎ＋０ｘ２０バイト目以降に、１６バイト毎に、制御データが設定される。
【００４７】
図１７に、実際に転送される要求の一例を示す。図１７の例では、要求元筐体番号のフィールドに０ｘ００が設定されており、これは筐体＃０であることを表す。要求元ノード種別のフィールドには０ｘ００が設定されており、これはファームウエアであることを表す。要求先筐体番号のフィールドには０ｘ０１が設定されており、これは筐体＃１であることを表す。要求先ノード種別には０ｘ２０が設定されており、これはハードウエアであることを表す。要求元時刻のフィールドには０ｘ５１ａ８４５２ｅが設定されており、これは２０１３年５月３１日６時３７分３４秒であることを表す。要求シーケンス番号のフィールドには０ｘ４３２１が設定されている。命令数のフィールドには０ｘ０３が設定されており、これは命令の数が３であることを表す。これ以降、３つの命令のそれぞれに対応する制御データが設定される。
【００４８】
図１５の説明に戻り、要求の転送先が自筐体である場合（ステップＳ１：Ｙｅｓルート）、第１処理部５０１は、要求に含まれる命令及び制御データ等をディスクリプタとしてメモリ（ここでは、メモリ３０１）に格納する（ステップＳ３）。
【００４９】
第１処理部５０１は、ハードウエアアクセスの実行指示を処理部３０２に出力する（ステップＳ５）。実行指示を受け付けた処理部３０２が実行する処理については、後で説明する。そして処理を終了する。
【００５０】
一方、要求の転送先が自筐体ではない場合（ステップＳ１：Ｎｏルート）、第１処理部５０１は、転送先の筐体のファームウエア（ここでは、ファームウエア５１０とする）が稼働しているか否かを、メモリ４０２に格納された転送テーブルに基づき判断する（ステップＳ７）。
【００５１】
転送先の筐体のファームウエア５１０が稼働している場合（ステップＳ７：Ｙｅｓルート）、第１処理部５０１は、要求を転送先の筐体のファームウエア５１０に、伝送路７０３を使用して転送する（ステップＳ９）。そして処理を終了する。
【００５２】
一方、転送先の筐体のファームウエア５１０が稼働していない場合（ステップＳ７：Ｎｏルート）、第１処理部５０１は、要求をエージェント１０４に出力する（ステップＳ１１）。要求を受け取ったエージェント１０４が実行する処理については、後で説明する。そして処理を終了する。
【００５３】
以上のような処理を実行すれば、転送先の筐体のファームウエア５１０が稼働していない場合においては、ファームウエア間通信に使用する伝送路とは異なる伝送路を使用して要求を転送できるようになる。
【００５４】
次に、図１８乃至図２０を用いて、エージェントが転送フレーム（すなわち、要求又は応答）を受信した際に実行する処理について説明する。
【００５５】
まず、エージェント（ここでは、エージェント１０４とする）の転送部１０４１は、転送フレームの転送先が自筐体であるか判断する（図１８：ステップＳ２１）。
【００５６】
図１９に、応答のフォーマットの一例を示す。図１９の例では、最初の１６バイトには、応答に対応する要求と同じ情報が設定される。次の１６バイトには、応答に関する情報が設定される。具体的には、応答元筐体番号のフィールドと、応答元ノード種別のフィールドと、応答先筐体番号のフィールドと、応答先ノード種別のフィールドと、応答元時刻（ここでは、応答が生成された時刻）のフィールドと、応答シーケンス番号のフィールドと、応答データサイズのフィールドとが含まれる。３３バイト目以降は、応答データが格納される。
【００５７】
図２０に、実際に転送される応答の一例を示す。図２０の例では、応答元筐体番号のフィールドに０ｘ０１が設定されており、これは筐体＃１であることを表す。応答元ノード種別のフィールドには０ｘ２０が設定されており、これはハードウエアであることを表す。応答先筐体番号のフィールドには０ｘ００が設定されており、これは筐体＃０であることを表す。応答先ノード種別には０ｘ００が設定されており、これはファームウエアであることを表す。応答元時刻のフィールドには０ｘ５１ａ８４５３ｅが設定されており、これは２０１３年５月３１日６時３７分５０秒であることを表す。応答シーケンス番号のフィールドには０ｘ９８７５が設定されている。応答データサイズのフィールドには０ｘ０２が設定されており、これは２バイトであることを表す。これ以降、応答データが設定される。
【００５８】
ステップＳ２１においては、応答に関する情報が転送フレームに設定されていない場合、転送先として要求先が特定される。応答に関する情報が転送フレームに設定されている場合、転送先として応答先が特定される。
【００５９】
図１８の説明に戻り、転送フレームの転送先が自筐体である場合（ステップＳ２１：Ｙｅｓルート）、転送部１０４１は、転送先がファームウエアであるか判断する（ステップＳ２３）。
【００６０】
転送フレームの転送先がファームウエアである場合（ステップＳ２３：Ｙｅｓルート）、転送フレームは応答である。従って、転送部１０４１は、転送フレームをファームウエア５００に転送する（ステップＳ２９）。そして処理を終了する。
【００６１】
一方、転送フレームの転送先がファームウエアではない場合（ステップＳ２３：Ｎｏルート）、転送フレームは要求である。従って、転送部１０４１は、転送フレームに含まれる命令及び制御データ等をディスクリプタとしてメモリ３０１に格納する（ステップＳ２５）。
【００６２】
転送部１０４１は、ハードウエアへのアクセスの実行指示を処理部３０２に出力する（ステップＳ２７）。そして処理を終了する。なお、ファームウエア５００がマスタである場合には転送部１０４１がステップＳ２５及びＳ２７の処理を実行することはない。しかし、ファームウエア５００がマスタではない場合もあるので、ここでは念のためステップＳ２５及びＳ２７の説明を行った。
【００６３】
一方、転送フレームの転送先が自筐体ではない場合（ステップＳ２１：Ｎｏルート）、転送フレームの転送先はエージェント（ここでは、筐体＃１のエージェントとする）である。従って、転送部１０４１は、転送先のエージェントが稼働しているか否かを、メモリ２０２に格納された転送テーブルに基づき判断する（ステップＳ３１）。
【００６４】
転送先のエージェントは稼働している場合（ステップＳ３１：Ｙｅｓルート）、転送部１０４１は、伝送路７０１を使用して転送フレームを転送先のエージェントに転送する（ステップＳ３３）。そして処理を終了する。
【００６５】
転送先のエージェントは稼働していない場合（ステップＳ３１：Ｎｏルート）、転送部１０４１は、タイムアウトであるか判断する。なお、タイムアウトの時間は転送テーブルに格納されている。タイムアウトではない場合（すなわち、筐体＃１のエージェントの状態が稼働中になった場合）、転送部１０４１は、伝送路７０１を使用して転送フレームを転送先のエージェントに転送する。タイムアウトである場合、転送部１０４１は、転送フレームの転送元に、エラーを示す応答を転送する（ステップＳ３５）。そして処理を終了する。
【００６６】
以上のような処理を実行すれば、論理ドメイン間の通信に使用する伝送路を迂回路として使用して、ハードウエアの監視及び制御を行えるようになる。
【００６７】
次に、図２１乃至図２３を用いて、要求を受け取った処理部が実行する処理について説明する。
【００６８】
まず、処理部（ここでは、処理部３１２とする）は、アクセス処理を実行する（図２１：ステップＳ４１）。アクセス処理については、図２２及び図２３を用いて説明する。
【００６９】
まず、処理部３１２は、メモリ３１１に格納されたディスクリプタから未処理の命令を１つ特定し、その命令のバスタイプを特定する（図２２：ステップＳ５１）。
【００７０】
処理部３１２は、ステップＳ５１において特定されたバスタイプがＩ２Ｃであるか判断する（ステップＳ５３）。バスタイプがＩ２Ｃである場合（ステップＳ５３：Ｙｅｓルート）、処理部３１２は、Ｉ２Ｃの命令を実行し（ステップＳ５５）、ハードウエアへのアクセスを行う。そしてステップＳ６７に移行する。
【００７１】
バスタイプがＩ２Ｃではない場合（ステップＳ５３：Ｎｏルート）、処理部３１２は、ステップＳ５１において特定されたバスタイプがＧＰＩＯであるか判断する（ステップＳ５７）。バスタイプがＧＰＩＯである場合（ステップＳ５７：Ｙｅｓルート）、処理部３１２は、ＧＰＩＯの命令を実行し（ステップＳ５９）、ハードウエアへのアクセスを行う。そしてステップＳ６７に移行する。
【００７２】
バスタイプがＧＰＩＯではない場合（ステップＳ５７：Ｎｏルート）、処理部３１２は、ステップＳ５１において特定されたバスタイプがＲＡＷであるか判断する（ステップＳ６１）。バスタイプがＲＡＷである場合（ステップＳ６１：Ｙｅｓルート）、処理部３１２は、ＲＡＷの命令を実行し（ステップＳ６５）、ハードウエアへのアクセスを行う。そしてステップＳ６７に移行する。
【００７３】
バスタイプがＲＡＷではない場合（ステップＳ６１：Ｎｏルート）、命令はディスクリプタ制御に関する命令である。従って、処理部３１２は、ディスクリプタ制御処理を実行する（ステップＳ６３）。ディスクリプタ制御処理については、図２３を用いて説明する。
【００７４】
まず、処理部３１２は、命令がＷａｉｔ命令であるか判断する（図２３：ステップＳ７１）。Ｗａｉｔ命令とは、処理部３１２が一定時間待機することで次の命令を実行するまでの時間を確保するための命令であり、パラメタは時間（マイクロ秒）である。命令がＷａｉｔ命令である場合（ステップＳ７１：Ｙｅｓルート）、処理部３１２は一定時間待機する（ステップＳ７３）。そして呼び出し元の処理に戻る。
【００７５】
命令がＷａｉｔ命令でない場合（ステップＳ７１：Ｎｏルート）、処理部３１２は、命令がＴｉｍｅｒ命令であるか判断する（ステップＳ７５）。Ｔｉｍｅｒ命令とは、指定された時間が経過した場合に指定の命令オフセットから命令を実行するための命令であり、パラメタは時間（秒）及び命令オフセットである。命令がＴｉｍｅｒ命令である場合（ステップＳ７５：Ｙｅｓルート）、処理部３１２はタイマを起動し（ステップＳ７７）、タイムアウト後に指定の命令オフセットから命令を実行する。そして呼び出し元の処理に戻る。
【００７６】
命令がＴｉｍｅｒ命令でない場合（ステップＳ７５：Ｎｏルート）、処理部３１２は、命令が分岐命令であるか判断する（ステップＳ７９）。分岐命令とは、指定のデータオフセットの位置に格納された値が期待値と一致するか判定し、期待値と一致する場合に指定の命令オフセットから命令を実行するための命令であり、パラメタはデータオフセット、期待値及び命令オフセットである。他に、データマスク等もパラメタに含まれる場合がある。命令が分岐命令である場合（ステップＳ７９：Ｙｅｓルート）、処理部３１２は、データオフセットの位置に格納された値及び期待値に基づく判定の結果に応じ、命令オフセットから命令を実行する（ステップＳ８１）。そして呼び出し元の処理に戻る。
【００７７】
命令が分岐命令でない場合（ステップＳ７９：Ｎｏルート）、処理部３１２は、命令が応答命令であるか判断する（ステップＳ８３）。応答命令とは、要求の転送元に対して送信する応答を生成するための命令であり、パラメタはデータオフセット及びデータサイズである。命令が応答命令である場合（ステップＳ８３：Ｙｅｓルート）、処理部３１２は、応答を生成する（ステップＳ８５）。そして呼び出し元の処理に戻る。
【００７８】
命令が応答命令でない場合（ステップＳ８３：Ｎｏルート）、処理部３１２は、命令が終端命令であるか判断する（ステップＳ８７）。終端命令とは、ディスクリプタ内の命令列の実行を中断し、処理部３１２を待機状態にするための命令であり、パラメタは無い。命令が終端命令ではない場合（ステップＳ８７：Ｎｏルート）、処理部３１２は、エラーを示す応答を生成する（ステップＳ８９）。そして呼び出し元の処理に戻る。一方、命令が終端命令である場合（ステップＳ８７：Ｙｅｓルート）、処理は端子Ｄを介して図２１の処理に移行し終了する。
【００７９】
図２２の説明に戻り、処理部３１２は、未処理の命令が有るか判断する（ステップＳ６７）。未処理の命令が有る場合（ステップＳ６７：Ｙｅｓルート）、ステップＳ５１の処理に戻る。一方、未処理の命令が無い場合（ステップＳ６７：Ｎｏルート）、呼び出し元の処理に戻る。
【００８０】
図２１の説明に戻り、処理部３１２は、処理部３１２に要求を出力したノード（ここでは、筐体＃１のファームウエア５１０或いは筐体＃１のエージェント）に、要求に対応する応答を出力する（ステップＳ４３）。そして処理を終了する。
【００８１】
以上のような処理を実行すれば、ファームウエアにより生成された要求の処理を、処理部が適切に行えるようになる。なお、上に示したバスタイプは一例であり、他のバスタイプであってもよい。また、命令の種類は、上に示した命令の種類に限られるわけではない。
【００８２】
次に、図２４を用いて、応答を受け取ったファームウエアによる転送処理について説明する。
【００８３】
まず、応答を受け取ったファームウエアの第１処理部（ここでは、第１処理部５０１とする）は、応答の転送先が他筐体であるか判断する（図２４：ステップＳ９１）。
【００８４】
応答の転送先が他筐体ではない場合（ステップＳ９１：Ｎｏルート）、自ファームウエア宛の応答である。従って、第１処理部５０１は、応答の内容に応じて処理を実行する（ステップＳ９３）。そして処理を終了する。
【００８５】
応答の転送先が他筐体である場合（ステップＳ９１：Ｙｅｓルート）、第１処理部５０１は、転送先の筐体のファームウエア（ここでは、ファームウエア５１０とする）が稼働しているか否かを、メモリ４０２に格納された転送テーブルに基づき判断する（ステップＳ９５）。
【００８６】
転送先の筐体のファームウエアが稼働している場合（ステップＳ９５：Ｙｅｓルート）、第１処理部５０１は、応答を転送先の筐体のファームウエア５１０に伝送路７０３を使用して転送する（ステップＳ９７）。そして処理を終了する。
【００８７】
転送先の筐体のファームウエアが稼働していない場合（ステップＳ９５：Ｎｏルート）、第１処理部５０１は、応答をエージェント１０４に出力する（ステップＳ９９）。そして処理を終了する。
【００８８】
以上のような処理を実行すれば、要求を出力したファームウエアがその要求に対する応答を受け取ることができるようになる。
【００８９】
次に、図２５乃至図２８を用いて、エージェントがコマンドキューを用いて転送フレームを転送する処理について説明する。説明を簡単にするため上では述べなかったが、エージェントは、宛先となる筐体毎にコマンドキューを有しており、コマンドキューにその筐体宛の要求を格納する。
【００９０】
図２５に、コマンドキューの構造の一例を示す。図２５の例では、コマンドキューは、管理キュー域と、データキュー域とを有する。管理キュー域には、データキュー域において要求が格納されている位置を表すオフセットと、要求のサイズとが要求毎に格納されている。データキュー域には、各要求が格納される。図２５に示したようなコマンドキューが、宛先となる筐体毎に用意される。
【００９１】
図２６を用いて、要求を受信したエージェントがコマンドキューを用いて実行する処理について説明する。
【００９２】
まず、エージェント（ここでは、エージェント１０４とする）の転送部１０４１は、要求の転送先用のコマンドキューに空きが有るか判断する（図２６：ステップＳ１０１）。以下では、コマンドキューのことを単純にキューと呼ぶ。キューに空きが無い場合（ステップＳ１０１：Ｎｏルート）、転送部１０４１は、要求を処理できないことを示す応答を、要求の転送元に送信する（ステップＳ１０９）。そして処理を終了する。一方、キューに空きが有る場合（ステップＳ１０１：Ｙｅｓルート）、転送部１０４１は、要求をキューに格納する（ステップＳ１０３）。なお、キューに格納された要求は格納の順に処理される。
【００９３】
転送部１０４１は、応答待ちの要求がキューに有るか判断する（ステップＳ１０５）。応答待ちの要求とは、転送先に転送されたが、その要求に対する応答が返ってきていない要求のことである。ステップＳ１０５においては、例えば、要求が応答待ちであるか否かを表すフラグを各要求について確認することで、応答待ちの要求がキューに有るか判断する。
【００９４】
応答待ちの要求がキューに有る場合（ステップＳ１０５：Ｙｅｓルート）、処理を終了する。応答待ちの要求がキューに無い場合（ステップＳ１０５：Ｎｏルート）、転送部１０４１は、キューの先頭の要求のコピーを生成し、転送先に転送する（ステップＳ１０７）。ここで、応答待ちであることを表すフラグが設定される。そして処理を終了する。
【００９５】
以上のような処理を実行すれば、要求を新たに受信する度にキュー内の要求を処理できるようになる。
【００９６】
図２７を用いて、応答を受信したエージェントがコマンドキューを用いて実行する処理について説明する。
【００９７】
まず、エージェント（ここでは、エージェント１０４とする）の転送部１０４１は、受信した応答に対応する要求がキューの中に有るか判断する（図２７：ステップＳ１１１）。
【００９８】
応答に対応する要求がキューの中に無い場合（ステップＳ１１１：Ｎｏルート）、エラーが発生したので、転送部１０４１は、エラーを示す応答を要求の転送元に送信する（ステップＳ１１３）。そして処理を終了する。
【００９９】
一方、応答に対応する要求がキューの中に有る場合（ステップＳ１１１：Ｙｅｓルート）、転送部１０４１は、応答に対応する要求をキューから削除する（ステップＳ１１５）。
【０１００】
転送部１０４１は、要求の転送元（すなわち、応答の転送先）に対して、応答を転送する（ステップＳ１１７）。また、転送部１０４１は、キューの先頭の要求のコピーを生成し、転送先に転送する（ステップＳ１１９）。ここで、応答待ちであることを表すフラグが設定される。そして処理を終了する。
【０１０１】
以上のような処理を実行すれば、要求に対する応答が返ってきたか否かを確認できるようになる。また、応答を新たに受信する度にキュー内の要求を処理できるようになる。
【０１０２】
図２８を用いて、メモリ４０２に格納された転送テーブルの内容が変化した際にエージェントが実行する処理について説明する。
【０１０３】
まず、エージェント（ここでは、エージェント１０４とする）の転送部１０４１は、応答待ちの要求についてタイムアウトが発生した（要求の転送先に要求のコピーを転送した時点から所定の時間が経過した）か判断する（図２８：ステップＳ１２１）。タイムアウトの時間は、転送テーブルに格納されている。
【０１０４】
タイムアウトが発生していない場合（ステップＳ１２１：Ｎｏルート）、処理を終了する。一方、タイムアウトが発生した場合（ステップＳ１２１：Ｙｅｓルート）、転送部１０４１は、一定時間待機する（ステップＳ１２５）。
【０１０５】
一定時間待機した後、転送部１０４１は、タイムアウトが発生した要求に対応する応答を受信したか判断する（ステップＳ１２７）。応答を受信した場合（ステップＳ１２７：Ｙｅｓルート）、処理を終了する。この場合、例えば別スレッドによって、図２７を用いて説明した処理が実行されることになる。
【０１０６】
一方、応答を受信していない場合（ステップＳ１２７：Ｎｏルート）、転送部１０４１は、タイムアウトが発生した、応答待ちの要求をキューから削除する（ステップＳ１２９）。ここで、応答待ちであることを表すフラグは削除される。
【０１０７】
転送部１０４１は、タイムアウトが発生した要求の転送元に、タイムアウトが発生したことを示す応答を送信する（ステップＳ１３１）。そして処理を終了する。
【０１０８】
以上のような処理を実行すれば、応答が返ってこない要求がキュー内に蓄積することを回避できるようになる。
【０１０９】
以上本発明の一実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、上で説明した筐体＃０及び＃１並びにファームウエア５００及びソフトウエア１００の機能ブロック構成は実際のプログラムモジュール構成に一致しない場合もある。
【０１１０】
また、上で説明したデータ保持構成は一例であって、上記のような構成でなければならないわけではない。さらに、処理フローにおいても、処理結果が変わらなければ処理の順番を入れ替えることも可能である。さらに、並列に実行させるようにしても良い。
【０１１１】
なお、上ではファームウエア５００がマスタのファームウエアである例を示したが、どの筐体におけるファームウエアがマスタのファームウエアであってもよい。
【０１１２】
なお、上ではファームウエアの停止によってファームウエア間の伝送路７０３が使用できなくなる例を示したが、物理的な故障によって伝送路７０３が使用できなくなった場合にも本実施の形態によって対処することができる。
【０１１３】
なお、上ではエージェントをソフトウエアとして実装する例を示したが、論理ドメイン用ハードウエアの一部として実装してもよい。
【０１１４】
以上述べた本発明の実施の形態をまとめると、以下のようになる。
【０１１５】
本実施の形態の第１の態様に係る情報処理装置は、（Ａ）管理プロセッサと、（Ｂ）プロセッサとを有する。そして、上で述べた管理プロセッサが、（ａ１）他の情報処理装置内のハードウエアへのアクセスの要求を、管理プロセッサと他の情報処理装置における管理プロセッサとの通信用の伝送路である第１の伝送路を使用して他の情報処理装置に転送することができない場合、要求をプロセッサに出力し、プロセッサが、（ｂ１）管理プロセッサから受け取った要求を、プロセッサと他の情報処理装置におけるプロセッサとの通信用の伝送路である第２の伝送路を使用して、他の情報処理装置に転送する。
【０１１６】
このようにすれば、例えば他の情報処理装置における管理プロセッサが停止した場合においても、要求を他の情報処理装置に送り届けることができる。これにより、ハードウエアを監視及び制御する機構の可用性を向上させることができるようになる。
【０１１７】
また、本情報処理装置が、（Ｃ）情報処理装置内のハードウエアへのアクセスを行う処理部をさらに有してもよい。そして、上で述べた管理プロセッサは、（ａ２）情報処理装置内のハードウエアへのアクセスの要求を、処理部に出力し、上で述べたプロセッサは、（ｂ２）他の情報処理装置から情報処理装置内のハードウエアへのアクセスの要求を受信した場合、当該要求を処理部に出力し、上で述べた処理部は、（ｃ１）情報処理装置内のハードウエアへのアクセスの要求を管理プロセッサ又はプロセッサから受け取った場合、当該要求に基づき、情報処理装置内のハードウエアへのアクセスを行い、（ｃ２）情報処理装置内のハードウエアへのアクセスの要求に対する応答を生成し、要求の出力元に出力してもよい。このように、ハードウエアへのアクセスを行う処理部を設けることで、ハードウエアアクセスに関連する処理（例えば要求及び応答の転送）を簡素化することができるようになる。
【０１１８】
また、本情報処理装置が、（Ｄ）他の情報処理装置における管理プロセッサの状態を示す情報を記憶する記憶装置をさらに有してもよい。そして、上で述べた管理プロセッサは、（ａ３）第１の伝送路を介して他の情報処理装置における管理プロセッサと通信を行うことにより、他の情報処理装置における管理プロセッサの状態を特定し、（ａ４）特定された状態に基づき、記憶装置に記憶された情報を更新してもよい。このようにすれば、第１の伝送路を使用して他の情報処理装置に要求を転送できるか否か判断できるようになる。
【０１１９】
また、上で述べたプロセッサは、（ｂ３）要求に対する応答を他の情報処理装置から第２の伝送路を介して受信した場合、応答を管理プロセッサに出力してもよい。このようにすれば、管理プロセッサが他の情報処理装置内のハードウエアの異常を検出できるようになる。
【０１２０】
本実施の形態の第１の態様に係る制御方法は、管理プロセッサとプロセッサとを有するコンピュータにより実行される。そして、本制御方法は、（Ｅ）管理プロセッサが、他の情報処理装置内のハードウエアへのアクセスの要求を、管理プロセッサと他の情報処理装置における管理プロセッサとの通信用の伝送路である第１の伝送路を使用して他の情報処理装置に転送することができない場合、要求をプロセッサに出力し、（Ｆ）プロセッサが、管理プロセッサから受け取った要求を、プロセッサと他の情報処理装置におけるプロセッサとの通信用の伝送路である第２の伝送路を使用して、他の情報処理装置に転送する処理を含む。
【０１２１】
なお、上記方法による処理をプロセッサに行わせるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。尚、中間的な処理結果はメインメモリ等の記憶装置に一時保管される。
【０１２２】
以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。
【０１２３】
（付記１）
管理プロセッサと、
プロセッサと、
を有し、
前記管理プロセッサが、
他の情報処理装置内のハードウエアへのアクセスの要求を、前記管理プロセッサと前記他の情報処理装置における管理プロセッサとの通信用の伝送路である第１の伝送路を使用して前記他の情報処理装置に転送することができない場合、前記要求を前記プロセッサに出力し、
前記プロセッサが、
前記管理プロセッサから受け取った前記要求を、前記プロセッサと前記他の情報処理装置におけるプロセッサとの通信用の伝送路である第２の伝送路を使用して、前記他の情報処理装置に転送する
ことを特徴とする情報処理装置。
【０１２４】
（付記２）
前記情報処理装置内のハードウエアへのアクセスを行う処理部
をさらに有し、
前記管理プロセッサは、
前記情報処理装置内のハードウエアへのアクセスの要求を、前記処理部に出力し、
前記プロセッサは、
前記他の情報処理装置から前記情報処理装置内のハードウエアへのアクセスの要求を受信した場合、当該要求を前記処理部に出力し、
前記処理部は、
前記情報処理装置内のハードウエアへのアクセスの要求を前記管理プロセッサ又は前記プロセッサから受け取った場合、当該要求に基づき、前記情報処理装置内のハードウエアへのアクセスを行い、
前記情報処理装置内のハードウエアへのアクセスの要求に対する応答を生成し、前記要求の出力元に出力する
ことを特徴とする付記１記載の情報処理装置。
【０１２５】
（付記３）
前記他の情報処理装置における管理プロセッサの状態を示す情報を記憶する記憶装置
をさらに有し、
前記管理プロセッサは、
前記第１の伝送路を介して前記他の情報処理装置における管理プロセッサと通信を行うことにより、前記他の情報処理装置における管理プロセッサの状態を特定し、
特定された前記状態に基づき、前記記憶装置に記憶された情報を更新する
ことを特徴とする付記１又は２記載の情報処理装置。
【０１２６】
（付記４）
前記プロセッサは、
前記要求に対する応答を前記他の情報処理装置から前記第２の伝送路を介して受信した場合、前記応答を前記管理プロセッサに出力する
ことを特徴とする付記１乃至３のいずれか１つ記載の情報処理装置。
【０１２７】
（付記５）
管理プロセッサとプロセッサとを有するコンピュータにより実行される制御方法であって、
前記管理プロセッサが、他の情報処理装置内のハードウエアへのアクセスの要求を、前記管理プロセッサと前記他の情報処理装置における管理プロセッサとの通信用の伝送路である第１の伝送路を使用して前記他の情報処理装置に転送することができない場合、前記要求を前記プロセッサに出力し、
前記プロセッサが、前記管理プロセッサから受け取った前記要求を、前記プロセッサと前記他の情報処理装置におけるプロセッサとの通信用の伝送路である第２の伝送路を使用して、前記他の情報処理装置に転送する
処理を実行する制御方法。
【０１２８】
（付記６）
第１の管理プロセッサと第１のプロセッサとを有する第１の情報処理装置と、
第２の管理プロセッサと第２のプロセッサとを有する第２の情報処理装置と、
を有し、
前記第１の管理プロセッサが、
前記第２の情報処理装置内のハードウエアへのアクセスの要求を、前記第１の管理プロセッサと前記第２の管理プロセッサとの通信用の伝送路である第１の伝送路を使用して前記第２の情報処理装置に転送することができない場合、前記要求を前記第１のプロセッサに出力し、
前記第１のプロセッサが、
前記第１の管理プロセッサから受け取った前記要求を、前記第１のプロセッサと前記第２のプロセッサとの通信用の伝送路である第２の伝送路を使用して、前記第２の情報処理装置に転送する
ことを特徴とする情報処理システム。
【符号の説明】
【０１２９】
１００，１１０  ソフトウエア    １０１  アプリケーション
１０２  ＯＳ    １０３  仮想化ソフトウエア
１０４  エージェント    １０４１  転送部
１０４２  状態通知部    ２００，２１０  論理ドメイン用ハードウエア
２０１，２１１  ＣＰＵ    ２０２，２１２  メモリ
２０３，２１３  Ｉ／Ｏ    ３００，３１０  ＦＰＧＡ
３０１，３１１  メモリ    ３０２，３１２  処理部
４００，４１０  サービスプロセッサ    ４０１，４１１  ＣＰＵ
４０２，４１２  メモリ    ４０３，４１３  Ｉ／Ｏ
５００，５１０  ファームウエア    ５０１  第１処理部
５０２  第２処理部    ６００，６１０  共通ハードウエア
６０１，６１１  ＰＳＵ    ６０２，６１２  ファン
【図１】
0006402619.tif 000002
【図２】
0006402619.tif 000003
【図３】
0006402619.tif 000004
【図４】
0006402619.tif 000005
【図５】
0006402619.tif 000006
【図６】
0006402619.tif 000007
【図７】
0006402619.tif 000008
【図８】
0006402619.tif 000009
【図９】
0006402619.tif 000010
【図１０】
0006402619.tif 000011
【図１１】
0006402619.tif 000012
【図１２】
0006402619.tif 000013
【図１３】
0006402619.tif 000014
【図１４】
0006402619.tif 000015
【図１５】
0006402619.tif 000016
【図１６】
0006402619.tif 000017
【図１７】
0006402619.tif 000018
【図１８】
0006402619.tif 000019
【図１９】
0006402619.tif 000020
【図２０】
0006402619.tif 000021
【図２１】
0006402619.tif 000022
【図２２】
0006402619.tif 000023
【図２３】
0006402619.tif 000024
【図２４】
0006402619.tif 000025
【図２５】
0006402619.tif 000026
【図２６】
0006402619.tif 000027
【図２７】
0006402619.tif 000028
【図２８】
0006402619.tif 000029