WO2025177500A1 - System, method and program for managing virtualization infrastructure - Google Patents

Abstract

The present invention continuously provides a high-priority service on a virtualization infrastructure even when a failure occurs in any of a plurality of infrastructure constituent devices constituting the virtualization infrastructure, and all physical resources in the infrastructure constituent device in which the failure has occurred stop operation. This system comprises: an information storage unit that stores information relating to physical resources of the entire cluster in which a plurality of workloads constructed on a virtualization infrastructure can operate, and information relating to the respective physical resources of a plurality of infrastructure constituent devices; and an information processing unit that classifies a plurality of services provided by the cluster into a plurality of service groups having different priorities, and for each of the plurality of respective service groups, arranges the plurality of workloads to be executed in the cluster and manages the physical resources required for the respective service groups on the basis of the information relating to the physical resources of the entire cluster and the information relating to the respective physical resources of the plurality of infrastructure constituent devices.

Description

System, method and program for managing virtualization infrastructure

The present invention relates to the management of a virtualization platform on which virtual machines can be built.

Conventionally, a virtualization platform for building virtual machines, consisting of multiple racks each containing multiple physical servers (physical resources), has been known (see, for example, Patent Document 1).

International Publication No. 2011/043317

If a failure occurs in one of the racks, which are multiple infrastructure-component devices that make up the virtualization infrastructure (for example, a failure in the power supply installed in each rack), all physical servers (physical resources) in the failed rack will stop operating, and processing (for example, service provision) by virtual machines built on the virtualization infrastructure may become impossible. Note that similar issues can also arise when a virtualization infrastructure is configured with multiple container-type data centers (infrastructure-component devices).

A system according to one aspect of the present invention is a system for managing a virtualization infrastructure comprising multiple infrastructure component devices, each having multiple physical resources. This system comprises an information storage unit that stores information on the overall physical resources of a cluster on which multiple workloads constructed on the virtualization infrastructure can run, and information on the physical resources of each of the multiple infrastructure component devices; and an information processing unit that classifies multiple services provided by the cluster on which multiple workloads constructed on the virtualization infrastructure can run into multiple service groups with different priorities, and, for each of the multiple service groups, allocates the multiple workloads executed on the cluster and manages the physical resources required by the service group based on the information on the overall physical resources of the cluster and the information on the physical resources of each of the multiple infrastructure component devices.

The system may also include a control unit that, when a failure occurs in one of the multiple infrastructure component devices, checks the priority of the service groups to which each of the multiple workloads running on the failed infrastructure component device belongs, and if it is confirmed that a workload of a service group with a priority equal to or higher than a predetermined priority was running on the failed infrastructure component device, stops the workload of the low-priority service group running on the non-failed infrastructure component device, and controls the system to restart the workload of the high-priority service group running on the failed infrastructure component device using the physical resources freed by the stopping of the workload on the non-failed infrastructure component device.

In the system, the information processing unit may calculate, for each resource component, the physical resources that can be used in the event of a failure in an infrastructure component device with the largest physical resources among the plurality of infrastructure component devices, based on information about the physical resources of each of the plurality of infrastructure component devices, and determine the predetermined priority based on the calculation results for each resource component of the available physical resources, information about each resource component of the physical resources corresponding to each of the plurality of priorities, and the competitive allocation setting conditions for each resource component.

In the system, the information processing unit may provide the user with impact information in the event that a failure occurs in the infrastructure component device with the greatest physical resources among the plurality of infrastructure component devices.

A method according to another aspect of the present invention is a method for managing a virtualization infrastructure comprising a plurality of infrastructure component devices each having a plurality of physical resources. This method includes storing information about the overall physical resources of a cluster on which a plurality of workloads constructed on the virtualization infrastructure can run, and information about the physical resources of each of the plurality of infrastructure component devices; classifying a plurality of services provided by the cluster on which a plurality of workloads constructed on the virtualization infrastructure can run into a plurality of service groups with different priorities; and, for each of the plurality of service groups, allocating a plurality of workloads to be executed on the cluster and managing the physical resources required by the service group based on the information about the overall physical resources of the cluster and the information about the physical resources of each of the plurality of infrastructure component devices.

The method may include, when a failure occurs in one of the multiple infrastructure component devices, checking the priority of the service groups to which each of the multiple workloads running on the failed infrastructure component device belongs; and, if it is confirmed that a workload of a service group with a priority equal to or higher than a predetermined priority was running on the failed infrastructure component device, stopping the workload of the low-priority service group running on the non-failed infrastructure component device; and restarting the workload of the high-priority service group running on the failed infrastructure component device using the physical resources freed by stopping the workload on the non-failed infrastructure component device.

The method may include calculating, for each resource component, the physical resources that can be used in the event of a failure in an infrastructure component device with the largest physical resources among the plurality of infrastructure component devices, based on information about the physical resources of each of the plurality of infrastructure component devices; and determining the predetermined priority based on the calculation results for each resource component of the available physical resources, information about each resource component of the physical resources corresponding to each of the plurality of priorities, and competitive allocation setting conditions for each resource component.

The method may also include providing the user with impact information in the event that a failure occurs in the infrastructure component device with the greatest physical resources among the plurality of infrastructure components.

A program according to yet another aspect of the present invention is a program executed by a computer or processor provided in a system that manages a virtualization infrastructure that includes multiple infrastructure-component devices, each having multiple physical resources. This program includes program code for storing information about the overall physical resources of a cluster on which multiple workloads constructed on the virtualization infrastructure can run, and information about the physical resources of each of the multiple infrastructure-component devices; program code for classifying multiple services provided by the cluster on which multiple workloads constructed on the virtualization infrastructure can run, into multiple service groups with different priorities; and program code for allocating multiple workloads to be executed on the cluster and managing the physical resources required by the service group for each of the multiple service groups, based on the information about the overall physical resources of the cluster and the information about the physical resources of each of the multiple infrastructure-component devices.

The program may include program code for, when a failure occurs in one of the multiple infrastructure component devices, checking the priority of the service groups to which each of the multiple workloads running on the failed infrastructure component device belongs; program code for stopping workloads of low-priority service groups running on the non-failed infrastructure component device when it is confirmed that workloads of high-priority service groups with a priority equal to or higher than a predetermined priority were running on the failed infrastructure component device; and program code for restarting workloads of high-priority service groups running on the failed infrastructure component device using physical resources freed by the stopping of the workloads on the non-failed infrastructure component device.

The program may include program code for calculating, for each resource component, the physical resources available for use in the event of a failure in an infrastructure component device with the greatest number of physical resources among the plurality of infrastructure component devices, based on information about the physical resources of each of the plurality of infrastructure component devices; and program code for determining the predetermined priority based on the calculation results for each resource component of the available physical resources, information about each resource component of the physical resources corresponding to each of the plurality of priorities, and competitive allocation setting conditions for each resource component.

The program may include program code for providing users with impact information in the event that a failure occurs in the infrastructure component device with the greatest physical resources among the plurality of infrastructure components.

In the system, method, and program, the physical resource may be a physical server, and the infrastructure component device may be a rack having multiple physical servers and a power supply.

In the system, method, and program, the physical resource may be a rack having multiple physical servers, and the infrastructure component device may be a container-type data center having multiple racks and a power source.

The program may include a machine-learned model.

The virtualization platform may be used, for example, in a data center, or in a RIC (RAN Intelligent Controller) used in the RAN (Radio Access Network) of a mobile communications system.

According to this invention, even if a failure occurs in one of the multiple infrastructure component devices that make up the virtualization infrastructure and all physical resources within the failed infrastructure component device stop operating, high-priority services can continue to be provided on the virtualization infrastructure.

FIG. 1 is a schematic diagram showing an example of the overall configuration of a virtualization platform to which a system according to an embodiment can be applied. FIG. 2 is an explanatory diagram showing an example of a failure occurring in a single physical server in a virtualization infrastructure according to a reference example. FIG. 3 is an explanatory diagram illustrating an example of a rack-scale failure occurring in the virtualization platform according to the embodiment. FIG. 4 is an explanatory diagram illustrating an example of the allocation of workloads with multiple priorities in a virtualization platform according to the embodiment. FIG. 5 is an explanatory diagram illustrating an example of the placement of workloads with multiple priorities when a rack-scale failure occurs in the virtualization platform according to the embodiment. FIG. 6 is an explanatory diagram illustrating an example of the configuration of a management system that manages a virtualization infrastructure according to the embodiment. FIG. 7 is a flowchart showing an example of generating a resource-related table of a virtual environment in the virtualization infrastructure according to the embodiment. FIG. 8 is a flowchart showing an example of generating a physical resource-related table in the virtualization platform according to the embodiment. FIG. 9 is a flowchart illustrating an example of calculation of the priority of a service group that restarts a workload when a rack-scale failure occurs in the virtualization platform according to the embodiment.

Hereinafter, an embodiment of the present invention will be described with reference to the drawings.
An example of a system according to an embodiment described herein defines service group units and priorities for each service group for resources of workloads running in a virtual environment on a virtualization platform, and when a resource situation makes it difficult to start all workloads (service groups) due to a failure of a platform component device (rack), etc., the system stops workloads of low-priority service groups and controls so that workloads of high-priority service groups can be started. In addition, the control involves defining and managing resource components (CPU (Central Processing Unit), memory, GPU (Graphics Processing Unit)) of physical resources consumed by each service group and competitive allocation settings for physical resources (e.g., allocating four virtual CPUs to one physical CPU actually installed in a physical server).

In particular, the virtualization infrastructure managed by the system of this embodiment can be used in the RIC (RAN Intelligent Controller) used in the RAN (Radio Access Network) of a mobile communications system.

FIG. 1 is a schematic diagram showing an example of the overall configuration of a virtualization platform to which a system according to an embodiment can be applied. In FIG. 1, the virtualization platform 10 comprises racks 110, 120, and 130 as multiple platform-constituting devices. The racks 110, 120, and 130 each have physical servers (also referred to as "physical hosts") 111, 121, and 131 as multiple physical resources. In the example of FIG. 1, the multiple physical servers 111, 121, and 131 (24 in the illustrated example) contained in the racks 110, 120, and 130 form a cluster, which is a unit of a group in which workloads such as virtual machines (VMs) or containers can run.

In the example of FIG. 1, the virtualization platform 10 is composed of three racks 110, 120, and 130, but the virtualization platform 10 may also be composed of two racks or four or more racks. Furthermore, the racks 110, 120, and 130 each have eight physical servers 111, 121, and 131, respectively, but the number of physical servers each rack 110, 120, and 130 may have may be one to seven, or nine or more. Furthermore, the number of physical servers each rack 110, 120, and 130 may have may differ from each other.

A cluster capable of running multiple workloads on the virtualization platform 10 is constructed using multiple racks 110, 120, and 130, with workloads such as virtual machines (VMs) or containers running on multiple physical servers 111, 121, and 131. Each of the multiple racks 110, 120, and 130 also has other devices such as a switch 112. Each of the multiple racks 110, 120, and 130 may have a power supply that supplies power to the multiple physical servers 111, 121, and 131.

In the virtualization platform 10 configured as described above, if a failure occurs in a single physical server 111' in one rack 110 (in the example of FIG. 2, the physical server at the bottom of the rack 110), for example, as shown in FIG. 2, the workload that was running on the failed physical server 111' can be restarted on another physical server in the cluster. Therefore, the entire cluster only needs to have surplus resources equivalent to one physical server.

However, rack-scale failures can occur in a virtualization platform 10 configured as described above. For example, as shown in Figure 3, if a failure occurs in the power supply system of one rack 110, all physical servers 111 within the rack 110 will go down. When a rack-scale failure occurs, there is nowhere to move the large number of workloads that were running on all physical servers 111' within the rack 110, and these workloads cannot be started, affecting the services provided. While it is possible to start all workloads that were running on all physical servers 111' in the rack 110 on physical servers in other racks, this would require a huge amount of surplus resources and would be unrealistic. For example, the entire cluster would require surplus resources equivalent to one rack. For this reason, rack failures are generally not included in failure cases.

The most likely scenario for a rack failure is one resulting in an interruption in the power supply, or a power system failure. Because the power systems of typical data centers are very stable due to multiple system connections, the installation of UPS (uninterruptible power systems), and in-house power generation, power system failures are often considered negligible. However, in recent years, with the emergence of container-type data centers and other technologies, it has become practical to make data centers more compact, and power system failures are no longer negligible. Even in the event of a power system failure, it is desirable to continue providing services as much as possible (by restarting the necessary workloads on the virtualization platform). While one option for preparing for such cases is to make workloads redundant using load balancers, a single configuration without redundancy has the advantage of being able to provide services with minimal resources and simplifying data sharing.

In this embodiment, the multiple services provided by a cluster built on the virtualization platform 10, which can run multiple workloads, are classified into multiple service groups with different priorities. Based on information about the physical servers (physical resources) 111, 121, and 131 of the entire cluster and information about the physical servers (physical resources) 111, 121, and 131 of each of the multiple racks (platform configuration devices) 110, 120, and 130, the placement of the multiple workloads executed in the cluster and the management of the physical servers (physical resources) 111, 121, and 131 required by the service group are performed for each of the multiple service groups. This workload placement and management of the physical servers (physical resources) for each of the multiple service groups makes it possible to continue providing high-priority services on the virtualization platform 10, even if a failure occurs in one of the multiple racks 110, 120, and 130 that make up the virtualization platform 10, causing all physical servers in the failed rack to stop operating.

FIG. 4 is an explanatory diagram showing an example of the arrangement of workloads with multiple priorities in the virtualization platform 10 according to the embodiment. In FIG. 4, the workloads running on the physical servers 111(1) to 111(3), 121(1) to 121(3), and 131(1) to 131(3) of the racks 110, 120, and 130 are indicated by square blocks 201A to 201C, 202A to 202C, and 203A to 203C. The symbols A, B, and C in each workload block indicate the priority of each service group. Priority A is the highest priority, Priority B is the second highest priority, and Priority C is the lowest priority. In the example of FIG. 4, four workloads can be started per physical server 111(1) to 111(3), 121(1) to 121(3), and 131(1) to 131(3).

In the virtualization platform 10 shown in Figure 4, the upper limit for the number of workloads in a cluster is 36, and there are currently 30 workloads running. Even if a single physical server fails, there are surplus resources available that allow up to one of the physical servers to be restarted on another physical server. However, if a rack 110 experiences a rack-wide failure, the remaining free resources in racks 120 and 130 do not have the capacity to start all 10 workloads 201A-201C running on physical servers 111(1)-111(3) of rack 110.

FIG. 5 is an explanatory diagram showing an example of the allocation of workloads with multiple priorities when a rack-wide failure occurs in the virtualization platform 10 according to the embodiment. In FIG. 5, when a failure occurs in rack 110, four workloads 201A in the service group with the highest priority A can be restarted using the free resources of other physical servers 121 and 131. However, for three workloads 201B in the service group with the second-highest priority B that were running in rack 110, there are insufficient free resources to restart them on the other physical servers 121 and 131.

In this embodiment, when a failure occurs in one of multiple racks (infrastructure configuration devices), the system checks the priority of the service groups to which each of the multiple workloads running on the rack (infrastructure configuration device) 110 where the failure occurred belongs. If it is confirmed that a workload from a service group with a higher priority than a predetermined priority (e.g., "medium" priority) is running on the rack (infrastructure configuration device) 110 where the failure occurred, the system stops the workloads from service groups with a lower priority (e.g., "low" priority) running on the other racks (infrastructure configuration devices) 120, 130 where the failure did not occur. Furthermore, the system restarts the workloads from the high-priority service groups A and B that were running on the rack (infrastructure configuration device) 110 where the failure occurred, using the physical resources freed up by stopping the workloads on the other racks (infrastructure configuration devices) 120, 130 where the failure did not occur.

In the example of Figure 5, some of the workloads 202C and 203C of the service group with low priority C that were running on physical servers 121 and 131 in racks 120 and 130 are stopped, and the resources freed up by stopping these workloads are used to restart three workloads 201B of the service group with priority B that were running on rack 110.

In the example of FIG. 5, depending on the resource status in each rack, all of the workloads of the service group with priority C that were running on the physical servers 121 and 131 in racks 120 and 130 may be stopped, and the resources freed up by stopping the workloads may be used to restart the workloads of the service group with priority B that were running on rack 110. Also, depending on the resource status in each rack, all of the workloads of the service group with priority C and some or all of the workloads of the service group with priority B that were running on the physical servers 121 and 131 in racks 120 and 130 may be stopped, and the resources freed up by stopping the workloads may be used to restart workload 201A of the service group with priority A, workload 201B of the service group with priority B, or both of these workloads that were running on rack 110.

As described above, in this embodiment, as a countermeasure against rack failures, surplus resources in the virtualization platform 10 can be reduced by accepting the abandonment of services from low-priority service groups.

FIG. 6 is an explanatory diagram showing an example of the configuration of a management system 30 that manages the virtualization platform 10 according to an embodiment. In FIG. 6, the management system 30 includes an information storage unit (DB) 310, an information processing unit 320, and a control unit 330. The management system 30 may further include a communication unit 340. The management system 30 may be installed on a server or cloud computer system separate from the virtualization platform 10, or may be installed as a management server on a physical server in the virtualization platform 10.

The information storage unit (DB) 310 stores information on all physical servers (physical resources) 111, 121, 131 of a cluster constructed on the virtualization platform 10 that can run multiple workloads, as well as information on each physical server (physical resource) 111, 121, 131 of multiple racks (platform configuration devices) 110, 120, 130. The information storage unit (DB) 310 also stores information on various tables in the configuration of the virtualization platform 10 described above, such as the service group table in Table 1, the priority-based resource table in Table 2, the rack resource table in Table 3, the cluster resource table in Table 4, and the condition table in Table 5.

In the example condition table in Table 5, the following conditions are shown: four virtual CPUs can be allocated and used for one physical CPU installed on the physical server; memory can be used up to the upper limit of the physical memory installed on the physical server; and two virtual GPUs can be allocated and used for one physical GPU installed on the physical server.

The information processing unit 320 classifies the multiple services provided by a cluster constructed on the virtualization infrastructure 10, capable of running multiple workloads, into multiple service groups with different priorities. Furthermore, the information processing unit 320 allocates the multiple workloads executed in the cluster and manages the physical servers (physical resources) required by each of the multiple service groups, based on information on the physical servers (physical resources) 111, 121, 131 of the entire cluster and information on the physical servers (physical resources) 111, 121, 131 of each of the multiple racks (infrastructure components) 110, 120, 130.

As described above, when a failure occurs in one of the multiple racks (infrastructure configuration devices) 110, 120, 130, the control unit 330 checks the priority of the service groups to which each of the multiple workloads running on the rack (infrastructure configuration device) 110 where the failure occurred belongs. Furthermore, if the control unit 330 checks that a workload from a service group with a higher priority than a predetermined priority (e.g., "medium" priority) was running on the rack (infrastructure configuration device) 110 where the failure occurred, it stops the workloads from a service group with a lower priority (e.g., "low" priority) running on the other racks (infrastructure configuration devices) 120, 130 where the failure did not occur. Furthermore, the control unit 330 controls the restart of the workloads from the high-priority service groups A and B that were running on the rack (infrastructure configuration device) 110 where the failure occurred, using the physical resources freed up by stopping the workloads on the other racks (infrastructure configuration devices) 120, 130 where the failure did not occur.

The communications unit 340 communicates with the terminal device of the user (or operator, etc.) 40 via a communications line or the like, and provides the user with impact information in the event of a failure in the rack (infrastructure component device) 110 with the greatest physical resources among multiple racks (infrastructure component devices) 110, 120, and 130.

FIG. 7 is a flowchart showing an example of generating a resource-related table for a virtual environment in the virtualization platform 10 according to an embodiment. In FIG. 7, the information processing unit 320 generates a workload table for a workload when deploying (e.g., building or creating) the workload in the virtualization platform 10 (S101). Next, the information processing unit 320 aggregates resource components (CPU, memory, GPU) for each service group with different priorities and creates the service group table shown in Table 1 (S102). Next, the information processing unit 320 aggregates resource components (CPU, memory, GPU) for each priority for the service group table shown in Table 1 and creates the priority-based resource table shown in Table 3 (S103).

FIG. 8 is a flowchart showing an example of generating a physical resource-related table in a virtualization platform according to an embodiment. In FIG. 8, the information processing unit 320 generates a physical server resource table from information about the physical servers in each rack that constitutes a cluster in the virtualization platform 10 (S201). Next, the information processing unit 320 aggregates the resource components (CPU, memory, GPU) in the physical server resource table to create the cluster resource table shown in Table 4 (S202). Next, the information processing unit 320 creates the rack resource table shown in Table 3 from the physical server resource table (S203).

Figure 9 is a flowchart showing an example of calculating the priority of a service group that restarts a workload when a rack-wide failure occurs in the virtualization platform 10 according to an embodiment. In Figure 9, the information processing unit 320 calculates the physical resources that can be used for each resource component (CPU, memory, GPU) when the rack 110 with the largest number of resource components (CPU, memory, GPU) goes down (fails), i.e., when a failure occurs in the rack 110, based on information on the physical servers 111, 121, 131 of each of the multiple racks 110, 120, 130 (S301). Next, the information processing unit 320 calculates and determines how many priorities can be covered in descending order of priority, i.e., the predetermined priority, based on the calculation results for each resource component (CPU, memory, GPU) of the physical resources of the available racks 120 and 130 (rack resource table in Table 7), information for each resource component (CPU, memory, GPU) of the physical resources corresponding to each of multiple priorities (high, medium, low) (resource table by priority in Table 6), and the competitive allocation setting conditions for each resource component (CPU, memory, GPU) in Table 5 (S302).

Referring to Table 7, we can see that if rack 110 (rack ID = 1) goes down, the total number of CPUs available for use on the virtualization platform 10 will be 16 (64 cores), memory 256 GB, and GPUs 8 (16 cores). Furthermore, referring to the condition-accepting row in Table 7, which is calculated taking into account the conflict allocation setting conditions for each resource component (CPU, memory, GPU) in Table 5, we see that

Next, the information processing unit 320 transmits impact information regarding the impact when the rack 110 with the largest number of resource components (CPU, memory, GPU) goes down (fails), i.e., when a failure occurs in the rack 110, to the terminal device of the user (or operator, etc.) 40 via the communication unit 340 and provides it (S303).

In the virtualization platform 10 of this embodiment, under normal circumstances, if all racks 110, 120, and 130 are operating normally, the workloads of all service groups with high, medium, and low priorities can be run.

Furthermore, in this embodiment, in pre-calculation to prepare for a rack failure in which one of the racks goes down (falls), it can be determined that the impact of a rack failure in which rack 110 goes down (falls) would be significant, since rack 110 has the largest resource components (CPU, memory, GPU) of the three racks 110, 120, and 130. If rack 110 goes down (falls), the number of CPU cores in the high and medium priority service groups will be 60, which will not be able to cover the workload of the low priority service group.

Furthermore, since the above pre-calculation shows that the workloads of low-priority service groups cannot be covered, when a rack failure occurs in which rack 110 goes down (falls), the workloads of low-priority service groups are stopped on the physical servers 121, 131 of the other racks 120, 130, and the workloads of high- and medium-priority service groups that were running on rack 110 before the failure are restarted using the resources of the physical servers 121, 131 that are free in racks 120, 130.

In this embodiment, all or part of the generation of the virtual environment resource-related table in FIG. 7, the generation of the physical resource-related table in FIG. 8, and the calculation of service group priorities in FIG. 9 may be pre-calculated before the actual operation of the virtualization infrastructure 10 begins, or may be recalculated when the number or configuration of racks in the virtualization infrastructure 10 changes, when workloads such as virtual machines (VMs) or containers running on the virtualization infrastructure 10 change, when services provided by the virtualization infrastructure 10 change, etc.

As described above, according to this embodiment, even if a failure occurs in one of the multiple racks 110, 120, 130 that make up the virtualization infrastructure 10 and all physical servers 111 in the failed rack stop operating, high-priority services can continue to be provided on the virtualization infrastructure 10.

Furthermore, according to this embodiment, excess resources of physical servers within racks in the virtualization platform 10 can be reduced.

Note that in this embodiment, the multiple infrastructure-constituting devices that make up the virtualization infrastructure 10 are mainly racks 110, 120, and 130 each having multiple physical servers and power supplies, and the physical resources are physical servers 111, 121, and 131. However, the types of multiple infrastructure-constituting devices and physical resources that make up the virtualization infrastructure 10 are not limited to these. For example, the multiple infrastructure-constituting devices that make up the virtualization infrastructure 10 may each be a container-type data center having multiple physical servers and power supplies, and the physical resources may be racks having multiple physical servers. In this case, even if a failure occurs in one of the multiple container-type data centers that make up the virtualization infrastructure 10 and all physical servers in the container-type data center where the failure occurred stop operating, high-priority services can continue to be provided on the virtualization infrastructure 10.

Furthermore, according to this embodiment, excess resources within the container-type data center in the virtualization platform 10 can be reduced.

The present invention reduces excess resources in the virtualization infrastructure 10, while enabling high-priority services to continue to be provided on the virtualization infrastructure 10 even if a failure occurs in one of the multiple racks 110, 120, and 130 that make up the virtualization infrastructure 10. This can contribute to achieving Goal 9 of the Sustainable Development Goals (SDGs), which is to "build inclusive and sustainable industrial infrastructure, promote inclusive and sustainable industrialization, and build resilient infrastructure."

Note that the processing steps and components of the management system (storage unit, information processing unit, control unit, communication unit, etc.) described in this specification can be implemented by various means. For example, these steps and components may be implemented by hardware, firmware, software, or a combination thereof.

With regard to hardware implementation, the processing units and other means used to realize the above steps and components in an entity (e.g., a physical server, rack, container-type data center, hard disk drive device, or optical disk drive device) may be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, electronic devices, other electronic units designed to perform the functions described herein, computers, or combinations thereof.

Furthermore, with regard to firmware and/or software implementations, the means, such as a processing unit, used to realize the components may be implemented with a program (e.g., code, such as procedures, functions, modules, instructions, etc.) that performs the functions described herein. In general, any computer/processor-readable medium tangibly embodying firmware and/or software code may be used to implement the means, such as a processing unit, used to realize the steps and components described herein. For example, the firmware and/or software code may be stored in memory and executed by a computer or processor, for example in a control device. The memory may be implemented within the computer or processor, or external to the processor. The firmware and/or software code may also be stored on a computer- or processor-readable medium, such as, for example, random access memory (RAM), read-only memory (ROM), non-volatile random access memory (NVRAM), programmable read-only memory (PROM), electrically erasable programmable read-only memory (EEPROM), flash memory, floppy disk, compact disk (CD), digital versatile disk (DVD), magnetic or optical data storage device, etc. The code may be executed by one or more computers or processors and may cause the computers or processors to perform certain aspects of the functionality described herein.

Furthermore, the medium may be a non-transitory recording medium. Furthermore, the program code may be in any format as long as it can be read and executed by a computer, processor, or other device or machine, and its format is not limited to a specific format. For example, the program code may be source code, object code, or binary code, or may be a mixture of two or more of these codes.

Furthermore, the description of the embodiments disclosed herein is provided to enable any person skilled in the art to make or use the present disclosure. Various modifications to the present disclosure will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other variations without departing from the spirit or scope of the present disclosure. Thus, the present disclosure is not intended to be limited to the examples and designs described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

10: Virtualization platform 30: Management system 110: Rack 111: Physical servers 111(1) to 111(3): Physical server 111': Physical server 112: Switch 120: Rack 121: Physical servers 121(1) to 121(3): Physical server 130: Rack 131: Physical servers 131(1) to 131(3): Physical servers 201A to 201C: Workloads 202A to 202C: Workloads 203A to 203C: Workload 320: Information processing unit 330: Control unit 340: Communication unit

Claims (10)

A system for managing a virtualization infrastructure having a plurality of infrastructure component devices each having a plurality of physical resources,
an information storage unit that stores information on the overall physical resources of a cluster on which multiple workloads constructed on the virtualization infrastructure can operate, and information on the physical resources of each of the multiple infrastructure-composing devices;
an information processing unit that classifies a plurality of services provided by a cluster constructed on the virtualization infrastructure in which a plurality of workloads can operate into a plurality of service groups having different priorities, and manages the allocation of the plurality of workloads to be executed in the cluster and the physical resources required by each of the plurality of service groups based on information on the overall physical resources of the cluster and information on the physical resources of each of the plurality of infrastructure-composing devices;
A system comprising: 10. The system of claim 1,
A system characterized by comprising a control unit that, when a failure occurs in one of the multiple infrastructure component devices, checks the priority of the service groups to which each of the multiple workloads running on the failed infrastructure component device belongs, and if it is confirmed that a workload of a service group with a priority higher than a predetermined priority was running on the failed infrastructure component device, stops the workload of the low-priority service group running on the infrastructure component device where the failure did not occur, and controls the system to restart the workload of the high-priority service group that was running on the failed infrastructure component device using the physical resources freed up by the stopping of the workload on the infrastructure component device where the failure did not occur. In the system of claim 2,
The information processing unit
Based on the information on the physical resources of each of the plurality of infrastructure component devices, calculates for each resource component an available physical resource in the event of a failure in an infrastructure component device having the largest physical resource among the plurality of infrastructure component devices;
determining the predetermined priority based on the calculation result for each resource component of the available physical resources, information for each resource component of the physical resources corresponding to each of the plurality of priorities, and a competitive allocation setting condition for each resource component;
A system characterized by: In the system of claim 3,
the information processing unit provides a user with impact information when a failure occurs in an infrastructure component device having the largest physical resources among the plurality of infrastructure component devices.
A system characterized by: 5. The system of claim 1,
the physical resource is a physical server,
The infrastructure component device is a rack having a plurality of physical servers and a power supply.
A system characterized by: 5. The system of claim 1,
the physical resource is a rack having a plurality of physical servers;
The infrastructure component device is a container-type data center having a plurality of racks and a power supply.
A system characterized by: A method for managing a virtualization infrastructure having a plurality of infrastructure component devices each having a plurality of physical resources, comprising:
storing information on the overall physical resources of a cluster on which a plurality of workloads constructed on the virtualization infrastructure can operate, and information on the physical resources of each of the plurality of infrastructure-composing devices;
classifying a plurality of services provided by a cluster that is constructed on the virtualization infrastructure and that is capable of running a plurality of workloads into a plurality of service groups having different priorities;
Based on information on the overall physical resources of the cluster and information on the physical resources of each of the plurality of infrastructure components, for each of the plurality of service groups, allocating a plurality of workloads to be executed in the cluster and managing the physical resources required by the service group;
A method comprising: 8. The method of claim 7,
When a failure occurs in any of the plurality of infrastructure components, checking the priority of a service group to which each of the plurality of workloads running on the infrastructure component device where the failure occurred belongs;
When it is confirmed that a workload of a service group with a higher priority than a predetermined priority is running on the infrastructure component device where the failure has occurred, stopping the workload of a service group with a lower priority running on the infrastructure component device where the failure has not occurred;
restarting the workload of the high-priority service group that was running on the infrastructure component device where the failure occurred, using physical resources that have become available due to the suspension of the workload on the infrastructure component device where the failure has not occurred;
A method comprising: A program executed by a computer or processor provided in a system that manages a virtualization infrastructure that includes multiple infrastructure component devices each having multiple physical resources,
program code for storing information on the overall physical resources of a cluster on which a plurality of workloads constructed on the virtualization infrastructure can operate, and information on the physical resources of each of the plurality of infrastructure-composing devices;
a program code for classifying a plurality of services provided by a cluster constructed on the virtualization platform in which a plurality of workloads can be operated into a plurality of service groups having different priorities;
program code for managing, for each of the plurality of service groups, the placement of a plurality of workloads to be executed in the cluster and the management of physical resources required by the service group, based on information on the overall physical resources of the cluster and information on the physical resources of each of the plurality of infrastructure components;
A program comprising: In the program of claim 9,
a program code for, when a failure occurs in any of the plurality of infrastructure components, checking the priority of a service group to which each of a plurality of workloads running on the infrastructure component device in which the failure occurs belongs;
a program code for stopping a workload of a service group with a high priority equal to or higher than a predetermined priority that is running on the infrastructure component device where the failure has occurred, when it is confirmed that the workload of the service group with a high priority equal to or higher than a predetermined priority is running on the infrastructure component device where the failure has occurred;
program code for restarting the workload of the high-priority service group that was running on the infrastructure component device where the failure occurred, using physical resources that have become available due to the suspension of the workload on the infrastructure component device where the failure has not occurred;
A program comprising: