特開 2023-84777 ディザスタリカバリシステム及びディザスタリカバリ方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023084777

(43)【公開日】2023-06-20

(54)【発明の名称】ディザスタリカバリシステム及びディザスタリカバリ方法

(51)【国際特許分類】

   G06F 11/14 20060101AFI20230613BHJP

   G06F 3/06 20060101ALI20230613BHJP

   G06F 13/10 20060101ALI20230613BHJP

【ＦＩ】

G06F11/14 651

G06F3/06 304F

G06F11/14 656

G06F11/14 664

G06F3/06 301W

G06F3/06 301X

G06F13/10 340A

G06F11/14 658

【審査請求】未請求

【請求項の数】11

【出願形態】ＯＬ

(21)【出願番号】P 2021199067

(22)【出願日】2021-12-08

(71)【出願人】

【識別番号】000005108

【氏名又は名称】株式会社日立製作所

(74)【代理人】

【識別番号】110002365

【氏名又は名称】弁理士法人サンネクスト国際特許事務所

(72)【発明者】

【氏名】里山 愛

(72)【発明者】

【氏名】出口 彰

(57)【要約】

【課題】
顧客が利用するサービスに適合するディザスタリカバリ構成を提供しつつディザスタリカバリシステム全体のコストを削減する。
【解決手段】
ディザスタリカバリシステム（情報処理システム１）において、クラウド管理ノード３００は、プライマリサイト１００で実行される各アプリケーション（アプリ１５３）の性能の重視性を示す重要度情報を、当該アプリケーションを実行する仮想計算機（ＶＭ１５２）と対応付けて管理し、仮想計算機ごとに、対応するアプリケーションの重要度情報に基づいて、複数種類のＤＲ方式のうちから、当該仮想計算機及び当該アプリケーションに適用するＤＲ方式を決定し、当該仮想計算機が使用するデータのデータ転送に適用される所定の設定項目の内容を決定する。
【選択図】図２

【特許請求の範囲】

【請求項1】

通常時にサービスを提供するプライマリサイトにおける障害発生時に、当該プライマリサイトで実行されていた仮想計算機及びアプリケーションをセカンダリサイトで復旧するディザスタリカバリ構成を備えるディザスタリカバリシステムであって、
アプリケーションを実行する仮想計算機を実行する第１のサーバシステムと、ストレージに前記第１のサーバシステムが使用するデータを格納する第１のストレージシステムと、を有するプライマリサイトと、
クラウドストレージに前記第１のサーバシステムが使用するデータのバックアップ用データを格納する第２のストレージシステムと、前記障害発生時に、前記クラウドストレージに格納したバックアップ用データを用いて、前記プライマリサイトにおける対応関係を考慮した構成で前記仮想計算機及び前記アプリケーションを復旧する第２のサーバシステムと、を有するセカンダリサイトと、
前記プライマリサイトと前記セカンダリサイトとによる前記ディザスタリカバリ構成を構築するための制御、及び前記プライマリサイトから前記セカンダリサイトに前記バックアップ用データを転送するデータ転送の仲介を行うクラウド管理ノードと、
を備え、
前記クラウド管理ノードは、
前記プライマリサイトで実行される各前記アプリケーションの性能の重視性を示す重要度情報を当該アプリケーションを実行する前記仮想計算機と対応付けて管理し、
前記仮想計算機ごとに、対応するアプリケーションの前記重要度情報に基づいて、複数種類のディザスタリカバリ方式のうちから当該仮想計算機及び当該アプリケーションに適用するディザスタリカバリ方式を決定し、
前記仮想計算機ごとに、対応するアプリケーションの前記重要度情報に基づいて、当該仮想計算機が使用するデータの前記データ転送に適用される所定の設定項目の内容を決定する
ことを特徴とするディザスタリカバリシステム。

【請求項2】

前記データ転送において、
前記クラウド管理ノードは、前記プライマリサイトの前記第１のストレージシステムにおいて前記バックアップ用データを圧縮してから前記セカンダリサイトの前記第２のストレージシステムに転送し、
前記第２のストレージシステムは、前記プライマリサイトから転送された前記バックアップ用データを圧縮されたまま格納する
ことを特徴とする請求項１に記載のディザスタリカバリシステム。

【請求項3】

前記複数種類のディザスタリカバリ方式には少なくともパイロットライト方式が含まれ、
前記パイロットライト方式が適用される前記仮想計算機が使用するデータの前記データ転送において、
前記第２のストレージシステムは、前記プライマリサイトから転送された前記バックアップ用データの少なくとも一部を前記復旧が開始されるまで伸長せずに格納する
ことを特徴とする請求項２に記載のディザスタリカバリシステム。

【請求項4】

前記第２のストレージシステムのクラウドストレージには、リソースの使用コストまたは性能が異なる複数種類のクラウドストレージが含まれ、
前記クラウド管理ノードは、前記所定の設定項目の内容の決定の１つとして、前記仮想計算機ごとに、対応するアプリケーションの前記重要度情報に基づいて、前記データ転送における前記バックアップ用データの格納先を、前記複数種類のクラウドストレージのうちから決定する
ことを特徴とする請求項１に記載のディザスタリカバリシステム。

【請求項5】

前記クラウド管理ノードは、前記所定の設定項目の内容の決定の１つとして、前記仮想計算機ごとに、対応するアプリケーションの前記重要度情報に基づいて、前記データ転送における前記バックアップ用データの転送方法を、同期コピー及び非同期コピーを含む複数種類の転送方法のうちから決定する
ことを特徴とする請求項１に記載のディザスタリカバリシステム。

【請求項6】

前記クラウド管理ノードは、前記所定の設定項目の内容の決定の１つとして、前記仮想計算機ごとに、対応するアプリケーションの前記重要度情報に基づいて、通信コストまたは通信速度が異なる複数種類のネットワークのうちから、前記データ転送において前記バックアップ用データを転送するネットワークの種類を決定する
ことを特徴とする請求項１に記載のディザスタリカバリシステム。

【請求項7】

前記クラウド管理ノードは、前記所定の設定項目の内容の決定の１つとして、前記仮想計算機ごとに、対応するアプリケーションの前記重要度情報に基づいて、データの圧縮率または圧縮データの伸長速度が異なる複数種類の圧縮アルゴリズムのうちから、前記データ転送において前記バックアップ用データの圧縮に使用する圧縮アルゴリズムを決定する
ことを特徴とする請求項２に記載のディザスタリカバリシステム。

【請求項8】

前記第２のストレージシステムは、前記第２のサーバシステムが生成する仮想計算機が直接データにアクセスできる第１のストレージ装置と、前記第２のサーバシステムが生成する仮想計算機が直接データにアクセスできない第２のストレージ装置と、を有し、
前記復旧のために前記クラウド管理ノードから前記セカンダリサイトにフェイルオーバの実行が指示されたとき、前記データ転送による前記バックアップ用データが前記第２のストレージ装置に格納されている場合には、
当該バックアップ用データは伸長されて、前記第１のストレージ装置に生成されたボリュームに格納され、当該ボリュームが前記バックアップ用データを使用する仮想計算機にアタッチされる
ことを特徴とする請求項１に記載のディザスタリカバリシステム。

【請求項9】

前記クラウド管理ノードは、
前記仮想計算機ごとに、前記復旧のために実行されるフェイルオーバの開始から仮想計算機の起動完了までに要する環境構築時間を見積もり、
データの圧縮率または圧縮データの伸長速度が異なる複数種類の圧縮アルゴリズムのうちから、前記バックアップ用データの伸長に要する時間が前記見積もった環境構築時間以内に収まる程度のデータ量に前記バックアップ用データを圧縮可能な圧縮アルゴリズムを、前記データ転送において前記バックアップ用データの圧縮に使用する圧縮アルゴリズムとして決定する
ことを特徴とする請求項２に記載のディザスタリカバリシステム。

【請求項10】

前記仮想計算機ごとに当該仮想計算機及び当該アプリケーションに適用するディザスタリカバリ方式が指定される場合、
前記クラウド管理ノードは、前記指定されたディザスタリカバリ方式に基づいて、前記仮想計算機で実行される前記アプリケーションの前記重要度情報を決定する
ことを特徴とする請求項１に記載のディザスタリカバリシステム。

【請求項11】

通常時にサービスを提供するプライマリサイトにおける障害発生時に、当該プライマリサイトで実行されていた仮想計算機及びアプリケーションをセカンダリサイトで復旧するディザスタリカバリ構成を備えるディザスタリカバリシステムによるディザスタリカバリ方法であって、
前記ディザスタリカバリシステムは、
アプリケーションを実行する仮想計算機を実行する第１のサーバシステムと、ストレージに前記第１のサーバシステムが使用するデータを格納する第１のストレージシステムと、を有するプライマリサイトと、
クラウドストレージに前記第１のサーバシステムが使用するデータのバックアップ用データを格納する第２のストレージシステムと、前記障害発生時に、前記クラウドストレージに格納したバックアップ用データを用いて、前記プライマリサイトにおける対応関係を考慮した構成で前記仮想計算機及び前記アプリケーションを復旧する第２のサーバシステムと、を有するセカンダリサイトと、
前記プライマリサイトと前記セカンダリサイトとによる前記ディザスタリカバリ構成を構築するための制御、及び前記プライマリサイトから前記セカンダリサイトに前記バックアップ用データを転送するデータ転送の仲介を行うクラウド管理ノードと、
を有し、
前記クラウド管理ノードが、
前記プライマリサイトで実行される各前記アプリケーションの性能の重視性を示す重要度情報を当該アプリケーションを実行する前記仮想計算機と対応付けて管理し、
前記仮想計算機ごとに、対応するアプリケーションの前記重要度情報に基づいて、複数種類のディザスタリカバリ方式のうちから当該仮想計算機及び当該アプリケーションに適用するディザスタリカバリ方式を決定し、
前記仮想計算機ごとに、対応するアプリケーションの前記重要度情報に基づいて、当該仮想計算機が使用するデータの前記データ転送に適用される所定の設定項目の内容を決定する
ことを特徴とするディザスタリカバリ方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ディザスタリカバリシステム及びディザスタリカバリ方法に関し、ディザスタリカバリ構成を提供するディザスタリカバリシステム及びそのディザスタリカバリ方法に適用して好適なものである。

