CLD

OBSOLETE CONTENT

This wiki has been archived and the content is no longer updated.

cld: Coarse locking daemon and namespace service

Overview

One of the lowest-level components of Project Hail. Inspired by Google's "Chubby" lock service, this software provides a cache-coherent, highly-available distributed filesystem for small files.

CLD's primary uses include consensus service (election of a master, with fail-over, also known as lock service), reliable name space, and reliable small file storage.

Notable attributes

• API presented to developers is that of a filesystem: OPEN, CLOSE, READ, WRITE, LOCK, UNLOCK, etc. This renders the API easily understandable to most developers.

• Consensus service, as a service. Coarse locking -- locks held for hours, days, or longer -- may be leveraged to provide master election and fail-over services for other distributed services built on top of this service. Centralized coarse locking frees other distributed services from having to implement the same high-availability fail-over code, over and over again.

• Offloaded consensus. For services built on top of this consensus service, consensus may be achieved even if less than half of the cluster is available. Consensus depends more on lock service high availability, than purely on number of downstream service cluster nodes.

• Cache coherence in a network filesystem. If you are willing to stall writes in order to process cache invalidations, then cached reads may proceed rapidly, without network activity, because the cache is known to be valid.

• Storage of important, ACL-secured data files, often bootstrap configuration files for other cloud services.

• A naming service, an alternative to internal DNS, because DNS cache expiration is much less precise than CLD cache expiration policy.

Coarse grained locking

Fine-grained locking is the practice of locking + using + unlocking a resource in rapid succession.

The opposite, coarse grained locking, is the practice of holding locks for hours, days, or longer. Coarse grained locks impose less load on a lock server, and lock acquisition rate is only weakly related to transaction rate. Lock server availability has less impact on clients, relative to fine-grained locking.

A common example is that of electing a primary from an equivalent set of replicas. All replicas attempt to acquire a lock. One succeeds, becoming the primary, and holds the lock until the replica shuts down or crashes.

Status

Initial server and client coding complete.

Several key design elements not yet implemented:

• replication infrastructure complete in server, needs debugging and test
• no client-side caching
• consider switching from db4 to a less complex, write-ahead logging database.

Resources

See notes on the CLD network protocol.

Download releases here.

Developers: browse the git repo, or check out from git://git.kernel.org/pub/scm/daemon/distsrv/hail.git

Related: Chubby paper (PDF), Paxos made live (PDF)

Open projects

A wealth of projects large and small awaits interested contributors. Programmers will need to learn git, participate on the hail-devel mailing list, check out the source code, build and set up the project. Contributions from non-programmers are welcome as well -- documentation, feedback, and in general using the software.

Here are some suggestions for projects:

• document and debug CLD network protocol
• document setup and system administration procedures
• implement access control lists (ACLs)
• write CLD client libraries for Java, Python, C++, or other languages. Only a C-language client library exists at present.
• CLD's current C client API is noted to be cumbersome, and could be improved.
• write FUSE interface to CLD