(57)【要約】【課題】高負荷時等のストレージ装置に対するキャッシュ処理に起因して、スループットが低下する等の問題を解消する。【解決手段】本発明の実施形態に係る通信装置において、ブリッジ処理部は、第１通信処理部で受信された第１データ転送要求を第２通信処理部から送信し、第２通信処理部で受信された第１応答を第１通信処理部から送信する。キャッシュプロキシ処理部は、第１データ転送要求で要求されるデータがストレージ装置に存在する場合は、データを含む第２応答を第１通信処理部を介して送信し、データが存在しない場合は、代理で第２通信装置からデータを含む第３応答を受信して、データを含む第４応答を第１通信処理部を介して送信する。状態取得部は、ストレージ装置の状態を表す情報を取得する。振分処理部は、ストレージ装置の状態に応じて、ブリッジ処理部およびキャッシュプロキシ処理部のいずれの処理をするかを決定する。【選択図】図１
2017058858.tif 000002
【特許請求の範囲】
【請求項１】
第１通信装置と通信する第１通信処理部と、
第２通信装置と通信する第２通信処理部と、
前記第１通信処理部で受信された前記第２通信装置に対する第１データ転送要求を前記第２通信処理部から送信し、前記第２通信処理部で受信された、前記第１データ転送要求で要求されたデータを含む第１応答を、前記第１通信処理部から送信するブリッジ処理部と、
前記第１データ転送要求で要求される前記データがストレージ装置に存在するかを調べ、前記データが存在する場合は、前記データを含む第２応答を前記第１通信処理部を介して送信し、前記データが存在しない場合は、前記第２通信装置に対して前記データの送信を要求する第２データ転送要求を前記第２通信処理部を介して送信し、前記第２データ転送要求に対する前記第２通信装置の第３応答に含まれるデータを前記ストレージ装置に格納し、前記データを含む第４応答を前記第１通信処理部を介して送信するキャッシュプロキシ処理部と、
前記ストレージ装置の状態を表す情報を取得する状態取得部と、
前記第１通信処理部で前記第１データ転送要求が受信された場合に、前記ストレージ装置の前記状態に応じて、前記第１データ転送要求に関する処理を前記ブリッジ処理部および前記キャッシュプロキシ処理部のいずれで行うかを決定する振分処理部と、を備え、
前記振分処理部により前記ブリッジ処理部が決定された場合、前記ブリッジ処理部が前記第１データ転送要求に関する前記処理を行い、前記キャッシュプロキシ処理部が決定された場合、前記キャッシュプロキシ処理部が前記第１データ転送要求に関する前記処理を行う
通信装置。
【請求項２】
前記状態取得部は、前記ストレージ装置の状態を表す前記情報に基づき、前記ストレージ装置の負荷状態が高いか低いかを判定し、
前記振分処理部は、前記ストレージ装置の前記負荷状態が高い場合は、前記ブリッジ処理部を決定し、前記ストレージ装置の前記負荷状態が低い場合は、前記キャッシュプロキシ処理部を決定する
請求項１に記載の通信装置。
【請求項３】
前記状態取得部は、前記ストレージ装置のスループットを表す情報を取得し、前記スループットに基づき前記ストレージ装置の前記負荷状態を判定する
請求項２に記載の通信装置。
【請求項４】
前記ストレージ装置に対する書き込みまたは読み出しのリクエストを格納するリクエストキューを備え、
前記状態取得部は、前記リクエストキューに存在する前記リクエストの個数に応じて、前記ストレージ装置の前記負荷状態を判定する
請求項２に記載の通信装置。
【請求項５】
第１汎用処理部と、第２汎用処理部とを具備し、
前記第１汎用処理部は、前記キャッシュプロキシ処理部の処理と、前記第１通信処理部の制御処理と、前記第２通信処理部の制御処理と、前記ストレージ装置の制御処理と、を実行し、
前記第２汎用処理部は、前記ブリッジ処理部と前記振分処理部と前記状態取得部の処理を実行し、
前記第２汎用処理部の前記状態取得部が、前記リクエストキューに存在する前記リクエストの個数の情報を取得する
請求項４に記載の通信装置。
【請求項６】
前記状態取得部は、前記ストレージ装置の状態を表す前記情報に基づき、前記ストレージ装置が正常状態か異常状態かを判定し、
前記振分処理部は、前記ストレージ装置が前記異常状態の場合は、前記ブリッジ処理部を決定し、前記ストレージ装置が前記正常状態の場合は前記キャッシュプロキシ処理部を決定する
請求項１に記載の通信装置。
【請求項７】
前記状態取得部は、前記ストレージ装置の負荷状態が高いか低いかを判定し、
前記振分処理部は、前記ストレージ装置が前記正常状態で、かつ前記ストレージ装置の負荷状態が高い場合は、前記ブリッジ処理部を決定し、前記ストレージ装置が前記正常状態で、かつ前記ストレージ装置の負荷状態が低い場合は、前記キャッシュプロキシ処理部を決定する
請求項５に記載の通信装置。
【請求項８】
前記振分処理部は、前記異常状態が決定された後は、前記状態取得部から前記ストレージ装置が前記正常状態か前記異常状態かの通知を受けることなく、前記第１通信処理部で受信される前記第１データ転送要求に対して、常に前記ブリッジ処理部を決定する
請求項６または７に記載の通信装置。
【請求項９】
前記状態取得部は、前記ストレージ装置が前記異常状態から前記正常状態に戻ったことを検知し、
前記振分処理部は、前記ストレージ装置が前記正常状態に戻った後に前記第１通信処理部で受信される前記第１データ転送要求に対しては、前記状態取得部から前記ストレージ装置が前記正常状態か前記異常状態かの通知を受け、前記ストレージ装置が前記異常状態の場合は、前記ブリッジ処理部を決定し、前記ストレージ装置が正常状態の場合は前記キャッシュプロキシ処理部を決定する
請求項８に記載の通信装置。
【請求項１０】
前記ストレージ装置をさらに備えた
請求項１ないし９のいずれか一項に記載の通信装置。
【請求項１１】
前記状態取得部は、前記第１通信処理部で前記振分処理部により前記キャッシュプロキシ処理部が決定される前記第１データ転送要求の受信頻度と、前記第１データ転送要求で要求されるデータサイズとに関する情報を取得し、前記情報に応じて、前記ストレージ装置の負荷状態を判定する
請求項２または７に記載の通信装置。
【請求項１２】
前記状態取得部は、前記第２通信処理部から送信される前記第２データ転送要求の送信頻度と前記第２データ転送要求で要求されるデータサイズとに関する情報を取得し、前記情報に応じて、前記ストレージ装置の負荷状態を判定する
請求項２または７に記載の通信装置。
【請求項１３】
前記ストレージ装置に対しファイルの書き込みまたは読み出しの指示をアプリケーションまたはユーザから受けて、前記ストレージ装置に対し前記ファイルの前記書き込みまたは前記読み出しの処理を行い、
前記状態取得部は、前記ストレージ装置に対する前記書き込みまたは前記読み出しの前記指示の頻度と前記ファイルのサイズとに関する情報を取得し、前記情報に基づき前記ストレージ装置の負荷状態を判定する
請求項２または７に記載の通信装置。
【請求項１４】
第１通信装置と通信する第１通信処理部と、第２通信装置と通信する第２通信処理部とを用いた通信装置で実行する通信方法であって、
前記第１通信処理部で受信された前記第２通信装置に対する第１データ転送要求を前記第２通信処理部から送信し、前記第２通信処理部で受信された、前記第１データ転送要求で要求されたデータを含む第１応答を、前記第１通信処理部から送信するブリッジ処理ステップと、
前記第１データ転送要求で要求される前記データがストレージ装置に存在するかを調べ、前記データが存在する場合は、前記データを含む第２応答を前記第１通信処理部を介して送信し、前記データが存在しない場合は、前記第２通信装置に対して前記データの送信を要求する第２データ転送要求を前記第２通信処理部を介して送信し、前記第２データ転送要求に対する前記第２通信装置の第３応答に含まれる前記データを前記ストレージ装置に格納し、前記データを含む第４応答を前記第１通信処理部を介して送信するキャッシュプロキシ処理ステップと、
前記ストレージ装置の状態を表す情報を取得する状態取得ステップと、
前記第１通信処理部で前記第１データ転送要求が受信された場合に、前記ストレージ装置の前記状態に応じて、前記第１データ転送要求に関する処理を前記ブリッジ処理ステップおよび前記キャッシュプロキシ処理ステップのいずれで実行するかを決定する振分処理ステップと、を備え、
前記ブリッジ処理ステップが決定された場合、前記ブリッジ処理ステップが前記第１データ転送要求に関する前記処理を行い、前記キャッシュプロキシ処理ステップが決定された場合、前記キャッシュプロキシ処理ステップが前記第１データ転送要求に関する前記処理を行う
通信方法。
【請求項１５】
第１通信装置と通信する第１通信処理部と、第２通信装置と通信する第２通信処理部とを用いたコンピュータに実行させるためのコンピュータプログラムであって、
前記第１通信処理部で受信された前記第２通信装置に対する第１データ転送要求を前記第２通信処理部から送信し、前記第２通信処理部で受信された、前記第１データ転送要求で要求されたデータを含む第１応答を、前記第１通信処理部から送信するブリッジ処理ステップと、
前記第１データ転送要求で要求される前記データがストレージ装置に存在するかを調べ、前記データが存在する場合は、前記データを含む第２応答を前記第１通信処理部を介して送信し、前記データが存在しない場合は、前記第２通信装置に対して前記データの送信を要求する第２データ転送要求を前記第２通信処理部を介して送信し、前記第２データ転送要求に対する前記第２通信装置の第３応答に含まれる前記データを前記ストレージ装置に格納し、前記データを含む第４応答を前記第１通信処理部を介して送信するキャッシュプロキシ処理ステップと、
前記ストレージ装置の状態を表す情報を取得する状態取得ステップと、
前記第１通信処理部で前記第１データ転送要求が受信された場合に、前記ストレージ装  前記第１通信処理部で前記第１データ転送要求が受信された場合に、前記ストレージ装置の前記状態に応じて、前記第１データ転送要求に関する処理を前記ブリッジ処理ステップおよび前記キャッシュプロキシ処理ステップのいずれで実行するかを決定する振分処理ステップと、を備え、
前記ブリッジ処理ステップが決定された場合、前記ブリッジ処理ステップが前記第１データ転送要求に関する前記処理を行い、前記キャッシュプロキシ処理ステップが決定された場合、前記キャッシュプロキシ処理ステップが前記第１データ転送要求に関する前記処理を行う
コンピュータプログラム。
【請求項１６】
第１通信装置と通信する第１通信処理部と、
第２通信装置と通信する第２通信処理部と、
前記第１通信処理部で受信された前記第２通信装置に対する第１データ転送要求を前記第２通信処理部から送信し、前記第２通信処理部で受信された、前記第１データ転送要求で要求されたデータを含む第１応答を、前記第１通信処理部から送信するブリッジ処理部と、
前記第１データ転送要求で要求される前記データがストレージ装置に存在するかを調べ、前記データが存在する場合は、前記データを含む第２応答を前記第１通信処理部を介して送信し、前記データが存在しない場合は、前記第２通信装置に対して前記データの送信を要求する第２データ転送要求を前記第２通信処理部を介して送信し、前記第２データ転送要求に対する前記第２通信装置の第３応答に含まれるデータを前記ストレージ装置に格納し、前記データを含む第４応答を前記第１通信処理部を介して送信するキャッシュプロキシ処理部と、を備え、
前記ストレージ装置に第１アクセス負荷をかけた状態で前記第１通信処理部で前記第１データ転送要求が受信された場合は、前記第２通信処理部から前記第１データ転送要求が送信され、
前記ストレージ装置に第１アクセス負荷より低い第２アクセス負荷をかけた状態で前記第１通信処理部で前記第１データ転送要求が受信された場合は、前記第２通信処理部から前記第１データ転送要求が送信されない
通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、通信装置、通信方法およびコンピュータプログラムに関する。
【背景技術】
【０００２】
近年、動画コンテンツなどのコンテンツのリッチ化に伴い、ネットワークを流れるデータ量は爆発的に増大している。このようなトラフィックの増大により、ネットワークの帯域が圧迫され、エンドユーザに対して低スループット・高遅延といった通信品質の低下を招いてしまう。別の言い方をすれば、ネットワークトラフィック増大に対応のための回線増強によるコスト増加が問題となる。これらの問題の解決方法の１つとして、エンドユーザの通信端末（クライアント）とサーバとの間にキャッシュプロキシサーバを設置する方法が一般的に知られている。
【０００３】
キャッシュプロキシサーバは、クライアントがサーバへ発行したＨＴＴＰ  ＧＥＴリクエスト等のデータ転送要求を取得し、クライアントの代わりにサーバに対してデータ転送要求を発行する。サーバから送られてきたデータ転送要求の応答をキャッシュプロキシサーバが受け取ると、その応答をクライアントへ送信すると共に、応答で返ってきたデータをキャッシュプロキシサーバ内部のストレージ装置に、キャッシュデータとして保持する。キャッシュプロキシサーバは、これ以降に発行された同一データに対するリクエストは、サーバにリクエストを発行せずに、ストレージ装置に格納されたキャッシュデータを用いて応答する。このような動作により、頻繁にアクセスされるデータはキャッシュプロキシサーバに保持されたキャッシュデータに基づいて応答することになり、サーバとキャッシュサーバ間のトラフィックを削減できるという効果が得られる。また、キャッシュサーバの上位回線の影響を受けないことから、クライアントに対して高スループット・低応答遅延の通信を提供できるという効果も得られる。
【０００４】
上記のようなキャッシュプロキシサーバが持つキャッシュプロキシ機能を、クライアント端末に近い通信機器である、無線ＬＡＮアクセスポイントやネットワークスイッチ、ネットワークルータ等に持たせることが考えられる。このことは、上位回線コストを抑えつつ、高スループット・低応答遅延を実現する上でより効果的な手段である。しかし、これらの通信機器では、従来必要としなかったストレージ装置を搭載することが必要になり、新たな課題が生じる。例えば、ストレージ装置へのアクセスが高負荷になった場合に、ストレージアクセスがボトルネックとなり、システム全体として性能が低下する可能性がある。特に、動作ログやエラーログ等を、キャッシュデータと共有のストレージ装置に保存する場合、ログ書き込みが発生した場合に一時的にストレージ装置の負荷が高くなり、クライアントへの応答が遅くなるといったことが予想される。
【０００５】
また、ストレージ装置が各部品の中でも比較的寿命が短いという課題もある。特にＳＳＤやｅＭＭＣ等のＮＡＮＤストレージ装置の寿命は大きな問題になると思われる。製品を考えた場合に、ストレージ装置が故障した場合でも従来の通信装置としての最低限の動作を継続することが重要になる。
【０００６】
サーバなどでの高価な通信装置では、ＲＡＩＤ等の技術によって冗長性を持たせることで信頼性を確保しているが、無線ＬＡＮアクセスポイントなどの通信装置では、ストレージ装置を複数台載せることはコスト（費用）などの面で不利になる可能性がある。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００７−１１０７４２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
従来、コンテンツのビットレートと、上位回線の帯域とを考慮してキャッシュ処理をするか否か決定するという技術は存在する。しかしながら、この技術では、ストレージ装置へのアクセスが高負荷である場合や故障状態にある場合などでも、ストレージ装置に対するキャッシュ処理を行ってしまい、スループットの低下や応答遅延時間の増大を招く問題があった。場合によっては、システム全体として動作が停止してしまうという問題があった。
【０００９】
本発明の実施形態は、高負荷時または故障状態時のストレージ装置に対するキャッシュ処理に起因して、スループットが低下し、または応答遅延時間が増加等する問題を解消することを目的とする。
【課題を解決するための手段】
【００１０】
本発明の実施形態に係る通信装置は、第１通信装置と通信する第１通信処理部と、第２通信装置と通信する第２通信処理部と、ブリッジ処理部と、キャッシュプロキシ処理部と、状態取得部と、振分処理部とを備える。
【００１１】
前記ブリッジ処理部は、前記第１通信処理部で受信された前記第２通信装置に対する第１データ転送要求を前記第２通信処理部から送信し、前記第２通信処理部で受信された、前記第１データ転送要求で要求されたデータを含む第１応答を前記第１通信処理部から送信する。
【００１２】
前記キャッシュプロキシ処理部は、前記第１データ転送要求で要求される前記データがストレージ装置に存在するかを調べ、前記データが存在する場合は、前記データを含む第２応答を前記第１通信処理部を介して送信し、前記データが存在しない場合は、前記第２通信装置に対して前記データの送信を要求する第２データ転送要求を前記第２通信処理部を介して送信し、前記第２データ転送要求に対する前記第２通信装置の第３応答に含まれるデータを前記ストレージ装置に格納し、前記データを含む第４応答を前記第１通信処理部を介して送信する。
【００１３】
前記状態取得部は、前記ストレージ装置の状態を表す情報を取得する。
【００１４】
前記振分処理部は、前記第１通信処理部で前記データ転送要求が受信された場合に、前記ストレージ装置の前記状態に応じて、前記データ転送要求を前記ブリッジ処理部および前記キャッシュプロキシ処理部のいずれが処理するかを決定する。
【００１５】
前記振分処理部により前記ブリッジ処理部が決定された場合、前記ブリッジ処理部が前記データ転送要求を処理し、前記キャッシュプロキシ処理部が決定された場合、前記キャッシュプロキシ処理部が前記データ転送要求を処理する。
【図面の簡単な説明】
【００１６】
【図１】第１の実施形態に係わる通信装置の構成を示すブロック図。
【図２】第１の実施形態の動作を示すフローチャート。
【図３】第２の実施形態に係わる通信装置のハードウェア構成図。
【図４】第２の実施形態に係わる通信装置のソフトウェア構成図。
【図５】第２の実施形態に係わる通信装置の他のソフトウェア図。
【図６】第２の実施形態に係わる通信装置の他のハードウェア構成図。
【図７】第３の実施形態に係わる通信装置の構成を示すブロック図。
【図８】第３の実施形態の動作を示すフローチャート。
【図９】第３の実施形態に係わる通信装置のハードウェア構成図。
【発明を行うための最良の形態】
【００１７】
以下、図面を参照しながら、本発明の実施形態について説明する。
【００１８】
（第１の実施形態）
図１は、本発明の第１の実施形態に係わる通信装置１０１のブロック図である。この第１の通信形態に係わる通信装置１０１は、第１通信処理部１１１と、第２通信処理部１１２と、振分処理部１１３と、ブリッジ処理部１１４と、プロトコル処理部１１５と、データアクセス部１１６と、リクエストキュー１１７と、ストレージ処理部１１８と、ストレージ負荷判定部１１９と、アプリケーション部１２１とを備える。アプリケーション部１２１は、キャッシュプロキシ処理部（キャッシュプロキシアプリ）１２２を備える。通信装置１０１は、一例としてアクセスポイント等の中継装置である。
【００１９】
通信装置１０１は、任意のインタフェースでストレージ装置２０１に接続されている。図１では通信装置１０１の外部にストレージ装置２０１が接続されているが、通信装置１０１内部に存在してもかまわない。ストレージ装置２０１の具体的な実装形態は、例えばＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）やＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）、ＳＤカード、ｅＭＭＣ等が想定されるが、これらに限定されない。
【００２０】
第１通信処理部１１１は、無線ネットワーク上の通信装置である通信端末３０１Ａ、３０１Ｂ、３０１Ｃと通信する。第１通信処理部１１１は、パケットの送受信処理を行う。第１通信処理部１１１はアンテナを具備している。具体的な処理としては、通信インタフェースの制御、ＭＡＣレイヤの処理等を行う。無線ネットワークは一例であり、有線ネットワークでもかまわない。通信端末３０１Ａ、３０１Ｂ、３０１Ｃは、例えばユーザにより操作されるパーソナルコンピュータ（ＰＣ）、スマートフォン、携帯電話、タブレットなどの通信装置であるが、通信機能を備えている限り、これらに限定されない。例えば通信機能を備えた家電機器でもよい。通信端末３０１Ａ〜３０１Ｃは、例えばデータの送信を要求するデータ転送要求を送信する。
【００２１】
第２通信処理部１１２は有線のネットワーク５０１に接続され、ネットワーク５０１上の通信装置であるサーバ４０１Ａ、４０１Ｂと通信する。第２通信処理部１１２は、パケットの送受信処理を行う。具体的な処理としては、通信インタフェースの制御、ＭＡＣレイヤの処理等を行う。有線ネットワークは一例であり、代わりに無線ネットワークでも可能である。サーバ４０１Ａ、４０１Ｂは、データの送信を要求するデータ転送要求を受けて、要求されたデータを含む応答を返す通信装置であり、例えばＨＴＴＰサーバ（Ｗｅｂサーバ）、ＦＴＰサーバ等が想定される。ただし、要求されたデータを返す機能を備えている限り、これに限定されるものではない。そのような機能を備えている限り、ＰＣやスマートフォン等のユーザが操作する通信装置でもよい。
【００２２】
プロトコル処理部１１５は、各種のプロトコル処理を行い、アプリケーション部１２１とサーバとの間、およびアプリケーション部１２１と通信端末との間で、データの送受信を行う。データ送信時は、データをアプリケーション部１２１から受け取り、パケット処理を行って、第１通信処理部１１１または第２通信処理部１１２に送出する。データの受信処理時は、第１通信処理部１１１または第２通信処理部１１２から受け取ったパケットをプロトコル処理してデータを取得し、アプリケーション部１２１にデータを渡す。具体的な処理として、ＴＣＰ／ＩＰ、ＵＤＰ／ＩＰ、ＳＳＬ／ＴＳＬまたはＩＰＳｅｃ等のプロトコル処理が想定されるが、これらに限定されない。本実施形態の説明では、ＴＣＰ／ＩＰを想定する。
【００２３】
データアクセス部１１６は、上位のアプリケーション部１２１からの要求を受けて、データの格納アドレスの算出およびリクエストコマンド（リクエスト）の生成等、データの読み出しや書き込みに必要な処理を行う。データアクセス部１１６は、ストレージ装置２０１のデータへアクセスするための当該リクエストコマンドをリクエストキュー１１７へ渡す。具体的な処理としては、ファイルシステムの処理およびまたはブロックレイヤの一部の処理等を想定する。
【００２４】
リクエストキュー１１７はデータアクセス部１１６から入力されたリクエストを内部に保持する。リクエストキュー１１７の構造は、一例としてＦＩＦＯである。リクエストキュー１１７は、内部に保持しているリクエストを、順次ストレージ処理部１１８へ渡す。リクエストキュー１１７の具体的な形態としては、ファイルシステムの内部に存在するキュー、ブロックレイヤの内部に存在するキュー、またはストレージコントローラのドライバの内部に存在するキュー等である。キューは、上位レイヤからのリクエストを保持し、発行可能なものから順次下位レイヤに渡す。ファイルシステムは、ブロックレイヤの上位レイヤであり、ブロックレイヤはストレージコントローラの上位レイヤである。
【００２５】
ファイルシステムに存在するキューとしては、ｒｅａｄ（）やｗｒｉｔｅ（）といったＡＰＩを用いて上位のアプリケーションから渡されるリクエストを管理するキューがある。ブロックレイヤに存在するキューとしては、アクセスするストレージ装置２０１のアドレス（またはブロック）を指定したリクエストを管理するキューがあり、このアドレスはディスクリプタ等を用いて表される。ストレージコントローラのドライバに存在するキューとしては、ストレージドライバへ発行するレジスタアクセスやＤＭＡ転送コマンド等のリクエストを管理するキューがある。例えばファイルシステムは、キャッシュプロキシアプリから要求されるファイル（データ）の読み出しまたは書き込みのリクエストを受け、これをリクエストキューに格納する。ファイルシステムはリクエストキューから取り出したリクエストから、要求されているファイル（データ）が格納されているブロック（アドレス）を特定し、ブロック（アドレス）の読み出しまたは書き込みのリクエストをブロックレイヤに出力する。ブロックレイヤは当該ブロックの要求をリクエストキューに格納する。ブロックレイヤはリクエストキューから取り出したリクエストから、レジスタアクセスまたはＤＭＡ転送コマンド等のリクエストを生成し、ストレージドライバ（ＮＡＮＤドライバなど）に出力する。ストレージドライバは、当該リクエストをリクエストキューに格納する。ストレージコントローラは、リクエストキューから取り出したリクエストをストレージ装置が対応する命令に変換し、ストレージコントローラに出力する。
【００２６】
ストレージ処理部１１８は、リクエストキュー１１７から渡されたリクエストを基に、ストレージ装置２０１の任意のアドレスに対するデータの書き込みおよび読み出しを行う。ストレージ処理部１１８の具体的な処理としては、ブロックレイヤの一部処理またはストレージコントローラの制御処理またはこれらの両方を想定する。
【００２７】
ストレージ装置２０１は、キャッシュプロキシアプリ用のキャッシュデータ等を格納する。キャッシュデータは、例えばＵＲＬ等のＵＲＩ、または任意のデータ識別子と対応づけて記憶されていてもよい。ログ領域、または、ソフトウェアスタック、またはキャッシュプロキシアプリ用以外のデータ、またはこれらの全てを格納する領域をストレージ装置２０１に設けても構わない。
【００２８】
ストレージ負荷判定部１１９は、ストレージ装置２０１の負荷状態の判定（負荷判定）を行う。ストレージ装置の負荷状態の判定方法には、ストレージ装置２０１からストレージ処理部１１８に対するアクセススループット、またはストレージ装置２０１へのリクエスト発行数等を用いる。ストレージ負荷判定部１１９は、ストレージ装置２０１の状態を表す情報を取得する状態取得部の一形態である。ストレージ負荷判定部１１９は、取得した情報に基づき、ストレージ装置２０１の負荷状態を判定する。
【００２９】
スループットの情報を取得する方法としては、Ｓ．Ｍ．Ａ．Ｒ．Ｔ  （Ｓｅｌｆ−Ｍｏｎｉｔｏｒｉｎｇ，  Ａｎａｌｙｓｉｓ  ａｎｄ  Ｒｅｐｏｒｔｉｎｇ  Ｔｅｃｈｎｏｌｏｇｙ）等のＨＤＤやＳＳＤに内蔵されている機能を用いる方法でもよい。ストレージ装置２０１から読み出しているデータ量、またはストレージ装置２０１へ書き込んでいるデータ量を算出する機能を独自に用意し、当該機能を用いてスループット（例えば単位時間当たりの書き込みまたは読み出しのデータ量）を算出してもかまわない。
【００３０】
また、リクエスト発行数の情報を取得する方法は、リクエストキュー１１７の情報を用いる方法でもよいし、ストレージ装置２０１に発行しているリクエストコマンド（リクエスト）の数を保持するような専用の仕組みを用いてもよい。本実施形態では、リクエストキュー１１７による負荷判定を用いるものとする。
【００３１】
リクエストキュー１１７による負荷判定は、事前に閾値を設定しておき、リクエストキュー１１７に保持されているリクエスト数が閾値を超えていたら、ストレージ装置２０１の負荷が大きいと判定し、閾値以下であればストレージ装置２０１の負荷は小さいと判定する。閾値はアプリケーション部１２１から変更が可能であってもよい。また、書き込みや読み出し等、リクエストの種別毎にリクエスト数をカウントし、個別に閾値を設定してもよい。
【００３２】
振分処理部１１３は、第１通信処理部１１１または第２通信処理部１１２から受けたパケットを、プロトコル処理部１１５へ渡すか、ブリッジ処理部１１４へ渡すかを決定する。この決定のために、パケットのヘッダ情報、およびストレージ負荷判定部１１９の判定結果を用いる。
【００３３】
ブリッジ処理部１１４は、第１通信処理部１１１および第２通信処理部１１２の一方から受けたパケットを、他方の通信処理部へ送出する。このような処理を、ブリッジ処理と呼ぶ。本実施形態では、振分処理部１１３からパケットを受け取り、パケットのヘッダ情報などから、第１通信処理部１１１と第２通信処理部１１２のどちらへ送出するかを決定する。この際、ブリッジ処理部１１４は、事前に設定されたフィルタ情報などから、パケットフィルタ処理を行ってもよい。また、ブリッジ処理部１１４は、ＮＡＴ  （Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｉｏｎ）処理を行ってもよい。
【００３４】
アプリケーション部１２１のキャッシュプロキシ処理部（キャッシュプロキシアプリとも呼ぶ）１２２は、プロトコル処理部１１５から渡されたパケットを基に、キャッシュプロキシ処理を行う。キャッシュプロキシ処理部（キャッシュプロキシアプリとも呼ぶ）１２２は、アプリケーション部１２１で動作するアプリケーションのうちの１つである。キャッシュプロキシアプリは、必要に応じてストレージ装置２０１へのアクセス要求をデータアクセス部１１６に発行することで、ストレージ装置２０１に対してデータの読み出しまたは書き込みを行う。ストレージ装置２０１に書き込まれたデータは、キャッシュデータに対応する。キャッシュプロキシアプリが処理するプロトコルの例としては、ＨＴＴＰ、ＨＴＴＰＳまたはＦＴＰ等が想定されるが、これらに限定されない。本実施形態では、キャッシュプロキシアプリは、ＨＴＴＰを処理するものとする。
【００３５】
次に図１および図２を用いて、第１の実施形態に係わる通信装置１０１の動作について説明する。図２は、第１の実施形態に係わる通信装置１０１の動作を示すフローチャートである。以下の説明では、通信端末からサーバへデータ転送要求（通信端末がサーバに自端末へデータを送信してもらうことの要求）を発行した例を用いて説明を行う。ただし、通信端末からサーバへのデータ送信の要求（通信端末が自端末からサーバへデータを送信することの要求）、またはサーバから通信端末へのデータ転送要求でも同様の動作が可能である。
【００３６】
通信端末がサーバに対してデータを転送するようデータ転送要求を発行した場合、当該データ転送要求に関するパケットが、通信装置１０１に送信される。通信装置１０１の第１通信処理部１１１は、当該パケットを受信し、振分処理部１１３へ当該パケットを渡す。通信端末から送信されるパケットは、実際には、使用するプロトコル（ＭＡＣ等）に応じたフレームに含まれる形で送信され、当該フレームが第１通信処理部１１１で受信および処理されてパケットが抽出される。
【００３７】
振分処理部１１３は、受信したパケットの走査を行い（Ｓ１１）、パケットのヘッダ情報を取得する。パケット情報に基づき、パケットの宛先ＩＰアドレスが通信装置１０１のＩＰアドレスと一致するかを判断し（Ｓ１２）、一致した場合は、当該パケットをプロトコル処理部１１５へ渡す（Ｓ１９）。
【００３８】
宛先ＩＰアドレスが通信装置１０１のＩＰアドレス一致しない場合は、振分処理部１１３は、さらに宛先ポート番号を確認し、キャッシュプロキシ処理用に予め定めたポート番号と一致するかを確認する（Ｓ１３）。ポート番号が一致しなかった場合は、当該パケットのデータはキャッシュプロキシ処理の対象ではないため、ブリッジ処理部１１４へパケットを渡す（Ｓ１３）。
【００３９】
ここで、キャッシュプロキシ処理を行うポート番号について補足説明をする。このポート番号は、一例として、キャッシュプロキシアプリ１２２の起動時に設定される。振分処理部１１３は、キャッシュプロキシアプリ１２２から事前にこのポート番号の通知を受けてもよいし、振分処理部１１３がキャッシュプロキシアプリの管理する設定情報を参照することによりポート番号を取得してもよい。本実施形態では、ＨＴＴＰで交換されるデータを、キャッシュプロキシアプリ処理の対象（ストレージ装置２０１にキャッシュする対象）とする。このため、ポート番号としては、例えばポート８０番や８０８０番等が事前に設定されている。
【００４０】
宛先ポート番号が、予め定めたポート番号と一致した場合は、振分処理部１１３は、当該パケットのセッションが、通信装置１０１に登録済みのセッションに一致するかを確認する（Ｓ１４）。ここで、セッションとは、宛先ＩＰアドレス、発信元ＩＰアドレス、宛先ポート番号および発信元ポート番号の４つの情報で管理する通信コネクションである。セッションは、キャッシュプロキシアプリ１２２のバッファに格納されている。バッファは、具体的なハードウェアとしては、メモリ、ハードディスク、ＳＳＤ等の記憶装置により実現されることができる。
【００４１】
通信装置１０１に登録済みのセッションは、通信装置１０１宛てのコネクションか、キャッシュプロキシ処理のためにキャッシュプロキシアプリ１２２が通信端末と確立したコネクションであるかのどちらかである。このため、パケットのセッションが、登録済みのセッションに該当する場合は（Ｓ１５のＹｅｓ）、そのセッションは、（現時点でのストレージ装置２０１の負荷状態に拘わらず）通信装置１０１が処理すべきセッションであるため、振分処理部１１３は、当該パケットをプロトコル処理部１１５へ渡す（Ｓ１９）。なお、この時、当該パケットがキャッシュプロキシ処理部１２２で処理されることが明らかである場合（宛先ＩＰアドレスが自装置でなく、宛先ポート番号が予め定めたポート番号に一致することが振分処理部１１３で判断できる場合など）は、プロトコル処理部１１５を介さず直接、キャッシュプロキシ処理部１２２へパケットを渡してもよい。
【００４２】
一方、当該パケットのセッションが、登録済みのセッションと一致しない場合は（Ｓ１５のＮｏ）、当該パケットのＴＣＰヘッダのＳＹＮフラグを確認する（Ｓ１６）。ＳＹＮフラグが立っていない場合は、すでにこのセッションはブリッジ処理の対象（キャッシュプロキシ処理の対象でない）として判定済みである。つまり、このセッションの開始のトリガーとなる、ＴＣＰコネクションの確立を要求するＳＹＮパケット（ＳＹＮフラグが立っているパケット）の受信時に、ストレージ装置２０１の負荷判定がすでに行われており、ブリッジ処理の対象となることが既に判定済みである。よって、このパケットは、ブリッジ処理部１１４へ渡す。なお、使用する通信プロトコルによってはＳ１６の処理は不要な場合もあり得る。
【００４３】
一方、当該パケットのＳＹＮフラグが立っている場合は、このパケットはＴＣＰコネクションの確立要求を行うＳＹＮパケットであるため、このＴＣＰコネクション（セッション）に対して、キャッシュプロキシ処理およびブリッジ処理のどちらの対象とするかを、振分処理部１１３は、ストレージ装置２０１の負荷状態に応じて決定する（Ｓ１７）。具体的に、振分処理部１１３は、ストレージ負荷判定部１１９からストレージ装置の負荷を表す情報を取得する。
【００４４】
ここで、ストレージ負荷判定部１１９は、振分処理部１１３からの要求を受けてストレージ装置２０１の負荷を判定し、判定した結果を示す情報を返してもよい。または、一定期間ごとにストレージ装置の負荷を判定し、振分処理部１１３からの要求を受けた時点で最新の判定結果を返してもよい。
【００４５】
振分処理部１１３は、ストレージ負荷判定部１１９から取得した判定結果から、現在のストレージ装置の負荷が低い場合は、プロトコル処理部１１５へパケットを渡す。なお、この時、パケットの処理がキャッシュプロキシ処理部１２２で行われることが明らかである場合は、プロトコル処理部１１５を介さず直接、キャッシュプロキシ処理部１２２へパケットを渡すことも可能である。一方、ストレージ装置の負荷が高い場合は、振分処理部１１３は、ブリッジ処理部１１４へパケットを渡す。
【００４６】
以上が、通信端末から送信されたパケットに対して振分処理部１１３により行われる振り分け処理である。ブリッジ処理部１１４またはプロトコル処理部１１５へ振り分けられたパケットは、ブリッジ処理部１１４またはプロトコル処理部１１５でそれぞれの処理が行われる。以下、ブリッジ処理部１１４またはプロトコル処理部１１５の処理について詳細に説明する。
【００４７】
まず、ブリッジ処理部１１４にパケットが振り分けられた場合について説明する。ブリッジ処理部１１４は、振分処理部１１３から受け取ったパケットを、第１通信処理部１１１または第２送信処理部１１２へ渡す。第１通信処理部１１１に渡すか、第２通信処理部１１２へ渡すかの判断は、ヘッダ情報に含まれるＭＡＣアドレスまたはＩＰアドレスまたはこれらの両方等を用いて行う。または、振分処理部１１３からパケットを受け取る際に、通信処理部を指定する情報の通知を受け、当該指定された通信処理部にパケットを渡すような形態でもよい。本例では通信端末とサーバ間の通信を想定しているため、通信端末から受信されたパケットは、サーバへ送信するため、第２通信処理部１１２へ渡される。
【００４８】
次に、プロトコル処理部１１５にパケットが振り分けられた場合について説明する。プロトコル処理部１１５は、振分処理部１１３からパケットを受け取り、プロトコル処理を行った後、パケットのヘッダ情報またはセッション情報またはこれらの両方を基に、該当するアプリケーション部１２１に、パケットに含まれるデータを渡す。必要に応じて、セッション情報またはヘッダ情報またはこれらの両方も、当該アプリケーション部１２１に渡す。具体的に、これらのデータ、ヘッダ情報およびセッション情報を渡す相手となるアプリケーション部１２１は、パケットの宛先ＩＰアドレスが通信装置１０１のＩＰアドレスに一致せず、かつ、ポート番号がキャッシュプロキシ処理を行う宛先ポート番号の場合は、キャッシュプロキシアプリ（キャッシュプロキシ処理部）１１２である。それ以外の場合は、例えばＨＴＴＰサーバアプリ等のアプリケーション（すなわちアプリケーション部１２１で稼働している別のアプリケーション）である。
【００４９】
キャッシュプロキシ処理部１２２は、当該パケットのセッションが登録済みかを判断し、まだ登録されていなければ、通信端末と自装置（通信装置１０１）の間でコネクションを確立し、セッション情報（通信端末−通信装置１０１）を登録する。このとき、セッション情報における通信装置１０１のＩＰアドレスおよびポート番号は、一例として、サーバと同じ（すなわち通信端末から送信されたパケットの宛先ＩＰアドレスおよび宛先ポート番号と同じ）にする。
【００５０】
さらに、キャッシュプロキシ処理部１２２は、当該パケットの宛先ＩＰアドレスのサーバ（すなわち通信端末が宛先として指定していたサーバ）と通信装置１０１との間でコネクションを確立し、セッション情報（通信装置１０１−サーバ）を登録する。つまり、通信装置１０１は、パケットの宛先ＩＰアドレスのサーバに対してコネクションの確立要求を送信することにより、サーバとの間でコネクションを確立する。サーバと通信装置１０１との間でコネクションと、通信端末と通信装置１０１の間のコネクションは、互いに対応がとれるように管理しておく。
【００５１】
キャッシュプロキシ処理部１２２は、上記２つのコネクションを確立してそれぞれのセッション情報を登録した場合、または、パケットのセッションが既に登録されていた場合、受信したパケットのデータの処理を行う。パケットのデータがＨＴＴＰ  ＧＥＴリクエストのようなデータ転送要求である場合、キャッシュプロキシ処理部１２２は、当該データ転送要求で要求されたデータ（例えばＨＴＴＰ  ＧＥＴリクエストで要求されたＵＲＬに存在するデータが）が、ストレージ装置２０１にキャッシュされているかを確認する。なお、受信されたパケットがＳＹＮパケット等、コネクションの確立を要求するパケットの場合、データ転送要求が当該パケットに含まれない場合もある。この場合は、ＳＹＮフラグとＡＣＫフラグにフラグを立てたパケットを通信端末に返すなど、使用する通信プロトコルに応じた手順を実行すればよい。
【００５２】
以下、当該データがストレージ装置２０１にキャッシュされていることを、ストレージ装置２０１にキャッシュデータが存在すると表現することがある。ストレージ装置２０１にキャッシュデータが存在した場合と、存在しなかった場合の処理をそれぞれ説明する。
【００５３】
まず、ストレージ装置２０１にキャッシュデータが存在しない場合は、キャッシュプロキシ処理部１２２は、サーバに対してデータ転送要求を発行する。つまり、キャッシュプロキシ処理部１２２は、通信端末の代理として、サーバへデータ転送要求を発行する。具体的には、キャッシュプロキシ処理部１２２は、ＨＴＴＰリクエストを生成し、プロトコル処理部１１５へ渡す。プロトコル処理部１１５は、ＴＣＰ／ＩＰヘッダの付加などのプロトコル処理を行い、パケットを第２通信処理部１１２へ渡す。第２通信処理部１１２は、受け取ったパケットをサーバへ送信する。
【００５４】
第２通信処理部１１２は、データ転送要求に対する応答であるパケットをサーバから受信する。より詳細には、使用する通信プロトコルに応じたフレームを受信し、フレームの受信処理を行ってパケットを抽出する。第２通信処理部１１２は、当該パケットを振分処理部１１３へ渡す。振分処理部１１３は、パケットのＩＰヘッダから、通信装置１０１宛てのパケットであることを把握し、プロトコル処理部１１５へパケットを渡す。プロトコル処理部１１５は、当該パケットのプロトコル処理を行い、ＩＰヘッダ等からキャッシュプロキシ処理部１２２宛てのパケットであることを把握し、キャッシュプロキシ処理部１２２へ当該パケットを渡す。キャッシュプロキシ処理部１２２は、受信したパケットのデータを通信端末へ送信するように、通信端末とのセッション情報（通信端末−通信装置１０１）を用いて、プロトコル処理部１１５および第１通信処理部１１１を介して、当該データの送信処理を行う。この時、キャッシュプロキシ処理部１２２は、サーバから受信したデータを、ストレージ装置２０１にキャッシュデータとして保存する。一例として、通信端末に送信するパケットの送信元ＩＰアドレスは、サーバと同じＩＰアドレスであり、送信元ポート番号もサーバと同じポート番号（通信端末が送信するパケットの宛先ポート番号）である。したがって、通信端末から見れば、あたかもサーバと通信をしているように見える。
【００５５】
次に、ストレージ装置２０１にキャッシュデータが存在した場合の処理を説明する。キャッシュデータが存在した場合、キャッシュプロキシ処理部１２２は、ストレージ装置２０１から、通信端末から要求されたデータを読み出して、当該データを含む応答を通信端末に返す。具体的には、ストレージ装置２０１から読み出したデータにＨＴＴＰヘッダ等を付加して、プロトコル処理部１１５へ渡す。プロトコル処理部１１５は、ＴＣＰ／ＩＰヘッダの付加等のプロトコル処理を行い、第１通信処理部１１１へパケットを渡し、第１通信処理部１１１は通信端末に対してパケットを送信する。このとき、一例として、パケットの送信元ＩＰアドレスは、サーバと同じＩＰアドレスに設定し、送信元ポート番号もサーバと同じポート番号（通信端末が送信するパケットの宛先ポート番号）に設定する。したがって、通信端末から見れば、あたかもサーバと通信をしているのと同じに見える。
【００５６】
以上のような処理により、キャッシュプロキシ処理部１２２は、通信端末からサーバとのコネクションの確立を要求するパケットを受けた場合に、通信装置１０１でいったんコネクションを終端し、新たにサーバ間でコネクションを確立する。これにより、通信装置１０１は、通信端末の代理としてサーバにアクセスすることが可能となる。
【００５７】
なお、キャッシュプロキシ処理部１２２の動作は、本実施形態の動作に限定されるものではない。通信端末の代わりにサーバからデータを取得して、ストレージ装置２０１にデータをキャッシュして、同一のデータに対するデータ転送要求に対しては、ストレージ装置２０１のキャッシュデータから応答するような一般的なキャッシュプロキシであれば、別の動作でも問題ない。例えば、本実施形態とは別の動作例として、通信端末および通信装置１０１間、通信装置１０１およびサーバ間で、（ブリッジ処理するか否かに拘わらず）常にコネクションを別々に確立する形態でもよい。通信端末は、通信装置１０１のＩＰアドレスおよびポート番号に基づき、サーバ宛の要求を含むパケットをカプセル化したパケットを通信装置１０１に送信する形態でもよい。この場合、通信装置１０１は、ブリッジ処理を行う場合も、キャッシュプロキシ処理を行う場合も、常に自装置のＩＰアドレスおよびポート番号を送信元ＩＰアドレスおよび送信元ポート番号として、サーバと通信する。この動作例の場合、プロトコル処理部１１５の負荷は増加するものの、ストレージ装置２０１がボトルネックでシステム全体の性能低下を避ける効果は依然として得ることができる。
【００５８】
本実施形態では、ストレージ装置の負荷状態を、ストレージ装置に対するリクエスト数およびスループット等に基づき判定したが、これに限定されない。例えば、通信端末からキャッシュプロキシアプリの処理の対象であるデータ転送要求が受信される頻度および当該データ転送要求で要求されるデータサイズ等の情報を、本実施形態に係る状態取得部で取得し、当該頻度およびデータサイズ等に基づいてストレージ装置の負荷状態を間接的に判定してもよい。例えば一定時間当たりに受信されるデータ転送要求数の平均（または一定時間当たりに受信されるデータ転送要求数の平均等）が閾値以上の場合に、ストレージ装置の負荷が高いと判定し、閾値未満の場合は、ストレージ装置の負荷が低いと判定してもよい。または直前の一定時間当たりに要求されるファイルサイズの合計（または一定時間当たりに要求されるファイルサイズの合計の平均等）を計算し、当該合計が閾値以上の場合に、ストレージ装置の負荷が高いと判定し、閾値未満の場合は、ストレージ装置の負荷が低いと判定してもよい。
【００５９】
別の例として、通信装置のアプリケーション部が、ユーザ入力手段（タッチパネル、キーボード、マウス等）または別のアプリケーションから、ストレージ装置へのファイル生成（書き込み）指示または読み出し指示等を受けて、ストレージ装置に対しファイルの生成またはファイルの読み出しを行う場合を考える。この場合に、ユーザからの指示の頻度またはファイルのサイズ等を、本実施形態に係る情報取得部で取得し、当該頻度またはファイルのサイズ等に基づいてストレージ装置の負荷状態を間接的に判定してもよい。例えば直前の一定時間当たりに受信される指示数（または一定時間当たりに受信される指示数の平均等）が閾値以上の場合に、ストレージ装置の負荷が高いと判定し、閾値未満の場合は、ストレージ装置の負荷が低いと判定してもよい。または直前の一定時間当たりに受信する各指示のファイルサイズの合計（または一定時間当たりに指示されるファイルサイズの合計の平均等）を計算し、合計サイズが閾値以上の場合に、ストレージ装置の負荷が高いと判定し、閾値未満の場合は、ストレージ装置の負荷が低いと判定してもよい。
【００６０】
さらに別の例として、第２通信処理部１１２からサーバに送信されるパケットをスイッチミラーリング等を利用して、本実施形態に係る情報取得部で取得し、当該パケットが通信装置からサーバへ向けて送信されるデータ転送要求である場合は、それはキャッシュプロキシアプリ１２２により送信されたデータ転送要求であると考えられる。そこで、そのデータ転送要求の頻度およびデータ転送要求で要求されるデータサイズ等を利用して、ストレージ装置の負荷を判定してもよい。例えば直前の一定時間当たりに送信されるデータ転送要求数（または一定時間当たりに送信されるデータ転送要求数の平均等）が閾値以上の場合に、ストレージ装置の負荷が高いと判定し、閾値未満の場合は、ストレージ装置の負荷が低いと判定してもよい。または直前の一定時間当たりに要求するファイルサイズの合計（または一定時間当たりに要求するファイルサイズの合計の平均等）を計算し、合計が閾値以上の場合に、ストレージ装置の負荷が高いと判定し、閾値未満の場合は、ストレージ装置の負荷が低いと判定してもよい。
【００６１】
以上に述べた以外の方法で、ストレージ装置の負荷状態を判定することも当然可能である。
【００６２】
このように、第１の実施形態によれば、ストレージ装置２０１の負荷が高い場合には、キャッシュプロキシ処理をスキップして、ブリッジ処理を行うことによりストレージ装置２０１がボトルネックでシステム全体の性能低下を避けることが可能になる。つまり、ストレージ装置の一時的な高負荷時も、通信装置（中継装置等）としての動作を最低限継続することができる。
【００６３】
また、本実施形態によれば、プロトコル処理部１１５に渡す前にストレージ装置２０１の負荷を判定することで、これらの無駄なオーバーヘッドを削減できるという効果もある。つまり、振分処理部１１３を設けずに、必ずプロトコル処理部１１５にパケットを受け渡し、キャッシュプロキシ処理部１２２などのアプリケーション部１２１で、ストレージ装置２０１の負荷を測定して、負荷が大きい場合にブリッジ処理部１１４にパケットを渡す方法も考えられる。しかし、この場合、無駄なプロトコル処理やアプリケーション処理が当該パケット度に発生することになる。これに対し、本実施形態は、プロトコル処理部１１５に渡す前にストレージ装置２０１の負荷を判定することで、これらの無駄な処理を削減できる。
【００６４】
上述したように、本実施形態に係る通信装置は、ストレージ装置２０１の負荷状態に応じて、ブリッジ処理とキャッシュプロキシ処理間で動作を切り換える。いずれの動作が行われているかは、外部から第１通信処理部１１１で受信されるパケットおよび第２通信処理部１１２から送信されるパケットを監視することで、（通信装置の内部の動作を検査しなくても）把握することも可能である。
【００６５】
すなわち、ストレージ装置２０１にある負荷（第１アクセス負荷）をかけた状態で、第１通信処理部１１１でサーバに対するデータ転送要求のパケットが受信された場合に、第２通信処理部１１２から当該パケットが転送されたかを監視する。パケットの転送が検出された場合、ストレージ装置２０１に大きな負荷がかかっており、通信装置でブリッジ処理が行われていると判断できる。一方、ストレージ装置２０１に第１アクセス負荷より低い負荷（第２アクセス負荷）をかけた状態で、第１通信処理部１１１でサーバへのデータ転送要求のパケットが受信された場合に、第２通信処理部１１２からサーバに当該パケットが転送されない場合、通信装置でキャッシュプロキシ処理が行われていると判断できる。ここで第２通信処理部１１２からサーバに当該パケットが転送されない場合とは、何らパケットが送信されない場合、および通信装置とサーバ間で設定したセッションでパケットが送信される場合を含む。
【００６６】
第１通信処理部１１１へ受信されるパケットをスイッチ等によりミラーリングして取得する手段、第２通信処理部１１２から送信されるパケットをスイッチ等によりミラーリングして取得する手段、これら両手段を用いて、パケットの転送があったか否かを判断する手段を備えた監視装置を提供してもよい。監視装置は物理的に１つの装置でも、ネットワークを介して相互接続された複数の装置から構成されてもよい。
【００６７】
ストレージ装置２０１に負荷をかける方法としては、上述した例のようにストレージ装置２０１へのファイルの書き込み指示または読み出し指示等で、ストレージ装置２０１に負荷をかける量を調整してもよい。例えば大容量のファイルの書き込みまたは読み出し指示を与えて実行させている状態を、第１アクセス負荷をかけた状態としてもよい。また、何ら書き込みまたは読み出し指示を与えない状態、または小容量のファイルの書き込みまたは読み出し指示を与えて実行させている状態を、第２アクセス負荷をかけた状態としてもよい。ここで述べた以外の方法でストレージ装置２０１にかける負荷を調整しても良い。例えば書き込みまたは読み出し指示の個数の量で、ストレージ装置２０１にかける負荷を調整してもよい。上述の監視装置は、ストレージ装置２０１に負荷をかける手段を備えていてもよい。
【００６８】
（第２の実施形態）
第２の実施形態では、第１の実施形態に係る通信装置の具体的なハードウェア構成およびソフトウェア構成の例を示す。図３は第２の実施形態に関わる通信装置の例を示した図である。
【００６９】
図３の通信装置は、第１汎用処理部６１１と、第２汎用処理部６１２と、ＳＤＲＡＭ６２１と、ＳＤＲＡＭコントローラ６１３と、ストレージ装置２０１と、ストレージコントローラ６１４と、ＷＬＡＮ  ＲＦ６３１と、ＷＬＡＮ  Ｌｏｗｅｒ  ＭＡＣ  Ｂａｓｅｂａｎｄ６１５と、ＷＬＡＮ  Ｕｐｐｅｒ  ＭＡＣ６１６と、ＧｂＥ（１Ｇｉｇａｂｉｔ  Ｅｔｈｅｒｎｅｔ（登録商標））  ＰＨＹ６４１と、ＧｂＥ  ＭＡＣ  （１Ｇｉｇａｂｉｔ  Ｅｔｈｅｒｎｅｔ  ＭＡＣ）６１７と、バッファ管理部６１８と、ＬＵＴ  （Ｌｏｏｋ−ｕｐ  Ｔａｂｌｅ）  ＲＡＭ６１９と、ＳＲＡＭ６２０と、を備える。第１汎用処理部６１１と、第２汎用処理部６１２はそれぞれ一例として、ＣＰＵ等のプロセッサにより構成される。図においてひとかたまりに配置されているバッファ管理部６１８、第２汎用処理部６１２、ＲＡＭ６１９およびＳＲＡＭ６２０は、一例として１の集積回路（チップ）により構成されていてもよいし、複数のチップにより構成されてもよい。
【００７０】
ＷＬＡＮ  ＲＦ６３１は、無線によって外部の無線端末と無線信号の送受信を行う。受信処理の場合、ＷＬＡＮ  ＲＦ６３１は無線信号を信号処理してフレームを取得し、ＷＬＡＮ  Ｌｏｗｅｒ  ＭＡＣ  Ｂａｓｅｂａｎｄ６１５へ渡す。送信処理の場合、ＷＬＡＮ  Ｌｏｗｅｒ  ＭＡＣ  Ｂａｓｅｂａｎｄ６１５から受け取ったフレームに信号処理を行って、無線信号を送信する。
【００７１】
ＷＬＡＮ  Ｌｏｗｅｒ  ＭＡＣ  Ｂａｓｅｂａｎｄ６１５は、ＷＬＡＮ  ＭＡＣの下位レイヤの処理を行う。受信処理の場合、フレームをＷＬＡＮ  ＲＦ６３１から受け取り、ＷＬＡＮ  ＭＡＣの下位レイヤの処理を行って、後述のＷＬＡＮ  Ｕｐｐｅｒ  ＭＡＣ６１６へ渡す。送信処理の場合、ＷＬＡＮ  Ｕｐｐｅｒ  ＭＡＣ６１６から受け取ったフレームにＷＬＡＮ  ＭＡＣの下位レイヤ処理を行った後、ＷＬＡＮ  ＲＦ６３１へ渡す。本実施形態では、ＷＬＡＮ  Ｕｐｐｅｒ  ＭＡＣ６１６とのフレームの受け渡しは、後述のＳＤＲＡＭ６２１に確保したＷＬＡＮバッファを介して行うことを想定しているが、この構成に限定されない。例えば、各処理部の内部にバッファを搭載して直接、フレームを渡すような構成でもよい。
【００７２】
ＷＬＡＮ  Ｕｐｐｅｒ  ＭＡＣ６１６は、ＷＬＡＮ  ＭＡＣの上位レイヤの処理を行う。受信処理の場合、ＷＬＡＮ  Ｌｏｗｅｒ  ＭＡＣ  Ｂａｓｅｂａｎｄ６１５からフレームを受け取り、ＷＬＡＮ  ＭＡＣの上位レイヤの処理を行って、第２汎用処理部６１２にフレーム（ここではパケットの形態でもよい）を渡す。送信の場合は、第２汎用処理部６１２からフレームを受け取り、ＷＬＡＮ  ＭＡＣの上位レイヤの処理を行って、ＷＬＡＮ  Ｌｏｗｅｒ  ＭＡＣ  Ｂａｓｅｂａｎｄ６１５へ、処理されたフレームを渡す。本実施形態では、ＷＬＡＮ  Ｌｏｗｅｒ  ＭＡＣ  Ｂａｓｅｂａｎｄ６１５とのフレームの受け渡しは、ＳＤＲＡＭ６２１に確保したＷＬＡＮバッファ、第２汎用処理部６１２とのフレームの受け渡しには、ＳＤＲＡＭに確保したパケットバッファを介して行うことを想定しているが、この構成に限定されない。例えば、各処理部の内部にバッファを搭載して直接、フレームを渡すような構成でもよい。パケットバッファによるフレームの受け渡しに関しては、後述のバッファ管理部６１８の説明で詳細に述べる。
【００７３】
ＧｂＥ  ＭＡＣ６１７は、１  Ｇｉｇａｂｉｔ  Ｅｔｈｅｒｎｅｔ  ＭＡＣであり、ＭＡＣ処理を行う。受信時はＧｂＥ  ＰＨＹ６４１から受け取ったフレームをＭＡＣ処理し、第２汎用処理部６１２へ渡す。送信の場合は、第２汎用処理部６１２からフレームを受け取り、ＭＡＣ処理を行って、ＧｂＥ  ＰＨＹ６４１から送出する。本実施形態では、第２汎用処理部６１２とのフレームの受け渡しには、ＳＤＲＡＭ６２１に確保したパケットバッファを介して行うことを想定しているが、その限りではない。
【００７４】
バッファ管理部６１８は、ＳＤＲＡＭ６２１に確保したパケットバッファを管理する。パケットバッファの管理の例としては、バッファ管理部６１８は、各パケットバッファをバッファ識別子とその識別子に対応するディスクリプタとで管理する。ディスクリプタには、パケットバッファのアドレス、メモリの所有者（アプリケーションなど）、次に実行する処理内容等の属性が記載される。各処理部は、バッファ識別子を通知し合うことで、特定のパケットバッファのディスクリプタを参照でき、パケットまたはフレームの受け渡しが可能になる。
【００７５】
第２汎用処理部６１２は、ＳＲＡＭ６２０に格納されたファームウェア６２２を実行する。ファームウェア６２２はストレージ装置２０１に格納しておき、通信装置の起動時や、第２汎用処理部の初期化時に、ＳＲＡＭ６２０へ読み出す方法が考えられる。第２汎用処理部６１２は第１汎用処理部６１１から通信処理の一部をオフロードする。第２汎用処理部６１２で実行する処理は、処理が単純で、かつ頻繁に実行される通信処理である。これにより、第１汎用処理部６１１の処理負荷を抑えつつ、高速に通信処理を実行できるという効果が期待できる。本実施形態では、ファームウェア６２２にブリッジ処理部１１４、ストレージ負荷判定部１１９、振分処理部１１３の機能を備え、第２汎用処理部６１２はそれらの処理を実行する。また、第２汎用処理部６１２は、セッション情報およびパケット分類に必要な情報等の各処理に必要な情報を、ＬＵＴ  ＲＡＭ６１９またはＳＲＡＭ６２０またはこれらの両方に保持して、それらを用いて各処理を実行する。ただし、ＬＵＴ  ＲＡＭ６１９を設けずに、ＳＤＲＡＭ６２０からこれらの情報を読み出す構成でも問題ない。
【００７６】
ＳＤＲＡＭコントローラ６１３はＳＤＲＡＭ６２１に接続され、各処理部からのアクセスを受け付けて、ＳＤＲＡＭ６２１に対しデータの読み出しおよび書き込みを行う。各処理部からのアクセスには、ＤＭＡＣ（Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌｌｅｒ）（図示せず）を用いてＤＭＡ転送によるアクセスを想定するが、この構成に限定されない。
【００７７】
ＳＤＲＡＭ６２１には、各処理に必要なメモリ領域が確保される。本実施形態では、アプリケーション領域６２３およびカーネル領域６２４が確保される。アプリケーション領域６２３には、キャッシュプロキシ処理で用いられるキャッシュ領域６２３Ａが確保される。カーネル領域６２４には、ＴＣＰ／ＩＰ処理で必要なセッション情報（ＩＰアドレスおよびポート番号、シーケンス番号等）６３２や、フレームを一時的に保持するＷＬＡＮバッファ６３３、パケットを一時的に保持するパケットバッファ６３４、リクエストキュー１１７が確保される。リクエストキュー１１７には、ストレージ装置２０１にアクセスするためにファイルシステム、ブロックレイヤおよびストレージドライバ処理等の各レイヤ間のリクエストを保持する。
【００７８】
ストレージコントローラ６１４はストレージ装置２０１に接続され、各処理部からのアクセスを受け付けて、ストレージ装置２０１に対してデータの読み出しおよび書き込みを行う。各処理部からのアクセスには、ＤＭＡＣ（図に未掲載）を用いてＤＭＡ転送によるアクセスを想定するが、この構成に限定されない。
【００７９】
ストレージ装置２０１には、第１汎用処理部６１１のソフトウェアスタック６４２や、第２汎用処理部６１２用のファームウェア６４３、キャッシュプロキシ処理のキャッシュ領域として用いるキャッシュ領域６４４、通信装置の動作やエラー等のログを格納するログ領域６４５などが確保される。
【００８０】
第１汎用処理部６１１は、ストレージ装置２０１に格納されたソフトウェアスタック６４２を用いて、各処理部の制御、通信処理、ストレージ装置処理、ファイルシステム処理、キャッシュプロキシ処理等を実行する。第１汎用処理部６１１のソフトウェアスタック６４２を含むシステム構成を図４に示す。
【００８１】
ソフトウェアスタック６４２のＣａｃｈｅ  Ｐｒｏｘｙ  Ａｐｐｌｉｃａｔｉｏｎ６５１は、キャッシュプロキシ処理を行う。カーネル空間のＴＣＰ／ＩＰ６５２は、送信するデータへのＴＣＰ／ＩＰヘッダの付加や、パケットのＴＣＰ／ＩＰヘッダの解析等のプロトコル処理を行う。Ｂｒｉｄｇｅ６５３は、通信インタフェース（通信処理部）間のブリッジ処理を行う。ＧｂＥ  ＭＡＣ６１７とＷＬＡＮ  ＭＡＣ（６１５、６１６）間のパケットのブリッジ処理は、第２汎用処理部６１２が行ってもよい。ストレージ負荷判定および受信パケット振分処理も、第２汎用処理部６１２が行ってもよい。図５のように、第２汎用処理部が存在しない形態の場合は、ブリッジ処理や、ストレージ負荷判定および受信パケット振分処理は、第１汎用処理部６１１で行えばよい。また、複雑なルールに基づくフィルタ処理を含んだブリッジ処理などの複雑な処理の場合も、第２汎用処理部ではなく、第１汎用処理部のＢｒｉｄｇｅ６５３で処理を行うことが考えられる。ＮＩＣ  Ｄｒｉｖｅｒ６５４は、ＧｂＥ  ＭＡＣ６１７の制御を行うデバイスドライバである。ＷＬＡＮ  ｄｒｉｖｅｒ６５５は、ＷＬＡＮ  ＭＡＣ（６１５、６１６）の制御を行うデバイスドライバである。Ｆｉｌｅ  Ｓｙｓｔｅｍ６６６は、ストレージ装置２０１に格納されたデータにファイル単位でアクセスするためのファイルシステム処理を行う。Ｂｌｏｃｋ  Ｌａｙｅｒ６６７は、ストレージ装置２０１のデータにブロック単位でアクセスするためのブロックレイヤの処理を行う。Ｓｔｏｒａｇｅ  Ｄｒｉｖｅｒ６６８はストレージコントローラ６１４の制御を行うデバイスドライバである。第２汎用処理部ドライバ６５６は、第２汎用処理部６１２を制御するためのドライバである。以上が、第１汎用処理部で行う処理内容であるが、上記の処理以外にも第１汎用処理部は、その他種々の処理を行うことが可能である。
【００８２】
次に、図３および図４を用いて、第２の実施形態に係わる通信装置の動作について説明する。以下の動作説明では、無線ＬＡＮ（ＷＬＡＮ）で接続される通信端末が、ＧｂＥ（１Ｇｉｇａｂｉｔ  Ｅｔｈｅｒｎｅｔ）を介して接続されるサーバへ対してデータ転送要求を発行する例に説明を行うが、通信端末からサーバへのデータ送信の場合や、サーバから通信端末へのデータ転送要求を行う場合でも、基本的な動作は同じである。
【００８３】
通信端末がサーバに対してデータを転送することを要求するため、ＨＴＴＰ  ＧＥＴリクエストのようなデータ転送要求を送信する。データ転送要求の無線信号がＷＬＡＮ  ＲＦ６３１で受信され、受信処理を経て、ＷＬＡＮ  Ｌｏｗｅｒ  ＭＡＣ  Ｂａｓｅｂａｎｄ６１５へフレームが渡される。ＷＬＡＮ  Ｌｏｗｅｒ  ＭＡＣ  Ｂａｓｅｂａｎｄ６１５は、ＳＤＲＡＭ６２１に確保されたＷＬＡＮバッファ６３３にフレームを書き込み、ＷＬＡＮ  ＭＡＣの下位レイヤ処理を行う。そして、書き込んだＷＬＡＮバッファのアドレス等を、後段の処理に必要な情報と共に、ＷＬＡＮ  Ｕｐｐｅｒ  ＭＡＣ６１６へ通知する。
【００８４】
ＷＬＡＮ  Ｕｐｐｅｒ  ＭＡＣ６１６は、ＷＬＡＮ  Ｌｏｗｅｒ  ＭＡＣ  Ｂａｓｅｂａｎｄ６１５から通知されたアドレスに格納されたフレームに対して、ＷＬＡＮ  ＭＡＣの上位レイヤ処理を行うとともに、バッファ管理部６１８に空いているパケットバッファを問い合わせ、バッファ識別子を受け取る。ＷＬＡＮ  Ｕｐｐｅｒ  ＭＡＣ６１６およびＷＬＡＮ  Ｄｒｉｖｅｒ６５５は、バッファ管理部６１８から受け取ったバッファ識別子を用いてディスクリプタを参照して、パケットバッファのアドレスを取得する。ＷＬＡＮ  Ｕｐｐｅｒ  ＭＡＣ６１６およびＷＬＡＮ  Ｄｒｉｖｅｒ６５５は、取得したアドレスのパケットバッファに対してパケットを書き込み、第２汎用処理部６１２にバッファ識別子と共にパケットを受信したことを通知する。
【００８５】
第２汎用処理部６１２は、受け取ったバッファ識別子を用いてディスクリプタを参照し、パケットバッファのアドレスを取得し、該当のアドレスに格納されたパケットの処理を行う。第２汎用処理部６１２の具体的な処理内容は、受信パケット振り分け処理、ストレージ装置の負荷判定処理およびブリッジ処理である。第２汎用処理部６１２の振分処理部１１３は、図２のステップＳ１８の処理を行う場合、第２汎用処理部６１２のブリッジ処理部１１４にパケットを受け渡し、ステップＳ１９の処理を行う場合は、第１汎用処理部６１１へパケットを渡す。この時、パケットの受け渡しは、バッファ記述子を通知することで行う。
【００８６】
ここで、第２汎用処理部６１２で実行されるストレージ負荷判定部１１９は、第１汎用処理部６１１が管理するリクエストキュー１１７の情報を参照できる必要がある。リクエストキュー１１７は具体的には、図４に示すように、ファイルシステム６６６、ブロックレイヤ６６７、ストレージドライバ６６８の各内部に存在する。リクエストキュー１１７は、上位レイヤの処理部からストレージ装置２０１へのアクセス要求を受け付けて、下位レイヤの処理部へリクエストを発行するためのキューである。ストレージ負荷判定部１１９は、これらのファイルシステム、ブロックレイヤ、ストレージドライバの内、１つのレイヤあるいは複数のレイヤが管理するリクエストキュー１１７の情報にアクセス可能である。このため、第２汎用処理部６１２の初期化時や、ファイルシステム６６６の初期化時、ブロックレイヤ６６７の初期化時、ストレージドライバ６６８の初期化時などに、第１汎用処理部６１１は、リクエストキュー１１７の情報が格納されているＳＤＲＡＭ６２１のアドレスを、ストレージ負荷判定部１１９に通知する等しておく必要が有る。
【００８７】
図４および図５の例では、ブロックレイヤのリクエストキューをストレージ負荷判定部１１９が参照している。ファイルシステム６６６のリクエストキューまたはストレージドライバ６６８のリクエストキューを参照してもよい。またはファイルシステム６６６のリクエストキュー、ブロックレイヤ６６７のリクエストキュー、ストレージドライバ６６８のリクエストキューのうちのいずれか２つ、または３つのリクエストキューを参照してもよい。
【００８８】
振分処理部１１３がブリッジ処理部１１４へパケットを受け渡した場合は、ブリッジ処理部１１４は、ＧｂＥ  ＭＡＣ６１７およびＮＩＣドライバ６５４に、パケットパケット識別子を通知することによりパケットを渡す。ＧｂＥ  ＭＡＣ６１７およびＮＩＣドライバ６５４は、受け取ったバッファ識別子を用いてディスクリプタを参照し、パケットバッファに格納されているパケットをＧｂＥ  ＰＨＹ６４１から送出する。
【００８９】
振分処理部１１３が第１汎用処理部６１１へパケットを受け渡した場合は、第１汎用処理部６１１は、パケットに対してＴＣＰ／ＩＰ処理を行い、上位の適当なアプリケーションにパケットのデータを渡す。以降のキャッシュプロキシ処理等は、第１の実施形態と同様にして行われる。キャッシュデータへのアクセスは、ファイルシステム６６６、ブロックレイヤ６６７およびストレージドライバ６６８によって、ストレージコントローラ６１４を介してストレージ装置２０１へアクセスすることになる。
【００９０】
このように、第２の実施形態によるハードウェア構成およびソフトウェア構成を採用することで、第１の実施形態に係る通信装置を実現することができる。よって第２の実施形態に係る通信装置によれば、第１の実施形態と同様の効果を得ることができる。
【００９１】
図６は、第２の実施形態に係る通信装置の別のハードウェア構成例を示す。図３と同じ要素には同一の符号を付して、変更または拡張された処理を除き、重複する説明を省略する。
【００９２】
ＴＣＰ／ＩＰの処理を、専用のハードウェアであるＴＣＰ／ＩＰオフロード処理部６８１で処理し、ストレージ装置２０１へのアクセスを、専用ハードウェアであるストレージアクセスオフロード処理部６８２を用いる。この場合、ストレージアクセスオフロード処理部６８２とＴＣＰ／ＩＰオフロード処理部６８１間のデータの受け渡しは、オフロードバッファ管理部を６８３介して行われる。
【００９３】
オフロードバッファ管理部６８３は、ストレージアクセスオフロード処理部６８２とＴＣＰ／ＩＰオフロード処理部６８１が参照する送受信バッファ６９１を管理する。オフロードバッファ管理部６８３の送受信バッファ６９１の管理方法の例としては、セッション毎にデータが書き込まれている先頭アドレスと末尾アドレスを管理する。例えばキャッシュプロキシアプリケーションがストレージ装置２０１のキャッシュデータを送信する場合は、第１汎用処理部６１１は、ストレージアクセスオフロード処理部６８２に対してストレージ装置２０１の任意のアドレスに格納されたデータを読み出すように指示する。またこれと同時に、ＴＣＰ／ＩＰオフロード処理部６８１に、ストレージアクセスオフロード処理部６８２が読み出したデータを、特定のセッションで送信するように指示する。
【００９４】
ストレージアクセスオフロード処理部６８２は、ストレージ装置２０１からデータを順次読み出して、オフロードバッファ管理部６８３が管理する先頭アドレスからバッファにデータを書き込む。この時、ストレージアクセスオフロード処理部６８２は書き込みが完了したバッファ位置として、バッファ情報の末尾アドレスを順次更新していく。ＴＣＰ／ＩＰオフロード処理部６８１は、オフロードバッファ管理部６８３が管理しているバッファ情報の先頭アドレスから末尾アドレスまでのデータを順次読み出し、プロトコル処理を実施してネットワークへ送出する。この時、ＴＣＰ／ＩＰオフロード処理部６８１は、読み出しが完了したバッファ位置としてバッファ情報の先頭アドレスを順次更新していく。
【００９５】
このようにして、ストレージアクセスオフロード処理部６８２とＴＣＰ／ＩＰオフロード処理部６８１が、１つのバッファをリングバッファのように扱うことで、効率良く転送を行うことが可能になる。
【００９６】
（第３の実施形態）
図７は、第３の実施形態に係わる通信装置を示すブロック図である。第３の実施形態の通信装置１００１では、第１の実施形態のストレージ負荷判定部１１９に代えて、ストレージ異常判定部１３１を備える。その他の処理部は、第１の実施形態と同様であるため、拡張または変更された処理を除き説明を省略する。
【００９７】
ストレージ異常判定部１３１は、ストレージ装置２０１が正常に動作しているか、何らかの異常状態に陥っていないかの判定を行う。ストレージ装置２０１の異常状態とは、例えばストレージ装置２０１からの応答がない状態や、データ化けが発生して正しくデータにアクセスできない状態等のことである。異常状態を判定する方法としては、例えばＳＡＴＡなどのリンクエラーや、ＡＨＣＩのブロック単位のエラーで判定する方法等が考えられる。また、Ｓ．Ｍ．Ａ．Ｒ．Ｔに含まれるエラーレートや不良セクタ数、ＥＣＣエラー数、温度等を用いて、事前に設定した閾値を超えた場合に、異常状態であると判定する方法も考えられる。ストレージ異常判定部１３１は、ストレージ装置２０１の現在の状態を、振分処理部１１３に通知する。ストレージ異常判定部１３１は、ストレージ装置２０１の状態を表す情報を取得する状態取得部の一形態であり、一例として、上述したように、ＳＡＴＡなどのリンクエラーや、ＡＨＣＩのブロック単位のエラー等の情報を取得する。ストレージ異常判定部１３１は、当該取得した情報に基づき、ストレージ装置２０１が正常状態か異常状態かを判定する。
【００９８】
図８は、第３の実施形態に係わる通信装置１００１の動作を示すフローチャートである。以下では第１の実施形態との差分について述べる。
【００９９】
第３の実施形態では、振分処理部１１３に渡されたパケットが、既にキャッシュプロキシ処理が行われているセッションに属さない場合（Ｓ１５のＮｏ）、かつＳＹＮパケットの場合、振分処理部１１３は、ストレージ異常判定部１３１から現在、ストレージ装置２０１が正常に動作しているか、異常状態にあるかの状態を表す情報を取得する。ここで、ストレージ異常判定部１３１は、振分処理部１１３からの要求を受けてからストレージ装置２０１の異常有無を判定してもよいし、一定期間ごとにストレージ装置２０１の異常有無を判定しておき、振分処理部１１３からの要求を受けた時点で最新の判定結果を返してもよい。
【０１００】
振分処理部１１３は、ストレージ異常判定部１３１から取得した判定結果から、現在のストレージ装置２０１が正常動作している場合は、プロトコル処理部１１５へパケットを渡す。この時、当該パケットの処理がキャッシュプロキシ処理部１２２で行われることが明らかである場合（宛先ＩＰアドレスが自装置でなく、宛先ポート番号が予め定めたポート番号に一致することが振分処理部１１３で判断できる場合など）は、プロトコル処理部１１５を介さず直接、キャッシュプロキシ処理部１２２へパケットを渡すような形態でもよい。ストレージ装置２０１が異常の場合は、振分処理部１１３は、ブリッジ処理部１１４へパケットを渡す。
【０１０１】
一方、振分処理部１１３に渡されたパケットが、既にキャッシュプロキシ処理が行われているセッションに属する場合（Ｓ１５のＹｅｓ）、振分処理部１１３は、ストレージ異常判定部１３１から現在、ストレージ装置２０１が正常状態か、異常状態かを表す情報を取得する（Ｓ２２）。現在のストレージ装置２０１が正常動作している場合は、プロトコル処理部１１５へパケットを渡す（Ｓ１９）。ストレージ装置２０１が異常の場合は、振分処理部１１３は、ブリッジ処理部１１４へパケットを渡す（Ｓ１８）。
【０１０２】
図８に示した動作例では、パケットを受信し、宛先ＩＰアドレスが自装置のＩＰアドレスに一致しない場合（Ｓ１２のＮｏ）、現在のストレージ装置２０１の状態を判定している。別の動作例としては、パケットの受信処理とは独立にし、一度ストレージ装置２０１の異常状態を検知した後は、振分処理部１１３は、常にブリッジ処理部１１４へパケットを振り分ける構成にしてもよい。ストレージ装置２０１が故障して、アクセスが完全に不能になった場合などは、ストレージ装置２０１の状態をこれ以上確認する必要がないため効率的である。
【０１０３】
ストレージ装置２０１の異常状態が発生した場合は、通信装置１００１の管理者が、ストレージ装置２０１の交換またはファイルシステムの修復等によって、ストレージ装置２０１の復旧を行うことが想定される。復旧によりストレージ装置が再び正常に動作を開始した場合は、再度キャッシュプロキシ処理を行えばよい。この方が、性能および上位回線の帯域を低減する観点から望ましい。
【０１０４】
このため、ストレージ異常判定部１３１は、ストレージ装置が正常に動作を開始したことを検知して、振分処理部１１３にその旨を通知する機能を有してもよい。ストレージ装置が異常状態から正常状態に遷移したかの判定には、例えば、ｆｓｃｈｋなどのファイルシステムの復旧処理と連動して、ファイルシステムの復旧が正常に完了した場合は、振分処理部１１３にストレージ装置が正常状態である旨を通知する方法が考えられる。また、ストレージ装置の交換作業が行われる場合は、ｍｏｕｎｔ等のストレージ装置のｍｏｕｎｔ処理や、ｍｋｆｓ等の新規ファイルシステム作成などと連動して、正常に処理が完了した場合は、振分処理部１１３に正常状態を通知する方法が考えられる。また、ストレージ装置やストレージコントローラに発行されるコマンドやその応答等を監視して、異常状態から正常状態に遷移したと判定する方法も考えられる。また、アプリケーション部１２１に専用の処理部を設けて、ストレージ装置の復旧が完了した場合は、アプリケーション部１２１から明示的にストレージ装置が正常状態である旨を、振分処理部１１３に通知するような構成でもよい。
【０１０５】
このように、第３の実施形態によれば、ストレージ装置２０１が異常状態にある場合には、プロトコル処理およびキャッシュプロキシ処理をスキップして、ブリッジ処理を行うことにより、キャッシュプロキシ動作を除く最低限の通信装置１００１の処理（中継処理等）を継続することが可能になる。振分処理部１１３を設けずに、必ずプロトコル処理部１１５にパケットを受け渡し、キャッシュプロキシ処理部１２２などのアプリケーションにより、ストレージ装置２０１の異常有無を観測して、必要に応じてブリッジ処理部１１４にパケットを渡す方法も考えられる。しかしながら、この場合、ストレージ装置２０１が異常であった場合、無駄なプロトコル処理やアプリケーション処理がパケット毎に発生することになる。本実施形態では、プロトコル処理部１１５に渡す前にストレージ装置２０１の異常有無を判定することで、これらの無駄なオーバーヘッドを削減できるという効果もある。
【０１０６】
図９に、図７の通信装置のハードウェア構成例を示す。第２の実施形態に係る図３と同一または対応する部分には同一の符号を付して、拡張または変更された処理を除き、説明を省略する。
【０１０７】
図９の通信装置は、第１汎用処理部６１１と第２汎用処理部６１２を備え、ストレージ異常判定部１３１の機能を第２汎用処理部６１２で行う。また、この通信装置は、第１ストレージ装置２０１Ａと第２ストレージ装置２０１Ｂを備える。キャッシュプロキシアプリケーション以外の、通信装置の処理が最低限動作するために必要な、ソフトウェアスタック６４２と第２汎用処理部ファームウェア６４３を、容量の小さな第１ストレージ装置２０１Ａに格納する。そして、キャッシュ領域６４４を、容量の大きな第２ストレージ装置２０１Ｂに格納する。キャッシュ領域６４４は高頻度に読み書きが実行さるため、ストレージ装置２０１Ｂの故障確立が高まる。しかしながら、このように通信装置として最低限動作するために必要な情報を第２ストレージ装置２０１Ｂから分離することで、第２ストレージ装置２０１Ｂが異常状態に陥った場合にも、キャッシュプロキシ処理以外の最低限の通信装置としての動作を継続することができる。
【０１０８】
なお、各実施形態の通信装置は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することが可能である。すなわち、通信装置が備える各ブロックは、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現することができる。このとき、通信装置は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現してもよいし、ＣＤ−ＲＯＭなどの記憶媒体に記憶して、あるいはネットワークを介して上記のプログラムを配布して、このプログラムをコンピュータ装置に適宜インストールすることで実現してもよい。また、ストレージ装置は、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒなどの記憶媒体などを適宜利用して実現することができる。
【０１０９】
本実施形態で用いられる用語は、広く解釈されるべきである。例えば用語“プロセッサ”は、汎用目的プロセッサ、中央処理装置（ＣＰＵ）、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、コントローラ、マイクロコントローラ、状態マシンなどを包含してもよい。状況によって、“プロセッサ”は、特定用途向け集積回路、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラム可能論理回路（ＰＬＤ）などを指してもよい。“プロセッサ”は、複数のマイクロプロセッサのような処理装置の組み合わせ、ＤＳＰおよびマイクロプロセッサの組み合わせ、ＤＳＰコアと協働する１つ以上のマイクロプロセッサを指してもよい。
【０１１０】
別の例として、用語“メモリ”は、電子情報を格納可能な任意の電子部品を包含してもよい。“メモリ”は、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、プログラム可能読み出し専用メモリ（ＰＲＯＭ）、消去可能プログラム可能読み出し専用メモリ（ＥＰＲＯＭ）、電気的消去可能ＰＲＯＭ（ＥＥＰＲＯＭ）、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）、フラッシュメモリ、磁気または光学データストレージを指してもよく、これらはプロセッサによって読み出し可能である。プロセッサがメモリに対して情報を読み出しまたは書き込みまたはこれらの両方を行うならば、メモリはプロセッサと電気的に通信すると言うことができる。メモリは、プロセッサに統合されてもよく、この場合も、メモリは、プロセッサと電気的に通信していると言うことができる。
【０１１１】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【符号の説明】
【０１１２】
１０１：通信装置
１１１：第１通信処理部
１１２：第２通信処理部
１１３：振分処理部
１１４：ブリッジ処理部
１１５：プロトコル処理部
１１６：データアクセス部
１１７：リクエストキュー
１１８：ストレージ処理部
１１９：ストレージ負荷判定部
１２１：アプリケーション部
１２２：キャッシュプロキシ処理部（キャッシュプロキシアプリ）
１３１：ストレージ異常判定部
２０１：ストレージ装置
３０１Ａ、３０１Ｂ、３０１Ｃ：通信端末
４０１Ａ、５０１Ｂ：サーバ
５０１：ネットワーク
【図１】
2017058858.tif 000003
【図２】
2017058858.tif 000004
【図３】
2017058858.tif 000005
【図４】
2017058858.tif 000006
【図５】
2017058858.tif 000007
【図６】
2017058858.tif 000008
【図７】
2017058858.tif 000009
【図８】
2017058858.tif 000010
【図９】
2017058858.tif 000011