Skip to content

A simple mutex service for coordinating certain cluster operations.

License

Notifications You must be signed in to change notification settings

calston/distributex

Repository files navigation

Distributex

Build Status

Distributex is a simple mutex service for coordinating certain cluster operations.

Note: Distributex is not designed for tasks which require high performance or fair lock acquisition. It is a very simple Busy-waiting lock with very slow acquisition. Do not use it for extremely large clusters either as there's a good chance a requester might never obtain a lock.

Distributex server

The Distributex server provides a simple HTTP service. It is written using Twisted, and provides a Twisted plugin. It also requires PyYAML for its configuration.

You can start it as follows, or wrap it in supervisor, or pass -d, or whatever

$ twistd -n distributex -c distributex.yaml

The configuration file is a simple YAML structure which defines lock pools. A lock pool is a resource you want to allow things to fight over.

backend: memcache
pools:
    - name: pool1
      expire: 300

    - name: pool2
      expire: 300
      maxlocks: 5
      servers: acme1, acme2

This will create two pools whose lock expires after 5 minutes. It's generally a good idea to set an expiry to ensure something, otherwise it will default to 30 minutes. If you don't want it to expire then set it to 0, but I don't recommend that.

You can specify either the 'memcache' backend or 'inmemory', there are pros and cons to both. Memcache will be slower, but state is retained away from the Distributex server and you can scale out workers - however since the inmemory backend can handle about 5000 waiting locks on a single machine redundancy is the only real concern. Lock expiry is also a bit more reliable and simpler in the memcache backend.

A comma separated list of servers can also be provided to prevent accidental pool incursions. This isn't secure, nor are lock releases, since anyone can just forge their hostname. The distributex client will pass the FQDN of the host.

It is also possible to set 'maxlocks' which allows the pool to behave like a semaphore.

You can test the service as follows

$ curl "http://localhost:9889/get/?host=me&pool=pool1"
YES
$ curl "http://localhost:9889/get/?host=them&pool=pool1"
NO
$ curl "http://localhost:9889/release/?host=me&pool=pool1"
OK
$ curl "http://localhost:9889/get/?host=them&pool=pool1"
YES
$ curl "http://localhost:9889/release/?host=them&pool=pool1"
OK

The service also provides a 'wait' command which will leave the connection open until a lock is obtained.

Distributex client

A simple Python script is provided to wrap commands.

usage: distributex [-h] -H HOST -r POOL [-p PORT] [command]

Distributex client

positional arguments:
  command     Command to execute when lock is obtained

optional arguments:
  -h, --help  show this help message and exit
  -H HOST     Server hostname
  -r POOL     Resource pool
  -p PORT     Server port (default 9889)
  -l          Use local locking as well

This is useful for blocking a cron job like Puppet.

*/5 * * * * /usr/bin/distributex -H distributex.acme.com -r pool1 '/usr/bin/puppet agent --onetime --no-daemonize'

This will ensure that only one instance of Puppet in the cluster runs at any time. You might also want to pass -l to distributex to prevent local process overlap.

About

A simple mutex service for coordinating certain cluster operations.

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages