JP5879982B2 - ストレージ装置、ストレージ制御プログラムおよびストレージ制御方法 - Google Patents

ストレージ装置、ストレージ制御プログラムおよびストレージ制御方法 Download PDF

Info

Publication number
JP5879982B2
JP5879982B2 JP2011263010A JP2011263010A JP5879982B2 JP 5879982 B2 JP5879982 B2 JP 5879982B2 JP 2011263010 A JP2011263010 A JP 2011263010A JP 2011263010 A JP2011263010 A JP 2011263010A JP 5879982 B2 JP5879982 B2 JP 5879982B2
Authority
JP
Japan
Prior art keywords
update
request
unit
priority
node
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2011263010A
Other languages
English (en)
Other versions
JP2013114623A (ja
Inventor
宗則 前田
宗則 前田
純 加藤
純 加藤
達夫 熊野
達夫 熊野
雅寿 田村
雅寿 田村
健 飯澤
健 飯澤
泰生 野口
泰生 野口
年弘 小沢
年弘 小沢
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2011263010A priority Critical patent/JP5879982B2/ja
Priority to US13/615,836 priority patent/US9208114B2/en
Publication of JP2013114623A publication Critical patent/JP2013114623A/ja
Application granted granted Critical
Publication of JP5879982B2 publication Critical patent/JP5879982B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14Handling requests for interconnection or transfer
    • G06F13/20Handling requests for interconnection or transfer for access to input/output bus
    • G06F13/28Handling requests for interconnection or transfer for access to input/output bus using burst mode transfer, e.g. direct memory access DMA, cycle steal

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本発明は、ストレージ装置、ストレージ制御プログラムおよびストレージ制御方法に関する。
従来、分散KVS(Key-Value Store)等のNoSQLを初めとするストレージシステムにおいて、データの複製であるレプリカを複数のノードに配置する技術が知られている。このような技術が適用されたストレージシステムは、レプリカを複数のノードに配置することで、ディスク故障などによるデータの消失を防ぐとともに、各ノードに配置されたレプリカからデータの読出しを許可することで、アクセスの負荷分散を行う。
ここで、ストレージシステムは、各レプリカから読み出されるデータの同一性を保証するStrong Consistencyが要求される場合がある。このようなStrong Consistencyを保つ手法の一例として、チェインレプリケーションの技術が知られている。このようなチェインレプリケーションが適用されたストレージシステムの一例について以下に説明する。
まず、図21を用いて、クライアントがPut要求を発行した際にストレージシステムが実行する処理の一例について説明する。図21は、チェインレプリケーションの一例について説明するための図である。なお、図21に示す例では、チェインレプリケーションの一例としてCRAQ(Chain Replication with Apportioned Query)が適用されたストレージシステムについて説明する。
図21に示す例では、ストレージシステムは、同一のレプリカを有するN個のノードを有する。なお、図21に示す例では、ストレージシステムは、N個のノードのうち、1stノード、2ndノード、3rdノード、Nthノード以外のノードについては、図示を省略している。
このようなストレージシステムが有する各ノードは、クライアントがPut要求を発行した場合には、各ノードを順に並べた経路に沿って、データの書込みを要求するupdate要求を順次転送する。例えば、図21に示す例では、ストレージシステムは、経路の始端となる1stノードをPut要求の発行先として指定する。このような場合には、図21中(A)に示すように、クライアントは、Put要求を経路の始端となる1stノードに発行する。
1stノードは、Put要求を受信した場合には、新たなデータの書込みを準備するとともに、図21中(B)に示すように、2ndノードにupdate要求を送信する。また、2ndノードは、1stノードからupdate要求を受信した場合には、新たなデータの書込みを準備するとともに、update要求を3rdノードに転送する。
その後、各ノードは、update要求を経路の終端となるNthノードまで順に転送する。また、図21中(C)に示すように、経路の終端となるNthノードは、update要求を受信した場合には、新たなデータを書込むとともに、update要求に対する応答であるupdated要求を経路の1つ前のノードに送信する。
その後、各ノードは、updated要求を受信した場合は、準備したデータの書込みを実行するとともに、updated要求を経路に沿って、始端となる1stノードまで順に転送する。そして、1stノードは、図21中(D)に示すように、updated要求を受信した場合には、準備したデータの書込みを実行し、書込み処理が終了した旨をクライアントに通知する。
Object Storage on CRAQ, High-throughput chain replication for read-mostly workloads, Jeff Terrace and Michael J.Freedman Princeton University, USENIX annual Technical Conference.San Diego, CA, June 2009. Chain Replication for Supporting High Throughput and Availability, Robbert van Renesse, Fred B.Schneider, USENIX Association OSDI’04:6th Symposium on Peration Systems Design and Implementation.
しかし、上述したチェインレプリケーションの技術では、Put要求の発行先となるノードが予め決められており、任意のノードにPut要求を発行することができないという問題がある。このため、ノードの設置位置が分散されたストレージシステムにおいては、複数のクライアントにより発行されたPut要求に対する処理が公平に実行されない。
図22は、Put要求に対する処理を実行するタイミングを説明するための図である。図22に示す例では、クライアント8aと1stノードがデータセンター#1に設置され、クライアント8bがデータセンター#2に設置される。また、図22に示す例では、ネットワーク遅延により、クライアント8aが発行したPut要求は、発行されてから2ミリ秒後に1stノードに到着し、クライアント8bが発行したPut要求は、発行されてから25ミリ秒後に1stノードに到着する。
ここで、クライアント8bがPut要求を発行してから10ミリ秒後に、クライアント8aがPut要求を発行したとする。このような場合には、1stノードは、図22中(E)に示すようにクライアント8aが発行したPut要求を先に受信する。その後、図22中(F)に示すように、クライアント8bが発行したPut要求を受信する。このため、1stノードは、クライアント8aが後から発行したPut要求を、クライアント8bが先に発行したPut要求よりも先に実行してしまう。
本願は、1つの側面では、どのノードに発行されたPut要求も適切に実行する。
1つの側面では、データの更新処理の要求と、更新処理の優先度を示す優先度とを受信するストレージ装置である。ストレージ装置は、データを記憶する他のストレージ装置へ、更新処理の要求と優先度とを転送する。また、ストレージ装置は、更新処理の要求を受信した場合は、更新処理の実行を待機し、他のストレージ装置からデータの更新を行った旨の応答をさらに受信した場合は、待機させた更新処理を実行する。また、ストレージ装置は、新たに更新処理の要求と優先度とを受信した際に、他の更新処理の実行を待機している場合には、新たに受信した優先度が、待機中の更新処理の優先度よりも高いか否かを判別する。そして、ストレージ装置は、新たに受信した優先度が待機中の更新処理の優先度よりも高いと判別した場合には、待機中の更新処理の実行をキャンセルする。また、ストレージ装置は、新たに受信した優先度が待機中の更新処理の優先度よりも高いと判別した場合には、データを記憶する他のストレージ装置へ、新たに受信した更新処理の要求と新たに受信した優先度とを転送する。
1つの側面では、どのノードに発行されたPut要求も適切に実行する。
図1は、実施例1に係るストレージシステムを説明するための図である。 図2は、実施例1に係るノードの機能構成を説明するための図である。 図3は、状態管理表の一例を説明するための図である。 図4は、実施例1に係るストレージシステムが実行する処理を説明するための図である。 図5は、実施例1に係るノードがPut要求を受信した際に実行する処理の流れを説明するための第1の図である。 図6は、実施例1に係るノードがPut要求を受信した際に実行する処理の流れを説明するための第2の図である。 図7は、実施例1に係る状態更新処理の流れについて説明するためのフローチャートである。 図8は、実施例1に係る更新失敗通知処理の流れについて説明するためのフローチャートである。 図9は、実施例1に係る更新完了通知処理の流れについて説明するためのフローチャートである。 図10は、更新失敗通知を取得した際に実行する処理の流れを説明するための第1のフローチャートである。 図11は、更新失敗通知を取得した際に実行する処理の流れを説明するための第2のフローチャートである。 図12は、更新完了通知を取得した際に実行する処理の流れを説明するための第1のフローチャートである。 図13は、更新完了通知を取得した際に実行する処理の流れを説明するための第2のフローチャートである。 図14は、更新完了通知を取得した際に実行する処理の流れを説明するための第3のフローチャートである。 図15は、実施例2に係るノードの機能構成を説明するための図である。 図16は、実施例2に係る状態管理表を説明するための図である。 図17は、実施例2に係る更新失敗通知部が更新失敗通知を取得した際に実行する処理の流れを説明するためのフローチャートである。 図18は、実施例2に係る更新完了通知部が更新完了通知を取得した際に実行する処理の流れを説明するための第1のフローチャートである。 図19は、実施例2に係る更新完了通知部が更新完了通知を取得した際に実行する処理の流れを説明するための第2のフローチャートである。 図20は、ストレージ制御プログラムを実行するコンピュータの一例を説明するための図である。 図21は、チェインレプリケーションの一例について説明するための図である。 図22は、Put要求に対する処理を実行するタイミングを説明するための図である。
以下に添付図面を参照して本願に係るストレージ装置、ストレージ制御プログラムおよびストレージ制御方法について説明する。
以下の実施例1では、図1を用いて、ストレージシステムの一例を説明する。図1は、実施例1に係るストレージシステムを説明するための図である。なお、以下の説明において、ノードとは、例えば、データの複製であるレプリカを記憶する記憶装置と、他のノードとの通信処理、データの更新処理、データの管理処理等を実行する演算処理装置とを有するストレージ装置やサーバ等が適用されるものとする。
図1に示す例では、ストレージシステム1は、複数のクライアント2、3を有する。また、ストレージシステム1は、複数のノード4〜7を有する。各ノード4〜7は、それぞれ、同一のデータの複製である1stレプリカから4thレプリカを記憶する。図1に示す例では、ノード4は、1stレプリカを記憶する。また、ノード5は、2ndレプリカを記憶する。また、ノード6は、3rdレプリカを記憶する。また、ノード7は、4thレプリカを記憶する。
図1に示す例では、クライアント2、3は、任意のノード4〜7に対して、データの書込み等の更新処理を要求するPut要求を発行する。また、クライアント2、3は、Put要求が示す更新処理の優先度をしめすマーク強度を格納したPut要求を発行する。また、クライアント2、3は、データの読出し要求であるGet要求を各ノード4〜7に発行する。
例えば、クライアント2、3は、マーク強度、更新操作タグ、データが格納された要求を発行する。ここで、マーク強度とは、要求が示す処理の実行強度、すなわち、要求が示す処理の優先度を示す情報であり、例えば、クライアント2、3が要求を発行した時刻である。また、更新操作タグとは、要求が示す処理内容を示し、例えば、データの書込み処理を示す「Put」や、データの読出しを示す「Get」が格納される。
すなわち、更新操作タグに「Put」が格納された要求がPut要求であり、更新操作タグに「Get」が格納された要求がGet要求である。なお、データは、Put要求のみに格納され、書込み対象となるデータである。なお、クライアント2、3がGet要求を発行した際に各ノード4〜7が実行する処理については、従来のストレージシステムが実行する処理と同様の処理を実行するものとして、以下の説明を省略する。
次に、図2を用いて、ノード4について説明する。図2は、実施例1に係るノードの機能構成を説明するための図である。なお、以下の説明においては、ノード5〜7は、ノード4と同様の処理を実行するものとして、説明を省略する。
図2に示す例では、ノード4は、ネットワークインターフェース10、要求受信部11、要求処理部12、データ更新部17、データ記憶部18、要求発行部19を有する。また、ノード4は、クライアント位置記憶部20、トポロジー計算部21、ノード間要求並列送信部22、クライアント位置判断部23、クライアント要求送信部24を有する。
また、要求処理部12は、Put要求処理部13、状態更新部14、更新失敗通知部15、更新完了通知部16を有する。また、データ記憶部18は、1stレプリカを記憶するとともに、状態管理表18aと、ルーティング情報18bとノード情報18cを記憶する。
状態管理表18aは、ノード4が準備中の更新処理の内容を示す表である。ここで、図3は、状態管理表の一例を説明するための図である。図3に示す例では、状態管理表18aは、準備中の更新処理を示す更新ステータスと、実行をキャンセルした更新処理を示すキャンセル表とを有する。ここで更新ステータスには、マーク強度「x」、親レプリカ「y」、子レプリカ数が格納される。
ここで「x」は、Put要求をクライアントが発行した時刻である。また、「y」とは、Put要求の送信元となるクライアント、又は、Put要求の転送元であるレプリカを示す情報である。
子レプリカ数とは、ノード4がPut要求を転送するノードの数を示す情報である。例えば、ノード4がPut要求をノード5に転送する場合には、子レプリカ数として「1」が格納され、ノード4がPut要求をノード5およびノード6に転送する場合には、子レプリカ数として「2」が格納される。なお、キャンセル表には、実行をキャンセルした更新処理のマーク強度、親レプリカ、子レプリカ数が格納される。
図2に戻って、ルーティング情報18bとは、ノード4がクライアント2、3からPut要求を受信した場合に、受信したPut要求を転送する経路を示す。例えば、ノード4は、ルーティング情報として、G1=({レプリカ1,レプリカ2,レプリカ3,レプリカ4},{(レプリカ1,レプリカ2),(レプリカ1,レプリカ3),(レプリカ2,レプリカ4),(レプリカ4,レプリカ3)},レプリカ1,レプリカ3)を記憶する。
ここで、ルーティング情報におけるレプリカ1とは1stレプリカを示し、レプリカ2とは2ndレプリカを示し、レプリカ3とは3rdレプリカを示し、レプリカ4とは4thレプリカを示す。また、ルーティング情報には、Put要求の転送先となる全てのレプリカ、Put要求の転送元となるレプリカと転送先となるレプリカの組の集合、経路の始端となるレプリカ、経路の終端となるレプリカが順に格納される。
すなわち、上述した例では、ルーティング情報であるG1は、Put要求を転送する対象となるレプリカの集合が1stレプリカから4thレプリカまでの4つのレプリカである旨を示す。また、G1は、1stレプリカを記憶するノードから2ndレプリカを記憶するノードと3rdレプリカを記憶するノードにPut要求を転送する旨の転送経路を示す。また、G1は、2ndレプリカを記憶するノードから4thレプリカを記憶するノードにPut要求を転送し、4thレプリカを記憶するノードから3rdレプリカを記憶するノードにPut要求を転送する旨の転送経路を示す。また、G1は、Put要求を転送する経路の始端が1stレプリカを記憶するノードであり、経路の終端が3rdレプリカを記憶するノードであることを示す。
なお、各ノード4〜7が記憶するルーティング情報は、同一のデータの複製であるレプリカについて、同一のトポロジに対し、それぞれ異なる経路でPut要求等を転送するので、それぞれ異なるルーティング情報を記憶することとなる。例えば、3rdレプリカを記憶するノード6は、ルーティング情報としてG3=({レプリカ1,レプリカ2,レプリカ3,レプリカ4},{(レプリカ3,レプリカ1),(レプリカ3,レプリカ4),(レプリカ1,レプリカ2),(レプリカ4,レプリカ2)},レプリカ3,レプリカ2)を記憶する。
ノード情報18cとは、ノード4が記憶する1stレプリカと同じデータのレプリカをどのノードが記憶しているかを示す。例えば、ノード情報18cは、2ndレプリカをノード5が記憶し、3rdレプリカをノード6が記憶し、4thレプリカをノード7が記憶している旨を示す。
ネットワークインターフェース10は、クライアント2、3及び他のノード5〜7が送信したPut要求、更新処理が成功した旨を示す更新完了通知、更新処理が失敗した旨を示す更新失敗通知を受信する。そして、ネットワークインターフェース10は、受信したPut要求、更新完了通知、更新失敗通知を要求受信部11へ出力する。
また、ネットワークインターフェース10は、ノード間要求並列送信部22から、Put要求、または、更新完了通知、または、更新失敗通知を送信先となるノードの通知とともに取得する。このような場合には、ネットワークインターフェース10は、通知されたノードへPut要求、または、更新完了通知、または、更新失敗通知を送信する。
また、ネットワークインターフェース10は、クライアント要求送信部24から更新完了通知、または、更新失敗通知をクライアントのIPアドレスと、Put要求のトランザクションIDともに取得する。このような場合には、ネットワークインターフェース10は、取得したIPアドレスを宛先として取得した更新完了通知、または、更新失敗通知を送信する。
要求受信部11は、ネットワークインターフェース10からPut要求を取得した場合には、Put要求を解析し、ルーティング情報が格納されているか否かを判別する。そして、要求受信部11は、ルーティング情報が格納されていない場合には、クライアントが発行したPut要求であると判別し、送信元となるクライアントのIPアドレスとトランザクションIDとをクライアント位置記憶部20に格納する。また、要求受信部11は、受信したPut要求を要求処理部12が有するPut要求処理部13に出力する。
一方、要求受信部11は、取得したPut要求にルーティング情報が格納されている場合には、取得したPut要求が他のノード5〜7から転送されてきたものであると判別し、Put要求をPut要求処理部13にそのまま出力する。また、要求受信部11は、ネットワークインターフェース10から更新失敗通知を取得した場合には、取得した更新失敗通知を更新失敗通知部15に出力する。また、要求受信部11は、更新完了通知を取得した場合には、取得した更新完了通知を更新完了通知部16に出力する。
要求処理部12は、Put要求を取得した際に、他のPut要求が示す更新処理を準備中である場合には、新たに取得したPut要求に格納されたマーク強度と、準備中の更新処理に係るPut要求に格納されていたマーク強度とを比較する。すなわち、Put要求処理部13は、新たな更新処理と準備中の更新処理との優先度を比較する。そして、Put要求処理部13は、新たな更新処理の優先度が準備中の更新処理の優先度よりも高い場合は、準備中の更新処理をキャンセルするとともに、新たなPut要求を他のノード5〜7に転送する。
以下、このような要求処理部12が有するPut要求処理部13、状態更新部14、更新失敗通知部15、更新完了通知部16が実行する処理について説明する。例えば、Put要求処理部13は、Put要求を取得した場合には、更新処理の対象となるレプリカをデータ記憶部18から検索する。また、Put要求処理部13は、状態管理表18aの更新ステータスを参照し、更新処理を準備中であるか否かを判別する。
そして、Put要求処理部13は、更新処理を準備中ではないと判別した場合には、Put要求に格納されたルーティング情報が示す経路において、ノード4が終端となるか否かを判別する。一方、Put要求処理部13は、Put要求にルーティング情報が格納されていない場合、つまり、Put要求がクライアント2、3から受信したものである場合は、Put要求の対象となるレプリカのルーティング情報18bをデータ記憶部18から取得する。そして、Put要求処理部13は、ルーティング情報18bが示す経路において、ノード4が終端となるか否かを判別する。
その後、Put要求処理部13は、ノード4が終端となると判別した場合には、Put要求を更新完了通知部16に出力する。また、Put要求処理部13は、ノード4が終端ではないと判別した場合には、Put要求を状態更新部14に出力する。
また、Put要求処理部13は、更新処理を準備中であると判別した場合には、以下の処理を実行する。すなわち、Put要求処理部13は、Put要求に格納されたルーティング情報、または、Put要求の対象となるレプリカのルーティング情報18bをデータ記憶部18から取得し、ノード4が終端となるか否かを判別する。
また、Put要求処理部13は、状態管理表18aの更新ステータスを参照し、更新ステータスが示すマーク強度と新たに取得したPut要求に格納されたマーク強度とを比較する。すなわち、Put要求処理部13は、準備中の更新処理の優先度と、新たに取得したPut要求の優先度とを比較する。
そして、Put要求処理部13は、ノード4が終端ではなく、かつ、新たに取得したPut要求の優先度が準備中の更新処理の優先度よりも高いと判別した場合には、状態更新部14にPut要求を出力する。また、Put要求処理部13は、ノード4が終端であり、かつ、新たに取得したPut要求の優先度が準備中の更新処理の優先度よりも高いと判別した場合には、更新完了通知部16にPut要求を出力する。なお、Put要求処理部13は、新たに取得したPut要求の優先度が準備中の更新処理の優先度よりも高いと判別した場合には、更新失敗通知部15にPut要求を出力する。
例えば、Put要求処理部13は、クライアント2、3がPut要求を発行した時刻がマーク強度である際に、より早い時刻が格納されたPut要求を優先度が高いと判別する。すなわち、Put要求処理部13は、先に発行されたPut要求の優先度が、後に発行されたPut要求の優先度よりも高いと判別する。
なお、Put要求処理部13は、状態更新部14、更新失敗通知部15、更新完了通知部16にPut要求を出力する場合には、以下の処理を実行する。すなわち、Put要求処理部13は、Put要求がクライアント2、3から受信したものである場合には、データ記憶部18から取得したルーティング情報18bをPut要求に格納し、ルーティング情報18bを格納したPut要求を出力する。つまり、Put要求処理部13は、他のノード5〜7が格納したルーティング情報、または、データ記憶部8に記憶されたルーティング情報18bが格納されたPut要求を出力する。
また、Put要求処理部13は、更新失敗通知を取得した場合には、更新失敗通知を更新失敗通知部15に出力する。また、Put要求処理部13は、更新完了通知を取得した場合には、更新完了通知を更新完了通知部16に出力する。
状態更新部14は、Put要求処理部13から、Put要求を取得した場合は、以下の処理を実行する。すなわち、状態更新部14は、取得したPut要求が示す更新処理に合わせて、状態管理表18aを更新する。具体的には、状態更新部14は、状態管理表18aに更新ステータスが格納されているか否かを判別する。そして、状態更新部14は、状態管理表18aに更新ステータスが格納されている場合には、更新ステータスの内容をキャンセル表に移動する。
また、状態更新部14は、取得したPut要求からマーク強度とルーティング情報とを取得する。また、状態更新部14は、取得したルーティング情報を用いて、ノード4にPut要求を送信したノード、すなわち、親レプリカを記憶するノードを識別する。なお、状態更新部14は、取得したルーティング情報に、ノード4が記憶するレプリカが始端として記憶されている場合には、Put要求を発行したクライアントを識別する。また、状態更新部14は、取得したルーティング情報を用いて、Put要求を転送するノードの数、すなわち、子レプリカ数を識別する。
そして、状態更新部14は、取得したマーク強度、識別した親レプリカまたはクライアント、識別した子レプリカ数を新たな更新ステータスとして状態管理表18aに格納する。また、状態更新部14は、要求発行部19に対して、Put要求を出力する。
更新失敗通知部15は、Put要求処理部13からPut要求を取得した場合には、以下の処理を実行する。まず、Put要求処理部13は、取得したPut要求に格納されたルーティング情報を用いて、取得したPut要求の送信元が、親レプリカを記憶するノードであるか、クライアントであるか否かを判別する。
そして、更新失敗通知部15は、取得したPut要求の送信元が親レプリカを記憶するノードである場合には、Put要求の送信元となるノードを識別し、識別したノードに更新失敗通知を送信するよう要求発行部19に依頼する。この際、更新失敗通知部15は、Put要求に格納されていたルーティング情報を要求発行部19に出力する。
一方、更新失敗通知部15は、Put要求の送信元がクライアントである場合には、Put要求の送信元であるクライアントを識別し、識別したクライアントに更新失敗通知を送信するよう要求発行部19に依頼する。
また、更新失敗通知部15は、更新失敗通知を取得した場合には、以下の処理を実行する。まず、後述するように、更新失敗通知には、失敗した更新処理のマーク強度と、失敗した更新処理を要求するPut要求に格納されていたルーティング情報とが格納されている。そして、更新失敗通知部15は、更新失敗通知から、失敗した更新処理のマーク強度を取得し、取得したマーク強度と、更新ステータスのマーク強度とを比較する。
その後、更新失敗通知部15は、更新失敗通知から取得したマーク強度と更新ステータスのマーク強度とが一致した場合には、以下の処理を実行する。まず、更新失敗通知部15は、更新ステータスに更新失敗フラグを設定するとともに、更新ステータスの子レプリカ数を1デクリメントする。ここで更新失敗フラグとは、更新ステータスが示す更新処理が失敗した旨を示す任意の情報である。
次に、更新失敗通知部15は、更新ステータスの子レプリカ数が0であるか否かを判別し、子レプリカ数が0である場合には、更新失敗通知の転送先となるクライアント、または、ノードを識別する。そして、更新失敗通知部15は、識別したクライアント、または、ノードに対して更新失敗通知を転送するよう要求発行部19に依頼する。
一方、更新失敗通知部15は、更新失敗通知から取得したマーク強度と更新ステータスのマーク強度とが一致しなかった場合は、キャンセル表の各エントリを参照し、更新失敗通知から取得したマーク強度と同じマーク強度のエントリを取得する。そして、更新失敗通知部15は、取得したエントリの子レプリカ数を1デクリメントする。
次に、更新失敗通知部15は、取得したエントリの子レプリカ数が0となった場合には、エントリを削除する。その後、更新失敗通知部15は、更新失敗通知の転送先となるクライアント、または、ノードを識別し、識別したクライアント、または、ノードに対して更新失敗通知を転送するよう要求発行部19に依頼する。なお、更新失敗通知部15は、更新失敗通知を転送するよう要求発行部19に依頼する場合には、転送する更新失敗通知を要求発行部19に出力する。
更新完了通知部16は、Put要求処理部13からPut要求を取得した場合には、以下の処理を実行する。すなわち、更新完了通知部16は、取得したPut要求が示す更新処理を実行するようデータ更新部17に依頼する。そして、更新完了通知部16は、取得したPut要求のルーティング情報を用いて、取得したPut要求の送信元が、親レプリカを記憶するノードであるか、クライアントであるか否かを判別する。
そして、更新完了通知部16は、取得したPut要求の送信元が親レプリカを記憶するノードである場合には、Put要求の送信元となるノードを識別し、識別したノードに更新完了通知を送信するよう要求発行部19に依頼する。この際、更新完了通知部16は、Put要求に格納されていたルーティング情報を要求発行部19に出力する。
一方、更新完了通知部16は、取得したPut要求の送信元がクライアントである場合には、Put要求の送信元であるクライアントを識別し、識別したクライアントに更新完了通知を送信するよう要求発行部19に依頼する。
また、更新完了通知部16は、Put要求処理部13から更新完了通知を取得した場合には、以下の処理を実行する。まず、後述するように、更新完了通知には、更新失敗通知と同様に、実行が完了した更新処理のマーク強度と、実行が完了した更新処理を要求するPut要求に格納されていたルーティング情報とが格納されている。そして、更新完了通知部16は、更新完了通知から、マーク強度とルーティング情報とを取得し、取得したマーク強度と、更新ステータスのマーク強度とを比較する。
そして、更新完了通知部16は、取得したマーク強度と更新ステータスのマーク強度とが一致する場合には、更新ステータスに更新失敗フラグが設定されているか否かを判別する。また、更新完了通知部16は、更新失敗フラグが設定されている場合には、更新ステータスの子レプリカ数を1デクリメントする。そして、更新完了通知部16は、更新ステータスの子レプリカ数が0になった場合には、更新失敗通知を転送するクライアント、または親レプリカを記憶するノードを識別する。その後、更新完了通知部16は、識別したクライアントまたはノードに更新失敗通知を送信するよう要求発行部19に依頼する。
また、更新完了通知部16は、更新ステータスに更新失敗フラグが設定されていない場合には、更新ステータスの子レプリカ数を1デクリメントする。そして、更新完了通知部16は、更新ステータスの子レプリカ数が0になった場合には、データ更新部17にレプリカの更新を依頼する。
また、更新完了通知部16は、更新ステータスをクリアするとともに、更新完了通知の転送先となるクライアント、または、親レプリカを記憶するノードを識別する。その後、更新完了通知部16は、識別したクライアントまたはノードに更新完了通知を転送するよう要求発行部19に依頼する。この際、更新完了通知部16は、他のノードから受信した更新完了通知を要求発行部19に出力する。
一方、更新完了通知部16は、更新完了通知から取得したマーク強度と更新ステータスのマーク強度とが一致しなかった場合は、キャンセル表の各エントリを参照し、更新完了通知から取得したマーク強度と同じマーク強度のエントリを取得する。そして、更新完了通知部16は、取得したエントリの子レプリカ数を1デクリメントする。次に、更新完了通知部16は、取得したエントリの子レプリカ数が0となった場合には、エントリを削除する。
その後、更新完了通知部16は、更新失敗通知の転送先となるクライアント、または、ノードを識別し、識別したクライアント、または、ノードに対して更新失敗通知を送信するよう要求発行部19に依頼する。なお、更新完了通知部16は、更新失敗通知を送信するよう要求発行部19に依頼する場合には、他のノードから受信した更新完了通知に格納されているルーティング情報を要求発行部19に出力する。
このように、更新完了通知部16は、更新ステータスに更新失敗フラグが設定されている場合には、Put要求を転送したノードのいずれかに、転送したPut要求よりも高い優先度のPut要求が送信されており、更新失敗通知を受信済みであると判別する。このため、更新完了通知部16は、Put要求を転送した全てのノードから更新完了通知を取得した場合には、レプリカの更新を依頼するとともに、クライアントまたは親レプリカを記憶するノードに更新完了通知を送信する。
また、更新完了通知部16は、Put要求を転送したいずれかのノードから更新失敗通知を取得し、かつ、Put要求を転送した全てのノードから更新完了通知または更新失敗通知を取得した場合には、以下の処理を実行する。すなわち、更新完了通知部16は、レプリカの更新を依頼せずに、クライアントまたは親レプリカを記憶するノードに更新失敗通知を送信する。また、更新完了通知部16は、準備中の更新処理をキャンセルした後に、Put要求を転送したノードから更新完了通知または更新失敗通知を取得した場合には、クライアント、または、親レプリカを記憶するノードに更新失敗通知を送信する。
データ更新部17は、データ記憶部18が記憶するレプリカのデータを更新する。具体的には、データ更新部17は、更新完了通知部16からレプリカの更新を依頼された場合には、更新ステータスが示す更新処理を実行する。
要求発行部19は、状態更新部14からPut要求を取得した場合には、Put要求に格納されたルーティング情報に従って、Put要求を他のノード5〜7に転送する。具体的には、要求発行部19は、状態更新部14から取得したPut要求をトポロジー計算部21に出力する。
また、要求発行部19は、クライアントに更新失敗通知を送信するよう更新失敗通知部15から依頼された場合には、更新失敗通知を生成する。そして、要求発行部19は、生成した更新失敗通知をクライアント位置判断部23に出力するとともに、更新失敗通知部15が識別したクライアントを通知する。
一方、要求発行部19は、ノードに更新失敗通知を送信するよう更新失敗通知部15から依頼された場合には、更新失敗通知を生成するとともに、更新失敗通知部15から取得したルーティング情報を更新失敗通知に格納する。その後、要求発行部19は、生成した更新失敗通知をトポロジー計算部21に出力する。
なお、要求発行部19は、更新完了通知部16から更新失敗通知を送信するよう依頼された場合には、更新失敗通知部15から更新失敗通知を送信するよう依頼された場合と同様の処理を実行する。すなわち、要求発行部19は、更新失敗通知を生成し、生成した更新失敗通知をトポロジー計算部21、もしくは、クライアント位置判断部23に出力する。
また、要求発行部19は、更新失敗通知部15から更新失敗通知を取得するとともに、更新失敗通知部15が識別したクライアントに更新失敗通知を転送するよう依頼された場合には、以下の処理を実行する。すなわち、要求発行部19は、取得した更新失敗通知をクライアント位置判断部23に出力するとともに、更新失敗通知部15が識別したクライアントを通知する。
また、要求発行部19は、更新失敗通知部15から更新失敗通知を取得するとともに、更新失敗通知部15が識別したノードに更新失敗通知を転送するよう依頼された場合には、以下の処理を実行する。すなわち、要求発行部19は、取得した更新失敗通知をトポロジー計算部21に出力する。
また、要求発行部19は、クライアントに更新完了通知を送信するよう更新完了通知部16から依頼された場合には、更新完了通知を生成する。そして、要求発行部19は、生成した更新完了通知をクライアント位置判断部23に出力するとともに、更新完了通知部16が識別したクライアントを通知する。
また、要求発行部19は、ノードに更新完了通知を送信するよう更新完了通知部16から依頼された場合には、更新完了通知を生成するとともに、更新完了通知部16から取得したルーティング情報を更新完了通知に格納する。その後、要求発行部19は、生成した更新完了通知をトポロジー計算部21に出力する。
また、要求発行部19は、更新完了通知部16から更新完了通知を取得するとともに、更新完了通知部16が識別したクライアントに更新完了通知を転送するよう依頼された場合には、以下の処理を実行する。すなわち、要求発行部19は、取得した更新完了通知をクライアント位置判断部23に出力するとともに、更新完了通知部16が識別したクライアントを通知する。
また、要求発行部19は、更新完了通知部16から更新完了通知を取得するとともに、更新完了通知部16が識別したノードに更新完了通知を転送するよう依頼された場合には、以下の処理を実行する。すなわち、要求発行部19は、取得した更新完了通知をトポロジー計算部21に出力する。
クライアント位置記憶部20は、ノード4に対してPut要求を発行したクライアントのIPアドレスとPut要求のトランザクションIDとを記憶する。具体的には、クライアント位置記憶部20は、クライアント2がノード4にPut要求を発行した場合には、クライアント2のIPアドレスを要求受信部11から取得し、取得したIPアドレスを記憶する。
トポロジー計算部21は、要求発行部19からPut要求を取得した場合には、取得したPut要求に格納されたルーティング情報を用いて、ノード4がPut要求を送信するノードを識別する。そして、トポロジー計算部21は、取得したPut要求をノード間要求並列送信部22に出力するとともに、Put要求を識別したノードに送信するよう依頼する。
また、トポロジー計算部21は、要求発行部19から更新失敗通知を取得した場合には、取得した更新失敗通知に格納されたルーティング情報を用いて、ノード4が更新失敗通知を送信するノードを識別する。具体的には、トポロジー計算部21は、更新失敗通知に格納されたルーティング情報が示す経路を逆に辿り、ノード4に対してPur要求を送信したノードを識別する。そして、トポロジー計算部21は、取得した更新失敗通知をノード間要求並列送信部22に出力するとともに、更新失敗通知を識別したノードに送信するよう依頼する。
また、トポロジー計算部21は、要求発行部19から更新完了通知を取得した場合には、更新失敗通知を取得した際と同様の処理を実行し、更新完了通知を送信するノードを識別する。そして、トポロジー計算部21は、取得した更新完了通知をノード間要求並列送信部22に出力するとともに、更新完了通知を識別したノードに送信するよう依頼する。
例えば、トポロジー計算部21は、Put要求に上述したルーティング情報G1が格納されている場合には、Put要求を送信するノードとして、2ndレプリカを記憶するノード5、および、3rdレプリカを記憶するノード6を識別する。このような場合には、トポロジー計算部21は、Put要求をノード5およびノード6に送信するようノード間要求並列送信部22に依頼する。
また、例えば、トポロジー計算部21は、Put要求に上述したルーティング情報G3が格納されている場合には、Put要求を送信するノードとして、2ndレプリカを記憶するノード5を識別する。このような場合には、トポロジー計算部21は、Put要求をノード5に送信するようノード間要求並列送信部22に依頼する。
また、例えば、トポロジー計算部21は、更新失敗通知に上述したルーティング情報G3が格納されている場合には、ルーティング情報G3の、Put要求の転送元となるレプリカと転送先となるレプリカの組の集合を解析する。そして、トポロジー計算部21は、3rdレプリカを記憶するノード6が1stレプリカを記憶するノード4にPut要求を送信すると判別する。このため、トポロジー計算部21は、更新失敗通知の送信先がノード6であると判別し、更新失敗通知をノード6に送信するようノード間要求並列送信部22に依頼する。
同様に、トポロジー計算部21は、更新完了通知に上述したルーティング情報G3が格納されている場合には、更新完了通知の送信先として、3rdレプリカを記憶するノード6を識別する。このような場合には、トポロジー計算部21は、更新完了通知をノード6に送信するようノード間要求並列送信部22に依頼する。
ノード間要求並列送信部22は、トポロジー計算部21から送信を依頼されたPut要求、更新失敗通知、または、更新完了通知を、トポロジー計算部21が識別したノードに対して送信する。例えば、ノード間要求並列送信部22は、Put要求をノード5に送信するよう依頼された場合には、Put要求を格納したパケットにノード5のIPアドレスを宛先として格納し、ネットワークインターフェース10に出力する。
クライアント位置判断部23は、要求発行部19から更新失敗通知を取得するとともに、クライアントの通知を取得した場合には、以下の処理を実行する。すなわち、クライアント位置判断部23は、クライアント位置記憶部20を参照し、通知されたクライアントのIPアドレスとPut要求のトランザクションIDとを取得する。そして、クライアント位置判断部23は、取得した更新失敗通知と取得したIPアドレスとトランザクションIDとをクライアント要求送信部24に出力する。
同様に、クライアント位置判断部23は、要求発行部19から更新完了通知を取得するとともに、クライアントの通知を取得した場合には、通知されたクライアントのIPアドレスをクライアント位置記憶部20から取得する。そして、クライアント位置判断部23は、取得した更新完了通知と取得したIPアドレスとをクライアント要求送信部24に出力する。
クライアント要求送信部24は、クライアント位置判断部23から取得したクライアントのIPアドレスを宛先として、更新失敗通知や更新完了通知をネットワークインターフェース10を介して送信する。例えば、クライアント要求送信部24は、更新失敗通知、または、更新完了通知を格納したパケットに通知されたIPアドレスを宛先として格納し、ネットワークインターフェース10に出力する。
例えば、ネットワークインターフェース10、要求処理部12、Put要求処理部13、状態更新部14、更新失敗通知部15、更新完了通知部16、データ更新部17とは、電子回路である。また、要求発行部19、トポロジー計算部21、ノード間要求並列送信部22、クライアント位置判断部23、クライアント要求送信部24とは、電子回路である。ここで、電子回路の例として、ASIC(Application Specific Integrated Circuit)やFPGA(Field Programmable Gate Array)などの集積回路、またはCPU(Central Processing Unit)やMPU(Micro Processing Unit)などを適用する。
また、データ記憶部18、クライアント位置記憶部20とは、RAM(Random Access Memory)、ROM(Read Only Memory)、フラッシュメモリ(flash memory)などの半導体メモリ素子、または、ハードディスク、光ディスクなどの記憶装置である。
上述したように、要求受信部11は、クライアント2、3や、他ノード5〜7からマーク強度が格納されたPut要求を受信する。また、要求処理部12は、現在実行を準備中の更新処理と新たに受信したPut要求による更新処理との優先度を比較し、新たに受信したPut要求による更新処理の優先度が高いと判別した場合には、準備中の更新処理をキャンセルする。その後、要求処理部12は、新たなPut要求による更新処理の実行を準備するとともに、Put要求に格納されたルーティング情報、または、ノード4が記憶するルーティング情報18bに従って、Put要求を他のノード5〜7に転送させる。
このため、ストレージシステム1は、任意のノードに発行されたPut要求を適切に実行できる。例えば、ノード4は、自身に発行されたPut要求を開始した後に、ノード5に発行されたPut要求の転送を受付けた場合には、どちらのPut要求が先に発行されたものであるかを判別し、より先に判別された方のPut要求を実行する。この結果、ノード4は、任意のノードに発行されたPut要求を適切に実行できる。
また、例えば、クライアント3とノード4が異なるデータセンターに設置されており、クライアント3とノード5が同じデータセンターに設置されている場合に、クライアント3は、1stレプリカを記憶するノード4にPut要求を発行せずともよい。つまり、クライアント3は、異なるデータセンターに設置されたノード4ではなく、同じデータセンターに設置されたノード5にPut要求を発行すればよい。このように、ストレージシステム1は、各クライアント2、3と各ノード4〜7との間のレイテンシを最小限に抑え、各クライアント2、3が発行したPut要求が示す更新処理を、公平に実行することができる。
また、各クライアント2、3は、最も近いノードにPut要求を発行することができる。この結果、ストレージシステム1は、各クライアント2、3が発行するPut要求のラウンドトリップ時間を短縮することができる。例えば、クライアント2とノード4との通信に2ミリ秒のレイテンシが存在し、クライアント3とノード4との通信に25ミリ秒のレイテンシが存在し、クライアント3とノード5との通信に2ミリ秒のレイテンシが存在するものとする。このような場合は、クライアント2がノード4にPut要求を発行し、クライアント3がノード5にPut要求を発行すれば、各クライアント2、3が発行するPut要求のラウンドトリップ時間をそろえることができる。
また、例えば、各クライアント2、3は、Get要求を最寄のノードに発行するため、Put要求の発行先ノードが指定されている場合には、Put要求とGet要求とで異なるノードに対し、セッションを設定することとなる。このため、従来のストレージシステムのように、Put要求の発行先ノードが指定されている場合は、各クライアントとノードとの間に2つのセッションが設定されるので、セッション管理等に要する計算資源や通信資源が増大する。一方、ストレージシステム1においては、各クライアント2、3は、Get要求と同様に、Put要求を最寄のノードに発行することができる。このため、ストレージシステム1は、ッション管理等に要する計算資源や通信資源を削減することができる。
次に、図4を用いて、ストレージシステム1が実行する処理の一例について説明する。図4は、実施例1に係るストレージシステムが実行する処理を説明するための図である。なお、図4に示す例では、クライアント2がクライアント3よりも先にPut要求を発行したものとする。また、図4に示す例では、ネットワークの遅延により、クライアント3が後に発行したPut要求をノード6が取得し、その後、クライアント2が発行したPut要求をノード4が取得したものとする。
また、図4に示す例では、クライアント2、3は、Put要求を発行した時刻をマーク強度として格納するものとする。また、図4に示す例では、ノード4は、ルーティング情報G1を記憶し、ノード6がルーティング情報G3を記憶しているものとする。また、図4に示す例では、各ノード4〜7は、先に発行されたPut要求による更新処理の優先度が高いと判別するものとする。
例えば、図4中(G)に示すように、ノード6は、クライアント3からPut要求を受信する。このような場合には、ノード6は、クライアント3のPut要求による更新処理の実行を準備するとともに、図4中(H)に示すように、クライアント3のPut要求をノード7に転送する。ここで、図4中(I)に示すように、ノード4は、クライアント2からPut要求を受信する。
次に、ノード7は、クライアント3のPut要求による更新処理の実行を準備するとともに、図4中(J)に示すように、Put要求をノード5に転送する。また、図4中(K)に示すように、ノード4は、クライアント2のPut要求をノード5に転送し、図4中(L)に示すように、クライアント2のPut要求をノード6に転送する。すると、ノード5およびノード6は、クライアント2のPut要求による更新処理とクライアント3のPut要求による更新処理との優先度を比較し、先に発行されたクライアント2のPut要求による更新処理の方が優先度が高いと判別する。
このため、ノード5は、クライアント2のPut要求に対して、更新失敗通知をノード7に発行する。また、ノード7は、更新失敗通知をノード6に転送する。その後、ノード6は、Put要求を転送したノード7から更新失敗通知を取得した後に、更新失敗通知をクライアント3に送信する。
また、ノード5は、クライアント2のPut要求による更新処理の実行を準備するとともに、図4中(M)に示すように、クライアント2のPut要求をノード7に転送する。ノード7は、クライアント2のPut要求による更新処理の実行を準備し、図4中(N)に示すように、クライアント2のPut要求をノード6に転送する。
その後ノード6は、Put要求による更新処理を実行し、更新完了通知をノード4とノード7に送信する。このような場合には、ノード7は、準備していた更新処理を実行するとともに、ノード5に更新完了通知を転送する。また、ノード5は、更新完了通知を受信した場合には、準備していた更新処理を実行するとともに、ノード4に更新完了通知を転送する。
その後、ノード4は、ノード6とノード5から更新完了通知を受信した場合には、準備していた更新処理を実行するとともに、クライアント2に対して更新完了通知を転送する。このように、ストレージシステム1は、それぞれ異なるノード4、6に対してPut要求が発行された場合にも、先に発行されたPut要求による更新処理のみを実行することができる。このため、ストレージシステム1は、Put要求の発行先を任意化した場合にも、Strong Consistencyを保持したまま、Put要求による更新処理を適切に実行することができる。
なお、各ノード4〜7は、Put要求にトランザクションIDを付与し、更新失敗通知、または、更新成功通知を送信する場合には、対応するPut要求に付与されたトランザクションIDを付与することで、Put要求と各通知との対応を識別してもよい。
次に、図5、図6を用いて、Put要求処理部13がPut要求を受信した際に実行する処理の流れについて説明する。図5は、実施例1に係るノードがPut要求を受信した際に実行する処理の流れを説明するための第1の図である。また、図6は、実施例1に係るノードがPut要求を受信した際に実行する処理の流れを説明するための第2の図である。
例えば、Put要求処理部13は、Put要求を受信した場合には、図5に示す各処理を実行する。すなわち、Put要求処理部13は、Put要求による更新処理の対象となるレプリカをデータ記憶部18から検索する(ステップS101)。次に、Put要求処理部13は、状態管理表18aの読出しを行い、更新ステータスを取得する(ステップS102)。そして、Put要求処理部13は、他のPut要求による更新処理が実行中か否か、すなわち、更新ステータスに他のPut要求による更新処理の情報が格納されているか否かを判別する(ステップS103)。
また、Put要求処理部13は、他のPut要求による更新処理が準備中ではないと判別した場合には(ステップS103否定)、Put要求を転送するルーティング情報を取得する(ステップS104)。そして、Put要求処理部13は、取得したルーティング情報を用いて、自身が経路の終端であるか否かを判別する(ステップS105)。
また、Put要求処理部13は、自身が経路の終端であると判別した場合には(ステップS105肯定)、更新完了通知部16にPut要求を出力し(ステップS106)、処理を終了する。また、Put要求処理部13は、自身が経路の終端ではないと判別した場合には(ステップS105否定)、状態更新部14にPut要求を出力し(ステップS107)、処理を終了する。
また、Put要求処理部13は、他のPut要求による更新処理が準備中であると判別した場合には(ステップS103肯定)、図6に示す処理を実行する。すなわち、Put要求処理部13は、Put要求を転送するルーティング情報を取得する(ステップS108)。そして、Put要求処理部13は、取得したルーティング情報を用いて、ノード4が終端であるか否かを判別する(ステップS109)。
また、Put要求処理部13は、ノード4が経路の終端ではないと判別した場合には(ステップS109否定)、更新ステータスから現在のマーク強度を取得するとともに、Put要求からマーク強度を取得する(ステップS110)。そして、Put要求処理部13は、Put要求のマーク強度が、現在のマーク強度よりも大きいか否かを判別する(ステップS111)。
その後、Put要求処理部13は、Put要求のマーク強度が、現在のマーク強度よりも大きいと判別した場合には(ステップS111肯定)、状態更新部14にPut要求を出力し(ステップS112)、処理を終了する。また、Put要求処理部13は、Put要求のマーク強度が、現在のマーク強度以下であると判別した場合には(ステップS111否定)、更新失敗通知部15にPut要求を出力し(ステップS113)、処理を終了する。
また、Put要求処理部13は、ノード4が経路の終端であると判別した場合には(ステップS109肯定)、更新ステータスから現在のマーク強度を取得するとともに、Put要求からマーク強度を取得する(ステップS114)。そして、Put要求処理部13は、Put要求のマーク強度が、現在のマーク強度よりも大きいか否かを判別する(ステップS115)。
その後、Put要求処理部13は、Put要求のマーク強度が、現在のマーク強度よりも大きいと判別した場合には(ステップS115肯定)、更新完了通知部16にPut要求を出力し(ステップS116)、処理を終了する。また、Put要求処理部13は、Put要求のマーク強度が、現在のマーク強度以下であると判別した場合には(ステップS115否定)、更新失敗通知部15にPut要求を出力し(ステップS113)、処理を終了する。
次に、図7を用いて、状態更新部14がPut要求を取得した際に実行する状態更新処理の流れについて説明する。図7は、実施例1に係る状態更新処理の流れについて説明するためのフローチャートである。例えば、図7に示す例では、状態更新部14は、Put要求を取得したことをトリガとして、状態更新処理を開始する。
まず、状態更新部14は、Put要求からマーク強度とルーティング情報とを取得する(ステップS201)。次に、状態更新部14は、状態管理表18aの更新ステータスを、取得したマーク強度とルーティング情報とに応じて更新する(ステップS202)。具体的には、状態更新部14は、取得したルーティング情報から親レプリカと子レプリカ数とを識別し、マーク強度とともに、更新ステータスとして格納する。次に、状態更新部14は、Put要求を要求発行部19に送信することで、Put要求を子レプリカを記憶するノードに転送するよう依頼し(ステップS203)、処理を終了する。
次に、図8を用いて、更新失敗通知部15がPut要求を取得した際に実行する更新失敗通知処理の流れについて説明する。図8は、実施例1に係る更新失敗通知処理の流れについて説明するためのフローチャートである。例えば、図8に示す例では、更新失敗通知部15は、Put要求を取得したことをトリガとして、更新失敗通知処理を開始する。
まず、更新失敗通知部15は、Put要求に格納されたルーティング情報を用いて、親、すなわち、ノード4に対してPut要求を送信したノード、または、クライアントを識別する(ステップS301)。そして、更新失敗通知部15は、親がクライアントであるか否かを判別する(ステップS302)。
また、更新失敗通知部15は、親がクライアントである場合には(ステップS302肯定)、要求発行部19にクライアントへ更新失敗通知を送信するよう依頼し(ステップS303)、処理を終了する。また、更新失敗通知部15は、親がクライアントでない場合には(ステップS302否定)、親レプリカを記憶するノードを識別し(ステップS304)、識別したノードに更新失敗通知を送信するよう要求発行部19に依頼する(ステップS305)。その後、更新失敗通知部15は、処理を終了する。
次に、図9を用いて、更新完了通知部16がPut要求を取得した際に実行する更新完了通知処理の流れについて説明する。図9は、実施例1に係る更新完了通知処理の流れについて説明するためのフローチャートである。例えば、図9に示す例では、更新完了通知部16は、Put要求を取得したことをトリガとして、更新失敗通知処理を開始する。
まず、更新完了通知部16は、取得したPut要求に従って、データ記憶部18に記憶されたレプリカを更新するようデータ更新部17に依頼する(ステップS401)。そして、更新完了通知部16は、ルーティング情報を用いて、親ノード、または、親レプリカを識別する(ステップS402)。また、更新完了通知部16は、親がクライアントであるか否かを判別する(ステップS403)。
そして、更新完了通知部16は、親がクライアントであると判別した場合には(ステップS403肯定)、クライアントに更新完了通知の送信を要求発行部19に依頼し(ステップS404)、処理を終了する。また、更新完了通知部16は、親がノードであると判別した場合には(ステップS403否定)、親レプリカを記憶するノードを識別し(ステップS405)、識別したノードに更新完了通知を送信するよう要求発行部19に依頼する(ステップS406)。その後、更新完了通知部16は、処理を終了する。
次に、図10、図11を用いて、更新失敗通知部15が更新失敗通知を取得した際に実行する処理の流れについて説明する。図10は、更新失敗通知を取得した際に実行する処理の流れを説明するための第1のフローチャートである。図11は、更新失敗通知を取得した際に実行する処理の流れを説明するための第2のフローチャートである。なお、図10に示す例では、更新失敗通知部15は、更新失敗通知を取得したことをトリガとして処理を開始する。
まず、更新失敗通知部15は、状態管理表18aから更新ステータスを読み出す(ステップS501)。そして、更新失敗通知部15は、更新ステータスのマーク強度と更新失敗通知のマーク強度が一致するか否かを判別する(ステップS502)。そして、更新失敗通知部15は、更新ステータスのマーク強度と更新失敗通知のマーク強度とが一致する場合は(ステップS502肯定)、以下の処理を実行する。すなわち、更新失敗通知部15は、状態管理表18aの更新失敗フラグを更新ステータスに設定するとともに、更新ステータスの子レプリカ数を1減らす(ステップS503)。
次に、更新失敗通知部15は、更新ステータスの子レプリカ数が0であるか否かを判別し(ステップS504)、更新ステータスの子レプリカ数が0であると判別した場合には(ステップS504肯定)、以下の処理を実行する。すなわち、更新失敗通知部15は、更新が失敗した更新処理を要求したPut要求の送信元である親が、クライアントであるか否かを判別する(ステップS505)。
そして、更新失敗通知部15は、親がクライアントである場合には(ステップS505肯定)、要求発行部19にクライアントへ更新失敗通知を送信するよう依頼し(ステップS506)、処理を終了する。また、更新失敗通知部15は、親がクライアントではない場合には(ステップS505否定)、親レプリカを記憶するノードを識別し(ステップS507)、識別したノードに更新失敗通知を送信するよう要求発行部19に依頼する(ステップS508)。その後、更新失敗通知部15は、処理を終了する。なお、更新失敗通知部15は、更新ステータスの子レプリカ数が0ではないと判別した場合には(ステップS504否定)、処理を終了する。
一方、更新失敗通知部15は、更新ステータスのマーク強度と更新失敗通知のマーク強度とが一致しない場合は(ステップS502否定)、図11に示す処理を開始する。すなわち、更新失敗通知部15は、状態管理表18aのキャンセル表から、更新失敗通知のマーク強度と一致するマーク強度を有するエントリを取得する(ステップS509)。
次に、更新失敗通知部15は、取得したエントリの子レプリカ数を1減らし(ステップS510)、子レプリカ数が0になったか否かを判別する(ステップS511)。次に、更新失敗通知部15は、子レプリカ数が0になったと判別した場合は(ステップS511肯定)、取得したエントリをキャンセル表から削除するとともに(ステップS512)、以下の処理を実行する。すなわち、更新失敗通知部15は、更新が失敗した更新処理を要求したPut要求の送信元である親が、クライアントであるか否かを判別する(ステップS513)。
そして、更新失敗通知部15は、親がクライアントである場合には(ステップS513肯定)、要求発行部19にクライアントへ更新失敗通知を送信するよう依頼し(ステップS514)、処理を終了する。また、更新失敗通知部15は、親がクライアントではない場合には(ステップS513否定)、親レプリカを記憶するノードを識別し(ステップS515)、識別したノードに更新失敗通知を送信するよう要求発行部19に依頼する(ステップS516)。その後、更新失敗通知部15は、処理を終了する。なお、更新失敗通知部15は、更新ステータスの子レプリカ数が0ではないと判別した場合には(ステップS511否定)、処理を終了する。
次に、図12、図13、図14を用いて、更新完了通知部16が更新完了通知を取得した際に実行する処理の流れについて説明する。図12は、更新完了通知を取得した際に実行する処理の流れを説明するための第1のフローチャートである。図13は、更新完了通知を取得した際に実行する処理の流れを説明するための第2のフローチャートである。図14は、更新完了通知を取得した際に実行する処理の流れを説明するための第3のフローチャートである。
まず、図12に示す例では、更新完了通知部16は、更新完了通知を取得したことをトリガとして、処理を開始する。まず、更新完了通知部16は、更新ステータスを状態管理表18aから取得する(ステップS601)。次に、更新完了通知部16は、更新ステータスのマーク強度と更新完了通知のマーク強度とが一致するか否かを判別する(ステップS602)。そして、更新完了通知部16は、更新ステータスのマーク強度と更新完了通知のマーク強度とが一致しない場合には(ステップS602否定)、図11に示した更新失敗通知部15と同じ処理を実行する。
一方、更新完了通知部16は、更新ステータスのマーク強度と更新完了通知のマーク強度とが一致する場合には(ステップS602肯定)、更新失敗フラグが設定済みか否かを判別する(ステップS603)。
ここで、更新完了通知部16は、更新失敗フラグが設定済みではない場合には(ステップS603否定)、図13に示す処理を実行する。すなわち、更新完了通知部16は、状態管理表18aの更新ステータスの子レプリカ数を1減らし(ステップS604)、子レプリカ数が0になったか否かを判別する。そして、更新完了通知部16は、子レプリカ数が0になったと判別した場合には(ステップS605肯定)、レプリカの更新をデータ更新部17に依頼する(ステップS606)。
次に、更新完了通知部16は、状態管理表18aの更新ステータスをクリアし(ステップS607)、更新が完了した更新処理を要求したPut要求の送信元である親がクライアントであるか否かを判別する(ステップS608)。そして、更新完了通知部16は、親がクライアントである場合には(ステップS608肯定)、要求発行部19にクライアントへ更新完了通知を送信するよう依頼し(ステップS609)、処理を終了する。
また、更新完了通知部16は、親がクライアントではない場合には(ステップS608否定)、親レプリカを記憶するノードを識別し(ステップS610)、識別したノードに更新完了通知を送信するよう要求発行部19に依頼する(ステップS611)。その後、更新完了通知部16は、処理を終了する。なお、更新完了通知部16は、子レプリカ数が0ではない場合には(ステップS605否定)、処理を終了する。
一方、図12に戻って、更新完了通知部16は、更新失敗フラグが設定済みであると判別した場合には(ステップS603肯定)、状態管理表18aの更新ステータスの子レプリカ数を1減らし(ステップS612)、子レプリカ数が0になったか否かを判別する(ステップS613)。次に、更新完了通知部16は、子レプリカ数が0になったと判別した場合は(ステップS613肯定)、更新が失敗した更新処理を要求したPut要求の送信元である親が、クライアントであるか否かを判別する(ステップS614)。
そして、更新完了通知部16は、親がクライアントである場合には(ステップS614肯定)、要求発行部19にクライアントへ更新失敗通知を送信するよう依頼し(ステップS615)、処理を終了する。また、更新完了通知部16は、親がクライアントではない場合には(ステップS614否定)、親レプリカを記憶するノードを識別し(ステップS616)、識別したノードに更新失敗通知を送信するよう要求発行部19に依頼する(ステップS617)。その後、更新完了通知部16は、処理を終了する。なお、更新完了通知部16は、子レプリカ数が0ではない場合には(ステップS613否定)、処理を終了する。
[ノードの効果]
上述したように、ノード4は、更新処理の優先度であるマーク強度が格納されたPut要求を受信する。そして、ノード4は、Put要求を受信した際に、他の更新処理を実行している場合には、新たに受信したPut要求が要求する更新処理の優先度が、準備中の更新処理の優先度よりも高いか否かを判別する。例えば、ノード4は、新たに受信したPut要求が発行された時刻が、準備中の更新処理を要求したPut要求が発行された時刻よりも先であるか否かを判別する。
そして、ノード4は、新たに受信したPut要求が要求する更新処理の優先度が、準備中の更新処理の優先度よりも高いと判別した場合には、準備中の更新処理をキャンセルするとともに、新たに受信したPut要求を、他のノード5〜7へ転送する。このため、ノード4〜7を有するストレージシステム1は、どのノード4〜7に発行されたPut要求も適切に実行することができる。
また、ノード4は、新たに受信したPut要求が要求する更新処理の優先度が、準備中の更新処理の優先度よりも低いと判別した場合には、Put要求の送信元に対して、更新失敗通知を送信する。このため、ノード4〜7を有するストレージシステム1は、優先度の高い更新処理を優先して実行するとともに、優先度の低い更新処理を要求するPut要求の送信元へ、Put要求が失敗した旨を通知することができる。
また、ノード4は、Put要求を転送したノードから更新失敗通知を受信した場合には、転送したPut要求が要求する更新処理の実行をキャンセルするとともに、更新失敗通知を、ノード4にPut要求を送信したノードやクライアントへ転送する。このため、ノード4〜7を有するストレージシステム1は、Put要求の送信先で失敗した更新処理を実行することなく、処理を進めることができる。
また、ノード4は、クライアントから受信したPut要求には、自身が記憶するルーティング情報18bを格納するとともに、ルーティング情報18bが示す経路に従って、Put要求を他のノード5〜7に転送する。また、ノード4は、他のノード5〜7から受信したPut要求を転送する場合には、Put要求に格納されたルーティング情報、すなわち、他のノード5〜7が記憶するルーティング情報に従って、Put要求を転送する。このため、ノード4〜7を有するストレージシステム1は、Put要求を受付けた各ノード4〜7ごとに、効率良くPut要求を転送する経路を定めることができる。
また、ノード4は、自身がPut要求を転送した全てのノードから更新完了通知を受信した場合には、Put要求の送信元であるクライアント、または、他のノードへ更新完了通知を送信する。このため、ノード4〜7を有するストレージシステム1は、Put要求を転送する経路が複数存在する場合、つまり、Put要求を送信する経路がマルチパスである場合にも、Strong Consistencyを保持したまま、更新処理を実行することができる。
また、ノード4は、実行をキャンセルした更新処理についての更新完了通知を他のノードから受信した場合には、実行をキャンセルした更新処理を要求するPut要求の送信元へ、更新失敗通知を送信する。このため、ノード4は、キャンセルされる更新処理についての更新完了通知を転送することなく、各ノード4〜7が実行する更新処理をそろえることができる。
また、ノード4は、更新処理の準備中にPut要求を受信した場合は、準備中の更新処理を要求したPut要求が発行された時刻と、新たに受信したPut要求が発行された時刻とを比較し、より早く発行されたPut要求が要求する更新処理を実行する。このため、ノード4は、各ノード4〜7の設置位置が分散されている場合にも、各クライアント2、3が発行するPut要求が要求する更新処理を公平に実行することができる。
以下の実施例2では実施例1の状態管理表18aとは異なる状態管理表18dを有するノード4aについて説明する。まず、図15を用いて、ノード4aについて説明する。図15は、実施例2に係るノードの機能構成を説明するための図である。なお、図15に示す例では、図2に示した各部10〜24と同様の処理を実行するものについては、同じ符号を付し、以下の説明を省略する。
図15に示す例では、ノード4aは、要求処理部12a、要求発行部19aを有する。要求処理部12aは、Put要求処理部13a、状態更新部14a、更新失敗通知部15a、更新完了通知部16aを有する。また、ノード4aは、データ記憶部18に、状態管理表18dを記憶させる。
図16は、実施例2に係る状態管理表を説明するための図である。図16に示す例では、状態管理表18dには、更新ステータスとして、マーク強度、親レプリカ、親のエージ、子レプリカ数が格納され、ノード4aのエージが更新ステータスとは別に格納される。なお、更新処理を要求するPut要求の送信元がクライアントである場合には、親レプリカの代わりにクライアントを示す情報が格納される。
また、エージとは、ノード4aが更新失敗通知および更新完了通知を他のノードから受信した際に、他のノードにおいて失敗、または完了した更新処理が、他の更新処理と衝突したか否かを判別するための情報である。また、図16に示す例では、転送されるPut要求、更新失敗通知、更新完了通知には、マーク強度とルーティング情報とに加えて、エージ情報が格納される。
Put要求処理部13aは、Put要求処理部13が実行する処理と同様の処理を実行する。ただし、Put要求処理部13aは、新たに受信したPut要求のマーク強度が更新ステータスのマーク強度よりも低い場合には、更新ステータスの情報を更新失敗通知部15aに出力する。つまり、Put要求処理部13aは、キャンセルされる更新要求の情報を更新失敗通知部15aに出力する。その後、Put要求処理部13aは、新たに受信したPut要求を状態更新部14aに出力する。
状態更新部14aは、状態更新部14が実行する処理と同様の処理を実行する。また、状態更新部14aは、クライアントがノード4aに発行したPut要求を取得した場合には、更新ステータスに、クライアントのエージ「⊥」を併せて格納する。ここで、「⊥」とは、エージの最小値を示す記号であるが、他の記号を採用することとしてもよい。
更新失敗通知部15aは、更新失敗通知部15と同様の処理を実行する。ただし、更新失敗通知部15aは、更新ステータスの情報、つまり、キャンセルされる更新処理に係るマーク強度、親レプリカ、親のエージ、子レプリカ数を通知された場合は、以下の処理を実行する。
すなわち、更新失敗通知部15aは、取得した更新ステータスに含まれる親レプリカを記憶するノード、または、クライアントに対して更新失敗通知を送信するよう要求発行部19aに依頼する。また、更新失敗通知部15aは、ノード4aのエージを1インクリメントする。また、更新失敗通知部15aは、更新失敗通知を取得した場合には、更新ステータスを状態管理表18dから取得し、更新失敗通知に格納されたマーク強度と更新ステータスのマーク強度が一致するか否かを判別する。また、更新失敗通知部15aは、更新失敗通知に格納されたエージと、状態管理表18dの現在のエージとが一致するか否かを判別する。
そして、更新失敗通知部15aは、更新失敗通知のマーク強度が更新ステータスのマーク強度と一致し、かつ、更新失敗通知のエージと、現在のエージが一致しない場合には、準備中の更新処理をキャンセルするため、更新ステータスをクリアする。つまり、更新失敗通知部15aは、ノード4aから転送したPut要求が他のノードで他のPut要求と衝突し、優先度負けして実行されなかったと判別した場合には、準備中の更新処理をキャンセルするため、更新ステータスをクリアする。
そして、更新失敗通知部15aは、キャンセルした更新処理を要求したPut要求の送信元であるクライアント、または、ノードを識別し、識別したクライアント、または、ノードに更新失敗通知を送信するよう要求発行部19aに依頼する。なお、更新失敗通知部15aは、更新失敗通知を送信するよう要求発行部19aに依頼する場合には、Put要求に格納されていたエージ、すなわち、Put要求の送信元である親のエージを出力する。また、更新失敗通知部15aは、更新失敗通知を転送するよう要求発行部19aに依頼する場合には、クリアする更新ステータスに含まれる親のエージを出力する。
更新完了通知部16aは、更新完了通知を取得した場合には、更新ステータスを状態管理表18dから取得し、更新完了通知のマーク強度が更新ステータスのマーク強度と一致し、かつ、更新完了通知のエージと、現在のエージが一致するか判別する。そして、更新完了通知部16aは、更新ステータスを状態管理表18dから取得し、更新完了通知のマーク強度が更新ステータスのマーク強度と一致し、かつ、更新完了通知のエージと、現在のエージが一致する場合には、以下の処理を実行する。
まず、更新完了通知部16aは、更新ステータスの子レプリカ数を1デクリメントする。次に、更新完了通知部16aは、更新ステータスの子レプリカ数が0となったか否かを判別する。つまり、更新完了通知部16aは、Put要求を転送した全てのノードから、マーク強度とエージとが一致する更新完了通知を取得したか否かを判別する。そして、更新完了通知部16aは、更新ステータスの子レプリカ数が0となった場合には、レプリカを更新するとともに、更新ステータスをクリアする。
そして、更新完了通知部16aは、実行した更新処理を要求するPut要求の送信元であるクライアント、またはノードを識別し、識別したクライアント又はノードに更新完了通知を送信するよう要求発行部19aに依頼する。なお、更新完了通知部16aは、更新完了通知を送信するよう要求発行部19aに依頼する場合には、Put要求に格納されていたエージ、すなわち、Put要求の送信元である親のエージを出力する。また、更新完了通知部16aは、更新失敗通知や更新完了通知を転送するよう要求発行部19aに依頼する場合には、クリアする更新ステータスに含まれる親のエージを出力する。
要求発行部19aは、要求発行部19と同様の処理を実行する。また、要求発行部19aは、更新失敗通知部15a、または、更新完了通知部16aから更新失敗通知を送信するよう依頼された場合には、以下の処理を実行する。すなわち、要求発行部19aは、更新失敗通知を送信する依頼とともに、クリアする更新ステータスに含まれる親のエージを取得し、取得した親のエージを更新失敗通知に格納する。
また、要求発行部19aは、Put要求を送信する場合には、状態管理表18dを参照し、更新ステータスを取得する。そして、要求発行部19aは、取得した状態管理表18dの現在のエージをPut要求に格納し、エージを格納したPut要求を送信する。
また、要求発行部19aは、更新完了通知や更新失敗通知を生成した場合には、更新処理を要求したPut要求に格納されているエージ、つまり、親ノードのエージを格納する。また、要求発行部19aは、更新完了通知や更新失敗通知を転送する場合には、更新失敗通知部15aや更新完了通知部16aから通知されたエージを格納する。
このようなノード4aは、クライアント2から受信したPut要求を転送する場合には、現在のエージをPut要求に格納して転送する。また、ノード4aは、終端ではなく、かつ、他のノードから受信したPut要求が優先度負けしない場合には、取得したPut要求に格納されたエージを現在のエージ、つまり、ノード4a自身のエージとする。
また、ノード4aは、優先度負けした更新処理をキャンセルした場合には、キャンセルした更新処理を要求したPut要求に格納されていたエージ、つまり親ノードのエージを更新失敗通知に格納し、その後、更新失敗通知を親ノードに送信する。また、ノード4aは、更新失敗通知を送信する場合には、現在のエージを1加算する。その後、ノード4aは、優先度勝ちした更新処理を要求したPut要求に、現在のエージを格納し、子レプリカを記憶するノードに転送する。
また、ノード4aは、自身が終端であり、かつ、受信したPut要求が示す更新処理が優先度負けしなかった場合には、レプリカのデータを更新するとともに、親ノードのエージが格納された更新完了通知を親ノードに送信する。また、ノード4aは、レプリカのデータを更新した場合には、親ノードのエージを更新完了通知に格納し、その後、更新完了通知を親ノードに送信する。
このため、ノード4aは、送信したPut要求が示す更新処理が、全ての子ノードにおいて実行され、かつ、ノード4aにて準備中の更新処理が優先負けしなかった場合にのみ、現在のエージと同一のエージが格納された更新完了通知を受信する。一方、ノード4aは、Put要求を送信してから更新完了通知を受信するまでの間に、更新処理が優先度負けした場合には、現在のエージとは異なるエージが格納された更新完了通知を受信するので、レプリカの更新処理を実行しない。この結果、ノード4aは、任意のノードに発行されたPut要求を適切に実行することができる。
次に、図17を用いて、実施例2に係る更新失敗通知部15aが更新失敗通知を取得した際に実行する処理の流れについて説明する。図17は、実施例2に係る更新失敗通知部が更新失敗通知を取得した際に実行する処理の流れを説明するためのフローチャートである。なお、図17に示す例では、更新失敗通知部15aは、更新失敗通知を取得したことをトリガとして、処理を実行する。
まず、更新失敗通知部15aは、状態管理表18dから更新ステータスを取得する(ステップS701)。次に、更新失敗通知部15aは、更新ステータスと更新失敗通知とのマーク強度が一致し、かつ、更新ステータスのエージと現在のエージとが一致するか否かを判別する(ステップS702)。
そして、更新失敗通知部15aは、各マーク強度、および、各エージが一致しない場合には(ステップS702否定)、処理を終了する。一方、更新失敗通知部15aは、各マーク強度、および、各エージが一致すると判別した場合には(ステップS702肯定)、状態管理表18dの更新ステータスをクリアする(ステップS703)。
また、更新失敗通知部15aは、クリアした更新ステータスが示す更新処理において、親がクライアントであるか否かを判別する(ステップS704)。そして、更新失敗通知部15aは、親がクライアントであると判別した場合には(ステップS704肯定)、要求発行部19aにクライアントへ更新失敗通知の送信を依頼し(ステップS705)、処理を終了する。
一方、更新失敗通知部15aは、親がクライアントではないと判別した場合には(ステップS704否定)、親レプリカを記憶するノードを識別する(ステップS706)。その後、更新失敗通知部15aは、要求発行部19aに識別したノードへ更新失敗通知を送信するように依頼し(ステップS707)、処理を終了する。
次に、図18、図19を用いて、更新完了通知部16aが、更新完了通知を取得した際に実行する処理の流れを説明する。なお、図18は、実施例2に係る更新完了通知部が更新完了通知を取得した際に実行する処理の流れを説明するための第1のフローチャートである。また、図19は、実施例2に係る更新完了通知部が更新完了通知を取得した際に実行する処理の流れを説明するための第2のフローチャートである。
なお、図18に示す例では、更新完了通知部16aは、更新完了通知を取得したことをトリガとして、処理を実行する。まず、更新完了通知部16aは、状態管理表18dから更新ステータスを取得する(ステップS801)。次に、更新完了通知部16aは、更新ステータスと更新完了通知とのマーク強度が一致し、かつ、更新ステータスのエージと現在のエージとが一致するか否かを判別する(ステップS802)。そして、更新完了通知部16aは、更新ステータスと更新完了通知とのマーク強度が一致し、かつ、更新ステータスのエージと現在のエージとが一致しない場合は(ステップS802否定)、処理を終了する。
そして、更新完了通知部16aは、各マーク強度、および、各エージが一致すると判別した場合には(ステップS802肯定)、状態管理表18dの更新ステータスの子レプリカ数を1減らす(ステップS803)。次に、更新完了通知部16aは、子レプリカの数が0であるか否かを判別し(ステップS804)、子レプリカの数が0ではない場合には(ステップS804否定)、処理を終了する。一方、更新完了通知部16aは、子レプリカの数が0である場合には(ステップS804肯定)、図19に示す処理を実行する。
まず、更新完了通知部16aは、レプリカの更新をデータ更新部17に依頼する(ステップS805)。次に、更新完了通知部16aは、状態管理表18dの更新ステータスをクリアする(ステップS806)。そして、更新完了通知部16aは、クリアした更新ステータスが示す更新処理において、親がクライアントであるか否かを判別する(ステップS807)。
そして、更新完了通知部16aは、親がクライアントであると判別した場合には(ステップS807肯定)、要求発行部19aにクライアントへ更新完了通知の送信を依頼し(ステップS808)、処理を終了する。一方、更新完了通知部16aは、親がクライアントではないと判別した場合には(ステップS807否定)、親レプリカを記憶するノードを識別する(ステップS809)。その後、更新完了通知部16aは、要求発行部19aに識別したノードへ更新完了通知を送信するように依頼し(ステップS810)、処理を終了する。
[ノード4aの効果]
上述したように、ノード4aは、状態管理表18dにキャンセル表を備えずとも、更新完了通知や更新失敗通知のエージと現在のエージとが一致するか否かを判別することにより、子レプリカを記憶するノードにおいて優先負けしたか否かを判別する。このため、ノード4aは、キャンセル表を備えずとも、任意のノードに対して発行された複数のPut処理が示す更新処理を、適切に実行することができる。
また、ノード4aは、状態管理表18dにキャンセル表を有さないので、状態管理表18dの容量を削減することができる。また、ノード4aは、キャンセル表の各エントリについての操作を不要とするので、処理コストを削減することができる。
また、ノード4aは、現在のエージと更新完了通知のエージとが異なる場合には、すぐに更新失敗通知を親レプリカを記憶するノードやクライアントに送信する。このため、ノード4aは、Put要求の結果を迅速にクライアント2、3に送信することができる。
これまで本発明の実施例について説明したが実施例は、上述した実施例以外にも様々な異なる形態にて実施されてよいものである。そこで、以下では実施例3として本発明に含まれる他の実施例を説明する。
(1)優先度について
上述したノード4、ノード4aは、Put要求が発行された時刻をマーク強度とし、先に発行されたPut要求が要求する更新処理を実行した。しかし、実施例はこれに限定されるものではない。
例えば、ノード4、4aは、後に発行されたPut要求が要求する更新処理を実行することとしてもよい。すなわち、ノード4、4aは、準備中の更新要求に係るマーク強度と、新たに受信したPut要求のマーク強度とを比較し、後の時刻を示すマーク強度が格納されたPut要求が要求する更新要求を実行することとしてもよい。
このような処理を実行した場合には、例えば、ノード4、4aは、レプリカのデータが最後の更新のみが適用されるようなデータである場合には、更新処理をlazyに実行する結果、更新回数を削減することができる。
また、ノード4、4aは、複数のマーク強度を用いることとしてもよい。例えば、ノード4、4aは、Put要求が発行された時刻に加えて、Put要求をクライアント2、3から受信したノードに一意の数値を格納する。そして、ノード4、4aは、準備中の更新要求に係るPut要求のマーク強度と、新たに受信したPut要求のマーク強度を比較し、時刻が同一である場合には、Put要求を受信したノードに応じて、実行する更新要求を決定しても良い。このような処理を実行した場合には、ノード4、4aは、クライアント側が計測する時刻の制度が十分ではない場合にも、本発明を適用することができる。
また、ノード4、4aは、マーク強度として、Put要求をノードが受信した際の時刻を用いることとしてもよい。一般に、ストレージシステムに含まれる各ノードの時刻は、高精度で一致しており、より信頼性の高い処理を実行することができる。
また、ノード4、4aは、Put要求を発行させたユーザに応じて、実行する更新処理を決定しても良い。また、ノード4、4aは、更新処理の対象となるデータのサイズに応じて、実行する更新処理を決定しても良い。例えば、ノード4、4aは、小さいサイズのデータほど、優先的に更新処理が実行されることとしてもよい。すなわち、小さいサイズのデータほど、記憶領域を確保し易いという経験則より、ストレージシステム1全体のレイテンシを小さくすることができる。
(2)ノードの数およびルーティング情報について
上述したストレージシステム1は、ノード4〜7を有していたが、実施例はこれに限定されるものではなく、任意の数のノードを有することができる。また、各ノード4〜7は、同じデータのレプリカを記憶していたが、実施例はこれに限定されるものではない。例えば、ノード4〜6がデータAのレプリカを記憶し、ノード3〜7がデータBのレプリカを記憶しているものとする。このような場合にも、各ノード4〜7は、レプリカごとにルーティング情報を有し、Put要求の対象となるデータに応じたルーティング情報を格納した場合には、任意のノードに発行されたPut要求を適切に実行することができる。
また、上述したルーティング情報は、あくまで一例であり、Put要求を転送する経路を特定することができるのであれば、任意の形式のルーティング情報を採用してよい。例えば、各ノードが記憶するレプリカのデータが移動せずに固定である場合には、Put要求の転送先となるレプリカではなく、ノードを示す情報が格納されたルーティング情報であってもよい。
(3)各情報について
上述したノード4、ノード4aは、ルーティング情報、エージ、マーク強度をPut要求、更新失敗通知、更新完了通知に格納して送信した。しかし、実施例はこれに限定されるものではなく、例えば、ノード4、ノード4aは、ルーティング情報、エージ、マーク強度等を、Put要求とともに送信してもよい。
(4)プログラム
ところで、実施例1、2に係るノード4、4aは、ハードウェアを利用して各種の処理を実現する場合を説明した。しかし、実施例はこれに限定されるものではなく、あらかじめ用意されたプログラムをストレージ装置として動作するコンピュータで実行することによって実現するようにしてもよい。そこで、以下では、図20を用いて、実施例1に示したノード4と同様の機能を有するプログラムを実行するコンピュータの一例を説明する。図20は、ストレージ制御プログラムを実行するコンピュータの一例を説明するための図である。
図20に例示されたコンピュータ100は、ROM(Read Only Memory)110、HDD(Hard Disk Drive)120、RAM(Random Access Memory)130、CPU(Central Processing Unit)140がバス160で接続される。また、コンピュータ100は、他のコンピュータと通信を行うためのI/O(Input Output)150がバス160で接続される。
なお、HDD120は、通常のレプリカや、状態管理表18a、ルーティング情報18b、ノード情報18cが記憶されることとなる。RAM130には、ストレージ制御プログラム131が記憶されており、CPU140が読み出して実行することによって、図20に示す例では、ストレージ制御プロセス141として機能するようになる。なお、ストレージ制御プロセス141は、図2に示すノード4と同様の機能を発揮するが、図15に示すノード4aと同様の機能を発揮させることも可能である。
なお、本実施例で説明したシステム制御プログラムは、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク(FD)、CD−ROM(Compact Disc Read Only Memory)、MO(Magneto Optical Disc)、DVD(Digital Versatile Disc)などのコンピュータで読取可能な記録媒体に記録される。また、このプログラムは、コンピュータによって記録媒体から読み出されることによって実行することもできる。
1 ストレージシステム
2、3 クライアント
4〜7、4a ノード
10 ネットワークインターフェース
11 要求受信部
12、12a 要求処理部
13、13a Put要求処理部
14、14a 状態更新部
15、15a 更新失敗通知部
16、16a 更新完了通知部
17 データ更新部
18 データ記憶部
18a、18d 状態管理表
19、19a 要求発行部
20 クライアント位置記憶部
21 トポロジー計算部
22 ノード間要求並列送信部
23 クライアント位置判断部
24 クライアント要求送信部

Claims (9)

  1. データの更新処理の要求と、当該更新処理の優先度を示す優先度とを受信する受信部と、
    前記データを記憶する他のストレージ装置へ、前記更新処理の要求と前記優先度とを転送する転送部と、
    前記更新処理の要求を受信した場合は、当該更新処理の実行を待機し、前記他のストレージ装置から前記データの更新を行った旨の応答をさらに受信した場合は、前記待機させた更新処理を実行する処理部と、
    前記受信部が新たに更新処理の要求と前記優先度とを受信した際に、前記処理部が他の更新処理の実行を待機している場合には、当該新たに受信した優先度が、待機中の更新処理の優先度よりも高いか否かを判別する判別部と、
    を有し、
    前記処理部は、前記判別部が、前記新たに受信した優先度が前記待機中の更新処理の優先度よりも高いと判別した場合には、前記待機中の更新処理の実行をキャンセルし、
    前記転送部は、前記判別部が、前記新たに受信した優先度が前記待機中の更新処理の優先度よりも高いと判別した場合には、前記データを記憶する他のストレージ装置へ、前記新たに受信した更新処理の要求と前記新たに受信した優先度とを転送す
    とを特徴とするストレージ装置。
  2. 前記転送部は、前記判別部が、前記新たに受信した優先度が前記待機中の更新処理の優先度よりも低いと判別した場合には、前記新たに受信した要求の送信元に対して、前記更新処理が失敗した旨の応答を送信することを特徴とする請求項1に記載のストレージ装置。
  3. 前記処理部は、前記更新処理の要求と前記優先度とを転送したストレージ装置から前記更新処理が失敗した旨の通知を受信した場合には、当該更新処理の実行をキャンセルし、
    前記転送部は、前記処理部が実行をキャンセルした更新処理の要求の送信元に対して、当該更新処理が失敗した旨の通知を転送することを特徴とする請求項2に記載のストレージ装置。
  4. 前記データを記憶する複数のストレージ装置を接続した経路を示す経路情報を記憶する経路記憶部をさらに有し、
    前記転送部は、クライアントから受信した前記更新処理の要求と前記優先度とを転送する場合には、当該更新処理の要求と当該優先度とともに前記経路情報を転送し、前記他のストレージ装置から受信した前記更新処理の要求と前記優先度と前記経路情報とを転送する場合には、当該経路情報が示す経路に従って、当該更新処理の要求と当該優先度と当該経路情報とを転送することを特徴とする請求項1〜3のいずれか1つに記載のストレージ装置。
  5. 前記転送部は、前記更新処理の要求を転送した全てのストレージ装置から当該更新処理が完了した旨の応答を受信した場合には、前記待機中の更新処理を実行するとともに、当該更新処理の要求の送信元へ、当該更新処理が完了した旨の応答を転送することを特徴とする請求項4に記載のストレージ装置。
  6. 前記転送部は、前記処理部が実行をキャンセルした更新処理について、他のストレージ装置から当該更新処理が完了した旨の応答を受信した場合には、当該更新処理の要求の送信元へ、当該更新処理が失敗した旨の応答を送信することを特徴とする請求項4または5に記載のストレージ装置。
  7. 前記受信部は、クライアントが前記更新処理の要求を発行した時刻を前記優先度として受信し、
    前記判別部は、前記新たに受信した時刻が、前記待機中の更新処理の要求とともに受信した時刻よりも古い時刻を示す場合には、当該新たに受信した優先度が、前記待機中の更新処理の優先度よりも高いと判別することを特徴とする請求項1〜6のいずれか1つに記載のストレージ装置。
  8. データの更新処理を要求する更新要求と当該更新処理の優先度を示す優先度とを受信した場合には、当該更新処理を実行するストレージ装置が実行するストレージ制御プログラムであって、
    前記データを記憶する他のストレージ装置へ、前記更新処理の要求と前記優先度とを転送し、
    前記更新処理の要求を受信した場合は、当該更新処理の実行を待機し、前記他のストレージ装置から前記データの更新を行った旨の応答をさらに受信した場合は、前記待機させた更新処理を実行し、
    新たに更新処理の要求と前記優先度とを受信した際に、他の更新処理の実行を待機している場合には、当該新たに受信した優先度が、待機中の更新処理の優先度よりも高いか否かを判別し、
    前記新たに受信した優先度が前記待機中の更新処理の優先度よりも高いと判別した場合には、前記待機中の更新処理の実行をキャンセルし、
    前記新たに受信した優先度が前記待機中の更新処理の優先度よりも高いと判別した場合には、前記データを記憶する他のストレージ装置へ、前記新たに受信した更新処理の要求と前記新たに受信した優先度とを転送す
    処理を前記ストレージ装置に実行させることを特徴とするストレージ制御プログラム。
  9. データの更新処理を要求する更新要求と当該更新処理の優先度を示す優先度とを受信した場合には、当該更新処理を実行するストレージ装置が実行するストレージ制御方法であって、
    前記データを記憶する他のストレージ装置へ、前記更新処理の要求と前記優先度とを転送し、
    前記更新処理の要求を受信した場合は、当該更新処理の実行を待機し、前記他のストレージ装置から前記データの更新を行った旨の応答をさらに受信した場合は、前記待機させた更新処理を実行し、
    新たに更新処理の要求と前記優先度とを受信した際に、他の更新処理の実行を待機している場合には、当該新たに受信した優先度が、待機中の更新処理の優先度よりも高いか否かを判別し、
    前記新たに受信した優先度が前記待機中の更新処理の優先度よりも高いと判別した場合には、前記待機中の更新処理の実行をキャンセルし、
    前記新たに受信した優先度が前記待機中の更新処理の優先度よりも高いと判別した場合には、前記データを記憶する他のストレージ装置へ、前記新たに受信した更新処理の要求と前記新たに受信した優先度とを転送す
    処理を実行することを特徴とするストレージ制御方法。
JP2011263010A 2011-11-30 2011-11-30 ストレージ装置、ストレージ制御プログラムおよびストレージ制御方法 Active JP5879982B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2011263010A JP5879982B2 (ja) 2011-11-30 2011-11-30 ストレージ装置、ストレージ制御プログラムおよびストレージ制御方法
US13/615,836 US9208114B2 (en) 2011-11-30 2012-09-14 Storage device, computer-readable recording medium, and storage control method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2011263010A JP5879982B2 (ja) 2011-11-30 2011-11-30 ストレージ装置、ストレージ制御プログラムおよびストレージ制御方法

Publications (2)

Publication Number Publication Date
JP2013114623A JP2013114623A (ja) 2013-06-10
JP5879982B2 true JP5879982B2 (ja) 2016-03-08

Family

ID=48467880

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2011263010A Active JP5879982B2 (ja) 2011-11-30 2011-11-30 ストレージ装置、ストレージ制御プログラムおよびストレージ制御方法

Country Status (2)

Country Link
US (1) US9208114B2 (ja)
JP (1) JP5879982B2 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9667530B2 (en) * 2013-05-06 2017-05-30 International Business Machines Corporation Privacy preserving query method and system for use in federated coalition networks
GB2519119A (en) 2013-10-10 2015-04-15 Ibm Linear network coding in a dynamic distributed federated database
US10855580B2 (en) * 2019-03-27 2020-12-01 Amazon Technologies, Inc. Consistent route announcements among redundant controllers in global network access point

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2643356B2 (ja) * 1988-09-14 1997-08-20 株式会社日立製作所 分散システムにおけるトランザクション整合性保証制御方法
JPH0887436A (ja) * 1994-09-19 1996-04-02 Nec Corp 分散db処理方式
US5577240A (en) * 1994-12-07 1996-11-19 Xerox Corporation Identification of stable writes in weakly consistent replicated databases while providing access to all writes in such a database
JPH1084377A (ja) * 1996-09-09 1998-03-31 Oki Electric Ind Co Ltd 複数サーバの相互バックアップ方法及びルーチング方法
JP4160544B2 (ja) * 1998-01-20 2008-10-01 富士通株式会社 ドキュメント分散処理システムのサーバ管理方法およびサーバプログラムの記録媒体
US6510421B1 (en) * 1998-12-29 2003-01-21 Oracle Corporation Performing 2-phase commit with presumed prepare
JP4481053B2 (ja) * 2004-03-26 2010-06-16 シャープ株式会社 通信機器、通信機器の制御方法、通信機器の制御プログラム
US8799914B1 (en) * 2009-09-21 2014-08-05 Tilera Corporation Managing shared resource in an operating system by distributing reference to object and setting protection levels
JP2011076487A (ja) * 2009-09-30 2011-04-14 Oki Networks Co Ltd 計算機、及びデータベース管理プログラム
US8868855B2 (en) * 2011-02-28 2014-10-21 Hewlett-Packard Development Company, L.P. Request management system and method for dynamically managing prioritized requests
US9021146B2 (en) * 2011-08-30 2015-04-28 Apple Inc. High priority command queue for peripheral component

Also Published As

Publication number Publication date
US20130138893A1 (en) 2013-05-30
JP2013114623A (ja) 2013-06-10
US9208114B2 (en) 2015-12-08

Similar Documents

Publication Publication Date Title
US10645152B2 (en) Information processing apparatus and memory control method for managing connections with other information processing apparatuses
KR101080845B1 (ko) 교착 상태의 방지를 위한 데이터 처리 방법 및 시스템
US10754843B2 (en) Method and apparatus for information management
JP5879982B2 (ja) ストレージ装置、ストレージ制御プログラムおよびストレージ制御方法
US9830263B1 (en) Cache consistency
US20160034191A1 (en) Grid oriented distributed parallel computing platform
JP5754504B2 (ja) 管理装置、情報処理装置、情報処理システム及びデータ転送方法
JP6131907B2 (ja) 分散データベース、データ共有方法、プログラム、装置
JP6357807B2 (ja) タスク割当プログラム、タスク実行プログラム、マスタサーバ、スレーブサーバおよびタスク割当方法
JP5182162B2 (ja) 計算機システム及びi/o制御方法
JP5381109B2 (ja) 通信装置及びその制御プログラム
JP5783008B2 (ja) ストレージ装置、ストレージシステム、データ更新方法およびデータ管理プログラム
JP6046523B2 (ja) インメモリ型分散データベース、データ分散方法及びプログラム
US9594651B2 (en) Parallel computer system and control method for parallel computer system
US10749957B2 (en) Method and apparatus for information management
US8380938B2 (en) Providing shared access to data storage resources across cluster computing environment boundaries
US10855610B2 (en) Information processing apparatus, information processing system, information processing method, and storage medium
JP5354007B2 (ja) 分散処理システム、インタフェース、記憶装置、分散処理方法、分散処理プログラム
KR102476933B1 (ko) 인터커넥트 및 인터커넥트의 작동방법
US20180131785A1 (en) Reducing response times to gateway-connected devices
JP7358878B2 (ja) データ転送システム、データ転送方法、及び、データ転送プログラム
JP4671059B2 (ja) マルチノードネットワークシステム
JP5965160B2 (ja) データ同期システム、運用系コンピュータ、及び待機系コンピュータ
JP6658299B2 (ja) 情報処理装置及び情報処理装置の制御方法
JP2006012112A (ja) 共有相互接続パーティションの動的パーティション・マネジメントの方法及びシステム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20140805

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20150430

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20150519

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20150717

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20160105

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20160118

R150 Certificate of patent or registration of utility model

Ref document number: 5879982

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150