JP2014235531A - データ転送装置、データ転送システム、およびプログラム - Google Patents

Abstract

【課題】メモリ使用量の増大を抑制しつつ、ストレージの大記憶容量と高速応答を実現する。【解決手段】本実施形態としてのデータ転送装置は、 ネットワークを介して通信装置と所定のプロトコルにしたがって通信するデータ転送装置であって、書き込み制御部と、送信制御部とを備える。書き込み制御部は、第1データを含む第１応答メッセージを、ストレージに書き込む制御を行う。前記送信制御部は、 前記通信装置と同じまたは異なる第１通信装置から、前記第１データのデータ取得要求メッセージが受信されたとき、前記ストレージから前記第１応答メッセージを読み出して、前記第１応答メッセージを前記第１通信装置へ送信する制御を行う。【選択図】図２

Description

本発明の実施形態は、データ転送装置、データ転送システム、およびプログラムに関する。

従来のサーバには、ストレージ上にファイルとしてデータを記憶し、クライアントからの要求に応じて、データをストレージから読み出して送信し、またデータをストレージに書き込むものがあった。この場合、頻繁にアクセスされるデータについては、ＤＲＡＭ（Dynamic Random Access Memory）に配置することで、高速応答を実現することができるが、大記憶容量で高速応答を実現するには、多量のＤＲＡＭを要するという問題があった。

特開２００２−９９４６５号公報

本発明の実施形態は、メモリ使用量の増大を抑制しつつ、記憶容量の大容量化と、データの高速応答を実現することを目的とする。

本発明の実施形態としてのデータ転送装置は、ネットワークを介して通信装置と所定のプロトコルにしたがって通信するデータ転送装置であって、書き込み制御部と、送信制御部とを備える。書き込み制御部は、第1データを含むデータ保存要求メッセ―ジを元に生成された前記第1データを含む第１応答メッセージを、ストレージに書き込む制御を行う。前記送信制御部は、前記通信装置と同じまたは異なる第１通信装置から、前記第１データのデータ取得要求メッセージが受信されたとき、前記ストレージから前記第１応答メッセージを読み出して、前記第１応答メッセージを前記第１通信装置へ送信する制御を行う。

本発明の実施形態に係るデータ転送システムの全体構成を示す。 キャッシュサーバの構成を示す。 データ保持構造体の例を示す。 データ保持管理表（ハッシュ表）を示す。 データ保持構造体の未使用管理表を示す。 GET要求を受信した場合の処理シーケンスを示す。 GET要求メッセージの構成を示す。 応答データを格納する様子を示す。 応答データの形式の例を示す。 SET要求メッセージを受信したときの処理のシーケンスを示す。 未使用のデータ保持構造体を特定する例を示す。 データ保持構造体を未使用管理表から取り出して、データ保持管理表に追加する例を示す。 応答データのフラッシュ前に、次のGET要求が到着した場合のシーケンスを示す。 キャッシュプロトコルメッセージの他の例を示す。 データ保持構造体の拡張構造の例を示す。

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

図１は、本実施形態に係るデータ転送装置を含むキャッシュサーバと、キャッシュアクセスクライアント（以下、クライアント）とを備えたデータ転送システムの全体構成を示す。

キャッシュサーバ１０１とクライアント２０１はネットワーク３０１により接続されている。クライアントは１台のみ示しているが、複数台のクライアントがネットワーク３０１に接続されていてもよい。

本実施形態ではネットワーク３０１は、例えばＥｔｈｅｒｎｅｔ（登録商標）のようなＬＡＮを想定するが、方式はなんでも構わない。またネットワーク３０１は、ＬＡＮに限定されず、ワイドエリアネットワークでも、インターネットでもよい。また、ネットワークは、有線でも無線でもよい。

クライアント２０１は、キャッシュサーバ１０１が定めた手順（キャッシュプロトコル）で、キャッシュサーバ１０１とメッセージを送受信する通信クライアント装置である。キャッシュサーバ１０１は、データを記憶するストレージを有する。本実施形態では、ストレージは、キャッシュプロトコルの応答メッセージの形式でデータを記憶することを特徴の１つとしている。

キャッシュサーバ１０１は、クライアント２０１から保存対象としてのデータを含むデータ保存要求メッセージを受けると、当該データを含む応答メッセージ（応答データ）を作成して、当該応答データをストレージに保存する。キャッシュサーバ１０１は、クライアント２０１からデータ取得要求メッセージを受けると、当該取得要求されたデータを含む応答データをストレージから読み出す。キャッシュサーバ１０１は、読み出した応答データにヘッダを付加してパケットを構成し、当該パケットをクライアント２０１に送信する。取得要求を受けた際に応答メッセージを作成する必要はなく、事前に作成した応答メッセージ（応答データ）をストレージから読み出してヘッダを付加して送信すればよいため、大容量化しても、高速な応答が可能となる。なお、データの保存要求を行ったクライアントと、当該データの取得要求を行うクライアントは同じである場合、異なる場合どちらもあり得る。

ここで、本実施形態では、キャッシュサーバ１０１は、キーと、バリューを対応させた記憶方法をとるものとする。このため、キャッシュサーバ１０１を、キーバリューストア（ＫＶＳ）サーバと呼び、クライアント２０１は、ＫＶＳクライアントと呼ぶ場合もある。

図２の下に、キャッシュサーバ１０１におけるデータ転送装置のハードウェア構成図を示す。図２の上に、キャッシュサーバ１０１のＣＰＵにより実行されるソフトウェアによる機能ブロック構成を示す。

図２の下に示すように、キャッシュサーバ１０１は、データ転送装置とＳＡＴＡ（Serial Advanced Technology Attachment）ストレージ１２とを備える。データ転送装置は、直接送信ＨＷ(HardWare)部（送信装置）１１、ＣＰＵ３１、メインメモリ３２、バスブリッジ部３３を備える。ＣＰＵ３１、メインメモリ３２は一般的なものである。バスブリッジ部３３は、例えばＰＣＩ Ｅｘｐｒｅｓｓのような多種多様なデバイスを接続するバスであれば、方式はなんでも構わない。

図２の上の機能ブロック図は、ＣＰＵ３１によりＯＳ（オペレーティングシステム）４１と、ＯＳ４１上で動作するアプリケーション５１が実行されることにより実現される機能ブロック図である。ソフトウェアは、図示しない記憶装置に記憶されており、メインメモリ３２に読み出して実行されることにより、図示の各ブロックの機能が実現される。メインメモリ３２として不揮発性メモリを用いる場合は、ソフトウェアをメインメモリ３２に記憶させる方式も可能である。

直接送信ＨＷ部１１は、ネットワーク入出力部２１、ＴＣＰ処理オフローディング部２２、ダイレクトストレージアクセス処理部２３、ＳＡＴＡ入出力部２４、バス入出力部２５を備える。

ネットワーク入出力部２１は、ネットワーク３０１に接続する通信インタフェースであり、MAC層の処理を行う。

ＴＣＰ処理オフローディング部２２は、ＴＣＰ／ＩＰ通信プロトコル処理の一部をハードウェア（ＨＷ）で実行する処理部である。データ送信時に、送信データに、ＴＣＰヘッダ、および、ＩＰヘッダを付与する。また、データ受信時に、ＩＰヘッダの宛先ＩＰアドレス、ＴＣＰヘッダの宛先ポートに基づき、該当する接続を有しているかいないかを確認する。有している場合には、受信データを、ＯＳ４１のＴＣＰ／ＩＰプロトコルスタック部４３に渡すことを行う。本実施形態では、ＴＣＰ処理オフローディング部２２はハードウェアにより構成されるが、ソフトウェア（たとえばＯＳに搭載される）をＣＰＵに実行させることにより、ＴＣＰ処理オフローディング部の機能を実現してもよい。ＳＡＴＡ入出力部２４は、ＳＡＴＡストレージ１２に接続するためのインタフェース部である。ここではストレージ１２は、データ転送装置と外部接続されているが、ＬＡＮ等のネットワークを介して接続される構成も可能である。この場合のネットワークは、クライアント２０１と接続されているネットワーク３０１でもよいし、これとは別のネットワークでもよい。

ダイレクトストレージアクセス処理部２３は、ＯＳ４１のストレージドライバ部（書き込み制御部）４４からの指示に従って、ＳＡＴＡストレージ１２へのアクセスを実施する。あるいは、ＯＳ４１の直接送信ＨＷドライバ部（送信制御部）４７からの指示に従い、ＳＡＴＡストレージ１２からデータ（ここでは応答データ）を読み出し、そのデータをＴＣＰ処理オフローディング部２２に渡す。データを受け取ったＴＣＰ処理オフローディング部２２は、ＴＣＰヘッダおよびＩＰヘッダを付与し、これらのヘッダが付与されたデータを、ネットワーク入出力部２１を通じて、ネットワーク３０１に送出する。

バス入出力部２５は、例えばＰＣＩ Ｅｘｐｒｅｓｓのようなバスを介して、ＣＰＵ３１、メインメモリ３２と接続するための、デバイス側のインタフェース部である。バス入出力部２５は、ＣＰＵ３１やメインメモリ３２との間で、データの受け渡しを行う。ＣＰＵによる処理の指示も、ＣＰＵ３１やメインメモリ３２との間で受け渡しされる。これにより、ソフトウェア（ＯＳ）からの指示や、データのやり取りが、直接送信ＨＷ部１１に対して可能となる。

