A server extension method and module

Abstract

This invention discloses a server expansion method and module. Based on cluster operation data, this invention pre-assesses load trends and initiates the expansion process before overload risks materialize, significantly advancing the response window from several minutes. This allows ample time for node startup and traffic access, thereby significantly reducing the risk of increased service response latency or request failures caused by instantaneous peak traffic. Furthermore, this invention utilizes business data file migration to ensure new nodes are in the necessary state from the initial startup stage. Combined with dual preheating processes at the application and network layers, this ensures that nodes complete environment optimization and connection pre-establishment before officially receiving traffic. This "preloading" of the operating environment before new nodes officially receive business traffic avoids the problems of soaring initial request latency and increased error rates caused by directly connecting "cold" nodes in traditional solutions. Therefore, this invention is highly suitable for large-scale applications and deployments.

Description

Technical Field

[0001] This invention belongs to the field of server extension technology, specifically relating to a server extension method and module. Background Technology

[0002] In the fields of distributed systems and cloud computing, elastic scaling of server clusters is a key technology for ensuring service quality and resource utilization efficiency. Traditional server cluster expansion solutions typically employ a threshold-based passive triggering mechanism. This involves monitoring systems to collect node load metrics (such as CPU utilization, memory usage, and request queue length) in real time. When a metric exceeds a preset threshold, the expansion process is triggered, dynamically adding node instances. However, this approach suffers from significant lag. From the load rising to the threshold trigger to the new node starting up and connecting to traffic, it often takes several minutes or even longer. During this period, the service may already be overloaded, leading to increased response latency or request failures.

[0003] Meanwhile, in existing technologies, the process of new nodes receiving traffic after startup lacks a refined warm-up mechanism. That is, new nodes are often in a "cold state" in the early stage of startup. Existing technologies usually directly accept traffic, which will cause the latency of the first wave of requests to soar, the error rate to rise, and even trigger cascading failures. Therefore, there is an urgent need for a server expansion method that can achieve predictive scaling and enable new nodes to be connected smoothly in order to improve the elasticity and service quality of the server. Summary of the Invention

[0004] The purpose of this invention is to provide a server expansion method and module to solve the problems of significant lag caused by the threshold-based passive triggering mechanism for server expansion in the prior art, as well as the problems of soaring initial request latency, increased error rate, and even cascading failures caused by the lack of a refined warm-up mechanism.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: Firstly, a server extension method is provided, including: Obtain the operating data of the server cluster, and perform load prediction on the server cluster based on the operating data to obtain the load prediction data of the server cluster. Based on the load prediction data, determine whether the server cluster is at risk of overload; If so, configure the initial new server nodes for the server cluster; Identify the overloaded server units in the server cluster and migrate the business data files in the overloaded server units to the initial new server node to obtain the new server node; The new server node is subjected to application layer preheating and network layer preheating processes to obtain a preloaded server node; The preloaded server node is added to the overloaded server unit to complete the server expansion of the server cluster.

[0006] Based on the aforementioned disclosures, this invention pre-judges load trends using cluster operation data and initiates an expansion process before overload risks materialize, significantly advancing the response window from several minutes. This allows ample time for node startup and traffic access, thereby significantly reducing the risk of increased service response latency or request failures caused by instantaneous peak traffic. Furthermore, this invention utilizes business data file migration to ensure new nodes are in the necessary state from the outset. Combined with dual preheating processes at the application and network layers, it ensures that nodes complete environment optimization and connection pre-establishment before officially receiving traffic. This "preloading" of the operating environment before new nodes begin handling business traffic avoids the problems of soaring initial request latency and increased error rates caused by directly connecting "cold" nodes in traditional solutions. Therefore, this invention comprehensively improves the elasticity and service quality of server clusters, making it highly suitable for large-scale applications and deployments.

[0007] In one possible design, the server cluster includes multiple server units, and each server unit includes several server nodes; Among them, the overloaded server units identified in the server cluster include: For any server unit, obtain the number of business data files on each server node in the server unit, and the access frequency of each business data file; The access frequency of each server node is calculated based on the access frequency of each business data file and the number of business data files on each server node. The total access frequency of any server unit is calculated using the access frequency of each node. Based on the total access frequency, the average load of any server unit is calculated, and after all server units have been traversed, the average load of each server unit is obtained. The server unit with the highest average load is designated as the overloaded server unit.

[0008] In one possible design, the business data file of any server node includes a main business file and a secondary business file, and the secondary business file is a backup business file corresponding to the main business file of each server node in the same server unit excluding the aforementioned server node. The process of migrating the business data files in the overloaded server unit to the initial new server node to obtain the new server node includes: Calculate the average access frequency of files within each server node of the overloaded server unit; The server node with the highest average access frequency is designated as the overload node; From the main business files in the overloaded node, identify the files to be migrated and migrate them to the initial new server node; A swap and decomposition migration strategy is adopted to populate the initial new server node with secondary business files, so that the new server node is obtained after the secondary business files are populated.

[0009] In one possible design, the files to be migrated in the overloaded nodes are identified, including: Sort the main business files in the overloaded nodes in descending order of access frequency. The access frequency of each sorted main business file is accumulated sequentially until it first exceeds or equals the target value. Then, each main business file that participated in the accumulation is used as the file to be migrated. The target value is 0.5P, and P is the total load of the overloaded node.

