[Samba] One shared folder to be HA over CIFS to windows clients

David Roid dataroid at gmail.com
Fri Jan 7 21:05:23 MST 2011


I think what you really need is clusterd file system..

2011/1/8 Emiliano Bonassi <benazhack at gmail.com>

> Hi,
> i'm Emiliano this is my first mail to samba mailing list.
> I have to solve this issue for a company. They need to had a folder, shared
> over CIFS for windows/mac clients, that is always available, also if the
> server who host it hang up or burn.
> I've looked for a lot of solution but i cannot find the right for me.
> Actually the company has two server, all running debian lenny as linux
> distro.
> The first one, a quad core proliant ml350 g5 6tb raid 10, work as primary
> server. On it i've installed vmware server that runs a win2003 r2 guest for
> central authentication,domain policing ecc. It has another role : the
> primary file server, running  a samba server integrated with AD.
> The seconde one, a pentium 4 1,2 tb raid 5, work as secondary server. Like
> the proliant it has vmware server running a BDC w2k3 r2 for fail-over and
> load balancing windows services. Here the file sharing is offered again by
> a
> samba server that shares archive folders.
> Now, how can i have the same shared folder on both file servers?
> I can adopt microsoft technology : use DFS filesystem and FSR replicas.
> Actually, i'm fallen in love with the DFS functionality that permit to
> uniform the namespace of file servers resource using only the name of the
> ad
> domain, but i hate the limits of FSR replicas.
> Hyp:
> - Think that i use DFS and setup that \mydomain\dfs\aaa refer to
> \firstserver\aaa and \secondserver\aaa.
> - aaa on the firstserver and on the secondserver are the same
> - i've setup FSR replicas continuosly between the two shares.
>
> Now, if from one my win client i poll for \mydomain\dfs\aaa , using
> somekind
> of roundrobin\casual algorithm, the DC tell me that \mydomain\dfs\aaa is
> \firstserver\aaa or \secondserver\aaa.
> Suppose, that DC translate the dfs share with the share on the second file
> server, this means that if i open a file gino.txt i'm working on gino.txt
> on
> secondserver.
> So now, before the FSR replica, second server got a version of gino.txt
> newer than first server.
> Now there is a little window of time when if another client ask for the
> same
> dfs share and the same file, it could be possible that DC translate
> \mydomain\dfs\aaa with \firstserver\dfs\aaa and this second windows client
> works a different version of the file.
> Now imagine, that, always before the start of FSR replica, this second
> windows client save a modified version of gino.txt .
> The FSR algorithm take a decision, "i propagate the newer version of file".
> So DFS doesn't work for my situation, i think.
>
> So i ask to you if CTDB samba could work for my problem.
> I think no, because i have to have the same configuration (also shares,
> here
> is the problem, i need only one share) between the two fileservers.
> I'm trying to test this configuration: using LVM create a LV and mirror
> with
> drbd between two fileserver.
> After, put a GFS2 filesystem on them and sharing the filesystem as two
> separate shares on the two file servers.
> Now i think that DFS could work as a peacemaker to decide which host is up
> and translate DFS correctly.
> Suppose that i open gino.txt on \1st\aaa , modify it, and save it. If i
> setup drbd with the sync mode, instantanously, because the copy it's at the
> block level, i have the same file on \2nd\aaa.
> But if i open gino.txt on \1st\aaa and gino.txt \2nd\aaa , who tell to the
> two usesr that the same file is opened on both fileserver?
> From my test seems that only ctdb samba could provide a locking mechanism (
> at the cifs level), but gfs2 doesn't provide nothing like that.
>
> My hope is that someone had the same issue and solved in some way, i know
> that it is long but it's also difficult to explain my doubts and willings.
> Thanks for the reply,
>  Emiliano
>
>
> PS: I've looked for also GlusterFS but not tested, i'm scared that
> operating
> as FUSE there will be some performance break down. I will test, i wish.
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>


More information about the samba mailing list