【背景技術】

【0002】

特許文献１に開示されているように、地震や火災といった大規模災害が発生した場合のプライマリサイトにおけるデータロストに備えて、遠隔地のサイト（セカンダリサイト）にデータを多重化して保持するディザスタリカバリ（ＤＲ）技術が知られている。

【0003】

ディザスタリカバリの方法は複数知られており、例えば非特許文献１には、マルチサイト方式及びパイロットライト方式が開示されている。マルチサイト方式は、セカンダリサイトにおいて常にプライマリサイトと同じシステムを稼働させている。一方、パイロットライト方式は、セカンダリサイトにおいて最小限の部分だけをスタンバイしておき、障害が検知されて復旧する必要が生じたときに、本番環境（プライマリサイトと同じ環境）を素早く構築する。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】米国特許出願公開第２００９／０２７１５８２号明細書

【非特許文献】

【0005】

【非特許文献1】舟崎 健治、市崎 洋平、“AWS大阪ローカルリージョンの活用とAWSで実現するDisaster Recovery”、［online］、［令和3年9月28日検索］、インターネット〈URL：https://d1.awsstatic.com/webinars/jp/pdf/services/20180717_AWS-BlackBelt_OsakaLocalRegion_KIX_DR.pdf〉

【発明の概要】

【発明が解決しようとする課題】

【0006】

しかし、上述した従来のディザスタリカバリ技術をプライマリサイトがオンプレミス環境でセカンダリサイトをクラウド環境とするハイブリッドクラウド環境に適用した場合には、プライマリサイトで顧客（ユーザ）へのサービスの提供が行われる通常時から、セカンダリサイトのクラウド側のリソースの使用量が多くなることが想定され、クラウド側のリソースのコストが高くなってしまうという課題があった。顧客が利用するサービスは、プライマリサイトまたはセカンダリサイトで実行されるアプリケーションによって提供されるが、サービスごとに要求される性能は異なり、例えば安価なサービスにおいてリソースのコストが高くなることは好ましくない。

【0007】

本発明は以上の点を考慮してなされたもので、顧客が利用するサービスに適合するディザスタリカバリ構成を提供しつつディザスタリカバリシステム全体のコストを削減することが可能なディザスタリカバリシステム及びディザスタリカバリ方法を提案しようとするものである。

【課題を解決するための手段】

【0008】

かかる課題を解決するため本発明においては、通常時にサービスを提供するプライマリサイトにおける障害発生時に、当該プライマリサイトで実行されていた仮想計算機及びアプリケーションをセカンダリサイトで復旧するディザスタリカバリ構成を備えるディザスタリカバリシステムであって、アプリケーションを実行する仮想計算機を実行する第１のサーバシステムと、ストレージに前記第１のサーバシステムが使用するデータを格納する第１のストレージシステムと、を有するプライマリサイトと、クラウドストレージに前記第１のサーバシステムが使用するデータのバックアップ用データを格納する第２のストレージシステムと、前記障害発生時に、前記クラウドストレージに格納したバックアップ用データを用いて、前記プライマリサイトにおける対応関係を考慮した構成で前記仮想計算機及び前記アプリケーションを復旧する第２のサーバシステムと、を有するセカンダリサイトと、前記プライマリサイトと前記セカンダリサイトとによる前記ディザスタリカバリ構成を構築するための制御、及び前記プライマリサイトから前記セカンダリサイトに前記バックアップ用データを転送するデータ転送の仲介を行うクラウド管理ノードと、を備え、前記クラウド管理ノードは、前記プライマリサイトで実行される各前記アプリケーションの性能の重視性を示す重要度情報を当該アプリケーションを実行する前記仮想計算機と対応付けて管理し、前記仮想計算機ごとに、対応するアプリケーションの前記重要度情報に基づいて、複数種類のディザスタリカバリ方式のうちから当該仮想計算機及び当該アプリケーションに適用するディザスタリカバリ方式を決定し、前記仮想計算機ごとに、対応するアプリケーションの前記重要度情報に基づいて、当該仮想計算機が使用するデータの前記データ転送に適用される所定の設定項目の内容を決定するディザスタリカバリシステムが提供される。

【0009】

また、かかる課題を解決するため本発明においては、通常時にサービスを提供するプライマリサイトにおける障害発生時に、当該プライマリサイトで実行されていた仮想計算機及びアプリケーションをセカンダリサイトで復旧するディザスタリカバリ構成を備えるディザスタリカバリシステムによるディザスタリカバリ方法であって、前記ディザスタリカバリシステムは、アプリケーションを実行する仮想計算機を実行する第１のサーバシステムと、ストレージに前記第１のサーバシステムが使用するデータを格納する第１のストレージシステムと、を有するプライマリサイトと、クラウドストレージに前記第１のサーバシステムが使用するデータのバックアップ用データを格納する第２のストレージシステムと、前記障害発生時に、前記クラウドストレージに格納したバックアップ用データを用いて、前記プライマリサイトにおける対応関係を考慮した構成で前記仮想計算機及び前記アプリケーションを復旧する第２のサーバシステムと、を有するセカンダリサイトと、前記プライマリサイトと前記セカンダリサイトとによる前記ディザスタリカバリ構成を構築するための制御、及び前記プライマリサイトから前記セカンダリサイトに前記バックアップ用データを転送するデータ転送の仲介を行うクラウド管理ノードと、を有し、前記クラウド管理ノードが、前記プライマリサイトで実行される各前記アプリケーションの性能の重視性を示す重要度情報を当該アプリケーションを実行する前記仮想計算機と対応付けて管理し、前記仮想計算機ごとに、対応するアプリケーションの前記重要度情報に基づいて、複数種類のディザスタリカバリ方式のうちから当該仮想計算機及び当該アプリケーションに適用するディザスタリカバリ方式を決定し、前記仮想計算機ごとに、対応するアプリケーションの前記重要度情報に基づいて、当該仮想計算機が使用するデータの前記データ転送に適用される所定の設定項目の内容を決定するディザスタリカバリ方法が提供される。

【発明の効果】

【0010】

本発明によれば、顧客が利用するサービスに適合するディザスタリカバリ構成を提供しつつディザスタリカバリシステム全体のコストを削減することができる。

【図面の簡単な説明】

【0011】

【図1】本発明の一実施形態に係る情報処理システム１のハードウェア構成例を示すブロック図である。

【図2】情報処理システム１の運用イメージを示す図である。

【図3】メモリ３０２に格納される制御情報及び制御プログラムを示す図である。

【図4】ＶＭアプリ管理情報４１０の一例を示す図である。

【図5】アプリ重要度管理情報４２０の一例を示す図である。

【図6】重要度ＤＲ管理情報４３０の一例を示す図である。

【図7】ＤＲ管理情報４４０の一例を示す図である。

【図8】データ転送先決定処理の処理手順例を示すフローチャートである。

【図9】転送データ圧縮方法決定処理の処理手順例を示すフローチャートである。

【図10】データ転送ネットワーク決定処理の処理手順例を示すフローチャートである。

【図11】データ転送処理の処理手順例を示すフローチャートである。

【図12】パイロットライト方式におけるディザスタリカバリ処理の処理手順例を示すフローチャートである。

【図13】転送データ圧縮方法決定処理の別の処理手順例を示すフローチャートである。

【発明を実施するための形態】

【0012】

以下、図面を参照して、本発明の実施形態を詳述する。

【0013】

但し、以下の実施形態は本発明を説明するための例示であって、説明の明確化のため、適宜、省略及び簡略化がなされている。また、実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。本発明が実施形態に制限されることは無く、本発明の思想に合致するあらゆる応用例が本発明の技術的範囲に含まれる。本発明は、当業者であれば本発明の範囲内で様々な追加や変更等を行うことができる。本発明は、他の種々の形態でも実施する事が可能である。特に限定しない限り、各構成要素は複数でも単数でも構わない。

【0014】

なお、以下の説明では「テーブル」という表現にて本発明の情報を説明するが、これらの情報は必ずしもテーブルによるデータ構造で表現されていなくても良く、「リスト」や「ＤＢ（データベース）」等のデータ構造、あるいはそれ以外で表現されていても良い。そのため、データ構造に依存しないことを示すために「テーブル」、「リスト」、「ＤＢ」等については、単に「情報」と呼ぶこともできる。また、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ」という表現を用いることが可能であり、これらについてはお互いに置換が可能である。

【0015】

また、以下の説明では、プログラムを実行して行う処理を説明する場合があるが、プログラムは、少なくとも１以上のプロセッサ（例えばＣＰＵ）によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）及び／又はインターフェースデバイス（例えば通信ポート）等を用いながら行うため、処理の主体がプロセッサとされてもよい。同様に、プログラムを実行して行う処理の主体が、プロセッサを有するコントローラ、装置、システム、計算機、ノード、ストレージシステム、ストレージ装置、サーバ、管理計算機、クライアント、又は、ホストであってもよい。プログラムを実行して行う処理の主体（例えばプロセッサ）は、処理の一部又は全部を行うハードウェア回路を含んでもよく、また、モジュール化されていても良い。例えば、プログラムを実行して行う処理の主体は、暗号化及び復号化、又は圧縮及び伸張を実行するハードウェア回路を含んでもよい。各種プログラムはプログラム配布サーバや記憶メディアによって各計算機にインストールされてもよい。プロセッサは、プログラムに従って動作することによって、所定の機能を実現する機能部として動作する。プロセッサを含む装置及びシステムは、これらの機能部を含む装置及びシステムである。また、「リード／ライト処理」を「読み出し／書き込み処理」または「更新処理」等と記載することがある。

【0016】

