A method and system for forcibly evacuating a batch of cloud hosts in the same node in a cloud scenario
By constructing a list of available nodes and sorting them according to the remaining resources, the problem of cloud hosts being unable to be quickly moved to the same node under abnormal circumstances was solved, enabling efficient batch removal of cloud hosts and improving the success rate.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-02-03
- Publication Date
- 2026-03-24
AI Technical Summary
Existing technologies cannot quickly and successfully migrate cloud host groups running on the same node to other nodes when physical servers crash, experience power outages, or network interruptions, resulting in partial success and partial failure.
This paper provides a method for forcibly removing cloud hosts on the same node in a cloud scenario. By obtaining the cloud host information of the failed node, a list of available nodes is constructed and sorted according to the remaining resources. Resource occupation is attempted step by step to ensure that all cloud hosts are successfully removed from the same node.
It enables cloud hosts to be quickly and in batches moved to the same available node, improving the success rate of the move and avoiding inconsistencies such as partial success and partial failure.
Smart Images

Figure CN116233144B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the field of cloud computing, and in particular to a method and system for forcibly evacuating a batch of cloud hosts on the same node in a cloud scenario. BACKGROUND
[0002] Currently, cloud computing products basically have the function of cloud host groups. There are four cloud host group strategies: "forced same node", "forced different node", "prefer same node", and "prefer different node". According to different group strategies, multiple cloud hosts can be divided into different groups (Note: Cloud host groups can be logically understood as a group of cloud hosts. In fact, in the field of cloud computing, cloud host groups represent a scheduling strategy. According to this strategy, cloud hosts can be scheduled to the corresponding node for creation).
[0003] The use scenario of a group of "forced same node" cloud hosts: For example, an enterprise user uses multiple cloud hosts to form a cluster to run business. The cloud hosts in the cluster need to run on the same node to facilitate the fastest memory sharing and improve unified management and operation and maintenance efficiency. Therefore, when creating these cloud hosts, the server_group parameter is specified as the "forced same node" cloud host group, so that the created cloud hosts all run on the same node.
[0004] When a physical server (hereinafter referred to as a node) is abnormally down, power off, network interruption, etc., the cloud hosts running on the node need to be quickly (within 2 minutes) evacuated to other nodes. Cloud native and most current cloud products do not have the function of evacuating a group of cloud hosts that meet the group strategy (forced scheduling to the same computing node). If the multiple cloud hosts to be evacuated are specified by the server_group attribute as the group strategy "forced scheduling to the same computing node", the evacuation will fail.
[0005] Suppose there is a group of cloud hosts (a total of 5) scheduled and created according to the application group strategy "forced scheduling to the same computing node". The host node where the cloud hosts are located is down and needs to be evacuated to other nodes to ensure that the cloud hosts can continue to be used. There are 50 available nodes in the physical cluster (the cluster can be composed of cloud hosts or physical nodes. Here, the cluster composed of physical nodes is expressed). The node scheduler ServerGroupAffinityFilter in the cloud native evacuation process will directly fail to schedule, resulting in that all virtual machines in the group cannot be evacuated.
[0006] If the filter limit of the cloud host group strategy in the scheduling process is ignored, the cloud hosts may be successfully scheduled and evacuated to other nodes. However, the following problems still exist:
[0007] If random scheduling and evacuation are adopted, it cannot be guaranteed that all the cloud hosts in this group are successfully evacuated to the same node, thereby being contrary to the "forced same node" scheduling strategy of the cloud hosts in this group before evacuation;
[0008] If specified node scheduling and evacuation are adopted, partial evacuation success and partial evacuation failure may occur due to insufficient resources of the node or other reasons, and the successfully evacuated cloud hosts cannot be rolled back to the down node, and the time consumption is relatively long. SUMMARY
[0009] The technical problem to be solved by the present application is that when encountering physical server abnormal downtime, power failure, network interruption and the like, a group of cloud hosts running on the physical server need to be quickly evacuated (within 2 minutes) to other physical servers, and cloud native and most current cloud products do not realize the function of evacuating a group of virtual machines meeting the group strategy (forced scheduling to the same computing physical server). The present application provides a forced same node cloud host batch evacuation method in a cloud scenario, and the present application also provides a forced same node cloud host batch evacuation system in a cloud scenario, which can meet the evacuation limit of the cloud host group strategy, can quickly evacuate all cloud hosts to the same available node, can greatly improve the evacuation success rate, and will not cause inconsistent problems of partial success and partial failure, so as to solve the defects caused by the prior art.
[0010] To solve the above technical problems, the present application provides the following technical solutions:
[0011] In a first aspect, a forced same node cloud host batch evacuation method in a cloud scenario is provided, which comprises the following steps:
[0012] Step 1: obtaining all cloud host information on a node when the node is down to form a first cloud host list;
[0013] Step 2: obtaining all cloud hosts in the first cloud host list meeting the evacuation condition to obtain a second cloud host list;
[0014] Step 3: traversing the second cloud host list, selecting a first available node list meeting the required resources of all the cloud hosts in the second cloud host list from a resource database, and sorting to obtain a second available node list;
[0015] Step 4: sequentially selecting a first node in the second available node list and performing resource occupation of all the cloud hosts in the second cloud host list on the first node, and obtaining a node resource occupation record of successful occupation;
[0016] Step 5: judging whether all the cloud hosts in the second cloud host list are successfully occupied;
[0017] If yes, scheduling success feedback data is generated;
[0018] If not, delete the node resource occupation record in the resource database;
[0019] Step 6: sequentially select the next node in the second available node list and perform resource occupation on all cloud hosts in the second cloud host list on the node, and obtain the node resource occupation record of the occupation success;
[0020] Step 7: if the cloud host is not occupied successfully after repeating steps 5-6 to traverse the second available node list, generate a scheduling failure feedback data;
[0021] Step 8: according to the scheduling success feedback data, batch rebuild all cloud hosts in the second cloud host list, and all cloud hosts are successfully rebuilt to successfully evacuate, otherwise, fail to evacuate.
[0022] The above-mentioned forced same node cloud host batch evacuation method in a cloud scenario, wherein the evacuation condition in step 2 includes that the cloud host state is running, the running node is a down node, and the "forced same node" group policy is specified, and all cloud hosts satisfying the above three conditions form a third cloud host list;
[0023] Traverse the third cloud host list to construct a fourth cloud host list according to the required resource information of the cloud host, and sort to obtain the second cloud host list.
[0024] The above-mentioned forced same node cloud host batch evacuation method in a cloud scenario, wherein the sorting rule of the fourth cloud host list is:
[0025] First, sort according to the nuam node number, and if the nuam node number is consistent, sort according to the resource cloud host required resource score, and the nuam node number and the resource score are more in front.
[0026] The above-mentioned forced same node cloud host batch evacuation method in a cloud scenario, wherein in step 3, the second cloud host list is traversed, a first resource request object for each cloud host is constructed and sent to the resource database, and a third available node list is constructed in the resource database according to the resource request object for each cloud host.
[0027] Take the intersection of all the third available node lists to obtain a fourth available node list;
[0028] Take the physical device resources required by each of the second cloud host list and merge into a second resource request object, denoted as REQUEST_SPEC object, obtain a fifth available node list from the resource database that meets the physical device resources required when all the cloud hosts are created together, take the intersection of the fourth available node list and the fifth available node list to obtain the first available node list;
[0029] Sort the first available node list to obtain the second available node list.
[0030] The above-mentioned cloud scenario forced same node cloud host batch evacuation method, wherein the first resource request object is composed of CPU, memory and physical devices for creating corresponding cloud hosts;
[0031] The first available node list contains all available nodes that meet the current cloud host creation and the node resource remaining quantity score of each available node;
[0032] The calculation method of the resource remaining quantity score is as follows: 4 points for 1 CPU, 1 point for 1G memory, and 1 point for 1 physical device;
[0033] The first available node list is sorted according to the node resource remaining quantity score from high to low to obtain the second available node list.
[0034] Secondly, a cloud scenario forced same node cloud host batch evacuation system, comprising a data processing module, a resource database, a scheduling module and a reconstruction module;
[0035] The data processing module is used to obtain all cloud host information on the node when the node is down to form a first cloud host list; also used to obtain all cloud hosts in the first cloud host list that meet the evacuation conditions to obtain a second cloud host list; also used to traverse the second cloud host list and select a first available node list from the resource database that meets all the cloud hosts in the second cloud host list and sort to obtain a second available node list;
[0036] The scheduling module is configured to sequentially select a first node in the second available node list, and perform resource occupation on all the cloud hosts in the second cloud host list on the first node, and obtain a node resource occupation record of successful occupation; determine whether all the cloud hosts in the second cloud host list are successfully occupied; if yes, generate scheduling success feedback data; if no, delete the node resource occupation record in the resource database; and sequentially select a next node in the second available node list, and perform resource occupation on all the cloud hosts in the second cloud host list on the node, and obtain the node resource occupation record of successful occupation; if the cloud hosts are not successfully occupied after repeating the iteration of the second available node list, generate scheduling failure feedback data.
[0037] The reconstruction module is configured to batch-reconstruct all the cloud hosts in the second cloud host list according to the scheduling success feedback data; if all the cloud hosts are successfully reconstructed, the evacuation is successful; otherwise, the evacuation fails.
[0038] In a third aspect, a chip includes a processor configured to invoke and run a computer program from a memory, so that a device installed with the chip performs the method of any one of the first aspect.
[0039] The cloud scenario forced same-node cloud host batch evacuation method and system has the following technical effects:
[0040] The evacuation limitation of the cloud host group strategy can be met, all the cloud hosts can be quickly and batch-evacuated to the same available node, the evacuation success rate can be greatly improved, and the inconsistent problem of partial success and partial failure can be avoided. BRIEF DESCRIPTION OF DRAWINGS
[0041] Figure 1 The cloud scenario forced same-node cloud host batch evacuation method is shown in a flowchart. DETAILED DESCRIPTION
[0042] In order to make the technical means, creative features, purposes and effects of the application easy to understand, the technical solutions in the embodiments of the application are described in detail below in combination with specific drawings. Obviously, the described embodiments are part of the embodiments of the application, rather than all the embodiments.
[0043] Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the application.
[0044] It is to be understood that the structures, proportions, sizes, etc. shown in the drawings attached to the present specification are merely used to cooperate with the content disclosed in the present specification for the understanding and reading of those skilled in the art, and are not used to limit the defined conditions under which the present application can be implemented, and therefore do not have technical substantive significance. Any modification of the structure, change of the proportional relationship, or adjustment of the size, without affecting the effects that can be produced by the present application and the purposes that can be achieved, should still fall within the scope of the technical content disclosed by the present application.
[0045] Meanwhile, the terms such as "upper", "lower", "left", "right", "middle", and "one" cited in the present specification are merely for the clear understanding of the description, and are not used to limit the range in which the present application can be implemented, and the change or adjustment of the relative relationship, without substantially changing the technical content, is also considered as the scope in which the present application can be implemented.
[0046] In a first aspect, a first embodiment is shown as follows: Figure 1 A method for forcibly evacuating a batch of cloud hosts on the same node in a cloud scenario, comprising the following steps:
[0047] Step 1: Obtain all cloud host information on the node when the node is down to form a first cloud host list;
[0048] Step 2: Obtain all cloud hosts in the first cloud host list that meet the evacuation conditions to obtain a second cloud host list;
[0049] Step 3: Traverse the second cloud host list, and select a first available node list that meets the required resources of all cloud hosts in the second cloud host list from a resource database and sort to obtain a second available node list;
[0050] Step 4: Select the first node in the second available node list in sequence and perform resource occupation on all cloud hosts in the second cloud host list on the first node, and obtain the node resource occupation record of the occupation success;
[0051] Step 5: Determine whether all cloud hosts in the second cloud host list are successfully occupied;
[0052] Yes, generate a scheduling success feedback data;
[0053] No, delete the node resource occupation record in the resource database;
[0054] Step 6: Select the next node in the second available node list in sequence and perform resource occupation on all cloud hosts in the second cloud host list on the node, and obtain the node resource occupation record of the occupation success;
[0055] Step 7: If the cloud host is not successfully occupied after traversing the second available node list, generate a scheduling failure feedback data.
[0056] Select nodes in the second available node list from front to back, and let the cloud hosts in the second cloud host list occupy resources in turn from front to back. If resource occupation fails on the same node, all the cloud hosts are rolled back (clean up the resource occupation successful cloud host resource data in the resource database), the next available node is selected for resource occupation, and the retry is performed until all the available nodes fail in resource occupation. Then, a result of scheduling failure is returned, and the resource scheduling process ends.
[0057] If all the cloud hosts in the second cloud host list successfully occupy resources on the same available node in the second available node list, a result of scheduling success is returned immediately, and the resource scheduling process ends.
[0058] Step 8: According to the scheduling success feedback data, all the cloud hosts in the second cloud host list are reconstructed in batches. If all the cloud hosts are successfully reconstructed, the evacuation is successful, otherwise, the evacuation fails.
[0059] The above method for forcibly evacuating cloud hosts in the same node in a cloud scenario, wherein the evacuation conditions in step 2 include that the cloud host state is running, the running node is a down node, and the “forced same node” group policy is specified. All cloud hosts that meet the above three conditions form a third cloud host list.
[0060] The third cloud host list is traversed to construct a fourth cloud host list according to the required resource information of the cloud host, and the fourth cloud host list is sorted to obtain the second cloud host list.
[0061] The data format of each cloud host is as follows:
[0062]
[0063]
[0064] The above data is composed of 3 groups of key / value. The instance is the cloud host uuid, the resource is the required resource score of the cloud host (score = cpu * 4 + memory + accels, 1 CPU requires 4 points, 1 G memory requires 1 point, and 1 physical device accels requires 1 point), and the numa_node_count is the required numa node number.
[0065] The above method for forcibly evacuating cloud hosts in the same node in a cloud scenario, wherein the sorting rule of the fourth cloud host list is:
[0066] First, sort according to the numa node number. If the numa node numbers are consistent, sort according to the resource score of the cloud host. The cloud host with more numa node numbers and resource scores is arranged in the front.
[0067] The fourth cloud host list before sorting is as follows: [
[0069] {"instance": "cloud host 1", "resource": 25, "numa_node_count": 2},
[0070] {"instance": "cloud host 2", "resource": 50, "numa_node_count": 2},
[0071] {"instance": "cloud host 3", "resource": 75, "numa_node_count": 1},
[0072] {"instance": "cloud host 4", "resource": 80, "numa_node_count": 1} ];
[0074] The second cloud host list after sorting is as follows: [
[0076] {"instance": "cloud host 2", "resource": 50, "numa_node_count": 2},
[0077] {"instance": "cloud host 1", "resource": 25, "numa_node_count": 2},
[0078] {"instance": "cloud host 4", "resource": 80, "numa_node_count": 1},
[0079] {"instance": "cloud host 3", "resource": 75, "numa_node_count": 1}
[0080] ]。
[0081] The forced same-node cloud host batch evacuation method in the above cloud scenario, wherein in step 3, the second cloud host list is traversed, a first resource request object for each cloud host is built as a request_spec object and sent to a resource database, and a third available node list is built for each cloud host in the resource database according to the resource request object;
[0082] Taking the intersection of all the third available node lists obtains a fourth available node list in the same data format as the third available node list, and each node in the fourth available node list meets the resource requirement of individual creation of all cloud hosts in the second cloud host list;
[0083] Taking the physical device resource required by each cloud host in the second cloud host list and merging into a second resource request object denoted as REQUEST_SPEC, a fifth available node list (in the same data format as the fourth available node list) that meets the physical device resource required by all cloud hosts together is obtained from the resource database, and the intersection of the fourth available node list and the fifth available node list obtains the first available node list;
[0084] The first available node list is sorted to obtain the second available node list.
[0085] The above is a method for forcibly evacuating cloud hosts in a cloud scenario, wherein the first resource request object is composed of CPU, memory, and physical devices for creating corresponding cloud hosts;
[0086] The first available node list contains all available nodes that meet the current cloud host individually created and the node resource remaining quantity score of each available node;
[0087] The calculation method of the resource remaining quantity score is as follows: 4 points for 1 CPU, 1 point for 1G memory, and 1 point for 1 physical device; the basic resource contains CPU and memory, and an example of the third available node list is as follows:
[0088]
[0089] The data of each available node is composed of key / value, the key is the uuid of the node, and the value is the remaining resource score; the remaining resource score is also composed of key / value, and the value is the score; the key has base_resource_score (remaining basic resource score) and accel_resource_score (remaining physical device score);
[0090] The first available node list is sorted according to the node resource remaining quantity score from high to low to obtain the second available node list;
[0091] First, sort according to the remaining basic resource score (base_resource_score); if the remaining basic resource scores are consistent, sort according to the remaining physical device resource score (accel_resource_score); the resource remaining score is arranged in front; and the second available node list is obtained;
[0092] The first available node list before sorting is as follows: [
[0094] {'nodeA': {'base_resource_score': 280, 'accel_resource_score': 11}},
[0095] {'nodeB': {'base_resource_score': 190, 'accel_resource_score': 8}},
[0096] {'nodeC': {'base_resource_score': 190, 'accel_resource_score': 10}} ];
[0098] The second available node list after sorting is as follows: [
[0100] {'nodeA': {'base_resource_score': 280, 'accel_resource_score': 11}},
[0101] {'nodeC': {'base_resource_score': 190, 'accel_resource_score': 10}},
[0102] {'nodeB': {'base_resource_score': 190, 'accel_resource_score': 8}}
[0103] ]。
[0104] Design of scheduling process:
[0105] Because the resources (CPU, memory, physical devices) required by cloud hosts, and the numa affinity, the combination mode of the resource mapping relationship between each cloud host and the physical node is unpredictable, all the resources required by all cloud hosts cannot be combined and scheduled together, plus resource preemption conflicts and other problems, therefore the resource scheduling result cannot guarantee that the cloud host can successfully occupy resources 100%, but this scheduling design can quickly occupy resources under the condition that the remaining available nodes are not down and the resources are sufficient, and greatly improves the resource occupation success rate;
[0106] The purpose of sorting the cloud host list and the available node list is also to improve the resource occupation success rate, and can solve the resource fragmentation problem when the resources are critical. What is the resource fragmentation problem? Suppose:
[0107] Cloud host 1: 2 numas are needed, 4 CPUs and 8G memory are needed for numa1, and 4 CPUs and 8G memory are needed for numa2;
[0108] Cloud host 2: 1 numa is needed, 2 CPUs and 2G memory are needed for nuam1;
[0109] Available node 1: 2 numas are available, 6 CPUs and 10G memory are left for numa1, and 4 CPUs and 8G memory are left for numa2;
[0110] The resources are just enough to meet the resource occupation of two cloud hosts. If cloud host 2 occupies the resources of numa2 on available node 1 first, the remaining resources on node 1 are 6 CPUs and 10G memory for numa1, and 2 CPUs and 6G memory, which cannot meet the resource occupation of cloud host 2, resulting in resource occupation failure. If the cloud hosts are sorted and cloud host 1 occupies the resources first, both cloud hosts can occupy successfully.
[0111] In a second aspect, a second embodiment, a system for forcibly evacuating batch cloud hosts on the same node in a cloud scenario, comprising a data processing module, a resource database, a scheduling module, and a reconstruction module;
[0112] The data processing module is configured to obtain all cloud host information on a node when the node is down to form a first cloud host list, obtain all cloud hosts in the first cloud host list that meet the evacuation condition to obtain a second cloud host list, and traverse the second cloud host list and select a first available node list that meets all the cloud hosts in the second cloud host list from the resource database to obtain a second available node list after sorting;
[0113] The scheduling module is configured to sequentially select a first node in the second available node list, and perform resource occupation on the first node for all cloud hosts in the second cloud host list, and obtain node resource occupation records of successful occupation, determine whether all cloud hosts in the second cloud host list are successfully occupied, if yes, generate a scheduling success feedback data, if no, delete the node resource occupation records in the resource database, and sequentially select a next node in the second available node list, and perform resource occupation on the node for all cloud hosts in the second cloud host list, and obtain node resource occupation records of successful occupation, and if all cloud hosts are not successfully occupied after traversing the second available node list, generate a scheduling failure feedback data;
[0114] The reconstruction module is configured to batch-reconstruct all cloud hosts in the second cloud host list according to the scheduling success feedback data, and if all cloud hosts are successfully reconstructed, the evacuation is successful, otherwise the evacuation fails.
[0115] In a third aspect, a chip, comprising: a processor configured to invoke and run a computer program from a memory, so that a device installed with the chip performs the method according to any one of the first aspect.
[0116] For example, the memory can include random access memory, flash memory, read only memory, programmable read only memory, non-volatile memory, or registers, etc.
[0117] The processor can be a central processing unit (CPU) or a graphic processing unit (GPU), etc.
[0118] The processor can execute the execution instructions stored in the memory, thereby realizing the various processes described herein.
[0119] It can be understood that the memory in the embodiments can be a volatile memory or a non-volatile memory, or can include both volatile and non-volatile memories.
[0120] The non-volatile memory can be a ROM (Read-Only Memory), a PROM (Programmable ROM), an EPROM (Erasable PROM), an EEPROM (Electrically EPROM), or a flash memory.
[0121] The volatile memory can be a RAM (Random Access Memory) used as an external cache.
[0122] By way of example, and not limitation, many forms of RAM can be used, such as SRAM (Static RAM), DRAM (Dynamic RAM), SDRAM (Synchronous DRAM), DDR SDRAM (Double Data Rate SDRAM), ESDRAM (Enhanced SDRAM), SLDRAM (Synchlink DRAM), and DRDRAM (Direct Rambus DRAM). The memory described herein is intended to include, among others, these and any other suitable types of memory.
[0123] In some embodiments, the memory stores elements, upgrade packages, executable units or data structures, or their subsets, or their extended sets, such as operating systems and application programs;
[0124] The operating system includes various system programs, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks.
[0125] The application programs include various application programs for implementing various application services. The programs for implementing the method embodiments of the present application can be included in the application programs.
[0126] Those skilled in the art can understand that the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein can be realized in electronic hardware or a combination of software and electronic hardware.
[0127] Whether these functions are realized in hardware or software depends on the specific application and design constraints of the technical solution.
[0128] Those skilled in the art can use different ways to realize the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.
[0129] In the embodiments of the present application, the disclosed system, device and method can be realized in other ways.
[0130] For example, the division of units or modules is only a logical functional division, and there can be another division way in actual implementation.
[0131] For example, multiple units or modules or components can be combined or integrated into another system.
[0132] In addition, the functional units or modules in the embodiments of the present application can be integrated in one processing unit or module, or can be separate physical entities, etc.
[0133] It should be understood that in various embodiments of the present application, the size of the sequence number of each process does not mean the execution order, and the execution order of each process should be determined according to its function and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.
[0134] The functions, if realized in the form of software functional units and sold or used as independent products, can be stored in a machine-readable storage medium.
[0135] Therefore, the technical scheme of the present application can be embodied in the form of a software product, which can be stored in a machine readable storage medium and can include a plurality of instructions to cause an electronic device to execute all or part of the processes of the technical scheme described in the embodiments of the present application.
[0136] The storage medium can include ROM, RAM, removable disks, hard disks, magnetic disks, or optical disks, and various media that can store program codes.
[0137] In summary, the method and system for forcibly evacuating a batch of cloud hosts on the same node in a cloud scenario can meet the evacuation limit of the cloud host group policy, can quickly evacuate all cloud hosts to the same available node, and can greatly improve the evacuation success rate without inconsistent problems such as partial success and partial failure.
[0138] The specific embodiments of the application are described above. It should be understood that the application is not limited to the specific embodiments described above, and that the devices and structures not described in detail should be understood as being implemented in a conventional manner in the art; those skilled in the art can make various modifications or changes within the scope of the claims, and make several simple deductions, modifications or substitutions, which do not affect the essential content of the application.
Claims
1. A method for forcibly removing cloud hosts on the same node in a cloud scenario, characterized in that, Includes the following steps: Step 1: Obtain information on all cloud hosts on the node when it crashes to form a first cloud host list; Step 2: Obtain all cloud hosts in the first cloud host list that meet the withdrawal conditions and process them to obtain the second cloud host list; Step 3: Traverse the second cloud host list, and select the first available node list that satisfies the resources required by all the cloud hosts in the second cloud host list from the resource database, and sort it to obtain the second available node list; Step 4: Select the first node in the second available node list in sequence and occupy the resources of all the cloud hosts in the second cloud host list on the first node, and obtain the resource occupation record of the successfully occupied node; Step 5: Determine whether all the cloud servers in the second cloud server list have been successfully occupied; If yes, then generate scheduling success feedback data; No, then delete the node resource usage record in the resource database; Step 6: Select the next node in the second available node list in sequence and occupy the resources of all the cloud hosts in the second cloud host list on that node, and obtain the resource occupation record of the node that was successfully occupied; Step 7: After repeating steps 5-6 to traverse the second available node list, if the cloud host fails to be successfully occupied, generate scheduling failure feedback data; Step 8: Rebuild all cloud hosts in the second cloud host list in batches according to the successful scheduling feedback data. If all cloud hosts are successfully rebuilt, the withdrawal is successful; otherwise, the withdrawal fails.
2. The method for forcibly removing cloud hosts on the same node in a cloud scenario as described in claim 1, characterized in that, The evacuation conditions in step 2 include the cloud host being in a running state, the running node being a down node, and being assigned the "force same node" group policy. All cloud hosts that meet the above three conditions simultaneously form a third cloud host list. The third cloud host list is traversed to construct a fourth cloud host list based on the resource information required by the cloud hosts, and then sorted to obtain the second cloud host list.
3. The method for forcibly removing cloud hosts on the same node in a cloud scenario as described in claim 2, characterized in that, The sorting rules for the fourth cloud host list are as follows: First, sort by the number of nuam nodes. If the number of nuam nodes is the same, sort by the resource score required by the cloud server. The server with more nuam nodes and more resource scores will be ranked first.
4. A method for forcibly removing cloud hosts on the same node in a cloud scenario as described in claim 2 or 3, characterized in that, In step 3, the second cloud host list is traversed, a first resource request object, denoted as request_spec, is constructed for each cloud host and sent to the resource database. In the resource database, a third available node list is constructed for each cloud host based on the resource request object. The fourth available node list is obtained by taking the intersection of all the third available node lists; Take the physical device resources required by each cloud host in the second cloud host list and merge them into a second resource request object, denoted as REQUEST_SPEC object. Obtain the fifth available node list from the resource database that satisfies the physical device resources required when all cloud hosts are created together. Take the intersection of the fourth available node list and the fifth available node list to obtain the first available node list. The second list of available nodes is obtained by sorting the first list of available nodes.
5. A method for forcibly removing cloud hosts on the same node in a cloud scenario as described in claim 4, characterized in that, In the above-mentioned method for forcibly removing cloud hosts on the same node in a cloud scenario, the first resource request object consists of the CPU, memory, and physical devices that create the corresponding cloud host; The first list of available nodes includes all available nodes that can be created individually by the current cloud host and a score for the remaining number of node resources for each available node; The score for the remaining resources is calculated as follows: 4 points for 1 CPU remaining, 1 point for 1 GB of memory remaining, and 1 point for 1 physical device remaining. The first list of available nodes is sorted from highest to lowest according to the remaining resource score of the nodes to obtain the second list of available nodes.
6. A system for forcibly removing cloud hosts on the same node in a cloud scenario, characterized in that, It includes a data processing module, a resource database, a scheduling module, and a reconstruction module; The data processing module is used to obtain information on all cloud hosts on the node when the node crashes to form a first cloud host list; it is also used to obtain all cloud hosts in the first cloud host list that meet the evacuation conditions to obtain a second cloud host list; it is also used to traverse the second cloud host list, and select a first available node list from the resource database that meets all cloud hosts in the second cloud host list, and sort it to obtain a second available node list. The scheduling module is used to sequentially select the first node in the second available node list and occupy resources on the first node for all the cloud hosts in the second cloud host list, and obtain the resource occupation record of the successfully occupied node. Determine whether all cloud hosts in the second cloud host list have been successfully occupied; If yes, then generate scheduling success feedback data; If not, delete the node resource occupation record in the resource database; it is also used to sequentially select the next node in the second available node list and occupy the resources of all the cloud hosts in the second cloud host list on that node, and obtain the node resource occupation record of the successfully occupied node; if the cloud host is not successfully occupied after repeatedly traversing the second available node list, generate scheduling failure feedback data. The reconstruction module is used to reconstruct all the cloud hosts in the second cloud host list in batches according to the scheduling success feedback data. If all the cloud hosts are reconstructed successfully, the withdrawal is successful; otherwise, the withdrawal fails.
7. A chip, wherein, include: A processor for retrieving and running a computer program from memory, causing a device on which the chip is mounted to perform the method as described in any one of claims 1-5.
Citation Information
Patent Citations
Cloud computing resource management method, device and equipment and computer readable storage medium
CN109669762A
Double-virtual-machine quasi-synchronous evacuation method under disaster risk model
CN110058970A