CN115344440A

CN115344440A - Running state detection method and device for server

Info

Publication number: CN115344440A
Application number: CN202110528716.9A
Authority: CN
Inventors: 程宝传; 翟健翔; 钟国城; 蔡少芝
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2021-05-14
Filing date: 2021-05-14
Publication date: 2022-11-15

Abstract

The application discloses a method and a device for detecting the running state of a server, wherein the method can be applied to equipment with a forwarding function (called as first equipment), and the first equipment can be a switch, a router, a load balancer and the like. The first device may forward a message from the client to a target server in the server cluster according to the load balancing policy, and after forwarding the message, the first device detects an operating state of the target server according to a receiving condition of the message from the target server. Compared with the prior art that the detection equipment needs to periodically send the detection message to the servers in the server cluster to detect the running state of the servers, the method in the application is beneficial to reducing the network resources occupied by the process of detecting the running state of the servers.

Description

Method and device for detecting running state of server

Technical Field

The present application relates to the field of communications, and in particular, to a method and an apparatus for detecting an operating state of a server.

Background

In order to improve the concurrent processing capacity of the service, a load balancing system is generally used to process a request message of a client accessing the service. The load balancing system generally comprises a plurality of servers, and the plurality of servers provide services for the client in a load balancing mode. When the operation state of a server among the plurality of servers is abnormal, the server may not be able to continue providing the service. In order to ensure the reliability of the service, the operating state of each server needs to be detected to find the server with an abnormal operating state, and then maintain the server, or forward a request packet accessing the service to other servers in the load balancing system.

Currently, a detection device is generally used to detect the operating status of each server in a load balancing system. The detection device sends detection messages to the servers, judges whether response messages of the servers to the detection messages are received or not, and then determines the running state of the corresponding server according to the judgment result so as to find the server with abnormal running state.

The load balancing system usually includes a large number of servers, and the detection device detects the operation status of each server to generate a large number of detection messages and response messages, which not only affect other services of the load balancing system, but also occupy a large amount of network resources.

Disclosure of Invention

The application provides a method for detecting the running state of a server, which is used for reducing network resources occupied by the running state detection process.

The application provides a method for detecting the running state of a server in a first aspect. The method can be applied to a first device, the first device can be used for forwarding messages interacted between a client and a server, and the first device can be used for detecting the operation state of the server. Specifically, the first device may receive a first packet from the client. After receiving the first packet, the first device may forward the first packet to the target server. In one possible implementation, the first packet may access a first service, and the target server is configured to provide the first service. After the first device forwards the first packet, the operating state of the target server may be detected according to a receiving condition of a packet (for convenience of description, the packet is referred to as a second packet) meeting a certain specific condition. In one possible implementation, the second message is a message from the target server. If the operation state of the target server is normal, the target server may receive and process the first message and send a second message to the client, and accordingly, the first device may receive the second message from the target server within a certain time length (referred to as a preset time length). If the operation state of the target server is abnormal, the first device may not receive the second message from the target server within the preset time. Therefore, in a possible implementation manner, the first device may determine whether the second message from the target server is received within a preset time period, and based on that the first device does not receive the second message within the preset time period, the first device may determine that the operating state of the target server is abnormal.

It can be seen that, in the method provided in the first aspect of the present application, the first device may detect the operation state of the target server without additionally generating and sending a detection message to the target server in the process of forwarding the packet between the client and the target server, which is beneficial to reducing network resources occupied by the operation state detection process. If a certain server cluster in the load balancing system is used for providing the first service accessed by the first message, the target server is a server in the server cluster and can provide the first service in a load balancing manner. In the process of forwarding the message between the client and the server cluster, the first device may detect the operating states of the servers in the server cluster without generating and sending a detection message to the servers in the server cluster, which is beneficial to reducing network resources occupied in the operating state detection process and influence on other services of the load balancing system.

In one possible implementation, the first device may be a physical entity in the network or a device (e.g., a chip or a functional module) in the physical entity, which may be, for example, a router or a switch or a firewall or a load balancer, etc. in the network. Alternatively, in one possible implementation, the first device may be a virtual device (e.g., a virtual machine or a container) running in a physical entity, for example, the virtual device may be a virtual router or a virtual switch or a virtual load balancer or a forwarding device, etc.

In one possible implementation, the client and the target server may be a client and a server under a C (client)/S (server) architecture, respectively, for example, the client may be a client installed with an application program, and the client may be a computer, a mobile terminal, an entertainment device, or the like, for example. Alternatively, the client and the target server may be a client and a server in a B (browser)/S architecture, respectively, for example, the client may be a server providing various services for the user equipment, such as a software-defined networking (SDN) server, a world wide web (web) server, a File Transfer Protocol (FTP) server, an enterprise key application server and other key task servers (e.g., a server providing a firewall service), a Service Processing Unit (SPU) in a Communication Technology (CT) field, and the like.

In the process of forwarding the message between the client and the target server, the first device can detect the running state of the target server without additionally generating and sending a detection message to the target server, which is favorable for reducing network resources occupied in the running state detection process. If the target server is a server in a server cluster in the load balancing system, the first device may detect the operating state of the server in the server cluster without additionally generating and sending a detection message to each server in the server cluster in the process of forwarding the message between the client and the server cluster, which is beneficial to reducing the occupation of network resources and the influence on other services of the load balancing system in the operation state detection process.

Since the running state detection performed by the first device is triggered by the message of the access service, for the un-accessed server in the server cluster, the first device may not detect the running state thereof, which is beneficial to reducing the running state detection times performed by the first device, thereby being beneficial to reducing the occupation of the running state detection on a Central Processing Unit (CPU) of the first device.

Since the first device detects the operating state of the target server by identifying the source network address of the second packet, the method provided in the first aspect is not affected by the Protocol used for transmitting the first packet, and can be applied to an application scenario in which a Transmission Control Protocol (TCP) or a User Datagram Protocol (UDP) or other protocols are used for transmitting packets, and it is not necessary to perform deep packet detection on the first packet or the second packet, which is beneficial to reducing the influence of the operating state detection process on the forwarding performance of the first device.

In a possible implementation manner, the first device may record a time length after forwarding the first message, and determine whether to receive the second message when the recorded time length reaches or exceeds a preset time length.

Because the time consumed by the first device from receiving the first message to forwarding the first message is generally much shorter than the preset time, in a possible implementation manner, the first device may record the time after receiving the first message, and determine whether to receive the second message when the recorded time reaches or exceeds the preset time.

In a possible implementation manner, although the target server cannot process the first packet forwarded by the first device, the target server may process other packets besides the first packet forwarded by the first device, and accordingly, the first device may receive a processing result packet of the other packets sent by the target server. Therefore, in order to detect the operation state of the target server corresponding to the first service and improve the detection accuracy of the operation state of the target server, in a possible implementation manner, the second message may be a processing result message of the target server for the first service. In a possible implementation manner, the second packet may be a processing result packet of the target server on the first packet. In one possible implementation, the destination network address of the second packet may be the source network address of the first packet. The first device may identify the second packet by reading a five-tuple of the received packet.

In one possible implementation, the first device may locally maintain flow record information (or session record information), where the flow record information includes records corresponding to one or more network flows (or data flows), and a record corresponding to one network flow includes a matching rule for identifying a packet in the network flow and a forwarding rule for forwarding the packet in the network flow. After receiving the first packet, the first device may search for a record corresponding to the first packet in the stream record information. In a possible implementation manner, the first packet does not satisfy the matching rule in all records in the flow record information, and the first device may determine that the first packet is the first packet of a new network flow (referred to as a first network flow).

In a possible implementation manner, after receiving the first packet, the first device may generate a matching rule, where the matching rule is used to identify the second packet. For example, the first device may determine a second five-tuple from the network address of the destination server and a five-tuple of the first packet (referred to as a first five-tuple), and then generate the matching rule from the second five-tuple. The source network address of the second quintuple is the network address of the destination server, the destination network address of the second quintuple is the source network address in the first message, and the protocol of the second quintuple is the protocol (such as TCP or UDP) adopted by the first message. The matching rule may be a hash value of the second five tuple. After the first device generates the matching rule, the matching result of the matching rule may be recorded. The first device may record the matching result as the first information after generating the matching rule. Then, the first device may determine whether the received packet satisfies the matching rule. Based on that the received message does not satisfy the matching rule, the first device does not operate the matching result, or records the matching result as the first information again. Based on the received message satisfying the matching rule, the first device may record the matching result as the second information. The second information is different from the first information, and the first device can determine whether the second message is received or not by checking the matching result, so that whether the second message is received within a preset time length or not can be judged.

In a possible implementation manner, after the first device determines that the second message is received within the preset time period or the second message is not received, it may not be necessary to continue to record the matching result.

In a possible implementation manner, the matching rule and the matching result may be stored in the first device in the form of a table (e.g., a session table), and the table may further include other information, for example, statistical information of the second packet received by the first device (e.g., the number of the second packets).

