Recommended setup & configuration for 3 servers

Hi Doug

So if I installed elasticsearch on my 3 servers (all on the same
network, with multicast enabled (is that an apt-get install?)),

...however you install ES

used the same clustername for them, and they could all see each other
on post 9300, would ...

  1. An index created on one with 2 replicas automatically replicate
    across the 3 servers?

Yes

  1. A document indexed to one server automatically be replicated to 2
    other replicas on the other two servers?

Yes

  1. A fallen-over node be able to bring itself back up, repair itself,
    and add itself back into the cluster? Would the service wrapper do
    this?

Well, depends...

If a node dies, the service wrapper should restart it.

If a node leaves the cluster for some reason (eg network outage) then it
won't rejoin the cluster automatically (unless something has changed
recently that I don't know about).

You would have to stop and start the node manually for it to rejoin the
cluster. And it is possible that you could have docs indexed just to
this node and not to the other two nodes, which you would then lose.
There is no conflict resolution available.

Have a look at "Write consistency" on this page:

clint

That's fantastic, thankyou very much for answering so fully and patiently.
I have just one last question -- is it definitely port 9300 that the nodes
need to be able to see each other on, rather than 9200 (like for local
development)?
& thanks again,
Doug.

On 17 October 2011 15:56, Clinton Gormley clint@traveljury.com wrote:

Hi Doug

So if I installed elasticsearch on my 3 servers (all on the same
network, with multicast enabled (is that an apt-get install?)),

...however you install ES

used the same clustername for them, and they could all see each other
on post 9300, would ...

  1. An index created on one with 2 replicas automatically replicate
    across the 3 servers?

Yes

  1. A document indexed to one server automatically be replicated to 2
    other replicas on the other two servers?

Yes

  1. A fallen-over node be able to bring itself back up, repair itself,
    and add itself back into the cluster? Would the service wrapper do
    this?

Well, depends...

If a node dies, the service wrapper should restart it.

If a node leaves the cluster for some reason (eg network outage) then it
won't rejoin the cluster automatically (unless something has changed
recently that I don't know about).

You would have to stop and start the node manually for it to rejoin the
cluster. And it is possible that you could have docs indexed just to
this node and not to the other two nodes, which you would then lose.
There is no conflict resolution available.

Have a look at "Write consistency" on this page:
Elasticsearch Platform — Find real-time answers at scale | Elastic

clint

Hi,

Nodes talk to each other through proprietary binary protocol, by default it
is bound to ports starting at 9300. However, it can be fully customized:

Every node can also expose its API via HTTP, by default this is allowed and
is bound to ports starting at 9200. This can be customized as well:

This is what many [third-party] clients use to talk to nodes in cluster.

Regards,
Lukas

On Mon, Oct 17, 2011 at 11:30 PM, doug livesey biot023@gmail.com wrote:

That's fantastic, thankyou very much for answering so fully and patiently.
I have just one last question -- is it definitely port 9300 that the nodes
need to be able to see each other on, rather than 9200 (like for local
development)?
& thanks again,
Doug.

On 17 October 2011 15:56, Clinton Gormley clint@traveljury.com wrote:

Hi Doug

So if I installed elasticsearch on my 3 servers (all on the same
network, with multicast enabled (is that an apt-get install?)),

...however you install ES

used the same clustername for them, and they could all see each other
on post 9300, would ...

  1. An index created on one with 2 replicas automatically replicate
    across the 3 servers?

Yes

  1. A document indexed to one server automatically be replicated to 2
    other replicas on the other two servers?

Yes

  1. A fallen-over node be able to bring itself back up, repair itself,
    and add itself back into the cluster? Would the service wrapper do
    this?

Well, depends...

If a node dies, the service wrapper should restart it.

If a node leaves the cluster for some reason (eg network outage) then it
won't rejoin the cluster automatically (unless something has changed
recently that I don't know about).

You would have to stop and start the node manually for it to rejoin the
cluster. And it is possible that you could have docs indexed just to
this node and not to the other two nodes, which you would then lose.
There is no conflict resolution available.

Have a look at "Write consistency" on this page:
Elasticsearch Platform — Find real-time answers at scale | Elastic

clint

One more think that I am not 100% sure that was explained in this
discussion, is that when you search on a node, the search will automatically
be balanced and executed across several shards (matching the search
request), and balanced across several nodes. So, elasticsearch will do the
distributed search part for you.

Even if you have 1 index, with 5 shards, and 2 replicas on 3 node cluster,
the search request will end up executed on 5 different shards, across
several nodes.

On Mon, Oct 17, 2011 at 11:40 PM, Lukáš Vlček lukas.vlcek@gmail.com wrote:

Hi,

Nodes talk to each other through proprietary binary protocol, by default it
is bound to ports starting at 9300. However, it can be fully customized:
Elasticsearch Platform — Find real-time answers at scale | Elastic

Every node can also expose its API via HTTP, by default this is allowed and
is bound to ports starting at 9200. This can be customized as well:
Elasticsearch Platform — Find real-time answers at scale | Elastic
This is what many [third-party] clients use to talk to nodes in cluster.

Regards,
Lukas

On Mon, Oct 17, 2011 at 11:30 PM, doug livesey biot023@gmail.com wrote:

That's fantastic, thankyou very much for answering so fully and patiently.
I have just one last question -- is it definitely port 9300 that the nodes
need to be able to see each other on, rather than 9200 (like for local
development)?
& thanks again,
Doug.

On 17 October 2011 15:56, Clinton Gormley clint@traveljury.com wrote:

Hi Doug

So if I installed elasticsearch on my 3 servers (all on the same
network, with multicast enabled (is that an apt-get install?)),

...however you install ES

used the same clustername for them, and they could all see each other
on post 9300, would ...

  1. An index created on one with 2 replicas automatically replicate
    across the 3 servers?

Yes

  1. A document indexed to one server automatically be replicated to 2
    other replicas on the other two servers?

Yes

  1. A fallen-over node be able to bring itself back up, repair itself,
    and add itself back into the cluster? Would the service wrapper do
    this?

Well, depends...

If a node dies, the service wrapper should restart it.

If a node leaves the cluster for some reason (eg network outage) then it
won't rejoin the cluster automatically (unless something has changed
recently that I don't know about).

You would have to stop and start the node manually for it to rejoin the
cluster. And it is possible that you could have docs indexed just to
this node and not to the other two nodes, which you would then lose.
There is no conflict resolution available.

Have a look at "Write consistency" on this page:
Elasticsearch Platform — Find real-time answers at scale | Elastic

clint

Excellent, so literally the only thing I need to worry about with regards to
redundancy is implementing failover on the IP of the node I call.
Thanks very much,
Doug.

On 18 October 2011 01:06, Shay Banon kimchy@gmail.com wrote:

One more think that I am not 100% sure that was explained in this
discussion, is that when you search on a node, the search will automatically
be balanced and executed across several shards (matching the search
request), and balanced across several nodes. So, elasticsearch will do the
distributed search part for you.

Even if you have 1 index, with 5 shards, and 2 replicas on 3 node cluster,
the search request will end up executed on 5 different shards, across
several nodes.

On Mon, Oct 17, 2011 at 11:40 PM, Lukáš Vlček lukas.vlcek@gmail.comwrote:

Hi,

Nodes talk to each other through proprietary binary protocol, by default
it is bound to ports starting at 9300. However, it can be fully customized:
Elasticsearch Platform — Find real-time answers at scale | Elastic

Every node can also expose its API via HTTP, by default this is allowed
and is bound to ports starting at 9200. This can be customized as well:
Elasticsearch Platform — Find real-time answers at scale | Elastic
This is what many [third-party] clients use to talk to nodes in cluster.

Regards,
Lukas

On Mon, Oct 17, 2011 at 11:30 PM, doug livesey biot023@gmail.com wrote:

That's fantastic, thankyou very much for answering so fully and
patiently.
I have just one last question -- is it definitely port 9300 that the
nodes need to be able to see each other on, rather than 9200 (like for local
development)?
& thanks again,
Doug.

On 17 October 2011 15:56, Clinton Gormley clint@traveljury.com wrote:

Hi Doug

So if I installed elasticsearch on my 3 servers (all on the same
network, with multicast enabled (is that an apt-get install?)),

...however you install ES

used the same clustername for them, and they could all see each other
on post 9300, would ...

  1. An index created on one with 2 replicas automatically replicate
    across the 3 servers?

Yes

  1. A document indexed to one server automatically be replicated to 2
    other replicas on the other two servers?

Yes

  1. A fallen-over node be able to bring itself back up, repair itself,
    and add itself back into the cluster? Would the service wrapper do
    this?

Well, depends...

If a node dies, the service wrapper should restart it.

If a node leaves the cluster for some reason (eg network outage) then it
won't rejoin the cluster automatically (unless something has changed
recently that I don't know about).

You would have to stop and start the node manually for it to rejoin the
cluster. And it is possible that you could have docs indexed just to
this node and not to the other two nodes, which you would then lose.
There is no conflict resolution available.

Have a look at "Write consistency" on this page:
Elasticsearch Platform — Find real-time answers at scale | Elastic

clint

Hi - So if I want my client to be aware of just one IP and if I want the load balancing to be automatically happen within ES, do I need to put something like Apache fail over mechanism before ES?
The reason is that I dont want my clients to be aware of any nodes except just one destination address.