From: Friedrich Weber <f.weber@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Mira Limbeck <m.limbeck@proxmox.com>
Subject: Re: [pve-devel] [PATCH docs v2] pvecm, network: add section on corosync over bonds
Date: Fri, 25 Jul 2025 16:05:32 +0200 [thread overview]
Message-ID: <4533cf05-33a0-4695-a9b3-088dbbfe3df1@proxmox.com> (raw)
In-Reply-To: <3027d138-99d3-419c-a124-7edc8a4f5623@proxmox.com>
On 25/07/2025 14:23, Mira Limbeck wrote:
>
>
> On 7/25/25 13:50, Friedrich Weber wrote:
>> On 25/07/2025 13:39, Friedrich Weber wrote:
>>> [...]
>>> +Corosync Over Bonds
>>> +~~~~~~~~~~~~~~~~~~~
>>> +
>>> +Using a xref:sysadmin_network_bond[bond] as the only Corosync link can be
>>> +problematic in certain failure scenarios. If one of the bonded interfaces fails
>>> +and stops transmitting packets, but its link state stays up, some bond modes
>>> +may cause a state of asymmetric connectivity where cluster nodes can only
>>> +communicate with different subsets of other nodes. In case of asymmetric
>>> +connectivity, Corosync may not be able to form a stable quorum in the cluster.
>>> +If this state persists and HA is enabled, nodes may fence themselves, even if
>>> +their respective bond is still fully functioning. In the worst case, the whole
>>> +cluster may fence itself.
>>> +
>>> +For this reason, our recommendations are as follows.
>>> +
>>> +* We recommend a dedicated physical NIC for the primary Corosync link. Bonds
>>> + can be used as additional links for increased redundancy.
>>
>> These recommendations are still not 100% clear: Are we fine with a setup
>> with
>>
>> - link 0: dedicated corosync link
>> - link 1: corosync link over a bond with a problematic mode (such as
>> balance-rr or LACP with bond-lacp-rate slow)
>>
>> ?
>> In my tests, as long as the dedicated link 0 is completely online, it
>> doesn't matter if a bond runs into the failure scenario above (one of
>> the bonded NICs stops transmitting packets), corosync will just continue
>> using link 0. But as soon as link 0 goes down and the failure scenario
>> happens, the whole-cluster fence may happen. So should our
>> recommendation be the relatively strict "if you put corosync on a bond
>> (even if it is only a redundant link), use only active-backup or
>> LACP+bond-lacp-rate fast"?
>
> I'd say yes, the recommendation should be either dedicated link
> directly, or a bond as redundant link with active-backup or
> LACP+lacp-rate fast only.
Thanks for the input. I've rephrased the section (and did some other
adjustments) to make it clear that the caveats apply whenever a bond is
used for corosync traffic.
v3:
https://lore.proxmox.com/pve-devel/20250725140312.250936-1-f.weber@proxmox.com/T/
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next prev parent reply other threads:[~2025-07-25 14:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-25 11:39 Friedrich Weber
2025-07-25 11:50 ` Friedrich Weber
2025-07-25 12:22 ` Mira Limbeck
2025-07-25 14:05 ` Friedrich Weber [this message]
2025-07-25 14:04 ` [pve-devel] superseded: " Friedrich Weber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4533cf05-33a0-4695-a9b3-088dbbfe3df1@proxmox.com \
--to=f.weber@proxmox.com \
--cc=m.limbeck@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox