A cloud host memory optimization allocation method based on capacity calculation and dynamic migration

Abstract

The application discloses a cloud host memory optimization allocation method based on capacity calculation and dynamic migration. The method receives a large-specification cloud host creation request and obtains the required memory size; detects resource distribution, and when global resources are sufficient but no single machine meets the request, judges whether the total free memory meets the preset redundancy condition; if yes, the request is suspended and a fragment consolidation trigger instruction is generated; the value of each host is calculated according to a migration cost function, and the target host is selected by comprehensively considering the free memory, the number of cloud hosts and the value; a migration path mapping of the cloud host to be migrated out is generated, and the migration engine executes migration through an automatic script calling hot migration interface; the memory release of the target host is monitored, and after the available memory meets the standard, the suspended request is issued for deployment, and the opening is completed. The application realizes active rescue and stable migration when large-specification instance creation fails, and solves the technical problem of real-time opening failure caused by memory fragmentation when the total resources are sufficient.

Description

Technical Field

[0001] This application relates to the field of cloud resource pool scheduling technology, specifically to a cloud host memory optimization allocation method based on capacity calculation and dynamic migration. Background Technology

[0002] With the rapid evolution and large-scale application of cloud computing technology, data centers are undergoing a profound transformation from traditional distributed architectures to large-scale centralized resource pools. Cloud resource pools, through virtualization, containerization, and software-defined technologies, abstract distributed physical resources such as computing, storage, and networks into a unified logical resource pool, enabling on-demand allocation and elastic scaling of resources.

[0003] Cloud resource pool scheduling, as a key technology layer connecting upper-layer business needs and underlying physical infrastructure, aims to dynamically orchestrate and optimize resource allocation through intelligent decision-making algorithms. Its goal is to maximize resource utilization, reduce energy costs, and ensure high system availability while meeting Service Level Agreements (SLAs).

[0004] Currently, cloud resource pool scheduling strategies (such as OpenStack Nova or Kubernetes Scheduler) mostly employ filtering and weighting based on current static available memory. When a request for a large amount of memory (e.g., 128GB) is received from a cloud host, the scheduler scans all hosts in the resource pool. If no host has available memory... Greater than the requested value The scheduler will directly return a "resources insufficient" error, causing the task to fail.

[0005] To address this issue, patent document CN120353567A discloses a resource management method, apparatus, and electronic device. The method includes: acquiring load and resource information of the sub-machines in each physical machine; selecting migrateable physical machines as source-end master machines and non-migrateable physical machines as destination-end master machines based on the load and resource information of the sub-machines in each physical machine; sequentially selecting the sub-machines in each source-end master machine as sub-machines to be migrated; and, based on the resource information of the sub-machines to be migrated, selecting destination-end master machines whose idle resources are greater than or equal to the resource information of the sub-machines to be migrated and which belong to fragmented resources as the destination-to-migrate master machines corresponding to the sub-machines to be migrated; and hot-migrating each sub-machine to be migrated from each source-end master machine to its corresponding destination-to-migrate master machine. However, this method is a passive approach and cannot proactively intervene to rescue users when they fail to create large-scale instances. It can only fill scattered fragments to free up the entire machine and cannot aggregate the scattered memory from multiple host machines into one to meet the large-scale requirements. In addition, this method only performs simple packing based on static specifications and cannot minimize the impact on existing network services.

[0006] Patent document CN117971381A discloses a NUMA-level fragmentation method, including: defragmenting the host machine's resources at the NUMA level based on the host machine's resource allocation information; sorting the host machine based on supply and demand matching during resource fragmentation, and then sorting the NUMA nodes within the host machine; scheduling virtual machines based on supply and demand matching, finding the optimal destination host for the selected virtual machines or combinations of virtual machines, and determining the migration strategy for the virtual machines or combinations of virtual machines; optimizing and executing the migration strategy for the virtual machines or combinations of virtual machines. However, this method mainly considers the NUMA (Non-Uniform Memory Access) node level within the physical server. Even if the host machine has sufficient overall memory, if it is distributed across different NUMA nodes (e.g., cross-node access), it can lead to performance degradation or HugePages allocation failure.

[0007] In summary, existing technologies can only serve as passive background defragmentation tools, and their decision-making is based entirely on static resource information (such as static memory specifications, static CPU remaining capacity, and static NUMA allocation status), which has the following drawbacks:

[0008] (1) There is a lack of an on-demand real-time triggering mechanism, making it impossible to proactively intervene and provide assistance when creation fails;

[0009] (2) The migration cost assessment has a single and static dimension, focusing only on static resources while ignoring the impact of dynamic factors such as real-time I / O load on the business;

[0010] (3) The lack of safety redundancy design, in pursuit of extreme fullness, has buried potential stability risks;

[0011] (4) Optimize target misalignment, focusing only on the periodic emptying of the entire machine in the background rather than solving the problem of real-time scheduling failure of large-scale instances. Summary of the Invention

[0012] To address this issue, this application provides a cloud server memory optimization allocation method based on capacity calculation and dynamic migration. This method solves the problem in existing technologies where, despite sufficient total resources, large-scale instances cannot be deployed in real time due to memory fragmentation. This is because existing technologies lack an on-demand real-time triggering mechanism, have static migration cost assessments, lack security redundancy design, and have misaligned optimization goals.

[0013] To achieve the above objectives, this application provides the following technical solution:

[0014] Firstly, a cloud server memory optimization allocation method based on capacity calculation and dynamic migration, the method being applied to a resource scheduler, comprising:

[0015] Step 1: Receive a large-scale cloud server creation request and obtain the required memory size from the large-scale cloud server creation request;

[0016] Step 2: Detect the resource distribution in the resource pool based on the required memory size. When it is detected that the global resources in the resource pool are sufficient but the single-machine resources are insufficient, calculate the total free memory of the resource pool and determine whether the total free memory meets the preset redundancy condition. The redundancy condition is determined based on the required memory size and the preset redundancy coefficient.

[0017] Step 3: If the preset redundancy conditions are met, the creation request status of the large-scale cloud host is changed from the scheduling state to the suspended state, and a defragmentation trigger instruction is generated; the defragmentation trigger instruction contains the required memory size;

[0018] Step 4: Calculate the migration cost of each host in the resource pool based on the defragmentation trigger instruction and migration cost function, and select the host with the largest current free memory, the fewest number of running cloud hosts, and the smallest migration cost as the target host.

[0019] Step 5: Generate a migration path mapping for the cloud host to be migrated out based on the target host, and send the migration path mapping to the migration engine; The migration engine calls the hot migration interface of the virtualization platform through automated script orchestration based on the migration path mapping to hot migrate the cloud host to be migrated out to the corresponding receiving host.

[0020] Step 6: During the hot migration process, the available memory release status of the target host machine is monitored in real time by polling. When the available memory of the target host machine reaches or exceeds the required memory size, the resources of the target host machine are locked, and the creation request of the large-scale cloud host in the suspended state is sent to the target host machine to complete the deployment and activation of the large-scale cloud host.

[0021] Preferably, in step 2, when determining whether the total free memory meets the preset redundancy condition, the specific formula is as follows: ,in, This represents the total free memory in the resource pool. This indicates the memory size required in a large-scale cloud server creation request. This indicates the preset redundancy coefficient.

[0022] Preferably, the preset redundancy coefficient is set to 1.2.

[0023] Preferably, in step 4, the migration cost function is:

[0024]

[0025] in, Indicates the migration cost. Indicates the number on the target host machine The current memory allocation value of the cloud server to be migrated out. This indicates the preset maximum memory baseline value. Indicates the number on the target host machine Real-time I / O load of cloud servers awaiting migration. This indicates the preset maximum I / O reference value. , Let these represent the weighting coefficients for memory and I / O, respectively, and satisfy the following conditions: , This indicates that the target host machine has... The cloud server is awaiting relocation.

[0026] Preferably, step 5, generating the migration path mapping for the cloud host to be migrated out based on the target host, specifically includes:

[0027] Step 501: Query all existing cloud hosts running on the target host machine and generate a list of cloud hosts to be migrated out. Sort the cloud hosts in the list of cloud hosts to be migrated out in descending order of memory size.

[0028] Step 502: Traverse the list of cloud hosts to be migrated out in descending order, and allocate a receiving host from the resource pool for each cloud host that can accommodate the cloud host.

[0029] Step 503: Generate the migration path mapping based on the allocation results.

[0030] Preferably, in step 502, allocating a receiving host capable of accommodating each cloud host from the resource pool specifically includes:

[0031] Select candidate host machines from the resource pool whose available resources are greater than or equal to the current cloud host's memory size;

[0032] Calculate the amount of remaining idle resources for each candidate host after it receives the cloud host;

[0033] The candidate host with the smallest remaining idle resources is selected as the receiving host of the cloud host.

[0034] Preferably, in step 503, the migration path mapping is as follows:

[0035]

[0036] in, Indicates the cloud host ID. Indicates the target host machine. Indicates the receiving host machine, This indicates the allocated resource slot information.

[0037] Preferably, in step 5, when hot-migrating the cloud host to be migrated out to the corresponding receiving host, if the migration fails, a failure reminder will be returned to the resource scheduler, and the task will be suspended and switched to manual migration adjustment.

[0038] Preferably, in step 5, the virtualization platform is KVM or QEMU, and the hot migration interface is the virshmigrate interface.

[0039] Secondly, a cloud server memory optimization allocation device based on capacity calculation and dynamic migration includes:

[0040] A request receiving module is created to receive large-scale cloud host creation requests and obtain the required memory size from the large-scale cloud host creation requests;

[0041] The resource detection module is used to detect the resource distribution in the resource pool based on the required memory size. When it is detected that the global resources in the resource pool are sufficient but the single-machine resources are insufficient, the module calculates the total free memory in the resource pool and determines whether the total free memory meets the preset redundancy conditions. The redundancy conditions are determined based on the required memory size and the preset redundancy coefficient.

[0042] The defragmentation trigger module is used to change the status of the large-scale cloud host creation request from the scheduling state to the suspended state if the preset redundancy conditions are met, and to generate a defragmentation trigger instruction; the defragmentation trigger instruction includes the required memory size;

[0043] The target host machine determination module is used to calculate the migration cost of each host machine in the resource pool according to the defragmentation trigger instruction and migration cost function, and select the host machine with the largest current free memory, the fewest number of running cloud hosts and the smallest migration cost as the target host machine.

[0044] The migration path generation module is used to generate a migration path mapping for the cloud host to be migrated out based on the target host, and to call the hot migration interface of the virtualization platform through automated script orchestration based on the migration path mapping to hot migrate the cloud host to be migrated out to the corresponding receiving host.

[0045] The real-time polling monitoring module is used to poll and monitor the available memory release status of the target host in real time during the hot migration process. When it is detected that the available memory of the target host reaches or exceeds the required memory size, the resources of the target host are locked, and the creation request of the suspended large-scale cloud host is sent to the target host to complete the deployment and activation of the large-scale cloud host.

[0046] Compared with the prior art, this application has at least the following beneficial effects:

[0047] This application provides a cloud server memory optimization allocation method based on capacity calculation and dynamic migration. It receives large-scale cloud server creation requests and obtains the required memory size; detects resource distribution; when global resources are sufficient but no single machine can fulfill the request, it determines whether the total free memory meets preset redundancy conditions; if so, it suspends the request and generates a defragmentation trigger command; calculates the cost value of each host machine based on a migration cost function, and selects the target host machine by considering free memory, the number of cloud servers, and the cost value; generates a migration path mapping for the cloud servers to be migrated out, and the migration engine executes the migration by calling the hot migration interface through an automated script; monitors the memory release of the target host machine, and once the available memory reaches the target, it issues the suspended request for deployment, completing the activation. This application, through on-demand real-time triggering, dynamic cost assessment, and security redundancy design, achieves proactive rescue and stable migration when large-scale instance creation fails, accurately solving the technical challenge of real-time activation failure due to memory fragmentation despite sufficient total resources. Attached Figure Description

[0048] To more intuitively illustrate the prior art and this application, exemplary drawings are provided below. It should be understood that the specific shapes and structures shown in the drawings should not generally be regarded as limiting conditions for implementing this application; for example, based on the technical concept disclosed in this application and the exemplary drawings, those skilled in the art are able to easily make conventional adjustments or further optimizations to the addition / reduction / classification, specific shapes, positional relationships, connection methods, size ratios, etc. of certain units (components).

[0049] Figure 1 A flowchart illustrating a cloud host memory optimization allocation method based on capacity calculation and dynamic migration, provided in Embodiment 1 of this application;

[0050] Figure 2 This is an interactive flowchart of a cloud host memory optimization allocation method based on capacity calculation and dynamic migration, provided in Embodiment 1 of this application. Detailed Implementation

[0051] The present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0052] In the description of this application: unless otherwise stated, "a plurality of" means two or more. The terms "first," "second," "third," etc., in this application are intended to distinguish the objects referred to and do not have any special meaning in terms of technical connotation (e.g., they should not be construed as an emphasis on importance or order). Expressions such as "including," "comprising," and "having" also mean "not limited to" (certain units, components, materials, steps, etc.).

[0053] The terms used in this application, such as "upper," "lower," "left," "right," and "middle," are generally used to indicate the general relative positional relationship for the purpose of intuitive understanding by referring to the accompanying drawings, and are not absolute limitations on the positional relationship in the actual product.

[0054] Example 1

[0055] This embodiment provides a cloud host memory optimization allocation method based on capacity calculation and dynamic migration. This method provides a systematic solution to problems such as memory space fragmentation, failure to open large-scale instances due to insufficient continuous resources on a single machine, and lack of dynamic adjustment capability of static allocation strategies during cloud resource pool scheduling. It is applicable to scenarios such as public cloud or private cloud resource scheduling, deep integration of data center resources, and automated cloud platform operation and maintenance.

[0056] Please see Figure 1 and Figure 2 This embodiment provides a cloud server memory optimization allocation method based on capacity calculation and dynamic migration. This method is applied to a resource scheduler and includes:

[0057] S1: Receives large-scale cloud server creation requests and obtains the required memory size from the large-scale cloud server creation requests. ;

[0058] S2: Detect the resource distribution in the resource pool based on the required memory size. When it is detected that the global resources in the resource pool are sufficient but the single-machine resources are insufficient, calculate the total free memory in the resource pool and determine whether the total free memory meets the preset redundancy conditions. The redundancy conditions are determined based on the required memory size and the preset redundancy coefficient.

[0059] Specifically, when the resource scheduler receives the required memory... When a large-scale cloud server creation request is received, and it is detected that global resources are sufficient but individual machine resources are insufficient, the resource scheduler will calculate the total free memory of the current resource pool. And determine the total free memory. Whether the preset redundancy conditions are met, i.e., judgment ,in, This represents the total free memory in the resource pool. This indicates the memory size required in a large-scale cloud server creation request. This indicates the preset redundancy coefficient. The preferred value is 1.2.

[0060] S3: If the preset redundancy conditions are met, the status of the large-scale cloud host creation request will be changed from the scheduling state to the suspended state, and a defragmentation trigger instruction will be generated; the defragmentation trigger instruction includes the required memory size.

[0061] Specifically, if the total free memory If the preset redundancy conditions are met, the prerequisite for performing "memory defragmentation" is deemed satisfied, and the resource scheduler will change the status of the large-scale cloud host creation request from "scheduling" to "Pending / Deferred." At this time, the resource scheduler will generate a request containing the original request parameters. The "fragmentation trigger command" is used. Therefore, this embodiment replaces the traditional "failure terminates" logic with a reverse compensation mechanism that "triggers automatic reassembly after failure".

[0062] S4: Calculate the migration cost of each host in the resource pool based on the defragmentation trigger instruction and migration cost function, and select the host with the largest current free memory, the fewest number of running cloud hosts and the smallest migration cost as the target host.

[0063] Specifically, for the resource pools identified in the above steps as eligible for defragmentation, the resource scheduler calculates the "fill cost" for each host machine in the pool as a cleanup target. To minimize the impact of the migration process on existing services, this embodiment introduces a migration cost function to evaluate the migration cost of each host machine. The migration cost function is as follows:

[0064]

[0065] in, Indicates the migration cost. Indicates the number on the target host machine The current memory allocation value of the cloud server to be migrated out. This indicates the preset maximum memory baseline (such as the memory configuration of the largest cloud host in the resource pool or the total memory of physical machines). Indicates the number on the target host machine Real-time I / O load (such as disk read rate) of cloud servers to be migrated out. This indicates the preset maximum I / O baseline value (such as the maximum bandwidth threshold of the storage link). , Let these represent the weighting coefficients for memory and I / O, respectively, and satisfy the following conditions: , This indicates that the target host machine has... The cloud server is awaiting relocation.

[0066] In this step, the migration cost function eliminates the unit effect through denominator division, thus... This results in a comprehensive score reflecting the difficulty of migration, and a migration cost calculation model that takes into account both memory size and I / O load ensures that the reorganization process minimizes the impact on the stability of existing services. Finally, the resource scheduler selects a server with ample available memory, the fewest running cloud servers, and the lowest migration cost. The smallest host machine is selected as the target host machine.

[0067] S5: Generate a migration path mapping for the cloud host to be migrated out based on the target host and send the migration path mapping to the migration engine; The migration engine calls the hot migration interface of the virtualization platform through automated script orchestration based on the migration path mapping to hot migrate the cloud host to be migrated out to the corresponding receiving host.

[0068] Specifically, a migration path mapping for the cloud host to be migrated out is generated based on the target host, including:

[0069] S501: Query all existing cloud hosts running on the target host machine and generate a list of cloud hosts to be migrated out. Sort the cloud hosts in the list of cloud hosts to be migrated out in descending order of memory size.

