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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.