JP7260801B2 - バックアップシステム及びその方法並びにプログラム - Google Patents

Description

特許法第３０条第２項適用 （１）２０１９年４月１１日、電子情報通信学会 信学技報 ネットワークシステム研究会（ＮＳ） ｖｏｌ．１１９ Ｎｏ．５ ＮＳ２０１９－１３ ｐｐ．７３－７７において発表した。

本発明は、ネットワーク内のあるノードに配備されたストレージに格納されたデータを他のノードに配備されたストレージに格納するバックアップシステムに関する。

近年、映像ＩｏＴ（Internet of Things）の普及によって、店舗の防犯や動物の生態記録等、様々な目的で監視カメラを配置し、作成した映像ファイル（以下、単に「ファイル」と言う）をネットワーク経由で拠点（ノード）にあるストレージに長期保存し、遠隔地にて映像の視聴や解析等を行うことが可能となってきている。

ここで、ストレージ故障などによってファイルが消失することを防ぐため、同一拠点の別ストレージまたは別拠点のストレージにレプリケーションすることが行われている。特に災害回避を想定したケースでは、複数拠点（例えば、複数データセンタ）にファイルをレプリケーションすることで災害によるファイルの消失を回避している。国内であれば５００ｋｍ（例えば、東京－大阪間）離隔しているデータセンタ、国外であれば他の国のデータセンタにレプリケーションすることで災害によるファイル消失を回避できると考えられる。

Qasmi, Wasiq Noor Ahmad, et al. "A comparative study of failover schemes for IaaS recovery." Information Networking (ICOIN), 2018 International Conference on. IEEE, 2018 Li, Xiaole, et al. "Redundancy-Guaranteed and Receiving-Constrained Disaster Backup in Cloud Data Center Network." IEEE Access 6 (2018): 47666-47681 Ferdousi, Sifat, et al. "Disaster-aware data-center and content placement in cloud networks." 2013 IEEE International Conference on Advanced Networks and Telecommunications Systems (ANTS). IEEE, 2013. Alshammari, Mohammad M., et al. "Disaster recovery in single-cloud and multi-cloud environments: Issues and challenges." 2017 4th IEEE International Conference on Engineering Technologies and Applied Sciences (ICETAS). IEEE, 2017.

しかし、レプリケーションによりファイルを保管するリソース（ストレージ）、すなわちレプリケーション先となる拠点は広域に多数分散しているため、想定する災害に応じて物理的なレプリケーション先を選定することが困難である。また、物理的なレプリケーション先を決定したとしても、実際にレプリケーションを実施しようとした際に、当該レプリケーション先の残りリソースが少なくなっていることを原因として、レプリケーションできないことがある。

一方、バックアップ箇所へのアクセス方法（非特許文献１）やバックアップ手法（非特許文献２）については既存技術がある。しかし、非特許文献１には、アプリケーションのフェイルオーバー方法は予め決められたバックアップ箇所へのどのようにアクセスするかのみ記載されているが、物理的な振り分け先を指定する技術には記載されていない。また、非特許文献２には、帯域利用状況を考慮して送る順番とスループットをどのように設定するか記載されているが、こちらも物理的に配置する内容は記載されていない。

このように、従来、物理的にどこにレプリケーションするかを決定する方法については確立した技術が存在していなかった。

本発明は上記事情に鑑みてなされたものであり、その目的とするところは、災害を考慮したバックアップ先を決定することができるバックアップシステム及びその方法を提供することにある。

上記目的を達成するために、本願発明は、それぞれストレージが配備された複数のノードを含むネットワークにおいて、第１のノードのストレージに格納されたオリジナルデータを第２のノードのストレージに複製して格納するバックアップシステムであって、災害情報並びにネットワーク情報及びノード情報を取得する情報取得部と、災害情報並びにネットワーク情報及びノード情報に基づき、オリジナルデータが格納されている第１のノードと当該オリジナルデータのバックアップ先の候補となる１以上の第２のノードとの関連付け情報を含むバックアップ先ノード情報を生成するとともに当該バックアップ先ノード情報を所定の記憶部に保存するバックアップ先ノード情報生成部と、オリジナルデータのバックアップを実施する際に、少なくとも前記バックアップ先ノード情報に含まれるバックアップ先の候補となる１以上の第２のノードからバックアップ先の第２のノードを算出するバックアップ先ノード算出部と、オリジナルデータを第１のノードのストレージから前記算出された第２ノードのストレージに複製して格納するバックアップ実行部とを備えたことを特徴とする。

本発明によれば、災害情報を考慮してバックアップ先のノードが決定されるので、適切な災害に強いバックアップシステムを構築できる。また、本発明では、オリジナルデータが格納されている第１のノードと当該オリジナルデータのバックアップ先の候補となる１以上の第２のノードとの関連付け情報を含むバックアップ先ノード情報を予め生成する。そして、オリジナルデータのバックアップの際に、当該バックアップ先ノード情報に含まれるバックアップ先の候補となる１以上の第２のノードからバックアップ先の第２のノードを算出する。これにより、バックアップ先の算出処理では全てのノードについて考慮しなくてよいので当該算出処理の負荷が軽減する。

本発明が想定するネットワーク構成図 本発明の一実施の形態に係るレプリケーションシステムの構成図 本発明の一実施の形態に係るマスターサーバの機能ブロック図 災害情報の一例を説明する図 レプリケーショングループを説明する図 レプリケーショングループ構築処理を説明するフローチャート レプリケーショングループの構築例を示す図 レプリケーション先算出部の処理を説明するフローチャート レプリケーション先の算出例を示す図 レプリケーション実行装置の機能ブロック図 本発明の実施例１を説明する図（レプリケーショングループ構築例１） 本発明の実施例２を説明する図（レプリケーショングループ構築例２） 本発明の実施例３を説明する図（レプリケーション先ノード算出例１） 本発明の実施例４を説明する図（レプリケーション先ノード算出例２） 本発明の実施例５を説明する図（レプリケーション先ノード算出例３） 他の実施形態のマスターサーバの機能ブロック図 他の実施形態のレプリケーション実行装置の機能ブロック図 静的な災害情報によるレプリケーション実行済状態を説明する図 動的な災害情報に対する処理を説明するフローチャート 動的な災害情報を説明する図 動的な災害情報に対する被災判定を説明する図 動的な災害情報に対する実施判定を説明する図 動的な災害情報に対する追加ノードの選定を説明する図 追加ノードへのバックアップを説明する図 優先度を用いた追加ノードへのバックアップを説明する図 優先度を用いた追加ノードへのバックアップを説明する図 追加ノードのテンポラリデータの削除を説明する図

まず、本発明が想定するネットワーク構成について図１を参照して説明する。図１は本発明が想定するネットワーク構成図である。

