Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <20100828213456.GA23023@alumni.caltech.edu>
References: <4C794746.8040708@gmail.com>
 <AANLkTi=2PrnYA4VLX+qbdrBDQSRJAg2NFFMaBRCX7WPf@mail.gmail.com>
 <4C79550E.1080907@gmail.com> <20100828213456.GA23023@alumni.caltech.edu>
From: Benjamin Black <b@b3k.us>
Date: Sat, 28 Aug 2010 14:44:41 -0700
Message-ID: <AANLkTimWXUFhd3YxuBVQU-QspEpmmC665CaE=-c-su-_@mail.gmail.com>
Subject: Re: Cassandra & HAProxy
To: user@cassandra.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sat, Aug 28, 2010 at 2:34 PM, Anthony Molinaro
<anthonym@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
>
> =A0mode tcp
> =A0balance leastconn
> =A0server 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