About Node Discovery and Clients (newbie question)

I have an ES cluster divided into 6 servers at 172.16.146.xxx and
172.16.147.xxx with no multicast discovery enabled:

discovery.zen.multicast.enabled: false

but with two gossip servers, one from each ip range, configured as the
unicast hosts list, so the cluster is discovered and formed ok.

discovery.zen.ping.unicast.hosts: ["172.16.146.1", "172.16.147.1"].

Does this configuration (no multicast and only two unicast hosts) make
sense? What would happen if one of these fails?

At the same time I've created a client to index/search data in a ES
cluster, based on configuration it initiates a Node or a Transport
client, with a list of hosts also configured for the latter.

Hosting the client in 172.16.137.156, if I start a Node client, with
the cluster name correctly set, it can't discover the cluster
(MasterNotDiscoveredException), but using the Transport one, with the
list of hosts explicitly declared, it works ok, as expected.

So, how the Node client would find the master if no multicast nor list
of hosts was explicitly defined?

Thanks for your great support,

How did you configure the node client? It uses the same discovery as the
other nodes in the cluster. You need to configure it with the same settings
as the non client nodes for discovery.

On Wed, Sep 14, 2011 at 10:38 PM, Frederic focampo.br@gmail.com wrote:

I have an ES cluster divided into 6 servers at 172.16.146.xxx and
172.16.147.xxx with no multicast discovery enabled:

discovery.zen.multicast.enabled: false

but with two gossip servers, one from each ip range, configured as the
unicast hosts list, so the cluster is discovered and formed ok.

discovery.zen.ping.unicast.hosts: ["172.16.146.1", "172.16.147.1"].

Does this configuration (no multicast and only two unicast hosts) make
sense? What would happen if one of these fails?

At the same time I've created a client to index/search data in a ES
cluster, based on configuration it initiates a Node or a Transport
client, with a list of hosts also configured for the latter.

Hosting the client in 172.16.137.156, if I start a Node client, with
the cluster name correctly set, it can't discover the cluster
(MasterNotDiscoveredException), but using the Transport one, with the
list of hosts explicitly declared, it works ok, as expected.

So, how the Node client would find the master if no multicast nor list
of hosts was explicitly defined?

Thanks for your great support,

Oh, yes that makes sense. I just configured the cluster name for the
node client following the Java API client page, but forgot to set the
other cluster settings.

One last one, in which scenarios would you recommend to configure
cluster discovery using unicast over multicast? (thinking on server
failures, new added nodes, etc)

Thanks,

On 15 sep, 06:48, Shay Banon kim...@gmail.com wrote:

How did you configure the node client? It uses the same discovery as the
other nodes in the cluster. You need to configure it with the same settings
as the non client nodes for discovery.

On Wed, Sep 14, 2011 at 10:38 PM, Frederic focampo...@gmail.com wrote:

I have an ES cluster divided into 6 servers at 172.16.146.xxx and
172.16.147.xxx with no multicast discovery enabled:

discovery.zen.multicast.enabled: false

but with two gossip servers, one from each ip range, configured as the
unicast hosts list, so the cluster is discovered and formed ok.

discovery.zen.ping.unicast.hosts: ["172.16.146.1", "172.16.147.1"].

Does this configuration (no multicast and only two unicast hosts) make
sense? What would happen if one of these fails?

At the same time I've created a client to index/search data in a ES
cluster, based on configuration it initiates a Node or a Transport
client, with a list of hosts also configured for the latter.

Hosting the client in 172.16.137.156, if I start a Node client, with
the cluster name correctly set, it can't discover the cluster
(MasterNotDiscoveredException), but using the Transport one, with the
list of hosts explicitly declared, it works ok, as expected.

So, how the Node client would find the master if no multicast nor list
of hosts was explicitly defined?

Thanks for your great support,

Unicast allows for simpler fine grained control over what talks to what.
Multicast allows for that as well, but you need to configure different
multicast IPs / ports. Both are good.

On Thu, Sep 15, 2011 at 4:50 PM, Frederic focampo.br@gmail.com wrote:

Oh, yes that makes sense. I just configured the cluster name for the
node client following the Java API client page, but forgot to set the
other cluster settings.

One last one, in which scenarios would you recommend to configure
cluster discovery using unicast over multicast? (thinking on server
failures, new added nodes, etc)

Thanks,

On 15 sep, 06:48, Shay Banon kim...@gmail.com wrote:

How did you configure the node client? It uses the same discovery as the
other nodes in the cluster. You need to configure it with the same
settings
as the non client nodes for discovery.

On Wed, Sep 14, 2011 at 10:38 PM, Frederic focampo...@gmail.com wrote:

I have an ES cluster divided into 6 servers at 172.16.146.xxx and
172.16.147.xxx with no multicast discovery enabled:

discovery.zen.multicast.enabled: false

but with two gossip servers, one from each ip range, configured as the
unicast hosts list, so the cluster is discovered and formed ok.

discovery.zen.ping.unicast.hosts: ["172.16.146.1", "172.16.147.1"].

Does this configuration (no multicast and only two unicast hosts) make
sense? What would happen if one of these fails?

At the same time I've created a client to index/search data in a ES
cluster, based on configuration it initiates a Node or a Transport
client, with a list of hosts also configured for the latter.

Hosting the client in 172.16.137.156, if I start a Node client, with
the cluster name correctly set, it can't discover the cluster
(MasterNotDiscoveredException), but using the Transport one, with the
list of hosts explicitly declared, it works ok, as expected.

So, how the Node client would find the master if no multicast nor list
of hosts was explicitly defined?

Thanks for your great support,