計算機システムでの部分障害処理方法
【課題】 論理分割可能な計算機では、ハードウェア障害が発生しても、障害の影響を受けないＬＰＡＲは実行を継続可能な場合がある。この場合、ハードウェア保守で計算機全体を停止しなければならない時に、継続稼働しているＬＰＡＲを停止してよいのか容易に判断できない。
【解決手段】 計算機で発生したハードウェア障害について、ハイパバイザが、実行継続可能なＬＰＡＲに実行継続可能なハードウェア障害として障害発生を通知し、それを受けたＬＰＡＲが障害対応処理を実行したことをハイパバイザに通知し、その通知状況を取得するためのインタフェイスをハイパバイザが提供する。このインタフェイスを通じて、ＬＰＡＲごとの実行継続可能なハードウェア障害への対応状況を登録・取得可能とし、計算機全体での対応状況を判定可能とする。
【解決手段】 計算機で発生したハードウェア障害について、ハイパバイザが、実行継続可能なＬＰＡＲに実行継続可能なハードウェア障害として障害発生を通知し、それを受けたＬＰＡＲが障害対応処理を実行したことをハイパバイザに通知し、その通知状況を取得するためのインタフェイスをハイパバイザが提供する。このインタフェイスを通じて、ＬＰＡＲごとの実行継続可能なハードウェア障害への対応状況を登録・取得可能とし、計算機全体での対応状況を判定可能とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、論理分割で複数のＬＰＡＲが実行している計算機システムでの、部分的な障害の処理方法に関する。
【背景技術】
【０００２】
計算機を有効に利用する方法として、仮想化や論理分割がある。これらの技術によれば、一台の物理計算機上に仮想的な計算機を構成できるため、物理計算機の能力を有効に活用できる。計算機性能の向上に伴い、安価な計算機においても仮想化や論理分割が利用可能となり、広く用いられている。
【０００３】
計算機は、さまざまなハードウェア障害検出機構を有する。計算機は、その各コンポーネントの異常を検知し、割り込みによってＯＳやハイパバイザといったソフトウェアに障害を通知する。障害を通知する割り込みは、一般にマシンチェック割り込みと呼ばれる。ＯＳやハイパバイザは、マシンチェックで通知された障害の内容に応じて計算機全体を停止する、あるいは、発生した障害に関係する部分のみを停止できる。
【０００４】
論理分割をサポートする計算機は、発生したハードウェア障害の影響を受けるＬＰＡＲにだけマシンチェックを通知し、マシンチェックを通知されたそのＬＰＡＲのみ実行を、停止できる。障害を起こしたコンポーネントを利用していないＬＰＡＲは、継続して実行できる。例えば、特許文献１では、計算機の入出力装置に発生した障害について、実行時に当該の障害に関係するＬＰＡＲを特定し、そのＬＰＡＲにのみマシンチェックを送信する方法を開示している。仮想化においても、原理的には、同様の障害処理が可能である。
【０００５】
データの消失や処理の中断が許容されない計算機システムを構成する技術として、クラスタ技術がある。クラスタに構成されたシステムでは、計算機が障害で停止してしまうことに備えて、予備の計算機を配備する。データ処理を実行する計算機（主系）と予備の計算機（従系）とが相互に稼働状態を監視し、主系のデータ処理が停止した場合に、従系がこのデータ処理を引き継ぐ。この引継ぎ処理を、フェイルオーバーと呼ぶ。これらの制御は、一般には、主系と従系で実行するクラスタ管理ソフトウェアと呼ばれるソフトウェアが実行する。
【０００６】
論理分割でのハードウェア障害処理とクラスタ構成を組み合わせることで、高信頼なシステムを構成できる。この場合、ハードウェア障害に関係するＬＰＡＲで実行するクラスタ管理ソフトウェアは、フェイルオーバーを実行して、そのＬＰＡＲで実行していたデータ処理を他の計算機で待機している従系のＬＰＡＲに継続させる。一方、障害の影響を受けないＬＰＡＲは、そのまま継続してデータ処理を実行することとなる。このような技術は、特許文献２に開示されている。
【０００７】
障害を発生したハードウェアは、いずれ交換が必要である。一般的には、クラスタを構成している場合、故障したハードウェアを搭載している計算機で主系として実行しているアプリケーション、仮想計算機及びＬＰＡＲを、クラスタ内の従系に構成された計算機へ手動でフェイルオーバーした後、主系の仮想計算機あるいはLPARを実行していた計算機の計算機を停止し、ハードウェアを交換する。保守を実施する作業員は、前と同じ計算機が停止可能か、何らかのデータ処理が実行していないかを何らかの手段で判定し、前と同じ計算機を停止する作業を実施することになる。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開2004-342109号公報
【特許文献２】特開2008-140198号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
論理分割を利用している場合、ハードウェア障害時に、その影響を受けるＬＰＡＲのみを停止し、他のＬＰＡＲの実行を継続できる。一方で、故障した部品を交換する際に計算機全体を停止しなければならない場合、実行を継続しているＬＰＡＲを停止してよいのか、その作業時に判断しなければならないという課題がある。一般には、ＬＰＡＲごとに無関係の業務が実行しているため、業務の停止の可否の判断は容易ではない。また、停止してよいとしても、作業員が手動で操作しなければならず、操作ミスの可能性が発生する問題がある。
【００１０】
クラスタ構成の場合も同様の問題が発生する。論理分割を利用していない場合のクラスタ構成では、物理計算機の運転モードは主系か従系の何れかであり、目視により簡単に把握させることができた。これにより、保守を実施する作業員は、容易に当該計算機の運転状態を把握することができ、安全に当該計算機を停止することができた。
【００１１】
一方、論理分割を採用し、ＬＰＡＲごとにクラスタを構成すると、ハードウェア障害時にＬＰＡＲごとにフェイルオーバーが実行し、一台の物理計算機内に主系と従系のＬＰＡＲが混在することとなる。このため、物理計算機の実行状態の把握には、複数のＬＰＡＲの状態を参照しなければならないため、確認作業が複雑になる問題がある。
【００１２】
また、作業員が、保守作業開始までに主系となっているＬＰＡＲをフェイルオーバーさせる必要がある。複数のＬＰＡＲの状態の参照や、データ処理を実行している主系のＬＰＡＲに対する手動の操作が必要となるため、これを実行する操作員には、判断や操作を正しく行うよう常に細心の注意を払わなければならないという大変さがある。
【課題を解決するための手段】
【００１３】
上記課題を解決するために、本発明は、クラスタを構成する物理計算機上に、ハイパバイザの制御により複数のＬＰＡＲが生成された仮想計算機システムに関し、以下のハードウェア障害処理を行うものである。即ち、第一の物理計算機でハードウェア障害が発生すると、第一の物理計算機が有する第一のハイパバイザは、第一の物理計算機上に生成されたＬＰＡＲについて実行の継続可能なＬＰＡＲの有無を判定する。実行の継続が可能でないＬＰＡＲがある場合、第一のハイパザイザは、実行の継続が可能でない第一のＬＰＡＲを停止し、第一のＬＰＡＲとクラスタを構成する第二の物理計算機上に生成された第二のＬＰＡＲが有するクラスタ制御部は、第一のＬＰＡＲの業務を第二のＬＰＡＲへフェイルオーバーする第一のフェイルオーバーをする。実行の継続が可能なＬＰＡＲがある場合、実行の継続が可能な第三のＬＰＡＲとクラスタを構成する第二の物理計算機上に生成された第四のＬＰＡＲが有するクラスタ制御部は、第三のＬＰＡＲの業務を第四のＬＰＡＲへフェイルオーバーする第二のフェイルオーバーを行う。
【００１４】
なお、第三のＬＰＡＲが有するクラスタ制御部は、第二のフェイルオーバーが完了すると、第一のハイパバイザが有する障害通知情報に対し、第二のフェイルオーバー後における第三のＬＰＡＲの停止の可否を、可に設定してもよい。
【００１５】
また、ハイパバイザの制御により複数のＬＰＡＲが生成され、クラスタを構成する物理計算機において、ハイパバイザは、障害通知情報を有し、障害通知情報は、ＬＰＡＲの実行に影響しないハードウェア障害について、ＬＰＡＲ毎の障害通知の要求有無及びフェイルオーバー後におけるＬＰＡＲの停止の可否を管理する。ハードウェア障害が発生すると、ハイパバイザは、障害通知情報を参照し、ハードウェア障害通知の要求があるＬＰＡＲに対して、障害通知を送信し、複数のＬＰＡＲについて実行の継続可能なＬＰＡＲの有無を判定する。実行の継続が可能でないＬＰＡＲがある場合、ハイパザイザは、実行の継続が可能でないＬＰＡＲ１を停止し、ＬＰＡＲ１は、クラスタを構成するＬＰＡＲへフェイルオーバーされる。実行の継続が可能なＬＰＡＲがある場合、実行の継続が可能なＬＰＡＲ２は、クラスタを構成するＬＰＡＲへフェイルオーバーされる。障害通知を受信したＬＰＡＲが有するクラスタ制御部は、ＬＰＡＲのフェイルオーバーが完了すると、障害通知情報におけるフェイルオーバー後におけるＬＰＡＲの停止の可否を、可に設定する。
【発明の効果】
【００１６】
本発明によれば、フェイルオーバー後におけるＬＰＡＲの停止の可否が障害通知情報に記録されるので、部分的なハードウェア障害発生後の保守時に、計算機が保守作業を実施可能な状態にあるかを、作業員が容易に判断可能となる。
【００１７】
また、実行継続可能なハードウェア障害の通知を受けたＬＰＡＲがそれに応じた障害対応処理を実行したことを通知するためのインタフェイスをハイパバイザが提供し、ＬＰＡＲの障害対応処理の通知状況をハイパバイザが保持し、その通知状況を取得するためのインタフェイスをハイパバイザが提供するので、これらのインタフェイスを通じて、ＬＰＡＲごとの実行継続可能なハードウェア障害への対応状況を登録・取得可能とし、計算機全体での対応状況を判定可能とする。
【図面の簡単な説明】
【００１８】
【図１】本発明の実施の形態での計算機の構成を示す図である。
【図２】本発明の実施の形態での計算機の構成を示す図である。
【図３】本発明の実施の形態での計算機システムの構成を示す図である。
【図４】本発明の実施の形態でのハイパバイザとクラスタ制御部の保持するデータの構造を示す図である。
【図５】本発明の実施の形態でのハイパバイザとＯＳのハードウェア障害処理手順を示すフローチャートである。
【図６】本発明の実施の形態でのクラスタ管理ミドル内のフェイルオーバー要求の監視手順を示すフローチャートである。
【図７】本発明の実施の形態でのデータ処理プログラムの処理手順を示すフローチャートである。
【図８】本発明の実施の形態でのクラスタ制御部のフェイルオーバー処理手順を示すフローチャートである。
【図９】本発明の実施の形態でのシステム構成を示す図である。
【図１０】本発明の実施の形態でのシステム管理画面を示す図である。
【図１１】フェイルオーバー要求テーブルの構造を示す図である。
【図１２】障害通知テーブルの状態を示す図である。
【発明を実施するための形態】
【００１９】
＜実施例１＞
本発明を適用した計算機システムについて、図面により説明する。
【００２０】
図３は、本発明の実施の形態の計算機システムの構成を示す図である。計算機１００と計算機２００で実行するＬＰＡＲ２１０と３１０、２６０と３６０がクラスタを構成している。計算機１００は計算機Ａ、計算機２００は計算機Ｂとして区別されているとする。計算機１００内では、ＬＰＡＲ２１０はＬＰＡＲ名がＬＰＡＲ１、２６０がＬＰＡＲ名がＬＰＡＲ２として区別されるとする。計算機２００内でもＬＰＡＲ３１０がＬＰＡＲ３、ＬＰＡＲ３６０がＬＰＡＲ４と名前付けされているとする。また、ＬＰＡＲ２１０とＬＰＡＲ２６０がクラスタの主系で、ＬＰＡＲ３１０と３６０がクラスタの従系であるとする。
【００２１】
計算機１００では、ハイパバイザ２５０（図３には記載していない）によってＬＰＡＲ２１０と２６０が構成され実行している。ハイパバイザ２５０は、計算機１００内のＣＰＵで実行するソフトウェアか、計算機１００内のハードウェアとして実現される。図３では、ハイパバイザ２５０が、ＬＰＡＲ２１０に論理的なＮＩＣ３９２と３９３、ＬＰＡＲ２６０にＮＩＣ３９４と３９５を割り当てていることを示している。他のＬＰＡＲも同様に論理的なＮＩＣを割り当てられている。
【００２２】
クラスタを構成するＬＰＡＲ２１０とＬＰＡＲ３１０を例に、ソフトウェア構成を説明する。ＬＰＡＲ２１０では、ＯＳ２３０、クラスタ制御部２２０、データ処理プログラム２１１が実行している。ＬＰＡＲ３１０も同様である。ＬＰＡＲ２１０のクラスタ制御部２２０とＬＰＡＲ３１０のクラスタ制御部３２０は、ネットワーク３９０を介して相互に稼働状況を監視している。クラスタ制御部２２０と３２０の制御下で、主系として実行しているＬＰＡＲでデータ処理プログラムが実行する。例えば、ＬＰＡＲ２１０が主系であれば、データ処理プログラム２１１が実際的な処理を実行する。
【００２３】
ＬＰＡＲ２１０が障害により実行を停止した場合は、ＬＰＡＲ３１０のクラスタ制御部３２０がＬＰＡＲ２１０の異常を検知し、フェイルオーバー処理を実行して、データ処理プログラム３１１の実行を開始する（以降、ＬＰＡＲ２１０は従系となる）。データ処理プログラム２１１と３１１は、ネットワーク３９１を経由して処理要求と結果を送受信する。
【００２４】
ここでデータ処理プログラムの実行を開始するとして説明したが、クラスタの構成によっては、従系でもデータ処理が実行しているが、実際的な出力を実施していない場合もある。この場合、クラスタ制御部は、フェイルオーバーでは、データ処理プログラム３１１が実際的な出力を開始するように制御する。
【００２５】
ＬＰＡＲ２６０とＬＰＡＲ３６０も同様なクラスタを構成しているとする。また、図３には記載していないが、主記憶装置、ＣＰＵ、データ処理プログラムの実行に必要な記憶装置などの資源も論理的分割され、各ＬＰＡＲに割り当てられているものとする。
【００２６】
図１は、本発明の実施でのクラスタを構成する計算機１００の構造を示している。計算機１００の構成として示すが、他の計算機も同様の構成である。計算機１００は、ＣＰＵ１０１ないし１０４、主記憶装置１２０、Ｉ／Ｏバス管理装置１３０が、バス１１０を介して接続している。Ｉ／Ｏバス管理装置１３０が接続するＩ／Ｏバス１４０には、ディスプレイやキーボードなどの入出力装置１５０、外部記憶装置に接続するためのＨＢＡ（Host Bus Adapter）１６１ないし１６３、ネットワークに接続するためのＮＩＣ（Network Interface Adapter）１７１ないし１７３が接続している。この例では、それぞれ３個ずつのアダプタを掲載したが３個に限定するものではなく、システムを構成するのに必要な個数だけアダプタは搭載される。
【００２７】
ＣＰＵ１０１ないし１０４は、主記憶装置１２０にプログラムを読み込み、主記憶装置１２０に読み込まれたプログラムを実行して、様々の処理を実行する。以降の説明では、これをプログラムや処理が実行すると記載する。
【００２８】
計算機１００内の各コンポーネントは、異常検知の機能を有しているとする。例えば、ＣＰＵ１０１ないし１０４は、内部キャッシュの一部の故障、内部のコアの故障、内部のレジスタの故障などを検知できるとする。ＣＰＵ１０１ないしＣＰＵ１０４は、このような内部の障害を検知するとマシンチェック割り込みを生成して、ソフトウェアに異常を通報する。
【００２９】
主記憶装置１２０、Ｉ／Ｏバス管理装置１３０、ＨＢＡ１６１ないしＨＢＡ１６３、ＮＩＣ１７１ないし１７３も、同様の機能を有しているとする。主記憶装置１２０の障害の場合、主記憶装置１２０を管理する装置を経由して、ＣＰＵ１０１ないし１０４の何れか、あるいは、すべてにマシンチェック割り込みを送信する。ＨＢＡ１６１ないし１６３、ＮＩＣ１７１ないし１７３が異常を検知した場合、Ｉ／Ｏバス管理装置１３０がマシンチェック割り込みを送信する。
【００３０】
図２は、本発明の実施の形態の、計算機内のソフトウェアの構成を示す図である。計算機１００を例に説明する。計算機１００は、ハイパバイザ２５０を実行している。ハイパバイザ２５０は、計算機１００の資源を論理的に分割し、ＬＰＡＲ２１０とＬＰＡＲ２６０を実行している。分割される資源は、ＣＰＵ１０１ないし１０４、主記憶装置１２０、ＨＢＡ１６１ないし１６３、ＮＩＣ１７１ないし１７３である。それぞれのＬＰＡＲ２１０と２６０は、ハイパバイザ２５０が提供する資源を利用して実行している。ハイパバイザ２５０は、計算機１００を構成するコンポーネントからのマシンチェック割り込みを処理するマシンチェック割り込み処理部２５１、障害通知テーブル２５２を有している。
【００３１】
障害通知テーブル２５２の構成を図４に示す。テーブル２５２は、ハイパバイザ２５０の上で実行する各ＬＰＡＲについて、ＬＰＡＲ番号４０１、当該ＬＰＡＲに影響しないハードウェア障害の通知を要求しているかを示すフラグ（障害通知要否フラグ４０２）、過去のハードウェア障害の有無（障害通知フラグ４０３）、ハードウェア障害の通知後に当該ＬＰＡＲで障害に対応する処理が実行されて、当該ＬＰＡＲを停止してよい状態となっているかを示すフラグ（停止可否フラグ４０４）を保持する。
【００３２】
ハイパバイザ２５０は、障害通知要否フラグ４０２、停止可否フラグ４０４を設定するインタフェイスを、ＯＳ２３０から利用可能なようにＬＰＡＲ２１０に提供する。ハイパバイザ２５０は、ＬＰＡＲ開始時にテーブル２５２の当該ＬＰＡＲ用のエントリを割り当て、障害通知要否フラグ４０２に否、障害通知フラグに否、停止可否フラグに否を示す値を設定する。この時のテーブル内容を図４の４１０に示す。
【００３３】
ＬＰＡＲ内の構成について、ＬＰＡＲ２１０を例に説明する。ＬＰＡＲ２１０では、ＯＳ２３０が実行している。ＯＳ２３０には、ハイパバイザが送信した論理的なマシンチェック割り込みを処理するマシンチェック割り込み処理部２３１がある。ＯＳ２３０は、マシンチェック割り込みが発生したことを、ＯＳ２３０で実行するプログラムに通知するインタフェイスを有する。プログラムは、そのインタフェイスを介して、マシンチェック割り込み発生の通知を受信できるものとする。
【００３４】
ＬＰＡＲ２１０は、ＬＰＡＲ３１０とクラスタを構成している。ＬＰＡＲ２１０は、ＯＳ２３０を実行している。ＯＳ２３０上では、クラスタ制御部２２０が実行している。クラスタ制御部２２０は、主系と従系の間の相互監視や、フェイルオーバー処理を実行する。クラスタ制御部２２０は、ＯＳ２３０からハードウェア障害が発生している旨の通知を受け付ける障害通知受付部２２２、フェイルオーバー要求を管理するフェイルオーバー要求テーブル２２３、フェイルオーバー処理を実施するフェイルオーバー処理部２２４、フェイルオーバー処理をスケジュールする要求監視部２２５、クラスタで実行するデータ処理プログラム２１１にクラスタ状態等の情報提供や、フェイルオーバー操作インタフェイスを提供するクラスタ制御インタフェイス２２１を有している。
【００３５】
クラスタ制御部２２０は、クラスタ構成を開始する際に、ハイパバイザ２５０が提供するインタフェイスを通じて、当該ＬＰＡＲにハードウェア障害を通知するように、障害通知要否フラグ４０２を「要」に、停止可否フラグ４０４を「否」に設定する。ＬＰＡＲ２６０のクラスタ制御部２７０も実行している時点の障害通知テーブル２５２の状態を図４の４２０に示す。
【００３６】
従系となるＬＰＡＲ３１０のクラスタ制御部３２０は、停止可否フラグ４０４を「可」に設定する。停止可否フラグの設定は、データ処理プログラムを実行している主系の側は停止させてはいけないが、従系の側は停止してもよいことを示す設定である。ＬＰＡＲ３６０のクラスタ制御部３７０も実行している時点の障害通知テーブル２５２の状態を図４の４３０に示す。ここでは、ＬＰＡＲ３とＬＰＡＲ４が従系となっている様子を示している。
【００３７】
クラスタ制御部２２０と３２０は、その制御下で実行するＬＰＡＲの運転モードが従系から主系に遷移する際には、障害通知テーブル２５２の停止可否フラグ４０４を「可」から「否」に、逆の遷移をする場合には「否」から「可」に設定する。
【００３８】
クラスタ制御部２２０のフェイルオーバー要求テーブル２２３の構造を図１１に示す。テーブル２２３は、フェイルオーバー実施の要求を受けているか（要求フラグ１１１０）、未処理のフェイルオーバー要求があるか（未完要求フラグ１１１１）を示す値を保持している。クラスタ制御インタフェイス２２１を通じて、データ処理プログラム２１１や他のプログラムは、これらのフラグを設定可能である。また、フェイルオーバー処理部２２４、要求監視部２２５もこれらのフラグを操作する。
【００３９】
データ処理プログラム２１１は、クラスタ上で実行するアプリケーションである。ＬＰＡＲ２１０が主系である時に障害で実行を停止すると、このプログラム２１１の処理が計算機２００のＬＰＡＲ３１０で引き継がれる。この際、処理を引き継いだＬＰＡＲ３１０が主系となるように、クラスタ制御部３２０が制御を行う。
【００４０】
もう一方のＬＰＡＲ２６０も同様の構成である（図は省略）。データ処理プログラム２６１は、ＬＰＡＲ２１０で実行するプログラム２１１とは、独立に実行するプログラムであってよい。また、計算機２００のＬＰＡＲ３１０と３６０の構成も同様である。
【００４１】
図３のシステムで、計算機１００にハードウェア障害が発生したものとして、本実施の形態でのハードウェア障害処理方法を説明する。ここでは、計算機１００で実行するＬＰＡＲ２１０と２６０が主系、計算機２００で実行するＬＰＡＲ３１０と３６０が従系であるとして説明する。以下、ＬＰＡＲ２１０での動作について説明するが、他のＬＰＡＲでも同様の動作を実行する。
【００４２】
まず、クラスタ制御部２２０の動作について説明する。クラスタ開始時に、クラスタを構成する各ＬＰＡＲのクラスタ制御部は、ハードウェア障害の発生を示すマシンチェック割り込みを通知するよう、ＯＳに登録する。ＬＰＡＲ２１０であれば、クラスタ制御部２２０はＯＳ２３０にマシンチェック割り込みの通知を要求する（フロー省略）。
【００４３】
ＬＰＡＲ２１０の稼働中、クラスタ制御部２２０は、一般的なクラスタと同様に、サービスを提供するデータ処理プログラム２１１の実行を制御し、クラスタを構成する計算機を相互に監視している。例の構成であれば、ＬＰＡＲ３１０で実行するクラスタ制御部３２０と相互に通信して、稼働状況を監視している。従系側のクラスタ制御部３２０が主系の異常を検知すると、クラスタ制御部３２０の制御によりフェイルオーバーが実行されて、ＬＰＡＲ３１０が主系になる。
【００４４】
クラスタ制御部２２０は、ＯＳ２３０やデータ処理プログラム２１１からのクラスタ制御要求も待機している。
【００４５】
次に、ハードウェア障害発生時の動作について説明する。ここで説明するのは、障害が部分的な障害であり、影響を受けるＬＰＡＲのみ停止すれば、他のＬＰＡＲは継続して実行可能である場合についてである。すべてのＬＰＡＲに影響を及ぼすハードウェア障害の場合は、全ＬＰＡＲの実行を停止し、クラスタを構成している全ＬＰＡＲがフェイルオーバーすることになる。ここでは、ＬＰＡＲ２６０が実行継続不可となるハードウェア障害が発生したとして説明する。
【００４６】
図５に、部分的なハードウェア障害発生時のハイパバイザのマシンチェック割り込み処理部２５１と、ＯＳ２３０のマシンチェック割り込み処理部２３１の処理フローを示す。
【００４７】
計算機１００でハードウェア障害が発生すると、障害を起こしたコンポーネントはＣＰＵ１０１ないしＣＰＵ１０４にマシンチェック割り込みを送信する。割り込みを捕獲したＣＰＵは、ハイパバイザ２５０のマシンチェック割り込み処理部２５１を実行する。マシンチェック割り込み処理部２５１は、割り込みの内容から障害部位を特定し（ステップ５０１）、そのハードウェア障害の影響で実行が不可能となるＬＰＡＲを特定する（ステップ５０２）。
【００４８】
マシンチェック割り込み処理部２５１は、実行が不可能なＬＰＡＲに、実行継続不可を示すマシンチェック(Uncorrectable Machine Check)を送信し、当該ＬＰＡＲの実行を停止させる（ステップ５０３）。この時、クラスタ制御部２２０は、障害通知テーブル２５２の障害通知フラグを「あり」に、停止可否フラグを「可」に変更する。
【００４９】
この例では、ハイパバイザからＬＰＡＲ２６０に、実行継続不可マシンチェック割り込みを送信する。ＬＰＡＲ２６０で実行するＯＳ２８０のマシンチェック割り込み処理部２８１が、ハイパバイザのマシンチェック割り込み処理部２５１から送信された割り込みを捕獲し、ＯＳ２８０の実行を停止する。
【００５０】
ＯＳ２８０の実行が停止すると、クラスタを構成する計算機２００のＬＰＡＲ３６０のクラスタ制御部３７０が、ＯＳ２８０の実行の停止を検知して、フェイルオーバーを実行する。この結果、ＬＰＡＲ３６０が主系となり、データ処理プログラム３６１が実行を開始する。この時、前述したとおり、クラスタ制御部３７０は、障害通知テーブル２５２のＬＰＡＲ３６０（ＬＰＡＲ４）の停止可否フラグ４０４を「否」に設定している。この時の計算機２００の障害通知テーブル２５２の様子を、図１２の４４０に示す。
【００５１】
次に、マシンチェック割り込み処理部２５１は、障害通知テーブル２５２の障害通知要否フラグ４０２を参照して、障害通知を要求しているＬＰＡＲについて、障害通知フラグ
４０３を「あり」に、停止可否フラグ４０４を「否」に設定し、実行継続可能であるがハードウェア障害が発生している旨を通知するマシンチェック(Correctable Machine Check)を送信する（ステップ５０４）。
【００５２】
図４の４２０に示す通り、ＬＰＡＲ１に対応するＬＰＡＲ２１０が通知を要求しており、マシンチェック割り込み処理部２５１は、ＬＰＡＲ２１０に実行継続可能マシンチェックを送信する。また、割り込み処理部２５１は、マシンチェック送信前に、障害通知テーブル２５２のＬＰＡＲ２１０に対応する障害通知フラグ４０３を「あり」に、停止可否フラグ４０４を「否」に設定する。この時、ＬＰＡＲ２１０（ＬＰＡＲ１）の障害通知テーブル２５２は、障害通知フラグ４０３が「あり」、停止可否フラグ４０３が「否」となっている。この状態は、ＬＰＡＲ２１０がハードウェア障害通知を受信したが、それに対応してＬＰＡＲ２１０を停止するために必要な処理が完了していないことを示している。この時の計算機１００の障害通知テーブル２５２の様子を図１２の４５０に示す。
【００５３】
ＬＰＡＲ２６０の実行はすでに停止しているので、マシンチェックは送信しない。
【００５４】
マシンチェック割り込みを受けて、ＯＳ２３０のマシンチェック割り込み処理部２３１が起動し、以下に示す処理を実行する。
【００５５】
割り込み処理部２３１は、捕獲したマシンチェックが実行継続不可を示すマシンチェックかどうかを判定する（ステップ５１０）。
【００５６】
実行継続不可なマシンチェックである場合は、ＯＳ２３０の実行を停止する（ステップ５１３）。
【００５７】
実行継続可能なマシンチェックである場合は、障害発生を記録し（ステップ５１１）、障害通知を要求しているプログラムに障害内容を通知する（ステップ５１２）。
【００５８】
この例では、クラスタ制御部２２０がマシンチェック割り込みの通知を要求しているので、ＯＳ２３０は、クラスタ制御部２２０の障害通知受付部２２２を実行するようにスケジュールする。この例では、マシンチェックの通知を割り込み処理部２３１から通知するとしたが、マシンチェック割り込み処理部２３１の実行完了後に、通知処理が実行されてもよい。
【００５９】
マシンチェック割り込み処理終了後、障害通知受付部２２２が、ＯＳ２３０によってディスパッチされて実行する。障害通知受付部２２２は、クラスタ制御部２２０のフェイルオーバー要求テーブル２２３の要求フラグ１１１０を「あり」、未完要求フラグ１１１１を「あり」を示す値に設定する（処理フローなし）。
【００６０】
クラスタ制御部２２０の要求監視部２２５は、定期的にフェイルオーバー要求テーブル２２３をチェックする処理を実行している。図６に処理フローを示す。要求管理部２２５は、フェイルオーバー要求テーブル２２３の未完要求フラグ１１１１を検査し、要求があったがフェイルオーバーが完了していないかどうかを判定する（ステップ６０１）。
【００６１】
そうである場合、テーブル２２３の要求フラグ１１１０を「あり」に再設定する（ステップ６０２）。
【００６２】
要求管理部２２５は、これらの処理ののち、あらかじめ決められた時間待機して（ステップ６０３）、ステップ６０１からチェック処理を繰り返す。
【００６３】
これによって、一定時間ごとに未完了のフェイルオーバー要求を再発行し、最初のフェイルオーバー要求の時点でフェイルオーバーができない状態であっても、将来のある時点でフェイルオーバー処理が再実行されるようにする。なお、一定時間とは、実行している業務に応じてユーザが設定するものであり、例えば３０秒毎としてもよい。
【００６４】
次に、データ処理プログラム２１１の処理内容を説明する。図７に、データ処理プログラム２１１の処理フローを示す。データ処理プログラム２１１は、基本的には、ネットワーク経由で送信される処理要求を受け付け、それに対応するデータ処理を実施することを繰り返しているものとする。
【００６５】
データ処理プログラム２１１は、処理要求を待機している（ステップ７０１）。データ処理プログラム２１１は、あらかじめ決められた時間でタイムアウトするように待機している。処理要求が到着するかタイムアウトによって、ステップ７０１は完了する。
【００６６】
データ処理プログラム２１１は、クラスタ制御インタフェイス２２１を介してクラスタ制御部２２０にフェイルオーバー要求があるかを問い合わせる（ステップ７０２）。クラスタ制御部２２０は、フェイルオーバー要求テーブル２２３の要求フラグ１１１０の値を返す。
【００６７】
ステップ７０２でフェイルオーバー要求がないと判定された場合、要求されたデータ処理を実行する（ステップ７０３）。ただし、タイムアウトでステップ７０１を完了している場合は、何もしない。
【００６８】
処理完了後、データ処理プログラム２１１は、再び処理要求の到着を待つ（ステップ７０１）。
【００６９】
ステップ７０２でフェイルオーバー要求があると判定された場合、データ処理プログラム２１１は、クラスタ制御部２２０にフェイルオーバーを要求する（ステップ７１０）。
【００７０】
要求後、データ処理プログラム２１１は、フェイルオーバー処理の完了を待ち、フェイルオーバーの実行状況をクラスタ制御部２２０から取得し、フェイルオーバーが成功したかどうかを判定する（ステップ７１１）。
【００７１】
フェイルオーバーが成功した場合は、データ処理プログラム２１１は実行を停止する。失敗した場合は、データ処理プログラム２１１は、再び処理要求の到着を待機する（ステップ７０１）。
【００７２】
フェイルオーバーが失敗した場合は、要求監視部２２５の処理によって、将来のある時点でフェイルオーバーが再度要求される。フェイルオーバーが成功した時点でデータ処理プログラム２１１の処理が強制的に停止する処理であってもよい。この場合、フェイオーバー失敗の場合のみデータ処理プログラム２１１の処理が継続することになる。
【００７３】
図８にクラスタ制御部２２０のフェイルオーバー処理部２２４の処理フローを示す。
【００７４】
フェイルオーバー処理部２２４は、データ処理プログラム２１１の要求を受けてフェイルオーバー処理を実行する（ステップ８０１）。フェイルオーバーが完了すると、計算機３００のＬＰＡＲ３１０が主系となり、データ処理プログラム３１１が要求を受け付け、データ処理を実行する。
【００７５】
フェイルオーバー処理部２２４は、フェイルオーバーが成功したかどうかを判定する（ステップ８０２）。
【００７６】
フェイルオーバーが成功した場合には、フェイルオーバー要求テーブル２２３の未完要求フラグ１１１１を「なし」に、要求フラグ１１１０も「なし」に設定する（ステップ８０３）。
【００７７】
さらに、ハイパバイザ２５０内の障害通知テーブル２５２の停止可否フラグ４０４を「可」に設定する（ステップ８０４）。これは、ハイパバイザ２５０が提供するインタフェイスを介して実行する。これにより、障害通知テーブル２５２のＬＰＡＲ２１０のエントリは、障害通知フラグ４０３が「あり」、停止可否フラグ４０４が「可」になったことになる。これは、障害が通知されて、それに対応して停止する準備が整ったことを示している。この時の計算機１００の障害通知テーブル２５２の様子を図１２の４６０に示す。これに示される通り、計算機１００で実行しているＬＰＡＲ１とＬＰＡＲ２は停止可能であることが、障害通知テーブル２５２を参照することで容易に判別可能となる。また、計算機２００の障害通知テーブル２５２の様子を図１２の４７０に示す。ＬＰＡＲ３１０が主系になったことに伴い、ＬＰＡＲ３の停止可否フラグ４０４が「否」となっている様子を示している。
【００７８】
なお、フェイルオーバーが失敗した場合には、主系での実行が継続する。後の時点で、フェイルオーバーが再度要求される。
【００７９】
以上の実施の形態により、計算機１００でハードウェア障害が発生した際に、その障害とは無関係、即ち障害の発生していないハード上のクラスタ構成をとるＬＰＡＲに自動的にフェイルオーバーし、その結果ＬＰＡＲ２１０が従系となるため、将来の保守作業に備えて、障害が発生したハードウェアの実行を停止する作業を、作業者が実施可能となる。
【００８０】
本発明では、障害通知要求フラグ４０２と停止可否フラグ４０４を管理する障害通知テーブル２５２ハイパバイザ２５０内に設け、これらを更新するインタフェイスをハイパバイザ２５０が提供している。これによって、ハイパイザ２５０は、部分障害発生時に継続実行が可能なＬＰＡＲに障害発生を通知し、将来の停止に向けた処理を実行させることが可能となっている。また、ＬＰＡＲで実行するプログラム（実施例ではクラスタ制御部２２０）が、自身の実行とは直接関係のない部分障害の通知を受けて、将来の保守時のシステムの停止に向けた処理を実行することができる（実施例ではフェイルオーバーを実施）。これによって、障害通知を受けたＬＰＡＲは、将来の保守に備えて実行するための準備を実行し、加えて、準備完了したことをハイパバイザ２５０に通知できる。通常のシステムでは、ＬＰＡＲを停止可能であるかどうかを確認する方法は実行されている業務に依存するため、個別に確認しなければならない。本発明によれば、ハイパバイザ２５０は、計算機１００全体を停止可能かどうかを判断するための情報を、実行する業務に関係なく保持できるため、保守に関わる作業員は容易に計算機を停止可能かどうか判断可能となる。
【００８１】
また、本実施の形態のようにクラスタ制御と組み合わせることにより、ハードウェア障害発生から保守の時点までのいずれかの時点で、安全に系切り替えを実行して、保守作業に備えることが可能である。ハードウェア障害の通知を外部から監視して系切り替えを起動することも可能であるが、ハイパバイザがクラスタ制御に系切り替えの契機を与えることにより、ハードウェア障害の発生を外部から監視するためのシステム構成が不要となる。このような監視のシステムは、ハードウェア障害を見落とさないために二重化するといった構成が必要になるが、これらが不要となり、システム構成が簡便、かつ、高信頼となる。
【００８２】
また、系切り替え等の作業を自動で実施することにより、保守の時点で必要となる手動の作業が削減され、
本発明では、クラスタ制御と組み合わせたが、クラスタ制御に限定するものではない。マシンチェック割り込みの通知を受けて、ハイパバイザ２５０の障害通知テーブル２５２を更新するプログラムが実行していれば、将来の停止に向けた処理を実行することが可能である。
【００８３】
＜実施例２＞
次に、本発明を適用した第二の計算機システムについて説明する。図９は、本発明の第二の実施の形態のシステム構成図である。
【００８４】
第二の実施の形態では、第一の実施の形態でのシステム構成に加えて、計算機１００と計算機２００の稼働状態を監視する計算機９００が追加されている。計算機１００と計算機２００は、ＮＩＣ９３１と９３２が搭載されており、ネットワーク９２０を介して計算機９００と接続している。このネットワーク９２０を介して、ハイパバイザ２５０のインタフェイスを参照可能で、障害通知テーブル２５２の内容を取得可能であるとする。
【００８５】
計算機９００は、図１に示したのと同様の構成の計算機である。計算機９００では、障害状況表示部９１０が実行している。障害状況表示部９１０は、管理対象の計算機から情報を取得して表示する。ここでは、計算機１００と計算機２００が管理対象として登録されているとする。特に、計算機１００と計算機２００のハイパバイザから、障害通知テーブル２５２の状態を取得して表示する。これによって、実行継続可能なハードウェア障害の発生の有無と、それに対応した停止準備処理が実行されたかを容易に判定できる。
【００８６】
図１０に障害状況の表示の例を示す。これは、第一の実施の形態で、ＬＰＡＲ２１０のフェイルオーバーが完了した後の状態を示している例である。この表示は、図１２に示した計算機１００の障害通知テーブル４６０、計算機２００の障害通知テーブル４７０に基づき構成される。この表示の内容の構成方法を以下に説明する。
【００８７】
図１０の表示を作成する障害状況表示部９１０は、計算機Ａに対応する計算機１００のＬＰＡＲ名１００１、稼働状況１００２をハイパバイザ２５２より取得する。これらの情報は、管理情報としてハイパバイザ２５２から取得可能であるとする。障害状況表示部９１０は、稼働中のＬＰＡＲについて、障害通知テーブル２５２の内容をハイパバイザより取得する。具体的には、障害状況表示部９１０は、障害通知１００３の内容を障害通知テーブル２５２の障害通知フラグ４０３より取得した値を、停止可否１００４の内容を障害通知テーブル２５２の停止可否フラグ４０４より取得した値を表示する。この例では、ＬＰＡＲ２６０（ＬＰＡＲ２）は停止しているため、ＬＰＡＲ２１０（ＬＰＡＲ１）の情報を取得して表示する。停止しているＬＰＡＲの情報は、ＬＰＡＲ名と稼働状況のみ表示し、他の情報は表示しない。
【００８８】
計算機Ｂに対応する計算機２００の情報も同様に取得して表示する。具体的には、ＬＰＡＲ３１０（ＬＰＡＲ３）、ＬＰＡＲ２６０（ＬＰＡＲ４）の情報を取得して、ＬＰＡＲ名１０１１、稼働状況１０１２、障害通知１０１３、停止可否１０１４を表示する。
【００８９】
図１２の障害管理テーブル４６０ではＬＰＡＲ１の障害通知フラグ４０３は「あり」、停止可否フラグ４０４は「可」となっているため、障害状況表示部９１０は、計算機１００の障害通知１００３は「あり」、停止可否１００４は「可」と表示する。計算機２００についても同様に、障害通知テーブル４７０の内容を取得して情報を表示する。
【００９０】
この例では、計算機Ａが計算機１００に、計算機Ｂが計算機２００に対応している。計算機ＡではＬＰＡＲ１が実行中であるが、障害通知を受け、停止可能な状態になっていること、ＬＰＡＲ２が実行を停止していることを表示している。また、計算機ＢではＬＰＡＲ３，４とも実行中であることを示している。
【００９１】
保守作業では、画面表示１０００を参照することにより、計算機ＡではＬＰＡＲ１が実行しているが停止可能であることが、この画面を通じて判断することができる。
【００９２】
以上により、ハードウェアの部分障害で実行を継続するＬＰＡＲがあっても、保守の時点で停止可能な状態になっているかを容易に判断することが可能となる。これは、ＬＰＡＲで実行するクラスタ制御部２２０のような管理ソフトウェアが、ハイパバイザが提供するインタフェイスによってハイパバイザ２５０と連携して、ハイパバイザ２５０内の障害通知テーブル２５２にＬＰＡＲの停止可否状態を設定可能となっていることによる。
【００９３】
一般に、ＬＰＡＲに搭載される業務システムは無関係のシステムであり、業務を停止可能かどうかは、その業務システムの管理者でなければ判断できない。本発明によれば、部分障害で継続実行しているＬＰＡＲに、保守作業に向けた停止準備を実行させ、その準備処理の状況を容易に確認することができる。これにより、故障部品の交換時に、計算機を停止する作業が容易になる。
【００９４】
本実施の形態では、データ処理プログラム２１１とクラスタ制御部２２０が連携してフェイルオーバーを実行したが、クラスタ制御部２２０が単独でフェイルオーバーを起動してもよい。
【００９５】
これまでの実施の形態では、データ処理プログラム２１１にクラスタのフェイルオーバーの実行タイミングを判断させていたが、ハイパバイザがＬＰＡＲの動作状況を監視して、クラスタ制御部２２０にフェイルオーバーを起動させることでもよい。例えば、ＬＰＡＲのアイドル状態の検知、Ｉ／Ｏ状態の監視により、処理の切れ目を判定してフェイルオーバーを実行してもよい。
【００９６】
以上の実施の形態では、論理分割を前提として説明したが、仮想化機構が部分障害に対応した機能を持っている場合は、それを前提としてもよい。
【符号の説明】
【００９７】
１００…計算機、１０１ないし１０４…ＣＰＵ、１１０…バス、１２０…主記憶装置、１３０…Ｉ／Ｏバス制御装置、１４０…Ｉ／Ｏバス、１５０…入出力装置、１６１ないし１６３…ＨＢＡ、１７１ないし１７３ＮＩＣ、２００…計算機、２１０…ＬＰＡＲ、２１１…データ処理プログラム、２１２…クラスタ制御連携部、２２０…クラスタ制御部、２２１…クラスタ制御インタフェイス、２２２…障害通知受付部、２２３…フェイルオーバー要求テーブル、２２４…フェイルオーバー処理部、２２５…要求監視部、２３０…ＯＳ，２３１…マシンチェック割り込み処理部、２５０…ハイパバイザ、２５１…マシンチェック割り込み処理部、２５２…障害通知テーブル、２６０…ＬＰＡＲ、２６１…データ処理プログラム、２７０…クラスタ制御部、２８０…ＯＳ、３１０…ＬＰＡＲ、３１１…データ処理プログラム、３２０…クラスタ制御部、３３０…ＯＳ、３６０…ＬＰＡＲ、３６１…データ処理プログラム、３７０…クラスタ制御部、３８０…ＯＳ、３９０ないし３９１…ネットワーク、３９２ないし３９９…ＮＩＣ、４０１ないし４０４…障害通知テーブル２５２内のデータ、４１０ないし４７０…障害通知テーブルの状態例、５０１ないし５１３…処理ステップ、６０１ないし６０３…処理ステップ、７０１ないし７１１…処理ステップ、８０１ないし８０４…処理ステップ、９００…計算機、９１０…障害状況処理部、９２０…ネットワーク、９３１ないし９３２…ＮＩＣ、１０００…画面表示例、１００１ないし１０１４…画面表示内容、１１１０ないし１１１１…フェイルオーバー要求テーブル２２３内のデータ
【技術分野】
【０００１】
本発明は、論理分割で複数のＬＰＡＲが実行している計算機システムでの、部分的な障害の処理方法に関する。
【背景技術】
【０００２】
計算機を有効に利用する方法として、仮想化や論理分割がある。これらの技術によれば、一台の物理計算機上に仮想的な計算機を構成できるため、物理計算機の能力を有効に活用できる。計算機性能の向上に伴い、安価な計算機においても仮想化や論理分割が利用可能となり、広く用いられている。
【０００３】
計算機は、さまざまなハードウェア障害検出機構を有する。計算機は、その各コンポーネントの異常を検知し、割り込みによってＯＳやハイパバイザといったソフトウェアに障害を通知する。障害を通知する割り込みは、一般にマシンチェック割り込みと呼ばれる。ＯＳやハイパバイザは、マシンチェックで通知された障害の内容に応じて計算機全体を停止する、あるいは、発生した障害に関係する部分のみを停止できる。
【０００４】
論理分割をサポートする計算機は、発生したハードウェア障害の影響を受けるＬＰＡＲにだけマシンチェックを通知し、マシンチェックを通知されたそのＬＰＡＲのみ実行を、停止できる。障害を起こしたコンポーネントを利用していないＬＰＡＲは、継続して実行できる。例えば、特許文献１では、計算機の入出力装置に発生した障害について、実行時に当該の障害に関係するＬＰＡＲを特定し、そのＬＰＡＲにのみマシンチェックを送信する方法を開示している。仮想化においても、原理的には、同様の障害処理が可能である。
【０００５】
データの消失や処理の中断が許容されない計算機システムを構成する技術として、クラスタ技術がある。クラスタに構成されたシステムでは、計算機が障害で停止してしまうことに備えて、予備の計算機を配備する。データ処理を実行する計算機（主系）と予備の計算機（従系）とが相互に稼働状態を監視し、主系のデータ処理が停止した場合に、従系がこのデータ処理を引き継ぐ。この引継ぎ処理を、フェイルオーバーと呼ぶ。これらの制御は、一般には、主系と従系で実行するクラスタ管理ソフトウェアと呼ばれるソフトウェアが実行する。
【０００６】
論理分割でのハードウェア障害処理とクラスタ構成を組み合わせることで、高信頼なシステムを構成できる。この場合、ハードウェア障害に関係するＬＰＡＲで実行するクラスタ管理ソフトウェアは、フェイルオーバーを実行して、そのＬＰＡＲで実行していたデータ処理を他の計算機で待機している従系のＬＰＡＲに継続させる。一方、障害の影響を受けないＬＰＡＲは、そのまま継続してデータ処理を実行することとなる。このような技術は、特許文献２に開示されている。
【０００７】
障害を発生したハードウェアは、いずれ交換が必要である。一般的には、クラスタを構成している場合、故障したハードウェアを搭載している計算機で主系として実行しているアプリケーション、仮想計算機及びＬＰＡＲを、クラスタ内の従系に構成された計算機へ手動でフェイルオーバーした後、主系の仮想計算機あるいはLPARを実行していた計算機の計算機を停止し、ハードウェアを交換する。保守を実施する作業員は、前と同じ計算機が停止可能か、何らかのデータ処理が実行していないかを何らかの手段で判定し、前と同じ計算機を停止する作業を実施することになる。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開2004-342109号公報
【特許文献２】特開2008-140198号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
論理分割を利用している場合、ハードウェア障害時に、その影響を受けるＬＰＡＲのみを停止し、他のＬＰＡＲの実行を継続できる。一方で、故障した部品を交換する際に計算機全体を停止しなければならない場合、実行を継続しているＬＰＡＲを停止してよいのか、その作業時に判断しなければならないという課題がある。一般には、ＬＰＡＲごとに無関係の業務が実行しているため、業務の停止の可否の判断は容易ではない。また、停止してよいとしても、作業員が手動で操作しなければならず、操作ミスの可能性が発生する問題がある。
【００１０】
クラスタ構成の場合も同様の問題が発生する。論理分割を利用していない場合のクラスタ構成では、物理計算機の運転モードは主系か従系の何れかであり、目視により簡単に把握させることができた。これにより、保守を実施する作業員は、容易に当該計算機の運転状態を把握することができ、安全に当該計算機を停止することができた。
【００１１】
一方、論理分割を採用し、ＬＰＡＲごとにクラスタを構成すると、ハードウェア障害時にＬＰＡＲごとにフェイルオーバーが実行し、一台の物理計算機内に主系と従系のＬＰＡＲが混在することとなる。このため、物理計算機の実行状態の把握には、複数のＬＰＡＲの状態を参照しなければならないため、確認作業が複雑になる問題がある。
【００１２】
また、作業員が、保守作業開始までに主系となっているＬＰＡＲをフェイルオーバーさせる必要がある。複数のＬＰＡＲの状態の参照や、データ処理を実行している主系のＬＰＡＲに対する手動の操作が必要となるため、これを実行する操作員には、判断や操作を正しく行うよう常に細心の注意を払わなければならないという大変さがある。
【課題を解決するための手段】
【００１３】
上記課題を解決するために、本発明は、クラスタを構成する物理計算機上に、ハイパバイザの制御により複数のＬＰＡＲが生成された仮想計算機システムに関し、以下のハードウェア障害処理を行うものである。即ち、第一の物理計算機でハードウェア障害が発生すると、第一の物理計算機が有する第一のハイパバイザは、第一の物理計算機上に生成されたＬＰＡＲについて実行の継続可能なＬＰＡＲの有無を判定する。実行の継続が可能でないＬＰＡＲがある場合、第一のハイパザイザは、実行の継続が可能でない第一のＬＰＡＲを停止し、第一のＬＰＡＲとクラスタを構成する第二の物理計算機上に生成された第二のＬＰＡＲが有するクラスタ制御部は、第一のＬＰＡＲの業務を第二のＬＰＡＲへフェイルオーバーする第一のフェイルオーバーをする。実行の継続が可能なＬＰＡＲがある場合、実行の継続が可能な第三のＬＰＡＲとクラスタを構成する第二の物理計算機上に生成された第四のＬＰＡＲが有するクラスタ制御部は、第三のＬＰＡＲの業務を第四のＬＰＡＲへフェイルオーバーする第二のフェイルオーバーを行う。
【００１４】
なお、第三のＬＰＡＲが有するクラスタ制御部は、第二のフェイルオーバーが完了すると、第一のハイパバイザが有する障害通知情報に対し、第二のフェイルオーバー後における第三のＬＰＡＲの停止の可否を、可に設定してもよい。
【００１５】
また、ハイパバイザの制御により複数のＬＰＡＲが生成され、クラスタを構成する物理計算機において、ハイパバイザは、障害通知情報を有し、障害通知情報は、ＬＰＡＲの実行に影響しないハードウェア障害について、ＬＰＡＲ毎の障害通知の要求有無及びフェイルオーバー後におけるＬＰＡＲの停止の可否を管理する。ハードウェア障害が発生すると、ハイパバイザは、障害通知情報を参照し、ハードウェア障害通知の要求があるＬＰＡＲに対して、障害通知を送信し、複数のＬＰＡＲについて実行の継続可能なＬＰＡＲの有無を判定する。実行の継続が可能でないＬＰＡＲがある場合、ハイパザイザは、実行の継続が可能でないＬＰＡＲ１を停止し、ＬＰＡＲ１は、クラスタを構成するＬＰＡＲへフェイルオーバーされる。実行の継続が可能なＬＰＡＲがある場合、実行の継続が可能なＬＰＡＲ２は、クラスタを構成するＬＰＡＲへフェイルオーバーされる。障害通知を受信したＬＰＡＲが有するクラスタ制御部は、ＬＰＡＲのフェイルオーバーが完了すると、障害通知情報におけるフェイルオーバー後におけるＬＰＡＲの停止の可否を、可に設定する。
【発明の効果】
【００１６】
本発明によれば、フェイルオーバー後におけるＬＰＡＲの停止の可否が障害通知情報に記録されるので、部分的なハードウェア障害発生後の保守時に、計算機が保守作業を実施可能な状態にあるかを、作業員が容易に判断可能となる。
【００１７】
また、実行継続可能なハードウェア障害の通知を受けたＬＰＡＲがそれに応じた障害対応処理を実行したことを通知するためのインタフェイスをハイパバイザが提供し、ＬＰＡＲの障害対応処理の通知状況をハイパバイザが保持し、その通知状況を取得するためのインタフェイスをハイパバイザが提供するので、これらのインタフェイスを通じて、ＬＰＡＲごとの実行継続可能なハードウェア障害への対応状況を登録・取得可能とし、計算機全体での対応状況を判定可能とする。
【図面の簡単な説明】
【００１８】
【図１】本発明の実施の形態での計算機の構成を示す図である。
【図２】本発明の実施の形態での計算機の構成を示す図である。
【図３】本発明の実施の形態での計算機システムの構成を示す図である。
【図４】本発明の実施の形態でのハイパバイザとクラスタ制御部の保持するデータの構造を示す図である。
【図５】本発明の実施の形態でのハイパバイザとＯＳのハードウェア障害処理手順を示すフローチャートである。
【図６】本発明の実施の形態でのクラスタ管理ミドル内のフェイルオーバー要求の監視手順を示すフローチャートである。
【図７】本発明の実施の形態でのデータ処理プログラムの処理手順を示すフローチャートである。
【図８】本発明の実施の形態でのクラスタ制御部のフェイルオーバー処理手順を示すフローチャートである。
【図９】本発明の実施の形態でのシステム構成を示す図である。
【図１０】本発明の実施の形態でのシステム管理画面を示す図である。
【図１１】フェイルオーバー要求テーブルの構造を示す図である。
【図１２】障害通知テーブルの状態を示す図である。
【発明を実施するための形態】
【００１９】
＜実施例１＞
本発明を適用した計算機システムについて、図面により説明する。
【００２０】
図３は、本発明の実施の形態の計算機システムの構成を示す図である。計算機１００と計算機２００で実行するＬＰＡＲ２１０と３１０、２６０と３６０がクラスタを構成している。計算機１００は計算機Ａ、計算機２００は計算機Ｂとして区別されているとする。計算機１００内では、ＬＰＡＲ２１０はＬＰＡＲ名がＬＰＡＲ１、２６０がＬＰＡＲ名がＬＰＡＲ２として区別されるとする。計算機２００内でもＬＰＡＲ３１０がＬＰＡＲ３、ＬＰＡＲ３６０がＬＰＡＲ４と名前付けされているとする。また、ＬＰＡＲ２１０とＬＰＡＲ２６０がクラスタの主系で、ＬＰＡＲ３１０と３６０がクラスタの従系であるとする。
【００２１】
計算機１００では、ハイパバイザ２５０（図３には記載していない）によってＬＰＡＲ２１０と２６０が構成され実行している。ハイパバイザ２５０は、計算機１００内のＣＰＵで実行するソフトウェアか、計算機１００内のハードウェアとして実現される。図３では、ハイパバイザ２５０が、ＬＰＡＲ２１０に論理的なＮＩＣ３９２と３９３、ＬＰＡＲ２６０にＮＩＣ３９４と３９５を割り当てていることを示している。他のＬＰＡＲも同様に論理的なＮＩＣを割り当てられている。
【００２２】
クラスタを構成するＬＰＡＲ２１０とＬＰＡＲ３１０を例に、ソフトウェア構成を説明する。ＬＰＡＲ２１０では、ＯＳ２３０、クラスタ制御部２２０、データ処理プログラム２１１が実行している。ＬＰＡＲ３１０も同様である。ＬＰＡＲ２１０のクラスタ制御部２２０とＬＰＡＲ３１０のクラスタ制御部３２０は、ネットワーク３９０を介して相互に稼働状況を監視している。クラスタ制御部２２０と３２０の制御下で、主系として実行しているＬＰＡＲでデータ処理プログラムが実行する。例えば、ＬＰＡＲ２１０が主系であれば、データ処理プログラム２１１が実際的な処理を実行する。
【００２３】
ＬＰＡＲ２１０が障害により実行を停止した場合は、ＬＰＡＲ３１０のクラスタ制御部３２０がＬＰＡＲ２１０の異常を検知し、フェイルオーバー処理を実行して、データ処理プログラム３１１の実行を開始する（以降、ＬＰＡＲ２１０は従系となる）。データ処理プログラム２１１と３１１は、ネットワーク３９１を経由して処理要求と結果を送受信する。
【００２４】
ここでデータ処理プログラムの実行を開始するとして説明したが、クラスタの構成によっては、従系でもデータ処理が実行しているが、実際的な出力を実施していない場合もある。この場合、クラスタ制御部は、フェイルオーバーでは、データ処理プログラム３１１が実際的な出力を開始するように制御する。
【００２５】
ＬＰＡＲ２６０とＬＰＡＲ３６０も同様なクラスタを構成しているとする。また、図３には記載していないが、主記憶装置、ＣＰＵ、データ処理プログラムの実行に必要な記憶装置などの資源も論理的分割され、各ＬＰＡＲに割り当てられているものとする。
【００２６】
図１は、本発明の実施でのクラスタを構成する計算機１００の構造を示している。計算機１００の構成として示すが、他の計算機も同様の構成である。計算機１００は、ＣＰＵ１０１ないし１０４、主記憶装置１２０、Ｉ／Ｏバス管理装置１３０が、バス１１０を介して接続している。Ｉ／Ｏバス管理装置１３０が接続するＩ／Ｏバス１４０には、ディスプレイやキーボードなどの入出力装置１５０、外部記憶装置に接続するためのＨＢＡ（Host Bus Adapter）１６１ないし１６３、ネットワークに接続するためのＮＩＣ（Network Interface Adapter）１７１ないし１７３が接続している。この例では、それぞれ３個ずつのアダプタを掲載したが３個に限定するものではなく、システムを構成するのに必要な個数だけアダプタは搭載される。
【００２７】
ＣＰＵ１０１ないし１０４は、主記憶装置１２０にプログラムを読み込み、主記憶装置１２０に読み込まれたプログラムを実行して、様々の処理を実行する。以降の説明では、これをプログラムや処理が実行すると記載する。
【００２８】
計算機１００内の各コンポーネントは、異常検知の機能を有しているとする。例えば、ＣＰＵ１０１ないし１０４は、内部キャッシュの一部の故障、内部のコアの故障、内部のレジスタの故障などを検知できるとする。ＣＰＵ１０１ないしＣＰＵ１０４は、このような内部の障害を検知するとマシンチェック割り込みを生成して、ソフトウェアに異常を通報する。
【００２９】
主記憶装置１２０、Ｉ／Ｏバス管理装置１３０、ＨＢＡ１６１ないしＨＢＡ１６３、ＮＩＣ１７１ないし１７３も、同様の機能を有しているとする。主記憶装置１２０の障害の場合、主記憶装置１２０を管理する装置を経由して、ＣＰＵ１０１ないし１０４の何れか、あるいは、すべてにマシンチェック割り込みを送信する。ＨＢＡ１６１ないし１６３、ＮＩＣ１７１ないし１７３が異常を検知した場合、Ｉ／Ｏバス管理装置１３０がマシンチェック割り込みを送信する。
【００３０】
図２は、本発明の実施の形態の、計算機内のソフトウェアの構成を示す図である。計算機１００を例に説明する。計算機１００は、ハイパバイザ２５０を実行している。ハイパバイザ２５０は、計算機１００の資源を論理的に分割し、ＬＰＡＲ２１０とＬＰＡＲ２６０を実行している。分割される資源は、ＣＰＵ１０１ないし１０４、主記憶装置１２０、ＨＢＡ１６１ないし１６３、ＮＩＣ１７１ないし１７３である。それぞれのＬＰＡＲ２１０と２６０は、ハイパバイザ２５０が提供する資源を利用して実行している。ハイパバイザ２５０は、計算機１００を構成するコンポーネントからのマシンチェック割り込みを処理するマシンチェック割り込み処理部２５１、障害通知テーブル２５２を有している。
【００３１】
障害通知テーブル２５２の構成を図４に示す。テーブル２５２は、ハイパバイザ２５０の上で実行する各ＬＰＡＲについて、ＬＰＡＲ番号４０１、当該ＬＰＡＲに影響しないハードウェア障害の通知を要求しているかを示すフラグ（障害通知要否フラグ４０２）、過去のハードウェア障害の有無（障害通知フラグ４０３）、ハードウェア障害の通知後に当該ＬＰＡＲで障害に対応する処理が実行されて、当該ＬＰＡＲを停止してよい状態となっているかを示すフラグ（停止可否フラグ４０４）を保持する。
【００３２】
ハイパバイザ２５０は、障害通知要否フラグ４０２、停止可否フラグ４０４を設定するインタフェイスを、ＯＳ２３０から利用可能なようにＬＰＡＲ２１０に提供する。ハイパバイザ２５０は、ＬＰＡＲ開始時にテーブル２５２の当該ＬＰＡＲ用のエントリを割り当て、障害通知要否フラグ４０２に否、障害通知フラグに否、停止可否フラグに否を示す値を設定する。この時のテーブル内容を図４の４１０に示す。
【００３３】
ＬＰＡＲ内の構成について、ＬＰＡＲ２１０を例に説明する。ＬＰＡＲ２１０では、ＯＳ２３０が実行している。ＯＳ２３０には、ハイパバイザが送信した論理的なマシンチェック割り込みを処理するマシンチェック割り込み処理部２３１がある。ＯＳ２３０は、マシンチェック割り込みが発生したことを、ＯＳ２３０で実行するプログラムに通知するインタフェイスを有する。プログラムは、そのインタフェイスを介して、マシンチェック割り込み発生の通知を受信できるものとする。
【００３４】
ＬＰＡＲ２１０は、ＬＰＡＲ３１０とクラスタを構成している。ＬＰＡＲ２１０は、ＯＳ２３０を実行している。ＯＳ２３０上では、クラスタ制御部２２０が実行している。クラスタ制御部２２０は、主系と従系の間の相互監視や、フェイルオーバー処理を実行する。クラスタ制御部２２０は、ＯＳ２３０からハードウェア障害が発生している旨の通知を受け付ける障害通知受付部２２２、フェイルオーバー要求を管理するフェイルオーバー要求テーブル２２３、フェイルオーバー処理を実施するフェイルオーバー処理部２２４、フェイルオーバー処理をスケジュールする要求監視部２２５、クラスタで実行するデータ処理プログラム２１１にクラスタ状態等の情報提供や、フェイルオーバー操作インタフェイスを提供するクラスタ制御インタフェイス２２１を有している。
【００３５】
クラスタ制御部２２０は、クラスタ構成を開始する際に、ハイパバイザ２５０が提供するインタフェイスを通じて、当該ＬＰＡＲにハードウェア障害を通知するように、障害通知要否フラグ４０２を「要」に、停止可否フラグ４０４を「否」に設定する。ＬＰＡＲ２６０のクラスタ制御部２７０も実行している時点の障害通知テーブル２５２の状態を図４の４２０に示す。
【００３６】
従系となるＬＰＡＲ３１０のクラスタ制御部３２０は、停止可否フラグ４０４を「可」に設定する。停止可否フラグの設定は、データ処理プログラムを実行している主系の側は停止させてはいけないが、従系の側は停止してもよいことを示す設定である。ＬＰＡＲ３６０のクラスタ制御部３７０も実行している時点の障害通知テーブル２５２の状態を図４の４３０に示す。ここでは、ＬＰＡＲ３とＬＰＡＲ４が従系となっている様子を示している。
【００３７】
クラスタ制御部２２０と３２０は、その制御下で実行するＬＰＡＲの運転モードが従系から主系に遷移する際には、障害通知テーブル２５２の停止可否フラグ４０４を「可」から「否」に、逆の遷移をする場合には「否」から「可」に設定する。
【００３８】
クラスタ制御部２２０のフェイルオーバー要求テーブル２２３の構造を図１１に示す。テーブル２２３は、フェイルオーバー実施の要求を受けているか（要求フラグ１１１０）、未処理のフェイルオーバー要求があるか（未完要求フラグ１１１１）を示す値を保持している。クラスタ制御インタフェイス２２１を通じて、データ処理プログラム２１１や他のプログラムは、これらのフラグを設定可能である。また、フェイルオーバー処理部２２４、要求監視部２２５もこれらのフラグを操作する。
【００３９】
データ処理プログラム２１１は、クラスタ上で実行するアプリケーションである。ＬＰＡＲ２１０が主系である時に障害で実行を停止すると、このプログラム２１１の処理が計算機２００のＬＰＡＲ３１０で引き継がれる。この際、処理を引き継いだＬＰＡＲ３１０が主系となるように、クラスタ制御部３２０が制御を行う。
【００４０】
もう一方のＬＰＡＲ２６０も同様の構成である（図は省略）。データ処理プログラム２６１は、ＬＰＡＲ２１０で実行するプログラム２１１とは、独立に実行するプログラムであってよい。また、計算機２００のＬＰＡＲ３１０と３６０の構成も同様である。
【００４１】
図３のシステムで、計算機１００にハードウェア障害が発生したものとして、本実施の形態でのハードウェア障害処理方法を説明する。ここでは、計算機１００で実行するＬＰＡＲ２１０と２６０が主系、計算機２００で実行するＬＰＡＲ３１０と３６０が従系であるとして説明する。以下、ＬＰＡＲ２１０での動作について説明するが、他のＬＰＡＲでも同様の動作を実行する。
【００４２】
まず、クラスタ制御部２２０の動作について説明する。クラスタ開始時に、クラスタを構成する各ＬＰＡＲのクラスタ制御部は、ハードウェア障害の発生を示すマシンチェック割り込みを通知するよう、ＯＳに登録する。ＬＰＡＲ２１０であれば、クラスタ制御部２２０はＯＳ２３０にマシンチェック割り込みの通知を要求する（フロー省略）。
【００４３】
ＬＰＡＲ２１０の稼働中、クラスタ制御部２２０は、一般的なクラスタと同様に、サービスを提供するデータ処理プログラム２１１の実行を制御し、クラスタを構成する計算機を相互に監視している。例の構成であれば、ＬＰＡＲ３１０で実行するクラスタ制御部３２０と相互に通信して、稼働状況を監視している。従系側のクラスタ制御部３２０が主系の異常を検知すると、クラスタ制御部３２０の制御によりフェイルオーバーが実行されて、ＬＰＡＲ３１０が主系になる。
【００４４】
クラスタ制御部２２０は、ＯＳ２３０やデータ処理プログラム２１１からのクラスタ制御要求も待機している。
【００４５】
次に、ハードウェア障害発生時の動作について説明する。ここで説明するのは、障害が部分的な障害であり、影響を受けるＬＰＡＲのみ停止すれば、他のＬＰＡＲは継続して実行可能である場合についてである。すべてのＬＰＡＲに影響を及ぼすハードウェア障害の場合は、全ＬＰＡＲの実行を停止し、クラスタを構成している全ＬＰＡＲがフェイルオーバーすることになる。ここでは、ＬＰＡＲ２６０が実行継続不可となるハードウェア障害が発生したとして説明する。
【００４６】
図５に、部分的なハードウェア障害発生時のハイパバイザのマシンチェック割り込み処理部２５１と、ＯＳ２３０のマシンチェック割り込み処理部２３１の処理フローを示す。
【００４７】
計算機１００でハードウェア障害が発生すると、障害を起こしたコンポーネントはＣＰＵ１０１ないしＣＰＵ１０４にマシンチェック割り込みを送信する。割り込みを捕獲したＣＰＵは、ハイパバイザ２５０のマシンチェック割り込み処理部２５１を実行する。マシンチェック割り込み処理部２５１は、割り込みの内容から障害部位を特定し（ステップ５０１）、そのハードウェア障害の影響で実行が不可能となるＬＰＡＲを特定する（ステップ５０２）。
【００４８】
マシンチェック割り込み処理部２５１は、実行が不可能なＬＰＡＲに、実行継続不可を示すマシンチェック(Uncorrectable Machine Check)を送信し、当該ＬＰＡＲの実行を停止させる（ステップ５０３）。この時、クラスタ制御部２２０は、障害通知テーブル２５２の障害通知フラグを「あり」に、停止可否フラグを「可」に変更する。
【００４９】
この例では、ハイパバイザからＬＰＡＲ２６０に、実行継続不可マシンチェック割り込みを送信する。ＬＰＡＲ２６０で実行するＯＳ２８０のマシンチェック割り込み処理部２８１が、ハイパバイザのマシンチェック割り込み処理部２５１から送信された割り込みを捕獲し、ＯＳ２８０の実行を停止する。
【００５０】
ＯＳ２８０の実行が停止すると、クラスタを構成する計算機２００のＬＰＡＲ３６０のクラスタ制御部３７０が、ＯＳ２８０の実行の停止を検知して、フェイルオーバーを実行する。この結果、ＬＰＡＲ３６０が主系となり、データ処理プログラム３６１が実行を開始する。この時、前述したとおり、クラスタ制御部３７０は、障害通知テーブル２５２のＬＰＡＲ３６０（ＬＰＡＲ４）の停止可否フラグ４０４を「否」に設定している。この時の計算機２００の障害通知テーブル２５２の様子を、図１２の４４０に示す。
【００５１】
次に、マシンチェック割り込み処理部２５１は、障害通知テーブル２５２の障害通知要否フラグ４０２を参照して、障害通知を要求しているＬＰＡＲについて、障害通知フラグ
４０３を「あり」に、停止可否フラグ４０４を「否」に設定し、実行継続可能であるがハードウェア障害が発生している旨を通知するマシンチェック(Correctable Machine Check)を送信する（ステップ５０４）。
【００５２】
図４の４２０に示す通り、ＬＰＡＲ１に対応するＬＰＡＲ２１０が通知を要求しており、マシンチェック割り込み処理部２５１は、ＬＰＡＲ２１０に実行継続可能マシンチェックを送信する。また、割り込み処理部２５１は、マシンチェック送信前に、障害通知テーブル２５２のＬＰＡＲ２１０に対応する障害通知フラグ４０３を「あり」に、停止可否フラグ４０４を「否」に設定する。この時、ＬＰＡＲ２１０（ＬＰＡＲ１）の障害通知テーブル２５２は、障害通知フラグ４０３が「あり」、停止可否フラグ４０３が「否」となっている。この状態は、ＬＰＡＲ２１０がハードウェア障害通知を受信したが、それに対応してＬＰＡＲ２１０を停止するために必要な処理が完了していないことを示している。この時の計算機１００の障害通知テーブル２５２の様子を図１２の４５０に示す。
【００５３】
ＬＰＡＲ２６０の実行はすでに停止しているので、マシンチェックは送信しない。
【００５４】
マシンチェック割り込みを受けて、ＯＳ２３０のマシンチェック割り込み処理部２３１が起動し、以下に示す処理を実行する。
【００５５】
割り込み処理部２３１は、捕獲したマシンチェックが実行継続不可を示すマシンチェックかどうかを判定する（ステップ５１０）。
【００５６】
実行継続不可なマシンチェックである場合は、ＯＳ２３０の実行を停止する（ステップ５１３）。
【００５７】
実行継続可能なマシンチェックである場合は、障害発生を記録し（ステップ５１１）、障害通知を要求しているプログラムに障害内容を通知する（ステップ５１２）。
【００５８】
この例では、クラスタ制御部２２０がマシンチェック割り込みの通知を要求しているので、ＯＳ２３０は、クラスタ制御部２２０の障害通知受付部２２２を実行するようにスケジュールする。この例では、マシンチェックの通知を割り込み処理部２３１から通知するとしたが、マシンチェック割り込み処理部２３１の実行完了後に、通知処理が実行されてもよい。
【００５９】
マシンチェック割り込み処理終了後、障害通知受付部２２２が、ＯＳ２３０によってディスパッチされて実行する。障害通知受付部２２２は、クラスタ制御部２２０のフェイルオーバー要求テーブル２２３の要求フラグ１１１０を「あり」、未完要求フラグ１１１１を「あり」を示す値に設定する（処理フローなし）。
【００６０】
クラスタ制御部２２０の要求監視部２２５は、定期的にフェイルオーバー要求テーブル２２３をチェックする処理を実行している。図６に処理フローを示す。要求管理部２２５は、フェイルオーバー要求テーブル２２３の未完要求フラグ１１１１を検査し、要求があったがフェイルオーバーが完了していないかどうかを判定する（ステップ６０１）。
【００６１】
そうである場合、テーブル２２３の要求フラグ１１１０を「あり」に再設定する（ステップ６０２）。
【００６２】
要求管理部２２５は、これらの処理ののち、あらかじめ決められた時間待機して（ステップ６０３）、ステップ６０１からチェック処理を繰り返す。
【００６３】
これによって、一定時間ごとに未完了のフェイルオーバー要求を再発行し、最初のフェイルオーバー要求の時点でフェイルオーバーができない状態であっても、将来のある時点でフェイルオーバー処理が再実行されるようにする。なお、一定時間とは、実行している業務に応じてユーザが設定するものであり、例えば３０秒毎としてもよい。
【００６４】
次に、データ処理プログラム２１１の処理内容を説明する。図７に、データ処理プログラム２１１の処理フローを示す。データ処理プログラム２１１は、基本的には、ネットワーク経由で送信される処理要求を受け付け、それに対応するデータ処理を実施することを繰り返しているものとする。
【００６５】
データ処理プログラム２１１は、処理要求を待機している（ステップ７０１）。データ処理プログラム２１１は、あらかじめ決められた時間でタイムアウトするように待機している。処理要求が到着するかタイムアウトによって、ステップ７０１は完了する。
【００６６】
データ処理プログラム２１１は、クラスタ制御インタフェイス２２１を介してクラスタ制御部２２０にフェイルオーバー要求があるかを問い合わせる（ステップ７０２）。クラスタ制御部２２０は、フェイルオーバー要求テーブル２２３の要求フラグ１１１０の値を返す。
【００６７】
ステップ７０２でフェイルオーバー要求がないと判定された場合、要求されたデータ処理を実行する（ステップ７０３）。ただし、タイムアウトでステップ７０１を完了している場合は、何もしない。
【００６８】
処理完了後、データ処理プログラム２１１は、再び処理要求の到着を待つ（ステップ７０１）。
【００６９】
ステップ７０２でフェイルオーバー要求があると判定された場合、データ処理プログラム２１１は、クラスタ制御部２２０にフェイルオーバーを要求する（ステップ７１０）。
【００７０】
要求後、データ処理プログラム２１１は、フェイルオーバー処理の完了を待ち、フェイルオーバーの実行状況をクラスタ制御部２２０から取得し、フェイルオーバーが成功したかどうかを判定する（ステップ７１１）。
【００７１】
フェイルオーバーが成功した場合は、データ処理プログラム２１１は実行を停止する。失敗した場合は、データ処理プログラム２１１は、再び処理要求の到着を待機する（ステップ７０１）。
【００７２】
フェイルオーバーが失敗した場合は、要求監視部２２５の処理によって、将来のある時点でフェイルオーバーが再度要求される。フェイルオーバーが成功した時点でデータ処理プログラム２１１の処理が強制的に停止する処理であってもよい。この場合、フェイオーバー失敗の場合のみデータ処理プログラム２１１の処理が継続することになる。
【００７３】
図８にクラスタ制御部２２０のフェイルオーバー処理部２２４の処理フローを示す。
【００７４】
フェイルオーバー処理部２２４は、データ処理プログラム２１１の要求を受けてフェイルオーバー処理を実行する（ステップ８０１）。フェイルオーバーが完了すると、計算機３００のＬＰＡＲ３１０が主系となり、データ処理プログラム３１１が要求を受け付け、データ処理を実行する。
【００７５】
フェイルオーバー処理部２２４は、フェイルオーバーが成功したかどうかを判定する（ステップ８０２）。
【００７６】
フェイルオーバーが成功した場合には、フェイルオーバー要求テーブル２２３の未完要求フラグ１１１１を「なし」に、要求フラグ１１１０も「なし」に設定する（ステップ８０３）。
【００７７】
さらに、ハイパバイザ２５０内の障害通知テーブル２５２の停止可否フラグ４０４を「可」に設定する（ステップ８０４）。これは、ハイパバイザ２５０が提供するインタフェイスを介して実行する。これにより、障害通知テーブル２５２のＬＰＡＲ２１０のエントリは、障害通知フラグ４０３が「あり」、停止可否フラグ４０４が「可」になったことになる。これは、障害が通知されて、それに対応して停止する準備が整ったことを示している。この時の計算機１００の障害通知テーブル２５２の様子を図１２の４６０に示す。これに示される通り、計算機１００で実行しているＬＰＡＲ１とＬＰＡＲ２は停止可能であることが、障害通知テーブル２５２を参照することで容易に判別可能となる。また、計算機２００の障害通知テーブル２５２の様子を図１２の４７０に示す。ＬＰＡＲ３１０が主系になったことに伴い、ＬＰＡＲ３の停止可否フラグ４０４が「否」となっている様子を示している。
【００７８】
なお、フェイルオーバーが失敗した場合には、主系での実行が継続する。後の時点で、フェイルオーバーが再度要求される。
【００７９】
以上の実施の形態により、計算機１００でハードウェア障害が発生した際に、その障害とは無関係、即ち障害の発生していないハード上のクラスタ構成をとるＬＰＡＲに自動的にフェイルオーバーし、その結果ＬＰＡＲ２１０が従系となるため、将来の保守作業に備えて、障害が発生したハードウェアの実行を停止する作業を、作業者が実施可能となる。
【００８０】
本発明では、障害通知要求フラグ４０２と停止可否フラグ４０４を管理する障害通知テーブル２５２ハイパバイザ２５０内に設け、これらを更新するインタフェイスをハイパバイザ２５０が提供している。これによって、ハイパイザ２５０は、部分障害発生時に継続実行が可能なＬＰＡＲに障害発生を通知し、将来の停止に向けた処理を実行させることが可能となっている。また、ＬＰＡＲで実行するプログラム（実施例ではクラスタ制御部２２０）が、自身の実行とは直接関係のない部分障害の通知を受けて、将来の保守時のシステムの停止に向けた処理を実行することができる（実施例ではフェイルオーバーを実施）。これによって、障害通知を受けたＬＰＡＲは、将来の保守に備えて実行するための準備を実行し、加えて、準備完了したことをハイパバイザ２５０に通知できる。通常のシステムでは、ＬＰＡＲを停止可能であるかどうかを確認する方法は実行されている業務に依存するため、個別に確認しなければならない。本発明によれば、ハイパバイザ２５０は、計算機１００全体を停止可能かどうかを判断するための情報を、実行する業務に関係なく保持できるため、保守に関わる作業員は容易に計算機を停止可能かどうか判断可能となる。
【００８１】
また、本実施の形態のようにクラスタ制御と組み合わせることにより、ハードウェア障害発生から保守の時点までのいずれかの時点で、安全に系切り替えを実行して、保守作業に備えることが可能である。ハードウェア障害の通知を外部から監視して系切り替えを起動することも可能であるが、ハイパバイザがクラスタ制御に系切り替えの契機を与えることにより、ハードウェア障害の発生を外部から監視するためのシステム構成が不要となる。このような監視のシステムは、ハードウェア障害を見落とさないために二重化するといった構成が必要になるが、これらが不要となり、システム構成が簡便、かつ、高信頼となる。
【００８２】
また、系切り替え等の作業を自動で実施することにより、保守の時点で必要となる手動の作業が削減され、
本発明では、クラスタ制御と組み合わせたが、クラスタ制御に限定するものではない。マシンチェック割り込みの通知を受けて、ハイパバイザ２５０の障害通知テーブル２５２を更新するプログラムが実行していれば、将来の停止に向けた処理を実行することが可能である。
【００８３】
＜実施例２＞
次に、本発明を適用した第二の計算機システムについて説明する。図９は、本発明の第二の実施の形態のシステム構成図である。
【００８４】
第二の実施の形態では、第一の実施の形態でのシステム構成に加えて、計算機１００と計算機２００の稼働状態を監視する計算機９００が追加されている。計算機１００と計算機２００は、ＮＩＣ９３１と９３２が搭載されており、ネットワーク９２０を介して計算機９００と接続している。このネットワーク９２０を介して、ハイパバイザ２５０のインタフェイスを参照可能で、障害通知テーブル２５２の内容を取得可能であるとする。
【００８５】
計算機９００は、図１に示したのと同様の構成の計算機である。計算機９００では、障害状況表示部９１０が実行している。障害状況表示部９１０は、管理対象の計算機から情報を取得して表示する。ここでは、計算機１００と計算機２００が管理対象として登録されているとする。特に、計算機１００と計算機２００のハイパバイザから、障害通知テーブル２５２の状態を取得して表示する。これによって、実行継続可能なハードウェア障害の発生の有無と、それに対応した停止準備処理が実行されたかを容易に判定できる。
【００８６】
図１０に障害状況の表示の例を示す。これは、第一の実施の形態で、ＬＰＡＲ２１０のフェイルオーバーが完了した後の状態を示している例である。この表示は、図１２に示した計算機１００の障害通知テーブル４６０、計算機２００の障害通知テーブル４７０に基づき構成される。この表示の内容の構成方法を以下に説明する。
【００８７】
図１０の表示を作成する障害状況表示部９１０は、計算機Ａに対応する計算機１００のＬＰＡＲ名１００１、稼働状況１００２をハイパバイザ２５２より取得する。これらの情報は、管理情報としてハイパバイザ２５２から取得可能であるとする。障害状況表示部９１０は、稼働中のＬＰＡＲについて、障害通知テーブル２５２の内容をハイパバイザより取得する。具体的には、障害状況表示部９１０は、障害通知１００３の内容を障害通知テーブル２５２の障害通知フラグ４０３より取得した値を、停止可否１００４の内容を障害通知テーブル２５２の停止可否フラグ４０４より取得した値を表示する。この例では、ＬＰＡＲ２６０（ＬＰＡＲ２）は停止しているため、ＬＰＡＲ２１０（ＬＰＡＲ１）の情報を取得して表示する。停止しているＬＰＡＲの情報は、ＬＰＡＲ名と稼働状況のみ表示し、他の情報は表示しない。
【００８８】
計算機Ｂに対応する計算機２００の情報も同様に取得して表示する。具体的には、ＬＰＡＲ３１０（ＬＰＡＲ３）、ＬＰＡＲ２６０（ＬＰＡＲ４）の情報を取得して、ＬＰＡＲ名１０１１、稼働状況１０１２、障害通知１０１３、停止可否１０１４を表示する。
【００８９】
図１２の障害管理テーブル４６０ではＬＰＡＲ１の障害通知フラグ４０３は「あり」、停止可否フラグ４０４は「可」となっているため、障害状況表示部９１０は、計算機１００の障害通知１００３は「あり」、停止可否１００４は「可」と表示する。計算機２００についても同様に、障害通知テーブル４７０の内容を取得して情報を表示する。
【００９０】
この例では、計算機Ａが計算機１００に、計算機Ｂが計算機２００に対応している。計算機ＡではＬＰＡＲ１が実行中であるが、障害通知を受け、停止可能な状態になっていること、ＬＰＡＲ２が実行を停止していることを表示している。また、計算機ＢではＬＰＡＲ３，４とも実行中であることを示している。
【００９１】
保守作業では、画面表示１０００を参照することにより、計算機ＡではＬＰＡＲ１が実行しているが停止可能であることが、この画面を通じて判断することができる。
【００９２】
以上により、ハードウェアの部分障害で実行を継続するＬＰＡＲがあっても、保守の時点で停止可能な状態になっているかを容易に判断することが可能となる。これは、ＬＰＡＲで実行するクラスタ制御部２２０のような管理ソフトウェアが、ハイパバイザが提供するインタフェイスによってハイパバイザ２５０と連携して、ハイパバイザ２５０内の障害通知テーブル２５２にＬＰＡＲの停止可否状態を設定可能となっていることによる。
【００９３】
一般に、ＬＰＡＲに搭載される業務システムは無関係のシステムであり、業務を停止可能かどうかは、その業務システムの管理者でなければ判断できない。本発明によれば、部分障害で継続実行しているＬＰＡＲに、保守作業に向けた停止準備を実行させ、その準備処理の状況を容易に確認することができる。これにより、故障部品の交換時に、計算機を停止する作業が容易になる。
【００９４】
本実施の形態では、データ処理プログラム２１１とクラスタ制御部２２０が連携してフェイルオーバーを実行したが、クラスタ制御部２２０が単独でフェイルオーバーを起動してもよい。
【００９５】
これまでの実施の形態では、データ処理プログラム２１１にクラスタのフェイルオーバーの実行タイミングを判断させていたが、ハイパバイザがＬＰＡＲの動作状況を監視して、クラスタ制御部２２０にフェイルオーバーを起動させることでもよい。例えば、ＬＰＡＲのアイドル状態の検知、Ｉ／Ｏ状態の監視により、処理の切れ目を判定してフェイルオーバーを実行してもよい。
【００９６】
以上の実施の形態では、論理分割を前提として説明したが、仮想化機構が部分障害に対応した機能を持っている場合は、それを前提としてもよい。
【符号の説明】
【００９７】
１００…計算機、１０１ないし１０４…ＣＰＵ、１１０…バス、１２０…主記憶装置、１３０…Ｉ／Ｏバス制御装置、１４０…Ｉ／Ｏバス、１５０…入出力装置、１６１ないし１６３…ＨＢＡ、１７１ないし１７３ＮＩＣ、２００…計算機、２１０…ＬＰＡＲ、２１１…データ処理プログラム、２１２…クラスタ制御連携部、２２０…クラスタ制御部、２２１…クラスタ制御インタフェイス、２２２…障害通知受付部、２２３…フェイルオーバー要求テーブル、２２４…フェイルオーバー処理部、２２５…要求監視部、２３０…ＯＳ，２３１…マシンチェック割り込み処理部、２５０…ハイパバイザ、２５１…マシンチェック割り込み処理部、２５２…障害通知テーブル、２６０…ＬＰＡＲ、２６１…データ処理プログラム、２７０…クラスタ制御部、２８０…ＯＳ、３１０…ＬＰＡＲ、３１１…データ処理プログラム、３２０…クラスタ制御部、３３０…ＯＳ、３６０…ＬＰＡＲ、３６１…データ処理プログラム、３７０…クラスタ制御部、３８０…ＯＳ、３９０ないし３９１…ネットワーク、３９２ないし３９９…ＮＩＣ、４０１ないし４０４…障害通知テーブル２５２内のデータ、４１０ないし４７０…障害通知テーブルの状態例、５０１ないし５１３…処理ステップ、６０１ないし６０３…処理ステップ、７０１ないし７１１…処理ステップ、８０１ないし８０４…処理ステップ、９００…計算機、９１０…障害状況処理部、９２０…ネットワーク、９３１ないし９３２…ＮＩＣ、１０００…画面表示例、１００１ないし１０１４…画面表示内容、１１１０ないし１１１１…フェイルオーバー要求テーブル２２３内のデータ
【特許請求の範囲】
【請求項１】
クラスタを構成する第一の物理計算機及び第二の物理計算機上に、ハイパバイザの制御により複数のＬＰＡＲが生成された仮想計算機システムにおけるハードウェア障害処理方法であって、
前記第一の物理計算機でハードウェア障害が発生すると、
前記第一の物理計算機が有する第一のハイパバイザは、前記第一の物理計算機上に生成されたＬＰＡＲについて実行の継続可能なＬＰＡＲの有無を判定し、
実行の継続が可能でないＬＰＡＲがある場合、
前記第一のハイパザイザは、実行の継続が可能でない第一のＬＰＡＲを停止し、
前記第一のＬＰＡＲとクラスタを構成する前記第二の物理計算機上に生成された第二のＬＰＡＲが有するクラスタ制御部は、前記第一のＬＰＡＲの業務を前記第二のＬＰＡＲへフェイルオーバーする第一のフェイルオーバーを行い、
実行の継続が可能なＬＰＡＲがある場合、
実行の継続が可能な第三のＬＰＡＲとクラスタを構成する前記第二の物理計算機上に生成された第四のＬＰＡＲが有するクラスタ制御部は、前記第三のＬＰＡＲの業務を前記第四のＬＰＡＲへフェイルオーバーする第二のフェイルオーバーを行うことを特徴とするハードウェア障害処理方法。
【請求項２】
前記ハイパバイザは、障害通知情報を有し、
前記障害通知情報は、前記ＬＰＡＲの実行に影響しないハードウェア障害について、ＬＰＡＲ毎の障害通知の要求有無及びフェイルオーバー後における前記ＬＰＡＲの停止の可否を管理し
前記第一のハイパバイザは、前記第一のハイパザイザが有する障害通知情報を参照し、前記実行の継続が可能な第三のＬＰＡＲにおけるハードウェア障害通知の要求がある場合、前記第三のＬＰＡＲに前記障害通知を送信し、
前記障害通知を受信した前記第三のＬＰＡＲが有するクラスタ制御部は、前記第二のフェイルオーバーの状況を管理するフェイルオーバー要求情報を有し、前記フェイルオーバ要求情報に前記第二のフェイルオーバーの要求ありを設定することを特徴とする請求項１記載のハードウェア障害処理方法。
【請求項３】
前記第三のＬＰＡＲが有するクラスタ制御部は、
前記フェイルオーバー要求情報を参照し、前記フェイルオーバー要求がある場合、前記第二のフェイルオーバーを行い、
前記第二のフェイルオーバーが完了すると、前記第一のハイパバイザが有する障害通知情報に対し、前記第二のフェイルオーバー後における前記第三のＬＰＡＲの停止の可否を、可に設定することを特徴とする請求項２記載のハードウェア障害処理方法。
【請求項４】
前記仮想計算機システムは、障害状況表示部を有し、
前記障害状況表示部は、前記システムに存在するＬＰＡＲ毎に、稼動状況及び停止可否を表示し、
前記障害状況表示部で表示される停止可否は、前記障害通知情報が管理するフェイルオーバー後における前記ＬＰＡＲの停止の可否に基づくことを特徴とする請求項３記載のハードウェア障害処理方法。
【請求項５】
前記第三のＬＰＡＲのクラスタ制御部は、前記フェイルオーバー要求情報の参照を、所定の時間毎に行うことを特徴とする請求項３記載のハードウェア障害処理方法。
【請求項６】
前記第一の物理計算機及び第二の物理計算機のハイパバイザは、
ＬＰＡＲが実行継続可能なハードウェア障害の通知を要求することを登録するインタフェイスを有し、
前記インタフェイスでの登録状況に合わせて、通知を要求したＬＰＡＲに実行継続可能なハードウェア障害を通知することを特徴とする請求項１記載のハードウェア障害処理方法。
【請求項７】
前記第一のハイパバイザ及び前記第二の物理計算機が有する第二のハイパバイザは、
前記第三のＬＰＡＲが第二のフェイルオーバーを実行したことを通知するためのインタフェイスを有し、
ＬＰＡＲの障害対応処理の通知状況を前記第一ハイパバイザ、前記第二のハイパザイザのうち少なくとも一方が保持し、
その通知状況を取得するためのインタフェイスを前記第一ハイパバイザ、前記第二のハイパザイザのうち少なくとも一方が有することを特徴とする請求項１記載のハードウェア障害処理方法。
【請求項８】
前記第一ハイパバイザ、前記第二のハイパザイザのうち少なくとも一方の保持する障害対応状況を取得して表示する手順と装置を備えていることを特徴とする請求項７記載のハードウェア障害処理方法。
【請求項９】
前記第一ハイパバイザ、前記第二のハイパザイザのうち少なくとも一方からの継続実行可能なハードウェア障害通知を受けて系切り替えを実行する手順と、
系切り替え完了後に障害対応処理を実行した旨を、前記第一ハイパバイザ、前記第二のハイパザイザのうち少なくとも一方のインタフェイスで通知する手順とを有し、
系切り替えの完了状況を、前記第一ハイパバイザ、前記第二のハイパザイザのうち少なくとも一方より取得できることを特徴とする請求項７記載のハードウェア障害処理方法。
【請求項１０】
クラスタを構成する第一の物理計算機及び第二の物理計算機上に、ハイパバイザの制御により複数のＬＰＡＲが生成された仮想計算機システムにおいて、
前記第一の物理計算機でハードウェア障害が発生すると、
前記第一の物理計算機が有する第一のハイパバイザは、前記第一の物理計算機上に生成されたＬＰＡＲについて実行の継続可能なＬＰＡＲの有無を判定し、
実行の継続が可能でないＬＰＡＲがある場合、
前記第一のハイパザイザは、実行の継続が可能でない第一のＬＰＡＲを停止し、
前記第一のＬＰＡＲとクラスタを構成する前記第二の物理計算機上に生成された第二のＬＰＡＲが有するクラスタ制御部は、前記第一のＬＰＡＲの業務を前記第二のＬＰＡＲへフェイルオーバーする第一のフェイルオーバーを行い、
実行の継続が可能なＬＰＡＲがある場合、
実行の継続が可能な第三のＬＰＡＲとクラスタを構成する前記第二の物理計算機上に生成された第四のＬＰＡＲが有するクラスタ制御部は、前記第三のＬＰＡＲの業務を前記第四のＬＰＡＲへフェイルオーバーする第二のフェイルオーバーを行うことを特徴とする仮想計算機システム。
【請求項１１】
前記ハイパバイザは、障害通知情報を有し、
前記障害通知情報は、前記ＬＰＡＲの実行に影響しないハードウェア障害について、ＬＰＡＲ毎の障害通知の要求有無及びフェイルオーバー後における前記ＬＰＡＲの停止の可否ｆを管理し
前記第一のハイパバイザは、前記第一のハイパザイザが有する障害通知情報を参照し、前記実行の継続が可能な第三のＬＰＡＲにおけるハードウェア障害通知の要求がある場合、前記第三のＬＰＡＲに前記障害通知を送信し、
前記障害通知を受信した前記第三のＬＰＡＲが有するクラスタ制御部は、前記第二のフェイルオーバーの状況を管理するフェイルオーバー要求情報を有し、前記フェイルオーバー要求情報に前記第二のフェイルオーバーの要求ありを設定することを特徴とする請求項１０記載の仮想計算機システム。
【請求項１２】
前記第三のＬＰＡＲが有するクラスタ制御部は、
前記フェイルオーバー要求情報を参照し、前記フェイルオーバー要求がある場合、前記第二のフェイルオーバーを行い、
前記第二のフェイルオーバーが完了すると、前記第一のハイパバイザが有する障害通知情報に対し、前記第二のフェイルオーバー後における前記第三のＬＰＡＲの停止の可否を、可に設定することを特徴とする請求項１１記載の仮想計算機システム。
【請求項１３】
前記仮想計算機システムは、障害状況表示装置を有し、
前記障害状況表示装置は、前記システムに存在するＬＰＡＲ毎に、稼動状況及び停止可否を表示し、
前記障害状況表示装置で表示される停止可否は、前記障害通知情報が管理するフェイルオーバ後における前記ＬＰＡＲの停止の可否に基づくことを特徴とする請求項１２記載の仮想計算機システム。
【請求項１４】
前記第三のＬＰＡＲのクラスタ制御部は、前記フェイルオーバー要求情報の参照を、所定の時間毎に行うことを特徴とする請求項１２記載の仮想計算機システム。
【請求項１５】
ハイパバイザの制御により複数のＬＰＡＲが生成され、クラスタを構成する物理計算機において、
前記ハイパバイザは、障害通知情報を有し、
前記障害通知情報は、前記ＬＰＡＲの実行に影響しないハードウェア障害について、ＬＰＡＲ毎の障害通知の要求有無及びフェイルオーバー後における前記ＬＰＡＲの停止の可否を管理し
ハードウェア障害が発生すると、前記ハイパバイザは、
前記障害通知情報を参照し、
ハードウェア障害通知の要求があるＬＰＡＲに対して、前記障害通知を送信し、
前記複数のＬＰＡＲについて実行の継続可能なＬＰＡＲの有無を判定し、
実行の継続が可能でないＬＰＡＲがある場合、
前記ハイパザイザは、実行の継続が可能でないＬＰＡＲ１を停止し、
前記ＬＰＡＲ１は、クラスタを構成するＬＰＡＲへフェイルオーバーされ、
実行の継続が可能なＬＰＡＲがある場合、
実行の継続が可能なＬＰＡＲ２は、クラスタを構成するＬＰＡＲへフェイルオーバーされ、
前記障害通知を受信したＬＰＡＲが有するクラスタ制御部は、前記ＬＰＡＲのフェイルオーバーが完了すると、前記障害通知情報におけるフェイルオーバー後におけるＬＰＡＲの停止の可否を、可に設定する)ことを特徴とする計算機。
【請求項１】
クラスタを構成する第一の物理計算機及び第二の物理計算機上に、ハイパバイザの制御により複数のＬＰＡＲが生成された仮想計算機システムにおけるハードウェア障害処理方法であって、
前記第一の物理計算機でハードウェア障害が発生すると、
前記第一の物理計算機が有する第一のハイパバイザは、前記第一の物理計算機上に生成されたＬＰＡＲについて実行の継続可能なＬＰＡＲの有無を判定し、
実行の継続が可能でないＬＰＡＲがある場合、
前記第一のハイパザイザは、実行の継続が可能でない第一のＬＰＡＲを停止し、
前記第一のＬＰＡＲとクラスタを構成する前記第二の物理計算機上に生成された第二のＬＰＡＲが有するクラスタ制御部は、前記第一のＬＰＡＲの業務を前記第二のＬＰＡＲへフェイルオーバーする第一のフェイルオーバーを行い、
実行の継続が可能なＬＰＡＲがある場合、
実行の継続が可能な第三のＬＰＡＲとクラスタを構成する前記第二の物理計算機上に生成された第四のＬＰＡＲが有するクラスタ制御部は、前記第三のＬＰＡＲの業務を前記第四のＬＰＡＲへフェイルオーバーする第二のフェイルオーバーを行うことを特徴とするハードウェア障害処理方法。
【請求項２】
前記ハイパバイザは、障害通知情報を有し、
前記障害通知情報は、前記ＬＰＡＲの実行に影響しないハードウェア障害について、ＬＰＡＲ毎の障害通知の要求有無及びフェイルオーバー後における前記ＬＰＡＲの停止の可否を管理し
前記第一のハイパバイザは、前記第一のハイパザイザが有する障害通知情報を参照し、前記実行の継続が可能な第三のＬＰＡＲにおけるハードウェア障害通知の要求がある場合、前記第三のＬＰＡＲに前記障害通知を送信し、
前記障害通知を受信した前記第三のＬＰＡＲが有するクラスタ制御部は、前記第二のフェイルオーバーの状況を管理するフェイルオーバー要求情報を有し、前記フェイルオーバ要求情報に前記第二のフェイルオーバーの要求ありを設定することを特徴とする請求項１記載のハードウェア障害処理方法。
【請求項３】
前記第三のＬＰＡＲが有するクラスタ制御部は、
前記フェイルオーバー要求情報を参照し、前記フェイルオーバー要求がある場合、前記第二のフェイルオーバーを行い、
前記第二のフェイルオーバーが完了すると、前記第一のハイパバイザが有する障害通知情報に対し、前記第二のフェイルオーバー後における前記第三のＬＰＡＲの停止の可否を、可に設定することを特徴とする請求項２記載のハードウェア障害処理方法。
【請求項４】
前記仮想計算機システムは、障害状況表示部を有し、
前記障害状況表示部は、前記システムに存在するＬＰＡＲ毎に、稼動状況及び停止可否を表示し、
前記障害状況表示部で表示される停止可否は、前記障害通知情報が管理するフェイルオーバー後における前記ＬＰＡＲの停止の可否に基づくことを特徴とする請求項３記載のハードウェア障害処理方法。
【請求項５】
前記第三のＬＰＡＲのクラスタ制御部は、前記フェイルオーバー要求情報の参照を、所定の時間毎に行うことを特徴とする請求項３記載のハードウェア障害処理方法。
【請求項６】
前記第一の物理計算機及び第二の物理計算機のハイパバイザは、
ＬＰＡＲが実行継続可能なハードウェア障害の通知を要求することを登録するインタフェイスを有し、
前記インタフェイスでの登録状況に合わせて、通知を要求したＬＰＡＲに実行継続可能なハードウェア障害を通知することを特徴とする請求項１記載のハードウェア障害処理方法。
【請求項７】
前記第一のハイパバイザ及び前記第二の物理計算機が有する第二のハイパバイザは、
前記第三のＬＰＡＲが第二のフェイルオーバーを実行したことを通知するためのインタフェイスを有し、
ＬＰＡＲの障害対応処理の通知状況を前記第一ハイパバイザ、前記第二のハイパザイザのうち少なくとも一方が保持し、
その通知状況を取得するためのインタフェイスを前記第一ハイパバイザ、前記第二のハイパザイザのうち少なくとも一方が有することを特徴とする請求項１記載のハードウェア障害処理方法。
【請求項８】
前記第一ハイパバイザ、前記第二のハイパザイザのうち少なくとも一方の保持する障害対応状況を取得して表示する手順と装置を備えていることを特徴とする請求項７記載のハードウェア障害処理方法。
【請求項９】
前記第一ハイパバイザ、前記第二のハイパザイザのうち少なくとも一方からの継続実行可能なハードウェア障害通知を受けて系切り替えを実行する手順と、
系切り替え完了後に障害対応処理を実行した旨を、前記第一ハイパバイザ、前記第二のハイパザイザのうち少なくとも一方のインタフェイスで通知する手順とを有し、
系切り替えの完了状況を、前記第一ハイパバイザ、前記第二のハイパザイザのうち少なくとも一方より取得できることを特徴とする請求項７記載のハードウェア障害処理方法。
【請求項１０】
クラスタを構成する第一の物理計算機及び第二の物理計算機上に、ハイパバイザの制御により複数のＬＰＡＲが生成された仮想計算機システムにおいて、
前記第一の物理計算機でハードウェア障害が発生すると、
前記第一の物理計算機が有する第一のハイパバイザは、前記第一の物理計算機上に生成されたＬＰＡＲについて実行の継続可能なＬＰＡＲの有無を判定し、
実行の継続が可能でないＬＰＡＲがある場合、
前記第一のハイパザイザは、実行の継続が可能でない第一のＬＰＡＲを停止し、
前記第一のＬＰＡＲとクラスタを構成する前記第二の物理計算機上に生成された第二のＬＰＡＲが有するクラスタ制御部は、前記第一のＬＰＡＲの業務を前記第二のＬＰＡＲへフェイルオーバーする第一のフェイルオーバーを行い、
実行の継続が可能なＬＰＡＲがある場合、
実行の継続が可能な第三のＬＰＡＲとクラスタを構成する前記第二の物理計算機上に生成された第四のＬＰＡＲが有するクラスタ制御部は、前記第三のＬＰＡＲの業務を前記第四のＬＰＡＲへフェイルオーバーする第二のフェイルオーバーを行うことを特徴とする仮想計算機システム。
【請求項１１】
前記ハイパバイザは、障害通知情報を有し、
前記障害通知情報は、前記ＬＰＡＲの実行に影響しないハードウェア障害について、ＬＰＡＲ毎の障害通知の要求有無及びフェイルオーバー後における前記ＬＰＡＲの停止の可否ｆを管理し
前記第一のハイパバイザは、前記第一のハイパザイザが有する障害通知情報を参照し、前記実行の継続が可能な第三のＬＰＡＲにおけるハードウェア障害通知の要求がある場合、前記第三のＬＰＡＲに前記障害通知を送信し、
前記障害通知を受信した前記第三のＬＰＡＲが有するクラスタ制御部は、前記第二のフェイルオーバーの状況を管理するフェイルオーバー要求情報を有し、前記フェイルオーバー要求情報に前記第二のフェイルオーバーの要求ありを設定することを特徴とする請求項１０記載の仮想計算機システム。
【請求項１２】
前記第三のＬＰＡＲが有するクラスタ制御部は、
前記フェイルオーバー要求情報を参照し、前記フェイルオーバー要求がある場合、前記第二のフェイルオーバーを行い、
前記第二のフェイルオーバーが完了すると、前記第一のハイパバイザが有する障害通知情報に対し、前記第二のフェイルオーバー後における前記第三のＬＰＡＲの停止の可否を、可に設定することを特徴とする請求項１１記載の仮想計算機システム。
【請求項１３】
前記仮想計算機システムは、障害状況表示装置を有し、
前記障害状況表示装置は、前記システムに存在するＬＰＡＲ毎に、稼動状況及び停止可否を表示し、
前記障害状況表示装置で表示される停止可否は、前記障害通知情報が管理するフェイルオーバ後における前記ＬＰＡＲの停止の可否に基づくことを特徴とする請求項１２記載の仮想計算機システム。
【請求項１４】
前記第三のＬＰＡＲのクラスタ制御部は、前記フェイルオーバー要求情報の参照を、所定の時間毎に行うことを特徴とする請求項１２記載の仮想計算機システム。
【請求項１５】
ハイパバイザの制御により複数のＬＰＡＲが生成され、クラスタを構成する物理計算機において、
前記ハイパバイザは、障害通知情報を有し、
前記障害通知情報は、前記ＬＰＡＲの実行に影響しないハードウェア障害について、ＬＰＡＲ毎の障害通知の要求有無及びフェイルオーバー後における前記ＬＰＡＲの停止の可否を管理し
ハードウェア障害が発生すると、前記ハイパバイザは、
前記障害通知情報を参照し、
ハードウェア障害通知の要求があるＬＰＡＲに対して、前記障害通知を送信し、
前記複数のＬＰＡＲについて実行の継続可能なＬＰＡＲの有無を判定し、
実行の継続が可能でないＬＰＡＲがある場合、
前記ハイパザイザは、実行の継続が可能でないＬＰＡＲ１を停止し、
前記ＬＰＡＲ１は、クラスタを構成するＬＰＡＲへフェイルオーバーされ、
実行の継続が可能なＬＰＡＲがある場合、
実行の継続が可能なＬＰＡＲ２は、クラスタを構成するＬＰＡＲへフェイルオーバーされ、
前記障害通知を受信したＬＰＡＲが有するクラスタ制御部は、前記ＬＰＡＲのフェイルオーバーが完了すると、前記障害通知情報におけるフェイルオーバー後におけるＬＰＡＲの停止の可否を、可に設定する)ことを特徴とする計算機。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２０１２−２３０４４４（Ｐ２０１２−２３０４４４Ａ）
【公開日】平成２４年１１月２２日（２０１２．１１．２２）
【国際特許分類】
【出願番号】特願２０１１−９６６８９（Ｐ２０１１−９６６８９）
【出願日】平成２３年４月２５日（２０１１．４．２５）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２４年１１月２２日（２０１２．１１．２２）
【国際特許分類】
【出願日】平成２３年４月２５日（２０１１．４．２５）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]