JP2004110791A - ブレードアーキテクチャのための動的適応サーバプロビジョニング - Google Patents

Abstract

【課題】　ラック・ブレードコンピュータアセンブリのコンピューティング資源を自動的に割り当てる。
【解決手段】　本方法は、ラック・ブレードコンピュータアセンブリのラックに配置されたアプリケーションサーバプールからサーバパフォーマンス情報を受け取ることと、アプリケーションサーバプールに対する少なくとも１つのＱｏＳ属性（たとえば、ＱｏＳ属性の集合体）を確定することと、ＱｏＳ属性が標準より下であると確定することと、アプリケーションサーバプールによって使用されるためにフリーサーバプールからブレードサーバを割り当てることとを含む。
【選択図】図４

Description

　本発明の実施形態は、概してコンピュータシステムに関する。
　より詳細には、本発明の実施形態は、サービス品質要求を満たすためにコンピューティング資源（たとえば、ブレードサーバ）をいかに作業負荷に割り当てるかを自動化するラック・ブレードコンピューティングシステムおよび方法に関する。

　［関連発明の相互参照］
　この特許出願は、以下の本願と同一の譲受人に譲渡された特許出願に関連する。
　すなわち、２０００年１月２８日に出願され「Dynamic Management of Computer Workloads Through Service Level Optimization」と題された米国特許出願第０９／４９３，７５３号と、２０００年４月２９日に出願され「Reconfiguration Support for a Multi-Partition Computer System」と題された米国特許出願第０９／５６２，５９０号と、２００２年７月２６日に出願され「Dynamic Management of Virtual Partition Computer Workloads Through Service Level Optimization」と題された米国特許出願第１０／２０６，５９４号とである。

　情報テクノロジ（ＩＴ）産業では、コストを削減するためにデータセンタ空間の平方フィート当りのコンピュータ密度をより高くすることが要求されており、それと同時に、ＩＴサービス提供能力は向上しなければならない。
　ブレードサーバにおける別の重要な傾向は、Ｉｎｔｅｌプロセッサおよびチップセットを取り巻くサーバアーキテクチャと、ＷｉｎｄｏｗｓまたはＬｉｎｕｘ動作環境との標準化であった。
　ＷｉｎｄｏｗｓまたはＬｉｎｕｘを実行している安価な業界標準サーバは、データセンタにおいて激増しており、管理容易性問題をもたらしている。
　データセンタに入るサーバが増大することにより、ＩＴ組織は、サーバとそれらが実行するアプリケーションとを管理する追加のシステム管理者を雇用しなければならない。
　より密度が高くより管理コストの低いシステムに対する要求に応答して、多くの主なベンダは、近年、新たなサーバアーキテクチャ、すなわち「ラック・ブレード（rack and blade）」アーキテクチャに基づく製品を導入した。

　概して、ブレードサーバは、少なくとも１つ（たとえば、２つ以上）のマイクロプロセッサと、メモリと、任意に永久記憶装置とを備える、薄い、モジュール式の電子回路基板である。
　より詳細には、ブレードサーバは、プロセッサと、メモリと、ディスクと、接続手段（標準省スペースコンピュータラックのスロットにネジで取り付ける）とを備えた単一の独立したコンピュータマザーボードである。
　すべてのブレードサーバが、通常、単一（または、より一般的には二重冗長）電源と、ファンと、バックボーンとを共有する。
　ブレードサーバのバックボーンへの接続手段は、プロプラエタリであるかまたは標準ベース（たとえば、コンパクトＰＣＩ）である。

　ブレードサーバは、通常、単一の専用アプリケーション（ウェブページを提供する等）を対象としており、多くが同様のサーバを含む省スペースラックのスロットに容易に挿入することができる。
　省スペースラックによっては、単に例として、標準４２Ｕラックに、すべてが共通の高速バスを共有しあまり熱を生成しないように設計されている２８０までのブレードサーバを取り付ける容量を有し、それによりスペースとともにエネルギーコストが節約される。
　ブレードサーバのユーザには、大型のデータセンタとウェブサイトをホストするインタネットサービスプロバイダ（ＩＳＰ）とがある。

　ブレードサーバは、時に「高密度サーバ」と呼ばれ、通常、ファイル共有、ウェブページサービングおよびキャッシング、ＳＳＬ暗号化またはウェブ通信、より小型のディスプレイのためのウェブページコンテンツのトランスコーディング、ならびに音声および映像コンテンツストリーミング等の、単一タスクに専用のサーバのクラスタリングに使用される。

　ブレードサーバは、通常、オペレーティングシステムを搭載し、標準的に、単一アプリケーションまたはアプリケーションコンポーネントに専用である。
　ブレードに必要な記憶装置を、ブレードに組み込むことができ、あるいはストレージエリアネットワーク（ＳＡＮ）またはネットワーク接続ストレージ（ＮＡＳ）等の標準接続メカニズムを介して外部から入手可能とすることができる。
　ブレードを動作させるために必要なオペレーティングシステムとアプリケーションとを、ブレードが利用可能な記憶装置からロードすることができる。

　より従来的なクラスタサーバのように、ブレードサーバを、負荷分散およびフェイルオーバ能力を含むように管理することも可能である。
　負荷分散は、ブレードサーバが行わなければならない作業の量を２つ以上のブレードサーバ間で分配することにより、同じ時間でより多くの作業が行われ、概してすべてのユーザがより高速にサービスされるようにしている。

　負荷分散を、ハードウェア、ソフトウェア、またはそれらの組合せで実施することができる。
　通常、負荷分散は、ブレードサーバクラスタリングの主な要因である。
　フェイルオーバは、主ブレードサーバが将来の、またはスケジュールされたダウン時間に利用不可能となった場合に、主ブレードサーバの機能を補助ブレードサーバが引き受ける、バックアップ動作モードである。

　ストレージエリアネットワーク（ＳＡＮ）等の最近の開発により、ブレードサーバとデータ記憶システムとの間で任意のものから任意のものへの（any-to-any）接続が可能になる。
　概して、記憶ネットワークは、ブレードサーバとシステムとの間に、各々が関連するすべてのコンポーネントの完全なセットからなる多くの経路を使用する。
　障害経路は、経路のいずれかの個々のコンポーネントの障害からもたらされる可能性がある。
　各々が冗長コンポーネントを有する複数の接続経路を使用して、１つ（または複数）の経路に障害が発生した場合であっても接続が依然として存続可能であることを確実にするのに役立つ。
　自動フェイルオーバの能力は、装置の問題によってもたらされる必然的な割込みにも関らず正常機能を維持することができることを意味する。

　提供される大抵のブレードサーバは、今日、統合管理ソリューションを提供する。
　たとえば、Ｄｅｌｌ　ＰｏｗｅｒＥｄｇｅ　１６５５ＭＣは、オペレーティングシステム独立のキーボード、ビデオおよびマウス機能とともに、専用管理ネットワークを通してシャシおよびブレード監視とリモート電源制御とを提供する管理カードを含む。
　ＨＰ　ＰｒｏＬｉａｎｔ　ＢＬ　ｅ−Ｃｌａｓｓは、Integrated Administrator、すなわちリモートアクセスまたはローカルアクセスのための統合サーバブレード管理ソリューションを含む。
　それはまた、中央イメージリポジトリから１つまたは複数のブレードサーバに、オペレーティングシステムおよびアプリケーションをインストールすることを可能にするラピッドデプロイメント（rapid deployment（短期間導入））ソリューションも含む。

　ブレードサーバアーキテクチャは、「スケールアウト」すなわち水平方向にスケーリングすることができる、すなわちタスクを実行しているサーバのプールにさらなるサーバを追加することにより容量を拡張することができる、情報テクノロジー（ＩＴ）サービスまたはアプリケーションに対して理想的である。
　水平方向にスケーリングするサービスの例には、主にＨＴＴＰによるウェブサーバと、通常ＦＴＰによるがメディアストリーミングも含むファイルサーバと、アプリケーションサーバとがある。

　複数のウェブサーバを負荷分散ネットワーク装置に接続することにより、ウェブページ要求をサービスするタスクを共有することができる。
　ファイルサーバは、結合してより高いスループットを提供することができる複数サーバである。
　通常、これらのサーバの前に、ネットワークによるサービスへのアクセスを仮想化するトラフィック管理装置がある。
　アプリケーションサーバは、Ｊａｖａ２エンタプライズエディション（Enterprise Edition）等の標準プラットフォームでビジネスロジックを実行するサーバである。
　複数のアプリケーションサーバが併せて動作することにより、負荷を共有することによってより高いサービス能力を提供することができる。

　今日、大抵の主なベンダがブレードサーバによる統合管理ソリューションを提供するが、これらのソリューションは、完全なプロビジョニング自動化を提供するには及ばない。
　オペレータは、いずれのブレードサーバでいずれのアプリケーションまたはサービスを実行するかを判断し、たとえばともにＨＰからのＩｎｓｉｇｈｔ　ＭａｎａｇｅｒまたはＯｐｅｎｖｉｅｗ等のツールを使用して、各ブレードサーバにおける可用性およびパフォーマンスを管理しなければならない。
　要求が急上昇した場合、ウェブサイトのヒットが急速に増大した場合と同様に、アプリケーションをサポートするブレードサーバの数を増大させることが必要である場合がある。

　迅速に応答するためには、パフォーマンス監視および警報とラピッドデプロイメントとを利用する場合であっても、かなりの人間の介入が必要となる。
　たとえば、ブレードのグループで実行中の事前指定されたレベルのＨＴＴＰサービスを維持するために、複数のステップを実行することが必要な場合がある。

　１つのステップは、適当な処置を講ずることができるように、サービス品質の劣化を検出するためにパフォーマンス監視サービスが動作中であることを確実にする、ということである。
　パフォーマンス劣化をアサートする多くの異なるメカニズムがあり、大抵、ＣＰＵ消費閾値、プロセスの数、同時のアクティブな接続の数等のシステムレベルパフォーマンス基準に基づく。
　また、パフォーマンス監視サービスを、アプリケーションレベルで、たとえば単位時間当りに供給されるページの数か、または要求毎の平均応答時間で取得することも可能である。

　もう１つのステップは、追加のサーバ資源を要求しているサービスを実行するために割り当てることができる候補ブレードサーバを選択する、ということである。
　このプロセスは、実行しているサーバの数の減少に耐えることができる、ラックによって提供される別のサービスを特定する必要があり得る。
　代替的に、ブレードサーバを、システム管理者によって維持されるスタンバイサーバのフリープールから取得することができる。

　一旦割り当てるための候補ブレードサーバが特定されると、その候補ブレードサーバがすでにサービスをアクティブに実行している場合、それに対しデータおよびプロセスを「フラッシュ」する必要があり、このブレードサーバにトラフィックを向けるトラフィック管理装置に対し、トラフィックがその候補ブレードサーバにそれ以上ルーティングされないように、再環境設定通知を送信する必要がある。
　また、フラッシュプロセスでは、ＩＰアドレスをこのブレードサーバに再割り当てする必要もある。

　ブレードサーバのグループで動作している事前指定されたレベルのＨＴＴＰサービスを維持するために必要であり得るさらなるステップは、候補ブレードサーバに、それが所望のタスクを実行するために必要である動作環境とアプリケーションバイナリとをプリロードする必要がある場合がある、ということである。
　このステップを実行するためには、オペレータがリポジトリから正しいイメージを選択し、それを候補ブレードサーバにロードするために使用することができるラピッドデプロイメントシステムを有することが必要となる。

　一旦オペレーティングシステムとアプリケーションコードとがロードされると、候補ブレードサーバを環境設定することが必要となる。
　これには、追加のデータおよびエージェントと、この候補ブレードサーバに特定であり先に示したラピッドデプロイメントステップによって取り込まれていない任意の他のステップとが必要となる場合がある。

　一旦候補ブレードサーバが環境設定され実行中となると、それを同じタスクを実行しているブレードサーバのプールに追加することが必要となる。
　これは、通常、ブレードサーバプールにトラフィックを向けるトラフィック管理装置に対する設定変更を必要とする。

　最後に、示したステップのすべてが実行された後、パフォーマンス管理ループが再構成されたプールによって再開する。
　規則的な間隔で、またはアラームが鳴った場合に、監視ツールによって能力要求が検査され、ブレードサーバは、ラックに導入されたすべてのサービスに対する全サービスレベル目的を満足させるために再平衡化される。

　本発明の実施形態は、ラック・ブレードコンピュータアセンブリのコンピューティング資源を自動的に割り当てる方法を提供する。

　本方法は、ラック・ブレードコンピュータアセンブリのラックに配置されたアプリケーションサーバプールからサーバパフォーマンス情報を受け取ることと、アプリケーションサーバプールに対する少なくとも１つのＱｏＳ属性（たとえば、ＱｏＳ属性の集合体）を確定することと、ＱｏＳ属性が標準より下であると確定することと、アプリケーションサーバプールによって使用されるためにフリーサーバプールからブレードサーバを割り当てることとを含む。
　本方法は、使用するために割り当てる前に、フリーサーバプールからブレードサーバを選択することであって、それによって選択されたブレードサーバを取得する、選択することと、使用するために割り当てる前に、選択されたブレードサーバをアプリケーションサーバプールで動作するように用意することとをさらに含んでよい。

　本方法は、アプリケーションサーバプールに関連するトラフィック管理装置を再環境設定することをさらに含んでよい。
　ラック・ブレードコンピュータアセンブリのコンピューティング資源を自動的に割り当てるこの方法の実施形態の特徴のうちの１つまたは複数を実行する命令が格納された、機械読取可能媒体が提供される。

　また、本発明の実施形態は、ラック・ブレードコンピュータアセンブリのコンピューティング資源を自動的に割り当てる方法も提供する。
　本方法は、ラック・ブレードコンピュータアセンブリのラックに配置されたアプリケーションサーバプールからサーバパフォーマンス情報を受け取ることと、アプリケーションサーバプールに対する少なくとも１つのＱｏＳ属性（たとえば、ＱｏＳ属性の集合体）を確定することと、ＱｏＳ属性が標準より上であると確定することと、アプリケーションサーバプールからブレードサーバの使用を取り除くこととを含む。

　本方法はさらに、フリーサーバプールによって使用されるために、取り除かれたブレードサーバを割り当てることを含んでよい。
　ラック・ブレードコンピュータアセンブリのコンピューティング資源を自動的に割り当てるこの方法の実施形態の特徴のうちの１つまたは複数を実行する命令が格納された、機械読取可能媒体が提供される。

　さらに、本発明の実施形態は、ラック・ブレードコンピュータアセンブリのコンピュータ資源を自動的に割り当てる方法を提供する。
　本方法は、ラック・ブレードコンピュータアセンブリのラックに配置されたアプリケーションサーバプールからサーバパフォーマンス情報を受け取ることと、アプリケーションサーバプールに対する少なくとも１つのＱｏＳ属性を確定することと、ＱｏＳ属性が標準より下であると確定することと、フリーサーバプールのいずれのブレードサーバも使用することができないと確定することと、アプリケーションサーバプールによって使用されるために優先度の低いブレードサーバを利用する（improve）こととを含む。

　本方法は、さらに、使用するために利用する前に、アプリケーションサーバプールからブレードサーバを選択することであって、それにより選択されたブレードサーバを取得する、選択することを含んでよい。
　選択されたブレードサーバを使用するために利用することは、選択されたブレードサーバをアプリケーションサーバプールで動作するように用意することを含む。
　さらに、本方法は、選択されたブレードサーバをフラッシュすることと、アプリケーションサーバプールに関連するトラフィック管理装置を再環境設定することとを含んでよい。
　ラック・ブレードコンピュータアセンブリのコンピューティング資源を自動的に割り当てるこの方法の実施形態の特徴のうちの１つまたは複数を実行する命令が格納された、機械読取可能媒体が提供される。

　また、本発明の実施形態は、ラック・ブレードコンピュータアセンブリのコンピューティング資源を自動的に割り当てる方法であって、ラック・ブレードコンピュータアセンブリのラックに配置されたアプリケーションサーバプールからサーバパフォーマンス情報を受け取ることと、アプリケーションサーバプールに対する少なくとも１つのＱｏＳ属性を確定することと、ＱｏＳ属性が標準より下であると確定することとを含む方法も提供する。
　また、本方法の実施形態は、フリーサーバプールが使用するためのブレードサーバを有すると確定することと、フリーサーバプールから、アプリケーションサーバプールによって使用可能なブレードサーバを選択することとを提供する。

　本方法のさらなる実施形態は、選択された使用可能なブレードサーバにソフトウェアをインストールすること、および／または選択された使用可能なブレードサーバを環境設定すること、および／または選択された使用可能なブレードサーバを動作するように用意すること、および／またはアプリケーションサーバプールに関連するトラフィック管理装置を再環境設定することを含む。
　ラック・ブレードコンピュータアセンブリのコンピューティング資源を自動的に割り当てるこの方法の実施形態の特徴のうちの１つまたは複数を実行する命令が格納された、機械読取可能媒体が提供される。

　また、本発明の実施形態は、ラック・ブレードコンピュータアセンブリのコンピューティング資源を自動的に割り当てるシステムであって、ラック・ブレードコンピュータアセンブリからブレードサーバパフォーマンス情報を受け取る手段と、ブレードサーバパフォーマンス情報を受け取る手段に連結され、イメージリポジトリを管理する手段とを備えたシステムをさらに提供する。
　さらに、本システムは、ブレードサーバパフォーマンス情報を受け取る手段に連結された、少なくとも１つのポリシを格納するデータベース手段と、ブレードサーバパフォーマンス情報を受け取る手段に連結された、ハードウェア情報を格納するリポジトリ手段とを有してよい。
　ラック・ブレードコンピュータアセンブリは、フリーサーバプールと、少なくとも１つ（たとえば、２つ以上）のアプリケーションサーバプールとを備える。

　これらの提供物（provisions）は、以下の説明を読み進めるにしたがい当業者には明らかになるであろうあらゆる補助的な提供物および特徴とともに、本発明の実施形態の装置、組立品、システムおよび方法によって達成され、そのあらゆる実施形態を、単に実施例として添付図面を参照して示す。

　本発明によれば、ラック・ブレードコンピュータアセンブリのコンピューティング資源を自動的に割り当てる方法が提供される。

　本明細書の説明において、本発明の実施形態の完全な理解を提供するために、構成要素および／または方法の実施例等、複数の特定の詳細を提供する。
　しかしながら、当業者は、本発明の一実施形態を、特定の詳細のうちの１つまたは複数なしに、あるいは他の装置、システム、組立品、方法、構成要素、材料、部品等により実施することができる、ということを認めるであろう。
　言い換えれば、本発明の実施形態の態様を不明確にすることを回避するために、既知の構造、材料、または動作を特に詳細には図示も説明もしない。

　本発明の実施形態の目的のための「コンピュータ」は、メインフレームコンピュータ、パーソナルコンピュータ、ラップトップ、ノートブック、マイクロコンピュータ、サーバ、または同様のもののいずれか等、いかなるプロセッサ内蔵装置であってもよい。
　「コンピュータプログラム」は、当業者には既知であるコンピュータに挿入されるいかなる適当なプログラムまたはコード化された命令のシーケンスであってもよい。

　より詳細に言えば、コンピュータプログラムは、実行時にコンピュータに対して所定の方法で振る舞わせる編成された命令のリストである。
　コンピュータプログラムは、材料（変数と呼ぶ）のリストと、コンピュータに対し変数の処理の仕方を伝える命令（ステートメントと呼ぶ）のリストとを含む。
　変数は、数値データ、テキスト、またはグラフィカルイメージを表すことができる。

　本発明の実施形態の目的のための「コンピュータ読取可能媒体」は、命令実行システム、装置、機器または装置によるか、またはそれに関連して使用されるプログラムを内蔵し、格納し、通信し、伝播し、または移送することができるいかなる媒体であってもよい。
　コンピュータ読取可能媒体は、限定としてではなく単に例として、電子、磁気、光、電磁気、赤外線、または半導体のシステム、機器、装置、伝播媒体、またはコンピュータメモリとすることができる。

　本発明の実施形態の「サービス品質（Quality of Service）」すなわちＱｏＳ属性は、プリミティブの測定可能特性、特に任意の特定のアプリケーションによって制御システムに供給されるパフォーマンスのレベルを画定することができる。
　単に例として、ＱｏＳは、ファイルサービスに対し「ＸＭｂ／秒の総スループットを実現する（Deliver X Mb/s Aggregate Throughput）」であってよく、または電子メール交換サービスに対し「Ｎ電子メールメッセージ／秒を処理する（Process N Email Messages Per Second）」であってよい。

　また、ＱｏＳ属性を、制御システムのいかなる特定のアプリケーションに関してでもなく、コンピュータシステムに関して定義することも可能である。
　さらに単に例として、コンピュータシステム用語におけるＱｏＳは、「このサービスに寄与している各サーバにおいてＣＰＵ負荷をＸパーセントより低く維持する（Maintain CPU Load Below X Percent On Each Server Contributing To This Service）」であってよい。

　アプリケーションレベルで属性を測定することが困難である場合に、かかるプロキシＱｏＳ属性を使用することができる。
　また、ＱｏＳ属性は、「サービスレベル目標値（Service Level Objective）」すなわちＳＬＯとしても既知である。

　本発明のあらゆる実施形態における「資源割当プリミティブ（Resource Allocation Primitive）」は、特定のＱｏＳ属性を達成するために制御システムの実施形態によって行われる動作を定義する。
　ブレードサーバアーキテクチャにおけるより一般的な資源割当プリミティブ動作のうちの１つは、特に最も少ない数のサーバでＱｏＳ属性を維持するために、アプリケーションサーバプールに対してブレードサーバを追加または除去することである。

　本発明のあらゆる実施形態における「ポリシ（Policy）」は、ＱｏＳ属性と資源割当プリミティブとのペア等のペアを定義するルールであってよい。
　ペアポリシにより、サービス品質要求と任意のサービス品質属性を維持するためにとる必要がある動作とを定義することが可能になる。
　ポリシは、ＱｏＳ属性が自動化制御システムによって維持されるのを可能にする記述であってよい。

　「トラフィック管理装置（Traffic Management Device）」（ＴＭＤ）は、通常分散アプリケーションにおいてインターネットまたはイントラネットから発してよいサービスに対する要求に対して、ルーティング装置として機能する。
　トラフィック管理装置は、サービスに対する要求を、サービスに対する任意の特定の要求をサービスすることができる適当なブレードサーバに向ける。

　単に例として、トラフィック管理装置は、負荷分散アプライアンスであってよく、それは、ラウンドロビン、最小負荷または同様のもののいずれか等、何らかの所定のメカニズムを使用することにより、ＨＴＴＰトラフィックをブレードサーバのプールのいくつかのあり得るブレードサーバのうちの１つまたは複数にルーティングする。
　ラックのブレードサーバの結合を統合された管理プリミティブとともに利用することにより、あり得る最低コストで最適なパフォーマンスを得ることができるような方法で、作業負荷をブレードサーバにマップする自動化メカニズムを提供することが望ましい。

　本発明のあらゆる実施形態における「ラピッドデプロイメントシステム（Rapid Deployment System）」（ＲＤＳ）は、オペレーティングシステムとアプリケーションイメージとが中央リポジトリに格納され、ブレードサーバにリモートにインストールされるのを可能にするシステムまたは機能あるいはサービスを含む。
　本発明のあらゆる実施形態の目的のために、ラピッドデプロイメントサービスは、各ブレードサーバに対して利用可能であり、関連するブレードサーバをブートするために必要ないかなるコードをも作成し、または生成することができる。
　また、各ブレードサーバに対するラピッドデプロイメントサービスは、それぞれのブレードサーバが利用可能な唯一の記憶装置である場合にローカルブレード記憶装置にインストールされる、ネットワーキング動作を介して利用可能なコードのアプリケーションも作成することができる。

　「アプリケーションサーバプール（Application Server Pool）」すなわちＡＳＰは、所望のサービスを供給するために連動して作用するブレードサーバのグループである。
　ＡＳＰのすべてのブレードサーバが、同じ動作環境と同じアプリケーションとを実行することができる。
　アプリケーションサーバプールは、通常、任意のアプリケーションサーバプールに関連するそれぞれのブレードサーバにトラフィックをルーティングするトラフィック管理装置に連結される。
　アプリケーションサーバプールは、１つまたは複数のＱｏＳ属性が関連付けられるとともに、優先度のより高いアプリケーションサーバプールの必要を満たすためにアプリケーションサーバプールからブレードサーバを取り除くことが必要であり、いずれのフリーサーバプールにおいてもいずれのブレードサーバも使用可能でない場合に、使用されることになる相対優先度を有する。

　「フリーサーバプール（Free Server Pool）」（ＦＳＰ）は、目下いかなるアプリケーションサーバプールにも割り当てられていないブレードサーバのグループである。
　フリーサーバプールからの１つまたは複数のブレードサーバに対し、本発明のあらゆる実施形態に対する動的な適応ブレードサーバプロビジョニングに従って割り当てを行うことができる。

　ＦＳＰにおけるブレードサーバはスタンバイ状態であり、すなわち、起動されネットワークに接続されているが、オペレーティングシステムを実行していない。
　ＦＳＰにおける１つまたは複数のブレードサーバに、オペレーティングシステム（ＯＳ）と必要とされる可能性が最も高いアプリケーションとをプリロードすることができる。

　ここで図１を参照すると、概略的に、本発明のあらゆる実施形態に対する、概して１０として示すラック・ブレードコンピューティングシステムの概略図が示されている。
　ラック・ブレードコンピューティングシステム１０は、少なくとも１つのラック、特に、ラック１２ａ、ラック１２ｂおよびラック１２ｃを備える概して１２として示す複数のラックを有する。
　ラック１２は、概して１６として示すローカルエリアネットワーク（ＬＡＮ）を介して管理サーバ１４に連結される。

　ＬＡＮ１６は、管理サーバ１４とそれぞれのラック１２ａ、１２ｂ、および１２ｃとの間の信号インターフェースとして機能する。
　管理サーバ１４は、複数のラック１２にわたって作用し、動作的にそれらに及ぶ。
　ＡＳＰ２０は、それらのそれぞれの関連するラック１２に専用であってよく、通常専用である。
　ラック・ブレードコンピューティングシステム１０は、管理サーバ１４を通して管理される動的プロビジョニングシステムのあらゆる実施形態を実行する。

　ラック１２ａ、ラック１２ｂ、およびラック１２ｃは、ラック１２の各々において概して２０として示す少なくとも１つのアプリケーションサーバプール（ＡＳＰ）を含む。
　より詳細には、ラック１２ａ、１２ｂ、およびラック１２ｃは、それぞれ、第１ＡＳＰ２０ａおよび第２ＡＳＰ２０ａと、第１ＡＳＰ２０ｂおよび第２ＡＳＰ２０ｂと、第１ＡＳＰ２０ｃおよび第２ＡＳＰ２０ｃとを含む。
　ＡＳＰ２０の各々は、所望のサービスまたはアプリケーションを実行することができる少なくとも１つのブレードサーバ（以下「３４」として特定する）を有する。

　任意に、ラック１２の少なくとも１つは、ラック１２のＡＳＰ２０のいずれにも割り当てられていない、概して２４として示すフリーサーバプール（ＦＳＰ）を含む。
　なお、当然ながら、いかなるＦＳＰ２４も、所望のサービスまたはアプリケーションを実行することができる少なくとも１つのフリーブレードサーバを含む。

　また、当然ながら、いかなる特定のＡＳＰ２０におけるブレードサーバの最大数も、特定のラック１２におけるブレードサーバの総数から特定のフリーサーバプール２４におけるアクティブなブレードサーバの数を引いたものである。
　図１に最もよく示すように、ラック１２ａ、１２ｂおよび１２ｃは、それぞれＦＳＰ２４ａ、ＦＳＰ２４ｂ、およびＦＳＰ２４ｃを含む。

　ＡＳＰ２０の各々を、望ましい場合は、ラック１２の各々の外部にある概して２８として示すトラフィック管理装置（ＴＭＤ）に連結することができ、トラフィック管理装置２８の各々をＬＡＮ１６に連結することができる。
　より詳細には、および図１にさらに最もよく示すように、ＡＳＰ２０ａ−２０ａ、２０ｂ−２０ｂ、および２０ｃ−２０ｃは、それぞれ、各ラック１２の外部にある概して３０として示す関連するローカルＬＡＮを通してＴＭＤ２８ａ−２８ａ、２８ｂ−２８ｂおよび２８ｃ−２８ｃに連結され、ＴＭＤ２８ａ−２８ａ、２８ｂ−２８ｂおよび２８ｃ−２８ｃは、それぞれネットワークバックボーン１６に連結される。
　ローカルＬＡＮ３０を、より詳細に３０ａ−３０ａ、３０ｂ−３０ｂおよび３０ｃ−３０ｃとして示すことができ、ローカルＬＡＮ３０は、図示するようにそれぞれのＴＭＤ２８をそれぞれのラック１２に連結するすることができる。

　ここで図２を参照すると、概して３４として示す少なくとも１つのブレードサーバを含むＡＳＰ２０ａが図示されている。
　より詳細には、ＡＳＰ２０ａは、ブレードサーバ３４ａ−３４ａ−３４ａを含み、それらの各々は関連するサーバエージェント３５ａを有する。
　いずれかの関連するサーバエージェントを含むブレードサーバ３４の各々は、概して３６として示すチャネルラインを介してネットワークバックボーン１６と通信する。

　より詳細には、それぞれの関連するサーバエージェント３５ａ−３５ａ−３５ａを含むそれぞれのブレードサーバ３４ａ−３４ａ−３４ａは、それぞれのチャネルライン３６ａ−３６ａ−３６ａを介してＬＡＮ１６と通信する。
　また、それぞれの関連するサーバエージェント３５ａ−３５ａ−３５ａを含むブレードサーバ３４ａ−３４ａ−３４ａは、監視チャネルライン３８を介して管理サーバ１４とも通信する。

