JP2018503897A - クラウドシステムにおけるリソース管理 - Google Patents

Abstract

【課題】複数の物理及び／又はソフトウェアリソースのうち、ある物理及び／又はソフトウェアリソースに少なくとも１つの仮想リソースを割り振るための方法及び装置を得る。【解決手段】アフィニティ情報を考慮して、複数の物理及び／又はソフトウェアリソースのうち、ある物理及び／又はソフトウェアリソースに少なくとも１つの仮想リソースを割り振るための方法及び装置が提示され、アフィニティ情報は、要求された仮想リソースが、第１のテナントとは異なるテナントの１つ又は複数の仮想リソースと同じ物理及び／又はソフトウェアリソース上にコロケートされ得るかどうかを指定する。【選択図】図１

Description

本技術は、複数の物理及び／又はソフトウェアリソースのうち、ある物理及び／又はソフトウェアリソースに、少なくとも１つの仮想リソースを割り振るための方法及び装置に関する。特に、本技術は、電気通信クラウドシステムにおけるリソース管理のためのテナントアフィニティに関する。

ネットワーク機能仮想化（ＮＦＶ：Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎｓ Ｖｉｒｔｕａｌｉｚａｔｉｏｎ）は、通信サービスを提供するための手法である。ＮＦＶは、事業者のネットワークにおける現在のネットワーク機能（たとえば、ファイアウォール、ＤＰＩ、サービングゲートウェイ、．．．）を専用ハードウェアから汎用ＩＴインフラストラクチャに移動するために、ＩＴからの仮想化及び自動化技法を適用する。これらの変形されたネットワーク機能は、「仮想ネットワーク機能」（ＶＮＦ：Ｖｉｒｔｕａｌ Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎ）として知られている。ＶＮＦは、１つ又は複数の仮想機械（ＶＭ）及び仮想ネットワークから成ることができ、それらが合わさってネットワーク機能を実現する。これらのＶＭ及び仮想ネットワークは一般的に、本発明において仮想化リソースと呼ばれる。

本発明によって対処される問題のうちの１つは、リソースの物理クラスタ化に起因するデータセンターにおけるリソースの浪費である。この文脈における「物理クラスタ化」は、特定のベンダー（本明細書内で「テナント」とも呼ばれる）からのアプリケーションソフトウェアに計算及び記憶リソースの既定のセットが排他的に割り当てられることを意味する。したがって、別のベンダーからのアプリケーションソフトウェアはこれらのリソースを、使用されていない場合でも使用することができない。そのような「物理クラスタ化」には、２つの主な理由がある。
Ａ．セキュリティ：ベンダー（テナント）は、自身のＶＭが他のベンダー（テナント）からの他のＶＭと共有物理又はハイパーバイザソフトウェアリソース上にコロケートされることを、たとえば、ハイパーバイザ又はＶＭのバグを利用して競合ベンダーからのＶＭからのトラフィックを傍受する可能性によるセキュリティ上の理由で、望まないことがある。
Ｂ．パフォーマンス：ベンダー（テナント）は、自身のＶＮＦ（ひいては、基礎をなすＶＭ）のパフォーマンスが予測可能であることを保証することを望んでおり、そのため、第２のベンダーからのＶＭの機能不全は、第１のベンダーからのＶＭに影響を与える可能性がある。ベンダーが、自身のＶＭが障害に直面したときに障害理由を追跡し分析することも容易である。

「物理クラスタ化」は、２つの主な問題につながり得る。
１．データセンターのリソースの浪費：リソースクラスタの事前プロビジョニングは、特に事前プロビジョニングが、後にテナントの実際の要件と合致しなくなるような不適切な方法で行われる場合に、リソースの浪費につながり得る。具体的には、リソースのそのようなクラスタにおけるリソースの実際の使用は、トラフィック負荷、障害などの多様な要因により動的に変わることがある。
２．ベンダー／テナント要件へのより強い依存：データセンターにおけるリソースの物理クラスタ化は依然として、ＶＮＦソフトウェアの獲得をインフラストラクチャハードウェアに結び付ける。そのような行動は、物理／ハードウェアリソース上で実行されているアプリケーションソフトウェアから当該リソースを抽出することを目的とする仮想化を導入する当初の動機のうちの１つに大きく反する。

本開示を通じて、「ソフトウェア」という用語は、次のうちの１つを指す。第一に、異なるテナントによって共有されることがある、システムインフラストラクチャの一部であるソフトウェア、たとえば、ハイパーバイザソフトウェアの形態によるソフトウェア、第二に、アプリケーション又はサービスの機能、具体的にはネットワーク機能を実行するためにテナントによって提供されるソフトウェア。必要な場合、また文脈から別途明らかではない場合、用語の２つの別個の使用を区別するために、「ハイパーバイザソフトウェア」、「アプリケーションソフトウェア」、又は、「ＶＮＦソフトウェア」への明示的な言及が行われる。

図２は、上記で概説した物理クラスタ化問題の一例を示している。４つの異なるクラスタが作成され、それぞれのベンダー（テナント）、すなわち、Ｔ−Ａ、Ｔ−Ｂ、Ｔ−Ｃ及びＴ−Ｄに割り当てられる。この図はまた、どのようにしてＶＭがいくつかの物理ホスト（サーバ）に割り振られるかと、トラフィック負荷などに応じて、どのようにして物理クラスタ化が各クラスタ内のリソースの浪費につながり得るかとを示している。基本的に、共有された可能性があるデータセンターにおけるリソースのプールは、ここでは、異なるクラスタに断片化されており、クラスタの所有者／ユーザ以外のベンダー／テナントへのリソースの割振りが妨げられている。

