Multi-server quick deployment method and device, electronic equipment and storage medium

Abstract

The invention provides a multi-server quick deployment method and device, electronic equipment and a storage medium, and the method comprises the steps: analyzing a configuration file to determine a target server needing to deploy an application system and a deployment sequence; generating an incremental package of the application system; fragmenting the incremental packet, and calculating a concurrent quantity; judging whether the target server is ready or not; and if the target servers are ready, sending the fragmented incremental packets to a plurality of concurrent target servers according to a deployment sequence, so that the target servers deploy the application system. According to the scheme, the target server to be deployed and the deployment sequence are determined through the configuration file, and the incremental package of the application system is fragmented. The fragmented incremental packages are sent to the multiple ready target servers in a concurrent mode, so that the target servers deploy the application systems, the deployment time consumption of the servers is reduced, and the deployment efficiency is improved.

Description

Technical Field

[0001] The present invention relates to the field of distributed system operation and maintenance technology, and in particular to a multi-server rapid deployment method, device, electronic device and storage medium. Background Art

[0002] In cloud computing environments, big data clusters, and distributed applications, it's often necessary to deploy the same application system to dozens or even hundreds of servers simultaneously. Currently, a linear execution model (such as the Ansible tool) is commonly used to deploy multiple servers simultaneously. However, when the number of servers exceeds 50, the deployment time of the linear execution model increases exponentially, resulting in long server deployment times and low deployment efficiency. Summary of the Invention

[0003] In view of this, embodiments of the present invention provide a multi-server rapid deployment method, apparatus, electronic device, and storage medium to solve the problems of long server deployment time and low deployment efficiency in a linear execution mode.

[0004] To achieve the above objectives, the embodiments of the present invention provide the following technical solutions:

[0005] A first aspect of an embodiment of the present invention discloses a method for rapid deployment of multiple servers, the method comprising:

[0006] Parse the configuration file to determine the target server and deployment order for the application system;

[0007] generating an incremental package for the application system;

[0008] Slice the incremental package and calculate the concurrent quantity;

[0009] Determining whether the target server is ready;

[0010] If the target server is ready, the fragmented incremental package is sent to the concurrent number of target servers in accordance with the deployment order, so that the target servers deploy the application system.

[0011] Preferably, determining whether the target server is ready includes:

[0012] Sending a prepare message to the target server, the prepare message including at least a transaction tracking field and a security check field;

[0013] If a ready message fed back by the target server is received, determining that the target server is ready;

[0014] If the ready message fed back by the target server is not received, it is determined that the target server is not ready.

[0015] Preferably, generating the incremental package of the application system includes:

[0016] Obtaining a new deployment package and an old deployment package of the application system;

[0017] The new deployment package and the old deployment package are processed in a differential compression manner to generate an incremental package of the application system.

[0018] Preferably, it also includes:

[0019] If the target server is not ready, identifying an error type of the target server;

[0020] When the error type of the target server is a recoverable error, a recovery strategy is selected using a decision tree strategy, and the target server is repaired according to the recovery strategy;

[0021] When the error type of the target server is an unrecoverable error, a file-level rollback, a configuration-level rollback, and a system-level rollback are performed on the target server.

[0022] Preferably, before generating the incremental package of the application system, the method further includes:

[0023] Predict the resources required to deploy the application system to obtain resource demand information;

[0024] The resource requirement information is sent to the target server.

[0025] Preferably, after sending the fragmented incremental packets to the concurrent number of target servers, the method further includes:

[0026] Collecting operating indicators of the target server;

[0027] A comprehensive report is generated using the operational indicators, the comprehensive report including at least a deployment integrity index, a performance volatility coefficient, and a security compliance score.

[0028] Preferably, sending the fragmented incremental package to the concurrent number of target servers according to the deployment order includes:

[0029] According to the deployment order, the fragmented incremental package is sent to the concurrent number of target servers through cyclic redundancy check and acceleration protocol.

[0030] A second aspect of an embodiment of the present invention discloses a multi-server rapid deployment device, the device comprising:

[0031] A parsing unit, used to parse the configuration file to determine the target server and deployment order of the application system;

[0032] A generating unit, configured to generate an incremental package for the application system;

[0033] A processing unit, configured to fragment the incremental packet and calculate the concurrent quantity;

[0034] A judging unit, configured to judge whether the target server is ready;

[0035] The sending unit is used to send the fragmented incremental package to the concurrent number of target servers in accordance with the deployment order if the target server is ready, so that the target server deploys the application system.

[0036] A third aspect of an embodiment of the present invention discloses an electronic device, comprising: a processor and a memory, wherein the processor and the memory are connected via a communication bus; wherein the processor is used to call and execute a program stored in the memory; and the memory is used to store a program, wherein the program is used to implement the multi-server rapid deployment method disclosed in the first aspect of the embodiment of the present invention.

[0037] A fourth aspect of an embodiment of the present invention discloses a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program. When the computer program is executed by a processor, the multi-server rapid deployment method disclosed in the first aspect of the embodiment of the present invention is implemented.

[0038] Based on the above-mentioned embodiment of the present invention, a multi-server rapid deployment method, device, electronic device and storage medium are provided. The method comprises the following steps: parsing a configuration file to determine the target servers and deployment order on which the application system needs to be deployed; generating an incremental package for the application system; sharding the incremental package and calculating the concurrent number; determining whether the target server is ready; if the target server is ready, sending the sharded incremental package to the concurrent number of target servers in the deployment order, so that the target server deploys the application system. This solution determines the target servers and deployment order to be deployed through a configuration file, and shards the incremental package of the application system. The sharded incremental package is sent to multiple ready target servers in a concurrent manner, so that the target server deploys the application system, thereby reducing the server deployment time and improving deployment efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0040] Figure 1A flowchart of a multi-server rapid deployment method provided by an embodiment of the present invention;

[0041] Figure 2 An example diagram of the interaction between seed nodes and target nodes provided by an embodiment of the present invention;

[0042] Figure 3 Another flow chart of a multi-server rapid deployment method provided by an embodiment of the present invention;

[0043] Figure 4 This is a structural block diagram of a multi-server rapid deployment device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0044] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0045] In this application, the terms "comprises," "comprising," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not preclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0046] In cloud computing environments, big data clusters, and distributed applications, it is often necessary to deploy the same application system to dozens or even hundreds of servers simultaneously. The current technical bottlenecks faced by enterprise-level application deployment are as follows:

[0047] 1. Serial deployment efficiency issues: Traditional tools such as Ansible use a linear execution mode. When the number of servers to be deployed exceeds 50, the deployment time increases exponentially, making it difficult to cope with rapidly iterating application systems.

[0048] 2. Consistency assurance defects: Existing configuration management tools such as Puppet and Chef lack atomicity control during concurrent deployment, which may cause inconsistent deployment package versions obtained by different servers (with a high probability of version differences).

[0049] 3. Incomplete result collection: Most tools only capture the final status and lack detailed execution details for each stage. This ultimately leads to deployment failures and the inability to pinpoint the specific failure link.

[0050] 4. Protocol compatibility issues: Traditional deployment tools rely on specific agents and have a compatibility failure rate of 15%-20% in heterogeneous environments.

[0051] To this end, this solution proposes a multi-server rapid deployment method, device, electronic device, and storage medium. This method uses a configuration file to determine the target servers and deployment order, and then fragments the application system's incremental package. The fragmented incremental packages are sent concurrently to multiple ready target servers, enabling them to deploy the application system, reducing server deployment time and improving deployment efficiency.

[0052] This solution adopts a distributed architecture of "seed node control + target server execution" and achieves efficient communication between servers through standardized JSON data format.

[0053] The core innovations of this solution include: 1) an agentless deployment solution based on native tools such as SSH / SCP, eliminating environmental dependencies; 2) an intelligent deployment package distribution mechanism that supports incremental transmission and integrity verification; 3) multi-stage status monitoring and automatic rollback capabilities to ensure deployment atomicity; and 4) centralized result collection that can generate comprehensive reports including execution logs, performance indicators, and security checks.

[0054] In actual applications, this solution can shorten the deployment time of 100 servers from 4 hours in the traditional solution to less than 20 minutes, while ensuring 100% version consistency. It is particularly suitable for scenarios such as cloud computing and edge computing that require rapid deployment of large-scale server clusters. The following describes the specific content of this solution in detail through various examples.

[0055] See also Figure 1 , shows a flowchart of a multi-server rapid deployment method provided by an embodiment of the present invention, the method comprising:

[0056] Step S101: Parse the configuration file to determine the target server where the application system needs to be deployed and the deployment order.

[0057] In the specific implementation of step S101 , the configuration file is parsed to determine the target server (also called target node) where the application system needs to be deployed, and to determine the deployment order.

[0058] Specifically, the program deployment process is started, the parameters in the configuration file (json configuration file) are parsed, the deployment requirements of each server are analyzed through the parsed parameters, and whether the server can be deployed with the application system is checked, thereby determining the target server, which is the server on which the application system can be deployed.

[0059] The dependency relationships in the configuration files are parsed through graph algorithms, and the deployment order is determined based on the dependency relationships to maximize the satisfaction of the program's deployment requirements. The deployment order is the order in which the application system is deployed on each target server.

[0060] In some specific embodiments, resources required for deploying the application system are predicted to obtain resource demand information, where the resource demand information is: resources required for deploying the application system; and the resource demand information is sent to a target server.

[0061] Specifically, the LSTM model is trained based on historical data, and then the trained LSTM model is used to predict resource demand information.

[0062] The stage of determining the target server, deployment sequence, and resource requirement information is the deployment preparation stage, which is divided into three parts: "Starting the program", "Dependency analysis", and "Resource evaluation".