　なお、ＡＳＰ２０ａを、ブレードサーバ３４ａ−３４ａ−３４ａとそれらの関連するサーバエージェント３５ａ−３５ａ−３５ａとを含むように説明したが、当然ながら、ＡＳＰ２０ｂおよびＡＳＰ２０ｃもまた、同様のブレードサーバを関連するサーバエージェントとともに有し、チャネルライン３６と同様のチャネルラインを介してＬＡＮ１６と通信する。
　また、ＡＳＰ２０ａのブレードサーバ３４ａ−３４ａ−３４ａを、それらの関連するサーバエージェント３５ａ−３５ａ−３５ａとともに、監視チャネルライン３８を介して管理サーバ１４と通信しているように示したが、当然ながら、ＡＳＰ２０ｂおよびＡＳＰ２０ｃのブレードサーバもまた、それらの関連するサーバエージェントとともに、同様の監視チャネルラインを介して管理サーバ１４と通信する。

　続けて図２を参照するとともにここで図３も参照すると、データリポジトリ、特にポリシデータベース４０とハードウェア情報リポジトリ（ＨＩＲ）とに連結された管理サーバ１４が示されている。
　また、管理サーバ１４とイメージリポジトリ４８とに通信可能に連結されたラピッドデプロイメントシステム５０もまた示されている。

　ラピッドデプロイメントシステム５０は、イメージリポジトリ４８を管理し、プロビジョニングライン６０を介してＬＡＮ１６と通信する。
　図３に示すように、管理サーバ１４は、任意のＡＳＰ２０のブレードサーバ３４のうちの１つまたは複数に、任意の望ましいオペレーティングシステム（ＯＳ）および／またはアプリケーションをインストールすることができるラピッドデプロイメントシステム５０も含むことができる。

　より詳細には、管理サーバ１４は、ラピッドデプロイメントシステム５０を使用することにより、イメージリポジトリ４８からプロビジョニングライン６０を通して１つまたは複数のブレードサーバ３４に、イメージ（たとえば、任意の所望のオペレーティングシステムおよび／またはアプリケーションを含むディスクイメージ等のイメージ）をプロビジョニングすることができる。
　管理サーバ１４は、その関連するラピッドデプロイメントシステム５０を使用し、かつそれに対して、任意のＡＳＰ２０のブレードサーバ３４のうちのいずれかをフリーサーバプール２４のブレードサーバのうちのいずれかと同様に導入しおよび／または削除するように命令する能力を有する。
　なお、当然ながら、ラピッドデプロイメントシステム５０はＩＯが管理サーバ１４にあってよく、あるいは別個のサーバに導入されることも可能である。

　ポリシデータベース４０は、ＱｏＳ属性および動作のすべてを、ポリシの形態で、特にポリシまたはルールの形態で格納する。
　ハードウェア情報リポジトリ４４は、単に例として、ＡＳＰ２０およびそれらの関連するブレードサーバ３４に関する情報ならびにＦＳＰ２４に関する情報等、それが管理するハードウェアのすべてに関する情報を含む。

　管理サーバ１４は、図示するように、ブレードサーバ３４の各々とともにそれらの関連するサーバエージェント３５ａと通信する。
　サーバエージェント３５ａは、その関連するブレードサーバ３４ａで実行しているアプリケーションのパフォーマンスを測定する。

　測定を、ハードウェアレベル、たとえばＣＰＵおよびメモリ利用で、あるいはアプリケーション特有の測定を使用してアプリケーションレベルで行ってよい。
　ウェブベースエンタプライズ管理（Web-based Enterprise Management（ＷＢＥＭ））またはシステムネットワーク監視プロトコル（Systems Network Monitoring Protocol（ＳＮＭＰ））等の標準メカニズムを使用して、任意のサーバエージェント３５ａから管理サーバ１４にこの情報を通信することができる。

　また、サーバエージェント３５ａは、アラーム（たとえば、ＳＮＭＰトラップ）を非同期に管理サーバ１４に伝送してもよい。
　サーバエージェント３５ａは、任意の所望のアプリケーションレベルパフォーマンスを測定するためにアプリケーション特有のコンポーネントを有してよい。
　単に例として、Ｍｉｃｒｏｓｏｆｔ　Ｅｘｃｈａｎｇｅサーバを監視しているサーバエージェント３５ａは、Ｍｉｃｒｏｓｏｆｔ　Ｅｘｃｈａｎｇｅサーバによって単位時間当りに処理されるメッセージを取得し、それらを追跡する能力を有する。

　さらに図２および図３に最もよく示すように、管理サーバ１４は、ＡＳＰ２０の各々によってサポートされる各アプリケーションに対しアプリケーションプラグイン７０を有する。
　このため、通常、複数のアプリケーションプラグイン７０がある。
　各アプリケーションプラグイン７０は、ブレードサーバ３４上の各サーバエージェント３５ａから発している基準（すなわち、属性が処理される程度の定量的測度か、または観測された属性値から計算された値）を相関させるとともに、ＡＳＰ２０の各々がどの程度そのＱｏＳ属性を満たしているかの現基準を提供する。

　また、管理サーバ１４は、それぞれのＡＳＰ２０のブレードサーバ３４にトラフィックをルーティングするトラフィック管理装置２８の各々を環境設定する能力も有する。
　トラフィック管理装置２８の各々は、ＳＮＭＰ等の標準管理プロトコルを使用して管理サーバ１４と通信する。

　ここで図４を参照すると、本発明の実施形態の動作を表すブロックフローチャートが示されている。
　図４によって表す動作は、概して、修復または保守のためにのみ停止または休止する、エンドレスな連続して実行する動作である。
　管理サーバ１４は、通常、アイドルループの形態をとり、ブレードサーバ３４に関連するサーバエージェント３５ａから情報を受け取るまで待機している。

　図示するように、管理サーバ１４は、サーバエージェント３５ａによってブレードサーバ３４から受け取られその後伝送される情報から、ブレードサーバ３４の各々のパフォーマンスを監視する。
　管理サーバ１４は、監視チャネルライン３８を介してサーバエージェント３５ａから情報が伝送された場合、または新たなポーリングサイクルが開始した場合に起動（wake up）する。

　サーバエージェント３５ａによって監視チャネルライン３８を介して管理サーバ１４に渡される情報は、関連するブレードサーバ３４ａにおけるアプリケーションのパフォーマンスを示す数値データからなる。
　たとえば、サーバエージェント３５ａは、関連するブレードサーバ３４ａにおけるアプリケーションのパフォーマンスを反映する合成数を生成してよい。

　情報を、規則的なまたは周期的な間隔でポーリングによって同期に、あるいはそれぞれのサーバエージェント３５ａによって送信されるアラームによって同期に、管理サーバ１４に伝送してよい。
　ポーリングが頻繁に行われる場合、アラーム伝送は必要ではなく、任意の機能となる。

　図４のステップ１０１に従って、管理サーバ１４がブレードサーバ３４に関連するサーバエージェント３５ａの各々からサーバパフォーマンス情報を受け取った後、その受け取ったサーバパフォーマンス情報のすべてが、管理サーバ１４によって照合され、相関され、統合され、その後、管理サーバ１４は、それぞれのＡＳＰ２０に対して少なくとも１つのＱｏＳ属性を計算または確定する。
　より詳細には、およびステップ１０２によって示すように、ＡＳＰ２０の各々に対する管理サーバ１４に関連する各アプリケーションプラグイン７０は、ＡＳＰ２０の各々に対して少なくとも１つのＱｏＳ（たとえば、総ＱｏＳ）を計算または確定する。

　実行中のまたはラック１２のうちの１つにおけるＡＳＰによって実行されている特定のアプリケーションまたはサービス要求に対して測定または確定されたＱｏＳ属性が、ユーザによって設定され、またはポリシＤＢ４０に配置された標準または目標から異なり、逸脱し、またはそれている場合、ステップ１０３に従って、測定または確定されたＱｏＳ属性が標準または目標より上であるか下であるかの判断がなされる。
　ステップ１０３に従って、目標または標準からずれがない場合、管理サーバ１４によりいかなる動作も要求されず、管理サーバ１４は、図４において戻りループ１２０を介してアイドルループに戻る。

