Does Consul work with the scenario where the IP address in “join” is reachable only for that node, the same address won’t be reachable from other nodes. And this IP maybe different than what is advertised.
Say Node A advertises IP A.1 and has join [B.1], but node C has join [B.2]
B.1 and B.2 point to B, but A cannot reach B with B.2 (only with B.1), so there should be no exchange of peer IPs for this setup to work.
Related
I've just created three dedicated master nodes and one data node for my cluster.
Now, I need to configure an initial list of nodes that will be contacted to discover and form a cluster.
I included IP addresses of the three dedicated master nodes as the values of discovery.zen.ping.unicast.hosts, but should I also include the IP address of the data node?
Adding IP address of 3 master nodes is sufficient. Data node's IP Address is not necessary.
I spent a little bit time to study about Consul. I had read about Consensus Protocol. I saw that if Consul cluster want to be available, it needs a quorum of servers node to elect leader. I wonder that when consul cluster has less than a quorum of nodes running, why does it not use the remain running nodes instead?
Can anyone answer for me? Thank you so much
A quorum is required to ensure that you'll never have inconsistent results. Otherwise a cluster of eight nodes (A B C D E F G H) might have a networking fail and become partitioned into two clusters (A B C D) (E F G H). Those two clusters then make two separate decisions that are incompatible (say update the same property of some configuration). When the partition is healed there's no way to merge the two changes.
If a quorum is required then you know that any quorum has at least one copy of every decision made; thus any conflicts will be spotted by at least one node and disallowed.
Lets say I have a cassandra cluster with the following scheme:
(76-100) Node1 - Node2 (0-25)
| |
(51-75) Node4 - Node3 (26-50)
Each node is primarily responsible for a range of partition keys: For example, for a total range of 0-100, I have indicated what range the node is responsible above.
Now, lets say Node 1 is coordinator handing requests. A read request corresponding to partition key 28 reaches Node 1.
How does Node 1 know that Node 2 is primary node for partition key 28. Does each node have a mapping of node IDs to the partition key they are responsible for.
For instance,
{Node1:76-100, Node2: 0-25, Node3: 26-50, Node4: 51-75}
is this mapping present as global configuration in all the nodes since any node can act as coordinator when requests are forwarded in round-robin fashion?
Thanks
The mapping is not present as a global configuration. Rather each node maintains its own copy of the state of the other nodes in the cluster. Typically the cluster will use the gossip protocol to frequently exchange information about the other nodes in the cluster with a few nearby nodes. In this way the mapping information will rapidly propagate to all the nodes in the cluster, even if there are thousands of nodes.
It is necessary for every node to know how to map partition keys to token values, and to know which node is responsible for that token. This is so that every node can act as a coordinator to handle any request by sending it to the exact nodes that are handling that key.
Taken a step further, if you use for example the current java driver, you can have the client use a token aware routing policy. This works by the client driver also getting a copy of the information about how to map keys to nodes. Then when you issue a request, it will be sent directly to a node that is handling that key. This gives a nice performance boost.
Generally you do not need to worry about how the keys are mapped, since if you use vnodes and the Murmur3Partitioner, the cluster will take care of creating the mapping of keys to balance the load across the cluster as nodes are added and removed.
For example, we have one master node running on master1
two data nodes running on server2, server3
Let us say shard relocation happening from server2 to server3
Now to copy the data folder, will elasticsearch cluster make use of master1 (which is a master node) i.e. is the data transferred directly from server2 to server3 or will it go via master1?
We would like to know this as our master1 is running low configuration machine.
No, the master node is not directly involved in the transfer of shards from one node to another. The data is copied from the source node directly to the destination node.
The master node is involved in managing global cluster state, but if it's master only it will not have any data files on it nor have data transferred to or from it:
Note, Elasticsearch is a peer to peer based system, nodes communicate
with one another directly if operations are delegated / broadcast. All
the main APIs (index, delete, search) do not communicate with the
master node. The responsibility of the master node is to maintain the
global cluster state, and act if nodes join or leave the cluster by
reassigning shards.
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/modules-discovery.html
dedicated master nodes are nodes with the settings node.data: false
and node.master: true. We actively promote the use of dedicated master
nodes in critical clusters to make sure that there are 3 dedicated
nodes whose only role is to be master, a lightweight operational
(cluster management) responsibility. By reducing the amount of
resource intensive work that these nodes do (in other words, do not
send index or search requests to these dedicated master nodes), we
greatly reduce the chance of cluster instability.
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/modules-node.html
Assume there are 3 running nodes launched with multicast=false and unicast=true, but no unicast nodes are given when starting. After they all get up, they are not aware of each other.
Is there a way to tell each one IP address of the other two so they can do discovery at runtime and join to same cluster?
Yes, add the ip addresses of all the other nodes in the cluster to the
discovery.zen.ping.unicast.hosts property,
in the elasticsearch.yml file in the config folder.
Say you have three nodes, in each node, add the address of the other two nodes as below:
discovery.zen.ping.unicast.hosts: ["xx.xx.xxx.xx","yy.yy.yy.yy"]