[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