JP7367873B2

JP7367873B2 - データノード、データノード管理方法、および、データノード管理プログラム

Info

Publication number: JP7367873B2
Application number: JP2022532230A
Authority: JP
Inventors: 公利齋藤; 崇佳平澤
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2020-06-26
Filing date: 2020-06-26
Publication date: 2023-10-24
Anticipated expiration: 2040-06-26
Also published as: JPWO2021260948A1; WO2021260948A1; US20230262149A1

Description

本発明は、データノード、データノード管理方法、および、データノード管理プログラムに関する。

スイッチなどの通信装置は、通信装置に搭載されるハードウェアと、そのハードウェア上で動作するNOS（Network Operating System）などのソフトウェアが統合された状態で、従来は販売されていた。つまり、通信装置内の実装の内容は使用者には隠蔽（ブラックボックス化）されていた。
一方、通信装置に対して使用者が自由に機能を追加したいというニーズがある。そこで、ASIC（Application Specific Integrated Circuit）をハードウェアとして搭載する通信装置上で動作するソフトウェアを、使用者が自由に開発できるようにしたホワイトボックス機器が提案されている。

図８は、ホワイトボックス機器７０１の一例を示すブロック図である。
ホワイトボックス機器７０１は、図面下側から順に、斜線を付した四角で示す６本の通信ポートである物理層（PHY）と、それらのPHYを束ねて転送処理を高速に行うASICと、そのASICに対して転送制御を行うNOSとが備えられている。

非特許文献１には、通信装置上で動作する１つのVM（Virtual Machine）に対して、通信装置内のハードウェアであるデータプレーンを１つ以上紐付ける「Node Slicing」が記載されている。同じ通信装置上に複数のVMを冗長構成として動作させることで、１つのVMが故障しても他のVMが代替し、ソフトウェア故障時の信頼性を高める。

ジュニパーネットワークス、「ジュニパーネットワークス, "Node Slicingとは」、［online］、［2020年5月27日検索］、インターネット〈URL：https://www.juniper.net/jp/jp/products-services/what-is/node-slicing/〉

非特許文献１では、複数のハードウェア資源を１つのソフトウェア（VM）に使用させるための技術を説明した。一方、１つのハードウェア資源を複数のソフトウェア（NOS）に共用させたいニーズもある。
例えば、単一のASICを複数のNOSで共有してマウント（紐付け）することで、ASICをNOS単位にリソース分割し、ASICのリソース効率を高めるユースケースを検討する。

図９は、図８のホワイトボックス機器をリソース分割したときのブロック図である。
機能ごとの論理単位でリソース分割をする例として、ホワイトボックス機器７０２は、L3VPN（Layer 3 Virtual Private Network）が動作する論理単位７０２Ａと、L2VPN（Layer 2 Virtual Private Network）が動作する論理単位７０２Ｂとで同じASICを共用する構成である。

用途ごとの論理単位でリソース分割をする例として、ホワイトボックス機器７０３は、会社の第１部署が使用する論理単位７０３Ａと、会社の第２部署が使用する論理単位７０３Ｂと、会社の第３部署が使用する論理単位７０３Ｃとで同じASICを共用する構成である。または、実験網ごとの論理単位でリソース分割をする場合も挙げられる。
このように、個別の論理単位では処理負荷が軽量である場合には、１台のホワイトボックス機器７０２，７０３に統合することで、論理単位ごとに専用の物理装置を用意する方式よりもコストを削減できる。

図１０は、図９のリソース分割における問題点を示すブロック図である。
論理単位７０３ＡのNOSは、ユーザＡの経路「0.0.0.1」の通知を受け、その経路の転送先として自身のポート情報（図１０の左から２番目のPHY）を対応づけるように経路制御表（FIB：Forwarding Information Base）に書き込み命令を呼び出す。
論理単位７０３ＣのNOSは、ユーザＣの経路「0.0.0.1」の通知を受け、その経路の転送先として自身のポート情報（図１０の左から５番目のPHY）を対応づけるようにFIBに書き込み命令を呼び出す。なお、ユーザＡとユーザＣとは別のユーザであり、偶然に同じ経路「0.0.0.1」を用いている。

ここで、ASICは、両NOSからの命令を受け、そのままFIBに経路「0.0.0.1」を書き出してしまうと、最初に書き出した経路「0.0.0.1」→「左から２番目のPHY」が、次に書き出した経路「0.0.0.1」→「左から５番目のPHY」により上書きされ、消失してしまう。
この消失が発生するのは、既存のNOSが、ハードウェアのリソースを分割して他のNOSとリソースを共用するように設計されていないためである。なお、NOS自体にリソースを共用する拡張を行うことは運用上大きな負担となるので、拡張はNOS以外に施す必要がある。

そこで、本発明は、データノードのハードウェア資源をリソース分割し、複数のNOSによって制御可能とすることを主な課題とする。

前記課題を解決するために、本発明のデータノードは、以下の特徴を有する。
本発明は、転送先を示すＦＩＢを参照してデータを転送するハードウェア層と、前記ハードウェア層に対して前記ＦＩＢの内容を設定する複数のＮＯＳとの間でメッセージを仲介するブリッジ層を備えており、
前記ブリッジ層が、
前記各ＮＯＳが使用可能な前記ハードウェア層のリソースを対応づける設定情報が格納される設定格納部と、
前記各ＮＯＳから前記ＦＩＢの内容を設定するメッセージを受け、前記設定格納部の設定情報に従い、前記各ＮＯＳが使用可能な前記ハードウェア層のリソースを含むようにメッセージを変換してから、変換後のメッセージをもとに前記ＦＩＢの内容を更新させるメッセージ処理部とを有することを特徴とする。

本発明によれば、データノードのハードウェア資源をリソース分割し、複数のNOSによって制御可能とすることができる。

本実施形態に係わるデータノードの概要を示す構成図である。本実施形態に係わるデータノードのハードウェア構成図である。本実施形態に係わる図１に示したデータノードの詳細を示す構成図である。本実施形態に係わるデータノードの処理を示すシーケンス図である。本実施形態に係わるデータノードの処理を示すシーケンス図である。本実施形態に係わる設定格納部の第１例を示す構成図である。本実施形態に係わる設定格納部の第２例を示す構成図である。ホワイトボックス機器の一例を示すブロック図である。図８のホワイトボックス機器をリソース分割したときのブロック図である。図９のリソース分割における問題点を示すブロック図である。

以下、本発明の一実施形態について、図面を参照して詳細に説明する。

図１は、データノード１００の概要を示す構成図である。
図１のデータノード１００は、図１０と同様に、論理単位１００Ａ，１００Ｂ，１００Ｃにリソース分割が可能である。なお、リソースの分割数は、図１の３つに限定されない。そのため、データノード１００は、複数のＮＯＳ１０（論理単位ごとのＮＯＳ１０Ａ，１０Ｂ，１０Ｃ）と、ＡＳＩＣ処理部４１と、斜線を付した四角で示す６本の通信ポートである物理層（PHY）と、ＦＩＢ４３とを有する。

一方、図１のデータノード１００は、新たに、ブリッジ層２０がＮＯＳ１０とＡＳＩＣ処理部４１との間にコンポーネントとして配備されている。ブリッジ層２０は、複数のＮＯＳ１０間でＦＩＢ４３に書き出すリソース情報（「２番ポート」などのポート情報、「0.0.0.1」などのルーティング情報など）が、互いに衝突しないように、ＦＩＢ４３に書き出すリソース情報を適宜メッセージ変換する。
これにより、各ＮＯＳ１０が他のＮＯＳ１０の挙動を知らなくても、データノード１００のハードウェア資源をあたかも自身が専有しているかのように動作することができる。