　アイドルループに関して示したように、アイドル状態にある管理サーバ１４は、監視チャネルライン３８を通して、ブレードサーバ３４に関連するサーバエージェント３５ａによって伝送される情報を介して、ブレードサーバ３４のパフォーマンスを監視している。
　ステップ１０４に従って、測定されたＱｏＳ属性が目標より下ではない場合、その測定されたＱｏＳ属性は目標より上であり、対象ＡＳＰ２０ａは、オーバプロビジョニングされており最適に動作していない。

　このため、過剰なサーバを他のＡＳＰ２０に利用可能とするために、対象ＡＳＰ２０ａのブレードサーバ能力を低減しなければならない。
　ポリシＤＢ４０において、動作に対して必要なオーバプロビジョニングの閾値を、動作に対する任意の頻度とともに指定することが可能である。

　ステップ１０４に従って、測定されたＱｏＳ属性が目標または標準より下ではない場合、その測定されたＱｏＳ属性は標準または目標より上であり、管理サーバ１４による動作が実行される。
　ブロック１０５によって表すように、とられる動作は、管理サーバ１４が対象ＡＳＰ２０ａのブレードサーバ３４のうちの１つまたは複数を選択し、それまたはそれらを、対象ＡＳＰ２０ａに関連するＦＳＰ２４ａに戻すことである。

　ステップ１０５は、残りのブレードサーバ３４により多くの作業負荷を配置し、また対象ＡＳＰ２０ａに関連するＴＭＤ２８ａの再環境設定も要求する。
　ＴＭＤ２８ａを、管理サーバ１４により、選択されたブレードサーバをその現設定から取り除く環境設定コマンドを発行することによって再環境設定することができる。
　たとえば、ＴＭＤ２８ａが負荷分散装置である場合、管理サーバ１４は、負荷分散装置がトラフィックを向けるサーバのプールから、選択されたブレードサーバを取り除くように、負荷分散装置を再環境設定する。

　任意に、ブレードサーバ３４のうちの１つまたは複数の使用または可用性がＦＳＰ２４ａに戻される前に、１つまたは複数のブレードサーバ３４のアドレス可能なメモリおよび記憶域をフラッシュまたはクレンジングすることができ、そのため、ＡＳＰ２０ａにおいてサービスするために呼び出された場合、アドレス可能なメモリおよび記憶域のすべてが、任意のアプリケーションまたはサービス要求を実行する際に、およびセキュリティ対策としても使用可能となる。
　管理サーバ１４によってブレードサーバ選択プロセスが実行され、１つまたは複数の選択されたブレードサーバ３４がＦＳＰ２４ａに戻された後、管理サーバ１４は、図４において戻りループ１２４を介してアイドルループに戻る。

　ステップ１０４によって行われる判断に従って、総ＱｏＳ属性が目標より下である場合、ブレードサーバプロビジョニングステップを実行しなければならない。
　プロビジョニングのためのブレードサーバの数を、定義された標準または目的からの総ＱｏＳ属性のずれの重大度、プロビジョニングの頻度、および他の任意の所望の要素とともに、ポリシＤＢ４０において事前定義することができる。

　ブレードサーバプロビジョニングステップは、ステップ１０６に従って、ＦＳＰ２４ａが対象ＡＳＰ２０ａに引き込むために利用可能な１つまたは複数のブレードサーバ３４を有するか否かを判断することを含む。
　ＦＳＰ２４ａにおいていずれのブレードサーバ３４も利用可能でない場合、すべて、以降まったく同一のことばで繰り返されるかのように引用をもって開示内容がすべて本明細書に援用されたものとする、上述した米国特許出願第０９／５６２，５９０号、同第０９／４９３，７５３号および同第１０／２０６，５９４号に例示され、詳細に説明されているように、ステップ１０７に従って、ブレードサーバ選択アルゴリズムが呼び出され、優先度の低いＡＳＰ１２からの１つまたは複数のブレードサーバ３４から特定がなされる、ブレードサーバ選択プロセスが実行される。

　より詳細には、および米国特許出願第１０／２０６，５９４号に開示されているように、パーティション負荷マネージャまたはそれぞれのＡＳＰアプリケーションプラグイン７０は、システムの関連するＡＳＰ２０から資源要求情報を受け取る。
　ＡＳＰアプリケーションプラグイン７０は、好ましくは、資源要求情報を検査し、その要求情報を利用可能な資源と比較する。

　比較に基づき、ＡＳＰアプリケーションプラグイン７０は、特定のＡＳＰの資源を増大させ、低減させることができ、または変更しなくてよい。
　ＡＳＰ２０のパフォーマンスが遅延している場合（たとえば、トランザクションが目標より長くかかっている場合）、ＡＳＰ２０は、ＡＳＰアプリケーションプラグイン７０に対し、資源の権利を増大させるよう要求することができる。

　ＡＳＰ２０が標準以上の結果を達成している場合、ＡＳＰアプリケーションプラグイン７０は、ＡＳＰアプリケーションプラグイン７０に対してそれが過剰な資源を有していることを通知し、その権利を低減し、それを１つまたは複数のＡＳＰ２０に割り当てることができる。
　ＡＳＰ２０のサイズを変更するために、ブレード負荷マネージャ（すなわち、管理サーバ１４）によって提供される命令に基づいて、１つまたは複数のブレードサーバ３４から１つまたは複数の他のブレードサーバ３４に資源を移動させる、アロケータ（図示せず）を設けることができる。

　管理サーバ１４は、ユーザまたは管理者から目標情報と優先度情報とを受け取る。
　かかる目標および優先度情報は、各ＡＳＰ２０のすべてのブレードサーバ３４に対して同じである可能性があり、あるいはいかなるそれぞれのＡＳＰ２０の各ブレードサーバ３４またはブレードサーバ３４のグループに対しても特有である可能性がある。
　また、管理サーバ１４は、パフォーマンスモニタから、各ＡＳＰ２０内のブレードサーバ３４の各々の中のアプリケーションのパフォーマンスを監視するプロセスである、追加の情報も受け取る。

　管理サーバ１４は、パフォーマンスモニタからの情報を検査し、その情報を目標と比較する。
　管理サーバ１４は、比較に基づき、アプリケーションの権利を増大させ、低減ることができ、あるいは変更しなくてよい。
　アプリケーションの性能が遅延している場合、たとえばトランザクションが目標より長くかかっている場合、管理サーバ１４は権利を増大させる。
　アプリケーションが標準以上の結果を達成している場合、管理サーバ１４は、その権利を低減させ、それを別のアプリケーションに割り当てる。

　このように、管理サーバ１４は、コンピュータ資源に関連するそれぞれのＡＳＰ２０のブレードサーバ３４に割り当てられた少なくとも１つの優先度に基づいて、コンピュータ資源に対する資源要求値を確定することができる。
　管理サーバ１４は、それぞれの資源要求値に基づいてそれぞれのＡＳＰ２０の各ブレードサーバ３４に対し割当値を形成するように動作可能であり、それによってラック・ブレードコンピューティングシステムの実施形態は、割当値に基づいてＡＳＰ２０間でコンピュータ資源を割り当てる。

　なお、管理サーバ１４はまた、それぞれのＡＳＰアプリケーションプラグイン７０とも対話する。
　管理サーバ１４は、各ＡＳＰ２０を含むシステムの資源要求を確定した後、資源要求情報を各ＡＳＰアプリケーションプラグイン７０に周期的に送信し、それによってＡＳＰアプリケーションプラグイン７０は、資源要求情報を受け取った後、それぞれのＡＳＰ２０間でシステム資源を割り当てる。
　管理サーバ１４は、ＡＳＰ２０の資源に関する情報を受け取る。