データセンターのリソースクラスタ化の領域には、上記の問題に対処しようと試みるいくつかの既存の技術がある。１つの手法は、ＶＭｗａｒｅのＶＳｐｈｅｒｅ ５．５であり、これはオンライン（http://pubs.vmware.com/vsphere-55/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-55-resource-management-guide.pdf）で入手可能な「ｖＳｐｈｅｒｅ ＥＳＸｉ Ｖｃｅｎｔｅｒ ｓｅｒｖｅｒ ｒｅｓｏｕｒｃｅ ｍａｎａｇｅｍｅｎｔ ｇｕｉｄｅ」の中で説明されている。ＶＳｐｈｅｒｅにより、次のようないくつかのタイプのアフィニティを定義することができる。
・ＣＰＵアフィニティ：ＣＰＵアフィニティは、マルチプロセッサシステムにおける利用可能なプロセッサのサブセットへのＶＭの割当てを制約するために使用される、つまり、プロセッサへのＶＭの配置の制約を指定する。
・ＶＭアフィニティ：ＶＭ間アフィニティルールは、個々のＶＭ間のアフィニティ（又はアンチアフィニティ）を指定するために使用される、つまり、選択された個々のＶＭが同じホスト上で実行されるべきか、それとも別個の物理ホスト（サーバ）上で維持されるべきかを指定する。
・ＶＭホストアフィニティ：ＶＭホストアフィニティルールは、選択されたＶＭ分散型リソーススケジューラ（ＤＲＳ：Ｄｉｓｔｒｉｂｕｔｅｄ Ｒｅｓｏｕｒｃｅ Ｓｃｈｅｄｕｌｅｒ）グループの要素が、指定されたホストＤＲＳグループの要素上で実行できるかどうかを指定する。ＶＭホストアフィニティルールは、以下の構成要素を含む。ａ）１つのＶＭ ＤＲＳグループ、ｂ）１つのホストＤＲＳグループ、並びにｃ）ルールが必須（ｍｕｓｔ）であるか、それとも推奨（ｓｈｏｕｌｄ）であるか、及びルールがアフィニティ（実行される）を表すか、それともアンチアフィニティ（実行されない）を表すかの指定。

最後のタイプのアフィニティ（すなわち、ＶＭホストアフィニティ）は、データセンターにおけるリソースを区分し、図２に示すもののようなリソースクラスタを作成するために使用されるものである。特定の物理ホスト（ホストＤＲＳグループ）のこれらのクラスタは次いで、テナント（ＶＭ ＤＲＳグループ）に割り当てられ得る。だが、そのような作成がオフラインで（事前に計画されて）前もって行われて、ＶＭ割振り要求を受信する、つまり、割振りはあらかじめすでに指定されている。したがって、それは、リソース浪費の問題を解決しない。図２及び他の図におけるデータセンタースキーマは、物理サーバごとに４つの仮想機械（ＶＭ）を指定する。この構成は、説明のために選択されており、実際の実施形態では変わり得る、つまり、物理サーバごとに１つ又は複数の仮想機械があり得る。上記で概説したリソースクラスタの事前計画及び割振りの欠点に加えて、アフィニティルールの指定及び維持は、異なる要件を伴う多様な作業負荷を有する多数のテナントを抱えたデータセンター構成では特に、非常に複雑で大きな労力を要することがある。
アフィニティグループを宣言し、そのようなアフィニティグループに基づいてデータ項目及び計算リソースを割り振ることに基づく同様の手法は、米国特許第８５７７８９２ Ｂ２号においてＰｅｉｒａｕｌｔらによって説明されている。この手法の基本的な考えは、計算リソースをアフィニティグループに関連付けることができ、そのようなアフィニティグループを地理的領域又はいくつかのデータセンターに関連付けることができるというものである。データ項目及び計算リソースは、アフィニティグループに関連付けられ、次いで、そのような関連付けられたアフィニティグループに基づいて割り振られ得る。この解決策は、ＶＭｗａｒｅがそのＤＲＳクラスタを介してサポートするものと非常に似ている。

別の手法は、米国特許第８４０２１３９Ｂ２号においてＦｅｒｒｉｓらによって提示されており、クラウド管理システムであり得るマッチングシステムが、データセンターにおける物理ホスト又はサーバであり得る利用可能なクラウド機器に関する情報を収集し、これらの機器を、ユーザに要求されたサービスとマッチングする。そのような要求されたサービスは、いくつかのＶＭ上に配備されたアプリケーションである。マッチングシステムはリソースを追跡し管理することもできるので、ユーザは特定の権利を有することができ、割り当てられたリソースはユーザに利用可能となる。だが、米国特許第８４０２１３９ Ｂ２号は、他のテナント要求と比較して、表された必要なアフィニティに基づいてリソースを割り振る問題を解決していない。

別の手法は、ＡＣＭ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｍｅａｓｕｒｅｍｅｎｔ ａｎｄ Ｍｏｄｅｌｉｎｇ ｏｆ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍｓ （ＳＩＧＭＥＴＲＩＣＳ ２０１３）において「Ｄｅｆｒａｇｍｅｎｔｉｎｇ ｔｈｅ Ｃｌｏｕｄ Ｕｓｉｎｇ Ｄｅｍａｎｄ−ｂａｓｅｄ Ｒｅｓｏｕｒｃｅ Ａｌｌｏｃａｔｉｏｎ」の中でＧ． Ｓｈａｎａｍｕｇａｎａｔｈａｎらによって説明されている。著者は、顧客によって購入された大量のリソースをそのＶＭの間で、個々の需要並びに他のテナント指定の制御、たとえば、予約、制限及び優先度に基づいて動的に割り振る２つのアルゴリズムを提案している。提案された分散型二分探索（ＤＢＳ：Ｄｉｓｔｒｉｂｕｔｅｄ Ｂｉｎａｒｙ Ｓｅａｒｃｈ）アルゴリズムは、集中型のＶＭｗａｒｅのＤＲＳリソースマネージャのアルゴリズムと合致するが、分散型環境で機能している。また、他の提案されたアルゴリズム、Ｂａｓｅ＋Ｐｒｏｐｏｒｔｉｏｎａｌ Ｅｘｃｅｓｓ（ＢＰＸ）は、完全に非同期である。この解決策の主な相違として、本明細書で開示する技術に関係する、クラウド／データセンターリソースのデフラグを可能にするが、この場合、割振りは、ＶＭ負荷及び顧客による要求で表されるＶＭの負荷優先度に基づく。したがって、この解決策は明示的なテナント間アフィニティ情報を考慮しない。

リソースがアフィニティグループに基づいて割り振られるとき、前述の手法はすべて、リソースグループがあらかじめ事前計画された方法で割り振られることを必要とする。

米国特許第８４０２１３９Ｂ２号

"ｖＳｐｈｅｒｅ ＥＳＸｉ Ｖｃｅｎｔｅｒ ｓｅｒｖｅｒ ｒｅｓｏｕｒｃｅ ｍａｎａｇｅｍｅｎｔ ｇｕｉｄｅ"、http://pubs.vmware.com/vsphere-55/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-55-resource-management-guide.pdf "Ｄｅｆｒａｇｍｅｎｔｉｎｇ ｔｈｅ Ｃｌｏｕｄ Ｕｓｉｎｇ Ｄｅｍａｎｄ−ｂａｓｅｄ Ｒｅｓｏｕｒｃｅ Ａｌｌｏｃａｔｉｏｎ"、著作Ｇ． Ｓｈａｎａｍｕｇａｎａｔｈａｎら、ＡＣＭ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｍｅａｓｕｒｅｍｅｎｔ ａｎｄ Ｍｏｄｅｌｉｎｇ ｏｆ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍｓ （ＳＩＧＭＥＴＲＩＣＳ ２０１３）

