ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Valentin Kulichenko <valentin.kuliche...@gmail.com>
Subject Re: Zookeeper Discovery SPI & external IP address in AWS
Date Mon, 26 Jun 2017 22:32:39 GMT
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 <irudyak@gmail.com> 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 <
> valentin.kulichenko@gmail.com> 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 <irudyak@gmail.com> 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" <
> > > valentin.kulichenko@gmail.com> 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 <yzhdanov@apache.org>
> > > > 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
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message