<div dir="ltr">Thank you for all the information.<div><br></div><div>Yes, I am using multicast. Actually i had tried without nodelist but was hasty in reading the error message.</div><div>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.</div><div><br></div><div>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.</div><div>In this case, should I be configuring expected_votes as 1? </div><div><br></div><div>Currently my two-nodes in the cluster discovered each other without any nodelist and expected_votes as 1. Which is what I always wanted.</div><div><br></div><div>-Thanks</div><div>Nikhil</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 8, 2016 at 9:53 PM, Ferenc Wágner <span dir="ltr"><<a href="mailto:wferi@niif.hu" target="_blank">wferi@niif.hu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Nikhil Utane <<a href="mailto:nikhil.subscribed@gmail.com">nikhil.subscribed@gmail.com</a>> writes:<br>
<br>
> Would like to know the best and easiest way to add a new node to an already<br>
> running cluster.<br>
><br>
> Our limitation:<br>
> 1) pcsd cannot be used since (as per my understanding) it communicates over<br>
> ssh which is prevented.<br>
> 2) No manual editing of corosync.conf<br>
<br>
</span>If you use IPv4 multicast for Corosync 2 communication, then you needn't<br>
have a nodelist in corosync.conf. However, if you want a quorum<br>
provider, then expected_votes must be set correctly, otherwise a small<br>
partition booting up could mistakenly assume it has quorum. In a live<br>
system all corosync daemons will recognize new nodes and increase their<br>
"live" expected_votes accordingly. But they won't write this back to<br>
the config file, leading to lack of information on reboot if they can't<br>
learn better from their peers.<br>
<span class=""><br>
> So what I am thinking is, the first node will add nodelist with nodeid: 1<br>
> into its corosync.conf file.<br>
><br>
> nodelist {<br>
> node {<br>
> ring0_addr: node1<br>
> nodeid: 1<br>
> }<br>
> }<br>
><br>
> The second node to be added will get this information through some other<br>
> means and add itself with nodeid: 2 into it's corosync file.<br>
> Now the question I have is, does node1 also need to be updated with<br>
> information about node 2?<br>
<br>
</span>It'd better, at least to exclude any possibility of clashing nodeids.<br>
<span class=""><br>
> When i tested it locally, the cluster was up even without node1 having<br>
> node2 in its corosync.conf. Node2's corosync had both. If node1 doesn't<br>
> need to be told about node2, is there a way where we don't configure the<br>
> nodes but let them discover each other through the multicast IP (best<br>
> option).<br>
<br>
</span>If you use IPv4 multicast and don't specify otherwise, the node IDs are<br>
assigned according to the ring0 addresses (IPv4 addresses are 32 bit<br>
integers after all). But you still have to update expected_votes.<br>
<span class=""><br>
> Assuming we should add it to keep the files in sync, what's the best way to<br>
> add the node information (either itself or other) preferably through some<br>
> CLI command?<br>
<br>
</span>There's no corosync tool to update the config file. An Augeas lense is<br>
provided for corosync.conf though, which should help with the task (I<br>
myself never tried it). Then corosync-cfgtool -R makes all daemons in<br>
the cluster reload their config files.<br>
<span class="HOEnZb"><font color="#888888">--<br>
Feri<br>
</font></span></blockquote></div><br></div>