Zookeeper Discovery SPI & external IP address in AWS

[irudyak]

Hi guys,

How to force *TcpDiscoveryZookeeperIpFinder* to publish public IP address
(in addition to private IP) of Ignite node when it's deployed in Amazon?

By default it just publishing private IP addresses of nodes which makes it
impossible to connect to cluster from outside using *Zookeeper Discovery
SPI*.

I tried to use something like this (see below) for *discoverySPI*:

<property name="discoverySpi">
<bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
<property name="addressResolver">
<bean class="org.apache.ignite.configuration.BasicAddressResolver">
<constructor-arg>
<map>
<entry key="<node-private-ip>" value="<node-public-ip>"/>
</map>
</constructor-arg>
</bean>
</property>
<property name="ipFinder">
<bean
class="org.apache.ignite.spi.discovery.tcp.ipfinder.zk.TcpDiscoveryZookeeperIpFinder">
<property name="zkConnectionString" value="<zookeeper-ip>:2181"/>
</bean>
</property>
</bean>
</property>

But such way it only publish public IPs to Zookeeper.

Actually I am looking for something like *advertised.host.name
<http://advertised.host.name>* analog in Kafka. Which allows to publish
private and public IP addresses for a node to Zookeeper.

Such way all internal services communicates through private IPs, but
external services communicates using public IPs.

Igor

[Valentin Kulichenko]

Igor,

What version are you going on? I believe we already fixed this in the past.

-Val

On Wed, Jun 21, 2017 at 2:30 AM Igor Rudyak <[hidden email]> wrote:

> Hi guys,
>
> How to force *TcpDiscoveryZookeeperIpFinder* to publish public IP address
> (in addition to private IP) of Ignite node when it's deployed in Amazon?
>
> By default it just publishing private IP addresses of nodes which makes it
> impossible to connect to cluster from outside using *Zookeeper Discovery
> SPI*.
>
> I tried to use something like this (see below) for *discoverySPI*:
>
> <property name="discoverySpi">
> <bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
> <property name="addressResolver">
> <bean class="org.apache.ignite.configuration.BasicAddressResolver">
> <constructor-arg>
> <map>
> <entry key="<node-private-ip>" value="<node-public-ip>"/>
> </map>
> </constructor-arg>
> </bean>
> </property>
> <property name="ipFinder">
> <bean
>
> class="org.apache.ignite.spi.discovery.tcp.ipfinder.zk.TcpDiscoveryZookeeperIpFinder">
> <property name="zkConnectionString" value="<zookeeper-ip>:2181"/>
> </bean>
> </property>
> </bean>
> </property>
>
> But such way it only publish public IPs to Zookeeper.
>
> Actually I am looking for something like *advertised.host.name
> <http://advertised.host.name>* analog in Kafka. Which allows to publish
> private and public IP addresses for a node to Zookeeper.
>
> Such way all internal services communicates through private IPs, but
> external services communicates using public IPs.
>
> Igor
>

[irudyak]

Hi Val,

I am using version 2.0.0.

Igor

On Jun 21, 2017 5:50 AM, "Valentin Kulichenko" <
[hidden email]> wrote:

> Igor,
>
> What version are you going on? I believe we already fixed this in the past.
>
> -Val
>
> On Wed, Jun 21, 2017 at 2:30 AM Igor Rudyak <[hidden email]> wrote:
>
> > Hi guys,
> >
> > How to force *TcpDiscoveryZookeeperIpFinder* to publish public IP
> address
> > (in addition to private IP) of Ignite node when it's deployed in Amazon?
> >
> > By default it just publishing private IP addresses of nodes which makes
> it
> > impossible to connect to cluster from outside using *Zookeeper Discovery
> > SPI*.
> >
> > I tried to use something like this (see below) for *discoverySPI*:
> >
> > <property name="discoverySpi">
> > <bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
> > <property name="addressResolver">
> > <bean class="org.apache.ignite.configuration.BasicAddressResolver">
> > <constructor-arg>
> > <map>
> > <entry key="<node-private-ip>" value="<node-public-ip>"/>
> > </map>
> > </constructor-arg>
> > </bean>
> > </property>
> > <property name="ipFinder">
> > <bean
> >
> > class="org.apache.ignite.spi.discovery.tcp.ipfinder.zk.
> TcpDiscoveryZookeeperIpFinder">
> > <property name="zkConnectionString" value="<zookeeper-ip>:2181"/>
> > </bean>
> > </property>
> > </bean>
> > </property>
> >
> > But such way it only publish public IPs to Zookeeper.
> >
> > Actually I am looking for something like *advertised.host.name
> > <http://advertised.host.name>* analog in Kafka. Which allows to publish
> > private and public IP addresses for a node to Zookeeper.
> >
> > Such way all internal services communicates through private IPs, but
> > external services communicates using public IPs.
> >
> > Igor
> >
>

[irudyak]

Val,

Are there any ticket for this in Jira?

Igor

On Jun 21, 2017 5:50 AM, "Valentin Kulichenko" <
[hidden email]> wrote:

> Igor,
>
> What version are you going on? I believe we already fixed this in the past.
>
> -Val
>
> On Wed, Jun 21, 2017 at 2:30 AM Igor Rudyak <[hidden email]> wrote:
>
> > Hi guys,
> >
> > How to force *TcpDiscoveryZookeeperIpFinder* to publish public IP
> address
> > (in addition to private IP) of Ignite node when it's deployed in Amazon?
> >
> > By default it just publishing private IP addresses of nodes which makes
> it
> > impossible to connect to cluster from outside using *Zookeeper Discovery
> > SPI*.
> >
> > I tried to use something like this (see below) for *discoverySPI*:
> >
> > <property name="discoverySpi">
> > <bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
> > <property name="addressResolver">
> > <bean class="org.apache.ignite.configuration.BasicAddressResolver">
> > <constructor-arg>
> > <map>
> > <entry key="<node-private-ip>" value="<node-public-ip>"/>
> > </map>
> > </constructor-arg>
> > </bean>
> > </property>
> > <property name="ipFinder">
> > <bean
> >
> > class="org.apache.ignite.spi.discovery.tcp.ipfinder.zk.
> TcpDiscoveryZookeeperIpFinder">
> > <property name="zkConnectionString" value="<zookeeper-ip>:2181"/>
> > </bean>
> > </property>
> > </bean>
> > </property>
> >
> > But such way it only publish public IPs to Zookeeper.
> >
> > Actually I am looking for something like *advertised.host.name
> > <http://advertised.host.name>* analog in Kafka. Which allows to publish
> > private and public IP addresses for a node to Zookeeper.
> >
> > Such way all internal services communicates through private IPs, but
> > external services communicates using public IPs.
> >
> > Igor
> >
>

[Valentin Kulichenko]

Igor,

Here is the ticket I'm talking about:
https://issues.apache.org/jira/browse/IGNITE-3230

-Val

On Wed, Jun 21, 2017 at 8:57 AM, Igor Rudyak <[hidden email]> wrote:

> Val,
>
> Are there any ticket for this in Jira?
>
> Igor
>
> On Jun 21, 2017 5:50 AM, "Valentin Kulichenko" <
> [hidden email]> wrote:
>
> > Igor,
> >
> > What version are you going on? I believe we already fixed this in the
> past.
> >
> > -Val
> >
> > On Wed, Jun 21, 2017 at 2:30 AM Igor Rudyak <[hidden email]> wrote:
> >
> > > Hi guys,
> > >
> > > How to force *TcpDiscoveryZookeeperIpFinder* to publish public IP
> > address
> > > (in addition to private IP) of Ignite node when it's deployed in
> Amazon?
> > >
> > > By default it just publishing private IP addresses of nodes which makes
> > it
> > > impossible to connect to cluster from outside using *Zookeeper
> Discovery
> > > SPI*.
> > >
> > > I tried to use something like this (see below) for *discoverySPI*:
> > >
> > > <property name="discoverySpi">
> > > <bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
> > > <property name="addressResolver">
> > > <bean class="org.apache.ignite.configuration.BasicAddressResolver">
> > > <constructor-arg>
> > > <map>
> > > <entry key="<node-private-ip>" value="<node-public-ip>"/>
> > > </map>
> > > </constructor-arg>
> > > </bean>
> > > </property>
> > > <property name="ipFinder">
> > > <bean
> > >
> > > class="org.apache.ignite.spi.discovery.tcp.ipfinder.zk.
> > TcpDiscoveryZookeeperIpFinder">
> > > <property name="zkConnectionString" value="<zookeeper-ip>:2181"/>
> > > </bean>
> > > </property>
> > > </bean>
> > > </property>
> > >
> > > But such way it only publish public IPs to Zookeeper.
> > >
> > > Actually I am looking for something like *advertised.host.name
> > > <http://advertised.host.name>* analog in Kafka. Which allows to
> publish
> > > private and public IP addresses for a node to Zookeeper.
> > >
> > > Such way all internal services communicates through private IPs, but
> > > external services communicates using public IPs.
> > >
> > > Igor
> > >
> >
>

[irudyak]

Thanks Val,

It looks like there is still this problem in version 2.0.0

Igor

On Wed, Jun 21, 2017 at 3:20 PM, Valentin Kulichenko <
[hidden email]> wrote:

> Igor,
>
> Here is the ticket I'm talking about:
> https://issues.apache.org/jira/browse/IGNITE-3230
>
> -Val
>
> On Wed, Jun 21, 2017 at 8:57 AM, Igor Rudyak <[hidden email]> wrote:
>
> > Val,
> >
> > Are there any ticket for this in Jira?
> >
> > Igor
> >
> > On Jun 21, 2017 5:50 AM, "Valentin Kulichenko" <
> > [hidden email]> wrote:
> >
> > > Igor,
> > >
> > > What version are you going on? I believe we already fixed this in the
> > past.
> > >
> > > -Val
> > >
> > > On Wed, Jun 21, 2017 at 2:30 AM Igor Rudyak <[hidden email]> wrote:
> > >
> > > > Hi guys,
> > > >
> > > > How to force *TcpDiscoveryZookeeperIpFinder* to publish public IP
> > > address
> > > > (in addition to private IP) of Ignite node when it's deployed in
> > Amazon?
> > > >
> > > > By default it just publishing private IP addresses of nodes which
> makes
> > > it
> > > > impossible to connect to cluster from outside using *Zookeeper
> > Discovery
> > > > SPI*.
> > > >
> > > > I tried to use something like this (see below) for *discoverySPI*:
> > > >
> > > > <property name="discoverySpi">
> > > > <bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
> > > > <property name="addressResolver">
> > > > <bean class="org.apache.ignite.configuration.BasicAddressResolver">
> > > > <constructor-arg>
> > > > <map>
> > > > <entry key="<node-private-ip>" value="<node-public-ip>"/>
> > > > </map>
> > > > </constructor-arg>
> > > > </bean>
> > > > </property>
> > > > <property name="ipFinder">
> > > > <bean
> > > >
> > > > class="org.apache.ignite.spi.discovery.tcp.ipfinder.zk.
> > > TcpDiscoveryZookeeperIpFinder">
> > > > <property name="zkConnectionString" value="<zookeeper-ip>:2181"/>
> > > > </bean>
> > > > </property>
> > > > </bean>
> > > > </property>
> > > >
> > > > But such way it only publish public IPs to Zookeeper.
> > > >
> > > > Actually I am looking for something like *advertised.host.name
> > > > <http://advertised.host.name>* analog in Kafka. Which allows to
> > publish
> > > > private and public IP addresses for a node to Zookeeper.
> > > >
> > > > Such way all internal services communicates through private IPs, but
> > > > external services communicates using public IPs.
> > > >
> > > > Igor
> > > >
> > >
> >
>

[Valentin Kulichenko]

Anton, Nikolay,

Looks like you participated in the fix. Can you please check?

-Val

On Wed, Jun 21, 2017 at 7:01 PM Igor Rudyak <[hidden email]> wrote:

> Thanks Val,
>
> It looks like there is still this problem in version 2.0.0
>
> Igor
>
> On Wed, Jun 21, 2017 at 3:20 PM, Valentin Kulichenko <
> [hidden email]> wrote:
>
> > Igor,
> >
> > Here is the ticket I'm talking about:
> > https://issues.apache.org/jira/browse/IGNITE-3230
> >
> > -Val
> >
> > On Wed, Jun 21, 2017 at 8:57 AM, Igor Rudyak <[hidden email]> wrote:
> >
> > > Val,
> > >
> > > Are there any ticket for this in Jira?
> > >
> > > Igor
> > >
> > > On Jun 21, 2017 5:50 AM, "Valentin Kulichenko" <
> > > [hidden email]> wrote:
> > >
> > > > Igor,
> > > >
> > > > What version are you going on? I believe we already fixed this in the
> > > past.
> > > >
> > > > -Val
> > > >
> > > > On Wed, Jun 21, 2017 at 2:30 AM Igor Rudyak <[hidden email]>
> wrote:
> > > >
> > > > > Hi guys,
> > > > >
> > > > > How to force *TcpDiscoveryZookeeperIpFinder* to publish public IP
> > > > address
> > > > > (in addition to private IP) of Ignite node when it's deployed in
> > > Amazon?
> > > > >
> > > > > By default it just publishing private IP addresses of nodes which
> > makes
> > > > it
> > > > > impossible to connect to cluster from outside using *Zookeeper
> > > Discovery
> > > > > SPI*.
> > > > >
> > > > > I tried to use something like this (see below) for *discoverySPI*:
> > > > >
> > > > > <property name="discoverySpi">
> > > > > <bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
> > > > > <property name="addressResolver">
> > > > > <bean class="org.apache.ignite.configuration.BasicAddressResolver">
> > > > > <constructor-arg>
> > > > > <map>
> > > > > <entry key="<node-private-ip>" value="<node-public-ip>"/>
> > > > > </map>
> > > > > </constructor-arg>
> > > > > </bean>
> > > > > </property>
> > > > > <property name="ipFinder">
> > > > > <bean
> > > > >
> > > > > class="org.apache.ignite.spi.discovery.tcp.ipfinder.zk.
> > > > TcpDiscoveryZookeeperIpFinder">
> > > > > <property name="zkConnectionString" value="<zookeeper-ip>:2181"/>
> > > > > </bean>
> > > > > </property>
> > > > > </bean>
> > > > > </property>
> > > > >
> > > > > But such way it only publish public IPs to Zookeeper.
> > > > >
> > > > > Actually I am looking for something like *advertised.host.name
> > > > > <http://advertised.host.name>* analog in Kafka. Which allows to
> > > publish
> > > > > private and public IP addresses for a node to Zookeeper.
> > > > >
> > > > > Such way all internal services communicates through private IPs,
> but
> > > > > external services communicates using public IPs.
> > > > >
> > > > > Igor
> > > > >
> > > >
> > >
> >
>

[yzhdanov]

Guys, I don't get the point.

1. Why addresses processed by address resolver should appear in shared
finder? In my understanding finders contain only internal IPs which should
be processed by a resolver.

2. This one is very critical. Nikolay and Anton, how can I review the
changes?! Please update the ticket with PR or commit hash.

--Yakov

[Valentin Kulichenko]

Yakov,

Nodes that join outside of the network (usually these are clients) need to
know public addresses to connect. To make it work either of these must
happen:

1. Server nodes publish their public addresses in IP finder so that clients
can use them to connect.
2. Client nodes use address resolver to map published internal addresses to
public addresses.

Both will work, but frankly I like option 1 more. First of all, it's just
more intuitive that IP finder contains all possible addresses that can be
used to join. Second of all, option 2 introduces requirement to have
address resolver for server addresses configured on client nodes - this is
not very good from usability standpoint.

-Val

On Mon, Jun 26, 2017 at 3:17 AM, Yakov Zhdanov <[hidden email]> wrote:

> Guys, I don't get the point.
>
> 1. Why addresses processed by address resolver should appear in shared
> finder? In my understanding finders contain only internal IPs which should
> be processed by a resolver.
>
> 2. This one is very critical. Nikolay and Anton, how can I review the
> changes?! Please update the ticket with PR or commit hash.
>
> --Yakov
>

[irudyak]

Option 2 also will not work for IaaS environments, where node can
dynamically join or leave cluster.

Igor

On Jun 26, 2017 12:12 PM, "Valentin Kulichenko" <
[hidden email]> wrote:

> Yakov,
>
> Nodes that join outside of the network (usually these are clients) need to
> know public addresses to connect. To make it work either of these must
> happen:
>
> 1. Server nodes publish their public addresses in IP finder so that clients
> can use them to connect.
> 2. Client nodes use address resolver to map published internal addresses to
> public addresses.
>
> Both will work, but frankly I like option 1 more. First of all, it's just
> more intuitive that IP finder contains all possible addresses that can be
> used to join. Second of all, option 2 introduces requirement to have
> address resolver for server addresses configured on client nodes - this is
> not very good from usability standpoint.
>
> -Val
>
> On Mon, Jun 26, 2017 at 3:17 AM, Yakov Zhdanov <[hidden email]>
> wrote:
>
> > Guys, I don't get the point.
> >
> > 1. Why addresses processed by address resolver should appear in shared
> > finder? In my understanding finders contain only internal IPs which
> should
> > be processed by a resolver.
> >
> > 2. This one is very critical. Nikolay and Anton, how can I review the
> > changes?! Please update the ticket with PR or commit hash.
> >
> > --Yakov
> >
>

[Valentin Kulichenko]

Igor,

It depends on how address resolver works. But I agree, in general case it's
possible that a node can only resolve public address for itself. In such
scenario we must publish public addresses in IP finder.

-Val

On Mon, Jun 26, 2017 at 1:02 PM, Igor Rudyak <[hidden email]> wrote:

> Option 2 also will not work for IaaS environments, where node can
> dynamically join or leave cluster.
>
> Igor
>
> On Jun 26, 2017 12:12 PM, "Valentin Kulichenko" <
> [hidden email]> wrote:
>
> > Yakov,
> >
> > Nodes that join outside of the network (usually these are clients) need
> to
> > know public addresses to connect. To make it work either of these must
> > happen:
> >
> > 1. Server nodes publish their public addresses in IP finder so that
> clients
> > can use them to connect.
> > 2. Client nodes use address resolver to map published internal addresses
> to
> > public addresses.
> >
> > Both will work, but frankly I like option 1 more. First of all, it's just
> > more intuitive that IP finder contains all possible addresses that can be
> > used to join. Second of all, option 2 introduces requirement to have
> > address resolver for server addresses configured on client nodes - this
> is
> > not very good from usability standpoint.
> >
> > -Val
> >
> > On Mon, Jun 26, 2017 at 3:17 AM, Yakov Zhdanov <[hidden email]>
> > wrote:
> >
> > > Guys, I don't get the point.
> > >
> > > 1. Why addresses processed by address resolver should appear in shared
> > > finder? In my understanding finders contain only internal IPs which
> > should
> > > be processed by a resolver.
> > >
> > > 2. This one is very critical. Nikolay and Anton, how can I review the
> > > changes?! Please update the ticket with PR or commit hash.
> > >
> > > --Yakov
> > >
> >
>