[0070] More specifically, this step is based on the target host machine identified in the previous step (abbreviated as: Query all existing cloud servers currently in operation and generate a list of cloud servers to be migrated out. List of cloud servers to be migrated. Cloud servers in the cloud are classified according to memory specifications Sort in descending order. This order prioritizes larger instances to prevent refactoring failures later in the migration process, as large-memory cloud servers may not be able to accommodate the remaining small fragments.

[0071] S502: Traverse the list of cloud hosts to be migrated out in descending order, and allocate a receiving host from the resource pool for each cloud host that can accommodate it.

[0072] More specifically, allocating a receiving host machine capable of accommodating each cloud server from the resource pool, including:

[0073] S5021: Select candidate host machines from the resource pool whose idle resources are greater than or equal to the current cloud host's memory size;

[0074] S5022: Calculate the amount of remaining idle resources for each candidate host after it receives the cloud host;

[0075] S5023: Select the candidate host with the smallest remaining idle resources as the receiving host of the cloud host.

[0076] In summary, this step involves starting with the list of cloud servers to be migrated. Take out the cloud host in sequence In the resource pool, except All other host machines (i.e., the set of receiving host machines) The search is performed within the specified range. This applies to each cloud server. Calculate the remaining available memory of each receiving host. and select the one that satisfies And the difference The smallest host machine serves as the cloud host. The receiving end. Additionally, during the traversal process, for each successfully matched receiving end, the corresponding resources of that receiving end are deducted from the simulation logic, until the list of cloud hosts to be migrated is reached. All cloud servers have been allocated.

[0077] The core purpose of this step, which utilizes the "minimum fragmentation gap" (i.e., the available space with the smallest difference mentioned above), is to accurately fill the existing cloud host resources into the resources of other host machines, so as not to occupy large blocks of continuous resources of other host machines.

[0078] S503: Generate migration path mapping based on the allocation results.

[0079] Specifically, the data structure for migration path mapping is defined as follows:

[0080]

[0081] in, Indicates the cloud host ID. Indicates the target host machine. Indicates the receiving host machine, This represents the allocated resource slot information. This mapping table explicitly records the ID of each cloud host, the source host (i.e., the target host), the receiving host ID, and the allocated resource slot information, serving as the sole instruction input for subsequent automated execution.

[0082] Based on the migration path mapping planned by the resource scheduler, the migration engine calls the hot migration API (such as virsh migrate) of the virtualization platform (such as KVM / QEMU) through automated script orchestration. After receiving the API call, the virtualization platform performs hot migration of the cloud hosts on the specified host, migrating the existing cloud hosts on the locked target host to the receiving host in parallel. If the migration fails, it will return false to the resource scheduler (i.e., a failure reminder) and suspend the task, switching to manual migration adjustment.

[0083] S6: During the hot migration process, the available memory release status of the target host machine is monitored in real time by polling. When the available memory of the target host machine reaches or exceeds the required memory size, the resources of the target host machine are locked, and the creation request of the suspended large-scale cloud host is sent to the target host machine to complete the deployment and activation of the large-scale cloud host.

[0084] Specifically, the resource scheduler monitors the execution results of the hot migration and completes resource release and reallocation to the new host. During the hot migration process, it polls and monitors the memory release status of the target host in real time. Once it detects the available memory after the target host releases, it will... This means issuing instructions to create large-scale cloud servers that have been suspended, completing the final activation process, and realizing an automated migration chain, that is, establishing a complete closed loop from "gap calculation - target locking - cost assessment - automatic script execution".

[0085] This embodiment provides a cloud server memory optimization allocation method based on capacity calculation and dynamic migration, which has the following advantages:

[0086] 1. Upon receiving a request to create a large-scale cloud host, the scheduler monitors the resource distribution in the resource pool in real time. When it detects that global resources are sufficient but no single host can fulfill the request, it immediately suspends the request and generates a defragmentation trigger command. Compared to existing technologies that can only perform passive background defragmentation and cannot detect creation failure events, this embodiment implements an on-demand, real-time triggering mechanism of "failure equals reorganization," which can proactively intervene and rescue when creation fails without manual intervention, significantly improving the success rate and response speed of large-scale instance activation.

[0087] 2. A migration cost function is used to calculate the migration cost of each host machine, taking into account dynamic factors such as the cloud host's memory size and real-time I / O load. Compared to existing technologies that make migration decisions based solely on static resource specifications and ignore the impact of real-time business load, this embodiment prioritizes the host machine with the lowest migration cost as the target host machine. This can identify and avoid the migration risks of cloud hosts with high I / O loads, ensuring that the defragmentation process has minimal impact on existing network services and guaranteeing business stability.

[0088] 3. Before triggering defragmentation, this embodiment first determines whether the total free memory in the resource pool meets the preset redundancy conditions. Compared with the shortcomings of existing technologies that pursue extreme fullness and do not reserve resource buffers for the migration process, this embodiment reserves a safe buffer space for the hot migration process through redundancy coefficients, avoiding business jitter or migration failure caused by resource contention during the migration process, and improving the overall stability and reliability of the system.

[0089] 4. By locking the target host machine, generating migration path mapping, performing hot migration, monitoring memory release, and deploying large-scale cloud hosts in a complete closed loop, compared with the shortcomings of existing technologies that only focus on periodically clearing the entire machine in the background and the misalignment between the optimization target and the actual problem scenario, this embodiment directly addresses the specific technical problem of "sufficient total resources but insufficient memory on a single machine causing the real-time activation of large-scale instances to fail". With the direct goal of ensuring the successful activation of the current request, it achieves a technical leap from "passive management" to "proactive rescue".

[0090] In summary, this embodiment treats the host machine as the smallest resource allocation unit. Its purpose is to solve the problem of insufficient overall memory on a physical machine. The core logic is to automatically trigger the "defragmentation" mechanism when it detects that the individual resources are insufficient but the total amount is sufficient (i.e., to judge in advance whether the hot migration will fail and to intercept it). By calculating the migration cost minimization scheme, the cloud host hot migration is executed by an automated script, thereby "freeing up" continuous memory space to meet the needs of large-scale instances. This greatly improves the success rate of large-scale instance opening, realizes deep integration and compact layout of resource pool, and the entire process is automatically completed by the script in milliseconds, without the user's awareness or manual intervention.

[0091] Example 2

[0092] This embodiment provides a cloud server memory optimization allocation device based on capacity calculation and dynamic migration, including:

[0093] A request receiving module is created to receive large-scale cloud host creation requests and obtain the required memory size from the large-scale cloud host creation requests;

[0094] The resource detection module is used to detect the resource distribution in the resource pool based on the required memory size. When it is detected that the global resources in the resource pool are sufficient but the single-machine resources are insufficient, the module calculates the total free memory in the resource pool and determines whether the total free memory meets the preset redundancy conditions. The redundancy conditions are determined based on the required memory size and the preset redundancy coefficient.

[0095] The defragmentation trigger module is used to change the status of the large-scale cloud host creation request from the scheduling state to the suspended state if the preset redundancy conditions are met, and to generate a defragmentation trigger instruction; the defragmentation trigger instruction includes the required memory size;

[0096] The target host machine determination module is used to calculate the migration cost of each host machine in the resource pool according to the defragmentation trigger instruction and migration cost function, and select the host machine with the largest current free memory, the fewest number of running cloud hosts and the smallest migration cost as the target host machine.

[0097] The migration path generation module is used to generate a migration path mapping for the cloud host to be migrated out based on the target host, and to call the hot migration interface of the virtualization platform through automated script orchestration based on the migration path mapping to hot migrate the cloud host to be migrated out to the corresponding receiving host.

[0098] The real-time polling monitoring module is used to poll and monitor the available memory release status of the target host in real time during the hot migration process. When it is detected that the available memory of the target host reaches or exceeds the required memory size, the resources of the target host are locked, and the creation request of the suspended large-scale cloud host is sent to the target host to complete the deployment and activation of the large-scale cloud host.

[0099] For details on the specific implementation of each module in a cloud host memory optimization allocation device based on capacity calculation and dynamic migration, please refer to the above description of the limitations of a cloud host memory optimization allocation method based on capacity calculation and dynamic migration, which will not be repeated here.

[0100] The technical features of the above embodiments can be combined in any way (as long as there is no contradiction in the combination of these technical features). For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described; these embodiments not explicitly written should also be considered to be within the scope of this specification.

Claims

1. A cloud server memory optimization allocation method based on capacity calculation and dynamic migration, characterized in that, The method is applied to a resource scheduler, including: Step 1: Receive a large-scale cloud server creation request and obtain the required memory size from the large-scale cloud server creation request; Step 2: Detect the resource distribution in the resource pool based on the required memory size. When it is detected that the global resources in the resource pool are sufficient but the single-machine resources are insufficient, calculate the total free memory of the resource pool and determine whether the total free memory meets the preset redundancy condition. The redundancy condition is determined based on the required memory size and the preset redundancy coefficient. Step 3: If the preset redundancy conditions are met, the creation request status of the large-scale cloud host is changed from the scheduling state to the suspended state, and a defragmentation trigger instruction is generated; the defragmentation trigger instruction contains the required memory size; Step 4: Calculate the migration cost of each host in the resource pool based on the defragmentation trigger instruction and migration cost function, and select the host with the largest current free memory, the fewest number of running cloud hosts, and the smallest migration cost as the target host. Step 5: Generate a migration path mapping for the cloud host to be migrated out based on the target host, and send the migration path mapping to the migration engine; The migration engine calls the hot migration interface of the virtualization platform through automated script orchestration based on the migration path mapping to hot migrate the cloud host to be migrated out to the corresponding receiving host. Step 6: During the hot migration process, the available memory release status of the target host machine is monitored in real time by polling. When the available memory of the target host machine reaches or exceeds the required memory size, the resources of the target host machine are locked, and the creation request of the large-scale cloud host in the suspended state is sent to the target host machine to complete the deployment and activation of the large-scale cloud host.

2. The cloud host memory optimization allocation method based on capacity calculation and dynamic migration according to claim 1, characterized in that, In step 2, when determining whether the total free memory meets the preset redundancy conditions, the specific formula is as follows: ,in, This represents the total free memory in the resource pool. This indicates the memory size required in a large-scale cloud server creation request. This indicates the preset redundancy coefficient.

3. The cloud host memory optimization allocation method based on capacity calculation and dynamic migration according to claim 2, characterized in that, The preset redundancy coefficient is set to 1.

2.

4. The cloud host memory optimization allocation method based on capacity calculation and dynamic migration according to claim 1, characterized in that, In step 4, the migration cost function is: ； in, Indicates the migration cost. Indicates the number on the target host machine The current memory allocation value of the cloud server to be migrated out. This indicates the preset maximum memory baseline value. Indicates the number on the target host machine Real-time I / O load of cloud servers awaiting migration. This indicates the preset maximum I / O reference value. , Let these represent the weighting coefficients for memory and I / O, respectively, and satisfy the following conditions: , This indicates that the target host machine has... The cloud server is awaiting relocation.

5. The cloud host memory optimization allocation method based on capacity calculation and dynamic migration according to claim 1, characterized in that, Step 5, generating the migration path mapping for the cloud host to be migrated out based on the target host, specifically includes: Step 501: Query all existing cloud hosts running on the target host machine and generate a list of cloud hosts to be migrated out. Sort the cloud hosts in the list of cloud hosts to be migrated out in descending order of memory size. Step 502: Traverse the list of cloud hosts to be migrated out in descending order, and allocate a receiving host from the resource pool for each cloud host that can accommodate the cloud host. Step 503: Generate the migration path mapping based on the allocation results.

6. The cloud host memory optimization allocation method based on capacity calculation and dynamic migration according to claim 5, characterized in that, In step 502, allocating a receiving host capable of accommodating each cloud host from the resource pool specifically includes: Select candidate host machines from the resource pool whose available resources are greater than or equal to the current cloud host's memory size; Calculate the amount of remaining idle resources for each candidate host after it receives the cloud host; The candidate host with the smallest remaining idle resources is selected as the receiving host of the cloud host.

7. The cloud host memory optimization allocation method based on capacity calculation and dynamic migration according to claim 5, characterized in that, In step 503, the migration path is mapped as follows: ； in, Indicates the cloud host ID. Indicates the target host machine. Indicates the receiving host machine, This indicates the allocated resource slot information.

8. The cloud host memory optimization allocation method based on capacity calculation and dynamic migration according to claim 1, characterized in that, In step 5, when hot-migrating the cloud host to be migrated out to the corresponding receiving host, if the migration fails, a failure reminder will be returned to the resource scheduler, and the task will be suspended and switched to manual migration adjustment.

9. The cloud host memory optimization allocation method based on capacity calculation and dynamic migration according to claim 1, characterized in that, In step 5, the virtualization platform is KVM or QEMU, and the hot migration interface is the virsh migrate interface.

10. A cloud server memory optimization allocation device based on capacity calculation and dynamic migration, characterized in that, include: A request receiving module is created to receive large-scale cloud host creation requests and obtain the required memory size from the large-scale cloud host creation requests; The resource detection module is used to detect the resource distribution in the resource pool based on the required memory size. When it is detected that the global resources in the resource pool are sufficient but the single-machine resources are insufficient, the module calculates the total free memory in the resource pool and determines whether the total free memory meets the preset redundancy conditions. The redundancy conditions are determined based on the required memory size and the preset redundancy coefficient. The defragmentation trigger module is used to change the status of the large-scale cloud host creation request from the scheduling state to the suspended state and generate a defragmentation trigger instruction if the preset redundancy conditions are met. The defragmentation trigger instruction includes the required memory size; The target host machine determination module is used to calculate the migration cost of each host machine in the resource pool according to the defragmentation trigger instruction and migration cost function, and select the host machine with the largest current free memory, the fewest number of running cloud hosts and the smallest migration cost as the target host machine. The migration path generation module is used to generate a migration path mapping for the cloud host to be migrated out based on the target host, and to call the hot migration interface of the virtualization platform through automated script orchestration based on the migration path mapping to hot migrate the cloud host to be migrated out to the corresponding receiving host. The real-time polling monitoring module is used to poll and monitor the available memory release status of the target host in real time during the hot migration process. When it is detected that the available memory of the target host reaches or exceeds the required memory size, the resources of the target host are locked, and the creation request of the suspended large-scale cloud host is sent to the target host to complete the deployment and activation of the large-scale cloud host.

Images