Cloud load balancing system and cloud load balancing method

Abstract

This disclosure provides a cloud load balancing system and method, including: a core switch, at least two load balancers, and listeners and multiple load balancing instances deployed in each load balancer. The core switch, in response to detecting VIP network segment traffic, queries routing information and directs the next hop of the VIP network segment traffic to a target load balancer among the at least two load balancers. The listeners in the target load balancers forward the VIP network segment traffic to the target load balancing instance corresponding to the user IP. The target load balancing instances determine the target application server corresponding to the VIP network segment traffic according to a load balancing algorithm and send the VIP network segment traffic to the target application server for appropriate processing. This disclosure provides a cloud load balancing solution for container cloud platforms that meets functional and performance requirements, as well as cost control.

Description

Technical Field

[0001] This disclosure relates to the field of cloud computing, and in particular to a cloud load balancing system and a cloud load balancing method. Background Technology

[0002] With container technology and container cluster management systems becoming increasingly popular, building enterprise-grade container cloud platforms has become an industry trend. Simultaneously, a high-performance cloud load balancer needs to be built to provide unified load support for enterprise-grade container cloud platforms.

[0003] Currently, there are numerous load balancers and software options available. Taking software load balancers as an example, most vendors choose Nginx to meet certain load balancing needs through simple installation and configuration. However, software load balancers offer limited functionality and often fail to meet the diverse requirements of container cloud platforms. On the other hand, hardware load balancers, such as F5, offer superior functionality and performance compared to software load balancers, but they are more expensive and have redundant configurations. Therefore, providing cloud load balancing for container cloud platforms that meets both functional and performance requirements while controlling costs is a pressing issue that needs to be addressed. Summary of the Invention

[0004] To address the aforementioned issues, this disclosure provides a cloud load balancing system and a cloud load balancing method to provide a cloud load balancing solution for container cloud platforms that meets both functional and performance requirements while controlling costs.

[0005] In a first aspect, this disclosure provides a cloud load balancing system, including: a core switch, a physical access switch and at least two load balancers, wherein the load balancers are equipped with listeners and multiple load balancing instances, and the core switch and at least two load balancers all run the Boundary Gateway Protocol (BGP). The core switch stores routing information of the virtual IP (VIP) network segment corresponding to the load balancer.

[0006] The core switch is used to respond to the detection of VIP network segment traffic, query routing information, and direct the next hop of the VIP network segment traffic to the target load balancer among at least two load balancers. The VIP network segment traffic carries the user IP and the target VIP.

[0007] The listener in the target load balancer is used to respond to the detection of traffic in the VIP network segment and forward the traffic to the target load balancer instance corresponding to the user IP based on HAProxy rules;

[0008] The target load balancer instance is used to determine the target application server corresponding to the VIP network segment traffic based on the load balancing algorithm; and to send the VIP network segment traffic to the target application server through the internal network card so that the target application server can process the VIP network segment traffic accordingly.

[0009] In one possible implementation, the cloud load balancing system further includes an Application Programming Interface (API) server and a Subscriber component. The load balancer includes a proxy component, wherein: the API server is used to respond to a load balancing instance creation request by sending the load balancing instance creation request to the corresponding region's subscription component; the load balancing instance creation request is issued by the user through a User Interface (UI); the subscription component is used to allocate physical resources for the load balancing instance to be created and write the integrated load balancing instance metadata information into the distributed database of the cloud load balancing system; the proxy component is used to listen for load balancing instance metadata information write events in the distributed database and construct the load balancing instance based on the load balancing instance metadata information.

[0010] In one possible implementation, the subscription component is also used to: determine the available physical resources in the corresponding load balancer to meet the physical resources required by the load balancer to be created before allocating physical resources to the load balancer instance to be created.

[0011] In one possible implementation, the subscription component is also configured to: issue a prompt message for adding a new load balancer in response to the fact that available physical resources do not meet the physical resources required by the load balancer instance to be created.

[0012] In one possible implementation, the cloud load balancing system further includes a service discovery module, wherein: the API server is also used to respond to a listener creation request by sending the listener creation request to the subscription component of the corresponding region; the listener creation request is issued by the user through the UI; the subscription component is also used to query the load balancer to which the listener to be created belongs, integrate the relevant information into the listener metadata, and then send the listener creation request to the service discovery module; the service discovery module is used to integrate the backend address of the application server into the listener metadata and write the integrated listener metadata information into the distributed database of the cloud load balancing system; the load balancer to which the listener to be created belongs is used to construct the listener based on the listener metadata information when it detects the listener metadata information being written to the distributed database.

[0013] In one possible implementation, the service discovery module is also used to subscribe to relevant events for different architectures.

[0014] In one possible implementation, the relevant events include Mesos events and / or K8S events, and the service discovery module is specifically used for at least one of the following: for Mesos events, obtaining the backend address by tracing the server; for K8S events, obtaining the application's backend address by the Cloud Control Matrix (CCM).

[0015] In one possible implementation, the load balancer is connected to the target application server via a virtual switch.

[0016] One possible implementation of the load balancing algorithm includes round-robin, source address session persistence, and least links.

[0017] In one possible implementation, the cloud load balancing system further includes a distributed database; the listener is also used to: monitor whether the data in the distributed database is updated; in response to the data update in the distributed database, update the updated data to the corresponding configuration file and perform hot reloading to make the update effective, the configuration file storing the IP address and port of the application server corresponding to the load balancer.

[0018] Secondly, this disclosure provides a cloud load balancing method applied to a cloud load balancing system, which includes: a core switch, a physical access switch and at least two load balancers. Each load balancer is equipped with a listener and multiple load balancing instances. Both the core switch and the at least two load balancers run BGP. The core switch stores routing information for the VIP network segment corresponding to the load balancer.

[0019] Cloud load balancing methods include:

[0020] In response to detecting VIP network segment traffic, the core switch queries the routing information and directs the next hop of the VIP network segment traffic to the target load balancer among at least two load balancers. The VIP network segment traffic carries the user IP and the target VIP.

[0021] When the listener in the target load balancer detects traffic in the VIP network segment, it forwards the VIP network segment traffic to the target load balancer instance corresponding to the user's IP address based on the HAProxy rules.

[0022] The target load balancing instance determines the target application server corresponding to the VIP network segment traffic based on the load balancing algorithm; and sends the VIP network segment traffic to the target application server through the internal network card, so that the target application server can process the VIP network segment traffic accordingly.

[0023] This disclosure provides a cloud load balancing system and a cloud load balancing method. The cloud load balancing system includes a core switch, physical access switches, and at least two load balancers. Each load balancer deploys a listener and multiple load balancing instances. Both the core switch and the at least two load balancers are operational. The core switch stores routing information for the VIP network segment corresponding to each load balancer. The core switch, in response to detecting VIP network segment traffic, queries the routing information and directs the next hop of the VIP network segment traffic to a target load balancer among the at least two load balancers. The VIP network segment traffic carries a user IP address and a target VIP. The listener in the target load balancer, in response to detecting VIP network segment traffic, forwards the VIP network segment traffic to the target load balancer instance corresponding to the user IP address based on HAProxy rules. The target load balancer instance, according to a load balancing algorithm, determines the target application server corresponding to the VIP network segment traffic and sends the VIP network segment traffic to the target application server via an internal network interface card (NIC) for appropriate processing. In this disclosure, the target load balancer, i.e., hardware load balancer, is determined through the core switch; the target application server, i.e., software load balancer, is determined through the target load balancer instance. Therefore, the cloud load balancing system of this disclosure provides cloud load balancing by combining software load balancing and hardware load balancing. Compared with software load balancers, it can meet the functional and performance requirements of container cloud platforms for load balancing. In addition, compared with pure hardware load balancers, it can reduce the high cost of hardware load balancers when achieving the same functional and performance requirements, thus controlling costs. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 This is a schematic diagram illustrating an application scenario provided by an embodiment of the present disclosure;

[0026] Figure 2 This is a schematic diagram of the structure of a cloud load balancing system 200 provided in an embodiment of the present disclosure;

[0027] Figure 3 This is a schematic diagram of the structure of a cloud load balancing system 300 provided in another embodiment of the present disclosure;

[0028] Figure 4A schematic diagram of the structure of a cloud load balancing system 400 provided in yet another embodiment of this disclosure;

[0029] Figure 5 A flowchart of a cloud load balancing method provided in an embodiment of this disclosure. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0031] Currently, there are numerous load balancers and software options available. Taking software load balancers as an example, most vendors choose Nginx to meet certain load balancing needs through simple installation and configuration. However, software load balancers offer limited functionality and often fail to meet the diverse requirements of container cloud platforms. On the other hand, hardware load balancers, such as F5, offer superior functionality and performance compared to software load balancers, but they are more expensive and have redundant configurations. Therefore, providing cloud load balancing for container cloud platforms that meets both functional and performance requirements while controlling costs is a pressing issue that needs to be addressed.

[0032] To address the aforementioned problems, the inventors discovered that a two-tier load balancing architecture can be constructed by combining software load balancing and hardware load balancing. For example, a core switch is introduced as the first-layer physical load balancing architecture, used to allocate specific load balancers based on access requests. Furthermore, each load balancer contains at least one user load balancing instance, which, based on the application server's load status, sends access requests through a virtual switch to the application server that meets the load balancing conditions. This virtual switch serves as the second-layer software load balancing architecture. In this way, the cloud load balancing system disclosed herein implements a combined software and hardware load balancing architecture, which not only improves functionality but also reduces load balancing costs.

[0033] Figure 1 This is a schematic diagram illustrating the application scenarios provided in this disclosure, such as... Figure 1 As shown, Figure 1In this application scenario, application servers 101, 102, and 103 can be included, along with client 104 and cloud load balancing system 105. A user (not shown in the diagram) sends an access request through client 104. This request is first sent via the internet to cloud load balancing system 105, which then forwards the request to the corresponding application server based on cloud load balancing conditions. Specifically, this application server can be application server 102.

[0034] For example, after a user selects the application to access on client 104, the client sends an access request, which can be sent to cloud load balancing system 105 via a fixed network or mobile network. Cloud load balancing system 105 also includes at least one cloud load balancer (not shown in the diagram), and each cloud load balancer corresponds to at least one application server. That is, the cloud load balancer is used to perform load balancing on its corresponding application server. As an example, the cloud load balancer can send access requests to the corresponding application servers sequentially in a round-robin manner, i.e., according to a certain direction. After the access request is sent to the application server, since the access request carries the port information of the accessed application, the application server reads the port information and selects the corresponding application replica to respond to the access request. It should be noted that application servers 101 to 103 can be configured in a virtual environment, using container technology to enable the same application to be compatible in different configuration environments.

[0035] After the corresponding application copy in the application server responds to the access request, it will return an acknowledgment signal to client 104 to inform client 104 that the user response is complete.

[0036] In this application scenario, the client 104 can be a mobile phone or a PC host. At least one cloud load balancing system 105 may exist; this disclosure does not limit its presence.

[0037] The cloud load balancing system of this disclosure will be described next through specific embodiments, such as... Figure 2 As shown, Figure 2 This is a schematic diagram of the structure of a cloud load balancing system 200 provided in one embodiment of the present disclosure. The cloud load balancing system 200 includes: a core switch 201, a physical access switch 202, and at least two load balancers: load balancer 203 and load balancer 204 (two load balancers are used as an example for illustration). Each load balancer may deploy a listener and multiple load balancing instances. For example, Figure 2In this configuration, load balancer 203 includes load balancer instance 2031, load balancer instance 2032, and listener 2030; load balancer 204 includes load balancer instance 2041, load balancer instance 2042, and listener 2040. Core switch 201, load balancer 203, and load balancer 204 all run Border Gateway Protocol (BGP). Core switch 201 stores routing information for the corresponding VIP network segment of each load balancer.

[0038] Specifically, the core switch 201 is used to respond to the detection of VIP network segment traffic, query routing information, and direct the next hop of the VIP network segment traffic to the target load balancer among at least two load balancers, wherein the VIP network segment traffic carries the user IP and the target VIP.

[0039] After receiving the access request from the user, the cloud load balancing system 200 will first send the access request to the core switch 201. Specifically, the access request can be forwarded to the cloud load balancing system 200 by a wired network or by a wireless network. For example, the wireless network may include base stations, routers, and other devices; the wired network may include a local area network or a fixed broadband network.

[0040] Core switch 201, as the front-end device for hardware load balancing, is responsible for extracting the user's VIP and the port information of the application the user wants to access from the received access request. Furthermore, core switch 201 has pre-built a routing table based on the VIP, reflecting the target load balancer corresponding to each user's VIP. Based on each user's service demand (the number of applications they can access), a routing table is constructed to perform hardware load balancing for users, ensuring that each load balancer achieves a similar load state. For example, the access request can be transmitted in the form of traffic data. When core switch 201 obtains that the user's VIP is 110, it determines the target load balancer is 203 by querying the routing table, and then sends the service access request to the target load balancer 203. It should be understood that: Figure 2 As one example of this disclosure, the number of load balancers may also be three, four or more, and this disclosure does not limit them.

[0041] The listener in the target load balancer is used to respond to the detection of traffic in the VIP network segment and, based on HAProxy rules, forward the VIP network segment traffic to the target load balancer instance corresponding to the user's IP.

[0042] It can be understood that a listener is a software component installed on the target load balancer. One function of the listener can be to forward user access requests to the corresponding load balancer instance based on HAProxy rules. For example, based on the user's VIP in the access request, the listener can determine the IP address and port of the user's load balancer instance corresponding to that VIP, and then forward the access request to that load balancer instance.

[0043] Furthermore, as a target load balancer instance, it is used to determine the target application server corresponding to the VIP network segment traffic according to the load balancing algorithm; and to send the VIP network segment traffic to the target application server through the internal network card so that the target application server can process the VIP network segment traffic accordingly.

[0044] For example, load balancing algorithms may include round-robin, source address session hold, and least connections, etc.

[0045] The so-called round-robin method means that the application servers are load-balanced in a fixed order. The source address session persistence algorithm is similar to the hardware load balancing architecture of the core switch, which determines the target application server based on the VIP of the access request. The least link method, as the name suggests, determines the access request to the application server with the lowest load by judging the load of multiple application servers.

[0046] After determining the target application server according to the algorithm described above, the target load balancer instance extracts the port of the application the user wants to access from the access request and sends the access request to the application replica on the corresponding target server. It should be understood that each load balancer server corresponds to at least one target application server. The internal configuration environments of multiple target application servers can be the same or different. Each target application server contains an identical application replica, which can be considered the result of multiple replications of the source application. This method of multiple application servers each hosting an application replica of a specific source application serves as a software-layer load balancing architecture.

[0047] This disclosure provides a cloud load balancing system as described above. The system uses a core switch to query routing information and directs the next hop of VIP network segment traffic to a target load balancer among at least two load balancers. Within the target load balancer, the system uses a target load balancing instance and a load balancing algorithm to determine the target application server corresponding to the VIP network segment traffic. In this disclosure, the target load balancer is determined through the core switch (hardware load balancing), and the target application server is determined through the target load balancing instance (software load balancing). Therefore, this cloud load balancing system provides cloud load balancing by combining software and hardware load balancing. Compared to software load balancers, this can meet the functional and performance requirements of container cloud platforms for load balancing. Furthermore, compared to pure hardware load balancers, it reduces the high costs associated with hardware load balancers when achieving the same functional and performance requirements, thus controlling costs.

[0048] In some embodiments, the cloud load balancing system also includes an API server and a subscription component (also known as a Subscriber component), and the load balancer includes a proxy component (also known as an Agent component), wherein:

[0049] API server 205 is used to respond to load balancer instance creation requests by sending the load balancer instance creation request to the subscription component of the corresponding region. The load balancer instance creation request is issued by the user through the user interface (UI).

[0050] API server 205 is used to receive requests from the user's terminal. These requests can be access requests or creation requests, and creation requests can be further divided into load balancer instance creation requests and listener creation requests.

[0051] If the API server 205 receives a creation request, it will determine the region of the user who made the request based on the VIP of the request, and then send the creation request to the subscription component of the corresponding region.

[0052] Subscription component 206 is used to allocate physical resources to the load balancer instance to be created and write the integrated load balancer instance metadata information into the distributed database of the cloud load balancing system. It should be understood that before allocating physical resources to the load balancer instance to be created, subscription component 206 will also determine whether the available physical resources in the corresponding load balancer meet the physical resources required by the load balancer instance to be created. If there is a situation where the available physical resources do not meet the physical resources required by the load balancer instance to be created, subscription component 206 will issue a prompt message to add a new load balancer.

[0053] For example, if the creation request is for a load balancer instance, the subscription component 206, upon receiving the request, will first determine whether each load balancer has enough space to create a new instance; or, determine whether space can be freed up to create a new load balancer instance. Specifically, for the latter, the subscription component 206 will obtain the user's information based on the VIP of the creation request. If the user is not a new user, the physical resources of the user's previous load balancer instance can be freed up for the creation of this instance. It should be understood that, due to the large number of users, multiple users may share the same physical resources at different times; therefore, the aforementioned users can also be understood as tenants. If the user is a new user, no space can be freed up.

[0054] After allocating physical resources (i.e., freeing up space as described above), the subscription component 206 writes the load balancing instance metadata information into the distributed database 207, which may be ETCD. This load balancing instance metadata information may include: the user corresponding to the load balancing instance, and the IP addresses and ports of all applications accessible to that user on the application server.

[0055] In this embodiment, load balancer 203 includes a proxy component 2033, and load balancer 204 includes a proxy component 2043. Both proxy components are used to construct a load balancer instance based on the load balancer instance metadata information when a write event to the load balancer instance metadata information is detected in the distributed database.

[0056] For example, proxy components 2033 and 2043 periodically listen for load balancer instance metadata write events in the distributed database. If the event occurs, a load balancer instance is built; otherwise, the listening continues.

[0057] In this embodiment, a load balancing instance is created by combining a proxy component, a distributed database, and a subscription component. Since the proxy component is only used to listen for load balancing instance metadata write events and to build the load balancing instance, the cloud load balancing system can improve the creation rate of load balancing instances. Furthermore, the subscription component can flexibly allocate physical resources for the creation of load balancing instances, satisfying a multi-user mechanism, meaning the cloud load balancing system can provide load balancing services to more users.

[0058] Figure 3This is a schematic diagram of the structure of a cloud load balancing system 300 provided in an embodiment of the present disclosure. The cloud load balancing system 300 includes a core switch 301, a physical access switch 302, a load balancer 303, a load balancer 304, an API server 305, a subscription component 306, a distributed database 307, and a service discovery module 308, wherein:

[0059] API server 305 is used to respond to listener creation requests by sending the listener creation request to the subscription component of the corresponding area. The listener creation request is issued by the user through the UI.

[0060] In this embodiment, API server 305 and Figure 2 The listener creates a request to the API server with a 205 error, which serves the same purpose and will not be elaborated on here.

[0061] The subscription component 306 is used to query the load balancer to which the listener to be created belongs, integrate the relevant information into the listener metadata, and then send the listener creation request to the service discovery module 308.

[0062] The subscription component 306 determines the load balancer to which the user sending the listener creation request belongs based on the VIP of the listener creation request, and then sends the listener creation request to that load balancer. This information includes the user's VIP and the ports of all applications the user can access in this listener creation request.

[0063] The service discovery module 308 is used to integrate the backend address of the application server into the listener metadata and write the integrated listener metadata information into the distributed database 307 of the cloud load balancing system.

[0064] It should be understood that the cloud load balancing system 300 stores a configuration file containing the VIP (VIP) of each user, the ports of all applications accessible to each user, the IP address of each application replica on the application server, and the port of each application replica on the server. The VIP and port mentioned earlier can be considered as front-end ports, i.e., those facing the user's client; the IP address and port mentioned later can be considered as back-end ports, facing the application server. Additionally, the configuration file can also store the IP address of the distributed database 307 and the IP addresses of multiple application servers.

[0065] The service discovery module 308 can save the IP address and port of the application server that the user can access in the listener metadata and write the listener metadata into the distributed database 307.

[0066] In addition, the service discovery module 308 can exist independently on a server or be deployed on a load balancer; this disclosure does not limit its use.

[0067] In the above, the load balancer to which the listener to be created belongs, as determined by the subscription component 306, is used to construct the listener based on the listener metadata information when the listener metadata information is written to the distributed database.

[0068] For example, Figure 3 In the embodiments, load balancer 303 includes load balancing instance 3031, load balancing instance 3032, listener 3030 and proxy component 3033, and load balancer 304 includes load balancing instance 3041, load balancing instance 3042, listener 3040 and proxy component 3043.

[0069] Listener 3030 was created by load balancer 303; listener 3040 was created by load balancer 304.

[0070] In addition, the aforementioned service discovery module 308 can also be used to subscribe to relevant events for different architectures.

[0071] Depending on the software architecture, the service discovery module 308 may subscribe to different events. These events often cause changes to the IP address of the application server, the IP address of the application replica in the application server, and the port in the configuration file.

[0072] For example, the relevant events include Mesos events and / or K8S events, and the service discovery module is specifically used for at least one of the following: for Mesos events, obtaining the backend address by tracing the server; for K8S events, obtaining the application's backend address by the cloud control matrix.

[0073] Mesos, as a distributed software architecture, can model distributed systems such as Cloud Load Balancer 200 and Cloud Load Balancer 300. Kubernetes (K8S), on the other hand, is a management tool for container technology. In essence, Mesos manages the IP addresses and ports of individual servers in a cloud load balancer system, while K8S manages the IP addresses and ports of multiple application replicas within an application server.

[0074] The cloud control matrix is ​​used to obtain the IP address of the application replica; the tracing server is used to obtain the IP address of the application server; and it can also obtain the IP address of the server where the load balancer, distributed database, and even the service discovery module reside.

[0075] After the listener is built, in some implementations, the listener can also be used to: monitor whether the data in the distributed database is updated; in response to the data being updated in the distributed database, update the updated data to the corresponding configuration file and perform hot reloading to make the update effective. The configuration file stores the IP address and port of the application server corresponding to the load balancer.

[0076] For example, this can be achieved through the Confd component in the listener. As previously described, the service discovery module 308 integrates the application server's IP address into the listener metadata based on different events and writes the integrated listener metadata information into the distributed database of the cloud load balancing system. When the Confd component detects a data update in the distributed database, it loads the updated data into the configuration file. Specifically, this loading method can be hot-loading, meaning the configuration file is updated without restarting the server.

[0077] In other embodiments, the load balancer is connected to the target application server via a virtual switch.

[0078] As described earlier, the internal configuration environments of multiple target application servers can be the same or different. In this embodiment, when the internal configuration environments of multiple target application servers are different, a virtual switch is needed to establish a virtual tunnel. This virtual tunnel can connect application copies with different configuration environments. For example, the application server systems may include Windows, Linux, iOS, or even DOS operating systems. Since the configuration environments differ across operating systems, the virtual tunnel provided by the virtual switch ensures that application copies are compatible across multiple operating systems without requiring reconfiguration of the application's underlying code.

[0079] This virtual switch can be mounted on a load balancer or deployed independently.

[0080] In this embodiment, by introducing a listener, hot updates of the configuration file can be achieved based on various events. Furthermore, the service discovery module can dynamically obtain the IP address of the backend application server and store it in a distributed database. This allows the listener to obtain the application server's IP address in real time, thereby indirectly improving the frequency and speed of configuration file updates.

[0081] Next, this disclosure provides another embodiment, which is provided by Figure 4 The cloud load balancing system 400 provides, such as Figure 4 The cloud load balancing system 400 includes:

[0082] The core switch 401, the physical access switch 402, and at least two load balancers (e.g. Figure 4 The load balancers 403, 404, and 405 are shown. Each load balancer deploys a listener and multiple load balancer instances. Load balancer 403 includes a listener 4030, a user 1 load balancer instance 4031, a user 2 load balancer instance 4032, and a proxy component 4033; load balancer 404 includes a listener 4040, a user 1 load balancer instance 4041, a user 2 load balancer instance 4042, and a proxy component 4043; load balancer 405 includes a listener 4050, a user 1 load balancer instance 4051, a user 2 load balancer instance 4052, and a proxy component 4053. Each listener includes a Confd component and a haproxy component. The haproxy component is used to schedule data traffic for access requests based on haproxy rules. In addition, in order to provide a unified access point for the core switch 401, this embodiment also sets up a physical access switch 402, which is used to connect the load balancers 403 to 405 in a unified manner through equal-cost routes based on the BGP protocol.

[0083] The cloud load balancing system 400 may also include: an API server 406, a subscription component 407, a service discovery module 408, a distributed database 409, and a virtual switch 410. The virtual switch connects application servers 411 to 419 by establishing virtual tunnels. Note that application servers 411 to 413 belong to load balancer 403; application servers 414 to 416 belong to load balancer 404; and application servers 417 to 419 belong to load balancer 405. It should be understood that a load balancer, also known as a dedicated load balancer, is a dedicated server used for load balancing of application servers.

[0084] The actual application process of this cloud load balancing system is as follows:

[0085] When a user on a client wants to access an application, they select the application in the client's UI. The client then sends an access request, which is ultimately received by the application server. This access request carries the user's VIP and the port (e.g., 80) of the application the user selected to access.

[0086] The access request will first be transmitted to the cloud load balancer system 400 via the wireless network. It should be understood that the client needs to create its own load balancer instance before sending the access request. That is, if the user has not created a load balancer instance, the access request will not be transmitted to the cloud load balancer system 400. The user's creation of the load balancer instance and the creation of the listener have been described in the preceding embodiments and will not be repeated here.

[0087] After receiving the access request, the cloud load balancing system 400 will configure a specific load balancer for it via the core switch 401. For example, if the core switch obtains the VIP of the user requesting the access request as 100.110, it will determine the target load balancer of the access request as load balancer 404 by querying the routing table. The access request will then be sent to load balancer 404 via the physical access switch 402. The listener 4040 in load balancer 404 will send the access request to the corresponding load balancing instance based on the VIP of the access request, for example, user 1 load balancer instance 4041. User 1 load balancer instance 4041 will then determine the application server with the lowest load based on a preset algorithm, such as the least links method. For example, application server 416. It should be understood that the application servers run different host systems; after establishing a virtual tunnel through the virtual switch 410, the three are connected in a virtual environment. Specifically, the internal network card in user 1 load balancer instance 4041 will send the access request to application server 416 through the virtual tunnel. Application server 416 will determine the application replica corresponding to port 80 based on port 80, and that application replica will respond to the access request. Simultaneously, after the response is complete, an acknowledgment signal will be returned to the user's client.

[0088] The cloud load balancing system provided in this application has at least the following advantages: it implements a two-tier architecture based on hardware load balancing and software load balancing; based on a core switch, it can achieve a unified entry point and load balancer allocation; the load balancer can be horizontally scaled; a multi-user mechanism allows the load balancer to flexibly configure physical resources for multiple users; a service discovery module can dynamically obtain the addresses of backend application servers, and the listener updates the configuration files in real time; the cloud load balancing system supports TCP, HTTP, and HTTPS protocols; and the load balancing instance includes at least the following scheduling algorithms: round-robin, source address session persistence, and least connections.

[0089] It should be understood that: Figure 2 , Figure 3 as well as Figure 4 The embodiments can be combined with each other or used independently, and all can be used as embodiments provided by this disclosure. This disclosure does not limit them.

[0090] After introducing the cloud load balancing system provided in this disclosure, through Figure 5 This document introduces the cloud load balancing methods provided in this disclosure. For example... Figure 5 As shown, this cloud load balancing method includes:

[0091] When the S501 core switch detects traffic in the VIP network segment, it queries the routing information and directs the next hop of the VIP network segment traffic to the target load balancer among at least two load balancers. The VIP network segment traffic carries the user's IP address and the target VIP.

[0092] S502. When the listener in the target load balancer detects traffic in the VIP network segment, it forwards the VIP network segment traffic to the target load balancer instance corresponding to the user IP based on the HAProxy rules.

[0093] S503. The target load balancing instance determines the target application server corresponding to the VIP network segment traffic based on the load balancing algorithm; and sends the VIP network segment traffic to the target application server through the internal network card so that the target application server can process the VIP network segment traffic accordingly.

[0094] It can be understood that this cloud load balancing method can be executed by the aforementioned cloud load balancing system, and the specific implementation and function of this cloud load balancing method are similar to those of the aforementioned cloud load balancing system, so they will not be repeated here.

[0095] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this disclosure, and not to limit it; although this disclosure has been described in detail with reference to the foregoing embodiments,

[0096] Those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this disclosure.

Claims

1. A cloud load balancing system, characterized in that, include: The system includes a core switch, physical access switches, and at least two load balancers. Each load balancer is equipped with a listener and multiple load balancer instances. Both the core switch and the at least two load balancers run Border Gateway Protocol (BGP). The core switch stores routing information for the virtual IP address (VIP) network segment corresponding to the load balancer. The core switch is used to respond to the detection of VIP network segment traffic, query the routing information, and direct the next hop of the VIP network segment traffic to the target load balancer among the at least two load balancers. The VIP network segment traffic carries the user IP and the target VIP. The listener in the target load balancer is used to forward the VIP network segment traffic to the target load balancer instance corresponding to the user IP based on the haproxy rules in response to the detection of the VIP network segment traffic. The target load balancing instance is used to determine the target application server corresponding to the VIP network segment traffic according to the load balancing algorithm; and to send the VIP network segment traffic to the target application server through the internal network card, so that the target application server can process the VIP network segment traffic accordingly. The cloud load balancing system also includes an application programming interface (API) server and a subscription component. The load balancer includes a proxy component. Specifically: the API server, in response to a load balancing instance creation request, sends the request to the corresponding region's subscription component; the load balancing instance creation request is issued by the user through a user interface (UI). The subscription component allocates physical resources for the load balancing instance to be created and writes the integrated load balancing instance metadata information into the distributed database of the cloud load balancing system. The proxy component, upon detecting a write event to the load balancing instance metadata information in the distributed database, constructs the load balancing instance based on the load balancing instance metadata information. The cloud load balancing system also includes a service discovery module, wherein: the API server is further configured to respond to a listener creation request by sending the listener creation request to the subscription component of the corresponding region, the listener creation request being issued by the user through the user interface (UI); the subscription component is further configured to query the load balancer to which the listener to be created belongs, integrate the relevant information into the listener metadata, and then send the listener creation request to the service discovery module; the service discovery module is configured to integrate the backend address of the application server into the listener metadata, and write the integrated listener metadata information into the distributed database of the cloud load balancing system; the load balancer to which the listener to be created belongs is configured to construct the listener based on the listener metadata information when it detects a listener metadata information write event in the distributed database; The load balancer is connected to the target application server via a virtual switch.

2. The cloud load balancing system according to claim 1, characterized in that, The subscription component is also used for: Before allocating physical resources to the load balancer instance to be created, determine the available physical resources in the corresponding load balancer to meet the physical resources required by the load balancer instance to be created.

3. The cloud load balancing system according to claim 2, characterized in that, The subscription component is also used for: In response to the fact that the available physical resources do not meet the physical resources required for the load balancer instance to be created, a prompt message is issued to add a new load balancer.

4. The cloud load balancing system according to claim 1, characterized in that, The service discovery module is also used to subscribe to relevant events for different architectures.

5. The cloud load balancing system according to claim 4, characterized in that, The relevant events include Mesos events and / or Kubernetes events, and the service discovery module is specifically used for at least one of the following: In response to Mesos events, the backend address is obtained by tracing the server. In response to Kubernetes events, the backend address of the application is obtained through the cloud control matrix.

6. The cloud load balancing system according to any one of claims 1 to 3, characterized in that, The cloud load balancing system also includes a distributed database; the listener is also used for: Monitor whether the data in the distributed database is updated; In response to an update in the distributed database, the updated data is updated to the corresponding configuration file, and hot-loading is performed to make the update effective. The configuration file stores the IP address and port of the application server corresponding to the load balancer.

7. A cloud load balancing method, characterized in that, This system is applied to a cloud load balancing system, which includes a core switch, physical access switches, and at least two load balancers. Each load balancer deploys a listener and multiple load balancing instances. The core switch and the at least two load balancers all run Border Gateway Protocol (BGP). The core switch stores routing information for the VIP network segment corresponding to each load balancer. The cloud load balancing system also includes an Application Programming Interface (API) server and a subscription component. Each load balancer includes a proxy component. The system also includes a service discovery module. The load balancers and target application servers are connected via virtual switches. The cloud load balancing method includes: In response to detecting VIP network segment traffic, the core switch queries the routing information and directs the next hop of the VIP network segment traffic to the target load balancer among the at least two load balancers. The VIP network segment traffic carries the user IP and the target VIP. In response to detecting traffic in the VIP network segment, the listener in the target load balancer forwards the traffic in the VIP network segment to the target load balancer instance corresponding to the user IP based on the HAProxy rules. The target load balancing instance determines the target application server corresponding to the VIP network segment traffic according to the load balancing algorithm; and sends the VIP network segment traffic to the target application server through the internal network card, so that the target application server can process the VIP network segment traffic accordingly. In response to a load balancer instance creation request, the API server sends the load balancer instance creation request to the subscription component of the corresponding region. The load balancer instance creation request is issued by the user through the user interface (UI). The subscription component allocates physical resources to the load balancing instance to be created and writes the integrated load balancing instance metadata information into the distributed database of the cloud load balancing system. When the proxy component detects a write event to the load balancing instance metadata information in the distributed database, it constructs a load balancing instance based on the load balancing instance metadata information. In response to a listener creation request, the API server sends the listener creation request to the subscription component of the corresponding region. The listener creation request is issued by the user through the user interface (UI). The subscription component queries the load balancer to which the listener to be created belongs, integrates the relevant information into the listener metadata, and then sends the listener creation request to the service discovery module. The service discovery module integrates the backend address of the application server into the listener metadata, and writes the integrated listener metadata information into the distributed database of the cloud load balancing system. The load balancer to which the listener to be created belongs constructs the listener based on the listener metadata information written to the distributed database when it detects the listener metadata information being written.

Images