Cluster deployment method and system, electronic device

Through the load balancing module and virtual extended LAN tunnel technology within the cluster, the problem of the cluster being unable to access across subnets is solved, efficient cross-subnet traffic distribution and rapid automatic switching of faults are achieved, and the availability and responsiveness of the cluster are improved.

CN119299360BActive Publication Date: 2025-10-24CHINA TELECOM INTELLIGENT NETWORK TECHNOLOGY CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202411237517.2
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-09-04
Publication Date
2025-10-24
Estimated Expiration
2044-09-04

AI Technical Summary

Technical Problem

In the existing technology, clusters deployed using direct routing cannot be accessed within different Layer 3 domains, resulting in the load balancer only being able to work within the same Layer 2 domain and unable to distribute traffic across subnets. The configuration process is complicated and lacks fault monitoring.

Method used

By obtaining the business traffic type through the load balancing module within the cluster and distributing the traffic among different subnets according to the IP virtual server and IP channel configuration rules, cross-subnet access is achieved by combining the virtual extended LAN tunnel, and a network management platform and operation monitoring module are equipped for dynamic adjustment and troubleshooting.

Benefits of technology

It achieves cross-subnet load balancing, improves cluster availability and responsiveness, simplifies the configuration process, and supports rapid automatic switching and monitoring of faults.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119299360B_ABST
    Figure CN119299360B_ABST
Patent Text Reader

Abstract

The application discloses a cluster deployment method and system and electronic equipment. The method is applied to a cluster deployment system deployed in a first subnet in a cluster, and comprises the following steps: obtaining a plurality of incoming service traffics of a service subsystem of a first server, wherein the first server has a load balancing function; obtaining a configuration rule of the first server, wherein the configuration rule at least comprises an IPVS configuration rule for defining a corresponding relationship between an IPVS of the first server and a second server for processing different types of service traffics, and an IP channel configuration rule for defining an IP channel between the first server and the second server; for each incoming service traffic, determining a type of the current incoming service traffic, and distributing the current incoming service traffic to a service subsystem of a second target server through a target IP channel according to the type and the configuration rule. The application solves the technical problem that a cluster deployed by using a direct routing mode cannot realize access in different three-layer domains.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network security, in particular to a cluster deployment method and system and an electronic device. BACKGROUND

[0002] With the rapid development of 5G converged private network services, the interworking demand between private networks and public networks is increasingly urgent, but this also brings a series of network security, operator control and other problems. In order to solve this problem, the operator proposes the architecture concept of signaling interworking gateway (Customized-Inter Working Function, C-IWF), that is, by deploying a signaling interworking gateway between the private network and the public network, the security of the public network and the private network is ensured, and the complexity of network connection is simplified. In order to ensure the stability and high availability of C-IWF, high-availability clusters are often deployed.

[0003] Currently, related technical personnel usually use IPVS (Internet Protocol Virtual Server) as a load balancer of the cluster when deploying a high-availability cluster, and uses a direct routing (DR) method to distribute cluster inbound traffic to a service processing unit. However, this deployment scheme cannot cross three-layer networks and can only realize load balancing within the same subnet (The Onion Router, onion routing) two-layer domain.

[0004] In view of the above problems, no effective solution has been proposed so far. SUMMARY

[0005] The embodiments of the present application provide a cluster deployment method and system and an electronic device to at least solve the technical problem that the cluster deployed by using the direct routing method cannot realize access in different three-layer domains.

[0006] According to an aspect of the embodiments of the present application, a cluster deployment method is provided, which is applied to a cluster deployment system deployed in a first subnet in a cluster, and the cluster includes a plurality of subnets, and the method comprises: obtaining a plurality of incoming service traffics of a service subsystem of a first server, wherein the first server is a server with a load balancing function in the first subnet; obtaining configuration rules of the first server, wherein the configuration rules at least include: IP virtual server configuration rules and IP channel configuration rules, the IP virtual server configuration rules are used to define a corresponding relationship between an IP virtual server corresponding to the first server and a second server processing different types of service traffics, and the IP channel configuration rules are used to define IP channels between the first server and the second server; for each incoming service traffic, determining a type of the current incoming service traffic, and distributing the current incoming service traffic to a service subsystem of a corresponding second target server through a target IP channel according to the type and the configuration rules.

[0007] Optionally, the obtaining of the configuration rules of the first server comprises: in response to a cluster deployment instruction initiated by a target user, obtaining corresponding cluster configuration data, wherein the cluster configuration data at least includes: first configuration data used to reflect types of service traffics processed by each server in the cluster, and second configuration data used to reflect traffics to be load balanced, and the second configuration data is determined at least according to a destination IP address, a destination port and a service type of the traffics; and determining the configuration rules of the first server according to the cluster configuration data.

[0008] Optionally, the determining of the distribution of the current incoming service traffic to the service subsystem of the corresponding second target server through the target IP channel according to the type and the configuration rules comprises: determining the second target server with processing the type according to the type and the IP virtual server configuration rules, wherein the second server is in a different subnet from the first server; determining the target IP channel between the first server and the second target server according to the IP channel configuration rules; and distributing the incoming service traffic of the corresponding type to the service subsystem of the second target server according to the target IP channel.

[0009] Optionally, the method further comprises: monitoring running state data of the service subsystems of each second server, and determining running states of each service subsystem according to the running state data, wherein the type of the running state includes: a normal state or an abnormal state; and adjusting the IP virtual server configuration rules of the first server according to the running states of each service subsystem.

[0010] Optionally, the method further comprises: sharing the information of the shunting of the ingress service traffic of the service subsystem of the first server to the service subsystems of the second servers to a cluster deployment system in a second subnet in the cluster, wherein the second subnet is a subnet in the cluster other than the first subnet.

[0011] Optionally, the method further comprises: sharing the information of the shunting of the ingress service traffic of the service subsystem of the first server to the service subsystems of the second servers to a cluster deployment system in a second subnet in the cluster, wherein the second subnet is a subnet in the cluster other than the first subnet.

