You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by pshomov <pe...@activitystream.com> on 2016/02/11 11:53:59 UTC
Node discovery behind NAT
Hello,
I have an Ignite node (IGFS caching HDFS) running on one of my servers,
close to where my data is. And I would like to have a node on my laptop to
have cached data close by. I setup the config for the node on my laptop to
have discoverySpi like this
/<property name="discoverySpi">
<bean
class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
<property name="ipFinder">
<bean
class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
<property name="addresses">
<list>
<value>XX.XX.XX.XX</value>
</list>
</property>
</bean>
</property>
</bean>
</property>
/
The node on the server however reports this
/[10:30:08,910][INFO ][disco-event-worker-#49%null%][GridDiscoveryManager]
Added new node to topology: TcpDiscoveryNode
[id=d527106b-9286-4218-95aa-2558c9ea31e5, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1,
172.16.208.1, 172.16.216.1, 192.168.1.42], sockAddrs=[/172.16.216.1:47500,
/0:0:0:0:0:0:0:1:47500, /172.16.208.1:47500, /127.0.0.1:47500,
/192.168.1.42:47500, /172.16.208.1:47500, /172.16.216.1:47500,
/192.168.1.42:47500], discPort=47500, order=28, intOrder=15,
lastExchangeTime=1455186602893, loc=false, ver=1.5.0#20151229-sha1:f1f8cda2,
isClient=false]
[10:30:08,911][WARN ][disco-event-worker-#49%null%][GridDiscoveryManager]
Node FAILED: TcpDiscoveryNode [id=d527106b-9286-4218-95aa-2558c9ea31e5,
addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 172.16.208.1, 172.16.216.1,
192.168.1.42], sockAddrs=[/172.16.216.1:47500, /0:0:0:0:0:0:0:1:47500,
/172.16.208.1:47500, /127.0.0.1:47500, /192.168.1.42:47500,
/172.16.208.1:47500, /172.16.216.1:47500, /192.168.1.42:47500],
discPort=47500, order=28, intOrder=15, lastExchangeTime=1455186602893,
loc=false, ver=1.5.0#20151229-sha1:f1f8cda2, isClient=false]
[10:30:08,939][INFO
][exchange-worker-#52%null%][GridCachePartitionExchangeManager] Skipping
rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=28,
minorTopVer=0], evt=NODE_JOINED, node=d527106b-9286-4218-95aa-2558c9ea31e5]
[10:30:08,949][INFO
][exchange-worker-#52%null%][GridCachePartitionExchangeManager] Skipping
rebalanc
ing (nothing scheduled) [top=AffinityTopologyVersion [topVer=29,
minorTopVer=0], evt=NODE_FAILED node=d527106b-9286-4218-95aa-2558c9ea31e5]
/
If I get this right, the node on the server is trying to initiate a
connection back to my laptop on the IP address the node is running on. And
that is a problem, since on my laptop I have a local IP provided by DHCP
server on the local network.
Is there a way to persuade the communicationSpi to re-use the socket we have
already opened from the laptop?
--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Node-discovery-behind-NAT-tp2956.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Node discovery behind NAT
Posted by Petar Shomov <pe...@activitystream.com>.
Hi Valentin,
Well, we can certainly work with this setup. Not ideal but usable ;) Will
look into doing something about UPnP to see if I can make the whole think a
bit more dynamic.
Thank you for your help!
Best regards,
Petar
On Thu, Feb 11, 2016 at 8:48 PM, vkulichenko <va...@gmail.com>
wrote:
> Hi,
>
> No, this socket can't be reused. And you're right, server's communication
> SPI can try to establish connection with the client (to port 47100 by
> default).
>
> If client is behind NAT, you can setup port forwarding on the router. You
> will also have to implement AddressResolver interface and provide it in
> IgniteConfiguration.setAddressResolver().
>
> For example, assume that server can access the router by IP 1.2.3.4 and
> your
> laptop has address 192.168.10.10. In this case the router should be able to
> forward 1.2.3.4:47100 to 192.168.10.10:47100. And address resolver should
> map 192.168.10.10 to 1.2.3.4, so that the server node knows which address
> to
> use to connect to the client.
>
> Will this work for you?
>
> Actually, I think we should add proper routing for client nodes. This is a
> known issue, I will check if we already have a ticket for this.
>
> -Val
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/Node-discovery-behind-NAT-tp2956p2965.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>
Re: Node discovery behind NAT
Posted by vkulichenko <va...@gmail.com>.
Hi,
No, this socket can't be reused. And you're right, server's communication
SPI can try to establish connection with the client (to port 47100 by
default).
If client is behind NAT, you can setup port forwarding on the router. You
will also have to implement AddressResolver interface and provide it in
IgniteConfiguration.setAddressResolver().
For example, assume that server can access the router by IP 1.2.3.4 and your
laptop has address 192.168.10.10. In this case the router should be able to
forward 1.2.3.4:47100 to 192.168.10.10:47100. And address resolver should
map 192.168.10.10 to 1.2.3.4, so that the server node knows which address to
use to connect to the client.
Will this work for you?
Actually, I think we should add proper routing for client nodes. This is a
known issue, I will check if we already have a ticket for this.
-Val
--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Node-discovery-behind-NAT-tp2956p2965.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.