When is best practice to use an ES node as HTTP only?

Elastic Stack Elasticsearch
1

I'll have 5 ES nodes in my cluster, at this time I do not know how many
documents we are going to have or what the average queries per second will
be as we haven't go live yet.

Should I set up one of the nodes as a HTTP node to take some of the
processing load of the data nodes or will having a cluster of 5 data nodes
(i.e. no HTTP nodes) be sufficient to handle the processing plus indexing
and searching?

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

2

Will you use clients with HTTP access only? And how many parallel HTTP
client accesses do you want to allow?

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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

3

Thanks for your response.

The plan is to use two HTTP access only clients in parallel.

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

4

If you will access with two clients only, there is almost no need in
preparing extra nodes for them.

Criteria for setting up HTTP proxy nodes are massive parallel HTTP accesses
(a few hundred requests in parallel) and large result sets, which can
legitimate a separation of index/search data nodes from proxy nodes for
HTTP traffic handling and response generation phase.

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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

5

If I have 5 ES nodes in my cluster which ES node should should my clients
point to, the master node? If the master node goes down and a new one is
elected how will my client communicate with Elasticsearch, they will still
be pointing the the node that is down?

On Sunday, October 27, 2013 1:56:31 PM UTC, Jörg Prante wrote:

If you will access with two clients only, there is almost no need in
preparing extra nodes for them.

Criteria for setting up HTTP proxy nodes are massive parallel HTTP
accesses (a few hundred requests in parallel) and large result sets, which
can legitimate a separation of index/search data nodes from proxy nodes for
HTTP traffic handling and response generation phase.

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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

6

You can handle that with a load balancer, in your app, or use DNS round
robin or something similar.
There's nothing native to ES that'll handle it.

Regards,
Mark Walkom

Infrastructure Engineer
Campaign Monitor
email: markw@campaignmonitor.com
web: www.campaignmonitor.com

On 28 October 2013 19:43, dan dan.tuffery@gmail.com wrote:

If I have 5 ES nodes in my cluster which ES node should should my clients
point to, the master node? If the master node goes down and a new one is
elected how will my client communicate with Elasticsearch, they will still
be pointing the the node that is down?

On Sunday, October 27, 2013 1:56:31 PM UTC, Jörg Prante wrote:

If you will access with two clients only, there is almost no need in
preparing extra nodes for them.

Criteria for setting up HTTP proxy nodes are massive parallel HTTP
accesses (a few hundred requests in parallel) and large result sets, which
can legitimate a separation of index/search data nodes from proxy nodes for
HTTP traffic handling and response generation phase.

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+unsubscribe@googlegroups.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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

7

With the standard Elasticsearch clients
http://www.elasticsearch.org/blog/unleash-the-clients-ruby-python-php-perl/node
failover is fully supported. You can either 'sniff' a cluster for
active nodes, or you can pass a list of node IPs to connect to. If a node
fails, it will be sorted out from the connection list.

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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.