===========================
Bond assignment strategies
===========================

Bonds should be assigned to aggregators in a way that fulfils the
partner's business requirements. For example, a partner with three
aggregators who wants to handle a single failure at a time will have a
different strategy than a partner who wants a spare aggregator for every
primary aggregator.

Grouping bonds by maximum throughput
-------------------------------------

When assigning bonds to aggregators, the maximum throughput of the bonds
should be considered. This is because the main resource use on
aggregators scales with traffic throughput, not with number of bonds.

For example, suppose a partner has the following bonds:

#. 50 Mbps + 50 Mbps legs = 100 Mbps total
#. 25 + 25 Mbps legs = 50 Mbps total
#. 20 + 20 Mbps legs = 40 Mbps total
#. 5 + 5 Mbps legs = 10 Mbps total

When splitting the bonds into two groups, a simple assignment might put
bonds 1 and 2 together and bond 3 and 4 together. However, this would
distribute throughput poorly—the maximum throughput of the first group
would be 150 Mbps, and the maximum throughput of the second group would
be 50 Mbps. It would be better to put bond 1 in its own group and put
bonds 2, 3, and 4 together. This would result in two groups with equal
maximum throughput of 100 Mbps.

Strategies
-----------

Mixed secondary with uniform assignment
++++++++++++++++++++++++++++++++++++++++

Mixed secondary is a strategy that uses every aggregator as a secondary
for some group of bonds. It is appropriate for partners with three or
more aggregators who want to handle the case where a small proportion-
between 25 and 33%- of the aggregators can fail at once without bonds
going offline. No standby aggregators are needed, but each aggregator
needs to have enough idle CPU to handle the extra bonds that could be
assigned to it if other aggregators fail.

The key strategy of mixed secondary is that for bonds on any given
primary aggregator, the secondary aggregator of those bonds is
configured uniformly over the other aggregators. With this
configuration, if an aggregator fails, its bonds will be assigned to a
variety of other aggregators. The other aggregators will each get a
small additional load. No single aggregator will be assigned a large
number of additional bonds.

|image0|

In the example above, notice the bonds configured with Aggregator A as
their primary (the three bonds at the left side of the image). Their
secondary aggregators are each different—the secondary aggregator of
one bond is Aggregator B, one has Aggregator C, and the third bond has
Aggregator D as its secondary. If Aggregator A fails, Aggs B, C, and D
will each only be assigned one additional bond.

Advantages
^^^^^^^^^^^

-  Aggregator failover rate up to about 33% of aggregators, depending on
   idle CPU
-  Cost effective—no idle aggregators
-  All aggregators host bonds at all times—verifies aggregator
   configurations are correct

Disadvantages
^^^^^^^^^^^^^^

-  Time consuming to configure and maintain—bonds with a shared primary
   aggregator must be configured with a uniform distribution of
   secondary aggregators

Backup pairs with uniform assignment
+++++++++++++++++++++++++++++++++++++

Backup pairs with uniform assignment is appropriate for partners with
only two aggregators, or with many aggregators and high redundancy
requirements where up to half the partner's aggregators can fail without
bonds going offline. In an environment with only two aggregators, it can
be considered a type of mixed secondary with uniform assignment. In this
configuration, aggregators must be kept at 50% or less CPU utilization,
because their load will approximately double when the other aggregator
in the pair fails.

In this strategy, aggregators are considered in pairs. Bonds are
assigned to the pair such that about half the bonds (calculated by
maximum throughput, not raw number of bonds) in the pair have one
aggregator set as their primary and the other aggregator as their
secondary, and the other bonds are set with the reverse—the first
aggregator as their secondary and the other as their primary. If one
aggregator in the pair fails, all its bonds will be assigned to the
other aggregator.

 

|image1|

Advantages
^^^^^^^^^^^

-  Highly redundant—handles 50% aggregator failover rate
-  Easy to configure
-  All aggregators host bonds at all times—verifies aggregator
   configurations are correct

Disadvantages
^^^^^^^^^^^^^^

-  Expensive—all aggregators must have at least 50% CPU idle

Single hot standby
+++++++++++++++++++

Single hot standby is appropriate for partners with three or more
aggregators, where one aggregator can be left with no bonds normally
assigned. All bonds are configured with the standby aggregator as their
secondary agg. In this configuration, a single aggregator can fail, and
its bonds will be moved to the standby aggregator. If two aggregators
fail, all the bonds from both failed aggregators will be assigned to the
standby aggregator, which may become overloaded.

|image2|

Advantages
^^^^^^^^^^^

-  Cost effective in larger environments
-  Easy to configure—all bonds have the same secondary aggregator
-  No interruption if standby aggregator fails or is removed from
   service

Disadvantages
^^^^^^^^^^^^^^

-  Limited to a single aggregator failure—two aggregators failures at
   the same time can overload the standby agg
-  Possible for standby aggregator configuration to be incorrect,
   resulting in failure when bonds are moved to the agg

Dual hot standby
+++++++++++++++++

Dual hot standby combines elements from single hot standby and mixed
secondary strategies. Two standby aggregators are required, and from any
given primary aggregator, its bonds should have their secondary
aggregators split between each standby agg. This allows up to two
aggregators to fail without overloading the standby aggregators.

|image3|

In the example above, notice the bonds configured with Aggregator A as
their primary (the four bonds at the left side of the image). Of those
bonds, two have Aggregator D as their secondary, and two have Agg E as
their secondary.

Advantages
^^^^^^^^^^^

-  Handles two simulataneous aggregator failures
-  No interruption if standby aggregators fail or are removed from
   service

Disadvantages
^^^^^^^^^^^^^^

-  Cost effective only in large environments
-  Time consuming to configure and maintain—bonds with a shared primary
   aggregator must be configured with different secondary aggregators
-  Possible for standby aggregator configurations to be incorrect,
   resulting in failure when bonds are moved to a standby agg

Backup pairs with hot standby hosts
++++++++++++++++++++++++++++++++++++

Similar to backup pairs with uniform assignment, backup pairs with hot
standby hosts is appropriate for partners with only two aggregators, or
with many aggregators and high redundancy requirements where up to half
the partner's aggregators can fail at the same time without bonds going
offline.

In this strategy, a group of bonds is configured with the same primary
aggregator and the same secondary aggregator. If the primary aggregator
fails, each bond on the aggregator is moved to the secondary aggregator.
The secondary aggregator should have the same CPU as the primary
aggregator so that it is not overloaded when the primary fails.

|image4|

Advantages
^^^^^^^^^^^

-  Highly redundant—handles 50% aggregator failover rate
-  Easy to configure

Disadvantages
^^^^^^^^^^^^^^

-  Expensive—half of the partner's aggregators are idle
-  Possible for standby aggregator configurations to be incorrect,
   resulting in failure when bonds are moved to a standby agg


.. |image0| image:: /attachments/2228269/2392086.png
.. |image1| image:: /attachments/2228269/2392087.png
.. |image2| image:: /attachments/2228269/2392089.png
.. |image3| image:: /attachments/2228269/2392090.png
.. |image4| image:: /attachments/2228269/2392088.png
