(57)【要約】【課題】  キャパシティ・オンデマンドを容易にするためにウェブ・サーバを遠隔かつ動的に構成する方法とシステムを提供する。【解決手段】  本発明は、サーバが自ら生成するデータとともに果たす役割の定義に起因する厳格なインフラストラクチャとアーキテクチャに関し、サーバ・ファームなどの環境内において少なくとも１つのサーバを管理し監督する上で生じる問題点に対する解決策を提供する。この解決策は、サーバがＵＲＬを処理し、当該サーバを再始動する必要も当該サーバに対する手動による介入の必要もなく当該サーバがそれを遠隔のデータ・ソースに関連付けることを可能にするとともに、当該サーバから収集したパフォーマンスのデータを照合し解析して当該サーバが超過状態にあるのか稼働中なのかを判断するのを可能にするモジュール化した自動コンピューティング・コンポーネントの形態で提供する。
2005539298.tif 000002
【特許請求の範囲】
【請求項１】
キャパシティ・オンデマンドを容易にするためにサーバを遠隔かつ動的に構成する方法であって、
（ａ）クライアント装置が通信ネットワーク中の第１のサーバにリソースを要求するステップと、
（ｂ）前記第１のサーバが前記クライアント装置から前記リソースを求める前記要求を受領するステップと、
（ｃ）前記第１のサーバが、前記リソースを求める前記クライアントの前記要求を動的コンテンツ・モジュールに転送するステップであって、前記動的コンテンツ・モジュールは要求された前記リソースの提供元になりうるとともに利用可能な第３のサーバを特定し、要求された前記リソースを前記クライアント装置に送付する、ステップと、
（ｄ）前記第１のサーバおよび前記第３のサーバが出力するパフォーマンスのデータを照合し、前記第１のサーバが前記パフォーマンスのデータを第２のサーバに転送するステップと、
（ｅ）第２のサーバが、ステップ（ｄ）において照合した前記パフォーマンスのデータを解析して前記第１のサーバおよび前記第３のサーバのパフォーマンス能力を判定し、前記第１のサーバまたは前記第３のサーバが所定の閾値に到達しているか否かを確認するステップと、
（ｆ）前記第２のサーバが、ステップ（ｅ）に応答して前記第１のサーバまたは前記第３のサーバの割り振りを調整し、前記第１のサーバまたは前記第３のサーバの構成を更新する命令を動的構成モジュールに発行し、リソースの更新が成功したか否かを判断するステップと
を備えた
方法。
【請求項２】
さらに、
前記動的コンテンツ・モジュールが前記第３のサーバ用の接続構成ファイルを前記動的構成モジュールに要求するステップを備えた、
請求項１に記載の方法。
【請求項３】
前記動的構成モジュールが前記第１のサーバおよび前記第３のサーバの一方または双方用の構成設定を格納する、
請求項１に記載の方法。
【請求項４】
前記第１のサーバおよび前記第３のサーバの一方または双方の割り振りを調整する前記ステップがさらに、フリー・サーバ・リソース・プールから追加のサーバを割り振るステップを備えている、
請求項１に記載の方法。
【請求項５】
前記第１のサーバおよび前記第３のサーバの一方または双方の割り振りを調整する前記ステップがさらに、前記第１のサーバおよび前記第３のサーバの一方または双方の割り振りを解除して割り振り済みリソース・プールからフリー・サーバ・リソース・プールに戻すステップを備えている、
請求項１に記載の方法。
【請求項６】
前記第１のサーバおよび前記第２のサーバがＸＭＬデータ・ストリームを通じて互いに通信する、
請求項１または２に記載の方法。
【請求項７】
前記第２のサーバが、少なくとも１つの第１のサーバ用に中央制御点を提供する管理サーバである、
請求項１に記載の方法。
【請求項８】
要求される前記リソースを前記第１のサーバから分離して新たなサービスの導入または冗長なサービスの除去を可能にする、
請求項１に記載の方法。
【請求項９】
前記第１のサーバが複数のサーバである、
請求項１に記載の方法。
【請求項１０】
前記第３のサーバが複数のサーバである、
請求項１に記載の方法。
【請求項１１】
キャパシティ・オンデマンドを容易にするためにサーバを遠隔かつ動的に構成するシステムであって、前記システムは通信ネットワーク中にあるリソースを要求して受領するクライアント装置とともに使用するものであり、
第１のサーバであって、前記第１のサーバは動的コンテンツ・モジュール、動的構成モジュール、および報告モジュールを備え、さらに、
前記リソースを求める前記クライアントの要求を前記動的コンテンツ・モジュールに転送する手段と、
前記動的コンテンツ・モジュールが、前記要求されたリソースの提供元になりうる第３のサーバを特定する手段、および前記動的構成モジュールに格納されている、前記第３のサーバに付随する接続構成ファイルを検索・取得する手段と、
前記報告モジュールが、前記第１のサーバおよび前記第３のサーバが出力するパフォーマンスのデータを照合する手段、および前記パフォーマンスのデータを第２のサーバに転送する手段と
を備えた第１のサーバと、
第２のサーバであって、前記第２のサーバは解析モジュール、リソース割り振りモジュール、およびリソース更新モジュールを備え、前記第２のサーバは前記パフォーマンスのデータを前記解析モジュールに転送し、さらに、
前記解析モジュールが前記第１のサーバおよび前記第３のサーバのパフォーマンス能力を判定する手段、ならびに前記第１のサーバおよび前記第３のサーバが所定の閾値に到達しているか否かを確認する手段と、
前記リソース割り振りモジュールが、確認する前記手段に応答して前記第１のサーバおよび前記第３のサーバの一方または双方の割り振りを調整する手段と、
前記第１のサーバおよび前記第３のサーバの一方または双方の構成を更新する命令を前記第１のサーバの前記動的構成モジュールに発行する手段、および前記第１のサーバおよび前記第３のサーバの一方または双方の割り振りまたは割り振りの解除が成功したか否かを判断する手段と
を備えた第２のサーバと、
第３のサーバであって、前記第３のサーバは少なくとも１つのリソース、および前記第３のサーバが要求されたリソースを前記第１のサーバに提供する手段を備えた第３のサーバと
を備えた
システム。
【請求項１２】
前記第１のサーバおよび前記第３のサーバの一方または双方の割り振りを調整する前記手段が、さらに、追加のサーバをフリー・サーバ・リソース・プールから割り振る手段を備えている、
請求項１１に記載のシステム。
【請求項１３】
前記第１のサーバまたは前記第３のサーバの割り振りを調整する手段が、さらに、前記第１のサーバおよび前記第３のサーバの一方または双方の割り振りを解除して割り振り済みリソース・プールからフリー・サーバ・リソース・プールに戻す手段を備えている、
請求項１１に記載のシステム。
【請求項１４】
前記第１のサーバと前記第２のサーバとの間の通信を行なう手段がＸＭＬデータ・ストリームを通したものである、
請求項１１に記載のシステム。
【請求項１５】
前記接続構成ファイルが前記第１のサーバおよび前記第３のサーバ用の接続設定を含んでいる、
請求項１１に記載のシステム。
【請求項１６】
前記動的構成モジュールが、第１のサーバおよび第３のサーバ用の構成設定を格納する手段を備えている、
請求項１１に記載のシステム。
【請求項１７】
前記第２のサーバが、前記第１のサーバおよび前記第３のサーバ用の中央制御点用の手段を備えた管理サーバである、
請求項１１に記載のシステム。
【請求項１８】
要求される前記リソースが、新たなサービスを導入しうるように、または冗長なサービスを除去しうるように前記第１のサーバから分離されている、
請求項１１に記載のシステム。
【請求項１９】
前記第１のサーバが複数のサーバである、
請求項１１に記載のシステム。
【請求項２０】
前記第３のサーバが複数のサーバである、
請求項１１に記載のシステム。
【請求項２１】
コンピュータ読み取り可能な記憶媒体に格納されたコンピュータ・プログラム・コードであって、データ処理システムで実行すると、当該データ処理システムに請求項１に記載の方法を実行させるコンピュータ・プログラム・コードを含むコンピュータ・プログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はネットワーク・サービスの分野に関し、特にキャパシティ・オンデマンド（capacity on demand）を容易にするためにサーバを遠隔かつ動的に構成する方法に関する。
【背景技術】
【０００２】
多くの会社が様々なアプリケーションをホストしうる安全かつ頑健かつ柔軟なインフラストラクチャを提供するホスティング・サービスを顧客に提案している。上記アプリケーションとしては、たとえばウェブ・アプリケーションが挙げられる。このウェブ・アプリケーションには、たとえばオンライン・バンキング、オンライン・ショッピング、情報サービス、ホスティング・サービスなどが含まれる。ホスティング・サービスとは顧客に自分が使用した処理能力の分だけ支払うことを可能にするものであり、たとえば「使用した分だけ支払う機能（pay for used capacity)」が挙げられる。この「使用した分だけ支払う機能」により、顧客は最新の機器を対費用効果の高い態様で配備することが可能になる。ホスティング・サービスは多くの会社（business）に、自社の技術インフラストラクチャを社内に構築して運用することに対する代替ソリューションを提供するものである。その際、ソフトウェア・アプリケーションとハードウェア・リソース（たとえばサーバ）を管理するために他社のデータ・センタにあるコンピュータ・システムを活用する。これらのサーバとサービスを管理し監督することは多くのホスティング会社にとって解決すべき大きな課題である。というのは、サーバ・ファームのような環境にあるサーバを管理し監督することに付随する主要な問題点は、自身が生成し続けるデータに関してサーバが果たす役割の定義に起因してサーバのインフラストラクチャとアーキテクチャが厳格であるという点だからである。
【０００３】
たとえば特定の顧客の製品をサポートしているウェブ・サーバにリソースを厳格に割り当てると、能力の限界まで使用されておらず利用されているのだが高価すぎるウェブ・サーバのリソースが存在することになる一方、他の製品をサポートしている他のサーバは能力の限界まで酷使されるということになる可能性がある。また、今日の最新のウェブ・サーバ・ソフトウェアは複雑であるが柔軟であり、ＡＰＩ（Application Protocol Interface）を使用することにより基本的なＨＴＭＬ（Hypertext Markup Language)ページを提供する標準的なサービスを超えた強力な処理を容易にするように構成し拡張することができる。しかし、現在の配備の実務と技術では、ウェブ・サーバは構成ファイルまたはバイナリ・レジストリを用いて手動で構成する必要があるから、動作中は静的に保って特定のウェブサイト（またはウェブサイト群）に対する要求を処理する必要がある。また、特定のＨＴＭＬページ用の追加もしくは別のリソース、または、別のウェブ・サイトのＵＲＬを生成する必要がある場合、あるいは、サーバ・プールに新たなサーバを脱着する必要が生じた場合、変更を有効にするにはサーバを再起動しなければならない。この結果、サーバ・ファームの管理者側には多大な管理努力が必要になる。というのは、サーバを手動で構成するには多大な時間がかかるとともに、サーバをシャットダウンしたのち変更を有効にするためにサーバを再起動すると、ある期間、サービスの欠落を招く可能性があるので、これが常に好都合であるとは限らないからである。
【０００４】
米国特許出願公報（US patent application publication)第ＵＳ２００２／０００２６０２号（２６０２）には協働する複数のウェブ・サーバが出力するウェブ・ページを組織的な態様で提供することを目的とするリソースを指定しているクライアントの要求に応答してウェブ・ページをクライアントに提供するとともに信頼性の高い接続を維持し、サーバとクライアントが同期状態を維持して情報が失われないようにしたシステムが記載されている。
【特許文献１】米国特許出願公報第ＵＳ２００２／０００２６０２号
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記事項を実行してウェブ・サーバがＵＲＬを処理し当該ＵＲＬをデータ・ソースに関連付けうるようにするためには、人手によってウェブ・サーバに介入する必要があるとともに、変更を有効にするためにウェブ・サーバをシャットダウンして再起動しなければならない。
【課題を解決するための手段】
【０００６】
本発明は次に示す方法を提供するものである。
キャパシティ・オンデマンドを容易にするためにサーバを遠隔かつ動的に構成する方法であって、
（ａ）クライアント装置が通信ネットワーク中の第１のサーバにリソースを要求するステップと、
（ｂ）前記第１のサーバが前記クライアント装置から前記リソースを求める前記要求を受領するステップと、
（ｃ）前記第１のサーバが、前記リソースを求める前記クライアントの前記要求を動的コンテンツ・モジュールに転送するステップであって、前記動的コンテンツ・モジュールは要求された前記リソースの提供元になりうるとともに利用可能な第３のサーバを特定し、要求された前記リソースを前記クライアント装置に送付する、ステップと、
（ｄ）前記第１のサーバおよび前記第３のサーバが出力するパフォーマンスのデータを照合し、前記第１のサーバが前記パフォーマンスのデータを第２のサーバに転送するステップと、
（ｅ）第２のサーバが、ステップ（ｄ）において照合した前記パフォーマンスのデータを解析して前記第１のサーバおよび前記第３のサーバのパフォーマンス能力を判定し、前記第１のサーバまたは前記第３のサーバが所定の閾値に到達しているか否かを確認するステップと、
（ｆ）前記第２のサーバが、ステップ（ｅ）に応答して前記第１のサーバまたは前記第３のサーバの割り振りを調整し、前記第１のサーバまたは前記第３のサーバの構成を更新する命令を動的構成モジュールに発行し、リソースの更新が成功したか否かを判断するステップと
を備えた
方法。
【０００７】
本発明によれば、サーバのパフォーマンスを最適化して、当該サーバのパフォーマンス（たとえばサーバはその能力一杯に機能しているのか、あるいは、サーバは利用中なのか）に応じて当該サーバをサーバ・プールから割り振ったり、あるいは割り振りを解除したりすることが可能になるので好都合である。また、モジュール化した自動コンピューティング・コンポーネントを使用することにより、本システムは変動するとともに予測不可能な条件の下で自身を構成および再構成することができる。さらに、本方法によれば、他の従来技術に係るシステムと異なり、サーバを再始動する必要なくハードウェア・リソースまたはデータ・リソースを変更することが可能になる。
【０００８】
本発明は動的コンテンツ・モジュールが動的構成モジュールに第３のサーバ用の接続構成ファイルを要求するステップを備えるのが望ましい。これにより、第１のサーバはクライアントが要求しているリソースを保持しているデータ・ソース・サーバを特定することが可能になる。
【０００９】
本発明は第１のサーバおよび第３のサーバの一方または双方をフリー・サーバ・プールから割り振ったり、その割り振りを解除してフリー・サーバ・リソース・プールに戻したりする調整を行なうステップを備えるのが望ましい。これにより、本発明はサーバのパフォーマンスをモニタすることが可能になるとともに、サーバの作業負荷に応じて余分なリソースを付加したりリソースの割り振りを解除したりすることが可能になる。
【００１０】
本発明は新たなサービスの導入または冗長なサービスの除去を可能にするために、要求されるリソースを第１のサーバから分離するステップを備えるのが望ましい。
【００１１】
別の側面から見ると、本発明はキャパシティ・オンデマンドを容易にするためにサーバを遠隔かつ動的に構成するシステムを提供するものである。そのシステムは次に示すように構成する。
キャパシティ・オンデマンドを容易にするためにサーバを遠隔かつ動的に構成するシステムであって、前記システムは通信ネットワーク中にあるリソースを要求して受領するクライアント装置とともに使用するものであり、
第１のサーバであって、前記第１のサーバは動的コンテンツ・モジュール、動的構成モジュール、および報告モジュールを備え、さらに、
前記リソースを求める前記クライアントの要求を前記動的コンテンツ・モジュールに転送する手段と、
前記動的コンテンツ・モジュールが、前記要求されたリソースの提供元になりうる第３のサーバを特定する手段、および前記動的構成モジュールに格納されている、前記第３のサーバに付随する接続構成ファイルを検索・取得する手段と、
前記報告モジュールが、前記第１のサーバおよび前記第３のサーバが出力するパフォーマンスのデータを照合する手段、および前記パフォーマンスのデータを第２のサーバに転送する手段と
を備えた第１のサーバと、
第２のサーバであって、前記第２のサーバは解析モジュール、リソース割り振りモジュール、およびリソース更新モジュールを備え、前記第２のサーバは前記パフォーマンスのデータを前記解析モジュールに転送し、さらに、
前記解析モジュールが前記第１のサーバおよび前記第３のサーバの目標達成能力を判定する手段、ならびに前記第１のサーバおよび前記第３のサーバが所定の閾値に到達しているか否かを確認する手段と、
前記リソース割り振りモジュールが、確認する前記手段に応答して前記第１のサーバおよび前記第３のサーバの一方または双方の割り振りを調整する手段と、
前記第１のサーバおよび前記第３のサーバの一方または双方の構成を更新する命令を前記第１のサーバの前記動的構成モジュールに発行する手段、および前記第１のサーバおよび前記第３のサーバの一方または双方の割り振りまたは割り振りの解除が成功したか否かを判断する手段と
を備えた第２のサーバと、
第３のサーバであって、前記第３のサーバは少なくとも１つのリソース、および前記第３のサーバが要求されたリソースを前記第１のサーバに提供する手段を備えた第３のサーバと
を備えた
システム。
【００１２】
別の利点はＨＴＴＰ  ＵＲＬをサーバによって処理しうるとともに、サーバを再始動させる必要も手動による介入も必要とすることなく遠隔にあるデータ・ソースに関連付けできる点である。本発明のさらなる利点はデータ・ソースとハードウェア・リソースの動的なプラグ・アンド・プレイの管理を中央において安全に行なうことにより、「オン・ザ・フライ（on the fly) 」状態でウェブ・サイトにサービスを提供できる点である。本発明の別の利点はＦＴＰ、ＸＭＬ、ＳＯＡＰ、およびファイル共用などの別の機構用の複数のプロトコルをサポートしうる点である。
【発明を実施するための最良の形態】
【００１３】
図１は本発明を実装することのできるサーバ・ファームを示す図である。このサーバ・ファームはインターネットのようなネットワーク１１０に接続された複数のクライアント装置１００、１０５を備えている。クライアント装置１００、１０５はネットワーク１１０の向こう側にあるリソースを求める要求を送受信することによりトランザクションを実行する。ルータ１１５、１２０はネットワーク１１０とＬＡＮ（local area network）１２５との間の接続を提供している。ＬＡＮ１２５には高速イーサネット（Ｒ）ネットワークまたは他の任意の好適な伝送媒体すなわち接続形態を用いることができる。ルータ１１５、１２０は入来する要求を受信し、当該要求をネットワーク１３５を介してルータ／ファイアウオール１３０へ転送する。ルータ／ファイアウオール１３０はこの要求をサーバ１４５〜１５５へフィルタリングする。本発明はサーバ１４５〜１５５用の中央制御点用に管理サーバ１４０を実現するものである。サーバ１４５〜１５５は次に例示するものを含む少なくとも１つのサーバ技術によって実装することができる。すなわち、ＵＮＩＸ（Ｒ）（これはアメリカ合衆国および他の国々におけるジ・オープン・グループ（The Open Group) の登録商標である）、Ｎｏｖｅｌｌ（これはアメリカ合衆国および他の国々におけるノベル社（Novell Inc）の登録商標である）、もしくはＷｉｎｄｏｗｓ  ＮＴ（Ｒ）（これはアメリカ合衆国および他の国々におけるマイクロソフト社（Microsoft Corporation)の登録商標である）、および／またはピア・ツー・ピア・ネットワーク構成である。（「Ａおよび／またはＢ」は「ＡおよびＢ、Ａ、またはＢ」を表わす。）以上、本発明をサーバ・ファームを参照して説明したが、本発明はパーベイシブ・コンピューティング環境および他のサーバ・ネットワーキング構成に等しく適用することができる。
【００１４】
アプリケーション・データはサーバ１４０〜１５５から分離している少なくとも１つのデータ・ソース・サーバ１７５、１８０中のデータ・ストアに格納されている。要求はサーバ１４０〜１５５のうちの任意の１つのものがネットワーク１６０をまたいで送信する。この要求はルータ／ファイアウオール１６５が受信した後、後続するネットワーク１７０をまたいで、少なくとも１つのクライアント装置１００、１０５が要求したリソースを格納している適切なデータ・ソース・サーバ１７５、１８０に転送する。
【００１５】
次に図２を参照する。図２は本システムの概略を示す図である。本システムはサーバ１４５〜１５５についてパフォーマンスの課題を検出する自己診断機能を提供するモジュール化自動コンピューティング・コンポーネントを備えている。また、モジュール化コンポーネントを使用することにより、本システムはデータ・ソースを「プラグ・アンド・プレイ（plug and play)」する機能を備え、新たなサービスの導入を容易にしうるようにしている。
【００１６】
本システムは報告モジュール２０５、動的コンテンツ・モジュール２１５、および動的構成モジュール２１６を有するサーバ１４５を備えている。報告モジュール２０５は配置済みのサーバ・プール中の各サーバ１４５〜１５５が出すパフォーマンスと要求データを照合する。動的コンテンツ・モジュール２１５はリソースを求める要求を、要求されたリソースにアクセスするのに最適なインタフェース中に送出する。その際、サーバ１４５〜１５５の固有のデータ・アクセス機能を使用するか、あるいは、遠隔サーバへの接続を自ら確立して管理する。動的構成モジュール２１６は配置済みのサーバ・プール中の各サーバ用、および当該サーバにリソースを要求するクライアント装置１００用に構成ファイルを更新し、処理し、格納する。この構成ファイルは特定のサーバ１４５〜１５５用の構成設定（たとえば登録キー、ポート設定、インストール・パス、認証設定、ユーザ設定、ＳＭＰＴ設定、接続設定、ウェブ・ブラウザ設定、および、これらの設定のログなど）を保持するために使用する。
【００１７】
本システムはさらに管理サーバ１４０、解析モジュール２３０、リソース割り振りモジュール２３５、リソース更新モジュール２４０、および管理クライアント２４５を備えている。管理サーバ１４０は利用可能なサーバ・プール中のすべてのサーバ用に中央制御点を提供する。解析モジュール２３０は報告モジュール２０５が出すパフォーマンスと要求データを解析する。リソース割り振りモジュール２３５はフリー・サーバ・リソース・プール中に、割り振り済みのサーバのプールに付加すべきフリー・リソースがあるか否かを判断する。あるいは、必要な場合にサーバの割り振りを解除し、それをフリー・リソース・サーバ・プールに戻す。リソース更新モジュール２４０はあるリソースが、利用可能なリソース・プールに成功裏に割り振られたか否か、あるいは、それへの割り振りを成功裏に解除されたかを否かを判断する。管理クライアント２４５は構成タスクを手動でシステムに入力するためのものである。管理クライアント２４５はサーバの管理者が出す管理要求を受領することができる。管理クライアントはグラフィカル・ユーザ・インタフェースとして機能するとともに、管理サーバへの接続をきわめて柔軟にしている。たとえば、インターネットが介在する互いに別の場所にあるサーバ１４５〜１５５と管理サーバ１４０との間の遠隔の接続を標準のＨＴＴＰ接続を用いて実現している。許可された管理者のみが構成の変更を行ないうるようにするために、認証要求と資格要求を処理するインタフェースがセキュリティ・ディレクトリに設けられている（図示せず）。
【００１８】
サーバ１４５〜１５５と管理サーバ１４０との間では、ＨＴＴＰセッション上のトランスポート機構２２０、２２５としてＸＭＬ（Extensible Markup Language) を用いてデータ・ストリーム２２０、２２５が送受信されている。ＸＭＬとはウェブ上の構造化ドキュメントとデータ用の汎用フォーマットのことである。ＸＭＬではＨＴＭＬと同様のタグを使用しているから、多くの人々が理解しうる態様でデータを構造化することが可能である。ＸＭＬに関するさらなる情報はワールド・ワイド・ウェブ・コンソーシアム（World Wide Web Consortium)において取得することができる。
【００１９】
クライアント装置１００は特定のリソースを求める要求をサーバ１４５に送信する。サーバ１４５が受信するそのような要求はＨＴＴＰ  ＵＲＬ（たとえばＨＴＭＬページを要求するhttp://www.ibm.com）である。本サーバはＨＴＴＰ  ＵＲＬを変換するために、インターネット・ドメイン名をネットワーク・アドレス（たとえば129.42.19.99）に変換するＤＮＳ（Domain Name Service)を使用する。リソースは標準のＨＴＭＬページまたは実行（.exe）ファイルである可能性が高い。サーバ１４５はクライアント装置１００、１０５が出したリソースを求める要求を受信する。当該要求は動的コンテンツ・モジュール２１５に宛てて送付される。
【００２０】
図２には管理サーバ１４０とサーバ１４５だけを示したが、認識すべき点を挙げると、本システムは図１に示すように複数のサーバ１４５〜１５５を備え、各サーバは図２に示すモジュール群を備えている。
【００２１】
次に図３を参照して、動的コンテンツ・モジュール２１５の動作を説明する。留意点を挙げると、図３において破線はデータの流れを表し、実単線は制御の流れを表している。動的コンテンツ・モジュール２１５はステップ３００において、クライアント装置が出す、リソースを求める要求を受信した後、ステップ３０５においてサーバ１４５に格納されているコンテンツと要求されたリソースとを比較する。たとえば、クライアントが「www.ibm.com/news/today.html 」に対してリソースを要求するものとすると、動的コンテンツ・モジュールは当該サーバに格納されている「today.html」なるページとソース・サーバに格納されている「today.html」ページとを比較し、「today.html」ページが更新されているか否かを判断し、クライアント装置に最新の「today.html」ページを送付する。ステップ３１０において、本サーバはコンテンツがキャッシュされているか否かを判断し、ステップ３６０においてキャッシュ済みのコンテンツが現在かつ最新であるか否かを判断する。キャッシュ済みのコンテンツが現在のものである場合、制御はステップ３３５に進み、要求されたリソースをコンテンツ・キャッシュ・ストア３５０から検索・取得する。同様に、コンテンツがキャッシュされていない場合、ステップ３１５において要求されたリソースを格納しているサーバを特定する。またステップ３５５において、サーバ１４５のアクティビティに関する情報を報告モジュール２０５に送付する。この情報にはリソース（たとえば製品）ごとの要求数、本サーバが応答するのに要した時間、要求されたサービスの種別（たとえばＨＴＴＰ、ＦＴＰ（File Transfer Protocol) など）が含まれる。
【００２２】
サーバ１４５がデータ・ソース・サーバ１７５を特定しうるようにするために、本サーバはステップ３２５において接続構成ストア３２０からデータ・ソース・サーバ１７５用の接続構成ファイルを検索・取得する。次いでステップ３３０において、コンテンツ要求について事前処理を実行する。次いでステップ３３５において、データ・ソース・サーバ１７５に宛てて要求を発行する。次いでステップ３４０において、サーバ１４５はクライアント装置３００が要求したコンテンツをソース・サーバから受領する。検索・取得したコンテンツはコンテンツ・キャッシュ・データ・ストア３５０にそのまま格納するか、あるいはステップ３４５において、当該検索・取得したコンテンツを用いて既存のコンテンツをリフレッシュした後、コンテンツ・キャッシュ・データ・ストア３５０に格納する。
【００２３】
ステップ３５５の参照に戻る。ステップ３００においてクライアント装置１００が要求したリソースに関する情報はパフォーマンスの情報とともに報告モジュール２１０に送付する。次に図４を参照する。報告モジュール２０５は動的コンテンツ・モジュール２１５からコンテンツ情報を受領した後、ステップ４００において当該情報を記録する。これらの詳細はステップ４０５においてサーバ統計データ・ストアに格納する。各サーバ１４５〜１５５に付随するサーバ統計（応答時間、要求されたページ数、回数、特定ページ情報、特定サーバ情報、サーバ構成の詳細、およびパフォーマンス・データ）はステップ４１０においてＸＭＬデータ・ストリーム２２０に乗せて管理サーバ１４０に送付する。
【００２４】
次に図５を参照する。管理サーバ１４０の解析モジュール２３０はＸＭＬデータ・ストリーム２２０中のサーバ統計を受領し、ステップ５００において当該サーバ統計を解析し、ステップ５０５においてサーバ１４５〜１５５が所定の閾値（しきいち、いきち）に到達しているか否かを判断する。当該サーバのパフォーマンスが所定の閾値に到達していない場合、制御はステップ５００に戻る。そうでない場合、制御はステップ５１０に進む。解析モジュール２３０はサーバの現在の構成設定を解析した後、当該サーバの構成設定をリソース割り振りモジュール２３５に送付する。
【００２５】
次に図６を参照する。パフォーマンスが閾値を超過している場合、あるいは、割り振り済みのサーバの現在のプールからサーバを１つ除去してフリー・リソース・プールに戻す必要のある場合、リソース割り振りモジュール２３５は割り振り済みのサーバ１４５〜１５５の現在のプールに新たなサーバを付加すべきか否かを判断する。解析モジュール２３０が余分のサーバを追加すべきであると判断した場合、制御はステップ６０５に進む。次いで、リソース割り振りモジュールはステップ６１０において予備のリソースが存在するか否かを判断する。予備のリソースとしては、たとえば追加のサーバなどのハードウェア・リソースを挙げることができる。予備のリソースを割り振ることができない場合、制御はステップ６３０に進み、ステップ６３５において例外エラーを生成して管理コンソール２４５に表示し、ステップ６３５においてリソースの更新は失敗した旨を技術要員に警告する。次にステップ６１０の参照に戻る。予備のリソースが割り振り済みである場合、制御はステップ６１５に進み、新たなサーバを選定する。そして、当該サーバの構成設定ファイルに関する情報を特定のサーバ１４０〜１５５の構成データベース６１５に要求する。ステップ６２０において当該構成設定ファイルを受領したら、選定したサーバ用の現在の命令を用いて当該構成設定ファイルを更新し、リソース更新モジュール２４０と動的構成モジュール２１６にＸＭＬデータ・ストリーム２２５を通じて送付する。
【００２６】
次に図７を参照する。ステップ７００においてサーバ１４５の動的構成モジュール２１６に宛ててＸＭＬデータ・ストリーム２２５を通じて構成更新情報を発行する。リソース更新モジュール２４０はステップ７１０において、サーバ１４５が出す確認応答を待ち受ける。ステップ７１５において構成の更新が成功した場合、制御はステップ７２０に進み、構成データベース７３０を更新する。ステップ７２０の参照に戻る。サーバ１４５が出す確認応答が成功した場合にも、制御はステップ７３５に進み、負荷を均衡化させる基盤整備を求める構成更新要求を要求する。同様に、ステップ７２０において構成の更新が成功しなかった場合、制御はステップ７４５に進み、例外処理の警告を生成する。そして、ステップ７５０において、リソースの更新は失敗したものとみなす。
【図面の簡単な説明】
【００２７】
【図１】本発明の好適な実施形態に従い本発明を実装することのできるサーバ・ファームを示す図である。
【図２】本発明の好適な実施形態に従い本システムのコンポーネント群の概要を示すブロック図である。
【図３】本発明の好適な実施形態に従い図２のウェブ・サーバの動的コンテンツ・モジュールの機能を示すフローチャートを示す図である。
【図４】本発明の好適な実施形態に従い図２のウェブ・サーバの報告モジュールの機能を示すフローチャートを示す図である。
【図５】本発明の好適な実施形態に従い図２の管理サーバの解析モジュールの機能を示すフローチャートを示す図である。
【図６】本発明の好適な実施形態に従い図２の管理サーバのリソース割り振りモジュールの機能を示すフローチャートを示す図である。
【図７】本発明の好適な実施形態に従い図２の管理サーバのリソース更新モジュールの機能を示すフローチャートを示す図である。
【符号の説明】
【００２８】
１００  クライアント装置
１０５  クライアント装置
１１０  ネットワーク
１１５  ルータ
１２０  ルータ
１２５  ＬＡＮ
１３０  ルータ／ファイアウオール
１３５  ネットワーク
１４０  管理サーバ
１４５  サーバ
１５０  サーバ
１５０  サーバ
１６０  ネットワーク
１６５  ルータ／ファイアウオール
１７０  ネットワーク
１７５  データ・ソース・サーバ
１８０  データ・ソース・サーバ
【図１】
2005539298.tif 000003
【図２】
2005539298.tif 000004
【図３】
2005539298.tif 000005
【図４】
2005539298.tif 000006
【図５】
2005539298.tif 000007
【図６】
2005539298.tif 000008
【図７】
2005539298.tif 000009
【手続補正書】
【提出日】平成16年4月8日(2004.4.8)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
サーバのキャパシティ・オンデマンドを実現するためにサーバ（１４５、１５、１５５）を遠隔かつ動的に構成する方法であって、
（ａ）第１のサーバ（１４５）が、リソースを求める要求をクライアント装置（１００）から受領するステップと、
（ｂ）前記リソースを求める前記クライアントの前記要求を動的コンテンツ・モジュール（２１５）に転送するステップであって、前記動的コンテンツ・モジュール（２１５）は要求された前記リソースの提供元になりうるとともに利用可能な第３のサーバ（１５０）を特定し、要求された前記リソースを前記クライアント装置（１００）に送付する、ステップと、
（ｃ）前記第１のサーバ（１４５）および前記第３のサーバ（１５０）が出力するパフォーマンスのデータを照合し、前記第１のサーバが前記パフォーマンスのデータを第２のサーバに転送するステップと、
（ｄ）受領した、ステップ（ｃ）において照合した前記パフォーマンスのデータを解析して前記第１のサーバおよび前記第３のサーバ（１５０）のパフォーマンス能力を判定し、前記第１のサーバまたは前記第３のサーバが所定の閾値に到達しているか否かを確認するステップと、
（ｅ）前記第２のサーバが、ステップ（ｄ）に応答して前記第１のサーバ（１４５）または前記第３のサーバ（１５０）のリソースの割り振りを調整し、前記第１のサーバ（１４５）または前記第３のサーバ（１５０）の構成を更新する命令を動的構成モジュール（２１６）に発行し、リソースの更新が成功したか否かを判断するステップと
を備えた
方法。
【請求項２】
さらに、
前記動的コンテンツ・モジュール（２１５）が前記第３のサーバ用の接続構成ファイルを前記動的構成モジュール（２１６）に要求するステップを備えた、
請求項１に記載の方法。
【請求項３】
前記動的構成モジュール（２１６）が前記第１のサーバ（１４５）および前記第３のサーバ（１５０）の一方または双方用の構成設定を格納する、
請求項１に記載の方法。
【請求項４】
前記第１のサーバ（１４５）および前記第３のサーバ（１５０）の一方または双方の割り振りを調整する前記ステップがさらに、フリー・サーバ・リソース・プールから追加のサーバを割り振るステップを備えている、
請求項１に記載の方法。
【請求項５】
前記第１のサーバ（１４５）および前記第３のサーバ（１５０）の一方または双方の割り振りを調整する前記ステップがさらに、前記第１のサーバ（１４５）および前記第３のサーバ（１５０）の一方または双方の割り振りを解除して割り振り済みリソース・プールからフリー・サーバ・リソース・プールに戻すステップを備えている、
請求項１に記載の方法。
【請求項６】
前記第１のサーバ（１４５）および前記第２ののサーバ（１４０）がＸＭＬデータ・ストリームを通じて互いに通信する、
請求項１または２に記載の方法。
【請求項７】
前記第２のサーバ（１４０）が、少なくとも１つの第１のサーバ（１４５）および少なくとも１つの第３のサーバ（１５０）用に中央制御点を提供する管理サーバである、
請求項１に記載の方法。
【請求項８】
要求される前記リソースを前記第１のサーバ（１４０）から分離して新たなサービスの導入または冗長なサービスの除去を可能にする、
請求項１に記載の方法。
【請求項９】
前記第１のサーバ（１４５）が複数のサーバである、
請求項１に記載の方法。
【請求項１０】
前記第３のサーバ（１５０）が複数のサーバである、
請求項１に記載の方法。
【請求項１１】
サーバのキャパシティ・オンデマンドを実現するためにサーバを遠隔かつ動的に構成するシステムであって、前記システムは通信ネットワーク中にあるリソースを要求して受領するクライアント装置とともに使用するものであり、
第１のサーバ（１４５）であって、前記第１のサーバ（１４５）は動的コンテンツ・モジュール（２１５）、動的構成モジュール（２１６）、および報告モジュール（２０５）を備え、さらに、
前記リソースを求める前記クライアントの要求を前記動的コンテンツ・モジュール（２１５）に転送する手段と、
前記動的コンテンツ・モジュール（２１５）が、前記要求されたリソースの提供元になりうる第３のサーバ（１５０）を特定する手段、および前記動的構成モジュールに格納されている、前記第３のサーバ（１５０）に付随する接続構成ファイルを検索・取得する手段と、
前記報告モジュール（２０５）が、前記第１のサーバ（１４５）および前記第３のサーバ（１５０）が出力するパフォーマンスのデータを照合する手段、および前記パフォーマンスのデータを第２のサーバ（１４０）に転送する手段と
を備えた第１のサーバ（１４５）と、
第２のサーバ（１４０）であって、前記第２のサーバ（１４０）は解析モジュール（２３０）、リソース割り振りモジュール（２３５）、およびリソース更新モジュール（２４０）を備え、前記第２のサーバ（１４０）は前記パフォーマンスのデータを前記解析モジュール（２３０９に転送し、さらに、
前記解析モジュール（２３０）が前記第１のサーバ（１４５）および前記第３のサーバ（１５０）のパフォーマンス能力を判定する手段、ならびに前記第１のサーバ（１４５）および前記第３のサーバ（１５０）が所定の閾値に到達しているか否かを確認する手段と、
前記リソース割り振りモジュール（２３５）が、確認する前記手段に応答して前記第１のサーバ（１４５）および前記第３のサーバ（１５０）の一方または双方の割り振りを調整する手段と、
前記第１のサーバ（１４５）および前記第３のサーバ（１５０）の一方または双方の構成を更新する命令を前記第１のサーバ（１４５）の前記動的構成モジュール（２１６）に発行する手段、および前記第１のサーバ（１４５）および前記第３のサーバ（１５０）の一方または双方の割り振りまたは割り振りの解除が成功したか否かを判断する手段と
を備えた第２のサーバ（１４０）と、
第３のサーバ（１５０）であって、前記第３のサーバ（１５０）は少なくとも１つのリソース、および前記第３のサーバ（１５０）が要求されたリソースを前記第１のサーバ（１４５）に提供する手段を備えた第３のサーバ（１５０）と
を備えた
システム。
【請求項１２】
前記第１のサーバ（１４５）および前記第３のサーバ（１５０）の一方または双方の割り振りを調整する前記手段が、さらに、追加のサーバをフリー・サーバ・リソース・プールから割り振る手段を備えている、
請求項１１に記載のシステム。
【請求項１３】
前記第１のサーバ（１４５）または前記第３のサーバ（１５０）の割り振りを調整する手段が、さらに、前記第１のサーバ（１４５）および前記第３のサーバ（１５０）の一方または双方の割り振りを解除して割り振り済みリソース・プールからフリー・サーバ・リソース・プールに戻す手段を備えている、
請求項１１に記載のシステム。
【請求項１４】
前記第１のサーバ（１４５）と前記第２のサーバ（１４０）との間の通信を行なう手段がＸＭＬデータ・ストリームによるものである、
請求項１１に記載のシステム。
【請求項１５】
前記接続構成ファイルが前記第１のサーバ（１４５）および前記第３のサーバ（１５０）用の接続設定を含んでいる、
請求項１１に記載のシステム。
【請求項１６】
前記動的構成モジュール（２１６）が、第１のサーバ（１４５）および第３のサーバ（１５０）用の構成設定を格納する手段を備えている、
請求項１１に記載のシステム。
【請求項１７】
前記第２のサーバ（１４０）が、前記第１のサーバおよび前記第３のサーバ（１５０）用の中央制御点用の手段を備えた管理サーバである、
請求項１１に記載のシステム。
【請求項１８】
要求される前記リソースが、新たなサービスを導入しうるように、または冗長なサービスを除去しうるように前記第１のサーバ（１４５）から分離されている、
請求項１１に記載のシステム。
【請求項１９】
前記第１のサーバ（１４５）が複数のサーバである、
請求項１１に記載のシステム。
【請求項２０】
前記第３のサーバ（１５０）が複数のサーバである、
請求項１１に記載のシステム。
【請求項２１】
コンピュータ読み取り可能な記憶媒体に格納されたコンピュータ・プログラム・コードであって、データ処理システムで実行すると、当該データ処理システムに請求項１に記載の方法を実行させるコンピュータ・プログラム・コードを含むコンピュータ・プログラム製品。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はネットワーク・サービスの分野に関し、特にサーバのキャパシティ・オンデマンド（capacity on demand）を実現するためにサーバを遠隔かつ動的に構成する方法に関する。
【背景技術】
【０００２】
多くの会社が様々なアプリケーションをホストしうる安全かつ頑健かつ柔軟なインフラストラクチャを提供するホスティング・サービスを顧客に提案している。上記アプリケーションとしては、たとえばウェブ・アプリケーションが挙げられる。このウェブ・アプリケーションには、たとえばオンライン・バンキング、オンライン・ショッピング、情報サービス、ホスティング・サービスなどが含まれる。ホスティング・サービスとは顧客に自分が使用した処理能力の分だけ支払うことを可能にするものであり、たとえば「使用した分だけ支払う機能（pay for used capacity)」が挙げられる。この「使用した分だけ支払う機能」により、顧客は最新の機器を対費用効果の高い態様で配備することが可能になる。ホスティング・サービスは多くの会社（business）に、自社の技術インフラストラクチャを社内に構築して運用することに対する代替ソリューションを提供するものである。その際、ソフトウェア・アプリケーションとハードウェア・リソース（たとえばサーバ）を管理するために他社のデータ・センタにあるコンピュータ・システムを活用する。これらのサーバとサービスを管理し監督することは多くのホスティング会社にとって解決すべき大きな課題である。というのは、サーバ・ファームのような環境にあるサーバを管理し監督することに付随する主要な問題点は、自身が生成し続けるデータに関してサーバが果たす役割の定義に起因してサーバのインフラストラクチャとアーキテクチャが厳格であるという点だからである。
【０００３】
たとえば特定の顧客の製品をサポートしているウェブ・サーバにリソースを厳格に割り当てると、能力の限界まで使用されておらず利用されているのだが高価すぎるウェブ・サーバのリソースが存在することになる一方、他の製品をサポートしている他のサーバは能力の限界まで酷使されるということになる可能性がある。また、今日の最新のウェブ・サーバ・ソフトウェアは複雑であるが柔軟であり、ＡＰＩ（Application Protocol Interface）を使用することにより基本的なＨＴＭＬ（Hypertext Markup Language)ページを提供する標準的なサービスを超えた強力な処理を容易にするように構成し拡張することができる。しかし、現在の配備の実務と技術では、ウェブ・サーバは構成ファイルまたはバイナリ・レジストリを用いて手動で構成する必要があるから、動作中は静的に保って特定のウェブサイト（またはウェブサイト群）に対する要求を処理する必要がある。また、特定のＨＴＭＬページ用の追加もしくは別のリソース、または、別のウェブ・サイトのＵＲＬを生成する必要がある場合、あるいは、サーバ・プールに新たなサーバを脱着する必要が生じた場合、変更を有効にするにはサーバを再起動しなければならない。この結果、サーバ・ファームの管理者側には多大な管理努力が必要になる。というのは、サーバを手動で構成するには多大な時間がかかるとともに、サーバをシャットダウンしたのち変更を有効にするためにサーバを再起動すると、ある期間、サービスの欠落を招く可能性があるので、これが常に好都合であるとは限らないからである。
【０００４】
米国特許出願公報（US patent application publication)第ＵＳ２００２／０００２６０２号（２６０２）には協働する複数のウェブ・サーバが出力するウェブ・ページを組織的な態様で提供することを目的とするリソースを指定しているクライアントの要求に応答してウェブ・ページをクライアントに提供するとともに信頼性の高い接続を維持し、サーバとクライアントが同期状態を維持して情報が失われないようにしたシステムが記載されている。
米国特許出願公報第ＵＳ２００２／００２６１１号（Ａ１）には、少なくとも１つのネットワーク接続されたクライアント・コンピュータにネットワーク接続された複数のサーバによってネットワーク機能を実現するシステムが開示されている。
国際公開特許明細書第ＷＯ００／６２５０２号にはネットワークのトラフィックを制御する分散型サーバ・クラスタが開示されている。
【特許文献１】米国特許出願公報第ＵＳ２００２／０００２６０２号
【特許文献１】米国特許出願公報第ＵＳ２００２／００２６１１号
【特許文献１】国際公開特許明細書第ＷＯ００／６２５０２号
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、米国特許出願公報第ＵＳ２００２／０００２６０２号に記載された事項を実行してウェブ・サーバがＵＲＬを処理し当該ＵＲＬをデータ・ソースに関連付けうるようにするためには、人手によってウェブ・サーバに介入する必要があるとともに、変更を有効にするためにウェブ・サーバをシャットダウンして再起動しなければならない。
また、米国特許出願第公報ＵＳ２００２／００２６１１号は事前構成のフロント・エンド・サーバを実現するために、プロキシ／キャッシング・サービスの機能を強化することに関するものである。
さらに、国際公開特許明細書第ＷＯ００／６２５０２号はサーバが故障したことを検出したら、ネットワークのトラフィックを故障したマシンから少なくとも１つの稼働中のマシンに自動的に切り換える負荷均衡化システムに関するものである。
【課題を解決するための手段】
【０００６】
第１の側面から見ると、本発明は次に示す方法を提供するものである。
サーバのキャパシティ・オンデマンドを実現するためにサーバ（１４５、１５、１５５）を遠隔かつ動的に構成する方法であって、
（ａ）第１のサーバ（１４５）が、リソースを求める要求をクライアント装置（１００）から受領するステップと、
（ｂ）前記リソースを求める前記クライアントの前記要求を動的コンテンツ・モジュール（２１５）に転送するステップであって、前記動的コンテンツ・モジュール（２１５）は要求された前記リソースの提供元になりうるとともに利用可能な第３のサーバ（１５０）を特定し、要求された前記リソースを前記クライアント装置（１００）に送付する、ステップと、
（ｃ）前記第１のサーバ（１４５）および前記第３のサーバ（１５０）が出力するパフォーマンスのデータを照合し、前記第１のサーバが前記パフォーマンスのデータを第２のサーバに転送するステップと、
（ｄ）受領した、ステップ（ｃ）において照合した前記パフォーマンスのデータを解析して前記第１のサーバおよび前記第３のサーバ（１５０）のパフォーマンス能力を判定し、前記第１のサーバまたは前記第３のサーバが所定の閾値に到達しているか否かを確認するステップと、
（ｅ）前記第２のサーバが、ステップ（ｄ）に応答して前記第１のサーバ（１４５）または前記第３のサーバ（１５０）のリソースの割り振りを調整し、前記第１のサーバ（１４５）または前記第３のサーバ（１５０）の構成を更新する命令を動的構成モジュール（２１６）に発行し、リソースの更新が成功したか否かを判断するステップと
を備えた
方法。
【０００７】
本発明によれば、サーバのパフォーマンスを最適化して、当該サーバのパフォーマンス（たとえばサーバはその能力一杯に機能しているのか、あるいは、サーバは利用中なのか）に応じて当該サーバをサーバ・プールから割り振ったり、あるいは割り振りを解除したりすることが可能になるので好都合である。また、モジュール化した自動コンピューティング・コンポーネントを使用することにより、本システムは変動するとともに予測不可能な条件の下で自身を構成および再構成することができる。さらに、本方法によれば、他の従来技術に係るシステムと異なり、サーバを再始動する必要なくハードウェア・リソースまたはデータ・リソースを変更することが可能になる。
【０００８】
本発明は動的コンテンツ・モジュールが動的構成モジュールに第３のサーバ用の接続構成ファイルを要求するステップを備えるのが望ましい。これにより、第１のサーバはクライアントが要求しているリソースを保持しているデータ・ソース・サーバを特定することが可能になる。
【０００９】
本発明は第１のサーバおよび第３のサーバの一方または双方をフリー・サーバ・プールから割り振ったり、その割り振りを解除してフリー・サーバ・リソース・プールに戻したりする調整を行なうステップを備えるのが望ましい。これにより、本発明はサーバのパフォーマンスをモニタすることが可能になるとともに、サーバの作業負荷に応じて余分なリソースを付加したりリソースの割り振りを解除したりすることが可能になる。
【００１０】
本発明は新たなサービスの導入または冗長なサービスの除去を可能にするために、要求されるリソースを第１のサーバから分離するステップを備えるのが望ましい。
【００１１】
別の側面から見ると、本発明はキャパシティ・オンデマンドを実現するためにサーバを遠隔かつ動的に構成するシステムを提供するものである。そのシステムは次に示すように構成する。
キャパシティ・オンデマンドを容易にするためにサーバを遠隔かつ動的に構成するシステムであって、前記システムは通信ネットワーク中にあるリソースを要求して受領するクライアント装置とともに使用するものであり、
第１のサーバであって、前記第１のサーバは動的コンテンツ・モジュール、動的構成モジュール、および報告モジュールを備え、さらに、
前記リソースを求める前記クライアントの要求を前記動的コンテンツ・モジュールに転送する手段と、
前記動的コンテンツ・モジュールが、前記要求されたリソースの提供元になりうる第３のサーバを特定する手段、および前記動的構成モジュールに格納されている、前記第３のサーバに付随する接続構成ファイルを検索・取得する手段と、
前記報告モジュールが、前記第１のサーバおよび前記第３のサーバが出力するパフォーマンスのデータを照合する手段、および前記パフォーマンスのデータを第２のサーバに転送する手段と
を備えた第１のサーバと、
第２のサーバであって、前記第２のサーバは解析モジュール、リソース割り振りモジュール、およびリソース更新モジュールを備え、前記第２のサーバは前記パフォーマンスのデータを前記解析モジュールに転送し、さらに、
前記解析モジュールが前記第１のサーバおよび前記第３のサーバの目標達成能力を判定する手段、ならびに前記第１のサーバおよび前記第３のサーバが所定の閾値に到達しているか否かを確認する手段と、
前記リソース割り振りモジュールが、確認する前記手段に応答して前記第１のサーバおよび前記第３のサーバの一方または双方の割り振りを調整する手段と、
前記第１のサーバおよび前記第３のサーバの一方または双方の構成を更新する命令を前記第１のサーバの前記動的構成モジュールに発行する手段、および前記第１のサーバおよび前記第３のサーバの一方または双方の割り振りまたは割り振りの解除が成功したか否かを判断する手段と
を備えた第２のサーバと、
第３のサーバであって、前記第３のサーバは少なくとも１つのリソース、および前記第３のサーバが要求されたリソースを前記第１のサーバに提供する手段を備えた第３のサーバと
を備えた
システム。
【００１２】
別の利点はＨＴＴＰ  ＵＲＬをサーバによって処理しうるとともに、サーバを再始動させる必要も手動による介入も必要とすることなく遠隔にあるデータ・ソースに関連付けできる点である。本発明のさらなる利点はデータ・ソースとハードウェア・リソースの動的なプラグ・アンド・プレイの管理を中央において安全に行なうことにより、「オン・ザ・フライ（on the fly) 」状態でウェブ・サイトにサービスを提供できる点である。本発明の別の利点はＦＴＰ、ＸＭＬ、ＳＯＡＰ、およびファイル共用などの別の機構用の複数のプロトコルをサポートしうる点である。
【発明を実施するための最良の形態】
【００１３】
図１は本発明を実装することのできるサーバ・ファームを示す図である。このサーバ・ファームはインターネットのようなネットワーク１１０に接続された複数のクライアント装置１００、１０５を備えている。クライアント装置１００、１０５はネットワーク１１０の向こう側にあるリソースを求める要求を送受信することによりトランザクションを実行する。ルータ１１５、１２０はネットワーク１１０とＬＡＮ（local area network）１２５との間の接続を提供している。ＬＡＮ１２５には高速イーサネット（Ｒ）ネットワークまたは他の任意の好適な伝送媒体すなわち接続形態を用いることができる。ルータ１１５、１２０は入来する要求を受信し、当該要求をネットワーク１３５を介してルータ／ファイアウオール１３０へ転送する。ルータ／ファイアウオール１３０はこの要求をサーバ１４５〜１５５へフィルタリングする。本発明はサーバ１４５〜１５５用の中央制御点用に管理サーバ１４０を実現するものである。サーバ１４５〜１５５は次に例示するものを含む少なくとも１つのサーバ技術によって実装することができる。すなわち、ＵＮＩＸ（Ｒ）（これはアメリカ合衆国および他の国々におけるジ・オープン・グループ（The Open Group) の登録商標である）、Ｎｏｖｅｌｌ（これはアメリカ合衆国および他の国々におけるノベル社（Novell Inc）の登録商標である）、もしくはＷｉｎｄｏｗｓ  ＮＴ（Ｒ）（これはアメリカ合衆国および他の国々におけるマイクロソフト社（Microsoft Corporation)の登録商標である）、および／またはピア・ツー・ピア・ネットワーク構成である。（「Ａおよび／またはＢ」は「ＡおよびＢ、Ａ、またはＢ」を表わす。）以上、本発明をサーバ・ファームを参照して説明したが、本発明はパーベイシブ・コンピューティング環境および他のサーバ・ネットワーキング構成に等しく適用することができる。
【００１４】
アプリケーション・データはサーバ１４０〜１５５から分離している少なくとも１つのデータ・ソース・サーバ１７５、１８０中のデータ・ストアに格納されている。要求はサーバ１４０〜１５５のうちの任意の１つのものがネットワーク１６０をまたいで送信する。この要求はルータ／ファイアウオール１６５が受信した後、後続するネットワーク１７０をまたいで、少なくとも１つのクライアント装置１００、１０５が要求したリソースを格納している適切なデータ・ソース・サーバ１７５、１８０に転送する。
【００１５】
次に図２を参照する。図２は本システムの概略を示す図である。本システムはサーバ１４５〜１５５についてパフォーマンスの課題を検出する自己診断機能を提供するモジュール化自動コンピューティング・コンポーネントを備えている。また、モジュール化コンポーネントを使用することにより、本システムはデータ・ソースを「プラグ・アンド・プレイ（plug and play)」する機能を備え、新たなサービスの導入を容易にしうるようにしている。
【００１６】
本システムは報告モジュール２０５、動的コンテンツ・モジュール２１５、および動的構成モジュール２１６を有するサーバ１４５を備えている。報告モジュール２０５は配置済みのサーバ・プール中の各サーバ１４５〜１５５が出すパフォーマンスと要求データを照合する。動的コンテンツ・モジュール２１５はリソースを求める要求を、要求されたリソースにアクセスするのに最適なインタフェース中に送出する。その際、サーバ１４５〜１５５の固有のデータ・アクセス機能を使用するか、あるいは、遠隔サーバへの接続を自ら確立して管理する。動的構成モジュール２１６は配置済みのサーバ・プール中の各サーバ用、および当該サーバにリソースを要求するクライアント装置１００用に構成ファイルを更新し、処理し、格納する。この構成ファイルは特定のサーバ１４５〜１５５用の構成設定（たとえば登録キー、ポート設定、インストール・パス、認証設定、ユーザ設定、ＳＭＰＴ設定、接続設定、ウェブ・ブラウザ設定、および、これらの設定のログなど）を保持するために使用する。
【００１７】
本システムはさらに管理サーバ１４０、解析モジュール２３０、リソース割り振りモジュール２３５、リソース更新モジュール２４０、および管理クライアント２４５を備えている。管理サーバ１４０は利用可能なサーバ・プール中のすべてのサーバ用に中央制御点を提供する。解析モジュール２３０は報告モジュール２０５が出すパフォーマンスと要求データを解析する。リソース割り振りモジュール２３５はフリー・サーバ・リソース・プール中に、割り振り済みのサーバのプールに付加すべきフリー・リソースがあるか否かを判断する。あるいは、必要な場合にサーバの割り振りを解除し、それをフリー・リソース・サーバ・プールに戻す。リソース更新モジュール２４０はあるリソースが、利用可能なリソース・プールに成功裏に割り振られたか否か、あるいは、それへの割り振りを成功裏に解除されたかを否かを判断する。管理クライアント２４５は構成タスクを手動でシステムに入力するためのものである。管理クライアント２４５はサーバの管理者が出す管理要求を受領することができる。管理クライアントはグラフィカル・ユーザ・インタフェースとして機能するとともに、管理サーバへの接続をきわめて柔軟にしている。たとえば、インターネットが介在する互いに別の場所にあるサーバ１４５〜１５５と管理サーバ１４０との間の遠隔の接続を標準のＨＴＴＰ接続を用いて実現している。許可された管理者のみが構成の変更を行ないうるようにするために、認証要求と資格要求を処理するインタフェースがセキュリティ・ディレクトリに設けられている（図示せず）。
【００１８】
サーバ１４５〜１５５と管理サーバ１４０との間では、ＨＴＴＰセッション上のトランスポート機構２２０、２２５としてＸＭＬ（Extensible Markup Language) を用いてデータ・ストリーム２２０、２２５が送受信されている。ＸＭＬとはウェブ上の構造化ドキュメントとデータ用の汎用フォーマットのことである。ＸＭＬではＨＴＭＬと同様のタグを使用しているから、多くの人々が理解しうる態様でデータを構造化することが可能である。ＸＭＬに関するさらなる情報はワールド・ワイド・ウェブ・コンソーシアム（World Wide Web Consortium)において取得することができる。
【００１９】
クライアント装置１００は特定のリソースを求める要求をサーバ１４５に送信する。サーバ１４５が受信するそのような要求はＨＴＴＰ  ＵＲＬ（たとえばＨＴＭＬページを要求するhttp://www.ibm.com）である。本サーバはＨＴＴＰ  ＵＲＬを変換するために、インターネット・ドメイン名をネットワーク・アドレス（たとえば129.42.19.99）に変換するＤＮＳ（Domain Name Service)を使用する。リソースは標準のＨＴＭＬページまたは実行（.exe）ファイルである可能性が高い。サーバ１４５はクライアント装置１００、１０５が出したリソースを求める要求を受信する。当該要求は動的コンテンツ・モジュール２１５に宛てて送付される。
【００２０】
図２には管理サーバ１４０とサーバ１４５だけを示したが、認識すべき点を挙げると、本システムは図１に示すように複数のサーバ１４５〜１５５を備え、各サーバは図２に示すモジュール群を備えている。
【００２１】
次に図３を参照して、動的コンテンツ・モジュール２１５の動作を説明する。留意点を挙げると、図３において破線はデータの流れを表し、実単線は制御の流れを表している。動的コンテンツ・モジュール２１５はステップ３００において、クライアント装置が出す、リソースを求める要求を受信した後、ステップ３０５においてサーバ１４５に格納されているコンテンツと要求されたリソースとを比較する。たとえば、クライアントが「www.ibm.com/news/today.html 」に対してリソースを要求するものとすると、動的コンテンツ・モジュールは当該サーバに格納されている「today.html」なるページとソース・サーバに格納されている「today.html」ページとを比較し、「today.html」ページが更新されているか否かを判断し、クライアント装置に最新の「today.html」ページを送付する。ステップ３１０において、本サーバはコンテンツがキャッシュされているか否かを判断し、ステップ３６０においてキャッシュ済みのコンテンツが現在かつ最新であるか否かを判断する。キャッシュ済みのコンテンツが現在のものである場合、制御はステップ３３５に進み、要求されたリソースをコンテンツ・キャッシュ・ストア３５０から検索・取得する。同様に、コンテンツがキャッシュされていない場合、ステップ３１５において要求されたリソースを格納しているサーバを特定する。またステップ３５５において、サーバ１４５のアクティビティに関する情報を報告モジュール２０５に送付する。この情報にはリソース（たとえば製品）ごとの要求数、本サーバが応答するのに要した時間、要求されたサービスの種別（たとえばＨＴＴＰ、ＦＴＰ（File Transfer Protocol) など）が含まれる。
【００２２】
サーバ１４５がデータ・ソース・サーバ１７５を特定しうるようにするために、本サーバはステップ３２５において接続構成ストア３２０からデータ・ソース・サーバ１７５用の接続構成ファイルを検索・取得する。次いでステップ３３０において、コンテンツ要求について事前処理を実行する。次いでステップ３３５において、データ・ソース・サーバ１７５に宛てて要求を発行する。次いでステップ３４０において、サーバ１４５はクライアント装置３００が要求したコンテンツをソース・サーバから受領する。検索・取得したコンテンツはコンテンツ・キャッシュ・データ・ストア３５０にそのまま格納するか、あるいはステップ３４５において、当該検索・取得したコンテンツを用いて既存のコンテンツをリフレッシュした後、コンテンツ・キャッシュ・データ・ストア３５０に格納する。
【００２３】
ステップ３５５の参照に戻る。ステップ３００においてクライアント装置１００が要求したリソースに関する情報はパフォーマンスの情報とともに報告モジュール２１０に送付する。次に図４を参照する。報告モジュール２０５は動的コンテンツ・モジュール２１５からコンテンツ情報を受領した後、ステップ４００において当該情報を記録する。これらの詳細はステップ４０５においてサーバ統計データ・ストアに格納する。各サーバ１４５〜１５５に付随するサーバ統計（応答時間、要求されたページ数、回数、特定ページ情報、特定サーバ情報、サーバ構成の詳細、およびパフォーマンス・データ）はステップ４１０においてＸＭＬデータ・ストリーム２２０に乗せて管理サーバ１４０に送付する。
【００２４】
次に図５を参照する。管理サーバ１４０の解析モジュール２３０はＸＭＬデータ・ストリーム２２０中のサーバ統計を受領し、ステップ５００において当該サーバ統計を解析し、ステップ５０５においてサーバ１４５〜１５５が所定の閾値（しきいち、いきち）に到達しているか否かを判断する。当該サーバのパフォーマンスが所定の閾値に到達していない場合、制御はステップ５００に戻る。そうでない場合、制御はステップ５１０に進む。解析モジュール２３０はサーバの現在の構成設定を解析した後、当該サーバの構成設定をリソース割り振りモジュール２３５に送付する。
【００２５】
次に図６を参照する。パフォーマンスが閾値を超過している場合、あるいは、割り振り済みのサーバの現在のプールからサーバを１つ除去してフリー・リソース・プールに戻す必要のある場合、リソース割り振りモジュール２３５は割り振り済みのサーバ１４５〜１５５の現在のプールに新たなサーバを付加すべきか否かを判断する。解析モジュール２３０が余分のサーバを追加すべきであると判断した場合、制御はステップ６０５に進む。次いで、リソース割り振りモジュールはステップ６１０において予備のリソースが存在するか否かを判断する。予備のリソースとしては、たとえば追加のサーバなどのハードウェア・リソースを挙げることができる。予備のリソースを割り振ることができない場合、制御はステップ６３０に進み、ステップ６３５において例外エラーを生成して管理コンソール２４５に表示し、ステップ６３５においてリソースの更新は失敗した旨を技術要員に警告する。次にステップ６１０の参照に戻る。予備のリソースが割り振り済みである場合、制御はステップ６１５に進み、新たなサーバを選定する。そして、当該サーバの構成設定ファイルに関する情報を特定のサーバ１４０〜１５５の構成データベース６１５に要求する。ステップ６２０において当該構成設定ファイルを受領したら、選定したサーバ用の現在の命令を用いて当該構成設定ファイルを更新し、リソース更新モジュール２４０と動的構成モジュール２１６にＸＭＬデータ・ストリーム２２５を通じて送付する。
【００２６】
次に図７を参照する。ステップ７００においてサーバ１４５の動的構成モジュール２１６に宛ててＸＭＬデータ・ストリーム２２５を通じて構成更新情報を発行する。リソース更新モジュール２４０はステップ７１０において、サーバ１４５が出す確認応答を待ち受ける。ステップ７１５において構成の更新が成功した場合、制御はステップ７２０に進み、構成データベース７３０を更新する。ステップ７２０の参照に戻る。サーバ１４５が出す確認応答が成功した場合にも、制御はステップ７３５に進み、負荷を均衡化させる基盤整備を求める構成更新要求を要求する。同様に、ステップ７２０において構成の更新が成功しなかった場合、制御はステップ７４５に進み、例外処理の警告を生成する。そして、ステップ７５０において、リソースの更新は失敗したものとみなす。
【図面の簡単な説明】
【００２７】
【図１】本発明の好適な実施形態に従い本発明を実装することのできるサーバ・ファームを示す図である。
【図２】本発明の好適な実施形態に従い本システムのコンポーネント群の概要を示すブロック図である。
【図３】本発明の好適な実施形態に従い図２のウェブ・サーバの動的コンテンツ・モジュールの機能を示すフローチャートを示す図である。
【図４】本発明の好適な実施形態に従い図２のウェブ・サーバの報告モジュールの機能を示すフローチャートを示す図である。
【図５】本発明の好適な実施形態に従い図２の管理サーバの解析モジュールの機能を示すフローチャートを示す図である。
【図６】本発明の好適な実施形態に従い図２の管理サーバのリソース割り振りモジュールの機能を示すフローチャートを示す図である。
【図７】本発明の好適な実施形態に従い図２の管理サーバのリソース更新モジュールの機能を示すフローチャートを示す図である。
【符号の説明】
【００２８】
１００  クライアント装置
１０５  クライアント装置
１１０  ネットワーク
１１５  ルータ
１２０  ルータ
１２５  ＬＡＮ
１３０  ルータ／ファイアウオール
１３５  ネットワーク
１４０  管理サーバ
１４５  サーバ
１５０  サーバ
１５０  サーバ
１６０  ネットワーク
１６５  ルータ／ファイアウオール
１７０  ネットワーク
１７５  データ・ソース・サーバ
１８０  データ・ソース・サーバ
【国際調査報告】
2005539298.tif 000010
2005539298.tif 000011
2005539298.tif 000012