なお、ブリッジ層２０は、１バックグランドプログラムやコンテナ等で実装される。またＮＯＳ１０、ブリッジ層２０は、データノード１００（ホワイトボックススイッチ）内に構築してもよいし、データノード１００とは別装置である外部サーバに構築してもよい。
そして、ＡＳＩＣ処理部４１の制御用ドライバは、例えば、OFDPA Pipeline modelなどの公開されている仕様を元に実装される。例えば、OFDPA Pipeline modelの「vrf table」は、ルーティング情報を分割するために活用できる。

図２は、データノード１００のハードウェア構成図である。
データノード１００は、ＣＰＵ９０１と、ＲＡＭ９０２と、ＲＯＭ９０３と、ＨＤＤ９０４と、通信Ｉ／Ｆ９０５と、入出力Ｉ／Ｆ９０６と、メディアＩ／Ｆ９０７とを有するコンピュータ９００として構成される。
通信Ｉ／Ｆ９０５は、外部の通信装置９１５と接続される。入出力Ｉ／Ｆ９０６は、入出力装置９１６と接続される。メディアＩ／Ｆ９０７は、記録媒体９１７からデータを読み書きする。さらに、ＣＰＵ９０１は、ＲＡＭ９０２に読み込んだプログラム（アプリケーションや、その略のアプリとも呼ばれる）を実行することにより、各処理部を制御する。そして、このプログラムは、通信回線を介して配布したり、ＣＤ－ＲＯＭ等の記録媒体９１７に記録して配布したりすることも可能である。

図３は、図１に示したデータノード１００の詳細を示す構成図である。
データノード１００は、経路管理などを行うソフトウェアの処理部として、複数のＮＯＳ１０と、ブリッジ層２０と、ＡＳＩＣ側インタフェース３１と、ＡＳＩＣ制御部３２と、ハードウェア層４０とを有する。
各ＮＯＳ１０は、ＲＩＢ（Routing Information Base）１１と、ＡＰＩコール部１２とを有する。さらに、各ＮＯＳ１０には、図示省略したルーティングエンジン（経路演算部）と、CLI（Command Line Interface）やNetconfなどの設定投入用UI（User Interface）も有する。
ブリッジ層２０は、ＯＳ側インタフェース２１と、メッセージ変換部（メッセージ処理部）２２と、ＡＰＩ呼出部２３と、設定格納部２４とを有する。
データノード１００は、データ転送を行うハードウェア層４０として、ＡＳＩＣ処理部４１と、ＰＨＹ４２と、ＦＩＢ４３とを有する。

ＮＯＳ１０のインストール方法は、基本的には、各ＮＯＳ１０が推奨する方法に準拠すればよい。一方、従来のインストール時にはＡＳＩＣ側インタフェース３１を参照するように設定するが、本実施形態のデータノード１００のインストール時にはＯＳ側インタフェース２１を参照するように、ＮＯＳ１０の参照先アドレス、ポート情報などを設定する。

図４のシーケンス図を適宜参照しながら、図３の構成要素を明らかにする。
ＮＯＳ１０のＲＩＢ１１には、ＮＯＳ１０上で動作するBGP（Border Gateway Protocol）などのルーティングプロトコルにより計算されたルーティングの情報が格納される。ＲＩＢ１１内のルーティングの情報は、ネットワークトポロジの変化に伴い、適宜更新される（Ｓ１１）。
ＡＰＩコール部１２は、ＲＩＢ１１に格納されている最新のルーティングの情報を自身のＡＳＩＣ処理部４１の転送処理に反映させるため、ＦＩＢ４３への書き込み処理を依頼するためのＡＰＩコールをＯＳ側インタフェース２１に通知する（Ｓ１２）。

ＯＳ側インタフェース２１は、各ＮＯＳ１０のＡＰＩコール部１２からのＡＰＩコールを受け、メッセージ変換部２２にＡＰＩコールをメッセージ伝搬する（Ｓ１３）。メッセージ変換部２２は、Ｓ１６で後記するメッセージ変換において参照されるリソース情報（詳細は、図６のポート情報、I/F情報など）を設定格納部２４に要求し（Ｓ１４）、その回答を得る（Ｓ１５）。設定格納部２４には、リソース情報が、設定ファイルまたはデータベースとして格納される。
そして、メッセージ変換部２２は、Ｓ１３で伝搬されたＡＰＩコールが示すＦＩＢ４３に書き出すリソース情報が、ＮＯＳ１０どうしで衝突しないように、ＦＩＢ４３に書き出すリソース情報を適宜メッセージ変換する（Ｓ１６）。

図５のシーケンス図を適宜参照しながら、図３の構成要素を明らかにする。
メッセージ変換部２２は、Ｓ１６で変換したメッセージ（ＡＰＩコール）をＡＰＩ呼出部２３に伝搬する（Ｓ２１）。
ＡＰＩ呼出部２３は、Ｓ２１のメッセージ（あるＮＯＳ１０からのＡＰＩコール）を、他のＮＯＳ１０からのＡＰＩコールとコンフリクトしないように、待ち合わせ処理を行ってから（Ｓ２２）、ＡＳＩＣ側インタフェース３１にＡＰＩコールを通知する（Ｓ２３）。

つまり、ＡＰＩ呼出部２３は、ＡＳＩＣ側インタフェース３１に対して、同時に１つのメッセージだけを処理させるように、複数のメッセージを順番に待ち合わせる。
例えば、ＡＰＩ呼出部２３は、ＮＯＳ１０ＡからのメッセージをＡＳＩＣ側インタフェース３１に通知した後、そのメッセージへの応答がＡＳＩＣ側インタフェース３１から戻ってきた後に、ＮＯＳ１０ＢからのメッセージをＡＳＩＣ側インタフェース３１に通知する。

図３に戻り、ＡＳＩＣ側インタフェース３１は、ＡＳＩＣ制御部３２を利用するためのミドルウェアであり、通信機器ベンダ独自のSDK（Software Development Kit）や、オープンに使用可能なAPI（Application Programming Interface）として提供される。例えば、以下のAPIが公開されている。
・OF-DPA（OpenFlow Data Plane Abstraction）
・Open NSL（Network Switch Layer）
・SAI（Switch Abstraction Interface）
ＡＳＩＣ制御部３２は、ハードウェア層４０に依存した制御用ドライバであり、通信機器ベンダにより提供される。
ＡＳＩＣ処理部４１は、ＦＩＢ４３に記載された内容に従って、ＰＨＹ４２を介して外部の装置との間で、ハードウェアによるパケットの高速伝送（フォワーディング）を行う。なお、各ＰＨＹ４２には、ポート番号（0/0/0～0/0/5）が割り当てられている。

Ｓ２３でＡＳＩＣ側インタフェース３１に通知されたＡＰＩコールは、ＡＳＩＣ制御部３２→ＡＳＩＣ処理部４１→ＦＩＢ４３に通知されることで、ＦＩＢ４３の内容が書き換わる。
これにより、ＡＳＩＣ処理部４１は、最新のＦＩＢ４３を参照して得た適切なポートを介して、他装置との間でデータパケットを送受信できる。また、ＡＳＩＣ処理部４１は、他装置からＲＩＢ１１を更新するための制御系パケット（ルーティングプロトコルのリンクステートなど）を受け、最新のＦＩＢ４３を参照して自装置の各ＮＯＳ１０のうちの適切なＮＯＳ１０に向けて転送できる。

