JP4627768B2

JP4627768B2 - データ転送を制限し分散コンピュータのソフトウェアコンポーネントを管理するためのシステム

Info

Publication number: JP4627768B2
Application number: JP2007141157A
Authority: JP
Inventors: タバラバサム; シー．ハントガレン; ハイドリーアーマー; ピー．レビスティーブン; エス．スチューツデービッド; ブイ．ウェランドロバート
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2000-10-24
Filing date: 2007-05-28
Publication date: 2011-02-09
Anticipated expiration: 2021-10-24
Also published as: EP1202526A3; JP2007287165A; JP2011040096A; US20050192971A1; EP1202526A2; JP4188584B2; US7043545B2; US20050102403A1; EP2237523A2; EP2237523A3; US20050102404A1; US6886038B1; US20050102388A1; JP2002202952A; US20100287271A1; US7016950B2

Description

本発明はコンピュータシステムの管理に関する。さらに詳しくは、本発明は、データ転送を制限し分散コンピュータのソフトウェアコンポーネントを管理するためのシステム、方法、コンピュータ読取可能媒体、およびコンピュータ読取可能メモリに関する。

インターネット (the Internet) とその使用は、この近年に大幅に拡張しており、その拡張は今後も続くことが予想されている。インターネットの顕著な使い方の１つは、ワールドワイドウェブ（World Wide Web WWW。”Web”とも呼ばれている）であり、これは、ユーザが、見たりさもなければ提供したりできるドキュメントの集まりであり（”ウェブページ”と呼ばれる）、そこには、ユーザがアクセスできる１つまたは複数の他のページへのリンクが含まれているのが代表的である。多くの企業や個人は、プレゼンスをWeb上に創設し、１または２以上のWebページで自社または自分のことを記述し、自社製品やサービスを説明し、他の対象の情報を特定し、商品やサービスの購入を可能にする、といったことを行っているのが代表的である。

Webページは、Webページを「ホストする」とも呼ばれるプロセスである、１つまたは複数のWebサーバを通して、Web上で利用可能になっているのが代表的である。これらのWebページは、そのページを見ることを要求した、誰にでも自由に利用可能になっているときもあれば（例えば、会社の広告）、Webページへのアクセスが制限されているときもある（例えば、Webページにアクセスするには、パスワードが要求されることがある）。Webページを見ることを要求している人が非常に多数であると（特に、Webがグローバルにアクセス可能であること鑑みて）、十分にWebページをホストするためには、非常に多数のサーバが必要になる場合がある（例えば、同じWebページを複数のサーバでホストすると、そのWebページに同時にアクセスできる人の数が増加することになる）。さらに、Webは地理的に分散しており、アクセスに統一性がないため、サーバを異なるリモートロケーションに分散化し、世界の異なるロケーションにいる人々のアクセスタイムを最小限にすることが、しばしば望まれている。さらに、人々は、一日中Webページを見ている傾向があるので（この場合も、特にWebがグローバルにアクセス可能であることに鑑みて）、Webページをホストするサーバは、毎日24時間の間、機能状態に保っておく必要がある。

しかし、非常に多数のサーバを管理することは、困難になることがある。サーバを稼動状態に保つためには、高信頼電源が必要になる。盗みや他の悪意のある人が、サーバを破損したり、サーバにしのび込んだりする試みを防止するためには、物理的セキュリティが必要になる。アクセス要求がサーバに確実に到達することを保証するためには、高信頼インターネットコネクションが必要になる。サーバが正しく動作することを保証するためには、正しい動作環境（例えば、温度、湿度など）が必要になる。そこで、企業がこれらの問題に対処するのを支援する「共同ロケーション施設(co-location facilities)」が発達してきた。

ここで、共同ロケーション施設とは、複数のサーバを収容できる複合施設 (complex) のことである。共同ロケーション施設は、高信頼インターネットコネクション、高信頼電源、および適切な動作環境を提供しているのが代表的である。また、共同ロケーション施設は、複数のセキュアエリア（例えば、ケージ (cage)）を含み、異なる企業が自社サーバをそこに置いておくことを可能にしているのが代表的である。特定の企業が共同ロケーション施設に置いておくサーバの集まりは、実際には、任意の個々の共同ロケーション施設に、単独のサーバだけが置かれているとしても、「サーバクラスタ(server cluster)」と呼ばれている。この場合、その特定企業は、自社サーバクラスタ内のサーバのオペレーションの管理を担当することになる。

しかしながら、このような共同ロケーション施設にも、問題が起こっている。１つの問題は、データのセキュリティ (data security) である。異なる企業（競争企業でさえも）は、同一共同ロケーション施設にサーバクラスタを置くことが可能になっている。このような状況では、ある企業を目的にインターネットから受信された（またはサーバクラスタ内のサーバから送信された）データが、その共同ロケーション施設に置かれている別の企業のサーバにルーチング（経路選択）されないようにする配慮が必要である。

もう１つの問題は、共同ロケーション施設に置かれた後の、サーバの管理の問題である。現在では、ある企業に属するシステムアドミニストレータ（システム管理者）は、サーバに障害（または他の問題）が起きたとき、共同ロケーション施設のアドミニストレータに連絡し（電話によるのが代表的）、特定のサーバをリセットすること（サーバ側のハードウェアリセットボタンを押すか、あるいはサーバをパワーオフした後で、パワーオンをする方法が代表的）をアドミニストレータに要求することが可能になっている。この限られたリセットだけの機能では、企業が得られる管理機能が非常に乏しい。別の方法として、企業に属するシステムアドミニストレータは、自身で共同ロケーション施設に赴き、障害を起こしたサーバに立ち会うことが可能になっている。残念ながら、システムアドミニストレータが共同ロケーション施設に赴いて、サーバに立ち会うようにすると、大量の時間が浪費されることになる。従って、サーバコンピュータを共同ロケーション施設で管理する改善方法があると、好都合である。

さらに、世界各国に置かれている個人ユーザのコンピュータの数は増加を続けており、その形体としては、パーソナルコンピュータ（ＰＣ）、パーソナルデジタルアシスタント (personal digital assistant PDA)、ポケットコンピュータ、パームサイズ (palm-sized) コンピュータ、ハンドヘルドコンピュータ、デジタルセルラーホン (digital cellular phone) などがある。これらユーザコンピュータ上のソフトウェアの管理は非常に面倒で、時間のかかる仕事であり、また、これらのマシンのユーザは非専門家であることが多いため、これらのユーザにとっては特に困難になっている。システムアドミニストレータや技術者は、ユーザコンピュータが置かれているリモートロケーションに赴くか、あるいは電話で管理オペレーションをウォークスルー (walk-through) することがよく行われている。ユーザが介入することなく、ユーザのロケーションでリモートコンピュータを管理するように改善すると、さらに好都合である。

本発明は、このような問題に鑑みてなされたもので、その目的とするところは、コンピュータシステムの管理を改善することができる、データ転送を制限し分散コンピュータのソフトウェアコンポーネントを管理するためのシステムおよび方法を提供することにある。

以下では、共同ロケーション施設 (co-location facility) に置かれているサーバコンピュータのクラスタにおいて、データ転送を制限し、ソフトウェアコンポーネントを管理することが説明されている。

本発明の一態様によれば、コントローラ（”BMonitor”と名付けられている）はコンピュータ（例えば、共同ロケーション施設に置かれた各ノード）に置かれている。BMonitorは複数のフィルタを含み、共同ロケーション施設内の別のノードやインターネット経由でコンピュータに結合されたクライアントコンピュータなどのように、データをどことの間で送受信できるかがこれらのフィルタによって特定されるようになっている。これらのフィルタは、コンピュータのオペレーション期間に、コンピュータに結合された１つまたは複数の管理デバイス (management device) によって変更することが可能になっている。

別の態様によれば、”BMonitor”と名付けられたコントローラ（コンピュータに置かれている）は、そのコンピュータ上に存在するソフトウェアコンポーネントを管理している。要求が外部ソースからBMonitorによって受信されると、その要求はBMonitorによって実行される。この要求は、コンピュータと同じ場所に置かれている管理コンソールからでも、コンピュータから離れた場所に置かれている管理コンソールからでも、出すことが可能になっている。

別の態様によれば、”BMonitor”と名付けられたコントローラ（コンピュータに置かれている）は、複数の管理デバイス間のやりとりを仲介するトラステッドサードパーティ（trusted third party：第三者機関）の働きをしている。BMonitorは複数の所有権ドメイン (ownership domain) を維持しており、各ドメインは管理デバイスに対応づけられていると共に、各ドメインは、どのタイプの管理機能（function）をBMonitorに実行させることを指示できるかを示す、独自の権利セットをもっている。１つの所有権ドメインだけが、どの時点においてもトップレベルドメインになっており、このトップレベルドメインは、下位レベルのドメインよりも権利セットがさらに拡大されている。トップレベルドメインは、他の管理デバイスに対応づけられる、新しい所有権ドメインを作成することができ、また、トップレベルドメインを削除し、それに対応する管理デバイスの管理権を、下位レベル所有権ドメインに対応する管理デバイスによって、いつでも取り消すことが可能になっている。トップレベル所有権ドメインになっている所有権ドメインが変更されるたびに、コンピュータのシステムメモリは消去できるので、ある所有権ドメインからの機密情報が、他の所有権ドメインに対応するデバイスによって利用されることが防止されている。

別の態様によれば、BMonitorは、ノードで実行されている他のソフトウェアエンジン (software engine) よりも高い特権レベルで実行されるため、他のソフトウェアエンジンがBMonitorによって設定された制限に干渉するのを防止している。

以下には、添付図面を参照して本発明について説明されているが、本発明は以下の説明に限定されるものではない。また、図面全体を通して、類似のコンポーネントおよび/または機能は、同一符号を用いて示されている。

本発明によれば、本発明によれば、共同ロケーション施設に置かれているサーバコンピュータのクラスタにおいて、データ転送を制限し、ソフトウェアコンポーネントを管理することにより、コンピュータシステムの管理を効率よく行える。

以下、図面を参照して本発明の実施形態を詳細に説明する。なお、各図面において同様の機能を有する箇所には同一の符号を付し、説明の重複は省略する。

図１は、本発明のいくつかの実施形態で使用できるような、クライアント/サーバネットワークシステムと環境を示す図である。一般的に、システムは、１つまたは複数（n個）のクライアントコンピュータ１０２１〜１０２ｎと、各々が複数のサーバコンピュータのクラスタ（サーバクラスタ）１０６１−１、１０６１−２、１０６ｍ−１、１０６ｍ−２を含んでいる１つまたは複数（m個）の共同ロケーション施設１０４１〜１０４ｍと、１つまたは複数の管理デバイス１１０と、１つまたは複数の別設（例えば、共同ロケーション施設に含まれていない）サーバ１１２とを含んでいる。これらのサーバ、クライアントコンピュータ、および管理デバイスは、データ通信ネットワーク１０８を通して相互に通信している。図１の通信ネットワークは、インターネットのような公衆ネットワーク１０８を含んでいる。インターネットに加えて、あるいはその代用として、他のタイプの通信ネットワークを使用することも可能であり、その中には、ローカルエリアネットワーク (local area network LAN)、広域ネットワーク (wide area network WAN) などが含まれている。データ通信ネットワーク１０８の構築は、さまざまな方法で行うことが可能であり、その中には、ワイヤード（有線）および/またはワイヤレス（無線）通信媒体が含まれている。

ネットワーク１０８を利用した通信を行うには、広範囲にわたる通信プロトコルの使用が可能である。ある実装では、クライアントコンピュータ１０２１〜１０２ｎとクラスタ１０６１−２、１０６ｍ−１、１０６ｍ−２内のサーバコンピュータは、ハイパーテキスト転送プロトコル (Hypertext Transfer Protocol HTTP) を使用して相互に通信することが可能になっており、そこでは、Webページはサーバコンピュータによってホストされ、HTML(Hypertext Markup Language)またはXML(eXtensible Markup Language)などの、マークアップ言語で書かれている。

管理デバイス１１０は、デバイス１１０から離れたロケーションに置かれている１つまたは複数のコンピューティングデバイスのソフトウェアコンポーネントを管理する働きをする。この管理の中には、管理されるコンピューティングデバイスとの間でやりとりされるデータ転送を制限することを含めることも可能である。図１に示す例では、管理デバイス１１０は、クライアント１０２１〜１０２ｎ、サーバクラスタ１０６１−１、１０６１−２、１０６ｍ−１、１０６ｍ−２、またはサーバ１１２の、１つまたは複数をリモートで管理することが可能になっている。リモートで管理できるコンピューティングデバイスは広範囲にわたっており、その中には、パーソナルコンピュータ (personal computer PC)、ネットワークPC、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラマブルな家庭用電化製品、ミニコンピュータ、メインフレームコンピュータ、ゲーミングコンソール (gaming console)、インターネット機器、パーソナルデジタルアシスタント (personal digital assistant PDA)、ポケットコンピュータ、パームサイズ (palm-sized) コンピュータ、ハンドヘルドコンピュータ、デジタルセルラーホン (digital cellular phone)、などが含まれている。コンピューティングデバイスのリモート管理は、以下に詳しく説明されているように、コマンドをネットワーク１０８経由でデバイスに伝達することによって行われる。

以下の説明では、本発明の実施形態は、プログラムモジュールのように、１つまたは複数の従来パーソナルコンピュータによって実行されるコンピュータ実行可能命令の一般的意味において説明されている。一般的に、プログラムモジュールには、特定のタスクを実行し、あるいは特定の抽象データ型を実装している、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれている。さらに、当業者ならば理解されるように、本発明の種々実施形態は、他のコンピュータシステム構成で実施することが可能であり、その中には、ハンドヘルドデバイス、ゲーミングコンソール (gaming console)、インターネットアプライアンス (Internet appliance)、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラマブルな家庭用電化製品、ネットワークPC、ミニコンピュータ、メインフレームコンピュータなどが含まれている。分散コンピュータ環境では、プログラムモジュールは、ローカルとリモートの両方のメモリストレージデバイスに置いておくことが可能になっている。

別の方法として、本発明の実施形態は、ハードウェアで実現することも、ハードウェア、ソフトウェア、および/またはファームウェアの組み合わせで実現することもできる。例えば、本発明は、その全体または一部を１つまたは複数の特定用途向け集積回路 (application specific integrated circuit ASIC) またはプログラム可能論理デバイス (programmable logic device PLD) に実装させることが可能になっている。

図２は、本発明のいくつかの実施形態に従って使用できるコンピュータ１４２の例を示す概要図である。図示のコンピュータ１４２の例としては、図１のクライアントコンピュータ１０２１〜１０２ｎとしての機能をもつコンピュータ、図１の共同ロケーション施設１０４１〜１０４ｍや他のロケーションに置かれているコンピュータやノード（例えば、以下に説明する図５のノード２４８）、あるいはローカルまたはリモート管理コンソールがあり、これらは、以下に詳しく説明されている。

コンピュータ１４２は、１つまたは複数のプロセッサまたは処理ユニット１４４、システムメモリ１４６、およびシステムメモリ１４６を含む種々のシステムコンポーネントをプロセッサ１４４に結合しているバス１４８を含んでいる。バス１４８は、数種タイプのバス構造のいずれかの１つまたは複数を表しており、その中には、種々のバスアーキテクチャのいずれかを採用しているメモリバスまたはメモリコントローラ、ペリフェラル（周辺）バス、高速グラフィックスポート、およびプロセッサまたはローカルバスが含まれている。システムメモリとしては、リードオンリメモリ (read only memory ROM) １５０とランダムアクセスメモリ (random access memory RAM) １５２がある。基本入出力システム (basic input/output system BIOS) １５４は、スタートアップ中のように、コンピュータ１４２内の要素間で情報を転送するのを支援する基本ルーチンで構成され、ROM １５０に格納されている。

コンピュータ１４２は、さらに、ハードディスク（図示せず）との間で読み書きを行い、ハードディスクドライブインタフェース１５７（例えば、SCSI、ATA、他のタイプのインタフェース）を介してバス１４８に接続されているハードディスクドライブ１５６、リムーバル磁気ディスク１６０との間で読み書きを行い、磁気ディスクドライブインタフェース１６１を介してバス１４８に接続されている磁気ディスクドライブ１５８、およびCD-ROMやDVD、その他の光メディアなどの、リムーバル光ディスク１６４との間で読み書きを行い、光ドライブインタフェース１６５を介してバス１４８に接続されている光ディスクドライブ１６２を装備している。これらのドライブおよびそれぞれに関連するコンピュータ読取可能媒体は不揮発性ストレージとして、コンピュータ１４２のためのコンピュータ読取可能命令、データ構造、プログラムモジュールおよび他のデータを格納している。ここで説明している例示環境では、ハードディスク、リムーバル磁気ディスク１６０およびリムーバル光ディスク１６４が採用されているが、当業者ならば理解されるように、コンピュータによってアクセス可能なデータを格納しておくことができる他のタイプのコンピュータ読取可能媒体を、例示動作環境で使用することも可能であり、そのようなものとしては、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ランダムアクセスメモリ (RAM)、リードオンリメモリ (ROM) などがある。

いくつかのプログラムモジュールは、ハードディスク、磁気ディスク１６０、光ディスク１６４、ROM １５０またはRAM １５２に格納しておくことが可能であり、その中には、オペレーティングシステム１７０ａ、１７０ｂ、１つまたは複数のアプリケーションプログラム１７２ａ、１７２ｂ、他のプログラムモジュール１７４ａ、１７４ｂ、およびプログラムデータ１７６ａ、１７６ｂが含まれている。ユーザは、キーボード１７８やポインティングデバイス１８０などの、入力デバイスを通してコマンドと情報をコンピュータ１４２に入力することができる。他の入力デバイス（図示せず）としては、マイクロホン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナなどがある。上記および他の入力デバイスは、システムバスに結合されているインタフェース１６８を介して処理ユニット１４４に接続されている。モニタ１８４や他のタイプのディスプレイデバイスも、ビデオアダプタ１８６のような、インタフェースを介してシステムバス１４８に接続されている。モニタのほかに、パーソナルコンピュータは、スピーカやプリンタのような、他のペリフェラル（周辺）出力デバイス（図示せず）を装備しているのが代表的である。

コンピュータ１４２は、オプションとして、リモートコンピュータ１８８のような、１つまたは複数のリモートコンピュータとの論理コネクションを使用するネットワーキング環境で動作している。リモートコンピュータ１８８は、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークPC、ピアデバイス（peer device）または他の共通ネットワークノードにすることが可能であり、図２にはメモリストレージデバイス１９０だけが示されているが、コンピュータ１４２に関連して上述した要素の多くまたは全部を含んでいるのが代表的である。図２に示す論理コネクションとしては、ローカルエリアネットワーク (LAN) １９２と広域ネットワーク (WAN) １９４がある。このようなネットワーキング環境は、オフィス、企業内 (enterprise-wide) コンピュータネットワーク、イントラネット (intranet)、およびインターネットで普及している。ここで説明している本発明の実施形態では、リモートコンピュータ１８８は、Microsoft Corporation (Redmond, Washington州) で製造され、販売されている”Internet Explorer” Webブラウザなどの、インターネットWebブラウザプログラム（これは、オプションとして、オペレーティングシステムに組み込まれていることもある）を実行している。

LANネットワーキング環境で使用されるときは、コンピュータ１４２は、ネットワークインタフェースまたはアダプタ１９６を通してローカルネットワーク１９２に接続されている。WANネットワーキング環境で使用されるときは、コンピュータ１４２は、インターネットなどの広域ネットワーク１９４上の通信を確立するためのモデム１９８や他のコンポーネントを装備しているのが代表的である。モデム１９８は内蔵型と外付け型があり、どちらも、インタフェース（例えば、シリアルポートインタフェース１６８）を介してシステムバス１４８に接続されている。ネットワーキング環境では、パーソナルコンピュータ１４２に関連して上述したプログラムモジュールまたはその一部は、リモートメモリストレージデバイスに格納しておくことができる。以上から理解されるように、図示のネットワークコネクションは例示であり、コンピュータ間の通信リンクを確立する他の手段を使用することも可能である。

一般的に、コンピュータ１４２のデータプロセッサは、コンピュータの種々のコンピュータ読取可能媒体に時期を異にして格納されている命令によってプログラムされている。プログラムとオペレーティングシステムは、例えば、フロッピー（登録商標）ディスクやCD-ROMに入れて配布されるのが代表的である。これらは、そこからインストールされ又は、コンピュータの二次メモリ (secondary memory) にロードされる。実行時に、これらは、少なくともその一部が、コンピュータの一次電子メモリ (primary electronic memory) にロードされている。ここで説明している本発明によれば、マイクロプロセッサまたは他のデータプロセッサと関連付けて以下に説明されているステップを実現するための命令またはプログラムは、上記および他のタイプのコンピュータ読取可能ストレージ媒体に収められている。また、本発明によれば、コンピュータ自体が、後述する方法と手法に従ってプログラムされるようになっている。さらに、コンピュータのある種のサブコンポーネントは、後述する機能とステップを実行するようにプログラム可能になっている。本発明によれば、そのようなサブコンポーネントは下述するようにプログラムされるようになっている。さらに、ここで説明している本発明によれば、データ構造は、下述するように、種々タイプのメモリ媒体上に具現化されている。

説明の便宜上、プログラムおよびオぺレーティングシステムのような他の実行可能プログラムコンポーネントは、ここでは個別的ブロックとして示されているが、当然に理解されるように、このようなプログラムとコンポーネントは、時期を異にしてコンピュータの異なるストレージコンポーネントに置かれていて、コンピュータのデータプロセッサによって実行されるようになっている。

図３は、例示の共同ロケーション施設を示す詳細ブロック図である。共同ロケーション施設１０４は、図示のように複数のノード２１０−１〜２１０−ｎ（サーバコンピュータとも呼ばれる）を含んでいる。共同ロケーション施設１０４は、ノードをいくつでも収容することが可能であり、数千にもわたる数のノードを容易に収容することが可能になっている。

ノードは、サーバクラスタ（またはノードクラスタ）と呼ばれる、いくつかのクラスタにグループ化されている。説明を簡単にし、図面の混乱を避けるために、図３にはただ１つのクラスタ２１２だけが示されている。各サーバクラスタは、共同ロケーション施設１０４の特定カスタマに対応するノードを含んでいる。あるサーバクラスタのノードは、他のサーバクラスタのノードから物理的に隔離されている。この物理的隔離は、共同ロケーション施設１０４でのロックされた個別ケージや個別ルームのように、異なる形体にすることができる。サーバクラスタを物理的に隔離すると、共同ロケーション施設１０４のカスタマは、自分だけが自分のノードに物理的にアクセスできることが保証される（他のカスタマはアクセスできない）。別の方法として、サーバクラスタは、相互に対して物理的にではなく、論理的に隔離することも可能である（例えば、以下で詳しく説明するクラスタ境界を使用して）。

ランドロード/テナント関係（貸主/借主 (lessor/lessee) 関係とも呼ばれる）は、ノードをベースにして設定することも可能である。共同ロケーション施設１０４の所有者（および/またはオペレータ）は、個々のノードを所有している（さもなければ、その権利を有している）ので、「ランドロード」と見ることができる。共同ロケーション施設１０４のカスタマは、ランドロードからノードをリースするので、「テナント」と見ることができる。ランドロードは、どのタイプのデータまたはプログラムがテナントによってノードにストアされているかには無関心であるのが一般的であるが、クラスタに境界を設けて、異なるクラスタからのノードが、相互に通信するのを防止するようにしている。これについては、以下に詳しく説明されている。さらに、ノードを使用すると、テナントは、そのノードがテナントだけにリースされるとしても、ランドロードがテナントによってストアされた機密情報にアクセスできないとの保証が得られる。

異なるクラスタのノードは、物理的に隔離されていても、ネットワークコネクション（１つまたは複数）２１６へのアクセス、場合によっては、アプリケーションオペレーション管理コンソール２４２へのアクセスを可能にする、同じトランスポート媒体（１つまたは複数）２１１に物理的に結合されていることがよくある。これについては、以下に詳しく説明されている。このトランスポート媒体はワイヤド（有線）またはワイヤレス（無線）にすることができる。

各ノードは、共有トランスポート媒体２１１に結合できるので、各ノードは、他のどのノードとの間でデータを送受信できるかを制限するように構成可能になっている。いくつかの異なるノードをテナントのサーバクラスタに含めることが可能になっていれば、テナントは、そのクラスタ内の異なるクラスタの間でデータを、処理や保管などの目的のために、受け渡しできることを望む場合がある。しかし、テナントは、サーバクラスタに属していない他のノードにデータが渡されるのを望まないのが一般的である。他のどのノードとの間でデータを送受信できるかを制限するようにクラスタ内の各ノードを構成すると、サーバクラスタの境界を設定し、適用することが可能になる。このようなサーバクラスタ境界を設定し、適用すると、テナントのデータがクラスタに属していないノードに誤って、あるいは不正に転送されることが防止される。

ランドロードによって設定される、これらの初期境界は、異なるカスタマのノード間の通信を防止するので、各カスタマのデータがそのカスタマの他のノードに渡されることが保証されることになる。カスタマ自身も、そのクラスタ内にサブ境界を別に定義し、ノードのサブクラスタを設定すると、そこから出入りするデータが、クラスタ内の他のノードとの間で受け渡しされることが防止される。カスタマは、そのようなサブクラスタ境界を自由に追加し、変更し、削除し、その他を行うことができるが、それが許されるのは、ランドロードによって定義された境界（つまり、クラスタ境界）内に限られている。従って、カスタマは、ノードとの間で行われる通信が、同じクラスタに属していない別のノードにまで拡張されるような形で境界を変更することはできない。

共同ロケーション施設１０４は、ノードノード２１０−１〜２１０−ｎの各々に対して高信頼電源２１４と高信頼ネットワークコネクション（１つまたは複数−以下同じ）２１６（例えば、図１のネットワーク１０８）を提供している。電源２１４とネットワークコネクション２１６はノードノード２１０−１〜２１０−ｎのすべてによって共有されているが、別の方法として、ノードノード２１０−１〜２１０−ｎまたはノードグループ（例えば、クラスタ）に別の電源２１４とネットワークコネクション２１６を提供することも可能である。高信頼電源を提供するための広範囲にわたる、従来のメカニズムは、いずれも、電源障害（停電）時のバックアップ発電機、冗長発電機、バッテリ、燃料電池、あるいは他の蓄電メカニズムと併用して、電力会社から供給される電力のような、高信頼電源２１４を提供するために使用することができる。同様に、高信頼ネットワークコネクションを提供するための広範囲にわたる、従来のメカニズムは、いずれも、冗長コネクショントランスポート媒体、異種のコネクション媒体、異なるアクセスポイント（例えば、異なるインターネットアクセスポイント、異なるインターネットサービスプロバイダ (Internet service provider ISP) など）などの、ネットワークコネクション２１６を提供するために使用することができる。

いくつかの実施形態では、ノードノード２１０−１〜２１０−ｎは、共同ロケーション施設１０４のオペレータまたは所有者によって、施設１０４のスペースおよびサービス（例えば、高信頼電源２１４とネットワークコネクション２１６）と一緒にカスタマにリースまたは販売されている。他の実施形態では、施設１０４のスペースとサービスはカスタマにリースされる一方、１つまたは複数のノードはカスタマによって用意されるようになっている。

各ノードノード２１０−１〜２１０−ｎの管理は多層方式で行われる。図４は、例示の多層管理アーキテクチャを示すブロック図である。この多層アーキテクチャは３層からなっている。すなわち、クラスタオペレーション管理層２３０、アプリケーションオペレーション管理層２３２、およびアプリケーション開発層２３４である。クラスタオペレーション管理層２３０は、管理されるサーバ（１つまたは複数−以下同じ）と同じロケーションに（例えば、共同ロケーション施設に）ローカルに実装され、サーバのハードウェアオペレーションを管理することを担当している。図示の例では、クラスタオペレーション管理層２３０は、どのソフトウェアコンポーネントがノードノード２１０−１〜２１０−ｎで実行されているかには無関係であり、関係があるのは、ノードノード２１０−１〜２１０−ｎのハードウェアオペレーションを継続することと、ノードクラスタ間に境界を設定することだけである。

