JP2011222011A - リモート・ダイレクト・ストレージ・アクセス - Google Patents

Abstract

【課題】半導体ストレージのリモート・ダイレクト・アクセスに関するシステム、装置、及び方法を提供する。
【解決手段】サーバのネットワーク・インターフェース・コンポーネント（ＮＩＣ）は、サーバの中央処理ユニット（ＣＰＵ）及びメインメモリを迂回するネットワーク・ストレージ・アクセス・リンクによって、半導体ストレージモジュールにアクセスする。ＮＳＡリンクは、半導体ストレージのリニアな「メモリビュー」にリモート・エンティティーを提供するために、リモート・ダイレクト・メモリ・アクセス（ＲＤＭＡ）をサポートする。ＮＳＡリンクは、ＮＩＣ及びストレージ・コントローラと直接接続するアービターを含んでもよい。
【選択図】図１

Description

本発明の実施形態は、ストレージ分野、より具体的にはリモート・ダイレクト・ストレージ・アクセスに関する。

半導体デバイス（ＳＳＤ）は、ブロック指向のストレージ・コンセプトを用いて、例えばＮＡＮＤ半導体デバイス等の不揮発性フラッシュメモリを概念化する。オペレーティング・システム（ＯＳ）は、ブロックレベル・アドレスを有するストレージ・コマンドをストレージ・コントローラに対して発行する。ストレージ・コントローラは、ウェアレベリング・アルゴリズムに従ってブロックレベル・アドレスを翻訳し、翻訳したアドレスに対応するストレージ・アクセス・コマンドを発行する。このように、ストレージ・コントローラは、ユーザに意識させないで、フラッシュ・デバイスを横断して、リード／ライト・アクセスをＯＳにとどけることができる。一方で、ストレージ・コントローラへのブロックレベル・コマンドの発行は、ローカル・システムの状態が既知であることを要求する。これは、フラッシュ・デバイスのネットワークへのアクセス可能性を含むだろう。

本発明の実施形態は、添付の図面を伴う以下の詳細な説明によって、容易に理解されるであろう。説明を分かり易くするために、構成要素の類に符号等を与える。発明の実施形態は、例として説明され、添付の図面の形状に限定されない。
様々な実施形態にしたがったサーバを説明している。 様々な実施形態にしたがった図１のサーバに用いられてもよいアービターを説明している。 様々な実施形態にしたがったマネージング・サーバ及びクラウド・サーバ・プールを有するデータセンタを説明している。 様々な実施形態にしたがったクラウド・サーバ・プールを遠隔でセットアップするマネージング・サーバのメソッドのフローチャートである。 様々な実施形態にしたがった故障レポートを有するマネージング・サーバを提供するマネージド・サーバのメソッドのフローチャートである。

以下の詳細な説明では、全体を通して、数が指定されているような複数の要素等のうちの１つの要素を形成し、かつ、実施されてもよい発明の実施形態の例として示される、添付の図面を参照する。他の実施形態が利用され、本発明の範囲から外れることのない構造上の又は論理的な変更がされることが理解されるであろう。したがって、以下の詳細な説明は、限定的な意味に解釈されてはならず、本発明にしたがった実施形態の範囲は、添付の特許請求の範囲及びそれらの均等物により定められる。

様々なオペレーションは、それぞれの並列の離散したオペレーションとして記載され、ある意味で本発明の実施形態の理解を助けるだろう。しかしながら、記述の順番について、オペレーションが順番に依存するという意味を含むと解釈されるべきでない。

本発明では、「Ａ及び／又はＢ」という表現は「Ａ」、「Ｂ」、又は「Ａ及びＢ」を意味する。本発明では、「Ａ、Ｂ及び／又はＣ」という表現は「Ａ」、「Ｂ」、「Ｃ」、「Ａ及びＢ」、「Ａ及びＣ」、「Ｂ及びＣ」、又は「Ａ、Ｂ又はＣ」を意味する。

説明においては、１つ以上の同じ又は異なる実施形態を言及してもよい「１つの実施形態」又は「複数の実施形態」という表現を用いるだろう。更に、本発明の実施形態に関して用いられる「備える」、「有する」「含む」等の用語は、同義である。

本開示の実施形態は、半導体ストレージのリモート・ダイレクト・アクセスに関するシステム及び方法を含む。いくつかの実施形態において、中央処理ユニット（ＣＰＵ）及びサーバのメインメモリを迂回するネットワーク・ストレージ・アクセス（ＮＳＡ）リンクによって、サーバのネットワーク・インターフェース・コンポーネント（ＮＩＣ）は、サーバの半導体ストレージモジュールにアクセスしてもよい。ＮＳＡリンクは、半導体ストレージのリニアな「メモリビュー」にリモート・エンティティーを提供するために、リモート・ダイレクト・メモリ・アクセス（ＲＤＭＡ）をサポートしてもよい。いくつかの実施形態において、ＮＳＡリンクは、ＮＩＣ及びストレージ・コントローラと直接接続するアービターを含んでもよい。様々な実施形態においては、ＮＳＡリンクは、ネットワークにおいて、クラウド・サーバ・プールにおけるサーバのセットアップ、及び／又は用途の変更に用いられてもよい。いくつかの実施形態において、ＮＳＡリンクは、故障検出及び／又はレポーティング・オペレーションに用いられてもよい。ＮＳＡリンクは、暗号化及び／又は圧縮をもたらして、安全な通信、及び／又はネットワーク回線容量の確保をしてもよい。

図１は、様々な実施形態にしたがったサーバ１００を説明している。サーバ１００は、サーバ１００をネットワークに通信接続させるＮＩＣ１０４を含んでもよい。ＮＩＣ１０４は、相互接続１１２によって、ＮＩＣ−ストレージ・コントローラ間（ＮＴＳ）アービター１０８と直接接続されてもよい。ここで、第１の構成要素から送信された信号が、中間処理又は信号のルーティングなしに直接第２の構成要素に提供されたならば、２つの構成要素は互いに「直接接続」しているとみなす。構成要素は、相互接続により互いに直接接続してもよい。相互接続は、例えば相互接続１１２だが、これに限らず配線、ワイヤ、ビア等であってもよい。

ＮＴＳアービター１０８は、相互接続１２０によってストレージ・コントローラ１１６に直接接続されてもよい。別の実施形態においては、ＮＴＳアービター１０８は、ＮＩＣ１０４に統合されてストレージ・コントローラ１１６に直接接続されてもよく、又はストレージ・コントローラ１１６に統合されてＮＩＣ１０４に直接接続されてもよい。

ストレージ・コントローラ１１６は、相互接続１２８によってストレージモジュール１２４に接続されてもよい。ストレージモジュール１２４は、ＮＡＮＤフラッシュ・デバイス又は相変化ストレージ・デバイスのような不揮発性ストレージ・デバイスであってよい。

サーバ１００は、サーバ１００の様々な周辺機器に関連する入／出力（Ｉ／Ｏ）タスクをコントロールする集積回路が統合されているコントローラ・ハブ１３２を含んでもよい。コントローラ・ハブ１３２は、プラットフォーム・コントローラ・ハブ（ＰＣＨ）、サウスブリッジ、Ｉ／Ｏコントローラ・ハブ等であってよい。コントローラ・ハブ１３２は、直接的又は間接的にサーバ１００の中央処理ユニット（ＣＰＵ）１３６に接続されてもよい。ＣＰＵ１３６は、直接的又は間接的にメインメモリ１４０に接続されてもよい。コントローラ・ハブ１３２がサウスブリッジである実施形態において、コントローラ・ハブ１３２はノースブリッジを経由して間接的にＣＰＵ１３６に接続されてよい。本実施形態においてＣＰＵ１３６は、ノースブリッジを経由してメインメモリ１４０に接続されてもよい。

サーバ１００は、コントローラ・ハブ１３２とストレージ・コントローラ１１６との間で接続されるコントローラ・ハブ−ストレージ・コントローラ間（ＣＴＳ）アービター１４４を含んでもよい。いくつかの実施形態において、ＣＴＳアービター１４４は、ストレージ・コントローラ１１６又はコントローラ・ハブ１３２に統合される。ＣＰＵ１３６は、コントローラ・ハブ１３２、ＣＴＳアービター１４４及びストレージ・コントローラ１１６を横断するホスト・ストレージ・アクセス（ＨＳＡ）リンク１４８を経由してストレージモジュール１２４とアクセスしてもよい。ＨＳＡリンク１４８を経由するストレージモジュール１２４へのアクセスは、従来のストレージ・アクセスのように見えてもよい。例えば、コントローラ・ハブ１３２は、ブロックレベル・アドレスを有するＣＴＳアービター１４４へのアクセス要求を発行してもよい。このブロックレベル・アドレスを有するＣＴＳアービター１４４へのアクセス要求は、ブロックレベル・アクセス要求として言及されてよい。ＣＴＳアービター１４４は、ウェアレベリング及び／又はエラー修正を提供するために、ブロックレベル・アドレスを物理的なアドレスに翻訳してもよい。ＣＴＳアービター１４４は、適切な物理的なアドレスを有するアクセス要求を、ストレージモジュール１２４内の指定された空間にアクセスしてもよいストレージ・コントローラ１１６に対して発行してもよい。

ＨＳＡリンク１４８を経由するストレージモジュール１２４へのアクセスは、従来のストレージ・アクセスのように見えてもよいと同時に、ＣＰＵ１３６及びメインメモリ１４０を迂回するネットワーク・ストレージ・アクセス（ＮＳＡ）リンク１５２を経由するストレージモジュール１２４へのアクセスは、リモート・エンティティーへのメモリ・アクセスのように見えてもよい。これは、ストレージモジュール１２４から、又はストレージモジュール１２４へ送信されたデータにアクセスするときに、リモート・エンティティーが参照してもよいバッファをＮＴＳアービター１０８が登録することにより行われてもよい。

いくつかの実施形態において、ＮＩＣ１０４、ＮＴＳアービター１０８、ＣＴＳアービター１４４、及び／又はストレージ・コントローラ１１６は、コントローラ・ハブ１３２に統合されてもよい。

図２は、いくつかの実施形態にしたがったＮＴＳアービター１０８の更なる詳細を説明している。ＮＴＳアービター１０８は、メモリ２０８に接続する処理ユニット２０４を含んでもよい。ＮＴＳアービター１０８は、キャッシュメモリであるメモリ２０８を有する集積回路であってもよい。処理ユニット２０４及びメモリ２０８は、離れていてよく、ＣＰＵ１３６及びメインメモリ１４０とは区別されてよい。更に、処理ユニット２０４及びメモリ２０８は、ＮＳＡリンク１５２に関連するタスクを実行するのに限定された機能性を有してさえいればよい。このため、これらの構成要素は、パワーが、ＣＰＵ１３６及びメインメモリ１４０よりも著しく、小さく／少なくてもよい。

オペレーションにおいて、処理ユニット２０４は、バッファレベル・アクセス要求として、アクセス要求をリモート・エンティティーにＮＩＣ１０４を経由して伝えてもよく、物理的なアドレス（ＰＡ）に基づくアクセス要求として、アクセス要求をストレージ・コントローラ１１６に伝えてもよい。例えば、処理ユニット２０４は、バッファを識別するＮＩＣ１０４からアクセス要求（例えば、読み書きのリクエスト）を受信してもよい。処理ユニットは、メモリ２０８のリンクリスト２１２に基づいて、バッファに対応する物理的な格納空間のアドレスを決定してもよい。バッファを物理的な格納空間のアドレスに翻訳すると、処理ユニット２０４は、物理的な格納空間のアドレスを含んだ別のアクセス要求を、ストレージ・コントローラ１１６に対して発行する。

説明されているように、リモート・ダイレクト・ストレージ・アクセスを提供するサーバ１００は、サーバ１００のリモート・マネジメントについての多くの利点を提供するだろう。

図３は、いくつかの実施形態にしたがった、ネットワーク３１２を経由してクラウド・サーバ・プール３０８に通信接続されたマネージング・サーバ３０４を含むデータセンタ３００を説明している。クラウド・サーバ・プール３０８は、例えばマネージド・サーバ３１６等の１以上のマネージド・サーバを有する。マネージング・サーバ３０４は、リモート・ダイレクト・ストレージ・アクセスを用いて、クラウド・サーバ・プール３０８のマネージド・サーバに関する多くのマネージメント・タスクを実行してもよい。マネージメント・タスクの例として、新しいサーバのセットアップ、既存のサーバの用途の変更、故障のマネジメント、オペレーションのリカバリ等が挙げられる。

マネージング・サーバ３０４は、ＮＩＣ３２４及びストレージ媒体３２８と、直接的又は間接的に接続するＣＰＵ３２０を含んでもよい。ストレージ媒体３２８は、格納されている、ＣＰＵ３２０に実行されるとマネージング・サーバ３０４に、ここで記載されている様々なマネージング・タスクを実行させる命令を含んでもよい。命令は、ストレージ媒体３２８から直接実行されてもよく、ＣＰＵ３２０による実行に先だって、例えば揮発性メモリ等の他の媒体に移動されてもよい。

サーバ１００に類似していてもよいマネージド・サーバ３１６は、上述したような半導体ストレージモジュールへのＮＳＡリンクを有し、少なくともいくつかのマネージメント・タスクを容易にしてもよい。クラウド・サーバ・プール３０８の他のマネージド・サーバもまた、サーバ１００に類似してもよい。しかしながら、いくつかの実施形態においては、１以上の他のマネージド・サーバは、ＮＳＡリンクを有さなくてもよい。

図４は、いくつかの実施形態にしたがった、例えばクラウド・サーバ・プール３０８等のクラウド・サーバ・プールを遠隔的にセットアップする、例えばマネージング・サーバ３０４等のマネージング・サーバのメソッドのフローチャート４００である。

ブロック４０４において、マネージング・サーバは、リモート・プロビジョニングの手順に入るだろう。これは、サーバの新しいグループがデータセンタに加えられた場合（又は、サーバの既存のグループの用途が変更された場合）に起こるとよく、適切なブート・イメージを有するサーバが提供されるのが望ましい。ブート・イメージは、命令、及びサーバ上のハードウエアのブートを許可するデータを含んでもよい。ブート・イメージは、例えばオペレーティング・システム、ユーティリティー、及び診断等の、ブート及びデータのリカバリー情報等を含んでもよい。これらの実施形態においては、マネージング・サーバはまた、ブート・サーバとして言及されてもよい。

ブロック４０８において、マネージング・サーバは、クラウド・サーバ・プールに、セットアップするさらなるサーバが存在するか否かを決定してもよい。ブート・サーバは、セットアップすべきブート・サーバの入力、すなわちマニフェストと、以前にセットアップされたサーバの内部で生成したリストとの比較によりこれを決定してもよい。

ブロック４０８において、セットアップするさらなるサーバが存在すると決定された場合、ブロック４１２において、ブート・サーバは、セットアップするさらなるサーバからターゲット・サーバを選択してもよい。

ブロック４１２に続くであろうブロック４１６において、ブート・サーバは、選択されたターゲット・サーバのセキュリティー接続が証明されているかを決定してもよい。ターゲット・サーバが以前にブート・サーバとの安全な接続をもったことがある場合は、ブート・サーバは、以前の安全な接続がまだ有効なのかを決定する。例えば新しいサーバであるとき等、ターゲット・サーバが以前にブート・サーバとの安全な接続をもったことがない場合、ブート・サーバは、ターゲット・サーバから、例えば媒体アクセス制御（ＭＡＣ）アドレス等の認証情報を読み出し、読み出した認証情報を、セットアップされるサーバのマニフェストから得た認証情報と比較してもよい。

ブロック４１６において、ブート・サーバは、セキュリティ接続が証明されないことを決定した場合、ブロック４２０において、ブート・サーバは、ターゲット・サーバはセットアップ不可であることを示してよく、手順はブロック４０８にループ・バックしてもよい。

ブロック４１６において、ブート・サーバが、セキュリティー接続が証明されることを決定した場合、ブロック４２４において、ブート・サーバは、ポスティング・バッファの割当のために、マネージド・サーバのＮＴＳアービターと交渉してもよい。マネージド・サーバのＮＴＳアービターと直接交渉されるときは、マネージド・サーバのＣＰＵ又はメインメモリからのいかなるアクションも伴わないだろう。交渉には、ブート・サーバが、所定サイズの格納空間の割当要求をＮＴＳアービターへ送信することが含まれてもよい。ポスティング・バッファの割当とポスティング・バッファの識別子とを示す割当要求に基づいて、ブート・サーバは、ＮＴＳアービターからの応答を受信してもよい。また応答は、ポスティング・バッファのサイズを含んでもよい。

ブロック４２４に続くであろうブロック４２８において、ブート・サーバは、ブート・イメージとポスティング・バッファの識別子とをＮＴＳアービターに送信してもよい。ＮＴＳアービターは、ブート・イメージの、ポスティング・バッファに関連するストレージモジュールの物理的な空間への格納をもたらしてもよい。上述のように、ブート・イメージは、マネージド・サーバのＮＳＡリンクを経由してストレージモジュールに保存されてもよい。ひとたびブート・イメージが半導体ストレージモジュールに保存されると、ＣＰＵは、次のブート手順においてＣＰＵによって用いられるブート・イメージへのアクセスを入手できるだろう。

ブロック４２８においてブート・イメージが送信された後、ブート・サーバは、セットアップされたサーバのリストをアップデートしてもよく、ブロック４３２においてターゲット・サーバがセットアップされることを示す。プロビジョニング手順は、ブート・サーバが、セットアップするさらなるサーバがクラウド・サーバ・プールにあるか否かを決定するブロック４０８へループ・バックしてもよい。ブロック４０８において、さらなるセットアップされるサーバが存在しないと判断された場合、ブロック４３６において、ブート・サーバは、プロビジョニング手順から抜け出てもよい。

図４において議論されたマネージド・サーバの遠隔的なプロビジョニングの方法が、全てのブート・イメージの初期のプロビジョニングを意図する一方で、他の実施形態は、異なる利用モデルにおけるリモート・ダイレクト・ストレージ・アクセスを採用することができる。例えば、一実施形態においては、マネージング・サーバは、１以上のアップデートカプセルがマネージド・サーバへ積極的に転送される、段階的なプロビジョニングにおけるリモート・ダイレクト・ストレージ・アクセスを用いてもよい。いくつかの実施形態において、マネージド・サーバは、選択肢を有し、アップデートをスケジュールしてもよい。

図４を参照して説明された遠隔的なプロビジョニング手順は、マネージド・デバイスの半導体ストレージモジュールへのデータの転送に用いられるリモート・ダイレクト・ストレージ・アクセスの実施形態である。他の実施形態においては、リモート・ダイレクト・ストレージ・アクセスは、例えばリカバリー・オペレーション等の半導体ストレージモジュールからのデータの転送に用いられてもよい。そのような実施形態は、図５に関連してこれから記述される。

図５は、いくつかの実施形態にしたがった、例えばマネージング・サーバ３０４等のマネージング・サーバに、リカバリー・オペレーションにおける故障レポートを提供する、例えばマネージド・サーバ３１６等のマネージド・サーバのメソッドのフローチャート５００である。

ブロック５０４において、例えばＮＴＳアービター１０８等のＮＴＳアービターは、故障イベントを検出してもよい。故障イベントは、マネージド・サーバのＣＰＵ及び／又はメインメモリに関連してもよい。いくつかの実施形態において、マネージド・サーバの操作の失敗を検出した場合、マネージング・サーバによって生成かつ送信された故障レポートを、マネージング・サーバから受信することにより、ＮＴＳアービターは故障を検出してもよい。マネージド・サーバの反応が悪くなった場合、及び／又は期待されたアクション／レポートの提供を失敗した場合、マネージング・サーバは、マネージド・サーバの操作の失敗を検出する。他の実施形態において、ＮＴＳアービターは、内部で、言い換えればマネージング・サーバからのレポートなしで、故障イベントを検出してもよい。ＮＴＳアービターは、ストレージモジュール内の故障フラグをモニタリングすることにより、故障イベントを検出してもよい。失敗が起きた場合、例えばマネージド・サーバのＣＰＵ等によって故障フラグがセットされてもよい。ＮＴＳアービターは、故障フラグがセットされたことを決定してよく、それにより故障イベントを検出する。

いくつかの実施形態において、故障フラグは、例えばストレージモジュール１２４等のストレージモジュールのパフォーマンスに基づいて、例えばＣＰＵ１３６及び／又はストレージ・コントローラ１１６等のコントローリング・デバイスによりセットされてもよい。オペレーションにおいて、コントローリング・デバイスはストレージモジュールの操作パラメータを監視してもよい。操作パラメータは、リード／ライトの失敗、失敗したセルを有するストレージモジュールの部分、有効なストレージ、応答時間等を含んでもよい。これらの操作パラメータが望ましい閾値を下回った場合、コントローリング・デバイスは、ＮＴＳアービター１０８によって、識別できる故障フラグをセットしてもよい。

ブロック５０４の後に起こるであろうブロック５０８において、ＮＴＳアービターは、アクセス要求をマネージド・サーバのストレージ・コントローラに送信してもよい。アクセス要求は、ブート・イメージが存在する、及び／又は例えばメモリ・ファイル・イメージ、クラッシュ・ダンプ・ログ、スタック状態データ、及び／又はレジスタ値のような処理状態データ等の実行状態データの格納専用の実行状態格納空間である格納空間に関連する読み込み要求であってもよい。マネージド・サーバのＣＰＵは、ＨＳＡリンクを経由し、例えば、さまざまなプロセスへの入口／出口を容易にする、及び／又は先行する、又は後に起こる、ＣＰＵが故障フラグをセットしてもよいシステムの故障（例えば、オペレーティング・システムの障害）かもしれない異常を検出した場合等の実行状態データを、通常動作の工程における実行状態の格納空間に格納してもよい。

ブロック５０８の後に起こるであろうブロック５１２において、ＮＴＳアービターはマネージド・サーバのＮＩＣへレポーティング・コマンドを送信してもよい。レポーティング・コマンドは、ストレージモジュールの望ましい格納空間から読み出したデータを含んでもよい。

ブロック５１２の後に起こるであろうブロック５１６において、ＮＩＣは、ネットワーク上でマネージング・サーバへレポートを送信してもよい。

好ましい実施形態を記載する目的で、いくつかの実施形態を説明したが、多種多様の代替、及び／又は同等の実施形態、又は同じ目的を達成するための計画された実装は、本発明の範囲から逸脱すること無い実施形態に置換されてもよいことを、当業者はよく理解するだろう。本願は、ここで議論された実施形態の様々な適応又は変形をカバーすることが意図されている。したがって、本発明にしたがった実施形態は、特許請求の範囲及びその均等のみに限定されていることを明確に意図している。

Claims (20)

1. 装置であって、
   中央処理ユニットと、
   不揮発性方式で情報を格納する半導体ストレージモジュールと、
   前記装置をネットワークに通信接続させるネットワーク・インターフェース・コンポーネント（ＮＩＣ）と、
   ブロックレベル・アクセス要求を処理することにより、前記中央処理ユニットを前記半導体ストレージモジュールに通信接続させる第１のアービターと、
   前記ＮＩＣからのブロックレベル・アクセス要求を処理することにより、前記ＮＩＣを前記半導体ストレージモジュールに通信接続する第２のアービターと
   を備える装置。
2. 前記第１のアービターへの前記ブロックレベル・アクセス要求を提供するコントローラ・ハブを更に備える請求項１に記載の装置。
3. 前記半導体ストレージモジュールと接続されるストレージ・コントローラと、
   前記コントローラ・ハブ、前記第１のアービター、及び前記ストレージ・コントローラを含んで、前記中央処理ユニットを前記半導体ストレージモジュールに通信接続させるホスト・ストレージ・アクセス・リンクと、
   前記第２のアービター及び前記ストレージ・コントローラを含んで、前記中央処理ユニット及び前記装置のメインメモリを迂回して前記ＮＩＣを前記半導体ストレージモジュールに通信接続させるネットワーク・ストレージ・アクセス・リンクと
   を更に備える請求項２に記載の装置。
4. 前記ＮＩＣ及び前記第２のアービターを有するコントローラ・ハブを更に備える請求項１に記載の装置。
5. 前記第２のアービターは、処理ユニット及びメモリを有する請求項１に記載の装置。
6. 前記処理ユニットは、
   バッファを特定するアクセス要求を受信し、
   前記メモリのリンクリストに基づき、前記バッファに対応する物理的な格納空間のアドレスを決定し、
   前記物理的な格納空間のアドレスを有する他のアクセス要求を発行する、請求項５に記載の装置。
7. 前記半導体ストレージモジュールは、ＮＡＮＤフラッシュ・デバイスを有する請求項１に記載の装置。
8. 前記半導体ストレージモジュールは、相変化ストレージ・デバイスを有する請求項１に記載の装置。
9. サーバのネットワーク・インターフェース・コンポーネント（ＮＩＣ）において、ネットワークを介し、リモート・エンティティーから、リモート・ポスティング・バッファを特定するストレージ・アクセス要求を受信する段階と、
   アービターが前記ＮＩＣと直接的に接続すること、又は当該アービターが前記ＮＩＣに統合されることにより、前記ストレージ・アクセス要求に基づき前記サーバの半導体ストレージモジュールにアクセスするアクセス段階と
   を備える方法。
10. 前記ストレージ・アクセス要求を受信する段階は、前記サーバをセットアップする、又は前記サーバの用途を変更するためのブート・イメージと、前記ポスティング・バッファの前記ブート・イメージを格納するコマンドとをブート・サーバから受信する段階を有する請求項９に記載の方法。
11. 前記アクセス段階は、
    前記アービターにより、前記ポスティング・バッファに対応する物理的な格納空間のアドレスを決定する段階と、
    前記アービターにより、前記物理的な格納空間のアドレスを含んだ他のアクセス要求を、ストレージ・コントローラに対して発行する段階と
    を有する請求項９に記載の方法。
12. 前記サーバの他のアービターにおいて、コントローラ・ハブから、ブロックベースのアクセス要求を受信する段階と、
    前記他のアービターにより、前記ブロックベースのアクセス要求に基づき前記サーバの前記半導体ストレージモジュールにアクセスする段階と
    を更に備える請求項９に記載の方法。
13. サーバのメインメモリ及び中央処理ユニット（ＣＰＵ）を迂回したネットワークストレージ・アクセス・リンクを経由して、前記サーバのアービターから直接的に、半導体ストレージモジュールのアドレス空間からのデータを含んだレポート・コマンドを受信する手段と、
    前記データを含んだレポートを、ネットワークを通じてリモート・エンティティーに送信する手段と
    を備える装置。
14. 前記サーバの障害イベントを検出する手段と、
    前記検出に基づき、前記レポート・コマンドを生成する手段と
    を更に備える請求項１３に記載の装置。
15. 前記検出する手段は、前記リモート・エンティティーから障害インジケータを受信する手段を有する請求項１４に記載の装置。
16. 前記検出する手段は、障害フラグが前記半導体ストレージモジュールにセットされていることを決定する手段を有する請求項１４に記載の装置。
17. ブート・サーバが、ターゲット・サーバに搭載されたアービターに、割当要求を送信する段階と、
    前記ブート・サーバが、前記アービターから、前記割当要求に基づいて前記ブート・サーバに割り当てられたポスティング・バッファの識別子を示す応答を受信する段階と、
    前記識別子とブート・イメージとを、前記ブート・サーバにより前記アービターへ送信して、前記ポスティング・バッファに対応した半導体ストレージモジュールの格納空間に格納する段階と
    を備える方法。
18. 前記ブート・サーバが、ネットワークを通じて前記ブート・イメージを送信することにより、前記ターゲット・サーバを含む複数のサーバをセットアップする段階を更に備える請求項１７に記載の方法。
19. 前記ターゲット・サーバのネットワーク・インターフェース・コンポーネントから、媒体アクセス制御（ＭＡＣ）アドレスを受信する段階と、
    前記ＭＡＣアドレスに基づいて、前記ターゲット・サーバがセットアップ可能なサーバであることを決定する段階と、
    前記決定に基づいて、前記割当要求を送信する段階と
    を更に備える請求項１７に記載の方法。
20. 前記割当要求における前記ポスティング・バッファの要求サイズを提供する段階を更に備える請求項１７に記載の方法。

Images