JP2019518260A - メモリ・プール・アーキテクチャ用のマルチテナント・メモリ・サービスのための方法、装置、コンピュータ・プログラム製品、データセンタ・ファシリティ - Google Patents

Abstract

【課題】データセンタ運用環境内のデータ処理システムを提供する。【解決手段】メモリ管理サービスが、非集約型計算環境内のメモリ・システム全体のうちの構成可能な部分を占める。このサービスは、システムがアクセスできる実メモリのプールに対する最適化されたデータ編成能力を提供する。このサービスは、さまざまな種類のデータ・ストアを、データ構造レベルなどで、ハードウェア内で実装できるようにする。メモリ・プール全体で、高性能で再利用可能なデータ構造の実装を作成および管理し、その後、データ編成をいつ使用するべきかを決定するために、分析（例えば、マルチテナントの類似性および重複の検出）を使用して、ストレージ容量の節約が可能になる。このサービスは、データの使用パターンおよび分散パターンを前提として、メモリを、より効率的であることがある異なるデータ構造に再編成してもよい。また、このサービスは、有利なことに、自動化されたバックアップを効率的に管理する。【選択図】図２

Description

本開示は、データセンタ運用環境内のデータ処理システムに一般に関する。

よく知られた情報技術（ＩＴ：information technology）配信モデルは、クラウド・コンピューティングである。クラウド・コンピューティングによって、共有されたリソース、ソフトウェア、および情報が、インターネットを経由してオンデマンドでコンピュータおよびその他のデバイスに提供される。クラウド・コンピューティングは、ＩＴのコストおよび複雑性を大幅に低減しながら、ワークロード最適化およびサービス配信を改善する。このアプローチでは、アプリケーション・インスタンスがホストされ、例えばＨＴＴＰ経由で従来のＷｅｂブラウザを介して、アクセス可能なインターネットベースのリソースから利用可能になる。クラウドの計算リソースは、通常は仮想化アーキテクチャを使用して、１つまたは複数のネットワーク・アプリケーションを実行する大規模なサーバ・ファームに収容されることが多い。仮想化アーキテクチャでは、アプリケーションは、データセンタ・ファシリティ内の物理サーバにマッピングされた仮想サーバまたはいわゆる「仮想マシン」（ＶＭ：virtual machine）内で実行される。

データセンタ自体の内部では、データセンタのネットワークが、通常は、電気的スイッチの複数の層（つまり、アクセス層、集約層、およびコア層）を含んでいる階層設計に従って設計される。データセンタのフロント・エンドでは、コンテンツおよび負荷バランシング・スイッチ（content and load balancing switches）がゲートウェイ・ルータを介してインターネットに接続され、一方、バック・エンドでは、それらがコア・スイッチにリンクされる。通常、コア・スイッチは集約スイッチにリンクされ、集約スイッチはラック・スイッチに接続される。各ラック・スイッチは、ラック内のサーバに接続される。データセンタのネットワーク内のスイッチは、通常は電子スイッチ・ファブリック（electronic switch fabric）上で動作し、それらのスイッチ間のリンクは、銅ケーブルまたは光ファイバのいずれかである。外部ネットワークから要求が来た場合、その要求は、最初に負荷バランシングおよびコンテンツ・スイッチ（load balancing and content switches）に到達し、負荷バランシングおよびコンテンツ・スイッチは、要求を適切なサーバにルーティングする。要求を満たすために、サーバは、同じラックまたは異なるラック内の他のサーバと協調することができる。例えば、アプリケーション・サーバは、データベース・サーバと協調して、要求を処理することができる。要求の完了後に、応答がゲートウェイ・ルータを介して外部ネットワークに送信される。

説明したような従来のデータセンタ・アーキテクチャは、スケーラビリティ、フォールト・トレランス、およびエネルギー効率を含むが、これらに限定されない、多くの課題に直面している。これらの課題のため、多くのデータセンタ・アーキテクチャは、クラウド・コンピューティングの需要の増大に対処することに苦労している。さらに、サーバ（特に、サーバのメモリ）が独立して管理されるため、これらのアーキテクチャは、メモリ管理、データの重複、および非効率的なメモリ割り当てに関して、非常に非効率的である。

拡張メモリとして機能するためにデータセンタ内の他の処理リソースによってアクセスおよび使用され得る「メモリ・プール」を提供することが、従来技術において知られている。これらのアプローチは、コピー方式を容易にするように設計される。そのよう方式では、メモリのチャンクを、拡張メモリから、処理ブレード上のプロセッサに直接配置されたか、または取り付けられたより小さいメモリにコピーまたはページングする。しかし、この直接的な固定されたメモリは、ページング・メカニズムに関連する遅延が一部のコードを妨げることに起因する性能上の問題を引き起こすため、異なるインスタンスのメモリの内容を全体として切り替えることを妨げる。

"Draft NIST Working Definition of Cloud Computing" by Peter Mell and Tim Grance, dated October 7, 2009

これらおよびその他の従来技術のアプローチに関連する非効率性に対処するように、メモリ・プールを実装および管理することが望ましい。従って、発明が解決しようとする課題はメモリ・プール・アーキテクチャ用のマルチテナント・メモリ・サービスを提供することである。

「非集約型サーバ」アーキテクチャは、メモリ管理サービスを提供することによって改良される。非集約型サーバのアプローチでは、データセンタ内の類似する種類のサーバ・リソースが、計算プール、メモリ・プール、およびストレージ・プールなどの各プールに集約される。その後、テナントのワークロードの要件を満たすように、プールから適切な量のリソースを割り当てることによって、サーバが動的に構築される。非集約型サーバのアプローチは、異なるテナントおよび処理コンポーネントの間でメモリ・コンポーネントを使用、再利用、または共有することができるため、従来のデータセンタ・アーキテクチャと比較して、リソース利用率を向上させる。本開示によれば、メモリが他のシステム・コンポーネントとは独立して管理されるため、独自の管理能力を作り出す機会を提供し、大きな恩恵をもたらすことができる。

本開示の第１の態様によれば、マルチテナント計算環境（multi-tenant compute environment）内のメモリを管理するための方法が提供される。この方法は、メモリ・リソース・プールを提供することから開始する。特定のワークロードに関して、メモリ・リソースがメモリ・リソース・プールからプロセッサのセットに割り当てられる。特定のワークロードのデータは、ハッシュ・テーブル、リンク・リストなどのデータ構造に従って、割り当てられたメモリ・リソース内で編成される。ワークロードが処理されるときに、この方法は、特定のワークロードのデータ構造内のデータの再編成が、データ構造によって使用されるメモリの性能を向上させるかどうか、またはそのようなメモリを節約するかどうかを（例えば、分析に基づいて）決定する。再編成がメモリの性能を向上させるということ、またはメモリを節約するということを決定したときに、特定のメモリ管理動作が実行されて、データを管理する。

本開示の第２の態様によれば、計算環境内のリソースを割り当てるための装置が説明される。この装置は、１つまたは複数のハードウェア・プロセッサのセットと、前述したステップなどの一連の処理を実行するためにハードウェア・プロセッサによって実行されるコンピュータ・プログラム命令を保持するコンピュータ・メモリとを備える。

本開示の第３の態様によれば、計算環境内のリソースを割り当てるためにデータ処理システムにおいて使用される、非一時的コンピュータ可読媒体内のコンピュータ・プログラム製品が説明される。コンピュータ・プログラム製品は、データ処理システムにおいて実行され、前述のステップなどの処理を実行するように機能するコンピュータ・プログラム命令を保持する。

本開示の第４の態様によれば、データセンタ・ファシリティが説明される。データセンタは、メモリ・プール、光相互接続、およびメモリ・マネージャを備えている。メモリ管理は、ハードウェア要素内で実行され、メモリ・リソース・プールから複数のテナントのワークロード用のプロセッサのセットへの、メモリ・リソースの割り当てを管理するように機能する。このマネージャは、データ構造に従って特定のテナントのワークロードのデータを編成することと、データ構造内のデータを選択的に再編成して、データ構造の性能を向上させ、特定のテナントのワークロードにサービスを提供するために必要なメモリを削減することとを実行するようにも機能する。

本開示のメモリ・サービスは、好ましくは、メモリ・システム全体のうちの構成可能な部分を占め、メモリ・システムの残りの部分を、標準的な高性能の読み込み／格納処理（load-store operations）のために空いたままにする。このサービスは、システムがすでにアクセスできる実メモリのプールに対する最適化されたデータ編成能力を提供する。この目的で、このメモリ・サービスは、データ構造レベルなどで、ハードウェア内で特定の種類のデータ・ストアを実装する能力を提供する。一実施形態では、このメモリ・サービスは、メモリ・プール全体での高性能で再利用可能なデータ構造の実装の作成および管理を可能にすることによって、ならびにデータの編成を実行する価値があるかどうか、およびいつ実行するかを決定するために、さまざまな分析（例えば、マルチテナントの類似性、重複の検出など）を使用する能力によって、データ構造の性能管理およびストレージ容量の節約を行う。したがって、このサービスは、好ましくは、データ構造内の類似性および重複を（ワークロード間でも）検出することによって、容量の必要性を利用して削減し、メモリ空間を節約する。望ましい場合、このサービスは、データ構造の性能を継続的に改善するために、例えば監視されているデータ使用パターンまたはデータ分散に基づいて、データ構造自体を変更または調整してもよい。さらに別の特徴は、好ましくは、データのコピーがハードウェア・プロセッサを通ることを必要とせずに、自動化されたバックアップを提供できることである。

以上では、開示される主題のより関連する特徴の一部について概説した。これらの特徴は、単に例であると解釈されるべきである。説明されるように、開示された主題を異なる方法で適用することによって、または主題を変更することによって、多くのその他の有益な結果を実現できる。

主題および主題の利点をさらに完全に理解するために、ここで、添付の図面と併せて行われる以下の説明を参照する。

本開示の例示の態様が実装されてよい計算システム環境を示す例示のブロック図である。 例示的な実施形態の態様が実装されてよい、光学的に接続されたメモリ・システムのハードウェア構造の例示のブロック図である。 図２の光学的に接続されたメモリ・システム内のプロセッサ設計のハードウェア構造を示すブロック図である。 プロセッサでメモリにアクセスするためのハードウェア構造を示すブロック図である。 本開示に記載された非集約型計算システムを示す図である。 本開示の手法が実装されてよい代替のデータセンタ・アーキテクチャを示す図である。 本開示の第１の実施形態に記載された、メモリ管理サービスを含むように拡張された図６のデータセンタを示す図である。 本開示の第２の実施形態に記載されたデータセンタを示す図である。 メモリ空間を節約するためにデータ構造内の類似性および重複の検出を使用する容量節約ルーチンのプロセス・フローを示す図である。

本開示の手法は、好ましくは、「非集約型」計算システム環境の文脈において実装され、「非集約型サーバ」（本明細書では、しばしば「サーバ・エンティティ」と呼ばれる）は、共有サーバ・リソース・プール（つまり、計算プール、メモリ・プール、アクセラレータ（例えば、ＧＰＵアクセラレータ、ネットワーク・アクセラレータなど）プール、ストレージ・プールなどのうちの１つまたは複数）から選択された（または割り当てられた）サーバ・リソースで構成されるか、そのようなサーバ・リソースを構成する。名前が示すように、「計算」プールは通常、物理プロセッサ（ＣＰＵなど）を構成し、「メモリ」プールは通常、物理メモリ・デバイス（デュアル・インライン・メモリ・モジュール（ＤＩＭＭ：dual-inline-memory modules）など）を構成する、などとなっている。特定の共有プールは、好ましくは、特定のリソース・タイプのみを含むが、特定のリソース・プールは、１つまたは複数のリソース・サブタイプで構成されてよい。一般的なリソースが収集されるか、集約されるか、またはその他の任意の適切な方法で結合されてよいため、「プール」という概念は、制限することを意図していない。さらに「プール」は、一般的なタイプまたはサブタイプを持つリソースの専用のセットであるか、またはそのようなリソースの何らかの一時的な集合であってよい。好ましくは、特定のサーバ・エンティティは、サーバ・リソース・プールのうちの１つまたは複数からのサーバ・リソースを備える。

好ましい実施形態では、下で説明されるように、本開示の内容が実践される非集約型計算システムは、メモリの（電気相互接続ではなく）光相互接続を利用するが、これに限定されない。

通常、共有リソース・プールは、特定のデータセンタの物理的制約の範囲内で利用可能であるが、同様に、これに限定されない。したがって、共有リソース・プール自体が、物理データセンタ間で共有されてよい。さらに、特定のサーバ・エンティティが各サーバ・プールからのリソースで構成される必要はない。

光学的に接続されたスイッチング・メモリ・アーキテクチャ（switching optically-connected memory architecture）
背景の目的で、ただし限定することを目的とせず、以下では、本開示の手法（下で説明される）が実践されてよい代表的なコンピュータ環境について説明する。

ここで図１を参照すると、本開示の非集約型計算システムが実装されてよい計算環境の例示のアーキテクチャ１０が示されている。コンピュータ・システム１０は、通信ポート１８およびメモリ・デバイス１６に接続された中央処理装置（ＣＰＵ：central processing unit）を含んでいる。通信ポート１８は、通信ネットワーク２０と通信する。通信ネットワーク２０およびストレージ・ネットワークは、サーバ（ホスト）２４および２２、ならびにストレージ・システム１４を含んでよいストレージ・システムと通信するように構成されてよい。ストレージ・システムは、ハード・ディスク・ドライブ（ＨＤＤ：hard disk drive）デバイス、半導体デバイス（ＳＳＤ：solid-state device）などを含んでよく、新磁気ディスク制御機構（ＲＡＩＤ：redundant array of independent 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）：利用者に提供される能力は、処理、ストレージ、ネットワーク、およびその他の基本的な計算リソースのプロビジョニングであり、利用者は、オペレーティング・システムおよびアプリケーションを含むことができる任意のソフトウェアをデプロイして実行できる。利用者は、基盤になるクラウド・インフラストラクチャを管理することも制御することもないが、オペレーティング・システム、ストレージ、およびデプロイされたアプリケーションを制御することができ、場合によっては、選択されたネットワーク・コンポーネント（例えば、ホスト・ファイアウォール）を限定的に制御できる。

