Virtual Nodes: Rethinking Topology in Cassandra

Eric [email protected]

@jericevans

ApacheCon EuropeNovember 7, 2012

Rethinking Topology in Cassandra

1Wednesday, November 7, 12

mailto:[email protected]

mailto:[email protected]

DHT 101


DHT 101partitioning

AZ


The keyspace, a namespace encompassing all possible keys

DHT 101partitioning

A

B

C

Y

Z


The namespace is divided into N partitions (where N is the number of nodes). Partitions are mapped to nodes and placed evenly throughout the namespace.

DHT 101partitioning

A

B

C

Y Key = Aaa

Z


A record, stored by key, is positioned on the next node (working clockwise) from where it sorts in the namespace

DHT 101replica placement

A

B

C

Y Key = Aaa

Z


Additional copies (replicas) are stored on other nodes. Commonly the next N-1 nodes, but anything deterministic will work.

DHT 101consistency

Consistency

Availability

Partition tolerance


With multiple copies comes a set of trade-offs commonly articulated using the CAP theorem; At any given point, we can only guarantee 2 of Consistency, Availability, and Partition tolerance.

A

?

?

W

DHT 101scenario: consistency level = one


Writing at consistency level ONE provides very high availability, only one in 3 member nodes need be up for write to succeed

A

?

?

R

DHT 101scenario: consistency level = all


If strong consistency is required, reads with consistency ALL can be used of writes performed at ONE. The trade-off is in availability, all 3 member nodes must be up, else the read fails.

DHT 101scenario: quorum write

A

B

?

R+W > N

W


Using QUORUM consistency, we only require floor((N/2)+1) nodes.

DHT 101scenario: quorum read

?

B

C

R+W > N

R


Using QUORUM consistency, we only require floor((N/2)+1) nodes.

Awesome, yes?


Well...


Problem:Poor load distribution


Distributing Load

A

B

C

Y

Z

M


B and C hold replicas of A

Distributing Load

A

B

C

Y

Z

M


A and B hold replicas of Z

Distributing Load

A

B

C

Y

Z

M


Z and A hold replicas of Y

Distributing Load

A

B

C

Y

Z

M


Disaster strikes!

Distributing Load

AZ

Y B

CM


Sets [Y,Z,A], [Z,A,B], [A,B,C] all suffer the loss of A; Results in extra load on neighboring nodes

Distributing Load

A

B

C

Y

Z A1

M


Solution: Replace/repair down node

Distributing Load

AZ

Y B

C

A1

M


Neighboring nodes are needed to stream missing data to A; Results in even more load on neighboring nodes

Problem:Poor data distribution


Distributing DataA

B

CD


Ideal distribution of keyspace

Distributing DataA

B

CD

E


Bootstrapping a node, bisecting one partition; Distribution is no longer ideal

Distributing Data

A

B

CD

EA

C

B

D


Moving existing nodes means moving corresponding data; Not ideal

Distributing DataA

B

CD

H E

FG


Frequently cited alternative: Double the size of your cluster, bisecting all ranges

Virtual Nodes


In a nutshell...

host

host

host


Basically: “nodes” on the ring are virtual, and many of them are mapped to each “real” node (host)

Benefits

• Operationally simpler (no token management)

• Better distribution of load

• Concurrent streaming involving all hosts

• Smaller partitions mean greater reliability

• Supports heterogenous hardware


Strategies

• Automatic sharding

• Fixed partition assignment

• Random token assignment


StrategyAutomatic Sharding

• Partitions are split when data exceeds a threshold

• Newly created partitions are relocated to a host with lower data load

• Similar to sharding performed by Bigtable, or Mongo auto-sharding


StrategyFixed Partition Assignment

• Namespace divided into Q evenly-sized partitions

• Q/N partitions assigned per host (where N is the number of hosts)

• Joining hosts “steal” partitions evenly from existing hosts.

• Used by Dynamo and Voldemort (described in Dynamo paper as “strategy 3”)


StrategyRandom Token Assignment

• Each host assigned T random tokens

• T random tokens generated for joining hosts; New tokens divide existing ranges

• Similar to libketama; Identical to Classic Cassandra when T=1


Considerations

1. Number of partitions

2. Partition size

3. How 1 changes with more nodes and data

4. How 2 changes with more nodes and data


Evaluating

Strategy No. Partitions Partition size

Random O(N) O(B/N)

Fixed O(1) O(B)

Auto-sharding O(B) O(1)

B ~ total data size, N ~ number of hosts


Evaluating


• partition size constant (great)

• number of partitions scales linearly with data size (bad)




Evaluating



• Number of partitions is constant (good)

• Partition size scales linearly with data size (bad)

• Higher operational complexity (bad)



Evaluating




• Number of partitions scales linearly with number of hosts (good ok)

• Partition size increases with more data; decreases with more hosts (good)


Evaluating





Cassandra


Configurationconf/cassandra.yaml

# Comma separated list of tokens,# (new installs only).initial_token:<token>,<token>,<token>

or

# Number of tokens to generate.num_tokens: 256


Two params control how tokens are assigned. The initial_token param now optionally accepts a csv list, or (preferably) you can assign a numeric value to num_tokens

Configurationnodetool info

Token : (invoke with -T/--tokens to see all 256 tokens)ID : 64090651-6034-41d5-bfc6-ddd24957f164Gossip active : trueThrift active : trueLoad : 92.69 KBGeneration No : 1351030018Uptime (seconds): 45Heap Memory (MB): 95.16 / 1956.00Data Center : datacenter1Rack : rack1Exceptions : 0Key Cache : size 240 (bytes), capacity 101711872 (bytes ...Row Cache : size 0 (bytes), capacity 0 (bytes), 0 hits, ...


To keep the output readable, nodetool info no longer displays tokens (if there are more than one), unless the -T/--tokens argument is passed

Configurationnodetool ring

Datacenter: datacenter1==========Replicas: 2

Address Rack Status State Load Owns Token 9022770486425350384127.0.0.1 rack1 Up Normal 97.24 KB 66.03% -9182469192098976078127.0.0.1 rack1 Up Normal 97.24 KB 66.03% -9054823614314102214127.0.0.1 rack1 Up Normal 97.24 KB 66.03% -8970752544645156769127.0.0.1 rack1 Up Normal 97.24 KB 66.03% -8927190060345427739127.0.0.1 rack1 Up Normal 97.24 KB 66.03% -8880475677109843259127.0.0.1 rack1 Up Normal 97.24 KB 66.03% -8817876497520861779127.0.0.1 rack1 Up Normal 97.24 KB 66.03% -8810512134942064901127.0.0.1 rack1 Up Normal 97.24 KB 66.03% -8661764562509480261127.0.0.1 rack1 Up Normal 97.24 KB 66.03% -8641550925069186492127.0.0.1 rack1 Up Normal 97.24 KB 66.03% -8636224350654790732......


nodetool ring is still there, but the output is significantly more verbose, and it is less useful as the go-to

Configurationnodetool status

Datacenter: datacenter1=======================Status=Up/Down|/ State=Normal/Leaving/Joining/Moving-- Address Load Tokens Owns Host ID RackUN 10.0.0.1 97.2 KB 256 66.0% 64090651-6034-41d5-bfc6-ddd24957f164 rack1UN 10.0.0.2 92.7 KB 256 66.2% b3c3b03c-9202-4e7b-811a-9de89656ec4c rack1UN 10.0.0.3 92.6 KB 256 67.7% e4eef159-cb77-4627-84c4-14efbc868082 rack1


New go-to command is nodetool status




Of note, since it is no longer practical to name a host by it’s token (because it can have many), each host has a unique ID




Note the token per-node count

MigrationA

C B


Migrationedit conf/cassandra.yaml and restart

# Number of tokens to generate.num_tokens: 256


Step 1: Set num_tokens in cassandra.yaml, and restart node

Migrationconvert to T contiguous tokens in existing ranges

AAAAAAAAAAAA

AA A A A A A A A A AC

AA

AA

AA

AAAA

AB


This will cause the existing range to be split into T contiguous tokens. This results in no change to placement

Migrationshuffle

AAAAAAAAAAAA

AA A A A A A A A A AC

AA

AA

AA

AAAA

AB


Step 2: Initialize a shuffle operation. Nodes randomly exchange ranges.

Shuffle

• Range transfers are queued on each host

• Hosts initiate transfer of ranges to self

• Pay attention to the logs!


Shufflebin/shuffle

Usage: shuffle [options] <sub-command>

Sub-commands: create Initialize a new shuffle operation ls List pending relocations clear Clear pending relocations en[able] Enable shuffling dis[able] Disable shuffling

Options: -dc, --only-dc Apply only to named DC (create only) -tp, --thrift-port Thrift port number (Default: 9160) -p, --port JMX port number (Default: 7199) -tf, --thrift-framed Enable framed transport for Thrift (Default: false) -en, --and-enable Immediately enable shuffling (create only) -H, --help Print help information -h, --host JMX hostname or IP address (Default: localhost) -th, --thrift-host Thrift hostname or IP address (Default: JMX host)


Performance


removenode

0

100

200

300

400

Acunu Reflex / Cassandra 1.2 Cassandra 1.1


17 node cluster of EC2 m1.large instances, 460M rows

bootstrap

0

125

250

375

500

Acunu Reflex / Cassandra 1.2 Cassandra 1.1


17 node cluster of EC2 m1.large instances, 460M rows

The End

• Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, Gunavardhan Kakulapati, Avinash Lakshman, Alex Pilchin, Swaminathan Sivasubramanian, Peter Vosshall and Werner Vogels “Dynamo: Amazon’s Highly Available Key-value Store” Web.

• Low, Richard. “Improving Cassandra's uptime with virtual nodes” Web.

• Overton, Sam. “Virtual Nodes Strategies.” Web.

• Overton, Sam. “Virtual Nodes: Performance Results.” Web.

• Jones, Richard. "libketama - a consistent hashing algo for memcache clients” Web.


http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html




http://tinyurl.com/vnodesuptime

http://tinyurl.com/vnodesuptime

http://tinyurl.com/vnodestrategies

http://tinyurl.com/vnodestrategies

http://tinyurl.com/vnodesperf

http://tinyurl.com/vnodesperf

http://tinyurl.com/libketama




Virtual Nodes: Rethinking Topology in Cassandra

Technology

Transcript of Virtual Nodes: Rethinking Topology in Cassandra