[0063] The target servers are determined in the "Starter" section, the deployment order is determined in the "Dependency Analysis" section, and resource requirement information is predicted in the "Resource Assessment" section.

[0064] Step S102: Generate an incremental package for the application system.

[0065] In the specific implementation of step S102 , a new deployment package and an old deployment package of the application system are obtained; the new deployment package and the old deployment package are processed in a differential compression manner to generate an incremental package of the application system.

[0066] Specifically, the bsdiff algorithm is used to generate the incremental package of the application system, and the incremental package Δ = the new deployment package Old deployment package.

[0067] Step S103: Segment the incremental packet and calculate the concurrent quantity.

[0068] In the specific implementation of step S103, the incremental packet is fragmented (40-byte header overhead) according to the formula "S=min(MTU-40,1446)", where S is the calculated fragment size and MTU is the maximum transmission unit (Maximum Transmission Unit). A cyclic redundancy check (CRC32) is used to verify the fragmented incremental packet.

[0069] In addition, the incremental packet can also be fragmented according to the MTU value, that is, , f(x) is the final size after fragmentation according to the MTU value, and size is the total size of the data to be transmitted (in bytes).

[0070] After the incremental packet is fragmented, in order to ensure the transmission of the fragments, the fragments are retransmitted through intelligent retransmission if there is an error in the transmission of the fragments.

[0071] To implement intelligent retransmission, the retransmission timeout must be dynamically calculated based on the RTT: RTO = SRTT + max(G, K × RTTVAR). Here, G = clock granularity, K = 4, RTT = round-trip time; SRTT = smoothed round-trip time (SRTT), a weighted average estimate of historical RTTs; and RTTVAR = round-trip time variation (RTTVAR), a measure of RTT fluctuation.

[0072] The concurrency number is calculated through a bandwidth adaptive algorithm. The concurrency number represents the maximum number of target servers to which the incremental packages of the application system can be distributed at one time.

[0073] In the implementation of the bandwidth adaptive algorithm, the initial concurrency number C_init = BDP / RTT, where BDP = bandwidth-delay product, and the dynamic adjustment ΔC = η × (1-loss_rate), where η = learning rate (0.1), ΔC is the dynamically adjusted concurrency number, and loss_rate is the packet loss rate.

[0074] When calculating the number of concurrent connections, you can use adaptive threading technology to calculate the optimal number of concurrent connections: Threads = min[bandwidth (Mbps) / δ, number of nodes / 5, 32], where δ is the packet size coefficient and the number of nodes is the number of target servers (i.e., target nodes).

[0075] The process of generating incremental packages, sharding the incremental packages, and calculating the number of concurrent requests is the intelligent distribution stage, which is further divided into two parts: "transmission optimization technology" and "concurrency control model".

[0076] The "Transmission Optimization Technology" section describes how to generate incremental packets and segment them, and the "Concurrency Control Model" section describes how to calculate the number of concurrent connections.

[0077] Step S104: Determine whether the target server is ready. If the target server is ready, execute step S105; if the target server is not ready, execute step S106.

[0078] In the specific implementation of step S104 , a prepare message (PREPARE message) is sent to the target server. The prepare message includes at least a transaction tracking field (tx_id) and a security check field (checksum). The security check field uses the SHA-256 algorithm.

[0079] For example: Send the prepare message "PREPARE(tx_id,checksum)" to the target server through the seed node (also known as the control center).

[0080] If a ready message (READY message) fed back by the target server is received, it is determined that the target server is ready, and step S105 is executed.

[0081] If no ready message is received from the target server, it is determined that the target server is not ready, and step S106 is executed.

[0082] For example, a seed node (also known as the control center) sends a "PREPARE(tx_id, checksum)" message to the target server. If the target server responds with a "READY(resources)" message, the target server is determined to be ready, and step S105 is executed. Conversely, if the target server does not respond with a "READY(resources)" message, the target server is determined to be unready.

[0083] Step S105: sending the fragmented incremental package to a concurrent number of target servers in a deployment order, so that the target servers deploy the application system.

[0084] In the specific implementation of step S105, if the target server is ready, the fragmented incremental package is sent to the calculated "concurrent number" of target servers through cyclic redundancy check (CRC32) and acceleration protocol (TCP acceleration protocol) in accordance with the deployment order, so that the target server deploys the application system.

[0085] Specifically, if the target server is ready, the seed node performs a COMMIT (non-blocking) operation to distribute the fragmented incremental package to each target server. The fragmented incremental package can be sent to a maximum of "concurrent number" target servers at one time, allowing the target server to deploy the application system.

[0086] It should be noted that after sending the sharded incremental package to the target server, after the target server completes the "application system deployment", the target server will execute the DONE (metrics) operation, reply the specified message (indicating that the deployment is complete) to the seed node, and at the same time return some log data during the execution process.

[0087] In some specific embodiments, after sending the fragmented incremental packages to a concurrent number of target servers, the operating indicators of the target servers are collected; and a comprehensive report is generated using the operating indicators, which includes at least a deployment integrity index, a performance fluctuation coefficient, and a security compliance score.

[0088] The deployment integrity index = number of successfully deployed nodes / total number of nodes*100, the performance fluctuation coefficient uses the t-test p-value, and the security compliance score uses the CIS benchmark compliance.

[0089] Step S106: Identify the error type of the target server.

[0090] In the specific implementation of step S106 , if the target server is not ready, the error type of the target server is identified.

[0091] It should be noted that this solution pre-classifies errors. Specifically, it defines seven types of recoverable errors and three types of fatal errors (irrecoverable errors) to locate the root cause of execution failures.

[0092] When the error type of the target server is a recoverable error, step S107 is executed; when the error type of the target server is an unrecoverable error, step S108 is executed.

[0093] Step S107: When the error type of the target server is a recoverable error, a recovery strategy is selected using a decision tree strategy, and the target server is repaired according to the recovery strategy.

[0094] In the specific implementation of step S107 , when the error type of the target server is a recoverable error, a decision tree strategy is adopted to select a recovery strategy, and the target server is repaired according to the recovery strategy.

[0095] It should be noted that if the target server exception cannot be automatically repaired according to the recovery policy, you can manually handle it and then execute the program deployment again.

[0096] Step S108: When the error type of the target server is an unrecoverable error, a file-level rollback, a configuration-level rollback, and a system-level rollback are performed on the target server.

[0097] It should be noted that this solution provides a fast rollback function, which is implemented by a three-level rollback system, namely file-level rollback, configuration-level rollback, and system-level rollback.

[0098] In the specific implementation of step S108 , when the error type of the target server is an unrecoverable error, a file-level rollback, a configuration-level rollback, and a system-level rollback are performed on the target server.

[0099] Among them, file-level rollback is completed in seconds through inode indexing, configuration-level rollback is implemented based on Git version control, and system-level rollback relies on LVM snapshots.

[0100] The above process of sending the prepare message "PREPARE(tx_id,checksum)" and receiving the ready message "READY(resources)" is the atomic execution phase, which is further divided into two parts: the "two-phase commit protocol" and the "exception handling mechanism".

[0101] In the "Two-Phase Commit Protocol" section, the seed node sends a "PREPARE(tx_id,checksum)" prepare message to the target server. The seed node receives the "READY(resources)" ready message from the target server. The seed node executes the COMMIT (non-blocking) operation, and the target server executes the DONE(metrics) operation.

[0102] In the "Exception Handling Mechanism" section, the error type of the target server is identified. When the error type of the target server is a recoverable error, the target server is automatically repaired according to the recovery strategy. When the error type of the target server is an unrecoverable error, the target server is rolled back at the file level, configuration level, and system level.

[0103] The above embodiments of the present invention Figure 1 The content of each step can be executed by the control center (seed node), and through the interaction between the seed node and the target node (corresponding to the target server), a multi-server deployment application system can be realized.

[0104] In this embodiment of the present invention, the target servers to be deployed and the deployment order are determined through a configuration file, and the application system's incremental package is fragmented. The fragmented incremental packages are then sent concurrently to multiple ready target servers, enabling the target servers to deploy the application system, reducing server deployment time and improving deployment efficiency.

[0105] In actual applications, this solution adopts a "center control-edge execution" distributed architecture for rapid deployment of multiple servers. This distributed architecture is a hierarchical system composed of three core components: the control center, the execution terminal, and the data interaction layer.

[0106] 1) Control center (seed node):

[0107] It mainly includes deployment strategy engine, intelligent scheduler and security certification center.

[0108] Among them, the deployment strategy engine: implements deployment process control based on the finite state machine (FSM) and contains 12 state transition nodes.

[0109] Intelligent scheduler: An improved genetic algorithm (GA) is used for task scheduling, and the fitness function is: f(x)=α·T_completion+β·R_bandwidth+γ·C_consistency.

[0110] Among them, α, β, and γ are weight coefficients, which are dynamically adjusted through reinforcement learning; T_completion is the task completion time, R_bandwidth is the bandwidth utilization, and C_consistency is the consistency (or stability).

[0111] The intelligent scheduler dynamically calculates the optimal number of concurrent threads through an adaptive thread pool: Threads = min[bandwidth (Mbps) / δ, number of nodes / 5, 32].

[0112] Security Authentication Center: Implements an identity authentication system based on the SPIFFE standard and supports X.509 certificate rotation.

[0113] 2) Execution terminal (target server group):

[0114] Multiple execution terminals are deployed on the target node, including lightweight agents and local sandbox environments. The lightweight agent includes a command executor, a file manager, and a status reporter.

[0115] Among them, lightweight agent: a microservice written in Rust (<2MB memory usage).

[0116] Command executor: supports multiple scripting language interpreters such as Bash / Python / PowerShell, and is used for script execution on target nodes.