[irudyak]

Val,

Regarding resolver it makes sense.

Actually as of now, Option 2 doesn't work to connect Ignite clients to
cluster using private-to-public IPs mapping. It just falls into infinite
connection loop and periodically reports something like this:

*[14:42:15] Failed to connect to any address from IP finder (will retry to
join topology every 2 secs): [/0:0:0:0:0:0:0:1%1:47500, /127.0.0.1:47500
<http://127.0.0.1:47500>, /<server-1-private-ip>:47500,
/<server-2-private-ip>:47500, /<server-3-private-ip>:47500]*

Even if I manually specify all public IPs for discovery, like this:

*<bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">*
* <property name="ipFinder">*
* <bean
class="org.apache.ignite.spi.discovery.tcp.ipfinder.multicast.TcpDiscoveryMulticastIpFinder">*
* <property name="addresses">*
* <list>*
* <value><server-1-public-ip></value>*
* <value><server-2-public-ip></value>*
* <value><server-3-public-ip></value>*
* </list>*
* </property>*
* </bean>*
* </property>*
*</bean>*

It still can't connect to cluster and just periodically reports the same
error.

Does actually cluster membership protocol support the case when node
available through multiple IP addresses and treats <ip-address-1>,
<ip-address-2> and etc. as just different IPs corresponding to the same
node?


Igor

On Mon, Jun 26, 2017 at 1:55 PM, Valentin Kulichenko <
[hidden email]> wrote:

> Igor,
>
> It depends on how address resolver works. But I agree, in general case it's
> possible that a node can only resolve public address for itself. In such
> scenario we must publish public addresses in IP finder.
>
> -Val
>
> On Mon, Jun 26, 2017 at 1:02 PM, Igor Rudyak <[hidden email]> wrote:
>
> > Option 2 also will not work for IaaS environments, where node can
> > dynamically join or leave cluster.
> >
> > Igor
> >
> > On Jun 26, 2017 12:12 PM, "Valentin Kulichenko" <
> > [hidden email]> wrote:
> >
> > > Yakov,
> > >
> > > Nodes that join outside of the network (usually these are clients) need
> > to
> > > know public addresses to connect. To make it work either of these must
> > > happen:
> > >
> > > 1. Server nodes publish their public addresses in IP finder so that
> > clients
> > > can use them to connect.
> > > 2. Client nodes use address resolver to map published internal
> addresses
> > to
> > > public addresses.
> > >
> > > Both will work, but frankly I like option 1 more. First of all, it's
> just
> > > more intuitive that IP finder contains all possible addresses that can
> be
> > > used to join. Second of all, option 2 introduces requirement to have
> > > address resolver for server addresses configured on client nodes - this
> > is
> > > not very good from usability standpoint.
> > >
> > > -Val
> > >
> > > On Mon, Jun 26, 2017 at 3:17 AM, Yakov Zhdanov <[hidden email]>
> > > wrote:
> > >
> > > > Guys, I don't get the point.
> > > >
> > > > 1. Why addresses processed by address resolver should appear in
> shared
> > > > finder? In my understanding finders contain only internal IPs which
> > > should
> > > > be processed by a resolver.
> > > >
> > > > 2. This one is very critical. Nikolay and Anton, how can I review the
> > > > changes?! Please update the ticket with PR or commit hash.
> > > >
> > > > --Yakov
> > > >
> > >
> >
>

[Valentin Kulichenko]

Igor,

Are you sure these connections are not blocked by firewall? If you provide
addresses explicitly in static IP finder, then it doesn't matter what is
published in shared IP finder. Is it possible that public addresses are
actually published and connectivity issue is caused by something else?

-Val

On Mon, Jun 26, 2017 at 3:01 PM, Igor Rudyak <[hidden email]> wrote:

> Val,
>
> Regarding resolver it makes sense.
>
> Actually as of now, Option 2 doesn't work to connect Ignite clients to
> cluster using private-to-public IPs mapping. It just falls into infinite
> connection loop and periodically reports something like this:
>
> *[14:42:15] Failed to connect to any address from IP finder (will retry to
> join topology every 2 secs): [/0:0:0:0:0:0:0:1%1:47500, /127.0.0.1:47500
> <http://127.0.0.1:47500>, /<server-1-private-ip>:47500,
> /<server-2-private-ip>:47500, /<server-3-private-ip>:47500]*
>
> Even if I manually specify all public IPs for discovery, like this:
>
> *<bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">*
> * <property name="ipFinder">*
> * <bean
> class="org.apache.ignite.spi.discovery.tcp.ipfinder.multicast.
> TcpDiscoveryMulticastIpFinder">*
> * <property name="addresses">*
> * <list>*
> * <value><server-1-public-ip></value>*
> * <value><server-2-public-ip></value>*
> * <value><server-3-public-ip></value>*
> * </list>*
> * </property>*
> * </bean>*
> * </property>*
> *</bean>*
>
> It still can't connect to cluster and just periodically reports the same
> error.
>
> Does actually cluster membership protocol support the case when node
> available through multiple IP addresses and treats <ip-address-1>,
> <ip-address-2> and etc. as just different IPs corresponding to the same
> node?
>
>
> Igor
>
> On Mon, Jun 26, 2017 at 1:55 PM, Valentin Kulichenko <
> [hidden email]> wrote:
>
> > Igor,
> >
> > It depends on how address resolver works. But I agree, in general case
> it's
> > possible that a node can only resolve public address for itself. In such
> > scenario we must publish public addresses in IP finder.
> >
> > -Val
> >
> > On Mon, Jun 26, 2017 at 1:02 PM, Igor Rudyak <[hidden email]> wrote:
> >
> > > Option 2 also will not work for IaaS environments, where node can
> > > dynamically join or leave cluster.
> > >
> > > Igor
> > >
> > > On Jun 26, 2017 12:12 PM, "Valentin Kulichenko" <
> > > [hidden email]> wrote:
> > >
> > > > Yakov,
> > > >
> > > > Nodes that join outside of the network (usually these are clients)
> need
> > > to
> > > > know public addresses to connect. To make it work either of these
> must
> > > > happen:
> > > >
> > > > 1. Server nodes publish their public addresses in IP finder so that
> > > clients
> > > > can use them to connect.
> > > > 2. Client nodes use address resolver to map published internal
> > addresses
> > > to
> > > > public addresses.
> > > >
> > > > Both will work, but frankly I like option 1 more. First of all, it's
> > just
> > > > more intuitive that IP finder contains all possible addresses that
> can
> > be
> > > > used to join. Second of all, option 2 introduces requirement to have
> > > > address resolver for server addresses configured on client nodes -
> this
> > > is
> > > > not very good from usability standpoint.
> > > >
> > > > -Val
> > > >
> > > > On Mon, Jun 26, 2017 at 3:17 AM, Yakov Zhdanov <[hidden email]>
> > > > wrote:
> > > >
> > > > > Guys, I don't get the point.
> > > > >
> > > > > 1. Why addresses processed by address resolver should appear in
> > shared
> > > > > finder? In my understanding finders contain only internal IPs which
> > > > should
> > > > > be processed by a resolver.
> > > > >
> > > > > 2. This one is very critical. Nikolay and Anton, how can I review
> the
> > > > > changes?! Please update the ticket with PR or commit hash.
> > > > >
> > > > > --Yakov
> > > > >
> > > >
> > >
> >
>

[irudyak]

I am 100% sure, cause  "*telnet  <public-ip>  11211*"  works just perfect.

Igor

On Mon, Jun 26, 2017 at 3:32 PM, Valentin Kulichenko <
[hidden email]> wrote:

> Igor,
>
> Are you sure these connections are not blocked by firewall? If you provide
> addresses explicitly in static IP finder, then it doesn't matter what is
> published in shared IP finder. Is it possible that public addresses are
> actually published and connectivity issue is caused by something else?
>
> -Val
>
> On Mon, Jun 26, 2017 at 3:01 PM, Igor Rudyak <[hidden email]> wrote:
>
> > Val,
> >
> > Regarding resolver it makes sense.
> >
> > Actually as of now, Option 2 doesn't work to connect Ignite clients to
> > cluster using private-to-public IPs mapping. It just falls into infinite
> > connection loop and periodically reports something like this:
> >
> > *[14:42:15] Failed to connect to any address from IP finder (will retry
> to
> > join topology every 2 secs): [/0:0:0:0:0:0:0:1%1:47500, /127.0.0.1:47500
> > <http://127.0.0.1:47500>, /<server-1-private-ip>:47500,
> > /<server-2-private-ip>:47500, /<server-3-private-ip>:47500]*
> >
> > Even if I manually specify all public IPs for discovery, like this:
> >
> > *<bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">*
> > * <property name="ipFinder">*
> > * <bean
> > class="org.apache.ignite.spi.discovery.tcp.ipfinder.multicast.
> > TcpDiscoveryMulticastIpFinder">*
> > * <property name="addresses">*
> > * <list>*
> > * <value><server-1-public-ip></value>*
> > * <value><server-2-public-ip></value>*
> > * <value><server-3-public-ip></value>*
> > * </list>*
> > * </property>*
> > * </bean>*
> > * </property>*
> > *</bean>*
> >
> > It still can't connect to cluster and just periodically reports the same
> > error.
> >
> > Does actually cluster membership protocol support the case when node
> > available through multiple IP addresses and treats <ip-address-1>,
> > <ip-address-2> and etc. as just different IPs corresponding to the same
> > node?
> >
> >
> > Igor
> >
> > On Mon, Jun 26, 2017 at 1:55 PM, Valentin Kulichenko <
> > [hidden email]> wrote:
> >
> > > Igor,
> > >
> > > It depends on how address resolver works. But I agree, in general case
> > it's
> > > possible that a node can only resolve public address for itself. In
> such
> > > scenario we must publish public addresses in IP finder.
> > >
> > > -Val
> > >
> > > On Mon, Jun 26, 2017 at 1:02 PM, Igor Rudyak <[hidden email]>
> wrote:
> > >
> > > > Option 2 also will not work for IaaS environments, where node can
> > > > dynamically join or leave cluster.
> > > >
> > > > Igor
> > > >
> > > > On Jun 26, 2017 12:12 PM, "Valentin Kulichenko" <
> > > > [hidden email]> wrote:
> > > >
> > > > > Yakov,
> > > > >
> > > > > Nodes that join outside of the network (usually these are clients)
> > need
> > > > to
> > > > > know public addresses to connect. To make it work either of these
> > must
> > > > > happen:
> > > > >
> > > > > 1. Server nodes publish their public addresses in IP finder so that
> > > > clients
> > > > > can use them to connect.
> > > > > 2. Client nodes use address resolver to map published internal
> > > addresses
> > > > to
> > > > > public addresses.
> > > > >
> > > > > Both will work, but frankly I like option 1 more. First of all,
> it's
> > > just
> > > > > more intuitive that IP finder contains all possible addresses that
> > can
> > > be
> > > > > used to join. Second of all, option 2 introduces requirement to
> have
> > > > > address resolver for server addresses configured on client nodes -
> > this
> > > > is
> > > > > not very good from usability standpoint.
> > > > >
> > > > > -Val
> > > > >
> > > > > On Mon, Jun 26, 2017 at 3:17 AM, Yakov Zhdanov <
> [hidden email]>
> > > > > wrote:
> > > > >
> > > > > > Guys, I don't get the point.
> > > > > >
> > > > > > 1. Why addresses processed by address resolver should appear in
> > > shared
> > > > > > finder? In my understanding finders contain only internal IPs
> which
> > > > > should
> > > > > > be processed by a resolver.
> > > > > >
> > > > > > 2. This one is very critical. Nikolay and Anton, how can I review
> > the
> > > > > > changes?! Please update the ticket with PR or commit hash.
> > > > > >
> > > > > > --Yakov
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Valentin Kulichenko]

Igor,

You need to investigate deeper then. It's not obvious what's going on and
why there is an issue.

-Val

On Mon, Jun 26, 2017 at 3:36 PM, Igor Rudyak <[hidden email]> wrote:

> I am 100% sure, cause  "*telnet  <public-ip>  11211*"  works just perfect.
>
> Igor
>
> On Mon, Jun 26, 2017 at 3:32 PM, Valentin Kulichenko <
> [hidden email]> wrote:
>
> > Igor,
> >
> > Are you sure these connections are not blocked by firewall? If you
> provide
> > addresses explicitly in static IP finder, then it doesn't matter what is
> > published in shared IP finder. Is it possible that public addresses are
> > actually published and connectivity issue is caused by something else?
> >
> > -Val
> >
> > On Mon, Jun 26, 2017 at 3:01 PM, Igor Rudyak <[hidden email]> wrote:
> >
> > > Val,
> > >
> > > Regarding resolver it makes sense.
> > >
> > > Actually as of now, Option 2 doesn't work to connect Ignite clients to
> > > cluster using private-to-public IPs mapping. It just falls into
> infinite
> > > connection loop and periodically reports something like this:
> > >
> > > *[14:42:15] Failed to connect to any address from IP finder (will retry
> > to
> > > join topology every 2 secs): [/0:0:0:0:0:0:0:1%1:47500, /
> 127.0.0.1:47500
> > > <http://127.0.0.1:47500>, /<server-1-private-ip>:47500,
> > > /<server-2-private-ip>:47500, /<server-3-private-ip>:47500]*
> > >
> > > Even if I manually specify all public IPs for discovery, like this:
> > >
> > > *<bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">*
> > > * <property name="ipFinder">*
> > > * <bean
> > > class="org.apache.ignite.spi.discovery.tcp.ipfinder.multicast.
> > > TcpDiscoveryMulticastIpFinder">*
> > > * <property name="addresses">*
> > > * <list>*
> > > * <value><server-1-public-ip></value>*
> > > * <value><server-2-public-ip></value>*
> > > * <value><server-3-public-ip></value>*
> > > * </list>*
> > > * </property>*
> > > * </bean>*
> > > * </property>*
> > > *</bean>*
> > >
> > > It still can't connect to cluster and just periodically reports the
> same
> > > error.
> > >
> > > Does actually cluster membership protocol support the case when node
> > > available through multiple IP addresses and treats <ip-address-1>,
> > > <ip-address-2> and etc. as just different IPs corresponding to the same
> > > node?
> > >
> > >
> > > Igor
> > >
> > > On Mon, Jun 26, 2017 at 1:55 PM, Valentin Kulichenko <
> > > [hidden email]> wrote:
> > >
> > > > Igor,
> > > >
> > > > It depends on how address resolver works. But I agree, in general
> case
> > > it's
> > > > possible that a node can only resolve public address for itself. In
> > such
> > > > scenario we must publish public addresses in IP finder.
> > > >
> > > > -Val
> > > >
> > > > On Mon, Jun 26, 2017 at 1:02 PM, Igor Rudyak <[hidden email]>
> > wrote:
> > > >
> > > > > Option 2 also will not work for IaaS environments, where node can
> > > > > dynamically join or leave cluster.
> > > > >
> > > > > Igor
> > > > >
> > > > > On Jun 26, 2017 12:12 PM, "Valentin Kulichenko" <
> > > > > [hidden email]> wrote:
> > > > >
> > > > > > Yakov,
> > > > > >
> > > > > > Nodes that join outside of the network (usually these are
> clients)
> > > need
> > > > > to
> > > > > > know public addresses to connect. To make it work either of these
> > > must
> > > > > > happen:
> > > > > >
> > > > > > 1. Server nodes publish their public addresses in IP finder so
> that
> > > > > clients
> > > > > > can use them to connect.
> > > > > > 2. Client nodes use address resolver to map published internal
> > > > addresses
> > > > > to
> > > > > > public addresses.
> > > > > >
> > > > > > Both will work, but frankly I like option 1 more. First of all,
> > it's
> > > > just
> > > > > > more intuitive that IP finder contains all possible addresses
> that
> > > can
> > > > be
> > > > > > used to join. Second of all, option 2 introduces requirement to
> > have
> > > > > > address resolver for server addresses configured on client nodes
> -
> > > this
> > > > > is
> > > > > > not very good from usability standpoint.
> > > > > >
> > > > > > -Val
> > > > > >
> > > > > > On Mon, Jun 26, 2017 at 3:17 AM, Yakov Zhdanov <
> > [hidden email]>
> > > > > > wrote:
> > > > > >
> > > > > > > Guys, I don't get the point.
> > > > > > >
> > > > > > > 1. Why addresses processed by address resolver should appear in
> > > > shared
> > > > > > > finder? In my understanding finders contain only internal IPs
> > which
> > > > > > should
> > > > > > > be processed by a resolver.
> > > > > > >
> > > > > > > 2. This one is very critical. Nikolay and Anton, how can I
> review
> > > the
> > > > > > > changes?! Please update the ticket with PR or commit hash.
> > > > > > >
> > > > > > > --Yakov
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[yzhdanov]

>>Both will work, but frankly I like option 1 more. First of all, it's just
>>more intuitive that IP finder contains all possible addresses that can be
>>used to join. Second of all, option 2 introduces requirement to have
>>address resolver for server addresses configured on client nodes - this is
>>not very good from usability standpoint.

Val, I see your point, but (1) means that clients should have public IPs
for communication or server resolver should be able to resolve them. In any
case there will be some mixture. Is that correct?

--Yakov

[Valentin Kulichenko]

Yakov,

What do you mean by 'mixture'? :) Client obviously needs to know public
addresses to connect and I think it's natural to get them from IP finder.
Is there something wrong with this?

-Val

On Tue, Jun 27, 2017 at 5:01 AM, Yakov Zhdanov <[hidden email]> wrote:

> >>Both will work, but frankly I like option 1 more. First of all, it's just
> >>more intuitive that IP finder contains all possible addresses that can be
> >>used to join. Second of all, option 2 introduces requirement to have
> >>address resolver for server addresses configured on client nodes - this
> is
> >>not very good from usability standpoint.
>
> Val, I see your point, but (1) means that clients should have public IPs
> for communication or server resolver should be able to resolve them. In any
> case there will be some mixture. Is that correct?
>
> --Yakov
>

[yzhdanov]

Val,

What if client sits in  a private network, too?

Btw, do we pass all addresses through address resolver prior to sealing
node attributes? I mean communication, rest, etc?

--Yakov

[Valentin Kulichenko]

Yakov,

Private address should be published as well, of course.

-Val

On Wed, Jun 28, 2017 at 3:47 AM, Yakov Zhdanov <[hidden email]> wrote:

> Val,
>
> What if client sits in  a private network, too?
>
> Btw, do we pass all addresses through address resolver prior to sealing
> node attributes? I mean communication, rest, etc?
>
> --Yakov
>

[yzhdanov]

My point is that communication SPI should put both address types to its
attributes to share - private and addresses processed by a resolver.

--Yakov