JP6435050B2 - Resource management in cloud systems - Google Patents

Description

  The present technology relates to a method and apparatus for allocating at least one virtual resource to a certain physical and / or software resource among a plurality of physical and / or software resources. In particular, the present technology relates to tenant affinity for resource management in a telecommunications cloud system.

  Network function virtualization (NFV) is a technique for providing a communication service. NFV uses virtualization and automation techniques from IT to move current network functions (eg, firewalls, DPIs, serving gateways,...) In an operator's network from dedicated hardware to a general-purpose IT infrastructure. Apply. These modified network functions are known as “virtual network functions” (VNFs). A VNF can consist of one or more virtual machines (VMs) and a virtual network, which together provide a network function. These VMs and virtual networks are generally referred to as virtualized resources in the present invention.

One of the problems addressed by the present invention is the waste of resources in the data center due to physical clustering of resources. “Physical clustering” in this context means that a predetermined set of computing and storage resources is exclusively assigned to application software from a particular vendor (also referred to herein as “tenant”). Therefore, application software from another vendor cannot use these resources even when not in use. There are two main reasons for such “physical clustering”.
A. Security: Vendors (tenants) use their VMs to be collocated on shared physical or hypervisor software resources with other VMs from other vendors (tenants), for example using a hypervisor or VM bug. This may not be desirable for security reasons due to the possibility of intercepting traffic from VMs from competing vendors.
B. Performance: Vendors (tenants) want to ensure that the performance of their VNFs (and hence the underlying VMs) is predictable, so a VM malfunction from a second vendor is May affect VMs from the first vendor. It is also easy for vendors to track and analyze the reason for failure when their VM faces a failure.

“Physical clustering” can lead to two main problems.
1. Data center resource waste: Pre-provisioning of resource clusters can lead to resource waste, especially if the pre-provisioning is done in an inappropriate manner that later does not meet the tenant's actual requirements. Specifically, the actual use of resources in such a cluster of resources may change dynamically due to various factors such as traffic load, failures, and the like.
2. Stronger reliance on vendor / tenant requirements: Physical clustering of resources in the data center still ties VNF software acquisition to infrastructure hardware. Such behavior is largely contrary to one of the original motivations for introducing virtualization aimed at extracting such resources from application software running on physical / hardware resources.

  Throughout this disclosure, the term “software” refers to one of the following: First, software that is part of the system infrastructure that may be shared by different tenants, eg software in the form of hypervisor software, second, application or service functionality, specifically network functionality Software provided by the tenant to run. An explicit reference to “hypervisor software”, “application software”, or “VNF software” is used to distinguish the two distinct uses of the term when necessary and not otherwise apparent from the context. Done.

  FIG. 2 shows an example of the physical clustering problem outlined above. Four different clusters are created and assigned to each vendor (tenant), ie TA, TB, TC and TD. This figure also shows how VMs are allocated to several physical hosts (servers) and how physical clustering can lead to waste of resources within each cluster, depending on traffic load etc. Is shown. Basically, the pool of resources in the data center that may have been shared is now fragmented into different clusters, preventing allocation of resources to vendors / tenants other than the cluster owner / user. ing.

In the area of data cluster resource clustering, there are several existing technologies that attempt to address the above problems. One approach is VMware's VSphere 5.5, which is online (http://pubs.vmware.com/vsphere-55/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server- 55-resource-management-guide.pdf), described in “vSphere ESXi Vserver server resource management guide”. With VSphere, several types of affinity can be defined:
CPU affinity: CPU affinity is used to constrain the allocation of VMs to a subset of available processors in a multiprocessor system, ie, it specifies constraints on the placement of VMs on a processor.
VM affinity: Inter-VM affinity rules are used to specify affinity (or anti-affinity) between individual VMs, ie whether selected individual VMs should be run on the same host or Specifies whether to be maintained on a separate physical host (server).
VM Host Affinity: The VM Host Affinity Rule specifies whether the elements of the selected VM Distributed Resource Scheduler (DRS) group can be executed on the elements of the specified Host DRS Group. The VM host affinity rule includes the following components. a) one VM DRS group, b) one host DRS group, and c) whether the rule is mandatory or recommended, and whether the rule represents affinity (executed) , Or whether to represent anti-affinity (not executed).

The last type of affinity (ie, VM host affinity) is used to partition resources in the data center and create a resource cluster such as that shown in FIG. These clusters of a particular physical host (host DRS group) can then be assigned to a tenant (VM DRS group). However, such creation is done off-line (pre-planned) in advance and receives a VM allocation request, that is, the allocation is already specified in advance. Therefore, it does not solve the problem of resource waste. The data center schema in FIG. 2 and other figures specifies four virtual machines (VMs) for each physical server. This configuration has been selected for explanation and may vary in actual embodiments, i.e. there may be one or more virtual machines per physical server. In addition to the shortcomings of resource cluster pre-planning and allocation outlined above, the specification and maintenance of affinity rules is very complex, especially in data center configurations with a large number of tenants with diverse workloads with different requirements. Can be labor intensive.
A similar approach based on declaring affinity groups and allocating data items and computational resources based on such affinity groups is described by Peirart et al. In US Pat. No. 8,578,789 B2. The basic idea of this approach is that computational resources can be associated with affinity groups, and such affinity groups can be associated with geographic regions or several data centers. Data items and computational resources can be associated with affinity groups and then allocated based on such associated affinity groups. This solution is very similar to what VMware supports through its DRS cluster.

  Another approach is presented by Ferris et al. In US Pat. No. 8,402,139 B2, where a matching system, which can be a cloud management system, collects information about available cloud devices that can be physical hosts or servers in a data center, These devices are matched with the service requested by the user. Such requested services are applications deployed on several VMs. Since the matching system can also track and manage resources, the user can have certain rights and the allocated resources are made available to the user. However, US Pat. No. 8,402,139 B2 does not solve the problem of allocating resources based on the required affinity expressed compared to other tenant requests.

  Another approach is described in “Defragmenting the Cloud Usage Demand-Gothed-Residence Resource.” In ACM International Conference on Measurement and Modeling of Computer Systems (SIGMETRICS 2013) As described by Shanamuganathan et al. The author proposes two algorithms that dynamically allocate a large amount of resources purchased by customers between their VMs based on individual demands and other tenant-specified controls such as reservations, limits and priorities. ing. The proposed distributed binary search (DBS) algorithm is consistent with the centralized VMware DRS resource manager algorithm, but is functioning in a distributed environment. Another proposed algorithm, Base + Proportional Exceed (BPX), is completely asynchronous. The main difference in this solution is that it allows defragmentation of cloud / data center resources related to the technology disclosed herein, in which case the allocation is a VM represented by the VM load and customer demand. Based on load priority. Therefore, this solution does not consider explicit inter-tenant affinity information.

  When resources are allocated based on affinity groups, all of the above approaches require that resource groups be allocated in a pre-planned manner.

U.S. Pat. No. 8,402,139 B2

“VSphere ESXi Vcenter server resource management guide”, http://pubs.vmware.com/vsphere-55/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-55-resource-management-guide. pdf “Defragmenting the Cloud Using Demand-based Resource Allocation”, work G.R. Shanamuganathan et al., ACM International Conference on Measurement and Modeling of Computer Systems (SIGMETRICS 2013)

According to one embodiment, a method of allocating at least one virtual resource to a certain physical and / or software resource among a plurality of physical and / or software resources by a virtual resource management engine, comprising:
Obtaining information used to identify a first tenant requesting the at least one virtual resource;
A resource allocation request that specifies whether the requested virtual resource can be co-located on the same physical and / or software resource as one or more virtual resources of another tenant different from the first tenant Obtaining affinity information as a parameter;
Allocating at least one virtual resource based on the affinity information.

  This method has the advantage and advantage that resources in the data center can be allocated without having to plan physical and hypervisor software resources in advance and / or without having to pre-allocate to tenants (vendors). Without such pre-allocation, the resource pool is statistically shared among tenants, so fewer resources are required in the data center, while at the same time, when determining allocations, different tenants Affinity information representing constraints on the placement of virtual machines is considered. Therefore, as shown in FIG. 4, it is possible to save infrastructure resources and capital expenditure, and at the same time, the operation cost is reduced by reducing the amount of necessary resources.

  Allocation of at least one virtual resource based on the affinity information has the effect and advantage that resource fragmentation by the tenant is avoided. This may be based on other parameters or resource capabilities, such as resource type (if any specific hardware acceleration is possible on some hosts), resource quality, elasticity level, etc. Provides more flexibility to implement.

  In one embodiment, the method includes an intermediate step for obtaining information related to the current allocation of virtual resources to a plurality of physical and software resources.

  This has the advantage and advantage that at run time in a more dynamic manner, affinity information can be considered and resources in the data center can be allocated.

  In one embodiment, the virtualization resource management engine is part of an entity responsible for virtual infrastructure management of virtual, physical and software resources in a data center or cloud infrastructure.

  This has the benefit and advantage of enabling virtualization infrastructure administrators, eg, network operators, to separate the computing, storage and network resources in the data center from the implementation by the vendor of the deployed software. Have. In particular, application software implementations do not need to consider how to set and enforce affinity constraints when deployed in a specific cloud environment. The entity responsible for virtual infrastructure management can be, for example, a VIM in the NFV Architecture Framework.

  In one embodiment, the information and affinity information signaling entity used to identify the first tenant is the entity responsible for managing the virtual network functions.

  This is because a tenant (vendor) that controls an entity in charge of management of a virtual network function, for each VNF deployment / operation case, such a VNF and a corresponding virtualization resource are the virtualization resources of other tenants. And has the effect and advantage of making it possible to determine how it should be deployed in terms of whether it is collocated. The entity responsible for managing the virtual network function may be, for example, a VNFM in the NFV architecture framework.

  In one embodiment, signaling is forwarded through an entity responsible for organizing resources and virtual network functions.

  This is due to the entity responsible for the organization of resources and virtual network functions, such as the traffic load in the data center, the priority of their VNFs, and / or additional network services and resource policy constraints. Partly determined, has the effect and advantage of allowing having different VNF provisioning strategies under different circumstances. The entity responsible for organizing resources and virtual network functions may be, for example, an NFVO in the NFV architecture framework.

  In one embodiment, the method includes an intermediate step for finding affinity information based on the information received to identify the first tenant.

  This has the advantage and advantage in that the affinity information need not be explicitly specified and transmitted, but is determined based on the identification information of the first tenant. This makes the signaling protocol more efficient and allows entities other than that tenant (vendor) to determine a particular tenant's affinity information.

  In one embodiment, the method includes an intermediate step for discovering affinity information based on information received to identify the first tenant, and the information used to identify the first tenant. The signaling entity is responsible for managing the virtual network functions, and the discovery of information related to affinity based on the information used to identify the first tenant is responsible for organizing resources and virtual network functions Signaling of information related to affinity and information used to identify the first tenant and performed by the entity responsible for organizing the resources and virtual network functions.

  This embodiment realizes several effects and advantages as follows. For each VNF deployment / operation case, a tenant (vendor) that controls an entity responsible for managing virtual network functions, such VNFs and corresponding virtualization resources are collocated with virtualization resources of other tenants. In terms of whether or not it should be deployed. In addition, vendors and network operators can have different VNF provisioning strategies under different circumstances, such as traffic load in the data center, their VNF priority, and / or additional network service and resource policy constraints. Finally, the signaling protocol can be more efficient, allowing entities other than that tenant (vendor) to determine a particular tenant's affinity information.

  In one embodiment, the information related to affinity is part of the policy, and the affinity information is signaled as part of the policy setup process.

  This has the effect that the entity responsible for managing the virtual network function can directly issue a resource allocation request that only needs to specify the resource requirements and the VNF type or class for such resource allocation, and Have advantages. The VIM then maps such information with the information contained in the policy and sends a resource allocation accordingly. Thus, signaling can be more efficient.

  In one embodiment, the process of allocating the at least one virtual resource to a certain physical and / or software resource among a plurality of physical and / or software resources is part of the management operation, and the management operation is virtualized. It preferably includes a first instantiation of the deployment, or a full or partial scale-out, migration or recovery of the virtualization resources of an existing virtualized deployment.

  This has the advantage and advantage that the aforementioned effects and benefits of the allocation method are maintained when the management operation occurs, since the allocation method is also effective in other management operations.

  In one embodiment, the at least one virtual resource is a virtual machine (VM) running on a hypervisor or a virtual application container running on an operating system, or a virtual disk drive for storage.

  This has the advantage and advantage that the method is applicable to computer hardware and software systems and infrastructure generally available in the data center.

  In one embodiment, the allocation of virtual resources is performed for virtualized deployment, where the virtualized deployment is a virtual network function (VNF).

  This has the advantage and advantage that the method can be applied to allocate resources for virtual network functions in a telecommunications cloud.

  In one embodiment, the affinity information preferably includes one or more of anti-affinity for a specific tenant, affinity for a specific tenant, affinities for virtual resources that are computationally intensive, storage or network intensive, and different allocations. Multiple values can be taken for the case.

  This is because the affinity information can represent affinity or anti-affinity for some or all of the vendors, or the affinity information can represent affinity or anti-affinity to colocate a virtualized resource with several capabilities. It has the effect and advantage of being able to.

According to one embodiment, an apparatus for allocating at least one virtual resource to a certain physical and / or software resource among a plurality of physical and / or software resources by a virtualized resource management engine, which is required. A resource allocation request parameter that specifies whether the virtual resource can be co-located on the same physical and / or software resource as one or more virtual resources of another tenant different from the first tenant A module for obtaining information,
A module designed to allocate at least one virtual resource based on affinity information;
An apparatus comprising:

  According to another embodiment, the apparatus further comprises a module for obtaining information related to a current allocation of virtual resources to a plurality of physical and software resources.

  According to another embodiment, the apparatus further comprises a module for allocating the at least one virtual resource based on the affinity information.

  The effects and advantages realized by the apparatus embodiments correspond to the effects and advantages of the method embodiments described in detail above.

FIG. 2 is a diagram showing an overview of an architecture framework for network function virtualization, in particular, an architecture with function building blocks of an ETSI NFV E2E architecture framework. FIG. 3 illustrates an example of a data center conceptual schema and physical clustering problem. It is a figure which shows the effect when using an example of tenant affinity, and tenant affinity with a VM affinity rule. FIG. 2 illustrates a conceptual scheme of a data center according to the prior art based on a DRS cluster and a conceptual scheme of a data center with allocation according to one embodiment based on inter-tenant affinity values. It is a figure which shows one Embodiment of the method for allocating a virtual resource based on tenant affinity information whose affinity value between tenants is "1". It is a figure which shows one Embodiment of the method for allocating a virtual resource based on tenant affinity information whose affinity value between tenants is "0". FIG. 3 illustrates signaling and information flow between functional blocks of the NFV architecture framework when performing a first exemplary embodiment of a method for allocating virtualized resources based on tenant affinity information. FIG. 6 illustrates signaling and information flow between functional blocks of the NFV architecture framework when performing a second exemplary embodiment of a method for allocating virtualized resources based on tenant affinity information. FIG. 7 illustrates signaling and information flow between functional blocks of the NFV architecture framework when performing a third exemplary embodiment of a method for allocating virtualized resources based on tenant affinity information. FIG. 7 illustrates signaling and information flow between functional blocks of the NFV architecture framework when performing a fourth exemplary embodiment of a method for allocating virtualized resources based on tenant affinity information.

First, some terms used in the description are defined in the following abbreviation list.
CMS Cloud Management System DRS Distributed Resource Scheduler NFV Network Function Virtualization NFVI NFV Infrastructure NFVO NFV Orchestrator VIM Virtual Infrastructure Manager VNF Virtual Network Function VNFM VNF Manager

  The NFV specification is being promoted by the Industry Specification Group (ISG) at the European Telecommunications Standards Institute (ETSI). The ETSI NFV defines an NFV architecture framework that focuses on new functional blocks and reference points brought about by the virtualization of the operator's network. An overview of the NFV architecture framework is shown in FIG.

  The NFV architecture framework represents functional blocks and reference points between such functional blocks. Functional partitioning and declared reference points support management and organization of VNFs 101 in a multi-vendor ecosystem. Specifically, the framework performs the necessary functional partitioning to ensure that the VNF software can be separated from the underlying infrastructure. In this scenario, VNF vendors and implementers become real tenants when using infrastructure that is likely to be managed by another entity, for example, a mobile network operator. This infrastructure consists of computational, storage and network resources located in one or more data centers. The infrastructure is also becoming shared and by using virtualization techniques several VMs can be allocated and run on a single physical server.

  Throughout the description, the terms “vendor” and “tenant” are used interchangeably.

The technology disclosed in this specification mainly deals with the following functional blocks of the NFV architecture framework shown in FIG.
An NFV orchestrator (NFVO) 102 responsible for organizing and managing NFV infrastructure and software resources and realizing network services over NFVI. Network services are realized by a collection of one or more VNFs.
A VNF manager (VNFM) 103 responsible for VNF lifecycle management (eg, VNF instantiation, update, query, scaling, termination).
A virtualization infrastructure manager (VIM) 104 that controls and manages NFVI computation, storage and network resources. For cloud-based NFVI, the VIM can be implemented as a cloud management system (CMS).
An NFV infrastructure (NFVI) 105 comprising a set of computational, storage and network resources to which virtualized resources are allocated.

  While NFVO performs global resource allocation, VNFM can interact directly with VIM (eg, CMS) to request management of virtualized resources as part of VNF deployment and management. One example for such an interaction is a capacity extension for deployed VNFs, which may consist of the VNFM requesting additional VMs from the VMS that are then added to the VNF.

The teachings of this disclosure address the following issues in the context of the NFV architecture framework. Assuming a multi-vendor VNF scenario where VNFs come from different vendors, each with specific resource requirements, physical clustering of resources can be avoided, improving statistical gain by sharing resources among different vendors. Describe how you can be assured.
Hereinafter, embodiments of the present invention will be described.

  The technology disclosed herein is based on declaring explicit affinity rules based on tenant / vendor information. By declaring such information, the virtualized resource manager engine (part of the cloud management system, or part of the VIM) can be virtualized without having to plan in advance the division of physical and software resources in the data center. Virtualized resources (eg, VMs) can be allocated as part of a deployment (eg, VNF).

This solution focuses on:
• Parameters related to tenant affinity on the interface with the functional blocks of the NFV architecture framework.
-A method for resource allocation based on tenant affinity information.

  In the claims, the tenant affinity parameter, called affinity information, indicates that the virtualized resource requested by the tenant (vendor) is collocated on the same physical and / or software resources as other virtualized resources from other tenants (vendors). Give information on whether to get. Tenant affinity is a different parameter than that described in the background section as provided by other affinity parameters known in the state of the art, for example, VMware DRS. FIG. 3 illustrates a tenant affinity parameter according to one embodiment and how tenant affinity information usage is complementary to the VM affinity information used in the latest technology (ie, the VM affinity defined above). Show. This VM affinity information refers only to the affinity between the selected VMs, not the server. Here, VM affinity = 0 means that the new selected VM cannot be allocated on the same server, and VM affinity = 1 means that the selected VM must be allocated on the same server. To do. In this example, virtual resources (VM) C3 and C4 of tenant “C” are selected VMs having VM affinity = 0 and are allocated to servers 1 and 2 while using “VM affinity = 0” information. (Case 301). Therefore, C3 and C4 are allocated to different servers (server 1 and server 2). However, when the “tenant affinity = 1” information is further considered, this means that each of the tenant's new VMs is allocated to a server to which only this tenant's VM is allocated or a server that has not yet been allocated a VM. It means you have to. Thus, as shown on the right hand side of FIG. 3, an allocation is performed for servers 2 and 3 (case 302) and these servers are only used by the same tenant C (pointing to server 2), or It is not used at all and is therefore fully available (pointing to server 3).

  Although FIG. 3 shows an example with only two selected VMs, those skilled in the art will appreciate that the same principles can be applied to more than two selected VMs to be allocated.

  FIG. 4 compares the prior art (based on DRS clusters) with the technique according to the present disclosure. The left hand side of the figure shows the “physical clustering” technique described above. The right hand side shows an example using the tenant affinity parameter. In this case, an affinity value of “1” means that the resource cannot be shared among tenants, and thus a virtual resource having this value can share a server only with other virtual resources from the same tenant. Furthermore, there is a virtual resource having an affinity value of “0”, which means that the server can be shared with virtual resources from other tenants.

  Several embodiments are possible using this basic idea, some of which are detailed below.