これに対して、アプリケーションオペレーション管理層２３２は、管理されるサーバが置かれている場所とは別の（例えば、共同ロケーション施設とは別の）リモートロケーションにあって、サーバに結合されていてまだ通信状態にあるクライアントコンピュータのロケーションに実装されている。アプリケーションオペレーション管理層２３２は、サーバのソフトウェアオペレーションを管理し、サーバクラスタ内にサブ境界を定義することを担当している。クライアントをサーバに結合するには、インターネット経由や専用（例えば、ダイヤルアップ）コネクション経由といったように、さまざまな方法で行うことが可能になっている。また、クライアントは、サーバに結合したままにしておくことも、不定期に（例えば、管理目的のための必要時のみ）結合することも可能である。

アプリケーション開発層２３４は、サーバとは別のロケーション（例えば、共同ロケーション施設とは別のロケーション）に置かれている、別のクライアントコンピュータに実装されており、サーバ上で実行されるソフトウェアコンポーネントまたはエンジンを開発することを担当している。別の方法として、共同ロケーション施設１０４のノードノード２１０−１〜２１０−ｎに置かれているカレントソフトウェアにリモートクライアントがアクセスすることによって、ノードのための追加ソフトウェアコンポーネントやエンジンを開発することも可能である。アプリケーション開発層２３４が実装されているクライアントは、アプリケーションオペレーション管理層２３２が実装されているクライアントとは別のクライアントであるのが一般的であるが、これらの２層２３２と２３４は、同じクライアントに（少なくとも部分的に）実装させることも可能である。

図４には３層だけが示されているが、これとは別に、多層アーキテクチャは異なる数の層で構成することも可能である。例えば、アプリケーションオペレーション管理層を２層に分割し、各層に異なる（またはオーバラップする）責任をもたせれば、結果的に、４層のアーキテクチャが得られることになる。これらの層での管理は、同じ場所（例えば、単独のアプリケーション管理コンソールを共用にする）からでも、異なる場所（例えば、２つの異なるオペレーション管理コンソール）からでも行うことができる。

図３に戻って説明すると、共同ロケーション施設１０４は、各サーバクラスタのためのクラスタオペレーション管理コンソールを含んでいる。図３の例では、クラスタオペレーション管理コンソール２４０はクラスタ２１２に対応付けられている。クラスタオペレーション管理コンソール２４０はクラスタ２１２のためのクラスタオペレーション管理層２３０（図４）を実装しており、クラスタ２１２内のノードのハードウェアオペレーションを管理することを担当している。クラスタオペレーション管理コンソール２４０はクラスタ２１２内のハードウェアをモニタリングし、ハードウェア障害を判別することを試みている。広範囲にわたる、どのようなハードウェア障害でもモニタリングすることが可能であり、その中には、プロセッサ障害、バス障害、メモリ障害などが含まれている。ハードウェアオペレーションをモニタリングする方法は、クラスタオペレーション管理コンソール２４０が、応答するように特定のハードウェアの使用を要求するテストメッセージや制御シグナルをノードへ送信するとか（無応答または誤りのある応答は障害が起きたことを示している）、特定のハードウェアの使用を要求するテストメッセージや制御シグナルを生成させ、ノードからクラスタオペレーション管理コンソール２４０へ定期的に送信させるとか（特定の時間期間内にこのメッセージまたは制御シグナルを受信しないときは、障害が起きたことを示している）、といったように、種々の方法が可能である。別の方法として、クラスタオペレーション管理コンソール２４０は、どのタイプのハードウェア障害が発生したかを判別することを試みるのではなく、障害が起きたことだけを判別するようにすることもできる。

ハードウェア障害が検出されると、クラスタオペレーション管理コンソール２４０は、その障害を訂正するように働く。クラスタオペレーション管理コンソール２４０が取るアクションは、ハードウェアだけでなく、障害のタイプによっても異なることがあり、また、サーバクラスタが異なると異なることもある。訂正アクションとしては、アドミニストレータに通知すること（例えば、ライトの点滅、オーディオアラーム、電子メールメッセージ、セルホンまたはページャのコール、など）、問題を物理的に訂正することを試みること（例えば、ノードをリブートする、障害を起こしたノードの代わりに別のバックアップノードを起動する、など）がある。

クラスタオペレーション管理コンソール２４０は、共同ロケーション施設１０４内にクラスタ境界も設定する。コンソール２４０によって設定されたクラスタ境界は、あるクラスタ（例えば、クラスタ２１２）内のノード２１０−３が、別のクラスタ（例えば、クラスタ２１２に属さないクラスタ）と通信するのを防止し、他方では、これと同時に、クラスタ内のノード２１０−３がそのクラスタ内の他のノードと通信する能力を妨げないようにする。これらの境界によると、テナントは、ネットワークコネクション２１６がテナントによって共有されている場合であっても、施設１０４に置かれた他のテナントのノードに自分のデータを伝達できないことを知ることができるので、テナントのデータのセキュリティが得られることになる。

図示の例では、共同ロケーション施設１０４の各クラスタは、専用クラスタオペレーション管理コンソールを含んでいる。別の方法として、単独のクラスタオペレーション管理コンソールを複数のサーバクラスタに対応付けて、そのハードウェアオペレーションを管理させることも可能である。別の代替方法によれば、複数のクラスタオペレーション管理コンソールを単独のサーバクラスタに対応付けて、そのハードウェアオペレーションを管理させることも可能である。このような複数コンソールに単独のサーバクラスタを、共有方式で管理させることも、１つのコンソールを、別のコンソールのバックアップとして動作させることもできる（例えば、冗長性をもたせると信頼性が向上するので、保守などが容易化される）。

アプリケーションオペレーション管理コンソール２４２も、共同ロケーション施設１０４に結合され、通信状態に置かれている。アプリケーションオペレーション管理コンソール２４２は、共同ロケーション施設１０４から離れたロケーションに置かれている（つまり、共同ロケーション施設１０４内ではなく、カスタマのオフィスに置かれているのが代表的である）。共同ロケーション施設１０４の各々のサーバクラスタに異なるアプリケーションオペレーション管理コンソール２４２を対応付けることができるが、別の方法として、単独のサーバクラスタに複数のコンソール２４２を対応付けることも、複数のサーバクラスタに単独のコンソール２４２を対応付けることも可能である。アプリケーションオペレーション管理コンソール２４２は、クラスタ２１２のためのアプリケーションオペレーション管理層２３２（図４）を実装しており、クラスタ２１２内のソフトウェアオペレーションを管理するだけでなく、クラスタ２１２内のサブ境界をセキュアにすることも担当している。

アプリケーションオペレーション管理コンソール２４２はクラスタ２１２内のソフトウェアをモニタリングしており、ソフトウェア障害を判別することを試みている。広範囲にわたるソフトウェア障害をモニタリングすることが可能であり、例えば、「ハングアップした」または無応答のアプリケーションプロセスまたはスレッド、アプリケーションプロセスまたはスレッドの実行時エラーなどの、ソフトウェア障害をモニタリングすることができる。ソフトウェアオペレーションのモニタリング方法はさまざまな方法が可能であり（上述したハードウェアオペレーションのモニタリングと同様である）、例えば、アプリケーションオペレーション管理コンソール２４２が、応答するように特定のルーチンの使用を要求するテストメッセージや制御シグナルをノード上で実行中の特定プロセスまたはスレッドに送信する（無応答または誤った応答は障害が起きたことを示している）。または、特定ソフトウェアルーチンの使用を要求するメッセージや制御シグナルを生成させ、ノード上で実行中のプロセスまたはスレッドからアプリケーションオペレーション管理コンソール２４２に定期的に送信させるとか（このようなメッセージや制御シグナルを特定時間の期間内に受け取らなかったときは、障害が起きたことを示している）、といった方法が可能である。別の方法として、アプリケーションオペレーション管理コンソール２４２は、どのタイプのソフトウェア障害が発生したかを判別する試みを行うのではなく、障害が発生したことだけを判別するようにすることもできる。

ソフトウェア障害が検出されると、アプリケーションオペレーション管理コンソール２４２は、その障害を訂正するように働く。アプリケーションオペレーション管理コンソール２４２が取るアクションは、ソフトウェアだけでなく、障害のタイプによっても異なることがあり、また、サーバクラスタが異なると異なることもある。訂正アクションとしては、アドミニストレータに通知すること（例えば、ライトの点滅、オーディオアラーム、電子メールメッセージ、セルホンまたはページャのコール、など）、問題を訂正することを試みること（例えば、ノードをリブートする、ソフトウェアコンポーネントまたはエンジンのイメージを再ロードする、プロセスを終了した後再実行する、など）がある。

従って、ノード２１０−１〜２１０−ｎの管理は、ノードと同一ロケーションに置かれている他のノード（存在する場合）の数に関係なく、複数のマネージャに分散化されている。この多層管理によると、ハードウェアオペレーション管理はアプリケーションオペレーション管理から分離されるので、ノードに対する管理責任を、２つの異なるコンソール（各々は異なるエンティティの制御下に置かれている）に分担させることが可能になる。

図５は、本発明のいくつかの実施形態による、リモートで管理される例示ノードを示す詳細ブロック図である。ノード２４８は、共同ロケーション施設のノード２１０−１〜２１０−ｎにすることも、別設のデバイス（例えば、図１のクライアント１０２−１〜１０２−ｎまたはサーバ１１２）にすることも可能である。ノード２４８は、”BMonitor”と呼ばれるモニタ２５０、および複数のソフトウェアコンポーネントまたはエンジン２５２を含み、大容量ストレージデバイス２６２に結合されている（大容量ストレージデバイスを内蔵している場合もある）。図示の例では、ノード２４８は、複数の特権レベル (privilege level)（例えば、x86アーキテクチャプロセッサにおけるリング）をサポートするプロセッサ（１または複数）を搭載したコンピューティングデバイスになっている。図示の例では、これらの特権レベルはリング (ring) と呼ばれているが、異なるプロセッサアーキテクチャを採用している別の実装では、別の用語が用いられている場合がある。この複数リングによれば、１組の優先レベル (prioritized level) が用意され、ソフトウェアがその優先レベルで実行されるようになっている。なお、優先レベルは４レベル（リング0, 1, 2, 3）になっていることが多い。リング0は、最大特権リングと呼ばれるのが代表的である。リング0で実行されるソフトウェアプロセスは、特権の低いリングで実行されるプロセスよりも、アクセスできる機能（例えば、命令）が多くなっているのが代表的である。さらに、特定のリングで実行されているプロセッサは、優先度の高いリングのコードやデータを変更することができない。図示の例では、BMonitor ２５０はリング0で実行されるのに対し、エンジン２５２はリング1（またはリング２および/または3）で実行されている。従って、BMonitor２５０（リング0で実行されている）のコードまたはデータは、エンジン２５２（リング1で実行されている）によって直接に変更することができない。むしろ、このような変更は、エンジン２５２がBMonitor２５０に変更を依頼することによって（例えば、BMonitor２５０にメッセージを送るとか、BMonitor２５０の関数を呼び出すとか、といった方法で）行われる必要がある。BMonitor２５０をリング0で実装すると、BMonitor２５０は、BMonitor２５０によって課されている制限をバイパスしようとする統制されていないあるいは悪意のあるエンジン２５２から保護されることになる。

別の方法として、BMonitor２５０は、統制されていないあるいは悪意のあるエンジン２５２からBMonitor２５０を保護する、他の方法で実装することも可能である。例えば、ノード２４８は、１つはエンジン２５２を実行するためのプロセッサ、もう１つはBMonitor２５０を実行するためのプロセッサといったように、複数のプロセッサを含むことができる。エンジン２５２が実行されているプロセッサとは別のプロセッサでBMonitor２５０だけを実行させるようにすると、BMonitor２５０をエンジン２５２から効果的にシールドすることが可能になる。

BMonitor２５０は、ノード２４８の基本的制御モジュールである。つまり、これは、ネットワークインタフェースカードとメモリマネージャの両方を制御している（オプションとして、内蔵している場合もある）。ネットワークインタフェースカード（これは、BMonitor２５０とは別になっていることもあれば、BMonitor２５０がネットワークインタフェースカードに内蔵されていることもある）を制御すると、BMonitor２５０は、ノード２４８との間で送受されるデータを制御することができる。メモリマネージャを制御すると、BMonitor２５０は、ノード２４８で実行されているエンジン２５２に対するメモリの割り振りを制御できるので、統制されていないあるいは悪意のあるエンジンがBMonitor２５０のオペレーションに干渉するのを防止することができる。

ノード２４８の種々の態様がBMonitor２５０（例えば、ネットワークインタフェースカード）の制御下に置かれていることがあっても、BMonitor２５０は、その機能の少なくとも一部を、ノード２４８で実行されているエンジン２５２が利用できるようにしている。BMonitor２５０は、データを別のノード２４８やインターネットに送出するといったように、エンジン２５２がそこから機能へのアクセスを要求できるようにするインタフェースとなっている（例えば、以下で詳しく説明するコントローラ２５４を通して）。これらの要求は、メッセージを送信する、関数をコールする、といったように、さまざまな形体にすることができる。

BMonitor２５０は、コントローラ２５４、ネットワークインタフェース２５６、１つまたは複数のフィルタ２５８、１つまたは複数の鍵２５９、およびBMonitor２５０制御プロトコル (BMonitor Control Protocol BMCP) モジュール２６０を含んでいる。ネットワークインタフェース２５６は、ノード２４８とネットワーク（例えば、図１のネットワーク１０８）とを結ぶインタフェースとなっている。共同ロケーション施設に置かれた他の、どのノード（および/または他のソース）またはターゲット（例えば、図１のインターネット１０８に結合されている）との間でデータを送受信できるか（あるいは送受信できないか）は、フィルタ２５８によって判別される。これらのノードまたは他のソース/ターゲットを判別するには、ネットワークアドレス（例えば、インターネットプロトコル (Internet Protocol IP) アドレス）、ある種のグローバルにユニークな識別子 (ID)、ローカルにユニークな識別子（例えば、共同ロケーション施設１０４が所有するまたは独自の番号付け方式）といった、さまざまな方法で行うことが可能である。

フィルタ２５８は、ノードへのアクセスを完全に制限することも（例えば、ノードとの間でデータの送受信ができない）、ノードへのアクセスを部分的に制限することもできる。部分的アクセス制限は、さまざまな形体にすることができる。例えば、ノードからデータを受信できるが、ノードには送信できない（またはその逆）、といったようにノードを制限することができる。別の例として、あるタイプのデータ（例えば、HTTPなどの、ある種のプロトコルに準拠する通信）だけが、ノードとの間で送信および/または受信できるようにノードを制限することもできる。特定タイプのデータに基づくフィルタリングをどのように実装するかは、データをパケットに入れ、そのパケットに含まれるデータのタイプを示すヘッダ情報と一緒にデータを伝達するといった、さまざまな方法が可能である。

フィルタ２５８は、図１の１つまたは複数の管理デバイス１１０によっても、あるいは図３のアプリケーションオペレーション管理コンソール２４２またはクラスタオペレーション管理コンソール２４０のどちらかによっても、追加することができる。図示の例では、クラスタオペレーション管理コンソール２４０によって追加されたフィルタ（クラスタ境界を設定するために）は、ノードへの完全アクセスを制限しているのに対し（例えば、別のノードへのアクセスはすべてが禁止される）、アプリケーションオペレーション管理コンソール２４２によって（クラスタ内にサブ境界を設定するために）または管理デバイス１１０によって追加されたフィルタは、ノードへの完全アクセスまたは部分的アクセスのどちらかを制限することが可能になっている。

コントローラ２５４も、どのフィルタをフィルタ２５８に追加できるかに対していくつかの制限を設けている。図３と４に示す多層管理アーキテクチャでは、コントローラ２５４は、クラスタオペレーション管理コンソール２４０が、必要とするどのフィルタでも追加できるようにしている（これにより、クラスタの境界が定義される）。他方、コントローラ２５４は、少なくともその制限度が、コンソール２４０によって追加されたフィルタと同じであるフィルタだけを、アプリケーションオペレーション管理コンソール２４２が追加することに制限している。コンソール２４２が、コンソール２４０によって追加されたフィルタより制限度の低いフィルタを追加しようとすると（その場合には、サブ境界はクラスタ境界を越えることになる）、コントローラ２５４は、そのフィルタを追加することを拒否する（別の方法として、制限度が低くならないようにフィルタを修正することも可能である）。このような制限を設けると、コントローラ２５４は、アプリケーションオペレーション管理レベルで設定されたサブ境界が、クラスタオペレーション管理レベルで設定されたクラスタ境界を越えるのを防止することができる。

コントローラ２５４は、１つまたは複数のフィルタ２５８を使用して、ノード２４８から送信されるおよび/またはノード２４８によって受信されるデータパケットを制限するように動作する。あるエンジン２５２を目的としたデータ、またはエンジン２５２から別のノードに送られるデータは、すべてがネットワークインタフェ−ス２５６とフィルタ２５８を経由して渡される。コントローラ２５４はデータにフィルタ２５８を適用し、データのターゲット（例えば、そのデータを収めているパケットのヘッダ部分に指定されているのが代表的）を、フィルタ２５８に指定されている許容された（および/または制限された）ノード（および/またはネットワークアドレス）と比較する。データのターゲットが許容されていることをフィルタ２５８が示していれば、コントローラ２５４は、データがターゲットに渡されること（ノード２４８に送り込まれるか、あるいはノード２４８から送出されること）を許可する。他方、データのターゲットが許容されないことをフィルタ２５８が示していれば、コントローラ２５４は、データがターゲットに渡されるのを禁止する。コントローラ２５４は、データをターゲットに渡すことができないとの通知をデータのソース（送信元）に戻すこともあれば、データを無視または破棄するだけのこともある。

コントローラ２５４によってフィルタ２５８をデータに適用すると、サーバクラスタ（図３）の境界に制限を設けることが可能になる。フィルタ２５８は、サーバクラスタ（例えば、クラスタ２１２）内の全ノードのノードアドレスを使用してプログラムすることができる（例えば、図３のアプリケーションオペレーション管理コンソール２４２によって）。このようにすると、コントローラ２５４は、サーバクラスタに属していないノードから受信されたデータが、エンジン２５２に渡されるのを防止し、同様に、サーバクラスタ内のノードとは別のノードへ送られるデータが送信されるのを防止する。同様に、インターネット１０８（図１）から受信されたデータはターゲットノード２４８を特定できるので（例えば、IPアドレスによって）、ターゲットノードとは別のノードのコントローラ２５４は、データがエンジン２５２に渡されるのを防止することになる。さらに、フィルタ２５８はクラスタオペレーション管理コンソール２４０によって容易に修正を加えることができるので、サーバクラスタ境界は、サーバクラスタでの変更を受け入れるように容易に変更することができる（例えば、ノードをサーバクラスタに追加することおよび/またはサーバクラスタからノードを除去すること）。

BMCPモジュール２６０は分散ホスト制御プロトコル (Distributed Host Control Protocol DHCP) を実装しているので、BMonitor２５０（従って、ノード２４８）がDHCPサーバ（例えば、図３のクラスタオペレーション管理コンソール２４０）からIPアドレスを取得することを可能にしている。ノード２４８の初期化プロセス期間に、BMCPモジュール２６０は、DHCPサーバにIPアドレスを要求し、この要求を受けて、DHCPサーバはIPアドレスをモジュール２６０に与える。DHCPに関する詳細情報は、Microsoft Corporation (Redmond, Washington州) から入手することができる。

ソフトウェアエンジン２５２は、広範囲にわたる従来のソフトウェアコンポーネントのどれかを含んでいる。エンジン２５２の例としては、オペレーティングシステム（例えば、Windows（登録商標） NT）、ロードバランシング (load balancing) サーバコンポーネント（例えば、複数ノード２４８の処理負荷を平衡化する）、キャッシングサーバコンポーネント（例えば、別のノード２４８からの、またはインターネット経由で受信したデータおよび/または命令をキャッシュする）、ストレージマネージャコンポーネント（例えば、別のノード２４８からの、またはインターネット経由で受信したデータのストレージを管理する）、などがある。ある実装では、エンジン２５２の各々はプロトコルベースのエンジンであるので、エンジン２５２およびBMonitor２５０が同じプログラミング言語で書かれていなくても、メッセージおよび/または関数コールを通して、BMonitor２５０および他のエンジン２５２と通信する。

コントローラ２５４はローダ２６４と併用されて、エンジン２５２の実行を制御することを担当している。この制御は、エンジン２５２の実行開始または起動、エンジン２５２の実行終了、ストレージデバイスからのエンジン２５２のイメージの再ロード、エンジン２５２の実行のデバッグ、などのように、さまざまな形体にすることができる。コントローラ２５４は、これらの制御アクションのどれをとるか、その制御アクションをいつとるか、に関する指示を、図３のアプリケーションオペレーション管理コンソール２４２から受け取る。エンジン２５２の実行を起動させる場合には（その実行が最近に中止されたエンジンをリスタートすることを含む）、コントローラ２５４はローダ２６４と通信して、エンジン２５２のイメージをストレージデバイス（例えば、デバイス２６２、ROMなど）からノード２４８のメモリ（例えば、RAM）にロードする。ローダ２６４は従来と同じように動作して、エンジンのイメージをストレージデバイスからメモリにコピーし、必要とされるオぺレーティングシステムのパラメータを初期化してエンジン２５２が実行されるようにする。従って、エンジン２５２の制御は、実際には、管理されるノード２４８と同じロケーションでローカルにではなく、リモートデバイスによって管理される。

コントローラ２５４は、図３のアプリケーションオペレーション管理コンソール２４２または図１の管理デバイス１１０が、フィルタセット２５８からどのフィルタを追加するか（および/または除去するか）を、そこから指定できるインタフェースともなっている。

コントローラ２５４は、図３のクラスタオペレーション管理コンソール２４０が、そこからコマンドをコントローラ２５４に渡すことができるインタフェースも備えている。ノードをリブートする、ノードをシャットダウンする、ノードを低電力ステートに（例えば、サスペンドまたはスタンバイステートに）する、クラスタ境界を変更する、暗号鍵（存在する場合）を変更する、といったように、種々タイプのハードウェアオペレーション中心のコマンドを、クラスタオペレーション管理コンソール２４０からコントローラ２５４に伝達することが可能になっている。

コントローラ２５４は、さらに、BMonitor２５０に対して暗号化サポートを行うので（これはオプションである）、データを大容量ストレージデバイス２６２（例えば、磁気ディスク、光ディスクなど）にセキュアにストアしておくこと、およびノード２４８とオペレーション管理コンソール（例えば、図３のコンソール２４０または２４２）または他の管理デバイス（例えば、図１の管理デバイス１１０）の間でセキュアな通信を行うことを可能にしている。コントローラ２５４は複数の暗号鍵を保存しており、その中には、対称鍵 (symmetric keys)（秘密鍵暗号化で使用される秘密鍵）、公開/秘密鍵ペア（公開鍵暗号化を目的とする）などのように、データを暗号化しおよび/またはデータを解読する際に使用される、さまざまな異種の鍵を含めることが可能である。

BMonitor２５０は公開鍵暗号化手法 (public key cryptography) を利用して、ノード２４８と管理コンソール（例えば、図３のコンソール２４０と２４２）または管理デバイス（例えば、図１の管理デバイス１１０）の間でセキュアな通信が行われるようにしている。この公開鍵暗号化手法は、公開鍵 (public key) と秘密鍵 (private key) の両方を含む鍵ペア (key pair) と暗号化アルゴリズム (encryption algorithm) をベースにしている。暗号化アルゴリズムは、公開鍵に基づいてデータを暗号化し、秘密鍵がなければデータが効率的に解読されないようにする。従って、公開鍵保持者からの通信は、公開鍵を使用して暗号化されるので、秘密鍵所有者だけがその通信を解読できるようにしている。公開鍵暗号化手法は、周知のRSA (Rivest, Shamir, Adelman) 暗号化手法のように、さまざまなものが使用可能である。暗号化手法の基礎入門書として、Bruce Schneir著「応用暗号化手法：プロトコル、アルゴリズム、およびCによるソースコード(Applied Cryptography: Protocols, Algorithms, and Source Code in C)」、John Wiley & Sons、初版著作権所有1994（または第２版著作権所有1996）がある。

BMonitor２５０は、ランドロードとテナントの両者のための公開/秘密鍵ペアを含むように初期化されている。これらの鍵ペアはBMonitor２５０によって生成できるが、別の方法として、他のコンポーネントが生成して、BMonitor２５０にストアしておくこともできる（この場合、他のコンポーネントは鍵ペアの情報を壊さないものとして信頼されている）。本明細書では、Uは公開鍵を示し、Rは秘密鍵を示すように使用されている。ランドロード用の公開/秘密鍵ペアは (U_L, R_L) と呼ばれ、テナント用の公開/秘密鍵ペアは (U_T, R_T) と呼ばれる。BMonitor２５０は、公開鍵U_LとU_Tをランドロードが利用できるようにしているが、秘密鍵R_LとR_T は秘密に保っている。図示の例では、BMonitor２５０は、秘密鍵R_LとR_T を公開することがないので、ランドロードだけでなく、テナントも、公開鍵を使用して暗号化した情報（例えば、それぞれ、図３のクラスタオペレーション管理コンソール２４０とアプリケーションオペレーション管理コンソール２４２を通して）が、BMonitor２５０以外の、他のどのエンティティによっても解読されないことが保証される。

ランドロードに公開鍵U_LとU_Tが与えられると、ランドロードは特定のテナントにノード２１０−１〜２１０−ｎを割り当て、そのテナントに公開鍵U_Tを与えることができる。この公開鍵U_Tを使用すると、テナントは、BMonitor２５０だけが解読できる（秘密鍵R_Tを使用して）、BMonitor２５０への通信を暗号化することができる。必ずしも必要ではないが、テナント用の慎重な初期ステップでは、BMonitor２５０が新しい公開/秘密鍵ペア (U_T, R_T) を生成することをBMonitor２５０に要求するようになっている。この要求を受けて、コントローラ２５４またはBMonitor２５０の鍵ジェネレータ (key generator)（図示せず）は、さまざまな周知方法のいずれかで新しい公開/秘密鍵ペアを生成し、その新鍵ペアをテナント鍵ペアとしてストアし、新公開鍵U_Tをテナントに送り返す。新鍵ペアを生成すると、テナントは、ランドロードを含めて、他のどのエンティティにも、テナントの公開鍵U_Tが気づかれないことが保証される。さらに、テナントは、新しい鍵ペアを別の時期に生成させることも可能になっている。

BMonitor２５０が秘密鍵をストアし、テナントに公開鍵を知らせるときの公開/秘密鍵ペアがあると、情報をテナントからBMonitor２５０にセキュアに伝えることが可能になる。情報がBMonitor２５０からテナントにセキュアに伝えられることを保証するために、別の公開/秘密鍵ペアがテナントによって生成され、公開鍵部分がBMonitor２５０に伝えられる。従って、BMonitor２５０からテナントへのどの通信も、この公開鍵部分を使用して暗号化することができ、対応する秘密鍵の保持者によってのみ（つまり、テナントによってのみ）解読されることができる。

BMonitor２５０はまた、ディスク鍵を、鍵２５９の１つとして保持しており、これは、１つまたは複数の対称鍵を使用して生成される（ここで、対称鍵 (symmetric keys) とは、秘密鍵暗号化で使用される秘密鍵のことである）。対称鍵でもあるディスク鍵は、情報を大容量ストレージデバイス２６２にストアするためにBMonitor２５０によって使用される。BMonitor２５０はディスク鍵をセキュアに保っているので、これは、ノードが大容量ストレージデバイス２６２にストアしたデータを暗号化し、ノードが大容量ストレージデバイス２６２から取り出したデータを解読するためにだけ使用される（従って、ランドロードとテナントを含めて、他のどのエンティティにも、ディスク鍵を知らせないで済むようになっている）。

ディスク鍵を使用すると、大容量ストレージデバイス２６２にストアされているデータは、それを暗号化したノード２４８だけが解読でき、他のどのノードまたはデバイスも解読できないことが保証される。従って、例えば、大容量ストレージデバイス２６２が取り外されているような場合に、デバイス２６２上のデータを読み取る試みが行われると、その試みは失敗することになる。BMonitor２５０は、データのソースに関係なく、大容量ストレージデバイス２６２にストアされているデータを、ディスク鍵を使用して暗号化する。例えば、データのソースとしては、テナントのカスタマが使用しているクライアントデバイス（例えば、図１のクライアント１０２１〜１０２ｎ）、管理デバイス（例えば、図１のデバイス１１０または図３のコンソール２４０または２４２）などがある。

ある実装では、ディスク鍵は、各管理デバイスに対応するストレージ鍵を組み合わせることによって生成される。ストレージ鍵を組み合わせるには、さまざまな仕方が可能であり、ある実装では、鍵の一方を他方の鍵を暗号化するために使用し、その結果の値を鍵のもう１つの鍵で暗号化するようにして組み合わされている。

さらに、BMonitor２５０は、ノード２４８の管理を分担している複数の、相互に不信の管理エージェント間のやりとりを仲介するトラステッドサードパーティ（第三者機関）の働きをしている。例えば、ノード２４８のランドロードとテナントは、お互いを完全に信用していないのが代表的である。そのため、BMonitor２５０はトラステッドサードパーティの働きをして、特定のエンティティまたはエージェントによってBMonitor２５０に利用可能にされた情報がそのエンティティまたはエージェントだけがアクセスでき、他のエンティティやエージェントはアクセスできないことを、ノード２４８の貸主 (lessor) と借主 (lessee) に信頼させるようにしている（例えば、貸主が与えた機密情報は借主がアクセスすることできない。その逆も同じである）。BMonitor２５０は、階層化された所有権ドメイン (ownership domain DO) のセットを使用して、この信頼を生みやすくしている。所有権ドメインは、BMonitor２５０における認証と権利の基本単位であり、各管理エンティティまたはエージェント（例えば、貸主と借主）は、別々の所有権ドメインに対応付けられている（なお、各管理エンティティが複数の管理デバイスをもっていれば、そこから管理責任を行使することができる）。

図６は、本発明のいくつかの実施形態による例示の所有権ドメインのセットを示すブロック図である。複数（ｘ個）の所有権ドメイン２８０、２８２、および２８４は、所有権ドメインスタック２８６として編成されている。各所有権ドメイン２８０〜２８４は、特定の管理レベルおよび１つまたは複数の管理デバイス（例えば、図１のデバイス１１０、図３のコンソール２４０と２４２など）に対応付けられている。ベースまたはルート (root) 所有権ドメイン２８０は、上述したランドロードのように、ノードの実際の所有者に対応している。次の下位所有権ドメイン２８２は、ハードウェアの所有者からハードウェアをリースしているエンティティ（例えば、上述したテナント）に対応している。特定の所有者ドメイン内の管理デバイスは、所有権ドメインスタック２８６上で上位にある別の管理デバイス用に、別の所有権ドメインをセットアップすることができる。例えば、ノードがリースされているエンティティは、別のエンティティ用に別の所有権ドメインをセットアップすることができる（例えば、データベースクラスタを実装しているノードクラスタをセットアップするために）。

新しい所有権ドメインが作成されると、その所有権ドメインは、所有権ドメインスタック２８６の先頭にプッシュされる。これは、別の新しい所有権ドメインを作成するか、あるいはその権利が取り消されるまで、トップレベル所有権ドメインのままになっている。所有権ドメインの権利は、所有権ドメインスタック２８６上の、いずれかの下位レベル所有権ドメイン内のデバイスによって取り消すことが可能であり、取り消されると、その所有権ドメインは、他の上位レベル所有権ドメインがあれば、それと一緒にスタック２８６からポップされる（除去される）。例えば、ノード２４８の所有者（所有権ドメイン２８０）が所有権ドメイン２８２の権利を取り消すようなことがあると、所有権ドメイン２８２と２８４は所有権ドメインスタック２８６からポップされることになる。

各所有権ドメインは、対応する権利セットをもっている。図示の例では、トップレベル所有権ドメインは１つの権利セットをもち、その中には、次のような権利が含まれている。すなわち、(1) 新しい所有権ドメインを所有権ドメインスタック上にプッシュする権利、(2) ノード内のいずれかのシステムメモリにアクセスする権利、(3) ノード内のまたはノードに結合された、いずれかの大容量ストレージデバイスにアクセスする権利、(4) ノードに置かれたパケットフィルタを修正（追加、除去、または変更）する権利、(5) ノード上でソフトウェアエンジン（例えば、図５のエンジン２５２）の実行を開始する権利、(6) ノードをリセットすることも含めて、ノード上でソフトウェアエンジンの実行を中止する権利、(7) ノード上でソフトウェアエンジンをデバッグする権利、(8) 自身の認証信用証明 (authentication credential)（例えば、その公開鍵またはID）を変更する権利、(9) 自身のストレージ鍵を修正する権利、(10) エンジンイベント、マシンイベント、および/またはパケットフィルタイベントなどのイベントに加入する権利（例えば、これらのイベントの１つが起こったとき管理コンソールまたは他のデバイスに通知する）である。さらに、下位レベル所有権ドメインの各々は別の権利セットをもち、その中には、次のような権利が含まれている。すなわち、(1) 既存の所有権ドメインをポップする権利、(2) ノードに置かれたパケットフィルタを修正（追加、削除、または変更）する権利、(3) 自身の認証信用証明（例えば、公開鍵またはID）を変更する権利、(4) マシンイベントおよび/またはパケットフィルタイベントに加入する権利である。別の方法として、上記権利の一部をセットから除くことも（例えば、状況に応じては、ノード上でソフトウェアエンジンをデバックする権利は必要でない場合がある）、他の権利をセットに含めることも可能である（例えば、トップレベルノードに、自身を所有権ドメインスタックからポップオフする権利を含めることができる）。

所有権ドメインは、オペレーション期間中に何度でも、所有権ドメインスタックに追加したり、そこから除去したりすることができる。どの所有権ドメインが除去および/または追加されるかは、実行されているアクティビティによって変化する。１つの例として、ノード２４８の所有者（ルート所有権ドメイン２８０に対応する）がノード２４８上でなんらかのオペレーションを実行することを望んでいると、すべての上位レベル所有権ドメイン２８２〜２８４が取り消され、望みのオペレーションが実行され（所有権ドメイン２８０がトップレベルドメインになるので、拡張権利セットが利用可能になる）、新しい所有権ドメインを作成し、所有権ドメインスタック２８６に追加することが可能になる（例えば、以前にトップレベル所有権ドメインに対応付けられていた管理エージェントは、以前の位置に戻されることになる）。

BMonitor２５０は、所有権ドメインの１つに対応するエンティティ（例えば、そのエンティティによって制御されている管理コンソール）から要求が受け取られるたびに、その所有権ドメインがどの権利をもっているかをチェックする。所有権ドメインが要求を実現するために必須の権利をもっていれば、BMonitor２５０はその要求を実行する。しかし、所有権ドメインが必須の権利セットをもっていなければ、要求は実行されない（例えば、要求が実行できないとの通知を要求側に戻すことも、要求を無視するだけにすることもできる）。

図示の例では、各所有権ドメインは識別子 (ID)、公開鍵、およびストレージ鍵を含んでいる。識別子は、所有権ドメインのユニーク識別子として使用され、公開鍵は、その所有権ドメインに対応する管理デバイスにセキュアな通信を送信するために使用され、ストレージ鍵は、大容量ストレージデバイスにストアされた情報を暗号化するために（少なくとも部分的に）使用される。追加の秘密鍵を各々の所有権ドメインごとに含めておくと、所有権ドメインに対応する管理デバイスは、BMonitorにセキュアな通信を送信することが可能になる。ルート所有権ドメイン２８０が作成されるとき、これはそのIDと公開鍵をもつように初期化される（例えば、BMonitor２５０によって）。ルート所有権ドメイン２８０は、ストレージ鍵（および秘密鍵）を含むように初期化することも可能であり、あるいは後で追加することも可能である（例えば、BMonitor２５０に生成させるとか、管理コンソールからBMonitor２５０に伝える、など）。同様に、新しい所有権ドメインが作成されるたびに、その新所有権ドメインを作成する所有権ドメインは、IDと公開鍵を、新所有権ドメインのBMonitor２５０に伝達する。ストレージ鍵（および秘密鍵）は、所有権ドメインの作成時でも、あるいはその後でも、新所有権ドメインのために作成することができる。

BMonitor２５０は、所有権ドメインの各々に対応する管理デバイスを認証する。BMonitorは、管理デバイスが認証されるまでは、その管理デバイスからのどのコマンドも受け付けず、特定の所有権ドメインの機密情報（暗号鍵）を、自身をその所有権ドメインに対応するものとして認証できる管理デバイスにだけ公開する。この認証プロセスは、ノードのオペレーション期間中、何度でも行うことができるので、１つまたは複数の所有権ドメインの管理デバイスは時間の経過と共に変わることになる。管理デバイスの認証を行うには、さまざまな方法が可能である。ある実装では、管理デバイスがBMonitor２５０とのコネクションを要求し、自分が特定の所有権ドメインに対応していることを主張すると、BMonitor２５０はトークン（例えば、ランダムな数）を生成し、所有権ドメインの公開鍵でトークンを暗号化し、その暗号化トークンを要求側管理デバイスに送信する。暗号化トークンを受け取ると、管理デバイスは、その秘密鍵を使用してトークンを解読し、解読したトークンをBMonitor２５０に戻す。戻されたトークンがBMonitor２５０によって生成されたトークンに一致していると、管理デバイスの認証性が確認される（これは、対応する秘密鍵をもつ管理デバイスだけがトークンを解読できるからである）。類似のプロセスを使用して、BMonitor２５０が自身を管理デバイスに対して認証することも可能である。

認証されると、管理デバイスは要求をBMonitor２５０に伝達し、その要求のいずれかを実行させることができる（ただし、そうする権利を持っていることが条件である）。必ずしも必要でないが、管理コンソールにとって賢明なことは、初めて自身をBMonitor２５０に対して認証したとき、その公開鍵/秘密鍵ペアを変更しておくことである。

新しい所有権ドメインが作成されるとき、その新所有権ドメインを作成する管理デバイスは、オプションとして、既存のエンジン２５２を終了し、システムメモリと大容量ストレージデバイスを消去しておくことができる。このようにすると、暗号化に上乗せされる形でセキュリティレベルが強化されるので、ある管理デバイスが、別の管理デバイスによってハードウェア上にストアされた情報にアクセスすることが防止されることになる。さらに、所有権ドメインがスタックからポップされるたびに、BMonitor２５０は既存のエンジン２５２を終了し、システムメモリを消去し、その所有権ドメインのストレージ鍵も消去する。従って、その所有権ドメインによってストアされた情報は、残りの所有権ドメインによってアクセスされることはない。つまり、メモリは消去されているので、データはメモリになく、ストレージ鍵なしでは、大容量ストレージデバイス上の情報を解読することができない。別の方法として、BMonitor２５０は、大容量ストレージデバイスも消去することが可能である。しかし、鍵を消去し、データを暗号化したままにしておけば、BMonitor２５０は、ポップされた所有権ドメインが再作成されるとき（同じストレージ鍵を使用すれば）、データを回復することが可能になる。

図７は、本発明のいくつかの実施形態によるBMonitor２５０の全体的オペレーションを示すフロー図である。初めに、BMonitor２５０は、送られてくる入力をモニタリングしている（ブロック２９０）。これらの入力が送られてくるソースは、別のノード２４８、ネットワークコネクション２１６を経由するクライントコンピュータ（図３）、クライアントオペレーション管理コンソール２４０、アプリケーションオペレーション管理コンソール２４２、エンジン２５２、管理デバイス１１０（図１）といったように、さまざまである。

受け取った要求が制御要求であれば（例えば、図３のコンソール２４０または２４２の１つ、または図１の管理デバイスからの）、要求側デバイスがその要求に対して必要な権利を持っているかどうかがチェックされる（トップレベル所有権ドメインに基づいて）（ブロック２９２）。要求側デバイスが必要な権利をもっていなければ、BMonitor２５０は要求を実行することなく、入力のモニタリング（ブロック２９０）に戻る。しかし、要求側デバイスが必要な権利をもっていれば、要求は実行され（ブロック２９４）、BMonitor２５０は受け取った入力のモニタリング（ブロック２９０）を続ける。しかし、受け取った要求がデータ要求であるときは（例えば、別のノード２４８またはネットワークコネクション２１６経由のクライアントコンピュータからのインバウンド、エンジン２５２からのアウトバウンドなど）、BMonitor２５０は要求を受け付けるか、さもなければ拒否し（ブロック２９６）、送られている入力のモニタリング（ブロック２９０）を続ける。BMonitor２５０が要求を受け付けるかどうかは、上述したように、フィルタ２５８（図５）によって決まる。

図８は、本発明のいくつかの実施形態によるアウトバウンドデータ要求を処理するときの例示プロセスを示すフローチャートである。図８のプロセスは、図５のBMonitor２５０に実装されており、ソフトウェアで実行することができる。図８のプロセスを、図１、３および５に示すコンポーネントと関連付けて説明すると、次の通りである。

初めに、アウトバウンドデータ要求が受信される（ステップ３００）。コントローラ２５４は、その要求をアウトバウンド要求制約条件 (request restrictions) と比較する（ステップ３０２）。この比較は、データに対応する情報（例えば、データを収めているパケットのヘッダ内の情報またはデータに内在する情報。例えば、データ要求がBMonitor２５０に渡されたときの仕方（例えば、複数の関数コールのどれが使用されたか）などの情報）にアクセスし、フィルタ２５８が維持しているアウトバウンド要求制約条件と比較することにより行われる。この比較を行うと、BMonitor２５０は、アウトバウンドデータ要求をターゲットに渡すことが許されるかどうかを判断することができる（ステップ３０４）。例えば、どのターゲットにデータを送信できないかをフィルタ２５８が示す場合、アウトバウンドデータ要求をターゲットに渡すことが許されるのは、ターゲット識別子( ID) がフィルタ２５８で特定されていないときだけである。

アウトバウンドデータ要求をターゲットに渡すことが許されていれば、BMonitor２５０は、要求をターゲットに送信する（ステップ３０６）。例えば、BMonitor２５０は、トランスポート媒体２１１を経由して（ネットワークコネクション２１６を経由することもある）要求を該当ターゲットに送信することも、別のコネクションを経由してネットワーク１０８に送信することもできる。しかし、アウトバウンドデータ要求をターゲットに渡すことが許されていなければ、BMonitor２５０は要求を拒否する（ステップ３０８）。BMonitor２５０は、オプションとして、要求が拒否されたとの通知を、その要求のソースに送信することも、要求をドロップするだけのことも可能である。

図９は、本発明のいくつかの実施形態によるインバウンドデータ要求を処理するときの例示プロセスを示すフローチャートである。図９のプロセスは図５のBMonitor２５０に実装され、ソフトウェアで実行することが可能である。図９のプロセスを、図５に示すコンポーネントと関連付けて説明すると、次の通りである。

初めに、インバウンドデータ要求が受信される（ステップ３１０）。コントローラ２５４は、その要求をインバウンド要求制約条件と比較する（ステップ３１２）。この比較は、データに対応する情報にアクセスし、フィルタ２５８が維持しているインバウンド要求制約条件と比較することにより行われる。この比較を行うと、BMonitor２５０は、ソフトウェアエンジン２５２のどれが、データ要求を受信することが許されるかどうかを判断することができる（ステップ３１４）。例えば、どのソースからデータを受信できるかをフィルタ２５８が示す場合、エンジン２５２がデータ要求を受信することが許されるのは、データのソースがフィルタ２５８で特定されているときだけである。

インバウンドデータ要求を受信することが許されていれば、BMonitor２５０は、その要求をターゲットのエンジン２５２に転送する（ステップ３１６）。しかし、インバウンドデータ要求をソースから受信することが許されていなければ、BMonitor２５０は要求を拒否する（ステップ３１８）。BMonitor２５０は、オプションとして、要求が拒否されたとの通知を、その要求のソースに送信することも、要求をドロップするだけのことも可能である。

結論
上述してきた説明では、構造上の特徴および/または方法ステップに特有の用語が用いられているが、当然に理解されるように、請求項に定義されている本発明は、上述してきた特定の特徴やステップに限定されるものではない。むしろ、特定の特徴とステップは、本発明を実施するための例示形態として開示されたものである。

本発明のいくつかの実施形態で使用できるような、クライアント/サーバネットワークシステムと環境を示す図である。本発明のいくつかの実施形態に従って使用できるコンピュータの例を示す概要図である。例示の共同ロケーション施設を示す詳細ブロック図である。例示の多層管理アーキテクチャを示すブロック図である。本発明のいくつかの実施形態による例示のノードを示す詳細ブロック図である。本発明のいくつかの実施形態による例示の所有権ドメインセットを示すブロック図である。本発明のいくつかの実施形態によるBMonitorの全体的オペレーションを示すフロー図である。本発明のいくつかの実施形態によるアウトバウンドデータ要求を処理するための例示プロセスを示すフローチャートである。本発明のいくつかの実施形態によるインバウンドデータ要求を処理するための例示プロセスを示すフローチャートである。

符号の説明

１０２１〜１０２ｎクライアント
１０４１〜１０４ｍ共同ロケーション施設
１０６１−１、１０６１−２、１０６ｍ−１、１０６ｍ−１サーバクラスタ
１０８インターネット
１１０管理デバイス
１１２サーバ
２１０−１〜２１０−ｎノード
２３０クラスタオペレーション管理層
２３２アプリケーションオペレーション管理層
２３４アプリケーション開発層
２４０クラスタオペレーション管理コンソール
２４２アプリケーションオペレーション管理コンソール
２４８ノード
２５０ BMonitor
２５２エンジン
２５６ネットワークインタフェース
２５８フィルタ
２５９鍵
２６０ BMCPモジュール
２６２大容量ストレージデバイス
２６４ローダ
２８０、２８２、２８４所有権ドメイン
２８６所有権ドメインスタック

Claims

共同ロケーション施設内に設けられた複数のノードと、
前記複数のノードを管理する複数の管理デバイスであって、前記複数の管理デバイスの各々は、順序付けられた複数の所有権ドメインの別々の１つに対応付けられ、前記複数の所有権ドメインのうち最も上位に順位付けられた所有権ドメインは、新しい所有権ドメインを作成する権利と、前記管理デバイスに関連付けられた複数のノード内のいずれかのシステムメモリにアクセスする権利とを含む第１の権利セットを有するトップレベル所有権ドメインであり、前記複数の所有権ドメインのうちの前記トップレベル所有権ドメイン以外の所有権ドメインの各々は、上位に順序付けられた所有権ドメインを取り消す権利を含む第２の権利セットを有する、管理デバイスとを備えるシステムであって、
前記所有権ドメインが取り消され、当該取り消された所有権ドメインよりも上位に順序付けられた所有権ドメインがある場合、前記取り消された所有権ドメインよりも上位に順序付けられた全ての所有権ドメインを取り消し、
前記新しい所有権ドメインが作成される場合、当該新しい所有権ドメインが前記トップレベル所有権ドメインとなり、前記新しい所有権ドメインを作成した管理デバイスが管理するノードのシステムメモリに格納された情報を消去することを特徴とするシステム。
請求項１に記載のシステムにおいて、前記第１の権利セットは、前記ノードに結合された大容量ストレージデバイスにアクセスする権利と、および前記ノード内のフィルタに変更を加える権利とをさらに含み、前記第２の権利セットは、前記ノード内のフィルタに変更を加える権利と、前記所有権ドメインに対する認証信用証明を変更する権利と、前記ノードにおけるマシンイベント及びパケットフィルタイベントに加入する権利とをさらに含むことを特徴とするシステム。