JP2019020816A - 分散コンピューティングシステムにおけるデータをリカバリする方法およびシステム - Google Patents

Abstract

【課題】分散コンピューティングシステムにおけるリカバリに要する時間を短縮する。【解決手段】複数の拠点に存在する複数のノードを有する分散コンピューティングシステムのうちの少なくとも１つのノード（例えば後述のサーバ）又は別の計算機（例えば後述の管理サーバ）が、（Ａ）複数のノードのうちのリカバリ対象のノードが保持している１以上のデータセットと同じ１以上のデータセットを保持している１以上のノードが存在する１以上の拠点を特定し、（Ｂ）同じ１以上のデータセットのリストア先となるノードの拠点であるリストア先拠点を、複数の拠点から、特定した１以上の拠点を基に決定する。【選択図】図２１

Description

本発明は、概して、分散コンピューティングシステムにおけるデータのリカバリに関する。

分散コンピューティングシステムにおけるデータのリカバリに関し、例えば、特許文献１に開示の技術が知られている。特許文献１によれば、ストレージ装置と複数のバックアップ装置とを備える分散バックアップシステムにおいて、ストレージ装置は、リストアに係る要求データ転送サイズを考慮することにより、バックアップ装置の選択を実行する。

特表２０１５−５２９８６１号公報

以下の説明では、分散コンピューティングシステムの要素としての計算機を「ノード」と言うことがある。プロセッサやメモリや通信インタフェースデバイスといった計算リソースを有するいずれの計算機もノードになることができてよい。ノードは、物理的な計算機であってもよいし、物理的な計算機の少なくとも一部の計算リソースを基に動作する仮想的な計算機であってもよい。

また、以下の説明では、「データセット」とは、アプリケーションプログラムのようなプログラムから見た１つの論理的な電子データの塊であり、例えば、レコード、ファイル、キーバリューペアおよびタプルのうちのいずれでもよい。

一般に、分散コンピューティングシステムは、地理的に離れた複数の拠点（例えばデータセンタまたはネットワークセグメント）に存在する複数のノードから構成され、データセットは、２以上の拠点における２以上のノードにレプリカとして分散している。いずれかのノードで障害が発生した場合、リカバリ処理が必要になる。リカバリ処理は、障害が発生したノード（以下、障害ノード）が保持していたデータセットを別のノードにリストアする処理を含む。具体的には、リカバリ処理では、リストア先拠点が決定され、リストア先拠点におけるノード（例えば、新たに追加されたノード、または、既存の予備のノード）が、リストア先ノードとされる。そして、１以上のリストア元拠点における１以上のリストア元ノードからリストア対象のデータセット（障害ノードが保持していたデータセットと同じデータセット）がリストア先ノードにリストアされる。

データセットのリストア中（例えば転送中）は、リストア元ノードの計算リソースが消費される。このため、データセットのリストアに長い時間を要すると、分散コンピューティングシステムの処理性能が低下する期間が長期化するおそれがある。

複数の拠点に存在する複数のノードを有する分散コンピューティングシステムのうちの少なくとも１つのノード（例えば後述のサーバ）又は別の計算機（例えば後述の管理サーバ）が、
（Ａ）複数のノードのうちのリカバリ対象のノードが保持している１以上のデータセットと同じ１以上のデータセットを保持している１以上のノードが存在する１以上の拠点を特定し、
（Ｂ）前記同じ１以上のデータセットのリストア先となるノードの拠点であるリストア先拠点を、前記複数の拠点から、特定した１以上の拠点を基に決定する。

本発明によれば、分散コンピューティングシステムにおいて、リカバリに要する時間を短縮することが期待できる。

第一の実施例に係るブロックチェーンシステムの構成の一例を示す図である。 第一の実施例に係るブロックチェーンプログラムの構成の一例を示す図である。 第一の実施例に係るブロックチェーン管理プログラムの一例の構成を示す図である。 第一の実施例に係るサーバ情報の構成の一例を示す図である。 第一の実施例に係る累計データ量情報の構成の一例を示す図である。 第一の実施例に係る拠点間通信速度情報の構成の一例を示す図である。 第一の実施例に係るトランザクション処理の一例を示すフローチャートである。 第一の実施例に係るサーバ追加処理の一例を示すフローチャートである。 第一の実施例に係るリカバリ処理の一例を示すフローチャートである。 第一の実施例に係るリストア先拠点決定処理の一例を示すフローチャートである。 第一の実施例に係る定期監視処理の一例を示すフローチャートである。 第二の実施例に係る分散ファイルシステムの構成の一例を示す図である。 第二の実施例に係るクライアントプログラムの構成の一例を示す図である。 第二の実施例に係る分散プログラムの構成の一例を示す図である。 第二の実施例に係る管理プログラムの構成の一例を示す図である。 第二の実施例に係るサーバ情報の構成の一例を示す図である。 第二の実施例に係るレプリケーション情報の構成の一例を示す図である。 第二の実施例に係るファイル情報の構成の一例を示す図である。 第二の実施例に係る書込み処理の一例を示すフローチャートである。 第二の実施例に係るリストア先拠点決定処理の一例を示すフローチャートである。 第一の実施例の概要を示す模式図である。

以下、本発明の幾つかの実施例について説明する。

なお、以下の説明においては、「インタフェース部」は、１以上のインタフェースデバイス、具体的には、ユーザインタフェース部と、通信インタフェース部とのうちの少なくとも１つを含んでよい。ユーザインタフェース部は、１以上のＩ／Ｏデバイス（例えば入力デバイス（例えばキーボードおよびポインティングデバイス）と出力デバイス（例えば表示デバイス））と表示用計算機とのうちの少なくとも１つのＩ／Ｏデバイスを含んでよい。通信インタフェース部は、１以上の通信インタフェースデバイスを含んでよい。１以上の通信インタフェースデバイスは、１以上の同種の通信インタフェースデバイス（例えば１以上のＮＩＣ（Network Interface Card））であってもよいし２以上の異種の通信インタフェースデバイス（例えばＮＩＣとＨＢＡ（Host Bus Adapter））であってもよい。

また、以下の説明においては、「記憶部」は、１以上のメモリを含む。記憶部に関して少なくとも１つのメモリは、揮発性メモリでよい。記憶部は、主に、プロセッサ部による処理の際に使用される。

また、以下の説明においては、「プロセッサ部」は、１以上のプロセッサを含む。少なくとも１つのプロセッサは、典型的には、ＣＰＵ（Central Processing Unit）のようなマイクロプロセッサである。１以上のプロセッサの各々は、シングルコアでもよいしマルチコアでもよい。プロセッサは、処理の一部または全部を行うハードウェア回路を含んでもよい。プロセッサ部は、処理の一部または全部を行うハードウェア回路（例えばＦＰＧＡ（Field-Programmable Gate Array）またはＡＳＩＣ（Application Specific Integrated Circuit））を含んでもよい。

また、以下の説明では、「ＰＤＥＶ」は、物理的な記憶デバイスを意味し、典型的には、不揮発性の記憶デバイス（例えば補助記憶デバイス）でよい。ＰＤＥＶは、例えば、ＨＤＤ（Hard Disk Drive）またはＳＳＤ（Solid State Drive）でよい。ストレージシステムに異なる種類のＰＤＥＶが混在していてもよい。

また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ部によって実行されることで、定められた処理を、適宜に記憶部およびインタフェース部のうちの少なくとも１つを用いながら行うため、処理の主語が、プロセッサ部（或いは、プロセッサ部を有する計算機または計算機システム）とされてもよい。プログラムは、プログラムソースから計算機にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記録媒体（例えば非一時的な記録媒体）であってもよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。また、プログラムが実行されることによって実現される処理のうちの少なくとも一部が、ハードウェア回路によって実現されてもよい。

図２１は、本発明の第一の実施例の概要を示す模式図である。

第一の実施例に係るブロックチェーンシステム（分散コンピューティングシステムの一例）が、１以上のノードの一例である１以上のサーバ１２０（例えばサーバ１〜４）で構成されているとする。１以上のサーバ１２０が存在する１以上の拠点１０１（例えば拠点１〜４）がある。

また、サーバ１が、データ１〜４を保持しているとする。サーバ２が、データ１を保持しているとする。サーバ３が、データ１〜３を保持しているとする。サーバ４が、データ１および４を保持しているとする。データ１〜４の各々は、データセットの一例であり、後述のブロックチェーンデータである。

サーバ１で障害が発生したとする。図２１の説明において、障害が発生したサーバ１を「障害サーバ１」と言う。

図２１に示すように、障害サーバ１（リカバリ対象のノードの一例）が保持しているデータ１〜４と同じデータ１〜４を保持するサーバ２〜４が、同一の拠点に存在するとは限らない。このため、或るデータのリストアは短時間で済んでも別のデータのリストアに長時間かかれば、障害サーバ１のリカバリに長時間かかる。

一比較例として、いずれのサーバで障害が生じても予め決められている拠点２がリストア先とされ、拠点２内のサーバがリストア先サーバとされることが考えられる。しかし、一比較例では、障害サーバ１が保持しているデータ１〜４と同じデータ１〜４を、拠点３内のサーバ３や拠点４内のサーバ４から拠点２内のサーバに転送する必要が生じ、リカバリに長時間かかる。

そこで、本実施例では、ブロックチェーン管理プログラム３００が、障害ノード１が保持しているデータ１〜４と同じデータ１〜４を保持しているサーバ２〜４が存在する拠点２〜４を特定する。そして、ブロックチェーン管理プログラム３００が、データ１〜４のリストア先となるサーバの拠点であるリストア先拠点を、複数の拠点１〜４から、特定した拠点２〜４を基に決定する。図２１の例では、拠点３が、リストア先拠点として決定される。その後、リストア先拠点３内のサーバ５がリストア先サーバとして選択される。サーバ２〜４からサーバ５にデータ１〜４が転送（リストア）される。

以下、図面を用いて本発明の第一の実施例を詳細に説明する。

図１は、本発明の第一の実施例に係るブロックチェーンシステムの概略構成を示すブロック図である。

ブロックチェーンシステムは、分散コンピューティングシステムの一例であり、ネットワーク１１０を介して１以上のクライアント１００と接続された１以上（典型的には複数）のサーバ１２０と、１以上の管理サーバ１３０とを備えている。

クライアント１００は、１以上のサーバ１２０が提供するブロックチェーンサービス（分散コンピューティングサービスの一例）を利用するために使用する計算機である。クライアント１００では、ブロックチェーンサービスを利用するためのクライアントプログラムが動作する。クライアントプログラムをサーバ１２０で動作させることで、サーバ１２０がクライアント１００を兼用してもよい。

ネットワーク１１０は、クライアント１００と、サーバ１２０と、管理サーバ１３０と、を相互に接続するネットワークである。ネットワーク１１０は、例えばLocal Area Network（LAN）やWide Area Network（WAN）である。

サーバ１２０は、クライアント１００に対してブロックチェーンサービスを提供する計算機である。サーバ１２０は、ネットワークインタフェース１５０、ディスクドライブ１８０、ディスクコントローラ１６０、メモリ１７０、および、それらに接続されたＣＰＵ１４０を有する。ネットワークインタフェース１５０が、インタフェース部の一例である。ディスクドライブ１８０およびメモリ１７０が、記憶部の一例である。ディスクコントローラ１６０およびＣＰＵ１４０が、プロセッサ部の一例である。ＣＰＵ１４０は、メモリ１７０に格納されたプログラムを実行する。ネットワークインタフェース１５０は、クライアント１００との通信に使用される。ディスクドライブ１８０は、ＰＤＥＶの一例であり、例えば後述のブロックチェーンデータ１９０のようなデータセットを格納する。ディスクコントローラ１６０は、ディスクドライブ１８０への入出力を制御する。メモリ１７０は、プログラムやデータを格納する。ネットワークインタフェース１５０、ディスクドライブ１８０、ディスクコントローラ１６０、メモリ１７０、および、ＣＰＵ１４０は、内部的な通信路（例えば、バス）によって接続されていてよい。なお、サーバ１２０は、仮想マシンでもよい。

サーバ１２０のメモリ１７０には、プログラムやデータが格納される。ＣＰＵ１４０により実行されるプログラムは、例えば、ブロックチェーンプログラム２００および取得プログラム２０１である。本実施例は、ブロックチェーンサービスを提供する主体が、例としてブロックチェーンプログラム２００であることを前提に説明する。

ブロックチェーンプログラム２００は、クライアント１００に対して、他のサーバ１２０におけるブロックチェーンプログラム２００と協調してスマートコントラクトをサービスし、クライアント１００から受信したトランザクション要求に基づいてスマートコントラクトを実行する。

ディスクコントローラ１６０は、メモリ１７０に格納された各種プログラムの入出力要求に基づいて、ディスクドライブ１８０のデータを例えばブロック単位で入出力する。

ディスクドライブ１８０は、メモリ１７０に格納された各種プログラムが読み書きするデータを格納するための記憶デバイスである。本実施例において、ディスクドライブ１８０には、ブロックチェーンデータ１９０が格納される。

管理サーバ１３０は、ブロックチェーンシステムを管理する計算機であり、管理システムの一例である。「管理システム」は、一以上の計算機で構成されてよい。具体的には、例えば、管理計算機が表示デバイスを有していて管理計算機が自分の表示デバイスに情報を表示する場合、管理計算機が管理システムでよい。また、例えば、管理計算機が表示用情報を遠隔の表示用計算機に送信し表示用計算機がその情報を表示する場合（管理計算機が表示用計算機に情報を表示する場合）、管理計算機と表示用計算機とのうちの少なくとも管理計算機を含んだシステムが管理システムでよい。管理システムにおける計算機が「表示用情報を表示する」ことは、計算機が有する表示デバイスに表示用情報を表示することであってもよいし、計算機が表示用計算機に表示用情報を送信することであってもよい（後者の場合は表示用計算機によって表示用情報が表示される）。

管理サーバ１３０は、定められた周期でサーバ１２０の生存（ダウンしているか否か）の確認や、その確認結果に基づきリカバリ処理を行ったり、ブロックチェーンシステム管理者（以下、管理者）からブロックチェーンシステムに関する情報の登録を受け付けたりする。管理サーバ１３０は、ネットワークインタフェース５０（インタフェース部の一例）、メモリ７０（記憶部の一例）およびそれらに接続されたＣＰＵ４０（プロセッサ部の一例）を有する。メモリ７０が、ブロックチェーン管理プログラム３００を格納する。ブロックチェーン管理プログラム３００は、ＣＰＵ４０により実行されることで、サーバ１２０の生存を定期的に確認し、ダウンしていればリカバリ処理を行う。なお、ブロックチェーン管理プログラム３００が、クライアント１００およびサーバ１２０のいずれかで動作されてもよく、その場合、クライアント１００が管理サーバ１３０を兼用してもよいし、サーバ１２０が管理サーバ１３０を兼用してもよい。

ブロックチェーンシステムを構成する１以上（典型的には複数）のサーバ１２０が、１以上（典型的には複数）の拠点１０１に存在する。各拠点１０１は、データセンタまたは同一のネットワークセグメントである。少なくとも１つの拠点１０１に管理サーバ１３０が配置されてよい。例えば、クラウド環境においては、多数のデータセンタが存在し、各データセンタ内に仮想マシンが作成され、それら仮想マシンは拠点１０１間のネットワーク１１０により接続される。

図２は、ブロックチェーンプログラム２００の機能構成を示すブロック図である。なお、図２の説明において、図２に示すブロックチェーンプログラム２００を実行するサーバ１２０を、「自サーバ１２０」と言い、自サーバ１２０以外のサーバ１２０のうちの少なくとも１つを「他サーバ１２０」と言う。また、図２に示すブロックチェーンプログラム２００を実行するサーバ１２０が存在する拠点１０１を「自拠点１０１」と言い、自拠点１０１以外の拠点１０１のうちの少なくとも１つを「他拠点１０１」と言う。

ブロックチェーンプログラム２００は、スマートコントラクト２１０と、トランザクション処理モジュール２２０と、サーバ追加処理モジュール２３０と、チャネル更新処理モジュール２４０と、を備える。