図１に示すように、ネットワークは複数のノード１０がそれぞれリンク２０により他のノード１０に接続して構成される。各ノード１０にはファイルを保管するストレージ（図示省略）が配備されている。各ノード１０は、地理的に互いに隔離した拠点に対応する。ノード１０は、例えばデータセンタや基地局などが挙げられる。リンク２０は、各ノード１０間を接続する回線である。なお、ネットワークトポロジーについては図１に示すものに限られることなく、メッシュ構造、階層構造、ツリー構造、これらを組み合わせなど何れであってもよい。ネットワークは、単一の事業者網により構成されていてもよいし、複数の事業者網により構成されていてもよいし、インターネットを含んで構成されていてもよい。

ノード１０には、映像ＩｏＴ端末などのようにデータを生成し、ノード１０のストレージに保存する端末１が接続している。換言すれば、アプリケーションレベルにおいて、ノード１０は端末１を収容する。端末１の種別、形態等については不問である。なお、本願では、ノード１０に接続された端末１により生成され、当該端末１に接続しているノード１０のストレージに保存されたデータ（換言すればバックアップの対象となるオリジナルデータ）を、プライマリデータ１２と呼ぶものとする。また、プライマリデータ１２を複製して他のノード１０のストレージに保存されたデータを、レプリケーションデータ１３と呼ぶものとする。

本実施形態に係るバックアップシステムは、プライマリデータ１２のバップアップ先のノード１０の候補を示すグループを予め構築しておき、バックアップ実行時に前記グループの中からバックアップ先のノード１０を算出し、算出したノード１０のストレージにプライマリデータ１２をバックアップする。

なお、本実施形態に係る「バックアップ」は、ノード１０に格納されたデータをリアルタイムにバックアップするレプリケーションであってもよいし、ノード１０に格納されたデータを定期バックアップなどのように定期的又は任意時にバックアップするものであってもよい。以下、本発明の一実施の形態としてレプリケーションシステムについて図面を参照して説明する。

図２は本実施の形態に係るレプリケーションシステムの構成図である。図２に示すように、レプリケーションシステムは、レプリケーションを制御するマスターサーバ１００と、各ノード１０に配備にされたレプリケーション実行装置２００とを備えている。マスターサーバ１００は、各ノード１０と通信可能であればネットワーク内においてどこに配備されていてもよい。マスターサーバ１００及びレプリケーション実行装置２００の実装形態は不問であり、それぞれ専用装置として実装してもよいし、汎用装置やその仮想化環境上にプログラムをインストールして実装してもよいし、また分散して実装してもよい。

図３はマスターサーバの機能ブロック図である。図３に示すように、マスターサーバ１００は、災害情報、ネットワーク情報、ノード情報などの各種データを取得するデータ取得部１１０と、取得したデータを記憶保持するとともに後述するレプリケーショングループ情報を記憶保持する記憶部１２０と、後述するレプリケーショングループを構築するレプリケーショングループ構築部１３０（バックアップ先ノード情報生成部）と、レプリケーション先計算部１４０（バックアップ先ノード算出部）とを備えている。

データ取得部１１０は、所定のクラウドサーバや管理者からの入力により災害情報を取得し記憶部１２０に記憶する。ここで災害情報（静的な災害情報）とは、地震などの災害により被害の発生が予想される地域（災害地域）についての情報であり、エリア情報（どの範囲に災害が発生するか）と強度情報（震度であれば震度７，６強など、津波であれば高さなど）を含む。対象とする災害としては、特定の地震（南海トラフ巨大地震，首都直下大地震等）などの災害だけでなく、当該災害に付随する災害（例えば地震に付随する津波）も加味する。また、災害情報は、震度データや津波データに限らず、ストレージなどが収容されている建物に被害を与えるものであればよい。なお、図４に示すように、ある災害の災害地域と、当該災害に付随する災害の災害地域とは必ずしも一致しない点に留意されたい。図４の例では、震度７地震に係るエリア９１にノードＩＤ「Ａ」及び「Ｂ」のノード１０が含まれ、当該地震７に付随する津波に係るエリア９２にノードＩＤ「Ｂ」及び「Ｃ」のノード１０が含まれていることを示している。災害情報は政府や民間企業がネットワークを介して提供しているので、データ取得部１１０はネットワークを介して取得することができる。

また、データ取得部１１０は、ネットワーク情報を、ネットワークを構成するネットワーク装置やネットワークを管理する管理装置などからネットワークを介して取得するほか、管理者からの入力により取得し、記憶部１２０に記憶する。ここでネットワーク情報は、図１及び図２に示すネットワーク構成を示す情報であり、各ノード１０の地理的な位置情報、各ノード１０間のネットワーク接続状況（ネットワークトポロジー）、各リンク２０の帯域、リンクコスト、各ノード１０間のホップ数などの静的な情報を含む。幾つかの実施例では、各リンク２０の帯域利用率など動的に変化する情報を含むことができる。なお、前記ホップ数はネットワークトポロジーから算出することができるので、記憶部１２０に記憶しなくてもよい。

また、データ取得部１１０は、ノード情報を、各ノード１０に配備された管理装置や各ノード１０を集中管理する管理装置などからネットワークを介して取得するほか、管理者からの入力により取得し、記憶部１２０に記憶する。ここでノード情報は、自ノード１０の識別情報、自ノード１０におけるストレージの各種情報を含む。ストレージの各種情報としては、例えば自ノード１０全体におけるストレージ容量やストレージの書き込み速度などの静的な情報を含む。幾つかの実施例では、残ストレージ容量などの動的に変化する情報を含むことができる。

レプリケーショングループ構築部１３０は、記憶部１２０に記憶された各種情報のうち静的な情報が更新された際に、記憶部１２０に記憶された各種情報に基づきレプリケーショングループを作成し、作成したレプリケーショングループの情報を記憶部１２０に記憶する。

レプリケーショングループについて図５を参照して説明する。レプリケーショングループとは、プライマリデータ１２の保存されたノード１０と、当該プライマリデータ１２のレプリケーション先の候補となる１又は複数のノード１０とを関連づけた（紐付けた）情報を意味する。本実施の形態では、レプリケーショングループ情報は、図５に示すように、複数のノード１０の識別情報を含む順序付きの集合からなり、第１の要素がプライマリデータ１２の保存されたノード１０の識別情報を表し、続く１以上の要素がレプリケーション先の候補となるノード１０の識別情報を表している。グループ内のノード数ｎ＿ｐは、予め記憶部１２０に記憶しておいてもよいし、ＳＬＡ（Service Level Agreement）などに基づいて動的に計算してもよい。なお本願の図面では、必要に応じてレプリケーショングループを「ＲＧ」と省略して表記している。

レプリケーショングループの構築処理について図６を参照して説明する。図６はレプリケーショングループ構築処理を説明するフローチャートである。当該構築処理を実施する契機は、データ取得部１１０によって収集される災害情報の更新時、ネットワーク情報のうち静的な情報の更新時、ノード情報のうち静的な情報の更新時である。

まず、データ取得部１１０は、災害情報、ネットワーク情報、ノード情報を取得する（ステップＳ１）。次に、レプリケーショングループ構築部１３０は、記憶部１２０から、レプリケーション内のノード数ｎ＿ｐと、プライマリデータ１２が格納されるノード１０のノードＩＤを取得する（ステップＳ２）。次に、レプリケーショングループ構築部１３０は、当該ノード１０のレプリケーション先候補を全ノード１０の中から抽出するため、まず、当該ノード１０が災害地域に含まれる災害について当該災害に含まれる他のノード１０を全ノード１０から除外し、さらに所定の選定アルゴリズムにより、残余のノード１０の中からノード数ｎ＿ｐ－１のノード１０をレプリケーション先候補として選定する（ステップＳ３）。以上の処理をプライマリデータ１２が格納されている全ノード１０について実行する（ステップＳ４）。レプリケーショングループ構築部１３０は、生成したレプリケーショングループ情報を記憶部１２０に記憶する。

レプリケーショングループ構築部１３０における前記ステップＳ３の選定処理では、記憶部１２０に記憶されているノード情報を参照して、所定の選定アルゴリズムにより、残余のノード１０の中からノード数ｎ＿ｐ－１のノード１０をレプリケーション先候補として選定する。

選定アルゴリズムとしては、例えば、（ａ）ランダムに選定する、（ｂ）プライマリデータ１２の格納ノードからのネットワーク的な距離（ホップ数）が小さいものから選定する、（ｃ）ストレージ容量が大きいものから選定する、などが挙げられる。なお、前記（ｂ）や（ｃ）の選定処理では、ノード数ｎ＿ｐまで絞りきれない場合には、更に、各ノード１０が含まれる災害の数が少ないものを選定してもよいし、ランダムに選定するようにしてもよい。

前記（ａ）は、実装が最も簡易であるという利点がある。前記（ｂ）は、レプリケーション時におけるネットワークリソースの消費量の軽減や処理時間の軽減という利点がある。また前記（ｃ）は、レプリケーショングループ内全体のストレージ容量がなくなる頻度を小さくすることが可能であるという利点がある。図７に、ノードＩＤ「Ａ」であるノード１０についてのレプリケーショングループ構築の例を示す。図７の例では、選定アルゴリズムとして上記（ｂ）を用いている。

レプリケーション先計算部１４０の機能について図８を参照して説明する。図８は、レプリケーション先の算出処理を説明するフローチャートである。

レプリケーション先計算部１４０は、ノード１０のレプリケーション実行装置２００から受信したデータ検知通知に基づきレプリケーション先の算出処理を開始する。レプリケーション先計算部１４０は、まず、データ検知通知の送信元のノード１０についてのレプリケーショングループを記憶部１２０から取得する（ステップＳ１１）。次に、レプリケーション先計算部１４０は、算出に必要なネットワーク情報およびノード情報を記憶部１２０から取得する（ステップＳ１２）。幾つかの実施例では、ここで取得する情報として、レプリケーション先計算部１４０は、後述する算出アルゴリズムに応じて静的な情報だけでなく動的な情報を取得する。動的な情報は、当該情報が記憶部１２０に記憶されている場合はそれを取得することができる。また、動的な情報は、データ取得部１１０を用いてリアルタイムに取得してもよい。

次に、レプリケーション先計算部１４０は、データ検知通知の送信元のノード１０のストレージに格納されているプライマリデータ１２のレプリケーション先である他のノード１０を、所定の算出アルゴリズムを用いて、前記ステップＳ１１及びＳ１２で取得した各種情報に基づき算出する（ステップＳ１３）。レプリケーション先計算部１４０は、算出したレプリケーション先ノード１０のノードＩＤをレプリケーション実行装置２００に送信する（ステップＳ１４）。

レプリケーション先計算部１４０における前記算出処理について説明する。ノード数ｎ＿ｐが２の場合、レプリケーション先は一意に決定される。ノード数ｎ＿ｐが２より大きい場合、すなわちレプリケーショングループ内にレプリケーション先の候補となるノード１０が複数ある場合は、前記算出アルゴリズムによりノード１０を算出する。

算出アルゴリズムとしては、システム全体としてのストレージの利用効率やコストなどの指標値や、レプリケーション時におけるスループットなどの指標値に基づき、指標値が最適となるようなレプリケーション先のノード１０を算出する。例えば、レプリケーション先計算部１４０は、（ａ）残ストレージ容量にもとづきレプリケーション先を決定する、（ｂ）帯域の空き帯域幅にもとづきレプリケーション先を決定する、（ｃ）ディスクの書き込み速度（低コストなディスク）にもとづきレプリケーション先を決定する、（ｄ）プライマリデータ１２の格納されたノード１０との間のホップ数によりレプリケーション先を決定する、などが挙げられる。

前記（ａ）は、ストレージ容量が足りなくなる頻度を低減可能という利点がある。前記（ｂ）は、リンク２０の帯域逼迫を最小化可能という利点がある。前記（ｃ）は低コストミニマムなレプリケーションが可能という利点がある。前記（ｄ）はネットワークのリソース利用の効率化やRTT(Round trip time)の低減という利点がある。

なお、前述したレプリケーショングループ構築部１３０における選定アルゴリズムと、レプリケーション先計算部１４０における算出アルゴリズムは独立しており、任意の組み合わせが可能である。

図９にレプリケーショングループを(Ａ,Ｃ,Ｅ)としたときに、残ストレージ容量が多いノードにレプリケーションする例を示す。ここでは、ノードＣおよびノードＥの総ストレージ容量は同じであって、残ストレージ容量を％で示している。

図１０は、レプリケーション実行装置の機能ブロック図である。図１０に示すように、レプリケーション実行装置２００は、データ検知部２１０と、レプリケーション先問い合わせ部２２０と、レプリケーション処理部２３０とを備えている。データ検知部２１０は、ノード１０のストレージ１１を監視し、端末１によりプライマリデータ１２が保存されたことを検出する。レプリケーション先問い合わせ部２２０は、データ検知部２１０がプライマリデータ１２の保存を検知すると、レプリケーション先のノード１０をマスターサーバ１００のレプリケーション先計算部１４０に問い合わせる。レプリケーション先問い合わせ部２２０は、レプリケーション先計算部１４０から応答を受領すると、レプリケーション処理部２３０にレプリケーション先のノード１０を指定してレプリケーションの実行を指示する。レプリケーション処理部２３０は、プライマリデータ１２を、指定されたノード１０に対してレプリケーションする。

＜実施例１＞
本発明の実施例１について図１１を参照して説明する。本実施例１はレプリケーショングループ構築部１３０によるレプリケーショングループの構築例である。本実施例１では、レプリケーショングループ構築部１３０における選定アルゴリズムとして、ホップ数に基づく選定を行うものとする。また、ホップ数による選定の結果、候補となるノードが複数ある場合には、さらに、自身が属する災害情報の数に基づき選定を行う（好ましくは災害情報に含まれないノードを選定する）。なお、レプリケーショングループ内のノード数ｎ＿ｐは３とする。

以下の説明では、ノードＩＤが「Ｘ」であるノード１０をノードＸと表記するものとする。

レプリケーショングループ構築部１３０は、まず、プライマリデータ１２がノードＡに保存される場合のレプリケーショングループを構築する。ここで、ノードＡは震度７エリアに含まれるため、震度７エリアに含まれないノードＣ，ノードＤ，ノードＥがレプリケーショングループの対象となる。次に、ホップ数が少ない上位２つ（レプリケーショングループには自身のノード、つまりノードＡが含まれるため）のノードを選定する。図１１の例では、ホップ数１としてノードＥがあり、ホップ数２としてノードＣとノードＤがある。そこで、さらにホップ数２のノードＣとノードＤのうち、災害情報に含まれていない、すなわち自身が属する災害情報の数が少ないノードＤを選定する。以上により、プライマリデータ１２がノードＡに保存される場合のレプリケーショングループは、図１１に示すように（Ａ，Ｄ，Ｅ）となる。

その他のノードＢ～ノードＥに対しても同様な計算を行うことにより、図１１に示すように、プライマリデータ１２が各ノードに含まれる場合のレプリケーショングループが構築される。

＜実施例２＞
本発明の実施例２について図１２を参照して説明する。本実施例２はレプリケーショングループ構築部１３０によるレプリケーショングループの構築例である。本実施例２では、レプリケーショングループ構築部１３０における選定アルゴリズムとして、ストレージ容量の多いノードを選定するものである。なお、レプリケーショングループ内のノード数ｎ＿ｐは３とする。

レプリケーショングループ構築部１３０は、まず、プライマリデータ１２がノードＡに保存される場合のレプリケーショングループを構築する。ここで、ノードＡは震度７エリアに含まれるため、震度７エリアに含まれないノードＣ，ノードＤ，ノードＥがレプリケーショングループの対象となる。次に、ストレージ容量が多い上位２つ（レプリケーショングループには自身のノード、つまりノードＡが含まれるため）のノードを選定する。図１２の例では、ノードＤとノードＥが選定される。以上により、プライマリデータ１２がノードＡに保存される場合のレプリケーショングループは、図１２に示すように（Ａ，Ｄ，Ｅ）となる。

その他のノードＢ～ノードＥに対しても同様な計算を行うことにより、図１２に示すように、プライマリデータ１２が各ノードに含まれる場合のレプリケーショングループが構築される。

＜実施例３＞
本発明の実施例３について図１３を参照して説明する。本実施例３はレプリケーション先計算部１４０によるレプリケーション先の算出例である。本実施例３では、レプリケーション先計算部１４０における算出アルゴリズムとして、残ストレージ容量にもとづきレプリケーション先を決定するものである。なお、本実施例３では、前述した実施例１によってレプリケーショングループが既に構築されているものとする。

本実施例３では、プライマリデータ１２がノードＡに保存されたことをデータ検知部２１０が検知し、レプリケーション先計算部１４０がレプリケーション先を算出することを想定する。また、本実施例３では、図１３に示すレプリケーショングループが既に構築されているものとする。

図１３に示すように、ノードＡはレプリケーショングループ（Ａ，Ｃ，Ｅ）に含まれるため、レプリケーション先の候補としてはノードＣ，Ｅの２つが挙げられる。本実施例３では「残ストレージ容量にもとづきレプリケーション先を決定」するため、記憶部１２０又はデータ取得部１１０から各ノードの残ストレージ容量を取得する。ここでは、ノードＣ，ノードＥの残ストレージ容量がそれぞれ５０％，１０％だったとする。そこで、レプリケーション先計算部１４０は、レプリケーション先として残ストレージ容量が多いノードＣを算出する。なお、ノードＣおよびノードＥの総ストレージ容量は、同じであるとする。

＜実施例４＞
本発明の実施例４について図１４を参照して説明する。本実施例４はレプリケーション先計算部１４０によるレプリケーション先の算出例である。本実施例４では、レプリケーション先計算部１４０における算出アルゴリズムとして、帯域の空き帯域幅にもとづきレプリケーション先を決定するものである。なお、本実施例４では、前述した実施例１によってレプリケーショングループが既に構築されているものとする。

本実施例４では、プライマリデータ１２がノードＡに保存されたことをデータ検知部２１０が検知し、レプリケーション先計算部１４０がレプリケーション先を算出することを想定する。また、本実施例４では、図１４に示すレプリケーショングループが既に構築されているものとする。

図１４に示すように、ノードＡはレプリケーショングループ（Ａ，Ｃ，Ｅ）に含まれるため、レプリケーション先の候補としてはノードＣ，Ｅの２つが挙げられる。本実施例４では「帯域の空き帯域幅にもとづきレプリケーション先を決定」するため、記憶部１２０又はデータ取得部１１０から各ノード間のリンクの帯域の空き容量を取得する。ここで、ノードｉ，ｊ間のリンクをＬ＿ｉｊと表記するものとする。各リンクの帯域の空き容量は、図１４に示すようなものであったとする。

レプリケーション先計算部１４０は、途中のリンクの帯域逼迫を防ぐため，各ノード間（ノードＡ－ノードＣ，ノードＡ－ノードＥ）の空き帯域幅の最小値が大きいノード（ＣｏｒＥ）をレプリケーション先とする。図１４の例では、ノードＡ－ノードＣ間はそれぞれ，１０，３の空き帯域幅があるため３，ノードＡ－ノードＥ間は７の空き帯域幅があるため７となる。つまり、ノードＡ－ノードＥ間のほうが空き帯域幅の最小値が大きいため、レプリケーション先計算部１４０は、レプリケーション先としてノードＥを算出する。

＜実施例５＞
本発明の実施例５について図１５を参照して説明する。本実施例５はレプリケーション先計算部１４０によるレプリケーション先の算出例である。本実施例５では、レプリケーション先計算部１４０における算出アルゴリズムとして、ディスクの書き込み速度（低コストなディスク）にもとづきレプリケーション先を決定するものである。なお、本実施例５では、前述した実施例１によってレプリケーショングループが既に構築されているものとする。

本実施例５では、プライマリデータ１２がノードＡに保存されたことをデータ検知部２１０が検知し、レプリケーション先計算部１４０がレプリケーション先を算出することを想定する。また、本実施例５では、図１５に示すレプリケーショングループが既に構築されているものとする。

図１５に示すように、ノードＡはレプリケーショングループ（Ａ，Ｃ，Ｅ）に含まれるため、レプリケーション先の候補としてはノードＣ，Ｅの２つが挙げられる。本実施例５では「ディスクの書き込み速度（低コストなディスク）にもとづきレプリケーション先を決定」するため、記憶部１２０又はデータ取得部１１０から各ノードにあるディスクの書き込み速度（またはコスト）を取得する。

図１５に示すように、ノードＣ，ノードＥのディスクの書き込み速度（コスト）がそれぞれ、４０Ｍｂｐｓ（＄８０／１ＴＢ），６０Ｍｂｐｓ（＄１００／１ＴＢ）だった場合、レプリケーション先計算部１４０は、レプリケーション先として低コストなノードＣを算出する。

以上本発明の一実施の形態について詳述したが本発明はこれに限定されるものではない。例えば、上記実施の形態では、ノード１０に格納されたデータをリアルタイムにバックアップするレプリケーションシステムについて説明したが、ノード１０に格納されたデータを定期バックアップなどのように定期的又は任意時にバックアップするシステムであっても本発明を適用できる。

また、上記実施の形態では、端末１として映像を出力するＩｏＴ端末について例示したが、他の種類の端末であっても本発明を適用できる。

また、上記実施の形態では、バックアップの対象として、データ（ファイル）を例示したが、データ以外のVM（Virtual Machine）、コンテナなどの仮想化環境についてもバックアップの対象としてもよい。VMは、物理サーバを複数に分割した仮想的なサーバである。コンテナは、１つのOSの上で提供される仮想的なユーザ空間である。

以下に、本発明の他の実施の形態について説明する。

＜他の実施の形態＞
エッジコンピューティング（Edge computing; EC）環境では、サーバ故障、ストレージ故障などによるVM（Virtual Machine）またはコンテナの可用性低下、データ（ファイル）の消失などを防ぐ必要がある。このため、同一拠点あるいは別拠点の他のサーバ、他のストレージなどに、バックアップ（レプリケーションを含む）することが想定される。

特に自然災害の回避（Disaster recovery; DR）を想定したケースでは、複数拠点（例えば、複数データセンタ; DC）にVM、コンテナ、ファイルをバックアップすることで、災害による可用性低下やファイル消失を回避する。

ECでは、リソース（CPU、メモリ、ストレージ、ネットワーク帯域など）が広域に分散しているため、一般的に各拠点のリソースが少ない。また、確実なバックアップとのトレードオフとして、リソースの利用効率が低いという問題がある。

そのため、従来のバックアップ技術をECに適用する場合、ノード（局舎）間の通信帯域、ノード内のサーバおよびストレージを増強する必要があり、CAPEXまたはOPEXの増加につながる。CAPEX （capital expenditure）は設備投資であり、OPEX（operating expenditure）は運用コストである。

すなわち、地理的に離れた拠点のノードのみをバックアップ先とすると、バックアップ先の拠点数が少なく、かつ、各拠点のリソース量は少ないため、バックアップできないことがある。また、予測情報の更新頻度が高い災害に追従するようにバックバックアップを行う場合、事前にネットワーク帯域、ストレージ容量などのリソースを多く用意する必要があるため、CAPEXの増加につながる。

本実施形態では、台風、雷などの動的な災害の予測情報、及びユーザが求めるDRの要求レベル（ユーザ故障率）を用いて、バックアップの必要性を判定する。これにより、本実施形態では、ユーザのDRの要求レベルに応じたバックアップができるようになる。このため、本実施形態では、インフラ提供者のCAPEXを低減することができ、ユーザがインフラ提供者へ支払うコストも低減することができる。

（マスターサーバの構成）
図１６は、本実施形態のマスターサーバの機能ブロック図である。本実施形態のマスターサーバ１０１は、上記実施形態と同様に、リアルタイムにバックアップするレプリケーションを制御するが、レプリケーションに限定されない。図示するマスターサーバ１０１は、データ取得部１１０と、レプリケーショングループ構築部１３０と、レプリケーション先計算部１４０と、被災判定部１５０と、実施判定部１６０と、優先度計算部１７０と、削除部１８０と、記憶部１２０とを備える。

データ取得部１１０は、所定のクラウドサーバまたは管理者からの入力により、災害情報（災害予測情報）、ネットワーク情報、ノード情報などの各種データを取得し、記憶部１２０に記憶する。本実施形態の災害情報には、上記の実施形態で記載した静的な災害情報だけでなく、動的な災害予測情報も含まれる。

静的な災害情報は、情報の更新頻度（例えば数年に１回など）が低い災害情報である。動的な災害情報は、情報の更新頻度（例えば数時間に１回など）が高い災害情報である。動的な災害情報としては、例えば、雷、台風、大雨などがある。

レプリケーショングループ構築部１３０（バックアップ先ノード情報生成部）は、静的な災害情報に基づいて、データ、VMおよびコンテナの少なくとも１つを備えるプライマリノード（第１のノード）と、プライマリノードのバックアップ先候補となる１以上の第２のノードとを含むレプリケーショングループ情報を生成する。

レプリケーション先計算部１４０（バックアップ先ノード算出部）は、ネットワーク情報およびノード情報の少なくとも１つを用いて、レプリケーショングループ情報の第２のノードの中からレプリケーション先のセカンダリノードを決定する。また、レプリケーション先計算部１４０は、動的な災害情報に対する追加ノード（第３のノード）を決定し、レプリケーショングループ情報に追加ノードを追加する。

被災判定部１５０は、データ取得部１１０が取得した動的な災害情報の災害エリアにプライマリノードとセカンダリノードの両方が含まれるか否かを判定する。実施判定部１６０は、災害エリアにプライマリノードとセカンダリノードの両方が含まれる場合、プライマリノードおよびセカンダリノードの被災率（EC被災率）が、ユーザが要求するユーザ故障率（ユーザのDRの要求レベル）より大きいか否かを判定する。すなわち、被災判定部１５０は、バックアップまたはレプリケーションの必要性を判定する。

優先度計算部１７０は、ネットワーク帯域、災害到達予測時間、バックアップ先の残ストレージ容量などを用いて、バックアップ可能なデータサイズなどのリソース容量を計算する。バックアップ可能なリソース容量より、バックアップが必要なリソース容量が大きい場合、優先度計算部１７０は、データ、VM、コンテナに優先度を設定する。

削除部１８０は、動的な災害情報により追加ノードにバックアップされた不要なテンポラリデータ、テンポラリVM、テンポラリコンテナを削除する。

記憶部１２０には、データ取得部１１０が取得した災害情報、ネットワーク情報、ノード情報などの各種データデータが記憶される。また、記憶部１２０には、レプリケーショングループ情報が記憶される。

（レプリケーション実行装置の構成）
図１７は、本実施形態のレプリケーション実行装置の機能ブロック図である。図示するレプリケーション実行装置２０１（バックアップ実行部）は、データ検知２１０と、レプリケーション先問い合わせ部２２０と、レプリケーション処理部２３０とを備える。

本実施形態のデータ検知２１０は、ノード１０のストレージなどを監視し、端末１によりデータ１２、VM１４、コンテナ１６の少なくとも１つが更新されたことを検知する。

レプリケーション先問い合わせ部２２０は、データ検知部２１０が更新を検知すると、レプリケーション先のノードをマスターサーバ１０１のレプリケーション先計算部１４０に問い合わせる。レプリケーション先問い合わせ部２２０は、レプリケーション先計算部１４０から通知されたレプリケーション先のノードを指定して、レプリケーション処理部２３０にレプリケーションの実行を指示する。

レプリケーション処理部２３０は、指定されたレプリケーション先のノードに、データ１２、VM１４、コンテナ１６の少なくとも１つを複製する。また、動的な災害情報については、レプリケーション処理部２３０は、EC被災率がユーザ故障率以上の場合に、プライマリノードまたはバックアップ先のノードに格納されたデータ、VMおよびコンテナの少なくとも１つを、追加ノードに複製する。

（本実施形態の処理）
ここでは、上記の実施形態で説明した、静的な災害情報にもとづくレプリケーションが実施済の状態において、動的な災害情報を取得した際の処理について説明する。

図１８は、静的な災害情報にもとづくレプリケーションが実行されている実行済状態の一例を示す図である。ここでは、静的な災害情報として、震度７地震が予測され、災害エリアにはノードＡおよびノードＢが含まれる。また、ノードＡのレプリケーショングループ（ＲＧ）は、（Ａ，Ｅ）であり、ノードＡのレプリケーション先はノードＥである。レプリケーショングループのノード数は２である。この場合、ノードＡのプライマリデータ１２およびプライマリVM１４は、ノードＥにレプリケーションされ、セカンダリデータ１３（レプリケーションデータ）およびセカンダリVM１５（レプリケーションVM）としてノードEに格納されている。本実施形態のセカンダリデータは、上記実施形態のレプリケーションデータと同じものである。

図示する例では、レプリケーションの対象は、データとVMとするが、これに限定されない。レプリケーションの対象は、コンテナであってもよい。すなわち、レプリケーションの対象は、データ、VM、コンテナの少なくとも１つであってもよい。

図１９は、本実施形態の処理を示すフローチャートである。ここでは、図１８に示す静的な災害情報にもとづくレプリケーションが実行済みの状態において、動的な災害情報を取得した場合の処理を説明する。

データ取得部１１０は、あらかじめ、ユーザがユーザ端末を用いて入力したユーザ故障率、SLA（Service level agreement）、コストなどを取得しておく（Ｓ２１）。ユーザ故障率は、ユーザがEC（例えば図１）に求める故障率である。ユーザは、インフラ提供者への支払いコストを考量して、所望のユーザ故障率Pu（例えばPu＝f(cost)）を設定する。

ユーザは、ユーザ故障率のかわりに、SLA、コストなどをマスターサーバ１０１に入力してもよい。この場合、データ取得部１１０は、ユーザが入力したSLAまたはコストを取得し、SLAまたはコストを用いて、ユーザ故障率Puを算出してもよい。

データ取得部１１０は、所定のクラウドサーバまたは管理者からの入力により、動的な災害情報を取得する（Ｓ２２）。データ取得部１１０は、政府、民間企業などが高い頻度で更新している動的な災害情報（例えば雷、台風など）を、ネットワークを介して取得する。動的な災害情報には、エリア情報（災害の発生範囲）、強度情報（災害の規模）、発生確率情報（災害の発生確率）、到達時間情報（災害の到達予測時間）などが含まれる。動的な災害情報は高い頻度で更新され、データ取得部は、動的な災害情報が更新されるたびに取得する。

被災判定部１５０は、動的な災害情報のエリア情報を用いて、災害エリアにプライマリデータおよびプライマリVMを保持するプライマリノードと、セカンダリデータおよびセカンダリVMを保持するセカンダリノードの両方が含まれるか否かを判定する（Ｓ２３）。すなわち、被災判定部１５０は、プライマリデータおよびプライマリVMと、セカンダリデータおよびセカンダリVMとが、同時に被災するか否かを判定する。被災判定部１５０は、動的な災害情報の災害種類ごとに判定する。

本実施形態では、プライマリノード（プライマリデータ、プライマリVM等）およびセカンダリノード（セカンダリデータ、セカンダリVM等）の同時被災を防ぐことを目的としている。このため、動的な災害情報に対しては、プライマリノードとセカンダリノードが同時に被災する可能性がある場合のみバックアップを行う。このバックアップには、レプリケーションも含まれる。

図２０は、図１８に示すレプリケーション実施済み状態で、動的な災害情報を取得した場合を説明する説明図である。図示する動的な災害情報には、台風と雷の２つの災害情報が含まれる。台風の災害エリアＴには、ノードＡおよびノードＢが含まれ、雷の災害エリアＫには、ノードＡおよびノードＥが含まれる。ノードＡ（プライマリノード）の災害発生確率は、台風が70％で、雷が10％である。ノードＥ（セカンダリノード）の災害発生確率は、台風が0％で、雷が20％である。雷の災害エリアＫには、ノードＡおよびノードＥが含まれるため、雷に対する同時被災のリスクがある。一方、台風の災害エリアＴには、ノードＡが含まれるが、ノードＥは含まれないため、台風による同時被災のリスクはない。

したがって、図２１に示すように、被災判定部１５０は、雷については、災害エリアＫにプライマリノードとセカンダリノードの両方が含まれると判定し（Ｓ２３：ＹＥＳ）、バックアップの対象とする。一方、被災判定部１５０は、台風については、災害エリアＴにプライマリノードとセカンダリノードの両方が含まれないと判定し（Ｓ２３：ＮＯ）、バックアップの対象とせずにＳ２２に戻り、次に動的な災害情報が更新されるのを待つ。

プライマリノードとセカンダリノードの両方が含まれる場合（Ｓ２３：ＹＥＳ）、実施判定部１６０は、災害の発生確率、強度、ECの故障率、耐障害性、局舎の築年数、地理情報などを用いてEC被災率Pmを算出する（Ｓ２４）。EC被災率Pmは、現在発生しうる災害の発生確率を加味したうえで、どの程度の確率でプライマリノードおよびセカンダリノードが被災（故障）するかを示す指標である。本実施形態では、EC被災率Pmを、以下の式により算出する。

EC被災率Pm＝α×Pi×Pj

αは、耐障害性、局舎の築年数、地理情報などを用いて算出される災害発生時の故障率である。すなわち、αは、仮に災害が発生した場合、どの程度の確率でECが故障（被災）するかを示す指標である。ここでは、最も安全側の評価であるα＝１（災害が発生した場合は、必ず故障する）を用いて評価する。Piは、プライマリノードiでの災害発生確率である。Pjは、セカンダリノードjの災害発生確率である。PiおよびPjには、動的な災害情報を用いる。

図２２の例では、ノードＡ（プライマリノード）の災害発生確率をPa＝0.1とし、ノードＥ（セカンダリノード）の災害発生確率Pe＝0.2とする。この場合、EC被災率は以下のとおりである。

EC被災率Pm＝1×0.1×0.2＝0.02

実施判定部１６０は、算出したEC被災率Pmと、Ｓ２１で取得したユーザ故障率Puとを比較し、バックアップするか否かを判定する（Ｓ２５）。具体的には、実施判定部１６０は、EC被災率Pmがユーザ故障率Pu以上か否か（EC被災率Pm≧ユーザ故障率Pu）を判定する。EC被災率Pmがユーザ故障率Pu以上の場合、ユーザが求める故障率を満たせていないため、実施判定部１６０は、バックアップすると判定する。実施判定部１６０は、対象の種類毎（データ、VM）に判定する。