This technique described herein and specified in the claims has the following advantages.
-Allows resources in the data center to be allocated at runtime in a more dynamic way without the need to plan physical and software resources in advance and pre-allocate to tenants (vendors). Since resource pools are statistically shared among tenants, fewer resources are required in the data center. Therefore, as shown in FIG. 4, resource and capital expenditures can be saved, which means that the operation cost can be reduced by reducing the amount of necessary resources at the same time.
-Avoid resource fragmentation by tenants. This may be based on other parameters or resource capabilities, such as resource type (if any specific hardware acceleration is possible on some hosts), resource quality, elasticity level, etc. Provides more flexibility to implement.
Enables the virtualization infrastructure administrator (in this case, the network operator) to separate the computation, storage and network resources in the data center from the VNF software vendor implementation.
How a tenant (vendor) deploys for each VNF deployment / operation case in terms of whether such VNFs and corresponding virtualized resources are collocated with other tenant virtualized resources Allows you to decide what should be done. This allows vendors to have different VNF provisioning strategies under different circumstances, such as traffic load in the data center, their VNF priority, and / or additional network service and resource policy constraints.

  Hereinafter, a method for allocating virtual resources based on tenant affinity information will be described.

  FIG. 5 shows an example in which the inter-tenant affinity value is “1”. This means that the VM cannot be collocated with VMs from other tenants.

  FIG. 6 shows an example in which the inter-tenant affinity value is “0”. In such an example, the request is to allocate a VM and be able to co-locate with VMs from other tenants.

  The method shown in FIGS. 5 and 6 includes the following four main steps.

  1. Step 1 (S501): A request is made to allocate one or more virtualized resources (for simplicity, such resources are assumed to be virtual machines, VMs). Such a request includes information (parameter) for identifying a tenant that has transmitted such a request, and a tenant affinity value for each virtualization resource.

2. Step 2 (S502): The virtualization resource management engine 511 collects input information from the request in Step 1. In addition, additional information (stored or retrieved from another entity) regarding the current placement of virtualized resources on the pool of shared physical and software resources in the data center can be collected. This additional information includes at least the following information elements in the tables shown with the examples of FIGS. 5 and 6 for each identified physical host (identified by the “server id” parameter 521).
a. Use Affinity 522 (how the current host / server is used): This corresponds to the tenant affinity parameter signaled in step 1, but here the current physical host can be shared with other tenants (Use affinity “0”) or dedicated to the tenant (use affinity “1”).
b. One or more tenants using such resources (used tenant id 523), and c. Virtualization resource (eg, VM) identifier (vm-id 524): A list of virtual machines instantiated on this physical host.

  3. Step 3 (S503): The virtualization resource management engine discovers a physical host (server) that uses the resource and tenant affinity requirements.

  4). Step 4 (S504): The virtualization resource management engine assigns a hypervisor or virtual machine manager for the selected server / host to allocate a virtualization resource (eg, VM) in the data center (cloud infrastructure) 512 Send an allocation request for.

Some embodiments may be based on the person issuing and processing the request with the tenant affinity information and based on how such information is processed, for example,
Based on actual resource requests on the interface or by mapping resource requests to actual reservations of resources (Note: in this case, reservations are logical, eg number of vCPUs, virtual memory, etc. That is, it is larger in terms of quota rather than physical host reservation), or by setting up and using policies.

  FIGS. 7-10 show NFV architecture frames when performing an exemplary embodiment of a method for allocating virtualization resources based on tenant affinity information, respectively described below as Embodiments 1-4. 2 shows an exemplary information flow between functional blocks of a work.

  Other possible embodiments, referred to as Embodiments A through D, are during resource management operations such as scaling out a virtualized deployment (eg, VNF), or during partial or full movement of virtualized resources, or Including utilizing the present invention during partial or full recovery of a virtualized deployment. In addition, the tenant affinity parameter not only holds one of the binary values “0” and “1” that have been used as an example so far, but also includes values from sets having more than two values. Can be extended to hold. All these embodiments are summarized and described in the following sections.

  The first set of embodiments 1-4 is directed to the use of the present invention during a resource allocation request procedure.

  Embodiment 1 is the main basic embodiment that has been used as an example throughout the above text. Here, the resource allocation request is requested in addition to existing parameters (such as specific resource requirements and possibly reservation information), as well as the tenant identification (tenant id) as presented in this disclosure Includes tenant affinity for each virtualized resource. In this case, as in step S701, the resource request is made by the VNFM and transmitted to the VIM. The handling of such requirements during tenant affinity mapping and resource selection is realized by VIM. The sequence of steps and signaling between functional blocks according to Embodiment 1 is shown in FIG.

  The second embodiment is another embodiment which is also aimed at the tenant affinity and tenant id signaling as part of the allocation request. In this case, as outlined in the first embodiment, the VNFM and the VIM Instead of being done directly between, it is done indirectly through NFVO (as shown in steps S801 and S802). Tenant affinity information is still signaled by VNFM. During this process, the NFVO can also map resource requests by the VNFM to specific reservations. The sequence of steps and signaling between functional blocks according to Embodiment 2 is shown in FIG.

  The third embodiment differs from the second embodiment in that not all information needs to be signaled from the VNFM. Rather, some of the information is derived by the NFVO that maps the tenant id from the resource request from the VNFM. The NFVO here maintains internal information that allows tenant affinity information to be derived. NFVO can also map VNFM resource requests to specific reservations. The NFVO can then proceed to signaling a resource allocation request to the VIM as in Embodiment 2 (as in step S902). The sequence of steps and signaling between functional blocks according to Embodiment 3 is shown in FIG.

  Embodiment 4: In this case, tenant affinity information signaling is part of the policy creation process. In this illustrative case shown in FIG. 10, NFVO is the “policy creation” originator and VIM is the entity that maintains such a policy. Such a policy creation request (step S1001) includes information on a tenant identifier (tenant id), a tenant affinity parameter, and a VNF class or a class list ([vnf class]) from a tenant that should follow such affinity placement requirements. including. The parameter notation uses square brackets “[“ ”]” to indicate that one of the values or a list of values can be specified. The VIM stores such information that can be used later to make allocation decisions. When a policy is created, another third element, for example, a resource allocation request (for example, VNFM needs to specify only resource requirements and VNF type or class (vnf class) for such resource allocation. Step S1003) can be transmitted directly. The VIM then maps such information with the information contained in the policy and determines resource allocation accordingly.

  The second set of embodiments scales the capacity of the VNF or moves a VNF virtual machine from one physical host to another physical host where such tenant affinity can be used. Or different types of resource operations, such as partially or fully recovering VNFs. Accordingly, these embodiments are orthogonal to the first set of embodiments. The first set describes different ways to implement signaling procedures to support passing tenant affinity related information through different functional blocks within the NFV architecture framework, and the second set is supported Different operations on the virtualized resource to be obtained are described. Thus, features of embodiments from both sets of embodiments can be combined.

  Embodiment A uses tenant affinity information as part of the actual virtual resource allocation request during a new instantiation process of VNF (virtualized deployment). This is an example that has been used heretofore.

  In embodiment B, it is assumed that the VNF should be scaled out, for example, by adding additional virtual machines to this VNF. Therefore, this scale-out procedure also requires new resource allocation and tenant affinity information is used to ensure proper instantiation of such resources. In such cases, new virtualized resources may be required as part of such VNFs or extensions of existing ones, eg, allocation of additional vCPUs or virtual memory to existing virtualized resources (VMs). Note that a scale-in procedure in which the capacity of the VNF is reduced may also require tenant affinity information. Examples are when the VIM wants to determine which VM to remove first, or when the VM after resource consolidation after scale-in should move (described in embodiment C below).

  Embodiment C assumes a migration scenario, i.e., the entire VNF or part of the VNF should move to different servers within or between data centers. This can be achieved by standard virtual machine movement techniques commonly used in data centers. Here, the tenant affinity information is used to determine to which server the VM of the VNF can or cannot be moved.

  Embodiment D is directed to VNF virtualization resource recovery (failure recovery) for the entire VNF or part of the VNF. An example here is the failure of several VMs in VNF that need to be redeployed to a new server. Also in this case, tenant affinity information is used to determine candidate servers suitable for such redeployment.

  Finally, in the third set of embodiments I-III, the possible values of the tenant affinity parameter are variable. The value is binary as described so far, or takes a different value from a predefined set of values.

  In embodiment I, the tenant affinity parameter is a binary value that determines whether the virtualized resource can be collocated with virtualized resources from other tenants. If the parameter is equal to “0”, the virtualized resource can be collocated on the shared physical and software resources in the data center with other virtualized resources from other tenants, and if this parameter is equal to “1” Virtualized resources cannot be co-located with virtualized resources from other tenants. This is the embodiment described in the above text.

In embodiment II, the tenant affinity parameter can take a value from a value set, with different values indicating information on affinity or anti-affinity for some or all of the tenants (vendors). For example,
Tenant affinity = A: affinity for an arbitrary tenant (vendor) in group A.
Tenant affinity = B: affinity for any tenant (vendor) different from tenant id = X.
Tenant affinity = C: affinity for tenant id = Z rather than for tenant id = Y.
・ Others.

In embodiment III, the tenant affinity parameter can take a value from a value set with more than two values, with different values to affinity or anti-affinity for a collocated virtualized resource with several capabilities. Information. For example,
Tenant affinity = M: Anti-affinity for VMs that have a heavy calculation load from other tenants.
Tenant affinity = N: Anti-affinity for VMs with a lot of input / output data from other tenants.
・ Others.

  It will be readily apparent to those skilled in the art that the methods, elements, units, and devices described with respect to the embodiments of the invention may be implemented in hardware, software, or a combination of both. In particular, the embodiments of the invention and the elements of the modules described with respect to the embodiments of the invention may be implemented by one or more computer programs being executed on a computer or executed by a microprocessor. It will be understood. Any apparatus that implements the present invention may particularly take the form of a computing device operating as a network entity.

Claims (14)

A method of allocating at least one virtual resource to a certain physical and / or software resource among a plurality of physical and / or software resources (105) by a virtual resource management engine (511),
The virtualization resource management engine obtaining identification information used to identify a first tenant requesting the at least one virtual resource;
The requested virtual resource may be collocated on the same physical and / or software resources as one or more virtual resources of another tenant different from the first tenant identified by the acquired identification information The virtual resource management engine obtains affinity information as a parameter of a resource allocation request that specifies whether or not;
The virtual resource management engine allocates the at least one virtual resource based on the acquired affinity information;
Including methods. Obtaining information related to a current allocation of virtual resources to the plurality of physical and software resources;
The method of claim 1 comprising:   The virtual resource management engine is part of an entity (104) responsible for virtual infrastructure management of virtual, physical and software resources in a data center or cloud infrastructure (512). the method of. The identification information used to identify the first tenant and the signaling entity of the affinity information are entities (103) responsible for managing virtual network functions according to any one of claims 1-3. The method described.   The method according to any of the preceding claims, wherein the signaling is transferred through an entity (102) responsible for organizing resources and virtual network functions. An intermediate step for discovering the affinity information based on the identification information received to identify the first tenant;
The method according to claim 1, comprising: The identity signaling entity used to identify the first tenant is an entity responsible for managing virtual network functions;
The discovery of the affinity information based on identification information used to identify the first tenant is performed by an entity responsible for organizing resources and virtual network functions;
The method of claim 6, wherein the identification information used to identify the first tenant and the signaling of the affinity information is performed by an entity responsible for organizing resources and virtual network functions.   The method according to claim 1, wherein the affinity information is part of a policy, and the affinity information is signaled as part of the policy setup process. A process of allocating the at least one virtual resource to a certain physical and / or software resource among the plurality of physical and / or software resources is part of a management operation;
The management operation is as follows:
A first instantiation of a virtualized deployment, or
Full or partial scale-out, migration, or recovery of virtualization resources in an existing virtualization deployment,
The method according to claim 1, comprising: The at least one virtual resource is
A virtual machine running on the hypervisor,
A virtual application container running on the operating system, or
A virtual disk drive for storage,
The method according to any one of claims 1 to 9.   The method according to any one of claims 1 to 10, wherein the allocation of virtual resources is performed for virtualized deployment, and the virtualized deployment is a virtual network function. The affinity information can take a plurality of values for different allocation cases, and the allocation case is a virtual resource with a large load on the anti-affinity for a specific tenant, affinity for a specific tenant, calculation, storage or network Affinity for,
Including one or more of
The method according to claim 1. An apparatus for allocating at least one virtual resource to a certain physical and / or software resource among a plurality of physical and / or software resources (105) by a virtual resource management engine (511),
A module for obtaining identification information used to identify a first tenant requesting the at least one virtual resource;
The requested virtual resource may be collocated on the same physical and / or software resources as one or more virtual resources of another tenant different from the first tenant identified by the acquired identification information A module for acquiring affinity information as a parameter for resource allocation request,
A module designed to allocate the at least one virtual resource based on the acquired affinity information;
A device comprising: The computer program for making a computer perform the method as described in any one of Claims 1-12.