From: Hannes Duerr <h.duerr@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Friedrich Weber <f.weber@proxmox.com>
Subject: Re: [pve-devel] [PATCH docs v3] pvecm, network: add section on corosync over bonds
Date: Mon, 28 Jul 2025 18:16:12 +0200 [thread overview]
Message-ID: <86841dab-96d5-403d-a91f-a69d17b716a7@proxmox.com> (raw)
In-Reply-To: <20250725140312.250936-1-f.weber@proxmox.com>
On 7/25/25 4:03 PM, Friedrich Weber wrote:
> +Corosync Over Bonds
> +~~~~~~~~~~~~~~~~~~~
> +
> +Using a xref:sysadmin_network_bond[bond] as a 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, and there are no other
> +Corosync links available
I thought it can also occur if the are still other Corosync links available?
If i understand the next part correct you're even assuming it?
> , some bond modes may cause a state of asymmetric
> +connectivity where cluster nodes can only communicate with different subsets of
> +other nodes. Affected are bond modes that provide load balancing, as these
> +modes may still try to send out a subset of packets via the failed interface.
> +In case of asymmetric connectivity, Corosync may not be able to form a stable
> +quorum in the cluster.
--- here
> 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.
> +
> +We recommend at least one dedicated physical NIC for the primary Corosync link,
> +see xref:pvecm_cluster_requirements[Requirements]. Bonds may be used as
> +additional links for increased redundancy. To avoid fencing in the failure
> +scenario outlined above, the following caveats apply whenever a bond is used
> +for Corosync traffic:
> +
> +* We *advise against* using bond modes *balance-rr*, *balance-xor*,
> + *balance-tlb*, or *balance-alb* for Corosync traffic. As explained above,
> + they can cause asymmetric connectivity in certain failure scenarios.
> +
> +* *IEEE 802.3ad (LACP)*: This bond mode can cause asymmetric connectivity in
> + certain failure scenarios as explained above, but it can recover from this
> + state, as each side of the bond (Proxmox VE node and switch) can stop using a
> + bonded interface if it has not received three LACPDUs in a row on it.
> + However, with default settings, LACPDUs are only sent every 30 seconds,
> + yielding a failover time of 90 seconds. This is too long, as nodes with HA
> + resources will fence themselves already after roughly one minute without a
> + stable quorum. If LACP bonds are used for corosync traffic, we recommend
> + setting `bond-lacp-rate fast` *on the Proxmox VE node and the switch*!
> + Setting this option on one side requests the other side to send an LACPDU
> + every second. Setting this option on both sides can reduce the failover time
> + in the scenario above to 3 seconds and thus prevent fencing.
> +
> +* Bond mode *active-backup* will not cause asymmetric connectivity in the
> + failure scenario described above. The node whose bond experienced the failure
> + may lose connection to the cluster and, if HA is enabled, fence itself.
> +
> Separate Cluster Network
> ~~~~~~~~~~~~~~~~~~~~~~~~
>
_______________________________________________
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-28 16:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-25 14:01 Friedrich Weber
2025-07-28 16:16 ` Hannes Duerr [this message]
2025-07-29 16:25 ` Friedrich Weber
2025-07-30 8:59 ` [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=86841dab-96d5-403d-a91f-a69d17b716a7@proxmox.com \
--to=h.duerr@proxmox.com \
--cc=f.weber@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