Virtual Nodes: Rethinking Topology in Cassandra
-
Upload
eric-evans -
Category
Technology
-
view
4.170 -
download
2
description
Transcript of Virtual Nodes: Rethinking Topology in Cassandra
Eric [email protected]
@jericevans
ApacheCon EuropeNovember 7, 2012
Rethinking Topology in Cassandra
1Wednesday, November 7, 12
DHT 101
2Wednesday, November 7, 12
DHT 101partitioning
AZ
3Wednesday, November 7, 12
The keyspace, a namespace encompassing all possible keys
DHT 101partitioning
A
B
C
Y
Z
4Wednesday, November 7, 12
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
5Wednesday, November 7, 12
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
6Wednesday, November 7, 12
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
7Wednesday, November 7, 12
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
8Wednesday, November 7, 12
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
9Wednesday, November 7, 12
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
10Wednesday, November 7, 12
Using QUORUM consistency, we only require floor((N/2)+1) nodes.
DHT 101scenario: quorum read
?
B
C
R+W > N
R
11Wednesday, November 7, 12
Using QUORUM consistency, we only require floor((N/2)+1) nodes.
Awesome, yes?
12Wednesday, November 7, 12
Well...
13Wednesday, November 7, 12
Problem:Poor load distribution
14Wednesday, November 7, 12
Distributing Load
A
B
C
Y
Z
M
15Wednesday, November 7, 12
B and C hold replicas of A
Distributing Load
A
B
C
Y
Z
M
16Wednesday, November 7, 12
A and B hold replicas of Z
Distributing Load
A
B
C
Y
Z
M
17Wednesday, November 7, 12
Z and A hold replicas of Y
Distributing Load
A
B
C
Y
Z
M
18Wednesday, November 7, 12
Disaster strikes!
Distributing Load
AZ
Y B
CM
19Wednesday, November 7, 12
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
20Wednesday, November 7, 12
Solution: Replace/repair down node
Distributing Load
A
B
C
Y
Z A1
M
21Wednesday, November 7, 12
Solution: Replace/repair down node
Distributing Load
AZ
Y B
C
A1
M
22Wednesday, November 7, 12
Neighboring nodes are needed to stream missing data to A; Results in even more load on neighboring nodes
Problem:Poor data distribution
23Wednesday, November 7, 12
Distributing DataA
B
CD
24Wednesday, November 7, 12
Ideal distribution of keyspace
Distributing DataA
B
CD
E
25Wednesday, November 7, 12
Bootstrapping a node, bisecting one partition; Distribution is no longer ideal
Distributing Data
A
B
CD
EA
C
B
D
26Wednesday, November 7, 12
Moving existing nodes means moving corresponding data; Not ideal
Distributing Data
A
B
CD
EA
C
B
D
27Wednesday, November 7, 12
Moving existing nodes means moving corresponding data; Not ideal
Distributing DataA
B
CD
H E
FG
28Wednesday, November 7, 12
Frequently cited alternative: Double the size of your cluster, bisecting all ranges
Distributing DataA
B
CD
H E
FG
29Wednesday, November 7, 12
Frequently cited alternative: Double the size of your cluster, bisecting all ranges
Virtual Nodes
30Wednesday, November 7, 12
In a nutshell...
host
host
host
31Wednesday, November 7, 12
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
32Wednesday, November 7, 12
Strategies
• Automatic sharding
• Fixed partition assignment
• Random token assignment
33Wednesday, November 7, 12
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
34Wednesday, November 7, 12
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”)
35Wednesday, November 7, 12
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
36Wednesday, November 7, 12
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
37Wednesday, November 7, 12
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
38Wednesday, November 7, 12
Evaluating
• Automatic sharding
• partition size constant (great)
• number of partitions scales linearly with data size (bad)
• Fixed partition assignment
• Random token assignment
39Wednesday, November 7, 12
Evaluating
• Automatic sharding
• Fixed partition assignment
• Number of partitions is constant (good)
• Partition size scales linearly with data size (bad)
• Higher operational complexity (bad)
• Random token assignment
40Wednesday, November 7, 12
Evaluating
• Automatic sharding
• Fixed partition assignment
• Random token assignment
• Number of partitions scales linearly with number of hosts (good ok)
• Partition size increases with more data; decreases with more hosts (good)
41Wednesday, November 7, 12
Evaluating
• Automatic sharding
• Fixed partition assignment
• Random token assignment
42Wednesday, November 7, 12
Cassandra
43Wednesday, November 7, 12
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
44Wednesday, November 7, 12
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, ...
45Wednesday, November 7, 12
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......
46Wednesday, November 7, 12
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
47Wednesday, November 7, 12
New go-to command is nodetool status
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
48Wednesday, November 7, 12
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
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
49Wednesday, November 7, 12
Note the token per-node count
MigrationA
C B
50Wednesday, November 7, 12
Migrationedit conf/cassandra.yaml and restart
# Number of tokens to generate.num_tokens: 256
51Wednesday, November 7, 12
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
52Wednesday, November 7, 12
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
53Wednesday, November 7, 12
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!
54Wednesday, November 7, 12
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)
55Wednesday, November 7, 12
Performance
56Wednesday, November 7, 12
removenode
0
100
200
300
400
Acunu Reflex / Cassandra 1.2 Cassandra 1.1
57Wednesday, November 7, 12
17 node cluster of EC2 m1.large instances, 460M rows
bootstrap
0
125
250
375
500
Acunu Reflex / Cassandra 1.2 Cassandra 1.1
58Wednesday, November 7, 12
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.
59Wednesday, November 7, 12