disadvantages of linux cluster - admin

[Robert G. Brown]

On Wed, 6 Nov 2002, Donald Becker wrote:

> On Wed, 6 Nov 2002, Nicholas Henke wrote:
> > On Wed, 6 Nov 2002 09:11:21 -0500 (EST)
> > "Robert G. Brown" <rgb at phy.duke.edu> wrote:
> > 
> > >   * Shoot your users.  G'wan, admit it, you've thought about it.  They
> > > just clutter up the computing landscape.  Well, OK, so we can't do
> > > that<sigh>.  So user support costs are relatively difficult to
> > > control, especially since it is a well known fact that all the things
> > 
> > As someone who administers > 200 machines, I do not believe I have seen a
> > more accurate statement. Hillarious!
> 
> Support costs are directly tied to the number of different application

Hmmm,

s/not/and/

> configurations, not the number of users.  Google has a single

and I'd then agree.  Although it isn't as funny that way;-) 

Seriously, support costs depend onboth -- not quite bilinearly, but a
complex function that increases monotonically with both.  Each user
takes (statistically) some support time for each application in common
use.  With few, simple, slowly varying applications that may not be a
LOT of average time, but it is there and eats some FTE, per user.

Some applications are complex (and/or semi-broken), and the average time
per user can be significant, so doubling the number of users of the
application may be a real hit on sysadmin time.

Then there is user turnover, where supporting users learning to do even
simple tasks generates work over and over.  Every year we get a new dose
of users in the form of incoming students (and staff, postdocs and
faculty, to a lesser extent), and every year our systems folks are
hammered by the same old questions on the same old applications to get
them going.  We have a website page with "why folks get KLEZ and how
KLEZ forges headers" on it because this was FAQ.  No one finds it and
reads it on their own, of course, but now our sysadmins can refer people
to the page rather than block copy in a tedious explanation for why the
mail they just received from somebody's AV program doesn't mean that
they have KLEZ but that somebody they know (who uses
Windows/Explorer/Outlook) does.

It is also common for just a handful of "squeaky wheel" users (old and
new) to consume 80% of the energies spent by our sysadmins on support of
all kinds!  Our sysadmins have been known to metaphorically hide under
desks when certain individuals come looking for help.  Again.  Today.

It is rare, though, that one can double the number of users of even a
simple application and not double the AVERAGE amount of time required to
teach newbies among that base to use it, teach old hands to deal with
the latest changes, teach everybody to RTFM, and deal with your users
suffering from personality disorders of all the various kinds who bug
you about the application just because they can (you're paid to "take
it", right?:-)

The user support problem is nontrivial and I wasn't kidding above --
user support in a LAN environment (with lots of applications run in many
different ways) doesn't scale worth a damn (the way many sysadmin tasks
can be made to) because a significant fraction of all users in a given
random pool are constitutionally incapable of finding or reading
documentation on their own.  Hell, they're incapable of reading
documentation and using it to learn an application if you print it out
for them and deposit it in their lap along with a teaching videotape.
In a few cases they are not capable of finding their own rears with both
hands and a map.  

Some people simply have to be tutored to learn to use certain tools, and
others have, well, personality disorders and seem to relish the idea of
demanding support instead of coping on their own.  If you like, users
are every bit as complex as applications and it is the interface between
all this complexity that is the trouble.  It destroys the very notion of
scalable user support -- you can invest lots of energy in "collective"
support mechanisms like interactive help or online documentation (and we
have) and sometimes it helps a bit, but you can't make all the damn
horses drink.

You can only shoot them.

   rgb

Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu