cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Evans (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-4119) Support multiple non-consecutive tokens per host (virtual nodes)
Date Tue, 10 Apr 2012 16:11:19 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-4119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Eric Evans updated CASSANDRA-4119:
----------------------------------

    Description: 
This is the parent ticket for the virtual nodes implementation which was proposed here: http://www.mail-archive.com/dev@cassandra.apache.org/msg03837.html
and discussed in the subsequent thread.

The goals of this ticket are:
* reduced operations complexity for scaling up/down
* reduced rebuild time in event of failure
* evenly distributed load impact in the event of failure
* evenly distributed impact of streaming operations
* more viable support for heterogeneity of hardware

The intention is that this can be done in a way which is
* fully backwards-compatible
* optionally enabled

The latter of these can be trivially achieved by setting the number of tokens per host to
1, to reproduce the existing behaviour.

Implementation detail can be added and discussed in the sub-tickets, but here is an overview
of the proposed changes:
* TokenMetadata will allow multiple tokens per host
* Hosts will be referred to by a UUID instead of token (e.g. in Gossip, when storing hints,
etc.)
* A bootstrapping node can get multiple tokens from initial_token (comma separated) or by
random allocation
* NetworkTopologyStrategy will be extended to be aware of virtual nodes so that replicas are
not placed on the same host (similar to racks now)
* Repairs will be staggered similar to CASSANDRA-3721
* Nodetool operations will be virtual-node aware, while maintaining backwards compatibility
(ie. existing scripts won't have to change)
* Upgrade will be a standard rolling upgrade, with optional rolling migration to full vnode
support

  was:
This is the parent ticket for the virtual nodes implementation which was proposed here: http://www.mail-archive.com/dev@cassandra.apache.org/msg03837.html
and discussed in the subsequent thread.

The goals of this ticket are:
* reduced operations complexity for scaling up/down
* reduced rebuild time in event of failure
* evenly distributed load impact in the event of failure
* evenly distributed impact of streaming operations
* more viable support for heterogeneity of hardware

The intention is that this can be done in a way which is
* fully backwards-compatible
* optionally enabled

The latter of these can be trivially achieved by setting the number of tokens per host to
1, to reproduce the existing behaviour.

Implementation detail can be added and discussed in the sub-tickets, but here is an overview
of the proposed changes:
* TokenMetadata will allow multiple tokens per host
* Hosts will be referred to by IP instead of token (e.g. in Gossip, when storing hints, etc.)
* A bootstrapping node can get multiple tokens from initial_token (comma separated) or by
random allocation
* NetworkTopologyStrategy will be extended to be aware of virtual nodes so that replicas are
not placed on the same host (similar to racks now)
* Repairs will be staggered similar to CASSANDRA-3721
* Nodetool operations will be virtual-node aware, while maintaining backwards compatibility
(ie. existing scripts won't have to change)
* Upgrade will be a standard rolling upgrade, with optional rolling migration to full vnode
support

    
> Support multiple non-consecutive tokens per host (virtual nodes)
> ----------------------------------------------------------------
>
>                 Key: CASSANDRA-4119
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4119
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Sam Overton
>            Assignee: Sam Overton
>              Labels: virtualnodes, vnodes
>
> This is the parent ticket for the virtual nodes implementation which was proposed here:
http://www.mail-archive.com/dev@cassandra.apache.org/msg03837.html and discussed in the subsequent
thread.
> The goals of this ticket are:
> * reduced operations complexity for scaling up/down
> * reduced rebuild time in event of failure
> * evenly distributed load impact in the event of failure
> * evenly distributed impact of streaming operations
> * more viable support for heterogeneity of hardware
> The intention is that this can be done in a way which is
> * fully backwards-compatible
> * optionally enabled
> The latter of these can be trivially achieved by setting the number of tokens per host
to 1, to reproduce the existing behaviour.
> Implementation detail can be added and discussed in the sub-tickets, but here is an overview
of the proposed changes:
> * TokenMetadata will allow multiple tokens per host
> * Hosts will be referred to by a UUID instead of token (e.g. in Gossip, when storing
hints, etc.)
> * A bootstrapping node can get multiple tokens from initial_token (comma separated) or
by random allocation
> * NetworkTopologyStrategy will be extended to be aware of virtual nodes so that replicas
are not placed on the same host (similar to racks now)
> * Repairs will be staggered similar to CASSANDRA-3721
> * Nodetool operations will be virtual-node aware, while maintaining backwards compatibility
(ie. existing scripts won't have to change)
> * Upgrade will be a standard rolling upgrade, with optional rolling migration to full
vnode support

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message