Open Stack

On 09/17/2018 09:39 AM, Peter Penchev wrote:
> Hi,
> 
> So here's a possibly stupid question - or rather, a series of such :)
> Let's say a company has two (or five, or a hundred) datacenters in
> geographically different locations and wants to deploy OpenStack in both.
> What would be a deployment scenario that would allow relatively easy
> migration (cold, not live) of instances from one datacenter to another?
> 
> My understanding is that for servers located far away from one another
> regions would be a better metaphor than availability zones, if only
> because it would be faster for the various storage, compute, etc.
> services to communicate with each other for the common case of doing
> actions within the same datacenter.  Is this understanding wrong - is it
> considered all right for groups of servers located in far away places to
> be treated as different availability zones in the same cluster?
> 
> If the groups of servers are put in different regions, though, this
> brings me to the real question: how can an instance be migrated across
> regions?  Note that the instance will almost certainly have some
> shared-storage volume attached, and assume (not quite the common case,
> but still) that the underlying shared storage technology can be taught
> about another storage cluster in another location and can transfer
> volumes and snapshots to remote clusters.  From what I've found, there
> are three basic ways:
> 
> - do it pretty much by hand: create snapshots of the volumes used in
>    the underlying storage system, transfer them to the other storage
>    cluster, then tell the Cinder volume driver to manage them, and spawn
>    an instance with the newly-managed newly-transferred volumes

Yes, this is a perfectly reasonable solution. In fact, when I was at 
AT&T, this was basically how we allowed tenants to spin up instances in 
multiple regions: snapshot the instance, it gets stored in the Swift 
storage for the region, tenant starts the instance in a different 
region, and Nova pulls the image from the Swift storage in the other 
region. It's slow the first time it's launched in the new region, of 
course, since the bits need to be pulled from the other region's Swift 
storage, but after that, local image caching speeds things up quite a bit.

This isn't migration, though. Namely, the tenant doesn't keep their 
instance ID, their instance's IP addresses, or anything like that.

I've heard some users care about that stuff, unfortunately, which is why 
we have shelve [offload]. There's absolutely no way to perform a 
cross-region migration that keeps the instance ID and instance IP addresses.

> - use Cinder to backup the volumes from one region, then restore them to
>    the other; if this is combined with a storage-specific Cinder backup
>    driver that knows that "backing up" is "creating a snapshot" and
>    "restoring to the other region" is "transferring that snapshot to the
>    remote storage cluster", it seems to be the easiest way forward (once
>    the Cinder backup driver has been written)

Still won't have the same instance ID and IP address, which is what 
certain users tend to complain about needing with move operations.

> - use Nova's "server image create" command, transfer the resulting
>    Glance image somehow (possibly by downloading it from the Glance
>    storage in one region and simulateneously uploading it to the Glance
>    instance in the other), then spawn an instance off that image

Still won't have the same instance ID and IP address :)

Best,
-jay

> The "server image create" approach seems to be the simplest one,
> although it is a bit hard to imagine how it would work without
> transferring data unnecessarily (the online articles I've seen
> advocating it seem to imply that a Nova instance in a region cannot be
> spawned off a Glance image in another region, so there will need to be
> at least one set of "download the image and upload it to the other
> side", even if the volume-to-image and image-to-volume transfers are
> instantaneous, e.g. using glance-cinderclient).  However, when I tried
> it with a Nova instance backed by a StorPool volume (no ephemeral image
> at all), the Glance image was zero bytes in length and only its metadata
> contained some information about a volume snapshot created at that
> point, so this seems once again to go back to options 1 and 2 for the
> different ways to transfer a Cinder volume or snapshot to the other
> region.  Or have I missed something, is there a way to get the "server
> image create / image download / image create" route to handle volumes
> attached to the instance?
> 
> So... have I missed something else, too, or are these the options for
> transferring a Nova instance between two distant locations?
> 
> Thanks for reading this far, and thanks in advance for your help!
> 
> Best regards,
> Peter
> 
> 
> 
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>