(57)【要約】      （修正有）【課題】データをローカルおよび／またはクラウドのサーバーでフレキシブルに管理して、サーバーやネットワークの障害時にも継続的かつ最適に使用できるようにするデータ管理システム及び方法を提供する。【解決手段】クラウドの管理サーバーとバックアップサーバーと仮想サーバーと、ローカルの主サーバーとローカルの端末とがネットワークで接続され、ローカルの主サーバーのデータをクラウドのバックアップサーバーにバックアップし、ローカルの主サーバーに障害が発生した場合にクラウドのバックアップサーバーのバックアップデータを使用して、クラウドの仮想サーバーにローカルの主サーバーのデータを復元し、クラウドの仮想サーバーを一時的な主サーバーとしてシステム利用を継続させ、リストア後にローカルの端末からクラウドの仮想サーバーにアクセスするアクセス方式を通常運用時のリモート接続方式に替えてファイル転送方式に切替える。【選択図】図１−１
2017182380.tif 000002
【特許請求の範囲】
【請求項１】
各サーバーの役割を規定する管理情報を保持するクラウドの管理サーバーと、クラウドのバックアップサーバーと、クラウドの仮想サーバー用仮想マシンと、ローカルの実マシンの実サーバーと、１以上のローカルの端末とがネットワークで接続され、通常運用時に、前記管理サーバーの管理情報には、前記ローカルの実マシンの実サーバーを主サーバーとして運用すべく規定されているデータ管理システムであって、
前記ローカルの主サーバーのデータを、前記クラウドのバックアップサーバーにバックアップする第１のバックアップ手段と、
ローカルの主サーバーに障害が発生した場合に、前記管理サーバーの管理情報に、前記クラウドの仮想サーバー用仮想マシンから仮想サーバーを生成し、前記仮想マシンの仮想サーバーを主サーバーとしての運用させるための情報を書き込むと共に、前記クラウドのバックアップサーバーのバックアップデータを使用して、前記クラウドの仮想サーバー用仮想マシンの仮想サーバーに前記ローカルの主サーバーのデータを復元し、前記仮想マシンの仮想サーバーを一時的な主サーバーとして、システム利用を継続させる障害時リストア手段と、
リストア後に、前記１以上のローカルの端末から前記クラウドの仮想サーバー用仮想マシンの仮想サーバーにアクセスする際のアクセス方式を、前記通常運用時のリモート接続方式に替えてファイル転送方式に切替えるアクセス変更手段と、
を備え、前記ローカルの主サーバーの障害発生の際に、クラウドのバックアップサーバーを用いてシステム利用を継続させることを特徴とするデータ管理システム。
【請求項２】
請求項１に記載のデータ管理システムにおいて、さらに、
前記ローカルの主サーバーの障害が復旧したときに、システムを通常運用状態に回復させるための手段として、
前記管理サーバーの管理情報に基づいて、データ復旧先として利用可能なサーバーとして、前記障害が発生したローカルの実サーバーを修理した実サーバー、ローカル又はクラウドの別の実サーバー、およびローカル又はクラウドの仮想サーバーの中から、データ復旧先のサーバーを選択するための復旧先サーバー選択手段と、
前記一時的な主サーバーとして運用していたクラウドの仮想サーバーのデータの更新内容を、前記バックアップサーバーにバックアップする手段と、
前記バックアップサーバーのバックアップデータを、前記復旧先として選択したサーバーにリストアするとともに、当該リストア後に、前記管理サーバーの管理情報に、主サーバーを、前記一時的な主サーバーとして運用していたクラウドの仮想サーバーから、前記復旧先として選択したサーバーに切り換えるための情報を書き込み、システムを通常運用状態に復旧させる復旧時リストア手段と、を備えることを特徴とするデータ管理システム。
【請求項３】
請求項１又は２に記載のデータ管理システムにおいて、
前記クラウドの管理サーバーとして仮想的に構築された管理サーバーを用い、
前記クラウドのバックアップサーバーとして仮想的に構築されたバックアップサーバーを用い、
前記ローカルの実マシンの実サーバーに替えて仮想的に構築されたサーバーを用いて、
運用することを特徴とするデータ管理システム。
【請求項４】
クラウドの仮想マシンの仮想サーバーと、各サーバーの役割を規定する管理情報を保持するクラウドの管理サーバーと、ローカルの実マシンの実サーバーと、１以上のローカルの端末とがネットワークで接続され、
通常運用時に、前記管理サーバーの管理情報には、前記クラウドの仮想マシンの仮想サーバーを主サーバーとし、前記ローカルの実マシンの実サーバーをキャッシュサーバーとして運用すべく規定されているデータ管理システムであって、
前記ローカルのキャッシュサーバーが、
前記クラウドの主サーバーのデータおよび前記管理サーバーの管理情報を当該キャッシュサーバーにキャッシュして前記１以上のローカルの端末に利用させるキャッシュ手段と、
前記ネットワークの通信障害又は前記仮想マシンの主サーバーに障害が発生した場合に、前記ローカルのキャッシュサーバーのデータを元に、当該ローカルのキャッシュサーバー上に、前記管理サーバーの管理情報と、前記クラウドの仮想サーバーの元本データの少なくとも一部を復元して、元本の部分的なコピーデータとすることにより、そのままでは直接操作できない当該元本の部分的なキャッシュデータを、直接操作できる元本データの部分的なコピーデータとして取り扱い、一時的に、前記ローカルのキャッシュサーバーを一時的な主サーバーとして運用すべく前記管理情報を書き換えるリカバリ手段と、
を備え、通信障害、またはクラウドの仮想マシン内の主サーバーの障害発生時にシステム利用を継続させることを特徴とするデータ管理システム。
【請求項５】
請求項４に記載のデータ管理システムにおいて、さらに、
前記ネットワークの通信障害又は前記仮想マシンの主サーバーの障害が回復した場合に、前記一時的な主サーバーとして運用していた前記ローカルのキャッシュサーバーのデータの更新内容を、前記クラウドの仮想マシンの仮想サーバーに反映させる障害復旧処理手段を備えることを特徴とするデータ管理システム。
【請求項６】
各サーバーの役割を規定する管理情報を保持する管理サーバーと、クラウドの仮想マシンの仮想サーバーと、ローカルの実マシンの実サーバーと、１以上のローカルの端末とがネットワークで接続され、
前記管理サーバーの管理情報には、請求項１乃至３のいずれかに記載のデータ管理システムの構成を第１の運用形態とし、請求項４または５に記載のデータ管理システムの構成を第２の運用形態として登録されており、
前記主サーバーに接続する前記ローカルの端末数を含む条件および／または予め規定された運用ポリシーに基づいて、前記管理情報の内容を、前記第１の運用形態と第２の運用形態とで相互に切替える運用形態切替手段を備えることを特徴とするデータ管理システム。
【請求項７】
各サーバーの役割を規定する管理情報を保持する管理サーバーと、クラウドの仮想マシンの仮想サーバーと、ローカルの実マシンの実サーバーと、１以上のローカルの端末とがネットワークで接続され、
前記管理サーバーの管理情報には、前記クラウドの仮想マシンの仮想サーバーと前記ローカルの実マシンの実サーバーのうち、いずれか一方をマスターサーバー、他方をスレーブサーバーとして、サーバー２台構成で運用する通常運用形態と、
請求項４または５に記載のデータ管理システムの構成が第２の運用形態として登録されており、
前記ローカルの端末の負荷や、前記ネットワークの通信速度を含む環境条件に基づいて、前記通常運用形態から前記第２の運用形態に切り替える運用形態切替手段を備えることを特徴とするデータ管理システム。
【請求項８】
各サーバーの役割を規定する管理情報を保持するクラウドの管理サーバーと、クラウドのバックアップサーバーと、クラウドの仮想サーバー用仮想マシンと、ローカルの実マシンの実サーバーと、１以上のローカルの端末とがネットワークで接続されたデータ管理システムの運用方法において、
通常運用時に、前記管理サーバーが、前記ローカルの実マシンの実サーバーを主サーバーとして運用するよう前記管理情報を設定し、
前記クラウドのバックアップサーバーが、前記ローカルの主サーバーのバックアップを保存し、
ローカルの主サーバーに障害が発生した場合に、
前記管理サーバーが、前記クラウドの仮想サーバー用仮想マシンから仮想サーバーを生成し、前記仮想マシンの仮想サーバーを主サーバーとしての運用させるための情報を前記管理情報に書き込むと共に、前記クラウドのバックアップサーバーのバックアップデータを使用して、前記クラウドの仮想サーバー用仮想マシンの仮想サーバーに前記ローカルの主サーバーのデータをリストアし、前記仮想マシンの仮想サーバーを一時的な主サーバーとして、システム利用を継続させ、
リストア後に、前記１以上のローカルの端末から前記クラウドの仮想サーバー用仮想マシンの仮想サーバーにアクセスする際のアクセス方式を、前記通常運用時のリモート接続方式に替えてファイル転送方式に切替えて、
前記ローカルの主サーバーの障害発生の際に、クラウドのバックアップサーバーを用いてシステム利用を継続させることを特徴とするデータ管理システムの運用方法。
【請求項９】
請求項８に記載の方法において、さらに、
前記ローカルの主サーバーの障害が復旧したときに、
前記管理サーバーが、前記管理情報に基づいて、前記障害が発生したローカルの実サーバーを修理した実サーバー、ローカル又はクラウドの別の実サーバー、およびローカル又はクラウドの仮想サーバーの中から、データ復旧先のサーバーを選択し、
前記バックアップサーバーが、前記一時的な主サーバーとして運用していたクラウドの仮想サーバーのデータの更新内容をバックアップし、
前記バックアップサーバーのバックアップデータを、前記復旧先として選択したサーバーにリストアするとともに、当該リストア後に、前記管理サーバーが管理情報に、主サーバーを、前記一時的な主サーバーとして運用していたクラウドの仮想サーバーから、前記復旧先として選択したサーバーに切り換えるよう前記管理情報を更新し、システムを通常運用状態に復旧させることを特徴とするデータ管理システムの運用方法。
【請求項１０】
請求項９又は１０に記載の方法において、
前記クラウドの管理サーバーとして仮想的に構築された管理サーバーを用い、
前記クラウドのバックアップサーバーとして仮想的に構築されたバックアップサーバーを用い、
前記ローカルの実マシンの実サーバーに替えて仮想的に構築されたサーバーを用いて、
運用することを特徴とするデータ管理システムの運用方法。
【請求項１１】
クラウドの仮想マシンの仮想サーバーと、各サーバーの役割を規定する管理情報を保持するクラウドの管理サーバーと、ローカルの実マシンの実サーバーと、１以上のローカルの端末とがネットワークで接続されたデータ管理システムの運用方法において、
通常運用時に、前記管理サーバーが、前記クラウドの仮想マシンの仮想サーバーを主サーバーとし、前記ローカルの実マシンの実サーバーをキャッシュサーバーとして運用するよう前記管理情報を設定し、
前記ローカルのキャッシュサーバーが、前記クラウドの主サーバーのデータおよび前記管理サーバーの管理情報を当該キャッシュサーバーにキャッシュして前記１以上のローカルの端末に利用させ、
前記ネットワークの通信障害又は前記仮想マシンの主サーバーに障害が発生した場合に、前記キャッシュサーバーが、前記ローカルのキャッシュサーバーのデータを元に、当該ローカルのキャッシュサーバー上に、前記管理サーバーの管理情報と、前記クラウドの仮想サーバーの元本データの少なくとも一部を復元して、元本の部分的なコピーデータとすることにより、そのままでは直接操作できない当該元本の部分的なキャッシュデータを、直接操作できる元本データの部分的なコピーデータとして取り扱い、一時的に、前記ローカルのキャッシュサーバーを一時的な主サーバーとして運用すべく前記管理情報を書き換えることを特徴とするデータ管理システムの運用方法。
【請求項１２】
請求項１２に記載の方法において、さらに、
前記ネットワークの通信障害又は前記仮想マシンの主サーバーの障害が回復した場合に、前記ローカルのキャッシュサーバーが、前記一時的な主サーバーとして運用していた前記ローカルのキャッシュサーバーのデータの更新内容を、前記クラウドの仮想マシンの仮想サーバーに反映させることを特徴とするデータ管理システムの運用方法。
【請求項１３】
各サーバーの役割を規定する管理情報を保持する管理サーバーと、クラウドの仮想マシンの仮想サーバーと、ローカルの実マシンの実サーバーと、１以上のローカルの端末とがネットワークで接続されたデータ管理システムの運用方法において、
前記管理サーバーの管理情報には、請求項８乃至１０のいずれかに記載の運用方法を第１の運用形態とし、請求項１１または１２に記載の運用方法を第２の運用形態として登録されており、
前記管理サーバーが、前記主サーバーに接続する前記ローカルの端末数を含む条件および／または予め規定された運用ポリシーに基づいて、前記管理情報の内容を、前記第１の運用形態と第２の運用形態とで相互に切替えることを特徴とするデータ管理システムの運用方法。
【請求項１４】
各サーバーの役割を規定する管理情報を保持する管理サーバーと、クラウドの仮想マシンの仮想サーバーと、ローカルの実マシンの実サーバーと、１以上のローカルの端末とがネットワークで接続されたデータ管理システムの運用方法において、
前記管理サーバーの管理情報には、前記クラウドの仮想マシンの仮想サーバーと前記ローカルの実マシンの実サーバーのうち、いずれか一方をマスターサーバー、他方をスレーブサーバーとして、サーバー２台構成で運用する通常運用形態と、
請求項１１または１２に記載のデータ管理システムの運用方法が第２の運用形態として登録されており、
前記管理サーバーが、前記ローカルの端末の負荷や、前記ネットワークの通信速度を含む環境条件に基づいて、前記通常運用形態から前記第２の運用形態に切り替えることを特徴とするデータ管理システムの運用方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ管理システムおよび方法に関し、特に、アプリケーションデータをローカルおよび／またはクラウドのサーバーでフレキシブルに管理して、サーバーやネットワークの障害時にも継続的に使用できるようにしたデータ管理システムおよび方法に関する。
【背景技術】
【０００２】
従来より、例えばローカルのファイルサーバーのデータのバックアップをとり、データの破損時などに交換用または修理したサーバーに復旧することが行われている。例えば、特許文献１には、クラウド上の仮想マシンのバックアップサーバーにネットワーク経由でバックアップデータを保存することが記載されている。特許文献２には、ローカルのファイルサーバーが修理できなかった場合や、同じハードウェア構成の交換用サーバーがない場合に、ローカルの別の実マシンやクラウド上の仮想マシン内に仮想技術を利用して仮想サーバーを立ち上げ、そこにバックアップデータをリストアしてシステム運用を継続することが提案されている。
【０００３】
ところが、仮想サーバーがローカルの実マシン上に構築された場合、復旧後のパフォーマンスは実マシンの性能に依存するため、高パフォーマンスを求めると高スペックの実マシンが必要となり、費用のかかるものであった（特許文献３）。また、仮想サーバーがクラウドの仮想マシン上に構築された場合は、パフォーマンスがネットワークの状態に依存するため、ローカル端末での処理の応答時間が長くなり業務に支障が出ることがあった。
【０００４】
クラウド上の仮想マシンの仮想サーバーのデータを利用する場合に、ネットワークの状態によってパフォーマンスが左右される問題を改善すべく、キャッシュサーバーを設置して処理の高速化を図ったり、ローカルにスレーブサーバーを設置して処理能力の強化を行ったりすることがある（例えば、特許文献４、５）。
【０００５】
しかしながら、クラウド上の仮想サーバーのデータの複製を蓄積するキャッシュサーバーをローカルに設置した場合は、仮想サーバーに障害が発生したり（サーバーダウン）、ネットワークに問題が生じて仮想サーバーとの接続が途絶えるとキャッシュ機能が維持できず、仮想サーバーまたはネットワークの障害が回復するまでローカルの実端末での業務を継続できなかった。また、スレーブサーバーを設置する場合、パフォーマンスがスレーブサーバーのスペックに依存することとなり、高スペックのスレーブサーバーを用意するには費用がかかるものとなる。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特許第３７６８７７５号
【特許文献２】特許第３０２２７６８号
【特許文献３】特開平４−１４１７４４号公報
【特許文献４】特許第２７０１８０６号
【特許文献５】特開昭６２−１７２３４７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
本発明が解決しようとする課題は、ローカルの実サーバー（主サーバー）のデータをクラウドの仮想サーバーにバックアップしているシステムにおいて、主サーバーに障害が生じた場合でも運用を継続できるようにするとともに、ネットワーク状態へのパフォーマンスの依存を最小限に抑えることである。
【０００８】
また、本発明のさらなる課題は、クラウド上の仮想サーバー（主サーバー）とローカルの実サーバー（小規模なハードウェアのキャッシュサーバー）を有するシステムにおいて、クラウド上の主サーバーやネットワークに障害が生じた場合でも、キャッシュサーバーを一時的な主サーバーに代替させて運用を継続できるようにし、クラウド上の主サーバーまたはネットワークが復旧したときに更新データを主サーバーに反映させて元の運用状態に戻せるようにすることである。
【０００９】
本発明のさらなる課題は、上記したクラウド上の仮想サーバー（バックアップサーバー）とローカルの主サーバーを用いた第一の運用形態と、クラウド上の仮想サーバー（主サーバー）とローカルのキャッシュサーバーを用いた第二の運用形態とを、接続人数等の条件や運用ポリシーに応じて相互に切り換えるシステムを提供することである。
【００１０】
本発明のさらなる課題は、クラウドの仮想マシンの仮想サーバーと、ローカルの実マシンの実サーバーを含むシステムにおいて、仮想サーバーと実サーバーとの一方をマスターサーバー、他方をスレーブサーバーとして運用し、仮想マシンと実マシンの負荷やパフォーマンスに応じてスレーブサーバーをキャッシュサーバーやバックアップサーバーとして運用することである。
【課題を解決するための手段】
【００１１】
上記課題を解決するために、本発明の第１の運用形態のデータ管理システムは、各サーバーの役割を規定する管理情報を保持するクラウドの管理サーバーと、クラウドのバックアップサーバーと、クラウドの仮想サーバー用仮想マシンと、ローカルの実マシンの実サーバーと、１以上のローカルの端末とがネットワークで接続され、通常運用時に、前記管理サーバーの管理情報には、前記ローカルの実マシンの実サーバーを主サーバーとして運用すべく規定されているデータ管理システムであって、
前記ローカルの主サーバーのデータを、前記クラウドのバックアップサーバーにバックアップする第１のバックアップ手段と、
ローカルの主サーバーに障害が発生した場合に、前記管理サーバーの管理情報に、前記クラウドの仮想サーバー用仮想マシンから仮想サーバーを生成し、前記仮想マシンの仮想サーバーを主サーバーとしての運用させるための情報を書き込むと共に、前記クラウドのバックアップサーバーのバックアップデータを使用して、前記クラウドの仮想サーバー用仮想マシンの仮想サーバーに前記ローカルの主サーバーのデータを復元し、前記仮想マシンの仮想サーバーを一時的な主サーバーとして、システム利用を継続させる障害時リストア手段と、
リストア後に、前記１以上のローカルの端末から前記クラウドの仮想サーバー用仮想マシンの仮想サーバーにアクセスする際のアクセス方式を、前記通常運用時のリモート接続方式に替えてファイル転送方式に切替えるアクセス変更手段と、
を備え、前記ローカルの主サーバーの障害発生の際に、クラウドのバックアップサーバーを用いてシステム利用を継続させることを特徴とする。
【００１２】
本発明の第２の運用形態のデータ管理システムは、クラウドの仮想マシンの仮想サーバーと、各サーバーの役割を規定する管理情報を保持するクラウドの管理サーバーと、ローカルの実マシンの実サーバーと、１以上のローカルの端末とがネットワークで接続され、通常運用時に、前記管理サーバーの管理情報には、前記クラウドの仮想マシンの仮想サーバーを主サーバーとし、前記ローカルの実マシンの実サーバーをキャッシュサーバーとして運用すべく規定されているデータ管理システムであって、
前記ローカルのキャッシュサーバーが、
前記クラウドの主サーバーのデータおよび前記管理サーバーの管理情報を当該キャッシュサーバーにキャッシュして前記１以上のローカルの端末に利用させるキャッシュ手段と、
前記ネットワークの通信障害又は前記仮想マシンの主サーバーに障害が発生した場合に、前記ローカルのキャッシュサーバーのデータを元に、当該ローカルのキャッシュサーバー上に、前記管理サーバーの管理情報と、前記クラウドの仮想サーバーの元本データの少なくとも一部を復元して、そのままでは直接操作できない当該元本のキャッシュデータを、直接操作できる元本データの部分的なコピーデータとして取り扱い、一時的に、前記ローカルのキャッシュサーバーを一時的な主サーバーとして運用すべく前記管理情報を書き換えるリカバリ手段と、
を備え、通信障害、またはクラウドの仮想マシン内の主サーバーの障害発生時にシステム利用を継続させることを特徴とする。
【００１３】
本発明のさらなる実施形態では、各サーバーの役割を規定する管理情報を保持する管理サーバーと、クラウドの仮想マシンの仮想サーバーと、ローカルの実マシンの実サーバーと、１以上のローカルの端末とがネットワークで接続され、
前記管理サーバーの管理情報には、上記第１の運用形態と、第２の運用形態とが運用形態として登録されており、
前記主サーバーに接続する前記ローカルの端末数を含む条件および／または予め規定された運用ポリシーに基づいて、前記管理情報の内容を、前記第１の運用形態と第２の運用形態とで相互に切替える運用形態切替手段を備えることを特徴とする。
【００１４】
本発明のさらなる実施形態では、各サーバーの役割を規定する管理情報を保持する管理サーバーと、クラウドの仮想マシンの仮想サーバーと、ローカルの実マシンの実サーバーと、１以上のローカルの端末とがネットワークで接続され、
前記管理サーバーの管理情報には、前記クラウドの仮想マシンの仮想サーバーと前記ローカルの実マシンの実サーバーのうち、いずれか一方をマスターサーバー、他方をスレーブサーバーとして、サーバー２台構成で運用する通常運用形態と、上記第２の運用形態とが登録されており、
前記ローカルの端末の負荷や、前記ネットワークの通信速度を含む環境条件に基づいて、前記通常運用形態から前記第２の運用形態に切り替える運用形態切替手段を備えることを特徴とする。
【発明の効果】
【００１５】
本願発明にかかるデータ管理システムの第１の運用形態では、ローカルの実サーバー（主サーバー）と、ローカルの１以上の端末と、クラウドのバックアップサーバーとを含むシステムにおいて、主サーバーはバックアップサーバーに定期的にバックアップを行い、主サーバーが故障したときは、クラウドの仮想サーバーにバックアップデータをリストアして、当該仮想サーバーを主サーバーに切り換えることでシステム運用を継続することができ、さらにローカルの端末が、主サーバーがローカルにある場合はＬＡＮでアクセスし、主サーバーがクラウドにある場合はファイル転送方式（Ｗｅｂ接続）に切り替えることにより、通信速度が遅い場合でも円滑に業務処理が可能となる。
【００１６】
本発明にかかるデータ管理システムの第２の運用形態では、クラウドの仮想サーバー（主サーバー）と、ローカルの実サーバー（キャッシュサーバー）と、ローカルの１以上の端末と、とを含むシステムにおいて、ローカルの端末から主サーバーへアクセスする毎にキャッシュサーバーがデータのキャッシュを蓄積し、主サーバーやネットワークに障害が生じた場合に、キャッシュサーバーを一時的に主サーバーとして利用できるようシステムを再構成することにより業務を継続することができ、クラウドの主サーバーまたはネットワークが復旧したときには障害発生中の更新データをクラウドの主サーバーに反映することにより、障害復旧後にも支障なく業務を継続することができる。
【００１７】
本発明によると、さらに主サーバーに接続するローカルの端末数などの条件、および／または予め規定された運用ポリシーに基づいて、上記の第１の運用形態と第２の運用形態とを相互に切り替えることにより、実施環境に応じて冗長性をもたせた最適なデータ管理方法が可能となる。
【００１８】
本発明によると、クラウドの仮想サーバーとローカルの実サーバーのうち、一方をマスターサーバー、他方をスレーブサーバーとして運用する通常運用形態と、上記の第２の運用形態とを、ローカルの端末やネットワークの負荷を含む環境条件に応じて切り替えることにより、実施環境に応じて冗長性をもたせた最適なデータ管理方法が可能となる。
【図面の簡単な説明】
【００１９】
【図１−１】図１−１は、本願発明にかかるデータ管理システムの全体構成を示す図である。
【図１−２−１】図１−２−１は、本願発明の第１の運用形態の、通常稼働時の各要素の関係を示す図である。
【図１−２−２】図１−２−２は、第１の運用形態において、ファイルサーバー２２０に障害が生じた場合の各要素の関係を示す図である。
【図１−２−３】図１−２−３は、本発明の第２の運用形態の、通常稼働時の各要素の関係を示す図である。
【図１−２−４】図１−２−４は、第２の運用形態において、仮想サーバー１３０またはネットワーク接続に障害が生じた場合の各要素の関係を示す図である。
【図２−１】図２−１は、図１に示す管理サーバー１１０の概略ブロック図である。
【図２−２】図２−２は、図１に示すアプリサーバー１２０の概略ブロック図である。
【図２−３】図２−３は、図１に示すファイルサーバー２２０の概略ブロック図である。
【図２−４】図２−４は、図１に示すバックアップサーバー１５０の概略ブロック図である。
【図２−５】図２−５は、図１に示すキャッシュサーバー２３０の概略ブロック図である。
【図２−６】図２−６は、図１に示す端末ＰＣ２１０の概略ブロック図である。
【図２−７】図２−７は、図１に示す仮想サーバー１３０の概略ブロック図である。
【図３−１】図３−１−１、図３−１−２は、第１の運用形態において、ファイルサーバー２２０の通常稼働時および障害対策時の処理フローを端末２１０側から説明するフローチャートである。
【図３−２】図３−２は、第１の運用形態において、ローカル２００のファイルサーバー２２０の障害発生時の切り替え処理の、管理サーバー１１０側の処理を説明するためのフローチャートである。
【図３−３】図３−３は、ローカル２００のファイルサーバー２３０の障害復旧時の切り替え処理を説明するためのフローチャートである。
【図３−４】図３−４−１、図３−４−２は、第２の運用形態において、キャッシュサーバー２３０の通常稼働時およびネットワーク障害対策時の処理フローを端末２１０側から説明するフローチャートである。
【図３−５】図３−５は、第２の運用形態において、仮想サーバー１３０やネットワークに障害が生じた場合のキャッシュサーバー２３０の処理を説明する図である。
【図３−６−１】図３−６−１は、第２の運用形態における障害復旧時の切り替え処理を、キャッシュサーバー２３０側から説明するフローチャートである。
【図３−６−２】図３−６−２は、第２の運用形態における障害復旧時の切り替え処理を、クラウド１００の管理サーバー１１０側から説明するフローチャートである。
【図３−７】図３−７は、本発明の第１の変形例の動作を説明するためのフローチャートである。
【図３−８】図３−８は、本発明の第２の変形例の動作を説明するためのフローチャートである。
【図４−１】図４−１は、クラウド１００の管理サーバー１１０が保有する管理情報の一実施例を示す図である。
【図４−２】図４−２は、管理サーバー１１０が管理するライセンス管理テーブル４１０の実施例を示す図である。
【図４−３】図４−３は、第１の運用形態における通常稼働時の管理サーバー１１０の管理情報の例を示す図である。
【図４−４】図４−４は、第２の運用形態における通常稼働時の管理サーバー１１０の管理情報の例を示す図である。
【図４−５】本願第２の変形例において、図１−２に示すシステム構成の通常稼働時の管理サーバー１１０の管理情報の例を示す図である。
【図４−６】本願第２の変形例において、図１−２−３に示すシステム構成となるときの管理サーバー１１０の管理情報の例を示す図である。
【図５−１】図５−１は、本発明の実施例における管理メニュー画面の例を示す図である。
【図５−２−１】図５−２−１は、第１の運用形態におけるデータ管理画面の例を示す図である。
【図５−２−２】図５−２−２は、第２の運用形態におけるデータ管理画面の例を示す図である。
【図５−３】図５−３は、元本データを復元する確認画面の例を示す図である。
【図６】図６は、管理サーバーが管理する資源の一覧を示す例である。
【発明を実施するための形態】
【００２０】
本発明を実施するための形態を、添付の図面を参照しながら以下に詳細に説明する。最初に、本明細書で用いられる用語説明を行い、その後にシステム構成、システム動作、各種テーブル、画面例などを用いて本発明を説明する。
【００２１】
（１）用語説明
「アプリ」：サービスを受ける契約者（会計事務所、顧問先等）が業務処理で使用するアプリケーションプログラムをいう。
「データ」：アプリによって入力、出力される業務の情報をいう。対象となる装置に保存するデータ（ファイル）が元本データ、コピーデータ、キャッシュデータ、バックアップデータのいずれかを区別するために、ＸＸデータと表記することもある。
「元本データ」：データのマスターをいう。
「更新データ」：元本データの読み出し後、データの追加、削除などの変更が生じた際の差分のデータをいうが、元本データに差分のデータを付加したデータ、あるいは差分のデータだけのいずれであってもよい。
「コピーデータ」：元本データを複写したデータをいう。
「アプリサーバー（アプリケーションサーバー）」：サービス契約者が必要とする適切なバージョンのアプリを提供するサーバーをいう。
「管理サーバー」：契約者の情報や、課金情報、アプリの提供、元本データ、コピーデータ、管理情報の管理、共有等の仕組みを統合管理するサーバーをいう。主にクラウド側に設置されていることを前提として記載するが、ローカル側に設置されていてもよい。また実マシンの実サーバーや仮想サーバーのほか、仮想マシンの仮想サーバーで構成してもよい。
「クラウド（ＩＤＣ）」：サービス提供者が物理サーバー、記録装置、通信機器等を設置し、契約者に対するサービスを履行するために必要な前記管理サーバー、アプリサーバー、バックアップサーバー、キャッシュサーバー、データの保存、保全を行う設備（インターネットデータセンター）をいう。１拠点で構成していてもよいし、多数の拠点で分散的あるいは多重的あるいは仮想的に構成されていてもよい。また、必ずしも拠点である必要はなく、実機のサーバーで構成されていてもよいし、センター自体が仮想的なサーバーであってもよい。
「ローカル（事務所）」：サービス契約者がサービスを利用している会計事務所等の拠点をいう。
「実機（実マシン）」：入力、記録、制御などの物理的な装置を搭載したコンピューターをいう。
「仮想」：ソフトウェア技術により、実機のサーバー上に構築した擬似的なコンピューターをいう。
「仮想マシン」：仮想のコンピューターで、サーバーの機能を提供するコンピューターをいう。仮想マシン上にさらに仮想サーバー等の仮想のコンピューターを動作させることもできる。
「単体機」：アプリの起動、データの入出力操作を行う端末で、単独でも動作するコンピューターであり、元本、コピー、更新データ等をコンピューター内部の記録装置に保持する機能を持つ。
「端末機」：アプリの起動、データの入出力操作を行う端末をいう。
「端末」：アプリの起動、データの入出力を行うコンピューターをいい、必要に応じて更新データを記憶装置に保持する機能を使用する。主にローカル側に設置されていることを前提として記載するが、クラウド側に設置されていてもよく、実マシン（端末PC）でもよいし、仮想端末でもよい。
「ファイル」：アプリによって入力、出力される業務の情報であるデータのまとまりをいう。
「キャッシュ」：クラウドの仮想マシンの仮想サーバーに登録されたデータを使用するとき、使用するデータを一時的にローカルのキャッシュサーバーの記憶装置に一時保存することまたはそのデータをいい、同じデータへのアクセス時にそのデータにアクセスすることでアクセス高速化を図る。ここで保存するデータは、ＤＢテーブル全体や使用するファイル全体等、より大きなデータをキャッシュでき、より効率よくデータへの高速アクセスを実現する。キャッシュアクセスとファイル転送の違いであるが、更新しようとしているデータの位置を端末アプリケーションが明確に意識できているかが大きな違いである。キャッシュアクセス時、端末アプリケーションはキャッシュへのアクセスは意識しておらず、元本データのあるサーバーの記憶装置にアクセスしていると認識する（実際は中継しているキャッシュサーバー内のキャッシュデータにアクセスしている）。一方ファイル転送時、端末アプリケーションが使用するデータはいったんクラウドのサーバーにある元本データをローカルの記憶装置にファイル転送して、端末アプリケーションはそのローカルの装置に対してアクセスしている点が異なる。
「バックアップ」：障害発生に備えてサーバーの記憶装置の内容を複製し、クラウドのバックアップサーバーの記憶装置に保存することをいう。バックアップデータの対象は、元本データ、更新データ、管理情報、使用プログラム、アプリ情報などがある。
「リストア」：障害が発生した場合に、障害が発生した機器（サーバー、端末等）に代わって別のサーバーに同じ役割を持たせるために必要な情報等をバックアップサーバーからバックアップデータを復元し、利用可能な状態を構築することをいう。
「リカバリ」：「リストア」は、別のサーバーを起動等した上で、データの移し替えや、環境の復旧を行なうのに対し、同じサーバー内のデータの取り扱いを切り換える処理であり、別サーバーにデータと環境を復旧する「リストア」と区別して、リカバリと呼ぶ。第１の運用形態において、ネットワーク障害時のキャッシュサーバーにおけるリカバリ処理の場合は、元本の部分的なコピーデータについてリカバリ処理が行なわれるが、元本の全部についてリカバリ処理がなされることを除外する趣旨ではない。
「直接処理」：データファイルを直接オープンして更新することをいう。内蔵ディスク、ローカルのファイルサーバーがなければ高速に処理することができない。
「ファイル転送」：扱うデータを操作するファイル単位でまとめてコンピューター（端末）間で転送（コピー）することをいう。
「直接処理方式」：元本データまたはコピーデータのファイルを直接オープンして更新する方式をいい、元本データがクラウドにあり、端末がローカルというように離れている時には遅くなる方式である。
「ファイル転送方式」：通信環境に依存することなく、データの入出力を行うための手法であり、クラウドの仮想サーバーに元本データがある場合、元本データをいったんローカルの記憶装置にコピーしてそのデータを直接操作することで高速な処理を実現する。
「ファイルサーバー」：元本データないしコピーデータを格納する管理装置としての役割を持つサーバーをいう。主に元本データを格納して管理するが、障害発生時に一時的なファイルサーバーとして機能する場合には、コピーデータを格納して管理する。
「主サーバー」：ファイルサーバーのうち、データの元本場所として管理しているファイルサーバーをいう。このため、障害発生時の一時的なファイルサーバーについては、一時的な主サーバーと読み替えられることがある。
「キャッシュサーバー」：キャッシュデータを管理する管理装置としての役割を持つサーバーをいう。
「バックアップサーバー」：バックアップデータを管理する管理装置としての役割を持つサーバーをいう。主にクラウド側に設置されていることを前提として記載するが、ローカル側に設置されていてもよい。また実マシンの実サーバーや仮想サーバーのほか、仮想マシンの仮想サーバーで構成してもよい。
「管理メニュー」：サービス契約者が、契約形態に応じて使用可能なサービスを選択したり、元本、コピーなどのデータの保管場所や、操作する端末の種類などを設定するためのグラフィカル・ユーザー・インターフェースをいう。
「管理情報」：管理サーバーが管理する情報をいい、「管理区分」、「実機／仮想」、「名称」、管理するデータを示す「データ」、「役割」、「有効／無効」、「管理場所」、「状態」、「接続元」、課金の有無を管理する「課金有無」等の情報を含み得る。
「アカウント」：ユーザー管理テーブル（図示せず）で管理しており、ユーザー名、パスワード、ログイン可能な端末、アクセス権限、等からなり、ライセンス管理テーブル（図４−２）と組み合わせて使用される。
【００２２】
（２）システム構成および簡単な動作の説明
次に、本願発明のシステム構成について説明する。図１−１は、本願発明にかかるデータ管理システムの全体構成を示す図である。図１に示すように、例えば会計事務所のコンピューターシステムといったローカル（事務所）のシステム２００がクラウド（ＩＤＣ）１００につながっている。ローカル２００では１以上の端末ＰＣ（１〜Ｎ）２１０と、ファイルサーバー２２０と、キャッシュサーバー２３０とがＬＡＮ接続され、ファイヤウォールＦＷを介してインターネットに接続されている。クラウド１００では管理サーバー１１０と、アプリサーバー１２０と、仮想サーバー１３０を実装する仮想マシン１４０と、バックアップサーバー１５０とがＬＡＮ接続され、ファイヤウォールＦＷを介してインターネットに接続されている。
【００２３】
ここで、クラウド側の仮想マシン１４０は、既に仮想マシンとして起動している場合のほか、起動していない場合で起動待ちの場合や、起動の準備さえされていない状態を含むものとする。このため、クラウドの仮想マシン仮想サーバーは、すでに存在する場合の他、仮想マシンの起動から始まって仮想サーバーとして構成する前の段階を含み、障害発生の時点など、必要に応じて選択的にネットワークに接続されるようにしてもよい。なお、上記のようにクラウド１００の構成要素は複数の拠点に点在してインターネットで相互接続されていてもよい。また、後の説明により明らかなように本発明は常にこれらの構成要素の全部を必要とするものではなく、実施例および／または実施環境によってこれらの要素の一部または全部を選択的に利用するものである。
【００２４】
図１−２−１は、本願発明の第１の運用形態における、通常稼働時の各要素の関係を示す図である。第１の運用形態では、ローカルの個々の端末２１０が利用するデータ元本はローカルのファイルサーバー２２０に格納されており、端末２１０はＬＡＮを介して所望のファイルを直接操作することができる。ファイルサーバー２２０のデータはクラウド１００のバックアップサーバー１５０に随時あるいは定期的にバックアップされる。各サーバーの役割やそのときの有効／無効、接続先などの情報は管理サーバー１１０の管理情報に規定され、各サーバーや端末２１０は必要に応じて管理サーバー１１０の管理情報を参照し、データのアクセス先やバックアップデータの送り先などの情報を取得する。なお、クラウドのバックアップサーバーや管理サーバー及びローカルのファイルサーバーは、それぞれ実サーバーである場合の他、仮想的に構築されたサーバーを用いるようにしてもよい。また、管理サーバー及びバックアップサーバーは主にクラウド側に設置されていることを前提として記載するが、ローカル側に設置されていてもよい。
【００２５】
図１−２−２は、上記の第１の運用形態において、ファイルサーバー２２０に障害が生じた場合の各要素の関係を示す図である。運用中にファイルサーバー２２０に障害が生じた場合、後に詳述するが、管理サーバー１１０の管理情報が変更され、クラウド１００の仮想マシンに仮想サーバー１３０が用意されて、バックアップサーバー１５０からこの仮想サーバー１３０にバックアップデータがリストアされる。端末２１０は管理サーバー１１０の管理情報に従って以降は仮想サーバー１３０のファイルにアクセスして、業務が継続される。この切り替え処理により、端末２１０のオペレーターはファイルサーバー２２０に障害が生じてクラウド上の仮想サーバー１３０にアクセス先が切り替わったことを意識せずに業務を継続することができる。さらに、ローカル２００のファイルサーバー２２０からクラウド１００の仮想サーバー１３０に接続先が切り替わったことにより、アクセス方式を通常の接続方式からネットワーク環境による影響の少ないファイル転送方式に変更して、レスポンス遅延が生じないようにする。なお、クラウドのバックアップサーバーや管理サーバー及びローカルのファイルサーバーは、それぞれ実サーバーである場合の他、仮想的に構築されたサーバーを用いるようにしてもよい。また、管理サーバー及びバックアップサーバーは主にクラウド側に設置されていることを前提として記載するが、ローカル側に設置されていてもよい。
【００２６】
図１−２−３は、本発明の第２の運用形態における、通常稼働時の各要素の関係を示す図である。第２の運用形態では、ローカル２００の端末２１０で使用する元本データはクラウド１００の仮想マシン１４０に構成された仮想サーバー１３０に格納されており、さらにクラウド１００のバックアップサーバー１５０にバックアップされる。ローカル２００にはキャッシュサーバー２３０が設けられ、端末２１０からアクセスしたデータの複製がここに蓄積（キャッシュ）される。ここでもアクセス方法はファイル転送方式が用いられ、アクセス時に元本データがキャッシュサーバー２３０に読み込まれ、端末２１０からこのキャッシュデータに対して直接操作が行われる。この場合でも、端末２１０のオペレーターからは、仮想サーバー１３０の元本データを操作しているように見えている。管理サーバー１１０の管理情報も最初に参照されてキャッシュデータとして取り込まれている。
【００２７】
なお、クラウドのバックアップサーバーや管理サーバー及びローカルのキャッシュサーバーは、それぞれ実サーバーである場合の他、仮想的に構築されたサーバーを用いるようにしてもよい。また、管理サーバー及びバックアップサーバーは主にクラウド側に設置されていることを前提として記載するが、ローカル側に設置されていてもよい。キャシュサーバーは主にローカル側に設置されていることを前提として記載するが、クラウド側に設置されていてもよい。なお、本システムによれば、ローカルの実サーバーとしてのキャッシュサーバーは、通常時にキャッシュ機能を持たせられればよく、他方で、障害時には、あくまで一時的なファイルサーバーとして機能するだけに留めるので、負荷によって、多少処理速度が低下しても良いことを背景として、比較的小規模ハードウェア構成で済むというメリットがある。
【００２８】
図１−２−４は、第２の運用形態において、仮想サーバー１３０またはネットワーク接続に障害が生じた場合の各要素の関係を示す図である。仮想サーバー１３０またはネットワーク接続に障害が生じると、仮想サーバー１３０の元本データにアクセスできなくなる。キャッシュサーバー２３０は、そのときにキャッシュしていた管理情報およびファイルデータ（キャッシュデータ）のコピーを作成し、管理情報のファイルのアクセス先情報を当該キャッシュサーバーに変更する。これが端末２１０に通知されてアクセスパスが変更され、障害発生中はキャッシュサーバーが一時的なファイルサーバーの役割を果たし、業務を継続することができる。
【００２９】
以上、直接操作できないキャッシュサーバーのキャッシュデータを、元本の部分的なコピーデータとして取り扱うことにより、直接操作可能な元本の部分的なコピーデータとして取り扱い、キャッシュサーバーを一時的なファイルサーバーとして機能させるためのリカバリ処理について説明した。ここで、第１の運用形態の「  リストア手段  」は、別のサーバーを起動等した上で、  データの移し替えや環境の復旧を行なうので、リストアと呼び、他方、第２の運用形態では、同じキャッシュサーバー内のキャッシュデータの取り扱いを元本の部分的なコピーデータに替える処理であり、別サーバーにデータと環境を復旧する第１の運用形態の「  リストア手段  」と異なるため、リカバリと呼んで区別することにする。なお、第１の運用形態において、ネットワーク障害時のキャッシュサーバーにおけるリカバリ処理の場合は、元本の部分的なコピーデータについてリカバリ処理が行なわれるが、仮想サーバーの障害発生時に、バックアップサーバーのデータを用いてリカバリ処理を行なう場合など、元本の全部についてリカバリ処理がなされることを除外する趣旨ではない。
【００３０】
障害が回復したら、バックアップサーバー１５０を経由して仮想サーバー１３０に更新データを反映させてから、元のキャッシュサーバーとしての役割に戻る。なお、クラウドのバックアップサーバーや管理サーバー及びローカルのキャッシュサーバーは、それぞれ実サーバーである場合の他、仮想的に構築されたサーバーを用いるようにしてもよい。また、マスターサーバー、管理サーバー及びバックアップサーバーは主にクラウド側に設置されていることを前提として記載するが、ローカル側に設置されていてもよい。スレーブサーバーが主にローカル側に設置されていることを前提として記載するが、クラウド側に設置されていてもよい。また、本システムによれば、陳腐化したスレーブサーバーをキャッシュサーバーにすることによりマシンを効率的に活用することができるメリットがある。
【００３１】
図２−１〜図２−７は、図１に示す管理サーバー１１０、アプリサーバー１２０、ファイルサーバー２２０、バックアップサーバー１５０、キャッシュサーバー２３０、端末ＰＣ２１０、および仮想サーバー１３０の概略ブロック図である。図２−１の管理サーバー１１０の記憶部１１２に、管理情報、ライセンス情報、利用者情報等が格納される。図２−２のアプリサーバー１２０にはアプリデータや、アプリバージョンが格納されている。図２−５のキャッシュサーバー２３０の記憶部２３２には、キャッシュデータの他に、管理サーバー１１０が有する管理情報、ライセンス情報、利用者情報などが保存され、さらに図１−２−４に示すように障害時にファイルサーバーを代替するためのコピーデータ格納部が用意されている。図２−６のローカルの端末２１０は単体機として機能する場合の処理データや管理サーバーへの接続先を示す管理サーバーアクセス用パスを記憶する記憶部２１２と、オペレーターがファイルを操作するためのキーボード等の入力部２１４と、ディスプレイへの出力部２１５とを備える。
【００３２】
（３）管理情報やテーブルの説明
図４−１は、クラウド１００の管理サーバー１１０が保有する管理情報の一実施例を示す図である。本図に示すように、管理情報には当システムに組み込まれるか利用可能な各種サーバーや端末およびその内容がリストアップされている。管理情報に含まれる情報は以下の通りである。
「番号」：管理番号の項目番号で、システム側で自動採番される。
「管理区分」：管理サーバーで管理する対象であって、本明細書では、単体機（操作とデータを取り扱う装置）、サーバー（データを取り扱う装置）、端末機（操作を取り扱う装置）の種別を含む。このうち、単体機、サーバーは、元本データないしコピーデータを格納する管理装置としての役割も備える。装置の区分であり、単体機、サーバー、アプリケーションサーバー、キャッシュサーバー、バックアップサーバー、スレーブサーバー、端末がある。  
「実機／仮想」：装置が、仮想環境上にあるものか、実機上にあるかの区別に用いる。
「名称」：サーバー、ＰＣ等の識別用に付与される名称である。
「データ」：管理装置が管理するデータの種類をいい、元本データ、コピーデータ、キャッシュデータ、バックアップデータのいずれかを区別する。
「役割」：ファイルＳＶ（サーバー）、アプリＳＶ、バックアップＳＶ、キャッシュＳＶ、管理ＳＶ、単体機、端末機等のサーバーや端末などの装置が実行できる機能を示す。
「有効／無効」：役割を利用するときの設定で、使用する時は有効、使用を中止する場合は無効に設定する、また、使用できる状況であれば有効である、使用できない状況であれば無効の表示となる。有効と無効はトグル形式で設定／表示できるようになっている。
「最新データ」：各サーバーや端末が有する元本データやバックアップデータ、コピーデータなどが最新のものか（更新済み）、それとも障害発生、サーバーの停止やデータの更新処理がされていないことにより元本データの最新のものとは異なっているか（未更新）の別を示す。
「管理場所」：サーバーや端末などの装置が物理的に存在する場所を示すものであり、クラウドはＩＤＣを示し、ローカルは会計事務所などの事務所内や顧問先等の外出先を含むＩＤＣ以外の場所を示す。
「状態」：動作、停止、故障、ネットワーク障害等による通信障害等の装置の状態及び１つの装置に複数の役割が存在する場合はその装置の役割の状態を示す。
「接続元」：仮想ＰＣを使用しているときに、その仮想ＰＣへログインしているモバイル機器（スマートフォンやタブレット等）の名称を示す。
【００３３】
図４−２は、管理サーバー１１０が管理するライセンス管理テーブル４１０の実施例を示す図である。例えば本発明のサービスの提供者が、複数の会計事務所、企業、個人などに複数の税務会計用アプリを提供している場合に、企業や事務所ごとに契約しているアプリの種類やライセンス数、使用者数をオンラインで管理するためのテーブルである。ライセンス管理テーブル４１０はユーザー名、契約しているアプリ名、許諾しているライセンス総数、現在使用しているライセンス数などの情報が登録される。利用契約締結時にライセンスがこのテーブルに登録され、例えば会計事務所の端末２１０からアプリを使用する際に管理サーバー１１０にアクセスすると使用ライセンス数が把握される。
【００３４】
（４）第１の運用形態の説明
図１−２−１、図１−２−２に示す第１の運用形態について、フローチャート、管理情報テーブルの内容および画面例を用いて詳細に説明する。図３−１（３−１−１、３−１−２）は、第１の運用形態において、ファイルサーバー２２０の通常稼働時および障害対策時の処理フローを端末２１０側から説明するフローチャートである。例えば会計事務所のシステムにおいて事務所員（すなわちオペレーター）が事務所の業務データ（例えば顧客の出納帳データ）を操作しようとする場合、オペレーターが端末を選択する（Ｓ２−１）。この場合の端末２１０は事務所のデスクトップＰＣであってもよいし、ネットワーク接続されたモバイル端末であってもよい。端末２１０はクラウド１００の管理サーバー１１０にログインすると、他の接続端末からの管理サーバー１１０へのアクセスロック処理が行われる（Ｓ２−２）。また、使用端末が管理情報にある現在の端末情報の設定のうち、端末の設置場所（ローカル）、有効／無効（無効）や役割（端末機）等を設定することで、管理サーバー１１０は通知された端末２１０の情報をライセンス管理テーブル４１０（図４−２）で確認して、端末に関する情報が管理情報において更新される（Ｓ２−３）。この管理情報が図４−３の管理情報テーブルである。管理サーバーは更新された管理情報とライセンス管理テーブルの情報をもとに使用端末へ使用可能なアカウントを通知する。ログインの際の管理情報は図４−３の内容となり、端末２１０に表示される画面は図５−２のようになる。管理情報および画面例に示すように、通常稼働時にはローカル２００の実サーバー２２０に元本データがあり、これがクラウド１００のバックアップサーバー１５０にバックアップされ、クラウド上の仮想サーバーは現在無効となっている。このように、図４−１に示した管理情報は、システムの構成要素の稼働状態や障害発生状況に応じて、図４−１から図４−３の内容に更新されたように、随時、動的に書き換えられて、管理されている。
【００３５】
端末２１０は、元本データの管理場所、使用端末２１０の管理場所、バックアップデータの管理場所の情報を管理サーバー１１０から取得する（Ｓ２−５）。このとき、利用するアプリの最新版はクラウド１００のアプリサーバー１２０に登録されており、管理サーバー１１０は端末２１０に最新アプリの更新情報を通知して最新版にアップデートされるようにすることができる。この場合（通常時）のアクセスパスはローカル２００のファイルサーバー２２０となる。オペレーターは端末２１０でアプリを起動し、アクセスするデータを選択する（Ｓ２−６）。
【００３６】
サーバーへのアクセス方式を判断するため、元本データの登録場所（すなわちローカル（事務所）２００のファイルサーバーまたはクラウド（ＩＤＣ）１００の仮想サーバー１３０）と端末２１０の設置場所を比較する（Ｓ２−７）。通常運用時には端末２１０とファイルサーバー２２０が同じローカル２００にあるため、アクセス方式はLANでのアクセスとなるので、ファイルサーバー２２０の元本データを直接操作してファイルを更新する（Ｓ２−１７）。一方、図１−２−２に示すようなファイルサーバー２１０の障害発生時には元本データがクラウド１００の仮想サーバー１３０に代替され、端末２１０と元本データの設置場所が異なるため、アクセス方式はWeb接続によるファイル転送によるアクセスとなるので、仮想サーバー１３０のデータを直接操作するのではなく、データを仮想サーバー１３０から端末２１０の記憶装置にファイル転送してコピーデータとして登録し、これを操作した後に更新データを再びファイル転送方式で仮想サーバー１３０に戻し、仮想サーバー１３０の元本データが更新される（Ｓ２−８〜Ｓ２−１１）。
【００３７】
なお、例えば自宅のモバイル端末から、事務所のローカルの実サーバーないし実サーバーに接続する端末に、リモートデスクトップでアクセスするような場合などの、モバイル端末でリモートデスクトップを利用する場合は、当該モバイル端末は必ずしも事務所内にある必要はなく、自宅や移動中の車内や電車内であっても構わない。このような場合にも、管理情報における端末の設置場所はローカルとなる。この場合において、ステップＳ２−７は、上記のような場合もローカルとして取り扱うことになるので、そのまま動作することになる。元本データは、バックアップサーバー１５０にバックアップされる（Ｓ２−１２）。また、端末２１０で使用したアプリ情報や、管理サーバー１１０の管理情報も、バックアップサーバー１５０にバックアップされる（Ｓ２−１４〜Ｓ２−１６）。バックアップのタイミングは更新と同時でもよいし、所定の日時でもよい。またバックアップはブルバックアップでもよいし、差分バックアップでもよい。
【００３８】
図３−２は、第１の運用形態において、ローカル２００のファイルサーバー２２０の障害発生時の切り替え処理の、管理サーバー１１０側の処理を説明するためのフローチャートである。管理サーバー１１０はファイルサーバー２２０の動作を随時監視しており、電源等のハードの故障等の障害が生じた場合にはこれを検知して端末２１０に通知してもよいし、ファイルサーバー２２０にアクセスできなくなった端末２１０が障害を検知してもよい。運用を継続するために端末２１０からクラウドの管理サーバー１１０へログインすると、他の端末から管理サーバー１３０へのアクセスロック処理が行われ（Ｓ３−１）、端末２１０に関する管理情報（端末の設置場所（ローカル）、有効／無効（有効）や役割（端末機から単体機に変更）等）が更新される（Ｓ３−２）。このときの端末２１０に表示される画面例を、図５−１に示す。
【００３９】
次に管理サーバー１１０は、当該管理サーバーが管理している資源のうち、ファイルサーバーとして利用可能なサーバーの一覧を取得して、端末２１０のオペレーターに通知して選択させる（Ｓ３−３）。この一覧の例を図６に示す。図６に示すように、管理サーバー１１０はクラウド１００および／またはローカル２００に複数のサーバーを管理しており、それぞれデータの有無、データが最新であるか否か、サーバーが有効／無効か、状態、実機か仮想かが管理されている。機能未設定のサーバーは設定によりファイルサーバー、バックアップサーバー、キャッシュサーバーとして機能させることができる。スレーブサーバーの状態１〜３はそれぞれ、状態１がコールドスタンバイ、状態２がウォームスタンバイ、状態３がホットスタンバイを意味する。これらのサーバーの数やそのステータスは実施環境や本発明のサービスの運用ポリシーによって適宜決定され、図６に示す例に何ら限定されるものではない。
【００４０】
図６に示す環境において、条件１または２（未稼働のサーバー（機能未設定）、停止、無効、データなし）の場合、選択されたサーバーを起動して（Ｓ３−７、Ｓ３−１６）ファイルサーバーの機能を設定し（Ｓ３−８）、バックアップサーバー１５０のバックアップデータを用いてデータをリストアする（Ｓ３−９）。条件３または４（未稼働のファイルサーバー、停止、有効、データ未設定）の場合、そのままバックアップデータをリストアする（Ｓ３−９）。条件５または６（スレーブサーバー、コールドスタンバイ、停止、有効、コピーデータ、未更新）の場合、選択したサーバーを起動して（Ｓ３−１３）、バックアップサーバー１５０からバックアップデータをリストアし、コピーデータを最新のデータに更新する（Ｓ３−１４）。条件７または８（スレーブサーバー、ウォームスタンバイ、停止、有効、コピーデータ、未更新）の場合、既に起動しているため、バックアップサーバー１５０からバックアップデータをリストアし、コピーデータを最新のデータに更新する（Ｓ３−１４）。条件９または１０（スレーブサーバー、ホットスタンバイ、停止、有効、コピーデータ、更新済み）の場合、既に立ち上がってデータも同期されているため、そのまま切り替え処理へと進む。なお、バックアップデータのリストア時に、コピーデータの更新はフルバックアップデータのリストアでもよいし、最新データとの差分のみリストアしてもよい。また図５−３に示すような確認画面を表示させてもよい。切り替え処理では、クラウド１００の管理サーバー１１０の管理情報（図４−３参照）に対して、選択したサーバー（仮想マシンまたは実マシン）が新たなファイルサーバー（元本データ管理装置）として準備できたため（ファイルサーバーの利用環境構築）、選択したサーバーの管理情報（データ（元本データに変更）、有効／無効（有効に変更））を更新する（Ｓ３−１０、Ｓ３−１１）。なお、図１−２−２に示す例では、仮想マシンの仮想サーバー１３０を障害時の代替サーバーに構成している。管理情報を更新したら（Ｓ３−１１）、管理サーバー１１０へのアクセスアンロック処理を行う（Ｓ３−１２）。これにより端末２１０から管理情報を参照して、新たなファイルサーバー（クラウド１００の仮想サーバー１３０）にアクセスされる。このアクセス方式は前述のようにファイル転送方式となる。
【００４１】
図３−３は、ローカル２００のファイルサーバー２３０の障害復旧時の切り替え処理を説明するためのフローチャートである。ファイルサーバー２３０の復旧後に、使用端末２１０からクラウド１００の管理サーバー１１０にログインすると、管理サーバー１３０へのアクセスロック処理が行われる（Ｓ３−２１）。管理サーバー１１０は端末２１０の情報（端末の設置場所（ローカル）、有効／無効（有効）や役割（単体機から端末機に変更）等）を管理情報上で更新する（Ｓ３−２２）。次に、管理サーバー１１０は端末２１０に再び利用可能なサーバーの一覧（図６参照）を提示し、復旧先のサーバーの選択を受け付ける（Ｓ３−２３）。ファイルサーバー２３０の回復後にシステムを戻すために、この場合はローカルのファイルサーバー２３０を選択する（図示せず）。選択後の確認画面の例を、図５−３に示す。なお、復旧先のサーバーは予め定められたポリシー（サーバー性能、設置場所、実機／仮想の別など）により管理サーバー１１０が自動で決定してもよい。次に、管理サーバー１１０は、障害発生中にファイルサーバーとして用いていたクラウド１００の仮想サーバーのデータを、バックアップサーバー１５０にバックアップする（Ｓ３−２４）。次に、管理サーバー１１０は復旧先のローカル２００の実マシンのファイルサーバー２２０に、クラウド１００のバックアップサーバーからバックアップデータをリストアして、ファイルサーバー２２０の利用環境を構築する（Ｓ３−２５）。そして、管理サーバー１１０は、元本データの管理場所を、クラウドの仮想サーバー１３０から復旧したローカルのファイルサーバー２３０に切り替えるべく、管理情報を更新する（Ｓ３−２６）。具体的には仮想サーバー１３０へのアクセスロック処理を行った上で、管理情報において仮想サーバーのデータの設定を「元本」から「なし」に変更し、ファイルサーバー２２０のデータ設定を「コピー」から「元本」に変更する。管理情報更新後に仮想サーバーが記憶しているデータを削除する。次に、クラウドの仮想サーバー１３０を停止し（Ｓ３−２７）、管理情報においてこの仮想サーバー１３０を無効にするとともに、ローカルのファイルサーバー２３０を有効にするよう更新する（Ｓ３−２８、Ｓ３−２９）。そして、管理サーバー１１０へのアクセスアンロック処理を行い、システムを元の状態に戻す（Ｓ３−３０）。本実施例では、ファイルサーバー２２０を実サーバーとしているが、仮想サーバーでもよい。
【００４２】
（５）第２の運用形態の説明
次に、図１−２−３、図１−２−４に示す第２の運用形態について、フローチャート、管理情報テーブルの内容等を用いて詳細に説明する。図３−４（３−４−１、３−４−２）は、第２の運用形態において、キャッシュサーバー２３０の通常稼働時の処理フローを端末２１０側から説明するフローチャートである。例えば会計事務所のシステムにおいて事務所員（すなわちオペレーター）が事務所のファイル（例えば顧客の出納帳データ）を操作しようとする場合、オペレーターが端末（図５−２−２の実機ＰＣ１）を選択する（Ｓ４−１）。端末２１０は管理サーバーアクセス用パスに示される管理サーバーへアクセスする（S4-2）。端末２１０はクラウド１００の管理サーバー１１０にログインすると、他の接続端末からの管理サーバー１１０へのアクセスロック処理が行われる（Ｓ４−３）。また、使用端末が管理情報にある現在の端末情報の設定のうち、「役割」を「端末機」に、「有効／無効」を「無効」に設定することで、管理サーバー１１０は通知された端末２１０の情報をライセンス管理テーブル４１０（図４−２）で確認して、端末に関する情報が管理情報（端末２１０を登録）において更新される（Ｓ４−４）。管理サーバーは更新された管理情報とライセンス管理テーブルの情報をもとに使用端末へ使用可能なアカウントを通知する。ログインの際の管理情報は図４−４の内容となり、端末２１０に表示される画面は図５−２−２のようになる。これらの図に示すように、通常稼働時にはクラウド１００の仮想サーバー１３０に元本データがあり、これがバックアップサーバー１５０にバックアップされ、ローカル２００にキャッシュサーバー２３０が設置されている。
【００４３】
端末２１０は、元本データの管理場所、使用端末２１０の管理場所、バックアップデータの管理場所の情報を管理サーバー１１０から取得する。このとき、利用するアプリの最新版はクラウド１００のアプリサーバー１２０に登録されており、管理サーバー１１０は端末２１０に最新アプリの更新情報を通知して最新版にアップデートされるようにすることができる。この場合（通常時）のアクセスパスはローカル２００のファイルサーバー２２０となる。オペレーターは端末２１０でアプリを起動し、アクセスするデータを選択する。また、利用させるアプリの最新版はクラウド１００のアプリサーバー１２０に登録されており、管理サーバー１１０は端末２１０に最新アプリの更新情報と元本データのアクセス用パスを通知する（Ｓ４−５）。この場合（通常稼働時）のアクセスパスはクラウド１００の仮想サーバー１３０となる。端末２１０は元本データの管理場所と使用端末の管理場所と、バックアップデータの管理場所とを取得する（Ｓ４−６）。このとき、端末２１０に通知あるいは取得された、クラウド１００の管理サーバー１１０が管理している使用プログラム、データ、アプリ更新情報、元本データアクセスパス、元本データ管理場所、使用端末の管理場所、バックアップデータ管理場所などの管理情報が、キャッシュサーバー２３０に保存される（Ｓ４−７）。このキャッシュサーバー２３０の動作はバックグラウンドで行われ、端末２１０のオペレーターが意識することはない。
【００４４】
これらの環境が整ったら、端末２１０でアプリが起動され、アクセスするデータが選択される（Ｓ４−８）。データアクセス時、サーバーへのアクセス方式を判断するため、端末２１０は元本データの場所と端末２１０の設置場所を比較する（Ｓ４−９）。通常稼働時には、元本データはクラウド１００の仮想サーバー１３０にあるため、ステップＳ４−１０に進む。後に詳述するが、仮想サーバー１３０の故障による障害発生時にはローカル２００のキャッシュサーバー２３０が仮想サーバー（ファイルサーバー）を代替するため、元本データと端末２１０の設置場所は同じローカル２００となり、キャッシュサーバー２３０の元本データへのアクセスが行われる（Ｓ４−２０）。ネットワークの障害発生時には仮想サーバー１３０へアクセスできないので、ローカルのキャッシュサーバーのデータを元に、クラウドの仮想サーバーの元本データの少なくとも一部を復元して、元本の部分的なコピーデータとすることにより、そのままでは直接操作できない当該元本の部分的なキャッシュデータを、直接操作できる元本データの部分的なコピーデータとして取り扱うことで、ローカル２００のキャッシュサーバー２３０が管理サーバーおよび仮想サーバー（ファイルサーバー）を代替するため、元本データと端末２１０の設置場所は同じローカル２００となり、キャッシュサーバー２３０のコピーデータへのアクセスが行われる（Ｓ４−２０）。なお、ネットワークの障害発生時の場合は管理サーバーアクセス用パスがクラウドの管理サーバーからキャッシュサーバー内の管理サーバー（代替機能）に変更される。
【００４５】
通常稼働時、キャッシュサーバー２３０は端末２１０からのリクエストを監視しており、端末２１０がアクセスしようとするデータのキャッシュがキャッシュサーバー２３０内にあるか否かを確認し、ある場合には端末２１０にこれを提供する（Ｓ４−１２）。キャッシュサーバー２３０にキャッシュデータがない場合は、クラウド１００の仮想サーバー１３０から指定されたデータがローカルのキャッシュサーバー２３０にファイル転送され、端末２１０はキャッシュサーバー内のデータを直接操作して更新する（Ｓ４−１１、Ｓ４−１２）。処理終了後には、ローカルのキャッシュサーバー２３０のキャッシュデータがクラウドの仮想サーバーの元本データの管理場所にファイル転送され、これが反映される（Ｓ４−１３）。元本データはバックアップサーバー１５０にバックアップされる（Ｓ４−１４）。別のデータを処理する場合（S４−１５：Ｎｏ）はアクセスするデータ選択処理（Ｓ４−８）へと戻り、データ処理を終わる場合は処理を終了する（S４−１５：Ｙｅｓ）。
【００４６】
図３−５は、第２の運用形態において、仮想サーバー１３０やネットワークに障害が生じた場合のキャッシュサーバー２３０の処理を説明する図である。第２の運用形態において、図１−２−４に示すように、クラウド１００の仮想サーバー１３０が故障したり、クラウド１００とローカル２００を接続するネットワークに障害が生じたりした場合、仮想サーバー１３０の元本データにアクセスできなくなる。この場合、オペレーターは端末２１０から管理サーバーアクセス用パスに示された管理サーバーにログインする（Ｓ５−１）。仮想サーバー１３０の故障の場合には、クラウドの管理サーバー１１０の管理ツールを起動する。キャッシュサーバー２３０は、当該キャッシュサーバーのアクセスロック処理を行い、このローカルの実マシンのキャッシュサーバーとしての動作を停止する（Ｓ５−３）。キャッシュサーバー２３０は、管理情報においてバックアップサーバー１５０を無効にするよう更新する（Ｓ５−９）。そして、ローカルのキャッシュサーバー２３０の役割をキャッシュサーバー（キャッシュＳＶ）からファイルサーバー（ファイルＳＶ）へと切り替えて、管理情報においてキャッシュサーバーを無効から有効に変更する（Ｓ５−１０）。障害発生中のデータアクセス処理は図３−４のフローを踏襲するが、アクセス先がキャッシュサーバー２３０のコピー領域となる。
【００４７】
ネットワーク障害の場合には使用者権限でローカル２００のキャッシュサーバー２３０にログインし、キャッシュサーバー２３０の管理ツールを起動する（Ｓ５−２）。キャッシュサーバー２３０は、当該キャッシュサーバーのアクセスロック処理を行い、このローカルの実マシンのキャッシュサーバーとしての動作を停止する（Ｓ５−３）。次に、ネットワークに障害がある場合には当該キャッシュサーバー２３０のキャッシュデータに登録していた管理情報（図４−４参照）を、当該キャッシュサーバー２３０内のコピーデータ領域にコピーする（Ｓ５−４）。また、キャッシュデータに登録していた更新データを、キャッシュサーバー内のコピー領域にコピーして、利用環境を構築する（Ｓ５−５）。そして、コピーした管理情報から構築したキャッシュサーバー内の管理サーバー（代替機能）において、管理情報の管理場所をクラウド１００の管理サーバー１１０からローカルのキャッシュサーバー内の管理サーバー（代替機能）に書き換えるとともに（Ｓ５−６）、元本データの管理場所をクラウドからローカルのキャッシュサーバー２３０に変更するよう管理情報を更新する（Ｓ５−７）。これを受けて端末２１０は、ログインする管理サーバーアクセス用パスをローカル１００のキャッシュサーバー２３０内の管理サーバー（代替機能）に切り替える（Ｓ５−８）。キャッシュサーバー２３０は、管理情報においてバックアップサーバー１５０を無効にするよう更新する（Ｓ５−９）。そして、ローカルのキャッシュサーバー２３０の役割をキャッシュサーバーからファイルサーバーへと切り替え、キャッシュサーバー内の管理サーバー（代替機能）の情報（図４−６の番号７）を管理情報へ追加して、管理情報においてキャッシュサーバーを無効から有効に変更する（Ｓ５−１０）。障害発生中のデータアクセス処理は図３−４のフローを踏襲するが、アクセス先がキャッシュサーバー２３０のコピー領域となる。
【００４８】
図３−６−１は、第２の運用形態における障害復旧時の切り替え処理を、キャッシュサーバー２３０側から説明するフローチャートである。元々の主サーバーであるクラウド１００の仮想サーバー１１０の障害、またはネットワーク障害が回復したら、クラウド１００の管理サーバー１１０がこれを検知し、ローカル２００の端末２１０に通知する（Ｓ６−１−１）。ネットワーク障害が回復した場合には、これを受けた端末２１０は、ローカルのキャッシュサーバー２３０内の管理サーバー（代替機能）にログインする（Ｓ６−１−２）。ローカル２００のキャッシュサーバー２３０はアクセスロック処理を行い（Ｓ６−１−３）、ローカルのキャッシュサーバー２３０内の管理サーバー（代替機能）が、端末２１０のログイン先である管理サーバーの場所の情報（管理サーバーアクセス用パス）を、キャッシュサーバー内の管理サーバー（代替機能）から、クラウド１００の管理サーバー１１０へ変更する（Ｓ６−１−４）。このとき、管理情報において管理サーバーのアクセス用パスもクラウド１００に更新される。その後に、ローカル１００のキャッシュサーバー内の管理サーバー（代替機能）が、使用端末２１０のログアウトを受け付ける（Ｓ６−１−５）。
【００４９】
図３−６−２は、第２の運用形態における障害復旧時の切り替え処理を、クラウド１００の管理サーバー１１０側から説明するフローチャートである。クラウド１００の管理サーバー１１０が、端末２１０のログインを受け付けると、管理サーバー１１０へのアクセスロック処理を行う（Ｓ６−２−１）。管理サーバー１１０は、端末２１０の情報を取得して管理サーバー１１０の管理情報を更新する（Ｓ６−２−２）。端末２１０へ使用可能アカウントを通知する。次に、管理サーバー１１０は、ローカル２００のキャッシュサーバーのデータ（コピーデータ、更新データ、管理情報）をクラウド１００のバックアップサーバー１５０へバックアップする（Ｓ６−２−３）。また、クラウドの管理サーバー１１０が管理している資源のうち、利用可能なサーバーの一覧を端末２１０に通知し（図６参照）、オペレーターにどのサーバーに元本データを復旧させるかを選択させる（Ｓ６−２−４、図６）。これは、予め定められたポリシー（サーバー性能、設置場所、実機／仮想の別など）により管理サーバー１１０が自動で決定してもよい。復旧先のサーバー（クラウドの仮想サーバー）が決定したら、当該サーバーを立ち上げて（Ｓ６−２−５）、クラウド１００のバックアップサーバー１５０からバックアップデータをリストアして、仮想サーバー１３０の利用環境を構築する（Ｓ６−２−６）。その後、ローカル２００の実マシンのキャッシュサーバー２３０を無効にした上で、キャッシュサーバー２３０の役割を、障害運用時のファイルサーバーから再びキャッシュサーバーへと切り替え、その内容を管理情報に反映させる（Ｓ６−２−７）。そして、管理サーバー１１０はローカル２００のキャッシュサーバー２３０に作成されていたコピーデータを削除し、キャッシュサーバー２３０を有効にすべく管理情報を更新する（Ｓ６−２−８）。その後にクラウド１００の管理サーバー１１０へのアクセスアンロック処理を行い（Ｓ６−２−９）、端末２１０からのログアウトを受け付ける（Ｓ６−２−１０）。以降は、ローカル１００の端末１１０からクラウド１００の管理サーバー１１０および仮想サーバー１３０へアクセスして通常稼働時の業務が行われる。
【００５０】
以上に本発明の第１および第２の運用形態について詳細に説明したが、本発明は上述した実施形態に限らず、図１−１に示す利用可能な資源を用いて様々な変形例、変更例を実現することができる。以下に、いくつかの変形例について説明する。
【００５１】
（６）第１の変形例の説明
本発明の実施形態の第１の変形例として、図１−２−１に示す第１の運用形態の通常稼働時から、図１−２−３に示す第２の運用形態に移行する運用形態を説明する。図１−２−１に示すように、ローカル２００のファイルサーバー２２０を主サーバーとし、通常時にはローカル１００の端末２１０はこのファイルサーバー２２０の元本データにアクセスする。クラウド１１０の管理サーバー１１０がこの運用形態を管理情報に規定しており、ファイルサーバー２２０の元本データはクラウド１００のバックアップサーバー１５０にバックアップされている。この状態から、主サーバーであるファイルサーバー２２０にアクセスする端末２１０の数や、その設置場所（事務所にあるか、遠隔地からインターネット経由でアクセスするか）等の条件、あるいは予め規定された運用ポリシーに基づいて、所定の条件が満たされた場合に、図１−２−３に示す第２の運用形態に移行する。例えば、遠隔地からリモート接続する端末２１０が１０台以上となった場合に、事務所（ローカル）のファイルサーバー２２０では負荷が過大となる、あるいは事務所のＬＡＮに外部からのアクセスを増やすのが好ましくない等の観点から、主サーバーをクラウド１００上に移して第２の運用形態とすることなどが考えられる。第２の運用形態に切り替えると、クラウド１００上の仮想サーバー用仮想マシン１４０（これは実機でもよい）に仮想サーバー１３０がセットアップされてバックアップサーバー１５０からバックアップデータがリストアされ、以降に端末２１０はこの仮想サーバー１３０を主サーバーとしてアクセスする。このとき、ローカル１００のファイルサーバー２２０はキャッシュサーバーへと切り替えられ、事務所（ローカル１００）にある端末２１０はキャッシュデータを利用して業務を行うことができる。
【００５２】
図３−７は、この第１の変形例における、図１−２−１の通常稼働時から、図１−２−３に示す第２の運用形態に移行する切り替え動作を説明するためのフローチャートである。運用切り替えのトリガとなる条件はクラウド１００の管理サーバー１１０で監視されており、条件を満たす場合、あるいは端末２１０のオペレーターかシステム管理者による特別な入力指示があった場合、または端末２１０から管理サーバーにログインした場合に、クラウド１００の管理サーバー１１０はアクセスロック処理を行い（Ｓ７−１−１）、端末２１０の情報に基づいて管理情報が更新される（Ｓ７−１−２）。管理サーバー１１０から端末２１０に使用可能アカウントを通知する。次に、クラウドの管理サーバー１１０が管理している資源のうち利用可能なサーバーの一覧をオペレーターに提示し（図６参照）、切り替え先のサーバーの選択を受け付ける（Ｓ７−１−３）。この場合に図５−３に示す確認画面が提示されてもよい。次に、クラウドの管理サーバー１１０は、今まで主サーバーとして用いていたローカル２００の実マシンのファイルサーバー２２０へ各端末が接続できないようにするアクセスロック処理を行う（Ｓ７−１−４）。その後、もしバックアップデータが最新でなければ、ファイルサーバー２２０のデータをクラウド１００のバックアップサーバー１５０にバックアップして、ローカルのファイルサーバー２２０に保存されている元本データを削除する（Ｓ７−１−５）。その後、選択されたサーバー（図１−２−３の例では仮想サーバー１３０）を起動し（Ｓ７−１−６）、バックアップサーバー１５０からバックアップデータをリストアして、利用環境を構築する（Ｓ７−１−７）。その後、管理情報のファイルサーバー２２０とクラウド１００の仮想サーバー１３０の両方を無効にしたうえで、元本データの管理場所を、ローカル２００のファイルサーバー２２０からクラウド１００の仮想サーバー１３０に変更するとともに、今まで主サーバーとして利用していたローカル２００のファイルサーバーの役割をキャッシュサーバーへ切り替えて、さらにファイルサーバー２２０とクラウド１００の仮想サーバー１３０の両方を有効にするよう、管理サーバー１１０の管理情報を更新する（Ｓ７−１−８、Ｓ７−１−９）。以上が終了したら、管理サーバー１１０のアクセスアンロック処理を行い（Ｓ７−１−１０）、端末２１０が管理サーバー１１０からログアウトする（Ｓ７−１−１１）。以降は図１−２−３に示す運用形態となり、端末２１０はクラウド１００の仮想サーバー１３０を主サーバーとしてデータを操作する。なお、詳細には説明しないが、例えば主サーバーにアクセスする端末の数が減って所定数以下となるといった条件や、予め規定された運用ポリシー（一日のうちの所定の時間帯（例えば日中／夜間）、あるいは平日／終日で切り替わるようにしたり、障害発生時は復旧を優先又は運用継続を優先したりする等）に応じて、図１−２−３の運用形態から図１−２−１の運用形態に戻るようにすることができる。
【００５３】
（７）第２の変形例の説明
次の例として、クラウドの仮想マシンの仮想サーバーと、ローカルの実マシンの実サーバーが、それぞれマスターサーバーおよびスレーブサーバーとして稼働している状態から、例えば、ローカルの端末からのアクセスが集中して負荷が大きくなったり、ネットワークの通信速度が低下するなどして、クラウドの仮想マシンの仮想サーバー（マスターサーバー）の応答が遅くなった場合に、スレーブサーバーをキャッシュサーバーとして用いる運用（図１−２−３に示す第２の運用形態）に切換える例について、説明する。通常稼働時には、図１−１に示す全体構成図において、クラウド１００の仮想マシンの仮想サーバー１３０にデータ元本があり（すなわちマスターサーバー）、ローカル２００のファイルサーバーにコピーデータが設けられ（すなわちスレーブサーバー）、クラウド１００にバックアップサーバー１５０がある。端末２３０はローカル１００にある他、遠隔値からネットワーク接続するものがあってもよい。これらのサーバーの場所や役割が管理サーバー１１０の管理情報で管理される。この場合の管理情報の例を図４−５に示す。
【００５４】
この状態から、例えば端末からのアクセスが集中して負荷が大きくなったり、ローカルとクラウドをつなぐネットワークのトラフィックが増えてレスポンス遅延が生じたりしたような場合に、管理サーバー１１０がそれまでスレーブサーバーとして用いていたローカル２００のファイルサーバー２２０をキャッシュサーバーに代替させる処理を行う。図３−８は、このような実施例の切り替え処理を説明するためのフローチャートである。
【００５５】
図３−８に示すように、例えば上記のような運用形態の切替条件が満たされた場合、あるいは端末２１０のオペレーターかシステム管理者による特別な入力指示があった場合、または端末２１０から管理サーバーにログインした場合に、クラウド１００の管理サーバー１１０はアクセスロック処理を行い（Ｓ８−１）、端末２１０の情報に基づいて管理情報が更新される（Ｓ８−２）。管理サーバー１１０から端末２１０に使用可能アカウントを通知する。次に、クラウドの管理サーバー１１０が管理している資源のうち利用可能なサーバーの一覧をオペレーターに提示し（図６参照）、切り替え先のサーバーの選択を受け付ける（Ｓ８−３）。この場合に図５−３に示す確認画面が提示されてもよい。管理サーバー１１０はローカル２００の実マシンのファイルサーバー２２０のアクセスロック処理を行い（Ｓ８−４）、この実マシンを無効にしたうえで、実マシンの役割をファイルサーバーからキャッシュサーバーへと切り替え（図４−５の番号２の「役割」の「ファイルＳＶ」から、図４−６の番号２の「役割」の「キャッシュＳＶ」に書き換え）、実マシンを有効にして管理情報の内容を更新する（Ｓ８−５）。また、管理サーバー１１０はローカルの実マシンのコピーデータを削除し（Ｓ８−６）、またローカルのキャッシュサーバーへのアクセスロック処理を行う（Ｓ８−７）。その後に管理サーバー１１０のアクセスアンロック処理を行い（Ｓ８−８）、使用端末２１０が管理サーバー１１０からログアウトする（Ｓ８−９）。この状態の管理情報の例を、図４−６に示す。この管理情報と、図１−２−３に示すように、仮想サーバー１３０にデータ元本があり、バックアップサーバー１５０にバックアップデータがとられ、ローカルの実サーバーはキャッシュサーバー２３０となった第２の運用形態となる。ここからさらにマスタサーバー（仮想サーバー１３０）やネットワークに障害が生じた場合には、図１−２−４に示す障害時の運用形態に切り替わってもよい。
【００５６】
また、管理情報テーブル（図４−１、図４−３など）の管理情報の遷移（変化）を、日時等と共に、ログとして記録し、後で、クラウド側のシステム管理者や、ローカル側のシステム管理者などが、一覧表示で確認することができる。また、管理情報の遷移（変化）のログに基づいて、故障した装置の状況やネット障害、クラウド側の仮想マシンの仮想サーバーの障害発生の状況を集約、集計した一覧表を生成する等して、故障や障害の発生状況ないし稼働率の把握が可能となる。また、時間帯による端末接続数の推移の傾向や、ネットワーク障害の発生状況、あるいはクラウド側の仮想マシンの仮想サーバーなどの稼働率の状況や、ローカルの実マシンの実サーバーの稼働率や故障率などの情報を、運用ポリシーにフィードバックして反映し、第１の運用形態と第２の運用形態の切り替えの基準とすることもできる。
【００５７】
ここで、障害発生の内容としては、上記で説明した、ローカルの実サーバーの障害や、ネットワーク障害、クラウドの仮想サーバーの障害のほか、以下のような例が考えられる。
【００５８】
まず、第１の運用形態において運用する際に、ローカルの実サーバーの障害時に、さらにネットワーク障害や管理サーバーの障害が発生したような場合がある（単体機で運用する状態）。
【００５９】
この場合、通常、利用者が会計事務所の実機ＰＣ１（単体機）を起動してログインし、クラウド（ＩＤＣセンター）の管理サーバーにアクセスする際、ここで管理サーバーに障害が発生している場合、最新のアプリ情報と最新の管理情報が入手できないので、実機ＰＣ１（単体機）に保存している現状の古いアプリと現状の古い管理情報を元にアプリを起動し、元本データにアクセスして入力処理を行う。
【００６０】
その後管理サーバーの障害が解消し、最新のアプリ情報が入手できるようになったとき、古いアプリで開いた入力中のデータがあった場合、古いアプリのまま登録処理を行い、古いアプリを終了させる。そのうえで管理サーバーに接続して最新のアプリを実機ＰＣ１（単体機）にダウンロード、インストールし、その後通常の処理を行う。
【００６１】
あるいは、アプリを起動する前から通信障害が発生した場合、利用者が会計事務所の実機ＰＣ１（単体機）を起動してログインし、管理サーバーにアクセスしようとしても通信障害が発生しているため、最新のアプリ情報と最新の管理情報が入手できないので、実機ＰＣ１（単体機）に保存している現状のアプリと現状の管理情報を元にデータ管理アプリが起動し、データ管理メニューを表示する。
【００６２】
データ管理メニューには、前回の上で管理場所が「センター」になっている箇所がグレーアウトするとともに「通信障害が発生したので、番号１．実機ＰＣ１のコピーデータを元本データに切り替えますか？」と確認メッセージが出るので、それに同意すると実機ＰＣ１（単体機）のコピーデータが元本データに切り替わる。実機ＰＣ１（単体機）は切り替わった実機ＰＣ１（単体機）の元本データに直接アクセスして入力、登録処理を行う。
【００６３】
通信障害が解消し、ＩＤＣセンターとの通信が確立した場合、利用者が会計事務所の実機ＰＣ１（単体機）を起動してログインし、ＩＤＣセンターの管理サーバーにアクセスした時に、データ管理アプリが起動し、データ管理メニューを表示する。データ管理メニュー上で管理場所が「センター」になっている箇所が元の表示に戻り、「通信障害が回復したので、番号１．実機ＰＣ１の元本データを番号２．仮想ＳＶ１に切り替えますか？」と確認メッセージが出るので、それに同意すると実機ＰＣ１（単体機）のコピーデータがＩＤＣサーバーの仮想サーバーである仮想ＳＶ１（サーバー）にコピーされ、実機ＰＣ１（単体機）の元本データがコピーデータに切り替わる。
【００６４】
あるいは、第２の運用形態において通常稼働状態で運用する際に、ネットワークは正常だが、ローカルの実マシンの実サーバー（実機サーバー）に障害が発生したような場合がある（クラウドの仮想サーバーと端末とで運用）。
【００６５】
以上、システムの構成要素が有効あるいは無効かに応じて、第１の運用形態や第２の運用形態から、単体機での運用、端末と仮想サーバーとで運用、のいずれかに切替えて運用可能であることを示したが、ネットワーク（インターネット側）の接続が何らかの障害によってオフラインになってしまった場合や、システムの構成要素に障害が発生したときも、同様に運用を切替えて、システムを利用可能である。
【００６６】
例えば、ネットワーク（インターネット側）がオフラインになった場合には、ユーザー端末で利用していたデータの状態を、管理サーバーに問い合わせることなくユーザー端末自身で判断することができる。
【００６７】
より具体的には、例えば、ユーザー端末ないしファイルサーバー（ローカルの実サーバー）と管理サーバーとの間で、ネットワークが接続できず、ユーザー端末ないしファイルサーバー（ローカルの実サーバー）が、オフライン動作に移行する場合や、ファイルサーバー（クラウドの仮想サーバー）を含むシステムの構成要素のいずれかで障害が発生した場合おいて、オフラインと判断する場合には、処理対象のデータが元本データであるか元本データのコピー（更新前データ）であるかであるかどうかを、管理サーバーに問い合わせる代りに、ユーザー端末の制御部ないし、ファイルサーバー（ローカルの実サーバー）の制御部により、自立的に判定を行ない、システムの利用を継続することができる。
【００６８】
あるいは、ファイルサーバー（クラウドの仮想サーバー）において障害が発生と判断する場合において、ユーザー端末における、処理対象のデータが元本データのコピー（更新前データ）である場合には、元本データのコピー（更新前データ）を、一時的に、元本データであるとして取り扱い（単体機での運用と同様の処理に暫定的に移行）、システムの利用を継続することができる。
【００６９】
この場合、ユーザー端末において、元本データないし元本データのコピー（更新前データ）を用いて、データの更新処理を行ない、作成し終わった更新後データを、ネットワークの接続が回復した後に、元本データの格納場所として設定された、システム構成のうちアクティブな構成要素（仮想サーバー等）に対して返却する。
【００７０】
このように、オフラインで使用できなくなったシステムの構成要素、あるいは障害が発生したシステムの構成要素に応じて、元本データの管理場所と元本データのコピーの管理場所を切替えて動的に運用できる。
【００７１】
また、ユーザーは元本データの管理場所を自由に設定でき、あるいは障害発生が発生した場合には、障害が発生したシステムの構成要素に応じて、一時的に元本データの管理場所を動的に切替えることができる。つまり、設定した元本データ及び元本のコピーデータの管理場所や、システムの構成要素の有効無効に応じて、様々な形態に合わせて機動的に運用できる統合的な新しいサービスを提供することができる。
【００７２】
このように、本発明では図１−１に示すいずれかのサーバーが存在しなくてもよく、また図示する他に他の仮想サーバーまたは実サーバーが、クラウドまたはローカルに存在してもよい。これらのサーバーの情報および役割が管理サーバー１１０の管理情報で管理され、障害発生状況や運用ポリシーに応じて適宜ファイルサーバー（マスターまたはスレーブ）、キャッシュサーバー、バックアップサーバー等の役割を切り替えて運用することができる。これにより、冗長性を確保するとともに、状況に応じて最適なシステム運用を行うことが可能となる。
【産業上の利用可能性】
【００７３】
本発明は、アプリケーションデータをローカルおよび／またはクラウドのサーバーから利用する情報処理産業に利用することができる。
【符号の説明】
【００７４】
１００  クラウド（ＩＤＣ）
１１０  管理サーバー
１２０  アプリサーバー
１３０  仮想サーバー
１４０  仮想マシン
１５０  バックアップサーバー
２００  ローカル（事務所）
２１０  端末
２２０  ファイルサーバー
２３０  キャッシュサーバー
【図１−１】
2017182380.tif 000003
【図１−２−１】
2017182380.tif 000004
【図１−２−２】
2017182380.tif 000005
【図１−２−３】
2017182380.tif 000006
【図１−２−４】
2017182380.tif 000007
【図２−１】
2017182380.tif 000008
【図２−２】
2017182380.tif 000009
【図２−３】
2017182380.tif 000010
【図２−４】
2017182380.tif 000011
【図２−５】
2017182380.tif 000012
【図２−６】
2017182380.tif 000013
【図２−７】
2017182380.tif 000014
【図３−１−１】
2017182380.tif 000015
【図３−１−２】
2017182380.tif 000016
【図３−２】
2017182380.tif 000017
【図３−３】
2017182380.tif 000018
【図３−４−１】
2017182380.tif 000019
【図３−４−２】
2017182380.tif 000020
【図３−５】
2017182380.tif 000021
【図３−６−１】
2017182380.tif 000022
【図３−６−２】
2017182380.tif 000023
【図３−７】
2017182380.tif 000024
【図３−８】
2017182380.tif 000025
【図４−１】
2017182380.tif 000026
【図４−２】
2017182380.tif 000027
【図４−３】
2017182380.tif 000028
【図４−４】
2017182380.tif 000029
【図４−５】
2017182380.tif 000030
【図４−６】
2017182380.tif 000031
【図５−１】
2017182380.tif 000032
【図５−２−１】
2017182380.tif 000033
【図５−２−２】
2017182380.tif 000034
【図５−３】
2017182380.tif 000035
【図６】
2017182380.tif 000036
【手続補正書】
【提出日】平成29年6月2日(2017.6.2)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
クラウドの高速ネットワークに接続された、各サーバーの役割を規定する管理情報を保持し障害発生時に大体サーバーへの切り替え動作を制御するクラウドの管理サーバーと、クラウドのバックアップサーバーと、障害発生時に生成されるクラウドの仮想サーバー用仮想マシンである仮想代替サーバーとで構成されるクラウド上の各装置と、
ローカルの高速ネットワークに接続された、ローカルの実マシンの実ファイルサーバーと、１以上のローカルの実端末とで構成されるローカル上の各装置と、
各装置が接続されたクラウド上の高速ネットワークと各装置が接続されたローカル上の高速ネットワーク間が、低速なネットワークで接続されているデータ管理システムにおいて、
前記クラウドの管理サーバーの管理情報は、元本やコピーを含むデータの属性、各装置の設置場所がクラウドかローカルかの管理場所、および各装置が仮想サーバーか実サーバーか端末かの役割を少なくとも備え、通常運用時に、前記ローカルの実マシンの実サーバーを主サーバーとして運用すべく規定されており、
前記ローカルの実マシンの実ファイルサーバーのデータを、前記クラウドのバックアップサーバーにバックアップする第１のバックアップ手段と、
前記ローカルの実マシンの実ファイルサーバーに障害が発生した場合に、前記クラウドの管理サーバーの前記管理情報に、前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーを生成し、前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーを仮想代替サーバーとして運用させるための情報に更新すると共に、前記クラウドのバックアップサーバーのバックアップデータを使用して、前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーに前記ローカルの実マシンの実ファイルサーバーのデータを復元した前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーを一時的なファイルサーバーとしてセットアップしたうえでシステムを起動し、システム利用を継続させる障害時回復手段と、
前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーの起動後に、前記ローカルの実マシンの実ファイルサーバーの代替として、前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーを一時的なファイルサーバーとして設定し運用する際に、前記クラウドの管理サーバーの管理情報に基づいて、前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーの設置場所と前記ローカルの実端末の設置場所がクラウドとローカルで異なり高速の通信速度を確保できない場合に、前記ローカルの実端末からファイルサーバーにアクセスする際のアクセス先を前記実ファイルサーバーから前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーに一時的なファイルサーバーとして切り替え、前記ローカルの実端末と前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーとの間のアクセス方式を前記クラウドの管理サーバーの管理情報から通信状況や設置場所に応じてサーバーとオンラインで直接通信するリモート接続方式と、必要なファイルをダウンロードしてローカルでコピーデータを直接操作して終了後にアップロードして登録するファイル転送方式とに自動的に切り替える手段と、
前記ローカルの実端末において、ローカルの実端末のコピーデータに更新が発生した場合には、前記管理情報に基づいてデータのアクセス方式を、前記サーバーとオンラインで直接通信するリモート接続方式ではなく、前記必要なファイルをダウンロードしてローカルで直接操作して終了後にアップロードして登録するファイル転送方式を利用して、前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーの元本データを更新させる前記管理情報の役割とデータの属性の更新内容に応じた更新手段と、を備えることで、
前記ローカルの実端末と、一時的なファイルサーバーとしての前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーがそれぞれの役割を担い、役割に応じたデータの管理と共に用いられるアクセス先に応じた最適なアクセス方式の利用により、
前記ローカルの実端末と前記仮想代替サーバーを、障害発生時の各サーバーと実端末の役割及びデータの取り扱いを自動的に切り替えることでシステム利用を継続させることを特徴とするデータ管理システム。
【請求項２】
請求項１に記載のデータ管理システムにおいて、さらに、
前記ローカルの実マシンの実ファイルサーバーの障害が復旧したときに、システムを通常運用状態に回復させるための手段として、
前記管理サーバーの管理情報に基づいて、データ復旧先として利用可能なサーバーとして、前記障害が発生したローカルの実マシンの実ファイルサーバーを修理した実サーバー、ローカル又はクラウドの別の実サーバー、およびローカル又はクラウドの仮想サーバーの中から、データ復旧先のサーバーを選択するための復旧先サーバー選択手段と、
前記一時的なファイルサーバーとして運用していた前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーのデータの更新内容を、前記バックアップサーバーにバックアップする手段と、
前記バックアップサーバーのバックアップデータを、前記復旧先として選択したサーバーにリストアするとともに、当該リストア後に、前記管理サーバーの管理情報に、主サーバーを、前記一時的なファイルサーバーとして運用していた前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーから、前記復旧先として選択したサーバーに切り換えるための情報を書き込み、システムを通常運用状態に復旧させる復旧時リストア手段と、を備えることを特徴とするデータ管理システム。
【請求項３】
請求項１又は２に記載のデータ管理システムにおいて、
前記クラウドの管理サーバーとして仮想的に構築された管理サーバーを用い、
前記クラウドのバックアップサーバーとして仮想的に構築されたバックアップサーバーを用い、
前記ローカルの実マシンの実ファイルサーバーに替えて仮想的に構築されたサーバーを用いて、
運用することを特徴とするデータ管理システム。
【請求項４】
各サーバーの役割を規定する管理情報を保持するクラウドの管理サーバーと、クラウドのバックアップサーバーと、クラウドの仮想サーバー用仮想マシンと、ローカルの実マシンの実サーバーと、１以上のローカルの端末とがネットワークで接続されたデータ管理システムにおいて、
前記管理サーバーの管理情報には、通常運用時に前記ローカルの実マシンの実サーバーを主サーバーとして運用する第１の運用形態と、通常運用時に前記クラウドの仮想マシンの仮想サーバーを主サーバーとし前記ローカルの実マシンの実サーバーをキャッシュサーバーとして運用する第２の運用形態とが登録されており、前記管理サーバーは、主サーバーに接続する前記ローカルの端末が所定数以下の場合に前記第１の運用形態で運用し、前記ローカルの端末数が前記所定数を越えたら前記第２の運用形態で運用するように前記管理情報を切り替え、
前記第１の運用形態のシステム構成として、
前記ローカルの主サーバーのデータを、前記クラウドのバックアップサーバーにバックアップする第１のバックアップ手段と、
ローカルの主サーバーに障害が発生した場合に、前記管理サーバーの管理情報に、前記クラウドの仮想サーバー用仮想マシンから仮想サーバーを生成し、前記仮想マシンの仮想サーバーを主サーバーとしての運用させるための情報を書き込むと共に、前記クラウドのバックアップサーバーのバックアップデータを使用して、前記クラウドの仮想サーバー用仮想マシンの仮想サーバーに前記ローカルの主サーバーのデータを復元し、前記仮想マシンの仮想サーバーを一時的な主サーバーとして、システム利用を継続させる障害時リストア手段と、
リストア後に、前記１以上のローカルの端末から前記クラウドの仮想サーバー用仮想マシンの仮想サーバーにアクセスする際のアクセス方式を、前記通常運用時のリモート接続方式に替えてファイル転送方式に切替えるアクセス変更手段と、
を備え、前記ローカルの主サーバーの障害発生の際に、クラウドのバックアップサーバーを用いてシステム利用を継続させ、
前記第２の運用形態のシステム構成として、
前記ローカルのキャッシュサーバーが、
前記クラウドの主サーバーのデータおよび前記管理サーバーの管理情報を当該キャッシュサーバーにキャッシュして前記１以上のローカルの端末に利用させるキャッシュ手段と、
前記ネットワークの通信障害又は前記仮想マシンの主サーバーに障害が発生した場合に、前記ローカルのキャッシュサーバーのデータを元に、当該ローカルのキャッシュサーバー上に、前記管理サーバーの管理情報と、前記クラウドの仮想サーバーの元本データの少なくとも一部を復元して、元本の部分的なコピーデータとすることにより、そのままでは直接操作できない当該元本の部分的なキャッシュデータを、直接操作できる元本データの部分的なコピーデータとして取り扱い、一時的に、前記ローカルのキャッシュサーバーを一時的な主サーバーとして運用すべく前記管理情報を書き換えるリカバリ手段と、
を備え、通信障害、または前記主サーバーの障害発生時にシステム利用を継続させることを特徴とするデータ管理システム。
【請求項５】
請求項４に記載のデータ管理システムにおいて、さらに、前記第２の運用形態の運用時に、
前記ネットワークの通信障害又は前記仮想マシンの主サーバーの障害が回復した場合に、前記一時的な主サーバーとして運用していた前記ローカルのキャッシュサーバーのデータの更新内容を、前記クラウドの仮想マシンの仮想サーバーに反映させる障害復旧処理手段を備えることを特徴とするデータ管理システム。
【請求項６】
請求項４又は５に記載のデータ管理システムにおいて、前記管理サーバーの管理情報にはさらに、前記クラウドの仮想サーバー用仮想マシンと前記ローカルの実マシンの実サーバーのうち、いずれか一方をマスターサーバー、他方をスレーブサーバーとして、サーバー２台構成で運用する第３の運用形態が登録されており、
前記管理サーバーが、前記第２の運用形態での運用時に、さらに前記ローカルの端末の負荷や、前記ネットワークの通信速度を含む環境条件に基づいて、前記第２の運用形態から前記第３の運用形態に切り替えることを特徴とするデータ管理システム。
【請求項７】
クラウドの高速ネットワークに接続された、各サーバーの役割を規定する管理情報を保持し障害発生時に大体サーバーへの切り替え動作を制御するクラウドの管理サーバーと、クラウドのバックアップサーバーと、障害発生時に生成されるクラウドの仮想サーバー用仮想マシンである仮想代替サーバーとで構成されるクラウド上の各装置と、
ローカルの高速ネットワークに接続された、ローカルの実マシンの実ファイルサーバーと、１以上のローカルの実端末とで構成されるローカル上の各装置と、
各装置が接続されたクラウドの高速ネットワークと各装置が接続されたローカルの高速ネットワーク間が、低速なネットワークで接続されているデータ管理システムの運用方法において、
前記クラウドの管理サーバーの管理情報は、元本やコピーを含むデータの属性、各装置の設置場所がクラウドかローカルかの管理場所、および各装置が仮想サーバーか実サーバーか端末かの役割を少なくとも備え、
通常運用時に、前記管理サーバーが、前記ローカルの実マシンの実サーバーを主サーバーとして運用するよう前記管理情報を設定し、
前記クラウドのバックアップサーバーが、前記ローカルの実マシンの実ファイルサーバーのバックアップを保存し、
前記ローカルの実マシンの実ファイルサーバーに障害が発生した場合に、
前記クラウドの管理サーバーが、前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーを生成し、前記仮想マシンの仮想代替サーバーを主サーバーとして運用させるよう前記管理情報を更新すると共に、前記クラウドのバックアップサーバーのバックアップデータを使用して、前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーに前記ローカルの実マシンの実ファイルサーバーのデータを復元した前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーを一時的なファイルサーバーとしてセットアップしたうえでシステムを起動し、システム利用を継続させ、
前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーの起動後に、前記ローカルの実マシンの実ファイルサーバーの代替として、前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーを一時的なファイルサーバーとして設定し運用する際に、前記クラウドの管理サーバーの管理情報に基づいて、前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーの設置場所と前記ローカルの実端末の設置場所がクラウドとローカルで異なり高速の通信速度を確保できないと判定される場合に、前記ローカルの実端末からファイルサーバーにアクセスする際のアクセス先を前記実ファイルサーバーから前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーに一時的なファイルサーバーとして切り替え、
前記ローカルの実端末が、ローカルの実端末のコピーデータに更新が発生した場合には、前記管理情報に基づいてデータのアクセス方式を、前記サーバーとオンラインで直接通信するリモート接続方式から、前記必要なファイルをダウンロードしてローカルで直接操作して終了後にアップロードして登録するファイル転送方式を利用して、前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーの元本データを更新させ、
前記ローカルの実端末と、一時的なファイルサーバーとしての前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーがそれぞれの役割を担い、役割に応じたデータの管理と共に用いられるアクセス先に応じた最適なアクセス方式の利用により、前記ローカルの実端末と前記仮想代替サーバーを、障害発生時の各サーバーと実端末の役割及びデータの取り扱いを自動的に切り替えることでシステム利用を継続させることを特徴とするデータ管理システムの運用方法。
【請求項８】
請求項７に記載の方法において、さらに、
前記ローカルの実マシンの実ファイルサーバーの障害が復旧したときに、
前記管理サーバーが、前記管理情報に基づいて、前記障害が発生したローカルの実マシンの実ファイルサーバーを修理した実サーバー、ローカル又はクラウドの別の実サーバー、およびローカル又はクラウドの仮想サーバーの中から、データ復旧先のサーバーを選択し、
前記バックアップサーバーが、前記一時的なファイルサーバーとして運用していた前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーのデータの更新内容をバックアップし、
前記バックアップサーバーのバックアップデータを、前記復旧先として選択したサーバーにリストアするとともに、当該リストア後に、前記管理サーバーが管理情報に、主サーバーを、前記一時的なファイルサーバーとして運用していたクラウドの仮想サーバー用仮想マシンである仮想代替サーバーから、前記復旧先として選択したサーバーに切り換えるよう前記管理情報を更新し、システムを通常運用状態に復旧させることを特徴とするデータ管理システムの運用方法。
【請求項９】
請求項７又は８に記載の方法において、
前記クラウドの管理サーバーとして仮想的に構築された管理サーバーを用い、
前記クラウドのバックアップサーバーとして仮想的に構築されたバックアップサーバーを用い、
前記ローカルの実マシンの実ファイルマシンの実サーバーに替えて仮想的に構築されたサーバーを用いて、
運用することを特徴とするデータ管理システムの運用方法。
【請求項１０】
各サーバーの役割を規定する管理情報を保持するクラウドの管理サーバーと、クラウドのバックアップサーバーと、クラウドの仮想サーバー用仮想マシンと、ローカルの実マシンの実サーバーと、１以上のローカルの端末とがネットワークで接続されたデータ管理システムの運用方法において、
前記管理サーバーの管理情報には、通常運用時に前記ローカルの実マシンの実サーバーを主サーバーとして運用する第１の運用形態と、通常運用時に前記クラウドの仮想マシンの仮想サーバーを主サーバーとし、前記ローカルの実マシンの実サーバーをキャッシュサーバーとして運用する第２の運用形態とが登録されており、前記管理サーバーは、主サーバーに接続する前記ローカルの端末が所定数以下の場合に前記第１の運用形態で運用し、前記ローカルの端末数が前記所定数を越えたら前記第２の運用形態で運用するように前記管理情報を切り替え、
前記第１の運用形態での運用時に、前記管理サーバーが、
前記ローカルの主サーバーのデータを、前記クラウドのバックアップサーバーにバックアップし、
ローカルの主サーバーに障害が発生した場合に、前記管理サーバーの管理情報に、前記クラウドの仮想サーバー用仮想マシンから仮想サーバーを生成し、前記仮想マシンの仮想サーバーを主サーバーとしての運用させるための情報を書き込むと共に、前記クラウドのバックアップサーバーのバックアップデータを使用して、前記クラウドの仮想サーバー用仮想マシンの仮想サーバーに前記ローカルの主サーバーのデータを復元し、前記仮想マシンの仮想サーバーを一時的な主サーバーとして、システム利用を継続させ、
リストア後に、前記１以上のローカルの端末から前記クラウドの仮想サーバー用仮想マシンの仮想サーバーにアクセスする際のアクセス方式を、前記通常運用時のリモート接続方式に替えてファイル転送方式に切替えて、前記ローカルの主サーバーの障害発生の際に、クラウドのバックアップサーバーを用いてシステム利用を継続させ、
前記第２の運用形態での運用時に、
前記管理サーバーが、通常時の設定として、前記クラウドの仮想マシンの仮想サーバーを主サーバーとし、前記ローカルの実マシンの実サーバーをキャッシュサーバーとして運用するよう前記管理情報を設定し、
前記ローカルのキャッシュサーバーが、前記クラウドの主サーバーのデータおよび前記管理サーバーの管理情報を当該キャッシュサーバーにキャッシュして前記１以上のローカルの端末に利用させ、
前記ネットワークの通信障害又は前記仮想マシンの主サーバーに障害が発生した場合に、前記キャッシュサーバーが、前記ローカルのキャッシュサーバーのデータを元に、当該ローカルのキャッシュサーバー上に、前記管理サーバーの管理情報と、前記クラウドの仮想サーバーの元本データの少なくとも一部を復元して、元本の部分的なコピーデータとすることにより、そのままでは直接操作できない当該元本の部分的なキャッシュデータを、直接操作できる元本データの部分的なコピーデータとして取り扱い、一時的に、前記ローカルのキャッシュサーバーを一時的な主サーバーとして運用すべく前記管理情報を書き換えることを特徴とするデータ管理システムの運用方法。
【請求項１１】
請求項１０に記載の方法において、さらに、前記第２の運用形態の運用時に、
前記ネットワークの通信障害又は前記仮想マシンの主サーバーの障害が回復した場合に、前記ローカルのキャッシュサーバーが、前記一時的な主サーバーとして運用していた前記ローカルのキャッシュサーバーのデータの更新内容を、前記クラウドの仮想マシンの仮想サーバーに反映させることを特徴とするデータ管理システムの運用方法。
【請求項１２】
請求項１０又は１１に記載の方法において、前記管理サーバーの管理情報にはさらに、前記クラウドの仮想マシンの仮想サーバーと前記ローカルの実マシンの実サーバーのうち、いずれか一方をマスターサーバー、他方をスレーブサーバーとして、サーバー２台構成で運用する第３の運用形態が登録されており、
前記管理サーバーが、前記第２の運用形態での運用時に、さらに前記ローカルの端末の負荷や、前記ネットワークの通信速度を含む環境条件に基づいて、前記第２の運用形態から前記第３の運用形態に切り替えることを特徴とするデータ管理システムの運用方法。
【手続補正書】
【提出日】平成29年8月17日(2017.8.17)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項１
【補正方法】変更
【補正の内容】
【請求項１】
クラウドの高速ネットワークに接続された、各サーバーの役割を規定する管理情報を保持し障害発生時に代替サーバーへの切り替え動作を制御するクラウドの管理サーバーと、クラウドのバックアップサーバーと、障害発生時に生成されるクラウドの仮想サーバー用仮想マシンである仮想代替サーバーとで構成されるクラウド上の各装置と、
ローカルの高速ネットワークに接続された、ローカルの実マシンの実ファイルサーバーと、１以上のローカルの実端末とで構成されるローカル上の各装置と、
各装置が接続されたクラウド上の高速ネットワークと各装置が接続されたローカル上の高速ネットワーク間が、低速なネットワークで接続されているデータ管理システムにおいて、
前記クラウドの管理サーバーの管理情報は、元本やコピーを含むデータの属性、各装置の設置場所がクラウドかローカルかの管理場所、および各装置が仮想サーバーか実サーバーか端末かの役割を少なくとも備え、通常運用時に、前記ローカルの実マシンの実サーバーを主サーバーとして運用すべく規定されており、
前記ローカルの実マシンの実ファイルサーバーのデータを、前記クラウドのバックアップサーバーにバックアップする第１のバックアップ手段と、
前記ローカルの実マシンの実ファイルサーバーに障害が発生した場合に、前記クラウドの管理サーバーの前記管理情報に、前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーを生成し、前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーを仮想代替サーバーとして運用させるための情報に更新すると共に、前記クラウドのバックアップサーバーのバックアップデータを使用して、前記仮想代替サーバーに前記ローカルの実マシンの実ファイルサーバーのデータを復元した一時的なファイルサーバーとしてセットアップしたうえでシステムを起動させる障害時回復手段と、
前記仮想代替サーバーの起動後に、前記クラウドの管理サーバーの管理情報に基づいて、前記仮想代替サーバーの設置場所と前記端末の設置場所がクラウドとローカルで異なる場合に、前記ローカルの実端末からファイルサーバーにアクセスする際のアクセス先を前記実ファイルサーバーから前記クラウドの仮想代替サーバーに切り替え、前記ローカルの実端末と前記仮想代替サーバーとの間のアクセス方式を前記クラウドの管理サーバーの管理情報から設置場所に応じてサーバーとオンラインで直接通信するリモート接続方式から、必要なファイルをダウンロードしてローカルでコピーデータを直接操作して終了後にアップロードして登録するファイル転送方式へ自動的に切り替える手段と、
前記ローカルの実端末において、コピーデータに更新が発生した場合には、前記管理情報に基づいてデータのアクセス方式を、前記サーバーとオンラインで直接通信するリモート接続方式ではなく、前記必要なファイルをダウンロードしてローカルで直接操作して終了後にアップロードして登録するファイル転送方式を利用して、前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーの元本データを更新させる更新手段と、を備えることで、
前記ローカルの実端末と、一時的なファイルサーバーとしての前記クラウドの仮想代替サーバーがそれぞれの役割を担い、役割に応じたデータの管理と共に用いられるアクセス先に応じた最適なアクセス方式の利用により、障害発生時の各サーバーと実端末の役割及びデータの取り扱いを自動的に切り替えることでシステム利用を継続させることを特徴とするデータ管理システム。
【手続補正２】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項７
【補正方法】変更
【補正の内容】
【請求項７】
クラウドの高速ネットワークに接続された、各サーバーの役割を規定する管理情報を保持し障害発生時に代替サーバーへの切り替え動作を制御するクラウドの管理サーバーと、クラウドのバックアップサーバーと、障害発生時に生成されるクラウドの仮想サーバー用仮想マシンである仮想代替サーバーとで構成されるクラウド上の各装置と、
ローカルの高速ネットワークに接続された、ローカルの実マシンの実ファイルサーバーと、１以上のローカルの実端末とで構成されるローカル上の各装置と、
各装置が接続されたクラウドの高速ネットワークと各装置が接続されたローカルの高速ネットワーク間が、低速なネットワークで接続されているデータ管理システムの運用方法において、
前記クラウドの管理サーバーの管理情報は、元本やコピーを含むデータの属性、各装置の設置場所がクラウドかローカルかの管理場所、および各装置が仮想サーバーか実サーバーか端末かの役割を少なくとも備え、
通常運用時に、前記管理サーバーが、前記ローカルの実マシンの実サーバーを主サーバーとして運用するよう前記管理情報を設定し、
前記クラウドのバックアップサーバーが、前記ローカルの実マシンの実ファイルサーバーのバックアップを保存し、
前記ローカルの実マシンの実ファイルサーバーに障害が発生した場合に、
前記クラウドの管理サーバーが、前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーを生成し、前記仮想マシンの仮想代替サーバーを主サーバーとして運用させるよう前記管理情報を更新すると共に、前記クラウドのバックアップサーバーのバックアップデータを使用して、前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーに前記ローカルの実マシンの実ファイルサーバーのデータを復元した前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーを一時的なファイルサーバーとしてセットアップしたうえでシステムを起動し、
前記仮想代替サーバーの起動後に、前記クラウドの管理サーバーの管理情報に基づいて、前記クラウドの仮想代替サーバーの設置場所と前記実端末の設置場所がクラウドとローカルで異なる場合に、前記ローカルの実端末からファイルサーバーにアクセスする際のアクセス先を前記実ファイルサーバーから前記クラウドの仮想サーバー用仮想マシンである仮想代替サーバーに切り替え、
前記ローカルの実端末が、コピーデータに更新が発生した場合には、前記管理情報に基づいてデータのアクセス方式を、前記サーバーとオンラインで直接通信するリモート接続方式から、前記必要なファイルをダウンロードしてローカルで直接操作して終了後にアップロードして登録するファイル転送方式を利用して、前記仮想代替サーバーの元本データを更新させ、
前記ローカルの実端末と、一時的なファイルサーバーとしての前記クラウドの仮想代替サーバーがそれぞれの役割を担い、役割に応じたデータの管理と共に用いられるアクセス先に応じた最適なアクセス方式の利用により、障害発生時の各サーバーと実端末の役割及びデータの取り扱いを自動的に切り替えることでシステム利用を継続させることを特徴とするデータ管理システムの運用方法。