On 06/17/2016 06:07 AM, Marius Vollmer wrote:
Stephen Gallagher <sgallagh(a)redhat.com> writes:
> Well, at minimum it will need to be able to select the teamd runner. This
> fundamentally changes how the team behaves and what it should do when one or
> more interfaces go down.
>
> See
>
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/...
> for details on the different runners.
>
> This is important because the runner in use will definitely depend on the
> use-case. For example, if the most important thing is maximizing throughput (but
> with a higher load on the machine), you will probably want either the
> 'loadbalance' or 'lacp' runner (the 'lacp' runner requires
supporting hardware).
> If your use-case is to use teaming purely for reliability in the face of
> outages, then 'activebackup' where the interfaces each travel on different
paths
> from the others is probably your preference. 'roundrobin' is lower overhead
than
> 'loadbalance' but since it doesn't measure anything can end up in
situations
> where one interface is handling far more of the load than others.
Thanks for the feedback!
Broadcast seems to be fundamentally different from the remaining
runners. Maybe we can have a checkbox for it.
But why would you need to decide between performance and reliability?
What's wrong with using all links all the time?
Not all of the links are going to the same place. I wasn't fully clear when I
said it travels on different paths. It's more likely that you would be dealing
with different geographies.
Let's hypothesize the Netflix case: normally when you connect to Netflix and ask
to play a movie, it will route to the physically nearest
(lowest-latency/highest-bandwidth) streaming server. However, what happens when
that nearest server goes down? (Power outage, someone hits the buried line with
a back-hoe, etc.?)
With activebackup, the behavior would be to willingly sacrifice some of the
performance by switching over to a less-desirable link (maybe one that is
hundreds of miles further away).
As another example, normal throughput would be handled by a 30GigE or
Fiber-channel connection, but the administrator might want to keep a backup
100/1000 mbps ethernet line around as a backup. They *could* opt to use
'loadbalance' in that situation, but that adds considerable (I don't have
numbers handy, but I understand that it's human-measurable for large loads)
overhead as every packet has to be routed to the connection with the lowest load
(and tuning loadbalance is a tricky business). They could also choose
'roundrobin' which has essentially no overhead (it just rotates through the
connections), but this can be unpredictable as you could randomly end up with
more of the large packets being pushed through the tiny pipe while the
high-bandwidth line sits idle.
I guess there is an answer to that, but would that mean that we need
to
flag certain links as "Use only as backup"? It's not a fundamental
change in what the team does, but a change in the role of a port, no?
Well, another thing to consider is nested teaming (Which I'm pretty sure is
available now in NM). In theory, you could set up one team device that uses the
'activebackup' runner to select between two or more devices that are themselves
team devices using 'loadbalance' or 'roundrobin'. This would be useful
for
situations where you wanted to push more bandwidth than a single network port
can manage but also wanted to have an active backup to a different geography.