Deployment relationship adjustment method, apparatus, cluster, storage medium, and program product

Abstract

The present invention relates to the technical field of computers. Disclosed are a deployment relationship adjustment method, an apparatus, a cluster, a storage medium, and a program product, used for providing services with different target availabilities on a large-scale server cluster. A virtual node set composed of virtual nodes jointly used for providing a service of target availability is deployed on a server cluster, and the difference between failure rates of servers in the server cluster is greater than a first target difference. The method comprises: predicting the availability of a service on the basis of a first deployment relationship and a failure rate of a server corresponding to the first deployment relationship; when the availability does not meet a target availability, adjusting the first deployment relationship to obtain a second deployment relationship, wherein the availability of the service provided when the virtual node set is deployed on the server cluster on the basis of the second deployment relationship is higher than the availability of the service provided when the virtual node set is deployed on the server cluster on the basis of the first deployment relationship; and deploying the virtual node set on the server cluster on the basis of the second deployment relationship.

Description

Deployment relationship adjustment methods, devices, clusters, storage media and program products

[0001] This application claims priority to Chinese patent application filed on April 15, 2025, with application number 202510468471.3 and entitled "Deployment Relationship Adjustment Method, Apparatus, Cluster, Storage Medium and Program Product", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of computer technology, and in particular to methods, apparatus, clusters, storage media, and program products for adjusting deployment relationships. Background Technology

[0003] While various cloud computing vendors offer a wide range of cloud service products to their users, they also categorize these products into different service levels to further diversify their offerings and cater to a wider range of users with diverse needs. Once a user purchases a product at a specific service level, the vendor is obligated to adhere to the corresponding service level agreement (SLA) for the agreed-upon service period. Failure to meet the SLA's requirements will negatively impact the user experience.

[0004] To ensure that products with different service levels can achieve their corresponding service levels, the traditional approach is to first create a resource pool using servers of similar reliability, based on indicators such as the reliability of each server. This results in multiple resource pools of different service levels, and then products of different service levels are deployed to different resource pools. This approach limits the size of each resource pool, making it difficult to meet users' elastic resource demands, and also leads to low resource utilization. Summary of the Invention

[0005] This application provides a method, apparatus, cluster, storage medium, and program product for adjusting deployment relationships. By dynamically adjusting the deployment relationships of virtual nodes in a server cluster, it enables multiple differentiated SLA services (with different target availability) to be deployed on the same large-scale server cluster (which may include servers with large differences in failure rates). While ensuring that the services meet the target availability, it provides stronger resource elasticity and improves resource utilization.

[0006] In a first aspect, this application provides a deployment relationship adjustment method applied to the control node of a server cluster. The server cluster has a set of virtual nodes deployed on it, and the virtual nodes in the set collectively provide a service with a target availability. The difference in failure rates between servers in the server cluster is greater than a first target difference. The method includes: predicting service availability based on a first deployment relationship of the virtual node set in the server cluster and the failure rates of the servers corresponding to the first deployment relationship; adjusting the deployment relationship of at least one virtual node in the virtual node set on the server cluster when the availability does not meet the target availability, to obtain a second deployment relationship of the virtual node set on the server cluster; wherein the availability of the service provided when the virtual node set is deployed on the server cluster according to the second deployment relationship is higher than the availability of the service provided when deployed on the server cluster according to the first deployment relationship; and deploying the virtual node set on the server cluster according to the second deployment relationship.

[0007] It is understandable that the difference in failure rates among servers in the server cluster in this application is greater than the first target difference (i.e., a larger difference), which aims to demonstrate that the server cluster in this application can achieve a large scale. This differs from the traditional technical solution of "first dividing the server cluster into smaller resource pools of different levels, and then deploying services to the corresponding smaller resource pools." The solution provided in this application does not require dividing the server cluster; different services (or services with different availability requirements) can share the server cluster. This provides users with sufficient flexibility, reducing the impact of sudden increases in computing resource demand caused by business surges on the entire server cluster. Furthermore, by predicting service availability, if it is detected that a service may not meet the target availability, the deployment relationship of some / all virtual nodes in the set of virtual nodes used to provide that service on the server cluster can be adjusted in a timely manner to improve the availability of that service and achieve the target availability goal. In this way, servers with large differences in failure rates can be fully utilized in this server cluster, improving resource utilization.

[0008] It is worth noting that in actual implementation, there is no need to detect the relationship between the failure rates of different servers in the server cluster and the difference from the first target. This application also supports scenarios where the failure rates of different servers are less than the difference from the first target.

[0009] In one possible implementation, adjusting the deployment relationship of at least one virtual node in the virtual node set on the server cluster to obtain a second deployment relationship of the virtual node set on the server cluster includes: adjusting at least one virtual node in the virtual node set from a first source server to a first target server to obtain a second deployment relationship of the virtual node set on the server cluster; wherein the failure rate of the first target server is less than the failure rate of the first source server.

[0010] It is understandable that by adjusting virtual nodes to servers with lower failure rates, the average failure rate of the servers corresponding to the set of virtual nodes to which the virtual node belongs can be reduced, the expected downtime of the services provided by the set can be reduced, and the availability of services can be improved without changing the service cycle.

[0011] In one possible implementation, the method further includes: in response to receiving a first expansion request, adding a first virtual node deployed on a first server in the server cluster to a set of virtual nodes to obtain an expanded set of virtual nodes; wherein the first expansion request is used to request the addition of virtual nodes to the set of virtual nodes; and the failure rate of the first server is lower than the maximum value of the failure rates of the servers corresponding to the first deployment relationship.

[0012] Understandably, adding virtual nodes from servers with lower failure rates to a virtual node set can both expand the capacity of that set and reduce the average failure rate of the servers corresponding to that set, thereby improving service availability.

[0013] In one possible implementation, when availability does not meet the target availability, the deployment relationship of at least one virtual node in the virtual node set on the server cluster is adjusted to obtain a second deployment relationship of the virtual node set on the server cluster. This includes: when availability does not meet the target availability, inputting the first deployment relationship, the failure rate of each server in the server cluster, and the target availability into the target model; the target model is used to determine the deployment relationship that can meet the target availability; obtaining the second deployment relationship output by the target model; wherein, the availability of the service provided by the virtual node set when deployed on the server cluster according to the second deployment relationship meets the target availability.

[0014] Understandably, by using a pre-trained target model, a second deployment relationship that can meet the target availability can be obtained efficiently, thus improving the efficiency of adjusting the deployment relationship.

[0015] In one possible implementation, when the availability does not meet the target availability, the deployment relationship of at least one virtual node in the virtual node set on the server cluster is adjusted to obtain a second deployment relationship of the virtual node set on the server cluster. This includes: adjusting the deployment relationship of at least one virtual node in the virtual node set on the server cluster to obtain an adjusted deployment relationship; predicting the service availability again based on the adjusted deployment relationship and the failure rate of the server corresponding to the adjusted deployment relationship; the availability obtained from the second prediction is higher than the availability obtained from the previous prediction; repeating the above steps until the availability obtained from the i-th prediction meets the target availability, and determining the deployment relationship corresponding to the availability obtained from the i-th prediction as the second deployment relationship, where i is an integer greater than 1.

[0016] Understandably, by adjusting the deployment relationship multiple times, the average failure rate of the server corresponding to the virtual node set can be reduced each time until a second deployment relationship that can meet the target availability is obtained. This method does not require pre-training the model, has a low deployment threshold, and can also ensure that the virtual node set provides services that meet the target availability when it is deployed according to the second deployment relationship.

[0017] In one possible implementation, if the availability satisfies the target availability, the method further includes: if the difference between availability and target availability exceeds the second target difference, adjusting at least one virtual node in the virtual node cluster from the second source server to the second target server to obtain a third deployment relationship of the virtual node set in the server cluster; wherein the failure rate of the second target server is greater than the failure rate of the second source server.

[0018] Understandably, when the predicted availability meets the target availability, and there is a significant difference between the actual availability and the target availability, adjusting at least one virtual node in the virtual node cluster to a server with a higher failure rate can ensure that the server with the higher failure rate is also fully utilized, thereby improving resource utilization. At the same time, it reduces the resource dependence on the server with the lower failure rate, making the overall load of the server cluster more balanced.

[0019] In one possible implementation, the method further includes: in response to receiving a second expansion request, adding a first virtual node deployed on a second server in the server cluster to a set of virtual nodes to obtain an expanded set of virtual nodes; wherein the second expansion request is used to request the addition of virtual nodes to the set of virtual nodes; and the failure rate of the second server is higher than the minimum failure rate of the servers corresponding to the first deployment relationship.

[0020] Understandably, when the predicted availability meets the target availability, and there is a significant difference between the actual availability and the target availability, adding virtual nodes from servers with higher failure rates to the virtual node set can both expand the capacity of the virtual node set and ensure that servers with higher failure rates are fully utilized, thereby improving resource utilization.

[0021] In one possible implementation, service availability is predicted based on the first deployment relationship of the virtual node set in the server cluster and the failure rate of the server corresponding to the first deployment relationship, including: obtaining historical data on service availability; and predicting service availability based on the first deployment relationship of the virtual node set in the server cluster and the failure rate and historical data of the server corresponding to the first deployment relationship.

[0022] It is understandable that historical data on service availability includes, but is not limited to, the time during which the service has been unavailable in the current service cycle. Combining this historical data can improve the accuracy of predicting service availability.

[0023] In one possible implementation, the difference between the failure rate of the target component in the server corresponding to the second deployment relationship and the failure rate index of the target component required by the service is smaller than the difference of the third target.

[0024] It is understandable that when adjusting the deployment relationship of virtual nodes on the server cluster, ensuring that the failure rate of the target components in the server meets the failure rate index requirements can better meet user needs and avoid the impact of excessive component failure rate on business.

[0025] In one possible implementation, the method further includes: identifying abnormal servers from the servers corresponding to the set of virtual nodes; wherein the abnormal server is a server with a failure rate higher than a failure rate threshold; and adjusting the virtual nodes on the abnormal server to other servers in the server cluster; wherein the failure rate of the other servers is lower than the failure rate threshold.

[0026] Understandably, when an abnormal server with a failure rate higher than the failure rate threshold is detected, the virtual nodes deployed on that abnormal server should be promptly moved to other servers with lower failure rates to prevent the excessively high failure rate from severely reducing service availability.

[0027] Secondly, this application provides a deployment relationship adjustment apparatus for performing any of the deployment relationship adjustment methods provided in the first aspect above.

[0028] In one possible implementation, this application can divide the deployment relationship adjustment device into functional modules according to the method provided in the first aspect above. For example, each function can be divided into a separate functional module, or two or more functions can be integrated into one module. For example, this application can divide the deployment relationship adjustment device into a prediction module, a first adjustment module, and a deployment module according to function. The descriptions of the possible technical solutions and beneficial effects performed by the above-described functional modules can refer to the technical solutions provided in the first aspect above or its corresponding possible implementations, and will not be repeated here.

[0029] Thirdly, embodiments of this application provide a computing device, which includes a processor and a memory, with the processor coupled to the memory; the memory is used to store computer instructions, which are loaded and executed by the processor to enable the computing device to implement the deployment relationship adjustment method provided in the first aspect and various alternative implementations described above.

[0030] Fourthly, embodiments of this application provide a computing device cluster, which includes at least one computing device, each computing device including a processor and a memory, the processor being coupled to the memory; the processor of the at least one computing device is used to execute computer instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the deployment relationship adjustment method provided in the first aspect and various optional implementations described above.

[0031] Fifthly, embodiments of this application provide a computer-readable storage medium storing at least one computer program instruction, which is loaded and executed by a processor to implement the deployment relationship adjustment method provided in the first aspect and various alternative implementations described above.

[0032] Sixthly, embodiments of this application provide a computer program product including computer instructions stored in a computer-readable storage medium. A processor of a computing device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computing device to perform the deployment relationship adjustment method provided in the first aspect and various optional implementations described above.

[0033] For a detailed description of aspects two through six and their various implementations in this application, please refer to the detailed description in aspect one and its various implementations; and for a detailed description of the beneficial effects of aspects two through six and their various implementations, please refer to the beneficial effect analysis in aspect one and its various implementations, which will not be repeated here.

[0034] These or other aspects of this application will become more readily apparent in the following description. Attached Figure Description

[0035] Figure 1 is a schematic diagram of the deployment relationship under a traditional technology;

[0036] Figure 2 is a schematic diagram of the architecture of a cloud computing system provided in an embodiment of this application;

[0037] Figure 3 is a schematic diagram of the architecture of a cloud service deployment platform provided in an embodiment of this application;

[0038] Figure 4 is an exemplary software architecture diagram of the deployment relationship adjustment system involved in the embodiment shown in Figure 3;

[0039] Figure 5 is a schematic diagram of the structure of a computing device provided in an embodiment of this application;

[0040] Figure 6 is a flowchart of a deployment relationship adjustment method provided in an embodiment of this application;

[0041] Figure 7 is a schematic diagram of a deployment relationship involved in the embodiment shown in Figure 6;

[0042] Figure 8 is a comparative diagram showing the deployment relationship before and after adjustment in the embodiment shown in Figure 7;

[0043] Figure 9 is a schematic diagram of a module interaction provided in an embodiment of this application;

[0044] Figure 10 is a schematic diagram of a deployment relationship adjustment device provided in an embodiment of this application;

[0045] Figure 11 is a schematic diagram of a computing device provided in an embodiment of this application;

[0046] Figure 12 is a schematic diagram of a computing device cluster provided in an embodiment of this application;

[0047] Figure 13 is a schematic diagram of a connection method between computing device clusters provided in an embodiment of this application. Detailed Implementation

[0048] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0049] In this article, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0050] Furthermore, in the description of the embodiments of this application, unless otherwise stated, "multiple" refers to two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0051] Furthermore, to facilitate a clear description of the technical solutions in the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" are not necessarily different. Meanwhile, in the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is being used as an example, illustration, or description. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of terms such as "exemplary" or "for example" is intended to present related concepts in a concrete manner for ease of understanding.

[0052] First, the application scenarios of the embodiments of this application will be introduced by way of example.

[0053] When cloud service providers offer a variety of cloud service products to users, they also categorize these products into different tiers, each corresponding to a different level of service. In other words, when users choose different tiers of cloud service products, they are also choosing the service levels promised in different Service Level Agreements (SLAs). SLAs often involve one or more evaluation metrics and corresponding calculation methods, as well as handling methods in case the relevant cloud service product fails to meet the standards.

[0054] Service availability is a common core metric. Availability refers to the promised service availability rate within a service cycle. An example calculation method is as follows:

[0055] To ensure their products meet certain availability metrics, cloud service providers often employ a traditional solution: first, classify servers based on one or more metrics such as hardware failure rate, reliability, and computing power; then, utilize servers of different tiers to form multiple resource pools of varying levels. Before deployment, based on the required availability metrics and other data, calculate which resource pool the product should be deployed in to meet those metrics, and then complete the deployment.

[0056] Figure 1 illustrates a deployment relationship under a traditional technology. In Figure 1, each server first undergoes a health level assessment, and then, based on their health levels, they are grouped into three resource pools as shown in Figure 1. Specifically, resource pool 1 contains servers with a health level of A, resource pool 2 contains servers with a health level of B, and resource pool 3 contains servers with a health level of C. The health status of the servers corresponding to health levels A through C decreases sequentially, becoming progressively worse.

[0057] Furthermore, traditional technologies deploy services with different SLA levels on different resource pools. As shown in Figure 1, the three nodes (which can be virtual machines or containers, etc.) corresponding to service A with a target availability of 99% are deployed in resource pool 1, the three nodes corresponding to service B with a target availability of 97% are deployed in resource pool 2, and the three nodes corresponding to service C with a target availability of 95% are deployed in resource pool 3.

[0058] This traditional method divides computing resources into multiple small, independent resource pools. Even when resource pool 1 in Figure 1 is fully loaded, it cannot allocate idle computing resources from resource pools 2 or 3. Considering the resource utilization of multiple pools, this approach has low overall resource utilization. Moreover, the small size and low elasticity of each independent resource pool make it unable to respond promptly to fluctuations in user workload. In the event of a sudden surge in workload, the probability of overload or even crash is high.

[0059] In view of this, this application proposes a deployment relationship adjustment method. By dynamically adjusting the deployment relationship of virtual nodes on servers, multiple differentiated SLA services (with different target availability) can be deployed in the same large resource pool. The aforementioned large resource pool includes servers with significantly different failure rates (compared to the small resource pools in traditional technologies), and can meet the needs of differentiated SLA services, significantly improving resource utilization. Furthermore, the larger-scale resource pool can provide better resource elasticity to meet user needs.

[0060] In some feasible embodiments, the method can be applied to the control node of a server cluster, on which a set of virtual nodes is deployed. The virtual nodes in the set of virtual nodes collectively provide a service with a target availability, and the difference in failure rates between servers in the server cluster is greater than a first target difference. Specifically, the method includes: predicting service availability based on a first deployment relationship of the set of virtual nodes in the server cluster and the failure rate of the servers corresponding to the first deployment relationship; if the availability does not meet the target availability, adjusting the deployment relationship of at least one virtual node in the set of virtual nodes in the server cluster to obtain a second deployment relationship of the set of virtual nodes in the server cluster; wherein the availability of the service provided when the set of virtual nodes is deployed in the server cluster according to the second deployment relationship is higher than the availability of the service provided when deployed in the server cluster according to the first deployment relationship; and deploying the set of virtual nodes in the server cluster according to the second deployment relationship.

