JP2014530413A - 分離された仮想空間を提供するための方法および装置 - Google Patents

Abstract

様々な実施形態は、複数のＯＳを実行する必要なく、アプリケーション分離仮想空間を作成する方法および装置を提供する。アプリケーション分離仮想空間は、リソース・マネージャを利用するオペレーティングシステム（ＯＳ）によって作成される。リソース・マネージャは、従来のＯＳカーネルのネットワーク・スタックおよびＩ／Ｏサブシステムを、ＯＳによって管理される物理リソースの複数の分離されたネットワーク・スタック／仮想Ｉ／Ｏビューを有するように書き換えることによって、アプリケーションを互いに分離する。分離されたネットワーク・スタックおよび仮想Ｉ／Ｏビューは、アプリケーションの分離仮想空間に割り当てられたリソースを識別し、分離識別子を介してアプリケーションにマッピングされる。

Description

概して本発明は、分離された仮想プライベート・サーバを作成するための方法および装置に関する。

このセクションは、本発明のよりよい理解を促進するのに役立ち得る態様を紹介する。したがって、このセクションの記述は、この観点から読まれるべきであり、なにが従来技術であるか、または、なにが従来技術でないかについての承認として理解されるべきではない。

ホスト環境が物理サーバのリソースを動的に割り当てることを可能にし、仮想プライベート・サーバを生み出す多数の技術が存在する。いくつかの既知のシステムでは、物理サーバは、「ゲスト」オペレーティングシステム（ＯＳ）または仮想マシンのリソースを作成、解放、および管理する仕事を課された、仮想マシン・マネージャを実行する。

様々な実施形態は、複数のＯＳを実行する必要なく、アプリケーション分離仮想空間を作成する方法および装置を提供する。アプリケーション分離仮想空間は、リソース・マネージャを利用するオペレーティングシステム（ＯＳ）によって作成される。リソース・マネージャは、従来のＯＳカーネルのネットワーク・スタックおよびＩ／Ｏサブシステムを、ＯＳによって管理される物理リソースの複数の分離されたネットワーク・スタック／仮想Ｉ／Ｏビューを有するように書き換えることによって、アプリケーションを互いに分離する。分離されたネットワーク・スタックおよび仮想Ｉ／Ｏビューは、アプリケーションの分離仮想空間に割り当てられたリソースを識別し、分離識別子を介してアプリケーションにマッピングされる。複数のＯＳを実行する必要なしに、分離された動作環境をアプリケーションに提供する方法および装置が作成されることが有利である。

一実施形態では、リソース・マネージャを作成するための方法が提供される。方法は、デジタル・データ・ストレージ内に管理レベルＯＳを作成する工程と、アプリケーション分離仮想空間に対するアプリケーション要求を監視する工程と、アプリケーション分離仮想空間に対するいくつかのアプリケーション要求を許可する工程と、を含む。アプリケーション要求を許可する工程は、アプリケーション分離仮想空間の分離識別子を決定する工程と、分離識別子に基づいて管理レベルＯＳを更新する工程と、デジタル・データ・ストレージ内にアプリケーション・ネットワーク・スタックを作成する工程と、を含む。

いくつかの実施形態では、管理レベルＯＳを更新する工程は、少なくとも１つの共通リソース・スケジューラを更新する工程を含む。

いくつかの実施形態では、管理レベルＯＳを更新する工程は、少なくとも１つのメモリ共通リソース・アロケータを更新する工程を含む。

いくつかの実施形態では、管理レベルＯＳを更新する工程は、少なくとも１つのリソース・テーブルを更新する工程を含む。

別の実施形態では、アプリケーション分離仮想空間内のシステム・コール要求に対応する方法が提供される。方法は、システム・コール要求を受信する工程と、分離識別子を取得する工程と、分離識別子に基づいてシステム・コール要求を満たすために、アプリケーション・リソースを利用する工程と、を含む。

いくつかの実施形態では、システム・コール要求は、修正されたシステム・コールを呼び出す。

いくつかの実施形態では、当該方法は、システム・コールから修正されたシステム・コールを作成する工程を含む。

いくつかの実施形態では、修正されたシステム・コールは、仮想ディスクＩ／Ｏビューにアクセスする。

いくつかの実施形態では、修正されたシステム・コールは、共有メモリにアクセスする。

別の実施形態では、システム・リソースを管理するための装置が提供される。当該装置は、デジタル・データ・ストレージを含み、デジタル・データ・ストレージは、少なくとも１つの記憶デバイスおよび少なくとも１つのメモリ・デバイスを含む。当該装置は、少なくとも１つのネットワーク・インタフェースおよび少なくとも１つのプロセッサも含む。プロセッサ（複数可）は、デジタル・データ・ストレージ内に管理レベルＯＳを作成し、アプリケーション分離仮想空間に対するアプリケーション要求を監視し、アプリケーション分離仮想空間に対する複数のアプリケーション要求を許可するようにプログラムされる。要求の許可は、アプリケーション分離仮想空間の分離識別子の判定と、分離識別子に基づく管理レベルＯＳの更新と、デジタル・データ・ストレージ内のアプリケーション・ネットワーク・スタックの作成と、を含む。

いくつかの実施形態では、管理レベルＯＳの更新は、少なくとも１つの共通リソース・スケジューラの更新も含む。

いくつかの実施形態では、１つの共通リソース・スケジューラは、分離識別子に基づいて、少なくとも１つのプロセッサへのアクセスを制御する。

いくつかの実施形態では、管理レベルＯＳの更新は、少なくとも１つのメモリ共通リソース・アロケータの更新を含む。

いくつかの実施形態では、管理レベルＯＳの更新は、少なくとも１つのリソース・テーブルの更新を含む。

別の実施形態では、システム・コールに対応するための装置が提供される。装置は、デジタル・データ・ストレージを含み、デジタル・データ・ストレージは、少なくとも１つの記憶デバイスおよび少なくとも１つのメモリ・デバイス、少なくとも１つのネットワーク・インタフェース、ならびに少なくとも１つのプロセッサを含む。プロセッサは、システム・コール要求を受信し、分離識別子を取得し、分離識別子に基づいてシステム・コール要求を満たすために、アプリケーション・リソースを利用するようにプログラムされる。

いくつかの実施形態では、システム・コール要求は、修正されたシステム・コールを呼び出す。

いくつかの実施形態では、少なくとも１つのプロセッサは、システム・コールから修正されたシステム・コールを作成するようにプログラムされる。

いくつかの実施形態では、修正されたシステム・コールは、仮想ディスクＩ／Ｏビューにアクセスする。

いくつかの実施形態では、修正されたシステム・コールは、共有メモリにアクセスする。

別の実施形態では、リソース・マネージャを作成するためのデジタルデータ記憶媒体が提供される。媒体は、デジタル・データ・ストレージ内に管理レベルＯＳを作成し、アプリケーション分離仮想空間に対するアプリケーション要求を監視し、アプリケーション分離仮想空間に対するいくつかのアプリケーション要求を許可するためのプログラムを含む。アプリケーション要求の許可は、アプリケーション分離仮想空間の分離識別子を判定することと、分離識別子に基づいて管理レベルＯＳを更新することと、デジタル・データ・ストレージ内にアプリケーション・ネットワーク・スタックを作成することとを含む。

様々な実施形態が、添付図面に示される。

リソース管理システムの一実施形態を概略的に示すブロック図を示す。 図１のリソース・マネージャの一実施形態を概略的に示すブロック図を示す。 例示的なシステム・コールを示す。 例示的なシステム・コールを示す。 例示的なシステム・コールを示す。 図２乃至５の機能ブロックを参照し、図２のリソース・マネージャを作成するための方法の一実施形態を示すフローチャートを示す。 図２乃至５の機能ブロックを参照し、図２のリソース・マネージャによるシステム・コールを処理するための方法の一実施形態を示すフローチャートを示す。 図１のエンド・リソース・マネージャ１１０の一実施形態のブロックを概略的に示す。

理解を容易にするために、同一の参照番号は、実質的に同じもしくは同様の構造および／または実質的に同じもしくは同様の機能を有する要素を示すために使用されている。

アプリケーション分離仮想空間は、リソース・マネージャを利用するオペレーティングシステム（ＯＳ）によって作成される。リソース・マネージャは、従来のＯＳカーネルのネットワーク・スタックおよびＩ／Ｏサブシステムを、ＯＳによって管理される物理リソースの複数の分離されたネットワーク・スタック・ビューおよび／または仮想Ｉ／Ｏビューを有するように書き換えることによって、アプリケーションを互いに分離する。分離されたネットワーク・スタックおよび仮想Ｉ／Ｏビューは、アプリケーションの分離仮想空間に割り当てられたリソースを識別し、分離識別子を介してアプリケーションにマッピングされる。

図１は、リソース管理システム１００の一実施形態を概略的に示すブロック図を示す。リソース管理システム１００は、リソース管理システム１００のリソース・クラスタ１２０内のリソースの割り当てを制御する、リソース・マネージャ１１０を含む。

以下でさらに詳細に説明するリソース・マネージャ１１０は、リソース・クラスタ１２０内のリソースの、アプリケーションへの割り当てを制御する。

リソース・クラスタ１２０は、リソース・マネージャ１１０によって割り当てられた物理システム・リソースを含むことができる。リソースは、例えば、１つまたは複数のプロセッサ１３０、１つまたは複数のネットワーク・インタフェース１４０、およびデジタル・データ・ストレージ１５０を含むことができる。

デジタル・データ・ストレージ１５０は、１つまたは複数の記憶デバイス１５４および１つまたは複数のメモリ・デバイス１５８を含むことができる。記憶デバイス１５４は、不揮発性データを格納するのに適した任意の装置を含むことができる。メモリ・デバイス１５８は、ＣＰＵによって主記憶デバイスとしてアクセスされるのに適した任意の装置を含むことができる。

いくつかの実施形態では、リソース・マネージャ１１０は、デジタル・データ・ストレージ１５０内に配置され、１つまたは複数のプロセッサ１３０によって実行される１つまたは複数の実体的なプログラム内で具体化されてよい。

いくつかの実施形態では、リソース・マネージャ１１０は、リソース・クラスタ１２０内のリソースの、個々のアプリケーションへの割り当てを決定するために、リソース・テンプレートを含む。リソース・テンプレートは、アプリケーションのクラスに基づいて、アプリケーション毎にカスタマイズされてよく、および／または、それらは、課金および／またはサービスレベル・アグリーメントに基づくことができる。リソース・テンプレートは、ＣＰＵサイクル（すなわち、プロセッサ）要件、ネットワーク・インタフェース要件、ストレージ使用要件、および／またはメモリ使用要件のような、様々なタイプのアプリケーション・リソース要件のいずれかに関連するパラメータ値を含むことができる。

ＣＰＵ要件は、専用プロセッサ（複数可）および／またはコア（複数可）に関する要件、タイム・スライス（アプリケーションに利用可能なコアのティック数）、優先順位、最大待ち時間など、任意の適切なパラメータまたはパラメータの組み合わせを含むことができる。ネットワーク・インタフェース要件は、ＩＰアドレス、最大待ち時間、最小帯域幅など、任意の適切なパラメータまたはパラメータの組み合わせを含むことができる。ストレージ使用要件は、ストレージ・サイズ、アクセス速度など、任意の適切なパラメータまたはパラメータの組み合わせを含むことができる。メモリ使用要件は、アクセス速度、利用可能な最小の物理メモリおよび弾性的拡張など、任意の適切なパラメータまたはパラメータの組み合わせを含むことができる。

いくつかの実施形態では、リソース・クラスタ１２０内のリソースは、サーバのような単一の物理的エンティティから供給されてよい。他の実施形態では、リソース・クラスタ１２０内のリソースは、物理的に分離されたエンティティから供給されてよい。

一実施形態では、プロセッサ１３０は、機器の１つまたは複数のラック（ｒａｃｋ）内のいくつかのブレード（ｂｌａｄｅ）であってよく、ネットワーク・インタフェース１４０は、いくつかのネットワーク・インタフェース・カード（ＮＩＣ）であってよく、記憶デバイス１５４は、いくつかの外部記憶デバイスを含んでよく、メモリ・デバイス１５８は、機器の１つまたは複数のラック内のいくつかのブレードであってよい。いくつかの実施形態では、リソースの一部は、（例えば、クラウド・ネットワーク内に）遠隔配置された装置によって提供されてよいことを理解されたい。

いくつかの実施形態では、記憶デバイス１５４は、ハードディスク・ドライブ、光ディスク・ドライブ、フラッシュメモリ、などであってよい。

いくつかの実施形態では、メモリ・デバイス１５８は、ランダム・アクセス・メモリ（ＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、フラッシュメモリ、などであってよい。

図２は、図１のリソース・マネージャ１１０の一実施形態を概略的に示すブロック図を示す。リソース・マネージャ１１０は、オペレーティングシステムおよび個々のアプリケーションへの、図１のリソース・クラスタ１２０内のリソースの割り当てを制御する管理レベルＯＳ２１０を含む。本明細書で言及するように、所与のアプリケーションに割り当てられた集合的リソースは、上述したアプリケーションが内部で動作している「アプリケーション分離仮想空間」である。アプリケーションに割り当てられた集合的リソースは、割り当てられた専用リソースおよび共有リソース（すなわち、アプリケーション専用ではないリソース）の両方を含む。共有リソースは、管理レベルＯＳ２１０内に存在してよく、一方、別々のネットワーク・スタックおよびＩ／Ｏ設備は、仮想ネットワーク・スタック２２０内に保持されることになる。有利には、各アプリケーション分離仮想空間は、各仮想空間インスタンス専用のハードウェア・リソースを必要とすることなく、独立したエンティティとして外部ネットワークに対して現れる。本明細書で使用される「アプリケーション」という用語は、サービスも含むものとして、広く解釈されるべきである。

リソース・マネージャ管理レベルＯＳ２１０は、リソースの割り当てを制御するための構造を含み、オプションで、共有リソースのためのコントローラも含む。アプリケーション・プロセスは、リソースへの直接のアクセスを制限される。代わりに、管理レベルＯＳ２１０は、Ｉ／Ｏデバイス、ファイル・システム、およびネットワーク通信設備のようなリソースにアクセスするための抽象化層を提供する。

割り当て制御構造は、制御プログラム（図示せず）およびリソース・テーブル２１８を含むことができる。リソース・テーブルは、分離識別子をアプリケーションの分離された仮想空間にマッピングするために、制御プログラムによって使用される。共有リソース・コントローラは、スケジューラ２１２、メモリ・アロケータ・プログラム２１４、および共通ドライバ２１６を含むことができる。有利には、管理レベルの１つのＯＳのみが必要とされるが、必要に応じて、より多くの管理レベルのＯＳが使用されてよい。

仮想ネットワーク・スタック２２０は、管理ネットワーク・スタック２３０、および、１つまたは複数のアプリケーション・ネットワーク・スタック２４０−１〜２４０−Ｎを含む。管理ネットワーク・スタック２３０は、インフラストラクチャ・オペレータのために提供されるＯＳの管理ビューである。各アプリケーション・ネットワーク・スタック２４０−１〜２４０−Ｎ、集合的にアプリケーション・ネットワーク・スタック２４０は、一意的なネットワーク・スタック（ＩＰ層）および一意的な仮想Ｉ／Ｏ層である。管理レベルＯＳ２１０は、アプリケーション・ネットワーク・スタック２４０へのアプリケーションのアクセスを制御するために、分離識別子およびリソース・テーブル２１８を使用する。

各ネットワーク・スタック・インスタンスは、他のすべてのものから完全に独立しており、そのため、各インスタンスは、固有のプライベート・ルーティング・テーブル、通信ソケットのセット、および、関連するプロトコル制御ブロックを保持する。その個々のアプリケーション分離仮想空間内で動作するアプリケーション・プロセスのみがアクセスを有するように、ネットワーク・スタックへのアクセスを制御するために、分離識別子を使用することができる。このような構成は、パフォーマンスを向上させ、同時に、アプリケーション・ネットワーク・スタック２４０を互いに分離するため、有利である。アプリケーション・ネットワーク・スタック２４０には、一意的なリソースを割り当てることもでき、例えば、各アプリケーションは、固有のＩＰアドレスおよびポートを保持することを許可されてよいことを理解されたい。

単一の一意的なリソースの使用を、リソースへのアクセスを争うアプリケーション間で共有する（例えば、ＭＵＸ／ＤＥＭＵＸする）ために、スケジューラ２１２を管理レベルＯＳ２１０によって作成することができる。スケジューラ２１２は、要求しているアプリケーション間で供給リソースを割り当てるために管理レベルＯＳ２１０によって利用されるスケジューリング・アルゴリズムを含むことができる。

利用可能なメモリ（例えば、図１のメモリ・デバイス１５８）をアプリケーションに割り当てるために、メモリ・アロケータ２１４を、管理レベルＯＳ２１０によって利用することができる。

重複ドライバに関連するオーバヘッドを低減するために、共通ドライバ２１６を、管理レベルＯＳ２１０によって利用することができる。例えば、共通ドライバ２１６中の単一のイーサネット（登録商標）層ドライバは、ＭＡＣ（媒体アクセス制御）および管理レベルＯＳ２１０間の通信を提供することができ、その上のネットワーク層プロトコルおよびアプリケーション層へのアクセスを提供することもできる。

分離識別子を使用してアプリケーションの分離仮想空間にリソースをマッピングするために、リソース・テーブル２１８を、管理レベルＯＳ２１０によって利用することができる。

いくつかの実施形態では、管理レベルＯＳ２１０は、ＯＳの起動中に、従来のネットワーク・スタックおよびＩ／Ｏ機能、例えば、管理ネットワーク・スタック２３０を作成する。アプリケーション分離仮想空間を必要とするこの環境で起動する各後続の可視アプリケーションのために、管理レベルＯＳ２１０は、アプリケーション・ネットワーク・スタック２４０−Ｘを作成し、ここで、「Ｘ」は、アプリケーション・ネットワーク・スタック２４０の１つを示す。

いくつかの実施形態では、管理レベルＯＳ２１０は、アプリケーションを他のアプリケーションから分離するために、分離識別子を使用することによって、カーネルへのシステム・コールの動作を修正する。例えば、システム上のすべてのネットワーク・デバイスに戻るシステム・コールを実行するアプリケーション・プロセスは、それ自体のアプリケーション分離仮想空間内のデバイス（実または擬似）のみに応答する。したがって、他のネットワーク・デバイスは、アプリケーションのプロセスによって使用されず、または見られさえしないことになる。

