[Samba] Ideas for distributed Samba servers

[Nico Kadel-Garcia]

On Sat, Apr 10, 2010 at 1:14 PM, Eric Shubert <ejs at shubes.net> wrote:
> Robert LeBlanc wrote:
>>
>> I'm trying to think about how to setup a Samba system and would like to
>> pick
>> the brains of some experts. We are looking up put a large amount of
>> storage
>> ~75TB in a central data center. We have some remote (ok, not remote, but
>> across slower links, ok if you consider several hundred clients over 1Gb
>> to
>> be slow) locations that we would like to set up samba servers that 'cache'
>> the file system and serve it up to the clients in the building and sync
>> with
>> the main data center storage. The idea is have a couple of TB that are
>> located in the building that serve up the Samba share. When a client
>> requests a file, if it's in the local cache it is served up from there, if
>> not then the Samba server grabs the file from the main data center and
>> serves it to the client. When a file is written, something like rsync is
>> used to transfer only difference back to the main data center. The problem
>> is that I'm not sure of a file system that does this. We are using Lustre
>> on
>> our HPC, but this won't do what we want.
>>
>> Any suggestions are welcome.
>>
>> Robert LeBlanc
>> Life Sciences & Undergraduate Education Computer Support
>> Brigham Young University
>
> I'm curious to know what you came up with for this. Care you share?
> TIA.

It's a historically tricky problem, and takes serious thought about
who is allowed to make changes, and how they propagate to remote
locations, and about how synchronization is scheduled.

One of my favorites has become "git". Use local repositories, much as
git is used for the Linux kernel, and submit changes to a central
repository for users who are so authorized. The merging capabilities
are pretty good, and changes can be made locally without committing
them to the central repository.

And by the way, it run on Samba one heck of a lot more efficiently and
effectively than Subversion does.