Cluster deployment method and system and electronic equipment

By obtaining the business traffic type and distributing it across subnets through the load balancing module within the cluster, combined with virtual extended LAN tunnels and server status monitoring, the problem of the cluster being inaccessible in different Layer 3 domains was solved, achieving efficient load balancing and rapid fault handling.

CN119299360AActive Publication Date: 2025-01-10CHINA TELECOM INTELLIGENT NETWORK TECHNOLOGY CO LTD
View PDF 4 Cites 0 Cited by

Patent Information

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

AI Technical Summary

Technical Problem

In existing technologies, clusters deployed using direct routing cannot access each other across different Layer 3 domains, causing load balancers to operate only within the same subnet and unable to cross Layer 3 networks.

Method used

The system obtains the type of business traffic by the load balancing module within the cluster, and distributes the traffic to servers in different subnets according to the IP virtual server and IP tunnel configuration rules. It uses virtual extended LAN tunnels to achieve cross-subnet traffic distribution and monitors server status for dynamic adjustments.

Benefits of technology

It achieves cross-subnet load balancing, improves cluster availability and responsiveness, enables rapid failover and troubleshooting, and enhances system stability and operational efficiency.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119299360A_ABST
    Figure CN119299360A_ABST
Patent Text Reader

Abstract

The invention 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 inbound service flows of a service subsystem of a first server, the first server having a load balancing function; a configuration rule of the first server is obtained, and the configuration rule at least comprises an IPVS configuration rule for defining the corresponding relation between the IPVS of the first server and a second server for processing different types of service traffic and an IP channel configuration rule for defining an IP channel between the first server and the second server; and for each incoming service flow, determining the type of the current incoming service flow, and determining to distribute the current incoming service flow to the service subsystem of the second target server through the target IP channel according to the type and the configuration rule. The technical problem that a cluster deployed in a direct routing mode cannot be accessed in different three-layer domains is solved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of network security technology, and more specifically, to a cluster deployment method and system, and an electronic device. Background Art

[0002] With the rapid development of 5G converged private network services, the need for intercommunication between private networks and large networks has become increasingly urgent. However, this has also brought about a series of problems such as network security and operator control. In order to solve this problem, operators have proposed the architecture concept of Customized-Inter Working Function (C-IWF), that is, by deploying a signaling interworking gateway between the private network and the large network, it not only ensures the security of the large network and the private network, but also simplifies the complexity of network connection. In order to ensure the stability and high availability of C-IWF, it is often necessary to deploy a high-availability cluster.

[0003] At present, when deploying high-availability clusters, relevant technicians usually use IPVS (Internet Protocol Virtual Server, IP virtual server) as the cluster's load balancer, and use direct routing (Direct Routing, DR) to distribute the cluster's inbound traffic to the business processing unit. However, this deployment solution cannot cross the third-layer network and can only achieve load balancing within the second-layer domain of the same subnet (The Onion Router).

[0004] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

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

[0006] According to one aspect of an embodiment of the present application, a cluster deployment method is provided, which is applied to a cluster deployment system deployed in a first subnet within a cluster, and the cluster includes multiple subnets, including: obtaining multiple incoming business flows of a business subsystem of a first server, wherein the first server is a server with a load balancing function in the first subnet; obtaining configuration rules for the first server, wherein the configuration rules include at least: IP virtual server configuration rules and IP channel configuration rules, the IP virtual server configuration rules are used to define the correspondence between the IP virtual server corresponding to the first server and the second server that processes different types of business flows, and the IP channel configuration rules are used to define the IP channel between the first server and the second server; for each incoming business flow, determining the type of the current incoming business flow, and determining, based on the type and the configuration rules, to distribute the current incoming business flow to the business subsystem of the corresponding second target server through the target IP channel.

[0007] Optionally, obtaining the configuration rules of the first server includes: in response to a cluster deployment instruction initiated by a target user, obtaining corresponding cluster configuration data, wherein the cluster configuration data includes at least one of the following: first configuration data for reflecting the type of business 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 based on the destination IP address, destination port and business type of the traffic; determining the configuration rules of the first server according to the cluster configuration data.

[0008] Optionally, determining according to the type and configuration rules to distribute the current incoming business traffic to the business subsystem of the corresponding second target server through the target IP channel includes: determining according to the type and IP virtual server configuration rules a second target server corresponding to the processing type, wherein the second server and the first server are in different subnets; determining according to the IP channel configuration rules a target IP channel between the first server and the second target server; and distributing the corresponding type of incoming business traffic to the business subsystem of the second target server according to the target IP channel.

[0009] Optionally, the method also includes: monitoring the operating status data of the business subsystems of each second server, and determining the operating status of each business subsystem based on the operating status data, wherein the type of operating status includes: normal status or abnormal status; adjusting the IP virtual server configuration rules of the first server according to the operating status of each business subsystem.

[0010] Optionally, the IP virtual server configuration rules of the first server are adjusted according to the operating status of each business subsystem, including: when the operating status of the target business subsystem is normal, retaining the second server corresponding to the target business subsystem in the IP virtual server configuration rules; when the operating status of the target business subsystem is abnormal, deleting the second server corresponding to the target business subsystem in the IP virtual server configuration rules.

[0011] Optionally, the method also includes: sharing the diversion information of the incoming business traffic of the business subsystem of the first server to the business subsystems of multiple second servers within the cluster deployment system within multiple second subnets, wherein the second subnets are subnets other than the first subnet in the multiple subnets within the cluster.

[0012] Optionally, the configuration rules also include: virtual extended LAN tunnel rules, wherein the method also includes: building at least one virtual extended LAN tunnel between the first server and a third server with load balancing function in the second subnet according to the virtual extended LAN tunnel rules, and forming a bridge by at least one virtual extended LAN tunnel; receiving a message sent by any third server through the constructed virtual extended LAN tunnel, and synchronizing the message to other third servers through the bridge.

[0013] According to another aspect of an embodiment of the present application, a cluster deployment system is also provided, including: a system deployed in a first subnet within a cluster, the cluster including multiple subnets, the system including: a network management platform, used to respond to cluster deployment instructions initiated by a target user and obtain corresponding cluster configuration data; a network function management module, used to determine the configuration rules of the first server based on the cluster configuration data, wherein the configuration rules include at least: IP virtual server configuration rules, IP channel configuration rules, the IP virtual server configuration rules are used to define the correspondence between the IP virtual server corresponding to the first server and the second server processing different types of business traffic, and the IP channel configuration rules are used to define the IP channel between the first server and the second server; a load balancing module, used to obtain multiple incoming business flows of the business subsystem of the first server; for each incoming business flow, determine the type of the current incoming business flow, and determine, based on the type and configuration rules, to distribute the current incoming business flow to the corresponding business subsystem of the second target server through the target IP channel.

[0014] Optionally, the system also includes: a storage module, wherein the storage module is used to store cluster configuration data of multiple users, wherein the cluster configuration data includes at least one of the following: first configuration data for reflecting the type of business traffic processed by each server in the cluster, second configuration data for reflecting the traffic to be load balanced, and the second configuration data is determined at least based on the destination IP address, destination port and business type of the traffic.

[0015] Optionally, the load balancing module is used to determine the type of incoming business traffic for each incoming business traffic; determine a second target server corresponding to the processing type based on the type and the IP virtual server configuration rule, wherein the second server and the first server are in different subnets; determine a target IP channel between the first server and the second target server based on the IP channel configuration rule; and distribute the corresponding type of incoming business traffic to the business subsystem of the second target server based on the target IP channel.

[0016] Optionally, the above-mentioned load balancing module is also used to share the diversion information of the incoming business traffic of the business subsystem of the first server to the business subsystems of multiple second servers to the load balancing module in the second subnet, wherein the second subnet is other subnets among the multiple subnets in the cluster except the first subnet.

[0017] Optionally, the load balancing module is also used to monitor the operating status data of the business subsystems of each second server, and determine the operating status of each business subsystem based on the operating status data, wherein the types of operating status include: normal status or abnormal status; adjust the IP virtual server configuration rules of the first server according to the operating status of each business subsystem, including: when the operating status of the target business subsystem is normal, retain the second server corresponding to the target business subsystem in the IP virtual server configuration rules; when the operating status of the target business subsystem is abnormal, delete the second server corresponding to the target business subsystem in the IP virtual server configuration rules.

[0018] Optionally, the system also includes: an operation monitoring module, wherein the operation monitoring module is used to obtain the operation status of the business subsystems of the first server and multiple second servers reported by the load balancing module; when the operation status of any business subsystem is a fault state, the corresponding alarm prompt information is fed back to the network management platform, wherein the alarm prompt information is used to prompt that the operation status of the business subsystem is abnormal.

[0019] Optionally, the configuration rules also include: virtual extended LAN tunnel rules, wherein the above-mentioned load balancing module is also used to build at least one virtual extended LAN tunnel with at least one load balancing module in the second subnet according to the virtual extended LAN tunnel rules, and form a bridge with at least one virtual extended LAN tunnel; receive a message sent by the load balancing module in any second subnet through the constructed virtual extended LAN tunnel, and synchronize the message to the load balancing module in the third subnet through the bridge, wherein the third subnet is other subnets among the multiple second subnets in the cluster except the current second subnet.

[0020] According to another aspect of an embodiment of the present application, an electronic device is further provided, the electronic device comprising: a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to execute the above-mentioned cluster deployment method through the computer program.

[0021] In the embodiment of the present application, the cluster deployment system deployed in each subnet in the cluster is used to perform the following steps: obtain the inbound business traffic of the business subsystem of the first server with load balancing function in the subnet; obtain the configuration rules of the first server, wherein the configuration rules at least include: IP virtual server configuration rules, IP channel configuration rules, 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 that processes different types of business traffic, and IP channel configuration rules are used to define the IP channel between the first server and the second server; for each inbound business traffic, determine the type of the current inbound business traffic, and determine to distribute the current inbound business traffic to the business subsystem of the corresponding second target server through the target IP channel according to the type and configuration rules. This solves the technical problem that the cluster deployed by direct routing cannot achieve access in different three-layer domains. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0023] Figure 1 It is a schematic diagram of a cluster deployment architecture based on relevant technologies;

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

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

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

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

[0028] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution 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 part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0029] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, 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 "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[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, data for analysis, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. For example, an interface is set up between this system and the relevant user or organization. Before obtaining relevant information, it is necessary to send an acquisition request to the aforementioned user or organization through the interface, and obtain relevant information after receiving the consent information fed back by the aforementioned user or organization.

[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): It is a gateway device used to achieve interworking and integration between different types of networks. Generally, it can be used to interconnect mobile networks and fixed networks to transmit data and signaling between mobile networks and fixed networks.

[0033] IPVS (IP Virtual Server): It is a technology that provides load balancing function under LVS (Linux Virtual Server). When the initial message of a TCP connection arrives, IPVS can select a server and forward the message to the server. After that, by checking the IP and TCP message header addresses of the sending message, it ensures that the subsequent messages of this connection are forwarded to the same server.

[0034] IP (Internet Protocol) is a network layer protocol in the TCP / IP system. The purpose of designing IP is to improve the scalability of the network: first, to solve Internet problems and realize the interconnection of large-scale, heterogeneous networks; second, to separate the coupling relationship between top-level network applications and bottom-level network technologies to utilize the independent development of the two. Based on the end-to-end design principle, IP only provides a connectionless, unreliable, best-effort data packet transmission service for the host.

[0035] VXLAN (Virtual eXtensible Local Area Network): is a network virtualization technology that can improve the expansion problem of large-scale cloud computing during deployment. It is an extension of VLAN. As a powerful tool, VXLAN can penetrate the third-layer network to extend the second layer. It encapsulates traffic and extends it to the third-layer network to solve the portability limitations of VMS (Virtual Memory System), making it possible to access servers on external IP subnets.

[0036] IP Tunnel: refers to a channel that can be used to communicate between two networks using network protocols. In this channel, data packets of other network protocols are first encapsulated before the information is transmitted. Usually, it is used to deploy IP networks directly connected by routing. IP tunnels can construct intermediate transmission networks through the underlying routing protocol.

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

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

[0039] TOR (Top of Row), also known as the top-of-rack wiring method, is an extension of the EOR method. When using TOR wiring, 1-2 access switches are deployed on the top of each server cabinet in the POD, and the rack-mounted services are connected to the cabinets through jumpers. On the switch, the uplink port of the switch is connected to the aggregation switch or core switch in the EOR network cabinet through copper cable or optical fiber.

[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, including: fan-out, publish-subscribe, task allocation, request-reply, etc.

[0041] Example 1

[0042] In the 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), 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 the cluster deployment architecture has the following disadvantages:

[0043] (1) IPVS rules are configured on Server 2 and Server 15 with load balancing functions in the same subnet (i.e., the same group of TOR), and both Server 2 and Server 15 adopt DR (direct routing) mode. When using IPVS technology to distribute the service inbound traffic of their service subsystems, it can only be distributed to Service Subsystem 1, Service Subsystem 2, ..., Service Subsystem 15 in the same subnet in the same Layer 2 domain, and it is impossible to distribute traffic across subnets and TORs.

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

[0045] (2) IPVS rule configuration needs to be manually configured and issued one by one, which makes the configuration process complicated. In addition, there is no fault monitoring function in the entire system. Once a system failure occurs, it is difficult to quickly identify the faulty business subsystem in the cluster.

[0046] In order to solve the above problems, the embodiments of the present application provide relevant solutions, 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 in this application can be deployed in a cluster with multiple subnets (ie, different TORs). The specific deployment method can refer to Figure 2 , the cluster deployment system is deployed on server 2 and server 17 with load balancing function as an example, and server 2 and server 17 are in different groups of TOR.

[0048] Specifically, for a cluster deployment system 30 in a single first subnet (which can be any subnet in the cluster), its specific architecture diagram is as follows: Figure 3 As shown, it 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 the first server with a load balancing function in the cluster, wherein:

[0049] The network management platform 31 can respond to the cluster deployment instruction initiated by the target user and obtain the corresponding cluster configuration data;

[0050] The network function management module 32 may determine the configuration rules of the first server according to the cluster configuration data, wherein the above configuration rules at least include: an IP virtual server (IPVS) configuration rule and an 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 service 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 multiple incoming business flows of the business subsystem of the first server; for each incoming business flow, determine the type of the current incoming business flow, and determine to distribute the current incoming business flow to the corresponding business subsystem of the second target server through the target IP channel based on the type and configuration rules.

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

[0053] The functions and interaction processes of each module in the cluster deployment system 30 are described below in conjunction with a specific implementation process.

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

[0055] Among them, the cluster configuration data of each user includes at least one of the following: first configuration data used to reflect the type of business traffic processed by each server in the cluster (which can be understood as: configuring the server to support processing of traffic of different business types), and second configuration data used to reflect the traffic to be load balanced (which can be understood as: configuring the traffic that needs to be load shared), and the second configuration data is determined at least based on the destination IP address, destination port and business type of the traffic.

[0056] As an optional implementation, since the IP virtual server configuration rule predefines the correspondence between the IP virtual server corresponding to the first server and the second server processing different types of business traffic (that is, defining multiple real servers corresponding to the IP virtual server corresponding to the first server, and defining the traffic type processed by each real server); 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 obtains multiple incoming business traffic of the business subsystem of the first server, for each incoming business traffic, it can be diverted in the following manner:

[0057] Step 1: Determine the type of incoming service traffic; determine a second target server corresponding to the processing type according to the type and the IP virtual server configuration rule, wherein the second server and the first server are in different subnets;

[0058] Step 2: Determine the target IP channel between the first server and the second target server according to the IP channel configuration rule;

[0059] Step 3: Distribute the corresponding type of incoming business traffic to the business subsystem of the second target server according to the target IP channel.

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

[0061] The above-mentioned diversion process can solve the problem that when the high-availability cluster deployed in the IPVSDR mode in the related technology diverts the incoming business traffic, it can only be diverted to the business subsystem under the same group of TOR in the same Layer 2 domain, and the specification limitation of distributing traffic across subnet TOR can not be achieved.

[0062] Optionally, the load balancing module 33 may also share the diversion information of the incoming business traffic of the first server's business subsystem to the business subsystems of multiple second subsystems (i.e., the business subsystems of the second servers to which the incoming business traffic is diverted) with the load balancing modules in other subnets.

[0063] Furthermore, in order to ensure that the load balancing module 33 distributes the incoming business traffic of the business subsystem of the first server to the business subsystems of servers in other subnets that can operate normally, the load balancing module 33 can also monitor the operating status data of the business subsystems of each second server, and determine the operating status of each business subsystem based on the operating status data, wherein the types of operating status include: normal status or abnormal status; and adjust the IP virtual server configuration rules of the first server according to the operating status of each business subsystem.

[0064] Specifically, the load balancing module 33 can implement the periodic request and reply of the corresponding operating status data of the business subsystem of the second server based on ZeroMQ, thereby monitoring the operating status data of the business subsystems of multiple second servers that process the incoming business traffic of the business subsystem of the first server, so as to determine the corresponding operating status according to the operating status data of each business system; and then adjust the IP virtual server configuration rules of the first server according to the operating status of each business subsystem.

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

[0066] When the target service subsystem is in a normal operating state, retaining the second server corresponding to the target service subsystem in the IP virtual server configuration rule;

[0067] When the running state of the target service subsystem is abnormal, 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 business subsystem of the second server that processes a certain type of business traffic of the business subsystem of the first server is abnormal (i.e., unhealthy), it means that the business subsystem cannot normally process this type of business traffic, and at this time, this type of business traffic should not be distributed to the abnormal business subsystem. Therefore, in this case, the load balancing module 33 can delete the second server corresponding to the abnormal business subsystem pre-configured in the IP virtual server configuration rule of the first server, so that the abnormal business subsystem can no longer continue to receive traffic; on the contrary, if the business subsystem of the second server that processes a certain type of business traffic of the business subsystem of the first server is normal, it will continue to be retained. The purpose of this is to ensure that all types of incoming business traffic of the business subsystem of the first server are always routed to the business subsystem of the real server that can be processed normally, thereby achieving fast and automatic fault switching to improve the availability and responsiveness of the cluster.

[0069] For example, assume that the IP virtual server defined in the IP virtual server configuration rule of the first server corresponds to a real server that processes the same traffic type, where Server 1, Server 2, and Server 3 can all process Class A business traffic. Then, when the type of the incoming business traffic of the business subsystem of the first server is Class A, but the load balancing module 33 of the first server detects that the business subsystems of Server 1 and Server 2 are both in an abnormal state, in order to ensure that Class A business traffic can be routed to the business subsystem of Server 3 that can process it normally, the correspondence between the IP virtual server and Server 1 and Server 2 pre-defined in the IP virtual server configuration rule can be deleted, and the correspondence between the IP virtual server and Server 3 can be retained to update the IP virtual server configuration rule.

[0070] In addition, in order to enable relevant technical personnel to know the faulty business subsystem in the subnet in real time and troubleshoot the fault in time, the cluster deployment system in this application also includes: an operation monitoring module 35, which can obtain the operation status of the business subsystem of the first server and multiple second servers reported by the load balancing module 33; when the operation status of any business subsystem is a faulty state, the corresponding alarm prompt information is fed back to the network management platform 31, wherein the alarm prompt information is used to prompt that the operation status of the business subsystem is abnormal. In this way, the target user can quickly locate and process the faulty business subsystem in time through the network management platform 31, thereby solving the technical problem that the high-availability cluster deployed by the relevant technology cannot troubleshoot the system fault 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 by related technologies is limited to the same Layer 2 domain, the network function management module 32 in the embodiment of the present application can also generate corresponding virtual extended local area network (VXLAN) tunnel rules based on the cluster configuration data, and send the rules to the load balancing module 33.

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

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

[0074] Furthermore, the load balancing module 33 can receive a message sent by any load balancing module in the second subnet through the constructed virtual extended LAN 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 in other subnets (i.e., the initiating node) conducts an IPVS synchronization session through the virtual extended LAN tunnel between it and the control node, the load balancing module 33 in the first subnet can first receive the message sent by the initiating node, and then flood the message to other virtual extended LAN tunnels in the bridge through the bridge to synchronize it to the load balancing modules in other subnets (i.e., the third subnet) other than the non-initiating node, wherein the third subnet is other subnets in the multiple second subnets in the cluster except the current second subnet (i.e., the subnet where the initiating node is located).

[0076] In the above cluster deployment system, IPVS IP tunnel mode is used to optimize Figure 1 The IPVSDR mode used, and the IP channel and VXLAN tunnel 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 to achieve the rapid deployment of high-specification clusters, and solve the problem that the high-availability cluster deployed by the IPVSDR method in the related technology cannot be accessed in different three-layer domains, and the session cannot be synchronized in different two-layer domains. At the same time, the cluster deployed by this application can achieve fast and automatic fault switching and efficient and fast operation and maintenance.

[0077] Example 2

[0078] In the above operating environment, the present application also 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. Figure 4 is a flow chart of an optional cluster deployment method according to an embodiment of the present application, such as Figure 4 As shown, the method at least includes steps S402-S406, wherein:

[0079] Step S402: Acquire multiple incoming service flows of the service subsystem of the first server.

[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 obtain the inbound business traffic of the business subsystem of the first server to obtain multiple inbound business traffics, and the types of each inbound business traffic can be the same or different. In addition, the above-mentioned first server is a server with load balancing function in the first subnet.

[0081] Step S404, configuration rules of the first cargo server.

[0082] In the technical solution provided in step S404, the above-mentioned configuration rules include at least: IP virtual server (IPVS for short) configuration rules and IP channel configuration rules. The IP virtual server configuration rules are used to define the correspondence between the IP virtual server corresponding to the first server and the second server processing different types of business traffic. The IP channel configuration rules are used to define the IP channel between the first server and the second server.

[0083] Step S406: for each incoming service flow, determine the type of the current incoming service flow, and determine to distribute the current incoming service flow to the service subsystem of the corresponding second target server through the target IP channel according to the type and configuration rules.

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

[0085] The above method of this embodiment is further introduced below.

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

[0087] Step S4041, in response to the cluster deployment instruction initiated by the target user, obtaining corresponding cluster configuration data, 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, destination port and service type of the traffic;

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

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

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

[0091] Step S4061, determining a second target server corresponding to the processing type according to the type and the IP virtual server configuration rule, wherein the second server and the first server are in different subnets;

[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: Distribute the corresponding type of incoming service traffic 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 incoming business traffic of the business subsystem of the first server is A at the current moment, and the real server (i.e., the second target server) corresponding to the IP virtual server of the first server and capable of processing incoming business traffic of type A is determined to be B through the IP virtual server configuration rules, and the IP channel between the first server and the second server is determined to be IP channel C through the IP channel configuration rules, then in the load balancing stage, the incoming business traffic of type A can be transmitted to the business subsystem of the real server B through IP channel C.

[0095] The cluster deployment system deployed in the first subnet can solve the problem that the high-availability cluster deployed in the IPVSDR mode in the related technology can only be distributed to the business subsystem under the same group TOR in the same Layer 2 domain when diverting the incoming business traffic through the above-mentioned diversion process, and cannot achieve the specification limitation of distributing traffic across subnet TOR.

[0096] Optionally, the load balancing module within the cluster deployment system within the first subnet can also share the diversion information of the incoming business traffic of the business subsystem of the first server to the business subsystems of multiple second subnets (i.e., the business subsystems of which second servers the incoming business traffic is diverted to) to the load balancing modules within the cluster deployment system within the multiple second subnets, wherein the above-mentioned second subnets are subnets other than the first subnet in the multiple subnets within the cluster.

[0097] Furthermore, in order to ensure that the incoming business traffic of the business subsystem of the first server can be distributed to the business subsystems of servers in other subnets that can operate normally, the load balancing module in the cluster deployment system deployed in the first subnet can also monitor the operating status data of the business subsystems of each second server, and determine the operating status of each business subsystem based on the operating status data, wherein the types of operating status include: normal status or abnormal status; and adjust the IP virtual server configuration rules of the first server according to the operating status of each business subsystem.

[0098] Specifically, the above-mentioned load balancing module can implement the second server's business subsystem to periodically request and reply to the corresponding operating status data based on ZeroMQ, thereby monitoring the operating status data of the business subsystems of multiple second servers that process the incoming business traffic of the business subsystem of the first server, so as to determine the corresponding operating status according to the operating status data of each business system; and then adjust the IP virtual server configuration rules of the first server according to the operating status of each business subsystem.

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

[0100] When the target service subsystem is in a normal operating state, retaining the second server corresponding to the target service subsystem in the IP virtual server configuration rule;

[0101] When the running state of the target service subsystem is abnormal, the second server corresponding to the target service subsystem in the IP virtual server configuration rule is deleted.

[0102] The above adjustment strategy can be understood as follows: if the business subsystem of the second server that processes a certain type of business traffic of the business subsystem of the first server is abnormal (i.e., unhealthy), it means that the business subsystem cannot normally process this type of business traffic, and at this time, this type of business traffic should not be distributed to the abnormal business subsystem. Therefore, in this case, the load balancing module can delete the second server corresponding to the abnormal business subsystem pre-configured in the IP virtual server configuration rule of the first server, so that the abnormal business subsystem can no longer continue to receive traffic; on the contrary, if the business subsystem of the second server that processes a certain type of business traffic of the business subsystem of the first server is normal, it will continue to be retained. The purpose of this is to ensure that all types of incoming business traffic of the business subsystem of the first server are always routed to the business subsystem of the real server that can handle it normally, thereby achieving fast and automatic fault switching 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 by related technologies is limited to the same Layer 2 domain, the network function management module in the cluster deployment system deployed in the first subnet can also generate corresponding virtual extended local area network (VXLAN) tunnel rules based on the cluster configuration data, and send the rules 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 LAN tunnel between the first server and the third server with load balancing function in the second subnet according to the virtual extended LAN tunnel rules, and the bridge is composed of at least one virtual extended LAN tunnel.

[0105] That is to say, the load balancing module acts as a control node, and builds at least one virtual extended LAN tunnel with other load balancing modules in different subnets (i.e., load balancing modules in at least one second subnet) according to the virtual extended LAN tunnel rules, and the VETP port (VXLAN TunnelEndpoints) at one end of the virtual extended LAN tunnel is the control node, and the VETP port at the other end is other load balancing modules in different subnets. Then, the control node binds all virtual extended LAN tunnels into a bridge.

[0106] Furthermore, the load balancing module can receive a message sent by any load balancing module in the second subnet through the constructed virtual extended LAN tunnel, and synchronize the message 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) conducts an IPVS synchronization session through the virtual extended LAN tunnel between it 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 LAN tunnels in the bridge through the bridge, so as to synchronize it to the load balancing modules in other subnets (i.e., the third subnet) other than the non-initiating node, wherein the third subnet is other subnets in the multiple second subnets in the cluster except the current second subnet (i.e., the subnet where the initiating node is located).

[0108] Based on the solutions defined in the above steps S402 to S406, it can be known that in an embodiment, the cluster deployment system deployed in the first subnet can adopt the IPVS IP tunnel mode optimization Figure 1 The IPVSDR mode used solves the problem that the high-availability cluster deployed by IPVSDR in related technologies cannot be accessed in different three-layer domains; at the same time, among the LB servers in different subnets, the load balancing module in any LB server is selected as the control node to build an IPVS tunnel with the LB servers in other subnets, and the control node binds these IPVS tunnels into a bridge, so that when the LB server in any subsequent subnet performs 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, so as to synchronize the synchronization message to the corresponding LB server, thereby solving the problem that sessions cannot be synchronized in different two-layer domains.

[0109] Example 3

[0110] According to an embodiment of the present application, an electronic device is also provided, wherein: Figure 5 is a schematic diagram of the structure of an optional electronic device according to an embodiment of the present application, such as Figure 5 As shown, the electronic device includes one or more processors; a memory for storing one or more programs, which, when the one or more programs are executed by the one or more processors, enables the one or more processors to run the programs, wherein the programs are configured to execute the cluster deployment method in the above-mentioned embodiment 2 when running.

[0111] Optionally, the processor is configured to execute the following steps through a computer program: obtaining multiple incoming business flows of a business subsystem of a first server, wherein the first server is a server with a load balancing function in a first subnet; obtaining configuration rules for the first server, wherein the configuration rules include at least: IP virtual server configuration rules and IP channel configuration rules, wherein the IP virtual server configuration rules are used to define the correspondence between the IP virtual server corresponding to the first server and the second server processing different types of business flows, and the IP channel configuration rules are used to define the IP channel between the first server and the second server; for each incoming business flow, determining the type of the current incoming business flow, and determining, based on the type and the configuration rules, to distribute the current incoming business flow to the business subsystem of the corresponding second target server through the target IP channel.

[0112] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0113] In the above embodiments of the present application, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0114] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of units can be a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0115] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed over multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0116] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0117] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the relevant technology or all or part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, server or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, disk or CD-ROM and other media that can store program codes.

