All Elasticsearch nodes will end up being part of the Akka cluster I
think you're really asking how many seed nodes you should specify. The seed
node list is probably going to be similar to what you might use for
zen.unicast.hosts.
Worth noting that besides being initial contact points for when the cluster
is starting up, with eskka they are also used for resolving partitions.
Given this requirement, you would ideally have 3 or more specified. It is
perfectly ok to have all of your nodes listed, if you know their addresses
before startup.
On Wed, May 7, 2014 at 9:31 PM, Ivan Brusic ivan@brusic.com wrote:
Extremely interesting! What is the recommended size of the Akka cluster
compared to the Elasticsearch cluster?
Worth noting that besides being initial contact points for when the
cluster is starting up, with eskka they are also used for resolving
partitions. Given this requirement, you would ideally have 3 or more
specified. It is perfectly ok to have all of your nodes listed, if you know
their addresses before startup.
Another idea for what nodes to use as seed: if you are using master-only
nodes, make them seed nodes.
At Sematext we use both ES and Akka (in SPM http://sematext.com/spm/), so
this is interesting for me to see... Would it make sense to add a bit more
to the README..... things like:
On Thursday, May 8, 2014 3:32:24 AM UTC-4, Shikhar Bhushan wrote:
All Elasticsearch nodes will end up being part of the Akka cluster I
think you're really asking how many seed nodes you should specify. The seed
node list is probably going to be similar to what you might use for
zen.unicast.hosts.
Worth noting that besides being initial contact points for when the
cluster is starting up, with eskka they are also used for resolving
partitions. Given this requirement, you would ideally have 3 or more
specified. It is perfectly ok to have all of your nodes listed, if you know
their addresses before startup.
At Sematext we use both ES and Akka (in SPM http://sematext.com/spm/),
so this is interesting for me to see... Would it make sense to add a bit
more to the README..... things like:
why? is something wrong with Zen?
pros and cons of this vs. Zen vs. ZK
Makes sense to add this context, I'll add to the docs soon.
The major con for eskka is of course that it is new and unproven.
vs zookeeper
You don't need to setup or admin ZooKeeper.
In Shay's resiliency blog post <http://resiliency and elasticsearch> he
writes "By having the discovery module in Elasticsearch using its own
infrastructure, specifically the communication layer, it means that we can
use the “liveness” of the cluster to assess its health." This is an
interesting point which partly holds for eskka as well, since it also lives
in the same JVM. However it doesn't use the same communication layer (the
ES internal transport), the akka cluster runs on a different port.
vs zen
Essentially: eskka is built to be split-brain resistant. But then so is Zen
in theory So I'd like to maybe do some testing with Jepsen before
making that tall claim.
Both Zen and Akka Cluster are implementing a gossip protocol for discovery
& fault-detection, however to me the latter feels better specified and
tested. eskka itself does not have any tests at the application-level which
I intend to fix.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
I
So I'd like to maybe do some testing with Jepsen before