また、各図においては、共通する構成に同一の参照番号が付されている。各図において同種の要素を区別しないで説明する場合には、参照符号又は参照符号における共通番号を使用し、同種の要素を区別して説明する場合は、その要素の参照符号を使用又は参照符号に代えてその要素に割り振られたＩＤを使用することがある。

【0017】

（１）構成
図１は、本発明の一実施形態に係る情報処理システム１のハードウェア構成例を示すブロック図である。

【0018】

情報処理システム１は、ディザスタリカバリ構成を提供するディザスタリカバリシステムであって、図１に示すように、プライマリサイト１００とセカンダリサイト２００とクラウド管理ノード３００とを備え、それぞれが互いにネットワーク１０（典型的にはＩＰ（Internet Protocol）ネットワーク）で接続される。本実施形態では、プライマリサイト１００にオンプレミスベースのストレージシステム（オンプレミスストレージ）を使い、セカンダリサイト２００にクラウドベースのストレージシステム（クラウドストレージ）を使ったディザスタリカバリ構成について説明するが、少なくともセカンダリサイト２００がクラウドストレージであればよく、プライマリサイト１００がクラウドストレージであっても本発明の本質は変わらない。また、記載の簡便のために「ディザスタリカバリ」をＤＲ（Disaster Recovery）と表記することがある。

【0019】

プライマリサイト１００は、通常状態においてアプリケーションによるサービスをユーザ（顧客）に提供するストレージシステムであって、オンプレミスストレージシステムからなり、具体的には、サーバシステム１１０、ストレージコントローラ１２０、及びオンプレミスストレージ１３０を備える。

【0020】

サーバシステム１１０は、プロセッサ１１１と、メモリ１１２と、ネットワークインターフェース（Ｉ／Ｆ）１１３とを有し、Ｉ／Ｆ１１３を介してネットワーク１０に接続される。ストレージコントローラ１２０は、メモリ１２２と、フロントエンドのネットワークインターフェース（Ｉ／Ｆ）１２４と、バックエンドのストレージインターフェース（Ｉ／Ｆ）１２３と、それらに接続されたプロセッサ１２１とを有する。ストレージコントローラ１２０は、Ｉ／Ｆ１２４を介してサーバシステム１１０に接続され、Ｉ／Ｆ１２３を介してオンプレミスストレージ１３０に接続される。オンプレミスストレージ１３０は、データを物理的に格納するストレージデバイスである。サーバシステム１１０及びストレージコントローラ１２０において、それぞれメモリ及びプロセッサは冗長化されている。

【0021】

メモリ１２２は、情報や１つ以上のプログラムを格納する。プロセッサ１２１が、当該１つ以上のプログラムを実行することで、サーバシステム１１０へのストレージ領域（ここでは論理ボリュームとして説明する）の提供、サーバシステム１１０からのライト要求やリード要求といったＩ／Ｏ（Input/Output）要求の処理を行う。例えば、ユーザ（顧客）が使用する上位装置（ホスト）からのボリュームを指定したライト要求やリード要求をサーバシステム１１０が受け、ストレージコントローラ１２０に送信する。そしてストレージコントローラ１２０が、当該ライト要求やリード要求に応答して、オンプレミスストレージ１３０内にある該当ボリュームに対するデータの読み書きを行う。

【0022】

ストレージコントローラ１２０及びオンプレミスストレージ１３０は、１つのストレージシステムとして構成されてもよい。例えば、ＲＡＩＤ（Redundant Array of Independent (or Inexpensive) Disks）技術によるハイエンド向けストレージシステムやフラッシュメモリを用いたストレージシステム等がある。

【0023】

オンプレミスストレージ１３０の構成は、例えば、それぞれが記憶装置を有する複数のストレージノードを備えたマルチノード構成のノード群（例えば分散システム）でもよい。各ストレージノードは、汎用の物理計算機でよい。各物理計算機が所定のソフトウェアを実行することにより、ＳＤｘ（Software-Defined anything）が構築されてよい。ＳＤｘとしては、例えば、ＳＤＳ（Software Defined Storage）又はＳＤＤＣ（Software-defined Datacenter）を採用することができる。また、オンプレミスストレージ１３０が、ハイパーコンバージドインフラストラクチャベースのストレージシステム、例えば、Ｉ／Ｏ要求を発行するホストシステムとしての機能（例えば、Ｉ／Ｏ要求を発行するアプリケーションの実行体（例えば、仮想マシンやコンテナ））と、当該Ｉ／Ｏ要求を処理するストレージシステムとしての機能（例えば、ストレージソフトウェアの実行体（例えば、仮想マシンやコンテナ）とを有するシステムでもよい。オンプレミスストレージ１３０の構成の一例でありこれに限定されない。

【0024】

セカンダリサイト２００は、地震や火災といった大規模災害が発生した場合のプライマリサイト１００におけるデータロストに備えてプライマリサイト１００のデータを保持し、プライマリサイト１００で障害等が発生した場合に、上記保持したデータを用いてプライマリサイト１００のデータ及びサービスを復旧するディザスタリカバリサイト（ＤＲサイト）である。本実施形態に係る情報処理システム１においてセカンダリサイト２００は、典型的にはパブリッククラウドに属し、クラウドベンダが提供するクラウドストレージサービスのベースとなるクラウドストレージシステムである。クラウドストレージサービスとしては、例えば、ＡＷＳ（Amazon Web Services）（登録商標）、Azure（登録商標）、Google Cloud Platform（登録商標）などがある。セカンダリサイト２００に利用されるクラウドストレージシステムは、パブリッククラウドに代えて、他種のクラウド（例えば、プライベートクラウド）に属するストレージシステムでもよい。ここでは一例としてパブリッククラウドの構成を用いて説明する。

【0025】

セカンダリサイト２００は、サーバシステム２１０及びストレージシステム２２０を備え、ネットワーク１０に接続される。

【0026】

サーバシステム２１０は、プロセッサ２１１と、メモリ２１２（更にストレージを持ってもよい）と、ネットワークインターフェース（図示せず）とを有し、当該ネットワークインターフェースを介してネットワーク１０に接続される。ストレージシステム２２０は、ハイエンド向けのコストが高い第１のストレージ装置２２１や低コストで大容量の第２のストレージ装置２２２等、性能や容量コストの異なるストレージを含む。第１のストレージ装置２２１及び第２のストレージ装置２２２は、ストレージコントローラ１２０と同様な部分と、データを物理的に格納する部分とからなる。ストレージシステム２２０の具体例として、第１のストレージ装置２２１はＡＷＳにおいて「ＥＢＳ」と称されるストレージサービスで提供されるブロックストレージに相当し、第２のストレージ装置２２２はＡＷＳにおいて「Ｓ３」と称されるストレージサービスで提供されるオブジェクトストレージに相当する。オブジェクトストレージはデータの同期ができないという性質を有する。

【0027】

クラウドサービス管理２３０は、クラウドサービス全般を管理する機能を有するコンポーネントである。クラウドは、クラウドサービス内に設けたクラウドサービス管理２３０がユーザの要求を受け、クラウド内に含まれる複数の異なるスペックのリソースの中からユーザの要求に合う適切なリソースを選択し、ユーザの要求された環境を構築するという利用方法が一般的であり、本実施形態のセカンダリサイト２００も同様とする。クラウドサービス内の主なリソースにはサーバシステム（すなわち、サーバシステム２１０）及びストレージシステム（ストレージシステム２２０）がある。クラウドサービス管理２３０は、例えば、アプライアンス（専用機器）であってもよいし、物理計算機でもよい。また、クラウドサービス管理２３０は、サーバシステム２１０の一部にあってもよいし、クラウド管理ノード３００内にあってもよい。以下の説明では、クラウドサービス内のサーバシステム２１０の１つのメモリ２１２内に格納されたプログラムとして説明する（図１では、分かり易さのために、セカンダリサイト２００内にサーバシステム２１０のメモリ２１２とは別構成で示している）。

【0028】

クラウド管理ノード３００は、プライマリサイト１００とセカンダリサイト２００とでＤＲ構成を構築するための制御を行ったり、プライマリサイト１００とセカンダリサイト２００と間のデータ転送を仲介したりするアプライアンスである。例えば、クラウド管理ノード３００は、セカンダリサイト２００のクラウドサービス内にあってもよいし、クラウドサービス管理２３０にあってもよい。本説明では一例として、クラウド管理ノード３００は、メモリ３０２及びＩ／Ｆ３０３と、それらに接続されたプロセッサ３０１とを有する物理計算機であるとする。

【0029】

なお、プライマリサイト１００におけるオンプレミスストレージ１３０とセカンダリサイト２００におけるクラウドストレージ（第１のストレージ装置２２１，第２のストレージ装置２２２）と間のデータ転送は、図１に示す情報処理システム１ではネットワーク１０を介して直接転送する方法としているが、これに限定されるものではなく、データ転送用の別のネットワーク経路や回線を用いて転送する方法でもよい。また、あらゆるネットワークや回線の種類は、本発明の本質ではない。

【0030】

また、ネットワーク１０にはストレージ管理システムが接続されていてもよい。例えば、このストレージ管理システムは、オンプレミスストレージ１３０の記憶領域の構成を管理する計算機システム（１つ以上の計算機）であり、オンプレミスストレージ１３０に関する設定をユーザから指示することができる。

【0031】

図２は、情報処理システム１の運用イメージを示す図である。

【0032】

図２に示したように、プライマリサイト１００内では、１以上のサーバシステム１１０からなるサーバ（サーバ群）１５１上に、１つ以上のＶＭ１５２が生成される。ＶＭ１５２は仮想マシンであり、各ＶＭ１５２上ではユーザに指定されたアプリ１５３が実行される。ユーザに指定されたアプリ１５３とは、ユーザにサービスを提供するアプリケーションであって、ユーザが利用するサービスの指定によって、当該サービスに対応するアプリ１５３が指定される。

【0033】

