Create unicast channel with different elasticsearch versions


(Danny) #1

I am having two elasticsearch nodes talk to each other, one is version 1.6.0 and the other is 1.4.5
I have both elasticsearch.yml files edited so they can talk to each other, though my worry is that because they are different versions, the nodes cannot talk to eachother.

cluster.name: cluster1
node.name: "node1"
network.host: 127.0.0.1
discovery.zen.ping.multicast.enabled: false
discovery.zen.ping.unicast.hosts: ["node1(ip)","node2(ip)[9300-9400]"]
index.number_of_shards: 5
index.number_of_replicas: 1
bootstrap.mlockall: true
node.master: true
node.data: true
discovery.zen.ping.timeout: 10s

(for the other .yml, the node(ip) is switched around)

If my configuration is correct (if not warn me), would the elasticsearch version matter when making nodes?


(Colin Goodheart-Smithe) #2

Elasticsearch nodes are generally backwards compatible for the same major version. However, you should only run a cluster with mixed versions on a temporary basis during an upgrade and not as a permanent solution.


(Danny) #3

I was able to update Elasticsearch so both VMs run 1.6.1

My goal is to have data from one elasticsearch VM to be sent to another elasticsearch VM by unicast, and have the data be saved on both elasicsearch VMs.

My first issue is that the nodes don't appear to recognize each other by unicast.
I am able to ping both VMs to each other, so I know they are both online. While using the same config as above:

192.168.1.5 is my primary VM
192.168.1.8 is my secondary VM

When I run sudo curl 127.0.0.1:9200/_cat/nodes
on my primary VM, I get: ELKVM 192.168.1.5 8 38 0.00 d * elasticsearch-5-node,
on my second VM, I get: ELKVM 192.168.1.5 7 37 0.00 d * elasticsearch-8-node.

When I run sudo curl 192.168.1.8:9200/_cat/nodes on my primary VM I get curl: (7) Failed connect to 192.168.1.8:9200; No route to host, and vice versa in my other VM.

Even if they are able to communicate, I can see what data is stored by using 'localhost:9200/_cat/indices?v' I have have had no luck in finding a command to trade data between nodes, if there is one I would appreciate it being shared.

After I get both nodes to talk to each other, I would like to use Elasticsearch instead of Logstash to forward data, along with saving space and time, are there examples of this working or is Logstash the best way to trade data?


(Colin Goodheart-Smithe) #4

From this output it looks like both modes are running on the same IP (192.168.1.5). Could your VMs be misconfigured and have the same IP address?

Also check that you can telnet to 192.168.1.8:9300 from 192.168.1.5 and that you can telnet to 192.168.1.5:9300 from 192.168.1.8.

The is no command for this. The shards of you index will automatically be distributed amoung the nodes of your cluster. You are not seeing this right now because the nodes cannot communicate with each other so have not been able to form a single cluster.

I don't understand what you are asking here, could you explain? Elasticsearch cannot be used to extract and forward data from a data source. That is the job of Logstash.


(Danny) #5

Typing ifconfig shows they have different IPs.
I prefer ssh, but I am able to ssh between both VMs, I can log into either VM from the other, and ping from each other.
If I try sudo telnet -d 192.168.1.8 9300 I get No route to host, vice versa for the other VM. Same with ssh doing sudo ssh user@192.168.1.8 -p 9300.

Maybe it's something with having network.host: 127.0.0.1, should the IP be something else?

I am running on CentOS 7.1

Ah. So shards are how indexes get automatically traded?

I want to be able to load data into one VM, have that data will be saved in that VM. Then that same data will be copied over to the other VM, be saved, allowing me to have two complete copies of data (automatically, hopefully). In the real word, if one server went down, I would still have the other server to analyze all the data with. I'm asking if Elasticsearch is able to trade data, or if that is the job of Logstash.


(Danny) #6

Now my primary .yml files have

netowrk.host: 0.0.0.0
discovery.zen.ping.unicast.hosts: ["192.168.1.5","192.168.1.8:9300"]

The secondary .yml file has:

netowrk.host: 0.0.0.0
discovery.zen.ping.unicast.hosts: ["192.168.1.8,"192.168.1.5:9300"]

(Magnus B├Ąck) #7

netowrk.host: 0.0.0.0

Do you really have "netowrk" in your configuration files?


(system) #8