[0012] Optionally, the configuration rule further comprises: a virtual extended local area network tunnel rule, wherein the method further comprises: establishing at least one virtual extended local area network tunnel between the first server and a third server in the second subnet having a load balancing function according to the virtual extended local area network tunnel rule, and forming a network bridge by the at least one virtual extended local area network tunnel; and receiving a packet sent by any third server through the established virtual extended local area network tunnel, and synchronizing the packet to other third servers through the network bridge.

[0013] According to another aspect of the embodiments of the present application, a cluster deployment system is further provided, comprising: a system deployed in a first subnet in a cluster, wherein the cluster comprises a plurality of subnets, and the system comprises: a network management platform configured to obtain cluster configuration data corresponding to a cluster deployment instruction initiated by a target user; a network function management module configured to determine a configuration rule of a first server according to the cluster configuration data, wherein the configuration rule comprises at least: an IP virtual server configuration rule and an IP channel configuration rule, the IP virtual server configuration rule is used to define a corresponding relationship between an IP virtual server corresponding to the first server and a second server processing different types of service traffic, and the IP channel configuration rule is used to define an IP channel between the first server and the second server; and a load balancing module configured to obtain a plurality of ingress service traffics of a service subsystem of the first server, determine a type of a current ingress service traffic for each ingress service traffic, and distribute the current ingress service traffic to a service subsystem of a target second server through a target IP channel according to the type and the configuration rule.

[0014] Optionally, the system further comprises a storage module, wherein the storage module is configured to store cluster configuration data of a plurality of users, and the cluster configuration data comprises at least one of the following: first configuration data reflecting types of service traffic processed by each server in the cluster, and second configuration data reflecting traffic to be load balanced, wherein the second configuration data is determined according to at least a destination IP address, a destination port, and a service type of the traffic.

[0015] Optionally, the load balancing module is configured to, for each incoming service traffic, determine a type of the incoming service traffic, determine a second target server having a processing type corresponding to the type according to the type and the IP virtual server configuration rule, wherein the second server is in a different subnet from the first server, determine a target IP tunnel between the first server and the second target server according to the IP tunnel configuration rule, and distribute the incoming service traffic of the corresponding type to a service subsystem of the second target server according to the target IP tunnel.

[0016] Optionally, the load balancing module is further configured to share, to a load balancing module in a second subnet, shunting information of incoming service traffic of the service subsystem of the first server to service subsystems of a plurality of second servers, wherein the second subnet is a subnet other than the first subnet in the cluster.

[0017] Optionally, the load balancing module is further configured to monitor running state data of each service subsystem of the second servers, and determine a running state of each service subsystem according to the running state data, wherein the running state comprises a normal state or an abnormal state, and adjust the IP virtual server configuration rule of the first server according to the running state of each service subsystem, including: in a case where a running state of a target service subsystem is the normal state, retaining a second server corresponding to the target service subsystem in the IP virtual server configuration rule; and in a case where the running state of the target service subsystem is the abnormal state, deleting the second server corresponding to the target service subsystem in the IP virtual server configuration rule.

[0018] Optionally, the system further comprises a running monitoring module, wherein the running monitoring module is configured to acquire running states of the service subsystems of the first server and the plurality of second servers reported by the load balancing module, and feed back corresponding alarm prompt information to a network management platform when a running state of any service subsystem is a fault state, wherein the alarm prompt information is used to prompt that the running state of the service subsystem is abnormal.

[0019] Optionally, the configuration rule further comprises a virtual extended local area network tunnel rule, wherein the load balancing module is further configured to establish at least one virtual extended local area network tunnel with the load balancing module in the at least one second subnet according to the virtual extended local area network tunnel rule, and form a bridge by using the at least one virtual extended local area network tunnel; and receive a packet sent by the load balancing module in any second subnet through the established virtual extended local area network tunnel, and synchronize the packet to the load balancing module in a third subnet through the bridge, wherein the third subnet is a plurality of second subnets in the cluster except the current second subnet.

[0020] According to another aspect of the embodiments of the present application, an electronic device is further provided, which comprises a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the cluster deployment method by using the computer program.

[0021] In the embodiments of the present application, the cluster deployment system deployed in each subnet in the cluster is used to perform the following steps: obtaining ingress service traffic of a service subsystem of a first server with load balancing function in the subnet; obtaining configuration rules of the first server, wherein the configuration rules at least comprise IP virtual server configuration rules and IP channel configuration rules, the IP virtual server configuration rules are used to define the corresponding relationship between an IP virtual server corresponding to the first server and a second server processing different types of service traffic, and the IP channel configuration rules are used to define IP channels between the first server and the second server; for each ingress service traffic, determining the type of the current ingress service traffic, and determining the target IP channel through which the current ingress service traffic is distributed to the service subsystem of the corresponding second target server according to the type and the configuration rules. Thus, the technical problem that the cluster deployed by using the direct routing mode cannot realize access in different three-layer domains is solved. BRIEF DESCRIPTION OF DRAWINGS

[0022] The accompanying drawings, which are included to provide a further understanding of the present application and are incorporated in and constitute a part of this application, illustrate embodiments of the present application and serve to explain the present application. In the drawings:

[0023] Figure 1 is a schematic diagram of a cluster deployment architecture according to the related art;

[0024] Figure 2 is a schematic diagram of deployment of an optional cluster deployment system according to an embodiment of the present application in a cluster;

[0025] Figure 3 is a schematic diagram of an architecture of an optional cluster deployment system according to an embodiment of the present application;

[0026] Figure 4 is a flow diagram of an optional cluster deployment method according to an embodiment of the present application;

[0027] Figure 5 is a structural diagram of an optional electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0028] In order to make the personnel in the art better understand the scheme of the present application, the technical scheme in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor should fall within the scope of protection of the present application.

[0029] It should be noted that the terms "first", "second", and the like in the specification and claims of the present application and the above-described drawings are used to distinguish similar objects, and do not necessarily have to describe a specific order or sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device that includes a series of steps or units does not have to be limited to only those steps or units clearly listed, but can include other steps or units that are not clearly listed or inherent to the process, method, product or device.

[0030] In addition, the relevant information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for display, analyzed data, etc.) involved in the present application are all information and data authorized by the user or authorized by all parties. For example, an interface is provided between the system and the relevant user or institution. Before obtaining the relevant information, the interface needs to send a request for obtaining to the aforementioned user or institution, and after receiving the consent information fed back by the aforementioned user or institution, the relevant information is obtained.

[0031] In order to better understand the embodiments of the present application, the technical terms involved in the embodiments of the present application are explained as follows:

[0032] C-IWF (Customized-Inter Working Function, signaling interworking gateway): as an inward device, it is used to realize the interworking and fusion between different types of networks. Generally, it can be used to interconnect mobile networks and fixed networks, so as to transmit data and signaling between mobile networks and fixed networks.

[0033] IPVS (IP Virtual Server): It is a technology running under LVS (Linux Virtual Server) to provide load balancing function. When the initial message of a TCP connection arrives, IPVS can select a server and forward the message to the server, and thereafter ensure the subsequent messages of the connection are forwarded to the same server by checking the IP and TCP message header address of the message.

[0034] IP (Internet Protocol): It is a network layer protocol in TCP / IP system. The purpose of designing IP is to improve the scalability of network: one is to solve the Internet problem and realize the interconnection and intercommunication of large-scale and heterogeneous networks; the other is to separate the coupling relationship between top network application and bottom network technology to take advantage of independent development of both. According to the end-to-end design principle, IP only provides a connectionless, unreliable and best-effort packet transmission service for hosts.

[0035] VXLAN (Virtual eXtensible Local Area Network): It is a network virtualization technology that can improve the expansion problem of large-scale cloud computing in deployment, and is an extension of VLAN. As a powerful tool, VXLAN can penetrate the three-layer network to expand the two-layer network, and it can solve the portability limitation of VMS (Virtual Memory System) by encapsulating traffic and expanding it to the third layer network, so as to access servers on external IP subnets.

[0036] IP tunnel: It refers to a channel that can use network protocols to communicate between two networks. In the channel, the data packets of other network protocols are first encapsulated, and then the information is transmitted. Usually, it is used to deploy IP networks connected directly by routing. IP tunnel can be constructed by underlying routing protocols to build intermediate transmission networks.

[0037] LB (Loading Balance): It is built on the existing network to provide a distribution to expand the bandwidth of network devices and servers, increase throughput, enhance network data processing capacity, improve network flexibility and availability.

[0038] EOR (End of Row) is the most traditional data center access switch integration method, in which an access switch is arranged in the end of a row of cabinets (switch cabinets) in the cabinet, and the hosts, servers and minicomputers in the equipment cabinet are connected by horizontal cables through permanent links.

[0039] TOR (Top of Row), also known as top-of-rack (TOR), is an extension of the End-of-Rack (EOR) approach. In TOR, one or two access switches are deployed above each server cabinet in a POD (Public Layout) (POD). Rack servers are connected to the cabinets via patch cables. The uplink ports on the switches are connected to aggregation switches or core switches in the EOR network cabinets via copper or fiber cables.

[0040] ZeroMQ (also known as MQ or zmq): is similar to the standard Berkeley socket, which provides various transmission tools, such as sockets for atomic message transmission within the process, between processes, TCP (Transmission Control Protocol) and multicast, and ZeroMQ can use various modes to implement N to N socket connections. These modes include: fan-out, publish-subscribe, task allocation, request-reply, etc.

[0041] Example 1

[0042] In related art, Figure 1 This is a schematic diagram of a cluster deployment architecture based on related technologies, such as Figure 1 As shown. The large network elements composed of UDM (Unified Data Management), SMF (Service Management Function), and AMF (Access and Mobility Management Function) and the private network elements composed of UPF (User Plane Function) 1, UPF2 (which meets different business requirements from UPF1) and SMF can be divided into four groups of TOR11, TOR12, TOR21, and TOR22 through EOR (End of Row), and each TOR group includes multiple servers, such as TOR11 includes server 1, server 2, ..., server 15. By Figure 1 After analysis, it is not difficult to see that this cluster deployment architecture has the following drawbacks:

[0043] (1) IPVS rules are configured on Server 2 and Server 15 with load balancing functions in the same subnet (i.e., the same TOR group). Both Server 2 and Server 15 use DR (Direct Routing) mode. When using IPVS technology to divert the service inbound traffic of their service subsystems, the traffic can only be diverted to Service Subsystem 1, Service Subsystem 2, ..., Service Subsystem 15 in the same subnet in the same Layer 2 domain, and traffic cannot be distributed across subnets or TORs.

[0044] (2) The synchronization session of the IPVS is limited to the servers 2 and 15 with load balancing function in the same subnet (i.e. the same group of TORs);

[0045] (2) The IPVS rule configuration needs to be manually configured and issued one by one, which leads to complicated configuration process, and there is no fault monitoring function in the whole system. Once the system fails, it is difficult to quickly identify the faulty business subsystem in the cluster.

[0046] To solve the above problems, the related solutions are provided in the embodiments of the present application, which are described in detail below. It should be noted that the technical solutions of the embodiments of the present application can be applied to various communication systems, such as Global System of Mobile communication (GSM) system, Code Division Multiple Access (CDMA) system, Wideband Code Division Multiple Access (WCDMA) system, General Packet Radio Service (GPRS), Long Term Evolution (LTE) system, LTE Frequency Division Duplex (FDD) system, LTE Time Division Duplex (TDD), Universal Mobile Telecommunication System (UMTS), Worldwide Interoperability for Microwave Access (WiMAX) communication system or 5G system, etc.

[0047] For example, the cluster deployment system provided by the present application can be deployed in a cluster with multiple subnets (i.e. different TORs). The specific deployment manner can be referred to Figure 2 , and the cluster deployment system is deployed in servers 2 and 17 with load balancing function, and the servers 2 and 17 are in different groups of TORs.

[0048] Specifically, for the cluster deployment system 30 in a single first subnet (which can be any subnet in the cluster), the specific architecture diagram is as shown in Figure 3 , which includes a network management platform 31, a network function management module 32, and a load balancing module 33, and the load balancing module 33 is deployed in a first server with load balancing function in the cluster. Specifically, the network management platform 31 is configured to:

[0049] The network management platform 31 can obtain the corresponding cluster configuration data in response to the cluster deployment instruction initiated by the target user.

[0050] The network function management module 32 can determine the configuration rule of the first server according to the cluster configuration data, wherein the configuration rule at least includes: IP virtual server (IPVS for short) configuration rule and IP channel configuration rule, and the IP virtual server configuration rule is used to define the corresponding relationship between the IP virtual server corresponding to the first server and the second server processing different types of traffic, and the IP channel configuration rule is used to define the IP channel between the first server and the second server.

[0051] The load balancing module 33 can obtain a plurality of incoming traffic of the service subsystem of the first server; for each incoming traffic, determine the type of the current incoming traffic, and according to the type and the configuration rule, distribute the current incoming traffic to the service subsystem of the corresponding second target server through the target IP channel.

[0052] It should be noted that the above Figure 3 The system shown in the figure is only a schematic, and does not limit the structure of the system, and the cluster deployment system can include but is not limited to Figure 3 The components shown in the figure.

[0053] The functions and interaction processes of each module in the cluster deployment system 30 will be described in detail in combination with the specific implementation process.

[0054] Specifically, when the user triggers the cluster deployment instruction in the network management platform 31 in the first subnet, and the network management platform 31 obtains the cluster configuration data of the user, in order to save the cluster configuration data set by different users, the cluster deployment system 30 in the present application further includes a storage module 34 for storing the cluster configuration data of a plurality of users.

[0055] Among them, the cluster configuration data of each user includes at least one of the following: the first configuration data for reflecting the type of traffic processed by each server in the cluster (it can be understood that: the configuration server supports processing traffic of different business types), and the second configuration data for reflecting the traffic to be load balanced (it can be understood as: configure the traffic that needs to be load shared), and the second configuration data is determined at least according to the destination IP address, destination port and business type of the traffic.

[0056] As an optional implementation, the IP virtual server corresponding to the first server and the second server processing different types of traffic are defined in advance in the IP virtual server configuration rule (i.e., the IP virtual server corresponding to the first server is defined to correspond to a plurality of real servers, and the type of traffic processed by each real server is defined); and the IP channel configuration rule is used to define the IP channel between the first server and each second server. Then, after the load balancing module 33 periodically acquires a plurality of incoming traffic of the service subsystem of the first server, for each incoming traffic, the following method can be used to distribute it:

[0057] First step: determine the type of the incoming traffic; determine the second target server with the type according to the type and the IP virtual server configuration rule, wherein the second server is in a different subnet from the first server;

[0058] Second step: determine the target IP channel between the first server and the second target server according to the IP channel configuration rule;

[0059] Third step: distribute the incoming traffic of the corresponding type to the service subsystem of the second target server according to the target IP channel.

[0060] For example, if the load balancing module 33 monitors the type of the incoming traffic of the service subsystem of the first server at the current time to be A, and determines that the real server (i.e., the second target server) corresponding to the IP virtual server of the first server and processing the type A of the incoming traffic is B through the IP virtual server configuration rule, and determines that the IP channel between the first server and the second server is IP channel C through the IP channel configuration rule, then in the load balancing stage, the type A of the incoming traffic can be transmitted to the service subsystem of the real server B through the IP channel C.

[0061] Through the above distribution process, the specification limitation that the high-availability cluster deployed by the related art using the IPVSDR mode can only distribute the incoming traffic to the service subsystems in the same two-layer domain and under the same group of TORs, and cannot realize cross-subnet TOR distribution, is solved.

[0062] Optionally, the load balancing module 33 can also share the distribution information of the incoming traffic of the service subsystem of the first server to the service subsystems of a plurality of second servers (i.e., to which service subsystems of the second servers the incoming traffic is distributed) to the load balancing modules in other subnets.

[0063] Further, in order to ensure that the load balancing module 33 distributes the ingress traffic of the service subsystem of the first server where the load balancing module 33 is located to the service subsystem of the server in the other subnet which can operate normally, the load balancing module 33 can also monitor the operation state data of each service subsystem of the second server, and determine the operation state of each service subsystem according to the operation state data, wherein the type of the operation state includes: normal state or abnormal state; and adjust the IP virtual server configuration rule of the first server according to the operation state of each service subsystem.

[0064] Specifically, the load balancing module 33 can request the corresponding operation state data of the service subsystem of the second server based on ZeroMQ, so as to monitor the operation state data of the service subsystem of the second server which processes the ingress traffic of the service subsystem of the first server, and determine the operation state of each service subsystem according to the operation state data of each service subsystem; and then adjust the IP virtual server configuration rule of the first server according to the operation state of each service subsystem.

[0065] Optionally, the load balancing module 33 can dynamically adjust the IP virtual server configuration rule of the first server according to the following adjustment strategy, which includes:

[0066] In the case that the operation state of the target service subsystem is normal state, the second server corresponding to the target service subsystem in the IP virtual server configuration rule is reserved;

[0067] In the case that the operation state of the target service subsystem is abnormal state, the second server corresponding to the target service subsystem in the IP virtual server configuration rule is deleted.

[0068] The above adjustment strategy can be understood as follows: if the service subsystem of the second server which processes a certain type of traffic of the service subsystem of the first server is abnormal (i.e. unhealthy), it means that the service subsystem cannot normally process the traffic of this type, and therefore, the traffic of this type should not be distributed to the abnormal service subsystem. Therefore, in this case, the load balancing module 33 can delete the second server corresponding to the abnormal service subsystem in the IP virtual server configuration rule of the first server, so that the abnormal service subsystem can no longer continue to receive traffic; on the contrary, if the service subsystem of the second server which processes a certain type of traffic of the service subsystem of the first server is normal, it is continued to be reserved. The purpose of this is to ensure that each type of ingress traffic of the service subsystem of the first server is always routed to the service subsystem of the real server which can normally process, so as to realize fast and automatic switching in case of failure, and improve the availability and responsiveness of the cluster.

[0069] For example, assuming that the IP virtual servers defined in the IP virtual server configuration rule of the first server correspond to real servers that process the same traffic type, where Server 1, Server 2, and Server 3 can all process A-class traffic. Then, when the type of the inbound traffic of the service subsystem of the first server is A-class, but the load balancing module 33 of the first server monitors that the service subsystems of Server 1 and Server 2 are both in an abnormal state, in order to ensure that the A-class traffic can be routed to the service subsystem of Server 3 that can normally process, the corresponding relationship between the IP virtual servers and Server 1 and Server 2 previously defined in the IP virtual server configuration rule can be deleted, and the corresponding relationship between the IP virtual servers and Server 3 is retained, so as to update the IP virtual server configuration rule.

[0070] In addition, in order to enable the related technical personnel to know the faulty service subsystems in the subnet in real time and troubleshoot the faults in time, the cluster deployment system in the present application further includes a running monitoring module 35 that can acquire the running states of the service subsystems of the first server and the plurality of second servers reported by the load balancing module 33; when the running state of any service subsystem is a fault state, the corresponding alarm prompt information is fed back to the network management platform 31, where the alarm prompt information is used to prompt that the running state of the service subsystem is abnormal. Thus, the target user can quickly locate and process the faulty service subsystem in time through the network management platform 31, thereby solving the technical problem that the high-availability cluster deployed in the related art cannot troubleshoot system faults in time, resulting in difficult and time-consuming troubleshooting.

[0071] As an optional implementation, in order to solve the problem that the IPVS synchronization session of the high-availability cluster deployed in the related art is limited in the same Layer 2 domain, the network function management module 32 in the embodiment of the present application can further generate a corresponding virtual extended local area network (VXLAN) tunnel rule according to the cluster configuration data, and issue the rule to the load balancing module 33.

[0072] The load balancing module 33 can build at least one virtual extended local area network tunnel according to the virtual extended local area network tunnel rule and the load balancing modules in the second subnet, and form a bridge with the at least one virtual extended local area network tunnel.

[0073] That is, the load balancing module 33 in the first subnet can act as a control node, and build at least one virtual extended local area network tunnel according to a virtual extended local area network tunnel rule and other load balancing modules (i.e., load balancing modules in at least one second subnet) in different subnets, wherein one end of the virtual extended local area network tunnel is a VETP port (VXLAN Tunnel Endpoints, VXLAN Tunnel Endpoints) of the control node, and the other end is a VETP port of the other load balancing modules in different subnets. Then, the control node binds all the virtual extended local area network tunnels into a bridge.

[0074] Further, the load balancing module 33 can receive the message sent by the load balancing module in any second subnet through the built virtual extended local area network tunnel, and synchronize the message to the load balancing module in the third subnet through the bridge.

[0075] It can be understood that when the load balancing module (i.e., the initiator node) in the other subnet performs an IPVS synchronization session through the virtual extended local area network tunnel between it and the control node, the load balancing module 33 in the first subnet can first receive the message sent by the initiator node, and then flood the message to other virtual extended local area network tunnels in the bridge to synchronize to the load balancing modules in the other subnets (i.e., the third subnet) other than the initiator node, wherein the third subnet is the other subnets in the multiple second subnets in the cluster except the current second subnet (i.e., the subnet where the initiator node is located).

[0076] In the above cluster deployment system, the IPVS IP tunnel mode is used to optimize Figure 1 The IPVSDR mode is used, IP channels and VXLAN tunnels are used in the cluster, and the network management platform 31, the network function management module 32, the load balancing module 33, the storage module 34, and the operation monitoring module 35 are introduced, so as to realize rapid deployment of high-specification clusters, solve the problem that the high-availability cluster deployed by the related technology in the IPVSDR mode cannot be accessed in different three-layer domains and cannot synchronize sessions in different two-layer domains. At the same time, the cluster deployed by the present application can realize rapid automatic switching of faults and efficient and fast operation and maintenance.

[0077] Embodiment 2

[0078] In the above running environment, the present application further provides an embodiment of a cluster deployment method applied to a cluster deployment system deployed in a first subnet in a cluster, and the cluster includes multiple subnets, and the first subnet can be any one of the multiple subnets. Wherein, Figure 4 is a flowchart of an optional cluster deployment method according to an embodiment of the present application, as Figure 4 shown, the method at least includes steps S402-S406, wherein:

[0079] In step S402, a plurality of incoming service traffics of the service subsystem of the first server are acquired.

[0080] In the technical solution provided in step S402, the load balancing module in the cluster deployment system deployed in the first subnet can periodically acquire the incoming service traffics of the service subsystem of the first server to obtain a plurality of incoming service traffics, and the types of each incoming service traffic can be the same or different. In addition, the first server is a server with load balancing function in the first subnet.

[0081] In step S404, a configuration rule of the first server is obtained.

[0082] In the technical solution provided in step S404, the configuration rule at least includes: an IP virtual server (IPVS) configuration rule and an IP channel configuration rule. The IP virtual server configuration rule is used to define the corresponding relationship between the IP virtual server corresponding to the first server and the second server processing different types of service traffics, and the IP channel configuration rule is used to define the IP channel between the first server and the second server.

