JP5332000B2 - 複合型計算機装置、複合型計算機の管理方法及び管理サーバ - Google Patents

複合型計算機装置、複合型計算機の管理方法及び管理サーバ Download PDF

Info

Publication number
JP5332000B2
JP5332000B2 JP2008321136A JP2008321136A JP5332000B2 JP 5332000 B2 JP5332000 B2 JP 5332000B2 JP 2008321136 A JP2008321136 A JP 2008321136A JP 2008321136 A JP2008321136 A JP 2008321136A JP 5332000 B2 JP5332000 B2 JP 5332000B2
Authority
JP
Japan
Prior art keywords
root
computer
failure
information
failure processing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2008321136A
Other languages
English (en)
Other versions
JP2010146175A5 (ja
JP2010146175A (ja
Inventor
貴成 馬場
敬太郎 上原
雄次 對馬
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2008321136A priority Critical patent/JP5332000B2/ja
Priority to US12/635,755 priority patent/US8046520B2/en
Publication of JP2010146175A publication Critical patent/JP2010146175A/ja
Publication of JP2010146175A5 publication Critical patent/JP2010146175A5/ja
Application granted granted Critical
Publication of JP5332000B2 publication Critical patent/JP5332000B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/40—Bus structure
    • G06F13/4004—Coupling between buses
    • G06F13/4022—Coupling between buses using switching circuits, e.g. switching matrix, connection or expansion network

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Mathematical Physics (AREA)
  • Computer Hardware Design (AREA)
  • General Physics & Mathematics (AREA)
  • Hardware Redundancy (AREA)
  • Debugging And Monitoring (AREA)

Description

本発明は、複数の計算機と複数のＩＯデバイスをＰＣＩ（Peripheral Component Interconnect）スイッチで接続した複合型計算機装置の装置制御技術に関して、特に複数の計算機で共有しているＩＯデバイスに障害が発生した場合の制御に関するものである。
企業で業務の情報処理を行うＩＴシステムは、業務毎にユーザに対して情報を表示するＷＥＢサーバ、情報を結合し処理するＡＰ（Ａｐｐｌｉｃａｔｉｏｎ）サーバ、情報を蓄積保存するＤＢ（Ｄａｔａ Ｂａｓｅ）サーバ等の様々なサーバから構成され、これらサーバにはＣＰＵ、メモリ、ＩＯ（またはＩ／Ｏ、以下同様）デバイス等から成る計算機が用いられている。上記のようにＩＴシステムは、多くのサーバから構成されるため、サーバの管理を容易にするために１つの装置に複数の計算機を搭載したブレードサーバが用いられる（例えば、特許文献１）。
計算機に用いられるＣＰＵは、近年、複数のプロセッサコアを持つマルチコア化による処理性能が向上しており、ＣＰＵを効率的に使用するため１つの計算機に複数の仮想的なサーバを稼動させる仮想サーバ技術が用いられるようになっている。また、計算機では他の計算機とのネットワーク通信やストレージ装置の接続にＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）やＦＣ−ＨＢＡ（Ｆｉｂｅｒ Ｃｈａｎｎｅｌ−Ｈｏｓｔ Ｂｕｓ Ａｄａｐｔｅｒ）等のＩＯデバイスが用いられる。
上記のように１つの計算機に複数のサーバが動作する一方で、計算機当たりに接続できるＩＯデバイス数は物理的な制約から増えていないため、相対的に計算機当りのＩＯデバイス数が不足する。
ＩＯデバイス数の不足を補う技術として、複数の計算機と複数のＩＯデバイスとを接続可能とするマルチルートＩＯスイッチ技術と、１つのＩＯデバイスを複数の計算機で共有することを可能とするマルチルートＩＯ仮想化技術（ＩＯＶ：ＩＯ Ｖｉｒｔｕａｌｉｚａｔｉｏｎ）とがある。前者のマルチルートＩＯスイッチ技術では、１つの計算機に接続可能なＩＯデバイスの個数をスケーラブルに変更することが可能である（例えば、非特許文献１）。後者のマルチルートＩＯ仮想化技術では、１つのＩＯデバイスを複数の計算機で共有することで仮想的にＩＯデバイスの数を増やすことが可能である。これらの技術を用いることで、仮想サーバを用いた場合のＩＯデバイス数の不足を解消することができる（例えば、特許文献２）。
なお、複数の計算機を一つの筐体に収容するブレードサーバについては特開２００２−３２１５３「カートリッジ型サーバユニットおよび該サーバユニット搭載用筐体」に記載されている。この種のマルチルートＩＯスイッチ技術については非特許文献１に記載されている。
特開２００２−３２１５３号 米国特許第７０５８７３８号明細書 「Advanced Switching Technology Tech Brief」、2005年発行、ASI-SIG発行、
従来の計算機では、計算機に接続されるＩＯデバイスは、計算機とＩＯデバイスが１対１の固定的な接続であり、１つのＩＯデバイスが複数の計算機から共有されることはないが、上記のマルチルートＩＯ仮想化技術を用いた複合型計算機装置では、１つのＩＯデバイスを複数の計算機から共有して使用することが可能である。このようなマルチルートＩＯ仮想化技術を用いた複合型計算機で、複数計算機で共有したＩＯデバイスの障害処理では、次のような問題点があることが本発明者により見い出された。
ＩＯデバイスの障害処理としては、ＯＳをシャットダウンまたは計算機の電源切断により停止するＯＳ停止処理、ＯＳをシャットダウンまたは電源切断後に再起動するＯＳリブート処理、障害が起きたＩＯデバイスを使用しないようにするＩＯ閉塞処理、障害が起きたＩＯデバイスの障害からの復帰を試みるＩＯリトライ処理、等の様々な障害処理方法が用いられる。これらのＩＯデバイスの障害処理方法のうちどの方法を用いるかは、主に次の２つ理由で決定する。
第１の理由は、計算機の各コンポーネントが各障害処理方法に対応しているかどうかである。ここで、計算機の各コンポーネントとは、ＩＯデバイス、チップセット、ＢＩＯＳ等のファームウェア、ＯＳのことを指す。例えば、ＩＯリトライ処理を行うには、ＩＯデバイス、チップセット、ファームウェア、ＯＳのそれぞれがＩＯリトライ処理を行えるようにサポートしている必要がある。
第２の理由は、計算機を使用するユーザの障害処理方針に依存する。例えば、ユーザの業務がなるべく停止しないようする可用性が要求される計算機では、通信の再開が期待されるＩＯリトライ処理が用いられるが、一方可用性の要求が低い計算機ではＯＳ停止処理やＯＳリブート処理が用いられる。
ＩＯデバイスの障害処理には複数の方法があるが、上記のような複数の計算機でＩＯデバイスを共有する場合は、計算機毎に異なったＩＯデバイスの障害処理方法が用いられる場合がある。これは、上記第１の理由から計算機毎に対応可能な障害処理方法が異なるため、あるいは、上記第２の理由から計算機毎にユーザの障害処理方針が異なるためである。
このようにＩＯデバイスを共有する複数の計算機間でＩＯデバイスの障害処理方法が異なると、ＩＯデバイスの障害処理が競合し、正しく障害処理が行われないという課題がある。
例えば、２個の計算機でひとつのＩＯデバイスを共有している場合に、第１の計算機の該当ＩＯデバイスの障害処理方法がＩＯリトライ処理で、第２の計算機の障害処理方法がＯＳリブート処理の場合、第１の計算機でＩＯリトライ処理中に第２の計算機のＯＳリブートによりＩＯデバイスのハードウェアリセットが行われると第１の計算機のＩＯリトライ処理が中断されるために障害処理が正しく行われない、という課題があった。
そこで、本発明は上記課題を解決すべくなされたもので、１つのＩＯデバイスを複数の計算機で共有する場合に、ＩＯデバイスに障害が発生した際に行われる計算機毎の障害処理を計算機間で調停してＩＯデバイスを共有している他の計算機に影響を与えないで障害処理を実行することを目的とする。
本発明は、演算処理を行うプロセッサと、情報を記憶するメモリと、前記プロセッサに接続されてＰＣＩのインターフェースを含むチップセットと、を有する複数の計算機と、複数のＩＯデバイスと前記複数の計算機とを相互に接続する１以上のＰＣＩスイッチと、前記計算機への前記ＩＯデバイスの割当てを管理するリソース管理部と、前記計算機と前記ＩＯデバイスとの論理的な接続を行う前記ＰＣＩスイッチを制御するマルチルートＩＯマネージャと、を備えた複合型計算機装置であって、前記ＩＯデバイスは、前記複数の計算機で共有することが可能なマルチルートＩＯデバイスを含み、前記マルチルートＩＯマネージャは、前記ＰＣＩスイッチを監視して、前記マルチルートＩＯデバイスに障害が発生したときには、前記リソース管理部に前記マルチルートＩＯデバイスの障害を通知する監視部と、前記マルチルートＩＯデバイスに障害が発生したときには、前記マルチルートＩＯデバイスのハードウェアリセットを抑止するＩＯデバイスハードリセット抑止部と、を備え、前記リソース管理部は、前記マルチルートＩＯデバイスの管理情報として、少なくとも、前記マルチルートＩＯデバイスを共有している計算機毎に該マルチルートＩＯデバイスに障害が発生したときの障害処理の内容を示す障害処理内容情報と、該マルチルートＩＯデバイスを共有している計算機毎に、当該マルチルートＩＯデバイスをハードウェアリセットすることが可能か否かを示す障害処理ステータス情報と、を含むＩＯデバイス管理情報と、前記マルチルートＩＯマネージャから前記マルチルートＩＯデバイスの障害発生の通知を受信したときに、当該マルチルートＩＯデバイスを共有している各計算機から障害処理の進捗情報をそれぞれ取得して、前記障害処理ステータス情報を更新し、該障害処理ステータス情報に基づいて前記マルチルートＩＯマネージャにマルチルートＩＯデバイスのハードウェアリセットの抑止または解除の指令を通知する障害処理調停部と、を有し、前記計算機は、前記マルチルートＩＯデバイスに障害が発生したときは、前記障害処理内容情報の障害処理を実行し、当該障害処理がマルチルートＩＯデバイスのハードウェアリセットのときには、前記マルチルートＩＯマネージャに当該マルチルートＩＯデバイスのハードウェアリセットを要求し、前記ＩＯデバイスハードリセット抑止部は、前記各計算機から前記障害が発生したマルチルートＩＯデバイスに対する前記ハードウェアリセットの要求に対して、前記障害処理調停部から当該マルチルートＩＯデバイスについてハードウェアリセットの抑止の指令を受け付けたときには、当該マルチルートＩＯデバイスのハードウェアリセットを抑止する。
したがって、本発明によれば、１つのＩＯデバイスを複数の計算機で共有した場合でも、リソース管理部がＩＯデバイスに障害が発生した際に行われる計算機毎の障害処理（マルチルートＩＯデバイスのハードウェアリセット）を計算機間で調停するため、ＩＯデバイスを共有している他の計算機に影響を与えないで障害処理を実行することが可能であり、これにより、障害処理内容が異なる計算機間、あるいは、ＯＳの種類またはＢＩＯＳの種類が異なる計算機間で障害処理の機能を保持したままＩＯデバイスを共有することができる。
また、計算機を構成する場合（または、ＩＯデバイスの障害時に他のＩＯデバイスに切り替える場合）に、予め設定した計算機のプロファイル情報にＩＯデバイスの障害時の障害回復処理の内容情報を含み、当該障害回復処理の内容情報を基にリソース管理部が、障害処理の内容を考慮して、計算機とＩＯデバイスを選択するため、障害回復処理を考慮した複数の計算機によるマルチルートＩＯデバイスの共有の設定を容易に行うことが可能となる。
以下、本発明の一実施形態を添付図面に基づいて説明する。なお、実施の形態を説明するために全図において、同一の部材には原則として同一の符号を付し、同一の符号を付した部材の繰り返しの説明は原則として省略する。
先ず本発明の一実施の形態による複合型計算機装置の構成について説明する。図１は本発明の第１の実施形態による複合型計算機装置のブロック図である。
図１に示すように、本実施の形態において複合型計算機装置は、１以上の計算機１００と複数のマルチルートＩＯデバイス１０２を相互に接続することが可能な１以上のマルチルートＰＣＩ Ｅｘｐｒｅｓｓスイッチ１０１と、予め設定されたＦｕｎｃｔｉｏｎ（機能）１２０を異なる計算機１００に割当てて共有することが可能な１以上のマルチルートＩＯデバイス１０２と、計算機１００の電源制御等を行う装置制御部１０３を実行する装置制御計算機１０３０と、マルチルートＰＣＩ Ｅｘｐｒｅｓｓスイッチ１０１と計算機１００とマルチルートＩＯデバイス１０２の接続（または割当）の設定と、マルチルートＰＣＩ Ｅｘｐｒｅｓｓスイッチ１０１とマルチルートＩＯデバイス１０２の初期化等の制御を行うマルチルートＩＯマネージャ１０４を実行するスイッチ管理計算機１０４０と、マルチルートＰＣＩ Ｅｘｐｒｅｓｓスイッチ１０１とマルチルートＩＯマネージャ１０４を接続する制御Ｉ／Ｆ（インターフェース）１１７と、複数の計算機１００と装置制御計算機１０３０及びスイッチ管理計算機１０４０を接続する制御Ｉ／Ｆ１１８と、から構成される。なお、このような制御Ｉ／Ｆ１１７、１１８には、制御用ＬＡＮ（Local Area Network）やＩ2Ｃ（Inter-Integrated Circuit）等のインターフェースが用いられる。
また、複合型計算機装置は、管理コンポーネントとして、管理者が操作する管理端末１０６からの要求を受け付けて計算機１００に対するマルチルートＩＯデバイス１０２の割当てを管理するリソース管理ソフトウェア１３２（リソース管理部）が動作する管理サーバ１０５と、複合型計算機装置を管理するＰＣ等で構成された端末計算機である管理端末１０６と、を備える。管理端末１０６と、管理サーバ１０５と、装装置制御計算機１０３０と、スイッチ管理計算機１０４０は、管理用ＬＡＮ等の管理ネットワーク１１９で相互に接続される。
マルチルートＩＯデバイス１０２としては、図中ＩＯデバイス１、３がネットワークインターフェースを備えたＮＩＣ（Network Interface Card）で、ＩＯデバイス２、４がＨＢＡ（Host Bus Adaptor）やＲＡＩＤカードで構成されたディスクインターフェースの例を示す。
ギガビットイーサネット（登録商標、以下同じ）スイッチ等のネットワークスイッチ１０７や、ＲＡＩＤ装置やＦＣ（Fibre Channel）スイッチ等のストレージ装置１０８は複合型計算機装置の外部の関連コンポーネントであり、マルチルートＩＯデバイス１０２の物理ポート１２１、ギガビットイーサネット等のネットワークインターフェース１３０、ＦＣ等のストレージネットワークインターフェース１３１経由で複合型計算機装置に接続される。
計算機１００は、ＣＰＵ（プロセッサ）１３４、メモリ１３５、マルチルートＰＣＩ Ｅｘｐｒｅｓｓスイッチ１０１とＣＰＵ１３４やメモリ１３５等との接続を行うチップセット１１３と、チップセット１１３に接続されて計算機の初期化や計算機１００の電源またはリセットなどの稼動に関する制御を行うＢＭＣ（Baseboard Management Controller）１３３のハードウェア構成要素を備える。ＢＭＣ１３３は、プロセッサとメモリ及び通信インターフェースを備えて装置制御計算機１０３０及びマルチルートＩＯマネージャ１０４と通信を行い、計算機１００の基板やチップセット１１３及びＣＰＵ１３４等のハードウェアの監視と、計算機１００の電源制御（起動、停止、再起動）を行う。ＢＭＣ１３３が行うハードウェアの監視は、例えば、ＣＰＵ１３４の温度やクーリングファンの回転速度やＣＰＵ１３４の駆動電圧などであり、この他所定の箇所の温度や電圧などを監視する。なお、本実施形態では、計算機１００の通常の起動や停止については、装置制御部１０３がＢＭＣ１３３に指令を行い、マルチルートＩＯデバイス１０２の障害回復処理中の計算機１００（ＯＳ１１１）の起動や停止についてはチップセット１１３が指令する例を示す。
計算機１００のソフトウェア構成要素は、ＢＩＯＳ（Basic Input/Output System）１１２と、オペレーティングシステム（ＯＳ）１１１と、マルチルートＩＯデバイス１０２のデバイスドライバ１１０と、管理サーバ１０５上で稼動するリソース管理ソフトウェア１３２と通信して計算機１００の管理を行うソフトウェアとしての管理エージェント１０９から成る。なお、図１の例では、それぞれの構成要素は１つしか記載していないが、複数の構成要素を持っても良い。
マルチルートＰＣＩ Ｅｘｐｒｅｓｓスイッチ１０１は、複数のＰＣＩ Ｅｘｐｒｅｓｓの規格に準拠した物理ポート１１５を持ち、各物理ポート１１５の通信の帯域情報を取得する帯域モニタ部１１６を備える。計算機１００とマルチルートＰＣＩ Ｅｘｐｒｅｓｓスイッチ１０１の間は、チップセット１１３のＰＣＩ Ｅｘｐｒｅｓｓの物理ポートであるルートポート１１４とマルチルートＰＣＩ Ｅｘｐｒｅｓｓスイッチ１０１の物理ポート１１５間をＰＣＩ ＥｘｐｒｅｓｓリンクＰＬ１で接続する。また、マルチルートＰＣＩ Ｅｘｐｒｅｓｓスイッチ１０１とマルチルートＩＯデバイス１０２の間は、ＰＣＩ Ｅｘｐｒｅｓｓ リンクＰＬ２で接続する。なお、ＰＣＩバスの最上流、すなわち、ＣＰＵ１３４およびメモリ１３５に近い側の最上流のポートを区別してルートポート（ＲＰ）１１４と呼ぶ。
次に、複合型計算機装置を管理するコンポーネントについて説明する。図２は、リソース管理ソフトウェア１３２を実行する管理サーバ１０５の構成図である。管理サーバ１０５は、演算処理を行うＣＰＵ１０５１と、ＣＰＵ１０５１が利用するデータやプログラムを格納するメモリ１０５２と、管理ネットワーク１１９と通信を行う通信インターフェース１０５３と、データやプログラムを保持するストレージ装置１０５４から構成される。
メモリ１０５２には、ＯＳ（図示省略）とリソース管理ソフトウェア１３２がロードされてＣＰＵ１０５１によって実行される。なお、ＯＳ及びリソース管理ソフトウェア１３２は記憶媒体対としてのストレージ装置１０５４に保持されて、ＣＰＵ１０５１によってメモリ１０５２にロードされる。
リソース管理ソフトウェア１３２は、物理リソース割当て制御部１２４と、障害処理調停部１２５と、ＩＯデバイス切り替え制御部１２６を備え、管理情報として、サーバプロファイル１２７と、ＩＯデバイス管理情報１２８を備える。
物理リソース割当て制御部１２４は、サーバプロファイル１２７に基づいて、計算機１００に実行させるＯＳの種類と、マルチルートＩＯデバイス１０２の障害発生時の処理内容から計算機１００に割り当てるマルチルートＩＯデバイス１０２を決定し、マルチルートＩＯマネージャ１０４に計算機１００とマルチルートＩＯデバイス１０２の割当を行うように指令する。
障害処理調停部１２５は、マルチルートＩＯマネージャ１０４からの障害発生通知を受け付けて、障害処理（障害回復処理）を実行し、後述するように装置制御計算機１０３０とスイッチ管理計算機１０４０に所定の指令を送信して、複数の計算機１００で共有されるマルチルートＩＯデバイス１０２の障害発生時の処理を調停する。
ＩＯデバイス切り替え制御部１２６は、マルチルートＩＯデバイス１０２に障害が発生したときに、ＩＯデバイス管理情報１２８に基づいて計算機１００に割り当てるマルチルートＩＯデバイス１０２を切り替える指令をマルチルートＩＯマネージャ１０４に指示する。
装置制御計算機１０３０は、図示はしないが、管理サーバ１０５と同様に、ＣＰＵとメモリ及びストレージ装置を備えた計算機で構成され、ＣＰＵは計算機１００の起動や停止を制御する装置制御部１０３をメモリにロードして実行する。装置制御部１０３には、マルチルートＩＯデバイス１０２の障害発生時の処理内容が競合する場合に、計算機１００の停止（ＯＳ停止）または再起動（ＯＳリブート）を抑制する電源制御抑止部１２２を含む。
スイッチ管理計算機１０４０は、図示はしないが、管理サーバ１０５と同様に、ＣＰＵとメモリ及びストレージ装置を備えた計算機で構成され、ＣＰＵはＰＣＩ Ｅｘｐｒｅｓｓスイッチ１０１を制御して計算機１００とマルチルートＩＯデバイス１０２の割り当てを管理するマルチルートＩＯマネージャ１０４をメモリにロードして実行する。マルチルートＩＯマネージャ１０４には、ＰＣＩ Ｅｘｐｒｅｓｓスイッチ１０１及びマルチルートＩＯデバイス１０２を監視して、マルチルートＩＯデバイス１０２やＰＣＩ Ｅｘｐｒｅｓｓスイッチ１０１に障害が発生したときには管理サーバ１０５に通知する監視部１２３０を有する。そして、マルチルートＩＯマネージャ１０４は、マルチルートＩＯデバイス１０２の障害発生時の障害回復の処理内容が競合する場合に、マルチルートＩＯデバイス１０２の再起動（ハードウェアリセット）を抑止（禁止）するＩＯデバイスハードリセット抑止部１２３を含む。
以下、第１の実施の形態による複合型計算機が保持する管理情報について図３、図１０、図１４を用いて詳しく説明する。
図３は第１の実施の形態による複合型計算機のＩＯデバイス管理情報１２８の一例を示した説明図である。図１０は第１の実施の形態による複合型計算機のサーバプロファイル１２７の一例を示した説明図である。図１４は第１の実施の形態による複合型計算機のＩＯデバイス切り替え候補の情報としてのＩＯデバイス管理情報１２８の一例を示した説明図である。
サーバプロファイル１２７は、計算機１００（または複合型計算機）の管理者が操作する管理端末１０６から要求する計算機１００の仕様情報であり、ＣＰＵ１３４、メモリ１３５、マルチルートＩＯデバイス１０２、ＯＳ１１１等の仕様情報を含む。サーバプロファイル１２７は、要求する計算機１００毎に、計算機１００の管理者が管理端末１０６で作成し、リソース管理ソフトウェア１３２が保持する。すなわち、計算機１００（または複合型計算機）の管理者は、管理端末１０６から管理サーバ１０５のリソース管理ソフトウェア１３２のサーバプロファイル１２７にアクセスして、計算機１００の仕様と、計算機１００に割り当てるマルチルートＩＯデバイス１０２及び障害処理の情報を設定する。
図１０は、ある１つの計算機１００のサーバプロファイル１２７のうちＩＯデバイスに関する情報を表形式ＦＴ９で示したものであり、当該計算機１００に必要なＩＯデバイスの情報として、計算機１００内でＩＯデバイスを識別する番号であるＩＯデバイス番号Ｋ９０１と、ＩＯデバイスの種類Ｋ９０２と、ＩＯデバイスに障害が発生したときの障害処理方法Ｋ９０３と、ＩＯデバイスに障害が発生したときにマルチルートＩＯデバイス１０２を切り替える否かを示す情報を格納する障害時ＩＯデバイス切り替え情報Ｋ９０４と、ＩＯデバイスが接続される外部装置の情報Ｋ９０５と、の列を持つ。
例えば、ＩＯデバイス番号Ｋ９０１が「１」のレコードは、マルチルートＩＯデバイス１０２の種類Ｋ９０２がＧｂＥ ＮＩＣ（Gigabit Ethernet（登録商標） Network Interface Card）であり、障害発生時の障害処理方法Ｋ９０３が「リトライ」であり、障害時ＩＯデバイス切り替えＫ９０５は切り替えをしないことを示す「なし」であり、外部装置の情報Ｋ９０５は「ＶＬＡＮ１」に接続するである。なお、障害処理方法については、後で詳細に説明する。
なお、図１０では図示を省略したが、サーバプロファイル１２７には、計算機１〜３毎に、ＣＰＵ１３４の種類と、メモリ１３５の量と、マルチルートＩＯデバイス１０２の種類と、ＯＳ１１１の種類を備えた仕様情報を含む。
一方、ＩＯデバイス管理情報１２８は、複合型計算機装置の計算機１００とマルチルートＩＯデバイス１０２の割当て等の情報を持ち、表形式で表すと図３のＦＴ２に示すように、複合型計算機装置内のマルチルートＩＯデバイス１０２の識別子であるＩＯデバイス識別子Ｋ２０１と、マルチルートＩＯデバイス１０２内のＰＣＩ Ｆｕｎｃｔｉｏｎ１２０の識別子Ｋ２０２と、ＰＣＩ Ｆｕｎｃｔｉｏｎ１２０を割当てた計算機１００の識別子Ｋ２０３と、マルチルートＩＯデバイス１０２に障害が発生した場合の障害処理方法Ｋ２０４と、マルチルートＩＯデバイス１０２に障害が発生した場合にマルチルートＩＯデバイス１０２の切り替えを行うか否かの情報Ｋ２０５と、ＰＣＩ Ｆｕｎｃｔｉｏｎ１２０を割当てた計算機１００上で動作するＯＳの種類Ｋ２０６と、マルチルートＩＯデバイス１０２に障害が発生した場合の障害処理のステータス情報として、当該マルチルートＩＯデバイス１０２がハードリセット（ハードウェアリセット）を実施可能か否かを示す障害処理ステータス情報Ｋ２０７、の列から成る。
例えば、ＩＯデバイス識別子Ｋ２０１が「１」でＰＣＩ Ｆｕｎｃｔｉｏｎ１２０の識別子Ｋ２０２が「３」のマルチルートＩＯデバイス１０２は、計算機１００の識別子Ｋ２０３が「３」の計算機に割当てられ、障害処理方法Ｋ２０４は「閉塞」で、障害時のＩＯデバイス切り替え情報Ｋ２０５は「あり」、すなわち、マルチルートＩＯデバイス１０２の切り替えを行うことを示し、ＯＳの種類Ｋ２０６は「ＯＳ Ａ」であり、障害処理のステータスＫ２０７はハードリセットが「不可」であることを示す。
また、この図３の例のように、障害時のＩＯデバイス切り替え情報Ｋ２０５が「あり」の場合は、ＩＯデバイス管理情報１２８は、マルチルートＩＯデバイス１０２の切り替えの候補となるＩＯデバイスの情報として図１４に示す情報を持つ。すなわち、表形式で表すと図１４のＦＴ１３に示すように、切り替え候補となるマルチルートＩＯデバイス１０２の識別子を格納するＩＯデバイス識別子Ｋ１３０１と、マルチルートＩＯデバイス１０２内のＰＣＩ Ｆｕｎｃｔｉｏｎ１２０の識別子Ｋ１３０２と、当該ＰＣＩ Ｆｕｎｃｔｉｏｎ１２０の空き帯域の情報Ｋ１３０３、の列から成る。
空き帯域情報Ｋ１３０３は、ＰＣＩ Ｅｘｐｒｅｓｓスイッチ１０１の帯域モニタ部１１６が取得したマルチルートＩＯデバイス１０２が利用した単位時間当たりの帯域情報Ｗ１と当該マルチルートＩＯデバイス１０２の仕様の最大帯域ＷＴとから次式により管理サーバ１０５が計算して求める。なお、帯域情報Ｗはデータの転送速度ＭＢｙｔｅ／ｓｅｃの平均値や単位時間当たりのトランザクション数（ＭＴ／ｓｅｃ）の平均値などで表現すればよい。
空き帯域＝ＷＴ−Ｗ１
リソース管理ソフトウェア１３２は、マルチルートＩＯデバイス１０２の帯域情報Ｗ１を、例えばスイッチ管理計算機１０４０経由で取得する。なお、上記空き帯域情報Ｋ１３０３に限定されるものではなく、マルチルートＩＯデバイス１０２の帯域の空き状況が分かる情報であれば種々変更可能である。
図３に示すように、ＩＯデバイス障害発生時の障害処理方法Ｋ２０４は、マルチルートＩＯデバイス１０２のＰＣＩ Ｆｕｎｃｔｉｏｎ１２０毎に異なっても良い。これは、各計算機１００で実行するＯＳの種類や、各計算機１００に搭載されたＢＩＯＳ（またはＥＦＩ：Extensible Firmware Interface）１１２の種類毎に使用可能な障害処理方法が異なるためである。障害処理方法Ｋ２０４としては、例えば、ＯＳ停止処理、ＯＳリブート処理、ＩＯ閉塞処理、ＩＯリトライ処理などがある。なお、ＯＳ停止処理は、ＯＳ１１１をシャットダウンまたは計算機１００の電源切断により停止する処理で、ＯＳリブート処理はＯＳ１１１をシャットダウンまたは計算機１００の電源切断後に再起動する処理であり、ＩＯ閉塞処理は障害が起きたマルチルートＩＯデバイス１０２の使用を禁止する処理であり、リトライ処理は障害が起きたマルチルートＩＯデバイス１０２の障害からの復帰を試みる処理である。
次に、第１の実施の形態による複合型計算機のＩＯデバイス障害発生時の障害処理方法について、図４〜図８を用いて説明する。
図４は本発明の第１の実施形態による複合型計算機のＩＯデバイス障害発生時の障害処理方法（ＯＳ停止処理）の一例を示したフローチャートである。図５は本発明の第１の実施形態による複合型計算機のＩＯデバイス障害発生時の障害処理方法（ＯＳリブート処理）の一例を示したフローチャートである。図６は本発明の第１の実施形態による複合型計算機のＩＯデバイス障害発生時の障害処理方法（ＩＯ閉塞処理）の一例を示したフローチャートである。図７は本発明の第１の実施形態による複合型計算機のＩＯデバイス障害発生時の障害処理方法（ＩＯリトライ処理（１））の一例を示したフローチャートである。図８は本発明の第１の実施形態による複合型計算機のＩＯデバイス障害発生時の障害処理方法（ＩＯリトライ処理（２））の一例を示したフローチャートである。
図４に示すように、ＯＳ停止処理は、マルチルートＩＯデバイス１０２の障害が発生するとマルチルートＩＯデバイス１０２、または、マルチルートＰＣＩ Ｅｘｐｒｅｓｓスイッチ１０１で障害が検出され、マルチルートＩＯデバイス１０２を共有しているすべての計算機１００のルートポート１１４に障害の発生が通知される（ステップＳ３０１）。
ルートポート１１４は、予め指定された障害処理方法、ここではＯＳ停止処理を選択して障害処理を開始し、ＢＩＯＳ１１２に障害発生を通知する（ステップＳ３０２）。ＢＩＯＳ１１２は、障害に関するログを採取して、障害の内容を解析し、解析結果をフラッシュメモリ等の不揮発の記憶媒体（図示省略）に保存し、ＢＭＣ１３３に通知する（ステップＳ３０３）。なお、障害に関するログは、ＯＳ１１１が取得してメモリ１３５の所定の領域に保持するものとする。
ＢＭＣ１３３は、ＯＳシャットダウン制御を開始し（ステップＳ３０４）、ＯＳ１１１がシャットダウンする（ステップＳ３０５）。ＢＭＣ１３３は計算機１００の電源供給を停止する処理を行い（ステップＳ３０６）、計算機１００の電源供給の停止により障害処理が完了する（ステップＳ３０７）。
図５に示すように、ＯＳリブート処理は、マルチルートＩＯデバイス１０２の障害が発生するとマルチルートＩＯデバイス１０２、または、マルチルートＰＣＩ Ｅｘｐｒｅｓｓスイッチ１０１で障害が検出され、マルチルートＩＯデバイス１０２を共有しているすべての計算機１００のルートポート１１４に障害の発生が通知される（ステップＳ４０１）。
ルートポート１１４は、予め指定された障害処理方法、ここではＯＳリブート処理を選択し障害処理を開始し、ＢＩＯＳ１１２に障害発生を通知する（ステップＳ４０２）。ＢＩＯＳ１１２は、障害に関するメモリ１３５の所定の領域からログを採取して、障害の内容を解析し、解析結果をフラッシュメモリ等の不揮発の記憶媒体（図示省略）に保存し、ＢＭＣ１３３に通知する（ステップＳ４０３）。
ＢＭＣ１３３は、ＯＳシャットダウン制御を開始し（ステップＳ４０４）、ＯＳ１１１がシャットダウンする（ステップＳ４０５）。ＢＭＣ１３３はマルチルートＩＯマネージャ１０４に対してマルチルートＩＯデバイス１０２のハードウェア的なリセット、いわゆる、ハードリセットを要求する（ステップＳ４０６）。マルチルートＩＯマネージャ１０４は、マルチルートＩＯデバイス１０２のハードリセット制御を行い（ステップＳ４０７）、マルチルートＩＯデバイス１０２のハードリセットが行われる（ステップＳ４０８）。マルチルートＩＯマネージャ１０４は、マルチルートＩＯデバイス１０２のハードリセットの完了を判定し、ＢＭＣ１３３に対してハードリセット完了の通知を行う（ステップＳ４０９）。ＢＭＣ１３３はＯＳブート制御を開始し（ステップＳ４１０）、ＯＳ１１１がブートし（ステップＳ４１１）、障害処理が完了する（ステップ４１２）。
ＩＯ閉塞処理は、ＯＳが動作中に障害が発生したＩＯデバイスを停止してＯＳ動作を続ける障害処理である。図６に示すように、ＩＯ閉塞処理は、マルチルートＩＯデバイス１０２の障害が発生するとマルチルートＩＯデバイス１０２、または、マルチルートＰＣＩ Ｅｘｐｒｅｓｓスイッチ１０１で障害が検出され、マルチルートＩＯデバイス１０２を共有しているすべての計算機１００のルートポート１１４に障害の発生が通知される（ステップＳ５０１）。
ルートポート１１４は、予め指定された障害処理方法、ここではＩＯ閉塞処理を選択し障害処理を開始し、ＢＩＯＳ１１２に障害発生を通知する（ステップＳ５０２）。ＢＩＯＳ１１２は、障害に関するログをメモリ１３５の所定の領域から採取して、障害の内容を解析し、解析結果をフラッシュメモリ等の不揮発の記憶媒体（図示省略）に保存し（ステップＳ５０３）、ＢＭＣ１３３にマルチルートＩＯデバイス１０２のハードリセット要求を行う（ステップＳ５０４）。
ＢＭＣ１３３がマルチルートＩＯデバイス１０２のハードリセットを行う処理は、図５で示したＯＳリブート処理のステップＳ４０６〜ステップＳ４０９の処理と同じである。マルチルートＩＯデバイス１０２のハードリセットの完了後、ＢＭＣ１３３は、ＢＩＯＳ１１２に対してマルチルートＩＯデバイス１０２のハードリセット完了通知を行い（ステップＳ５０９）、障害処理が完了する（ステップＳ５１０）。
ＩＯリトライ処理は、ＯＳ１１１が動作中にマルチルートＩＯデバイス１０２をリセットしマルチルートＩＯデバイス１０２の障害が回復した場合は、当該マルチルートＩＯデバイス１０２を使用し続ける障害処理である。本実施形態では、マルチルートＩＯデバイス１０２のリセットの種類として、計算機１００（例えば図１の計算機１）が使用しているＰＣＩ Ｆｕｎｃｔｉｏｎ１２０のみをリセットし、マルチルートＩＯデバイス１０２を共有している他の計算機（例えば図１の計算機２、３）が使用しているＰＣＩ Ｆｕｎｃｔｉｏｎ１２０に影響を与えないＦｕｎｃｔｉｏｎリセットと、マルチルートＩＯデバイス１０２のハードリセットと、の２種類の場合について説明する。
図７に示すように、Ｆｕｎｃｔｉｏｎリセットを用いるＩＯリトライ処理は、マルチルートＩＯデバイス１０２の障害が発生するとマルチルートＩＯデバイス１０２、または、マルチルートＰＣＩ Ｅｘｐｒｅｓｓスイッチ１０１で障害が検出され、マルチルートＩＯデバイス１０２を共有しているすべての計算機１００のルートポート１１４に障害の発生が通知される（ステップＳ６０１）。ルートポート１１４は、予め指定された障害処理方法、ここではＩＯリトライ処理を選択し障害処理を開始し、ＢＩＯＳ１１２、および、ＯＳ１１１に障害発生を通知する（ステップＳ６０２）。
ＢＩＯＳ１１２は、障害に関するログをメモリ１３５の所定の領域から採取して、障害の内容を解析し、解析結果をフラッシュメモリ等の不揮発の記憶媒体に保存する（ステップＳ６０３）。一方、ＯＳ１１１は、障害に関するログをメモリ１３５の所定の領域から採取して、障害の内容を解析し（ステップＳ６０４）、障害が発生したマルチルートＩＯデバイス１０２のデバイスドライバ１１０の停止処理を行い（ステップＳ６０５）、マルチルートＩＯデバイス１０２の当該計算機１００が使用するＰＣＩ Ｆｕｎｃｔｉｏｎ１２０のリセット制御を行う（ステップＳ６０６）。
マルチルートＩＯデバイス１０２のリセット処理が完了すると（ステップＳ６０７）、ＯＳ１１１は、デバイスドライバ１１０の再起動処理を行い（ステップＳ６０８）、マルチルートＩＯデバイス１０２が利用可能状態になることで障害処理が完了する（ステップＳ６０９）。
一方、図８に示すように、ハードリセットを用いるＩＯリトライ処理は、障害検出からデバイスドライバ１１０の停止処理までは、図７に示したＦｕｎｃｔｉｏｎリセットを用いるＩＯリトライ処理のステップＳ６０１〜ステップＳ６０５と同様である。ＯＳ１１１は、デバイスドライバ１１０の停止後にＢＭＣ１３３に対してマルチルートＩＯデバイス１０２のハードリセット要求を行う（ステップＳ７０１）。ＢＭＣ１３３がマルチルートＩＯデバイス１０２のハードリセットを行う処理は、図５で示したＯＳリブート処理のステップＳ４０６〜ステップＳ４０９の処理と同じである。
マルチルートＩＯデバイス１０２のハードリセットの完了後、ＢＭＣ１３３は、ＯＳ１１１に対してマルチルートＩＯデバイス１０２のハードリセット完了通知を行い（ステップＳ７０２）、ＯＳ１１１は、デバイスドライバ１１０の再起動処理を行い（ステップＳ７０３）、マルチルートＩＯデバイス１０２が利用可能状態になることで障害処理が完了する（ステップＳ７０４）。
なお、上記図３〜図８に示す障害処理では、説明を簡易にするため障害処理方法の選択をルートポート１１４が行っている例を示しているが、ルートポート１１４、ＢＩＯＳ１１２、ＢＭＣ１３３の個々の選択処理が総合的に機能し、障害処理方法が選択されても良い。また、ＯＳリブート処理、ＩＯ閉塞処理、ＩＯリトライ処理の障害処理中に障害処理が失敗した場合は、他の種類の障害処理が用いられることになるが、処理のフローは上記で説明したものと同じであり説明は省略する。
次に第１の実施の形態による複合型計算機の制御方法について説明する。最初に、マルチルートＩＯデバイス１０２に障害が発生したときのリソース管理ソフトウェア１３２による制御方法について図９を用いて説明する。
図９は、本発明の第１の実施形態による複合型計算機のＩＯデバイス障害発生時のリソース管理ソフトウェア１３２による障害処理方法の一例を示したフローチャートである。
マルチルートＩＯデバイス１０２に障害が発生した時は、リソース管理ソフトウェア１３２の障害処理調停部１２５は、マルチルートＩＯマネージャ１０４からの障害発生通知を受信することによりマルチルートＩＯデバイス１０２の障害発生を検知して障害処理（障害回復処理）を開始する（ステップＳ８０１）。
リソース管理ソフトウェア１３２の障害処理調停部１２５は、装置制御計算機１０３０で稼動する装置制御部１０３の計算機１００毎の電源制御抑止部１２２に対して計算機１００のリセット抑止を設定する（ステップＳ８０２）。これにより、障害が発生したマルチルートＩＯデバイス１０２を割当てられた計算機１００の管理エージェント１０９やユーザ操作による当該計算機１００の電源制御を抑止し、各計算機１００のマルチルートＩＯデバイス１０２のＩＯデバイス障害処理に影響がないようにする。なお、障害処理調停部１２５による計算機１００の電源制御抑止では、各計算機のＩＯデバイス障害処理の中で行われる計算機１００の電源制御（リブートや停止等）は含まれない。また、装置制御計算機１０３０の電源制御抑止部１２２は、計算機１００毎（図１の計算機１〜３毎）に電源制御の抑止状態を示す情報を格納するテーブル（図示省略）を備える。
次に、リソース管理ソフトウェア１３２の障害処理調停部１２５は、マルチルートＩＯマネージャ１０４のＩＯデバイスハードリセット抑止部１２３に対して、障害が発生したマルチルートＩＯデバイス１０２のハードリセットの抑止の設定を行う（ステップＳ８０３）。これにより、各計算機１００のＩＯデバイス障害処理の中でマルチルートＩＯデバイス１０２のハードリセットの要求があった場合にハードリセットを抑止することで他の計算機１００のＩＯデバイス障害処理へ影響を与えないようにすることができる。
次に、障害処理調停部１２５は、各計算機１００のＩＯデバイス障害処理の進捗状況を取得し、ＩＯデバイス管理情報１２８の障害処理ステータスＫ２０７のステータス情報を更新する（ステップＳ８０４）。
管理サーバ１０５で稼動するリソース管理ソフトウェア１３２がＩＯデバイス障害処理の進捗情報を取得する方法の一例としては、各計算機１００のＢＭＣ１３３から制御Ｉ／Ｆ１１７、装置制御計算機１０３０及び管理ネットワーク１１９を経由して進捗情報を取得する方法や、各計算機１００を管理ネットワークに接続して管理エージェント１０９から管理ネットワーク１１９経由で進捗情報を取得する方法を採用することができる。ここで、管理サーバ１０５のリソース管理ソフトウェア１３２が、マルチルートＩＯデバイス１０２の障害回復処理中の計算機１００から取得する障害処理の進捗情報は、図４〜図８で示したように、計算機１００で行われる障害処理がいずれの段階にあるかを示す情報である。例えば、進捗情報の取得は、計算機１００のチップセット１１３からマルチルートＩＯデバイス１０２障害処理の開始を受信したＢＭＣ１３３から取得することができる。ＢＭＣ１３３は、ＯＳ１１１に対するシャットダウンの指令や起動（または再起動）の指令や、ＯＳ１１１の起動完了の監視や、マルチルートＩＯデバイス１０２のハードリセットの要求等を行うので、障害処理中の計算機１００の動作状態を監視することができる。管理サーバ１０５のリソース管理ソフトウェア１３２は、装置制御計算機１０３０またはスイッチ管理計算機１０４０を介して、ＢＭＣ１３３が検出した計算機１００の動作状態を障害処理中の進捗情報として取得する。
次に、リソース管理ソフトウェア１３２は、マルチルートＩＯデバイス１０２の障害処理としてマルチルートＩＯデバイス１０２の切り替えを要求している計算機１００があるか否かを判定し（ステップＳ８０５）、マルチルートＩＯデバイス１０２の切り替えを要求している計算機１００がある場合はマルチルートＩＯデバイス１０２の切り替え処理を実行する（ステップＳ８０６）。
なお、マルチルートＩＯデバイス１０２の切り替え処理については後述する。次に、リソース管理ソフトウェア１３２の障害処理調停部１２５は、図３に示したＩＯデバイス管理情報１２８の障害処理ステータスＫ２０７のステータス情報から、マルチルートＩＯデバイス１０２を共有しているすべての計算機１００のＩＯデバイス障害処理でマルチルートＩＯデバイス１０２のハードリセットが可能な状態であるかを判定する（ステップＳ８０７）。
マルチルートＩＯデバイス１０２のハードリセットが可能な状態の場合は、ＩＯデバイスハードリセット抑止部１２３に対して当該マルチルートＩＯデバイス１０２のハードリセット抑止を解除する（ステップＳ８０８）。なお、マルチルートＩＯマネージャ１０４のＩＯデバイスハードリセット抑止部１２３は、ステップＳ８０８でのマルチルートＩＯデバイス１０２のハードリセット抑止解除時に、計算機１００からマルチルートＩＯデバイス１０２のハードリセット要求を受けた場合はハードリセットの制御を実行し、ハードリセット完了後に再び当該計算機１００をハードリセット抑止状態とする。このため、マルチルートＩＯマネージャ１０４のＩＯデバイスハードリセット抑止部１２３は、マルチルートＩＯデバイス１０２毎（図１のＩＯデバイス１〜４毎）にハードリセットが抑止状態であるか否かを示す情報を格納するテーブルを備える。
次に、リソース管理ソフトウェア１３２の障害処理調停部１２５は、マルチルートＩＯデバイス１０２を共有しているすべての計算機１００のうちマルチルートＩＯデバイス１０２の障害処理が完了し、かつマルチルートＩＯデバイス１０２のハードリセットが不可の計算機１００があるか否かを判定する（ステップＳ８０９）。ステップＳ８０９の条件を満たす計算機１００がある場合は、マルチルートＩＯデバイス１０２を共有しているすべての計算機１００のうちＩＯデバイスの障害処理中でマルチルートＩＯデバイス１０２のハードリセットが抑止されている計算機１００があるか否かを判定し（ステップＳ８１０）、ステップＳ８１０の条件を満たす計算機１００がある場合は、該当する計算機１００のマルチルートＩＯデバイス１０２の障害処理を中止する（ステップＳ８１１）。
次に、障害処理調停部１２５は、マルチルートＩＯデバイス１０２を共有しているすべての計算機１００のＩＯデバイスの障害処理が完了したかを判定し（ステップＳ８１２）、すべての計算機１００でＩＯデバイスの障害処理が完了していない場合は、ステップＳ８０４の障害処理の進捗情報の取得に戻りステップＳ８０４〜ステップＳ８１２の処理を再び行う。
一方、すべての計算機１００でＩＯデバイスの障害処理が完了した場合は、リソース管理ソフトウェア１３２はマルチルートＩＯマネージャ１０４のＩＯデバイスハードリセット抑止部１２３に対し、当該マルチルートＩＯデバイス１０２のハードリセットの抑止の解除設定を行う（ステップＳ８１３）。
次に、リソース管理ソフトウェア１３２の障害処理調停部１２５は、装置制御計算機１０３０で稼動する装置制御部１０３の計算機１００の電源制御抑止部１２２に対して計算機１００のリセット抑止の解除設定を行い（ステップＳ８１４）、マルチルートＩＯデバイス１０２の障害処理を完了する（ステップＳ８１５）。
次に、計算機１００のユーザである管理者が管理端末１０６を用いて、新たにサーバを構築するために計算機１００を構成する場合の複合型計算機の制御方法について、図１１〜図１３を用いて説明する。
図１１は、本発明の第１の実施形態による複合型計算機の計算機の構成方法の一例を示したフローチャートである。図１２は、本発明の第１の実施形態による複合型計算機の外部装置との接続関係の一例を示した説明図である。図１３は、本発明の第１の実施形態による複合型計算機のルートポート１１４毎の障害処理方法の指定の一例を示した説明図である。
リソース管理ソフトウェア１３２は、計算機１００の管理者が管理端末１０６から要求した計算機仕様に従った計算機の構成、すなわち、複合型計算機装置の中から計算機仕様に合った計算機１００とマルチルートＩＯデバイス１０２を選択し、計算機１００とマルチルートＩＯデバイス１０２の割当てを行い計算機の初期構築を行う。計算機１００の管理者が管理端末１０６から要求する計算機仕様をサーバプロファイル１２７と呼ぶ。
図１１に示すように、計算機１００の管理者が操作する管理端末１０６からの要求により管理サーバ１０５では計算機１００の構成処理が開始する（ステップＳ１００１）。
計算機１００の管理者は管理端末１０６から、リソース管理ソフトウェア１３２に対して、必要な計算機１００の仕様を計算機のサーバプロファイル１２７により要求する（ステップＳ１００２）。上述の通り、サーバプロファイル１２７は、計算機１００の仕様情報であり、ＣＰＵ１３４、メモリ１３５、マルチルートＩＯデバイス１０２、ＯＳ１１１等の仕様情報を含む。サーバプロファイル１２７の内、特に本実施形態に関連するマルチルートＩＯデバイス１０２に関する情報は、表形式で表すと図１０のＦＴ９に示す情報を持つ。
次にリソース管理ソフトウェア１３２の物理リソース割当て制御部１２４は、サーバプロファイル１２７で指定されたＯＳの種類が、指定されたマルチルートＩＯデバイス１０２の障害処理方法Ｋ９０３をサポートしているか否かを判定する（ステップＳ１００３）。
次に、物理リソース割当て制御部１２４は、複合型計算機の計算機１００でユーザに使用されていない計算機１００から、サーバプロファイル１２７に指定された障害処理方法Ｋ９０３をサポートしているＢＩＯＳ１１２を搭載している計算機１００があるか否かを判定する（ステップＳ１００４）。
次に、物理リソース割当て制御部１２４は、ステップＳ１００４の条件を満たす計算機１００を選択する（Ｓ１００５）。次に、物理リソース割当て制御部１２４は、複合型計算機のマルチルートＩＯデバイス１０２のうちユーザに使用されていないものから、サーバプロファイル１２７に指定されたＩＯデバイスの障害処理方法Ｋ９０３をサポートしているマルチルートＩＯデバイス１０２があるか否かを判定する（ステップＳ１００６）。
次に、物理リソース割当て制御部１２４は、ステップＳ１００６の条件を満たすマルチルートＩＯデバイス１０２の中から、サーバプロファイル１２７に指定された特定の外部装置Ｋ９０５、例えば、ネットワークスイッチ１０７、ストレージ装置１０８、に接続できるか否かを判定する（ステップＳ１００７）。
図１２を用いて、外部装置と接続できるマルチルートＩＯデバイス１０２の選択方法の一例について説明する。図１２は、前記図１に示した本発明の一実施の形態による複合型計算機装置のブロック図に対して、同一構成要素を区別するために、計算機１００を１００−１、１００−２、１００−３とし、マルチルートＩＯデバイス１０２を１０２−１、１０２−２、１０２−３、１０２−４とし、ネットワークスイッチ１０７を１０７−１、１０７−２とし、ストレージ装置１０８を１０８−１、１０８−２とし、ネットワークスイッチ１０７が構成するＶＬＡＮ（Virtual Local Area Network）識別子１１０１１、１１０１２、１１０１３、１１０１４とした例を示す。
図１２に示す構成の場合、図１０のサーバプロファイル１２７のＩＯデバイス番号が「１」のマルチルートＩＯデバイス１０２は「ＧｂＥ ＮＩＣ」の外部装置の情報Ｋ９０５は「ＶＬＡＮ１」であるので、図１２のネットワークスイッチ１（１０７−１）のＶＬＡＮ１（１１０１１）に接続可能なマルチルートＩＯデバイス１（１０２−１）が選択され、ネットワークスイッチ２（１０７−２）に接続しているマルチルートＩＯデバイス３（１０２−３）は選択されない。
また、図１０のサーバプロファイル１２７のＩＯデバイス番号が「４」のマルチルートＩＯデバイス１０２は「ＦＣ−ＨＢＡ（１Ｇ）」であり、外部装置の情報Ｋ９０５はストレージ装置１であるので、図１２のストレージ装置１（１０８−１）に接続可能なマルチルートＩＯデバイス１（１０２−２）が選択され、ストレージ装置２（１０８−２）に接続しているマルチルートＩＯデバイス４（１０２−４）は選択されない。
次に、物理リソース割当て制御部１２４は、ステップＳ１００７の条件を満たすマルチルートＩＯデバイス１０２の中から、計算機１００のルートポート１１４毎にＩＯデバイスの障害処理方法Ｋ９０４が同一にできるか否かを判定する（ステップＳ１００８）。
図１３を用いて、ステップＳ１００８で行われるルートポート１１４毎にＩＯデバイスの障害処理方法を同一にするマルチルートＩＯデバイス１０２の選択方法の一例について説明する。
図１３は、前記図１に示した本発明の一実施の形態による複合型計算機装置のブロック図に対して、同一構成要素を区別するために、計算機１００を１００−１、１００−２、１００−３とし、マルチルートＩＯデバイス１０２を１０２−１、１０２−２、１０２−３、１０２−４とし、ルートポート１１４を１１４−１１、１１４−１２、１１４−２１、１１４−２２、１１４−３１、１１４−３２とし、マルチルートＩＯデバイス１０２−１、１０２−２、１０２−３、１０２−４のＰＣＩ Ｆｕｎｃｔｉｏｎ１２０毎に、割当て計算機と、ＩＯデバイス障害処理方法１２０１１、１２０１２、１２０１３、１２０１４、１２０１５、１２０１６、１２０１７、１２０１８を加えたものである。
図１３に示す例では、計算機１（１００−１）には、ルートポート１１４−１１経由でＰＣＩ Ｆｕｎｃｔｉｏｎ１２０−１、１２０−３、ルートポート１１４−１２経由でＰＣＩ Ｆｕｎｃｔｉｏｎ１２０−５、１２０−７が割当てられている。この例の場合、ルートポート１１４毎にＩＯデバイスの障害処理方法を同一にすることは、ルートポート１１４−１１に関してはＰＣＩ Ｆｕｎｃｔｉｏｎ１２０１−１とＰＣＩ Ｆｕｎｃｔｉｏｎ １２０−３のＩＯデバイスの障害処理方法を同一にすることであり、ここではＯＳリブート処理で同一である。
また、ルートポート１１４−１２に関してはＰＣＩ Ｆｕｎｃｔｉｏｎ１２０−５とＰＣＩ Ｆｕｎｃｔｉｏｎ１２０−７のＩＯデバイスの障害処理方法を同一にすることであり、ここではＩＯ閉塞処理で同一である。
一方、例えば、計算機１（１００−１）のＰＣＩ Ｆｕｎｃｔｉｏｎ１２０−１とＰＣＩ Ｆｕｎｃｔｉｏｎ１２０−５に関しては、ルートポート１１４がそれぞれ異るためＩＯデバイスの障害処理方法が、ＯＳリブート処理とＩＯ閉塞処理と異なっても良い。
次に、物理リソース割当て制御部１２４は、サーバプロファイル１２７の障害時ＩＯデバイス切り替えが、「あり」、すなわち、ＩＯデバイスの切り替えを行う指定がある場合は、複合型計算機のマルチルートＩＯデバイス１０２のうちユーザに使用されていないものから、切り替えが可能なものを選択できるか否かを判定する（ステップＳ１００９）。この判定では、上述のステップＳ１００６、Ｓ１００７、Ｓ１００８での判定と同様の判定処理を行う。すなわち、マルチルートＩＯデバイス１０２がＩＯデバイスの障害処理方法をサポートしているか否か、外部装置に接続可能か否か、ルートポート１１４毎に障害処理方法を同一にできるか否か、の判定が行われる。
これらの判定の後、物理リソース割当て制御部１２４は、計算機１００に割当てるマルチルートＩＯデバイス１０２を選択し、マルチルートＩＯマネージャ１０４に計算機１００とマルチルートＩＯデバイス１０２の割当てを通知して、ＰＣＩ Ｅｘｐｒｅｓｓスイッチ１０１の設定を実行させて（ステップＳ１０１２）、計算機１００の構成が完了する（ステップＳ１０１３）。
一方、ステップＳ１００３、Ｓ１００４、Ｓ１００６、Ｓ１００７、Ｓ１００８、Ｓ１００９の判定処理を満たさなかった場合は、リソース管理ソフトウェア１３２は、計算機１００の管理者の管理端末１０６にサーバプロファイル１２７で要求した仕様の計算機を構成できないことを通知し、サーバプロファイル１２７の再設定をするか否かを判定する（ステップＳ１０１０）。計算機１００の管理者が管理端末１０６からサーバプロファイル１２７の再設定を行うことを通知した場合は、ステップＳ１００２に戻りサーバプロファイル１２７の再設定を行う。一方、計算機の管理者が操作する管理端末１０６からサーバプロファイル１２７の再設定を行わない通知を受けた場合は、計算機１００の構成を中止する（ステップＳ１０１１）。
以上の処理によって、管理サーバ１０５の物理リソース割当制御部１２４は、管理端末１０６から受け付けたサーバプロファイル１２７にしたがって、計算機１００にマルチルートＩＯデバイス１０２と外部装置を割り当てることができる。
なお、上記ステップＳ１００８の処理においては、チップセット１１３が提供するＰＣＩバス上のルートポート１１４毎に、各ルートポート１１４以下のＰＣＩツリーに割当てたすべてのＩＯデバイス（マルチルートＩＯデバイス１０２）について、サーバプロファイル１２７で指定された障害処理方法Ｋ９０３が実行可能であるときに、物理リソースを割り当てるようにしても良い。
次に、ＩＯデバイスの障害発生時に障害処理として他のＩＯデバイスに切り替える場合の複合型計算機の制御方法について、図１５、図１６を用いて説明する。
図１５は、本発明の第１の実施形態による複合型計算機の計算機のＩＯデバイスの障害発生時のＩＯデバイス切り替え方法の一例を示したフローチャートである。図１６は、本発明の第１の実施形態による複合型計算機のＩＯデバイスの障害発生時のＩＯデバイス切り替え対象となるＩＯデバイスを選択するグラフィカルインターフェースの一例を示した説明図である。
マルチルートＩＯデバイス１０２の障害時に行われるＩＯデバイス切り替え処理は、障害が発生したマルチルートＩＯデバイス１０２の代わりに複合型計算機内の使用されていない他のマルチルートＩＯデバイス１０２を計算機１００に割当てて障害を回復する障害処理方法である。
図１５に示すように、ＩＯデバイスの切り替え処理は、図９のステップＳ８０６のＩＯデバイスの切り替え実行により開始される（ステップＳ１４０１）。リソース管理ソフトウェア１３２のＩＯデバイス切り替え制御部１２６は、図１４に示すＩＯデバイス管理情報１２８を基に、計算機１００の管理者が操作する管理端末１０６に対して切り替え可能なマルチルートＩＯデバイス１０２の候補を通知する（ステップＳ１４０２）。
次に、ＩＯデバイス切り替え制御部１２６は、計算機１００の管理者が操作する管理端末１０６から切り替えるマルチルートＩＯデバイス１０２の指定があるか否かを判定し（ステップＳ１４０３）、指定がない場合、あるいは、ＩＯデバイスの切り替えの中止が指定された場合は、ＩＯデバイスの切り替えを中止する（ステップＳ１４０４）。
一方、切り替えるマルチルートＩＯデバイスが選択された場合は、ＩＯデバイス切り替え制御部１２６は、マルチルートＩＯマネージャ１０４に対して、計算機１００から障害が発生したマルチルートＩＯデバイス１０２について計算機１００の割当てを解除し、切り替え対象のマルチルートＩＯデバイス１０２を当該計算機１００に割当てる設定を行う（ステップＳ１４０５）。この設定は、管理サーバ１０５がＩＯデバイス管理情報１２８の割り当て計算機Ｋ２０３を更新することで行われる。
次に、ＩＯデバイス切り替え制御部１２６は、当該計算機１００の電源制御抑止を解除して、計算機１００の管理者が管理端末１０６から管理サーバ１０５を介して装置制御計算機１０３０から電源を投入（または再起動）することができるように設定して（ステップＳ１４０６）、ＩＯデバイスの切り替えが完了する（ステップＳ１４０７）。
次に、図１６を用いて、図１５のステップＳ１４０２で行われる計算機１００の管理者が操作する管理端末１０６に出力する切り替えＩＯデバイスの指定を行うためのグラフィカルインターフェースの一例を説明する。管理端末１０６に表示されるグラフィカルインターフェース１５０１は、リソース管理ソフトウェア１３２の管理画面１５０２を備え、ＩＯデバイス切り替えのグラフィカルインターフェースとして、障害が発生したマルチルートＩＯデバイス１０２の情報１５０３と、切り替えの候補となるマルチルートＩＯデバイス１０２の一覧１５０４と、ＩＯデバイスの切り替えの中止を指定する設定部１５０５と、を備える。
障害が発生したマルチルートＩＯデバイス１０２の情報１５０３として、マルチルートＩＯデバイス１０２の識別子１５０７と、マルチルートＩＯデバイス１０２の種類１５０８と、マルチルートＩＯデバイス１０２が接続されたマルチルートＰＣＩ Ｅｘｐｒｅｓｓスイッチ１０１の識別子１５０９およびポート番号１５１０と、マルチルートＩＯデバイス１０２のＰＣＩ Ｆｕｎｃｔｉｏｎ１２０の識別子１５１１と、帯域モニタ部１１６が取得したマルチルートＩＯデバイス１０２の当該計算機１００が使用する帯域情報１５１２と、当該マルチルートＩＯデバイス１０２に接続される外部装置の情報１５１３を備える。また、切り替えの候補となるマルチルートＩＯデバイス１０２の一覧１５０４は、候補となるマルチルートＩＯデバイス１０２のＰＣＩ Ｆｕｎｃｔｉｏｎ毎１５０６１、１５０６２、１５０６３の情報を表示する。
図１６の例では、ＰＣＩ Ｆｕｎｃｔｉｏｎが１５０６１、１５０６２、１５０６３の３つの候補について示している。切り替えの候補となるマルチルートＩＯデバイス１０２の情報としては、マルチルートＩＯデバイス１０２の識別子１５１４、マルチルートＩＯデバイス１０２が接続されたマルチルートＰＣＩ Ｅｘｐｒｅｓｓスイッチ１０１の識別子１５１５およびポート番号１５１６、マルチルートＩＯデバイス１０２のＰＣＩ Ｆｕｎｃｔｉｏｎの識別子１５１７、帯域モニタ部１１６が取得し障害処理調停部１２５が計算で求めたマルチルートＩＯデバイス１０２の空き帯域情報１５１８を持ち、計算機１００の管理者が操作する管理端末１０６でマルチルートＩＯデバイス１０２の機能（Ｆｕｎｃｔｉｏｎ）１５０６１〜１５０６３を選択させるための設定部１５１９を備える。
以上のように本発明の第１の実施形態によれば、管理者は管理端末１０６からマルチルートＩＯデバイスに障害が発生したときの障害処理内容を含む計算機１００（計算機１〜３）の仕様を管理サーバ１０５のサーバプロファイル１２７を定義しておく。そして、障害処理の内容には、マルチルートＩＯデバイス１０２毎に障害時の処理として、停止、リブート、閉塞、リトライ、および、ＩＯの切り替えを含む。
上記サーバプロファイル１２７に基づいて、管理サーバ１０５のリソース管理ソフトウェア１３２の物理リソース割り当て制御部１２４は、各計算機１００（計算機１〜３）に複合型計算機のリソースの割り当てを行う。
リソース管理ソフトウェア１３２は、リソースの割り当てを行う際には、サーバプロファイル１２７で指定された障害処理Ｋ９０３が可能なように計算機１００の構成をチェックする。
すなわち、リソース管理ソフトウェア１３２は、ＯＳ１１１と、ＢＩＯＳ１１２がサーバプロファイル１２７で指定された障害処理をサポートし、計算機１００のルートポート１１４以下のマルチルートＩＯデバイス１０２がすべて同じ障害処理に設定可能であり、さらに障害発生時にマルチルートＩＯデバイス１０２の切り替えを行う場合には、引継ぎが可能なマルチルートＩＯデバイスの候補を有する計算機１００とマルチルートＩＯデバイス１０２及び外部装置の組み合わせから計算機１００にリソースの割り当てを実施する。
ＰＣＩ Ｅｘｐｒｅｓｓスイッチ１０１はスイッチ管理計算機１０４０のマルチルートＩＯマネージャ１０４によって監視され、マルチルートＩＯマネージャ１０４はマルチルートＩＯデバイス１０２に障害が発生すると、管理サーバ１０５のリソース管理ソフトウェア１３２に障害の発生を通知する。
リソース管理ソフトウェア１３２はマルチルートＩＯデバイス１０２の障害発生の通知を受信すると、障害処理調停部１２５で、マルチルートＩＯデバイス１０２を共有している計算機１００の各障害処理方法から、閉塞、リトライの処理が完了するまで、マルチルートＩＯデバイス１０２のハードウェアリセットを抑止し、および、障害処理の内容がリブートの場合はリブートを抑止する。また、リトライが成功した場合は、ハードウェアリセットは行なわず、計算機１００の業務を継続させて複合型計算機の可用性を確保する。
リソース管理ソフトウェア１３２のＩＯデバイス切り替え制御部１２６は、障害処理でマルチルートＩＯデバイス１０２の切り替え処理対象のＩＯデバイスについて、引継ぎ可能なマルチルートＩＯデバイス１０２の候補と、各候補の空き帯域（空きスループット）を管理端末１０６に提示し、引継ぎ先のマルチルートＩＯデバイス１０２を選択させ、リソース管理ソフトウェア１３２は管理端末１０６から受け付けた引き継ぎ先のマルチルートＩＯデバイス１０２をスイッチ管理計算機１０４０のマルチルートＩＯマネージャ１０４に通知して、計算機１００に選択されたマルチルートＩＯデバイス１０２を割り当てる。
以上のような構成によって、管理サーバ１０５のリソース管理ソフトウェア１３２は、複数の計算機１００と複数のマルチルートＩＯデバイス１０２を備える複合型計算機で、マルチルートＩＯデバイス１０２の障害処理を行うことが可能なＯＳ１１１とＢＩＯＳ１１２及びチップセット１１３のルートポート１１４の設定を選択して、計算機１００を構成する。これにより、マルチルートＩＯデバイス１０２に障害が発生した場合でも、管理サーバ１０５の障害処理調停部１２５が、計算機１００の構成に応じて実行可能な障害処理を実施することが可能となり、複数の計算機１００で共有するマルチルートＩＯデバイス１０２の障害処理を円滑に行うことが可能となる。
そして、マルチルートＩＯデバイス１０２を共有している複数の計算機１００は、計算機１００毎に障害発生時の障害回復処理（リトライ、ＩＯ閉塞、ＯＳリブート、ＯＳ停止）が異なる場合であっても、障害処理調停部１２５が計算機１００間で障害回復処理が競合するのを回避して、障害回復処理を円滑に実現することができる。例えば、図１に示した計算機１の障害回復処理がリトライで、計算機２の障害回復処理がＯＳリブートの場合には、管理サーバ１０５がマルチルートＩＯマネージャ１０４のＩＯデバイスハードリセット抑止部１２３に計算機２のＯＳリブートを禁止するよう指示し、マルチルートＩＯマネージャ１０４が計算機２のＢＭＣ１３３に再起動を禁止することができるので、計算機１のマルチルートＩＯデバイス１０２に対するリトライ中にマルチルートＩＯデバイス１０２がハードリセットされるのを抑制できる。
また、計算機１００がマルチルートＩＯデバイス１０２の障害発生時に他のマルチルートＩＯデバイス１０２に切り替える場合には、管理サーバ１０５がサーバプロファイル１２７とＩＯデバイス管理情報１２８及びＰＣＩ Ｅｘｐｒｅｓｓスイッチ１０１の帯域モニタ部１１６が取得した帯域情報に基づいて、引継ぎ可能なマルチルートＩＯデバイス１０２を提示することができ、ＩＯデバイスの切り替えを確実に行うことが可能となる。
＜第２実施形態＞
次に本発明の第２の実施の形態による複合型計算機の構成について説明する。第２の実施形態における複合型計算機は、図１に示す本発明の第１の実施形態の複合型計算機と、図３に示すＩＯデバイス管理情報１２８と図９に示す複合型計算機のＩＯデバイス障害発生時の管理ソフトウェアによる障害処理方法が異なる以外は同じである。従って、以下では第１の実施形態と異なる分部についてだけ説明し、同じ部分については説明を省略する。
図１７は第２の実施の形態による複合型計算機の管理サーバ１０５が保持するＩＯデバイス管理情報１２８の一例を示した説明図である。
図１７に示すように、ＩＯデバイス管理情報１２８は表形式ＦＴ１６で表すと、図３に示した第１の実施形態のＩＯデバイス管理情報１２８にマルチルートＩＯデバイスの障害処理の優先度を示す情報Ｋ１６０１を追加したものである。
障害処理の優先度情報Ｋ１６０１は、複数の計算機１００でマルチルートＩＯデバイス１０２を共有している場合に、優先度Ｋ１６０１が高い方の計算機１００の障害処理が優先的に実行されることを示す。本実施形態では、障害処理の優先度情報Ｋ１６０１の数値が大きい方が、より優先度が高いものとする。
次に、第２の実施形態でのマルチルートＩＯデバイス１０２に障害が発生したときのリソース管理ソフトウェア１３２による制御方法について図１８を用いて説明する。
図１８は、本発明の第２の実施形態による複合型計算機のＩＯデバイス障害発生時の管理ソフトウェアによる障害処理方法の一例を示したフローチャートである。
図１８に示すように、図３に示した第１の実施形態の障害処理方法の、マルチルートＩＯデバイス１０２を割当てたすべての計算機１００のＩＯデバイスの障害処理でハードリセットが可能か否かを判定するステップＳ８０７と、ステップＳ８０７の判定でハードリセットが可能な状態の場合は、ＩＯデバイスハードリセット抑止部１２３に対して当該マルチルートＩＯデバイス１０２のハードリセット抑止を解除するステップＳ８０８とを、図１８のステップＳ１７０１、Ｓ１７０２に置き換えたもので、その他のステップは前記第１実施形態と同様である。
すなわち、第２の実施形態では、障害処理調停部１２５は、ＩＯデバイス管理情報１２８の障害処理ステータスＫ２０７のステータス情報と、障害処理の優先度情報Ｋ１６０１とから、マルチルートＩＯデバイス１０２を割当てたすべての計算機１００のうち、優先度が所定値Ｎ以上の障害処理でＩＯデバイスのハードリセットが可能か否かを判定する（ステップＳ１７０１）。
当該マルチルートＩＯデバイス１０２でハードリセットが可能な場合は、ＩＯデバイスハードリセット抑止部１２３に対して、優先度Ｎ以上に該当する計算機１００からのマルチルートＩＯデバイス１０２のハードリセット抑止を解除する（ステップＳ１７０２）。なお、ステップＳ１７０１、Ｓ１７０２の処理は、優先度Ｎが０、１、…、Ｎ（Ｎは、Ｎ＞０の整数）のすべての条件について判定される。第２の実施形態により、マルチルートＩＯデバイス１０２を複数の計算機１００で共有した場合に、優先度が高い計算機のＩＯデバイスの障害処理を優先的に実行することが可能になる。
＜第３実施形態＞
次に本発明の第３の実施の形態による複合型計算機の構成について説明する。第３の実施形態における複合型計算機は、図１に示した本発明の第１の実施形態の複合型計算機と、マルチルートＩＯマネージャ１０４のＩＯデバイスハードリセット制御の部分が異なる以外は同じである。従って、以下では第１の実施形態と異なる分部についてだけ説明し、同じ部分については説明を省略する。
図１９は第３の実施の形態による複合型計算機のＩＯデバイスのハードリセット制御の方法の一例を示したフローチャートである。第３の実施形態では、前記第１実施形態に示した図５、図６、図８に示すマルチルートＩＯマネージャ１０４のＩＯデバイスハードリセット制御（図５のステップＳ４０７）の制御部分が、図１９に示す制御で置き換わる。
すなわち、図１９に示すように、ＢＭＣ１３３または計算機１００からマルチルートＩＯデバイス１０２のハードリセット要求を受けたマルチルートＩＯマネージャ１０４は、マルチルートＩＯデバイス１０２のハードリセット制御を開始する（ステップＳ１８０１）。
次に、マルチルートＩＯマネージャ１０４は、ハードリセットを要求した計算機１００について、マルチルートＩＯデバイス１０２のハードリセット抑止が解除されているか否かを判定し（ステップＳ１８０２）、ハードリセット抑止が解除されてハードリセット可能な場合は、マルチルートＩＯデバイス１０２のハードリセットの制御を実行し（ステップＳ１８０３）、マルチルートＩＯデバイス１０２のハードリセットの完了によりハードリセットの制御を完了する（ステップＳ１８０４）。
一方、ステップＳ１８０２の判定で、ハードリセットが抑止されてハードリセットができない場合は、所定の時間Ｔ１だけ待ち（ステップＳ１８０５）、さらにステップＳ１８０１のＩＯデバイスのハードリセット制御を開始した時刻から所定の時間Ｔ２が経過したか否かを判定し（ステップＳ１８０６）、時間Ｔ２が経過していない場合は、ステップ１８０２に戻りマルチルートＩＯデバイス１０２のハードリセット可能か再度判定する。
一方、所定の時間Ｔ２が経過した場合は、当該計算機１００のＩＯデバイスの障害処理を中止する（Ｓ１８０７）。なお、所定の時間Ｔ１、時間Ｔ２は、複合型計算機装置の製造時の初期値として設定されているか、あるいは、計算機の管理者が操作する管理端末１０６により設定される等、予め設定された時間である。
第３の実施形態により、例えば、障害処理の進捗が速い計算機１００のマルチルートＩＯデバイス１０２のハードリセットを、障害処理の進捗が遅い計算機１００に合わせて、遅らせることが可能になる。
＜第４実施形態＞
次に本発明の第４の実施の形態による複合型計算機の構成について説明する。第４の実施形態における複合型計算機は、第３の実施形態と同様に、図１に示した本発明の第１の実施形態の複合型計算機と、マルチルートＩＯマネージャ１０４のＩＯデバイスハードリセット制御の部分が異なる以外は同じである。従って、以下では第１の実施形態と異なる分部についてだけ説明し、同じ部分については説明を省略する。
図２０は第４の実施の形態による複合型計算機のＩＯデバイスのハードリセット制御の方法の一例を示したフローチャートである。第４の実施形態では、図５、図６、図８に示すマルチルートＩＯマネージャ１０４のＩＯデバイスハードリセット制御（図５のステップＳ４０７）の制御部分が、図２０に示す制御で置き換わる。
すなわち、図２０に示すように、ＢＭＣ１３３等からマルチルートＩＯデバイス１０２のハードリセット要求を受けたマルチルートＩＯマネージャ１０４は、マルチルートＩＯデバイス１０２のハードリセット制御を開始する（ステップＳ１９０１）。
次に、マルチルートＩＯマネージャ１０４は、ハードリセットを要求した計算機１００について、マルチルートＩＯデバイス１０２のハードリセット抑止が解除されているか否かを判定し（ステップＳ１９０２）、ハードリセット抑止が解除されハードリセット可能な場合は、マルチルートＩＯデバイス１０２のハードリセットの制御を実行し（ステップＳ１９０３）、マルチルートＩＯデバイス１０２のハードリセットの完了によりハードリセットの制御を完了する（ステップＳ１９０４）。
一方、ステップＳ１９０２の判定で、ハードリセット抑止されハードリセットができない場合は、ＩＯでデバイスのハードリセットの代わりに、マルチルートＩＯデバイス１０２を共有している他の計算機に影響を与えないマルチルートＩＯデバイス１０２のリセットを実行する（ステップＳ１９０５）。
このような、マルチルートＩＯデバイス１０２を共有している他の計算機に影響を与えないＩマルチルートＩＯデバイス１０２のリセットとしては、例えば、ＰＣＩのＦｕｎｃｔｉｏｎレベルリセットがある。すなわち、マルチルートＩＯデバイス１０２のＦｕｎｃｔｉｏｎ１２０毎にリセットをかけることで、当該マルチルートＩＯデバイス１０２を共有する他の計算機１００に障害回復処理の影響を与えるのを防ぐことができる。
第４の実施形態により、他の計算機１００よりもマルチルートＩＯデバイス１０２の障害処理の優先度Ｋ１６０１が低い計算機１００のＩＯデバイスの障害処理を中止することなく実行することが可能になる。
＜第５実施形態＞
次に本発明の第５の実施の形態による複合型計算機の構成について説明する。第５の実施形態における複合型計算機は、図１に示した本発明の第１の実施形態の複合型計算機と、図１に示すリソース管理ソフトウェア１３２の構成、図１０に示す計算機のプロファイル情報と、図１１に示した複合型計算機の計算機の構成方法、が異なる以外は同じである。従って、以下では第１の実施形態と異なる分部についてだけ説明し、同じ部分については説明を省略する。
図２１は第５の実施の形態による複合型計算機の管理サーバ１０５の構成図で、図２２は第５の実施の形態による複合型計算機のＩＯデバイスの障害処理ポリシー情報の一例を示した説明図である。図２３は第５の実施の形態による複合型計算機のサーバプロファイルの一例を示した説明図である。図２４は第５の実施の形態による複合型計算機の計算機の構成方法の一例を示したフローチャートである。
図２１に示すように、第５の実施形態では、図１に示した第１の実施形態のリソース管理ソフトウェア１３２に、ＩＯデバイスの障害処理ポリシー情報２００１が追加される。図２２に示すように、このＩＯデバイスの障害処理ポリシー情報２００１は、表形式ＦＴ２１で表すと、ＯＳ１１１、ＢＩＯＳ１１２、マルチルートＩＯデバイス１０２の障害処理方法のサポート条件Ｋ２１０１、Ｋ２１０２、Ｋ２１０３がそれぞれ設定され、各サポート条件Ｋ２１０１、Ｋ２１０２、Ｋ２１０３に対するポリシーレベル毎に選択される障害処理方法Ｋ２１０４、Ｋ２１０５の列から成る。
例えば、障害処理方法のサポート条件として、ＯＳ１１１は、ＩＯリトライ処理サポートで、かつＩＯ閉塞処理サポート（Ｋ２１０１）、ＢＩＯＳ１１２はＩＯリトライ処理サポートで、かつＩＯ閉塞処理サポート（Ｋ２１０２）、マルチルートＩＯデバイス１０２はＩＯリトライ処理サポートで、かつＩＯ閉塞処理サポート（Ｋ２１０３）の場合は、ポリシーレベルが「低」の場合はＯＳリブート処理（Ｋ２１０４）が選択される。
第１の実施形態ではマルチルートＩＯデバイス１０２に障害が発生したときのＩＯデバイスの障害処理方法を計算機の管理者が操作する管理端末１０６でマルチルートＩＯデバイス１０２毎に指定させたが、本第５の実施形態では、計算機の管理者にはポリシーレベルのみを管理端末１０６で指定させ、個々のＩＯデバイスの障害処理方法はリソース管理ソフトウェア１３２がポリシーレベルとＩＯデバイスの障害処理ポリシー情報２００１を用いることで自動的に決定する。従って、図２３に示すように、第５の実施形態のサーバプロファイル１２７は、図１０に示した第１の実施形態のサーバプロファイル１２７からマルチルートＩＯデバイス１０２のＩＯデバイスの障害処理方法Ｋ９０３の列を除き、ＩＯデバイスの障害処理のポリシーレベル２２０１を追加した情報となる。
次に、第５の実施形態における、計算機１００のユーザである管理者が操作する管理端末１０６から、新たにサーバを構築するために計算機を構成する場合の複合型計算機の制御方法について説明する。
図２４に示すように、計算機の管理者が操作する管理端末１０６からの要求により計算機の構成処理が開始する（ステップＳ２３０１）。計算機１００の管理者は管理端末１０６から、リソース管理ソフトウェア１３２に対して、必要な計算機１００の仕様を計算機のサーバプロファイル１２７により要求する（ステップＳ２３０２）。上述の通り、サーバプロファイル１２７は、計算機１００の仕様情報であり、ＣＰＵ１３４と、メモリ１３５と、マルチルートＩＯデバイス１０２と、ＯＳ１１１等の仕様情報を含む。
第５の実施形態では、サーバプロファイル１２７の内、特に本実施形態に関連するマルチルートＩＯデバイス１０２に関する情報は、表形式で表すと図２３のＦＴ２２に示す情報と、ＩＯデバイス障害時の障害処理方法のポリシーレベル２２０１と、を備える。なお、ポリシーレベル２２０１は管理端末１０６等から受け付けた値であり、例えば。「高」あるいは「低」である。
次に、物理リソース割当て制御部１２４は、複合型計算機の計算機１００でユーザに使用されていないものから、サーバプロファイル１２７に合った計算機１００を選択する（ステップＳ２３０３）。
次に、物理リソース割当て制御部１２４は、複合型計算機のマルチルートＩＯデバイス１０２のユーザに使用されていないものから、サーバプロファイル１２７に指定された特定の外部装置Ｋ９０５、例えば、ネットワークスイッチ、ストレージ装置、に接続できるか否かを判定する（ステップＳ２３０４）。
次に、物理リソース割当て制御部１２４は、ステップＳ２３０４の条件を満たすマルチルートＩＯデバイス１０２の中から、計算機１００のルートポート１１４毎にマルチルートＩＯデバイス１０２の障害処理方法Ｋ９０４が同一にできるか否かを判定する（ステップＳ２３０５）。
次に、物理リソース割当て制御部１２４は、図２３のポリシーレベル２２０１と、図２１に示すＩＯデバイスの障害処理ポリシー情報２００１と、ステップＳ２３０３で選択した計算機１００のＯＳ１１１の種類およびＢＩＯＳ１１２の種類の情報と、ステップＳ２３０５で選択したマルチルートＩＯデバイス１０２の情報、から、マルチルートＩＯデバイス１０２に障害が発生した場合の障害処理方法を決定する（ステップＳ２３０６）。
次に、物理リソース割当て制御部１２４は、サーバプロファイル１２７の障害発生時にマルチルートＩＯデバイス１０２の切り替えが、あり、すなわち、ＩＯデバイスの切り替えを行う指定がある場合は、複合型計算機のマルチルートＩＯデバイス１０２のユーザに使用されていないものから、切り替えが可能なものを選択できるか判定する（ステップＳ２３０７）。この判定では、図１１で述べた第１実施形態のステップＳ１００９と同じ判定処理、すなわち、マルチルートＩＯデバイス１０２がＩＯデバイスの障害処理方法をサポートしているか、外部装置に接続可能か否か、ルートポート１１４毎に障害処理方法を同一にできるか否か、の判定が行われる。これらの判定後、物理リソース割当て制御部１２４は、計算機１００に割当てるマルチルートＩＯデバイス１０２を選択し、マルチルートＩＯマネージャ１０４に計算機１００とマルチルートＩＯデバイス１０２の割当て設定を行い（ステップＳ２３１０）、計算機１００の構成が完了する（ステップＳ２３１１）。
一方、ステップＳ２３０４、Ｓ２３０５、Ｓ２３０７の判定処理を満たさなかった場合は、リソース管理ソフトウェア１３２は、計算機１００の管理者が操作する管理端末１０６にサーバプロファイル１２７で要求した仕様の計算機を構成できないと通知し、サーバプロファイル１２７の再設定をするか否かを判定する（ステップＳ２３０８）。計算機の管理者が操作する管理端末１０６でサーバプロファイル１２７の再設定を行う場合は、ステップＳ２３０２に戻りサーバプロファイル１２７の再設定を行う。一方、計算機の管理者が操作する管理端末１０６でサーバプロファイル１２７の再設定を行わない場合は、計算機の構成を中止する（ステップＳ２３０９）。
以上により、第５の実施形態では、管理者は管理端末１０６等からポリシーレベル２２０１を設定することで、マルチルートＩＯデバイス１０２に障害が発生した時の障害処理方法を自動的に選択することが可能となり、複合型計算機の管理に要する労力を低減することが可能となる。
なお、前記第１〜第５の実施形態においては、計算機１００で一つのＯＳ１１１を動作させる場合を示したが、計算機１００で仮想マシンマネージャを実行し、この仮想マシンマネージャ上で複数のＯＳ１１１を稼動させる仮想計算機に適用しても良い。仮想計算機に適用する場合では、前記第１〜第５の実施形態におけるＢＭＣ１３３からＯＳ１１１に対する通知を、ＢＭＣ１３３から仮想マシンマネージャに対する通知とすればよい。
なお、前記第１〜第５の実施形態においては、装置制御部１０３と、マルチルートＩＯマネージャ１０４と、リソース管理ソフトウェア１３２が異なる計算機で実行される例を示したが、装置制御部１０３と、マルチルートＩＯマネージャ１０４及びリソース管理ソフトウェア１３２が同一の計算機で実行されてもよい。
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
本発明の複合型計算機装置における制御方法は、ビジネス業務を止めることができない企業のデータセンタ等のＩＴシステム向けの計算機、例えば、ブレードサーバ装置やラックマウント型サーバ装置への適用が可能である。また、ブレードサーバ装置やラックマウント型サーバ装置を管理するソフトウェアに適用することができる。
本発明の第１の実施の形態による複合型計算機装置のブロック図。 本発明の第１の実施の形態による管理サーバのブロック図。 本発明の第１の実施の形態による複合型計算機のＩＯデバイス管理情報の一例を示した説明図。 本発明の第１の実施形態による複合型計算機のＩＯデバイス障害発生時の障害処理方法（ＯＳ停止処理）の一例を示したフローチャート。 本発明の第１の実施形態による複合型計算機のＩＯデバイス障害発生時の障害処理方法（ＯＳリブート処理）の一例を示したフローチャート。 本発明の第１の実施形態による複合型計算機のＩＯデバイス障害発生時の障害処理方法（ＩＯ閉塞処理）の一例を示したフローチャート。 本発明の第１の実施形態による複合型計算機のＩＯデバイス障害発生時の障害処理方法（ＩＯリトライ処理（１））の一例を示したフローチャート。 本発明の第１の実施形態による複合型計算機のＩＯデバイス障害発生時の障害処理方法（ＩＯリトライ処理（２））の一例を示したフローチャート。 本発明の第１の実施形態による複合型計算機のＩＯデバイス障害発生時の管理ソフトウェアによる障害処理方法の一例を示したフローチャート。 第１の実施の形態による複合型計算機のサーバプロファイルの一例を示した説明図。 本発明の第１の実施形態による複合型計算機の計算機の構成方法の一例を示したフローチャート。 本発明の第１の実施形態による複合型計算機の外部装置との接続関係の一例を示した説明図。 本発明の第１の実施形態による複合型計算機のルートポート毎の障害処理方法の指定の一例を示した説明図。 第１の実施の形態による複合型計算機のＩＯデバイス切り替え候補の情報の一例を示した説明図。 本発明の第１の実施形態による複合型計算機の計算機のＩＯデバイスの障害発生時のＩＯデバイス切り替え方法の一例を示したフローチャート。 本発明の第１の実施形態による複合型計算機のＩＯデバイスの障害発生時のＩＯデバイス切り替え対象となるＩＯデバイスを選択するグラフィカルインターフェースの一例を示した説明図。 第２の実施の形態による複合型計算機のＩＯデバイス管理情報の一例を示した説明図。 本発明の第２の実施形態による複合型計算機のＩＯデバイス障害発生時の管理ソフトウェアによる障害処理方法の一例を示したフローチャート。 第３の実施の形態による複合型計算機のＩＯデバイスのハードリセット制御の方法の一例を示したフローチャート。 第４の実施の形態による複合型計算機のＩＯデバイスのハードリセット制御の方法の一例を示したフローチャート。 第５の実施の形態による複合型計算機の管理サーバの構成図。 第５の実施の形態による複合型計算機のＩＯデバイスの障害処理ポリシー情報の一例を示した説明図。 第５の実施の形態による複合型計算機のサーバプロファイルの一例を示した説明図。 第５の実施の形態による複合型計算機の計算機の構成方法の一例を示したフローチャート。
符号の説明
１００、１００−１、１００−２、１００−３ 計算機
１０１ マルチルートＰＣＩ Ｅｘｐｒｅｓｓスイッチ
１０２、１０２−１、１０２−２、１０２−３、１０２−４ マルチルートＩＯデバイス
１０３ 装置制御部
１０４ マルチルートＩＯマネージャ
１０５ 管理サーバ
１０６ 管理端末
１０７、１０７−１、１０７−２ ネットワークスイッチ
１０８、１０８−１、１０８−２ ストレージ装置
１０９ 管理エージェントソフトウェア
１１０ デバイスドライバ
１１１ オペレーティングシステム
１１２ ＢＩＯＳ
１１３ チップセット
１１４、１１４−１１、１１４−１２、１１４−２１、１１４−２２、１１４−３１、１１４−３２ ルートポート
１１５ 物理ポート
１１６ 帯域モニタ部
１１７、１１８ 制御Ｉ／Ｆ
１１９ 管理ネットワーク
１２０ ＰＣＩ Ｆｕｎｃｔｉｏｎ
１２１ 物理ポート
１２２ 計算機の電源制御抑止部
１２３ ＩＯデバイスハードリセット抑止部
１２４ 物理リソース割当て制御部
１２５ 障害処理調停部
１２６ ＩＯデバイス切り替え制御部
１２７ サーバプロファイル
１２８ ＩＯデバイス管理情報
１３０ ネットワークインターフェース
１３１ ストレージネットワークインターフェース
１３２ リソース管理ソフトウェア
１３３ ＢＭＣ
１３４ ＣＰＵ
１３５ メモリ
１１０１１、１１０１２、１１０１３、１１０１４ ＶＬＡＮ
１２０ ＰＣＩ Ｆｕｎｃｔｉｏ
１５０１ グラフィカルインターフェース
１５０２ リソース管理ソフトウェアの管理画面
１５０３ 障害が発生したマルチルートＩＯデバイスの情報
１５０４ 切り替えの候補となるマルチルートＩＯデバイスの一覧
１５０５ ＩＯデバイスの切り替えの中止を指定する設定部
１５０６１、１５０６２、１５０６３ 切り替えの候補となるマルチルートＩＯデバイス
１５０７ マルチルートＩＯデバイスの識別子
１５０８ マルチルートＩＯデバイスの種類
１５０９ マルチルートＰＣＩ Ｅｘｐｒｅｓｓスイッチの識別子
１５１０ マルチルートＰＣＩ Ｅｘｐｒｅｓｓスイッチのポート番号
１５１１ マルチルートＩＯデバイスのＰＣＩ Ｆｕｎｃｔｉｏｎの識別子
１５１２ 使用する帯域情報
１５１３ 接続される外部装置の情報
１５１４ マルチルートＩＯデバイスの識別子
１５１５ マルチルートＰＣＩ Ｅｘｐｒｅｓｓスイッチの識別子
１５１６ マルチルートＰＣＩ Ｅｘｐｒｅｓｓスイッチのポート番号
１５１７ マルチルートＩＯデバイスのＰＣＩ ＦｕｎｃｔＩＯｎの識別子
１５１８ 空き帯域情報
１５１９ 計算機の管理者に選択させるための設定部
２００１ 障害処理ポリシー情報
２２０１ ＩＯデバイスの障害処理のポリシーレベル
ＦＴ２ ＩＯデバイス管理情報
ＦＴ９ サーバプロファイル
ＦＴ１３ ＩＯデバイス管理情報
ＦＴ１６ ＩＯデバイス管理情報
ＦＴ２１ ＩＯデバイスの障害処理ポリシー情報
ＦＴ２２ サーバプロファイル

Claims (15)

  1. 演算処理を行うプロセッサと、情報を記憶するメモリと、前記プロセッサに接続されてＰＣＩのインターフェースを含むチップセットと、を有する複数の計算機と、
    複数のＩＯデバイスと前記複数の計算機とを相互に接続する１以上のＰＣＩスイッチと、
    前記計算機への前記ＩＯデバイスの割当てを管理するリソース管理部と、
    前記計算機と前記ＩＯデバイスとの論理的な接続を行う前記ＰＣＩスイッチを制御するマルチルートＩＯマネージャと、を備えた複合型計算機装置であって、
    前記ＩＯデバイスは、前記複数の計算機で共有することが可能なマルチルートＩＯデバイスを含み、
    前記マルチルートＩＯマネージャは、
    前記ＰＣＩスイッチを監視して、前記マルチルートＩＯデバイスに障害が発生したときには、前記リソース管理部に前記マルチルートＩＯデバイスの障害を通知する監視部と、
    前記マルチルートＩＯデバイスに障害が発生したときには、前記マルチルートＩＯデバイスのハードウェアリセットを抑止するＩＯデバイスハードリセット抑止部と、を備え、
    前記リソース管理部は、
    前記マルチルートＩＯデバイスの管理情報として、少なくとも、前記マルチルートＩＯデバイスを共有している計算機毎に該マルチルートＩＯデバイスに障害が発生したときの障害処理の内容を示す障害処理内容情報と、該マルチルートＩＯデバイスを共有している計算機毎に、当該マルチルートＩＯデバイスをハードウェアリセットすることが可能か否かを示す障害処理ステータス情報と、を含むＩＯデバイス管理情報と、
    前記マルチルートＩＯマネージャから前記マルチルートＩＯデバイスの障害発生の通知を受信したときに、当該マルチルートＩＯデバイスを共有している各計算機から障害処理の進捗情報をそれぞれ取得して、前記障害処理ステータス情報を更新し、該障害処理ステータス情報に基づいて前記マルチルートＩＯマネージャにマルチルートＩＯデバイスのハードウェアリセットの抑止または解除の指令を通知する障害処理調停部と、を有し、
    前記計算機は、
    前記マルチルートＩＯデバイスに障害が発生したときは、前記障害処理内容情報の障害処理を実行し、当該障害処理がマルチルートＩＯデバイスのハードウェアリセットのときには、前記マルチルートＩＯマネージャに当該マルチルートＩＯデバイスのハードウェアリセットを要求し、
    前記ＩＯデバイスハードリセット抑止部は、
    前記各計算機から前記障害が発生したマルチルートＩＯデバイスに対する前記ハードウェアリセットの要求に対して、前記障害処理調停部から当該マルチルートＩＯデバイスについてハードウェアリセットの抑止の指令を受け付けたときには、当該マルチルートＩＯデバイスのハードウェアリセットを抑止することを特徴とする複合型計算機装置。
  2. 請求項１に記載の複合型計算機装置において、
    前記障害処理調停部は、
    前記計算機のすべての障害処理ステータス情報についてハードウェアリセットが可能な場合に、前記ＩＯデバイスハードリセット抑止部に対して当該マルチルートＩＯデバイスのハードウェアリセットの抑止を解除することを特徴とする複合型計算機装置。
  3. 請求項１に記載の複合型計算機装置において、
    前記リソース管理部の前記ＩＯデバイス管理情報は、
    前記マルチルートＩＯデバイスを共有する前記計算機の障害処理ステータス毎に該マルチルートＩＯデバイスの障害処理の優先度情報を有し、
    前記ＩＯデバイスハードリセット抑止部は、
    前記マルチルートＩＯデバイスを共有する計算機毎にハードウェアリセットを抑止し、
    前記リソース管理部の障害処理調停部は、
    前記マルチルートＩＯデバイスの障害発生時に、当該障害の発生したマルチルートＩＯデバイスが割り当てられた計算機について前記ＩＯデバイス管理情報を参照し、前記ＩＯデバイス管理情報で指定された障害処理の優先度が所定値以上の計算機のうち、すべての障害処理ステータス情報についてハードウェアリセットが可能な場合に、前記ＩＯデバイスハードリセット抑止部に対して当該マルチルートＩＯデバイスのハードリセットの抑止を解除することを特徴とする複合型計算機装置。
  4. 請求項１に記載の複合型計算機装置において、
    前記リソース管理部は、
    前記計算機に前記ＩＯデバイスの割当てを行うための情報を予め格納したサーバプロファイル情報と、
    前記サーバプロファイル情報に基づいて、前記計算機に前記ＩＯデバイスを割当てる物理リソース割当て制御部をさらに有し、
    前記サーバプロファイル情報は、
    前記計算機に割当てるＩＯデバイス毎に該ＩＯデバイスの種類と、当該ＩＯデバイスに障害が発生したときの障害処理の内容と、当該ＩＯデバイスを割り当てた計算機で動作させるオペレーティングシステムの種類と、を含み、
    前記物理リソース割当て制御部は、
    前記計算機に前記ＩＯデバイスを割当てる際に、前記計算機で動作させるオペレーティングシステムが前記サーバプロファイル情報に格納された前記障害処理の内容を実行可能であり、かつ前記計算機に搭載されたチップセットが前記サーバプロファイル情報に格納された前記障害処理の内容を実行可能であり、かつ前記計算機に搭載されたＢＩＯＳが前記サーバプロファイル情報に格納された前記障害処理の内容を実行可能である、かつ前記計算機に割り当てるＩＯデバイスが前記サーバプロファイル情報に格納された前記障害処理の内容を実行であるときに、前記計算機に前記ＩＯデバイスを割り当てることを特徴とする複合型計算機装置。
  5. 請求項４に記載の複合型計算機装置において、
    前記リソース管理部の物理リソース割当て制御部は、
    前記ＩＯデバイスを割り当てる計算機のＰＣＩバス上のルートポート毎に、当該ルートポート以下のＰＣＩツリーに割当てたすべてのＩＯデバイスについて、前記サーバプロファイル情報の障害処理の内容が実行可能であるときに、前記計算機に前記ＩＯデバイスを割り当てることを特徴とする複合型計算機装置。
  6. 請求項５に記載の複合型計算機装置において、
    前記計算機は、前記マルチルートＩＯデバイスに障害が発生したときに、前記ＩＯデバイス管理情報で指定された障害処理内容情報がマルチルートＩＯデバイスのハードウェアリセットで、前記ＩＯデバイスハードリセット抑止部が当該マルチルートＩＯデバイスのハードウェアリセットを抑止している場合には、第１の所定時間が経過した後に当該マルチルートＩＯデバイスのハードリセットを再要求し、第２の所定時間が経過した後には障害処理を中断し、前記第２の所定時間が経過する以前に、当該マルチルートＩＯデバイスのハードウェアリセットの抑止が解除されたときには、当該マルチルートＩＯデバイスのハードウェアリセットを前記マルチルートＩＯマネージャに要求することを特徴とする複合型計算機装置。
  7. 請求項６に記載の複合型計算機装置において、
    前記リソース管理部は、
    前記計算機が実行するオペレーティングシステムと、前記計算機のＢＩＯＳと、前記計算機に割り当てるＩＯデバイスの障害処理のサポート条件と、前記サポート条件に対応して障害処理のレベルに応じた障害処理の内容を示す障害処理ポリシー情報を保持し、
    前記サーバプロファイル情報は、
    前記計算機に割り当てる前記ＩＯデバイスの種類の情報と、前記計算機で動作させるオペレーティングシステムの種類と、障害処理ポリシーのレベル情報を含み、
    前記物理リソース割当て制御部は、
    前記サーバプロファイル情報に基づいて前記計算機に前記ＩＯデバイスを割当てる際に、前記サーバプロファイル情報の前記オペレーティングシステムの種類と、前記計算機に搭載されたＢＩＯＳと、前記計算機に割り当てるＩＯデバイスが、前記障害処理ポリシーのレベルが前記障害処理ポリシー情報の前記障害処理のレベルに一致する前記障害処理のサポート条件を満足する物理リソースを割り当てることを特徴とする複合型計算機装置。
  8. 演算処理を行うプロセッサと、情報を記憶するメモリと、前記プロセッサに接続されてＰＣＩのインターフェースを含むチップセットと、を有する複数の計算機と、
    複数のＩＯデバイスと前記複数の計算機とを相互に接続する１以上のＰＣＩスイッチと、
    前記計算機への前記ＩＯデバイスの割当てを管理するリソース管理部と、
    前記計算機と前記ＩＯデバイスとの論理的な接続を行う前記ＰＣＩスイッチを制御するマルチルートＩＯマネージャと、を備えた複合型計算機装置で前記ＩＯデバイスに障害が発生したときに前記障害の回復処理を行う複合型計算機装置の管理方法であって、
    前記ＩＯデバイスは、前記複数の計算機で共有することが可能なマルチルートＩＯデバイスを含み、
    前記リソース管理部が、前記マルチルートＩＯデバイスの管理情報として、少なくとも、前記マルチルートＩＯデバイスを共有している計算機毎に該マルチルートＩＯデバイスに障害が発生したときの障害処理の内容を示す障害処理内容情報と、該マルチルートＩＯデバイスを共有している計算機毎に、当該マルチルートＩＯデバイスをハードウェアリセットすることが可能か否かを示す障害処理ステータス情報と、を含むＩＯデバイス管理情報を設定するステップと、
    前記マルチルートＩＯマネージャが、前記ＰＣＩスイッチを監視して、前記マルチルートＩＯデバイスに障害が発生したときには、前記リソース管理部に前記マルチルートＩＯデバイスの障害を通知するステップと、
    前記マルチルートＩＯマネージャが、前記ＰＣＩスイッチを監視して、前記マルチルートＩＯデバイスに障害が発生したときには、前記障害の発生したマルチルートＩＯデバイスのハードウェアリセットを抑止するステップと、
    前記リソース管理部が、前記マルチルートＩＯマネージャから前記マルチルートＩＯデバイスの障害発生の前記通知を受信したときに、当該マルチルートＩＯデバイスを共有している各計算機から障害処理の進捗情報を取得するステップと、
    前記リソース管理部が、前記取得した障害処理の進捗情報から前記障害処理ステータス情報を更新するステップと、
    前記リソース管理部が、前記更新した障害処理ステータス情報と、に基づいて前記マルチルートＩＯマネージャにマルチルートＩＯデバイスのハードウェアリセットの抑止または解除の指令を通知するステップと、
    前記計算機が、前記マルチルートＩＯデバイスに障害が発生したときは、前記障害処理内容情報の障害処理を実行し、当該障害処理がマルチルートＩＯデバイスのハードウェアリセットのときには、前記マルチルートＩＯマネージャに当該マルチルートＩＯデバイスのハードウェアリセットを要求するステップと、
    前記マルチルートＩＯマネージャが、前記各計算機から前記障害が発生したマルチルートＩＯデバイスに対する前記ハードウェアリセットの要求を受信し、前記リソース管理部から当該マルチルートＩＯデバイスについてハードウェアリセットの抑止の指令を受け付けたときには、当該マルチルートＩＯデバイスのハードウェアリセットを抑止するステップと、
    を含むことを特徴とする複合型計算機装置の管理方法。
  9. 請求項８に記載の複合型計算機装置の管理方法において、
    前記リソース管理部が、前記更新した障害処理ステータス情報と、に基づいて前記マルチルートＩＯマネージャにマルチルートＩＯデバイスのハードウェアリセットの抑止または解除の指令を通知するステップは、
    前記リソース管理部が、前記計算機のすべての障害処理ステータス情報についてハードウェアリセットが可能な場合に、前記マルチルートＩＯマネージャに対して当該マルチルートＩＯデバイスのハードウェアリセットの抑止を解除する指令を通知することを特徴とする複合型計算機装置の管理方法。
  10. 請求項８に記載の複合型計算機装置の管理方法において、
    前記リソース管理部が、前記マルチルートＩＯデバイスの管理情報として、少なくとも、前記マルチルートＩＯデバイスを共有している計算機毎に該マルチルートＩＯデバイスに障害が発生したときの障害処理の内容を示す障害処理内容情報と、該マルチルートＩＯデバイスを共有している計算機毎に、当該マルチルートＩＯデバイスをハードウェアリセットすることが可能か否かを示す障害処理ステータス情報と、を含むＩＯデバイス管理情報を設定するステップは、
    前記マルチルートＩＯデバイスを共有する前記計算機の障害処理ステータス毎に該マルチルートＩＯデバイスの障害処理の優先度情報を設定し、
    前記リソース管理部が、前記更新した障害処理ステータス情報と、に基づいて前記マルチルートＩＯマネージャにマルチルートＩＯデバイスのハードウェアリセットの抑止または解除の指令を通知するステップは、
    前記リソース管理部が、前記マルチルートＩＯデバイスの障害発生時に、当該障害の発生したマルチルートＩＯデバイスが割り当てられた計算機について前記ＩＯデバイス管理情報を参照し、前記ＩＯデバイス管理情報で指定された障害処理の優先度が所定値以上の計算機のうち、すべての障害処理ステータス情報についてハードウェアリセットが可能な場合に、前記マルチルートＩＯマネージャに対して当該マルチルートＩＯデバイスのハードリセットの抑止を解除する指令を通知することを特徴とする複合型計算機装置の管理方法。
  11. 請求項８に記載の複合型計算機装置の管理方法において、
    前記リソース管理部が、前記計算機に前記ＩＯデバイスの割当てを行うための情報をサーバプロファイル情報に格納するステップと、
    前記リソース管理部が、前記サーバプロファイル情報に基づいて、前記計算機に前記ＩＯデバイスを割当てるステップと、をさらに含み、
    前記サーバプロファイル情報は、
    前記計算機に割当てるＩＯデバイス毎に該ＩＯデバイスの種類と、当該ＩＯデバイスに障害が発生したときの障害処理の内容と、当該ＩＯデバイスを割り当てた計算機で動作させるオペレーティングシステムの種類と、を含み、
    前記リソース管理部が、前記サーバプロファイル情報に基づいて、前記計算機に前記ＩＯデバイスを割当てるステップは、
    前記リソース管理部が、前記計算機に前記ＩＯデバイスを割当てる際に、前記計算機で動作させるオペレーティングシステムが前記サーバプロファイル情報に格納された前記障害処理の内容を実行可能であり、かつ前記計算機に搭載されたチップセットが前記サーバプロファイル情報に格納された前記障害処理の内容を実行可能であり、かつ前記計算機に搭載されたＢＩＯＳが前記サーバプロファイル情報に格納された前記障害処理の内容を実行可能である、かつ前記計算機に割り当てるＩＯデバイスが前記サーバプロファイル情報に格納された前記障害処理の内容を実行であるときに、前記計算機に前記ＩＯデバイスを割り当てることを特徴とする複合型計算機装置の管理方法。
  12. 請求項１１に記載の複合型計算機装置の管理方法において、
    前記リソース管理部が、前記サーバプロファイル情報に基づいて、前記計算機に前記ＩＯデバイスを割当てるステップは、
    前記ＩＯデバイスを割り当てる計算機のＰＣＩバス上のルートポート毎に、当該ルートポート以下のＰＣＩツリーに割当てたすべてのＩＯデバイスについて、前記サーバプロファイル情報の障害処理の内容が実行可能であるときに、前記計算機に前記ＩＯデバイスを割り当てることを特徴とする複合型計算機装置の管理方法。
  13. 請求項１２に記載の複合型計算機装置の管理方法において、
    前記計算機は、前記マルチルートＩＯデバイスに障害が発生したときに、前記ＩＯデバイス管理情報で指定された障害処理内容情報がマルチルートＩＯデバイスのハードウェアリセットで、前記マルチルートＩＯマネージャが当該マルチルートＩＯデバイスのハードウェアリセットを抑止している場合には、第１の所定時間が経過した後に当該マルチルートＩＯデバイスのハードリセットを再要求し、第２の所定時間が経過した後には障害処理を中断し、前記第２の所定時間が経過する以前に、当該マルチルートＩＯデバイスのハードウェアリセットの抑止が解除されたときには、当該マルチルートＩＯデバイスのハードウェアリセットを前記マルチルートＩＯマネージャに要求することを特徴とする複合型計算機装置の管理方法。
  14. 請求項１３に記載の複合型計算機装置の管理方法において、
    前記リソース管理部が、前記計算機が実行するオペレーティングシステムと、前記計算機のＢＩＯＳと、前記計算機に割り当てるＩＯデバイスの障害処理のサポート条件と、前記サポート条件に対応して障害処理のレベルに応じた障害処理の内容を示す障害処理ポリシー情報を保持するステップをさらに含み、
    前記リソース管理部が、前記計算機に前記ＩＯデバイスの割当てを行うための情報をサーバプロファイル情報に格納するステップは、
    前記計算機に割り当てる前記ＩＯデバイスの種類の情報と、前記計算機で動作させるオペレーティングシステムの種類と、障害処理ポリシーのレベル情報を含み、
    前記リソース管理部が、前記サーバプロファイル情報に基づいて、前記計算機に前記ＩＯデバイスを割当てるステップは、
    前記リソース管理部が前記サーバプロファイル情報に基づいて前記計算機に前記ＩＯデバイスを割当てる際に、前記サーバプロファイル情報の前記オペレーティングシステムの種類と、前記計算機に搭載されたＢＩＯＳと、前記計算機に割り当てるＩＯデバイスが、前記障害処理ポリシーのレベルが前記障害処理ポリシー情報の前記障害処理のレベルに一致する前記障害処理のサポート条件を満足する物理リソースを割り当てることを特徴とする複合型計算機装置の管理方法。
  15. 演算処理を行うプロセッサと、情報を記憶するメモリと、を備えて、一つの入出力デバイスと複数の物理計算機とを相互に接続する１以上のＰＣＩスイッチに接続された入出力マネージャを制御する管理サーバにおいて、
    前記入出力デバイスは、前記２以上の物理計算機に対応付けられ、
    前記管理サーバは、
    ２以上の物理計算機と前記入出力デバイスとの対応付けを管理するリソース管理部を有し、
    前記リソース管理部は、
    該入出力デバイスに障害が発生したときの障害処理の内容を対応付けられている前記物理計算機毎に示す障害処理内容情報と、該入出力デバイスを共有している物理計算機毎に、当該入出力デバイスをハードウェアリセットすることが可能か否かを示す障害処理ステータス情報と、を含む入出力デバイス管理情報と、
    前記入出力マネージャから前記入出力デバイスの障害発生の通知を受信したときに、当該入出力デバイスに対応付けられる物理計算機から障害処理の進捗情報をそれぞれ取得して、前記障害処理ステータス情報を更新し、当該障害処理ステータス情報に基づいて前記入出力マネージャに前記入出力デバイスのハードウェアリセットの抑止または解除の指令を通知する障害処理調停部と、を有することを特徴とする管理サーバ。
JP2008321136A 2008-12-17 2008-12-17 複合型計算機装置、複合型計算機の管理方法及び管理サーバ Expired - Fee Related JP5332000B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2008321136A JP5332000B2 (ja) 2008-12-17 2008-12-17 複合型計算機装置、複合型計算機の管理方法及び管理サーバ
US12/635,755 US8046520B2 (en) 2008-12-17 2009-12-11 Compound computer system and method for sharing PCI devices thereof

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008321136A JP5332000B2 (ja) 2008-12-17 2008-12-17 複合型計算機装置、複合型計算機の管理方法及び管理サーバ

Publications (3)

Publication Number Publication Date
JP2010146175A JP2010146175A (ja) 2010-07-01
JP2010146175A5 JP2010146175A5 (ja) 2011-10-13
JP5332000B2 true JP5332000B2 (ja) 2013-10-30

Family

ID=42241926

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008321136A Expired - Fee Related JP5332000B2 (ja) 2008-12-17 2008-12-17 複合型計算機装置、複合型計算機の管理方法及び管理サーバ

Country Status (2)

Country Link
US (1) US8046520B2 (ja)
JP (1) JP5332000B2 (ja)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5272265B2 (ja) 2008-09-29 2013-08-28 株式会社日立製作所 Ｐｃｉデバイス共有方法
JP5401679B2 (ja) * 2009-02-19 2014-01-29 株式会社日立製作所 計算機システム、管理方法及び管理サーバ
JP5281942B2 (ja) * 2009-03-26 2013-09-04 株式会社日立製作所 計算機およびその障害処理方法
JP5074457B2 (ja) * 2009-06-04 2012-11-14 株式会社日立製作所 計算機システム、スイッチ切り替え方法及びｐｃｉスイッチ
US8938568B2 (en) 2010-08-19 2015-01-20 Ineda Systems Pvt. Ltd Multi-processor electronic systems
TW201224288A (en) * 2010-12-01 2012-06-16 Hon Hai Prec Ind Co Ltd System and method for controlling a fan
CN102486180A (zh) * 2010-12-02 2012-06-06 鸿富锦精密工业（深圳）有限公司 风扇控制系统及方法
WO2012140667A2 (en) * 2011-04-11 2012-10-18 Ineda Systems Pvt. Ltd Application sharing in multi host computing systems
JP6048402B2 (ja) 2011-06-08 2016-12-21 日本電気株式会社 コンピュータシステム、接続装置、電源制御方法、及び電源制御プログラム
US20130179601A1 (en) * 2012-01-10 2013-07-11 Hitachi, Ltd. Node provisioning of i/o module having one or more i/o devices
CN102707991B (zh) * 2012-05-17 2016-03-30 中国科学院计算技术研究所 多根i/o虚拟化共享方法和系统
CN102819447B (zh) * 2012-05-29 2015-06-03 中国科学院计算技术研究所 一种用于多根共享系统的直接i/o虚拟化方法和装置
US9529656B2 (en) 2012-06-22 2016-12-27 Hitachi, Ltd. Computer recovery method, computer system, and storage medium
GB2515053A (en) * 2013-06-12 2014-12-17 Acano Uk Ltd Collaboration Server
CN103353861B (zh) * 2013-06-18 2016-06-29 中国科学院计算技术研究所 实现分布式i/o资源池化的方法及装置
US9335986B1 (en) * 2013-12-11 2016-05-10 Amazon Technologies, Inc. Hot patching to update program code and/or variables using a separate processor
US9604585B2 (en) * 2014-07-11 2017-03-28 Ford Global Technologies, Llc Failure management in a vehicle
CN104454616A (zh) * 2014-12-26 2015-03-25 浪潮电子信息产业股份有限公司 一种精确调控风扇转速的方法
CN105224246B (zh) * 2015-09-25 2018-11-09 联想(北京)有限公司 一种信息以及内存配置方法和装置
CN109302386B (zh) * 2018-09-11 2020-08-25 网御安全技术（深圳）有限公司 一种服务器压缩解压缩刀片、系统、及压缩解压缩方法
US11194589B2 (en) * 2019-01-08 2021-12-07 Dell Products L.P. Information handling system adaptive component reset
US12072966B2 (en) * 2021-07-08 2024-08-27 Dell Products, L.P. System and method for device authentication using a baseboard management controller (BMC)

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5068851A (en) * 1989-08-01 1991-11-26 Digital Equipment Corporation Apparatus and method for documenting faults in computing modules
JP2663896B2 (ja) * 1995-01-20 1997-10-15 日本電気株式会社 バス障害処理システム
JP3565767B2 (ja) 2000-07-19 2004-09-15 トラストガード株式会社 カートリッジ型サーバユニットおよび該サーバユニット搭載用筐体ならびにサーバ装置
US7058738B2 (en) 2004-04-28 2006-06-06 Microsoft Corporation Configurable PCI express switch which allows multiple CPUs to be connected to multiple I/O devices
JP2006171952A (ja) * 2004-12-14 2006-06-29 Renesas Technology Corp 半導体集積回路装置
US7707465B2 (en) * 2006-01-26 2010-04-27 International Business Machines Corporation Routing of shared I/O fabric error messages in a multi-host environment to a master control root node

Also Published As

Publication number Publication date
US20100153615A1 (en) 2010-06-17
US8046520B2 (en) 2011-10-25
JP2010146175A (ja) 2010-07-01

Similar Documents

Publication Publication Date Title
JP5332000B2 (ja) 複合型計算機装置、複合型計算機の管理方法及び管理サーバ
US7802127B2 (en) Method and computer system for failover
US9606745B2 (en) Storage system and method for allocating resource
JP4295184B2 (ja) 仮想計算機システム
US8874952B2 (en) Computer system and availability method thereof
EP4083777B1 (en) Resource control node and method
US8060775B1 (en) Method and apparatus for providing dynamic multi-pathing (DMP) for an asymmetric logical unit access (ALUA) based storage system
US8312319B2 (en) Failover method through disk takeover and computer system having failover function
US8346997B2 (en) Use of peripheral component interconnect input/output virtualization devices to create redundant configurations
US8713362B2 (en) Obviation of recovery of data store consistency for application I/O errors
JP6458146B2 (ja) 計算機及びメモリ領域管理方法
US20130290541A1 (en) Resource management system and resource managing method
US9361255B2 (en) Method for controlling I/O switch, method for controlling virtual computer, and computer system
US8286163B2 (en) Coupling between server and storage apparatus using detected I/O adaptor and allowing application execution based on access group and port connection group in virtualized environment
JP2014106587A (ja) Ｉ／ｏデバイスの制御方法及び仮想計算機システム
WO2013157072A1 (ja) 計算機システム、リソース管理方法及び管理計算機
WO2015114816A1 (ja) 管理計算機および管理プログラム
WO2012004902A1 (ja) 計算機システム及び計算機システムの系切替制御方法
JP5321658B2 (ja) フェイルオーバ方法、およびその計算機システム。
EP2693718B1 (en) Information processing system, collecting program, and collecting method

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110831

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20110831

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120309

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20121221

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130312

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130508

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130702

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130709

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees