JP2002202951A

JP2002202951A - 共有コンピュータの分散管理のためのシステムおよび方法

Info

Publication number: JP2002202951A
Application number: JP2001326847A
Authority: JP
Inventors: Galen C Hunt; シー．ハントガレン; Aamer Hydrie; ハイドリーアーマー; Steven P Levi; ピー．レビスティーブン; David S Stutz; エス．スチューツデービッド; Bassam Tabbara; タバラバサム; Robert V Welland; ブイ．ウエランドロバート
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2000-10-24
Filing date: 2001-10-24
Publication date: 2002-07-19
Anticipated expiration: 2021-10-24
Also published as: JP5140128B2; US7370103B2; US7711121B2; JP2011003220A; EP2442492B1; EP2424165B1; EP2424167B1; US7606898B1; EP2424166A1; EP1202175B1; EP1202175A2; EP2442492A1; EP2424165B8; US7200655B2; US20060259609A1; ES2643489T3; EP2424164B1; JP2007305123A; US20050097097A1; JP4261096B2

Abstract

(57)【要約】【課題】共同ロケーション施設における共有コンピュ
ータの分散管理を改善する。【解決手段】多層管理アーキテクチャが採用され、こ
のアーキテクチャは、アプリケーション開発層、アプリ
ケーションオペレーション層、およびクラスタオペレー
ション層を含んでいる。アプリケーション開発層では、
アプリケーションは、１つまたは２つ以上のサーバコン
ピュータ上で実行されるように開発される。アプリケー
ションオペレーション層では、アプリケーションの実行
が管理され、共同ロケーション施設に置かれたサーバク
ラスタ内のサブ境界が設定可能になっている。クラスタ
オペレーション層では、サーバコンピュータのオペレー
ションは、どのアプリケーションが１つまたは２つ以上
のサーバコンピュータ上で実行されているかに関係な
く、管理され、共同ロケーション施設に置かれたサーバ
クラスタの境界が設定可能になっている。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、コンピュータシス
テムの管理に関する。さらに具体的には、本発明は、共
有コンピュータの分散管理に関する。

【０００２】

【従来の技術】インターネット（ｔｈｅＩｎｔｅｒｎ
ｅｔ）とその使用は、この近年に大幅に拡張しており、
その拡張は今後も続くことが予想されている。インター
ネットの顕著な使い方の１つは、ワールドワイドウェブ
（ＷｏｒｌｄＷｉｄｅＷｅｂＷＷＷ。”Ｗｅ
ｂ”とも呼ばれている）であり、これは、ユーザが見た
り、さもなければ、レンダリング（ｒｅｎｄｅｒｉｎ
ｇ）することができるドキュメントの集まりであり、そ
こには、ユーザがアクセスできる１つまたは２つ以上の
他のページへのリンクが含まれているのが代表的であ
る。多くの企業や個人は、１または２以上のＷｅｂペー
ジで構成される存在物をＷｅｂ上に創設し、１または２
以上のＷｅｂページで自社または自分のことを記述し、
自社製品やサービスを説明し、他の関心のある情報を特
定し、商品やサービスの購入を可能にしているのが代表
的である。

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

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

【０００５】ここで、共同ロケーション施設とは、複数
のサーバを収容できる複合体（ｃｏｍｐｌｅｘ）のこと
である。共同ロケーション施設は、高信頼インターネッ
トコネクション、高信頼電源、および正しい動作環境を
提供しているのが代表的である。また、共同ロケーショ
ン施設は、複数のセキュアエリア（例えば、ケージ（ｃ
ａｇｅ））を含み、異なる企業が自社サーバをそこに置
いておくことを可能にしているのが代表的である。特定
の企業が共同ロケーション施設に置いておくサーバの集
まりは、実際には、いずれかの個別的共同ロケーション
施設に、シングルサーバだけが置かれていることがあっ
ても、「サーバクラスタ（ｓｅｒｖｅｒｃｌｕｓｔｅ
ｒ）」と呼ばれる。この場合、その特定企業は、自社サ
ーバクラスタ内のサーバのオペレーションの管理を担当
することになる。

【０００６】

【発明が解決しようとする課題】しかしながら、このよ
うな共同ロケーション施設にも、問題が起こっている。
１つの問題は、データのセキュリティ（ｄａｔａｓｅ
ｃｕｒｉｔｙ）である。異なる企業（競争企業でさえ
も）は、同一共同ロケーション施設にサーバクラスタを
置くことが可能になっている。このような状況では、あ
る企業を目的に、インターネットから受信されたデータ
（またはサーバクラスタ内のサーバから送信されたデー
タ）が、その共同ロケーション施設に置かれている別の
企業のサーバにルーチング（経路探索）されないように
する配慮が必要である。

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

【０００８】もう１つの問題は、共同ロケーション施設
に置かれているサーバのオペレータだけでなく、これら
のサーバでホストされるＷｅｂサービスのオペレータ
も、その権利を行使することに関係する問題である。サ
ーバのオペレータは、サーバがＷｅｂサービスのオペレ
ータによって所有されている場合でも、その権利（例え
ば、サーバが置かれている施設のエリアを再所有する権
利）を保持できることが必要である。さらに、Ｗｅｂサ
ーバのオペレータは、自分のデータがセキュアに保たれ
ているとの保証を得る必要がある。

【０００９】以下に説明する本発明は、上記問題点を解
決し、共同ロケーション施設における共有コンピュータ
の分散管理を改善することを目的としている。

【００１０】

【課題を解決するための手段】以下では、共有コンピュ
ータの分散管理について説明する。

【００１１】本発明の一形態によれば、多層管理アーキ
テクチャ（ｍｕｌｔｉ−ｔｉｅｒｅｄｍａｎａｇｅｍ
ｅｎｔａｒｃｈｉｔｅｃｔｕｒｅ）が採用され、この
アーキテクチャは、アプリケーション開発層（ａｐｐｌ
ｉｃａｔｉｏｎｄｅｖｅｌｏｐｍｅｎｔｔｉｅ
ｒ）、アプリケーションオペレーション層（ａｐｐｌｉ
ｃａｔｉｏｎｏｐｅｒａｔｉｏｎｓｔｉｅｒ）、お
よびクラスタオペレーション層（ｃｌｕｓｔｅｒｏｐ
ｅｒａｔｉｏｎｓｔｉｅｒ）を含んでいる。アプリケ
ーション開発層では、アプリケーションは、１つまたは
２つ以上のサーバコンピュータ上で実行されるように開
発される。アプリケーションオペレーション層では、ア
プリケーションの実行が管理され、共同ロケーション施
設に置かれたサーバクラスタ内のサブ境界（ｓｕｂ−ｂ
ｏｕｎｄａｒｙ）が設定可能になっている。クラスタオ
ペレーション層では、サーバコンピュータのオペレーシ
ョンは、どのアプリケーションが１つまたは２つ以上の
サーバコンピュータ上で実行されているかに関係なく、
管理され、共同ロケーション施設に置かれたサーバクラ
スタの境界が設定可能になっている。

【００１２】別の形態によれば、共同ロケーション施設
は、各々が異なるカスタマーに対応している複数のサー
バクラスタを含んでいる。各々のサーバクラスタごと
に、クラスタオペレーション管理コンソールは、クラス
タのハードウェアオペレーションを管理するために共同
ロケーション施設にローカルに実装され、アプリケーシ
ョン管理コンソールは、クラスタのソフトウェアオペレ
ーションを管理するために、共同ロケーション施設から
離れたロケーションに実装されている。ハードウェアに
障害が起きた場合は、クラスタオペレーション管理コン
ソールは訂正アクションをとる（例えば、共同ロケーシ
ョン施設にいるアドミニストレータに通知するか、ある
いは自身で障害の訂正を試みる）。ソフトウェアに障害
が起きた場合は、アプリケーションオペレーション管理
コンソールは訂正アクションをとる（例えば、カスタマ
ーのアドミニストレータの一人に通知するか、あるいは
自身で障害の訂正を試みる）。

【００１３】別の形態によれば、サーバクラスタの境界
は、クラスタオペレーション管理コンソールによって設
定される。境界を設定すると、データがサーバクラスタ
内のノードにだけルーチングされ、共同ロケーション施
設に置かれていて、サーバクラスタに属していない他の
ノードにはルーチングされないことが保証される。さら
に、サーバクラスタ内のサブ境界はアプリケーションオ
ペレーション管理コンソールによって設定され、データ
がサーバクラスタ内の特定ノードにだけルーチングされ
ることを保証する。

【００１４】別の形態によれば、共同ロケーション施設
に置かれる予定の、複数のサーバコンピュータに対する
権利はカスタマーに販売され、多層管理方式（ｍｕｌｔ
ｉｐｌｅ−ｔｉｅｒｅｄｍａｎａｇｅｍｅｎｔｓｃ
ｈｅｍｅ）がサーバコンピュータで実施される。この多
層管理方式によれば、サーバコンピュータのハードウェ
アオペレーションは、共同ロケーション施設でローカル
に管理されるのに対し、サーバコンピュータのソフトウ
ェアオペレーションは、共同ロケーション施設から離れ
たロケーションから管理される。サーバコンピュータ
は、カスタマーに販売することも、カスタマーにリース
することも可能である。

【００１５】別の形態によれば、ランドロード／テナン
ト（ｌａｎｄｌｏｒｄ／ｔｅｎａｎｔ）関係は、共同ロ
ケーション施設で１つまたは２つ以上のサーバコンピュ
ータを使用して構築される。共同ロケーション施設のオ
ペレータは、施設とサーバの両方を提供する（従って、
このオペレータは「ランドロード」と見ることができ
る）。これに対して、施設のカスタマーは、施設の使用
だけでなく、その施設のサーバもリースする（従って、
このカスタマーは「テナント」と見ることができる）。
このランドロード／テナント関係によると、ランドロー
ドは、テナントが異なるごとにコンピュータクラスタを
設定し、テナントのデータがそのクラスタを越えて（お
よび別のテナントのクラスタに）渡されないように、ク
ラスタ間に境界を設定することが可能である。さらに、
暗号化がさまざまな形で採用されているので、テナント
がそのリースを終了したり、リースしているサーバの１
つをランドロードに返却した場合でも、リースしている
サーバにストアされている情報が他人に見られない。

【００１６】別の形態によれば、多層管理アーキテクチ
ャは、共同ロケーション施設に属していないコンピュー
タの管理において採用される。この多層管理アーキテク
チャは、ビジネスやホームなどのような、さまざまな環
境でコンピュータ（サーバコンピュータであるか否かに
関係なく）を管理するために使用される。

【００１７】以下、添付図面を参照して本発明が説明さ
れているが、その説明は単なる例示であり、その説明に
限定されるものではない。図面全体を通して用いられて
いる同一符号は、類似のコンポーネントおよび／または
特徴を示している。

【００１８】

【発明の実施の形態】図１は、本発明のいくつかの実施
形態で使用できるような、クライアント／サーバネット
ワークシステムと環境を示す。一般的に、システムは複
数（ｎ個）のクライアントコンピュータ１０２と複数
（ｍ個）の共同ロケーション施設１０４を含み、各施設
は複数のサーバコンピュータのクラスタ（サーバクラス
タ）１０６を含んでいる。これらのサーバとクライアン
トコンピュータは、データコミュニケーションネットワ
ーク１０８を通して相互に通信している。図１のコミュ
ニケーションネットワークは、インターネット（ｔｈｅ
Ｉｎｔｅｒｎｅｔ）のような公衆ネットワーク１０８
を含んでいる。インターネットに加えて、あるいはその
代用として、他のタイプのコミュニケーションネットワ
ークを使用することも可能であり、その中には、ローカ
ルエリアネットワーク（ｌｏｃａｌａｒｅａｎｅｔ
ｗｏｒｋＬＡＮ）、広域ネットワーク（ｗｉｄｅ
ａｒｅａｎｅｔｗｏｒｋＷＡＮ）などが含まれて
いる。データコミュニケーションネットワーク１０８の
構築は、さまざまな方法で行うことが可能であり、その
中には、ワイヤド（有線）および／またはワイヤレス
（無線）コミュニケーション媒体が含まれている。

【００１９】ネットワーク１０８を利用したコミュニケ
ーションを行うには、広範囲にわたる通信プロトコルの
使用が可能である。ある実装では、クライアントコンピ
ュータ１０２とクラスタ１０６内のサーバコンピュータ
は、ハイパーテキスト転送プロトコル（Ｈｙｐｅｒｔｅ
ｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌＨＴＴ
Ｐ）を使用して相互に通信することが可能になってお
り、そこでは、Ｗｅｂページはサーバコンピュータによ
ってホストされ、ハイパーテキストマークアップ言語
（ＨｙｐｅｒｔｅｘｔＭａｒｋｕｐＬａｎｇｕａｇ
ｅＨＴＭＬ）または拡張可能マークアップ言語（ｅ
ＸｔｅｎｓｉｂｌｅＭａｒｋｕｐＬａｎｇｕａｇｅ
ＸＭＬ）などの、マークアップ言語で書かれてい
る。

【００２０】以下の説明では、本発明の実施形態は、主
に、共同ロケーション施設（施設１０４など）での実装
と関連付けて説明される。しかし、本発明はそのような
実装に限定されるものではなく、広範囲にわたる状況の
いずれにおいても、分散管理のために使用することが可
能である。例えば、そのような状況としては、施設に置
かれたサーバのすべてが同一カスタマーに所有またはリ
ースされる場合、シングルコンピューティングデバイス
（例えば、サーバまたはクライアント）が管理対象とな
っている場合、ビジネスまたはホーム環境におけるコン
ピュータ（サーバが否かに関係なく）が管理対象となっ
ている場合、などがある。

【００２１】以下の説明では、本発明の実施形態は、プ
ログラムモジュールのように、１つまたは２つ以上の従
来パーソナルコンピュータによって実行されるコンピュ
ータ実行可能命令の一般的なコンテキストで説明されて
いる。一般的に、プログラムモジュールには、特定のタ
スクを実行し、あるいは特定の抽象データ型を実装して
いる、ルーチン、プログラム、オブジェクト、コンポー
ネント、データ構造などが含まれている。さらに、当業
者ならば理解されるように、本発明の種々実施形態は、
他のコンピュータシステム構成で実施することが可能で
あり、その中には、ハンドヘルドデバイス、ゲーミング
コンソール（ｇａｍｉｎｇｃｏｎｓｏｌｅ）、インタ
ーネットアプライアンス（Ｉｎｔｅｒｎｅｔａｐｐｌ
ｉａｎｃｅ）、マルチプロセッサシステム、マイクロプ
ロセッサベースまたはプログラマブルコンシューマエレ
クトロニクス、ネットワークＰＣ、ミニコンピュータ、
メインフレームコンピュータなどが含まれている。分散
コンピュータ環境では、プログラムモジュールは、ロー
カルとリモートの両方のメモリストレージデバイスに置
いておくことが可能である。

【００２２】別の方法として、本発明の実施形態は、ハ
ードウェアで実現することも、ハードウェア、ソフトウ
ェア、および／またはファームウェアの組み合わせで実
現することもできる。例えば、本発明は、その全体また
は一部を１つまたは２つ以上の特定用途集積回路（ａｐ
ｐｌｉｃａｔｉｏｎｓｐｅｃｉｆｉｃｉｎｔｅｇｒ
ａｔｅｄｃｉｒｃｕｉｔＡＳＩＣ）またはプログ
ラマブルロジックデバイス（ｐｒｏｇｒａｍｍａｂｌｅ
ｌｏｇｉｃｄｅｖｉｃｅＰＬＤ）に実装させる
ことが可能である。

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

【００２４】コンピュータ１４２は、１つまたは２つ以
上のプロセッサまたは処理ユニット１４４、システムメ
モリ１４６、およびシステムメモリ１４６を含む種々シ
ステムコンポーネントをプロセッサ１４４に結合してい
るバス１４８を含んでいる。バス１４８は、数種タイプ
のバス構造のいずれかの１つまたは２つ以上を表してお
り、その中には、種々のバスアーキテクチャのいずれか
を採用しているメモリバスまたはメモリコントローラ、
ペリフェラル（周辺）バス、高速グラフィックスポー
ト、およびプロセッサまたはローカルバスが含まれてい
る。システムメモリとしては、リードオンリメモリ（ｒ
ｅａｄｏｎｌｙｍｅｍｏｒｙＲＯＭ）１５０と
ランダムアクセスメモリ（ｒａｎｄｏｍａｃｃｅｓｓ
ｍｅｍｏｒｙＲＡＭ）１５２がある。基本入出力
システム（ｂａｓｉｃｉｎｐｕｔ／ｏｕｔｐｕｔｓ
ｙｓｔｅｍＢＩＯＳ）１５４は、スタートアップ時
のときのように、コンピュータ１４２内のエレメント間
で情報を転送するのを支援する基本ルーチンで構成さ
れ、ＲＯＭ１５０に格納されている。

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

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

【００２７】コンピュータ１４２は、オプションとし
て、リモートコンピュータ１８８のような、１つまたは
２つ以上のリモートコンピュータとの論理コネクション
を使用するネットワーキング環境で動作している。リモ
ートコンピュータ１８８は、別のパーソナルコンピュー
タ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス
または他の共通ネットワークノードにすることが可能で
あり、図２にはメモリストレージデバイス１９０だけが
示されているが、コンピュータ１４２に関連して上述し
たエレメントの多くまたは全部を含んでいるのが代表的
である。図２に示す論理コネクションとしては、ローカ
ルエリアネットワーク（ＬＡＮ）１９２と広域ネットワ
ーク（ＷＡＮ）１９４がある。このようなネットワーキ
ング環境は、オフィス、企業内（ｅｎｔｅｒｐｒｉｓｅ
−ｗｉｄｅ）コンピュータネットワーク、イントラネッ
ト（ｉｎｔｒａｎｅｔ）、およびインターネット（ｔｈ
ｅＩｎｔｅｒｎｅｔ）で普及している。ここで説明して
いる本発明の実施形態では、リモートコンピュータ１８
８は、ＭｉｃｒｏｓｏｆｔＣｏｒｐｏｒａｔｉｏｎ
（Ｒｅｄｍｏｎｄ，Ｗａｓｈｉｎｇｔｏｎ）で製造さ
れ、販売されている”ＩｎｔｅｒｎｅｔＥｘｐｌｏｒ
ｅｒ” Ｗｅｂブラウザなどの、インターネットＷｅｂ
ブラウザプログラム（これは、オプションとして、オペ
レーティングシステムに組み込まれていることもある）
を実行している。

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

【００２９】一般的に、コンピュータ１４２のデータプ
ログラムは、コンピュータの種々のコンピュータ読取可
能媒体に時期を異にして格納されている命令によってプ
ログラムされている。プログラムとオペレーティングシ
ステムは、例えば、フロッピディスクやＣＤ−ＲＯＭに
入れて配布されるのが代表的である。これらは、そこか
らインストールされた後、コンピュータの二次メモリ
（ｓｅｃｏｎｄａｒｙｍｅｍｏｒｙ）にロードされてい
る。実行時に、これらは、少なくともその一部が、コン
ピュータの一次エレクトロニックメモリ（ｐｒｉｍａｒ
ｙｅｌｅｃｔｒｏｎｉｃｍｅｍｏｒｙ）にロードさ
れている。ここで説明している本発明によれば、マイク
ロプロセッサまたは他のデータプロセッサと関連付けて
以下に説明されているステップを実現するための命令ま
たはプログラムは、上記および他のタイプのコンピュー
タ読取可能ストレージ媒体に収められている。また、本
発明によれば、コンピュータ自体が、下述する方法と手
法に従ってプログラムされるようになっている。さら
に、コンピュータのある種のサブコンポーネントは、下
述する機能とステップを実行するようにプログラム可能
になっている。本発明によれば、そのようなサブコンポ
ーネントは下述するようにプログラムされるようになっ
ている。さらに、ここで説明している本発明によれば、
データ構造は、下述するように、種々タイプのメモリ媒
体上に具現化されている。

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

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

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

【００３３】ランドロード／テナント関係（貸主／借主
（ｌｅｓｓｏｒ／ｌｅｓｓｅｅ）関係とも呼ばれる）
は、ノード２１０をベースにして設定することも可能で
ある。共同ロケーション施設１０４の所有者（および／
またはオペレータ）は、個別的ノード２１０を所有して
いる（さもなければ、その権利を有している）ので、
「ランドロード」と見ることができる。共同ロケーショ
ン施設１０４のカスタマーは、ランドロードからノード
２１０をリースするので、「テナント」と見ることがで
きる。ランドロードは、どのタイプのデータまたはプロ
グラムがテナントによってノード２１０にストアされて
いるかには無関心であるのが代表的であるが、クラスタ
に境界を設けて、異なるクラスタからのノード２１０
が、相互に通信するのを防止するようにしている。これ
については、以下に詳しく説明されている。

【００３４】以下では、ランドロード／テナント関係
は、主に、２レベルに限定して、つまり、ランドロード
とテナントと関連付けて説明されている。しかし、代替
実施形態では、この関係は、任意の数のレベルに拡張す
ることも可能である。例えば、ランドロードは、その管
理責任を１つまたは２つ以上のサブランドロードと分担
することが可能であり（この場合、各々のサブランドロ
ードは、１つまたは２つ以上のノード２１０に対してあ
る種の管理制御権をもつことになる）、テナントも、同
じように、その管理責任を１つまたは２つ以上のサブテ
ナントと分担することが可能である（この場合は、各サ
ブテナントは、１つまたは２つ以上のノード２１０に対
してある種の管理制御権をもつことになる）。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００５２】多層管理アーキテクチャは、他の状況下に
おいて、１つまたは２つ以上のコンピュータが共同ロケ
ーション施設に属していない場合であっても、これらの
コンピュータを１つまたは２つ以上のリモートロケーシ
ョンから管理するためにも使用することができる。１つ
の例として、スモールビジネスは独自のコンピュータを
購入し、別の会社にそのコンピュータのハードウェアオ
ペレーションの管理を委託し、場合によっては、さらに
別の会社にコンピュータのソフトウェアオペレーション
の管理を委託することができる。

【００５３】この例では、スモールビジネス（コンピュ
ータの所有者）は第１管理層になっている。そのあと、
所有者はコンピュータをアウトソース（ｏｕｔｓｏｕｒ
ｃｅｄ）ハードウェアオペレータにリースしているが、
そのアウトソースハードウェアオペレータは第２管理層
になっている。このハードウェアオペレータは、管理対
象のコンピュータと一緒にスモールビジネスにローカル
に置かれているコントロールコンソールからでも、ある
リモートロケーションに置かれているコントロールコン
ソールからでも、クラスタオペレーション管理コンソー
ル２４０と同じようにハードウェアオペレーションを管
理することが可能になっている。そのあと、ハードウェ
アオペレータは、コンピュータをアウトソースソフトウ
ェアオペレータにリースしているが、そのアウトソース
ソフトウェアオペレータは第３管理層になっている。こ
のソフトウェアオペレータは、管理対象のコンピュータ
と一緒にスモールビジネスにローカルに置かれているコ
ントロールコンソールからでも、あるリモートロケーシ
ョンに置かれているコントロールコンソールからでも、
アプリケーションオペレーション管理コンソール２４２
と同じようにソフトウェアオペレーションを管理するこ
とが可能になっている。そのあと、ソフトウェアオペレ
ータは、コンピュータをその所有者に戻すようにリース
するので、所有者はコンピュータの「ユーザ」になり、
これは第４管理層になっている。通常オペレーション期
間は、コンピュータ所有者はこの第４管理層を占有して
いる。しかし、コンピュータ所有者は、例えば、コンピ
ュータ所有者がソフトウェアまたはハードウェアオペレ
ータを変更したいとき、その第１管理層の権利を行使し
て、ソフトウェアオペレータとハードウェアオペレータ
とのリースの一方または両方を打ち切ることができる。

【００５４】図５は、本発明のいくつかの実施形態によ
る例示ノードを示す。ノード２４８は、ノードの外部に
存在する他のデバイス（例えば、図３のコンソール２４
０と２４２）によって管理されている例示ノードであ
る。ノード２４８は図２のノードにすることも、別のロ
ケーションに置かれたノード（例えば、ビジネスまたは
ホーム環境におけるコンピュータ）にすることもでき
る。ノード２４８は、”ＢＭｏｎｉｔｏｒ”と呼ばれる
モニタ２５０、および複数のソフトウェアまたはエンジ
ン２５２を含み、大容量ストレージデバイス２６２に結
合されている（大容量ストレージデバイスに内蔵されて
いる場合もある）。図示の例では、ノード２４８は、複
数の特権レベル（ｐｒｉｖｉｌｅｇｅｌｅｖｅｌ）
（例えば、ｘ８６アーキテクチャプロセッサにおけるリ
ング）をサポートするプロセッサ（１または複数）を搭
載したサーバコンピュータになっている。図示の例で
は、これらの特権レベルはリング（ｒｉｎｇ）と呼ばれ
ているが、異なるプロセッサアーキテクチャを採用して
いる別の実装では、別の用語が用いられている場合があ
る。この複数リングによれば、１組の優先レベル（ｐｒ
ｉｏｒｉｔｉｚｅｄｌｅｖｅｌ）が用意され、ソフト
ウェアがその優先レベルで実行されるようになってい
る。なお、優先レベルは４レベル（リング０，１，
２，３）になっていることが多い。リング０は、最大
特権リングと呼ばれるのが代表的である。リング０で実
行されるソフトウェアプロセスは、特権の低いリングで
実行されるプロセスよりも、アクセスできる機能（例え
ば、命令）が多くなっているのが代表的である。さら
に、特定のリングで実行されているプロセッサは、優先
度の高いリングのコードやデータを変更することができ
ない。図示の例では、ＢＭｏｎｉｔｏｒ２５０はリン
グ０で実行されるのに対し、エンジン２５２はリング１
（またはリング１および／または３）で実行されてい
る。従って、ＢＭｏｎｉｔｏｒ２５０（リング０で実行
されている）のコードまたはデータは、エンジン２５２
（リング１で実行されている）によって直接に変更する
ことができない。むしろ、このような変更は、エンジン
２５２がＢＭｏｎｉｔｏｒ２５０に変更を依頼すること
によって（例えば、ＢＭｏｎｉｔｏｒ２５０にメッセー
ジを送るとか、ＢＭｏｎｉｔｏｒ２５０の関数を呼び出
すとか、といった方法で）行われる必要がある。ＢＭｏ
ｎｉｔｏｒ２５０をリング０で実装すると、ＢＭｏｎｉ
ｔｏｒ２５０は、ＢＭｏｎｉｔｏｒ２５によって課され
ている制限をバイパスしようとする乱暴なあるいは悪意
のあるエンジン２５２から保護されることになる。

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

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

【００５７】ＢＭｏｎｉｔｏｒ２５０は、コントローラ
２５４、ネットワークインタフェース２５６、１つまた
は２つ以上のフィルタ２５８、および分散ホスト制御プ
ロトコル（ＤｉｓｔｒｉｂｕｔｅｄＨｏｓｔＣｏｎ
ｔｒｏｌＰｒｏｔｏｃｏｌＤＨＣＰ）モジュール２６
０を含んでいる。ネットワークインタフェース２５６
は、共同ロケーション施設１０４の内部トランスポート
媒体２１１を通してノード２４８とネットワーク（例え
ば、図３のネットワークコネクション１２６）とを結ぶ
インタフェースとなっている。他のどのノード（および
／または他のソース）またはターゲット（例えば、図１
のインターネット１０８に結合されている）との間でデ
ータを送受信できるか（あるいは送受信できないか）
は、フィルタ２５８によって判別される。これらのノー
ドまたは他のソース／ターゲットを判別するには、ネッ
トワークアドレス（例えば、インターネットプロトコル
（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌＩＰ）アド
レス）、ある種のグローバルにユニークな識別子（Ｉ
Ｄ）、ローカルにユニークな識別子（例えば、共同ロケ
ーション施設１０４が所有するまたは独自の番号付け方
式）といった、さまざまな方法で行うことが可能であ
る。

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

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

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

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

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

【００６３】ＤＨＣＰモジュール２６０は分散ホスト制
御プロトコル（ＤｉｓｔｒｉｂｕｔｅｄＨｏｓｔＣ
ｏｎｔｒｏｌＰｒｏｔｏｃｏｌＤＨＣＰ）を実装
しているので、ＢＭｏｎｉｔｏｒ２５０（従って、ノー
ド２１０）がＤＨＣＰサーバ（例えば、図３のクラスタ
オペレーション管理コンソール２４０）からＩＰアドレ
スを取得することを可能にしている。ノード２１０の初
期化プロセス期間に、ＤＨＣＰモジュール２６０は、Ｄ
ＨＣＰサーバにＩＰアドレスを要求し、この要求を受け
て、ＤＨＣＰサーバはＩＰアドレスをモジュール２６０
に与える。ＤＨＣＰに関する詳細情報は、Ｍｉｃｒｏｓ
ｏｆｔＣｏｒｐｏｒａｔｉｏｎ（Ｒｅｄｍｏｎｄ，
Ｗａｓｈｉｎｇｔｏｎ）から入手することができる。

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

【００６５】コントローラ２５４は、さらに、エンジン
２５２の実行を制御することを担当している。この制御
は、エンジン２５２の実行開始、エンジン２５２の実行
終了、ストレージデバイスからのエンジン２５２のイメ
ージの再ロード、エンジン２５２の実行のデバッグ、な
どのように、さまざまな形体にすることができる。コン
トローラ２５４は、これらの制御アクションのどれをと
るか、その制御アクションをいつとるか、に関する指示
を、図３のアプリケーションオペレーション管理コンソ
ール２４２から受け取る。従って、エンジン２４２の制
御は、実際には、共同ロケーション施設１０４でローカ
ルにではなく、リモートのアプリケーションオペレーシ
ョン管理コンソール２４２によって管理される。コント
ローラ２５４は、アプリケーションオペレーション管理
コンソール２４２が、フィルタセット２５８からどのフ
ィルタを追加するか（および／または除去するか）を、
そこから指定できるインタフェースともなっている。

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

【００６７】コントローラ２５４は、さらに、ＢＭｏｎ
ｉｔｏｒ２５０に対して暗号化サポートを行うので、デ
ータを大容量ストレージデバイス２６２（例えば、磁気
ディスク、光ディスクなど）にセキュアにストアしてお
くこと、およびノード２４８とオペレーション管理コン
ソール（例えば、図３のコンソール２４０または２４
２）の間でセキュアコミュニケーションを行うことを可
能にしている。コントローラ２５４は複数の暗号鍵を保
存しており、その中には、クラスタオペレーション管理
コンソール２４０からノード２４８にアクセスするラン
ドロード用の鍵（「ランドロード鍵」と呼ぶことにす
る）、アプリケーションオペレーションコンソール２４
２からノード２４８にアクセスするノード２４８の借主
用の鍵（「テナント鍵」と呼ぶことにする）、および大
容量ストレージデバイス２６２にデータをセキュアにス
トアするためにＢＭｏｎｉｔｏｒ２５０が使用する鍵
（「ディスク鍵」と呼ぶことにする）が含まれている。

【００６８】ＢＭｏｎｉｔｏｒ２５０は公開鍵暗号化手
法（ｐｕｂｌｉｃｋｅｙｃｒｙｐｔｏｇｒａｐｈ
ｙ）を利用して、ノード２４８と管理コンソール（例え
ば、コンソール２４０と２４２）の間でセキュアコミュ
ニケーションが行われるようにしている。この公開鍵暗
号化手法は、公開鍵（ｐｕｂｌｉｃｋｅｙ）と秘密鍵
（ｐｒｉｖａｔｅｋｅｙ）の両方を含む鍵ペア（ｋｅ
ｙｐａｉｒ）と暗号化アルゴリズム（ｅｎｃｒｙｐｔ
ｉｏｎａｌｇｏｒｉｔｈｍ）をベースにしている。暗
号化アルゴリズムは、公開鍵に基づいてデータを暗号化
し、秘密鍵がなければデータが効率的に解読されないよ
うにする。従って、公開鍵保持者からのコミュニケーシ
ョンは、公開鍵を使用して暗号化されるので、秘密鍵所
有者だけがそのコミュニケーションを解読できるように
している。公開鍵暗号化手法は、周知のＲＳＡ（Ｒｉｖ
ｅｓｔ，Ｓｈａｍｉｒ，Ａｄｅｌｍａｎ）暗号化手
法のように、さまざまなものが使用可能である。暗号化
手法の基礎入門書として、ＢｒｕｃｅＳｃｈｎｅｉｒ
著「応用暗号化手法：プロトコル、アルゴリズム、およ
びＣによるソースコード（ＡｐｐｌｉｅｄＣｒｙｐｔ
ｏｇｒａｐｈｙ：Ｐｒｏｔｏｃｏｌｓ，Ａｌｇｏｒ
ｉｔｈｍｓ，ａｎｄＳｏｕｒｃｅＣｏｄｅｉｎ
Ｃ）」、ＪｏｈｎＷｉｌｅｙ＆Ｓｏｎｓ、初版
著作権所有１９９４（または第２版著作権所有１９９
６）がある。

【００６９】ＢＭｏｎｉｔｏｒ２５０は、ランドロード
とテナントの両者のための公開／秘密鍵ペアを含むよう
に初期化されている。これらの鍵ペアはＢＭｏｎｉｔｏ
ｒ２５０によって生成できるが、別の方法として、他の
コンポーネントが生成して、ＢＭｏｎｉｔｏｒ２５０に
ストアしておくこともできる（この場合、他のコンポー
ネントは鍵ペアの知識を壊さないものとして信頼されて
いる）。本明細書では、Ｕは公開鍵を示し、Ｒは秘密鍵
を示すように使用されている。ランドロード用の公開／
秘密鍵ペア２６４は（Ｕ_Ｌ，Ｒ_Ｌ）と呼ばれ、テナン
ト用の公開／秘密鍵ペア２６６は（Ｕ_Ｔ，Ｒ_Ｔ）と呼
ばれる。ＢＭｏｎｉｔｏｒ２５０は、公開鍵Ｕ_ＬとＵ_Ｔ
をランドロードが利用できるようにしているが、秘密鍵
Ｒ_ＬとＲ _Ｔは秘密に保っている。図示の例では、ＢＭ
ｏｎｉｔｏｒ２５０は、秘密鍵Ｒ _ＬとＲ_Ｔを公開する
ことがないので、ランドロードだけでなく、テナント
も、公開鍵を使用して暗号化した情報（例えば、それぞ
れ、図３のクラスタオペレーション管理コンソール２４
０とアプリケーションオペレーション管理コンソール２
４２を通して）が、ＢＭｏｎｉｔｏｒ２５０以外の、他
のどのエンティティによっても解読されないことが保証
される。

【００７０】ランドロードに公開鍵Ｕ_ＬとＵ_Ｔが与えら
れると、ランドロードは特定のテナントにノード２１０
を割り当て、そのテナントに公開鍵Ｕ_Ｔを与えることが
できる。この公開鍵Ｕ_Ｔを使用すると、テナントは、Ｂ
Ｍｏｎｉｔｏｒ２５０だけが解読できる（秘密鍵Ｒ_Ｔを
使用して）、ＢＭｏｎｉｔｏｒ２５０へのコミュニケー
ションを解読することができる。必ずしも必要ではない
が、テナントにとって賢明である初期ステップでは、Ｂ
Ｍｏｎｉｔｏｒ２５０が新しい公開／秘密鍵ペア
（Ｕ_Ｔ，Ｒ_Ｔ）を生成することをＢＭｏｎｉｔｏｒ２
５０に要求するようになっている。この要求を受けて、
ＢＭｏｎｉｔｏｒ２５０の鍵ジェネレータ（ｋｅｙｇ
ｅｎｅｒａｔｏｒ）２６８は、さまざまな周知方法のい
ずれかで新しい公開／秘密鍵ペアを生成し、その新鍵ペ
アを鍵ペア２６６としてストアし、新公開鍵Ｕ_Ｔをテナ
ントに送り返す。新鍵ペアを生成すると、テナントは、
ランドロードを含めて、どの他のエンティティにも、テ
ナントの公開鍵Ｕ_Ｔが気づかれないことが保証される。
さらに、テナントは、新しい鍵ペアを別の時期に生成さ
せることも可能になっている。

【００７１】ＢＭｏｎｉｔｏｒ２５０は、どのエンティ
ティが新しい公開／秘密鍵ペアを要求できるかについて
制約を設けている。テナントは、新しいテナント公開／
秘密鍵ペアを要求できるが、新しいランドロード公開／
秘密鍵ペアを要求することはできない。他方、ランドロ
ードは、新しいランドロード公開／秘密鍵ペアだけでな
く、新しいテナント公開／秘密鍵ペアも要求することが
できる。新しい公開／秘密鍵ペアの要求を受け取ると、
コントローラ２５４は、要求者がテナントであるか、ラ
ンドロードであるかを確かめてから（例えば、リモート
ログインプロシージャ、パスワード検証、要求者がノー
ド２４８と通信している、あるいは結合されている仕
方、などに基づいて）、新鍵ペアを生成するようにして
いる。

【００７２】ＢＭｏｎｉｔｏｒ２５０と、ランドロード
およびテナント制御デバイス（例えば、それぞれオペレ
ーション管理コンソール２４０と２４２）との間の双方
向コミュニケーションをセキュアに保つために、ランド
ロードとテナント制御デバイスも、公開／秘密鍵ペアを
生成すること（さもなければ、公開／秘密鍵ペアが割り
当てられること）が可能になっている。そのような場合
には、コンソール２４０と２５０は、セキュアに通信し
たいと望んでいる（あるいはそのように期待している）
相手側ノード２４８のＢＭｏｎｉｔｏｒ２５０にそれぞ
れの公開鍵を伝えることができる。コンソールの公開鍵
がＢＭｏｎｉｔｏｒ２５０に知らされると、ＢＭｏｎｉ
ｔｏｒ２５０は、そのコンソールへのコミュニケーショ
ンを、その公開鍵を使用して暗号化できるので、秘密鍵
をもつコンソール以外の他のデバイスがそのコミュニケ
ーションを読み取ることが防止される。

【００７３】ＢＭｏｎｉｔｏｒ２５０はディスク鍵２７
０も保持しており、これは、１つまたは２つ以上の対称
鍵２７２と２７４を使用して生成される（ここで、対称
鍵（ｓｙｍｍｅｔｒｉｃｋｅｙｓ）とは、秘密鍵暗号
化で使用される秘密鍵のことである）。対称鍵でもある
ディスク鍵２７０は、情報を大容量ストレージデバイス
２６２にストアするためにＢＭｏｎｉｔｏｒ２５０によ
って使用される。ＢＭｏｎｉｔｏｒ２５０はディスク鍵
２７０をセキュアに保っているので、これは、ノード２
４８が大容量ストレージデバイス２６２にストアするデ
ータを暗号化し、ノード２４８が大容量ストレージデバ
イス２６２から取り出すデータを解読するためにだけ使
用される（従って、ランドロードとテナントを含めて、
他のどのエンティティにも、ディスク鍵２７０を知らせ
ないで済むようになっている）。別の方法として、ラン
ドロードまたはテナントにディスク鍵２７０を知らせる
ことも、あるいはディスク鍵２７０のベースとなってい
る別の鍵を知らせることも可能である。

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

【００７５】ディスク鍵２７０は、対称鍵２７２と２７
４に基づいて生成される。本明細書では、Ｋは対称鍵を
指すために使用されているので、Ｋ_Ｌはランドロード対
称鍵（鍵２７２）を指し、Ｋ_Ｔはテナント対称鍵（鍵２
７４）を指している。個別鍵２７２と２７４を生成する
方法としては、従来のさまざまな方法が可能である（例
えば、乱数ジェネレータに基づいて）。ディスク鍵２７
０はＫ_Ｌ鍵が単独である場合と、Ｋ_Ｌ鍵とＫ_Ｔ鍵の組み
合わせである場合とがある。ノード２１０が現在テナン
トにリースされていない場合や、テナントがＫ_Ｔ鍵を設
定していなかった場合には、コントローラ２５４は、Ｋ
_Ｌ鍵をディスク鍵２７０として保存している。しかし、
ノード２４８がテナントにリースされていて、テナント
がＫ_Ｔ鍵を設定している場合には、ディスク鍵２７０は
Ｋ_Ｌ鍵とＫ_Ｔ鍵の組み合わせになっている。Ｋ_Ｌ鍵とＫ
_Ｔ鍵の組み合わせはさまざまなものが可能であり、ある
実装では、一方の鍵を使用して他方の鍵を暗号化するよ
うに組み合わされており、暗号化された鍵がディスク鍵
２７０になっている。従って、大容量ストレージデバイ
ス２６２にストアされたデータは、テナントが対称鍵Ｋ
_Ｔを設定していない場合であっても、常に暗号化されて
いる。さらに、ランドロードとテナントがそれぞれの鍵
Ｋ_ＬとＫ_Ｔを知っている場合には、これらの鍵を組み合
わせると、データを暗号化するために使用できる鍵が得
られるので、ランドロードとテナントのどちらも、個別
的にデータを解読することができないことになる。

【００７６】図示の例では、初期時には、ノード２４８
に対称鍵Ｋ_ＬとＫ_Ｔが与えられていない。ランドロード
はノード２４８を初期化するとき、新しい鍵Ｋ_Ｌを要求
し（例えば、図３のクラスタオペレーション管理コンソ
ール２４０を通して）、この要求に応答して、鍵ジェネ
レータ２６８は新しい鍵を生成し、コントローラ２５４
はこの新生成の鍵を鍵２７２として保存しておく。同様
に、テナントが初めてノード２４８をリースするとき、
ノード２４８にはまだテナント対称鍵Ｋ_Ｔが与えられて
いない。テナントは、新しい鍵Ｋ_Ｔの要求を通知するこ
とができ（例えば、図３のアプリケーションオペレーシ
ョン管理コンソール２４２を通して）、この要求に応答
して、鍵ジェネレータ２６８は新しい鍵を生成し、コン
トローラ２５４はこの新生成の鍵を鍵２７４として保存
しておく。さらに、新しい鍵Ｋ_ＴまたはＫ_Ｌが生成され
るたびに、コントローラ２５４は新しいディスク鍵２７
０を生成する。

【００７７】図５にはランドロード鍵とテナント鍵（Ｋ
_ＬとＫ_Ｔ）だけが示されているが、別の方法として、追
加の対称鍵（例えば、サブテナント、サブランドロード
などからの）を組み合わせて、ディスク鍵２７０を得る
ことも可能である。例えば、３つの対称鍵がある場合、
第１の鍵を第２の鍵で暗号化し、その結果を第３の鍵で
暗号化するように組み合わせると、ディスク鍵２７０を
得ることができる。例えば、サブテナント用に追加の対
称鍵を使用することも可能である。

【００７８】ランドロードは、テナント鍵ペアであって
も、ランドロード鍵ペアであっても、新しい公開／秘密
鍵ペアをＢＭｏｎｉｔｏｒ２５０に要求することもでき
る。新鍵ペアを要求すると、例えば、ランドロードは、
ノード２４８を一方のテナントから別のテナントに再割
り当てすることができる。１つの例として、テナントが
ノード２４８を必要としなくなった場合（またはノード
の必要リース料の支払いを行わない場合）、ランドロー
ドはＢＭｏｎｉｔｏｒ２５０と通信して（例えば、図３
のコンソール２４０を通して）テナントの公開／秘密鍵
ペアを変更することができる（変更すると、テナントは
新鍵をもっていないので、テナントからのどのコミュニ
ケーションも、ＢＭｏｎｉｔｏｒ２５０によって解読さ
れることが禁止されることになる）。さらに、ランドロ
ードは、ランドロード用の新しい公開／秘密鍵ペアを要
求することも可能である。これは、特定のインターバル
で行うことも、ランドロードが新鍵を必要としたときに
だけ行うこともできる（例えば、安全上の配慮から）。

【００７９】ある実装では、ＢＭｏｎｉｔｏｒ２５０
は、新しいランドロード秘密鍵Ｒ_Ｌを生成するたびに、
ディスク鍵２７０とランドロード対称鍵Ｋ_Ｌの両方を破
棄し、新しい鍵Ｋ_Ｌ（および新しいディスク鍵２７０）
を生成する。鍵Ｋ_Ｌとディスク鍵２７０を置き換えると
（および旧鍵の記録をとっておかないと）、ランドロー
ドは、その鍵を変更した後、ノード２１０に以前にスト
アされていたどのテナントデータも、アクセスされない
ことを保証することができる。従って、ランドロード
は、テナントがノード２４８に以前にストアされていた
データにアクセスするのを禁止したいときだけ、新しい
公開／秘密鍵ペアを生成するようにする注意が必要であ
る。

【００８０】さらに、ＢＭｏｎｉｔｏｒ２５０は、新し
いテナント秘密鍵Ｒ_Ｔを生成するたびに、ディスク鍵２
７０とテナント対称鍵Ｋ_Ｔの両方を、新しく生成した鍵
Ｋ_Ｔ（および新しいディスク鍵２７０）で置き換えるこ
とも可能である。このようにすると、テナントはデータ
の暗号化方法を望み通りに変更できるので、ノード２４
８にストアされているデータのセキュリティが強化され
ることになる。しかし、ＢＭｏｎｉｔｏｒ２５０が旧鍵
Ｋ_Ｔとディスク鍵２７０を破棄したときは、テナント
は、ノードに以前にストアされていたデータが必要でな
くなったときだけ（例えば、別の場所にバックアップが
とられている）、新しいテナント秘密鍵Ｒ _Ｔを要求する
ようにする注意が必要である。

【００８１】なお、ここで注意すべきことは、異なるノ
ード２４８には異なる鍵（鍵２６４、２６６、および２
７０）が与えられるのが代表的であることである。別の
方法として、複数のノードに同じ鍵（例えば、鍵２７
０）を使用させることも可能である。しかし、そのよう
な場合は、鍵の伝達（例えば、ノード２４８間の）は、
セキュリティが危険にさらされないようにセキュアに行
われるようにする配慮が必要である。例えば、追加の公
開／秘密鍵ペアを、２つのノード２４８のＢＭｏｎｉｔ
ｏｒ２５０に使用させると、相互間の情報の伝達がセキ
ュアに行われることになる。

【００８２】従って、権利が保証され、行使されるリー
スハードウェア環境を設定することができる。ランドロ
ードは、ノードを複数の異なるテナントにリースし、異
なるテナントにリースされたノードが相互に通信するの
を防止する境界を設定することができる。テナントは、
リースしたノードに、他のテナントではなく、管理のた
めに自分だけがアクセスできること、および他のだれも
がアクセスできないようにデータがセキュアにノードに
ストアされること（たとえテナントがそのハードウェア
使用を放棄または縮小した場合でも）が保証されること
になる。さらに、ランドロードとテナントのどちらも、
セキュアにストアされたデータがテナントのいずれかに
よって危険にさらされることなく、ランドロードが機器
を移動し、どのノードが個人に割り当てられているかを
変更し、ハードウェア（例えば、大容量ストレージデバ
イス）を除去できる、といったが保証が得られることに
なる。

【００８３】図６は、本発明のいくつかの実施形態によ
る暗号鍵生成と配布のための例示プロセスを示す。初め
に、コンピュータ（例えば、図５のノード２４８）は、
ランドロードとテナントの両方に対する公開／秘密鍵ペ
アを特定する（ステップ２８０）。この特定は、以前に
生成された鍵ペアにアクセスすることによって行うこと
も、コンピュータ自身が新しい鍵を生成することによっ
て行うこともできる。コンピュータは、ランドロード鍵
ペアからのランドロード秘密鍵とテナント鍵ペアからの
テナント秘密鍵の両方を秘密に保っているが、ランドロ
ード鍵ペアからのランドロード公開鍵とテナント鍵ペア
からのテナント公開鍵をランドロードに転送する。図示
の例では、ランドロードは、図３のクラスタオペレーシ
ョン管理コンソール２４０で表されているが、これとは
別に、他のデバイスまたはエンティティでランドロード
を表すことも可能である。

【００８４】そのあと、ランドロードはテナント公開鍵
をテナントに転送する（ステップ２４８）。図示の例で
は、テナントは図３のアプリケーションオペレーション
管理コンソール２４２で表されているが、これとは別
に、他のデバイスまたはエンティティでテナントを表す
ことも可能である。そのあと、テナントはコンピュータ
と通信して、新しいテナント鍵ペアを生成する（ステッ
プ２８６）。コンピュータは、新しい鍵ペアからのテナ
ント秘密鍵を秘密に保ち、その新鍵ペアからのテナント
公開鍵をテナントに転送する（ステップ２８８）。その
あと、テナントは、新しいテナント公開鍵を使用してセ
キュアメッセージ（データ、指示、要求など）をコンピ
ュータに伝達することが可能になり（ステップ２９
０）、他方、ランドロードは、ランドロード公開鍵を使
用してセキュアメッセージをコンピュータに伝達するこ
とが可能になる（ステップ２９２）。

【００８５】図７は、本発明のいくつかの実施形態によ
るクラスタオペレーション管理コンソールのオペレーシ
ョンのための例示プロセスを示す。図７のプロセスは、
共同ロケーション施設に置かれたクラスタオペレーショ
ン管理コンソールに実装され、ソフトウェアで実行され
ることが可能になっている。

【００８６】初めに、クラスタオペレーション管理コン
ソールは、サーバクラスタ内のノードを、サーバクラス
タの境界（存在する場合）をもつ構成にする（ステップ
３００）。この構成は、クラスタオペレーション管理コ
ンソールが、フィルタをサーバクラスタ（１つまたは複
数）内のノードに伝えることによって行われる。

【００８７】そのあと、サーバクラスタ内のハードウェ
アオペレーションは、ハードウェア障害の有無について
絶えずモニタリングされる（ステップ３０２と３０
４）。ハードウェア障害が検出されると、訂正アクショ
ンがとられ（ステップ３０６）、ハードウェアオペレー
ションのモニタリングが継続される。上述したように、
さまざまな訂正アクションをとることが可能である。な
お、訂正アクションに基づいて（あるいは別の時期
に）、ノードは新しいクラスタ境界をもつように再構成
することが可能である（ステップ３００）。

【００８８】図８は、本発明のいくつかの実施形態によ
るアプリケーションオペレーション管理コンソールのオ
ペレーションのための例示プロセスを示す。図８のプロ
セスは、共同ロケーション施設から離れた個所に置かれ
ているアプリケーションオペレーション管理コンソール
に実装され、ソフトウェアで実行されることが可能にな
っている。

【００８９】初めに、アプリケーションオペレーション
管理コンソールは、サーバクラスタ内のノードを、サー
バクラスタのサブ境界（存在する場合）をもつ構成にす
る（ステップ３２０）。この構成は、アプリケーション
オペレーション管理コンソールが、フィルタをサーバク
ラスタ（１つまたは複数）内のノードに伝えることによ
って行われる。

【００９０】そのあと、サーバクラスタ内のソフトウェ
アオペレーションは、ソフトウェア障害が検出されるま
で絶えずモニタリングされる（ステップ３２２と３２
４）。このソフトウェア障害としては、特定ソフトウェ
アエンジンの障害（例えば、そのエンジンに障害が起き
たが、他のエンジンはそのまま稼動している）、あるい
はノード全体の障害（例えば、ノード全体がハングアッ
プしている）がある。ソフトウェア障害が検出される
と、訂正アクションがとられ（ステップ３２６）、ソフ
トウェアオペレーションのモニタリングが継続される。
上述したように、さまざまな訂正アクションをとること
が可能である。なお、訂正アクションに基づいて（ある
いはオペレーション中の別の時期に）、サーバコンピュ
ータは、新しいサブ境界をもつように再構成することが
可能である（ステップ３２０）。

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

【００９２】

【発明の効果】本発明の一形態によれば、多層管理アー
キテクチャ（ｍｕｌｔｉ−ｔｉｅｒｅｄｍａｎａｇｅ
ｍｅｎｔａｒｃｈｉｔｅｃｔｕｒｅ）が採用され、こ
のアーキテクチャは、アプリケーション開発層（ａｐｐ
ｌｉｃａｔｉｏｎｄｅｖｅｌｏｐｍｅｎｔｔｉｅ
ｒ）、アプリケーションオペレーション層（ａｐｐｌｉ
ｃａｔｉｏｎｏｐｅｒａｔｉｏｎｓｔｉｅｒ）、お
よびクラスタオペレーション層（ｃｌｕｓｔｅｒｏｐ
ｅｒａｔｉｏｎｓｔｉｅｒ）を含んでいる。アプリケ
ーション開発層では、アプリケーションは、１つまたは
２つ以上のサーバコンピュータ上で実行されるように開
発される。アプリケーションオペレーション層では、ア
プリケーションの実行が管理され、共同ロケーション施
設に置かれたサーバクラスタ内のサブ境界（ｓｕｂ−ｂ
ｏｕｎｄａｒｙ）が設定可能になる。クラスタオペレー
ション層では、サーバコンピュータのオペレーション
は、どのアプリケーションが１つまたは２つ以上のサー
バコンピュータ上で実行されているかに関係なく、管理
され、共同ロケーション施設に置かれたサーバクラスタ
の境界が設定可能になる。以上により、共同ロケーショ
ン施設における共有コンピュータの分散管理が改善され
る。

【００９３】本発明の別の形態によれば、共同ロケーシ
ョン施設は、各々が異なるカスタマーに対応している複
数のサーバクラスタを含んでいる。各々のサーバクラス
タごとに、クラスタオペレーション管理コンソールは、
クラスタのハードウェアオペレーションを管理するため
に共同ロケーション施設にローカルに実装され、アプリ
ケーション管理コンソールは、クラスタのソフトウェア
オペレーションを管理するために、共同ロケーション施
設から離れたロケーションに実装されている。ハードウ
ェアに障害が起きた場合は、クラスタオペレーション管
理コンソールは訂正アクションをとる（例えば、共同ロ
ケーション施設にいるアドミニストレータに通知する
か、あるいは自身で障害の訂正を試みる）。ソフトウェ
アに障害が起きた場合は、アプリケーションオペレーシ
ョン管理コンソールは訂正アクションをとる（例えば、
カスタマーのアドミニストレータの一人に通知するか、
あるいは自身で障害の訂正を試みる）。

【００９４】本発明の別の形態によれば、サーバクラス
タの境界は、クラスタオペレーション管理コンソールに
よって設定される。境界を設定すると、データがサーバ
クラスタ内のノードにだけルーチングされ、共同ロケー
ション施設に置かれていて、サーバクラスタに属してい
ない他のノードにはルーチングされないことが保証され
る。さらに、サーバクラスタ内のサブ境界はアプリケー
ションオペレーション管理コンソールによって設定さ
れ、データがサーバクラスタ内の特定ノードにだけルー
チングされることを保証する。

【００９５】本発明の別の形態によれば、共同ロケーシ
ョン施設に置かれる予定の、複数のサーバコンピュータ
に対する権利はカスタマーに販売され、多層管理方式
（ｍｕｌｔｉｐｌｅ−ｔｉｅｒｅｄｍａｎａｇｅｍｅ
ｎｔｓｃｈｅｍｅ）がサーバコンピュータで実施され
る。この多層管理方式によれば、サーバコンピュータの
ハードウェアオペレーションは、共同ロケーション施設
でローカルに管理されるのに対し、サーバコンピュータ
のソフトウェアオペレーションは、共同ロケーション施
設から離れたロケーションから管理される。サーバコン
ピュータは、カスタマーに販売することも、カスタマー
にリースすることも可能である。

【００９６】本発明の別の形態によれば、ランドロード
／テナント（ｌａｎｄｌｏｒｄ／ｔｅｎａｎｔ）関係
は、共同ロケーション施設で１つまたは２つ以上のサー
バコンピュータを使用して構築される。共同ロケーショ
ン施設のオペレータは、施設とサーバの両方を提供する
（従って、このオペレータは「ランドロード」と見るこ
とができる）。これに対して、施設のカスタマーは、施
設の使用だけでなく、その施設のサーバもリースする
（従って、このカスタマーは「テナント」と見ることが
できる）。このランドロード／テナント関係によると、
ランドロードは、テナントが異なるごとにコンピュータ
クラスタを設定し、テナントのデータがそのクラスタを
越えて（および別のテナントのクラスタに）渡されない
ように、クラスタ間に境界を設定することが可能であ
る。さらに、暗号化がさまざまな形で採用されているの
で、テナントがそのリースを終了したり、リースしてい
るサーバの１つをランドロードに返却した場合でも、リ
ースしているサーバにストアされている情報が他人に見
られない。

【００９７】本発明の別の形態によれば、多層管理アー
キテクチャは、共同ロケーション施設に属していないコ
ンピュータの管理において採用される。この多層管理ア
ーキテクチャは、ビジネスやホームなどのような、さま
ざまな環境でコンピュータ（サーバコンピュータである
か否かに関係なく）を管理するために使用される。

【図面の簡単な説明】

【図１】本発明のいくつかの実施形態で使用できるよう
な、クライアント／サーバネットワークシステムと環境
を示す図である。

【図２】本発明のいくつかの実施形態に従って使用でき
るコンピュータの例を示す概要図である。

【図３】例示の共同ロケーション施設を示す詳細ブロッ
ク図である。

【図４】例示の多層管理アーキテクチャを示すブロック
図である。

【図５】本発明のいくつかの実施形態による例示のノー
ドを示す詳細ブロック図である。

【図６】本発明のいくつかの実施形態による暗号鍵の生
成と配布のための例示プロセスを示すフローチャートで
ある。

【図７】本発明のいくつかの実施形態によるクラスタ管
理コンソールのオペレーションのための例示プロセスを
示すフローチャートである。

【図８】本発明のいくつかの実施形態によるアプリケー
ションオペレーション管理コンソールのオペレーション
のための例示プロセスを示すフローチャートである。

【符号の説明】

１０２クライアントコンピュータ１０４共同ロケーション施設１０６サーバコンピュータ（サーバクラスタ）１０８インターネット２１０ノード２３０クラスタオペレーション管理層２３２アプリケーションオペレーション管理層２３４アプリケーション開発層２４０クラスタオペレーション管理コンソール２４２アプリケーションオペレーション管理コンソー
ル

