The document describes Chubby, a lock service developed by Google for loosely coupled distributed systems. Chubby uses a consensus protocol to elect a master from replicas and provides coarse-grained locking. It interfaces like a file system but stores ephemeral and permanent nodes. Clients cache data and use handles to subscribe to events. Chubby scales through techniques like reducing communication and partitioning while its usage includes locking, naming, and master election in distributed systems like GFS and Bigtable.

1. Advanced Topics in
Distributed Systems
The Chubby lock service for loosely-
coupled distributed systems
Mike Burrows, Google Inc.
Presented by: Ioanna Tsalouchidou
1

2. Outline
● Introduction
● Design
● Scaling
● Usage
● Summary
2

3. Introduction
● What is Chubby?
– An engineering effort by Google
– Coarse-grained lock service
– Loosely-coupled distributed systems
– Large number of small machines
– High-speed network (1Gbit/s Ethernet)
– Availability and Reliability Vs. Performance
3

4. Outline
● Introduction - Motivation
● Design
● Scaling
● Usage
● Summary
4

5. Design
le
iona
Rat
ks Se
Loc qu
en
Sy
st em ce
str rs
uc
tur rs
e
handle
File
Fa Backup
es il-o
pAliv ve
Kee rs
Dir Mirroring
ec
tor Events
ies
ns
Sessio
Ca se
ch a Ba API
ing Dat
5

6. Rationale
● Lock service library Vs. Paxos client library
– Maintain existing program structure
– Advertising the results
– Familiar interface to programmers
– Reduces the # of servers needed for progress
● Design decision
– Small-files service (for primaries)
– Event notification
– Consistent caching 6

7. Rationale
● Coarse-grained locks
– Less load in the lock server
– Less delay caused by lock server unavailability
– Survive lock server failures
– Many clients served by less servers
● Fine-grained locks
– Lock-server unavailability → many clients stall
7

8. System Structure
● One Chubby cell → five servers
● Client ↔ Server: via client library
● Server and library communicate via RPC
8
● Optional: proxy server

9. Chubby Cell
● Set of five servers (replicas)
:-)
● Distributed consensus protocol
● One master among replicas
● Master lease → periodically renewed
9

10. Chubby Client
● Clients find the master between replicas
● Client requests to master
● Write requests via consensus protocol
among replicas
● Read requests handled by master
App Library
10

11. Files, directories and handles
● Interface: similar to UNIX file system
/ls/foo/wombat/pouch
11

12. Files, directories and handles
● Interface: similar to UNIX file system
/ls/foo/wombat/pouch
Stands for lock service.
Common to all Chubby names
12

13. Files, directories and handles
● Interface: similar to UNIX file system
/ls/foo/wombat/pouch
Stands for lock service.
Common to all Chubby names
The name of a Chubby cell, which is
resolved to one or more servers
through a DNS lookup
13

14. Files, directories and handles
● Interface: similar to UNIX file system
/ls/foo/wombat/pouch
Stands for lock service.
Common to all Chubby names
The name of a Chubby cell, which is
resolved to one or more servers
through a DNS lookup
The name of the directory and the file
14

15. Files, directories and handles
● Interface: similar to UNIX file system
/ls/foo/wombat/pouch
● Name space: files and directories called nodes
– Ephemeral
– Permanent
● Clients open nodes to obtain Handles
– ~ UNIX file descriptors
– Subscription to events
15

16. Locks
● Any node can act as a lock
● Advisory locks (no mandatory locks)
● Client handles hold
– Exclusive locks (write)
– Shared locks (read)
● No write permission → no influence to writers
16

17. Sequencers
● Sequence numbers to interactions that use
locks
● Lock holder requests a sequencer
● Opaque bite-string → state of lock
– Name of lock
– Mode which was acquired
– Lock generation number
17

18. Caching
● To reduce read traffic
– File data
– Meta-data
– File absence
– Consistent, write-through cache
18

19. Fail-overs
19

20. Fail-overs
20

21. Fail-overs
OOOPS
21

22. Fail-overs
OOOPS
22

23. Outline
● Introduction - Motivation
● Design
● Scaling
● Usage
● Summary
24

24. Current scaling techniques
● Reduce communication with the master
– Client caching
– Open handles
● Use a nearby cell (found with DNS)
● Increase lease time (12s → 60s)
● Protocol-conversion servers
– Translate Chubby to less-complex
25

25. Future scaling techniques
● Proxies
– Handling KeepAlive requests
– Read requests
● Partitioning
– Enable large Chubby cells
– Little communication between partitions
26

26. Outline
● Introduction
● Design
● Scaling
● Usage
● Summary
27

27. Usage
● Initially as a lock service
● Most popular use as a name service
● GFS: to appoint a master server
● Bigtable
– Master election
– Master discovers its controlling servers
– Clients to find their master
28

28. Summary
● Distributed lock service
– Coarse grained synchronization
● Based on existing ideas and algorithms
● Primary internal name service
● Reliable but low-volume storage
29

29. Advanced Topics in
Distributed Systems
The Chubby lock service for loosely-
coupled distributed systems
Mike Burrows, Google Inc.
Presented by: Ιωάννα Τσαλουχίδου
30