[OpenAFS] Re: Doubts about OpenAFS implementation in a company

[Andrew Deason]

On Wed, 18 May 2011 12:05:15 +0200
Stanisław Kamiński <stasheck.fora@gmail.com> wrote:

> - there is single AFS cell covering all the offices
> - every office has it's own db and fileserver (Debian 5/6)

Every office, meaning the 3 in Poland and the 3 in other countries? You
have 6 dbservers? 6 is way more than normal; you would probably be fine
with 3. 3 voting sites, that is; if you turn one into a non-voting clone
like Hartmut said, you may want 4 in total.

> There are two things that are, ahem, not as fast as one would like.
> The worse one is directory traversal - moving between levels of
> directories can take 5-10 seconds (on a workstation with 1 Gbit link
> to AFS server in its location).

"Moving" as in, just "cd"ing? (Which is just looking up and 'stat'ing
dirs) Or moving something between dirs? How many entries are in these
directories?

> The other one is the upload/download speed itself - last time I
> measured, windows client d/u was 2/5 MB/s - I think I can get more
> than that.

On which link? That actually sounds not bad for a 10/1 M link ;)

> As I'm currently making my way through "Managing AFS" by Richard
> Campbell, I'm not yet fully up-to-speed on OpenAFS inner workings and
> such. Right now I only want to ask: is the design of our AFS system
> correct? Or did the guy introducing it made some short-sighted
> projections which don't hold water in current environment (as
> described). I'm talking here about single-cell design - although I'm
> not sure it's easy to move volumes between different cells.

I think the tougher thing when talking about managing multiple cells
usually has to do with replicating RO data, but you haven't mentioned
that yet. Is the only data in the cell stuff like home directories or
group collaboration areas? That is, you don't distribute software or
other RO data via AFS?

Moving data between cells should not be terrible; I'm not sure off the
top of my head how seamlessly it can be done, but at the very least you
can always "vos dump ... | vos restore ..." and update a mountpoint.
Dealing with one big cell tends to be easier for administration, but
smaller cells have better failure compartmentalization, etc.

But in any case, most places tend to have one cell (or a smaller number
of large cells), because there aren't really mature tools to manage
multiple cells together publicly available. So that's certainly not an
uncommon choice.

-- 
Andrew Deason
adeason@sinenomine.net