On 8/28/10 2:44 PM, Benjamin Black wrote:
On Sat, Aug 28, 2010 at 2:34 PM, Anthony Molinaro
<antho...@alumni.caltech.edu> wrote:
I think maybe he thought you meant put a layer between cassandra internal
communication.
No, I took the question to be about client connections.
There's no problem balancing client connections with
haproxy, we've been pushing several billion requests per month through
haproxy to cassandra.
Can it be done: yes. Is it best practice: no. Even 10 billion
requests/month is an average of less than 4000 reqs/sec. Just not
that many for a distributed database like Cassandra.
we use
mode tcp
balance leastconn
server local 127.0.0.1:12350 check
so basically just a connect based check, and it works fine
Cassandra can, and does, fail in ways that do not stop it from
answering TCP connection requests. Are you saying it works fine
because you have seen numerous types of node failures and this was
sufficient? I would be quite surprised if that were so. Using an LB
for service discovery is a fine thing (connect to a VIP, call
describe_ring, open direct connections to cluster nodes). Relying on
an LB to do the right thing when it is totally ignorant of what is
going across those client connections (as is implied by simply
checking for connectivity) is asking for trouble. Doubly so when you
use a leastconn policy (a failing node can spit out an error and close
a connection with impressive speed, sucking all the traffic to itself;
common problem with HTTP servers giving back errors).
b
Yes it was in reference to client connections. Instead of clients
sending requests to individual nodes it would send it to haproxy. FYI we
are using ruby and our client is the Cassandra gem which I think you may
know about :)
