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.
-Ben
More information in blueprint:
https://blueprints.launchpad.net/manila/+spec/share-migration
Regards,
--
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-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
