[ovs-dev] [PATCH] bonding: Balance bond slaves based on ratio.
jesse at nicira.com
Thu Oct 15 20:37:29 UTC 2009
Ian Campbell wrote:
> On Thu, 2009-10-15 at 04:28 +0100, Jesse Gross wrote:
>> Previously when deciding whether to migrate a hash between slaves
>> we would never move it if it would cause more load on the new slave
>> than the old. This could lead to a situation where the slaves would
>> be imbalanced but no migration would occur since it would flip the
>> load. This will do the migration if it will decrease the ratio.
> This sounds logical to me and the implementation seems to match.
> I wonder how it behaves in bonds with more than two slaves? It will only
> compare pairs of slaves but I guess there is a good chance that it will
> still converge on a reasonably stable configuration. (I'm not really all
> that bothered about the >2 slave case behaving in an ideal fashion, more
> idly wondering).
Thanks for bringing this up. It's difficult to reason about so it is
good to double check (and I found a bug related to the sort order while
verifying my assumptions). I believe that this implementation will
always result in convergence on a stable configuration even for larger
numbers of slaves. Here is my reasoning:
In order for the distribution to be unstable a migration or set of
migrations would need to undo the result of a previous migration in
order to flip between a set of states. This can never occur because we
will only move a hash if the new slave has less load than the old when
comparing load excluding the migrating hash. The chain of migrations
can be arbitrarily long but as long as the base load must always
decrease, a hash will never be able to return to the original slave.
While there could be other hashes that are moving and therefore changing
the base load, all of them would need to move back to their origins to
perpetuate the cycle. While there are some esoteric configurations that
could cause a few rounds of rebalancing, something needs to move to a
lower load in every step. As a result, there is no way to return to the
origin and everything must eventually settle. In practice, I don't
believe that this will take very many shifts because we compare the most
loaded slaves to the least first so we should skip most of the
Hopefully all that makes sense. This implementation is certainly more
aggressive about balancing (obviously it wasn't doing enough before) but
it shouldn't infinitely migrate hashes...
More information about the dev