KR101916809B1 - Apparatus for placing virtual cluster and method for providing the same - Google Patents

Abstract

A virtual cluster placement method according to an embodiment of the present invention is provided. The virtual cluster placement method includes receiving system information for a virtual cluster system including a plurality of virtual machines, classifying the plurality of virtual machines into subgroups, assigning a plurality of virtual machines And arranging one of the plurality of virtual machines in one of the plurality of hosts in accordance with a relationship attribute between the subgroups or a relation attribute between the plurality of virtual machines in the subgroup. The present invention can provide a virtual cluster placement method and an apparatus for providing the virtual cluster placement method, in which each of a plurality of virtual machines in a virtual cluster can be placed in suitable hosts according to a relationship property to each other.

Description

TECHNICAL FIELD [0001] The present invention relates to a virtual cluster allocating method,

The present invention relates to a virtual cluster placement method and apparatus for providing the same, and more particularly, to a virtual cluster placement method for maximizing placement efficiency of a virtual cluster and an apparatus for providing the same.

In a virtual computing environment based on a virtual machine (VM), virtual machine scheduling is a process of determining a host to which a requested virtual machine is to be placed and operated, and a virtual machine scheduler is a tool performing virtual machine scheduling.

The deployment scheme that determines the hosts on which virtual machines are to be deployed or run depends on the purpose of the hardware resources, the policy, and the quality of the service to be provided to the user. Conventionally, the arrangement of the virtual machines has been performed using a layout method such as FirstFit, RoundRobin, WorstFit, BestFit, and the like.

The arrangement method of a virtual machine is generally composed of a detailed algorithm execution unit of filtering, sorting, and selecting. For example, in the case of OpenStack's FilterScheduler, the hosts that can not accommodate the requested virtual machines in the host list are first filtered, the hosts are sorted according to specific weights in the filtered host list, Select the host. However, in a conventional layout scheme for calculating this best layout result, the layout time can be increased, which can cause a delay in the service response time.

Furthermore, as the virtual computing system evolves, there is an increasing demand for virtual clusters (VCs) that can perform virtual computing using two or more virtual machines. Accordingly, a more efficient arrangement method for creating a plurality of virtual machines is further demanded.

BACKGROUND OF THE INVENTION [0002] Techniques as a background of the invention have been made in order to facilitate understanding of the present invention. And should not be construed as an admission that the matters described in the technical background of the invention are present in the prior art.

Placing virtual machines in a virtual cluster is different from simply placing a plurality of virtual machines sequentially. In the arrangement of virtual machines in a virtual cluster, consideration should be given to distributed placement according to avoidance conditions and integrated placement according to intimacy conditions.

Considering these points, the arrangement of virtual machines is not composed of uniform execution units of filtering, sorting, and selection algorithms, but can be made up of various combinations of algorithm execution units.

However, since the conventional virtual machine arrangement method is not aware of the relation attribute in the virtual cluster at all, it can not implement the combination of various algorithm execution units or perform the arrangement as efficiently as possible according to the situation.

Accordingly, a problem to be solved by the present invention is to provide a virtual cluster placement method capable of implementing various combinations of algorithm execution units in the arrangement of virtual machines to maximize placement efficiency according to a situation, and an apparatus for providing the same .

Another object of the present invention is to provide a virtual cluster arrangement method and a device for providing the virtual cluster arrangement in which each of a plurality of virtual machines in a virtual cluster can be placed in suitable hosts according to the relationship property to each other.

Another object of the present invention is to provide a virtual cluster allocation method and a device for providing a virtual cluster allocation method capable of more efficiently performing a classification of a plurality of virtual machines in a virtual cluster or determining a relation attribute thereof, will be.

The problems of the present invention are not limited to the above-mentioned problems, and other problems not mentioned can be clearly understood by those skilled in the art from the following description.

According to an aspect of the present invention, there is provided a method for arranging virtual clusters according to an embodiment of the present invention. The virtual cluster placement method includes receiving system information for a virtual cluster system including a plurality of virtual machines, classifying the plurality of virtual machines into subgroups, assigning a plurality of virtual machines And arranging one of the plurality of virtual machines in one of the plurality of hosts in accordance with a relationship attribute between the subgroups or a relation attribute between the plurality of virtual machines in the subgroup.

According to another aspect of the present invention, the step of placing one of the plurality of virtual machines in one of the plurality of hosts includes placing a part of the plurality of virtual machines in mutually different hosts among the plurality of hosts.

According to another aspect of the present invention, placing one of the plurality of virtual machines on one of the plurality of hosts includes performing a calculation associated with placement of a plurality of virtual machines via at least one computing module, Wherein each of the at least one calculation module comprises the steps of: (a) handling information about the subgroup; (b) partitioning the subgroup; (c) sorting the host; (d) e) extracting the host; Or (f) performing a user-defined function.

According to another aspect of the present invention, the step of placing one of the plurality of virtual machines in one of the plurality of hosts is performed using a combination of calculation modules that are different from each other according to the relationship property.

According to another aspect of the present invention, the relationship attribute between the subgroups or the relationship attribute between the plurality of virtual machines in the subgroup is distributed or integrated.

According to another aspect of the present invention, a virtual cluster placement method further includes the step of updating the placement map for the virtual cluster system after the step of placing one of the plurality of virtual machines on one of the plurality of hosts, One calculation module is configured to be accessible to the batch map.

According to another aspect of the present invention, placing one of the plurality of virtual machines in one of the plurality of hosts includes selecting the host based on the deployment map to place the virtual machine in one of the plurality of hosts .

According to another aspect of the present invention, the step of classifying a plurality of virtual machines into subgroups includes classifying a plurality of virtual machines into subgroups based on resource requirements of a plurality of virtual machines or based on user-defined .

According to still another aspect of the present invention, the step of classifying a plurality of virtual machines into subgroups is a step of classifying a plurality of virtual machines into subgroups according to a classification criterion, and the classification criterion is a classification history .

According to another aspect of the present invention, the step of determining the relationship attribute between the subgroups or the relationship attribute between the plurality of virtual machines in the subgroup includes: determining, based on the history of the determination of the relationship attribute or the previously stored determination information, Or a relationship attribute between a plurality of virtual machines in a subgroup.

According to another aspect of the present invention, the virtual cluster placement method further includes the step of verifying a relationship attribute between the subgroups or a relationship attribute between the plurality of virtual machines in the subgroup.

According to an aspect of the present invention, there is provided an apparatus for providing a virtual cluster arrangement, the apparatus comprising: a request receiving unit for receiving system information about a virtual cluster system including a plurality of virtual machines; And a placement engine coupled to the request receiver, wherein the placement engine classifies the plurality of virtual machines into subgroups, determines a relationship attribute between the subgroups or a plurality of virtual machines in the subgroup, And one of the plurality of virtual machines is arranged in one of the plurality of hosts in accordance with a relationship attribute between the virtual machines and a relation attribute between the virtual machines in the subgroup.

According to another aspect of the present invention, a placement engine is arranged to place one of a plurality of virtual machines in a plurality of hosts via at least one calculation module, each of the at least one calculation module comprising: (a) (B) partitioning the subgroups; (c) sorting the hosts; (d) filtering the hosts; (e) extracting the hosts; Or (f) performing a user-defined function.

According to another aspect of the present invention, the placement engine is further configured to deploy one of the plurality of virtual machines to one of the plurality of hosts, and then update the deployment map for the virtual cluster system.

According to another aspect of the present invention, a placement engine is configured to place one of a plurality of virtual machines in one of a plurality of hosts by selecting a host based on a placement map so as to place the virtual machine in one of the plurality of hosts do.

The details of other embodiments are included in the detailed description and drawings.

The present invention has the effect of providing a virtual cluster placement method capable of implementing various combinations of algorithm execution units in the arrangement of virtual machines and an apparatus for providing the same, in order to maximize the placement efficiency according to the situation.

In addition, the present invention can provide a virtual cluster placement method and an apparatus for providing the virtual cluster placement method, in which each of a plurality of virtual machines in a virtual cluster can be placed in suitable hosts according to the relationship property to each other.

Furthermore, the present invention provides a virtual cluster placement method and a device for providing the virtual cluster placement method that can more efficiently perform the classification or relational attribute determination of a plurality of virtual machines in a virtual cluster, and verify the same again.

The effects according to the present invention are not limited by the contents exemplified above, and more various effects are included in the specification.

Figure 1 illustrates, by way of example, a block diagram of an apparatus for virtual cluster deployment according to an embodiment of the invention.
FIG. 2 is a schematic flowchart for explaining a virtual cluster arrangement method according to an embodiment of the present invention.
3 is a schematic diagram for explaining a virtual cluster arrangement method according to an embodiment of the present invention.
4A and 4B are schematic diagrams for explaining a specific application example of a virtual cluster arrangement method according to an embodiment of the present invention.
5 is a conceptual diagram for explaining an example in which a virtual cluster including a plurality of virtual machines is arranged in a plurality of hosts in a specific application example of a virtual cluster arrangement method according to an embodiment of the present invention.
FIGS. 6 to 10 are graphs for explaining the processing performance and the performance indexes of the virtual cluster placement method according to an embodiment of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS The advantages and features of the present invention, and the manner of achieving them, will be apparent from and elucidated with reference to the embodiments described hereinafter in conjunction with the accompanying drawings. It should be understood, however, that the invention is not limited to the disclosed embodiments, but is capable of many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, To fully disclose the scope of the invention to those skilled in the art, and the invention is only defined by the scope of the claims.

The shapes, sizes, ratios, angles, numbers, and the like disclosed in the drawings for describing the embodiments of the present invention are illustrative, and thus the present invention is not limited thereto. Like reference numerals refer to like elements throughout the specification. In the following description, well-known functions or constructions are not described in detail since they would obscure the invention in unnecessary detail. Where "includes", "having", "done", etc. are used in the present specification, other portions may be added unless "only" is used. Unless the context clearly dictates otherwise, including the plural unless the context clearly dictates otherwise.

Although the first, second, etc. are used to describe various components, these components are not limited by these terms. These terms are used only to distinguish one component from another. Therefore, the first component mentioned below may be the second component within the technical spirit of the present invention.

Like reference numerals refer to like elements throughout the specification.

It is to be understood that each of the features of the various embodiments of the present invention may be combined or combined with each other partially or wholly and technically various interlocking and driving are possible and that the embodiments may be practiced independently of each other, It is possible.

Figure 1 illustrates, by way of example, a block diagram of an apparatus for virtual cluster deployment according to an embodiment of the invention. Here, a virtual cluster (VC) placement apparatus 100 may be a part of the virtual cluster scheduling framework 1000. The virtual cluster scheduling framework 1000 includes a VC framework for scheduling control requests in response to a control request for a VC and for creating, stopping, resuming, and deleting virtual machines in the VC according to the determined schedule to be. The VC framework is configured to directly control, or directly control, the hosts on which the virtual machines are placed, through an external virtual machine management system.

Referring to FIG. 1, a virtual cluster scheduling framework 1000 includes at least a virtual cluster placement apparatus 100, a VC schedule management unit 200, and an information management unit 300 according to an embodiment of the present invention.

The virtual cluster placement apparatus 100 is a device for placing a plurality of virtual machines in a plurality of hosts in response to a control request for a plurality of virtual machines in a VC. The virtual cluster placement apparatus 100 may be implemented as an independent apparatus, but may be implemented in a computing device for determining hosts to which virtual machines are to be placed so that placement of virtual machines in the VC is completed when a user's VC creation request is generated Lt; / RTI > module.

The VC schedule management unit 200 performs schedule management tasks such as creation, change, and correction of the drive schedule of the VC. The VC schedule management unit 200 is connected to the virtual cluster placement apparatus 100 and transmits a VC control request, for example, a request for generating virtual machines in the VC to the virtual cluster placement apparatus 100. [

The information management unit 300 manages information on the virtual machine and the host. The information management unit 300 provides the virtual cluster placement apparatus 100 with the detailed information of the virtual machine and the host necessary for placement in the virtual cluster scheduling framework 1000. In addition, the information management unit 300 can periodically receive and update detailed information on the virtual machine and the host through the synchronization modules.

The virtual cluster placement apparatus 100 includes a request receiving unit 122, a VC placement engine core 120, an infrastructure resource state calculation unit 110, a resource information providing unit 124, a strategy execution unit 130, (140) and a plurality of calculation modules (150).

The request reception unit 122 receives a VC placement request from various components outside the virtual cluster placement apparatus 100, for example, the VC schedule management unit 200, and transmits various information generated during the VC placement process to the VC schedule management unit 200). The information may include, for example, the VC placement result and whether the placement result is successful or not. The VC placement request received by the request receiver 122 is passed to the VC placement engine core 120 to initiate the VC placement. When the VC placement operation is completed, the placement result is returned to the VC schedule management unit 200.

VC placement engine core 120 is a component that governs the placement of virtual machines within a VC. The VC placement engine core 120 receives various information required for placement from neighboring components such as the request receiving unit 122, the strategy executing unit 130, the infrastructure resource state calculating unit 110 and the like, for example, Host information and virtual machine information. A VC deployment strategy is a method for deploying virtual machines within a VC. The information of the host includes resource information of the physical host, for example, the number of CPU cores, the memory capacity, and the like. The information of the virtual machine includes the number of CPU cores allocated to the virtual machine, the memory capacity, an operating system installed in the virtual machine, and an installed application. The VC placement engine core 120 performs the VC placement requested from the VC user through the strategy execution unit 130 based on the collected information.

The strategy execution unit 130 performs a batch operation according to the VC placement condition using the VC placement strategy, from the VC placement engine core 120 to the placement of the VCs requested. In addition, it provides the VC arrangement engine core 120 with various error conditions that occur in the VC arrangement process, for example, a VC arrangement scheduling unavailable error.

The VC placement strategy management unit 140 supplies a VC placement strategy to the VC placement engine core 120. [ The VC placement strategy management unit 140 manages the life cycle of the VC placement strategy. The VC placement strategy management unit 140 automatically recognizes the dynamic addition, modification, or deletion of the VC placement strategy, detects a change in the VC placement strategy generated by the user, and when the change occurs in the VC placement strategy, Dynamically add, modify, or delete placement strategies.

The resource information providing unit 124 supplies various information required for the VC arrangement performed by the virtual cluster placing apparatus 100, for example, resource and status information for virtual machines in the VC, resources and status information of the hosts And the rack information in which the hosts are arranged to the VC layout engine core 120 and also provides the information to the information management unit 300 so that the information management unit 300 can have the updated information.

The infrastructure resource state calculation unit 110 performs a pre-calculation operation of various information required for VC placement. The infrastructure resource status calculation unit 110 can calculate the host resource status at a specific time point, for example, based on registered VCs and virtual machine schedules. The host resource state at a particular point in time allows the virtual cluster scheduling framework 1000 to be driven based on various time conditions. The virtual cluster scheduling framework 1000 may include, for example, a VC run time scheduling engine (not shown) and may provide the run time scheduling engine with a host resource state at a particular point in time. Accordingly, it is possible to prevent problems such as inability to drive due to insufficient host resources at the time of starting the VC.

The plurality of calculation modules 150 are modules for performing batch operations according to the VC placement strategy. The plurality of calculation modules 150 may include, for example, a VC information handling module, a VC subgrouping module, a VC relationship attribute analysis module, a VC subgroup information handling module, a VC subgroup partitioning module, a host sorting module, An extraction module, a host selection module, a host status update module, a VC layout map update module, a VC table generation module, and a user-defined function module. In accordance with the various VC placement strategies, the plurality of calculation modules 150 can be combined in various ways and are not limited by one embodiment. One of the plurality of virtual machines may be arranged in a plurality of hosts through the combination of the calculation modules 150. [

1, the virtual cluster placement apparatus 100 includes a request receiving unit 122, a VC placement engine core 120, an infrastructure resource state calculation unit 110, a resource information providing unit 124, a strategy execution unit 130 ), A VC placement strategy management unit 140, and a plurality of calculation modules 150, each of which may be designed in one integrated form or in a separate form, according to an implementation method or an embodiment of the present invention It is also possible to implement. That is, all of the elements or modules described herein may be stored in a general-purpose computer or a storage unit disposed in a server and operated by a processor connected thereto.

FIG. 2 is a schematic flowchart for explaining a virtual cluster arrangement method according to an embodiment of the present invention. The description will be made with reference to the constituent elements of the virtual cluster placement apparatus 100 shown in FIG.

The virtual cluster placement method is started when the request reception unit 122 of the virtual cluster placement apparatus 100 receives the VC placement request from the VC schedule management unit 200. [ First, in response to the VC placement request, the VC placement engine core 120 receives system information about the VC system including a plurality of virtual machines from the resource information providing unit 124 (S210). The system information for the VC system includes a list of virtual machines, a list of hosts, a list of racks in which hosts are located, and the like. The list of virtual machines and the list of hosts can be divided into a list of virtual machines for internal virtual computing, a list of virtual machines for shared virtual computing, and a list of hosts. The system information receiving step may involve an initialization step including securing a data storage space for VC placement and initializing various variables.

On the other hand, the VC placement engine core 120 may further include removing the pre-selected hosts from the host list received from the resource information providing unit 124 when the VC placement request is a request for VC migration.

In addition, the VC placement engine core 120 may request the infrastructure resource state calculation unit 110 to calculate the host resource state at the time when the VC is driven, and receive the calculation. In this case, it is possible to prevent a resource shortage problem due to other reserved VCs at the time when the VC is driven.

Next, the VC placement engine core 120 places a plurality of virtual machines in the VC according to the VC placement strategy. The VC placement engine core 120 may use the default VC placement strategy, receive the VC placement strategy from the VC strategy management unit 140, and use the received VC placement strategy.

Hereinafter, the operations of placing virtual machines in the VC according to the VC placement are configured to be performed by the independent calculation module 150. [ For example, placing one of the plurality of virtual machines on one of the plurality of hosts performs calculations associated with placement of the plurality of virtual machines through at least the following calculation module 150 (s). Here, each of the calculation modules 150 may be configured to perform the steps of: handling information about a subgroup, partitioning a subgroup, sorting the host, filtering the host, extracting the host, And performing at least one of the following steps. The plurality of calculation modules 150 can be variously combined, and the calculation modules 150 used according to the VC placement strategy can be different.

In the following, a method of arranging virtual machines in a VC with an exemplary dynamic VC division placement strategy among various VC placement strategies will be described. However, the VC placement strategy is not limited thereto, and may be a static VC division-based placement strategy.

In accordance with the dynamic VC partitioning strategy, a plurality of virtual machines are classified into subgroups (S220). Next, a relationship attribute between the subgroups or a relation attribute between a plurality of virtual machines in the subgroup is determined (S230). Next, one of the plurality of virtual machines is placed in one of the plurality of hosts in accordance with the relationship attribute between the subgroups or the relationship attribute between the plurality of virtual machines in the subgroup (S240).

Next, it is determined whether placement for all the virtual machines is completed (S250), and when all the virtual machines are disposed, the VC placement ends. If all of the virtual machines are not disposed, step S240 is repeated. The step of placing one of the plurality of virtual machines in one of the plurality of hosts can be repeated, for example, by the number of the plurality of virtual machines, and a virtual machine of any size, for example, two or three virtual machines, As shown in FIG.

The placement strategy execution unit 130 can return the placement result to the VC placement core after finishing the placement for the VC for the internal virtual computing resource. When the placement result is successful, the VC placement engine core 120 finally generates a VC placement map and delivers it to the VC schedule management unit 200 in the form of a table. Thereafter, an identifier of the host to be driven is assigned to each of the virtual machines in the requested VC. The VC placement map indicates hosts where VMs and VMs are placed in the VC. The VC layout map is provided for considering various relationship characteristics in the VC. Unlike VM placement, the larger the number of VMs in a VC, the more difficult it is to perform placement with only a single batch calculation. Accordingly, the arrangement of the other VMs can be determined in consideration of the relation in which the VMs in the VC are arranged. The VC placement map can be continuously updated whenever the VM is deployed on the host.

Hereinafter, steps 220 to 250 will be described in detail with reference to Figs. 3 to 5. Fig. 3 is a schematic diagram for explaining a virtual cluster arrangement method according to an embodiment of the present invention. 4A and 4B are schematic diagrams for explaining a specific application example of a virtual cluster arrangement method according to an embodiment of the present invention. 5 is a conceptual diagram for explaining an example in which a VC including a plurality of virtual machines is arranged in a plurality of hosts in a specific application example of a virtual cluster arrangement method according to an embodiment of the present invention.

Referring to FIG. 3, a plurality of operations for determining a host on which virtual machines in a VC are to run are shown. Each of the operations may exist as an independent module as in FIG. 3, but some or all of them may be integrated. The plurality of modules may be comprised of a pre-processing flow, a main processing flow, and a post-processing flow.

First, the preprocessing flow includes a VC information handling module 312, a VC subgrouping module 314, a VC relationship attribute analysis module 316, and a user-defined function module 318. In N1 of the preprocessing step, information about the VC is provided, information about the VC is processed, and the VCs are sub-grouped.

The VC information handling module 312 is a functional module for modifying or changing information on virtual machines in the VC, and the subgrouping module of the VC classifies the virtual machines into specific criteria. The subgroups may be generated by one or more. Here, the specific criteria are not limited, and the subgrouping of the virtual machines may be performed by the user's selection, and may be performed automatically based on the classification history or the stored classification information. The relationship attributes within a subgroup or between subgroups can be determined by extracting and analyzing the characteristics of the virtual machines in the VC. For example, the subgroups can be classified based on the resource requirements of the virtual machine. Further, the step of verifying the classification of the subgroup according to a predetermined criterion can be further included.

In the VC relationship property analysis module 316, the relation attributes between the virtual machines in the sub-group or the sub-group in the VC are determined. Relationship attributes are concerned with whether integration or distributed deployment between virtual machines at the host / rack / service area level is required. The relationship attribute is divided into an integrated layout in which a plurality of virtual machines are arranged in the same host and a distributed layout in which each of a plurality of virtual machines is arranged in different hosts, according to matters to be considered in placing virtual machines in the VC. The determined relationship attributes are used in the main process flow. The relationship attribute may be determined by the user's selection, and may be automatically determined based on the classification history or the previously stored classification information. For example, the relationship attributes within a subgroup or between subgroups can be determined by extracting and analyzing the characteristics of the virtual machines in the VC. The user-defined function module 318 may be configured to perform functions related to other subgroups. Furthermore, the relationship attribute can be verified according to a predetermined criterion.

Referring to FIG. 4A, VC MyHadoopVC includes five virtual machines 440. Among the virtual machines 440, NameNode_JobTrackers 441 and 442 are classified into a subgroup Master, and DataNode_TaskTrackers 443, 444, and 445 are classified into a subgroup Slave01. The relation attributes of NameNode_JobTrackers 441 and 442 in the subgroup Master are distributed and the relation attributes of DataNode_TaskTrackers 443, 444 and 445 in the subgroup Slave01 are integrated. The relationship attribute between subgroup Master and subgroup Slave01 is distributed.

These relationship attributes can be identified and stored using, for example, XML. Referring to FIG. 4B, the id of the VC is MyHadoop and the id of the subgroup in the VC is Master and Slave01, respectively. The subgroups are grouped in a distributed arrangement. In FIG. 4B, an exemplary distribution arrangement is indicated as Availability. The relational attributes in the subgroup Master are distributed and the virtual machines NameNode_JobTracker01 and NameNode_JobTracker02 in the subgroup Master have relationship attributes that allow them to be mounted on different hosts accordingly. The relationship attributes within the subgroup Slave01 are in an integrated arrangement and are illustratively represented by Affinity_BestEffort. The virtual machines DataNode_TaskTracker01, DataNode_TaskTracker02, DataNode_TaskTracker03 in the subgroup Slave01 have relationship attributes that allow them to be mounted on the same host as possible.

Referring back to FIG. 3, data and relationship attributes for subgroups at N2 are used in the main process flow. In the main process flow, a VC subgroup information handling module 321 for selectively performing information modification sorting on a subgroup basis may be included. Also included in the dynamic VC partitioning strategy is a VC subgroup partitioning module 322. The VC subgroup partitioning module 322 calculates a partition size for placing virtual machines in the VC on a specific host. Additionally, if a VC subgroup partitioning module 322 is included, as many virtual machines as the determined VC partition size can be deployed to a particular host.

In addition, a host ordering module 323 for sorting the hosts in the host list based on the set criteria, a host filtering module 324 for filtering the hosts based on the set criterion, a host extraction module 325 for extracting hosts based on the set criterion, A user-defined function module 326 associated with the main process flow may be included in the main process flow. In N3, data for the subgroup of VCs, relationship attributes, partition size of the VC subgroup, and list of filtered / extracted / sorted hosts are provided.

Next, in the main process flow, the host selection module 327 selects a specific host to which the virtual machine is to be placed in the host list. The host selection module 327 determines, based on the provided information, the host where the virtual machine is to be placed at the time when the host selection module is driven. Next, the host state update module 328 updates the resource and state information of the host based on the information about the virtual machine in the VC determined by the host to be driven after the placement of the virtual machine. In the main process flow, only the host selection module 327 and the host status update module 328 described above may be configured.

Next, in the post-process flow, the VC batch termination checking module 331 which determines whether all the hosts to be placed for all the virtual machines in the VC requested in the batch scheduling have been calculated determines whether or not the batch is terminated. If there are still virtual machines to be placed, the VC placement map update module 332 updates the map of the virtual machines placed in the VC, and provides the map to the main scaling processing modules. Thereby, the main processing flow is repeated again at N2. That is, the modules of the main process flow are configured to be accessible to the updated batch map. Accordingly, the host selection module 327 selects a host based on the deployment map so that the virtual machine is placed in one of the plurality of hosts in accordance with the relationship attribute. As the placement of virtual machines is repeated, virtual machines may be placed on the same host or on different hosts depending on the relationship attributes. When the placement of all the virtual machines in the VC is completed, the VC placement map generation module 333 generates the VC placement table, and the execution of the VC placement strategy is terminated.

 Referring to FIG. 5, hosts 510, 520, 530 in which a plurality of virtual machines 430 are located are shown. DataNode_TaskTracker01 443, DataNode_TaskTracker02 444 and DataNode_TaskTracker03 445 are located in different hosts 510 and 520, respectively, according to the relationship attributes in FIGS. 4A and 4B, NameNode_JobTracker01 441 and NameNode_JobTracker 02 442 are located in different hosts 510 and 520, (530) but is different from NameNode_JobTracker01 (441) and NameNodeJobTracker02 (442).

According to the virtual cluster placement method according to an embodiment of the present invention, the virtual machines of the VC can be arranged and arranged so as to perform an optimized operation according to their operating characteristics. In addition, a virtual cluster placement method can be performed with a combination of independent calculation modules according to various VC placement strategies. Further, the application of the VC is not limited, and may include Hadoop, R, and the like.

FIGS. 6 to 10 are graphs for explaining the processing performance and the performance indexes of the virtual cluster placement method according to an embodiment of the present invention.

6-10 show performance indicators such as processing performance, service latency, resource utilization rate and batch calculation time, which are shown by various VC placement algorithms that can be implemented in the VC placement framework through experiments.

For this experiment, we implemented a simulator to simulate the virtual cluster service environment. In the simulator, various quantitative conditions (VC scale, VM specification) for VC to be used by VC users (individual or group) in a medium - sized inner cloud (PrivateCloud) And virtual cluster is created / used / destroyed based on the simulation result. Each virtualized host used in the experiment has a hardware resource specification of 64GB of memory on a 32-core CPU. Therefore, the virtual computing service environment in this experiment provides users with a total of 64,000 CPU cores and 128,000GB of memory capacity.

The placement strategies applied for this experiment are three kinds of VC placement strategies (FirstFit-VM, NextFit-VM, and Volume-VM) based on the existing placement method of virtual machine unit and the virtual cluster arrangement according to one embodiment of the present invention (FirstFit-VC, NextFit-VC, and Volume-VC) based on the dynamic virtual cluster partition arrangement, which is one embodiment of the method.

Dynamic VC partition-based deployment strategies dynamically partition VCs during placement and perform deployment. For example, in the case of FirstFit-VC, after finding the first available host, the number of virtual machines that can be allocated to the host is determined as the VC partition size, do.

The Volume-VM and Volume-VC placement strategy is a type of Worst-Fit placement algorithm among the bin-packing placement algorithms. After scoring the available resources for each host, the highest score host The virtual machine of the virtual cluster being arranged in the virtual cluster is determined and placed. The formula used in the host scoring process utilized the host scoring formula developed by TimothyWood. The difference between a Volume-VM deployment strategy and a Volume-VC deployment strategy is whether or not to deploy the virtual machines to the highest score host. That is, in the case of Volume-VM, when a host having the highest score is found, one of the virtual machines in the virtual cluster being placed on the host is determined for placement, and the host scoring process is performed again. When the host having the highest score is found, the number of virtual machines that can be placed on the host is calculated. Then, the virtual machines are placed as many as the number of deployable virtual machines, and then the host scoring process is performed again.

In this experiment, VC users can designate the VC scale from 2 to 256, with an N power of 2. In the VC, the VM specification is 1 to 8 for the CPU, 1 GB to 16 GB for the memory resource Memory can be specified up to.

In addition, VC users take a certain amount of time and then return resources that are in use to the virtual computing facility through termination of the virtual cluster. VC generation requests are accumulated in the waiting queue of the FIFO structure, and virtual cluster placement and allocation are performed through the FCFS method. Therefore, after a certain period of time has elapsed after the simulation starts, due to a shortage of resources, new VC users wait until the VC users occupying resources ahead of them return resources, thereby increasing waiting time.

It is assumed that the size of the virtual cluster requested by the VC users, the specification of the virtual machine in the virtual cluster, the usage time and the inter-arrival time follow the uniform distribution, so that the VC use request is uniformly formed for each condition Experiments were designed and implemented to use virtual cluster services. In this experiment, it is assumed that it is used and terminated for a given usage time, and when a given computing resource is actively used, it is assumed that a CPU-intensive processing operation is performed in a virtual cluster to be generated. Because of the CPU load and the network load of the management virtual machine (ManagementVM or Dom0) running on each host according to the virtualization software when the network intensive processing is performed, the CPU of the user virtual machine (User VM or DomU) This can affect the use of major computing resources. In this context, it is assumed that the management virtual machine of each host maintains a state that does not cause a load so as to have a high effect on the CPU usage of the user virtual machine. This experiment was repeated 30 times for each batch algorithm, and the result was calculated.

FIG. 6 shows throughputs according to the number of VC use requests (number of workloads) requested per minute per VC placement strategy, and FIG. 7 shows the response time of service. Referring to FIGS. 6 and 7, conventional VC placement strategies for performing VM-based placement scheduling have generally shown a sharp increase in service response time from the time of 14 to 18 VC usage requests per minute, Respectively. In particular, the Volume-VM deployment strategy showed the lowest throughput performance and showed a dramatic increase in service response times for more than 14 VCs (840 per hour) requests per minute. FirstFit-VM and NextFit-VM each increase the service response time to less than 5 minutes from the time when 16 VC requests per minute are generated, and then increase to about 8 minutes and 15 minutes respectively from 18, , There was a sharp increase in service response time. In addition, the throughput was limited from 18 points per minute mentioned above.

The deployment strategies implemented with the virtual cluster placement method according to an embodiment of the present invention showed the limit of the throughput per minute from the point of time when 20 to 24 VC usage requests per minute occurred. In particular, the Voluem-VC deployment strategy corresponding to the Volume-VM deployment strategy starts to increase the service response time from 18 points per minute, and when 20 or more minute VC usage requests arrive from 20, Respectively. FirstFit-VC deployment strategy and NextFit-VC deployment strategy start to show a slight increase in service response time when 20 VC usage requests arrive per minute. From 22 VCs, The response time increases and the throughput per minute is limited.

For the throughput per minute, the FirstFit-VC deployment strategy and the NextFit-VC deployment strategy showed about 17% performance difference compared to the existing deployment strategies compared to the FirstFit-VM deployment strategy and NextFit-VM deployment strategy. The volume-VC placement strategy showed about 46% difference in processing performance compared to Volume-VM placement strategy, showing the largest processing performance difference among the corresponding placement strategies.

FIG. 8 shows the resource utilization rate by the VC placement strategy, and the resource utilization rate is calculated by the average of CPU and memory resource usage. The resource utilization rate is similar to the throughput per minute shown in FIG. Therefore, it can be seen that the difference in throughput per minute, which is one of the performance indicators, occurs due to the difference in resource utilization rate among various influencing factors. Furthermore, the FirstFit-VC deployment strategy, NextFit-VC deployment strategy, and F's existing FirstFit-VM deployment strategy and NextFit-VM deployment strategy showed comparable throughput, resource utilization, and service response times. VC and Volume Next-V and NextFit-VM showed a difference of about 23% between per-minute throughput, ie, Volume-VC and Volume- The VM showed a difference in throughput of about 43% per minute.

The main reason for the difference in performance between deployment strategies is that, as mentioned above, the cause of resource utilization can be found. For the additional reason, in the case of the placement strategy based on the dynamic VC division implemented by the virtual cluster placement method according to an embodiment of the present invention, even if based on the same placement strategy idea, The faster batch can be performed. 9 shows the batch processing time according to the VC size according to the VC placement strategy. The difference in placement time between the placement strategies using the dynamic VC partitioning function of the virtual cluster placement method according to one embodiment of the present invention and the corresponding single virtual machine placement strategies becomes larger as the virtual cluster size becomes larger.

When the size of the virtual cluster is small, the placement strategies of the virtual cluster placement method according to an embodiment of the present invention do not have a large difference in placement speed compared with the placement plans of a single virtual machine. However, The difference in deployment time started to increase and the difference in deployment time occurred up to 3 times (compared to Volume-VM and Volume-VC) when the virtual cluster size reached 256.

Figure 10 shows the VC partition sizes for each placement strategy while processing the number of requests per minute 22, virtual cluster size 256. As can be seen from FIG. 10, among the various factors affecting the batch processing time, the difference in virtual cluster partition size is an important factor affecting the placement speed. For single virtual machine unit deployment strategies, the virtual cluster partition size is 1 as designed in the deployment strategy, while 1.4 for FirstFit-VC, 1.7 for NextFit-VC, and 2.9 for Volume-VC. By default, if the virtual cluster partition size is greater than 1, the number of deployments is reduced by half, so Volume-VC is about 3 times larger than Volume-VM, a single virtual machine deployment strategy. The reason why the batch scheduling processing time is about three times as fast as the size is explained.

It is important to consider the virtual cluster partition size in batch scheduling even under the same deployment strategy and deployment mechanism, because it is very important to improve batch processing time for medium and large virtual clusters.

This improvement in batch processing time is not only meaningful for speeding up batching. Improvement in batch processing time is a fundamental factor for shortening deployment time to provide faster service for virtual clusters of various sizes in a large virtual computing environment (or facility), and can also affect resource availability. In a situation where virtual cluster users return resources they have used after a certain period of time and reallocate them to new virtual cluster users based on the returned resources, it is necessary to maintain a certain level by improving the resource utilization rate faster through quick deployment. Time improvement can be one of the factors that contribute to the improvement of resource utilization rate.

In the environment where computing resources are continuously expanded due to continuous addition of virtual computing resources (host expansion, etc.), fast reallocation of resources returned after use and quick allocation of newly added resources must be simultaneously performed Batch processing time improvement will become even more important. The virtual cluster placement method according to an embodiment of the present invention can realize various placement models of virtual machines in virtual clusters in addition to improving virtual cluster placement processing time.

Although the embodiments of the present invention have been described in detail with reference to the accompanying drawings, it is to be understood that the present invention is not limited to those embodiments and various changes and modifications may be made without departing from the scope of the present invention. . Therefore, the embodiments disclosed in the present invention are intended to illustrate rather than limit the scope of the present invention, and the scope of the technical idea of the present invention is not limited by these embodiments. Therefore, it should be understood that the above-described embodiments are illustrative in all aspects and not restrictive. The scope of protection of the present invention should be construed according to the following claims, and all technical ideas within the scope of equivalents should be construed as falling within the scope of the present invention.

Claims (16)

Receiving system information for a virtual cluster system including a plurality of virtual machines;
Classifying the plurality of virtual machines into subgroups considering resource requirements of the plurality of virtual machines;
Determining a relationship attribute between the subgroups and a relationship attribute between a plurality of virtual machines in the subgroup, wherein the relationship attribute includes a plurality of virtual machines in the subgroup, Determining a relational attribute, which is a distributed or integrated deployment of virtual machines; And
One of the subgroups is allocated to one of the plurality of hosts in consideration of a relationship attribute between the subgroups, a relation attribute between the plurality of virtual machines in the subgroup, and a division size of the subgroup, Placing a portion of a plurality of virtual machines in hosts different than one of the plurality of hosts,
Wherein the relationship attribute is a host or rack or service area level. delete The method according to claim 1,
Wherein placing one of the subgroups in one of the plurality of hosts or placing a portion of the plurality of virtual machines in the subgroup in hosts different from one of the plurality of hosts comprises: Performing a computation associated with the group or placement of some of the virtual machines in the subgroup,
Wherein each of the at least one calculation module comprises:
(a) handling information about the subgroup;
(b) partitioning the subgroup;
(c) aligning the host;
(d) filtering the host;
(e) extracting the host; or
and (f) performing a user-defined function. The method of claim 3,
Wherein placing one of the subgroups in one of the plurality of hosts or placing a portion of the plurality of virtual machines in the subgroup in hosts different from one of the plurality of hosts comprises: A method of virtual cluster placement, wherein the virtual cluster placement is performed using a combination of modules. delete The method of claim 3,
After placing one of the subgroups in one of the plurality of hosts or placing some of the plurality of virtual machines in the subgroup in hosts different from one of the plurality of hosts, Further comprising the step of updating the map,
Wherein the at least one computing module is configured to be accessible to the deployment map. The method according to claim 1,
After placing one of the subgroups in one of the plurality of hosts or placing some of the plurality of virtual machines in the subgroup in hosts different from one of the plurality of hosts, Further comprising the step of updating the map. 8. The method of claim 7,
Wherein placing one of the subgroups in one of the plurality of hosts or placing a part of the plurality of virtual machines in the subgroup in hosts different from one of the plurality of hosts comprises: Selecting a host based on the placement map to place a portion of the plurality of virtual machines in one of the plurality of hosts. delete The method according to claim 1,
Wherein the step of classifying the plurality of virtual machines into subgroups comprises:
And considering the classification history or the previously stored classification information, in addition to the resource requirements of the plurality of virtual machines. The method according to claim 1,
Wherein determining a relationship attribute between the subgroups or a relationship attribute between a plurality of virtual machines in the subgroup comprises:
Determining a relationship attribute between the subgroups or a relationship attribute between a plurality of virtual machines in the subgroup according to a history of the determination of a relationship attribute or previously stored decision information. 12. The method of claim 11,
Further comprising verifying a relationship attribute between the subgroups or a relationship attribute between a plurality of virtual machines in the subgroup. A request receiving unit for receiving system information about a virtual cluster system including a plurality of virtual machines; And
And a placement engine coupled to the request receiver,
Wherein the placement engine comprises:
Classifying the plurality of virtual machines into subgroups considering resource requirements of a plurality of virtual machines,
After classifying the plurality of virtual machines into subgroups, determining a relationship attribute between the subgroups and a relation attribute between a plurality of virtual machines in the subgroup,
Wherein the relational attribute is a distributed or integrated placement of a plurality of virtual machines in a subgroup,
One of the subgroups is allocated to one of the plurality of hosts in consideration of a relationship attribute between the subgroups, a relation attribute between the plurality of virtual machines in the subgroup, and a division size of the subgroup, To place some of the plurality of virtual machines in hosts different from one of the plurality of hosts, and
Wherein the relationship attribute is a host or rack or service area level. 14. The method of claim 13,
Wherein the placement engine is arranged to place one of the subgroups in a plurality of hosts via at least one computing module or to place a part of the plurality of virtual machines in the subgroup in hosts different from one of the plurality of hosts ,
Wherein each of the at least one calculation module comprises:
(a) handling information about the subgroup;
(b) partitioning the subgroup;
(c) aligning the host;
(d) filtering the host;
(e) extracting the host; or
and (f) performing a user-defined function. < Desc / Clms Page number 21 > 14. The method of claim 13,
Wherein the placement engine places one of the subgroups in one of a plurality of hosts or places some of the plurality of virtual machines in the subgroup in hosts different from one of the plurality of hosts, And to update the deployment map for the virtual cluster. 16. The method of claim 15,
Wherein the placement engine selects one of the subgroups based on the placement map so that a portion of the plurality of virtual machines in the subgroup or subgroup is located in one of the plurality of hosts, Or place some of the plurality of virtual machines in the sub-group in hosts that are different from one of the plurality of hosts.

Images