Open Stack

On 04/03/2017 02:24 PM, Tom Barron wrote:
> We're building an NFS frontend onto the CephFS driver and
> are considering the relative merits, for the DHSS=False case,
> of following (1) the lvm driver model, and (2) the generic
> driver model.
>
> With #1 export locations use a configured address in the backend,
> e.g. lvm_share_export_ip and the exporting is done from the
> host itself.
>
> With #2 export locations use address from (typically at least)
> a floating-IP assigned to a service VM.  The service VM must
> be started up externally to manila services themselves -
> e.g. by devstack plugin, tripleo, juju, whatever - prior to
> configuring the backend in manila.conf.
>
> I lean towards #1 because of its relative simplicity, and
> because of its smaller resource footprint in devstack gate, but want
> to make sure that I'm not missing some critical limitations.
> The main limitation that occurs to me is that multiple backends
> of the same type, both DHSS=False - so think of London and Paris
> with the lvm jobs in gate - will typically have the same export
> location IP.  They'll effectively have the same share server
> as long as they run from a manila-share service on a single
> host.  Offhand, that doesn't seem a show-stopper.
>
> Am I missing something important about that limitation, and are
> there other issues that I should think about?

I think either #1 or #2 could work but #1 will be simpler should have a 
smaller resource footprint as you point out.

There's no rule that says that 2 different backends can't share an IP 
address. Manila intentionally hides all concepts of "servers" from end 
users such that it's impossible to predict the IP address of the server 
that will host the share until after the share is created and the export 
location(s) are filled in by the backend. Typically backends fully own 1 
or more IPs and it's just a question of whether the will be 1 export 
location or more, but we left this up to the implementer for maximum 
flexibility.

If 2 backends were to share an IP address then they would need to avoid 
conflicting NFS export locations with some kind of namespacing scheme, 
but a simple directory prefix would be good enough.

While Manila doesn't care about 2 backends potentially sharing an IP, 
you do have to consider how the m-shr services interact with the daemon 
to avoid situations where they fight eachother. I haven't looked into 
the potential issues around sharing a Ganesha instance, but I know that 
the LVM driver, which uses nfs-kernel-server, does have some issues in 
this area which need fixing.

> Thanks,
>
> -- Tom
>
> p.s. When I asked this question on IRC vponmaryov suggested that I look
> at the zfsforlinux driver, which allows for serving shares from the host
> but which also allows for running a share server on a remote host,
> accessible via ssh.  The remote host could be an appliance or a service
> VM.  At the moment I'm leaning in this direction as it allows one to run
> with a simple configuration as in #1 but also allows for deployment with
> multiple backends, each with their own share servers.

What Valeriy was referring to is the ability to run the m-shr service on 
a node other than where the NFS daemon resides. ZFS initially 
implemented this because we were interested in managing potentially 
non-Linux-based ZFS servers (like FreeBSD and Illumos) but we never 
pursued those options due to technical challenges, and we later gave up 
on supporting remote ZFS using SSH altogether.

-Ben