From: Mira Limbeck <m.limbeck@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: Re: [pve-devel] [PATCH docs v2] pvecm, network: add section on corosync over bonds
Date: Fri, 25 Jul 2025 14:22:44 +0200 [thread overview]
Message-ID: <3027d138-99d3-419c-a124-7edc8a4f5623@proxmox.com> (raw)
In-Reply-To: <73cae5cf-3035-4cb8-9583-c71d7a8fd337@proxmox.com>
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.
_______________________________________________
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 12:21 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 [this message]
2025-07-25 14:05 ` Friedrich Weber
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=3027d138-99d3-419c-a124-7edc8a4f5623@proxmox.com \
--to=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