[OpenAFS] Re: Afs User volume servers in VM's

[Stephan Wiesand]

On Oct 26, 2011, at 16:55 , Andrew Deason wrote:

> On Wed, 26 Oct 2011 07:34:04 -0700 (PDT)
> Booker Bense <bbense@slac.stanford.edu> wrote:
>=20
>> Ideally, you'd like one mini-server per user volume and at least the
>> user would only shoot himself in the foot. I don't think this is
>> particularly practical even with current VM's, but how far can you
>> push it?
>=20
> You don't necessarily need VMs for this; at least, I'm not sure I see
> what benefit you get from separating these via VMs. You can (with I
> think 1.6.0 or a patch to 1.4.x) run these as chrooted fileservers on
> the same box, which would have less overhead.
>=20
> I think you could push it pretty far as far as resource utilization on
> the box goes, since the fileserver can scale down pretty small wrt
> memory usage. However, keep in mind that in the current implementation
> you need one IP per fileserver, which is the resource you may run out =
of
> first unless you have a lot of unused ipv4 space.

Good point. This problem will vanish with IPv6, though.

Containers could be another solution.

Running multiple fileservers on different ports on the same system would =
be even more efficient. Is this possible or could be implemented (in =
theory)?

> This also doesn't help you much if the server is getting bogged down =
due
> to the I/O in servicing the relevant requests, unless you separate the
> user volumes physically.

A single 1.4 fileserver is not able to make a decent contemporary =
fileserver sweat. I don't have much data on 1.6 servers.

> But for the simple (and presumably common) case
> of running out of fileserver threads or the fileserver not being
> mp-scalable, sure.


We're suffering from the same problem as SLAC, and are working around it =
by keeping home directories small enough to make them unusable for use =
from the compute farm and providing extra volumes on fileservers =
dedicated to workgroups. User education tends to be more effective if =
careless use penalizes familiar co-workers only ;-)

What would be a great feature to have is a way to keep the server from =
using more than, say, half of the available threads for a single volume. =
Would this be feasible to implement at all?

--=20
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany