Hi, I had almost the same problem. For this situation I put a hw load-balancer in front of 2 qpid servers, using RoundRobin algorithm. So, the clients could connect to that VIP and the messages was distributed to 2 servers. About the consumers, I had only 1 consumer, so I put on 2 vm servers and each one was connected on one qpid server.
Att., Rodrigo Kellermann Ferreira On 9/28/11, Zhemzhitsky Sergey <[email protected]> wrote: > Hi Jakub, > > I understand that all the events are synchronized between all nodes of the > cluster. > What I'd like to understand is: > > 1. Whether it is possible to distribute the connections between the nodes of > the cluster transparently for the clients of the cluster? > 2. Does it make sense to distribute connections between the nodes if we have > about 100 connections to the first node and no connections to the second > one? > 3. Are there any benefits of using two-node cluster where the first node has > 50 connections and the second node has the same amount of connections > comparing to the two-node cluster where the first node has 100 connections > and the second node has no connections at all? > > Best Regards, > Sergey Zhemzhitsky > > > -----Original Message----- > From: Jakub Scholz [mailto:[email protected]] > Sent: Wednesday, September 28, 2011 12:43 PM > To: [email protected] > Subject: Re: QPID Cluster and load balancing > > Hi Sergey, > > From what I understood, the OpenAIS / Corosync layer used for clustering in > Qpid is anyway synchronizing the events between all nodes. So the load > should be almost the same, or? You may get some overhead on one node from > handling the connections, but is it so significant? > > Regards > Jakub > > On Wed, Sep 28, 2011 at 08:58, Zhemzhitsky Sergey > <[email protected]> wrote: >> Hi guys, >> >> I have the following issue: >> We have a two-node cluster that consists of node1 and node2. Message >> senders are written in c++ and consumers are java clients. >> The problem is that the first node (node1) is declared as the first >> node in java qpid connection factory like this >> >> amqp://guest:guest@/?failover='failover_exchange'&brokerlist='tcp://node1?connectdelay='5000'&retries='1000'&connecttimeout='5000'&heartbeat='1';tcp://node2?connectdelay='5000'&retries='1000'connecttimeout='5000'&heartbeat='1'' >> >> As the first node is listed first in the brokerlist parameter all java >> clients connect to the first node only. (They are able to reconnect to the >> second node, but only if the first node fails). >> >> The similar issue is actual for our c++ message senders too. They are all >> connect to the first node only. >> >> So the second node in our cluster acts as backup of the first node what we >> do not like. What we would like to achieve is to spread connections >> between all nodes of the cluster somehow. >> >> Is it possible? Are c++ and java qpid clients able to load-balance between >> nodes of the qpid cluster? What is the general solution for the described >> issue for the N-node cluster? >> >> >> Best Regards, >> Sergey Zhemzhitsky >> >> >> _______________________________________________________ >> >> The information contained in this message may be privileged and conf >> idential and protected from disclosure. If you are not the original >> intended recipient, you are hereby notified that any review, >> retransmission, dissemination, or other use of, or taking of any action in >> reliance upon, this information is prohibited. If you have received this >> communication in error, please notify the sender immediately by replying >> to this message and delete it from your computer. Thank you for your >> cooperation. Troika Dialog, Russia. >> If you need assistance please contact our Contact Center (+7495) 258 >> 0500 or go to www.troika.ru/eng/Contacts/system.wbp >> >> > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > > _______________________________________________________ > > The information contained in this message may be privileged and conf > idential and protected from disclosure. If you are not the original intended > recipient, you are hereby notified that any review, retransmission, > dissemination, or other use of, or taking of any action in reliance upon, > this information is prohibited. If you have received this communication in > error, please notify the sender immediately by replying to this message and > delete it from your computer. Thank you for your cooperation. Troika Dialog, > Russia. > If you need assistance please contact our Contact Center (+7495) 258 0500 > or go to www.troika.ru/eng/Contacts/system.wbp > > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
