CN104935672A - High available realizing method and equipment of load balancing service - Google Patents
High available realizing method and equipment of load balancing service Download PDFInfo
- Publication number
- CN104935672A CN104935672A CN201510376962.1A CN201510376962A CN104935672A CN 104935672 A CN104935672 A CN 104935672A CN 201510376962 A CN201510376962 A CN 201510376962A CN 104935672 A CN104935672 A CN 104935672A
- Authority
- CN
- China
- Prior art keywords
- node
- load
- load equalizer
- load balancing
- balancing service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1038—Load balancing arrangements to avoid a single path through a load balancer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention discloses a high available realizing method of a load balancing service. The method is applied to load balancing nodes in a load balancing service cluster of Openstack. The method comprises the steps as follows: switching a second LB node used as any backup LB node of the load balancing service cluster as a main LB node after LBaas agent on the first LB node used as the main LB node of the load balancing service cluster is failed, configuring a virtual host name of the load balancing service cluster as a self virtual host name, and starting the LBaas agent; transmitting a synchronous request message carried with the virtual host name to a control node; receiving a synchronous response message returned by the control node, and creating each load balancer according to configuration information of each load balancer carried by the synchronous response message and port numbers which correspond to each load balancer one by one.
Description
Technical field
The present invention relates to communication technical field, particularly relate to a kind of load balancing service high availability implementation method and equipment.
Background technology
Openstack is a cloud computing platform that user can be helped to build and manage publicly-owned cloud, privately owned cloud etc.Neutron is the networking component in Openstack, the virtual of network function is provided, not only network flexibly can be provided to connect for tenant, the high-level service of L4 ~ L7 can also be provided, such as load balancing service (Loadbalance as a service, LBaas) etc., user can by more application deployment in the cloud environment of oneself by these services.
The realization of LBaas service roughly divides two parts, a part operates in the Controlling vertex of openstack, for user the access of application programming interface (Application Programming Interface, API) is provided, the additions and deletions of database change look into and user request scheduling; A part is as LBaas agent, generally operate on load balancing (Loadbalance, LB) node, be used for configuring and disposing load equalizer, LB node is the node running LBaas agent, such as network node or independent virtual machine VM.Controlling vertex receives after user creates the request of load equalizer, this request scheduling can be started on the LB node of LBaasa gent to certain.Each LB node starting LBaas agent can report own node title (hostname) to Controlling vertex; In the database of Controlling vertex, the LB node of each startup LBaas agent identifies the configuration information preserving each load equalizer that this LB node creates by self hostname, when such LB node restarts LBaas agent, can obtain from the database of Controlling vertex by the load equalizer configuration information that this LB node has created, then on this LB node, regenerate these load equalizers.
Summary of the invention
In view of this, the present invention proposes a kind of load balancing service high availability implementation method and equipment, efficiently solve the flow interrupt problem that single point failure point in prior art is brought.
The technical scheme that the present invention proposes is:
A kind of load balancing service high availability implementation method, the method is applied to the load balancing node in the load balancing service cluster of Openstack, and the method comprises:
After acting on behalf of LBaas agent inefficacy as the load balancing service on a LB node of the main LB node of load balancing service cluster, the 2nd LB node as the arbitrary standby LB node of load balancing service cluster switches to main LB node, the virtual hostname of described load balancing service cluster is configured to self virtual hostname, and starts the LBaas agent of described Section Point;
Transmission carries the synchronization request message of described virtual hostname to described Controlling vertex;
Receive the syn ack message that described Controlling vertex is responded described synchronization request message, described syn ack message carries the configuration information of each load equalizer mated with described virtual hostname, and described each load equalizer port numbers one to one;
According to configuration information and the described each load equalizer of described each load equalizer port numbers establishment one to one of described each load equalizer.
Realize a load balancing node device for load balancing service High Availabitity, this equipment is applied to the load balancing service cluster of Openstack, and during the two LB node of this equipment as the standby LB node of load balancing service cluster, this equipment comprises:
Handover module, after LBaas agent inefficacy is acted on behalf of in load balancing service on a LB node of the main LB node as load balancing service cluster, described 2nd LB node is switched to main LB node, the virtual hostname of described load balancing service cluster is configured to self virtual hostname, and starts the LBaas agent of described Section Point;
Sending module, for send carry described virtual hostname synchronization request message to described Controlling vertex;
Receiver module, for receiving the syn ack message that described Controlling vertex is responded described synchronization request message, described syn ack message carries the configuration information of each load equalizer mated with described virtual hostname, and described each load equalizer port numbers one to one;
Load equalizer creation module, for according to the configuration information of described each load equalizer and described each load equalizer one to one port numbers create described each load equalizer.
To sum up, the present invention proposes a kind of load balancing service high availability implementation method, in the method, load balancing service cluster comprises main LB node and standby LB node, only main LB node starts LBaas agent, after the LBaas agent on main LB node lost efficacy, standby LB node switches to new main LB node, and start LBaas agent, the configuration information of each load equalizer then generated on the synchronous former main LB node of Controlling vertex request and each load equalizer port numbers one to one, regenerate each load equalizer, recover the service traffics forwarded by former main LB node, the present invention is by the LB Joint Enterprise backup LB node for starting LBaas agent, switched to new main LB node by backup LB node and regenerated each load equalizer after the LBaas agent on main LB node loses efficacy, achieve the High Availabitity of load balancing service.
Accompanying drawing explanation
Fig. 1 is the networking diagram of technical solution of the present invention;
Fig. 2 is the flow chart of technical solution of the present invention;
Fig. 3 is the group-network construction figure of one embodiment of the invention;
Fig. 4 is the networking diagram of the inventive method embodiment;
Fig. 5 is the flow chart of embodiment of the method;
Fig. 6 is Neutron LBaas Organization Chart in the embodiment of the present invention;
Fig. 7 is the load balancing node device structure chart of the embodiment of the present invention.
Embodiment
In prior art, Controlling vertex can manage the LB node of multiple startup LBaas agent, by dispatching algorithm, user is created the request scheduling of load equalizer on the LBaas agent of certain LB node, the LBaas agent that each LB node starts can generate and configure multiple load equalizer.Therefore, the LBaas agent be deployed on LB node is single point failure point, if do not done any improvement, when certain LB node down machine, LBaas agent on this LB node lost efficacy, and then each load equalizer resulting through the LBaasagent establishment on LB node is also unavailable, uses the flow of load balancing service on this LB node to interrupt.
Therefore, technical solution of the present invention proposes a kind of high availability scheme realizing load balancing service, create load balancing service cluster, load balancing service cluster is made up of for LB node main LB node and at least one, only main LB node starts LBaas agent, when main LB node down machine, one of them switches to new main LB node for LB node, new main LB node starts LBaas agent, and configuration information and each load equalizer port numbers one to one of each load equalizer be dispatched on former main LB node is obtained from Controlling vertex, new main LB node regenerates each load equalizer be originally created on former main LB node, and then recover the business of user, the present invention proposes a kind of implementation method of load balancing service High Availabitity, the technical scheme of the embodiment of the present invention is:
Fig. 1 is the networking structure figure of technical solution of the present invention, as shown in Figure 1, the load balancing service of Openstack is provided by Controlling vertex and load balancing service cluster, load balancing service cluster comprises main LB node, and be called a LB node, at least one is for LB node, the standby LB node of new main LB node is wherein switched to be called the 2nd LB node, Fig. 2 is the flow chart of the embodiment of the present invention, as shown in Figure 2, comprises the following steps:
Step 201: after the LBaas agent on a LB node lost efficacy, the 2nd LB node switched to main LB node, and the virtual hostname of load balancing service cluster is configured to self virtual hostname, and starts the LBaas agent of self.
In this step, main LB node in load balancing service cluster is an entirety for LB node with each for Controlling vertex, only main LB node starts LBaas agent in load balancing service cluster, and create each load equalizer and carry out forwarding service flow, the forwarding of the standby not responsible flow of LB node.
Load balancing service cluster is created by keeper, keeper is load balancing service cluster configuration virtual hostname and virtual ip address, and the virtual hostname of this load balancing service cluster and the corresponding relation of virtual ip address are configured on Controlling vertex, after the main LB node startup LBaasagent of load balancing service cluster, the virtual hostname of load balancing service cluster is configured to self virtual hostname, the virtual ip address of load balancing service cluster is configured to self virtual ip address, thus make Controlling vertex pass through the position of the main LB node of the local virtual ip address of preservation and the corresponding relation determination load balancing service cluster of virtual hostname.
Therefore, after the LBaas agent on a LB node lost efficacy, 2nd LB node switches to new main LB node, start LBaas agent, and the virtual hostname of load balancing service cluster is configured to self virtual hostname, the virtual ip address of load balancing service cluster is configured to self virtual ip address, and after this, by the local virtual ip address of preservation and the corresponding relation of virtual hostname, Controlling vertex determines that the main LB node of this load balancing service cluster is the 2nd LB node.
In addition, after the LBaas agent on a LB node lost efficacy, first a LB node was attempted restarting LBaas agent in the machine, if restart unsuccessfully, the 2nd LB node just switches to new main LB node; If the LBaas agent on a LB node is restarted successfully, then a LB node continues the forwarding as main LB node bearer service flow.
Step 202: the 2nd LB node transmission carries the synchronization request message of virtual hostname to Controlling vertex.
In this step, 2nd LB node needs to send to Controlling vertex the synchronization request message carrying virtual hostname, Request Control node by the configuration information of each load equalizer of scheduling on a LB node and each load equalizer one to one port numbers be synchronized to the 2nd LB node, make the 2nd LB node can re-create each load equalizer of scheduling on a LB node, take over the load balancing business of a LB node completely.
Wherein, the configuration information of each load equalizer dispatched on a LB node comprises: the port id etc. that the load-balancing algorithm that the pool ids (being equivalent to load equalizer id) on the LBaas agent of a LB node, the monitoring associated by certain pool (being used for monitoring provides the health status of the rear end server of service), each load equalizer use, pool (load equalizer) associate.
Controlling vertex end preserves the configuration information of the load equalizer of scheduling on a LB node, is that the virtual hostname by preserving a LB node realizes with the corresponding relation of the load equalizer configuration information of scheduling on this main LB node.Therefore, the 2nd LB node carries virtual hostname when Controlling vertex sends synchronization request message, then Controlling vertex can determine the load equalizer configuration information of coupling according to the virtual hostname carried in synchronization request message.During the main LB node of the one LB node as load balancing service cluster, creating one to one after port from load equalizer with it when it is each scheduling, can Controlling vertex be sent to preserve the corresponding relation between this load equalizer and the port numbers of port one to one, so far, no matter which this load equalizer is created in switches on the standby LB node of new main LB node, and this load equalizer one to one port numbers is constant.
Step 203: the 2nd LB node receives the syn ack message that Controlling vertex is responded synchronization request message, this syn ack message carries the configuration information of each load equalizer mated with the virtual hostname of the 2nd LB node, and each load equalizer port numbers one to one.
In this step, Controlling vertex determines each load equalizer mated with this virtual hostname according to the virtual hostname that synchronization request message carries, and determine and each load equalizer mated port numbers one to one according to each load equalizer of the coupling determined, by the load equalizer of the configuration information of the load equalizer of each coupling determined and each coupling one to one port numbers be carried in syn ack message and send to the 2nd LB node.
Step 204: the 2nd LB node according to the configuration information of each load equalizer and each load equalizer one to one port numbers create each load equalizer.
In this step, the 2nd LB node according to the configuration information of each load equalizer carried in syn ack message and each load equalizer one to one port numbers create each load equalizer, concrete steps are:
2nd LB node loads the configuration information of each load equalizer received, by each load equalizer received one to one the corresponding relation of port numbers and the true host name of the 2nd LB node be carried on to upgrade in message and send to Controlling vertex, make Controlling vertex upgrade local above-mentioned each load equalizer true host name of main LB node that port numbers is corresponding one to one of preserving;
Create with each load equalizer port one to one, and by each load equalizer received one to one port numbers be configured at establishment with on each load equalizer one to one port.
Wherein, when a LB node is main LB node, it often creates a load equalizer, just Controlling vertex is sent to preserve the corresponding relation of the true host name of the port numbers of this load equalizer and a LB node, the virtual switch of increasing income making the follow-up corresponding relation by this port numbers and true host name of Controlling vertex be transmitted to a LB node is acted on behalf of (open vswitch agent), openvswitch agent for a LB node carries out issuing of stream table, be prior art herein, no longer describe in detail.What preserve due to Controlling vertex is the corresponding relation of true host name and port numbers, after the 2nd LB node switches to main LB node, be created in the true host name that true main frame corresponding to the port numbers of the port of the load equalizer on the 2nd LB node is called the 2nd LB node, it is no longer the true host name of a LB node, therefore the 2nd LB node transmission carries the renewal message of the port numbers of each load equalizer and the corresponding relation of self true host name to Controlling vertex, to upgrade true host name corresponding to the port numbers being created in the load equalizer on the 2nd LB node that Controlling vertex is preserved.
In this step, 2nd LB node is according to after load equalizer configuration information and each load equalizer port numbers establishment one to one load equalizer, periodically transmission carries the heartbeat message of virtual hostname to Controlling vertex, and whether the LBaas agent that Controlling vertex is monitored on the 2nd LB node is effective.
Further, technical solution of the present invention can adopt pacemaker and corosync as cluster management instrument, each LB node respectively in load management balancing service cluster.Wherein, pacemaker is responsible for startup and the stopping of LBaas agent on LB node in load balancing service cluster, and corosync is responsible for the telecommunication management between load balancing service cluster interior joint, particularly:
Suppose that balancing cluster is made up of lbnode1 and lbnode2 by load, the real IP address of lbnode1 is 10.0.0.21, and true main frame is called lbnode1; The real IP address of lbnode2 is 10.0.0.41, and true main frame is called lbnode2, and wherein, lbnode1 is main LB node, and lbnode2 is standby LB node.
Lbnode1 installs corosync, and configuration corosync uses the 10.0.0.0/24 network segment as the heartbeat between lbnode1 and lbnode2, starts corosync service, and arranges corosync for start self-starting, guarantees that corosync can identify lbnode1; Lbnode2 installs corosync, and configuration corosync uses the 10.0.0.0/24 network segment as the heartbeat between lbnode1 and lbnode2, starts corosync service, and arranges corosync for start self-starting, guarantees that corosync can identify lbnode2.
Lbnode1 installs and starts pacemaker, pacemaker is set for start self-starting, write RA (the Resource Agent of LBaas agent, Resource Broker) script, the pacemaker on lbnode1 realizes by RA script the LBaas agent starting, stop and monitoring lbnode1; Lbnode2 installs and starts pacemaker, arrange pacemaker for self-starting of starting shooting, write the RA script of LBaas agent, the pacemaker on lbnode2 realizes by RA script the LBaasagent starting, stop and monitoring lbnode2.
The pacemaker of main LB node (lbnode1) creates three kinds of resources: (1) creates the virtual ip address resource of load balancing service cluster; (2) LBaas agent resource is created; (3) create a resource group, this resource group comprises virtual ip address resource and the LBaas agent resource of aforementioned establishment, and in this resource group, virtual ip address resource is front, and LBaas agent resource is rear.
After pacemaker on lbnode1 creates above-mentioned three kinds of resources, by three kinds of source synchronous of establishment in the pacemaker of lbnode2.
Pacemaker on lbnode1 starts the resource group created, and virtual ip address resource and LBaasagent resource are all enabled on main LB node (lbnode1).
In sum, load balancing service cluster is created by pacemaker and corosync, two LB node lbnode1 and lbnode2 are had in this cluster, LBaas agent is enabled on main LB node by pacemaker, standby LB node does not start LBaas agent, aggregated structure as shown in Figure 3, lbnode1 is main LB node, start LBaas agent, and create haproxy1 and haproxy2 two load equalizers, lbnode2 is standby LB node, does not start LBaas agent, does not create load equalizer.
Below in conjunction with specific embodiment, above-mentioned load balancing service high availability implementation method is described in detail.
The present embodiment is described in detail to technical solution of the present invention for the Neutron load balancing service of Openstack, Fig. 4 is the networking structure figure of the present embodiment, as shown in Figure 4, load balancing network is made up of Controlling vertex and load balancing service cluster, load balancing service cluster comprises LB1, LB2, LB3, wherein, LB1 is main LB node, and LB2, LB3 are respectively standby LB node.Fig. 5 is the flow chart of the present embodiment, as shown in Figure 5, comprises the following steps:
LBaas agent on step 501:LB1 lost efficacy, and LB2 switches to main LB node.
In this step, LBaas agent on LB1 lost efficacy, from standby LB node, select a standby LB node to switch to new main LB node, when there being at least one for LB node, new main LB node is switched to for selecting a standby LB node LB node from least one, method has multiple, be such as that each is for LB Node configuration priority etc., switching to new main LB node not to be the key of technical solution of the present invention from least one for selecting a standby LB node LB node about how, being not described in detail in this.Suppose that LB2 is switched to new main LB node by the present embodiment.
Step 502:LB2 starts self LBaas agent, and the virtual hostname of load balancing service cluster is configured to self virtual hostname, and the virtual ip address of load balancing service cluster is configured to self virtual ip address.
In this step, after LB2 switches to new main LB node, start self LBaas agent, and the virtual hostname of load balancing service cluster is configured to self virtual hostname, suppose that fictitious host computer is called lbnode, the virtual ip address of load balancing service cluster is configured to self virtual ip address, supposes that virtual ip address is IP-1.
Step 503:LB2 transmission carries the synchronization request message of virtual hostname lbnode to Controlling vertex.
Step 504: Controlling vertex receives the synchronization request message carrying virtual hostname lbnode that LB2 sends, determines the configuration information of each load equalizer mated and each load equalizer port numbers one to one of coupling according to the virtual hostname lbnode carried in this synchronization request message.
In this step, suppose that the corresponding relation of the virtual hostname that Controlling vertex this locality is preserved and each load equalizer is as shown in table 1, port numbers table is as shown in table 2 one to one for each load equalizer of Controlling vertex this locality preservation.In table 1, namely fictitious host computer be called lbnode LB node on scheduling have Haproxy A, Haproxy B two load equalizers, on the LB node that fictitious host computer is called xbnode, scheduling has Haproxy C, Haproxy D, Haproxy E tri-load equalizers.In table 2, load equalizer Haproxy A one to one port numbers is Port A, and other are similar, describe in detail no longer one by one.
Table 1
Table 2
| Load equalizer | Port numbers |
| Haproxy A | Port A |
| Haproxy B | Port B |
| Haproxy C | Port C |
| Haproxy D | Port D |
| Haproxy E | Port E |
The virtual hostname lbnode question blank 1 that Controlling vertex carries according to the synchronization request message received and table 2, determine that the load equalizer mated with lbnode is Haproxy A, Haproxy B, HaproxyA one to one port numbers be Port A, Haproxy B one to one port numbers be Port B.
Step 505: Controlling vertex send carry Haproxy A, the configuration information of Haproxy B two load equalizers and Haproxy A port numbers Port A, Haproxy B port numbers Port B one to one one to one syn ack message to LB2.
Step 506:LB2 receives the syn ack message that Controlling vertex is sent, according to configuration information and Haproxy A port numbers Port A, Haproxy B port numbers Port B generation one to one one to one Haproxy A, Haproxy B two load equalizers of the Haproxy A carried in this syn ack message, Haproxy B two load equalizers.
In this step, LB2 loads the configuration information of Haproxy A in the syn ack message received, Haproxy B two load equalizers, port numbers Port A and the corresponding relation of the true host name of the 2nd LB node (being assumed to be lbnode3) and the corresponding relation of port numbers Port B and the true host name lbnode3 of the 2nd LB node are carried on to upgrade in message and send to Controlling vertex, make Controlling vertex upgrade the local Port A the preserved main LB node true host name corresponding with Port A;
Create and Haproxy A port one to one, and Port A is configured on this port, as the mark of this port, afterwards, be responsible for realizing the service traffics of load balancing by Haproxy A by this port repeat; Create and Haproxy B port one to one, and Port B is configured on this port, as the mark of this port, afterwards, be responsible for realizing the service traffics of load balancing by Haproxy B by this port repeat.
Step 507:LB2 periodically sends heartbeat message to Controlling vertex, and this heartbeat message carries virtual hostname lbnode.
In this step, LB2 periodically transmission carries the heartbeat message of virtual hostname lbnode to Controlling vertex, whether the LBaas agent that Controlling vertex is determined on LB2 according to heartbeat message is effective, if receive the heartbeat message that LB2 sends before timer expiry, then illustrate that the LBaas agent on LB2 is effective, then Controlling vertex receives user's request when setting up the message of load equalizer, load equalizer newly-built for this request can be considered to be dispatched on LB2, such as, on LB2, to create load equalizer Haproxy C again; If Controlling vertex does not still receive the heartbeat message that LB2 sends after timer expiry, then illustrate that the LBaas agent on LB2 lost efficacy, then Controlling vertex receives user when asking the request of newly-built load equalizer, can not consider to be dispatched on LB2, but load equalizer newly-built for this request is dispatched in other load balancing service clusters on the effective main LB node of LBaas agent.
Fig. 6 be the present embodiment realize Organization Chart, as shown in Figure 6, Neutron-server operates in the Controlling vertex of Openstack, for user the access of API (Application Programming Interface, application programming interface) is provided, the additions and deletions of database change look into and user request scheduling, LBaas agent operates in the LB node (such as network network node or independent virtual machine VM) of load balancing service cluster, be used for configuring and disposing load equalizer, namely the haproxy M in Fig. 6 and haproxy N, Neutron-server receives after user creates the request of load equalizer, can this request scheduling on the LBaas agent of the main LB node of certain load balancing service cluster, the LBaas agent that the main LB node of each load balancing service cluster starts can register to Neutron-server, report the virtual hostname of the main LB node of the state of LBaas agent and this LBaasagent place, in the database of Neutron-server, preserve the corresponding relation of the virtual hostname of the main LB node of LBaas agent and its place of each startup, Neutron-server can use Neutron agent-list CLI (Command Line, order line) to order and check all LBaas agent information, and, Neutron-server preserves load equalizer and relevant information thereof that each LBaas agent started generates in a database, like this when restarting certain LBaasagent, the LBaas agent of restarting can obtain the load equalizer and relevant information that are produced by it from the database of Neutron-server, then on the main LB node of this LBaas agent operation, these load equalizers are regenerated, or, when the standby LB node of certain load balancing service cluster switches to new main LB node, new main LB node starts LBaas agent, the load equalizer that the LBaas agent obtaining former main LB node from the database of Neutron-server produces and relevant information, then on new main LB node, these load equalizers are regenerated.
In the present embodiment, at least two LB nodes form a load balancing service cluster, a LB node in this load balancing service cluster is main LB node, other LB nodes are standby LB node, wherein, only main LB node starts LBaas agent, after the LBaas agent on main LB node lost efficacy, one of them switches to new main LB node for LB node, and on this new main LB node, create the load-balanced server of scheduling on former main LB node, make new main LB node take over the load balancing service of former main LB node, achieve the High Availabitity of load balancing service.
For said method, the present invention also discloses a kind of load balancing node device, this equipment is applied to the load balancing service cluster of Openstack, Fig. 7 is the structure chart of this equipment, as shown in Figure 7, this equipment is the standby LB node of load balancing service cluster, and when being called the 2nd LB node, this equipment comprises:
Handover module 701, after LBaas agent inefficacy is acted on behalf of in load balancing service on a LB node of the main LB node as load balancing service cluster, described 2nd LB node is switched to main LB node, the virtual hostname of described load balancing service cluster is configured to self virtual hostname, and starts the LBaas agent of described Section Point;
Sending module 702, for send carry described virtual hostname synchronization request message to described Controlling vertex;
Receiver module 703, for receiving the syn ack message that described Controlling vertex is responded described synchronization request message, described syn ack message carries the configuration information of each load equalizer mated with described virtual hostname, and described each load equalizer port numbers one to one;
Load equalizer creation module 704, for according to the configuration information of described each load equalizer and described each load equalizer one to one port numbers create described each load equalizer.
Described load equalizer creation module 704 is when according to the configuration information of described each load equalizer and described each load equalizer, port numbers creates described each load equalizer one to one, specifically for:
Load the configuration information of described each load equalizer, by described each load equalizer one to one the corresponding relation of port numbers and the true host name of described 2nd LB node be carried on to upgrade in message and send to described Controlling vertex, make described Controlling vertex upgrade local described each load equalizer true host name of main LB node that port numbers is corresponding one to one of preserving;
Create with described each load equalizer port one to one, and by described each load equalizer one to one port numbers be configured at establishment with on described each load equalizer one to one port.
Handover module 701 also for:
After described 2nd LB node switches to main LB node, the virtual ip address of described load balancing service cluster is configured to self virtual ip address;
The described virtual ip address of described load balancing service cluster and described virtual hostname, be keeper be described load balancing service cluster configuration when creating described load balancing service cluster, and the corresponding relation of described virtual ip address and described virtual hostname is kept on described Controlling vertex, makes described Controlling vertex determine the main LB node of described load balancing service cluster according to described virtual ip address.
2nd LB node is switched to main LB node by handover module 701, is, after a described LB node restarts the LBaas agent failure of self, described 2nd LB node is switched to main LB node.
Load equalizer creation module 704 is according to after the configuration information of described each load equalizer and the described each load equalizer of described each load equalizer port numbers establishment one to one, and sending module 702 is further used for: periodically transmission carries the heartbeat message of described virtual hostname to described Controlling vertex.
The foregoing is only preferred embodiment of the present invention, not in order to limit the present invention, all any amendments done within the spirit and principles in the present invention, equivalent replacement, improvement etc., all should be included within the scope of protection of the invention.
Claims (10)
1. a load balancing service high availability implementation method, the method is applied to the load balancing node in Openstack load balancing service cluster, and it is characterized in that, the method comprises:
After acting on behalf of LBaas agent inefficacy as the load balancing service on a LB node of the main LB node of described load balancing service cluster, the 2nd LB node as the arbitrary standby LB node of described load balancing service cluster switches to main LB node, the virtual hostname of described load balancing service cluster is configured to self virtual hostname, and starts the LBaas agent of described 2nd LB node;
Transmission carries the synchronization request message of described virtual hostname to described Controlling vertex;
Receive the syn ack message that described Controlling vertex is responded described synchronization request message, described syn ack message carries the configuration information of each load equalizer mated with described virtual hostname, and described each load equalizer port numbers one to one;
According to configuration information and the described each load equalizer of described each load equalizer port numbers establishment one to one of described each load equalizer.
2. method according to claim 1, is characterized in that, the described configuration information according to described each load equalizer and described each load equalizer one to one port numbers create described each load equalizer, specifically comprise:
Described 2nd LB node loads the configuration information of described each load equalizer, by described each load equalizer one to one the corresponding relation of port numbers and the true host name of described 2nd LB node be carried on to upgrade in message and send to described Controlling vertex, make described Controlling vertex upgrade local described each load equalizer true host name of main LB node that port numbers is corresponding one to one of preserving;
Create with described each load equalizer port one to one, and by described each load equalizer one to one port numbers be configured at establishment with on described each load equalizer one to one port.
3. method according to claim 1, is characterized in that, the method comprises further:
After described 2nd LB node switches to main LB node, the virtual ip address of described load balancing service cluster is configured to self virtual ip address;
The described virtual ip address of described load balancing service cluster and described virtual hostname, be keeper be described load balancing service cluster configuration when creating described load balancing service cluster, and the corresponding relation of described virtual ip address and described virtual hostname is kept on described Controlling vertex, makes described Controlling vertex determine the position of the main LB node of described load balancing service cluster by the corresponding relation of described virtual ip address and described virtual hostname.
4. method according to claim 1, is characterized in that, described 2nd LB node switches to main LB node, is that described 2nd LB node switches to main LB node after a described LB node restarts the LBaas agent failure of self.
5. method according to claim 1, is characterized in that, the method comprises further:
Described 2nd LB node is according to after the configuration information of described each load equalizer and the described each load equalizer of described each load equalizer port numbers establishment one to one, and periodically transmission carries the heartbeat message of described virtual hostname to described Controlling vertex.
6. one kind realizes the load balancing node device of load balancing service High Availabitity, this equipment is applied to the load balancing service cluster of Openstack, it is characterized in that, this equipment is that when switching to the 2nd LB node of main LB node by standby LB node in load balancing service cluster, this equipment comprises:
Handover module, after LBaas agent inefficacy is acted on behalf of in load balancing service on a LB node of the main LB node as described load balancing service cluster, described 2nd LB node is switched to main LB node, the virtual hostname of described load balancing service cluster is configured to self virtual hostname, and starts LBaas agent;
Sending module, for send carry described virtual hostname synchronization request message to described Controlling vertex;
Receiver module, for receiving the syn ack message that described Controlling vertex is responded described synchronization request message, described syn ack message carries the configuration information of each load equalizer mated with described virtual hostname, and described each load equalizer port numbers one to one;
Load equalizer creation module, for according to the configuration information of described each load equalizer and described each load equalizer one to one port numbers create described each load equalizer.
7. method equipment according to claim 6, is characterized in that,
Described load equalizer creation module is when according to the configuration information of described each load equalizer and described each load equalizer, port numbers creates described each load equalizer one to one, specifically for:
Load the configuration information of described each load equalizer, by described each load equalizer one to one the corresponding relation of port numbers and the true host name of described 2nd LB node be carried on to upgrade in message and send to described Controlling vertex, make described Controlling vertex upgrade local described each load equalizer true host name of main LB node that port numbers is corresponding one to one of preserving;
Create with described each load equalizer port one to one, and by described each load equalizer one to one port numbers be configured at establishment with on described each load equalizer one to one port.
8. equipment according to claim 6, is characterized in that, described handover module also for:
After described 2nd LB node switches to main LB node, the virtual ip address of described load balancing service cluster is configured to self virtual ip address;
The described virtual ip address of described load balancing service cluster and described virtual hostname, be keeper be described load balancing service cluster configuration when creating described load balancing service cluster, and the corresponding relation of described virtual ip address and described virtual hostname is kept on described Controlling vertex, makes described Controlling vertex determine the main LB node of described load balancing service cluster according to described virtual ip address.
9. equipment according to claim 6, is characterized in that, the 2nd LB node is switched to main LB node by described handover module, is, after a described LB node restarts the LBaas agent failure of self, described 2nd LB node is switched to main LB node.
10. equipment according to claim 6, is characterized in that,
Described load equalizer creation module is according to after the configuration information of described each load equalizer and the described each load equalizer of described each load equalizer port numbers establishment one to one, and described sending module is further used for: periodically transmission carries the heartbeat message of described virtual hostname to described Controlling vertex.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510376962.1A CN104935672B (en) | 2015-06-29 | 2015-06-29 | Load balancing service high availability implementation method and equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510376962.1A CN104935672B (en) | 2015-06-29 | 2015-06-29 | Load balancing service high availability implementation method and equipment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN104935672A true CN104935672A (en) | 2015-09-23 |
| CN104935672B CN104935672B (en) | 2018-05-11 |
Family
ID=54122639
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201510376962.1A Active CN104935672B (en) | 2015-06-29 | 2015-06-29 | Load balancing service high availability implementation method and equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN104935672B (en) |
Cited By (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106506648A (en) * | 2016-11-10 | 2017-03-15 | 东软集团股份有限公司 | Load balancing service management method and system |
| CN106598700A (en) * | 2016-12-12 | 2017-04-26 | 武汉烽火信息集成技术有限公司 | Second-level high availability realization method of virtual machine based on pacemaker |
| WO2017114017A1 (en) * | 2015-12-30 | 2017-07-06 | 华为技术有限公司 | Computer device, system and method for implementing load balancing |
| CN107018041A (en) * | 2017-03-31 | 2017-08-04 | 杭州数梦工场科技有限公司 | Data migration method and device in cluster |
| CN107743152A (en) * | 2017-12-07 | 2018-02-27 | 南京易捷思达软件科技有限公司 | The implementation method of the High Availabitity of load equalizer in a kind of OpenStack cloud platforms |
| CN108063783A (en) * | 2016-11-08 | 2018-05-22 | 上海有云信息技术有限公司 | The dispositions method and device of a kind of load equalizer |
| CN108132829A (en) * | 2018-01-11 | 2018-06-08 | 郑州云海信息技术有限公司 | A kind of high available virtual machine realization method and system based on OpenStack |
| CN108234271A (en) * | 2017-10-25 | 2018-06-29 | 国云科技股份有限公司 | A kind of cloud platform service network IP management methods |
| CN109218160A (en) * | 2018-09-11 | 2019-01-15 | 武汉维力克科技有限公司 | A kind of communication device based on fictitious host computer |
| CN109684039A (en) * | 2018-12-25 | 2019-04-26 | 上海思询信息科技有限公司 | A method of it is extended based on OpenStack and realizes physical node management |
| CN109726013A (en) * | 2018-12-28 | 2019-05-07 | 杭州迪普科技股份有限公司 | A kind of LBaaS manages the method and device of more LB equipment |
| CN110177048A (en) * | 2019-05-28 | 2019-08-27 | 银联商务股份有限公司 | A kind of high availability implementation method and device of virtual private cloud system |
| CN111314114A (en) * | 2020-01-19 | 2020-06-19 | 苏州浪潮智能科技有限公司 | Deployment method and system for improving high availability of RabbitMQ |
| US10817506B2 (en) | 2018-05-07 | 2020-10-27 | Microsoft Technology Licensing, Llc | Data service provisioning, metering, and load-balancing via service units |
| CN111901409A (en) * | 2020-07-24 | 2020-11-06 | 山东海量信息技术研究院 | Load balancing implementation method and device of virtualized cloud platform and readable storage medium |
| CN112540827A (en) * | 2020-12-08 | 2021-03-23 | 北京航天云路有限公司 | Load balancing system based on k8s platform and implementation method |
| CN113098728A (en) * | 2019-12-23 | 2021-07-09 | 华为技术有限公司 | Health check method of load balancing system and related equipment |
| CN113709220A (en) * | 2021-08-16 | 2021-11-26 | 华云数据控股集团有限公司 | High-availability realization method and system of virtual load balancer and electronic equipment |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050021751A1 (en) * | 2003-07-24 | 2005-01-27 | International Business Machines Corporation | Cluster data port services for clustered computer system |
| CN101719841A (en) * | 2009-11-13 | 2010-06-02 | 曙光信息产业(北京)有限公司 | Monitoring system and method of distributed type assemblies |
| CN102447624A (en) * | 2011-11-23 | 2012-05-09 | 成都市华为赛门铁克科技有限公司 | Load balancing method in server cluster, as well as node server and cluster |
| CN104184819A (en) * | 2014-08-29 | 2014-12-03 | 城云科技（杭州）有限公司 | Multi-hierarchy load balancing cloud resource monitoring method |
| CN104394224A (en) * | 2014-11-28 | 2015-03-04 | 无锡华云数据技术服务有限公司 | Load balance system |
-
2015
- 2015-06-29 CN CN201510376962.1A patent/CN104935672B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050021751A1 (en) * | 2003-07-24 | 2005-01-27 | International Business Machines Corporation | Cluster data port services for clustered computer system |
| CN101719841A (en) * | 2009-11-13 | 2010-06-02 | 曙光信息产业(北京)有限公司 | Monitoring system and method of distributed type assemblies |
| CN102447624A (en) * | 2011-11-23 | 2012-05-09 | 成都市华为赛门铁克科技有限公司 | Load balancing method in server cluster, as well as node server and cluster |
| CN104184819A (en) * | 2014-08-29 | 2014-12-03 | 城云科技（杭州）有限公司 | Multi-hierarchy load balancing cloud resource monitoring method |
| CN104394224A (en) * | 2014-11-28 | 2015-03-04 | 无锡华云数据技术服务有限公司 | Load balance system |
Cited By (33)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107078969A (en) * | 2015-12-30 | 2017-08-18 | 华为技术有限公司 | Realize computer equipment, the system and method for load balancing |
| CN107078969B (en) * | 2015-12-30 | 2019-04-19 | 华为技术有限公司 | Realize computer equipment, the system and method for load balancing |
| WO2017114017A1 (en) * | 2015-12-30 | 2017-07-06 | 华为技术有限公司 | Computer device, system and method for implementing load balancing |
| US10171567B2 (en) | 2015-12-30 | 2019-01-01 | Huawei Technologies Co., Ltd. | Load balancing computer device, system, and method |
| CN108063783A (en) * | 2016-11-08 | 2018-05-22 | 上海有云信息技术有限公司 | The dispositions method and device of a kind of load equalizer |
| CN106506648B (en) * | 2016-11-10 | 2019-05-17 | 东软集团股份有限公司 | Load balancing service management method and system |
| CN106506648A (en) * | 2016-11-10 | 2017-03-15 | 东软集团股份有限公司 | Load balancing service management method and system |
| CN106598700A (en) * | 2016-12-12 | 2017-04-26 | 武汉烽火信息集成技术有限公司 | Second-level high availability realization method of virtual machine based on pacemaker |
| CN107018041A (en) * | 2017-03-31 | 2017-08-04 | 杭州数梦工场科技有限公司 | Data migration method and device in cluster |
| CN107018041B (en) * | 2017-03-31 | 2019-05-17 | 杭州数梦工场科技有限公司 | Data migration method and device in cluster |
| CN108234271A (en) * | 2017-10-25 | 2018-06-29 | 国云科技股份有限公司 | A kind of cloud platform service network IP management methods |
| CN107743152A (en) * | 2017-12-07 | 2018-02-27 | 南京易捷思达软件科技有限公司 | The implementation method of the High Availabitity of load equalizer in a kind of OpenStack cloud platforms |
| CN108132829A (en) * | 2018-01-11 | 2018-06-08 | 郑州云海信息技术有限公司 | A kind of high available virtual machine realization method and system based on OpenStack |
| US11030185B2 (en) | 2018-05-07 | 2021-06-08 | Microsoft Technology Licensing, Llc | Schema-agnostic indexing of distributed databases |
| US10970269B2 (en) | 2018-05-07 | 2021-04-06 | Microsoft Technology Licensing, Llc | Intermediate consistency levels for database configuration |
| US11397721B2 (en) | 2018-05-07 | 2022-07-26 | Microsoft Technology Licensing, Llc | Merging conflict resolution for multi-master distributed databases |
| US11379461B2 (en) | 2018-05-07 | 2022-07-05 | Microsoft Technology Licensing, Llc | Multi-master architectures for distributed databases |
| US11321303B2 (en) | 2018-05-07 | 2022-05-03 | Microsoft Technology Licensing, Llc | Conflict resolution for multi-master distributed databases |
| US10817506B2 (en) | 2018-05-07 | 2020-10-27 | Microsoft Technology Licensing, Llc | Data service provisioning, metering, and load-balancing via service units |
| US10970270B2 (en) | 2018-05-07 | 2021-04-06 | Microsoft Technology Licensing, Llc | Unified data organization for multi-model distributed databases |
| US10885018B2 (en) | 2018-05-07 | 2021-01-05 | Microsoft Technology Licensing, Llc | Containerization for elastic and scalable databases |
| CN109218160A (en) * | 2018-09-11 | 2019-01-15 | 武汉维力克科技有限公司 | A kind of communication device based on fictitious host computer |
| CN109684039A (en) * | 2018-12-25 | 2019-04-26 | 上海思询信息科技有限公司 | A method of it is extended based on OpenStack and realizes physical node management |
| CN109726013A (en) * | 2018-12-28 | 2019-05-07 | 杭州迪普科技股份有限公司 | A kind of LBaaS manages the method and device of more LB equipment |
| CN110177048B (en) * | 2019-05-28 | 2022-03-25 | 银联商务股份有限公司 | High-availability implementation method and device of virtual private cloud system |
| CN110177048A (en) * | 2019-05-28 | 2019-08-27 | 银联商务股份有限公司 | A kind of high availability implementation method and device of virtual private cloud system |
| CN113098728A (en) * | 2019-12-23 | 2021-07-09 | 华为技术有限公司 | Health check method of load balancing system and related equipment |
| CN113098728B (en) * | 2019-12-23 | 2023-12-19 | 华为云计算技术有限公司 | Health check method of load balancing system and related equipment |
| CN111314114A (en) * | 2020-01-19 | 2020-06-19 | 苏州浪潮智能科技有限公司 | Deployment method and system for improving high availability of RabbitMQ |
| CN111901409A (en) * | 2020-07-24 | 2020-11-06 | 山东海量信息技术研究院 | Load balancing implementation method and device of virtualized cloud platform and readable storage medium |
| CN112540827A (en) * | 2020-12-08 | 2021-03-23 | 北京航天云路有限公司 | Load balancing system based on k8s platform and implementation method |
| CN113709220A (en) * | 2021-08-16 | 2021-11-26 | 华云数据控股集团有限公司 | High-availability realization method and system of virtual load balancer and electronic equipment |
| CN113709220B (en) * | 2021-08-16 | 2024-03-22 | 华云数据控股集团有限公司 | High-availability implementation method and system of virtual load equalizer and electronic equipment |
Also Published As
| Publication number | Publication date |
|---|---|
| CN104935672B (en) | 2018-05-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN104935672A (en) | High available realizing method and equipment of load balancing service | |
| US10089123B2 (en) | Virtual cable modem termination system redundancy in a cable modem network environment | |
| US10140112B2 (en) | Update management system and update management method | |
| US11307943B2 (en) | Disaster recovery deployment method, apparatus, and system | |
| CN103703724B (en) | Resource payment method | |
| CN108011732B (en) | Method, controller and system for configuring service resources | |
| EP3210367B1 (en) | System and method for disaster recovery of cloud applications | |
| CN100426751C (en) | Method for ensuring accordant configuration information in cluster system | |
| CN102664747B (en) | Cloud calculating platform system | |
| CN108628716B (en) | Information receiving and managing system, method and device | |
| CN106060088A (en) | Service management method and device | |
| CN104869057A (en) | OpeFlow switch graceful restart processing method, device and OpeFlow controller | |
| US20230132861A1 (en) | Switching method and apparatus, device, and storage medium | |
| CN103631652A (en) | Method and system for achieving virtual machine migration | |
| WO2012155630A1 (en) | Method, device, and system for disaster recovery | |
| CN110391940A (en) | Response method, device, system, equipment and the storage medium of address of service | |
| CN111459639A (en) | Distributed task management platform and method supporting global multi-machine-room deployment | |
| CN106411574B (en) | Management control method and device | |
| US20150363278A1 (en) | Virtual resource-based backup | |
| CN113821334A (en) | Method, device and system for configuring edge side equipment | |
| CN114095342B (en) | Backup realization method and device | |
| CN100362811C (en) | Method for obtaining configuration information | |
| US10536875B2 (en) | System and method for seamless TCP connection handoff | |
| CN113452585A (en) | Communication method and device | |
| CN114930313A (en) | System and method for managing blockchain nodes |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| CB02 | Change of applicant information |
Address after: 310052 Binjiang District Changhe Road, Zhejiang, China, No. 466, No. Applicant after: Xinhua three Technology Co., Ltd. Address before: 310052 Binjiang District Changhe Road, Zhejiang, China, No. 466, No. Applicant before: Huasan Communication Technology Co., Ltd. |
|
| CB02 | Change of applicant information | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |