Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150618/4bb281d5/attachment.html>