ＯＳ４１は、ネットワークドライバ部４２、ＴＣＰ／ＩＰプロトコルスタック部４３、ストレージドライバ部４４、バッファキャッシュ部４５、ファイルシステム部４６、直接送信ＨＷドライバ部（送信ドライバ部）４７、システムコール部４８を有している。アプリケーションプログラム５１は、ＯＳ４１の上位で動作するプログラムであり、本実施形態では、キャッシュサーバプログラムである。

ＯＳ４１のネットワークドライバ部４２は、直接送信ＨＷ部１１が有するネットワーク入出力部２１を介して、ネットワーク３０１へデータを送受信するデバイスドライバである。

ＴＣＰ／ＩＰプロトコルスタック部４３は、ＴＣＰ／ＩＰのプロトコルに従って、データの送受信を実現する処理部である。ＴＣＰ処理オフローディング部２２との処理分担の機能を有している。上述のように、ヘッダ処理はハードウェアであるＴＣＰ処理オフローディング部２２で行い、それ以外のＴＣＰのセッション制御に関する処理を、このソフトウェア部分であるＴＣＰ／ＩＰプロトコルスタック部４３で実施する。

ストレージドライバ部４４は、直接送信ＨＷ部１１が有するＳＡＴＡ入出力部２４を介して、ＳＡＴＡで接続されているストレージ１２へのアクセスを実現するデバイスドライバである。

バッファキャッシュ部４５は、メインメモリ３２上に、ストレージ１２の一部のデータをキャッシュして、ストレージへの読み書きを、メインメモリ３２へのキャッシュアクセスへ代替することで、ストレージ１２へのアクセス回数を削減する。これにより、データアクセスの高速化を実現する。

ファイルシステム部４６は、ストレージ１２の記憶領域を論理的にフォーマットし、ファイルによるデータ管理を実現する処理部である。論理フォーマットの方式により、FATファイルシステム、exFATファイルシステム、UNIXファイルシステム、Berkley Fastファイルシステム、extファイルシステムなどがある。本実施形態では、特にどの方式でも構わない。

直接送信ＨＷドライバ部４７は、ＳＡＴＡストレージ１２上のファイルを構成する一連のセクタから該当するデータ（ここでは応答データ）を取り出して、ＴＣＰ／ＩＰで直接（すなわちＴＣＰ／ＩＰプロトコルスタック部４３の処理を介さずに）送出する指示を行うデバイスドライバである。本願では、キャッシュサーバプログラム部５１が、システムコール部４８のsendfile()システムコールにより、データ送出指示を行うのを契機に、直接送信ＨＷドライバ部４７は、ダイレクトストレージアクセス処理部２３とＴＣＰ処理オフローディング部２２の処理開始を指示する。ダイレクトストレージアクセス処理部２３は、直接送信ＨＷドライバ部４７から指定されたファイルのセクタ列の抽出し、抽出したセクタ列の中から該当するデータ（応答データ）を取り出して、ＴＣＰ処理部オフローディング部２２に渡す。ＴＣＰ処理部オフローディング部２２は、当該応答データに、ＩＰヘッダおよびＴＣＰヘッダを付与してパケットとし、当該パケットをネットワーク３０１に送出する。

システムコール部４８は、キャッシュサーバプログラム部（アプリケーションプログラム）５１とのプログラムインタフェースを提供する処理部である。実現方法はＯＳにより様々であるが、ＣＰＵ３１が提供するソフトウェア例外を使用する場合が多い。提供される機能もＯＳにより様々であるが、本実施形態では、ネットワークからのデータ受信のrecv()システムコール、ファイル（ストレージ）へのデータ書き込みのwrite()システムコール、ファイルデータをネットワークへ送出するsendfile()システムコールを図示している。

キャッシュサーバプログラム部５１は、キャッシュプロトコル処理部５２、データ記憶指示部５３、直接送出指示部５４、データ配置管理部５５を有している。

キャッシュプロトコル処理部５２は、ネットワーク３０１を介してクライアント２０１が送信してきたキャッシュプロトコルメッセージを受信し、当該キャッシュプロトコルメッセージの内容を解釈する処理部である。本実施形態ではキャッシュプロトコルとしてmemcachedを想定するが、これに限定されるものでない。基本的な要求メッセージの種類として、データの送信（取得）を要求するGET要求メッセージ、データの記憶（保存）を要求するSET要求メッセージがある。その他の種類の要求メッセージも、実装して構わない。システムコール部４８からのrecv()システムコールを受けることで、キャッシュプロトコル処理部５２は、ＯＳ４１から要求メッセージを受信する。

データ記憶指示部５３は、キャッシュプロトコル処理部５２でSET要求メッセージが受信された場合に、データ配置管理部５５の指示により、SET要求メッセージに含まれるデータを含む応答メッセージ（応答データ）をファイルに書き出す処理を行うwrite()システムコールを呼ぶ。

直接送出指示部５４は、キャッシュプロトコル処理部５２でGET要求メッセージが受信された場合に、データ配置管理部５５の指示により、ファイル中のデータ（応答データ）を読み出してネットワーク３０１に送出する処理を行うsendfile()システムコールを呼ぶ。

データ配置管理部５５は、ストレージ１２上の使用領域および未使用領域を管理するとともに、どのファイルのどこの位置に、何のデータがあるかを管理する処理部である。データ配置管理部５５は、キー(key)と、キーに対応するデータがどのファイルのどこに保持されているかを記述したデータ保持構造体を用いてデータをキーごとに管理する。キーはより一般的に識別子を呼ぶ。なお、SET要求およびGET要求には、キーの指定が含まれており、SET要求には保存対象となるデータも含まれる。また、データ配置管理部５５は、キーのハッシュ表（データ保持管理表）を持ち、キーから目的のデータ保持構造体を速やかに検索できる仕組みを提供する。

図３に、データ保持構造体の例を示している。データ保持構造体は、key、value length、file descriptor、file offsetを有している。その他の項目、たとえば有効期限などを有しても良い。

keyは、データの検索キーとなる文字列、あるいは、バイト列である。

value lengthは、keyに対応してクライアントから保存要求されたデータのバイト長である。

file descriptorは、記憶しているデータが書き込まれているファイルを識別する記述子である。file descriptorは、一般的なＯＳにおいて、ファイルアクセスする際に使用する識別子である。例えばファイル名を記述子に変換するopen()システムコールが有名である。記憶しているデータが書き込まれているファイルを識別する情報である限り、他の形式でも構わない。

file offsetは、keyに対応して記憶しているデータ（クライアントから保存要求されたデータを含む応答データ）のファイル上の記憶場所である。file offsetは、当該ファイルの先頭からのバイト位置を示す。図では、ファイルＡの斜線の場所に、該当する応答データが記憶されていることを示している。１つのファイルには、多数のデータが保持されており、各データが、縦線で区切られている。本実施形態では、これらの各データは、それぞれキャッシュプロトコルの応答メッセージの形式を有する応答データであると想定する。

図４には、キーから目的のデータ保持構造体を速やかに検索するためのデータ保持管理表（ハッシュ表）を示す。

データ保持管理表は、key（文字列あるいはバイト列）のハッシュ値を計算し、計算した結果をインデックスとしてもつ表である。なお、同一のハッシュ値を得られるkeyは複数存在し得る。この表は複数のエントリを有し、各エントリは、ハッシュ値（インデックス）と、当該ハッシュ値を持つkeyのデータ保持構造体のリストとを含む。これにより、目的のkeyを持つデータ保持構造体の検索は、keyのハッシュ値を計算し、その結果をインデックスとするエントリにおけるデータ保持構造体のリストから、key（文字列あるいはバイト列）の値が一致するデータ保持構造体を検索することで実現できる。具体的には、図の例において、リストの一番左のデータ保持構造体から順番に、keyの値が一致するデータ保持構造体が見つかるまで、右側へデータ保持構造体を移動しながら確認を行う。NULLは、リストの終端を示しており、データ保持構造体が特定されずにNULLに達したら、目的のkeyをもつデータは存在しないと判断する。

図５は、データ保持構造体の未使用管理表を示している。未使用管理表は、データ配置管理部５５が管理している。

未使用管理表は、未使用のデータ保持構造体をリストで管理している。「クラス」は、データ保持構造体が割り当てられる記憶領域のサイズの分類である。例えば、128バイト以下をクラス１、128バイトより大きく256バイト以下をクラス２、256バイトより大きく1024バイト以下をクラス３、のように設計で決めることができる。SET要求メッセージで保存要求されたデータから生成される応答メッセージ（応答データ）のサイズが128バイト以下の場合は、クラス１に分類されているデータ保持構造体のリストの中から使用するデータ保持構造体を特定して、特定したデータ保持構造体に示される場所に先頭からデータを格納する。使用したデータ保持構造体は、未使用管理表から削除して、図４に示したデータ保持管理表に移動させる。すなわち、keyのハッシュ値を求めて、求めたハッシュ値に対応するリストの末尾（あるいは任意の位置）に追加する。

図６に、クライアント２０１からGET要求メッセージを受信した場合の処理シーケンスを示している。処理の流れを矢印付きの太い線で示している。太い線が通過しているブロックの処理部が、処理を行う。

まず、GET要求メッセージを受信する（（１））。ネットワーク入出力部２１、ＴＣＰ処理オフローディング部２２、ネットワークドライバ部４２、ＴＣＰ／ＩＰプロトコルスタック部４３、システムコール部４８（recv()システムコール）を介して、キャッシュプロトコル処理部５２が、GET要求メッセージを受信する。

図７に、GET要求メッセージの構成を示している。MACヘッダ/MACトレーラは、ネットワーク入出力部２１が処理し、IPヘッダおよびTCPヘッダは、ＴＣＰ処理オフローディング部２２、ＴＣＰ／ＩＰプロトコルスタック部４３が処理する。これらの処理は、一般的な通信処理と同様に行えばよい。キャッシュプロトコル処理部５２は、キャッシュプロトコルメッセージの処理を行う。ここではキャッシュプロトコル処理部５２は、キャッシュプロトコルメッセージがGET要求メッセージであることを解釈し、“xxxx”をキーとするバリューデータの取得を要求していることを理解する。

次に、データ検索処理（（２））、データ送出指示処理（（３））、データ取得処理（（４））、応答データ送信（（５））と続く。

図８および図９を用いて、この一連の流れを具体的に説明する。

図８に示すように、まず、GET要求に含まれているキーであるxxxxのハッシュ値を、データ配置管理部５５が計算する。ハッシュ値として、0x05を得たとする。

0x05のエントリにおいて、先頭に位置するデータ保持構造体のkeyの値をチェックし、当該keyの値がxxxxであることを確認できたため、検索を完了する（（２））。

当該データ保持構造体に含まれている、file descriptorとfile offsetが、目的のデータの場所を示している。これらfile descriptorとfile offsetを引数に、直接送信指示部５４がsendfile()システムコールを呼ぶことで、データ送出を直接送信ＨＷドライバ部４７に指示する（（３））。

直接送信ＨＷドライバ部４７は、ダイレクトストレージアクセス処理部２３を制御することで、sendfile()で指定されたファイル（ここではz(=file descriptor)がファイルAを指している）のオフセット位置（0xabcd00）のデータ（応答データ）を、ＳＡＴＡストレージ１２から読み出しながら、ＴＣＰ処理オフローディング部２２にデータを渡す（（４））。ＴＣＰ処理オフローディング部２２は、渡されたデータにヘッダを付加してパケットを構築し、パケットをネットワークから送出する（（５））。これにより、応答データ送信を完了する。

図８に示すように、ファイル上に保持しているデータ（応答データ）は、応答メッセージの形式を有する。したがって、ＴＣＰヘッダ、ＩＰヘッダ、ＭＡＣヘッダ／ＭＡＣトレーラを付与するだけで、応答メッセージの送出を行うことができる。つまり、GET要求メッセージを受けた後、キャッシュプロトコルのソフトウェア処理により、応答メッセージを組み立てる必要はない。したがって、高速な応答が可能となる。また、応答メッセージはSATAストレージ１２に記憶しておき、SATAストレージ１２から直接読み出して送信するため、メインメモリ３２のサイズを抑制できる。

図９に、応答メッセージの形式の例を示す（ここでは図８の下に示したものと同じである）。例えば、キャッシュプロトコルメッセージは、応答データであることを示す「VALUE」、キーのxxxx、値の長さのyyyy、バリュー（データ本体）の「……」、メッセージの終端の「END」で構成される。xxxx,yyyyの各x,yには数値が入る。応答データには、データの有効期限情報や、チェックコード、圧縮データかどうかなどを示すフラグなどが付与される場合もある。チェックコード付きの応答データの例は後述する。

図１０は、SET要求メッセージを受信したときの処理のシーケンス（書き込みシーケンス）を示している。

ネットワーク入出力部２１、ＴＣＰ処理オフローディング部２２、ネットワークドライバ部４２、ＴＣＰ／ＩＰプロトコルスタック部４３、システムコール部４８（recv()システムコール）を介して、キャッシュプロトコル処理部５２が、SET要求メッセージを受信する（（１））。

図１１に示すように、SET要求メッセージは、mmmm（各ｍには数値が入る）をキーに、nnnn（各ｎには数字が入る）の長さのデータの保持を指示するメッセージであるとする。 まず、データ配置管理部５５は、nnnnの値をチェックし、当該nnnnの長さのデータから生成される応答データ（応答メッセージ）のヘッダ長を特定し、nnnnの長さとヘッダ長を合計した値が、クラス３の長さだったとする。

なお、応答データのヘッダ長は、規定の最長フォーマット（keyは250バイト、その他の数値は１６バイト等）の長さを用いても良い。または、クラスを決める際に、一時的に応答データのヘッダを作成し、そのヘッダの長さを用いてもよい。

未使用管理表におけるクラス３のエントリのリストから、未使用のデータ保持構造体を１つ取り出す。このデータ保持構造体は、ファイルＡ（file descriptorはz）のオフセット0xdcba00に、クラス３のサイズの記憶領域を割り当てられている。

図１２に示すように、データ配置管理部５５は、受信したSET要求メッセージに含まれるデータ部分“…”を含む応答メッセージ（図中の右側の斜線部分）を作成し、データ記憶指示部５３を介して、ファイルAのオフセット0xdcba00の記憶領域へ、応答データの書込指示を行う。また、キーmmmmのハッシュ値を計算し、ハッシュ表において当該ハッシュ値をインデックスとして有するエントリのリストに、上記未使用管理表から取り出したデータ保持構造体を追加する。図示の例では、ハッシュ値として0x02を得た場合の例が示される。

ここでは、ファイルへの書き込みは、バッファキャッシュ部４５により、まずメインメモリ３２上にキャッシュされる（図１０の（３））。この場合、キャッシュとして、バッファキャッシュ部４５が、メインメモリ３２上に、書き込みデータ（応答データ）を保持する。メインメモリ３２に書き込まれたデータは、ＯＳ４１の処理に従い、遅延して、ストレージ１２上に、フラッシュされる（書き戻される）。なお、応答データをメインメモリ３２にキャッシュすることなく、ストレージ１２に直接、書き込んでも良い。

図１３には、メインメモリ３２上の応答データのフラッシュ前に、次のGET要求メッセージが到着した場合のシーケンスを示している。

バッファキャッシュ部４５が保持している応答データが、次のGET要求メッセージで取得要求されているデータを含む場合のシーケンスを示す。データ送出指示処理までは、図６を用いて前述した通りの処理が行われる（（１）、（２）、（３））。データ送出指示処理の途中で、直接送信HWドライバ部４７は、バッファキャッシュ部４５で保持している応答データに対してフラッシュ指示を行う（（３−１））。不要なフラッシュを避けられる意味で、送出対象である、当該ファイルの当該オフセット箇所のデータのみのフラッシュ指示が好ましいが、バッファキャッシュ部４５が保持しているすべてのデータに対してフラッシュを指示しても構わない。ここでは、GET要求されたデータを含む応答データのみがバッファキャッシュされており、この応答データがストレージ１２上にフラッシュバックされる（（３−２））。直接送信HWドライバ部４７がバッファキャッシュ部４５にフラッシュを指示し、バッファキャッシュ部４５がストレージドライバ部４４を介して、ダイレクトストレージアクセス処理部２３を操作して、ＳＡＴＡストレージ１２へのデータ書き込み（フラッシュバック）を実施する。そのあと、直接送信HWドライバ部４７は、データ送出指示処理の続きを実施する（（３−３））。続いて、データ取得処理（（４））、応答データ送信処理（（５））が実施される。

図１４に、キャッシュプロトコルメッセージの他の例として、上述したチェックコード付きの応答データの例を示す。図中のcccがチェックコードであり、例えば単調増加のシーケンス番号である。図９のメッセージにおける「……」のバリューに加え、チェークコードが含まれる。チェックコードの付与は、バリューの登録時（更新時）に、データ配置管理部５５で行われる。チェックコードは、GETS要求メッセージを受けた場合に、GETS要求メッセージの応答データに含まれて、クライアントへ送られる。GETS要求メッセージの「GETS」は、単に、GET要求メッセージの「GET」の字面を「GETS」に変えたものである。ここで、チェックコードは、以下の目的で利用される。

あるクライアントAが、GETS 要求を行なって、チェックコード付きの応答データを受信したとする。次に、そのクライアントAが、そのチェックコードを指定したバリューの更新を行おうとした際、クライアントが指定したチェックコードと、サーバにおいて当該キーに付与されているチェックコードが管理しているものと一致しない状態、すなわち、クライアントAが GETS 応答を受け取ってから、チェックコードを指定したバリューの更新を行う間に、 他のクライアントBによって、当該キーのバリューが既に更新されている状態である場合がある。このような場合に、クライアントAのチェックコードを指定したバリューの更新は排除される。チェックコードは、casID（Check And Set ID）と呼ぶ場合もある。