[0083] In step S406, for each incoming service traffic, the type of the current incoming service traffic is determined, and the current incoming service traffic is distributed to the service subsystem of the corresponding second target server through the target IP channel according to the type and the configuration rule.

[0084] In the technical solution provided in step S406, for each incoming service traffic of the service subsystem of the first server, the load balancing module in the cluster deployment system deployed in the first subnet can determine the type of the current incoming service traffic, and distribute the current incoming service traffic to the service subsystem of the corresponding second target server through the target IP channel according to the type and the configuration rule.

[0085] The above method of the embodiment will be further introduced.

[0086] As an optional implementation, in the technical solution provided in step S404, the method can include:

[0087] In step S4041, in response to the cluster deployment instruction initiated by the target user, the corresponding cluster configuration data is acquired, wherein the cluster configuration data includes at least one of the following: first configuration data for reflecting the type of service traffic processed by each server in the cluster, and second configuration data for reflecting the traffic to be load balanced, and the second configuration data is determined at least according to the destination IP address, the destination port and the service type of the traffic;

[0088] Step S4042, determining the configuration rule of the first server according to the cluster configuration data.

[0089] In the above embodiment, each module in the cluster deployment system deployed in the first subnet can obtain the configuration rule of the first server through the following interaction process: first, the network management platform responds to the cluster deployment instruction of the target user, and acquires the cluster configuration data configured by the target user according to the action triggered by the target user on the network management platform, and then the network function management module determines the configuration rule configured by the target user for the first server according to the cluster configuration data, and delivers the configured rule to the load balancing module.

[0090] As an optional implementation, in the technical solution provided in the above step S406, the method can comprise:

[0091] Step S4061, determining a second target server with a processing type according to the type and the IP virtual server configuration rule, wherein the second server is in a different subnet from the first server;

[0092] Step S4062, determining a target IP channel between the first server and the second target server according to the IP channel configuration rule;

[0093] Step S4063, distributing the incoming service traffic of the corresponding type to the service subsystem of the second target server according to the target IP channel.

[0094] For example, if the load balancing module in the cluster deployment system deployed in the first subnet monitors that the type of the incoming service traffic of the service subsystem of the first server is A at the current time, and determines that the real server (i.e., the second target server) corresponding to the IP virtual server of the first server and having the processing type A of the incoming service traffic is B through the IP virtual server configuration rule, and determines that the IP channel between the first server and the second server is IP channel C through the IP channel configuration rule, then in the load balancing stage, the incoming service traffic of type A can be transmitted to the service subsystem of the real server B through the IP channel C.

[0095] Through the above shunting process, the cluster deployment system deployed in the first subnet can solve the specification limitation that the high-availability cluster deployed by the related art using the IPVSDR mode can only be distributed to the service subsystem under the same group of TORs in the same layer 2 domain, and cannot realize cross-subnet TOR traffic distribution.

[0096] Optionally, the load balancing module in the cluster deployment system in the first subnet can also share the shunting information of the ingress traffic of the service subsystem of the first server to the service subsystems of the plurality of second servers (i.e., to which service subsystems of the second servers the ingress traffic is shunted) to the load balancing modules in the cluster deployment systems in the plurality of second subnets, wherein the second subnets are the other subnets in the cluster except the first subnet.

[0097] Further, in order to ensure that the ingress traffic of the service subsystem of the first server can be distributed to the service subsystems of the servers in the other subnets which can operate normally, the load balancing module in the cluster deployment system deployed in the first subnet can also monitor the operation state data of each service subsystem of the second server, and determine the operation state of each service subsystem according to the operation state data, wherein the types of the operation state include: normal state or abnormal state; and adjust the IP virtual server configuration rule of the first server according to the operation state of each service subsystem.

[0098] Specifically, the load balancing module can realize the second server's service subsystem's regular request reply corresponding operation state data based on ZeroMQ, so as to realize the monitoring of the operation state data of the plurality of second servers' service subsystems which process the ingress traffic of the first server's service subsystem, to determine the corresponding operation state according to the operation state data of each service system; and then adjust the IP virtual server configuration rule of the first server according to the operation state of each service subsystem.

[0099] Optionally, the load balancing module can dynamically adjust the IP virtual server configuration rule of the first server according to the following adjustment strategy, including:

[0100] In the case that the operation state of the target service subsystem is normal state, the second server corresponding to the target service subsystem in the IP virtual server configuration rule is retained;

[0101] In the case that the operation state of the target service subsystem is abnormal state, the second server corresponding to the target service subsystem in the IP virtual server configuration rule is deleted.

[0102] The adjustment strategy can be understood as follows: if the service subsystem of the second server that processes the certain type of service traffic of the service subsystem of the first server is abnormal (i.e., unhealthy), it indicates that the service subsystem cannot normally process the certain type of service traffic, and therefore, the certain type of service traffic should not be distributed to the abnormal service subsystem. Therefore, in this case, the load balancing module can delete the second server corresponding to the abnormal service subsystem that is pre-configured in the IP virtual server configuration rule of the first server, so that the abnormal service subsystem can no longer continue to receive traffic. Conversely, if the service subsystem of the second server that processes the certain type of service traffic of the service subsystem of the first server is normal, it is continued to be retained. The purpose of this is to ensure that each type of incoming service traffic of the service subsystem of the first server is always routed to the service subsystem of the real server that can normally process it, thereby realizing fast automatic switching in case of failure to improve the availability and responsiveness of the cluster.

[0103] As an optional implementation, in order to solve the problem that the IPVS synchronization session of the high-availability cluster deployed in the related art is limited within the same Layer 2 domain, the network function management module in the cluster deployment system deployed in the first subnet can also generate a corresponding virtual extended local area network (VXLAN) tunnel rule according to the cluster configuration data, and deliver the rule to the load balancing module.