一実施形態によれば、仮想化リソース管理エンジンによって、複数の物理及び／又はソフトウェアリソースのうち、ある物理及び／又はソフトウェアリソースに、少なくとも１つの仮想リソースを割り振る方法であって、
上記少なくとも１つの仮想リソースを要求している第１のテナントを識別するために使用される情報を取得するステップと、
上記要求された仮想リソースが、上記第１のテナントとは異なる別のテナントの１つ又は複数の仮想リソースと同じ物理及び／又はソフトウェアリソース上にコロケートされ得るかどうかを指定する、リソース割振り要求のパラメータとしてのアフィニティ情報を取得するステップと、
アフィニティ情報に基づいて少なくとも１つの仮想リソースを割り振るステップと
を含む方法が提供される。

この方法は、物理及びハイパーバイザソフトウェアリソースを事前に計画する必要及び／又はテナント（ベンダー）に事前に割り振る必要なしに、データセンターにおけるリソースが割り振られ得るという効果及び利点を有する。そのような事前割振りがなければ、リソースのプールがテナントの間で統計的に共有されるので、データセンターにおいて必要とされるリソースが少なくなる一方で、同時に、割振りを決定するときに、異なるテナントの仮想機械の配置に対する制約を表すアフィニティ情報が考慮される。したがって、図４に示すように、インフラストラクチャリソース及び資本支出の節約が可能であり、同時に、必要なリソースの量が減ることで運用コストも減る。

上記アフィニティ情報に基づく少なくとも１つの仮想リソースの割振りは、テナントによるリソースの断片化が回避されるという効果及び利点を有する。これは、他のパラメータ又はリソース能力、たとえば、リソースのタイプ（何らかの特定のハードウェアアクセラレーションがいくつかのホストで可能である場合）、リソースの品質、弾力性レベルなどに基づいてそのような断片化を実行するためのさらなる柔軟性をもたらす。

一実施形態では、本方法は、複数の物理及びソフトウェアリソースへの仮想リソースの現在の割振りに関係する情報を取得するための中間ステップを含む。

これは、より動的な方法で実行時に、アフィニティ情報が考慮されて、データセンターにおけるリソースが割り振られ得るという効果及び利点を有する。

一実施形態では、仮想化リソース管理エンジンは、データセンター又はクラウドインフラストラクチャにおける仮想、物理及びソフトウェアリソースの仮想化インフラストラクチャ管理を担当するエンティティの一部である。

これは、仮想化インフラストラクチャの管理者、たとえば、ネットワーク事業者が、データセンターにおける計算、記憶及びネットワークリソースを、配備されるソフトウェアのベンダーによる実装から分離することを可能にするという効果及び利点を有する。特に、アプリケーションソフトウェアの実装は、特定のクラウド環境に配備されているときに、アフィニティ制約を設定及び実施する方法を考慮する必要がない。仮想化インフラストラクチャ管理を担当するエンティティは、たとえば、ＮＦＶアーキテクチャフレームワーク（Ａｒｃｈｉｔｅｃｔｕｒａｌ Ｆｒａｍｅｗｏｒｋ）におけるＶＩＭであり得る。

一実施形態では、第１のテナントを識別するために使用される情報及びアフィニティ情報のシグナリングエンティティは、仮想ネットワーク機能の管理を担当するエンティティである。

これは、仮想ネットワーク機能の管理を担当するエンティティを制御するテナント（ベンダー）が、ＶＮＦの配備／運用のケースごとに、そのようなＶＮＦ及び対応する仮想化リソースが、他のテナントの仮想化リソースとコロケートされるかどうかの点で、どのように配備されるべきかを決定することを可能にするという効果及び利点を有する。仮想ネットワーク機能の管理を担当するエンティティは、たとえば、ＮＦＶアーキテクチャフレームワークにおけるＶＮＦＭであり得る。

一実施形態では、シグナリングは、リソース及び仮想ネットワーク機能の編成を担当するエンティティを通じて転送される。

これは、ベンダー及びネットワーク事業者が、データセンターにおけるトラフィック負荷、自身のＶＮＦの優先度、並びに／又は追加のネットワークサービス及びリソースポリシー制約のような、リソース及び仮想ネットワーク機能の編成を担当するエンティティによって部分的に決定される、異なる状況下で異なるＶＮＦプロビジョニング戦略を持つことを可能にするという効果及び利点を有する。リソース及び仮想ネットワーク機能の編成を担当するエンティティは、たとえば、ＮＦＶアーキテクチャフレームワークにおけるＮＦＶＯであり得る。

一実施形態では、本方法は、第１のテナントを識別するために受信された情報に基づいてアフィニティ情報を発見するための中間ステップを含む。

これは、アフィニティ情報が明示的に指定され送信される必要はないが、第１のテナントの識別情報に基づいて判断されるという点で効果及び利点を有する。これは、シグナリングプロトコルをより効率的にし、そのテナント（ベンダー）以外のエンティティが特定のテナントのアフィニティ情報を判断することを可能にする。

一実施形態では、本方法は、第１のテナントを識別するために受信された情報に基づいてアフィニティ情報を発見するための中間ステップを含み、第１のテナントを識別するために使用される情報のシグナリングエンティティが、仮想ネットワーク機能の管理を担当するエンティティであり、第１のテナントを識別するために使用される情報に基づくアフィニティに関係する情報の発見が、リソース及び仮想ネットワーク機能の編成を担当するエンティティによって実行され、第１のテナントを識別するために使用される情報及びアフィニティに関係する情報のシグナリングが、リソース及び仮想ネットワーク機能の編成を担当するエンティティによって実行される。

この実施形態は、次のようないくつかの効果及び利点を実現する。仮想ネットワーク機能の管理を担当するエンティティを制御するテナント（ベンダー）が、ＶＮＦの配備／運用のケースごとに、そのようなＶＮＦ及び対応する仮想化リソースが、他のテナントの仮想化リソースとコロケートされるかどうかの点で、どのように配備されるべきかを決定することが可能になる。さらにベンダー及びネットワーク事業者が、データセンターにおけるトラフィック負荷、自身のＶＮＦの優先度、並びに／又は追加のネットワークサービス及びリソースポリシー制約のような、異なる状況下で異なるＶＮＦプロビジョニング戦略を持つことができる。最後に、シグナリングプロトコルがより効率的になり得、そのテナント（ベンダー）以外のエンティティが特定のテナントのアフィニティ情報を判断することを可能にする。

