I am setting up a new environment with ElasticSearch, and the out of the
box zen discovery makes it real easy to load balance.
But if I want to set up my environment like the following.
Three servers running on the same network, works perfectly and they find
each other.
es1 10.2.88.21
es2 10.2.88.22
es3 10.2.88.23
But then, from my web application I want to access the cluster via ip
10.2.88.24, which is a virtual ip so that if one node goes down, it does
not matter since I always access 10.2.88.24 and it contains all three of
them.
Is my intentions clear? How would i configure ElasticSearch for this
purpose?
I am setting up a new environment with Elasticsearch, and the out of the
box zen discovery makes it real easy to load balance.
But if I want to set up my environment like the following.
Three servers running on the same network, works perfectly and they find
each other.
es1 10.2.88.21
es2 10.2.88.22
es3 10.2.88.23
But then, from my web application I want to access the cluster via ip
10.2.88.24, which is a virtual ip so that if one node goes down, it does
not matter since I always access 10.2.88.24 and it contains all three of
them.
Is my intentions clear? How would i configure Elasticsearch for this
purpose?
I am setting up a new environment with Elasticsearch, and the out of the
box zen discovery makes it real easy to load balance.
But if I want to set up my environment like the following.
Three servers running on the same network, works perfectly and they find
each other.
es1 10.2.88.21
es2 10.2.88.22
es3 10.2.88.23
But then, from my web application I want to access the cluster via ip
10.2.88.24, which is a virtual ip so that if one node goes down, it does
not matter since I always access 10.2.88.24 and it contains all three of
them.
Is my intentions clear? How would i configure Elasticsearch for this
purpose?
//Tommy
--
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 elasticsearc...@googlegroups.com <javascript:>.
For more options, visit https://groups.google.com/groups/opt_out.
I am setting up a new environment with Elasticsearch, and the out of the
box zen discovery makes it real easy to load balance.
But if I want to set up my environment like the following.
Three servers running on the same network, works perfectly and they find
each other.
es1 10.2.88.21
es2 10.2.88.22
es3 10.2.88.23
But then, from my web application I want to access the cluster via ip
10.2.88.24, which is a virtual ip so that if one node goes down, it does
not matter since I always access 10.2.88.24 and it contains all three of
them.
Is my intentions clear? How would i configure Elasticsearch for this
purpose?
I am setting up a new environment with Elasticsearch, and the out of
the box zen discovery makes it real easy to load balance.
But if I want to set up my environment like the following.
Three servers running on the same network, works perfectly and they
find each other.
es1 10.2.88.21
es2 10.2.88.22
es3 10.2.88.23
But then, from my web application I want to access the cluster via ip
10.2.88.24, which is a virtual ip so that if one node goes down, it does
not matter since I always access 10.2.88.24 and it contains all three of
them.
Is my intentions clear? How would i configure Elasticsearch for this
purpose?
I am setting up a new environment with Elasticsearch, and the out of
the box zen discovery makes it real easy to load balance.
But if I want to set up my environment like the following.
Three servers running on the same network, works perfectly and they
find each other.
es1 10.2.88.21
es2 10.2.88.22
es3 10.2.88.23
But then, from my web application I want to access the cluster via ip
10.2.88.24, which is a virtual ip so that if one node goes down, it does
not matter since I always access 10.2.88.24 and it contains all three of
them.
Is my intentions clear? How would i configure Elasticsearch for this
purpose?
--
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 elasticsearc...@googlegroups.com <javascript:>.
For more options, visit https://groups.google.com/groups/opt_out.
I am setting up a new environment with Elasticsearch, and the out of
the box zen discovery makes it real easy to load balance.
But if I want to set up my environment like the following.
Three servers running on the same network, works perfectly and they
find each other.
es1 10.2.88.21
es2 10.2.88.22
es3 10.2.88.23
But then, from my web application I want to access the cluster via ip
10.2.88.24, which is a virtual ip so that if one node goes down, it does
not matter since I always access 10.2.88.24 and it contains all three of
them.
Is my intentions clear? How would i configure Elasticsearch for this
purpose?
If you use a cname the port doesn't matter. If a node goes down the the
connection will timeout, and your app should be able to gracefully handle
this and retry a connection which should connect to a different node. If
you keep the TTL for the cname down low (eg a minute), then you can easily
work around any extended downtime for a node by updating the record.
Using VIPs is good, but if you want something basic this might be the
easiest.
However a thought occurs that if you are using Windows, specifically server
2008, then you might be able to leverage Windows Clustering and have a VIP
and then point a cname to that. Windows Clustering is pretty easy too
I am setting up a new environment with Elasticsearch, and the out of
the box zen discovery makes it real easy to load balance.
But if I want to set up my environment like the following.
Three servers running on the same network, works perfectly and they
find each other.
es1 10.2.88.21
es2 10.2.88.22
es3 10.2.88.23
But then, from my web application I want to access the cluster via
ip 10.2.88.24, which is a virtual ip so that if one node goes down, it does
not matter since I always access 10.2.88.24 and it contains all three of
them.
Is my intentions clear? How would i configure Elasticsearch for this
purpose?
I would only suggest that the VIP is not used at all by Elasticsearch
itself (I.e. TCP/9300) only use it to expose the cluster to external
entities.
I can imagine ES may get v confused if a node which was on one IP appeared
on another one without disconnecting from the cluster first... But maybe it
doesn't care?
BTW, why route all your requests through 1 IP only?
On 29/07/2013 6:51 PM, "Mark Walkom" markw@campaignmonitor.com wrote:
If you use a cname the port doesn't matter. If a node goes down the the
connection will timeout, and your app should be able to gracefully handle
this and retry a connection which should connect to a different node. If
you keep the TTL for the cname down low (eg a minute), then you can easily
work around any extended downtime for a node by updating the record.
Using VIPs is good, but if you want something basic this might be the
easiest.
However a thought occurs that if you are using Windows, specifically
server 2008, then you might be able to leverage Windows Clustering and have
a VIP and then point a cname to that. Windows Clustering is pretty easy too
I am setting up a new environment with Elasticsearch, and the out
of the box zen discovery makes it real easy to load balance.
But if I want to set up my environment like the following.
Three servers running on the same network, works perfectly and they
find each other.
es1 10.2.88.21
es2 10.2.88.22
es3 10.2.88.23
But then, from my web application I want to access the cluster via
ip 10.2.88.24, which is a virtual ip so that if one node goes down, it does
not matter since I always access 10.2.88.24 and it contains all three of
them.
Is my intentions clear? How would i configure Elasticsearch for
this purpose?
//Tommy
--
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 elasticsearc...@googlegroups.com.
For more options, visit https://groups.google.com/**grou**
ps/opt_out https://groups.google.com/groups/opt_out.
In that case, take nginx, and put it up in load balancing mode like
described here, with a short fail timeout
DNS round robin is not recommended, unless you accept downtimes for many
minutes. You can't control the TTL how it propagates through all the DNS
services when a server goes down.
Do not expect high performance and scalability with Windows.
fwiw, our usual setup is
[ a pair of LBs using haproxy - http checks if using http, or simple tcp
if relying on thrift] --> [ a number n of instances running in master-only
mode, data= false ,effectively master + routing only] --> [ a number m of
data nodes].
Linux on EC2.
( got to play a bit with using specific http queries to get an http ok/
error from ES ,when using thrift ).
DNS round robin is not recommended, unless you accept downtimes for many
minutes. You can't control the TTL how it propagates through all the DNS
services when a server goes down.
Do not expect high performance and scalability with Windows.
DNS round robin is not recommended, unless you accept downtimes for many
minutes. You can't control the TTL how it propagates through all the DNS
services when a server goes down.
Do not expect high performance and scalability with Windows.
nginx is preferable if you want also request / response filtering, static
file serving, authentication, compression, logging, traffic shaping, http
flooding prevention, awesome concurrency. In combination with ucarp on a
local network, I set up nginx's in a row of machines, avoiding any SPOF
(within a data center) with failover of 1 second, no matter if there is a
Java EE JVM, or Perl/Python/Ruby/PHP processes connected to ES in the back
yard.
nginx is preferable if you want also request / response filtering, static
file serving, authentication, compression, logging, traffic shaping, http
flooding prevention, awesome concurrency. In combination with ucarp on a
local network, I set up nginx's in a row of machines, avoiding any SPOF
(within a data center) with failover of 1 second, no matter if there is a
Java EE JVM, or Perl/Python/Ruby/PHP processes connected to ES in the back
yard.
nginx is preferable if you want also request / response filtering, static
file serving, authentication, compression, logging, traffic shaping, http
flooding prevention, awesome concurrency. In combination with ucarp on a
local network, I set up nginx's in a row of machines, avoiding any SPOF
(within a data center) with failover of 1 second, no matter if there is a
Java EE JVM, or Perl/Python/Ruby/PHP processes connected to ES in the back
yard.
Why route everythin to 1 ip only, that is because i don't want to target a
specific node because what happens if that ones goes down.
Ofcourse I can build this into my application to try different ip addresses
if one does not answer but setting up a VIP pointing containing all the
node ips does seem like a good idea, doesn't it?
Den måndagen den 29:e juli 2013 kl. 10:55:47 UTC+2 skrev Norberto Meijome:
I would only suggest that the VIP is not used at all by Elasticsearch
itself (I.e. TCP/9300) only use it to expose the cluster to external
entities.
I can imagine ES may get v confused if a node which was on one IP appeared
on another one without disconnecting from the cluster first... But maybe it
doesn't care?
BTW, why route all your requests through 1 IP only?
On 29/07/2013 6:51 PM, "Mark Walkom" <ma...@campaignmonitor.com<javascript:>>
wrote:
If you use a cname the port doesn't matter. If a node goes down the the
connection will timeout, and your app should be able to gracefully handle
this and retry a connection which should connect to a different node. If
you keep the TTL for the cname down low (eg a minute), then you can easily
work around any extended downtime for a node by updating the record.
Using VIPs is good, but if you want something basic this might be the
easiest.
However a thought occurs that if you are using Windows, specifically
server 2008, then you might be able to leverage Windows Clustering and have
a VIP and then point a cname to that. Windows Clustering is pretty easy too
I am setting up a new environment with Elasticsearch, and the out
of the box zen discovery makes it real easy to load balance.
But if I want to set up my environment like the following.
Three servers running on the same network, works perfectly and
they find each other.
es1 10.2.88.21
es2 10.2.88.22
es3 10.2.88.23
But then, from my web application I want to access the cluster via
ip 10.2.88.24, which is a virtual ip so that if one node goes down, it does
not matter since I always access 10.2.88.24 and it contains all three of
them.
Is my intentions clear? How would i configure Elasticsearch for
this purpose?
//Tommy
--
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 elasticsearc...@googlegroups.com.
For more options, visit https://groups.google.com/**grou**
ps/opt_out 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 elasticsearc...@googlegroups.com <javascript:>.
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 elasticsearc...@googlegroups.com <javascript:>.
For more options, visit https://groups.google.com/groups/opt_out.
Why route everythin to 1 ip only, that is because i don't want to target a
specific node because what happens if that ones goes down.
Ofcourse I can build this into my application to try different ip
addresses if one does not answer but setting up a VIP pointing containing
all the node ips does seem like a good idea, doesn't it?
Den måndagen den 29:e juli 2013 kl. 10:55:47 UTC+2 skrev Norberto Meijome:
I would only suggest that the VIP is not used at all by Elasticsearch
itself (I.e. TCP/9300) only use it to expose the cluster to external
entities.
I can imagine ES may get v confused if a node which was on one IP
appeared on another one without disconnecting from the cluster first... But
maybe it doesn't care?
BTW, why route all your requests through 1 IP only?
On 29/07/2013 6:51 PM, "Mark Walkom" ma...@campaignmonitor.com wrote:
If you use a cname the port doesn't matter. If a node goes down the the
connection will timeout, and your app should be able to gracefully handle
this and retry a connection which should connect to a different node. If
you keep the TTL for the cname down low (eg a minute), then you can easily
work around any extended downtime for a node by updating the record.
Using VIPs is good, but if you want something basic this might be the
easiest.
However a thought occurs that if you are using Windows, specifically
server 2008, then you might be able to leverage Windows Clustering and have
a VIP and then point a cname to that. Windows Clustering is pretty easy too
I am setting up a new environment with Elasticsearch, and the out
of the box zen discovery makes it real easy to load balance.
But if I want to set up my environment like the following.
Three servers running on the same network, works perfectly and
they find each other.
es1 10.2.88.21
es2 10.2.88.22
es3 10.2.88.23
But then, from my web application I want to access the cluster
via ip 10.2.88.24, which is a virtual ip so that if one node goes down, it
does not matter since I always access 10.2.88.24 and it contains all three
of them.
Is my intentions clear? How would i configure Elasticsearch for
this purpose?
//Tommy
--
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 elasticsearc...@googlegroups.**com.
For more options, visit https://groups.google.com/**grou
ps/opt_out https://groups.google.com/groups/opt_out.
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.