[0118] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A cluster deployment method, characterized in that: A cluster deployment system is applied to a cluster deployed in a first subnet, and the cluster includes multiple subnets, including: Acquire multiple inbound business flows of a business subsystem of a first server, wherein the first server is a server with a load balancing function in the first subnet; Acquire configuration rules of the first server, wherein the configuration rules at least include: Internet Protocol 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 traffic, and the IP channel configuration rules are used to define the IP channel between the first server and the second server; For each of the incoming service flows, the type of the current incoming service flow is determined, and according to the type and the configuration rule, a service subsystem for distributing the current incoming service flow to the corresponding second target server through a target IP channel is determined.

2. The method according to claim 1, characterized in that Obtaining the configuration rule of the first server includes: In response to a cluster deployment instruction initiated by a target user, corresponding cluster configuration data is obtained, 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, destination port and service type of the traffic; A configuration rule for the first server is determined according to the cluster configuration data.

3. The method according to claim 1, characterized in that Determining, according to the type and the configuration rule, to distribute the current incoming service traffic to the service subsystem of the corresponding second target server through the target IP channel includes: Determining a second target server capable of processing the type according to the type and the IP virtual server configuration rule, wherein the second server and the first server are in different subnets; Determining a target IP channel between the first server and the second target server according to the IP channel configuration rule; Distribute the corresponding type of incoming service traffic to the service subsystem of the second target server according to the target IP channel.

4. The method according to claim 1, characterized in that: The method further comprises: Monitoring the operation status data of each of the business subsystems of the second server, and determining the operation status of each of the business subsystems according to the operation status data, wherein the type of the operation status includes: normal state or abnormal state; The IP virtual server configuration rules of the first server are adjusted according to the operating status of each of the business subsystems.

5. The method according to claim 4, characterized in that Adjusting the IP virtual server configuration rule of the first server according to the operating status of each of the business subsystems includes: When the operation state of the target business subsystem is normal, retaining the second server corresponding to the target business subsystem in the IP virtual server configuration rule; When the operation state of the target service subsystem is abnormal, the second server corresponding to the target service subsystem in the IP virtual server configuration rule is deleted.

6. The method according to claim 1, characterized in that The method further comprises: The inbound business traffic of the business subsystem of the first server is diverted to the business subsystems of multiple second servers and the diversion information is shared in the cluster deployment system within multiple second subnets, wherein the second subnet is other subnets in the multiple subnets within the cluster except the first subnet.

7. The method according to claim 1, characterized in that The configuration rules also include: virtual extended LAN tunnel rules, wherein the method further includes: According to the virtual extended LAN tunnel rule, at least one virtual extended LAN tunnel is established between the first server and a third server with a load balancing function in the second subnet, and a network bridge is formed by at least one virtual extended LAN tunnel; A message is received from any third server through the constructed virtual extended LAN tunnel, and the message is synchronized to other third servers through the bridge.

8. A cluster deployment system, characterized in that: The system is deployed in a first subnet in a cluster, the cluster includes multiple subnets, the system includes: a network management platform, a network function management module, a load balancing module, and the load balancing module is deployed on a first server with a load balancing function in the first subnet, wherein: The network management platform is used to respond to the cluster deployment instruction initiated by the target user and obtain the corresponding cluster configuration data; The network function management module is used to determine the configuration rules of the first server according to the cluster configuration data, 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 business traffic, and the IP channel configuration rules are used to define the IP channel between the first server and the second server; The load balancing module is used to obtain multiple incoming business flows of the business subsystem of the first server; for each of the incoming business flows, determine the type of the current incoming business flow, and determine to distribute the current incoming business flow to the business subsystem of the corresponding second target server through the target IP channel based on the type and the configuration rules.

9. The system according to claim 8, characterized in that The system also includes a storage module, wherein: The storage module is used to store cluster configuration data of multiple users, wherein the cluster configuration data includes at least one of the following: first configuration data for reflecting the type of business 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 based on the destination IP address, destination port and business type of the traffic.

10. The system according to claim 8, characterized in that in, The load balancing module is used to determine the type of incoming business traffic for each incoming business traffic; determine a second target server capable of processing the type according to the type and the IP virtual server configuration rule, wherein the second server and the first server are in different subnets; determine a target IP channel between the first server and the second target server according to the IP channel configuration rule; and distribute the incoming business traffic of the corresponding type to the business subsystem of the second target server according to the target IP channel.

11. The system according to claim 8, characterized in that in, The above-mentioned load balancing module is also used to share the diversion information of the incoming business traffic of the business subsystem of the first server to the business subsystems of multiple second servers to the load balancing modules in multiple second subnets, wherein the second subnet is other subnets in the multiple subnets in the cluster except the first subnet.

12. The system according to claim 8, characterized in that The load balancing module is also used to monitor the operating status data of the business subsystems of each of the second servers, and determine the operating status of each business subsystem based on the operating status data, wherein the type of the operating status includes: normal status or abnormal status; adjust the IP virtual server configuration rules of the first server according to the operating status of each of the business subsystems, including: when the operating status of the target business subsystem is normal, retain the second server corresponding to the target business subsystem in the IP virtual server configuration rules; when the operating status of the target business subsystem is abnormal, delete the second server corresponding to the target business subsystem in the IP virtual server configuration rules.

13. The system according to claim 11, characterized in that The system also includes: an operation monitoring module, wherein: The operation monitoring module is used to obtain the operation status of the business subsystems of the first server and multiple second servers reported by the load balancing module; when the operation status of any of the business subsystems is a fault state, the corresponding alarm prompt information is fed back to the network management platform, wherein the alarm prompt information is used to prompt that the operation status of the business subsystem is abnormal.

14. The system according to claim 8, characterized in that The configuration rules also include: virtual extended LAN tunnel rules, where: The load balancing module is further used to build at least one virtual extended LAN tunnel with at least one load balancing module in the second subnet according to the virtual extended LAN tunnel rule, and to form a bridge with at least one of the virtual extended LAN tunnels; receive a message sent by a load balancing module in any second subnet through the constructed virtual extended LAN tunnel, and synchronize the message to the load balancing module in the third subnet through the bridge, wherein the third subnet is other subnets in the multiple second subnets in the cluster except the current second subnet.

15. An electronic device, characterized in that: include: A memory and a processor, wherein the processor is used to run a program stored in the memory, wherein the program executes the cluster deployment method according to any one of claims 1 to 7 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

  • Measurement-Based Validation of a Simple Model for Panoramic Profiling of Subnet-Level Network Data Traffic

    US20100034102A1

  • Cluster destination address table-IP routing for clusters

    US6993034B1