[OpenAFS] OpenAFS in a production environment
Fri, 12 Aug 2005 15:26:20 -0700
I can't release too many details about how we're using OpenAFS, although I can
say that it's a great tool for sharing data between distant locations.
OpenAFS in general seems fairly stable once you have it configured properly,
although there are some points which I believe are worth considering before
comitting oneself to it.
First, performance in general is not going to be as good as NFS for read/write
data on the local network. With the 1.2 series clients, performance was
actually rather terrible in our configuration for a single client. The 1.3
series seems to have come a long way toward fixing this, although write
performance is still slower than NFSv3. OpenAFS has file locking semantics
which seem to strongly favor reads over writes.
Second, OpenAFS doesn't seem to work very well with NATs. This seems to mostly
be an artifact of it being a UDP-based protocol. If you have a lot of clients
behind NATs, OpenAFS may not be suitable for your use. The developers do not
seem to be interested in a solution for this at the moment, although to be
fair there are a number of other things they are working on.
Third, client support for newer platforms has improved since we started using
it but it isn't perfect yet. OpenAFS seems to just now be stabilizing on the
Linux 2.6 series kernels in the newer 1.3 releases. Older releases of OpenAFS
don't support 2.6 at all with PAGs to my knowledge. I wouldn't recommend
running a pre-release filesystem (or pre-relase anything) on production
systems. OS X support seems good all around, but tends to come out a while
after each new release of the OS.
As for the previously supported platforms, Solaris support seems good enough.
We haven't had any complaints about it yet. We have no HP-UX systems to test
it on, so I can't comment on that. The Linux 2.4 client works as well as any
of the other clients, with big performance improvements coming along in the
1.3 series. The Windows 2k/XP client has definitely come a long way, although
it's not yet ready for our network. The Windows issue is probably due to our
network configuration, and may not apply to you. Windows isn't critical to
our use of AFS though.
Fourth, backups can of course be interesting due to the way OpenAFS stores
files. The included backup system will take some scripting if you want to use
it reasonably. I've been able to make it work well enough, but you might be
better off with a third party backup solution if you don't want to invest a
lot of time in it.
As with any new service, the best thing you can do is test, test, test. I'd
advise making your own test cell to ensure that you're comfortable with the
management interfaces. It's also good to have documented recovery mechanisms
before going forward with an implementation.
On Friday 12 August 2005 14:15, Sean Kelly wrote:
> I've been stalking this mailing list for a few months now while pondering
> the possibility of deploying an AFS setup in my environment. However, while
> reading this list I've not been able to get a firm idea of how stable
> OpenAFS is.
> There seem to be a lot of reports about OpenAFS causing many Linux kernel
> panics, having issues with newer or older kernel versions, random
> configurations, or just instability in general. Is this because OpenAFS
> really is a very sensitive program/service, or is it the standard problem
> of only hearing from those who are having a problem?
> Does OpenAFS work with RHEL AS 4? RHEL AS 3? HP-UX and Solaris?
> I'd be interested in hearing an in depth description of how people are
> using AFS both in commercial and educational environments today and their
> success and failure stories. I realize AFS has been around for a long time
> and do have the _Managing AFS_ book, but I'd be curious if things have
> changed in the post-TransArc era.