JP6677052B2 - 通信管理装置、通信管理方法及びプログラム - Google Patents

通信管理装置、通信管理方法及びプログラム Download PDF

Info

Publication number
JP6677052B2
JP6677052B2 JP2016073184A JP2016073184A JP6677052B2 JP 6677052 B2 JP6677052 B2 JP 6677052B2 JP 2016073184 A JP2016073184 A JP 2016073184A JP 2016073184 A JP2016073184 A JP 2016073184A JP 6677052 B2 JP6677052 B2 JP 6677052B2
Authority
JP
Japan
Prior art keywords
storage nodes
communication
relationship
identifier
storage
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
JP2016073184A
Other languages
English (en)
Other versions
JP2017184195A (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.)
NEC Corp
Original Assignee
NEC Corp
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 NEC Corp filed Critical NEC Corp
Priority to JP2016073184A priority Critical patent/JP6677052B2/ja
Publication of JP2017184195A publication Critical patent/JP2017184195A/ja
Application granted granted Critical
Publication of JP6677052B2 publication Critical patent/JP6677052B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Description

本開示は、ネットワークを管理する技術に関する。
分散ファイルシステム（以後、「分散ＦＳ」（Ｆｉｌｅ Ｓｙｓｔｅｍ）と表記）や分散型オブジェクトストレージでは、ノード管理を行う必要がある。そのノード管理の方法として、（１）メタデータサーバを用いた中央集権的な管理手法、または、（２）システムに所属するノードそれぞれが算出アルゴリズムないし管理テーブルをもち、通信先を解決する管理手法が用いられてきた。
特許文献１乃至９には、ＯｐｅｎＦｌｏｗ（登録商標）に代表されるＳＤＮ（Ｓｏｆｔｗａｒｅ−Ｄｅｆｉｎｅｄ Ｎｅｔｗｏｒｋ）及びパケットの転送に関連する技術が開示されている。
特開２０１５−１５４２１０号公報 特開２０１５−０９５７３０号公報 特開２０１０−１０９７９１号公報 特表２０１５−５３７７５４号公報 特開２００３−１５３２３９号公報 欧州特許出願公開第２７３１３０４号明細書 欧州特許出願公開第２７８２３１２号明細書 米国特許出願公開第２０１４／０２２９９４５号明細書 米国特許出願公開第２０１４／０２６９２８８号明細書
（１）の中央集権的な管理を行っている場合、管理を行う制御サーバに障害が発生すると、その障害の影響が全体に波及する問題がある。そのため、制御サーバを冗長化するなど対策を講じなければならない。また制御サーバへアクセスが集中し過ぎるので、制御サーバの性能がネックになることよって、分散ＦＳ又は分散オブジェクトストレージ全体で性能が出なくなるといった問題点もある。
（２）の分散管理型の手法では、システムに参加するノードがそれぞれのノードを把握しなければならない。この方法は、あるノードがダウンしても、残っているノードは動作を継続でき、システムとしては運用が継続できるメリットがある。しかし、参加ノードとオブジェクトの担当の把握を、それぞれのノードが行わなければならないので、ノード管理の負担が大きい。また、ノードの追加など、システムに参加するノードに変更が加わった場合に、管理情報が全体に伝わりきるまで時間がかかるという欠点が存在する。
本発明の目的の１つは、分散型ストレージにおける管理負荷を軽減しながら高速で柔軟な経路の切り替えをできる管理技術を提供することにある。
本発明の一態様に係る通信管理装置は、複数の実ストレージノードのいずれかにオブジェクトを送信する経路における複数の通信機器の、前記オブジェクトに一意に付与される識別子に基づいて前記オブジェクトの転送先を決定する第１のルールを含む設定を、前記識別子を前記複数の実ストレージノードのいずれかに割り当てる第１の割り当て関係と、前記複数の通信機器及び前記複数の実ストレージノードの接続関係とに基づいて生成する生成手段と、前記通信機器に前記設定を適用する適用手段と、を備える。
本発明の一態様に係る通信管理方法は、複数の実ストレージノードのいずれかにオブジェクトを送信する経路における複数の通信機器の、前記オブジェクトに一意に付与される識別子に基づいて前記オブジェクトの転送先を決定する第１のルールを含む設定を、前記識別子を前記複数の実ストレージノードのいずれかに割り当てる第１の割り当て関係と、前記複数の通信機器及び前記複数の実ストレージノードの接続関係とに基づいて生成し、前記通信機器に前記設定を適用する。
本発明の一態様に係るプログラムは、コンピュータに、複数の実ストレージノードのいずれかにオブジェクトを送信する経路における複数の通信機器の、前記オブジェクトに一意に付与される識別子に基づいて前記オブジェクトの転送先を決定する第１のルールを含む設定を、前記識別子を前記複数の実ストレージノードのいずれかに割り当てる第１の割り当て関係と、前記複数の通信機器及び前記複数の実ストレージノードの接続関係とに基づいて生成する生成処理と、前記通信機器に前記設定を適用する適用処理と、を実行させる。
本発明によると、分散型ストレージにおける管理負荷を軽減しながら高速で柔軟な経路の切り替えをできるという効果がある。
図１は、本発明の第１の実施形態に係る分散ストレージシステムの構成を表す図である。 図２は、本発明の第１の実施形態に係るOpenFlowネットワークを模式的に表す図である。 図３は、OpenFlowスイッチの構成を模式的に表す図である。 。図４は、Flow Tableの構造を模式的に表す図である。 図５は、ネットワークパケットの構造の概要を表す図である。 図６は、本発明の第１の実施形態に係るハッシュ空間の分割の例を表す図である。 図７は、Group Table の構造を模式的に表す図である。 図８は、本発明の第１の実施形態に係るシステムの全体的な動作を表すフローチャートである。 図９は、本発明の第１の実施形態に係るシステムの、オブジェクトストレージ用のオーバレイネットワークの設計及び構築の動作を表すフローチャートである。 図１０は、本発明の第１の実施形態に係るFlow Tableの例を示す図である。 図１１は、本発明の第１の実施形態に係るFlow Tableの例を示す図である。 図１２は、本発明の第１の実施形態に係るFlow Tableの例を示す図である。 図１３は、本発明の第１の実施形態に係るOpenFlowスイッチの、パケットが到着した際の動作の例を表すフローチャートである。 図１４は、本発明の第１の実施形態に係るクライアントの全体的な動作の例を表すフローチャートである。 図１５は、本発明の第１の実施形態に係るオブジェクトストレージノードの動作の例を表すフローチャートである。 図１６は、本発明の第１の実施形態に係るシステムの、データのやり取りを行う動作の例を表すシーケンス図である。 図１７は、フラグメントが発生するデータを模式的に表す図である。 図１８は、本実施形態に係るシステムの、接続リクエストを使用する動作の例を表すシーケンス図である。 図１９は、本発明の第１の実施形態に係るシステムの、解決策が適用された動作の例を表すシーケンス図である。 図２０は、本発明の第１の実施形態のシステムに係る、フォーマットを変換する機能がライブラリに組み込まれている構成の例を表す図である。 図２１は、本実施形態に係るシステムの、通信モジュールに通信の解説を要求する動作の例を表すシーケンス図である。 図２２は、実施形態に係る通信モジュールを使ったオブジェクトストレージの通信の例を表すシーケンス図である。 図２３は、本発明の第２の実施形態に係るストレージシステムの構成を表すブロック図である。 図２４は、本発明の第２の実施形態に係る通信機器の構成の例を表すブロック図である。 図２５は、本発明の第２の実施形態に係る通信管理装置の動作の例を表すフローチャートである。 図２６は、本発明の第２の実施形態に係る通信機器の動作の例を表すフローチャートである。 図２７は、本発明の第３の実施形態に係る通信管理装置の構成の例を表すブロック図である。 図２８は、本発明の第３の実施形態に係る通信管理装置の動作の例を表すフローチャートである。 図２９は、本発明の各実施形態に係る装置を実現することができる、コンピュータ１０００のハードウェア構成の一例を表す図である。
次に、発明の実施形態について、図面を参照して詳細に説明する。
＜＜第１の実施形態＞＞
最初に、本実施形態の特徴について、簡単に説明する。
本発明では、ノード管理機能をストレージシステム側からネットワーク側へ移譲した新たなシステムを構築する。
本実施形態では、ストレージネットワーク用のオーバレイネットワークを構築し、利用する。本実施形態では、実現にあたり、OpenFlowを利用するだけでなく拡張する。そして、本実施形態は、例えば以下に示す特徴を備える。
１．OpenFlowコントローラ又はOpenFlowコントローラの協調サーバが分散ストレージの配置情報を管理する機能を有し、分散型オブジェクトストレージのリソース分担を適切に管理する。以下で説明する図１及び以下の説明では、分散ストレージの配置情報を管理する機能を、「分散ストレージ配置情報管理機能」とも表記する。
２．分散ストレージの配置情報を管理する機能とOpenFlowコントローラが連携し、分散ストレージ用のオーバレイネットワークをOpenFlowネットワーク上に構築する。
３．構築したオーバレイネットワークでは、オブジェクト(リソース)と結びつけられたハッシュ値（リソース識別子）などを手掛かりとして、OpenFlowスイッチが適切なストレージノードへリクエストを配送する。
次に、本実施形態を実現する技術の概要について説明する。
リソースをストレージの代表アドレスへ送信すると、ネットワークがそのリソースの担当ノードへそのオブジェクトを配送するように、分散ストレージ用のオーバレイネットワークを構築し、構築したオーバレイネットワークを使用する。これによりストレージのクライアントは、リソースの担当ノードを直接把握せずとも、分散ストレージを利用できるようになる。
分散ストレージ用のオーバレイネットワークを構築するのに、OpenFlowを利用する。OpenFlowはオーバレイネットワークを構築することができるが、現行仕様のままではオブジェクトストレージ用のネットワークが構築できない。構築にあたって、例えば以下の少なくともいずれかの解決を行う。
（１）オブジェクトストレージで使用するリソース識別子とリクエストを扱えるようOpenFlow仕様を拡張する。
（２）送信用モジュールにより、リソース識別子やリクエストなどの必要情報をOpenFlowが扱えるプロトコルヘッダ領域へマッピングし、OpenFlowを流用できるようにする。
分散ストレージの各ノードがどのリソース（オブジェクトストレージにとってはオブジェクトに相当）を担当するかを管理できるようにするために、分散ストレージの配置情報を管理する機能を用意する。分散ストレージの配置情報を管理する機能は、限られたメモリを使うOpenFlowスイッチでもリソースを扱えるようにする。また、分散ストレージの配置情報を管理する機能は、OpenFlowコントローラと連携し、OpenFlowスイッチのFlow Tableを設定することで、分散ストレージ用のオーバレイネットワーク構築に利用される。
＜構成＞
次に、本実施形態の構成について説明する。
本実施形態では、分散型オブジェクトストレージのオーバレイネットワークを構築することによって、ノード管理をネットワーク側において実現する。クライアント、及び、オブジェクトストレージの構成ノードは、オブジェクトストレージ用の機能モジュールに、以下で説明するやりとりを行うための通信機能を追加で備える。
まずオブジェクトストレージについて簡潔に説明する。
オブジェクトストレージは、オブジェクトと呼ぶ一連のデータを、そのオブジェクトに関連付けたオブジェクト識別子を使用してアクセスするストレージ装置である。オブジェクト識別子として、一般的に、なんらかのハッシュ値が用いられることが多い。データの格納に際し、階層構造を持たないフラットな配置が採用されることが多いが、格納方法は厳密には定められていない。
オブジェクトストレージとのデータのやり取りに、CRUD (Create, Read, Update, Delete) I/F (Interface)ではなく、REST (Representational State Transfer) I/Fと呼ぶインタフェース仕様を用いることがある。以下の説明では、REST I/F を「Rest I/F」とも表記する。REST I/Fは、目的のリソースを指定するリソース識別子、及び、リソースに対する操作を表すリクエストの、２つの属性を使用する。オブジェクトストレージは、リソースをオブジェクト（一連のデータ）に、リソース識別子をオブジェクト識別子に置き換えることによって、容易にREST I/Fとして利用できるようになる。
リソースに対するリクエストを説明する。リクエストには、GET、HEAD、POST、PUT、及び、DELETE が存在する。これらのリクエストは、主に次の意味で使用される。
GET ： 指定されたリソース識別子のリソースを取り出す。
HEAD ： 指定されたリソース識別子のメタリソースを取り出す。
POST ： 指定したリソース識別子にリソースを新規作成する。
PUT ： 指定したリソース識別子にリソースを更新する。
DELETE ： 指定したリソース識別子のリソースを削除する。
本実施形態では、リクエストにリクエストID（Ｉｄｅｎｔｉｆｉｅｒ）と呼ぶ識別番号を割り当てる。例えば、上述のリクエストに割り当てるリクエストIDを、GETから順に1, 2, … とする。数値に割り当てるのは、情報量を削減し、パケット上の記述位置を固定するためである。しかし、要はリクエストを識別できればよいので、リクエストIDとして、文字列などの別の表現を使ってもよい。
上記リクエストは、HEAD、及び、POSTを除き、CRUD (Create, Read, Update, Delete) にほぼ対応している。そのため、インタフェース仕様をRest I/Fによって実現可能であれば、Rest I/Fの代わりにリソース識別子とCRUDを基にしたリクエストを代替に使ったI/Fも容易に実現可能である。
本実施形態では、オブジェクトの最大サイズを1460（本実施形態で使用するヘッダ長）以下とする (関連1)。この制限は、オブジェクトのサイズを通信に使うEthernet（登録商標）の標準MTU（Maximum Transmission Unit）サイズ(1500)以下にするためである。サイズの拡張方法に際しては＜＜関連技術＞＞において説明する。
またオブジェクトストレージのサーバやクライアントが持つオブジェクトストレージ用プログラムが、本実施形態で使用するネットワークプロトコルにのっとり、データを用意する例となっている。通信フォーマットへの変換をオブジェクトストレージ用のプログラムではなく、外部ライブラリやOS（Operating System）として提供する方法に関しては、＜＜関連技術＞＞に記載する(関連2)。
本実施形態について、図１、図２を用いて説明する。図１は、本実施形態の分散ストレージシステムの構成を表す図である。図２は、本実施形態のOpenFlowネットワークを模式的に表す図である。図２は図１のOpenFlowネットワーク部分（図1、101）をより具体的にしたものである。
本実施形態で取り扱うネットワークは、単なるEthernet機器ではなくOpenFlow対応機器を用いたネットワークで構成している。OpenFlowと対比するものとして単なるEthernetをレガシーネットワークと称することもある。
OpenFlowネットワークは、1つ又は複数のOpenFlowコントローラと呼ばれるネットワークの制御コントローラと、1つ以上のOpenFlowスイッチで構成する。OpenFlowスイッチは、datapath IDと呼ぶ識別子で区別される。本実施形態では、分かりやすさを優先し、OpenFlowスイッチの識別子を、数値の代わりにOFS1, OFS2, … と表記することがある。
OpenFlowコントローラとOpenFlowスイッチは、Ethernetのネットワークで接続した制御用ネットワークで結ばれ、OpenFlowプロトコルを用いて制御通信を行う。
OpenFlowスイッチ間の接続で構成したネットワークは、PC（Personal Computer）などの機器の通信に使用される。ここでは、そのようなネットワークを、OpenFlowネットワークと称する。
図１、図２で示されるネットワーク構成では、1つのOpenFlowコントローラ（図1、103）と3つのOpenFlowスイッチ(図2、201〜203)が使用される。本実施形態の説明では、OpenFlowコントローラをOFCと、OpenFlowスイッチをOFSと略記する。特にOFCに関する説明の必要がない場合、以後の図中でも簡単のためOFCを省略する。
本実施形態では、OpenFlowコントローラに分散ストレージ配置情報管理手段（図1、104） と呼ぶストレージ用のオーバレイネットワークを構築するための機能を搭載する。分散ストレージ配置情報管理手段は、OpenFlowコントローラと協調するサーバに搭載される形態でもよい。(分散ストレージ配置情報管理手段の具体的な機能については後述する。)
Client (図１、106) はオブジェクトストレージのクライアントである装置である。通常、クライアントは、パーソナルコンピュータなどの通信機能を備える機器である。本実施形態では、クライアントは、加えて、オブジェクトストレージを使用するための機能を備える。
OFSには、オブジェクトストレージを構成するコンピュータ (オブジェクトストレージノード) (図1、105) が接続される。
OFSには、オブジェクトストレージノード以外にも、別途、パーソナルコンピュータやサーバ(図1、107) が接続されてもよい。そして、OFSに接続されている装置は、それぞれの通信にOFSを使用していてもよい。つまり、OFSを介して、オブジェクトストレージ以外の通信が行われていてもよい。
図２では、OFS間の接続を明示したい部分にポート番号が記載されている。具体的には、OSF間の接続関係は以下の通りである。
OFS1 のポート1 と OFS2 のポート0 とがケーブル接続され、
OFS1 のポート2 と OFS3 のポート0 とがケーブル接続される。
また、OSFとオブジェクトストレージノードとの接続関係は以下の通りである。
OFS2 のポート1 と オブジェクトストレージノード1 とがケーブル接続され、
OFS2 のポート2 と オブジェクトストレージノード2 とがケーブル接続される。
OFS3 のポート1 と オブジェクトストレージノード3 とがケーブル接続され、
OFS3 のポート2 と オブジェクトストレージノード4 とがケーブル接続される。
OpenFlowスイッチの内部構成を図３に示す。図３は、OpenFlowスイッチの構成を模式的に表す図である。現在の規約上、OpenFlowスイッチは、OpenFlowコントローラと通信するための通信手段(Secure Channel)と、ある種のActionリストを格納するGroup Tableと、0番から始まる複数のFlow Tableとを備える。Group Table及び各Flow Tableは、例えば、メモリなどの記憶装置に格納されていてもよい。
Flow Tableを、図４を用いて説明する。図４は、Flow Tableの構造を模式的に表す図である。各Flow Tableは、1エントリにMatch Fieldsと、Countersと、Instructionsとを構成にもつ複数のフローエントリで構成される。なお、Flow Tableの構成要素は、OpenFlowのバージョンにより異なることがある。
Match Fieldsは、このエントリに該当するパケットの条件を保持する。Match FieldはANYという全ての値に該当する特殊な値のほか、Ethernet、及び、TCP/IP（Transmission Control Protocol/Internet Protocol）のヘッダ情報などを指定できる。参考にOpenFlow version 1.1で指定できるものを以下に記す。
1. パケットの入力ポート(Ingress Port)、
2. 統計情報などのメタ情報(Metadata)、
3. Ether source MAC address、
4. Ether destination MAC address、
5. Ether type、
6. VLAN ID、
7. VLAN priority、
8. MPLS label、
9. MPLS traffic class、
10. IPv4 source address、
11. IPv4 destination address、
12. IPv4 proto/ARP opcode、
13. IPv4 ToS bits、
14. TCP/UDP/SCTP source portまたはICMP type、
15. TCP/UDP/SCTP destination portまたはICMP code
これらの属性によって指定されるトラフィックは、フローと呼ばれる。本実施形態では、OpenFlowの仕様にある属性の他に、オブジェクトストレージ用の属性 (リソース識別子、及び、リクエスト) をフローで指定できるようにする。(必要によっては、リクエスト番号などの他の属性が、さらに追加されていてもよい。)
ネットワークパケットは、宛先や送信元などの情報を含むプロトコルヘッダと、データを格納するペイロードで構成される。これを図で表すと、図５のようになる。図５は、ネットワークパケットの構造の概要を表す図である。本実施形態のオブジェクトストレージのやりとりでは、ペイロードの先頭にリクエストとリソース識別子とをおき、プロトコルヘッダの延長として扱えるようにする。(関連1 フラグメントへの対応で拡張する方向もあり)。なお、本実施形態では、フラグメントが発生しないよう、プロトコルヘッダとUDP（User Datagram Protocol）データグラムのサイズがMTU値を超えないものとする。Ethernetでの標準サイズは1500バイトで、IP、UDPヘッダサイズをそこから減じると1460バイトである。そのため、本実施形態では、オブジェクトの最大サイズを1460（本実施形態で使用するヘッダサイズ）以内とした。
Countersには、このCountersのエントリに該当した場合に更新される統計情報が格納される。
Instructionsは、処理命令を保持する。Instructionsには、Match Fieldsに該当するパケットに対して処理を行うactionが登録される。
Rest I/F用のフローの実現方法についてより詳しく説明する。
本実施形態で扱うリソース識別子は、SHA-1（Secure Hash Algorithm 1）で得られるハッシュ値であるとする。しかしながら、リソースを適切に表すことができるならば、リソース識別子は、別の方式で得られた値でも構わない。方式の選択にあたっては、ハッシュ値が固定長となる方がOpenFlowスイッチ上の動作性能面で望ましい。
SHA-1で得られるハッシュ値は、0から“(2の160乗)-1”の範囲をとる。OpenFlowへ適用するにあたり、一つのハッシュ値を単純に一フローエントリに対応付けると、Flow Tableへ割り当てなければならないメモリが多くなってしまう。またフローエントリ数が多くなるとフローの確認回数が多くなり、OpenFlowスイッチの処理性能へ影響してしまう。この２つの問題のため本実施形態では次のような工夫を行う。
本実施形態に係るシステムで扱えるオブジェクトストレージの最大ノード数をnとする。
最初にハッシュ空間をn個に分割する。ハッシュ空間の分割例として、ハッシュ値を2のべき乗で割ることとする。例えば16 (= 2^4) 分割であれば、ハッシュ空間の分割は、図６のようになる。図６は、ハッシュ空間の分割の例を表す図である。これにより、ハッシュ値が含まれる領域を、ハッシュ値を2進数で表した値の先頭ビット(16分割では4bit) だけを見ることによって判別できる、簡易な判別方法が実現できる。
次に、分割したハッシュ空間の担当を、例えば以下のように、仮想的なオブジェクトストレージ（すなわち、仮想オブジェクトストレージ）に関連付ける。
ハッシュ空間領域0 ： 仮想オブジェクトストレージ0、
ハッシュ空間領域1 ： 仮想オブジェクトストレージ1、
……
仮想オブジェクトストレージは、Flow Table上に枠を事前に確保しておく意味を持つ。
最後に、仮想オブジェクトストレージと、実際に存在するオブジェクトストレージとの間の関連付けを行う。ここまでで説明した関連付けは、OpenFlowコントローラ、又は、コントローラと協調するサーバに搭載された分散ストレージ配置情報管理手段によって行われる。分散ストレージ配置情報管理手段は、ノードの追加及び削除などのタイミングで、適切に対応付けを行うことによって、適切に維持管理を行う。本実施形態のオブジェクトストレージの構成ノードを4つとしたとき、割り当てをConsistent Hashing法に基づいて以下のようにする。
仮想オブジェクトストレージ0〜3 ： Object Storage 1
仮想オブジェクトストレージ4〜7 ： Object Storage 2
仮想オブジェクトストレージ8〜11 ： Object Storage 3
仮想オブジェクトストレージ12〜15 ： Object Storage 4
Object Storage 1からObject Storage 4は、上述のオブジェクトストレージノードである。以下、オブジェクトストレージノードは、「実ノード」とも表記される。実ノードを確定すると、スイッチが転送すべきポートが判明するので、Flow Tableへ記述できようになる。なお実ノードが存在しない場合、パケットをドロップさせる。
このように、一旦仮想ノード（すなわち、仮想オブジェクトストレージ。以下、仮想ストレージノードとも表記される。）として枠を設けておくと、実際のオブジェクトストレージノードが増減してもFlow Tableのフローエントリ数は変化しない。そのため、OpenFlowスイッチの処理性能へのインパクトを防止できる。
なおOpenFlowの仕様v1.1までは、フローのマッチ条件としてIPアドレスのマスク部分しか範囲の指定ができなかった。しかし、v1.2では、範囲で指定できる対象が拡張された。本実施形態でも、リソース識別子(ハッシュ値) のマッチ条件は、範囲で指定できるように拡張される。すなわち、リソース識別子の先頭数bitの値をフローのマッチ条件として扱えるようにし、リソースID空間の分割数の増減に備える。
以上により、本実施形態では、リソースID先頭の4bitの値によって、担当するオブジェクトストレージが決定できるようになるので、Storage Overlay Networkの記述をFlow Tableの形へ実装できる。
Group Tableを、図７を用いて説明する。図７は、Group Table の構造を模式的に表す図である。Group Tableは、1エントリにGroup Identifierと、Group Typeと、Countersと、Action Bucketsとを持つ、複数のグループエントリで構成される。Group Tableを使用することによって、プロトコルフィールドを書き換えて転送するなどの動作が実現できる。
Group Identifierは、符号なし32bitの整数であり、グループエントリを識別する一意な識別子である。
Group Typeは、このグループエントリの意味を表し、Action Bucketsの使い方を表す。OpenFlow v1.1の仕様ではGroup Type として、all、select、indirect、fast failoverの4つがある。
値がallの場合、Action Bucketsに登録したaction bucketの全てを実行する。それぞれのaction bucketの実行に際して、パケットは効率的にコピーされて渡される。
値がselectの場合、Action Bucketsに登録したaction bucketのどれかを実行する。
Countersは、このグループエントリが処理したパケットの統計情報を格納する。
Action Bucketsは、action bucketのリストである。それぞれのaction bucketは実行やパラメータ変更などを行うactionのリストを格納する。
OpenFlowコントローラは、セキュリティを確保した通信経路を通してOpenFlowスイッチのFlow Tableなどを設定する。OpenFlowスイッチに入力されたパケットに対して、OpenFlowスイッチは、設定されたFlow Tableに従って、転送や破棄などの処理を行う。
具体的には、OpenFlowスイッチは、パケットを受け取るとFlow Tableを使ったパイプライン処理を実施する。パイプライン処理は、Flow Tableの0番のテーブルから始まり、GoTo命令がないTableの最後のフローエントリまで実施されたら終了する。Goto命令は指定した別のFlow Tableへ処理を移すことができるが、Flow Tableの後戻りはできない。つまり常にテーブル番号を大きくしていく方向にのみGoto命令は使用できる。
＜動作の説明＞
次に、本実施形態に係るシステムの全体的な動作について、図８を用いて説明する。図８は、本実施形態に係るシステムの全体的な動作を表すフローチャートである。
最初に、システムは、通常のOpenFlow技術を用いてベースとなるOpenFlowネットワークを構築する (ステップS0101)。
次に、システムは、オブジェクトストレージ用のオーバレイネットワークの設計と構築とを行う (ステップS0102)。具体的な内容は後述する。
ネットワークの設計と構築とを終えると、オブジェクトストレージを構成するノードはストレージのサービスを開始する (ステップS0103)。オブジェクトストレージのクライアントとオブジェクトストレージのやりとりが行われるようになる。
オブジェクトストレージ用のオーバレイネットワークの設計及び構築(ステップS0102) を、図９を用いてより詳細に説明する。図９は、オブジェクトストレージ用のオーバレイネットワークの設計及び構築の動作を表すフローチャートである。オーバレイネットワークの実現方法により事前に把握しておく必要がある情報は異なる。本実施形態では、ネットワーク設計者は、この時点までに、オブジェクトストレージが使用するIPアドレス(代表オブジェクトストレージアドレス)や、接続するオブジェクトストレージノードが接続されているOFS及び接続しているポートを把握している必要がある。
最初に、OpenFlowコントローラ又は協調サーバの分割ストレージ配置情報管理手段（以下、「管理部」とも表記）は、オブジェクトストレージがリソース識別子として取り扱うハッシュ空間の分割を行う (ステップS0201)。管理部は、ハッシュ空間を分割したら、分割したそれぞれの空間を担当する仮想オブジェクトストレージを決定する。具体的な方法はリソース識別子の説明箇所に記載している。
次に、管理部は、REST I/Fを使った場合の実際の配送先を決定する (ステップS0202)。上の関連付けに続いて、管理部は、仮想オブジェクトストレージノードと実ストレージノードの関連付けを行う。実ストレージノードを決定すると、OFSにとって送信すべき物理ポート番号を具体的に決定できる。つまりパケットを転送すべきポートが分かる。このようにしてオブジェクトストレージ用のフローエントリが作成できるようになる(ステップS0203)。
ネットワーク全体の配送ルートが指定できるようになったので、OpenFlowコントローラは、設計したネットワークになるようネットワーク上に存在するOpenFlowスイッチのFlow Tableを設定する。本実施形態では、OFS1のFlow Tableは図１０に示すようなFlow Tableになり、OFS2のFlow Tableは図１１に示すようなFlow Tableになり、OFS3のFlow Tableは図１２に示すようなFlow Tableになる。図１０、図１１及び図１２は、Flow Tableの例を示す図である。
最初に実行されるFlow Table0には、オブジェクトストレージ用のやりとりかそうでないかを判断するフローエントリを記載する。具体的には、パケットの宛先IPアドレスが特定のIPアドレスに該当する場合、本実施形態のOpenFlowスイッチは、受信したパケットによる通信がオブジェクトストレージ用の通信と解釈する。この特定のIPアドレスは、上述の代表オブジェクトストレージアドレス（以下、「代表アドレス」とも表記）である。そして、本実施形態のOpenFlowスイッチは、オブジェクトストレージ用のフロー処理を記載したFlow Table1へ処理を進める。
パケットの宛先IPアドレスが代表オブジェクトストレージアドレスでなかった場合は、その宛先IPアドレスはANYのフローエントリにマッチする。そのため、本実施形態のOpenFlowスイッチは、Flow Table2へ処理を進める。管理部は、Flow Table2には、OpenFlowネットワーク用エントリを設定する。Flow Table2へ処理を進めたOpenFlowスイッチは、(オブジェクトストレージ以外の)通常の通信を処理する。このように処理の始めに代表アドレスで振り分ける処理にすることで、別のオブジェクトストレージ用のオーバレイネットワークを構築する際でも、ANYの前に同様の手法で作成するオブジェクトストレージ用のフローを差し込めばよく、容易に拡張可能になっている。
宛先IPアドレスが代表オブジェクトストレージアドレスである場合の処理を記載したFlow Table1について説明する。Flow Table1では、Match Fieldsにリソース識別子を指定するフローが設定され、その条件に該当したパケットを適切なポートへ送信するactionがInstructionsに設定される。すなわち、Flow Table1には、リソース識別子を担当するノードへ送付するフローエントリが記述される。
オブジェクトストレージノードが直結されたOpenFlowスイッチ(OFS2及びOSF3)では、直結されたポートが送信ポートになる (図１１：上2つのフローエントリ、図１２：下2つのフローエントリ)。それ以外のエントリでは、リソース識別子を担当するノードが接続されているOpenFlowスイッチへ適切に転送されるポートが指定される。
OFCは、最終的に設計したフローテーブルを、ネットワーク上のOFSへ配布する (ステップS0204)。フローテーブルを配布することにより、設計されたOpenFlowネットワークが動作を開始する。
パケットが到着した際のOpenFlowスイッチの動作を、図１３を用いて説明する。図１３は、OpenFlowスイッチの、パケットが到着した際の動作の例を表すフローチャートである。
OpenFlowスイッチは、パケットが到着すると、到着したパケットをFlow Tableに従って処理する。Flow Tableは、前述したとおり、基本的にはOFSが動作する前にOFCにより設定される。
OpenFlowスイッチは、まずFlow Table0から順に処理する。OpenFlowスイッチは、宛先IPアドレスが代表オブジェクトストレージアドレスにマッチするかを条件にしたフローエントリにより、オブジェクトストレージ用のパケットなのかをチェックする (ステップS0301)。パケットの宛先IPアドレスが代表オブジェクトストレージアドレスに該当した場合（ステップS0301においてＹｅｓ）、OpenFlowスイッチは、Flow Table1へ処理を移動する (ステップS0302)。
Flow Table1には、リソース識別子をチェックするフローが記載されている。本実施形態における動作拡張により、OpenFlowスイッチは、ペイロードの先頭にあるリソース識別子を読出する。OpenFlowスイッチは、リソース識別子がフローエントリのMatch Fieldsに該当するか確認する。OpenFlowスイッチは、リソース識別子がフローエントリのMatch Fieldsに該当する場合フローエントリのInstructionsに設定されたoutput actionにしたがって、所定のポートへパケットを送信する。
ステップS0301において、リソース識別子がフローエントリのMatch Fieldsにマッチしない場合（ステップS0301においてＮｏ）、OpenFlowスイッチは、パケットを通常パケットとして処理する (S0303)。これは、OpenFlowスイッチが、Flow Table0 のANYのフローにより、通常のOpenFlow処理用エントリを格納したFlow Table2へ処理を進めることで実現される。
オブジェクトストレージを利用するクライアントについて説明する。図１４は、クライアントの全体的な動作の例を表すフローチャートである。
クライアントは、オブジェクトストレージとのデータのやりとりをRest I/Fを通して行う。クライアントは、本ネットワーク用のフォーマットでやりとりする機能を有する。
クライアントは、オブジェクトストレージと通信を行うため、準備段階でUDPソケット(通信端)を作成する(ステップS0401)。
UDPソケットは、送信毎に宛先アドレスを指定できる。オブジェクトストレージとの通信では、クライアントは、代表オブジェクトストレージアドレスを送信先IPアドレスに指定する。クライアントは、リクエストID及びリソース識別子を格納した本ネットワークのフォーマットに従ったデータを送信要求する(ステップS0402)。
クライアントは、オブジェクトストレージを使用しなくなった場合は、作成していたUDPソケットを終了するのに加えて、オブジェクトストレージ用の機能も終了させる (ステップS0403)。
オブジェクトストレージノードの動作の説明を、図１５を用いて説明する。図１５は、オブジェクトストレージノードの動作の例を表すフローチャートである。
オブジェクトストレージを構成するノード（すなわち、オブジェクトストレージノード）は、サービスの準備の段階（ステップS0501）で、待ち受け用のソケットを作成する。このソケットはクライアントとの通信で利用する。
オブジェクトストレージノードは、オブジェクトストレージサービスの提供準備が終了すると、待ち受けソケットを使ったデータサービスの提供を開始する (ステップS0502)。
オブジェクトストレージノードは、サービスの提供を終えるには、待ち受けソケットを終了する。オブジェクトストレージノードは、さらに、サービス提供で用いていた機能を順次終了する (ステップS0503)。
本実施形態に係るネットワークを介して、クライアントがRest I/Fを使ってオブジェクトストレージとデータ（すなわち、本実施形態ではリソース）のやりとりする動作を、図１６を使って説明する。図１６は、本実施形態に係るシステムの、データのやり取りを行う動作の例を表すシーケンス図である。
なお、操作対象のリソースには、生成されたリソース識別子が付与されている(既存技術)。リソース識別子は、リソースが持つデータのハッシュ値を算出することによって生成されてもよく、リソースを格納するパス名を基に生成されてもよい。
本実施形態では、リソースに対する操作を表すリクエストに、上述の、数値を使用したリクエストIDという識別子が使用される。
これまでに上述したように、クライアントは、送信データ(例えば、ペイロードの部分) を次のように作成する。クライアントは、ペイロードの部分に、リクエストID、リソース識別子を順番に先頭から格納する。クライアントは、ペイロードの部分に、リクエストによっては後で必要なデータを含めてもよい。以下の説明では、リクエストIDの後の括弧内の数字は、本実施形態において、それぞれの動作にリクエストIDとして付与されている数値である。
例えばGET動作の場合、クライアントは、GETのリクエストID (1)、及び、リソース識別子を送信データとして送信要求を行う。
HEAD動作の場合、クライアントは、HEADのリクエストID (2)、及び、リソース識別子を送信データとして送信要求を行う。
POST動作の場合、クライアントは、POSTのリクエストID (3)、及び、リソース識別子に続き、オブジェクトストレージへ保存するデータを加えたものを送信データとして送信要求を行う。
PUT動作の場合、クライアントは、PUTのリクエストID (4)、及び、リソース識別子に続き、オブジェクトストレージへ保存するデータを加えたものを送信データとして送信要求を行う。
DELETE動作の場合、クライアントは、DELETEのリクエストID (5)、及び、リソース識別子をデータとして送信要求を行う。
OFS1及びOFS2は、パケットの宛先IPアドレスが代表オブジェクトストレージアドレスであるか確認したのち、リソース識別子の転送先にしたがってパケットを転送する。最終的に、担当ノードがパケットを受け取る。ここでは、オブジェクトストレージ1がリクエストを受け取ったとする。
パケットを受け取ったオブジェクトストレージノードは、リクエストIDとリソース識別子に基づいて、リクエストを処理する。本実施形態に係るネットワークに特有のデータフォーマットを取り扱う技術以外の、Rest I/Fの実行部分の技術は、通常の技術と同じでよい。
以下に、動作の一例を示す。以下の説明でも、括弧内の数値はリクエストIDとして設定されている数値を表す。以下では、例えば、「リクエストIDがGET(1)である場合」は、「リクエストIDが1であり、リクエストIDが示す動作の種類がGETである」ことを表す。
リクエストIDがGET(1)である場合、オブジェクトストレージ1は、リソース識別子で指定されたリソースのデータを記憶装置から取り出し、クライアントへそのデータを送信する。
リクエストIDがHEAD(2) である場合、オブジェクトストレージ1は、リソース識別子で指定されたリソースのメタ情報を記憶装置ないしファイルシステムから取り出し、クライアントへ取り出したデータを送信する。
リクエストIDがPOST(3) である場合、オブジェクトストレージ1は、リソース識別子で指定されたリソースとして同時に渡されたデータをオブジェクトとして記憶装置へ書き込む。書込みが完了すると、オブジェクトストレージ1は、書込み完了通知をクライアントへ送信する。
リクエストIDがPUT(4) である場合、オブジェクトストレージ1は、リソース識別子で指定されたリソースとして同時に渡されたデータをオブジェクトとして記憶装置へ書き込む。書込みが完了すると、オブジェクトストレージ1は、書込み完了通知をクライアントへ送信する。
リクエストIDがDELETE(5) である場合、オブジェクトストレージ1は、リソース識別子で指定されたリソースを削除する。削除が完了すると、オブジェクトストレージ1は、完了通知をクライアントへ送信する。
クライアントへの応答時に、送信元情報が、ストレージノードが使用するIPアドレスであり、代表アドレスと異なっている場合に、(例えばネットワークフィルタに引っかかるなどの)問題が生じる場合がある。
これに対しては以下のような解決策がある。
解決策１．通信フォーマットの拡張
（Ａ）Rest I/Fのフォーマットや通信フォーマットに、通信要求の度に更新される識別子をクライアントがいれておき、ストレージノードが、応答する際に遅れてきた識別子を返す。この仕組みにより、送信元アドレスが代表ストレージアドレスと異なっていても、リクエストを認識できるようになる。（アプリケーションによる対応1：NFS/RPC（Network File System/Remote Procedure Call）の仕組みを流用)
解決策２．アドレスの変換
（Ａ）ストレージノードが、アドレス変換機構(NAT、Network Address Translation)を持ち、送信する際に送信元アドレスを代表ストレージアドレスへ変換して送信する。(OS機構の利用)
（Ｂ）ストレージノードの応答に、raw socketを用い、ストレージノードは、送信元アドレスを代表ストレージアドレスにして送信する。(アプリケーションによる対応2)
（Ｃ）OpenFlowスイッチで、オブジェクトストレージとクライアントとの間で使用するポート番号、かつ宛先アドレスが、代表ストレージアドレスでない場合、OpenFlowスイッチが、送信元アドレスを代表ストレージアドレスへ変換して、転送する。(ネットワーク経路上における対応)
また、この問題を解決するためにOS基盤や通信ライブラリへ手を入れてもよい。
＜効果の説明＞
通常の分散型ストレージは、オブジェクトストレージに参加するノードを管理する必要があるので、ノード管理機能を備えていた。本実施形態によって、ネットワークにおいてノード管理が行えるようになるので、分散オブジェクトストレージが持たなければならない管理機能が大幅に削減できるようになる。
分散ストレージとの通信処理の高速化：一般的に、リソースの担当ノードを求め、その担当ノードと通信を行う必要があるが、本実施形態では、リソースを代表アドレスへ送信すればよい。その後は、リソースはOpenFlowスイッチにより順次配送される。
また、OpenFlowスイッチにより極めて高速に配送処理が行えることにより、通信性能が向上する。
リソースを担当するノードを更に柔軟に決定できる：分散ストレージの配置情報管理手段で実担当ノードを割り当てる事が可能である。すなわち、一般的な方式よりもより直接的にリソースの担当ノードを決定できる柔軟性を持つ。(例えば、空間を等分して担当しなければならないなどの制約がない。)
担当ノードの切り替えを早く実施できる：クライアントやノードで接続相手を管理している場合、それらを順次変更していかなければならない。しかし、本実施形態では、OpenFlowスイッチのFlow Tableを変更すれば済むため、切り替えを早く実施できる。関係するノードやクライアントが増加するほど、この効果は増す。
また、メタデータサーバを使った集中管理方式ではメタデータサーバの障害がシステム全体に波及する問題があるが、それとは異なり本実施形態では、 OpenFlowコントローラがダウンしてもサービスが継続できる利点がある。本実施形態では、OpenFlowコントローラがダウンしても、経路の変更ができないだけである。通信は設定済みのOpenFlowスイッチが処理を継続するため、直ちにサービスが停止することはない。
＜＜関連技術＞＞
本実施形態では、OpenFlowコントローラの数、及び、OpenFlowスイッチの数に制限はない。本実施形態は、例示したOpenFlowコントローラの数、及び、OpenFlowスイッチの数と異なる数の、OpenFlowコントローラ及びOpenFlowスイッチにより構成されるネットワークでも実施可能である。
本実施形態に係るシステムの構成を、OpenFlowスイッチ内でパケットを複製し、複数のオブジェクトストレージノードへ配送することによって、データの冗長化を行う構成にしてもよい。また、本実施形態に係るシステムの構成を、オーバレイネットワークを２面以上持つ構成に拡張してもよい。そして、ストレージノードの追加及び削除によって変化したストレージネットワークの複数の状態を世代として持つことによって、ストレージノードの追加及び削除に対応できるようにすることも考えられる。
OpenFlowコントローラを拡張するモジュール、又は、OpenFlowコントローラと協調動作するモジュールによって、OpenFlowスイッチのFlow Tableが自動的に組み立てられるようにしてもよい。
＜関連技術＞
関連1：データ長を拡大するための実装例
（フラグメントが関わる問題に関して）
UDPデータグラム、TCPストリームは1回の送信要求にMTU以上のサイズを指定できる。送信データの大きさによってはフラグメントと呼ぶネットワーク処理が、下位レイヤにおいて行われる。本実施形態では、簡便化のために、一回のやりとりで行うデータサイズをMTU以下に限定している。しかし、画像データなどのMTUより大きいサイズのデータ扱う事を考えるとMTU以上のデータ長を扱えるように拡張する必要がある。
図１７を用いてフラグメントが発生したときの問題を解説する。本実施形態の説明において、送信要求時にリソースリクエストIDとリソース識別子を先頭にしたデータを渡すことによって、UDPデータグラフはプロトコルヘッダ(UDPヘッダ)の直後、つまりペイロードの先頭に、リソースリクエストとリソース識別子が格納される。ここでフラグメントが発生すると、分割された最初のパケットにしかリソースリクエストとリソース識別子が格納されないため、後続のパケットだけによって転送先を特定できない問題が発生する。
この問題に対してはいくつかの解決策がある。
（解決方法１）
解決方法１は、オブジェクトストレージで使用するフォーマットを拡張するものである。すなわちリソースID、リクエスト識別子の他に、データのオフセット（一連のデータの先頭からの長さ）、データサイズを追加する。
送信を行う側で1パケットで取り扱えないデータサイズであった場合、1パケットに収まるサイズに分割し、分割されたデータの開始点をオフセットに、オフセットからのデータ長をデータサイズに格納し、分割した該当のデータを添えて送信することで、解決できる。
（解決方法２）
解決方法２は、VLAN tagなど使用しないプロトコルヘッダへリソース識別子の断片情報(先頭ビット) を格納するようにし、パケットの該当領域を見るだけでOFSが判断できるように拡張することである。
コンピュータに搭載されている通常のオペレーティングシステムは、その内部(kernel)のネットワークモジュールでプロトコル処理を行っている。このため、クライアントのネットワークモジュールに本実施形態のネットワークに対応させるよう手を加えることにより、上述の解決方法２は実現できる。また、OFSが、リソースがオブジェクトストレージとの通信によるリソースであるか確認するため、Flow Table0に該当領域も見るフローを追加し、該当する場合はオブジェクトストレージ用の通信を処理するFlow Table1に分岐するように設定する必要がある。
（解決方法３）
解決方法３は、OFS内部でフラグメントパケットを一旦組み立てて、転送先を認識したのち、再度分割して転送することである。
フラグメントしているパケットを判別することは、IPヘッダのフラグメントビットを参照することによって可能である。OFSは、パケットがフラグメントしていたらそのパケットの転送を待ち、一旦データグラムへ戻すことによって、パケット群のリソース識別子を得ればよい。その後、OFSは、そのデータグラムを再度分割し、リソース識別子から得た転送先へパケットを送信すればよい。
この方法には、OFS内部のメモリ使用量が増加し性能が低下する欠点がある。しかし、クライアントやオブジェクトストレージノードへの機能追加が抑えられるという利点がある。
（解決方法４）
解決方法４は、通信相手を検出するように拡張し、実際のやりとりは代表オブジェクトストレージアドレスではなく、そこから得た情報を使って行うことである。この方法は、UDPに限らずTCPを使った通信においても可能である。
UDPを使用する場合を説明する。解決方法４では、リソースリクエストに接続リクエストを加える。クライアント、及び、オブジェクトストレージノードが接続リクエストを知っておく必要がある。図１８は、本実施形態に係るシステムの、接続リクエストを使用する動作の例を表すシーケンス図である。
クライアントは、代表オブジェクトストレージアドレスに対して、操作対象のリソース識別子と接続リクエストとを送信する。
OFSは、リソース識別子を参照し、そのリソース識別子を担当とするオブジェクトストレージノードへリクエストを届ける。
担当のオブジェクトストレージノードは、リクエストIDを確認し、リクエストが接続リクエストであれば、自身のIPアドレス及びポート番号などの通信用情報を、クライアントへ送付する。
通信用情報を受け取ったクライアントは、代表オブジェクトストレージアドレスでなく、通信用情報を使って送信を行う。クライアントは、もし通信に必要であればソケットを作成する。
TCPを使った通信は、sequence番号、ack番号をソケット(通信端)毎に管理しており、UDPのように同一のソケットを使って異なる相手と通信することができない。それにより、TCPを使った通信は分散ノードと通信する場合に同一のソケットが使えない問題を抱える。この問題も、また、リソースリクエストへ接続リクエストを追加し、コールバックさせる方法によって解決できる。図１９は、本実施形態に係るシステムの、解決策が適用された動作の例を表すシーケンス図である。
クライアントは、初めの要求時に、接続リクエストと操作対象のリソースIDとを要求のペイロードに格納し、要求をオブジェクトストレージネットワークへ送信する。
OFSは、リソースIDから担当のオブジェクトストレージノードへ要求を送り届ける。
オブジェクトストレージノードは、リクエストIDを確認し、要求が接続リクエスト要求であれば、クライアントのIPアドレスを宛先アドレスに持つTCPソケットを作成する。クライアントとオブジェクトストレージノードは、TCPセッションを確立できたら、Rest I/Fのやりとりをおこない、そのやりとりの実行後にソケットを削除する。
セッションはオブジェクトストレージノード側から開設してもよい。クライアント側から張るようにしてもよい。またソケットの作成が負荷になるようであれば、再利用できるよう管理を行うことも考えられる。
関連２：オブジェクトストレージ用オーバレイネットワークの構築方法について
本実施形態では、オブジェクトストレージ用のオーバレイネットワークの構築として、OpenFlowをオブジェクトストレージ用の情報が読めるように拡張した。ここでは、別の方法として、既存のプロトコルフィールドを活かす方法を記載する。この方法によると、既存のフィールドを使用するため、OpenFlowスイッチ自体は現行の製品がそのまま流用できる利点がある。
本実施形態では、ペイロード上にオブジェクトストレージ用のヘッダは設けられない。プロトコルヘッダにおいて使用していない領域が使用する。一つの例としてVLAN（Virtual Local Area Network）ヘッダを利用する。OpenFlowでは、VLANに関する次のフィールドがフローのマッチング条件に既に使用できる。
VLAN ID ： 12bit
VLAN priority ： 3bit
本実施形態では、リクエスト識別子にVLAN priorityフィールドを使用し、リソース識別子にVLAN IDで使用されていない値を使用する。フィールドのbit長が小さいため、リソース識別子全体を格納することはできない。そのため仮想オブジェクトストレージが判別できる情報のみがフィールドに格納される。本実施形態では、リソース識別子の先頭4bitが利用される。同様に先頭4bitを利用し、本例では、（1000〜1016）に割り当てる。(VLAN ID 0は、制限によって利用できない。ここでは仮に1000から順に割り当てた。)
オーバレイネットワークの設計にあたり、OpenFlowコントローラは、本実施形態で説明したように、リソース識別子の空間を分割した後、領域と仮想オブジェクトストレージに対応付けを行う。その後、OpenFlowコントローラは、仮想オブジェクトストレージと実ストレージとを関連付ける。本実施形態では、さらに、リソース識別子の先頭ビットが示す値とVLAN IDとの関連付けを行ってもよい。
関連付けが終わると、OpenFlowコントローラは、次に担当の実ストレージノードへ配送されるような、マッチング条件にVLAN IDを使用したFlow Tableを作成する。つまり、OpenFlowコントローラは、VLAN ID及びpriorityによって、オブジェクトストレージ用のオーバレイネットワークを作成する。(Flow Table1のリソース識別子用フローのマッチング条件が、VLAN ID及びpriorityを使用しているものとなる)。
オブジェクトストレージのクライアントは、送信時に、リソース識別子の先頭数ビット(用いる仮想ストレージノード数に依存) をVLAN IDにセットし、リクエスト識別子をVLAN priorityへセットする。このようにすることで、OpenFlowスイッチは、代表オブジェクトストレージアドレスと、VLAN IDと、priorityとに基づいてパケットを転送するだけで、最終的にリソースを担当するマシンへパケットを転送することが可能となる。
なおTCP/IPプロトコルの細かな部分は、アプリケーションプログラムでは設定できず、OSの内部で設定されることが多い。したがってOSの一機能としてこのような通信機構を提供すると、アプリケーション側で対応するよりも簡単に以上の方法を実装できる。あくまでアプリケーションプログラム側で実装する場合は、raw socketと呼ばれる既存の通信の仕組みを用いた実装が可能である。raw socketを使用するとプロトコルヘッダを自由に設定できるようになる。OS及びアプリケーションプログラムをミックスした構成も考えられる。
（多様なオブジェクトストレージフォーマットへの対応）
「オブジェクトストレージ」という同じ名称で呼ばれていても、オブジェクトストレージにおいて使用されるデータフォーマットは様々なものが存在する。すなわち、使用されるデータフォーマットは統一されていない。ここではさらなる工夫として、オブジェクトストレージの多様なフォーマットに対応する、通信モジュールを使用する方法を記載する。直前に記載した事項にも考慮している。
ここまでで説明した本実施形態では、オブジェクトストレージ内の通信モジュールが、使用するネットワークに合わせてフォーマットを変換している。オブジェクトストレージ自体は使用されるフォーマットに関与せず、外部の通信モジュールが、適時、通信用のフォーマットへ変換する仕組みをについて説明する。
その形態として、ライブラリ形態で利用する方式と、OSの機能としてフォーマットの変換を提供する形態、および、それらの複合形態が考えられる。
以下では、例として、フォーマットを変換する機能を、ライブラリとして組み込む形式について説明する。その他の形態も、大きく変わらず実現できる。（OSに組み入れた方がより楽に実現できる。）図２０は、本実施形態のシステムに係る、フォーマットを変換する機能がライブラリに組み込まれている構成の例を表す図である。
図２０における通信管理部は、通信を管理する機構である。通信に必要な情報は、通信ハンドラと呼ぶ管理構造体に格納される。また、通信ハンドラには、一意に特定できるIDが作成時に付与される。通信管理部は、ハンドラの作成や廃棄といったハンドラの管理作業を行う役割と、指定されたIDのハンドラが持つ情報を渡す役割とを持つ。
オブジェクトストレージは、初期化時に、通信ハンドラの作成を通信管理部へ要求する（図２１）。図２１は、本実施形態に係るシステムの、通信モジュールに通信の解説を要求する動作の例を表すシーケンス図である。オブジェクトストレージは、通信ハンドラの作成の要求する際、引数として代表オブジェクトストレージアドレスなど送信用情報も渡す。通信管理部は、ハンドラ作成要求時に渡された通信情報を通信ハンドラへ記録したのち、通信に使用するsocketを作成する。ハンドラの作成が終わると、ハンドラのIDを要求アプリケーションへ返却する。オブジェクトストレージは、以後の通信時に受け取ったハンドラIDを指定して要求を行う。
次に、通信モジュールを使ったオブジェクトストレージの通信について説明する。図２２は、通信モジュールを使ったオブジェクトストレージの通信の例を表すシーケンス図である。
本通信モジュールを使用して送信を行う場合、入出力受付部が用意する送信要求I/Fから送信要求を発行する。送信要求I/Fは、通信ハンドラのIDと、オブジェクトストレージのフォーマットで整形されたデータとを、入出力受付部へ渡す。なお、入出力受付部へデータを渡す際に、リソースIDとリクエストIDとをともに渡してもよい。このようにすれば後述するフォーマット変換を、より楽に行うことができる。
通信モジュールは、送信要求を受け付けると、渡されたデータのフォーマットから、リソース識別子とリクエストIDとを得る。次に、通信モジュールは、渡されたデータのフォーマットの、本実施形態で使用する通信用フォーマットへの変換を行う。
本実施形態では、データフォーマットの前に、リクエストIDとリソース識別子が記載される。
別の実施形態では、リクエストIDの一部を加工してVLAN IDへ、リソース識別子をVLAN priorityへ格納してもよい。
通信モジュールは、オーバレイネットワーク用のフォーマットを変換したのち、通信に必要なIP及びUDPなどのネットワークヘッダを記述する。その次に、通信モジュールは、通信ハンドラが持つraw socketを使って、作成したデータのOSの通信レイヤへの送信要求を行い、ネットワークへ送信する。
送信が完了すると、通信モジュールは、送信完了通知を送信要求元へ返却する。
次に、受信動作を説明する。オブジェクトストレージプログラムは、ハンドラIDと受信バッファ用のメモリアドレスを引数に、入出力受付部が用意する受信インタフェースを実行する。受信インタフェースは、ハンドラIDで指定されたハンドラのソケットが受信しているかを確認し、受信していた場合、上位で使用するフォーマットへ受信データを変換する。
本実施形態では、データの先頭にオーバレイネットワークで使用したヘッダが追加されているので、オブジェクトストレージプログラムは、追加されたヘッダの削除を行う。
他の実施形態（例えばVLANを使用する例）では、追加されたヘッダはないので、データ領域はそのまま使用すればよい。
オブジェクトストレージプログラムは、変換したデータを、引数として渡された受信バッファに書き込む。最後に受信関数を戻し、オブジェクトストレージプログラム側の受信機構が動作する。
（その他の実現方法：ネットワーク側で対処する方法）
本実施形態は、ネットワーク側のみを拡張することでも実現が可能である。
１．特定のネットワークポートのパケットが到着した場合、オブジェクトストレージの通信と判断し、パケットの解析を行う。
（Ａ）（Ｂ）において使用しているプロトコルフィールドに情報があれば（Ｂ）を実施しない。(プロトコルフィールドに情報があるパケットは、他のスイッチから転送されたパケットである。)
（Ｂ）プロトコルフィールドに情報がない場合はフォーマットの解析を実行し、必要なリソースIDなどの情報を入手する。
フォーマットの解析方法には、（１）先頭からの固定長の範囲を解析する方法、及び、（２）オブジェクトストレージのフォーマットを解析できるように、より大きく拡張した形態等が考えられる。
これまでの実現と同様に、使用していないプロトコルフィールドを使用し、仮想オブジェクトストレージ用の情報をそのプロトコルフィールドを書き込む。この書込みにより、常にスイッチで解析動作を行う必要がなくなる。（これは、Group Tableの仕組みにより実現される）
２．プロトコルフィールドの情報に基づき、（以上で説明したように）オーバレイネットワークで転送を行っていく。最終的に目的地にパケットを届ける。
本実施形態は、以上のようにネットワーク側のみを拡張することでも実現できる。以上、OpenFlowを例に本実施形態を説明したが、ストレージネットワーク用のオーバレイネットワークを構築するのに利用する技術は、OpenFlowに限られず、例えば、SDNを実現する他の技術であってもよい。
＜＜第２の実施形態＞＞
次に、本発明の第２の実施形態について、図面を参照して詳細に説明する。
＜構成＞
図２３は、本実施形態に係るストレージシステム１の構成を表すブロック図である。本実施形態のストレージシステム１は、第１の実施形態を模式的に表す。
図２３を参照すると、本実施形態にストレージシステム１は、通信管理装置１０と、複数の通信機器２０と、複数の実ストレージノード３０とを含む。通信管理装置１０には、設定端末装置５０が通信可能に接続されていてもよい。
通信機器２０は、例えば、一般的なOpenFlowスイッチとしても動作する交換機である。通信機器２０の各々は、少なくとも１台の他の通信機器２０と通信可能に接続されている。実ストレージノード３０は、いずれかの通信機器２０に通信可能に接続されている。通信機器２０は、各実ストレージノード３０と、いずれかの通信機器２０と通信可能な装置（例えば情報処理装置６０）との間の通信を媒介する、通信ネットワーク４０を実現する。言い換えると、通信機器２０は、接続されている機器が少なくとも１つの通信機器２０を介して通信可能な通信ネットワーク４０を実現する。実ストレージノード３０は、通信ネットワーク４０に接続されている。また、情報処理装置６０も、通信ネットワーク４０に接続されている。通信ネットワーク４０は、第１の実施形態におけるStorage Overlay Networkである。
通信管理装置１０と通信機器２０とは、さらに、通信ネットワーク４０とは独立した経路で、通信可能に接続されている。
通信管理装置１０は、決定部１１と、生成部１２と、適用部１３と、入出力部１４と、記憶部１５とを含む。通信管理装置１０は、一般的なOpenFlowコントローラとして動作する制御装置である。通信管理装置１０のこれらの部は、主に、第１の実施形態における、分散ストレージの配置情報を管理する機能（すなわち、分散ストレージ配置情報管理手段）に相当する。
設定端末装置５０は、例えば、ストレージシステム１の管理者が入力した、複数の通信機器２０と複数の実ストレージノード３０との接続関係と、実ストレージノード３０に対する仮想ストレージノードの割り当てとを、通信管理装置１０に送信する。
各通信機器２０は複数のポートを備える。１つのポートに他の通信機器２０又は実ストレージノード３０を接続できる。複数の通信機器２０と複数の実ストレージノード３０との接続関係は、例えば、それぞれの通信機器２０の、他の装置が接続されているポートと、そのポートに接続されている他の装置とを特定する情報である。上述の「他の装置」は、他の通信機器２０のいずれか又は実ストレージノード３０のいずれかを指す。実ストレージノード３０に対する仮想ストレージノードの割り当ては、例えば、それぞれの実ストレージノード３０に割り当てられている仮想ストレージノードを特定できる情報である。複数の仮想ストレージノードが、１つの実ストレージノード３０に割り当てられていてもよい。
通信管理装置１０の入出力部１４は、設定端末装置５０から、通信機器２０の接続関係と、通信機器２０と実ストレージノード３０との接続関係と、実ストレージノード３０に対する仮想ストレージノードの割り当てとを受信する。通信管理装置１０は、受信した、通信機器２０の接続関係と、通信機器２０と実ストレージノード３０との接続関係と、実ストレージノード３０に対する仮想ストレージノードの割り当てとを、記憶部１５に格納する。以下の説明では、実ストレージノード３０に対する仮想ストレージノードの割り当ては、「第３の割り当て関係」とも表記される。
記憶部１５は、例えば、通信機器２０の接続関係と、通信機器２０と実ストレージノード３０との接続関係と、実ストレージノード３０に対する仮想ストレージノードの割り当てとを記憶する。
情報処理装置６０は、オブジェクトストレージとやりとりをする装置である。情報処理装置６０は、オブジェクトストレージとやりとりをする際に、リソース識別子とリクエストの種類よってはオブジェクトの内容を、ストレージシステム１に対して送信する。情報処理装置６０は、オブジェクトをストレージシステム１に記憶させる場合、例えば、リソース識別子が一意に付与されたオブジェクトを、ストレージシステム１に対して送信してもよい。ストレージシステム１に対して送信されるオブジェクトには、送信先のアドレスとして、ストレージシステム１の代表アドレスが付与されていればよい。代表アドレスは、あらかじめ定められていればよい。オブジェクトを受信した通信機器２０は、その通信機器２０に適用されている設定にしたがって、いずれかのポートに接続されている装置（すなわち、他の通信機器２０又は実ストレージノード３０）を、そのオブジェクトの転送先として決定する。通信機器２０は、決定した転送先に、受信したオブジェクトを転送する。転送先が実ストレージノード３０である場合、その実ストレージノード３０は、オブジェクトを受信し、受信したオブジェクトを記憶する。通信機器２０に適用されている設定は、例えば以下で説明するように生成される。その設定は、例えば、上述のFlow Table として表されていてもよい。
決定部１１は、リソース識別子を複数の実ストレージノードのいずれかに割り当てる第１の割り当て関係を決定する。具体的には、決定部１１は、例えば上述のConsistent Hashingによって、前記リソース識別子を、前記使用部分に基づいて前記複数の仮想ストレージノードのいずれかに割り当てる第２の割り当て関係を決定すればよい。リソース識別子がハッシュ値として割り当てられている場合、リソース識別子の一部（例えば先頭の所定数のビット。以下、「使用部分」とも表記）と仮想ストレージノードのいずれかに割り当てる第２の割り当て関係を決定してもよい。決定部１１は、仮想ストレージノードの数に基づいて、使用部分（上述の例の場合、先頭のビット数）を決定してもよい。決定部１１は、仮想ストレージノードの数より小さくない最小の２のべき乗の指数を、使用部分のビット数として決定してもよい。第２の割り当て関係と上述の第３の割り当て関係とによって、リソース識別子と実ストレージノード３０との関係が特定される。決定部１１は、上述の、第２の割り当て関係と第３の割り当て関係とに基づいて、第１の割り当て関係を決定すればよい。
生成部１２は、オブジェクトに一意に付与されるリソース識別子に基づいてオブジェクトの転送先を決定するルールを含む設定を表すデータを、上述の第１の割り当て関係と、例えば記憶部１５に格納されている、通信機器２０の接続関係とに基づいて生成する。以下の説明では、設定を表すデータを、単に「設定」と表記する。オブジェクトに一意に付与されるリソース識別子に基づいてオブジェクトの転送先を決定するルールを、「第１のルール」と表記する。
なお、一つの仮想ストレージノードに、複数の実ストレージノード３０が割り当てられていてもよい。その場合、第１の割り当て関係において、一つのリソース識別子に対して、複数の実ストレージノード３０が割り当てられる。言い換えると、第１の割り当て関係は、リソース識別子を、２つ以上の実ストレージノードに割り当てる割り当てを含んでいてもよい。これは、一つのオブジェクトが２つ以上の実ストレージノードに送信されることを表す。その場合、少なくともいずれかの通信機器２０において、同じオブジェクトを２つ以上の転送先に転送される。生成部１２は、同じオブジェクトを２つ以上の転送先に転送する通信機器２０の設定として、オブジェクトの転送先として、２つ以上の転送先を決定する第１のルールを含む設定を生成すればよい。その場合、その通信機器２０は、同じオブジェクトの数が２以上になるよう、オブジェクトを複写すればよい。生成部１２は、転送先の数が２以上である通信機器２０の設定として、オブジェクトを転送先の数と同じ数になるよう複写するルール（以下、「第２のルール」と表記）を更に含む設定を生成すればよい。
生成部１２は、オブジェクトの送信先のアドレスとして、上述の代表アドレスが指定されている場合、上述の第１のルールに従ってオブジェクトの転送先を決定する第３のルールを含む設定を生成してもよい。そして、その第３のルールは、オブジェクトの送信先のアドレスとして、上述の代表アドレスが指定されていない場合、通信機器２０は、通常のOpenFlowスイッチとして、Flow Tableに基づいて動作するよう設定されていればよい。
適用部１３は、生成部１２が通信機器２０ごとに生成した設定を、通信機器２０に適用する。具体的には、適用部１３は、設定（すなわち、設定を表すデータ）を、通信機器２０に送信する。
次に、通信機器２０の構成について図面を参照して詳細に説明する。
図２４は、本実施形態に係る通信機器２０の構成の例を表すブロック図である。
図２４を参照すると、通信機器２０は、設定受信部２１と、転送先決定部２２と、入出力部２３とを含む。
通信機器２０の設定受信部２１が、通信管理装置１０の適用部１３から、設定を受信する。設定受信部２１は、受信した設定を転送先決定部２２に送信する。
入出力部２３は、いずれかのポートに接続されている装置（情報処理装置６０、他の通信機器２０、又は、実ストレージノード３０）からオブジェクトを受信する。
転送先決定部２２は、受信したオブジェクトの転送先を、受信した設定に従って決定する。
入出力部２３は、転送先決定部２２が決定した転送先に、受信したオブジェクトを転送する。
＜動作＞
次に、本実施形態の通信管理装置１０の動作について、図面を参照して詳細に説明する。
図２５は、本実施形態の通信管理装置１０の動作の例を表すフローチャートである。
図２５に示す動作では、入出力部１４が、複数の通信機器２０及び複数の実ストレージノード３０の接続関係と、仮想ストレージノードの実ストレージノードへの割り当て（すなわち、第３の割り当て関係）を受信する（ステップＳ１０１）。入出力部１４は、受信した接続関係及び第３の割り当て関係を、記憶部１５に格納する。実ストレージノードは、第１の実施形態のオブジェクトストレージノードに相当する。
決定部１１は、例えば、仮想ストレージノードの数に基づいて、リソース識別子の使用部分を決定する（ステップＳ１０２）。決定部１１は、例えば決定した使用部分に基づいて、仮想ストレージノードに対するリソース識別子の割り当て（すなわち、第２の割り当て関係）を決定する（ステップＳ１０３）。決定部１１は、第２の割り当て関係と、第３の割り当て関係とに基づいて、実ストレージノードに対するリソース識別子の割り当て（すなわち、第１の割り当て関係）を決定する（ステップＳ１０４）。
次に、生成部１２が、入出力部１４が受信し記憶部１５に格納されている前述の接続関係と、決定部１１によって決定された第１の割り当て関係とに基づいて、オブジェクトに一意に付与されるリソース識別子に基づいてオブジェクトの転送先を決定する第１のルールを含む設定を生成する（ステップＳ１０５）。上述のように、第１のルールは、オブジェクトに一意に付与されるリソース識別子に基づいてオブジェクトの転送先を決定するルールである。生成部１２は、リソース識別子が２つ以上の実ストレージノードに割り当てられたオブジェクトに対して、２つ以上の転送先を決定する第１のルールと、上述の第２のルールとを含む設定を生成してもよい。上述のように第２のルールは、オブジェクトの数が転送先と同じ数になるようオブジェクトを複製し、転送先の各々にそのオブジェクトを転送するルールである。生成部１２は、オブジェクトの送信先が上述の代表アドレスである場合に第１のルールに従ってオブジェクトの転送先を決定し、それ以外の場合、通常のOpen Flow NetworkのFlow Tableに基づいて転送先を決定する第３のルールを生成してもよい。
次に、適用部１３が、生成した設定を通信機器２０に適用する（ステップＳ１０６）。例えば、適用部１３は、生成した設定を通信機器２０に送信する。通信機器２０の設定受信部２１が、設定を受信する。転送先決定部２２は、受信した設定に従って転送先を決定する。
次に、本実施形態の通信機器２０の動作について、図面を参照して詳細に説明する。
図２６は、本実施形態の通信機器２０の動作の例を表すフローチャートである。図２６に示す動作の例は、上述の第１、第２、及び第３のルールを含む設定に従って動作する通信機器２０の動作の例である。
図２６によると、まず、入出力部２３が、オブジェクトについて一意であるリソース識別子が付与されているオブジェクトを受信する（ステップＳ２０１）。オブジェクトには、さらに、送信先のアドレスが付与されている。
転送先決定部２２は、送信先のアドレスが代表アドレスであるか否かを判定する（ステップＳ２０２）。送信先のアドレスが代表アドレスでない場合（ステップＳ２０２においてＮＯ）、転送先決定部２２は、一般的なOpenFlowスイッチとして動作することによって、送信先のアドレスに基づいて受信したオブジェクトの転送先を決定する（ステップＳ２０７）。そして、入出力部２３は、受信したオブジェクトを、決定された転送先に転送する（ステップＳ２０７）。
送信先のアドレスが代表アドレスである場合（ステップＳ２０２においてＹＥＳ）、転送先決定部２２は、通信管理装置１０から受信した設定に従って、リソース識別子に基づいて、受信したオブジェクトの転送先を決定する（ステップＳ２０３）。
２つ以上の転送先が決定されなかった場合（ステップＳ２０６においてＮＯ）、入出力部２３は、受信したオブジェクトを、決定された転送先に転送する（ステップＳ２０７）。
２つ以上の転送先が決定された場合（ステップＳ２０６においてＹＥＳ）、入出力部２３は、オブジェクトの数が転送先の数になるように、オブジェクトを複製する（ステップＳ２０５）。そして、入出力部２３は、オブジェクトを、決定された転送先に転送する（ステップＳ２０７）。
＜効果＞
以上で説明した本実施形態には、分散型ストレージにおける管理負荷を軽減しながら高速で柔軟な経路の切り替えをできるという効果がある。その理由は、生成部１２が生成した、オブジェクトの転送先を決定する設定を、適用部１３が通信機器２０に適用するからである。そのため、通信管理装置１０が、通信機器２０におけるオブジェクトの転送のたびに転送先の決定する必要が無いので、通信管理装置１０の負荷が軽減される。また、参加ノードとオブジェクトの担当の把握を、それぞれの通信機器２０が行なう必要が無いので、通信機器２０の負担が軽減される。また、通信機器２０の追加など、システムに参加する通信機器２０に変更が加わった場合、設定は通信管理装置１０によって各通信機器２０に送信されるので、設定が全体に伝わりきるまで時間が短縮される。
＜＜第３の実施形態＞＞
次に、本発明の第３の実施形態について、図面を参照して詳細に説明する。
＜構成＞
図２７は、本実施形態の通信管理装置１０Ａの構成の例を表すブロック図である。
図２７を参照すると、通信管理装置１０Ａは、生成部１２と、適用部１３とを含む。
生成部１２は、複数の実ストレージノードのいずれかにオブジェクトを送信する経路における複数の通信機器の設定を、第１の割り当て関係と、複数の通信機器及び複数の実ストレージノードの接続関係とに基づいて生成する。設定は、前記オブジェクトに一意に付与される識別子に基づいて前記オブジェクトの転送先を決定する第１のルールを含む。第１の割り当て関係は、前記識別子を前記複数の実ストレージノードのいずれかに割り当てる割り当てを表す。
適用部１３は、通信機器に設定を適用する。
＜動作＞
次に、本実施形態の通信管理装置１０Ａの動作について、図面を参照して詳細に説明する。
図２８は、本実施形態の通信管理装置１０Ａの動作の例を表すフローチャートである。
図２８を参照すると、生成部１２は、上述の、通信機器の設定を生成する（ステップＳ３０１）。生成部１２は、通信機器毎に設定を生成すればよい。次に、適用部１３が、通信機器に設定を適用する（ステップＳ３０２）。適用部１３は、通信機器毎に、生成された設定を適用すればよい。
＜効果＞
以上で説明した本実施形態には、第２の実施形態と同じ効果がある。その理由は、第２の実施形態の効果が生じる理由と同じである。
＜＜他の実施形態＞＞
上述の各実施形態に係る装置は、それぞれ、コンピュータ及びコンピュータを制御するプログラム、専用のハードウェア、又は、コンピュータ及びコンピュータを制御するプログラムと専用のハードウェアの組合せにより実現することができる。上述の各実施形態にかかる装置は、例えば、第１の実施形態に係るOFS、OFC及び協調サーバ、第２及び第３の実施形態に係る通信管理装置、及び、第２の実施形態に係る通信機器などである。
言い換えると、上述の各実施形態に係る装置は、回路構成（ｃｉｒｃｕｉｔｒｙ）などのハードウェアによって実現することができる。回路構成は、例えば、コンピュータに含まれるプロセッサとメモリであってもよい。その場合、プログラムが、メモリにロードされていればよい。そのプログラムは、プロセッサが実行することが可能であり、コンピュータを上述の各実施形態に係る装置として動作させればよい。回路構成は、例えば、通信可能に接続された複数のコンピュータであってもよい。回路構成は、例えば、回路（ｃｉｒｃｕｉｔ）であってもよい。回路構成は、例えば、通信可能に接続された複数の回路であってもよい。回路構成は、通信可能に接続された、１台以上のコンピュータと、１個以上の回路との組み合わせであってもよい。
図２９は、本発明の各実施形態に係る装置を実現することができる、コンピュータ１０００のハードウェア構成の一例を表す図である。図２９を参照すると、コンピュータ１０００は、プロセッサ１００１と、メモリ１００２と、記憶装置１００３と、Ｉ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）インタフェース１００４とを含む。また、コンピュータ１０００は、記録媒体１００５にアクセスすることができる。メモリ１００２と記憶装置１００３は、例えば、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ハードディスクなどの記憶装置である。記録媒体１００５は、例えば、ＲＡＭ、ハードディスクなどの記憶装置、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、可搬記録媒体である。記憶装置１００３が記録媒体１００５であってもよい。プロセッサ１００１は、メモリ１００２と、記憶装置１００３に対して、データやプログラムの読み出しと書き込みを行うことができる。プロセッサ１００１は、Ｉ／Ｏインタフェース１００４を介して、他の装置にアクセスすることができる。プロセッサ１００１は、記録媒体１００５にアクセスすることができる。記録媒体１００５には、コンピュータ１０００を通信管理装置１０として動作させるプログラムが格納されている。記録媒体１００５には、コンピュータ１０００を通信管理装置１０Ａとして動作させるプログラムが格納されていてもよい。記録媒体１００５には、コンピュータ１０００を通信機器２０として動作させるプログラムが格納されていてもよい。記録媒体１００５には、コンピュータ１０００を、第１の実施形態のOFCとして動作させるプログラムが格納されていてもよい。記録媒体１００５には、コンピュータ１０００を、第１の実施形態のOFSとして動作させるプログラムが格納されていてもよい。記録媒体１００５には、コンピュータ１０００を、第１の実施形態の協調サーバとして動作させるプログラムが格納されていてもよい。
プロセッサ１００１は、記録媒体１００５に格納されている、上述のプログラムを、メモリ１００２にロードする。そして、プロセッサ１００１が、メモリ１００２にロードされたプログラムを実行することにより、コンピュータ１０００は、上述の装置のいずれかとして動作する。
決定部１１、生成部１２、適用部１３、入出力部１４、設定受信部２１、転送先決定部２２、及び、入出力部２３は、例えば、メモリ１００２と、メモリ１００２にロードされた専用のプログラムを実行するプロセッサ１００１により実現することができる。また、記憶部１５は、コンピュータ１０００が含むメモリ１００２やハードディスク装置等の記憶装置１００３により実現することができる。あるいは、決定部１１、生成部１２、適用部１３、入出力部１４、記憶部１５は、設定受信部２１、転送先決定部２２、及び、入出力部２３は、の一部又は全部を、各部の機能を実現する専用の回路によって実現することもできる。
また、上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
（付記１）
複数の実ストレージノードのいずれかにオブジェクトを送信する経路における複数の通信機器の、前記オブジェクトに一意に付与される識別子に基づいて前記オブジェクトの転送先を決定する第１のルールを含む設定を、前記識別子を前記複数の実ストレージノードのいずれかに割り当てる第１の割り当て関係と、前記複数の通信機器及び前記複数の実ストレージノードの接続関係とに基づいて生成する生成手段と、
前記通信機器に前記設定を適用する適用手段と、
を備える通信管理装置。
（付記２）
前記第１の割り当て関係は、前記識別子を、前記複数の実ストレージノードのうち２つ以上の実ストレージノードに割り当てる割り当てを含み、
前記生成手段は、いずれかの前記通信機器の前記設定として、前記識別子が２つ以上の実ストレージノードに割り当てられた前記オブジェクトに対して、２つ以上の前記転送先を決定する前記第１のルールと、当該オブジェクトの数が前記転送先の数と同じになるよう当該オブジェクトを複製し、当該オブジェクトを前記転送先の各々に転送する第２のルールとを含む前記設定を生成する
付記１に記載の通信管理装置。
（付記３）
前記複数の実アドレスのいずれかに送信される前記オブジェクトは、送信先のアドレスとして代表アドレスが付与され、
前記生成手段は、オブジェクトに送信先として付与されているアドレスが前記代表アドレスである場合に前記第１のルールに従って前記オブジェクトの前記転送先を決定する第３のルールをさらに含む、前記設定を生成する
付記１又は２に記載の通信管理装置。
（付記４）
前記生成手段は、前記識別子の一部である使用部分に基づいて前記オブジェクトの転送先を決定する前記第１のルールを含む前記設定を、前記使用部分を前記複数の実ストレージノードのいずれかに割り当てる前記第１の割り当て関係に基づいて生成する
付記１乃至３のいずれかに記載の通信管理装置。
（付記５）
複数の仮想ストレージノードの数に基づいて前記識別子における前記使用部分を決定し、前記識別子を、前記使用部分に基づいて前記複数の仮想ストレージノードのいずれかに割り当てる第２の割り当て関係を決定し、当該第２の割り当てと、前記複数の仮想ストレージノードの各々を前記複数の実ストレージノードのいずれかに割り当てる第３の割り当て関係とに基づいて、前記第１の割り当て関係を決定する決定手段
を更に備える付記４に記載の通信管理装置。
（付記６）
付記１乃至５のいずれか１項に記載の通信管理装置と、
前記設定に従って前記オブジェクトを転送する前記通信機器と、
を含む通信システム。
（付記７）
付記１乃至５のいずれかに記載の通信管理装置が生成した前記設定に従って、前記オブジェクトの転送先を決定する転送先決定手段と、
前記オブジェクトを受信し、当該オブジェクトを前記転送先決定手段によって決定された前記転送先に送信する入出力手段と、
を備える通信装置。
（付記８）
複数の実ストレージノードのいずれかにオブジェクトを送信する経路における複数の通信機器の、前記オブジェクトに一意に付与される識別子に基づいて前記オブジェクトの転送先を決定する第１のルールを含む設定を、前記識別子を前記複数の実ストレージノードのいずれかに割り当てる第１の割り当て関係と、前記複数の通信機器及び前記複数の実ストレージノードの接続関係とに基づいて生成し、
前記通信機器に前記設定を適用する、
通信管理方法。
（付記９）
前記第１の割り当て関係は、前記識別子を、前記複数の実ストレージノードのうち２つ以上の実ストレージノードに割り当てる割り当てを含み、
いずれかの前記通信機器の前記設定として、前記識別子が２つ以上の実ストレージノードに割り当てられた前記オブジェクトに対して、２つ以上の前記転送先を決定する前記第１のルールと、当該オブジェクトの数が前記転送先の数と同じになるよう当該オブジェクトを複製し、当該オブジェクトを前記転送先の各々に転送する第２のルールとを含む前記設定を生成する
付記８に記載の通信管理方法。
（付記１０）
前記複数の実アドレスのいずれかに送信される前記オブジェクトは、送信先のアドレスとして代表アドレスが付与され、
オブジェクトに送信先として付与されているアドレスが前記代表アドレスである場合に前記第１のルールに従って前記オブジェクトの前記転送先を決定する第３のルールをさらに含む、前記設定を生成する
付記８又は９に記載の通信管理方法。
（付記１１）
前記識別子の一部である使用部分に基づいて前記オブジェクトの転送先を決定する前記第１のルールを含む前記設定を、前記使用部分を前記複数の実ストレージノードのいずれかに割り当てる前記第１の割り当て関係に基づいて生成する
付記８乃至１０のいずれかに記載の通信管理方法。
（付記１２）
複数の仮想ストレージノードの数に基づいて前記識別子における前記使用部分を決定し、前記識別子を、前記使用部分に基づいて前記複数の仮想ストレージノードのいずれかに割り当てる第２の割り当て関係を決定し、当該第２の割り当てと、前記複数の仮想ストレージノードの各々を前記複数の実ストレージノードのいずれかに割り当てる第３の割り当て関係とに基づいて、前記第１の割り当て関係を決定する
付記１１に記載の通信管理方法。
（付記１３）
コンピュータに、
複数の実ストレージノードのいずれかにオブジェクトを送信する経路における複数の通信機器の、前記オブジェクトに一意に付与される識別子に基づいて前記オブジェクトの転送先を決定する第１のルールを含む設定を、前記識別子を前記複数の実ストレージノードのいずれかに割り当てる第１の割り当て関係と、前記複数の通信機器及び前記複数の実ストレージノードの接続関係とに基づいて生成する生成処理と、
前記通信機器に前記設定を適用する適用処理と、
を実行させるプログラム。
（付記１４）
前記第１の割り当て関係は、前記識別子を、前記複数の実ストレージノードのうち２つ以上の実ストレージノードに割り当てる割り当てを含み、
前記生成処理は、いずれかの前記通信機器の前記設定として、前記識別子が２つ以上の実ストレージノードに割り当てられた前記オブジェクトに対して、２つ以上の前記転送先を決定する前記第１のルールと、当該オブジェクトの数が前記転送先の数と同じになるよう当該オブジェクトを複製し、当該オブジェクトを前記転送先の各々に転送する第２のルールとを含む前記設定を生成する
付記１３に記載のプログラム。
（付記１５）
前記複数の実アドレスのいずれかに送信される前記オブジェクトは、送信先のアドレスとして代表アドレスが付与され、
前記生成処理は、オブジェクトに送信先として付与されているアドレスが前記代表アドレスである場合に前記第１のルールに従って前記オブジェクトの前記転送先を決定する第３のルールをさらに含む、前記設定を生成する
付記１３又は１４に記載のプログラム。
（付記１６）
前記生成処理は、前記識別子の一部である使用部分に基づいて前記オブジェクトの転送先を決定する前記第１のルールを含む前記設定を、前記使用部分を前記複数の実ストレージノードのいずれかに割り当てる前記第１の割り当て関係に基づいて生成する
付記１３乃至１５のいずれかに記載のプログラム。
（付記１７）
コンピュータに、
複数の仮想ストレージノードの数に基づいて前記識別子における前記使用部分を決定し、前記識別子を、前記使用部分に基づいて前記複数の仮想ストレージノードのいずれかに割り当てる第２の割り当て関係を決定し、当該第２の割り当てと、前記複数の仮想ストレージノードの各々を前記複数の実ストレージノードのいずれかに割り当てる第３の割り当て関係とに基づいて、前記第１の割り当て関係を決定する決定処理
を更に実行させる付記１６に記載のプログラム。
以上、実施形態を参照して本発明を説明したが、本発明は上記実施形態に限定されるものではない。本発明の構成や詳細には、本発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
１ ストレージシステム
１０ 通信管理装置
１０Ａ 通信管理装置
１１ 決定部
１２ 生成部
１３ 適用部
１４ 入出力部
１５ 記憶部
２０ 通信機器
３０ 実ストレージノード
４０ 通信ネットワーク
５０ 設定端末装置
６０ 情報処理装置
１０１ OpenFlow Network
１０２ Storage Overlay Network
１０３ OpenFlow controller
１０４ 分散ストレージ配置情報管理手段
１０５ Object Storage
１０６ Client
１０７ Other Server
２０１ OSF
２０２ OSF
２０３ OSF
１０００ コンピュータ
１００１ プロセッサ
１００２ メモリ
１００３ 記憶装置
１００４ Ｉ／Ｏインタフェース
１００５ 記録媒体

Claims (10)

  1. 複数の実ストレージノードのいずれかにオブジェクトを送信する経路における複数の通信機器の、前記オブジェクトに一意に付与される識別子に基づいて前記オブジェクトの転送先を決定する第１のルールを含む設定を、前記識別子を前記複数の実ストレージノードのいずれかに割り当てる第１の割り当て関係と、前記複数の通信機器及び前記複数の実ストレージノードの接続関係とに基づいて生成する生成手段と、
    前記通信機器に前記設定を適用する適用手段と、
    を備え、
    前記第１の割り当て関係は、前記識別子を複数の仮想ストレージノードのいずれかに割り当てる第２の割り当て関係と、前記複数の仮想ストレージノードの各々に前記複数の実ストレージノードのいずれかを割り当てる第３の割り当て関係とに基づき、
    前記生成手段は、前記複数の実ストレージノードの数に変更があった場合、前記第２の割り当て関係と、前記変更に応じて更新された前記第３の割り当て関係に基づく前記第１の割り当て関係に基づいて、前記設定を生成する
    通信管理装置。
  2. 前記第１の割り当て関係は、前記識別子を、前記複数の実ストレージノードのうち２つ以上の実ストレージノードに割り当てる割り当てを含み、
    前記生成手段は、いずれかの前記通信機器の前記設定として、前記識別子が２つ以上の実ストレージノードに割り当てられた前記オブジェクトに対して、２つ以上の前記転送先を決定する前記第１のルールと、当該オブジェクトの数が前記転送先の数と同じになるよう当該オブジェクトを複製し、当該オブジェクトを前記転送先の各々に転送する第２のルールとを含む前記設定を生成する
    請求項１に記載の通信管理装置。
  3. 前記複数の実ストレージノードのいずれかに送信される前記オブジェクトを送信するためのパケットは、送信先のアドレスとして代表アドレスが付与され、
    前記生成手段は、パケットに送信先として付与されているアドレスが前記代表アドレスであるか否かに基づいて、前記パケットによる通信がオブジェクトへのアクセス用の通信であるか否かを判定し、付与されている前記アドレスが前記代表アドレスである場合に前記第１のルールに従って前記パケットにより転送される前記オブジェクトの前記転送先を決定し、付与されている前記アドレスが前記代表アドレスではない場合、オブジェクトのアクセス用以外の通信のための第４のルールに従って前記パケットの送信先を決定する第３のルールをさらに含む、前記設定を生成する
    請求項１又は２に記載の通信管理装置。
  4. 前記生成手段は、前記識別子の一部である使用部分に基づいて前記オブジェクトの転送先を決定する前記第１のルールを含む前記設定を、前記使用部分を前記複数の実ストレージノードのいずれかに割り当てる前記第１の割り当て関係に基づいて生成する
    請求項１乃至３のいずれかに記載の通信管理装置。
  5. 前記複数の仮想ストレージノードの数に基づいて前記識別子における前記使用部分を決定し、前記識別子を、前記使用部分に基づいて前記複数の仮想ストレージノードのいずれかに割り当てる前記第２の割り当て関係を決定し、当該第２の割り当て関係と、前記第３の割り当て関係とに基づいて、前記第１の割り当て関係を決定する決定手段
    を更に備える請求項４に記載の通信管理装置。
  6. 請求項１乃至５のいずれか１項に記載の通信管理装置と、
    前記設定に従って前記オブジェクトを転送する前記通信機器と、
    を含む通信システム。
  7. 請求項１乃至５のいずれかに記載の通信管理装置が生成した前記設定に従って、前記オブジェクトの転送先を決定する転送先決定手段と、
    前記オブジェクトを受信し、当該オブジェクトを前記転送先決定手段によって決定された前記転送先に送信する入出力手段と
    を備える通信装置。
  8. 複数の実ストレージノードのいずれかにオブジェクトを送信する経路における複数の通信機器の、前記オブジェクトに一意に付与される識別子に基づいて前記オブジェクトの転送先を決定する第１のルールを含む設定を、前記識別子を前記複数の実ストレージノードのいずれかに割り当てる第１の割り当て関係と、前記複数の通信機器及び前記複数の実ストレージノードの接続関係とに基づいて、前記複数の実ストレージノードの数に変更があった場合に生成し、
    前記通信機器に前記設定を適用する、
    前記第１の割り当て関係は、前記識別子を複数の仮想ストレージノードのいずれかに割り当てる第２の割り当て関係と、前記複数の仮想ストレージノードの各々を前記複数の実ストレージノードのいずれかに割り当てる第３の割り当て関係とに基づき、
    前記第３の割り当て関係は、前記複数の実ストレージノードの数の変更に応じて変更される
    通信管理方法。
  9. 前記第１の割り当て関係は、前記識別子を、前記複数の実ストレージノードのうち２つ以上の実ストレージノードに割り当てる割り当てを含み、
    いずれかの前記通信機器の前記設定として、前記識別子が２つ以上の実ストレージノードに割り当てられた前記オブジェクトに対して、２つ以上の前記転送先を決定する前記第１のルールと、当該オブジェクトの数が前記転送先の数と同じになるよう当該オブジェクトを複製し、当該オブジェクトを前記転送先の各々に転送する第２のルールとを含む前記設定を生成する
    請求項８に記載の通信管理方法。
  10. コンピュータに、
    複数の実ストレージノードのいずれかにオブジェクトを送信する経路における複数の通信機器の、前記オブジェクトに一意に付与される識別子に基づいて前記オブジェクトの転送先を決定する第１のルールを含む設定を、前記識別子を前記複数の実ストレージノードのいずれかに割り当てる第１の割り当て関係と、前記複数の通信機器及び前記複数の実ストレージノードの接続関係とに基づいて生成する生成処理と、
    前記通信機器に前記設定を適用する適用処理と、
    を実行させ、
    前記第１の割り当て関係は、前記識別子を複数の仮想ストレージノードのいずれかに割り当てる第２の割り当て関係と、前記複数の仮想ストレージノードの各々を前記複数の実ストレージノードのいずれかに割り当てる第３の割り当て関係とに基づき、
    前記生成処理は、前記複数の実ストレージノードの数に変更があった場合、前記第２の割り当て関係と、前記変更に応じて変更された前記第３の割り当て関係に基づく前記第１の割り当て関係に基づいて、前記設定を生成する
    プログラム。
JP2016073184A 2016-03-31 2016-03-31 通信管理装置、通信管理方法及びプログラム Active JP6677052B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2016073184A JP6677052B2 (ja) 2016-03-31 2016-03-31 通信管理装置、通信管理方法及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2016073184A JP6677052B2 (ja) 2016-03-31 2016-03-31 通信管理装置、通信管理方法及びプログラム

Publications (2)

Publication Number Publication Date
JP2017184195A JP2017184195A (ja) 2017-10-05
JP6677052B2 true JP6677052B2 (ja) 2020-04-08

Family

ID=60007305

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016073184A Active JP6677052B2 (ja) 2016-03-31 2016-03-31 通信管理装置、通信管理方法及びプログラム

Country Status (1)

Country Link
JP (1) JP6677052B2 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022038933A1 (ja) 2020-08-18 2022-02-24 富士フイルム株式会社 情報処理装置、情報処理方法及び情報処理プログラム
JPWO2022038935A1 (ja) 2020-08-21 2022-02-24

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4022117B2 (ja) * 2002-09-20 2007-12-12 富士通株式会社 負荷分散方法及びその装置
JP4995300B2 (ja) * 2010-04-20 2012-08-08 日本電信電話株式会社 サーバ選択制御装置、サービス要求装置、サーバ選択制御方法、サービス要求方法、サーバ選択制御プログラム、サービス要求プログラム、サービス提供システムおよびサービス提供方法
CN103250449B (zh) * 2010-12-02 2016-04-20 日本电气株式会社 通信系统、控制设备、通信方法和程序
EP2833584A4 (en) * 2012-03-30 2015-12-09 Nec Corp DISTRIBUTED STORAGE SYSTEM, CONTROL DEVICE, CLIENT TERMINAL AND LOAD DISTRIBUTION METHOD AND PROGRAM
JP5953991B2 (ja) * 2012-07-03 2016-07-20 富士通株式会社 通信制御方法、通信制御装置、通信機器、及びプログラム

Also Published As

Publication number Publication date
JP2017184195A (ja) 2017-10-05

Similar Documents

Publication Publication Date Title
US10649798B2 (en) Virtual switching method, related apparatus, and computer system
US11372802B2 (en) Virtual RDMA switching for containerized applications
Al-Shabibi et al. OpenVirteX: Make your virtual SDNs programmable
US9614930B2 (en) Virtual machine mobility using OpenFlow
US20190079897A1 (en) Remote direct memory access in computing systems
US7257817B2 (en) Virtual network with adaptive dispatcher
US8819211B2 (en) Distributed policy service
JP5621778B2 (ja) コンテンツベーススイッチシステム、及びコンテンツベーススイッチ方法
US7899047B2 (en) Virtual network with adaptive dispatcher
US8913613B2 (en) Method and system for classification and management of inter-blade network traffic in a blade server
US9548890B2 (en) Flexible remote direct memory access resource configuration in a network environment
CN105993161B (zh) 用于解析地址的元件、方法、系统和计算机可读存储设备
JP2020526122A (ja) データ処理方法、ネットワークインタフェースカード、及びサーバ
CN113439428A (zh) 操作具有dns高速缓存的装置的系统和方法
CN112887229B (zh) 一种会话信息同步方法及装置
WO2015006970A1 (zh) 交换设备、控制器、交换设备配置、报文处理方法及系统
JP6677052B2 (ja) 通信管理装置、通信管理方法及びプログラム
JP5609527B2 (ja) ネットワーク仮想化システム、ノード、ネットワーク仮想化方法、及び、ネットワーク仮想化プログラム
KR20210016802A (ko) 소프트웨어 정의 네트워킹 환경에서 서버-클라이언트 기반의 네트워크 서비스를 위한 플로우 테이블을 최적화하는 방법 및 이를 위한 sdn 스위치
KR20210070873A (ko) 패킷 복제 방법 및 장치
KR20220076826A (ko) Ndn 기반의 인-네트워크 처리 방법 및 시스템
Chung et al. P4mt: Designing and evaluating multi-tenant services for p4 switches
CN116195239A (zh) 通过分布式弹性中间盒提供模块化网络服务
JP2017146873A (ja) データ提供システム、データ提供方法、データ提供装置、更新対象装置及びコンピュータ・プログラム
Xue et al. Virtualization of table resources in programmable data plane with global consideration

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190215

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20191107

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20191119

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200117

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: 20200212

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20200225

R150 Certificate of patent or registration of utility model

Ref document number: 6677052

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150