　それぞれのＡＳＰアプリケーションプラグイン７０が１つのＡＳＰ２０に対して存在するが、各ＡＳＰアプリケーションプラグイン７０は、他のＡＳＰアプリケーションプラグイン７０にアクセスすることができる。
　代替的に、ＡＳＰアプリケーションプラグイン７０は、ラック１２のＡＳＰ２０のすべてを管理するサービスモジュールに存在してよい。
　さらに代替的に、および上述したように、いかなるＡＳＰアプリケーションプラグイン７０が各ＡＳＰ２０に存在してもよく、協働してそれぞれ含まれるブレードサーバ３４間で資源を割り当ててよい。

　先に示したように、ＡＳＰアービタまたは資源アロケータ（図示せず）が、ＡＳＰ２０の優先度と資源要求とに基づいてあらゆるＡＳＰ２０間で資源を割り当てる。
　この資源の移動を、ＡＳＰ２０のサイズ変更と呼んでよい。
　ＡＳＰ２０は、好ましくは管理サーバ１３を通して、各要求された資源の量の指示を含む優先順位付きのアプリケーション目標のリストを維持する。

　優先度の等しいアプリケーション目標は等しく処理される。
　アプリケーションは複数の目標を有してよい。
　優先度の高いアプリケーション目標の要求は、優先度の低いアプリケーション目標より前に満足される。
　未割当資源を、予備として保持してもデフォルトパーティションに割り当ててもよい。
　なお、デフォルトＡＳＰ２０のアプリケーションが常にその目標を超えている可能性があり、そのため、かかる状況が資源の再割当またはＡＳＰ２０のサイズ変更をもたらすイベントではないという規則が必要な場合がある。

　したがって、ステップ１０７によって表される選択プロセスは、同じラック１２（たとえば、ラック１２ａ）の他のＡＳＰ２０ａの相対パフォーマンスを、それらの優先度とともに見ることにより、別のＡＳＰ２０ａに再割り当てされた場合に最も少なくパフォーマンスに影響を与える１つまたは複数のブレードサーバ３４ａを特定する。

　ステップ１０７に従って１つまたは複数のブレードサーバ３４ａが選択された後、選択されたブレードサーバ３４ａは、フラッシュされ、その後再プロビジョニングの用意がなされる。
　ステップ１０６に従って１つまたは複数の利用可能なブレードサーバがＦＳＰ２４ａから選択されると、それまたはそれらもまた再プロビジョニングされなければならない。

　任意のブレードサーバ（すなわち、ステップ１０７に従って選択されたブレードサーバか、またはステップ１０６に従ってＦＳＰ２４ａから選択された利用可能なブレードサーバ）を再プロビジョニングするために、ステップ１０９に従って、選択されたブレードサーバは、ラピッドデプロイメントシステム５０のラピッドデプロイメントサービスによって最初に再度目的を持たされる（repurposed）（たとえば、適当なソフトウェアのインストールおよび環境設定）必要がある。
　より詳細には、ラピッドデプロイメントシステム５０は、オペレーティングシステムおよびアプリケーションの新たなイメージをインストールすることにより、ブレードサーバに対する新たなパーソナリティを生成する。
　さらに、ラピッドデプロイメントシステム５０は、いずれかの特定のブレードサーバを環境設定し、それをサービスのために用意する。

　先に示したように、イメージリポジトリ４８に格納されたイメージは、アプリケーションとともにオペレーティングシステムのディスクイメージを含んでよい。
　ラピッドデプロイメントシステム５０は、イメージリポジトリ４８からイメージビットを取り除き、それらを、環境設定およびブートの用意をするためにブレードサーバのハードディスクにコピーする。
　このように、適当なイメージを、イメージリポジトリ４８から選択し、その後１つまたは複数の選択されたブレードサーバ３４にインストールすることができる。

　その後、１つまたは複数の選択されたブレードサーバに再度目的を持たせるための、環境設定と、ラピッドデプロイメントシステム５０からのラピッドデプロイメントサービスの呼出しとの後、ステップ１１０に従って、再度目的を持たされ環境設定された１つまたは複数の選択されたブレードサーバ３４は、その後動作する用意がなされる。
　ブレードサーバに対して動作の用意をすることは、イメージがインストールされた後、およびブレードサーバが用意ができていると宣言される前に実行される必要のある、任意の環境設定動作を含む。

　最後に、ステップ１１１に従って、用意ができた、再度目的が持たされた、環境設定されたブレードサーバ３４を使用するために受け取ったＡＳＰ２０ａが関連する適当なＴＭＤ２８ａ自体が、この時ＡＳＰ２０ａにおいて使用することができる余分な、または追加された１つまたは複数のブレードサーバ３４を考慮するように、再環境設定される。
　ステップ１１１の後、管理サーバ１４は、図４における戻りループ１２８を介してアイドルループに戻る。

　このように、本発明のあらゆる実施形態の実施により、ＡＳＰ２０（たとえば、ＡＳＰ２０ａ）は、それらのそれぞれのラック１２（たとえば、ラック１２ａ）に存在しているブレードサーバ３４の数を増大させるか、または減少させるのみである。
　いかなるブレードサーバの選択も、ラック境界のいずれをも越えない。
　ブレードサーバの選択はすべて、それぞれのラック１２内において自己完結する。

　ブレードサーバ選択およびラピッドデプロイメントツールは、それぞれのラック１２内で利用可能な統合管理インフラストラクチャを利用するが、それぞれのラック１２を越えない。
　しかしながら、管理サーバ１４は、複数のラック１２においてＡＳＰ２０を動的にプロビジョニングしながら、すべてのラック１２のすべてのＡＳＰ２０に関する情報を受け取り維持する。
　また、本発明のあらゆる実施形態の実施により、適応制御は、ネットワーク（たとえば、ＬＡＮ１６）に連結されたブレードサーバを越えて動作し、水平にスケーリング可能なサービスまたはアプリケーションに関連するブレードサーバ能力を調整するタスクを自動化する。

　本明細書を通して、「一実施形態」、「実施形態」または「特定の実施形態」に対する言及は、実施形態に関連して説明した特定の特徴、構造または特性が本発明の少なくとも１つの実施形態に含まれるが、必ずしもすべての実施形態には含まれないことを意味する。
　このように、本明細書を通してあらゆる場所での「一実施形態において」、「実施形態において」または「特定の実施形態において」という句のそれぞれの出現は、必ずしも同じ実施形態を言及していない。

　さらに、本発明のいかなる特定の実施形態の特定の特徴、構造または特性も、任意の適当な方法で１つまたは複数の他の実施形態と結合し得る。
　当然ながら、本明細書の教示に鑑みて、本明細書で説明し例示した本発明の実施形態の他の変形形態および変更形態が可能であり、それらを本発明の精神および範囲の一部として考慮すべきである。

　さらに、プログラムされた汎用デジタルコンピュータを使用することにより、特定用途向け集積回路、プログラマブルロジックデバイスまたはフィールドプログラマブルゲートアレイを使用することにより、あるいは相互接続されたコンポーネントおよび回路のネットワークを使用することにより、本発明の実施形態のコンポーネントの少なくともいくつかを実施することができる。
　接続は、有線であっても、無線であっても、モデムによっても、その他同種類のものであってもよい。

　また、図面／図に示す要素のうちの１つまたは複数を、特定の適用に従って有用であるように、より分離された、または統合された方法で実施することも、場合によっては実行不可能であるとして取り除くか、または放棄することも可能である、ということも認められよう。
　また、コンピュータが上述した方法のいずれかを実行することができるように、機械読取可能媒体に格納することができるプログラムまたはコードを実施することも、本発明の精神および範囲内にある。

　さらに、図面におけるいかなる信号矢印も、特に断りのない限り、単に例示的であって限定するものとみなすべきではない。
　さらに、本明細書で使用する「または（or）」は、特に断りのない限り、概して「および／または」を意味することが意図されている。
　また、コンポーネントまたはステップの組合せは、示されているようにも考慮され、そこでは用語は、分離または結合の可能性が不明瞭であるように表しているように予測される。

　本明細書の説明においておよび特許請求の範囲を通して使用するように、「１つの（a、an）」および「その（the）」は、文脈上明らかに他の意味を示す場合を除き複数の言及を含む。
　また、本明細書の説明において、および特許請求の範囲を通して、「内（in）」の意味は、文脈上明らかに他の意味を示す場合を除き「内」と「上（on）」とを含む。

　要約書に述べられていることを含む、本発明の例示した実施形態の上述した説明は、網羅的であるように、および発明を本明細書で開示した厳密な形態に限定するようには意図されていない。
　本明細書では、発明の特定の実施形態および発明の実施例を、単に例示の目的のみのために説明するが、当業者が理解し認めるように、本発明の精神および範囲内においてあらゆる等価な変更形態が可能である。
　示したように、これらの変更形態を、本発明の例示した実施形態の上記説明に鑑みて本発明に対して行うことができ、それらは、本発明の精神および範囲内に含まれるものである。

　このように、本明細書では本発明をその測定の実施形態に関して説明したが、上記開示にはある範囲の変更形態、あらゆる変更形態および代用形態があるように意図され、場合によっては本発明の実施形態のいくつかの特徴は、示すような本発明の範囲および精神から逸脱することなく他の特徴の対応する使用なしに使用される、ということが認められよう。
　したがって、特定の状況または材料を本発明の本質的な範囲および精神に適応させるように、多くの変更を行うことができる。
　本発明は、特許請求の範囲で使用される特定の用語および／またはこの発明を実施するために考えられる最良の形態として開示された特定の実施形態に限定されず、添付の特許請求項の範囲内にある任意の、およびすべての実施形態と等価物とを含む、ということが意図されている。

　本発明は、ラック・ブレードコンピュータアセンブリのコンピューティング資源を自動的に割り当てるために利用可能である。

各々が少なくとも１つのアプリケーションサーバプール（ＡＳＰ）を含む複数のラックの概略図である。 ラック・ブレードコンピューティングシステムと、コンピューティング資源（たとえば、ブレードサーバ）がコンピュータ作業負荷にいかに割り当てられるかを自動化する方法との実施形態に対するソフトウェアデータベースの概略図である。 ラピッドデプロイメントシステムを含み、イメージリポジトリとアプリケーションサーバプールのブレードサーバとに通信可能に関係する、管理サーバの概略図である。 本発明の実施形態を動作させる制御システムのブロックフローチャートである。

符号の説明

１０・・・ラック・ブレードコンピューティングシステム、
１２・・・ラック、
１４・・・管理サーバ、
１６・・・ＬＡＮ、
２０・・・アプリケーションサーバプール（ＡＳＰ）、
２４・・・フリーサーバプール（ＦＳＰ）、
２８・・・トラフィック管理装置（ＴＭＤ）、
３０・・・ローカルＬＡＮ、
３４・・・ブレードサーバ、
３５・・・サーバエージェント、
３６・・・チャンネルライン、
３８・・・監視チャネルライン、
４０・・・ポリシデータベース、
４８・・・イメージリポジトリ、
５０・・・ラピッドデプロイメントシステム、
６０・・・プロビジョニングライン、
７０・・・アプリケーションプラグイン、

Claims (10)

1. 　ラック・ブレードコンピュータアセンブリのコンピューティング資源を自動的に割り当てる方法であって、
   　ラック・ブレードコンピュータアセンブリのラックに配置されたアプリケーションサーバプールからサーバパフォーマンス情報を受け取ることと、
   　前記アプリケーションサーバプールに対する少なくとも１つのＱｏＳ属性を確定することと、
   　前記ＱｏＳ属性が標準より下であると確定することと、
   　前記アプリケーションサーバプールによって使用されるためにフリーサーバプールからブレードサーバを割り当てることと
   　を含む方法。
2. 　ラック・ブレードコンピュータアセンブリのコンピューティング資源を自動的に割り当てる方法であって、
   　ラック・ブレードコンピュータアセンブリのラックに配置されたアプリケーションサーバプールからサーバパフォーマンス情報を受け取ることと、
   　前記アプリケーションサーバプールに対する少なくとも１つのＱｏＳ属性を確定することと、
   　前記ＱｏＳ属性が標準より上であると確定することと、
   　前記アプリケーションサーバプールからブレードサーバの使用を取り除くことと
   　を含む方法。
3. 　ラック・ブレードコンピュータアセンブリのコンピューティング資源を自動的に割り当てる方法であって、
   　ラック・ブレードコンピュータアセンブリのラックに配置されたアプリケーションサーバプールからサーバパフォーマンス情報を受け取ることと、
   　前記アプリケーションサーバプールに対する少なくとも１つのＱｏＳ属性を確定することと、
   　前記ＱｏＳ属性が標準より下であると確定することと、
   　フリーサーバプールのいずれのブレードサーバも使用することができないと確定することと、
   　前記アプリケーションサーバプールによって使用されるために優先度の低いブレードサーバを選択することと
   　を含む方法。
4. 　請求項１記載の方法に従って生成されたアプリケーションサーバプール。
5. 　請求項２記載の方法に従って生成されたアプリケーションサーバプール。
6. 　請求項３記載の方法に従って生成されたアプリケーションサーバプール。
7. 　ラック・ブレードコンピュータアセンブリのコンピューティング資源を自動的に割り当てる方法であって、
   　ラック・ブレードコンピュータアセンブリのラックに配置されたアプリケーションサーバプールからサーバパフォーマンス情報を受け取ることと、
   　前記アプリケーションサーバプールに対する少なくとも１つのＱｏＳ属性を確定することと、
   　前記ＱｏＳ属性が標準より下であると確定することと、
   　フリーサーバプールが使用するためのブレードサーバを有すると確定することと、
   　前記フリーサーバプールから、前記アプリケーションサーバプールによって使用可能なブレードサーバを選択することと
   　を含む方法。
8. 　製品であって、
   　ラック・ブレードコンピュータアセンブリのラックに配置されたアプリケーションサーバプールからサーバパフォーマンス情報を受け取る命令と、
   　前記アプリケーションサーバプールに対する少なくとも１つのＱｏＳ属性を確定する命令と、
   　前記ＱｏＳ属性が標準より下であると確定する命令と、
   　フリーサーバプールのいずれのブレードサーバも使用することができないと確定する命令と、
   　前記アプリケーションサーバプールによって使用されるために優先度の低いブレードサーバを選択する命令と
   　が格納されている機械読取可能媒体を具備する物品。
9. 　ラック・ブレードコンピュータアセンブリのコンピューティング資源を自動的に割り当てるシステムであって、
   　管理サーバと、
   　該管理サーバに連結されたラピッドデプロイメントシステムと、
   　前記管理サーバに連結されたラック・ブレードコンピュータシステムと
   　を具備するシステム。
10. 　ラック・ブレードコンピュータアセンブリのコンピューティング資源を自動的に割り当てるシステムであって、
    　ラック・ブレードコンピュータアセンブリからブレードサーバパフォーマンス情報を受け取る手段と、
    　ブレードサーバパフォーマンス情報を受け取る前記手段に連結され、イメージリポジトリを管理する手段と
    　を具備するシステム。

Images