[OpenAFS] OpenAFS in a production environment

[Lester Barrows]

Hi Sean,

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.

Regards,
Lester Barrows

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.
>
> Thanks!