プライマリサイト１００において、データは、容量仮想化技術によりプール１４０を介してオンプレミスストレージ１３０内の記憶領域に格納される。ストレージ制御プログラム１２５は、ストレージコントローラ１２０のメモリ１２２内に格納されたプログラムであって、オンプレミスストレージ１３０を制御する。コピー機能１２６は、ストレージコントローラ１２０のメモリ１２２内に格納されたプログラムによって実現される機能（あるいはそのプログラム）であって、プライマリサイト１００のオンプレミスストレージ１３０に格納されたデータを複製してセカンダリサイト２００に転送する機能を有する。

【0034】

サーバシステム１１０のメモリ１１２内には、ＶＭ制御情報（不図示）が格納される。ＶＭ制御情報は、オンプレミスストレージ１３０内に格納されてもよい。ＶＭ制御情報は、ＶＭ１５２の制御のための情報、例えば、各ＶＭ１５２へ割り当てられるリソース（例えばボリューム）の量を表す情報を含む。

【0035】

前述したように、ＶＭ１５２上で実行するアプリ１５３は、ユーザによって指示される。サーバ１５１のメモリ（すなわち、サーバシステム１１０のメモリ１１７）には、ＶＭと実行するアプリ１５３との識別子の対応情報が格納されている。あるいは、この識別子の対応情報は、ネットワーク１０を介して接続される不図示のストレージ管理システム（オンプレミスストレージ１３０の記憶領域の構成を管理する計算機システム）内に格納されていてもよい。

【0036】

情報処理システム１は、クラウド管理ノード３００がプライマリサイト１００のリソース構成情報及びアプリ情報を取得し、クラウドサービス側に指示することで、セカンダリサイト２００がプライマリサイト１００と同じＶＭ（ＶＭ２５２）とアプリ（アプリ２５３）を実行する、ＤＲ環境を構築することができる。プライマリサイト１００のリソース構成情報及びアプリ情報は、例えばサーバシステム１１０のメモリ１１２またはオンプレミスストレージ１３０に格納されるが、ネットワーク１０を介して接続される不図示のストレージ管理システム内に格納されてもよい。

【0037】

前述したとおり、ディザスタリカバリ（ＤＲ）には異なるレベルの方法があり、本実施形態に係る情報処理システム１は、このような異なるレベルのＤＲ方法を利用することができる。ＤＲ方法は、ユーザが選択して指示することもできるし、システム側で自動的に選択することもできる。また、ＤＲ方法は、ＶＭ単位、あるいはボリューム単位などで指定することができる。ここではＶＭ単位でＤＲ方法を指定することを例とする。

【0038】

サービスの提供のために仮想マシン（ＶＭ）上で実行されるアプリケーションには、性能が最も重視されるアプリケーションもあれば、ＲＴＯ（Recovery Time Objective）が多少下がっても許容されるアプリケーションもあり、アプリケーションごとに性能の重視性が異なる。そこで、本実施形態に係る情報処理システム１は、ＶＭ１５２上で実行されるアプリ１５３ごとに、アプリ１５３の性能の重視性を表す「重要度」の情報を管理し、この重要度の情報に基づいて、ＶＭごとに適したディザスタリカバリレベル（ＤＲ方法）を選択してクラウドＤＲ構成を構築する。

【0039】

具体的には例えば、図２に示すように、プライマリサイト１００の「ＶＭ２」上で実行される「アプリ２」が重要度が高いアプリケーションである場合、セカンダリサイト２００のクラウド内において「ＶＭ２」でマルチサイト方式を選択することにより、重要度が高い「アプリ２」のサーバリソースをＤＲ構成の構築開始後すぐに確保する。一方、プライマリサイト１００の「ＶＭ１」上で実行される「アプリ１」が重要度が低いアプリケーションである場合、セカンダリサイト２００のクラウド内において「ＶＭ１」でパイロットライト方式を選択することにより、重要度が低い「アプリ１」のサーバリソースをＤＲ構成の構築開始時には確保しない。「ＶＭ１」にパイロットライト方式を選択した場合、「アプリ１」のサーバリソースは、プライマリサイト１００からセカンダリサイト２００に業務処理を切り替える時点で確保される。

【0040】

このように、本実施形態に係る情報処理システム１は、ＤＲ方法を選択する際に参照するアプリの重要度の情報を利用し、プライマリサイト１００とセカンダリサイト２００との間のデータ転送に関して、重要度に応じたデータ転送方法及びデータ転送先ストレージ装置選択方法、もしくは、これら組み合わせた方法を実施することで、クラウドＤＲのコスト削減を実現することができる。

【0041】

以下に、本実施形態に係る情報処理システム１におけるＤＲ環境構築の手順の概要を説明する。

【0042】

まず、プライマリサイト１００のアプリ１５３の「重要度」の情報は、例えば、コマンドやユーザ入力用ＧＵＩ（Graphical User Interface）からの入力によるユーザの指示を受けた結果や、クラウド管理ノード３００が情報を収集し分析して得られた結果等から、クラウド管理ノード３００（プロセッサ３０１）がアプリの「重要度」の情報を決定し、クラウド管理ノード３００のメモリ３０２内のアプリ重要度管理情報４２０（詳細は、図５で後述）に予め登録されているとする。本実施形態で説明する例では、プライマリサイト１００で生成された「ＶＭ１」のＶＭ１５２で実行する「アプリ１」のアプリ１５３は重要度が低く、「ＶＭ２」のＶＭ１５２で実行する「アプリ２」のアプリ１５３は重要度が高い。

【0043】

次に、クラウド管理ノード３００（プロセッサ３０１）は、アプリ重要度管理情報４２０に登録された重要度の情報を参照し、当該重要度に応じたＤＲ方法を決定し、重要度ＤＲ管理情報４３０（詳細は、図６で後述）に登録する。前述したように、ＶＭ上で実行されるアプリには、性能を重視するものや、多少ＲＴＯが下がっても許容されるもの（性能をそこまで重視しないもの）があるため、例えば、ＲＴＯを重視するアプリ（すなわち、重要度が高いアプリ）を実行するＶＭはマルチサイト方式によってＤＲ環境を構築し、ＲＴＯの低下が許容されるアプリ（すなわち、重要度が低いアプリ）を実行するＶＭではパイロットライト方式によってＤＲ環境を構築する。

【0044】

具体的にはまず、クラウド管理ノード３００は、プライマリサイト１００のＶＭ制御情報とＶＭ１５２上で実行するアプリ１５３の情報とをプライマリサイト１００から受け取り、ＶＭアプリ管理情報４１０で管理する。そして、クラウド管理ノード３００は、重要度の情報を参照してＶＭ１５２（ＶＭ２５２）に対するＤＲ方法を選択し、セカンダリサイト２００へＤＲ環境構築要求の指示を出す。

【0045】

そして、セカンダリサイト２００内のクラウドサービス管理２３０は、上記のＤＲ環境構築の要求に従って、要求に合うクラウド内のリソースを選択し割り当てを行う。

【0046】

例えば、重要度が低いアプリ１に対応するＤＲ構成では、平常時はＤＲ先（セカンダリサイト２００内）にサーバシステム等のリソースを確保せず、障害の発生に対するフェイルオーバ起動の際に当該リソースを確保する。平常時にＤＲ先にリソースが確保されないことについて、図２のセカンダリサイト２００では、重要度が低い「アプリ１」（アプリ２５３）、当該アプリを実行する「ＶＭ１」（ＶＭ２５２）、及び当該ＶＭを生成するサーバ２５１が破線で表されている。但し、このようなＤＲ構成でも、プライマリサイト１００のデータは常にＤＲ先に転送する。これがパイロットライト方式である。

【0047】

また例えば、重要度が高いアプリ２に対応するＤＲ構成では、平常時からＤＲ先（セカンダリサイト２００内）にプライマリサイト１００と同じサーバ環境を構築する。また、プライマリサイト１００のデータは常にＤＲ先に転送する。これがマルチサイト方式である。

【0048】

クラウドでは、リソースを割り当てた時点でリソースの使用量に対して課金が発生するため、上記のように重要度が低いアプリのリソース割り当てを必要となる直前まで極力行わないようにすることで、ＤＲのコストを低減することができる。

【0049】

なお、プライマリサイト１００のデータは、クラウド管理ノード３００のＤＲ管理プログラム４６０（図３参照）により、クラウド管理ノード３００を介してセカンダリサイト２００内に転送される。プライマリサイト１００とセカンダリサイト２００との間のデータ転送は、複数種類のデータ転送方法のバリエーションのうちから選択された方法で実施され、その決定方法は図８を参照して後述される。

【0050】

図３は、メモリ３０２に格納される制御情報及び制御プログラムを示す図である。図３に示したように、クラウド管理ノード３００のメモリ３０２には、制御情報として、ＶＭアプリ管理情報４１０、アプリ重要度管理情報４２０、重要度ＤＲ管理情報４３０、及びＤＲ管理情報４４０が格納される。これらの制御情報は、図４～図７に具体例を示す。また、メモリ３０２には、制御プログラムとして、ＤＲ管理プログラム４６０が格納される。なお、メモリ３０２には図示していないプログラムも格納される。

【0051】

ＤＲ管理プログラム４６０は、プライマリサイト１００とセカンダリサイト２００との間でのＤＲ環境構築の指示、ＶＭ及びアプリについてＤＲ環境で対応するペアの形成、及び、プライマリサイト１００からセカンダリサイト２００へのデータ転送制御などを行う。

【0052】

図４は、ＶＭアプリ管理情報４１０の一例を示す図である。ＶＭアプリ管理情報４１０は、プライマリサイト１００のサーバ１５１上に生成されたＶＭ１５２に関する管理情報を含む。図４に例示したＶＭアプリ管理情報４１０は、ＶＭ４１１、アプリ４１２、ＤＲ方法４１３、転送先４１４、圧縮方法４１５、転送方法４１６、及びネットワーク４１７の項目を有して構成される。

【0053】

ＶＭ４１１には、ＶＭ１５２を特定する識別子が格納され、アプリ４１２には、当該ＶＭ上で実行されるアプリ１５３の識別子が格納される。例えば図４によれば、「ＶＭ１」は「アプリ１」を実行し、「ＶＭ２」は「アプリ２」を実行することが示される。ＶＭ４１１及びアプリ４１２の情報は、ＤＲ管理プログラム４６０がプライマリサイト１００側から対応する情報を取得して、ＶＭアプリ管理情報４１０に予め登録される。

【0054】

ＤＲ方法４１３には、ＶＭ１５２をＤＲする際のＤＲ方法が格納される。ＤＲ方法４１３の情報は、クラウド管理ノード３００（ＤＲ管理プログラム４６０）がアプリ重要度管理情報４２０及び重要度ＤＲ管理情報４３０を参照して、アプリ１５３の重要度に応じたＤＲ方法を決定し、その決定結果が登録される。具体的には本例の場合、ＤＲ管理プログラム４６０は、重要度が「高い」アプリ１５３を実行するＶＭ１５２はマルチサイト方式によってＤＲ環境を構築するとし、重要度が「低い」アプリ１５３を実行するＶＭ１５２はパイロットライト方式によってＤＲ環境を構築するように決定する。すなわち、「アプリ２」を実行する「ＶＭ２」のＤＲ方法４１３には「マルチサイト」方式が登録され、アプリ１」を実行する「ＶＭ１」のＤＲ方法４１３には「パイロットライト」方式が登録される。このようなＤＲ方法の決定は、顧客が要望するサービスに適合するものである。

【0055】

転送先４１４には、ＤＲ先（厳密には、転送データの格納先）のストレージの機種情報が格納される。具体的には例えば、「ＶＭ１」は重要度が低い「アプリ１」を実行することから、ＤＲの転送先ストレージ機種も性能重視ではない。そこで図４の場合、「ＶＭ１」に対応する転送先４１４には、性能重視ではないが、コストパフォーマンスに優れ、容量に上限がないストレージサービスとして「Ｓ３」が登録されている。一方、「ＶＭ２」は重要度が高い「アプリ２」を実行することから、「ＶＭ２」に対応する転送先４１４には、高性能なストレージサービスとして「ＥＢＳ」が登録されている。なお、転送先４１４に格納されるストレージの機種情報は、装置名に限定される必要はなく、他にも例えば、ハイエンドやミッドレンジ等のストレージクラスを示す識別子等でもよい。転送先４１４の情報は、ＤＲ管理プログラム４６０が後述するデータ転送先決定処理（図８参照）を実行することによって、決定及び登録される。

【0056】

圧縮方法４１５には、ＶＭ１５２が使用するデータをストレージデバイスに格納する際の圧縮アルゴリズムの種類が格納される。情報処理システム１では、データの圧縮または伸長に関して特徴が異なる複数種類の圧縮アルゴリズム（圧縮方法）が用意されており、それらのうち、図４に示した「アルゴリズム１」はデータの圧縮率が高い圧縮アルゴリズムであり、「アルゴリズム２」は圧縮データの伸長速度が速い（伸長時間が短い、と読み替えても良い）圧縮アルゴリズムであるとする。圧縮方法４１５の情報は、ＤＲ管理プログラム４６０がプライマリサイト１００側から対応する情報を取得し、後述する転送データ圧縮方法決定処理（図９参照）を実行することによって、決定及び登録される。具体的には図４の場合、「ＶＭ１」に対応する圧縮方法４１５に「アルゴリズム１」が登録されており、「ＶＭ２」に対応する圧縮方法４１５に「アルゴリズム２」が登録されている。この場合、「ＶＭ１」で使用するデータは、「アルゴリズム１」を使ったデータ圧縮が実施された上でオンプレミスストレージ１３０に格納され、「ＶＭ２」で使用するデータは、「アルゴリズム２」を使ったデータ圧縮が実施された上でオンプレミスストレージ１３０に格納されることを意味する。

【0057】

転送方法４１６には、プライマリサイト１００からセカンダリサイト２００へのデータ転送において実施されるデータ転送方法が格納される。転送方法４１６に格納されるデータ転送方法としては、例えば図４に示したように、データを同期してコピーする「同期コピー」、データを非同期でコピーする「非同期コピー」が挙げられるが、その他のデータ転送方法が選択されてもよい。転送方法４１６の情報は、ＤＲ管理プログラム４６０が後述するデータ転送先決定処理（図８参照）を実行することによって、決定及び登録される。

【0058】

ネットワーク４１７には、プライマリサイト１００からセカンダリサイト２００へのデータ転送の経路（ネットワーク）について、使用する回線の種類や帯域等によるネットワーク種類を示す情報が格納される。図４に示した「低速」は、安価で通信速度が遅いネットワーク帯域を使用することを意味し、「高速」は、高価で通信速度が速いネットワーク帯域を使用することを意味する。ネットワーク４１７の情報は、ＤＲ管理プログラム４６０が後述するデータ転送ネットワーク決定処理（図１０参照）を実行することによって、決定及び登録される。

【0059】

図５は、アプリ重要度管理情報４２０の一例を示す図である。アプリ重要度管理情報４２０は、ＶＭ１５２上で実行されるアプリ１５３の重要度を示す情報を含む。図５に例示したアプリ重要度管理情報４２０は、アプリ４２１及び重要度４２２の項目を有して構成される。

【0060】

アプリ４２１には、ＶＭ１５２上で実行されるアプリ１５３を特定する識別子が格納され、重要度４２２には、当該アプリについて、前述したようにアプリケーションの性能重視性等から予め設定される「重要度」が格納される。アプリの「重要度」は、ユーザが指定して登録するとしてもよいし、計算機側で過去の情報を分析して自動的に設定する等としてもよい。図５の場合、「アプリ１」は重要度が「低い」アプリであり、「アプリ２」は重要度が「高い」アプリであることが登録されている。なお、重要度４２２に格納される値は、「重要度」を特定可能な識別子や数値等であってもよい。また、重要度の段階数は２以上であればいくつでもよい。また、アプリの「重要度」は、予め設定されているとしたが、ユーザによる指定やプログラムによる分析等を受けて、システムの運用途中で変更可能としてもよい。

【0061】

図６は、重要度ＤＲ管理情報４３０の一例を示す図である。重要度ＤＲ管理情報４３０は、アプリ重要度管理情報４２０の重要度４２２に登録されたアプリの重要度に対応するＤＲ方法の情報を含む。図６に例示した重要度ＤＲ管理情報４３０は、重要度４３１及びＤＲ方法４３２の項目を有して構成される。

【0062】

重要度４３１には、アプリケーションの性能重視性等から予め設定されるアプリの重要度が格納され、これは、アプリ重要度管理情報４２０に登録される重要度４２２と対応する。ＤＲ方法４３２には、アプリの重要度に対応するＤＲ方法が格納される。重要度ＤＲ管理情報４３０の各情報は、ユーザによって予め登録されるとする。例えば図６の重要度ＤＲ管理情報４３０では、重要度が低いアプリをＤＲする場合にはパイロットライト方式によるＤＲ環境を構築し、重要度が高いアプリをＤＲする場合にはマルチサイト方式によるＤＲ環境を構築する、ことが設定される。

【0063】

図７は、ＤＲ管理情報４４０の一例を示す図である。ＤＲ管理情報４４０は、ＤＲ環境において対応するペアの関係（ＤＲ関係）を示す情報を含む。図７に例示したＤＲ管理情報４４０は、プライマリ４４１及びセカンダリ４４２の項目を有して構成される。

【0064】

プライマリ４４１には、ＤＲのプライマリ側の各構成（プライマリサイト１００やＶＭ１５２等）を示す識別子が格納され、セカンダリ４４２には、プライマリ４４１に対応するかたちで、ＤＲのセカンダリ側の各構成（セカンダリサイト２００やＶＭ２５２等）を示す識別子が格納される。

【0065】

（２）処理
以下では、上述した構成を用いて、本実施形態に係る情報処理システム１においてＤＲ環境構築のために実行される各種処理について詳しく説明する。

【0066】

（２－１）データ転送先決定処理
図８は、データ転送先決定処理の処理手順例を示すフローチャートである。データ転送先決定処理は、プライマリサイト１００からセカンダリサイト２００へのデータ転送におけるデータ転送先ストレージ及びデータ転送方法を決定する処理であって、クラウド管理ノード３００のＤＲ管理プログラム４６０によってＶＭ１５２ごとに実行される。

【0067】

図８によればまず、ＤＲ管理プログラム４６０は、ＶＭアプリ管理情報４１０とアプリ重要度管理情報４２０とを参照し、処理対象のＶＭ１５２が実行するアプリ１５３の重要度を求める（ステップＳ１０１）。

【0068】

次に、ＤＲ管理プログラム４６０は、ステップＳ１０１で求めたアプリの重要度を参照して、重要度に対する所定の判定基準を満たしているかを確認し（ステップＳ１０２）、その判定結果に応じて、ＤＲ先であるクラウドサービス（セカンダリサイト２００）内のストレージリソースのうちから、データ転送先のストレージリソースのクラス（もしくは、クラウドサービスに指定できるストレージの機種等でもよい）を決定する。図８に示した処理例では、ステップＳ１０１で求めたアプリの重要度が「高い」場合（ステップＳ１０２のＹＥＳ）、ステップＳ１０３に進み、ステップＳ１０１で求めたアプリの重要度が「低い」場合（ステップＳ１０２のＮＯ）、ステップＳ１０５に進む。

【0069】

ステップＳ１０２からステップＳ１０３に進んだ場合、ＤＲ管理プログラム４６０は、クラウド内のハイエンドのストレージ装置を、処理対象のＶＭ１５２が使用するデータのデータ転送先に決定し、決定内容をＶＭアプリ管理情報４１０の転送先４１４に登録する。具体例で説明すると、重要度が高いアプリ２を実行するＶＭ２が使用するデータのデータ転送先として第１のストレージ装置２２１が決定され、ＶＭ２（アプリ２）に対応する転送先４１４に、第１のストレージ装置２２１の機種情報である「ＥＢＳ」が登録される。

