Page History

...

Zookeeper is essential for the correct operation of Kafka. There are a number of things that must be done to keep zookeeper running happily as we have learned the hard way, hopefully Dave and Neha will add this since I don't know what we did.

Stable version

At LinkedIn, we are running Zookeeper 3.3.*. Version 3.3.3 has known serious issues regarding ephemeral node deletion and session expirations. After running into those issues in production, we upgraded to 3.3.4 and have been running that smoothly for 1/2 year now.

Operationalizing Zookeeper

Operationally, we do the following for a healthy Zookeeper installation -

1. Redundancy in the physical/hardware/network layout: try not to put them all in the same rack, decent (but don't go nuts) hardware, try to
   keep redundant power and network paths, etc
2. I/O segregation: if you do a lot of write type traffic you'll almost definitely want the transaction logs on a different disk group than
   application logs and snapshots (the write to the zookeeper service has a synchronous write to disk, which can be slow).
3. Application segregation: Unless you really understand the application patterns of other apps that you want to install on the same box, it
   can be a good idea to run zookeeper in isolation (though this can be a balancing act with the capabilities of the hardware).
4. Use care with virtualization: It can work, depending on your cluster layout and read/write patterns and SLAs, but the tiny overheads
   introduced by the virtualization layer can add up and throw off zookeeper, as it can be very time sensitive
5. Zookeeper configuration and monitoring: It's java, make sure you give it 'enough' heap space (We usually run them with 3-5G, but that's
   mostly due to the data set size we have here). Unfortunately we don't have a good formula for it. As far as monitoring, both JMZ and the 4
   letter commands are very useful, they do overlap in some cases (and in those cases we prefer the 4 letter commands, they seem more
   predictable, or at the very least, they work better with the LI monitoring infrastructure)
6. Don't overbuild the cluster: large clusters, especially in a write heavy usage pattern, means a lot of intra cluster communication
   (quorums on the writes and subsequent cluster member updates), but don't underbuild it (and risk swamping the cluster).
7. Try to run on a 3-5 node cluster: Zookeeper writes use quorums and inherently that means having an odd number of machines in a cluster.
   Remember that a 5 node cluster will cause writes to slow down compared to a 3 node cluster, but will allow more fault tolerance.

Overall, we try to keep the zookeeper system as small as will handle the load (plus standard growth capacity planning) and as simple as possible. We try not to do anything fancy with the configuration or application
layout as compared to the official release as well as keep it as self contained as possible. For these reasons, we tend to skip the OS packaged versions, since it has a tendency to try to put things in the OS standard hierarchy, which can be 'messy', for want of a better way to word it.