一実施形態では、アフィニティに関係する情報は、ポリシーの一部であり、アフィニティ情報は、ポリシーのセットアッププロセスの一部としてシグナリングされる。

これは、仮想ネットワーク機能の管理を担当するエンティティが、そのようなリソース割振りのためにリソース要件及びＶＮＦのタイプ又はクラスのみを指定する必要があるリソース割振り要求を直接発信することができるという効果及び利点を有する。次いで、ＶＩＭは、そのような情報を、ポリシーに含まれる情報とマッピングし、それに応じてリソース割振りを発信する。したがって、シグナリングはより効率的になり得る。

一実施形態では、複数の物理及び／又はソフトウェアリソースのうち、ある物理及び／又はソフトウェアリソースに、上記少なくとも１つの仮想リソースを割り振るプロセスは、管理動作の一部であり、管理動作が、仮想化配備の第１のインスタンス化、又は既存の仮想化配備の仮想化リソースの全面的若しくは部分的なスケールアウト、移動若しくは回復を含むことが好ましい。

これは、割振り方法が他の管理動作においても効果的であるので、管理動作が発生したときに割振り方法の前述の効果及び利益が維持されるという効果及び利点を有する。

一実施形態では、少なくとも１つの仮想リソースは、ハイパーバイザ上で実行される仮想機械（ＶＭ）若しくはオペレーティングシステム上で実行される仮想アプリケーションコンテナ、又は記憶用の仮想ディスクドライブである。

これは、データセンターにおいて一般に利用可能なコンピュータハードウェア及びソフトウェアシステム及びインフラストラクチャに本方法が適用可能であるという効果及び利点を有する。

一実施形態では、仮想リソースの割振りは仮想化配備のために行われ、仮想化配備が仮想ネットワーク機能（ＶＮＦ）である。

これは、電気通信クラウドにおける仮想ネットワーク機能のためにリソースを割り振るために本方法が適用可能であるという効果及び利点を有する。

一実施形態では、アフィニティ情報は、特定のテナントに対するアンチアフィニティ、特定のテナントに対するアフィニティ、計算、記憶若しくはネットワークの負荷が大きい仮想リソースに対するアフィニティのうちの１つ又は複数を含むことが好ましい、異なる割振りケースを対象とする複数の値を取ることができる。

これは、アフィニティ情報がベンダーの一部若しくは全部に対するアフィニティ若しくはアンチアフィニティを表すことができ、又はアフィニティ情報が、いくつかの能力を有する仮想化リソースをコロケートするためにアフィニティ若しくはアンチアフィニティを表すことができるという効果及び利点を有する。

一実施形態によれば、仮想化リソース管理エンジンによって、複数の物理及び／又はソフトウェアリソースのうち、ある物理及び／又はソフトウェアリソースに、少なくとも１つの仮想リソースを割り振るための装置であって、要求された仮想リソースが、第１のテナントとは異なる別のテナントの１つ又は複数の仮想リソースと同じ物理及び／又はソフトウェアリソース上にコロケートされ得るかどうかを指定する、リソース割振り要求のパラメータとしてのアフィニティ情報を取得するためのモジュールと、
アフィニティ情報に基づいて少なくとも１つの仮想リソースを割り振るように設計されたモジュールと、
を備える装置が提供される。

別の実施形態によれば、本装置は、複数の物理及びソフトウェアリソースへの仮想リソースの現在の割振りに関係する情報を取得するためのモジュールをさらに備える。

別の実施形態によれば、本装置は、上記アフィニティ情報に基づいて上記少なくとも１つの仮想リソースを割り振るためのモジュールをさらに備える。

本装置の実施形態によって実現される効果及び利点は、上記で詳細に説明した方法の実施形態の効果及び利点に対応する。

ネットワーク機能仮想化のためのアーキテクチャフレームワーク、特に、ＥＴＳＩ ＮＦＶ Ｅ２Ｅアーキテクチャフレームワークの機能ビルディングブロックによるアーキテクチャの概要を示す図である。 データセンターの概念的スキーマ及び物理クラスタ化問題の一例を示す図である。 テナントアフィニティの使用の一例及びＶＭアフィニティルールとともにテナントアフィニティを使用したときの効果を示す図である。 ＤＲＳクラスタに基づく従来技術によるデータセンターの概念的スキーム及びテナント間アフィニティ値に基づく一実施形態による割振りを伴うデータセンターの概念的スキームを示す図である。 テナント間アフィニティ値が「１」である、テナントアフィニティ情報に基づいて仮想化リソースを割り振るための方法の一実施形態を示す図である。 テナント間アフィニティ値が「０」である、テナントアフィニティ情報に基づいて仮想化リソースを割り振るための方法の一実施形態を示す図である。 テナントアフィニティ情報に基づいて仮想化リソースを割り振るための方法の第１の例示的な実施形態を実行したときの、ＮＦＶアーキテクチャフレームワークの機能ブロック間のシグナリング及び情報フローを示す図である。 テナントアフィニティ情報に基づいて仮想化リソースを割り振るための方法の第２の例示的な実施形態を実行したときの、ＮＦＶアーキテクチャフレームワークの機能ブロック間のシグナリング及び情報フローを示す図である。 テナントアフィニティ情報に基づいて仮想化リソースを割り振るための方法の第３の例示的な実施形態を実行したときの、ＮＦＶアーキテクチャフレームワークの機能ブロック間のシグナリング及び情報フローを示す図である。 テナントアフィニティ情報に基づいて仮想化リソースを割り振るための方法の第４の例示的な実施形態を実行したときの、ＮＦＶアーキテクチャフレームワークの機能ブロック間のシグナリング及び情報フローを示す図である。

最初に、説明で使用するいくつかの用語を、以下の略語リストで定義する。
ＣＭＳ クラウド管理システム
ＤＲＳ 分散型リソーススケジューラ
ＮＦＶ ネットワーク機能仮想化
ＮＦＶＩ ＮＦＶインフラストラクチャ
ＮＦＶＯ ＮＦＶオーケストレータ
ＶＩＭ 仮想インフラストラクチャマネージャ
ＶＮＦ 仮想ネットワーク機能
ＶＮＦＭ ＶＮＦマネージャ

ＮＦＶの仕様は、欧州電気通信標準化機構（ＥＴＳＩ：Ｅｕｒｏｐｅａｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｔａｎｄａｒｄｓ Ｉｎｓｔｉｔｕｔｅ）におけるＩｎｄｕｓｔｒｙ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｇｒｏｕｐ（ＩＳＧ）によって推進されている。ＥＴＳＩ ＮＦＶは、事業者のネットワークの仮想化によってもたらされる新しい機能ブロック及び参照点に焦点を当てたＮＦＶアーキテクチャフレームワークを定義している。ＮＦＶアーキテクチャフレームワークの概要は、図１に示されている。

ＮＦＶアーキテクチャフレームワークは、機能ブロック及びそのような機能ブロッの間の参照点を表している。機能の分割及び宣言された参照点は、マルチベンダエコシステムにおけるＶＮＦ１０１の管理及び編成をサポートする。具体的には、フレームワークは、基礎をなすインフラストラクチャからＶＮＦソフトウェアが確実に分離され得るように、必要な機能分割を行う。このシナリオでは、ＶＮＦベンダー及び実装者が、たとえば、モバイルネットワーク事業者のような、別のエンティティによって管理される可能性が高いインフラストラクチャを使用するときに、実際のテナントになる。このインフラストラクチャは、１つ又は複数のデータセンターに配置された計算、記憶及びネットワークリソースから成る。インフラストラクチャはまた、共有されるようになっており、仮想化技法を使用することによって、いくつかのＶＭが割り振られ、単一の物理サーバ上で実行され得る。

説明全体にわたって、「ベンダー」という用語と「テナント」という用語とは互換的に使用される。

本明細書で開示する技術は、図１に示すＮＦＶアーキテクチャフレームワークの以下の機能ブロックを主に扱う。
・ＮＦＶインフラストラクチャ及びソフトウェアリソースの編成及び管理を担当し、ＮＦＶＩ上でネットワークサービスを実現するＮＦＶオーケストレータ（ＮＦＶＯ）１０２。ネットワークサービスは、１つ又は複数のＶＮＦの集合によって実現される。
・ＶＮＦライフサイクル管理（たとえば、ＶＮＦのインスタンス化、更新、照会、スケーリング、終了）を担当するＶＮＦマネージャ（ＶＮＦＭ）１０３。
・ＮＦＶＩ計算、記憶及びネットワークリソースを制御及び管理する仮想化インフラストラクチャマネージャ（ＶＩＭ）１０４。クラウドベースのＮＦＶＩの場合、ＶＩＭは、クラウド管理システム（ＣＭＳ）として実装され得る。
・仮想化リソースが割り振られる計算、記憶及びネットワークリソースのセットを備えるＮＦＶインフラストラクチャ（ＮＦＶＩ）１０５。

ＮＦＶＯが大域リソース割振りを行う一方で、ＶＮＦＭは、ＶＩＭ（たとえば、ＣＭＳ）と直接対話して、ＶＮＦの配備及び管理の一部として仮想化リソースの管理を要求することができる。そのような対話に関する一例は、配備されたＶＮＦのための容量拡大であり、この拡大は、ＶＮＦに次に追加される追加のＶＭをＶＮＦＭがＣＭＳに要求することから成り得る。

本開示の教示は、ＮＦＶアーキテクチャフレームワークの文脈における以下の問題に取り組む。特定のリソース要件をそれぞれ有する異なるベンダーからＶＮＦが来るマルチベンダーＶＮＦシナリオを仮定すると、リソースの物理クラスタ化が回避され得ることで、異なるベンダーの間でリソースを共有することによる統計的利得の改善を保証することを、どのようにして確実にできるかについて述べる。
以下では、本発明の実施形態について説明する。

本明細書で開示する技術は、テナント／ベンダー情報に基づいて明示的なアフィニティルールを宣言することに基づく。そのような情報を宣言することによって、仮想化リソースマネージャエンジン（クラウド管理システムの一部、又はＶＩＭの一部）は、データセンターにおける物理及びソフトウェアリソースの区分を事前に計画する必要なく、仮想化配備（たとえば、ＶＮＦ）の一部として仮想化リソース（たとえば、ＶＭ）を割り振ることができる。

この解決策は、以下に焦点を当てる。
・ＮＦＶアーキテクチャフレームワークの機能ブロックを伴うインターフェース上のテナントアフィニティに関するパラメータ。
・テナントアフィニティ情報に基づくリソース割振りのための方法。

請求項ではアフィニティ情報と呼ばれるテナントアフィニティパラメータは、テナント（ベンダー）によって要求された仮想化リソースが、他のテナント（ベンダー）からの他の仮想化リソースと同じ物理及び／又はソフトウェアリソース上にコロケートされ得るかどうかの情報を与える。テナントアフィニティは、最新技術で知られている他のアフィニティパラメータ、たとえば、ＶＭｗａｒｅのＤＲＳによって提供されるような背景セクションで説明したものとは異なるパラメータである。図３は、一実施形態によるテナントアフィニティパラメータと、テナントアフィニティ情報の使用が、最新技術で使用されるＶＭアフィニティ情報（すなわち、上記で定義したＶＭ間アフィニティ）と相補関係にある様子とを説明し示している。このＶＭアフィニティ情報は、サーバではなく、選択されたＶＭの間のアフィニティのみを指す。ここで、ＶＭアフィニティ＝０は、新しい選択されたＶＭを同じサーバ上に割り振ることができないことを意味し、ＶＭアフィニティ＝１は、選択されたＶＭを同じサーバ上に割り振らなければならないことを意味する。この例では、テナント「Ｃ」の仮想リソース（ＶＭ）Ｃ３及びＣ４は、ＶＭアフィニティ＝０を有する選択されたＶＭであり、「ＶＭアフィニティ＝０」情報を利用する間にサーバ１及び２に割り振られている（ケース３０１）。したがって、Ｃ３及びＣ４は、異なるサーバ（サーバ１及びサーバ２）に割り振られている。ただし、「テナントアフィニティ＝１」情報がさらに考慮されるときには、これは、テナントの新しいＶＭの各々が、このテナントのＶＭのみが割り振られているサーバ又はＶＭがまだ割り振られていないサーバに割り振られなければならないことを意味する。したがって、図３の右手側に示すように、割振りがサーバ２及び３に対して実行され（ケース３０２）、これらのサーバは、同じテナントＣによってのみ使用される（サーバ２を指す）か、又はまったく使用されておらず、したがって完全に利用可能である（サーバ３を指す）。

図３は、２つの選択されたＶＭのみを有する一例を示しているが、割り振られるべき３つ以上の選択されたＶＭにも同じ原理を適用できることを、当業者は理解されよう。

図４は、従来技術（ＤＲＳクラスタに基づく）と本開示による技術とを比較している。図の左手側は、上述の「物理クラスタ化」手法を示している。右手側は、テナントアフィニティパラメータを使用する一例を示している。この場合、「１」のアフィニティ値は、リソースをテナント間で共有できず、したがって、この値を有する仮想化リソースが、同じテナントからの他の仮想化リソースとのみサーバを共有できることを意味する。さらに、「０」のアフィニティ値を有する仮想化リソースも存在し、この値は、他のテナントからの仮想化リソースとサーバを共有できることを意味する。