[0061] Because the difference in failure rates among servers in a server cluster can be greater than the initial target difference (a significant difference), meaning that servers traditionally rigidly divided into multiple distinct clusters can collectively form a single large-scale server cluster within the application, this provides ample flexibility for user services and reduces the impact of sudden surges in computing resource demands on the entire server cluster. Furthermore, by predicting service availability, if the predicted availability of a service fails to meet the target availability, the deployment of some or all virtual nodes in the set of virtual nodes providing that service across the server cluster can be adjusted in a timely manner to improve the service's availability and achieve the target availability goal. In this way, servers with significantly different failure rates can be fully utilized within the server cluster, significantly improving resource utilization.

[0062] Secondly, the system architecture of the embodiments of this application will be described by way of example.

[0063] Figure 2 is a schematic diagram of the architecture of a cloud computing system provided in an embodiment of this application. As shown in Figure 2, the cloud computing system 100 includes a computing server cluster 110, a storage server cluster 120, a management server cluster 130, a network device cluster 140, and a user terminal 150. The computing server cluster 110, the storage server cluster 120, and the management server cluster 130 communicate with the user terminal 150 through the network device cluster 140.

[0064] The computing server cluster 110 includes one or more computing servers (two computing servers, namely computing server 111 and computing server 112, are shown in Figure 2, but are not limited to two computing servers).

[0065] Computing servers, as computing resources within the cloud computing system 100, such as servers and desktop computers, are used to generate and allocate computing resources based on virtualization technology and user needs. At the hardware level, computing servers are equipped with processors and memory (not shown in Figure 2; the specific hardware structure can be found in Figure 5 below, and will not be elaborated upon here). The computing functions of the computing server are implemented by the processor running programs in memory. The computing server can also read / write data from various storage servers in the storage server cluster 120 according to user needs.

[0066] The storage server cluster 120 includes one or more storage servers (two storage servers, namely storage server 121 and storage server 122, are shown in Figure 2, but are not limited to two storage servers).

[0067] Storage servers, as storage resources within the cloud computing system 100, such as servers, desktop computers, or storage array controllers and hard disk enclosures, provide logical disk storage and integrated backup services for cloud virtual machines within the cloud computing system 100. In terms of hardware, storage servers are equipped with network interface cards (NICs), processors, and memory. The processor in the storage server processes data from outside the storage server. The NIC controls the access process to the memory, such as controlling address signals, data signals, and various command signals, enabling the storage server to provide the memory as a storage resource to users. Memory is used to store data and may include RAM and / or hard disks. RAM refers to internal memory that directly exchanges data with the processor; RAM can quickly read and write data at any time, serving as temporary data storage for the operating system or other running programs. Unlike RAM, hard disks are slower to read and write data and are typically used for persistent data storage.

[0068] The management server cluster 130 includes one or more management servers (two management servers, namely management server 131 and management server 132, are shown in Figure 2, but are not limited to two management servers).

[0069] The management server is used to manage all computing services, shared storage, and network of the entire cloud computing system 100, and also provides users or administrators with an application program interface (API) for managing the entire node. In this application, the cloud computing system 100 can provide the program product of this application to users by providing an accessible application program interface.

[0070] Network device cluster 140 includes one or more switches and routers, as shown in Figure 2. In this embodiment, network device cluster 140 includes router 141, switch 142, switch 143, switch 144, and switch 145. User terminal 150 is connected to router 141 via the Internet. Router 141 is then connected to switch 143 via switch 142. Switch 143 is connected to each computing server in computing server cluster 110. Switch 144 is connected to each computing server in computing server cluster 110 and each storage server in storage server cluster 120. Switch 145 is connected to each computing server in computing server cluster 110, each storage server in storage server cluster 120, and each management server in management server cluster 130.

[0071] Optionally, the number and type of switches included in the network device cluster 140 can be adjusted according to the needs of the cloud computing system 100. Switches 142, 143, 144, and 145 can be switches with different functions. For example, switch 142 is a core switch, while switches 143, 144, and 145 are switches used to manage specific network segments. For instance, switch 142 can be a core switch, switch 143 can be an internal / external switching network segment switch, switch 144 can be a storage network segment switch, and switch 145 can be a management network segment switch.

[0072] User terminal 150 includes one or more user terminals (two user terminals, namely user terminal 151 and user terminal 152, are shown in Figure 2, but are not limited to two user terminals). The user terminal contains the interfaces and applications required for accessing the cloud computing system 100.

[0073] It is worth noting that Figure 2 is only a schematic diagram and should not be construed as a limitation of this application. The cloud computing system 100 may also include other devices, which are not shown in Figure 2.

[0074] The computing servers and storage servers in the cloud computing system 100 provided in this application can be nodes in a cloud platform. Based on the equipment of the cloud computing system 100 shown in Figure 2, the cloud computing system 100 implements the functions of computing nodes, storage nodes, and other nodes based on Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS), providing services (such as computing services, storage services, and network services) to user terminals 150 through these nodes. These nodes can be service nodes (such as computing nodes and storage nodes) in the cloud obtained by virtualizing the resources (such as computing resources and storage resources) of the cloud computing system 100.

[0075] Based on the cloud computing architecture shown in Figure 2, Figure 3 is a schematic diagram of the architecture of a cloud service deployment platform provided in an embodiment of this application. Specifically, the server cluster 2100 in the cloud service deployment platform 2000 shown in Figure 3 can be the computing server cluster 110 in Figure 2, while the deployment relationship adjustment system 2200 shown in Figure 3 can run on the control node of the server cluster 2100, or it can run on an independent management device (e.g., the management server cluster 130 in Figure 2). As an example, the server cluster 2100 in Figure 3 specifically includes servers 2110 to 2140, but in actual deployment, there can be more servers; this application does not impose any limitations on this.

[0076] Furthermore, the cloud service deployment platform 2000 can interact with users' terminal devices (terminal devices 2500 and 2600 as shown in Figure 3) through the network (including but not limited to the Internet), and dynamically and flexibly adjust the deployment relationship through the deployment relationship adjustment system 2200 based on the interaction information, the deployment status of each virtual node set, and the load status of computing resources in the server cluster, etc., to meet availability requirements.

[0077] As an example, Figure 3 shows a virtual node set 2300 (specifically including virtual nodes 2310-2330) and a virtual node set 2400 (specifically including virtual nodes 2410 and 2420). The different virtual node sets are deployed on a large-scale server cluster (this application can support large differences in failure rates between servers in the server cluster), share the resources of the cluster, and provide services with different availability (or SLA levels).

[0078] Furthermore, Figure 4 is an exemplary software architecture diagram of the deployment relationship adjustment system involved in the embodiment shown in Figure 3, wherein the deployment relationship adjustment system 2200 shown in Figure 4 includes at least: a service satisfaction assessment module 2210 and an adjustment module 2220.

[0079] Specifically, the service satisfaction assessment module 2210 can at least predict whether each virtual node set can meet its corresponding target availability according to the current deployment relationship, based on the deployment status of each virtual node set, the failure rate of the server where the virtual nodes in each virtual node set are located, and the target availability of the services provided by each virtual node set, and output corresponding adjustment strategies when necessary.

[0080] The adjustment module 2220 can at least be used to adjust the deployment relationship of virtual nodes in the server cluster according to the adjustment strategy output by the service satisfaction assessment module 2210.

[0081] Optionally, the deployment relationship adjustment system 2200 shown in Figure 4 may further include one or more of the following: a service configuration and management module 2230, a service status monitoring module 2240, a server failure rate prediction module 2250, a server status acquisition module 2260, and a server failure detection module 2270. The adjustment module 2220 may be further divided into a resource scheduling module 2221 and a migration module 2222.

[0082] Specifically, the resource scheduling module 2221 can at least be used to schedule virtual nodes that are predicted to need future expansion due to their inability to meet target availability to servers with lower failure rates (specifically, lower than the maximum failure rate among the current servers corresponding to that virtual node set). The specific number of nodes to be scheduled and the servers with the target failure rate can be calculated by the scheduling algorithm based on service status information, server failure rates, and current deployment relationships. The aforementioned scheduling algorithm can be implemented using simple rules or by using a scheduling optimization algorithm.

[0083] The migration module 2222, in collaboration with the resource scheduling module 2221, can at least improve service availability by migrating some virtual nodes from high-failure-rate servers to low-failure-rate servers according to the adjustment strategy output by the service satisfaction assessment module 2210. This reduces the average failure rate of the servers corresponding to the virtual node cluster, decreases the expected downtime, and improves availability. The specific migration orchestration algorithm can be implemented through rules or optimization algorithms. Hot migration technology can be selected during migration to achieve a seamless virtual node migration process for users; this application does not impose any restrictions on this.

[0084] The service configuration and management module 2230 is at least capable of defining (or receiving user-defined) different SLAs (including target availability) for services based on business needs and managing them.

[0085] The service status monitoring module 2240 can at least be used to record status-related information of the services provided by each set of virtual nodes, including but not limited to the interruption duration, number of failures, availability, and failure rate during historical service cycles and the current service cycle.

[0086] The server failure rate prediction module 2250 can at least be used to predict the server failure rate based on the hardware device status information collected by the server status acquisition module 2260 and the failure rate prediction model. Specifically, it can output the server failure rate (and the corresponding confidence level). The aforementioned failure rate prediction model is constructed using one or more of expert experience and machine learning models (including neural network models).

[0087] The server status acquisition module 2260 can at least be used to collect status-related information of each server (and may further include one or more components in the server) in the server cluster, including but not limited to: temperature information, batch information, historical maintenance information, environmental information, operating status information, alarm information, service time information, error logs, etc.

[0088] The server fault detection module 2270 can at least be used to perform in-depth detection on abnormal servers with a failure rate exceeding a certain threshold. For example, stress testing can be performed to determine whether the abnormal server actually has a hardware failure risk. Based on the detection results, a decision is made on whether the abnormal server needs to be repaired immediately or returned to the resource pool. The aforementioned server failure rate prediction module 2250 will also adjust the failure rate of the server based on the detection results given by the server fault detection module 2270.

[0089] The aforementioned deployment relationship adjustment system 2200 can run on the computing device shown in FIG5. FIG5 is a schematic diagram of the structure of a computing device provided in an embodiment of this application. The computing device 3000 shown in FIG5 includes at least: a memory 3010, a processor 3020 and a bus 3030.

[0090] The processor 3020 is at least capable of predicting service availability based on the deployment relationships of each virtual node set in the server cluster and the failure rates of the servers corresponding to those deployment relationships, comparing this prediction with the target availability, and flexibly adjusting the deployment relationships of virtual nodes in the virtual node set on the server cluster to ensure the target availability and improve resource utilization. The memory 3010 is at least capable of storing the logic code corresponding to the deployment relationship adjustment method provided in the embodiments of this application.

[0091] Optionally, the computing device 3000 can be various types of server equipment such as rack servers and full rack servers. The computing device 3000 can also be terminal computing devices such as computers, mobile terminals, tablet computers, laptops, desktop computers, all-in-one computers, personal digital assistants (PDAs), and ultra-mobile personal computers (UMPCs).

[0092] Optionally, the memory 3010 may include random access memory (RAM), read-only memory (ROM), etc., wherein the memory 3010 may run the necessary operating system in its RAM, as well as modules such as acquisition module and allocation module for executing the deployment relationship adjustment method provided in this application.

[0093] Optionally, the processor 3020 can be a central processing unit (CPU) or other general-purpose processor, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), digital signal processor (DSP) or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0094] Optionally, bus 3030 can be a peripheral component interconnect (PCI) bus, etc., and this application does not limit the type of bus. Buses can be divided into address buses, data buses, control buses, etc. For ease of illustration, only one line is used in Figure 5, but this does not mean that there is only one bus or one type of bus. Bus 3030 may include a path for transmitting information between various components of computing device 3000 (e.g., memory 3010 and processor 3020).

[0095] The system architecture and application scenarios described in this application are intended to more clearly illustrate the technical solutions of this application and do not constitute a limitation on the technical solutions provided in this application. As those skilled in the art will know, with the evolution of system architecture and the emergence of new business scenarios, the technical solutions provided in this application are also applicable to similar technical problems.

[0096] For ease of understanding, the deployment relationship adjustment method provided in this application embodiment is described below with reference to the accompanying drawings. This deployment relationship adjustment method is applicable to the computing device shown in FIG5. The execution of a certain step (such as S110 to S120 below) by the computing device described in the following embodiments can be understood as the processor 3020 executing the step, or it can also be understood as the deployment relationship adjustment system running on the computing device 3000 executing the step.

[0097] Figure 6 is a flowchart of a deployment relationship adjustment method provided in an embodiment of this application, which specifically includes the following steps:

[0098] S110, the computing device predicts service availability based on the first deployment relationship of the virtual node set in the server cluster and the failure rate of the server corresponding to the first deployment relationship.

[0099] In the embodiments of this application, virtual nodes in the same set of virtual nodes are used together to provide services with the target availability, while virtual nodes in different sets of virtual nodes can be used to provide services with different target availability. These different sets of virtual nodes can be deployed in the same server cluster (the same large-scale resource pool) and share the resources that the server cluster can provide.

[0100] Moreover, the difference in failure rates between servers in the server cluster can be greater than the first target difference (e.g., 5%). In other words, the difference in failure rates between different servers in the server cluster can be large, without the need to divide it into multiple small-scale server clusters (resource pools).

[0101] In step S110, the computing device can specifically predict the availability of the service using various methods. For example, it can use a pre-trained neural network model, which is pre-trained using historical data of deployment relationships (sample data), historical data of the failure rate of the servers corresponding to the deployment relationships (sample data), and historical data of availability (label data). The computing device inputs the first deployment relationship into the model and obtains the availability output by the model. Alternatively, the computing device can obtain a corresponding calculation formula by statistically analyzing historical data of deployment relationships, historical data of the failure rate of the servers corresponding to the deployment relationships, and historical data of availability. By substituting the first deployment relationship and the failure rate of the servers corresponding to the first deployment relationship into this calculation formula, the predicted availability data of the service is obtained. This application does not impose any limitations on this approach.

[0102] In this embodiment of the application, the failure rate of the server may include one or more of the overall failure rate of the server and the failure rates of individual components within the server.

[0103] To further improve the accuracy of predictions, in one possible implementation, service availability is predicted based on the first deployment relationship of the virtual node set in the server cluster and the failure rate of the server corresponding to the first deployment relationship. This includes: obtaining historical data on service availability; and predicting service availability based on the first deployment relationship of the virtual node set in the server cluster and the failure rate and historical data of the server corresponding to the first deployment relationship.

[0104] Specifically, the historical data on service availability can be data on unavailability that has occurred within the current service period. By combining this historical data, computing devices can more accurately predict the availability of services within the current period, promptly detect whether there is a risk that the target availability cannot be met if the current deployment relationship (first deployment relationship) is maintained, and then make corresponding adjustment measures.

[0105] Considering that the assessment of whether the target availability is met is often periodic, for example, by combining data from one month (one service cycle) to see if the target is met. However, when the computing device executes step S110, it may be in the first few days of the current service cycle, meaning that the amount of historical data in that service cycle is relatively small, leading to a data cold start problem.

[0106] In this application embodiment, a possible implementation is provided to solve the problem and further improve the accuracy of prediction. When the computing device obtains historical data on service availability, it specifically obtains historical data within a target time span. That is, the target time span can include not only historical data within the current service period, but also historical data within previous service periods.

[0107] For example, Figure 7 is a schematic diagram of a deployment relationship involved in the embodiment shown in Figure 6. It illustrates the deployment relationship of virtual nodes in three different virtual node sets (first virtual node set - third virtual node set) within the same server cluster (large resource pool). The first virtual node set - the third virtual node set are used to provide services with target availability of 98%, 99%, and 95%, respectively. The server cluster shown in Figure 1 includes at least four servers with different failure rates (actually, more servers may be included, not shown in Figure 7): server 1 with a failure rate of 1%, server 2 with a failure rate of 2.5%, server 3 with a failure rate of 5%, and server 4 with a failure rate of 8%. Based on the deployment relationship shown in Figure 7 and the failure rates of the servers corresponding to each deployment relationship, the computing device can predict the availability of the services provided by each of the three virtual node sets, which are 97%, 99%, and 96%, respectively.

[0108] S120, if the availability does not meet the target availability, the computing device adjusts the deployment relationship of at least one virtual node in the virtual node set on the server cluster to obtain a second deployment relationship of the virtual node set on the server cluster.

[0109] The availability of services provided when the virtual node set is deployed on the server cluster according to the second deployment relationship is higher than the availability of services provided when it is deployed on the server cluster according to the first deployment relationship.

[0110] Specifically, the computing device needs to adjust at least one virtual node in the virtual node set from the first source server to the first target server to obtain a second deployment relationship of the virtual node set in the server cluster; wherein, the failure rate of the first target server is less than the failure rate of the first source server.

[0111] In this way, due to the reduced server failure rate, the probability of the adjusted virtual nodes continuously providing available services is higher, thereby reducing downtime and improving service availability without changing the service cycle.

[0112] When a computing device adjusts the first deployment relationship to obtain the second deployment relationship, it can adopt different implementation methods:

[0113] Method 1: The computing device inputs the first deployment relationship, the failure rate of each server in the server cluster, and the target availability into the target model; the target model is used to determine the deployment relationship that can meet the target availability; the second deployment relationship output by the target model is obtained; wherein, the availability of the service provided by the virtual node set when deployed on the server cluster according to the second deployment relationship meets the target availability.

[0114] This approach fully leverages the reasoning capabilities of the neural network model (target model). The first deployment relationship, the failure rate of all servers in the server cluster, and the target availability are input into the target model. This model then determines a second deployment relationship that satisfies the target availability from the perspective of the entire server cluster. Compared to method 2, this method obtains the second deployment relationship that satisfies the target availability more efficiently, without repeatedly adjusting the deployment relationship and performing multiple prediction calculations.

[0115] Furthermore, if the target model outputs multiple candidate deployment relationships that can meet the target availability, the computing device can also sort the candidate deployment relationships based on other dimensions such as the confidence level of each candidate deployment relationship in meeting the target availability, the adjustment cost required to make adjustments, and the load of each server in the server cluster, and comprehensively determine the optimal candidate deployment relationship as the second deployment relationship.

[0116] For example, based on Figure 7, since the virtual nodes in the first virtual node set in Figure 7 are used together to provide a service with a target availability of 98%, but in step S110, the computing device predicts that the service availability is 97%, which cannot meet the target availability. Therefore, the computing device inputs the deployment relationship corresponding to the first virtual node set in Figure 7, the failure rate of each server in the server cluster (only 4 servers are shown in the figure, but there can be more), and the target availability into the target model to obtain two candidate deployment relationships output by the target model. Specifically, it adjusts the node currently deployed on server 4 in the first virtual node set to server 2 (with a confidence level of 80% to meet the target availability), or adjusts the node currently deployed on server 4 in the first virtual node set to server 1 (with a confidence level of 99% to meet the target availability).

[0117] Then, the computing device, based on the fact that the service cycle progress currently provided by the first virtual node set has reached 90% of the service cycle and there is little time remaining, adjusts the nodes currently deployed on server 4 in the first virtual node set to server 1 as the optimal second deployment relationship.

[0118] Method 2: The computing device adjusts the deployment relationship of at least one virtual node in the virtual node set on the server cluster to obtain the adjusted deployment relationship; based on the adjusted deployment relationship and the failure rate of the server corresponding to the adjusted deployment relationship, the availability of the service is predicted again; the availability predicted again is higher than the availability predicted in the previous prediction, and the computing device continues to repeat the above steps until the availability predicted in the i-th prediction meets the target availability, and the deployment relationship corresponding to the availability predicted in the i-th prediction is determined as the second deployment relationship, where i is an integer greater than 1.

[0119] In this approach, the computing device continuously predicts the availability of the service corresponding to each adjusted deployment relationship until the predicted availability meets the target availability. At this point, the adjustment of the deployment relationship stops, and the deployment relationship obtained from the last adjustment is used as the second deployment relationship. Compared to method 1, this method does not require pre-training of the target model, resulting in lower deployment costs and higher deployment efficiency.

[0120] For example, based on Figure 7, since the virtual nodes in the first virtual node set in Figure 7 are used to provide a service with a target availability of 98%, but in step S110, the computing device predicts that the service availability is 97%, which cannot meet the target availability. Therefore, the computing device first adjusts the deployment relationship of the virtual node in the first virtual node set that is deployed on the server with the highest failure rate (server 4 in Figure 7), moving it from server 4 to server 3. Then, based on the adjusted deployment relationship, it makes another prediction, obtaining a service availability of 97.5%, which still cannot meet the target availability. Then, it moves the node to server 2, and then makes another prediction based on the adjusted deployment relationship, obtaining a service availability of 98.5%, which meets the target availability. This results in a second deployment relationship, that is, moving the node originally deployed on server 4 in the first virtual node set shown in Figure 7 to server 2.

[0121] Considering that different servers vary with time, environment, load, batch, and other factors, their failure rates will also change, and there is a certain degree of unpredictability (such as unexpected factors such as unstable voltage in the server room accelerating hardware aging). Therefore, although the second deployment relationship obtained through the aforementioned methods 1 and 2 can guarantee that the target availability can be met with a high degree of confidence at the current moment (and for a period of time thereafter), its confidence is difficult to maintain at 100% throughout the entire service cycle. In this embodiment of the application, in order to achieve the target availability within the service cycle, the computing device can periodically execute step S110 (for example, once a day; the specific cycle can be set according to the service cycle and other factors, and this application does not impose any restrictions), thereby timely checking whether the deployment relationship of each virtual node set can meet the corresponding target availability and making timely adjustments.

[0122] To further improve service availability, in addition to adjusting the deployment relationship of virtual nodes in the virtual node set on the server cluster, the computing device can also adjust the deployment strategy of newly created virtual nodes. In one possible implementation, in response to receiving a first expansion request, the computing device adds the first virtual node deployed on the first server in the server cluster to the virtual node set, resulting in an expanded virtual node set. The first expansion request is used to request the addition of virtual nodes to the virtual node set. The failure rate of the first server is lower than the maximum failure rate of the servers corresponding to the first deployment relationship.

[0123] Referring to Figure 7 above, and taking the first virtual node set shown in Figure 7 as an example, the deployment relationship of the nodes in the first virtual node set on the server cluster can be called the first deployment relationship. Correspondingly, servers 1-4, where the nodes in the first virtual node set are actually deployed, can be called the servers corresponding to the first deployment relationship. The first server is the server in the server cluster whose failure rate is lower than the maximum failure rate among the servers corresponding to the first deployment relationship (servers 1-4) (the server with the highest failure rate is server 4, shown in Figure 7, with a failure rate of 8%). In other words, the first server includes at least any one of the servers 1-3 shown in Figure 7. Therefore, in response to an expansion request for the first virtual node set, the computing device can add virtual nodes deployed on servers 1-3 to the first virtual node set.

[0124] If there are idle virtual nodes on servers 1-3, the computing device can directly add them to the first set of virtual nodes. If not, the computing device can first create virtual nodes on the target servers (which may be the ones with the lowest load or randomly selected, and this application does not impose any restrictions) among servers 1-3, and then add the newly created virtual nodes to the first set of virtual nodes.

[0125] Through the above expansion method, the average failure rate of the servers deployed on the virtual nodes in the expanded virtual node set is lower than that before the expansion, thereby improving the availability of the service.

[0126] Considering the different types of user businesses, they may have some special requirements for servers. For example, if a user's business involves a large amount of data computation, requiring memory with a very low failure rate for support, then the difference between the failure rate of the target component (such as the aforementioned memory) in the server corresponding to the second deployment relationship obtained by the computing device and the failure rate index of the target component required by the service needs to be less than the third target difference. In other words, when executing step S120, the computing device needs to consider whether the server corresponding to the second deployment relationship can meet the failure rate index of the target component, thereby providing more reliable support for the user's business.

[0127] S130, the computing device deploys the virtual node set on the server cluster according to the second deployment relationship.

[0128] In this step, the computing device deploys the virtual node set on the server cluster according to the second deployment relationship obtained in step S120. In specific deployment, various implementation methods can be adopted, such as the hot migration technology of virtual nodes. Furthermore, the timing of adjustment can be determined by combining the user's business volume (which can be measured according to the virtual node load). This application does not impose any restrictions on this.

[0129] For example, based on Figure 7, since the virtual nodes in the first virtual node set in Figure 7 are used to provide a service with a target availability of 98%, but in step S110, the computing device predicts that the service availability is 97%, which cannot meet the target availability. Therefore, the second deployment relationship determined by the computing device in step S120 is as follows: the nodes originally deployed on server 4 in the first virtual node set shown in Figure 7 are adjusted to server 2. According to this second deployment relationship (which only involves the adjustment of nodes on server 4 compared to the current deployment relationship of the first virtual node set), the computing device performs hot migration of the nodes on server 4 to server 2 when the user traffic is lower than a set threshold.

[0130] Referring to Figure 8, which is a comparative diagram of the deployment relationship adjustment before and after the embodiment shown in Figure 7, the nodes originally deployed on server 4 (failure rate 8%) in the first virtual node set have been adjusted to server 2 (failure rate 2.5%). The rest remain unchanged and will not be described in detail here. Since the average failure rate of the servers deployed in the first virtual node set after the adjustment is lower than before the adjustment, the availability of the service is improved, and the target availability can be met.

[0131] Through steps S110-S130 and various possible implementations, services with different target availability are provided on the same large-scale server cluster (allowing for significant differences in failure rates among servers in the cluster). Furthermore, the availability of each service is predicted, and if the predicted availability of a service fails to meet the target availability, the deployment relationship of some virtual nodes in the set of virtual nodes used to provide that service is adjusted in a timely manner on the server cluster to improve the predicted availability of that service and achieve the goal of meeting the target availability. Compared to traditional technologies, the server cluster involved in this embodiment is larger in scale, thus providing sufficient flexibility, reducing the impact of business fluctuations on the cluster, and allowing servers with higher failure rates to be fully utilized, improving resource utilization.

[0132] The above describes how, when availability cannot meet the target availability, service availability is improved by adjusting deployment relationships to achieve the desired availability. However, when availability meets the target availability, to further improve resource utilization, this application also provides a possible implementation method, specifically including: when the difference between availability and target availability exceeds a second target difference, adjusting at least one virtual node in the virtual node cluster from the second source server to the second target server, resulting in a third deployment relationship of the virtual node set in the server cluster; wherein the failure rate of the second target server is greater than the failure rate of the second source server.

[0133] In other words, if the predicted availability is 99% and the target availability is 95%, and the difference exceeds 3% (the second target difference), the computing device, for the purpose of load balancing and improving resource utilization, will move at least one virtual node in the virtual node cluster from the second source server to the second target server (with a higher failure rate than the second source server). Although this reduces the availability of the service to some extent, it should be noted that the computing device can ensure that the target availability is met and achieve the overall resource utilization effect of the resource pool by executing the aforementioned steps S110-S130 and various implementation methods.

[0134] For example, a computing device detects that the load rate of a server in a server cluster has reached 100%, requiring appropriate offloading. In this case, the computing device can decide which virtual node deployment relationship to adjust on the server cluster based on the difference between the availability of the services provided by the set of virtual nodes to which each virtual node deployed on that server belongs and the corresponding target availability.

[0135] When determining the third deployment relationship, the computing device can refer to the implementation method used to determine the second deployment relationship, such as using models, which will not be elaborated here. However, the availability predicted by the computing device based on the third deployment relationship and the failure rate of the server corresponding to the third deployment relationship needs to meet the target availability.

[0136] Accordingly, if the availability meets the target availability, in response to receiving the second expansion request, the computing device adds the first virtual node deployed on the second server in the server cluster to the virtual node set, thus obtaining the expanded virtual node set; wherein, the second expansion request is used to request the addition of virtual nodes to the virtual node set; the failure rate of the second server is higher than the minimum failure rate of the servers corresponding to the first deployment relationship.

[0137] In other words, if the availability meets the target availability, the computing device can add the first virtual node deployed on the second server with a higher failure rate to the virtual node set. When selecting the second server in the server cluster, the computing device can select a server with a lower load rate and a failure rate that meets the requirements (higher than the minimum failure rate of the server corresponding to the first deployment relationship), thereby improving resource utilization.

[0138] While the deployment relationship adjustment method provided in this application can provide users with services of different SLA levels (target availability) on a large-scale server cluster (large resource pool) with significantly different failure rates, in order to avoid the problem of severely faulty servers continuously affecting user services and causing frequent adjustments to deployment relationships, this application also provides a possible implementation method, including: determining abnormal servers from the servers corresponding to the virtual node set; wherein, the abnormal server is a server with a failure rate higher than the failure rate threshold; adjusting the virtual nodes on the abnormal server to other servers in the server cluster; wherein, the failure rate of the other servers is lower than the failure rate threshold.

[0139] By setting a failure rate threshold, abnormal servers can be detected in a timely manner. Furthermore, the computing device can perform stress testing on abnormal servers to further determine their status. If a server fails the stress test, the computing device can generate an alarm message to remind maintenance personnel to repair the server in a timely manner.

[0140] In the embodiments of this application, the failure rate of the server and the failure rate of each component in the server can be predicted by means of expert experience, machine learning, etc. For example, server hardware status related information (including but not limited to temperature information, batch information, historical maintenance information, environmental information, equipment operation status, alarm information, service time information, error logs, etc. of each component) can be input into a pre-trained fault prediction model to obtain the server failure rate and confidence level. This application does not impose any restrictions on this.

[0141] Based on the deployment relationship adjustment method provided in this application, cloud service providers can not only offer differentiated SLA services to users within the same server cluster (including servers with significantly different failure rates), but also allow users to customize indicators in the SLA (such as target availability, component failure rate, etc.), thereby enabling computing devices to adjust deployment relationships according to user-defined targets. Furthermore, this application does not restrict the timing at which users initiate adjustments to SLA indicators; even during the current service cycle (e.g., one month) (e.g., the first three days), computing devices can make timely and accurate adjustments to deployment relationships to ensure target availability is met.

[0142] Based on the software architecture shown in Figure 4 and in conjunction with Figure 9, the deployment relationship adjustment method provided in this application will be described again below.

[0143] Figure 9 is a schematic diagram of a module interaction provided in an embodiment of this application, which specifically includes the following steps:

[0144] S210, the service configuration and management module 2230 submits service requirements to the service satisfaction assessment module 2210.

[0145] The service requirements may specifically include: the target availability of the services provided by the three different sets of virtual nodes shown in Figure 9, which are 99.9%, 98.5%, and 98.0%, respectively, and the deployment relationship of each virtual node in the set of virtual nodes on each server in the server cluster (not shown in Figure 9).

[0146] S220, the service status monitoring module 2240 provides the service satisfaction assessment module 2210 with service status information, including but not limited to the interruption duration, number of failures, availability, and failure rate of each service in the historical service cycle and the current service cycle.

[0147] S230, the server failure rate prediction module 2250 provides the service satisfaction assessment module 2210 with the failure rate of each server in the server cluster.

[0148] Furthermore, step S230 may also include:

[0149] S231, the server status acquisition module 2260 collects status-related information of each server in the server cluster, including but not limited to: temperature information, batch information, historical maintenance information, environmental information, operating status information, alarm information, service time information, error logs, etc.

[0150] S232, the server status acquisition module 2260 provides server information to the server failure rate prediction module 2250.

[0151] In this step, the server status acquisition module 2260 provides the information acquired in step S231 to the server failure rate prediction module 2250. Based on the acquired information, the server failure rate prediction module 2250 predicts the failure rate of each server and provides it to the service satisfaction assessment module 2210.

[0152] S240, Service Satisfaction Assessment Module 2210 triggers Adjustment Module 2220.

[0153] In this step, the service satisfaction assessment module 2210 can predict the availability of each service based on the data sent by each module in steps S210-S230. If it detects that the availability of a certain service cannot meet the corresponding availability target, it triggers the adjustment module 2220. Upon triggering, the service satisfaction assessment module 2210 can also send the calculated target deployment relationship to the adjustment module 2220 to complete the adjustment, or it can simply send a trigger signal (along with some necessary information, such as the current deployment relationship and target availability) to the adjustment module 2220, allowing the adjustment module 2220 to make its own decision on how to adjust the deployment relationship.

[0154] S250, adjust module 2220 to adjust deployment relationship.

[0155] In this step, the adjustment module 2220 can migrate the relevant virtual node source server to the target server according to the target deployment relationship sent by the service satisfaction assessment module 2210 through the migration module 2222. In the specific migration, the migration can be initiated during the low load period of the source server to reduce the impact on the business, or hot migration technology can be used (the business is almost uninterrupted during the migration process) to achieve a virtual node migration process that is imperceptible to users.

[0156] In addition, the adjustment module 2220 can also adjust the future expansion strategy of the virtual node set that cannot meet the target availability through the resource scheduling module 2221. The adjusted expansion strategy can be: deploy all virtual nodes that need to be expanded in the future to servers with lower failure rates (specifically, lower than the maximum failure rate of each server currently corresponding to the virtual node set).

[0157] S260, the server failure rate prediction module 2250 provides the server failure detection module 2270 with the identification of the abnormal server.

[0158] In this step, if the failure rate of each server predicted by the server failure rate prediction module 2250 exceeds the set failure rate threshold, it is regarded as an abnormal server, and the identifier of the server is sent to the server failure detection module 2270 for further detection.

[0159] S270, the server fault detection module 2270, detects abnormal servers.

[0160] In this step, the server fault detection module 2270 performs stress testing on the corresponding server based on the identifier of the abnormal server sent by the server failure rate prediction module 2250. If the server fails the stress test, an alarm message is generated to remind the operation and maintenance personnel to modify the server in time. If the server passes the stress test, the server fault detection module 2270 can also send the test result as negative feedback information to the server failure rate prediction module 2250 in order to improve the future prediction accuracy of the server failure rate prediction module 2250.

[0161] Optionally, the server fault detection module 2270 can also send the identifier of the server that failed the stress test to the adjustment module 2220 so that the virtual nodes currently deployed on the server can be adjusted to other servers in a timely manner.

[0162] Through steps S210-S270, different modules perform their respective functions and work together to predict the availability of each service. They also adjust the deployment relationship of virtual nodes that cannot meet the target availability on the server cluster in a timely manner, thereby improving differentiated services for users on a unified large-scale server cluster.

[0163] It is worth noting that steps S210-S270 described above are merely an exemplary execution order, and in practice, the order of different steps is not limited. Moreover, different steps are not necessarily executed sequentially; in particular, steps S210, S220, and S230 can be executed in parallel by their respective modules, and this application does not impose any restrictions.

[0164] It is also worth noting that the above-mentioned interaction process is mainly for the case where the predicted service availability does not meet the target availability. However, when the predicted service availability meets the target availability and there is a large difference between the two, the above modules can also cooperate to adjust the deployment relationship, thereby improving the utilization of resources while ensuring that the target availability is met. Since the process is similar, it will not be elaborated here.

[0165] The foregoing mainly describes the solutions of the embodiments of this application from the perspective of methods and module interactions. It is understood that, in order to achieve the above functions, the deployment relationship adjustment device includes at least one of the hardware structures and software modules corresponding to each function. Those skilled in the art should readily recognize that, in conjunction with the units and algorithm steps of the various examples described in the embodiments disclosed herein, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this application.

[0166] This application embodiment can divide the deployment relationship adjustment device into functional units according to the above method example. For example, each function can be divided into different functional units, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional unit. The unit division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0167] For example, Figure 10 is a schematic diagram of a deployment relationship adjustment device provided in an embodiment of this application. The deployment relationship adjustment device 800 is applied in a computing device (control node of a server cluster), or the deployment relationship adjustment device 800 can be a computing device, where a set of virtual nodes is deployed on the aforementioned server cluster. The virtual nodes in the set of virtual nodes collectively provide a service with a target availability, and the difference in failure rates between the servers in the server cluster is greater than a first target difference. The deployment relationship adjustment device 800 includes:

[0168] The prediction module 810 is used to predict the availability of the service based on the first deployment relationship of the virtual node set in the server cluster and the failure rate of the server corresponding to the first deployment relationship.

[0169] The first adjustment module 820 is used to adjust the deployment relationship of at least one virtual node in the virtual node set on the server cluster when the availability does not meet the target availability, to obtain a second deployment relationship of the virtual node set on the server cluster; wherein the availability of the service provided by the virtual node set when deployed on the server cluster according to the second deployment relationship is higher than the availability of the service provided when deployed on the server cluster according to the first deployment relationship.

[0170] Deployment module 830 is used to deploy the virtual node set on the server cluster according to the second deployment relationship.

[0171] In one possible implementation, the first adjustment module 820 is further configured to adjust at least one virtual node in the virtual node set from the first source server to the first target server, thereby obtaining a second deployment relationship of the virtual node set in the server cluster; wherein the failure rate of the first target server is less than the failure rate of the first source server.

[0172] In one possible implementation, the apparatus further includes a first expansion module, which is configured to, in response to receiving a first expansion request, add a first virtual node deployed on a first server in the server cluster to the virtual node set, thereby obtaining an expanded virtual node set; wherein, the first expansion request is used to request the addition of virtual nodes to the virtual node set; and the failure rate of the first server is lower than the maximum value of the failure rates of the servers corresponding to the first deployment relationship.

[0173] In one possible implementation, the first adjustment module 820 is further configured to input the first deployment relationship, the failure rate of each server in the server cluster, and the target availability into the target model; the target model is configured to determine the deployment relationship that can satisfy the target availability; and obtain the second deployment relationship output by the target model; wherein the availability of the service provided by the virtual node set when deployed on the server cluster according to the second deployment relationship satisfies the target availability.

[0174] In one possible implementation, the first adjustment module 820 is further configured to adjust the deployment relationship of at least one virtual node in the virtual node set on the server cluster to obtain an adjusted deployment relationship; based on the adjusted deployment relationship and the failure rate of the server corresponding to the adjusted deployment relationship, the availability of the service is predicted again; the availability obtained by the second prediction is higher than the availability obtained by the previous prediction; the above steps are repeated until the availability obtained by the i-th prediction meets the target availability, and the deployment relationship corresponding to the availability obtained by the i-th prediction is determined as the second deployment relationship, where i is an integer greater than 1.

[0175] In one possible implementation, if the availability satisfies the target availability, the apparatus further includes a second adjustment module, which is used to adjust at least one virtual node in the virtual node cluster from a second source server to a second target server if the difference between the availability and the target availability exceeds a second target difference, thereby obtaining a third deployment relationship of the virtual node set in the server cluster; wherein the failure rate of the second target server is greater than the failure rate of the second source server.

[0176] In one possible implementation, the apparatus further includes a second expansion module, which is configured to, in response to receiving a second expansion request, add a first virtual node deployed on a second server in the server cluster to the virtual node set, thereby obtaining an expanded virtual node set; wherein the second expansion request is used to request the addition of virtual nodes to the virtual node set; and the failure rate of the second server is higher than the minimum failure rate among the servers corresponding to the first deployment relationship.

[0177] In one possible implementation, the prediction module 810 is further configured to acquire historical data on the availability of the service; and predict the availability of the service based on the first deployment relationship of the virtual node set in the server cluster, the failure rate of the server corresponding to the first deployment relationship, and the historical data.

[0178] In one possible implementation, the difference between the failure rate of the target component in the server corresponding to the second deployment relationship and the failure rate index of the target component required by the service is less than the third target difference.

[0179] In one possible implementation, the apparatus further includes a third adjustment module, which is used to determine abnormal servers from the servers corresponding to the set of virtual nodes; wherein the abnormal server is a server with a failure rate higher than a failure rate threshold; and adjust the virtual nodes on the abnormal server to other servers in the server cluster; wherein the failure rate of the other servers is lower than the failure rate threshold.

[0180] For example, referring to Figure 6, the prediction module 810 can be used to execute S110 as shown in Figure 6, the first adjustment module 820 can be used to execute S120 as shown in Figure 6, and the deployment module 830 can be used to execute S130 as shown in Figure 6.

[0181] As a feasible example, the deployment relationship adjustment device 800 provided in this application is implemented through a software module. For example, the software module can be provided to users through a cloud service subscription model, and users can choose different subscription levels according to their needs. Alternatively, the software module can also provide enterprise-level customized services with professional domain customization, interface personalization and extended functions according to the needs of users or enterprises.

[0182] Furthermore, the deployment relationship adjustment device 800 provided in this application can also be provided to users as a value-added service, and this application does not limit this. When the deployment relationship adjustment device 800 is implemented through a software module, the deployment relationship adjustment device 800 can also be embedded into resource deployment software or cloud service scheduling system.

[0183] This application also provides a computing device 100. As shown in FIG11, the computing device 100 includes: a bus 102, a processor 104, a memory 106, and a communication interface 108. The processor 104, the memory 106, and the communication interface 108 communicate with each other via the bus 102. The computing device 100 may be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in the computing device 100.

[0184] Bus 102 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, only one line is used in Figure 11, but this does not imply that there is only one bus or one type of bus. Bus 102 can include pathways for transmitting information between various components of computing device 100 (e.g., memory 106, processor 104, communication interface 108).

[0185] The processor 104 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0186] Memory 106 may include volatile memory, such as random access memory (RAM). Processor 104 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0187] The memory 106 stores executable program code, which the processor 104 executes to implement the functions of the aforementioned prediction module, first adjustment module, and deployment module, thereby realizing the deployment relationship adjustment method. That is, the memory 106 stores instructions for executing the deployment relationship adjustment method.

[0188] This application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0189] As shown in Figure 12, the computing device cluster includes at least one computing device 100. The memory 106 of one or more computing devices 100 in the computing device cluster may store the same instructions for executing deployment relationship adjustment methods.

[0190] In some possible implementations, the memory 106 of one or more computing devices 100 in the computing device cluster may also store partial instructions for executing the deployment relationship adjustment method. In other words, a combination of one or more computing devices 100 can jointly execute the instructions for executing the deployment relationship adjustment method.

[0191] The memories 106 in different computing devices 100 within the computing device cluster can store different instructions, each used to execute a portion of the functions of the deployment relationship adjustment device. That is, the instructions stored in the memories 106 of different computing devices 100 can implement the functions of one or more modules among the prediction module, the first adjustment module, and the deployment module.

[0192] In some possible implementations, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc. Figure 13 illustrates one possible implementation. As shown in Figure 13, two computing devices 100A and 100B are connected via a network. Specifically, they are connected to the network through communication interfaces in each computing device. In this type of possible implementation, the memory 106 in computing device 100A stores instructions for executing the functions of the prediction module. Simultaneously, the memory 106 in computing device 100B stores instructions for executing the functions of the first adjustment module and the deployment module.

[0193] It should be understood that the functions of computing device 100A shown in Figure 13 can also be performed by multiple computing devices 100. Similarly, the functions of computing device 100B can also be performed by multiple computing devices 100.

[0194] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions, capable of running on a computing device or stored on any usable medium. When the computer program product is run on at least one computing device, it causes the at least one computing device to perform a deployment relationship adjustment method.

[0195] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to perform a deployment relationship adjustment method, or instruct the computing device to perform a deployment relationship adjustment method.

[0196] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of this application.

Claims

1. A method for adjusting deployment relationships, characterized in that, A control node applied to a server cluster, wherein a set of virtual nodes is deployed on the server cluster, and the virtual nodes in the set of virtual nodes collectively provide a service with a target availability, wherein the difference in failure rates between the servers in the server cluster is greater than a first target difference, the method comprising: Based on the first deployment relationship of the virtual node set in the server cluster, and the failure rate of the server corresponding to the first deployment relationship, the availability of the service is predicted; If the availability does not meet the target availability, the deployment relationship of at least one virtual node in the virtual node set on the server cluster is adjusted to obtain a second deployment relationship of the virtual node set on the server cluster; wherein, the availability of the service provided by the virtual node set when deployed on the server cluster according to the second deployment relationship is higher than the availability of the service provided when deployed on the server cluster according to the first deployment relationship. According to the second deployment relationship, the virtual node set is deployed on the server cluster.

2. The method according to claim 1, characterized in that, Adjusting the deployment relationship of at least one virtual node in the virtual node set on the server cluster to obtain a second deployment relationship of the virtual node set on the server cluster includes: At least one virtual node in the virtual node set is moved from the first source server to the first target server to obtain a second deployment relationship of the virtual node set in the server cluster; wherein the failure rate of the first target server is less than the failure rate of the first source server.

3. The method according to claim 1 or 2, characterized in that, The method further includes: In response to receiving a first expansion request, a first virtual node deployed on a first server in the server cluster is added to the virtual node set to obtain an expanded virtual node set; wherein, the first expansion request is used to request the addition of virtual nodes to the virtual node set; the failure rate of the first server is lower than the maximum failure rate of the servers corresponding to the first deployment relationship.

4. The method according to any one of claims 1-3, characterized in that, Adjusting the deployment relationship of at least one virtual node in the virtual node set on the server cluster to obtain a second deployment relationship of the virtual node set on the server cluster includes: The first deployment relationship, the failure rate of each server in the server cluster, and the target availability are input into the target model; the target model is used to determine the deployment relationship that can satisfy the target availability. Obtain the second deployment relationship output by the target model; wherein, the availability of the service provided by the virtual node set when deployed on the server cluster according to the second deployment relationship satisfies the target availability.

5. The method according to any one of claims 1-3, characterized in that, Adjusting the deployment relationship of at least one virtual node in the virtual node set on the server cluster to obtain a second deployment relationship of the virtual node set on the server cluster includes: Adjust the deployment relationship of at least one virtual node in the virtual node set on the server cluster to obtain the adjusted deployment relationship; Based on the adjusted deployment relationship and the failure rate of the server corresponding to the adjusted deployment relationship, the availability of the service is predicted again; the availability predicted again is higher than the availability predicted in the previous prediction. Repeat the above steps until the availability obtained from the i-th prediction meets the target availability. Then, determine the deployment relationship corresponding to the availability obtained from the i-th prediction as the second deployment relationship, where i is an integer greater than 1.

6. The method according to any one of claims 1-5, characterized in that, If the availability satisfies the target availability, the method further includes: If the difference between the availability and the target availability exceeds the second target difference, at least one virtual node in the virtual node cluster is moved from the second source server to the second target server to obtain a third deployment relationship of the virtual node set in the server cluster; wherein the failure rate of the second target server is greater than the failure rate of the second source server.

7. The method according to claim 6, characterized in that, The method further includes: In response to receiving a second expansion request, the first virtual node deployed on the second server in the server cluster is added to the virtual node set to obtain an expanded virtual node set; wherein, the second expansion request is used to request the addition of virtual nodes to the virtual node set; the failure rate of the second server is higher than the minimum failure rate of the servers corresponding to the first deployment relationship.

8. The method according to any one of claims 1-7, characterized in that, The prediction of service availability based on the first deployment relationship of the virtual node set in the server cluster and the failure rate of the servers corresponding to the first deployment relationship includes: Obtain historical data on the availability of the service; Based on the first deployment relationship of the virtual node set in the server cluster, the failure rate of the server corresponding to the first deployment relationship, and the historical data, the availability of the service is predicted.

9. The method according to any one of claims 1-8, characterized in that, The difference between the failure rate of the target component in the server corresponding to the second deployment relationship and the failure rate index of the target component required by the service is less than the third target difference.

10. The method according to any one of claims 1 to 9, characterized in that, The method further includes: From the servers corresponding to the set of virtual nodes, identify abnormal servers; wherein, the abnormal servers are servers with a failure rate higher than the failure rate threshold. The virtual nodes on the abnormal server are moved to other servers in the server cluster; wherein the failure rate of the other servers is lower than the failure rate threshold.

11. A deployment relationship adjustment device, characterized in that, The device includes: The prediction module is used to predict the availability of the service based on the first deployment relationship of the virtual node set in the server cluster and the failure rate of the server corresponding to the first deployment relationship. A first adjustment module is configured to adjust the deployment relationship of at least one virtual node in the virtual node set on the server cluster when the availability does not meet the target availability, to obtain a second deployment relationship of the virtual node set on the server cluster; wherein the availability of the service provided by the virtual node set when deployed on the server cluster according to the second deployment relationship is higher than the availability of the service provided when deployed on the server cluster according to the first deployment relationship. The deployment module is used to deploy the set of virtual nodes on the server cluster according to the second deployment relationship.

12. The apparatus according to claim 11, characterized in that, The first adjustment module is also used for, At least one virtual node in the virtual node set is moved from the first source server to the first target server to obtain a second deployment relationship of the virtual node set in the server cluster; wherein the failure rate of the first target server is less than the failure rate of the first source server.

13. The apparatus according to claim 11 or 12, characterized in that, The device further includes a first expansion module, which is used for: In response to receiving a first expansion request, a first virtual node deployed on a first server in the server cluster is added to the virtual node set to obtain an expanded virtual node set; wherein, the first expansion request is used to request the addition of virtual nodes to the virtual node set; the failure rate of the first server is lower than the maximum failure rate of the servers corresponding to the first deployment relationship.

14. The apparatus according to any one of claims 11-13, characterized in that, The first adjustment module is also used for, The first deployment relationship, the failure rate of each server in the server cluster, and the target availability are input into the target model; the target model is used to determine the deployment relationship that can satisfy the target availability. Obtain the second deployment relationship output by the target model; wherein, the availability of the service provided by the virtual node set when deployed on the server cluster according to the second deployment relationship satisfies the target availability.

15. The apparatus according to any one of claims 11-13, characterized in that, The first adjustment module is also used for, Adjust the deployment relationship of at least one virtual node in the virtual node set on the server cluster to obtain the adjusted deployment relationship; Based on the adjusted deployment relationship and the failure rate of the server corresponding to the adjusted deployment relationship, the availability of the service is predicted again; the availability predicted again is higher than the availability predicted in the previous prediction. Repeat the above steps until the availability obtained from the i-th prediction meets the target availability. Then, determine the deployment relationship corresponding to the availability obtained from the i-th prediction as the second deployment relationship, where i is an integer greater than 1.

16. The apparatus according to any one of claims 11-15, characterized in that, If the availability meets the target availability, the apparatus further includes a second adjustment module, the second adjustment module being used to: If the difference between the availability and the target availability exceeds the second target difference, at least one virtual node in the virtual node cluster is moved from the second source server to the second target server to obtain a third deployment relationship of the virtual node set in the server cluster; wherein the failure rate of the second target server is greater than the failure rate of the second source server.

17. The apparatus according to claim 16, characterized in that, The device further includes a second expansion module, which is used for: In response to receiving a second expansion request, the first virtual node deployed on the second server in the server cluster is added to the virtual node set to obtain an expanded virtual node set; wherein, the second expansion request is used to request the addition of virtual nodes to the virtual node set; the failure rate of the second server is higher than the minimum failure rate of the servers corresponding to the first deployment relationship.

18. The apparatus according to any one of claims 11-17, characterized in that, The prediction module is also used for, Obtain historical data on the availability of the service; Based on the first deployment relationship of the virtual node set in the server cluster, the failure rate of the server corresponding to the first deployment relationship, and the historical data, the availability of the service is predicted.

19. The apparatus according to any one of claims 11-18, characterized in that, The difference between the failure rate of the target component in the server corresponding to the second deployment relationship and the failure rate index of the target component required by the service is less than the third target difference.

20. The apparatus according to any one of claims 11 to 19, characterized in that, The device further includes a third adjustment module, the third adjustment module being used for, From the servers corresponding to the set of virtual nodes, identify abnormal servers; wherein, the abnormal servers are servers with a failure rate higher than the failure rate threshold. The virtual nodes on the abnormal server are moved to other servers in the server cluster; wherein the failure rate of the other servers is lower than the failure rate threshold.

21. A computing device cluster, characterized in that, It includes at least one computing device, each computing device including a processor and memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the computing device cluster to perform the deployment relationship adjustment method as described in any one of claims 1-10.

22. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes computer instructions; when the computer instructions are executed in a computing device, the computing device performs the deployment relationship adjustment method according to any one of claims 1-10.

23. A computer program product, characterized in that, When the computer program product is run on a computing device, the computing device performs the deployment relationship adjustment method according to any one of claims 1-10.

Images