JP5965781B2 - リソース管理装置、リソース管理方法およびプログラム - Google Patents

Description

本発明は、リソース管理装置、リソース管理方法およびプログラムに関する。

従来、災害発生時に複数のデータセンタに予め備えてある復旧用リソースを用いてアプリケーションシステムを復旧するディザスタリカバリシステムがある。このようなディザスタリカバリシステムには、災害が発生していない平常時において、アプリケーションシステムが利用するデータを記憶させるリカバリ用データセンタを予め選択しておくものがある。

特開２０１１−１５０４５９号公報

しかしながら、上述のような従来のディザスタリカバリシステムにおいては、選択したリカバリ用データセンタの環境や動作状況によっては、平常時のアプリケーションシステムの性能が低下してしまうことがあるという問題があった。

本発明は、このような状況に鑑みてなされたもので、アプリケーションシステムの性能が低下する程度を低減させることができるリソース管理装置、リソース管理方法およびプログラムを提供する。

上述した課題を解決するために、本発明は、ネットワークを介して接続される複数のデータ記憶装置にデータを記憶させて、当該データを利用するアプリケーションシステムの障害復旧を可能にするディザスタリカバリシステムのリソースを管理するリソース管理装置であって、前記アプリケーションシステムの障害復旧に必要なリソースを示す要求リソース情報を取得する要求リソース情報取得部と、前記データ記憶装置が提供可能なリソースを示す提供可能リソース情報を取得する提供可能リソース情報取得部と、前記データ記憶装置との通信を行う前記ネットワークの遅延状況を示す遅延情報を取得する遅延情報取得部と、取得された前記要求リソース情報と、前記提供可能リソース情報と、前記遅延情報とに基づいて、複数の前記データ記憶装置の中から前記アプリケーションシステムが利用する前記データを記憶させるデータ記憶装置を選択する選択部と、前記選択部が選択した前記データ記憶装置に、前記アプリケーションシステムが利用する前記データを送信する送信部とを備え、前記選択部は、前記要求リソース情報、前記提供可能リソース情報、または前記遅延情報のうち、少なくともいずれかの情報に変化が生じた場合に、前記データを記憶させるデータ記憶装置の選択を開始することを特徴とするリソース管理装置である。

また、本発明は、上記のリソース管理装置において、前記要求リソース情報には、前記データ記憶装置に対する前記データの書き込み遅延の程度を示す書込遅延情報が含まれ、前記選択部は、取得された前記要求リソース情報が示すリソースと、取得された前記提供可能リソース情報が示すリソースとを比較した結果と、当該要求リソース情報に含まれる前記書込遅延情報と、取得された前記遅延情報とを比較した結果とに基づいて、複数の前記データ記憶装置の中から前記アプリケーションシステムが利用する前記データを記憶させるデータ記憶装置を選択することを特徴とする。

また、本発明は、ネットワークを介して接続される複数のデータ記憶装置にデータを記憶させて、当該データを利用するアプリケーションシステムの障害復旧を可能にするディザスタリカバリシステムのリソースを管理するリソース管理装置を用いたリソース管理方法であって、前記リソース管理装置が備える要求リソース情報取得部が、前記アプリケーションシステムの障害復旧に必要なリソースを示す要求リソース情報を取得する要求リソース情報取得ステップと、前記リソース管理装置が備える提供可能リソース情報取得部が、前記データ記憶装置が提供可能なリソースを示す提供可能リソース情報を取得する提供可能リソース情報取得ステップと、前記リソース管理装置が備える遅延情報取得部が、前記データ記憶装置との通信を行う前記ネットワークの遅延状況を示す遅延情報を取得する遅延情報取得ステップと、前記リソース管理装置が備える選択部が、取得された前記要求リソース情報と、前記提供可能リソース情報と、前記遅延情報とに基づいて、複数の前記データ記憶装置の中から前記アプリケーションシステムが利用する前記データを記憶させるデータ記憶装置を選択する選択ステップと、前記リソース管理装置が備える送信部が、前記選択ステップによって選択された前記データ記憶装置に、前記アプリケーションシステムが利用する前記データを送信する送信ステップと、を備え、前記選択ステップでは、前記要求リソース情報、前記提供可能リソース情報、または前記遅延情報のうち、少なくともいずれかの情報に変化が生じた場合に、前記データを記憶させるデータ記憶装置の選択を開始することを特徴とするリソース管理方法である。

また、本発明は、ネットワークを介して接続される複数のデータ記憶装置にデータを記憶させて、当該データを利用するアプリケーションシステムの障害復旧を可能にするディザスタリカバリシステムのリソースを管理するリソース管理装置のコンピュータに、前記コンピュータが備える要求リソース情報取得部が、前記アプリケーションシステムの障害復旧に必要なリソースを示す要求リソース情報を取得する要求リソース情報取得ステップと、前記コンピュータが備える提供可能リソース情報取得部が、前記データ記憶装置が提供可能なリソースを示す提供可能リソース情報を取得する提供可能リソース情報取得ステップと、前記コンピュータが備える遅延情報取得部が、前記データ記憶装置との通信を行う前記ネットワークの遅延状況を示す遅延情報を取得する遅延情報取得ステップと、前記コンピュータが備える選択部が、取得された前記要求リソース情報と、前記提供可能リソース情報と、前記遅延情報とに基づいて、複数の前記データ記憶装置の中から前記アプリケーションシステムが利用する前記データを記憶させるデータ記憶装置を選択する選択ステップと、前記コンピュータが備える送信部が、前記選択ステップによって選択された前記データ記憶装置に、前記アプリケーションシステムが利用する前記データを送信する送信ステップと、を実行させるためのプログラムであり、前記選択ステップでは、前記要求リソース情報、前記提供可能リソース情報、または前記遅延情報のうち、少なくともいずれかの情報に変化が生じた場合に、前記データを記憶させるデータ記憶装置の選択を開始することを特徴とするプログラムである。

以上説明したように、本発明によれば、アプリケーションシステムの性能が低下する程度を低減させることができるリソース管理装置、リソース管理方法およびプログラムを提供することができる。

本発明の第１の実施形態におけるディザスタリカバリシステムの概要を示す構成図である。 本実施形態におけるアプリケーションシステムの配置の一例を示す模式図である。 本実施形態におけるディザスタリカバリシステムの構成の一例を示す構成図である。 本実施形態におけるディザスタリカバリシステムの動作の一例を示すフローチャートである。 本実施形態の要求リソース情報の一例を示す図である。 本実施形態の残リソーステーブルの一例を示す図である。 本実施形態のリカバリ先登録済みリソーステーブルの一例を示す図である。 本実施形態のバッファリソーステーブルの一例を示す図である。 本実施形態の提供可能リソーステーブルの一例を示す図である。 本実施形態におけるディザスタリカバリシステムの同期情報の転送動作の一例を示すフローチャートである。 本実施形態におけるネットワーク遅延テーブルの一例を示す図である。 本実施形態におけるディスク書き込み待ち率の一例を示す図である。 本実施形態におけるディザスタリカバリシステムのリソース監視動作の一例を示すフローチャートである。 本発明の第２の実施形態におけるディザスタリカバリシステムの構成の一例を示す構成図である。 本実施形態におけるディザスタリカバリシステムのリカバリ先データセンタＤＣの変更動作の一例を示すフローチャートである。

＜第１の実施形態＞
以下、本発明の第１の実施形態について、図面を参照して説明する。
図１は、本発明の第１の実施形態におけるディザスタリカバリシステム１の概要を示す構成図である。同図に示すようにディザスタリカバリシステム１は、複数のデータセンタＤＣがＩＰネットワークであるネットワーク５を介して接続されてなる。このデータセンタＤＣには、リカバリ元データセンタＤＣ−Ａ、および第１リカバリ先データセンタＤＣ−Ｂ〜第ｎリカバリ先データセンタＤＣ−ｎ（ｎは自然数。）が含まれる。なお、これら第１リカバリ先データセンタＤＣ−Ｂ、および第１リカバリ先データセンタＤＣ−Ｂ〜第ｎリカバリ先データセンタＤＣ−ｎの構成は同一であるため、以下、これらを区別しない場合には、リカバリ先データセンタＤＣと総称して説明する。一般にディザスタリカバリシステムとは、当該ディザスタリカバリシステムに含まれるデータセンタＤＣのうちの、１つまたは複数のデータセンタＤＣが災害等の障害により使用できなくなった場合に、使用可能な他のデータセンタＤＣを使用することにより、当該ディザスタリカバリシステムを利用するアプリケーションシステムを継続的に動作させる仕組みである。ここで、アプリケーションシステムとは、コンピュータの利用者がコンピュータ上で実現したい機能を、当該利用者に提供するソフトウエアを動作させるコンピュータシステムである。

