(57)【要約】【課題】１つの実行系ノードに対して１つの待機系ノードを必要とすることなく、かつ障害の要因に対応した計算機の系切り替え制御方式を提供する。【解決手段】ｎ個の実行系ノード２００に対して異なる特性(CPU性能、I/O性能、通信性能など)をもつｍ個の待機系ノード３００を用意しておく。ｍ個の待機系ノード３００は障害の要因ごとに切り替え対象とする優先度を予め登録しておく。１つの実行系ノード２００に障害が発生した場合、障害の要因を取り除ける待機系ノード３００をｍ個の待機系ノードの中から選択することで、データ処理を引き継ぐ。【選択図】図２
2007207219.tif 000002
【特許請求の範囲】
【請求項１】
業務を実行する複数の計算機を備えた第１の計算機システムと、複数の計算機を備えた第２の計算機システムと、を備えて、前記第１の計算機システムの計算機に障害が発生したときには、前記第２の計算機システムの計算機に第１の計算機システムの計算機で実行していた業務を引き継ぐ計算機システムの管理方法であって、
前記第１の計算機システムの計算機毎の稼働状態を示す稼動情報を収集する手順と、
前記稼動情報に基づいて、前記第１の計算機システムを構成する計算機に障害が発生したことを検知する手順と、
前記稼動情報に基づいて前記前記第１の計算機システムを構成する計算機に発生した障害の要因を検出する手順と、
前記第２の計算機システムを構成する計算機の性能に関する性能情報を取得する手順と、
前記第１の計算機システムに発生した障害の要因と、前記取得した第２の計算機システムの計算機の性能情報に基づいて、前記第２の計算機システムの中から前記障害を回復可能な計算機を選択する手順と、
前記選択した第２の計算機システムの計算機に、前記障害が発生した第１の計算機システムの計算機で実行していた業務を引き継ぐ手順と、
を含むことを特徴とする計算機システムの管理方法。
【請求項２】
前記第２の計算機システムを構成する計算機の数は、前記第１の計算機システムを構成する計算機の数よりも少ないことを特徴とする請求項１に記載の計算機システムの管理方法。
【請求項３】
前記第２の計算機システムは、性能の異なる計算機を含み、
前記障害を回復可能な計算機を選択する手順は、
前記障害の要因を回復可能な所定の性能を備えた計算機を選択することを特徴とする請求項１に記載の計算機システムの管理方法。
【請求項４】
前記第１の計算機システムを構成する計算機に障害が発生したことを検知する手順は、
前記第１の計算機システムの計算機の性能に関連する性能情報を取得する手順と、
前記性能情報と予め設定した値とを比較して、前記比較結果が予め設定した条件となったときに、障害が発生したことを判定する手順と、
前記性能情報の種類に基づいて前記障害の要因を判定する手順と、
を含むことを特徴とする請求項１に記載の計算機システムの管理方法。
【請求項５】
前記第１の計算機システムを構成する計算機は、
ストレージ装置に格納されたデータベースを複数の分割データベースに分割し、前記分割したデータベースに対して計算機を関連付けてデータ処理を前記業務として提供する手順を含むことを特徴とする請求項１に記載の計算機システムの管理方法。
【請求項６】
前記第１の計算機システムを構成する計算機に障害が発生したことを検知する手順は、  前記障害が発生した計算機のデータ処理を停止させる手順を含むことを特徴とする請求項５に記載の計算機システムの管理方法。
【請求項７】
前記第１の計算機システムと第２の計算機システムを管理する管理サーバを含み、
前記管理サーバが、前記障害が発生したことを検知する手順と、前記障害を回復可能な計算機を選択する手順と、前記障害が発生した第１の計算機システムの計算機から前記障害選択した第２の計算機システムの計算機に業務を引き継ぐ手順と、を実行することを特徴とする請求項１に記載の計算機システムの管理方法。
【請求項８】
前記第２の計算機システムを構成する計算機の内の一つが、前記障害が発生したことを検知する手順と、前記障害を回復可能な計算機を選択する手順と、前記障害が発生した第１の計算機システムの計算機から前記障害選択した第２の計算機システムの計算機に業務を引き継ぐ手順と、を実行することを特徴とする請求項１に記載の計算機システムの管理方法。
【請求項９】
前記稼動情報に基づいて前記第１の計算機システムの障害を回復可能な計算機の性能に関連する性能情報を演算し、当該性能情報に基づいて前記第２の計算機システムを構成する計算機の性能を変更する手順をさらに含み、
前記障害を回復可能な計算機を選択する手順は、
前記性能を変更した計算機を選択することを特徴とする請求項１に記載の計算機システムの管理方法。
【請求項１０】
前記第２の計算機システムを構成する計算機の性能を変更する手順は、
前記第１の計算機システムの計算機の性能に関連する性能情報を取得する手順と、
前記性能情報と予め設定した値とを比較して、当該比較結果が予め設定した条件となったときに、前記第２の計算機システムを構成する計算機の性能を変更することを判定する手順と、
前記性能情報の種類に基づいて前記第２の計算機システムを構成する計算機の性能を変更する手順と、
を含むことを特徴とする請求項９に記載の計算機システムの管理方法。
【請求項１１】
前記稼動情報を収集する手順は、
前記第１の計算機システムの計算機毎の稼働状態を示す第１の稼動情報を収集する手順と、
前記第１の計算機システムの計算機毎に実行される業務の実行状態を示す第２の稼動情報を収集する手順と、を含み、
前記計算機に障害が発生したことを検知する手順は、
前記第１の稼動情報に基づいて、前記第１の計算機システムを構成する計算機に障害が発生したことを検知し、
前記第２の計算機システムを構成する計算機の性能を変更する手順は、
前記第２の稼動情報に基づいて前記第１の計算機システムの障害を回復可能な計算機の性能に関連する性能情報を演算し、当該性能情報に基づいて前記第２の計算機システムを構成する計算機の性能を変更することを特徴とする請求項９に記載の計算機システムの管理方法。
【請求項１２】
業務を実行する複数の計算機を備えた第１の計算機システムと、複数の計算機を備えた第２の計算機システムと、を備えて、前記第１の計算機システムの計算機に障害が発生したときには、前記第２の計算機システムの計算機に第１の計算機システムの計算機で実行していた業務を引き継ぐ計算機システムの管理方法であって、
前記第１の計算機システムの計算機毎の稼働状態を示す稼動情報を収集する手順と、
前記稼動情報に基づいて、前記第１の計算機システムを構成する計算機に障害が発生したことを検知する手順と、
前記稼動情報に基づいて前記発生した障害の要因を検出する手順と、
前記第２の計算機システムを構成する計算機の性能に関する性能情報を取得する手順と、
前記第１の計算機システムに発生した障害の要因と、前記取得した第２の計算機システムの計算機の性能情報に基づいて、前記障害を回復可能な第２の計算機システムの計算機の性能情報を演算する手順と、
前記第２の計算機システムの計算機の中から前記性能を満たす計算機を選択する手順と、
前記選択した第２の計算機システムの計算機に、前記障害が発生した第１の計算機システムの計算機で実行していた業務を引き継ぐ手順と、
を含むことを特徴とする計算機システムの管理方法。
【請求項１３】
業務を実行する複数の計算機を備えた第１の計算機システムと、複数の計算機を備えた第２の計算機システムと、を備えて、前記第１の計算機システムの計算機に障害が発生したときには、前記第２の計算機システムの計算機に第１の計算機システムの計算機で実行していた業務を引き継ぐ計算機システムの管理方法であって、
前記第１の計算機システムの計算機毎の稼働状態を示す稼動情報を収集する手順と、
前記稼動情報に基づいて、前記第１の計算機システムを構成する計算機に障害が発生したことを検知する手順と、
前記第２の計算機システムを構成する計算機の性能に関する性能情報を取得する手順と、
前記第１の計算機システムに発生した障害の要因と、前記取得した第２の計算機システムの計算機の性能情報に基づいて、前記第２の計算機システムの中から前記障害を回復可能な計算機の性能情報を演算する手順と、
前記演算した性能情報に基づいて前記第２の計算機システムを構成する計算機の性能を変更する手順と、
前記性能を変更した第２の計算機システムの計算機を第１の計算機システムの引き継ぎ先として選択する手順と、
前記選択した第２の計算機システムの計算機に、前記障害が発生した第１の計算機システムの計算機で実行していた業務を引き継ぐ手順と、
を含むことを特徴とする計算機システムの管理方法。
【請求項１４】
前記稼動情報と予め設定した情報を比較することで、前記第１の計算機システムを構成する計算機に障害が発生することを予測する手順と、
前記稼動情報に基づいて前記予測された障害の要因を特定し、当該障害の要因に基づいて前記予測された障害を回復可能な計算機の性能情報を演算する手順と、
前記演算した性能情報に基づいて前記第２の計算機システムを構成する計算機の性能を変更する手順と、
を含むことを特徴とする請求項１３に記載の計算機システムの管理方法。
【請求項１５】
プロセッサと記憶装置及びインターフェースを有し、
プロセッサと記憶装置及びインターフェースを含んで業務を実行する複数の計算機を備えた第１の計算機システムと、
プロセッサと記憶装置及びインターフェースを含んで複数の計算機を備えた第２の計算機システムと、
前記インターフェースを介して第１の計算機システムと第２の計算機システム及び管理サーバを接続するネットワークと、を備え、
前記第１の計算機システムの計算機に障害が発生したときには、前記第２の計算機システムの計算機に前記業務を引き継がせる管理サーバであって、
前記管理サーバは、
前記インターフェースを介して前記プロセッサが受信した第１の計算機システムの計算機毎の稼動情報を前記記憶装置に格納し、当該稼動情報に基づいて前記第１の計算機システムの計算機に障害が発生したことを検知する障害監視部と、
前記稼動情報に基づいて前記プロセッサが前記発生した障害の要因を検出し、当該障害の要因と、前記第２の計算機システムを構成する計算機の性能情報に基づいて、前記第２の計算機システムの中から前記障害を回復可能な計算機を選択する予備系ノード選択部と、
前記障害が発生した第１の計算機システムで実行していた業務を、前記選択した第２の計算機システムの計算機に引き継ぐように当該選択した計算機に前記プロセッサが指令する予備系ノード起動部と、
を備えたことを特徴とする管理サーバ。
【請求項１６】
プロセッサと記憶装置及びインターフェースを有し、
プロセッサと記憶装置及びインターフェースを含んで業務を実行する複数の計算機を備えた第１の計算機システムと、
プロセッサと記憶装置及びインターフェースを含んで複数の計算機を備えた第２の計算機システムと、
前記インターフェースを介して前記第１の計算機システムと第２の計算機システム及び管理サーバを接続するネットワークとを備え、
前記第１の計算機システムの計算機に障害が発生したときには、前記第２の計算機システムの計算機に前記業務を引き継がせる管理サーバであって、
前記管理サーバは、
前記インターフェースを介して前記プロセッサが受信した第１の計算機システムの計算機毎の稼動情報を前記記憶装置に格納し、当該稼動情報に基づいて前記第１の計算機システムの計算機に障害が発生したことを検知する障害監視部と、
前記稼動情報に基づいて前記プロセッサが前記障害を回復可能な性能情報を演算し、当該性能情報に基づいて前記第２の計算機システムに計算機の性能を変更する指令を送信するノード環境設定制御部と、
前記障害が発生した第１の計算機システムで実行していた業務を、前記性能を変更した第２の計算機システムの計算機に引き継ぐように前記第２の計算機システムへ前記プロセッサが指令する予備系ノード起動部と、
を備えたことを特徴とする管理サーバ。
【請求項１７】
前記第２の計算機システムは、物理計算機上に複数の仮想計算機を実行させる仮想化部を有し、
前記ノード環境設定制御部は、
前記性能情報に基づいて前記第２の計算機システムの仮想化部に仮想計算機の性能を変更する指令を送信し、
前記予備系ノード起動部は、
前記障害が発生した第１の計算機システムで実行していた業務を、前記性能を変更した第２の計算機システムの仮想計算機に引き継ぐように前記第２の計算機システムの仮想計算機へ前記プロセッサが指令することを特徴とする請求項１６に記載の管理サーバ。
【請求項１８】
業務を実行する複数の計算機を備えた第１の計算機システムと、
複数の計算機を備えた第２の計算機システムと、
前記第１の計算機システムの計算機に障害が発生したときには、前記第２の計算機システムの計算機で業務を引き継がせる管理サーバと、
前記第１の計算機システムと第２の計算機システム及び管理サーバを接続するネットワークとを備えた計算機システムであって、
前記第１の計算機システムの計算機は、
演算を実行するプロセッサと、
データを格納するストレージ部とプロセッサの間で、データの転送を制御するＩ／Ｏ制御部と、
前記プロセッサとネットワークとの間で通信を制御する通信制御部と、
前記プロセッサとＩ／Ｏ制御部及び通信制御部の稼動状態を検出する状態検知部と、
前記状態検知部に異常が発生したか否かを判定する異常検知部と、
前記異常が発生したときには、当該異常が発生した部位を異常の種類として設定し、異常の発生と前記種類と当該異常の発生した計算機の識別子を前記管理サーバに通知する状態通知部と、
を備えたことを特徴とする計算機システム。
【請求項１９】
業務を実行する複数の計算機を備えた第１の計算機システムと、複数の計算機を備えた第２の計算機システムと、を備えて、前記第１の計算機システムの計算機に障害が発生したときには、前記第２の計算機システムの計算機に第１の計算機システムの計算機で実行していた業務を引き継がせる処理を管理サーバに機能させるプログラムであって、
前記第１の計算機システムの計算機毎の稼働状態を示す稼動情報を収集する手順と、
前記稼動情報に基づいて、前記第１の計算機システムを構成する計算機に障害が発生したことを検知する処理と、
前記稼動情報に基づいて前記前記第１の計算機システムを構成する計算機に発生した障害の要因を検出する処理と、
前記第２の計算機システムを構成する計算機の性能に関する性能情報を取得する処理と、
前記第１の計算機システムに発生した障害の要因と、前記取得した第２の計算機システムの計算機の性能情報に基づいて、前記第２の計算機システムの中から前記障害を回復可能な計算機を選択する処理と、
前記選択した第２の計算機システムの計算機に、前記障害が発生した第１の計算機システムの計算機で実行していた業務を引き継ぐ指令を送信する処理と、
を前記管理サーバに機能させることを特徴とするプログラム。
【請求項２０】
業務を実行する複数の計算機を備えた第１の計算機システムと、複数の計算機を備えた第２の計算機システムと、を備えて、前記第１の計算機システムの計算機に障害が発生したときには、前記第２の計算機システムの計算機に第１の計算機システムの計算機で実行していた業務を引き継がせる処理を管理サーバに機能させるプログラムであって、
前記第１の計算機システムの計算機毎の稼働状態を示す稼動情報を収集する手順と、
前記稼動情報に基づいて、前記第１の計算機システムを構成する計算機に障害が発生したことを検知する処理と、
前記稼動情報に基づいて前記前記第１の計算機システムを構成する計算機に発生した障害の要因を検出する処理と、
前記第２の計算機システムを構成する計算機の性能に関する性能情報を取得する処理と、
前記第１の計算機システムに発生した障害の要因と、前記取得した第２の計算機システムの計算機の性能情報に基づいて前記障害を回復可能な計算機の性能情報を演算する処理と、
前記演算した性能情報に基づいて前記第２の計算機システムを構成する計算機の性能を変更する処理と、
前記性能を変更した第２の計算機システムの計算機に、前記障害が発生した第１の計算機システムの計算機で実行していた業務を引き継ぐ指令を送信する処理と、
を前記管理サーバに機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は計算機システムのデータ処理技術に関わり、特に、系切り替え機能を有するデータベース管理システムに適用可能な技術に関するものである。
【背景技術】
【０００２】
データベース管理システム（以下、ＤＢＭＳ）では、システムの信頼性向上と稼動率向上を目的として、障害発生時の影響の局所化と迅速なシステム回復が重要である。従来より、ＤＢＭＳでは、障害発生時の迅速なシステム回復のために、サービス実行用の実行系ノードとは別に待機系ノードを用意し、障害発生時には実行系ノードから待機系ノードにサービスの実行を切り替える「系切り替え」という技術が用いられてきた。
【０００３】
ＤＢＭＳの障害対策としては、システム構成によってホットスタンバイ無停止運用を行う技術が知られている（例えば、非特許文献１）。
【０００４】
一方、データベース処理負荷を複数のプロセッサに分散させ実行するアーキテクチャも知られており、例えば、非特許文献２に開示されている。上記従来技術にはShared Everything, Shared Disk(共用型)アーキテクチャが開示されており、この種のシステムではＤＢ処理を行う全てのノードが全てのディスクにアクセス可能であり、Shared Nothing(非共用型)アーキテクチャでは各ノードに接続されたディクスに格納されたデータのみにアクセス可能である。
【０００５】
上記従来技術において、任意のノードで障害が発生している場合、予め決められた待機系ノードに対して系切り替えをするために、実行系ノードに対して１：１で予備系ノードを用意するサーバープール等が知られている。しかし、近年のブレードサーバの登場と相まって、ハードウェア的なノードの追加や構成変更が容易になってきており、ブレードの追加時にシステムに存在するノードを有効利用することができるソフトウェア技術が注目されている。
【非特許文献１】「Transaction Processing: Concepts and Techniques」、Jim Gray、Andreas Reuter  著、Morgan Kaufmann Publishers、１９９２年発行、第６４６頁〜第６４８頁、第９２５頁〜第９２７頁
【非特許文献２】「Parallel Database Systems: The Future of High Performance Database Systems」、David DeWitt、Jim Gray  著、COMMUNICATIONS OF THE ACM, Vol.35, N06, 1992年発行, 第８５頁〜第９８頁
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上記系切り替え機能を持つシステムでは、１つの実行系ノードに対して別に同等性能を持つ待機系ノードを用意する必要があり、複数ノードで稼動しているＤＢＭＳではノードの数だけの待機系ノードが必要となる。通常のサービス実行時には待機系ノードは遊んでいる状態であり、通常未稼動状態である待機専用のリソース(プロセッサやメモリなど)を必要とするシステムにおいては通常時にリソースを有効に利用できておらず、システム構築・運用におけるＴＣＯ(Total Cost of Ownership)削減の観点で問題である。
【０００７】
また、系切り替えが発生する障害の要因にはハードウェア障害や処理負荷が増大したためにシステムが極端に遅くなるといった性能障害など様々なものがある。障害の要因がハードウェア障害のような場合には単純に待機系ノードに系を切り替えることによって障害要因は取り除かれることとなるが、処理負荷増大による性能障害の場合、系を切り替えたとしても、切り替えた先の待機系ノードでもまた性能障害に陥るという問題がある。
【０００８】
本発明の目的は上記問題を解決し、前述のような１つの実行系ノードに対して１つの待機系ノードを必要とすることなく、かつ障害の要因に対応した計算機の系切り替え制御方式を提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明は、業務を実行する複数の計算機を備えた第１の計算機システムと、複数の計算機を備えた第２の計算機システムと、を備えて、前記第１の計算機システムの計算機に障害が発生したときには、前記第２の計算機システムの計算機に第１の計算機システムの計算機で実行していた業務を引き継ぐ計算機システムの管理方法であって、前記第１の計算機システムを構成する計算機に障害が発生したことを検知し、前記発生した障害の要因と、前記第２の計算機システムを構成する計算機の性能に関する性能情報に基づいて、前記第２の計算機システムの中から前記障害を回復可能な計算機を選択し、前記選択した第２の計算機システムの計算機に、前記障害が発生した第１の計算機システムの計算機で実行していた業務を引き継ぐ。
【００１０】
また、前記第２の計算機システムを構成する計算機の数は、前記第１の計算機システムを構成する計算機の数よりも少ない。
【００１１】
また、業務を実行する複数の計算機を備えた第１の計算機システムと、複数の計算機を備えた第２の計算機システムと、を備えて、前記第１の計算機システムの計算機に障害が発生したときには、前記第２の計算機システムの計算機に第１の計算機システムの計算機で実行していた業務を引き継ぐ計算機システムの管理方法であって、前記第１の計算機システムの計算機毎の稼働状態を示す稼動情報を収集し、前記稼動情報に基づいて、前記第１の計算機システムを構成する計算機に障害が発生したことを検知して、前記稼動情報に基づいて前記発生した障害の要因を検出し、前記第２の計算機システムを構成する計算機の性能に関する性能情報を取得し、前記障害の要因と前記性能情報に基づいて前記障害を回復可能な計算機の性能情報を演算し、前記演算した性能情報に基づいて前記第２の計算機システムを構成する計算機の性能を変更し、前記性能を変更した第２の計算機システムの計算機を第１の計算機システムの引き継ぎ先として選択して、前記選択した第２の計算機システムの計算機に、前記障害が発生した第１の計算機システムの計算機で実行していた業務を引き継ぐ。
【発明の効果】
【００１２】
したがって、本発明は、ｎ個の実行系ノード（第１の計算機システムの計算機）に対してｍ（＜ｎ）個の待機系ノード（第２の計算機システムの計算機）だけを用意することで、１つの実行系ノードに対して１つの特定の待機系ノードを割り当てずに、障害が発生した時にｍ個の待機系の中から障害の要因に応じた適切なものを選択することによって、遊んでいる状態の待機系ノードの運用コストを減少することができる。
【００１３】
また、ｍ個の待機系ノードに障害の要因に対応した特性をもつノードを用意しておくことで、系切り替えが発生した時に系切り替え（引き継ぎ）後に同じ障害要因が発生しないようにできる。
【００１４】
さらに、障害の内容に応じた性能の待機系ノードの計算機を選択してデータベースを引き継ぐことができ、実行系ノードを引き継ぐ待機系ノードの計算機の性能が過剰になるのを防ぐことができる。
【発明を実施するための最良の形態】
【００１５】
以下、本発明を実施するための最良の形態を図面に基づいて詳細に説明する。
【００１６】
＜第１実施形態＞
図１は、第１の実施形態を示し、本発明を適用する計算機システムのハードウェア構成を示すブロック図である。
【００１７】
図１において、ネットワーク４１０には、業務を提供する実行系ノード２００を構成するサーバ４２０と、実行系ノード２００に障害が発生したときに業務を引き継ぐ予備系（待機系）ノード３００のサーバ４３０と、これら実行系ノード２００と予備系ノード３００を管理する管理サーバ１００と、実行系ノード２００にアクセスするクライアントコンピュータ１５０が接続されている。なお、ネットワーク４１０は、例えば、ＩＰネットワークで構成される。また、業務はデータベース管理システムやアプリケーションあるいはサービスなどで構成される。
【００１８】
管理サーバ１００は、演算処理を行うＣＰＵ１０１と、プログラムやデータを格納するメモリ１０２と、ネットワーク４１０を介して他の計算機と通信を行うネットワークインターフェース１０３を備える。なお、ＣＰＵはホモジニアス・プロセッサに限定されるものではなく、ヘテロジニアス・プロセッサで構成することができる。
【００１９】
実行系ノード２００は、１つまたは複数のサーバ４２０から構成される。サーバ４２０は、演算処理を行うＣＰＵ４２１と、データベースの処理を行うプログラムやデータを格納するメモリ４２２と、ネットワーク４１０を介して他の計算機と通信を行う通信制御装置４２３と、ＳＡＮ（Storage Area Network）４０５を介してストレージ装置４０６にアクセスを行うＩ／Ｏ制御装置（ホストバスアダプタ）４２４を備える。
【００２０】
予備系ノード３００は、実行系ノードと同様に、１つまたは複数のサーバ４３０から構成される。但し、実行系ノード２００のサーバ４２０の総数に比して予備系ノード３００のサーバ４３０の総数は少なく設定される。
【００２１】
サーバ４３０は、演算処理を行うＣＰＵ４３１と、データベースの処理を行うプログラムやデータを格納するメモリ４３２と、ネットワーク４１０を介して他の計算機と通信を行う通信制御装置４３３と、ＳＡＮ（Storage Area Network）４０５を介してストレージ装置４０６にアクセスを行うＩ／Ｏ制御装置４３４を備える。
【００２２】
ストレージ装置４０６は複数のディスクドライブを備え、実行系ノード２００と予備系ノード３００からアクセス可能な記憶領域としてボリューム４０７が設定される。このボリューム４０７に後述するデータベース４００が格納される。
【００２３】
図２は、図１の計算機システムで実行されるデータベース管理システムのソフトウェア構成を示すブロック図である。この例では、障害発生時に障害の要因に対応したＤＢアクセス処理を再開可能なデータベースシステムの構成を示すものである。本実施形態では、ネットワーク４１０で接続された１台以上のサーバ４２０と１台以上のサーバ４３０と管理サーバ１００、及びサーバ４２０とサーバ４３０に接続されたデータベース４００で実現されている。
【００２４】
実行系ノード２００の各サーバ４２０では、自身の障害の有無を検知する障害検知部２１０と、クライアントコンピュータ１５０からの要求に応じて、ストレージ装置４０６のボリューム４０７に格納されたデータベース４００に対して参照または更新を行うデータベース管理システム（ＤＢＭＳ）２２０が割り当てられ、実行されている。
【００２５】
なお、データベース管理システム２２０は、ストレージ装置４０６のボリューム４０７に格納されたデータベース４００を複数の分割データベースに分割し、そのおのおのに対してサーバ４２０を関連付けてデータ処理を行う。
【００２６】
予備系ノード３００の各サーバ４３０にも、実行系ノード２００のサーバ４２０と同様に、障害検知部３１０とデータベース管理システム３２０が割り当てられている。
【００２７】
実行系ノード２００と予備系ノード３００を管理する管理サーバ１００では、各サーバ４２０の障害検知部２１０からの情報を監視し、各サーバ４２０の稼動状態を監視する障害監視部１１０と、予備系ノード３００の各サーバ４３０を管理する予備系ノード管理部１２０と、実行系ノード２００に障害が発生したときに、予備系ノード３００でデータベース管理システムを引き継ぐサーバ４３０を管理する予備系ノード優先度テーブル１３０が割り当てられている。
【００２８】
図３は図２に示した構成の実行系ノード２００の各機能要素をさらに詳細に示したブロック図である。図３においては、実行系ノード２００のうちひとつのノードを構成するひとつのサーバ４２０を示している。
【００２９】
障害検知部２１０は、ＣＰＵ４２１とＩ／Ｏ制御装置４２４と通信制御装置４２３及びデータベース管理システム２２０の状態を監視するノード状態チェック機能２１１を有する。ノード状態チェック機能２１１は、上記のデバイスまたはシステムのいずれかに異常があれば、ノード状態通達機能２１２から管理サーバ１００に障害情報を通知するとともに、ＤＢＭＳ停止機能２１３を用いてデータベース管理システム２２０に停止指示を出す。
【００３０】
ノード状態チェック機能２１１は、ＣＰＵ４２１の監視については、例えば、ＣＰＵ４２１の利用率または負荷を検知し、利用率が所定のしきい値（例えば、９９％）を超えている時間が所定時間に達した場合には負荷が過大になって障害が発生したと判定する。換言すれば、ＣＰＵ４２１の利用率が１００％の状態で所定時間を経過すると、障害が発生したと判定する。
【００３１】
ここで、ＣＰＵ４２１の負荷が要因でＤＢＭＳ２２０が動作できなくなる要因として、
・データベース４００のトランザクション処理量の増大（データベース４００の実行プロセスに対するＣＰＵ占有（利用）率の増大）
・データベース以外のプロセスのＣＰＵ占有率の増大
などが上げられる。
【００３２】
このため、ノード状態チェック機能２１１は、システム全体のＣＰＵ利用率、ＤＢプロセスのＣＰＵ利用率、ＣＰＵ４２１へのプロセスの実行待ち行列の長さ、ＣＰＵ４２１への実行可能プロセスのスワップ待ち行列の長さまたはメッセージキューの長さなどを監視することができる。そして、ノード状態チェック機能２１１は、監視した値が予め設定した値を超えたとき（または所定の条件を満たしたとき）に、障害発生を判定する。なお、ＣＰＵ４２１の利用率以外の測定値は、普段の値と比較して、増大した比率等によって障害発生を判定することができる。
【００３３】
また、ノード状態チェック機能２１１は、Ｉ／Ｏ制御装置４２４や通信制御装置４２３の監視については、スループット（転送速度や通信速度）を監視し、スループット（一定時間内のＩ／Ｏデータ量）が予め設定したしきい値未満となったときに障害が発生したと判定する。これは、純粋に、ストレージ装置４０６へのアクセス頻度やネットワーク４１０からのアクセス頻度が普段の値と比較し、増大した比率によって障害発生を判定するものである。
【００３４】
また、ノード状態チェック機能２１１は、データベース管理システム２２０の監視については、キャッシュメモリ（図示省略）へのバッファヒット率を監視して、測定したヒット率が予め設定したしきい値未満となったときに障害が発生したと判定する。この例も、上記と同様に、ストレージ装置４０６へのアクセス頻度が普段の値と比較し、増大した比率によって障害発生を判定するものである。
【００３５】
なお、実行系ノード２００の各サーバ４２０のデータベース管理システム２２０は、各サーバ４２０のハードウェアやソフトウェアに関するノード情報２２１を保持する。このノード情報２２１は、例えば、ＣＰＵ４２１の性能や数、メモリ４２２の容量、ＯＳの種類、ノードの識別子（ノード名）などが含まれる。
【００３６】
図４は図２で示した構成の管理サーバ１００の各機能要素の詳細を示すブロック図である。障害監視部１１０では各実行系ノード２００から通知があった障害情報を障害情報収集機能１１１で受け取る。障害情報収集機能１１１は障害情報と障害が発生したノード名を予備系ノード管理部１２０に通知する。
【００３７】
予備系ノード管理部１２０では、予備系ノード選択機能１２１が予備系ノード優先度テーブル１３０と障害情報に基づいて系切り替え先となる予備系ノード３００（サーバ４３０）を決定する。また、予備系ノード選択機能１２１は、系切り替え先として決定した予備系ノードを実行系ノード２００に割り当てた後に、この予備系ノードの情報を予備系ノード優先度テーブル１３０から削除する。予備系ノード起動機能１１２は上記決定した系切り替え先の予備系ノード３００に対して、系切り替え元ノードの情報とデータベース管理システム３２０の起動指示を行う。
【００３８】
図５は図２で示した構成の予備系ノード３００の各機能要素の詳細を示すブロック図である。図５においては、予備系ノード３００のうちひとつのノードを構成するひとつのサーバ４３０を示している。予備系ノード３００の障害検知部３１０のうち、ノード状態チェック機能３１１、ノード状態通達機能３１２は、実行系ノード２００のノード状態チェック機能２１１、ノード状態通達機能２１２と同様である。
【００３９】
障害検知部３１０のＤＢＭＳ起動処理機能３１３は、管理サーバ１００からデータベース管理システムの起動指示と系切り替え元のノード情報を受け取る。また、ＤＢＭＳ起動処理機能３１３は、切り換え元の実行系ノード２００から取得したノード情報をデータベース管理システム３２０に渡すとともに、データベース管理システム３２０の起動指示を行う。
【００４０】
図６、図７は予備系ノード３００が予備系ノードＡ、予備系ノードＢ、予備系ノードＣで構成された場合の一例を示しており、図６は予備系ノードＡ〜Ｃ間の性能差を示す説明図で、図７は同じく予備系ノードを管理する予備系ノード優先度テーブル１３０の構成例を示す。
【００４１】
図６ではそれぞれの予備系ノードＡ〜ＣがもつＣＰＵ性能、Ｉ／Ｏ性能、通信性能の性能差の例である。ＣＰＵ性能は予備系ノードＡの性能が一番高く、予備系ノードＢ、予備系ノードＣの順に性能が高い。Ｉ／Ｏ性能は予備系ノードＣの性能が一番高く、予備系ノードＡ、予備系ノードＢの順に性能が高くなる。通信性能は予備系ノードＢの性能が一番高く、予備系ノードＣ、予備系ノードＡの順に性能が高くなる。
【００４２】
図７は図６の予備系ノードの性能差を用いて作成した予備系ノード優先度テーブル１３０の例である。予備系ノード優先度テーブル１３０は、予備系ノード名（または識別子）１３１毎に、予備系ノード３００内でのＣＰＵ性能の順位がＣＰＵ負荷１３２に設定され、予備系ノード３００内でのＩ／Ｏ性能の順位がＩ／Ｏ負荷１３３に、同じく通信性能の順位が通信障害１３４に設定され、また、ＤＢＭＳの障害時に選択すべきノード（サーバ４３０）の順位がＤＢＭＳ障害１３５に格納される。なお、各項目の順位は、値が小さいほど優先度が高くなるように設定される。
【００４３】
ある実行系ノード２００に障害が発生した場合、予備系ノード管理部１２０は、障害の要因に従って系切り替え先の予備系ノード３００の決定を予備系ノード優先度テーブル１３０に基づいて行う。例えば、障害要因がＣＰＵ負荷１３２の場合は優先度に従い、ノードＡを選択する。障害要因がＩ／Ｏ負荷１３３の場合はノードＣを選択する。障害要因が通信障害１３４の場合はノードＢを選択する。障害要因がＤＢＭＳ障害１３５の場合はノードＢを選択をする。
【００４４】
なお、実行系ノード２００では、各サーバ４２０の上記各性能は均一であることが望ましい。しかしながら障害発生時には、サーバ４２０間で負荷が異なること場合がある。このため、予備系ノード３００を構築する際には、図６、図７で示したように、サーバ４３０間の各性能が異なるように構成することが望ましい。また、図６において予備系ノード３００を構成する各ノードＡ〜Ｃの性能の基準は、予備系ノード３００の構築に要する費用に応じて設定することができる。例えば、費用に余裕がある場合では、実行系ノード２００の性能を予備系ノード３００の低性能とする。あるいは、予備系ノード３００の構築に許容される費用が限られている場合では、実行系ノード２００の性能を予備系ノード３００の中間の性能とする。なお、図６、図７では、予備系ノード３００を３つのノードＡ〜Ｃで構成した例を示したが、多数のノードで構成する場合では、同一の性能を備えたサーバ４３０が複数存在してもよい。
【００４５】
図８は本実施形態の実行系ノード２００にて障害が発生した場合の処理手順のフローチャートである。
【００４６】
実行系ノード２００のノード状態チェック機能２１１はステップ６０１においてＣＰＵ４２１の処理負荷状態、Ｉ／Ｏ制御装置４２４の処理負荷状態、通信制御装置４２３の通信負荷状態、データベース管理システム２２０の状態をチェックし、それぞれの状態が正常であるかをチェックする。このとき、それぞれの状態が正常であれば、一定時間ごとにステップ６０１を繰り返して行う。チェックしたもののうち何れかの状態に異常がある場合にはステップ６０２に進む。
【００４７】
ステップ６０２では、障害の要因がＤＢＭＳ障害であるかどうかのチェックを行う。障害要因がＤＢＭＳ障害（ＤＢＭＳの停止や処理遅延）である場合は、データベース管理システム２２０が異常終了しているので、ステップ６０４に進み、管理サーバに対して障害内容を送信する。
【００４８】
また、ステップ６０２において、障害要因がＤＢＭＳ障害でない場合は、データベース管理システム２２０自体は正常動作中であるため、ステップ６０３に進み、データベース管理システム２２０に対して停止指示を出し、データベース管理システム３２０を停止する。その後、ステップ６０４に進み、管理サーバ１００に対して障害内容と、ノード情報を送信する。
【００４９】
図９は管理サーバ１００が実行系ノード２００から障害情報を受け取った場合の処理手順のフローチャートである。
【００５０】
管理サーバ１００の障害情報収集機能１１１はステップ７０１において、実行系ノード２００から障害情報を受け取る。ステップ７０２では予備系ノード選択機能１２１が予備系ノード優先度テーブル１３０の情報を取得して、ステップ７０４において、障害情報から得られた障害の要因を用いて、系の切り替え先となる予備系ノード３００を決定する。ステップ７０５においては、決定した予備系ノード３００の情報を予備系ノード優先度テーブルから削除する。次に予備系ノード起動機能１１２はステップ７０６において決定した予備系ノード３００に対して、障害が発生した実行系ノードのノード情報と予備系ノードの起動通知を送信する。
【００５１】
図１０は予備系ノード３００が管理サーバ１００からノード情報と起動通知を受け取った場合の処理手順のフローチャートである。
【００５２】
予備系ノード３００のＤＢＭＳ起動機能３１３はステップ８０１において、管理サーバ１００から障害が発生した実行系ノード２００のノード情報を受け取る。ステップ８０２において、受け取ったノード情報をデータベース管理システム３２０に転送し、データベース管理システム３２０は障害が発生した実行系ノード２００の情報を設定する。次にステップ８０３において、ＤＢＭＳ起動機能３１３はデータベース管理システム３２０に起動指示を出し、データベース管理システム３２０の起動を行う。起動が完了した後、ステップ８０４において、障害検知機構３１０にノード状態チェックを開始する。ここで、予備系ノード３００は実行系ノード２００として系切り替えが完了する。
【００５３】
図１１は上記図６と図７で示した予備系ノード３００として予備系ノードＡ４３０Ａ、予備系ノードＢ４３０Ｂ、予備系ノードＣ４３０Ｃを用意したデータベース管理システムのシステム構成を示す。ここで、データベース管理システムは、ブレードサーバ４４０に挿入された１台以上の実行系サーバ２００と３台の予備系サーバ（４３０Ａ〜Ｃ）で稼動する。
【００５４】
また、管理サーバ１００はブレードサーバ４４０の外側にあるが、ブレードサーバ４４０に挿入されたサーバでもよい。
【００５５】
実行系サーバ４２０は通常、ＤＢアクセス処理を行っているが任意の実行系サーバ４２０においてＣＰＵに高負荷がかかった場合についての動作を説明する。
【００５６】
実行系サーバ４２０がＤＢアクセス処理中によってＣＰＵ４２１に高負荷がかかった場合、実行系サーバ４２０の障害検知部２１０がＣＰＵ４２１に異常が生じたと判定する。障害検知部２１０は障害要因がＤＢＭＳ障害でないので、実行系サーバ４２０で稼動中のデータベース管理システム２２０を停止する。次に障害検知部２１０は実行系サーバ４２０で発生した障害情報を管理サーバ１００に対して送信をする。
【００５７】
実行系ノード２００からの障害情報を受け取った障害監視部１１０は、系切り替え先の予備系ノード３００を決定するために障害情報を予備系ノード管理部１２０に渡す。予備系ノード管理部１２０では予備系ノード優先度テーブル１３０（図７）を参照して、障害要因がＣＰＵ負荷である場合の優先度１の予備系ノードである予備系ノードＡ４３０Ａを系切り替え先として決定する。このとき、予備系ノード管理部１２０は予備系ノードＡ４３０Ａの情報を予備系ノード優先度テーブル１３０から削除する。次に障害監視部１１０は系切り替え先に決定した予備系ノードＡ４３０Ａに対して、系切り替え元の実行系ノード２００のノード情報とデータベース管理システムの起動通知を予備系ノードＡ４３０Ａに対して行う。
【００５８】
管理サーバ１００からの通知を受けた予備系ノードＡ４３０Ａは、受け取った系切り替え元の実行系ノード２００のノード情報をデータベース管理システム３２０に送り、ノード情報に基づいてデータベース管理システム３２０の設定をした後、データベース管理システム３２０の起動処理を行う。データベース管理システム３２０は起動処理が完了した後、障害検知部３１０に障害監視開始の通知をする。障害検知部３１０は通知を受けて障害監視を開始すると、系切り替え処理が完了する。
【００５９】
このようにして、障害が発生した実行系ノード２００から障害要因に応じた予備系ノードＡ３００のサーバ４３０Ａを割り当てることが可能となる。そして、予備系ノード３００の各サーバ４３０Ａ〜Ｃは、性能が異なるサーバで予備系ノード３００を構成することで、実行系ノード２００の障害要因の種類に応じた最適なサーバ４３０を引き継ぎ先として選択することが可能となる。これにより、予備系ノード３００の各サーバ４３０Ａ〜４３０Ｃを選択する際には、障害の要因を回復可能な所定の性能を備えたサーバ４３０Ａ〜４３０Ｃを選択することで、障害からの回復を確実に行うことができる。ここで、所定の性能は、ＣＰＵ性能、Ｉ／Ｏ性能、通信性能などであり、図７で示すように障害の要因別に、選択すべきサーバ４３０Ａ〜４３０Ｃの相対的な優先順位が予め設定される。この障害の要因別の優先順位は、上記サーバ４３０Ａ〜４３０Ｃの各種性能差に応じて予め設定したものである。
【００６０】
また、実行系ノード２００に障害が発生したときに、全てのサーバ４２０に障害が発生することは希であるため、予備系（待機系）ノード３００のサーバ４３０の数を実行系ノード２００のサーバ４２０の数よりも少なくすることができる。これにより、予備系ノード３００の構築、運用に係るコストを削減しながらも、耐障害性を高めることができる。
【００６１】
＜第２実施形態＞
図１２は、第２の実施形態を示し、前記第１実施形態の障害発生の判定を行う機能を実行系ノード２００のサーバ４２０から管理サーバ１００に移したものであり、その他の構成は、前記第１実施形態と同様である。
【００６２】
実行系ノード２００のサーバ４２０には、ＣＰＵ４２１、Ｉ／Ｏ制御装置４２４、通信制御装置４２３、データベース管理システム２２０を監視し、稼動状態を管理サーバ１００に通知するノード状態通達機能２１２Ａが稼動する。なお、ノード状態通達機能２１２Ａは、所定の周期で各デバイスやシステムの稼動状態を監視する。
【００６３】
管理サーバ１００の障害監視部１１０には、各サーバ４２０から収集した稼動状態を予め設定したしきい値と比較して、障害の有無を判定する障害判定部１１３が稼動する。この障害判定部１１３は、障害を検知すると必要に応じて障害が発生したサーバ４２０に対してＤＢＭＳ停止機能２１３に停止指令を通知する。その他は、前記第１実施形態と同様である。
【００６４】
このように、実行系ノード２００の各サーバ４２０の障害発生の判定を管理サーバ１００に集約して行うことで、各サーバ４２０の処理負荷を低減し、各サーバ４２０のリソースをより有効に利用することができる。
【００６５】
＜第３実施形態＞
図１３は、第３の実施形態を示し、前記第１実施形態の管理サーバ１００の機能を予備系ノード３００の一つのサーバに実行させ、物理的な管理サーバ１００を不要にしたものである。
【００６６】
予備系ノード３００には、前記第１実施形態と同様に３つのサーバ４３０Ａ〜４３０Ｃで構成し、各サーバ４３０Ａ〜Ｃには障害検知部３１０とデータベース管理システム３２０を備える。さらに、予備系ノード３００の一つのサーバ４３０Ｃには前記第１実施形態の管理サーバ１００と同様の機能を提供する管理部１００Ａを実行させる。
【００６７】
管理部１００Ａは、前記第１実施形態の管理サーバ１００の構成と同様であり、実行系ノード２００の障害情報を監視する障害監視部１１０と、予備系ノード３００を管理する予備系ノード管理部１２０と、業務（データベース管理システム）を引き継ぐサーバ４３０Ａ〜Ｃの順位を管理する予備系ノード優先度テーブル１３０とを備えている。
【００６８】
予備系ノード３００は、実行系ノード２００が正常に稼動していれば、障害に備えて待機しているだけである。そこで、予備系ノード３００のうちの一つのサーバ４３０Ａ〜Ｃに管理部１００Ａを割り当てて実行させることで、物理的な管理サーバ１００を不要にして、実行系ノード２００と予備系ノード３００の計算機のリソースを有効に利用することができる。
【００６９】
＜第４実施形態＞
図１４は、第４の実施形態を示し、前記第１実施形態に示した図１の計算機システムで実行されるデータベース管理システムのソフトウェア構成を示すブロック図である。この実施形態は、障害発生時に障害の要因に対応したＤＢアクセス処理を再開可能なデータベースシステムの構成を示すもので、前記第１実施形態と同一のものに同一の符号を付した。本実施形態では、ネットワーク４１０で接続された１台以上のサーバ４２０と１台以上のサーバ４３０と管理サーバ１００、及びサーバ４２０とサーバ４３０に接続されたデータベース４００で実現されている。
【００７０】
実行系ノード２００の各サーバ４２０では、自身の障害の有無を検知する障害検知部２１０と、クライアントコンピュータ１５０からの要求に応じて、ストレージ装置４０６のボリューム４０７に格納されたデータベース４００に対して参照または更新を行うデータベース管理システム（ＤＢＭＳ）２２０、ＤＢＭＳの内部情報の収集を行うＤＢ情報通知部２３０が割り当てられ、実行されている。ここで、ＤＢＭＳの内部情報であるＤＢ情報は、例えば、キャッシュメモリのヒット率やログバッファが満杯になった回数や単位時間当たりのＤＢ処理プロセス（スレッド）がダウンした回数などで構成することができる。
【００７１】
なお、データベース管理システム２２０は、ストレージ装置４０６のボリューム４０７に格納されたデータベース４００を複数の分割データベースに分割し、そのおのおのに対してサーバ４２０を関連付けてデータ処理を行う。
【００７２】
予備系ノード３００の各サーバ４３０にも、実行系ノード２００のサーバ４２０と同様に、障害検知部３１０とデータベース管理システム３２０、ＤＢ情報通知部３３０が割り当てられている。
【００７３】
実行系ノード２００と予備系ノード３００を管理する管理サーバ１００では、各サーバ４２０の障害検知部２１０からの情報とＤＢ情報通知部２３０からの情報を監視し、各サーバ４２０の稼動状態を監視する障害監視部１１０と、予備系ノード３００の各サーバ４３０を管理する予備系ノード管理部１２０が割り当てられている。予備系ノード管理部１２０では、実行系ノード２００に障害が発生したときに、各サーバ４２０のＤＢ情報通知部２３０からの情報から必要な予備系ノードのスペック（仕様情報）を算出するために利用するＤＢ情報解析テーブルと、予備系ノード３００でデータベース管理システムを引き継ぐサーバ４３０を管理する予備系ノード管理テーブル１３００が割り当てられている。また、管理サーバ１００は、各サーバ４２０ＤＢ情報通知部２３０から取得したデータベース管理システム２２０の状態を格納するＤＢ情報格納部１４０を備えている。
【００７４】
図１５は図１４に示した構成の実行系ノード２００の各機能要素をさらに詳細に示したブロック図である。図１５においては、実行系ノード２００のうちひとつのノードを構成するひとつのサーバ４２０を示している。
【００７５】
障害検知部２１０は、ＣＰＵ４２１とメモリ４２２とＩ／Ｏ制御装置４２４と通信制御装置４２３及びデータベース管理システム２２０の状態を監視するノード状態チェック機能２１１を有する。ノード状態チェック機能２１１は、上記のデバイスまたはシステムのいずれかに異常があれば、ノード状態通達機能２１２から管理サーバ１００に障害情報を通知するとともに、ＤＢＭＳ停止機能２１３を用いてデータベース管理システム２２０に停止指示を出す。
【００７６】
ノード状態チェック機能２１１は、ＣＰＵ４２１の監視については、例えば、ＣＰＵ４２１の利用率または負荷を検知し、利用率が所定のしきい値（例えば、９９％）を超えている時間が所定時間に達した場合には負荷が過大になって障害が発生したと判定する。換言すれば、ＣＰＵ４２１の利用率が１００％の状態で所定時間を経過すると、障害が発生したと判定する。
【００７７】
ここで、ＣＰＵ４２１の負荷が要因でＤＢＭＳ２２０が動作できなくなる要因として、
・データベース４００のトランザクション処理量の増大（データベース４００の実行プロセスに対するＣＰＵ占有（利用）率の増大）
・データベース以外のプロセスのＣＰＵ占有率の増大
などが上げられる。
【００７８】
このため、ノード状態チェック機能２１１は、システム全体のＣＰＵ利用率、ＤＢプロセスのＣＰＵ利用率、ＣＰＵ４２１へのプロセスの実行待ち行列の長さ、ＣＰＵ４２１への実行可能プロセスのスワップ待ち行列の長さ、またはメッセージキューの長さなどを監視することができる。そして、ノード状態チェック機能２１１は、監視した値が予め設定した値を超えたとき（または所定の条件を満たしたとき）に、障害発生を判定する。なお、ＣＰＵ４２１の利用率以外の測定値は、普段の値と比較して、増大した比率等によって障害発生を判定することができる。
【００７９】
また、ノード状態チェック機能２１１は、Ｉ／Ｏ制御装置４２４や通信制御装置４２３の監視については、スループット（転送速度や通信速度）を監視し、スループット（一定時間内のＩ／Ｏデータ量）が予め設定したしきい値未満となったときに障害が発生したと判定する。これは、純粋に、ストレージ装置４０６へのアクセス頻度やネットワーク４１０からのアクセス頻度が普段の値と比較し、増大した比率によって障害発生を判定するものである。
【００８０】
また、ノード状態チェック機能２１１は、データベース管理システム２２０の監視については、キャッシュメモリ（図示省略）へのバッファヒット率を監視して、測定したヒット率が予め設定したしきい値未満となったときに障害が発生したと判定する。この例も、上記と同様に、ストレージ装置４０６へのアクセス頻度が普段の値と比較し、増大した比率によって障害発生を判定するものである。キャッシュメモリ（またはＤＢキャッシュ、ＤＢ内部バッファ）やログバッファは、メモリ４２２の所定の領域に設定される。なお、ログバッファは、データベース管理システム２２０が作成したデータベースの操作履歴のログを一時的に格納するものである。
【００８１】
ＤＢ情報通知部２３０は、データベース管理システム２２０のＤＢ情報を定期的に収集するＤＢ状態取得機能２３１と収集したＤＢ情報を管理サーバ１００に通知を行うＤＢ状態通知機能２３２を有する。
【００８２】
ＤＢ状態取得機能２３１はＤＢＭＳ上から次のようなＤＢ情報を収集する。
・ メッセージキュー滞留の超過時間
・ 単位時間内のＤＢ処理プロセスダウン回数の超過
・ 排他タイムアウト数超過
・ ＵＡＰ（ＳＱＬ）実行時間経過
・ 排他競合回数超過
・ ログバッファ満杯回数
・ ＤＢ入出力バッファヒット率
なお、実行系ノード２００の各サーバ４２０のデータベース管理システム２２０は、各サーバ４２０のハードウェアやソフトウェアに関するノード情報２２１を保持する。このノード情報２２１は、例えば、ＣＰＵ４２１の性能や数、メモリ４２２の容量、ＯＳの種類、ノードの識別子（ノード名）などが含まれる。
【００８３】
図１６は図１４で示した構成の管理サーバ１００の各機能要素の詳細を示すブロック図である。障害監視部１１０では各実行系ノード２００から通知があった障害情報とＤＢ情報を情報収集機能１１１で受け取る。情報収集機能１１１は障害情報と障害が発生したノード名、ＤＢ情報を予備系ノード管理部１２０に通知する。
【００８４】
予備系ノード管理部１２０では、ＤＢ情報解析機能１２２がＤＢ情報解析テーブル１３１とＤＢ情報と障害が発生したノード情報に基づいて、予備系ノード３００として必要なスペックを算出する。また、予備系ノード選択機能１２１はＤＢ情報解析機能１２２で算出した予備系ノードに最も近いスペックを持つ予備系ノード３００（サーバ４３０）を予備系ノード管理テーブル１３００から決定する。
【００８５】
なお、算出したスペックに最も近いスペックを備えた予備系ノードの決定は、予備系ノード管理部１２０が算出したスペックを満足する予備系ノード３００のサーバ４３０のうち、最もスペック（性能）の低いものを選択する。例えば、算出したスペックがＣＰＵ性能＝１２０％で、予備系ノード３００にＣＰＵ性能が、１００％、１３０％、１５０％のサーバ４３０があるときには、ＣＰＵ性能＝１３０％のサーバ４３０を選択する。
【００８６】
また、予備系ノード選択機能１２１は、系切り替え先として決定した予備系ノードを実行系ノード２００に割り当てた後に、この予備系ノードの情報を予備系ノード管理テーブル１３００から削除する。予備系ノード起動機能１１２は上記決定した系切り替え先の予備系ノード３００に対して、系切り替え元ノードの情報とデータベース管理システム３２０の起動指示を行う。
【００８７】
図１７は図１４で示した構成の予備系ノード３００の各機能要素の詳細を示すブロック図である。図１７においては、予備系ノード３００のうちひとつのノードを構成するひとつのサーバ４３０を示している。予備系ノード３００の障害検知部３１０のうち、ノード状態チェック機能３１１、ノード状態通達機能３１２は、実行系ノード２００のノード状態チェック機能２１１、ノード状態通達機能２１２と同様である。
【００８８】
障害検知部３１０のＤＢＭＳ起動処理機能３１３は、管理サーバ１００からデータベース管理システムの起動指示と系切り替え元のノード情報を受け取る。また、ＤＢＭＳ起動処理機能３１３は、切り替え元の実行系ノード２００から取得したノード情報をデータベース管理システム３２０に渡すとともに、データベース管理システム３２０の起動指示を行う。
【００８９】
図１８は予備系ノード３００が予備系ノードＡ、予備系ノードＢ、予備系ノードＣで構成された場合の一例を示しており、予備系ノードを管理する予備系ノード管理テーブル１３００の構成例を示す。
【００９０】
予備系ノード管理テーブル１３００は、予備系ノード名（または識別子）１３０１毎に、予備系ノード３００内でのＣＰＵ性能を数値化（例えば、相対的な処理能力）したものがＣＰＵ負荷１３０２に設定され、予備系ノード３００内でのメモリ量をメモリ量１３０３に、Ｉ／Ｏ性能の差をここでは占有か共有のどちらか(占有の方が共有よりＩ／Ｏ性能がよい)をＩ／Ｏ性能１３０４に、同じく通信性能を通信性能１３０５に設定され、また、データベース処理の性能にかかわるＯＳの設定値がどのような値に設定してあるかをＯＳ設定Ａ１３０６、ＯＳ設定Ｂ１３０７に格納する。ＯＳ設定Ａ１３０６、ＯＳ設定Ｂ１３０７のＯＳの設定値は、例えば、カーネルのパラメータ値を示し、例えば、メッセージキューの数や、セマフォ数の最大値や共有メモリセグメントの最大サイズなど、変更可能なＯＳの設定値を示す。例えば、図１８においてＯＳ設定Ａ１３０６がメッセージキューの数を示し、ＯＳ設定Ｂ１３０７が共有メモリセグメントの最大サイズ（ｋＢ）である。
【００９１】
図１９は実行系ノード２００から取得したＤＢ情報をＤＢ情報解析機能１２２が解析を行うための情報を格納しているＤＢ情報解析テーブル１３１の構成例を示す。
【００９２】
ＤＢ情報解析テーブル１３１は、ＤＢ情報１３１１毎に、閾値１３１２が設定され、それぞれのＤＢ情報１３１１が閾値１３１２を超えた場合、それぞれ必要とするリソース内容１３１３を設定される。リソース内容１３１３は必要とする対象リソース名１３１４と必要なリソース量１３１５を設定し、必要なリソース量１３１５は現在のリソース量に何％加算という値や数値を設定する。
【００９３】
ある実行系ノード２００に障害が発生した場合、予備系ノード管理部１２０は、ノード情報とＤＢ情報から必要となるリソース量をＤＢ情報解析テーブル１３１に基づいて求め、求めたリソース量に従って、系切り替え先の予備系ノード３００の決定を予備系ノード管理テーブル１３００に基づいて行う。例えば、ＣＰＵ性能100でＩ／Ｏ性能が共有である実行系ノード２００において障害が発生した時に、単位時間内のＤＢ処理プロセス（スレッド）ダウン回数の超過が１６であった場合、切り替え先の予備系ノードに求められるＣＰＵ性能は１００×１．３＝１３０であり、Ｉ／Ｏ性能は占有となる。この情報を予備系ノード管理テーブルから、ノードＣを選択する。
【００９４】
なお、予備系ノード管理部１２０は、実行系ノード２００に発生した障害が複数あるときは、対象リソース名１３１４が同一の中から必要なリソース量１３１５の最大値を選択する。例えば、ある実行系ノード２００に発生した障害が、メッセージキュー滞留の超過時間がしきい値１３１２を超え、かつ、ダウン回数の超過がしきい値１３１２に超えた場合、必要なリソース量１３１５の最大値である＋３０％を選択し、切り替え先の予備系ノードに求められるＣＰＵ性能を１００×１．３＝１３０％とする。
【００９５】
なお、実行系ノード２００では、各サーバ４２０の上記各性能は均一であることが望ましい。しかしながら障害発生時には、サーバ４２０間で負荷が異なること場合がある。このため、予備系ノード３００を構築する際には、図１８で示したように、サーバ４３０間の各性能が異なるように構成することが望ましい。また、予備系ノード３００を構成する各ノードＡ〜Ｃの性能の基準は、予備系ノード３００の構築に要する費用に応じて設定することができる。例えば、費用に余裕がある場合では、実行系ノード２００の性能を予備系ノード３００の低性能とする。あるいは、予備系ノード３００の構築に許容される費用が限られている場合では、実行系ノード２００の性能を予備系ノード３００の中間の性能とする。なお、図１８では、予備系ノード３００を３つのノードＡ〜Ｃで構成した例を示したが、多数のノードで構成する場合では、同一の性能を備えたサーバ４３０が複数存在してもよい。
【００９６】
図２０は本実施形態の実行系ノード２００にて障害が発生した場合の処理手順のフローチャートである。この処理は、実行系ノード２００の各サーバ４２０で所定の周期などで実行されるものである。
【００９７】
実行系ノード２００ではＤＢ状態取得機能２３１がステップ６０１でデータベース管理システム２２０のＤＢ情報の取得を行い、取得したＤＢ情報はＤＢ状態通知機能２３２によってステップ６０２で管理サーバ１００に送信する。
【００９８】
ノード状態チェック機能２１１はステップ６０３においてＣＰＵ４２１の処理負荷状態、メモリ４２２のメモリ使用量、Ｉ／Ｏ制御装置４２４の処理負荷状態、通信制御装置４２３の通信負荷状態、データベース管理システム２２０の状態をチェックし、それぞれの状態が正常であるかをチェックする。このとき、それぞれの状態が正常であれば、一定時間ごとにステップ６０１〜ステップ６０３を繰り返して行う。チェックしたもののうち何れかの状態に異常がある場合にはステップ６０４に進む。
【００９９】
ステップ６０４では、障害の要因がＤＢＭＳ障害であるかどうかのチェックを行う。障害要因がＤＢＭＳ障害（ＤＢＭＳの停止や処理遅延）である場合は、データベース管理システム２２０が異常終了しているので、ステップ６０６に進み、管理サーバ１００に対して障害情報とノード情報を送信する。
【０１００】
また、ステップ６０４において、障害要因がＤＢＭＳ障害でない場合は、データベース管理システム２２０自体は正常動作中であるため、ステップ６０５に進み、データベース管理システム２２０に対して停止指示を出し、データベース管理システム２２０を停止する。その後、ステップ６０６に進み、管理サーバ１００に対して障害情報と、ノード情報を送信する。
【０１０１】
図２１は、管理サーバ１００が実行系ノード２００から障害情報を受け取った場合に実行する処理手順のフローチャートである。
【０１０２】
管理サーバ１００の障害情報収集機能１１１はステップ７０１において、実行系ノード２００から障害情報又はＤＢ情報を受け取る。ステップ７０２ではＤＢ情報解析機能１３１が受け取った（または、ＤＢ情報格納部１４０から読み込んだ）ＤＢ情報の解析をＤＢ情報解析テーブル１３１を用いて行う。
【０１０３】
予備系ノード選択機能１２１はステップ７０３で障害情報から障害要因を取得し、ステップ７０４では上記ステップ７０２で取得したＤＢ解析情報とステップ７０３で取得した障害要因の情報を用いてＤＢ情報解析テーブル１３１から予備系ノードとして必要なマシンスペックを算出する。
【０１０４】
ステップ７０５で予備系ノードとして必要なマシンスペックに一番性能の近い予備系ノードを予備系ノード管理テーブル１３００を用いて、系の切り替え先となる予備系ノード３００を決定する。ステップ７０６においては、上記ステップ７０５で決定した予備系ノード３００の情報を予備系ノード管理テーブル１３００から削除する。次に予備系ノード起動機能１１２はステップ７０７において決定した予備系ノード３００に対して、障害が発生した実行系ノード２００のノード情報と起動通知を上記決定した予備系ノード３００へ送信する。
【０１０５】
図２２は予備系ノード３００が管理サーバ１００からノード情報と起動通知を受け取ったときに実行する処理手順のフローチャートである。
【０１０６】
予備系ノード３００のＤＢＭＳ起動機能３１３はステップ８０１において、管理サーバ１００から障害が発生した実行系ノード２００のノード情報を受け取る。ステップ８０２において、受け取ったノード情報をデータベース管理システム３２０に転送し、データベース管理システム３２０は障害が発生した実行系ノード２００の情報を設定する。次にステップ８０３において、ＤＢＭＳ起動機能３１３はデータベース管理システム３２０に起動指示を出し、データベース管理システム３２０の起動を行う。起動が完了した後、ステップ８０４において、障害検知機構３１０にノード状態チェックを開始する。ここで、予備系ノード３００は実行系ノード２００として系切り替えが完了する。
【０１０７】
以上のように、障害要因をノードの障害とノードが実行する業務（データベース管理システムやアプリケーションまたはサービス）の障害に切り分けて、障害の内容（種類）に応じた性能、仕様の予備系ノード３００のサーバ４３０を選択してデータベースを引き継ぐことができる。特に、予備系ノード管理部１２０が、障害の発生した実行系ノード２００を引き継ぐ予備系ノード３００のサーバ４３０のスペック（性能及び仕様）を求め、このスペックに最も近いスペックを持つ予備系ノード３００（サーバ４３０）を選択することで、実行系ノード２００を引き継ぐ予備系ノード３００のサーバ４３０の性能または仕様が過剰になるのを防ぐことができる。これにより、予備系ノード３００のリソースを効率よく利用することができる。
【０１０８】
また、ノードの障害に加えて業務の障害の要因を検知し、予備系ノード３００で障害を回復可能な計算機の性能を求めるようにしたので、実行系ノード２００の障害を確実に回復することができる。そして、予備系ノード３００で選択する計算機の性能を、演算した性能に最も近いものとすることで、予備系ノード３００のリソースが無駄に消費されるのを防いで、効率の良い系切替を実現できる。
【０１０９】
＜第５実施形態＞
図２３は、第５の実施形態を示し、本発明を適用する計算機システムのハードウェア構成を示すブロック図である。前記第４実施形態では物理サーバ上に１つの実行系ノードを作成し、障害が発生した場合には物理サーバ（４２０）単位で系の切り替えを実施していたが、第５の実施形態では、物理サーバ上に仮想化した１つ以上の仮想サーバを作成し、仮想サーバ単位での系切り替えを実施する構成である。
【０１１０】
また、第５の実施形態では前記第４実施形態の系切り替え先の選択方法に加えて、仮想化している系切り替え先の各サーバの予備系ノードのリソースを動的に変更する機能を追加する。その他の構成は前記第４実施形態と同様であり、同一のものに同一の符号を付した。
【０１１１】
図２３において、実行系ノード２００は１つまたは複数の物理サーバ９２６から構成される。物理サーバはサーバ仮想化プログラム９２５により１つまたは複数の仮想サーバ９２０から構成される。仮想サーバ９２０は演算処理を行う仮想ＣＰＵ９２１と、データベースの処理を行うプログラムやデータを格納する仮想メモリ９２２と、ネットワーク４１０を介して他の計算機と通信を行う仮想通信制御装置９２３と、ＳＡＮ（Storage Area Network）４０５を介してストレージ装置４０６にアクセスを行う仮想Ｉ／Ｏ制御装置（ホストバスアダプタ）９２４を備える。
【０１１２】
予備系ノード３００は、実行系ノードと同様に、１つまたは複数の物理サーバ９３６から構成され、物理サーバ９３６は１つまたは複数の仮想サーバ９３０から構成される。仮想サーバ９３０はサーバ仮想化プログラム９３５により演算処理を行う仮想ＣＰＵ９３１と、データベースの処理を行うプログラムやデータを格納する仮想メモリ９３２と、ネットワーク４１０を介して他の計算機と通信を行う仮想通信制御装置９３３と、ＳＡＮ（Storage Area Network）４０５を介してストレージ装置４０６にアクセスを行う仮想Ｉ／Ｏ制御装置（ホストバスアダプタ）９３４を備える。
【０１１３】
実行系ノード２００及び予備系ノード３００のそれぞれの仮想ＣＰＵ、仮想メモリ、仮想通信制御装置、仮想Ｉ／Ｏ制御装置は、物理サーバのＣＰＵ，メモリ、通信制御装置、Ｉ／Ｏ制御装置のリソースを割り当てており、各リソースの割当量はサーバ仮想化プログラムによって制御されている。
【０１１４】
図２４は実行系サーバ２００から受け取ったＤＢ情報を用いて、予備系ノード３００として必要なリソースやＯＳの設定内容を求め、実行系ノード２００から予備系ノード３００への系切り替えが発生する前に、予備系ノード３００の仮想ＣＰＵ９３１、仮想メモリ９３２、仮想通信制御装置９３３、仮想Ｉ／Ｏ制御装置９３４やＯＳパラメータを変更する処理を行う。なお、予備系ノード３００では、サーバ仮想化プログラム９３５が少なくともひとつの仮想サーバ９３０を生成しているものとする。
【０１１５】
管理サーバ１００は障害監視部１１０と予備系ノード管理部１２０で構成され、前記第４実施形態の予備系ノード管理部１２０にノード環境設定制御部１２３を追加する。ノード環境設定制御部１２３はＤＢ情報解析機能１２２がＤＢ情報を解析した結果から、予備系ノード３００に必要なリソース情報やＯＳの設定内容を受け取る。
【０１１６】
ノード環境設定制御部１２３は、予備系ノード管理テーブル１３００を用いて設定を変更する予備系ノード３００の仮想サーバ９３０を選択し、選択した予備系ノード３００の仮想サーバ９３０に対してリソース情報やＯＳの設定内容で構成される設定情報を送信する。
【０１１７】
ノード環境設定制御部１２３は予備系ノード３００の設定が完了したら、予備系ノード管理テーブル１３００の内容を更新する。
【０１１８】
その他の機能は前記第４実施形態と同様である。
【０１１９】
図２５においては、予備系ノード３００のうちのひとつのノードを構成するひとつの物理サーバ９３６を示している。仮想サーバ９３０はサーバ仮想化プログラム９３５によって物理サーバ９３６のリソース（ＣＰＵ、メモリ、Ｉ／Ｏ制御装置、通信制御装置、ＯＳパラメータなど）を割り当てられている。ＯＳパラメタ設定機能９３５１は管理サーバ１００から送信された設定情報に従い、仮想サーバ９３０のＯＳパラメタ値の変更を行う。
【０１２０】
ＣＰＵ割当機能９３５２は管理サーバ１００から送信された設定情報に従い、仮想サーバ９３０の仮想ＣＰＵ９３１に割り当てられている物理サーバ９３６のＣＰＵの割当量の変更を行う。メモリ割当機能９３５３は管理サーバ１００から送信された設定情報に従い、仮想サーバ９３０の仮想メモリ９３２に割り当てられている物理サーバ９３６のメモリの割当量の変更を行う。ＤＩＳＫ割当機能９３５４は管理サーバ１００から送信された設定情報に従い、仮想サーバ９３０の仮想Ｉ／Ｏ制御装置９３４に割り当てられている物理サーバ９３６のＩ／Ｏ制御装置の割当量の変更を行う。通信割当機能９３５５は管理サーバ１００から送信された設定情報に従い、仮想サーバ９３０の仮想通信制御装置９３３に割り当てられている物理サーバ９３６の通信制御装置の割当量の変更を行う。
【０１２１】
その他の機能は前記第４実施形態と同様である。
【０１２２】
図２６は予備系ノード３００のうちひとつのノードを構成するひとつの仮想サーバ９３０に対してリソースを動的に変更して系切り替えを行うための処理手順を示すフローチャートである。この処理は、管理サーバ１００が実行系ノード２００から障害情報を受信したときに実行する。
【０１２３】
管理サーバ１００の障害情報収集機能１１１はステップ７０１において、実行系ノード２００から障害情報又はＤＢ情報を受け取る。ステップ７１１では系切り替えが発生したかどうかを障害情報を用いて判定を行い、障害情報がある場合にはステップ７０２へ進み、障害情報がない場合はそのまま処理を終了する。
【０１２４】
ステップ７０２ではＤＢ情報解析機能１３１が受け取った（または、ＤＢ情報格納部１４０から読み込んだ）ＤＢ情報の解析をＤＢ情報解析テーブル１３１を用いて行う。
【０１２５】
予備系ノード選択機能１２１はステップ７０３で障害情報から障害要因を取得し、ステップ７０４では上記ステップ７０２で取得したＤＢ解析情報とステップ７０３で取得した障害要因の情報を用いてＤＢ情報解析テーブル１３１から予備系ノードとして仮想サーバ９３０に必要なマシンスペックを算出する。
【０１２６】
ステップ７０５で予備系ノードとして必要なマシンスペックに一番性能の近い予備系ノードを予備系ノード管理テーブル１３００を用いて、系の切り替え先となる予備系ノード３００の仮想サーバ９３０を決定する。ステップ７０６においては、上記ステップ７０５で決定した予備系ノード３００の情報を予備系ノード管理テーブル１３００から削除する。次に予備系ノード起動機能１１２はステップ７０７において決定した予備系ノード３００に対して、障害が発生した実行系ノード２００のノード情報と起動通知を上記決定した予備系ノード３００へ送信する。
【０１２７】
図２７は予備系ノード３００が管理サーバ１００から予備系ノードの設定を変更する設定情報を受け取った場合の処理手順のフローチャートである。
【０１２８】
予備系ノード３００のサーバ仮想化プログラム９３５はステップ９０１において、管理サーバ１００から設定情報を受け取る。ステップ９０２において受け取った設定情報にＯＳのパラメータの内容に変更がある場合にはステップ９０３で、ＯＳのパラメータを変更して、ステップ９０４へ進む。ＯＳのパラメタ変更内容がない場合にはそのままステップ９０４へ進む。ステップ９０４では受け取った設定情報にＣＰＵ割当変更がある場合にはステップ９０５で、ＣＰＵの割当を変更して、ステップ９０６へ進む。ＣＰＵ割当変更がない場合にはそのままステップ９０６へ進む。ステップ９０６では受け取った設定情報にメモリ割当変更がある場合にはステップ９０７で、メモリの割当を変更して、ステップ９０８へ進む。メモリ割当変更がない場合にはそのままステップ９０８へ進む。ステップ９０８では受け取った設定情報にＤＩＳＫ割当変更がある場合にはステップ９０９で、ＤＩＳＫの割当を変更して、ステップ９１０へ進む。ＤＩＳＫ割当変更がない場合にはそのままステップ９１０へ進む。ステップ９１０では受け取った設定情報に通信割当変更がある場合にはステップ９１１で、通信の割当を変更して、ステップ９０１へ戻る。通信割当変更がない場合にはそのままステップ９０１へ戻る。これによって予備系ノードのリソースの動的変更処理は終了となる。
【０１２９】
以上のように、障害要因をノードの障害とデータベース管理システムの障害に切り分けて、障害の内容に応じた性能、仕様の予備系ノード３００の仮想サーバ９３０を選択してデータベースを引き継ぐことができる。また、予備系ノード管理部１２０は、ノード環境設定制御部１２３を備えることで、仮想サーバ９３０のスペック（性能及び仕様）を動的に変更することが可能となって、予備系ノード３００のリソースを効率よく利用することができる。
【０１３０】
＜第６実施形態＞
図２８は、第６の実施形態を示し、管理サーバ１００が実行系ノード２００に障害がない場合でも、系切り替えが発生したときに必要となるスペックの仮想サーバ９３０を設定しておくものである。その他の構成は前記第５実施形態と同様である。
【０１３１】
図中ステップ７０１〜７０７の処理は前記第５実施形態と同様であり、障害情報があったときに管理サーバ１００で実行される。
【０１３２】
ステップ７１１の判定で障害情報がない場合、ステップ７１２でＤＢ情報解析機能１３１が受け取ったＤＢ情報の解析をＤＢ情報解析テーブル１３１を参照して実行する。この解析は、受信したＤＢ情報のうちＤＢ情報解析テーブル１３１の閾値の所定比率（例えば、９０％）を超える実行系ノード２００の仮想サーバ９２０を障害が発生する恐れがある仮想サーバとして抽出する。次に、ＤＢ情報解析機能１３１は、抽出した仮想サーバ９２０を予備系ノード３００で引く次ぐのに必要な仮想サーバ９３０のリソース量の増分をＤＢ情報解析テーブル１３１から取得する。
【０１３３】
次に、ノード環境設定制御部１２３はステップ７１３で上記ステップ７１２で取得したリソース量の増分から上記抽出された実行系ノード２００の仮想サーバ９２０を引き継ぐことが可能な予備系ノード３００に必要なマシンスペックを算出する。
【０１３４】
次に、ステップ７１３では、ノード環境設定制御部１２３が、予備系ノード管理テーブル１３００で管理されている予備系ノード３００の中に、上記ステップ７１２の算出結果としての必要なマシンスペックに近い予備系ノードが存在するかどうかをチェックする。このチェックの結果、ノード環境設定制御部１２３は、必要なマシンスペックに近い予備系ノードがない場合は、予備系ノード３００の設定変更が必要であると判定して、ステップ７１４に進む。一方、ノード環境設定制御部１２３は、必要なマシンスペックに近い予備系ノードが存在する場合はステップ７０１に戻る。
【０１３５】
ステップ７１４では、ノード環境設定制御部１２３が、上記ステップ７１３で算出したマシンスペックと予備系ノード優先度テーブル１３０から設定を変更する予備系ノード３００の仮想サーバ９３０を選択し、変更する設定情報を予備系ノードのサーバ仮想化プログラム９３５に対して送信する。ステップ７１５では、設定情報を変更した予備系ノード３００の予備系ノード優先度テーブル１３０の情報を更新を行い、ステップ７０１に戻る。
【０１３６】
以上の処理により、管理サーバ１００の予備系ノード管理部１２０は、障害がない場合でも、データベース管理システムに障害が発生することが予測される仮想サーバ９２０を検出することができる。そして、ノード環境設定制御部１２３は、データベース管理システムの障害が予測される仮想サーバ９２０を引き継ぐことが可能な仮想サーバ９３０がなければ、予備系ノード３００の仮想化プログラム９３５に対して設定情報を送信し、障害の発生以前に必要となるスペックの仮想サーバ９３０を予備系ノード３００に設定することができる。そして、障害の発生以前に引き継ぐ仮想サーバ９３０を予め予備系ノード３００に設定しておくことで、系切り替えに要する時間を短縮することも可能となる。
【０１３７】
さらに、ＤＢ情報解析機能１３１は、ＤＢ情報解析テーブル１３１の閾値を超えないＤＢ情報のうち、閾値の所定比率を超えたＤＢ情報に対応する実行系ノード２００の仮想サーバ９２０を、障害発生の可能性がある仮想サーバとして検出することができるので、予備系ノード３００のリソースを無駄なく利用することが可能となるのである。
【０１３８】
なお、上記各実施形態では、実行系ノード２００のサーバ４２０でデータベース管理システム２２０を実行する例を示したが、サーバ４２０が提供するサービスはデータベースに限定されるものではなく、ＷＥＢサービス等を実行することができる。
【０１３９】
また、上記各実施形態では、サーバ４２０（ノード）毎にデータベース管理システム２２０を実行していたが、複数のサーバ４２０で同一の処理を並列的に実行するようにしても良い。
【産業上の利用可能性】
【０１４０】
以上のように、本発明によれば実行系ノードと予備系ノードを備えて、実行系ノードの障害時に予備系ノードへ切り換える計算機システムに適用することができる。
【図面の簡単な説明】
【０１４１】
【図１】第１の実施形態を示し、本発明を適用する計算機システムのブロック図。
【図２】図１の計算機システムで実行されるデータベース管理システムのソフトウェア構成を示すブロック図である。
【図３】実行系ノードの各機能要素をさらに詳細に示すブロック図である。
【図４】管理サーバの各機能要素の詳細を示すブロック図である。
【図５】予備系ノードの各機能要素の詳細を示すブロック図である。
【図６】予備系ノードＡ〜Ｃの性能差を示す説明図である。
【図７】予備系ノードを管理する予備系ノード優先度テーブルの構成例を示す説明図である。
【図８】実行系ノードで行われる障害が発生した場合の処理手順のフローチャートである。
【図９】管理サーバが実行系ノードから障害情報を受け取った場合の処理手順のフローチャートである。
【図１０】予備系ノードが管理サーバからノード情報と起動通知を受け取った場合の処理手順のフローチャートである。
【図１１】実行系ノードで障害が発生した場合の系切り換え処理を示すブロック図。
【図１２】第２の実施形態を示しデータベース管理システムのうち実行系ノードと管理サーバを示すブロック図である。
【図１３】第３の実施形態を示しデータベース管理システムの構成を示すブロック図である。
【図１４】第４の実施形態を示し、図１の計算機システムで実行されるデータベース管理システムのソフトウェア構成を示すブロック図である。
【図１５】実行系ノードの各機能要素をさらに詳細に示すブロック図である。
【図１６】管理サーバの各機能要素の詳細を示すブロック図である。
【図１７】予備系ノードの各機能要素の詳細を示すブロック図である。
【図１８】予備系ノードを管理する予備系ノード管理テーブルの構成例を示す説明図である。
【図１９】ＤＢ情報から必要なリソースとそのリソース量を解析するために利用するＤＢ情報解析テーブルの構成例を示す説明図である。
【図２０】実行系ノードで行われる障害が発生した場合の処理手順のフローチャートである。
【図２１】管理サーバが実行系ノードから障害情報を受け取った場合の処理手順のフローチャートである。
【図２２】予備系ノードが管理サーバからノード情報と起動通知を受け取った場合の処理手順のフローチャートである。
【図２３】第５の実施形態を示し、本発明を適用する計算機システムのブロック図。
【図２４】管理サーバの各機能要素の詳細を示すブロック図である。
【図２５】予備系ノードの各機能要素の詳細を示すブロック図である。
【図２６】管理サーバが予備系ノードのリソースを動的に変更する場合の処理手順のフローチャートである。
【図２７】予備系ノードが管理サーバからリソースの変更を通知してきた場合の処理手順のフローチャートである。
【図２８】第６の実施形態を示し、管理サーバが予備系ノードのリソースを動的に変更する場合の処理手順のフローチャートである。
【符号の説明】
【０１４２】
１００  管理サーバ
２００  実行系ノード
３００  予備系ノード
４２０、４３０  サーバ
２１０、３１０  障害検知部
１１０  障害監視部
１２０  予備系ノード監視部
１３０  予備系ノード優先度テーブル
２２０、３２０  データベース管理システム
４００  データベース
９２０、９３０  仮想サーバ
９２５、９３５  サーバ仮想化プログラム
９２６、９３６  物理サーバ
【図１】
2007207219.tif 000003
【図２】
2007207219.tif 000004
【図３】
2007207219.tif 000005
【図４】
2007207219.tif 000006
【図５】
2007207219.tif 000007
【図６】
2007207219.tif 000008
【図７】
2007207219.tif 000009
【図８】
2007207219.tif 000010
【図９】
2007207219.tif 000011
【図１０】
2007207219.tif 000012
【図１１】
2007207219.tif 000013
【図１２】
2007207219.tif 000014
【図１３】
2007207219.tif 000015
【図１４】
2007207219.tif 000016
【図１５】
2007207219.tif 000017
【図１６】
2007207219.tif 000018
【図１７】
2007207219.tif 000019
【図１８】
2007207219.tif 000020
【図１９】
2007207219.tif 000021
【図２０】
2007207219.tif 000022
【図２１】
2007207219.tif 000023
【図２２】
2007207219.tif 000024
【図２３】
2007207219.tif 000025
【図２４】
2007207219.tif 000026
【図２５】
2007207219.tif 000027
【図２６】
2007207219.tif 000028
【図２７】
2007207219.tif 000029
【図２８】
2007207219.tif 000030