Server cluster scheduling method and system

Abstract

The invention provides a server cluster scheduling method and system, and the method comprises the steps: respectively obtaining the network transmission delay of a detection server and each node server and the internal instruction processing delay of each node server, designing the delay, calculating a two-factor weight forward accumulation mechanism, and carrying out the calculation of the two-factor weight forward accumulation mechanism; comprehensive processing delay, such as network delay and instruction processing delay core factors, of each node server in the server cluster is dynamically detected and evaluated, and the information is taken as a core basis of scheduling decision, so that dynamic request distribution is realized, the cluster operation environment is dynamically adapted, and the scheduling efficiency is improved. Therefore, the problem of uniformly assigning calculation tasks or flow in static scheduling can be solved, and the method is more efficient.

Description

Technical Field

[0001] This invention relates to the field of server cluster scheduling technology, and more specifically, to a server cluster scheduling method and system. Background Technology

[0002] GB35114, "Technical Requirements for Information Security of Networked Public Security Video Surveillance Systems," is a national standard. This standard clarifies four requirements for information security systems connected to a network: interconnection structure, certificate and key requirements, basic functional requirements, and performance requirements. This allows video surveillance platform software to achieve secure video encoding and transmission based on this standard. Video surveillance platforms built under this standard often rely on a cluster of multiple backend servers for their core service capabilities, such as multiple media servers and signaling servers deployed in a distributed manner. These server clusters often need to process SIP signaling queries and media stream forwarding requests from a large number of front-end devices (such as encrypted cameras) in real time. Therefore, a practical load balancing scheduling system needs to be designed to prevent excessive load on a single server or single point of failure from disrupting the entire service.

[0003] However, load balancing and scheduling in such systems often employ simple round-robin, hash, or static weight-based strategies to design and implement internal load scheduling. While these methods are simple to implement, they cannot handle or adapt to dynamic changes in server clusters, especially in environments requiring real-time calculation of load, network latency, and query response delays.

[0004] This type of method has the following problems: Lack of overall assessment of complex processing links: A complete GB35114 query command (such as querying device status via the 35114SIP protocol) needs to go through multiple stages such as command parsing, security verification, and business processing inside the server. Traditional methods are difficult to quantify the "end-to-end" latency of the entire processing flow, resulting in quantitative analysis in a single dimension, which cannot determine the true computing efficiency of the system.

[0005] Therefore, in the current environment, there is an urgent need for a scheduling system that can intelligently and accurately assess the real-time status of the GB35114 system server and perform optimal scheduling accordingly, so as to improve the overall processing efficiency, reliability and response speed of the system. Summary of the Invention

[0006] This invention addresses the technical problems existing in the prior art by providing a server cluster scheduling method and system that can intelligently and comprehensively evaluate the total latency of each node server in the server cluster from two dimensions, thereby realizing the scheduling of the server cluster.

[0007] According to a first aspect of the present invention, a server cluster scheduling method is provided, comprising: The detection server generates a probe command packet, sends the probe command packet concurrently to each node server in the server cluster, and records the sending timestamp of the probe command packet; Each node server receives the probe command packet, records the arrival timestamp of the probe command packet, constructs a SIP query command based on the probe command packet, and records the completion timestamp of the construction of the SIP query command; Based on the SIP query command, business logic processing is performed on the node server. When the processing is completed, the processing end timestamp is recorded. The internal command processing delay of the node server is calculated based on the construction completion timestamp and the processing end timestamp. Each node server will return a response packet to the detection server, including the arrival timestamp and the internal instruction processing delay; The detection server calculates the network transmission delay based on the arrival timestamp in the response packet and the sending timestamp recorded locally, and calculates the total delay of each node server based on the network transmission delay and the internal instruction processing delay; When a real user request arrives, the detection server determines the optimal node server based on the total latency of each node server and distributes the real user request to the optimal node server.

[0008] Based on the above technical solution, the present invention can also be improved as follows.

[0009] Optionally, a SIP query command is constructed based on the probe command packet, and the timestamp of the completion of the construction of the SIP query command is recorded, including: After receiving the probe command packet, the node server calls the query command assembly tool to construct a SIP query command to query the status of the virtual or real front-end device. After the assembly is completed, the timestamp of the completion of the construction of the SIP query command is recorded.

[0010] Optionally, business logic processing is performed on the node server based on the SIP query command, and a processing end timestamp is recorded upon completion, including: The SIP query command is submitted to the SIP scheduling engine and the actual business processing flow on the node server for processing. After processing is completed, the result is recorded and returned with a timestamp as the processing end timestamp. Based on the construction completion timestamp and the processing end timestamp, calculate the internal instruction processing latency of the node server, including: D_process=T_process_end-T_process_start; Where T_process_end represents the processing end timestamp, T_process_start represents the construction completion timestamp, and D_process represents the internal instruction processing delay.

[0011] Optionally, calculating the internal instruction processing latency of the node server based on the construction completion timestamp and the processing end timestamp further includes: Obtain the internal instruction processing latency of the current probe and the internal instruction processing latency of the previous probes; The internal command processing latency of the current probe is dynamically updated based on the internal command processing latency of the current probe and the internal command processing latency of previous probes. ; Where D_process represents the internal instruction processing latency for the current probe. The weights for internal instruction processing latency are Avg_D_process_pre, which is the average of the internal instruction processing latency from the previous probes. This indicates the internal instruction processing delay for the current probe after dynamic updates.

[0012] Optionally, each node server returns a response packet to the detection server, including the arrival timestamp and internal instruction processing delay, and further includes: The detection server presets a minimum computational response time for each node server and distributes the minimum computational response time to each node server. Each node server determines whether the internal instruction processing delay is greater than the minimum calculation response time. If so, the node server does not actively reply to the probe response, but only encapsulates the arrival timestamp into a response packet and returns it to the detection server. When the detection server receives the response packet, it determines that the corresponding node server is lost and will not participate in subsequent task processing.

[0013] Optionally, the detection server calculates the network transmission delay based on the arrival timestamp in the response packet and the sending timestamp recorded locally, including: D_network=T_arrive-T_end; Where T_arrive represents the arrival timestamp of the probe command packet, T_end represents the sending timestamp of the probe command packet, and D_network represents the network transmission delay; Based on the network transmission latency and the internal instruction processing latency, calculate the total latency of each node server, including: D_total=D_network+D_process; Where D_total represents the total latency, and D_process represents the internal instruction processing latency.

[0014] Optionally, based on the network transmission delay and the internal instruction processing delay, the total delay of each node server is calculated, and then the process further includes: The virtual factor weight is calculated for each node server based on the total latency D_total of each node server, using the following formula: ; in, Let be the virtual factor weight of the i-th node server. Let K be the total latency of the i-th node server, and K be a preset normalization constant. The detection server maintains a weight table locally, which stores the parameter information of each node server, including the virtual factor weight of the node server and the IP identifier of the node server.

[0015] Optionally, when a real user request arrives, the detection server determines the optimal node server based on the total latency of each node server and distributes the real user request to the optimal node server, including: When a real user request arrives, the detection server determines the optimal node server based on the virtual factor weight of each node server using a probability selection algorithm, and intelligently distributes the real user request to the optimal node server. The detection server determines the optimal node server based on the virtual factor weight of each node server using a probabilistic selection algorithm, including: ; Where P(i) is the probability that the i-th node server is selected. Let be the virtual factor weight of the i-th node server. This represents the sum of the virtual factor weights of all node servers; The node server with the highest probability of being selected is determined as the optimal node server.

[0016] Optionally, the virtual factor weight of each node server in the weight table is periodically reduced by a preset ratio, and the reduced virtual factor weight of each node server is: ; in, The weights are the virtual factor weights after weight reduction. Decay_factor represents the decay factor, where 0 < Decay_factor < 1.