[0117] File Manager: Supports breakpoint resuming, copying files from the seed node to the target server, and supports breakpoint resuming.

[0118] Status reporter: collects system metrics (collects 50+ system metrics per second and implements system call filtering through eBPF). During the deployment process, it collects the execution status of the target server and returns it to the control center to record the execution status of each task.

[0119] 3) Data interaction layer:

[0120] The communication protocol stack in the data interaction layer includes the application layer, transport layer and security layer. Figure 1 The configuration file parsed in step S101 is the JSON configuration file in the data interaction layer. The data interaction layer implements communication based on the JSON-RPC protocol and supports QUIC transport layer encryption.

[0121] Application layer: Use json format to maximize the flexibility of data transmission and storage.

[0122] Transport layer: QUIC protocol (UDP port 443).

[0123] Security layer: ChaCha20-Poly1305 encryption.

[0124] The message format specifications of the data interaction layer are as follows:

[0125] "{

[0126] "master":{

[0127] "name":"hci01",

[0128] "account":"root",

[0129] "password":"123456?",

[0130] "network":{

[0131] "ip":"192.168.10.1",

[0132] "bond":{

[0133] "bond0":[

[0134] "eno1",

[0135] "en02"

[0136] ],

[0137] "bond1":[

[0138] "enp15sf0",

[0139] "enp15sf1" ]

[0141] }

[0142] }

[0143] },

[0144] "salve":[

[0145] {

[0146] "name":"hci01",

[0147] "account":"root",

[0148] "password":"123456?",

[0149] "network":{

[0150] "ip":"192.168.10.1",

[0151] "bond":{

[0152] "bond0":[

[0153] "eno1",

[0154] "en02"

[0155] ],

[0156] "bond1":[

[0157] "enp15sf0",

[0158] "enp15sf1" ]

[0160] }

[0161] }

[0162] },

[0163] {

[0164] "name":"hci03",

[0165] "account":"root",

[0166] "password":"123456?",

[0167] "network":{

[0168] "ip":"192.168.10.1",

[0169] "bond":{

[0170] "bond0":[

[0171] "eno1",

[0172] "en02"

[0173] ],

[0174] "bond1":[

[0175] "enp15sf0",

[0176] "enp15sf1" ]

[0178] }

[0179] }

[0180] } ]

[0182] }".

[0183] The protocol extensions of the data interaction layer include: transaction tracking field tx_id, security verification field checksum, and phase status field phase (including precheck / deploy / verify states).

[0184] Based on the above hierarchical system, when deploying multiple servers, the interaction example of the seed node and the target node is as follows: Figure 2 shown.

[0185] The seed node sends PREPARE(tx_id, checksum) to the target node. If it receives READY(resources) from the target node, it determines that the target node is ready. The seed node performs a COMMIT (non-blocking) operation to distribute the sharded incremental package to the target node. The target node performs a DONE(metrics) operation, replies to the seed node with a specified message (indicating deployment completion) and returns some log data during the execution process.

[0186] To better understand the process of rapid deployment of multiple servers in this solution, Figure 3 Another flowchart of a multi-server rapid deployment method is shown, which is illustrated from an overall level. Figure 3 The steps include:

[0187] Step S301: Start the program and parse the configuration file.

[0188] Step S302: Dependency analysis to determine the deployment order.

[0189] Step S303: Resource estimation, predicting resource demand information based on the LSTM model.

[0190] Step S304: perform differential compression to generate an incremental package.

[0191] Step S305: Transmit in fragments and calculate the fragment size.

[0192] Step S306: Concurrency control, bandwidth adaptively adjusts the number of concurrent connections.

[0193] Step S307: Execute the PREPARE operation.

[0194] Step S308: Check if it is ready. If not, go to step S309; ​​if so, go to step S314.

[0195] Step S309: Error classification, identifying the error type.

[0196] Step S310: Is it a recoverable error? If so, go to step S311; if not, go to step S313.

[0197] Step S311: adopting a decision tree strategy for automatic repair.

[0198] Step S312: Determine whether the automatic repair is successful. If not, manually process and re-execute the program deployment; if so, re-execute the program deployment.

[0199] Step S313: Rapid rollback, starting the three-level rollback system.

[0200] Step S314: Execute a COMMIT operation in a non-blocking manner.

[0201] Step S315: Execute the DONE operation to collect monitoring information.

[0202] Step S316: The status reporter collects system indicators and returns them to the control center.

[0203] Step S317: Collect node indicators to generate a comprehensive report containing multiple quantitative indicators.

[0204] It should be noted that Figure 3 The execution principle of each step in the embodiment of the present invention can be found in the above embodiment of the present invention. Figure 1 The content in will not be repeated here.

[0205] As can be seen from the above examples, this solution aims to address the systemic technical challenges currently faced by enterprise-level IT infrastructure in the process of deploying multi-server applications. By building an intelligent, standardized, and highly reliable automated deployment device, it fundamentally improves the efficiency and quality of distributed system operation and maintenance. Specifically, the core objectives of this solution are reflected in the following dimensions:

