[jira] [Commented] (TS-3418) Second hash ring for consistently hashed parent selection

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TS-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989923#comment-14989923 ] 

ASF GitHub Bot commented on TS-3418:
------------------------------------

GitHub user jrushf1239k opened a pull request:

    https://github.com/apache/trafficserver/pull/321

    Parent selection 2.0

    This is a refactor of Parent Selection to add the following features:
    
    1) multi-site origin - using parent selection, origin servers may be selected using round robin or consistent hash algorithms.
    
    2) simple retry - if the parent is an origin server and a 404 response is received when this feature is enabled, the transaction will be retried using another parent.  The user may define a list of response codes for simple retry.  Both enabling and defining response codes may be done using header_rewrite on a delivery service basis.
    
    3) dead server retry - if the parent is an origin server and a 503 response is received when this feature is enabled, the current parent is marked down for 5 minutes and the transaction will be retried using another parent.  The user may define a list of response codes for dead server retry.  Both enabling and defining response codes may be done using header_rewrite on a delivery service basis.
    
    4) Added a secondary_parent list to parent.config when round_robin=consistent_hash.  The secondary parents are added to a secondary hash ring for parent selection when a primary parent is down.  In a cache hierarchy this would allow you to take advantage of another set of mid tier caches content affinity when a primary parent is down, see TS-3418.
    
    I refactored Parent Selection using a Strategy design pattern where the Round robin and consistent hash implementations are in there own class.  These strategy implementations are created per row in parent.config when the traffic server starts and reads the parent.config file.  This refactor made it easier to add the secondary hash feature.
    
    I plan on doing a presentation of all this at the ATS summit this month.
    
    thanks

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/jrushf1239k/trafficserver parent-selection-2.0

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/trafficserver/pull/321.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #321
    
----
commit 451f9176bd83291c37d65a2cef4bf510b1775d9a
Author: John J. Rushford <jo...@cable.comcast.com>
Date:   2015-11-03T17:03:54Z

    parent selection refactor, multi-site-origin, simple retry and dead server retry pull request.

commit 02b6b6b283fabdaf6174d934dc0c3cb2939a19f1
Author: John J. Rushford <jo...@cable.comcast.com>
Date:   2015-11-03T17:04:42Z

    parent selection refactor, multi-site-origin, simple retry and dead server retry pull request.

commit 740184053671bb88b7f15708cab18d34384a1e7d
Author: John J. Rushford <jo...@cable.comcast.com>
Date:   2015-11-03T17:41:51Z

    clang format.

commit 0bd0d3dba938088ba8b5ecca94880814304fc7b2
Author: John J. Rushford <jo...@cable.comcast.com>
Date:   2015-11-03T18:51:11Z

    update documentation with multi-site-origin, simple and dead server retry configuration information.

commit 1d9967fe12d56e15d2d6040d59c2b827b38199d2
Author: John J. Rushford <jo...@cable.comcast.com>
Date:   2015-11-04T15:16:26Z

    Fix go_direct behaviour in ParentConsistentHash.

commit e8ce2438c92650b50e39ec1dab44e6c158ec6568
Author: John J. Rushford <jo...@cable.comcast.com>
Date:   2015-11-04T15:18:27Z

    Merge branch 'master' into parent-selection-2.0

----


> Second hash ring for consistently hashed parent selection 
> ----------------------------------------------------------
>
>                 Key: TS-3418
>                 URL: https://issues.apache.org/jira/browse/TS-3418
>             Project: Traffic Server
>          Issue Type: New Feature
>          Components: Parent Proxy
>            Reporter: Leif Hedstrom
>            Assignee: John Rushford
>             Fix For: 6.1.0
>
>
> It would be incredibly useful if we allowed for an (optional) second hash ring in the consistent hashing in parent selection. Imagine a setup where you have two set of parent proxies. A child would prefer to always use a parent <n> in ring <A> for a set of URLs, <X>. In the case of parent <n> not being available, instead of rehashing <X> to the surviving members of ring <A>, we could now hash the URLs to parent <m> in ring <B>. Upon failure there, we'd then go back and rehash on the primary ring again (<A>).
> This sounds complicated, but is simple in principle. Instead of immediately rehashing content upon a parent failure, we have a backup pool (potentially remote) of parents, that are likely to have the content. The idea is to minimize origin server traffic at all cost.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)