[Gluster-users] Migration path from native Gluster-NFS towards NFS-Ganesha
giuseppe.ragusa at hotmail.com
Tue Jan 17 00:10:29 UTC 2017
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:
>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 ;-)
More information about the Gluster-users