スマートコントラクト２１０は、自サーバ１２０のＣＰＵ１４０によって実行される。スマートコントラクト２１０は、例えば、仮想通貨や証券といった金融資産の取引を処理するためのプログラムである。なお、スマートコントラクト２１０は複数種存在してもよい。トランザクションとスマートコントラクト２１０は、１：１、１：Ｎ（Ｎは２以上の整数）、Ｍ：１（Ｍは２以上の整数）、またはＭ：Ｎで対応してよい。

トランザクション処理モジュール２２０は、クライアント１００からのトランザクション要求を契機として、自サーバ１２０のＣＰＵ１４０によって実行される。トランザクション処理モジュール２２０は、トランザクション要求を受信し、当該トランザクション要求に基づいて、対応するスマートコントラクト２１０を実行する。さらに、トランザクション処理モジュール２２０は、実行結果を、当該モジュール２２０を実行するサーバ１２０が属する１以上のチャネルに属する１以上の他サーバ１２０に分配し、確定した上で、クライアント１００にトランザクション処理結果を応答する。ここで、「チャネル」とは、ブロックチェーンシステムにおけるデータ共有範囲を意味し、具体的には、１以上のサーバ１２０で構成されたグループのことである。同一チャネルに属するサーバ１２０間のみでデータの共有を行うことができる。

サーバ追加処理モジュール２３０は、管理者が新たなサーバ１２０を追加した際に、管理者からの指示に基づいて、自サーバ１２０のＣＰＵ１４０によって実行される。サーバ追加処理モジュール２３０は、他拠点１０１のサーバ１２０との通信速度を計測し、拠点間通信速度情報６００を更新する。このとき、自拠点１０１または他拠点１０１内に複数のサーバ１２０が存在する場合は、サーバ追加処理モジュール２３０は、例えば、自サーバ１２０と自拠点１０１または他拠点１０１内の２以上の他サーバ１２０との通信速度に基づく通信速度（例えば、平均速度、最高速度および最低速度のうちのいずれか）を求め（または、自拠点１０１または他拠点１０１内の代表他サーバとの通信速度を求め）、自拠点１０１内の通信速度、または、他拠点１０１との通信速度として、拠点間通信速度情報６００を更新する。また、自拠点１０１内のサーバ１２０が自サーバ１２０のみの場合は、自サーバ１２０のネットワークインタフェース１５０（例えばNIC（Network Interface Card））の限界速度が、自拠点１０１内の通信速度でもよい。

チャネル更新処理モジュール２４０は、管理者がチャネルを作成する際や、サーバ１２０をチャネルに加える際に利用される。具体的には、例えば、管理者は、サーバ１２０上のブロックチェーンプログラム２００に、サーバＩＤとチャネルＩＤを指定したチャネル作成指示を与える。チャネル更新処理モジュール２４０は、そのチャネル作成指示に応答して、その指示で指定されたサーバＩＤをもつエントリの参加チャネルＩＤリスト４２０（図４参照）に、チャネル作成指示で指定されたチャネルＩＤを加える。なお、そのようなエントリが存在しない場合、チャネル更新処理モジュール２４０は、エントリを新規に作成する。ブロックチェーンプログラム２００が、クライアント１００から、チャネルＩＤを指定したトランザクション要求を受信した場合、その要求に従うトランザクションを実行し、その指定されたチャネルＩＤに属する他サーバ１２０上のブロックチェーンプログラム２００に、トランザクションの実行結果を配信する。

図３は、ブロックチェーン管理プログラム３００の構成例を示す図である。

ブロックチェーン管理プログラム３００は、リカバリ処理モジュール３１０と、拠点決定モジュール３２０と、定期監視モジュール３３０とを有し、サーバ情報４００と、累計データ量情報５００と、拠点間通信速度情報６００と、を管理する。

リカバリ処理モジュール３１０は、ハードビート信号の断絶などでサーバ１２０のダウンを検知し、拠点決定モジュール３２０を利用して新サーバを作成するべき位置（以下、リストア先拠点）を判断し、そのリストア先拠点にサーバ１２０を新たに作成する。なお、作成するサーバは仮想マシンでもよい。そして、リカバリ処理モジュール３１０は、ダウンしたサーバ１２０が保持していたデータを、リストア先拠点を判断する際に利用した情報の少なくとも一部を基に、通信速度が高速であるサーバから優先的にリストア先拠点におけるリストア先サーバにリストアする。

拠点決定モジュール３２０は、サーバ情報４００と、累計データ量情報５００と、拠点間通信速度情報６００と、を基に、ダウンしたサーバが所持していた全データを最短時間でリストア可能なリストア先拠点を決定する。

定期監視モジュール３３０は、あらかじめ定められたスケジュールに基づいて、管理サーバ１３０のＣＰＵ４０によって定期的に実行され、ブロックチェーンデータ１９０の容量の合計を各チャネルについて求め、累計データ量情報５００を更新する。

サーバ情報４００は、サーバ、チャネルおよび拠点の関係を示す情報である。累計データ量情報５００は、ブロックチェーンデータ１９０の合計容量を各チャネルについて示す情報である。拠点間通信速度情報６００は、各拠点間の通信速度を示す情報であり、サーバ１２０の追加時または予め定められた周期にてブロックチェーンプログラム２００により更新される。

図４は、サーバ情報４００の構成例を示す図である。

サーバ情報４００は、例えばテーブルであり、サーバ毎にエントリを有する。各エントリは、サーバＩＤ４１０、参加チャネルＩＤリスト４２０および拠点ＩＤ４３０といった情報を格納する。以下、１のサーバ１２０（図４の説明において「対象サーバ１２０」）を例に取る。

サーバＩＤ４１０は、対象サーバ１２０を識別するためのＩＤである。参加チャネルＩＤリスト４２０は、対象サーバ１２０が属するチャネルを識別するためのＩＤの一覧である。拠点ＩＤ４３０は、対象サーバ１２０が属する拠点を識別するためのＩＤである。

図５は、累計データ量情報５００の構成例を示す図である。

累計データ量情報５００は、例えばテーブルであり、チャネル毎にエントリを有する。各エントリは、チャネルＩＤ５１０および累計データ量５２０といった情報を格納する。以下、１のチャネル（図５の説明において「対象チャネル」）を例に取る。

チャネルＩＤ５１０は、対象チャネルのＩＤである。累計データ量５２０は、対象チャネルが扱うデータの合計容量（累計データ量）を示す。

図６は、拠点間通信速度情報６００の構成例を示す図である。

拠点間通信速度情報６００は、例えば、拠点ＩＤ６１０と拠点ＩＤ６２０とのマトリックスである。各セルは、当該セルに対応した拠点ＩＤ６１０が示す拠点と、当該セルに対応した拠点ＩＤ６２０が示す拠点との間の通信速度を示す値を格納する。

以下、本実施例で行われる処理の一例を説明する。

図７は、トランザクション処理のフローチャートの一例である。

ブロックチェーンプログラム２００のトランザクション処理モジュール２２０は、クライアント１００からトランザクション要求を受信する（Ｓ７１０）。トランザクション要求は、チャネルＩＤやパラメータ（例えば、スマートコントラクトを指定するパラメータ）を含む。

次に、トランザクション処理モジュール２２０は、トランザクション要求で指定されたスマートコントラクト２１０を実行する（Ｓ７２０）。ここで、スマートコントラクトの実行結果、すなわち、戻り値やブロックチェーンデータ１９０に反映するデータは、合意形成処理で使用するためメモリ１７０に退避しておく。

そして、トランザクション処理モジュール２２０は、合意形成処理を実施する（Ｓ７３０）。合意形成処理は、複数のサーバ１２０でアトミックにスマートコントラクト実行結果をブロックチェーンデータ１９０に書き込むために行われる。

次に、トランザクション処理モジュール２２０は、トランザクション要求に含まれるチャネルＩＤのチャネルに属するサーバ１２０にスマートコントラクトの実行結果を配信する（Ｓ７４０）。

そして、トランザクション処理モジュール２２０は、スマートコントラクトの実行結果をブロックチェーンデータ１９０に書き込む（Ｓ７５０）。

