Network teaming, what do you need?

[Marius Vollmer]

Hi,

so I had a first go at adding network teaming support to Cockpit:

https://github.com/cockpit-project/cockpit/pull/4571

The current code doesn't expose _any_ configuration settings for a team,
because the defaults are perfect!

At least, that's my working assumption right now. :-)

If you use teams, what settings to do you have to change?  Can you see a
way to improve teamd itself so that you could just use the default
instead?

Thanks!

[Stephen Gallagher]

On 06/16/2016 03:39 AM, Marius Vollmer wrote:
> Hi,
>
> so I had a first go at adding network teaming support to Cockpit:
> https://github.com/cockpit-project/cockpit/pull/4571
>
> The current code doesn't expose _any_ configuration settings for a team,
> because the defaults are perfect!
>
> At least, that's my working assumption right now. :-)
>
> If you use teams, what settings to do you have to change?  Can you see a
> way to improve teamd itself so that you could just use the default
> instead?
>
> Thanks!

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

Unfortunately, this is not a decision that we can realistically make
automatically for the user.

[Marius Vollmer]

Stephen Gallagher  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/htm...
> 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?

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?

[Stephen Gallagher]

On 06/17/2016 06:07 AM, Marius Vollmer wrote:
> Stephen Gallagher  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/htm...
> > 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.