Subject: Re: [OpenAFS] scalability

[Kim Kimball]

Universities such as UNC have as many users and at least as much disk space.
They had several AFS/UNIX administrators -- not several AFS-only
administrators.

Industries such as UAL (United Airlines) have in excess of ten-thousand
users accessing about 3/4 terabyte (including all replicas) of
business-critical information 24/7, 365/year -- planet wide -- and have 1
1/2 AFS administrators -- who also aren't dedicated solely to AFS.  (I set
this up, I should know.)  UAL won a technology award (2nd place) for the
system.  It works well.

The AFS administration itself, once your admin is up to speed, is not
difficult.  It is, in fact, very easy to administer and scale AFS itself.
Adding a server is easy, adding a client is easy, adding a user is easy, and
lots of the procedures can be automated.

Exclusive use of NT for a system such as you describe _will_ be much more
problematic.  The underlying OS is simply not reliable, relative to UNIX,
and when a fileserver crashes it affects _all_ AFS users accessing
unreplicated data on that server.  With 40000 users this may or may not be a
problem -- it depends on how much of the data being accessed is
unreplicated.  (AFS clients, when data is replicated, will automatically
find another fileserver with the replicated data.)  In any case, however, my
consistent experience is that UNIX fileservers run for hundreds of days or
even for years with no crashes, and I've yet to see NT consistently meet
that standard.  I avoid NT for AFS fileservers.

Some use of NT (AFS clients, e.g.) is not problematic, and can be very
useful in a Wintel environment.

Universities with large numbers of users, regardless of system architecture,
have a user/account management problem, because the user community is so
dynamic:  add lots of users at the beginning of  fall term, delete users as
they graduate, etc.

See above -- universities are already managing this headache with AFS.

Relative to other approaches, AFS makes it very easy to relocate data (can
be done "live"), replicate data (no one notices), update replicated data
(next access gets the new data to the accessing user), retire a server (move
the data to other AFS servers -- which is easy -- while the users are
accessing the data -- the system automatically adjusts to the new
locations -- users are _not_ required to know anything new just because
you've put their home directory on another AFS server ...)

AFS is ideal in numerous ways -- especially for the user community you
describe.

Scalability will not be a problem.

-------------------------------------------------------
Dexter "Kim" Kimball
CCRE, Inc.
14421 N. County Rd. 25E (Swanson Ranch Road)
PO Box 209
Masonville, CO 80541

        kim@ccre.com
-------------------------------------------------------


> David Bear wrote:
>
> > I'm wondering if anyone has any metrics or 'gut feeling' for how
scalable
> > AFS is on 2 sides.  Side one is technically, how many clients, how much
> > space, etc.  Side 2 is administratively.  I'm interested in comparatives
> > as well: ie how many sys admins does it take to manage 100gigs of AFS
> > space  and 40000 users, versus some NT base solution.  What kind of
> > incremental price points are there?  meaning, 1 afs sysadmin can handle
x
> > gigs and y users, 2 afs sysadmin can handle n*x gigs and m*y users --
etc,
> > versus doing the same thing for an NT based network.
> >
> > Thanks for any input.
> >
> > --
> > David Bear
> > College of Public Programs/ASU
> > 480-965-8257
> > ...the way is like water, going where nobody wants it to go