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