(57)【要約】【課題】メインストレージとリモートストレージの構成が異なる場合に、リモートストレージ側の性能低下を抑制するディザスタリカバリシステムを提供する。【解決手段】マスタストレージは、マスタボリュームをなす各ブロックにおけるアクセスを監視することで、マスタボリュームの各ブロックにおける負荷に関する情報を含む性能情報を生成し、生成された性能情報を中間ストレージの性能情報格納領域に格納する、アクセス監視部を備える。リモートストレージは、中間ストレージに格納された性能情報を取得し、取得した性能情報を分析する、アクセス分析部を備える。アクセス分析部は、性能情報の分析結果に基づいて、マスタボリュームから取得されたデータの自装置における格納先を変更する。【選択図】図１
2018169772.tif 000002
【特許請求の範囲】
【請求項１】
マスタストレージと、
前記マスタストレージとは異なるサイトに設置されたリモートストレージと、
前記マスタストレージ及びリモートストレージに接続された中間ストレージと、
を含み、
前記マスタストレージは、
マスタボリュームをなす各ブロックにおけるアクセスを監視することで、前記マスタボリュームの各ブロックにおける負荷に関する情報を含む性能情報を生成し、前記生成された性能情報を前記中間ストレージの性能情報格納領域に格納する、アクセス監視部を備え、
前記リモートストレージは、
前記中間ストレージに格納された性能情報を取得し、前記取得した性能情報を分析する、アクセス分析部を備え、
前記アクセス分析部は、
前記性能情報の分析結果に基づいて、前記マスタボリュームから取得されたデータの自装置における格納先を変更する、
ディザスタリカバリシステム。
【請求項２】
前記アクセス分析部は、
前記性能情報の分析結果に基づき、前記マスタボリュームをなすブロックのうち、ブロックに対する負荷が所定の値よりも高いブロックから得られるデータの格納先を入れ替える、請求項１のディザスタリカバリシステム。
【請求項３】
前記マスタストレージは、
前記マスタボリュームのデータが更新されたことに応じて、前記更新されたデータとデータの更新順序を示す更新順序情報を含むジャーナルデータを生成し、前記生成されたジャーナルデータを前記中間ストレージに転送すると共に、前記生成されたジャーナルデータを前記中間ストレージのジャーナル管理領域に格納する、ジャーナル転送部をさらに備える、請求項２のディザスタリカバリシステム。
【請求項４】
前記アクセス分析部は、
前記性能情報の分析結果に基づき、前記中間ストレージのジャーナル管理領域に格納されたジャーナルデータを、前記中間ストレージのリモートデータ退避領域に退避するか否かを決定する、請求項３のディザスタリカバリシステム。
【請求項５】
前記アクセス分析部は、
前記マスタボリュームをなすブロックのうち、ブロックに対する更新が所定の値よりも多いブロックに対応するジャーナルデータを、前記リモートデータ退避領域に退避するジャーナルデータと決定する、請求項４のディザスタリカバリシステム。
【請求項６】
前記リモートストレージは、
前記アクセス分析部が、前記ジャーナルデータを前記リモートデータ退避領域に退避しないと決定したジャーナルデータを取得する、ジャーナル取得部をさらに備える、請求項４又は５のディザスタリカバリシステム。
【請求項７】
前記リモートストレージは、
前記アクセス分析部が、前記ジャーナルデータを前記リモートデータ退避領域に退避すると決定したジャーナルデータを、前記中間ストレージの前記ジャーナル管理領域から前記リモートデータ退避領域に移動する、リモートデータ管理部をさらに備える、請求項５又は６のディザスタリカバリシステム。
【請求項８】
前記リモートデータ管理部は、
前記リモートデータ退避領域からジャーナルデータを取得する、請求項７のディザスタリカバリシステム。
【請求項９】
マスタストレージと、
前記マスタストレージとは異なるサイトに設置されたリモートストレージと、
前記マスタストレージ及びリモートストレージに接続された中間ストレージと、
を含むディザスタリカバリシステムにおいて、
マスタボリュームをなす各ブロックにおけるアクセスを監視することで、前記マスタボリュームの各ブロックにおける負荷に関する情報を含む性能情報を生成し、前記生成された性能情報を前記中間ストレージの性能情報格納領域に格納するステップと、
前記中間ストレージに格納された性能情報を取得し、前記取得した性能情報を分析するステップと、
前記性能情報の分析結果に基づいて、前記マスタボリュームから取得されたデータの自装置における格納先を変更するステップと、
を含む、ディザスタリカバリ方法。
【請求項１０】
マスタボリュームをなす各ブロックにおけるアクセスを監視することで、前記マスタボリュームの各ブロックにおける負荷に関する情報を含む性能情報を生成し、前記生成された性能情報を、中間ストレージの性能情報格納領域に格納するマスタストレージから、前記中間ストレージを介してデータを取得する、リモートストレージに搭載されたコンピュータに、
前記中間ストレージに格納された性能情報を取得し、前記取得した性能情報を分析する処理と、
前記性能情報の分析結果に基づいて、前記マスタボリュームから取得されたデータの自装置における格納先を変更する処理と、
を実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ディザスタリカバリシステム、ディザスタリカバリ方法及びプログラムに関する。
【背景技術】
【０００２】
ホスト計算機とストレージ装置を含んで構成される業務システムにおいて、ディザスタリカバリシステムが構築されることがある（特許文献１、２参照）。ディザスタリカバリシステムでは、メインサイトと同様な構成をリモートサイトに設置し、メインサイトとリモートサイトをネットワークで接続する。その上で、メインサイトのストレージ装置にて更新されたデータをネットワーク経由でリモートサイトに随時バックアップ（あるいは、ミラーリング）する。
【０００３】
ディザスタリカバリシステムでは、メインサイトが被災した際にリモートサイトにて業務を継続する。このようなディザスタリカバリシステムでは、メインサイト被災時のデータロストを最小限に抑える必要がある。つまり、マスタ（メインサイトのストレージ装置）の更新になるべく同期し、直近で更新されたデータをリモートサイトにバックアップして保持する必要がある。
【０００４】
通常、ディザスタリカバリシステムにおいてリモートサイトはメインサイトと同じ構成を採用することが多い。しかしながら、コスト削減のため、リモートサイトとメインサイトの一部構成を非同一とし、リモートサイトを小規模な構成とすることもある。また、近年、クラウドストレージに代表されるようにローカルサイトとネットワークで接続された外部ストレージに対しネットワーク経由でデータの保管／参照を可能とするサービスが登場している。
【０００５】
特許文献１には、メインサイトとリモートサイトの間のジャーナルサイトにジャーナルストレージを設置し、マスタに対する更新データをジャーナルストレージに同期コピーして記録し、さらにジャーナルストレージから更新データをリモートサイトに転送する技術が開示されている。また、特許文献３及び４には、記憶装置のバックアップに関する技術が開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１０−１８２１５４号公報
【特許文献２】特開２００６−３３８０６４号公報
【特許文献３】特開２０１４−０９９０５４号公報
【特許文献４】国際公開第２０１５／０９７７３７号
【発明の概要】
【発明が解決しようとする課題】
【０００７】
なお、上記先行技術文献の各開示を、本書に引用をもって繰り込むものとする。以下の分析は、本発明者らによってなされたものである。
【０００８】
上述のように、メインサイトとリモートサイトにより構成されるディザスタリカバリシステムでは、マスタストレージにて更新されたデータをリモートストレージに複製することで、メインサイトが被災した際にリモートサイトでの業務継続を可能とする。
【０００９】
ここで、特許文献１に開示されたように、ジャーナル方式のディザスタリカバリシステムが存在する。ジャーナル方式のディザスタリカバリシステムでは、マスタストレージに、マスタボリュームに対する更新順序通りに更新データを記録するジャーナル領域を設ける。マスタストレージでは、バックグラウンドにてデータをリモートストレージへ複製する。リモートサイト（リモート側）では、更新順序通りに元のデータを復元する。
【００１０】
このような対応により、ジャーナル方式のディザスタリカバリシステムでは、ネットワーク遅延の影響を受けずに、ホストの応答性能低下を抑え、且つ、一貫性を保持している。しかし、このようなジャーナル方式では、リモートサイトへの未転送の更新データが大量に存在する場合、メインサイトが被災した時にジャーナルデータの損失によるデータロストが大きくなる。そこで、メインサイトとリモートサイトの間に中間サイトを設けて、中間サイトに更新データを格納し、メインサイトが被災した際のデータロストを防止することが行われる。
【００１１】
リモートサイト側のリモートストレージは、通常、メインサイト側のストレージ（マスタストレージ）と同一性能、同一構成とするが、コスト削減のため、マスタストレージよりも小規模なストレージで構成する場合がある。このような場合、各ボリュームの領域のアクセス頻度に偏りが生じる事があり、アクセスの競合が発生してアクセス性能が低下し、リモートサイトの運用開始後に構成変更やデータの再配置等の作業が発生する可能性がある。
【００１２】
この点、特許文献１に開示された技術でも同様であり、特許文献１では、メインサイトとリモートサイトの回線障害時にはジャーナルストレージに直近の更新データを保持しているため、メインサイトが被災した際のデータロストを防止している。しかし、特許文献１において、リモートサイトの構成が異なる場合（特に、リモートサイトの構成がメインサイトの構成よりも劣る場合）のアクセス性能の劣化に関しては考慮されていない。
【００１３】
本発明は、メインストレージとリモートストレージの構成が異なる場合に、リモートストレージ側の性能低下を抑制する、ディザスタリカバリシステム、ディザスタリカバリ方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１４】
本発明の第１の視点によれば、マスタストレージと、前記マスタストレージとは異なるサイトに設置されたリモートストレージと、前記マスタストレージ及びリモートストレージに接続された中間ストレージと、を含み、前記マスタストレージは、マスタボリュームをなす各ブロックにおけるアクセスを監視することで、前記マスタボリュームの各ブロックにおける負荷に関する情報を含む性能情報を生成し、前記生成された性能情報を前記中間ストレージの性能情報格納領域に格納する、アクセス監視部を備え、前記リモートストレージは、前記中間ストレージに格納された性能情報を取得し、前記取得した性能情報を分析する、アクセス分析部を備え、前記アクセス分析部は、前記性能情報の分析結果に基づいて、前記マスタボリュームから取得されたデータの自装置における格納先を変更する、ディザスタリカバリシステムが提供される。
【００１５】
本発明の第２の視点によれば、マスタストレージと、前記マスタストレージとは異なるサイトに設置されたリモートストレージと、前記マスタストレージ及びリモートストレージに接続された中間ストレージと、を含むディザスタリカバリシステムにおいて、マスタボリュームをなす各ブロックにおけるアクセスを監視することで、前記マスタボリュームの各ブロックにおける負荷に関する情報を含む性能情報を生成し、前記生成された性能情報を前記中間ストレージの性能情報格納領域に格納するステップと、前記中間ストレージに格納された性能情報を取得し、前記取得した性能情報を分析するステップと、前記性能情報の分析結果に基づいて、前記マスタボリュームから取得されたデータの自装置における格納先を変更するステップと、を含む、ディザスタリカバリ方法が提供される。
【００１６】
本発明の第３の視点によれば、マスタボリュームをなす各ブロックにおけるアクセスを監視することで、前記マスタボリュームの各ブロックにおける負荷に関する情報を含む性能情報を生成し、前記生成された性能情報を、中間ストレージの性能情報格納領域に格納するマスタストレージから、前記中間ストレージを介してデータを取得する、リモートストレージに搭載されたコンピュータに、前記中間ストレージに格納された性能情報を取得し、前記取得した性能情報を分析する処理と、前記性能情報の分析結果に基づいて、前記マスタボリュームから取得されたデータの自装置における格納先を変更する処理と、を実行させるプログラムが提供される。
なお、このプログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。記憶媒体は、半導体メモリ、ハードディスク、磁気記録媒体、光記録媒体等の非トランジェント（non-transient）なものとすることができる。本発明は、コンピュータプログラム製品として具現することも可能である。
【発明の効果】
【００１７】
本発明の各視点によれば、メインストレージとリモートストレージの構成が異なる場合に、リモートストレージ側の性能低下を抑制することに寄与する、ディザスタリカバリシステム、ディザスタリカバリ方法及びプログラムが、提供される。
【図面の簡単な説明】
【００１８】
【図１】一実施形態の概要を説明するための図である。
【図２】第１の実施形態に係るディザスタリカバリシステムの概略構成の一例を示す図である。
【図３】第１の実施形態に係るディザスタリカバリシステムの動作の一例を示す図である。
【図４】ジャーナル管理領域の一例を示す図である。
【図５】リモートデータ退避領域の一例を示す図である。
【図６】性能情報格納領域の一例を示す図である。
【図７】ブロック割り当てテーブルの一例を示す図である。
【図８】性能情報テーブルの一例を示す図である。
【図９】マスタストレージのジャーナル転送部の動作の一例を示すフローチャートである。
【図１０】マスタストレージのアクセス監視部の動作の一例を示すフローチャートである。
【図１１】リモートストレージのジャーナル取得部の動作の一例を示すフローチャートである。
【図１２】リモートストレージのリモートデータ管理部の動作の一例を示すフローチャートである。
【図１３】リモートストレージのアクセス分析部の動作の一例を示すフローチャートである。
【発明を実施するための形態】
【００１９】
初めに、一実施形態の概要について説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、この概要の記載はなんらの限定を意図するものではない。また、各図におけるブロック間の接続線は、双方向及び単方向の双方を含む。一方向矢印については、主たる信号（データ）の流れを模式的に示すものであり、双方向性を排除するものではない。
【００２０】
一実施形態に係るディザスタリカバリシステムは、マスタストレージ１０１と、マスタストレージ１０１とは異なるサイトに設置されたリモートストレージ１０２と、マスタストレージ１０１及びリモートストレージ１０２に接続された中間ストレージ１０３と、を含む（図１参照）。マスタストレージ１０１は、マスタボリュームをなす各ブロックにおけるアクセスを監視することで、マスタボリュームの各ブロックにおける負荷に関する情報を含む性能情報を生成し、生成された性能情報を中間ストレージ１０３の性能情報格納領域に格納する、アクセス監視部１１１を備える。リモートストレージ１０２は、中間ストレージ１０３に格納された性能情報を取得し、取得した性能情報を分析する、アクセス分析部１２１を備える。アクセス分析部１２１は、性能情報の分析結果に基づいて、マスタボリュームから取得されたデータの自装置にける格納先を変更する。
【００２１】
上記一実施形態に係るディザスタリカバリシステムにおいて、リモートストレージ１０２は、マスタストレージ１０１から取得した性能情報に従って、被災後に運用を行った場合に、バックアップボリュームのアクセスの負荷が分散されるようにデータの格納領域の割り当てを変更する。その結果、リモートストレージ１０２の側ではアクセス負荷が分散されるように格納領域を配置しているため、被災後に構成変更やデータの再配置やデータの転送を行うことなくリモートサイトでの業務を継続できる。つまり、メインストレージとリモートストレージの構成が異なる場合であっても、リモートストレージ１０２の側の性能低下を抑制することができる。
【００２２】
以下に具体的な実施の形態について、図面を参照してさらに詳しく説明する。なお、各実施形態において同一構成要素には同一の符号を付し、その説明を省略する。
【００２３】
［第１の実施形態］
第１の実施形態について、図面を用いてより詳細に説明する。
【００２４】
図２は、第１の実施形態に係るディザスタリカバリシステムの概略構成の一例を示す図である。図２を参照すると、ディザスタリカバリシステムは、メインサイトと、リモートサイトと、外部サイトと、から構成される。
【００２５】
図２に示すディザスタリカバリシステムでは、メインサイトにマスタストレージ１１が配置され、遠隔地のリモートサイトにリモートストレージ２１が配置される。
【００２６】
ディザスタリカバリシステムでは、マスタストレージ１１上のマスタボリュームに記憶されたデータをリモートストレージ２１のバックアップボリュームに複製（コピー）することで、被災時のデータロストを防止する。
【００２７】
また、ディザスタリカバリシステムでは、メインサイト及びリモートサイトから公衆回線等のネットワークによりアクセス可能なクラウドストレージを経由して、メインサイトからリモートサイトにデータが転送（複製）される。
【００２８】
メインサイトには、ホスト計算機１０と、ホスト計算機１０とネットワークにより接続されたマスタストレージ１１と、が含まれる。
【００２９】
マスタストレージ１１には、マスタボリューム１２と、ジャーナルボリューム１３と、コントローラ１４と、が含まれる。
【００３０】
マスタボリューム１２は、ホスト計算機１０からアクセス可能（読み書き可能）である。マスタボリューム１２は、ＨＤＤ（Hard Disk Drive）等の記憶媒体の集合から構成される。図２では、マスタボリューム１２を構成する各記憶媒体をＭＶＯＬと表記し、各記憶媒体の識別情報を記号＃と数字の組み合わせにて表記している。
【００３１】
ジャーナルボリューム１３は、マスタボリューム１２にて更新されたデータ（更新データを含むブロック）に対して更新順序情報を付加してパッケージ化したジャーナルデータを記録するボリュームである。
【００３２】
コントローラ１４は、マスタストレージ１１の全体を制御するモジュール（手段）である。コントローラ１４は、マスタボリューム１２及びジャーナルボリューム１３に対するアクセス制御を行う。また、コントローラ１４は、マスタストレージ１１に内蔵された通信インターフェイスであるＮＩＣ（Network Interface Card）を制御し、外部装置との間の相互通信を実現する。
【００３３】
コントローラ１４には、ジャーナル転送部２０１とアクセス監視部２０２の２つの処理モジュールが含まれる。
【００３４】
マスタストレージ１１のジャーナル転送部２０１は、マスタボリューム１２のデータが更新されたことに応じて、更新されたデータとデータの更新順序を示す更新順序情報を含むジャーナルデータを生成する。また、ジャーナル転送部２０１は、生成されたジャーナルデータをクラウドストレージ３１（中間ストレージ）に転送すると共に、生成されたジャーナルデータをクラウドストレージ３１の所定領域に格納する。より具体的には、ジャーナル転送部２０１は、更新データ（更新ブロック）に更新順序情報を付加してパッケージ化したジャーナルデータを生成し、ジャーナルボリューム１３に格納する。なお、ジャーナル転送部２０１は、マスタボリューム１２の各ブロックにおいて所定のサイズのデータが更新された場合や一定時間に亘り更新がないブロック等をジャーナルデータ生成の対象とする。つまり、ジャーナル転送部２０１は、所定の条件に合致するブロックからジャーナルデータを生成する。
【００３５】
また、ジャーナル転送部２０１は、ジャーナルボリューム１３に格納したジャーナルデータをクラウドストレージ３１のジャーナル管理領域３２に向けて送信する。つまり、ジャーナル転送部２０１は、ジャーナルボリューム１３からジャーナルデータを読み出し、クラウドストレージ３１（外部サイトに構築されたストレージ）のジャーナル管理領域３２にジャーナルデータを登録する。クラウドストレージ３１及びその内部領域の詳細は後述する。
【００３６】
アクセス監視部２０２は、マスタボリューム１２をなす各ブロックにおけるアクセスを監視することで、マスタボリューム１２の各ブロックにおける負荷に関する情報を含む性能情報を生成する。アクセス監視部２０２は、生成された性能情報をクラウドストレージ３１の所定領域に格納する。つまり、アクセス監視部２０２は、マスタボリューム１２の負荷を監視する。アクセス監視部２０２は、マスタボリューム１２における所定サイズのブロックごとの負荷や更新頻度を監視し、これらの情報を性能情報としてクラウドストレージ３１の性能情報格納領域３４に登録する。
【００３７】
なお、アクセス監視部２０２が負荷を監視するマスタボリューム１２のブロックのサイズとジャーナル転送部２０１が生成するジャーナルデータのサイズは一致する。つまり、マスタボリューム１２の各ブロックが所定の条件（例えば、所定サイズのデータ更新、所定の時間更新がない）に合致すると、ジャーナルデータが生成される。
【００３８】
外部サイトには、メインサイト及びリモートサイトのそれぞれからアクセス可能なクラウドストレージが１以上含まれる。外部サイトに設置されるストレージが上述の中間ストレージである。第１の実施形態では、２つのクラウドストレージ３１−１、３１−２を含む構成を説明する。なお、本願開示では、２つのクラウドストレージ３１−１、３１−２を区別する特段の理由が無い場合には、単に「クラウドストレージ３１」と表記する。また、他の構成についても同様に、ハイフン（−）の前の数字にて当該構成を代表するものとする。
【００３９】
クラウドストレージ３１は、メインサイト及びリモートサイトの双方からアクセス可能に構成されている。つまり、クラウドストレージ３１は、メインサイト及びリモートサイトとの間で予め定めたインターフェイスによりデータの登録、取得、削除が可能に構成されている。
【００４０】
また、クラウドストレージ３１には種々のデータ格納領域が定義される。具体的には、ジャーナル管理領域３２、リモートデータ退避領域３３、性能情報格納領域３４が少なくとも定義される。
【００４１】
なお、クラウドストレージ３１には、データを格納する記憶媒体や、当該記憶媒体に対する制御手段（コントローラ）が含まれるが、図２ではこれらの図示を省略している。
【００４２】
リモートサイトは、メインサイトが保持するデータのバックアップデータを作成、管理するサイトである。リモートサイトには、ホスト計算機２０と、ホスト計算機２０とネットワークにより接続されたリモートストレージ２１と、が含まれる。
【００４３】
リモートストレージ２１は、バックアップボリューム２２と、コントローラ２３と、各種テーブル情報が構築される記憶媒体（図２ではテーブル情報を図示している）と、が含まれる。
【００４４】
バックアップボリューム２２は、ホスト計算機２０からアクセス可能（読み書き可能）であり、マスタボリューム１２のバックアップデータを記憶する。バックアップボリューム２２は、マスタボリューム１２と同様に、複数の記憶媒体を含んで構成される。図２では、バックアップボリューム２２を構成する記憶媒体をＢＶＯＬと表記し、各記憶媒体の識別情報を記号＃と数字の組み合わせにて表記している。
【００４５】
コントローラ２３は、リモートストレージ２１の全体を制御するモジュール（手段）である。コントローラ２３は、バックアップボリューム２２に対するアクセス制御を行う。また、コントローラ２３は、リモートストレージ２１に内蔵された通信インターフェイスであるＮＩＣ（Network Interface Card）を制御し、外部装置との間の相互通信を実現する。
【００４６】
コントローラ２３には、ジャーナル取得部３０１と、リモートデータ管理部３０２と、アクセス分析部３０３の３つの処理モジュールが含まれる。
【００４７】
ジャーナル取得部３０１は、クラウドストレージ３１に登録されたジャーナルデータを取得する手段である。より具体的には、ジャーナル取得部３０１は、定期的にクラウドストレージ３１にアクセスして、ジャーナルデータがジャーナル管理領域３２に登録されているか否かを確認する。
【００４８】
自装置に未転送（未取得）のジャーナルデータが登録されている場合、ジャーナル取得部３０１は、当該未転送のジャーナルデータの取得がリモートデータ管理部３０２により必要と判断された場合に、当該ジャーナルデータを取得する。つまり、ジャーナル取得部３０１は、リモートデータ退避領域３３に退避しないと決定されたジャーナルデータだけを取得する。ジャーナル取得部３０１は、当該取得したジャーナルデータを展開し、バックアップボリューム２２にデータを反映する。ジャーナル取得部３０１は、クラウドストレージ３１から取得したデータを削除する。
【００４９】
リモートデータ管理部３０２は、クラウドストレージ３１におけるジャーナル管理領域３２のジャーナルデータを、必要に応じてリモートデータ退避領域３３に転送（複製）する手段である。つまり、リモートデータ管理部３０２は、リモートデータ退避領域３３に退避すると決定されたジャーナルデータを、ジャーナル管理領域３２からリモートデータ退避領域３３に移動する。
【００５０】
より具体的には、リモートデータ管理部３０２は、後述するブロック割り当てテーブル３１１を参照し、クラウドストレージ３１に登録されているジャーナルデータの退避が必要と判断した場合、クラウドストレージ３１のジャーナル管理領域３２に存在するジャーナルデータをリモートデータ退避領域３３に複製する。
【００５１】
また、リモートデータ管理部３０２は、メインサイトの被災時等、リモートデータ退避領域３３に登録されているジャーナルデータの取得が必要と判断した場合は、リモートデータ退避領域３３からジャーナルデータを取得する。その場合には、リモートデータ管理部３０２は、取得したジャーナルデータを展開し、バックアップボリューム２２に当該データを反映する。その後、リモートデータ管理部３０２は、クラウドストレージ３１のリモートデータ退避領域３３から取得したジャーナルデータを削除する。
【００５２】
アクセス分析部３０３は、クラウドストレージ３１に格納された性能情報を取得し、取得した性能情報を分析する手段である。また、アクセス分析部３０３は、分析結果に応じてブロック割り当てテーブル３１１を更新することで、バックアップデータの格納場所を変更する。つまり、アクセス分析部３０３は、性能情報の分析結果に基づいて、マスタボリューム１２から取得されたバックアップデータの自装置にける格納先（バックアップボリュームをなく記憶媒体）を変更する。
【００５３】
より具体的には、アクセス分析部３０３は、定期的にクラウドストレージ３１の性能情報格納領域３４にアクセスし、性能情報が存在するか否かを確認する。アクセス分析部３０３は、性能情報が登録されていた場合は当該性能情報を取得し、取得した性能情報により後述する性能情報テーブル３１２を更新する。性能情報テーブル３１２には、マスタボリュームのブロックを単位として負荷情報と更新頻度が記憶されており、アクセス分析部３０３は、当該記録された負荷情報と更新頻度に基づき、ブロックの割り当て変更が必要か否かを判断する。具体的には、アクセス分析部３０３は、性能情報の分析結果に基づき、マスタボリューム１２をなすブロックのうち、ブロックに対する負荷が所定の値よりも高いブロックから得られるバックアップデータの格納先を入れ替える。
【００５４】
なお、ブロックの割り当て変更とは、バックアップボリューム２２をなす複数の記憶媒体間において、データの格納先を移動する処理である。例えば、記憶媒体ＢＶＯＬ＃００に格納されたバックアップデータを記憶媒体ＢＶＯＬ＃０１に移動する処理が、ブロックの割り当て変更である。アクセス分析部３０３は、ブロックの割り当て変更が必要と判断した場合には、上記割り当て変更処理を実行すると共に、ブロック割り当てテーブル３１１の該当領域を更新する。
【００５５】
また、アクセス分析部３０３は、クラウドストレージ３１のジャーナル管理領域３２に登録されたジャーナルデータの退避に関する判定も行う。具体的には、アクセス分析部３０３は、性能情報の分析結果に基づき、ジャーナル管理領域３２に格納されたジャーナルデータを、リモートデータ退避領域３３に退避するか否かを決定する。アクセス分析部３０３は、性能情報テーブル３１２に格納された性能情報に基づいてクラウドストレージ３１のジャーナルデータを直ちに取得する必要がないと判断した場合、当該判断結果をブロック割り当てテーブル３１１に反映する。具体的には、アクセス分析部３０３は、マスタボリューム１２をなすブロックのうち、ブロックに対する更新が所定の値よりも多い（更新頻度が所定の値よりも多い）ブロックに対応するジャーナルデータを、リモートデータ退避領域３３に退避すると判断する。
【００５６】
次に、上記説明したジャーナルデータの移動を、図３を用いて説明する。
【００５７】
図３を参照すると、ジャーナルボリューム１３にジャーナルデータＤ１〜Ｄ６が順次格納される。これらのジャーナルデータは、クラウドストレージ３１に分散して格納される。図３の例では、ジャーナルデータＤ１〜Ｄ３がクラウドストレージ３１−１のジャーナル管理領域３２−１に格納され、ジャーナルデータＤ４〜Ｄ６がクラウドストレージ３１−２のジャーナル管理領域３２−２に格納される。
【００５８】
リモートストレージ２１は、基本的には、ジャーナル管理領域３２に登録されたジャーナルデータを取得し、バックアップボリューム２２に格納する。しかし、性能情報格納領域３４に格納された性能情報を分析した結果、ジャーナルデータが頻繁に更新される可能性が高いと判断した場合に、リモートストレージ２１は、当該ジャーナルデータをリモートデータ退避領域３３に退避し、バックアップボリューム２２に格納しない。
【００５９】
図３の例では、ジャーナルデータＤ１及びＤ５が、リモートデータ退避領域に退避されている。その後、メインサイトが被災する等してバックアップデータが必要となると、リモートストレージ２１は、退避したジャーナルデータ（図３の例では、ジャーナルデータＤ１、Ｄ５）を取得し、バックアップボリューム２２に反映する。
【００６０】
続いて、クラウドストレージ３１に定義される各種データ領域の詳細を説明する。
【００６１】
図４は、ジャーナル管理領域３２の一例を示す図である。図４を参照すると、ジャーナル管理領域３２は、更新順序情報（ＩＤ；IDentifier）、マスタボリューム１２の識別情報（ＭＶＯＬ）、ボリューム内でのアドレス、ジャーナルデータ（更新されたブロック）を管理する。
【００６２】
図４の各エントリは、ジャーナルデータの登録状況を表す。例えば、図４の１行目のエントリは、ＩＤが「１００」のジャーナルデータは、マスタボリューム１２に含まれる記憶媒体ＭＶＯＬ＃００のアドレス「０００２」のブロックに対応するものであり、更新されたデータ値は「ＤＡＴＡ１００」であることを示している。
【００６３】
図５は、リモートデータ退避領域３３の一例を示す図である。リモートデータ退避領域３３のデータ格納構造は、図４に示すジャーナル管理領域３２の構造と同一である。図５の各エントリは、ジャーナル管理領域３２から転送されたジャーナルデータを表す。
【００６４】
図６は、性能情報格納領域３４の一例を示す図である。図６を参照すると、性能情報格納領域３４は、マスタボリューム１２の識別情報（ＭＶＯＬ）、ボリューム内でのアドレス、負荷情報、更新頻度を管理する。
【００６５】
図６の各エントリは、マスタボリューム１２の各ブロックにおける負荷状況を示す。図６に示す負荷情報は、例えば、ＩＯ密度（ＩＯＰＳ）である。ＩＯ密度が多い場合、該当ブロックに対するアクセス負荷が高いと判断される。
【００６６】
更新頻度は、例えば、過去の一定期間における該当ブロックのアドレスに対する更新回数とする。更新頻度が高いブロックは、ジャーナルデータの転送後も直ちに更新される可能性が高いと判断できる。例えば、図６を参照すると、マスタボリューム１２をなす記憶媒体ＭＶＯＬ＃００のアドレス「００００」におけるブロックの負荷状況（負荷情報、更新頻度）は、記憶媒体ＭＶＯＬ＃０１のアドレス「００００」の負荷状況よりも軽いものと判断できる。
【００６７】
続いて、リモートストレージ２１に構築されるテーブル情報の説明を行う。
【００６８】
図７は、ブロック割り当てテーブル３１１の一例を示す図である。ブロック割り当てテーブル３１１は、バックアップデータを管理するためのテーブル情報である。図７を参照すると、ブロック割り当てテーブル３１１には、マスタボリューム１２の識別情報（ＭＶＯＬ＃）、マスタボリューム１２内のアドレス、格納先、バックアップボリューム２２の識別情報（ＢＶＯＬ＃）、バックアップボリューム２２内のアドレス、退避対象の各フィールドが含まれる。
【００６９】
図７に示すマスタボリューム１２に関する情報（識別情報ＭＶＯＬ＃、アドレス）とバックアップボリューム２２に関する情報（識別情報ＢＶＯＬ＃、アドレス）により、バックアップデータの格納先を管理する。図７において、格納先のフィールドは、バックアップデータ（ジャーナルデータ）が実際に存在する場所を示す。具体的には、格納先フィールドに「ＬＯＣＡＬ」が設定されたデータは、リモートストレージ２１内のバックアップボリューム２２に格納されていることを示す。格納先が「ＬＯＣＡＬ」の場合には、バックアップボリューム２２上の領域が割り当てられ、当該領域に最新のジャーナルデータから抽出されたバックアップデータが格納されていることを示す。
【００７０】
なお、上述のように、バックアップボリューム２２に格納されたバックアップデータの格納先は、アクセス分析部３０３により適宜変更される。具体的には、アクセス分析部３０３が、性能情報を分析することで、マスタボリューム１２における高負荷なブロックに対応するバックアップデータは可能な限り異なる記憶媒体に格納されるように再配置される。その場合、バックアップデータがマスタボリューム１２をなす記憶媒体間で移動し、且つ、ブロック割り当てテーブル３１１の該当箇所が書き換えられる。一方、格納先フィールドに「クラウドストレージ３１」が設定されている場合には、最新のジャーナルデータはクラウドストレージ３１のリモートデータ退避領域３３に格納されていることを示す。この場合、バックアップデータは、バックアップボリューム２２には格納されていない。
【００７１】
格納先フィールドに「クラウドストレージ３１」が設定されたエントリのバックアップボリューム２２に関する情報（ＢＶＯＬ＃、アドレス）は、クラウドストレージ３１からジャーナルデータを取得した場合のバックアップボリューム２２におけるデータ格納先（複製先）を示す。図７の例では、５行目、６行目に対応するジャーナルデータはクラウドストレージ３１−１に格納されており、当該ジャーナルデータから抽出されるバックアップデータはバックアップボリューム２２の記憶媒体ＢＶＯＬ＃０１のアドレス「２０００」、「２００１」に格納予定であることを示す。
【００７２】
退避対象フィールドは、ジャーナルデータの退避に関する属性を示す。退避対象フィールドに「ＮＯ」が設定されていれば、マスタボリューム１２の該当ブロックに対応するジャーナルデータは退避の対象外であり、クラウドストレージ３１にジャーナルデータが登録されれば、即座に取得する必要があることを示す。
【００７３】
対して、退避対象フィールドに「ＹＥＳ」が設定されていれば、当該ブロックに対応するジャーナルデータはジャーナルデータが登録されても即座に取得せず、リモートデータ退避領域３３に退避する対象であることを示す。
【００７４】
図８は、性能情報テーブル３１２の一例を示す図である。図８に示す性能情報テーブル３１２のデータ格納構造は、図６に示す性能情報格納領域３４の構造と同一である。性能情報テーブル３１２は、マスタボリューム１２の負荷状況（性能）を管理するためのテーブルである。リモートストレージ２１のアクセス分析部３０３は、クラウドストレージ３１の性能情報格納領域３４から最新の性能情報を取得し、当該情報を性能情報テーブル３１２に反映する。
【００７５】
［動作の説明］
続いて、第１の実施形態に係る各装置、各モジュールの動作について説明する。
【００７６】
図９は、マスタストレージ１１のジャーナル転送部２０１の動作の一例を示すフローチャートである。
【００７７】
ジャーナル転送部２０１は、マスタボリューム１２が更新されるたびに動作する。ジャーナル転送部２０１は、更新されたデータが規定サイズに到達したか否か、又は、先にデータを更新してから所定の時間経過したブロックが存在するか否かに応じて、ジャーナルデータの生成要否を判定する（ステップＳ０１）。
【００７８】
ジャーナルデータの生成が不要であれば（ステップＳ０１、Ｎｏ分岐）、処理は終了する。
【００７９】
ジャーナルデータの生成が必要であれば（ステップＳ０１、Ｙｅｓ分岐）、ジャーナル転送部２０１は、更新されたデータ（更新されたブロック）に更新順序情報（ＩＤ）を付与してジャーナルデータを生成する（ステップＳ０２）。
【００８０】
その際、ジャーナル転送部２０１は、ジャーナルデータにマスタボリューム１２に関する情報（識別情報、アドレス）を付加してジャーナルボリューム１３に登録する（ステップＳ０３）。
【００８１】
その後、ジャーナル転送部２０１は、ジャーナルデータをクラウドストレージ３１に送信する（ステップＳ０４）。その際、ジャーナル転送部２０１は、２つのクラウドストレージ３１のうちいずれかを選択して、ジャーナルデータをクラウドストレージ３１のジャーナル管理領域３２に登録する。
【００８２】
なお、ジャーナルデータの転送先なるクラウドストレージ３１を決定する際には、ジャーナル転送部２０１は、転送先のクラウドストレージ３１との間の回線の混雑状況や負荷を判断し、ジャーナルデータがなるべく分散して配置されるようにする。また、ジャーナル転送部２０１は、ジャーナルデータの送信（登録）後には、ジャーナルボリューム１３からジャーナルデータを削除する。
【００８３】
ジャーナル転送部２０１によるジャーナルデータの送信のタイミングは、一定時間の間隔でまとめて転送してもよいし、ジャーナルデータ作成後、直ちに転送してもよい。
【００８４】
図１０は、マスタストレージ１１のアクセス監視部２０２の動作の一例を示すフローチャートである。
【００８５】
アクセス監視部２０２は、定期的に動作し、マスタボリューム１２の性能情報をブロック単位で収集する（ステップＳ１１）。
【００８６】
その後、アクセス監視部２０２は、２つのクラウドストレージ３１のいずれかを選択し、収集した性能情報をクラウドストレージ３１の性能情報格納領域３４に登録する（ステップＳ１２）。
【００８７】
図１１は、リモートストレージ２１のジャーナル取得部３０１の動作の一例を示すフローチャートである。
【００８８】
ジャーナル取得部３０１は、クラウドストレージ３１のジャーナル管理領域３２を定期的に参照する（ステップＳ２１）。なお、ジャーナルデータは更新順序通りに復元される必要がある。そこで、ジャーナル取得部３０１は、前回処理したデータの更新順序情報を記憶しておき、次の更新順序情報を持つジャーナルデータを処理対象とする。
【００８９】
その後、ジャーナル取得部３０１は、未取得（未転送）のジャーナルデータがジャーナル管理領域３２に存在するか否かを確認する（ステップＳ２２）。
【００９０】
未取得のジャーナルデータが存在しない場合（ステップＳ２２、Ｎｏ分岐）には、処理を終了する。
【００９１】
未取得のジャーナルデータが存在する場合（ステップＳ３２、Ｙｅｓ分岐）には、ジャーナル取得部３０１は、リモートデータ管理部３０２を起動する（ステップＳ２３）。
【００９２】
リモートデータ管理部３０２は、ブロック割り当てテーブル３１１を確認し、ジャーナル管理領域３２に存在するジャーナルデータをクラウドストレージ３１から取得する必要があるか否かを判定する。リモートデータ管理部３０２は、判定結果をジャーナル取得部３０１に通知する。
【００９３】
ジャーナル取得部３０１は、リモートデータ管理部３０２からの通知が「ジャーナルデータの取得は不要」であれば（ステップＳ２４、Ｎｏ分岐）、ジャーナルデータの取得は行わず処理を終了する。
【００９４】
通知が「ジャーナルデータの取得が必要」であれば（ステップＳ２４、Ｙｅｓ分岐）、ジャーナル取得部３０１は、クラウドストレージ３１のジャーナル管理領域３２からジャーナルデータを取得し、バックアップボリューム２２へ取得したデータを反映（登録、格納）する（ステップＳ２５）。
【００９５】
その後、ジャーナル取得部３０１は、クラウドストレージ３１からジャーナルデータを削除する（ステップＳ２６）。
【００９６】
図１２は、リモートストレージ２１のリモートデータ管理部３０２の動作の一例を示すフローチャートである。
【００９７】
リモートデータ管理部３０２は、ジャーナル取得部３０１からの起動要求で呼び出される、又は、リモートデータ退避領域３３に退避されたデータをバックアップボリュームに反映するための取得要求により呼び出される。なお、リモートデータ管理部３０２が呼び出される際には、マスタボリューム１２の識別情報とブロックのアドレスが指定される（ブロックが指定される）。
【００９８】
図１２（ａ）は、ジャーナル取得部３０１により起動された場合のリモートデータ管理部３０２の動作の一例を示す。
【００９９】
初めに、リモートデータ管理部３０２は、ブロック割り当てテーブル３１１における取得判定の対象となるブロックを参照する（ステップＳ３１）。
【０１００】
次に、リモートデータ管理部３０２は、対象となるブロック（ジャーナル取得部３０１により指定されたブロック）の退避が必要か否かを確認する（ステップＳ３２）。
【０１０１】
リモートデータ管理部３０２は、対象となるブロックの最新データがジャーナルデータとしてクラウドストレージ３１のジャーナル管理領域３２に存在し、且つ、退避対象（図７の退避対象フィールドに「ＹＥＳ」が設定）の場合、退避が必要と判断する。
【０１０２】
対して、リモートデータ管理部３０２は、対象となるブロックの最新データがジャーナルデータとしてクラウドストレージ３１のジャーナル管理領域３２に存在するが、当該ジャーナルデータが退避対象ではない場合（図７の退避対象フィールドに「ＮＯ」が設定）、退避は不要と判断する。
【０１０３】
退避が必要であれば（ステップＳ３２、Ｙｅｓ分岐）、リモートデータ管理部３０２は、ジャーナル取得部３０１に対して「取得が必要」を応答する（ステップＳ３３）。
【０１０４】
退避が不要であれば（ステップＳ３２、Ｎｏ分岐）、リモートデータ管理部３０２は、ジャーナル取得部３０１に対して「取得は不要」を応答する（ステップＳ３４）。
【０１０５】
図１２（ｂ）は、バックアップボリューム２２にデータを反映するための取得要求により呼び出された際のリモートデータ管理部３０２の動作を示す。なお、外部から災害発生等の通知を受けた場合に、コントローラ２３がリモートデータ管理部３０２に取得要求を発行する。
【０１０６】
初めに、リモートデータ管理部３０２は、ブロック割り当てテーブル３１１を参照する（ステップＳ４１）。
【０１０７】
その後、リモートデータ管理部３０２は、取得要求にて指定されたブロックが取得対象であるか否かを判断する（ステップＳ４２）。
【０１０８】
その際、リモートデータ管理部３０２は、指定されたブロックの格納先がクラウドストレージ３１である場合に、当該ブロックの取得が必要と判断する。
【０１０９】
ブロックの取得が不要であれば（ステップＳ４２、Ｎｏ分岐）、処理は終了する。
【０１１０】
ブロックの取得が必要であれば（ステップＳ４２、Ｙｅｓ分岐）、リモートデータ管理部３０２は、クラウドストレージ３１のリモートデータ退避領域３３からジャーナルデータを取得し、バックアップボリューム２２に反映する（ステップＳ４３）。
【０１１１】
その後、リモートデータ管理部３０２は、リモートデータ退避領域３３から取得済みのジャーナルデータを削除する（ステップＳ４４）。
【０１１２】
図１３は、リモートストレージ２１のアクセス分析部３０３の動作の一例を示すフローチャートである。アクセス分析部３０３は、定期的に呼び出され動作する。
【０１１３】
初めに、アクセス分析部３０３は、クラウドストレージ３１の性能情報格納領域３４に性能情報が格納されていれば、当該性能情報を取得する（ステップＳ５１）。
【０１１４】
その後、アクセス分析部３０３は、取得した性能情報を性能情報テーブル３１２に反映し、取得済みの性能情報をクラウドストレージ３１の性能情報格納領域３４から削除する（ステップＳ５２）。
【０１１５】
次に、アクセス分析部３０３は、性能情報テーブル３１２及びブロック割り当てテーブル３１１を参照し、各ブロックにおける負荷状況及び更新頻度を確認する（ステップＳ５３）。
【０１１６】
確認した結果、高負荷なブロックが存在し、且つ、当該ブロックの記憶先を入れ替える必要があると判断した場合（ステップＳ５４、Ｙｅｓ分岐）、アクセス分析部３０３は、当該ブロック（バックアップデータ）を入れ替える（ステップＳ５５）。具体的には、アクセス分析部３０３は、性能情報テーブル３１２の負荷情報フィールドに記載された値に対して閾値処理を実行し、予め定めた負荷よりも負荷を有するブロックを抽出する。その後、アクセス分析部３０３は、ブロック割り当てテーブル３１１を参照し、上記抽出されたブロックの格納先に偏りがあるか否かに応じて、ブロック（バックアップデータ）の記憶先を入れ替える必要があるか否かを判定する。
【０１１７】
このように、アクセス分析部３０３は、高負荷なブロックが存在する場合、同じ記憶媒体に当該ブロックが記録されると互いに干渉して性能低下が生じる可能性があるため、当該高負荷なブロックはなるべく同じ記憶媒体に記録しないようにバックアップデータを入れ替える。但し、高負荷なブロックであっても、当該ブロックに対応するジャーナルデータがクラウドストレージ３１に格納されている場合、データを入れ替える必要はないと判断される。つまり、高負荷なブロックの格納先が「ＬＯＣＡＬ」であれば、バックアップデータの付け替えが行われる可能性がある。
【０１１８】
バックアップデータの入れ替えが必要なければ（ステップＳ５４、Ｎｏ分岐）、アクセス分析部３０３は、高頻度に更新されるブロックが存在するか否かを判定する（ステップＳ５６）。具体的には、アクセス分析部３０３は、性能情報テーブル３１２の更新頻度フィールドに記載された値に対して閾値処理を実行し、予め定めた頻度よりも高頻度に更新されるブロックの有無を判定する。
【０１１９】
高頻度に更新されるブロックが存在しなければ（ステップＳ５６、Ｎｏ分岐）、処理を終了する。
【０１２０】
高頻度に更新されるブロックが存在すれば（ステップＳ５６、Ｙｅｓ分岐）、アクセス分析部３０３は、当該ブロックを退避対象に設定する（ステップＳ５７）。その際、アクセス分析部３０３は、ブロック割り当てテーブル３１１の該当ブロックの退避対象フィールドに「ＹＥＳ」を設定する。
【０１２１】
このように、高頻度で更新されるブロックが存在する場合、当該ブロックに対応するジャーナルデータをリモートストレージ２１のバックアップボリューム２２に格納しても再び更新される可能性が高いため、アクセス分析部３０３は、当該ブロックに対応するジャーナルデータを退避対象に決定し、ブロック割り当てテーブル３１１に反映する。
【０１２２】
なお、マスタストレージ１１、リモートストレージ２１に含まれるコントローラ１４、２３は、マスタストレージ１１、リモートストレージ２１に搭載されたコンピュータ（例えば、ＣＰＵ（Central Processing Unit）等）に、そのハードウェアを用いて、上述のした各コントローラの処理モジュールの処理を実行させるコンピュータプログラムにより実現することもできる。
【０１２３】
第１の実施形態では、マスタストレージ１１からリモートストレージ２１に転送されるジャーナルデータは、リモートストレージ２１から直ちに取得されず、必要に応じて退避領域に退避される。その結果、クラウドストレージ３１を利用したディザスタリカバリシステムでメインサイトとリモートサイトのストレージの構成が異なるような場合においても、クラウドストレージ３１とリモートストレージ２１間のネットワークのデータ転送量を削減できる。
【０１２４】
第１の実施形態では、マスタストレージ１１の性能情報を取得し、リモートストレージ２１側では、高負荷なブロックが分散されて配置される（高負荷なブロック間の干渉が抑制されるように配置される）。その結果、リモートサイトでは複数の業務間で干渉することにより発生し得る性能低下を抑制することができる。
【０１２５】
以上のように、第１の実施形態では、メインサイトのマスタストレージ１１と、遠隔地に設置されたリモートサイトのリモートストレージ２１の間に公衆回線等のネットワークで接続されたデータの登録、取得、削除が可能な一つ以上のクラウドストレージ３１を利用する。マスタストレージ１１の側では、マスタボリューム１２にて更新されたデータをマスタストレージ１１上のジャーナルボリューム１３に記録し、規定のサイズのブロックごとに、更新順序情報を付加してパッケージ化する。パッケージ化されたデータは、ジャーナルデータとして所定のクラウドストレージ３１のジャーナル管理領域３２に登録される。
【０１２６】
さらに、マスタストレージ１１の側ではマスタボリューム１２に対する各ブロックの負荷や更新頻度の性能情報を記録し、クラウドストレージ３１上の性能情報格納領域３４に性能情報として登録する。
【０１２７】
リモートストレージ２１の側では、クラウドストレージ３１上のジャーナルデータの有無を確認し、ジャーナルデータが存在する場合は付加された更新順序情報に従って、ジャーナル管理領域３２からジャーナルデータを取得し、順次バックアップボリューム２２に反映する。ただし、ジャーナルデータを取得する前に、更新対象のブロックを確認し、高負荷あるいは高頻度に更新されると判断した場合はブロック割り当てテーブル３１１の更新だけを行い、ジャーナルデータの取得は行わず、クラウドストレージ３１上のリモートデータ退避領域３３にジャーナルデータを退避する。
【０１２８】
また、リモートストレージ２１は、取得した性能情報に従って、被災後に運用を行った場合に、バックアップボリュームのアクセスの負荷が分散されるように格納領域の割り当ての付け替えを行う。
【０１２９】
その結果、メインサイトの被災時にはクラウドストレージ３１上の更新データをリモートストレージ２１に反映するがリモートストレージ２１の側ではアクセス負荷が分散されるように格納領域を配置しているため、被災後に構成変更やデータの再配置やデータの転送を行うことなくリモートサイトでの業務を継続できる。
【０１３０】
上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
［付記１］
上述の第１の視点に係るディザスタリカバリシステムのとおりである。
［付記２］
前記アクセス分析部は、
前記性能情報の分析結果に基づき、前記マスタボリュームをなすブロックのうち、ブロックに対する負荷が所定の値よりも高いブロックから得られるデータの格納先を入れ替える、付記１のディザスタリカバリシステム。
［付記３］
前記マスタストレージは、
前記マスタボリュームのデータが更新されたことに応じて、前記更新されたデータとデータの更新順序を示す更新順序情報を含むジャーナルデータを生成し、前記生成されたジャーナルデータを前記中間ストレージに転送すると共に、前記生成されたジャーナルデータを前記中間ストレージのジャーナル管理領域に格納する、ジャーナル転送部をさらに備える、付記２のディザスタリカバリシステム。
［付記４］
前記アクセス分析部は、
前記性能情報の分析結果に基づき、前記中間ストレージのジャーナル管理領域に格納されたジャーナルデータを、前記中間ストレージのリモートデータ退避領域に退避するか否かを決定する、付記３のディザスタリカバリシステム。
［付記５］
前記アクセス分析部は、
前記マスタボリュームをなすブロックのうち、ブロックに対する更新が所定の値よりも多いブロックに対応するジャーナルデータを、前記リモートデータ退避領域に退避するジャーナルデータと決定する、付記４のディザスタリカバリシステム。
［付記６］
前記リモートストレージは、
前記アクセス分析部が、前記ジャーナルデータを前記リモートデータ退避領域に退避しないと決定したジャーナルデータを取得する、ジャーナル取得部をさらに備える、付記４又は５のディザスタリカバリシステム。
［付記７］
前記リモートストレージは、
前記アクセス分析部が、前記ジャーナルデータを前記リモートデータ退避領域に退避すると決定したジャーナルデータを、前記中間ストレージの前記ジャーナル管理領域から前記リモートデータ退避領域に移動する、リモートデータ管理部をさらに備える、付記５又は６のディザスタリカバリシステム。
［付記８］
前記リモートデータ管理部は、
前記リモートデータ退避領域からジャーナルデータを取得する、付記７のディザスタリカバリシステム。
［付記９］
上述の第２の視点に係るディザスタリカバリ方法のとおりである。
［付記１０］
上述の第３の視点に係るプログラムのとおりである。
なお、付記９の形態及び付記１０の形態は、付記１の形態と同様に、付記２の形態〜付記８の形態に展開することが可能である。
【０１３１】
なお、引用した上記の特許文献等の各開示は、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の全開示の枠内において種々の開示要素（各請求項の各要素、各実施形態ないし実施例の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし、選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。
【符号の説明】
【０１３２】
１０、２０  ホスト計算器
１１、１０１  マスタストレージ
１２  マスタボリューム
１３  ジャーナルボリューム
１４、２３  コントローラ
２１、１０２  リモートストレージ
２２  バックアップボリューム
３１、３１−１、３１−２  クラウドストレージ
３２、３２−１、３２−２  ジャーナル管理領域
３３、３３−１、３３−２  リモートデータ退避領域
３４、３４−１、３４−２  性能情報格納領域
１０３  中間ストレージ
１１１、２０２  アクセス監視部
１２１、３０３  アクセス分析部
２０１  ジャーナル転送部
３０１  ジャーナル取得部
３０２  リモートデータ管理部
３１１  ブロック割り当てテーブル
３１２  性能情報テーブル
【図１】
2018169772.tif 000003
【図２】
2018169772.tif 000004
【図３】
2018169772.tif 000005
【図４】
2018169772.tif 000006
【図５】
2018169772.tif 000007
【図６】
2018169772.tif 000008
【図７】
2018169772.tif 000009
【図８】
2018169772.tif 000010
【図９】
2018169772.tif 000011
【図１０】
2018169772.tif 000012
【図１１】
2018169772.tif 000013
【図１２】
2018169772.tif 000014
【図１３】
2018169772.tif 000015