[0017] According to a second aspect of the present invention, a server cluster scheduling system is provided, comprising a detection server and a server cluster, wherein the server cluster comprises multiple node servers, the detection server comprises a parameter construction engine, a load calculator, a network latency calculator, a starting point calculator and a scheduling decision unit, and each of the node servers comprises a load detection engine, a SIP query instruction assembly module and a SIP scheduling engine. The parameter construction engine is used to generate probe command packets and send the probe command packets concurrently to each node server in the server cluster. The starting point calculator is used to inject a sending timestamp into the probe command packet; Each node server receives the probe command packet, records the arrival timestamp of the probe command packet, and triggers the load detection engine; The load detection engine is used to construct a SIP query instruction based on the detection instruction packet, record the construction completion timestamp of the SIP query instruction, and hand over the constructed SIP query instruction to the internal SIP scheduling engine for business logic processing, and record the processing end timestamp when the processing is completed. Each node server calculates its internal instruction processing delay based on the construction completion timestamp and the processing end timestamp, and returns a response packet including the arrival timestamp and the internal instruction processing delay to the detection server. The network latency calculator is used to calculate the network transmission latency based on the arrival timestamp in the response packet and the sending timestamp recorded locally. The load calculator is used to calculate the total latency of each node server based on the network transmission latency and the internal instruction processing latency. The scheduling decision unit is used to determine the optimal node server based on the total latency of each node server when a real user request arrives, and to distribute the real user request to the optimal node server.

[0018] This invention provides a server cluster scheduling method and system that acquires the network transmission latency between the detection server and each node server, as well as the internal instruction processing latency of each node server. It designs a latency and calculation dual-factor weight positive accumulation mechanism to dynamically detect and evaluate the comprehensive processing latency of each node server in the server cluster, such as network latency and instruction processing latency core factors. This information is used as the core basis for scheduling decisions, thereby realizing dynamic request distribution and dynamically adapting to the cluster operating environment. This can solve the problem of static scheduling uniformly distributing computing tasks or traffic, and is more efficient. Attached Figure Description

[0019] Figure 1A flowchart of a cluster server scheduling method provided in one embodiment of the present invention; Figure 2 This is a schematic diagram illustrating the detection of server construction probe instruction packets in a cluster server scheduling method according to an embodiment of the present invention; Figure 3 This is a schematic diagram illustrating the interaction between the detection server and each node server in the cluster in a cluster server scheduling method provided in an embodiment of the present invention. Figure 4 This is a structural block diagram of a cluster server scheduling system provided in one embodiment of the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. In addition, the technical features of the various embodiments or individual embodiments provided by the present invention can be arbitrarily combined with each other to form feasible technical solutions. Such combinations are not constrained by the order of steps and / or structural composition patterns, but must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed by the present invention.

[0021] To address the shortcomings of existing server cluster scheduling methods, this invention provides a server cluster scheduling method. Figure 1 A flowchart of a server cluster scheduling method is shown, which includes the following steps: Step 1: The detection server generates a probe command packet, sends the probe command packet concurrently to each node server in the server cluster, and records the sending timestamp of the probe command packet.

[0022] Understandably, the detection server periodically and concurrently sends constructed probe commands to each node server in the cluster (such as node servers A, B, and C) to calculate the network and hardware load of each node server.

[0023] For details, see Figure 2The detection server's "parameter construction engine" generates detection command packets based on the detection task parameters. Before sending these packets to each node server in the server cluster, the "starting point calculator" injects a precise sending timestamp T_send (initial parameter) into each packet. This is equivalent to leaving an initial marker when the calculation factor is initiated; this initial marker is used as a reference point for subsequent calculations of the entire cluster. After the detection command packets are constructed, the detection server sends them to each node server in the cluster and records the sending time. If a node server does not respond in time, it can be considered that the node server is lost and unavailable.

[0024] Step 2: Each node server receives the probe command packet, records the arrival timestamp of the probe command packet, constructs a SIP query command based on the probe command packet, and records the completion timestamp of the construction of the SIP query command.

[0025] Understandably, upon receiving a probe command packet, each node server in the cluster immediately records the arrival timestamp T_arrive for subsequent comparison. By subtracting the sending timestamp from the arrival timestamp, the network transmission latency can be obtained. The node server can either record the arrival timestamp T_arrive of the probe command packet in its response packet and immediately return it to the detection server to report the latency, or return it along with the previously processed data to save communication efficiency.

[0026] In addition, after receiving the probe command packet, the node server's "load probe engine" will simulate real business and call the "35114 SIP query command assembly" module to construct a secure SIP query command that conforms to the GB35114 standard to query the status of virtual or real front-end devices. This SIP query command is used to probe computing efficiency. After the SIP query command is assembled, the timestamp T_process_start (computation factor) of the SIP query command construction completion is recorded.

[0027] During the SIP query command construction phase, the load probing engine calls the 35114 SIP query command assembly module to construct a Query method SIP request conforming to the GB35114 standard. The target of the command can be a fixed virtual device ID or a loopback device registered by itself, and the timestamp T_process_start of the SIP query command construction completion is recorded.

[0028] Step 3: Perform business logic processing on the node server based on the SIP query command. Record the processing end timestamp when the processing is completed. Calculate the internal command processing delay of the node server based on the construction completion timestamp and the processing end timestamp.

[0029] Understandably, this SIP command is submitted to the "SIP scheduling engine" inside the node server and processed by subsequent actual business processes (such as querying the database or actual devices). If the node server is currently handling high concurrency, the task queue of the SIP scheduling engine will accumulate. The waiting time of this command in the queue is one of the important indicators for measuring load.

[0030] After the SIP instruction is processed, the result is recorded and a timestamp T_process_end is returned, which is the timestamp (calculation factor) of the SIP instruction processing completion. The node server calculates the internal instruction processing latency D_process = T_process_end - T_process_start. This latency comprehensively reflects the current state of the node server, such as CPU computing power, memory usage, and I / O load.

[0031] Specifically, the node server dynamically calculates the internal instruction processing latency D_process by averaging multiple probes of D_process. Specifically, it obtains the internal instruction processing latency of the current probe and the internal instruction processing latencies of previous probes; and dynamically updates the internal instruction processing latency of the current probe based on these two latencies. ; Where D_process represents the internal instruction processing latency for the current probe. The weights for internal instruction processing latency are Avg_D_process_pre, which is the average of the internal instruction processing latency from the previous probes. This indicates the internal instruction processing delay for the current probe after dynamic updates.

[0032] Step 4: Each node server returns a response packet to the detection server, including the arrival timestamp and internal instruction processing delay.

[0033] Understandably, each node server records the arrival timestamp T_arrive of the probe command packet and calculates its internal command processing latency D_process. This arrival timestamp T_arrive and the calculated internal command processing latency D_process are encapsulated in a response packet and returned to the detection server as one of the reference parameters for subsequent node server selection. Furthermore, each node server has a preset minimum computation response time, which can be sent and synchronized to all node servers by the detection server. If the internal command processing latency of a node server exceeds the minimum computation response time, the node server can choose not to respond to the probe. In this case, the probe server will only receive the arrival timestamp T_arrive from the probe command packet, indicating that the node server's computation is fully loaded. The detection server will then consider the node server lost. This solves the problem of some node servers being unable to report computation latency after being fully loaded or even crashing.

[0034] Step 5: The detection server calculates the network transmission delay based on the arrival timestamp in the response packet and the sending timestamp recorded locally, and calculates the total delay of each node server based on the network transmission delay and the internal instruction processing delay.

[0035] Understandably, after receiving the response packet from each node server, the detection server extracts the arrival timestamp T_arrive from the response packet. The detection server's "network latency calculator" calculates the one-way network transmission latency D_network by comparing T_send and T_arrive, and records the single-trip latency time between the node server and the detection server as a network latency factor, which is used as one of the reference parameters for subsequent server selection.

[0036] The server's "load calculator" combines the two data points to obtain the total end-to-end latency of this probe: D_total = D_network + D_process.

[0037] The D_total value is a measure of the "quality" of the exploration path (from the detection server to the target server and complete the processing) for this factor calculation. Subsequently, a weighted calculation is performed according to the two factors, and the reciprocal of D_total (or a function negatively correlated with it) is used to update the "virtual weight factor weight" pointing to the node server. The shorter the total latency, the more the weight factor is enhanced, and the more likely the node server is to be scheduled.

[0038] The detection server maintains a weight table locally, which stores the parameter information of each node server, including the virtual factor weight and IP identifier of the node server. The virtual factor weight of each node server is dynamically updated at a fixed period. When a real request arrives, the node server with the higher weight can be selected for execution with a certain probability.

[0039] The virtual factor weight of each node server is calculated as follows: Each time the network transmission delay D_network (ms) and the server's internal processing delay D_process (ms) are detected, the total delay D_total of each node server is calculated as D_network + D_process (ms). The virtual factor weight W of each node server is then calculated based on the total delay. i =K / D_total i Where K is a normalization constant (e.g., 1000ms), mapping millisecond-level latency to a reasonable weight range (e.g., W=100 when D_total=10ms). The calculated virtual factor weight W... i The values ​​are associated with the node server information and stored, and the virtual factor weights of all node servers are sorted to organize the scheduling sequence.

[0040] Step 6: When a real user request arrives, the detection server determines the optimal node server based on the total latency of each node server and distributes the real user request to the optimal node server.

[0041] Understandably, periodic probing of each node server in the cluster results in faster-responding node servers receiving higher weight factors. Higher weights ensure that the detection server always has a real-time dispatch table, so that the detection service can quickly provide a processing path when a real request needs to be processed.

[0042] When a real business request (not a probe request) arrives at the detection server and needs to be scheduled, the "decision scheduling unit" no longer uses traditional polling. Instead, it makes a probabilistic selection based on the current weight factor weight of each node server (and possible heuristic information, such as the server's static weight). The higher the weight factor weight of a server, the greater the probability of it being selected.

[0043] It should be noted that, in order to prevent the algorithm from converging prematurely to a suboptimal solution (i.e., a certain node server monopolizes traffic due to short-term good performance), the system will periodically "reduce the weight" of the virtual factor of all node servers by a certain percentage to ensure continuous exploration of other possibilities.

[0044] Specifically, to prevent the virtual factor weights of node servers from growing indefinitely and to maintain the dynamic fluidity of the weight table, the virtual factor weights of all node servers in the weight table are globally and periodically decayed. (See also...) Figure 3 .

[0045] in, , The decayed virtual factor weight is Decay_factor, which is the decay factor. Decay_factor = 0.95~0.99 (per cycle), and the cycle = 30 seconds~60 seconds (matching the detection cycle).

[0046] When a real user request arrives, the detection server determines the optimal node server based on the virtual factor weight of each node server using a probability selection algorithm, and intelligently distributes the real user request to the optimal node server. The detection server determines the optimal node server based on the virtual factor weight of each node server using a probabilistic selection algorithm, including: Calculate the probability that the current node server is selected based on its virtual factor weight W_i and the virtual factor weights of other node servers in the server cluster: ; Where P(i) is the probability that the i-th node server is selected. Let be the virtual factor weight of the i-th node server. This represents the sum of the virtual factor weights of all node servers; The node server with the highest probability of being selected is determined as the optimal node server.

[0047] For each node server in the cluster, manual parameter configuration and expansion are supported. Some node servers with computation priority can be configured with an initial network latency factor to achieve virtual scheduling, so that some node servers can be assigned more computing tasks until the node servers no longer report computing factors and reach computation saturation.

[0048] For node servers with high network throughput requirements, the initial computation factor can be configured to manually change the computation weight, allocating fewer computation tasks until the node server stops reporting network latency factors, thus achieving network throughput saturation.

[0049] See Figure 4A server cluster scheduling system is provided, which includes a detection server and a server cluster. The server cluster includes multiple node servers. The detection server includes a parameter construction engine, a load calculator, a network latency calculator, a starting point calculator, and a scheduling decision unit. Each node server includes a load detection engine, an SPI query instruction assembly module, and an SPI scheduling engine. The parameter construction engine is used to generate probe command packets and send the probe command packets concurrently to each node server in the server cluster. The starting point calculator is used to inject a sending timestamp into the probe command packet; Each node server receives the probe command packet, records the arrival timestamp of the probe command packet, and triggers the load detection engine; The load detection engine is used to construct a real SPI query instruction according to the detection instruction packet, record the construction completion timestamp of the real SPI query instruction, and hand over the constructed real SPI query instruction to the internal SPI scheduling engine for business logic processing, and record the processing end timestamp when the processing is completed. Each node server calculates its internal instruction processing delay based on the construction completion timestamp and the processing end timestamp, and returns a response packet including the arrival timestamp and the internal instruction processing delay to the detection server. The network latency calculator is used to calculate the network transmission latency based on the arrival timestamp in the response packet and the sending timestamp recorded locally. The load calculator is used to calculate the total latency of each node server based on the network transmission latency and the internal instruction processing latency. The scheduling decision unit is used to determine the optimal node server based on the total latency of each node server when a real user request arrives, and to distribute the real user request to the optimal node server.

[0050] The detection server's parameter construction engine generates a probe command packet. After the starting point calculator injects a sending timestamp (T_send) into the probe command packet, the detection server concurrently sends the probe command packet to each server in the cluster (such as node servers A, B, and C).

[0051] After receiving the probe command packet, each node server in the cluster records the arrival timestamp (T_arrive) of the probe command packet, which completes the first step of network transmission delay calculation.

[0052] When the probe command packet reaches the node server, the load probing engine of each node server is triggered. It instructs the 35114 SIP query command assembly module to construct the SIP query command and records the construction completion time (T_process_start) of the SIP query command. The SIP query command is handed over to the internal SIP scheduling engine and subsequent business logic processing (simulating access to front-end cameras and other devices). After the SIP query command is processed, the processing end timestamp (T_process_end) is recorded. The node server calculates the internal command processing latency D_process based on the construction completion time (T_process_start) and processing end timestamp (T_process_end) of the SIP query command.

[0053] The node server returns a response packet to the detection server, containing the arrival timestamp T_arrive of the probe command packet and the internal command processing latency D_process. The detection server's network latency calculator calculates the network transmission latency D_network based on T_send and T_arrive. The load calculator combines the network transmission latency D_network and the internal command processing latency D_process to obtain the total latency D_total between each node server and the detection server in meo. The core of the algorithm uses the total latency D_total to update the virtual factor weight of the corresponding node server (the strength of the "weight factor" on the path changes dynamically in the graph).

[0054] When a real user request arrives, the decision scheduling unit of the detection server intelligently distributes the request to the optimal node server based on the current virtual factor weight of each node server through a probability selection algorithm, thereby completing the load balancing scheduling of the cluster.

[0055] Here, we assume there are n available servers in the current cluster, and the current weight factor of each server is W. i Then the probability that server i is selected is:

[0056] Where P(i) is the probability that the i-th node server is selected, and W i Let be the virtual factor weight of the i-th node server. This represents the sum of the virtual factor weights of all node servers.

[0057] Based on the virtual factor weight of each node server, the probability of each node server being selected is calculated. The node server with the highest probability of being selected is determined as the optimal node server, and user requests are distributed to the optimal node server.

[0058] This invention provides a server cluster scheduling method and system, which, compared with the prior art, has the following advantages: (1) Dynamic adjustment based on cluster: By actively injecting timestamps (weight factors) and simulating real business, the network status and comprehensive processing capabilities of each machine in the server cluster can be measured in real time and accurately, avoiding the problem that traditional static load balancing cannot dynamically calculate the cluster status as the business system changes.

[0059] (2) High scheduling decision efficiency: By introducing a weighted positive accumulation mechanism of latency and computation dual factors and a probability selection mechanism, the scheduling system has self-learning and adaptive capabilities. The system can automatically discover and prioritize the use of the server with the best current overall status (lowest latency), which significantly reduces the overall request response time.

[0060] (3) Improved system robustness: When the performance of a server decreases or the network fluctuates, its weight factor will decrease relatively due to the increase in latency, and the probability of being selected will decrease accordingly, thereby realizing automatic avoidance of faults or performance degradation, and improving the stability and efficiency of the entire GB35114 service cluster.

[0061] (4) High resource utilization: This method realizes dynamic monitoring of load, avoids the unbalanced situation of some servers being overloaded while others are idle, and improves the resource utilization efficiency and throughput of the entire server cluster.

[0062] (5) Seamless integration with GB35114 standard: The probe command completely simulates GB35114 standard SIP signaling, and the service processing flow also conforms to the standard specifications, so that this method can be naturally embedded into the existing GB35114 system architecture without large-scale modification.

[0063] (6) It has the ability to manually configure parameters: manual parameters can be configured according to business needs or network routing modifications. For example, if the network environment or computing power of a server is upgraded, the network factor can be adjusted to increase the server's throughput, or the computing factor can be reduced to increase the computing power, thus realizing an asymmetric scheduling structure. The adjustment of factor weights can take effect immediately.

[0064] It should be noted that the descriptions of each embodiment in the above embodiments have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0065] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0066] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0067] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0068] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0069] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0070] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A server cluster scheduling method, characterized in that, include: The detection server generates a probe command packet and sends the probe command packet concurrently to each node server in the server cluster, and records the sending timestamp of the probe command packet; Each node server receives the probe command packet, records the arrival timestamp of the probe command packet, constructs a SIP query command based on the probe command packet, and records the completion timestamp of the construction of the SIP query command; Based on the SIP query command, business logic processing is performed on the node server. When the processing is completed, the processing end timestamp is recorded. The internal command processing delay of the node server is calculated based on the construction completion timestamp and the processing end timestamp. Each node server will return a response packet to the detection server, including the arrival timestamp and the internal instruction processing delay; The detection server calculates the network transmission delay based on the arrival timestamp in the response packet and the sending timestamp recorded locally, and calculates the total delay of each node server based on the network transmission delay and the internal instruction processing delay; When a real user request arrives, the detection server determines the optimal node server based on the total latency of each node server and distributes the real user request to the optimal node server.

2. The server cluster scheduling method according to claim 1, characterized in that, Construct a SIP query command based on the probe command packet, and record the timestamp of the completion of the construction of the SIP query command, including: After receiving the probe command packet, the node server calls the query command assembly module to construct a SIP query command to query the status of the virtual device or the real front-end device. After the assembly is completed, the timestamp of the completion of the construction of the SIP query command is recorded.

3. The server cluster scheduling method according to claim 2, characterized in that, Based on the SIP query command, business logic processing is performed on the node server. Upon completion of processing, a processing end timestamp is recorded, including: The SIP query command is submitted to the SIP scheduling engine and the actual business processing flow on the node server for processing. After processing is completed, the result is recorded and returned with a timestamp as the processing end timestamp. Based on the construction completion timestamp and the processing end timestamp, calculate the internal instruction processing latency of the node server, including: D_process=T_process_end-T_process_start; Where T_process_end represents the processing end timestamp, T_process_start represents the construction completion timestamp, and D_process represents the internal instruction processing delay.

4. The server cluster scheduling method according to claim 3, characterized in that, Based on the construction completion timestamp and the processing end timestamp, the internal instruction processing latency of the node server is calculated, and the calculation also includes: Obtain the internal instruction processing latency of the current probe and the internal instruction processing latency of the previous probes; The internal command processing latency of the current probe is dynamically updated based on the internal command processing latency of the current probe and the internal command processing latency of previous probes. ； Where D_process represents the internal instruction processing latency for the current probe. The weights for internal instruction processing latency are Avg_D_process_pre, which is the average of the internal instruction processing latency from the previous probes. This indicates the internal instruction processing delay for the current probe after dynamic updates.

5. The server cluster scheduling method according to claim 1, characterized in that, Each node server returns a response packet to the detection server, including the arrival timestamp and internal instruction processing delay, and also includes: The detection server presets a minimum computational response time for each node server and distributes the minimum computational response time to each node server. Each node server determines whether the internal instruction processing delay is greater than the minimum calculation response time. If so, the node server does not actively reply to the probe response, but only encapsulates the arrival timestamp into a response packet and returns it to the detection server. When the detection server receives the response packet, it determines that the corresponding node server is lost and will not participate in subsequent task processing.

6. The server cluster scheduling method according to claim 1, characterized in that, The detection server calculates the network transmission delay based on the arrival timestamp in the response packet and the sending timestamp recorded locally, including: D_network=T_arrive-T_end; Where T_arrive represents the arrival timestamp of the probe command packet, T_end represents the sending timestamp of the probe command packet, and D_network represents the network transmission delay; Based on the network transmission latency and the internal instruction processing latency, calculate the total latency of each node server, including: D_total=D_network+D_process; Where D_total represents the total latency, and D_process represents the internal instruction processing latency.

7. The server cluster scheduling method according to claim 1, characterized in that, Based on the network transmission delay and the internal instruction processing delay, the total delay of each node server is calculated, followed by: The virtual factor weight is calculated for each node server based on the total latency D_total of each node server, using the following formula: ； in, Let be the virtual factor weight of the i-th node server. Let K be the total latency of the i-th node server, and K be a preset normalization constant. The detection server maintains a weight table locally, which stores the parameter information of each node server, including the virtual factor weight of the node server and the IP identifier of the node server.

8. The server cluster scheduling method according to claim 7, characterized in that, When a real user request arrives, the detection server determines the optimal node server based on the total latency of each node server and distributes the real user request to the optimal node server, including: When a real user request arrives, the detection server determines the optimal node server based on the virtual factor weight of each node server using a probability selection algorithm, and intelligently distributes the real user request to the optimal node server. The detection server determines the optimal node server based on the virtual factor weight of each node server using a probabilistic selection algorithm, including: Based on the virtual factor weight of the current node server Calculate the probability of the current node server being selected by considering the virtual factor weights of other node servers in the server cluster: ； Where P(i) is the probability that the i-th node server is selected. Let be the virtual factor weight of the i-th node server. This represents the sum of the virtual factor weights of all node servers; The node server with the highest probability of being selected is determined as the optimal node server.

9. The cluster server scheduling method according to claim 7, characterized in that, Also includes: The virtual factor weight of each node server in the weight table is periodically reduced by a preset ratio. The reduced virtual factor weight of each node server is as follows: ； in, The weights are the virtual factor weights after weight reduction. Decay_factor represents the decay factor, where 0 < Decay_factor < 1.

10. A server cluster scheduling system, characterized in that, It includes a detection server and a server cluster. The server cluster includes multiple node servers. The detection server includes a parameter construction engine, a load calculator, a network latency calculator, a starting point calculator, and a scheduling decision unit. Each node server includes a load detection engine, a SIP query command assembly module, and a SIP scheduling engine. The parameter construction engine is used to generate probe command packets and send the probe command packets concurrently to each node server in the server cluster. The starting point calculator is used to inject a sending timestamp into the probe command packet; Each node server receives the probe command packet, records the arrival timestamp of the probe command packet, and triggers the load detection engine; The load detection engine is used to construct a SIP query instruction based on the detection instruction packet, record the construction completion timestamp of the SIP query instruction, and hand over the constructed SIP query instruction to the internal SIP scheduling engine for business logic processing, and record the processing end timestamp when the processing is completed. Each node server calculates its internal instruction processing delay based on the construction completion timestamp and the processing end timestamp, and returns a response packet including the arrival timestamp and the internal instruction processing delay to the detection server. The network latency calculator is used to calculate the network transmission latency based on the arrival timestamp in the response packet and the sending timestamp recorded locally. The load calculator is used to calculate the total latency of each node server based on the network transmission latency and the internal instruction processing latency. The scheduling decision unit is used to determine the optimal node server based on the total latency of each node server when a real user request arrives, and to distribute the real user request to the optimal node server.

Images