図６は、設定格納部２４の第１例を示す構成図である。
設定格納部２４には、ＮＯＳ１０の識別子（ID,Name）ごとに、利用するＰＨＹ４２のポート情報のリスト（Port）と、ＦＩＢ４３にデータを書き込むときに利用するＡＳＩＣ側インタフェース３１（I/F）とが対応づけられている。なお、図示しないがＮＯＳ１０が利用するリソース情報として、ポート情報の他にルーティング情報（図１の経路0.0.0.1など）なども対応づけられていてもよい。
このように、あらかじめ利用するＡＳＩＣ側インタフェース３１や利用するＰＨＹ４２をＮＯＳ１０ごとに分離して設定格納部２４に登録しておくことで、複数のＮＯＳ１０が同じＡＳＩＣ処理部４１を並列的に利用しつつ、個別のＰＨＹ４２を利用できる。

以下、メッセージ変換部２２が、ＮＯＳ１０ＣからのＡＰＩコールを受信したときの、リソース情報の重複を避けるためのメッセージ変換処理（Ｓ１６）の一例を説明する。
まず、ＮＯＳ１０Ｃが設定格納部２４に登録されているＮＯＳ１０Ｃのポート情報（Port＝0/0/4、0/0/5）を知っている場合を考える。このとき、ＮＯＳ１０Ｃから受信するＡＰＩコールに、「Port＝0/0/4、0/0/5」以外のポートが指定されることはＮＯＳ１０Ｃ側の誤りである。よって、メッセージ変換部２２は、誤ったＡＰＩコールを拒否すればよい。

一方、ＮＯＳ１０Ｃが設定格納部２４のポート情報（Port＝0/0/4、0/0/5）を知らない場合には、メッセージ変換部２２は、ＮＯＳ１０Ｃから受信したＡＰＩコールの「Port＝0/0/4、0/0/5」以外のポートを、以下のように変換すればよい。
・変換前「Port＝0/0/0」→変換後「Port＝0/0/4」
・変換前「Port＝0/0/1」→変換後「Port＝0/0/5」

以下に、変換前のＦＩＢ４３（VLANテーブル）のエントリの一例を示す。
Table ID 10 (VLAN):
-- inPort = 0(Physical) vlanId:mask = 0x0000:0x1fff (VLAN 0) | GoTo =20 …
-- inPort = 1(Physical) vlanId:mask = 0x0000:0x1fff (VLAN 0) | GoTo =20 …

以下に、変換後のＦＩＢ４３（VLANテーブル）のエントリの一例を示す。
Table ID 10 (VLAN):
-- inPort = 4(Physical) vlanId:mask = 0x0000:0x1fff (VLAN 0) | GoTo =20 …
-- inPort = 5(Physical) vlanId:mask = 0x0000:0x1fff (VLAN 0) | GoTo =20 …
「(Physical)」の前の数字がポート番号（Port＝0/0/NのNに該当）である。

また、メッセージ変換部２２は、ルーティング情報の変換も行ってもよい。以下では、設定格納部２４のID列に記載の番号をそのままＦＩＢ４３のvrfフィールドに書き込む一例を示す。
以下に、変換前のvrfフィールドの一例を示す。
Table ID 30 (Unicast Routing):
-- etherType = 0x0800 vrf = 0x0000 dstIp4 = 100.100.0.0/255.255.255.252 | GoTo = 60

以下に、変換後のvrfフィールドの一例を示す。
Table ID 30 (Unicast Routing):
-- etherType = 0x0800 vrf = 0x0003 dstIp4 = 100.100.0.0/255.255.255.252 | GoTo = 60
「vrf = 0x0003」の１桁目「3」が、ＮＯＳ１０Ｃに対応する設定格納部２４のID列「3」と同じになるように、ルーティング情報が変換されている。

図７は、設定格納部２４の第２例を示す構成図である。
ここでは、２つのＮＯＳ１０（ＮＯＳ１０Ａ、ＮＯＳ１０Ｂ）がインストールされ、４つのポート情報（Port＝0/0/0～0/0/3）を使用する設定格納部２４Ｂの例を説明する。
新たに５つめのポート情報（Port＝0/0/4）が増設されると、メッセージ変換部２２は、Ｓ１４で設定格納部２４に要求する処理として、負荷が高いＮＯＳ１０Ａに対して、新たにPort＝0/0/4を追加する。これにより、設定格納部２４Ｂから設定格納部２４Ｃに更新される。
また、メッセージ変換部２２は、ポートの減設時も同様に、設定格納部２４内のPort列の更新により対応すればよい。

［効果］
本発明のデータノード１００は、転送先を示すＦＩＢ４３を参照してデータを転送するハードウェア層４０と、ハードウェア層４０に対してＦＩＢ４３の内容を設定する複数のＮＯＳ１０との間でメッセージを仲介するブリッジ層２０を備えており、
ブリッジ層２０が、
各ＮＯＳ１０が使用可能なハードウェア層４０のリソースを対応づける設定情報が格納される設定格納部２４と、
各ＮＯＳ１０からＦＩＢ４３の内容を設定するメッセージを受け、設定格納部２４の設定情報に従い、各ＮＯＳ１０が使用可能なハードウェア層４０のリソースを含むようにメッセージを変換してから、変換後のメッセージをもとにＦＩＢ４３の内容を更新させるメッセージ変換部２２とを有することを特徴とする。

これにより、ブリッジ層２０において、ハードウェア層４０に対するメッセージのやり取りを仲介することにより、複数のＮＯＳ１０におけるＲＩＢ１１変更時のＦＩＢ４３への書込処理について、複数のＮＯＳ１０間でのリソース競合を回避する。
よって、ＮＯＳ１０、ハードウェア層４０への機能追加なしに、１台のホワイトボックス機器（データノード１００）に対して同時並列的に複数ＮＯＳ１０を利用できるので、単一のハードウェア層４０のリソースの利用効率を向上できる。

本発明は、転送先を示すＦＩＢ４３を参照してデータを転送するハードウェア層４０と、ハードウェア層４０に対してＦＩＢ４３の内容を設定する複数のＮＯＳ１０との間でメッセージを仲介するブリッジ層２０を備えており、
ブリッジ層２０が、
各ＮＯＳ１０が使用可能なハードウェア層４０のリソースを対応づける設定情報が格納される設定格納部２４と、
各ＮＯＳ１０からＦＩＢ４３の内容を設定するメッセージを受け、設定格納部２４の設定情報において、ＮＯＳ１０が使用可能ではないハードウェア層４０のリソースを含むメッセージを拒否する一方で、ＮＯＳ１０が使用可能なハードウェア層４０のリソースを含むメッセージをもとにＦＩＢ４３の内容を更新させるメッセージ変換部２２とを有することを特徴とする。

これにより、複数のＮＯＳ１０がそれぞれ使用可能なハードウェア層４０のリソースを制限することで、ＦＩＢ４３への書込処理について、複数のＮＯＳ１０間でのリソース競合を回避できる。

本発明は、データノード１００が、さらに、ＡＰＩ呼出部２３を備えており、
ＡＰＩ呼出部２３が、ＮＯＳ１０が使用可能なハードウェア層４０のリソースを含むメッセージをハードウェア層４０に送信してＦＩＢ４３の内容を更新させる処理について、一方のＮＯＳ１０からのメッセージが完了するまで、他方のＮＯＳ１０からのメッセージの送信を待ちあわせることを特徴とする。

これにより、ＦＩＢ４３に書き込む処理中のコンフリクト（書込み処理衝突）を回避できる。

１０ＮＯＳ
１１ＲＩＢ
１２ＡＰＩコール部
２０ブリッジ層
２１ＯＳ側インタフェース
２２メッセージ変換部（メッセージ処理部）
２３ＡＰＩ呼出部
２４設定格納部
３１ＡＳＩＣ側インタフェース
３２ＡＳＩＣ制御部
４０ハードウェア層
４１ＡＳＩＣ処理部
４２ＰＨＹ
４３ＦＩＢ
１００データノード

Claims

