I have also been thinking of QOS on the interface.
Followup: since QoS is part of linux kernel routing, there's a great
"HOW-TO" doc on "Linux Advanced Routing & Traffic Control" here:
HTML: http://lartc.org/lartc.html
PDF: http://lartc.org/lartc.pdf
..good deep stuff. For bandwidth control, skip to Chap. 9 on "Queueing Disciplines".
Of such docs will be moot after Apple spends 10 man years wrapping all this up
in a pretty little GUI that a 5 year old could navigate, replete with interactively
resizable network valves, drop shadows and shiny buttons. :/
QoS is useful not so much for Rush as it is for file system traffic management,
so that workstation traffic gets immediate attention by the file server over
farm traffic, to decrease perceived 'file server slowness' to interactive users
when the farm is rendering full bore.
Most of you trying to do bandwidth control likely have *large* networks in the
150 - 700 machine range, have NetApps, and are doing traffic control either
at your file server's interfaces, or on your master switch.
It's unlikely anyone needing traffic control will be using a linux file server,
as that box probably melted long ago when you got above 30 machines on your net ;)
But the above docs are, if nothing else, a good intro to the concepts.
I would think the best scenario is where you split the farm and workstation
traffic to separate subnets, and assign them separate interfaces on the
file server, giving priority workstation interface when the farm interface
reaches some high watermark, or when the workstation requests are taking
too long to resolve.
Or if not that, QoS management at the switch would probably be the second choice,
such that any workstation traffic triggers a choke algorithm if contention
for the file server is greater than some percentage of overall bandwidth.
|