デプロイメント・モデルは、通常、次のとおりである。
プライベート・クラウド：このクラウド・インフラストラクチャは、ある組織のためにのみ運用される。このクラウド・インフラストラクチャは、この組織またはサード・パーティによって管理することができ、オンプレミスまたはオフプレミスに存在することができる。
コミュニティ・クラウド：このクラウド・インフラストラクチャは、複数の組織によって共有され、関心事（例えば、任務、セキュリティ要件、ポリシー、およびコンプライアンスに関する考慮事項）を共有している特定のコミュニティをサポートする。このクラウド・インフラストラクチャは、これらの組織またはサード・パーティによって管理することができ、オンプレミスまたはオフプレミスに存在することができる。
パブリック・クラウド：このクラウド・インフラストラクチャは、一般ユーザまたは大規模な業界団体が使用できるようになっており、クラウド・サービスを販売する組織によって所有される。
ハイブリッド・クラウド：このクラウド・インフラストラクチャは、データとアプリケーションの移植を可能にする標準化された技術または独自の技術（例えば、クラウド間の負荷バランスを調整するためのクラウド・バースト）によって固有の実体を残したまま互いに結合された２つ以上のクラウド（プライベート、コミュニティ、またはパブリック）の複合である。

クラウド・コンピューティング環境は、ステートレス、疎結合、モジュール性、および意味的相互運用性に重点を置いたサービス指向の環境である。クラウド・コンピューティングの中心になるのは、相互接続されたノードのネットワークを備えるインフラストラクチャである。特に、クラウド・コンピューティング・ノード内には、他の多数の汎用または専用のコンピューティング・システム環境または構成と共に運用できるコンピュータ・システム／サーバが存在する。コンピュータ・システム／サーバと共に使用するのに適した既知のコンピューティング・システム、環境、または構成、あるいはその組み合わせの例は、パーソナル・コンピュータ・システム、サーバ・コンピュータ・システム、シン・クライアント、シック・クライアント、ハンドヘルドまたはラップトップ・デバイス、マイクロプロセッサ・システム、マイクロプロセッサベース・システム、セット・トップ・ボックス、プログラマブル・コンシューマ・エレクトロニクス、ネットワークＰＣ、マイクロコンピュータ・システム、メインフレーム・コンピュータ・システム、およびこれらの任意のシステムまたはデバイスを含む分散クラウド・コンピューティング環境などを含むが、これらに限定されない。コンピュータ・システム／サーバは、コンピュータ・システムによって実行されているプログラム・モジュールなどの、コンピュータ・システムによって実行可能な命令との一般的な関連において説明されてよい。通常、プログラム・モジュールは、特定のタスクを実行するか、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、論理、データ構造などを含むことができる。コンピュータ・システム／サーバは、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される、分散クラウド・コンピューティング環境で実践されてよい。分散クラウド・コンピューティング環境において、プログラム・モジュールは、メモリ・ストレージ・デバイスを含む、ローカルおよびリモートの両方のコンピュータ・システム・ストレージ媒体に配置されてよい。

標準的なクラウド・コンピューティング環境は、フロント・エンドＩＤマネージャ（front end 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）６２０と共に備えており、データベース管理システム６２０は、ユーザ、その他のアプリケーション、およびデータベースと情報をやりとりしてデータを獲得および分析するコンピュータ・ソフトウェア・アプリケーションである。汎用ＤＢＭＳは、データベースの定義、作成、問い合わせ、更新、および管理を可能にする。代表的なＤＢＭＳは、ＩＢＭ（Ｒ） ＤＢ２（Ｒ）である。

一実施形態では、データベース６１８はリレーショナルである。このデータベースは、定められたサーバ・エンティティごとに、サーバを構成するリソースを識別するデータ・レコード（または、さらに一般的には、データ・セット）を格納する。好ましくは、このデータ・レコードは、識別子（一意のサーバＩＤ）に関連付けられ、サーバを構成する各リソースは、データベース内で、この一意のサーバ識別子に関連付けられる。したがって、前述した例を引き続き参照すると、第１のサーバ・エンティティ６１０は一意のサーバＩＤ_１に関連付けられてよく、第２のサーバ・エンティティ６１２は一意のサーバＩＤ_２に関連付けられてよい、などのようになる。

好ましくは、リソース・プールの個々のコンポーネントも、データベース内で追跡される識別子を含み、リソースがサーバ・エンティティに割り当てられた場合、このリソースの識別子はこのサーバ・エンティティに関連付けられる（相互参照される）。したがって、上の第１の例を引き続き参照すると、ＣＰＵ６０２ａ、メモリ６０４ｂ、ＧＰＵアクセラレータ６０６ｃ、およびストレージ６０８ｄのさまざまなリソース固有の識別子が、（リレーショナル・テーブルまたはその他の方法によって）第１のサーバ・エンティティ６１０の一意のサーバ識別子である一意のサーバＩＤ１に関連付けられる。同様に、第２の例を引き続き参照すると、ＣＰＵ６０２ｂ、メモリ６０４ａ、ＧＰＵアクセラレータ６０６ｂ、およびストレージ６１０ａのさまざまなリソース固有の識別子が、第２のサーバ・エンティティの一意のサーバ識別子である一意のサーバＩＤ２に関連付けられる、などのように、サーバ・エンティティごとに同様に関連付けられる。

サーバ・エンティティが最初に構築されるときに、サーバ・エンティティは、リソース割り当てメカニズムによってサーバ・プールから選択された１つまたは複数のサーバ・プールのリソースのセットを含む。したがって、サーバ・エンティティの一意のサーバ識別子は、リソース固有の識別子の初期セットに関連付けられる。後でリソースがサーバ・エンティティに割り当てられるか、またはサーバ・エンティティから割り当て解除されると、特定のサーバ・エンティティ識別子に関連付けられた構成要素であるリソース識別子のセットも変わる。

リソース・プールの複数のインスタンスが存在してよい。複数のインスタンスが存在する場合、サーバ・エンティティをサポートするための特定のリソースが、それらのインスタンスのうちの１つまたは複数から選択される。好ましくは、リソース・プールの第１のインスタンスに割り当てられたリソースがサーバ・エンティティの構築に使用された場合、能力をこのサーバ・エンティティに追加することが必要になったときに、好ましくは、追加リソースも、可能であれば同じインスタンスから取り出される。

好ましくは、リソース固有の識別子は、リソースのステータス、属性、他のリソースとの関係などに関する情報を提供する。したがって、データベース（集中させるか、または分散させてよい）は、サーバ・エンティティ、サーバ・プール、および特定のサーバ・エンティティを構成するさまざまなリソースに関する情報のリポジトリに機能する。

リレーショナル・データベースは実装に役立つが、サーバ・エンティティ識別子とリソース固有の識別子は、他の方法（例えば、リンク・リスト、データ配列、ハッシュ・テーブル、またはその他の方法）で互いに関連付けられてよい。

一般に、リソース割り当てメカニズム６１４およびデータベース・システム６１６は、連携して非集約型計算システムを管理する。リソース割り当てメカニズムは、サーバを定めるアイドル状態および使用中のＣＰＵ、メモリ、ＧＰＵアクセラレータ、およびその他のコンポーネントを追跡する追跡システムとして機能する。さらに、追跡システムは、どのＣＰＵ、メモリ、アクセラレータ、またはその他のコンポーネントがサーバの一部であるかについての、定められた各サーバの記録を残す。前述したように、定められたサーバごとに、一意のＩＤが指定され、要求された数のＣＰＵ、メモリ、およびストレージが、下で詳細に説明されるように、例えばリソースの局所性、最良の適合性、および将来の拡張の必要性に基づいて、アイドル状態のリソースのプールから選択される。一意のサーバＩＤおよびこれらの各リソースのＩＤが、追跡システムにおいて記録される。好ましくは、前述したように、使用中のコンポーネントは、使用中としてマークが付けられ、アイドル状態のコンポーネントのプールから削除される。

好ましくは、サーバ・エンティティの各コンポーネントは、そのコンポーネントが含まれているサーバの一意のサーバＩＤを使用して、タグ付けされる。したがって、このコンポーネントは、一意のサーバＩＤによって識別されたサーバ・エンティティのコンポーネントであるということを認識する。

好ましくは、非集約型計算システムに対して発行された各要求、および要求に応答して受信されたデータも、サーバ・エンティティＩＤを使用してタグ付けされる。例えば、要求がリソースで受信された場合、このリソースは、要求にタグ付けされたサーバ・エンティティＩＤを、リソースのサーバ・エンティティＩＤと比較する。言い換えると、コンポーネントは、要求が、コンポーネントが割り当てられているサーバ・エンティティＩＤに一致するかどうかをチェックする能力を備えている。一致する場合、コンポーネントは、その要求を、使用して処理することができる要求であると認識する。要求にタグ付けされたサーバ・エンティティＩＤが、コンポーネントにタグ付けされたサーバ・エンティティＩＤと一致しない場合、コンポーネントは、その要求を無視できるということを認識する。

メモリ・プール用のマルチテナント・メモリ・サービス
本開示によれば、図６の「非集約型サーバ」アーキテクチャが、メモリ管理サービスによって改良される。下で示されているように、メモリ管理サービスは、メモリ・プール用の独自のメモリ管理能力を提供し、それによって、メモリ・プール（したがって、データセンタ）がより効率的に動作できるようにし、性能およびメモリ使用率を向上させる。

メモリ・プールが仮定される。前述したように、この種類の非集約型計算システムでは、メモリ・プールからのメモリ・コンポーネントは、異なるテナントおよび処理コンポーネント間で使用、再利用、または共有され得る。メモリ管理サービスは、メモリ・プールを作成する責任を負ってよいが、これは必須要件ではない。通常、プール内で管理される基本的なメモリ・コンポーネントは、メモリ・モジュール割り当てブロック（memory module allocation block）（例えば、ＤＩＭＭモジュール）である。ただし、プール内のメモリ・コンポーネント（または「リソース」）が任意のその他の種類の物理メモリ構造であってよいため、これは限定ではない。

メモリ管理サービスは、「メモリ管理」コンポーネントまたはメカニズムによって実装されてよい。ここで、図７を参照すると、メモリ管理サービスの実装が示されている。この例では、データセンタ７００の一部が示されており、「計算ドローア（compute drawer）」７０２として識別されるプロセッサ・プール、および「メモリ・ドローア（memory drawer）」７０４として識別されるメモリ・プールを含んでいる。計算ドローア７０２は、プロセッサ（通常は、ＣＰＵ）のブロック７０６を含んでおり、各ブロック７０６は、通常、１つまたは複数のＣＰＵ７０８を含んでいる。メモリ・ドローア７０４は、メモリのブロック７１０を含んでおり、各ブロック７１０は、通常、１つまたは複数のＤＩＭＭモジュール７１２を含んでいる。従来、標準的な読み込み／格納処理７１４は、図６に関して前述されたリソース割り当てメカニズムなどの、他の管理機能によって管理されている。本開示によれば、メモリ管理サービス７１５は、下で説明されるように、メモリ管理サービスの運用を容易にするサービス・プロセッサ７１６を含んでいる。サービス・プロセッサ７１６は、スタンドアロン・メカニズム（standalone mechanism）であってよく、または別のメモリ・コントローラの一部であってもよい。サービス・プロセッサ７１６は、サービス運用を制御するメモリ・サービス・コード（memory service code）を含んでいる。このコードは、サービスの機能を実行するためにハードウェア内で実行される１つまたは複数のコンピュータ・プログラム（それぞれ、プログラム命令セットを含んでいる）を含んでいる。高いレベルで、サービス・プロセッサは、その機能を実行するのに必要なだけのメモリ量を（メモリ・ドローア７０４から）動的に獲得するように動作する。好ましくは、メモリ管理サービスは、読み込み／格納処理の効率的使用に関して最適化されていないワークロードに対して動作するが、これは限定ではない。

したがって、図７に示されているように、メモリ・プール（メモリ・ドローア７０４）が作成され、メモリ管理サービスによって、このメモリ・プールから異なるメモリ・モジュールをプロセッサ７０８の異なるインスタンスに割り当てることができる。好ましくは、このサービスは、割り当ての最小の粒度で（したがって、可能な場合は帯域幅を共有して）メモリ・モジュール７１２をメモリ・ドローアから割り当てる。メモリ・モジュール７１２は、異なるユーザ／テナントの２つの異なるインスタンス間で共有されるように割り当てられてよいが、通常、そうすることは望ましくない。これは、そのように共有された使用が、２つ以上のテナントがそのモジュールに同時にアクセスする場合、（読み取り／書き込みに関して）そのモジュールから使用できる全帯域幅に影響を与えるためである。したがって、好ましくは、メモリ・モジュールは、一度に１つのテナントに割り当てられる。したがって、異なるメモリ・ブロックが異なるテナントに割り当てられ、メモリ・サービスは、メモリ・ブロックをあるベアメタルのサービスから別のベアメタルのサービスに切り替えるように機能するか、またはそのインスタンスを起動状態に保って、作業が開始されたときに非常に素早く再開できるようにしておくため以外の必要性がない場合、メモリ・ブロックを一時停止するように機能する。このようにして、メモリ・サービスは、メモリ・コンポーネントごとの高速な俊敏性および柔軟性を提供する。

したがって、図７に示されているように、本開示のメモリ・サービスは、好ましくは、メモリ・システム（メモリ・プール）全体のうちの構成可能な部分を占め、メモリ・システムの残りの部分を、標準的な高性能の読み込み／格納処理のために空いたままにする。やはり示されているように、メモリ・サービス７１５を利用する要求は、プロセッサ７１６によって管理され、プロセッサ７１６は、メモリ・プール・コントローラとして動作し、特に、システムがすでにアクセスできる実メモリのプールに対する最適化されたデータ編成能力を提供するために動作する。この目的で、このメモリ・サービスは、データ構造レベルなどで、ハードウェア内で特定の種類のデータ・ストアを実装する能力を提供する。好ましい実施形態では、下で説明されているように、メモリ・サービスは、メモリ・プール全体での高性能で再利用可能なデータ構造実装の作成および管理を可能にすることによって、ストレージ容量の節約を行う。さらに、やはり下で説明されているように、このサービスは、データの編成を実行する価値があるかどうか、およびいつ実行するかを決定するために、さまざまな分析（例えば、マルチテナントの類似性、重複の検出など）を提供する。下で説明されているように、このサービスは、好ましくは、データ構造の性能を向上させ、データ構造内の類似性および重複を（ワークロード間でも）検出することによって、容量の必要性をさらに利用して削減し、メモリ空間を節約する。

本明細書において使用されているように、「データ構造」の概念は、データにアクセスするために必要な方法に基づいてワークロードが使用するデータの編成のことを指している。例えば、あるプログラマは、順次アクセスがワークロードでの主要なアクセス方法である場合、データを「リンク・リスト」に入れることを選択することがあり、またはよりランダムなアクセスが支配的である場合、データを「ハッシュ・テーブル」に入れること選択することがある。データ構造のその他の種類は、ツリー、配列、スタック、キューなどを含むが、これらに限定されない。データ構造は、２種類以上のデータ構造の混合であってよい。一般的に言うと、データ構造は、ワークロードにおいてデータを編成するように実装される構造のことを指している。通常、データ構造の選択は、ワークロードの必要性または要件に関するプログラマの理解に基づいて、プログラマによって行われる。

本開示の手法によれば、下でさらに説明されているように、メモリ・サービスは、好ましくは、（そうすることが理にかなっている場合）さまざまな形態のデータ構造最適化を実行する。１つのデータ構造最適化では、データ構造内のデータの重複排除および圧縮によって、集約に占める空間を削減する機会が存在することがある。別のデータ構造最適化では、データ構造は、データの挿入および取り出しに関して最適な性能を保証するために、時間の経過に伴って調整されてよい。この後者の調整のほとんどは、通常、性能を対象にする。例えば、特定のハッシュ値に対して多すぎるエントリを含んでいるハッシュ・テーブルは、再ハッシュまたはツリーの再バランス調整などが行われてよい。データ構造によって使用されるメモリの性能を向上させるか、またはそのようなメモリを節約するためのデータ構造のその他の最適化が実装されてもよい。

したがって、データ構造の性能の最適化方法の例として、メモリ・サービスが、例えば特定のデータ使用パターンまたはデータの分散あるいはその両方を前提として、メモリを、さらに効率的であることのある異なるデータ構造に再編成するように選択的に動作する。この目的で、好ましくは、メモリ・マネージャは、データ使用パターンおよびデータ分散を監視し、現在使用中のデータ構造を変更する（または補う）かどうか、およびいつ変更する（または補う）かを決定する。既知の使用に基づく性能最適化方式および分散に基づく性能最適化方式が、メモリ・サービスでのデータ構造の再編成をサポートするために利用されてよい。そのような使用に基づく最適化は、データ構造内のほとんどアクセスされないデータの圧縮、ほとんどアクセスされないデータのストレージへの移動、使用傾向に基づいた、頻繁にアクセスされるデータのキャッシュへの事前読み込みなどを含むことができるが、これらに限定されない。代表的な分散に基づく性能最適化方式は、ハッシュベースの構造に適用される再ハッシュ・アルゴリズム、ツリーベースの構造に適用される再バランス調整アルゴリズムなどを含むが、これらに限定されない。

メモリ・サービスのさらに別の態様は、例えばストレージ・リソースをバックアップするために、メモリ・プールの自動化されたバックアップを提供する。図８は、このシナリオを示している。図８に示されているように、データセンタ８００は、計算ドローア８０２およびメモリ・ドローア８０４、ならびにメモリ・サービス８１５を含んでいる。加えて、データセンタは、データ・ストア８０８のセット含んでいるストレージ・ドローア８０６として識別されるストレージ・プールを含んでいる。データ・ストア８１０のうちの少なくとも一部が、バックアップ用に提供される。この目的で、プロセスによって、またはワークロードからのプログラム命令によって、メモリ・マネージャ・サービス８１５がデータ・セットの編成を追跡し、その理解を深める。その後、ストレージ・プールに対する定期的または指示されたバックアップ処理８１２が、いつでも、中断を最小限に抑えて実行される。これは（図示されているように）、データのコピーが計算プールのプロセッサを通る必要がないためである。好ましくは、バックアップは、特定のデータ・セットに対して実行される。キャッシュされていないデータは、好ましくは、バックアップ・ストレージに直接コピーされるが、キャッシュされたデータはメイン・メモリにフラッシュされてから、バックアップ・ストレージに直接コピーされる。あるいはバックアップは、キャッシュのフラッシュがすでに発生しているイベント（例えば、ページ・フォルト）の間に起こるように構成される。

したがって、好ましくは、メモリ・サービスは、容量の節約、性能の最適化、および回復力のうちの１つまたは複数を提供することによって、メモリ・プールを管理する。

以下では、好ましい容量節約手法のさらなる詳細について説明する。このアプローチでは、好ましくは、データがポインタと共にブロックに格納される。その後、例えばインデックス付与および比較分析によって、共通のデータ・ブロックが識別される。共通のデータ・ブロックが検出された場合、それらの時間の経過に伴う安定性を決定するための分析が実行される。共通のデータ・ブロックが（構成可能な基準に基づいて）安定していると見なされた場合、メモリ・サービスはそれらの重複を除去し、そのポインタを第１のコピーに向ける。その後、このデータの単一のコピー（オーバーサブスクライブされた値と呼ばれる）が管理される（例えば、メモリ・マネージャが、必要に応じて、安定したオーバーサブスクライブされた値の差分を更新する）。一方、共通のデータ・ブロックが安定していると見なされない場合、好ましくは、データの除去が実行されない。

図９は、本開示の容量節約ルーチンのプロセス・フローを示している。通常、前述したように、このルーチンは、データ構造内の類似性および重複を検出することによって、容量の必要性を利用して削減し、メモリ空間を節約する。このルーチンは、１つの特定のワークロードに対して動作してよく、または複数のワークロードにまたがって動作してもよい。図９に示されたプロセス・フローは、複数のワークロードにまたがる例を示している。このルーチンはステップ９００で開始し、データがポインタと共にブロックに格納される。ステップ９０２で、好ましくは、既知のインデックス付与方式および比較分析方式によって、共通のデータ・ブロックが識別される。ステップ９０４で、検出された共通のデータ・ブロックごとに、共通のデータ・ブロックが時間の経過にかかわらず安定しているかどうかを決定するためのテストが実行される。安定性の評価に使用される基準の性質は変化してよいが、通常、ステップ９０４は、共通のデータ・ブロック内の値が、構成された期間の後に変化したかどうか、構成された処理のセットの後に変化したかどうか、などを決定するためにテストする。ステップ９０４でのテストの結果が肯定的である場合、共通のデータ・ブロックは安定していると見なされ、その後、制御がステップ９０６に分岐し、ステップ９０６でメモリ・サービスが重複を除去する。ステップ９０８で、メモリ・サービスが、ポインタを第１のコピーに向け、その後、この第１のコピーは「オーバーサブスクライブされた値」として参照される。一方、ステップ９０４でのテストの結果が否定的である場合、共通のデータ・ブロックは不安定であると見なされる。その後、このルーチンは終了する。

オーバーサブスクライブされた値は安定していると仮定されるが、その後、ワークロードのうちの１つがオーバーサブスクライブされたデータ値を変更する必要がある状況が生じることがある。頻繁に発生することが予想されない、そのような状況では、メモリ・サービスは、新しい値を格納するよりも安価に、オーバーサブスクライブされた値の差分を計算して格納することができるかどうかを決定するために、分析を実行する。この差分値を小さいサイズで格納できる場合、この差分値が作成された後、ワークロードのポインタが、この差分に向けられる。この差分値が、元のサイズと同じ、またはほとんど同じ大きさである場合、オーバーサブスクライブされた位置が複製され、それぞれ別の値として維持される。このオーバーサブスクライブされた値の管理は、ステップ９０８の後に続くステップ９１０に示されている。

マネージャは、安定したオーバーサブスクライブされた値の差分を更新するために必要な作業も管理する。これが、ステップ９１２に示されている。特に、（好ましくは、ステップ９０４で使用されたしきい値と同じしきい値を使用して）差分のうちの１つが大きく変化し、安定しなくなった場合、マネージャはその差分を新しい値として切り離し、それに応じてそのポインタが調整される。安定しなくなった値が、ベースになるオーバーサブスクライブされた値である場合、マネージャは、どの差分が最も安定しているかを決定するための分析を実行し、その差分が新しいベース値になる。その後、古いベースが切り離されて、別のオーバーサブスクライブされていない値になる。一方、どの差分も安定していない場合、好ましくは、それらの差分およびベース値がすべて切り離されて、新しいサブスクライブされていない値になる。

このアプローチは、大きな利点を提供する。メモリ・サービスは、ハードウェアに近い実装を使用して、高性能を実現する。このアプローチは、メモリ・プール制御のためのデータ構造の構築および再利用を可能にし、それによって、各ワークロードによって生成される非効率的で潜在的に不安定な実装を減らす。このアプローチは、データの編成によって、効率の高い安定した状態のメモリ管理操作を促進する。特に、メモリ・サービスは、システムがすでにアクセスできる実メモリのプールに対する高度に最適化されたデータ編成能力を提供する。（図９に関して説明されたように）オーバーサブスクライブされた値を管理することによって、マネージャは、データの安定性を前提として、類似性および重複の検出による最適化を実行する価値があるかどうかを決定し、それによって、コストのかかるコピーおよび記録の保持を防ぐ。これらの最適化は、使用される場合、性能を最適化するために、メモリ内で実行される。さらに、自動化されたバックアップ能力は、バックアップの目的で、メモリ・プールからデータを効率的に取り出す、ハードウェアで実現される方法を提供する。好ましくは、基本操作を容易にするために、メモリ・マネージャによってデータのコピーは実行されない。ハードウェア構造は、プロセッサを通るというコストのかかる処理を伴わずに複製を生成する効率的な方法も可能にする。

したがって、本明細書におけるアプローチは、好ましくは、データ編成メカニズム（つまり、データ構造の操作、データ構造の性能最適化、処理時間、メモリ内の重複排除など）のハードウェアベースの実装を追加することによって、非集約型システム内でのメイン・メモリの使用を最適化し、複数のテナントにまたがる利用率の向上を可能にする。このようにして、メモリ・サービスは、実メモリに対するより高いレベルでのデータ編成能力を計算ノードに提供することができる。このアプローチでは、ある範囲のメモリが計算ノードに与えられる必要はなく、バックエンドの最適化がハードウェアおよびソフトウェアにおいて利用できるような方法で、データ編成能力（つまり、集合的データ構造など）が使用可能になる。さらに、本明細書におけるアプローチは、仮想メモリ・システムを作成するために、複数のホストまたはクライアント／サーバのインストールを必要としない。

本明細書に記載された利点は、異なるメモリ・モジュールをプロセッサの異なるインスタンスに割り当てることができるメモリ・プールを割り当てるメモリ管理サービスによって提供される。メモリ・サービス構造（データ構造レベルであってよい）は、ハードウェア内で格納部を実装するために構築される。このサービスの実施形態は、好ましくは、データ構造内の類似性および重複を検出することによって、容量の必要性を利用して削減する容量節約機能をさらに含む。このサービスのさらに別の実施形態は、データの使用パターンおよび分散を前提として、メモリを、より効率的であることがある異なるデータ構造に再編成する能力をさらに提供する。このサービスのさらに別の実施形態は、好ましくは、コピーをプロセッサに通すことを必要とせずにバックアップ処理が発生できるようにすることによって、自動化されたバックアップ（したがって、強化されたデータ回復力）も提供する。

前述したように、上で説明された機能は、スタンドアロンのアプローチ（例えば、プロセッサによって実行されるソフトウェアベースの機能）として実装されてよく、またはサービス（ＳＯＡＰ／ＸＭＬインターフェイスを介したＷｅｂサービスを含む）として利用されてもよい。本明細書に記載された特定のハードウェアおよびソフトウェアの実装の詳細は、単に例示を目的としており、記載された主題の範囲を制限するようには意図されていない。

さらに一般的には、開示された主題との関連において、コンピューティング・デバイスはそれぞれ、ハードウェアおよびソフトウェアを備えているデータ処理システムであり、これらのエンティティは、ネットワーク（インターネット、イントラネット、エクストラネット、プライベート・ネットワーク、あるいは任意のその他の通信媒体またはリンクなど）を経由して互いに通信する。データ処理システム上のアプリケーションは、特にＨＴＴＰ、ＦＴＰ、ＳＭＴＰ、ＳＯＡＰ、ＸＭＬ、ＷＳＤＬ、ＵＤＤＩ、およびＷＳＦＬのサポートを含むが、これらに限定されない、Ｗｅｂならびにその他の既知のサービスおよびプロトコルのネイティブ・サポートを提供する。ＳＯＡＰ、ＷＳＤＬ、ＵＤＤＩ、およびＷＳＦＬに関する情報は、これらの規格を開発および維持する役割を担っているワールド・ワイド・ウェブ・コンソーシアム（Ｗ３Ｃ：World Wide Web Consortium）から提供されており、ＨＴＴＰ、ＦＴＰ、ＳＭＴＰ、およびＸＭＬに関するさらなる情報は、インターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ：Internet Engineering Task Force）から提供されている。これらの既知の規格およびプロトコルを熟知していることが仮定される。

本明細書に記載された手法は、単純なｎ層アーキテクチャ、Ｗｅｂポータル、フェデレーテッド・システムなどを含む、さまざまなサーバサイド・アーキテクチャ内で、またはこれらと併せて、実装されてよい。前述したように、本明細書における手法は、疎結合されたサーバ（「クラウド」ベースを含む）環境内で実践されてもよい。

