KR20160148898A - Apparatus and Method for Mapping of Tenant Based Dynamic Processor - Google Patents

Apparatus and Method for Mapping of Tenant Based Dynamic Processor Download PDF

Info

Publication number
KR20160148898A
KR20160148898A KR1020150085677A KR20150085677A KR20160148898A KR 20160148898 A KR20160148898 A KR 20160148898A KR 1020150085677 A KR1020150085677 A KR 1020150085677A KR 20150085677 A KR20150085677 A KR 20150085677A KR 20160148898 A KR20160148898 A KR 20160148898A
Authority
KR
South Korea
Prior art keywords
tenant
virtual machine
processor
queue
belonging
Prior art date
Application number
KR1020150085677A
Other languages
Korean (ko)
Inventor
최강일
이범철
Original Assignee
한국전자통신연구원
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 한국전자통신연구원 filed Critical 한국전자통신연구원
Priority to KR1020150085677A priority Critical patent/KR20160148898A/en
Publication of KR20160148898A publication Critical patent/KR20160148898A/en

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals

Abstract

A network virtualization apparatus according to an embodiment of the present invention includes a network interface card having a plurality of virtual machine queues, one or more virtual machines for each tenant, generated with respect to tenant information including tenant priority information received from a cloud OS, and a hypervisor which includes at least one processor mapped to a virtual machine queue transferred from the network interface card and processing the virtual machine queue and a virtual switch for transferring the packet of the virtual machine queue to the virtual machine. The hypervisor may perform mapping between the virtual machine queue and the processor for processing the virtual machine queue according to each tenant. So, an effect caused by network traffic can be prevented.

Description

[0001] APPARATUS AND METHOD FOR MAPPING OF TENANT BASED DYNAMIC PROCESSOR [0002]

The present invention relates to an apparatus and method for providing network virtualization, and more particularly, to an apparatus and method for allocating a dynamic processor to a tenant based system for providing network virtualization in a multi-tenant based cloud server system.

Processing techniques for speeding up network traffic performance in network interface cards (NICs) of multiprocessor based server systems have continued to evolve. The biggest problem was that the traffic received from the NIC was not effectively handled by multiprocessors in the server. The technology that solves this problem is Receive Side Scaling (RSS) technology. RSS technology handles network traffic received from a NIC of a multiprocessor-based server by performing a hash function and dividing it into different flows. In the RSS technology, traffic corresponding to the same flow is allocated to be processed by the same processor, so that the network traffic is dispersed by the multi-processor in the multiprocessor environment and processed at a high speed. However, there is a problem that RSS technology is difficult to apply in a virtualized environment.

A technique for solving the problem of RSS in a virtualized environment is the Virtual Machine Queue (VMQ) technology. In VMQ technology, virtual machine multi-queues are created in the NIC, and each virtual machine multi-queue is allocated to the processors in the host, so that multi-processor distributed processing of network traffic is possible even in a virtualized environment, Treatment.

For example, the server system sets up a virtual machine queue (VMQ) and allocates a processor (LP) to process the virtual machine queue. Receives packets input to the server through the NIC, classifies them based on the L2 information, and sends the packet to the virtual machine queue (VMQ). In the hypervisor, the processor that processes the virtual machine queue processes the packets entered in the virtual machine queue and delivers them to the virtual machine (VM) through the L2 virtual switch. The corresponding virtual machine created by the hypervisor processes the received packets do. However, because VMQ technology statically allocates virtual machine multi-queues, too few processor resources may be allocated for multiple queues where traffic congestion occurs and too many There is a problem that a problem of assigning to processor resources may occur.

The present invention classifies a virtual machine multi-queue and a processor that processes the multi-queue according to a tenant to which the virtual machine belongs, and based on the total usage of the network and the processor for each tenant, Based dynamic processor allocation device that provides network virtualization that dynamically allocates network traffic to virtual machines belonging to the same tenant so that the network traffic processing of the same tenant is not affected by the congestion of network traffic belonging to other tenants And methods.

The present invention provides a tenant-based dynamic processor allocation apparatus and method that provides network virtualization that ensures that network traffic processing of virtual machines belonging to the same tenant is not affected by the state of network traffic belonging to other tenants.

A network virtualization apparatus for a cloud server system according to an embodiment of the present invention includes a network interface card having a plurality of virtual machine queues, at least one virtual server for each tenant generated based on tenant information including tenant priority information received from the cloud OS At least one processor mapped to a virtual machine queue delivered from the network interface card to process the virtual machine queue and a virtual machine queue manager coupled to the virtual machine queue, Wherein the hypervisor performs the mapping between the virtual machine queue and the processor for processing the virtual machine queue separately for each tenant.

The hypervisor may dynamically allocate the virtual machine queue and the processor for each tenant in proportion to the total number of virtual machines belonging to the same tenant.

The hypervisor can dynamically allocate the virtual machine queue and the processor for each tenant in proportion to the total sum of virtual CPUs used in the virtual machines belonging to the same tenant.

When the creation of a new virtual machine is requested by the cloud OS, the hypervisor creates an additional virtual machine, extracts the tenant information including the virtual machine information of the additional virtual machine and the priority information of the tenant And dynamically reassign the virtual machine queue and the processor based on the extracted virtual machine information and the tenant information.

The hypervisor dynamically allocates the virtual machine queue and the processor for each tenant in proportion to the total sum of the virtual CPUs used in the virtual machine belonging to the same tenant or in proportion to the total sum of the virtual CPUs used in the virtual machine belonging to the same tenant Can be reassigned.

If the virtual machine is deleted by the cloud OS, the hypervisor removes the deleted virtual machine, extracts tenant information including virtual machine information of the removed virtual machine and priority information of the tenant, And dynamically reassign the virtual machine queue and the processor based on the extracted virtual machine information and the tenant information.

The hypervisor dynamically allocates the virtual machine queue and the processor for each tenant in proportion to the total sum of the virtual CPUs used in the virtual machine belonging to the same tenant or in proportion to the total sum of the virtual CPUs used in the virtual machine belonging to the same tenant Can be reassigned.

When the traffic usage of the virtual machine belonging to the first tenant is increased so that it can no longer be processed by the processor belonging to the first tenant, the hypervisor uses all the processors that process the virtual machine queue belonging to the first tenant If it is possible to perform the TDVMQ extension process by using all the processors that process the virtual machine queue belonging to the first tenant as a result of checking whether or not the TDVMQ (Tenant-based Dynamic Virtual Machine Queue) extension process can be performed, The TDVMQ extension process can be performed using all the processors that process the virtual machine queues belonging to the first tenant.

If it is determined that the TDVMQ extension process can not be performed using all of the processors that process the virtual machine queue belonging to the first tenant, the hypervisor can not perform the TDVMQ extension process for the second tenant in the cloud server system And if there is a usable second tuner, if the priority of the first tuner is higher than or equal to the priority of the usable second tuner, The TDVMQ extension process can be performed using the processor.

If the idle processor is not available for the second tenant in the cloud server system, then the hypervisor is configured to perform a TDVMQ reduction on the second tenant in the cloud server system rather than the first tenant If the priority of the first tuner is higher than or equal to the priority of the second tuner, if it is possible to perform the TDVMQ reduction process as a result of checking, The TDVMQ reduction process can be performed using an algorithm of FIG.

The hypervisor may perform the TDVMQ extension process using a processor that becomes an idle processor according to the result of performing the TDVMQ reduction process of the second tenant.

According to an embodiment of the present invention, a virtual machine multi-queue and a processor for processing the multi-queue are classified into tenants to which the virtual machine belongs, and based on the total usage amount of the network and the processor, Machine multi-queues are dynamically allocated to multi-processors belonging to the tenants to provide network virtualization that ensures that the network traffic processing of virtual machines belonging to the same tenant is not affected by the congestion of network traffic belonging to other tenants. Based dynamic processor allocation apparatus and method are provided.

In addition, according to an embodiment of the present invention, a tenant-based dynamic processor allocation device that provides network virtualization that ensures that network traffic processing of virtual machines belonging to the same tenant is not affected by the state of network traffic belonging to another tenant, Method is provided.

FIG. 1 is a view for explaining a network virtualization apparatus having a TDVMQ (Tenant-based Dynamic Virtual Machine Queue) structure for application to a cloud server system for tenant-based dynamic processor allocation according to an embodiment of the present invention.
FIG. 2 is a view for explaining a network virtualization apparatus of a T-DVMQ structure allocating a virtual machine queue and a processor for processing the virtual machine queue in proportion to the total number of virtual machines according to an embodiment of the present invention.
3 illustrates a network virtualization apparatus of a TDVMQ structure allocating a virtual machine queue and a processor for processing the virtual machine queue in proportion to the total number of virtual CPUs (vCPUs) used in the virtual machine according to an embodiment of the present invention Fig.
4 illustrates a network virtualization apparatus of a TDVMQ structure that allocates a virtual machine queue and a processor for processing the virtual machine queue when a new virtual machine is created by a cloud OS or a control manager according to an embodiment of the present invention FIG.
5 illustrates a network virtualization apparatus of a TDVMQ structure that allocates a virtual machine queue and a processor that processes the virtual machine queue when a new virtual machine is deleted by a cloud OS or a control manager according to an embodiment of the present invention FIG.
6 is a diagram for explaining a network virtualization apparatus when traffic to a virtual machine increases according to an embodiment of the present invention.
FIG. 7 is a view for explaining a network virtualization apparatus after dynamically changing an allocation table between a virtual machine and a processor from the TDVMQ structure of FIG. 6 according to an embodiment of the present invention.
8 is a diagram illustrating a network virtualization apparatus of a TDVMQ structure that allocates a virtual machine queue and a processor for processing the virtual machine queue when the traffic for the virtual machine decreases according to an embodiment of the present invention.
Figure 9 is a control flow diagram illustrating tenant-based dynamic processor allocation in accordance with one embodiment of the present invention.
10 is a control flowchart for explaining a TDVMQ extension process according to an embodiment of the present invention.
11 is a diagram illustrating a system in which traffic congestion occurs in a processor according to an embodiment of the present invention.
FIG. 12 is a diagram showing a system after dynamically changing an allocation table between a virtual machine and a processor by a network virtualization device from the TDVMQ structure of FIG. 11. FIG.
13 is a diagram illustrating a system in which traffic congestion occurs in a processor according to another embodiment of the present invention.
FIG. 14 is a diagram showing a system after dynamically changing an allocation table between a virtual machine and a processor by a network virtualization device from the TDVMQ structure of FIG. 13. FIG.
15 is a diagram illustrating a system in which traffic congestion occurs in a processor according to another embodiment of the present invention.
FIG. 16 is a diagram illustrating a tenant performing a reduction process according to a tenant-based TDVMQ extension process from the TDVMQ structure of FIG. 13. FIG.
FIG. 17 is a diagram illustrating a tenant performing an extension process according to a tenant-based TDVMQ extension process from the TDVMQ structure of FIG. 16. FIG.

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. In the following description of the embodiments of the present invention, a detailed description of known functions and configurations incorporated herein will be omitted when it may make the subject matter of the present disclosure rather unclear.