In a possible implementation manner, the first device may start recording a duration (e.g., start a timer) after generating the matching rule, and based on that the recording duration reaches or exceeds the preset duration, and based on that the matching result is the first information, the first device may determine that the second message is not received within the preset duration. In a possible implementation manner, based on that the recording duration reaches or exceeds the preset duration, and based on that the matching result is the first information, the first device may determine that the second message is received within the preset duration.

Because the time length consumed by the first device to receive the first message and to forward the first message is generally much shorter than the preset time length, the application does not limit the first device to start recording the time length after generating the matching rule, and in a possible implementation manner, the first device only needs to start recording the time length within a shorter time length before and after forwarding the first message, where the shorter time length is relative to the preset time length, for example, the first device may start recording the time length after generating a session table for the first message, or start recording the time length after receiving the first message, or start recording the time length after forwarding the first message, and the like.

In one possible implementation manner, the preset duration is determined according to a preset response duration of the first service. In one possible implementation, the response duration of the first service may be configured for the tenant of the first service.

In one possible implementation, the preset duration is equal to a response duration of the first service. Or, in a possible implementation manner, the starting time of the response duration of the first service corresponds to the time when the client sends the request packet of the first service, the ending time of the response duration of the first service corresponds to the time when the client receives the processing result packet of the request packet, and accordingly, the preset duration is smaller than the response duration of the first service. In a possible implementation manner, if the first device can receive the processing result message of the first message within a preset time period, the client can receive the processing result message of the first message within a response time period of the first service after the first message is sent. If the first device determines a preset time length according to the response time length of the first service and executes the method to detect the operation state of the server in the server cluster, the first device forwards the request message of the first service to the server with a normal operation state, so that the first device receives the processing result message of the request message within the preset time length, and the client receives the processing result message within the response time length of the first service, thereby being beneficial to improving the user experience of the first service.

In a possible implementation manner, the target server is a server in a server cluster in the load balancing system, the server cluster includes n servers, n is a positive integer greater than 1, and the server in the server cluster is configured to provide a first service accessed by the first packet in the load balancing manner.

In a possible implementation manner, after receiving the first packet, the first device may obtain server information corresponding to the first service. The server information of the first service records the identification of the server with normal operation state in the server cluster. Assume that server information acquired after the first device receives the first message records identifiers of m servers, where the m servers are servers in a server cluster, the identifiers of the m servers include an identifier of a target server, and m is a positive integer smaller than or equal to n. In a possible implementation manner, the first device may select an identifier of the target server from the identifiers of the m servers, and then forward the first packet to the target server according to the identifier of the target server. In one possible implementation, the identification of the server is the name or number of the server or a network address (e.g., an IP address and port number).

In a possible implementation manner, after determining that the operating state of the target server is abnormal, the first device may modify server information corresponding to the first service, where the modified server information does not include the identifier of the target server. In this way, when the first device receives the packet requesting the first service, the first device may not continuously forward the packet to the target server, which is beneficial to improving the reliability of the first service.

In a possible implementation manner, if the first device does not receive the second message within a preset time period, the first device may directly determine that the operation state of the target server is abnormal.

Or, in a possible implementation manner, in order to further improve the accuracy of the detection result, if the first device does not receive the second message within the preset time period, the first device may execute other steps to further determine whether the target server is abnormal. For example, in a possible implementation manner, based on that the first device does not receive the second packet within a preset time period, the first device may send a first message to the target server, where the first message is used to detect an operating state of the target server. In one possible implementation, the first message instructs the target server to send a response message to the first device. After that, the first device may further determine whether the operation state of the target server is normal or abnormal according to the reception condition of the response message. The first message and the response message may be sent in the form of a message, and therefore, it may also be considered that the first device sends a detection message to the target server, where the detection message instructs the target server to send the response message to the first device.

Compared with the prior art that detection messages are periodically sent to all servers in the server cluster, the detection messages are sent to the screened servers with longer response time, and therefore the calculation resources and the network resources of the first device are saved.

In a possible implementation manner, if the first device determines that the operation state of the target server is abnormal, the first device may send a second message to the second device, where the second message is used to notify the second device that the operation state of the target server is abnormal. In a possible implementation manner, the second device may be a detection device, and after receiving the second message, the detection device may notify a maintenance person to check and maintain the target server, or may refer to a detection scheme in the prior art, send a detection message to the target server, and determine whether a response message of the target server to the detection message is received, and then determine the operation state of the target server according to a determination result. For example, if the first device receives a response message of the target server, the first device may determine that the operating state of the target server is normal, and if the first device does not receive the response message of the target server, the first device may determine that the operating state of the target server is abnormal. In a possible implementation manner, after determining whether the target server is abnormal, the second device may send the determination result to the first device.

Alternatively, in one possible implementation, the second device may be a forwarding device or a load balancing device other than the first device. After receiving the second message, the second device may not forward the packet accessing the first service to the target server, thereby being beneficial to ensuring the reliability of the first service.

In a second aspect, the present application provides an operation status detection apparatus for a server, where the operation status detection apparatus for the server may be the first device mentioned in the first aspect, or an apparatus in the first device, or an apparatus capable of being used in cooperation with the first device. In one design, the apparatus for detecting an operating state of the server may include a module corresponding to the execution of the method/operation/step/action described in any one of the first aspect or any one of the possible implementations of the first aspect, where the module may be a hardware circuit, a module existing in a software form, or a module implemented by a combination of a hardware circuit and a software.

In a possible implementation manner, the device for detecting the operating state of the server includes a communication module and a processing module, wherein the communication module is configured to receive a first packet from a client and further configured to forward the first packet to a target server after receiving the first packet, and the processing module is configured to determine that the operating state of the target server is abnormal based on that the communication module does not receive a second packet from the target server within a preset time period.

In a possible implementation manner, the destination network address of the second packet is the source network address of the first packet.

In a possible implementation manner, the first packet is a first packet in a first network flow received by the first device.

In a possible implementation manner, the processing module is further configured to generate a matching rule after the communication module receives the first packet, and record a matching result of the matching rule, where the matching rule is used to identify the second packet, and the matching result is recorded as first information based on that the first device does not receive a packet that satisfies the matching rule, and the matching result is recorded as second information based on that the first device receives a packet that satisfies the matching rule.

In a possible implementation manner, the processing module is further configured to determine, based on that a recording duration reaches or exceeds the preset duration and based on that the matching result is the first information, that the first device does not receive the second packet within the preset duration, where the recording duration is a duration recorded by the first device after the matching rule is generated.

In a possible implementation manner, the preset duration is determined according to a response duration of the service requested by the first packet.

In a possible implementation manner, the first packet requests a first service, the target server is determined by the first device from n servers corresponding to the first service, and n is a positive integer greater than 1.

In a possible implementation manner, the communication module is configured to forward the first packet to the target server according to server information corresponding to the first service, where the server information includes identifiers of m servers, the n servers include the m servers, the identifiers of the m servers include the identifier of the target server, and m is a positive integer smaller than or equal to n. The processing module is further configured to modify the server information after determining that the operating state of the target server is abnormal, where the modified server information does not include the identifier of the target server.

In a possible implementation manner, the communication module is further configured to send a first message to the target server after the processing module determines that the operation state of the target server is abnormal, where the first message is used to detect the operation state of the target server.

In a possible implementation manner, the communication module is further configured to send a second message to the second device after the processing module determines that the operation state of the target server is abnormal, where the second message is used to notify the second device that the operation state of the target server is abnormal.

For the beneficial effects of this aspect, please refer to the related descriptions of the first aspect, which will not be described herein again.

In a third aspect, the present application provides an apparatus for detecting an operating status of a server, where the apparatus for detecting an operating status of a server includes a processor and a memory, where the processor is coupled to the memory, and the memory is used to store program codes, and when the processor executes the program codes stored in the memory, the processor can perform the method described in the first aspect or any one of the possible implementations of the first aspect.

In a possible implementation, the instructions are stored in a memory external to the operating state detection means of the server. When these instructions are decoded and executed by the processor of the operation state detection device of the server, a part or all of the contents of the instructions are temporarily stored in the memory inside the operation state detection device of the server. Optionally, a part of the content of the instructions is stored in a memory outside the operation state detection device of the server, and the other part of the content of the instructions is stored in a memory inside the operation state detection device of the server.

In a possible implementation manner, the apparatus for detecting an operating state of the server may further include a communication interface, and the processor may be capable of receiving the first message, or forwarding the first message to the target server, or sending the second message to the second device, or sending the first message to the target server, for example.

A fourth aspect of the present application provides a chip system, which includes a processor and an interface circuit, the processor being coupled to a memory through the interface circuit, and the processor being configured to execute program code in the memory to perform the method described in the first aspect or any one of the possible implementation manners of the first aspect. The chip system may be formed by a chip, and may also include a chip and other discrete devices.

