Подключитесь к серверу Ignite с публичным и приватным ip - PullRequest
0 голосов
/ 02 июля 2018

Я попытался подключить свой клиент Ignite A (работает в Eclipse IDE) к удаленному серверу Ignite B, работающему в другой сети (ВМ OpenStack). B имеет общедоступный IP-адрес («плавающий IP-адрес»): например, 193.224.x.x и частный IP-адрес: 192.168.0.4 (не отображается из A). В A я установил общедоступный IP-адрес B для подключения в Java (например: IgniteConfiguration < TcpDiscoverySpi.setIpFinder < TcpDiscoveryVmIpFinder < setAddresses(Arrays.asList("193.224.x.x")). Порт 47500 (и некоторые другие для Ignite) открыт на B для всех. Затем я запускаю клиент, через какое-то время получаю исключение:

SEVERE: Failed to reinitialize local partitions (preloading will be stopped): GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=6, minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode [id=4a4a9c63-b3e6-4191-a966-6fe86071c7d5, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 192.168.1.100], sockAddrs=[/192.168.1.100:0, /0:0:0:0:0:0:0:1:0, /127.0.0.1:0], discPort=0, order=6, intOrder=0, lastExchangeTime=1530529560836, loc=true, ver=2.5.0#20180523-sha1:86e110c7, isClient=true], topVer=6, nodeId8=4a4a9c63, msg=null, type=NODE_JOINED, tstamp=1530529560973], nodeId=4a4a9c63, evt=NODE_JOINED]
class org.apache.ignite.IgniteCheckedException: Failed to send message (node may have left the grid or TCP connection cannot be established due to firewall issues) [node=TcpDiscoveryNode [id=d5828cee-0bbb-45e8-ba55-c34c1e68f165, addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.17.0.1, 192.168.0.4], sockAddrs=[/192.168.0.4:47500, /172.17.0.1:47500, 0:0:0:0:0:0:0:1%lo:47500, /127.0.0.1:47500], discPort=47500, order=1, intOrder=1, lastExchangeTime=1530529560939, loc=false, ver=2.5.0#20180523-sha1:86e110c7, isClient=false], topic=TOPIC_CACHE, msg=GridDhtPartitionsSingleMessage [parts=null, partCntrs=null, partSizes=null, partHistCntrs=null, err=null, client=true, compress=true, finishMsg=null, super=GridDhtPartitionsAbstractMessage [exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=6, minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode [id=4a4a9c63-b3e6-4191-a966-6fe86071c7d5, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 192.168.1.100], sockAddrs=[/192.168.1.100:0, /0:0:0:0:0:0:0:1:0, /127.0.0.1:0], discPort=0, order=6, intOrder=0, lastExchangeTime=1530529560836, loc=true, ver=2.5.0#20180523-sha1:86e110c7, isClient=true], topVer=6, nodeId8=4a4a9c63, msg=null, type=NODE_JOINED, tstamp=1530529560973], nodeId=4a4a9c63, evt=NODE_JOINED], lastVer=GridCacheVersion [topVer=0, order=1530529560661, nodeOrder=0], super=GridCacheMessage [msgId=1, depInfo=null, err=null, skipPrepare=false]]], policy=2]

Я вижу признаки того, что клиент на самом деле на мгновение подключен к серверу (снимок топологии [ver=6, servers=1, clients=1, CPUs=8,), но после этого он отключается (или что-то происходит). Из исключения кажется (я чувствую, что) клиент хочет подключиться к sockAddrs=[/192.168.0.4:47500..., который завершается неудачей, вместо 193.224.x.x:47500.

Я попробовал то, что обнаружил, чтобы B узнал его внешний IP, в конфигурационном файле, но ни один не работал:

<property name="addressResolver">
    <bean class="org.apache.ignite.configuration.BasicAddressResolver">
        <constructor-arg>
            <map>
                <entry key="192.168.0.4" value="193.224.x.x"> 

ни

<bean class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
    <property name="localAddress" value="193.224.x.x"/> 

ни

<property name="discoverySpi">
     <bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
         <property name="localAddress" value="193.224.x.x"/>

Понятия не имею, как это исправить. Документы по Ignite очень кратки относительно этой конфигурации кластеризации.

1 Ответ

0 голосов
/ 02 июля 2018

Похоже, Discovery работает для вас, но связь не получается.

Вы можете попробовать указать свой собственный TcpCommunicationSpi для IgniteConfiguration, установив localAddress для него в 193.224.x.x на узле сервера. Однако это, вероятно, приведет к тому, что весь трафик между узлами будет передаваться по внешней сети.

Вы также можете попытаться установить localAddress на 193.224.x.x (или другой внешний адрес) на узле A, чтобы убедиться, что он не привязывается к своему собственному 192.168.x.x, который не используется совместно с B Оставляя конфигурацию на B без изменений.

...