Hi,

I (sysamin of an SME) am currently an exclusive windows 2K user. I am offering you the chanllenge to convert me over to a linux user providing linux can solve my problem (and I sure hope it does) so please accept my challenge

We have Multiple satalite offices and one Head Office. We also have one large branch, which is my main concern here.

I am based at head office and we have hardware VPN's over ADSL to connect the satalites and main branch to head office. There is a central fileserver here which all branches and satalites access for files.

The problem is that all the ADSL connections only have 256k upstreams, so as you can imagine with several VPN lans connected trnasfering files can take ages. This is not so much a problem for occasional file access from satalite offices, but for the main branch, several users could be trying to use the 256k connection at the same time, as we are dealing with large spreadsheets, powerpoints etc it can take 10 - 20 mins to open a file at the branch.

I have already worked out what I want the solution to be, but windows does not seem to offer what I am looking for, so this is where you guys come in.


This is what I want

HEAD = Head office fileserver

BRANCH = Branch office fileserver


I want to physically mirror the fileshare drives on HEAD and BRANCH so that the exact same files are availably locally at both the head office and the branch office.

Here is the twisty bit (as I am aware of basic file replication techniques in windows already)

1) when someone opens a file at the branch office, they open a local copy of the file from the BRANCH server.

2) I want the BRANCH server to tell HEAD server that the file is in use and thus lock the file from editing, so it is locked at both HEAD and BRANCH and only 1 person at any 1 time on the WAN can get R/W access to a file

3) when the user at the branch office has finished editing the file and clicks save, the file is to be saved on BRANCH

4) BRANCH now knows that it has a more up to date version of the file then HEAD, so the file must be kept locked WAN wide for the time being.

5) BRANCH now background transfers the file over to HEAD (so speed is no longer important) so that HEAD and BRANCH now once again have identical copies of the file.

6) Now that the files are up to date on both servers BRANCH can tell HEAD its ok to unlock the file now.

The same would happen the other way arround if someone edited a file at head office where HEAD would lock the file wan wide, background transfer it over and then unlock it again




So.... come on guys .... is linux the man for the job?

Thanks for taking the time to read this, I look forward to your responses

Luke

I'll have a go at it:

1.) Set-up an OpenVPN connection across the WAN between HEAD and BRANCH offices.
2.) Install Samba on the HEAD fileserver with locks and/or oplocks enabled
3.) Install both Samba AND NFS servers on the BRANCH server
4.) Mount an NFS shared drive from the BRANCH NFS server onto the HEAD Samba fileserver and use that as the main shared folder.
5.) Configure Samba on the BRANCH server to use the NFS shared drive as it's main shared folder as well.

OpenVPN may speed-up the WAN link a bit with compression enabled (I'm using an OpenVPN tunnel all the way to Asia and it works quite well speed-wise).

NFS being a *faster protocol than SMB (at least from my experience, esp. over UDP) would be the better choice over the WAN link. Although this could also be done using rsync, I'm just not sure how it would work when file locking needs to be managed by the HEAD Samba fileserver at all times. If someone else here has an alternate solution using rsync, I think that would be the near-ideal.


*I did a 650mb iso transfer over my LAN to my fileserver running both Samba and NFS. Here are the transfer time results:

SMB: 2min 3sec
NFS: 1min 18sec

I'd imagine I could get even better results with NFS if I tweak it away from the defaults.

Hi jymbo,

Thanks for replying.

Unfortunatly as stated I am not a linux user, so what your saying doesn't mean much to me.

Speeding up the VPN is not going to be a great benefit as even if a protocol could double the speed of the transfer it still wouldn't be enough. We have 256k upload when in reality we ned about 2Meg minimum

If you could explain your answer regarding Samba/NFS I would apreciate it

Regards

Luke

Sorry 'about that...I formatted my post to get some feedback from the other network gurus here. Anyway, let me explain...

Samba:NFS: My idea is roughly this: 2 Samba fileservers sharing one common NFS drive, with the HEAD Samba fileserver controlling the file locks.

With NFS, the shared drive would appear at the remote end as a local filesystem, and then Samba would take care of making that filesystem available to the Windows clients.

Anyone else is welcome to jump in here and help me out with this.

Hi again jymbo,

so will NFS do the background transfers?

Luke

No. NFS simply provides a network drive that is shared between endpoints. Your ideal solution is to use rsync, which will do the "background" transfers. The only problem I see with rsync is that the fileserver on either end has no means of communicating the file locks. Rsync is ideal for mirroring FTP servers, but if anyone else knows a way to adapt it to Samba shares with the file locking feature you require, then that would be a better solution.

I have a very similar issue with 2 locations. One has sdsl with 1.1mb both ways, the other sdsl with 512k both ways. I have a server running Samba for the file sharing. The VPN is setup over 2 Cisco 1700 Routers. My solution to this problem unfortunately has been to setup a Windows 2000 Terminal Server in my Head Office so that the files are just being transfered locally instead of over the Internet, and they just get a picture of whats happening. If there was a solution like what was described in the first post I would love to be using that instead.

Jymbo I was wondering what kind of connections you have in your locations to be able to do a file transfer of that nature with that speed. Is it that fast because of the OpenVPN system, or because of the NFS, would it have been slower if you were using Samba instead? I have not seen any data or side by side comparison of NFS and Samba, it may just be something I need to do and see what kind of speeds I get.


Thanks

I'm not getting that speed over my VPN, but rather, over LAN. I was just trying to back-up my claim that NFS is faster than SMB. But as Lukemh pointed-out, any speed difference between SMB and NFS is irrelevent over a 256K WAN link.

I guess what I'm trying to visualize here is that by isolating the requests for the files from the Windows clients behind each respsective Samba server, and only using the WAN link for the NFS communications solely between the 2 Samba servers themselves, you can better utilize what little 256K you have (instead of having every Windows users' file requests indiscriminately choking the WAN link). Kind of like a proxy.

Here is some interesting information on a tequnique called WAFS ..... it is _almost_ what I am looking for. My only problem with the WAFS setup is that it only caches the files, so every file has to be requested at least once before it apears on the edge server (Edge server is the term they have given to the server that is in the remote office and holds the cache of the file) Rather then having to request the files first to the cache, i want them to all already be there ...... but like I say its not far off what I am looking for.

http://networking.earthweb.com/netos...le.php/3379391

http://www.commsdesign.com/design_co...cleID=21100084

Thanks

Luke

I have been researching an issue for a client of a similar nature and have come across a product being produced by a company called Signiant. Their product, Mobilize for Enterprise Remote Data Management, was originally created for Nortel Networks to replicate large stores of data, research and source code across their global wide-area network. Signiant was spun off from Nortel specifically to develop and market this as a product.

It might be something worth looking in to.

Cheers!