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 < [email protected]> 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 <[email protected]> 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" < > > [email protected]> 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 <[email protected]> > > > 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 > > > > > > > > > >