図２２では、VMのユーザ故障率Pu,vmを0.3とし、データのユーザ故障率Pu,dataを0.01とする。実施判定部１６０は、VMについては、EC被災率Pmがユーザ故障率Pu,vmより小さい（Pm＜Pu,vm）と判定し（Ｓ２５：ＮＯ）、バックアップ不要と判定する。一方、実施判定部１６０は、データについては、EC被災率Pmはユーザ故障率Pu,dataより大きい（Pm＜Pu,data）と判定し（Ｓ２５：ＹＥＳ）、バックアップは必要と判定する。

レプリケーション先計算部１４０は、動的な災害情報に対する追加ノード（第３のノード）を選定し、当該追加ノードを記憶部１２０に記憶したレプリケーショングループに追加する（Ｓ２６）。レプリケーション先計算部１４０は、上記実施形態のレプリケーション構築処理と同様の選定アルゴリズムを用いて、動的な災害情報に対するバックアップ先となる追加ノードを決定する。追加ノード数Mは、少なくとも１つであって、あらかじめ記憶部１２０に記憶されている。

ここでは、レプリケーション先計算部１４０は、災害エリアに含まれないノードの中から、プライマリノードまたはセカンダリノードからのホップ数を用いて、追加ノードを決定する。この場合、レプリケーション先計算部１４０は、災害エリアに含まれないノードであって、かつ、プライマリノードまたはセカンダリノードからのホップ数が小さいノードから順に追加ノード数Mになるまで選択する。ホップ数が同じノードが複数存在することで、選定した追加ノードの数が追加ノード数Mを超える場合は、例えば、残ストレージ容量に基づいて選択する。

図２３に示す例では、追加ノード数M＝１とする。この場合、雷の災害エリアＫに含まれず、ノードＡまたはノードＥからホップ数１のノードは、ノードＢおよびノードＤである。ノードＢの残ストレージ容量は500Tbitで、ノードＤの残ストレージ容量は400Tbitである。この場合、レプリケーション先計算部１４０は、残ストレージ容量が多いノードＢを追加ノードとして選択し、追加ノードＢをレプリケーショングループに加える。これにより、雷の動的な災害情報に対するノードＡのデータ用のレプリケーショングループは、元の（Ａ,Ｅ）から、（Ａ,Ｅ,[Ｂ]）に更新される。

レプリケーション実行装置２０１は、更新後のレプリケーショングループに従って、動的な災害情報に対するバックアップを実行する（Ｓ２７）。具体的には、レプリケーション実行装置２０１は、追加ノードから近い（ホップ数が少ない）プライマリノードまたはセカンダリノードから、バックアップが必要と判定した対象（データ、VM）を、追加ノードにバックアップする。

バックアップの実行に際し、優先度計算部１７０は、ネットワーク帯域、災害到達予測時間、バックアップ先の残ストレージ容量などを用いて、バックアップ可能なリソース容量（例えばデータサイズなど）を計算する。バックアップ可能なリソース容量より、バックアップが必要なリソース容量が大きい場合、優先度計算部１７０は、データおよびVMに優先度を設定する。例えば、優先度計算部１７０は、データ種別、データアクセス時刻、データ更新時刻などを用いて、各データ（ファイル）に優先度を設定する。また、優先度計算部１７０は、バックアップするファイルの数が最大となるように、各ファイルに優先度を設定してもよい。レプリケーション実行装置２０１は、データの優先度に従い、順にデータをバックアップする。

バックアップの対象がVM、コンテナの場合であっても、優先度計算部１７０は、データと同様に、種別、アクセス時刻、更新時刻などを用いて、VMまたはコンテナに優先度を設定する。

なお、追加ノード数Mが複数ある場合、上記実施形態と同様の算定アルゴリズムを用いて、レプリケーション先計算部１４０は、いずれか１つの追加ノードを決定する。例えば、レプリケーション先計算部１４０は、(a)ネットワーク帯域およびストレージ容量に空きがある追加ノード、(b)ネットワーク帯域に空きがないがストレージ容量の空きはある追加ノード、(c)ストレージ容量に空きがないが、ネットワーク帯域の空きはある追加ノードなどを選択する。レプリケーション実行装置２０１は、レプリケーション先計算部１４０が決定した追加ノードに対し、データまたはVMをコピーする。

図２４に示す例では、ノードＢ（追加ノード）に近いノードＡ（プライマリノード）のレプリケーション実行装置２０１が、ノードＡのプライマリデータをノードＢに、テンポラリデータ１７としてバックアップする。ここでは、優先度計算部１７０が算出したバックアップ可能なデータサイズが、バックアップが必要なデータサイズより大きいものとする。この場合、雷の到達時間までに、全てのプライマリデータをノードＢにバックアップできるため、レプリケーション実行装置２０１は、単純なバックアップ行う。

図２５に示す例では、バックアップ可能なデータサイズに対して、バックアップが必要なデータサイズが大きい場合を示す。この場合、優先度計算部１７０は、データに優先度を設定する。図示する例では、優先度計算部１７０は、最終アクセス時刻を用いてデータの優先度を設定する。

ここで、災害情報に含まれる災害到達予定時刻は１時間後とし、ノードＡおよびノードＢ間のネットワーク帯域は10Gbpsとする。優先度計算部１７０は、バックアップ可能なデータサイズとして、10 Gbps×3600s＝36Tbitを算出する。レプリケーション実行装置２０１は、最終アクセス時刻を用いてノードＡのデータを並べ替え（ソート）、最終アクセス時刻が直近のデータから順にバックアップする。図示する例では、レプリケーション実行装置２０１は、ノードＡのデータ４０の中から、データａ、ｂの順にバックアップする。データa、bの総量は36Tbitであるため、データａおよびデータｂは確実にバックアップされるが、それ以外のデータは、バックアップされない可能性がある。

図２６に示す例では、バックアップ可能なデータサイズに対して、バックアップが必要なデータサイズが大きい場合を示す。図示する例では、優先度計算部１７０は、最終更新時刻を用いてデータの優先度を設定する。

ここで、優先度計算部１７０は、バックアップ先のノードＢの残ストレージ容量を用いてバックアップ可能なデータサイズを算出する。すなわち、優先度計算部１７０は、残ストレージ容量500 Tbitをバックアップ可能なデータサイズとする。レプリケーション実行装置２０１は、最終更新時刻を用いてノードＡのデータを並べ替え、最終更新時刻が直近のデータから順にバックアップする。図示する例では、レプリケーション実行装置２０１は、ノードＡのデータ５０の中から、データａａａａ、ｂｂｂｂの順にバックアップする。データaａａａ、bｂｂｂの総量は500Tbitであるため、データａａａａおよびデータｂｂｂｂは確実にバックアップされるが、それ以外のデータは、バックアップされない。

図２７は、削除部１８０の処理を示す図である。ノードＡおよびノードＥが被災することなく雷が通過した場合、または、雷が発生しなかった場合は、ノードＢにバックアップされたテンポラリデータ１７は不要となる。削除部１８０は、不要になったテンポラリデータ１７を削除する。これにより、リソースの利用効率を高めることができる。