このディザスタリカバリシステム１の概要について説明する。ディザスタリカバリシステム１は、リカバリ元データセンタＤＣ−Ａにおいて動作するアプリケーションシステムが利用するリソースを、他のデータセンタＤＣ（例えば、リカバリ先データセンタＤＣ−Ｂ）に確保する。ここでリソースとは、アプリケーションシステムが使用するデータを記憶させる記憶装置（例えば、半導体メモリやハードディスク）や、アプリケーションシステムを構成するソフトウエアを動作させるＣＰＵ（Central Processing Unit）など、アプリケーションシステムの動作に必要なコンピュータ資源である。ディザスタリカバリシステム１は、リカバリ元データセンタＤＣ−Ａにおいてアプリケーションシステムが生成したデータをリカバリ元データセンタＤＣ−Ａのデータ記憶部に記憶させる。また、ディザスタリカバリシステム１は、リカバリ先データセンタＤＣ−Ｂに確保したリソースを利用して、リカバリ元データセンタＤＣ−Ａのデータ記憶部に記憶させたデータと同一のデータを、ネットワーク５を介して送信し、リカバリ先データセンタＤＣ−Ｂのデータ記憶部に記憶させる。つまり、ディザスタリカバリシステム１は、アプリケーションシステムが生成したデータを、リカバリ元データセンタＤＣ−Ａのデータ記憶部と、リカバリ先データセンタＤＣ−Ｂのデータ記憶部とに記憶させる。これにより、ディザスタリカバリシステム１は、リカバリ元データセンタＤＣ−Ａにアプリケーションシステムを動作させることができない障害が発生した場合に、リカバリ先データセンタＤＣ−Ｂにおいてアプリケーションシステムを動作させることができる。このようにして、ディザスタリカバリシステム１は、リカバリ元データセンタＤＣ−Ａが使用できなくなった場合においても、アプリケーションシステムを継続的に動作させる。すなわち、ディザスタリカバリシステム１は、ネットワーク５を介して接続される複数のデータセンタＤＣが備えるデータ記憶装置にデータを記憶させて、当該データを利用するアプリケーションシステムの障害復旧を可能にする。

このディザスタリカバリシステム１の各データセンタＤＣに対するアプリケーションシステム２の配置の一例について、図２を参照して説明する。
図２は、本実施形態におけるアプリケーションシステム２の配置の一例を示す模式図である。同図に示すように、各リカバリ先データセンタＤＣは、１または複数の物理サーバを備えている。例えば、第１リカバリ先データセンタＤＣ−Ｂは、物理サーバ２１０Ａ、物理サーバ２１０Ｂおよび物理サーバ２１０Ｃを備えている。同様に、第２リカバリ先データセンタＤＣ−Ｃは、物理サーバ２２０Ａ、物理サーバ２２０Ｂおよび物理サーバ２２０Ｃを備えている。ディザスタリカバリシステム１のリカバリ対象のアプリケーションシステム２は、これらの物理サーバのうち、いずれか１つまたは複数の物理サーバをリカバリ先にして配置される。また、ディザスタリカバリシステム１のリカバリ対象のアプリケーションシステム２には、一例として、アプリケーションシステム２Ａと、アプリケーションシステム２Ｂとが含まれている。リカバリ元データセンタＤＣ−Ａは、アプリケーションシステム２Ａと、アプリケーションシステム２Ｂとを動作させて、利用者に各アプリケーションシステムを提供する。ディザスタリカバリシステム１は、アプリケーションシステム２Ａと、アプリケーションシステム２Ｂとのリカバリ先データセンタＤＣとして、第１リカバリ先データセンタＤＣ−Ｂを選択する。このうち、アプリケーションシステム２Ａは、第１リカバリ先データセンタＤＣ−Ｂの物理サーバ２１０ＡおよびＣに配置される。また、アプリケーションシステム２Ｂは、第１リカバリ先データセンタＤＣ−Ｂの物理サーバ２１０Ｂに配置される。以下、ディザスタリカバリシステム１が各アプリケーションシステム２の配置先にするリカバリ先データセンタＤＣを選択する仕組みについて説明する。

図３は、本実施形態におけるディザスタリカバリシステム１の構成の一例を示す構成図である。ディザスタリカバリシステム１は、上述したようにリカバリ元データセンタＤＣ−Ａと、リカバリ先データセンタＤＣとを備えている。まず、このうちリカバリ先データセンタＤＣの構成について説明する。リカバリ先データセンタＤＣには、上述したように第１リカバリ先データセンタＤＣ−Ｂと、第２リカバリ先データセンタＤＣ−Ｃとが含まれる。

第１リカバリ先データセンタＤＣ−Ｂは、複数の物理サーバ２１０と、通信部２１１と、第１リソース管理部２１５とを備えている。

通信部２１１は、リカバリ元データセンタＤＣ−Ａからネットワーク５を介して供給されるデータを受信するとともに、ネットワーク５を介してリカバリ元データセンタＤＣ−Ａにデータを送信する。このリカバリ元データセンタＤＣ−Ａからネットワーク５を介して供給されるデータには、後述する同期情報が含まれている。また、ネットワーク５を介してリカバリ元データセンタＤＣ−Ａに送信されるデータには、第１リソース管理部２１５が管理する第１リカバリ先データセンタＤＣ−Ｂが提供可能なリソースを示す提供可能リソース情報が含まれている。

物理サーバ２１０は、アプリケーションシステム２が生成するデータを記憶する。具体的には、物理サーバ２１０は、アプリケーションシステム２によって生成されたデータであって、リカバリ元データセンタＤＣ−Ａからネットワーク５および通信部２１１を介して第１リカバリ先データセンタＤＣ−Ｂに供給されるデータを記憶する。第１リカバリ先データセンタＤＣ−Ｂは、複数の物理サーバ２１０として、物理サーバ２１０Ａ、物理サーバ２１０Ｂ、および物理サーバ２１０Ｃを備えている。これら物理サーバ２１０Ａ、物理サーバ２１０Ｂ、および物理サーバ２１０Ｃの構成は同一であるため、以下、これらを区別しない場合には、物理サーバ２１０と総称して説明する。物理サーバ２１０は、不図示のＣＰＵと、メモリと、ハードディスクとを備えている。物理サーバ２１０は、通信部２１１から供給されるデータをＣＰＵによって取得し、取得したデータをメモリおよびハードディスクに書き込む。また、物理サーバ２１０は、メモリおよびハードディスクに書き込まれているデータをＣＰＵによって読み出し、読み出したデータを通信部２１１に供給する。

第１リソース管理部２１５は、第１リカバリ先データセンタＤＣ−Ｂが提供可能なリソースを管理するとともに、管理した結果に基づいて、当該提供可能なリソースを示す提供可能リソース情報を生成する。具体的には、第１リソース管理部２１５は、複数の物理サーバ２１０のそれぞれが備えるＣＰＵ、メモリ、およびハードディスクのリソースのうち、未使用のリソースを管理する。より具体的には、第１リソース管理部２１５は、各物理サーバ２１０が備えるＣＰＵコア数のうち、使用されていないＣＰＵコア数を、自身が備える記憶部の残リソーステーブルに記憶する。また、第１リソース管理部２１５は、各物理サーバ２１０が備えるメモリの記憶量のうち、使用されていないメモリ記憶量を、自身が備える記憶部の残リソーステーブルに記憶する。また、第１リソース管理部２１５は、各物理サーバ２１０が備えるハードディスクの記憶量のうち、使用されていない記憶量を、自身が備える記憶部の残リソーステーブルに記憶する。この残リソーステーブルについては、後述する。

第１リカバリ先データセンタＤＣ−Ｂと同様にして、第２リカバリ先データセンタＤＣ−Ｃは、複数の物理サーバ２２０と、通信部２２１と、第２リソース管理部２２５とを備えている。また、第２リカバリ先データセンタＤＣ−Ｃは、複数の物理サーバ２２０として、物理サーバ２２０Ａ、物理サーバ２２０Ｂ、および物理サーバ２２０Ｃを備えている。これら物理サーバ２２０Ａ、物理サーバ２２０Ｂ、および物理サーバ２２０Ｃの構成は同一であるため、以下、これらを区別しない場合には、物理サーバ２２０と総称して説明する。また、通信部２２１、および第２リソース管理部２２５は、それぞれ通信部２１１および第１リソース管理部２１５と同様の構成であるため、説明を省略する。

次に、リカバリ元データセンタＤＣ−Ａの構成について説明する。リカバリ元データセンタＤＣ−Ａは、アプリケーションシステム２と、リカバリ元データ記憶部３と、リソース管理装置１００と、同期情報取得部１０６とを備えている。このリカバリ元データ記憶部３には、アプリケーションシステム２が生成したデータが記憶される。