[0104] The load balancing module in the cluster deployment system deployed in the first subnet can build at least one virtual extended local area network tunnel between the first server and the third server with load balancing function in the second subnet according to the virtual extended local area network tunnel rule, and form a bridge by the at least one virtual extended local area network tunnel.

[0105] That is, the load balancing module as a control node builds at least one virtual extended local area network tunnel according to the virtual extended local area network tunnel rule and other load balancing modules (i.e., load balancing modules in at least one second subnet) in different subnets, and one end of the virtual extended local area network tunnel (VXLAN Tunnel Endpoint, VETP) is the control node, and the other end is the other load balancing module in different subnets. Then, the control node binds all the virtual extended local area network tunnels into a bridge.

[0106] Further, the load balancing module can receive the packet sent by the load balancing module in any second subnet through the built virtual extended local area network tunnel, and synchronize the packet to the load balancing module in the third subnet through the bridge.

[0107] It can be understood that when the load balancing module in other subnets (i.e., the initiating node) performs an IPVS synchronization session through a virtual extended local area network tunnel between the load balancing module and the control node, the load balancing module in the first subnet can first receive the message sent by the initiating node, and then flood the message to other virtual extended local area network tunnels in the bridge through the bridge, to synchronize to the load balancing module in other subnets (i.e., the third subnet) other than the initiating node, wherein the third subnet is a plurality of second subnets in the cluster except the current second subnet (i.e., the subnet where the initiating node is located).

[0108] Based on the scheme defined in steps S402 to S406, it can be known that in the embodiment, the cluster deployment system deployed in the first subnet can use the IPVS IP tunnel mode optimization Figure 1 The IPVSDR mode used solves the problem that the high-availability cluster deployed by the related art in the IPVSDR mode cannot be accessed in different three-layer domains; meanwhile, a load balancing module in an optional LB server in different subnets is selected as a control node to build IPVS tunnels with LB servers in other subnets, and the control node binds these IPVS tunnels into a bridge, so that when the LB server in any subnet performs an IPVS session synchronization, the LB server in the subnet can send the synchronization message to the control node first, and the control node floods the synchronization message to other IPVS tunnels in the bridge through the bridge, to synchronize the synchronization message to the corresponding LB server, thereby solving the problem that the sessions cannot be synchronized in different two-layer domains.

[0109] Embodiment 3

[0110] According to the embodiments of the present application, an electronic device is also provided, wherein Figure 5 is a structural schematic diagram of an optional electronic device according to the embodiments of the present application, as Figure 5 shown, the electronic device includes one or more processors; a memory for storing one or more programs, when the one or more programs are executed by the one or more processors, the one or more processors are caused to implement a program for running, wherein the program is set to execute the cluster deployment method in the above-mentioned embodiment 2 when running.

[0111] Optionally, the processor is configured to implement the following steps by computer program execution: obtaining a plurality of incoming service traffics of a service subsystem of the first server, wherein the first server is a server with load balancing function in the first subnet; obtaining configuration rules of the first server, wherein the configuration rules at least include: IP virtual server configuration rules and IP channel configuration rules, the IP virtual server configuration rules are used to define the corresponding relationship between the IP virtual server corresponding to the first server and the second server processing different types of service traffics, and the IP channel configuration rules are used to define the IP channel between the first server and the second server; for each incoming service traffic, determining the type of the current incoming service traffic, and determining the target IP channel through which the current incoming service traffic is distributed to the service subsystem of the corresponding second target server according to the type and the configuration rules.

[0112] The above sequence numbers of the embodiments of the present application are only for description, and do not represent the advantages and disadvantages of the embodiments.

[0113] In the above embodiments of the present application, the description of each embodiment has its own focus, and the parts not described in detail in a certain embodiment can be referred to the related description of other embodiments.

[0114] In the several embodiments of the present application, it should be understood that the disclosed technology can be implemented in other ways. Of course, the unit embodiment described above is only schematic. For example, the division of the units can be a logical function division, and there can be another division manner in actual implementation, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections between the units can be indirect couplings or communication connections through some interfaces, units or modules, and can be electrical or other forms.

[0115] The units described as separate components can or can not be physically separate, and the components displayed as units can or can not be physical units, that is, they can be located in one place, or can be distributed on a plurality of units. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiment scheme.

[0116] In addition, each functional unit in each embodiment of the present application can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit. The above integrated unit can be realized in the form of hardware, or in the form of software functional unit.

[0117] The integrated unit, if implemented in the form of a software function unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application or the part that essentially contributes to the related art or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server or a network device, etc.) to execute all or part of the steps of the method described in the embodiments of the present application. The aforementioned storage medium includes a U disk, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and various media that can store program codes.

[0118] The above only describes the preferred embodiments of the present application. It should be noted that, for those skilled in the art, without departing from the principles of the present application, a number of improvements and refinements can be made, which should also be considered as the protection scope of the present application.

Claims

1. A cluster deployment method, characterized by, The application is applied to a cluster deployment system deployed in a first subnet in a cluster, and the cluster comprises a plurality of subnets, comprising: acquiring a plurality of incoming traffic flows of a service subsystem of a first server, wherein the first server is a server with a load balancing function in the first subnet; acquiring configuration rules of the first server, comprising: in response to a cluster deployment instruction initiated by a target user, acquiring corresponding cluster configuration data, wherein the cluster configuration data comprises: first configuration data for reflecting types of traffic processed by each server in the cluster, and second configuration data for reflecting traffic to be load balanced, and the second configuration data is determined at least according to a destination IP address, a destination port and a service type of the traffic; determining the configuration rules of the first server according to the cluster configuration data, wherein the configuration rules at least comprise: Internet Protocol (IP) virtual server configuration rules and IP channel configuration rules, the IP virtual server configuration rules are used to define a corresponding relationship between an IP virtual server corresponding to the first server and a second server processing different types of traffic, and the IP channel configuration rules are used to define an IP channel between the first server and the second server; for each of the incoming traffic flows, determining a type of the current incoming traffic flow, and determining, according to the type and the configuration rules, that the current incoming traffic flow is distributed to a service subsystem of a corresponding second target server through a target IP channel, comprising: determining, according to the type and the IP virtual server configuration rules, a second target server with processing the type; determining a target IP channel between the first server and the second target server according to the IP channel configuration rules; and distributing the incoming traffic flow of the corresponding type to the service subsystem of the second target server according to the target IP channel.

