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@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
