特許第6853829号(P6853829)IP Force 特許公報掲載プロジェクト 2015.5.11 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ インターナショナル・ビジネス・マシーンズ・コーポレーションの特許一覧
特許6853829非集約型計算システムを実現するための方法、装置、コンピュータ・プログラム製品、およびデータセンタ・ファシリティ
<>
  • 特許6853829-非集約型計算システムを実現するための方法、装置、コンピュータ・プログラム製品、およびデータセンタ・ファシリティ 図000002
  • 特許6853829-非集約型計算システムを実現するための方法、装置、コンピュータ・プログラム製品、およびデータセンタ・ファシリティ 図000003
  • 特許6853829-非集約型計算システムを実現するための方法、装置、コンピュータ・プログラム製品、およびデータセンタ・ファシリティ 図000004
  • 特許6853829-非集約型計算システムを実現するための方法、装置、コンピュータ・プログラム製品、およびデータセンタ・ファシリティ 図000005
  • 特許6853829-非集約型計算システムを実現するための方法、装置、コンピュータ・プログラム製品、およびデータセンタ・ファシリティ 図000006
  • 特許6853829-非集約型計算システムを実現するための方法、装置、コンピュータ・プログラム製品、およびデータセンタ・ファシリティ 図000007
  • 特許6853829-非集約型計算システムを実現するための方法、装置、コンピュータ・プログラム製品、およびデータセンタ・ファシリティ 図000008
  • 特許6853829-非集約型計算システムを実現するための方法、装置、コンピュータ・プログラム製品、およびデータセンタ・ファシリティ 図000009
  • 特許6853829-非集約型計算システムを実現するための方法、装置、コンピュータ・プログラム製品、およびデータセンタ・ファシリティ 図000010
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6853829
(24)【登録日】2021年3月16日
(45)【発行日】2021年3月31日
(54)【発明の名称】非集約型計算システムを実現するための方法、装置、コンピュータ・プログラム製品、およびデータセンタ・ファシリティ
(51)【国際特許分類】
   G06F 9/50 20060101AFI20210322BHJP
【FI】
   G06F9/50 120A
