DNS on its own can be enough in some scenarios
Care to explain how DNS alone can do distributed config management?
Look up how service discovery via srv records works. That is how active directory (amongst other things) works under the covers
ZooKeeper vs. Doozer vs. Etcd
81–90 of 91 posts
Re: ZooKeeper vs. Doozer vs. Etcd
#82If infrastructure (eg system) configuration is the goal, there's already a much more accessible project with backend support (flexibility to hack up support for ldap, zk, etc):
https://github.com/puppetlabs/hiera
Intro: http://www.devco.net/archives/2011/06/05/hiera_a_pluggable_h...
Note: Does not depend on puppet, so it'll work with chef. A hiera-databag adapter would make sense.
Re: ZooKeeper vs. Doozer vs. Etcd
#83Earlier quoted context omitted.
You can also use DNS like a distributed cache. This is useful when you have millions of clients because their local DNS server will do caching for you. You can also use it like a bloom filter where cache hits are true positives and anything that misses might or might not be a valid key.
That sounds like the opposite of a Bloom filter. In a Bloom filter, you can have false positives but you always get true negatives.
I meant to say "except" where i went on explaining the opposite kind of lookups.
Re: ZooKeeper vs. Doozer vs. Etcd
#84Sorry if this is a dumb question but I've never understood the purpose of these configuration stores. If you're not running in the cloud, but have servers in a datacenter that all mount an NFS share, is there any benefit of these over simply reading a json/yaml file off of an NFS mount?
Resiliency to your NFS server falling over is one. Sane atomic updates and locking is another.
HA NFS is not hard. Using DRDB to replicate the underlying block device, or Gluster to replicate the underlying filesystem, plus IP takeover or e.g. keeaplived is fairly trivial to set up. Running NFS on a single server is a bit like running one of these configuration management systems on a single server - they won't be resilient then either. Using Gluster directly is another easy way of getting resiliency.
Atomic updates and locking is another matter, but for a lot of setups it's simply not needed.
Re: ZooKeeper vs. Doozer vs. Etcd
#85Earlier quoted context omitted.
Resiliency to your NFS server falling over is one. Sane atomic updates and locking is another.
HA NFS is not hard. Using DRDB to replicate the underlying block device, or Gluster to replicate the underlying filesystem, plus IP takeover or e.g. keeaplived is fairly trivial to set up. Running NFS on a single server is a bit like running one of these configuration management systems on a single server - they won't be resilient then either. Using Gluster directly is another easy way of getting resiliency. Atomic u…
Or you can run a single tool that is designed for this one job.
Gluster in particular isn't a panacea for resiliency, you've got to really know where it departs from POSIX to not create problems for yourself.
Re: ZooKeeper vs. Doozer vs. Etcd
#86Earlier quoted context omitted.
> raft doesn't allow reading directly from followers, In raft all client connections to followers redirected to use the current master. > i think they did paxos a disadvantage by not just focusing on multi-paxos Raft is equivalent to (multi-)Paxos
Having followers redirect to the leader is how the paper describes the algorithm. But I don't think there is anything stopping you from having followers service committed log entry reads, provided you're willing to live with being out-of-date.
i don't think this is the case. here is a link to a video by one of the authors about log repair during leader election:
http://www.youtube.com/watch?feature=player_detailpage&v=YbZ...
log entries on a follower may get rolled back - and thrown out - since they were not accepted on a majority of followers.
Re: ZooKeeper vs. Doozer vs. Etcd
#87Earlier quoted context omitted.
HA NFS is not hard. Using DRDB to replicate the underlying block device, or Gluster to replicate the underlying filesystem, plus IP takeover or e.g. keeaplived is fairly trivial to set up. Running NFS on a single server is a bit like running one of these configuration management systems on a single server - they won't be resilient then either. Using Gluster directly is another easy way of getting resiliency. Atomic u…
Or you can run a single tool that is designed for this one job. Gluster in particular isn't a panacea for resiliency, you've got to really know where it departs from POSIX to not create problems for yourself.
Are the GlusterFS people mistaken?
http://gluster.org/community/documentation/index.php/Gluster...
"GlusterFS is fully POSIX compliant."
Re: ZooKeeper vs. Doozer vs. Etcd
#88Earlier quoted context omitted.
Or you can run a single tool that is designed for this one job. Gluster in particular isn't a panacea for resiliency, you've got to really know where it departs from POSIX to not create problems for yourself.
Are the GlusterFS people mistaken? http://gluster.org/community/documentation/index.php/Gluster... "GlusterFS is fully POSIX compliant."
Ooh, news to me. That certainly wasn't the case 2 years ago.
Re: ZooKeeper vs. Doozer vs. Etcd
#89One point the article didn't cover is clients. Making a good Zookeeper client is hard, for two reasons: 1. The protocol is difficult to implement. In theory you could just use Jute to codegen this part, but that assumes Jute supports the language you need. Doozer improves on this with a simple text-based protocol, and etcd goes a little further with a HTTP API. 2. The primitives Zookeeper exposes are very primitive.…
one other thing to keep in mind is that the underlying algorithms (zab and raft) provide different guarantees. for example, zookeeper/zab allows reading directly from followers with a guarantee to get at least a past value that won't be rolled back. this was one reason zookeer didn't use paxos: https://cwiki.apache.org/confluence/display/ZOOKEEPER/Zab+vs... in my understanding, raft doesn't allow reading directly fro…
I'm the original author of go-raft (the implementation used in etcd) so I'll try to address some of the points in this thread.
Raft only updates the state of the system once log entries are committed to a quorum the local state will never be rolled back. Log entries can be thrown out but they haven't been committed to the local state so it doesn't matter.
You can read from the leader if you need to ensure linearizability but that will kill your read scaling. Another approach is to read locally and check that the local raft node isn't in a "candidate" state (which would mean that it hasn't received a heartbeat from the master within the last 150ms). That approach works for a lot of cases.
As far as implementing multi-paxos, the authors behind Google Chubby have talked about how there is a large divide between theoretical multi-paxos and actually implementing multi-paxos. Also, there aren't any standalone multi-paxos Go libraries available. I wrote go-raft at the time because there wasn't an alternative distributed consensus library in Go at the time.
Let me know if you need an extra pair of eyes on your Raft implementation or if you have any questions (ben@skylandlabs.com).
Re: ZooKeeper vs. Doozer vs. Etcd
#90There's also http://arakoon.org/