[pve-devel] [RFC pve-cluster] prefer 'name' subkey over 'ring0_addr' for nodename

Thomas Lamprecht t.lamprecht at proxmox.com
Mon Oct 5 17:38:55 CEST 2015


Ok, i think its time to go home for today. A reboot solved my 
objections, everything is working as expected and better.
Lesson learned, live integration of such changes with corosync-cfgtool 
-R do not work on multi nodes cluster.

Request for comment.

On 10/05/2015 05:25 PM, Thomas Lamprecht wrote:
> Ok, have some objections myself, the test i did were one an one node 
> cluster (yeah, poor I know), on a three node cluster i have problems 
> with:
>
>> logging {
>>   debug: off
>>   to_syslog: yes
>> }
>>
>> nodelist {
>>   node {
>>     nodeid: 2
>>     quorum_votes: 1
>>     ring0_addr: two-coro
>>     name: two
>>   }
>>
>>   node {
>>     nodeid: 1
>>     quorum_votes: 1
>>     ring0_addr: one-coro
>>     name: one
>>   }
>>
>>   node {
>>     nodeid: 3
>>     quorum_votes: 1
>>     ring0_addr: three-coro
>>     name: three
>>   }
>>
>> }
>>
>> quorum {
>>   provider: corosync_votequorum
>> }
>>
>> totem {
>>   cluster_name: teachings
>>   config_version: 11
>>   ip_version: ipv4
>>   secauth: on
>>   version: 2
>>   interface {
>>     bindnetaddr: 10.10.1.151
>>     ringnumber: 0
>>   }
>>
>> }
> I get the
>> Oct 05 17:23:26 a corosync[1722]: [VOTEQ ] configuration error: 
>> nodelist or quorum.expected_votes must be configured!
>> Oct 05 17:23:26 a corosync[1722]: [VOTEQ ] will continue with current 
>> runtime data
> Error, which is a bit strange, my hosts file has
>
>> # corosync
>> 10.10.1.151 one-coro.proxmox.com one-coro
>> 10.10.1.152 two-coro.proxmox.com two-coro
>> 10.10.1.153 three-coro.proxmox.com three-coro
>
> In there. I better recheck all.
>
>
> On 10/05/2015 04:58 PM, Thomas Lamprecht wrote:
>> I ran into trouble when switching the corosync communication to an 
>> own network, under the condition that I didn't want to move the 
>> webinterface address/communication with it.
>> As a reference I followed roughly this procedure:
>> I configured my new NIC/interface, added a new /etc/hosts entries for 
>> my static addresses where corosync should run, then changed the 
>> 'ring0_addr' from my nodes and the bindnetaddr from my totem 
>> respectively, followed by a reboot.
>> It worked besides that pmxcfs uses ring0_addr for the nodenames, so 
>> .members had "wrong" nodename entries and the ha-manager (for 
>> example, there are more problems) couldn't find the lrm_status'es 
>> anymore (as it searched for the wrong /etc/pve/nodes/<...>) directory.
>>
>> As corosync.conf allows a node entry 'name' this should be used if 
>> defined, else we keep current behaviour and fall back to 'ring0_addr'.
>> FYI, pacemacer also uses the name key, but only when ring0_addr is an 
>> IP address and not a hostname.
>>
>> Any objections? Else I will integrate those changes in pvecm, to ease 
>> up configuration for separated cluster communications and redundant 
>> ring protocol use.
>>
>> Thomas Lamprecht (1):
>>    Prefer name key from corosync config for nodename
>>
>>   data/src/confdb.c | 6 ++++++
>>   1 file changed, 6 insertions(+)
>>
>
>
> _______________________________________________
> pve-devel mailing list
> pve-devel at pve.proxmox.com
> http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>





More information about the pve-devel mailing list