[pve-devel] PATCH: Add support for bridges with more than one physical link.
Andrew Thrift
andrew at networklabs.co.nz
Wed Feb 12 10:05:56 CET 2014
Correct in your case, but not all Proxmox users have MSTP/PVST+ configured.
A much lower risk strategy is to use Multi-Chassis Link Aggregation Groups
between Switch-A and Switch-B with a 4 port "bond" on the Proxmox hosts,
using a L3/L4 hash you will achieve better load balancing of traffic across
all 4 links and as this requires no changes to Proxmox will not introduce
the chance of loops.
We have had this in production for 13 months now with no issues.
On Wed, Feb 12, 2014 at 9:55 PM, Pablo Ruiz <pablo.ruiz at gmail.com> wrote:
> That's what MSTP/PVSTP+ is supposed to avoid. (And infact, it does so in
> our environment).. however, it requires switches with such capability.
>
>
> On Wed, Feb 12, 2014 at 9:53 AM, Andrew Thrift <andrew at networklabs.co.nz>wrote:
>
>> While this is a very neat way to load balance vlan traffic, it could be
>> dangerous.
>>
>> You are effectively allowing users to create a loop. Unless they have
>> their switches and spanning tree configured correctly upstream of the host,
>> they could create a large broadcast storm on their network, likely knocking
>> out other hosts and switches control planes.
>>
>> It is the same as looping a cable between two ports on a switch that does
>> not have edge-safeguard functionality.
>>
>> Just my 2c.
>>
>>
>>
>>
>> On Wed, Feb 12, 2014 at 6:28 PM, Pablo Ruiz <pablo.ruiz at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> In our proxmox cluster, each node has two bond interfaces, and each bond
>>> interface connects to and independent switch. This allows us to enable
>>> MSTP/PVSTP+ and thus load share traffic on different vlans across switches.
>>>
>>> +==========+
>>> | SWITCH-A |---,
>>> +==========+ |
>>> +=======+ | |
>>> | |-----(bond1)--´ |
>>> -----| Node-X | (trunk)
>>> | |-----(bond2)--, |
>>> +=======+ | |
>>> +==========+ |
>>> | SWITCH-B |---´
>>> +==========+
>>>
>>> In this setup, we have a couple of vlans (iSCSI-A & iSCSI-B) each which
>>> has been priorized (by means of MSTP/PVST) on each switch. Also, proxmox's
>>> internal (software) bridges have STP disabled (so they do not conflict with
>>> MSTP's traffic). With this setup we are able to achieve full-redundant
>>> network interconnects, while at the same time using both links/bonds for
>>> iSCSI traffic (with multipath+round-robin).
>>>
>>> However, proxmox's current code doesnt allow bridges with more than one
>>> physical interface, something we had to apply an small enhacement to
>>> proxmox in order to setup our cluster as stated.
>>>
>>> We would like to have this enhacement merged into proxmox, and so I've
>>> read about proxmox development policies, etc. And as stated here is the
>>> link containing a diff format patch:
>>> https://github.com/pruiz/pve-common/commit/ce0173a1079e4fc8bb08d9eebd1df71f0f8dc3fe.diff aswell
>>> as the prettified diff from github:
>>> https://github.com/pruiz/pve-common/commit/ce0173a1079e4fc8bb08d9eebd1df71f0f8dc3fe
>>>
>>> This code has been in production for little more than a month with no
>>> issues. But, please let me know what maybe missing and/or what amendments
>>> needs to be done in order for this patch to be accepted into proxmox.
>>>
>>> Best regards,
>>> Pablo
>>>
>>> PD: I'll be sending the signed contribution aggrement by tomorrow, as
>>> soon as I get to my office. As I hope to send another contribution
>>> regarding ZFS plugin next.
>>>
>>> _______________________________________________
>>> pve-devel mailing list
>>> pve-devel at pve.proxmox.com
>>> http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.proxmox.com/pipermail/pve-devel/attachments/20140212/8579c9dd/attachment.htm>
More information about the pve-devel
mailing list