We use mutlicast but our networks are very we're pretty used to multicast for other stuff like varnish cache flushes. I figured unicast vs multicast was a networking decision based on how your data center is rigged. No one has complained about chatter and we've never seen a problem with accidental joining. We keep the cluster names distinct even for networks that we imagine aren't flat from a multicast perspective.
Nik On Wed, Jan 15, 2014 at 3:59 PM, Mohit Anchlia <mohitanch...@gmail.com>wrote: > IHO, I think there is no perfect solution for any of the complex > network issues, however if we know of a config that reduces the risk > signficantly then I think we should adopt that as a default config. > > > On Wed, Jan 15, 2014 at 11:17 AM, joergpra...@gmail.com < > joergpra...@gmail.com> wrote: > >> The preflight checklist is misleading in several statements: >> >> - you can not "accidentally join" clusters because of multicast. It >> happens when using the default cluster name >> >> - "a lot of chatter with no use" is just pure ignorance of network >> technology. Multicast was designed for zero config, and I love ES for zero >> config. And there is no chatter if you set up a private network for ES >> hosts. That is simple with a router/switch and DHCP. Whole corporation and >> datacenter networks can not live without link-local config for example. >> >> - "you don't have to include the whole cluster" is misleading - each data >> node must always be able to connect to one of the eligible master nodes, or >> the cluster may not work correctly >> >> - the "avoiding split brain" section is a very bold and wrong headline. >> It is promising that split-brains can be avoided by a N/2+1 setting. >> Unfortunately that is nonsense, the truth is, it lowers the risk >> significantly. But there can still be obscure network splits where two >> halves of a split cluster may overlap, so the condition of N/2+1 can become >> true for both halves. >> >> Why do I not count hosts/nodes? There is a difference between the number >> of data nodes and master eligible nodes in a cluster. I have three master >> eligible nodes and set minimum_master_nodes to 3, and that's it. After that >> I can start or stop additional data nodes as much as I like. >> >> Jörg >> >> -- >> You received this message because you are subscribed to the Google Groups >> "elasticsearch" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to elasticsearch+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elasticsearch/CAKdsXoG8Yi8KuG7%2BYa3HQEAj%2BDhPUvzoqd6aR-Gpd4iQxAF%3D%2Bw%40mail.gmail.com >> . >> >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to elasticsearch+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elasticsearch/CAOT3TWoibQk_0o313aXEwYkbYrQiVnmgrp4eNnOMTurmCS6PPw%40mail.gmail.com > . > > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAPmjWd198GpnLrTpkFRLzWgZApEiEBqq2-h--GTTUZCQNH4ykA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