いくつかの実施形態では、Ｕｎｉｘ（登録商標）／Ｌｉｎｕｘ（登録商標）／ＰＯＳＩＸ（登録商標）グループＩＤ（ＧＩＤ）が、分離識別子である。ＧＩＤは、従来、学生のグループまたは従業員の部署のようなユーザのグループを作成するために使用される。ユーザおよびグループの概念は、通常、サーバで使用されないため、アプリケーションを作成するプロセスのグループを編成するために、管理レベルＯＳ２１０によってＧＩＤを利用することができる。このように、管理レベルＯＳ２１０は、アプリケーションのプロセスによる使用に利用可能なアプリケーション分離仮想空間内のリソースを識別する。いくつかの実施形態では、修正されたシステム・コールは、他のアプリケーションによって使用されるリソースのハンドルおよび／または名前の閲覧およびアクセスを抑制する。

有利には、分離識別子を使用するアプリケーション・ネットワーク・スタック２４０の管理は、アプリケーションから物理ネットワーク・インタフェースへのデータ・パス上の著しく少ないオーバヘッドを可能にする。それは、また、アプリケーション・ネットワーク・スタックを分離しない従来のＯＳ環境と比較して、他のシステム・リソース、具体的にはＣＰＵおよびＲＡＭのよりよい利用をもたらす。

いくつかの実施形態では、スケジューラ２１２は、アプリケーション間でＣＰＵ処理サイクル（例えば、図１のプロセッサ１３０）を共有するようにプログラムされたスケジューリング・アルゴリズムを含む。プロセッサ１３０は、１つまたは複数のコアをそれぞれが含み得る１つまたは複数のプロセッサを含んでよいことを理解されたい。スケジューラ２１２は、コア（複数可）および／またはプロセッサ（複数可）の全部または一部をアプリケーションに割り当てるために、リソース・テンプレートを使用することができる。スケジューリング・アルゴリズムは、従来の公平（ｆａｉｒｎｅｓｓ）アルゴリズムおよび／または従来の優先アルゴリズムのような、任意の適切なアルゴリズムであってよい。コア（複数可）および／またはプロセッサ（複数可）は、アプリケーション間で共有されてもよく、または、アプリケーション専用であってもよいことを理解されたい。例えば、実時間決定性アプリケーションは、専用のコア（複数可）および／またはプロセッサ（複数可）を必要とする可能性がある。

いくつかの実施形態では、スケジューラ２１２は、割り当てられていないおよび／または活用されていないリソースを、リソースを要求するアプリケーション・プロセス間に分配することができる。活用されていないリソースは、アプリケーション専用であるが、その割り当てられた部分の全ての範囲まではアプリケーションによって使用されていないリソースである。

いくつかの実施形態では、スケジューラ２１２は、第２のアプリケーション分離仮想空間内のリソースの使用をスケジュールするために使用されるのとは異なるスケジューリング・アルゴリズムを使用して、第１のアプリケーション分離仮想空間内のリソースの使用をスケジュールすることができる。

いくつかの実施形態では、メモリ・アロケータ２１４は、アプリケーションに割り当てられるメモリの量およびタイプを決定するために、リソース・テーブル２１８を利用することができる。さらに、メモリ・アロケータ２１４、または、オプションでリソース・テーブル２１８は、アプリケーションのプロセスにすでに割り当てられたメモリの量、およびオプションでタイプを決定するために、メモリ・テーブルを含むことができる。このように、メモリ・アロケータ２１４は、次に、メモリに対するアプリケーションのプロセスからの要求が、許可されるべきかどうかを判定することができる。

いくつかの実施形態では、メモリ・アロケータ２１４は、図３に示すｍａｌｌｏｃ（）コマンドのような従来のメモリ割り当て技術を修正する。メモリ・アロケータ２１４は、要求するプロセスのアプリケーションに利用可能なリソースを分離するようにｍａｌｌｏｃ（）コマンドをカスタマイズするために、分離識別子（例えば、ＧＩＤ）を利用することによって、従来のｍａｌｌｏｃ（）システム・コールを修正する。

例えば、図３および４、ならびに、以下に示す擬似コード・ライン（１）〜（１５）を参照すると、アプリケーションのプロセスは、サイズ・パラメータ・セットを有するｍａｌｌｏｃ（）システム・コールを、コード・ライン（１）で要求されるメモリのブロックに使用することによって、メモリブロックを要求する。修正されたｍａｌｌｏｃ（）要求は、次に、アプリケーションに割り当てられたメモリの量（例えば、ＲｅｓｏｕｃｅＴａｂｌｅ［ＧＩＤ］［ＡｌｌｏｃａｔｅｄＭｅｍｏｒｙ］）、および、すでにアプリケーションによって使用中のメモリの量（例えば、ＭｅｍｏｒｙＴａｂｌｅ［ＧＩＤ］［ＵｓｅｄＭｅｍｏｒｙ］）を決定する。

コード・ライン（２）では、メモリ・アロケータ２１４は、プロセス分離識別子（例えば、ＧＩＤ）を取得する。

コード・ライン（３）では、メモリ・アロケータ２１４は、アプリケーションによって使用中のメモリ、および要求されたメモリブロックのサイズの合計と、アプリケーションに割り当てられたメモリとを比較することによって、メモリがアプリケーションに利用可能かどうかを判定する。

コード・ライン（３）の比較が、真である場合、コード・ライン（５）で、割り当てられた空間へのポインタを返すことによって、メモリが割り当てられる。コード・ライン（６）では、メモリ・アロケータ２１４は、従来のｍａｌｌｏｃ（）が、要求されたメモリブロックを割り当てることに成功したかどうかを判定する。従来のｍａｌｌｏｃ（）が成功した場合、メモリ・アロケータ２１４は、コード・ライン（７）で、割り当てられたメモリの更新された量を反映するように、メモリ・テーブルを更新する。そして、成功したかどうかに関わらず、ｍａｌｌｏｃ（）は、コード・ライン（８）で、割り当てられたメモリへのポインタを返す。

コード・ライン（３）の比較が、偽である場合、メモリ・アロケータ２１４は、コード・ライン（１２）で、要求を満たすために十分なストレージがないことを示すために、ｍａｌｌｏｃ（）ｅｒｒｎｏをセットし、コード・ライン（１３）で、ヌル・ポインタまたは他の指標ポインタを返す。

（１）ｍｏｄｉｆｉｅｄ＿ｍａｌｌｏｃ（ｓｉｚｅ＿ｔ ｓｉｚｅ）｛
（２）ＧＩＤ＝ｇｅｔｇｉｄ（）；
（３）ｉｆ（（ＭｅｍｏｒｙＴａｂｌｅ［ＧＩＤ］［ＵｓｅｄＭｅｍｏｒｙ］＋ｓｉｚｅ）≦ＲｅｓｏｕｒｃｅＴａｂｌｅ［ＧＩＤ］［ＡｌｌｏｃａｔｅｄＭｅｍｏｒｙ］）
（４） ｛
（５） ｃｈａｒ＊ｂｕｆｆｅｒ＝ｍａｌｌｏｃ（ｓｉｚｅ）；
（６） ｉｆ（＊ｂｕｆｆｅｒ！＝ＮＵＬＬ＆＆ｅｒｒｎｏ＝＝０）
（７） ＭｅｍｏｒｙＴａｂｌｅ［ＧＩＤ］［ＵｓｅｄＭｅｍｏｒｙ］＋＝ｓｉｚｅ；
（８） ｒｅｔｕｒｎ＊ｂｕｆｆｅｒ；
（９） ｝
（１０）ｅｌｓｅ
（１１） ｛
（１２） ｓｅｔ ｅｒｒｎｏ＝ＥＮＯＭＥＭ；
（１３） ｒｅｔｕｒｎ ＮＵＬＬ ＰＯＩＮＴＥＲ；
（１４） ｝
（１５）｝

いくつかの実施形態では、分離識別子を、仮想ディスクＩ／Ｏビュー２４６の１つにマッピングするために、管理レベルＯＳ２１０によってリソース・テーブル２１８を利用することができる。このようなマッピングは、ＯＳシステム・コール・レベルでのアプリケーション・ビューを、アプリケーションのＩ／Ｏ環境に制限する。例えば、分離識別子は、同じマシン上で動作する他のアプリケーションおよび／またはサービスが、同じポートで異なるＩＰアドレスを開くときでさえ、アプリケーションが、一意的な特定のＩＰアドレス／ポートでソケットを開くことを可能にする。

別の例では、「経路」が、実際のｉノードにマッピングされるが、経路は、アプリケーションの仮想ディスクＩ／Ｏビュー２４６−Ｘ内へのこの分離識別子のカスタム・ビューである。ここで、「Ｘ」は、アプリケーションの仮想ディスクＩ／Ｏビューの１つを示す。従来、Ｉ／Ｏデバイス、ドライバ、および他のシステム・リソースにアクセスするために、アプリケーションのプロセスによって、／ｄｅｖファイル・システムを使用することができる。例えば、／ｄｅｖファイル・システムは、／ｄｅｖ／ｓｄａのようなディスク・ドライバへのアクセスを提供する。従来のＯＳは、典型的には、Ｌｉｎｕｘシステム上のハードディスクのためのドライバを提供することになる。分離識別子によって変更される同様の要求では、／ｄｅｖ／ｓｄａは、アプリケーション分離仮想空間の知識を有するドライバ内への入口となる。要求応答は、分離識別子によって識別されるアプリケーション分離仮想空間に割り当てられたディスクの（または、仮想ディスクの）シリンダのサブセットのみを含むように許可されることになる。

例えば、図４および５、ならびに擬似コード・ライン（１６）〜（２０）を参照すると、修正されたｇｅｔｃｗｄ（）要求は、アプリケーションの仮想ディスクＩ／Ｏビュー２４６−Ｘ内の現在の作業ディレクトリを取得するために、分離識別子を利用する。

コード・ライン（１６）では、アプリケーションのプロセスは、ｇｅｔｃｗｄ（）システム・コールを、文字配列へのポインタ、および配列のサイズと共に使用することによって、現在の作業ディレクトリを要求する。コード・ライン（１６）では、現在の作業ディレクトリは、従来のｇｅｔｃｗｄ（）要求を使用して取得される。このような要求は、現在の作業ディレクトリを、「／ｍａｃｈｉｎｅｓ／ｍａｃｈｉｎｅ１／ａｐｐｌｉｃａｔｉｏｎ１／ｄｉｒ１」のような文字列で返すことができる。返される文字列は、システムＩ／Ｏビュー内のディレクトリの場所のシステム・ビューである。

コード・ライン（１７）では、装置２１４は、プロセッサの分離識別子（例えば、ＧＩＤ）を取得する。

コード・ライン（１８）では、システムＩ／Ｏビューを、仮想ディスクＩ／Ｏビュー２４６に変換するために、カスタマイズされたコールが作成されてよい。ｔｒｉｍ＿ｇｉｄｂａｓｅ（）ルーチンは、要求を行うＧＩＤアプリケーションのベース文字列を検索するために、分離識別子（例えば、ＧＩＤ）を利用し、次に、返された現在の作業ディレクトリ文字列からそのベース文字列をトリミングする。例えば、ＧＩＤによって参照されるアプリケーションのベースが、"／ｍａｃｈｉｎｅｓ／ｍａｃｈｉｎｅ１"であった場合、ｔｒｉｍ＿ｇｉｄｂａｓｅ（）コールは、アプリケーション分離仮想空間の仮想ディスクＩ／Ｏビューに「／ａｐｐｌｉｃａｔｉｏｎ１／ｄｉｒ１」を返すように、検索された作業ディレクトリ文字列からこのベースを取り除くことになる。

（１６）ｍｏｄｉｆｉｅｄ＿ｇｅｔｃｗｄ（ｃｈａｒ＊ｂｕｆ，ｓｉｚｅ＿ｔ ｓｉｚｅ）｛
（１７）ｇｅｔｃｗｄ（ｂｕｆ）；
（１８）ＧＩＤ＝ｇｅｔｇｉｄ（）；
（１９）ｔｒｉｍ＿ｇｉｄｂａｓｅ（ｂｕｆ，ＧＩＤ）；
（２０）｝

同様に、いくつかの実施形態では、仮想ファイル・システム「／ｐｒｏｃ」によって識別されるリソースは、アプリケーション分離仮想空間にマッピングされてよい。「／ｐｒｏｃ」は、「実際の」ファイルを含まず、代わりに、実行時システム情報（例えば、システム・メモリ、取り付けられたデバイス、ハードウェア構成、など）を含むことに注意されたい。このように、「／ｐｒｏｃ」を、管理レベルＯＳ２１０のための制御および情報センタとみなすことができる。さらに、いくつかのシステム・ユーティリティは、単に「／ｐｒｏｃ」内のファイルへの呼び出しであるため、「／ｐｒｏｃ」ディレクトリ内に位置するファイルを変更することによって、分離識別子を利用するようにシステム・ユーティリティを修正することができる。例えば、「ｌｓｍｏｄ」は、「ｃａｔ／ｐｒｏｃ／ｍｏｄｕｌｅｓ」と同じであり、一方、「ｌｓｐｃｉ」は、「ｃａｔ／ｐｒｏｃ／ｐｃｉ」の同義語である。修正されたｇｅｔｃｗｄ（）ルーチンと同様に、これらのシステム・ユーティリティは、アプリケーション分離仮想空間ビューに基づいて情報を返すために、分離識別子を使用するように修正されてよい。

図６は、図１および２の機能ブロックを参照して、図２のリソース・マネージャ１１０を形成するための方法の一実施形態を示すフローチャートを示す。方法６００は、管理レベルＯＳを作成する工程（例えば、ステップ６１０）、および管理ネットワーク・スタックを作成する工程（例えば、ステップ６２０）を含む。方法６００は、アプリケーション分離仮想空間が、新しいアプリケーションのために作成されるべきかどうかを監視する工程（例えば、ステップ６３０）も含む。アプリケーション分離仮想空間が作成されるべき場合、装置は、アプリケーション分離仮想空間のための分離識別子を決定する（例えば、ステップ６４０）。装置は、次に、管理レベルＯＳを更新し（例えば、ステップ６６０）、分離識別子に基づいてアプリケーション・ネットワーク・スタックを作成する（例えば、ステップ６５０）。管理レベルＯＳ、管理ネットワーク・スタック、およびアプリケーション・ネットワーク・スタックのデータ構造およびプログラムの一部または全部は、図１のデジタル・データ・ストレージ１５０に格納されてよいことを理解されたい。

方法６００では、ステップ６１０は、図２乃至５に記載の管理レベルＯＳ２１０のような管理レベルＯＳを作成する工程を含む。

方法６００では、ステップ６２０は、図２乃至５に記載の管理ネットワーク・スタック２３０のような管理ネットワーク・スタックを作成する工程を含む。

方法６００では、ステップ６３０は、アプリケーション分離仮想空間が、新しいアプリケーションのために作成されるべきであるかどうかを監視する工程を含む。管理レベルＯＳは、例えば、システム・ハイパーバイザからの、アプリケーション仮想空間を確立するための要求を監視することができる。要求が受信され、管理レベルＯＳが、要求を許可するべきであると判定すると、方法は、ステップ６４０に進む。管理レベルＯＳは、単に、アプリケーション分離仮想空間を確立する要求のすべてを受け入れることができ、または、リソースがアプリケーションに割り当てられるために利用可能であるかどうかを判定することができる。

方法６００では、ステップ６４０は、新しいアプリケーションのための分離識別子を決定する工程を含む。分離識別子は、図２乃至５に関連して説明したように、リソースをアプリケーション分離仮想空間にマッピングする。

方法６００では、ステップ６５０は、分離識別子に基づいて管理レベルＯＳを更新する工程を含む。管理レベルＯＳは、図２乃至５に関連して説明したように、アプリケーション分離仮想空間に割り当てられたリソースをマッピングするために、分離識別子を使用する。

方法６００では、ステップ６６０は、分離識別子に基づいてアプリケーション層ネットワーク・スタックを作成する工程を含む。アプリケーション層ネットワーク・スタックは、図２乃至５に関連して説明したように、分離識別子を使用して、管理レベルＯＳのリソース制御をマッピングする。

方法６００のいくつかの実施形態では、管理レベルＯＳは、図２乃至５に記載のような割り当て制御構造を含む。例えば、管理レベルＯＳは、制御プログラム、リソース・テーブル（例えば、図２のリソース・テーブル２１８）、スケジューラ（例えば、図２のスケジューラ２１２）、メモリ・アロケータ（例えば、図２のメモリ・アロケータ２１４）、および共通ドライバ（例えば、図２の共通ドライバ２１６）を含むことができる。

これらの実施形態では、ステップ６６０は、分離識別子をリソース・ベース名にマッピングするために、リソース・テーブル２１８を更新する工程を含むことができる。更新する工程は、スケジューラ・アルゴリズム内のＣＰＵサイクルのスケジューリングを変更するために、スケジューラ２１２を更新する工程を含むこともできる。更新する工程は、メモリ・アロケータ２１４を更新する工程を含むこともできる。メモリ・アロケータは、リソース・テンプレートからメモリ割り当てパラメータを取得し、要求されたメモリがメモリ・デバイス（例えば、図１のメモリ・デバイス１５８）内で利用可能であることを確認し、次に、要求しているアプリケーションによって使用される現在のメモリを反映するために、そのメモリ使用パラメータをリセットすることができる。

いくつかの実施形態では、ステップ６３０は、受信した要求に、または、リソース・マネージャによるアプリケーションの解析に基づいて、アプリケーションの新しいインスタンスを実行するように決定する工程を含むことができる。アプリケーション解析は、アプリケーションが低速で動作しているかどうかの決定であってよい。リソース・マネージャは、そのアプリケーションに設定された性能しきい値に対するアプリケーションの応答時間を監視することによって、アプリケーションが低速で動作していると判定することができる。

同様に、リソース・マネージャは、アプリケーションの活用されていないインスタンスを停止することができることを理解されたい。

図７は、図１および２の機能ブロックを参照し、図２のリソース・マネージャ１１０によるシステム・コールを処理するための方法の一実施形態を示すフローチャートを示す。方法７００は、修正されたシステム・コールを作成する工程（ステップ７１０）を含む。管理レベルＯＳは、次に、アプリケーション要求を監視することになり（ステップ７２０）、要求が受信されると、要求を、修正されたシステム・コールに向けることになる（ステップ７３０）。修正されたシステム・コールは、次に、分離識別子を取得し（ステップ７４０）、分離識別子によってアプリケーションにマッピングされたアプリケーション分離仮想空間のリソースに基づいて、アプリケーションの要求に応答するために、分離識別子を使用することができる。

方法７００では、ステップ７１０は、修正されたシステム・コールを作成する工程を含む。従来のシステム・コールは、図２乃至５に関連して説明したように修正される。修正されたシステム・コールは、アプリケーションが、そのアプリケーション分離仮想空間内のシステム・コールを利用することを可能にする。

方法７００では、ステップ７２０は、いつシステム・コールに応対するかを決定するために、アプリケーション要求を監視する工程を含む。管理レベルＯＳが、アプリケーション要求を満たすべきであると判定した場合、方法は、ステップ７３０に進む。

方法７００では、ステップ７３０は、修正されたシステム・コールを呼び出す工程を含む。修正されたシステム・コールは、図２乃至５に関連して説明したように呼び出される。

方法７００では、ステップ７４０は、修正されたシステム・コールで使用されるべき分離識別子を取得する工程を含む。分離識別子は、図２乃至５に関連して説明したように取得される。いくつかの実施形態では、分離識別子は、システム・コールの一部であってよく、または、修正されたシステム・コールで（例えば、ｇｅｔｇｉｄ（）を使用して）検索されてよい。他の実施形態では、分離識別子は、システム・コール内の情報に基づいて取得されてよい。例えば、要求が属するアプリケーション分離仮想空間を識別するために、ＩＰアドレス／ポート・タプルが使用されてよい。この識別は、タプルを分離識別子と一致させるためのリソース・テーブル（例えば、図２の２１８）を検索するために、受信した要求からの一意的なＩＰアドレス／ポート・タプルを使用することができる。

方法７００では、ステップ７５０は、図２乃至５に関連して説明したように、分離識別子に基づいてアプリケーション・リソースを利用する工程を含む。上述したように、装置は、プロセスにシステム・リソースの分離ビューを与えるために、分離識別子を使用する。システム・リソースの分離ビューは、アプリケーションのビューを、そのアプリケーション分離仮想空間内のこれらのリソースのみに制限する。いくつかの実施形態においては、アプリケーションが、割り当てられていないリソースへのアクセスを有することになる場合、ビューは、これらのリソースを含むこともできる。

方法７００のいくつかの実施形態では、ステップ７１０は、オプションであってよい。例えば、装置は、以前に作成された修正されたシステム・コールを使用することができる。このような以前に作成された修正されたシステム・コールは、デジタル・データ・ストレージ内に格納されてよく、または、後述するプログラム記憶デバイス内に設けられてよい。

特定の順序で主に示され、説明されているが、方法６００および７００に示すステップは、任意の適切な順序で実行されてよいことを理解されたい。さらに、１つのボックスで示すステップは、シーケンス内の複数の場所で実行されてもよい。

様々な上述した方法のステップは、プログラムされたコンピュータによって実行されてよいことを理解されたい。ここで、いくつかの実施形態は、プログラム記憶デバイス、例えば、デジタルデータ記憶媒体をカバーすることも意図され、デジタルデータ記憶媒体は、機械またはコンピュータ可読であり、命令の機械実行可能またはコンピュータ実行可能プログラムを符号化し、前記命令は、上述した方法のステップの一部または全部を実行する。プログラム記憶デバイスは、例えば、デジタル・メモリ、磁気ディスクおよび磁気テープのような磁気記憶媒体、ハード・ドライブ、または、光学的に読み取り可能なデジタルデータ記憶媒体であってよい。実施形態は、上述した方法の前記ステップを実行するようにプログラムされたコンピュータをカバーすることも意図される。

図８は、図１のエンド・リソース・マネージャ１１０の一実施形態の機能ブロックを概略的に示す。リソース・マネージャ１１０は、例えば、方法６００および／または７００を使用して、アプリケーション分離仮想空間を管理することができる。リソース・マネージャ１１０は、プロセッサ８１０およびデジタル・データ・ストレージ８１１を含む。

プロセッサ８１０は、リソース・マネージャ１１０の動作を制御する。プロセッサ８１０は、デジタル・データ・ストレージ８１１と協働する。

デジタル・データ・ストレージ８１１は、共通ドライバ（例えば、図２の共通ドライバ２１６）およびリソース・テーブル（例えば、図２のリソース・テーブル２１８）を格納する。デジタル・データ・ストレージ８１１は、プロセッサ８１０によって実行可能なプログラム８２０も格納する。

プロセッサ実行可能なプログラム８２０は、スケジューラ・プログラム８２１、メモリ・アロケータ・プログラム８２３、および割り当て制御プログラム８２７を含むことができる。プロセッサ８１０は、図１〜７に記載の機能を実装するために、および／または、方法６００および／または７００のステップを実行するために、プロセッサ実行可能なプログラム８２０と協働する。

プロセッサ実行可能なプログラム８２０がプロセッサ８１０上で実施されると、プログラム・コード・セグメントは、特定の論理回路に類似した動作をする独自のデバイスを提供するために、プロセッサと結合する。

例えば、プログラムおよびロジックが、デジタル・データ・ストレージ内に格納され、メモリが、プロセッサに通信可能に接続される実施例に関して本明細書に示し、説明しているが、このような情報は、デバイスの任意の適切な構成に通信可能に結合されたメモリ、ストレージ、またはデータベースの任意の適切な構成を使用して、メモリ（複数可）、ストレージ（複数可）、および／または内部もしくは外部データベース（複数可）の任意の適切な組み合わせに情報を格納して、または、任意の適切な数のアクセス可能な外部メモリ、ストレージ、またはデータベースを使用して（例えば、任意の適切な数のメモリ、ストレージ、またはデータベースを使用する）、任意の他の適切な方法で格納されてよいことを理解されたい。このように、本明細書で参照されるデジタル・データ・ストレージという用語は、メモリ（複数可）、ストレージ（複数可）、およびデータベース（複数可）のすべての適切な組み合わせを包含するためのものである。

説明および図面は、単に、本発明の原理を例示する。したがって、当業者は、本明細書に明示的に説明または図示されていないが、本発明の原理を具体化し、その要旨および範囲内に含まれる様々な構成を考案することができることになることが理解されるであろう。さらに、本明細書に記載のすべての例は、主として、本発明の原理、および、技術を促進することに対して発明者（複数可）によって寄与される概念を理解する上で読者を助けるための、教育学的目的のためのみのものであることが明確に意図されており、このような具体的に記載された例および条件に限定されないものとして解釈されるべきである。さらに、本発明の原理、態様、および実施形態を列挙する本明細書のすべての文は、その等価物を包含することが意図される。

「プロセッサ」とラベル付けされた任意の機能ブロックを含む、図に示す様々な要素の機能は、専用ハードウェア、ならびに、適切なソフトウェアと関連してソフトウェアを実行することができるハードウェアの使用を介して提供されてよい。プロセッサによって提供される場合、機能は、単一の専用プロセッサによって、単一の共有プロセッサによって、または、そのいくつかが共有されてよい複数の個別のプロセッサによって提供されてよい。さらに、「プロセッサ」または「コントローラ」という用語の明示的な使用は、ソフトウェアを実行することができるハードウェアのみを指すものと解釈されるべきではなく、限定なしに、デジタル信号プロセッサ（ＤＳＰ）ハードウェア、ネットワーク・プロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲートアレイ（ＦＰＧＡ）、ソフトウェアを格納する読み取り専用メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、および不揮発性ストレージを暗黙的に含むことができる。従来のおよび／またはカスタムの他のハードウェアが含まれてもよい。同様に、図１に示すあらゆるスイッチは、単に概念的なものである。それらの機能は、プログラム・ロジックの動作を介して、専用ロジックを介して、プログラム制御および専用ロジックの相互作用を介して、または、手動でさえ実行されてよく、具体的な技術は、文脈からより具体的に理解されるように、実施者により選択可能である。

本明細書中のあらゆるブロック図は、本発明の原理を具体化する例示的な回路網の概念的図を表すことを理解されたい。同様に、あらゆるフローチャート、流れ図、状態遷移図、擬似コード、などは、コンピュータ可読媒体内に実質的に表現されてよく、コンピュータまたはプロセッサが明示的に示されているか否かにかかわらず、このようなコンピュータまたはプロセッサによって実行されてよい、様々なプロセスを表すことを理解されたい。

Claims (10)

1. リソース・マネージャを作成するための方法であって、
   デジタル・データ・ストレージに通信可能に結合されたプロセッサで、前記デジタル・データ・ストレージ内に管理レベルＯＳを作成するステップと、
   前記デジタル・データ・ストレージと協働する前記プロセッサによって、アプリケーション分離仮想空間に対するアプリケーション要求を監視するステップと、
   前記デジタル・データ・ストレージと協働する前記プロセッサによって、アプリケーション分離仮想空間に対する複数のアプリケーション要求を許可するステップと、
   を含み、
   前記アプリケーション要求を許可するステップは、
   前記アプリケーション分離仮想空間の分離識別子を決定するステップと、
   前記分離識別子に基づいて前記管理レベルＯＳを更新するステップと、
   前記デジタル・データ・ストレージ内にアプリケーション・ネットワーク・スタックを作成するステップと、
   を含む、方法。
2. 前記管理レベルＯＳを更新するステップは、
   少なくとも１つの共通リソース・スケジューラを更新するステップと、
   少なくとも１つのメモリ共通リソース・アロケータを更新するステップと、
   少なくとも１つのリソース・テーブルを更新するステップと、
   のうちの少なくとも１つをさらに含む、請求項１に記載の方法。
3. 前記デジタル・データ・ストレージと協働する前記プロセッサによって、システム・コール要求を受信するステップと、
   前記デジタル・データ・ストレージと協働する前記プロセッサによって、分離識別子を取得するステップと、
   前記デジタル・データ・ストレージと協働する前記プロセッサによって、前記分離識別子に基づいて前記システム・コール要求を満たすために、アプリケーション・リソースを利用するステップと、
   をさらに含む、請求項１に記載の方法。
4. リソース管理装置であって、
   デジタル・データ・ストレージを備え、前記デジタル・データ・ストレージが、少なくとも１つの記憶デバイスおよび少なくとも１つのメモリ・デバイスを含み、前記リソース管理装置が、さらに、
   少なくとも１つのネットワーク・インタフェースと、
   少なくとも１つのプロセッサと、
   を備え、前記少なくとも１つのプロセッサが、
   前記デジタル・データ・ストレージ内に管理レベルＯＳを作成し、
   アプリケーション分離仮想空間に対するアプリケーション要求を監視し、
   アプリケーション分離仮想空間に対する複数のアプリケーション要求を許可するように構成され、
   要求の前記許可が、
   前記アプリケーション分離仮想空間の分離識別子の決定と、
   前記分離識別子に基づく前記管理レベルＯＳの更新と、
   前記デジタル・データ・ストレージ内のアプリケーション・ネットワーク・スタックの作成と、
   を含む、リソース管理装置。
5. 前記管理レベルＯＳの更新が、少なくとも１つの共通リソース・スケジューラの更新をさらに含み、該１つの共通リソース・スケジューラは、前記分離識別子に基づいて、前記少なくとも１つのプロセッサへのアクセスを制御する、請求項４に記載の装置。
6. 前記少なくとも１つのプロセッサが、さらに、
   システム・コール要求を受信し、
   分離識別子を取得し、
   前記分離識別子に基づいて前記システム・コール要求を満たすために、アプリケーション・リソースを利用するように構成される、請求項４に記載の装置。
7. 前記システム・コール要求が、修正されたシステム・コールを呼び出す、請求項６に記載の装置。
8. 前記少なくとも１つのプロセッサが、さらに、システム・コールから前記修正されたシステム・コールを作成するように構成される、請求項６に記載の装置。
9. 前記修正されたシステム・コールが、仮想ディスクＩ／Ｏビューにアクセスする、請求項７に記載の装置。
10. 前記修正されたシステム・コールが、共有メモリにアクセスする、請求項７に記載の装置。

Images