さらに一般的には、本明細書に記載された主題は、完全にハードウェアである実施形態、完全にソフトウェアである実施形態、またはハードウェアとソフトウェアの両方の要素を含んでいる実施形態の形態をとることができる。好ましい実施形態では、信頼できるプラットフォーム・モジュールの機能が、ファームウェア、常駐ソフトウェア、マイクロコードなどを含むがこれらに限定されないソフトウェアにおいて実装される。さらに、ダウンロードおよび削除のインターフェイスおよび機能は、コンピュータまたは任意の命令実行システムによって、またはこれらに関連させて使用するためのプログラム・コードを提供するコンピュータ使用可能媒体またはコンピュータ可読媒体からアクセスできるコンピュータ・プログラム製品の形態をとることができる。この説明の目的で、コンピュータ使用可能媒体またはコンピュータ可読媒体は、命令実行システム、命令実行装置、または命令実行デバイスによって、またはこれらに関連させて使用するためのプログラムを含むか、または格納することができる任意の装置であることができる。この媒体は、電子システム、磁気システム、光システム、電磁気システム、赤外線システム、または半導体システム（あるいは、装置またはデバイス）であることができる。コンピュータ可読媒体の例としては、半導体メモリまたは固体メモリ、磁気テープ、取り外し可能コンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ：random access memory）、読み取り専用メモリ（ＲＯＭ：read-only memory）、剛体磁気ディスク、および光ディスクが挙げられる。光ディスクの現在の例としては、コンパクト・ディスク読み取り専用メモリ（ＣＤ−ＲＯＭ：compact disk-read only memory）、コンパクト・ディスク読み取り／書き込み（ＣＤ−Ｒ／Ｗ：compact disk-read/write）、およびＤＶＤが挙げられる。コンピュータ可読媒体は、有形の非一時的アイテムである。

コンピュータ・プログラム製品は、記載された機能のうちの１つまたは複数を実装するためのプログラム命令（またはプログラム・コード）を含んでいる製品であってよい。これらの命令またはコードは、ネットワークを経由してリモート・データ処理システムからダウンロードされた後に、データ処理システム内の非一時的コンピュータ可読記憶媒体に格納されてよい。または、これらの命令またはコードは、サーバ・データ処理システム内のコンピュータ可読記憶媒体に格納され、リモート・システム内のコンピュータ可読記憶媒体において使用するために、ネットワークを経由してリモート・データ処理システムにダウンロードされるように適合されてよい。

代表的実施形態では、インターフェイスおよびユーティリティが、専用コンピューティング・プラットフォーム内で、好ましくは１つまたは複数のプロセッサによって実行されるソフトウェア内で、実装される。ソフトウェアは、１つまたは複数のプロセッサに関連付けられた１つまたは複数のデータ・ストアまたはメモリ内で維持され、ソフトウェアは、１つまたは複数のコンピュータ・プログラムとして実装されてよい。集合的に、この専用ハードウェアおよびソフトウェアは、前述した機能を備える。

上では、本発明の特定の実施形態によって実行される特定の順序の処理を説明したが、代替の実施形態が、処理を異なる順序で実行すること、特定の処理を組み合わせること、特定の処理を重ね合わせることなどを実行してよいため、そのような順序は例であると理解されるべきである。本明細書における特定の実施形態例への参照は、記載された実施形態が特定の特徴、構造、または特性を含むことができるが、必ずしもすべての実施形態がこの特定の特徴、構造、または特性を含まなくてもよいということを示している。

最後に、システムの特定のコンポーネントが別々に説明されたが、当業者は、機能の一部が、特定の命令、プログラム・シーケンス、コード部分などにおいて、組み合わされるか、または共有されてよいということを理解するであろう。

本明細書における手法は、通常、技術または技術分野（データセンタ・アーキテクチャ、非集約型計算環境など）に対する前述の改良、および前述したようなメモリ・プール管理方式に対する特定の技術的改良を提供する。

以上で本発明を説明したが、特許請求の範囲は次のとおりである。

Claims (25)

1. マルチテナント計算環境においてメモリを管理する方法であって、
   メモリ・リソース・プールを提供することと、
   特定のワークロードに関して、メモリ・リソースを前記メモリ・リソース・プールからプロセッサのセットに割り当てることと、
   データ構造に従って、前記割り当てられたメモリ・リソース内の前記特定のワークロードのデータを編成することと、
   前記特定のワークロードの前記データ構造内の前記データの再編成が、前記データ構造の性能を向上させるかどうか、または前記データ構造によって使用されるメモリを節約するかどうかを決定することと、
   再編成が性能を向上させるということ、またはメモリを節約するということを決定したときに、前記データを管理するための特定の動作を実行することと
   を含む、方法。
2. 前記特定の動作がデータの類似性または重複を検出し、前記検出に応答して、特定のデータを前記割り当てられたメモリ・リソースから除去する、請求項１に記載の方法。
3. 複数のテナントまたは複数のプロセスに共通しているデータ・ブロックを識別することと、
   共通のデータ・ブロックを識別したときに、構成可能なしきい値に従って、前記共通のデータ・ブロックが安定しているかどうかを決定することと、
   前記共通のデータ・ブロックが安定しているということを決定したときに、重複する共通のデータ・ブロックを除去することと、
   前記共通のデータ・ブロックのインスタンスを共有された共通のデータ・ブロックとして関連付けることと、
   前記複数のテナントまたは複数のプロセスに、前記共有された共通のデータ・ブロックへのポインタを提供することと
   によって、データの類似性または重複が検出される、請求項２に記載の方法。
4. 第１のテナントの共有された共通のデータ・ブロックの値が変化したことを決定することと、
   前記第１のテナントの前記共有された共通のデータ・ブロックの差分値を格納することのほうが、計算コストが少ないかどうかを決定することと、
   前記差分値を格納することのほうが計算コストが少ないということを決定したときに、前記第１のテナントの前記共有された共通のデータ・ブロックの前記差分値を格納することと
   をさらに含む、請求項３に記載の方法。
5. 前記第１のテナントの前記共有された共通のデータ・ブロックの新しい値を格納することのほうが、計算コストが少ないかどうかを決定することと、
   新しい値を格納することのほうが計算コストが少ないということを決定したときに、前記第１のテナントの前記共有された共通のデータ・ブロックの前記新しい値を格納することと
   をさらに含む、請求項４に記載の方法。
6. 前記データを管理するための前記特定の動作が、
   前記データのデータ分散または使用パターンを監視することと、
   前記監視することに基づいて、最適化を適用して前記データ構造を調整することと
   を含む、請求項１に記載の方法。
7. データ・セットをプロファイリングしてデータ・セット・スキーマを生成することと、
   プロセッサを使用せずに前記データ・セットを定期的にバックアップすることと、
   バックアップ処理の前に、キャッシュされたデータをメイン・メモリにフラッシュすることと
   をさらに含む、請求項１に記載の方法。
8. 前記特定のワークロードのアクセス要件に基づいて前記データ構造が前記データを編成する、請求項１に記載の方法。
9. マルチテナント計算環境においてメモリを管理する装置であって、
   １つまたは複数のハードウェア・プロセッサと、
   前記ハードウェア・プロセッサによって実行されるコンピュータ・プログラム命令を保持しているコンピュータ・メモリと
   を備え、前記コンピュータ・プログラム命令が、
   メモリ・リソース・プールを編成することと、
   特定のワークロードに関して、メモリ・リソースを前記メモリ・リソース・プールからプロセッサのセットに割り当てることと、
   データ構造に従って、前記割り当てられたメモリ・リソース内の前記特定のワークロードのデータを編成することと、
   前記特定のワークロードの前記データ構造内の前記データの再編成が、前記データ構造の性能を向上させるかどうか、または前記データ構造によって使用されるメモリを節約するかどうかを決定することと、
   再編成が性能を向上させるということ、またはメモリを節約するということを決定したときに、前記データを管理するための特定の動作を実行することと
   を実行するように機能する、装置。
10. 前記特定の動作がデータの類似性または重複を検出し、前記検出に応答して、特定のデータを前記割り当てられたメモリ・リソースから除去する、請求項９に記載の装置。
11. 複数のテナントまたは複数のプロセスに共通しているデータ・ブロックを識別することと、
    共通のデータ・ブロックを識別したときに、構成可能なしきい値に従って、前記共通のデータ・ブロックが安定しているかどうかを決定することと、
    前記共通のデータ・ブロックが安定しているということを決定したときに、重複する共通のデータ・ブロックを除去することと、
    前記共通のデータ・ブロックのインスタンスを共有された共通のデータ・ブロックとして関連付けることと、
    前記複数のテナントまたは複数のプロセスに、前記共有された共通のデータ・ブロックへのポインタを提供することと
    によって、データの類似性または重複が検出される、請求項１０に記載の装置。
12. 前記コンピュータ・プログラム命令が、
    第１のテナントの共有された共通のデータ・ブロックの値が変化したことを決定することと、
    前記第１のテナントの前記共有された共通のデータ・ブロックの差分値を格納することのほうが、計算コストが少ないかどうかを決定することと、
    前記差分値を格納することのほうが計算コストが少ないということを決定したときに、前記第１のテナントの前記共有された共通のデータ・ブロックの前記差分値を格納することと
    を実行するようにさらに機能する、請求項１１に記載の装置。
13. 前記コンピュータ・プログラム命令が、
    前記第１のテナントの前記共有された共通のデータ・ブロックの新しい値を格納することのほうが、計算コストが少ないかどうかを決定することと、
    新しい値を格納することのほうが計算コストが少ないということを決定したときに、前記第１のテナントの前記共有された共通のデータ・ブロックの前記新しい値を格納することとを実行するようにさらに機能する、請求項１２に記載の装置。
14. 前記データを管理するための前記特定の動作が、
    前記データのデータ分散または使用パターンを監視することと、
    前記監視することに基づいて、最適化を適用して前記データ構造を調整することと
    を含む、請求項９に記載の装置。
15. 前記コンピュータ・プログラム命令が、
    データ・セットをプロファイリングしてデータ・セット・スキーマを生成することと、
    プロセッサを使用せずに前記データ・セットを定期的にバックアップすることと、
    バックアップ処理の前に、キャッシュされたデータをメイン・メモリにフラッシュすることと
    を実行するようにさらに機能する、請求項９に記載の装置。
16. 前記特定のワークロードのアクセス要件に基づいて前記データ構造が前記データを編成する、請求項９に記載の装置。
17. マルチテナント計算環境内のメモリを管理するためにデータ処理システムにおいて使用するための非一時的コンピュータ可読媒体内のコンピュータ・プログラム製品であって、前記コンピュータ・プログラム製品が前記データ処理システムにおいて実行されるコンピュータ・プログラム命令を保持しており、前記コンピュータ・プログラム命令が、
    メモリ・リソース・プールを編成することと、
    特定のワークロードに関して、メモリ・リソースを前記メモリ・リソース・プールからプロセッサのセットに割り当てることと、
    データ構造に従って、前記割り当てられたメモリ・リソース内の前記特定のワークロードのデータを編成することと、
    前記特定のワークロードの前記データ構造内の前記データの再編成が、前記データ構造の性能を向上させるかどうか、または前記データ構造によって使用されるメモリを節約するかどうかを決定することと、
    再編成が性能を向上させるということ、またはメモリを節約するということを決定したときに、前記データを管理するための特定の動作を実行することと
    を実行するように機能する、コンピュータ・プログラム製品。
18. 前記特定の動作がデータの類似性または重複を検出し、前記検出に応答して、特定のデータを前記割り当てられたメモリ・リソースから除去する、請求項１７に記載のコンピュータ・プログラム製品。
19. 複数のテナントまたは複数のプロセスに共通しているデータ・ブロックを識別することと、
    共通のデータ・ブロックを識別したときに、構成可能なしきい値に従って、前記共通のデータ・ブロックが安定しているかどうかを決定することと、
    前記共通のデータ・ブロックが安定しているということを決定したときに、重複する共通のデータ・ブロックを除去することと、
    前記共通のデータ・ブロックのインスタンスを共有された共通のデータ・ブロックとして関連付けることと、
    前記複数のテナントまたは複数のプロセスに、前記共有された共通のデータ・ブロックへのポインタを提供することと
    によって、データの類似性または重複が検出される、請求項１８に記載のコンピュータ・プログラム製品。
20. 前記コンピュータ・プログラム命令が、
    第１のテナントの共有された共通のデータ・ブロックの値が変化したことを決定することと、
    前記第１のテナントの前記共有された共通のデータ・ブロックの差分値を格納することのほうが、計算コストが少ないかどうかを決定することと、
    前記差分値を格納することのほうが計算コストが少ないということを決定したときに、前記第１のテナントの前記共有された共通のデータ・ブロックの前記差分値を格納することと
    を実行するようにさらに機能する、請求項１９に記載のコンピュータ・プログラム製品。
21. 前記コンピュータ・プログラム命令が、
    前記第１のテナントの前記共有された共通のデータ・ブロックの新しい値を格納することのほうが、計算コストが少ないかどうかを決定することと、
    新しい値を格納することのほうが計算コストが少ないということを決定したときに、前記第１のテナントの前記共有された共通のデータ・ブロックの前記新しい値を格納することと
    を実行するようにさらに機能する、請求項２０に記載のコンピュータ・プログラム製品。
22. 前記データを管理するための前記特定の動作が、
    前記データのデータ分散または使用パターンを監視することと、
    前記監視することに基づいて、最適化を適用して前記データ構造を調整することと
    を含む、請求項１７に記載のコンピュータ・プログラム製品。
23. 前記コンピュータ・プログラム命令が、
    データ・セットをプロファイリングしてデータ・セット・スキーマを生成することと、
    プロセッサを使用せずに前記データ・セットを定期的にバックアップすることと、
    バックアップ処理の前に、キャッシュされたデータをメイン・メモリにフラッシュすることと
    を実行するようにさらに機能する、請求項１７に記載のコンピュータ・プログラム製品。
24. 前記特定のワークロードのアクセス要件に基づいて前記データ構造が前記データを編成する、請求項１７に記載のコンピュータ・プログラム製品。
25. データセンタ・ファシリティであって、
    メモリ・プールと、
    光相互接続と、
    ハードウェア要素内で実行されるメモリ・マネージャとを備え、前記メモリ・マネージャが、前記メモリ・リソース・プールから複数のテナントのワークロードのプロセッサのセットへのメモリ・リソースの割り当てを管理することと、データ構造に従って特定のテナントのワークロードのデータを編成することと、前記データ構造内の前記データを選択的に再編成して、前記データ構造の性能を向上させるか、または前記特定のテナントのワークロードにサービスを提供するために必要なメモリを削減することとを実行するように機能する、データセンタ・ファシリティ。

Images