On Mon, Jan 16, 2017, at 14:08, Kaleb S. KEITHLEY wrote: > On 01/12/2017 04:36 PM, Giuseppe Ragusa wrote: > > Hi all, > > > > 1) Is it possible (and advisable, in production too) today (3.8.x) to > > configure a GlusterFS based cluster to use NFS-Ganesha (as NFS v3/v4 > > solution) and Samba (as CIFS solution) both controlled by CTDB as a highly > > available *and* load balanced (multiple IPs with DNS round-robin, not > > active/passive) storage solution? (note: I mean *without* using a full > > Pacemaker+Corosync stack) > > It's probably doable. > > The only reason it's not advisable — IMO — is that it's not what we're > doing, and getting help could be pretty hard. > > The Samba team has all the CTDB experience. I've poked them — hopefully > they will respond.
I've already integrated native Gluster-NFS with CTDB using the monitoring solution tracked in: https://bugzilla.redhat.com/show_bug.cgi?id=1371178 From the docs it seems that all the actual NFS HA/LB work (in what you're doing) is done by Ganesha upcalls, but nonetheless all setup hints/script assume that a full Pacemaker+Corosync stack is present, so I should read through all scripts to untangle it from them... I will do this eventually anyway (since Gluster-NFS is deprecated), but I would try to avoid doing this in a hurry and without any guidance from the developers, only to solve stability issues (that's unfortunately the immediate reason why I posted my request for advice on the migration). ;-) > Is there some reason you don't want to use Pacemaker and Corosync? All the reasons lie in the fact that I don't think it's advisable to make oVirt and Pacemaker+Corosync coexist on the same machines (oVirt has it's own PowerManagement which would overlap with Pacemaker fencing, just to name the most obvious problem tha comes to my mind...) If I had a pure storage setup to care for (no hyperconvergence), I would not have thought twice and I would already have a nice Pacemaker-enabled setup > > 2) If the answer to the above question is "yes", is the above above > > mentioned solution capable of coexisting with oVirt in an hyperconverged > > setup (assuming replica 3 etc. etc.)? > > Off hand I can't think of any reason why not. Many thanks for your advice! When I will come to try the integration, I will duly document it and report back for any issue. > > Many thanks in advance to anyone who can answer the above and/or point me > > to any relevant resources/docs. > > > > https://github.com/linux-ha-storage/storhaug is basis for the Common HA > solution for NFS-Ganesha and Samba that GlusterFS-3.10 will be using. > N.B. It's also based on Pacemaker and Corosync. As I already mentioned to some oVirt developers when we met face to face in Italy: oVirt is a nice VMware killer solution, but integrating GlusterFS only to kill VSAN it's too humble a project... ;-) Let's kill also NetApp alltogether while we are at it :-D And no, don't think I dislike Pacemaker+Corosync at all: it's wonderful (and I actually use it alot), but this one seems not its game ;-) Best regards, Giuseppe > -- > > Kaleb _______________________________________________ Gluster-users mailing list [email protected] http://lists.gluster.org/mailman/listinfo/gluster-users
