Can CTDB be used to create HA NAS reexporting NFS via Samba?

[Alexander]

Thanks for the explanation, now it's definitely more clear to me.

Using cluster file system is unfortunately not an option due to overall
setup (long story) - Samba is a kind of secondary way of access for our
developers and it's a mandate that data reside on a backend NFS server.

What's interesting that we have one instance where 2 Samba servers are under
DNS Round Robin and sharing the same NFS mounts and we never seen any data
corruption problems even despite the NFS lack of coherency (I got myself
educated on this specific topic during last couple of days and well yeah -
that's a complete disaster by design :) ). To some extent that resembles the
Samba+CTDB in active/active config from the NFS client on Samba behavior
standpoint. Maybe it's just the access pattern that does not cause problems,
in this case it's still worth at least to play with CTDB. However that poses
some risk to the data integrity by design, something which is not desirable
of course.

Ok, thanks again for all the information provided, I'll give it a thorough
try and post back if anything interesting/viable will be achieved.
I'm still open for information, so if anyone has anything to say on the
topic - would be great to hear.

cheers,
Alexander

On Wed, Jan 14, 2009 at 9:02 AM, ronnie sahlberg
<ronniesahlberg at gmail.com>wrote:

> Hi Alexander,
>
> You can do this with CTDB and a ctdb-ified version of samba.
> But there are practical restrictions.
>
> CTDB requires a filesystem that provides a coherent view of the
> filesystem across the nodes that has it mounted.
> NFS has no provisioning of coherence at all, not even across multiple
> clients attached to a single server, and its actually surprising what
> kind of stuff they (the NFS folks) get away with and why there is not
> a lot more data corruption than actually occurs with nfs.
>
> The only way to workaround these coherency issues within NFS is to
> limit yourself to only use CTDB/Samba to build a pure ip failover kind
> of cluster.
> I.e. Two nodes  both mapping the same "backend cluster filesystem" as
> an NFS share off a backend NFS server
> then a two node CTDB/Samba cluster which has one single "public ip"
> defined. And then re-export the share through samba.
> All clients attached to the public ip only so that only one of the
> nodes are serving data/metadata at a time.
>
>
> Only one of the two nodes would host that specific public ip at a time
> and you would essentially have a active/passive failover solution.
> CTDB/Samba would be a bit overkill for this situation and you would
> probably be better off using heartbeat or something similar instead to
> build your active/passive failover "cluster".
>
>
>
> In short, its technically possible to use NFS as the backend
> filesystem for CTDB/Samba but you dont want to do it.
>
>
> Why dont you try one of the available cluster filesystems that comes
> with linux instead and build a proper cluster?
> Something like GFS, GFS2, PVFS, ... you name them they are too many to
> count...
>
> For production use, there are commercial offerings available too.
>
>
>
>
>
> On Tue, Jan 13, 2009 at 11:57 PM, Alexander <forsmbg at googlemail.com>
> wrote:
> > Well, ok, I get it, thanks for the clarification, Volker.
> > But I think that anyway it sounds good enough to try it out, how much of
> the
> > availability it can bring.
> >
> > Have you anything to say about the main question, NFS being reexported in
> > this setup? Will it work or it's hard to say or something?
> >
> > Thanks,
> > Alexander
> >
> >
> > On Tue, Jan 13, 2009 at 3:52 PM, Volker Lendecke
> > <Volker.Lendecke at sernet.de>wrote:
> >
> >> On Tue, Jan 13, 2009 at 03:34:35PM +0300, Alexander wrote:
> >> > potential for production use. And looking at its features like that
> >> gentle
> >> > TCP session takeover and everything - it looks like a solution for a
> >> [kind
> >> > of] true non-stop fileserver.
> >>
> >> No. Ctdb can't do TCP session failover. Ctdb has
> >> capabilities to trigger the client to very quickly reconnect
> >> under all circumstances. But the client will be able to tell
> >> that a node failed.
> >>
> >> With SMB2 there will be support for so-called durable file
> >> handles which make the client OS completely hide a failover
> >> from the client applications. But that's not there yet in
> >> Samba.
> >>
> >> Volker
> >>
> >
>