(57)【特許請求の範囲】
【請求項１】
複数の実ストレージノードのいずれかにオブジェクトを送信する経路における複数の通信機器の、前記オブジェクトに一意に付与される識別子に基づいて前記オブジェクトの転送先を決定する第１のルールを含む設定を、前記識別子を前記複数の実ストレージノードのいずれかに割り当てる第１の割り当て関係と、前記複数の通信機器及び前記複数の実ストレージノードの接続関係とに基づいて生成する生成手段と、
前記通信機器に前記設定を適用する適用手段と、
を備え、
前記第１の割り当て関係は、前記識別子を複数の仮想ストレージノードのいずれかに割り当てる第２の割り当て関係と、前記複数の仮想ストレージノードの各々に前記複数の実ストレージノードのいずれかを割り当てる第３の割り当て関係とに基づき、
前記生成手段は、前記複数の実ストレージノードの数に変更があった場合、前記第２の割り当て関係と、前記変更に応じて更新された前記第３の割り当て関係に基づく前記第１の割り当て関係に基づいて、前記設定を生成する
通信管理装置。
【請求項２】
前記第１の割り当て関係は、前記識別子を、前記複数の実ストレージノードのうち２つ以上の実ストレージノードに割り当てる割り当てを含み、
前記生成手段は、いずれかの前記通信機器の前記設定として、前記識別子が２つ以上の実ストレージノードに割り当てられた前記オブジェクトに対して、２つ以上の前記転送先を決定する前記第１のルールと、当該オブジェクトの数が前記転送先の数と同じになるよう当該オブジェクトを複製し、当該オブジェクトを前記転送先の各々に転送する第２のルールとを含む前記設定を生成する
請求項１に記載の通信管理装置。
【請求項３】
前記複数の実ストレージノードのいずれかに送信される前記オブジェクトを送信するためのパケットは、送信先のアドレスとして代表アドレスが付与され、
前記生成手段は、パケットに送信先として付与されているアドレスが前記代表アドレスであるか否かに基づいて、前記パケットによる通信がオブジェクトへのアクセス用の通信であるか否かを判定し、付与されている前記アドレスが前記代表アドレスである場合に前記第１のルールに従って前記パケットにより転送される前記オブジェクトの前記転送先を決定し、付与されている前記アドレスが前記代表アドレスではない場合、オブジェクトのアクセス用以外の通信のための第４のルールに従って前記パケットの送信先を決定する第３のルールをさらに含む、前記設定を生成する
請求項１又は２に記載の通信管理装置。
【請求項４】
前記生成手段は、前記識別子の一部である使用部分に基づいて前記オブジェクトの転送先を決定する前記第１のルールを含む前記設定を、前記使用部分を前記複数の実ストレージノードのいずれかに割り当てる前記第１の割り当て関係に基づいて生成する
請求項１乃至３のいずれかに記載の通信管理装置。
【請求項５】
前記複数の仮想ストレージノードの数に基づいて前記識別子における前記使用部分を決定し、前記識別子を、前記使用部分に基づいて前記複数の仮想ストレージノードのいずれかに割り当てる前記第２の割り当て関係を決定し、当該第２の割り当て関係と、前記第３の割り当て関係とに基づいて、前記第１の割り当て関係を決定する決定手段
を更に備える請求項４に記載の通信管理装置。
【請求項６】
請求項１乃至５のいずれか１項に記載の通信管理装置と、
前記設定に従って前記オブジェクトを転送する前記通信機器と、
を含む通信システム。
【請求項７】
請求項１乃至５のいずれかに記載の通信管理装置が生成した前記設定に従って、前記オブジェクトの転送先を決定する転送先決定手段と、
前記オブジェクトを受信し、当該オブジェクトを前記転送先決定手段によって決定された前記転送先に送信する入出力手段と
を備える通信装置。
【請求項８】
複数の実ストレージノードのいずれかにオブジェクトを送信する経路における複数の通信機器の、前記オブジェクトに一意に付与される識別子に基づいて前記オブジェクトの転送先を決定する第１のルールを含む設定を、前記識別子を前記複数の実ストレージノードのいずれかに割り当てる第１の割り当て関係と、前記複数の通信機器及び前記複数の実ストレージノードの接続関係とに基づいて、前記複数の実ストレージノードの数に変更があった場合に生成し、
前記通信機器に前記設定を適用する、
前記第１の割り当て関係は、前記識別子を複数の仮想ストレージノードのいずれかに割り当てる第２の割り当て関係と、前記複数の仮想ストレージノードの各々を前記複数の実ストレージノードのいずれかに割り当てる第３の割り当て関係とに基づき、
前記第３の割り当て関係は、前記複数の実ストレージノードの数の変更に応じて変更される
通信管理方法。
【請求項９】
前記第１の割り当て関係は、前記識別子を、前記複数の実ストレージノードのうち２つ以上の実ストレージノードに割り当てる割り当てを含み、
いずれかの前記通信機器の前記設定として、前記識別子が２つ以上の実ストレージノードに割り当てられた前記オブジェクトに対して、２つ以上の前記転送先を決定する前記第１のルールと、当該オブジェクトの数が前記転送先の数と同じになるよう当該オブジェクトを複製し、当該オブジェクトを前記転送先の各々に転送する第２のルールとを含む前記設定を生成する
請求項８に記載の通信管理方法。
【請求項１０】
コンピュータに、
複数の実ストレージノードのいずれかにオブジェクトを送信する経路における複数の通信機器の、前記オブジェクトに一意に付与される識別子に基づいて前記オブジェクトの転送先を決定する第１のルールを含む設定を、前記識別子を前記複数の実ストレージノードのいずれかに割り当てる第１の割り当て関係と、前記複数の通信機器及び前記複数の実ストレージノードの接続関係とに基づいて生成する生成処理と、
前記通信機器に前記設定を適用する適用処理と、
を実行させ、
前記第１の割り当て関係は、前記識別子を複数の仮想ストレージノードのいずれかに割り当てる第２の割り当て関係と、前記複数の仮想ストレージノードの各々を前記複数の実ストレージノードのいずれかに割り当てる第３の割り当て関係とに基づき、
前記生成処理は、前記複数の実ストレージノードの数に変更があった場合、前記第２の割り当て関係と、前記変更に応じて変更された前記第３の割り当て関係に基づく前記第１の割り当て関係に基づいて、前記設定を生成する
プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、ネットワークを管理する技術に関する。
【背景技術】
【０００２】
分散ファイルシステム（以後、「分散ＦＳ」（Ｆｉｌｅ  Ｓｙｓｔｅｍ）と表記）や分散型オブジェクトストレージでは、ノード管理を行う必要がある。そのノード管理の方法として、（１）メタデータサーバを用いた中央集権的な管理手法、または、（２）システムに所属するノードそれぞれが算出アルゴリズムないし管理テーブルをもち、通信先を解決する管理手法が用いられてきた。
【０００３】
特許文献１乃至９には、ＯｐｅｎＦｌｏｗ（登録商標）に代表されるＳＤＮ（Ｓｏｆｔｗａｒｅ−Ｄｅｆｉｎｅｄ  Ｎｅｔｗｏｒｋ）及びパケットの転送に関連する技術が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１５−１５４２１０号公報
【特許文献２】特開２０１５−０９５７３０号公報
【特許文献３】特開２０１０−１０９７９１号公報
【特許文献４】特表２０１５−５３７７５４号公報
【特許文献５】特開２００３−１５３２３９号公報
【特許文献６】欧州特許出願公開第２７３１３０４号明細書
【特許文献７】欧州特許出願公開第２７８２３１２号明細書
【特許文献８】米国特許出願公開第２０１４／０２２９９４５号明細書
【特許文献９】米国特許出願公開第２０１４／０２６９２８８号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００５】
（１）の中央集権的な管理を行っている場合、管理を行う制御サーバに障害が発生すると、その障害の影響が全体に波及する問題がある。そのため、制御サーバを冗長化するなど対策を講じなければならない。また制御サーバへアクセスが集中し過ぎるので、制御サーバの性能がネックになることよって、分散ＦＳ又は分散オブジェクトストレージ全体で性能が出なくなるといった問題点もある。
【０００６】
（２）の分散管理型の手法では、システムに参加するノードがそれぞれのノードを把握しなければならない。この方法は、あるノードがダウンしても、残っているノードは動作を継続でき、システムとしては運用が継続できるメリットがある。しかし、参加ノードとオブジェクトの担当の把握を、それぞれのノードが行わなければならないので、ノード管理の負担が大きい。また、ノードの追加など、システムに参加するノードに変更が加わった場合に、管理情報が全体に伝わりきるまで時間がかかるという欠点が存在する。
【０００７】
本発明の目的の１つは、分散型ストレージにおける管理負荷を軽減しながら高速で柔軟な経路の切り替えをできる管理技術を提供することにある。
【課題を解決するための手段】
【０００８】
本発明の一態様に係る通信管理装置は、複数の実ストレージノードのいずれかにオブジェクトを送信する経路における複数の通信機器の、前記オブジェクトに一意に付与される識別子に基づいて前記オブジェクトの転送先を決定する第１のルールを含む設定を、前記識別子を前記複数の実ストレージノードのいずれかに割り当てる第１の割り当て関係と、前記複数の通信機器及び前記複数の実ストレージノードの接続関係とに基づいて生成する生成手段と、前記通信機器に前記設定を適用する適用手段と、を備える。
【０００９】
本発明の一態様に係る通信管理方法は、複数の実ストレージノードのいずれかにオブジェクトを送信する経路における複数の通信機器の、前記オブジェクトに一意に付与される識別子に基づいて前記オブジェクトの転送先を決定する第１のルールを含む設定を、前記識別子を前記複数の実ストレージノードのいずれかに割り当てる第１の割り当て関係と、前記複数の通信機器及び前記複数の実ストレージノードの接続関係とに基づいて生成し、前記通信機器に前記設定を適用する。
【００１０】
本発明の一態様に係るプログラムは、コンピュータに、複数の実ストレージノードのいずれかにオブジェクトを送信する経路における複数の通信機器の、前記オブジェクトに一意に付与される識別子に基づいて前記オブジェクトの転送先を決定する第１のルールを含む設定を、前記識別子を前記複数の実ストレージノードのいずれかに割り当てる第１の割り当て関係と、前記複数の通信機器及び前記複数の実ストレージノードの接続関係とに基づいて生成する生成処理と、前記通信機器に前記設定を適用する適用処理と、を実行させる。
【発明の効果】
【００１１】
本発明によると、分散型ストレージにおける管理負荷を軽減しながら高速で柔軟な経路の切り替えをできるという効果がある。
【図面の簡単な説明】
【００１２】
【図１】図１は、本発明の第１の実施形態に係る分散ストレージシステムの構成を表す図である。
【図２】図２は、本発明の第１の実施形態に係る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
１０００    コンピュータ
１００１    プロセッサ
１００２    メモリ
１００３    記憶装置
１００４    Ｉ／Ｏインタフェース
１００５    記録媒体
【図１】
0006677052.tif 000002
【図２】
0006677052.tif 000003
【図３】
0006677052.tif 000004
【図４】
0006677052.tif 000005
【図５】
0006677052.tif 000006
【図６】
0006677052.tif 000007
【図７】
0006677052.tif 000008
【図８】
0006677052.tif 000009
【図９】
0006677052.tif 000010
【図１０】
0006677052.tif 000011
【図１１】
0006677052.tif 000012
【図１２】
0006677052.tif 000013
【図１３】
0006677052.tif 000014
【図１４】
0006677052.tif 000015
【図１５】
0006677052.tif 000016
【図１６】
0006677052.tif 000017
【図１７】
0006677052.tif 000018
【図１８】
0006677052.tif 000019
【図１９】
0006677052.tif 000020
【図２０】
0006677052.tif 000021
【図２１】
0006677052.tif 000022
【図２２】
0006677052.tif 000023
【図２３】
0006677052.tif 000024
【図２４】
0006677052.tif 000025
【図２５】
0006677052.tif 000026
【図２６】
0006677052.tif 000027
【図２７】
0006677052.tif 000028
【図２８】
0006677052.tif 000029
【図２９】
0006677052.tif 000030