[0010] In one possible design, a swap and decomposition migration strategy is employed to populate the initial new server node with secondary business files, including: From all the server nodes in the overloaded server unit except for the overloaded node, randomly select one server node as the designated node. From the secondary business files of the specified node, filter out the backup business files corresponding to the primary business files of the overloaded node; From the selected backup business files, the target file is separated, wherein the target file is the backup business file corresponding to the business files in the main business files of the overloaded node, excluding the files to be migrated; The target file is migrated to the initial new server node to serve as a secondary business file within the initial new server node; Each server node in the overloaded server unit, excluding the overloaded node, is designated as a backup service node. N-2 nodes are randomly selected from the backup service nodes as contributing nodes, where N is the total number of server nodes in the overloaded server unit; From the sub-business files corresponding to each contributing node, extract a backup business file as the backup migration file for the preloaded server node. The backup business files extracted from each contributing node are different from each other, and each backup business file is not the backup business file corresponding to the target file or the file to be migrated. Select the server nodes in the backup server nodes that were not selected as contributing nodes as the target nodes; From the secondary business files of the target node, select the backup business files corresponding to the primary business files of the overloaded nodes, and then split the selected backup business files into... and ,in, The backup business files corresponding to the files to be migrated. The target file; use or The secondary business files of each contributing node are filled in so that the number of secondary business files of each contributing node remains at N-1, and the backup business files in the secondary business files of any contributing node are different from each other. Each backup migration file is migrated to the initial new server node to obtain the new server node.

[0011] In one possible design, the new server node undergoes application layer preheating and network layer preheating to obtain a preloaded server node, including: Register the new server node to the management center of the server cluster, and set the traffic receiving weight of the new server node to zero so that the new server node stops receiving business request traffic; An application-layer warm-up task is performed on the new server node to obtain an initial warm-up node. The application-layer warm-up task includes cache warm-up, connection pool warm-up, and execution of hot code paths. A probe is enabled to send a simulated service request to the initial warm-up node, so as to monitor the probe response data of the initial warm-up node in real time after the simulated service request is sent, wherein the probe response data includes the probe request success rate; When the probe response data meets the preset conditions, the traffic receiving weight of the initial preheating node is set to be greater than 0 so that the initial preheating node can receive service request traffic. The traffic receiving weight of the initial preheating node is dynamically adjusted through a feedback control loop algorithm until the target weight is reached. Then, the preheating status of the initial preheating node is updated to an active state to obtain the preloaded server node.

[0012] In one possible design, the flow reception weight of the initial preheating node is dynamically adjusted through a feedback control loop algorithm, including: After receiving business request traffic, the performance indicators of the initial warm-up node are collected in real time, including response latency, number of active connections in the connection pool, number of error responses, memory utilization, and CPU utilization. The performance metric is compared with a preset threshold. If the performance metric is lower than the preset threshold, the traffic reception weight is increased. If the performance metric is higher than the preset threshold, the increase or decrease of the traffic reception weight is paused.

[0013] In one possible design, based on the operational data, load prediction is performed on the server cluster to obtain load prediction data for the server cluster, including: A load prediction model is obtained, wherein the load prediction model is trained by taking several sample operation data of the server cluster as input and the load prediction data of the server cluster within a preset time period as output. The load prediction model adopts an LSTM model, and the sample operation data includes the memory usage information, CPU usage information, request rate information and request queue length information of the server cluster within the set time period. The operational data is input into the load prediction model to obtain the load prediction data.

[0014] Secondly, a server extension module is provided, including: The load prediction unit is used to acquire the operating data of the server cluster and perform load prediction on the server cluster based on the operating data to obtain the load prediction data of the server cluster. The load prediction unit is used to determine whether there is an overload risk in the server cluster based on the load prediction data. The configuration unit is used to configure an initial new server node for the server cluster when the load prediction unit determines that the server cluster is at risk of overload. A data migration unit is used to identify overloaded server units in the server cluster and migrate the business data files in the overloaded server units to the initial new server node to obtain a new server node. The preheating unit is used to perform application layer preheating and network layer preheating processing on the new server node to obtain a preloaded server node. An expansion unit is used to add the preloaded server node to the overloaded server unit to complete the server expansion of the server cluster.

[0015] Thirdly, a server expansion device is provided. Taking the device as an electronic device as an example, it includes a memory, a processor, and a transceiver that are sequentially and communicatively connected. The memory is used to store a computer program, the transceiver is used to send and receive messages, and the processor is used to read the computer program and execute the server expansion method as described in the first aspect or any possible design of the first aspect.

[0016] Fourthly, a storage medium is provided that stores instructions which, when executed on a computer, perform the server extension method as described in the first aspect or any possible design of the first aspect.

[0017] Fifthly, a computer program product containing instructions is provided that, when the instructions are executed on a computer, causes the computer to perform the server extension method as described in the first aspect or any possible design of the first aspect.

[0018] Beneficial effects: (1) This invention pre-judges the load trend based on the cluster operation data and starts the expansion process before the overload risk is formed, which greatly advances the response window that was originally several minutes, thereby reserving sufficient time for node startup and traffic access, and thus significantly reducing the risk of increased service response delay or request failure caused by instantaneous peak. At the same time, this invention uses business data file migration to enable new nodes to have the necessary state in the early stage of startup. Combined with the dual preheating process of application layer and network layer, it ensures that the node completes environment optimization and connection pre-establishment before officially accessing traffic, so that the operating environment is "preloaded" before the new node officially takes over the business traffic, avoiding the problems of soaring delay and increased error rate of the first wave of requests caused by the direct access of "cold state" nodes in the traditional solution. Therefore, this invention comprehensively improves the elasticity and service quality of the server cluster, and is therefore very suitable for large-scale application and promotion. Attached Figure Description

[0019] Figure 1 A flowchart illustrating the steps of the server extension method provided in this embodiment of the invention; Figure 2 A structural diagram of the server expansion module provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the present invention will be briefly introduced below in conjunction with the accompanying drawings and descriptions of the embodiments or the prior art. Obviously, the following description of the structure of the accompanying drawings is only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. It should be noted that the description of these embodiments is for the purpose of helping to understand the present invention, but does not constitute a limitation of the present invention.

[0021] It should be understood that although the terms first, second, etc., may be used herein to describe various units, these units should not be limited by these terms. These terms are only used to distinguish one unit from another. For example, a first unit may be referred to as a second unit, and similarly, a second unit may be referred to as a first unit, without departing from the scope of the exemplary embodiments of the invention.

[0022] It should be understood that the term "and / or" that may appear in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, B exists alone, and A and B exist simultaneously. The term " / and" that may appear in this document describes another relationship between related objects, indicating that two relationships can exist. For example, A / and B can mean: A exists alone, and A and B exist alone. In addition, the character " / " that may appear in this document generally indicates that the related objects before and after it are in an "or" relationship.

[0023] Example: See Figure 1 As shown, the server expansion method provided in this embodiment can be executed by, but is not limited to, a computer device with certain computing resources, such as an electronic device like a server. It is understood that the aforementioned execution subject does not constitute a limitation on the embodiments of this application. Accordingly, the operation steps of this method can be, but are not limited to, the steps S1 to S6 below.

[0024] S1. Obtain the operating data of the server cluster, and perform load prediction on the server cluster based on the operating data to obtain the load prediction data of the server cluster; in specific implementation, for example, but not limited to, first obtaining the load prediction model; then, inputting the operating data into the load prediction model to obtain the load prediction data.

[0025] It should be noted that the aforementioned load prediction model is trained by taking several sample operation data of the server cluster as input and the load prediction data of the server cluster within a preset time period (such as the predicted value of the aforementioned sample operation data) as output. The sample operation data may include, but is not limited to, memory usage information, CPU usage information, request rate information, and request queue length information of the server cluster within the set time period. Of course, the types of data in the sample operation data of the server cluster can be increased or decreased according to the actual use scenario, and this embodiment does not make specific limitations.

[0026] Furthermore, the aforementioned load forecasting model uses the LSTM model; of course, other time series forecasting models can also be selected, such as the ARIM model, gated cyclic unit (GRU), Bayesian structured time series model (BSTS), etc. This embodiment is not limited to the aforementioned example.

[0027] Thus, after obtaining the load prediction data of the server cluster, it is possible to determine whether there is an overload risk, and then, based on the judgment result, to choose whether to proceed with the server expansion process.

[0028] The overload risk assessment process is shown in step S2 below.

[0029] S2. Based on the load prediction data, determine whether there is an overload risk in the server cluster. In this embodiment, the various indicators (i.e., the predicted operating data) in the load prediction data are weighted and summed to obtain a scalar data, which is then used as the total load. Next, determine whether the total load is greater than the set load of the server cluster. If it is less than or equal to the set load, no expansion is needed, and the process can be terminated directly. Otherwise, it is determined that there is an overload risk, and the server node expansion process needs to be performed, i.e., the following steps S3 to S6 are executed.

[0030] S3. If so, configure the initial new server nodes for the server cluster.

[0031] After configuring the initial new server nodes for the server cluster, data migration is required to provide the necessary business data for the subsequent node warm-up. The data migration process is shown in step S4 below.

[0032] S4. Identify the overloaded server units in the server cluster and migrate the business data files in the overloaded server units to the initial new server node to obtain the new server node.

[0033] In this embodiment, the server cluster includes multiple server units, and each server unit includes several server nodes. Furthermore, the business data file of any server node includes a main business file and secondary business files, and the secondary business files are backup business files corresponding to the main business files of all server nodes in the same server unit, excluding the aforementioned server node. Thus, assuming a server unit contains N server nodes, then any server node in that server unit contains its corresponding main business file and N-1 backup business files.

[0034] Therefore, in this embodiment, the access frequency of the server nodes is first calculated based on the main business file, and then the total access frequency of the server unit is calculated based on this. Next, the average load of each server unit is determined according to the total access frequency of each server unit. Finally, the overloaded server units are determined based on the average load. Optionally, the process of determining the overloaded server units can be, but is not limited to, the steps S41 to S45 below.

[0035] S41. For any server unit, obtain the number of business data files on each server node in the server unit, and the access frequency of each business data file; in this embodiment, obtain the number of main business files on each server node, and the access frequency of each main business file, and then calculate the node access frequency based on this, as shown in step S42 below.

[0036] S42. Calculate the node access frequency of each server node based on the access frequency of each business data file and the number of business data files on each server node. In this embodiment, for any server node, sum the access frequencies of each main business file in that server node to obtain the node access frequency. Thus, after obtaining the node access frequency of each server node, the total access frequency of the server unit can be calculated, as shown in step S43 below.

[0037] S43. Calculate the total access frequency of any server unit using the access frequency of each node; in a specific application, sum the access frequencies of all nodes to obtain the total access frequency of any server unit; then, the load of the server unit can be calculated based on the total access frequency, as shown in step S44 below.

[0038] S44. Calculate the average load of any server unit based on the total access frequency, and obtain the average load of each server unit after traversing all server units; in this embodiment, the average load can be obtained by dividing the total access frequency by the total number of server nodes in any server unit.

[0039] Thus, after obtaining the average load, the overloaded server units can be determined based on the load size, as shown in step S45 below.

[0040] S45. The server unit with the highest average load is designated as the overloaded server unit.

[0041] Based on the aforementioned steps S41 to S45, after identifying the overloaded server unit from the server cluster, the data files in the overloaded server unit can be migrated, as shown in the following steps S46 to S49.

[0042] S46. Calculate the average access frequency of files within each server node in the overloaded server unit; in specific applications, for any server node in the overloaded server unit, sum the access frequencies of each main business file in that server node, and then divide the summation result by the total number of main business files to obtain the average access frequency of that server node; therefore, in this embodiment, the average access frequency of files within a server node is used as a measure of the node's load. Thus, the server node with the highest average access frequency can be identified as an overloaded node, and files in the overloaded node can be migrated. The process is shown in steps S47 to S49 below.

[0043] S47. Designate the server node with the highest average access frequency as the overload node.

[0044] After identifying the server node with the highest load, the main business files on that server node need to be migrated to the newly added node (i.e., migrated to the initial new server node); the process is shown in step S48 below.

[0045] S48. From the main business files in the overloaded node, determine the files to be migrated and migrate the files to be migrated to the initial new server node; in specific applications, this embodiment uses the hot files in the main business files of the overloaded node as the files to be migrated, and then migrates them to the initial new server node.

[0046] Optionally, but not limited to, the following methods can be used to determine the aforementioned files to be migrated: First, the main business files in the overloaded node are sorted in descending order of access frequency. Then, the access frequency of each sorted main business file is accumulated sequentially until it first exceeds or equals the target value. At this point, the main business files that participate in the accumulation are designated as the files to be migrated. The target value is 0.5P, and P is the total load of the overloaded node (i.e., the sum of the access frequencies of each main business file).

[0047] The reason for determining the files to be migrated in the aforementioned manner is as follows: The core purpose of dynamic expansion is to add new nodes to the service units with the heaviest load and migrate part of the load on overloaded nodes to new nodes, so that the load of the two is close to balanced. Therefore, stopping when the accumulated sum first exceeds half of the total load can ensure that the amount of load migrated is as close as possible to the remaining amount of files on the original node, but not less than half, avoiding over-migration or under-migration. At the same time, accumulating in descending order of access frequency means that the files with the highest access frequency are migrated first, thereby reducing the load to the greatest extent.

[0048] Once the file to be migrated is identified, it can be used as the main business file of the initial new server node, and thus it can be migrated to the initial new server node.

[0049] Meanwhile, as explained above, each node also needs to store backup business files of the main business files of the other nodes. Therefore, it is also necessary to populate the initial new server node with backup business files so that the configured initial new server node meets the service unit configuration requirements. The backup business file population process is shown in step S49 below.

[0050] S49. Using an exchange and decomposition migration strategy, the initial new server node is populated with secondary business files to obtain the new server node after the secondary business files are populated. In specific applications, after adding a new server node, in order to avoid all secondary business files being migrated and reduce migration overhead, this embodiment provides an exchange and decomposition migration strategy to populate the secondary business files of the initial new server node. The process can be, but is not limited to, the steps S49a to S49k below.

[0051] S49a. Randomly select one server node from all server nodes in the overloaded server unit, excluding the overloaded node, as the designated node.

[0052] In this embodiment, it is equivalent to randomly selecting one of the N-1 backup business files corresponding to the main business file of the overloaded node and migrating it to the initial new server node as its corresponding backup business file. The process is shown in steps S49b to S49d below.

[0053] S49b. From the secondary business files of the specified node, filter out the backup business files corresponding to the main business files of the overloaded node; after filtering out the backup business files corresponding to the main business files of the overloaded node from the specified node, file separation can be performed. That is, since only part of the main business files of the overloaded node were migrated in the initial new server node, it is necessary to migrate the backup business files corresponding to the unmigrated files to the initial new server node. The process is shown in steps S49c and S49d below.

[0054] S49c. Separate the target file from the selected backup business files, wherein the target file is the backup business file corresponding to the business files in the main business files of the overloaded node, excluding the files to be migrated.

[0055] S49d. Migrate the target file to the initial new server node as a secondary business file in the initial new server node. In this embodiment, the above process is illustrated by an example: Assume that the overloaded server unit contains three server nodes: node 1, node 2, and node 3. The main business files of nodes 1-3 are A, B, and C, respectively. Therefore, the main business file of node 1 is A, and its secondary business files are B' (the backup business file corresponding to the main business file B in node 2) and C' (the backup business file corresponding to the main business file C in node 3). Similarly, the main business file of node 2 is B, and its secondary business files are A' (the backup business file corresponding to the main business file A in node 1) and C', while the main business file of node 3 is C, and its secondary business files are A' (the backup business file corresponding to the main business file A in node 1) and B'.

[0056] In this scenario, we assume node 1 is an overloaded node, and A = A1 + A2, where A2 represents the file to be migrated, and A1 is the file in A excluding A1; meanwhile, the backup business file corresponding to A1 is... The backup business file corresponding to A2 is .

[0057] Furthermore, after the files to be migrated are migrated, the files contained in node 1 are (A1, B', C'), the files contained in node 2 are (B, A', C'), and the files contained in node 3 are (C, A', B'). Similarly, the files contained in the initial new server node are (A2).

[0058] At this point, excluding the overloaded node, the remaining server nodes are node 2 and node 3. Therefore, one of node 2 and node 3 is randomly selected as the designated node. Then, the backup business file corresponding to A1 can be obtained from the designated node. If node 2 is selected as the designated node, then the sub-business file A' of node 2 will be separated into... Then Migrate to the initial new server node.

[0059] Therefore, node 1 now contains the file (A1, B', C'), and node 2 contains the file (B, (C'), A' in node 2 becomes The reason is: it was separated from A' Going out, node 3 contains the file (C, A', B'), while the initial new server node contains the file (A2, ).

[0060] Thus, after migrating one backup business file, the initial new server node still needs N-2 backup business files. This embodiment uses a decomposition and exchange strategy to fill in N-2 backup business files, as shown in steps S49e to S49k below.

[0061] S49e. Each server node in the overloaded server unit, excluding the overloaded node, is designated as a backup service node.

[0062] S49f. Randomly select N-2 nodes from the backup service nodes as contributing nodes, where N is the total number of server nodes in the overloaded server unit.

[0063] In this embodiment, after completing one After the migration, the backup business files corresponding to the main business files of the overloaded node will still have N-2 copies distributed on other nodes. However, the new node is not allowed to store more than two copies of the same data. Therefore, the N-2 copies cannot be directly migrated to the new node. They need to be "swapped" to other nodes. At this time, N-2 nodes are selected as contributing nodes from all nodes except the overloaded node and the new node. Then, a backup business file is extracted from the secondary business files stored in the contributing nodes for swapping. The process is shown in step S49g below.

[0064] S49g. Extract a backup business file from the sub-business files corresponding to each contributing node, and use it as the backup migration file for the preloaded server node. The backup business files extracted from each contributing node are different from each other, and each backup business file is not the backup business file corresponding to the target file or the file to be migrated.

[0065] Based on the example above, the backup service nodes are Node 2 and Node 3. At this time, it is necessary to randomly select 3-2=1 nodes from Node 2 and Node 3 as contributing nodes. For example, Node 2 can be selected again as a contributing node. Then, the backup business files need to be extracted from the sub-business files of Node 2.

[0066] As previously stated, the file contained in node 2 is (B, (C'), its sub-business document is Therefore, it is necessary to start from C'. Choose one from C' to serve as the backup migration file; the selected file must meet the following condition: it is not... or Therefore, only C' can be extracted as a backup migration file; at this time, the file contained in node 2 is (B, This is because C' was extracted and cached; while the files contained in node 1 and node 3 remain unchanged.

[0067] Meanwhile, new nodes are not allowed to store more than two copies of the same data. Therefore, it is necessary to ensure that the backup business files extracted from each contributing node are different. As a result, after the backup business files of each contributing node are extracted, the number of secondary business files in each contributing node will be reduced by one. Therefore, it is necessary to perform swapping and filling, and the process is shown in steps S49h to S49j below.

[0068] S49h. Select the server nodes in the backup server nodes that were not selected as contributing nodes as the target nodes.

[0069] S49i. From the secondary service files of the target node, select the backup service file corresponding to the primary service file of the overloaded node, and split the selected backup service file into... and ,in, The backup business files corresponding to the files to be migrated. The target file is referred to here.

[0070] In this embodiment, the backup service nodes are Node 2 and Node 3, and Node 2 has been selected as the contributing node. Therefore, Node 3 is selected as the target node. At this point, it is necessary to extract A' from the target node's sub-business file and separate it into... and Then, the nodes in node 3 can be used. or To fill the backup empty slots in node 2, the process is as shown in step S49j below.

[0071] S49j. Utilizing or The secondary business files of each contributing node are populated to keep the number of secondary business files of each contributing node at N-1, and to ensure that the backup business files in the secondary business files of any contributing node are different from each other.

[0072] In this embodiment, the file contained in node 2 is (B, Furthermore, during the swapping process, nodes are not allowed to store more than two copies of the same data. Therefore, only the data in node 3 can be swapped. Fill into node 2, and retain the data in node 3. At this point, the file contained in node 2 becomes (B, , ), while the file contained in node 3 becomes (C, At this point, the number of backup business files of node 2 is 2, which meets the requirement of N-1 backup data storage quantity.

[0073] After filling the backup slots of each contributing node, the backup migration files extracted from each contributing node can be migrated to the initial new server node, thereby completing the filling of the backup business files of the initial new server node and obtaining the new server node. The process is shown in step S49k below.

[0074] S49k. Migrate each backup migration file to the initial new server node to obtain the new server node; based on the foregoing example, the initial new server node contains the following files (A2, Node 1 contains the file (A1, B', C'), and Node 2 contains the file (B, C'). , ), and the files contained in node 3 then become (C, ,B').

[0075] Through the aforementioned steps S49a to S49k, this embodiment utilizes existing backup business files for decomposition and reconfiguration, avoiding a large amount of additional data transmission and controlling migration overhead to grow at an approximately linear (rather than quadratic) rate. This avoids the problem of high migration overhead, saves system resources, and accelerates server expansion efficiency.

[0076] After migrating the business data files in the overloaded server unit, node preheating can be performed to avoid the problems of latency spikes, error rate increases and cascading failures caused by "cold state" nodes directly taking over traffic; the node preheating process is as shown in step S5 below.

[0077] S5. Perform application layer preheating and network layer preheating processing on the new server node to obtain a preloaded server node; in specific implementation, for example, but not limited to, the following steps S51 to S54 can be used to achieve node preheating.

[0078] S51. Register the new server node to the management center of the server cluster, and set the traffic receiving weight of the new server node to zero so that the new server node stops receiving business request traffic; in this embodiment, node registration is performed by calling the service API (Consul, etcd, Nacos) to register node information; at the same time, setting the traffic receiving weight to 0 can completely shield the network layer of the node from traffic, creating an "isolated" environment for warm-up.

[0079] Then, the application layer can be preheated, as shown in step S52 below.

[0080] S52. Perform an application-layer preheating task on the new server node to obtain an initial preheated node. The application-layer preheating task includes cache preheating, connection pool preheating, and execution of hot code paths. In this embodiment, application-layer preheating completes resource initialization, cache loading, connection pool establishment, and code JIT preheating within the node. The detailed process is as follows: Since the main business file of the new server node was obtained during the file migration process, the business service type corresponding to the main business file is known. Therefore, during cache preheating, the hot data corresponding to the main business file can be recorded in the local cache or distributed cache. For example, if the business service type corresponding to the main business file is e-commerce, then the information of popular products will be loaded into the cache. Of course, different hot data can be defined according to different business service types. This embodiment is not limited to the example above.

[0081] After cache preheating is completed, connection pool preheating can be performed, which involves pre-creating connection pools for databases, downstream services, or message queues. If a database connection pool is used, the minimum number of connections is created in advance, and a query statement is sent to the database to verify the validity of the database connection. If it is a downstream service, a connection is pre-established with the downstream HTTP client. If it is a message queue, producer / consumer connections are created to subscribe to specified topics, such as product information push.

[0082] After the connection pool is established, hot code paths can be executed. For JIT compiled languages ​​such as Java and C#, the code needs to be interpreted during the first execution and compiled into machine code only after multiple calls. Therefore, the warm-up phase can execute a specified business process several times to allow JIT to complete optimization in advance. That is, a request process is generated based on the business service file of the main business file, and then the request process is executed several times to complete the JIT compilation. For example, based on the previous example, requests such as order creation and user query can be executed.

[0083] Thus, the application layer can be warmed up in the aforementioned manner, and then the network layer can be warmed up, as shown in steps S53 and S54 below.

[0084] S53. Enable probes to send simulated service requests to the initial warm-up node, so as to monitor the probe response data of the initial warm-up node in real time after sending the simulated service requests, wherein the probe response data includes the probe request success rate; in this embodiment, after the application layer warm-up is completed, traffic can be gradually introduced through the load balancer, while allowing probe traffic to establish network connections in advance, so as to achieve "connection ready" and "gradual service traffic".

[0085] Among them, enabling probes to send simulated service requests to the initial warm-up nodes refers to actively generating traffic of the same type as the actual service through probes deployed in the system, and actively measuring and probing the nodes to monitor node health and network quality. It is the key to connecting "application layer warm-up completion" and "formal service traffic access".

[0086] Optionally, the frequency of sending simulated business requests to the node via probe traffic can be 3 to 5 times that of normal health checks. In this way, by sending simulated business requests to the initial warm-up node through the aforementioned probe, the actual number of connections in the HTTP connection pool and database connection pool can be reduced to the minimum idle value, avoiding the temporary creation of connections during subsequent formal traffic.

[0087] Furthermore, after sending a simulated service request, the corresponding response data, such as the probe request success rate, can be obtained, and it can be determined whether it meets the preset conditions. In this way, when it is determined that the preset conditions are met, traffic can be gradually increased, as shown in step S54 below.

[0088] S54. When the probe response data meets the preset conditions, the traffic receiving weight of the initial preheating node is set to be greater than 0 so that the initial preheating node can receive service request traffic. The traffic receiving weight of the initial preheating node is dynamically adjusted through a feedback control loop algorithm until the target weight is reached. Then, the preheating status of the initial preheating node is updated to an active state to obtain the preloaded server node.

[0089] In this embodiment, the preset condition is that the probe request success rate is greater than the success rate threshold (such as 98% or 100%). When the preset condition is met, the traffic receiving weight of the initial warm-up node is set to be greater than 0 (such as setting a very low value, such as 1%), so that the initial warm-up node receives business request traffic, that is, introduces actual business. Then, the weight can be dynamically adjusted according to the response data of the actual business requests until the target weight is reached. In this way, traffic can be gradually introduced and smoothly integrated into the cluster.

[0090] Optionally, the process of dynamically adjusting the traffic receiving weight of the initial preheating node is as follows: (1) After receiving the service request traffic, the performance indicators of the initial preheating node are collected in real time (wherein, the performance indicators include response latency, number of active connection pools, number of error responses, memory utilization and CPU utilization); (2) The performance indicators are compared with a preset threshold. If the performance indicators are lower than the preset threshold, the traffic receiving weight is increased. If the performance indicators are higher than the preset threshold, the increase or decrease of the traffic receiving weight is paused.

[0091] In this embodiment, each performance indicator is assigned its own threshold. Weight enhancement is performed only when all performance indicators are less than the corresponding threshold; otherwise, the increase or decrease of weight can be paused.

[0092] The formula for increasing the weight can be, but is not limited to, the following: Weight' = min(target_weight, weight+delta), where Weight' is the increased traffic receiving weight, target_weight is the target weight, weight is the previous traffic receiving weight, and delta is the set increment step size; meanwhile, reducing the weight is weight multiplied by a fixed ratio (e.g., 0.9).

[0093] In this way, by dynamically adjusting the traffic reception weight in the aforementioned manner until it reaches the target weight (a set value), the preheating of the new server node can be completed.

[0094] Therefore, after the node is preheated through the aforementioned steps S51 to S54, the preloaded server node can be smoothly introduced, as shown in step S6 below.

[0095] S6. Add the preloaded server node to the overloaded server unit to complete the server expansion of the server cluster; in this embodiment, after the preloaded server node is connected, the service unit node list can be updated so that the new node can start receiving requests, thereby restoring the normal operation of the server cluster.

[0096] Therefore, through the server expansion method described in detail in steps S1 to S6 above, this invention pre-judges the load trend based on cluster operation data and initiates the expansion process before the risk of overload occurs, significantly advancing the response window that was originally several minutes. This allows sufficient time for node startup and traffic access, thereby significantly reducing the risk of increased service response latency or request failures caused by instantaneous peaks. At the same time, this invention uses business data file migration to ensure that new nodes have the necessary state at the initial startup stage. Combined with dual preheating processes at the application layer and network layer, this ensures that nodes complete environment optimization and connection pre-establishment before officially accessing traffic. This allows the operating environment to be "preloaded" before new nodes officially take on business traffic, avoiding the problems of soaring initial request latency and increased error rate caused by direct access of "cold state" nodes in traditional solutions. Therefore, this invention comprehensively improves the elasticity and service quality of server clusters, making it highly suitable for large-scale applications and promotion.

[0097] like Figure 2 As shown, the second aspect of this embodiment provides a hardware module for implementing the server expansion method described in the first aspect of the embodiment, comprising: The load prediction unit is used to acquire the operating data of the server cluster and perform load prediction on the server cluster based on the operating data to obtain the load prediction data of the server cluster.

[0098] The load prediction unit is used to determine whether there is an overload risk in the server cluster based on the load prediction data.

[0099] The configuration unit is used to configure an initial new server node for the server cluster when the load prediction unit determines that the server cluster is at risk of overload.

[0100] The data migration unit is used to identify overloaded server units in the server cluster and migrate the business data files in the overloaded server units to the initial new server node to obtain a new server node.

[0101] The preheating unit is used to perform application layer preheating and network layer preheating processing on the new server node to obtain a preloaded server node.

[0102] An expansion unit is used to add the preloaded server node to the overloaded server unit to complete the server expansion of the server cluster.

[0103] The working process, working details and technical effects of the module provided in this embodiment can be found in the first aspect of the embodiment, and will not be repeated here.

[0104] like Figure 3 As shown, the third aspect of this embodiment provides a server expansion device. Taking the device as an electronic device as an example, it includes: a memory, a processor, and a transceiver that are connected in sequence. The memory is used to store a computer program, the transceiver is used to send and receive messages, and the processor is used to read the computer program and execute the server expansion method as described in the first aspect of the embodiment.

[0105] For specific examples, the memory may include, but is not limited to, random access memory (RAM), read-only memory (ROM), flash memory, first-in-first-out (FIFO) memory, and / or first-in-last-out (FILO) memory, etc.; specifically, the processor may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor may be implemented using at least one hardware form of DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), PLA (Programmable Logic Array). The processor may also include a main processor and a coprocessor. The main processor, also known as the CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state.

[0106] In some embodiments, the processor may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. For example, the processor may not be limited to microprocessors of the STM32F105 series, reduced instruction set computer (RISC) microprocessors, x86 architecture processors, or processors with integrated neural network processing units (NPUs). The transceiver may be, but is not limited to, a Wi-Fi transceiver, a Bluetooth transceiver, a General Packet Radio Service (GPRS) transceiver, a ZigBee (a low-power LAN protocol based on the IEEE 802.15.4 standard) transceiver, a 3G transceiver, a 4G transceiver, and / or a 5G transceiver. Furthermore, the device may also include, but is not limited to, a power module, a display screen, and other necessary components.

[0107] The working process, working details and technical effects of the electronic device provided in this embodiment can be found in the first aspect of the embodiment, and will not be repeated here.

[0108] The fourth aspect of this embodiment provides a storage medium that stores instructions containing the server extension method described in the first aspect of the embodiment. That is, the storage medium stores instructions that, when executed on a computer, perform the server extension method as described in the first aspect of the embodiment.

[0109] The storage medium refers to a carrier for storing data, which may include, but is not limited to, floppy disks, optical disks, hard disks, flash memory, USB flash drives, and / or memory sticks. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices.

[0110] The working process, working details and technical effects of the storage medium provided in this embodiment can be found in the first aspect of the embodiment, and will not be repeated here.

[0111] The fifth aspect of this embodiment provides a computer program product containing instructions that, when executed on a computer, cause the computer to perform the server extension method as described in the first aspect of the embodiment, wherein the computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device.

[0112] Finally, it should be noted that the above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A server extension method, characterized in that, include: Obtain the operating data of the server cluster, and perform load prediction on the server cluster based on the operating data to obtain the load prediction data of the server cluster. Based on the load prediction data, determine whether the server cluster is at risk of overload; If so, configure the initial new server nodes for the server cluster; Identify the overloaded server units in the server cluster and migrate the business data files in the overloaded server units to the initial new server node to obtain the new server node; The new server node is subjected to application layer preheating and network layer preheating processes to obtain a preloaded server node; The preloaded server node is added to the overloaded server unit to complete the server expansion of the server cluster.

2. The method according to claim 1, characterized in that, The server cluster includes multiple server units, and each server unit includes several server nodes; Among them, the overloaded server units identified in the server cluster include: For any server unit, obtain the number of business data files on each server node in the server unit, and the access frequency of each business data file; The access frequency of each server node is calculated based on the access frequency of each business data file and the number of business data files on each server node. The total access frequency of any server unit is calculated using the access frequency of each node. Based on the total access frequency, the average load of any server unit is calculated, and after all server units have been traversed, the average load of each server unit is obtained. The server unit with the highest average load is designated as the overloaded server unit.

3. The method according to claim 2, characterized in that, The business data file of any server node includes a main business file and a secondary business file, and the secondary business file is a backup business file corresponding to the main business file of each server node in the same server unit excluding the aforementioned server node; The process of migrating the business data files in the overloaded server unit to the initial new server node to obtain the new server node includes: Calculate the average access frequency of files within each server node of the overloaded server unit; The server node with the highest average access frequency is designated as the overload node; From the main business files in the overloaded node, identify the files to be migrated and migrate them to the initial new server node; A swap and decomposition migration strategy is adopted to populate the initial new server node with secondary business files, so that the new server node is obtained after the secondary business files are populated.

4. The method according to claim 3, characterized in that, The files to be migrated in the overloaded nodes were identified, including: Sort the main business files in the overloaded nodes in descending order of access frequency. The access frequency of each sorted main business file is accumulated sequentially until it first exceeds or equals the target value. Then, each main business file that participated in the accumulation is used as the file to be migrated. The target value is 0.5P, and P is the total load of the overloaded node.

5. The method according to claim 3, characterized in that, A swap and decomposition migration strategy is employed to populate the initial new server node with secondary business files, including: From all the server nodes in the overloaded server unit except for the overloaded node, randomly select one server node as the designated node. From the secondary business files of the specified node, filter out the backup business files corresponding to the primary business files of the overloaded node; From the selected backup business files, the target file is separated, wherein the target file is the backup business file corresponding to the business files in the main business files of the overloaded node, excluding the files to be migrated; The target file is migrated to the initial new server node to serve as a secondary business file within the initial new server node; Each server node in the overloaded server unit, excluding the overloaded node, is designated as a backup service node. N-2 nodes are randomly selected from the backup service nodes as contributing nodes, where N is the total number of server nodes in the overloaded server unit; From the sub-business files corresponding to each contributing node, extract a backup business file as the backup migration file for the preloaded server node. The backup business files extracted from each contributing node are different from each other, and each backup business file is not the backup business file corresponding to the target file or the file to be migrated. Select the server nodes in the backup server nodes that were not selected as contributing nodes as the target nodes; From the secondary business files of the target node, select the backup business files corresponding to the primary business files of the overloaded nodes, and then split the selected backup business files into... and ,in, The backup business files corresponding to the files to be migrated. The target file; use or The secondary business files of each contributing node are filled in so that the number of secondary business files of each contributing node remains at N-1, and the backup business files in the secondary business files of any contributing node are different from each other. Each backup migration file is migrated to the initial new server node to obtain the new server node.

6. The method according to claim 1, characterized in that, The new server node undergoes application layer preheating and network layer preheating processes to obtain a preloaded server node, including: Register the new server node to the management center of the server cluster, and set the traffic receiving weight of the new server node to zero so that the new server node stops receiving business request traffic; An application-layer warm-up task is performed on the new server node to obtain an initial warm-up node. The application-layer warm-up task includes cache warm-up, connection pool warm-up, and execution of hot code paths. A probe is enabled to send a simulated service request to the initial warm-up node, so as to monitor the probe response data of the initial warm-up node in real time after the simulated service request is sent, wherein the probe response data includes the probe request success rate; When the probe response data meets the preset conditions, the traffic receiving weight of the initial preheating node is set to be greater than 0 so that the initial preheating node can receive service request traffic. The traffic receiving weight of the initial preheating node is dynamically adjusted through a feedback control loop algorithm until the target weight is reached. Then, the preheating status of the initial preheating node is updated to an active state to obtain the preloaded server node.

7. The method according to claim 6, characterized in that, The flow reception weight of the initial preheating node is dynamically adjusted through a feedback control loop algorithm, including: After receiving business request traffic, the performance indicators of the initial warm-up node are collected in real time, including response latency, number of active connections in the connection pool, number of error responses, memory utilization, and CPU utilization. The performance metric is compared with a preset threshold. If the performance metric is lower than the preset threshold, the traffic reception weight is increased. If the performance metric is higher than the preset threshold, the increase or decrease of the traffic reception weight is paused.

8. The method according to claim 1, characterized in that, Based on the operational data, load prediction is performed on the server cluster to obtain load prediction data for the server cluster, including: A load prediction model is obtained, wherein the load prediction model is trained by taking several sample operation data of the server cluster as input and the load prediction data of the server cluster within a preset time period as output. The load prediction model adopts an LSTM model, and the sample operation data includes the memory usage information, CPU usage information, request rate information and request queue length information of the server cluster within the set time period. The operational data is input into the load prediction model to obtain the load prediction data.

9. A server expansion module, characterized in that, include: The load prediction unit is used to acquire the operating data of the server cluster and perform load prediction on the server cluster based on the operating data to obtain the load prediction data of the server cluster. The load prediction unit is used to determine whether there is an overload risk in the server cluster based on the load prediction data. The configuration unit is used to configure an initial new server node for the server cluster when the load prediction unit determines that the server cluster is at risk of overload. A data migration unit is used to identify overloaded server units in the server cluster and migrate the business data files in the overloaded server units to the initial new server node to obtain a new server node. The preheating unit is used to perform application layer preheating and network layer preheating processing on the new server node to obtain a preloaded server node. An expansion unit is used to add the preloaded server node to the overloaded server unit to complete the server expansion of the server cluster.

10. A computer program product containing instructions, characterized in that, When the instructions are executed on the computer, the computer performs the server extension method as described in any one of claims 1 to 8.

Images