(57)【要約】  ネットワークストレージサーバー４００はボトムアップキャッシュ階層を有する。ボトムレベルキャッシュ４１２はＮＩＣとＨＢＡの組み合わせであるコントローラ４０にある。ネットワークへ出入りするストレージデータ１はボトムレベルキャッシュでキャッシュされ、これらのデータに関するメタデータ２は処理のためサーバーホスト４０２へ渡される。キャッシュデータがボトムレベルキャッシュの収容能力を超えるとき、データは、コントローラ上のメモリより大きいホストメモリへ移される。ネットワークからのストレージリード要求で、殆どのデータはストレージデバイス４１３からボトムレベルキャッシュを経てネットワークに渡される。同様に、ネットワークからのストレージライト要求で、殆どのデータは、ホストメモリ４１０へコピーすることなく、ボトムレベルキャッシュを経てストレージデバイスに書き込まれる。コントローラレベルでのデータキャッシュは、バストラフィックを削減し、ネットワーク型ストレージの性能向上をもたらす。【選択図】図４
2007510978.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに連結されたストレージサーバーであって、
中央プロセッサユニット（ＣＰＵ）及び第１のメモリを有するホストモジュールと、
ホストモジュールを連結するシステム相互接続部と、
プロセッサ、前記ネットワークに連結されたネットワークインターフェイス装置、ストレージサブシステムに連結されたストレージインターフェイス装置、及び第２のメモリを含む統合コントローラと、
を備え、
前記第２のメモリが、前記ネットワークへ読み出されるか、又は、前記ストレージサブシステムへ書き込まれるかするストレージデータを一時的に記憶する下位レベルキャッシュを画成し、リード要求又はライト要求が前記ストレージデータを前記第１のメモリによって画成された上位レベルキャッシュへロードすることなく処理される、ストレージサーバー。
【請求項２】
前記第２のメモリが前記ネットワークインターフェイス装置と前記ストレージインターフェイス装置とによって共用される、請求項１に記載のストレージサーバー。
【請求項３】
前記統合コントローラが、
前記プロセッサ、前記ネットワークインターフェイス装置、及び前記ストレージインターフェイス装置を連結する内部バスと、
前記プロセッサと前記第２のメモリを連結するメモリバスと
を含む、請求項１に記載のストレージサーバー。
【請求項４】
前記システム相互接続部がバスである、請求項３に記載のストレージサーバー。
【請求項５】
前記システム相互接続部がスイッチベースの装置である、請求項１に記載のストレージサーバー。
【請求項６】
Ｉ／Ｏ要求のストレージデータが前記下位レベルキャッシュで保持され、前記Ｉ／Ｏ要求のメタデータが前記Ｉ／Ｏ要求のヘッダを生成するために前記ホストモジュールへ送信される、請求項１に記載のストレージサーバー。
【請求項７】
前記Ｉ／Ｏ要求がリードデータ又はライトデータである、請求項６に記載のストレージサーバー。
【請求項８】
前記上位レベルキャッシュ及び前記下位レベルキャッシュを管理するキャッシュマネージャをさらに備える、請求項１に記載のストレージサーバー。
【請求項９】
前記キャッシュマネージャが前記ホストモジュールによって保持される、請求項８に記載のストレージサーバー。
【請求項１０】
前記キャッシュマネージャが前記上位レベルキャッシュ及び前記下位レベルキャッシュに格納されたデータを管理するハッシュテーブルを保持する、請求項９に記載のストレージサーバー。
【請求項１１】
前記ストレージサーバーがダイレクトアタッチドストレージシステムに設けられる、請求項１に記載のストレージサーバー。
【請求項１２】
前記ストレージサーバー及び前記ストレージサブシステムが同じ筐体内に設けられる、請求項１に記載のストレージサーバー。
【請求項１３】
前記ストレージサーバーがネットワークアタッチドストレージシステム又はストレージエリアネットワークシステムに設けられる、請求項１に記載のストレージサーバー。
【請求項１４】
ネットワークに連結されたストレージサーバーを管理する方法であって、
前記ネットワークを介してリモート装置からストレージデータに関するアクセス要求を前記ストレージサーバーで受信するステップと、
前記ストレージサーバーのホストモジュールの上位レベルキャッシュに前記ストレージデータを記憶することなく、前記アクセス要求に応答して、前記アクセス要求に関連付けられた前記ストレージデータを、前記ストレージサーバーの、前記ネットワークに連結された第１のインターフェイス及びストレージサブシステムに連結された第２のインターフェイスを有する統合コントローラの下位レベルキャッシュで記憶するステップと、
を備える方法。
【請求項１５】
前記アクセス要求がライト要求であり、
前記アクセス要求に関連付けられたメタデータを、システム相互接続部を介して、前記ホストモジュールへ送信し、その間に前記ストレージデータを前記統合コントローラで保持するステップをさらに備える、
請求項１４に記載の方法。
【発明の詳細な説明】
【関連出願の相互参照】
【０００１】
[0001]本願は、参照として本明細書に組み込まれた、２００３年１０月２０日に出願された米国仮特許出願第６０／５１２，７２８号の優先権を主張する。
【発明の背景】
【０００２】
[0002]本発明は、ネットワークに接続されたストレージサーバーに関する。
【０００３】
[0003]データは、すべてのコンピューティングプロセスの基礎である基本的なリソースである。近年のインターネットと電子ビジネスの爆発的な成長と共に、データストレージシステムに関する要求は非常に増大している。データストレージシステムは、１台以上のストレージサーバーと、１台以上のクライアント又はユーザシステムとを含む。ストレージサーバーは、クライアントのリード要求及びライト要求（Ｉ／Ｏ要求とも呼ばれる）を取り扱う。ストレージサーバーがＩ／Ｏ要求をより高速かつより効率的に取り扱えるようにするため多くの研究が振り向けられた。
【０００４】
[0004]ストレージサーバーのＩ／Ｏ要求処理能力は、ＣＰＵ性能及びネットワーク速度の劇的な増加をもたらした技術的進歩の結果として、過去１０年間に亘って劇的に向上した。同様に、データストレージシステムのスループットは、ＲＡＩＤ（安価なディスクの冗長アレイ）のようなストレージ装置レベルでのデータマネージメント技術の改良と、広範なキャッシュの使用とに起因して非常に向上した。
【０００５】
[0005]対照的に、ＰＣＩバスのようなシステム相互接続部の性能増加は、同じ期間中のＣＰＵ及び周辺機器の進歩に遅れをとる。その結果として、システム相互接続部は、高性能サーバーに対する主な性能ボトルネックになった。このボトルネック問題は、コンピュータアーキテクチャ及びシステムコミュニティによって広く理解されている。広範囲に亘る研究がこのボトルネック問題を解決するために行われた。この分野における一つの顕著な研究努力は、ＰＣＩをＰＣＩ−Ｘ又はＩｎｆｉｎｉＢａｎｄ（商標）で置き換えることによりシステム相互接続部の帯域幅を増加させることに関する。ＰＣＩ−Ｘは「ＰＣＩ拡張」を表し、１３３ＭＢｐｓから事実上１ＧＢｐｓまでＰＣＩの速度を改良する改良型ＰＣＩバスである。ＩｎｆｉｎｉＢａｎｄ（商標）技術は、より高い帯域幅を提供するため、共有バスとは対照的にスイッチファブリックを使用する。
【発明の簡単な概要】
【０００６】
[0006]本発明の実施形態は、システム相互接続部によるデータトラフィックを最小限に抑える改良されたキャッシュ構造を有するストレージサーバーに関する。ストレージサーバーでは、ボトムレベルキャッシュ（例えば、ＲＡＭ）は、ネットワークインターフェイスカード（ＮＩＣ）の機能とストレージ装置インターフェイス（例えば、ホストバスアダプタ）の機能を組み合わせる組み込みコントローラに存在する。ネットワークとの間で送受されるストレージデータは、このボトムレベルキャッシュでキャッシュされ、これらのストレージデータに関するメタデータだけが処理のためサーバーのＣＰＵシステム（「メインプロセッサ」とも称される）へ渡される。
【０００７】
[0007]キャッシュされたデータがボトムレベルキャッシュの収容能力を超えるとき、データは、通例的にコントローラ上のメモリよりはるかに大きいホストＲＡＭへ移される。コントローラ上のキャッシュはレベル−１（Ｌ−１）キャッシュと称され、メインプロセッサ上のキャッシュはレベル−２（Ｌ−２）キャッシュと称される。この新しいシステムは、トップレベルキャッシュが最小かつ最速であり、階層内で下位になるにつれて、キャッシュがより大きくなり、より遅くなる伝統的なトップダウンキャッシュに対して、ボトムアップキャッシュ構造（ＢＵＣＳ）と称される。
【０００８】
[0008]一実施形態では、ネットワークに連結されたストレージサーバーは、中央プロセッサユニット（ＣＰＵ）及び第１のメモリを含むホストモジュールと、ホストモジュールを連結するシステム相互接続部と、プロセッサ、ネットワークに連結されたネットワークインターフェイス装置、ストレージサブシステムに連結されたストレージインターフェイス装置、及び第２のメモリを含む統合コントローラとを含む。第２のメモリは、ネットワークへ読み出されるか、又は、ストレージサブシステムへ書き込まれるストレージデータを一時的に記憶する下位レベルキャッシュを画成するので、リード要求又はライト要求は、ストレージデータを第１のメモリによって画成された上位レベルキャッシュへロードすることなく処理され得る。
【０００９】
[0009]別の実施形態では、ネットワークに連結されたストレージサーバーを管理する方法は、ネットワークを介してリモート装置からストレージデータに関するアクセス要求をストレージサーバーで受信するステップを備える。アクセス要求に関連付けられたストレージデータは、アクセス要求に応答して、ストレージサーバーのホストモジュールの上位レベルキャッシュにストレージデータを記憶することなく、ストレージサーバーの統合コントローラであって、ネットワークに連結された第１のインターフェイス及びストレージサブシステムに連結された第２のインターフェイスを有する統合コントローラの下位レベルキャッシュで記憶される。
【００１０】
[0010]アクセス要求はライト要求である。アクセス要求に関連付けられたメタデータはシステム相互接続部を介してホストモジュールへ送信され、同時にストレージデータを統合コントローラで持ち続ける。この方法は、ホストモジュールで統合コントローラから受信されたメタデータを使用して記述子を生成するステップと、統合コントローラで記述子を受信するステップと、統合コントローラの第２のインターフェイスを介してストレージデータをストレージサブシステム内の適切なロケーションに書き込むために記述子を統合コントローラにおけるストレージデータに関連付けるステップとをさらに含む。
【００１１】
[0011]アクセス要求はリード要求であり、ストレージデータは第２のインターフェイスを介してストレージサブシステムから取得される。この方法は、最初にストレージデータをホストモジュールへ転送することなく、第１のインターフェイスを介してストレージデータをリモート装置へ送信するステップをさらに含む。
【００１２】
[0012]別の実施形態では、ストレージサーバーに設けられたストレージコントローラのための統合コントローラは、データを処理するプロセッサと、下位レベルキャッシュを画成するメモリと、ネットワークを介してリモート装置に連結された第１のインターフェイスと、ストレージサブシステムに連結された第２のインターフェイスとを含む。統合コントローラは、下位レベルキャッシュでリモート装置から受信されたライト要求に関連付けられたライトデータを一時的に記憶し、その後、ライトデータをストレージサーバーのホストモジュールに関連付けられた上位レベルキャッシュに記憶させることなく、第２のインターフェイスを介してライトデータをストレージサブシステムへ送信するように構成される。
【００１３】
[0013]さらに別の実施形態では、コンピュータ読み取り可能な媒体は、ネットワークを介してリモート装置からストレージサーバーで受信されたアクセス要求を取り扱うコンピュータプログラムを含む。このコンピュータプログラムは、ネットワークを介してリモート装置からストレージデータに関するアクセス要求をストレージサーバーで受信し、アクセス要求に応答して、ストレージサーバーのホストモジュールの上位レベルキャッシュにストレージデータを記憶することなく、ストレージサーバーの統合コントローラであって、ネットワークに連結された第１のインターフェイス及びストレージサブシステムに連結された第２のインターフェイスを有する統合コントローラの下位レベルキャッシュでアクセス要求に関連付けられたストレージデータを記憶するコードを備える。
【００１４】
[0014]アクセス要求はライト要求であり、プログラムは、アクセス要求に関連付けられたメタデータを、システム相互接続部を介して、ホストモジュールへ送信し、同時にストレージデータを統合コントローラで持ち続けるコードをさらに備える。記述子が統合コントローラから受信されたメタデータを使用してホストモジュールで生成され、統合コントローラへ送信され、このプログラムは、統合コントローラの第２のインターフェイスを介してストレージデータをストレージサブシステム内の適切なロケーションに書き込むために記述子を統合コントローラにおけるストレージデータに関連付けるコードをさらに備える。
【００１５】
[0015]アクセス要求はリード要求であり、ストレージデータは第２のインターフェイスを介してストレージサブシステムから取得される。コンピュータプログラムは、最初にストレージデータをホストモジュールへ転送することなく、第１のインターフェイスを介してストレージデータをリモート装置へ送信するコードをさらに備える。
【発明の詳細な説明】
【００１６】
[0025]本発明は、ストレージシステム内のストレージサーバーに関する。一実施形態では、ストレージサーバーは、下位レベルキャッシュがＩ／Ｏ要求を処理するため高い頻度で使用されるボトムアップキャッシュ構造（ＢＵＣＳ）を備えている。本明細書で使用されるように、下位レベルキャッシュ又はメモリは、ホストモジュールのＣＰＵに直接的に割り当てられたキャッシュ又はメモリを指す。
【００１７】
[0026]このようなストレージサーバーにおいて、Ｉ／Ｏ要求に関連付けられたストレージデータは、伝統的なトップダウンキャッシュ階層において高い頻度で使用されるデータができるだけ上位レベルキャッシュに入れられるのに対して、システムバス又は相互接続部によるデータトラフィックを最小限に抑えるためにできるだけ下位レベルキャッシュで持ち続けられる。ネットワークからのストレージリード要求に関して、殆どのデータは、ハードドライブ又はＲＡＩＤのようなストレージ装置からボトムレベルキャッシュを介してネットワークへ直接的に渡される。同様に、ネットワークからのストレージライト要求に関して、殆どのデータは、既存のシステムの場合のように、それらを上位レベルキャッシュ（「メインメモリ又はキャッシュ」とも称される）へコピーすることなく、下位レベルキャッシュを介してストレージ装置へ直接的に書き込まれる。
【００１８】
[0027]コントローラレベルにおけるこのようなデータのキャッシュ化は、ＰＣＩバスのようなシステムバス上のトラフィックを劇的に削減し、ネットワーク型データストレージ操作のすばらしい性能向上をもたらすことになる。インテル（Ｉｎｔｅｌ）のＩＱ８０３１０リファレンスボード及びリナックス（Ｌｉｎｕｘ）ＮＢＤ（ネットワークブロック装置）を使用する一つの実験では、ＢＵＣＳは、ほとんど３倍の倍率で従来のシステムによる応答時間及びシステムスループットを改善する。
【００１９】
[0028]図１Ａ〜１Ｃは、情報インフラストラクチャにおける種々のタイプのストレージシステムを示す。図１Ａは例示的なダイレクトアタッチドストレージ（ＤＡＳ）システム１００を図示する。ＤＡＳシステムは、ネットワーク１０６を介してストレージサーバー１０４に連結されたクライアント１０２を含む。ストレージサーバー１０４は、データを使用又は生成するアプリケーション１０８と、データを管理するファイルシステム１１０と、データを記憶するストレージサブシステム１１２とを含む。ストレージサブシステムは、磁気ディスク装置、光ディスク装置、テープベースの装置などである１台以上のストレージ装置を含む。ストレージサブシステムは一実施形態においてはディスクアレイ装置である。
【００２０】
[0029]ＤＡＳは、ストレージサブシステムとサーバーとの間の専用通信リンクを介してストレージサブシステムをサーバーへローカルに取り付ける従来の方法である。ＳＣＳＩコネクションがＤＡＳを実施するため一般に使用される。サーバーは、典型的にブロックレベルインターフェイスを使用してストレージサブシステムと通信する。サーバーに常駐するファイルシステム１１０は、アプリケーション１０８からのファイル要求（又はＩ／Ｏ要求）を完了するためにストレージサブシステム１１２から必要とされるデータブロックを決定する。
【００２１】
[0030]図１Ｂは例示的なストレージエリアネットワーク（ＳＡＮ）システム１２０を図示する。システム１２０は、第１のネットワーク１２６を介してストレージサーバー１２４に連結されたクライアント１２２を含む。サーバー１２４はアプリケーション１２３及びファイルシステム１２５を含む。ストレージサブシステム１２８は第２のネットワーク１３０を介してストレージサーバー１２４に連結される。第２のネットワーク１３０は、ストレージサブシステム、バックアップストレージサブシステム、及びストレージサーバーを接続するため設けられたネットワークである。第２のネットワークはストレージエリアネットワークのように称される。ＳＡＮは一般的にＦＩＣＯＮ（商標）又はファイバーチャネルを用いて実施される。ＳＡＮは、単一キャビネットに設けられるか、又は、多数の地理的位置を橋渡しする。ＤＡＳと同様に、ＳＡＮサーバーはストレージサブシステム１２８へブロックレベルインターフェイスを与える。
【００２２】
[0031]図１Ｃは例示的なネットワークアタッチドストレージ（ＮＡＳ）システム１４０を図示する。システム１４０は、ネットワーク１４６を介してストレージサーバー１４４に連結されたクライアント１４２を含む。サーバー１４４はファイルシステム１４８及びストレージサブシステム１５０を含む。アプリケーション１５２はネットワーク１４６とクライアント１４２との間に設けられる。固有のファイルシステムをもつストレージサーバー１４４はネットワーク１４６へ直接的に接続され、このネットワークはＬＡＮによってＮＦＳ及びＳＭＢ／ＣＩＦＳのような業界標準ネットワークファイルシステムインターフェイスに応答する。ファイル要求（又はＩ／Ｏ要求）はクライアントからファイルシステム１４８へ直接的に送信される。ＮＡＳサーバー１４４はストレージサブシステム１５０にファイルレベルインターフェイスを提供する。
【００２３】
[0032]図２は、ストレージサーバー２０２及びストレージサブシステム２０４を含む例示的なストレージシステム２００を図示する。サーバー２０２は、ＣＰＵ２０８、メインメモリ２１０及び不揮発性メモリ２１２を含むホストモジュール２０６を含む。一実施形態では、メインメモリとＣＰＵは、これらの２個のコンポーネント間の通信を高速化するため専用バス２１２を介して相互に接続される。メインメモリはＲＡＭであり、ＣＰＵによってメインキャッシュとして使用される。不揮発性メモリは本実施形態ではＲＯＭであり、ＣＰＵによって実行されるプログラム又はコードを記憶するため使用される。ＣＰＵはさらにメインプロセッサのように称される。
【００２４】
[0033]ストレージサーバー２０２は、モジュール２０６、ディスクコントローラ２１４、ネットワークインターフェイスカード（ＮＩＣ）２１６を一緒に連結するメインバス２１３（又はシステム相互接続部）を含む。一実施形態では、メインバス２１３はＰＣＩバスである。ディスクコントローラはペリフェラルバス２１８によってストレージサブシステム２０４へ連結される。一実施形態では、ペリフェラルバスは、ＳＣＳＩバスである。ＮＩＣはネットワーク２２０に連結され、ネットワークとストレージサーバー２０２との間で通信インターフェイスとして機能する。ネットワーク２２０はサーバー２０２を、クライアント１０２、１２２又は１４２のようなクライアントに連結する。
【００２５】
[0034]図１Ａ〜図２を参照すると、異なる技術に基づくストレージシステムは異なるコマンドセット及び異なるメッセージフォーマットを使用するが、ネットワークを通るデータフロー及びサーバー内部のデータフローは数多くの点で類似する。リード要求に関して、クライアントは、コマンド及びメタデータを含むリード要求をサーバーへ送信する。メタデータは要求されたデータのロケーション及びサイズに関する情報を提供する。パケットを受信すると、サーバーは要求を確認し、要求されたデータを含む１個以上のパケットをクライアントへ送信する。
【００２６】
[0035]ライト要求に関して、クライアントは、メタデータと、その後に続いてライトデータを含む１個以上のパケットとを含むライト要求をサーバーへ送信する。ライトデータは、ある実施形態において、ライト要求自体に含まれてもよい。サーバーはライト要求を確認し、ライトデータをシステムメモリへコピーし、データをその取り付けられたストレージサブシステム内の適切なロケーションへ書き込み、肯定応答をクライアントへ送信する。
【００２７】
[0036]用語「クライアント」及び「サーバー」は本文書では広義に使用される。例えば、ＳＡＮシステムにおいて、要求を送信するクライアントはサーバー１２４であり、要求を処理するサーバーはストレージサブシステム１２８である。
【００２８】
[0037]図３は、従来技術によるリード／ライト要求に応答するストレージサーバー３００内部の例示的なデータフローを図示する。サーバーは、ホストモジュール３０２、ディスクコントローラ３０４、ＮＩＣ３０６、及びこれらのコンポーネントを連結する内部バス（又はメインバス）３０８を含む。モジュール３０２は、メインプロセッサ（図示せず）及び上位レベルキャッシュ３１０を備える。ディスクコントローラ３０４は、第１のデータバッファ（又は下位レベルキャッシュ）３１２を含み、ディスク３１３（又はストレージサブシステム）に連結される。ディスク／ストレージサブシステムは、ＮＡＳ若しくはＤＡＳシステムのサーバーへ直接的に取り付けられるか、又は、リンクされるか、或いは、ＳＡＮシステム内のネットワークを介してサーバーへ連結される。ＮＩＣ３０６は、第２のデータバッファ３１４を含み、ネットワークを介してクライアント（図示せず）に連結される。内部バス３０８はシステム相互接続部であり、本実施形態ではＰＣＩバスである。
【００２９】
[0038]動作中、ＮＩＣ３０６を介してクライアントからリード要求を受信すると、モジュール３０２（又はサーバーのオペレーションシステム）は、要求されたデータがメインキャッシュ３１０にあるかどうかを判定する。もしあるならば、メインキャッシュ３１０のデータが処理され、クライアントへ送信される。もしないならば、モジュール３０２は、ディスクコントローラ３０４へのＩ／Ｏ操作を呼び出し、ＰＣＩバス３０８を介してディスク３１３からデータをロードする。データがメインキャッシュへロードされた後、メインプロセッサはヘッダを生成し、ＰＣＩバスを介してＮＩＣへ転送される応答パケットを組み立てる。ＮＩＣは、次に、パケットをクライアントへ送信する。その結果、データはＰＣＩバスによって２回移動させられる。
【００３０】
[0039]ＮＩＣ３０６を介してクライアントからライト要求を受信すると、モジュール３０２は、最初にＰＣＩバスを介してＮＩＣからメインキャッシュ３１０へデータをロードし、次に、そのデータをＰＣＩバスによってディスク３１３に格納する。データはライト操作に関してＰＣＩバスを２回移動する。したがって、サーバー３００は、従来の方法の下でＩ／Ｏ要求を完了するためにＰＣＩバスを高い頻度で使用する。
【００３１】
[0040]図４は本発明の一実施形態によるストレージサーバー４００を図示する。ストレージサーバー４００は、ホストモジュール４０２、ＢＵＣＳコントローラ４０４、及びこれらの２個のコンポーネントを連結する内部バス４０６を含む。モジュール４０２は、キャッシュマネージャ４０８、及びメインすなわち上位レベルキャッシュ４１０を含む。ＢＵＣＳコントローラ４０４は下位レベルキャッシュ４１２を含む。ＢＵＣＳコントローラは、ネットワークを介して、ディスク４１３及びクライアント（図示せず）に連結される。したがって、ＢＵＣＳコントローラは、ディスクコントローラ３０４の機能とＮＩＣ３０６の機能を組み合わせ、「統合コントローラ」と称される。ディスク４１３は、サーバー４００に直接的に取り付けられたストレージサブシステム内にあっても、ネットワークを介してサーバー４００に連結されたリモートストレージサブシステム内にあってもよい。サーバー４００は、実施に応じて、ＤＡＳ、ＮＡＳ又はＳＡＮシステムに設けられたサーバーである。
【００３２】
[0041]ＢＵＣＳアーキテクチャでは、データは、内部バスによってデータを行き来させるのではなく、できる限り下位レベルキャッシュで持ち続けられる。ストレージデータを記述するメタデータと操作を記述するコマンドは処理のためモジュール４０２へ転送され、一方、対応するストレージデータは下位レベルキャッシュ４１２で持ち続けられる。したがって、殆どのストレージデータは、トラフィックボトルネックを回避するために、内部又はＰＣＩバス４０６によって上位レベルキャッシュ４１０へ転送されない。下位レベルキャッシュ（すなわち、Ｌ−１キャッシュ）は通常は電力及び費用の制約のために制限されるので、上位レベルキャッシュ（すなわち、Ｌ−２キャッシュ）がＩ／Ｏ要求を処理するためＬ−１キャッシュと共に使用される。キャッシュマネージャ４０８はこの２レベルの階層を管理する。本実施形態では、キャッシュマネージャはサーバーのオペレーションシステムのカーネルに常駐する。
【００３３】
[0042]図４を再度参照すると、リード要求に関して、キャッシュマネージャ４０８は、データがＬ−１キャッシュにあるか、又は、Ｌ−２キャッシュにあるかをチェックする。データがＬ−１キャッシュにあるならば、モジュール４０２は、ヘッダを準備し、ネットワークインターフェイス（図５を参照）を通るネットワークによってデータパケットを要求元クライアントへ送信するためにＢＵＣＳコントローラを呼び出す。データがＬ−２キャッシュにあるならば、キャッシュマネージャ４０８は、ネットワークを介してクライアントへ送信されるようにＬ−２キャッシュからＬ−１キャッシュへデータを移動する。データがストレージ装置、すなわち、ディスク４１３にあるならば、キャッシュマネージャは、データを読み出し、Ｌ−１キャッシュへそのままデータをロードする。本実施形態では、両方の場合に、ホストモジュールはパケットヘッダを生成し、それらをＢＵＣＳコントローラへ転送する。コントローラはヘッダとデータを組み立て、次に、組み立てられたパケットを要求元クライアントへ送信する。
【００３４】
[0043]ライト要求に関して、ＢＵＣＳコントローラは、データパケットに含まれるデータの固有識別子を生成し、ホストにこの識別子を通知する。ホストは、次に、メタデータを対応する前のコマンドパケット内のこの識別子に添付する。実際のライトデータはＬ−１キャッシュに保存され、次に、ストレージ装置内の正しいロケーションに書き込まれる。その後、サーバーは肯定応答をクライアントへ送信する。したがって、ＢＵＣＳアーキテクチャは、ＰＣＩバスによる大量データの転送を最小限に抑える。もっと正確には、ＩＯ要求のコマンド部分とメタデータだけが、可能ならいつでもＰＣＩバスを介してホストモジュールへ送信される。
【００３５】
[0044]本文書で使用されるように、用語「メタ情報」は要求又はパケット内の管理データを指す。すなわち、メタ情報は、パケット（例えば、Ｉ／Ｏ要求）内の実際のリードデータ又はライトデータではない情報又はデータである。したがって、メタ情報は、メタデータ、ヘッダ、コマンド部分、データ識別子、その他の管理情報、又は、これらの要素の任意の組み合わせを指す。
【００３６】
[0045]ストレージサーバー４００では、データパケットからコマンドパケットを分離し、コマンドパケットをホストへ転送するハンドラが設けられる。ハンドラは、本発明によるＢＵＣＳコントローラで動くプログラムの一部として実施される。ハンドラはＢＵＣＳコントローラ内の不揮発性メモリに格納される（図５を参照）。
【００３７】
[0046]好ましくは、異なるプロトコルはそれらの固有の特定のメッセージフォーマットを有するので、ハンドラはネットワークストレージプロトコル毎に設けられる。新たに作成されたネットワークコネクションに対し、コントローラ４０４は、最初に、そのコネクションが属するコネクションを決定するために、すべてのハンドラを使用することを試みる。ネットワークストレージサービスを提供する周知のポートに関して、コネクション設定の最初でハンドラ探索手続きを回避するため、特定のハンドラがそれらのために設けられる。プロトコルが既知であり、対応するハンドラが決定されると、コネクションが終了するまで、選択されたハンドラがコネクション上の残りのデータ操作のため使用される。
【００３８】
[0047]図５は本発明の一実施形態によるＢＵＣＳ又は統合コントローラ５００を示す。コントローラ５００は、ディスク／ストレージコントローラの機能及びＮＩＣの機能を統合する。コントローラは、プロセッサ５０２、メモリ（「下位レベルキャッシュ」とも称される）５０４、不揮発性メモリ５０６、ネットワークインターフェイス５０８、及びストレージインターフェイス５１０を含む。専用バスであるメモリバス５１２は、これらのコンポーネントのための高速通信パスを提供するためにキャッシュ５０４をプロセッサ４０２に接続する。内部バス５１４はコントローラ５００内の種々のコンポーネントを連結し、ＰＣＩバス又はＰＣＩ−Ｘバス又はその他の適当なタイプである。ペリフェラルバス５１６は不揮発性メモリ５０６をプロセッサ５０２に連結する。
【００３９】
[0048]不揮発性メモリ５０６は、本実施形態におけるファームウェアを格納するフラッシュＲＯＭである。フラッシュＲＯＭに格納されたファームウェアは、組み込みＯＳコードと、ストレージコントローラの機能に関するマイクロコード、例えば、ＲＡＩＤ機能コードと、ある種のネットワークプロトコル機能とを含む。ファームウェアはストレージサーバーのホストモジュールを使用してアップグレードされる。
【００４０】
[0049]本実施形態では、ストレージインターフェイス５１０は、装着されたディスクを制御するストレージコントローラチップであり、ネットワークインターフェイスは、パケットを送受信するネットワーク媒体アクセス制御（ＭＡＣ）チップである。
【００４１】
[0050]メモリ５０４はＲＡＭであり、Ｌ−１キャッシュを提供する。メモリ５０４は、好ましくは、大規模であり、例えば、１ＧＢ以上である。メモリ５０４は共有メモリであり、ストレージインターフェイス及びネットワークインターフェイスの機能を提供するためにストレージ及びネットワークインターフェイス５０８及び５１０と共に使用される。別個のストレージインターフェイス（又はホストバスアダプタ）とＮＩＣインターフェイスをもつ従来のサーバーシステムでは、ストレージＨＢＡ上のメモリとＮＩＣ上のメモリは物理的に分離され、ピア間での相互アクセスを困難にする。ＨＢＡとＮＩＣの融合は、データの単一コピーが異なるサブシステムによって参照されることを可能にさせ、高性能をもたらす。
【００４２】
[0051]本実施形態では、オンボードＲＡＭ、すなわち、メモリ５０４は２個の部分に区分される。一方の部分は、オンボードオペレーションシステム（ＯＳ）とコントローラ５００上で動くプログラムのため確保される。もう一方、すなわち、主たる部分は、ＢＵＣＳ階層のＬ−１キャッシュとして使用される。同様に、モジュール４０２のメインメモリ４１０の区分はＬ−２キャッシュのため確保される。キャッシュ化の基本ユニットは、ファイルシステムレベルプロトコルのファイルブロック又はブロックレベルストレージプロトコルのためのディスクブロックである。
【００４３】
[0052]キャッシュ化の基本データユニットとしてブロックを使用することは、ストレージサーバーがネットワーク要求パケットとは無関係にキャッシュ内容を保持することを可能にする。キャッシュマネージャ４０８はこの２レベルのキャッシュ階層を管理する。キャッシュされたデータは、データブロックのオンディスクオフセットをそのハッシュキーとして使用するハッシュ化テーブル４１４によって組織化され管理される。テーブル４１４は、キャッシュマネージャ４０８の一部分として、又は、別個のエンティティとして格納される。
【００４４】
[0053]基本ハッシュエントリーは、ストレージ装置上のデータオフセット、ストレージ装置識別子、データのサイズ、ハッシュテーブルキューのリンクポインタ、キャッシュポリシーキューのリンクポインタ、データポインタ、及び状態フラグを含む複数の項目を収容する。状態フラグの各ビットは、データがＬ−１キャッシュであるか、又は、Ｌ−２キャッシュであるか、データがダーティデータであるかどうか、エントリー及びデータが操作中にロックされているかどうかなどの様々な状態を示す。
【００４５】
[0054]データは物理メモリ内に不連続的に格納されるので、ｉｏｖｅｃ（Ｉ／Ｏベクトルデータ構造）の構造が一つの一つのデータを表現する。各ｉｏｖｅｃ構造は、メモリ内で連続し、スキャッタ・ギャザー方式ＤＭＡによって直接的に使用される一つのデータのアドレス及び長さを格納する。各ハッシュエントリーのサイズは一実施例では約２０バイトである。各エントリーによって表現されるデータの平均サイズが４０９６バイトであるならば、ハッシュエントリーコストは５％未満である。データブロックがＬ−１又はＬ−２キャッシュに追加されるとき、新しいキャッシュエントリーは、キャッシュマネージャによって作成され、このデータブロックに関するメタデータが詰められ、ハッシュテーブル内の適当な場所に挿入される。
【００４６】
[0055]ハッシュテーブルは実施に応じて異なる場所に保存され、１）ＢＵＣＳコントローラはＬ−１キャッシュとＬ−２キャッシュの両方のためのハッシュテーブルをオンボードメモリに保存し、２）ホストモジュールはすべてのメタデータをメインメモリに保存し、３）ＢＵＣＳコントローラ及びホストモジュールはそれらの固有のキャッシュされたメタデータを個別に保存する。
【００４７】
[0056]好ましい実施形態では、第２の方法がホストモジュールに常駐するキャッシュマネージャにＬ−１キャッシュとＬ−２キャッシュの両方のためのメタデータを保持させるため採用される。キャッシュマネージャは、キャッシュマネージメントタスクを終えるために、異なるメッセージを、ＡＰＩを介して、スレーブとして機能するＢＵＣＳコントローラへ送信する。ネットワークストレージプロトコルはホストモジュール側で殆ど処理され、ホストモジュールは、キャッシュされたデータに関するメタデータを、ＢＵＣＳコントローラよりも容易に抽出し取得することができるので、第２の方法が本実施形態では優先される。他の実施形態では、ＢＵＣＳコントローラがこのようなタスクを取り扱う。
【００４８】
[0057]最長不使用アルゴリズム（ＬＲＵ）置換ポリシーは、キャッシュが満杯になったとき、キャッシュに入れられる新しいデータのための場所を作るためにキャッシュマネージャ４０８において実施される。一般に、最も高い頻度で使用されるデータはＬ−１キャッシュで持ち続けられる。Ｌ−１キャッシュが満杯になると、最長期間に亘ってアクセスされなかったデータがＬ−１キャッシュからＬ−２キャッシュへ移される。キャッシュマネージャは、このようなデータ再配置を反映させるためにハッシュテーブル内の対応するエントリーを更新する。データがＬ−２キャッシュからディスクストレージへ移されるならば、ハッシュエントリーはハッシュテーブルから解放され、キャッシュマネージャによって放棄される。
【００４９】
[0058]Ｌ−２キャッシュ内の一つのデータが再度アクセスされ、Ｌ−１キャッシュに入れられる必要があるとき、それはＬ−１キャッシュへ返送される。Ｌ−２キャッシュ内のデータがディスクドライブへ書き込まれる必要があるとき、そのデータは、ＢＵＣＳコントローラへ転送され、Ｌ−１キャッシュを使うことなく、ＢＵＣＳコントローラによって直接的にディスクドライブへ書き込まれる。このようなライト操作はオンボードＯＳ  ＲＡＭ空間の一部として確保されたバッファを経由する。
【００５０】
[0059]ＢＵＣＳは従来のストレージコントローラ及びＮＩＣを統合ＢＵＣＳコントローラで置き換えるので、ホストＯＳとインターフェイスコントローラとの間の相互作用は変更される。本実施形態では、ホストモジュールは、ある付加的な機能をもつＮＩＣとしてＢＵＣＳコントローラを取り扱うので、新しい装置のクラスは作成される必要がなく、ＯＳカーネルへの変更を最小限に留める。
【００５１】
[0060]ホストＯＳでは、ＯＳの他の部分によって利用される複数のＡＰＩをエクスポートするためにコードが付加され、さらに対応するマイクロコードがＢＵＣＳコントローラに設けられる。ＡＰＩ毎に、ホストＯＳは特定のコマンドコード及びパラメータをＢＵＣＳコントローラのレジスタに書き込み、コマンドディスパッチャは、希望のタスクを終えるために対応する搭載マイクロコードを呼び出す。ＡＰＩはＢＵＣＳコントローラの不揮発性メモリに格納されるか、又は、ホストＯＳの一部としてＲＡＭにロードされる。
【００５２】
[0061]提供される１個のＡＰＩは初期化ＡＰＩのｂｕｃｓ．ｃａｃｈｅ．ｉｎｉｔ（）である。ホストモジュールの起動中に、ＢＵＣＳコントローラ上のマイクロコードは、オンボードメモリを検出し、そのメモリの一部分を内部使用のため用意し、メモリの残りの部分をＬ−１キャッシュのため確保する。ホストＯＳは初期化中にこのＡＰＩを呼び出し、Ｌ−１キャッシュサイズを取得する。ホストＯＳはさらに起動時にＬ−２キャッシュを検出する。Ｌ−１キャッシュ及びＬ−２キャッシュに関する情報を取得した後、ホストＯＳは、初期化を終了するためにハッシュテーブル及びその他のデータ構造をセットアップする。
【００５３】
[0062]図７は本発明の一実施形態によるリード要求を実行するプロセス７００を図示する。ホストがクライアントからのリード要求のためのデータを発送する必要があるとき、ホストはデータのロケーションを見つけるためにハッシュテーブルをチェックする（ステップ７０２）。データ又はデータの一部分は、Ｌ−１キャッシュとＬ−２キャッシュとストレージ装置を含む三カ所の考えられる場所にある。一つ一つのデータに対し、ホストは、その情報と実行されるべき動作に関する記述子を生成する（ステップ７０４）。Ｌ−１キャッシュ内のデータに関して、プロセッサ５０２はそのデータをそのまま発送する。Ｌ−２キャッシュ内のデータに関して、ホストはＬ−１キャッシュ内にこのデータのための新しいロケーションを与え、ＤＭＡによってそのデータをＬ−２キャッシュからＬ−１キャッシュへ移し、それを発送する。ディスクドライバ上のデータについて、ホストはＬ−１キャッシュ内に新しいロケーションを見つけ、プロセッサにディスクドライブからそのデータを読み出させ、そのデータをＬ−１キャッシュに入れる。このディスク操作中にＬ−１キャッシュが満杯であるならば、ホストは、Ｌ−１キャッシュ内のどのデータがＬ−２キャッシュへ移されるかをさらに決定し、データ再配置のためのソースアドレス及びデスティネーションアドレスを提供する。これらの記述子は、実際の操作を実行するためにＡＰＩ  ｂｕｃｓ．ａｐｐｅｎｄ．ｄａｔａ（）によってプロセッサ５０２へ送信される（ステップ７０６）。受信された記述子毎に、プロセッサはパラメータをチェックし、リード操作を終了するために異なるマイクロコードを呼び出す（ステップ７０８）。
【００５４】
[0063]図８は本発明の一実施形態によるライト要求を実行するプロセス８００を図示する。クライアントからのライト要求に対し、ホストモジュールはコマンドパケットを取得し、Ｌ−１キャッシュ内のロケーションを指定する（ステップ８０２）。キャッシュマネージャを使用するホストモジュールは、Ｌ−１キャッシュが受信されるライトデータのための十分な空き領域を欠くならば、Ｌ−１キャッシュ内のアクセス頻度の低いデータをＬ−２キャッシュへ再配置する。ホストモジュールは、このとき、コマンドパケットに続く後続のデータパケットを読むためにＡＰＩ  ｂｕｃｓ．ｒｅａｄ．ｄａｔａ（）を使用する（ステップ８０４）。ホストＯＳは、次に、プロセッサ５０２にそのデータをそのままＬ−１キャッシュへ入れさせる（ステップ８０６）。
【００５５】
[0064]ホストモジュールがデータをそのままディスクドライブへ書き込みたいとき、ＡＰＩ  ｂｕｃｓ．ｗｒｉｔｅ．ｄａｔａ（）が呼び出される（ステップ８０８）。ホストモジュールは、Ｌ−１又はＬ−２内のデータロケーション、データサイズ、及びディスク上のロケーションを含む書き込まれるデータの記述子を提供する。データは、次に、プロセッサ５０２によって、オンボードＯＳのため確保されたＲＡＭ空間の一部分であるプロセッサバッファへ転送され、ディスクに書き込まれる（ステップ８１０）。
【００５６】
[0065]主要な操作を補助するためＢＵＣＳシステムにはある種のその他のＡＰＩが規定されている。例えば、ＡＰＩ  ｂｕｃｓ．ｄｅｓｔａｇｅ．Ｌ−１（）は、Ｌ−１キャッシュからＬ−２キャッシュへデータをデステージするため設けられる。ＡＰＩ  ｂｕｃｓ．ｐｒｏｍｐｔ．Ｌ−２（）はＬ−２キャッシュからＬ−１キャッシュへデータを移動する。これらのＡＰＩは、必要に応じてＬ−１キャッシュとＬ−２キャッシュを動的にバランスさせるためキャッシュマネージャによって使用される。
【００５７】
[0066]ＢＵＣＳシステムでは、ストレージコントローラ及びＮＩＣは、両方の機能を統合し、統一されたキャッシュメモリを有するＢＵＣＳコントローラによって置き換えられる。これは、一旦データがストレージデバイスから読み出されると、Ｉ／Ｏバス、ホストＣＰＵ及びメインメモリを呼び出すことなく、データをネットワークへ発送することを可能にさせる。高い頻度で使用されるデータをオンボードキャッシュメモリ（Ｌ−１キャッシュ）に入れることにより、多数のリード要求が直接的に満たされる。クライアントからのライト要求は、バストラフィックを呼び出すことなく、データを直接的にＬ−１キャッシュへ置くことによって満たされる。Ｌ−１キャッシュ内のデータは、必要に応じてホストメモリ（Ｌ−２キャッシュ）へ再配置される。有効なキャッシュ化ポリシーを用いて、この多重レベルキャッシュは、ネットワーク型ストレージデータアクセスのための高速かつ大型のキャッシュを提供する。
【００５８】
[0067]本発明は、当業者が発明を実施することができるように特定の実施形態又は実施の観点から説明されている。開示された実施形態又は実施は、発明の範囲から逸脱することなく修正又は変更される。例えば、内部バスは、ＰＣＩ−Ｘバスでもよく、又は、スイッチファブリック、例えば、ＩｎｆｉｎｉＢａｎｄ（商標）でもよい。したがって、発明の範囲は特許請求の範囲を使用して定められるべきである。
【図面の簡単な説明】
【００５９】
【図１Ａ】例示的なダイレクトアタッチドストレージ（ＤＡＳ）システムを図示する。
【図１Ｂ】例示的なストレージエリアネットワーク（ＳＡＮ）システムを図示する。
【図１Ｃ】例示的なネットワークアタッチドストレージ（ＮＡＳ）システムを図示する。
【図２】ストレージサーバー及びストレージサブシステムを含む例示的なストレージシステムを図示する。
【図３】従来技術によるリード／ライト要求に応答するストレージサーバー内部の例示的なデータフローを図示する。
【図４】本発明の一実施形態によるストレージサーバーを図示する。
【図５】本発明の一実施形態によるＢＵＣＳすなわち統合コントローラを図示する。
【図６】本発明の一実施形態によるリード要求を実行するプロセスを図示する。
【図７】本発明の一実施形態によるライト要求を実行するプロセスを図示する。
【図１Ａ】
2007510978.tif 000003
【図１Ｂ】
2007510978.tif 000004
【図１Ｃ】
2007510978.tif 000005
【図２】
2007510978.tif 000006
【図３】
2007510978.tif 000007
【図４】
2007510978.tif 000008
【図５】
2007510978.tif 000009
【図６】
2007510978.tif 000010
【図７】
2007510978.tif 000011
【国際調査報告】
2007510978.tif 000012