アプリケーションシステム２とは、ディザスタリカバリシステム１がリカバリ対象とする、例えば、アプリケーションシステム２Ａおよびアプリケーションシステム２Ｂである。アプリケーションシステム２は、自身が動作させるソフトウエアによって生成したデータを、リカバリ元データ記憶部３に記憶させる。また、アプリケーションシステム２は、アプリケーションシステム２が要求するリソースを示す、要求リソース情報を出力する。この要求リソース情報については、後述する。

同期情報取得部１０６は、アプリケーションシステム２がリカバリ元データ記憶部３に記憶させる同期情報を取得する。ここで、同期情報とは、アプリケーションシステム２が生成したデータであり、ディザスタリカバリシステム１がリカバリ対象とするデータである。

リソース管理装置１００は、要求リソース情報取得部１０１と、提供可能リソース情報取得部１０２と、遅延情報取得部１０３と、選択部１０４と、通信部（送信部）１０５とを備えている。
要求リソース情報取得部１０１は、アプリケーションシステム２の障害復旧に必要なリソースを示す要求リソース情報を取得する。具体的には、要求リソース情報取得部１０１は、アプリケーションシステム２が出力する要求リソース情報を取得する。

提供可能リソース情報取得部１０２は、リカバリ先データセンタＤＣ（データ記憶装置）の物理サーバ２１０が提供可能なリソースを示す提供可能リソース情報を取得する。具体的には、提供可能リソース情報取得部１０２は、第１リカバリ先データセンタＤＣ−Ｂの第１リソース管理部２１５が生成する提供可能リソース情報を、通信部２１１、ネットワーク５および通信部１０５を介して取得する。また、提供可能リソース情報取得部１０２は、第２リカバリ先データセンタＤＣ−Ｃの第２リソース管理部２２５が生成する提供可能リソース情報を、通信部２２１、ネットワーク５および通信部１０５を介して取得する。このようにして、提供可能リソース情報取得部１０２は、各リカバリ先データセンタＤＣから提供可能リソース情報を取得する。

遅延情報取得部１０３は、リカバリ先データセンタＤＣ（データ記憶装置）の物理サーバ２１０との通信を行うネットワーク５の遅延状況を示す遅延情報を取得する。具体的には、遅延情報取得部１０３は、リカバリ元データセンタＤＣ−Ａの通信部１０５と、第１リカバリ先データセンタＤＣ−Ｂの通信部２１１との間のネットワーク５の遅延時間を算出し、算出した遅延時間を遅延情報として取得する。例えば、遅延情報取得部１０３は、所定の間隔（例えば、１時間毎）により、リカバリ元データセンタＤＣ−Ａの通信部１０５から、各リカバリ先データセンタＤＣに対して、ネットワーク５を介した情報の到達性を確認する通信（例えば、ｐｉｎｇ）を行うことにより、遅延時間を算出し、算出した遅延時間を遅延情報として取得する。なお、第１リカバリ先データセンタＤＣ−Ｂとの間の遅延時間の算出について、遅延情報取得部１０３は、リカバリ元データセンタＤＣ−Ａの通信部１０５がネットワーク５に情報（例えば、同期情報）を送信してから、第１リカバリ先データセンタＤＣ−Ｂの通信部２１１から当該同期情報の書込み完了を示す情報を受信するまでの時間を計測して、ネットワーク５の遅延時間を算出してもよい。この場合には、第１リカバリ先データセンタＤＣ−Ｂの通信部２１１は、第１リカバリ先データセンタＤＣ−Ｂからネットワーク５を介して受信した同期情報が物理サーバ２１０に書き込まれたことを示す情報（例えば、同期情報の書込み完了を示す情報）を、物理サーバ２１０から取得する。次に、通信部２１１は、取得した同期情報の書込み完了を示す情報を、ネットワーク５を介してリカバリ元データセンタＤＣ−Ａに送信する。遅延情報取得部１０３は、このようにして取得した同期情報の書込み完了を示す情報に基づいて、ネットワーク５の遅延状況を示す遅延情報を取得する。

また、遅延情報取得部１０３は、第１リカバリ先データセンタＤＣ−Ｂの場合と同様にして、第２リカバリ先データセンタＤＣ−Ｃの通信部２１１との間のネットワーク５の遅延時間に基づく遅延情報を取得する。すなわち、リカバリ元データセンタＤＣ−Ａの通信部１０５と、第２リカバリ先データセンタＤＣ−Ｃの通信部２１１との間のネットワーク５の遅延時間を算出し、算出した遅延時間を遅延情報として取得する。

選択部１０４は、取得された要求リソース情報と、提供可能リソース情報と、遅延情報とに基づいて、複数のリカバリ先データセンタＤＣ（データ記憶装置）の中からアプリケーションシステム２が利用するデータ（例えば、同期情報）を記憶させるリカバリ先データセンタＤＣ（データ記憶装置）を選択する。具体的には、選択部１０４は、取得された要求リソース情報が示すリソースと、取得された提供可能リソース情報が示すリソースとを比較した結果に基づいて、複数のリカバリ先データセンタＤＣの中から、アプリケーションシステム２が利用する同期情報を記憶させるリカバリ先データセンタＤＣの候補を抽出する。このとき選択部１０４は、要求リソース情報が示すリソースに比して、提供可能リソース情報が示すリソースが大きいリカバリ先データセンタＤＣを、アプリケーションシステム２が利用する同期情報を記憶させるリカバリ先データセンタＤＣの候補として抽出する。次に、選択部１０４は、要求リソース情報と、取得された遅延情報とを比較した結果に基づいて、抽出したリカバリ先データセンタＤＣの候補の中から、アプリケーションシステム２が利用する同期情報を記憶させるリカバリ先データセンタＤＣを選択する。ここで、要求リソース情報には、リカバリ先データセンタＤＣに対するデータ（例えば、同期情報）の書き込み遅延の程度を示す書込遅延情報（例えば、ディスク書き込み待ち率）が含まれている。このディスク書き込み待ち率とは、アプリケーションシステム２が同期情報を生成した回数に対する、生成した同期情報の転送が待たされた回数の割合である。ここでいう同期情報の転送とは、同期情報をリカバリ元データセンタＤＣ−Ａからリカバリ先データセンタＤＣに送信して、送信した同期情報をリカバリ先データセンタＤＣにおいて記憶させることである。このディスク書き込み待ち率の算出は、アプリケーションシステム２において行われる。アプリケーションシステム２は、前回生成した同期情報の転送動作が完了する前に、同期情報を新たに生成したことにより、新たに生成した同期情報の転送動作が待たされたか否かに基づいて、ディスク書き込み待ち率を算出する。そしてアプリケーションシステム２は、算出したディスク書き込み率を、不図示の記憶部が有するディスク書き込み待ち率テーブルに記憶させる。アプリケーションシステム２は、ディスク書き込み待ち率テーブルに記憶させたディスク書き込み待ち率を、要求リソース情報に含めて選択部１０４に出力する。このディスク書き込み待ち率テーブルの詳細については後述する。

次に、選択部１０４は、要求リソース情報に含まれるディスク書き込み待ち率の大きさを、各アプリケーションシステム間（例えば、アプリケーションシステム２Ａ、およびアプリケーションシステム２Ｂ）において比較する。次に、選択部１０４は、比較した結果と、取得した遅延情報とに基づいて、アプリケーションシステム２のリカバリ先データセンタＤＣを選択する。より具体的には、選択部１０４は、ディスク書き込み待ち率が相対的に大きいアプリケーションシステム２（例えば、アプリケーション２Ａ）のリカバリ先データセンタＤＣとして、遅延情報が示すネットワーク５の遅延時間が相対的に短いリカバリ先データセンタＤＣ（例えば、第１リカバリ先データセンタＤＣ−Ｂ）を選択する。すなわち、選択部１０４は、取得された要求リソース情報が示すリソースと、取得された提供可能リソース情報が示すリソースとを比較した結果と、要求リソース情報に含まれる書込遅延情報と、取得された遅延情報とを比較した結果とに基づいて、複数のリカバリ先データセンタＤＣの中からアプリケーションシステムが利用するデータを記憶させるリカバリ先データセンタＤＣを選択する。なお、ここでは、アプリケーションシステム２は、ディスク書き込み待ち率を実測によって算出しているが、これに限られない。例えば、アプリケーションシステム２は、アプリケーションシステム２の規模や、アプリケーションシステム２の利用者数、アプリケーションシステム２が利用者に利用される頻度（例えば、単位時間当たりのページビュー）に基づいて、ディスク書き込み待ち率を推定してもよい。また、例えば、アプリケーションシステム２は、ディスク書き込み待ち率をＯＳ（Operating System）から取得してもよい。ここで、例えば、ＯＳがＬｉｎｕｘ（登録商標）である場合には、アプリケーションシステム２は、ｉｏｓｔａｔやｖｍｓｔａｔといったコマンドのｉｏｗａｉｔをディスク書き込み待ち率として使用してもよい。

通信部（送信部）１０５は、選択部１０４が選択したリカバリ先データセンタＤＣ（データ記憶装置）に、アプリケーションシステム２が利用するデータ（例えば、同期情報）を送信する。このようにして、ディザスタリカバリシステム１は、アプリケーションシステム２が生成したデータ（例えば、同期情報）を、リカバリ元データ記憶部３に記憶させるとともに、選択部１０４が選択したリカバリ先データセンタＤＣ（データ記憶装置）に記憶させる。

次に、図４を参照して、ディザスタリカバリシステム１の動作について説明する。
図４は、本実施形態におけるディザスタリカバリシステム１の動作の一例を示すフローチャートである。ここでは、一例として、アプリケーションシステム２Ｂのリカバリ先データセンタを選択する動作について説明する。

まず、アプリケーションシステム２Ｂは、リソース管理装置１００に対してリソース確保通知を出力する（ステップＳ２−１０）。ここで、リソース確保通知とは、アプリケーションシステム２Ｂが要求するリソースをリカバリ先データセンタＤＣに確保するためにアプリケーションシステム２Ｂからリソース管理装置１００に対して出力される情報である。このリソース確保通知には、アプリケーションシステム２Ｂが要求するリソースを示す要求リソース情報が含まれている。具体的には、アプリケーションシステム２Ｂは、リソース管理装置１００に対してアプリケーションシステム２Ｂのリソース確保通知を出力する。このアプリケーションシステム２Ｂのリソース確保通知には、アプリケーションシステム２Ｂが要求するリソースの一例として、ＣＰＵ”２ｃｏｒｅ”、メモリ（Ｍｅｍ）”４ＧＢ”、ハードディスク（Ｄｉｓｃ）”１００ＧＢ”を示す要求リソース情報が含まれている。

次に、リソース管理装置１００の要求リソース情報取得部１０１は、アプリケーションシステム２Ｂから出力されるリソース確保通知を取得する（ステップＳ１００−１０）。上述したように、このリソース確保通知には、要求リソース情報が含まれている。要求リソース情報取得部１０１は、取得した要求リソース情報を不図示の記憶部に記憶させる。この要求リソース情報取得部１０１が取得する要求リソース情報について図５を参照して説明する。

図５は、本実施形態の要求リソース情報取得部１０１が記憶させる要求リソース情報の一例を示す図である。要求リソース情報とは、アプリケーションシステム２の名称を示すアプリケーションシステム名と、当該アプリケーションシステム２が要求するリソースの量を示す情報とが関連付けられている情報である。具体的には、要求リソース情報を記憶する記憶部には、アプリケーションシステム名”アプリケーションシステム２Ａ”と、要求するリソースの量としてのＣＰＵ”４ｃｏｒｅ”と、メモリ（Ｍｅｍ）”１６ＧＢ”と、ハードディスク（Ｄｉｓｃ）”３０ＧＢ”とが関連付けられて記憶されている。また、アプリケーションシステム名”アプリケーションシステム２Ａ”と、要求するリソースの量としてのＣＰＵ”１ｃｏｒｅ”と、メモリ（Ｍｅｍ）”８ＧＢ”と、ハードディスク（Ｄｉｓｃ）”６０ＧＢ”とが関連付けられて記憶されている。また、アプリケーションシステム名”アプリケーションシステム２Ｂ”と、要求するリソースの量としてのＣＰＵ”１ｃｏｒｅ”と、メモリ（Ｍｅｍ）”２ＧＢ”と、ハードディスク（Ｄｉｓｃ）”５０ＧＢ”とが関連付けられて記憶されている。

再び、図４を参照してディザスタリカバリシステム１の動作について説明する。リソース管理装置１００は、各リカバリ先データセンタＤＣに対して、提供可能リソース情報送信要求を送信する（ステップＳ１００−２０）。ここで、提供可能リソース情報送信要求とは、リカバリ先データセンタＤＣがアプリケーションシステム２に提供することが可能なリソースを示す情報を、リソース管理装置１００に対して送信することをリカバリ先データセンタＤＣに対して要求する情報である。

次に、各リカバリ先データセンタＤＣは、提供可能リソース情報送信要求を受信すると、提供可能リソース情報を送信する。具体的には、第１リカバリ先データセンタＤＣ−Ｂは、リソース管理装置１００から提供可能リソース情報送信要求を受信すると、第１リソース管理部２１５が生成する提供可能リソース情報を、リソース管理装置１００に対して送信する（ステップＳ２１−１０）。また、第２リカバリ先データセンタＤＣ−Ｃは、リソース管理装置１００から提供可能リソース情報送信要求を受信すると、第２リソース管理部２２５が生成する提供可能リソース情報を、リソース管理装置１００に対して送信する（ステップＳ２２−１０）。ここで、一例として、第１リソース管理部２１５が提供可能リソース情報を生成する仕組みについて、図６から図８を参照して説明する。

図６は、本実施形態の第１リソース管理部２１５が記憶する残リソーステーブルの一例を示す図である。第１リソース管理部２１５は、各物理サーバ２１０が備えるリソースのうち、使用されていないＣＰＵコア数と、メモリの記憶量と、ハードディスクの記憶量とを不図示の記憶部が有する残リソーステーブルに記憶させる。具体的には、第１リソース管理部２１５は、物理サーバ名”物理サーバ２１０Ａ”と、ＣＰＵコア数”１２ｃｏｒｅ”と、メモリ（Ｍｅｍ）の記憶量”２０ＧＢ”と、ハードディスク（Ｄｉｓｃ）の記憶量”１００ＧＢ”とを関連付けて、不図示の記憶部が有する残リソーステーブルに記憶させる。また、第１リソース管理部２１５は、物理サーバ２１０Ｂの残リソースとして、物理サーバ名”物理サーバＢ”と、ＣＰＵコア数”２ｃｏｒｅ”と、メモリ（Ｍｅｍ）の記憶量”３ＧＢ”と、ハードディスク（Ｄｉｓｃ）の記憶量”６０ＧＢ”とを関連付けて、不図示の記憶部が有する残リソーステーブルに記憶させる。同様に、第１リソース管理部２１５は、物理サーバ名”物理サーバ２１０Ｃ”と、ＣＰＵコア数”４ｃｏｒｅ”と、メモリ（Ｍｅｍ）の記憶量”１６ＧＢ”と、ハードディスク（Ｄｉｓｃ）の記憶量”９０ＧＢ”とを関連付けて、不図示の記憶部が有する残リソーステーブルに記憶させる。

次に、図７を参照して本実施形態の第１リソース管理部２１５が記憶するリカバリ先登録済みリソーステーブルの一例について説明する。
図７は、本実施形態の第１リソース管理部２１５が記憶するリカバリ先登録済みリソーステーブルの一例を示す図である。第１リソース管理部２１５は、物理サーバ名と、アプリケーションシステム名と、各物理サーバ２１０が備えるリソースのうちアプリケーションシステム２がリカバリ先として登録しているＣＰＵコア数と、メモリの記憶量と、ハードディスクの記憶量とを関連付けて、不図示の記憶部が有するリカバリ先登録済みリソーステーブルに記憶させる。具体的には、第１リソース管理部２１５は、物理サーバ名”物理サーバ２１０Ａ”と、アプリケーションシステム名“アプリケーションシステム２Ａ”と、ＣＰＵコア数”１ｃｏｒｅ”と、メモリ（Ｍｅｍ）の記憶量”２ＧＢ”と、ハードディスク（Ｄｉｓｃ）の記憶量”１０ＧＢ”とを関連付けて、不図示の記憶部が有するリカバリ先登録済みリソーステーブルに記憶させる。また、第１リソース管理部２１５は、物理サーバ名”物理サーバＢ”と、アプリケーションシステム名“登録なし”と、ＣＰＵコア数”０ｃｏｒｅ”と、メモリ（Ｍｅｍ）の記憶量”０ＧＢ”と、ハードディスク（Ｄｉｓｃ）の記憶量”０ＧＢ”とを関連付けて、不図示の記憶部が有するリカバリ先登録済みリソーステーブルに記憶させる。ここで、アプリケーションシステム名“登録なし”とは、物理サーバ２１０Ｂに登録されているアプリケーションシステム２が存在していないことを示す。同様に、第１リソース管理部２１５は、物理サーバ名”物理サーバ２１０Ｃ”と、アプリケーションシステム名“アプリケーションシステム２Ａ”と、ＣＰＵコア数”２ｃｏｒｅ”と、メモリ（Ｍｅｍ）の記憶量”４ＧＢ”と、ハードディスク（Ｄｉｓｃ）の記憶量”３０ＧＢ”とを関連付けて、不図示の記憶部が有するリカバリ先登録済みリソーステーブルに記憶させる。

次に、図８を参照して本実施形態の第１リソース管理部２１５が記憶するバッファリソーステーブルの一例について説明する。
図８は、本実施形態の第１リソース管理部２１５が記憶するバッファリソーステーブルの一例を示す図である。ここで、バッファリソースとは、残リソーステーブルに記憶されている未使用リソースのうち、アプリケーションシステム２に使用させないリソースである。このバッファリソースによって、仮に、一時的に要求リソース情報が示すリソースの大きさ（例えば、リソース量）を上回るリソースをアプリケーションシステム２が使用した場合であっても、アプリケーションシステム２が生成する情報を記憶させることができる。つまり、バッファリソースとは、要求されるリソースに対して余分に確保されるリソースである。このバッファリソースの大きさは、物理サーバ２１０の規模や、物理サーバ２１０への登録が予定されるアプリケーションシステム２の規模に基づいて、予め設定されている。具体的には、第１リソース管理部２１５は、ＣＰＵコア数”１ｃｏｒｅ”と、メモリ（Ｍｅｍ）の記憶量”１ＧＢ”と、ハードディスク（Ｄｉｓｃ）の記憶量”１０ＧＢ”とを関連付けて、不図示の記憶部が有するバッファリソーステーブルに記憶させる。

次に、図９を参照して本実施形態の第１リソース管理部２１５が記憶する提供可能リソーステーブルの一例について説明する。
図９は、本実施形態の第１リソース管理部２１５が記憶する提供可能リソーステーブルの一例を示す図である。ここで、提供可能リソーステーブルとは、提供可能リソース情報を記憶させるテーブルである。また、提供可能リソース情報とは、物理サーバ２１０がアプリケーションシステム２に提供することができるリソースの大きさの上限値を示す情報である。第１リソース管理部２１５は、各物理サーバ２１０について、上述した残リソーステーブルが示すリソースの大きさから、リカバリ先登録済みテーブルが示すリソースの大きさと、バッファリソーステーブルが示すリソースの大きさとの和を減算したリソースの大きさを、提供可能リソースとして算出する。そして、第１リソース管理部２１５は、各物理サーバ２１０について算出したリソースの大きさを提供可能リソース情報として、不図示の記憶部が有する提供可能リソーステーブルに記憶させる。具体的には、第１リソース管理部２１５は、物理サーバ名”物理サーバ２１０Ａ”と、ＣＰＵコア数”１０ｃｏｒｅ”と、メモリ（Ｍｅｍ）の記憶量”１７ＧＢ”と、ハードディスク（Ｄｉｓｃ）の記憶量”８０ＧＢ”とを関連付けて、不図示の記憶部が有する提供可能リソーステーブルに記憶させる。また、第１リソース管理部２１５は、物理サーバ名”物理サーバＢ”と、ＣＰＵコア数”１ｃｏｒｅ”と、メモリ（Ｍｅｍ）の記憶量”２ＧＢ”と、ハードディスク（Ｄｉｓｃ）の記憶量”５０ＧＢ”とを関連付けて、不図示の記憶部が有する提供可能リソーステーブルに記憶させる。同様に、第１リソース管理部２１５は、物理サーバ名”物理サーバ２１０Ｃ”と、ＣＰＵコア数”１ｃｏｒｅ”と、メモリ（Ｍｅｍ）の記憶量”１１ＧＢ”と、ハードディスク（Ｄｉｓｃ）の記憶量”５０ＧＢ”とを関連付けて、不図示の記憶部が有する提供可能リソーステーブルに記憶させる。このようにして、第１リソース管理部２１５は、提供可能リソース情報を生成する。なお、第２リソース管理部２２５が生成する提供可能リソース情報については、第１リソース管理部２１５が生成する提供可能リソース情報と同様であるため、説明を省略する。

再び、図４を参照してディザスタリカバリシステム１の動作について説明する。リソース管理装置１００の提供可能リソース情報取得部１０２は、各リカバリ先データセンタＤＣから送信された提供可能リソース情報を取得する。具体的には、提供可能リソース情報取得部１０２は、第１リカバリ先データセンタＤＣ−Ｂから送信された提供可能リソース情報を取得するとともに、第２リカバリ先データセンタＤＣ−Ｃから送信された提供可能リソース情報を取得する（ステップＳ１００−３０）。

次に、リソース管理装置１００の遅延情報取得部１０３は、ネットワーク５の遅延状況を示す遅延情報を取得する（ステップＳ１００−４０）。ここで、遅延情報取得部１０３は、例えば、ネットワーク５の遅延状況を推定して得られた遅延時間に基づく遅延情報を取得する。

次に、リソース管理装置１００の選択部１０４は、リカバリ先データセンタＤＣの中から、アプリケーションシステム２が利用するリカバリ先データセンタＤＣを選択する（ステップＳ１００−５０）。ここで、選択部１０４は、ステップＳ１００−１０において取得された要求リソース情報と、ステップＳ１００−３０において取得された提供可能リソース情報と、ステップＳ１００−４０において取得された遅延情報とに基づいて、リカバリ先データセンタＤＣを選択して、リカバリ先データセンタＤＣの選択処理を終了する。具体的には、選択部１０４は、取得された要求リソース情報が示すリソースと、取得された提供可能リソース情報が示すリソースとを比較した結果に基づいて、複数のリカバリ先データセンタＤＣの中から、アプリケーションシステム２が利用する同期情報を記憶させるリカバリ先データセンタＤＣの候補を抽出する。次に、選択部１０４は、要求リソース情報と、取得された遅延情報とを比較した結果に基づいて、抽出したリカバリ先データセンタＤＣの候補の中から、アプリケーションシステム２が利用する同期情報を記憶させるリカバリ先データセンタＤＣを選択する。

次に、図１０を参照して、ディザスタリカバリシステム１の同期情報の転送動作について説明する。
図１０は、本実施形態におけるディザスタリカバリシステム１の同期情報の転送動作の一例を示すフローチャートである。

まず、アプリケーションシステム２は、同期情報を生成して、生成した同期情報をリカバリ元データ記憶部３に記憶させる（ステップＳ２−２０）。

同期情報取得部１０６は、アプリケーションシステム２が同期情報をリカバリ元データ記憶部３に記憶させたことを検出すると、記憶させた同期情報を取得する（ステップＳ１００−６０）。

次に、リソース管理装置１００の通信部１０５は、ステップＳ１００−６０において同期情報取得部１０６が取得した同期情報を、第１リカバリ先データセンタＤＣ−Ｂに送信する（ステップＳ１００−８０）。

次に、第１リカバリ先データセンタＤＣ−Ｂの通信部２１１は、リソース管理装置１００の通信部１０５から送信された同期情報を受信すると、物理サーバ２１０に受信した同期情報を書き込んで記憶させる（ステップＳ２１−２０）。さらに、第１リカバリ先データセンタＤＣ−Ｂの通信部２１１は、受信した同期情報の書き込みが完了すると、同期情報の書込み完了を示す情報をリソース管理装置１００に送信する。

次に、リソース管理装置１００は、同期情報の書き込み完了を示す情報をアプリケーションシステム２に出力して、同期情報の転送動作１回あたりの処理を終了する（ステップＳ１００−１００）。アプリケーションシステム２は、リソース管理装置１００が出力する同期情報の書き込み完了を示す情報を取得すると、同期情報の転送動作を終了して、新たに生成した同期情報の転送動作に移行する。すなわち、ディザスタリカバリシステム１は、上述したステップＳＳ−２０からステップＳ１００−１００までの動作を繰り返し行うことにより、アプリケーションシステム２が生成する同期情報を転送する。

次に、遅延情報取得部１０３が遅延情報を取得する動作について説明する。遅延情報取得部１０３は、所定の間隔（例えば、１時間毎）により、リカバリ元データセンタＤＣ−Ａの通信部１０５から、各リカバリ先データセンタＤＣに対して、ネットワーク５を介した情報の到達性を確認する通信（例えば、ｐｉｎｇ）を行うことにより、遅延時間を算出する。次に、遅延情報取得部１０３は、算出した遅延時間を不図示の記憶部が有するネットワーク遅延テーブルに記憶させる。このネットワーク遅延テーブルについて、図１１を参照して説明する。

図１１は、本実施形態におけるネットワーク遅延テーブルの一例を示す図である。ネットワーク遅延テーブルとは、リカバリ元データセンタＤＣ−Ａと、各リカバリ先データＤＣとの間のネットワーク５の遅延時間の履歴を示す情報である。具体的には、リソース管理装置１００は、データセンタ名“ＤＣ−Ｂ”と、時間軸（例えば、日付ごと）に並べられているネットワーク遅延時間“１０ｍｓ”、“７ｍｓ”、“９ｍｓ”とを関連付けて、リソース管理装置１００が備える不図示の記憶部が有するネットワーク遅延テーブルに記憶させる。同様にして、リソース管理装置１００は、データセンタ名“ＤＣ−Ｃ”と、ネットワーク遅延時間“２０ｍｓ”、“１８ｍｓ”、“２０ｍｓ”とを関連付けて、ネットワーク遅延テーブルに記憶させる。