この基本的な考えを使用するいくつかの実施形態が可能であり、それらのいくつかについて、以下で詳述する。

本明細書で説明し、請求項で指定するこの技術は、以下の利点を有する。
・物理及びソフトウェアリソースを事前に計画する必要及びテナント（ベンダー）に事前に割り振る必要なしに、より動的な方法で実行時にデータセンターにおけるリソースを割り振ることを可能にする。リソースのプールがテナントの間で統計的に共有されるので、データセンターにおいて必要とされるリソースが少なくなる。したがって、図４に示すように、リソース及び資本支出の節約が可能であり、このことは、同時に、必要なリソースの量が減ることで運用コストを減らすことができることを意味する。
・テナントによるリソースの断片化を回避する。これは、他のパラメータ又はリソース能力、たとえば、リソースのタイプ（何らかの特定のハードウェアアクセラレーションがいくつかのホストで可能である場合）、リソースの品質、弾力性レベルなどに基づいてそのような断片化を実行するためのさらなる柔軟性をもたらす。
・仮想化インフラストラクチャの管理者（この場合、ネットワーク事業者）が、データセンターにおける計算、記憶及びネットワークリソースを、ＶＮＦソフトウェアのベンダーによる実装から分離することを可能にする。
・テナント（ベンダー）が、ＶＮＦの配備／運用のケースごとに、そのようなＶＮＦ及び対応する仮想化リソースが、他のテナントの仮想化リソースとコロケートされるかどうかの点で、どのように配備されるべきかを決定することを可能にする。これは、ベンダーが、データセンターにおけるトラフィック負荷、自身のＶＮＦの優先度、並びに／又は追加のネットワークサービス及びリソースポリシー制約のような、異なる状況下で異なるＶＮＦプロビジョニング戦略を持つことを可能にする。

以下では、テナントアフィニティ情報に基づいて仮想化リソースを割り振るための方法について説明する。

図５は、テナント間アフィニティ値が「１」である一例を示している。これは、ＶＭを他のテナントからのＶＭとコロケートできないことを意味する。

図６は、テナント間アフィニティ値が「０」である一例を示している。そのような例では、要求は、ＶＭを割り振り、他のテナントからのＶＭとコロケートすることができるよう求めるものである。

図５及び図６に示す方法は、以下の４つの主要なステップを含む。

１．ステップ１（Ｓ５０１）：１つ又は複数の仮想化リソース（簡単にするために、そのようなリソースが仮想機械、ＶＭであると想定される）を割り振るよう求める要求が実行される。そのような要求は、そのような要求を発信しているテナントを識別する情報（パラメータ）と、仮想化リソースごとのテナントアフィニティ値とを含む。

２．ステップ２（Ｓ５０２）：仮想化リソース管理エンジン５１１が、ステップ１の要求からの入力情報を収集する。さらに、データセンターにおける共有物理及びソフトウェアリソースのプール上の仮想化リソースの現在の配置に関する（記憶されたか、又は別のエンティティから取り出された）追加の情報を収集することができる。この追加情報は、（「サーバｉｄ」パラメータ５２１によって識別される）識別された物理ホストごとに、図５及び図６の例とともに示す表における少なくとも以下の情報要素を含む。
ａ．使用アフィニティ５２２（現在のホスト／サーバがどのように使用されるか）：これは、ステップ１でシグナリングされたテナントアフィニティパラメータに対応するが、ここでは、現在の物理ホストを他のテナントと共有できる（使用アフィニティ「０」）か、それとも当該テナント専用である（使用アフィニティ「１」）かを識別する。
ｂ．そのようなリソースを使用する１つ又は複数のテナント（使用テナントｉｄ５２３）、及び
ｃ．仮想化リソース（たとえば、ＶＭ）の識別子（ｖｍ−ｉｄ５２４）：この物理ホスト上でインスタンス化された仮想機械のリスト。

３．ステップ３（Ｓ５０３）：仮想化リソース管理エンジンは、そのリソース及びテナントアフィニティ要件を使用する物理ホスト（サーバ）を発見する。

４．ステップ４（Ｓ５０４）：仮想化リソース管理エンジンは、データセンター（クラウドインフラストラクチャ）５１２における仮想化リソース（たとえば、ＶＭ）を割り振るための、選択されたサーバ／ホストのためのハイパーバイザ又は仮想機械マネージャ向けの割振り要求を発信する。

いくつかの実施形態は、テナントアフィニティ情報とともに要求を発信し処理する者に基づいて、またそのような情報が処理される方法に基づいて、たとえば、
・インターフェース上の実際のリソース要求に基づいて、又は
・リソースの実際の予約にリソース要求をマッピングすることによって（注：この場合、予約は論理的であり、たとえば、ｖＣＰＵの数、仮想メモリなど、つまり、物理ホストの予約ではなく割当量の点でより大きいものである）、又は
・ポリシーをセットアップし使用することによって
可能である。

図７〜図１０は、それぞれ実施形態１〜実施形態４として以下で説明する、テナントアフィニティ情報に基づいて仮想化リソースを割り振るための方法の例示的な実施形態を実行したときの、ＮＦＶアーキテクチャフレームワークの機能ブロック間の例示的な情報フローを示している。

実施形態Ａ〜実施形態Ｄと呼ばれる他の可能な実施形態は、仮想化配備（たとえば、ＶＮＦ）をスケールアウトするなどのリソース管理動作中、又は仮想化リソースの部分的若しくは全面的移動中、又は仮想化配備の部分的若しくは全面的回復中に本発明を利用することを含む。また、テナントアフィニティパラメータは、今まで例として使用されてきた「０」及び「１」の２進値のうちの１つを保持するだけではなく、３つ以上の値を有するセットからの値も保持するように拡張され得る。これらの実施形態はすべて、以下のセクションで要約し説明する。

実施形態１〜４の第１のセットは、リソース割振り要求手順中の本発明の使用を対象とする。

実施形態１は、上記の文章を通じて例として使用されてきた主要な基本的実施形態である。ここで、リソース割振り要求は、（特定のリソース要件、及び場合によっては予約情報のような）既存のパラメータに加えて、本開示で提示されるようなテナントの識別（テナントｉｄ）及び要求された仮想化リソースごとのテナントアフィニティを含む。この場合、ステップＳ７０１のように、リソース要求はＶＮＦＭによって行われ、ＶＩＭに対して発信される。テナントアフィニティのマッピング及びリソースの選択中におけるそのような要件の処理が、ＶＩＭによって実現される。実施形態１による一連のステップ及び機能ブロック間のシグナリングは、図７に示されている。

実施形態２は、同じく割振り要求の一部としてのテナントアフィニティ及びテナントｉｄのシグナリングを目的とする別の実施形態であるが、この場合には、実施形態１で概説したようにＶＮＦＭとＶＩＭとの間で直接的に行われる代わりに、（ステップＳ８０１及びＳ８０２に示すように）ＮＦＶＯを通じて間接的に行われる。テナントアフィニティ情報は依然としてＶＮＦＭによってシグナリングされる。このプロセス中、ＮＦＶＯは、ＶＮＦＭによるリソース要求を特定の予約にマッピングすることもできる。実施形態２による一連のステップ及び機能ブロック間のシグナリングは、図８に示されている。

実施形態３は、すべての情報がＶＮＦＭからシグナリングされる必要があるとは限らないという点で、実施形態２とは異なる。情報の一部はむしろ、ＶＮＦＭからのリソース要求からのテナントｉｄをマッピングするＮＦＶＯによって導出される。ここでのＮＦＶＯは、テナントアフィニティ情報を導出することを可能にする内部情報を維持する。ＮＦＶＯは、ＶＮＦＭによるリソース要求を特定の予約にマッピングすることもできる。次いで、ＮＦＶＯは、実施形態２と同様に（ステップＳ９０２のように）ＶＩＭへのリソース割振り要求のシグナリングに進むことができる。実施形態３による一連のステップ及び機能ブロック間のシグナリングは、図９に示されている。

実施形態４：この場合、テナントアフィニティ情報のシグナリングは、ポリシー作成プロセスの一部である。図１０に示すこの例示的な場合、ＮＦＶＯは、「ポリシー作成」の発信側であり、ＶＩＭは、そのようなポリシーを維持するエンティティである。そのようなポリシー作成要求（ステップＳ１００１）は、そのようなアフィニティ配置要件に従うべきテナントからのテナント識別子（テナントｉｄ）、テナントアフィニティパラメータ、及びＶＮＦのクラス又はクラスのリスト（［ｖｎｆクラス］）に関する情報を含む。パラメータ表記は、値のうちの１つ又は値のリストが指定され得ることを示すために角括弧“［“ ”］”を使用する。ＶＩＭは、割振り決定を行うために後に使用できるそのような情報を記憶する。ポリシーが作成されると、別の第３の要素、たとえば、ＶＮＦＭが、そのようなリソース割振りのためにリソース要件及びＶＮＦのタイプ又はクラス（ｖｎｆクラス）のみを指定する必要があるリソース割振り要求（ステップＳ１００３）を直接発信することができる。次いで、ＶＩＭは、そのような情報を、ポリシーに含まれる情報とマッピングし、それに応じてリソース割振りを決定する。

実施形態の第２のセットは、ＶＮＦの容量をスケーリングすること、又はＶＮＦの仮想機械をある物理ホストから、そのようなテナントアフィニティが使用され得る別の物理ホストに部分的若しくは全面的に移動すること、又はＶＮＦを部分的若しくは全面的に回復することのような、異なるタイプのリソース動作に関係する。したがって、これらの実施形態は、実施形態の第１のセットに直交する。第１のセットは、ＮＦＶアーキテクチャフレームワーク内の異なる機能ブロックを通じてテナントアフィニティ関連情報が渡されるのをサポートするためのシグナリング手順を実装する異なる方法について説明しており、第２のセットは、サポートされ得る仮想化リソース上の異なる動作について説明している。したがって、実施形態の両方のセットからの実施形態の特徴は結合され得る。

実施形態Ａは、ＶＮＦ（仮想化配備）の新しいインスタンス化プロセス中に実際の仮想化リソース割振り要求の一部としてテナントアフィニティ情報を使用する。これは、これまで本明細書において使用してきた例である。

実施形態Ｂでは、ＶＮＦが、たとえば、さらなる仮想機械をこのＶＮＦに追加することによってスケールアウトされるべきであると想定される。したがって、このスケールアウト手順も新しいリソースの割振りを必要とし、そのようなリソースの適切なインスタンス化を確実にするためにテナントアフィニティ情報が使用される。そのような場合、そのようなＶＮＦ、又は既存のものの拡張、たとえば、既存の仮想化リソース（ＶＭ）へのさらなるｖＣＰＵ若しくは仮想メモリの割振りの一部として、新しい仮想化リソースが要求され得る。ＶＮＦの容量が減らされるスケールイン手順もテナントアフィニティ情報を必要とする可能性があることに留意されたい。例として、どのＶＭを最初に除去すべきかをＶＩＭが決定したい場合、又はスケールイン後のリソース統合の後のＶＭが移動すべきである場合（以下の実施形態Ｃで説明する）がある。

実施形態Ｃは、移動シナリオ、つまり、ＶＮＦ全体又はＶＮＦの一部がデータセンター内又はデータセンター間で異なるサーバに移動すべきであることを想定している。これは、データセンターにおいて一般に使用される標準的な仮想機械移動技術により実現可能である。ここで、テナントアフィニティ情報は、どのサーバにＶＮＦのＶＭを移動できるか又はできないかを判断するために使用される。

実施形態Ｄは、ＶＮＦ全体又はＶＮＦの一部に関する、ＶＮＦの仮想化リソース回復（障害回復）を対象とする。ここでの例は、新しいサーバに再配備される必要があるＶＮＦのいくつかのＶＭの障害である。この場合にはまた、テナントアフィニティ情報は、そのような再配備に適した候補サーバを判断するために使用される。

最後に、実施形態Ｉ〜ＩＩＩの第３のセットでは、テナントアフィニティパラメータの可能な値は、可変的である。値は、今まで説明したように２進数であるか、又は既定の値セットからの異なる値を取る。

実施形態Ｉでは、テナントアフィニティパラメータは、仮想化リソースが他のテナントからの仮想化リソースとコロケートできるかどうかを決定する２進値である。パラメータが「０」に等しい場合、仮想化リソースは、他のテナントからの他の仮想化リソースと、データセンターにおける共有物理及びソフトウェアリソース上にコロケートでき、このパラメータが「１」に等しい場合、仮想化リソースは、他のテナントからの仮想化リソースとコロケートできない。これは、上記の文章で説明してきた実施形態である。

