9 ms·
> It's ironic that ZK requires such consistency when the goals of Mesos are exactly the opposite. Is it ironic? Seems to me that if you want to have a distribu
by mdellabitta 12y ago
> It's ironic that ZK requires such consistency when the goals of Mesos are exactly the opposite.
Is it ironic? Seems to me that if you want to have a distributed cluster that can deal with worker failure and still be useful, you need to rely on something to durably maintain your state at a lower level.
- carlivar 12y agoI agree and I want that thing not to be ZK. Consul or etcd would be fine.
- mdellabitta 12y agoWell, you've described how zk doesn't meet the needs of your software as written, but I'm not sure you've established why Mesos would be better off without it...
- carlivar 12y agoYes, I have. Zookeeper's logging (and thus troubleshooting ability) is atrocious.
- mdellabitta 12y agoAnd yet somehow they seem to have gotten it to work. I run a few Zookeeper-based systems where ZK just seems to work and I don't have to look at logging statements, either. I've never dealt with Zookeeper downtime that wasn't Amazon's fault.
- carlivar 12y agoSo you are having ZK downtime? Such a system shouldn't ever really go down, even with Amazon problems. We strive for software in which individual nodes can be flakey or down without impacting the uptime of the whole cluster. ZK doesn't fit this criteria, as you have just stated. I prefer gossip-based Raft systems, for example (which is why I like Consul so much. We're also big Riak users).
- mdellabitta 12y ago> So you are having ZK downtime? No, individual nodes have gone down based on hardware problems. The system stays up. Jespen has given Zookeeper probably the most ringing endorsement of anything it's tested, so I don't know what you're on about.