kafka-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gwens...@apache.org
Subject [04/21] kafka git commit: KAFKA-2930: Update references to ZooKeeper in the docs.
Date Wed, 06 Apr 2016 00:09:11 GMT
KAFKA-2930: Update references to ZooKeeper in the docs.

Author: Flavio Junqueira <fpj@apache.org>

Reviewers: Ismael Juma, Gwen Shapira

Closes #615 from fpj/KAFKA-2930


Project: http://git-wip-us.apache.org/repos/asf/kafka/repo
Commit: http://git-wip-us.apache.org/repos/asf/kafka/commit/c216f8a8
Tree: http://git-wip-us.apache.org/repos/asf/kafka/tree/c216f8a8
Diff: http://git-wip-us.apache.org/repos/asf/kafka/diff/c216f8a8

Branch: refs/heads/0.10.0
Commit: c216f8a8e8ff6a3c140b9e0678c4362d4b035982
Parents: c588a72
Author: Flavio Junqueira <fpj@apache.org>
Authored: Fri Apr 1 15:57:39 2016 -0700
Committer: Gwen Shapira <cshapi@gmail.com>
Committed: Tue Apr 5 17:08:53 2016 -0700

----------------------------------------------------------------------
 docs/ops.html | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/kafka/blob/c216f8a8/docs/ops.html
----------------------------------------------------------------------
diff --git a/docs/ops.html b/docs/ops.html
index 541a01d..b239a0e 100644
--- a/docs/ops.html
+++ b/docs/ops.html
@@ -934,17 +934,17 @@ The final alerting we do is on the correctness of the data delivery.
We audit th
 <h3><a id="zk" href="#zk">6.7 ZooKeeper</a></h3>
 
 <h4><a id="zkversion" href="#zkversion">Stable version</a></h4>
-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 over a year now.
+The current stable branch is 3.4 and the latest release of that branch is 3.4.6, which is
the one ZkClient 0.7 uses. ZkClient is the client layer Kafka uses to interact with ZooKeeper.
 
 <h4><a id="zkops" href="#zkops">Operationalizing ZooKeeper</a></h4>
 Operationally, we do the following for a healthy ZooKeeper installation:
 <ul>
-  <li>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.</li>
-  <li>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).</li>
+  <li>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. A typical ZooKeeper ensemble has 5 or 7 servers, which tolerates 2 and 3 servers
down, respectively. If you have a small deployment, then using 3 servers is acceptable, but
keep in mind that you'll only be able to tolerate 1 server down in this case. </li>
+  <li>I/O segregation: if you do a lot of write type traffic you'll almost definitely
want the transaction logs on a dedicated disk group. Writes to the transaction log are synchronous
(but batched for performance), and consequently, concurrent writes can significantly affect
performance. ZooKeeper snapshots can be one such a source of concurrent writes, and ideally
should be written on a disk group separate from the transaction log. Snapshots are writtent
to disk asynchronously, so it is typically ok to share with the operating system and message
log files. You can configure a server to use a separate disk group with the dataLogDir parameter.</li>
   <li>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).</li>
   <li>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</li>
-  <li>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 JMX and
the 4 letter words (4lw) 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)</li>
-  <li>Don't overbuild the cluster: large clusters, especially in a write heavy usage
pattern, means a lot of intracluster communication (quorums on the writes and subsequent cluster
member updates), but don't underbuild it (and risk swamping the cluster).</li>
-  <li>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.</li>
+  <li>ZooKeeper configuration: 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, but keep in mind that allowing for more
ZooKeeper state means that snapshots can become large, and large snapshots affect recovery
time. In fact, if the snapshot becomes too large (a few gigabytes), then you may need to increase
the initLimit parameter to give enough time for servers to recover and join the ensemble.</li>

+  <li>Monitoring: Both JMX and the 4 letter words (4lw) 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)</li>
+  <li>Don't overbuild the cluster: large clusters, especially in a write heavy usage
pattern, means a lot of intracluster communication (quorums on the writes and subsequent cluster
member updates), but don't underbuild it (and risk swamping the cluster). Having more servers
adds to your read capacity.</li>
 </ul>
 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.


Mime
View raw message