On Wed, 18 May 2011 12:05:15 +0200 Stanisław Kamiński <[email protected]> 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 [email protected] _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
