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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