【0070】

さらに、次のステップＳ１０４において、ＤＲ管理プログラム４６０は、データ転送方法を決定し、決定内容をＶＭアプリ管理情報４１０の転送方法４１６に登録する。ステップＳ１０３においてハイエンドのストレージ装置（第１のストレージ装置２２１）がデータ転送先とされたことからも分かるように、重要度が高いアプリ２のデータは、重要なデータであり、ＲＰＯ（Recovery Point Objective）も重視される。したがって、ステップＳ１０４においてＤＲ管理プログラム４６０は、ＶＭ２が使用するデータのプライマリサイト１００からセカンダリサイト２００へのデータ転送方法として、同期コピーによるデータ転送方法を選択し、ＶＭ２（アプリ２）に対応する転送方法４１６に「同期コピー」を登録する。

【0071】

一方、ステップＳ１０２からステップＳ１０５に進んだ場合、ＤＲ管理プログラム４６０は、クラウド内の低コストのストレージ装置を、処理対象のＶＭ１５２が使用するデータのデータ転送先に決定し、決定内容をＶＭアプリ管理情報４１０の転送先４１４に登録する。具体例で説明すると、重要度が低いアプリ１を実行するＶＭ１が使用するデータのデータ転送先として第２のストレージ装置２２２が決定され、ＶＭ１（アプリ１）に対応する転送先４１４に、第２のストレージ装置２２２の機種情報である「Ｓ３」が登録される。

【0072】

さらに、次のステップＳ１０６において、ＤＲ管理プログラム４６０は、データ転送方法を決定し、決定内容をＶＭアプリ管理情報４１０の転送方法４１６に登録する。ステップＳ１０５において低コストのストレージ装置（第２のストレージ装置２２２）がデータ転送先とされたことからも分かるように、重要度が低いアプリ１のデータは、多少ＲＴＯが低下しても許容されるデータと考えられる。したがって、ステップＳ１０６においてＤＲ管理プログラム４６０は、ＶＭ１が使用するデータのプライマリサイト１００からセカンダリサイト２００へのデータ転送方法として、非同期コピーによるデータ転送方法を選択し、ＶＭ１（アプリ１）に対応する転送方法４１６に「非同期コピー」を登録する。

【0073】

そしてステップＳ１０４またはステップＳ１０６が終了すると、ＤＲ管理プログラム４６０は、データ転送先決定処理を終了する。

【0074】

なお、データ転送先決定処理の変形例として、例えば、ＤＲ管理プログラム４６０は、アプリの重要度が高い場合に、ステップＳ１０４において非同期コピーのデータ転送方法を選択するようにしてもよい。また、ＤＲ管理プログラム４６０は、決定されたデータ転送先のストレージデバイスがオブジェクトストレージである場合は、オブジェクトストレージではデータの上書き処理ができないという性質を鑑みて、非同期コピーによるデータ転送方法を選択する。また、ＤＲ管理プログラム４６０は、非同期コピーによるデータ転送方法を選択する場合には、非同期コピーに属する複数のデータ転送方法のうちから何れかを選択するようにしてもよい。例えば、同期を一切とらない非同期コピーの他にも、スナップショットの差分を定期的に転送する差分コピーと呼ばれる方法がある。

【0075】

以上のように、ＤＲ管理プログラム４６０は、ＶＭ１５２上で実行されるアプリ１５３の重要度に基づいてデータ転送先決定処理を実行することにより、プライマリサイト１００からセカンダリサイト２００へのデータ転送におけるデータ転送先ストレージ及びデータ転送方法を、顧客が利用するサービス（アプリケーション）に応じて適切に決定することができる。

【0076】

（２－２）転送データ圧縮方法決定処理
図９は、転送データ圧縮方法決定処理の処理手順例を示すフローチャートである。転送データ圧縮方法決定処理は、プライマリサイト１００からセカンダリサイト２００に転送するデータの圧縮方法を決定する処理であって、クラウド管理ノード３００のＤＲ管理プログラム４６０によってＶＭ１５２ごとに実行される。

【0077】

本実施形態に係る情報処理システム１は、プライマリサイト１００のオンプレミスストレージ１３０に格納されたデータを所定の圧縮方法（圧縮アルゴリズム）によって圧縮し、圧縮したままセカンダリサイト２００に転送することにより、データ転送時間を削減し、転送コストを削減することができる。また、ＤＲ先（セカンダリサイト２００）に転送された圧縮データは、必要になったとき（例えば、パイロットライト方式であれば障害発生に対するフェイルオーバ起動の際）に伸長されることから、クラウドにおけるＤＲコストを削減することができる。

【0078】

図９によればまず、ＤＲ管理プログラム４６０は、図８のステップＳ１０１と同様に、ＶＭアプリ管理情報４１０とアプリ重要度管理情報４２０とを参照し、処理対象のＶＭ１５２が実行するアプリ１５３の重要度を求める（ステップＳ２０１）。

【0079】

次に、ＤＲ管理プログラム４６０は、ステップＳ２０１で求めたアプリの重要度を参照して、重要度に対する所定の判定基準を満たしているかを確認し（ステップＳ２０２）、その判定結果に応じて、転送データの圧縮方法を決定する。図９に示した処理例では、ステップＳ２０１で求めたアプリの重要度が「高い」場合（ステップＳ２０２のＹＥＳ）、ステップＳ２０３に進み、ステップＳ２０１で求めたアプリの重要度が「低い」場合（ステップＳ２０２のＮＯ）、ステップＳ２０４に進む。

【0080】

ステップＳ２０２からステップＳ２０３に進んだ場合、ＤＲ管理プログラム４６０は、予め用意された複数種類の圧縮アルゴリズムのうちから、伸長速度が速い（伸長時間が短い）圧縮アルゴリズムを、転送データの圧縮方法に決定し、その決定内容をＶＭアプリ管理情報４１０の圧縮方法４１５に登録する。前述したように、重要度が高いアプリ２を実行するＶＭ２に対してはマルチサイト方式でＤＲ環境が構築されることから、ＤＲ先へのデータ転送を短時間で行うことが重要である。すなわち、重要度が高いアプリ２のデータは、データの圧縮率の高さよりも、圧縮データの伸長速度の速さ（伸長時間の短さ）が重視される。そこでステップＳ２０３においてＤＲ管理プログラム４６０は、圧縮率は高くなくても伸長速度が速い「アルゴリズム２」を、アプリ２（ＶＭ２）のデータの圧縮方法として決定し、ＶＭ２（アプリ２）に対応する圧縮方法４１５に「アルゴリズム２」を登録する。

【0081】

一方、ステップＳ２０２からステップＳ２０４に進んだ場合、ＤＲ管理プログラム４６０は、予め用意された複数種類の圧縮アルゴリズムのうちから、圧縮率が高い圧縮アルゴリズムを、転送データに使用する圧縮方法に決定し、その決定内容をＶＭアプリ管理情報４１０の圧縮方法４１５に登録する。前述したように、重要度が低いアプリ１を実行するＶＭ１ではパイロットサイト方式でＤＲ環境が構築されることから、ＤＲ先のリソース使用量を抑制することが重要である。すなわち、重要度が低いアプリ１のデータは、圧縮データの伸長速度の速さ（伸長時間の短さ）よりも、データの圧縮率の高さが重視される。そこでステップＳ２０４においてＤＲ管理プログラム４６０は、圧縮データの伸長は速くなくても圧縮率が高い「アルゴリズム１」を、アプリ１（ＶＭ１）のデータの圧縮方法として決定し、ＶＭ１（アプリ１）に対応する圧縮方法４１５に「アルゴリズム１」を登録する。

【0082】

そしてステップＳ２０３またはステップＳ２０４が終了すると、ＤＲ管理プログラム４６０は、転送データ圧縮方法決定処理を終了する。

【0083】

なお、上述した転送データ圧縮方法決定処理ではＶＭ１５２ごとに圧縮アルゴリズムを決定するとしたが、変形例として、ＤＲ管理プログラム４６０は、１ボリュームごと、もしくは１ボリューム内のデータ領域ごとに、圧縮アルゴリズムを決定するようにしてもよい。

【0084】

（２－３）データ転送ネットワーク決定処理
図１０は、データ転送ネットワーク決定処理の処理手順例を示すフローチャートである。データ転送ネットワーク決定処理は、プライマリサイト１００とセカンダリサイト２００との間でデータを転送する際に使用されるネットワーク種類を決定する処理であって、クラウド管理ノード３００のＤＲ管理プログラム４６０によってＶＭ１５２ごとに実行される。

【0085】

図１０によればまず、ＤＲ管理プログラム４６０は、図８のステップＳ１０１や図９のステップＳ２０１と同様に、ＶＭアプリ管理情報４１０とアプリ重要度管理情報４２０とを参照し、処理対象のＶＭ１５２が実行するアプリ１５３の重要度を求める（ステップＳ３０１）。

【0086】

次に、ＤＲ管理プログラム４６０は、ステップＳ３０１で求めたアプリの重要度を参照して、重要度に対する所定の判定基準を満たしているかを確認し（ステップＳ３０２）、その判定結果に応じて、処理対象のＶＭ１５２のデータ転送において使用するネットワーク種類を決定する。図１０に示した処理例では、ステップＳ３０１で求めたアプリの重要度が「高い」場合（ステップＳ３０２のＹＥＳ）、ステップＳ３０３に進み、ステップＳ３０１で求めたアプリの重要度が「低い」場合（ステップＳ３０２のＮＯ）、ステップＳ３０４に進む。

【0087】

