To add to this, the EC2 plugin also works ok. It also seems to work fine
without security groups too.
On the timeouts, i suspect 60s is slightly high given the fact that
cross-region AWS comms are actually very fast but for 'uncontrollable'
latency purposes, i've left it at a minute.
Done some wikipedia river testing on the setup and works perfectly with
000's of docs.
On 4 October 2012 16:42, Drew Raines aaraines@gmail.com wrote:
Derry O' Sullivan wrote:
For anyone who is interested, the problem was to do with my
network.publish_host setting. It was not being set correctly so
both nodes could not contact each other. Once that was set
correctly, all worked perfectly.Here's a minimal 2-node zen config similar to what worked for him:
cluster.name: foo node.name: alice network.publish_host: 23.20.100.100 discovery.zen.ping_timeout: 60s discovery.zen.ping.multicast.enabled: false discovery.zen.ping.unicast.hosts: ["54.247.55.55"] cluster.name: foo node.name: bob network.publish_host: 54.247.55.55 discovery.zen.ping_timeout: 60s discovery.zen.ping.multicast.enabled: false discovery.zen.ping.unicast.hosts: ["23.20.100.100"]If alice is in us-east and bob in eu-west, they won't be able to
communicate by 10/8 addresses[1]. Since an individual ec2 node knows
nothing about its public IP, its local interface is identified by a
10/8 address.When alice looks through the unicast list to try and join bob, she
will connect to bob's internal interface (due to his auto-resolved
network.bind_host[2]) through the AWS perimeter by his public IP.
During the transport handshake, bob needs to tell her how to get
back to him to communicate further, and that's what the
network.publish_host is for. alice also tells bob about her
publish_host, and they're off to the races.[3]Derry originally was trying to get this working with ec2 discovery
and reported that correctly supplying publish_host and his security
group caused it to work as well. So if you want a simpler
alternative to zen for this particular case, you should try that.-Drew
Footnotes:
[1] They have to talk over public nets.
[2] In order to open a socket, ES has to bind to an interface. ES
can use the network.bind_host setting if you don't want it to
resolve it for itself. And if you supply simply network.host
without the other two, it will use that IP to bind to an
interface and talk to peers.[3] Note that this technique should also work across generic NATs if
you supplied appropriate host:port combinations in the unicast
list and then told your router to redirect those ports to
appropriate nodes.--
--