CN118158222A - Load balancer deployment method, device, electronic device, storage medium and product - Google Patents

Abstract

The present disclosure proposes a method, device, electronic device, storage medium and product for deploying a load balancer. The method comprises: obtaining cluster information of each cluster in the target cloud platform, wherein the cluster information at least includes the corresponding load balancer LB instance deployed in the cluster, the subnet to which the LB instance belongs and the cluster resource usage rate; in response to a request to create a target LB instance belonging to a first subnet, determining whether there is an LB instance belonging to the first subnet in the cluster of the target cloud platform; if the determination result is no, then deploying the target LB instance in the cluster with the lowest cluster resource usage rate based on the cluster information of each cluster in the target cloud platform.

Description

Load balancer deployment method, device, electronic device, storage medium and product

Technical Field

The present disclosure relates to the field of cloud computing technology, and in particular to a load balancer deployment method, device, electronic device, storage medium and product.

Background technique

Load balancing is a key component of high-availability network infrastructure. Cloud platform users can usually deploy multiple application servers, with different application servers handling different businesses. Then, by configuring the load balancing (LB) instance in the cluster, the LB instance in the cluster can be used to distribute requests to different servers in the cluster, thereby improving the performance and reliability of websites, applications, databases, or other services.

However, in the related technology, each time a LB instance is created, multiple message queue (MQ) messages need to be sent to query the resource usage on each cluster, which reduces the availability of the cluster. If there is a problem with the MQ service, the usage of the cluster resources cannot be obtained, resulting in the failure of creating the LB instance in the cluster.

Summary of the invention

The present disclosure provides a load balancer deployment method, device, electronic device, storage medium and product to solve the problems in the related art.

A first aspect of the present disclosure provides a load balancer deployment method, the method comprising:

Obtain cluster information of each cluster in the target cloud platform. The cluster information includes at least the load balancer LB instance deployed in the corresponding cluster, the subnet to which the LB instance belongs, and the cluster resource usage rate.

In response to a request to create a target LB instance belonging to the first subnet, determine whether there is an LB instance belonging to the first subnet in the cluster of the target cloud platform;

If the judgment result is no, the target LB instance is deployed in the cluster with the lowest cluster resource utilization based on the cluster information of each cluster in the target cloud platform.

In one embodiment, after determining whether there is an LB instance belonging to the first subnet in the cluster of the target cloud platform, the method provided by the present disclosure further includes:

If the judgment result is yes, based on the cluster information of each cluster in the target cloud platform, it is judged whether the cluster resource usage rate of the first cluster where the LB instance belonging to the first subnet exists reaches the preset cluster resource usage rate threshold;

If the judgment result is yes, the target LB instance is deployed in the second cluster with the lowest cluster resource utilization rate among the remaining clusters; wherein the remaining clusters refer to the clusters in the target cloud platform except the first cluster.

In one embodiment, deploying the target LB instance in the second cluster with the lowest cluster resource usage among the remaining clusters includes:

Bind the virtual IP address of the target LB instance to the port of the second cluster; the port refers to the port created when the cluster applies to the software-defined network SDN controller of the target cloud platform for subnet allocation.

In one embodiment, after determining whether the cluster resource usage rate of the first cluster having the LB instance belonging to the first subnet reaches a preset cluster resource usage rate threshold, the method provided by the present disclosure further includes:

If the judgment result is no, the target LB instance is deployed in the first cluster.

In one embodiment, the method provided by the present disclosure further includes:

In response to a third cluster having a fault in the target cloud platform, obtaining at least one first LB instance deployed on the third cluster and a subnet to which each first LB instance belongs based on cluster information of each cluster in the target cloud platform;

Based on the cluster information of each cluster in the target cloud platform, determine whether there is an LB instance in the healthy cluster that has the same subnet as the first LB instance; a healthy cluster refers to a cluster in the target cloud platform that has not experienced any failure;

If the judgment result is yes, the corresponding first LB instance is deployed in the first healthy cluster; the first healthy cluster refers to a healthy cluster in which there is an LB instance in the same subnet as the first LB instance.

In one embodiment, after determining whether there is an LB instance in the healthy cluster that is the same as the subnet to which the first LB instance belongs, the method provided by the present disclosure further includes:

If the judgment result is no, the corresponding first LB instance is deployed in the second healthy cluster; the second healthy cluster refers to the cluster with the lowest cluster resource utilization rate among the healthy clusters in which there is no LB instance in the same subnet as the first LB instance.

A second aspect of the present disclosure provides a load balancer deployment device, the device comprising:

An acquisition unit is used to acquire cluster information of each cluster in the target cloud platform, where the cluster information at least includes a load balancer LB instance deployed in the corresponding cluster, a subnet to which the LB instance belongs, and a cluster resource usage rate;

A determination unit, configured to determine, in response to a request to create a target LB instance belonging to the first subnet, whether there is an LB instance belonging to the first subnet in the cluster of the target cloud platform;

The deployment unit is used to deploy the target LB instance in the cluster with the lowest cluster resource usage based on the cluster information of each cluster in the target cloud platform if the judgment result is no.

A third aspect of the present disclosure provides an electronic device, including:

At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the method described in the embodiment of the first aspect of the present disclosure.

The fourth aspect embodiment of the present disclosure proposes a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to enable a computer to execute the method described in the first aspect embodiment of the present disclosure.

The fifth aspect embodiment of the present disclosure proposes a computer program product, including a computer program, which implements the method described in the first aspect embodiment of the present disclosure when executed by a processor.

In summary, the present disclosure proposes a load balancer deployment method, which includes: obtaining cluster information of each cluster in the target cloud platform, the cluster information at least including the load balancer LB instance that has been deployed in the corresponding cluster, the subnet to which the LB instance belongs, and the cluster resource utilization rate; in response to a request to create a target LB instance belonging to the first subnet, determining whether there is an LB instance belonging to the first subnet in the cluster of the target cloud platform; if the determination result is no, deploying the target LB instance in the cluster with the lowest cluster resource utilization rate based on the cluster information of each cluster in the target cloud platform.

Through the solution provided by the present disclosure, the health status of each cluster can be found through the Load Balancer-as-a-Service Agent (lbaas-agent) control node, and the LB instance belonging to the first subnet in the cluster can be determined according to the cluster index, so that the LB instance in each cluster can be efficiently located and managed, thereby improving the availability of the cluster. If there is no LB instance belonging to the same subnet in the cluster of the target cloud platform, by deploying the target LB instance of the first subnet in the cluster with the lowest resource utilization, the load balancing performance of the cluster is improved, which helps to utilize cluster resources and avoid resource waste.

It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings herein are incorporated into and constitute a part of the specification, illustrate embodiments consistent with the present disclosure, and together with the description are used to explain the principles of the present disclosure, and do not constitute improper limitations on the present disclosure.

FIG1 is a principle block diagram of a soft load balancing deployment architecture provided by an embodiment of the present disclosure;

FIG2 is a flow chart of a load balancer deployment method provided by an application example of the present disclosure;

FIG3 is a schematic diagram of a process of deploying a target LB instance in a second cluster according to an embodiment of the present disclosure;

FIG4 is a block diagram of a load balancer deployment architecture provided by an application example of the present disclosure;

FIG5 is a schematic diagram of a process of cross-cluster deployment of LB instances provided by an application example of the present disclosure;

FIG6 is a flow chart of a load balancer deployment method provided by an application example of the present disclosure;

FIG7 is a schematic diagram of a process of deploying a first LB instance in a first healthy cluster according to an embodiment of the present disclosure;

FIG8 is a flow chart of another load balancer deployment method provided by an application example of the present disclosure;

FIG9 is a schematic diagram of the structure of a load balancer deployment device provided in an embodiment of the present disclosure;

FIG. 10 is a schematic diagram of the hardware composition structure of an electronic device provided in an embodiment of the present disclosure.

Detailed ways

Embodiments of the present disclosure are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present disclosure, and should not be construed as limiting the present disclosure.

In the related technology, LBs under the same subnet are usually distributed in the same cluster, resulting in uneven use of cluster resources under the same subnet. When the cluster resources where the LB under the same subnet is located are full, it is impossible to continue to create LB under the subnet, and it is necessary to switch subnets to create new instances, thereby reducing the cluster utilization under the same subnet.

In related technologies, common load balancer deployment solutions are as follows:

(1) As shown in Figure 1, multiple clusters are deployed, and clusters support expansion and contraction;

(2) Each cluster contains two servers, active and standby, supporting active and standby high availability;

(3) A LB instance contains a pair of active and standby Linux Virtual Servers (LVS). Keepalived is used to implement high availability mechanism configuration and management between LVS clusters to achieve layer 4 traffic forwarding. Nginx is deployed in a distributed manner on the backend of LVS to achieve layer 7 traffic forwarding. When users send down information such as creating LB instances and listeners from the cloud platform, different LVS+NGINX namespaces (NAMESPCE) will be automatically created in each server to meet tenant isolation scenarios.

(4) When the user uses subnet 1 (subnet) to create a load balancer LB1 for the first time, lbaas-agent detects that there is no LB instance under this subnet in all clusters. It needs to apply to the Software Defined Network (SDN) controller to allocate a virtual local area network (VLAN) (different clusters have different VLAN ranges), create ports and other resources, and perform hierarchical binding operations. When the user accesses the LB, the SDN virtual tunnel endpoint (VTEP) device performs virtual extensible LAN (VXLAN) encapsulation and decapsulation to enable the created LB instance resources under this subnet to communicate with the backend server traffic under the same subnet, and then send the LB1 configuration to one of the clusters, such as cluster 1. When you use subnet 1 to create an LB instance later, use the allocated VLAN, port and other resources to bind the LB2 virtual Internet Protocol (VIP) address, LVS and NGINX Internet Protocol (IP) address to the port, and send the LB2 configuration to cluster 1 to achieve traffic interoperability. Each VLAN corresponds to a subnet, so the LBs under the same subnet are distributed on two servers in the same cluster. When NAMESPCE or other resources in cluster 1 are full, you cannot use subnet 1 to continue creating LB instances.

The above solution has the following defects:

Distributing LBs under the same subnet in the same cluster can easily cause uneven use of cluster resources. Some clusters have 100% resource utilization, while others have very low utilization. When the cluster resources of the LB under the same subnet are full, it is impossible to create LBs under the subnet. It is necessary to switch to subnet 2 to create new instances, which fall on idle clusters. This is unacceptable to cloud platform users. In addition, if the resource utilization of cluster 1 is full, when cluster 1 fails, all LB instances that have been configured in the cluster cannot be created in the new cluster due to the restrictions of the LB instances in the same subnet, resulting in the inability to migrate the LB instances in the failed cluster to the normal cluster.

In order to solve at least one defect in the related art, the present disclosure provides a load balancer deployment method, which can efficiently locate and manage the LB instances in each cluster by searching the health status of each cluster through the lbaas-agent control node and determining the LB instances belonging to the first subnet in the cluster according to the cluster index, thereby improving the availability of the cluster. If there is no LB instance belonging to the same subnet in the cluster of the target cloud platform, by deploying the target LB instance of the first subnet in the cluster with the lowest resource utilization, the load balancing performance of the cluster is improved, which helps to utilize cluster resources and avoid resource waste.

The present disclosure is further described in detail below with reference to the accompanying drawings and specific embodiments.

As shown in FIG2 , a load balancer deployment method provided in an embodiment of the present disclosure includes the following steps:

Step 201, obtaining cluster information of each cluster in the target cloud platform.

In one embodiment, the cluster information of each cluster can be obtained through the lbaas-agent management and control node.

In one embodiment, the cluster information includes at least the LB instance that has been deployed in the corresponding cluster, the subnet to which the LB instance belongs, and the cluster resource usage rate.

In one embodiment, the lbaas-agent management and control node can periodically detect the health status of different clusters by monitoring the agent heartbeat, and store the cluster health status in a database.

In one embodiment, the lbaas-agent control node can also be used to monitor the distribution of LB instances.

In one embodiment, the database storing the health status of the cluster may be any one of the three databases: MySQL, PostgreSQL, and Neutron, which is not limited in the present disclosure.

In one embodiment, by acquiring cluster information of each cluster in the target cloud platform, the LB instance in each cluster can be efficiently located and managed, thereby improving the availability of the cluster.

Step 202, in response to a request to create a target LB instance belonging to the first subnet, determining whether there is an LB instance belonging to the first subnet in the cluster of the target cloud platform;

In one embodiment, the target LB instance refers to a LB instance created in response to a request to create a target LB instance belonging to the first subnet.

In one embodiment, the first subnet may be a logical subnet divided in a local area network or a wide area network.

In one embodiment, the LB instance of the first subnet may be one or more, which is not limited in the present disclosure.

In one embodiment, when the lbaas-agent control node receives a request to create a target LB instance belonging to the first subnet, the lbaas-agent control node can query the database, which contains multiple LB instance IDs and corresponding subnet IDs. The LB instance under the first subnet can be searched based on the first subnet ID and the corresponding LB instance ID in the database.

Step 203, if the judgment result is no, then based on the cluster information of each cluster in the target cloud platform, the target LB instance is deployed in the cluster with the lowest cluster resource utilization.

In one embodiment, the database is queried through the lbaas-agent management and control node. If the LB instance under the first subnet cannot be found according to the first subnet ID and the corresponding LB instance ID, the target LB instance is deployed in the cluster with the lowest cluster resource utilization based on the cluster information of each cluster in the target cloud platform.

In one embodiment, if the LB instance under the first subnet cannot be found according to the first subnet ID and the corresponding LB instance ID, the steps of deploying the target LB instance in the cluster with the lowest cluster resource usage based on the cluster information of each cluster in the target cloud platform include:

Through the lbaas-agent control node, obtain the cluster information of each cluster in the target cloud platform and determine the cluster with the lowest cluster resource utilization;

On the selected cluster with the lowest cluster resource usage, use the deployment tools provided by the target cloud platform, such as Docker, Kubernetes, Ansible, Chef, Puppet, and other tools, to deploy the target LB instance to the cluster with the lowest cluster resource usage.

In one embodiment, by deploying the target LB instance in the cluster with the lowest cluster resource utilization, the load balancing performance of the cluster is improved, which helps to utilize cluster resources and avoid resource waste.

In summary, the present disclosure proposes a load balancer deployment method, which includes: obtaining cluster information of each cluster in the target cloud platform, the cluster information at least including the load balancer LB instance that has been deployed in the corresponding cluster, the subnet to which the LB instance belongs, and the cluster resource utilization rate; in response to a request to create a target LB instance belonging to the first subnet, determining whether there is an LB instance belonging to the first subnet in the cluster of the target cloud platform; if the determination result is no, deploying the target LB instance in the cluster with the lowest cluster resource utilization rate based on the cluster information of each cluster in the target cloud platform.

Through the solution provided by the present disclosure, the health status of each cluster is searched through the lbaas-agent control node and the LB instance belonging to the first subnet in the cluster is determined according to the cluster index, so that the LB instance in each cluster can be efficiently located and managed, thereby improving the availability of the cluster. If there is no LB instance belonging to the same subnet in the cluster of the target cloud platform, the target LB instance of the first subnet is deployed in the cluster with the lowest resource utilization, which improves the load balancing performance of the cluster, helps to utilize cluster resources, and avoids resource waste.

In one embodiment, as shown in FIG3 , after step 202, the method provided by the present disclosure includes the following steps:

Step 301: If the judgment result is yes, then based on the cluster information of each cluster in the target cloud platform, it is determined whether the cluster resource usage rate of the first cluster where the LB instance belonging to the first subnet exists reaches a preset cluster resource usage rate threshold;

In one embodiment, the first cluster refers to a cluster under the first subnet.

In one embodiment, the preset cluster resource usage rate threshold refers to a critical value of the cluster resource usage rate.

In one embodiment, the preset cluster resource usage threshold may be used to measure whether the LB instance of the first cluster can be created under the first subnet.

In one embodiment, since the LB instances of the first subnet are usually distributed in the same cluster, the resources of each cluster in the first subnet are unevenly used, which reduces the cluster utilization of the first subnet. Therefore, whether the cluster resource utilization of the first cluster using the LB instances of the first subnet reaches a preset cluster resource utilization threshold is used as a criterion for determining whether the LB instances of the first cluster can be created under the first subnet, thereby improving the utilization of the cluster under the first subnet.

Step 302: If the judgment result is yes, the target LB instance is deployed in the second cluster with the lowest cluster resource utilization rate among the remaining clusters.

In one embodiment, the second cluster refers to another cluster other than the first cluster under the first subnet.

In one embodiment, the remaining clusters refer to clusters in the target cloud platform except the first cluster.

In one embodiment, deploying the target LB instance in the second cluster with the lowest cluster resource usage among the remaining clusters includes:

Assign a virtual local area network (VLAN) to the second cluster, create a port (self_port), and create a gateway port (gateway_port) based on self_port and VLAN;

Bind the target LB instance virtual IP address to the second cluster port;

Create LVS and NGINX ports, bind the addresses of LVS and NGINX to the self_port of the second cluster, and create configuration files for keepalived and nginx. When accessing the LB instance VIP (virtual IP address), forward the traffic to the second cluster.

In one embodiment, since there is an LB instance belonging to the first subnet in the cluster of the target cloud platform, and the cluster resource usage of the first cluster of LB instances belonging to the first subnet reaches a preset cluster resource usage threshold, the cluster utilization in the first subnet is improved by deploying the target LB instance in the second cluster with the lowest cluster resource usage among the remaining clusters.

In one embodiment, step 302 includes:

Bind the virtual IP address of the target LB instance to the port of the second cluster.

In one embodiment, the port refers to the port created when the cluster applies to the SDN controller of the target cloud platform for allocation of a subnet.

In one embodiment, the step of binding the virtual IP address of the target LB instance to the port port of the second cluster includes:

Determine the network topology of the second cluster: The network structure of the second cluster includes network devices, subnets, IP address ranges, etc.;

Configure virtual IP address: Configure the virtual IP address of the target LB instance, which can be done through the management console or command line interface of the target cloud platform;

Configure port forwarding rules: Configure port forwarding rules to forward traffic from the virtual IP address to the port of the second cluster;

Configure the network devices of the second cluster: Make sure that the network devices in the second cluster can accept traffic from the virtual IP address;

Test and verify: After completing the above configuration, test and verify to ensure that the virtual IP address is bound to the port of the second cluster. This can be verified by sending traffic and checking whether the port in the second cluster receives the traffic correctly;

In one embodiment, binding the virtual IP address of the target LB instance to the port of the second cluster can achieve high availability of the second cluster. If a node in the cluster fails and is unavailable, the target LB instance can automatically forward traffic to a healthy node to ensure normal operation of the business.

In one embodiment, after step 301, the method provided by the present disclosure further includes:

If the judgment result is no, the target LB instance is deployed in the first cluster.

In one embodiment, if the LB instance under the first subnet can be found according to the first subnet ID and the corresponding LB instance ID in the database, and the cluster utilization rate of the first cluster does not reach the preset cluster resource utilization rate threshold, the target LB instance is deployed in the first cluster.

In one embodiment, if the LB instance under the first subnet can be found based on the first subnet ID and the corresponding LB instance ID in the database, when the target LB instance is deployed in the first cluster, the target LB instance does not need to apply to the SDN controller for VLAN allocation and port creation, but only needs to bind the virtual IP address of the target LB instance to the port port of the first cluster, thereby improving the configuration efficiency of the target LB instance.

As shown in Figures 4 and 5: Figure 4 is a principle block diagram of the load balancer deployment architecture provided by the application example of the present disclosure, and Figure 5 is a schematic diagram of the process of cross-cluster deployment of LB instances provided by the application example of the present disclosure. Taking the case that there is an LB instance belonging to the first subnet in the first cluster of the target cloud platform, and the cluster utilization rate of the first cluster reaches the preset cluster resource utilization rate threshold, and continuing to create an LB instance under the first subnet as an example, it includes:

After receiving the request to create an LB instance, the lbaas-agent control node queries the database and selects a cluster whose health status is active.

The first cluster already has an LB instance under the first subnet and the resource usage rate (usage_rate) is 1. The number of LB instances under the first subnet in other clusters is 0. At this time, except for the first cluster, other clusters simultaneously apply to the SDN controller for allocation of a virtual local area network (VLAN) and creation of a port (self_port) and a gateway port (gateway_port);

The second cluster is assigned VLAN 200, and the second cluster self_port is created. A gateway_port is created based on the second cluster self_port and VLAN 200. The third cluster is assigned VLAN 300, and the third cluster self_port is created. A gateway_port is created based on the third cluster self_port and VLAN 300. The remaining clusters simultaneously create corresponding resources. When the LB instance is configured to a cluster, it is only necessary to bind the LB instance VIP address to the self_port, and create the keepalived and nginx configuration files to ensure that the traffic can be forwarded to the cluster normally.

Query the database to select the cluster with the least cluster resource usage. At this time, confirm the cluster configured for the LB instance, such as the second cluster, bind the LB instance VIP address to the self_port created in the second cluster, create LVS and NGINX ports, and bind the addresses of LVS and NGINX to the self_port of the second cluster. At the same time, create configuration files for keepalived and nginx. When accessing the LB instance VIP, the traffic is forwarded to the second cluster.

The lbaas-agent control node periodically detects the number of LB instances created on all clusters, CPU usage, memory usage, disk usage, and network card inbound and outbound traffic information, and calculates and updates the resource usage, subnet ID, cluster ID, and LB instance number information of each cluster in the database.

As shown in FIG. 6 , FIG. 6 is a flow chart of a load balancer deployment method provided by an application example of the present disclosure, comprising the following steps:

Step 601, obtaining cluster information of each cluster in the target cloud platform;

Step 602, in response to a request to create a target LB instance belonging to the first subnet, determining whether there is an LB instance belonging to the first subnet in the cluster of the target cloud platform;

If yes, proceed to step 603;

If not, proceed to step 604;

Step 603: Based on the cluster information of each cluster in the target cloud platform, determine whether the cluster resource usage rate of the first cluster where the LB instance belonging to the first subnet exists reaches a preset cluster resource usage rate threshold;

If yes, proceed to step 604;

If not, proceed to step 605;

Step 604: deploy the target LB instance in the second cluster with the lowest cluster resource utilization rate among the remaining clusters;

Step 605: deploy the target LB instance in the first cluster.

In one embodiment, as shown in FIG7 , the method provided by the present disclosure further includes the following steps:

Step 701, in response to a third cluster having a fault in the target cloud platform, obtaining at least one first LB instance deployed on the third cluster and a subnet to which each first LB instance belongs based on cluster information of each cluster in the target cloud platform;

In one embodiment, the third cluster ID in the database is searched through the lbaas-agent management node, the subnet ID corresponding to at least one first LB instance ID under the third cluster is searched according to the third cluster ID in the database, and the first LB instance is found according to the subnet ID corresponding to the first LB instance ID.

In one embodiment, the configuration information of listener, pool, health monitor, etc. is found according to the first LB instance ID. Among them, the listener is responsible for receiving client requests and forwarding the requests to the nodes in the cluster. When the listener receives the request, the pool is used to process the request to ensure the high availability and load balancing of the cluster. The health monitor is used to monitor the health status of the nodes in the cluster. If a node failure is detected, the LB instance stops forwarding traffic to the node.

In one embodiment, by obtaining at least one first LB instance deployed on the third cluster and the subnet to which each first LB instance belongs, the network isolation between different LB instances and the LB instance configuration information are understood, and the migration processing time of migrating the LB instance from the faulty cluster to the healthy cluster is optimized.

Step 702: Based on the cluster information of each cluster in the target cloud platform, determine whether there is a LB instance in the healthy cluster that has the same subnet as the first LB instance.

In one embodiment, a healthy cluster refers to a cluster in the target cloud platform that has not experienced any failure.

Step 703: If the judgment result is yes, the corresponding first LB instance is deployed in the first healthy cluster.

In one embodiment, the first healthy cluster refers to a healthy cluster having a LB instance in the same subnet as that to which the first LB instance belongs.

In one embodiment, if there is an LB instance in the healthy cluster that is in the same subnet as the first LB instance, it is only necessary to update the VIP address of the first LB instance to the port of the first healthy cluster, and deploy the configuration information of the LB instance in the first cluster. There is no need to re-apply for VLAN and create port resources from the SDN controller, thereby optimizing the fault handling time.

In one embodiment, the configuration information of the LB instance includes configuration information such as listener, pool, and health monitor.

In one embodiment, after step 702, the method provided by the present disclosure further includes:

If the judgment result is no, the corresponding first LB instance is deployed in the second healthy cluster.

In one embodiment, the second healthy cluster refers to a cluster with the lowest cluster resource usage among the healthy clusters that do not have an LB instance in the same subnet as that to which the first LB instance belongs.

In one embodiment, if there is no LB instance in the healthy cluster that is the same as the subnet to which the first LB instance belongs, the LB instances in different subnets in the faulty cluster are deployed in clusters with cluster resource utilization from low to high according to the number of LB instances in different subnets in the faulty cluster from high to low, and the cluster port information is updated and the LB instance configuration information is redeployed.

In one embodiment, the corresponding first LB instance is deployed in the second healthy cluster, which improves the load balancing performance of the cluster, helps to utilize cluster resources, and avoids resource waste.

As shown in FIG8 , FIG8 is a flow chart of a load balancer deployment method provided by an application example of the present disclosure, comprising the following steps:

Step 801, in response to a third cluster having a fault in the target cloud platform, obtaining at least one first LB instance deployed on the third cluster and a subnet to which each first LB instance belongs based on cluster information of each cluster in the target cloud platform;

Step 802: Based on the cluster information of each cluster in the target cloud platform, determine whether there is an LB instance in the healthy cluster that has the same subnet as the first LB instance;

If yes, proceed to step 803;

If not, proceed to step 804;

Step 803, deploying the corresponding first LB instance in the first healthy cluster;

Step 804: deploy the corresponding first LB instance in the second healthy cluster.

In order to implement the load balancer deployment method provided by the embodiment of the present disclosure, the embodiment of the present disclosure also provides a load balancer deployment device, as shown in Figure 9. Figure 9 is a structural diagram of the load balancer deployment device provided by the embodiment of the present disclosure, and the load balancer deployment device 900 includes:

The acquisition unit 901 is used to acquire cluster information of each cluster in the target cloud platform, where the cluster information at least includes the load balancer LB instance deployed in the corresponding cluster, the subnet to which the LB instance belongs, and the cluster resource usage rate;

A determination unit 902 is configured to determine, in response to a request to create a target LB instance belonging to the first subnet, whether there is an LB instance belonging to the first subnet in the cluster of the target cloud platform;

The deployment unit 903 is used to deploy the target LB instance in the cluster with the lowest cluster resource usage based on the cluster information of each cluster in the target cloud platform if the judgment result is no.

In one embodiment, the deployment unit 903 is specifically configured to:

If the judgment result is yes, based on the cluster information of each cluster in the target cloud platform, it is judged whether the cluster resource usage rate of the first cluster where the LB instance belonging to the first subnet exists reaches the preset cluster resource usage rate threshold;

If the judgment result is yes, the target LB instance is deployed in the second cluster with the lowest cluster resource utilization rate among the remaining clusters; wherein the remaining clusters refer to the clusters in the target cloud platform except the first cluster.

In one embodiment, the load balancer deployment device 900 further includes a binding unit, and the binding unit is used to:

Bind the virtual IP address of the target LB instance to the port of the second cluster; the port refers to the port created when the cluster applies to the software-defined network SDN controller of the target cloud platform for subnet allocation.

In one embodiment, the deployment unit 903 is specifically configured to:

If the judgment result is no, the target LB instance is deployed in the first cluster.

In one embodiment, the load balancer deployment device 900 further includes deploying a first LB instance unit, where the first LB instance unit is deployed to:

In response to a third cluster having a fault in the target cloud platform, obtaining at least one first LB instance deployed on the third cluster and a subnet to which each first LB instance belongs based on cluster information of each cluster in the target cloud platform;

Based on the cluster information of each cluster in the target cloud platform, determine whether there is an LB instance in the healthy cluster that has the same subnet as the first LB instance; a healthy cluster refers to a cluster in the target cloud platform that has not experienced any failure;

If the judgment result is yes, the corresponding first LB instance is deployed in the first healthy cluster; the first healthy cluster refers to a healthy cluster in which there is an LB instance in the same subnet as the first LB instance.

In one embodiment, a first LB instance unit is deployed, specifically for:

If the judgment result is no, the corresponding first LB instance is deployed in the second healthy cluster; the second healthy cluster refers to the cluster with the lowest cluster resource utilization rate among the healthy clusters in which there is no LB instance in the same subnet as the first LB instance.

It should be noted that: the load balancer deployment device provided in the above embodiment only uses the division of the above program modules as an example when performing load balancer deployment. In actual applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the load balancer deployment device is divided into different program modules to complete all or part of the processing described above. In addition, the load balancer deployment device provided in the above embodiment and the load balancer deployment method embodiment provided in the embodiment of the present disclosure belong to the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

Figure 10 is a schematic diagram of the hardware composition structure of an electronic device provided in an embodiment of the present disclosure. As shown in Figure 10, the electronic device 1000 includes at least one processor 1002; and a memory 1001 that is communicatively connected to the at least one processor 1002; wherein the memory 1001 stores instructions that can be executed by the at least one processor 1002, and the instructions are executed by the at least one processor 1002 to implement the steps of the load balancer deployment method in the embodiment of the present disclosure.

Optionally, the electronic device may specifically be a load balancer deployment device in an embodiment of the present application, and the electronic device may implement the corresponding processes implemented by the load balancer deployment device in each method in the embodiment of the present application, which will not be described in detail here for the sake of brevity.

It is understood that the electronic device also includes a communication interface 1003. The various components in the electronic device are coupled together through a bus system 1004. It is understood that the bus system 1004 is used to realize the connection and communication between these components. In addition to the data bus, the bus system 1004 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, various buses are marked as bus system 1004 in FIG. 10.

It can be understood that the memory 1001 can be a volatile memory or a non-volatile memory, and can also include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM); the magnetic surface memory can be a disk memory or a tape memory. The volatile memory can be a random access memory (RAM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available, such as static random access memory (SRAM), synchronous static random access memory (SSRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), direct memory bus random access memory (DRRAM). The memory 1001 described in the embodiments of the present invention is intended to include, but is not limited to, these and any other suitable types of memory.

The method disclosed in the above embodiment of the present disclosure can be applied to the processor 1002, or implemented by the processor 1002. The processor 1002 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the hardware integrated logic circuit in the processor 1002 or the instruction in the form of software. The above processor 1002 may be a general-purpose processor, a DSP, or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. The processor 1002 can implement or execute the various methods, steps and logic block diagrams disclosed in the embodiments of the present invention. The general-purpose processor may be a microprocessor or any conventional processor, etc. In combination with the steps of the method disclosed in the embodiment of the present invention, it can be directly embodied as a hardware decoding processor to execute, or it can be executed by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium, which is located in the memory 1001. The processor 1002 reads the information in the memory 1001 and completes the steps of the above method in combination with its hardware.

In an exemplary embodiment, the electronic device may be implemented by one or more application specific integrated circuits (ASIC), DSP, programmable logic device (PLD), complex programmable logic device (CPLD), FPGA, general purpose processor, controller, MCU, microprocessor, or other electronic components to execute the aforementioned method.

The embodiment of the present disclosure also provides a non-transitory computer-readable storage medium storing computer instructions, where the computer instructions are used to enable a computer to implement the steps of the load balancer deployment method of the embodiment of the present invention when executed.

Optionally, the computer-readable storage medium can be applied to the load balancer deployment device in the embodiments of the present application, and the computer instructions enable the computer to execute the corresponding processes implemented by the load balancer deployment device in the various methods of the embodiments of the present application. For the sake of brevity, they are not repeated here.

The embodiment of the present disclosure also provides a computer program product, including a computer program, which implements the steps of the load balancer deployment method provided by the embodiment of the present invention when executed by a processor.

In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are only schematic. For example, the division of units is only a logical function division. There may be other division methods in actual implementation, such as: multiple units or components can be combined, or can be integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the components shown or discussed can be through some interfaces, and the indirect coupling or communication connection of devices or units can be electrical, mechanical or other forms.

The units described above as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units; some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

In addition, all functional units in the embodiments of the present invention may be integrated into one processing unit, or each unit may be separately used as a unit, or two or more units may be integrated into one unit; the above-mentioned integrated units may be implemented in the form of hardware or in the form of hardware plus software functional units.

A person of ordinary skill in the art can understand that: all or part of the steps of implementing the above-mentioned method embodiment can be completed by hardware related to program instructions, and the aforementioned program can be stored in a computer-readable storage medium, which, when executed, executes the steps of the above-mentioned method embodiment; and the aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, ROM, RAM, magnetic disks or optical disks.

Alternatively, if the above-mentioned integrated unit of the present invention is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present invention can be essentially or partly reflected in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the methods of each embodiment of the present invention. The aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, ROM, RAM, magnetic disks or optical disks.

The above are only specific embodiments of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art who is familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed by the present invention, which should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be based on the protection scope of the claims.

Claims (10)

1. A method for deploying a load balancer, comprising:

Acquiring cluster information of each cluster in a target cloud platform, wherein the cluster information at least comprises a corresponding load balancer LB instance deployed by the cluster, a subnet to which the LB instance belongs and a cluster resource utilization rate;

Responding to a request for creating a target LB instance belonging to a first subnet, and judging whether the LB instance belonging to the first subnet exists in the cluster of the target cloud platform;

If the judgment result is negative, the target LB instance is deployed on the cluster with the lowest cluster resource utilization rate based on the cluster information of each cluster in the target cloud platform.

2. The method of claim 1, wherein after said determining whether there is an LB instance belonging to the first subnet in the cluster of the target cloud platform, the method further comprises:

If so, judging whether the cluster resource utilization rate of a first cluster of the LB instance belonging to the first subnet reaches a preset cluster resource utilization rate threshold or not based on cluster information of each cluster in the target cloud platform;

If yes, deploying the target LB instance in a second cluster with the lowest cluster resource utilization rate in the rest clusters; the remaining clusters refer to clusters except the first cluster in the target cloud platform.

3. The method of claim 2, wherein the deploying the target LB instance in the second cluster with the lowest cluster resource utilization among the remaining clusters comprises:

Binding the virtual IP address of the target LB instance to a port of the second cluster; the port refers to a port which is created when the cluster applies for the assignment of a subnet to a software defined network SDN controller of the target cloud platform.

4. The method of claim 2, wherein after determining whether the cluster resource usage of the first cluster in which the LB instance belongs to the first subnet reaches a preset cluster resource usage threshold, the method further comprises:

if not, deploying the target LB instance in the first cluster.

5. The method of claim 1, wherein the method further comprises:

Responding to the existence of a third cluster with faults in the target cloud platform, and acquiring at least one first LB instance deployed on the third cluster and a subnet to which each first LB instance belongs based on cluster information of each cluster in the target cloud platform;

Judging whether LB instances which are the same as the subnet to which the first LB instance belongs exist in a healthy cluster or not based on cluster information of each cluster in the target cloud platform; the healthy clusters refer to clusters which do not have faults in the target cloud platform;

If yes, deploying the corresponding first LB instance in the first health cluster; the first health cluster refers to a health cluster in which there are the same LB instances as the subnet to which the first LB instance belongs.

6. The method of claim 5, wherein after determining whether the same LB instance exists in the healthy cluster as the subnet to which the first LB instance belongs, the method further comprises:

if the judgment result is negative, deploying the corresponding first LB instance in the second health cluster; the second healthy cluster refers to a healthy cluster in which the same LB instance as the subnet to which the first LB instance belongs does not exist, and the cluster resource utilization rate is the lowest.

7. A load balancer deployment apparatus, comprising:

The system comprises an acquisition unit, a target cloud platform and a storage unit, wherein the acquisition unit is used for acquiring cluster information of each cluster in the target cloud platform, and the cluster information at least comprises a corresponding load balancer LB instance in which the cluster is deployed, a subnet to which the LB instance belongs and a cluster resource utilization rate;

The judging unit is used for responding to a request for creating a target LB instance belonging to a first subnet and judging whether the LB instance belonging to the first subnet exists in the cluster of the target cloud platform or not;

And the deployment unit is used for deploying the target LB instance on the cluster with the lowest cluster resource utilization rate based on the cluster information of each cluster in the target cloud platform if the judgment result is negative.

8. An electronic device, comprising:

At least one processor; and

A memory communicatively coupled to the at least one processor; wherein,

The memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 6.

9. A non-transitory computer readable storage medium storing computer instructions for causing the computer to perform the method of any one of claims 1 to 6.

10. A computer program product comprising a computer program which, when executed by a processor, implements the method of any one of claims 1 to 6.