2. The method of claim 1, wherein, The method further comprises: monitoring running state data of each service subsystem of the second server, and determining a running state of each service subsystem according to the running state data, wherein the type of the running state comprises: a normal state or an abnormal state; adjusting the IP virtual server configuration rules of the first server according to the running state of each service subsystem.

3. The method of claim 2, wherein, Adjusting the IP virtual server configuration rules of the first server according to the running state of each service subsystem, comprising: in the case that the running state of a target service subsystem is a normal state, retaining a second server corresponding to the target service subsystem in the IP virtual server configuration rules; in the case that the running state of a target service subsystem is an abnormal state, deleting the second server corresponding to the target service subsystem in the IP virtual server configuration rules.

4. The method of claim 1, wherein, The method further comprises: The shunting information of the in-bound service traffic of the service subsystem of the first server to the service subsystems of the plurality of second servers is shared to a cluster deployment system within a plurality of second subnets, wherein the second subnets are subnets within the cluster other than the first subnet.

5. The method of claim 1, wherein, The configuration rule further comprises a virtual extended local area network tunnel rule, and the method further comprises: at least one virtual extended local area network tunnel is built between the first server and a third server with load balancing function within the second subnet according to the virtual extended local area network tunnel rule, and a bridge is formed by the at least one virtual extended local area network tunnel; when receiving a packet sent by any third server through the built virtual extended local area network tunnel, the packet is synchronized to other third servers through the bridge.

6. A cluster deployment system, characterized by The system is deployed in a first subnet within a cluster, the cluster comprises a plurality of subnets, and the system comprises a network management platform, a network function management module and a load balancing module, wherein the load balancing module is deployed on a first server with load balancing function within the first subnet. The network management platform is configured to obtain corresponding cluster configuration data in response to a cluster deployment instruction initiated by a target user, wherein the cluster configuration data comprises first configuration data reflecting types of service traffic processed by each server within the cluster and second configuration data reflecting traffic to be load balanced, and the second configuration data is determined at least according to a destination IP address, a destination port and a service type of the traffic. The network function management module is configured to determine a configuration rule of the first server according to the cluster configuration data, wherein the configuration rule comprises at least an IP virtual server configuration rule and an IP channel configuration rule, the IP virtual server configuration rule is used to define a corresponding relationship between an IP virtual server corresponding to the first server and a second server processing different types of service traffic, and the IP channel configuration rule is used to define an IP channel between the first server and the second server. The load balancing module is configured to obtain a plurality of in-bound service traffic of a service subsystem of the first server, determine a type of a current in-bound service traffic for each in-bound service traffic, and distribute the current in-bound service traffic to a service subsystem of a corresponding second target server through a target IP channel according to the type and the configuration rule, comprising: determining a second target server with processing function corresponding to the type according to the type and the IP virtual server configuration rule, wherein the second target server is in a different subnet from the first server; determining a target IP channel between the first server and the second target server according to the IP channel configuration rule; and distributing the in-bound service traffic of the corresponding type to the service subsystem of the second target server according to the target IP channel.

7. The system of claim 6, wherein, The system further comprises a storage module, wherein The storage module is configured to store cluster configuration data of a plurality of users.

8. The system of claim 6, wherein, In the system, the network management platform is configured to obtain the cluster configuration data of the plurality of users from the storage module. The load balancing module is further configured to share the shunting information of the incoming traffic of the service subsystem of the first server to the service subsystems of the plurality of second servers to the load balancing modules in a plurality of second subnets, wherein the second subnets are subnets in the cluster other than the first subnet.

9. The system of claim 6, wherein, The load balancing module is further configured to monitor running state data of each service subsystem of the second servers, and determine a running state of each service subsystem according to the running state data, wherein the running state includes a normal state or an abnormal state; and adjust the IP virtual server configuration rule of the first server according to the running state of each service subsystem, including: in a case where a running state of a target service subsystem is the normal state, retaining the second server corresponding to the target service subsystem in the IP virtual server configuration rule; and in a case where the running state of the target service subsystem is the abnormal state, deleting the second server corresponding to the target service subsystem in the IP virtual server configuration rule.

10. The system of claim 7, wherein, The system further comprises a running monitoring module, wherein, The running monitoring module is configured to acquire the running states of the service subsystems of the first server and the second servers reported by the load balancing module, and feed back corresponding alarm prompt information to the network management platform when a running state of any service subsystem is a fault state, wherein the alarm prompt information is used to prompt that the running state of the service subsystem is abnormal.

11. The system of claim 6, wherein, The configuration rule further comprises a virtual extended local area network tunnel rule, wherein, The load balancing module is further configured to build at least one virtual extended local area network tunnel according to the virtual extended local area network tunnel rule and the load balancing modules in at least one second subnet, and form a bridge by using the at least one virtual extended local area network tunnel; receive a packet sent by the load balancing module in any second subnet through the built virtual extended local area network tunnel, and synchronize the packet to the load balancing module in a third subnet through the bridge, wherein the third subnet is a subnet in the cluster other than the current second subnet.

12. An electronic device, comprising: The system comprises: a memory and a processor, wherein the processor is configured to run a program stored in the memory, and the program performs the cluster deployment method in any one of claims 1 to 5 when running. The system comprises: a memory and a processor, wherein the processor is configured to run a program stored in the memory, and the program performs the cluster deployment method in any one of claims 1 to 5 when running.

Citation Information

Patent Citations

  • Data service system and method, server and computer readable storage medium

    CN108512935A

  • Data distribution method and related product

    CN109800204A