【請求項の数】12
【全頁数】26
(21)【出願番号】特願2018-547898(P2018-547898)
(86)(22)【出願日】2017年3月9日
(65)【公表番号】特表2019-511051(P2019-511051A)
(43)【公表日】2019年4月18日
(86)【国際出願番号】IB2017051383
(87)【国際公開番号】WO2017175079
(87)【国際公開日】20171012
【審査請求日】2019年8月19日
(31)【優先権主張番号】15/093,082
(32)【優先日】2016年4月7日
(33)【優先権主張国】US
(73)【特許権者】
【識別番号】390009531
【氏名又は名称】インターナショナル・ビジネス・マシーンズ・コーポレーション
【氏名又は名称原語表記】INTERNATIONAL BUSINESS MACHINES CORPORATION
(74)【代理人】
【識別番号】100108501
【弁理士】
【氏名又は名称】上野 剛史
(74)【代理人】
【識別番号】100112690
【弁理士】
【氏名又は名称】太佐 種一
(72)【発明者】
【氏名】シェンフェルト、オイゲン
(72)【発明者】
【氏名】サラプラ、ヴァレンティーナ
(72)【発明者】
【氏名】マヒンドル、ルチ
(72)【発明者】
【氏名】ビヴェンス、ジョン、アラン
(72)【発明者】
【氏名】ラマサミ、ハリゴヴィンド、ヴェンカトラージュ
(72)【発明者】
【氏名】ルアン、ヤオピン
(72)【発明者】
【氏名】リー、ミン
(72)【発明者】
【氏名】ダス、コウシク
【審査官】 田中 幸雄
(56)【参考文献】
【文献】 米国特許出願公開第2015/0381426(US,A1)
【文献】 特開2012−161033(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 9/50
(57)【特許請求の範囲】
【請求項1】
計算環境内でリソースを割り当てるための方法であって、
サーバ・リソース・プールのセットを提供するステップであって、サーバ・リソース・プールが一般的な種類のリソースのセットを含んでいる、前記提供するステップと、
要求の受信に応答して、前記サーバ・リソース・プールのうちの2つ以上から選択された1つまたは複数のリソースで構成されたサーバ・エンティティを定めるステップであって、前記1つまたは複数のリソースが、前記要求に関連付けられた予測されたワークロードに基づいて、前記サーバ・リソース・プールのうちの前記2つ以上から選択される、前記定めるステップと、
前記ワークロードが処理されるときに前記1つまたは複数のリソースを監視するステップから収集された情報を受信するステップと、
前記監視するステップに基づいて、前記ワークロードにおける変更に応じて、前記サーバ・エンティティの構成を調整するステップと、
一意のサーバ識別子を前記サーバ・エンティティに関連付けるステップであって、前記一意のサーバ識別子が、選択された前記1つまたは複数のリソースのそれぞれにも関連付けられる、前記関連付けるステップと、
前記サーバ・エンティティの前記構成の調整を反映するように前記一意のサーバ識別子を更新するステップと
を含む、方法。
【請求項2】
前記サーバ・リソース・プールを共有した共有サーバ・リソース・プールであって、前記共有サーバ・リソース・プールが、計算プールおよびメモリ・プールのうちの少なくとも1つである、請求項1に記載の方法。
【請求項3】
前記サーバ・エンティティの前記構成が、サーバ・リソース・プールの1つまたは複数のリソースを前記サーバ・エンティティに追加するステップによって調整される、請求項1に記載の方法。
【請求項4】
前記サーバ・エンティティに追加される前記1つまたは複数のリソースが、前記サーバ・エンティティ内にすでに存在する他の前記リソースに対するリソースのネットワーク局所性に基づいて選択される、請求項に記載の方法。
【請求項5】
前記サーバ・エンティティの前記構成が、サーバ・リソース・プールの1つまたは複数のリソースを前記サーバ・エンティティから削除するステップによって調整される、請求項1に記載の方法。
【請求項6】
前記サーバ・エンティティから削除された前記1つまたは複数のリソースを前記サーバ・リソース・プールに戻すステップをさらに含む、請求項に記載の方法。
【請求項7】
前記一意のサーバ識別子を、前記ワークロードに関連付けられたサービス要求に関連付けるステップと、
特定のリソースで、前記特定のリソースに関連付けられた同じ一意のサービス識別子に前記サービス要求が関連付けられているというステップの決定時に、前記サービス要求に対してサービスを提供するステップ
をさらに含む、請求項に記載の方法。
【請求項8】
請求項1〜7の何れか1項に記載の方法の各ステップをコンピュータ・ハードウェアによる手段として構成した、装置。
【請求項9】
請求項1〜7の何れか1項に記載の方法の各ステップをコンピュータに実行させる、コンピュータ・プログラム。
【請求項10】
請求項9に記載の前記コンピュータ・プログラムを、コンピュータ可読ストレージ媒体に記録した、ストレージ媒体。
【請求項11】
データセンタ・ファシリティであって、
サーバ・リソース・プールのセットであって、前記サーバ・リソース・プールが少なくとも計算プールおよびメモリ・プールを含んでいる、前記サーバ・リソース・プールのセットと、
前記計算プールから選択されたプロセッサ、前記メモリ・プールから選択されたコンピュータ・メモリ、および光相互接続を備えている少なくとも1つの非集約型計算システムと、
前記非集約型計算システムを定める一意のサーバ識別子を格納するデータベースであって、前記一意のサーバ識別子が、前記データベース内で、前記非集約型計算システム内の前記プロセッサおよびコンピュータ・メモリごとの識別子に関連付けられている、前記データベースと、
前記非集約型計算システムにおけるワークロードの変化に応答して、ワークロードの必要量に従って、前記非集約型計算システムの前記プロセッサまたは前記コンピュータ・メモリの構成を選択的に調整する、追跡システムと
を備えており、
前記一意のサーバ識別子が、前記非集約型計算システムの前記構成の調整を反映するように前記データベース内で更新される、データセンタ・ファシリティ。
【請求項12】
局所性、予想されるワークロードへの最良の適合性、および前記データセンタ・ファシリティに関連する将来の拡張要件のうちの1つに基づいて、前記プロセッサおよびコンピュータ・メモリが選択される、請求項11に記載のデータセンタ・ファシリティ。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、データセンタ運用環境内のデータ処理システムに一般に関する。
【背景技術】
【0002】
よく知られた情報技術(IT:information technology)配信モデルは、クラウド・コンピューティングである。クラウド・コンピューティングによって、共有されたリソース、ソフトウェア、および情報が、インターネットを経由してオンデマンドでコンピュータおよびその他のデバイスに提供される。クラウド・コンピューティングは、ITのコストおよび複雑性を大幅に低減しながら、ワークロード最適化およびサービス配信を改善する。このアプローチでは、アプリケーション・インスタンスがホストされ、例えばHTTP経由で従来のWebブラウザを介して、アクセス可能なインターネットベースのリソースから利用可能になる。クラウドの計算リソースは、通常は仮想化アーキテクチャを使用して、1つまたは複数のネットワーク・アプリケーションを実行する大規模なサーバ・ファームに収容されることが多い。仮想化アーキテクチャでは、アプリケーションは、データセンタ・ファシリティ内の物理サーバにマッピングされた仮想サーバまたはいわゆる「仮想マシン」(VM:virtual machine)内で実行される。
【0003】
データセンタ自体の内部では、データセンタのネットワークが、通常は、電気的スイッチの複数の層(つまり、アクセス層、集約層、およびコア層)を含んでいる階層設計に従って設計される。データセンタのフロント・エンドでは、コンテンツおよび負荷バランシング・スイッチ(content and load balancing switches)がゲートウェイ・ルータを介してインターネットに接続され、一方、バック・エンドでは、それらがコア・スイッチにリンクされる。通常、コア・スイッチは集約スイッチにリンクされ、集約スイッチはラック・スイッチに接続される。各ラック・スイッチは、ラック内のサーバに接続される。データセンタのネットワーク内のスイッチは、通常は電子スイッチ・ファブリック(electronic switch fabric)上で動作し、それらのスイッチ間のリンクは、銅ケーブルまたは光ファイバのいずれかである。外部ネットワークから要求が来た場合、その要求は、最初に負荷バランシングおよびコンテンツ・スイッチ(load balancing and content switches)に到達し、負荷バランシングおよびコンテンツ・スイッチは、要求を適切なサーバにルーティングする。要求を満たすために、サーバは、同じラックまたは異なるラック内の他のサーバと協調することができる。例えば、アプリケーション・サーバは、データベース・サーバと協調して、要求を処理することができる。要求の完了後に、応答がゲートウェイ・ルータを介して外部ネットワークに送信される。
【0004】
説明したような従来のデータセンタ・アーキテクチャは、スケーラビリティ、フォールト・トレランス、およびエネルギー効率を含むが、これらに限定されない、多くの課題に直面している。その結果、多くのデータセンタは、クラウド・コンピューティングの需要の増大に対処することに苦労している。
【0005】
データセンタの性能は、データセンタを構成しているハードウェア・システムの性質による影響も受ける。現在、ハードウェア・システムは、事前に定められた数のCPUおよびメモリと共に、事前にパッケージ化されており、このことが柔軟性を制限している。例えば、標準的な仮想マシンの環境では、仮想CPUの数が定められ、メモリが割り当てられる。そのような環境では、仮想CPUの数は変更できるが、どの物理CPUが使用されるかを指定する手段も、物理CPUの数を増やす方法を指定する手段もない。
【0006】
さらに、多くの場合、ダウンタイムおよび顧客への影響を生じさせずに、仮想能力および非仮想能力を調整できるように、物理ハードウェアの能力を動的にスケールアップまたはスケールダウンする必要がある。例えば、メモリ内の列指向リレーショナル・データベース管理システム(例えば、HANAサーバ)を含んでいるアプリケーション・サーバの場合を考える。非仮想環境内で、より多くのCPUまたはその他のリソースを、そのようなサーバに追加することが望まれる場合、より多くのリソースを動的に追加できるのではなく、ハードウェア・ボックスを構築する必要がある。ハイパーバイザの能力は、通常、基盤になるハードウェア・ボックスの能力に制限されるため、仮想環境において、同様の問題が存在する。
【0007】
データセンタのリソースのプロビジョニングのための別の既知のアプローチでは、製造業者によって事前に組み立てられた特定のコンポーネントを含んでいる構築済みのサーバを使用する。このアプローチでは、データセンタの顧客はオプション(サーバがどのリソースを保有するべきかの識別を含む)のメニューのリストから選択することができるが、通常は、望ましい特徴を有している最も近いボックスをユーザが手動で選択することによって、照合が行われる。しかし、選択されたボックスが使用不可能であることがあり、その場合、顧客の必要性を満たすために、より高価なボックスが使用される。このプロセスは、リソース(すなわち、プロセッサの種類、メモリ、ストレージGPU(storage GPU)など)の多くの可能な組み合わせをそれぞれが保有しているさまざまな種類のサーバの巨大なインベントリである各物理データセンタでの可用性を必要とする。これは、コストおよびリソース管理の観点から望ましくない。さらに、そのようなインベントリを利用できる場合でも、選択およびプロビジョニングのプロセスは、時間がかかり、複雑である。
【先行技術文献】
【非特許文献】
【0008】
【非特許文献1】“Draft NIST Working Definition of Cloud Computing” by Peter Mell and Tim Grance, dated October 7, 2009
【発明の概要】
【発明が解決しようとする課題】
【0009】
したがって、従来技術に関連するこれらおよびその他の問題に対処するための手法を提供する必要性が残されている。従って、解決しようとする課題は非集約型計算システムを実現する手法を提供することである。
【課題を解決するための手段】
【0010】
本開示の第1の態様によれば、計算環境内のリソースを割り当てるための方法が提供される。この方法は、サーバ・リソース・プール(server resource pool)のセットを提供することから開始し、サーバ・リソース・プールは、一般的な種類のリソースのセット(例えば、計算プール(compute pool)、メモリ・プールなど)を含んでいる。要求の受信に応答して、サーバ・エンティティが定められる。サーバ・エンティティは、サーバ・リソース・プールのうちの1つまたは複数から選択された1つまたは複数のリソースで構成される。要求に関連する予測されたワークロードに基づいて、1つまたは複数のリソースが、サーバ・リソース・プールのうちの1つまたは複数から選択される。その後、ワークロードが処理されるときに、ワークロードとしての1つまたは複数のリソースを監視することから収集された情報が受信される。監視することから収集された情報に基づいて、ワークロードにおける変更に応じて、サーバ・エンティティの構成が調整される。
【0011】
好ましくは、一意のサーバ識別子がサーバ・エンティティに関連付けられ、追跡の目的に使用される。一意のサーバ識別子は、サーバ・エンティティに対して選択された各リソースにも関連付けられる。一意の識別子は、サーバ・エンティティの構成の調整を反映するように更新される。
【0012】
本開示の第2の態様によれば、計算環境内のリソースを割り当てるための装置が説明される。この装置は、1つまたは複数のハードウェア・プロセッサのセットと、前述したステップなどの一連の処理を実行するためにハードウェア・プロセッサによって実行されるコンピュータ・プログラム命令を保持するコンピュータ・メモリとを備える。
【0013】
本開示の第3の態様によれば、計算環境内のリソースを割り当てるためにデータ処理システムにおいて使用される、非一時的コンピュータ可読媒体内のコンピュータ・プログラム製品が説明される。コンピュータ・プログラム製品は、データ処理システムにおいて実行され、前述のステップなどの処理を実行するように機能するコンピュータ・プログラム命令を保持する。
【0014】
本開示の第4の態様によれば、データセンタ・ファシリティが説明される。このデータセンタは、サーバ・リソース・プールのセット、非集約型計算システム(disaggregated compute system)、データベース、および追跡システムを備える。これらのサーバ・リソース・プールは、少なくとも計算プールおよびメモリ・プールを含む。この非集約型計算システムは、計算プールから選択されたプロセッサ、メモリ・プールから選択されたコンピュータ・メモリ、および光相互接続を備える。このデータベースは、非集約型計算システムを定める一意のサーバ識別子を格納する。この一意のサーバ識別子は、データベース内で、非集約型計算システム内のサーバに割り当てられた各リソース(例えば、プロセッサおよびコンピュータ・メモリ)の識別子に関連付けられる。追跡システムは、非集約型計算システムにおけるワークロードの変化に応答して、ワークロードの必要量に従って、非集約型計算システムのプロセッサまたはコンピュータ・メモリの構成を選択的に調整する。動作中に、一意のサーバ識別子は、非集約型計算システムの構成の調整を反映するようにデータベース内で更新される。
【0015】
好ましくは、オプションの態様として、前述のデータセンタ内で、局所性、予想されるワークロードへの最良の適合性、およびデータセンタ・ファシリティに関連する将来の拡張要件のうちの1つに基づいて、プロセッサおよびコンピュータ・メモリが選択される。
【0016】
前述の手法および技術的特徴は、大きな利点を提供する。それらは、初期リソースが予測された必要性に基づいてデータセンタ内で適切に割り当てられること、およびダウンタイムがなく、顧客への影響を最小限に抑えるか、または顧客への影響がない、物理的または仮想的ハードウェア能力の動的スケールアップまたはスケールダウンを可能にする。サーバ・エンティティは、プロセッサのサブセット、メモリのサブセットなどの割り当てから構築されるので、ワークロードの処理に必要なリソースのみが使用される。さらに、スケールアップが必要な場合、システムは、低コストで良好な性能を継続的に保証するために、好ましくは局所性の考慮(すなわち、追加リソースが存在する場所)に基づいて、必要な追加リソースを取得する。このアプローチは非集約型サーバを利用するので、これらの利点によって、データセンタは、より大きいモジュール性、より高いリソース利用率、より低いコスト、およびより良い性能を実現できる。サーバ・エンティティが必要に応じて構築され、それらのエンティティを構成しているリソースも、オンデマンドで動的に変更される。このアプローチは、ワークロード要件との不一致またはワークロード要件の変更に起因して、含まれている1つまたは複数のリソースの利用率が低下した場合にリソースのフラグメンテーションが発生するという、従来のサーバの使用から生じるワークロード割り当ての問題を解決する。本明細書に記載された共有リソース・プールおよびリソース割り当て方法を使用することによって、ワークロードの要件に従ってそれらのリソース・プールから割り当てることにより、サーバが動的かつオンデマンドで構築される。
【0017】
以上では、開示される主題のより関連する特徴の一部について概説した。これらの特徴は、単に例であると解釈されるべきである。説明されるように、開示された主題を異なる方法で適用することによって、または主題を変更することによって、多くのその他の有益な結果を実現できる。
【0018】
主題および主題の利点をさらに完全に理解するために、ここで、添付の図面と併せて行われる以下の説明を参照する。
【図面の簡単な説明】
【0019】
図1】本開示の例示の態様が実装されてよい計算システム環境を示す例示のブロック図である。
図2】例示的な実施形態の態様が実装されてよい、光学的に接続されたメモリ・システムのハードウェア構造の例示のブロック図である。
図3図2の光学的に接続されたメモリ・システム内のプロセッサ設計のハードウェア構造を示すブロック図である。
図4】プロセッサでメモリにアクセスするためのハードウェア構造を示すブロック図である。
図5】本開示に記載された非集約型計算システムを示す図である。
図6】本開示の手法が実装されてよい代替のデータセンタ・アーキテクチャを示す図である。
図7】第1の実施形態に記載された、新規サーバ割り当てのプロセス・フローを示す図である。
図8】第2の実施形態に記載された、サーバ・スケールアップ・リソース割り当て方法(server scale-up resource allocation method)のプロセス・フローを示す図である。
図9】第3の実施形態に記載された、サーバ・スケールダウン・リソース割り当て方法(server scale-down resource allocation method)のプロセス・フローを示す図である。
【発明を実施するための形態】
【0020】
本開示の手法は、好ましくは、「非集約型」計算システムの文脈において実装され、「非集約型サーバ」(本明細書では、しばしば「サーバ・エンティティ」と呼ばれる)は、共有サーバ・リソース・プール(つまり、計算プール、メモリ・プール、アクセラレータ・プール(例えば、GPUアクセラレータ、ネットワーク・アクセラレータなど)、ストレージ・プールなどのうちの1つまたは複数)から選択された(または割り当てられた)サーバ・リソースで構成されるか、そのようなサーバ・リソースを構成する。名前が示すように、「計算」プールは通常、物理プロセッサ(CPUなど)を構成し、「メモリ」プールは通常、物理メモリ・デバイス(デュアル・インライン・メモリ・モジュール(DIMM:dual-inline-memory modules)など)を構成する、などとなっている。特定の共有プールは、好ましくは、特定のリソース・タイプのみを含むが、特定のリソース・プールは、1つまたは複数のリソース・サブタイプで構成されてよい。一般的なリソースが収集されるか、集約されるか、またはその他の任意の適切な方法で結合されてよいため、「プール」という概念は、制限することを意図していない。さらに「プール」は、一般的なタイプまたはサブタイプを持つリソースの専用のセットであるか、またはそのようなリソースの何らかの一時的な集合であってよい。好ましくは、特定のサーバ・エンティティは、サーバ・リソース・プールのうちの1つまたは複数からのサーバ・リソースを備える。
【0021】
好ましい実施形態では、下で説明されるように、本開示の内容が実践される非集約型計算システムは、メモリの(電気相互接続ではなく)光相互接続を利用するが、これに限定されない。
【0022】
通常、共有リソース・プールは、特定のデータセンタの物理的制約の範囲内で利用可能であるが、同様に、これに限定されない。したがって、共有リソース・プール自体が、物理データセンタ間で共有されてよい。さらに、特定のサーバ・エンティティが各サーバ・プールからのリソースで構成される必要はない。
【0023】
光学的に接続されたスイッチング・メモリ・アーキテクチャ(switching optically-connected memory architecture)
背景の目的で、ただし限定することを目的とせず、以下では、本開示の手法(下で説明される)が実践されてよい代表的なコンピュータ環境について説明する。
【0024】
ここで図1を参照すると、本開示の非集約型計算システムが実装されてよい計算環境の例示のアーキテクチャ10が示されている。コンピュータ・システム10は、通信ポート18およびメモリ・デバイス16に接続された中央処理装置(CPU:central processing unit)を含んでいる。通信ポート18は、通信ネットワーク20と通信する。通信ネットワーク20およびストレージ・ネットワークは、サーバ(ホスト)24および22、ならびにストレージ・システム14を含んでよいストレージ・システムと通信するように構成されてよい。ストレージ・システムは、ハード・ディスク・ドライブ(HDD:hard disk drive)デバイス、半導体デバイス(SSD:solid-state device)などを含んでよく、新磁気ディスク制御機構(RAID:redundant array ofindependent disks)で構成されてよい。下で説明されるような処理は、システム10内または他の場所にあるストレージ・デバイス14上で実行されてよく、他のCPUデバイス12から独立して、または他のCPUデバイス12と連動して、あるいはその両方で動作する複数のメモリ・デバイス16を含んでよい。メモリ・デバイス16は、電子的消去可能プログラマブル読み取り専用メモリ(EEPROM:electronically erasable programmable read only memory)などのメモリまたは関連するデバイスのホストを含んでよい。メモリ・デバイス16およびストレージ・デバイス14は、信号伝達媒体を介してCPU12に接続される。加えて、CPU12は、通信ポート18を介して通信ネットワーク20に接続されて、複数のその他のホスト・コンピュータ・システム(computer host systems)24および22に接続されている。さらに、メモリ・デバイス16およびCPU12は、計算システム10の各コンポーネントに埋め込まれて含まれてよい。各ストレージ・システムは、分離した、または個別の、あるいはその両方のメモリ・デバイス16およびCPU12を含んでもよく、その場合、メモリ・デバイス16およびCPU12は、分離したメモリ・デバイス16またはCPU12あるいはその両方と連動して、あるいは分離したメモリ・デバイス16またはCPU12あるいはその両方として動作する。
【0025】
図2は、コンピュータ・システム内で光学的に接続されたメモリ・システムのハードウェア構造を示している例示のブロック図200である。光相互接続ファブリック(optical interconnection fabric)204を介したCPU218からのメモリ214の分離は、高帯域幅遠距離製品(high bandwidth distance product)である光リンク204によって実現可能である。そのような光学的に接続されたメモリ(OCM:Optically-Connected Memory)システム200では、CPU218およびメモリ214は、光リンクおよび少なくとも1つのスイッチング・ファブリック204を介して接続された別々のラック202および208に編成される。メモリ・ラック206内には、メモリ・ブレード208が配置され、他のメモリ・ブレードおよびプロセッサ(CPU)ラック202に通信可能に結合される。各メモリ・ブレード208は複数のメモリ・デバイス214、エージェント212、およびメモリ・コントローラ210を収容する。CPUラック202はプロセッサ・ブレード216を含み、各プロセッサ・ブレード216は他のプロセッサ・ブレード216およびメモリ・ラック206に通信可能に結合される。プロセッサ・ブレード216はプロセッサ218を含み、各プロセッサ218はローカル・メモリ(図示せず)を含んでいる。プロセッサ・ラック216内のプロセッサ218(および各物理計算ノード)は、既知の高速相互接続手段(図示せず)によってローカルに接続され、この高速相互接続手段は、プロセッサ・ブレード216内のプロセッサ218の物理計算ノード間で何らかのトポロジによって直接接続されたネットワーク、またはキャッシュ・コヒーレント対称型マルチプロセッサ(SMP:symmetric multiprocessor)ファブリック(cache coherent symmetric multiprocessor (SMP) fabric)を介してメモリを通るスイッチ、あるいはこれらの組み合わせであることができる。プロセッサ218、プロセッサ・ブレード216、メモリ214、およびメモリ・ブレード208はそれぞれ、複数の光外部リンクを共有する。これらの外部リンクは、超高帯域幅での光スイッチング・ファブリック内のポイントツーポイント接続を最適化するように作られている。この最適化は、そのような高帯域幅を容易にするために使用される物理的実装であるか、または選択されたプロトコルであってよく、好ましくは、1つの物理リンク内、またはいくつかの物理リンクでできた1つの高帯域幅物理リンクのように見える複数の物理リンク内のメモリ・スイッチングをサポートすることができる。これらの外部リンクは、通常、そのデータまたはコンテンツを認識しない少なくとも1つの光スイッチ204を介して回路スイッチングされるので、超軽量の通信プロトコルを使用するべきである。
【0026】
これらの外部リンクの物理的特性は、WDM(波長分割マルチプレクサ:wavelength division multiplexer)内での複数の光波長の使用を必要とすることがあり、それらの光波長は、1つのファイバまたは1つの外部リンクにすべて結合されるが、両端では分離可能である。ミラーに基づく微小電気機械システム「MEMS」(micro electro mechanical system)光回路スイッチ「OCS」(optical circuit switch)は、波長の数、プロトコル、および信号伝達速度にかかわらず、光学的領域において、それらの外部リンク内で光線を偏向させる。好ましくは、示された実施形態において、これらの外部リンクは、メモリ・ブレードおよびプロセッサ・ブレードすべてに共通している。
【0027】
好ましいアーキテクチャでは、少なくとも1つの光回路スイッチが光外部リンク間で共有される。また、複数の独立した回路が、光回路スイッチを共有しているプロセッサとメモリ・ブレードの間で確立されてよい。これらの外部リンクは、超高帯域幅でのポイントツーポイント接続を最適化するように作られている。この最適化は、そのような高帯域幅を容易にするために選択されたプロトコルにおいて使用される物理的実装であってよく、1つの物理リンク内、またはいくつかの物理リンクでできた1つの高帯域幅物理リンクのように見える複数の物理リンク内の複数のストリームの集約をサポートすることができる。これらの外部リンクは、そのプロトコル、データ、またはコンテンツを認識しないすべての光スイッチを介して回路スイッチングされるので、超軽量の通信プロトコルが使用される。さらに、これらの外部リンクの物理的特性は、WDM(波長分割マルチプレクサ)内での複数の光波長の使用を必要とすることがあり、それらの光波長は、1つのファイバまたは1つの外部リンクにすべて結合されるが、両端では分離可能である。ミラーに基づく微小電気機械システム「MEMS」(micro electro mechanical system)光回路スイッチ「OCS」(optical circuit switch)は、波長の数、プロトコル、および信号伝達速度にかかわらず、光学的領域において、それらの外部リンク内で光線を偏向させる。これらの外部リンクは、すべてのメモリ・ブレード/プロセッサ・ブレードがこれらの外部リンクのうちの1つまたはすべての上で、直接的に、または相互接続されたプロセッサ・ブレードを通過させることによって、情報を渡すことができるように、すべてのプロセッサ、ブレード、メモリ、および独立した回路に共通している。一実施形態例では、回路スイッチング・スイッチ(circuit-switching switch)が使用される。回路スイッチング・スイッチは、頻繁にスイッチングする必要がないため、構築が非常に単純であることがあり、さまざまな技術(例えば、すべて光学的なMEMSミラーに基づく技術)を使用して、回路、メモリ、およびプロセッサ・ブレードの間を動的に接続することができる。
【0028】
このような種類の外部リンク(図示せず)および動的スイッチングは、必要に応じて動的に変化する超高スループット(例えば、高帯域幅)の接続を可能にする。マルチコア処理チップは、マルチコア処理チップを他のそのような物理処理ノードまたはメモリ・サブシステムに相互接続するのに超高帯域幅のネットワークを必要とするので、例示的な光学的に接続されたメモリ・アーキテクチャは、メモリ・スイッチング動作によって機能的に可能になるソリューションの提供において、極めて重要な役割を果たす。
【0029】
光学的に接続されたメモリ・アーキテクチャ200は、次のような多数の恩恵をもたらす。(a)システム・ノード間で透過的にメモリ容量を変更し、(b)メモリのワーストケースのプロビジョニング(worst-case provisioning)の概念を排除し、アプリケーションがワークロードに応じてメモリ・フットプリントを変更できるようにし、(c)CPUのダウンタイムをメモリ・モジュールの故障から切り離し、それによってCPUの可用性を向上させる。下で説明されているように、メモリ管理手法のためのアーキテクチャが提供される。図2に示されているように、プロセッサ・ブレード202が複数のプロセッサ218をホストし、一方メモリ・モジュール214がメモリ・ブレード208内でパッケージ化(例えば、配置)される。プロセッサ・ブレード216およびメモリ・ブレード208は、別々のラック202および206内に編成され、光スイッチング・ファブリック204を介して相互接続される。CPUブレード202内の各プロセッサ218は、より高速なメモリ・アクセスに使用されるローカル・メモリ・プール310a〜nを含んでよい。メモリ・ブレード208は、ダイナミック・ランダム・アクセス・メモリ(DRAM:dynamic random access memory)メモリ・デバイスに加えて、CPUブレード216を変更せずに、フラッシュまたは相変化メモリなどの代替のメモリ・デバイスを統合することができる。
【0030】
ここで図3を参照すると、図3は、コンピュータ・システム内の光学的に接続されたメモリ・システムにおけるプロセッサ設計のハードウェア構造を示しているブロック図300である。図3に示されているように、プロセッサ側の設計300は、システム内のソフトウェア・スタック302(仮想化なし)および304(仮想化あり)を示しており、プロセッサ・ブレードは、光トランシーバ308および312を介してリモート・メモリ・ブレードと通信する。メモリ・コントローラ306が、ローカル・メモリ・プール310a〜nに関連付けられている。システム・メモリ・アドレス(SMA:System Memory Address)空間(図3の302および304に示されている)が特定の事前に定められた制限を超えた場合、このSMAはリモート・メモリ・アドレス(RMMA:Remote Memory Address)空間408(図4に示されている)にマッピングされ、アクセス要求が適切なチャネルを介してリモート・メモリ・ブレードにルーティングされる。メモリ・ブレード208(図2を参照)が、リモート・メモリ・アドレス(RMMA)空間と呼ばれる別個のアドレス空間を維持するということに注意するべきである。
【0031】
光学的に接続されたメモリ・システム(図2の200を参照)では、各プロセッサ・ノード218は、リモート・メモリとローカル・メモリの両方に関して、SMA空間を維持する。プロセッサ・ノード218は、ローカル物理メモリを、このアドレス空間のより低い部分にマッピングする。リモート・メモリは、使用可能な(すなわち、より高い)SMAアドレス空間(302および304に示されている)にマッピングされる。リモート・メモリ側では、メモリ・ブレード208はRMMAを維持する。したがって、プロセッサ側での各メモリ・アクセスは、最初にSMA空間(図3の302および304に示されている)にマッピングされるべきである。SMA(302および304に示されている)がリモート・メモリに対応する場合、SMA(図3の302および304に示されている)はRMMAにマッピングされ、このRMMAはリモート・メモリ・ブレード208に送信される。光プレーン(optical plane)がSMA(図3の302および304に示されている)を各RMMAに変換し、図3に示されているようにリモート・メモリと情報をやりとりする。
【0032】
プロセッサ・ブレード(図3のコンポーネント306、308、および310a〜nと共に示されている)は、例えばNorthbridge(TM)チップセットに接続された、電気−光(EO:Electrical-to-Optical)/光−電気(OE:Optical-to-Electrical)トランシーバ312を介してリモート・メモリに接続される。仮想化システムでは、SMA(図3の302および304に示されている)は、マシン・アドレス(MA:Machine Address)(302および304に示されている)に対応し、仮想化されないシステムでは、SMA(図3の302および304に示されている)は物理アドレス(PA)(図3の302および304に示されている)に対応するということに注意する。図3に示されているように、各プロセッサ・ブレード(コンポーネント306、308、および310a〜nと共に示されている)は、別々のチャネルを介した複数のメモリ・ブレードへの同時接続を含んでよい。ここで、シングルモード光ファイバの場合、チャネルは別個の光トランシーバに対応し、一方、波長分割多重方式(WDM:wavelength-division multiplexing)では、単一のトランシーバが複数のチャネルを提供してよい。
【0033】
光学的に接続されたシステム(図2の200に示されている)では、プロセッサ・ノードが、プロセッサ・ノードとリモート・メモリ・ブレードの間で確立された独立した回路を介してリモート・メモリにアクセスする。ここで図4を参照すると、コンピュータ・システム内で光相互接続ファブリックを介してメモリをスイッチングするためのハードウェア構造を示している例示のブロック図400が示されている。プロセッサB 402Bは、リモート・ブレードC 406Bとの回路を確立し、プロセッサA 402Aによってすでに保持されているデータへのアクセスを取得する。上で図2〜4において概説したように、プロセッサ・ノードはリモート・メモリ・ブレードへの複数のチャネルを含み、また、各メモリ・ブレードは複数のチャネルを備え、メモリ・ブレードを複数のプロセッサ・ノード間で共有できるようにする。光チャネル(メモリ・ブレードまたはプロセッサ・ノード内にある)は、1つまたは複数の光トランシーバによって提供される。プロセッサ・ノード402(402Aおよび402Bとして示されている)は、メモリ・ブレード406(406A〜Cとして示されている)との回路を開始し、メモリ要求をリモート・メモリ・コントローラに送信することによって、メモリをリモート・メモリ・ブレードから割り当てることができる。そのようなメモリ・システムでは、リモート・メモリ・ブレード内のスーパー・ページを保持しているプロセッサ・ノード402は、別のプロセッサに信号を送って、リモート・メモリ・ブレード406(406A〜Cとして示されている)との回路を確立し、後者のプロセッサ・ノードへのメモリ空間の転送を開始する。前者のプロセッサ・ノード(例えば、プロセッサA 402A)は、RMMAアドレス空間を受信側プロセッサ・ノード(例えば、プロセッサB 402B)に送信することができ、受信側プロセッサ・ノードは、提供されたアドレス空間にある同じデータにアクセスすることができる。送信側プロセッサは、例えばこのメモリ・ブレード(例えば、メモリ・ブレード406B)でスーパー・ページが不要になった場合に、リモート・メモリ・ブレード406(406A〜Cとして示されている)との回路を壊して(例えば、切断して)よい。プロセッサ・ノード間でアドレス空間を転送するそのようなプロセスは、メモリ・スイッチングと呼ばれる。メモリ・スイッチング・プロセスは図4に示されており、プロセッサ・ノードA 402Aが、リモート・メモリ・ブレードC 406に格納されたデータをプロセッサ・ノードB 402Bに送信する。プロセッサB 402Bは、リモート・メモリ・ブレードC 406との回路を開始する。メモリ・ブレード406が複数のチャネルを含んでよいので、メモリ・ブレード406のメモリ空間が複数のプロセッサ・ノード間で共有されてよく、各メモリ空間がメモリ・ブレード406内の空間全体のうちの重複していない部分を占めているということに注意する。また、メモリ・スイッチングの送信元の側はスイッチアウト処理(switch-out operation)と呼ばれ、送信先の側はスイッチイン処理(switch-in operation)と呼ばれることがある。
【0034】
前述した計算環境は好ましいが、限定することを意図していない。本開示の非集約型計算システムの態様は、サービス配信の従来のクラウド・コンピューティング・モデルを提供するデータセンタ内で実装されてよい。したがって、完全を期すために、以下のセクションでは、クラウド・コンピューティングに関してさらに詳細に説明する。
【0035】
クラウド・コンピューティング
クラウド・コンピューティングは、構成可能な計算リソース(例えば、ネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、およびサービス)の共有プールへの便利なオンデマンドのネットワーク・アクセスを可能にし、管理上の手間またはサービス・プロバイダとのやりとりを最小限に抑えて、それらのリソースを迅速にプロビジョニングおよび解放することができる。このクラウド・モデルは、“Draft NIST Working Definition of Cloud Computing” by Peter Mell and Tim Grance, dated October 7, 2009において、すべてさらに詳細に説明され、定義されているように、少なくとも5つの特徴、少なくとも3つのサービス・モデル、および少なくとも4つのデプロイメント・モデルを含むことができる。
【0036】
特に、標準的な特徴は次のとおりである。
オンデマンドのセルフ・サービス:クラウドの利用者は、サーバの時間、ネットワーク・ストレージなどの計算能力を一方的に、サービス・プロバイダとの人間的なやりとりを必要とせず、必要に応じて自動的にプロビジョニングすることができる。
幅広いネットワーク・アクセス:クラウドの能力は、ネットワークを経由して利用可能であり、標準的なメカニズムを使用してアクセスできるため、異種のシン・クライアントまたはシック・クライアント・プラットフォーム(例えば、携帯電話、ラップトップ、およびPDA)による利用を促進する。
リソース・プール:プロバイダの計算リソースは、プールされ、マルチテナント・モデルを使用して複数の利用者に提供される。さまざまな物理的および仮想的リソースが、要求に従って動的に割り当ておよび再割り当てされる。場所に依存しないという感覚があり、利用者は通常、提供されるリソースの正確な場所に関して管理することも知ることもないが、さらに高い抽象レベル(例えば、国、州、データセンタ)では、場所を指定できる場合がある。
迅速な順応性:クラウドの能力は、迅速かつ柔軟に、場合によっては自動的にプロビジョニングされ、素早くスケールアウトし、迅速に解放されて素早くスケールインすることができる。プロビジョニングに使用できる能力は、利用者には、多くの場合、任意の量をいつでも無制限に購入できるように見える。
測定されるサービス:クラウド・システムは、計測機能を活用することによって、サービスの種類(例えば、ストレージ、処理、帯域幅、およびアクティブなユーザのアカウント)に適した抽象レベルで、リソースの使用を自動的に制御および最適化する。リソースの使用量は監視、制御、および報告することができ、利用されるサービスのプロバイダと利用者の両方に透明性が提供される。
【0037】
サービス・モデルは、通常、次のとおりである。
SaaS(Software as a Service):利用者に提供される能力は、クラウド・インフラストラクチャ上で稼働しているプロバイダのアプリケーションの利用である。それらのアプリケーションは、Webブラウザ(例えば、Webベースの電子メール)などのシン・クライアント・インターフェイスを介して、さまざまなクライアント・デバイスからアクセスできる。利用者は、ネットワーク、サーバ、オペレーティング・システム、ストレージ、または個々のアプリケーション機能さえも含む基盤になるクラウド・インフラストラクチャを、限定的なユーザ固有のアプリケーション構成設定を行う可能性を除き、管理することも制御することもない。
PaaS(Platform as a Service):利用者に提供される能力は、プロバイダによってサポートされるプログラミング言語およびツールを使用して作成された、利用者が作成または取得したアプリケーションをクラウド・インフラストラクチャにデプロイすることである。利用者は、ネットワーク、サーバ、オペレーティング・システム、またはストレージを含む基盤になるクラウド・インフラストラクチャを管理することも制御することもないが、デプロイされたアプリケーション、および場合によってはアプリケーション・ホスティング環境の構成を制御することができる。
IaaS(Infrastructure as a Service):利用者に提供される能力は、処理、ストレージ、ネットワーク、およびその他の基本的な計算リソースのプロビジョニングであり、利用者は、オペレーティング・システムおよびアプリケーションを含むことができる任意のソフトウェアをデプロイして実行できる。利用者は、基盤になるクラウド・インフラストラクチャを管理することも制御することもないが、オペレーティング・システム、ストレージ、およびデプロイされたアプリケーションを制御することができ、場合によっては、選択されたネットワーク・コンポーネント(例えば、ホスト・ファイアウォール)を限定的に制御できる。
【0038】
デプロイメント・モデルは、通常、次のとおりである。
プライベート・クラウド:このクラウド・インフラストラクチャは、ある組織のためにのみ運用される。このクラウド・インフラストラクチャは、この組織またはサード・パーティによって管理することができ、オンプレミスまたはオフプレミスに存在することができる。
コミュニティ・クラウド:このクラウド・インフラストラクチャは、複数の組織によって共有され、関心事(例えば、任務、セキュリティ要件、ポリシー、およびコンプライアンスに関する考慮事項)を共有している特定のコミュニティをサポートする。このクラウド・インフラストラクチャは、これらの組織またはサード・パーティによって管理することができ、オンプレミスまたはオフプレミスに存在することができる。
パブリック・クラウド:このクラウド・インフラストラクチャは、一般ユーザまたは大規模な業界団体が使用できるようになっており、クラウド・サービスを販売する組織によって所有される。
ハイブリッド・クラウド:このクラウド・インフラストラクチャは、データとアプリケーションの移植を可能にする標準化された技術または独自の技術(例えば、クラウド間の負荷バランスを調整するためのクラウド・バースト)によって固有の実体を残したまま互いに結合された2つ以上のクラウド(プライベート、コミュニティ、またはパブリック)の複合である。
【0039】
クラウド・コンピューティング環境は、ステートレス、疎結合、モジュール性、および意味的相互運用性に重点を置いたサービス指向の環境である。クラウド・コンピューティングの中心になるのは、相互接続されたノードのネットワークを備えるインフラストラクチャである。特に、クラウド・コンピューティング・ノード内には、他の多数の汎用または専用のコンピューティング・システム環境または構成と共に運用できるコンピュータ・システム/サーバが存在する。コンピュータ・システム/サーバと共に使用するのに適した既知のコンピューティング・システム、環境、または構成、あるいはその組み合わせの例は、パーソナル・コンピュータ・システム、サーバ・コンピュータ・システム、シン・クライアント、シック・クライアント、ハンドヘルドまたはラップトップ・デバイス、マイクロプロセッサ・システム、マイクロプロセッサベース・システム、セット・トップ・ボックス、プログラマブル・コンシューマ・エレクトロニクス、ネットワークPC、マイクロコンピュータ・システム、メインフレーム・コンピュータ・システム、およびこれらの任意のシステムまたはデバイスを含む分散クラウド・コンピューティング環境などを含むが、これらに限定されない。コンピュータ・システム/サーバは、コンピュータ・システムによって実行されているプログラム・モジュールなどの、コンピュータ・システムによって実行可能な命令との一般的な関連において説明されてよい。通常、プログラム・モジュールは、特定のタスクを実行するか、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、論理、データ構造などを含むことができる。コンピュータ・システム/サーバは、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される、分散クラウド・コンピューティング環境で実践されてよい。分散クラウド・コンピューティング環境において、プログラム・モジュールは、メモリ・ストレージ・デバイスを含む、ローカルおよびリモートの両方のコンピュータ・システム・ストレージ媒体に配置されてよい。
【0040】
標準的なクラウド・コンピューティング環境は、フロント・エンドIDマネージャ(frontend identity manager)、ビジネス支援サービス(BSS:business support services)機能コンポーネント、運用支援サービス(OSS:operational support services)機能コンポーネント、および計算クラウド・コンポーネントを含む一連の高レベルの機能コンポーネントを含んでいる。IDマネージャは、要求元のクライアントとインターフェイスをとって、ID管理を提供する責任を負い、このコンポーネントは、IBM Corporation(ニューヨーク州アーモンク市)から提供されているIBM Security Federated Identity Manager(TFIM)などの、1つまたは複数の既知のシステムと共に実装されてよい。適切な環境では、TFIMは、フェデレーション・シングル・サインオン(F−SSO:federated single sign-on)を他のクラウド・コンポーネントに提供するために使用されてよい。ビジネス支援サービス・コンポーネントは、請求書作成の支援などの特定の管理機能を提供する。運用支援サービス・コンポーネントは、仮想マシン(VM)インスタンスなどの他のクラウド・コンポーネントのプロビジョニングおよび管理を提供するために使用される。クラウド・コンポーネントは、主要な計算リソースを表し、通常は、クラウドを介したアクセスに使用可能なターゲット・アプリケーションを実行するために使用される複数の仮想マシン・インスタンスである。1つまたは複数のデータベースが、ディレクトリ、ログ、およびその他の作業用データの格納に使用される。これらのコンポーネント(フロント・エンドIDマネージャも含まれる)は、すべてクラウド「内」にあるが、これは必須要件ではない。代替の実施形態では、IDマネージャはクラウドの外部で運用されてよい。サービス・プロバイダも、クラウドの外部で運用されてよい。
【0041】
一部のクラウドは、非従来型のIPネットワークに基づく。したがって、例えば、クラウドは、MACアドレスのハッシュを使用した特殊な単層IPルーティング(single layer IP routing)を伴う2層CLOSベース・ネットワーク(two-tier CLOS-based networks)に基づいてよい。本明細書に記載された手法は、そのような非従来型のクラウドにおいて使用されてよい。
【0042】
図5は、リソースの仮想化をサポートする標準的なITインフラストラクチャを示しており、このITインフラストラクチャにおいて、下で説明される本開示の手法が全体的または部分的に実装されてもよい。説明の目的で、共有(パブリック)リソースを提供するITデータセンタは「プロバイダ」であり、それらの共有リソースを使用してデータおよびアプリケーションを(あらゆる形態で)ホスト、格納、および管理する顧客または企業は「サブスクライバ」(または「顧客」または「テナント」)である。図5では、仮想マシン・ホスティング環境(あるいは、本明細書ではデータセンタまたは「クラウド」と呼ばれる)の例が示されている。この環境は、通常はハイパーバイザ管理VLAN506を介して物理データセンタ・ネットワーク504に接続されたホスト・マシン(HV)502(例えば、サーバまたは同様の物理マシン・コンピューティング・デバイス)を含んでいる。明示的に示されていないが、通常、この環境は、負荷バランサ、ネットワーク・データ・スイッチ(例えば、トップ・オブ・ラック・スイッチ)、ファイアウォールなども含んでいる。図5に示されているように、物理サーバ502はそれぞれ、仮想化技術を使用して1つまたは複数の仮想マシン(VM)508を動的に提供するように適合される。そのような技術は、例えば、VMware(R)またはその他から市販されている。サーバ仮想化は、当技術分野においてよく知られた手法である。図示されているように、複数のVMが1つのホスト・マシンに配置され、このホスト・マシンのCPU、メモリ、およびその他のリソースを共有することができ、それによって、組織のデータセンタの利用率を向上させる。この環境では、テナント・アプリケーション510がネットワーク・アプライアンス(network appliances)512においてホストされ、テナント・データがデータ・ストアおよびデータベース514に格納される。アプリケーションおよびデータ・ストアは、通常はネットワーク管理/ストレージVLAN516を介して、物理データセンタ・ネットワーク504に接続される。仮想マシン、アプリケーション、およびテナント・データは、集合的に、サブスクライバがアクセスできる仮想化リソース管理ドメイン(virtualized resource management domain)505を表す。このドメインを介して、サブスクライバの従業員は、プロバイダによって割り当てられ、物理ITインフラストラクチャによって支援される仮想化リソースに(さまざまな役割ベースの権限を使用して)アクセスし、管理してよい。インフラストラクチャの最下部は、プロバイダがアクセスできる管理ドメイン515を示している。このドメインは、プロバイダ従業員管理ポータル518、BSS/OSS管理機能520、さまざまなIDおよびアクセス管理機能522、セキュリティ・ポリシー・サーバ524、およびサーバ・イメージ528を管理するための管理機能526を含んでいる。これらの機能は、管理VLAN530を介して物理データセンタ・ネットワークとインターフェイスをとる。プロバイダの従業員は、特殊な権限(および、おそらくは特定のクライアント/ネットワーク)を持ち、それらの権限により、ITデータセンタのインフラストラクチャの管理(例えば、ハードウェアの設置およびソフトウェアのインストール、構成、監視、技術サポート、請求書作成など)に使用する運用支援サービスおよびビジネス支援サービス(OSS/BSS)にアクセスすることができる。
【0043】
一般的に言うと、クラウド・コンピューティング・インフラストラクチャは、ネットワークおよび1つまたは複数の管理サーバを介して接続されたホスト・マシン(例えば、サーバまたは同様の物理マシン・コンピューティング・デバイス)を含む仮想マシン・ホスト環境を提供する。通常、物理サーバはそれぞれ、VMware ESX/ESXiなどの仮想化技術を使用して1つまたは複数の仮想マシンを動的に提供するように適合される。複数のVMが1つのホスト・マシンに配置され、このホスト・マシンのCPU、メモリ、およびその他のリソースを共有することができ、それによって、組織のデータセンタの利用率を向上させる。管理サーバは、タスクの中でも特に、インフラストラクチャを監視し、必要に応じて、例えば仮想マシンをホスト間で移動させることによって、VM配置を自動的に操作する。
【0044】
非限定的な実装では、代表的プラットフォーム技術は、VMware vSphere 4.1 Update 1および5.0を含むIBM System x(R)サーバであるが、これに限定されない。
【0045】
非集約型システムを指定するための方法およびシステム
上の説明では、複数の代表的な動作環境を示したが、次に、本開示の手法について説明する。
【0046】
本開示の手法によれば、1つまたは複数のデータセンタ内で(またはデータセンタにまたがって)、サーバ・リソースが分解されて、共有サーバ・リソース・プール(つまり、計算プール、メモリ・プール、アクセラレータ・プール、ストレージ・プールなどのうちの1つまたは複数)に入れられる。サーバは、ワークロード要件に基づいて、これらのリソース・プールから割り当てることによって、動的に(例えば、オンデマンドに)構築される。本開示によれば、このような種類の非集約型計算システムは、共有サーバ・リソース・プール内の使用可能なリソースを追跡し、この情報に基づいて、それらのリソースを管理する。
【0047】
一実施形態によれば、非集約型計算システムに関連付けられた追跡メカニズムは、データベースを含む。このデータベースは、リソース・プールから利用可能なサーバを定めるさまざまなリソースの状態またはステータス(例えば、アイドル状態または使用中のCPU、メモリ、アクセラレータ、およびその他のコンポーネント)を追跡するデータを格納する。さらに、このデータベースは、定められたサーバ(「サーバ・エンティティ」と呼ばれる場合もある)ごとに、サーバを構成するリソース(例えば、CPU、メモリ、アクセラレータ、またはその他のコンポーネント)を識別するデータ・レコード(または、さらに一般的には、データ・セット)を格納する。好ましくは、このデータ・レコードは、一意のサーバIDなどの識別子に関連付けられ、サーバを構成する各リソースは、データベース内で、この一意のサーバ識別子に関連付けられる。リソース・プールの個々のコンポーネントも、データベース内で追跡される識別子を含む。リソース固有の識別子は、リソースのステータス、属性、他のリソースとの関係などに関する情報を提供する。したがって、データベース(集中させるか、または分散させてよい)は、サーバ・エンティティ、サーバ・プール、および特定のサーバ・エンティティを構成するさまざまなリソースに関する情報のリポジトリとして機能する。
【0048】
データセンタのリソースに対する要求に応答して、例えば新しいサーバを割り当てる場合、1つまたは複数のリソース・プールからリソースを選択することによって、サーバ・エンティティが定められる。リソースは、予測された必要性、または要求に関連して指定された必要量、あるいはその他の基準に基づいて選択されてよい。サーバ・エンティティは一意のサーバIDに関連付けられ、一意のサーバIDは、サーバ・エンティティを構成するリソースの識別子と一緒に、データベースに格納される。その後、サーバ・エンティティは、要求、あるいは1つまたは複数の関連するか、または関連付けられた要求のワークロード要件に基づいて、必要に応じてスケールアップまたはスケールダウンされてよい。
【0049】
したがって、例えば、要求が処理されるとき、または処理するための追加の関連する要求が受信されたときに、追跡システムは、使用量を監視して、サーバ・エンティティを構成しているリソースに対する調整が必要かどうかを決定する。監視することに基づいて、追跡システムが、サーバ・エンティティのコンポーネントにおける調整が必要であると決定した場合、この調整は、例えばサーバ・エンティティに関連付けられたリソースの割り当てを変更することによって、実行される。したがって、例えば、追加の計算およびメモリが必要な場合(スケールアップ)、追跡システムは(自動的に、またはデータセンタ内の他のリソース・プロビジョニング・システムと連携して)、例えば追加のプロセッサおよびメモリを選択することによって、サーバ・エンティティを調整し、その後、それらのプロセッサおよびメモリがサーバ・エンティティに追加される。これらの追加のプロセッサおよびメモリは、データベース内で維持および追跡されている情報によって示される、負荷、サーバ・エンティティを構成する既存のリソースへの近接性、可用性などの、1つまたは複数の基準に基づいて、選択されてよい。一方、この監視することが、必要なリソースがより少ないことを示している場合(スケールダウン)、追跡システムは、例えば特定のプロセッサおよびメモリを選択解除することによって、サーバ・エンティティを調整し、その後、それらのプロセッサおよびメモリがサーバ・エンティティから割り当て解除され、各リソース・プールに戻される。
【0050】
ここで図6を参照して、本開示は、非集約型計算システム600を指定するための方法およびシステムを提供する。好ましいアプローチでは、非集約型計算システム600は、光学的に接続されたスイッチング・メモリ・アーキテクチャが使用されるデータセンタ605内で構成される。このアーキテクチャは、図1〜4との関連において上で説明されたが、これに限定することは意図されていない。非集約型計算システム600内には、共有サーバ・プール(例えば、計算プール602、メモリ・プール604、アクセラレータ・プール606、ストレージ・プール608など)が存在している。リソース・プールの1つのインスタンスまたは複数のそのようなインスタンス(「複数のプール」と呼ばれることもある)が存在してよい。本明細書におけるアプローチでは、顧客のワークロードにサービスを提供する特定のサーバは、ワークロード要件に基づいて、これらのリソース・プールから割り当てることによって、動的に(例えば、オンデマンドに)構築される。したがって、例えば、第1のサーバ・エンティティ610は、CPU602a(計算プール602から選択されるか、またはその他の方法で取得される)、メモリ604b(メモリ・プール604から選択されるか、またはその他の方法で取得される)、アクセラレータ606c(アクセラレータ・プール606から選択されるか、またはその他の方法で取得される)、およびストレージ608d(ストレージ・プール608から選択されるか、またはその他の方法で取得される)を備えてよい。第2のサーバ・エンティティ612は、CPU602b、メモリ604a、アクセラレータ606b、およびストレージ608aを備えてよい。これらは、単に代表的例である。さらに、下で説明されているように、特定のサーバ・エンティティを構成する特定のサーバ・プールのリソースは、変化してよい。
【0051】
好ましくは、リソース・プールの特定のリソースが特定のサーバ・エンティティに関連付けられると、その特定のリソースは、別のサーバ・エンティティを構成するために利用できなくなる。言い換えると、好ましくは、リソース・プールの割り当て済みリソースは、割り当て解除されるまで、サーバ・エンティティに関連付けられたままであり、割り当て解除された時点で、そのリソースはリソース・プールに戻され、別のサーバ・エンティティによって再び使用され得る。限定することは意図されていないが、好ましくは、サーバ・エンティティは、(作成された後に)データセンタの1人の顧客(テナント)のみに関連付けられる。言い換えると、サーバ・エンティティは、好ましくは、テナント間で共有されない。
【0052】
そのような割り当ておよび割り当て解除を管理するために、本開示に従って、非集約型計算システム600は、共有サーバ・リソース・プール内で利用できるリソース、およびさまざまなサーバ・エンティティに対して割り当てられたか、または割り当て解除されたリソースを追跡する能力を有する。この目的で、非集約型計算システム600は、リソース割り当てメカニズム614を備えている追跡システム、および関連するデータベース・システム616を備える(または、それらに関連付けられる)。一般に、追跡システムは、データ処理システムとして実装され、スタンドアロン方式で、あるいは他のシステムのコンポーネントまたはデータセンタ内の機能として動作してよい。
【0053】
通常、リソース割り当てメカニズム614は、ソフトウェアにおいて(つまり、コンピュータ・プログラム命令のセットとして)実装され、1つまたは複数のハードウェア・プロセッサ内で実行される。リソース割り当てメカニズム614は、1つまたは複数のサブシステムまたはモジュール、プロセス、プログラム、または実行スレッドを備えてよく、そのようなコンポーネントは、同一の場所に配置するか、または分散させてよい。リソース割り当てメカニズム614は、通常、本開示に従ってサーバ・エンティティを作成および管理する1つまたは複数の割り当てアルゴリズムを実行する責任を負う。下で説明されているように、各アルゴリズムは、例えば、サーバ・エンティティの初期構築を実行するために使用される新規サーバ割り当てアルゴリズムと、既存のサーバの場合に、ワークロードを処理するためにさらに多くの能力が必要なときに、さらに多くのリソースを既存のサーバ・エンティティに追加するために使用されるサーバ・スケールアップ・アルゴリズム(server scale-up algorithm)と、既存のサーバの場合に、ワークロードを処理するために必要な能力がさらに少ないときに、リソースを既存のサーバ・エンティティから割り当て解除(削減)するために使用されるサーバ・スケールダウン・アルゴリズム(サーバ・スケールダウン・アルゴリズム)とを含む。これらの機能のうちの1つまたは複数が結合されてよく、他の種類のアルゴリズムが、リソース割り当てメカニズム614によって実装されてよい。
【0054】
リソース割り当てメカニズム614を含む1つまたは複数のアルゴリズムは、データベース・システム616に格納された情報を使用して、管理機能を実行する。前述したように、データベース・システム616は、共有サーバ・プール内のさまざまなリソースの、状態、ステータス、またはその他の特性および属性を追跡する情報を格納する。加えて、データベースは、リソース割り当てメカニズムによって構築された各サーバ・エンティティに関する情報を格納する。一般的に言うと、よく知られているように、データベース・システム616は、データベース618、つまり、1つまたは複数の方法で(例えば、スキーマ、テーブル、クエリ、レポート、ビュー、およびその他のオブジェクトを使用して)編成されたデータの集合を、データベース管理システム(DBMS:database management system)620と共に備えており、データベース管理システム620は、ユーザ、その他のアプリケーション、およびデータベースと情報をやりとりしてデータを獲得および分析するコンピュータ・ソフトウェア・アプリケーションである。汎用DBMSは、データベースの定義、作成、問い合わせ、更新、および管理を可能にする。代表的なDBMSは、IBM(R) DB2(R)である。
【0055】
一実施形態では、データベース618はリレーショナルである。このデータベースは、定められたサーバ・エンティティごとに、サーバを構成するリソースを識別するデータ・レコード(または、さらに一般的には、データ・セット)を格納する。好ましくは、このデータ・レコードは、識別子(一意のサーバID)に関連付けられ、サーバを構成する各リソースは、データベース内で、この一意のサーバ識別子に関連付けられる。したがって、前述した例を引き続き参照すると、第1のサーバ・エンティティ610は一意のサーバIDに関連付けられてよく、第2のサーバ・エンティティ612は一意のサーバIDに関連付けられてよい、などのようになる。
【0056】
前述したように、好ましくは、リソース・プールの個々のコンポーネントも、データベース内で追跡される識別子を含み、リソースがサーバ・エンティティに割り当てられた場合、このリソースの識別子はこのサーバ・エンティティに関連付けられる(相互参照される)。したがって、上の第1の例を引き続き参照すると、CPU602a、メモリ604b、ネットワーク・アクセラレータ606c、およびストレージ608dのさまざまなリソース固有の識別子が、(リレーショナル・テーブルまたはその他の方法によって)第1のサーバ・エンティティ610の一意のサーバ識別子である一意のサーバID1に関連付けられる。同様に、第2の例を引き続き参照すると、CPU602b、メモリ604a、アクセラレータ606b、およびストレージ610aのさまざまなリソース固有の識別子が、第2のサーバ・エンティティの一意のサーバ識別子である一意のサーバID2に関連付けられる、などのように、サーバ・エンティティごとに同様に関連付けられる。
【0057】
サーバ・エンティティが最初に構築されるときに、サーバ・エンティティは、リソース割り当てメカニズムによってサーバ・プールから選択された1つまたは複数のサーバ・プールのリソースのセットを含む。したがって、サーバ・エンティティの一意のサーバ識別子は、リソース固有の識別子の初期セットに関連付けられる。後でリソースがサーバ・エンティティに割り当てられるか、またはサーバ・エンティティから割り当て解除されると、特定のサーバ・エンティティ識別子に関連付けられた構成要素であるリソース識別子のセットも変わる。
【0058】
前述したように、リソース・プールの複数のインスタンスが存在してよい。複数のインスタンスが存在する場合、サーバ・エンティティをサポートするための特定のリソースが、それらのインスタンスのうちの1つまたは複数から選択される。好ましくは、リソース・プールの第1のインスタンスに割り当てられたリソースがサーバ・エンティティの構築に使用された場合、能力をこのサーバ・エンティティに追加することが必要になったときに、好ましくは、追加リソースも、可能であれば同じインスタンスから取り出される。
【0059】
好ましくは、リソース固有の識別子は、リソースのステータス、属性、他のリソースとの関係などに関する情報を提供する。したがって、データベース(集中させるか、または分散させてよい)は、サーバ・エンティティ、サーバ・プール、および特定のサーバ・エンティティを構成するさまざまなリソースに関する情報のリポジトリとして機能する。
【0060】
リレーショナル・データベースは実装に役立つが、サーバ・エンティティ識別子とリソース固有の識別子は、他の方法(例えば、リンク・リスト、データ配列、ハッシュ・テーブル、またはその他の方法)で互いに関連付けられてよい。
【0061】
一般に、リソース割り当てメカニズム614およびデータベース・システム616は、連携して非集約型計算システムを管理する。リソース割り当てメカニズムは、サーバを定めるアイドル状態および使用中のCPU、メモリ、アクセラレータ、およびその他のコンポーネントを追跡する追跡システムとして機能する。さらに、追跡システムは、どのCPU、メモリ、アクセラレータ、またはその他のコンポーネントがサーバの一部であるかについての、定められた各サーバの記録を残す。前述したように、定められたサーバごとに、一意のIDが指定され、要求された数のCPU、メモリ、およびストレージが、下で詳細に説明されるように、例えばリソースの局所性、最良の適合性、および将来の拡張の必要性に基づいて、アイドル状態のリソースのプールから選択される。一意のサーバIDおよびこれらの各リソースのIDが、追跡システムにおいて記録される。好ましくは、前述したように、使用中のコンポーネントは、使用中としてマークが付けられ、アイドル状態のコンポーネントのプールから削除される。
【0062】
好ましくは、サーバ・エンティティの各コンポーネントは、そのコンポーネントが含まれているサーバの一意のサーバIDを使用して、タグ付けされる。したがって、このコンポーネントは、一意のサーバIDによって識別されたサーバ・エンティティのコンポーネントであるということを認識する。
【0063】
好ましくは、非集約型計算システムに対して発行された各要求、および要求に応答して受信されたデータも、サーバ・エンティティIDを使用してタグ付けされる。例えば、要求がリソースで受信された場合、このリソースは、要求にタグ付けされたサーバ・エンティティIDを、リソースのサーバ・エンティティIDと比較する。言い換えると、コンポーネントは、要求が、コンポーネントが割り当てられているサーバ・エンティティIDに一致するかどうかをチェックする能力を備えている。一致する場合、コンポーネントは、その要求を、使用して処理することができる要求であると認識する。要求にタグ付けされたサーバ・エンティティIDが、コンポーネントにタグ付けされたサーバ・エンティティIDと一致しない場合、コンポーネントは、その要求を無視できるということを認識する。
【0064】
下で説明されているように、リソース選択(新規サーバ割り当て、サーバ・スケールアップ、およびサーバ・スケールダウン)に使用されるアルゴリズムは、選択を容易にするために共通の基準を使用することができ、またはこれらのアルゴリズムは、例えばリソースのトポロジおよびリソース割り当ての目的に基づいて、互いに異なるものにすることができる。リソースが相互接続された場合、割り当てられるリソースにおけるさらに高い柔軟性をシステムで利用できる。直接相互接続されないリソースの場合、好ましくは、アルゴリズムは、リソースの階層、ならびにホップ数、待ち時間、およびコストなどのその他の要因を考慮する。後者の場合、好ましくは、アルゴリズムは、ホップ数を最小限に抑えるよう試みる。
【0065】
図7は、第1の実施形態に記載された、新規サーバ割り当てのプロセス・フローを示している。このプロセスは、例示的な新規サーバ割り当てアルゴリズムを説明している。一般に、このアルゴリズムは、プールをチェックし、サーバ・エンティティの要件に最も良く適合するリソース・プール(およびリソース・プール内のリソース)を決定することによって動作する。前述したように、プール自体の性質および構成に応じて、複数のプールがサーバ・エンティティの基準を満たす場合があり、その場合、新規サーバ割り当てアルゴリズムは、好ましくは、計算システムの将来の拡張を可能にするために、最大のリソースを利用できるプールからリソースを割り当てる。
【0066】
新しいサーバの要求の受信時に、ステップ700で、新規サーバ割り当てプロセスを開始する。この要求は、ユーザ、あるいはエンティティまたはシステムを要求している何かから受信されてよい。この要求は、プログラムで受信されてよい。新規サーバ割り当てプロセスは、サーバ・プールおよびサーバ・プールに関連するリソースに関する情報のデータベースにアクセスすることができる。ステップ702で、システムが、初期割り当てアルゴリズムを使用してリソースを割り当てる。初期割り当てアルゴリズムは、リソース・プールの数および構成、リソースが相互接続されているかどうか、そのような相互接続の性質などを考慮してよいが、これらに限定されない。ただし、利用される特定の初期リソース割り当て方法は、本開示の制限にならない。必要なプールおよびプール内のリソースを選択した後に、ステップ704で、一意のサーバ識別子(構築された新しいサーバ定義を表す)が生成される。次に、ステップ706で、システムが追跡システムを更新し、新しいサーバ定義をデータベースに追加する。ステップ708で、追跡システムが、新しいサーバ・エンティティ用に選択されたリソースが利用できなくなった(すなわち、使用中である)ことを反映するように、さらにデータベースを更新する。ステップ710で、定められた新しいサーバ・エンティティに関連付けられた各リソースが、一致するタグを持っているサービス要求に応答できるように、一意のサーバ識別子を使用してタグ付けされる。
【0067】
図8は、第2の実施形態に記載された、サーバ・スケールアップ・リソース割り当て方法のプロセス・フローを示している。一般に、前述したように、アルゴリズムは、さらに多くのリソースを既存のサーバ・エンティティに追加するように動作する。スケールアップが必要な場合、アルゴリズムは、局所性に基づいてリソースを優先する。その選択では、他のすべてが同じであるとき、サーバ・エンティティ内にすでに存在するリソースに(ネットワーク的に)「より近い」リソースが、より遠いリソースよりも優先される。当然、近い、または遠いという概念は相対的な用語であり、1つまたは複数の要因(例えば、待ち時間、損失、コスト、ホップ数など)に依存してよい。1つのアプローチでは、システムは、割り当て済みのリソースに最も近いリソースを検出しようとする。ただし、他の基準を使用する他のスケールアップ手法が使用されてよいため、これは制限ではない。
【0068】
ステップ800で、ユーザまたは何らかの他のシステムが、サーバ・エンティティのさらに多くの能力を要求した場合、ルーチンを開始する。この要求は、プログラムで受信されてよい。ステップ802で、システムが、使用される特定のリソース・スケールアップ割り当てアルゴリズムに基づいて、一意のサーバIDに対してさらに多くのリソースを割り当てることによって、応答する。利用される特定のスケールアップ・リソース選択方法は、本開示の制限にならない。ステップ804で、追跡システムが、新しく割り当てられたリソースが現在使用中であることを示すように更新される。次に、ルーチンは806に進み、前と同様に、新しく割り当てられた各リソースが、一意のサーバIDを使用してタグ付けされる。
【0069】
図9は、第3の実施形態に記載された、サーバ・スケールダウン・リソース割り当て方法のプロセス・フローを示している。通常、このプロセスは、既存のサーバ・エンティティから割り当て解除するリソースを選択するために使用される。スケールダウンするためのさまざまなアプローチが存在してよい。例えば、割り当て解除されるべきリソースは、利用可能なプールのサイズを最大化すること、プール自体のサイズを最大化することなどのために、リソース・プールからリソースを解放する位置に基づいて選択されてよい。例えば、プール間でバランスをとることを促進するために、これらの要因のラウンド・ロビン選択が実施されてよい。別の変形では、アルゴリズムは、割り当てが特定のワークロードにとって最適な解決策であるかどうかを分析し、最適でない場合、ワークロードの性能が低下することをユーザに警告する。さらに別の変形では、アルゴリズムは、特定のワークロードに基づいてシステムで必要とされる能力を予測し、適切に推奨を行う。
【0070】
ステップ900で、ユーザまたは何らかの他のシステムから能力の削減の要求を受信したときに、ルーチンを開始する。この要求は、プログラムで受信されてよい。ステップ902で、システムが、アルゴリズムを実行し、リソースをサーバ・エンティティから割り当て解除することによって、要求に応答する。利用される特定のスケールダウン・リソース選択方法は、本開示の制限にならない。ステップ904で、割り当て解除されたリソースが各リソース・プールに戻されていて、アイドル状態になっておらず、一意のサーバIDを更新するように、追跡システムが更新される。ステップ906で、タグ(サーバ・エンティティを識別する)がリソース識別子から削除されて、プロセスを完了する。
【0071】
したがって、データセンタのリソースに対する要求に応答して、例えば新しいサーバを割り当てる場合、1つまたは複数のリソース・プールからリソースを選択することによって、サーバ・エンティティが定められる。リソースは、予測された必要性、または要求に関連して指定された必要量、あるいはその他の基準に基づいて選択されてよい。サーバ・エンティティは一意のサーバIDに関連付けられ、一意のサーバIDは、サーバ・エンティティを構成するリソースの識別子と一緒に、データベースに格納される。その後、サーバ・エンティティは、要求、あるいは1つまたは複数の関連するか、または関連付けられた要求のワークロード要件に基づいて、必要に応じてスケールアップまたはスケールダウンされてよい。
【0072】
したがって、例えば、要求が処理されるとき、または処理するための追加の関連する要求が受信されたときに、追跡システムは、使用量を監視して、サーバ・エンティティを構成しているリソースに対する調整が必要かどうかを決定する。使用量は、データセンタ内の1つまたは複数の監視システムまたは監視サブシステムによって監視される。特定の監視サブシステムは、特定のサーバ・リソース・タイプに関連付けられてよい。したがって、例えば、1つの監視サブシステムがメモリ・システムの監視に使用されてよく、一方で、第2の監視サブシステムがCPUの監視に使用される。監視することは、すべて既知の方法でリソースの状態またはステータスに関する情報を提供するように、リソースをプロビジョニングまたは構成することによって、実現される。監視サブシステムは、分散させて、データを中央モニタに提供してよく、この中央モニタは、サーバ・エンティティを収集して分析し、調整が必要かどうかを決定し、調整が必要な場合は、その調整の性質および範囲を決定する。
【0073】
監視に基づいて、追跡システムが、サーバ・エンティティのコンポーネントにおける調整が必要であると決定した場合、この調整は、例えばサーバ・エンティティに関連付けられたリソースの割り当てを変更することによって、実行される。したがって、例えば、追加の計算およびメモリが必要な場合(スケールアップ)、追跡システムは(自動的に、またはデータセンタ内の他のリソース・プロビジョニング・システムと連携して)、例えば追加のプロセッサおよびメモリを選択することによって、サーバ・エンティティを調整し、その後、それらのプロセッサおよびメモリがサーバ・エンティティに追加される。これらの追加のプロセッサおよびメモリは、データベース内で維持および追跡されている情報によって示される、負荷、サーバ・エンティティを構成する既存のリソースへの近接性、可用性、消費電力、発熱などの、1つまたは複数の基準に基づいて、選択されてよい。一方、この監視することが、必要なリソースがより少ないことを示している場合(スケールダウン)、追跡システムは、例えば特定のプロセッサおよびメモリを選択解除することによって、サーバ・エンティティを調整し、その後、それらのプロセッサおよびメモリがサーバ・エンティティから割り当て解除され、各リソース・プールに戻される。
【0074】
本明細書に記載された手法は、大きな利点を提供する。それらは、初期リソースが予測された必要性に基づいて適切に割り当てられること、およびダウンタイムがなく、顧客への影響を最小限に抑えるか、または顧客への影響がない、物理的または仮想的ハードウェア能力の動的スケールアップまたはスケールダウンを可能にする。サーバ・エンティティは、プロセッサのサブセット、メモリのサブセットなどの割り当てから構築されるので、ワークロードの処理に必要なリソースのみが使用される。さらに、スケールアップが必要な場合、システムは、低コストで良好な性能を継続的に保証するために、好ましくは局所性の考慮(すなわち、追加リソースが存在する場所)に基づいて、必要な追加リソースを取得する。このアプローチは非集約型サーバを利用するので、これらの利点によって、データセンタは、より大きいモジュール性、より高いリソース利用率、より低いコスト、およびより良い性能を実現できる。実際、大規模なデータセンタが出現し、サーバ数が増加し続けるクラウドに対する必要性がある状況で、このアプローチは、データセンタがさらにコスト効率が高く、信頼できる方法で稼働するための手段を提供する。サーバ・エンティティが必要に応じて構築され、それらのエンティティを構成しているリソースが、必要に応じて動的に変更される。このアプローチは、ワークロード要件との不一致またはワークロード要件の変更に起因して、含まれている1つまたは複数のリソースの利用率が低下した場合にリソースのフラグメンテーションが発生するという、従来のサーバの使用から生じるワークロード割り当ての問題を解決する。本明細書に記載された共有リソース・プールおよびリソース割り当て方法を使用することによって、ワークロードの要件に従ってそれらのリソース・プールから割り当てることにより、サーバが動的かつオンデマンドで構築される。
【0075】
本明細書に記載された利点は、さまざまなサーバ・リソース・プール(resource server pools)を維持して使用することによって、かつサーバ・エンティティの生成および管理を可能にするリソース割り当てメカニズムによって提供される。追跡システム、ならびに追跡システムに関連した、一意のサーバ識別子および一意のサーバ識別子に関連するデータのデータベースをさらに含むそのようなアプローチの実施形態は、システムがサーバ・リソース・プールに対するより堅牢なインベントリ管理を提供できるようにし、スケールアップ・アルゴリズムおよびスケールダウン・アルゴリズムがより効率的に動作することを保証できるようにする。それらの一意のサーバ識別子をリソースのタグとしても使用する、そのようなアプローチのさらに別の実施形態は、サーバ・エンティティに関連付けられていないリソースが、処理されるべきサーバの要求を処理していないということを保証するので、さらに追加の利点を提供する。
【0076】
前述したように、上で説明された機能は、スタンドアロンのアプローチ(例えば、プロセッサによって実行されるソフトウェアベースの機能)として実装されてよく、またはサービス(SOAP/XMLインターフェイスを介したWebサービスを含む)として利用されてもよい。本明細書に記載された特定のハードウェアおよびソフトウェアの実装の詳細は、単に例示を目的としており、記載された主題の範囲を制限するようには意図されていない。
【0077】
さらに一般的には、開示された主題との関連において、コンピューティング・デバイスはそれぞれ、ハードウェアおよびソフトウェアを備えているデータ処理システムであり、これらのエンティティは、ネットワーク(インターネット、イントラネット、エクストラネット、プライベート・ネットワーク、あるいは任意のその他の通信媒体またはリンクなど)を経由して互いに通信する。データ処理システム上のアプリケーションは、特にHTTP、FTP、SMTP、SOAP、XML、WSDL、UDDI、およびWSFLのサポートを含むが、これらに限定されない、Webならびにその他の既知のサービスおよびプロトコルのネイティブ・サポートを提供する。SOAP、WSDL、UDDI、およびWSFLに関する情報は、これらの規格を開発および維持する役割を担っているワールド・ワイド・ウェブ・コンソーシアム(W3C:World Wide Web Consortium)から提供されており、HTTP、FTP、SMTP、およびXMLに関するさらなる情報は、インターネット・エンジニアリング・タスク・フォース(IETF:Internet Engineering Task Force)から提供されている。これらの既知の規格およびプロトコルを熟知していることが仮定される。
【0078】
本明細書に記載された手法は、単純なn層アーキテクチャ、Webポータル、フェデレーテッド・システムなどを含む、さまざまなサーバサイド・アーキテクチャ内で、またはこれらと併せて、実装されてよい。前述したように、本明細書における手法は、疎結合されたサーバ(「クラウド」ベースを含む)環境内で実践されてもよい。
【0079】
さらに一般的には、本明細書に記載された主題は、完全にハードウェアである実施形態、完全にソフトウェアである実施形態、またはハードウェアとソフトウェアの両方の要素を含んでいる実施形態の形態をとることができる。好ましい実施形態では、信頼できるプラットフォーム・モジュールの機能が、ファームウェア、常駐ソフトウェア、マイクロコードなどを含むがこれらに限定されないソフトウェアにおいて実装される。さらに、ダウンロードおよび削除のインターフェイスおよび機能は、コンピュータまたは任意の命令実行システムによって、またはこれらに関連させて使用するためのプログラム・コードを提供するコンピュータ使用可能媒体またはコンピュータ可読媒体からアクセスできるコンピュータ・プログラム製品の形態をとることができる。この説明の目的で、コンピュータ使用可能媒体またはコンピュータ可読媒体は、命令実行システム、命令実行装置、または命令実行デバイスによって、またはこれらに関連させて使用するためのプログラムを含むか、または格納することができる任意の装置であることができる。この媒体は、電子システム、磁気システム、光システム、電磁気システム、赤外線システム、または半導体システム(あるいは、装置またはデバイス)であることができる。コンピュータ可読媒体の例としては、半導体メモリまたは固体メモリ、磁気テープ、取り外し可能コンピュータ・ディスケット、ランダム・アクセス・メモリ(RAM:random access memory)、読み取り専用メモリ(ROM:read-only memory)、剛体磁気ディスク、および光ディスクが挙げられる。光ディスクの現在の例としては、コンパクト・ディスク読み取り専用メモリ(CD−ROM:compact disk-read only memory)、コンパクト・ディスク読み取り/書き込み(CD−R/W:compact disk-read/write)、およびDVDが挙げられる。コンピュータ可読媒体は、有形の非一時的アイテムである。
【0080】
コンピュータ・プログラム製品は、記載された機能のうちの1つまたは複数を実装するためのプログラム命令(またはプログラム・コード)を含んでいる製品であってよい。これらの命令またはコードは、ネットワークを経由してリモート・データ処理システムからダウンロードされた後に、データ処理システム内の非一時的コンピュータ可読記憶媒体に格納されてよい。または、これらの命令またはコードは、サーバ・データ処理システム内のコンピュータ可読記憶媒体に格納され、リモート・システム内のコンピュータ可読記憶媒体において使用するために、ネットワークを経由してリモート・データ処理システムにダウンロードされるように適合されてよい。
【0081】
代表的実施形態では、インターフェイスおよびユーティリティが、専用コンピューティング・プラットフォーム内で、好ましくは1つまたは複数のプロセッサによって実行されるソフトウェア内で、実装される。ソフトウェアは、1つまたは複数のプロセッサに関連付けられた1つまたは複数のデータ・ストアまたはメモリ内で維持され、ソフトウェアは、1つまたは複数のコンピュータ・プログラムとして実装されてよい。集合的に、この専用ハードウェアおよびソフトウェアは、前述した機能を備える。
【0082】
上では、本発明の特定の実施形態によって実行される特定の順序の処理を説明したが、代替の実施形態が、処理を異なる順序で実行すること、特定の処理を組み合わせること、特定の処理を重ね合わせることなどを実行してよいため、そのような順序は例であると理解されるべきである。本明細書における特定の実施形態例への参照は、記載された実施形態が特定の特徴、構造、または特性を含むことができるが、必ずしもすべての実施形態がこの特定の特徴、構造、または特性を含まなくてもよいということを示している。
【0083】
最後に、システムの特定のコンポーネントが別々に説明されたが、当業者は、機能の一部が、特定の命令、プログラム・シーケンス、コード部分などにおいて、組み合わされるか、または共有されてよいということを理解するであろう。
【0084】
本明細書における手法は、通常、技術または技術分野に対する前述の改良、および前述したようなワークロード管理方式に対する特定の技術的改良を提供する。
【0085】
以上で本発明を説明したが、特許請求の範囲は次のとおりである。
図1
図2
図3
図4
図5
図6
図7
図8
図9