(57)【要約】【課題】ＩＯデバイスを複数の計算機で共有する場合に、ＩＯデバイスに障害が発生した際に行われる計算機毎の障害処理を計算機間で調停する。【解決手段】複数のＩＯデバイスと複数の計算機を接続するＰＣＩスイッチに接続されたマルチルートＩＯマネージャを制御する管理サーバのリソース管理部は、マルチルートＩＯデバイスを共有する計算機毎にマルチルートＩＯデバイスに障害が発生したときの障害処理の内容を示す障害処理内容情報と、マルチルートＩＯデバイスをハードウェアリセットすることが可能か否かを示す障害処理ステータス情報と、マルチルートＩＯデバイスの障害発生の通知を受信したときに、障害処理ステータス情報を更新し、当該障害処理ステータス情報に基づいてマルチルートＩＯマネージャにマルチルートＩＯデバイスのハードウェアリセットの抑止または解除の指令を通知する。【選択図】図２
2010146175.tif 000002
【特許請求の範囲】
【請求項１】
演算処理を行うプロセッサと、情報を記憶するメモリと、前記プロセッサに接続されてＰＣＩのインターフェースを含むチップセットと、を有する複数の計算機と、
複数のＩＯデバイスと前記複数の計算機とを相互に接続する１以上のＰＣＩスイッチと、
前記計算機への前記ＩＯデバイスの割当てを管理するリソース管理部と、
前記計算機と前記ＩＯデバイスとの論理的な接続を行う前記ＰＣＩスイッチを制御するマルチルートＩＯマネージャと、を備えた複合型計算機装置であって、
前記ＩＯデバイスは、前記複数の計算機で共有することが可能なマルチルートＩＯデバイスを含み、
前記マルチルートＩＯマネージャは、
前記ＰＣＩスイッチを監視して、前記マルチルートＩＯデバイスに障害が発生したときには、前記リソース管理部に前記マルチルートＩＯデバイスの障害を通知する監視部と、
前記マルチルートＩＯデバイスに障害が発生したときには、前記マルチルートＩＯデバイスのハードウェアリセットを抑止するＩＯデバイスハードリセット抑止部と、を備え、
前記リソース管理部は、
前記マルチルートＩＯデバイスの管理情報として、少なくとも、前記マルチルートＩＯデバイスを共有している計算機毎に該マルチルートＩＯデバイスに障害が発生したときの障害処理の内容を示す障害処理内容情報と、該マルチルートＩＯデバイスを共有している計算機毎に、当該マルチルートＩＯデバイスをハードウェアリセットすることが可能か否かを示す障害処理ステータス情報と、を含むＩＯデバイス管理情報と、
前記マルチルートＩＯマネージャから前記マルチルートＩＯデバイスの障害発生の通知を受信したときに、当該マルチルートＩＯデバイスを共有している各計算機から障害処理の進捗情報をそれぞれ取得して、前記障害処理ステータス情報を更新し、該障害処理ステータス情報に基づいて前記マルチルートＩＯマネージャにマルチルートＩＯデバイスのハードウェアリセットの抑止または解除の指令を通知する障害処理調停部と、を有し、
前記計算機は、
前記マルチルートＩＯデバイスに障害が発生したときは、前記障害処理内容情報の障害処理を実行し、当該障害処理がマルチルートＩＯデバイスのハードウェアリセットのときには、前記マルチルートＩＯマネージャに当該マルチルートＩＯデバイスのハードウェアリセットを要求し、
前記ＩＯデバイスハードリセット抑止部は、
前記各計算機から前記障害が発生したマルチルートＩＯデバイスに対する前記ハードウェアリセットの要求に対して、前記障害処理調停部から当該マルチルートＩＯデバイスについてハードウェアリセットの抑止の指令を受け付けたときには、当該マルチルートＩＯデバイスのハードウェアリセットを抑止することを特徴とする複合型計算機装置。
【請求項２】
請求項１に記載の複合型計算機装置において、
前記障害処理調停部は、
前記計算機のすべての障害処理ステータス情報についてハードウェアリセットが可能な場合に、前記ＩＯデバイスハードリセット抑止部に対して当該マルチルートＩＯデバイスのハードウェアリセットの抑止を解除することを特徴とする複合型計算機装置。
【請求項３】
請求項１に記載の複合型計算機装置において、
前記リソース管理部の前記ＩＯデバイス管理情報は、
前記マルチルートＩＯデバイスを共有する前記計算機の障害処理ステータス毎に該マルチルートＩＯデバイスの障害処理の優先度情報を有し、
前記ＩＯデバイスハードリセット抑止部は、
前記マルチルートＩＯデバイスを共有する計算機毎にハードウェアリセットを抑止し、
前記リソース管理部の障害処理調停部は、
前記マルチルートＩＯデバイスの障害発生時に、当該障害の発生したマルチルートＩＯデバイスが割り当てられた計算機について前記ＩＯデバイス管理情報を参照し、前記ＩＯデバイス管理情報で指定された障害処理の優先度が所定値以上の計算機のうち、すべての障害処理ステータス情報についてハードウェアリセットが可能な場合に、前記ＩＯデバイスハードリセット抑止部に対して当該マルチルートＩＯデバイスのハードリセットの抑止を解除することを特徴とする複合型計算機装置。
【請求項４】
請求項１に記載の複合型計算機装置において、
前記リソース管理部は、
前記計算機に前記ＩＯデバイスの割当てを行うための情報を予め格納したサーバプロファイル情報と、
前記サーバプロファイル情報に基づいて、前記計算機に前記ＩＯデバイスを割当てる物理リソース割当て制御部をさらに有し、
前記サーバプロファイル情報は、
前記計算機に割当てるＩＯデバイス毎に該ＩＯデバイスの種類と、当該ＩＯデバイスに障害が発生したときの障害処理の内容と、当該ＩＯデバイスを割り当てた計算機で動作させるオペレーティングシステムの種類と、を含み、
前記物理リソース割当て制御部は、
前記計算機に前記ＩＯデバイスを割当てる際に、前記計算機で動作させるオペレーティングシステムが前記サーバプロファイル情報に格納された前記障害処理の内容を実行可能であり、かつ前記計算機に搭載されたチップセットが前記サーバプロファイル情報に格納された前記障害処理の内容を実行可能であり、かつ前記計算機に搭載されたＢＩＯＳが前記サーバプロファイル情報に格納された前記障害処理の内容を実行可能である、かつ前記計算機に割り当てるＩＯデバイスが前記サーバプロファイル情報に格納された前記障害処理の内容を実行であるときに、前記計算機に前記ＩＯデバイスを割り当てることを特徴とする複合型計算機装置。
【請求項５】
請求項４に記載の複合型計算機装置において、
前記リソース管理部の物理リソース割当て制御部は、
前記ＩＯデバイスを割り当てる計算機のＰＣＩバス上のルートポート毎に、当該ルートポート以下のＰＣＩツリーに割当てたすべてのＩＯデバイスについて、前記サーバプロファイル情報の障害処理の内容が実行可能であるときに、前記計算機に前記ＩＯデバイスを割り当てることを特徴とする複合型計算機装置。
【請求項６】
請求項５に記載の複合型計算機装置において、
前記計算機は、前記マルチルートＩＯデバイスに障害が発生したときに、前記ＩＯデバイス管理情報で指定された障害処理内容情報がマルチルートＩＯデバイスのハードウェアリセットで、前記ＩＯデバイスハードリセット抑止部が当該マルチルートＩＯデバイスのハードウェアリセットを抑止している場合には、第１の所定時間が経過した後に当該マルチルートＩＯデバイスのハードリセットを再要求し、第２の所定時間が経過した後には障害処理を中断し、前記第２の所定時間が経過する以前に、当該マルチルートＩＯデバイスのハードウェアリセットの抑止が解除されたときには、当該マルチルートＩＯデバイスのハードウェアリセットを前記マルチルートＩＯマネージャに要求することを特徴とする複合型計算機装置。
【請求項７】
請求項６に記載の複合型計算機装置において、
前記リソース管理部は、
前記計算機が実行するオペレーティングシステムと、前記計算機のＢＩＯＳと、前記計算機に割り当てるＩＯデバイスの障害処理のサポート条件と、前記サポート条件に対応して障害処理のレベルに応じた障害処理の内容を示す障害処理ポリシー情報を保持し、
前記サーバプロファイル情報は、
前記計算機に割り当てる前記ＩＯデバイスの種類の情報と、前記計算機で動作させるオペレーティングシステムの種類と、障害処理ポリシーのレベル情報を含み、
前記物理リソース割当て制御部は、
前記サーバプロファイル情報に基づいて前記計算機に前記ＩＯデバイスを割当てる際に、前記サーバプロファイル情報の前記オペレーティングシステムの種類と、前記計算機に搭載されたＢＩＯＳと、前記計算機に割り当てるＩＯデバイスが、前記障害処理ポリシーのレベルが前記障害処理ポリシー情報の前記障害処理のレベルに一致する前記障害処理のサポート条件を満足する物理リソースを割り当てることを特徴とする複合型計算機装置。
【請求項８】
演算処理を行うプロセッサと、情報を記憶するメモリと、前記プロセッサに接続されてＰＣＩのインターフェースを含むチップセットと、を有する複数の計算機と、
複数のＩＯデバイスと前記複数の計算機とを相互に接続する１以上のＰＣＩスイッチと、
前記計算機への前記ＩＯデバイスの割当てを管理するリソース管理部と、
前記計算機と前記ＩＯデバイスとの論理的な接続を行う前記ＰＣＩスイッチを制御するマルチルートＩＯマネージャと、を備えた複合型計算機装置で前記ＩＯデバイスに障害が発生したときに前記障害の回復処理を行う複合型計算機装置の管理方法であって、
前記ＩＯデバイスは、前記複数の計算機で共有することが可能なマルチルートＩＯデバイスを含み、
前記リソース管理部が、前記マルチルートＩＯデバイスの管理情報として、少なくとも、前記マルチルートＩＯデバイスを共有している計算機毎に該マルチルートＩＯデバイスに障害が発生したときの障害処理の内容を示す障害処理内容情報と、該マルチルートＩＯデバイスを共有している計算機毎に、当該マルチルートＩＯデバイスをハードウェアリセットすることが可能か否かを示す障害処理ステータス情報と、を含むＩＯデバイス管理情報を設定するステップと、
前記マルチルートＩＯマネージャが、前記ＰＣＩスイッチを監視して、前記マルチルートＩＯデバイスに障害が発生したときには、前記リソース管理部に前記マルチルートＩＯデバイスの障害を通知するステップと、
前記マルチルートＩＯマネージャが、前記ＰＣＩスイッチを監視して、前記マルチルートＩＯデバイスに障害が発生したときには、前記障害の発生したマルチルートＩＯデバイスのハードウェアリセットを抑止するステップと、
前記リソース管理部が、前記マルチルートＩＯマネージャから前記マルチルートＩＯデバイスの障害発生の前記通知を受信したときに、当該マルチルートＩＯデバイスを共有している各計算機から障害処理の進捗情報を取得するステップと、
前記リソース管理部が、前記取得した障害処理の進捗情報から前記障害処理ステータス情報を更新するステップと、
前記リソース管理部が、前記更新した障害処理ステータス情報と、に基づいて前記マルチルートＩＯマネージャにマルチルートＩＯデバイスのハードウェアリセットの抑止または解除の指令を通知するステップと、
前記計算機が、前記マルチルートＩＯデバイスに障害が発生したときは、前記障害処理内容情報の障害処理を実行し、当該障害処理がマルチルートＩＯデバイスのハードウェアリセットのときには、前記マルチルートＩＯマネージャに当該マルチルートＩＯデバイスのハードウェアリセットを要求するステップと、
前記マルチルートＩＯマネージャが、前記各計算機から前記障害が発生したマルチルートＩＯデバイスに対する前記ハードウェアリセットの要求を受信し、前記管理サーバから当該マルチルートＩＯデバイスについてハードウェアリセットの抑止の指令を受け付けたときには、当該マルチルートＩＯデバイスのハードウェアリセットを抑止するステップと、
を含むことを特徴とする複合型計算機装置の管理方法。
【請求項９】
請求項８に記載の複合型計算機装置の管理方法において、
前記リソース管理部が、前記更新した障害処理ステータス情報と、に基づいて前記マルチルートＩＯマネージャにマルチルートＩＯデバイスのハードウェアリセットの抑止または解除の指令を通知するステップは、
前記管理サーバが、前記計算機のすべての障害処理ステータス情報についてハードウェアリセットが可能な場合に、前記マルチルートＩＯマネージャに対して当該マルチルートＩＯデバイスのハードウェアリセットの抑止を解除する指令を通知することを特徴とする複合型計算機装置の管理方法。
【請求項１０】
請求項８に記載の複合型計算機装置の管理方法において、
前記リソース管理部が、前記マルチルートＩＯデバイスの管理情報として、少なくとも、前記マルチルートＩＯデバイスを共有している計算機毎に該マルチルートＩＯデバイスに障害が発生したときの障害処理の内容を示す障害処理内容情報と、該マルチルートＩＯデバイスを共有している計算機毎に、当該マルチルートＩＯデバイスをハードウェアリセットすることが可能か否かを示す障害処理ステータス情報と、を含むＩＯデバイス管理情報を設定するステップは、
前記マルチルートＩＯデバイスを共有する前記計算機の障害処理ステータス毎に該マルチルートＩＯデバイスの障害処理の優先度情報を設定し、
前記リソース管理部が、前記更新した障害処理ステータス情報と、に基づいて前記マルチルートＩＯマネージャにマルチルートＩＯデバイスのハードウェアリセットの抑止または解除の指令を通知するステップは、
前記管理サーバが、前記マルチルートＩＯデバイスの障害発生時に、当該障害の発生したマルチルートＩＯデバイスが割り当てられた計算機について前記ＩＯデバイス管理情報を参照し、前記ＩＯデバイス管理情報で指定された障害処理の優先度が所定値以上の計算機のうち、すべての障害処理ステータス情報についてハードウェアリセットが可能な場合に、前記マルチルートＩＯマネージャ対して当該マルチルートＩＯデバイスのハードリセットの抑止を解除する指令を通知することを特徴とする複合型計算機装置の管理方法。
【請求項１１】
請求項８に記載の複合型計算機装置の管理方法において、
前記リソース管理部が、前記計算機に前記ＩＯデバイスの割当てを行うための情報をサーバプロファイル情報に格納するステップと、
前記リソース管理部が、前記サーバプロファイル情報に基づいて、前記計算機に前記ＩＯデバイスを割当てるステップと、をさらに含み、
前記サーバプロファイル情報は、
前記計算機に割当てるＩＯデバイス毎に該ＩＯデバイスの種類と、当該ＩＯデバイスに障害が発生したときの障害処理の内容と、当該ＩＯデバイスを割り当てた計算機で動作させるオペレーティングシステムの種類と、を含み、
前記リソース管理部が、前記サーバプロファイル情報に基づいて、前記計算機に前記ＩＯデバイスを割当てるステップは、
前記リソース管理部が、前記計算機に前記ＩＯデバイスを割当てる際に、前記計算機で動作させるオペレーティングシステムが前記サーバプロファイル情報に格納された前記障害処理の内容を実行可能であり、かつ前記計算機に搭載されたチップセットが前記サーバプロファイル情報に格納された前記障害処理の内容を実行可能であり、かつ前記計算機に搭載されたＢＩＯＳが前記サーバプロファイル情報に格納された前記障害処理の内容を実行可能である、かつ前記計算機に割り当てるＩＯデバイスが前記サーバプロファイル情報に格納された前記障害処理の内容を実行であるときに、前記計算機に前記ＩＯデバイスを割り当てることを特徴とする複合型計算機装置の管理方法。
【請求項１２】
請求項１１に記載の複合型計算機装置の管理方法において、
前記リソース管理部が、前記サーバプロファイル情報に基づいて、前記計算機に前記ＩＯデバイスを割当てるステップは、
前記ＩＯデバイスを割り当てる計算機のＰＣＩバス上のルートポート毎に、当該ルートポート以下のＰＣＩツリーに割当てたすべてのＩＯデバイスについて、前記サーバプロファイル情報の障害処理の内容が実行可能であるときに、前記計算機に前記ＩＯデバイスを割り当てることを特徴とする複合型計算機装置の管理方法。
【請求項１３】
請求項１２に記載の複合型計算機装置の管理方法において、
前記計算機は、前記マルチルートＩＯデバイスに障害が発生したときに、前記ＩＯデバイス管理情報で指定された障害処理内容情報がマルチルートＩＯデバイスのハードウェアリセットで、前記ＩＯデバイスハードリセット抑止部が当該マルチルートＩＯデバイスのハードウェアリセットを抑止している場合には、第１の所定時間が経過した後に当該マルチルートＩＯデバイスのハードリセットを再要求し、第２の所定時間が経過した後には障害処理を中断し、前記第２の所定時間が経過する以前に、当該マルチルートＩＯデバイスのハードウェアリセットの抑止が解除されたときには、当該マルチルートＩＯデバイスのハードウェアリセットを前記マルチルートＩＯマネージャに要求することを特徴とする複合型計算機装置の管理方法。
【請求項１４】
請求項１３に記載の複合型計算機装置の管理方法において、
前記リソース管理部が、前記計算機が実行するオペレーティングシステムと、前記計算機のＢＩＯＳと、前記計算機に割り当てるＩＯデバイスの障害処理のサポート条件と、前記サポート条件に対応して障害処理のレベルに応じた障害処理の内容を示す障害処理ポリシー情報を保持するステップをさらに含み、
前記リソース管理部が、前記計算機に前記ＩＯデバイスの割当てを行うための情報をサーバプロファイル情報に格納するステップは、
前記計算機に割り当てる前記ＩＯデバイスの種類の情報と、前記計算機で動作させるオペレーティングシステムの種類と、障害処理ポリシーのレベル情報を含み、
前記リソース管理部が、前記サーバプロファイル情報に基づいて、前記計算機に前記ＩＯデバイスを割当てるステップは、
前記管理サーバが前記サーバプロファイル情報に基づいて前記計算機に前記ＩＯデバイスを割当てる際に、前記サーバプロファイル情報の前記オペレーティングシステムの種類と、前記計算機に搭載されたＢＩＯＳと、前記計算機に割り当てるＩＯデバイスが、前記障害処理ポリシーのレベルが前記障害処理ポリシー情報の前記障害処理のレベルに一致する前記障害処理のサポート条件を満足する物理リソースを割り当てることを特徴とする複合型計算機装置の管理方法。
【請求項１５】
演算処理を行うプロセッサと、情報を記憶するメモリと、を備えて、一つの入出力デバイスと複数の物理計算機とを相互に接続する１以上のＰＣＩスイッチに接続された入出力マネージャを制御する管理サーバにおいて、
前記入出力デバイスは、前記２以上の物理計算機に対応付けられ、
前記管理サーバは、
２以上の物理計算機と前記入出力デバイスとの対応付けを管理するリソース管理部を有し、
前記リソース管理部は、
該入出力デバイスに障害が発生したときの障害処理の内容を対応付けられている前記物理計算機毎に示す障害処理内容情報と、該入出力デバイスを共有している物理計算機毎に、当該入出力デバイスをハードウェアリセットすることが可能か否かを示す障害処理ステータス情報と、を含む入出力デバイス管理情報と、
前記入出力マネージャから前記入出力デバイスの障害発生の通知を受信したときに、当該入出力デバイスに対応付けられる物理計算機から障害処理の進捗情報をそれぞれ取得して、前記障害処理ステータス情報を更新し、当該障害処理ステータス情報に基づいて前記入出力マネージャに前記入出力デバイスのハードウェアリセットの抑止または解除の指令を通知する障害処理調停部と、を有することを特徴とする管理サーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の計算機と複数のＩＯデバイスをＰＣＩ（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）識別子１１０１１、１１０１２、１１０１３、１１０１４とした例を示す。
【００８９】
図１２に示す構成の場合、図１０のサーバプロファイル１２７のＩＯデバイス番号が「１」のマルチルートＩＯデバイス１０２は「ＧｂＥ  ＮＩＣ」の外部装置の情報Ｋ９０５は「ＶＬＡＮ１」であるので、図１２のネットワークスイッチ１（１０７−１）のＶＬＡＮ１（１１０１１）に接続可能なマルチルートＩＯデバイス１（１０２−１）が選択され、ネットワークスイッチ２（１０７−２）に接続しているマルチルートＩＯデバイス３（１０２−３）は選択されない。
【００９０】
また、図１０のサーバプロファイル１２７のＩＯデバイス番号が「４」のマルチルートＩＯデバイス１０２は「ＦＣ−ＨＢＡ（１Ｇ）」であり、外部装置の情報Ｋ９０５はストレージ装置１であるので、図１２のストレージ装置１（１０８−１）に接続可能なマルチルートＩＯデバイス１（１０２−２）が選択され、ストレージ装置２（１０８−２）に接続しているマルチルートＩＯデバイス４（１０２−４）は選択されない。
【００９１】
次に、物理リソース割当て制御部１２４は、ステップＳ１００７の条件を満たすマルチルートＩＯデバイス１０２の中から、計算機１００のルートポート１１４毎にＩＯデバイスの障害処理方法Ｋ９０４が同一にできるか否かを判定する（ステップＳ１００８）。
【００９２】
図１３を用いて、ステップＳ１００８で行われるルートポート１１４毎にＩＯデバイスの障害処理方法を同一にするマルチルートＩＯデバイス１０２の選択方法の一例について説明する。
【００９３】
図１３は、前記図１に示した本発明の一実施の形態による複合型計算機装置のブロック図に対して、同一構成要素を区別するために、計算機１００を１００−１、１００−２、１００−３とし、マルチルートＩＯデバイス１０２を１０２−１、１０２−２、１０２−３、１０２−４とし、ルートポート１１４を１１４−１１、１１４−１２、１１４−２１、１１４−２２、１１４−３１、１１４−３２とし、マルチルートＩＯデバイス１０２−１、１０２−２、１０２−３、１０２−４のＰＣＩ  Ｆｕｎｃｔｉｏｎ１２０毎に、割当て計算機と、ＩＯデバイス障害処理方法１２０１１、１２０１２、１２０１３、１２０１４、１２０１５、１２０１６、１２０１７、１２０１８を加えたものである。
【００９４】
図１３に示す例では、計算機１（１００−１）には、ルートポート１１４−１１経由でＰＣＩ  Ｆｕｎｃｔｉｏｎ１２０−１、１２０−３、ルートポート１１４−１２経由でＰＣＩ  Ｆｕｎｃｔｉｏｎ１２０−５、１２０−７が割当てられている。この例の場合、ルートポート１１４毎にＩＯデバイスの障害処理方法を同一にすることは、ルートポート１１４−１１に関してはＰＣＩ  Ｆｕｎｃｔｉｏｎ１２０１−１とＰＣＩ  Ｆｕｎｃｔｉｏｎ  １２０−３のＩＯデバイスの障害処理方法を同一にすることであり、ここではＯＳリブート処理で同一である。
【００９５】
また、ルートポート１１４−１２に関してはＰＣＩ  Ｆｕｎｃｔｉｏｎ１２０−５とＰＣＩ  Ｆｕｎｃｔｉｏｎ１２０−７のＩＯデバイスの障害処理方法を同一にすることであり、ここではＩＯ閉塞処理で同一である。
【００９６】
一方、例えば、計算機１（１００−１）のＰＣＩ  Ｆｕｎｃｔｉｏｎ１２０−１とＰＣＩ  Ｆｕｎｃｔｉｏｎ１２０−５に関しては、ルートポート１１４がそれぞれ異るためＩＯデバイスの障害処理方法が、ＯＳリブート処理とＩＯ閉塞処理と異なっても良い。
【００９７】
次に、物理リソース割当て制御部１２４は、サーバプロファイル１２７の障害時ＩＯデバイス切り替えが、「あり」、すなわち、ＩＯデバイスの切り替えを行う指定がある場合は、複合型計算機のマルチルートＩＯデバイス１０２のうちユーザに使用されていないものから、切り替えが可能なものを選択できるか否かを判定する（ステップＳ１００９）。この判定では、上述のステップＳ１００６、Ｓ１００７、Ｓ１００８での判定と同様の判定処理を行う。すなわち、マルチルートＩＯデバイス１０２がＩＯデバイスの障害処理方法をサポートしているか否か、外部装置に接続可能か否か、ルートポート１１４毎に障害処理方法を同一にできるか否か、の判定が行われる。
【００９８】
これらの判定の後、物理リソース割当て制御部１２４は、計算機１００に割当てるマルチルートＩＯデバイス１０２を選択し、マルチルートＩＯマネージャ１０４に計算機１００とマルチルートＩＯデバイス１０２の割当てを通知して、ＰＣＩ  Ｅｘｐｒｅｓｓスイッチ１０１の設定を実行させて（ステップＳ１０１２）、計算機１００の構成が完了する（ステップＳ１０１３）。
【００９９】
一方、ステップＳ１００３、Ｓ１００４、Ｓ１００６、Ｓ１００７、Ｓ１００８、Ｓ１００９の判定処理を満たさなかった場合は、リソース管理ソフトウェア１３２は、計算機１００の管理者の管理端末１０６にサーバプロファイル１２７で要求した仕様の計算機を構成できないことを通知し、サーバプロファイル１２７の再設定をするか否かを判定する（ステップＳ１０１０）。計算機１００の管理者が管理端末１０６からサーバプロファイル１２７の再設定を行うことを通知した場合は、ステップＳ１００２に戻りサーバプロファイル１２７の再設定を行う。一方、計算機の管理者が操作する管理端末１０６からサーバプロファイル１２７の再設定を行わない通知を受けた場合は、計算機１００の構成を中止する（ステップＳ１０１１）。
【０１００】
以上の処理によって、管理サーバ１０５の物理リソース割当制御部１２４は、管理端末１０６から受け付けたサーバプロファイル１２７にしたがって、計算機１００にマルチルートＩＯデバイス１０２と外部装置を割り当てることができる。
【０１０１】
なお、上記ステップＳ１００８の処理においては、チップセット１１３が提供するＰＣＩバス上のルートポート１１４毎に、各ルートポート１１４以下のＰＣＩツリーに割当てたすべてのＩＯデバイス（マルチルートＩＯデバイス１０２）について、サーバプロファイル１２７で指定された障害処理方法Ｋ９０３が実行可能であるときに、物理リソースを割り当てるようにしても良い。
【０１０２】
次に、ＩＯデバイスの障害発生時に障害処理として他のＩＯデバイスに切り替える場合の複合型計算機の制御方法について、図１５、図１６を用いて説明する。
【０１０３】
図１５は、本発明の第１の実施形態による複合型計算機の計算機のＩＯデバイスの障害発生時のＩＯデバイス切り替え方法の一例を示したフローチャートである。図１６は、本発明の第１の実施形態による複合型計算機のＩＯデバイスの障害発生時のＩＯデバイス切り替え対象となるＩＯデバイスを選択するグラフィカルインターフェースの一例を示した説明図である。
【０１０４】
マルチルートＩＯデバイス１０２の障害時に行われるＩＯデバイス切り替え処理は、障害が発生したマルチルートＩＯデバイス１０２の代わりに複合型計算機内の使用されていない他のマルチルートＩＯデバイス１０２を計算機１００に割当てて障害を回復する障害処理方法である。
【０１０５】
図１５に示すように、ＩＯデバイスの切り替え処理は、図９のステップＳ８０６のＩＯデバイスの切り替え実行により開始される（ステップＳ１４０１）。リソース管理ソフトウェア１３２のＩＯデバイス切り替え制御部１２６は、図１４に示すＩＯデバイス管理情報１２８を基に、計算機１００の管理者が操作する管理端末１０６に対して切り替え可能なマルチルートＩＯデバイス１０２の候補を通知する（ステップＳ１４０２）。
【０１０６】
次に、ＩＯデバイス切り替え制御部１２６は、計算機１００の管理者が操作する管理端末１０６から切り替えるマルチルートＩＯデバイス１０２の指定があるか否かを判定し（ステップＳ１４０３）、指定がない場合、あるいは、ＩＯデバイスの切り替えの中止が指定された場合は、ＩＯデバイスの切り替えを中止する（ステップＳ１４０４）。
【０１０７】
一方、切り替えるマルチルートＩＯデバイスが選択された場合は、ＩＯデバイス切り替え制御部１２６は、マルチルートＩＯマネージャ１０４に対して、計算機１００から障害が発生したマルチルートＩＯデバイス１０２について計算機１００の割当てを解除し、切り替え対象のマルチルートＩＯデバイス１０２を当該計算機１００に割当てる設定を行う（ステップＳ１４０５）。この設定は、管理サーバ１０５がＩＯデバイス管理情報１２８の割り当て計算機Ｋ２０３を更新することで行われる。
【０１０８】
次に、ＩＯデバイス切り替え制御部１２６は、当該計算機１００の電源制御抑止を解除して、計算機１００の管理者が管理端末１０６から管理サーバ１０５を介して装置制御計算機１０３０から電源を投入（または再起動）することができるように設定して（ステップＳ１４０６）、ＩＯデバイスの切り替えが完了する（ステップＳ１４０７）。
【０１０９】
次に、図１６を用いて、図１５のステップＳ１４０２で行われる計算機１００の管理者が操作する管理端末１０６に出力する切り替えＩＯデバイスの指定を行うためのグラフィカルインターフェースの一例を説明する。管理端末１０６に表示されるグラフィカルインターフェース１５０１は、リソース管理ソフトウェア１３２の管理画面１５０２を備え、ＩＯデバイス切り替えのグラフィカルインターフェースとして、障害が発生したマルチルートＩＯデバイス１０２の情報１５０３と、切り替えの候補となるマルチルートＩＯデバイス１０２の一覧１５０４と、ＩＯデバイスの切り替えの中止を指定する設定部１５０５と、を備える。
【０１１０】
障害が発生したマルチルートＩＯデバイス１０２の情報１５０３として、マルチルートＩＯデバイス１０２の識別子１５０７と、マルチルートＩＯデバイス１０２の種類１５０８と、マルチルートＩＯデバイス１０２が接続されたマルチルートＰＣＩ  Ｅｘｐｒｅｓｓスイッチ１０１の識別子１５０９およびポート番号１５１０と、マルチルートＩＯデバイス１０２のＰＣＩ  Ｆｕｎｃｔｉｏｎ１２０の識別子１５１１と、帯域モニタ部１１６が取得したマルチルートＩＯデバイス１０２の当該計算機１００が使用する帯域情報１５１２と、当該マルチルートＩＯデバイス１０２に接続される外部装置の情報１５１３を備える。また、切り替えの候補となるマルチルートＩＯデバイス１０２の一覧１５０４は、候補となるマルチルートＩＯデバイス１０２のＰＣＩ  Ｆｕｎｃｔｉｏｎ毎１５０６１、１５０６２、１５０６３の情報を表示する。
【０１１１】
図１６の例では、ＰＣＩ  Ｆｕｎｃｔｉｏｎが１５０６１、１５０６２、１５０６３の３つの候補について示している。切り替えの候補となるマルチルートＩＯデバイス１０２の情報としては、マルチルートＩＯデバイス１０２の識別子１５１４、マルチルートＩＯデバイス１０２が接続されたマルチルートＰＣＩ  Ｅｘｐｒｅｓｓスイッチ１０１の識別子１５１５およびポート番号１５１６、マルチルートＩＯデバイス１０２のＰＣＩ  Ｆｕｎｃｔｉｏｎの識別子１５１７、帯域モニタ部１１６が取得し障害処理調停部１２５が計算で求めたマルチルートＩＯデバイス１０２の空き帯域情報１５１８を持ち、計算機１００の管理者が操作する管理端末１０６でマルチルートＩＯデバイス１０２の機能（Ｆｕｎｃｔｉｏｎ）１５０６１〜１５０６３を選択させるための設定部１５１９を備える。
【０１１２】
以上のように本発明の第１の実施形態によれば、管理者は管理端末１０６からマルチルートＩＯデバイスに障害が発生したときの障害処理内容を含む計算機１００（計算機１〜３）の仕様を管理サーバ１０５のサーバプロファイル１２７を定義しておく。そして、障害処理の内容には、マルチルートＩＯデバイス１０２毎に障害時の処理として、停止、リブート、閉塞、リトライ、および、ＩＯの切り替えを含む。
【０１１３】
上記サーバプロファイル１２７に基づいて、管理サーバ１０５のリソース管理ソフトウェア１３２の物理リソース割り当て制御部１２４は、各計算機１００（計算機１〜３）に複合型計算機のリソースの割り当てを行う。
【０１１４】
リソース管理ソフトウェア１３２は、リソースの割り当てを行う際には、サーバプロファイル１２７で指定された障害処理Ｋ９０３が可能なように計算機１００の構成をチェックする。
【０１１５】
すなわち、リソース管理ソフトウェア１３２は、ＯＳ１１１と、ＢＩＯＳ１１２がサーバプロファイル１２７で指定された障害処理をサポートし、計算機１００のルートポート１１４以下のマルチルートＩＯデバイス１０２がすべて同じ障害処理に設定可能であり、さらに障害発生時にマルチルートＩＯデバイス１０２の切り替えを行う場合には、引継ぎが可能なマルチルートＩＯデバイスの候補を有する計算機１００とマルチルートＩＯデバイス１０２及び外部装置の組み合わせから計算機１００にリソースの割り当てを実施する。
【０１１６】
ＰＣＩ  Ｅｘｐｒｅｓｓスイッチ１０１はスイッチ管理計算機１０４０のマルチルートＩＯマネージャ１０４によって監視され、マルチルートＩＯマネージャ１０４はマルチルートＩＯデバイス１０２に障害が発生すると、管理サーバ１０５のリソース管理ソフトウェア１３２に障害の発生を通知する。
【０１１７】
リソース管理ソフトウェア１３２はマルチルートＩＯデバイス１０２の障害発生の通知を受信すると、障害処理調停部１２５で、マルチルートＩＯデバイス１０２を共有している計算機１００の各障害処理方法から、閉塞、リトライの処理が完了するまで、マルチルートＩＯデバイス１０２のハードウェアリセットを抑止し、および、障害処理の内容がリブートの場合はリブートを抑止する。また、リトライが成功した場合は、ハードウェアリセットは行なわず、計算機１００の業務を継続させて複合型計算機の可用性を確保する。
【０１１８】
リソース管理ソフトウェア１３２のＩＯデバイス切り替え制御部１２６は、障害処理でマルチルートＩＯデバイス１０２の切り替え処理対象のＩＯデバイスについて、引継ぎ可能なマルチルートＩＯデバイス１０２の候補と、各候補の空き帯域（空きスループット）を管理端末１０６に提示し、引継ぎ先のマルチルートＩＯデバイス１０２を選択させ、リソース管理ソフトウェア１３２は管理端末１０６から受け付けた引き継ぎ先のマルチルートＩＯデバイス１０２をスイッチ管理計算機１０４０のマルチルートＩＯマネージャ１０４に通知して、計算機１００に選択されたマルチルートＩＯデバイス１０２を割り当てる。
【０１１９】
以上のような構成によって、管理サーバ１０５のリソース管理ソフトウェア１３２は、複数の計算機１００と複数のマルチルートＩＯデバイス１０２を備える複合型計算機で、マルチルートＩＯデバイス１０２の障害処理を行うことが可能なＯＳ１１１とＢＩＯＳ１１２及びチップセット１１３のルートポート１１４の設定を選択して、計算機１００を構成する。これにより、マルチルートＩＯデバイス１０２に障害が発生した場合でも、管理サーバ１０５の障害処理調停部１２５が、計算機１００の構成に応じて実行可能な障害処理を実施することが可能となり、複数の計算機１００で共有するマルチルートＩＯデバイス１０２の障害処理を円滑に行うことが可能となる。
【０１２０】
そして、マルチルートＩＯデバイス１０２を共有している複数の計算機１００は、計算機１００毎に障害発生時の障害回復処理（リトライ、ＩＯ閉塞、ＯＳリブート、ＯＳ停止）が異なる場合であっても、障害処理調停部１２５が計算機１００間で障害回復処理が競合するのを回避して、障害回復処理を円滑に実現することができる。例えば、図１に示した計算機１の障害回復処理がリトライで、計算機２の障害回復処理がＯＳリブートの場合には、管理サーバ１０５がマルチルートＩＯマネージャ１０４のＩＯデバイスハードリセット抑止部１２３に計算機２のＯＳリブートを禁止するよう指示し、マルチルートＩＯマネージャ１０４が計算機２のＢＭＣ１３３に再起動を禁止することができるので、計算機１のマルチルートＩＯデバイス１０２に対するリトライ中にマルチルートＩＯデバイス１０２がハードリセットされるのを抑制できる。
【０１２１】
また、計算機１００がマルチルートＩＯデバイス１０２の障害発生時に他のマルチルートＩＯデバイス１０２に切り替える場合には、管理サーバ１０５がサーバプロファイル１２７とＩＯデバイス管理情報１２８及びＰＣＩ  Ｅｘｐｒｅｓｓスイッチ１０１の帯域モニタ部１１６が取得した帯域情報に基づいて、引継ぎ可能なマルチルートＩＯデバイス１０２を提示することができ、ＩＯデバイスの切り替えを確実に行うことが可能となる。
【０１２２】
＜第２実施形態＞
次に本発明の第２の実施の形態による複合型計算機の構成について説明する。第２の実施形態における複合型計算機は、図１に示す本発明の第１の実施形態の複合型計算機と、図３に示すＩＯデバイス管理情報１２８と図９に示す複合型計算機のＩＯデバイス障害発生時の管理ソフトウェアによる障害処理方法が異なる以外は同じである。従って、以下では第１の実施形態と異なる分部についてだけ説明し、同じ部分については説明を省略する。
【０１２３】
図１７は第２の実施の形態による複合型計算機の管理サーバ１０５が保持するＩＯデバイス管理情報１２８の一例を示した説明図である。
【０１２４】
図１７に示すように、ＩＯデバイス管理情報１２８は表形式ＦＴ１６で表すと、図３に示した第１の実施形態のＩＯデバイス管理情報１２８にマルチルートＩＯデバイスの障害処理の優先度を示す情報Ｋ１６０１を追加したものである。
【０１２５】
障害処理の優先度情報Ｋ１６０１は、複数の計算機１００でマルチルートＩＯデバイス１０２を共有している場合に、優先度Ｋ１６０１が高い方の計算機１００の障害処理が優先的に実行されることを示す。本実施形態では、障害処理の優先度情報Ｋ１６０１の数値が大きい方が、より優先度が高いものとする。
【０１２６】
次に、第２の実施形態でのマルチルートＩＯデバイス１０２に障害が発生したときのリソース管理ソフトウェア１３２による制御方法について図１８を用いて説明する。
【０１２７】
図１８は、本発明の第２の実施形態による複合型計算機のＩＯデバイス障害発生時の管理ソフトウェアによる障害処理方法の一例を示したフローチャートである。
【０１２８】
図１８に示すように、図３に示した第１の実施形態の障害処理方法の、マルチルートＩＯデバイス１０２を割当てたすべての計算機１００のＩＯデバイスの障害処理でハードリセットが可能か否かを判定するステップＳ８０７と、ステップＳ８０７の判定でハードリセットが可能な状態の場合は、ＩＯデバイスハードリセット抑止部１２３に対して当該マルチルートＩＯデバイス１０２のハードリセット抑止を解除するステップＳ８０８とを、図１８のステップＳ１７０１、Ｓ１７０２に置き換えたもので、その他のステップは前記第１実施形態と同様である。
【０１２９】
すなわち、第２の実施形態では、障害処理調停部１２５は、ＩＯデバイス管理情報１２８の障害処理ステータスＫ２０７のステータス情報と、障害処理の優先度情報Ｋ１６０１とから、マルチルートＩＯデバイス１０２を割当てたすべての計算機１００のうち、優先度が所定値Ｎ以上の障害処理でＩＯデバイスのハードリセットが可能か否かを判定する（ステップＳ１７０１）。
【０１３０】
当該マルチルートＩＯデバイス１０２でハードリセットが可能な場合は、ＩＯデバイスハードリセット抑止部１２３に対して、優先度Ｎ以上に該当する計算機１００からのマルチルートＩＯデバイス１０２のハードリセット抑止を解除する（ステップＳ１７０２）。なお、ステップＳ１７０１、Ｓ１７０２の処理は、優先度Ｎが０、１、…、Ｎ（Ｎは、Ｎ＞０の整数）のすべての条件について判定される。第２の実施形態により、マルチルートＩＯデバイス１０２を複数の計算機１００で共有した場合に、優先度が高い計算機のＩＯデバイスの障害処理を優先的に実行することが可能になる。
【０１３１】
＜第３実施形態＞
次に本発明の第３の実施の形態による複合型計算機の構成について説明する。第３の実施形態における複合型計算機は、図１に示した本発明の第１の実施形態の複合型計算機と、マルチルートＩＯマネージャ１０４のＩＯデバイスハードリセット制御の部分が異なる以外は同じである。従って、以下では第１の実施形態と異なる分部についてだけ説明し、同じ部分については説明を省略する。
【０１３２】
図１９は第３の実施の形態による複合型計算機のＩＯデバイスのハードリセット制御の方法の一例を示したフローチャートである。第３の実施形態では、前記第１実施形態に示した図５、図６、図８に示すマルチルートＩＯマネージャ１０４のＩＯデバイスハードリセット制御（図５のステップＳ４０７）の制御部分が、図１９に示す制御で置き換わる。
【０１３３】
すなわち、図１９に示すように、ＢＭＣ１３３または計算機１００からマルチルートＩＯデバイス１０２のハードリセット要求を受けたマルチルートＩＯマネージャ１０４は、マルチルートＩＯデバイス１０２のハードリセット制御を開始する（ステップＳ１８０１）。
【０１３４】
次に、マルチルートＩＯマネージャ１０４は、ハードリセットを要求した計算機１００について、マルチルートＩＯデバイス１０２のハードリセット抑止が解除されているか否かを判定し（ステップＳ１８０２）、ハードリセット抑止が解除されてハードリセット可能な場合は、マルチルートＩＯデバイス１０２のハードリセットの制御を実行し（ステップＳ１８０３）、マルチルートＩＯデバイス１０２のハードリセットの完了によりハードリセットの制御を完了する（ステップＳ１８０４）。
【０１３５】
一方、ステップＳ１８０２の判定で、ハードリセットが抑止されてハードリセットができない場合は、所定の時間Ｔ１だけ待ち（ステップＳ１８０５）、さらにステップＳ１８０１のＩＯデバイスのハードリセット制御を開始した時刻から所定の時間Ｔ２が経過したか否かを判定し（ステップＳ１８０６）、時間Ｔ２が経過していない場合は、ステップ１８０２に戻りマルチルートＩＯデバイス１０２のハードリセット可能か再度判定する。
【０１３６】
一方、所定の時間Ｔ２が経過した場合は、当該計算機１００のＩＯデバイスの障害処理を中止する（Ｓ１８０７）。なお、所定の時間Ｔ１、時間Ｔ２は、複合型計算機装置の製造時の初期値として設定されているか、あるいは、計算機の管理者が操作する管理端末１０６により設定される等、予め設定された時間である。
【０１３７】
第３の実施形態により、例えば、障害処理の進捗が速い計算機１００のマルチルートＩＯデバイス１０２のハードリセットを、障害処理の進捗が遅い計算機１００に合わせて、遅らせることが可能になる。
【０１３８】
＜第４実施形態＞
次に本発明の第４の実施の形態による複合型計算機の構成について説明する。第４の実施形態における複合型計算機は、第３の実施形態と同様に、図１に示した本発明の第１の実施形態の複合型計算機と、マルチルートＩＯマネージャ１０４のＩＯデバイスハードリセット制御の部分が異なる以外は同じである。従って、以下では第１の実施形態と異なる分部についてだけ説明し、同じ部分については説明を省略する。
【０１３９】
図２０は第４の実施の形態による複合型計算機のＩＯデバイスのハードリセット制御の方法の一例を示したフローチャートである。第４の実施形態では、図５、図６、図８に示すマルチルートＩＯマネージャ１０４のＩＯデバイスハードリセット制御（図５のステップＳ４０７）の制御部分が、図２０に示す制御で置き換わる。
【０１４０】
すなわち、図２０に示すように、ＢＭＣ１３３等からマルチルートＩＯデバイス１０２のハードリセット要求を受けたマルチルートＩＯマネージャ１０４は、マルチルートＩＯデバイス１０２のハードリセット制御を開始する（ステップＳ１９０１）。
【０１４１】
次に、マルチルートＩＯマネージャ１０４は、ハードリセットを要求した計算機１００について、マルチルートＩＯデバイス１０２のハードリセット抑止が解除されているか否かを判定し（ステップＳ１９０２）、ハードリセット抑止が解除されハードリセット可能な場合は、マルチルートＩＯデバイス１０２のハードリセットの制御を実行し（ステップＳ１９０３）、マルチルートＩＯデバイス１０２のハードリセットの完了によりハードリセットの制御を完了する（ステップＳ１９０４）。
【０１４２】
一方、ステップＳ１９０２の判定で、ハードリセット抑止されハードリセットができない場合は、ＩＯでデバイスのハードリセットの代わりに、マルチルートＩＯデバイス１０２を共有している他の計算機に影響を与えないマルチルートＩＯデバイス１０２のリセットを実行する（ステップＳ１９０５）。
【０１４３】
このような、マルチルートＩＯデバイス１０２を共有している他の計算機に影響を与えないＩマルチルートＩＯデバイス１０２のリセットとしては、例えば、ＰＣＩのＦｕｎｃｔｉｏｎレベルリセットがある。すなわち、マルチルートＩＯデバイス１０２のＦｕｎｃｔｉｏｎ１２０毎にリセットをかけることで、当該マルチルートＩＯデバイス１０２を共有する他の計算機１００に障害回復処理の影響を与えるのを防ぐことができる。
【０１４４】
第４の実施形態により、他の計算機１００よりもマルチルートＩＯデバイス１０２の障害処理の優先度Ｋ１６０１が低い計算機１００のＩＯデバイスの障害処理を中止することなく実行することが可能になる。
【０１４５】
＜第５実施形態＞
次に本発明の第５の実施の形態による複合型計算機の構成について説明する。第５の実施形態における複合型計算機は、図１に示した本発明の第１の実施形態の複合型計算機と、図１に示すリソース管理ソフトウェア１３２の構成、図１０に示す計算機のプロファイル情報と、図１１に示した複合型計算機の計算機の構成方法、が異なる以外は同じである。従って、以下では第１の実施形態と異なる分部についてだけ説明し、同じ部分については説明を省略する。
【０１４６】
図２１は第５の実施の形態による複合型計算機の管理サーバ１０５の構成図で、図２２は第５の実施の形態による複合型計算機のＩＯデバイスの障害処理ポリシー情報の一例を示した説明図である。図２３は第５の実施の形態による複合型計算機のサーバプロファイルの一例を示した説明図である。図２４は第５の実施の形態による複合型計算機の計算機の構成方法の一例を示したフローチャートである。
【０１４７】
図２１に示すように、第５の実施形態では、図１に示した第１の実施形態のリソース管理ソフトウェア１３２に、ＩＯデバイスの障害処理ポリシー情報２００１が追加される。図２２に示すように、このＩＯデバイスの障害処理ポリシー情報２００１は、表形式ＦＴ２１で表すと、ＯＳ１１１、ＢＩＯＳ１１２、マルチルートＩＯデバイス１０２の障害処理方法のサポート条件Ｋ２１０１、Ｋ２１０２、Ｋ２１０３がそれぞれ設定され、各サポート条件Ｋ２１０１、Ｋ２１０２、Ｋ２１０３に対するポリシーレベル毎に選択される障害処理方法Ｋ２１０４、Ｋ２１０５の列から成る。
【０１４８】
例えば、障害処理方法のサポート条件として、ＯＳ１１１は、ＩＯリトライ処理サポートで、かつＩＯ閉塞処理サポート（Ｋ２１０１）、ＢＩＯＳ１１２はＩＯリトライ処理サポートで、かつＩＯ閉塞処理サポート（Ｋ２１０２）、マルチルートＩＯデバイス１０２はＩＯリトライ処理サポートで、かつＩＯ閉塞処理サポート（Ｋ２１０３）の場合は、ポリシーレベルが「低」の場合はＯＳリブート処理（Ｋ２１０４）が選択される。
【０１４９】
第１の実施形態ではマルチルートＩＯデバイス１０２に障害が発生したときのＩＯデバイスの障害処理方法を計算機の管理者が操作する管理端末１０６でマルチルートＩＯデバイス１０２毎に指定させたが、本第５の実施形態では、計算機の管理者にはポリシーレベルのみを管理端末１０６で指定させ、個々のＩＯデバイスの障害処理方法はリソース管理ソフトウェア１３２がポリシーレベルとＩＯデバイスの障害処理ポリシー情報２００１を用いることで自動的に決定する。従って、図２３に示すように、第５の実施形態のサーバプロファイル１２７は、図１０に示した第１の実施形態のサーバプロファイル１２７からマルチルートＩＯデバイス１０２のＩＯデバイスの障害処理方法Ｋ９０３の列を除き、ＩＯデバイスの障害処理のポリシーレベル２２０１を追加した情報となる。
【０１５０】
次に、第５の実施形態における、計算機１００のユーザである管理者が操作する管理端末１０６から、新たにサーバを構築するために計算機を構成する場合の複合型計算機の制御方法について説明する。
【０１５１】
図２４に示すように、計算機の管理者が操作する管理端末１０６からの要求により計算機の構成処理が開始する（ステップＳ２３０１）。計算機１００の管理者は管理端末１０６から、リソース管理ソフトウェア１３２に対して、必要な計算機１００の仕様を計算機のサーバプロファイル１２７により要求する（ステップＳ２３０２）。上述の通り、サーバプロファイル１２７は、計算機１００の仕様情報であり、ＣＰＵ１３４と、メモリ１３５と、マルチルートＩＯデバイス１０２と、ＯＳ１１１等の仕様情報を含む。
【０１５２】
第５の実施形態では、サーバプロファイル１２７の内、特に本実施形態に関連するマルチルートＩＯデバイス１０２に関する情報は、表形式で表すと図２３のＦＴ２２に示す情報と、ＩＯデバイス障害時の障害処理方法のポリシーレベル２２０１と、を備える。なお、ポリシーレベル２２０１は管理端末１０６等から受け付けた値であり、例えば。「高」あるいは「低」である。
【０１５３】
次に、物理リソース割当て制御部１２４は、複合型計算機の計算機１００でユーザに使用されていないものから、サーバプロファイル１２７に合った計算機１００を選択する（ステップＳ２３０３）。
【０１５４】
次に、物理リソース割当て制御部１２４は、複合型計算機のマルチルートＩＯデバイス１０２のユーザに使用されていないものから、サーバプロファイル１２７に指定された特定の外部装置Ｋ９０５、例えば、ネットワークスイッチ、ストレージ装置、に接続できるか否かを判定する（ステップＳ２３０４）。
【０１５５】
次に、物理リソース割当て制御部１２４は、ステップＳ２３０４の条件を満たすマルチルートＩＯデバイス１０２の中から、計算機１００のルートポート１１４毎にマルチルートＩＯデバイス１０２の障害処理方法Ｋ９０４が同一にできるか否かを判定する（ステップＳ２３０５）。
【０１５６】
次に、物理リソース割当て制御部１２４は、図２３のポリシーレベル２２０１と、図２１に示すＩＯデバイスの障害処理ポリシー情報２００１と、ステップＳ２３０３で選択した計算機１００のＯＳ１１１の種類およびＢＩＯＳ１１２の種類の情報と、ステップＳ２３０５で選択したマルチルートＩＯデバイス１０２の情報、から、マルチルートＩＯデバイス１０２に障害が発生した場合の障害処理方法を決定する（ステップＳ２３０６）。
【０１５７】
次に、物理リソース割当て制御部１２４は、サーバプロファイル１２７の障害発生時にマルチルートＩＯデバイス１０２の切り替えが、あり、すなわち、ＩＯデバイスの切り替えを行う指定がある場合は、複合型計算機のマルチルートＩＯデバイス１０２のユーザに使用されていないものから、切り替えが可能なものを選択できるか判定する（ステップＳ２３０７）。この判定では、図１１で述べた第１実施形態のステップＳ１００９と同じ判定処理、すなわち、マルチルートＩＯデバイス１０２がＩＯデバイスの障害処理方法をサポートしているか、外部装置に接続可能か否か、ルートポート１１４毎に障害処理方法を同一にできるか否か、の判定が行われる。これらの判定後、物理リソース割当て制御部１２４は、計算機１００に割当てるマルチルートＩＯデバイス１０２を選択し、マルチルートＩＯマネージャ１０４に計算機１００とマルチルートＩＯデバイス１０２の割当て設定を行い（ステップＳ２３１０）、計算機１００の構成が完了する（ステップＳ２３１１）。
【０１５８】
一方、ステップＳ２３０４、Ｓ２３０５、Ｓ２３０７の判定処理を満たさなかった場合は、リソース管理ソフトウェア１３２は、計算機１００の管理者が操作する管理端末１０６にサーバプロファイル１２７で要求した仕様の計算機を構成できないと通知し、サーバプロファイル１２７の再設定をするか否かを判定する（ステップＳ２３０８）。計算機の管理者が操作する管理端末１０６でサーバプロファイル１２７の再設定を行う場合は、ステップＳ２３０２に戻りサーバプロファイル１２７の再設定を行う。一方、計算機の管理者が操作する管理端末１０６でサーバプロファイル１２７の再設定を行わない場合は、計算機の構成を中止する（ステップＳ２３０９）。
【０１５９】
以上により、第５の実施形態では、管理者は管理端末１０６等からポリシーレベル２２０１を設定することで、マルチルートＩＯデバイス１０２に障害が発生した時の障害処理方法を自動的に選択することが可能となり、複合型計算機の管理に要する労力を低減することが可能となる。
【０１６０】
なお、前記第１〜第５の実施形態においては、計算機１００で一つのＯＳ１１１を動作させる場合を示したが、計算機１００で仮想マシンマネージャを実行し、この仮想マシンマネージャ上で複数のＯＳ１１１を稼動させる仮想計算機に適用しても良い。仮想計算機に適用する場合では、前記第１〜第５の実施形態におけるＢＭＣ１３３からＯＳ１１１に対する通知を、ＢＭＣ１３３から仮想マシンマネージャに対する通知とすればよい。
【０１６１】
なお、前記第１〜第５の実施形態においては、装置制御部１０３と、マルチルートＩＯマネージャ１０４と、リソース管理ソフトウェア１３２が異なる計算機で実行される例を示したが、装置制御部１０３と、マルチルートＩＯマネージャ１０４及びリソース管理ソフトウェア１３２が同一の計算機で実行されてもよい。
【０１６２】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【産業上の利用可能性】
【０１６３】
本発明の複合型計算機装置における制御方法は、ビジネス業務を止めることができない企業のデータセンタ等のＩＴシステム向けの計算機、例えば、ブレードサーバ装置やラックマウント型サーバ装置への適用が可能である。また、ブレードサーバ装置やラックマウント型サーバ装置を管理するソフトウェアに適用することができる。
【図面の簡単な説明】
【０１６４】
【図１】本発明の第１の実施の形態による複合型計算機装置のブロック図。
【図２】本発明の第１の実施の形態による管理サーバのブロック図。
【図３】本発明の第１の実施の形態による複合型計算機のＩＯデバイス管理情報の一例を示した説明図。
【図４】本発明の第１の実施形態による複合型計算機のＩＯデバイス障害発生時の障害処理方法（ＯＳ停止処理）の一例を示したフローチャート。
【図５】本発明の第１の実施形態による複合型計算機のＩＯデバイス障害発生時の障害処理方法（ＯＳリブート処理）の一例を示したフローチャート。
【図６】本発明の第１の実施形態による複合型計算機のＩＯデバイス障害発生時の障害処理方法（ＩＯ閉塞処理）の一例を示したフローチャート。
【図７】本発明の第１の実施形態による複合型計算機のＩＯデバイス障害発生時の障害処理方法（ＩＯリトライ処理（１））の一例を示したフローチャート。
【図８】本発明の第１の実施形態による複合型計算機のＩＯデバイス障害発生時の障害処理方法（ＩＯリトライ処理（２））の一例を示したフローチャート。
【図９】本発明の第１の実施形態による複合型計算機のＩＯデバイス障害発生時の管理ソフトウェアによる障害処理方法の一例を示したフローチャート。
【図１０】第１の実施の形態による複合型計算機のサーバプロファイルの一例を示した説明図。
【図１１】本発明の第１の実施形態による複合型計算機の計算機の構成方法の一例を示したフローチャート。
【図１２】本発明の第１の実施形態による複合型計算機の外部装置との接続関係の一例を示した説明図。
【図１３】本発明の第１の実施形態による複合型計算機のルートポート毎の障害処理方法の指定の一例を示した説明図。
【図１４】第１の実施の形態による複合型計算機のＩＯデバイス切り替え候補の情報の一例を示した説明図。
【図１５】本発明の第１の実施形態による複合型計算機の計算機のＩＯデバイスの障害発生時のＩＯデバイス切り替え方法の一例を示したフローチャート。
【図１６】本発明の第１の実施形態による複合型計算機のＩＯデバイスの障害発生時のＩＯデバイス切り替え対象となるＩＯデバイスを選択するグラフィカルインターフェースの一例を示した説明図。
【図１７】第２の実施の形態による複合型計算機のＩＯデバイス管理情報の一例を示した説明図。
【図１８】本発明の第２の実施形態による複合型計算機のＩＯデバイス障害発生時の管理ソフトウェアによる障害処理方法の一例を示したフローチャート。
【図１９】第３の実施の形態による複合型計算機のＩＯデバイスのハードリセット制御の方法の一例を示したフローチャート。
【図２０】第４の実施の形態による複合型計算機のＩＯデバイスのハードリセット制御の方法の一例を示したフローチャート。
【図２１】第５の実施の形態による複合型計算機の管理サーバの構成図。
【図２２】第５の実施の形態による複合型計算機のＩＯデバイスの障害処理ポリシー情報の一例を示した説明図。
【図２３】第５の実施の形態による複合型計算機のサーバプロファイルの一例を示した説明図。
【図２４】第５の実施の形態による複合型計算機の計算機の構成方法の一例を示したフローチャート。
【符号の説明】
【０１６５】
１００、１００−１、１００−２、１００−３  計算機
１０１  マルチルートＰＣＩ  Ｅｘｐｒｅｓｓスイッチ
１０２、１０２−１、１０２−２、１０２−３、１０２−４  マルチルートＩＯデバイス
１０３  装置制御部
１０４  マルチルートＩＯマネージャ
１０５  管理サーバ
１０６  管理端末
１０７、１０７−１、１０７−２  ネットワークスイッチ
１０８、１０８−１、１０８−２  ストレージ装置
１０９  管理エージェントソフトウェア
１１０  デバイスドライバ
１１１  オペレーティングシステム
１１２  ＢＩＯＳ
１１３  チップセット
１１４、１１４−１１、１１４−１２、１１４−２１、１１４−２２、１１４−３１、１１４−３２  ルートポート
１１５  物理ポート
１１６  帯域モニタ部
１１７、１１８  制御Ｉ／Ｆ
１１９  管理ネットワーク
１２０  ＰＣＩ  Ｆｕｎｃｔｉｏｎ
１２１  物理ポート
１２２  計算機の電源制御抑止部
１２３  ＩＯデバイスハードリセット抑止部
１２４  物理リソース割当て制御部
１２５  障害処理調停部
１２６  ＩＯデバイス切り替え制御部
１２７  サーバプロファイル
１２８  ＩＯデバイス管理情報
１３０  ネットワークインターフェース
１３１  ストレージネットワークインターフェース
１３２  リソース管理ソフトウェア
１３３  ＢＭＣ
１３４  ＣＰＵ
１３５  メモリ
１１０１１、１１０１２、１１０１３、１１０１４  ＶＬＡＮ
１２０  ＰＣＩ  Ｆｕｎｃｔｉｏ
１５０１  グラフィカルインターフェース
１５０２  リソース管理ソフトウェアの管理画面
１５０３  障害が発生したマルチルートＩＯデバイスの情報
１５０４  切り替えの候補となるマルチルートＩＯデバイスの一覧
１５０５  ＩＯデバイスの切り替えの中止を指定する設定部
１５０６１、１５０６２、１５０６３  切り替えの候補となるマルチルートＩＯデバイス
１５０７  マルチルートＩＯデバイスの識別子
１５０８  マルチルートＩＯデバイスの種類
１５０９  マルチルートＰＣＩ  Ｅｘｐｒｅｓｓスイッチの識別子
１５１０  マルチルートＰＣＩ  Ｅｘｐｒｅｓｓスイッチのポート番号
１５１１  マルチルートＩＯデバイスのＰＣＩ  Ｆｕｎｃｔｉｏｎの識別子
１５１２  使用する帯域情報
１５１３  接続される外部装置の情報
１５１４  マルチルートＩＯデバイスの識別子
１５１５  マルチルートＰＣＩ  Ｅｘｐｒｅｓｓスイッチの識別子
１５１６  マルチルートＰＣＩ  Ｅｘｐｒｅｓｓスイッチのポート番号
１５１７  マルチルートＩＯデバイスのＰＣＩ  ＦｕｎｃｔＩＯｎの識別子
１５１８  空き帯域情報
１５１９  計算機の管理者に選択させるための設定部
２００１  障害処理ポリシー情報
２２０１  ＩＯデバイスの障害処理のポリシーレベル
ＦＴ２  ＩＯデバイス管理情報
ＦＴ９  サーバプロファイル
ＦＴ１３  ＩＯデバイス管理情報
ＦＴ１６  ＩＯデバイス管理情報
ＦＴ２１  ＩＯデバイスの障害処理ポリシー情報
ＦＴ２２  サーバプロファイル
【図１】
2010146175.tif 000003
【図２】
2010146175.tif 000004
【図３】
2010146175.tif 000005
【図４】
2010146175.tif 000006
【図５】
2010146175.tif 000007
【図６】
2010146175.tif 000008
【図７】
2010146175.tif 000009
【図８】
2010146175.tif 000010
【図９】
2010146175.tif 000011
【図１０】
2010146175.tif 000012
【図１１】
2010146175.tif 000013
【図１２】
2010146175.tif 000014
【図１３】
2010146175.tif 000015
【図１４】
2010146175.tif 000016
【図１５】
2010146175.tif 000017
【図１６】
2010146175.tif 000018
【図１７】
2010146175.tif 000019
【図１８】
2010146175.tif 000020
【図１９】
2010146175.tif 000021
【図２０】
2010146175.tif 000022
【図２１】
2010146175.tif 000023
【図２２】
2010146175.tif 000024
【図２３】
2010146175.tif 000025
【図２４】
2010146175.tif 000026