(57)【要約】  実施形態の情報処理システムは、障害発生時に、情報処理システムを利用できない時間を短縮する。実施形態の情報処理システムは、ユーザシステムのインストール情報と、ユーザシステムのデータのバックアップデータと、ユーザシステムのデータの一部を表すキャッシュデータを記憶する記憶部と、仮想マシン構築部と、ユーザシステムのデータを復元する復元部と、ユーザシステムのデータの一部を、キャッシュデータに複製し、ユーザシステムの障害時に、キャッシュデータからユーザシステムのデータの一部を復元することにより、ユーザシステムを部分復旧させるキャッシュ制御部と、部分復旧後、キャッシュデータにより復元されていないユーザシステムのデータを、バックアップデータによって復元することにより、ユーザシステムを完全復旧させるまでの間は、整合性が保障されないユーザシステムのデータへのアクセスを待機させるアクセス待機部とを備える。
2014049691.tif 000002
【特許請求の範囲】
【請求項１】
仮想マシンにより実現されるユーザシステムのインストール情報と、前記ユーザシステムのデータのバックアップデータと、前記ユーザシステムのデータの一部を表すキャッシュデータを記憶する記憶部と、
前記インストール情報により前記仮想マシンを構築する仮想マシン構築部と、
前記バックアップデータにより前記ユーザシステムのデータを復元する復元部と、
前記ユーザシステムのデータの一部を、前記キャッシュデータに複製し、前記ユーザシステムの障害時に、前記キャッシュデータから前記ユーザシステムのデータの一部を復元することにより、前記ユーザシステムを部分復旧させるキャッシュ制御部と、
前記部分復旧後、前記キャッシュデータにより復元されていない前記ユーザシステムのデータを、前記バックアップデータによって復元することにより、前記ユーザシステムを完全復旧させるまでの間は、整合性が保障されない前記ユーザシステムのデータへのアクセスを待機させるアクセス待機部と
を備える情報処理システム。
【請求項２】
前記ユーザシステムのデータの一部は、前記ユーザシステムからアクセスされたデータである
請求項１に記載の情報処理システム。
【請求項３】
前記キャッシュ制御部は、
前記バックアップデータが取得された後に、前記ユーザシステムからアクセスされたデータを、前記キャッシュデータに複製する
請求項２に記載の情報処理システム。
【請求項４】
前記キャッシュ制御部は、
前記バックアップデータが前記記憶部に記憶されたときに、前記キャッシュデータを削除する
請求項２又は３に記載の情報処理システム。
【請求項５】
前記ユーザシステムのデータの一部は、所定のデータである
請求項１に記載の情報処理システム。
【請求項６】
前記アクセス待機部は、
前記ユーザシステムのデータへのアクセスを待機させるときに、復元される前記ユーザシステムのデータのデータ量に基づいて、前記完全復旧にかかる時間を算出し、前記時間が所定の閾値を超える場合には、前記ユーザシステムのデータへのアクセスを待機させずにエラーを返却する
請求項１乃至５のいずれか１項に記載の情報処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、情報処理システムに関する。
【背景技術】
【０００２】
情報処理システムの運用形態の１つとして、１つのシステム環境を複数の企業等で利用するマルチテナントシステムが知られている。また、ユーザ毎にハードウェアを用意せずに、業務システム等のテナントシステムを動作させるために必要なプラットフォームを、仮想マシンによって提供するＰａａＳ（Ｐｌａｔｆｏｒｍ  ａｓ  ａ  Ｓｅｒｖｉｃｅ）が知られている。【０００３】
また、情報処理システムに障害が発生した場合に、当該情報処理システムを障害から復旧させる技術が知られている。障害復旧技術の一例としては、情報処理システムの特定の時点のバックアップデータであるスナップショットに基づいて、特定の時点の情報処理システムのアプリケーションの状態を再現する技術が知られている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１０−２０５０１１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、スナップショットを使用して、情報処理システムを復旧する場合、データ量が多い場合には復旧に時間がかかり、情報処理システムを利用できない時間が長いという課題がある。
【課題を解決するための手段】
【０００６】
実施形態の情報処理システムは、仮想マシンにより実現されるユーザシステムのインストール情報と、前記ユーザシステムのデータのバックアップデータと、前記ユーザシステムのデータの一部を表すキャッシュデータを記憶する記憶部と、前記インストール情報により前記仮想マシンを構築する仮想マシン構築部と、前記バックアップデータにより前記ユーザシステムのデータを復元する復元部と、前記ユーザシステムのデータの一部を、前記キャッシュデータに複製し、前記ユーザシステムの障害時に、前記キャッシュデータから前記ユーザシステムのデータの一部を復元することにより、前記ユーザシステムを部分復旧させるキャッシュ制御部と、前記部分復旧後、前記キャッシュデータにより復元されていない前記ユーザシステムのデータを、前記バックアップデータによって復元することにより、前記ユーザシステムを完全復旧させるまでの間は、整合性が保障されない前記ユーザシステムのデータへのアクセスを待機させるアクセス待機部とを備える。
【図面の簡単な説明】
【０００７】
【図１】図１は、情報処理システムの構成の一例を説明するための図である。
【図２】図２は、第１の実施形態の情報処理システムの構成の一例を説明するための図である。
【図３】図３は、第１の実施形態の情報処理システムの部分復旧直後のデータの一例を説明するための図である。
【図４】図４は、第１の実施形態の情報処理システムの完全復旧直後のデータの一例を説明するための図である。
【図５】図５は、第１の実施形態の情報処理システムの部分復旧時のアクセス待機判定方法の一例を説明するためのフローチャートである。
【図６】図６は、第２の実施形態の情報処理システムの部分復旧直後のデータの一例を説明するための図である。
【図７】図７は、第２の実施形態の情報処理システムの完全復旧直後のデータの一例を説明するための図である。
【図８】図８は、第２の実施形態の情報処理システムの部分復旧時のアクセス待機判定方法の一例を説明するためのフローチャートである。
【図９】図９は、第３の実施形態の情報処理システムの部分復旧直後のデータの一例を説明するための図である。
【図１０】図１０は、第３の実施形態の情報処理システムの完全復旧直後のデータの一例を説明するための図である。
【図１１】図１１は、第３の実施形態の情報処理システムの部分復旧時のアクセス待機判定方法の一例を説明するためのフローチャートである。
【図１２】図１２は、第１、２及び３の実施形態の情報処理システムの構成の変形例１を説明するための図である。
【図１３】図１３は、第１、２及び３の実施形態の情報処理システムの構成の変形例２を説明するための図である。
【図１４】図１４は、第１、２及び３の実施形態の情報処理システムの構成の変形例３を説明するための図である。
【図１５】図１５は、第１、２及び３の実施形態の障害復旧システム、並びに仮想マシンが動作する情報処理装置のハードウェア構成の一例を示す図である。
【発明を実施するための形態】
【０００８】
図１は、情報処理システム１００の構成の一例を説明するための図である。情報処理システム１００は、障害復旧システム１、仮想マシン２１、及びクライアント装置３１を備える。仮想マシン２１は、業務システム２２、及びデータリポジトリ２３を備える。業務システム２２は、ユーザがクライアント装置３１からアクセスすることにより利用される。データリポジトリ２３は、業務システム２２で使用されるデータ（以下「業務データ」という。）を記憶する。
【０００９】
障害復旧システム１は、仮想マシン２１に障害が発生した場合に、仮想マシン２１を、新しく作成することによって、ユーザの業務システム２２、及びデータリポジトリ２３を復旧させる。障害復旧システム１は、記憶部２、仮想マシン構築部３、及び復元部４を備える。
【００１０】
記憶部２は、インストールイメージ１１、及びスナップショットリポジトリ１２を記憶する。インストールイメージ１１は、仮想マシン２１により実現されるユーザのテナントシステムの初期状態を記憶したイメージファイルである。なお、インストールイメージ１１は、イメージファイル形式以外の形式のインストール情報であってもよい。スナップショットリポジトリ１２は、データリポジトリ２３の業務データのスナップショットを記憶する。スナップショットは、定期的に取得される業務データのバックアップデータである。
【００１１】
仮想マシン構築部３は、仮想マシン２１に障害が発生した際に、インストールイメージ１１を使用して、初期状態の仮想マシン２１を、新たに作成する。復元部４は、スナップショットリポジトリ１２を使用して、スナップショットによりデータリポジトリ２３を復元する。
【００１２】
情報処理システム１００は、インストールイメージ１１から、仮想マシン２１上に初期状態のテナントシステムを再現できるようにし、テナントシステム毎のデータは、スナップショットリポジトリ１２から復元している。ユーザのテナントシステムを、仮想マシン２１により実現することにより、ユーザ毎に待機系のハードウェアを用意することなく、テナントシステムの障害復旧を可能にしている。
【００１３】
（第１の実施形態）
図２は、第１の実施形態の情報処理システム１００の構成の一例を説明するための図である。情報処理システム１００は、障害復旧システム１、仮想マシン２１、及びクライアント装置３１を備える。まず、障害復旧システム１による障害復旧の対象となるユーザのテナントシステムについて説明する。
【００１４】
ユーザのテナントシステムは、仮想マシン２１により実現される。仮想マシン２１は、情報処理装置等のハードウェア上に、ソフトウェアとして１つ以上実現される。仮想マシン２１は、仮想マシン２１を実現するソフトウェアの制御により、他の装置やソフトウェアに対して、専用のハードウェアとして実現されているかのように動作する。
【００１５】
仮想マシン２１は、業務システム２２、及びデータリポジトリ２３を備える。業務システム２２は、ユーザがクライアント装置３１からアクセスすることにより利用される。データリポジトリ２３は、業務データを記憶する。業務システム２２は、クライアント装置３１の操作に応じて、業務データの登録、更新、参照、及び削除を行う。
【００１６】
なお、障害復旧システム１による障害復旧対象となるユーザのテナントシステム（業務システム２２、及びデータリポジトリ２３）は、業務に使用されるシステムに限られない。また、テナントシステムではなく、任意のユーザシステムでもよい。すなわち、仮想マシン２１上で動作する任意のシステム（ソフトウェア）でもよい。
【００１７】
また、本実施形態では、データリポジトリ２３の形態をＫＶＳ（Ｋｅｙ  Ｖａｌｕｅ  Ｓｔｏｒｅ）とする。ＫＶＳは、データと、当該データを識別するキーをペアで保存する記憶方式である。
【００１８】
本実施形態の障害復旧システム１は、記憶部２、仮想マシン構築部３、復元部４、キャッシュ制御部５、及びアクセス待機部６を備える。
【００１９】
記憶部２は、インストールイメージ１１、スナップショットリポジトリ１２、及びキャッシュリポジトリ１３を記憶する。インストールイメージ１１は、仮想マシン２１により実現されるユーザのテナントシステムの初期状態のデータである。スナップショットリポジトリ１２は、データリポジトリ２３の業務データのスナップショットを記憶する。キャッシュリポジトリ１３は、業務データの一部を表すキャッシュデータを記憶する。
【００２０】
仮想マシン構築部３は、仮想マシン２１に障害が発生した際に、インストールイメージ１１を使用して、初期状態の仮想マシン２１を、新たに作成する。
【００２１】
復元部４は、スナップショットリポジトリ１２を使用して、スナップショットによりデータリポジトリ２３を復元する。なお、復元部４は、キャッシュ制御部５により、キャッシュリポジトリ１３のキャッシュデータから復元されたデータは、スナップショットに含まれる対応するデータにより上書きしない。
【００２２】
キャッシュ制御部５、及びアクセス待機部６は、業務システム２２とデータリポジトリ２３との間に存在し、プロキシとして動作する。すなわち、業務システム２２が、データリポジトリ２３の業務データにアクセスする場合は、キャッシュ制御部５、及びアクセス待機部６を介してアクセスする。
【００２３】
キャッシュ制御部５は、業務システム２２からアクセスされた業務データを、キャッシュリポジトリ１３に複製する。また、キャッシュ制御部５は、スナップショットがスナップショットリポジトリ１２に記憶されたときに、キャッシュデータを削除する。これにより、キャッシュデータの容量の増大を防ぐ。なお、キャッシュ制御部５は、データが登録されてからの経過日数や、データのアクセス頻度等に基づいて、キャッシュデータの一部のみを削除してもよい。
【００２４】
また、キャッシュ制御部５は、業務システム２２の障害時に、キャッシュリポジトリ１３のキャッシュデータから復元された業務データにより、業務システム２２を部分的に復旧させる。すなわち、障害復旧システム１は、スナップショットリポジトリ１２のスナップショットを使用せずに、キャッシュデータから、業務データの一部を復元して、業務システム２２を復旧する。
【００２５】
なお、ユーザのテナントシステム（仮想マシン２１）を部分的に復旧させるために必要なキャッシュデータは、テナントシステム毎に異なる。キャッシュリポジトリ１３に保存するキャッシュデータの取得方法の一例としては、スナップショット作成後から、アクセスされた業務データを全て取得する方法がある。
【００２６】
アクセス待機部６は、仮想マシン２１の状態が正常である場合は何もしない。アクセス待機部６は、キャッシュ制御部５による部分的な業務データの復旧後、復元部４による完全な業務データの復元前（以下「部分復旧」という。）に、整合性が保障されない業務データへのアクセスを待機させる。すなわち、アクセス待機部６は、整合性が保障されない業務データへのアクセス要求をバッファ等に保持する。アクセス待機部６は、仮想マシン２１の状態が再び正常に戻ったときに、ＦＩＦＯ（Ｆｉｒｓｔ  Ｉｎ  Ｆｉｒｓｔ  Ｏｕｔ）方式等により、バッファに保持されていた当該アクセス要求を開放する。アクセス待機部６による具体的なアクセス待機判定方法については後述する。
【００２７】
アクセス待機部６は、復元部４による完全な業務データの復元後（以下「完全復旧」という。）は、仮想マシン２１の状態が再び正常に戻ったことを認識する。
【００２８】
なお、本実施形態の仮想マシン構築部３、復元部４、キャッシュ制御部５、及びアクセス待機部６は、ソフトウェアにより実現してもよいし、ＩＣ（Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）等のハードウェアにより実現してもよい。または、ソフトウェア及びハードウェアの両方により実現してもよい。
【００２９】
次に、図３及び図４を用いて、障害発生から完全復旧までの間における本実施形態のスナップショットリポジトリ１２、キャッシュリポジトリ１３、及びデータリポジトリ２３のデータの状態について説明する。
【００３０】
図３は、第１の実施形態の情報処理システム１００の部分復旧直後のデータの一例を説明するための図である。データ６０は、障害発生直前のスナップショットリポジトリ１２のデータである。データ７０は、障害発生直前のデータリポジトリ２３のデータである。データ８０は、障害発生直前のキャッシュリポジトリ１３のデータである。
【００３１】
図３の障害発生直前のデータの例では、データリポジトリ２３の（ＫＥＹ，ＶＡＬＵＥ）＝（ＦＦＦ２，ＶＡＬＵＥ１００）のデータが、スナップショット取得後に更新されている（ＫＥＹ＝ＦＦＦ２のＶＡＬＵＥが、ＶＡＬＵＥ２からＶＡＬＵＥ１００に更新されている）。また、（ＫＥＹ，ＶＡＬＵＥ）＝（ＦＦＦ３，ＶＡＬＵＥ３）のデータが、スナップショット取得後に、データリポジトリ２３に登録されている。
【００３２】
そのため、キャッシュリポジトリ１３には、データ８０（（ＫＥＹ，ＶＡＬＵＥ）＝（ＦＦＦ２，ＶＡＬＵＥ１００），（ＦＦＦ３，ＶＡＬＵＥ３））が記憶されている。すなわち、本実施形態のキャッシュリポジトリ１３は、スナップショット取得後にアクセスされたデータリポジトリ２３のデータを記憶する。
【００３３】
データ６１は、部分復旧直後のスナップショットリポジトリ１２のデータである。データ７１は、部分復旧直後のデータリポジトリ２３のデータである。データ８１は、部分復旧直後のキャッシュリポジトリ１３のデータである。
【００３４】
図３の部分復旧直後のデータの例では、データリポジトリ２３のデータ７１（（ＫＥＹ，ＶＡＬＵＥ）＝（ＦＦＦ２，ＶＡＬＵＥ１００），（ＦＦＦ３，ＶＡＬＵＥ３））が、障害発生直前のキャッシュリポジトリ１３のデータ８０から復旧されている。データリポジトリ２３が部分復旧された後、キャッシュリポジトリ１３のデータ８０は、キャッシュ制御部５により削除される。
【００３５】
図４は、第１の実施形態の情報処理システム１００の完全復旧直後のデータの一例を説明するための図である。データ６２は、部分復旧状態のスナップショットリポジトリ１２のデータである。データ７２は、部分復旧状態のデータリポジトリ２３のデータである。データ８２は、部分復旧状態のキャッシュリポジトリ１３のデータである。
【００３６】
図４の部分復旧状態のデータの例では、データリポジトリ２３の（ＫＥＹ，ＶＡＬＵＥ）＝（ＦＦＦ３，ＶＡＬＵＥ２００）のデータが、部分復旧状態のときに、更新されている（ＶＡＬＵＥが、ＶＡＬＵＥ３からＶＡＬＵＥ２００に更新されている）。そのため、（ＫＥＹ，ＶＡＬＵＥ）＝（ＦＦＦ３，ＶＡＬＵＥ２００）のデータが、キャッシュリポジトリ１３に登録されている。すなわち、本実施形態のキャッシュリポジトリ１３は、部分復旧状態のときにアクセスされたデータリポジトリ２３のデータを記憶する。
【００３７】
データ６３は、完全復旧直後のスナップショットリポジトリ１２のデータである。データ７３は、完全復旧直後のデータリポジトリ２３のデータである。データ８３は、完全復旧直後のキャッシュリポジトリ１３のデータである。
【００３８】
図４の完全復旧直後のデータの例では、データリポジトリ２３のデータ７３のうち、（ＫＥＹ，ＶＡＬＵＥ）＝（ＦＦＦ０，ＶＡＬＵＥ１），（ＦＦＦ１，ＶＡＬＵＥ２）が、スナップショットリポジトリ１２のデータ６２を使用して、復元されている。なお、復元部４は、（ＫＥＹ，ＶＡＬＵＥ）＝（ＦＦＦ２，ＶＡＬＵＥ２）は、既に、障害発生直前のキャッシュリポジトリ１３のデータ８０（図３）から復元されているため、ＫＥＹ＝ＦＦＦ２のＶＡＬＵＥをＶＡＬＵＥ２で上書きしない。
【００３９】
次に、部分復旧状態における本実施形態のアクセス待機判定方法について説明する。図５は、第１の実施形態の情報処理システム１００の部分復旧時のアクセス待機判定方法の一例を説明するためのフローチャートである。
【００４０】
アクセス待機部６は、データリポジトリ２３へのアクセスが登録処理であるか否かを判定する（ステップＳ１）。登録処理である場合（ステップＳ１、Ｙｅｓ）は、ステップＳ２に進む。登録処理でない場合（ステップＳ１、Ｎｏ）は、ステップＳ３に進む。
【００４１】
アクセス待機部６は、ユーザがＫＥＹを発行する処理であるか否かを判定する（ステップＳ２）。アクセス待機部６は、ユーザがＫＥＹを発行する処理である場合（ステップＳ２、Ｙｅｓ）は、データリポジトリ２３へのアクセスを待機させる（ステップＳ６）。これにより、データリポジトリ２３に、ユーザから業務システム２２の想定外のデータが登録されることにより、データ整合性がとれなくなることを防ぐ。
【００４２】
アクセス待機部６は、ユーザがＫＥＹを発行する処理でない場合（ステップＳ２、Ｎｏ）は、データリポジトリ２３へのアクセスを待機させない（ステップＳ５）。業務システム２２が、想定されている適切なＫＥＹを発行するため、部分復旧状態のデータリポジトリ２３にデータを新規に登録しても、データの整合性が保たれると判断するためである。
【００４３】
アクセス待機部６は、ＫＥＹが指定されている処理（参照、更新、又は削除）であるか否かを判定する（ステップＳ３）。ＫＥＹが指定されている処理である場合（ステップＳ３、Ｙｅｓ）は、ステップＳ４に進む。ＫＥＹが指定されていない処理である場合（ステップＳ３、Ｎｏ）は、データリポジトリ２３へのアクセスを待機させる（ステップＳ６）。ＫＥＹの指定の有無によりアクセスの待機有無を判断する理由は、ＫＥＹの指定の有無が、当該処理後のデータの整合性を保障できるか否かの１つの指針となるためである。
【００４４】
アクセス待機部６は、データリポジトリ２３に処理対象のデータが存在しているか否かを判定する（ステップＳ４）。処理対象のデータが存在している場合（ステップＳ４、Ｙｅｓ）は、データリポジトリ２３へのアクセスを待機させない（ステップＳ５）。処理対象のデータが存在していない場合（ステップＳ４、Ｎｏ）は、データリポジトリ２３へのアクセスを待機させる（ステップＳ６）。
【００４５】
上述のアクセス待機判定方法によれば、部分復旧状態におけるＫＶＳ方式のデータリポジトリ２３へのアクセスで、待機させない操作は、以下の（１）〜（４）の場合である。
【００４６】
（１）ＫＶＳに登録されているデータを、ＫＥＹを指定して参照する。（２）ＫＶＳに登録されているデータを、ＫＥＹを指定して更新する。（３）ＫＶＳに登録されているデータを、ＫＥＹを指定して削除する。（４）業務システム２２により適切なＫＥＹが発行されたデータを登録する。
【００４７】
本実施形態の情報処理システム１００によれば、仮想マシン２１に障害が発生しても、ユーザのテナントシステムを迅速に部分復旧すること、及び上述のアクセス待機判定方法により、ユーザによって直近に利用されていたＫＶＳ方式のデータリポジトリ２３のデータに関する操作の継続可能性が保障される。
【００４８】
また、本実施形態の情報処理システム１００によれば、ユーザのテナントシステムが、部分復旧状態であっても、ＫＶＳ方式のデータリポジトリ２３のデータの整合性が保たれる操作は、当該操作を待機させずに完了させることができる。
【００４９】
なお、アクセス待機部６は、データリポジトリ２３へのアクセスを待機させる場合に、復旧させるデータ量等に基づいて、データリポジトリ２３を完全復旧させるために必要となる時間を算出し、タイムアウトするか否かを判定してもよい。
【００５０】
また、アクセス待機部６は、完全復旧するまでアクセスを待機させる際に、完全復旧に時間がかかることが想定される場合には、ユーザのクライアント装置３１に、すぐにエラーを返してもよい。すなわち、アクセス待機部６は、復元される業務データ量に基づいて、完全復旧にかかる時間を算出し、当該時間が所定の閾値を超える場合には、業務データへのアクセスを待機させずにエラーを返却するようにしてもよい。
【００５１】
（第２の実施形態）
第１の実施形態の情報処理システム１００は、仮想マシン２１のデータリポジトリ２３をＫＶＳであるとした。しかしながら、データリポジトリ２３の記憶方式は、ＫＶＳに限られない。本実施形態では、仮想マシン２１のデータリポジトリ２３が、ＲＤＢ（Ｒｅｌａｔｉｏｎａｌ  Ｄａｔａｂａｓｅ）である場合について説明する。一般に、ＲＤＢは、ＫＶＳよりもデータ同士に依存性や関連性がある。本実施形態では、このような場合について説明する。
【００５２】
本実施形態の情報処理システム１００の構成は、図２の第１の実施形態の情報処理システム１００と同様である。本実施形態の情報処理システム１００の構成の説明については、第１の実施形態の情報処理システム１００と同様の箇所は省略する。また、本実施形態の情報処理システム１００により復旧対象となるユーザのテナントシステムは、データリポジトリ２３の記憶方式が、ＫＶＳではなくＲＤＢである点以外は同様である。
【００５３】
本実施形態のキャッシュ制御部５は、第１の実施形態と同様に、業務システム２２からデータリポジトリ２３へのアクセスを中継するプロキシとして働く。また、キャッシュ制御部５は、業務システム２２からデータリポジトリ２３へ登録、更新、及び参照されるデータを、キャッシュリポジトリ１３に複製する。
【００５４】
ここで、キャッシュ制御部５は、参照及び更新等により、対象のレコードの特定のカラムのみにアクセスするクエリ文については、当該カラムのみではなく、全てのカラムを取得して、キャッシュリポジトリ１３に登録する。
【００５５】
図６及び図７を用いて、障害発生から完全復旧までの間における、本実施形態のスナップショットリポジトリ１２、キャッシュリポジトリ１３、及びデータリポジトリ２３のデータの状態について説明する。
【００５６】
図６及び図７の例では、データリポジトリ２３が、ＩＤ、ＮＡＭＥ、及びＤＥＰＩＤのカラムを有する社員テーブルと、ＤＥＰＩＤ、及びＤＥＰＴ＿ＮＡＭＥのカラムを有する所属テーブルとを記憶する場合について説明する。なお、社員テーブルのＤＥＰＩＤは、所属テーブルでは、主キーとなっている。すなわち、社員テーブルのＤＥＰＩＤは、外部キーである。
【００５７】
図６は、第２の実施形態の情報処理システム１００の部分復旧直後のデータの一例を説明するための図である。データ１２０は、障害発生直前のスナップショットリポジトリ１２のデータである。データ１２０は、データ１２１、及びデータ１２２を含む。データ１２１は、障害発生直前の社員テーブルのデータである。データ１２２は、障害発生直前の所属テーブルのデータである。
【００５８】
データ１４０は、障害発生直前のデータリポジトリ２３のデータである。データ１４０は、データ１４１、及びデータ１４２を含む。データ１４１は、障害発生直前の社員テーブルのデータである。データ１４２は、障害発生直前の所属テーブルのデータである。
【００５９】
データ１６０は、障害発生直前のキャッシュリポジトリ１３のデータである。データ１６０は、データ１６１、及びデータ１６２を含む。データ１６１は、障害発生直前の社員テーブルのデータである。データ１６２は、障害発生直前の所属テーブルのデータである。
【００６０】
図６の障害発生直前のデータの例では、データリポジトリ２３の（ＩＤ，ＮＡＭＥ，ＤＥＰＩＤ）＝（２，Ｎａｍｅ０３，２）のデータが、スナップショット取得後に更新されている（ＤＥＰＩＤが、１から２に更新されている）。また、（ＩＤ，ＮＡＭＥ，ＤＥＰＩＤ）＝（３，Ｎａｍｅ０４，２）のデータが、スナップショット取得後に、データリポジトリ２３に登録されている。
【００６１】
そのため、キャッシュリポジトリ１３には、データ１６１（（ＩＤ，ＮＡＭＥ，ＤＥＰＩＤ）＝（２，Ｎａｍｅ０３，２），（３，Ｎａｍｅ０４，２））が記憶されている。また、社員テーブルの外部キーＤＥＰＩＤ＝２に関連する所属テーブルのデータ１６２（（ＤＥＰＩＤ，ＤＥＰＴ＿ＮＡＭＥ）＝（２，Ｍａｎａｇｅｍｅｎｔ））についても記憶される。すなわち、本実施形態のキャッシュリポジトリ１３は、スナップショット取得後にアクセスされたデータリポジトリ２３のデータと、当該データに、外部キー等の設定により関連するデータとを記憶する。
【００６２】
データ１２３は、部分復旧直後のスナップショットリポジトリ１２のデータである。データ１２３は、データ１２４、及びデータ１２５を含む。データ１２４は、部分復旧直後の社員テーブルのデータである。データ１２５は、部分復旧直後の所属テーブルのデータである。
【００６３】
データ１４３は、部分復旧直後のデータリポジトリ２３のデータである。データ１４３は、データ１４４、及びデータ１４５を含む。データ１４４は、部分復旧直後の社員テーブルのデータである。データ１４５は、部分復旧直後の所属テーブルのデータである。
【００６４】
データ１６３は、部分復旧直後のキャッシュリポジトリ１３のデータである。データ１６３は、データ１６４、及びデータ１６５を含む。データ１６４は、部分復旧直後の社員テーブルのデータである。データ１６５は、部分復旧直後の所属テーブルのデータである。
【００６５】
図６の部分復旧直後のデータの例では、データリポジトリ２３のデータ１４４（（ＩＤ，ＮＡＭＥ，ＤＥＰＩＤ）＝（２，Ｎａｍｅ０３，２），（３，Ｎａｍｅ０４，２））が障害発生直前のキャッシュリポジトリ１３のデータ１６１から復旧されている。また、データリポジトリ２３のデータ１４５（（ＤＥＰＩＤ，ＤＥＰＴ＿ＮＡＭＥ）＝（２，Ｍａｎａｇｅｍｅｎｔ））が、障害発生直前のキャッシュリポジトリ１３のデータ１６２から復旧されている。データリポジトリ２３が部分復旧された後、キャッシュリポジトリ１３のデータ１６１及びデータ１６２は、キャッシュ制御部５により削除される。
【００６６】
図７は、第２の実施形態の情報処理システム１００の完全復旧直後のデータの一例を説明するための図である。データ１２６は、部分復旧状態のスナップショットリポジトリ１２のデータである。データ１２６は、データ１２７、及びデータ１２８を含む。データ１２７は、部分復旧状態の社員テーブルのデータである。データ１２８は、部分復旧状態の所属テーブルのデータである。
【００６７】
データ１４６は、部分復旧状態のデータリポジトリ２３のデータである。データ１４６は、データ１４７、及びデータ１４８を含む。データ１４７は、部分復旧状態の社員テーブルのデータである。データ１４８は、部分復旧状態の所属テーブルのデータである。
【００６８】
データ１６６は、部分復旧状態のキャッシュリポジトリ１３のデータである。データ１６６は、データ１６７、及びデータ１６８を含む。データ１６７は、部分復旧状態の社員テーブルのデータである。データ１６８は、部分復旧状態の所属テーブルのデータである。
【００６９】
図７の部分復旧状態のデータの例では、データリポジトリ２３の（ＩＤ，ＮＡＭＥ，ＤＥＰＩＤ）＝（３，Ｎａｍｅ１０，２）のデータが、部分復旧状態のときに、更新されている（ＮＡＭＥが、Ｎａｍｅ０４からＮａｍｅ１０に更新されている）。そのため、（ＩＤ，ＮＡＭＥ，ＤＥＰＩＤ）＝（３，Ｎａｍｅ１０，２）のデータが、キャッシュリポジトリ１３に登録されている。また、社員テーブルの外部キーＤＥＰＩＤ＝２に関連する所属テーブルのデータ１６８（（ＤＥＰＩＤ，ＤＥＰＴ＿ＮＡＭＥ）＝（２，Ｍａｎａｇｅｍｅｎｔ））についても記憶される。
【００７０】
すなわち、本実施形態のキャッシュリポジトリ１３は、部分復旧状態のときにアクセスされたデータリポジトリ２３のデータと、当該データに、外部キー等の設定により関連するデータとを記憶する。
【００７１】
データ１２９は、完全復旧直後のスナップショットリポジトリ１２のデータである。データ１２９は、データ１３０、及びデータ１３１を含む。データ１３０は、完全復旧直後の社員テーブルのデータである。データ１３１は、完全復旧直後の所属テーブルのデータである。
【００７２】
データ１４９は、完全復旧直後のデータリポジトリ２３のデータである。データ１４９は、データ１５０、及びデータ１５１を含む。データ１５０は、完全復旧直後の社員テーブルのデータである。データ１５１は、完全復旧直後の所属テーブルのデータである。
【００７３】
データ１６９は、完全復旧直後のキャッシュリポジトリ１３のデータである。データ１６９は、データ１７０、及びデータ１７１を含む。データ１７０は、完全復旧直後の社員テーブルのデータである。データ１７１は、完全復旧直後の所属テーブルのデータである。
【００７４】
図７の完全復旧直後のデータの例では、データリポジトリ２３のデータ１５０のうち、（ＩＤ，ＮＡＭＥ，ＤＥＰＩＤ）＝（０，Ｎａｍｅ０１，０），（１，Ｎａｍｅ０２，１）が、スナップショットリポジトリ１２のデータ１２７を使用して、復元されている。また、データリポジトリ２３のデータ１５１のうち、（ＤＥＰＩＤ，ＤＥＰＴ＿ＮＡＭＥ）＝（０，Ｓａｌｅｓ），（１，Ｄｅｖｅｌｏｐ）が、スナップショットリポジトリ１２のデータ１２８を使用して、復元されている。
【００７５】
なお、復元部４は、（ＩＤ，ＮＡＭＥ，ＤＥＰＩＤ）＝（２，Ｎａｍｅ０３，２）は、既に、障害発生直前のキャッシュリポジトリ１３のデータ１６１（図６）から復元されているため、ＤＥＰＩＤを１で上書きしない。
【００７６】
次に、部分復旧状態における本実施形態のアクセス待機判定方法について説明する。図８は、第２の実施形態の情報処理システム１００の部分復旧時のアクセス待機判定方法の一例を説明するためのフローチャートである。
【００７７】
アクセス待機部６は、データリポジトリ２３へのアクセスが登録処理であるか否かを判定する（ステップＳ１１）。登録処理である場合（ステップＳ１１、Ｙｅｓ）は、ステップＳ１２に進む。登録処理でない場合（ステップＳ１１、Ｎｏ）は、ステップＳ１４に進む。
【００７８】
アクセス待機部６は、ユーザが主キーを発行する処理であるか否かを判定する（ステップＳ１２）。アクセス待機部６は、ユーザが主キーを発行する処理である場合（ステップＳ１２、Ｙｅｓ）は、データリポジトリ２３へのアクセスを待機させる（ステップＳ２０）。これにより、ユーザが、業務システム２２の想定外のデータを、データリポジトリ２３に登録することによってデータの整合性がとれなくなることを防ぐ。
【００７９】
アクセス待機部６は、ユーザが主キーを発行する処理でない場合（ステップＳ１２、Ｎｏ）は、データリポジトリ２３へのアクセスを待機させない（ステップＳ１３）。業務システム２２が、想定されている適切な主キーを発行するため、部分復旧状態のデータリポジトリ２３にデータを新規に登録しても、データの整合性が保たれると判断するためである。
【００８０】
アクセス待機部６は、主キーが指定されている処理（参照、更新、又は削除）であるか否かを判定する（ステップＳ１４）。主キーが指定されている処理である場合（ステップＳ１４、Ｙｅｓ）は、ステップＳ１５に進む。主キーが指定されていない処理である場合（ステップＳ１４、Ｎｏ）は、データリポジトリ２３へのアクセスを待機させる（ステップＳ２０）。主キーの指定の有無によりアクセスの待機有無を判断する理由は、主キーの指定の有無が、当該処理後のデータの整合性を保障できるか否かの１つの指針となるためである。
【００８１】
アクセス待機部６は、データリポジトリ２３に処理対象のデータが存在しているか否かを判定する（ステップＳ１５）。処理対象のデータが存在している場合（ステップＳ１５、Ｙｅｓ）は、ステップＳ１６に進む。処理対象のデータが存在していない場合（ステップＳ１５、Ｎｏ）は、データリポジトリ２３へのアクセスを待機させる（ステップＳ２０）。
【００８２】
アクセス待機部６は、データリポジトリ２３へのアクセスが更新処理であるか否かを判定する（ステップＳ１６）。アクセスが更新処理である場合（ステップＳ１６、Ｙｅｓ）は、ステップＳ１７に進む。アクセスが更新処理でない場合（ステップＳ１６、Ｎｏ）は、ステップＳ１８に進む。
【００８３】
アクセス待機部６は、更新処理の対象となるカラムが、外部キーとして利用されるカラムであるか否かを判定する（ステップＳ１７）。外部キーとして利用されるカラムである場合（ステップＳ１７、Ｙｅｓ）は、データリポジトリ２３へのアクセスを待機させる（ステップＳ２０）。外部キーとして利用されるカラムでない場合（ステップＳ１７、Ｎｏ）は、データリポジトリ２３へのアクセスを待機させない（ステップＳ１３）。
【００８４】
アクセス待機部６は、データリポジトリ２３へのアクセスが削除処理であるか否かを判定する（ステップＳ１８）。アクセスが削除処理である場合（ステップＳ１８、Ｙｅｓ）は、ステップＳ１９に進む。アクセスが削除処理ではない場合（ステップＳ１８、Ｎｏ）は、データリポジトリ２３へのアクセスを待機させない（ステップＳ１３）。
【００８５】
アクセス待機部６は、削除対象のデータに、外部キーとして利用されるカラムが含まれているか否かを判定する（ステップＳ１９）。外部キーとして利用されるカラムが含まれている場合（ステップＳ１９、Ｙｅｓ）は、データリポジトリ２３へのアクセスを待機させる（ステップＳ２０）。外部キーとして利用されるカラムが含まれていない場合（ステップＳ１９、Ｎｏ）は、データリポジトリ２３へのアクセスを待機させない（ステップＳ１３）。
【００８６】
上述のアクセス待機判定方法によれば、部分復旧状態におけるＲＤＢ方式のデータリポジトリ２３へのアクセスで、待機させない操作は、以下の（１）〜（４）の場合である。
【００８７】
（１）ＲＤＢに登録されているデータを、主キーを指定して参照する。（２）ＲＤＢに登録されているデータの外部キーとして利用されないカラムを、主キーを指定して更新する。（３）外部キーとして利用されるカラムが存在しないテーブルから、主キーを指定してデータを削除する。（４）業務システム２２により適切な主キーが発行されたデータを登録する。
【００８８】
本実施形態の情報処理システム１００によれば、仮想マシン２１に障害が発生しても、仮想マシン２１を迅速に部分復旧すること、及び上述のアクセス待機判定方法により、ユーザによって直近に利用されていたＲＤＢ方式のデータリポジトリ２３のデータに関する操作の継続可能性が保障される。
【００８９】
また、本実施形態の情報処理システム１００によれば、仮想マシン２１が、部分復旧状態であっても、ＲＤＢ方式のデータリポジトリ２３のデータの整合性が保たれる操作は、当該操作を待機させずに完了させることができる。
【００９０】
（第３の実施形態）
第１及び２の実施形態の情報処理システム１００では、キャッシュ制御部５が、スナップショット取得後にアクセスされたデータリポジトリ２３のデータを、キャッシュリポジトリ１３に登録した。しかしながら、キャッシュリポジトリ１３には、ユーザによるアクセス有無によらずに、予め所定のデータを登録しておいてもよい。これにより、障害復旧システム１は、仮想マシン２１により実現されるテナントシステムの部分復旧範囲を広げることができる。本実施形態では、このような場合について説明する。
【００９１】
本実施形態の情報処理システム１００の構成は、図２の第１の実施形態の情報処理システム１００と同様である。本実施形態の情報処理システム１００の構成の説明については、第１の実施形態の情報処理システム１００と同様の箇所は省略する。また、本実施形態の情報処理システム１００により復旧対象となるユーザのテナントシステムは、データリポジトリ２３の記憶方式が、ＲＤＢであるとして説明する。しかしながら、復旧対象となるユーザのテナントシステムのデータリポジトリ２３の記憶方式は、ＲＤＢに限られない。
【００９２】
本実施形態のキャッシュリポジトリ１３は、業務データの一部を表すキャッシュデータを記憶する。キャッシュリポジトリ１３は、業務システム２２からアクセスされた業務データだけではなく、更に、予め定められた所定のデータを記憶する。当該所定のデータは、例えば、業務システム２２を運用するために必ず参照されるテーブルのデータや、アクセス頻度の高いテーブルのデータ等、業務システム２２にとって重要な役割を担うデータである。
【００９３】
なお、キャッシュリポジトリ１３に記憶された当該所定のデータは、業務システム２２からデータリポジトリ２３へのアクセスの一次キャッシュとして使用してもよい。これにより、障害の発生していない通常の運用時においても、業務システム２２からデータリポジトリ２３のデータにアクセスする処理を高速化するという効果がある。
【００９４】
なお、当該所定のデータを、業務システム２２における重要なテーブルの全データとしてもよい。当該重要なテーブルは、業務システム２２上で動作するアプリケーション毎に、どのテーブルが該当するかを対応付けることにより、予め定めておいてもよい。
【００９５】
図９及び図１０を用いて、障害発生から完全復旧までの間における、本実施形態のスナップショットリポジトリ１２、キャッシュリポジトリ１３、及びデータリポジトリ２３のデータの状態について説明する。
【００９６】
図９及び図１０の例では、データリポジトリ２３が、ＩＤ、ＮＡＭＥ、及びＤＥＰＩＤのカラムを有する社員テーブルと、ＤＥＰＩＤ、及びＤＥＰＴ＿ＮＡＭＥのカラムを有する所属テーブルとを記憶する場合について説明する。なお、社員テーブルのＤＥＰＩＤは、所属テーブルでは、主キーとなっている。すなわち、社員テーブルのＤＥＰＩＤは、外部キーである。また、所属テーブルのデータは、キャッシュリポジトリ１３に保存される上述の予め定められた所定のデータであるとする。
【００９７】
図９は、第３の実施形態の情報処理システム１００の部分復旧直後のデータの一例を説明するための図である。データ１６０は、障害発生直前のスナップショットリポジトリ１２のデータである。データ１６０は、データ１６１、及びデータ１６２を含む。データ１６１は、障害発生直前の社員テーブルのデータである。データ１６２は、障害発生直前の所属テーブルのデータである。
【００９８】
データ１８０は、障害発生直前のデータリポジトリ２３のデータである。データ１８０は、データ１８１、及びデータ１８２を含む。データ１８１は、障害発生直前の社員テーブルのデータである。データ１８２は、障害発生直前の所属テーブルのデータである。
【００９９】
データ２００は、障害発生直前のキャッシュリポジトリ１３のデータである。データ２００は、データ２０１、及びデータ２０２を含む。データ２０１は、障害発生直前の社員テーブルのデータである。データ２０２は、障害発生直前の所属テーブルのデータである。
【０１００】
図９の障害発生直前のデータの例では、データリポジトリ２３の（ＩＤ，ＮＡＭＥ，ＤＥＰＩＤ）＝（２，Ｎａｍｅ０３，２）のデータが、スナップショット取得後に更新されている（ＤＥＰＩＤが、１から２に更新されている）。また、（ＩＤ，ＮＡＭＥ，ＤＥＰＩＤ）＝（３，Ｎａｍｅ０４，２）のデータが、スナップショット取得後に、データリポジトリ２３に登録されている。
【０１０１】
そのため、キャッシュリポジトリ１３には、データ２０１（（ＩＤ，ＮＡＭＥ，ＤＥＰＩＤ）＝（２，Ｎａｍｅ０３，２），（３，Ｎａｍｅ０４，２））が記憶されている。また、所属テーブルに記憶されている全てのデータであるデータ２０２（（ＤＥＰＩＤ，ＤＥＰＴ＿ＮＡＭＥ）＝（０，Ｓａｌｅｓ），（１，Ｄｅｖｅｌｏｐ），（２，Ｍａｎａｇｅｍｅｎｔ））については、データリポジトリ２３のデータ１８２へのアクセス有無によらずに記憶される。
【０１０２】
すなわち、本実施形態のキャッシュリポジトリ１３は、スナップショット取得後にアクセスされたデータリポジトリ２３のデータと、予め定められた所定のデータである所属テーブルの全データとを記憶する。
【０１０３】
データ１６３は、部分復旧直後のスナップショットリポジトリ１２のデータである。データ１６３は、データ１６４、及びデータ１６５を含む。データ１６４は、部分復旧直後の社員テーブルのデータである。データ１６５は、部分復旧直後の所属テーブルのデータである。
【０１０４】
データ１８３は、部分復旧直後のデータリポジトリ２３のデータである。データ１８３は、データ１８４、及びデータ１８５を含む。データ１８４は、部分復旧直後の社員テーブルのデータである。データ１８５は、部分復旧直後の所属テーブルのデータである。
【０１０５】
データ２０３は、部分復旧直後のキャッシュリポジトリ１３のデータである。データ２０３は、データ２０４、及びデータ２０５を含む。データ２０４は、部分復旧直後の社員テーブルのデータである。データ２０５は、部分復旧直後の所属テーブルのデータである。
【０１０６】
図９の部分復旧直後のデータの例では、データリポジトリ２３のデータ１８４（（ＩＤ，ＮＡＭＥ，ＤＥＰＩＤ）＝（２，Ｎａｍｅ０３，２），（３，Ｎａｍｅ０４，２））が障害発生直前のキャッシュリポジトリ１３のデータ２０１から復旧されている。また、データリポジトリ２３のデータ１８５（（ＤＥＰＩＤ，ＤＥＰＴ＿ＮＡＭＥ）＝（０，Ｓａｌｅｓ），（１，Ｄｅｖｅｌｏｐ），（２，Ｍａｎａｇｅｍｅｎｔ））が、障害発生直前のキャッシュリポジトリ１３のデータ２０２から復旧されている。
【０１０７】
データリポジトリ２３が部分復旧された後、キャッシュリポジトリ１３のデータ２０１は、キャッシュ制御部５により削除される。しかし、予め定められたデータである所属テーブルのデータであるデータ２０２は、キャッシュ制御部５により削除されない。
【０１０８】
図１０は、第３の実施形態の情報処理システム１００の完全復旧直後のデータの一例を説明するための図である。データ１６６は、部分復旧状態のスナップショットリポジトリ１２のデータである。データ１６６は、データ１６７、及びデータ１６８を含む。データ１６７は、部分復旧状態の社員テーブルのデータである。データ１６８は、部分復旧状態の所属テーブルのデータである。
【０１０９】
データ１８６は、部分復旧状態のデータリポジトリ２３のデータである。データ１８６は、データ１８７、及びデータ１８８を含む。データ１８７は、部分復旧状態の社員テーブルのデータである。データ１８８は、部分復旧状態の所属テーブルのデータである。
【０１１０】
データ２０６は、部分復旧状態のキャッシュリポジトリ１３のデータである。データ２０６は、データ２０７、及びデータ２０８を含む。データ２０７は、部分復旧状態の社員テーブルのデータである。データ２０８は、部分復旧状態の所属テーブルのデータである。
【０１１１】
図１０の部分復旧状態のデータの例では、データリポジトリ２３の（ＩＤ，ＮＡＭＥ，ＤＥＰＩＤ）＝（３，Ｎａｍｅ１０，０）のデータが、部分復旧状態のときに、更新されている（ＮＡＭＥが、Ｎａｍｅ０４からＮａｍｅ１０に更新されている。また、ＤＥＰＩＤが、２から０に更新されている。）。そのため、（ＩＤ，ＮＡＭＥ，ＤＥＰＩＤ）＝（３，Ｎａｍｅ１０，０）のデータが、キャッシュリポジトリ１３に登録されている。また、キャッシュリポジトリ１３には、所属テーブルのデータ２０８（図９のデータ２０２と同一）が記憶されている。
【０１１２】
すなわち、本実施形態のキャッシュリポジトリ１３は、部分復旧状態のときにアクセスされたデータリポジトリ２３のデータを記憶し、所属テーブルのデータ２０８（図９のデータ２０２と同一）は、ユーザによるアクセス有無に関係なく、常に記憶されている。
【０１１３】
データ１６９は、完全復旧直後のスナップショットリポジトリ１２のデータである。データ１６９は、データ１７０、及びデータ１７１を含む。データ１７０は、完全復旧直後の社員テーブルのデータである。データ１７１は、完全復旧直後の所属テーブルのデータである。
【０１１４】
データ１８９は、完全復旧直後のデータリポジトリ２３のデータである。データ１８９は、データ１９０、及びデータ１９１を含む。データ１９０は、完全復旧直後の社員テーブルのデータである。データ１９１は、完全復旧直後の所属テーブルのデータである。
【０１１５】
データ２０９は、完全復旧直後のキャッシュリポジトリ１３のデータである。データ２０９は、データ２１０、及びデータ２１１を含む。データ２１０は、完全復旧直後の社員テーブルのデータである。データ２１１は、完全復旧直後の所属テーブルのデータである。
【０１１６】
図１０の完全復旧直後のデータの例では、データリポジトリ２３のデータ１９０のうち、（ＩＤ，ＮＡＭＥ，ＤＥＰＩＤ）＝（０，Ｎａｍｅ０１，０），（１，Ｎａｍｅ０２，１）が、スナップショットリポジトリ１２のデータ１６７を使用して、復元されている。また、データリポジトリ２３のデータ１９１は、データ１８８と同一である。
【０１１７】
なお、復元部４は、（ＩＤ，ＮＡＭＥ，ＤＥＰＩＤ）＝（２，Ｎａｍｅ０３，２）は、既に、障害発生直前のキャッシュリポジトリ１３のデータ２０１（図９）から復元されているため、ＤＥＰＩＤを１で上書きしない。
【０１１８】
次に、部分復旧状態における本実施形態のアクセス待機判定方法について説明する。図１１は、第３の実施形態の情報処理システム１００の部分復旧時のアクセス待機判定方法の一例を説明するためのフローチャートである。
【０１１９】
アクセス待機部６は、業務システム２２からデータリポジトリ２３へのアクセスが、予め定められた所定のデータへのアクセスであるか否かを判定する（ステップＳ４０）。所定のデータへのアクセスである場合（ステップＳ４０、Ｙｅｓ）は、ステップＳ４６に進む。所定のデータへのアクセスでない場合（ステップＳ４０、Ｎｏ）は、ステップＳ４１に進む。
【０１２０】
ステップＳ４１からステップＳ５０までの、アクセス待機判定処理は、第２の実施形態にかかる情報処理システム１００におけるステップＳ１１からステップＳ２０までと同様の処理なので、その説明を省略する。
【０１２１】
上述のアクセス待機判定方法によれば、部分復旧状態におけるＲＤＢ方式のデータリポジトリ２３へのアクセスで、待機させない操作は、以下の（１）〜（８）の場合である。
【０１２２】
（１）所定のデータを参照する。（２）所定のデータでないデータを、ＲＤＢに登録されている場合に、主キーを指定して参照する。（３）所定のデータの外部キーとして利用されないカラムを更新する。（４）所定のデータでないデータの外部キーとして利用されないカラムを、ＲＤＢに登録されている場合に、主キーを指定して更新する。（５）所定のデータが、外部キーとして利用されるカラムが存在しないテーブルに記憶されている場合に、削除する。（６）所定のデータでないデータが、外部キーとして利用されるカラムが存在しないテーブルに記憶されている場合に、主キーを指定して削除する。（７）所定のデータを登録する（所定のテーブルに所定のデータを登録する）。（８）業務システム２２により適切な主キーが発行された所定のデータでないデータを登録する。
【０１２３】
本実施形態の情報処理システム１００によれば、仮想マシン２１に障害が発生しても、仮想マシン２１を迅速に部分復旧すること、及び上述のアクセス待機判定方法により、ユーザによって直近に利用されていたＲＤＢ方式のデータリポジトリ２３のデータに関する操作の継続可能性が保障される。
【０１２４】
また、本実施形態の情報処理システム１００によれば、仮想マシン２１が、部分復旧状態であっても、ＲＤＢ方式のデータリポジトリ２３のデータの整合性が保たれる操作は、当該操作を待機させずに完了させることができる。
【０１２５】
また、本実施形態の情報処理システム１００によれば、ユーザによるアクセスの有無によらずに、予め所定のデータを登録しておくことにより、仮想マシン２１により実現されるテナントシステムの部分復旧範囲を広げることができる。
【０１２６】
次に、第１、２及び３の実施形態の情報処理システム１００の変形例について説明する。図１２は、第１、２及び３の実施形態の情報処理システム１００の構成の変形例１を説明するための図である。
【０１２７】
図１２は、第１、２及び３の実施形態の情報処理システム１００のキャッシュ制御部５及びアクセス待機部６を、仮想マシン２１上で実現した場合の例である。本変形例のように、キャッシュ制御部５及びアクセス待機部６は、仮想マシン２１上で実現してもよい。
【０１２８】
図１３は、第１、２及び３の実施形態の情報処理システム１００の構成の変形例２を説明するための図である。図１３では、業務システム２２を、仮想マシン２１により実現している。また、データリポジトリ２３を、仮想マシン２４により実現している。本変形例のように、障害復旧システム１の障害復旧対象となるテナントシステムは、業務システム２２と、データリポジトリ２３とを、異なる仮想マシンにより実現していてもよい。
【０１２９】
障害復旧システム１は、業務システム２２（仮想マシン２１）及びデータリポジトリ２３（仮想マシン２４）のいずれか一方に障害が発生した場合は、障害が発生した仮想マシンのみを復旧させる。
【０１３０】
図１４は、第１、２及び３の実施形態の情報処理システム１００の構成の変形例３を説明するための図である。図１４は、障害復旧システム１の障害復旧対象となるテナントシステム（仮想マシン２１及び仮想マシン４１）が、負荷分散や、障害耐性を向上させるために並列稼動している場合の例である。
【０１３１】
なお、仮想マシン２１の業務システム２２にアクセスするクライアント装置３１、及び仮想マシン４１の業務システム４２にアクセスするクライアント装置５１は、同一の装置であってもよい。
【０１３２】
図１４の変形例３の障害復旧システム１は、第１、２及び３の実施形態の障害復旧システム１の構成から更に、キャッシュ制御部７、アクセス待機部８、データリポジトリ同期部９、キャッシュ同期部１０、及びキャッシュリポジトリ１４を備える。
【０１３３】
キャッシュ制御部７、及びアクセス待機部８は、業務システム４２とデータリポジトリ４３との間に存在し、プロキシとして動作する。すなわち、業務システム４２が、データリポジトリ４３の業務データにアクセスする場合は、キャッシュ制御部７、及びアクセス待機部８を介してアクセスする。キャッシュ制御部７、及びアクセス待機部８の動作は、キャッシュ制御部５、及びアクセス待機部６と同様であるため、説明を省略する。
【０１３４】
キャッシュリポジトリ１４は、仮想マシン４１のデータリポジトリ４３の業務データの一部を表すキャッシュデータを記憶する。
【０１３５】
データリポジトリ同期部９は、データリポジトリ２３、及びデータリポジトリ４３のデータの状態を、常に同じ状態に保つために、データを同期する。
【０１３６】
仮想マシン２１、及び仮想マシン４１が、負荷分散を目的にして稼動している場合は、いずれか一方の仮想マシンのデータリポジトリのデータが変更されると、データリポジトリ同期部９は、他方の仮想マシンのデータリポジトリのデータにも変更を反映する。仮想マシン２１、及び仮想マシン４１が、障害耐性を向上させるために稼動している場合は、データリポジトリ同期部９は、データリポジトリ２３、及びデータリポジトリ４３のデータが一致しているかどうかを常に監視する。
【０１３７】
また、いずれか一方の仮想マシンが、障害復旧中（部分復旧から完全復旧までの間）である場合は、データリポジトリ同期部９は、正常稼働中の他方の仮想マシンで変更されたデータリポジトリのデータを、障害復旧中の仮想マシンのデータリポジトリに反映する。
【０１３８】
なお、データリポジトリ同期部９が、障害復旧中の仮想マシンのデータリポジトリにデータを反映させても、復元部４は、当該データリポジトリに既に登録されているデータについては上書きしないため、完全復旧後のデータの整合性は損なわれない。
【０１３９】
キャッシュ同期部１０は、キャッシュリポジトリ１３、及びキャッシュリポジトリ１４のデータの状態を、常に同じ状態に保つために、データを同期する。キャッシュ同期部１０は、いずれか一方のキャッシュリポジトリに変更があった場合に、他方のキャッシュリポジトリにも当該変更を反映させる。
【０１４０】
なお、図１４の変形例３では、２つの仮想マシン（仮想マシン２１、及び仮想マシン４１）を障害復旧の対象としている。しかしながら、障害復旧の対象となる仮想マシンは、負荷分散等の目的により３つ以上並列稼動している場合でもよい。３つ以上の仮想マシンを並列稼動させる場合についても、仮想マシンを部分復旧させる方法は同様である。すなわち、仮想マシン毎に、キャッシュリポジトリを用意して、仮想マシンを部分復旧することができる。
【０１４１】
なお、キャッシュ制御部５（７）とアクセス待機部６（８）は、各仮想マシン上で実現してもよいし、障害復旧システム１上で実現されたキャッシュ制御部５及びアクセス待機部６を共有してもよい。
【０１４２】
また、本実施形態の仮想マシン構築部３、復元部４、データリポジトリ同期部９、及びキャッシュ同期部１０は、ソフトウェアにより実現してもよいし、ＩＣ等のハードウェアにより実現してもよい。または、ソフトウェア及びハードウェアの両方により実現してもよい。
【０１４３】
図１４の変形例３の情報処理システム１００によれば、キャッシュ同期部１０が、複数のキャッシュリポジトリのデータを同期するため、複数の仮想マシンが並列稼動している場合であっても、複数のキャッシュリポジトリ間におけるデータの不一致を生じさせることなく仮想マシンを部分復旧することができる。
【０１４４】
上述のいずれか１つの実施形態の情報処理システム１００によれば、仮想マシン構築部３が、新規に構築した仮想マシン２１（２４、４１）に、業務システム２２（４２）、及び空のデータリポジトリ２３（４３）を作成し、キャッシュ制御部５（７）が、キャッシュデータを使用して、データリポジトリ２３（４３）を部分的に復旧する。これにより、ユーザの仮想マシン２１（２４、４１）を、迅速に部分復旧することができる。
【０１４５】
また、上述のいずれか１つの実施形態の情報処理システム１００によれば、仮想マシン２１（２４、４１）に障害が発生しても、迅速に部分復旧すること、及び上述のアクセス待機判定方法により、ユーザによって直近に利用されていたデータリポジトリ２３（４３）のデータに関する操作の継続可能性が保障される。
【０１４６】
また、上述のいずれか１つの実施形態の情報処理システム１００によれば、ユーザの仮想マシン２１（２４、４１）が、部分復旧状態であっても、データリポジトリ２３（４３）のデータの整合性が保たれる操作は、当該操作を待機させずに完了させることができる。
【０１４７】
図１５は、第１、２及び３の実施形態の障害復旧システム１、並びに仮想マシン２１（２４、４１）が動作する情報処理装置のハードウェア構成の一例を示す図である。
【０１４８】
上述の実施形態の障害復旧システム１は、ＣＰＵやＩＣなどの制御部９１と、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）９２やＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）９３等の主記憶装置と、ネットワークに接続するための通信Ｉ／Ｆ９４と、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）９５や光学ドライブ９６等の外部記憶装置を備えている。制御部９１、ＲＯＭ９２、ＲＡＭ９３、通信Ｉ／Ｆ９４、ＨＤＤ９５、及び光学ドライブ９６は、バス９７を介して、接続されている。
【０１４９】
例えば、上述の実施形態の記憶部２は、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）９５や光学ドライブ９６等の外部記憶装置に相当する。また、上述の実施形態の仮想マシン構築部３、復元部４、キャッシュ制御部５（７）、アクセス待機部６（８）、データリポジトリ同期部９、及びキャッシュ同期部１０は、制御部９１に相当する。
【０１５０】
なお、仮想マシン２１（２４、４１）、及び障害復旧システム１は、同一のハードウェアにより実現してもよいし、異なるハードウェアにより実現してもよい。
【０１５１】
上述の実施形態の障害復旧システム１で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｋ）等のコンピュータで読み取り可能な記録媒体に記録されてコンピュータ・プログラム・プロダクトとして提供される。
【０１５２】
また、上述の実施形態の障害復旧システム１で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、上述の実施の形態の障害復旧システム１で実行されるプログラムをインターネット等のネットワーク経由で提供又は配布するように構成してもよい。
【０１５３】
また、上述の実施形態の障害復旧システム１のプログラムを、ＲＯＭ９２等に予め組み込んで提供するように構成してもよい。
【０１５４】
上述の実施形態の障害復旧システム１で実行されるプログラムは、上述した各部（仮想マシン構築部３、復元部４、キャッシュ制御部５（７）、アクセス待機部６（８）、データリポジトリ同期部９、及びキャッシュ同期部１０）を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵが上記記憶媒体からプログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、仮想マシン構築部３、復元部４、キャッシュ制御部５（７）、アクセス待機部６（８）、データリポジトリ同期部９、及びキャッシュ同期部１０が主記憶装置上に生成されるようになっている。なお、上記各部の一部又は全部をプログラムにより実現せず、ＩＣ等のハードウェアにより実現する場合は、この限りではない。
【０１５５】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【０１５６】
１  障害復旧システム
２  記憶部
３  仮想マシン構築部
４  復元部
５  キャッシュ制御部
６  アクセス待機部
７  キャッシュ制御部
８  アクセス待機部
９  データリポジトリ同期部
１０  キャッシュ同期部
１１  インストールイメージ
１２  スナップショットリポジトリ
１３  キャッシュリポジトリ
１４  キャッシュリポジトリ
２１  仮想マシン
２２  業務システム
２３  データリポジトリ
２４  仮想マシン
３１  クライアント装置
４１  仮想マシン
４２  業務システム
４３  データリポジトリ
５１  クライアント装置
９１  制御部
９２  ＲＯＭ
９３  ＲＡＭ
９４  通信Ｉ／Ｆ
９５  ＨＤＤ
９６  光学ドライブ
９７  バス
１００  情報処理システム
【図１】
2014049691.tif 000003
【図２】
2014049691.tif 000004
【図３】
2014049691.tif 000005
【図４】
2014049691.tif 000006
【図５】
2014049691.tif 000007
【図６】
2014049691.tif 000008
【図７】
2014049691.tif 000009
【図８】
2014049691.tif 000010
【図９】
2014049691.tif 000011
【図１０】
2014049691.tif 000012
【図１１】
2014049691.tif 000013
【図１２】
2014049691.tif 000014
【図１３】
2014049691.tif 000015
【図１４】
2014049691.tif 000016
【図１５】
2014049691.tif 000017
【手続補正書】
【提出日】平成25年6月13日(2013.6.13)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
仮想マシンにより実現されるユーザシステムのインストール情報と、前記ユーザシステムのデータのバックアップデータと、前記ユーザシステムのデータの一部を表すキャッシュデータを記憶する記憶部と、
前記インストール情報により前記仮想マシンを構築する仮想マシン構築部と、
前記バックアップデータにより前記ユーザシステムのデータを復元する復元部と、
前記ユーザシステムのデータの一部を、前記キャッシュデータに複製し、前記ユーザシステムの障害時に、前記キャッシュデータから前記ユーザシステムのデータの一部を復元することにより、前記ユーザシステムを部分復旧させるキャッシュ制御部と、
前記部分復旧後、前記キャッシュデータにより復元されていない前記ユーザシステムのデータを、前記バックアップデータによって復元することにより、前記ユーザシステムを完全復旧させるまでの間は、整合性が保障されない前記ユーザシステムのデータへのアクセスを待機させるアクセス待機部と
を備える情報処理システム。
【請求項２】
前記ユーザシステムのデータの一部は、前記ユーザシステムからアクセスされたデータである
請求項１に記載の情報処理システム。
【請求項３】
前記キャッシュ制御部は、
前記バックアップデータが取得された後に、前記ユーザシステムからアクセスされたデータを、前記キャッシュデータに複製する
請求項２に記載の情報処理システム。
【請求項４】
前記キャッシュ制御部は、
前記バックアップデータが前記記憶部に記憶されたときに、前記キャッシュデータを削除する
請求項２又は３に記載の情報処理システム。
【請求項５】
前記ユーザシステムのデータの一部は、前記ユーザシステムからアクセスされたか否かによらない予め定められた所定のデータである
請求項１に記載の情報処理システム。
【請求項６】
前記アクセス待機部は、
前記ユーザシステムのデータへのアクセスを待機させるときに、復元される前記ユーザシステムのデータのデータ量に基づいて、前記完全復旧にかかる時間を算出し、前記時間が所定の閾値を超える場合には、前記ユーザシステムのデータへのアクセスを待機させずにエラーを返却する
請求項１乃至５のいずれか１項に記載の情報処理システム。
【手続補正２】
【補正対象書類名】図面
【補正対象項目名】図３
【補正方法】変更
【補正の内容】
【図３】
2014049691.tif 000018
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】図４
【補正方法】変更
【補正の内容】
【図４】
2014049691.tif 000019
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００３８
【補正方法】変更
【補正の内容】
【００３８】
図４の完全復旧直後のデータの例では、データリポジトリ２３のデータ７３のうち、（ＫＥＹ，ＶＡＬＵＥ）＝（ＦＦＦ０，ＶＡＬＵＥ０），（ＦＦＦ１，ＶＡＬＵＥ１）が、スナップショットリポジトリ１２のデータ６２を使用して、復元されている。なお、復元部４は、（ＫＥＹ，ＶＡＬＵＥ）＝（ＦＦＦ２，ＶＡＬＵＥ２）は、既に、障害発生直前のキャッシュリポジトリ１３のデータ８０（図３）から復元されているため、ＫＥＹ＝ＦＦＦ２のＶＡＬＵＥをＶＡＬＵＥ２で上書きしない。
【国際調査報告】
2014049691.tif 000020
2014049691.tif 000021
2014049691.tif 000022
2014049691.tif 000023