(57)【要約】【課題】データセンタ運用環境内のデータ処理システムを提供する。【解決手段】データセンタ内のサーバ・リソースが分解されて、共有サーバ・リソース・プールに入れられる。サーバは、ワークロード要件に基づいて、これらのリソース・プールから割り当てることによって、動的に、オンデマンドに構築される。このような種類の非集約型計算システムは、共有サーバ・リソース・プール内の使用可能なリソースを追跡し、この情報に基づいて、それらのリソースを管理する。構築された各サーバ・エンティティには、一意のサーバＩＤが割り当てられ、サーバ・エンティティのコンポーネントを構成する各リソースは、この識別子を使用してタグ付けされる。ワークロードがサーバ・エンティティによって処理されるときに、サーバ・エンティティの構成は、例えば、さらに多くのリソースをサーバ・エンティティに割り当てるか、またはリソースをサーバ・エンティティから割り当て解除することによって、変更してよい。ワークロード要求は、サーバ・エンティティの一意のサーバＩＤに関連付けられる。ワークロード要求がリソースで受信された場合、このリソースは、この要求に対してサービスを提供する前に、このリソースの一意のサーバＩＤをこの要求の一意のサーバＩＤと照合する。【選択図】図２
2019511051.tif 000002
【特許請求の範囲】
【請求項１】
計算環境内でリソースを割り当てるための方法であって、
サーバ・リソース・プールのセットを提供することであって、サーバ・リソース・プールが一般的な種類のリソースのセットを含んでいる、前記提供することと、
要求の受信に応答して、前記サーバ・リソース・プールのうちの２つ以上から選択された１つまたは複数のリソースで構成されたサーバ・エンティティを定めることであって、前記１つまたは複数のリソースが、前記要求に関連付けられた予測されたワークロードに基づいて、前記サーバ・リソース・プールのうちの前記２つ以上から選択される、前記定めることと、
前記ワークロードが処理されるときに前記１つまたは複数のリソースを監視することから収集された情報を受信することと、
前記監視することに基づいて、前記ワークロードにおける変更に応じて、前記サーバ・エンティティの構成を調整することと
を含む、方法。
【請求項２】
一意のサーバ識別子を前記サーバ・エンティティに関連付けることであって、前記一意のサーバ識別子が、選択された前記１つまたは複数のリソースのそれぞれにも関連付けられる、前記関連付けることと、
前記サーバ・エンティティの前記構成の調整を反映するように前記一意のサーバ識別子を更新することと
をさらに含む、請求項１に記載の方法。
【請求項３】
前記共有サーバ・リソース・プールが、計算プールおよびメモリ・プールのうちの少なくとも１つである、請求項１に記載の方法。
【請求項４】
前記サーバ・エンティティの前記構成が、サーバ・リソース・プールの１つまたは複数のリソースを前記サーバ・エンティティに追加することによって調整される、請求項１に記載の方法。
【請求項５】
前記サーバ・エンティティに追加される前記１つまたは複数のリソースが、前記サーバ・エンティティ内にすでに存在する他の前記リソースに対するリソースのネットワーク局所性に基づいて選択される、請求項４に記載の方法。
【請求項６】
前記サーバ・エンティティの前記構成が、サーバ・リソース・プールの１つまたは複数のリソースを前記サーバ・エンティティから削除することによって調整される、請求項１に記載の方法。
【請求項７】
前記サーバ・エンティティから削除された前記１つまたは複数のリソースを前記サーバ・リソース・プールに戻すことをさらに含む、請求項６に記載の方法。
【請求項８】
前記一意のサーバ識別子を、前記ワークロードに関連付けられたサービス要求に関連付けることと、
特定のリソースで、前記特定のリソースに関連付けられた同じ一意のサービス識別子に前記サービス要求が関連付けられているということの決定時に、前記サービス要求に対してサービスを提供することと
をさらに含む、請求項２に記載の方法。
【請求項９】
計算環境内でリソースを割り当てるための装置であって、
１つまたは複数のハードウェア・プロセッサと、
前記ハードウェア・プロセッサによって実行されるコンピュータ・プログラム命令を保持しているコンピュータ・メモリとを備え、前記コンピュータ・プログラム命令が、
サーバ・リソース・プールのセットを管理することであって、サーバ・リソース・プールが一般的な種類のリソースのセットを含んでいる、前記管理することと、
要求の受信に応答して、前記サーバ・リソース・プールのうちの２つ以上から選択された１つまたは複数のリソースで構成されたサーバ・エンティティを定めることであって、前記１つまたは複数のリソースが、前記要求に関連付けられた予測されたワークロードに基づいて、前記サーバ・リソース・プールのうちの前記２つ以上から選択される、前記定めることと、
前記ワークロードが処理されるときに前記１つまたは複数のリソースを監視することから収集された情報を受信することと、
前記監視することに基づいて、前記ワークロードにおける変更に応じて、前記サーバ・エンティティの構成を調整することと
を実行するように機能する、装置。
【請求項１０】
前記コンピュータ・プログラム命令が、
一意のサーバ識別子を前記サーバ・エンティティに関連付けることであって、前記一意のサーバ識別子が、選択された前記１つまたは複数のリソースのそれぞれにも関連付けられる、前記関連付けることと、
前記サーバ・エンティティの前記構成の調整を反映するように前記一意のサーバ識別子を更新することと
を実行するようにさらに機能する、請求項９に記載の装置。
【請求項１１】
前記共有サーバ・リソース・プールが、計算プールおよびメモリ・プールのうちの少なくとも１つである、請求項９に記載の装置。
【請求項１２】
前記サーバ・エンティティの前記構成が、サーバ・リソース・プールの１つまたは複数のリソースを前記サーバ・エンティティに追加することによって調整される、請求項９に記載の装置。
【請求項１３】
前記サーバ・エンティティに追加される前記１つまたは複数のリソースが、前記サーバ・エンティティ内にすでに存在する他の前記リソースに対するリソースのネットワーク局所性に基づいて選択される、請求項１２に記載の装置。
【請求項１４】
前記サーバ・エンティティの前記構成が、サーバ・リソース・プールの１つまたは複数のリソースを前記サーバ・エンティティから削除することによって調整される、請求項９に記載の装置。
【請求項１５】
前記コンピュータ・プログラム命令が、前記サーバ・エンティティから削除された前記１つまたは複数のリソースを前記サーバ・リソース・プールに戻すようにさらに機能する、請求項１４に記載の装置。
【請求項１６】
前記コンピュータ・プログラム命令が、
前記一意のサーバ識別子を、前記ワークロードに関連付けられたサービス要求に関連付けることと、
特定のリソースで、前記特定のリソースに関連付けられた同じ一意のサービス識別子に前記サービス要求が関連付けられているということの決定時に、前記サービス要求に対してサービスを提供することと
を実行するようにさらに機能する、請求項１０に記載の装置。
【請求項１７】
計算環境内のリソースを割り当てるためにデータ処理システムにおいて使用するための非一時的コンピュータ可読媒体内のコンピュータ・プログラム製品であって、前記コンピュータ・プログラム製品が前記データ処理システムにおいて実行されるコンピュータ・プログラム命令を保持しており、前記コンピュータ・プログラム命令が、
サーバ・リソース・プールのセットを管理することであって、サーバ・リソース・プールが一般的な種類のリソースのセットを含んでいる、前記管理することと、
要求の受信に応答して、前記サーバ・リソース・プールのうちの２つ以上から選択された１つまたは複数のリソースで構成されたサーバ・エンティティを定めることであって、前記１つまたは複数のリソースが、前記要求に関連付けられた予測されたワークロードに基づいて、前記サーバ・リソース・プールのうちの前記２つ以上から選択される、前記定めることと、
前記ワークロードが処理されるときに前記１つまたは複数のリソースを監視することから収集された情報を受信することと、
前記監視することに基づいて、前記ワークロードにおける変更に応じて、前記サーバ・エンティティの構成を調整することと
を実行するように機能する、コンピュータ・プログラム製品。
【請求項１８】
前記コンピュータ・プログラム命令が、
一意のサーバ識別子を前記サーバ・エンティティに関連付けることであって、前記一意のサーバ識別子が、選択された前記１つまたは複数のリソースのそれぞれにも関連付けられる、前記関連付けることと、
前記サーバ・エンティティの前記構成の調整を反映するように前記一意のサーバ識別子を更新することと
を実行するようにさらに機能する、請求項１７に記載のコンピュータ・プログラム製品。
【請求項１９】
前記共有サーバ・リソース・プールが、計算プールおよびメモリ・プールのうちの少なくとも１つである、請求項１７に記載のコンピュータ・プログラム製品。
【請求項２０】
前記サーバ・エンティティの前記構成が、サーバ・リソース・プールの１つまたは複数のリソースを前記サーバ・エンティティに追加することによって調整される、請求項１７に記載のコンピュータ・プログラム製品。
【請求項２１】
前記サーバ・エンティティに追加される前記１つまたは複数のリソースが、前記サーバ・エンティティ内にすでに存在する他の前記リソースに対するリソースのネットワーク局所性に基づいて選択される、請求項２０に記載のコンピュータ・プログラム製品。
【請求項２２】
前記サーバ・エンティティの前記構成が、サーバ・リソース・プールの１つまたは複数のリソースを前記サーバ・エンティティから削除することによって調整される、請求項１７に記載のコンピュータ・プログラム製品。
【請求項２３】
前記コンピュータ・プログラム命令が、前記サーバ・エンティティから削除された前記１つまたは複数のリソースを前記サーバ・リソース・プールに戻すようにさらに機能する、請求項２２に記載のコンピュータ・プログラム製品。
【請求項２４】
前記コンピュータ・プログラム命令が、
前記一意のサーバ識別子を、前記ワークロードに関連付けられたサービス要求に関連付けることと、
特定のリソースで、前記特定のリソースに関連付けられた同じ一意のサービス識別子に前記サービス要求が関連付けられているということの決定時に、前記サービス要求に対してサービスを提供することと
を実行するようにさらに機能する、請求項１８に記載のコンピュータ・プログラム製品。
【請求項２５】
データセンタ・ファシリティであって、
サーバ・リソース・プールのセットであって、前記サーバ・リソース・プールが少なくとも計算プールおよびメモリ・プールを含んでいる、前記サーバ・リソース・プールのセットと、
前記計算プールから選択されたプロセッサ、前記メモリ・プールから選択されたコンピュータ・メモリ、および光相互接続を備えている少なくとも１つの非集約型計算システムと、
前記非集約型計算システムを定める一意のサーバ識別子を格納するデータベースであって、前記一意のサーバ識別子が、前記データベース内で、前記非集約型計算システム内の前記プロセッサおよびコンピュータ・メモリごとの識別子に関連付けられている、前記データベースと、
前記非集約型計算システムにおけるワークロードの変化に応答して、ワークロードの必要量に従って、前記非集約型計算システムの前記プロセッサまたは前記コンピュータ・メモリの構成を選択的に調整する、追跡システムと
を備えており、
前記一意のサーバ識別子が、前記非集約型計算システムの前記構成の調整を反映するように前記データベース内で更新される、データセンタ・ファシリティ。
【請求項２６】
局所性、予想されるワークロードへの最良の適合性、および前記データセンタ・ファシリティに関連する将来の拡張要件のうちの１つに基づいて、前記プロセッサおよびコンピュータ・メモリが選択される、請求項２５に記載のデータセンタ・ファシリティ。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、データセンタ運用環境内のデータ処理システムに一般に関する。
【背景技術】
【０００２】
よく知られた情報技術（ＩＴ：information technology）配信モデルは、クラウド・コンピューティングである。クラウド・コンピューティングによって、共有されたリソース、ソフトウェア、および情報が、インターネットを経由してオンデマンドでコンピュータおよびその他のデバイスに提供される。クラウド・コンピューティングは、ＩＴのコストおよび複雑性を大幅に低減しながら、ワークロード最適化およびサービス配信を改善する。このアプローチでは、アプリケーション・インスタンスがホストされ、例えばＨＴＴＰ経由で従来のＷｅｂブラウザを介して、アクセス可能なインターネットベースのリソースから利用可能になる。クラウドの計算リソースは、通常は仮想化アーキテクチャを使用して、１つまたは複数のネットワーク・アプリケーションを実行する大規模なサーバ・ファームに収容されることが多い。仮想化アーキテクチャでは、アプリケーションは、データセンタ・ファシリティ内の物理サーバにマッピングされた仮想サーバまたはいわゆる「仮想マシン」（ＶＭ：virtual machine）内で実行される。
【０００３】
データセンタ自体の内部では、データセンタのネットワークが、通常は、電気的スイッチの複数の層（つまり、アクセス層、集約層、およびコア層）を含んでいる階層設計に従って設計される。データセンタのフロント・エンドでは、コンテンツおよび負荷バランシング・スイッチ（content and load balancing switches）がゲートウェイ・ルータを介してインターネットに接続され、一方、バック・エンドでは、それらがコア・スイッチにリンクされる。通常、コア・スイッチは集約スイッチにリンクされ、集約スイッチはラック・スイッチに接続される。各ラック・スイッチは、ラック内のサーバに接続される。データセンタのネットワーク内のスイッチは、通常は電子スイッチ・ファブリック（electronic switch fabric）上で動作し、それらのスイッチ間のリンクは、銅ケーブルまたは光ファイバのいずれかである。外部ネットワークから要求が来た場合、その要求は、最初に負荷バランシングおよびコンテンツ・スイッチ（load balancing and content switches）に到達し、負荷バランシングおよびコンテンツ・スイッチは、要求を適切なサーバにルーティングする。要求を満たすために、サーバは、同じラックまたは異なるラック内の他のサーバと協調することができる。例えば、アプリケーション・サーバは、データベース・サーバと協調して、要求を処理することができる。要求の完了後に、応答がゲートウェイ・ルータを介して外部ネットワークに送信される。
【０００４】
説明したような従来のデータセンタ・アーキテクチャは、スケーラビリティ、フォールト・トレランス、およびエネルギー効率を含むが、これらに限定されない、多くの課題に直面している。その結果、多くのデータセンタは、クラウド・コンピューティングの需要の増大に対処することに苦労している。
【０００５】
データセンタの性能は、データセンタを構成しているハードウェア・システムの性質による影響も受ける。現在、ハードウェア・システムは、事前に定められた数のＣＰＵおよびメモリと共に、事前にパッケージ化されており、このことが柔軟性を制限している。例えば、標準的な仮想マシンの環境では、仮想ＣＰＵの数が定められ、メモリが割り当てられる。そのような環境では、仮想ＣＰＵの数は変更できるが、どの物理ＣＰＵが使用されるかを指定する手段も、物理ＣＰＵの数を増やす方法を指定する手段もない。
【０００６】
さらに、多くの場合、ダウンタイムおよび顧客への影響を生じさせずに、仮想能力および非仮想能力を調整できるように、物理ハードウェアの能力を動的にスケールアップまたはスケールダウンする必要がある。例えば、メモリ内の列指向リレーショナル・データベース管理システム（例えば、ＨＡＮＡサーバ）を含んでいるアプリケーション・サーバの場合を考える。非仮想環境内で、より多くのＣＰＵまたはその他のリソースを、そのようなサーバに追加することが望まれる場合、より多くのリソースを動的に追加できるのではなく、ハードウェア・ボックスを構築する必要がある。ハイパーバイザの能力は、通常、基盤になるハードウェア・ボックスの能力に制限されるため、仮想環境において、同様の問題が存在する。
【０００７】
データセンタのリソースのプロビジョニングのための別の既知のアプローチでは、製造業者によって事前に組み立てられた特定のコンポーネントを含んでいる構築済みのサーバを使用する。このアプローチでは、データセンタの顧客はオプション（サーバがどのリソースを保有するべきかの識別を含む）のメニューのリストから選択することができるが、通常は、望ましい特徴を有している最も近いボックスをユーザが手動で選択することによって、照合が行われる。しかし、選択されたボックスが使用不可能であることがあり、その場合、顧客の必要性を満たすために、より高価なボックスが使用される。このプロセスは、リソース（すなわち、プロセッサの種類、メモリ、ストレージＧＰＵ（storage GPU）など）の多くの可能な組み合わせをそれぞれが保有しているさまざまな種類のサーバの巨大なインベントリである各物理データセンタでの可用性を必要とする。これは、コストおよびリソース管理の観点から望ましくない。さらに、そのようなインベントリを利用できる場合でも、選択およびプロビジョニングのプロセスは、時間がかかり、複雑である。
【先行技術文献】
【非特許文献】
【０００８】
【非特許文献１】“Draft NIST Working Definition of Cloud Computing” by Peter Mell and Tim Grance, dated October 7, 2009
【発明の概要】
【発明が解決しようとする課題】
【０００９】
したがって、従来技術に関連するこれらおよびその他の問題に対処するための手法を提供する必要性が残されている。従って、解決しようとする課題は非集約型計算システムを実現する手法を提供することである。
【課題を解決するための手段】
【００１０】
本開示の第１の態様によれば、計算環境内のリソースを割り当てるための方法が提供される。この方法は、サーバ・リソース・プール（server resource pool）のセットを提供することから開始し、サーバ・リソース・プールは、一般的な種類のリソースのセット（例えば、計算プール（compute pool）、メモリ・プールなど）を含んでいる。要求の受信に応答して、サーバ・エンティティが定められる。サーバ・エンティティは、サーバ・リソース・プールのうちの１つまたは複数から選択された１つまたは複数のリソースで構成される。要求に関連する予測されたワークロードに基づいて、１つまたは複数のリソースが、サーバ・リソース・プールのうちの１つまたは複数から選択される。その後、ワークロードが処理されるときに、ワークロードとしての１つまたは複数のリソースを監視することから収集された情報が受信される。監視することから収集された情報に基づいて、ワークロードにおける変更に応じて、サーバ・エンティティの構成が調整される。
【００１１】
好ましくは、一意のサーバ識別子がサーバ・エンティティに関連付けられ、追跡の目的に使用される。一意のサーバ識別子は、サーバ・エンティティに対して選択された各リソースにも関連付けられる。一意の識別子は、サーバ・エンティティの構成の調整を反映するように更新される。
【００１２】
本開示の第２の態様によれば、計算環境内のリソースを割り当てるための装置が説明される。この装置は、１つまたは複数のハードウェア・プロセッサのセットと、前述したステップなどの一連の処理を実行するためにハードウェア・プロセッサによって実行されるコンピュータ・プログラム命令を保持するコンピュータ・メモリとを備える。
【００１３】
本開示の第３の態様によれば、計算環境内のリソースを割り当てるためにデータ処理システムにおいて使用される、非一時的コンピュータ可読媒体内のコンピュータ・プログラム製品が説明される。コンピュータ・プログラム製品は、データ処理システムにおいて実行され、前述のステップなどの処理を実行するように機能するコンピュータ・プログラム命令を保持する。
【００１４】
本開示の第４の態様によれば、データセンタ・ファシリティが説明される。このデータセンタは、サーバ・リソース・プールのセット、非集約型計算システム（disaggregated compute system）、データベース、および追跡システムを備える。これらのサーバ・リソース・プールは、少なくとも計算プールおよびメモリ・プールを含む。この非集約型計算システムは、計算プールから選択されたプロセッサ、メモリ・プールから選択されたコンピュータ・メモリ、および光相互接続を備える。このデータベースは、非集約型計算システムを定める一意のサーバ識別子を格納する。この一意のサーバ識別子は、データベース内で、非集約型計算システム内のサーバに割り当てられた各リソース（例えば、プロセッサおよびコンピュータ・メモリ）の識別子に関連付けられる。追跡システムは、非集約型計算システムにおけるワークロードの変化に応答して、ワークロードの必要量に従って、非集約型計算システムのプロセッサまたはコンピュータ・メモリの構成を選択的に調整する。動作中に、一意のサーバ識別子は、非集約型計算システムの構成の調整を反映するようにデータベース内で更新される。
【００１５】
好ましくは、オプションの態様として、前述のデータセンタ内で、局所性、予想されるワークロードへの最良の適合性、およびデータセンタ・ファシリティに関連する将来の拡張要件のうちの１つに基づいて、プロセッサおよびコンピュータ・メモリが選択される。
【００１６】
前述の手法および技術的特徴は、大きな利点を提供する。それらは、初期リソースが予測された必要性に基づいてデータセンタ内で適切に割り当てられること、およびダウンタイムがなく、顧客への影響を最小限に抑えるか、または顧客への影響がない、物理的または仮想的ハードウェア能力の動的スケールアップまたはスケールダウンを可能にする。サーバ・エンティティは、プロセッサのサブセット、メモリのサブセットなどの割り当てから構築されるので、ワークロードの処理に必要なリソースのみが使用される。さらに、スケールアップが必要な場合、システムは、低コストで良好な性能を継続的に保証するために、好ましくは局所性の考慮（すなわち、追加リソースが存在する場所）に基づいて、必要な追加リソースを取得する。このアプローチは非集約型サーバを利用するので、これらの利点によって、データセンタは、より大きいモジュール性、より高いリソース利用率、より低いコスト、およびより良い性能を実現できる。サーバ・エンティティが必要に応じて構築され、それらのエンティティを構成しているリソースも、オンデマンドで動的に変更される。このアプローチは、ワークロード要件との不一致またはワークロード要件の変更に起因して、含まれている１つまたは複数のリソースの利用率が低下した場合にリソースのフラグメンテーションが発生するという、従来のサーバの使用から生じるワークロード割り当ての問題を解決する。本明細書に記載された共有リソース・プールおよびリソース割り当て方法を使用することによって、ワークロードの要件に従ってそれらのリソース・プールから割り当てることにより、サーバが動的かつオンデマンドで構築される。
【００１７】
以上では、開示される主題のより関連する特徴の一部について概説した。これらの特徴は、単に例であると解釈されるべきである。説明されるように、開示された主題を異なる方法で適用することによって、または主題を変更することによって、多くのその他の有益な結果を実現できる。
【００１８】
主題および主題の利点をさらに完全に理解するために、ここで、添付の図面と併せて行われる以下の説明を参照する。
【図面の簡単な説明】
【００１９】
【図１】本開示の例示の態様が実装されてよい計算システム環境を示す例示のブロック図である。
【図２】例示的な実施形態の態様が実装されてよい、光学的に接続されたメモリ・システムのハードウェア構造の例示のブロック図である。
【図３】図２の光学的に接続されたメモリ・システム内のプロセッサ設計のハードウェア構造を示すブロック図である。
【図４】プロセッサでメモリにアクセスするためのハードウェア構造を示すブロック図である。
【図５】本開示に記載された非集約型計算システムを示す図である。
【図６】本開示の手法が実装されてよい代替のデータセンタ・アーキテクチャを示す図である。
【図７】第１の実施形態に記載された、新規サーバ割り当てのプロセス・フローを示す図である。
【図８】第２の実施形態に記載された、サーバ・スケールアップ・リソース割り当て方法（server scale-up resource allocation method）のプロセス・フローを示す図である。
【図９】第３の実施形態に記載された、サーバ・スケールダウン・リソース割り当て方法（server scale-down resource allocation method）のプロセス・フローを示す図である。
【発明を実施するための形態】
【００２０】
本開示の手法は、好ましくは、「非集約型」計算システムの文脈において実装され、「非集約型サーバ」（本明細書では、しばしば「サーバ・エンティティ」と呼ばれる）は、共有サーバ・リソース・プール（つまり、計算プール、メモリ・プール、アクセラレータ・プール（例えば、ＧＰＵアクセラレータ、ネットワーク・アクセラレータなど）、ストレージ・プールなどのうちの１つまたは複数）から選択された（または割り当てられた）サーバ・リソースで構成されるか、そのようなサーバ・リソースを構成する。名前が示すように、「計算」プールは通常、物理プロセッサ（ＣＰＵなど）を構成し、「メモリ」プールは通常、物理メモリ・デバイス（デュアル・インライン・メモリ・モジュール（ＤＩＭＭ：dual-inline-memory modules）など）を構成する、などとなっている。特定の共有プールは、好ましくは、特定のリソース・タイプのみを含むが、特定のリソース・プールは、１つまたは複数のリソース・サブタイプで構成されてよい。一般的なリソースが収集されるか、集約されるか、またはその他の任意の適切な方法で結合されてよいため、「プール」という概念は、制限することを意図していない。さらに「プール」は、一般的なタイプまたはサブタイプを持つリソースの専用のセットであるか、またはそのようなリソースの何らかの一時的な集合であってよい。好ましくは、特定のサーバ・エンティティは、サーバ・リソース・プールのうちの１つまたは複数からのサーバ・リソースを備える。
【００２１】
好ましい実施形態では、下で説明されるように、本開示の内容が実践される非集約型計算システムは、メモリの（電気相互接続ではなく）光相互接続を利用するが、これに限定されない。
【００２２】
通常、共有リソース・プールは、特定のデータセンタの物理的制約の範囲内で利用可能であるが、同様に、これに限定されない。したがって、共有リソース・プール自体が、物理データセンタ間で共有されてよい。さらに、特定のサーバ・エンティティが各サーバ・プールからのリソースで構成される必要はない。
【００２３】
光学的に接続されたスイッチング・メモリ・アーキテクチャ（switching optically-connected memory architecture）
背景の目的で、ただし限定することを目的とせず、以下では、本開示の手法（下で説明される）が実践されてよい代表的なコンピュータ環境について説明する。
【００２４】
ここで図１を参照すると、本開示の非集約型計算システムが実装されてよい計算環境の例示のアーキテクチャ１０が示されている。コンピュータ・システム１０は、通信ポート１８およびメモリ・デバイス１６に接続された中央処理装置（ＣＰＵ：central processing unit）を含んでいる。通信ポート１８は、通信ネットワーク２０と通信する。通信ネットワーク２０およびストレージ・ネットワークは、サーバ（ホスト）２４および２２、ならびにストレージ・システム１４を含んでよいストレージ・システムと通信するように構成されてよい。ストレージ・システムは、ハード・ディスク・ドライブ（ＨＤＤ：hard disk drive）デバイス、半導体デバイス（ＳＳＤ：solid-state device）などを含んでよく、新磁気ディスク制御機構（ＲＡＩＤ：redundant array ofindependent disks）で構成されてよい。下で説明されるような処理は、システム１０内または他の場所にあるストレージ・デバイス１４上で実行されてよく、他のＣＰＵデバイス１２から独立して、または他のＣＰＵデバイス１２と連動して、あるいはその両方で動作する複数のメモリ・デバイス１６を含んでよい。メモリ・デバイス１６は、電子的消去可能プログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ：electronically erasable programmable read only memory）などのメモリまたは関連するデバイスのホストを含んでよい。メモリ・デバイス１６およびストレージ・デバイス１４は、信号伝達媒体を介してＣＰＵ１２に接続される。加えて、ＣＰＵ１２は、通信ポート１８を介して通信ネットワーク２０に接続されて、複数のその他のホスト・コンピュータ・システム（computer host systems）２４および２２に接続されている。さらに、メモリ・デバイス１６およびＣＰＵ１２は、計算システム１０の各コンポーネントに埋め込まれて含まれてよい。各ストレージ・システムは、分離した、または個別の、あるいはその両方のメモリ・デバイス１６およびＣＰＵ１２を含んでもよく、その場合、メモリ・デバイス１６およびＣＰＵ１２は、分離したメモリ・デバイス１６またはＣＰＵ１２あるいはその両方と連動して、あるいは分離したメモリ・デバイス１６またはＣＰＵ１２あるいはその両方として動作する。
【００２５】
図２は、コンピュータ・システム内で光学的に接続されたメモリ・システムのハードウェア構造を示している例示のブロック図２００である。光相互接続ファブリック（optical interconnection fabric）２０４を介したＣＰＵ２１８からのメモリ２１４の分離は、高帯域幅遠距離製品（high bandwidth distance product）である光リンク２０４によって実現可能である。そのような光学的に接続されたメモリ（ＯＣＭ：Optically-Connected Memory）システム２００では、ＣＰＵ２１８およびメモリ２１４は、光リンクおよび少なくとも１つのスイッチング・ファブリック２０４を介して接続された別々のラック２０２および２０８に編成される。メモリ・ラック２０６内には、メモリ・ブレード２０８が配置され、他のメモリ・ブレードおよびプロセッサ（ＣＰＵ）ラック２０２に通信可能に結合される。各メモリ・ブレード２０８は複数のメモリ・デバイス２１４、エージェント２１２、およびメモリ・コントローラ２１０を収容する。ＣＰＵラック２０２はプロセッサ・ブレード２１６を含み、各プロセッサ・ブレード２１６は他のプロセッサ・ブレード２１６およびメモリ・ラック２０６に通信可能に結合される。プロセッサ・ブレード２１６はプロセッサ２１８を含み、各プロセッサ２１８はローカル・メモリ（図示せず）を含んでいる。プロセッサ・ラック２１６内のプロセッサ２１８（および各物理計算ノード）は、既知の高速相互接続手段（図示せず）によってローカルに接続され、この高速相互接続手段は、プロセッサ・ブレード２１６内のプロセッサ２１８の物理計算ノード間で何らかのトポロジによって直接接続されたネットワーク、またはキャッシュ・コヒーレント対称型マルチプロセッサ（ＳＭＰ：symmetric multiprocessor）ファブリック（cache coherent symmetric multiprocessor （SMP） fabric）を介してメモリを通るスイッチ、あるいはこれらの組み合わせであることができる。プロセッサ２１８、プロセッサ・ブレード２１６、メモリ２１４、およびメモリ・ブレード２０８はそれぞれ、複数の光外部リンクを共有する。これらの外部リンクは、超高帯域幅での光スイッチング・ファブリック内のポイントツーポイント接続を最適化するように作られている。この最適化は、そのような高帯域幅を容易にするために使用される物理的実装であるか、または選択されたプロトコルであってよく、好ましくは、１つの物理リンク内、またはいくつかの物理リンクでできた１つの高帯域幅物理リンクのように見える複数の物理リンク内のメモリ・スイッチングをサポートすることができる。これらの外部リンクは、通常、そのデータまたはコンテンツを認識しない少なくとも１つの光スイッチ２０４を介して回路スイッチングされるので、超軽量の通信プロトコルを使用するべきである。
【００２６】
これらの外部リンクの物理的特性は、ＷＤＭ（波長分割マルチプレクサ：wavelength division multiplexer）内での複数の光波長の使用を必要とすることがあり、それらの光波長は、１つのファイバまたは１つの外部リンクにすべて結合されるが、両端では分離可能である。ミラーに基づく微小電気機械システム「ＭＥＭＳ」（micro electro mechanical system）光回路スイッチ「ＯＣＳ」（optical circuit switch）は、波長の数、プロトコル、および信号伝達速度にかかわらず、光学的領域において、それらの外部リンク内で光線を偏向させる。好ましくは、示された実施形態において、これらの外部リンクは、メモリ・ブレードおよびプロセッサ・ブレードすべてに共通している。
【００２７】
好ましいアーキテクチャでは、少なくとも１つの光回路スイッチが光外部リンク間で共有される。また、複数の独立した回路が、光回路スイッチを共有しているプロセッサとメモリ・ブレードの間で確立されてよい。これらの外部リンクは、超高帯域幅でのポイントツーポイント接続を最適化するように作られている。この最適化は、そのような高帯域幅を容易にするために選択されたプロトコルにおいて使用される物理的実装であってよく、１つの物理リンク内、またはいくつかの物理リンクでできた１つの高帯域幅物理リンクのように見える複数の物理リンク内の複数のストリームの集約をサポートすることができる。これらの外部リンクは、そのプロトコル、データ、またはコンテンツを認識しないすべての光スイッチを介して回路スイッチングされるので、超軽量の通信プロトコルが使用される。さらに、これらの外部リンクの物理的特性は、ＷＤＭ（波長分割マルチプレクサ）内での複数の光波長の使用を必要とすることがあり、それらの光波長は、１つのファイバまたは１つの外部リンクにすべて結合されるが、両端では分離可能である。ミラーに基づく微小電気機械システム「ＭＥＭＳ」（micro electro mechanical system）光回路スイッチ「ＯＣＳ」（optical circuit switch）は、波長の数、プロトコル、および信号伝達速度にかかわらず、光学的領域において、それらの外部リンク内で光線を偏向させる。これらの外部リンクは、すべてのメモリ・ブレード／プロセッサ・ブレードがこれらの外部リンクのうちの１つまたはすべての上で、直接的に、または相互接続されたプロセッサ・ブレードを通過させることによって、情報を渡すことができるように、すべてのプロセッサ、ブレード、メモリ、および独立した回路に共通している。一実施形態例では、回路スイッチング・スイッチ（circuit-switching switch）が使用される。回路スイッチング・スイッチは、頻繁にスイッチングする必要がないため、構築が非常に単純であることがあり、さまざまな技術（例えば、すべて光学的なＭＥＭＳミラーに基づく技術）を使用して、回路、メモリ、およびプロセッサ・ブレードの間を動的に接続することができる。
【００２８】
このような種類の外部リンク（図示せず）および動的スイッチングは、必要に応じて動的に変化する超高スループット（例えば、高帯域幅）の接続を可能にする。マルチコア処理チップは、マルチコア処理チップを他のそのような物理処理ノードまたはメモリ・サブシステムに相互接続するのに超高帯域幅のネットワークを必要とするので、例示的な光学的に接続されたメモリ・アーキテクチャは、メモリ・スイッチング動作によって機能的に可能になるソリューションの提供において、極めて重要な役割を果たす。
【００２９】
光学的に接続されたメモリ・アーキテクチャ２００は、次のような多数の恩恵をもたらす。（ａ）システム・ノード間で透過的にメモリ容量を変更し、（ｂ）メモリのワーストケースのプロビジョニング（worst-case provisioning）の概念を排除し、アプリケーションがワークロードに応じてメモリ・フットプリントを変更できるようにし、（ｃ）ＣＰＵのダウンタイムをメモリ・モジュールの故障から切り離し、それによってＣＰＵの可用性を向上させる。下で説明されているように、メモリ管理手法のためのアーキテクチャが提供される。図２に示されているように、プロセッサ・ブレード２０２が複数のプロセッサ２１８をホストし、一方メモリ・モジュール２１４がメモリ・ブレード２０８内でパッケージ化（例えば、配置）される。プロセッサ・ブレード２１６およびメモリ・ブレード２０８は、別々のラック２０２および２０６内に編成され、光スイッチング・ファブリック２０４を介して相互接続される。ＣＰＵブレード２０２内の各プロセッサ２１８は、より高速なメモリ・アクセスに使用されるローカル・メモリ・プール３１０ａ〜ｎを含んでよい。メモリ・ブレード２０８は、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ：dynamic random access memory）メモリ・デバイスに加えて、ＣＰＵブレード２１６を変更せずに、フラッシュまたは相変化メモリなどの代替のメモリ・デバイスを統合することができる。
【００３０】
ここで図３を参照すると、図３は、コンピュータ・システム内の光学的に接続されたメモリ・システムにおけるプロセッサ設計のハードウェア構造を示しているブロック図３００である。図３に示されているように、プロセッサ側の設計３００は、システム内のソフトウェア・スタック３０２（仮想化なし）および３０４（仮想化あり）を示しており、プロセッサ・ブレードは、光トランシーバ３０８および３１２を介してリモート・メモリ・ブレードと通信する。メモリ・コントローラ３０６が、ローカル・メモリ・プール３１０ａ〜ｎに関連付けられている。システム・メモリ・アドレス（ＳＭＡ：System Memory Address）空間（図３の３０２および３０４に示されている）が特定の事前に定められた制限を超えた場合、このＳＭＡはリモート・メモリ・アドレス（ＲＭＭＡ：Remote Memory Address）空間４０８（図４に示されている）にマッピングされ、アクセス要求が適切なチャネルを介してリモート・メモリ・ブレードにルーティングされる。メモリ・ブレード２０８（図２を参照）が、リモート・メモリ・アドレス（ＲＭＭＡ）空間と呼ばれる別個のアドレス空間を維持するということに注意するべきである。
【００３１】
光学的に接続されたメモリ・システム（図２の２００を参照）では、各プロセッサ・ノード２１８は、リモート・メモリとローカル・メモリの両方に関して、ＳＭＡ空間を維持する。プロセッサ・ノード２１８は、ローカル物理メモリを、このアドレス空間のより低い部分にマッピングする。リモート・メモリは、使用可能な（すなわち、より高い）ＳＭＡアドレス空間（３０２および３０４に示されている）にマッピングされる。リモート・メモリ側では、メモリ・ブレード２０８はＲＭＭＡを維持する。したがって、プロセッサ側での各メモリ・アクセスは、最初にＳＭＡ空間（図３の３０２および３０４に示されている）にマッピングされるべきである。ＳＭＡ（３０２および３０４に示されている）がリモート・メモリに対応する場合、ＳＭＡ（図３の３０２および３０４に示されている）はＲＭＭＡにマッピングされ、このＲＭＭＡはリモート・メモリ・ブレード２０８に送信される。光プレーン（optical plane）がＳＭＡ（図３の３０２および３０４に示されている）を各ＲＭＭＡに変換し、図３に示されているようにリモート・メモリと情報をやりとりする。
【００３２】
プロセッサ・ブレード（図３のコンポーネント３０６、３０８、および３１０ａ〜ｎと共に示されている）は、例えばＮｏｒｔｈｂｒｉｄｇｅ（ＴＭ）チップセットに接続された、電気−光（ＥＯ：Electrical-to-Optical）／光−電気（ＯＥ：Optical-to-Electrical）トランシーバ３１２を介してリモート・メモリに接続される。仮想化システムでは、ＳＭＡ（図３の３０２および３０４に示されている）は、マシン・アドレス（ＭＡ：Machine Address）（３０２および３０４に示されている）に対応し、仮想化されないシステムでは、ＳＭＡ（図３の３０２および３０４に示されている）は物理アドレス（ＰＡ）（図３の３０２および３０４に示されている）に対応するということに注意する。図３に示されているように、各プロセッサ・ブレード（コンポーネント３０６、３０８、および３１０ａ〜ｎと共に示されている）は、別々のチャネルを介した複数のメモリ・ブレードへの同時接続を含んでよい。ここで、シングルモード光ファイバの場合、チャネルは別個の光トランシーバに対応し、一方、波長分割多重方式（ＷＤＭ：wavelength-division multiplexing）では、単一のトランシーバが複数のチャネルを提供してよい。
【００３３】
光学的に接続されたシステム（図２の２００に示されている）では、プロセッサ・ノードが、プロセッサ・ノードとリモート・メモリ・ブレードの間で確立された独立した回路を介してリモート・メモリにアクセスする。ここで図４を参照すると、コンピュータ・システム内で光相互接続ファブリックを介してメモリをスイッチングするためのハードウェア構造を示している例示のブロック図４００が示されている。プロセッサＢ  ４０２Ｂは、リモート・ブレードＣ  ４０６Ｂとの回路を確立し、プロセッサＡ  ４０２Ａによってすでに保持されているデータへのアクセスを取得する。上で図２〜４において概説したように、プロセッサ・ノードはリモート・メモリ・ブレードへの複数のチャネルを含み、また、各メモリ・ブレードは複数のチャネルを備え、メモリ・ブレードを複数のプロセッサ・ノード間で共有できるようにする。光チャネル（メモリ・ブレードまたはプロセッサ・ノード内にある）は、１つまたは複数の光トランシーバによって提供される。プロセッサ・ノード４０２（４０２Ａおよび４０２Ｂとして示されている）は、メモリ・ブレード４０６（４０６Ａ〜Ｃとして示されている）との回路を開始し、メモリ要求をリモート・メモリ・コントローラに送信することによって、メモリをリモート・メモリ・ブレードから割り当てることができる。そのようなメモリ・システムでは、リモート・メモリ・ブレード内のスーパー・ページを保持しているプロセッサ・ノード４０２は、別のプロセッサに信号を送って、リモート・メモリ・ブレード４０６（４０６Ａ〜Ｃとして示されている）との回路を確立し、後者のプロセッサ・ノードへのメモリ空間の転送を開始する。前者のプロセッサ・ノード（例えば、プロセッサＡ  ４０２Ａ）は、ＲＭＭＡアドレス空間を受信側プロセッサ・ノード（例えば、プロセッサＢ  ４０２Ｂ）に送信することができ、受信側プロセッサ・ノードは、提供されたアドレス空間にある同じデータにアクセスすることができる。送信側プロセッサは、例えばこのメモリ・ブレード（例えば、メモリ・ブレード４０６Ｂ）でスーパー・ページが不要になった場合に、リモート・メモリ・ブレード４０６（４０６Ａ〜Ｃとして示されている）との回路を壊して（例えば、切断して）よい。プロセッサ・ノード間でアドレス空間を転送するそのようなプロセスは、メモリ・スイッチングと呼ばれる。メモリ・スイッチング・プロセスは図４に示されており、プロセッサ・ノードＡ  ４０２Ａが、リモート・メモリ・ブレードＣ  ４０６に格納されたデータをプロセッサ・ノードＢ  ４０２Ｂに送信する。プロセッサＢ  ４０２Ｂは、リモート・メモリ・ブレードＣ  ４０６との回路を開始する。メモリ・ブレード４０６が複数のチャネルを含んでよいので、メモリ・ブレード４０６のメモリ空間が複数のプロセッサ・ノード間で共有されてよく、各メモリ空間がメモリ・ブレード４０６内の空間全体のうちの重複していない部分を占めているということに注意する。また、メモリ・スイッチングの送信元の側はスイッチアウト処理（switch-out operation）と呼ばれ、送信先の側はスイッチイン処理（switch-in operation）と呼ばれることがある。
【００３４】
前述した計算環境は好ましいが、限定することを意図していない。本開示の非集約型計算システムの態様は、サービス配信の従来のクラウド・コンピューティング・モデルを提供するデータセンタ内で実装されてよい。したがって、完全を期すために、以下のセクションでは、クラウド・コンピューティングに関してさらに詳細に説明する。
【００３５】
クラウド・コンピューティング
クラウド・コンピューティングは、構成可能な計算リソース（例えば、ネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、およびサービス）の共有プールへの便利なオンデマンドのネットワーク・アクセスを可能にし、管理上の手間またはサービス・プロバイダとのやりとりを最小限に抑えて、それらのリソースを迅速にプロビジョニングおよび解放することができる。このクラウド・モデルは、“Draft NIST Working Definition of Cloud Computing” by Peter Mell and Tim Grance, dated October 7, 2009において、すべてさらに詳細に説明され、定義されているように、少なくとも５つの特徴、少なくとも３つのサービス・モデル、および少なくとも４つのデプロイメント・モデルを含むことができる。
【００３６】
特に、標準的な特徴は次のとおりである。
オンデマンドのセルフ・サービス：クラウドの利用者は、サーバの時間、ネットワーク・ストレージなどの計算能力を一方的に、サービス・プロバイダとの人間的なやりとりを必要とせず、必要に応じて自動的にプロビジョニングすることができる。
幅広いネットワーク・アクセス：クラウドの能力は、ネットワークを経由して利用可能であり、標準的なメカニズムを使用してアクセスできるため、異種のシン・クライアントまたはシック・クライアント・プラットフォーム（例えば、携帯電話、ラップトップ、およびＰＤＡ）による利用を促進する。
リソース・プール：プロバイダの計算リソースは、プールされ、マルチテナント・モデルを使用して複数の利用者に提供される。さまざまな物理的および仮想的リソースが、要求に従って動的に割り当ておよび再割り当てされる。場所に依存しないという感覚があり、利用者は通常、提供されるリソースの正確な場所に関して管理することも知ることもないが、さらに高い抽象レベル（例えば、国、州、データセンタ）では、場所を指定できる場合がある。
迅速な順応性：クラウドの能力は、迅速かつ柔軟に、場合によっては自動的にプロビジョニングされ、素早くスケールアウトし、迅速に解放されて素早くスケールインすることができる。プロビジョニングに使用できる能力は、利用者には、多くの場合、任意の量をいつでも無制限に購入できるように見える。
測定されるサービス：クラウド・システムは、計測機能を活用することによって、サービスの種類（例えば、ストレージ、処理、帯域幅、およびアクティブなユーザのアカウント）に適した抽象レベルで、リソースの使用を自動的に制御および最適化する。リソースの使用量は監視、制御、および報告することができ、利用されるサービスのプロバイダと利用者の両方に透明性が提供される。
【００３７】
サービス・モデルは、通常、次のとおりである。
ＳａａＳ（Software as a Service）：利用者に提供される能力は、クラウド・インフラストラクチャ上で稼働しているプロバイダのアプリケーションの利用である。それらのアプリケーションは、Ｗｅｂブラウザ（例えば、Ｗｅｂベースの電子メール）などのシン・クライアント・インターフェイスを介して、さまざまなクライアント・デバイスからアクセスできる。利用者は、ネットワーク、サーバ、オペレーティング・システム、ストレージ、または個々のアプリケーション機能さえも含む基盤になるクラウド・インフラストラクチャを、限定的なユーザ固有のアプリケーション構成設定を行う可能性を除き、管理することも制御することもない。
ＰａａＳ（Platform as a Service）：利用者に提供される能力は、プロバイダによってサポートされるプログラミング言語およびツールを使用して作成された、利用者が作成または取得したアプリケーションをクラウド・インフラストラクチャにデプロイすることである。利用者は、ネットワーク、サーバ、オペレーティング・システム、またはストレージを含む基盤になるクラウド・インフラストラクチャを管理することも制御することもないが、デプロイされたアプリケーション、および場合によってはアプリケーション・ホスティング環境の構成を制御することができる。
ＩａａＳ（Infrastructure as a Service）：利用者に提供される能力は、処理、ストレージ、ネットワーク、およびその他の基本的な計算リソースのプロビジョニングであり、利用者は、オペレーティング・システムおよびアプリケーションを含むことができる任意のソフトウェアをデプロイして実行できる。利用者は、基盤になるクラウド・インフラストラクチャを管理することも制御することもないが、オペレーティング・システム、ストレージ、およびデプロイされたアプリケーションを制御することができ、場合によっては、選択されたネットワーク・コンポーネント（例えば、ホスト・ファイアウォール）を限定的に制御できる。
【００３８】
デプロイメント・モデルは、通常、次のとおりである。
プライベート・クラウド：このクラウド・インフラストラクチャは、ある組織のためにのみ運用される。このクラウド・インフラストラクチャは、この組織またはサード・パーティによって管理することができ、オンプレミスまたはオフプレミスに存在することができる。
コミュニティ・クラウド：このクラウド・インフラストラクチャは、複数の組織によって共有され、関心事（例えば、任務、セキュリティ要件、ポリシー、およびコンプライアンスに関する考慮事項）を共有している特定のコミュニティをサポートする。このクラウド・インフラストラクチャは、これらの組織またはサード・パーティによって管理することができ、オンプレミスまたはオフプレミスに存在することができる。
パブリック・クラウド：このクラウド・インフラストラクチャは、一般ユーザまたは大規模な業界団体が使用できるようになっており、クラウド・サービスを販売する組織によって所有される。
ハイブリッド・クラウド：このクラウド・インフラストラクチャは、データとアプリケーションの移植を可能にする標準化された技術または独自の技術（例えば、クラウド間の負荷バランスを調整するためのクラウド・バースト）によって固有の実体を残したまま互いに結合された２つ以上のクラウド（プライベート、コミュニティ、またはパブリック）の複合である。
【００３９】
クラウド・コンピューティング環境は、ステートレス、疎結合、モジュール性、および意味的相互運用性に重点を置いたサービス指向の環境である。クラウド・コンピューティングの中心になるのは、相互接続されたノードのネットワークを備えるインフラストラクチャである。特に、クラウド・コンピューティング・ノード内には、他の多数の汎用または専用のコンピューティング・システム環境または構成と共に運用できるコンピュータ・システム／サーバが存在する。コンピュータ・システム／サーバと共に使用するのに適した既知のコンピューティング・システム、環境、または構成、あるいはその組み合わせの例は、パーソナル・コンピュータ・システム、サーバ・コンピュータ・システム、シン・クライアント、シック・クライアント、ハンドヘルドまたはラップトップ・デバイス、マイクロプロセッサ・システム、マイクロプロセッサベース・システム、セット・トップ・ボックス、プログラマブル・コンシューマ・エレクトロニクス、ネットワークＰＣ、マイクロコンピュータ・システム、メインフレーム・コンピュータ・システム、およびこれらの任意のシステムまたはデバイスを含む分散クラウド・コンピューティング環境などを含むが、これらに限定されない。コンピュータ・システム／サーバは、コンピュータ・システムによって実行されているプログラム・モジュールなどの、コンピュータ・システムによって実行可能な命令との一般的な関連において説明されてよい。通常、プログラム・モジュールは、特定のタスクを実行するか、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、論理、データ構造などを含むことができる。コンピュータ・システム／サーバは、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される、分散クラウド・コンピューティング環境で実践されてよい。分散クラウド・コンピューティング環境において、プログラム・モジュールは、メモリ・ストレージ・デバイスを含む、ローカルおよびリモートの両方のコンピュータ・システム・ストレージ媒体に配置されてよい。
【００４０】
標準的なクラウド・コンピューティング環境は、フロント・エンドＩＤマネージャ（frontend identity manager）、ビジネス支援サービス（ＢＳＳ：business support services）機能コンポーネント、運用支援サービス（ＯＳＳ：operational support services）機能コンポーネント、および計算クラウド・コンポーネントを含む一連の高レベルの機能コンポーネントを含んでいる。ＩＤマネージャは、要求元のクライアントとインターフェイスをとって、ＩＤ管理を提供する責任を負い、このコンポーネントは、ＩＢＭ  Ｃｏｒｐｏｒａｔｉｏｎ（ニューヨーク州アーモンク市）から提供されているＩＢＭ  Ｓｅｃｕｒｉｔｙ  Ｆｅｄｅｒａｔｅｄ  Ｉｄｅｎｔｉｔｙ  Ｍａｎａｇｅｒ（ＴＦＩＭ）などの、１つまたは複数の既知のシステムと共に実装されてよい。適切な環境では、ＴＦＩＭは、フェデレーション・シングル・サインオン（Ｆ−ＳＳＯ：federated single sign-on）を他のクラウド・コンポーネントに提供するために使用されてよい。ビジネス支援サービス・コンポーネントは、請求書作成の支援などの特定の管理機能を提供する。運用支援サービス・コンポーネントは、仮想マシン（ＶＭ）インスタンスなどの他のクラウド・コンポーネントのプロビジョニングおよび管理を提供するために使用される。クラウド・コンポーネントは、主要な計算リソースを表し、通常は、クラウドを介したアクセスに使用可能なターゲット・アプリケーションを実行するために使用される複数の仮想マシン・インスタンスである。１つまたは複数のデータベースが、ディレクトリ、ログ、およびその他の作業用データの格納に使用される。これらのコンポーネント（フロント・エンドＩＤマネージャも含まれる）は、すべてクラウド「内」にあるが、これは必須要件ではない。代替の実施形態では、ＩＤマネージャはクラウドの外部で運用されてよい。サービス・プロバイダも、クラウドの外部で運用されてよい。
【００４１】
一部のクラウドは、非従来型のＩＰネットワークに基づく。したがって、例えば、クラウドは、ＭＡＣアドレスのハッシュを使用した特殊な単層ＩＰルーティング（single layer IP routing）を伴う２層ＣＬＯＳベース・ネットワーク（two-tier CLOS-based networks）に基づいてよい。本明細書に記載された手法は、そのような非従来型のクラウドにおいて使用されてよい。
【００４２】
図５は、リソースの仮想化をサポートする標準的なＩＴインフラストラクチャを示しており、このＩＴインフラストラクチャにおいて、下で説明される本開示の手法が全体的または部分的に実装されてもよい。説明の目的で、共有（パブリック）リソースを提供するＩＴデータセンタは「プロバイダ」であり、それらの共有リソースを使用してデータおよびアプリケーションを（あらゆる形態で）ホスト、格納、および管理する顧客または企業は「サブスクライバ」（または「顧客」または「テナント」）である。図５では、仮想マシン・ホスティング環境（あるいは、本明細書ではデータセンタまたは「クラウド」と呼ばれる）の例が示されている。この環境は、通常はハイパーバイザ管理ＶＬＡＮ５０６を介して物理データセンタ・ネットワーク５０４に接続されたホスト・マシン（ＨＶ）５０２（例えば、サーバまたは同様の物理マシン・コンピューティング・デバイス）を含んでいる。明示的に示されていないが、通常、この環境は、負荷バランサ、ネットワーク・データ・スイッチ（例えば、トップ・オブ・ラック・スイッチ）、ファイアウォールなども含んでいる。図５に示されているように、物理サーバ５０２はそれぞれ、仮想化技術を使用して１つまたは複数の仮想マシン（ＶＭ）５０８を動的に提供するように適合される。そのような技術は、例えば、ＶＭｗａｒｅ（Ｒ）またはその他から市販されている。サーバ仮想化は、当技術分野においてよく知られた手法である。図示されているように、複数のＶＭが１つのホスト・マシンに配置され、このホスト・マシンのＣＰＵ、メモリ、およびその他のリソースを共有することができ、それによって、組織のデータセンタの利用率を向上させる。この環境では、テナント・アプリケーション５１０がネットワーク・アプライアンス（network appliances）５１２においてホストされ、テナント・データがデータ・ストアおよびデータベース５１４に格納される。アプリケーションおよびデータ・ストアは、通常はネットワーク管理／ストレージＶＬＡＮ５１６を介して、物理データセンタ・ネットワーク５０４に接続される。仮想マシン、アプリケーション、およびテナント・データは、集合的に、サブスクライバがアクセスできる仮想化リソース管理ドメイン（virtualized resource management domain）５０５を表す。このドメインを介して、サブスクライバの従業員は、プロバイダによって割り当てられ、物理ＩＴインフラストラクチャによって支援される仮想化リソースに（さまざまな役割ベースの権限を使用して）アクセスし、管理してよい。インフラストラクチャの最下部は、プロバイダがアクセスできる管理ドメイン５１５を示している。このドメインは、プロバイダ従業員管理ポータル５１８、ＢＳＳ／ＯＳＳ管理機能５２０、さまざまなＩＤおよびアクセス管理機能５２２、セキュリティ・ポリシー・サーバ５２４、およびサーバ・イメージ５２８を管理するための管理機能５２６を含んでいる。これらの機能は、管理ＶＬＡＮ５３０を介して物理データセンタ・ネットワークとインターフェイスをとる。プロバイダの従業員は、特殊な権限（および、おそらくは特定のクライアント／ネットワーク）を持ち、それらの権限により、ＩＴデータセンタのインフラスト���クチャの管理（例えば、ハードウェアの設置およびソフトウェアのインストール、構成、監視、技術サポート、請求書作成など）に使用する運用支援サービスおよびビジネス支援サービス（ＯＳＳ／ＢＳＳ）にアクセスすることができる。
【００４３】
一般的に言うと、クラウド・コンピューティング・インフラストラクチャは、ネットワークおよび１つまたは複数の管理サーバを介して接続されたホスト・マシン（例えば、サーバまたは同様の物理マシン・コンピューティング・デバイス）を含む仮想マシン・ホスト環境を提供する。通常、物理サーバはそれぞれ、ＶＭｗａｒｅ  ＥＳＸ／ＥＳＸｉなどの仮想化技術を使用して１つまたは複数の仮想マシンを動的に提供するように適合される。複数のＶＭが１つのホスト・マシンに配置され、このホスト・マシンのＣＰＵ、メモリ、およびその他のリソースを共有することができ、それによって、組織のデータセンタの利用率を向上させる。管理サーバは、タスクの中でも特に、インフラストラクチャを監視し、必要に応じて、例えば仮想マシンをホスト間で移動させることによって、ＶＭ配置を自動的に操作する。
【００４４】
非限定的な実装では、代表的プラットフォーム技術は、ＶＭｗａｒｅ  ｖＳｐｈｅｒｅ  ４．１  Ｕｐｄａｔｅ  １および５．０を含むＩＢＭ  Ｓｙｓｔｅｍ  ｘ（Ｒ）サーバであるが、これに限定されない。
【００４５】
非集約型システムを指定するための方法およびシステム
上の説明では、複数の代表的な動作環境を示したが、次に、本開示の手法について説明する。
【００４６】
本開示の手法によれば、１つまたは複数のデータセンタ内で（またはデータセンタにまたがって）、サーバ・リソースが分解されて、共有サーバ・リソース・プール（つまり、計算プール、メモリ・プール、アクセラレータ・プール、ストレージ・プールなどのうちの１つまたは複数）に入れられる。サーバは、ワークロード要件に基づいて、これらのリソース・プールから割り当てることによって、動的に（例えば、オンデマンドに）構築される。本開示によれば、このような種類の非集約型計算システムは、共有サーバ・リソース・プール内の使用可能なリソースを追跡し、この情報に基づいて、それらのリソースを管理する。
【００４７】
一実施形態によれば、非集約型計算システムに関連付けられた追跡メカニズムは、データベースを含む。このデータベースは、リソース・プールから利用可能なサーバを定めるさまざまなリソースの状態またはステータス（例えば、アイドル状態または使用中のＣＰＵ、メモリ、アクセラレータ、およびその他のコンポーネント）を追跡するデータを格納する。さらに、このデータベースは、定められたサーバ（「サーバ・エンティティ」と呼ばれる場合もある）ごとに、サーバを構成するリソース（例えば、ＣＰＵ、メモリ、アクセラレータ、またはその他のコンポーネント）を識別するデータ・レコード（または、さらに一般的には、データ・セット）を格納する。好ましくは、このデータ・レコードは、一意のサーバＩＤなどの識別子に関連付けられ、サーバを構成する各リソースは、データベース内で、この一意のサーバ識別子に関連付けられる。リソース・プールの個々のコンポーネントも、データベース内で追跡される識別子を含む。リソース固有の識別子は、リソースのステータス、属性、他のリソースとの関係などに関する情報を提供する。したがって、データベース（集中させるか、または分散させてよい）は、サーバ・エンティティ、サーバ・プール、および特定のサーバ・エンティティを構成するさまざまなリソースに関する情報のリポジトリとして機能する。
【００４８】
データセンタのリソースに対する要求に応答して、例えば新しいサーバを割り当てる場合、１つまたは複数のリソース・プールからリソースを選択することによって、サーバ・エンティティが定められる。リソースは、予測された必要性、または要求に関連して指定された必要量、あるいはその他の基準に基づいて選択されてよい。サーバ・エンティティは一意のサーバＩＤに関連付けられ、一意のサーバＩＤは、サーバ・エンティティを構成するリソースの識別子と一緒に、データベースに格納される。その後、サーバ・エンティティは、要求、あるいは１つまたは複数の関連するか、または関連付けられた要求のワークロード要件に基づいて、必要に応じてスケールアップまたはスケールダウンされてよい。
【００４９】
したがって、例えば、要求が処理されるとき、または処理するための追加の関連する要求が受信されたときに、追跡システムは、使用量を監視して、サーバ・エンティティを構成しているリソースに対する調整が必要かどうかを決定する。監視することに基づいて、追跡システムが、サーバ・エンティティのコンポーネントにおける調整が必要であると決定した場合、この調整は、例えばサーバ・エンティティに関連付けられたリソースの割り当てを変更することによって、実行される。したがって、例えば、追加の計算およびメモリが必要な場合（スケールアップ）、追跡システムは（自動的に、またはデータセンタ内の他のリソース・プロビジョニング・システムと連携して）、例えば追加のプロセッサおよびメモリを選択することによって、サーバ・エンティティを調整し、その後、それらのプロセッサおよびメモリがサーバ・エンティティに追加される。これらの追加のプロセッサおよびメモリは、データベース内で維持および追跡されている情報によって示される、負荷、サーバ・エンティティを構成する既存のリソースへの近接性、可用性などの、１つまたは複数の基準に基づいて、選択されてよい。一方、この監視することが、必要なリソースがより少ないことを示している場合（スケールダウン）、追跡システムは、例えば特定のプロセッサおよびメモリを選択解除することによって、サーバ・エンティティを調整し、その後、それらのプロセッサおよびメモリがサーバ・エンティティから割り当て解除され、各リソース・プールに戻される。
【００５０】
ここで図６を参照して、本開示は、非集約型計算システム６００を指定するための方法およびシステムを提供する。好ましいアプローチでは、非集約型計算システム６００は、光学的に接続されたスイッチング・メモリ・アーキテクチャが使用されるデータセンタ６０５内で構成される。このアーキテクチャは、図１〜４との関連において上で説明されたが、これに限定することは意図されていない。非集約型計算システム６００内には、共有サーバ・プール（例えば、計算プール６０２、メモリ・プール６０４、アクセラレータ・プール６０６、ストレージ・プール６０８など）が存在している。リソース・プールの１つのインスタンスまたは複数のそのようなインスタンス（「複数のプール」と呼ばれることもある）が存在してよい。本明細書におけるアプローチでは、顧客のワークロードにサービスを提供する特定のサーバは、ワークロード要件に基づいて、これらのリソース・プールから割り当てることによって、動的に（例えば、オンデマンドに）構築される。したがって、例えば、第１のサーバ・エンティティ６１０は、ＣＰＵ６０２ａ（計算プール６０２から選択されるか、またはその他の方法で取得される）、メモリ６０４ｂ（メモリ・プール６０４から選択されるか、またはその他の方法で取得される）、アクセラレータ６０６ｃ（アクセラレータ・プール６０６から選択されるか、またはその他の方法で取得される）、およびストレージ６０８ｄ（ストレージ・プール６０８から選択されるか、またはその他の方法で取得される）を備えてよい。第２のサーバ・エンティティ６１２は、ＣＰＵ６０２ｂ、メモリ６０４ａ、アクセラレータ６０６ｂ、およびストレージ６０８ａを備えてよい。これらは、単に代表的例である。さらに、下で説明されているように、特定のサーバ・エンティティを構成する特定のサーバ・プールのリソースは、変化してよい。
【００５１】
好ましくは、リソース・プールの特定のリソースが特定のサーバ・エンティティに関連付けられると、その特定のリソースは、別のサーバ・エンティティを構成するために利用できなくなる。言い換えると、好ましくは、リソース・プールの割り当て済みリソースは、割り当て解除されるまで、サーバ・エンティティに関連付けられたままであり、割り当て解除された時点で、そのリソースはリソース・プールに戻され、別のサーバ・エンティティによって再び使用され得る。限定することは意図されていないが、好ましくは、サーバ・エンティティは、（作成された後に）データセンタの１人の顧客（テナント）のみに関連付けられる。言い換えると、サーバ・エンティティは、好ましくは、テナント間で共有されない。
【００５２】
そのような割り当ておよび割り当て解除を管理するために、本開示に従って、非集約型計算システム６００は、共有サーバ・リソース・プール内で利用できるリソース、およびさまざまなサーバ・エンティティに対して割り当てられたか、または割り当て解除されたリソースを追跡する能力を有する。この目的で、非集約型計算システム６００は、リソース割り当てメカニズム６１４を備えている追跡システム、および関連するデータベース・システム６１６を備える（または、それらに関連付けられる）。一般に、追跡システムは、データ処理システムとして実装され、スタンドアロン方式で、あるいは他のシステムのコンポーネントまたはデータセンタ内の機能として動作してよい。
【００５３】
通常、リソース割り当てメカニズム６１４は、ソフトウェアにおいて（つまり、コンピュータ・プログラム命令のセットとして）実装され、１つまたは複数のハードウェア・プロセッサ内で実行される。リソース割り当てメカニズム６１４は、１つまたは複数のサブシステムまたはモジュール、プロセス、プログラム、または実行スレッドを備えてよく、そのようなコンポーネントは、同一の場所に配置するか、または分散させてよい。リソース割り当てメカニズム６１４は、通常、本開示に従ってサーバ・エンティティを作成および管理する１つまたは複数の割り当てアルゴリズムを実行する責任を負う。下で説明されているように、各アルゴリズムは、例えば、サーバ・エンティティの初期構築を実行するために使用される新規サーバ割り当てアルゴリズムと、既存のサーバの場合に、ワークロードを処理するためにさらに多くの能力が必要なときに、さらに多くのリソースを既存のサーバ・エンティティに追加するために使用されるサーバ・スケールアップ・アルゴリズム（server scale-up algorithm）と、既存のサーバの場合に、ワークロードを処理するために必要な能力がさらに少ないときに、リソースを既存のサーバ・エンティティから割り当て解除（削減）するために使用されるサーバ・スケールダウン・アルゴリズム（サーバ・スケールダウン・アルゴリズム）とを含む。これらの機能のうちの１つまたは複数が結合されてよく、他の種類のアルゴリズムが、リソース割り当てメカニズム６１４によって実装されてよい。
【００５４】
リソース割り当てメカニズム６１４を含む１つまたは複数のアルゴリズムは、データベース・システム６１６に格納された情報を使用して、管理機能を実行する。前述したように、データベース・システム６１６は、共有サーバ・プール内のさまざまなリソースの、状態、ステータス、またはその他の特性および属性を追跡する情報を格納する。加えて、データベースは、リソース割り当てメカニズムによって構築された各サーバ・エンティティに関する情報を格納する。一般的に言うと、よく知られているように、データベース・システム６１６は、データベース６１８、つまり、１つまたは複数の方法で（例えば、スキーマ、テーブル、クエリ、レポート、ビュー、およびその他のオブジェクトを使用して）編成されたデータの集合を、データベース管理システム（ＤＢＭＳ：database management system）６２０と共に備えており、データベース管理システム６２０は、ユーザ、その他のアプリケーション、およびデータベースと情報をやりとりしてデータを獲得および分析するコンピュータ・ソフトウェア・アプリケーションである。汎用ＤＢＭＳは、データベースの定義、作成、問い合わせ、更新、および管理を可能にする。代表的なＤＢＭＳは、ＩＢＭ（Ｒ）  ＤＢ２（Ｒ）である。
【００５５】
一実施形態では、データベース６１８はリレーショナルである。このデータベースは、定められたサーバ・エンティティごとに、サーバを構成するリソースを識別するデータ・レコード（または、さらに一般的には、データ・セット）を格納する。好ましくは、このデータ・レコードは、識別子（一意のサーバＩＤ）に関連付けられ、サーバを構成する各リソースは、データベース内で、この一意のサーバ識別子に関連付けられる。したがって、前述した例を引き続き参照すると、第１のサーバ・エンティティ６１０は一意のサーバＩＤ１に関連付けられてよく、第２のサーバ・エンティティ６１２は一意のサーバＩＤ２に関連付けられてよい、などのようになる。
【００５６】
前述したように、好ましくは、リソース・プールの個々のコンポーネントも、データベース内で追跡される識別子を含み、リソースがサーバ・エンティティに割り当てられた場合、このリソースの識別子はこのサーバ・エンティティに関連付けられる（相互参照される）。したがって、上の第１の例を引き続き参照すると、ＣＰＵ６０２ａ、メモリ６０４ｂ、ネットワーク・アクセラレータ６０６ｃ、およびストレージ６０８ｄのさまざまなリソース固有の識別子が、（リレーショナル・テーブルまたはその他の方法によって）第１のサーバ・エンティティ６１０の一意のサーバ識別子である一意のサーバＩＤ１に関連付けられる。同様に、第２の例を引き続き参照すると、ＣＰＵ６０２ｂ、メモリ６０４ａ、アクセラレータ６０６ｂ、およびストレージ６１０ａのさまざまなリソース固有の識別子が、第２のサーバ・エンティティの一意のサーバ識別子である一意のサーバＩＤ２に関連付けられる、などのように、サーバ・エンティティごとに同様に関連付けられる。
【００５７】
サーバ・エンティティが最初に構築されるときに、サーバ・エンティティは、リソース割り当てメカニズムによってサーバ・プールから選択された１つまたは複数のサーバ・プールのリソースのセットを含む。したがって、サーバ・エンティティの一意のサーバ識別子は、リソース固有の識別子の初期セットに関連付けられる。後でリソースがサーバ・エンティティに割り当てられるか、またはサーバ・エンティティから割り当て解除されると、特定のサーバ・エンティティ識別子に関連付けられた構成要素であるリソース識別子のセットも変わる。
【００５８】
前述したように、リソース・プールの複数のインスタンスが存在してよい。複数のインスタンスが存在する場合、サーバ・エンティティをサポートするための特定のリソースが、それらのインスタンスのうちの１つまたは複数から選択される。好ましくは、リソース・プールの第１のインスタンスに割り当てられたリソースがサーバ・エンティティの構築に使用された場合、能力をこのサーバ・エンティティに追加することが必要になったときに、好ましくは、追加リソースも、可能であれば同じインスタンスから取り出される。
【００５９】
好ましくは、リソース固有の識別子は、リソースのステータス、属性、他のリソースとの関係などに関する情報を提供する。したがって、データベース（集中させるか、または分散させてよい）は、サーバ・エンティティ、サーバ・プール、および特定のサーバ・エンティティを構成するさまざまなリソースに関する情報のリポジトリとして機能する。
【００６０】
リレーショナル・データベースは実装に役立つが、サーバ・エンティティ識別子とリソース固有の識別子は、他の方法（例えば、リンク・リスト、データ配列、ハッシュ・テーブル、またはその他の方法）で互いに関連付けられてよい。
【００６１】
一般に、リソース割り当てメカニズム６１４およびデータベース・システム６１６は、連携して非集約型計算システムを管理する。リソース割り当てメカニズムは、サーバを定めるアイドル状態および使用中のＣＰＵ、メモリ、アクセラレータ、およびその他のコンポーネントを追跡する追跡システムとして機能する。さらに、追跡システムは、どのＣＰＵ、メモリ、アクセラレータ、またはその他のコンポーネントがサーバの一部であるかについての、定められた各サーバの記録を残す。前述したように、定められたサーバごとに、一意のＩＤが指定され、要求された数のＣＰＵ、メモリ、およびストレージが、下で詳細に説明されるように、例えばリソースの局所性、最良の適合性、および将来の拡張の必要性に基づいて、アイドル状態のリソースのプールから選択される。一意のサーバＩＤおよびこれらの各リソースのＩＤが、追跡システムにおいて記録される。好ましくは、前述したように、使用中のコンポーネントは、使用中としてマークが付けられ、アイドル状態のコンポーネントのプールから削除される。
【００６２】
好ましくは、サーバ・エンティティの各コンポーネントは、そのコンポーネントが含まれているサーバの一意のサーバＩＤを使用して、タグ付けされる。したがって、このコンポーネントは、一意のサーバＩＤによって識別されたサーバ・エンティティのコンポーネントであるということを認識する。
【００６３】
好ましくは、非集約型計算システムに対して発行された各要求、および要求に応答して受信されたデータも、サーバ・エンティティＩＤを使用してタグ付けされる。例えば、要求がリソースで受信された場合、このリソースは、要求にタグ付けされたサーバ・エンティティＩＤを、リソースのサーバ・エンティティＩＤと比較する。言い換えると、コンポーネントは、要求が、コンポーネントが割り当てられているサーバ・エンティティＩＤに一致するかどうかをチェックする能力を備えている。一致する場合、コンポーネントは、その要求を、使用して処理することができる要求であると認識する。要求にタグ付けされたサーバ・エンティティＩＤが、コンポーネントにタグ付けされたサーバ・エンティティＩＤと一致しない場合、コンポーネントは、その要求を無視できるということを認識する。
【００６４】
下で説明されているように、リソース選択（新規サーバ割り当て、サーバ・スケールアップ、およびサーバ・スケールダウン）に使用されるアルゴリズムは、選択を容易にするために共通の基準を使用することができ、またはこれらのアルゴリズムは、例えばリソースのトポロジおよびリソース割り当ての目的に基づいて、互いに異なるものにすることができる。リソースが相互接続された場合、割り当てられるリソースにおけるさらに高い柔軟性をシステムで利用できる。直接相互接続されないリソースの場合、好ましくは、アルゴリズムは、リソースの階層、ならびにホップ数、待ち時間、およびコストなどのその他の要因を考慮する。後者の場合、好ましくは、アルゴリズムは、ホップ数を最小限に抑えるよう試みる。
【００６５】
図７は、第１の実施形態に記載された、新規サーバ割り当てのプロセス・フローを示している。このプロセスは、例示的な新規サーバ割り当てアルゴリズムを説明している。一般に、このアルゴリズムは、プールをチェックし、サーバ・エンティティの要件に最も良く適合するリソース・プール（およびリソース・プール内のリソース）を決定することによって動作する。前述したように、プール自体の性質および構成に応じて、複数のプールがサーバ・エンティティの基準を満たす場合があり、その場合、新規サーバ割り当てアルゴリズムは、好ましくは、計算システムの将来の拡張を可能にするために、最大のリソースを利用できるプールからリソースを割り当てる。
【００６６】
新しいサーバの要求の受信時に、ステップ７００で、新規サーバ割り当てプロセスを開始する。この要求は、ユーザ、あるいはエンティティまたはシステムを要求している何かから受信されてよい。この要求は、プログラムで受信されてよい。新規サーバ割り当てプロセスは、サーバ・プールおよびサーバ・プールに関連するリソースに関する情報のデータベースにアクセスすることができる。ステップ７０２で、システムが、初期割り当てアルゴリズムを使用してリソースを割り当てる。初期割り当てアルゴリズムは、リソース・プールの数および構成、リソースが相互接続されているかどうか、そのような相互接続の性質などを考慮してよいが、これらに限定されない。ただし、利用される特定の初期リソース割り当て方法は、本開示の制限にならない。必要なプールおよびプール内のリソースを選択した後に、ステップ７０４で、一意のサーバ識別子（構築された新しいサーバ定義を表す）が生成される。次に、ステップ７０６で、システムが追跡システムを更新し、新しいサーバ定義をデータベースに追加する。ステップ７０８で、追跡システムが、新しいサーバ・エンティティ用に選択されたリソースが利用できなくなった（すなわち、使用中である）ことを反映するように、さらにデータベースを更新する。ステップ７１０で、定められた新しいサーバ・エンティティに関連付けられた各リソースが、一致するタグを持っているサービス要求に応答できるように、一意のサーバ識別子を使用してタグ付けされる。
【００６７】
図８は、第２の実施形態に記載された、サーバ・スケールアップ・リソース割り当て方法のプロセス・フローを示している。一般に、前述したように、アルゴリズムは、さらに多くのリソースを既存のサーバ・エンティティに追加するように動作する。スケールアップが必要な場合、アルゴリズムは、局所性に基づいてリソースを優先する。その選択では、他のすべてが同じであるとき、サーバ・エンティティ内にすでに存在するリソースに（ネットワーク的に）「より近い」リソースが、より遠いリソースよりも優先される。当然、近い、または遠いという概念は相対的な用語であり、１つまたは複数の要因（例えば、待ち時間、損失、コスト、ホップ数など）に依存してよい。１つのアプローチでは、システムは、割り当て済みのリソースに最も近いリソースを検出しようとする。ただし、他の基準を使用する他のスケールアップ手法が使用されてよいため、これは制限ではない。
【００６８】
ステップ８００で、ユーザまたは何らかの他のシステムが、サーバ・エンティティのさらに多くの能力を要求した場合、ルーチンを開始する。この要求は、プログラムで受信されてよい。ステップ８０２で、システムが、使用される特定のリソース・スケールアップ割り当てアルゴリズムに基づいて、一意のサーバＩＤに対してさらに多くのリソースを割り当てることによって、応答する。利用される特定のスケールアップ・リソース選択方法は、本開示の制限にならない。ステップ８０４で、追跡システムが、新しく割り当てられたリソースが現在使用中であることを示すように更新される。次に、ルーチンは８０６に進み、前と同様に、新しく割り当てられた各リソースが、一意のサーバＩＤを使用してタグ付けされる。
【００６９】
図９は、第３の実施形態に記載された、サーバ・スケールダウン・リソース割り当て方法のプロセス・フローを示している。通常、このプロセスは、既存のサーバ・エンティティから割り当て解除するリソースを選択するために使用される。スケールダウンするためのさまざまなアプローチが存在してよい。例えば、割り当て解除されるべきリソースは、利用可能なプールのサイズを最大化すること、プール自体のサイズを最大化することなどのために、リソース・プールからリソースを解放する位置に基づいて選択されてよい。例えば、プール間でバランスをとることを促進するために、これらの要因のラウンド・ロビン選択が実施されてよい。別の変形では、アルゴリズムは、割り当てが特定のワークロードにとって最適な解決策であるかどうかを分析し、最適でない場合、ワークロードの性能が低下することをユーザに警告する。さらに別の変形では、アルゴリズムは、特定のワークロードに基づいてシステムで必要とされる能力を予測し、適切に推奨を行う。
【００７０】
ステップ９００で、ユーザまたは何らかの他のシステムから能力の削減の要求を受信したときに、ルーチンを開始する。この要求は、プログラムで受信されてよい。ステップ９０２で、システムが、アルゴリズムを実行し、リソースをサーバ・エンティティから割り当て解除することによって、要求に応答する。利用される特定のスケールダウン・リソース選択方法は、本開示の制限にならない。ステップ９０４で、割り当て解除されたリソースが各リソース・プールに戻されていて、アイドル状態になっておらず、一意のサーバＩＤを更新するように、追跡システムが更新される。ステップ９０６で、タグ（サーバ・エンティティを識別する）がリソース識別子から削除されて、プロセスを完了する。
【００７１】
したがって、データセンタのリソースに対する要求に応答して、例えば新しいサーバを割り当てる場合、１つまたは複数のリソース・プールからリソースを選択することによって、サーバ・エンティティが定められる。リソースは、予測された必要性、または要求に関連して指定された必要量、あるいはその他の基準に基づいて選択されてよい。サーバ・エンティティは一意のサーバＩＤに関連付けられ、一意のサーバＩＤは、サーバ・エンティティを構成するリソースの識別子と一緒に、データベースに格納される。その後、サーバ・エンティティは、要求、あるいは１つまたは複数の関連するか、または関連付けられた要求のワークロード要件に基づいて、必要に応じてスケールアップまたはスケールダウンされてよい。
【００７２】
したがって、例えば、要求が処理されるとき、または処理するための追加の関連する要求が受信されたときに、追跡システムは、使用量を監視して、サーバ・エンティティを構成しているリソースに対する調整が必要かどうかを決定する。使用量は、データセンタ内の１つまたは複数の監視システムまたは監視サブシステムによって監視される。特定の監視サブシステムは、特定のサーバ・リソース・タイプに関連付けられてよい。したがって、例えば、１つの監視サブシステムがメモリ・システムの監視に使用されてよく、一方で、第２の監視サブシステムがＣＰＵの監視に使用される。監視することは、すべて既知の方法でリソースの状態またはステータスに関する情報を提供するように、リソースをプロビジョニングまたは構成することによって、実現される。監視サブシステムは、分散させて、データを中央モニタに提供してよく、この中央モニタは、サーバ・エンティティを収集して分析し、調整が必要かどうかを決定し、調整が必要な場合は、その調整の性質および範囲を決定する。
【００７３】
監視に基づいて、追跡システムが、サーバ・エンティティのコンポーネントにおける調整が必要であると決定した場合、この調整は、例えばサーバ・エンティティに関連付けられたリソースの割り当てを変更することによって、実行される。したがって、例えば、追加の計算およびメモリが必要な場合（スケールアップ）、追跡システムは（自動的に、またはデータセンタ内の他のリソース・プロビジョニング・システムと連携して）、例えば追加のプロセッサおよびメモリを選択することによって、サーバ・エンティティを調整し、その後、それらのプロセッサおよびメモリがサーバ・エンティティに追加される。これらの追加のプロセッサおよびメモリは、データベース内で維持および追跡されている情報によって示される、負荷、サーバ・エンティティを構成する既存のリソースへの近接性、可用性、消費電力、発熱などの、１つまたは複数の基準に基づいて、選択されてよい。一方、この監視することが、必要なリソースがより少ないことを示している場合（スケールダウン）、追跡システムは、例えば特定のプロセッサおよびメモリを選択解除することによって、サーバ・エンティティを調整し、その後、それらのプロセッサおよびメモリがサーバ・エンティティから割り当て解除され、各リソース・プールに戻される。
【００７４】
本明細書に記載された手法は、大きな利点を提供する。それらは、初期リソースが予測された必要性に基づいて適切に割り当てられること、およびダウンタイムがなく、顧客への影響を最小限に抑えるか、または顧客への影響がない、物理的または仮想的ハードウェア能力の動的スケールアップまたはスケールダウンを可能にする。サーバ・エンティティは、プロセッサのサブセット、メモリのサブセットなどの割り当てから構築されるので、ワークロードの処理に必要なリソースのみが使用される。さらに、スケールアップが必要な場合、システムは、低コストで良好な性能を継続的に保証するために、好ましくは局所性の考慮（すなわち、追加リソースが存在する場所）に基づいて、必要な追加リソースを取得する。このアプローチは非集約型サーバを利用するので、これらの利点によって、データセンタは、より大きいモジュール性、より高いリソース利用率、より低いコスト、およびより良い性能を実現できる。実際、大規模なデータセンタが出現し、サーバ数が増加し続けるクラウドに対する必要性がある状況で、このアプローチは、データセンタがさらにコスト効率が高く、信頼できる方法で稼働するための手段を提供する。サーバ・エンティティが必要に応じて構築され、それらのエンティティを構成しているリソースが、必要に応じて動的に変更される。このアプローチは、ワークロード要件との不一致またはワークロード要件の変更に起因して、含まれている１つまたは複数のリソースの利用率が低下した場合にリソースのフラグメンテーションが発生するという、従来のサーバの使用から生じるワークロード割り当ての問題を解決する。本明細書に記載された共有リソース・プールおよびリソース割り当て方法を使用することによって、ワークロードの要件に従ってそれらのリソース・プールから割り当てることにより、サーバが動的かつオンデマンドで構築される。
【００７５】
本明細書に記載された利点は、さまざまなサーバ・リソース・プール（resource server pools）を維持して使用することによって、かつサーバ・エンティティの生成および管理を可能にするリソース割り当てメカニズムによって提供される。追跡システム、ならびに追跡システムに関連した、一意のサーバ識別子および一意のサーバ識別子に関連するデータのデータベースをさらに含むそのようなアプローチの実施形態は、システムがサーバ・リソース・プールに対するより堅牢なインベントリ管理を提供できるようにし、スケールアップ・アルゴリズムおよびスケールダウン・アルゴリズムがより効率的に動作することを保証できるようにする。それらの一意のサーバ識別子をリソースのタグとしても使用する、そのようなアプローチのさらに別の実施形態は、サーバ・エンティティに関連付けられていないリソースが、処理されるべきサーバの要求を処理していないということを保証するので、さらに追加の利点を提供する。
【００７６】
前述したように、上で説明された機能は、スタンドアロンのアプローチ（例えば、プロセッサによって実行されるソフトウェアベースの機能）として実装されてよく、またはサービス（ＳＯＡＰ／ＸＭＬインターフェイスを介したＷｅｂサービスを含む）として利用されてもよい。本明細書に記載された特定のハードウェアおよびソフトウェアの実装の詳細は、単に例示を目的としており、記載された主題の範囲を制限するようには意図されていない。
【００７７】
さらに一般的には、開示された主題との関連において、コンピューティング・デバイスはそれぞれ、ハードウェアおよびソフトウェアを備えているデータ処理システムであり、これらのエンティティは、ネットワーク（インターネット、イントラネット、エクストラネット、プライベート・ネットワーク、あるいは任意のその他の通信媒体またはリンクなど）を経由して互いに通信する。データ処理システム上のアプリケーションは、特にＨＴＴＰ、ＦＴＰ、ＳＭＴＰ、ＳＯＡＰ、ＸＭＬ、ＷＳＤＬ、ＵＤＤＩ、およびＷＳＦＬのサポートを含むが、これらに限定されない、Ｗｅｂならびにその他の既知のサービスおよびプロトコルのネイティブ・サポートを提供する。ＳＯＡＰ、ＷＳＤＬ、ＵＤＤＩ、およびＷＳＦＬに関する情報は、これらの規格を開発および維持する役割を担っているワールド・ワイド・ウェブ・コンソーシアム（Ｗ３Ｃ：World Wide Web Consortium）から提供されており、ＨＴＴＰ、ＦＴＰ、ＳＭＴＰ、およびＸＭＬに関するさらなる情報は、インターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ：Internet Engineering Task Force）から提供されている。これらの既知の規格およびプロトコルを熟知していることが仮定される。
【００７８】
本明細書に記載された手法は、単純なｎ層アーキテクチャ、Ｗｅｂポータル、フェデレーテッド・システムなどを含む、さまざまなサーバサイド・アーキテクチャ内で、またはこれらと併せて、実装されてよい。前述したように、本明細書における手法は、疎結合されたサーバ（「クラウド」ベースを含む）環境内で実践されてもよい。
【００７９】
さらに一般的には、本明細書に記載された主題は、完全にハードウェアである実施形態、完全にソフトウェアである実施形態、またはハードウェアとソフトウェアの両方の要素を含んでいる実施形態の形態をとることができる。好ましい実施形態では、信頼できるプラットフォーム・モジュールの機能が、ファームウェア、常駐ソフトウェア、マイクロコードなどを含むがこれらに限定されないソフトウェアにおいて実装される。さらに、ダウンロードおよび削除のインターフェイスおよび機能は、コンピュータまたは任意の命令実行システムによって、またはこれらに関連させて使用するためのプログラム・コードを提供するコンピュータ使用可能媒体またはコンピュータ可読媒体からアクセスできるコンピュータ・プログラム製品の形態をとることができる。この説明の目的で、コンピュータ使用可能媒体またはコンピュータ可読媒体は、命令実行システム、命令実行装置、または命令実行デバイスによって、またはこれらに関連させて使用するためのプログラムを含むか、または格納することができる任意の装置であることができる。この媒体は、電子システム、磁気システム、光システム、電磁気システム、赤外線システム、または半導体システム（あるいは、装置またはデバイス）であることができる。コンピュータ可読媒体の例としては、半導体メモリまたは固体メモリ、磁気テープ、取り外し可能コンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ：random access memory）、読み取り専用メモリ（ＲＯＭ：read-only memory）、剛体磁気ディスク、および光ディスクが挙げられる。光ディスクの現在の例としては、コンパクト・ディスク読み取り専用メモリ（ＣＤ−ＲＯＭ：compact disk-read only memory）、コンパクト・ディスク読み取り／書き込み（ＣＤ−Ｒ／Ｗ：compact disk-read/write）、およびＤＶＤが挙げられる。コンピュータ可読媒体は、有形の非一時的アイテムである。
【００８０】
コンピュータ・プログラム製品は、記載された機能のうちの１つまたは複数を実装するためのプログラム命令（またはプログラム・コード）を含んでいる製品であってよい。これらの命令またはコードは、ネットワークを経由してリモート・データ処理システムからダウンロードされた後に、データ処理システム内の非一時的コンピュータ可読記憶媒体に格納されてよい。または、これらの命令またはコードは、サーバ・データ処理システム内のコンピュータ可読記憶媒体に格納され、リモート・システム内のコンピュータ可読記憶媒体において使用するために、ネットワークを経由してリモート・データ処理システムにダウンロードされるように適合されてよい。
【００８１】
代表的実施形態では、インターフェイスおよびユーティリティが、専用コンピューティング・プラットフォーム内で、好ましくは１つまたは複数のプロセッサによって実行されるソフトウェア内で、実装される。ソフトウェアは、１つまたは複数のプロセッサに関連付けられた１つまたは複数のデータ・ストアまたはメモリ内で維持され、ソフトウェアは、１つまたは複数のコンピュータ・プログラムとして実装されてよい。集合的に、この専用ハードウェアおよびソフトウェアは、前述した機能を備える。
【００８２】
上では、本発明の特定の実施形態によって実行される特定の順序の処理を説明したが、代替の実施形態が、処理を異なる順序で実行すること、特定の処理を組み合わせること、特定の処理を重ね合わせることなどを実行してよいため、そのような順序は例であると理解されるべきである。本明細書における特定の実施形態例への参照は、記載された実施形態が特定の特徴、構造、または特性を含むことができるが、必ずしもすべての実施形態がこの特定の特徴、構造、または特性を含まなくてもよいということを示している。
【００８３】
最後に、システムの特定のコンポーネントが別々に説明されたが、当業者は、機能の一部が、特定の命令、プログラム・シーケンス、コード部分などにおいて、組み合わされるか、または共有されてよいということを理解するであろう。
【００８４】
本明細書における手法は、通常、技術または技術分野に対する前述の改良、および前述したようなワークロード管理方式に対する特定の技術的改良を提供する。
【００８５】
以上で本発明を説明したが、特許請求の範囲は次のとおりである。
【図１】
2019511051.tif 000003
【図２】
2019511051.tif 000004
【図３】
2019511051.tif 000005
【図４】
2019511051.tif 000006
【図５】
2019511051.tif 000007
【図６】
2019511051.tif 000008
【図７】
2019511051.tif 000009
【図８】
2019511051.tif 000010
【図９】
2019511051.tif 000011
【手続補正書】
【提出日】平成31年1月8日(2019.1.8)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
計算環境内でリソースを割り当てるための方法であって、
サーバ・リソース・プールのセットを提供することであって、サーバ・リソース・プールが一般的な種類のリソースのセットを含んでいる、前記提供することと、
要求の受信に応答して、前記サーバ・リソース・プールのうちの２つ以上から選択された１つまたは複数のリソースで構成されたサーバ・エンティティを定めることであって、前記１つまたは複数のリソースが、前記要求に関連付けられた予測されたワークロードに基づいて、前記サーバ・リソース・プールのうちの前記２つ以上から選択される、前記定めることと、
前記ワークロードが処理されるときに前記１つまたは複数のリソースを監視することから収集された情報を受信することと、
前記監視することに基づいて、前記ワークロードにおける変更に応じて、前記サーバ・エンティティの構成を調整することと
を含む、方法。
【請求項２】
一意のサーバ識別子を前記サーバ・エンティティに関連付けることであって、前記一意のサーバ識別子が、選択された前記１つまたは複数のリソースのそれぞれにも関連付けられる、前記関連付けることと、
前記サーバ・エンティティの前記構成の調整を反映するように前記一意のサーバ識別子を更新することと
をさらに含む、請求項１に記載の方法。
【請求項３】
前記サーバ・リソース・プールを共有した共有サーバ・リソース・プールであって、前記共有サーバ・リソース・プールが、計算プールおよびメモリ・プールのうちの少なくとも１つである、請求項１に記載の方法。
【請求項４】
前記サーバ・エンティティの前記構成が、サーバ・リソース・プールの１つまたは複数のリソースを前記サーバ・エンティティに追加することによって調整される、請求項１に記載の方法。
【請求項５】
前記サーバ・エンティティに追加される前記１つまたは複数のリソースが、前記サーバ・エンティティ内にすでに存在する他の前記リソースに対するリソースのネットワーク局所性に基づいて選択される、請求項４に記載の方法。
【請求項６】
前記サーバ・エンティティの前記構成が、サーバ・リソース・プールの１つまたは複数のリソースを前記サーバ・エンティティから削除することによって調整される、請求項１に記載の方法。
【請求項７】
前記サーバ・エンティティから削除された前記１つまたは複数のリソースを前記サーバ・リソース・プールに戻すことをさらに含む、請求項６に記載の方法。
【請求項８】
前記一意のサーバ識別子を、前記ワークロードに関連付けられたサービス要求に関連付けることと、
特定のリソースで、前記特定のリソースに関連付けられた同じ一意のサービス識別子に前記サービス要求が関連付けられているということの決定時に、前記サービス要求に対してサービスを提供することと
をさらに含む、請求項２に記載の方法。
【請求項９】
計算環境内でリソースを割り当てるための装置であって、
１つまたは複数のハードウェア・プロセッサと、
前記ハードウェア・プロセッサによって実行されるコンピュータ・プログラム命令を保持しているコンピュータ・メモリとを備え、前記コンピュータ・プログラム命令が、
サーバ・リソース・プールのセットを管理することであって、サーバ・リソース・プールが一般的な種類のリソースのセットを含んでいる、前記管理することと、
要求の受信に応答して、前記サーバ・リソース・プールのうちの２つ以上から選択された１つまたは複数のリソースで構成されたサーバ・エンティティを定めることであって、前記１つまたは複数のリソースが、前記要求に関連付けられた予測されたワークロードに基づいて、前記サーバ・リソース・プールのうちの前記２つ以上から選択される、前記定めることと、
前記ワークロードが処理されるときに前記１つまたは複数のリソースを監視することから収集された情報を受信することと、
前記監視することに基づいて、前記ワークロードにおける変更に応じて、前記サーバ・エンティティの構成を調整することと
を実行するように機能する、装置。
【請求項１０】
前記コンピュータ・プログラム命令が、
一意のサーバ識別子を前記サーバ・エンティティに関連付けることであって、前記一意のサーバ識別子が、選択された前記１つまたは複数のリソースのそれぞれにも関連付けられる、前記関連付けることと、
前記サーバ・エンティティの前記構成の調整を反映するように前記一意のサーバ識別子を更新することと
を実行するようにさらに機能する、請求項９に記載の装置。
【請求項１１】
前記サーバ・リソース・プールを共有した共有サーバ・リソース・プールであって、前記共有サーバ・リソース・プールが、計算プールおよびメモリ・プールのうちの少なくとも１つである、請求項９に記載の装置。
【請求項１２】
前記サーバ・エンティティの前記構成が、サーバ・リソース・プールの１つまたは複数のリソースを前記サーバ・エンティティに追加することによって調整される、請求項９に記載の装置。
【請求項１３】
前記サーバ・エンティティに追加される前記１つまたは複数のリソースが、前記サーバ・エンティティ内にすでに存在する他の前記リソースに対するリソースのネットワーク局所性に基づいて選択される、請求項１２に記載の装置。
【請求項１４】
前記サーバ・エンティティの前記構成が、サーバ・リソース・プールの１つまたは複数のリソースを前記サーバ・エンティティから削除することによって調整される、請求項９に記載の装置。
【請求項１５】
前記コンピュータ・プログラム命令が、前記サーバ・エンティティから削除された前記１つまたは複数のリソースを前記サーバ・リソース・プールに戻すようにさらに機能する、請求項１４に記載の装置。
【請求項１６】
前記コンピュータ・プログラム命令が、
前記一意のサーバ識別子を、前記ワークロードに関連付けられたサービス要求に関連付けることと、
特定のリソースで、前記特定のリソースに関連付けられた同じ一意のサービス識別子に前記サービス要求が関連付けられているということの決定時に、前記サービス要求に対してサービスを提供することと
を実行するようにさらに機能する、請求項１０に記載の装置。
【請求項１７】
計算環境内のリソースを割り当てるためにデータ処理システムにおいて使用するための非一時的コンピュータ可読媒体内のコンピュータ・プログラム製品であって、前記コンピュータ・プログラム製品が前記データ処理システムにおいて実行されるコンピュータ・プログラム命令を保持しており、前記コンピュータ・プログラム命令が、
サーバ・リソース・プールのセットを管理することであって、サーバ・リソース・プールが一般的な種類のリソースのセットを含んでいる、前記管理することと、
要求の受信に応答して、前記サーバ・リソース・プールのうちの２つ以上から選択された１つまたは複数のリソースで構成されたサーバ・エンティティを定めることであって、前記１つまたは複数のリソースが、前記要求に関連付けられた予測されたワークロードに基づいて、前記サーバ・リソース・プールのうちの前記２つ以上から選択される、前記定めることと、
前記ワークロードが処理されるときに前記１つまたは複数のリソースを監視することから収集された情報を受信することと、
前記監視することに基づいて、前記ワークロードにおける変更に応じて、前記サーバ・エンティティの構成を調整することと
を実行するように機能する、コンピュータ・プログラム製品。
【請求項１８】
前記コンピュータ・プログラム命令が、
一意のサーバ識別子を前記サーバ・エンティティに関連付けることであって、前記一意のサーバ識別子が、選択された前記１つまたは複数のリソースのそれぞれにも関連付けられる、前記関連付けることと、
前記サーバ・エンティティの前記構成の調整を反映するように前記一意のサーバ識別子を更新することと
を実行するようにさらに機能する、請求項１７に記載のコンピュータ・プログラム製品。
【請求項１９】
前記サーバ・リソース・プールを共有した共有サーバ・リソース・プールであって、前記共有サーバ・リソース・プールが、計算プールおよびメモリ・プールのうちの少なくとも１つである、請求項１７に記載のコンピュータ・プログラム製品。
【請求項２０】
前記サーバ・エンティティの前記構成が、サーバ・リソース・プールの１つまたは複数のリソースを前記サーバ・エンティティに追加することによって調整される、請求項１７に記載のコンピュータ・プログラム製品。
【請求項２１】
前記サーバ・エンティティに追加される前記１つまたは複数のリソースが、前記サーバ・エンティティ内にすでに存在する他の前記リソースに対するリソースのネットワーク局所性に基づいて選択される、請求項２０に記載のコンピュータ・プログラム製品。
【請求項２２】
前記サーバ・エンティティの前記構成が、サーバ・リソース・プールの１つまたは複数のリソースを前記サーバ・エンティティから削除することによって調整される、請求項１７に記載のコンピュータ・プログラム製品。
【請求項２３】
前記コンピュータ・プログラム命令が、前記サーバ・エンティティから削除された前記１つまたは複数のリソースを前記サーバ・リソース・プールに戻すようにさらに機能する、請求項２２に記載のコンピュータ・プログラム製品。
【請求項２４】
前記コンピュータ・プログラム命令が、
前記一意のサーバ識別子を、前記ワークロードに関連付けられたサービス要求に関連付けることと、
特定のリソースで、前記特定のリソースに関連付けられた同じ一意のサービス識別子に前記サービス要求が関連付けられているということの決定時に、前記サービス要求に対してサービスを提供することと
を実行するようにさらに機能する、請求項１８に記載のコンピュータ・プログラム製品。
【請求項２５】
データセンタ・ファシリティであって、
サーバ・リソース・プールのセットであって、前記サーバ・リソース・プールが少なくとも計算プールおよびメモリ・プールを含んでいる、前記サーバ・リソース・プールのセットと、
前記計算プールから選択されたプロセッサ、前記メモリ・プールから選択されたコンピュータ・メモリ、および光相互接続を備えている少なくとも１つの非集約型計算システムと、
前記非集約型計算システムを定める一意のサーバ識別子を格納するデータベースであって、前記一意のサーバ識別子が、前記データベース内で、前記非集約型計算システム内の前記プロセッサおよびコンピュータ・メモリごとの識別子に関連付けられている、前記データベースと、
前記非集約型計算システムにおけるワークロードの変化に応答して、ワークロードの必要量に従って、前記非集約型計算システムの前記プロセッサまたは前記コンピュータ・メモリの構成を選択的に調整する、追跡システムと
を備えており、
前記一意のサーバ識別子が、前記非集約型計算システムの前記構成の調整を反映するように前記データベース内で更新される、データセンタ・ファシリティ。
【請求項２６】
局所性、予想されるワークロードへの最良の適合性、および前記データセンタ・ファシリティに関連する将来の拡張要件のうちの１つに基づいて、前記プロセッサおよびコンピュータ・メモリが選択される、請求項２５に記載のデータセンタ・ファシリティ。
【国際調査報告】
2019511051.tif 000012
2019511051.tif 000013