Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ZooKeeper vs. Doozer vs. Etcd

devo.ps

Post reply on HN
Print view View original

31–40 of 91 posts

Re: ZooKeeper vs. Doozer vs. Etcd

#31

Post by ideal0227 »

tomjohnson3 wrote: post #21
russell_h wrote: post #13

One 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…

One thing is not correct. Raft allows to read from followers. You will never be able to read uncommitted value in raft.

Re: ZooKeeper vs. Doozer vs. Etcd

#32

Post by fintler »

enigmo wrote: post #26
voidmain wrote: post #24

Earlier quoted context omitted.

I agree. At FoundationDB, we're writing a coordination tool (working name "beastmaster") that provides service discovery, locking, leader election, etc on top of our transactional key/value store. It is higher level than these tools; our idea is to try to make it useful from a command line or DNS rather than have to be baked into every piece of software that needs service discovery. beast service --lock name=mailserv…

That's how our Chubby clone works... it uses the Route53 API to publish service endpoints and leaders.

I'm also in the club of people building one of these things (mine is on top of LevelDB and written in ANSI C with a lock-free design).

My most recent blog post is on getting the thing to bootstrap: http://www.bringhurst.org/2013/09/09/consensus-quorum-bootst...

Re: ZooKeeper vs. Doozer vs. Etcd

#33

Post by babo »

tomjohnson3 wrote: post #21
russell_h wrote: post #13

One 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…

> 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

Re: ZooKeeper vs. Doozer vs. Etcd

#34

Post by enigmo »

joevandyk wrote: post #29

I use postgresql + listen/notify to share and push configuration out to applications. Each application starts a thread that LISTEN's for NOTIFY's from postgresql. I have a settings table (name text, value text). Configuration data is stored there. insert into settings (name, value) values ('sites.my-site.authnet.api_key', 'asdfasdf'); There's a trigger on that table that issues a NOTIFY to all the clients. When the c…

If you already have to maintain a database and don't need lease/lock management or simple failover... broadcasting configuration values is pretty simple, sure.

Re: ZooKeeper vs. Doozer vs. Etcd

#35

Post by Juha »

benjaminwootton wrote: post #11
rkoz wrote: post #4

Earlier quoted context omitted.

Care to explain how DNS alone can do distributed config management?

Spotify store some configuration in configuration to good effect: http://labs.spotify.com/tag/dns/ It's obviously no Zookeeper but it is proven and mature.

That's interesting use of dns indeed.

They also mention the DNS for service discovery approach starts to reach it's limits and Spotify is considering Zookeeper (quote):

   We have not yet (as of January 2013) started implementing a replacement. We are 
   looking into using Zookeeper as an authoritative source for a static and dynamic 
   service registry, likely with a DNS facade.

Re: ZooKeeper vs. Doozer vs. Etcd

#36

Post by enigmo »

fintler wrote: post #32
enigmo wrote: post #26

Earlier quoted context omitted.

That's how our Chubby clone works... it uses the Route53 API to publish service endpoints and leaders.

I'm also in the club of people building one of these things (mine is on top of LevelDB and written in ANSI C with a lock-free design). My most recent blog post is on getting the thing to bootstrap: http://www.bringhurst.org/2013/09/09/consensus-quorum-bootst...

Ours is on top of LevelDB too but "lock free" in Haskell using the STM.

Re: ZooKeeper vs. Doozer vs. Etcd

#37

Post by johnbellone »

Juha wrote: post #30
alecthomas wrote: post #23

The story of Doozer is a classic example of how not to steward an open source project. It was released by two Heroku engineers who promptly completely abandoned it. By completely I mean did not respond to any communication whatsoever for a year or so, despite a very active community that had sprung up around the project in terms of users and forks. I don't begrudge them their lives (or whatever drew them away), but t…

I agree. It's a pity Doozer got to this point. I was happy to see that still this years Febrary proactive developers in the google groups ( https://groups.google.com/forum/#!topic/doozer/fVcS0y3KuHQ ) tried to get the project active and coordinated, but I guess merging different codebases from different forks was too big of a challenge.

What it really needs is a company like this to get behind it and stewart it.

Re: ZooKeeper vs. Doozer vs. Etcd

#39

Post by vidarh »

rkoz wrote: post #16
alanctgardner2 wrote: post #7

Earlier quoted context omitted.

Oh! Treat records as key-value pairs, and encode the value into the IP. If your timeout is 10 seconds, add a DNS record timeout.server.yourdomain which resolves to an IPv6 address with value 10. It gets tougher with ASCII strings, but you could support multi-record configs as well. Then your application just uses nslookup to download the config when you reload it. If someone builds this I will be their best friend

DNS maybe good for lightweight service discovery, people have been doing it for ages. However I wont waste anytime trying to dress it up as an answer for real world config management problems (distributed, hierarchical, model-agnostic, consistent .."stuff")

The only one on your checklist that DNS doesn't cover is consistency, and there's tons of applications where short term inconsistency is totally acceptable.

Re: ZooKeeper vs. Doozer vs. Etcd

#40

Post by vidarh »

zimbatm wrote: post #38

Or just push your config on S3 ? Easy to use and setup, reliable, good doc, supports ACL. The only downside is that it's not broadcasting changes.

People use services like Doozer, Zookeper and Etcd because of consistency+availability guarantees. S3 will give you the availability, but not consistency. If you can sacrifice consistency, there are tons of trivial ways of doing this (in addition to your suggestion of S3):

* DNS with slaves

* LDAP with slaves

* Rsync of a directory of config files

* Pair of web servers or NFS servers or Samba servers using either rsync or a redundant network filesystem (e.g. GlusterFS) or block device (e.g DRDB) to back it.

Solving that problem is easy. It's once you need/want the consistency guarantees things get dicy.

Post reply on HN