[openstack-dev] [Manila] Network path between admin network and shares
ben at swartzlander.org
Thu Jun 18 04:04:50 UTC 2015
On 06/11/2015 04:52 PM, Rodrigo Barbieri wrote:
> Hello all,
> There has been a lot of discussion around Share Migration lately. This
> feature has two main code paths:
> - Driver Migration: optimized migration of shares from backend A to
> backend B where both backends belong to the same driver vendor. The
> driver is responsible for migrating and just returns a model update
> dictionary with necessary changes to DB entry.
> - Generic Migration: This is the universal fallback for migrating a
> share from backend A to backend B, from any vendor to any vendor. In
> order to do this we have the approach where a machine in the admin
> network mounts both shares (source and destination) and copy the
> files. The problem is that it has been unusual so far in Manila design
> for a machine in the admin network to access shares which are served
> inside the cloud, a network path must exist for this to happen.
> I was able to code this change for the generic driver in the Share
> Migration prototype (https://review.openstack.org/#/c/179791/).
> We are not sure if all driver vendors are able to accomplish this. We
> would like to ask you to reply to this email if you are not able (or
> even not sure) to create a network path from your backend to the admin
> network so we can better think on the feasability of this feature.
I don't think that there will be any issue for drivers that don't handle
share servers -- those driver will have static network configurations
and accessibility between the node responsible for data copying and the
backend can be an exercise for the administrator. The same is true for
drivers that do handle share servers if a flat-network plugin is being
used. Connectivity between the tenant networks and the flat network used
for shares is left to the admin.
The real problem is for driver that handle share servers and create
segmented network interfaces. Those interfaces will usually not be
reachable from the backend network where the data copying node will
usually live. I'm *not* in favor using VMs to bridge this gap. VMs are
not something we can assume to exist in every Manila deployment, and I
would be disappointed if share migration ended up depending on Nova when
the rest of Manila's features don't.
I think we can solve this problem by allowing drivers that handle share
servers to create an additional "admin" network interface for the
purpose of migrations, and providing additional export locations on that
admin network interface. This would require us to create a way to flag
each export location as tenant facing, or admin facing, or both. Also,
drivers would need a second network plugin to supply IP addresses for
this admin network. Fortunately the network plugin could be the same for
all backends because there should only be 1 admin network, so we'd only
need a single new config flag in manila.conf.
The only downside I can think of with this approach is that it consumes
more network resources on the backends and could negatively affect
scalability. Given the high value of migration though, and the lack of a
workable alternative, I'd like to pursue this approach.
> More information in blueprint:
> Rodrigo Barbieri
> Computer Scientist
> Federal University of São Carlos
> +55 (11) 96889 3412
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev