(57)【要約】インターネットのためのホストサービスプロバイダが、離隔する顧客アカウント及び／又は地理的に別個のサイトを越えてホストサービスの動的管理を供給するように、操作される。複数の顧客アカウントの各々に対して、複数の個別サーバが、顧客アカウントに対して定義される共通の管理グループに割り当てされる。個々の管理グループは、その顧客アカウントに特有のソフトウエア及びデータにアクセスするように構成され、その顧客アカウントのためのホストサービスを提供する。システムは、各々の管理グループ内のサーバのパフォーマンス及び健全状態をモニタする。第１の管理グループからの少なくとも一つのサーバは、自動的モニタに応答して、第２の管理グループに自動的且つ動的に再割り当てされる。第２の管理グループのための顧客アカウントに特有のソフトウエア及びデータにアクセスする再割り当てされたサーバに対する初期化ポインタを設定し、更に再割り当てされたサーバが再開始時に第２の管理グループに結合するように再割り当てされたサーバを再初期化することによって、サーバの自動的且つ動的な再割り当てが完遂される。各々の管理グループ内のサーバのパフォーマンス及び健全状態は、管理グループとしてサーバと専ら相互接続するための独立の帯域外の通信チャネル全体にて、モニタされるのが好ましい。個々の管理グループは、別の顧客アカウントに対する利用要求、利用可能資源、及びサービスレベルアグリーメントに応答して、サーバを異なる管理ワークグループに動的に再割り当てする時期と方法を決定するマスタ判断ソフトウエアプログラムと通信するローカル判断ソフトウエアプログラムを含む。
2004519749.tif 000002
【特許請求の範囲】
【請求項１】
インターネットのためのサービスプロバイダを操作し、ホストサービスの動的管理を提供する自動的方法であって、
複数の顧客アカウントの各々に対して、顧客アカウントのための共通の管理グループに割り当てられ、その顧客アカウントに特有のソフトウエア及びデータにアクセスしその顧客アカウントのためのインターネットへのホストサービスを提供するようの構成される、複数のサーバを提供するステップと、
個々の管理グループを自動的にモニタリングするステップと、
自動モニタリングに応答して、第１の管理グループから第２の管理グループに少なくとも一つのサーバを自動的且つ動的に再割り当てするステップとを含み、
上記再割り当てするステップは、
上記の少なくとも一つのサーバが、第２の管理グループに対する顧客アカウントに特有のソフトウエア及びデータにアクセスするための初期ポインタを設定するサブステップと、
上記の少なくとも一つのサーバが第２の管理グループに結合するように、上記の少なくとも一つのサーバを再初期化するサブステップとを含む、
自動的方法。
【請求項２】
個々の管理グループに割り当てられた複数のサーバは、イントラネットにより操作自在に共に結合され、管理グループを自動的にモニタするステップは、その管理グループのためのイントラネットとは異なる通信チャネルにより一部完遂される、請求項１に記載の方法。
【請求項３】
第１の管理グループに割り当てられる複数のサーバが第１のサイトに配置され、第２の管理グループに割り当てられる複数のサーバが第１のサイトから地理上離隔する第２のサイトに配置され、自動的にモニタするステップは更に、第１の管理グループのための少なくともデータを第２のサイトに自動複写するサブステップを含む、請求項１に記載の方法。
【請求項４】
動的に再割り当てするステップが、サービスレベルアグリーメントデータベース内で定義される個々の顧客アカウントのためのパラメータと協働して自動的にモニタするのに応答して、実施される、請求項１に記載の方法。
【請求項５】
自動的にモニタするステップが、第２の管理グループ内の一つのサーバの故障を検出し、第１の管理グループ内の少なくともひとつのサーバを再割り当てして第２の管理グループ内の故障したサーバを置換する、請求項１に記載の方法。
【請求項６】
自動的にモニタするステップが第２の管理グループ内のサーバに対するワークロードの増加を予報し、第１の管理グループ内の少なくとも一つのサーバを動的に割り当てして第２の管理グループ内のより多数のサーバ間でワークロードの増加を再分配する、請求項１に記載の方法。
【請求項７】
初期化ポインタを設定するステップが、個々の顧客アカウントのための個人的モジュール内で維持される情報を利用する、請求項１に記載の方法。
【請求項８】
個々のサーバが、インターネットにプログラムにより接続し、動的に再割り当てするステップが更に、上記の少なくとも一つのサーバをスイッチして第２の管理グループの部分としてインターネットに操作自在に接続するサブステップを含む、請求項１に記載の方法。
【請求項９】
個々のサーバが更に、ディスク記録ユニットにプログラムにより接続し、動的に再割り当てするステップが更に、上記の少なくとも一つのサーバをスイッチしてディスク記録ユニットの一部と第２の管理グループの顧客アカウントに特有のデータとに操作自在に接続するサブステップを含む、請求項８に記載の方法。
【請求項１０】
動的に再割り当てするステップが更に、上記の少なくとも一つのサーバが顧客アカウントに動的に再割り当てされるとき、ホストサービスに対してより高いレートで顧客アカウントに請求するサブステップを含む、請求項１に記載の方法。
【請求項１１】
多数の顧客アカウントに供給されるインターネットに対するホストサービスの動的管理を設定するシステムであって、
イントラネットに操作自在に接続し、各々が、イントラネットから独立している他のサーバの少なくとも一つとの通信チャネルを設定するホスト管理回路を有する、少なくとも５つのサーバと、
サーバをモニタし通信チャネルを渡ってステータス情報を通信するローカル判断ソフトウエアプログラムを実行する少なくとも４つのサーバと、
第１の顧客アカウントのための第１の管理グループに割り当てられ、第１の顧客アカウントに特有のソフトウエア及びデータにアクセスして第１の顧客アカウントのためのインターネットへのホストサービスを提供するように構成される、少なくとも２つのサーバと、
第２の顧客アカウントのための第２の管理グループに割り当てられ、第２の顧客アカウントに特有のソフトウエア及びデータにアクセスして第２の顧客アカウントのためのインターネットへのホストサービスを提供するように構成される、少なくとも２つのサーバと、
他のサーバからのステータス情報を収集し、少なくともステータス情報に応答して第１の管理グループから第２の管理グループへ少なくとも一つのサーバを動的に再割り当てするマスタ判断ソフトウエアプログラムを実行する少なくとも一つのサーバと
を含むシステム。
【請求項１２】
マスタ判断ソフトウエアプログラムが、通信チャネルを利用して上記の少なくとも一つのサーバを動的に再割り当てし、第２の管理グループのための顧客アカウントに特有のソフトウエア及びデータにアクセスする上記の少なくとも一つのサーバに対する初期化ポインタを設定し、更に上記の少なくとも一つのサーバが第２の管理グループに結合するように上記の少なくとも一つのサーバを再初期化する、請求項１１に記載のシステム。
【請求項１３】
インターネットと個々のサーバとの間に操作自在に接続されるネットワークスイッチを更に含み、個々のサーバがマスタ判断ソフトウエアプログラムの制御の下でインターネットにプログラムで接続する、請求項１１に記載のシステム。
【請求項１４】
全てのサーバにプログラムで接続するディスク記録ユニットを更に含み、マスタ判断ソフトウエアプログラムは上記の少なくとも一つのサーバをスイッチし、第２の管理グループの顧客アカウントに特有のソフトウエア及びデータを格納するディスク記録ユニットの一部に操作自在に接続する、請求項１１に記載のシステム。
【請求項１５】
第１の管理グループに割り当てられる複数のサーバが第１のサイトに配置され、第２の管理グループに割り当てられる複数のサーバが第１のサイトから地理上離隔する第２のサイトに配置され、システムは更に、第１の管理グループのための少なくともデータを第２のサイトに自動複写する手段を含む、請求項１１に記載のシステム。
【請求項１６】
マスタ判断ソフトウエアが、
資源データベースと、
サービスレベルアグリーメントデータベースと、
資源データベース及びサービスレベルアグリーメントへアクセスし、上記の少なくとも一つのサーバを第１の顧客アカウントから第２の顧客アカウントへ動的に再割り当てするかどうかを決定するためにステータス情報を資源データベース及びサービスレベルアグリーメントの中の情報と比較する、マスタ判断ロジックモジュールと、
上記の少なくとも一つのサーバのための初期化ポインタを第２の管理グループのための顧客アカウントに特有のソフトウエア及びデータにアクセスするように設定することを、通信チャネルを利用してマスタ判断ロジックモジュールによって指示され、よって上記の少なくとも一つのサーバが第２の管理グループに結合するように上記の少なくとも一つのサーバを再初期化するとき、上記の少なくとも一つのサーバを動的に再割り当てするためにマスタ判断ロジックモジュールに操作自在にリンクされる、ディスパッチモジュールと
を含む、請求項１１に記載のシステム。
【請求項１７】
ディスパッチモジュールが更に、個々の顧客アカウントに対する接続ルールのセットと個人的モジュールのセットを含む、請求項１６に記載のシステム。
【請求項１８】
ローカル判断ソフトウエアプログラムが、予想応答時間及びそのサーバの可能性を決定する予報ルーチンの中に統合される出力を有する複数の計測モジュールを含む、請求項１１に記載のシステム。
【請求項１９】
所与のサーバのためのローカル判断ソフトウエアプログラムは更に、そのサーバに関連する管理グループにてサーバを付加する若しくは除去する要求を開始する予報ルーチンの少なくとも出力に接続するファジイロジック推論システムを含む、請求項１８に記載のシステム。
【請求項２０】
マスタ判断ソフトウエアプログラムが、全てのローカル判断ソフトウエアプログラムにてサーバを付加する若しくは除去する要求を、資源データベース及びサービスレベルアグリーメントデータベース内の情報と比較し、上記の少なくとも一つのサーバを第１の管理グループから第２の管理グループへ動的に再割り当てするかどうかを決定する、請求項１９に記載のシステム。
【請求項２１】
ホストサービスの動的管理を提供するために、インターネットに対するサービスプロバイダを操作する自動化方法であって、
複数の顧客アカウントの各々に対して、
その顧客アカウントのための共通の管理グループに割り当てられ、その顧客アカウントに特有のソフトウエア及びデータにアクセスしてその顧客アカウントのためのインターネットに対するホストサービスを提供するように構成された、複数のサーバを設定するステップと、
複数の顧客アカウントの各々のためのソフトウエア及びデータにアクセスするように選択の上構成され得る複数の仮想サーバのプールを設立するステップと、
個々の管理グループを自動的にモニタするステップと、
自動的モニタに応答して第１の管理グループの複数のサーバに結合するために、少なくとも一つの仮想サーバを自動的に割り当てるステップと、
上記の少なくとも一つの仮想サーバを自動的に割り当てるステップは、
第２の管理グループのための顧客アカウントに特有のソフトウエア及びデータにアクセスするため、上記の少なくとも一つの仮想サーバのための初期化ポインタを設定するサブステップと、
上記の少なくとも一つのサーバが第１の管理グループに結合するように、上記の少なくとも一つの仮想サーバを再初期化するサブステップとを含む、
自動化方法。
【請求項２２】
複数の仮想サーバのプールが、自動的モニタに応答して要求を基礎にして形成される請求項２１に記載の方法。
【請求項２３】
第２の管理グループの複数のサーバの少なくとも一つを自動的に割り当てを外し、その少なくとも一つのサーバを自動的モニタに応答して仮想サーバのプールに割り当てるステップを、
更に含む請求項２２に記載の方法。
【請求項２４】
初期化ポインタを設定するステップが、個々の管理グループに特有の個人的モジュール内で維持される情報を利用する、請求項２１に記載の方法。
【請求項２５】
初期化ポインタを設定するステップが、仮想サーバが割り当てされる管理グループに関連する顧客アカウント以外のどの顧客アカウントとも関連するソフトウエア及びデータへのアクセスから仮想サーバを排除する、請求項２１に記載の方法。
【請求項２６】
一つ以上の仮想サーバが、第１の管理グループに同時に割り当てられる、請求項２１に記載の方法。
【発明の詳細な説明】
【０００１】
発明の分野
本発明は、概略、データ処理ビジネスプラクティス分野に関する。特に、本発明は、離隔する顧客アカウント及び／又は地理上の別個のサイトへのホストサービスの動的管理を提示する方法及びシステムに関する。
【０００２】
発明の背景
インターネットの爆発的成長は、インターネットサービスプロバイダ（ＩＳＰ）、アプリケーションサービスプロバイダ（ＡＳＰ）、独立ソフトウエアベンダ（ＩＳＶ）、エンタプライズソリューションプロバイダ（ＥＳＰ）、マネジドサービスプロバイダ（ＭＳＰ）などのような、商業的なサービスプロバイダやホストファシリティの出現により、大いに推し進められてきた。これらビジネスの各々により提供されるサービスの正確なセットの明確な定義は存在しないが、概略、これらサービスプロバイダ及びホストファシリティは、セットアップチャージ及び定期報酬の払いと引き換えに、アプリケーションホスト、サイト開発、ｅ−コマースマネジメント及びサーバ開発に関する顧客のニーズの幾つか、大部分若しくは全てに適合すべく調整されたサービスを提供する。サーバ開発の文脈では、例えば、報酬は慣例上、顧客のアプリケーション若しくはウエブサイトのホストとなるため顧客に特化した特定のハードウエア若しくはソフトウエア構成を基礎にする。本発明の目的のために、“ホストサービス”という用語は、サービスプロバイダ及びホストファシリティのこの連続体により提供される種々のタイプのこれらサービスを含むことを、意図している。便宜上、サービスプロバイダ及びホストファシリティのこのグループは、ひとまとめにして、ホストサービスプロバイダ（ＨＳＰ）と呼ぶことにする。
【０００３】
商業上のＨＳＰは、電話会社が国際電話ネットワークを経由して意図する相手方への接続を顧客へ提供するのと同じように、利用者にインターネットのホストアプリケーションを提供する。ＨＳＰがアプリケーションをホストするのに利用するコンピュータ装置や、提供するサービスは、一般にサーバと呼ばれる。その最も単純な形態では、サーバは、ネットワークインターフェースを介してインターネットに接続し、且つ、顧客即ちサーバのクライアントによる要求に奉仕すべく設計された特定ソフトウエアを稼動するパーソナルコンピュータである。ホストサービスを提供するためにＨＳＰが利用し得る種々の分配モデルの全てのために、大抵のＨＳＰは、一般に“サーバファーム”と称されるものの中の内部ネットワークに接続するサーバの集合体を利用する。そこでは、各々のサーバが独自のタスクを実施するか、サーバグループがメールサーバ、ウエブサーバ、アクセスサーバ、アカウンティング・マネジメントサーバのような多重タスクの負荷を分配する。ホストウエブサイトの文脈では、例えば、より小さいウエブサイトを伴う顧客は、しばしば統合され、単体のウエブサーバによりサポートされる。しかしながら、より大きいウエブサイトは、そのサイトのためのみにサービスを提供する専用ウエブサーバ上で一般にホストされる。インターネット及びＨＳＰの概略の背景には、Ｇｅｏｆｆ  Ｈｕｓｔｏｎ，ＩＳＰ  Ｓｕｒｖｉｖａｌ  Ｇｕｉｄｅ：Ｓｔｒａｔｅｇｉｅｓ  Ｆｏｒ  Ｒｕｎｎｉｎｇ  Ａ  Ｃｏｍｐｅｔｉｔｉｖｅ  ＩＳＰ，（１９９９）を参照されたい。
【０００４】
インターネットサービスに対する要求が増大するにつれて、この要求に適合する更に大きいキャパシティに対するニーズが存在している。一つの解決策は、サーバとしてよりパワフルなコンピュータシステムを利用することであった。大きいメインフレームと中程度のコンピュータとのシステムが、大きいウエブサイト及び共同のネットワークをサービスするサーバとして、利用されてきた。大抵のＨＳＰは、それらシステムの高価さ、複雑さ、及びフレキシビリティの欠如のために、これらの大きいコンピュータシステムを利用しない傾向にある。その代わりに、ＨＳＰは、共通のインターネット接続やモデムのバンクに配線される多数の個別パソコンサーバからなり、時としてディスクドライブの共通セットにアクセスするサーバファームを利用するのを好む。ＨＳＰが新しいホストサービス顧客を追加すると、例えば、一つ又は複数のパソコンサーバが手作業でＨＳＰサーバファームに追加され、その顧客のための適宜のソフトウエアやデータ（例えば、ウエブコンテント）がロードされる。このように、ＨＳＰは、現存の顧客レベルをサポートするのに要求されるハードウエアのレベルを配備するのみである。同様に重要なことであるが、ＨＳＰは、このハードウエアのコストの重要部分をカバーする管理料を顧客に課金する。この方法を利用すると、ＨＳＰは、ＨＳＰに対し即時歳入を生成しない無駄な容量を伴う大きいコンピュータシステムのために、更に金を費やす必要が無い。サーバファームによる解決は、種々の顧客の全てが単体のより大きいメインフレームコンピュータからサービスを受ける場合よりも、顧客に関してセキュリティ及びデータインテグリティを維持するという問題点に対して、より容易な解決策ともなる。顧客に対するサーバの全てが、その顧客に対するソフトウエアのみロードしその顧客に対するデータのみに接続するのならば、その顧客の情報のセキュリティは物理的分離により保証される。
【０００５】
ＨＳＰに対し、多数のソフトウエア掲示パッケージが、ｒｅｎｓ．ｃｏｍからのＸａＣＣＴやｉｎｏｖａｗａｒｅ．ｃｏｍからのＨＳＰ  Ｐｏｗｅｒのように、これら計測サービスに対して計上し課金するのために、利用可能なものである。ｌｉｇｈｔｓｐｅｅｄｓｙｓｔｅｍｓ．ｃｏｍからのＩＰ  Ｍａｇｉｃ、ｒｅｓｏｎａｔｅ．ｃｏｍからのＩｎｔｅｒｎｅｔ  Ｓｅｒｖｉｃｅｓ  Ｍａｎａｇｅｍｅｎｔ、ｌｕｍｉｎａｔｅ．ｃｏｍからのＭＡＭＢＡなどのように、ＨＳＰネットワークの管理において手助けとなる他のソフトウエアプログラムが、開発されている。ＨＳＰのマネジメント及び操作は、Ｈｕｒｓｔｉ，Ｊａｎｉ，“Ｍａｎａｇｅｍｅｎｔ  ｏｆ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ  ａｎｄ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｓｉｏｎｉｎｇ”Ｓｅｍｉｎａｒ  ｉｎ  Ｉｎｔｅｒｎｅｔｗｏｒｋｉｎｇ，１９９９年４月１９日のように、記事やセミナの主題でもある。月単位でインターネットアクセス及びウエブサイトホスティングの商業レベルでの提供を行なうためのハードウエア、ソフトウエア、メンテナンス及びサポートの種種の構成を提供する典型的なＨＳＰの例が、ｒａｃｋｓｐａｃｅ．ｃｏｍに見つけ得る。
【０００６】
現在まで、ＨＳＰがサーバファームを構築した方法に関して２つのアプローチが存在する。一つのアプローチは、単一の製造者から供給される同一グループのパソコンシステム（ハードウエア及びソフトウエア）を利用することである。網一つは、多数の異なる製造者から供給されるパソコンシステムを利用することである。同一グループの方法は、単一のサーバプラットフォームをサポートしさえすればよいという点でＨＳＰの利益に寄与する。しかし同時にＨＳＰはこの単一のサーバプラットフォームに限定される。異なる製造さ光限定エレメントから供給されるシステムを利用する異なるグループの方法はより可撓性があり、所与の顧客即ちタスクに対して最も適切なサーバハードウエア及びソフトウエアプラットフォームを利用するという利益をＨＳＰにもたらす。しかし、この可撓性は、多重サーバプラットフォームに関連する増大する複雑性とサポートの挑戦とのコストにはね返る。
【０００７】
サーバファームを配置するのに利用される方法に関わりなく、そのようなサーバファームの実際の物理的なマネジメントは略同じである。顧客がアカウントのために提供されるサービスの量を増加させたり減少させたりしたいならば、ＨＳＰは、そのクライアントのウエブサイトのデータ記録部やネットワーク相互接続に直接ケーブルするＨＳＰサーバファームのその部分への若しくはその部分からのサーバを手作業で付加したり除去したりする。サービスが付加されるべき場合は、通常の処理は以下のバリエーションとなる。（ａ）サービスレベルを変更するオーダーがホスとサービス顧客から受信される。（ｂ）ＨＳＰは要求される変更に適合する新しいサーバハードウエアを入手する。（ｃ）ＨＳＰ部局は、サーバファームが配置されるサイトにて新しいサーバハードウエアを物理的にインストールする。（ｄ）新しいサーバハードウエアのためのケーブリングが、そのサイトのためのデータ記録部及びネットワーク接続に付加される。（ｅ）サーバハードウエアのためのソフトウエアがサーバ上にロードされ、ＨＳＰ部局は一連の初期化ステップを経過し、特にこの顧客の要求に合わせソフトウエアを構成する。（ｆ）新しくインストールされ十全に構成されたサーバが、顧客のアカウントのためのホスとサービスを提供するサーバの現存の管理グループに加わる。いずれにせよ、各々のサーバファームは特定の顧客にアサインされ、よって顧客のアカウントからのサービスに対して最大限の予測要求に適合するように構成されねばならない。
【０００８】
新しいサーバの管理グループへの付加を反映するため現存のサーバ内のポインタ及びテーブルは手作業で更新される必要があったので、この処理の最後のステップを完了させるのに所与の顧客のアカウントのため管理グループの中の現存サーバの幾つか若しくは全てをリブート若しくはリスタートすることが、もともと、必要であった。サーバハードウエアにて変更するこの予測される要求は、十分に定義されたウインドウにて、日曜日の深夜など定期的にのみ発生しうる。最近では、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）  ２０００、Ｍｉｃｒｏｓｏｆｔ  Ｃｌｕｓｔｅｒ  Ｓｅｒｖｅｒ、Ｏｒａｃｌｅ  Ｐａｒａｌｌｅｌ  Ｓｅｒｖｅｒ、Ｗｉｎｄｏｗｓ  Ｎｅｔｗｏｒｋ  Ｌｏａｄ  Ｂａｌａｎｃｉｎｇ  Ｓｅｒｖｉｃｅ（ＮＬＢ）及び同様のプログラムのようなソフトウエアが開発され、これら十分に定義されたウインドウズとは異なり、いつでも現存の管理グループに新しいサーバを自動的に接合し得るように拡張されている。
【０００９】
新しいサーバが現存の管理グループに自動的に接合する方法の例は、米国特許第５９５１６９４号で説明される。この特許では、管理グループ内のサーバの全ては、ゲートウェイサーバにより維持されるマッピングテーブルで示される。マッピングテーブルは、メールサービスグループ、データベースサービスグループ、アクセスサーバグループなどの、管理グループのための種々のサービスグループを同定する。ゲートウェイサーバは、マッピングテーブルを基にして、適切なサービスグループへの管理グループを求める要求を、経路付ける。新しいサーバは、適切なソフトウエアコンポーネントをサーバにロードすることによりサービスグループの一つに付加され、その後ゲートウェイサーバが新しいサーバを認識してマッピングテーブルに追加し、個々のサービスグループのために維持されるトランザクションログを利用して、サービスグループ内の残りのサーバにまで新しいサーバをスピードアップする。一方で、一つのサービスグループが重いワークロードを経験し別のサービスグループが軽い負荷であれば、一つのサービスグループから別のサービスグループへサーバをスイッチすることが可能である。特許は、マッピングテーブルを修正する負荷バランススキームを利用し、管理グループを構成する種々のサービスグループ間で管理グループに対する要求をより平滑に均衡化することを保証する、専用管理サーバで実行されるソフトウエアルーチンを説明する。
【００１０】
多数の特許が、シングルクラスタや管理グループのサーバ間でのワークロードバランスのための技術に付き、説明する。米国特許第６００６５２９号は、増田サーバの制御下のセキュリティ及びハートビート構成を含むソフトウエアクラスタを説明する。そこでは、クラスタメンバの全てが共通ＩＰアドレスを割り当てられ、負荷バランスはそのクラスタの範囲内で実施される。米国特許第５５３７５４２号、５９４８０６５号、５９７４４６２号は、共有データスペースを有する多重システムコンピュータプロセッシングシステムのための種々のワークロードバランス構成を説明する。サーバ間のワークの分配は、クライアントとサーバ間に仲介システムを差し挟むことによっても完遂され得る。米国特許第６０９７８８２号は、クライアントとサーバ間に差し挟まれ、利用可能なサーバ及びワークロードを基にして両者間のＩＰパケットをトランスペアレントに宛名を変える複製システムを説明する。
【００１１】
種々の技術が、シングルクラスタの多重コンピュータ若しくはサーバの操作を統合するのにも利用されている。米国特許第６０１４６６９号は、ロックステップ分布構成ファイルを利用することによるシングルクラスタ内の多重サーバのクラスタ操作を説明する。米国特許第６０８８７２７号は、共有データスペース多重コンピュータ環境内でのクラスタ制御を説明する。他の特許は、インプット／アウトプットスペースのシングルイメージが多重コンピュータを統合するのにいかに利用され得るのかを説明する。米国特許第５８３２２２２号は、インプット／アウトプットスペースのシングルイメージが地理的に離隔されたコンピュータシステムを統合するのにいかに利用され得るのかを説明する。米国特許第６０６７５４５号は、共有メタデータマネジメント、複製構成データベース及びドメイン負荷バランスを伴い、構成データベースの制御下でシングルドメインの中に及びそのシングルドメインからサーバを出入りさせる、分布ファイルシステムを説明する。
【００１２】
これらの方法は、管理グループ、ドメイン若しくは共有データスペースの範囲内でサーバのマネジメントを改善するものであるが、共通のオペレーティングシステムや共通の共有データスペースに対して定義されかつリンクされるサーバグループを超えて、これら技術を拡張することはできない。一般に、この限定は問題であると考えられてきた。というのは、これら方法の全ては、単一の会社のコンピュータネットワークの範囲内で管理され実装されるより大きな企業コンピュータシステムに向けられているからである。これらの方法がＨＳＰにより実利用され所与のクライアント即ち顧客の特定のアカウントにサーバが首尾よく割り当てられたとしても、これらの方法では、サーバのセットが種々のクライアント即ち顧客のための多重アカウントにホストサービスを首尾よく与えることはできない。
【００１３】
より大きな企業コンピュータシステムの操作を管理するシステムも開発されてきた。Ｈｅｗｌｅｔｔ−ＰａｃｋａｒｄのＯｐｅｎＶｉｅｗ、Ｃｏｍｐｕｔｅｒ  ＡｓｓｏｃｉａｔｅｓのＵｎｉｃｅｎｔｅｒＴＮＧ、ＩＢＭのＴｉｖｏｌｉ、ＬｕｍｉｎａｔｅのＭａｍｂａ、ＢＭＣ  ＳｏｆｔｗａｒｅのＰａｔｒｏｌなどである。一般に、これらのシステムは、単一の会社若しくは組織の範囲内で稼動する非常に多数のコンピュータと敵対する、目録管理及びソフトウエア展開制御問題に焦点を当てている。これらの操作管理システムのうちには、ネットワークを超える組織の範囲のサーバのパフォーマンスをただし、付加的な資源若しくは負荷分配の要求を決定する、パフフォーマンスモニタリングを含むものもある。同様のオーバーザネットワーク・アプローチが、集権的レポート及び管理特性を提供するためにも利用される。ＨＳＰにより利用されることが意図されるこのタイプの操作管理システムの例は、Ｔｉｖｏｌｉ  Ｓｅｒｖｉｃｅ  Ｄｅｌｉｖｅｒｙ  Ｍａｎａｇｅｍｅｎｔプラットフォームであり、利用者管理モジュール、ソフトウエア分配モジュール、目録モジュール、企業コンソール、セキュリティモジュール、ネットワークに付加されるとネットワークの中の全てのコンポーネントのカスタマイズビューを提供する企業マネジャモジュール、及び、共通データスペースを共有するサーバ間でワークロードのバランスを取らせるワークロードスケジューラからなる。これらモジュールの全ては、オーバーネットワーク通信スキームを利用して稼動する。該スキームは、ステータスと他のモジュールへのインシデント情報とを収集しレポートする、ネットワーク内の種々のノード上のエージェントを含む。新しいノードのためのハードウエアコンポーネントがネットワークに物理的に付加されると、Ｔｉｖｏｌｉ  Ｓｅｒｖｉｃｅ  Ｄｅｌｉｖｅｒｙ  Ｍａｎａｇｅｍｅｎｔプラットフォームの種々のモジュールは行き渡り、より自動のベースでこれらコンポーネントを管理する。しかしながら、ネットワークの中へ新しいノードのためハードウエアを物理的に付加するプロセスは、本質的に、前述と同様、完遂されるプロセスは手作業である。
【００１４】
コンピュータシステムを構成する物理的なハードウエアを管理するにおいて、コンピュータネットワーク内のハードウエアコンポーネントの故障を自動的に償う種々のアプローチが開発されている。米国特許第５６１５３２９号は、二次的なコンピュータシステムが一次的なコンピュータシステムが故障した際に一次的なコンピュータシステムに取って代わるという専用の独立の一次的及び二次的コンピュータシステムを利用する、リモートデータシャドウを実装する冗長なハードウエア構成の典型的な例を説明する。これらのタイプのミラーリング、即ちシャドウ構成の問題点は、高価で無駄があることであり、特に二次的なコンピュータシステムが一次的なコンピュータシステムの故障を待ってスタンバイモードにてアイドル状態にあることである。米国特許第５６９６８９５号は、一連のサーバの各々が自身のタスクを稼動するが、各々サーバが、他のサーバの一つに故障が発生した際にそのサーバに対するバックアップとしてアサインされているという、この問題の解決策を説明する。この構成では、タスクは、バックアップサーバで継続されるので両サーバで実施可能である。但し、パフォーマンスは低下する。このタイプの他の例には、Ｅｐｏｃｈ  Ｐｏｉｎｔ  ｏｆ  Ｄｉｓｔｒｉｂｕｔｉｏｎ（ＰＯＤ）サーバデザイン及びＵＳＩ  Ｃｏｍｐｌｅｘ  Ｗｅｂ  Ｓｅｒｖｉｃｅを含む。これらサービスを提供するのに利用されるハードウエアコンポーネントは、負荷バランスソフトウエアを含む予め定義されるコンピュータポッドであり、管理グループの範囲内でハードウエアコンポーネントの故障を補償もし得る。かような予め定義されたコンピュータポッドを利用しても、物理的な準備及び管理グループの中へのかようなポッドの設置は、完遂するのに一週間かかり得る。
【００１５】
これらの解決策の全ては、現存のハードウエアコンピュータ容量を基にして、管理グループ内でワークロード、及びハードウエア故障周りのルートの自動管理と均衡とを為すために稼動する。しかしながら、管理グループに対する付加的なハードウエア資源の自動展開を為し得る解決策は、殆ど開発されていない。もし、管理グループ内の付加的なハードウエア資源に対する潜在的な要求が前もって知られているのならば、最も共通の解決策は、管理グループのための資源に対する最も高い要求予測を基にして、管理グループのためのハードウエア資源を前もって構成すること、である。この解決策では、管理グループがピーク要求の機会の間に適宜反応し得るが、このピーク要求に合致すべく配置された特別のハードウエア資源はせいぜい他の機会に利用されるのみである。結果として、管理グループのためのホストサービスを提供するコストは、このグループのためのハードウエア資源の利用のために、増加する。
【００１６】
付加されるホストサービスのための要求に対する解決策の一つは、Ｃａｂｌｅ  ＆  Ｗｉｒｅｌｅｓｓにより提供されるＩｎｔｅｒｎｅｔ  Ｓｈｏｃｋ  Ａｂｓｏｒｂｅｒ（ＩＳＡ）である。ＩＳＡは、顧客の静的なＷｅｂコンテントを、Ｃａｂｌｅ  ＆  ＷｉｒｅｌｅｓｓのＩｎｔｅｒｎｅｔバックボーン上の種々のＰｏｉｎｔｓ  ｏｆ  Ｐｒｅｓｅｎｃｅ（ＰＯＰｓ）に配置される一つ又は複数のキャッシュサーバに分配される。この静的なｗｅｂコンテントの要求は、キャッシュサーバ及び種々のＰＯＰ位置に向けられ、顧客に対しホストサービスを提供する管理グループ内のサーバから、上記機能の負荷を減ずる。しかしながら、静的Ｗｅｂコンテントは、インターネットにおける一部の情報分配として自然に生じるものである。多数ユーザが所与のＩＰアドレスから静的情報を要求すると、インターネット上の多数の位置にてこの情報をキャッシュするということが、共通事項になってしまう。本質的に、ＩＳＡサービスは、インターネット上の静的ウエブコンテントのキャッシングを顧客が率先して開始できる。この解決策は潜在的に、静的Ｗｅｂコンテントの分配の実施を改良するものであるが、この解決策は、相互作用若しくは動的情報コンテントを含む多数の他のタイプのホストサービスには、適用できない。
【００１７】
重要な拡張が、ＨＳＰが管理されている方法に為され、ＨＳＰネットワークの操作を手助けする多数のプログラム及びツールが開発されているが、サーバファームの物理資源を形成し維持するためのＨＳＰにより利用される基礎的な技術は殆ど変動していない。サーバファーム物理資源が管理される方法に関し改善し得る、ＨＳＰを操作するより有効な方法を提供することが、望ましい。
【００１８】
発明の概要
本発明は、離隔する顧客アカウント及び／又は地理的に別個のサイトを越えてホストサービスの動的管理を供給するように、インターネットのためのホストサービスプロバイダを操作する方法及びシステムである。複数の顧客アカウントの各々に対して、複数の個別サーバが、顧客アカウントに対して定義される共通の管理グループに割り当てされる。個々の管理グループは、その顧客アカウントに特有のソフトウエア及びデータにアクセスするように構成され、その顧客アカウントのためのインターネットに対するホストサービスを提供する。システムは、各々の管理グループ内のサーバのパフォーマンス及び健全状態をモニタする。第１の管理グループからの少なくとも一つのサーバは、自動的モニタに応答して、第２の管理グループに自動的且つ動的に再割り当てされる。第２の管理グループのための顧客アカウントに特有のソフトウエア及びデータにアクセスする再割り当てされたサーバに対する初期化ポインタを設定し、更に再割り当てされたサーバが再開始時に第２の管理グループに結合するように再割り当てされたサーバを再初期化することによって、サーバの自動的且つ動的な再割り当てが完遂される。各々の管理グループ内のサーバのパフォーマンス及び健全状態は、管理グループを越えてサーバと専ら相互接続するための独立の帯域外の通信チャネル全体にて、モニタされるのが好ましい。個々の管理グループは、個々の顧客アカウントに関する利用要求、利用可能資源、及びサービスレベルアグリーメントに応答して、サーバを異なる管理グループに動的に再割り当てする時期と方法を決定するマスタ判断ソフトウエアプログラムと通信するローカル判断ソフトウエアプログラムを含む。
【００１９】
一つの実施形態では、多数の顧客アカウントのためのホストサービスの動的管理を設定するシステムは、イントラネットに操作自在に接続する少なくとも５つのサーバを含む。各々のサーバは、このイントラネットから独立している他のサーバの少なくとも一つとの通信チャネルを設定するホスト管理回路を含む。少なくとも４つのサーバは、サーバをモニタし通信チャネルを渡ってステータス情報を通信するローカル判断ソフトウエアプログラムを実行する。少なくとも２つのサーバは、第１の顧客アカウントのための第１の管理グループに割り当てられ、この第１の顧客アカウントに特有のソフトウエア及びデータにアクセスしてホストサービスがこの顧客アカウントのためにインターネットを介して提供されるように構成される。少なくとも２つの他のサーバは、第２の顧客アカウントのための第２の管理グループに割り当てられ、この第２の顧客アカウントに特有のソフトウエア及びデータにアクセスしてホストサービスがこの顧客アカウントのためにインターネットを介して提供されるように構成される。少なくとも一つのサーバは、他のサーバからのステータス情報を収集し、少なくともステータス情報に応答して第１の管理グループから第２の管理グループへ少なくとも一つのサーバを動的に再割り当てするマスタ判断ソフトウエアプログラムを実行するのが好ましい。
【００２０】
単一の顧客アカウント関係の範囲内での稼動に限定される、又は、大きく高価なコンピュータシステム及び共通オペレーティングシステム、若しくは共有データスペースを要求する、現存の負荷バランスシステムとは異なり、本発明は、多数の離隔した顧客アカウントを越えてサーバを動的に再割り当し、ホストサービスをより経済的且つ可撓性あるサーバファーム構成に設定することが可能である。本発明は多数の顧客アカウントのための多数の管理グループをサポートすることが可能であるため、異なる顧客アカウント間にてサーバ資源を理性的且つ動的に割り当てることができる。
【００２１】
好適な実施の形態の詳細な説明
図１を参照すると、ホストサービスプロバイダのための現存のサーバファーム２０の単純化した機能図が示される。かようなサーバファームは、所与の顧客アカウントのホストサービス要求をサポートするように静的に構成される既製のハードウエア及びソフトウエアコンポーネントを利用して、通常構成される。この実施形態では、ホストサーバプロバイダのためのサーバファーム２０は、４つの異なる顧客アカウントのためのホストサービスをサポートする。サーバファーム２０は、ネットワークスイッチ／ルータ２４によりインターネット２２に接続される。ネットワークスイッチ２４は、今度は、所与の顧客アカウントに対してフロントエンド／コンテントサーバ２８とバックエンド／コンピュートサーバ３０との間に形成される内部ネットワークスイッチ／ルータ２６に接続する。全てのフロントエンド／コンテントサーバ２８とバックエンド／コンピュートサーバ３０は、当該顧客アカウントに特化されたデータ及びソフトウエアを含むディスクシステム３２に接続する。サーバ２８、３０のためのハードウエアの物理的性質に依存するが、ディスクシステム３２はサーバハウジングの範囲内に含まれてもよく、ディスクシステム３２はサーバ２８、３０の各々に直接接続する物理的に分離したユニットの中に収容されてもよく、記憶部付随ネットワーク（ＳＡＮ）若しくはネットワーク付随記憶部（ＮＡＳ）構成として一つ以上のサーバ２８、３０に付随してもよい。
【００２２】
この構成は既製のハードウエアを十分に利用し、多数の独立した顧客アカウントに対してホストサービスを供給し得るサーバファーム２０を構築するのであるが、このタイプの構成では幾つかの重要な問題が露呈する。それらのうちで最も重要なものは、異なる顧客アカウント間でのシステム資源の割り当てと展開の一般的な静的性質である。この複合体の範囲内での単一の顧客アカウントを構成し管理するために、ＨＳＰのためのアドミニストレータは、顧客ニーズの突出した要求を基にして特定顧客アカウントに対し幾つかの固定レベルのシステム資源（例えば、サーバ、ディスク、ネットワークリング）を供用する必要がある。
【００２３】
例えば、予測されたピーク負荷の下で顧客アカウントが、ユーザ要求を処理するための３つのフロントエンドサーバ２８を要求し、これら要求により生成されるデータベース問い合わせ／更新を処理するための４重プロセッサバックエンドサーバ３０を要求するような、所与の顧客アカウントのために設計された比較的単純なウエブサイトを仮定する。このタイプのウエブサイトに対して、Ｆ５  Ｂｉｇ−ＩＰ、Ｃｉｓｃｏ  Ｌｏｃａｌ  Ｄｉｒｅｃｔｏｅ、若しくはＦｏｕｎｄｒｙ  ＳｅｒｅｒＩｒｏｎのようなハードウエアベース技術、又はＷｉｎｄｏｗｓ  Ｌｏａｄ  Ｂａｌａｎｃｅ  Ｓｅｒｖｉｃｅ（ＷＬＢＳ）などのソフトウエアベースソリューションは、フロントエンド／コンテントサーバ２８にも均一にユーザ要求を分配するのに利用されがちである。更に、バックエンドデータベース／コンピュートサーバ３０は、共通してクラスタとなり、あるレベルのフォールトトレラントを設定する。マイクロソフトクラスタサーバ（Ｍｉｃｒｏｓｏｆｔ  Ｃｌｕｓｔｅｒ  Ｓｅｒｖｅｒ）やオラクルパラレルサーバ（Ｏｒａｃｌｅ  Ｐａｒａｌｌｅｌ  Ｓｅｒｖｅｒ）のような、通常操作の間に生じ得るハードウエア故障に関わらず多数サーバによりウエブサイトが進む多数のソフトウエア製品が利用可能である。更に、Ｔｉｖｏｌｉ  Ｅｎｔｅｒｐｒｉｓｅ，ＨＰ  ＯｐｅｎＶｉｅｗのようなシステムモニタリングツールにより、アドミニストレータは、故障がサーバファーム２０の範囲内で検出される時期を通知され得る。これらツールは所与のサイトでの単一の顧客アカウントの範囲内のホストサービスを管理するには十分であるが、これらツールのうちで、離隔顧客アカウントに関してホストサービスを管理し得るものはない。
【００２４】
この例の文脈では、この顧客アカウントのためのウエブサイトは、毎分５０００トランザクションのピーク負荷を処理するように設計されたｅ−コマースであると仮定する。更に、サーバファーム２０の中の残余の顧客アカウントのためのウエブサイトは、夫々に毎分１０００、１５０００及び５０００トランザクションのピーク負荷を処理するように設計されたと仮定する。図２に示されるように、予想されるピーク負荷を処理するために個々の顧客アカウントを設計し構成しなければならないため、サーバファーム２０全体の中では相当量の無駄な容量が生じ得る。多数の顧客アカウントを処理するサーバファーム２０は過剰集合容量を備えていても、この特別の容量は、ハードウエア故障や一つのアカウントから次のアカウントへのピーク負荷の増加に反応するようには利用され得ない。特定の顧客アカウントのために構成される資源は、そのアカウントのために供されしかもそのアカウントのみである。第１の顧客アカウントのための一つのフロントエンドサーバ２８がハードウエア故障に遭遇する場合、ウエブトラフィックは残余のフロントエンドサーバ２８に経路付けされる。ハードウエア故障の前に顧客アカウントがビジーであり且つウエブトラフィックが一定であるか故障後増加する場合には、故障サーバから供される追加のトラフィックに加えてそれ自身の従前のワークロードを処理することにより、残余のフロントエンドサーバ２８は即座にオーバロードしてしまう。最善のシナリオでは、サーバファーム２０のためのシステム管理ソフトウエアが、サーバが故障したことに気付き、サーバ故障を示すメッセージを（ページャ及び／若しくはｅメールにより）サイトマネジャに送信する。サイトマネジャがこのメッセージを折りよく受け取りサイト上に配置されれば、サイトマネジャは故障したハードウエアコンポーネントを物理的に除去し、この目的のために望ましいことに貯蔵されているスペアのハードウエアコンポーネントをインストールし、新しいハードウエアコンポーネントを再ケーブルし、その顧客アカウントのための適切なソフトウエアを構成してインストールし、新しいハードウエアコンポーネントを残余のフロントエンドサーバ２８に再参加させる。このプロセスは１時間以内に完遂することが望ましい。もし、メッセージが折りよく受け取られなかったら、サイトマネジャがサーバファームが配置されるサイトに配置されていないならば、若しくは、故障ユニットに入れ替わって利用可能な貯蔵スペアハードウエアがなければ、このプロセスはさらに長くかかってしまう。そのうちに、ユーザが顧客アカウントにアクセスする応答時間が悪くなり、顧客アカウントはこの間別のハードウエア故障に益々脆弱になる。
【００２５】
顧客アカウントの構成される予想ピーク要求を超える要求の増加を、顧客アカウントが遭遇するような場合には、この増加したウエブトラフィックを分配するための負荷バランス設備に対して利用可能な資源は無い。サーバ２８、３０の全ては、ピーク容量で稼動している。結果として、顧客アカウントに対して相当に応答時間が悪化し、折りよく処理できない要求に対して、“サービス利用不可能”という応答になる可能性がある。消費者に対してサービスを折りよく適用できないことは、望ましくないが別の文脈での事業にとっては管理可能な問題点ではあるものの、ウエブサイトに対して“サービス利用不可能”というメッセージを生成するという付加的な問題点は、そのようなメッセージがいかなる理由に対しても持続しつづけるのならば、インターネットは、この情報をネットワーク内の膨大な中間ノードに伝播し始めてしまう、ということである。結果として、これらの中間ノードは、ウエブサイトが“利用不可能”であることを理解させるために、ウエブサイトへの後続の要求を迂回させてしまう。“サービス利用不可能”のメッセージを受け取る消費者がサービスされないだけでなく、顧客アカウントが飽和し若しくはオーバロードすると他の多数の消費者もウエブサイトにすら行き着かないことになってしまう。
【００２６】
ここで図３を参照すると、多数の顧客アカウントへのホストサービスの動的管理を提供するサーバファーム４０を示す。現存のサーバファーム２０と同様に、サーバファーム４０は、サーバファーム４０とインターネット２２との間の相互接続を確立するためのネットワークスイッチ４４を含む。しかしながら、現存のサーバファーム２０とは異なり、サーバ４６の母集団は、エンジングループマネジャ４８の制御の下に管理される。サーバ４６の各々は、ネットワークスイッチ４４によりインターネットと、更にディスク記録システム５０とプログラム上で接続する無国籍コンピュータ装置である。一つの実施形態では、サーバ４６は、Ｆｉｂｒｅ  Ｃｈａｎｎｅｌ記憶領域ネットワーク（ＳＡＮ）を経由してディスク記録システム５０に接続する。一方で、サーバ４６は、ネットワーク付随記憶部（ＮＡＳ）構成、スイッチ可能クロスバー構成、若しくは他の同様の相互接続技術を介してディスク記録システム５０に接続し得る。
【００２７】
図４及び図５に示されるように、エンジングループ４８は、多数の顧客アカウントの間にて無国籍サーバ４６を自動的に割り当てる責任を負い、割り当てられたアカウントに対してこれらサーバを構成する責任を負う。所与の顧客アカウントのためのサーバを、その顧客アカウントのために定義されその顧客アカウントにとって唯一のソフトウエア及びデータにアクセスするよう構成された共通の管理グループ５２に割り当てることにより、このことは為される。説明するように、エンジングループマネジャ４８は、個々の管理グループを自動的にモニタし、自動モニタリングに応じて、第１の管理グループ５２−ａから第２の管理グループ５２−ｂへサーバ４６’を自動的且つ動的に再割り当てする。第１の管理グループ５２−ａから再割り当てされたサーバ４６’のための初期化ポインタを、第２の管理グループ５２−ｂのための顧客アカウントに対して唯一のソフトウエア及びデータにアクセスするように設定するためにエンジングループマネジャ４８を利用し、そして、再割り当てされたサーバ４６’が第２の管理グループ５２−ｂに接合するように再割り当てされたサーバ４６’を再初期化することによって、このことは完遂される。現存する付加するためのプロセスは、ハードウエア資源をサーバファーム２０へ除去するのではなく、本発明は、できるだけ短時間で新しい管理グループ５２に利用可能な再割り当てサーバ４６’を作成できる。基本的には、再割り当てサーバ４６’をオンラインとするのに要求される唯一の有意な時間は、サーバ４６’をリブートするのに要求される時間と、このリブートされたサーバを認識するための、負荷バランスをとり及び／又はクラスタするソフトウエアのために要求される時間と、である。負荷バランスソフトウエアはフロントエンド／コンテントサーバとの接続でより通常に見出されることが理解されるが、クラスタするソフトウエア、又はクラスタするソフトウエアと負荷バランスソフトウエアとの組み合わせは、バックエンド／コンピュートサーバとの接続でより通常に利用される。負荷バランスソフトウエアという用語は、これら可能な組み合わせの何れに言及するのにも利用される。
【００２８】
一つの実施形態では、再割り当てサーバ４６’のためのソフトウエアは、サーバがオンラインとされ（即ち、リセットされてパワーオンされ）又はサーバがオフラインとされ（即ち、リセットされてパワーオフされ）るのに応じて、サーバを自動付加したり管理グループからサーバを自動除去したりする付加バランスソフトウエアを含むので、再割り当てサーバ４６’は、第２の組み合わせグループを自動的に接合する。前に説明したように、この種の付加バランスソフトウエアは今日広く知られており利用可能である、しかしながら、現存の付加バランスソフトウエアは、単一の管理グループからサーバを付加したり除去したりすることのみしかできない。この実施形態では、エンジングループマネジャ４８は、異なる管理グループ５２に渡る動的再割り当てサーバ４６’を許容する現在利用可能な商用付加バランスアプリケーションソフトウエアの能力を利用する。一方で、単一の管理グループのためのオペレーティングシステムの範囲内のエージェント若しくはサブルーチンは、再割り当てサーバ４６’がオンラインとなると再割り当てサーバ４６’を第２の管理グループ５２−ｂの中に統合する責任を負う。更に別の実施形態では、エンジングループマネジャ４８は、個々の管理グループ５２のための利用可能なサーバのリストに対する更新を発行し得る。
【００２９】
エンジングループマネジャ４８は、オペレーティングシステムやアプリケーションプログラムなどを含み管理グループ５２のために設置されたブートイメージソフトウエア及び構成ファイルの適切なコピーに、管理グループ５２のための各々のサーバの中のポインタをセットするのが好ましい。再割り当てサーバ４６’がリブートされると、そのポインタはエンジングループマネジャ４８によりリセットされ、第１の管理グループ５２−ａのためのブートイメージソフトウエア及び構成ファイルではなく、第２の管理グループ５２−ｂのためのブートイメージソフトウエア及び構成ファイルを指す。
【００３０】
概略、個々の管理グループ５２は、唯一の顧客アカウントのためのサーバファーム４０により提供されるウエブ再とや類似のホストサービスを示す。異なる顧客アカウントは、同じビジネスや関連する商用エンティティによって償われるが、所与の顧客アカウントに関連し、よって所与の管理グループ５２に関連するデータとソフトウエアはその顧客アカウントに対して唯一のものであることが理解される。大きいメインフレームコンピュータシステムの資源のタイムシェアリングを実行する単一の共通のオペレーティングシステムを利用することにより、多数顧客へホストサービスを提供する大きいメインフレームコンピュータ装置を利用するサーバプロバイダとは異なり、各々の管理グループ５２は、従来のオペレーティングシステムソフトウエアを含むが管理グループ５２に割り当てされるサーバ４６の外部には拡張しない唯一のソフトウエアからなる。本発明のこの分配方法では、比較的廉価な個別のサーバにインストールできる、よりシンプルな従来のソフトウエアアプリケーション及びオペレーティングシステムの利用が、許容される。このように、管理グループ５２を構成する個別要素は、比較的廉価な商業的に利用可能なハードウエアサーバ及びソフトウエアプログラムを含む。
【００３１】
図６及び図７は、本発明に係るサーバファーム４０のためのコンポーネント及びハードウエアの好適な実施形態を示す。本発明の好適な実施形態はこのハードウエアと関連させて説明されるが、本発明のコンセプトは、サーバにホストマネジメント回路若しくは説明する均等物が備わる限り、現下利用可能な１Ｕ若しくは２Ｕパッケージサーバを含む従来のあらゆるサーバを利用して実行されるサーバファームに等しく利用可能であることが理解される。
【００３２】
サーバファーム４０のためのハードウエアは、スケーラブルエンジン１００であり、動力及び空間が十分なキャビネット１１０内でエンジンブレード１３２として各々構成される多数の商業的利用可能であるサーバボード１０２からなるのが、好ましい。エンジンブレード１３２は、キャビネット１１０の前側１１２に鉛直方向に取り外し自在に配置される。キャビネット１１０の中央の貫通面１３０は、共通の電源となり全エンジンブレード１３２に対する境界信号を制御する。各々のエンジンブレード１３２のためのＩ／Ｏ信号は、貫通面１３０内のアパーチャを経由し、キャビネット１１０の背面に配置されるカードとインタフェースを取る。Ｉ／Ｏ信号は、適切なインタフェースカード１３４を経由し、ネットワークスイッチ４４を介してインターネットに到るか、ディスク記録部５０に到るか、である。独立のインタフェースカード１３４が、これらの異なる通信経路のために使われるのが好ましい。
【００３３】
スケーラブルエンジン１００は、共通ブレード担持構造１０３のため、同じキャビネット内に異なるタイプのサーバボード１０２を伴う。異なるタイプの商業的利用可能であるマザーボード１０２が、キャビネット１１０に一様な機械的インタフェースを設定する共通ブレード担持構造１０３の中に、装備される。種々のタイプのマザーボード１０２の中にプラグ接続する特別設計のＰＣＩホストボード１０４は、インタフェースカード１３４に接続するための貫通面１３０を経由する接続路を持つ。冗長なホストスワッピング可能な高性能電源装置１４４が、貫通面１３０の共通の動力信号に接続する。ホストボード１０４は、ＡＴＸパワーマネジメントプロトコルをエミュレートすることにより、エンジンブレード１３２のためにサーバボード１０２に動力信号を分配するマネジメント回路を含む。置換可能なファントレイ１４０が、エンジン１００を冷やすため、エンジンブレード１３２の下方に装備される。キャビネット１１０は、互いの頂部に積み重ねられ電源装置１４４を保持する動力フレーム１４６の頂部上に配置されるサブシャシー対１２９を含む、シャシーアセンブリ１２８内で、エンジンブレード１３２の多重列を伴うのが好ましい。キャビネット１１０は、イーサネット（登録商標）ネットワークスイッチ４４、１４７と、Ｆｉｂｒｅ  Ｃｈａｎｎｅｌネットワークを越えるディスクドライブ５０に付属する記録部スイッチ１４９とを装備するラックも、含むことが好ましい。
【００３４】
本発明は、各々少なくとも２つのエンジンブレード１３２を有する第１の管理グループ５２−ａと第２の管理グループ５２−ｂとに割り当てられる種々のサーバ４６を適切なアプリケーションソフトウエアと共に構成するサーバボード４６を伴うエンジンブレード１３２を収容する単体のキャビネット１１０に関して記述するのであるが、サーバファーム４０は、サーバファーム４０内のサーバ４６の全数に依存するどんな顧客数にも管理グループ５２を適応させ得る、ということが理解される。多数キャビネット１１０は統合されて所与の位置でのサーバ４６全数を概算し得るのが好ましい。以下に述べるように、エンジングループマネジャ４８の制御下で稼動する単一のサーバファー部４０の部分として、地理的に知覚する位置の多数のキャビネット１１０をリンクすることも可能である。
【００３５】
好適な実施形態では、各々のエンジンブレード１３２のサーバボード１０２は、Ｉｎｔｅｌ、ＳＰＡＲＣやＰｏｗｅｒＰＣデザイン等のための最も最近のプロセッサが配置され得、それらの各々は、ＷｉｎｄｏｗｓＮＴ、Ｗｉｎｄｏｗｓ２０００、Ｌｉｎｕｘ若しくはＳｏｌａｒｉｓなどの標準的なオペレーティングシステム環境をサポートし得る。各々のエンジンブレード１３２は、一つ又は複数のサーバボード１０２を適応させ得、各々のサーバボードは、現行のＡＴＸフォームファクタ若しくは将来業界に取り込まれ得る新しいフォームファクタに従うシングルのプロセッサ、若しくはマルチプロセッサであればよい。通信チャネル１０６は、ネットワークスイッチ４４若しくは記憶部スイッチ１４９のために通信パスから分離するＣｏｎｔｒｏｌｌｅｒ  Ａｒｅａ  Ｎｅｔｗｏｒｋ（ＣＡＮ）バスが実装されるのが好ましい。第２のフォールトバックアップ通信チャネル１０６’が、グループマネジャソフトウエア４８に対するフォールトトレラント及び冗長通信パスを許容するために、設定されてもよい。
【００３６】
従来のサーバでは、ポインタ及びスタートアップ構成情報は、サーバボード上の手作業のスイッチでセットされるか、サーバボード上のＰＲＯＭチップの中にハンドコードされるか、サーバボードがアクセスできるローカルハードドライブ上の固定位置に格納されるか、である。ホストボード１０４上の管理回路は、ポインタ及びスタートアップ構成情報がホスト管理回路により実際に供給されるように、適切なフックをサーバボード１０２の中へはめ込むように設計される。エンジンブレード１３２は、ローカルハードドライブ１０７上に格納される情報が通信チャネル１０６を介するホストボードにより構成されるようにホストボード１０４によってアクセスされるローカルハードドライブ１０７を含んでもよい。更に、ホストボード１０４は、サーバボード１０２への電力の印加を制御するＡＴＸ動力管理シーケンスをエミュレートすることによってキャビネット１００への共通の電力装置を利用できる電力管理回路１０８を含むのが好ましい。バックチャネルイーサネットスイッチ１４７も、アプリケーション及びデータ情報の通信をインターネット２２に渡る外部に経路付ける必要が無く、サーバファーム４０の範囲内で種々のサーバボード１０２の間で済ませることを許容するのが好ましい。
【００３７】
好適な実施の形態では、各々のキャビネット１１０は、３２までのエンジンブレード１３２を収容し得る。この構成では、ネットワークスイッチ４４、１４７は、Ｆｏｕｎｄｒｙの２つの３２回路のスイッチとなるイーサネットネットワークルータを含む。好ましい。ネットワークスイッチ４４、１４７によって、サーバ４６とネットワークスイッチ４４、１４７との間の接続の再構成が、サーバのためのＩＰアドレスを変更することで動的に調整され得るのが好ましい。ディスク記録ユニット５０に関しては、２つのオプションが利用可能である。第１に、独特のハードウエア及びソフトウエアは、基礎をなすＳＡＮ記録ハードウエア構成の詳細を抽出するディスク記録ユニット５０とエンジンブレード１３２との間のクロスバースイッチ１４９の形態の中に挿入され得る。この場合、ディスク記録ユニット５０と各々のブレード１３２との間のリンクは、ソフトウエアＡＰＩのセットを介してクロスバースイッチ１４９に連絡する。一方で、商業的に利用可能なＦｉｂｒｅ  Ｃｈａｎｎｅｌスイッチ、即ちＲＡＩＤ記録ボックスは、ブレード１３２とディスク記録ユニット５０との間に動的に連結を形成するのに利用され得る。いずれにせよ、エンジングループマネジャ４８の内部のソフトウエア層は、サーバブレード１３２とネットワークスイッチ１４７との間の接続に対し必要な構成の調整を行ない、よってディスク記録ユニット５０が完遂される。別の実施形態では、サーバ４６の一部が、ネットワークスイッチ即ちディスク記録ユニットに恒常的にケーブル接続し、例えばサーバファーム４０の所与の部位によりサポートされる顧客アカウントのセットが、再割り当てされ得ない基本数のサーバ４６を常に含んでも、スイッチコストを減少できる。この場合、各々の管理グループ５２のための基本数のサーバ４６は、その管理グループ５２のための関連ネットワークスイッチ１４９とディスク記録ユニット５０に恒常的にケーブル接続しうる。
【００３８】
再び図４及び図５を参照すると、本発明のサーバファームシステム４０は、多数顧客アカウントに設定されるホストサービスを動的に管理し得る。少なくとも５つのサーバ４６がイントラネット５４に操作自在に接続することが見て取れる。イントラネットは、サーバ４６をインターネット２２と相互接続させるのと同じネットワークスイッチ４４を越えて、若しくはサーバを互いに相互接続するネットワークスイッチ１４７と同じネットワークスイッチを越えて、形成されるのが好ましい。各々のサーバ４６は、ネットワークスイッチ４４及び／又は１４７により形成されるイントラネット５４から分離する少なくとも一つの他のサーバ４６を通信チャネル１０６に供給するホストボード１０４上に管理回路を有する。
【００３９】
少なくとも４つのサーバ４６が、サーバ４６をモニタするローカル判断ソフトウエアプログラム７０を実行し、通信チャネル１０６を越えてステータス情報を通信するように構成される。これらサーバ４６の少なくとも２つが、第１の顧客アカウントのための第１の管理グループ５２−ａに割り当てられ、第１の顧客アカウントにとって唯一であるソフトウエア及びデータにアクセスしその顧客アカウントのためにインターネットへのホストサービスを提供するように構成される。サーバ４６の少なくとも別の２つが、第２の顧客アカウントのための第２の管理グループ５２−ｂに割り当てられ、第２の顧客アカウントにとって唯一であるソフトウエア及びデータにアクセスしその顧客アカウントのためにインターネットへのホストサービスを提供するように構成される。サーバ４６の少なくとも一つは、他のサーバ４６上で実行するローカル判断ソフトウエアプログラム７０からのステータス情報を収集するマスタ判断ソフトウエアプログラム７２を実行する。一つの実施形態では、サーバ４６の対は、マスタ判断ソフトウエアプログラムのためにフォルトトレラント／冗長プロセスプラットフォームを形成するフォルトトレラント統合ソフトウエアを利用して、共に従属する。以下に述べるように、マスタ判断ソフトウエアプログラム７２は、ローカル判断ソフトウエアプログラム７０から収集された少なくともステータス情報に反応して、少なくとも一つのサーバ４６’を第１の管理グループ５２−ａから第２の管理グループ５２−ｂへ動的に再割り当てする。
【００４０】
両方の管理グループ５２のためのサーバ４６は、所与の顧客アカウントのために詳細化されたどの構成ででも配置され得る。図３に示すように、管理グループ５２−ｂのためのサーバ４６の３つは、フロントエンドサーバとして構成され、一つのサーバ４６は顧客アカウントに対するバックエンド／コンピュートサーバとして構成される。第２の管理グループ５２−ｂのための顧客アカウントに対するピーク利用活動度が相当に増加するのに応じて、第１の管理グループ５２−ａのためのサーバとしての現行の利用から、第２の管理グループ５２−ｂのためのバックエンド／コンピュートサーバとしての利用へ、サーバ４６’を再割り当てすることが必要であることを、マスタ判断ソフトウエアプログラム７２は判断する。この判断が到着する方法に関する好適な実施形態を、ローカル判断ソフトウエアプログラム７２の稼動の記述に関連して、説明する。説明の順を追うと、マスタ判断ソフトウエアプログラム７２は、図４に示されるように第２の管理グループ５２−ｂに対し再割り当てされるべきサーバ４６’の動的再割り当てを指示する。
【００４１】
本発明の好適な実施形態は、第１の管理グループ５２−ａから第２の管理グループ５２−ｂへの再割り当ての形態で示されるが、本発明は、所与の管理グループ５２に現下割り当てられていないが、稼動する管理グループ５２から引き揚げられるべきだとする要求が必ずしも無くとも再割り当てされてもよいとする利用可能サーバ４６’の共通プールを設定するように、実施されてもよいと、理解され得る。例えば、３２のサーバ４６を有するサーバファーム４０は、６つのサーバを４つの異なる顧客アカウントの各々に割り当て、一つのサーバ４６はマスタ判断ソフトウエアプログラム７２を実行し、残余の７つのサーバ４６のプール５６は初期には割り当てされないがその７つのサーバに対し定義されるなら４つのどの管理グループに対しても割り当てされ得る、というように設定され得る。管理グループへのサーバの割り当ては、本発明に係るサーバファーム４０の進行操作の間に動的になされるから、本発明の好適な実施形態では、このプール５６をバッファとして利用し、現在の管理グループ５２から先ず再割り当てされるサーバ４６’を外す必要を無くすことによって、再割り当てされるサーバ４６’を管理グループ５２の中に持ち込むのに必要な時間を更に減少させる。一つの実施形態では、プール５６はウオームサーバとコールドサーバの両方があり得る、ウオームサーバは、特定の管理グループ５２のために既に構成されているサーバ４６であり、よってそのウオームサーバを管理グループに結合させるためにそのウオームサーバをリブートする必要が無い。コールドサーバは、特定の管理グループ５２に対して構成されていないサーバであり、よってそのコールドサーバを管理グループに結合させるためにはそのコールドサーバをリブートすることが必要である。
【００４２】
再割り当てされるサーバ４６’は単に新しい管理グループに割り当てされ得るか、又は、第１の管理グループ５２−ａから第２の管理グループ５２−ｂへ同時に再割り当てされる複数の再割り当てサーバ４６’のグループとして再割り当てされる、ということも理解される。ネットワークスイッチ４４、１４７及び記録スイッチ１４９がそのような動的な再割り当てを適応させるように如何に構成されるかに関する文脈においては、ネットワーク４４、１４７及び／又は記録スイッチ１４９での動的構成ポートの数を減少させることが必要若しくは望ましいならば、多数のサーバ４６はグループとして共に再割り当てされてもよい、ということも理解される。
【００４３】
本発明の有意な利点の一つに、一つの管理グループ５２−ａから別の管理グループ５２−ｂへサーバを再割り当てするプロセスは、そのサーバが第２の管理グループ５２−ｂの一部としてサービス状態に入る前に、再割り当てされるサーバ４６’からの、第１の管理グループ５２に対する特定の顧客アカウントに関連する状態を、全てきれいに拭い取ることである。このことにより、異なる顧客アカウント間のデータに対する意識的な若しくは無意識のアクセスを排除する自然且つ非常に実効性のあるセキュリティメカニズムが提供される。サーバ４６又は４６’が、所与の管理グループ５２−ａのメンバで無いならば、該サーバが異なる管理グループ５２−ｂに対するデータ若しくは情報にアクセスする方法は無い。異なる顧客アカウントを越えてホストサービスをするための共有メモリスペース及び／又は共通オペレーティングシステムを用いるメインフレームサーバ若しくは他のより大きいサーバシステム内で実行されなければならない複雑で潜在的に不確定なソフトウエアセキュリティ特性の代わりに、本発明は、従来のサーバファーム構成で見られる顧客アカウント間でのシンプルな物理的独立という利点を保持しており、ハードウエアをいっそう利用する要求若しくは機会の折に、そのハードウエアに自動的且つ動的に再構成させる際であっても、上記利点を保持する。認証のためのアクセスとこの再構成の制御との唯一のポイントは、帯域外通信チャネル１０６を越えてマスタ判断ソフトウエアプログラム７２を介する。
【００４４】
図１４に示されるように、各々のサーバ４６は、マスタ判断ソフトウエアプログラム７２の制御下でインターネットにプログラム上で接続するのが、好ましい。マスタ判断ソフトウエアプログラム７２は、再割り当てされるサーバ４６’が、第２の管理グループの顧客アカウントに特有のソフトウエア及びデータを格納するディスク記録ユニットの一部に捜査上接続するように、スイッチすることも行なう。マスタ判断ソフトウエアプログラム７２が利用するステータス情報の少なくとも一部を通信するための、ネットワークスイッチ４４を越えるイントラネット５４から分離している帯域外通信チャネル１０６の利用は、セキュリティ、故障分離、及び帯域幅アイソレーションのために、為されることが好ましい。好適な実施形態では、通信チャネル１０６は、キャビネット１０６内部で１Ｍｂ／ｓの帯域幅で稼動するシリアルのＣｏｎｔｒｏｌｌｅｒ  Ａｒｅａ  Ｎｅｔｗｏｒｋ（ＣＡＮ）であり、第２のバックボーンも異なるキャビネット１０６間で１Ｍｂ／ｓの帯域幅で稼動する。インターネットプロトコル（ＩＰ）を利用する通信を伴う分離のイントラネットは、ＣＡＮバスのようなシリアルマネジメントインタフェースの代わりに、通信チャネル１０６のために利用され得る、ということが理解される。もっとも、そのような実施形態は、ホストボード１０４に接続する通信チャネル１０６に関して要求される通信のレベル及び複雑性のために実効的に過剰設計される。イントラネット５４の一部として通信チャネル１０６を実施することは可能であるが、セキュリティ、故障分離及び帯域幅アイソレーションの理由のため、そのような実施は好ましくない。
【００４５】
図８は、所与の顧客アカウントのため本発明により利用される種々のデータ及びソフトウエア層の一つの実施形態の階層関係のブロック図である。顧客データ及びデータベース６０は、この階層の基礎層を形成する。ウエブデータマネジメントソフトウエア層６２が、記録システム５０を含む記録ユニットの多数例を越えて顧客データ６０を管理するために、組み込まれてもよい。クラスタ及び／若しくは付加バランス感知アプリケーションソフトウエア６４は、顧客ウエブサイトのためのソフトウエア及びデータと従来からみなされているトップ層を含む。付加バランスソフトウエア６６は、共通の管理グループ５２の一部として多数サーバを共にグループ化する。従来のオペレーティングシステムソフトウエア６８には多数例が存在し、ひとつが個々のサーバ４６に対するものである。一方で、付加バランスソフトウエア６６とオペレーティングシステムソフトウエア６８は、単一の管理グループ５２内部の共通ソフトウエアパッケージの一部として、統合され得る。従来のオペレーティングシステムソフトウエア６８の上には、多数の顧客アカウント５２−ａ及び５２−ｂに渡る資源を管理する本発明に係るエンジンオペレーティングソフトウエア４８が存する。
【００４６】
図９に示される本発明の一つの実施形態では、第１の管理グループ５２−ａに割り当てされるサーバ４６は第１ののサイト８０に位置し、第２の管理グループ５２−ｂに割り当てされるサーバ４６は第１のサイト８０から地理的に離れた第２のサイトに位置する。この実施形態では、システムは、第１の管理グループ５２−ａのための少なくともデータを第２のサイト８２に自動的に複写する構成も、更に含む。好適な実施形態では、ネットワークスイッチ４４から分離する通信チャネル８４は、第１のサイト８０のディスク記録ユニット５０−ａからのデータを第２のサイト８２のディスク記録ユニット５０−ｂに複写するのに利用される。この構成の目的には、２面性がある。先ず、データの複写により、第１のサイト８０での災害時に災害からのリカバを可能にする冗長の且つバックアップの保護がもたらされる。次に、第２のサイト８２でデータの複写により、本発明は、第２のサイト８２に配置される利用可能サーバのプールの内のサーバ４６を含むことができる。これらサーバを第１の管理グループ５２−ａに動的に再割り当てすることで第１の顧客のホストサービスを求める要求の増大を満たすように、マスタ判断ソフトウエアプログラム７２がそれらプールの利用可能サーバを利用しうる。
【００４７】
第１のサイト８０のマスタ判断ソフトウエアプログラム７２と第２のサイト８２のマスタ判断ソフトウエアプログラム７２との調整は、各々のサイトでのマスタ判断ソフトウエアプログラム７２と通信するグローバル判断ソフトウエアルーチン８６の利用により完遂されるのが、好ましい。このモジュラ構成により、マスタ判断ソフトウエアプログラム７２は、所与のサイトのサーバ資源の管理に焦点を当てることができ、更にこのモジュラ構成は、各々のサイト８０、８２にグローバル判断ソフトウエアルーチン８６から付加的なオフサイトサービスを要求させるか、オフサイトサービスを利用可能とするように提示させるか、のコンセプトを拡張する。ローカル判断ソフトウエアプログラム７０が付加的なサーバに対する要求を為すか、又は、サーバを、所与のサイトでのマスタ判断ソフトウエアプログラム７２に対する再割り当て可能とするか、と同じやり方となる。
【００４８】
本発明の多重サイトの実施形態は、商業的に利用可能なＳＡＮ又はＮＡＳ記録ネットワークソフトウエアを利用し、２層構造のデータ冗長性及び複写階層を実施するのが好ましい。図９に示すように、第１の顧客アカウントの顧客のための顧客データの稼動バージョン７４は、第１のサイト８０のディスク記録ユニット５０上に維持される。データミラリング、データシャドウイング、若しくはＲＡＩＤデータ保護のような、冗長によるデータ保護は、第１のサイト８０の第１の顧客アカウントのための顧客データのバックアップバージョン７６を設立するのに利用される。ネットワークソフトウエアは通信チャネル８４を利用し、第２のサイト８２に配置される第１の顧客アカウントのための顧客データの第２のバックアップバージョン７８を生成する。インターネット２２に対するネットワークスイッチ４４の接続から独立する通信チャネル８４の利用は、冗長通信経路を許容し、第２のバックアップバージョン７８を生成するのに必要なバックグラウンド通信活動の影響を最小限とするものであるのが、好ましい。一方で、第２のサイト８２に位置する第１の顧客アカウントのための顧客データのバックアップバージョン７８は、ネットワークスイッチ４４及びインターネット２２を介して経路付けされ得る。別の実施形態では、顧客データの付加的なバックアップバージョンは、付加的なサイト配置で複写され、更に、サーバ資源を十分に利用しない顧客アカウントからこれら資源を要求する顧客アカウントにサーバを動的に再割り当てするシステムの容量を拡張するのが、好ましい。
【００４９】
図１０に示されるように、本発明は、サーバ資源を十分に利用しない顧客アカウントからこれら資源を要求する顧客アカウントにサーバを動的に再割り当てできるので、サーバファーム４０の資源は、ホストサービスを多数顧客アカウントに供給する際により実効性をもって利用され得る。顧客アカウント９１、９２、９３、９４及び９５の各々に対し、個々の顧客アカウントへのサーバ４６の全体的な割り当ては、比較的一定の限界に近い過剰容量の帯域幅が個々の顧客アカウントに維持されるように、完遂される。所与の顧客アカウントに割り当てられるハードウエア資源の変動が時間や日や週の単位で発生する、現存のサーバファームとは異なり、本発明では、要求ベースに基づき動的に割り当てされるサーバ資源での分刻みの変動が、許容される。図１０は、サーバファーム４０の一部を配置する多数の地理的に独立するサイトを利用する利点も示す。顧客アカウント９４及び９５に対するピーク利用は、サイト配置８０とサイト配置８２との間の時間帯の差異のために、他の顧客アカウント９１、９２及び９３のものから時間シフトしていることが、見うけられる。本発明は、ピーク利用におけるこれら時間シフトの差異という利点を持ち得、活動度における小康の最中にある他のサイト配置からピーク利用の期間中のサイト配置に、変動するサーバ容量を割り当てる。
【００５０】
図１３に示される本発明の多重サイト構成の一つの実施形態においては、少なくとも３つの独立したサイト配置８０、８２及び８４が、互いに離れて、少なくとも２４を（Ｎ＋１）で割ってできる数（商）の時間だけ地理的に位置することが好ましい。ここで、Ｎとは、多重サイト構成での独立したサイト配置の数を示す。３つの独立したサイト配置８０、８２及び８４を有する実施形態では、サイト配置は、互いに離れて８時間であることが好ましい。この地理的分離により実現される時間の差異により、全３サイトに配置される顧客アカウントの利用パターンは、所与の配置での各々のサーバが一つ又は複数の配置から他の配置へ動的に再割り当てされるサーバを利用できないとする場合に要求されるより相当少ない結合数のサーバにより、統合されサービスされることになる。サイト配置８０が夜間利用レベルを経験している際にこの利点は顕著になり、このサイト配置８０からのサーバは、昼間利用レベルを経験しているサイト配置８２に動的に再割り当てされ得る。同時に、サイト配置８４が夕方利用レベルを経験しているならば、この配置から別の配置へ、若しくはその逆に、サーバを再割り当てすべく適合されてもよく、適合されなくてもよい。一般的に、サイト配置は、後の時間帯（即ち、そのサイトの東側に）のサイト配置から先ず容量を借りるとみえるように構成され、先の時間帯（即ち、そのサイトの西側に）のサイト配置に利用可能な特別の容量を作成するようにみえる。他の好適な例も、後の利用及び先の利用パターンに依存するが、確立可能である。
【００５１】
ここで図１１を参照すると、マスタ判断ソフトウエアプログラム７２の好適な実施形態が示される。マスタ判断ソフトウエアプログラム７２は、資源データベース１５０、サービスレベルアグリーメントデータベース１５２、マスタ判断ロジックモジュール１５４及びディスパッチモジュール１５６を、含む。マスタ判断ロジックモジュール１５４は、資源データベース１５０とサービスレベルアグリーメントデータベース１５２にアクセスし、ステータス情報を資源データベース１５０とサービスレベルアグリーメントデータベース１５２内の情報と比較し、第１の顧客アカウントから第２の顧客アカウントへサーバを動的に再割り当てするか否かを判断する。ディスパッチモジュール１５６は、再割り当てされるサーバ４６’のための初期ポインタを第２の管理グループ５２−ｂのための顧客アカウントに特有のソフトウエア及びデータにアクセスするように設定することを、通信チャネル１０６を利用してマスタ判断ロジックモジュール１５４によって指示され、よって少なくとも一つのサーバが第２の管理グループ５２−ｂに結合するように再割り当てされるサーバ４６’を再初期化するとき、サーバを動的に再割り当てするためにマスタ判断ロジックモジュール１５４に操作自在にリンクされる。ディスパッチモジュール１５６は、各々のサーバ４６に対し、接続ルールのセット１６０と個人的モジュールのセット１６２を含むのが好ましい。接続ルール１６０は、所与のネットワークスイッチ４４若しくはデータ記録ユニット５０に特定のサーバ４６を接続する命令を与えている。個人的モジュール１６２は、顧客アカウントのための管理ワークグループに付加されるべきサーバボード１０２の特定ソフトウエア構成の詳細を記す。ディスパッチモジュール１５６がサーバを再割り当てする必要を決定すると、接続ルールのセット１６０と個人的モジュールのセット１６２が、特定の管理グループ５２にディスパッチされるサーバ４６を如何に構成するか、を決定することの評価を行なう。
【００５２】
本発明が離隔するアカウントを越えて動的にホストサービスを供給する方法に注目する別の方法は、特定の管理グループ５２のためのソフトウエア及びデータにアクセスするように選択的に構成される複数の仮想サーバのプールに割り当てされるサーバ４６の一部を眺めることである。ディスパッチモジュール１５６が特定の管理グループ５２にサーバ４６を追加する必要を決定すると、仮想サーバのプールからその管理グループにサーバの一つが自動的に割り当てられる。逆にいえば、ディスパッチモジュールが管理グループがそのサーバ４６の一つを手放すことを決定すると、その手放されるサーバは、別の管理グループへの再割り当てに利用され得る仮想サーバのプールに付加される。本発明をこの観点から眺めると、適宜の即ち要求をベースに、複数の仮想サーバのプールから一つ又は複数の仮想サーバを“製造”し形成するように、グループマネジャソフトウエア４８か稼動することがわかる。前に説明したように、仮想サーバのプールは、ウオームプールでもよくコールドプールでもよく、それらの組み合わせでもよい。仮想サーバは、接続ルール１６０と個人的モジュール１６２のセットに従って所望の管理グループにより利用されるように、製造され又は構成される。
【００５３】
この実施形態では、マスタ判断ロジックモジュール１５２は、マスタ判断ソフトウエアプログラムに関する情報を表示しアカウントメンテナンスを受け入れデータベースの中にて情報をプロセスに更新する管理コンソール１５８に、操作自在に接続される。ビリングソフトウエアモジュール１６０は、所与の顧客アカウントへのサーバの割り当てを基にして請求の追跡を維持するために、エンジングループマネジャ４８に統合される。サーバが顧客サービスレベルアグリーメントを基にして顧客アカウントに動的に再割り当てされるときのホストサービスに対しては、顧客アカウントがより高いレートで請求されるのが好ましい。
【００５４】
図１２は、所与の顧客アカウントのための３つの異なるサービスレベルアグリーメント構成の表示を示す。この実施形態では、サービスレベルアグリーメントは、１ヶ月のような所与の期間に対するホストサービスを提供するために、為される。１７０で示される第１のレベルでは、顧客アカウントは、６４００００の同時接続のためのホストサービスをサポートする容量が提供される。顧客アカウントが、第１のレベル１７０に対して委託される容量よりも大きい容量をサポートするためにサーバの再割り当てをする必要が無いならば、顧客は委託される容量のレベルに対するレートを確立するように課金される。１７２デで示される第２のレベルでは、顧客アカウントは、第１のレベル１７２の容量の２倍の容量をサポートするため、動的に拡張され得る。好適な実施形態では、エンジングループマネジャ４８が、予測されたピーク利用より高いピーク利用に適合する第２のレベル１７２の容量をサポートするために、顧客アカウントにサーバを動的に再割り当てすると、顧客アカウントは、付加的利用が要求された期間に対しては、より高いレートにて課金される。更に、顧客アカウントは、第２のレベル１７２により示されるより高いレベルのサービスを初期化するため一時金により課金され得る。一つの実施形態では、第２のレベル１７２のサービスのための課金は、第１のレベル１７０に課金されるレートの更に数倍のレートで生じる。第２のレベル１７２は、所与の期間、顧客に利用可能な保証された拡張レベルを示す。更に、第３のレベル１７４は、顧客アカウントのためホストサービスを明白に供給するために持ち込まれ得る選択的に拡張される付加的なサービスレベルを与える。この実施形態では、第３のレベル１７４は、第１のレベル１７０のより多数倍のサービスレベルを供給する。この拡張された付加的なサービスレベルを提供するための一つの実施形態では、ホストシステムは、このサービスレベルに適合する要求数のサーバを持ち込むために前に説明したように多重サイト構成を利用する。拡張された付加的なサービスが顧客アカウントに再割り当てされる期間に対して、その顧客アカウントにはより高いレートで課金されるのが、好ましい。一つの実施形態では、第３のサービスレベル１７４に対する課金は、拡張された付加的な第３のサービスレベル１７４が顧客アカウントに供給される所与の期間に対して、第１のレベル１７０の更に多数倍のレートで生じる。更に、顧客アカウントは、所与の期間のいつにおいても、この第３のサービスレベル１７４を開始するための一時金が課金される。所与の期間の終わりには、顧客は、所与の顧客アカウントに対して約定されたサービスレベルを変更し得る。
【００５５】
図１２に示すように、サービスレベルアグリーメントは、所与の顧客アカウントに対するより高い予測ピーク利用に応じて、第１の期間から第２の期間へ５０パーセント増加する。所与の顧客アカウントのためのサービスレベルアグリーメントに対する期間は、月単位が基本であり、近づく請求期間に関しサービスレベルアグリーメントへ推奨の上変更するという提案が、顧客に提示されるのが好ましい。この例は同時接続数の形態を示しているが、所与の顧客アカウントのためのサービスレベルアグリーメントは、同時接続数、ヒット、転送データ量、トランザクション数、接続時間、種々のアプリケーションソフトウエアプログラムで利用される資源、発生する歳入、若しくはそれらいずれでもの組み合わせなどの、種々のパフォーマンス計測指標によって形成され得るということが、理解されるべきである。サービスレベルアグリーメントは、フロントエンドサーバ、バックエンドサーバ、ネットワーク接続、又はディスク記録ユニットなどの、種々のタイプの資源に対する付託の種々のレベルに対して提示されてもよいということも、理解されるべきである。
【００５６】
ここで図１５を参照すると、ローカル判断ソフトウエアプログラム７０の好適な実施形態のブロック図が説明される。一連の計測モジュール１８０、１８１、１８２、１８３、及び１８４は、各々、ローカル判断ソフトウエアプログラム７０が稼動する特定サーバの操作における独立評価項目を実施した。これら計測モジュールからの出力は、ローカル判断ソフトウエアプログラム７０の統合モジュール１９０に対して与えられる。予報モジュール１９２は、種々の要求に対する予想される応答時間及びその可能性を作成する。優先度入力１９４はサービスレベルアグリーメントデータベース１５２からマスタ判断ソフトウエアプログラム７２により与えられ、ファジイ推論システム１９６は、管理グループ５２のためにエンジンブレード１０４を付加する要求を為すのか、あるいは、管理グループ５２からエンジンブレードを外す、即ち除去する申し出を為すのか、を判断する。ブレードを付加する、若しくは除去するという要求は、マスタ判断ソフトウエアプログラム７２への通信チャネル１０６を越えて通信される。一つの実施形態では、統合モジュール１９０は所与の管理グループ５２内部の個々のサーバ４６上で実行され、予報モジュール１９２及びファジイ推論モジュール１９６は所与の管理グループ５２内部の単一のサーバ４６上のみで実行され、種々の計測モジュール１８０−１８４の出力は、通信チャネル１０６を渡って割り当てされたサーバ４６に通信される。別の実施形態では、統合モジュール１９０、予報モジュール１９２及びファジイ推論モジュール１９６は、ブレードを付加する、又は除去する要求を生成するのに必要な情報の冗長性、若しくは分配処理の目的のために、所与の管理グループ内部の一つ以上のサーバ上で実行されてもよい。
【００５７】
統合モジュール１９０は、次の式に従って種々の計測モジュール間の平衡を実施するのが好ましい。
2004519749.tif 000003
ｉ＝ｌ  ｔｏ  Ｗｋ
【００５８】
ここで、Ｔｋｉは、計測タイプｋのｉ回目の要求のための時間であり、ｗｋは、計測タイプｋのウインドウサイズであり、ｍｉｎｋは計測タイプｋに対して予想される最小時間であり、ｍａｘｋは、計測タイプｋに対し許容される最大時間である。バランスされた要求レートＢｋは、ローカル判断ソフトウエアプログラム７０の予報モジュール１９２とファジイ推論モジュール１９６に渡される。計測タイプｋに対するウインドウサイズは、計測モジュール１８０−１８４の不必要な侵入を最小限とするように設定され、同時に、折よい十分な応答が管理グループ５２に対する利用要求を増加させることを許容する。
【００５９】
図１６は、変動する付加状況下での種々の計測モジュール１８０−１８４からのワークロード計測を示す。予想応答時間及びその応答時間の可能性に関し一定の予測見積を提示するワークロード計測は、一つも無いことがわかる。従って、ファジイ推論モジュール１９６は３つの基礎的パラメータを考慮しなければならない。種々の要求に対する予想応答時間、これら要求の優先度、それら発生の可能性、である。ファジイ推論モジュール１９６はこれら３つの考慮の全てを混合し、管理グループ５２にブレードを付加することを要求するか、又は除去することを要求するかに関する決定をなす。ファジイ推論ルールの例は、以下の通りである。
【００６０】
ｉｆ（ｐｒｉｏｒｉｔｙ  ｉｓ  ｕｒｇｅｎｔ）ａｎｄ（ｐｒｏｂａｂｉｌｉｔｙ  ｉｓ  ａｂｕｎｄａｎｔ）ａｎｄ（ｅｘｐｅｃｔｅｄ  ｒｅｓｐｏｎｓｅ  ｔｉｍｅ  ｉｓ  ｔｏｏ  ｈｉｇｈ）ｔｈｅｎ（ｍａｋｅ  ｒｅｑｕｅｓｔ  ｆｏｒ  ａｄｄｉｔｉｏｎａｌ  ｂｌａｄｅ）
【００６１】
ファジイ推論モジュール１９６の最終結果が、予想応答時間と、この管理グループ５２に対する応答時間の可能性とのグリッドに関して、付加するサーバを要求するニーズの輪郭を描く判断面を生成することであることが、好ましい。判断面の例が、図１７に示される。
【００６２】
この発明の開示の一部は、著作権保護下にある。著作権者は、特許及び商標の官庁でのファイル若しくは記録に現れるような、本発明開示のファクシミリ複製を認めるものであるが、その他は全て著作権が及ぶ。
【００６３】
本発明に係る自動化システムの好適な実施形態を説明したが、多数の変更及び変動が可能であり本発明の範囲は請求項により定義されるべきである、ということが認められる。
【図面の簡単な説明】
【図１】ホストサービスプロバイダのためのサーバファームの先行技術の構成の簡素化されたブロック図である。
【図２】先行技術のサーバファームホスト多重顧客アカウントのためのサーバ容量に関するインターネットトラフィックのグラフ表示である。
【図３】本発明に係るサーバファームの構成の単純化したブロック図である。
【図４】ハードウエア故障をアドレスするため第１の顧客アカウントから第２の顧客アカウントへのサーバの動的再割り当てを示す、図３と同様の単純化したブロック図である。
【図５】増大した利用要求をアドレスするため第１の顧客アカウントから第２の顧客アカウントへのサーバの動的再割り当てを示す、図３と同様の単純化したブロック図である。
【図６】本発明に係るサーバファームのコンポーネントの好適な実施形態のブロック図である。
【図７】本発明に係るサーバファームのためのハードウエアの好適な実施形態の分解斜視図である。
【図８】所与の顧客アカウントのため本発明により利用される種々のソフトウエア層の階層関係を示すブロック図である。
【図９】地理的に離隔する場所を超えて実行される本発明の実施形態のブロック図である。
【図１０】多数顧客のアカウントをホストする際の本発明のサーバファームのためのサーバ容量に関連するインターネットトラフィックのグラフ表示である。
【図１１】本発明のマスター判断ソフトウエアプログラムの好適な実施形態を示すブロック図である。
【図１２】所与の顧客アカウントのための３つの異なるサービスレベルアグリーメント構成のグラフ表示である。
【図１３】本発明の多重サイト実施形態のためのサーバ容量に関連するインターネットトラフィックのグラフ表示である。
【図１４】ネットワークスイッチと記録ユニットとの接続を制御するマスター判断ソフトウエアプログラムを示すブロック図である。
【図１５】ローカル判断ソフトウエアプログラムの好適な実施形態のブロック図である。
【図１６】変動する負荷状況下でローカル判断ソフトウエアプログラムの種々の計測モジュールからのワークロード計測のグラフ表示である。
【図１７】管理グループからのサーバを要求若しくは除去するローカル判断ソフトウエアプログラムにより生成される判断表面のグラフ表示である。
【符号の説明】
４０・・・サーバファーム、５０・・・ディスク記録部、１００・・・スケーラブルエンジン、１０２・・・サーバボード、１１０・・・キャビネット、１３２・・・エンジンブレード、１３４・・・インタフェースカード。
【図１】
2004519749.tif 000004
【図３】
2004519749.tif 000005
【図４】
2004519749.tif 000006
【図５】
2004519749.tif 000007
【図６】
2004519749.tif 000008
【図８】
2004519749.tif 000009
【図１４】
2004519749.tif 000010
【国際公開パンフレット】
2004519749.tif 000011
2004519749.tif 000012
2004519749.tif 000013
2004519749.tif 000014
2004519749.tif 000015
2004519749.tif 000016
2004519749.tif 000017
2004519749.tif 000018
2004519749.tif 000019
2004519749.tif 000020
2004519749.tif 000021
2004519749.tif 000022
2004519749.tif 000023
2004519749.tif 000024
2004519749.tif 000025
2004519749.tif 000026
2004519749.tif 000027
2004519749.tif 000028
2004519749.tif 000029
2004519749.tif 000030
2004519749.tif 000031
2004519749.tif 000032
2004519749.tif 000033
2004519749.tif 000034
2004519749.tif 000035
2004519749.tif 000036
2004519749.tif 000037
2004519749.tif 000038
2004519749.tif 000039
2004519749.tif 000040
2004519749.tif 000041
2004519749.tif 000042
2004519749.tif 000043
2004519749.tif 000044
2004519749.tif 000045
2004519749.tif 000046
2004519749.tif 000047
2004519749.tif 000048
2004519749.tif 000049
2004519749.tif 000050
2004519749.tif 000051
2004519749.tif 000052
2004519749.tif 000053
2004519749.tif 000054
2004519749.tif 000055
2004519749.tif 000056
2004519749.tif 000057
【国際調査報告】
2004519749.tif 000058
2004519749.tif 000059