実施形態ＩＩでは、テナントアフィニティパラメータは、値セットからの値を取ることができ、異なる値が、テナント（ベンダー）の一部又は全部に対するアフィニティ又はアンチアフィニティへの情報を示す。たとえば、
・テナントアフィニティ＝Ａ：グループＡの任意のテナント（ベンダー）に対するアフィニティ。
・テナントアフィニティ＝Ｂ：テナントｉｄ＝Ｘとは異なる任意のテナント（ベンダー）に対するアフィニティ。
・テナントアフィニティ＝Ｃ：テナントｉｄ＝Ｙに対してではなくテナントｉｄ＝Ｚに対するアフィニティ。
・その他。

実施形態ＩＩＩでは、テナントアフィニティパラメータは、３つ以上の値を有する値セットからの値を取ることができ、異なる値が、いくつかの能力を有するコロケートされた仮想化リソースに対するアフィニティ又はアンチアフィニティへの情報を示す。たとえば、
・テナントアフィニティ＝Ｍ：他のテナントからの計算負荷が大きいＶＭに対するアンチアフィニティ。
・テナントアフィニティ＝Ｎ：他のテナントからの入出力データの多いＶＭに対するアンチアフィニティ。
・その他。

本発明の実施形態に関して説明した方法、要素、ユニット及び装置は、ハードウェアにおいて、ソフトウェアにおいて、又はその両方の組合せとして実装され得ることが、当業者には直ちに明らかになろう。特に、本発明の実施形態及び本発明の実施形態に関して説明したモジュールの要素が、コンピュータ上で実行されているか、又はマイクロプロセッサによって実行されている１つ又は複数のコンピュータプログラムによって実装され得ることが理解されよう。本発明を実装する任意の装置は、特に、ネットワークエンティティとして動作するコンピューティングデバイスの形態をとることができる。

Claims (14)

1. 仮想化リソース管理エンジン（５１１）によって、複数の物理及び／又はソフトウェアリソース（１０５）のうち、ある物理及び／又はソフトウェアリソースに、少なくとも１つの仮想リソースを割り振る方法であって、
   前記少なくとも１つの仮想リソースを要求している第１のテナントを識別するために使用される情報を取得するステップと、
   前記要求された仮想リソースが、前記第１のテナントとは異なる別のテナントの１つ又は複数の仮想リソースと同じ物理及び／又はソフトウェアリソース上にコロケートされ得るかどうかを指定する、リソース割振り要求のパラメータとしてのアフィニティ情報を取得するステップと、
   前記アフィニティ情報に基づいて前記少なくとも１つの仮想リソースを割り振るステップと、
   を含む方法。
2. 前記複数の物理及びソフトウェアリソースへの仮想リソースの現在の割振りに関係する情報を取得するためのステップ、
   を含む、請求項１に記載の方法。
3. 前記仮想化リソース管理エンジンが、データセンター又はクラウドインフラストラクチャ（５１２）における仮想、物理及びソフトウェアリソースの仮想化インフラストラクチャ管理を担当するエンティティ（１０４）の一部である、請求項１又は２に記載の方法。
4. 前記第１のテナントを識別するために使用される情報及び前記アフィニティ情報のシグナリングエンティティが、仮想ネットワーク機能の管理を担当するエンティティ（１０３）である、請求項１〜３のいずれか一項に記載の方法。
5. シグナリングが、リソース及び仮想ネットワーク機能の編成を担当するエンティティ（１０２）を通じて転送される、請求項１〜４のいずれか一項に記載の方法。
6. 前記第１のテナントを識別するために受信された情報に基づいて前記アフィニティ情報を発見するための中間ステップ、
   を含む、請求項１〜５のいずれか一項に記載の方法。
7. 前記第１のテナントを識別するために使用される情報のシグナリングエンティティが、仮想ネットワーク機能の管理を担当するエンティティであり、
   前記第１のテナントを識別するために使用される情報に基づく前記アフィニティ情報の発見が、リソース及び仮想ネットワーク機能の編成を担当するエンティティによって実行され、
   前記第１のテナントを識別するために使用される情報及び前記アフィニティ情報のシグナリングが、リソース及び仮想ネットワーク機能の編成を担当するエンティティによって実行される、請求項６に記載の方法。
8. 前記アフィニティ情報が、ポリシーの一部であり、前記アフィニティ情報が、前記ポリシーのセットアッププロセスの一部としてシグナリングされる、請求項１〜７のいずれか一項に記載の方法。
9. 前記複数の物理及び／又はソフトウェアリソースのうち、ある物理及び／又はソフトウェアリソースに、前記少なくとも１つの仮想リソースを割り振るプロセスが、管理動作の一部であり、
   前記管理動作は、
   仮想化配備の第１のインスタンス化、又は、
   既存の仮想化配備の仮想化リソースの全面的若しくは部分的なスケールアウト、移動、若しくは、回復、
   を含む、請求項１〜８のいずれか一項に記載の方法。
10. 前記少なくとも１つの仮想リソースが、
    ハイパーバイザ上で実行される仮想機械、
    オペレーティングシステム上で実行される仮想アプリケーションコンテナ、又は、
    記憶用の仮想ディスクドライブである、
    請求項１〜９のいずれか一項に記載の方法。
11. 仮想リソースの割振りが仮想化配備のために行われ、前記仮想化配備が仮想ネットワーク機能である、請求項１〜１０のいずれか一項に記載の方法。
12. 前記アフィニティ情報が、異なる割振りケースを対象とする複数の値を取ることができ、前記割振りケースは、特定のテナントに対するアンチアフィニティ、特定のテナントに対するアフィニティ、計算、記憶若しくはネットワークの負荷が大きい仮想リソースに対するアフィニティ、
    のうちの１つ又は複数を含む、
    請求項１〜１１のいずれか一項に記載の方法。
13. 仮想化リソース管理エンジン（５１１）によって、複数の物理及び／又はソフトウェアリソース（１０５）のうち、ある物理及び／又はソフトウェアリソースに、少なくとも１つの仮想リソースを割り振るための装置であって、
    前記少なくとも１つの仮想リソースを要求している第１のテナントを識別するために使用される情報を取得するためのモジュールと、
    前記要求された仮想リソースが、前記第１のテナントとは異なる別のテナントの１つ又は複数の仮想リソースと同じ物理及び／又はソフトウェアリソース上にコロケートされ得るかどうかを指定する、リソース割振り要求のパラメータとしてのアフィニティ情報を取得するためのモジュールと、
    前記アフィニティ情報に基づいて前記少なくとも１つの仮想リソースを割り振るように設計されたモジュールと、
    を備える装置。
14. コンピュータ上で実行されたときに、前記コンピュータに、請求項１〜１２のいずれか一項に記載の方法を実行させることを可能にするコンピュータプログラムコードを備えるコンピュータプログラム。