Thank you for all the information. Yes, I am using multicast. Actually i had tried without nodelist but was hasty in reading the error message. Saw the "'corosync_quorum' failed to load for reason configuration error: nodelist " and didn't read the second part properly about expected_votes. My bad.
I don't want to configure quorum since keeping the service up is of utmost importance and the split-brain problem is indirectly getting handled through other means. In this case, should I be configuring expected_votes as 1? Currently my two-nodes in the cluster discovered each other without any nodelist and expected_votes as 1. Which is what I always wanted. -Thanks Nikhil On Wed, Jun 8, 2016 at 9:53 PM, Ferenc Wágner <wf...@niif.hu> wrote: > Nikhil Utane <nikhil.subscri...@gmail.com> writes: > > > Would like to know the best and easiest way to add a new node to an > already > > running cluster. > > > > Our limitation: > > 1) pcsd cannot be used since (as per my understanding) it communicates > over > > ssh which is prevented. > > 2) No manual editing of corosync.conf > > If you use IPv4 multicast for Corosync 2 communication, then you needn't > have a nodelist in corosync.conf. However, if you want a quorum > provider, then expected_votes must be set correctly, otherwise a small > partition booting up could mistakenly assume it has quorum. In a live > system all corosync daemons will recognize new nodes and increase their > "live" expected_votes accordingly. But they won't write this back to > the config file, leading to lack of information on reboot if they can't > learn better from their peers. > > > So what I am thinking is, the first node will add nodelist with nodeid: 1 > > into its corosync.conf file. > > > > nodelist { > > node { > > ring0_addr: node1 > > nodeid: 1 > > } > > } > > > > The second node to be added will get this information through some other > > means and add itself with nodeid: 2 into it's corosync file. > > Now the question I have is, does node1 also need to be updated with > > information about node 2? > > It'd better, at least to exclude any possibility of clashing nodeids. > > > When i tested it locally, the cluster was up even without node1 having > > node2 in its corosync.conf. Node2's corosync had both. If node1 doesn't > > need to be told about node2, is there a way where we don't configure the > > nodes but let them discover each other through the multicast IP (best > > option). > > If you use IPv4 multicast and don't specify otherwise, the node IDs are > assigned according to the ring0 addresses (IPv4 addresses are 32 bit > integers after all). But you still have to update expected_votes. > > > Assuming we should add it to keep the files in sync, what's the best way > to > > add the node information (either itself or other) preferably through some > > CLI command? > > There's no corosync tool to update the config file. An Augeas lense is > provided for corosync.conf though, which should help with the task (I > myself never tried it). Then corosync-cfgtool -R makes all daemons in > the cluster reload their config files. > -- > Feri >
_______________________________________________ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org