キャッシュサーバ１０１は、図９と図１４で示した２種類の応答データの両方を扱えることが必要な場合がある。その場合、図９で示した応答データを要求するGET要求に加え、図１４に示したチェックコード付き応答データを要求するGETS要求を用いるなど、複数の要求に応じた応答データをそれぞれ作成しておく。つまり、SET要求に含まれていたデータから、cccを付加したデータを生成し、同一のキーと、それぞれのデータ（SET要求に含まれていたデータと、cccを付加したデータ）を含むように複数の応答データを作成しておく。キャッシュサーバ１０１では、GET要求で答えるべき応答データと、GETS 要求で答えるべき応答データのように、クライアントからの要求に応じて、返すべき応答データを区別する。

チェックコードの有無による応答データの種類の区別は単なる一例であり、応答データの種類はこれに限定されない。たとえば、プロトコルがテキストメッセージ（GET等が人間で可読なもの）とバイナリメッセージ（数値の字面にエンコードされているもの）の両方に対応している場合や、データの圧縮有無など、同一のキーとバリューに対して、応答データの内容が異なる場合でもよい。

たとえば、 ASCII 文字列の要求メッセージにはテキスト応答で、バイナリデータの要求メッセージにはバイナリで応答する。このように、通常のキーバリュー型のデータベースのように、キーに対応してバリューを記憶するだけでなく、応答するデータ(字面)が要求毎に異なるならば、要求とキーの対応毎に、異なるバリュー（データ）を含む応答データを記憶する。

図１５は、このように、複数の応答データの形式に対応するためのデータ保持構造体の拡張構造を示す。この例のデータ保持構造体は、２種類の応答データに対応した場合のものである。各々の種類に対応した応答データそのものをファイル（本例ではファイルＡ）上に記憶しておき、それぞれの記憶場所（２か所）をデータ保持構造体に格納する。これらの記憶場所を、表や、配列、リスト構造にして管理して、応答データ数の増加に対応しても構わない。「descriptor1」がcccなしの応答データ、「descriptor2」がccc有りの応答データに対応すると解釈してもよいし、最初（上側）に記載された方がcccなしの応答データ、２番目に記載された方がccc有りの応答データに対応すると解釈してもよい。あるいは、応答データの種別を識別する情報をデータ保持構造体に追加してもよい。いずれにせよ、データ保持構造体は、キーと、当該２つの応答データと、２箇所の記憶場所の対応を管理する。

なお、図１５の例では、各応答データが同じファイル上に存在するが、各応答データが異なるファイル上に存在してもかまわない。つまりfile descriptorの値が、応答データに応じて異なってもかまわない。

尚、本実施形態では、図２の上のブロック構成は、キャッシュサーバ１０１のＣＰＵにより実行されるソフトウェアによる機能ブロック構成であると説明したが、必ずしもＣＰＵにより実行されるソフトウェアにより実現されなくてもよく、一部もしくは全ての構成をハードウェアにより実現しても良い。また、本実施形態では、キャッシュサーバ１０１が、応答メッセージを、データ保存要求メッセージを受けたことをきっかけに生成しストレージに保存する例を説明したが、キャッシュサーバ１０１若しくは別の装置によりあらかじめストレージに、応答メッセージを保存しておいても良い。この場合、キャッシュサーバ１０１は、データ保存要求メッセージを受けて応答メッセージの生成する処理は行わず、データ取得要求メッセージを受けた場合に、あらかじめストレージに記憶された応答メッセージを送信する処理を行うものであっても良い。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

Claims (12)

1. ネットワークを介して通信装置と所定のプロトコルにしたがって通信するデータ転送装置であって、
   第１データを含む第１応答メッセージを、ストレージに書き込む制御を行う書き込み制御部と、
   前記通信装置と同じまたは異なる第１通信装置から、前記第１データのデータ取得要求メッセージが受信されたとき、前記ストレージから前記第１応答メッセージを読み出して、前記第１応答メッセージを前記第１通信装置へ送信する制御を行う送信制御部と、
   を備えたデータ転送装置。
2. 更に、前記通信装置から前記第１データを含むデータ保存要求メッセージが受信されたとき、前記第１データを含む前記第１保存メッセージを生成するデータ管理部を備える
   請求項１記載のデータ転送装置。
3. 前記第１応答メッセージは、前記所定のプロトコルの形式の応答メッセージである
   請求項１又は２記載のデータ転送装置。
4. 前記データ保存要求メッセージは前記第１データの識別子である第１識別子を含み、
   前記データ管理部は、前記第１データと前記第１識別子を含む前記第１応答メッセージを生成し、
   前記データ管理部は、前記第１識別子と前記ストレージにおける前記第１応答メッセージの記憶場所である第１記憶場所との対応を管理し、
   前記書き込み制御部は、前記第１応答メッセージを、前記第１記憶場所に書き込む制御を行い、
   前記データ管理部は、前記第１識別子を指定したデータ取得要求メッセージが前記第１通信装置から受信されたとき、前記第１識別子に基づき前記第１応答メッセージが記憶された第１記憶場所を特定し、
   前記送信制御部は、前記ストレージにおいて特定した第１記憶場所から前記第１応答メッセージを読み出し、前記第１応答メッセージを前記第１通信装置に送信する制御を行う
   請求項２又は３に記載のデータ転送装置。
5. 前記データ管理部は、前記ストレージの使用領域および未使用領域を管理し、前記第１応答メッセージのサイズに基づき前記第１記憶場所を確保する
   請求項４記載のデータ転送装置。
6. 前記データ管理部は、前記第１データに基づき第２〜第Ｎ（Ｎは２以上の整数）のデータを生成し、前記第１識別子と前記第１〜第Ｎのデータのそれぞれとを含む第１〜第Ｎの応答メッセージを作成し、前記第１〜第Ｎの応答メッセージのそれぞれの記憶場所である第１〜第Ｎの記憶場所を前記第１〜第Ｎの応答メッセージのそれぞれのサイズに基づき決定し、前記第１識別子と第１〜第Ｎの応答メッセージと前記第１〜第Ｎの記憶場所との対応を管理し、
   前記書き込み制御部は、前記第１〜第Ｎの応答メッセージをそれぞれ前記第１〜第Ｎの記憶場所に書き込み、
   前記データ管理部は、前記第１識別子を指定した第Ｘ（Ｘは１以上Ｎ以下の整数）のデータ取得要求メッセージが受信されたとき、前記第Ｘの応答メッセージが格納されている記憶場所を特定し、
   前記送信制御部は、前記データ管理部により特定された記憶場所から前記第Ｘの応答メッセージを読み出し、前記第Ｘの応答メッセージを前記第１通信装置に送信する
   請求項５に記載のデータ転送装置。
7. 前記第１応答メッセージを前記ストレージに書き込む前に一時的にメインメモリにバッファリングするバッファキャッシュ部を備え、
   前記書き込み制御部は、前記第１応答メッセージが前記メインメモリにバッファリングされている間に、前記データ取得要求メッセージが受信されたとき、前記バッファリング中の第１応答メッセージを前記メインメモリから読み出してストレージに書き込む制御を行い、前記ストレージへの書き込みが完了するまで前記送信制御部の動作を待機させる
   請求項１、又は６に記載のデータ転送装置。
8. 前記データ管理部は、前記第１応答メッセージの記憶場所を、ファイル名と、ファイルの先頭位置からのオフセットにより決定する
   請求項４ないし７のいずれか一項に記載のデータ転送装置。
9. 前記ストレージにアクセスするアクセス処理部と、前記第１通信装置と通信する通信処理部と、を含むハードウェアの送信装置を備え、
   前記送信制御部は、前記アクセス処理部を制御することにより、前記ストレージからの前記第１応答メッセージの読み出しを行い、
   前記通信処理部は、前記ストレージから読み出された第１応答メッセージを前記第１通信装置に送信する
   請求項１ないし８のいずれか一項に記載のデータ転送装置。
10. 前記通信処理部は、前記通信装置と通信し、
    前記データ管理部は、前記通信処理部を介して前記通信装置から前記データ保存要求メッセージを受信し、
    前記書き込み制御部は、前記アクセス処理部を制御することにより前記ストレージへ前記第１応答メッセージの書き込みを行う
    請求項８に記載のデータ転送装置。
11. ネットワークを介して通信装置と所定のプロトコルにしたがって通信するデータ転送システムであって、
    第１データを含む第１応答メッセージを保持するストレージと、
    前記通信装置と同じまたは異なる第１通信装置から、前記第１データのデータ取得要求メッセージが受信されたとき、前記ストレージから前記第１応答メッセージを読み出して、前記第１応答メッセージを前記第１通信装置へ送信する制御を行う送信制御部と、
    を備えたデータ転送システム。
12. ネットワークを介して通信装置と所定のプロトコルにしたがってメッセージを通信する装置に搭載されたコンピュータに実行させるためのプログラムであって、
    第１データを含む第１応答メッセージをストレージへ書き込むことを書き込み制御部に指示するステップと、
    前記通信装置と同じまたは異なる第１通信装置から、前記第１データのデータ取得要求メッセージを受信すると、送信制御部に前記ストレージから前記第１応答メッセージの読み出しと前記第１応答メッセージの前記第１通信装置への送信を指示するステップと
    を備えたプログラム。

Images