ステップＳ３０２からステップＳ３０３に進んだ場合、ＤＲ管理プログラム４６０は、高速で高価なネットワーク帯域を処理対象のＶＭ１５２が使用するデータのデータ転送に用いるネットワーク種類に決定し、決定内容を示す情報をＶＭアプリ管理情報４１０のネットワーク４１７に登録する。具体例で説明すると、重要度が高いアプリ２のデータはＲＴＯを重視することから、ステップＳ３０３においてＤＲ管理プログラム４６０は、高速（高価）なネットワークの帯域を使用してプライマリサイト１００からセカンダリサイト２００にデータを転送することを決定し、当該決定したネットワーク種類を示す情報として、ＶＭ２（アプリ２）に対応するネットワーク４１７に「高速」を登録する。高速なネットワークの具体例としては、ＡＷＳ Ｄｉｒｅｃｔ Ｃｏｎｎｅｃｔが挙げられる。

【0088】

一方、ステップＳ３０２からステップＳ３０４に進んだ場合、ＤＲ管理プログラム４６０は、低速で安価なネットワーク帯域を処理対象のＶＭ１５２が使用するデータのデータ転送に用いるネットワーク種類に決定し、決定内容を示す情報をＶＭアプリ管理情報４１０のネットワーク４１７に登録する。具体例で説明すると、重要度が低いアプリ１のデータはＲＴＯよりもコストを重視することから、ステップＳ３０４においてＤＲ管理プログラム４６０は、安価（低速）なネットワークの帯域を使用してプライマリサイト１００からセカンダリサイト２００にデータを転送することを決定し、当該決定したネットワーク種類を示す情報として、ＶＭ１（アプリ１）に対応するネットワーク４１７に「低速」を登録する。低速なネットワークの具体例としては、インターネットなどが挙げられる。

【0089】

以上、データ転送先及びデータ転送方法を決定するデータ転送先決定処理（図８）、転送データの圧縮方法を決定する転送データ圧縮方法決定処理（図９）、及びデータ転送で使用するネットワーク種類を決定するデータ転送ネットワーク決定処理（図１０）について説明したが、本実施形態に係る情報処理システム１においてこれらの各決定処理は必ずしも全てが実行される必要はなく、選択的に一部の決定処理が実行されるとしてもよいし、複数の決定処理が組み合わせて実行されるとしてもよい。なお、上記の各決定処理のうちで実行されない決定処理が存在する場合でも、当該決定処理の代替手段（ユーザ指示や初期値の設定など）により、ＶＭアプリ管理情報４１０には、ＶＭごとに各データ項目の情報が登録されるとする。

【0090】

（２－４）データ転送処理
図１１は、データ転送処理の処理手順例を示すフローチャートである。データ転送処理は、図９に示した転送データ圧縮方法決定処理で決定された圧縮アルゴリズム（圧縮方法）を用いてデータ転送を行う処理であって、クラウド管理ノード３００のＤＲ管理プログラム４６０及びプライマリサイト１００のコピー機能１２６等によって実行される。

【0091】

図１１によればまず、ＤＲ管理プログラム４６０が、ＤＲ先にデータ転送する際にＶＭアプリ管理情報４１０の圧縮方法４１５に登録された圧縮アルゴリズムでデータを圧縮するよう、プライマリサイト１００に指示する（ステップＳ４０１）。これはクラウド管理ノード３００からストレージ管理装置を介して指示されてもよい。

【0092】

次に、ストレージコントローラ１２０内のコピー機能１２６が、セカンダリサイトへ転送するデータのコピーを作成する（ステップＳ４０２）。

【0093】

次に、ストレージコントローラ１２０内の圧縮機能が、指定された圧縮アルゴリズムを使用して、ステップＳ４０２でコピー機能１２６がコピーしたデータに対して圧縮処理を行う（ステップＳ４０３）。圧縮機能はプロセッサ１１１が所定のプログラムを実行することによって実現される機能であり、図１及び図２には図示していないが、例えばコピー機能１２６がこの機能を行うとしてもよい。

【0094】

次に、ストレージコントローラ１２０内のコピー機能１２６が、ステップＳ４０３の圧縮処理が終わった圧縮データを、セカンダリサイト２００へ転送する（ステップＳ４０４）。データ転送はＶＭアプリ管理情報４１０の登録情報に従って行われる。

【0095】

そして、セカンダリサイト２００において、例えばクラウドサービス管理２３０が、ステップＳ４０４で転送された圧縮データを、セカンダリサイト２００内のＤＲ環境の対応するストレージシステム内に格納し（ステップＳ４０５）、データ転送処理を終了する。ＤＲ環境の対応するストレージシステムは、ＶＭアプリ管理情報４１０の転送先４１４で指定される。また、セカンダリサイト２００では、転送された圧縮データが圧縮されたまま格納され、必要になったときに伸長されることから、クラウドにおけるＤＲコストを削減することができる。

【0096】

なお、ＶＭアプリ管理情報４１０の圧縮方法４１５で指定される圧縮アルゴリズムは、予めストレージコントローラ１２０内のメモリに用意されていてもよいし、指示を受けたときにプライマリサイト１００の外部からダウンロードする等してストレージコントローラ１２０内に格納される等であってもよい。また、圧縮機能は、ストレージコントローラ１２０内に備えられることに限定されず、プライマリサイト１００内の別の構成に備えられていてもよい。また、圧縮機能によって実行される圧縮処理は、データ転送中のバックグラウンドで実行するようにしてもよく、このようにする場合、圧縮処理を実行しながら、圧縮したデータを随時転送できるため、データ転送時間の所要時間を短縮することができる。

【0097】

（２－５）ディザスタリカバリ処理
情報処理システム１では、プライマリサイト１００において障害が検出されると、ディザスタリカバリ（ＤＲ）処理が実行されて、セカンダリサイト２００へのフェイルオーバが行われる。具体的には、ＤＲ管理プログラム４６０が、フェイルオーバを起動し、セカンダリサイト２００側に切り替える処理を指示する。ここで、ＤＲ方法がマルチサイト方式である場合は、セカンダリサイト２００において常にプライマリサイト１００と同じシステムが稼働されている（ＤＲ環境が構築されている）ため、容易に本番環境の切り替えが可能である。一方、ＤＲ方法がパイロットライト方式である場合は、平常時のセカンダリサイト２００では最小限の部分だけがスタンバイしているため、リソースの割り当てをしていないところのリソースの割り当てとＶＭの起動とを行って、ＤＲ環境を構築する。このようなＤＲ環境の構築には、既知のパイロットライト方式のＤＲ環境構築方法を利用でき、図１２に処理手順例を説明する。

【0098】

図１２は、パイロットライト方式におけるディザスタリカバリ処理の処理手順例を示すフローチャートである。図１２には、プライマリサイト１００において障害が検出されたときに情報処理システム１で実行されるディザスタリカバリ（ＤＲ）処理のうち、ＤＲ方法がパイロットライト方式である場合のＤＲ方法について、処理手順例が示されている。なお、本例において、プライマリサイト１００からセカンダリサイト２００への転送データが圧縮データである場合には、圧縮データはオブジェクトストレージである第２のストレージ装置２２２に格納されているとする。

【0099】

図１２によればまず、ＤＲ管理プログラム４６０が、フェイルオーバを起動し、セカンダリサイト２００側に切り替える処理の実行を、セカンダリサイト２００に指示する（ステップＳ５０１）。

【0100】

次に、セカンダリサイト２００側では、クラウドサービス管理２３０が、プライマリサイト１００からセカンダリサイト２００への転送データが圧縮データであるか否かを判定する（ステップＳ５０２）。具体的には、ＶＭアプリ管理情報４１０の圧縮方法４１５を参照することによって、ステップＳ５０２の判定が可能である。転送データが圧縮データである場合は（ステップＳ５０２のＹＥＳ）、ステップＳ５０３に進む。一方、転送データが圧縮データではない場合は（ステップＳ５０２のＮＯ）、ＤＲ処理を終了する。

【0101】

ステップＳ５０３以降の処理を説明する。セカンダリサイト２００側では、ＶＭ１５２のＤＲ方法がパイロットライト方式であることから、ＤＲ先のＶＭ２５２からアクセス可能なデータにするために、データ転送の際に圧縮されたデータを伸長し変換する必要がある。

【0102】

さらに、例えば、重要度の低いアプリ１を実行するＶＭ１が使用するデータは、安価なストレージ（本例では第２のストレージ装置２２２）内に格納するケースが多い。しかし、第２のストレージ装置２２２はオブジェクトストレージのため、ＶＭ２５２が直接データにアクセスして使用することができない。ＶＭ２５２がアクセス可能なストレージデバイスは、第１のストレージ装置２２１のようなブロックストレージやファイルストレージである。このため、オブジェクトストレージである第２のストレージ装置２２２からブロックストレージである第１のストレージ装置２２１にデータを移動して格納する処理が必要となる。

【0103】

そこでまず、クラウドサービス管理２３０は、オブジェクトストレージである第２のストレージ装置２２２に格納された圧縮データの伸長処理を指示し、第２のストレージ装置２２２は伸長処理を行い（ステップＳ５０３）、次に、ブロックストレージである第１のストレージ装置２２１に、ＶＭ１に提供するボリュームを生成し、ステップＳ５０３で伸長した後のデータをそのボリュームに格納する（ステップＳ５０４）。

【0104】

そして、クラウドサービス管理２３０は、ステップＳ５０４で伸長後のデータを格納したボリュームをＶＭ１にアタッチし（ステップＳ５０５）、ＤＲ処理を終了する。ステップＳ５０５の処理によって、ＶＭ１（ＶＭ２５２）はブロックストレージ内のボリュームのデータにアクセスできるようになる。

【0105】

なお、ステップＳ５０３～Ｓ５０５の処理は、パイロット方式におけるＤＲ処理に限定されるものではなく、データ転送によってプライマリサイト１００のバックアップ用データ（ＶＭ１５２が使用するデータを複製して圧縮したデータ）を格納するセカンダリサイト２００のストレージシステム２２０がオブジェクトストレージであった場合に広く適用することができる。

【0106】

