The Cluster Consensus

ZooKeeper of course needs an inherent cluster mode to manage the services within a cloud and on the hosts (Figure 6). This is part of the scope of service: Unlike Etcd or Consul, ZooKeeper relies on Paxos rather than Raft as an algorithm. However, this is just a technical detail from an administrator's perspective.

Figure 6: ZooKeeper also has native clustering in the background. It is by far the most seasoned component in the test.

Crucially, ZooKeeper guarantees programs a consistent cluster state and implements a quorum. This means that if a client connects to a ZooKeeper instance, the client can be sure to always receive the latest data recognized as valid by the cluster. The cluster partitions refuse to work without a quorum majority if the cluster temporarily falls apart.

As with Etcd, a framework for service discovery is missing in ZooKeeper. If you want to use the software accordingly, you need to take care yourself that available services log on and off with an entry in ZooKeeper.

ZooKeeper therefore cannot be used as a service registry. Netflix had such bad experiences that it wrote a standalone discovery service called Eureka [5], which does not require ZooKeeper. Ultimately, Eureka may be considered comparable to Etcd, but without being squeezed as tightly into the cloud corset.

Consul clearly defeats ZooKeeper when it comes to functions. In addition to the missing registry function, a mechanism for generating finished files from the stored configuration parameters is also missing in ZooKeeper: you need to make them yourself.

Multi-data-center setups are also more difficult because of the Paxos algorithm used. ZooKeeper comes with so-called observers that work much like the inter-data-center communication in Consul; however, the number of setups in the real world that actually use observers productively is likely to be extremely low.

Conclusions

Programs like Etcd and Consul make administrators' lives easier when used in the tools' traditional territory. For example, if all setup components are equipped with support for the respective tool, you can forget about synchronization of files in /etc. However – and this is the drawback – it is then very likely just a trendy cloud application designed for use as part of CoreOS or one of the many other micro-distributions. Only when all programs in the installation can communicate directly with the respective configuration manager does the manager reach its full potential.

The tools are significantly less attractive when it comes to conventional programs, with which they have no direct connection. This is where administrators can create a configuration file in /etc themselves using the template function from the respective tool, if available. Such a setup, however, hardly brings any advantages compared with classical automation by Puppet and the like. Old-fashioned programs do not benefit at all from the inherent clustering ability of individual tools.

Anyone who has dealt with Docker or one of the micro-distributions for cloud use will probably enjoy using Etcd, Consul, or ZooKeeper. If you only need central maintenance of archaic configuration files, though, you would be better off using Puppet, Chef, or one of the many alternatives available on the market.

This situation will not necessarily remain static. Because of its RESTful APIs, it is very easy for authors of other programs to adapt their software to the tools reviewed here. For example, if it were possible in the future to persuade the ever-popular Dovecot IMAP server to work with one of these tools, it would be a very attractive combination.