[Pacemaker] [Semi-OT] To bridge or to bond?

Arnold Krille arnold at arnoldarts.de
Sat May 5 17:05:04 UTC 2012


Hi all,

please excuse (and ignore) this mail when you think its not appropriate for 
this list or to faq.

We had our servers all connected via one gigabit switch and used bonds to have 
2GB links for each of them (using drbd and pacemaker/corosync to keep our data 
distributed and services/machines up and running).
As the switch constitudes a SPOF, we wanted to eliminate this and put a second 
GB-switch into the rack.
Now I/we can't use the real bonding-modes anymore, only fail-over, tlb and 
alb. We don't really like the idea of fail-over because that means going back 
to 1GB data-rates. Using tlb we get nearly 2GBits total rates with 1GB per 
connection so that looks nice throughput wise. But for simple icmp-pings, 
50-90% of pings are lost propably due to the switches re-learning the mac-
addresses all the time. Also some tcp-connections seem to stall due to this. 
Not really a nice situation when desktop-virtualization and terminal servers 
are used in this scenario.

My questions:
Is there something obvious I missed in the above configuration?(*)
Would it improve the situation stability- and performance-wise when I use 
bridges instead of bonds to connect to the switches and let stp do its job? 
Would that work with clusters and drbd?
Obviously the cleanest solution would be to use two stackable switches and 
make sure that they still do their job when one fails. But that is out of 
question due to the prices attached to the switches...

Thanks for your input on this and have a nice remaining weekend,

Arnold

(*) I haven't yet looked into the switches configuration if they have special 
options for such a scenario...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20120505/dbeabb04/attachment-0003.sig>


More information about the Pacemaker mailing list