Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0499519329 for ; Tue, 5 Apr 2016 21:44:58 +0000 (UTC) Received: (qmail 13445 invoked by uid 500); 5 Apr 2016 21:44:55 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 13403 invoked by uid 500); 5 Apr 2016 21:44:55 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 13393 invoked by uid 99); 5 Apr 2016 21:44:55 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Apr 2016 21:44:55 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 08B9CC0227 for ; Tue, 5 Apr 2016 21:44:55 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.28 X-Spam-Level: * X-Spam-Status: No, score=1.28 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=2, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=jonhaddad-com.20150623.gappssmtp.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id sCKxxMU20ts5 for ; Tue, 5 Apr 2016 21:44:52 +0000 (UTC) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id E18235F252 for ; Tue, 5 Apr 2016 21:44:51 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id fp4so18612185obb.2 for ; Tue, 05 Apr 2016 14:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jonhaddad-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=hV75y6Vdy+hb+LhYPbUHtZubri+VWJx7LxdaJfjhJac=; b=sHoxrOY6Od2aMi3/upDv2O9c9gokH9HAf9ocH1dDziWW0NqOh6S2p32m/1Dmhsyz4J nSIXPL4qJEQxvFZ8h8IjJCwnkWcYRQHb6jtqSrTWDvHUtY+5AryOOFn/hzLSILay7bXm qZU2gDtiUNEpdhs0tiwLwZ5ZhefmlEm1v0BwcbCSdOsKNJ7EzR6rThhXYSHqi5aoLpRf cZ1UtGE9e+Hj2mh5yDWNpfL28esziBt2b2wESxjoGf5gnyP16sHKSgf0MSgt0SPDR5sr C0RygYxb9ng5VeELPZghFY3Rr/JKJ39IaV6mPYEUy4JKIJ8Qc+ihALsdGo1f5P2mkw38 K6Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=hV75y6Vdy+hb+LhYPbUHtZubri+VWJx7LxdaJfjhJac=; b=Z1F3mnyZdF0CTHzDsHMTRxMt8ntIpudGnT3PSsYYc3/az23e2Euk+A/+UtREld3ff2 O9rIdsJonWS3ntdXYrZcumP9nLF5pq8imtzqS/ZEJECYxoBLLKRV7CaCJoVqauWo9wyU xH9ogtyDqOGFtO0sKQWraeY04laLFl9i3QV/kUtN1bhlkm2xjYCqU/ya5semsaasxBIL CB58JpTqm8mWClrZDflkqGCO7bT1H+5T0lwlEpNx0jnhJVJ0UZUE5y68BMAbrtjdQyg8 AQwC6kEVQCH4niFTbXhNhbOGCtyYsNGH3cTxCT0wuVtZVAXSBLou4uJLBQNZU4r+DVHN JIFQ== X-Gm-Message-State: AD7BkJI/K3g+hS2imiGZs/oAQXYOfi4hKNrgYZ3RhEOrMK0R4+tWym1GWKThQ/aeXWlif+RBlulPnHdnFA525g== X-Received: by 10.60.51.135 with SMTP id k7mr6979520oeo.42.1459892690718; Tue, 05 Apr 2016 14:44:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Haddad Date: Tue, 05 Apr 2016 21:44:41 +0000 Message-ID: Subject: Re: Is it possible to achieve "sticky" request routing? To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=001a11c301a63d9690052fc3c192 --001a11c301a63d9690052fc3c192 Content-Type: text/plain; charset=UTF-8 Jim, that's not what he asked. He asked for the equivalent of a load balancer with sticky sessions. On Tue, Apr 5, 2016 at 2:24 PM Jim Ancona wrote: > Jon and Steve: > > I don't understand your point. The TokenAwareLoadBalancer identifies the > nodes in the cluster that own the data for a particular token and route > requests to one of them. As I understand it, the OP wants to send requests > for a particular token to the same node every time (assuming it's > available). How does that fail in a large cluster? > > Jim > > On Tue, Apr 5, 2016 at 4:31 PM, Jonathan Haddad wrote: > >> Yep - Steve hit the nail on the head. The odds of hitting the right >> server with "sticky routing" goes down as your cluster size increases. You >> end up adding extra network hops instead of using token aware routing. >> >> Unless you're trying to do a coordinator tier (and you're not, according >> to your original post), this is a pretty bad idea and I'd advise you to >> push back on that requirement. >> >> On Tue, Apr 5, 2016 at 12:47 PM Steve Robenalt >> wrote: >> >>> Aside from Jon's "why" question, I would point out that this only really >>> works because you are running a 3 node cluster with RF=3. If your cluster >>> is going to grow, you can't guarantee that any one server would have all >>> records. I'd be pretty hesitant to put an invisible constraint like that on >>> a cluster unless you're pretty sure it'll only ever be 3 nodes. >>> >>> On Tue, Apr 5, 2016 at 9:34 AM, Jonathan Haddad >>> wrote: >>> >>>> Why is this a requirement? Honestly I don't know why you would do this. >>>> >>>> >>>> On Sat, Apr 2, 2016 at 8:06 PM Mukil Kesavan >>>> wrote: >>>> >>>>> Hello, >>>>> >>>>> We currently have 3 Cassandra servers running in a single datacenter >>>>> with a replication factor of 3 for our keyspace. We also use the >>>>> SimpleSnitch wiith DynamicSnitching enabled by default. Our load balancing >>>>> policy is TokenAwareLoadBalancingPolicy with RoundRobinPolicy as the child. >>>>> This overall configuration results in our client requests spreading equally >>>>> across our 3 servers. >>>>> >>>>> However, we have a new requirement where we need to restrict a >>>>> client's requests to a single server and only go to the other servers on >>>>> failure of the previous server. This particular use case does not have high >>>>> request traffic. >>>>> >>>>> Looking at the documentation the options we have seem to be: >>>>> >>>>> 1. Play with the snitching (e.g. place each server into its own DC or >>>>> Rack) to ensure that requests always go to one server and failover to the >>>>> others if required. I understand that this may also affect replica >>>>> placement and we may need to run nodetool repair. So this is not our most >>>>> preferred option. >>>>> >>>>> 2. Write a new load balancing policy that also uses the >>>>> HostStateListener for tracking host up and down messages, that essentially >>>>> accomplishes "sticky" request routing with failover to other nodes. >>>>> >>>>> Is option 2 the only clean way of accomplishing our requirement? >>>>> >>>>> Thanks, >>>>> Micky >>>>> >>>> >>> >>> >>> -- >>> Steve Robenalt >>> Software Architect >>> srobenalt@highwire.org >>> (office/cell): 916-505-1785 >>> >>> HighWire Press, Inc. >>> 425 Broadway St, Redwood City, CA 94063 >>> www.highwire.org >>> >>> Technology for Scholarly Communication >>> >> > --001a11c301a63d9690052fc3c192 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jim, that's not what he asked. He asked for the equivalent of a load ba= lancer with sticky sessions.


On Tue, Apr 5, 2016 at 2:24 PM Jim Ancona <jim@anconafamily.com> wrote:
Jon and Steve:

I= don't understand your point. The TokenAwareLoadBalancer identifies the= nodes in the cluster that own the data for a particular token and route re= quests to one of them. As I understand it, the OP wants to send requests fo= r a particular token to the same node every time (assuming it's availab= le). How does that fail in a large cluster?=C2=A0

Jim

On Tue, Apr 5, 2016 at 4:31 PM, Jonathan Ha= ddad <jon@jonhaddad.com> wrote:
Yep - Steve hit the nail on the head.=C2=A0 The odds= of hitting the right server with "sticky routing" goes down as y= our cluster size increases.=C2=A0 You end up adding extra network hops inst= ead of using token aware routing.

Unless you're tryi= ng to do a coordinator tier (and you're not, according to your original= post), this is a pretty bad idea and I'd advise you to push back on th= at requirement.

On Tue, Apr 5, 2016 at 12:47 PM Steve Robenalt <srobenalt@highwire.org>= ; wrote:
Aside fro= m Jon's "why" question, I would point out that this only real= ly works because you are running a 3 node cluster with RF=3D3. If your clus= ter is going to grow, you can't guarantee that any one server would hav= e all records. I'd be pretty hesitant to put an invisible constraint li= ke that on a cluster unless you're pretty sure it'll only ever be 3= nodes.=C2=A0

On Tue, Apr 5, 2016 at 9:34 AM, Jonathan= Haddad <jon@jonhaddad.com> wrote:
Why is this a requirement?=C2=A0 Honestly I don= 't know why you would do this.


On Sat, Apr 2, 2016 at 8:06 PM Mukil Kesavan <weirdbluelights@g= mail.com> wrote:
Hello,

We currently have 3 Cassandra servers runni= ng in a single datacenter with a replication factor of 3 for our keyspace. = We also use the SimpleSnitch wiith DynamicSnitching enabled by default. Our= load balancing policy is TokenAwareLoadBalancingPolicy with RoundRobinPoli= cy as the child. This overall configuration results in our client requests = spreading equally across our 3 servers.

However, w= e have a new requirement where we need to restrict a client's requests = to a single server and only go to the other servers on failure of the previ= ous server. This particular use case does not have high request traffic.

Looking at the documentation the options we have see= m to be:

1. Play with the snitching (e.g. place ea= ch server into its own DC or Rack) to ensure that requests always go to one= server and failover to the others if required. I understand that this may = also affect replica placement and we may need to run nodetool repair. So th= is is not our most preferred option.

2. Write a ne= w load balancing policy that also uses the HostStateListener for tracking h= ost up and down messages, that essentially accomplishes "sticky" = request routing with failover to other nodes.

Is o= ption 2 the only clean way of accomplishing our requirement?

=
Thanks,
Micky



--
Steve R= obenalt=C2=A0
Software Architect
(office/cell): 916-505-1785

=
HighWire Press, Inc.
425 Broadway St= , Redwood City, CA 94063

Technology for Scholarly Communication

--001a11c301a63d9690052fc3c192--