System upgrading method and device, electronic equipment, storage medium and program product

Abstract

The invention discloses a system upgrading method and device, electronic equipment, a storage medium and a program product. The method comprises the steps that under the condition that a system upgrading instruction is detected, upgrading stability of multiple servers in a server cluster is predicted, and stability prediction results corresponding to the multiple servers are obtained; determining a system upgrading sequence of the plurality of servers based on the stability prediction results corresponding to the plurality of servers; and based on a preset probing strategy, according to the system upgrading sequence, carrying out system upgrading on the plurality of servers in sequence. According to the method and the device, the technical problem of relatively low operation stability of the server cluster during system upgrading in related technologies is solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of server operation and maintenance, in particular to a system upgrading method and device, electronic equipment, storage medium and program product. BACKGROUND

[0002] In modern Internet applications, high-availability clusters have become a key architecture to ensure system stable operation and provide uninterrupted service. These clusters are usually composed of multiple servers, which distribute requests through load balancing technology to ensure that even if a single node fails, the system as a whole can continue to provide services. However, in the current cluster management strategy, when the servers in the cluster need to be upgraded, it will cause the running stability of the server cluster to be low, thereby causing the running efficiency of the server cluster to be low, and further causing the user experience to be poor.

[0003] For the above problems, no effective solutions have been proposed so far. SUMMARY

[0004] Embodiments of the present application provide a system upgrading method and device, electronic equipment, storage medium and program product to at least solve the technical problem of low running stability of a server cluster when performing system upgrading in related technologies.

[0005] According to an aspect of embodiments of the present application, a system upgrading method is provided, which is applied to a server cluster, and includes: in the case of detecting a system upgrading instruction, predicting the upgrading stability of multiple servers in the server cluster to obtain stability prediction results corresponding to the multiple servers, wherein the stability prediction result is used to represent the influence degree of the multiple servers on the running stability of the server cluster in the upgrading operation process; determining the system upgrading order of the multiple servers based on the stability prediction results corresponding to the multiple servers; and performing system upgrading on the multiple servers in turn based on a preset live detection strategy according to the system upgrading order, wherein the preset live detection strategy is used to adjust the detection results corresponding to the multiple servers, and the detection result is used to represent whether the multiple servers are in an online state.

[0006] Further, based on the preset probe alive strategy, the system upgrade is sequentially performed on the plurality of servers according to a system upgrade sequence, including: based on the system upgrade sequence, determining a target server from the plurality of servers, wherein the target server is a server in the plurality of servers that has not performed an upgrade operation and has a stability prediction result smaller than that of other servers, and the other servers are servers in the plurality of servers that have not performed an upgrade operation except for the target server; based on the preset probe alive strategy, performing system upgrade on the target server; repeating the steps of determining the target server from the plurality of servers based on the system upgrade sequence and performing system upgrade on the target server based on the preset probe alive strategy until the system upgrade of the plurality of servers is completed.

[0007] Further, based on the preset probe alive strategy, the system upgrade is sequentially performed on the plurality of servers according to a system upgrade sequence, including: based on the system upgrade sequence, determining a target server from the plurality of servers, wherein the target server is a server in the plurality of servers that has not performed an upgrade operation and has a stability prediction result smaller than that of other servers, and the other servers are servers in the plurality of servers that have not performed an upgrade operation except for the target server; based on the preset probe alive strategy, performing system upgrade on the target server; repeating the steps of determining the target server from the plurality of servers based on the system upgrade sequence and performing system upgrade on the target server based on the preset probe alive strategy until the system upgrade of the plurality of servers is completed.

[0008] Further, the preset probe alive strategy includes a preset probe alive threshold and a preset probe alive frequency, the preset probe alive threshold is used to represent the response time of any one server in the process of probing alive, and the preset probe alive frequency is used to represent the default value of the frequency of probing alive operation; adjusting the detection result corresponding to the target server to the offline state of the target server, including: modifying the running configuration of the server cluster to control the target server to be offline, wherein the running configuration is used to control any one server to be online or offline; determining the detection result of the target server based on the preset probe alive threshold and the preset probe alive frequency; in the case that the detection result is that the target server is in an offline state, it is determined that the detection result corresponding to the target server is successfully adjusted to the offline state of the target server.

[0009] Further, based on the preset probe alive threshold and the preset probe alive frequency, the detection result of the target server is determined, including: obtaining a first load state of the target server, wherein the first load state is used to represent the load state of the target server at the current time; based on the first load state, predicting a second load state of the target server in a future time period; based on the second load state, adjusting the preset probe alive threshold and the preset probe alive frequency respectively to obtain a target probe alive threshold and a target probe alive frequency; based on the target probe alive threshold and the target probe alive frequency, detecting the target server to obtain the detection result.

[0010] Furthermore, based on the target liveness detection threshold and the target liveness detection frequency, the target server is probed to obtain the detection results, including: sending a liveness detection command to the target server and receiving a response message from the target server, wherein the liveness detection command is used to instruct the target server to send a response message to the server cluster; if a response message is received within the target liveness detection threshold, the detection result is determined to be that the target server is online.

[0011] Furthermore, the method also includes: if no response message is received within the target detection threshold, repeatedly sending detection commands to the target server based on a preset detection frequency until a response message is received or the number of repetitions reaches a preset number; if the number of repetitions reaches the preset number, determining that the detection result is that the target server is offline.

[0012] Furthermore, adjusting the probe results corresponding to the target server to indicate that the target server is online includes: testing the target server based on preset test cases to determine whether the target server is running normally; modifying the running configuration of the server cluster to control the target server's online status if the target server is running normally; determining the probe results of the target server based on preset probe thresholds and preset probe frequencies; and confirming that the probe results indicate the target server is online if the probe results indicate that the target server is online.

[0013] Furthermore, the stability of upgrading multiple servers in the server cluster is predicted to obtain stability prediction results for multiple servers. This includes: obtaining multiple operating states corresponding to multiple servers; inputting the operating state corresponding to any one server into the stability prediction model; using the stability prediction model to predict the degree of impact on the operating stability of the server cluster when upgrading any one server; and obtaining the stability prediction result for any one server.

[0014] According to another aspect of the embodiments of this application, a system upgrade apparatus is also provided, applied to a server cluster. The apparatus includes: a status prediction module, used to predict the upgrade stability of multiple servers in the server cluster when a system upgrade instruction is detected, and obtain stability prediction results corresponding to multiple servers, wherein the stability prediction results are used to characterize the degree of impact of multiple servers on the operational stability of the server cluster during the upgrade operation; an order determination module, used to determine the system upgrade order of multiple servers based on the stability prediction results corresponding to multiple servers; and a system upgrade module, used to perform system upgrades on multiple servers sequentially according to the system upgrade order based on a preset detection strategy, wherein the preset detection strategy is used to adjust the detection results corresponding to multiple servers, and the detection results are used to characterize whether multiple servers are in an online state.

[0015] According to another aspect of the embodiments of this application, an electronic device is also provided, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods in various embodiments of this application when it runs.

[0016] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0017] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0018] According to another aspect of the embodiments of this application, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods in various embodiments of this application.

[0019] In this embodiment, upon detecting a system upgrade command, the stability of multiple servers in the server cluster is predicted to obtain stability prediction results for each server. Based on these prediction results, the system upgrade order for each server is determined. Then, based on a preset activation strategy, the servers are upgraded sequentially according to the upgrade order. By using the stability detection results for each server, a reasonable system upgrade order can be determined. Subsequently, based on the preset activation strategy and the upgrade order, the servers are upgraded sequentially. This avoids a sudden drop in the service capacity of the server cluster caused by simultaneously upgrading multiple unstable servers, achieving the goal of maintaining a high service capacity of the server cluster during system upgrades. This improves the operational stability of the server cluster during system upgrades and solves the technical problem of low operational stability of server clusters during system upgrades in related technologies. Attached Figure Description

[0020] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0021] Figure 1 This is a flowchart of a system upgrade method according to an embodiment of this application;

[0022] Figure 2 This is a schematic diagram of a system upgrade device according to an embodiment of this application. Detailed Implementation

[0023] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0024] The collection, storage, use, processing, transmission, provision, and disclosure of financial data or user data involved in the technical solution of this application all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0025] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0026] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0027] According to an embodiment of this application, an embodiment of a system upgrade method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0028] Figure 1 This is a flowchart of a system upgrade method according to an embodiment of this application, such as... Figure 1 As shown, this method is applied to a server cluster and includes the following steps:

[0029] Step S102: Upon detecting a system upgrade command, the upgrade stability of multiple servers in the server cluster is predicted to obtain stability prediction results for multiple servers. The stability prediction results are used to characterize the degree of impact of multiple servers on the operational stability of the server cluster during the upgrade operation.

[0030] The aforementioned system upgrade command can be issued by a system administrator or automated operation and maintenance tool to instruct the server system in the server cluster to update from the current version to a new version.

[0031] The aforementioned server cluster can be a collection of multiple servers that can be interconnected via a network to work together to provide services with high availability, load balancing, and fault tolerance. Servers in the cluster can run the same or different services and are coordinated through cluster management software or services to achieve optimized resource allocation and efficient system operation.

[0032] The aforementioned upgrade stability refers to the ability of the server cluster to maintain normal operation and responsiveness during the system upgrade process, without being affected by upgrade operations and experiencing problems such as service interruption, performance degradation, or data loss. It is related to the smoothness, compatibility, and security of the upgrade process, as well as the performance and functional integrity of the upgraded system.

[0033] The stability prediction results mentioned above can be the degree of impact of server system upgrades on the operational stability of the server cluster, which can be pre-assessed through algorithms or models.

[0034] In one optional embodiment, considering that different servers may carry services or data of varying importance, upgrading some servers may significantly impact service continuity, data integrity, or performance, while other servers may be less affected. By predicting stability, the risk of upgrading each server can be assessed in advance, allowing for a more comprehensive upgrade plan and reducing potential negative impacts. Therefore, when the server cluster receives the upgrade instruction, it can predict the upgrade stability of multiple servers within the cluster. This prediction determines the degree of impact of the upgrade operation on the overall stability of the server cluster, resulting in a stability prediction for each server. During subsequent upgrades, the upgrade system can dynamically adjust its upgrade strategy based on this stability prediction, minimizing the impact of the upgrade process on the normal operation of the server cluster and improving its operational stability during the upgrade process.

[0035] For example, a server cluster can collect log data, performance metrics, error rates, and other information from past server system upgrades to build a historical upgrade database. Then, machine learning algorithms such as random forests, support vector machines, or neural networks can be used to train a predictive model based on historical data in this database. This model can identify characteristics that may lead to instability in the server cluster during system upgrades. In practical applications, when an upgrade command is received, the server cluster can input the configuration, load, and version information of multiple servers into the trained predictive model and use this model to predict the stability of each server upgrade.

[0036] For example, staff can create a virtual or test environment similar to the production environment to simulate the server system upgrade process. Then, they can simulate the upgrade for each server in the server cluster, monitoring changes in the cluster's stability before and after the upgrade to obtain simulation data. Based on this simulation data, the server cluster can then analyze the impact of each server upgrade on the cluster's stability and construct the aforementioned stability prediction results.

[0037] Step S104: Based on the stability prediction results of multiple servers, determine the system upgrade order of multiple servers.

[0038] The aforementioned system upgrade sequence can be based on the stability prediction results of each server, planning the order in which servers will undergo software or hardware upgrades. This sequence aims to minimize the impact of the upgrade process on the overall availability of the server cluster, ensuring that critical services remain continuous and the system's stability is largely guaranteed during the upgrade. In actual upgrades, prioritizing the upgrade of servers with higher predicted stability can effectively avoid system service interruptions caused by upgrade operations, thereby achieving a smooth and efficient system upgrade.

[0039] In one optional embodiment, considering that if all servers are upgraded simultaneously, it may cause excessive instantaneous pressure on the data center or other shared resources such as network bandwidth, affecting the stability and performance of the entire server cluster, and even causing the entire server cluster to crash. To minimize the impact of the server system upgrade process on the operational stability of the server cluster, the upgrade system can determine the upgrade order based on the stability prediction results of the multiple servers mentioned above. This allows the multiple servers in the server cluster to be upgraded sequentially according to the predicted order of least to greatest impact on the operational stability of the server cluster, thereby better balancing resource usage and ensuring a smooth transition of resource requirements during the upgrade process.

[0040] Step S106: Based on the preset detection strategy, upgrade the system of multiple servers in sequence according to the system upgrade order. The preset detection strategy is used to adjust the detection results of multiple servers, and the detection results are used to characterize whether multiple servers are online.

[0041] The aforementioned preset online detection strategy can be a rule or method used to sense and adjust the server's online status during system upgrades. By changing the parameters or logic of the preset online detection strategy, the upgrade system's judgment of the server's online status can be affected, thereby temporarily taking the server offline during the upgrade to avoid receiving new requests and ensuring that the upgrade operation does not interfere with the normal service of the system. Once the upgrade is completed and verified to be error-free, the preset online detection strategy can enable the server to promptly return to the online state and resume processing requests.

[0042] The aforementioned detection results refer to the status information obtained by the upgrade system after detecting the server's health status according to a preset detection strategy. For example, the detection results can be divided into online and offline types, used to indicate whether the server can respond to requests and provide services normally. In system upgrade scenarios, by adjusting the detection results, server availability can be dynamically controlled, achieving a smooth upgrade process and ensuring service continuity and stability.

[0043] In an optional embodiment, considering that traditional system upgrades typically require downtime, which can cause the entire server cluster to be unavailable for a period of time, impacting user experience and task processing continuity, the aforementioned pre-defined activation mechanism allows the upgrade system to selectively take any single server offline instead of suspending the entire server cluster. This means that other servers can still process requests during the upgrade, reducing the impact of the upgrade on the entire server cluster. Furthermore, the aforementioned system upgrade sequence ensures that upgrades are performed sequentially, in order of increasing impact on the stability of the server cluster. This allows servers with high stability to recover more quickly after the upgrade, meaning they can rapidly rejoin the load balancing pool to share the load with other servers and reduce the overall service time window caused by the upgrade. Based on this, the upgrade system can perform system upgrades on multiple servers sequentially according to the system upgrade order based on a preset liveness detection strategy. During the upgrade process, the upgrade system can use the preset liveness detection strategy to adjust the detection results of multiple servers, that is, whether multiple servers are online. This allows the computing tasks of any one of the multiple servers to be automatically distributed to the other servers by the load balancer when any one of the servers is being upgraded, thereby ensuring the stable operation of the entire server cluster.

[0044] For example, a server cluster can first select the server that needs upgrading from multiple servers according to the system upgrade order. Then, the server cluster can take this server offline and send a liveness detection command to it according to a preset liveness detection strategy. Whether the server responds to the liveness detection command within a preset time determines whether the server is offline. While the server is offline, the server cluster can perform a system upgrade on it. After the upgrade is complete, the server cluster can bring it back online. At this time, the server cluster can again send a liveness detection command to the server according to the preset liveness detection strategy. Whether the server responds to the liveness detection command within a preset time determines whether the server is online. If the server is online, the system upgrade for that server is complete. Then, the server cluster can determine the next server to be upgraded according to the system upgrade order and repeat the above upgrade steps until all servers have been upgraded.

[0045] In this embodiment, upon detecting a system upgrade command, the stability of multiple servers in the server cluster is predicted to obtain stability prediction results for each server. Based on these prediction results, the system upgrade order for each server is determined. Then, based on a preset activation strategy, the servers are upgraded sequentially according to the upgrade order. By using the stability detection results for each server, a reasonable system upgrade order can be determined. Subsequently, based on the preset activation strategy and the upgrade order, the servers are upgraded sequentially. This avoids a sudden drop in the service capacity of the server cluster caused by simultaneously upgrading multiple unstable servers, achieving the goal of maintaining a high service capacity of the server cluster during system upgrades. This improves the operational stability of the server cluster during system upgrades and solves the technical problem of low operational stability of server clusters during system upgrades in related technologies.

[0046] Furthermore, based on a preset liveness detection strategy, multiple servers are upgraded sequentially according to the system upgrade order. This includes: determining a target server from among the multiple servers based on the system upgrade order, wherein the target server is the server among the multiple servers that has not undergone an upgrade operation and whose corresponding stability prediction result is lower than the stability prediction results of other servers, and the other servers are the servers among the multiple servers that have not undergone an upgrade operation, excluding the target server; upgrading the target server based on the preset liveness detection strategy; repeating the steps of determining the target server from among the multiple servers based on the system upgrade order and upgrading the target server based on the preset liveness detection strategy until all multiple servers have completed the system upgrade.

[0047] The aforementioned target server refers to the server selected for system upgrade in the current upgrade round within a server cluster environment, based on the system upgrade order described above. Specifically, during the upgrade process, the target server is determined from servers that meet the following conditions: the server has not yet undergone an upgrade operation, and the server's predicted stability is lower than other non-upgraded servers in the same upgrade round. This selection method can efficiently complete the system upgrade work for all servers while minimizing the impact of server upgrades on the overall operational stability of the server cluster.

[0048] In one optional embodiment, considering that a preset liveness detection strategy can ensure that the services provided by the server cluster are not significantly affected during the upgrade process, when a server is selected as the target server for upgrade, it is temporarily marked as offline according to the preset liveness detection strategy. This means that during the upgrade, the server cluster can automatically redirect computing tasks to other normally operating servers, thereby avoiding task processing failures or user experience degradation caused by the upgrade. Based on this, the server cluster can identify the target server from multiple servers in the cluster for priority upgrade according to the system upgrade order. The selection of the target server is based on the principle of relatively low stability prediction results, thereby ensuring that the target server selected each time is one of the servers that has not undergone system upgrade, and the impact of the upgrade operation on the server cluster is lower than that of other servers. Subsequently, the server cluster can implement the preset liveness detection strategy, and by adjusting the load balancing configuration, make the target server temporarily offline and no longer accept new external requests, thereby ensuring that the overall external service capability of the server cluster is not affected during the upgrade process. After the target server completes the system upgrade and verifies stability, the server cluster can restore the target server to an online state again through the liveness detection mechanism, so that the target server can provide normal services. The above process can be repeated on every server in the cluster until all servers have completed the system upgrade. This system upgrade scheme based on the liveness detection mechanism not only ensures seamless service continuity during the upgrade, but also provides more flexible scheduling, freeing the upgrade work from low-business hours and significantly improving the operational efficiency and user experience of the server cluster.

[0049] For example, suppose there are six servers A, B, C, D, E, and F in a server cluster, all deploying the same service. Following the system upgrade sequence, server A, whose stability prediction result is lower than the other servers, is first identified as the target server. Then, the server cluster can, based on a preset liveness detection strategy, remove server A from the load balancer configuration, putting server A offline, and then perform a system upgrade on server A. After the upgrade is complete, the server cluster can re-detect and bring server A back online, thus completing the system upgrade for server A. Next, the server cluster can repeat the above steps to identify server B, which has a lower stability prediction result and has not yet been upgraded, as the new target server, and perform the same system upgrade operation to complete the system upgrade for server B. This process can be repeated for the other servers until all servers (A, B, C, D, E, and F) have completed the system upgrade. During this process, the other servers not selected as target servers will remain online to ensure the continuity of service provided by the server cluster.

[0050] Furthermore, based on the preset detection strategy, the target server is upgraded, including: adjusting the detection results corresponding to the target server to indicate that the target server is offline; upgrading the target server; and if the target server upgrade is successful, adjusting the detection results corresponding to the target server to indicate that the target server is online.

[0051] The aforementioned offline state can be a state in which a server temporarily stops providing services to the outside world. When a server is offline, it does not respond to requests from the network. At this time, both client access requests and interaction requests from other servers will be distributed to other servers for processing.

[0052] The aforementioned online state can refer to the state in which the server is operating normally and providing services to the outside world. When a server is online, it can receive and process requests from the network, including access requests from clients and interaction requests from other servers, ensuring that the functionality and performance of the server cluster meet user needs and maintaining the continuity and availability of the server cluster's computing tasks.

[0053] In one optional embodiment, marking the target server as offline during the upgrade process prevents users from unknowingly attempting to use the server, avoiding potential errors or delays and thus achieving an efficient system upgrade of the target server. Furthermore, considering that if the target server remains marked offline, its processing power cannot be fully utilized even after the upgrade is complete, potentially overloading other servers, it is necessary to promptly adjust the detection results of the target server to online status after the system upgrade is finished. This allows the server cluster to redistribute computing tasks to the target server, improving the availability and response speed of the server cluster. Therefore, the server cluster can adjust the detection results of the target server to offline status, meaning the server cluster will no longer distribute computing tasks to the target server, ensuring that the target server does not affect other running services during the upgrade process. Subsequently, the server cluster can perform a system version update operation on the target server. After completing the system upgrade and verifying that the service is normal, the server cluster can restore the target server's detection results to an online state, allowing the target server to be rejoined to the service cluster and start receiving and processing computing tasks. The same system upgrade operation can be performed on other servers in the service cluster in turn, thereby achieving a graceful upgrade of the entire server cluster without causing computing task execution failure or service interruption.

[0054] For example, in a server cluster consisting of five servers, when a system upgrade is needed, the probe result of target server A is first adjusted to offline. This means the load balancer will identify target server A as unavailable and stop sending requests to it. Subsequently, the server cluster can perform system upgrade operations on target server A, including but not limited to installing new software versions and updating configuration files. After confirming the successful upgrade of target server A and verifying its functionality through testing, the probe result of target server A can be readjusted to online. The load balancer will then mark target server A as available again and resume distributing requests to it. Next, the same process is followed for target servers B, C, D, and E identified in the next system upgrade round, until all servers are upgraded. Throughout this process, the server cluster can still provide stable services unaffected by the upgrade operations.

[0055] Furthermore, the preset liveness detection strategy includes a preset liveness detection threshold and a preset liveness detection frequency. The preset liveness detection threshold is used to characterize the response time of any server during the liveness detection process, and the preset liveness detection frequency is used to characterize the default value of the frequency of liveness detection operations on any server. Adjusting the detection result of the target server to indicate that the target server is offline includes: modifying the running configuration of the server cluster to control the target server to go offline, wherein the running configuration is used to control the online or offline status of any server; determining the detection result of the target server based on the preset liveness detection threshold and the preset liveness detection frequency; and if the detection result indicates that the target server is offline, determining that the detection result of the target server has been successfully adjusted to indicate that the target server is offline.

[0056] The aforementioned preset liveness detection threshold can be a standard response time value pre-set by the server cluster to determine whether the server is in an acceptable working state. Specifically, if the server's response time exceeds the aforementioned preset liveness detection threshold, the server cluster can consider the server to be offline.

[0057] The aforementioned preset online detection frequency can refer to the interval set in advance for the server cluster to periodically and automatically check whether the server is online. It can be used to define how often the server cluster should perform a status probe to update the online or offline status of the server in a timely manner, thereby ensuring the stability and availability of the server cluster.

[0058] The above-mentioned runtime configuration can be used to control the online and offline status of servers. For server clusters, the runtime configuration can include information about how servers are identified and scheduled by the load balancer. By modifying the runtime configuration, the online or offline status of servers can be dynamically adjusted.

[0059] In an optional embodiment, considering that if the target server remains online during the upgrade, some computing tasks might be assigned to this target server being upgraded, leading to service unavailability or computing task failure, adjusting the target server's probing result to an offline state ensures that no new requests are distributed to the target server, thus avoiding the risk of service interruption. Based on this, the server cluster can adopt a strategy combining dynamic adjustment of load balancing configuration and a liveness detection mechanism. By modifying the running configuration corresponding to the target server, the target server's state in the load balancer is adjusted to offline, thereby performing a system upgrade on the target server. Specifically, after modifying the aforementioned running configuration, the server cluster can use a preset liveness detection strategy to probe the target server to ensure that the target server is offline before performing a system upgrade. The preset liveness detection strategy includes a preset liveness detection threshold and a preset liveness detection frequency. The preset liveness detection threshold can serve as a default judgment value for determining whether the target server's response has timed out. If the target server's response times out, it can be considered that the detection result in the current round of liveness detection indicates that the target server is offline. Furthermore, since servers may temporarily go offline during operation due to factors other than upgrades, the server cluster can repeatedly probe the target server based on a preset liveness detection frequency. If the target server consistently fails to respond, it can be confirmed that the target server is offline. In this case, the server cluster can perform a system upgrade on the target server. Based on the above preset liveness detection strategy, it can be ensured that the server cluster can accurately identify the offline status of the target server during the upgrade process, avoiding service failures caused by external service requests being assigned to this server.

[0060] For example, since the above-mentioned runtime configuration controls the online or offline status of any server, the server cluster can use pre-deployed scripts to modify the runtime configuration of the server cluster to control the target server offline. Subsequently, the server cluster can perform a liveness detection operation on the target server based on a preset liveness detection strategy. If the target server is repeatedly probed multiple times based on a preset liveness detection frequency, and the target server still fails to respond within the preset liveness detection threshold on the last probe, then the server cluster can confirm that the probe result for the target server has been successfully adjusted to indicate that the target server is in an offline state.

[0061] Further, based on a preset detection threshold and a preset detection frequency, the detection result of the target server is determined, including: obtaining the first load state of the target server, wherein the first load state is used to characterize the load state of the target server at the current moment; based on the first load state, predicting the second load state of the target server in a future time period; based on the second load state, adjusting the preset detection threshold and the preset detection frequency respectively to obtain the target detection threshold and the target detection frequency; and based on the target detection threshold and the target detection frequency, detecting the target server to obtain the detection result.

[0062] The aforementioned first load status can be the actual workload of the target server at the current moment. It can be measured by indicators such as memory usage, disk I / O (Input / Output) activity, network traffic, or the number of requests being processed, and is used to reflect the current operating efficiency and carrying capacity of the target server.

[0063] The second load state mentioned above can be based on the first load state mentioned above, which is an estimate of the workload level that the target server may reach in the future. This allows the server cluster to understand the potential pressure on the target server in advance and dynamically adjust the preset detection threshold and preset detection frequency to mitigate the impact of system upgrades on the target server on the server cluster.

[0064] The aforementioned target liveness detection threshold can be a new liveness detection threshold obtained by dynamically adjusting the preset liveness detection threshold based on the second load state. When performing liveness detection on the target server, if the response time index of the target server is less than the target liveness detection threshold, the target server can be considered to be online and able to respond to requests normally. Conversely, if the response time index of the target server is greater than or equal to the target liveness detection threshold, the target server can be considered to be offline and unable to respond to requests normally.

[0065] The aforementioned target liveness detection frequency can be a new liveness detection frequency obtained by dynamically adjusting the preset liveness detection frequency based on the second load state. When the target server fails to respond during liveness detection, the server cluster can repeatedly detect the target server according to the aforementioned target liveness detection threshold until the target server responds or the number of repetitions reaches the preset number.

[0066] In one optional embodiment, considering that adjusting the detection threshold and frequency can adapt to changes in server load status, a suitable detection intensity can be maintained during server upgrades, avoiding misjudgments of the target server's offline status and ensuring the efficient operation of the server cluster. Based on this, the server cluster can collect and analyze the target server's first load status, predict the target server's second load status in the future, and then dynamically adjust the preset detection threshold and preset detection frequency to generate the target detection threshold and target detection frequency. This dynamic adjustment strategy ensures the accuracy and efficiency of the preset detection strategy, accurately obtaining the target server's offline status without affecting the overall performance of the server cluster. This avoids assigning newly received computing tasks to the target server undergoing system upgrades, thereby improving the operational stability of the server cluster during the upgrade process. After determining the aforementioned target detection threshold and target detection frequency, the server cluster can probe the target server based on the target detection threshold and target detection frequency to ensure timely and accurate capture of the target server's offline status.