最後に、トランザクション処理モジュール２２０は、トランザクション要求に対する応答をクライアント１００に送信する（Ｓ７６０）。

図８は、サーバ追加処理のフローチャートの一例である。管理者などが新たなサーバ１２０を拠点１０１に追加したことを契機として、サーバ追加処理が行われる。以下、図８の説明において、追加されたサーバ１２０を「追加サーバ１２０」と言い、サーバ１２０の追加先の拠点１０１を、「追加先拠点１０１」と言う。

まず、追加サーバ１２０内の取得プログラム２０１が、追加サーバ１２０のサーバＩＤと、追加先拠点の拠点ＩＤとを、ブロックチェーン管理プログラム３００に通知する（Ｓ８１０）。ブロックチェーン管理プログラム３００は、その通知に基づいてサーバ情報４００を更新する（例えば、追加サーバ１２０に対応したエントリを追加し、当該エントリに、サーバＩＤ及び拠点ＩＤを格納する）。

次に、追加サーバ１２０内の取得プログラム２０１が、追加サーバ１２０と他拠点内のサーバ１２０との通信速度を計測する（Ｓ８２０）。

そして、追加サーバ１２０内の取得プログラム２０１が、計測した通信速度を、ブロックチェーン管理プログラム３００に通知する（Ｓ８３０）。ブロックチェーン管理プログラム３００は、その通知された通信速度に基づいて拠点間通信速度情報６００を更新する。更新後に新たに採用する値は、例えば、古い値（既に登録されている値）とＳ８３０により通知された値との平均値、最大値および最小値のいずれでもよい。

図９は、リカバリ処理のフローチャートの一例である。リカバリ処理は、例えば、あらかじめ定められたスケジュールに基づいて実行される。

リカバリ処理モジュール３１０は、各サーバ１２０について、ハートビート信号などを基に、サーバ１２０がダウンしているか否かを判断する（Ｓ９１０）。いずれかのサーバ１２０がダウンしていると判断された場合（Ｓ９１０：Ｙｅｓ）、Ｓ９２０が行われる。以下、ダウンしたサーバ１２０を「障害サーバ１２０」と言う。

次に、リカバリ処理モジュール３１０は、拠点決定モジュール３２０にリストア先拠点決定処理を実行させることで、リストア先拠点を特定する（Ｓ９２０）。

次に、リカバリ処理モジュール３１０は、Ｓ９２０で特定したリストア先拠点におけるサーバをリストア先サーバとして選択するリストア先サーバ選択処理を実行する（Ｓ９３０）。リストア先サーバ選択処理は、例えばサーバ情報４００を基に行われる。なお、リストア先サーバは、新たに作成されたサーバでもよいし、既存の予備のサーバであってもよい。新たに作成されたサーバは、例えば、クラウドコンピューティングシステムなどが提供するAPI（Application Programming Interface）を利用して自動作成されたサーバでもよいし、管理者によって手動作成されたサーバでもよい。

最後に、リカバリ処理モジュール３１０は、障害サーバ１２０が保持していたブロックチェーンデータ１９０と同じデータ（以下、リストア対象データ）をリストア先サーバにリストアするデータリストア処理を実行する（Ｓ９４０）。データリストア処理は、各リストア対象データについて、例えば、下記のうちのいずれかでよい。なお、同一のリストア対象データを格納している他サーバが２以上ある場合、リストア先拠点間との通信速度が最も早い拠点１０１の他サーバ１２０がリストア元サーバとされてよい。
・リカバリ処理モジュール３１０が、他サーバ１２０からリストア対象データを読み込み、当該リストア対象データをリストア先サーバ１２０に書き込む。
・リカバリ処理モジュール３１０が、リストア元サーバ１２０にリストア指示を送信する。リストア指示には、例えば、リストア対象データのＩＤとリストア先サーバのＩＤとが指定されている。当該リストア指示を受けたリストア元サーバ１２０（例えばブロックチェーンプログラム２００）は、リストア指示で指定されているリストア対象データを、そのリストア指示で指定されているリストア先サーバに書き込む。
・リカバリ処理モジュール３１０が、リストア先サーバ１２０にリストア指示を送信する。リストア指示には、例えば、リストア対象データのＩＤとリストア元サーバのＩＤとが指定されている。当該リストア指示を受けたリストア先サーバ１２０（例えばブロックチェーンプログラム２００）は、リストア指示で指定されているリストア対象データを、そのリストア指示で指定されているリストア元サーバから読み込む。

図１０は、リストア先拠点決定処理のフローチャートの一例である。リストア先拠点決定処理は、リカバリ処理モジュール３１０からの要求、または、管理者からの指示に応答して実行されてよい。当該要求または当該指示では、障害サーバのＩＤが指定されている。

まず、拠点決定モジュール３２０は、指定されたサーバＩＤ（障害サーバのサーバＩＤ）に対応した参加チャネルＩＤリスト４２０を参照して、障害サーバが属するチャネルを特定する（Ｓ１０１０）。リカバリ処理では、ここで特定したチャネルに属する全ブロックチェーンデータ１９０と同じデータ（リストア対象データ）を他サーバ１２０から取得する必要がある。

次に、拠点決定モジュール３２０は、各拠点について、Ｓ１０３０を行う。以下、１の拠点（図１０の説明において「対象拠点」）を例に取る。

拠点決定モジュール３２０は、累計データ量情報５００と拠点間通信速度情報６００とを基に、全リストア対象データ（Ｓ１０１０で特定した全チャネルが扱うブロックチェーンデータ）を対象拠点に転送するのに要する転送時間である全データ転送時間を算出する（Ｓ１０３０）。全データ転送時間は、Ｓ１０３０で特定されたＸ個のチャネル（Ｘは自然数）にそれぞれ対応したＸの転送時間の合計である。各チャネルについて、転送時間は、リストア対象データのデータ量（累計データ量）と、リストア対象データを保持する拠点と対象拠点間の通信速度とを基に算出される（例えば、転送時間＝累計データ量／通信速度）。或るチャネルについて、リストア対象データを保持する拠点が２以上存在する場合、２以上の転送時間があるが、その２以上の転送時間のうちのいずれかの転送時間の一例として最短の転送時間が、当該チャネルについての転送時間とされる。言い換えれば、２以上の拠点のうち対象拠点間との通信速度が最も早い拠点が、リストア元の拠点として採用される。

このようにして、各拠点について、全データ転送時間が算出される。拠点決定モジュール３２０は、全ての全データ転送時間のうちのいずれかの全データ転送時間の一例として最短の全データ転送時間に対応した拠点を、リストア先拠点として決定する（Ｓ１０４０）。拠点決定モジュール３２０は、決定したリストア先拠点の拠点ＩＤを、出力する（Ｓ１０５０）。具体的には、例えば、拠点ＩＤは、リカバリ処理モジュール３１０に出力されてもよいし、管理者に対して表示されてもよい。

なお、上記の例では説明の簡単のため、Ｓ１０３０が、全ての拠点１０１について行われるが、Ｓ１０３０が行われる拠点は、例えば、障害サーバが属していたチャネルと同一のチャネルに属するサーバ１２０が存在する拠点１０１のみに限定してもよい。例えば、図４を例に取り説明すると、サーバ１００１（サーバＩＤが“１００１”であるサーバ）が障害サーバの場合、サーバ１００１が属するチャネルAに属する他サーバが存在する拠点は拠点６００２（拠点ＩＤが“６００２”の拠点）および拠点６００３のみであり、その２つ拠点のみを、Ｓ１０３０が行われる拠点（すなわち、Ｓ１０３０の説明での「対象拠点」となる拠点）とすることもできる。

また、Ｓ１０３０およびＳ１０４０のステップを省くこともできる。例えば、図４を例に取り説明すると、サーバ１００６が障害サーバの場合、サーバ１００６が属するチャネルＥに属する他サーバが存在する拠点は６００５のみであり、拠点６００５の拠点ＩＤがリストア先拠点の拠点ＩＤとしてＳ１０５０にて出力されてもよい。

図１１は、定期監視処理のフローチャートの一例である。定期監視処理は、管理者からの指示に応答して、または、あらかじめ定められたスケジュールに基づいて実行される。

定期監視モジュール３３０は、全てのチャネルについて、Ｓ１１２０を行う。以下、１のチャネルを例に取る（図１１の説明において「対象チャネル」）。

定期監視モジュール３３０は、対象チャネルが扱うデータ量の合計、すなわち累計データ量を算出する（Ｓ１１２０）。Ｓ１１２０は、例えば、定期監視モジュール３３０が、各サーバ１２０のブロックチェーンデータ１９０の容量を取得することで実現可能である。

定期監視モジュール３３０は、各チャネルについての累計データ量を累計データ量情報５００に登録することにより累計データ量情報５００を更新する（Ｓ１１３０）。

また、定期監視処理において、拠点間通信速度情報６００が更新されてもよい。例えば、定期監視モジュール３３０は、Ｓ１１２０において、対象拠点と他の各拠点との通信速度の計測を対象拠点内のサーバに依頼し、Ｓ１１３０において、その依頼に応答して通知された通信速度を基に、拠点間通信速度情報６００を更新してもよい。

以上、本実施例によれば、サーバ情報４００と、累計データ量情報５００と、拠点間通信速度情報６００とを基に、リストア先拠点として、全データ転送時間が最短となる拠点が決定される。このため、複数のサーバにデータを分散保存するブロックチェーンシステムにおいて、データの高可用化のためのリカバリに要する時間を短縮できる。リカバリに要する時間が短縮されることにより、ブロックチェーンシステムのトランザクション処理性能が低下する時間を短縮できる。

以下、図面を用いて本発明の第二の実施例を詳細に説明する。その際、第一の実施例との相違点を主に説明し、第一の実施例との共通点については説明を省略または簡略する。第二の実施例では、ファイルが、データセットの一例である。

図１２は、本発明の第二の実施例に係る分散ファイルシステムの概略構成を示すブロック図である。分散ファイルシステムは、分散コンピューティングシステムの一例である。

クライアント１２００が、ネットワークインタフェース１２５０、メモリ１２７０、および、それらに接続されているＣＰＵ１２４０を有する。ネットワークインタフェース１２５０は、ネットワーク１１０に接続される。メモリ１２７０が、クライアントプログラム１３００を格納している。

サーバ１２２０内のメモリ１７０が、分散プログラム１４００を格納する。ＣＰＵ１４０が、分散プログラム１４００を実行する。ディスクドライブ１８０が、ファイルデータ１２３９を格納する。

管理サーバ１２３０内のメモリ７０が、管理プログラム１５００を格納する。ＣＰＵ４０が、管理プログラム１５００を実行する。

なお、管理プログラム１５００およびクライアントプログラム１３００の少なくとも１つを管理サーバ１２３０で動作させることで、管理サーバ１２３０が、クライアント１２００およびサーバ１２２０のうちの少なくとも１つを兼用してもよい。なお、クライアント１２００、サーバ１２２０および管理サーバ１２３０のうちの少なくとも１つは、仮想マシンでもよい。本実施例では、分散ファイルサービスを提供する主体が、例として分散プログラム１４００である。また、拠点の図示は省略されているが、第一の実施例と同様、第二の実施例においても、拠点１０１は存在する。

分散プログラム１４００は、クライアント１２００に対して、他のサーバ１２２０における分散プログラム１４００と、管理プログラム１５００と、協調して分散ファイルシステムをサービスし、クライアント１２００から受信したファイル読み書き要求に基づいてファイル内容の取得および保存を行う。

図１３は、クライアントプログラム１３００の機能構成を示すブロック図である。

クライアントプログラム１３００は、読込み処理モジュール１３１０と、書込み処理モジュール１３２０と、を備える。

読込み処理モジュール１３１０は、分散ファイルシステム利用者（以下、利用者）のファイル読込み指示を契機として、クライアント１２００のＣＰＵ１２４０によって実行される。読込み処理モジュール１３１０は、ファイルを読み込むべきサーバ１２２０を管理プログラム１５００に問い合わせ、その問合せに応答して回答されたサーバ１２２０に対して、読込み要求を送信する。

書込み処理モジュール１３２０は、利用者のファイル書込み指示を契機として、クライアント１２００のＣＰＵ１２４０によって実行される。書込み処理モジュール１３２０は、ファイルを書き込むべきサーバ１２２０を管理プログラム１５００に問い合わせ、その問合せに応答して回答されたサーバ１２２０に対して、書込み要求を送信する。

図１４は、分散プログラム１４００の機能構成を示すブロック図である。

分散プログラム１４００は、ファイル読込みモジュール１４１０と、ファイル書込みモジュール１４２０と、サーバ追加処理モジュール２３０と、を備える。

ファイル読込みモジュール１４１０は、クライアントプログラム１３００からの読込み要求に基づいて、その要求で指定されたファイルを読み込み、読み込んだファイルをクライアントプログラム１３００に返す。

ファイル書込みモジュール１４２０は、クライアントプログラム１３００からの書込み要求に基づいて、その要求で指定されたファイルを書き込む。さらに、ファイル書込みモジュール１４２０は、書込み対象のファイルに対応したファイルサイズ１８２０（図１８参照）を、書込み後のファイルサイズに更新する。また、書込み要求がレプリケーション用の書込み要求でない場合、ファイル書込みモジュール１４２０は、書込み対象のファイルに対応したマスタサーバＩＤ１８３０として、自サーバ（図１４の分散プログラム１４００を実行するサーバ）のサーバＩＤを格納する。また、書込み要求がレプリケーション用の書込み要求であった場合、ファイル書込みモジュール１４２０は、書込み対象のファイルに対応したレプリケーション先サーバＩＤリスト１８４０に、自サーバのサーバＩＤを加える。

図１５は、管理プログラム１５００の構成例を示す図である。

管理プログラム１５００は、保存先判断モジュール１５１０と、リカバリ処理モジュール３１０と、拠点決定モジュール１５２０と、レイアウト情報更新モジュール１５３０と、レプリケーション情報更新モジュール１５４０とを有し、サーバ情報１６００と、レプリケーション情報１７００と、ファイル情報１８００と、拠点間通信速度情報６００とを管理する。管理プログラム１５００は、ファイル情報１８００などにより、分散ファイルシステムのメタデータサーバのように振る舞い、分散プログラム１４００は管理プログラム１５００と協調することで分散ファイルシステムサービスを提供する。また、管理プログラム１５００は、リカバリ処理モジュール３１０などにより、分散ファイルシステムにおけるリカバリ処理などの運用管理も行う。

保存先判断モジュール１５１０は、ファイルを読み書きするべきサーバの特定処理を行う。

例えば、保存先判断モジュール１５１０が、クライアントプログラム１３００の読込み処理モジュール１３１０から、ファイル名を指定した読込み問合せ（指定したファイル名のファイルを読み込むサーバの問合せ）を受信すると、保存先判断モジュール１５１０は、ファイル情報１８００（図１８参照）から、その指定されたファイル名をファイル名１８１０として持つエントリを特定する。そして、そのエントリのマスタサーバＩＤをクライアントプログラム１３００に返す。

また、例えば、保存先判断モジュール１５１０が、クライアントプログラム１３００の書込み処理モジュール１３２０から、ファイル名を指定した書込み問合せ（指定したファイル名のファイルを書き込むサーバの問合せ）を受信すると、保存先判断モジュール１５１０は、書込み先サーバＩＤと、レプリケーション用の書込み先サーバＩＤを返す。具体的には、例えば、保存先判断モジュール１５１０は、その指定されたファイル名がファイル情報１８００に存在するかを確認する。存在した場合、保存先判断モジュール１５１０が、ファイル名が存在するエントリのマスタサーバＩＤを、書き込み先サーバＩＤとする。存在しない場合、保存先判断モジュール１５１０が、その指定されたファイル名のハッシュ値を求め、そのハッシュ値がサーバ情報１６００のハッシュ値最小値１６２０とハッシュ値最大値１６３０との範囲に収まるエントリのサーバＩＤを、書込み先サーバＩＤとする。また、レプリケーション用の書込み先サーバＩＤに関しては、例えば、保存先判断モジュール１５１０が、レプリケーション情報１７００（図１７参照）から、先の書込み先サーバＩＤをレプリケーション元サーバＩＤ１７１０として持つエントリを特定する。そして、保存先判断モジュール１５１０が、そのエントリのレプリケーション先サーバＩＤ１７２０が含む１以上のサーバＩＤの少なくとも１つを（例えば、ランダムまたはラウンドロビンで選択した少なくとも１つのサーバＩＤ）を、レプリケーション用の書込み先サーバＩＤとする。最後に、保存先判断モジュール１５１０は、書込み先サーバＩＤと、レプリケーション用の書込み先サーバＩＤとをクライアントプログラム１３００に返す。

拠点決定モジュール１５２０は、ファイル情報１８００と、サーバ情報１６００と、拠点間通信速度情報６００と、を元に、リストア先拠点を決定する。

レイアウト情報更新モジュール１５３０は、利用者からのレイアウト情報更新指示を契機として、管理サーバ１２３０のＣＰＵ４０によって実行される。レイアウト情報更新モジュール１５３０は、各サーバ１２２０が保持すべきファイルのファイル名のハッシュ値の範囲を求め、サーバ情報１６００を更新する。

レプリケーション情報更新モジュール１５４０は、分散ファイルシステム管理者（以下、管理者）によるレプリケーション情報更新指示を契機として、管理サーバ１２３０のＣＰＵ４０によって実行され、管理者のレプリケーション元サーバＩＤとレプリケーション先サーバＩＤの指定に基づいて、レプリケーション情報１７００を更新する。

サーバ情報１６００は、サーバ１２２０、ファイル及び拠点の関係を示す情報である。

レプリケーション情報１７００は、同一のデータを保持するべきサーバ１２２０の情報を保持する。クライアントプログラム１３００は、書込み処理において、マスタへの書き込みと同一の書込み要求を、レプリケーション対象の１以上のサーバ１２２０に同期的または非同期的に送信する。具体的には、例えば、クライアントプログラム１３００の書込み処理モジュール１３２０は、まず保存先判断モジュール１５１０に上述の書込み問合せを送信する。保存先判断モジュール１５１０は、書込み問合せで指定されているファイルをどのサーバにレプリケーションするべきかをレプリケーション情報１７００などを基に判断し、その判断結果を書込み処理モジュール１３２０に返す。そして、書込み処理モジュール１３２０は、先の問合せ結果に基づき、レプリケーション対象の１以上のサーバ１２２０に同期的または非同期的にマスタへの書き込みと同一の書込み要求を送信する。

ファイル情報１８００は、分散ファイルシステムが扱う各ファイルの情報を保持する。後述するように、ファイル情報１８００は、各ファイルのファイルサイズと、ファイルを保持するサーバのＩＤと、レプリケーション先サーバＩＤのリストと、を持つ。リカバリ処理において、拠点決定モジュール１５２０は、ファイル情報１８００と、サーバ情報１６００と、拠点間通信速度情報６００と、を基に、リカバリが最も早く終わるリストア先拠点を決定する。

図１６は、サーバ情報１６００の構成例を示す図である。

サーバ情報１６００は、例えばテーブルであり、サーバ毎にエントリを有する。各エントリは、サーバＩＤ１６１０、ハッシュ値最小値１６２０、ハッシュ値最大値１６３０、拠点ＩＤ１６４０およびサーバ種別１６５０といった情報を格納する。以下、１のサーバ１２２０（図１６の説明において「対象サーバ１２２０」）を例に取る。

サーバＩＤ１６１０は、対象サーバ１２２０を識別するためのＩＤである。ハッシュ値最小値１６２０は、対象サーバが保持するべきファイルのファイル名のハッシュ値の最小値である。ハッシュ値最大値１６３０は、対象サーバが保持するべきファイルのファイル名のハッシュ値の最大値である。拠点ＩＤ１６４０は、対象サーバ１２２０が属する拠点を識別するためのＩＤである。サーバ種別１６５０は、対象サーバ１２０の種別（例えば“マスタ”または“レプリカ”）を示す。

ハッシュ値最小値１６２０およびハッシュ値最大値１６３０は、ファイル名のハッシュ値が両者の範囲に収まるファイルが、対象サーバ１２２０に保存されることを意図する。ハッシュ値最小値１６２０とハッシュ値最大値１６３０とに関しては、管理者からのレイアウト情報更新指示を契機として、レイアウト情報更新モジュール１５３０が、サーバ種別“マスタ”に対応した１以上のサーバ１２２０の各々について、当該サーバ１２２０が保持すべきファイルのファイル名のハッシュ値の範囲を求め、サーバ情報１６００のハッシュ値最小値１６２０とハッシュ値最大値１６３０とを更新する。

図１７は、レプリケーション情報の構成例を示す図である。

レプリケーション情報１７００は、例えばテーブルであり、レプリケーション毎にエントリを有する。各エントリは、レプリケーション元サーバＩＤ１７１０と、レプリケーション先サーバＩＤ１７２０といった情報を格納する。以下、１のレプリケーション（図１７の説明において「対象レプリケーション」）を例に取る。

レプリケーション元サーバＩＤ１７１０は、対象レプリケーションに関してレプリケーション元のサーバのＩＤである。対象レプリケーションに関してレプリケーション先のサーバのＩＤである。なお、レプリケーション先サーバＩＤ１７２０として格納されるサーバＩＤは、一つでも、複数でもよい。

レプリケーション情報１７００は、管理者からのレプリケーション情報更新指示を契機として、レプリケーション情報更新モジュール１５４０により更新される。管理者は、分散ファイルシステムが保持するデータの冗長度に関する要件などを基に、レプリケーション先サーバＩＤ１７２０に指定するサーバＩＤの数などを決定し、レプリケーション情報更新モジュール１５４０にサーバＩＤの数のようなパラメータを指定した上記の更新指示を送信する。

図１８は、ファイル情報の構成例を示す図である。

ファイル情報１８００は、例えばテーブルであり、ファイル毎にエントリを有する。各エントリは、ファイル名１８１０、とファイルサイズ１８２０と、マスタサーバＩＤ１８３０と、レプリケーション先サーバＩＤリスト１７４０といった情報を格納する。以下、１のファイル（図１８の説明において「対象ファイル」）を例に取る。

ファイル名１８１０は、対象ファイルのファイル名である。ファイルサイズ１８２０は、対象ファイルのサイズを示す。マスタサーバＩＤ１８３０は、対象ファイルを保存するマスタサーバ（サーバ種別１６５０が“マスタ”であるサーバ）のＩＤである。レプリケーション先サーバＩＤリスト１８４０は、対象ファイルのレプリケーション先サーバのＩＤのリストである。レプリケーション先サーバＩＤリスト１８４０に含まれるサーバＩＤの数は、対象ファイルの重要度（例えば、ファイル識別子、更新頻度またはファイルサイズなどによって決定された値）に応じて決められてよい。

クライアントプログラム１３００の書込み処理モジュール１３２０による書込み要求またはレプリケーション用書込み要求を、分散プログラム１４００のファイル書込みモジュール１４２０が受け取った際に、ファイル書込みモジュール１４２０によりファイル情報１８００のエントリが作成または更新される。

図１９は、書込み処理のフローチャートの一例である。

まず、書込み処理モジュール１３２０は、管理プログラム１５００の保存先判断モジュール１５１０に対して、書込み問合せを送信する（Ｓ１９１０）。具体的には、例えば、書込み処理モジュール１３２０は、保存先判断モジュール１５１０に、書込み対象のファイル名を指定した書込み問合せを送信し、保存先判断モジュール１５１０から、書込みサーバＩＤ（書き込みを行うべきサーバのサーバＩＤ）と、レプリケーション用サーバＩＤ（レプリケーション用の書き込みを行うべきサーバのサーバＩＤ）とを受ける。

次に、書込み処理モジュール１３２０は、Ｓ１９１０で得た書込みサーバＩＤに対応したサーバ１２２０に、書込み対象のファイルの書込み要求を送信する（Ｓ１９２０）。その書込み要求は、分散プログラム１４００のファイル書込みモジュール１４２０により処理される。

最後に、書込み処理モジュール１３２０は、Ｓ１９１０で得たレプリケーション用サーバＩＤに対応したサーバ１２２０に、レプリケーション用の書込み要求を送信する（Ｓ１９３０）。レプリケーション用の書込み要求は、分散プログラム１４００のファイル書込みモジュール１４２０により処理される。Ｓ１９３０は、非同期的に行われる場合もある。

図２０は、リストア先拠点決定処理のフローチャートの一例である。リストア先拠点決定処理は、リカバリ処理モジュール３１０の要求に応答して実行されるが、リストア先拠点の助言を得るために管理者からの指示に応答して実行されてもよい。

拠点決定モジュール１５２０は、全ての拠点１０１について、Ｓ２０１０〜Ｓ２０３０を行う。以下、一の拠点を例に取る（図２０の説明において「対象拠点」）。

次に、拠点決定モジュール１５２０は、全てのファイルについて、Ｓ２０１０及びＳ２０２０を行う。以下、一のファイルを例に取る（図２０の説明において「対象ファイル」）。

拠点決定モジュール１５２０は、対象ファイルがレプリケーション対象か否を判断する（Ｓ２０１０）。対象ファイルに対応したマスタサーバＩＤ１８３０が、障害サーバのサーバＩＤの場合、Ｓ２０１０の判断結果が真となる。

Ｓ２０１０の判断結果が真の場合（Ｓ２０１０：Ｙｅｓ）、拠点決定モジュール１５２０は、対象ファイルのファイル転送時間を、拠点間通信速度情報６００と、サーバ情報１６００と、ファイル情報１８００と、を基に算出する（Ｓ２０２０）。具体的には、例えば、拠点決定モジュール１５２０は、以下の処理を行う。
・拠点決定モジュール１５２０は、対象ファイルに対応したレプリケーション先サーバＩＤリスト１８４０に含まれる１以上のレプリケーション先サーバＩＤを特定する。
・拠点決定モジュール１５２０は、サーバ情報１６００から、特定した１以上のレプリケーション先サーバＩＤに対応した１以上の拠点（図２０の説明において、「レプリケーション先拠点」）を特定する。
・拠点決定モジュール１５２０は、１以上のレプリケーション先拠点の各々について、拠点間通信速度情報６００から、対象拠点と当該レプリケーション先拠点との間の通信速度を特定する。これにより、１以上のレプリケーション先拠点にそれぞれ対応した１以上の通信速度が特定される。
・拠点決定モジュール１５２０は、特定された１以上の通信速度と、対象ファイルに対応したファイルサイズ１８２０とを基に、ファイル転送時間を決定する。具体的には、例えば、拠点決定モジュール１５２０は、対象ファイルに対応したファイルサイズ１８２０を、１以上の通信速度のうち最も早い通信速度で除算することで、最短の転送時間を、ファイル転送時間として決定する。

このようにして、全ファイルについて、ファイル転送時間が算出される。拠点決定モジュール１５２０は、全ファイルのファイル転送時間の合計である全ファイル転送時間を算出する（Ｓ２０３０）。

このようにして、全ての拠点について、全ファイル転送時間が算出される。

次に、拠点決定モジュール１５２０は、全ての全ファイル転送時間のうちのいずれかの全ファイル転送時間の一例として最小の全ファイル転送時間を特定し、特定した全ファイル転送時間に対応した拠点を求める（Ｓ２０４０）。

最後に、拠点決定モジュール１５２０は、Ｓ２０４０で求めた拠点の拠点ＩＤを出力する（Ｓ２０５０）。

以下、リストア先拠点決定処理の処理手順を、図６、 図１６、図１７、図１８の具体例を利用して説明する。なお、本具体例では、サーバ１００２（サーバＩＤが“１００２”であるサーバ）が障害サーバであるものとする。

まず、拠点決定モジュール１５２０は、全ての拠点の各々について、全ファイル転送時間（リストア先サーバを当該拠点に作成した場合の、障害サーバが保持していた全ファイルの取得に要する時間）を求める。本具体例では、拠点６００１〜６００８が存在するため、まずは、拠点６００１にリストア先サーバを設置した場合の全ファイル転送時間を求める。拠点決定モジュール１５２０は、ファイル情報１８００の各エントリを走査し、マスタサーバＩＤが“１００２”であるか否かを判断する（Ｓ２０１０）。具体例では、ファイル名“d.tar”に対応したマスタサーバＩＤが“１００２”である。ファイル“d.tar”（ファイル名“d.tar”のファイル）は、サーバ１００５と１００６にレプリケーションされている。また、サーバ情報１６００によれば、サーバ１００５とサーバ１００６は、それぞれ、拠点６００５と６００６に属する。拠点６００１と拠点６００５との通信速度は２MB/sであり、拠点６００１と拠点６００６との通信速度は１MB/sである。そのため、ファイル“d.tar”をより高速に取得するため、拠点決定モジュール１５２０は、拠点６００５のサーバ１００５からファイル“d.tar”の取得を行うこととし、ファイル“d.tar”のファイルサイズ“２０MB”を通信速度“２MB/s”で除し、ファイル転送時間“１０秒”を算出する（Ｓ２０２０）。

拠点決定モジュール１５２０は、同様の処理を全てのファイルに対しても実施し、拠点６００１にリストア先サーバを設置した際の全ファイル転送時間を算出する（Ｓ２０３０）。

拠点決定モジュール１５２０は、同様の処理を、他の拠点６００２〜６００８に対しても実施する。その後、拠点決定モジュール１５２０は、拠点６００１〜６００８から、最小の全ファイル転送時間の拠点をリストア先拠点として特定し、特定した拠点の拠点ＩＤを出力する（Ｓ２０４０）。

以上、本実施例によれば、ファイル情報１８００と、サーバ情報１６００と、拠点間通信速度情報６００と、に基づいて、リストア先拠点として、全ファイル転送時間が最短となる拠点が決定される。このため、複数のサーバにデータが分散保存され、レプリケーション時のサーバ１２２０の選択方法等に起因して、サーバ間でデータ配置の偏りが生じるような分散ファイルシステムにおいて、データの高可用化のためのリカバリに要する時間を短縮できる。リカバリに要する時間が短縮されることにより、分散ファイルシステムの読み書き処理性能が低下する時間を短縮できる。

以下、上述の説明を総括する。その総括において、上述の説明に無い事項が含まれていてもよい。なお、以下の総括において、データセットの一例が、上述のブロックチェーンデータおよびファイルである。また、ノードの一例が、サーバである。また、分散コンピューティングシステムの一例が、ブロックチェーンシステムおよび分散ファイルシステムである。また、管理プログラムの一例が、ブロックチェーン管理プログラム３００および管理プログラム１５００である。

管理プログラムが、分散コンピューティングシステムのうちの少なくとも１つのノード又は別の計算機で実行される。管理プログラムが、
（Ａ）複数のノードのうちのリカバリ対象のノード（例えば障害ノード）が保持している１以上のデータセットと同じ１以上のデータセットを保持している１以上のノードが存在する１以上の拠点を特定し、
（Ｂ）同じ１以上のデータセットのリストア先となるノードの拠点であるリストア先拠点を、複数の拠点から、特定した１以上の拠点を基に決定する。

リストア先拠点が、上記同じ１以上のデータセットが存在する１以上の拠点を基に決定されるので、その同じ１以上のデータセットのリストア（転送）にかかる時間を短縮することが期待できる。

上記のリストア先拠点は、複数の拠点の各々と１以上のリストア元拠点の各々との間の通信速度を基に決定されてよい。１以上のリストア元拠点の各々は、上記同じ１以上のデータセットの各々について、下記（ｘ）または（ｙ）でよい。
（ｘ）当該データセットを保持しているノードが存在する拠点、
（ｙ）当該データセットを保持している１以上のノードが存在する１以上の拠点である１以上の候補拠点のうちのいずれか。

通信速度を基にリストア先拠点が決定されるので、リストア（転送）にかかる時間を短縮することの確実性が高まることが期待できる。なお、拠点間の通信速度は、一般に、単位時間当たりの転送可能なデータ量で表現されるが、それに代えて、拠点間の距離で表現されてもよい。この場合、距離が長いほど、通信速度は低いと解釈可能である。

リストア先拠点は、複数の拠点のうち、特定した１以上の拠点にそれぞれ対応した１以上の通信速度の合計が最大の拠点でよい。これにより、リストアにかかる時間の一層の短縮が期待できる。なお、拠点間の通信速度が拠点間の距離で表現されている場合、「１以上の通信速度の合計が最大の拠点」とは、「１以上の距離の合計が最小の拠点」であってよい。

上記（ｙ）は、１以上の候補拠点のうち、通信速度が最大である拠点でよい。これにより、リストアにかかる時間の一層の短縮が期待できる。

リストア先拠点は、複数の拠点の各々と１以上のリストア元拠点の各々との間の通信速度の他に、１以上のデータセットの各々のデータサイズに基づいて決定されてよい。通信速度が早くても転送対象のデータセットのデータサイズが大きければ、転送完了に時間がかかる。データサイズを更に考慮することで、リストアにかかる時間を短縮することの確実性が高まることが期待できる。

リストア先拠点は、複数の拠点の各々の全データ転送時間に基づいてよい。複数の拠点の各々について、全データ転送時間は、上記同じ１以上のデータセットにそれぞれ対応した１以上の転送時間の合計でよい。複数の拠点のうちの各々について、１以上のデータセットの各々に関し、転送時間は、当該拠点と当該データセットを保持しているリストア元拠点との通信速度と、当該データセットのデータサイズとに基づいてよい。全データ転送時間に基づいてリストア先拠点が決定されるので、リストアにかかる時間を短縮することの確実性が高まることが期待できる。

リストア先拠点は、複数の拠点のうち全データ転送時間が最短の拠点でよい。これにより、リストアにかかる時間の一層の短縮が期待できる。

（ｙ）は、１以上の候補拠点のうち、転送時間が最短である拠点でよい。これにより、リストアにかかる時間の一層の短縮が期待できる。

複数の拠点は、特定された１以上の拠点でよい。これにより、通信速度を基にリストア先拠点を探す範囲（拠点の数）が絞り込まれるので、高速にリストア先拠点を決定することが期待できる。

リストア先拠点は、特定された１以上の拠点のうちのいずれかでよい。これにより、通信速度やデータサイズを考慮すること無しに（上記同じ１以上のデータセットの配置に基づいて）、リストア先拠点を決定することができ、故に、高速にリストア先拠点を決定することが期待できる。

１以上のデータセットの各々に関し、当該データセットと同じデータセットを保持している１以上のサーバの各々は、リカバリ対象のサーバと共に当該データセットのデータ共有範囲に属するサーバでよい。すなわち、データセット毎に、分散範囲の制御が可能である。

上記特定された１以上の拠点は、リカバリ対象のサーバにとって１以上のデータセットのレプリケーション先の１以上のサーバが存在する拠点でよい。すなわち、データセット毎に、分散範囲（具体的には、例えば、マスタサーバとレプリケーション先サーバ）の制御が可能である。

以上、幾つかの実施例を説明したが、これらは本発明の説明のための例示であって、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。

例えば、地理的に離れた複数の拠点の各々において、計算機システムが存在してよい。「計算機システム」は、１以上の物理的な計算機を含む。少なくとも１つの物理的な計算機が、仮想的な計算機（例えばＶＭ（Virtual Machine））を実行してもよいし、ＳＤｘ（Software-Defined anything）を実行してもよい。ＳＤｘとしては、例えば、ＳＤＳ（Software Defined Storage）（仮想的なストレージ装置の一例）又はＳＤＤＣ（Software-defined Datacenter）を採用することができる。計算機は、ストレージ装置でもよい。計算機システムは、クラウドコンピューティングシステムでもよい。

１２０：サーバ

Claims (14)

1. 複数の拠点に存在する複数のノードを有する分散コンピューティングシステムのうちの少なくとも１つのノード又は別の計算機に、
   （Ａ）前記複数のノードのうちのリカバリ対象のノードが保持している１以上のデータセットと同じ１以上のデータセットを保持している１以上のノードが存在する１以上の拠点を特定し、
   （Ｂ）前記同じ１以上のデータセットのリストア先となるノードの拠点であるリストア先拠点を、前記複数の拠点から、前記特定した１以上の拠点を基に決定し、
   前記リカバリ対象拠点は、前記リストア対象ノードが存在する拠点である、
   ことを実行させるコンピュータプログラム。
2. 前記リストア先拠点は、前記複数の拠点の各々と１以上のリストア元拠点の各々との間の通信速度を基に決定され、
   前記１以上のリストア元拠点の各々は、前記同じ１以上のデータセットの各々について、下記（ｘ）または（ｙ）である、
   （ｘ）当該データセットを保持しているノードが存在する拠点、
   （ｙ）当該データセットを保持している１以上のノードが存在する１以上の拠点である１以上の候補拠点のうちのいずれか、
   請求項１記載のコンピュータプログラム。
3. 前記リストア先拠点は、前記複数の拠点のうち、前記特定した１以上の拠点にそれぞれ対応した１以上の通信速度の合計が最大の拠点である、
   請求項２記載のコンピュータプログラム。
4. （ｙ）は、前記１以上の候補拠点のうち、通信速度が最大である拠点である、
   請求項２記載のコンピュータプログラム。
5. 前記リストア先拠点は、更に、前記１以上のデータセットの各々のデータサイズに基づいて決定される、
   請求項２記載のコンピュータプログラム。
6. 前記リストア先拠点は、前記複数の拠点の各々の全データ転送時間に基づいており、
   前記複数の拠点の各々について、全データ転送時間は、前記同じ１以上のデータセットにそれぞれ対応した１以上の転送時間の合計であり、
   前記複数の拠点の各々について、前記１以上のデータセットの各々に関し、転送時間は、
   当該拠点と、当該データセットを保持しているリストア元拠点との通信速度と、
   当該データセットのデータサイズと
   に基づいている、
   請求項５記載のコンピュータプログラム。
7. 前記リストア先拠点は、前記複数の拠点のうち全データ転送時間が最短の拠点である、
   請求項６記載のコンピュータプログラム。
8. （ｙ）は、前記１以上の候補拠点のうち、転送時間が最短である拠点である、
   請求項６記載のコンピュータプログラム。
9. 前記複数の拠点は、前記特定された１以上の拠点である、
   請求項２記載のコンピュータプログラム。
10. 前記リストア先拠点は、前記特定された１以上の拠点のうちのいずれかである、
    請求項１記載のコンピュータプログラム。
11. 前記１以上のデータセットの各々に関し、当該データセットと同じデータセットを保持している１以上のサーバの各々は、前記リカバリ対象のサーバと共に当該データセットのデータ共有範囲に属するサーバである、
    請求項１記載のコンピュータプログラム。
12. 前記特定された１以上の拠点は、前記リカバリ対象のサーバにとって前記１以上のデータセットのレプリケーション先の１以上のサーバが存在する拠点である、
    請求項１記載のコンピュータプログラム。
13. 複数の拠点に存在する複数のノードを有する分散コンピューティングシステムのうちの少なくとも１つのノード又は別の計算機であって、
    １以上のノードと通信のための１以上のインタフェースデバイスを含んだインタフェース部と、
    前記インタフェース部に接続された１以上のプロセッサを含んだプロセッサ部と
    を有し、
    前記プロセッサ部が、
    （Ａ）前記複数のノードのうちのリカバリ対象のノードが保持している１以上のデータセットと同じ１以上のデータセットを保持している１以上のノードが存在する１以上の拠点を特定し、
    （Ｂ）前記同じ１以上のデータセットのリストア先となるノードの拠点であるリストア先拠点を、前記複数の拠点から、前記特定した１以上の拠点を基に決定する、
    計算機。
14. 複数の拠点に存在する複数のノードを有する分散コンピューティングシステムのうちのリカバリ対象のノードをリカバリする方法であって、
    （Ａ）前記複数のノードのうちのリカバリ対象のノードが保持している１以上のデータセットと同じ１以上のデータセットを保持している１以上のノードが存在する１以上の拠点を特定し、
    （Ｂ）前記同じ１以上のデータセットのリストア先となるノードの拠点であるリストア先拠点を、前記複数の拠点から、前記特定した１以上の拠点を基にする、
    方法。