It is to be understood that when an element is referred to as being "connected" or "connected" to another element, it may be directly connected or connected to the other element, . In addition, the description of "including" a specific configuration in the present invention does not exclude a configuration other than the configuration, and means that additional configurations can be included in the practice of the present invention or the technical scope of the present invention.

In addition, the components shown in the embodiments of the present invention are shown independently to represent different characteristic functions, which does not mean that each component is composed of separate hardware or software constituent units. That is, each constituent unit is included in each constituent unit for convenience of explanation, and at least two constituent units of the constituent units may be combined to form one constituent unit, or one constituent unit may be divided into a plurality of constituent units to perform a function. The integrated embodiments and separate embodiments of the components are also included within the scope of the present invention, unless they depart from the essence of the present invention.

In addition, some of the components are not essential components to perform essential functions in the present invention, but may be optional components only to improve performance. The present invention can be implemented only with components essential for realizing the essence of the present invention, except for the components used for the performance improvement, and can be implemented by only including the essential components except the optional components used for performance improvement Are also included in the scope of the present invention.

First, network virtualization applied to a cloud server system should ensure that network traffic of virtual machines belonging to the same tenant is not affected by network traffic belonging to other tenants.

As a method for solving the above-mentioned problem of static allocation of the VMQ, a technique of dynamically allocating the VMQ (Dynamic Virtual Machine Queue) has been attempted. DVMQ technology is a method of dynamically allocating virtual machine queues to multiprocessors based on the amount of network traffic and the total amount of processor usage. If the amount of network traffic or the total usage of the processor exceeds the set maximum threshold value, the multi-machine queue allocated to the processor is dynamically reallocated and processed. Or when the amount of network traffic or the total amount of processor usage falls below a set minimum threshold value, the multi-machine queue assigned to the processor is dynamically reallocated to remove the processor from the allocation, thereby reducing network traffic processing performance and power consumption Can be optimized.

However, it is possible to optimize network processing performance and power consumption in multiprocessor environment by using existing VMQ or DVMQ technology, but there is insufficient consideration of network virtualization technology required in cloud system in this optimization process.

Accordingly, the present invention provides network virtualization that ensures that network traffic processing of virtual machines belonging to the same tenant is not affected by the situation of network traffic belonging to other tenants, for example, congestion.

According to an embodiment of the present invention, a hypervisor (or a virtual machine manager) that extracts tenant information and virtual machine information including priority information of tenants generated by a cloud OS or a control manager transmits a virtual machine queue and a corresponding multi- Processors can be classified by tenants, and virtual machine queues belonging to the tenants can be dynamically allocated to the multi-processors belonging to the tenants by each tenant.

At this time, the hypervisor may dynamically allocate a virtual machine queue and a processor that processes the virtual machine queue in proportion to the total number of virtual machines belonging to the same tenant.

Alternatively, the hypervisor may dynamically allocate a virtual machine queue and a processor that processes the virtual machine queue in proportion to the total number of virtual CPUs (vCPUs) used by the virtual machines belonging to the same tenant.

According to an embodiment of the present invention, a method of dynamically allocating a virtual machine queue and a processor within each tenant may follow the existing DVMQ scheme. However, the DVMQ method is different from the DVMQ method in that, in order to support network virtualization by eliminating interference between different tenants according to an embodiment of the present invention, the hypervisor dynamically allocates a virtual machine queue and a processor (VMQ / LP) (VMQ) belonging to the same tenant and the processor (LP) belonging to the tenant.

According to an embodiment of the present invention, when a new virtual machine is created by the cloud OS or the control manager, the hypervisor or the virtual machine manager extracts the tenant information including the generated virtual machine information and tenant priority information, Based on the extracted tenant information and virtual machine information, a virtual machine queue and a processor for processing the multi-queue are dynamically allocated to pre-allocated mappings for respective tenants.

According to an embodiment of the present invention, when the new virtual machine is deleted by the cloud OS or the control manager, the hypervisor or the virtual machine manager extracts the tenant information including the generated virtual machine information and tenant priority information, Based on the extracted tenant information, the virtual machine queue and the processor that processes the multi-queue are dynamically deleted in the pre-allocated mapping for each tenant.

According to an embodiment of the present invention, in order to optimize network traffic processing performance, when a traffic of a virtual machine belonging to one tenant increases in use and can no longer be processed by a processor belonging to the same tenant, , It is possible to dynamically allocate a virtual machine queue and a processor that processes the virtual machine queue so that it can be extended to processors not used by other tenants.

FIG. 1 is a diagram for explaining a network virtualization apparatus 100 having a tenant-based dynamic virtual machine queue (TDVMQ) structure for application to a cloud server system for tenant-based dynamic processor allocation according to an embodiment of the present invention .

Referring to FIG. 1, a tenant-based network virtualization apparatus 100 according to an embodiment of the present invention includes a network interface card (NIC) 110, a hypervisor 120, A virtual machine unit 130, and a cloud OS (Operating System) or a controller 150 (hereinafter referred to as a 'cloud OS').

Each component of such a network virtualization device 100 may be implemented in hardware (e.g., a semiconductor processor, etc.), software, or a combination thereof, where virtualization means performing a primary function with processing by software . As described below, the virtual machines (VMs, VM1 to VM5) of the virtual machine unit 130 are created (or assigned occupancy) by the hypervisor 120 under the control of the cloud OS 150, and each virtual machine (VM) is virtualized hardware, which may be, for example, a virtualized CPU for processing data on behalf of a physical CPU (Control Processing Unit) and operating on a respective different operating system (OS) Each of which occupies a part of the memory included in the system for operation. Each virtual machine (VM) includes a virtual network interface card (vNIC1 to vNIC5) for interfacing with the hypervisor 120 or another virtual machine.

For example, the cloud OS 150 may generate, for example, A, B, .. (see FIG. 2) as a tenant information or tenant ID for a tenant subscribed to the cloud server system as a Universally Unique Identifier (UUID) To the hypervisor 120 and the hypervisor 120 (e.g., the generating unit of the hypervisor 120) notifies the hypervisor 120 of each tenant corresponding to the tenant information (e.g., A, B, Machines VM1 to VM3 / VM4 to VM5 /. The hypervisor 120 stores the information of the tenant (for example, A, B, ..) and the virtual machine information for each tenant (for example, virtual machines VM1 to VM3 / VM4 to VM5 / To the network interface card (NIC) 110. The hypervisor 120 includes a generation unit for generating virtual machines VM1 to VM3 / VM4 to VM5 /. In addition, as shown in FIG. 1, the virtual machine queue VMQ And the output data of the logical processors LPs are output to the virtual machines VM1 through VMn5 via the virtual network interface cards vNIC1 through vNIC5, VM3 / VM4 to VM5 / ..).

The network interface card (NIC) 110 includes a MAC / PHY (Media Access Control and Physical Layer) processor 111, a Layer 2 (L2) classifier / sorter 112, virtual machine queues (VMQs, VMQ1 to VMQ5 ).

The MAC / PHY processor 111 determines whether the packet received from the outside matches the destination MAC address and receives the packet. The L2 classifier 112 identifies the tenants (eg, A, B, ..) based on the L2 information (eg, the MAC address of the virtual machine) of the received packet, classifies the packets by tenants, To the virtual machine queue (VMQ) belonging to the corresponding tenant. In some cases, the L2 classifier 112 parses the received packet to extract IP (Internet Protocol) information (eg, source IP address, destination IP address, protocol, source port, destination port) (E.g., A, B, ..) according to the IP address of the virtual machine (e.g., the IP address information of the virtual machine).

As described above, in the present invention, virtual machines (VM1 to VM3 / VM4 to VM5 / ..) for processing the corresponding packets for each tenant classified by tenant information (e.g., A, B, One or more logical processors LP of the hypervisor 120 and one or more virtual machine queues VMQ of the network interface card NIC 110 are designated corresponding to one or more virtual machines (VMs) And is operated.

In summary, a tenant-based network virtualization apparatus, that is, a server system 100 according to an embodiment of the present invention sets a virtual machine queue for each tenant generated by the cloud OS 150 or a control manager, Allocate a processor to process. The network virtualization apparatus receives a packet input to the server through the NIC 110, classifies the packet based on L2 information (for example, Destination MAC), and sends the packet to the virtual machine queue. The processor for processing the virtual machine queue processes a packet received in the virtual machine queue, transfers the packet to the virtual machine 130 through the virtual switch 121, and the virtual machine processes the received packet.

FIG. 2 is a view for explaining a network virtualization apparatus of a TDVMQ structure allocating a virtual machine queue and a processor for processing the virtual machine queue in proportion to the total number of virtual machines according to an embodiment of the present invention.

The hypervisor 120 according to the present embodiment can dynamically allocate a virtual machine queue to a processor that processes the virtual machine queue in proportion to the total number of virtual machines belonging to the same tenant.

For example, suppose that tenant A has virtual machines VM1, VM2, and VM3, tenant B has virtual machines VM4 and VM5, and there are five processors that process virtual machine queues. At this time, since there are a total of three VMs in the tenant A and a total of two VMs in the tenant B, the hypervisor 120 allocates the virtual machine queue to the virtual machine queue at the ratio of tenant A: tenant B = 3: Lt; RTI ID = 0.0 > processors. ≪ / RTI > That is, for a processor that processes a total of five virtual machine queues, three can be assigned to tenant A, and two to tenant B, in proportion to the total number of virtual machines belonging to tenant.

For example, in this situation, the hypervisor 120 allocates LP1, LP2, and LP3 to the tenant A as shown in FIG. 2, allocates the VM1 virtual machine queue and the VM2 virtual machine queue of the tenant A to the processor LP1, The virtual machine queue of LP2 may be allocated to LP2, and the virtual machine queue may not be allocated to LP3.

The hypervisor 120 may also assign LP4 and LP5 to tenant B, allocate tenant B's VM4 virtual machine queue to processor LP4, and VM5's virtual machine queue to LP5.

Table 1 below is a VMQ / LP allocation table according to one embodiment that dynamically allocates a virtual machine queue and a processor that processes the virtual machine queue in proportion to the total number of virtual machines belonging to the same tenant.

Figure pat00001

3 illustrates a network virtualization apparatus of a TDVMQ structure allocating a virtual machine queue and a processor for processing the virtual machine queue in proportion to the total number of virtual CPUs (vCPUs) used in the virtual machine according to an embodiment of the present invention Fig.

The hypervisor 120 according to the present embodiment can dynamically allocate a virtual machine queue to a processor that processes the virtual machine queue so as to be proportional to the total number of virtual CPUs (vCPUs) used in the virtual machines belonging to the same tenant have.

For example, assume that tenants A, VM2, and VM3 belong to four vCPUs, tenants B have virtual machines VM4 and VM5, nine vCPUs each, and a virtual machine queue Suppose you have five processors.

At this time, since the tenant A uses a total of twelve vCPUs and the tenant B uses a total of eighteen vCPUs, the hypervisor 120 allocates a virtual machine queue and a virtual machine queue at a ratio of tenant A: tenant B = 2: Lt; / RTI > can be dynamically allocated. That is, for a processor that processes a total of five virtual machine queues, two processors may be allocated to tenant A and three processors to tenant B in proportion to the total number of vCPUs belonging to the tenant.

For example, as shown in FIG. 3, the hypervisor 120 allocates LP1 and LP2 to tenant A, assigns VM1 virtual machine queue and VM2 virtual machine queue of tenant A to processor LP1, and virtual machine queue of VM3 LP2. ≪ / RTI > LP3, LP4, and LP5 may be assigned to tenant B, the VM4 virtual machine queue of tenant B may be allocated to processor LP4, the virtual machine queue of VM5 may be allocated to LP5, and the virtual machine queue may not be allocated to LP3.

Table 2 shows the virtual machine queues and the VMQ / VMs according to one embodiment for dynamically allocating the virtual machine queues and processors that process the virtual machine queues in proportion to the total number of virtual CPUs (vCPUs) used in the virtual machines belonging to the same tenant. LP allocation table.

Figure pat00002

4 illustrates a network virtualization apparatus of a TDVMQ structure that allocates a virtual machine queue and a processor for processing the virtual machine queue when a new virtual machine is created by a cloud OS or a control manager according to an embodiment of the present invention FIG.

According to the present embodiment, when a new virtual machine is created by the cloud OS or the control manager, the hypervisor 120 extracts the generated virtual machine information and tenant information (including tenant priority information) Based on the virtual machine information (including the tenant priority information) and the virtual machine information, the virtual machine queue and the processor that processes the multi-queue can be dynamically allocated to the pre-allocated mapping for the tenant.

At this time, the hypervisor 120 dynamically reassigns the virtual machine queue and the processor that processes the virtual machine queue so that it is proportional to the total number of virtual machines belonging to the same tenant, or the virtual CPU vCPUs) to the processor processing the virtual machine queue.

FIG. 4 shows a network virtualization apparatus in a case where a virtual machine VM6 belonging to the tenant B is created in the situation shown in FIG.

Table 3 shows the changed VMQ / LP allocation table when a virtual machine VM 6 belonging to tenant B is created.

Figure pat00003

 5 is a diagram for explaining a network virtualization apparatus of a TDVMQ structure that allocates a virtual machine queue and a processor for processing the virtual machine queue when a new virtual machine is deleted by a cloud OS or a control manager according to an embodiment of the present invention to be.

The hypervisor 120 according to the present embodiment extracts deleted virtual machine information and tenant information (including tenant priority information) when the new virtual machine is deleted by the cloud OS or the control manager, Based on the tenant priority information), the virtual machine queue and the processor that processes the multi-queue can be dynamically deleted from the pre-allocated mappings for the tenant.

At this time, the hypervisor 120 dynamically reassigns the virtual machine queue and the processor that processes the virtual machine queue so that it is proportional to the total number of virtual machines belonging to the same tenant, or the virtual CPU vCPUs) to the processor processing the virtual machine queue.

FIG. 5 is a flowchart illustrating a process of dynamically reallocating a virtual machine queue and a processor that processes the virtual machine queue so that the virtual machine VM3 belonging to the tenant A is deleted in proportion to the total number of virtual machines belonging to the same tenant. It is a figure.

Table 4 below shows an embodiment of the modified VMQ / LP allocation table.

Figure pat00004

When VM3 is deleted, the ratio of the total number of virtual machines belonging to tenant A to that of tenant A is changed to tenant A: tenant B = 2: 3 as shown in Table 4. Accordingly, the hypervisor 120 dynamically reassigns the virtual machine queue to the processor that processes the virtual machine queue so that the virtual machine queue is proportional to the total number of virtual machines belonging to the same tenant.

Or the hypervisor 120 may dynamically assign a virtual machine queue to a processor that processes the virtual machine queue so that the virtual machine queue is proportional to the total number of virtual CPUs (vCPUs) used in the virtual machine belonging to the same tenant.

6 and 7 are views for explaining a network virtualization apparatus of a TDVMQ structure that allocates a virtual machine queue and a processor for processing the virtual machine queue when the traffic to the virtual machine increases according to an embodiment of the present invention . FIG. 6 illustrates a system in which traffic for VMQ1 and VMQ2 is increased according to an example, and FIG. 7 illustrates a system after dynamically changing an allocation table between a virtual machine and a processor by a network virtualization apparatus.

As shown in FIG. 6, when the traffic for VMQ1 and VMQ2 increases and the traffic reaches the predetermined upper limit of TDVMQ in the processor LP1, the hypervisor 120 can perform a tenant-based TDVMQ spreading process.

In order to provide the network virtualization function, when the VMQ / LP allocation table is dynamically changed, the hypervisor 120 can restrict the mapping between the VMQ belonging to the same tenant and the processor (LP) belonging to the tenant. That is, the hypervisor 120 adjusts the mapping between the three VMQ1, VMQ2, VMQ3 and the three processors belonging to the tenant A to control the traffic of the processor LP1 belonging to the tenant A, It does not map the processors (LP4, LP5) belonging to and the VMQ belonging to tenant A to each other. Through this, network traffic processing of virtual machines belonging to the same tenant may not be affected by the state of network traffic belonging to other tenants.

The hypervisor 120 performs a tenant-based TDVMQ spreading process to determine VM1, VM2. The VMQ / LP allocation table for VM3 can be changed. For example, the hypervisor 120 may change the VMQ / LP allocation table as shown in Table 5. As shown in Table 5, the hypervisor 120 assigns the virtual machine queue VMQ1 to the processor LP1 and the virtual machine queues VMQ2 and VMQ3 to the processor LP2

 This allows the mapping relationship to be set so that the system has better overall performance.

Figure pat00005

When the hypervisor 120 changes the VMQ / LP allocation table as shown in Table 5, the mapping relationship of the VMQ2 from the existing LP1 to the LP2 is changed as shown in FIG. 7, thereby confirming that the traffic of the LP1 is reduced.

8 is a diagram illustrating a network virtualization apparatus of a TDVMQ structure that allocates a virtual machine queue and a processor for processing the virtual machine queue when the traffic for the virtual machine decreases according to an embodiment of the present invention.

FIG. 8 is a flowchart illustrating an operation of changing the allocation table between the virtual machine and the processor by the network virtualization apparatus dynamically when the traffic to the virtual machine is reduced in the situation of FIG. 7 and the processor LP1 fails to reach a predetermined lower TDVMQ threshold value. System.

The hypervisor 120 performs a tenant-based TDVMQ coalescing process when traffic to the virtual machine is reduced and is less than a predetermined lower TDVMQ threshold value for the processor LP1.

At this time, in order to provide the network virtualization function, the hypervisor 120 can limit the VMQ belonging to the same tenant to the processor mapping belonging to the corresponding tenant. That is, the hypervisor 120 adjusts the mapping between the three VMQ1, VMQ2, VMQ3 and the three processors belonging to the tenant A to control the traffic of the processor LP1 belonging to the tenant A, It does not map the processors (LP4, LP5) belonging to and the VMQ belonging to tenant A to each other. Through this, network traffic processing of virtual machines belonging to the same tenant may not be affected by the state of network traffic belonging to other tenants.

As a result of performing the tenant-based TDVMQ coalescing process, the VMQ / LP allocation table for VM1, VM2, and VM3 can be changed as shown in Table 6 below so that the system can be set to have lower overall power consumption.

Figure pat00006

As shown in Table 6, when the tenant-based TDVMQ coalescing process is performed, all of the virtual machine queues VMQ1, VMQ2, and VMQ3 are allocated to the processor LP2, and the LP1 processor can be changed to the idle state.

Figure 9 is a control flow diagram illustrating tenant-based dynamic processor allocation in accordance with one embodiment of the present invention.

First, the cloud OS creates tenant A and sets priority for tenant A (910).

Then, the cloud OS can send a command to the hypervisor to create virtual machines for tenant A, and the hypervisor creates 920 virtual machines for tenant A according to the instructions of the cloud OS.

The hypervisor extracts the tenant information and the virtual machine information including the priority information of the tenant (930).

The hypervisor can then classify the virtual machine queue for that tenant and the processor that will process that virtual machine queue (940).

The hypervisor may dynamically allocate a virtual machine queue to the processor based on tenant (950). The hypervisor can also be configured to allocate virtual machine queues belonging to the same tenant to the same processor or to an existing VMQ scheme.

In addition, the hypervisor may dynamically allocate virtual machine queues to the processors that process the virtual machine queues so that they are proportional to the total number of virtual machines belonging to the same tenant, or to virtual CPUs (vCPUs) The virtual machine queue may be dynamically allocated to the processor that processes the virtual machine queue to be proportional to the sum of the numbers.

If the TDVMQ upper threshold is exceeded (960), the hypervisor may perform a tenant-based TDVMQ spreading process (970).

On the other hand, if the lower threshold is not lower than the upper threshold of TDVMQ (980), the hypervisor may perform a tenant-based TDVMQ coalescing process (990).

According to another embodiment of the present invention, in order to optimize network traffic processing performance, when the traffic of a virtual machine belonging to one tenant increases and the processor belonging to the same tenant can not process any more, Processor to dynamically map the virtual machine queue and the processor processing the virtual machine queue.

10 is a control flowchart for explaining a TDVMQ extension process according to an embodiment of the present invention.

Assume that traffic to virtual machines belonging to the tenant Ti increases and a situation occurs in which any processor p that processes the virtual machine queue exceeds the TDVMQ maximum threshold (1001).

The hypervisor can check whether the TDVMQ extension can be performed using all the processors that process the virtual machine queue belonging to the tenant Ti (1002).

If it is determined that the TDVMQ extension can be performed using all the processors that process the virtual machine queue belonging to the tenant Ti, the hypervisor performs the TDVMQ expansion process using all the processors that process the machine queues belonging to the tenant Ti The tenant-based TDVMQ extension process is terminated (1003).

On the other hand, if TDVMQ can not be extended using all the processors that process the virtual machine queue belonging to the Tennant Ti, the hypervisor will not be able to determine whether the priority of the tenant Ti is higher than or equal to the priority of the tenant Tj, It is checked if the idle processor q is available (1004). In this case, j and i are not equal.

If the priority of the tenant Ti is higher than or equal to the priority of the tenant Tj, and the idle processor q is available to handle the virtual machine queue belonging to the tenant Tj, then the hypervisor The TDVMQ extension process is performed using the processor and the idle processor q that processes the virtual machine queue belonging to the tenant Tj (1005).

Then, the idle processor q that processes the virtual machine queue belonging to the tenant Tj is marked as belonging to the original tenant Tj (1006), and the tenant-based TDVMQ expansion process is terminated.

On the other hand, if the TDVMQ extension process can not be performed using all the processors that process the virtual machine queue belonging to the Tennant Ti and the idle processor q is not available for all other tenants in the server, It is possible to check whether the TDVMQ reduction process can be performed (1007). In this case, j and i are not equal.

As a result of the check, if the priority of the tenant Ti is higher than or equal to the priority of the tenant Tj, and the TDVMQ shrinking process can be performed on the tenant Tj, then the hypervisor can notify all the processors that process the virtual machine queue belonging to the tenant Tj (1008). ≪ / RTI >

The hypervisor may perform the TDVMQ extension process 1009 using all the processors that process the virtual machine queues belonging to the processor q and the tenant Ti that are the idle processors according to the result of performing the TDVMQ reduction process of the tenant Tj.

The hypervisor indicates (1010) that it belongs to the original tenant Tj for the idle processor q that processes the virtual machine queue belonging to the tenant Tj and ends the tenant-based TDVMQ expansion process.

If the priority of the tenant Ti is not higher than or equal to the priority of the tenant Tj, and the idle processor q is not available to handle the virtual machine queue belonging to the tenant Tj, the hypervisor processes the virtual machine queue belonging to the tenant Ti (1011) whether or not an idle processor q is available for all other tenants in the server,

1011 can not perform the TDVMQ shrink process on all tenants in the server, i.e., it can not perform the TDVMQ extension process using all the processors that process the virtual machine queue belonging to the tenant Ti, If an idle processor q is not available for the tenant and the TDVMQ reduction process can not be performed on all tenant Tj in the server, the tenant based TDVMQ expansion process is terminated.

11 and 12 are views for explaining a tenant-based TDVMQ expansion process when traffic congestion occurs in a processor according to an embodiment of the present invention. FIG. 11 shows a system in a case where traffic congestion occurs in the processor LP2, FIG. 12 shows a system after dynamically changing an allocation table between a virtual machine and a processor by a network virtualization apparatus from the TDVMQ structure of FIG. 11 have.

As shown in FIG. 11, when traffic congestion occurs in the processor LP2, the processor can be expanded in the tenant A according to the tenant-based TDVMQ expansion process of the present invention.

Thus, the hypervisor 120 is capable of extending the processor within Tenant A, in accordance with the tenant-based TDVMQ extension processes 1001 through 1003 of FIG. 10, in accordance with an embodiment of the present invention.

When such an extension process proceeds, VMQ2 is mapped from processor LP2 to processor LP1 in tenant A as shown in Fig.

13 and 14 are views for explaining a tenant-based TDVMQ expansion process when traffic congestion occurs in a processor according to another embodiment of the present invention. FIG. 13 shows a system in a case where traffic congestion occurs in the processor LP4, FIG. 14 shows a system after dynamically changing an allocation table between a virtual machine and a processor by a network virtualization device from the TDVMQ structure of FIG. 13 have.

As shown in FIG. 13, when traffic congestion occurs in the processor LP4, it can not be expanded in the tenant B according to the tenant-based TDVMQ expansion process of FIG. Processors LP4 and LP5 in the tenant B can not be used as expansion processors due to the mapping with virtual machine queues.

However, if the priority of tenant B is higher than or equal to the priority of tenant A, then processors belonging to tenant A can be used. As shown in FIG. 13, since the priority of tenant B is 10 and the priority of tenant A is 5, LP3 of tenant A not mapped to the virtual machine queue can be used for netten B.

Thus, the hypervisor 120 may extend tenant B using the LP3 of tenant A, in accordance with the tenant-based TDVMQ extension processes 1004 through 1006 of FIG. 10 according to an embodiment of the present invention.

As shown in FIG. 14, according to the tenant-based TDVMQ expansion process of the present invention, the processor of the tenant B can be extended to the LP 3 of the tenant A.

If the priority of tenant B is less than the priority of tenant A, the processor extension as shown in Fig. 14 would not have been achieved.

15 to 17 are views for explaining a tenant-based TDVMQ expansion process when traffic congestion occurs in a processor according to another embodiment of the present invention. FIG. 15 is a view showing a system when a traffic congestion occurs in the processor LP1, FIG. 16 is a diagram showing that a tenant B performs a reduction process according to a tenant-based TDVMQ expansion process, FIG. And the tenant A performs the expansion process according to the expansion process.

15, when the traffic congestion occurs in the LP1, the processor LP2 belonging to the tenant A is also mapped to the virtual machine queue according to the tenant-based TDVMQ expansion process, so that the processor in the tenant A can not be expanded.

In addition, processors belonging to tenant B are all mapped to virtual machine queues, so there is no available processor.

However, according to the tenant-based TDVMQ extension process of the present invention, if the priority of tenant A is higher than or equal to the priority of tenant B, it is possible to execute the reduction process for tenant B. That is, it is possible to set a processor belonging to the tenant B to be available by applying a reduction process to the tenant B.

Since the priority of tenant A is higher than the priority of tenant B, the system can extend tenant A by using LP3 of tenant B according to 1009 in the tenant-based TDVMQ extension process 1007 of FIG.

FIG. 16 shows a case where tenant B performs a reduction process according to the tenant-based TDVMQ extension process of the present invention, and FIG. 17 shows a case where tenant A has expanded using LP3.

If the priority of tenant B is higher than the priority of tenant B, even if there is a processor available to tenant B by executing the shrinking process for tenant B, the shrinking process can not be executed for tenant B, The extension process for tenant B is not performed either.

To summarize, according to the present invention, when there is a processor that can be expanded within the same tenant, a processor available to another tenant, or a shrinking process to another tenant, If you do not allow the extension beyond the tenant. Of course, if expansion is allowed, the priority of the tenant will be limited.

In the above-described embodiments, the methods are described on the basis of a flowchart as a series of steps or blocks, but the present invention is not limited to the order of steps, and some steps may occur in different orders or in a different order than the steps described above have. It will also be understood by those skilled in the art that the steps depicted in the flowchart illustrations are not exclusive and that other steps may be included or that one or more steps in the flowchart may be deleted without affecting the scope of the invention You will understand.

The above-described embodiments include examples of various aspects. While it is not possible to describe every possible combination for expressing various aspects, one of ordinary skill in the art will recognize that other combinations are possible. Accordingly, it is intended that the invention include all alternatives, modifications and variations that fall within the scope of the following claims.

Virtual Machine Queue (VMQ)
Dynamic Virtual Machine Queue (DVMQ)
A network interface card (NIC) 110,
A MAC / PHY (Media Access Control & PHYsical layer) processor 111,
A Layer 2 (L2) classifier / sorter 112,
Virtual machine queues (VMQs, VMQ1 through VMQ5)
The hypervisor 120,
A virtual machine unit (130)
A cloud operating system (OS) or controller 150,
Logical Processor (LP)
A virtual switch 121,

Claims (1)

A network interface card having a plurality of virtual machine queues;
One or more virtual machines for each tenant generated based on tenant information including tenant priority information received from the cloud OS;
At least one processor mapped with a virtual machine queue transferred from the network interface card to process the virtual machine queue and a virtual machine switching virtual machine queue to transfer packets of the virtual machine queue to the virtual machine queue, ,
Wherein the hypervisor performs the mapping between the virtual machine queue and the processor for processing the virtual machine queue by each of the tenants.
KR1020150085677A 2015-06-17 2015-06-17 Apparatus and Method for Mapping of Tenant Based Dynamic Processor KR20160148898A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020150085677A KR20160148898A (en) 2015-06-17 2015-06-17 Apparatus and Method for Mapping of Tenant Based Dynamic Processor

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020150085677A KR20160148898A (en) 2015-06-17 2015-06-17 Apparatus and Method for Mapping of Tenant Based Dynamic Processor

Publications (1)

Publication Number Publication Date
KR20160148898A true KR20160148898A (en) 2016-12-27

Family

ID=57736871

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020150085677A KR20160148898A (en) 2015-06-17 2015-06-17 Apparatus and Method for Mapping of Tenant Based Dynamic Processor

Country Status (1)

Country Link
KR (1) KR20160148898A (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190119230A (en) * 2018-04-04 2019-10-22 한국전자통신연구원 Apparatus and method for switching converged data

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190119230A (en) * 2018-04-04 2019-10-22 한국전자통신연구원 Apparatus and method for switching converged data

Similar Documents

Publication Publication Date Title
US11221884B2 (en) Hybrid virtual machine configuration management
US10409628B2 (en) Managing virtual machine instances utilizing an offload device
US10768972B2 (en) Managing virtual machine instances utilizing a virtual offload device
US10554485B2 (en) Method for configuring network, network system, and device
JP6200497B2 (en) Offload virtual machine flows to physical queues
WO2018010654A1 (en) Method, device, and system for virtual machine live migration
WO2015058377A1 (en) Method and device for creating virtual machine
EP4004751B1 (en) Pinned physical memory supporting direct memory access for virtual memory backed containers
US20180246772A1 (en) Method and apparatus for allocating a virtual resource in network functions virtualization network
US9594584B2 (en) Apparatus and method for mapping of tenant based dynamic processor
US11301278B2 (en) Packet handling based on multiprocessor architecture configuration
US20200274820A1 (en) Dynamic provisioning of multiple rss engines
US20220035662A1 (en) Scheduling workloads on a common set of resources by multiple schedulers operating independently
Seth et al. Dynamic threshold-based dynamic resource allocation using multiple VM migration for cloud computing systems
JP2010205208A (en) Host computer, multipath system, and method and program for allocating path
KR102126213B1 (en) Apparatus and Method for Mapping of Tenant Based Dynamic Processor
KR102053765B1 (en) Tenant Based Dynamic Processor Mapping Device and Method for Operating Thereof
KR20160148898A (en) Apparatus and Method for Mapping of Tenant Based Dynamic Processor
KR20170125564A (en) Packet distribution method and apparatus for parallel packet processing
KR20180060353A (en) System and Method for loseless load sharing acceleration and QoS guarantee of Virtual Machines
KR102145183B1 (en) Device and Method for Data Transmission and QoS Guarantee of Virtual Machines in Multicore-based Network Interface Card
Choi et al. Tenant based dynamic processor mapping in the cloud network function virtualization system
Chen et al. Efficient Usage of Network Bandwidth in the Cloud Architecture