We are indeed running this setup in production, have been for almost 2
years now, over a gradually increasing number of deployments.
Let me clarify though:
Our clusters don't exceed 5 nodes. We're not exercising Kafka nowhere
near its limits, or bandwidth or disk I/O for that matter.
When we reach the point we want to scale Kafka independently from ZK, we
will. The current setup is not set in stone. But for now everything is
running under modest load, so don't see the point of forgoing the
simplicity of this until we actually have a need to scale further or put
greater load on it. YMMV, not everyone is running at the same scale as
Heroku ;-)
Thanks,
Michal
On 04/06/17 11:34, Tom Crayford wrote:
Hi,
I would not recommend running this kind of set up in production. Busy
Kafka brokers use up a lot of disk and network bandwidth, which
zookeeper does not deal well with. This means that a burst of traffic
to 1 node carries the risk of disrupting the ZK ensemble.
Secondly, this will cause problems down the line, because you will
want to scale Kafka independently from ZK. ZK gets slower as you add
nodes, but Kafka can scale out for quite a while. For production
clusters, I'd recommend to always have 5 ZK nodes, but for Kafka, you
can scale well past that, or keep it small while you are starting out.
Thanks,
Tom Crayford
Heroku Kafka
On Sat, Jun 3, 2017 at 8:20 AM, Michal Borowiecki
<michal.borowie...@openbet.com <mailto:michal.borowie...@openbet.com>>
wrote:
I'm not an expert but I prefer keeping zookeepers on the same
hosts as kafka brokers and mimic each-others topology. The reason
is to minimize the chance of e.g. kafka brokers being able to talk
to one another but zookeepers not, or vice-versa. So, I'd say I
/do/ want my kafka broker and the co-located zookeeper to go down
together - for simplicity - prefer that to some asymmetric
failures to debug. This comes from past experience, albeit using
other technologies, when relying on 2 different clustering
mechanism made failures in one but not the other very difficult to
debug.
Also, I think I read this advice somewhere a long time ago (don't
recall where) and it made sense to me (given the prior experience)
and we've never tried a different arrangement.
As to the overheads, I believe it's mostly disk IO and can
hopefully be addressed by separate disks for each but it's never
been a bottleneck for us, so can't really say.
Thanks,
Michał
On 02/06/17 21:47, Mohammed Manna wrote:
Usually, the overhead comes when you have kafka and zookeeper doing the
housekeeping (i.e. Disk IO) on the same server. ZK even suggests that you
should keep their logs on totally different physical machine for better
performance. Furthermore, if a mechanical failure occurs, you might not
want both zookeeper and broker going down together.
Can anyone else chime in for some better points?
On 2 Jun 2017 7:57 pm, "Meghana Narasimhan"<mnarasim...@bandwidth.com>
<mailto:mnarasim...@bandwidth.com>
wrote:
Hi,
What are the pros and cons of setting up Zookeeper on the same server as
the Kafka broker ? Earlier offsets were being written to zookeeper which
was a major overhead but with offsets being written to Kafka now, what
other requirements should be taken into consideration for setting up
Zookeeper on the same server as Kafka vs having a separate zookeeper
cluster ?
Thanks,
Meghana
--
<http://www.openbet.com/> Michal Borowiecki
Senior Software Engineer L4
T: +44 208 742 1600 <tel:+44%2020%208742%201600>
+44 203 249 8448 <tel:+44%2020%203249%208448>
E: michal.borowie...@openbet.com
<mailto:michal.borowie...@openbet.com>
W: www.openbet.com <http://www.openbet.com/>
OpenBet Ltd
Chiswick Park Building 9
566 Chiswick High Rd
London
W4 5XT
UK
<https://www.openbet.com/email_promo>
This message is confidential and intended only for the addressee.
If you have received this message in error, please immediately
notify the postmas...@openbet.com <mailto:postmas...@openbet.com>
and delete it from your system as well as any copies. The content
of e-mails as well as traffic data may be monitored by OpenBet for
employment and security purposes. To protect the environment
please do not print this e-mail unless necessary. OpenBet Ltd.
Registered Office: Chiswick Park Building 9, 566 Chiswick High
Road, London, W4 5XT, United Kingdom. A company registered in
England and Wales. Registered no. 3134634. VAT no. GB927523612
--
Signature
<http://www.openbet.com/> Michal Borowiecki
Senior Software Engineer L4
T: +44 208 742 1600
+44 203 249 8448
E: michal.borowie...@openbet.com
W: www.openbet.com <http://www.openbet.com/>
OpenBet Ltd
Chiswick Park Building 9
566 Chiswick High Rd
London
W4 5XT
UK
<https://www.openbet.com/email_promo>
This message is confidential and intended only for the addressee. If you
have received this message in error, please immediately notify the
postmas...@openbet.com <mailto:postmas...@openbet.com> and delete it
from your system as well as any copies. The content of e-mails as well
as traffic data may be monitored by OpenBet for employment and security
purposes. To protect the environment please do not print this e-mail
unless necessary. OpenBet Ltd. Registered Office: Chiswick Park Building
9, 566 Chiswick High Road, London, W4 5XT, United Kingdom. A company
registered in England and Wales. Registered no. 3134634. VAT no.
GB927523612
