[PVE-User] Changing votes and quorum

[Thomas Lamprecht]

Hi!

Am 10/28/2018 um 02:54 PM schrieb Dewangga Alam:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Hello!
> 
> I was new in proxmox and am trying to build large scale proxmox 5.2
> cluster (>128 nodes). My `/etc/pve/corosync.conf` configuration like :
> 
> ```
> nodelist {
>   node {
>     name: node1
>     nodeid: 1
>     quorum_votes: 1
>     ring0_addr: 192.168.24.2
>   }
>   ... skip till nodes 28 ...
>   node {
>     name: node28
>     nodeid: 28
>     quorum_votes: 1
>     ring0_addr: 192.168.24.110
>   }
> }
> quorum {
>   provider: corosync_votequorum
>   expected_votes: 16

expected_votes must be your real highest expected votes.

>   last_man_standing: 1
>   last_man_standing_window: 20000



> }
> totem {
>   cluster_name: px-cluster1
>   config_version: 90
>   window_size: 300
>   interface {
>     ringnumber: 0
>   }
>   ip_version: ipv4
>   secauth: on
>   transport: udpu
>   version: 2
> }
> ```
> 
> My cluster have 28 nodes in each rack. and total nodes will 28 nodes*5
> racks. So it will 140 nodes in a cluster. From the adjustment above, I
> wonder there's affected to pve/corosync.conf configuration, but in
> fact, it didn't.
> 
> So my basic question, when I invoke `pvecm status` in a node, the
> result wasn't as I expect. Then, is it possible to change votequorum
> configuration?

What wasn't as expected? That your set expected_votes is not
"accepted" by corosync? That is expected behaviour.

What is the real problem you want to solve?

> 
> 
> ```
> Quorum information
> - ------------------
> Date:             Sun Oct 28 20:51:42 2018
> Quorum provider:  corosync_votequorum
> Nodes:            28
> Node ID:          0x00000002
> Ring ID:          1/27668
> Quorate:          Yes
> 
> Votequorum information
> - ----------------------
> Expected votes:   28

if more nodes are online than you set expected it will automatically use
the real node count, i.e. formula would be

expected = max(user_set_expected, #nodes_quorate_online)

Note that last_man_standing is not really recommended by us, if you
employ it nonetheless then please test it carefully before rolling out
in production, maybe take also a look at wait_for_all flag to take
this a bit on the save side for cluster cold boots.

> Highest expected: 28
> Total votes:      28
> Quorum:           15
> Flags:            Quorate LastManStanding
> ```
> -----BEGIN PGP SIGNATURE-----
> 
> iQIzBAEBCAAdFiEEZpxiw/Jg6pEte5xQ5X/SIKAozXAFAlvVv6UACgkQ5X/SIKAo
> zXBVdg/9GryQp4HbCmTYfHx1wlbESRlTsBViNCoKLCYcnbdYK9oZa6WCO34C5vHq
> RGSmvqT8CPk1exlXQYvHRNZwBJHzjZ8t5CtQXxOrW+SiIlSWcuW6iw+UKDrZASqI
> wwmJIy0Snu6GqP3Fb6OLfpU5rzGgHARQPBlSxAG7q8U7ZSzQIJ/bm7OnSc/R6Ghk
> Xv/GsCfYD3iDlkkGsUb0xG4f2X7o539OP4su5j+cYcjfKn/l+ffsi0P//hZn21He
> oltgUq6i9v6VJpwkc8rVIZ7/WI/yOqfiwV4OsYiJpASxxzvysJEKedLLp1fyNTuB
> a4D3JXy9caYurbEWGeApKnvJILtr2E1APDJWqXH82MYaY/HgNn97bkdvKnmaq/dD
> 3/TwaUUOn2Mk74Pw2WxqXHQp7heAZW1+O/pb6qtgIDIMsZRB4zZRddfbh6X7ySoi
> Ca8WIh9LkWhD5T1qZPhT2lFyWgLww1ZxCGbEKkVSH7MUsMG8+YwY9NwCTmFdiQoJ
> y9gNSMBJ4l8Fj+qyuvj0zd9Wmr3nW6/AsW+6edWUN9py0tKFxgOoqFTJDCn288AC
> ytl/a3V/iVDh21GnltkUdoUmZAaYIjty3CPLs3uTNqLaI/7c3FQAw8+13W1Oa1qR
> zrBdNa4fkljJw9ew1x5h4zW466HWb5wm1O/HAG9HmPKBQk9UH48=
> =wQxp
> -----END PGP SIGNATURE-----