[0206] Dimension 1: Breaking through the efficiency bottleneck of large-scale deployment:

[0207] Enterprises currently face the real challenge of exponential server growth. Traditional serial deployment methods increase deployment time nonlinearly for scenarios with more than 50 servers. This solution innovatively builds a three-level concurrency system (control layer, transport layer, and execution layer) to implement topology-aware scheduling of deployment tasks. It uses adaptive thread pool technology to dynamically calculate the optimal number of concurrent threads: threads = min[bandwidth (Mbps) / δ, number of nodes / 5, 32]. This significantly reduces deployment time for large-scale cluster nodes and significantly improves efficiency.

[0208] In particular, this solution uses the P2P fragmentation transmission protocol to fragment the incremental packet according to the MTU value, that is, , and uses CRC32 for verification, achieving a 98.7% transmission success rate in the test environment.

[0209] Dimension 2: Ensuring consistency in distributed environments:

[0210] In complex environments with mixed architectures (X86 / ARM) and multiple operating systems (RHEL / Ubuntu / CentOS, etc.), existing deployment tools are subject to the risk of version drift. This solution ensures consistency through: ① an atomic two-phase commit protocol (PREPARE-COMMIT-DONE process) and ② a real-time difference detection system (comparing node status every 5 seconds). This effectively addresses the consistency issue in distributed environments.

[0211] Dimension 3: Building a full-link observability system:

[0212] Existing deployment tools commonly suffer from the "deployment black box" problem, making it difficult to locate deployment failures. This solution's multi-dimensional monitoring includes: ① Fine-grained phase division (precheck / deploy / postcheck, etc.), ② Real-time metric collection of 10 indicators (CPU, memory, I / O, network, etc.), and ③ A distributed tracing system (based on the OpenTelemetry specification). Using "deployment electrocardiogram" technology, a time series database records millisecond-level state changes, enabling the identification of transient anomalies lasting as little as 200ms. The generated machine-readable report includes quantitative metrics such as the deployment completeness index (number of successful nodes / total number of nodes × 100), performance coefficient of variation (t-test p-value), and security compliance score (CIS benchmark compliance).

[0213] Dimension 4: Achieving seamless cross-platform compatibility:

[0214] Traditional deployment tools rely on specific runtime environments. This solution's breakthroughs lie in: ① a zero-agent architecture that relies solely on POSIX-standard tools like SSH / SCP; ② an adaptive execution engine (automatically identifying glibc versions, kernel features, etc.); and ③ a micro sandbox environment (500KB memory footprint, supporting eBPF system call filtering).

[0215] Dimension 5: Optimizing resource utilization efficiency:

[0216] Large-scale deployments often trigger resource storms. This solution's resource scheduling system features: ① intelligent throttling (dynamically adjusting resource quotas based on a PID controller), ② temperature-aware scheduling (preventing node overheating using the formula: T_optimal = 0.7 × T_threshold), and ③ network traffic shaping (using a token bucket algorithm to control bandwidth usage). This significantly improves resource utilization through peak-shifting execution and power capping.

[0217] Among them, T_optimal is the optimal operating temperature pursued by the scheduling system, which is lower than the threshold to reserve a safety margin; T_threshold is the temperature threshold of the node (hardware safety upper limit), which is defined by the chip or data center specifications.

[0218] Dimension 6: Promoting intelligent transformation of operations and maintenance:

[0219] Integrated AIops capabilities: ① Automatic generation of deployment plans (NLP parsing requirement documents), ② Root cause analysis of faults (based on Bayesian inference network), and ③ Parameter self-optimization system (reinforcement learning dynamic parameter adjustment).

[0220] The key technologies used in the implementation of this solution are state management system, performance optimization technology and intelligent sharding transmission technology.

[0221] 1) State management system:

[0222] Distributed state machine: Use the Raft protocol to ensure consistency.

[0223] Checkpoint mechanism: persist the state to LevelDB or local file every 30 seconds.

[0224] State synchronization: Based on gossip protocol propagation, convergence time <5s.

[0225] 2) Performance optimization technology:

[0226] Object pooling and zero copy are used for memory management. Object pooling reuses frequently created objects (connections, buffers, etc.). Zero copy uses the sendfile() system call to transfer files.

[0227] Batch processing and core binding are used for CPU optimization. Batch processing combines small I / O requests (threshold = 8KB). Core binding binds key threads to large cores (via cpuset).

[0228] 3) Intelligent fragmentation transmission technology:

[0229] Press the incremental package Fragmentation, through CRC32 checksum and TCP acceleration protocol, maximizes the transmission rate.

[0230] The reliability design of this solution is mainly achieved through fault tolerance mechanism and data consistency.

[0231] The specific content of the heartbeat detection in the fault tolerance mechanism is: bidirectional heartbeat (interval 2s, timeout 10s). When the incremental package is large and the deployment time is long, the fault tolerance mechanism is used to prevent the program from freezing.

[0232] The specific content of the verification mechanism in data consistency is: CRC32 per data block + overall SHA-256.

[0233] In general, this solution has the following beneficial effects:

[0234] Deployment efficiency is significantly improved: Through intelligent concurrency control and P2P sharding transmission technology, the deployment time of large-scale server clusters is shortened from the traditional several hours to tens of minutes, greatly improving efficiency and significantly reducing the waiting time for business online.

[0235] Version consistency assurance: An atomic commit mechanism is used to ensure 100% version consistency in a distributed environment, completely resolving common configuration drift and version inconsistency issues in traditional deployments.

[0236] Resource utilization optimization: The dynamic throttling algorithm effectively utilizes the average CPU load during deployment, improves utilization, reduces network bandwidth consumption, and prevents deployment operations from impacting production services.

[0237] Improved fault location efficiency: The full-link monitoring system can collect 10 indicators in real time, making fault location easier. When deployment problems occur, they can be quickly located and repaired.

[0238] Enhanced security protection: integrated quantum encryption channel and zero-trust architecture.

[0239] Cross-platform compatibility: The agentless architecture supports heterogeneous environments such as X86 / ARM, improving the first-time deployment success rate in mixed operating system clusters and significantly reducing environment adaptation costs.

[0240] Intelligent O&M support: Pre-deployment checks and analysis of historical deployment environment data identify issues early. Based on analysis of past deployment results, deployment recommendations are generated for the current deployment and automated remediation procedures are implemented, significantly reducing manual O&M costs.

[0241] This solution achieves significant technological breakthroughs across multiple dimensions. Its intelligent distributed architecture significantly improves the deployment efficiency of large-scale server clusters, effectively addressing the performance bottlenecks inherent in traditional serial deployment methods. Advanced version control mechanisms and atomic operations ensure high system deployment consistency in distributed environments, preventing common issues like configuration drift.

[0242] In terms of resource utilization, optimized transmission algorithms and dynamic scheduling strategies significantly reduce the deployment process's occupancy of system resources, achieving more efficient resource utilization. At the same time, the security protection system provides comprehensive security assurance for the deployment process, effectively preventing all potential security threats.

[0243] This solution's cross-platform compatibility enables it to adapt to a variety of complex heterogeneous environments, greatly enhancing its versatility and applicability. Its intelligent monitoring and prediction system provides strong support for operations and maintenance, significantly improving efficiency and reliability through automated analysis and early warning capabilities. These technical advantages combine to create an efficient, reliable, secure, and intelligent multi-server deployment solution.

[0244] Corresponding to the multi-server rapid deployment method provided by the above embodiment of the present invention, see Figure 4 The embodiment of the present invention also provides a structural block diagram of a multi-server rapid deployment device, which includes: a parsing unit 100, a generating unit 200, a processing unit 300, a judging unit 400, and a sending unit 500.

[0245] The parsing unit 100 is used to parse the configuration file to determine the target server and deployment order of the application system.

[0246] The generating unit 200 is used to generate an incremental package of the application system.

[0247] In a specific implementation, the generation unit 200 is specifically used to: obtain a new deployment package and an old deployment package of the application system; and process the new deployment package and the old deployment package using a differential compression method to generate an incremental package of the application system.

[0248] The processing unit 300 is used to segment the incremental packet and calculate the concurrent quantity.

[0249] The judging unit 400 is configured to judge whether the target server is ready.

[0250] In a specific implementation, the judgment unit 400 is specifically used to: send a prepare message to the target server, the prepare message including at least a transaction tracking field and a security check field; if a ready message is received from the target server, it is determined that the target server is ready; if no ready message is received from the target server, it is determined that the target server is not ready.

[0251] The sending unit 500 is used to send the fragmented incremental package to a concurrent number of target servers in a deployment order if the target server is ready, so that the target server deploys the application system.

[0252] In a specific implementation, the sending unit 500 is specifically used to: send the fragmented incremental packets to a concurrent number of target servers according to the deployment order through a cyclic redundancy check and an acceleration protocol.

[0253] In this embodiment of the present invention, the target servers to be deployed and the deployment order are determined through a configuration file, and the application system's incremental package is fragmented. The fragmented incremental packages are then sent concurrently to multiple ready target servers, enabling the target servers to deploy the application system, reducing server deployment time and improving deployment efficiency.

[0254] Preferably, combined Figure 4 The multi-server rapid deployment device further includes:

[0255] The identification unit is configured to identify an error type of the target server if the target server is not ready.

[0256] The repair unit is used to select a recovery strategy using a decision tree strategy when the error type of the target server is a recoverable error, and repair the target server according to the recovery strategy.

[0257] The rollback unit is used to perform file-level rollback, configuration-level rollback, and system-level rollback on the target server when the error type of the target server is an unrecoverable error.

[0258] Preferably, combined Figure 4 The multi-server rapid deployment device further includes:

[0259] The prediction unit is used to predict the resources required for deploying the application system to obtain resource demand information; and send the resource demand information to the target server.

[0260] Preferably, combined Figure 4 The multi-server rapid deployment device further includes:

[0261] The collection unit is used to collect the operating indicators of the target server.

[0262] A reporting unit is used to generate a comprehensive report using the operation indicators. The comprehensive report at least includes a deployment integrity index, a performance fluctuation coefficient, and a security compliance score.

[0263] Preferably, an embodiment of the present invention further provides an electronic device, comprising: a processor and a memory, the processor and the memory being connected via a communication bus; wherein the processor is used to call and execute a program stored in the memory; the memory is used to store a program, and the program is used to implement the multi-server rapid deployment method provided in the above method embodiment.

[0264] Preferably, an embodiment of the present invention further provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the multi-server rapid deployment method provided by the above method embodiment is implemented.

[0265] In summary, embodiments of the present invention provide a method, apparatus, electronic device, and storage medium for rapid multi-server deployment. These methods use a configuration file to determine the target servers to be deployed and the deployment order, and then fragment the incremental packages of an application system. These fragmented incremental packages are then sent concurrently to multiple ready target servers, enabling them to deploy the application system, reducing server deployment time and improving deployment efficiency.

[0266] Each embodiment in this specification is described in a progressive manner. The same or similar parts between the embodiments can be referred to each other. Each embodiment focuses on the differences from other embodiments. In particular, for system or system embodiments, since they are basically similar to method embodiments, the description is relatively simple. For relevant parts, refer to the partial description of the method embodiment. The system and system embodiments described above are merely schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment. A person of ordinary skill in the art can understand and implement it without expending creative work.

[0267] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present invention.

[0268] The above description of the disclosed embodiments is intended to enable one skilled in the art to implement or use the present invention. Various modifications to these embodiments will be readily apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the scope of the present invention. Therefore, the present invention is not limited to the embodiments shown herein, but is intended to conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A multi-server rapid deployment method, characterized in that: The method comprises: Parse the configuration file to determine the target server and deployment order for the application system; generating an incremental package for the application system; Slice the incremental package and calculate the concurrent quantity; Determining whether the target server is ready; If the target server is ready, the fragmented incremental package is sent to the concurrent number of target servers in accordance with the deployment order, so that the target servers deploy the application system.

2. The method according to claim 1, characterized in that Determining whether the target server is ready includes: Sending a prepare message to the target server, the prepare message including at least a transaction tracking field and a security check field; If a ready message fed back by the target server is received, determining that the target server is ready; If the ready message fed back by the target server is not received, it is determined that the target server is not ready.

3. The method according to claim 1, characterized in that Generating an incremental package for the application system includes: Obtaining a new deployment package and an old deployment package of the application system; The new deployment package and the old deployment package are processed in a differential compression manner to generate an incremental package of the application system.

4. The method according to any one of claims 1 to 3, characterized in that Also includes: If the target server is not ready, identifying an error type of the target server; When the error type of the target server is a recoverable error, a recovery strategy is selected using a decision tree strategy, and the target server is repaired according to the recovery strategy; When the error type of the target server is an unrecoverable error, a file-level rollback, a configuration-level rollback, and a system-level rollback are performed on the target server.

5. The method according to any one of claims 1 to 3, characterized in that: Before generating the incremental package of the application system, the following steps are also included: Predict the resources required to deploy the application system to obtain resource demand information; The resource requirement information is sent to the target server.

6. The method according to any one of claims 1 to 3, characterized in that: After sending the fragmented incremental package to the concurrent number of target servers, the method further includes: Collecting operating indicators of the target server; A comprehensive report is generated using the operational indicators, the comprehensive report including at least a deployment integrity index, a performance volatility coefficient, and a security compliance score.

7. The method according to claim 1, characterized in that Sending the fragmented incremental package to the concurrent number of target servers according to the deployment order includes: According to the deployment order, the fragmented incremental package is sent to the concurrent number of target servers through cyclic redundancy check and acceleration protocol.

8. A multi-server rapid deployment device, characterized in that: The device comprises: A parsing unit, used to parse the configuration file to determine the target server and deployment order of the application system; A generating unit, configured to generate an incremental package for the application system; A processing unit, configured to fragment the incremental packet and calculate the concurrent quantity; A judging unit, configured to judge whether the target server is ready; The sending unit is used to send the fragmented incremental package to the concurrent number of target servers in accordance with the deployment order if the target server is ready, so that the target server deploys the application system.

9. An electronic device, characterized in that: include: A processor and a memory, wherein the processor and the memory are connected via a communication bus; wherein the processor is configured to call and execute a program stored in the memory; The memory is used to store a program, and the program is used to implement the multi-server rapid deployment method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the multi-server rapid deployment method according to any one of claims 1 to 7 is implemented.

Images