A fifth aspect of the present application provides a computer-readable storage medium having program code stored therein, which when run on a computer device, causes the computer device to perform a method as described herein for enabling the first aspect or any one of the possible implementations of the first aspect.

A sixth aspect of the present application provides a computer program product comprising program code that, when executed by a computer device, performs the method as described herein when being capable of performing the first aspect or any one of its possible implementations.

Since each device provided in the present application can be used to execute the corresponding method, the technical effects obtained by each device in the present application can refer to the technical effects obtained by the corresponding method, and are not described herein again.

Drawings

FIG. 1 illustrates one possible application scenario of an embodiment of the present application;

FIG. 2A illustrates another possible application scenario of an embodiment of the present application;

FIG. 2B illustrates one deployment of the application scenario of FIG. 2A;

FIG. 3 shows a possible flow of a method according to an embodiment of the present application;

fig. 4 to fig. 6 respectively show another possible flow of the method according to the embodiment of the present application;

FIG. 7 shows one possible configuration of an apparatus according to an embodiment of the present application;

fig. 8 shows another possible structure of the device of the embodiment of the present application.

Detailed Description

First, an application scenario applicable to the embodiment of the present application is described by way of example.

Fig. 1 shows a possible application scenario of the embodiment of the present application. Referring to fig. 1, one possible application scenario of the embodiment of the present application includes a client 11, a first device 12, and a server 13.

The client 11 and the server 13 may be a client and a server under a C (client)/S (server) architecture, respectively, for example, the client 11 may be a client installed with an application program, and the client may be a computer, a mobile terminal, an entertainment device, or the like. Alternatively, the client 11 and the server 13 may be a client and a server under a B (browser)/S architecture, respectively, for example, the client 11 may be a server providing various services for the user equipment, such as a software-defined networking (SDN) server, a world wide web (web) server, a File Transfer Protocol (FTP) server, an enterprise critical application server and other critical task servers (e.g., a server providing a firewall service), a Service Processing Unit (SPU) in a communication (communication technology, CT) field, and the like.

In one possible implementation, the first device 12 may be a physical entity in the network or a device (e.g., a chip or a functional module) in the physical entity, which may be, for example, a router or a switch or a firewall or a load balancer, etc. in the network. Alternatively, in one possible implementation, the first device 12 may be a virtual device (e.g., a virtual machine or a container) running in a physical entity, for example, a virtual router or a virtual switch or a virtual load balancer or a virtual forwarding device, etc.

With continued reference to fig. 1, a communication connection is established between the client 11 and the first device 12, a communication connection is established between the first device 12 and the server 13, and the client 11 and the server 13 can interact or communicate through the first device 12. Exemplarily, referring to fig. 1, the client 11 may send a request for accessing a certain service (referred to as a first service), which may be sent to the first device 12 in the form of a message, and therefore, the request may also be referred to as a request message or a message. Illustratively, the request may be a Transmission Control Protocol (TCP) request or a User Datagram Protocol (UDP) request or other Protocol type request. The request may carry access data for the first service or may carry control information for controlling the transmission of the access data, e.g. the control information may request that a transmission link for the access data is established.

The first device 12 may receive the request and forward the request to a target server for providing the first service. In one possible implementation, the first device 12 may maintain a correspondence of the first service with a server for providing the first service. In one possible implementation, the first service may be identified by a destination network address in the request message, or by a name of the first service. The server 13 may receive and process the request and may then send the results of the processing of the request. The processing result may also be sent to the first device 12 in the form of a message, and thus, the processing result may also be referred to as a processing result message or a message. The first device 12 may receive the processing result and forward the processing result to the client 11.

Fig. 1 only exemplarily presents one possible application scenario of the present application, and in one possible implementation manner, the application scenario to which the embodiment of the present application is applicable may include more devices. For example, on the basis of the device shown in fig. 1, the first device 12 may also establish a communication connection with a client other than the client 11. For example, the client 11 and the server 13 interact or communicate via the first device 12 and one or more network devices other than the first device 12. For example, the first device 12 may also establish a communication connection with a server other than the server 13.

Fig. 2A shows another possible application scenario of the embodiment of the present application. Referring to fig. 2A, another possible application scenario of the embodiment of the present application includes a client 21, a first device 22, and a server cluster 23, where the server cluster 23 includes n servers, and n is a positive integer. For convenience of description, the n servers are respectively referred to as server 1, … …, server i, … … and server n, where i is any positive integer less than or equal to n. The server cluster 23 corresponds to a load balancing system, and the servers in the server cluster 23 are used for providing one or more services in a load balancing manner. For convenience of description, one of the services will be referred to as a first service.

The client 21 and the first device 22 shown in fig. 2A may be understood with reference to the client 11 and the first device 12 shown in fig. 1, respectively, and the server in the server cluster 23 shown in fig. 2A may be understood with reference to the server 13 shown in fig. 1, which is not described herein again.

With continued reference to fig. 2A, a communication connection is established between the client 21 and the first device 22, a communication connection is established between the first device 22 and the server cluster 23, and the client 21 and the servers in the server cluster 23 can interact or communicate through the first device 22. For example, referring to fig. 2A, the client 21 may send a request for accessing the first service, and the request may be sent to the first device 22 in the form of a message, and therefore, the request may also be referred to as a request message or a message. The request may carry access data for the first service or may carry control information for controlling the transmission of the access data, e.g. the control information may request that a transmission link for the access data is established.

In one possible implementation, the first device 22 may maintain a correspondence of the first service with a server (i.e., a server in the server cluster 23) for providing the first service. In one possible implementation, the first service may be identified by a destination network address in the request message, or by a name of the first service. The first device 22 may receive the request and forward the request to server i in the server cluster 23, e.g. according to a load balancing policy. The load balancing strategy comprises a load balancing algorithm, and the load balancing algorithm comprises but is not limited to a polling method, a random method, a source address hashing method, a weighted polling method, a weighted random method or a minimum concatenation method. The server i may receive and process the request, and may then transmit the result of the processing of the request. The processing result may also be sent to the first device 22 in the form of a message, and thus, the processing result may also be referred to as a processing result message or a message. The first device 22 may receive the processing result and forward the processing result to the client 21.

Fig. 2A is only used to exemplarily describe an application scenario to which the present application is applied, and in a possible implementation manner, the application scenario to which the embodiment of the present application is applied may include more or fewer devices. For example, on the basis of the device shown in fig. 2A, the first device 22 may also establish a communication connection with a client other than the client 21. For example, the client 21 and the server cluster 23 may interact or communicate through the first device 22 and one or more network devices other than the first device 22. For example, the first device 22 may also establish a communication connection with a server or server cluster other than the server cluster 23. For example, although fig. 2A shows n servers, the application scenario of the embodiment of the present application does not limit the number of servers in the server cluster 23, and the server cluster 23 may include 1 server or 2 servers or more than 2 servers.

In one possible implementation, the first device 22 may be a Load Balancer (LB) or a Service Load Balancer (SLB). In a possible implementation, the first device 22 may be applied in a data center hardware architecture, and optionally, the first device 22 is deployed in a top of rack (TOR) switch. Alternatively, in a possible implementation manner, the first device 22 may be applied to a container network scenario, and optionally, the first device 22 may be deployed in a virtual switch (vSwitch) in a compute node server. Alternatively, in a possible implementation, the first device 22 may be applied in a centralized scenario, and optionally, the first device 22 may be deployed in a hardware firewall. Or, in a possible implementation manner, the first device 22 may be applied to a public cloud scenario, and optionally, the first device 22 may be deployed in an SLB server.

A schematic diagram of the application scenario of fig. 2A deployed in the form of a distributed load balancing system is introduced below with reference to fig. 2B. Referring to fig. 2B, servers 1 to n shown in fig. 2A are virtual servers and are respectively deployed in nodes 1 to m, where m is a positive integer, and j in fig. 2B is a positive integer smaller than or equal to m. The first device 22 shown in fig. 2A is a virtual device operating in the node 1. Each of the nodes 1 to m may correspond to one physical server, for example. In one possible implementation, servers 1 to n each run on a Virtual Machine (VM) or in a container of the corresponding node. In a possible implementation manner, the client 21 may also be a virtual device deployed in a certain node, for example, the client 21 may be deployed in the same node as the first device 22, or deployed in the same node as the server in the server cluster 23, or deployed in a single node, that is, not deployed in the same node as the first device 22 and the server in the server cluster 23.

Fig. 2B is only an example, and the number of the virtual servers deployed by each node is not limited in the embodiment of the present application, and in a possible implementation manner, one node may deploy one or two or more virtual servers. In the embodiment of the present application, it is not limited that the first device 22 and the server in the server cluster 23 are deployed in the same node, and in a possible implementation manner, the first device 22 is deployed in the node m + 1.

In one possible implementation, the distributed load balancing system shown in fig. 2B may also include more or fewer devices. For example, in one possible implementation, a device having the same function as the first device 22 may be deployed in the node j. For example, in one possible implementation, the distributed load balancing system shown in fig. 2B may further include a control plane (control plane), which may be used to manage the topology of the distributed load balancing system.

In the application scenario shown in fig. 1, the server 13 is used for providing the first service, that is, the server 13 can provide the first service in a normal operating state, and if the operating state of the server 13 is abnormal, the server 13 may not be able to provide the first service. Similarly, in the application scenario shown in fig. 2A, the server cluster 23 is used to provide the first service, where a server in a normal operating state in the server cluster 23 can provide the first service, and a server in an abnormal operating state in the server cluster 23 may not provide the first service.

In order to ensure the reliability of the first service, it is necessary to detect the operating status of the server 13 or the servers in the server cluster 23 to maintain the servers with abnormal operating statuses, or the load balancing policy adopted by the first device may also be based on the operating status of the servers in the server cluster 23, for example, the first device forwards the request for accessing the first service to the servers with normal operating statuses in the server cluster 23 to ensure the reliability of the first service.

The operation state of the server is generally detected by a detection device (for example, the detection device 14 shown in fig. 1, the detection device 24 shown in fig. 2A, or the detection devices 1 to m shown in fig. 2B). The detection device periodically sends detection messages to each server, judges whether response messages of each server to the detection messages are received or not, and then determines the running state of the corresponding server according to the judgment result so as to find the server with abnormal running state. The detection device may send the detected operating state to the first device (not shown in fig. 2A and fig. 2B), and the first device may update the load balancing policy according to the received operating state of the server, and only forward the packet to the server in the normal operating state, which is beneficial to ensuring reliability of the service accessed by the client.

For example, referring to fig. 1, the detection device 14 transmits a detection message to the server 13, determines whether a response message to the detection message from the server 13 is received, determines the operation state of the server 13 according to the determination result, and may then transmit the detection result to the first device 12. The detection device 14 periodically sends detection messages to the server 13, and there is a waste of network resources.

Similarly, referring to fig. 2A, the detection device 24 sends a detection message to each server in the server cluster 23, detects a response condition of each server in the server cluster 23 to the detection message, determines an operation state of each server in the server cluster 23 according to the detection result, and then may send the detection result to the first device 22 (not shown in fig. 2A). The server cluster 23 usually includes a large number of servers, and the periodic operation status detection of the detection device 24 will generate a large number of detection messages, which will not only waste a large amount of network resources, but also affect other services of the load balancing system.

Similarly, referring to fig. 2B, the detection devices 1 to m send detection messages to the servers deployed at the corresponding nodes in the server cluster 23, detect response conditions of the corresponding servers to the detection messages, determine operating states of the corresponding servers according to the detection results, and then send the detection results to the first device 22 (not shown in fig. 2B) through, for example, a control platform. Similar to the foregoing analysis content of the defects in the prior art in the application scenario of fig. 1 or fig. 2A, the periodic sending of the detection messages by the detection devices 1 to m wastes a lot of network resources. In addition, in the application scenario corresponding to fig. 2B, the detection device 1 can only detect whether the server deployed on the node 1 is abnormal, and cannot detect whether the server across nodes (for example, the server i) is abnormal, and the detection devices deployed in the nodes 2 to m forward the detection result to the first device through other devices (for example, the aforementioned control plane), which is poor in timeliness.

In order to reduce network resources occupied by a running state detection process, embodiments of the present application provide a method and an apparatus for detecting a running state of a server. The method provided by the embodiments of the present application will be described first.

Fig. 3 shows a possible flow of the method according to the embodiment of the present application. Referring to fig. 3, a method according to an embodiment of the present application may include the following steps 301 to 303.

Step 301, a first device receives a first message from a client;

the first device may receive a first message from a client. In a possible implementation manner, after the client sends the first packet, the first packet directly reaches the first device without passing through other devices. Or, in a possible implementation manner, after the client sends the first packet, the first packet is forwarded to the first device by one or more network devices (the network devices are, for example, routers or switches or firewalls) other than the first device.

In one possible implementation, the client may be, for example, the client 11 shown in fig. 1, or the client 21 shown in fig. 2A or fig. 2B. The understanding of the client may refer to the related description of the client 11 in fig. 1 or the related description of the client 21 in fig. 2A or fig. 2B, and will not be described herein again.

In one possible implementation, the first device may be, for example, the first device 12 shown in fig. 1, or the first device 22 shown in fig. 2A or fig. 2B. The first device may be understood by referring to the description related to the first device 12 in fig. 1 or the description related to the first device 22 in fig. 2A or fig. 2B, and the description thereof is omitted here.

In a possible implementation manner, the first message may be one of the requests (or request messages) for accessing the first service shown in fig. 1 or fig. 2A.

Step 302, the first device forwards a first message to a target server;

after receiving the first packet, the first device may forward the first packet to the target server. In one possible implementation, the target server may be the server 13 shown in fig. 1, or the target server may be the server i in the server cluster 23 shown in fig. 2A or fig. 2B.

In a possible implementation manner, the first packet forwarded by the first device may directly reach the target server. Alternatively, in a possible implementation manner, the forwarded first packet may be forwarded to the destination server via one or more network devices (such as a router or a switch, or a firewall, etc.) other than the first device.

In one possible implementation, the first device may locally maintain flow record information (or session record information), where the flow record information includes records corresponding to one or more network flows (or data flows), and a record corresponding to one network flow includes a matching rule for identifying a packet in the network flow and a forwarding rule for forwarding the packet in the network flow. In one possible implementation, the forwarding rule may include information of a next hop network node. In a possible implementation, the record may further include statistical information of the network flow, such as the number of messages in the network flow.

Generally, messages having the same attribute and passing through an observation point in a certain time period belong to a network flow, and in a possible implementation manner, a matching rule of the messages in the network flow is determined according to the same attribute. Illustratively, the same attributes that define a network flow generally include one or more of the following: source IP address, destination IP address, source port number, network layer protocol class, IP service type and router/switch interface number. Among them, the source IP address, source port number, destination IP address, destination port number, and transport layer protocol are generally referred to as a five-tuple, which is most often used as the same attribute that defines a network flow. The embodiment of the present application does not limit the same attribute used for defining the network flow, and for convenience of description, the quintuple is taken as the same attribute for defining the network flow.

The stream record information may be stored in the first device in the form of a table or an array, etc. In the following, the embodiment of the present application is described by taking an example that the flow record information is stored in the first device in the form of a table, and accordingly, the flow record information is referred to as a flow table, and a record corresponding to one network flow is referred to as a flow table entry.

After receiving the first packet, the first device may search a flow table entry corresponding to the first packet in the flow table. In a possible implementation manner, the first packet does not satisfy the matching rule of all flow entries in the flow table, and the first device may determine that the first packet is a first packet of one network flow (referred to as a first network flow). In a possible implementation manner, if the first packet is a first packet of the first network flow, the first device may insert a new flow entry into the flow table, where a matching rule in the flow entry is used to identify a subsequent packet of the first network flow, and a forwarding rule in the flow entry is used to forward the subsequent packet of the first network flow. In a possible implementation manner, the first packet satisfies a matching rule of a certain flow entry in the flow table, and the first device may determine that the first packet is not a first packet of a network flow (i.e., a first network flow) corresponding to the flow entry, and may forward the first packet according to a forwarding rule of the flow entry.

Based on that the first device is the first device 22 shown in fig. 2A, the server cluster 23 is configured to provide the first service, and if the packet received by the first device 22 does not satisfy the matching rule of all the flow entries in the flow table, the first device 22 may select a server i (i.e., a target server) from the server cluster 23 according to the load balancing policy, create a flow entry of the first network flow in the flow table, and then forward the packet to the server i. If the packet received by the first device 22 satisfies the flow entry of the first network flow, the first device may forward the packet to the server i according to the flow entry of the first network flow.

The load balancing policy may include a load balancing algorithm including, but not limited to, a round robin method, a random method, a source address hashing method, a weighted round robin method, a weighted random method, or a minimum join method. In one possible implementation, the load balancing policy also takes into account other factors such as the operating status of the servers in the server cluster 23.

With continued reference to the application scenario described with reference to fig. 2A, although all servers in the server cluster 23 are configured to provide the first service, since some of the servers in the server cluster 23 may be abnormal, the abnormal servers in the server cluster 23 may not provide the first service. In order to reduce the influence of the backend server abnormality on the first service and improve the availability of the first service, in a possible implementation manner, after receiving the first packet, the first device may obtain server information of the first service, where the server information of the first service records an identifier of a server in the server cluster 23 that is in a normal operating state. In a possible implementation manner, the server information obtained after the first device receives the first packet records identifiers of m servers, where the m servers are servers in the server cluster 23, the identifiers of the m servers include an identifier of a server i, and m is a positive integer smaller than or equal to n. In a possible implementation manner, the first device may select an identifier of a server i (i.e., a target server) from the identifiers of the m servers, and then forward the first packet to the server i according to the identifier of the server i. In one possible implementation, the identification of the server is the name or number of the server or a network address (e.g., an IP address and port number).

In a possible implementation manner, if the first device determines that the target server is abnormal, the first device may modify server information corresponding to the first service, where the modified server information does not include the identifier of the target server. Therefore, the first device can be prevented from continuously forwarding the message for accessing the first service to the target server, and the reliability of the first service can be improved.

Step 303, based on that the first device does not receive the second message from the target server within the preset time length, the first device determines that the running state of the target server is abnormal;

after the first device forwards the first message, the operating state of the target server can be detected according to the receiving condition of the message meeting a certain specific condition. For convenience of description, in the embodiments of the present application, a "packet satisfying a certain condition" is referred to as a second packet.

After the first device forwards the first packet, if the operating state of the target server is normal, the target server may receive and process the first packet, and send a corresponding processing result packet (for example, the processing result shown in fig. 1 or fig. 2A) to the client, and accordingly, the first device may generally receive the processing result packet of the target server for the first packet within a certain time duration (referred to as a preset time duration). If the running state of the target server is abnormal, the first device generally cannot receive the processing result message of the first message from the target server within the preset time length. There are various reasons that cause the running state of the target server to be abnormal, and the common reasons are, for example, that the target server is in a shutdown state or that a link between the target server and the first device fails. In this case, the target server cannot process not only the first packet forwarded by the first device, but also other packets besides the first packet forwarded by the first device, and accordingly, the first device cannot receive the packet from the target server.

Based on the above analysis, in a possible implementation manner, the first device may determine whether to receive the message from the target server within a preset time period, and if the first device does not receive the message from the target server within the preset time period, it indicates that the first device does not receive a processing result message of the target server for the first message within the preset time period, and the first device may determine that the operation state of the target server is abnormal. Accordingly, in this implementation, the aforementioned second message may refer to a message from the target server. In one possible implementation manner, the first device may identify the second packet by determining whether a source network address of the received packet is a network address of the target server. Based on the source network address of the received message being the network address of the destination server, the first device may determine that the message is a second message. In one possible implementation, the network address includes an Internet Protocol (IP) address and/or a port number.

The specific implementation of step 303 will be further described later, for example, with reference to the contents of step 403, step 405, and step 406 in the embodiment corresponding to fig. 4, or with reference to the embodiment corresponding to fig. 6, which will not be described herein for the moment.

The advantageous effects of the corresponding embodiment of fig. 3 are analyzed below.

In the embodiment method corresponding to fig. 3, the first device may detect the operation state of the target server without additionally generating and sending a detection message to the target server in the process of forwarding the packet between the client and the target server, which is beneficial to reducing network resources occupied in the operation state detection process. If the target server is, for example, a server i in the server cluster 23 shown in fig. 2A, and the first device is, for example, the first device 22 shown in fig. 2A, in the process of forwarding the packet between the client 21 and the server cluster 23, the first device may detect the operating state of the server cluster 23 without additionally generating and sending a detection message to each server in the server cluster 23, which is beneficial to reducing network resources occupied by the operating state detection process and influences on other services of the server cluster 23. In addition, since the running state detection performed by the first device is triggered by the message of the access service, for the servers that are not accessed in the server cluster 23, the first device may not detect the running state thereof, which is beneficial to reducing the number of times of the running state detection performed by the first device, and is beneficial to reducing the occupation of the running state detection on the device resources (such as computing resources and storage resources) of the first device.

In addition, since the first device may detect the operating state of the target server by identifying the source network address of the second packet, the method in the embodiment corresponding to fig. 3 is not affected by the protocol used for transmitting the first packet, and may be applied to an application scenario where multiple protocols such as TCP or UDP are used to transmit packets. In addition, because the first device does not need to perform deep packet inspection on the first packet or the second packet, the influence of the running state inspection process on the forwarding performance of the first device can be reduced.

Two reasons for the target server exception are listed above, and in addition, there are other reasons that may cause the target server exception, for example, the load of the target server is too large (for example, the CPU occupancy is too large), and the target server may not provide the first service. In this case, although the target server cannot process the first packet forwarded by the first device, the target server may process other packets besides the first packet forwarded by the first device, and accordingly, the first device may receive a processing result packet of the other packets sent by the target server. Therefore, in order to detect the operation state of the target server corresponding to the first service and improve the detection accuracy of the operation state of the target server, in a possible implementation manner, the second message mentioned in step 303 may be a processing result message of the target server for the first service. Correspondingly, in a possible implementation manner, the second packet carries the identifier of the first service. In a possible implementation manner, the second packet mentioned in step 303 may be a processing result packet of the target server on the first packet. In a possible implementation manner, the destination network address of the aforementioned second packet may be the source network address of the first packet. In one possible implementation, the first device may identify the second packet by determining whether a destination network address of the packet from the destination server is the same as a source network address of the first packet. Based on the destination network address of the message from the destination server being the same as the source network address of the first message, the first device may determine that the message is a second message.

The present application does not limit the cause of the abnormality of the target server, and the above-listed causes are only examples.

In a possible implementation manner, the preset duration mentioned in step 303 is determined according to a preset response duration of the first service. In one possible implementation, the response duration of the first service may be configured for a tenant of the first service.

In one possible implementation, the preset duration is equal to a response duration of the first service. Or, in a possible implementation manner, the starting time of the response duration of the first service corresponds to the time when the client sends the request packet of the first service, the ending time of the response duration of the first service corresponds to the time when the client receives the processing result packet of the request packet, and accordingly, the preset duration is smaller than the response duration of the first service. In a possible implementation manner, if the first device can receive the processing result message of the first message within a preset time period, the client can receive the processing result message of the first message within a response time period of the first service after the first message is sent.

With continued reference to the application scenario shown in fig. 2A, it is assumed that the first device 22 determines a preset time length according to the response time length of the first service, and executes the method of the embodiment corresponding to fig. 3 according to the preset time length to detect the operation state of the servers in the server cluster 23. Then, the first device 22 updates the load balancing policy according to the detection result, and forwards the message for subsequently accessing the first service to the server in the normal operation state, which is beneficial for the first device to receive the processing result message within the preset time length, and is further beneficial for the client to receive the processing result message within the response time length of the first service, thereby being beneficial to improving the user experience of the first service.

In one possible implementation, with continued reference to fig. 3, after step 303, the corresponding embodiment method of fig. 3 further includes step 304.

Step 304, the first device sends a second message to the second device.

In a possible implementation manner, if the first device determines that the operation state of the target server is abnormal, the first device may send a second message to the second device, where the second message is used to notify the second device that the operation state of the target server is abnormal. In one possible implementation, the second device may be, for example, the detection device 14 shown in fig. 1 or the detection device 24 shown in fig. 2A or the detection device j shown in fig. 2B.

After receiving the second message, the second device may notify a maintenance person to check and maintain the target server, or may refer to an existing operation state detection scheme, send a detection message to the target server, and determine whether a response message of the target server to the detection message is received, and then determine the operation state of the target server according to the determination result. For example, if the second device receives a response message from the target server, the second device may determine that the operating state of the target server is normal, and if the second device does not receive the response message from the target server, the second device may determine that the operating state of the target server is abnormal.

Alternatively, in one possible implementation, the second device may be a forwarding device or a load balancing device other than the first device. Taking fig. 2B as an example, the second device may be a forwarding device or a load balancing device deployed in the node j, or a device having the same function as the first device. After receiving the second message, the second device may forward the packet accessing the first service to another server in the server cluster 23 except the target server (i.e., the server i), thereby being beneficial to ensuring the reliability of the first service.

In the prior art, the detection device periodically sends the detection message to the server, that is, even if the target server can send the second packet within the preset time period, the detection device still sends the detection message to the target server, which wastes network resources. In this embodiment of the application, the first device determines, through step 303, a time to send the detection message, and if the first device receives the second message from the target server within the preset time period, the first device does not need to send the detection message to the target server, which is beneficial to saving network resources.

In the application scenario corresponding to fig. 2A, the existing detection device 24 needs to periodically send detection messages to all servers in the server cluster 23, which wastes a lot of network resources. In this embodiment of the application, the first device screens out the suspicious server from the server cluster 23 through step 303, and the first device only needs to send a detection message to the suspicious server to further determine the operating state of the suspicious server, which is beneficial to reducing the occupation of network resources in the detection process.

In the method of the embodiment of the method corresponding to fig. 3 described above, after the first device receives and forwards the first packet from the client, the first device may detect the operating state of the target server according to whether the second packet from the target server is received within the preset time period. Taking the application scenario shown in fig. 2A as an example, another possible embodiment of the method of the present application is described below with reference to the flowchart shown in fig. 4. Compared with the embodiment method corresponding to fig. 3, the embodiment method corresponding to fig. 4 specifically describes how the first device determines whether the target server is received within a preset time period. Therefore, optionally, in the embodiment method corresponding to fig. 4, the content related to the embodiment method corresponding to fig. 3 can be understood with reference to the embodiment corresponding to fig. 3.

Referring to fig. 4, a method according to an embodiment of the present application may include the following steps 401 to 406.

Step 401, a first device receives a first message from a client;

for the understanding of the first device and the client, reference may be made to the foregoing description of the first device 22 and the client 21 in fig. 2A, respectively, and the description thereof is omitted here.

Step 402, the first device selects a server i as a target server according to server information corresponding to the first service;

in this embodiment, the first device may select a server i from the server cluster 23 as a target server. In one possible implementation, the first device may select server i according to a load balancing policy. For example, in a possible implementation manner, referring to the content of step 302 in the embodiment corresponding to fig. 3, based on that the first packet is the first packet of the first network flow, the first device may obtain server information of the first service, and select a server i as a target server from m servers recorded in the server information according to a load balancing algorithm.

In a possible implementation manner, referring to the content in step 302 in the embodiment corresponding to fig. 3, after receiving the first packet, the first device may search a flow table entry corresponding to the first packet in a flow table. If the first device finds a flow entry corresponding to the first packet in the flow table, the first device may determine that the first packet is a subsequent packet in the network flow corresponding to the flow entry. In a possible implementation manner, the first device may update the content of the flow entry according to the first packet, for example, update statistical information in the flow entry. If the first device cannot find the flow entry corresponding to the first packet in the flow table, the first device may determine that the first packet is the first packet of one network flow (referred to as a first network flow). In a possible implementation manner, based on that the first packet is the first packet of the first network flow, after the first device selects the target server, a new flow table entry (referred to as a first flow table entry) may be inserted into the flow table by the first device, where a matching rule in the first flow table entry is used to identify a subsequent packet of the first network flow, and a forwarding rule in the first flow table entry is used to forward the subsequent packet of the first network flow.

Step 402 is only one possible implementation manner for the first device to select the server i, and this embodiment does not limit that the first device must select the server i to process the first packet by executing step 402.

Step 403, the first device generates a matching rule and records a matching result of the matching rule;

referring to the content of step 302 in the corresponding embodiment of fig. 3, the first device may detect the operation status of the target server according to the reception of the second packet from the target server. In order to facilitate detection of the receiving condition of the second message, after selecting the server i as the target server, the first device may generate a matching rule for identifying the second message from the target server, and record a matching result of the matching rule. The first device may record the matching result as the first information based on that the first device does not receive the message satisfying the matching rule, and the first device may record the matching result as the second information based on that the first device receives the message satisfying the matching rule. After the first message is forwarded, the first device can determine whether a message meeting the matching rule is received or not by checking the matching result, namely, whether a second message from the target server is received or not is judged, and then the running state of the target server is detected.

Referring to the description of the second packet in the embodiment corresponding to fig. 3, in a possible implementation manner, the matching rule of the second packet may be used to identify the packet from the target server. Further, in a possible implementation manner, the matching rule of the second packet may also be used to identify a processing result packet of the target server for the first service. Taking the quintuple as an example of defining the same attribute of the network flow, in a possible implementation manner, the first device may determine a second quintuple according to the quintuple of the first packet (referred to as a first quintuple), and then determine a matching rule identifying the second packet according to the second quintuple. In a possible implementation manner, the source network address of the second quintuple is the network address of the destination server, and the destination network address of the second quintuple is the network address of the client. For ease of understanding, the following illustrates possible forms of the first five tuple and the second five tuple by table 1.

TABLE 1

Source IP	Source port	Destination IP	Destination port	Protocol
					ip1	port1	ip2	port2	protocol
ip3	port3	ip1	port1	protocol

Table 1 records two quintuple sets, where the first row of table 1 is used to indicate the information type corresponding to each column, the second row of table 1 records the first quintuple set, and the third row records the second quintuple set. Specifically, IP1 and port1 represent the IP address and source port of the client, IP2 and port2 represent the IP address and source port of the first device, IP3 and port3 represent the IP address and source port of the destination server,

in a possible implementation manner, after determining the second quintuple according to the first quintuple, the first device may calculate a hash value of the second quintuple, and use the obtained hash value (represented by a key) as a matching rule for identifying the second packet.

In a possible implementation manner, the first device may insert a new flow table entry (referred to as a second flow table entry) into the flow table, where a part of fields in the second flow table entry is used to indicate a matching rule, and a part of fields in the second flow table entry is used to record a matching result. If the content of the matching result is the first information (for example, "0"), it indicates that the first device has not received the message satisfying key1, and if the content of the matching result is the second information (for example, "1"), it indicates that the first device has received the message satisfying key 1. For ease of understanding, possible forms of the second flow entry are illustrated below by tables 2-1 and 2-2.

TABLE 2-1

Matching rules	Matching results
		key1	0
key2	0

Tables 2 to 2

Matching rules	Matching results
		key1	0
key2	1

The first row of tables 2-1 and 2-2 is used to indicate the type of information to which each column corresponds. The second row of tables 2-1 and 2-2 shows the contents of the second flow entry at time t1 and time t2, respectively. Assuming that key1 is used to identify the second packet, time 1 corresponds to the time when the first device generates the flow table entry, and time 2 corresponds to a time after time t1 by the first device. Since the matching result corresponding to the key1 is still 0 at the time t2, the first device may determine that the message satisfying the key1 is not received before the time t 2.

The first packet mentioned in the embodiment of the present application represents a type of packet from the client, and the first packet is not limited to be one packet. Similarly, the second packet mentioned in the embodiment of the present application represents a processing result packet of the first packet, and the second packet is not limited to be one packet. Assuming that the first device receives message 1 and message 2 at the same time (e.g., within a small time window), message 1 and message 2 both correspond to the first message mentioned in the embodiments of the present application, except that the source network addresses of message 1 and message 2 may be different, and/or the services accessed by message 1 and message 2 may be different. The first device may perform the embodiment method corresponding to fig. 4 for message 1 and message 2, respectively, and generate a flow entry (see the second row in tables 2-1 and 2-2) for identifying a processing result message (corresponding to the second message) of message 1, and a flow entry (see the third row in tables 2-1 and 2-2) for identifying a processing result message (corresponding to the second message) of message 2, respectively. Since the matching result corresponding to the key1 is still 0 at the time t2, the first device may determine that the message satisfying the key1 is not received before the time t2, that is, the processing result message of the message 1 is not received. Since the matching result corresponding to the key2 is 1 at the time t2, the first device may determine that the message satisfying the key2 is received before the time t2, that is, the processing result message for the message 2 has been received.

Step 404, the first device forwards a first message to a target server;

referring to the content of step 402, after selecting server i as the target server, the first device may forward the first packet to the target server.

In one possible implementation, the first device selects the target server from the server cluster 23 by using a Network Address Translation (NAT) based load balancing technology. Correspondingly, the first device may change the destination network address in the first message to the network address of the target server, for example, perform Destination Network Address Translation (DNAT) on the first message, and then send the modified first message to the target server.

The above describes a process (referred to as an uplink process) performed by the first device after receiving the first packet (including receiving the first packet) and before forwarding the first packet (including forwarding the first packet) through steps 401 to 404. To facilitate understanding of the upstream flow, fig. 5 illustrates one possible embodiment of the upstream flow.

Referring to fig. 5, the upstream flow may include steps 501 to 508.

Step 501, a first device receives a first message;

step 502, the first device searches a flow table entry corresponding to the first message in a flow table;

step 503, the first device determines whether the first message hits a flow entry in the flow table, if the first message hits the flow entry in the flow table, the first device executes step 504, and if the first message does not hit the flow entry in the flow table, the first device executes step 505;

step 504, the first device updates the hit flow table entry;

step 505, the first equipment selects a target server from the server information of the first service according to a load balancing strategy;

step 506, the first device creates a first flow table item and a second flow table item for the first message;

step 507, the first equipment carries out DNAT on the first message;

and step 508, the first equipment transmits the first message to the target server.

Step 501 shown in fig. 5 may be understood with reference to the content of step 401, step 502 to step 505 shown in fig. 5 may be understood with reference to the content of step 402, step 506 shown in fig. 5 may be understood with reference to the content of step 402 and step 403, and step 507 to step 508 shown in fig. 5 may be understood with reference to the content of step 404, which is not described again here.

Step 405, based on the recording duration reaching or exceeding the preset duration and the matching result being the first information, the first device determines that the second message is not received within the preset duration;

after the first device generates the matching rule for identifying the second packet or forwards the first packet, the first device may start recording the time length, and based on the recording time length reaching or exceeding the preset time length, the first device may read the matching result recorded in step 403. Based on the matching result being the first information, the first device may determine that the second message is not received within a preset time period. Based on the matching result being the second information, the first device may determine that the second message is received within a preset time period.

For understanding the preset time period, reference may be made to the description about the preset time period in the embodiment corresponding to fig. 3, which is not described herein again.

In a possible implementation manner, referring to the relevant content in step 403, after receiving the first packet, the first device may insert, based on that a flow entry corresponding to the first packet is not found in the flow table, a second flow entry (the flow entry is, for example, shown in the second row or the third row in table 2-1) into the flow table. After the first device generates the second flow entry, a timer may be started, and a duration of the timer may be set to a preset duration. When the duration recorded by the timer reaches or exceeds the preset duration, the first device may read the matching result in the second flow entry, determine that the second packet is not received within the preset duration based on the matching result in the second flow entry being the first information (e.g., "0" shown in the second row in table 2-2), and determine that the second packet is received within the preset duration based on the matching result in the second flow entry being the second information (e.g., "1" shown in the third row in table 2-2).

The first message mentioned in the embodiment of the present application represents a type of message from a client, and is not limited to be one message, and the first device may receive p first messages simultaneously (for example, within a smaller time window), and generate p flow entries for processing result messages of the p first messages, where p is a positive integer greater than or equal to 2. Assuming that the p first packets include packet 1 and packet 2 mentioned in the content of step 403, the second flow table entry generated for the processing result packet of packet 1 is shown in the second row of table 2-1, and the second flow table entry generated for the processing result packet of packet 2 is shown in the third row of table 2-2. In a possible implementation manner, the first device may start p timers after generating p second flow entries for the processing result packet of p first packets. In order to reduce the number of timers started in step 405, in a possible implementation manner, the first device may start a timer, and when the timer reaches or exceeds the preset duration, the first device may respectively read the matching results in the p flow table entries to respectively determine whether to receive the second messages (i.e., the processing result messages) corresponding to the p messages within the preset duration.

Step 403 and step 405 describe a possible way for the first device to determine whether the second message is received within the preset time period, and in the method in the embodiment of the present application, the first device may also determine whether the second message is received within the preset time period in other ways.

Step 406, the first device judges that the running state of the target server is abnormal;

based on that the first device does not receive the second message within the first preset time, the first device may determine that the operating state of the target server is abnormal.

In a possible implementation manner, if the first device does not receive the second message within the preset time period, the first device may directly determine that the operation state of the target server is abnormal.

Or, in a possible implementation manner, in order to further improve the accuracy of the detection result, if the first device does not receive the second packet within the preset time duration, the first device may perform other steps to further determine whether the target server is abnormal. For example, in a possible implementation manner, based on that the first device does not receive the second packet within a preset time period, the first device may send a first message to the target server, where the first message is used to detect an operating state of the target server. In one possible implementation, the first message instructs the target server to send a response message to the first device. After that, the first device may further determine whether the operation state of the target server is normal or abnormal according to the reception condition of the response message. The first message and the response message may be sent in the form of a message, and therefore, it may also be considered that the first device sends a detection message to the target server, where the detection message indicates that the target server sends the response message to the first device.

Steps 405 to 406 describe a process (referred to as a decision process) in which the first device determines the operation state of the target server from the matching rule generated in step 403 and the recorded matching result. For ease of understanding, fig. 6 shows one possible embodiment of the decision flow.

Referring to fig. 6, a determination process according to an embodiment of the present disclosure may include steps 601 to 606.

Step 601, responding to the overtime of the timer, and reading a matching result in the second flow table item by the first equipment;

the timer and the second flow table entry may be understood with reference to the timer and the second flow table entry mentioned in step 405, respectively. The timeout of the timer can specify that the time length recorded by the timer reaches or exceeds a preset time length.

Step 602, the first device determines that the matching result is the first information or the second information, if the matching result is the first information, the first device performs step 603, and if the matching result is the second information, the first device performs step 604;

step 603, the first equipment judges that the running state of the target server is normal;

step 604, the first device sends a first message to the target server;

step 605, the first device determines whether a response message of the first message is received, if the first device receives the response message, the first device performs step 603, and if the first device does not receive the response message, the first device performs step 606;

and 606, the first device judges that the running state of the target server is abnormal.

The steps shown in fig. 6 can be understood with reference to the related contents of step 405 and step 406 in the embodiment corresponding to fig. 5, and are not described herein again.

In the determination process provided in fig. 6, the first device first performs passive detection on the servers in the server cluster 23, screens out the target servers suspected to be abnormal with relatively low performance overhead, and then triggers an active detection mechanism, so as to more accurately determine whether the target servers are abnormal, and can detect the operating state of the server cluster 23 (for example, a large-scale distributed cluster node) with relatively low network resource overhead.

In one possible implementation, referring to fig. 4, after step 406, the corresponding embodiment method of fig. 4 further includes step 407.

Step 407, the first device modifies server information corresponding to the first service;

the server information corresponding to the first service is used to record the identifier of the server in the server cluster 23, which is in a normal operating state. Referring to the content of step 402, the server information corresponding to the first service acquired by the first device after receiving the first packet includes an identifier of the target server (i.e., server i). In a possible implementation manner, if the first device determines that the operating state of the target server is abnormal, the first device may modify server information corresponding to the first service, where the modified server information does not include the identifier of the target server. In this way, when the first device receives the packet requesting the first service, the first device avoids forwarding the packet to the server i, and instead forwards the packet to a server in the server cluster 23 in a normal operating state, which is beneficial to ensuring the reliability of the first service.

In a possible implementation manner, the first device may delete the identifier of the server i from the server information corresponding to the first service. Or, the first device records identifiers of all servers in the server cluster 23 and an operating state corresponding to each server, where the server information corresponding to the first service is an identifier of a server whose operating state is normal, and correspondingly, the first device may change the operating state of the server i to be abnormal, so that the server information corresponding to the first service does not include the identifier of the server i.

In one possible implementation, after step 406, the embodiment method corresponding to fig. 4 further includes step 408.

Step 408, the first device sends a second message to the second device.

In a possible implementation manner, if the first device determines that the operation state of the target server is abnormal, the first device may send a second message to the second device, where the second message is used to notify the second device that the operation state of the target server is abnormal. In one possible implementation, the second device may be, for example, the detection device 24 shown in fig. 2A. The understanding of step 408 can refer to the related description of step 304 in the corresponding embodiment of fig. 3, and is not described herein again.

The method according to the embodiment of the present application is introduced above, and the apparatus according to the embodiment of the present application is introduced below.

The embodiment of the application provides a running state detection device of a server. For example, the operation state detection device of the server may be the first device mentioned in the method of the embodiment of the present application, or a device in the first device, or a device that can be used in cooperation with the first device.

The following describes the device according to the embodiment of the present application. Fig. 7 is a schematic diagram of a possible structure of the operation state detection apparatus 7 of the server according to the embodiment of the present application. Referring to fig. 7, the operation state detection device 7 of the server includes a processor 701 and a memory 702.

The processor 701 may be one or more CPUs, which may be a single-core CPU or a multi-core CPU.

The memory 702 includes, but is not limited to, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a flash memory, an optical memory, or the like. The memory 702 has stored therein computer readable programs or instructions. Optionally, the memory 702 may be a non-volatile memory or a volatile memory.

Optionally, the operation state detection device 7 of the server further includes a communication interface 703, where the communication interface 703 may be a wired interface, for example, a Fiber Distributed Data Interface (FDDI) or a Gigabit Ethernet (GE) interface; the communication interface 703 may also be a wireless interface. The communication interface 703 is used for receiving network data from an internal network and/or an external network, or for transmitting network data to the internal network and/or the external network.

Optionally, the operation status detection device 7 of the server further includes a bus 704, and the processor 701 and the memory 702 are generally connected to each other through the bus 704, and may also be connected to each other in other manners.

The processor 701 causes the running state detection means 7 of the server to execute the method performed by the first device in the above-described method embodiment by reading and executing the program instructions stored in the memory 702. For example, the processor 701 reads and executes the program instructions stored in the memory 702 to make the server operation state detection device 7 execute the steps in the embodiment shown in fig. 3, the steps in the embodiment shown in fig. 4, the steps in the embodiment shown in fig. 5, or the steps in the embodiment shown in fig. 6. The processor 701 reads and executes the saved program instructions to make the operation state detection device 7 of the server execute the above steps in more detail, referring to the corresponding description in the foregoing method embodiments, which are not repeated here.

Optionally, the instructions are stored in a memory external to the computer device. When these instructions are decoded and executed by the processor 701 of the server operation state detection device 7, a part or all of the contents of the instructions are temporarily stored in the memory 702 inside the server operation state detection device 7. Alternatively, part of the contents of these instructions are stored in a memory external to the operation state detection means 7 of the server, and the other part of the contents of these instructions are stored in the memory 702 internal to the operation state detection means 7 of the server.

An embodiment of the present application further provides a chip system, which includes a processor and an interface circuit, where the processor is configured to be coupled to a memory through the interface circuit, and the processor is configured to execute the program code stored in the memory, so as to implement the method provided in any one of the method embodiments described above in the present application.

In one example, the processor may execute instructions stored in the memory to cause the system-on-chip to perform any of the method embodiments described above. Alternatively, the memory may be a storage unit within the system-on-chip, such as a register, a cache, etc., or the memory may be a memory external to the system-on-chip within the computer device, such as a read-only memory (ROM) or other types of static storage devices that may store static information and instructions, a Random Access Memory (RAM), etc. Optionally, the memory may be a non-volatile memory or a volatile memory. Alternatively, the processor may be a general purpose Central Processing Unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more ics for controlling the execution of programs in any of the above method embodiments.

Fig. 8 is a schematic view of another possible structure of the operation state detection device 8 of the server according to the embodiment of the present application. Referring to fig. 8, the operation state detection device 8 of the server includes a communication module 801 and a processing module 802. The communication module 801 is configured to receive a first packet from a client, and further configured to forward the first packet to a target server after receiving the first packet. The processing module 802 is configured to determine that the operation state of the target server is abnormal based on that the communication module 801 does not receive the second message from the target server within a preset time period.

Specifically, for example, the communication module 801 is configured to perform step 301, step 302, or step 304 in the embodiment shown in fig. 3, and the processing module 802 is configured to perform step 303 in the embodiment shown in fig. 3.

In one possible implementation, the communication module 801 is configured to perform step 401, or step 404, or step 408 in the embodiment shown in fig. 4. In a possible implementation manner, the processing module 802 is configured to execute step 402, or step 403, or step 405, or step 406, or step 407 in the embodiment shown in fig. 4.

In one possible implementation, the communication module 801 is configured to perform step 501 or step 508 in the embodiment shown in fig. 5. In one possible implementation manner, the processing module 802 is configured to perform at least one of the steps 502 to 507 in the embodiment shown in fig. 5.

In one possible implementation, the processing module 802 is configured to perform at least one step in the embodiment shown in fig. 6.

The division of the modules by the server operation state detection device 8 depicted in fig. 8 is only illustrative, and is only a logical functional division, and other division manners may be possible in actual implementation, for example, a plurality of modules or components may be combined or integrated into another system, or some features may be omitted or not executed. Each functional module in the server operation state detection device 8 may be integrated into one processing module, or each module may exist alone physically, or two or more modules may be integrated into one module.

The modules in fig. 8 may be implemented in the form of hardware, or may be implemented in the form of software functional units. For example, when implemented in software, the modules in fig. 8 may be implemented by software functional modules generated after the processor 701 in fig. 7 reads program codes stored in the memory 702. The modules in fig. 8 may also be implemented by different hardware in fig. 7, for example, the communication module 801 may be implemented by a communication interface 703, and the processing module 802 is implemented by a part of processing resources (e.g., other cores in a multi-core processor) in the processor 701 in fig. 7, or by a field-programmable gate array (FPGA), a coprocessor, or other programmable devices. Obviously, the above functional modules may also be implemented by a combination of software and hardware.

The embodiment of the application also provides a system for detecting the running state of the server, which can comprise a device for detecting the running state of the server, a client and the server, wherein the client can communicate with the target server through the device for detecting the running state of the server. In a possible implementation manner, the function of the operation state detection apparatus of the server may be understood with reference to the steps executed by the first device in any one of the embodiments shown in fig. 3 to 6, and the client and the server may be understood with reference to the client and the target server in the corresponding embodiments, which are not described herein again. In a possible implementation, the system may be, for example, as shown in fig. 1, where the client corresponds to the client 11 shown in fig. 1, the operation state detection device of the server corresponds to the first device 12, and the server corresponds to the server 13. In a possible implementation manner, the system may be shown in fig. 2A or fig. 2B, for example, where the client corresponds to the client 21 shown in fig. 2A or fig. 2B, the operation state detection device of the server corresponds to the first device 22, and the server corresponds to the server i in the server cluster 23.

The coupling in the embodiments of the present application is an indirect coupling or a communication connection between devices, units or modules, and may be an electrical, mechanical or other form for information interaction between the devices, units or modules.

One of ordinary skill in the art will appreciate that when aspects of the embodiments of the present application, or possible implementations of aspects, are implemented using software, the aspects, or possible implementations of aspects, may be implemented in whole or in part in the form of a computer program product. Computer program product refers to program code stored in a computer readable medium. When loaded and executed on a computer, cause the processes or functions described in accordance with the embodiments of the application to occur, in whole or in part. The method and the device for deploying the SLB in the network equipment can be operated in a cloud native (cloud native) environment without special hardware cooperation, and can also be operated in the network equipment in an embedded software mode, and the specific deploying position depends on the deploying position of the SLB. For example, in a firewall scenario, the foregoing aspects, or possible implementations of the aspects, may be software programs running on a CPU of a firewall code Segment Processing Unit (SPU).

The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium includes, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. The terms "first," "second," "third," "fourth," "fifth," "sixth," and the like in the description and claims of this application and in the foregoing drawings are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the terms so used are interchangeable under appropriate circumstances and are merely descriptive of the various embodiments of the application and how objects of the same nature can be distinguished. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of elements is not necessarily limited to those elements, but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. The term "plurality" appearing in the embodiments of the present application means two or more. It should be understood that the term "and/or" herein is merely one type of association relationship that describes an associated object, meaning that three relationships may exist, e.g., a and/or B may mean: a exists alone, A and B exist simultaneously, and B exists alone. In addition, the character "/" herein generally indicates that the former and latter related objects are in an "or" relationship.

It should be understood that, in the various embodiments of the present application, the sequence numbers of the above-mentioned processes do not mean the execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

The above embodiments are only used to illustrate the technical solutions of the present application, and not to limit the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present application.

Claims

1. An operation state detection method of a server is characterized by comprising the following steps:

the method comprises the steps that first equipment receives a first message from a client;

the first equipment forwards the first message to a target server;

and based on the fact that the first equipment does not receive a second message from the target server within a preset time length, the first equipment judges that the running state of the target server is abnormal.

2. The method of claim 1, wherein the destination network address of the second packet is the source network address of the first packet.

3. The method of claim 2, wherein the first packet is a first packet in a first network flow received by the first device.

4. The method of claim 3, wherein after the first device receives the first packet, the method further comprises:

the first device generates a matching rule and records a matching result of the matching rule, the matching rule is used for identifying the second message, the matching result is recorded as first information based on that the first device does not receive the message meeting the matching rule, and the matching result is recorded as second information based on that the first device receives the message meeting the matching rule.

5. The method of claim 4, further comprising:

and based on that the recording duration reaches or exceeds the preset duration and based on that the matching result is the first information, the first device determines that the second message is not received within the preset duration, wherein the recording duration is the duration recorded by the first device after the matching rule is generated.

6. The method according to any one of claims 1 to 5, wherein the preset duration is determined according to a response duration of the service requested by the first packet.

7. The method according to any of claims 1 to 6, wherein the first packet requests a first service, the target server is determined for the first device from n servers corresponding to the first service, and n is a positive integer greater than 1.

8. The method of claim 7, wherein forwarding, by the first device, the first packet to a target server comprises:

the first device forwards the first message to the target server according to server information corresponding to the first service, where the server information includes identifiers of m servers, the n servers include the m servers, the identifiers of the m servers include an identifier of the target server, and m is a positive integer less than or equal to n;

after the first device determines that the operating state of the target server is abnormal, the method further includes:

and the first equipment modifies the server information, and the modified server information does not comprise the identification of the target server.

9. The method according to any one of claims 1 to 8, wherein the determining, by the first device, that the operation state of the target server is abnormal comprises:

and the first equipment sends a first message to the target server, wherein the first message is used for detecting the running state of the target server.

10. The method according to any one of claims 1 to 9, wherein after the first device determines that the operation state of the target server is abnormal, the method further comprises:

and the first equipment sends a second message to second equipment, wherein the second message is used for informing the second equipment that the running state of the target server is abnormal.

11. The running state detection device of the server is characterized by comprising a communication module and a processing module:

the communication module is used for receiving a first message from a client and forwarding the first message to a target server after receiving the first message;

the processing module is used for judging that the running state of the target server is abnormal based on the fact that the communication module does not receive the second message from the target server within the preset time length.

12. An operating state detection apparatus of a server, comprising a processor and a memory coupled to the processor, the memory for storing program code, the processor for invoking the program code to perform the method of any of claims 1 to 10.

13. A chip system comprising a processor and interface circuitry, the processor being coupled to a memory via the interface circuitry, the processor being configured to execute program code in the memory to implement the method of any of claims 1 to 10.