次に、アプリケーションシステム２が、ディスク書き込み待ち率を算出する動作について説明する。アプリケーションシステム２は、前回生成した同期情報の転送動作が完了する前に、同期情報を新たに生成したことにより、新たに生成した同期情報の転送動作が待たされたか否かに基づいて、ディスク書き込み待ち率を算出する。そしてアプリケーションシステム２は、算出したディスク書き込み率を、不図示の記憶部が有するディスク書き込み待ち率テーブルに記憶させる。ここで、ディスク書き込み待ち率とは、同期情報を生成した回数に対する、生成した同期情報の転送が待たされた回数の割合である。このディスク書き込み待ち率について、図１２を参照して説明する。

図１２は、本実施形態におけるディスク書き込み待ち率の一例を示す図である。具体的には、アプリケーションシステム２は、物理サーバ名“物理サーバＡ”と、アプリケーションシステム名“アプリケーションシステム２Ａ”と、時系列（例えば、日付ごと）に並べられているディスク書き込み率“１”、“０．９”、“０．８”とを関連付けて不図示の記憶部が有するディスク書き込み待ち率テーブルに記憶させる。また、アプリケーションシステム２は、物理サーバ名“物理サーバＢ”と、アプリケーションシステム名“アプリケーションシステム２Ｂ”と、時系列（例えば、日付ごと）に並べられているディスク書き込み率“０．２”、“０．１１”、“０．１”とを関連付けて不図示の記憶部が有するディスク書き込み待ち率テーブルに記憶させる。同様に、アプリケーションシステム２は、物理サーバ名“物理サーバＣ”と、アプリケーションシステム名“アプリケーションシステム２Ａ”と、時系列（例えば、日付ごと）に並べられているディスク書き込み率“０．１”、“０．０１”、“０．１”とを関連付けて不図示の記憶部が有するディスク書き込み待ち率テーブルに記憶させる。

次に、図１３を参照して、ディザスタリカバリシステム１のリソース監視動作について説明する。
図１３は、本実施形態におけるディザスタリカバリシステム１のリソース監視動作の一例を示すフローチャートである。

アプリケーションシステム２は、要求リソースに変更がある場合には、リソース管理装置１００に対してリソース確保通知を出力する（ステップＳ２−３０）。また、アプリケーションシステム２は、要求リソースに変更がない場合には、リソース確保通知を出力しない。なお、アプリケーションシステム２は、要求リソースに変更がない場合には、リソース管理装置１００に対して、変更がない要求リソース情報を含むリソース確保通知を出力してもよい。

リソース管理装置１００は、アプリケーションシステム２からリソース確保通知が出力された場合には、要求リソースの変更の有無を確認する（ステップＳ１００−１１０）。また、リソース管理装置１００は、アプリケーションシステム２からリソース確保通知が出力されない場合には、所定の時間（例えば、１日）ごとに要求リソースの変更の有無を確認する。リソース管理装置１００は、要求リソースの変更がある場合には、要求リソーステーブルを更新する。

次に、リソース管理装置１００、第１リカバリ先データセンタＤＣ−Ｂ、および第２リカバリ先データセンタＤＣ−Ｃは、上述したステップＳ１００−２０からステップＳ１００−４０までと同様にして、提供可能リソース情報と、遅延情報とを取得する（ステップＳ１００−１２０からステップＳ１００−１４０まで）。

次に、リソース管理装置１００の選択部１０４は、取得した提供可能リソース情報と、遅延情報とに基づいて、リカバリ先データセンタＤＣの選択の要否を判定する（ステップＳ１００−１５０）。具体的には、選択部１０４は、提供可能リソース情報と、遅延情報とに基づく所定の条件が成立した場合に、リカバリ先データセンタＤＣの選択が必要と判定し（ステップＳ１００−１５０：ＹＥＳ）、処理をステップＳ１００−１６０に進める。一方、選択部１０４は、提供可能リソース情報と、遅延情報とに基づく所定の条件が成立しなかった場合には、リカバリ先データセンタＤＣの選択が不要と判定し（ステップＳ１００−１５０：ＮＯ）、リソース監視動作を終了する。

ここで、所定の条件とは、要求リソース情報、提供可能リソース情報、または遅延情報のうち、少なくともいずれかの情報に変化が生じたことを含む条件である。この所定の条件には、一例として、提供可能リソースの大きさが要求リソースの大きさよりも小さくなったこと、および要求リソースの大きさが大きくなったことが含まれる。また、この所定の条件には、ディスク書き込み待ち率の順にアプリケーションシステム２を並べた場合にアプリケーションシステム２の順序が変化したこと、およびネットワーク遅延時間の順にリカバリ先データセンタＤＣを並べた場合に、リカバリ先データセンタＤＣの順序が変化したことが含まれる。さらに、この所定の条件には、アプリケーションシステム２が追加、変更、削除されたこと、およびリカバリ先データセンタＤＣが追加、変更、削除されたことが含まれる。また、この所定の条件には、ディザスタリカバリが実行されたことが含まれる。

以上説明したように、本実施形態のディザスタリカバリシステム１は、リソース管理装置１００を備えている。このリソース管理装置１００は、要求リソース情報取得部１０１と、提供可能リソース情報取得部１０２と、遅延情報取得部１０３と、選択部１０４と、通信部（送信部）１０５とを備えている。

これにより、ディザスタリカバリシステム１は、アプリケーションシステム２が要求するリソースと、リカバリ先データセンタＤＣが提供可能なリソースとを比較して、リカバリ先データセンタＤＣを選択する。また、ディザスタリカバリシステム１は、アプリケーションシステム２の動作状況（例えば、ディスク書き込み待ち率）と、ネットワーク５を介した通信の遅延時間とに基づいて、リカバリ先データセンタＤＣを選択する。つまり、ディザスタリカバリシステム１は、リカバリ先データセンタＤＣの動作状況およびネットワーク５の通信遅延状況に基づいてリカバリ先データセンタＤＣを選択するため、アプリケーションシステム２の性能が低下する程度を低減させることができる。

また、ディザスタリカバリシステム１は、要求リソース情報、提供可能リソース情報、または遅延情報の少なくともいずれかの情報に変化が生じた場合に、リカバリ先データセンタＤＣを選択の判定を開始する。したがって、ディザスタリカバリシステム１は、アプリケーションシステム２から要求されるリソースが変化した場合、リカバリ先データセンタＤＣの提供可能リソースが変化した場合、またはネットワーク５の遅延時間が変化した場合に、リカバリ先データセンタＤＣを再度選択することができる。すなわち、ディザスタリカバリシステム１は、ディザスタリカバリシステム１は、要求されるリソースが変化した場合、提供可能リソースが変化した場合、またはネットワーク５の遅延時間が変化した場合であっても、リカバリ先データセンタＤＣを再度選択することにより、アプリケーションシステム２の性能が低下する程度を低減させることができる。

＜第２の実施形態＞
以下、本発明の第２の実施形態について、図面を参照して説明する。なお、第１の実施形態と同一の構成については、同一の符号を付してその説明を省略する。
図１５は、本発明の第２の実施形態におけるディザスタリカバリシステム１ａの構成の一例を示す構成図である。ディザスタリカバリシステム１ａは、第１の実施形態において説明したリソース管理装置１００が備える通信部１０５に代えて、データ送信装置３００を備える点が、第１の実施形態と異なる。

ディザスタリカバリシステム１ａは、リソース管理装置１００ａと、データ送信装置３００を備える。リソース管理装置１００ａは、要求リソース情報取得部１０１と、提供可能リソース情報取得部１０２と、遅延情報取得部１０３と、選択部１０４とを備えている。データ送信装置３００は、通信部（送信部）３０１と、切換部３０２と、検出部３０３とを備えている。

通信部（送信部）３０１は、リカバリ先データセンタＤＣ（データ記憶装置）のうちの第１リカバリ先データセンタＤＣ−Ｂ（第１のデータ記憶装置）と、第２リカバリ先データセンタＤＣ−Ｃ（第２のデータ記憶装置）との、いずれかのリカバリ先データセンタＤＣにアプリケーションシステム２の障害復旧に用いられるデータを送信する。具体的には、通信部３０１は、同期情報取得部１０６がアプリケーションシステム２から取得した同期情報を、第１リカバリ先データセンタＤＣ−Ｂに送信する。この通信部３０１は、アプリケーションシステム２が同期情報を生成するごとに、同期情報取得部１０６が取得した同期情報を、第１リカバリ先データセンタＤＣ−Ｂに送信する。

検出部３０３は、通信部（送信部）３０１が第１リカバリ先データセンタＤＣ−Ｂ（第１のデータ記憶装置）に送信したデータについて、第１リカバリ先データセンタＤＣ−Ｂから第２リカバリ先データセンタＤＣ−Ｃ（第２のデータ記憶装置）への転送が完了したことを検出する。ここで、第１リカバリ先データセンタＤＣ−Ｂから第２リカバリ先データセンタＤＣ−Ｃにリカバリ先データセンタＤＣの変更を行う場合について説明する。第１リカバリ先データセンタＤＣ−Ｂから第２リカバリ先データセンタＤＣ−Ｃに対する同期情報の転送が完了すると、第１リカバリ先データセンタＤＣ−Ｂの通信部２１１は、リカバリ元データセンタＤＣ−Ａに対して、転送完了を示す情報を送信する。リカバリ元データセンタＤＣ−Ａが備えるデータ送信装置３００の通信部３０１は、この転送完了を示す情報を受信する。検出部３０３は、通信部３０１が受信した転送完了を示す情報を取得することにより、第１リカバリ先データセンタＤＣ−Ｂから第２リカバリ先データセンタＤＣ−Ｃへの転送が完了したことを検出する。

切換部３０２は、検出部３０３が転送完了を検出した場合に、通信部（送信部）３０１の送信先を第１リカバリ先データセンタＤＣ−Ｂ（第１のデータ記憶装置）から第２リカバリ先データセンタＤＣ−Ｃに切り換える。具体的には、切換部３０２は、検出部３０３が転送完了を検出すると、選択部１０４から切り換え後のリカバリ先データセンタＤＣを示す情報を取得する。例えば、切換部３０２は、選択部１０４から切り換え後のリカバリ先データセンタＤＣを示す情報として、第２リカバリ先データセンタＤＣ−Ｃを示す情報を取得する。次に、切換部３０２は、取得した第２リカバリ先データセンタＤＣ−Ｃを示す情報に基づいて、通信部３０１の送信先を第２リカバリ先データセンタＤＣ−Ｃに切り換える。ここで、リカバリ先データセンタＤＣを示す情報とは、例えば、リカバリ先データセンタＤＣの宛先を示すＩＰアドレスである。

次に、図１５を参照して、ディザスタリカバリシステム１ａのリカバリ先データセンタＤＣの変更動作について説明する。
図１５は、本実施形態におけるディザスタリカバリシステム１ａのリカバリ先データセンタＤＣの変更動作の一例を示すフローチャートである。

まず、データ送信装置３００は、第１リカバリ先データセンタＤＣ−Ｂに対してリカバリ先の変更通知を送信する（ステップＳ１００−１９０）。ここで、リカバリ先の変更通知とは、第１リカバリ先データセンタＤＣ−Ｂとして選択されているリカバリ先データセンタＤＣに対して、リカバリ先の変更を通知する情報である。このリカバリ先の変更通知には、変更先のリカバリ先データセンタＤＣを示す情報が含まれている。例えば、リカバリ先の変更通知には、変更先の第２リカバリ先データセンタＤＣ−Ｃを示すＩＰアドレスが含まれている。

次に、第１リカバリ先データセンタＤＣ−Ｂは、リカバリ先の変更通知を受信すると、第１リカバリ先データセンタＤＣ−Ｂが備える各物理サーバ２１０に記憶されている同期情報について、リカバリ先の変更通知が示すリカバリ先データセンタＤＣへの転送を開始する（ステップＳ２１−４０）。具体的には、第１リカバリ先データセンタＤＣ−Ｂは、リカバリ先の変更通知を受信すると、物理サーバ２１０に記憶されている同期情報について、第２リカバリ先データセンタＤＣ−Ｃへの転送を開始する。

一方、アプリケーションシステム２は、生成した同期情報をデータ送信装置３００に出力する（ステップＳ２−４０）。データ送信装置３００は、アプリケーションシステム２が出力する同期情報を取得する（ステップＳ１００−２００）。

次に、データ送信装置３００の通信部３０１は、アプリケーションシステム２から取得した同期情報をリカバリ先の変更前のリカバリ先データセンタＤＣである、第１リカバリ先データセンタＤＣ−Ｂに送信する（ステップＳ１００−２１０）。

次に、第１リカバリ先データセンタＤＣ−Ｂの通信部２１１は、同期情報を受信すると、物理サーバ２１０に受信した同期情報を書き込んで記憶させる（ステップＳ２１−５０）。さらに、第１リカバリ先データセンタＤＣ−Ｂの通信部２１１は、受信した同期情報の書き込みが完了すると、同期情報の書込み完了を示す情報をデータ送信装置３００に送信する。

次に、データ送信装置３００は、同期情報の書き込み完了を示す情報をアプリケーションシステム２に出力する（ステップＳ１００−２２０）。ディザスタリカバリシステム１ａが備える各部は、上述した、ステップＳ２−４０からステップＳ１００−２２０まで、すなわち、図１５の破線ＳＱ１によって示されるシーケンスを、アプリケーションシステム２が同期情報を生成する毎に繰り返し実行する。

一方、第１リカバリ先データセンタＤＣ−Ｂの通信部２１１（転送部）は、ステップＳ２１−５０において記憶させた同期情報を読み出して、読み出した同期情報を第２リカバリ先データセンタＤＣ−Ｃに転送する（ステップＳ２１−６０）。なお、この通信部２１１（転送部）は、ステップＳ２１−５０において受信した同期情報を、物理サーバ２１０に記憶させる前に、第２リカバリ先データセンタＤＣ−Ｃに転送してもよい。これにより、通信部２１１は、同期情報を受信してから転送するまでの時間を低減することができる。

ここで、第１リカバリ先データセンタＤＣ−Ｂは、ステップＳ２１−４０において開始した同期情報の転送が、物理サーバ２１０に記憶されているすべての同期情報について完了すると、リカバリ先変更完了通知をデータ送信装置３００、および第２リカバリ先データセンタＤＣ−Ｃに送信する（ステップＳ２１−７０）。ここで、リカバリ先変更完了通知とは、物理サーバ２１０に記憶されているすべての同期情報について転送が完了したことを示す情報である。

次に、データ送信装置３００は、第１リカバリ先データセンタＤＣ−Ｂからリカバリ先変更完了通知を受信すると、リカバリ先データセンタＤＣを変更する（ステップＳ１００−２３０）。具体的には、データ送信装置３００の通信部３０１は、第１リカバリ先データセンタＤＣ−Ｂからリカバリ先変更完了通知を受信する。次に、検出部３０３は、通信部３０１がリカバリ先変更完了通知を受信したことにより、第１リカバリ先データセンタＤＣ−Ｂから第２リカバリ先データセンタＤＣ−Ｃへの同期情報の転送が完了したことを検出する。次に、切換部３０２は、検出部３０３が転送完了を検出した場合に、通信部（送信部）３０１の送信先を第１リカバリ先データセンタＤＣ−Ｂ（第１のデータ記憶装置）から第２リカバリ先データセンタＤＣ−Ｃに切り換える。このようにしてデータ送信装置３００は、リカバリ先変更完了通知を受信した後にアプリケーションシステム２から取得した同期情報を、変更後のリカバリ先データセンタＤＣに送信する。

また、第２リカバリ先データセンタＤＣ−Ｃは、第１リカバリ先データセンタＤＣ−Ｂからリカバリ先変更完了通知を受信すると、リカバリ先データセンタＤＣを変更する（ステップＳ２２−４０）。具体的には、第２リカバリ先データセンタＤＣ−Ｃは、データ送信装置３００から同期情報を受信できるように、同期情報の送信元を示す情報を変更する。

次に、アプリケーションシステム２は、生成した同期情報をデータ送信装置３００に出力する（ステップＳ２−５０）。データ送信装置３００は、アプリケーションシステム２が出力する同期情報を取得する（ステップＳ１００−２４０）。

次に、データ送信装置３００の通信部３０１は、アプリケーションシステム２から取得した同期情報をリカバリ先の変更後のリカバリ先データセンタＤＣである、第２リカバリ先データセンタＤＣ−Ｃに送信する（ステップＳ１００−２５０）。

次に、第２リカバリ先データセンタＤＣ−Ｃの通信部２２１は、同期情報を受信すると、受信した同期情報を物理サーバ２２０に書き込んで記憶させる（ステップＳ２２−５０）。さらに、第２リカバリ先データセンタＤＣ−Ｃの通信部２２１は、受信した同期情報の書き込みが完了すると、同期情報の書込み完了を示す情報をデータ送信装置３００に送信する。

次に、データ送信装置３００は、同期情報の書き込み完了を示す情報をアプリケーションシステム２に出力する（ステップＳ１００−２６０）。ディザスタリカバリシステム１ａが備える各部は、上述した、ステップＳ２−５０からステップＳ１００−２６０まで、すなわち、図１５の破線ＳＱ２によって示されるシーケンスを、アプリケーションシステム２が同期情報を生成する毎に繰り返し実行する。そして、ディザスタリカバリシステム１ａが備える各部は、アプリケーションシステム２による同期情報の生成が終了すると、処理を終了する。

以上説明したように、本実施形態のディザスタリカバリシステム１ａは、データ送信装置３００を備えている。このデータ送信装置３００は、通信部（送信部）３０１、切換部３０２と、検出部３０３とを備えている。

これにより、ディザスタリカバリシステム１ａは、リカバリ先データセンタＤＣの切り換え中に、アプリケーションシステム２が生成した同期情報について、切り換え前のリカバリ先データセンタＤＣに送信する。したがって、ディザスタリカバリシステム１ａは、リカバリ先データセンタＤＣの切り換え中に生成された同期情報について、切り換え後のリカバリ先データセンタＤＣのみならず、切り換え前のリカバリ先データセンタＤＣに記憶させることができる。仮に、リカバリ先データセンタＤＣの切り換え中に生成された同期情報について、切り換え後のリカバリ先データセンタＤＣにのみ送信する場合には、切り換え中にリカバリ元データセンタＤＣ−Ａに障害が発生した場合には次のような問題が生じる。すなわち、切り換え中にリカバリ元データセンタＤＣ−Ａに障害が発生した場合、アプリケーションが生成したすべての同期情報を記憶しているリカバリ先データセンタＤＣが存在しないという状況が発生しうる。このように、アプリケーションが生成したすべての同期情報を記憶しているリカバリ先データセンタＤＣが存在しない場合には、アプリケーションシステムを継続的に動作させることができないことがある。一方、ディザスタリカバリシステム１ａは、少なくとも切り換え前のリカバリ先データセンタＤＣには、アプリケーションが生成したすべての同期情報が記憶されているため、切り換え中にリカバリ元データセンタＤＣ−Ａに障害が発生した場合であっても、アプリケーションシステムを継続的に動作させることができる。つまり、ディザスタリカバリシステム１ａは、リカバリ先データセンタＤＣの切り換え中に、リカバリ元データセンタＤＣ−Ａに障害が発生する状況に対して、ディザスタリカバリシステムの頑強性を向上させることができる。

なお、本発明における各処理部の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより帳票処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータシステム」は、ホームページ提供環境（あるいは表示環境）を備えたＷＷＷシステムも含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。

また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。また、上記プログラムは、前述した機能の一部を実現するためのものであってもよい。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。

１、１ａ ディザスタリカバリシステム
２ アプリケーションシステム
３ リカバリ元データ記憶部
５ ネットワーク
１００ リソース管理装置
１０１ 要求リソース情報取得部
１０２ 提供可能リソース情報取得部
１０３ 遅延情報取得部
１０４ 選択部
１０５ 通信部（送信部）
１０６ 同期情報取得部
２１０、２１０Ａ、２１０Ｂ、２１０Ｃ 物理サーバ
２１１ 通信部
２１５ 第１リソース管理部
２２０、２２０Ａ、２２０Ｂ、２２０Ｃ 物理サーバ
２２１ 通信部
２２５ 第２リソース管理部
３００ データ送信装置
３０１ 通信部（送信部）
３０２ 切換部
３０３ 検出部
ＤＣ−Ａ リカバリ元データセンタ
ＤＣ−Ｂ 第１リカバリ先データセンタ
ＤＣ−Ｃ 第２リカバリ先データセンタ
ＤＣ−ｎ 第ｎリカバリ先データセンタ

Claims (4)

1. ネットワークを介して接続される複数のデータ記憶装置にデータを記憶させて、当該データを利用するアプリケーションシステムの障害復旧を可能にするディザスタリカバリシステムのリソースを管理するリソース管理装置であって、
   前記アプリケーションシステムの障害復旧に必要なリソースを示す要求リソース情報を取得する要求リソース情報取得部と、
   前記データ記憶装置が提供可能なリソースを示す提供可能リソース情報を取得する提供可能リソース情報取得部と、
   前記データ記憶装置との通信を行う前記ネットワークの遅延状況を示す遅延情報を取得する遅延情報取得部と、
   取得された前記要求リソース情報と、前記提供可能リソース情報と、前記遅延情報とに基づいて、複数の前記データ記憶装置の中から前記アプリケーションシステムが利用する前記データを記憶させるデータ記憶装置を選択する選択部と、
   前記選択部が選択した前記データ記憶装置に、前記アプリケーションシステムが利用する前記データを送信する送信部と、
   を備え、
   前記選択部は、
   前記要求リソース情報、前記提供可能リソース情報、または前記遅延情報のうち、少なくともいずれかの情報に変化が生じた場合に、前記データを記憶させるデータ記憶装置の選択を開始する
   ことを特徴とするリソース管理装置。
2. 前記要求リソース情報には、
   前記データ記憶装置に対する前記データの書き込み遅延の程度を示す書込遅延情報が含まれ、
   前記選択部は、
   取得された前記要求リソース情報が示すリソースと、取得された前記提供可能リソース情報が示すリソースとを比較した結果と、当該要求リソース情報に含まれる前記書込遅延情報と、取得された前記遅延情報とを比較した結果とに基づいて、複数の前記データ記憶装置の中から前記アプリケーションシステムが利用する前記データを記憶させるデータ記憶装置を選択する
   ことを特徴とする請求項１に記載のリソース管理装置。
3. ネットワークを介して接続される複数のデータ記憶装置にデータを記憶させて、当該データを利用するアプリケーションシステムの障害復旧を可能にするディザスタリカバリシステムのリソースを管理するリソース管理装置を用いたリソース管理方法であって、
   前記リソース管理装置が備える要求リソース情報取得部が、前記アプリケーションシステムの障害復旧に必要なリソースを示す要求リソース情報を取得する要求リソース情報取得ステップと、
   前記リソース管理装置が備える提供可能リソース情報取得部が、前記データ記憶装置が提供可能なリソースを示す提供可能リソース情報を取得する提供可能リソース情報取得ステップと、
   前記リソース管理装置が備える遅延情報取得部が、前記データ記憶装置との通信を行う前記ネットワークの遅延状況を示す遅延情報を取得する遅延情報取得ステップと、
   前記リソース管理装置が備える選択部が、取得された前記要求リソース情報と、前記提供可能リソース情報と、前記遅延情報とに基づいて、複数の前記データ記憶装置の中から前記アプリケーションシステムが利用する前記データを記憶させるデータ記憶装置を選択する選択ステップと、
   前記リソース管理装置が備える送信部が、前記選択ステップによって選択された前記データ記憶装置に、前記アプリケーションシステムが利用する前記データを送信する送信ステップと、
   を備え、
   前記選択ステップでは、
   前記要求リソース情報、前記提供可能リソース情報、または前記遅延情報のうち、少なくともいずれかの情報に変化が生じた場合に、前記データを記憶させるデータ記憶装置の選択を開始する
   ことを特徴とするリソース管理方法。
4. ネットワークを介して接続される複数のデータ記憶装置にデータを記憶させて、当該データを利用するアプリケーションシステムの障害復旧を可能にするディザスタリカバリシステムのリソースを管理するリソース管理装置のコンピュータに、
   前記コンピュータが備える要求リソース情報取得部が、前記アプリケーションシステムの障害復旧に必要なリソースを示す要求リソース情報を取得する要求リソース情報取得ステップと、
   前記コンピュータが備える提供可能リソース情報取得部が、前記データ記憶装置が提供可能なリソースを示す提供可能リソース情報を取得する提供可能リソース情報取得ステップと、
   前記コンピュータが備える遅延情報取得部が、前記データ記憶装置との通信を行う前記ネットワークの遅延状況を示す遅延情報を取得する遅延情報取得ステップと、
   前記コンピュータが備える選択部が、取得された前記要求リソース情報と、前記提供可能リソース情報と、前記遅延情報とに基づいて、複数の前記データ記憶装置の中から前記アプリケーションシステムが利用する前記データを記憶させるデータ記憶装置を選択する選択ステップと、
   前記コンピュータが備える送信部が、前記選択ステップによって選択された前記データ記憶装置に、前記アプリケーションシステムが利用する前記データを送信する送信ステップと、
   を実行させるためのプログラムであり、
   前記選択ステップでは、
   前記要求リソース情報、前記提供可能リソース情報、または前記遅延情報のうち、少なくともいずれかの情報に変化が生じた場合に、前記データを記憶させるデータ記憶装置の選択を開始する
   ことを特徴とするプログラム。

Images