多数のコンピューティングプラットフォームにおけるＯＳにとらわれない資源共有
【課題】複数のコンピューティングプラットフォームで資源を共有するための方法、装置、および、システムを提供する。
【解決手段】各プラットフォームに設けられたファームウェアは、オペレーティングシステムの実行時に利用可能なようにロードされる。共有資源は、プラットフォームで動作するオペレーティングシステムに対しローカル資源として示され、実際には、それらは通常、他のプラットフォームによりホストされる。オペレーティング資源アクセス要求は、要求するプラットフォームにより受信され、資源アクセス要求にサービスを提供するために用いられるターゲット資源を実際にホストする他のプラットフォームにルート変更して送られる。グローバル資源マップは、適切なホストプラットフォームを決定する目的で用いられる。プラットフォーム間の通信は、バンド外（ＯＯＢ）通信チャネルまたはネットワークを介し可能になる。ＯＯＢチャネルを介したデータのルート変更を実現するべく、隠し実行モードが実行される。それによって、本発明の方法は、プラットフォームで動作するオペレーティングシステムに対し、トランスペアレントに実行される。共有資源は、記憶、入力、および、ビデオ装置を含む。本発明の方法は、ＫＶＭ資源、および、共有ディスク記憶をサポートする目的で使用することができる。
【解決手段】各プラットフォームに設けられたファームウェアは、オペレーティングシステムの実行時に利用可能なようにロードされる。共有資源は、プラットフォームで動作するオペレーティングシステムに対しローカル資源として示され、実際には、それらは通常、他のプラットフォームによりホストされる。オペレーティング資源アクセス要求は、要求するプラットフォームにより受信され、資源アクセス要求にサービスを提供するために用いられるターゲット資源を実際にホストする他のプラットフォームにルート変更して送られる。グローバル資源マップは、適切なホストプラットフォームを決定する目的で用いられる。プラットフォーム間の通信は、バンド外（ＯＯＢ）通信チャネルまたはネットワークを介し可能になる。ＯＯＢチャネルを介したデータのルート変更を実現するべく、隠し実行モードが実行される。それによって、本発明の方法は、プラットフォームで動作するオペレーティングシステムに対し、トランスペアレントに実行される。共有資源は、記憶、入力、および、ビデオ装置を含む。本発明の方法は、ＫＶＭ資源、および、共有ディスク記憶をサポートする目的で使用することができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ブレードサーバなどのクラスタ化コンピューティング環境、より詳しくは、これに限定しないが、ノード全体で共有できるグローバル資源を生成すべく、個別のプラットフォーム（ノード）によりホストされる資源を共有する技術に関する。
【背景技術】
【０００２】
情報技術（ＩＴ）管理者および情報統括責任者は、能力を低下させることなく資本経費および営業費を削減しなければならないという強いプレッシャーにさらされており、ＩＴ管理は、より効果的にインフラ資源を利用する計算資源を提供する必要に迫られている。この目的を満たすべく、サーバの利用をいかに効率的に管理するか、いかに少ないスタッフでＩＴ業務をこなすか、床面積をいかに効率的に利用するか、また、電力問題をどう取り扱うかといった課題が日々取り上げられている。
【０００３】
一般的に、企業のＩＴ（情報技術）インフラは、コンピュータサーバに集中し、サーバは、さまざまなタイプのネットワーク、例えば、プライベートローカルエリアネットワーク（ＬＡＮ）、および、公私のワイドエリアネットワーク（ＷＡＮ）を介し互いに接続されている。サーバは、さまざまなアプリケーションを分散させ、かつ、データ記憶および処理プロセスを管理する目的で使用される。このようなサーバは、通常、スタンドアロンサーバ、および／または、４Ｕ、２Ｕ、および、１Ｕなどの高密度ラックマウントサーバを含む。
【０００４】
近年、過去にないサーバ密度および経済スケーラビリティを提供する新規のサーバ構成が導入されている。このサーバ構成は、「ブレードサーバ」として知られている。ブレードサーバは、共通のシャーシ内に配置された複数の密接した「サーバブレード」（ブレード）を用いることにより、高密度なコンピュータ機能を供給する。各ブレードは、１つ、または、それ以上のプロセッサ、メモリ、ネットワーク接続、および、ディスク記憶装置を含む完全なコンピューティングプラットフォームを単一のシステムボードに一体化して提供する。一方、電源およびファンなどの他の構成要素は、所定のシャーシおよび／またはラック内のブレード間で共有される。これによって、従来のラックマウントサーバに比べ、資本設備費用の大幅な削減が可能になる。
【０００５】
一般的に、ブレードサーバは、２つの市場をターゲットにしている。一方は、個別のブレードが個別のタスクを処理する高密度サーバ環境、他方は、スケーラブルコンピュータクラスタ環境である。スケーラブルコンピュータクラスタ（ＳＣＣ）は、２つまたはそれ以上のコンピュータシステム群であり、コンピュータインテンシブなタスクを実行するべく協働するよう構成されたコンピューティングノードとしても知られている。コンピュータのタスクを実行するべく協働する多数のノードを構成することにより、単一のシステムで実行した場合よりタスクを素早く計算できる。理論上は、タスクに適用されるノードが多いほど、タスクの計算は速くなる。しかし実際には、タスクを完了するために活用できるノード数は、使用するアプリケーションに依存する。
【０００６】
一般的なＳＣＣは、Ｌｉｎｕｘオペレーティングシステムおよびクラスタインフラソフトウェアを稼動させるインテルのサーバを用いて構築される。前記サーバは、市販（ＣＯＴＳ）サーバとも言われ、ネットワークを介し接続されることにより、クラスタを形成する。１つのＳＣＣは、通常、コンピュータインテンシブなタスクの実行時に有効な１０から１００のサーバがどこかに必要である。ブレードサーバなら、このような多数のサーバを1つの場所に集めてクラスタを形成するという要求に完璧に応えることができる。ブレードサーバのシャーシ設計およびアーキテクチャは、非常に大きなコンピュータの馬力を単一の場所に提供することができる。さらに、ブレードサーバアーキテクチャのビルトインネットワーキングおよびスイッチング能力は、ブレードを個別に追加または除去することができ、所定のタスクの最適なスケーリングを実現する。このような柔軟性をもったサーバベースのＳＣＣを用い、スーパーコンピュータのようなコンピュータタスクを実行する他のインフラの費用効果的な変形例を提供できる。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
上述のように、ブレードサーバにおける各サーバは、フルプラットフォーム機能を実現し、その結果、サーバにおいて、ブレードが個別に動作できるようになる。しかしながら、各ブレードにとって利用可能な資源は、そのブレードがもつ資源に限られるため、多くの場合、資源は効率的に利用されない。現状のアーキテクチャでは、サーバと広範囲にわたる資源とを効率的に共有できるスキームは確立されていない。
【課題を解決するための手段】
【０００８】
前述した側面および本発明の多くの効果は、添付の図面を参照しながら以下の詳細を読むことにより容易に理解されることであろう。なお、特に明記しない限り、全図面を通じて同様の要素には同様の参照符号を付して示す。
【０００９】
以下、ブレードサーバ環境のような、クラスタ化プラットフォーム環境全体で資源を共有化するための方法およびコンピュータ構成要素の実施例を説明する。以下の説明において、本発明の実施例を完全に理解することを目的として数多くの具体的な詳細が記載されている。しかしながら、１つまたはそれ以上の具体的な詳細の説明がなくとも、または、他の方法、構成要素、材料によっても本発明が実行可能であることは、当業者にとって明らかである。また、本発明の態様を不明確にしないよう、公知の構造、材料、または、オペレーションの詳細な説明は省略する。
【００１０】
本明細書を通じて使用される「一実施例」という語句は、特定の機能、構造、または、実施例と関連して記述される特徴が、本発明の少なくとも1つの実施例に含まれることを意味する。したがって、本発明を通じて随所に使用される「一実施例」という語句は、必ずしも同じ実施例を指すものではない。さらに、特定の機能、構造、または、特徴は、1つまたはそれ以上の実施例において適切な形で組み合わされてよい。
【発明の効果】
【００１１】
本発明の態様によれば、個別のプラットフォームによりホストされる資源が他のプラットフォームからもアクセス可能になる、クラスタ化プラットフォーム環境全体で資源を共有化する技術が開示される。この技術は、ＯＳとの連動を必要とせずに「ビハインドザシーン」アクセスメカニズムを提供するファームウェアベースの機能を用いる。実際には、資源共有およびアクセス操作は、ブレード上で動作するオペレーティングシステムに対し完全にトランスペアレントであり、オペレーティングシステムは、独立している。したがって、本願明細書において開示される新規な技術によってもたらされる機能は、既存および将来の分散型プラットフォーム環境で使用でき、使用に当たり、オペレーティングシステムをその環境向けに変更する必要がない。
【００１２】
一態様によれば、資源共有メカニズムは、グローバル資源を形成するよう集結された資源を公開しているいくつかのプラットフォームにより実現できる。各プラットフォームは、オペレーティングシステムのロード（プレブート）前、および、オペレーティングシステムの実行と同時に稼動する一組のファームウェアをそれぞれ用いる。一実施例において、実行時の配備は、システムマネジメントモード（ＳＭＭ）として知られる非表示実行モードによって容易になる。前記システムマネジメントモード（ＳＭＭ）は、周期的なシステムマネジメントインターラプト（ＳＭＩ）を受信しかつそれに応答する能力を有するので、資源共有を実現し、かつ、メカニズムを実行するよう設定されたファームウェアＳＭＭコードにアクセス情報をトラスペアレントに伝えることができるようになる。ＳＭＭ資源マネジメントコードは、情報およびメッセージを、他のノードに、アウトオブバンドネットワーク（ＯＯＢ）、または、通信チャネルを介し、オペレーションシステムに対しトランスペアレントに伝える。
【発明を実施するための最良の形態】
【００１３】
説明の便宜上、本発明のいくつかの実施例は、ブレードサーバ環境として以下に説明される。概要としては、本発明の実施例に従う資源共有スキームが通常実行できる典型的なブレードサーバ構成要素およびシステムが図１Ａ−Ｃおよび２に示される。典型的な構成の下では、複数のブレード１０２に電力および通信機能を提供する目的で、ラックマウントシャーシ１００が用いられる。各ブレード１０２は、それぞれ対応するスロットを占有する（すべてのスロットがシャーシで占有される必要はない点に注意）。または、１つまたはそれ以上のシャーシ１００が図１Ｃに示されるブレードサーバラック１０３内に設置されてもよい。各ブレードは、１つまたはそれ以上のマッチング・コネクタを介し設置されると同時に、インターフェース平面１０４（すなわちバックプレーンまたはミッドプレーン）に結合される。一般的に、インターフェース平面は、ブレードそれぞれのための複数のマッチングコネクタを含み、電力および通信信号をブレードに供給することもできる。現実行下では、多数のインターフェース平面が「ホットスワッピング」機能、すなわち、シャーシ全体の電源を入れたままで、データ信号をバッファリングすることもなく、ブレードを即座に追加または除去する（ホットスワッピングする）ことができる機能を提供する。
【００１４】
図１Ａおよび１Ｂは、典型的なミッドプレーンインターフェース平面構成を示す。インターフェース平面１０４の後部は、１つまたはそれ以上の電源１０６に接続される。多くの場合、電源は冗長化およびホットスワッピングが可能である。適切な電源プレーンおよびコンディショニング回路に結合されることにより、１つの電源が故障しても継続して動作することができる。任意の構成において、電源アレイを用いてブレードラック全体に電力を供給してもよく、この場合、電源とシャーシとが一対一の関係になくてもよい。また、複数の冷却ファン１０８を用いてシャーシを介し空気を引き込み、サーバブレードを冷却する。
【００１５】
ブレードサーバすべてに要求される重要な特徴として、他のＩＴインフラとも外部通信する能力が挙げられる。一般的に、外部通信は、１つまたはそれ以上のネットワーク接続カード１１０を介して行われ、ネットワーク接続カードは、それぞれインターフェース平面１０４に接続される。また、１つのネットワーク接続カードは、複数のネットワークポート接続（例えば、ＲＪ−４５ポート）を含む１つの物理的インターフェースを有するか、または、ネットワークスイッチ、ハブ、または、ルータなどのネットワーク装置に直接接続されるよう設計された高密度コネクタを備えてもよい。
【００１６】
ブレードサーバは、通常、ブレードの動作を個別に管理する何らかの管理インターフェースを提供する。これは、帯域外ネットワークまたは通信チャネルによって実現が容易になる。例えば、「プライベート」または「マネジメント」ネットワーク、および、適切なスイッチングを容易に実現するための１つまたはそれ以上のバスをインターフェース平面に組み込んでもよく、あるいは、プライベートネットワークは、強連結ネットワークケーブル配線、および、ネットワークを介し実行することもできる。前記スイッチングおよび他の、マネジメント機能は、任意でマネジメントカード１１２によって提供されてもよく、マネジメントカード１１２は、インターフェース平面の裏側または表側に結合される。さらに、また、マネジメントサーバを用いてブレード動作を管理してもよく、この場合、通信は、イーサネットなどの標準的なコンピュータネットワーク化インフラを介し処理される。
【００１７】
図２を参照し、例示的なブレード２００をさらに詳しく説明する。上述したように、各ブレードは、サーバタイプの機能を実行するよう構成された独立したコンピューティングプラットフォーム、すなわち、「カードのサーバ」を備える。したがって、各ブレードは、適切な集積回路（ＩＣ）を結合するための内部配線（すなわちバス）を提供する主回路基板２０１を含む従来のサーバに共通する構成要素と、主回路基板に取り付けられた他の構成要素とを含む。これらの構成要素は、システムメモリ２０４（ＤＤＲ ＲＡＭなど）、キャッシュメモリ２０６（ＳＤＲＡＭなど）、および、ファームウェア記憶装置２０８（フラッシュメモリなど）に結合された１つ、または、それ以上のプロセッサ２０２を含む。従来のネットワーク通信機能、例えば、ブレードと外部ネットワークインフラとの間の通信をサポートするための「公衆」ＮＩＣ（ネットワークインターフェース）チップ２１０が設けられる。例示された他の構成要素は、ステータスＬＥＤ２１２、ＲＪ−４５コンソールポート２１４、および、インターフェース平面コネクタ２１６を含む。付加的な構成要素は、さまざまな受動構成要素（抵抗器、コンデンサなど）、電力調整部品、および、周辺装置コネクタを含む。
【００１８】
通常、各ブレード２００は、オンボード記憶装置を提供することもでき、これは、１つまたはそれ以上のビルトイン・ディスクコントローラ、および、１つまたはそれ以上のディスクドライブ２１８が結合される対応するコネクタを介し実現が容易になる。例えば、典型的なディスクコントローラは、Ｕｌｔｒａ ＡＴＡコントローラ、および、ＳＣＳＩコントローラなどを含む。また、大量のデータを格納するためにネットワーク接続ストレージ（ＮＡＳ）機器が用いられるときは、ディスクドライブは、ブレードとは別に、同じまたは個別のケースのようなラックに収容されてもよい。
【００１９】
本発明の態様によれば、ブレードと、任意の専用管理コンポーネントとの間のバンド外通信のための機能が提供される。ここで使用されるように、バンド外通信チャネルは、ＯＳに対しトランスペアレントなデバイス間通信をサポートする通信手段であってオペレーティングシステムと協働せずにブレード間通信を可能にする手段を含む。通常、さまざまなアプローチによりＯＯＢチャネルを提供することができる。これらのアプローチは、ＳＭＢＵＳ標準（ｗｗｗ．ｓｍｂｕｓ．ｏｒｇ）を実行するシステムマネジメントバス、ＶＬＡＮ−８０２．１Ｑなどの専用プライベートまたはマネジメントネットワーク、あるいは、例えばＲＳ−４８５シリアル通信標準を用いるシリアル通信スキームなどの使用を含むが、これに限定されない。また、このような通信機能をサポートする１つまたはそれ以上の適切なＩＣがＯＯＢチャネルチップ２２０で示されるように、主回路基板２０１に取り付けられる。同時に、インターフェース平面１０４は、選択されたＯＯＢスキームを支持するための対応するバスまたはビルトインネットワークトレースを含んでもよい。また、有線ネットワークスキーム（イーサネットなど）の場合、適切なネットワークケーブル配線およびネットワーキングデバイスをシャーシ１００の内部または外部に配置させてもよい。
【００２０】
前述のように、本発明の実施例では、ブレードサーバノード全体で資源を共有化できるようにする資源共有セットアップおよびアクセス機構を実現するためのファームウェアベースのスキームを用いる。特に、資源管理ファームウェアコードが各ブレードの初期化の間にロードされ、ＯＳ実行中のアクセスを可能にする。同様に、初期化の間に資源情報が収集され、グローバル資源情報が確立される。このグローバル資源情報に基づき、各ブレードへの適切なグローバル資源アクセスが提供される。この情報は、グローバル資源が（オペレーションシステムの立場からは）ローカル資源として見えるよう、その初期化と同時にＯＳに伝えられる。ＯＳの実行中、共有資源へのアクセスは、ＯＳおよび／またはＯＳドライバと、資源アクセスマネジメントと協働する対応するファームウェアとの間のやりとりを介し処理され、このやりとりは、ＯＯＢチャネルを介し実現が容易になる。
【００２１】
一実施例において、資源共有は、拡張ファームウェアインターフェース（ＥＦＩ）（仕様およびその例は、ｈｔｔｐ：／／ｄｅｖｅｌｏｐｅｒ．ｉｎｔｅｌ．ｃｏｍ／ｔｅｃｈｎｏｌｏｇｙ／ｅｆｉを参照）として知られる拡張ファームウェアフレームワークにより実現が容易になる。ＥＦＩは、プラットフォームファームウェアと、シュリンクラップオペレーションシステム、または、他のカスタムアプリケーション環境との間の抽象的なプログラマチックインターフェースを記述する公の産業仕様（現在のバージョン１．１０は２００３年１月７日リリース）である。ＥＦＩフレームワークにより、プラットフォームのＢＩＯＳデバイス（フラッシュメモリなど）に格納されたＢＩＯＳコードにより提供されるもの以上にＢＩＯＳ機能を拡張できる。より詳しくは、ＥＦＩによって、主および二次フラッシュデバイス、オプションのＲＯＭ、多種の持続性記憶装置（ハードディスク、ＣＤ ＲＯＭなど）を含むさまざまな資源から、ファームウェアがファームウェアモジュールおよびドライバ形式で、コンピュータネットワーク上でもロードできるようになる。
【００２２】
図３は、コールドブート（パワーオフ／オン、リセット）に応答してフレームワーク下のプラットフォームにより実行されるオペレーションを示すよう用いられるイベントシーケンス／アーキテクチャダイアグラムを示す。プロセスは、プレＥＦＩ初期化環境（ＰＥＩ）位相、ドライバ実行環境（ＤＸＥ）位相、ブートデバイス選択（ＢＤＳ)位相、過渡システムロード（ＴＳＬ）位相、および、オペレーティングシステム実行時（ＲＴ）位相を含むいくつかの位相に論理的に分割される。位相は、積層され、ＯＳおよびプラットフォームのための適切な実行時環境を提供する。
【００２３】
ＰＥＩ位相は、プロセッサ（ＣＰＵ）、チップセット、および、マザーボードの特定の初期設定ルーチンをロードしかつ起動させる標準化された方法を提供する。ＰＥＩ位相は、位相を連続させるための安定した基盤を提供するのに十分なシステムを初期化する役割を担う。ＣＰＵ、チップセット、および、メインボード（すなわち、マザーボード）を含むプラットフォームのコア構成要素の初期化は、ＰＥＩ位相の間に実行される。この位相は、「初期の初期化」とも呼ばれる位相である。この位相の間に実行される典型的なオペレーションは、ＰＯＳＴ（パワーオンセルフテスト）オペレーションと、プラットフォーム資源の発見を含む。特に、ＰＥＩ位相では、メモリを見つけ、ＤＸＥ位相に伝えられる資源マップを準備する。ＰＥＩ位相の終端におけるシステムの状態は、ハンドオフブロック（ＨＯＢ）と呼ばれる場所に依存しないデータ構造のリストによりＤＸＥ位相に伝えられる。
【００２４】
ＤＸＥ位相は、システムの大半が初期化される位相である。ＤＸＥ位相は、ＤＸＥコア３００、ＤＸＥディスパッチャ３０２、および、一組のＤＥＸドライバ３０４を含むいくつかの構成要素によって実現が容易になる。ＤＸＥコア３００は、一組のブートサービス３０６、実行時サービス３０８、および、ＤＸＥサービス３１０を生成する。ＤＸＥディスパッチャ３０２は、ＤＸＥドライバ３０４を発見し、かつ、正しい順序で実行する役割を担う。ＤＸＥドライバ３０４は、コンソールおよびブートデバイスに対しソフトウェアを抽象化すると共に、プロセッサ、チップセット、および、プラットフォーム構成要素を初期化する役割を担う。これらの構成要素は、プラットフォームを初期化し、かつ、オペレーティングシステムをブートするために必要なサービスを提供するべく協働する。また、ＤＸＥと、ブートデバイス選択位相とが協働し、コンソールを確立し、かつ、オペレーティングシステムのブートを試みる。オペレーティングシステムがそのブートプロセスの開始（すなわちＢＤＳ位相の開始）に成功すると、ＤＸＥ位相は終了する。ＤＸＥコアによって提供された実行時サービス、および、選択ＤＸＥサービス、および、実行時ＤＸＥドライバによって提供された選択サービスだけがＯＳ実行時環境に存続することを許容される。ＤＸＥの結果は、完全に形成されたＥＦＩインターフェースを表す。
【００２５】
ＤＸＥコードは、ＣＰＵ、チップセット、または、プラットフォームに依存しない、完全な携帯型に設計される。これは、いくつかの機能で設計することにより、達成される。第１に、その初期状態では、ＤＸＥコアだけがＨＯＢリストに依存する。つまり、ＤＸＥコアは、前の位相からのどのサービスにも依存しないので、前の位相すべてをいったんアンロードして、ＨＯＢリストをＤＸＥコアに渡すことができる。第２に、ＤＸＥコアは、いかなるハードコード化アドレスも含まない。さらに、ＤＸＥコアは、物理的メモリ内のどこにでもロードすることができ、物理メモリまたはファームウェアセグメントがプロフェッサの物理アドレス空間内のどこに位置しようと、正しく機能することができる。第３に、ＤＸＥコアは、ＣＰＵ特定、チップセット特定、または、プラットフォーム特定情報のいずれも含まない。その代わりに、ＤＸＥコアは、一組のアーキテクチャのプロトコルインターフェースを介し、システムハードウェアから抽出される。これらアーキテクチャのプロトコルインターフェースは、ＤＸＥディスパッチャ３０２により起動されるＤＸＥドライバ３０４により生成される。
【００２６】
ＤＸＥコアは、図４に示すような、ＥＦＩシステムテーブル４００と、それに付随するブートサービス３０６および実行時サービス３０８のセットとを生成する。また、ＤＸＥコアは、ハンドルデータベース４０２を維持する。ハンドルデータベースは、１つ、または、それ以上のハンドルのリストを含み、ハンドルは、それぞれのプロトコル４０４にマップする１つ、または、それ以上の一意的なプロトコルＧＵＩＤ（グローバル一意識別子）
【００２７】
のリストである。プロトコルは、一組のサービスのためのソフトウェア抽象化である。いくつかのプロトコルは、入出力デバイスを抽象し、他のプロトコルは、共通の一組のシステムサービスを抽象する。プロトコルは、通常、一組のＡＰｌと、いくつかのデータフィールドを含む。プロトコルごとにＧＵＩＤによって名前がつけられ、ＤＸＥコアは、プロトコルがハンドルデータベース内に登録されることができるようにするサービスを生成する。ＤＸＥディスパッチャがＤＸＥドライバを実行すると、プラットフォームの具体的な詳細からＤＸＥコアを抽出するために使用されるアーキテクチャのプロトコルを含むハンドルデータベースにさらなるプロトコルが追加されてもよい。
【００２８】
ブートサービスは、ＤＸＥおよびＢＤＳ位相の間に使用される一組のサービスを含む。これらのサービスは、特に、メモリサービス、プロトコルハンドラサービス、および、ドライバサポートサービスを含む。メモリサービスは、バイト境界でメモリページおよびメモリプールを割り当て／解除するためのサービスを提供する。また、メモリサービスは、プラットフォームにおける現在の物理メモリの使用すべてのマップを検索するためのサービスを提供する。プロトコルハンドラサービスは、ハンドルデータベースに／からハンドルを追加／除去するためのサービスを提供する。また、プロトコルハンドラサービスは、ハンドルデータベースのハンドルに／からプロトコルを追加／除去するためのサービスを提供する。追加サービスは、あらゆる構成要素がハンドルデータベース内でハンドルを探すことができ、かつ、ハンドルデータベース内でプロトコルの開始および終了ができるようにするサービスである。サポートサービスは、プラットフォーム内でドライバとデバイスとを接続および切断するサービスを提供する。これらのサービスは、ＢＤＳ位相で用いられることにより、すべてのドライバがすべてのデバイスに接続されるか、または、最小数のドライバだけが、コンソールを確立しかつオペレーティングシステムをブートするため（すなわちすばやいブート機構をサポートするため）に必要とされるデバイスに接続される。
【００２９】
ブートサービスとは対照的に、実行時サービスは、プレブートとＯＳ実行時動作の間のどちらでも利用できる。本願明細書において開示される実施例により導入される１つの実行時サービスは、変数サービスである。以下に詳細に説明するように、変数サービスは、揮発性および不揮発性記憶装置から環境変数を探索し、追加し、かつ、除去するためのサービスを提供する。
【００３０】
ＤＸＥサービステーブルは、プレブートの間だけ利用可能な第１のＤＸＥサービス４０６Ａセットと、プレブート間およびＯＳ実行時間の両方で利用可能な第２のＤＸＥサービスセットとに対応するデータを含む。プレブートだけのサービスは、プラットフォーム内のＩ／Ｏ資源、メモリマップされたＩ／Ｏ資源、および、システムメモリ資源を管理するためのサービスを提供するグローバルコヒーレンスドメインサービスを含む。また、プレブートだけのサービスは、ＤＸＥディスパッチャによりディスパッチされるＤＸＥドライバを管理するためのサービスを提供するＤＸＥサービスも含む。
【００３１】
ブートサービス３０６、実行時サービス３０８、および、ＤＸＥサービス３１０のそれぞれにより提供されるサービスは、ＡＰＩ３１２、３１４、および、３１６の各セットを介しアクセスされる。ＡＰＩは、連続的にロードされる構成要素がＤＸＥコアにより提供される選択されたサービスを導入できるようにする抽象インターフェースを提供する。
【００３２】
ＤＸＥコア３００が初期化された後、制御は、ＤＸＥディスパッチャ３０２へと移る。ＤＸＥディスパッチャは、ＥＦＩフレームワーク下でファームウェアがそこからロードされる論理記憶装置に対応するファームウェア容量内で見つけられるＤＸＥドライバをロードしかつ起動する役割を担う。ＤＸＥディスパッチャは、ＨＯＢリストによって記述されたフレームウェア容量におけるドライバを探索する。実行を続けているうちに、他のファームウェア容量も見つかる可能性がある。そのときは、ディスパッチャは、そこで同様にドライバを探す。
【００３３】
ここにＤＸＥドライバの２つのサブクラスがある。第１のサブクラスは、ＤＸＥ位相内でごく初期に実行するＤＸＥドライバを含む。これらＤＸＥドライバの実行順序は、アプリオリファイルの存在および内容と、依存関係の表示の評価とに基づく。これら初期のＤＸＥドライバは、通常、プロセッサ、チップセット、および、プラットフォーム初期化コードを含むこともある。また、これら初期のドライバは、ブートサービスおよび実行時サービス完全なものとするようＤＸＥコアに要求されるアーキテクチャのプロトコルを生成することもある。
【００３４】
ＤＸＥドライバの第２のクラスは、ＥＦＩ１．１０ドライバモデルに準拠するものである。これらは、ＤＸＥディスパッチャにより実行されるときは、ハードウェアの初期化を実行しない。その代わり、ハンドルデータベース内にドライババインディングプロトコルインターフェースを登録する。ドライババインディングプロトコルのセットは、コンソールを確立し、かつ、ブートデバイスへのアクセスを提供するよう要求されるデバイスにドライバを接続すべくＢＤＳ位相で使用される。ＥＦＩ１．１０ドライバモデルに準拠するＤＸＥドライバは、コンソールデバイスおよびブートデバイスのソフトウェア抽象化を明確に依頼された場合、最終的にはそれを提供する。
【００３５】
ＤＸＥドライバのどれでもブートサービスおよび実行時サービスを使ってそれらの機能を実行することができる。しかしながら、初期のＤＸＥドライバは、アーキテクチャのプロトコルすべての登録がすんでいるわけではないので、それらを実行してもすべてのサービスが利用できるわけではないことを知っておく必要がある。ＤＸＥドライバは、依存関係の表示を用い、実行前に必要とするサービスおよびプロトコルインターフェースが利用可能であることを保証しなければならない。
【００３６】
ＥＦＩ１．１０ドライバモデルに準拠するＤＸＥドライバには前記のような懸念は不要である。これらのドライバは、実行時に、ドライババインディングプロトコルをハンドルデータベースにただ登録すればよい。このオペレーションは、アーキテクチャのプロトコルを使用しなくても実行できる。ドライババインディングプロトコルの登録と関連し、ＤＸＥドライバは、インストールコンフィギュレーションテーブル関数を用い、ＡＰＩを「公開」してもよい。この公開されたドライバは、ＡＰＩ３１８で表される。ＥＦＩ下では、ＡＰＩの公開により、他のファームウェア構成要素によりアクセスするためのＡＰＩが公にされる。ＡＰＩは、ＤＸＥドライバがそれぞれの寿命の間に対応するデバイス、バス、または、サービスのためのインターフェースを提供する。
【００３７】
ＢＤＳアーキテクチャのプロトコルは、ＢＤＳ位相間で実行する。ＢＤＳアーキテクチャのプロトコルは、プレブートサービス環境で実行するさまざまなアプリケーションを見つけ、ロードする。このようなアプリケーションは、従来のＯＳブートローダ、または、最終的なＯＳをロードする前にあるいはそれに代わって動作する拡張サービスを表すこともある。このような拡張プレブートサービスは、セットアップ設定、拡張診断、フラッシュアップデートサポート、ＯＥＭ値追加、または、ＯＳブートコードを含んでもよい。ブートディスパッチャ３２０は、ブートターゲット、例えば、システムによりブートされるＯＳの選択を可能にするよう、ＢＤＳ位相間で用いられる。
【００３８】
ＴＳＬ位相間で、最終ＯＳブートローダ３２２は、選択されたＯＳをロードするよう実行される。ＯＳが一旦ロードされてしまえば、ブートサービス３０６、および、ＤＸＥサービス３０６ＡのようにＡＰＩ３１８を介しＤＸＥドライバに接続して設けられた多くのサービスは必要なくなる。したがって、ＯＳ実行時の間にアクセスできる数の減ったＡＰＩのセットは、図３のＡＰＩ３１６Ａおよび３１８Ａとして示される。
【００３９】
本発明の原理の下で、ＯＳにトランスペアレントなバンド外通信スキームが用いられることにより、さまざまなタイプの資源をサーバノード全体で共有することが可能になる。同時に、ファームウェアベースの構成要素（ファームウェアドライバおよびＡＰＩなど）が用いられることにより、資源への低レベルのアクセス、および、ＯＯＢチャネルにおけるデータのルート変更が容易になる。このスキームは、ブレード群、個別のシャーシ、ラック、または、ラック群を含む多数のコンピューティングプラットフォーム全体で実行されてもよい。システム初期化の間、各プラットフォームに設けられたファームウェアは、ＯＯＢチャネル、適切な資源へのアクセス、および、データルート変更機構をセットアップするよう、ロードされかつ実行される。その後、各ブレードは、その共有資源に関する情報を、ＯＯＢを介しグローバル資源マネージャに伝送する。グローバル資源マネージャは、データを集め、「仮想」グローバル資源を構成する。グローバル資源記述子形式のグローバル資源構成データがブレードに返送されることにより、ブレードにグローバル資源の構成およびアクセス機構を通知する。その後、ドライバが構成され、グローバル資源へのアクセスをサポート持する。続いて、グローバル資源記述子が、ＯＳロードの間にオペレーティングシステムに渡される。ここでは、仮想グローバル資源は、オペレーティングシステムにはローカルデバイスのように見え、ＯＳ実行時のオペレーションの間に、ＯＳコードへの修正を必要とせずにローカルデバイスとして用いられる。プロセスの一実施例に従うフローチャート動作およびロジックが図５および７に示されており、それに対応するさまざまな構成要素間の動作およびやりとりは、図６、８Ａ、および、８Ｂに示されている。
【００４０】
図５によると、プロセスは、資源デバイスドライバおよびＯＯＢ通信フレームワークをセットアップするべく、各ブレードでいくつかの初期化オペレーションを実行することにより開始する。開始ブロック５００で示すように、パワーオン、または、リセットに応答し、システムは、図３を参照して前述したように、プレブートシステム初期化オペレーションを実行する。まず、各ブレードのブートファームウェアデバイス（ＢＦＤ）に格納されたファームウェアをロードして実行することにより、ブロック５０２における初期の初期化オペレーションが実行される。ＥＦＩ下では、ＢＦＤは、システムをブートするためのファームウェアを格納するファームウェアデバイスを含む。例えば、サーバブレード２００のＢＦＤは、ファームウェアデバイス２０８を含む。
【００４１】
続いてブロック５０２では、プロセッサ２０２がリセットベクトルを介しＢＦＤのブートブロックのベースアドレスに実行をジャンプさせるリセットスタブコードを実行する。ブートブロックは、初期の初期化を実行するためのファームウェア命令を含み、かつ、プロセッサに２０２よって実行されることにより、ＣＰＵ、チップセット、および、マザーボードを初期化する。（ウォームブート（リセット）の間は、初期の初期化は実行されないか、または、限られた方式で実行されることに注意。）次に、ＤＸＥ位相を導く、ＥＦＩコアに対応するファームウェア命令が実行される。ＤＸＥコア初期化の間に、図３および４を参照して上述したように変数サービスがセットアップされる。ＤＸＥコアが初期化されると、ＤＸＥディスパッチャ３０２は、ＤＸＥドライバ３０４をロードし始める。各ＤＸＥドライバは、システム構成要素に対応し、その構成要素に直接アクセスするためのインターフェースを提供する。ＤＸＥドライバは、ＯＯＢ通信を容易にするよう続いて用いられるＯＯＢモニタドライバに含まれる。
【００４２】
次に、ブロック５０４で、ＯＯＢモニタドライバは、各ブレードの保護された領域にインストールされる。上述したように、オペレーティングシステムにより管理されるネットワーク通信と関わりなく動作するバンド外通信チャネルまたはネットワークが、ブレード間通信を容易にする目的でＯＳに対しトランスペアレントに用いられる。
【００４３】
前述のブロック５０２におけるシステム初期化オペレーションの間に、システムメモリ２０４の一部がシステムを管理する目的で用いられるよう、セットアップされる。メモリのこの部分は、ＳＭＲＡＭ６００と呼ばれ（図６参照）、続いてロードされるオペレーティングシステムからは見えないようになっている。
【００４４】
ファームウェアのロードと共に、ファームウェアに格納されたＳＭＭ ＯＯＢ通信コード６０２がＳＭＲＡＭ６００にロードされ、ＯＯＢ通信を処理するための対応するＯＯＢ通信ＳＭＭハンドラ６０４がセットアップされる。ＳＭＭハンドラは、一種の割込みハンドラであって、システム管理割込み（ＳＭＩ）に応答して起動する。次に、システムプロセッサのＳＭＩピンを介し、ＳＭＩ割込みがアサートされる。ＳＭＩ割込みに応答し、プロセッサは、その時のコンテキスト（すなわち、その時の実行モード、スタック、および、レジスタ情報などを含む現在のオペレーションに関する情報）を格納し、かつ、その実行モードをそのシステム管理モードに切り替える。その後ＳＭＭハンドラは、それらがＳＭＩイベントをサービスするのに適切なハンドラかどうかを決定するべく順次ディスパッチされる。この決定は、どのハンドラが適切であるかを決定するにあたりほとんど待ち時間がないように、ＳＭＭハンドラコードにおいて非常に早期になされる。ハンドラが識別されると、ＳＭＩイベントのサービスを終了させることができる。ＳＭＩイベントのサービスが終了すると、ＲＳＭ（再開）命令が発せられ、予め保存されたコンテキストデータを用い、プロセッサはそれ以前の実行モードに戻る。最終的な結果としては、ＳＭＭオペレーションは、完全にオペレーティングシステムに対し、トランスペアレントになる。
【００４５】
図５のフローチャートに戻り、ブレードによってホストされる１つまたはそれ以上の共有可能な資源が見つかるかどうかの決定が決定ブロック５０６でなされる。一般的に、共有資源は、共有アクセスを可能にするブレード構成要素またはデバイスである。このような構成要素およびデバイスは、固定記憶装置、可換型媒体装置、入力装置（キーボード、マウスなど）、ビデオデバイス、オーディオデバイス、揮発性メモリ（すなわちシステムＲＡＭ）、および、不揮発性メモリなどを含むが、これに限定されない。
【００４６】
決定ブロック５０６への返事がＹＥＳの場合、ロジックは、発見される共有可能な資源それぞれに対する開始および終了ループブロック５０８および５０９それぞれの範囲内で定義されるループ操作の実行に進む。これは、ブロック５１０における操作を含み、ここで、共有資源を記述するためのデバイス経路が形成され、構成パラメータが収集される。デバイス経路は、外部のユーザに、資源にアクセスするための手段を提供する。構成パラメータは、以下に詳細に説明するグローバル資源を構築するために使用される。
【００４７】
ブロック５１０のオペレーションが実行された後、図示された実施例において、デバイス経路および資源構成情報が、ブロック５１２におけるＯＯＢ通信チャネル６１０を介し、グローバル資源マネージャ６０８に伝送されるかまたは同報される。グルーバル資源マネージャは、通常、ブレードの１つ、または、マネジメントカード１１２などの既存の構成要素によりホストされることもできる。後述するように、一実施例において、複数のローカルグローバル資源マネージャが用いられる。ここでは、グローバル資源マネジメントは、単一のマネージャを用いるよりはむしろ、集合的なプロセスを通じて処理される。グローバル資源マネージャをホストする構成要素のアドレスが公知のアプリオリである場合、その構成要素への選択的な伝送が用いられる。アドレスが知られていない場合、まず、ＯＯＢチャネルを介しメッセージが同報され、ホスト構成要素の位置が識別される。
【００４８】
前述したようにＳＭＭが隠された実行モード下でのＯＯＢ通信は、以下の方法で実行される。まず、ブレード間通信が実行されるブレードにおけるオプロセッサのオペレーティングモードをＳＭＭに切り替える必要がある。したがって、図６のＢＬＡＤＥ１のように、プロセッサをＳＭＭに切り替える目的でＳＭＩが生成される。これは、２つの手段のうちの１つにより実行される。１つは、プロセッサＳＭＩピンのアサーション（すなわち、ハードウェアによる生成）、もう１つは、ＳＭＩ命令を発することによるもの（すなわち、ソフトウェアに基づく生成）である。
【００４９】
一実施例では、ＳＭＩピンのアサーションは、マネジメントバスなどに適切な信号を配置することにより生成できる。例えば、Ｉ２Ｃを用いてＳＭＢＵＳが配備されると、バスラインの１つは、各ブレードプロセッサのＳＭＩピンに、そのブレードコネクタを介し直結されてもよい。また、インターフェース平面が同様の結果を生じる個別の手段を提供するようにしてもよい。構成に基づき、すべてのＳＭＩピンが共通に、単一のバスラインに結合されてもよいし、あるいは、バスは、それぞれのブレードに対し個別のＳＭＩピンアサーションを可能にするよう構成されてもよい。さらに、インテル?製などの特定のネットワークインターフェースチップは、従来のネットワーク通信に使用される第１のＭＡＣアドレスに加え、「バックチャネル」として使用される第２のＭＡＣアドレスを提供する。さらにまた、これらＮＩＣは、ビルトインシステム管理機能を提供する。この機能により、第２のＭＡＣアドレスを参照する着信がＮＩＣによるＳＭＩ信号のアサートを可能にする。このスキームは、ＯＯＢチャネルが「公衆」ネットワーク（図示せず）として同じ配線上に配備されることを可能にする。
【００５０】
一実施例では、ＯＯＢチャネルにアクセスするためにファームウェアドライバが用いられる。例えば、ＯＯＢチャネルがネットワークまたは直列の手段を介し実行されるとき、ネットワークまたはシリアルポートにアクセスするための適切なファームウェアドライバが提供される。このファームウェアドライバの構成は予め公知であってもよいので（したがってオペレーティングシステムとは独立している）、ＳＭＭハンドラは、ファームウェアドライバを介し、ＯＯＢチャネルに直接アクセスできる。また、Ｉ２Ｃのような専用マネジメントバスの場合、対応するファームウェアドライバを用いずにＳＭＭハンドラへの直接アクセスが可能になるが、ファームウェアドライバを用いてもかまわない。
【００５１】
ＳＭＩピンのアサーションに応答し、アサートされたプロセッサは、ＳＭＭ実行モードに切り替わり、適切なハンドラ（例えば通信ハンドラ６０４）がディスパッチされるまで、ＯＯＢ通信を容易にするべくそのＳＭＭハンドラをディスパッチする。そして、ＯＯＢ通信ネットワーク／チャネルオプションのそれぞれにおいて、ブレードプロセッサがＳＭＭで動作中であるとき、ＯＯＢ通信が実行され、それによって、通信は、それらのブレードで動作するオペレーティングシステムに対しトランスペアレントになる。
【００５２】
ブロック５１４に従い、グローバル資源マネージャ６０８により共有デバイス経路および資源構成情報が受信され、同様に、他のブレードの共有デバイス経路および資源構成情報もグローバル資源マネージャにより受信される。
【００５３】
本発明の一態様によれば、個々の資源が結合されることにより、グローバル資源を形成してよい。例えば、個別の記憶装置（ハードディスクおよびシステムＲＡＭなど）により提供される記憶領域が集結し、１つまたはそれ以上の「仮想」記憶ボリュームを形成することもできる。これは、ブロック５１６における資源構成情報を結集させることにより一部実現できる。ハードディスク資源の場合、資源構成情報は、通常、デバイスのアサーションに使用される記憶ブロックの数、分割化情報、および、他の情報などの記憶容量を含んでよい。資源構成情報が収集された後、グローバル資源アクセス機構（例えばＡＰＩ）、および、グローバル資源記述子６１２が構築される。グローバル資源記述子は、資源へのアクセス方法を識別する情報を含み、かつ、資源の構成（グローバルおよび／またはローカルの観点から）を記述する。
【００５４】
ブロック５１６のオペレーション終了後、グローバル資源記述子６１２は、ブロック５１８のＯＯＢチャネルを介し、ラック内のアクティブノードに伝送される。この伝送は、ノード対ノードのＯＯＢ通信を用い、または、ＯＯＢ同報通信を介し実行されてよい。グローバル資源記述子の受信に応答し、次の資源処理を導くブロック５２０におけるノードを受信することによりグローバル資源記述子は格納される。ブロック５１０、５１２、５１４、５１６、５１８、および、５２０のオペレーションは、共有可能なすべての資源が処理されるまで、発見されたそれぞれの資源ごとに同様のやり方で繰り返し実行される。
【００５５】
一実施例によれば、共有資源へのアクセスは、ブロック５２２におけるそれらのグローバル資源ＡＰＩを介し発見された共有資源にアクセスするよう構成された対応するファームウェアデバイスドライバにより提供される。特定の資源に適用されるときのこのアクセススキームの詳細は、以下に述べる。次のブロック５２４に示されるように、ＯＳのロードを準備するために前述のように継続してプレブートプラットフォーム初期化オペレーションが行われる。
【００５６】
ブロック５２６におけるＯＳロードの間に、発見された任意の共有資源に対応するグローバル資源記述子は、オペレーションシステムに渡される。ＯＳに渡されるグローバル資源記述子は、ブロック５１６で作成されたものと同じであってもなくてもかまわない。本質的に、グローバル資源記述子は、それ自身のデバイスドライバを介しオペレーティングシステムが資源へのアクセスを設定できるようにするための情報を含む。例えば、単一の共有記憶ボリュームの場合、ＯＳは、共有される個別の記憶装置の個別の記憶容量におよぶ記憶容量を有する「ローカル」記憶装置（または任意でネットワーク化された記憶装置）へのアクセスを有することを示す情報を受信する。多数の共有記憶ボリュームの場合は、それぞれの記憶容量情報は、それぞれのボリュームに対するＯＳに伝えられてよい。ＯＳのロードの完了により、次のブロック５２８に示されるようなＯＳ実行時オペレーションが導かれる。
【００５７】
ＯＳの実行中、グローバル資源は、オペレーティングシステムと、「低レベル」アクセスを共有資源に提供するよう構成されたファームウェア構成要素との組合せによりアクセスされる。最新のＯＳ／ファームウェアアーキテクチャ下では、デバイスアクセススキームは、オペレーティングシステムベンダがそれぞれ個別のデバイスに特有のデバイスドライバの書き込みを必要としないよう、意図的に抽象化され、これらのさらなる明確なアクセスの詳細は、対応するファームウェアドライバにより提供される。このアーキテクチャの成果の１つは、オペレーティングシステムがハードウェアデバイスに直接アクセスしなくてもいいことである。このことは、さまざまな点で有利である。特に、オペレーティングシステムは、デバイスの特別な低レベルアクセス構成を知る必要がない。したがって、個々のデバイスの資源を結集させた「仮想」資源を「構築」でき、適切に構成されたファームウェアドライバを介しこのようなデバイスに対応するアクセスが抽象化されることにより、ＯＳは、仮想資源が実際のローカルデバイスであるとみなすようになる。
【００５８】
一実施例において、この抽象化されたアクセススキームは、図８Ａおよび８Ｂに示されるような多層アーキテクチャとして構成される。各ブレードＢＬＡＤＥ１およびＢＬＡＤＥ２は、ＯＳデバイスドライバ８００−１および８００−２と、マネジメント／アクセスドライバ８０２−１および８０２−２と、資源デバイスドライバ８０４−１および８０４−２と、ＯＯＢ通信ハンドラ６０４−１および６０４−２とを含むアーキテクチャ構成要素のそれぞれのコピーを有する。
【００５９】
図７は、一実施例に従う共有資源にアクセスするための例示的プロセスを示すフローチャートである。このプロセスは、開始ブロック７００で示されるように、リクエスタからのアクセス要求により開始する。典型的なリクエスタは、プラットフォームのオペレーティングシステムで実行するアプリケーションであってもよい。このようなアプリケーションに対応する実行可能なコードは、図８Ａおよび８Ｂにおける実行時（ＲＴ）アプリケーション（ＡＰＰ）８０６および８０８により示されるようなシステムメモリ２０４に通常格納される。例えば、実行時アプリケーション８０６が共有データ記憶資源へのアクセスを望んでいると仮定する。この例では、アクセス要求は、予め格納されたファイルのオープンに対応する。ファイルの場所（ドライブ指定、経路およびファイル名など）が提供されると、実行時アプリケーションは、まず、ファイルにアクセスするようオペレーティングシステム（８１０）に要求する。ドライブ指定は、ブレード１の資源１と、ブレード２の資源２とを含む複数のディスクドライブ２１８を備える仮想グローバル記憶資源に対しオペレーティングシステムにより予め割り当てられたドライブレターである。
【００６０】
要求に応答し、オペレーティングシステム８１０は、ブロック７０２における記憶資源にアクセスするべくそのＯＳデバイスドライバ８００−１を用いる。通常、ＯＳデバイスドライバ８００−１が資源ドライバ８０４−１と直接インターフェースして資源１にアクセスする。しかしながら、マネジメント／アクセスドライバ８０２−１が代わりにアクセスされる。このような変更を実現するためには、ＡＰＩのようなインターフェース情報がＯＳロードの間にＯＳに伝えられ、それによって、ＯＳは、対応する資源（例えば資源１）にアクセスする要求があるときはいつでも、マネジメント／アクセスドライバ８０２−１にアクセスするよう命じられる。
【００６１】
どの共有資源がその要求にサービスを提供するかを決定するべく、適切な資源がアクセスできる特定のホストを識別するための機構が提供される。一実施例において、この機構は、グローバル資源マップにより実現が容易になる。図８ａの実施例において、共通のグローバル資源マップのローカルコピー８１２−１、および、８１２−２は、ブレードＢＬＡＤＥ１およびＢＬＡＤＥ２のそれぞれに格納される。図８Ｂの実施例では、共有グローバル資源マップ８１２Ａは、グローバル資源マネージャ６０８によりホストされる。グローバル資源マップは、特定の資源と、それら特定の資源によりホストされるグローバル資源の一部分とを一致させる。
【００６２】
続いて図７のフローチャートのブロック７０４において、マネジメント／アクセスドライバがローカルグローバル資源マップ８１２を問い合せ、特定のアクセス要求下にある資源のホストを決定する。この資源および／またはこれのホストは、例示された「資源ターゲット」として知られ、ＢＬＡＤＥ２にホストされる資源２を含む。
【００６３】
一旦資源ターゲットが識別されると、ＯＯＢ通信オペレーションは、資源アクセス要求を資源ターゲットに送る。まず、要求するプラットフォーム（例えば８０２−１）におけるマネジメント／アクセスドライバは、ＳＭＩをアサートし、そのプラットフォームローカルＯＯＢ通信ハンドラ６０４−１を起動する。それに応答し、ＢＬＡＤＥ１のプロセッサは、ブロック７０８で、モードをＳＭＭに切り替え、ＯＯＢ通信ハンドラ６０４−１が起動するまでにそのＳＭＭハンドラをディスパッチする。すると、ＯＯＢ通信ハンドラは、資源ターゲットホスト（ＢＬＡＤＥ２）におけるＳＭＩ信号をアサートし、２つのブレード間のＯＯＢ通信を開始する。ＳＭＩに応答し、ＢＬＡＤＥ２におけるプロセッサモードは、ブロック７１０において、そのＯＯＢ通信ハンドラを起動するＳＭＭに切り替えられる。この時点で、ブレード１および２は、ＯＯＢチャネル６１０を介し通信できるようにされ、アクセス要求は、ＯＯＢ通信ハンドラ６０４−２により受信される。一実施例において、資源アクセス要求が送信された後、「ＲＳＭ］命令がＢＬＡＤＥ１のプロセッサに発せられることにより、プロフェッサのオペレーティングモードは、ＳＭＭに切り替わる前のモードへと戻る。
【００６４】
次に、ブロック７１２において、アクセス要求は、マネジメント／アクセスドライバ８０２−２にそのＡＰＩを介し送られる。任意の実施例において、その後ブロック７１４においてクエリが実行され、アクセス要求を受信するプラットフォームがターゲット資源の実際のホストであることを確認する。もし正しいホストでない場合、一実施例では、そのことを示すリクエスタメッセージが返送される（図示せず）。他の実施例では、適切なグローバル資源マネージャが状況を把握している。基本的には、ローカルグローバル資源マップが異なる情報を含む場合（すなわちもはや同期しない）にこの状況は起きる。すると、グローバル資源マネージャは、コマンドを発し、ローカルグローバル資源マップを再び同期させる（図示せず）。
【００６５】
続いてブロック７１６では、プラットフォームホストの資源デバイスドライバ（８０４−２）が用いられ、アクセス要求にサービスを提供するよう、資源（例えば資源２）にアクセスする。本実施例では、アクセスは、要求されたデータファイルを返す。そして、ブロック７１８において、要求に対応するデータが、ＯＯＢチャネル６１０を介し、リクエスタに戻される。通信終了時において、ＢＬＡＤＥ２のプロセッサにＲＳＭ命令が発せられ、プロセッサのオペレーティングモードは、ＳＭＭに切り替わる前のモードに戻る。
【００６６】
特定の実施によっては、リクエスタのプロセッサは、この時点でＳＭＭにしてもしなくてもよい。例えば、前述の実施例において、リクエスタ（ＢＬＡＤＥ１）のプロセッサは、ブロック７０８において、ＳＭＭから切り替わる。この場合、ブロック７２２において新たなＳＭＩがアサートされ、ＯＯＢ通信ハンドラを起動させる。（任意のスキームに従い）アクセス要求を送信した後もＳＭＭモードが終了しない場合、ＯＯＢ通信ハンドラは、返送されるデータを受信するよう、すでに待機中である。いずれにせよ、ブロック７２４にで、返送されるデータは、ＯＯＢチャネル６１０を介し受信され、リクエスタのマネジメント／アクセスドライバ（８０２−１）へと渡される。次に、ブロック７２６でこのファームウェアドライバは、データをＯＳデバイスドライバ８００−１に送り、その後ブロック７２８で、そのデータは、オペレーティングシステムを介し、リクエスタにより受け取られる。
【００６７】
図８Ｂの実施例において、グローバル資源マップのローカルコピーの代わりに、単一のグローバル資源マップを用い、同様の資源アクセスプロセスが実行される。要するに、ローカルグローバル資源マップを用いるのではなく、グローバル資源マネージャ６０８が資源にアクセスするためのプロキシとして用いられることを除けば、図８Ａを参照して上記に述べたのと同じような数多いオペレーションである。したがって、資源アクセス要求は、識別された資源ターゲットに直接送られるのではなく、ＯＯＢチャネル６１０を介しグローバル資源マネージャ６０８に送信される。要求の受信と同時に、グローバル資源マップ８１２Ａの探索が実行され、資源ターゲットが決定される。続いて、データ要求は、リクエスタを識別する情報と共に、識別された資源ターゲットへと送られる。要求の受信と同時に、任意のオペレーション７１４を除くブロック７１２−７２８のオペレーションが実行される。
【００６８】
前述のスキームは、それぞれが各自の有する効果を発揮する。ローカルグローバル資源マップが用いられた場合、プロキシは必要なく、したがって、ブレードサーバ構成要素で実行するソフトウェアコンポーネントを変える必要もない。しかしながら、グローバル資源マップの同期化を促進する機構は必要なので、各ブレードに対するマネジメントオーバヘッドは増大する。単一のグローバル資源マネージャを用いる主な利点は、グローバル資源マップの同時発生が保証され（コピーが１つだけなので）、マップへの変更が個々のブレードの協力なしで行えることである。ほとんどの実施例において、主な欠点は、グローバル資源マネージャ機能のためのホストがどうしても必要になることである。通常、ホストは、マネジメント構成要素、あるいは、ブレードの１つである（例えば指名選択またはデフォルト選択されたブレード）。
【００６９】
一実施例において、グローバル資源マネージャにサービスを提供するブレードは、指名プロセスによって識別され、その場合、各ブレードは、マネジメントタスクを実行するためのファームウェアを含んでよい。一般的に、指名スキームは、シャーシスロットのような物理的割当て、または、ファーストイン順序スキームなどの活性化スキームに基づいてよい。例えば、スロットに基づくスキームでは、最下位のスロット割当てを有するブレードは、電源決定タスクが割り当てられる。このブレードが取り除かれた場合は、残りのブレードの中から、最下位スロット割当てを有するブレードが、グローバル資源マネージャのホストとなるよう指名されることもある。ファーストイン順序スキームでは、各ブレードは、ブレードが挿入されたかまたは起動された順序に基づき、挿入順序識別子（例えばナンバー）に割り当てられる。グローバルマネジメントタスクは、最初にインストールされたブレードである最も小さいナンバーのブレードに割り当てられる。このブレードが取り除かれると同時に、次に小さいインストールナンバーのブレードが新たな電源決定器として指名される。グローバル資源マネージャにおける変更全体の連続オペレーションを確実にする目的で、冗長スキームが実行され、そこで第２のブレードがライブバックアップとして指定される。
【００７０】
通常、グローバル資源マッピングデータは、システムメモリ内、または、ファームウェア変数データとして格納されてよい。ファームウェア変数データとして格納された場合、マッピングデータは、プラットフォームのシャットダウンの間持続できる。一実施例において、マッピングデータは、オペレーティングシステムから見えないシステムメモリの一部が格納される。システムメモリの見えない部分は、プレブートオペレーションの間、ＳＭＲＡＭの一部またはファームウェアによりリザーブされるメモリの一部を含んでよい。シャットダウンの間グローバル資源マッピングデータを持続させるやり方として、ディスクドライブのような持続性記憶装置にデータを格納する方法がる。しかしながら、ディスクドライブを用いる場合は、マッピングデータをディスクドライブのホスト保護領域（ＨＰＡ）など、プラットフォームオペレーティングシステムにアクセスされないように格納することが推奨される。グローバル資源マッピングデータが中央レポジトリに格納される場合（すなわち、図８Ｂの実施例により示されるように）、上記に提示されたものと同様のさまざまな記憶オプションを用いることもできる。グローバル資源マネージャが複数のサーバブレード以外の構成要素によりホストされる場合（例えば、マネジメントカード１１２または外部マネジメントサーバによりホストされる場合）、それらのホストには、ブレードで動作するオペレーティングシステムがアクセスできないので、ディスク記憶装置は安全に実行されることができる。
【００７１】
資源共有のより特殊な実施例を図９Ａ−Ｂおよび１０Ａ−Ｂに示す。これらのケースでは、共有される資源は、ディスクドライブ２１８を含む。図９Ａおよび１０Ａに示された実施例９００において、複数のディスクドライブ２１８により提供される記憶資源は、仮想記憶ボリューム"Ｖ："を形成するよう結集される。説明を明確にするべく、各ディスクドライブの記憶資源は、１０ブロックを含むＩ／Ｏ記憶群それぞれとして示される。さらに、各ブレード１−１６は、単一のディスクドライブ２１８のホストであることが示されている。実際の実行において、各ブレードは、０−Ｎディスクドライブをホストしてもよく（その構成に基づく）、各ディスクドライブのブロック数は、変化してよい。また、実際のブロック数は、ここに示されているものより桁違いに多くすることもできる。
【００７２】
オペレーティングシステムの見地からすると、仮想記憶ボリュームＶ：は、単一の記憶装置である。一般的に、共有記憶資源は、１−Ｎ仮想記憶ボリュームとして構成され、各ボリュームは、記憶装置のそれぞれのセットごとに張られた空間である。現実には、仮想記憶ボリュームＶ：は、１６のディスクドライブ２１８におよぶ。これを実現するため、ルックアップテーブル１０００を含むブローバル資源マップが用いられる。ルックアップテーブルは、Ｉ／Ｏブロックのそれぞれの範囲をＩ／Ｏブロックをホストするディスクドライブが存在するブレードにマップする。多数のディスクドライブをホストすることが可能な単一のブレードの場合、マップは、各ブレードにおける特定の記憶装置を識別する情報をさらに含むこともある。一般的に、ブレード数を単純に識別するよりはむしろ、アドレッシングスキームが用いられているが、説明を明確かつ単純にするため、ブレード数を割り当てて示している。
【００７３】
図９Ｂおよび１０Ｂは、ＲＡＩＤ（個別ディスクの冗長配列）−１標準に従うミラーリングおよびデュプレキシングを用いたＲＡＩＤ実施例９０２を示す。ＲＡＩＤ−１において、記憶装置のそれぞれのセットが対になり、データは、データの同一セットが対になった各記憶装置に書き込まれることにより、反映される。前述と同様の方法において、集結した記憶は、オペレーティングシステムに対し、仮想ボリュームＶ：として見える。図示された実施例において、記憶装置の数および種類は、実施例９００の記憶装置と同一であり、したがって、仮想ボリュームのブロックＩ／Ｏ記憶容量は、８０ブロックに半減する。グローバル資源マッピングは、オペレーティングシステムが対応するブロックＩ／Ｏアクセス要求を作成するとき、どのディスクドライブがアクセスされるかを決定するためのルックアップテーブル１００２に含まれる。ディスクドライブの対は、ＡからＨまでのラベルが付けられた論理記憶装置エンティティに分割される。
【００７４】
ＲＡＩＤ−１の原理に従い、論理記憶装置エンティティへの書き込みアクセスが実行されたとき、データは、基になる記憶装置それぞれに書き込まれる。一方、読み込みアクセスの間は、データは、（概ね）単一の記憶装から検索される。ＲＡＩＤ−１の実施の複雑さによっては、記憶装置の対の１つがデフォルト読み込みデバイスとして割当てられるか、または、記憶装置の両方により、並列読取り（デュプレキシング）を考慮に入れたこの機能を容易にすることができる。
【００７５】
図示された構成に加え、１つ、または、それ以上のディスクドライブ２１８を「ホットスペア」として用いる構成もある。この場合、ホットスペア記憶装置は、通常のアクセス操作の間には用いられず、故障したデバイスまたはブレードと交換するための予備となる。規格では、ホットスペアの交換が発生すると、（対の）故障していないデバイスに格納されたデータが交換デバイスに書き込まれることにより、記憶システムは、完全な冗長状態に戻る。これは、インタラクティブな方法で実行してもよく（例えば、並行して新たなデータ書き込みを許容するなど）、または、新たな書き込みを許容する前に実行してもよい。
【００７６】
一般的に，ＲＡＩＤ−１スキームは、単一のグローバル資源マネージャを用いるか、または、ローカルマネジメントを介すかのいずれかにより展開されることができる。例えば、（スタティック資源構成に対応して）「スタティック」マップが用いられる場合、適切なマッピング情報は、各ブレードに格納されることができる。一実施例では、この情報は、ファームウェア変数データとして格納されることもでき、それによって、プラットフォームのリセットまたはシャットダウンの間も持続することができる。動的な構成環境では、構成変化に対応するアップデートされた資源マッピングを少なくとも決定するための中央グローバル資源マネージャを用いることが望ましい。
【００７７】
ＲＡＩＤ−１に加え、ＲＡＩＤ−０、ＲＡＩＤ−２、ＲＡＩＤ−３、ＲＡＩＤ−５、および、ＲＡＩＤ−１０を含む他のＲＡＩＤ標準冗長記憶スキームを用いてもよい。これらのスキームはそれぞれある形式のストライピングを含むので、グローバル資源マップの複雑さが実質的に増す。さまざまな理由から、個別のローカルマネージャよりはむしろ中央グローバル資源マネージャを介した方が、ＲＡＩＤ−０、ＲＡＩＤ−２、ＲＡＩＤ−３、ＲＡＩＤ−５、および、ＲＡＩＤ−１０の実行は、より容易になる。
【００７８】
前述の原理は、ブレードサーバ環境を背景に述べられているが、これに限定されない。各ブレードは、ラックマウントサーバ、または、スタンドアロンサーバなどの独立したプラットフォームとみなしてよく、複数のプラットフォームにわたる資源共有は、ＯＯＢチャネルを介し、前述と同様のやり方で実現することができる。例えば、ラックマウントサーバ構成における配線および／またはルーティングは、ＯＯＢチャネルをサポートする目的で提供されてよい。
【００７９】
ラックマウントサーバなどに適切である、本発明の特定の実施例は、通常ＫＶＭとして知られる共有キーボード・ビデオ・マウスＩ／Ｏに関する。典型的なラックサーバでは、ＫＶＭスイッチが用いられることにより、単一のキーボード、ビデオディスプレイ、および、マウスがラック内のすべてのサーバに共有されることができるようになる。ＫＶＭスイッチは、別々のサーバから（それぞれのケーブルを介し）単一のキーボード、ビデオ、および、マウスＩ／ＯポートにＫＶＭ信号を送り、それによって、選択されたサーバのＫＶＭ信号は、選択ノブを回すことにより、または、入力信号源を選択することにより、アクセスされることができる。高密度サーバでは、配線および設置にかかるコストに加え、ＫＶＭスイッチに１５００ドルの費用がかかることもある。また、ＫＶＭ配線は、ベンチレーションおよびアクセスの可能性を低下させる。
【００８０】
前述した問題は、図１１-１３に示された共有ＫＶＭ実施例により解決される。図１１では、複数のラックマウントサーバ１１００のそれぞれは、スイッチ１１０２、および、対応するイーサネット配線（ネットワーク雲１１０４として図示）を介し他のサーバに接続される。各サーバ１１００は、プロセッサ１１０８、メモリ１１１０、ファームウェア記憶装置１１１２、および、ＮＩＣ１１１４を含む複数の構成要素がその上に装着されるかまたはそれに結合されるメインボード１１０６を含む。複数のＩ／Ｏポートも、マウスおよびキーボードポート１１１６および１１８と、ビデオポート１１２０とを含むメインボードに結合される。通常、各サーバは、複数のディスクドライブ１１２２を含む。
【００８１】
上述のＮＩＣに基づくバックチャネルＯＯＢスキームによれば、各サーバ１１００のＮＩＣ１１１４に割り当てられた第２のＭＡＣアドレスが用いられることにより、ＯＯＢチャネル１１２４をサポートする。キーボード１１２６、ビデオディスプレイ１１２８、および、マウス１１３０は、それぞれのケーブルを介し、サーバ１１００Ａの後部に配置されたＩ／Ｏポート１１１８、１１２０、および、１１１６にそれぞれ結合される。各サーバ１１１０におけるファームウェアは、サーバ１１００Ａを介し、ＫＶＭ信号をキーボード１１２６、ビデオディスプレイ１１２８、および、マウス１１３０に送るローカルグローバル資源マップ１１３２をホストするためのサポートを提供する。
【００８２】
サーバ１１００Ｎで動作するオペレーティングシステムは、通常、実行時アプリケーションへのユーザ入力に応答し、ビデオディスプレイをアップデートする要求を受信する。オペレーティングシステムは、そのＯＳビデオドライバ１２００Ｎを用いて変更を実現する。ＯＳビデオドライバは通常、オペレーティングシステムにより維持される仮想ビデオディスプレイに基づき、ビデオデータを生成し、仮想−物理ディスプレイマッピングが実行される。例えば、異なる解像度を有するモニタに表示される同じテキスト／グラフィックコンテンツには、解像度に特有の異なるビデオデータが必要である。そして、ＯＳビデオドライバがビデオルータドライバ１２０２Ｎとインターフェースすることにより、ビデオデータは、宛先デバイスであると思われる、サーバ１１００Ｎのビデオシップ１２０６Ｎに送られる。オペレーティングシステムに関する限り、ビデオルータドライバ１２０２Ｎは、サーバのファームウェアビデオデバイスドライバ、すなわち、ビデオデバイスドライバ１２０４Ｎである。しかしながら、ビデオデータの受信と同時に、ビデオルータドライバ１２０２Ｎは、グローバル資源マップ１１３４Ｎのルックアップにより、ビデオデータ宛先サーバを探索し、かつ、ＯＯＢ通信ハンドラ６０４Ｎおよび６０４Ａを介し、サーバ１１００ＡとのＯＯＢ通信を会しするよう、ＳＭＩをアサートする。
【００８３】
受信と同時に、ビデオデータは、ビデオデバイスドライバ１２０４Ａを介し、ビデオチップ１２０６Ａに書き込まれる。前述と同じ方法で、ビデオデータは、ＯＯＢ通信ハンドラ６０４Ａからビデオデバイスドライバ１２０４Ａに直接渡されるか、または、ビデオルータドライバ１２０２Ａを介し送られてもよい。ビデオデータの受信に応答し、ビデオチップ１２０６Ａは、ビデオポート１１２０を介しビデオモニタ１１２８により受信されるそのビデオ出力信号をアップデートする。オプションとして、グローバル資源マップ１１３４Ａの検証ルックアップを実行することにより、サーバ１１００Ａが正しいビデオデータ宛先サーバであることを検証してもよい。
【００８４】
キーボードおよびマウス信号は、同様な方法で処理される。ビデオと同様に、オペレーティングシステムは、通常、ポインティングデバイスの仮想位置が仮想ビデオディスプレイと相互参照されることができる仮想ポインタマップを維持し、これによって、ビデオディスプレイに関するカーソルの位置を決定することができる。また、マウス情報は、ビデオ信号の逆ルートを横断する。これは、サーバ１１００Ａを介し受信されたマウス入力がＯＯＢチャネルを介し、選択されたプラットフォーム（例えばサーバ１１００Ｎ）に伝えられるということであり、サーバ１１００Ａのグローバル資源マップ１１３４Ａをアップデートすることにより、正しい宛先プラットフォームを反映することが要求される。同様に、ルーティングキーボード信号も、マップのアップデートを要求する。キーボード信号との違いは、それらが双方向性であることであり、したがって、入出力両方のデータルート変更が要求される。
【００８５】
図１３に、キーボード入力信号処理プロトコルスタックおよびフローチャートの例を示す。ソフトウェア側のサーバ１１００Ｎのプロトコルスタックは、オペレーティングシステムキーボードドライバ１３００Ｎを含み、一方、ファームウェア構成要素は、キーボードルータドライバ１３０２Ｎ、ビデオデバイスドライバ１３０４Ｎ、および、ＯＯＢ通信ハンドラ６０４Ｎを含む。また、ファームウェア構成要素は、サーバ１１００Ａのプロトコルスタックも含む。
【００８６】
キーボード１１２６を介したユーザ入力に応答し、キーボード入力信号が生成され、キーボードポート１１１８Ａを介し、キーボードチップ１３０６Ａにより受信される。その後、キーボードチップ１３０６は、キーボードデバイスドライバ１３０４Ａにより受信される対応するキーボード（ＫＢ）データを生成する。この時点で、キーボード入力の処理は、資源共有に携わらない単一のプラットフォーム（例えばディスクトップコンピュータ）で実行されるのと同一である。通常、キーボードデバイスドライバ１３０４ＡがＯＳキーボードドライバ１３００Ａとインターフェースすることにより、キーボードデータをオペレーティングシステムに伝える。しかしながら、キーボードデータを受信するべく対象とされたＯＳキーボードドライバは、サーバ１１００Ｎで稼動している。したがって、キーボードデバイスドライバ１３０４により処理されるビデオデータがキーボードルータドライバ１３０２Ａに伝えられることにより、キーボードデータのルート変更が容易になる。
【００８７】
キーボードデータの受信に応答し、キーボードルータドライバは、グローバル資源マップ１１３４を問合せ、キーボードデータのルート変更先であるターゲットサーバを決定する。（本例ではサーバ１１００Ｎ）。そして、キーボードルータドライバは、ＳＭＩをアサートし、サーバ１１００Ａで動作するプロセッサをＳＭＭにし、キーボードデータをサーバターゲット識別データと共にＯＯＢ通信ハンドラ６０４Ａに伝える。そして、ＯＯＢ通信ハンドラ６０４ＡがＯＯＢ通信ハンドラ６０４Ｎとやり取りすることにより、ＯＯＢチャネル１１２４を介しての２つのサーバ間のＯＯＢ通信が容易になり、次にキーボードデータがＯＯＢ通信ハンドラ６０４Ｎにより受信されるようになる。キーボードデータの受信に応答し、ＯＯＢハンドラ６０４Ｎは、受信したキーボードデータをキーボードルータドライバ１３０２Ｎに転送する。この時、キーボードルータドライバは、キーボードデータを直接ＯＳキーボードドライバ１３００Ｎに渡してもよいし、あるいは、データをＯＳキーボードドライバ１３００Ｎに渡す前に、グローバル資源マップ１１３４Ｎのルーティング検証ルックアップを実行することにより、サーバ１１００Ｎがキーボードデータを受信するべき正しいサーバであることを保証するようにしてもよい。そして、ＯＳキーボードドライバは、キーボードデータを処理し、処理済のデータを、カレントフォーカスを有する実行時アプリケーションに提供する。
【００８８】
以上説明した本発明の実施例は、要約書に記載された事項を含むが、それに限定されない。上述した例示的な実施例は、当業者であれば本発明の範囲および原理を逸脱することなく様々に修正および変更できることが理解できよう。
【００８９】
前述の詳細な説明を考慮し、本発明は様々に修正できる。特許請求の範囲に用いられる用語は、本発明を明細書に記載された特定の実施例および特許請求の範囲に限定するものと解釈すべきではない。本発明の範囲は、特許請求の範囲の請求項に記載した全ての範囲内によって決定されるべきである。
【図面の簡単な説明】
【００９０】
【図１Ａ】複数のサーバブレードが設置されるブレードサーバシャーシの例を示す正面等角図である。
【図１Ｂ】図１Ａのブレードサーバシャーシの後部等角図である。
【図１Ｃ】図１Ａおよび図１Ｂに対応する複数のラックマウントブレードサーバシャーシが設置されるブレードサーバラックの正面等角図である。
【図２】典型的なサーバブレードの構成要素の詳細を示す図である。
【図３】ＡＣＰＩ標準に従うパワーマネジメントを展開するために用いられるさまざまなファームウェアおよびオペレーティングシステムを示す概略ブロック図である。
【図４】本発明の一実施例に従うパワーマネジメントスキームを実行するためのブレードを設定するブレード初期化の間に用いられるオペレーションおよびロジックを示すフローチャートである。
【図５】本発明の一実施例に従う資源共有をセットアップする初期化プロセスの間に用いられるオペレーションおよびロジックを示すフローチャートである。
【図６】図６の初期化プロセスの間に発生する様々なデータフローを示す概略図である。
【図７】本発明の一実施例に従う要求にサービスを提供するコンピューティングプラットフォームの要求時に受信される資源アクセス要求に応答して用いられるオペレーションおよびロジックを示すフローチャートである（サービスを提供する資源は、他のコンピューティングプラットフォームによりホストされる）。
【図８Ａ】ローカルグローバル資源マップを用いての、共有資源アクセスにおける対のコンピューティングプラットフォーム間のデータフローを示す概略図である。
【図８Ｂ】グローバル資源マネージャによりホストされる単一のグローバル資源マップを用いての、共有資源アクセスにおける対のコンピューティングプラットフォーム間のデータフローを示す概略図である。
【図９Ａ】複数のディスクドライブの記憶容量となる仮想記憶ボリュームとして構成される共有記憶資源を示す概略図である。
【図９Ｂ】図９Ａの共有記憶資源スキームとの相違を示す概略図である（ＲＡＩＤ−１は資源アクセスの間に実行される）。
【図１０Ａ】図９Ａの仮想記憶ボリュームスキームの更なる詳細を示す概略図である。
【図１０Ｂ】図９ＢのＲＡＩＤ−１実行の更なる詳細を示す概略図である。
【図１１】本発明の一実施例に従う共有キーボード、ビデオ、および、マウス（ＫＶＭ）アクセススキームを示す概略図である。
【図１２】ビデオ資源の共有をサポートする対のコンピューティングプラットフォーム間のデータフローを示す概略図である。
【図１３】ユーザ入力資源の共有をサポートする対のコンピューティングプラットフォーム間のデータフローを示す概略図である。
【技術分野】
【０００１】
本発明は、ブレードサーバなどのクラスタ化コンピューティング環境、より詳しくは、これに限定しないが、ノード全体で共有できるグローバル資源を生成すべく、個別のプラットフォーム（ノード）によりホストされる資源を共有する技術に関する。
【背景技術】
【０００２】
情報技術（ＩＴ）管理者および情報統括責任者は、能力を低下させることなく資本経費および営業費を削減しなければならないという強いプレッシャーにさらされており、ＩＴ管理は、より効果的にインフラ資源を利用する計算資源を提供する必要に迫られている。この目的を満たすべく、サーバの利用をいかに効率的に管理するか、いかに少ないスタッフでＩＴ業務をこなすか、床面積をいかに効率的に利用するか、また、電力問題をどう取り扱うかといった課題が日々取り上げられている。
【０００３】
一般的に、企業のＩＴ（情報技術）インフラは、コンピュータサーバに集中し、サーバは、さまざまなタイプのネットワーク、例えば、プライベートローカルエリアネットワーク（ＬＡＮ）、および、公私のワイドエリアネットワーク（ＷＡＮ）を介し互いに接続されている。サーバは、さまざまなアプリケーションを分散させ、かつ、データ記憶および処理プロセスを管理する目的で使用される。このようなサーバは、通常、スタンドアロンサーバ、および／または、４Ｕ、２Ｕ、および、１Ｕなどの高密度ラックマウントサーバを含む。
【０００４】
近年、過去にないサーバ密度および経済スケーラビリティを提供する新規のサーバ構成が導入されている。このサーバ構成は、「ブレードサーバ」として知られている。ブレードサーバは、共通のシャーシ内に配置された複数の密接した「サーバブレード」（ブレード）を用いることにより、高密度なコンピュータ機能を供給する。各ブレードは、１つ、または、それ以上のプロセッサ、メモリ、ネットワーク接続、および、ディスク記憶装置を含む完全なコンピューティングプラットフォームを単一のシステムボードに一体化して提供する。一方、電源およびファンなどの他の構成要素は、所定のシャーシおよび／またはラック内のブレード間で共有される。これによって、従来のラックマウントサーバに比べ、資本設備費用の大幅な削減が可能になる。
【０００５】
一般的に、ブレードサーバは、２つの市場をターゲットにしている。一方は、個別のブレードが個別のタスクを処理する高密度サーバ環境、他方は、スケーラブルコンピュータクラスタ環境である。スケーラブルコンピュータクラスタ（ＳＣＣ）は、２つまたはそれ以上のコンピュータシステム群であり、コンピュータインテンシブなタスクを実行するべく協働するよう構成されたコンピューティングノードとしても知られている。コンピュータのタスクを実行するべく協働する多数のノードを構成することにより、単一のシステムで実行した場合よりタスクを素早く計算できる。理論上は、タスクに適用されるノードが多いほど、タスクの計算は速くなる。しかし実際には、タスクを完了するために活用できるノード数は、使用するアプリケーションに依存する。
【０００６】
一般的なＳＣＣは、Ｌｉｎｕｘオペレーティングシステムおよびクラスタインフラソフトウェアを稼動させるインテルのサーバを用いて構築される。前記サーバは、市販（ＣＯＴＳ）サーバとも言われ、ネットワークを介し接続されることにより、クラスタを形成する。１つのＳＣＣは、通常、コンピュータインテンシブなタスクの実行時に有効な１０から１００のサーバがどこかに必要である。ブレードサーバなら、このような多数のサーバを1つの場所に集めてクラスタを形成するという要求に完璧に応えることができる。ブレードサーバのシャーシ設計およびアーキテクチャは、非常に大きなコンピュータの馬力を単一の場所に提供することができる。さらに、ブレードサーバアーキテクチャのビルトインネットワーキングおよびスイッチング能力は、ブレードを個別に追加または除去することができ、所定のタスクの最適なスケーリングを実現する。このような柔軟性をもったサーバベースのＳＣＣを用い、スーパーコンピュータのようなコンピュータタスクを実行する他のインフラの費用効果的な変形例を提供できる。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
上述のように、ブレードサーバにおける各サーバは、フルプラットフォーム機能を実現し、その結果、サーバにおいて、ブレードが個別に動作できるようになる。しかしながら、各ブレードにとって利用可能な資源は、そのブレードがもつ資源に限られるため、多くの場合、資源は効率的に利用されない。現状のアーキテクチャでは、サーバと広範囲にわたる資源とを効率的に共有できるスキームは確立されていない。
【課題を解決するための手段】
【０００８】
前述した側面および本発明の多くの効果は、添付の図面を参照しながら以下の詳細を読むことにより容易に理解されることであろう。なお、特に明記しない限り、全図面を通じて同様の要素には同様の参照符号を付して示す。
【０００９】
以下、ブレードサーバ環境のような、クラスタ化プラットフォーム環境全体で資源を共有化するための方法およびコンピュータ構成要素の実施例を説明する。以下の説明において、本発明の実施例を完全に理解することを目的として数多くの具体的な詳細が記載されている。しかしながら、１つまたはそれ以上の具体的な詳細の説明がなくとも、または、他の方法、構成要素、材料によっても本発明が実行可能であることは、当業者にとって明らかである。また、本発明の態様を不明確にしないよう、公知の構造、材料、または、オペレーションの詳細な説明は省略する。
【００１０】
本明細書を通じて使用される「一実施例」という語句は、特定の機能、構造、または、実施例と関連して記述される特徴が、本発明の少なくとも1つの実施例に含まれることを意味する。したがって、本発明を通じて随所に使用される「一実施例」という語句は、必ずしも同じ実施例を指すものではない。さらに、特定の機能、構造、または、特徴は、1つまたはそれ以上の実施例において適切な形で組み合わされてよい。
【発明の効果】
【００１１】
本発明の態様によれば、個別のプラットフォームによりホストされる資源が他のプラットフォームからもアクセス可能になる、クラスタ化プラットフォーム環境全体で資源を共有化する技術が開示される。この技術は、ＯＳとの連動を必要とせずに「ビハインドザシーン」アクセスメカニズムを提供するファームウェアベースの機能を用いる。実際には、資源共有およびアクセス操作は、ブレード上で動作するオペレーティングシステムに対し完全にトランスペアレントであり、オペレーティングシステムは、独立している。したがって、本願明細書において開示される新規な技術によってもたらされる機能は、既存および将来の分散型プラットフォーム環境で使用でき、使用に当たり、オペレーティングシステムをその環境向けに変更する必要がない。
【００１２】
一態様によれば、資源共有メカニズムは、グローバル資源を形成するよう集結された資源を公開しているいくつかのプラットフォームにより実現できる。各プラットフォームは、オペレーティングシステムのロード（プレブート）前、および、オペレーティングシステムの実行と同時に稼動する一組のファームウェアをそれぞれ用いる。一実施例において、実行時の配備は、システムマネジメントモード（ＳＭＭ）として知られる非表示実行モードによって容易になる。前記システムマネジメントモード（ＳＭＭ）は、周期的なシステムマネジメントインターラプト（ＳＭＩ）を受信しかつそれに応答する能力を有するので、資源共有を実現し、かつ、メカニズムを実行するよう設定されたファームウェアＳＭＭコードにアクセス情報をトラスペアレントに伝えることができるようになる。ＳＭＭ資源マネジメントコードは、情報およびメッセージを、他のノードに、アウトオブバンドネットワーク（ＯＯＢ）、または、通信チャネルを介し、オペレーションシステムに対しトランスペアレントに伝える。
【発明を実施するための最良の形態】
【００１３】
説明の便宜上、本発明のいくつかの実施例は、ブレードサーバ環境として以下に説明される。概要としては、本発明の実施例に従う資源共有スキームが通常実行できる典型的なブレードサーバ構成要素およびシステムが図１Ａ−Ｃおよび２に示される。典型的な構成の下では、複数のブレード１０２に電力および通信機能を提供する目的で、ラックマウントシャーシ１００が用いられる。各ブレード１０２は、それぞれ対応するスロットを占有する（すべてのスロットがシャーシで占有される必要はない点に注意）。または、１つまたはそれ以上のシャーシ１００が図１Ｃに示されるブレードサーバラック１０３内に設置されてもよい。各ブレードは、１つまたはそれ以上のマッチング・コネクタを介し設置されると同時に、インターフェース平面１０４（すなわちバックプレーンまたはミッドプレーン）に結合される。一般的に、インターフェース平面は、ブレードそれぞれのための複数のマッチングコネクタを含み、電力および通信信号をブレードに供給することもできる。現実行下では、多数のインターフェース平面が「ホットスワッピング」機能、すなわち、シャーシ全体の電源を入れたままで、データ信号をバッファリングすることもなく、ブレードを即座に追加または除去する（ホットスワッピングする）ことができる機能を提供する。
【００１４】
図１Ａおよび１Ｂは、典型的なミッドプレーンインターフェース平面構成を示す。インターフェース平面１０４の後部は、１つまたはそれ以上の電源１０６に接続される。多くの場合、電源は冗長化およびホットスワッピングが可能である。適切な電源プレーンおよびコンディショニング回路に結合されることにより、１つの電源が故障しても継続して動作することができる。任意の構成において、電源アレイを用いてブレードラック全体に電力を供給してもよく、この場合、電源とシャーシとが一対一の関係になくてもよい。また、複数の冷却ファン１０８を用いてシャーシを介し空気を引き込み、サーバブレードを冷却する。
【００１５】
ブレードサーバすべてに要求される重要な特徴として、他のＩＴインフラとも外部通信する能力が挙げられる。一般的に、外部通信は、１つまたはそれ以上のネットワーク接続カード１１０を介して行われ、ネットワーク接続カードは、それぞれインターフェース平面１０４に接続される。また、１つのネットワーク接続カードは、複数のネットワークポート接続（例えば、ＲＪ−４５ポート）を含む１つの物理的インターフェースを有するか、または、ネットワークスイッチ、ハブ、または、ルータなどのネットワーク装置に直接接続されるよう設計された高密度コネクタを備えてもよい。
【００１６】
ブレードサーバは、通常、ブレードの動作を個別に管理する何らかの管理インターフェースを提供する。これは、帯域外ネットワークまたは通信チャネルによって実現が容易になる。例えば、「プライベート」または「マネジメント」ネットワーク、および、適切なスイッチングを容易に実現するための１つまたはそれ以上のバスをインターフェース平面に組み込んでもよく、あるいは、プライベートネットワークは、強連結ネットワークケーブル配線、および、ネットワークを介し実行することもできる。前記スイッチングおよび他の、マネジメント機能は、任意でマネジメントカード１１２によって提供されてもよく、マネジメントカード１１２は、インターフェース平面の裏側または表側に結合される。さらに、また、マネジメントサーバを用いてブレード動作を管理してもよく、この場合、通信は、イーサネットなどの標準的なコンピュータネットワーク化インフラを介し処理される。
【００１７】
図２を参照し、例示的なブレード２００をさらに詳しく説明する。上述したように、各ブレードは、サーバタイプの機能を実行するよう構成された独立したコンピューティングプラットフォーム、すなわち、「カードのサーバ」を備える。したがって、各ブレードは、適切な集積回路（ＩＣ）を結合するための内部配線（すなわちバス）を提供する主回路基板２０１を含む従来のサーバに共通する構成要素と、主回路基板に取り付けられた他の構成要素とを含む。これらの構成要素は、システムメモリ２０４（ＤＤＲ ＲＡＭなど）、キャッシュメモリ２０６（ＳＤＲＡＭなど）、および、ファームウェア記憶装置２０８（フラッシュメモリなど）に結合された１つ、または、それ以上のプロセッサ２０２を含む。従来のネットワーク通信機能、例えば、ブレードと外部ネットワークインフラとの間の通信をサポートするための「公衆」ＮＩＣ（ネットワークインターフェース）チップ２１０が設けられる。例示された他の構成要素は、ステータスＬＥＤ２１２、ＲＪ−４５コンソールポート２１４、および、インターフェース平面コネクタ２１６を含む。付加的な構成要素は、さまざまな受動構成要素（抵抗器、コンデンサなど）、電力調整部品、および、周辺装置コネクタを含む。
【００１８】
通常、各ブレード２００は、オンボード記憶装置を提供することもでき、これは、１つまたはそれ以上のビルトイン・ディスクコントローラ、および、１つまたはそれ以上のディスクドライブ２１８が結合される対応するコネクタを介し実現が容易になる。例えば、典型的なディスクコントローラは、Ｕｌｔｒａ ＡＴＡコントローラ、および、ＳＣＳＩコントローラなどを含む。また、大量のデータを格納するためにネットワーク接続ストレージ（ＮＡＳ）機器が用いられるときは、ディスクドライブは、ブレードとは別に、同じまたは個別のケースのようなラックに収容されてもよい。
【００１９】
本発明の態様によれば、ブレードと、任意の専用管理コンポーネントとの間のバンド外通信のための機能が提供される。ここで使用されるように、バンド外通信チャネルは、ＯＳに対しトランスペアレントなデバイス間通信をサポートする通信手段であってオペレーティングシステムと協働せずにブレード間通信を可能にする手段を含む。通常、さまざまなアプローチによりＯＯＢチャネルを提供することができる。これらのアプローチは、ＳＭＢＵＳ標準（ｗｗｗ．ｓｍｂｕｓ．ｏｒｇ）を実行するシステムマネジメントバス、ＶＬＡＮ−８０２．１Ｑなどの専用プライベートまたはマネジメントネットワーク、あるいは、例えばＲＳ−４８５シリアル通信標準を用いるシリアル通信スキームなどの使用を含むが、これに限定されない。また、このような通信機能をサポートする１つまたはそれ以上の適切なＩＣがＯＯＢチャネルチップ２２０で示されるように、主回路基板２０１に取り付けられる。同時に、インターフェース平面１０４は、選択されたＯＯＢスキームを支持するための対応するバスまたはビルトインネットワークトレースを含んでもよい。また、有線ネットワークスキーム（イーサネットなど）の場合、適切なネットワークケーブル配線およびネットワーキングデバイスをシャーシ１００の内部または外部に配置させてもよい。
【００２０】
前述のように、本発明の実施例では、ブレードサーバノード全体で資源を共有化できるようにする資源共有セットアップおよびアクセス機構を実現するためのファームウェアベースのスキームを用いる。特に、資源管理ファームウェアコードが各ブレードの初期化の間にロードされ、ＯＳ実行中のアクセスを可能にする。同様に、初期化の間に資源情報が収集され、グローバル資源情報が確立される。このグローバル資源情報に基づき、各ブレードへの適切なグローバル資源アクセスが提供される。この情報は、グローバル資源が（オペレーションシステムの立場からは）ローカル資源として見えるよう、その初期化と同時にＯＳに伝えられる。ＯＳの実行中、共有資源へのアクセスは、ＯＳおよび／またはＯＳドライバと、資源アクセスマネジメントと協働する対応するファームウェアとの間のやりとりを介し処理され、このやりとりは、ＯＯＢチャネルを介し実現が容易になる。
【００２１】
一実施例において、資源共有は、拡張ファームウェアインターフェース（ＥＦＩ）（仕様およびその例は、ｈｔｔｐ：／／ｄｅｖｅｌｏｐｅｒ．ｉｎｔｅｌ．ｃｏｍ／ｔｅｃｈｎｏｌｏｇｙ／ｅｆｉを参照）として知られる拡張ファームウェアフレームワークにより実現が容易になる。ＥＦＩは、プラットフォームファームウェアと、シュリンクラップオペレーションシステム、または、他のカスタムアプリケーション環境との間の抽象的なプログラマチックインターフェースを記述する公の産業仕様（現在のバージョン１．１０は２００３年１月７日リリース）である。ＥＦＩフレームワークにより、プラットフォームのＢＩＯＳデバイス（フラッシュメモリなど）に格納されたＢＩＯＳコードにより提供されるもの以上にＢＩＯＳ機能を拡張できる。より詳しくは、ＥＦＩによって、主および二次フラッシュデバイス、オプションのＲＯＭ、多種の持続性記憶装置（ハードディスク、ＣＤ ＲＯＭなど）を含むさまざまな資源から、ファームウェアがファームウェアモジュールおよびドライバ形式で、コンピュータネットワーク上でもロードできるようになる。
【００２２】
図３は、コールドブート（パワーオフ／オン、リセット）に応答してフレームワーク下のプラットフォームにより実行されるオペレーションを示すよう用いられるイベントシーケンス／アーキテクチャダイアグラムを示す。プロセスは、プレＥＦＩ初期化環境（ＰＥＩ）位相、ドライバ実行環境（ＤＸＥ）位相、ブートデバイス選択（ＢＤＳ)位相、過渡システムロード（ＴＳＬ）位相、および、オペレーティングシステム実行時（ＲＴ）位相を含むいくつかの位相に論理的に分割される。位相は、積層され、ＯＳおよびプラットフォームのための適切な実行時環境を提供する。
【００２３】
ＰＥＩ位相は、プロセッサ（ＣＰＵ）、チップセット、および、マザーボードの特定の初期設定ルーチンをロードしかつ起動させる標準化された方法を提供する。ＰＥＩ位相は、位相を連続させるための安定した基盤を提供するのに十分なシステムを初期化する役割を担う。ＣＰＵ、チップセット、および、メインボード（すなわち、マザーボード）を含むプラットフォームのコア構成要素の初期化は、ＰＥＩ位相の間に実行される。この位相は、「初期の初期化」とも呼ばれる位相である。この位相の間に実行される典型的なオペレーションは、ＰＯＳＴ（パワーオンセルフテスト）オペレーションと、プラットフォーム資源の発見を含む。特に、ＰＥＩ位相では、メモリを見つけ、ＤＸＥ位相に伝えられる資源マップを準備する。ＰＥＩ位相の終端におけるシステムの状態は、ハンドオフブロック（ＨＯＢ）と呼ばれる場所に依存しないデータ構造のリストによりＤＸＥ位相に伝えられる。
【００２４】
ＤＸＥ位相は、システムの大半が初期化される位相である。ＤＸＥ位相は、ＤＸＥコア３００、ＤＸＥディスパッチャ３０２、および、一組のＤＥＸドライバ３０４を含むいくつかの構成要素によって実現が容易になる。ＤＸＥコア３００は、一組のブートサービス３０６、実行時サービス３０８、および、ＤＸＥサービス３１０を生成する。ＤＸＥディスパッチャ３０２は、ＤＸＥドライバ３０４を発見し、かつ、正しい順序で実行する役割を担う。ＤＸＥドライバ３０４は、コンソールおよびブートデバイスに対しソフトウェアを抽象化すると共に、プロセッサ、チップセット、および、プラットフォーム構成要素を初期化する役割を担う。これらの構成要素は、プラットフォームを初期化し、かつ、オペレーティングシステムをブートするために必要なサービスを提供するべく協働する。また、ＤＸＥと、ブートデバイス選択位相とが協働し、コンソールを確立し、かつ、オペレーティングシステムのブートを試みる。オペレーティングシステムがそのブートプロセスの開始（すなわちＢＤＳ位相の開始）に成功すると、ＤＸＥ位相は終了する。ＤＸＥコアによって提供された実行時サービス、および、選択ＤＸＥサービス、および、実行時ＤＸＥドライバによって提供された選択サービスだけがＯＳ実行時環境に存続することを許容される。ＤＸＥの結果は、完全に形成されたＥＦＩインターフェースを表す。
【００２５】
ＤＸＥコードは、ＣＰＵ、チップセット、または、プラットフォームに依存しない、完全な携帯型に設計される。これは、いくつかの機能で設計することにより、達成される。第１に、その初期状態では、ＤＸＥコアだけがＨＯＢリストに依存する。つまり、ＤＸＥコアは、前の位相からのどのサービスにも依存しないので、前の位相すべてをいったんアンロードして、ＨＯＢリストをＤＸＥコアに渡すことができる。第２に、ＤＸＥコアは、いかなるハードコード化アドレスも含まない。さらに、ＤＸＥコアは、物理的メモリ内のどこにでもロードすることができ、物理メモリまたはファームウェアセグメントがプロフェッサの物理アドレス空間内のどこに位置しようと、正しく機能することができる。第３に、ＤＸＥコアは、ＣＰＵ特定、チップセット特定、または、プラットフォーム特定情報のいずれも含まない。その代わりに、ＤＸＥコアは、一組のアーキテクチャのプロトコルインターフェースを介し、システムハードウェアから抽出される。これらアーキテクチャのプロトコルインターフェースは、ＤＸＥディスパッチャ３０２により起動されるＤＸＥドライバ３０４により生成される。
【００２６】
ＤＸＥコアは、図４に示すような、ＥＦＩシステムテーブル４００と、それに付随するブートサービス３０６および実行時サービス３０８のセットとを生成する。また、ＤＸＥコアは、ハンドルデータベース４０２を維持する。ハンドルデータベースは、１つ、または、それ以上のハンドルのリストを含み、ハンドルは、それぞれのプロトコル４０４にマップする１つ、または、それ以上の一意的なプロトコルＧＵＩＤ（グローバル一意識別子）
【００２７】
のリストである。プロトコルは、一組のサービスのためのソフトウェア抽象化である。いくつかのプロトコルは、入出力デバイスを抽象し、他のプロトコルは、共通の一組のシステムサービスを抽象する。プロトコルは、通常、一組のＡＰｌと、いくつかのデータフィールドを含む。プロトコルごとにＧＵＩＤによって名前がつけられ、ＤＸＥコアは、プロトコルがハンドルデータベース内に登録されることができるようにするサービスを生成する。ＤＸＥディスパッチャがＤＸＥドライバを実行すると、プラットフォームの具体的な詳細からＤＸＥコアを抽出するために使用されるアーキテクチャのプロトコルを含むハンドルデータベースにさらなるプロトコルが追加されてもよい。
【００２８】
ブートサービスは、ＤＸＥおよびＢＤＳ位相の間に使用される一組のサービスを含む。これらのサービスは、特に、メモリサービス、プロトコルハンドラサービス、および、ドライバサポートサービスを含む。メモリサービスは、バイト境界でメモリページおよびメモリプールを割り当て／解除するためのサービスを提供する。また、メモリサービスは、プラットフォームにおける現在の物理メモリの使用すべてのマップを検索するためのサービスを提供する。プロトコルハンドラサービスは、ハンドルデータベースに／からハンドルを追加／除去するためのサービスを提供する。また、プロトコルハンドラサービスは、ハンドルデータベースのハンドルに／からプロトコルを追加／除去するためのサービスを提供する。追加サービスは、あらゆる構成要素がハンドルデータベース内でハンドルを探すことができ、かつ、ハンドルデータベース内でプロトコルの開始および終了ができるようにするサービスである。サポートサービスは、プラットフォーム内でドライバとデバイスとを接続および切断するサービスを提供する。これらのサービスは、ＢＤＳ位相で用いられることにより、すべてのドライバがすべてのデバイスに接続されるか、または、最小数のドライバだけが、コンソールを確立しかつオペレーティングシステムをブートするため（すなわちすばやいブート機構をサポートするため）に必要とされるデバイスに接続される。
【００２９】
ブートサービスとは対照的に、実行時サービスは、プレブートとＯＳ実行時動作の間のどちらでも利用できる。本願明細書において開示される実施例により導入される１つの実行時サービスは、変数サービスである。以下に詳細に説明するように、変数サービスは、揮発性および不揮発性記憶装置から環境変数を探索し、追加し、かつ、除去するためのサービスを提供する。
【００３０】
ＤＸＥサービステーブルは、プレブートの間だけ利用可能な第１のＤＸＥサービス４０６Ａセットと、プレブート間およびＯＳ実行時間の両方で利用可能な第２のＤＸＥサービスセットとに対応するデータを含む。プレブートだけのサービスは、プラットフォーム内のＩ／Ｏ資源、メモリマップされたＩ／Ｏ資源、および、システムメモリ資源を管理するためのサービスを提供するグローバルコヒーレンスドメインサービスを含む。また、プレブートだけのサービスは、ＤＸＥディスパッチャによりディスパッチされるＤＸＥドライバを管理するためのサービスを提供するＤＸＥサービスも含む。
【００３１】
ブートサービス３０６、実行時サービス３０８、および、ＤＸＥサービス３１０のそれぞれにより提供されるサービスは、ＡＰＩ３１２、３１４、および、３１６の各セットを介しアクセスされる。ＡＰＩは、連続的にロードされる構成要素がＤＸＥコアにより提供される選択されたサービスを導入できるようにする抽象インターフェースを提供する。
【００３２】
ＤＸＥコア３００が初期化された後、制御は、ＤＸＥディスパッチャ３０２へと移る。ＤＸＥディスパッチャは、ＥＦＩフレームワーク下でファームウェアがそこからロードされる論理記憶装置に対応するファームウェア容量内で見つけられるＤＸＥドライバをロードしかつ起動する役割を担う。ＤＸＥディスパッチャは、ＨＯＢリストによって記述されたフレームウェア容量におけるドライバを探索する。実行を続けているうちに、他のファームウェア容量も見つかる可能性がある。そのときは、ディスパッチャは、そこで同様にドライバを探す。
【００３３】
ここにＤＸＥドライバの２つのサブクラスがある。第１のサブクラスは、ＤＸＥ位相内でごく初期に実行するＤＸＥドライバを含む。これらＤＸＥドライバの実行順序は、アプリオリファイルの存在および内容と、依存関係の表示の評価とに基づく。これら初期のＤＸＥドライバは、通常、プロセッサ、チップセット、および、プラットフォーム初期化コードを含むこともある。また、これら初期のドライバは、ブートサービスおよび実行時サービス完全なものとするようＤＸＥコアに要求されるアーキテクチャのプロトコルを生成することもある。
【００３４】
ＤＸＥドライバの第２のクラスは、ＥＦＩ１．１０ドライバモデルに準拠するものである。これらは、ＤＸＥディスパッチャにより実行されるときは、ハードウェアの初期化を実行しない。その代わり、ハンドルデータベース内にドライババインディングプロトコルインターフェースを登録する。ドライババインディングプロトコルのセットは、コンソールを確立し、かつ、ブートデバイスへのアクセスを提供するよう要求されるデバイスにドライバを接続すべくＢＤＳ位相で使用される。ＥＦＩ１．１０ドライバモデルに準拠するＤＸＥドライバは、コンソールデバイスおよびブートデバイスのソフトウェア抽象化を明確に依頼された場合、最終的にはそれを提供する。
【００３５】
ＤＸＥドライバのどれでもブートサービスおよび実行時サービスを使ってそれらの機能を実行することができる。しかしながら、初期のＤＸＥドライバは、アーキテクチャのプロトコルすべての登録がすんでいるわけではないので、それらを実行してもすべてのサービスが利用できるわけではないことを知っておく必要がある。ＤＸＥドライバは、依存関係の表示を用い、実行前に必要とするサービスおよびプロトコルインターフェースが利用可能であることを保証しなければならない。
【００３６】
ＥＦＩ１．１０ドライバモデルに準拠するＤＸＥドライバには前記のような懸念は不要である。これらのドライバは、実行時に、ドライババインディングプロトコルをハンドルデータベースにただ登録すればよい。このオペレーションは、アーキテクチャのプロトコルを使用しなくても実行できる。ドライババインディングプロトコルの登録と関連し、ＤＸＥドライバは、インストールコンフィギュレーションテーブル関数を用い、ＡＰＩを「公開」してもよい。この公開されたドライバは、ＡＰＩ３１８で表される。ＥＦＩ下では、ＡＰＩの公開により、他のファームウェア構成要素によりアクセスするためのＡＰＩが公にされる。ＡＰＩは、ＤＸＥドライバがそれぞれの寿命の間に対応するデバイス、バス、または、サービスのためのインターフェースを提供する。
【００３７】
ＢＤＳアーキテクチャのプロトコルは、ＢＤＳ位相間で実行する。ＢＤＳアーキテクチャのプロトコルは、プレブートサービス環境で実行するさまざまなアプリケーションを見つけ、ロードする。このようなアプリケーションは、従来のＯＳブートローダ、または、最終的なＯＳをロードする前にあるいはそれに代わって動作する拡張サービスを表すこともある。このような拡張プレブートサービスは、セットアップ設定、拡張診断、フラッシュアップデートサポート、ＯＥＭ値追加、または、ＯＳブートコードを含んでもよい。ブートディスパッチャ３２０は、ブートターゲット、例えば、システムによりブートされるＯＳの選択を可能にするよう、ＢＤＳ位相間で用いられる。
【００３８】
ＴＳＬ位相間で、最終ＯＳブートローダ３２２は、選択されたＯＳをロードするよう実行される。ＯＳが一旦ロードされてしまえば、ブートサービス３０６、および、ＤＸＥサービス３０６ＡのようにＡＰＩ３１８を介しＤＸＥドライバに接続して設けられた多くのサービスは必要なくなる。したがって、ＯＳ実行時の間にアクセスできる数の減ったＡＰＩのセットは、図３のＡＰＩ３１６Ａおよび３１８Ａとして示される。
【００３９】
本発明の原理の下で、ＯＳにトランスペアレントなバンド外通信スキームが用いられることにより、さまざまなタイプの資源をサーバノード全体で共有することが可能になる。同時に、ファームウェアベースの構成要素（ファームウェアドライバおよびＡＰＩなど）が用いられることにより、資源への低レベルのアクセス、および、ＯＯＢチャネルにおけるデータのルート変更が容易になる。このスキームは、ブレード群、個別のシャーシ、ラック、または、ラック群を含む多数のコンピューティングプラットフォーム全体で実行されてもよい。システム初期化の間、各プラットフォームに設けられたファームウェアは、ＯＯＢチャネル、適切な資源へのアクセス、および、データルート変更機構をセットアップするよう、ロードされかつ実行される。その後、各ブレードは、その共有資源に関する情報を、ＯＯＢを介しグローバル資源マネージャに伝送する。グローバル資源マネージャは、データを集め、「仮想」グローバル資源を構成する。グローバル資源記述子形式のグローバル資源構成データがブレードに返送されることにより、ブレードにグローバル資源の構成およびアクセス機構を通知する。その後、ドライバが構成され、グローバル資源へのアクセスをサポート持する。続いて、グローバル資源記述子が、ＯＳロードの間にオペレーティングシステムに渡される。ここでは、仮想グローバル資源は、オペレーティングシステムにはローカルデバイスのように見え、ＯＳ実行時のオペレーションの間に、ＯＳコードへの修正を必要とせずにローカルデバイスとして用いられる。プロセスの一実施例に従うフローチャート動作およびロジックが図５および７に示されており、それに対応するさまざまな構成要素間の動作およびやりとりは、図６、８Ａ、および、８Ｂに示されている。
【００４０】
図５によると、プロセスは、資源デバイスドライバおよびＯＯＢ通信フレームワークをセットアップするべく、各ブレードでいくつかの初期化オペレーションを実行することにより開始する。開始ブロック５００で示すように、パワーオン、または、リセットに応答し、システムは、図３を参照して前述したように、プレブートシステム初期化オペレーションを実行する。まず、各ブレードのブートファームウェアデバイス（ＢＦＤ）に格納されたファームウェアをロードして実行することにより、ブロック５０２における初期の初期化オペレーションが実行される。ＥＦＩ下では、ＢＦＤは、システムをブートするためのファームウェアを格納するファームウェアデバイスを含む。例えば、サーバブレード２００のＢＦＤは、ファームウェアデバイス２０８を含む。
【００４１】
続いてブロック５０２では、プロセッサ２０２がリセットベクトルを介しＢＦＤのブートブロックのベースアドレスに実行をジャンプさせるリセットスタブコードを実行する。ブートブロックは、初期の初期化を実行するためのファームウェア命令を含み、かつ、プロセッサに２０２よって実行されることにより、ＣＰＵ、チップセット、および、マザーボードを初期化する。（ウォームブート（リセット）の間は、初期の初期化は実行されないか、または、限られた方式で実行されることに注意。）次に、ＤＸＥ位相を導く、ＥＦＩコアに対応するファームウェア命令が実行される。ＤＸＥコア初期化の間に、図３および４を参照して上述したように変数サービスがセットアップされる。ＤＸＥコアが初期化されると、ＤＸＥディスパッチャ３０２は、ＤＸＥドライバ３０４をロードし始める。各ＤＸＥドライバは、システム構成要素に対応し、その構成要素に直接アクセスするためのインターフェースを提供する。ＤＸＥドライバは、ＯＯＢ通信を容易にするよう続いて用いられるＯＯＢモニタドライバに含まれる。
【００４２】
次に、ブロック５０４で、ＯＯＢモニタドライバは、各ブレードの保護された領域にインストールされる。上述したように、オペレーティングシステムにより管理されるネットワーク通信と関わりなく動作するバンド外通信チャネルまたはネットワークが、ブレード間通信を容易にする目的でＯＳに対しトランスペアレントに用いられる。
【００４３】
前述のブロック５０２におけるシステム初期化オペレーションの間に、システムメモリ２０４の一部がシステムを管理する目的で用いられるよう、セットアップされる。メモリのこの部分は、ＳＭＲＡＭ６００と呼ばれ（図６参照）、続いてロードされるオペレーティングシステムからは見えないようになっている。
【００４４】
ファームウェアのロードと共に、ファームウェアに格納されたＳＭＭ ＯＯＢ通信コード６０２がＳＭＲＡＭ６００にロードされ、ＯＯＢ通信を処理するための対応するＯＯＢ通信ＳＭＭハンドラ６０４がセットアップされる。ＳＭＭハンドラは、一種の割込みハンドラであって、システム管理割込み（ＳＭＩ）に応答して起動する。次に、システムプロセッサのＳＭＩピンを介し、ＳＭＩ割込みがアサートされる。ＳＭＩ割込みに応答し、プロセッサは、その時のコンテキスト（すなわち、その時の実行モード、スタック、および、レジスタ情報などを含む現在のオペレーションに関する情報）を格納し、かつ、その実行モードをそのシステム管理モードに切り替える。その後ＳＭＭハンドラは、それらがＳＭＩイベントをサービスするのに適切なハンドラかどうかを決定するべく順次ディスパッチされる。この決定は、どのハンドラが適切であるかを決定するにあたりほとんど待ち時間がないように、ＳＭＭハンドラコードにおいて非常に早期になされる。ハンドラが識別されると、ＳＭＩイベントのサービスを終了させることができる。ＳＭＩイベントのサービスが終了すると、ＲＳＭ（再開）命令が発せられ、予め保存されたコンテキストデータを用い、プロセッサはそれ以前の実行モードに戻る。最終的な結果としては、ＳＭＭオペレーションは、完全にオペレーティングシステムに対し、トランスペアレントになる。
【００４５】
図５のフローチャートに戻り、ブレードによってホストされる１つまたはそれ以上の共有可能な資源が見つかるかどうかの決定が決定ブロック５０６でなされる。一般的に、共有資源は、共有アクセスを可能にするブレード構成要素またはデバイスである。このような構成要素およびデバイスは、固定記憶装置、可換型媒体装置、入力装置（キーボード、マウスなど）、ビデオデバイス、オーディオデバイス、揮発性メモリ（すなわちシステムＲＡＭ）、および、不揮発性メモリなどを含むが、これに限定されない。
【００４６】
決定ブロック５０６への返事がＹＥＳの場合、ロジックは、発見される共有可能な資源それぞれに対する開始および終了ループブロック５０８および５０９それぞれの範囲内で定義されるループ操作の実行に進む。これは、ブロック５１０における操作を含み、ここで、共有資源を記述するためのデバイス経路が形成され、構成パラメータが収集される。デバイス経路は、外部のユーザに、資源にアクセスするための手段を提供する。構成パラメータは、以下に詳細に説明するグローバル資源を構築するために使用される。
【００４７】
ブロック５１０のオペレーションが実行された後、図示された実施例において、デバイス経路および資源構成情報が、ブロック５１２におけるＯＯＢ通信チャネル６１０を介し、グローバル資源マネージャ６０８に伝送されるかまたは同報される。グルーバル資源マネージャは、通常、ブレードの１つ、または、マネジメントカード１１２などの既存の構成要素によりホストされることもできる。後述するように、一実施例において、複数のローカルグローバル資源マネージャが用いられる。ここでは、グローバル資源マネジメントは、単一のマネージャを用いるよりはむしろ、集合的なプロセスを通じて処理される。グローバル資源マネージャをホストする構成要素のアドレスが公知のアプリオリである場合、その構成要素への選択的な伝送が用いられる。アドレスが知られていない場合、まず、ＯＯＢチャネルを介しメッセージが同報され、ホスト構成要素の位置が識別される。
【００４８】
前述したようにＳＭＭが隠された実行モード下でのＯＯＢ通信は、以下の方法で実行される。まず、ブレード間通信が実行されるブレードにおけるオプロセッサのオペレーティングモードをＳＭＭに切り替える必要がある。したがって、図６のＢＬＡＤＥ１のように、プロセッサをＳＭＭに切り替える目的でＳＭＩが生成される。これは、２つの手段のうちの１つにより実行される。１つは、プロセッサＳＭＩピンのアサーション（すなわち、ハードウェアによる生成）、もう１つは、ＳＭＩ命令を発することによるもの（すなわち、ソフトウェアに基づく生成）である。
【００４９】
一実施例では、ＳＭＩピンのアサーションは、マネジメントバスなどに適切な信号を配置することにより生成できる。例えば、Ｉ２Ｃを用いてＳＭＢＵＳが配備されると、バスラインの１つは、各ブレードプロセッサのＳＭＩピンに、そのブレードコネクタを介し直結されてもよい。また、インターフェース平面が同様の結果を生じる個別の手段を提供するようにしてもよい。構成に基づき、すべてのＳＭＩピンが共通に、単一のバスラインに結合されてもよいし、あるいは、バスは、それぞれのブレードに対し個別のＳＭＩピンアサーションを可能にするよう構成されてもよい。さらに、インテル?製などの特定のネットワークインターフェースチップは、従来のネットワーク通信に使用される第１のＭＡＣアドレスに加え、「バックチャネル」として使用される第２のＭＡＣアドレスを提供する。さらにまた、これらＮＩＣは、ビルトインシステム管理機能を提供する。この機能により、第２のＭＡＣアドレスを参照する着信がＮＩＣによるＳＭＩ信号のアサートを可能にする。このスキームは、ＯＯＢチャネルが「公衆」ネットワーク（図示せず）として同じ配線上に配備されることを可能にする。
【００５０】
一実施例では、ＯＯＢチャネルにアクセスするためにファームウェアドライバが用いられる。例えば、ＯＯＢチャネルがネットワークまたは直列の手段を介し実行されるとき、ネットワークまたはシリアルポートにアクセスするための適切なファームウェアドライバが提供される。このファームウェアドライバの構成は予め公知であってもよいので（したがってオペレーティングシステムとは独立している）、ＳＭＭハンドラは、ファームウェアドライバを介し、ＯＯＢチャネルに直接アクセスできる。また、Ｉ２Ｃのような専用マネジメントバスの場合、対応するファームウェアドライバを用いずにＳＭＭハンドラへの直接アクセスが可能になるが、ファームウェアドライバを用いてもかまわない。
【００５１】
ＳＭＩピンのアサーションに応答し、アサートされたプロセッサは、ＳＭＭ実行モードに切り替わり、適切なハンドラ（例えば通信ハンドラ６０４）がディスパッチされるまで、ＯＯＢ通信を容易にするべくそのＳＭＭハンドラをディスパッチする。そして、ＯＯＢ通信ネットワーク／チャネルオプションのそれぞれにおいて、ブレードプロセッサがＳＭＭで動作中であるとき、ＯＯＢ通信が実行され、それによって、通信は、それらのブレードで動作するオペレーティングシステムに対しトランスペアレントになる。
【００５２】
ブロック５１４に従い、グローバル資源マネージャ６０８により共有デバイス経路および資源構成情報が受信され、同様に、他のブレードの共有デバイス経路および資源構成情報もグローバル資源マネージャにより受信される。
【００５３】
本発明の一態様によれば、個々の資源が結合されることにより、グローバル資源を形成してよい。例えば、個別の記憶装置（ハードディスクおよびシステムＲＡＭなど）により提供される記憶領域が集結し、１つまたはそれ以上の「仮想」記憶ボリュームを形成することもできる。これは、ブロック５１６における資源構成情報を結集させることにより一部実現できる。ハードディスク資源の場合、資源構成情報は、通常、デバイスのアサーションに使用される記憶ブロックの数、分割化情報、および、他の情報などの記憶容量を含んでよい。資源構成情報が収集された後、グローバル資源アクセス機構（例えばＡＰＩ）、および、グローバル資源記述子６１２が構築される。グローバル資源記述子は、資源へのアクセス方法を識別する情報を含み、かつ、資源の構成（グローバルおよび／またはローカルの観点から）を記述する。
【００５４】
ブロック５１６のオペレーション終了後、グローバル資源記述子６１２は、ブロック５１８のＯＯＢチャネルを介し、ラック内のアクティブノードに伝送される。この伝送は、ノード対ノードのＯＯＢ通信を用い、または、ＯＯＢ同報通信を介し実行されてよい。グローバル資源記述子の受信に応答し、次の資源処理を導くブロック５２０におけるノードを受信することによりグローバル資源記述子は格納される。ブロック５１０、５１２、５１４、５１６、５１８、および、５２０のオペレーションは、共有可能なすべての資源が処理されるまで、発見されたそれぞれの資源ごとに同様のやり方で繰り返し実行される。
【００５５】
一実施例によれば、共有資源へのアクセスは、ブロック５２２におけるそれらのグローバル資源ＡＰＩを介し発見された共有資源にアクセスするよう構成された対応するファームウェアデバイスドライバにより提供される。特定の資源に適用されるときのこのアクセススキームの詳細は、以下に述べる。次のブロック５２４に示されるように、ＯＳのロードを準備するために前述のように継続してプレブートプラットフォーム初期化オペレーションが行われる。
【００５６】
ブロック５２６におけるＯＳロードの間に、発見された任意の共有資源に対応するグローバル資源記述子は、オペレーションシステムに渡される。ＯＳに渡されるグローバル資源記述子は、ブロック５１６で作成されたものと同じであってもなくてもかまわない。本質的に、グローバル資源記述子は、それ自身のデバイスドライバを介しオペレーティングシステムが資源へのアクセスを設定できるようにするための情報を含む。例えば、単一の共有記憶ボリュームの場合、ＯＳは、共有される個別の記憶装置の個別の記憶容量におよぶ記憶容量を有する「ローカル」記憶装置（または任意でネットワーク化された記憶装置）へのアクセスを有することを示す情報を受信する。多数の共有記憶ボリュームの場合は、それぞれの記憶容量情報は、それぞれのボリュームに対するＯＳに伝えられてよい。ＯＳのロードの完了により、次のブロック５２８に示されるようなＯＳ実行時オペレーションが導かれる。
【００５７】
ＯＳの実行中、グローバル資源は、オペレーティングシステムと、「低レベル」アクセスを共有資源に提供するよう構成されたファームウェア構成要素との組合せによりアクセスされる。最新のＯＳ／ファームウェアアーキテクチャ下では、デバイスアクセススキームは、オペレーティングシステムベンダがそれぞれ個別のデバイスに特有のデバイスドライバの書き込みを必要としないよう、意図的に抽象化され、これらのさらなる明確なアクセスの詳細は、対応するファームウェアドライバにより提供される。このアーキテクチャの成果の１つは、オペレーティングシステムがハードウェアデバイスに直接アクセスしなくてもいいことである。このことは、さまざまな点で有利である。特に、オペレーティングシステムは、デバイスの特別な低レベルアクセス構成を知る必要がない。したがって、個々のデバイスの資源を結集させた「仮想」資源を「構築」でき、適切に構成されたファームウェアドライバを介しこのようなデバイスに対応するアクセスが抽象化されることにより、ＯＳは、仮想資源が実際のローカルデバイスであるとみなすようになる。
【００５８】
一実施例において、この抽象化されたアクセススキームは、図８Ａおよび８Ｂに示されるような多層アーキテクチャとして構成される。各ブレードＢＬＡＤＥ１およびＢＬＡＤＥ２は、ＯＳデバイスドライバ８００−１および８００−２と、マネジメント／アクセスドライバ８０２−１および８０２−２と、資源デバイスドライバ８０４−１および８０４−２と、ＯＯＢ通信ハンドラ６０４−１および６０４−２とを含むアーキテクチャ構成要素のそれぞれのコピーを有する。
【００５９】
図７は、一実施例に従う共有資源にアクセスするための例示的プロセスを示すフローチャートである。このプロセスは、開始ブロック７００で示されるように、リクエスタからのアクセス要求により開始する。典型的なリクエスタは、プラットフォームのオペレーティングシステムで実行するアプリケーションであってもよい。このようなアプリケーションに対応する実行可能なコードは、図８Ａおよび８Ｂにおける実行時（ＲＴ）アプリケーション（ＡＰＰ）８０６および８０８により示されるようなシステムメモリ２０４に通常格納される。例えば、実行時アプリケーション８０６が共有データ記憶資源へのアクセスを望んでいると仮定する。この例では、アクセス要求は、予め格納されたファイルのオープンに対応する。ファイルの場所（ドライブ指定、経路およびファイル名など）が提供されると、実行時アプリケーションは、まず、ファイルにアクセスするようオペレーティングシステム（８１０）に要求する。ドライブ指定は、ブレード１の資源１と、ブレード２の資源２とを含む複数のディスクドライブ２１８を備える仮想グローバル記憶資源に対しオペレーティングシステムにより予め割り当てられたドライブレターである。
【００６０】
要求に応答し、オペレーティングシステム８１０は、ブロック７０２における記憶資源にアクセスするべくそのＯＳデバイスドライバ８００−１を用いる。通常、ＯＳデバイスドライバ８００−１が資源ドライバ８０４−１と直接インターフェースして資源１にアクセスする。しかしながら、マネジメント／アクセスドライバ８０２−１が代わりにアクセスされる。このような変更を実現するためには、ＡＰＩのようなインターフェース情報がＯＳロードの間にＯＳに伝えられ、それによって、ＯＳは、対応する資源（例えば資源１）にアクセスする要求があるときはいつでも、マネジメント／アクセスドライバ８０２−１にアクセスするよう命じられる。
【００６１】
どの共有資源がその要求にサービスを提供するかを決定するべく、適切な資源がアクセスできる特定のホストを識別するための機構が提供される。一実施例において、この機構は、グローバル資源マップにより実現が容易になる。図８ａの実施例において、共通のグローバル資源マップのローカルコピー８１２−１、および、８１２−２は、ブレードＢＬＡＤＥ１およびＢＬＡＤＥ２のそれぞれに格納される。図８Ｂの実施例では、共有グローバル資源マップ８１２Ａは、グローバル資源マネージャ６０８によりホストされる。グローバル資源マップは、特定の資源と、それら特定の資源によりホストされるグローバル資源の一部分とを一致させる。
【００６２】
続いて図７のフローチャートのブロック７０４において、マネジメント／アクセスドライバがローカルグローバル資源マップ８１２を問い合せ、特定のアクセス要求下にある資源のホストを決定する。この資源および／またはこれのホストは、例示された「資源ターゲット」として知られ、ＢＬＡＤＥ２にホストされる資源２を含む。
【００６３】
一旦資源ターゲットが識別されると、ＯＯＢ通信オペレーションは、資源アクセス要求を資源ターゲットに送る。まず、要求するプラットフォーム（例えば８０２−１）におけるマネジメント／アクセスドライバは、ＳＭＩをアサートし、そのプラットフォームローカルＯＯＢ通信ハンドラ６０４−１を起動する。それに応答し、ＢＬＡＤＥ１のプロセッサは、ブロック７０８で、モードをＳＭＭに切り替え、ＯＯＢ通信ハンドラ６０４−１が起動するまでにそのＳＭＭハンドラをディスパッチする。すると、ＯＯＢ通信ハンドラは、資源ターゲットホスト（ＢＬＡＤＥ２）におけるＳＭＩ信号をアサートし、２つのブレード間のＯＯＢ通信を開始する。ＳＭＩに応答し、ＢＬＡＤＥ２におけるプロセッサモードは、ブロック７１０において、そのＯＯＢ通信ハンドラを起動するＳＭＭに切り替えられる。この時点で、ブレード１および２は、ＯＯＢチャネル６１０を介し通信できるようにされ、アクセス要求は、ＯＯＢ通信ハンドラ６０４−２により受信される。一実施例において、資源アクセス要求が送信された後、「ＲＳＭ］命令がＢＬＡＤＥ１のプロセッサに発せられることにより、プロフェッサのオペレーティングモードは、ＳＭＭに切り替わる前のモードへと戻る。
【００６４】
次に、ブロック７１２において、アクセス要求は、マネジメント／アクセスドライバ８０２−２にそのＡＰＩを介し送られる。任意の実施例において、その後ブロック７１４においてクエリが実行され、アクセス要求を受信するプラットフォームがターゲット資源の実際のホストであることを確認する。もし正しいホストでない場合、一実施例では、そのことを示すリクエスタメッセージが返送される（図示せず）。他の実施例では、適切なグローバル資源マネージャが状況を把握している。基本的には、ローカルグローバル資源マップが異なる情報を含む場合（すなわちもはや同期しない）にこの状況は起きる。すると、グローバル資源マネージャは、コマンドを発し、ローカルグローバル資源マップを再び同期させる（図示せず）。
【００６５】
続いてブロック７１６では、プラットフォームホストの資源デバイスドライバ（８０４−２）が用いられ、アクセス要求にサービスを提供するよう、資源（例えば資源２）にアクセスする。本実施例では、アクセスは、要求されたデータファイルを返す。そして、ブロック７１８において、要求に対応するデータが、ＯＯＢチャネル６１０を介し、リクエスタに戻される。通信終了時において、ＢＬＡＤＥ２のプロセッサにＲＳＭ命令が発せられ、プロセッサのオペレーティングモードは、ＳＭＭに切り替わる前のモードに戻る。
【００６６】
特定の実施によっては、リクエスタのプロセッサは、この時点でＳＭＭにしてもしなくてもよい。例えば、前述の実施例において、リクエスタ（ＢＬＡＤＥ１）のプロセッサは、ブロック７０８において、ＳＭＭから切り替わる。この場合、ブロック７２２において新たなＳＭＩがアサートされ、ＯＯＢ通信ハンドラを起動させる。（任意のスキームに従い）アクセス要求を送信した後もＳＭＭモードが終了しない場合、ＯＯＢ通信ハンドラは、返送されるデータを受信するよう、すでに待機中である。いずれにせよ、ブロック７２４にで、返送されるデータは、ＯＯＢチャネル６１０を介し受信され、リクエスタのマネジメント／アクセスドライバ（８０２−１）へと渡される。次に、ブロック７２６でこのファームウェアドライバは、データをＯＳデバイスドライバ８００−１に送り、その後ブロック７２８で、そのデータは、オペレーティングシステムを介し、リクエスタにより受け取られる。
【００６７】
図８Ｂの実施例において、グローバル資源マップのローカルコピーの代わりに、単一のグローバル資源マップを用い、同様の資源アクセスプロセスが実行される。要するに、ローカルグローバル資源マップを用いるのではなく、グローバル資源マネージャ６０８が資源にアクセスするためのプロキシとして用いられることを除けば、図８Ａを参照して上記に述べたのと同じような数多いオペレーションである。したがって、資源アクセス要求は、識別された資源ターゲットに直接送られるのではなく、ＯＯＢチャネル６１０を介しグローバル資源マネージャ６０８に送信される。要求の受信と同時に、グローバル資源マップ８１２Ａの探索が実行され、資源ターゲットが決定される。続いて、データ要求は、リクエスタを識別する情報と共に、識別された資源ターゲットへと送られる。要求の受信と同時に、任意のオペレーション７１４を除くブロック７１２−７２８のオペレーションが実行される。
【００６８】
前述のスキームは、それぞれが各自の有する効果を発揮する。ローカルグローバル資源マップが用いられた場合、プロキシは必要なく、したがって、ブレードサーバ構成要素で実行するソフトウェアコンポーネントを変える必要もない。しかしながら、グローバル資源マップの同期化を促進する機構は必要なので、各ブレードに対するマネジメントオーバヘッドは増大する。単一のグローバル資源マネージャを用いる主な利点は、グローバル資源マップの同時発生が保証され（コピーが１つだけなので）、マップへの変更が個々のブレードの協力なしで行えることである。ほとんどの実施例において、主な欠点は、グローバル資源マネージャ機能のためのホストがどうしても必要になることである。通常、ホストは、マネジメント構成要素、あるいは、ブレードの１つである（例えば指名選択またはデフォルト選択されたブレード）。
【００６９】
一実施例において、グローバル資源マネージャにサービスを提供するブレードは、指名プロセスによって識別され、その場合、各ブレードは、マネジメントタスクを実行するためのファームウェアを含んでよい。一般的に、指名スキームは、シャーシスロットのような物理的割当て、または、ファーストイン順序スキームなどの活性化スキームに基づいてよい。例えば、スロットに基づくスキームでは、最下位のスロット割当てを有するブレードは、電源決定タスクが割り当てられる。このブレードが取り除かれた場合は、残りのブレードの中から、最下位スロット割当てを有するブレードが、グローバル資源マネージャのホストとなるよう指名されることもある。ファーストイン順序スキームでは、各ブレードは、ブレードが挿入されたかまたは起動された順序に基づき、挿入順序識別子（例えばナンバー）に割り当てられる。グローバルマネジメントタスクは、最初にインストールされたブレードである最も小さいナンバーのブレードに割り当てられる。このブレードが取り除かれると同時に、次に小さいインストールナンバーのブレードが新たな電源決定器として指名される。グローバル資源マネージャにおける変更全体の連続オペレーションを確実にする目的で、冗長スキームが実行され、そこで第２のブレードがライブバックアップとして指定される。
【００７０】
通常、グローバル資源マッピングデータは、システムメモリ内、または、ファームウェア変数データとして格納されてよい。ファームウェア変数データとして格納された場合、マッピングデータは、プラットフォームのシャットダウンの間持続できる。一実施例において、マッピングデータは、オペレーティングシステムから見えないシステムメモリの一部が格納される。システムメモリの見えない部分は、プレブートオペレーションの間、ＳＭＲＡＭの一部またはファームウェアによりリザーブされるメモリの一部を含んでよい。シャットダウンの間グローバル資源マッピングデータを持続させるやり方として、ディスクドライブのような持続性記憶装置にデータを格納する方法がる。しかしながら、ディスクドライブを用いる場合は、マッピングデータをディスクドライブのホスト保護領域（ＨＰＡ）など、プラットフォームオペレーティングシステムにアクセスされないように格納することが推奨される。グローバル資源マッピングデータが中央レポジトリに格納される場合（すなわち、図８Ｂの実施例により示されるように）、上記に提示されたものと同様のさまざまな記憶オプションを用いることもできる。グローバル資源マネージャが複数のサーバブレード以外の構成要素によりホストされる場合（例えば、マネジメントカード１１２または外部マネジメントサーバによりホストされる場合）、それらのホストには、ブレードで動作するオペレーティングシステムがアクセスできないので、ディスク記憶装置は安全に実行されることができる。
【００７１】
資源共有のより特殊な実施例を図９Ａ−Ｂおよび１０Ａ−Ｂに示す。これらのケースでは、共有される資源は、ディスクドライブ２１８を含む。図９Ａおよび１０Ａに示された実施例９００において、複数のディスクドライブ２１８により提供される記憶資源は、仮想記憶ボリューム"Ｖ："を形成するよう結集される。説明を明確にするべく、各ディスクドライブの記憶資源は、１０ブロックを含むＩ／Ｏ記憶群それぞれとして示される。さらに、各ブレード１−１６は、単一のディスクドライブ２１８のホストであることが示されている。実際の実行において、各ブレードは、０−Ｎディスクドライブをホストしてもよく（その構成に基づく）、各ディスクドライブのブロック数は、変化してよい。また、実際のブロック数は、ここに示されているものより桁違いに多くすることもできる。
【００７２】
オペレーティングシステムの見地からすると、仮想記憶ボリュームＶ：は、単一の記憶装置である。一般的に、共有記憶資源は、１−Ｎ仮想記憶ボリュームとして構成され、各ボリュームは、記憶装置のそれぞれのセットごとに張られた空間である。現実には、仮想記憶ボリュームＶ：は、１６のディスクドライブ２１８におよぶ。これを実現するため、ルックアップテーブル１０００を含むブローバル資源マップが用いられる。ルックアップテーブルは、Ｉ／Ｏブロックのそれぞれの範囲をＩ／Ｏブロックをホストするディスクドライブが存在するブレードにマップする。多数のディスクドライブをホストすることが可能な単一のブレードの場合、マップは、各ブレードにおける特定の記憶装置を識別する情報をさらに含むこともある。一般的に、ブレード数を単純に識別するよりはむしろ、アドレッシングスキームが用いられているが、説明を明確かつ単純にするため、ブレード数を割り当てて示している。
【００７３】
図９Ｂおよび１０Ｂは、ＲＡＩＤ（個別ディスクの冗長配列）−１標準に従うミラーリングおよびデュプレキシングを用いたＲＡＩＤ実施例９０２を示す。ＲＡＩＤ−１において、記憶装置のそれぞれのセットが対になり、データは、データの同一セットが対になった各記憶装置に書き込まれることにより、反映される。前述と同様の方法において、集結した記憶は、オペレーティングシステムに対し、仮想ボリュームＶ：として見える。図示された実施例において、記憶装置の数および種類は、実施例９００の記憶装置と同一であり、したがって、仮想ボリュームのブロックＩ／Ｏ記憶容量は、８０ブロックに半減する。グローバル資源マッピングは、オペレーティングシステムが対応するブロックＩ／Ｏアクセス要求を作成するとき、どのディスクドライブがアクセスされるかを決定するためのルックアップテーブル１００２に含まれる。ディスクドライブの対は、ＡからＨまでのラベルが付けられた論理記憶装置エンティティに分割される。
【００７４】
ＲＡＩＤ−１の原理に従い、論理記憶装置エンティティへの書き込みアクセスが実行されたとき、データは、基になる記憶装置それぞれに書き込まれる。一方、読み込みアクセスの間は、データは、（概ね）単一の記憶装から検索される。ＲＡＩＤ−１の実施の複雑さによっては、記憶装置の対の１つがデフォルト読み込みデバイスとして割当てられるか、または、記憶装置の両方により、並列読取り（デュプレキシング）を考慮に入れたこの機能を容易にすることができる。
【００７５】
図示された構成に加え、１つ、または、それ以上のディスクドライブ２１８を「ホットスペア」として用いる構成もある。この場合、ホットスペア記憶装置は、通常のアクセス操作の間には用いられず、故障したデバイスまたはブレードと交換するための予備となる。規格では、ホットスペアの交換が発生すると、（対の）故障していないデバイスに格納されたデータが交換デバイスに書き込まれることにより、記憶システムは、完全な冗長状態に戻る。これは、インタラクティブな方法で実行してもよく（例えば、並行して新たなデータ書き込みを許容するなど）、または、新たな書き込みを許容する前に実行してもよい。
【００７６】
一般的に，ＲＡＩＤ−１スキームは、単一のグローバル資源マネージャを用いるか、または、ローカルマネジメントを介すかのいずれかにより展開されることができる。例えば、（スタティック資源構成に対応して）「スタティック」マップが用いられる場合、適切なマッピング情報は、各ブレードに格納されることができる。一実施例では、この情報は、ファームウェア変数データとして格納されることもでき、それによって、プラットフォームのリセットまたはシャットダウンの間も持続することができる。動的な構成環境では、構成変化に対応するアップデートされた資源マッピングを少なくとも決定するための中央グローバル資源マネージャを用いることが望ましい。
【００７７】
ＲＡＩＤ−１に加え、ＲＡＩＤ−０、ＲＡＩＤ−２、ＲＡＩＤ−３、ＲＡＩＤ−５、および、ＲＡＩＤ−１０を含む他のＲＡＩＤ標準冗長記憶スキームを用いてもよい。これらのスキームはそれぞれある形式のストライピングを含むので、グローバル資源マップの複雑さが実質的に増す。さまざまな理由から、個別のローカルマネージャよりはむしろ中央グローバル資源マネージャを介した方が、ＲＡＩＤ−０、ＲＡＩＤ−２、ＲＡＩＤ−３、ＲＡＩＤ−５、および、ＲＡＩＤ−１０の実行は、より容易になる。
【００７８】
前述の原理は、ブレードサーバ環境を背景に述べられているが、これに限定されない。各ブレードは、ラックマウントサーバ、または、スタンドアロンサーバなどの独立したプラットフォームとみなしてよく、複数のプラットフォームにわたる資源共有は、ＯＯＢチャネルを介し、前述と同様のやり方で実現することができる。例えば、ラックマウントサーバ構成における配線および／またはルーティングは、ＯＯＢチャネルをサポートする目的で提供されてよい。
【００７９】
ラックマウントサーバなどに適切である、本発明の特定の実施例は、通常ＫＶＭとして知られる共有キーボード・ビデオ・マウスＩ／Ｏに関する。典型的なラックサーバでは、ＫＶＭスイッチが用いられることにより、単一のキーボード、ビデオディスプレイ、および、マウスがラック内のすべてのサーバに共有されることができるようになる。ＫＶＭスイッチは、別々のサーバから（それぞれのケーブルを介し）単一のキーボード、ビデオ、および、マウスＩ／ＯポートにＫＶＭ信号を送り、それによって、選択されたサーバのＫＶＭ信号は、選択ノブを回すことにより、または、入力信号源を選択することにより、アクセスされることができる。高密度サーバでは、配線および設置にかかるコストに加え、ＫＶＭスイッチに１５００ドルの費用がかかることもある。また、ＫＶＭ配線は、ベンチレーションおよびアクセスの可能性を低下させる。
【００８０】
前述した問題は、図１１-１３に示された共有ＫＶＭ実施例により解決される。図１１では、複数のラックマウントサーバ１１００のそれぞれは、スイッチ１１０２、および、対応するイーサネット配線（ネットワーク雲１１０４として図示）を介し他のサーバに接続される。各サーバ１１００は、プロセッサ１１０８、メモリ１１１０、ファームウェア記憶装置１１１２、および、ＮＩＣ１１１４を含む複数の構成要素がその上に装着されるかまたはそれに結合されるメインボード１１０６を含む。複数のＩ／Ｏポートも、マウスおよびキーボードポート１１１６および１１８と、ビデオポート１１２０とを含むメインボードに結合される。通常、各サーバは、複数のディスクドライブ１１２２を含む。
【００８１】
上述のＮＩＣに基づくバックチャネルＯＯＢスキームによれば、各サーバ１１００のＮＩＣ１１１４に割り当てられた第２のＭＡＣアドレスが用いられることにより、ＯＯＢチャネル１１２４をサポートする。キーボード１１２６、ビデオディスプレイ１１２８、および、マウス１１３０は、それぞれのケーブルを介し、サーバ１１００Ａの後部に配置されたＩ／Ｏポート１１１８、１１２０、および、１１１６にそれぞれ結合される。各サーバ１１１０におけるファームウェアは、サーバ１１００Ａを介し、ＫＶＭ信号をキーボード１１２６、ビデオディスプレイ１１２８、および、マウス１１３０に送るローカルグローバル資源マップ１１３２をホストするためのサポートを提供する。
【００８２】
サーバ１１００Ｎで動作するオペレーティングシステムは、通常、実行時アプリケーションへのユーザ入力に応答し、ビデオディスプレイをアップデートする要求を受信する。オペレーティングシステムは、そのＯＳビデオドライバ１２００Ｎを用いて変更を実現する。ＯＳビデオドライバは通常、オペレーティングシステムにより維持される仮想ビデオディスプレイに基づき、ビデオデータを生成し、仮想−物理ディスプレイマッピングが実行される。例えば、異なる解像度を有するモニタに表示される同じテキスト／グラフィックコンテンツには、解像度に特有の異なるビデオデータが必要である。そして、ＯＳビデオドライバがビデオルータドライバ１２０２Ｎとインターフェースすることにより、ビデオデータは、宛先デバイスであると思われる、サーバ１１００Ｎのビデオシップ１２０６Ｎに送られる。オペレーティングシステムに関する限り、ビデオルータドライバ１２０２Ｎは、サーバのファームウェアビデオデバイスドライバ、すなわち、ビデオデバイスドライバ１２０４Ｎである。しかしながら、ビデオデータの受信と同時に、ビデオルータドライバ１２０２Ｎは、グローバル資源マップ１１３４Ｎのルックアップにより、ビデオデータ宛先サーバを探索し、かつ、ＯＯＢ通信ハンドラ６０４Ｎおよび６０４Ａを介し、サーバ１１００ＡとのＯＯＢ通信を会しするよう、ＳＭＩをアサートする。
【００８３】
受信と同時に、ビデオデータは、ビデオデバイスドライバ１２０４Ａを介し、ビデオチップ１２０６Ａに書き込まれる。前述と同じ方法で、ビデオデータは、ＯＯＢ通信ハンドラ６０４Ａからビデオデバイスドライバ１２０４Ａに直接渡されるか、または、ビデオルータドライバ１２０２Ａを介し送られてもよい。ビデオデータの受信に応答し、ビデオチップ１２０６Ａは、ビデオポート１１２０を介しビデオモニタ１１２８により受信されるそのビデオ出力信号をアップデートする。オプションとして、グローバル資源マップ１１３４Ａの検証ルックアップを実行することにより、サーバ１１００Ａが正しいビデオデータ宛先サーバであることを検証してもよい。
【００８４】
キーボードおよびマウス信号は、同様な方法で処理される。ビデオと同様に、オペレーティングシステムは、通常、ポインティングデバイスの仮想位置が仮想ビデオディスプレイと相互参照されることができる仮想ポインタマップを維持し、これによって、ビデオディスプレイに関するカーソルの位置を決定することができる。また、マウス情報は、ビデオ信号の逆ルートを横断する。これは、サーバ１１００Ａを介し受信されたマウス入力がＯＯＢチャネルを介し、選択されたプラットフォーム（例えばサーバ１１００Ｎ）に伝えられるということであり、サーバ１１００Ａのグローバル資源マップ１１３４Ａをアップデートすることにより、正しい宛先プラットフォームを反映することが要求される。同様に、ルーティングキーボード信号も、マップのアップデートを要求する。キーボード信号との違いは、それらが双方向性であることであり、したがって、入出力両方のデータルート変更が要求される。
【００８５】
図１３に、キーボード入力信号処理プロトコルスタックおよびフローチャートの例を示す。ソフトウェア側のサーバ１１００Ｎのプロトコルスタックは、オペレーティングシステムキーボードドライバ１３００Ｎを含み、一方、ファームウェア構成要素は、キーボードルータドライバ１３０２Ｎ、ビデオデバイスドライバ１３０４Ｎ、および、ＯＯＢ通信ハンドラ６０４Ｎを含む。また、ファームウェア構成要素は、サーバ１１００Ａのプロトコルスタックも含む。
【００８６】
キーボード１１２６を介したユーザ入力に応答し、キーボード入力信号が生成され、キーボードポート１１１８Ａを介し、キーボードチップ１３０６Ａにより受信される。その後、キーボードチップ１３０６は、キーボードデバイスドライバ１３０４Ａにより受信される対応するキーボード（ＫＢ）データを生成する。この時点で、キーボード入力の処理は、資源共有に携わらない単一のプラットフォーム（例えばディスクトップコンピュータ）で実行されるのと同一である。通常、キーボードデバイスドライバ１３０４ＡがＯＳキーボードドライバ１３００Ａとインターフェースすることにより、キーボードデータをオペレーティングシステムに伝える。しかしながら、キーボードデータを受信するべく対象とされたＯＳキーボードドライバは、サーバ１１００Ｎで稼動している。したがって、キーボードデバイスドライバ１３０４により処理されるビデオデータがキーボードルータドライバ１３０２Ａに伝えられることにより、キーボードデータのルート変更が容易になる。
【００８７】
キーボードデータの受信に応答し、キーボードルータドライバは、グローバル資源マップ１１３４を問合せ、キーボードデータのルート変更先であるターゲットサーバを決定する。（本例ではサーバ１１００Ｎ）。そして、キーボードルータドライバは、ＳＭＩをアサートし、サーバ１１００Ａで動作するプロセッサをＳＭＭにし、キーボードデータをサーバターゲット識別データと共にＯＯＢ通信ハンドラ６０４Ａに伝える。そして、ＯＯＢ通信ハンドラ６０４ＡがＯＯＢ通信ハンドラ６０４Ｎとやり取りすることにより、ＯＯＢチャネル１１２４を介しての２つのサーバ間のＯＯＢ通信が容易になり、次にキーボードデータがＯＯＢ通信ハンドラ６０４Ｎにより受信されるようになる。キーボードデータの受信に応答し、ＯＯＢハンドラ６０４Ｎは、受信したキーボードデータをキーボードルータドライバ１３０２Ｎに転送する。この時、キーボードルータドライバは、キーボードデータを直接ＯＳキーボードドライバ１３００Ｎに渡してもよいし、あるいは、データをＯＳキーボードドライバ１３００Ｎに渡す前に、グローバル資源マップ１１３４Ｎのルーティング検証ルックアップを実行することにより、サーバ１１００Ｎがキーボードデータを受信するべき正しいサーバであることを保証するようにしてもよい。そして、ＯＳキーボードドライバは、キーボードデータを処理し、処理済のデータを、カレントフォーカスを有する実行時アプリケーションに提供する。
【００８８】
以上説明した本発明の実施例は、要約書に記載された事項を含むが、それに限定されない。上述した例示的な実施例は、当業者であれば本発明の範囲および原理を逸脱することなく様々に修正および変更できることが理解できよう。
【００８９】
前述の詳細な説明を考慮し、本発明は様々に修正できる。特許請求の範囲に用いられる用語は、本発明を明細書に記載された特定の実施例および特許請求の範囲に限定するものと解釈すべきではない。本発明の範囲は、特許請求の範囲の請求項に記載した全ての範囲内によって決定されるべきである。
【図面の簡単な説明】
【００９０】
【図１Ａ】複数のサーバブレードが設置されるブレードサーバシャーシの例を示す正面等角図である。
【図１Ｂ】図１Ａのブレードサーバシャーシの後部等角図である。
【図１Ｃ】図１Ａおよび図１Ｂに対応する複数のラックマウントブレードサーバシャーシが設置されるブレードサーバラックの正面等角図である。
【図２】典型的なサーバブレードの構成要素の詳細を示す図である。
【図３】ＡＣＰＩ標準に従うパワーマネジメントを展開するために用いられるさまざまなファームウェアおよびオペレーティングシステムを示す概略ブロック図である。
【図４】本発明の一実施例に従うパワーマネジメントスキームを実行するためのブレードを設定するブレード初期化の間に用いられるオペレーションおよびロジックを示すフローチャートである。
【図５】本発明の一実施例に従う資源共有をセットアップする初期化プロセスの間に用いられるオペレーションおよびロジックを示すフローチャートである。
【図６】図６の初期化プロセスの間に発生する様々なデータフローを示す概略図である。
【図７】本発明の一実施例に従う要求にサービスを提供するコンピューティングプラットフォームの要求時に受信される資源アクセス要求に応答して用いられるオペレーションおよびロジックを示すフローチャートである（サービスを提供する資源は、他のコンピューティングプラットフォームによりホストされる）。
【図８Ａ】ローカルグローバル資源マップを用いての、共有資源アクセスにおける対のコンピューティングプラットフォーム間のデータフローを示す概略図である。
【図８Ｂ】グローバル資源マネージャによりホストされる単一のグローバル資源マップを用いての、共有資源アクセスにおける対のコンピューティングプラットフォーム間のデータフローを示す概略図である。
【図９Ａ】複数のディスクドライブの記憶容量となる仮想記憶ボリュームとして構成される共有記憶資源を示す概略図である。
【図９Ｂ】図９Ａの共有記憶資源スキームとの相違を示す概略図である（ＲＡＩＤ−１は資源アクセスの間に実行される）。
【図１０Ａ】図９Ａの仮想記憶ボリュームスキームの更なる詳細を示す概略図である。
【図１０Ｂ】図９ＢのＲＡＩＤ−１実行の更なる詳細を示す概略図である。
【図１１】本発明の一実施例に従う共有キーボード、ビデオ、および、マウス（ＫＶＭ）アクセススキームを示す概略図である。
【図１２】ビデオ資源の共有をサポートする対のコンピューティングプラットフォーム間のデータフローを示す概略図である。
【図１３】ユーザ入力資源の共有をサポートする対のコンピューティングプラットフォーム間のデータフローを示す概略図である。
【特許請求の範囲】
【請求項１】
複数のコンピューティングプラットフォームで資源を共有する方法であって、
共有資源にアクセスするための資源アクセス要求を第１のコンピューティングプラットフォームで受信するステップと、
共有資源へのアクセスを可能にする第２のコンピューティングプラットフォームを決定するステップと、
前記第２のコンピューティングプラットフォームに前記資源アクセス要求を送信するステップと、
前記第２のコンピューティングプラットフォームを介し、前記共有資源にアクセスするステップと、
を含むことを特徴とする方法。
【請求項２】
前記方法は、
前記複数のコンピューティングプラットフォームが、ブレードサーバ環境で動作する複数のサーバブレードを備えることを特徴とする、請求項１に記載の方法。
【請求項３】
前記方法は、
前記複数のコンピューティングプラットフォームで動作するオペレーティングシステムに対しトランスペアレントに実行されることを特徴とする、請求項１に記載の方法。
【請求項４】
前記方法は、
前記複数のコンピューティングプラットフォームのそれぞれで動作するファームウェアにより実現が容易になることを特徴とする、請求項１に記載の方法。
【請求項５】
前記方法は、
前記資源アクセス要求が、バンド外（ＯＯＢ）の通信チャネルを介し、前記第２のコンピューティングプラットフォームに送信されることを特徴とする、請求項１に記載の方法。
【請求項６】
前記方法は、
前記ＯＯＢ通信チャネルが、システム管理マネジメントバス、イーサネットネットワーク、または、シリアル通信リンクの１つを備えることを特徴とする、請求項５に記載の方法。
【請求項７】
前記方法は、
目標となる資源が記憶装置を含むことを特徴とする、請求項５に記載の方法。
【請求項８】
前記方法は、
前記資源アクセス要求が、記憶装置書き込み要求を含み、前記方法は、該記憶装置書き込み要求に対応するデータを、前記ＯＯＢ通信チャネルを介し送信するステップをさらに含むことを特徴とする、請求項７に記載の方法。
【請求項９】
前記方法は、
前記資源アクセス要求が記憶装置読み取り要求を含み、前記方法は、
前記共有資源から前記読み取り要求に対応するデータを検索するステップと、
前記ＯＯＢ通信チャネルを介し、前記検索したデータを前記第１のコンピューティングプラットフォームに返送するステップと、
をさらに備えることを特徴とする、請求項７に記載の方法。
【請求項１０】
前記方法は、
コンピュータプラットフォームを介しアクセス可能なのはどの資源であるかを識別するグローバル資源マッピングデータを維持するステップと、
前記グローバル資源マッピングデータを用い、前記共有資源へのアクセスに用いられるのはどのコンピューティングプラットフォームかを決定するステップと、
をさらに備えることを特徴とする、請求項１に記載の方法。
【請求項１１】
前記方法は、
前記複数のコンピューティングプラットフォームのそれぞれにおいて、グローバル資源マッピングデータのローカルコピーが維持されていることを特徴とする、請求項１０に記載の方法。
【請求項１２】
前記方法は、
前記グローバル資源マッピングデータが、中央グローバル資源マネージャにより維持されることを特徴とする、請求項１０に記載の方法。
【請求項１３】
複数のコンピューティングプラットフォームで複数の記憶装置を共有する方法であって、
前記複数の記憶装置を仮想記憶ボリュームとして形成するステップと、
前記仮想記憶ボリュームとして定義される入出力（Ｉ／Ｏ）ブロックを、該Ｉ／Ｏブロックを実際にホストする対応する記憶装置にマップするグローバル資源マップを維持するステップと、
前記仮想記憶ボリュームを介しそこからデータがアクセスされるＩ／Ｏブロックを識別するデータアクセス要求を受信するステップと、
前記Ｉ／Ｏブロックを実際にホストするターゲット記憶装置へのアクセスが前記グローバル資源マップの使用を通じて可能になるコンピューティングプラットフォームを識別するステップと、
前記識別されたコンピューティングプラットフォームに前記データアクセス要求を転送するステップと、
前記識別されたコンピューティングプラットフォームを介し、前記ターゲット記憶装置のＩ／Ｏブロックにアクセスするステップと、
を含むことを特徴とする方法。
【請求項１４】
前記方法は、
前記複数の記憶装置を少なくとも１つのＲＡＩＤ（個別ディスクの冗長配列）記憶ボリュームとして構成するステップと、
前記少なくとも１つのＲＡＩＤ仮想記憶ボリュームとして定義された入出力（Ｉ／Ｏ）ブロックを、該（Ｉ／Ｏ）ブロックを実際にホストする対応する記憶装置にマップするＲＡＩＤ構成マッピング情報を維持するステップと、
読み書きアクセス要求に応答し、適切な記憶装置にアクセスするよう、前記ＲＡＩＤ構成マッピング情報を用いるステップと、
をさらに含むことを特徴とする、請求項１３に記載の方法。
【請求項１５】
前記方法は、
前記ＲＡＩＤ仮想記憶ボリュームが、前記ＲＡＩＤ−１標準に従い構成されることを特徴とする、請求項１４に記載の方法。
【請求項１６】
複数のコンピューティングプラットフォームで入力装置を共有する方法であって、
第１のコンピュータプラットフォームにおいて、第１のプラットフォームに結合される入力装置により生成される入力信号の受信に応答して生成される入力データを、第２のコンピューティングプラットフォームに転送するステップと、
前記第２のコンピューティングプラットフォームで動作するオペレーティングシステムに前記入力データを提供するステップと、
を含むことを特徴とする方法。
【請求項１７】
前記方法は、
前記第２のコンピューティングプラットフォームで動作するオペレーティングシステムに対しトランスペアレントに、ファームウェアによって実行されることを特徴とする、請求項１６に記載の方法。
【請求項１８】
前記方法は、
前記入力装置が、キーボードおよびマウスの１つを含むことを特徴とする、請求項１６に記載の方法。
【請求項１９】
複数のコンピューティングプラットフォームで、キーボード、ビデオ、および、マウス資源を共有する方法であって、
ユーザ入力に応答し、資源ホストコンピューティングプラットフォームで生成されるユーザ入力データを、該資源ホストコンピューティングプラットフォームに結合されたキーボードおよびマウスを介し、ターゲットコンピューティングプラットフォームに転送するステップと、
前記ユーザ入力データを、前記ターゲットコンピューティングプラットフォームで動作するオペレーティングシステムに提供するステップと、
前記ターゲットコンピューティングプラットフォームで動作するオペレーティングシステムにより生成されるビデオデータを、前記資源ホストコンピューティングプラットフォームに転送するステップと、
前記ビデオデータを前記資源ホストコンピューティングプラットフォームで処理することにより、前記資源ホストコンピューティングプラットフォームに結合されるビデオディスプレイを駆動するビデオディスプレイ信号を生成するステップと、
を含むことを特徴とする方法。
【請求項２０】
前記方法は、
前記資源ホストおよびターゲットコンピューティングプラットフォームのそれぞれに格納されたファームウェアにより容易に実現されることを特徴とする、請求項１９に記載の方法。
【請求項２１】
前記方法は、
前記資源ホスト、および、前記ターゲットコンピューティングプラットフォームを識別するグローバル資源マッピング情報を維持するステップをさらに含むことを特徴とする、請求項１９に記載の方法。
【請求項２２】
前記方法は、
前記ユーザ入力およびビデオデータが、バンド外通信チャネルを介し転送されることを特徴とする、請求項１９に記載の方法。
【請求項２３】
命令がその上に格納された機械可読媒体を含む製品であって、第１のコンピューティングプラットフォームに結合されたキーボード、ビデオ、および、マウス資源の共有をサポートする第１および第２のコンピューティングプラットフォームにおいて、前記命令は、
前記キーボードおよびマウスを介し、ユーザ入力に応答して前記第１のコンピューティングプラットフォームで生成される入力データを第２のコンピューティングプラットフォームに転送するステップと、
前記第２のコンピューティングプラットフォームで動作するオペレーティングシステムに前記入力データを提供するステップと、
前記第２のコンピューティングプラットフォームで動作する前記オペレーティングシステムにより生成されたビデオデータを、前記第１のコンピューティングプラットフォームにおけるビデオ信号生成構成要素に転送するステップとを含む動作を実行することを特徴とする製品。
【請求項２４】
前記製品は、
前記命令がファームウェア命令を含むことを特徴とする、請求項２３に記載の製品。
【請求項２５】
前記製品は、フラッシュデバイスを含むことを特徴とする、請求項２３に記載の製品。
【請求項２６】
前記製品は、前記動作が、前記第２のコンピューティングプラットフォームで動作するオペレーティングシステムに対しトランスペアレントに実行されることを特徴とする、請求項２３に記載の製品。
【請求項２７】
ブレードサーバシステムであって、
それぞれのサーバブレードが挿入可能な複数のスロットを含むシャーシと、
挿入されたサーバブレードのそれぞれのコネクタと嵌合する複数のコネクタを有し、かつ、前記複数のコネクタ間に通信経路を提供することにより、バンド外（ＯＯＢ）通信チャネルにおける実現を容易にするインターフェース平面と、
複数のサーバブレードとを含み、前記複数のサーバブレードのそれぞれは、その上で実効可能なプロセッサおよびファームウェアを含み、該プロセッサおよびファームウェアは、
前記複数のサーバブレードの少なくとも１つによりホストされる共有資源へのアクセスを要求するサーバブレード上で動作するオペレーティングシステムからの資源アクセス要求を受信するステップと、
前記資源アクセス要求にサービスを提供できるターゲット資源をホストする前記複数のサーバブレードの中からターゲット資源ホストを決定するステップと、
前記資源アクセス要求を前記ターゲット資源ホストに送信するステップと、
前記ターゲット資源ホストを介し前記ターゲット資源にアクセスすることにより、前記資源アクセス要求にサービスを提供するステップとを含む動作を実行することを特徴とするブレードサーバシステム。
【請求項２８】
前記ブレードサーバシステムは、
前記動作が、前記複数のサーバブレード上で実行されることが可能なオペレーティングシステムに対し、トランスペアレントに実行されることを特徴とする、請求項２７に記載のブレードサーバ。
【請求項２９】
前記ブレードサーバシステムは、
前記複数のサーバブレード間の通信が、バンド外ＯＯＢ通信チャネルにより容易に実現されることを特徴とする、請求項２７に記載のブレードサーバシステム。
【請求項３０】
前記ブレードサーバシステムは、前記各プロセッサが、前記ＯＯＢチャネルを介しての通信を容易にするために用いられる隠し実行モードをサポートすることを特徴とする、請求項２９に記載のブレードサーバシステム。
【請求項１】
複数のコンピューティングプラットフォームで資源を共有する方法であって、
共有資源にアクセスするための資源アクセス要求を第１のコンピューティングプラットフォームで受信するステップと、
共有資源へのアクセスを可能にする第２のコンピューティングプラットフォームを決定するステップと、
前記第２のコンピューティングプラットフォームに前記資源アクセス要求を送信するステップと、
前記第２のコンピューティングプラットフォームを介し、前記共有資源にアクセスするステップと、
を含むことを特徴とする方法。
【請求項２】
前記方法は、
前記複数のコンピューティングプラットフォームが、ブレードサーバ環境で動作する複数のサーバブレードを備えることを特徴とする、請求項１に記載の方法。
【請求項３】
前記方法は、
前記複数のコンピューティングプラットフォームで動作するオペレーティングシステムに対しトランスペアレントに実行されることを特徴とする、請求項１に記載の方法。
【請求項４】
前記方法は、
前記複数のコンピューティングプラットフォームのそれぞれで動作するファームウェアにより実現が容易になることを特徴とする、請求項１に記載の方法。
【請求項５】
前記方法は、
前記資源アクセス要求が、バンド外（ＯＯＢ）の通信チャネルを介し、前記第２のコンピューティングプラットフォームに送信されることを特徴とする、請求項１に記載の方法。
【請求項６】
前記方法は、
前記ＯＯＢ通信チャネルが、システム管理マネジメントバス、イーサネットネットワーク、または、シリアル通信リンクの１つを備えることを特徴とする、請求項５に記載の方法。
【請求項７】
前記方法は、
目標となる資源が記憶装置を含むことを特徴とする、請求項５に記載の方法。
【請求項８】
前記方法は、
前記資源アクセス要求が、記憶装置書き込み要求を含み、前記方法は、該記憶装置書き込み要求に対応するデータを、前記ＯＯＢ通信チャネルを介し送信するステップをさらに含むことを特徴とする、請求項７に記載の方法。
【請求項９】
前記方法は、
前記資源アクセス要求が記憶装置読み取り要求を含み、前記方法は、
前記共有資源から前記読み取り要求に対応するデータを検索するステップと、
前記ＯＯＢ通信チャネルを介し、前記検索したデータを前記第１のコンピューティングプラットフォームに返送するステップと、
をさらに備えることを特徴とする、請求項７に記載の方法。
【請求項１０】
前記方法は、
コンピュータプラットフォームを介しアクセス可能なのはどの資源であるかを識別するグローバル資源マッピングデータを維持するステップと、
前記グローバル資源マッピングデータを用い、前記共有資源へのアクセスに用いられるのはどのコンピューティングプラットフォームかを決定するステップと、
をさらに備えることを特徴とする、請求項１に記載の方法。
【請求項１１】
前記方法は、
前記複数のコンピューティングプラットフォームのそれぞれにおいて、グローバル資源マッピングデータのローカルコピーが維持されていることを特徴とする、請求項１０に記載の方法。
【請求項１２】
前記方法は、
前記グローバル資源マッピングデータが、中央グローバル資源マネージャにより維持されることを特徴とする、請求項１０に記載の方法。
【請求項１３】
複数のコンピューティングプラットフォームで複数の記憶装置を共有する方法であって、
前記複数の記憶装置を仮想記憶ボリュームとして形成するステップと、
前記仮想記憶ボリュームとして定義される入出力（Ｉ／Ｏ）ブロックを、該Ｉ／Ｏブロックを実際にホストする対応する記憶装置にマップするグローバル資源マップを維持するステップと、
前記仮想記憶ボリュームを介しそこからデータがアクセスされるＩ／Ｏブロックを識別するデータアクセス要求を受信するステップと、
前記Ｉ／Ｏブロックを実際にホストするターゲット記憶装置へのアクセスが前記グローバル資源マップの使用を通じて可能になるコンピューティングプラットフォームを識別するステップと、
前記識別されたコンピューティングプラットフォームに前記データアクセス要求を転送するステップと、
前記識別されたコンピューティングプラットフォームを介し、前記ターゲット記憶装置のＩ／Ｏブロックにアクセスするステップと、
を含むことを特徴とする方法。
【請求項１４】
前記方法は、
前記複数の記憶装置を少なくとも１つのＲＡＩＤ（個別ディスクの冗長配列）記憶ボリュームとして構成するステップと、
前記少なくとも１つのＲＡＩＤ仮想記憶ボリュームとして定義された入出力（Ｉ／Ｏ）ブロックを、該（Ｉ／Ｏ）ブロックを実際にホストする対応する記憶装置にマップするＲＡＩＤ構成マッピング情報を維持するステップと、
読み書きアクセス要求に応答し、適切な記憶装置にアクセスするよう、前記ＲＡＩＤ構成マッピング情報を用いるステップと、
をさらに含むことを特徴とする、請求項１３に記載の方法。
【請求項１５】
前記方法は、
前記ＲＡＩＤ仮想記憶ボリュームが、前記ＲＡＩＤ−１標準に従い構成されることを特徴とする、請求項１４に記載の方法。
【請求項１６】
複数のコンピューティングプラットフォームで入力装置を共有する方法であって、
第１のコンピュータプラットフォームにおいて、第１のプラットフォームに結合される入力装置により生成される入力信号の受信に応答して生成される入力データを、第２のコンピューティングプラットフォームに転送するステップと、
前記第２のコンピューティングプラットフォームで動作するオペレーティングシステムに前記入力データを提供するステップと、
を含むことを特徴とする方法。
【請求項１７】
前記方法は、
前記第２のコンピューティングプラットフォームで動作するオペレーティングシステムに対しトランスペアレントに、ファームウェアによって実行されることを特徴とする、請求項１６に記載の方法。
【請求項１８】
前記方法は、
前記入力装置が、キーボードおよびマウスの１つを含むことを特徴とする、請求項１６に記載の方法。
【請求項１９】
複数のコンピューティングプラットフォームで、キーボード、ビデオ、および、マウス資源を共有する方法であって、
ユーザ入力に応答し、資源ホストコンピューティングプラットフォームで生成されるユーザ入力データを、該資源ホストコンピューティングプラットフォームに結合されたキーボードおよびマウスを介し、ターゲットコンピューティングプラットフォームに転送するステップと、
前記ユーザ入力データを、前記ターゲットコンピューティングプラットフォームで動作するオペレーティングシステムに提供するステップと、
前記ターゲットコンピューティングプラットフォームで動作するオペレーティングシステムにより生成されるビデオデータを、前記資源ホストコンピューティングプラットフォームに転送するステップと、
前記ビデオデータを前記資源ホストコンピューティングプラットフォームで処理することにより、前記資源ホストコンピューティングプラットフォームに結合されるビデオディスプレイを駆動するビデオディスプレイ信号を生成するステップと、
を含むことを特徴とする方法。
【請求項２０】
前記方法は、
前記資源ホストおよびターゲットコンピューティングプラットフォームのそれぞれに格納されたファームウェアにより容易に実現されることを特徴とする、請求項１９に記載の方法。
【請求項２１】
前記方法は、
前記資源ホスト、および、前記ターゲットコンピューティングプラットフォームを識別するグローバル資源マッピング情報を維持するステップをさらに含むことを特徴とする、請求項１９に記載の方法。
【請求項２２】
前記方法は、
前記ユーザ入力およびビデオデータが、バンド外通信チャネルを介し転送されることを特徴とする、請求項１９に記載の方法。
【請求項２３】
命令がその上に格納された機械可読媒体を含む製品であって、第１のコンピューティングプラットフォームに結合されたキーボード、ビデオ、および、マウス資源の共有をサポートする第１および第２のコンピューティングプラットフォームにおいて、前記命令は、
前記キーボードおよびマウスを介し、ユーザ入力に応答して前記第１のコンピューティングプラットフォームで生成される入力データを第２のコンピューティングプラットフォームに転送するステップと、
前記第２のコンピューティングプラットフォームで動作するオペレーティングシステムに前記入力データを提供するステップと、
前記第２のコンピューティングプラットフォームで動作する前記オペレーティングシステムにより生成されたビデオデータを、前記第１のコンピューティングプラットフォームにおけるビデオ信号生成構成要素に転送するステップとを含む動作を実行することを特徴とする製品。
【請求項２４】
前記製品は、
前記命令がファームウェア命令を含むことを特徴とする、請求項２３に記載の製品。
【請求項２５】
前記製品は、フラッシュデバイスを含むことを特徴とする、請求項２３に記載の製品。
【請求項２６】
前記製品は、前記動作が、前記第２のコンピューティングプラットフォームで動作するオペレーティングシステムに対しトランスペアレントに実行されることを特徴とする、請求項２３に記載の製品。
【請求項２７】
ブレードサーバシステムであって、
それぞれのサーバブレードが挿入可能な複数のスロットを含むシャーシと、
挿入されたサーバブレードのそれぞれのコネクタと嵌合する複数のコネクタを有し、かつ、前記複数のコネクタ間に通信経路を提供することにより、バンド外（ＯＯＢ）通信チャネルにおける実現を容易にするインターフェース平面と、
複数のサーバブレードとを含み、前記複数のサーバブレードのそれぞれは、その上で実効可能なプロセッサおよびファームウェアを含み、該プロセッサおよびファームウェアは、
前記複数のサーバブレードの少なくとも１つによりホストされる共有資源へのアクセスを要求するサーバブレード上で動作するオペレーティングシステムからの資源アクセス要求を受信するステップと、
前記資源アクセス要求にサービスを提供できるターゲット資源をホストする前記複数のサーバブレードの中からターゲット資源ホストを決定するステップと、
前記資源アクセス要求を前記ターゲット資源ホストに送信するステップと、
前記ターゲット資源ホストを介し前記ターゲット資源にアクセスすることにより、前記資源アクセス要求にサービスを提供するステップとを含む動作を実行することを特徴とするブレードサーバシステム。
【請求項２８】
前記ブレードサーバシステムは、
前記動作が、前記複数のサーバブレード上で実行されることが可能なオペレーティングシステムに対し、トランスペアレントに実行されることを特徴とする、請求項２７に記載のブレードサーバ。
【請求項２９】
前記ブレードサーバシステムは、
前記複数のサーバブレード間の通信が、バンド外ＯＯＢ通信チャネルにより容易に実現されることを特徴とする、請求項２７に記載のブレードサーバシステム。
【請求項３０】
前記ブレードサーバシステムは、前記各プロセッサが、前記ＯＯＢチャネルを介しての通信を容易にするために用いられる隠し実行モードをサポートすることを特徴とする、請求項２９に記載のブレードサーバシステム。
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図１１】
【図１２】
【図１３】
【図３】
【図４】
【図５】
【図６】
【図７】
【図１１】
【図１２】
【図１３】
【公表番号】特表２００７−５２６５２７（Ｐ２００７−５２６５２７Ａ）
【公表日】平成１９年９月１３日（２００７．９．１３）
【国際特許分類】
【出願番号】特願２００６−５０９０９５（Ｐ２００６−５０９０９５）
【出願日】平成１６年６月９日（２００４．６．９）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０１８２５３
【国際公開番号】ＷＯ２００５／００６１８６
【国際公開日】平成１７年１月２０日（２００５．１．２０）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．イーサネット
２．Ｌｉｎｕｘ
【出願人】（５９１００３９４３）インテル・コーポレーション (1,101)
【Ｆターム（参考）】
【公表日】平成１９年９月１３日（２００７．９．１３）
【国際特許分類】
【出願日】平成１６年６月９日（２００４．６．９）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０１８２５３
【国際公開番号】ＷＯ２００５／００６１８６
【国際公開日】平成１７年１月２０日（２００５．１．２０）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．イーサネット
２．Ｌｉｎｕｘ
【出願人】（５９１００３９４３）インテル・コーポレーション (1,101)
【Ｆターム（参考）】
[ Back to top ]