以上説明した本実施形態では、動的な災害情報に対するバックアップの必要性を、ユーザ故障率を用いて判定する。これにより、本実施形態では、ユーザが要求する災害対策の要求レベルに応じたバックアップができる。このため、本実施形態では、インフラ提供者のCAPEXを低減できるとともに、ユーザのインフラ提供者への支払コストも低減できる。

１…端末
１０…ノード
１１…ストレージ
１２…プライマリデータ
２０…リンク
１００、１０１…マスターサーバ
１１０…データ取得部
１２０…記憶部
１３０…レプリケーショングループ構築部
１４０…レプリケーション先計算部
１５０…被災判定部
１６０…実施判定部
１７０…優先度計算部
１８０…削除部
２００、２０１…レプリケーション実行装置
２１０…データ検知部
２２０…レプリケーション先問い合わせ部
２３０…レプリケーション処理部

Claims (7)

1. それぞれストレージが配備された複数のノードを含むネットワークにおいて、第１のノードのストレージに格納されたオリジナルデータを第２のノードのストレージに複製して格納するバックアップシステムであって、
   災害情報並びにネットワーク情報及びノード情報を取得する情報取得部と、
   災害情報並びにネットワーク情報及びノード情報に基づき、オリジナルデータが格納されている第１のノードと当該オリジナルデータのバックアップ先の候補となる１以上の第２のノードとの関連付け情報を含むバックアップ先ノード情報を生成するとともに当該バックアップ先ノード情報を所定の記憶部に保存するバックアップ先ノード情報生成部と、
   オリジナルデータのバックアップを実施する際に、前記バックアップ先ノード情報に含まれるバックアップ先の候補となる１以上の第２のノードからバックアップ先の第２のノードを算出するバックアップ先ノード算出部と、
   オリジナルデータを第１のノードのストレージから前記算出された第２ノードのストレージに複製して格納するバックアップ実行部と、
   前記情報取得部が取得した更新頻度が高い動的災害情報の災害エリアに第１のノードと前記バックアップ先の第２のノードの両方が含まれるか否かを判定する被災判定部と、
   前記災害エリアに第１のノードと前記バックアップ先の第２のノードの両方が含まれる場合、第１のノードおよび前記バックアップ先の第２のノードの被災率が、ユーザが要求するユーザ故障率以上か否かを判定する実施判定部と、を備え、
   前記バックアップ実行部は、前記被災率が前記ユーザ故障率以上の場合、第１のノードまたは前記バックアップ先の第２のノードに格納された前記オリジナルデータまたは複製されたデータを、第３のノードに複製する
   ことを特徴とするバックアップシステム。
2. 前記バックアップ先ノード情報生成部は、全てのノードから、災害発生場所が第１のノードを含む災害情報に含まれる他のノードを除外し、除外したノードの中からバックアップ先の候補となる１以上の第２のノードを選定する
   ことを特徴とする請求項１記載のバックアップシステム。
3. 前記バックアップ先ノード算出部は、前記バックアップ先ノード情報に含まれるバックアップ先の候補となる複数の第２ノードの中から、システム全体としてのストレージの利用効率やコストの指標値又はバックアップ時におけるスループットの指標値に基づき、指標値が最適となるようなノードを算出する
   ことを特徴とする請求項１又は２記載のバックアップシステム。
4. 第１のノードにおいてストレージにオリジナルデータが保存されたことを検知するデータ検知部を備え、
   前記バックアップ実行部は、前記データ検知部がオリジナルデータの保存を検知すると、前記バックアップ先ノード算出部に対してバックアップ先の第２のノードを問い合わせ、当該問い合わせに対する応答に係る第２のノードのストレージに対してオリジナルデータを複製して格納する
   ことを特徴とする請求項１乃至３何れか１項記載のバックアップシステム。
5. それぞれストレージが配備された複数のノードを含むネットワークにおいて、第１のノードのストレージに格納されたオリジナルデータを第２のノードのストレージに複製して格納するバックアップシステムにおけるバックアップ方法であって、
   情報取得部が、災害情報並びにネットワーク情報及びノード情報を取得するステップと、
   バックアップ先ノード情報生成部が、災害情報並びにネットワーク情報及びノード情報に基づき、オリジナルデータが格納されている第１のノードと当該オリジナルデータのバックアップ先の候補となる１以上の第２のノードとの関連付け情報を含むバックアップ先ノード情報を生成するとともに当該バックアップ先ノード情報を所定の記憶部に保存するステップと、
   バックアップ先ノード算出部が、オリジナルデータのバックアップを実施する際に、少なくとも前記バックアップ先ノード情報に含まれるバックアップ先の候補となる１以上の第２のノードからバックアップ先の第２のノードを算出するステップと、
   バックアップ実行部が、オリジナルデータを第１のノードのストレージから前記算出された第２ノードのストレージに複製して格納するステップと、
   被災判定部が、前記情報取得部が取得した更新頻度が高い動的災害情報の災害エリアに第１のノードと前記バックアップ先の第２のノードの両方が含まれるか否かを判定するステップと、
   実施判定部が、前記災害エリアに第１のノードと前記バックアップ先の第２のノードの両方が含まれる場合、第１のノードおよび前記バックアップ先の第２のノードの被災率が、ユーザが要求するユーザ故障率以上か否かを判定するステップと、
   前記バックアップ実行部が、前記被災率が前記ユーザ故障率以上の場合、第１のノードまたは前記バックアップ先の第２のノードに格納された前記オリジナルデータまたは複製されたデータを、第３のノードに複製するステップと、を備える
   ことを特徴とするバックアップ方法。
6. 災害情報を取得する情報取得部と、
   前記災害情報に基づいて、データ、ＶＭおよびコンテナの少なくとも１つを備える第１のノードと、第１のノードのバックアップ先候補となる１以上の第２のノードとを含むグループ情報を生成するバックアップ先ノード情報生成部と、
   ネットワーク情報およびノード情報の少なくとも１つを用いて、前記グループ情報の第２のノードの中からバックアップ先ノードを、決定するバックアップ先ノード算出部と、
   前記データ、前記ＶＭおよび前記コンテナの少なくとも１つを、前記バックアップ先ノードに複製するバックアップ実行部と、
   前記情報取得部が取得した更新頻度が高い動的災害情報の災害エリアに第１のノードと前記バックアップ先ノードの両方が含まれるか否かを判定する被災判定部と、
   前記災害エリアに第１のノードと前記バックアップ先ノードの両方が含まれる場合、第１のノードおよび前記バックアップ先ノードの被災率が、ユーザが要求するユーザ故障率以上か否かを判定する実施判定部と、を備え、
   前記バックアップ実行部は、前記被災率が前記ユーザ故障率以上の場合、第１のノードまたは前記バックアップ先ノードに格納された前記データ、前記ＶＭおよび前記コンテナの少なくとも１つを、第３のノードに複製する
   ことを特徴とするバックアップシステム。
7. コンピュータを請求項１乃至４及び請求項６の何れか１項記載のバックアップシステムの各部として機能させることを特徴とするプログラム。

Images