Thanks, Ben. One somewhat tangential remark inline ...
On 04/03/2017 03:00 PM, Ben Swartzlander wrote: > 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. Yeah, and our dsvm-minimal lvm gate job today uses two lvm backends, London and Paris, each configured with the same value for lvm_share_export_IP, namely that of the devstack HOST_IP. > >> 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 __________________________________________________________________________ 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