また、上記はフェイルオーバ時の処理手順の一例であり、他にも例えば、ステップＳ５０３では第２のストレージ装置２２２内に格納された圧縮データを伸長処理するとしたところを、第１のストレージ装置２２１内のストレージコントローラ部もしくは回路等のハードウェア、またはセカンダリサイト２００内のクラウドにある他のノードやアプライアンスによって圧縮データの伸長処理が行われるとしてもよい。すなわち、圧縮データの伸長処理を行う箇所は、第２のストレージ装置２２２内に限定されるものではなく、第１のストレージ装置２２１内であってもよいし、これら以外の場所であってもよい。

【0107】

以上に説明したように、本実施形態に係る情報処理システム１によれば、アプリ１５３を利用する顧客が要望するサービスに適合するＤＲ方法（パイロットライト方式やマルチサイト方式）で、アプリ１５３の重要度に基づいて、ＤＲ先へのデータ転送に関する各種設定をＶＭ１５２ごとに決定することにより、顧客が利用するサービス（アプリケーション）に適合するディザスタリカバリ構成を提供することができる。さらに情報処理システム１は、ＤＲ先へのデータ転送を、アプリ１５３の重要度に基づいて決定された圧縮方法（圧縮アルゴリズム）による圧縮データで実行し、ＤＲ先で必要となるときまで圧縮データのままＤＲ先に格納することで、クラウド環境であるＤＲ先（セカンダリサイト２００）におけるコスト増加を抑制できるため、ディザスタリカバリシステム全体のコストを削減することができる。

【0108】

（３）他の実施形態
本発明は、上述した実施形態に限定されるものではなく、様々な変形例が含まれる。そこで以下では、本発明の他のいくつかの実施形態（変形例）について説明する。なお、以下に説明する変形例において説明しない情報処理システム１の構成や処理は、上述した実施形態と同様であると考えてよい。

【0109】

（３－１）第１の変形例
情報処理システム１は、図９に示した転送データ圧縮方法決定処理とは別の処理手順により、フェイルオーバを開始してからＤＲ環境を構築してＤＲ先のＶＭ２５２が起動できるようになるまでに要する時間（ＤＲ環境構築時間）の見積もりに基づいて、転送データの圧縮方法（圧縮アルゴリズム）を決定するようにしてもよい。

【0110】

図１３は、転送データ圧縮方法決定処理の別の処理手順例を示すフローチャートである。図１３に示す転送データ圧縮方法決定処理は、図９に示した転送データ圧縮方法決定処理と同様に、クラウド管理ノード３００のＤＲ管理プログラム４６０によってＶＭ１５２ごとに実行される。

【0111】

図１３によればまず、ＤＲ管理プログラム４６０は、圧縮データの単位データサイズあたりの伸長処理時間を見積もる（ステップＳ６０１）。さらに、ＤＲ管理プログラム４６０は、インスタンスを生成するために要する単位リソースあたりのインスタンス生成時間を見積もる（ステップＳ６０２）。インスタンス生成時間には、リソースの確保及びＶＭ２５２の起動に要する時間が含まれる。

【0112】

次に、ＤＲ管理プログラム４６０は、ＤＲ環境構築のために確保する必要があるリソース数と、ステップＳ６０２で見積もったインスタンス生成時間とに基づいて、フェイルオーバを開始してからＤＲ環境を構築してＤＲ先のＶＭ２５２が起動できるようになるまでに要するＤＲ環境構築時間を見積もる（ステップＳ６０３）。

【0113】

ステップＳ６０１～Ｓ６０３の見積もりを行った後、ＤＲ管理プログラム４６０は、予め用意された複数種類の圧縮アルゴリズムのうちから、ステップＳ６０３で見積もったＤＲ環境構築時間内に「圧縮データの伸長処理時間」が収まる程度のデータ量に圧縮可能な圧縮アルゴリズムを選択し、この圧縮アルゴリズムを処理対象のＶＭ１５２のデータの圧縮方法として、ＶＭアプリ管理情報４１０の当該ＶＭに対応する圧縮方法４１５に登録する（ステップＳ６０４）。なお、「圧縮データの伸長処理時間」は、圧縮アルゴリズムによるデータの圧縮率、ステップＳ６０１で見積もった単位データサイズあたりの伸長処理時間、及びステップＳ６０３で用いたＤＲ環境構築のために確保する必要があるリソース数、に基づいて算出できる。

【0114】

以上のように決定された圧縮方法によって転送データが圧縮されることにより、情報処理システム１では、ＤＲ環境の構築に伴う処理のバックグラウンドで圧縮データの伸長を行うと、ＤＲ環境構築が完了するまでに圧縮データの伸長処理を終了できると予測されることから、起動後のＶＭ２５２が遅延なくデータにアクセスできるようになり、フェイルオーバに要する時間を短縮する効果に期待できる。

【0115】

なお、転送データ圧縮方法決定処理のさらなる変形例として、これまではＶＭ単位で圧縮アルゴリズムを決定していたが、１ボリュームごと、もしくは１ボリューム内のデータ領域ごとに、圧縮アルゴリズムを決定するようにしてもよい。これは、フェイルオーバ時に、パイロットライト方式によるＤＲ環境構築のためのリソース確保及びＶＭ起動時間内にオブジェクトストレージ（第２のストレージ装置２２２）に格納された圧縮データの伸長処理が終わるようにするためである。このように対象を細分化して圧縮アルゴリズムを決定することにより、ＤＲ環境構築が完了する際に、データの伸長処理も隔日に完了させることができ、業務復旧時間の遅延を防止する効果が得られる。

【0116】

（３－２）第２の変形例
情報処理システム１は、転送データの格納先のストレージを選択するバリエーションとして、図８に示したデータ転送先決定処理の処理手順に代えて、フェイルオーバ時のＶＭ２５２の起動時間に基づいて、転送データの格納先のストレージをオブジェクトストレージまたはブロックストレージ（ファイルストレージ等でもよい）から選択するようにしてもよい。

【0117】

前述したようにオブジェクトストレージ（第２のストレージ装置２２２）に格納された圧縮データは、伸長後もそのままではＶＭ２５２からはアクセスできないため、ブロックストレージ等（第１のストレージ装置２２１）に移す必要があり、圧縮された転送データがブロックストレージ等に格納される場合に比べて、一連の処理の所要時間が長くなる。このため、ＶＭ２５２の起動時間が長い場合は問題にはならないが、起動時間が短い場合には、フェイルオーバ時に、ＶＭ２５２が起動した後にデータにアクセスできるまでに遅延が発生する可能性がある。

【0118】

本変形例は、このような点を考慮したものであり、フェイルオーバ時に起動終了するとすぐに（あるいは起動終了後の短い待機時間の後に）ＶＭ２５２が伸長後のデータにアクセスできるよう、フェイルオーバ時のＶＭ２５２の起動時間に基づいて、転送データの格納先のストレージを決定するものである。

【0119】

また、情報処理システム１が提供するストレージサービスを利用する顧客においては、業務の運用形態の変更等により、利用するアプリ１５３の重要度が変わることがある。このようにアプリの重要度に変更が発生した場合、情報処理システム１は、図８～図１０等に示した各種処理を実行し直すことにより、アプリの重要度に基づいて決定される各種の対応情報（具体的には、ＶＭアプリ管理情報４１０の転送先４１４、圧縮方法４１５、転送方法４１６、ネットワーク４１７等）を更新するようにしてよい。

【0120】

（３－３）第３の変形例
また、これまでの実施形態では、アプリの重要度がユーザ（顧客）の指示またはクラウド管理ノード３００による分析等によって予め決定されるとしたが、ＶＭごとに異なるレベルのＤＲ方法をユーザが設定したＤＲ環境では、ＤＲ管理プログラム４６０が、ＤＲ方法からＶＭ上で実行するアプリの重要度を決定するようにしてもよい。ＤＲ方法に基づいてアプリの重要度を決定するためには、例えば、パイロットライト方式の場合はアプリの重要度が「低い」とし、マルチサイト方式の場合はアプリの重要度が「高い」とする等、ＤＲ方法ごとに対応するアプリの重要度を定めておけばよい。その後、情報処理システム１（ＤＲ管理プログラム４６０）は、決定したアプリの重要度を利用して、前述した実施形態と同様に、プライマリサイト１００とセカンダリサイト２００との間のデータ転送先のストレージクラスやデータ格納時の圧縮方法を決定することができる。

【0121】

以上のように、情報処理システム１は、前述した実施形態や第１及び第２の変形例のように予め設定されるアプリの重要度に基づいてＤＲ方法を決定するか、第３の変形例のように予め設定されるＤＲ方法に基づいてアプリの重要度を決定し、これらの決定事項に基づいてＤＲ先へのデータ転送の各種設定（転送先ストレージ、圧縮方法、データ転送方法、データ転送時に使用するネットワーク種類）を決定することにより、ユーザ（顧客）が利用するサービスに適合するＤＲ構成を提供しつつ、ＤＲ構成の構築に伴う全体的なコストを低減することができる。

【符号の説明】

【0122】

１ 情報処理システム
１０ ネットワーク
１００ プライマリサイト
１１０，２１０ サーバシステム
１１１，１２１，２１１，３０１ プロセッサ
１１２，１２２，２１２，３０２ メモリ
１１３，１２４，３０３ ネットワークインターフェース（Ｉ／Ｆ）
１２０ ストレージコントローラ
１２３ ストレージインターフェース（Ｉ／Ｆ）
１２５ ストレージ制御プログラム
１２６ コピー機能
１３０ オンプレミスストレージ
１４０ プール
１５１，２５１ サーバ（サーバ群）
１５２，２５２ ＶＭ
１５３，２５３ アプリ
２００ セカンダリサイト
２２０ ストレージシステム
２２１ 第１のストレージ装置
２２２ 第２のストレージ装置
２３０ クラウドサービス管理
３００ クラウド管理ノード
４１０ ＶＭアプリ管理情報
４２０ アプリ重要度管理情報
４３０ 重要度ＤＲ管理情報
４４０ ＤＲ管理情報
４６０ ＤＲ管理プログラム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】