[0067] For example, if the prediction results show that the target server may have a high load in the future, the server cluster can relatively shorten the preset detection threshold to obtain the target detection threshold and increase the preset detection frequency to obtain the target detection frequency. This enables short-term, high-frequency detection to determine in a timely manner whether the target server is offline. This avoids the situation where a large number of computing tasks are mistakenly distributed to the target server when the server cluster fails to detect the offline state, which would lead to the failure of many computing tasks and reduce the user experience.

[0068] Furthermore, based on the target liveness detection threshold and the target liveness detection frequency, the target server is probed to obtain the detection results, including: sending a liveness detection command to the target server and receiving a response message from the target server, wherein the liveness detection command is used to instruct the target server to send a response message to the server cluster; if a response message is received within the target liveness detection threshold, the detection result is determined to be that the target server is online.

[0069] The aforementioned liveness detection command can be used to check whether the target server is online and capable of responding. It can include communication protocol information to instruct the target server to return a response message.

[0070] In one optional embodiment, considering that receiving a response message from the target server is a key criterion for determining whether the target server is online, if the target server can return a response promptly and correctly, it indicates that the target server is online; conversely, if the target server fails to return a response, it indicates that the target server is offline. Based on this, the server cluster can send a liveness detection command to the target server. This command instructs the target server to send a response message back to the server cluster. After sending the liveness detection command, the server cluster can wait for the response message from the target server. If the server cluster receives the response message, and the time difference between sending the liveness detection command and receiving the response message is less than the aforementioned target liveness detection threshold, the server cluster can determine that the target server is online.

[0071] Furthermore, the method also includes: if no response message is received within the target detection threshold, repeatedly sending detection commands to the target server based on a preset detection frequency until a response message is received or the number of repetitions reaches a preset number; if the number of repetitions reaches the preset number, determining that the detection result is that the target server is offline.

[0072] In an optional embodiment, considering that a single instance of non-response from the target server during the liveness detection process might be due to network fluctuations or other non-upgrade behaviors, the server cluster still cannot easily determine whether the target server is offline. Therefore, the server cluster can repeatedly send liveness detection commands to the target server based on a preset liveness detection frequency. If the server cluster successfully receives the response message when the number of repetitions is less than the preset number, and the time difference between sending the liveness detection command and receiving the response message is less than the target liveness detection threshold, then the server cluster can determine that the detection result indicates the target server is online. Conversely, if the server cluster still fails to successfully receive the response message when the number of repetitions equals the preset number, then the server cluster can determine that the detection result indicates the target server is offline.

[0073] Furthermore, adjusting the probe results corresponding to the target server to indicate that the target server is online includes: testing the target server based on preset test cases to determine whether the target server is running normally; modifying the running configuration of the server cluster to control the target server's online status if the target server is running normally; determining the probe results of the target server based on preset probe thresholds and preset probe frequencies; and confirming that the probe results indicate the target server is online if the probe results indicate that the target server is online.

[0074] The aforementioned preset test cases can refer to a set of predefined test programs, conditions, or structures used to verify whether the functions, performance, and stability of the target server meet the expected specifications and standards. This allows for a comprehensive evaluation of the target server's operational status after the upgrade, thereby ensuring that the target server can provide services stably and efficiently after going online.

[0075] In an optional embodiment, considering that after the target server completes the system upgrade, functional testing is still required to verify whether the new version is correctly deployed and whether all expected functions work properly, this helps the server cluster discover any possible deployment errors and ensures that the upgraded target server does not introduce new instability factors to the entire server cluster. Therefore, the server cluster can pre-build multiple test cases, i.e., the aforementioned preset test cases. Subsequently, the server cluster can perform automated testing on the target server based on the preset test cases. If all preset test cases executed by the target server pass successfully, the server cluster can determine that the target server can operate normally. At this point, the server cluster can re-control the target server to come online and participate in the processing of computing tasks. Specifically, the server cluster can use pre-compiled scripts to modify the server cluster's runtime configuration, thereby controlling the target server to come online. After the target server comes online, in order to promptly identify the successful online status of the target server, the server cluster can also use the same method as the aforementioned steps, that is, based on the preset detection threshold and preset detection frequency, to determine the detection result of the target server. If the detection result indicates that the target server is online, the server cluster can determine that the detection result corresponding to the target server has been successfully adjusted to indicate that the target server is online. This ensures that the target server after the system upgrade can safely and error-free reconnect to the cluster and continue to provide services without any negative impact.

[0076] Furthermore, the stability of upgrading multiple servers in the server cluster is predicted to obtain stability prediction results for multiple servers. This includes: obtaining multiple operating states corresponding to multiple servers; inputting the operating state corresponding to any one server into the stability prediction model; using the stability prediction model to predict the degree of impact on the operating stability of the server cluster when upgrading any one server; and obtaining the stability prediction result for any one server.

[0077] The stability prediction model mentioned above can be a mathematical model or a machine learning algorithm, used to predict the impact of server upgrades on the stability of the server cluster based on historical data and current operating conditions.

[0078] In one optional embodiment, considering the impact of different server upgrades on cluster stability, a more reasonable system upgrade sequence can be designed. For example, servers whose stability prediction results indicate a smaller impact on cluster stability can be prioritized for upgrades, thereby ensuring the overall stability of the server cluster. Based on this, the server cluster can obtain the operating status of each server. Subsequently, the server cluster can input the operating status of any server into a pre-built stability prediction model to predict the impact of that server's upgrade operation on the overall cluster stability, thus obtaining the stability prediction results for each server. In the above steps, by analyzing the server's operating status, the stability prediction model can more accurately assess the stability risks that system upgrade operations may bring, enabling the server cluster to select the best upgrade timing and sequence based on the stability prediction results when making upgrade decisions, avoiding service interruptions or performance degradation of the server cluster caused by server system upgrade operations.

[0079] For example, a server cluster can collect operational log data from each server over a period of time, including but not limited to memory usage, disk I / O, network traffic, and error logs. Subsequently, the server cluster can preprocess the collected historical log data to extract features related to server operational stability, such as average response time, failure frequency, and peak resource usage. Based on the aforementioned operational log data, a stability prediction model can be built using machine learning algorithms such as random forests, support vector machines, or neural networks. In practical applications, the server cluster can input the real-time operational status of the servers into this model and use the model to output the aforementioned stability prediction results, enabling the server cluster to determine a more appropriate system upgrade sequence based on these results.

[0080] According to an embodiment of this application, a system upgrade apparatus is provided. It should be noted that this apparatus can be used to execute the system upgrade method applied to a server cluster described above. The specific implementation process and application scenarios are the same as in the above embodiments, and will not be repeated here. Figure 2 This is a schematic diagram of a system upgrade device according to an embodiment of this application, such as... Figure 2 As shown, this device is used in a server cluster and includes:

[0081] The status prediction module 202 is used to predict the upgrade stability of multiple servers in the server cluster when a system upgrade command is detected, and obtain the stability prediction results for multiple servers. The stability prediction results are used to characterize the degree of impact of multiple servers on the operational stability of the server cluster during the upgrade operation.

[0082] The sequence determination module 204 is used to determine the system upgrade sequence of multiple servers based on the stability prediction results corresponding to multiple servers.

[0083] The system upgrade module 206 is used to upgrade multiple servers sequentially according to the system upgrade order based on a preset detection strategy. The preset detection strategy is used to adjust the detection results of multiple servers, and the detection results are used to characterize whether multiple servers are online.

[0084] Furthermore, the system upgrade module is also used to: determine the target server from multiple servers based on the system upgrade order, wherein the target server is the server among the multiple servers that has not undergone upgrade operations and whose corresponding stability prediction result is lower than the stability prediction results of other servers, and the other servers are the servers among the multiple servers that have not undergone upgrade operations other than the target server; perform system upgrade on the target server based on a preset liveness detection strategy; and repeatedly execute the steps of determining the target server from multiple servers based on the system upgrade order and performing system upgrade on the target server based on the preset liveness detection strategy until all multiple servers have completed the system upgrade.

[0085] Furthermore, the system upgrade module is also used to: adjust the detection results corresponding to the target server to indicate that the target server is offline; perform a system upgrade on the target server; and, if the target server upgrade is successful, adjust the detection results corresponding to the target server to indicate that the target server is online.

[0086] Furthermore, the preset liveness detection strategy includes a preset liveness detection threshold and a preset liveness detection frequency. The preset liveness detection threshold is used to characterize the response time of any server during the liveness detection process, and the preset liveness detection frequency is used to characterize the default value of the frequency of liveness detection operations on any server. The system upgrade module is also used to: modify the running configuration of the server cluster to control the target server to go offline, wherein the running configuration is used to control the online or offline status of any server; determine the detection result of the target server based on the preset liveness detection threshold and the preset liveness detection frequency; and if the detection result indicates that the target server is offline, determine that the detection result corresponding to the target server has been successfully adjusted to indicate that the target server is offline.

[0087] Furthermore, the system upgrade module is also used to: obtain the first load state of the target server, wherein the first load state is used to characterize the load state of the target server at the current moment; predict the second load state of the target server in a future time period based on the first load state; adjust the preset detection threshold and preset detection frequency based on the second load state to obtain the target detection threshold and target detection frequency; and detect the target server based on the target detection threshold and target detection frequency to obtain the detection results.

[0088] Furthermore, the system upgrade module is also used to: send a liveness detection command to the target server and receive a response message from the target server, wherein the liveness detection command is used to instruct the target server to send a response message to the server cluster; if a response message is received within the target liveness detection threshold, the detection result is determined to be that the target server is online.

[0089] Furthermore, the device also includes: an instruction sending module, used to repeatedly send an activity detection instruction to the target server based on a preset activity detection frequency when no response message is received within the target activity detection threshold, until a response message is received or the number of repetitions reaches a preset number; and a status determination module, used to determine that the detection result is that the target server is in an offline state when the number of repetitions reaches a preset number.

[0090] Furthermore, the system upgrade module is also used to: test the target server based on preset test cases to determine whether the target server is running normally; modify the running configuration of the server cluster to control the target server to go online when the target server is running normally; determine the detection result of the target server based on preset detection threshold and preset detection frequency; and if the detection result shows that the target server is online, determine that the detection result of the target server is successfully adjusted to show that the target server is online.

[0091] Furthermore, the state prediction module is also used to: obtain multiple operating states corresponding to multiple servers; input the operating state corresponding to any one server into the stability prediction model, and use the stability prediction model to predict the degree of impact on the operating stability of the server cluster when upgrading any one server, so as to obtain the stability prediction result corresponding to any one server.

[0092] Embodiments of this application also provide an electronic device, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods in various embodiments of this application when it runs.

[0093] Embodiments of this application also provide a computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0094] Embodiments of this application also provide a computer program product, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0095] Embodiments of this application also provide a computer program product, including a non-volatile computer-readable storage medium for storing a computer program that, when executed by a processor, implements the methods in various embodiments of this application.

[0096] Embodiments of this application also provide a computer program that, when executed by a processor, implements the methods described in the various embodiments of this application.

[0097] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0098] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0099] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0100] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0101] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0102] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0103] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A system upgrade method, characterized in that, Applied to a server cluster, the method includes: Upon detecting a system upgrade command, the upgrade stability of multiple servers in the server cluster is predicted to obtain stability prediction results for the multiple servers. The stability prediction results are used to characterize the degree of impact of the multiple servers on the operational stability of the server cluster during the upgrade operation. Based on the stability prediction results corresponding to the multiple servers, the system upgrade order of the multiple servers is determined; Based on a preset detection strategy, the system upgrades are performed on the multiple servers sequentially according to the system upgrade order. The preset detection strategy is used to adjust the detection results corresponding to the multiple servers, and the detection results are used to characterize whether the multiple servers are online.

2. The system upgrade method according to claim 1, characterized in that, Based on a preset activation detection strategy, the system upgrades are performed sequentially on the multiple servers according to the system upgrade order, including: Based on the system upgrade order, a target server is determined from the plurality of servers. The target server is the server among the plurality of servers that has not undergone upgrade operations and whose corresponding stability prediction result is lower than the stability prediction results of other servers. The other servers are the servers among the plurality of servers that have not undergone upgrade operations, excluding the target server. Based on the preset detection strategy, the target server is upgraded. The steps of determining the target server from the plurality of servers based on the system upgrade order and performing system upgrades on the target server based on the preset activation strategy are repeated until all the plurality of servers have completed the system upgrade.

3. The system upgrade method according to claim 2, characterized in that, Based on the preset activity detection strategy, a system upgrade is performed on the target server, including: Adjust the detection results corresponding to the target server to indicate that the target server is offline; Upgrade the system of the target server; If the target server is successfully upgraded, the detection result corresponding to the target server will be adjusted to indicate that the target server is online.

4. The system upgrade method according to claim 3, characterized in that, The preset liveness detection strategy includes a preset liveness detection threshold and a preset liveness detection frequency. The preset liveness detection threshold is used to characterize the response time of any server during the liveness detection process of any server. The preset liveness detection frequency is used to characterize the default value of the frequency of liveness detection operation of any server. Adjusting the detection results corresponding to the target server to indicate that the target server is offline includes: The running configuration of the server cluster is modified to control the target server to go offline, wherein the running configuration is used to control the online or offline status of any one of the servers; Based on the preset detection threshold and the preset detection frequency, the detection result of the target server is determined; If the detection result indicates that the target server is offline, the detection result corresponding to the target server is successfully adjusted to indicate that the target server is offline.

5. The system upgrade method according to claim 4, characterized in that, Based on the preset detection threshold and the preset detection frequency, the detection result of the target server is determined, including: Obtain the first load state of the target server, wherein the first load state is used to characterize the load state of the target server at the current moment; Based on the first load state, predict the second load state of the target server in a future time period; Based on the second load state, the preset liveness detection threshold and the preset liveness detection frequency are adjusted respectively to obtain the target liveness detection threshold and the target liveness detection frequency; Based on the target activation threshold and the target activation frequency, the target server is probed to obtain the probe results.

6. The system upgrade method according to claim 5, characterized in that, Based on the target activation threshold and the target activation frequency, the target server is probed to obtain the probe results, including: Send a liveness probe command to the target server and receive a response message from the target server, wherein the liveness probe command is used to instruct the target server to send the response message back to the server cluster; If the response message is received within the target activation threshold, the detection result is determined to indicate that the target server is online.

7. The system upgrade method according to claim 6, characterized in that, The method further includes: If no response message is received within the target detection threshold, the detection command is repeatedly sent to the target server based on the preset detection frequency until the response message is received or the number of repetitions reaches the preset number. If the number of repetitions reaches a preset number, the detection result is determined to be that the target server is offline.

8. The system upgrade method according to claim 3, characterized in that, Adjusting the detection results corresponding to the target server to indicate that the target server is online includes: Based on preset test cases, the target server is tested to determine whether the target server is operating normally. With the target server running normally, the operating configuration of the server cluster is modified to control the target server to come online; The detection results of the target server are determined based on the preset detection threshold and preset detection frequency. If the detection result indicates that the target server is online, then the detection result corresponding to the target server is successfully adjusted to indicate that the target server is online.

9. The system upgrade method according to claim 1, characterized in that, The upgrade stability of multiple servers in the server cluster is predicted to obtain the stability prediction results for the multiple servers, including: Obtain the multiple operating states corresponding to the multiple servers; The operating status of any server is input into the stability prediction model. When the stability prediction model is used to upgrade any server, the impact on the operating stability of the server cluster is predicted, and the stability prediction result for any server is obtained.

10. A system upgrade device, characterized in that, Applied to server clusters, including: The status prediction module is used to predict the upgrade stability of multiple servers in the server cluster when a system upgrade instruction is detected, and to obtain the stability prediction results corresponding to the multiple servers. The stability prediction results are used to characterize the degree of impact of the multiple servers on the operational stability of the server cluster during the upgrade operation. The sequence determination module is used to determine the system upgrade sequence of the multiple servers based on the stability prediction results corresponding to the multiple servers; The system upgrade module is used to perform system upgrades on the multiple servers sequentially according to the system upgrade order based on a preset detection strategy. The preset detection strategy is used to adjust the detection results corresponding to the multiple servers, and the detection results are used to characterize whether the multiple servers are online.

11. An electronic device, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, performs the method according to any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored executable program, wherein, when the executable program is executed, it controls the device on which the storage medium is located to perform the method according to any one of claims 1 to 9.

13. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method according to any one of claims 1 to 9.

Images