───────────────────────────────────────────────────── フロントページの続き (72)発明者アーマーハイドリーアメリカ合衆国 98033 ワシントン州カークランドノースイースト 107 プレイス 12511 (72)発明者スティーブンピー．レビアメリカ合衆国 98052 ワシントン州レッドモンドノースイースト 41 ストリート 16612 (72)発明者デービッドエス．スチューツアメリカ合衆国 98053 ワシントン州レッドモンドノースイースト 116 19610 (72)発明者バサムタバラアメリカ合衆国 98107 ワシントン州シアトルベイカーアベニューノースイースト 4119 (72)発明者ロバートブイ．ウエランドアメリカ合衆国 98122 ワシントン州シアトル 38 アベニュー 1100 Ｆターム(参考） 5B017 AA03 BA05 BA06 CA16 5B082 EA11 GA11 5B085 AC01 AC11 AE00 AE29 BA07 5J104 JA21 NA02 PA07

Claims

【特許請求の範囲】

【請求項１】アプリケーションが１つまたは２つ以上
のコンピュータ上で実行されるように開発されるアプリ
ケーション開発層と、アプリケーションの実行が管理されるアプリケーション
オペレーション層と、どのアプリケーションが１つまたは２つ以上のコンピュ
ータ上で実行されているかに係わりなく、コンピュータ
のオペレーションを管理するクラスタオペレーション層
とを備えたことを特徴とする多層管理アーキテクチャ。
【請求項２】請求項１に記載の多層管理アーキテクチ
ャにおいて、前記クラスタオペレーション層は、コンピ
ュータクラスタに属していない複数の他のコンピュータ
が該コンピュータクラスタ内の１つまたは２つ以上のコ
ンピュータにアクセスするのを防止するようにコンピュ
ータクラスタ境界をセキュアにすることを担当すること
を特徴とする多層管理アーキテクチャ。
【請求項３】請求項１に記載の多層管理アーキテクチ
ャにおいて、前記アプリケーションオペレーション層は
コンピュータクラスタ内のコンピュータ間のコミュニケ
ーションを制限するようにコンピュータクラスタ境界内
のサブ境界をセキュアにすることを担当することを特徴
とする多層管理アーキテクチャ。
【請求項４】請求項１に記載の多層管理アーキテクチ
ャにおいて、前記アプリケーションオペレーション層は
前記１つまたは２つ以上のコンピュータから離れたロケ
ーションに置かれているアプリケーションオペレーショ
ン管理コンソールに実装されることを特徴とする多層管
理アーキテクチャ。
【請求項５】請求項１に記載の多層管理アーキテクチ
ャにおいて、前記クラスタオペレーション層は前記１つ
または２つ以上のコンピュータと同じロケーションに置
かれているクラスタオペレーション管理コンソールに実
装されることを特徴とする多層管理アーキテクチャ。
【請求項６】請求項１に記載の多層管理アーキテクチ
ャにおいて、前記アプリケーションオペレーション層は
前記１つまたは２つ以上のコンピュータ上のアプリケー
ションプロセスの実行をモニタリングし、前記アプリケ
ーションプロセスの障害を検出することを特徴とする多
層管理アーキテクチャ。
【請求項７】請求項１に記載の多層管理アーキテクチ
ャにおいて、アプリケーションオペレーション層はコン
ピュータの１つでソフトウェア障害が起きたとき、その
障害に見合う訂正アクションをとることを特徴とする多
層管理アーキテクチャ。
【請求項８】請求項７に記載の多層管理アーキテクチ
ャにおいて、前記訂正アクションはコンピュータをリブ
ートするアクションを含むことを特徴とする多層管理ア
ーキテクチャ。
【請求項９】請求項７に記載の管理アーキテクチャに
おいて、前記訂正アクションはアドミニストレータに障
害を通知するアクションを含むことを特徴とする管理ア
ーキテクチャ。
【請求項１０】請求項１に記載の多層管理アーキテク
チャにおいて、前記クラスタオペレーション層は、前記
１つまたは２つ以上のコンピュータのハードウェアオペ
レーションをモニタリングし、ハードウェアの障害を検
出することを特徴とする多層管理アーキテクチャ。
【請求項１１】請求項１に記載の多層管理アーキテク
チャにおいて、前記クラスタオペレーション層は、コン
ピュータの１つのハードウェアに障害が起きたとき、そ
の障害に見合う訂正アクションをとることを特徴とする
多層管理アーキテクチャ。
【請求項１２】請求項１１に記載の多層管理アーキテ
クチャにおいて、前記訂正アクションはコンピュータを
リブートするアクションを含むことを特徴とする多層管
理アーキテクチャ。
【請求項１３】請求項１１に記載の多層管理アーキテ
クチャにおいて、前記訂正アクションは共同ロケーショ
ン施設のアドミニストレータに通知するアクションを含
むことを特徴とする多層管理アーキテクチャ。
【請求項１４】請求項１１に記載の多層管理アーキテ
クチャにおいて、前記１つまたは２つ以上のコンピュー
タは共同ロケーション施設の１つまたは２つ以上のクラ
スタに置かれていることを特徴とする多層管理アーキテ
クチャ。
【請求項１５】各々が異なるカスタマーに対応してい
る複数のノードクラスタと、当該複数のノードクラスタの少なくとも１つに対応して
いて、当該少なくとも１つのノードクラスタのハードウ
ェアオペレーションを管理するように構成されたクラス
タオペレーション管理コンソールとを備えたことを特徴
とする共同ロケーション施設システム。
【請求項１６】請求項１５に記載の共同ロケーション
施設システムにおいて、さらに、前記複数のノードクラ
スタの各々に対応する、異なるクラスタオペレーション
管理コンソールを含むことを特徴とするシステム。
【請求項１７】請求項１５に記載の共同ロケーション
施設システムにおいて、前記複数のノードクラスタの各
々は、複数のサーバコンピュータをそのノードとして含
んでいることを特徴とする共同ロケーション施設システ
ム。
【請求項１８】請求項１５に記載の共同ロケーション
施設システムにおいて、ハードウェアオペレーション
は、大容量ストレージデバイスオペレーション、メモリ
デバイスオペレーションおよびネットワークインタフェ
ースオペレーションの中の１つまたは２つ以上と、プロ
セッサオペレーションとを含むことを特徴とする共同ロ
ケーション施設システム。
【請求項１９】請求項１５に記載の共同ロケーション
施設システムにおいて、前記複数のノードクラスタの各
々は、共同ロケーション施設から離れた個所に置かれた
アプリケーションオペレーション管理コンソールからノ
ード制御コマンドを受け取るように構成された複数のノ
ードを含むことを特徴とする共同ロケーション施設シス
テム。
【請求項２０】請求項１９に記載の共同ロケーション
施設システムにおいて、各ノードクラスタ内の各ノード
は、ノードクラスタに対応するカスタマーと関連付けら
れたアプリケーションオペレーション管理コンソールか
ら、公開鍵を使用して暗号化された形で受け取られたコ
ミュニケーションを、ノードが秘密鍵を使用して解読可
能なように構成されていることを特徴とする共同ロケー
ション施設システム。
【請求項２１】請求１５に記載の共同ロケーション施
設システムにおいて、前記複数のクラスタ内の各ノード
に結合されたデータトランスポート媒体をさらに含み、
各ノードはそのデータトランスポート媒体を通して外部
ネットワークにアクセス可能としたことを特徴とする共
同ロケーション施設システム。
【請求項２２】請求項１５に記載の共同ロケーション
施設システムにおいて、外部ネットワークはインターネ
ットを含むことを特徴とする共同ロケーション施設シス
テム。
【請求項２３】請求項１５に記載の共同ロケーション
施設システムにおいて、各ノードクラスタ内の各ノード
は、ノードクラスタの境界をもつ構成となっていること
を特徴とする共同ロケーション施設システム。
【請求項２４】請求項１５に記載の共同ロケーション
施設システムにおいて、各ノードクラスタ内の各ノード
は、クラスタオペレーション管理コンソールから、公開
鍵を使用して暗号化された形で受け取られたコミュニケ
ーションを、ノードが秘密鍵を使用して解読可能に構成
されていることを特徴とする共同ロケーション施設シス
テム。
【請求項２５】請求項１５に記載の共同ロケーション
施設システムにおいて、ノードクラスタ内のノードの１
つまたは２つ以上は、共同ロケーション施設のオペレー
タからカスタマーによってリースされることを特徴とす
る共同ロケーション施設システム。
【請求項２６】共同ロケーション施設に置かれたコン
ピュータのクラスタのハードウェアオペレーションを、
前記共同ロケーション施設でモニタリングし、クラスタ内のコンピュータの１つにおけるハードウェア
障害を検出し、ハードウェア障害が検出された場合に、
そのハードウェア障害を訂正するアクションを実行する
ことを特徴とする方法。
【請求項２７】請求項２６に記載の方法において、前
記コンピュータのクラスタは、共同ロケーション施設に
置かれた複数のコンピュータクラスタの１つであること
を特徴とする方法。
【請求項２８】請求項２６に記載の方法において、前
記アクションは、共同ロケーション施設のアドミニスト
レータに障害を通知するアクションを含むことを特徴と
する方法。
【請求項２９】請求項２６に記載の方法において、前
記アクションは、障害を起こしたハードウェアを含むコ
ンピュータをリセットするアクションを含むことを特徴
とする方法。
【請求項３０】請求項２６に記載の方法において、前
記ハードウェアオペレーションは、大容量ストレージデ
バイスオペレーション、メモリデバイスオペレーショ
ン、およびネットワークインタフェースオペレーション
の中の１つまたは２つ以上と、プロセッサオペレーショ
ンとを含むことを特徴とする方法。
【請求項３１】請求項２６に記載の方法において、ク
ラスタに属していない複数の他のコンピュータがクラス
タ内の１つまたは２つ以上のコンピュータにアクセスす
るのを防止する境界を設けるように、クラスタ内の各コ
ンピュータを構成することを特徴とする方法。
【請求項３２】請求項２６に記載の方法を実行するた
めの、プロセッサによって実行可能なコンピュータプロ
グラムを格納したことを特徴とする１つまたは２つ以上
のコンピュータ読取可能メモリ。
【請求項３３】共同ロケーション施設に置かれたコン
ピュータのクラスのソフトウェアオペレーションを、共
同ロケーション施設から離れたロケーションからモニタ
リングし、クラスタ内のコンピュータの１つにおけるソフトウェア
障害を検出し、ソフトウェア障害が検出された場合には、そのソフトウ
ェア障害を訂正するアクションを実行することを特徴と
する方法。
【請求項３４】請求項３３に記載の方法において、前
記コンピュータのクラスタは、前記共同ロケーション施
設に置かれている複数のコンピュータクラスタの１つで
あることを特徴とする方法。
【請求項３５】請求項３３に記載の方法において、前
記アクションは、アドミニストレータに障害を通知する
アクションを含むことを特徴とする方法。
【請求項３６】請求項３３に記載の方法において、前
記アクションは、障害を起こしたソフトウェアを実行し
ているコンピュータをリセットするアクションを含むこ
とを特徴とする方法。
【請求項３７】請求項３３に記載の方法において、ク
ラスタ内の１つまたは２つ以上の第１コンピュータがク
ラスタ内の１つまたは２つ以上の第２コンピュータにア
クセスするのを防止するサブ境界を設けるように、クラ
スタ内の１つまたは２つ以上のコンピュータを構成する
ことを特徴とする方法。
【請求項３８】請求項３３に記載の方法において、ク
ラスタ内のコンピュータの１つ上にソフトウェアコンポ
ーネントをロードすることを管理することを特徴とする
方法。
【請求項３９】請求項３３に記載の方法において、ソ
フトウェア障害は、アプリケーションプロセスのハング
アップ、スレッドのハングアップ、およびアプリケーシ
ョンプロセス実行時エラーのうちの、１つまたは２つ以
上を含むことを特徴とする方法。
【請求項４０】コンピュータのクラスタから離れた個
所に置かれていて、請求項３３に記載の方法を実装する
ことを特徴とするコンピュータ。
【請求項４１】請求項３３に記載の方法において、モ
ニタリングし、検出し、および実行することは、リモー
トの前記コンピュータに実装されており、さらに、公開
鍵暗号手法を使用して、前記リモートのコンピュータと
コンピュータクラスタ内の各コンピュータ間のコミュニ
ケーションをセキュアにすることを特徴とする方法。
【請求項４２】請求項３３に記載の方法を実行するた
めの、プロセッサによって実行可能であるコンピュータ
プログラムを格納したことを特徴とする１つまたは２つ
以上のコンピュータ読取可能メモリ。
【請求項４３】１つまたは２つ以上のプロセッサによ
って実行されるときに、その１つまたは２つ以上のプロ
セッサに、共同ロケーション施設に置かれたコンピュータクラスタ
のソフトウェアオペレーションを、共同ロケーション施
設から離れたロケーションからモニタリングし、クラスタ内のコンピュータの１つで実行されているソフ
トウェアのオペレーションに障害が起きたとき、それに
見合う訂正アクションをとるアクションを実行させるコ
ンピュータプログラムが格納されていることを特徴とす
る１つまたは２つ以上のコンピュータ読取可能媒体。
【請求項４４】請求項４３に記載の１つまたは２つ以
上のコンピュータ読取可能媒体において、前記訂正アク
ションはアドミニストレータに障害を通知するアクショ
ンを含むことを特徴とする１つまたは２つ以上のコンピ
ュータ読取可能媒体。
【請求項４５】請求項４３に記載の１つまたは２つ以
上のコンピュータ読取可能媒体において、前記訂正アク
ションは、障害を起こしたソフトウェアを実行している
コンピュータをリセットするアクションを含むことを特
徴とする１つまたは２つ以上のコンピュータ読取可能媒
体。
【請求項４６】請求項４３に記載の１つまたは２つ以
上のコンピュータ読取可能媒体において、コンピュータ
プログラムは、実行されたとき、クラスタに属していな
い複数の他のコンピュータがクラスタ内の１つまたは２
つ以上のコンピュータにアクセスするのを防止する境界
を設けるように、クラスタ内の各コンピュータを構成す
るアクションを、さらに１つまたは２つ以上のプロセッ
サに実行させることを特徴とする１つまたは２つ以上の
コンピュータ読取可能媒体。
【請求項４７】請求項４３に記載の１つまたは２つ以
上のコンピュータ読取可能媒体において、ソフトウェア
のオペレーションの障害は、アプリケーションプロセス
のハングアップ、スレッドのハングアップ、およびアプ
リケーションプロセス実行時エラーのうちの、１つまた
は２つ以上を含むことを特徴とする１つまたは２つ以上
のコンピュータ読取可能媒体。
【請求項４８】施設に置かれている複数のコンピュー
タに対する権利を、カスタマーに販売し、複数のコンピュータで多層管理方式を実施し、複数のコ
ンピュータのハードウェアオペレーションは施設でロー
カルに管理され、複数のコンピュータのソフトウェアオ
ペレーションは施設から離れたロケーションから管理さ
れることを特徴とする方法。
【請求項４９】請求項４８に記載の方法において、前
記施設は共同ロケーション施設を含むことを特徴とする
方法。
【請求項５０】請求項４８に記載の方法において、前
記販売するステップでは、複数のコンピュータの少なく
とも１つをカスタマーにライセンスすることを特徴とす
る方法。
【請求項５１】請求項４８に記載の方法において、前
記販売するステップでは、複数のコンピュータの少なく
とも１つをカスタマーに販売することを特徴とする方
法。
【請求項５２】施設に置かれたクラスタ内の１つまた
は２つ以上のコンピュータがリースされているテナント
が、１つまたは２つ以上のコンピュータと通信可能とな
し、クラスタ内のコンピュータが別のクラスタ内のコンピュ
ータと通信することを防止するクラスタ境界を前記施設
に実装すること、を含むことを特徴とする方法。
【請求項５３】請求項５２に記載の方法において、前
記施設は共同ロケーション施設を含むことを特徴とする
方法。
【請求項５４】請求項５２に記載の方法において、前
記通信可能となすステップでは、１つまたは２つ以上の
コンピュータと、対応するテナントオペレーション管理
コンソールとの間にセキュアコミュニケーションチャネ
ルを確立することを特徴とする方法。
【請求項５５】請求項５４に記載の方法において、前記クラスタ境界は、多層管理アーキテクチャの第１層
に実装されており、前記多層管理アーキテクチャの第２層に実装されている
テナントオペレーション管理コンソールが、クラスタ内
にサブ境界を設定可能であることを特徴とする方法。
【請求項５６】請求項５２に記載の方法において、さ
らに、ランドロードオペレーション管理コンソールを通して前
記複数のコンピュータの少なくとも一部の管理を実行
し、複数のコンピュータの各々と、ランドロードオペレーシ
ョン管理コンソールとの間にセキュアコミュニケーショ
ンチャネルを確立することを特徴とする方法。
【請求項５７】請求項５６に記載の方法において、前
記ランドロードオペレーション管理コンソールは前記施
設に置かれていることを特徴とする方法。
【請求項５８】請求項５２に記載の方法において、前
記クラスタは、テナントにまだリースされていない、１
つまたは２つ以上の追加コンピュータを含むことを特徴
とする方法。
【請求項５９】共同ロケーション施設に置かれた複数
のコンピュータを複数のクラスタに分割し、前記クラスタを複数のテナントにリースし、前記テナントにリースされたクラスタ内のコンピュータ
と、前記テナントのオペレーション管理コンソールとの
間にセキュアコミュニケーションチャネルを確立可能と
することを特徴とする方法。
【請求項６０】請求項５９に記載の方法において、さ
らに、ランドロードオペレーション管理コンソールを通して前
記複数のコンピュータの少なくとも一部の管理を実行
し、前記テナントにリースされたクラスタ内のコンピュータ
と、前記ランドロードオペレーション管理コンソールと
の間にセキュアコミュニケーションチャネルを確立可能
とする、ことを特徴とする方法。
【請求項６１】請求項５９に記載の方法において、前
記クラスタ内のコンピュータが別のクラスタ内のコンピ
ュータと通信するのを防止するクラスタ境界を実装する
ことを特徴とする方法。
【請求項６２】請求項５９に記載の方法において、前
記クラスタ内のコンピュータが別のクラスタ内のコンピ
ュータと通信する能力を制限するクラスタサブ境界を実
装することを特徴とする方法。
【請求項６３】ランドロード鍵ペアとテナント鍵ペア
を１つのコンピュータで生成し、各々の鍵ペアは秘密鍵
と公開鍵を含み、ランドロード鍵ペアは、前記コンピュ
ータとランドロードデバイスとの間にセキュアコミュニ
ケーションを確立するために使用され、テナント鍵ペア
は、前記コンピュータと前記テナントデバイスとの間に
セキュアコミュニケーションを確立するために使用さ
れ、ランドロード秘密鍵とテナント秘密鍵を、他方のデバイ
スに公開することなく、コンピュータでセキュアに保
ち、ランドロード公開鍵とテナント公開鍵をランドロードデ
バイスに転送し、前記テナント公開鍵をテナントデバイスに転送すること
を特徴とする方法。
【請求項６４】請求項６３に記載の方法において、さ
らに、大容量ストレージデバイスにストアされるデータ
を暗号化するためのストレージ鍵を生成することを特徴
とする方法。
【請求項６５】請求項６４に記載の方法において、さ
らに、前記テナント秘密鍵が変更されるたびにカレント
ストレージ鍵を破棄し、新しいストレージ鍵を生成する
ことを特徴とする方法。
【請求項６６】請求項６４に記載の方法において、前
記ストレージ鍵を生成するステップでは、ランドロード
対称鍵とテナント対称鍵を組み合わせて、ストレージ鍵
を生成することを特徴とする方法。
【請求項６７】請求項６３に記載の方法において、さ
らに、前記テナント鍵を、ランドロードデバイスを経由
してテナントデバイスに転送することを特徴とする方
法。
【請求項６８】請求項６３に記載の方法において、前
記ランドロードデバイスは、クラスタオペレーション管
理コンソールを含むことを特徴とする方法。
【請求項６９】請求項６３に記載の方法において、前
記テナントデバイスは、アプリケーションオペレーショ
ン管理コンソールを含むことを特徴とする方法。
【請求項７０】大容量ストレージデバイスにストアさ
れるデータを暗号化するストレージ鍵を、コンピュータ
に保存しておき、テナント鍵が前記コンピュータで生成されなければ、ラ
ンドロード鍵だけを前記ストレージ鍵として使用し、前記テナント鍵が前記コンピュータで生成されれば、ラ
ンドロード鍵とテナント鍵を組み合わせて、前記ストレ
ージ鍵を生成することを特徴とする方法。
【請求項７１】請求項７０に記載の方法において、さ
らに、前記ランドロード鍵を使用して該ランドロード鍵
と前記テナント鍵を組み合わせて、前記テナント鍵を暗
号化することを特徴とする方法。
【請求項７２】請求項７０に記載の方法において、さ
らに、前記テナント鍵を使用して前記ランドロード鍵と
前記テナント鍵を組み合わせて、前記ランドロード鍵を
暗号化することことを特徴とする方法。
【請求項７３】コンピュータの所有者に対応する第１
層と、コンピュータのハードウェアオペレーションを管理する
予定のハードウェアオペレータに対応する第２層と、コンピュータのソフトウェアオペレーションを管理する
予定のソフトウェアオペレータに対応する第３層と、前記所有者に対応する第４層とを含み、そこで前記所有
者は、ハードウェアオペレータまたはソフトウェアオペ
レータの権利を取り消すときを除き、前記第４層で操作
するようにしたことを特徴とする多層コンピュータ管理
アーキテクチャ。
【請求項７４】請求項７３に記載の多層コンピュータ
管理アーキテクチャにおいて、前記第２層の管理は、前
記コンピュータから離れたロケーションに置かれている
管理コンソールに実装されていることを特徴とする多層
コンピュータ管理アーキテクチャ。
【請求項７５】請求項７３に記載の多層コンピュータ
管理アーキテクチャにおいて、前記第３層の管理は、前
記コンピュータから離れたロケーションに置かれている
管理コンソールに実装されていることを特徴とする多層
コンピュータ管理アーキテクチャ。
【請求項７６】請求項７３に記載の多層コンピュータ
管理アーキテクチャにおいて、さらに、各々の鍵ペアが
秘密鍵と公開鍵を含んでいる複数の鍵ペアを使用して、
前記コンピュータとハードウェアオペレータに対応する
管理デバイスとの間のコミュニケーションと、前記コン
ピュータとソフトウェアオペレータに対応する管理デバ
イスとの間のコミュニケーションとを共にセキュアにす
ることを特徴とする多層コンピュータ管理アーキテクチ
ャ。