[OpenAFS] AFS design question: implementing AFS over a highly-distributed, low-bandwidth network

[Derrick Brashear]

I can surmise how with incremental releases and a few other AFS
features you might have an optimized system for doing something close
to, but not exactly "failing over" a volume to a different site if the
primary user moves, but you'd need a web form or a script someone
would have to invoke to work it, and you'd want enough space at each
site to hold any data you might ever want to be resident there, even
if it's not now.

It might well be overkill.


On Thu, Jan 15, 2009 at 2:03 PM, Chaz Chandler <clc31@inbox.com> wrote:
> Hello all!
>
> I am attempting to implement OpenAFS across a VPN with limited bandwidth between sites but relatively mobile users who expect to have their data available (and writable) at whichever site they are currently located.
>
> The issue I am running up against is how to organize the AFS volume structure so that things like user home dirs, collaboration/group dirs, and writable system items (like a Windows profile, for instance) are optimally maintained in AFS.
>
> The set-up is:
> 1) Each site has an OpenAFS server (each with vl, pt, bu, vol, fileservers & salvager).  Currently, v1.4.8 on Linux 2.6.
> 2) Clients computers are a mix of Windows XP, OpenBSD, and Linux.  1.5 clients for windows, 1.4 clients for Linux, and native openbsd clients.
> 3) All sites are connected in a full mesh VPN (max of about 30KB/s for each link)
> 4) There's about 600GB of data at the moment.  Although most of it doesn't need to be writable most of the time, things that are frequently written are not currently segregated from static or infrequently-written files/dirs.  Perhaps only a few gigs change on a weekly basis.
> 5) Users move from site to site, but once there usually spend several weeks.  However, two sites are physically very close and users move between them more frequently (sometimes daily) although the link bandwidth is the same as the others.
> 6) We have a pretty standard AFS volume layout: separate volumes for each user, a few large volumes with relatively static content, a few volumes for groups to share.
> 7) Currently, volume releases are done manually.
> 8) When a user changes locations for a long stretch, we move their R/W user volume to the new location (electronically, not physically), a process which is labor- and time-intensive and usually has at least one snafu along the way.
> 9) We have been unable to come up with a working implementation of roaming windows profiles on AFS.
>
> I'm seeking recommendations on:
> 1) How others have set up a regular release schedule to keep a large amount of data synced over a slow network (custom scripts, I assume, but is there a repository of these things and what are the general mechanics and best practices here?)
> 2) What sort of volume layout would one recommend, and how should frequently-updated data be stored?  Take, for instance, three examples:
> - A software repository: large volume with relatively static contents, occasionally has large additions or subtractions when a new piece of software is added or an old one removed.  Ideally, these updates should be able to be accomplished from any location.  Users don't need to write to it, but may need to read from it frequently at LAN speeds.
> - A collaboration dir: several users read and write a small amount (10s of MBs) on a daily basis from different locations simultaneously, but they expect LAN-type performance.
> - A user dir: large amounts of data updated from a single location, but user may move to any other site at any time, potentially with up to a day of transit time in which a volume could be moved to the destination site.
> 3) Any concrete recommendations on how to properly implement windows integration with AFS (especially folder redirection and roaming profiles on AFS).  Yes, I've read the '04 and '05 best practices, however they are now quite old and did not work for me.
>
> I've been lurking on this list for a while now and have come to the conclusion that while there are a few very knowledgeable and experienced folks in the AFS community, there are not any good, current, and comprehensive AFS information repositories out there.  The list archives are the best option, but I find them almost impossible to use unless I know the exact phrase I'm looking for.  Is there something I'm missing?
>
> Cheers,
> -Chaz
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>



-- 
Derrick