Burrows, M. The Chubby lock service for loosely-coupled distributed systems. In Proceedings of the 7th Symposium on Operating Systems Design and Implementation (Seattle, Washington, November 06 - 08, 2006). 335-350.
* * *
Chubby is the distributed lock service used at Google. Based on Paxos, it offers high available coarse-grained locking. The paper includes topics from general rationale to detailed implementation issues.
The application of Chubby goes beyond what it is originally designed for. It is heavily used as a naming service in practice. The locks are named in a file-system-like manner. Thus the servers could keep their locations in files. The servers can make sure the data is never stale since they hold locks on the files. Then client can find the servers by querying everything within the certain directories. Using Chubby this way exploits its features well.
(lxy, lingu)
PDF from Google:
http://labs.google.com/papers/chubby-osdi06.pdf
@inproceedings{burrows06chubby,
author = {Burrows, Mike},
title = {The Chubby lock service for loosely-coupled distributed systems},
booktitle = {Proc. of the 7th Symposium on Operating Systems Design and Implementation},
year = {2006},
pages = {335--350},
location = {Seattle, Washington},
}
Gao Yuan will present this paper
The paper provides a quite comprehensive description of "Chubby" which is, at its heart, a lock service that basically offers high available coarse-grained lockings. The paper includes topics from general rational to detailed implementation issues that nearly covers everything a reader (and maybe a potential client) interested in Chubby needs to know.
The design rationale is thoughtful for developers. By providing a lock services instead of a Paxos library, the developers can easily add in replication and primary election in the developed structures without starting over the whole design. This way, the developers no longer need to take into account how to maintain high availability in the beginning stage of a system. Rather, they are able to concentrate on designing the core of system which is easier to build, to test and to modify. Adding supporting module of high availability later also enables the system development to proceed round-by-round which is an efficient and effective manner that is adopted widely nowadays.
The application of Chubby goes beyond what it is originally designed for. It is heavily used as a naming service in practice. The locks are named in a file-system-like manner. Thus the servers could keep their locations in files. The servers can make sure the data is never stale since they hold locks on the files. Then client can find the servers by querying everything within the certain directories. Using Chubby this way exploits its features well.
On the other hand, Chubby designers are less thoughtful (less practical) in that they seem to complain about developers on that they rarely consider availability. The designers use three mechanisms to prevent this situation. In my opinion, however, I do not believe their first mechanism of advising developers against tying availability too closely to Chubby's would be quite effective. When developers use Chubby services, they are unlikely to care about how Chubby is built up in details, but use it directly to create a reliable distributed lock for their own applications. Relying on developers behaving ideally is by no means a reliable mechanism. The other two mechanisms to prevent the situation seem much better than the first one.
(11-16-2009 03:59 AM)lxy Wrote: [ -> ]In my opinion, however, I do not believe their first mechanism of advising developers against tying availability too closely to Chubby's would be quite effective. When developers use Chubby services, they are unlikely to care about how Chubby is built up in details, but use it directly to create a reliable distributed lock for their own applications. Relying on developers behaving ideally is by no means a reliable mechanism.
You are right. A general principle is that users should only be aware of the interface and semantics of a service, not the internal implementation or pecularities of it.