転送先を示すＦＩＢ（Forwarding Information Base）を参照してデータを転送するハードウェア層と、前記ハードウェア層に対して前記ＦＩＢの内容を設定する複数のＮＯＳ（Network Operating System）との間でメッセージを仲介するブリッジ層を備えており、
前記ブリッジ層は、
前記各ＮＯＳが使用可能な前記ハードウェア層のリソースを対応づける設定情報が格納される設定格納部と、
前記各ＮＯＳから前記ＦＩＢの内容を設定するメッセージを受け、前記設定格納部の設定情報に従い、前記各ＮＯＳが使用可能な前記ハードウェア層のリソースを含むようにメッセージを変換してから、変換後のメッセージをもとに前記ＦＩＢの内容を更新させるメッセージ処理部とを有することを特徴とする
データノード。
転送先を示すＦＩＢを参照してデータを転送するハードウェア層と、前記ハードウェア層に対して前記ＦＩＢの内容を設定する複数のＮＯＳとの間でメッセージを仲介するブリッジ層を備えており、
前記ブリッジ層は、
前記各ＮＯＳが使用可能な前記ハードウェア層のリソースを対応づける設定情報が格納される設定格納部と、
前記各ＮＯＳから前記ＦＩＢの内容を設定するメッセージを受け、前記設定格納部の設定情報において、前記ＮＯＳが使用不可能な前記ハードウェア層のリソースを含むメッセージを拒否する一方で、前記ＮＯＳが使用可能な前記ハードウェア層のリソースを含むメッセージをもとに前記ＦＩＢの内容を更新させるメッセージ処理部とを有することを特徴とする
データノード。
前記データノードは、さらに、ＡＰＩ呼出部を備えており、
前記ＡＰＩ呼出部は、前記ＮＯＳが使用可能な前記ハードウェア層のリソースを含むメッセージを前記ハードウェア層に送信して前記ＦＩＢの内容を更新させる処理について、一方の前記ＮＯＳからのメッセージが完了するまで、他方の前記ＮＯＳからのメッセージの送信を待ちあわせることを特徴とする
請求項１または請求項２に記載のデータノード。
データノードは、転送先を示すＦＩＢを参照してデータを転送するハードウェア層と、前記ハードウェア層に対して前記ＦＩＢの内容を設定する複数のＮＯＳとの間でメッセージを仲介するブリッジ層を備えており、
前記ブリッジ層は、設定格納部と、メッセージ処理部とを有しており、
前記設定格納部には、前記各ＮＯＳが使用可能な前記ハードウェア層のリソースを対応づける設定情報が格納され、
前記メッセージ処理部は、前記各ＮＯＳから前記ＦＩＢの内容を設定するメッセージを受け、前記設定格納部の設定情報に従い、前記各ＮＯＳが使用可能な前記ハードウェア層のリソースを含むようにメッセージを変換してから、変換後のメッセージをもとに前記ＦＩＢの内容を更新させることを特徴とする
データノード管理方法。
データノードは、転送先を示すＦＩＢを参照してデータを転送するハードウェア層と、前記ハードウェア層に対して前記ＦＩＢの内容を設定する複数のＮＯＳとの間でメッセージを仲介するブリッジ層を備えており、
前記ブリッジ層は、設定格納部と、メッセージ処理部とを有しており、
前記設定格納部には、前記各ＮＯＳが使用可能な前記ハードウェア層のリソースを対応づける設定情報が格納され、
前記メッセージ処理部は、前記各ＮＯＳから前記ＦＩＢの内容を設定するメッセージを受け、前記設定格納部の設定情報において、前記ＮＯＳが使用不可能な前記ハードウェア層のリソースを含むメッセージを拒否する一方で、前記ＮＯＳが使用可能な前記ハードウェア層のリソースを含むメッセージをもとに前記ＦＩＢの内容を更新させることを特徴とする
データノード管理方法。
コンピュータを、請求項１ないし請求項３のいずれか１項に記載のデータノードとして機能させるためのデータノード管理プログラム。