[ovs-dev] [PATCH] bonding: Balance bond slaves based on ratio.

Jesse Gross 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 
intermediate steps.

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...

Jesse




More information about the dev mailing list