openstack team mailing list archive

[Glen Campbell <glen.campbell@xxxxxxxxxxxxx>]

That's probably the easiest to implement. This would mean that each
deployment of new images would need to be installed in each region.








On 5/17/11 12:47 PM, "Chris Behrens" <chris.behrens@xxxxxxxxxxxxx> wrote:

>
>Ignoring how it is actually implemented, I think we do want copies of
>base images in reach region.  We don't want any sort of outage in one
>region to adversely affect another region.
>
>- Chris
>
>
>On May 17, 2011, at 9:36 AM, Jay Pipes wrote:
>
>> On Tue, May 17, 2011 at 11:59 AM, Glen Campbell
>> <glen.campbell@xxxxxxxxxxxxx> wrote:
>>> If we are going to deploy Glance to support a global deployment of
>>>Nova, would it make sense to have replicas in different regions for
>>>better performance?
>>> Or, to put it another way, is there a recommended way to keep multiple
>>>Glance installations in sync?
>> 
>> Hi Glen!
>> 
>> I think a better idea than having multiple copies of an image in
>> different regions is to do two things:
>> 
>> a) Use a proxy caching server like Varnish or Squid to cache pieces or
>> all of an image in various zones
>> b) Use a highly-available storage system like Swift behind the global
>> Glance server
>> 
>> For a) we need to complete the HTTP 1.1 Cache headers blueprint
>> (https://blueprints.launchpad.net/glance/+spec/caching) and for b) you
>> would simply use the Swift backend, configured appropriately for a
>> large Swift cluster.
>> 
>>> Users doing snapshots/backups, etc., would presumably get better
>>>performance if Glance was local, but how would we keep the base/shared
>>>images in sync?
>> 
>> This is actually something that Rick H and Chris McG are working on.
>> The basic strategy that they came up with was to add a parent ID
>> attribute to the image and for any snapshot image, simply refer to the
>> base image as the snapshot image's parent. The glance client would
>> check for a parent_id that wasn't null and continue streaming the
>> image while it found a parent URI/ID.
>> 
>> For example, let's say you have a "golden image" with the URI:
>> http://glance.example.com/12345. A user creates an instance with this
>> image and some time later, decides to do a snapshot or backup of their
>> running instance. The snapshotting code in the virtualization layer
>> produces what is essentially a differential snapshot, containing only
>> the differing bits of the existing image with the base golden image.
>> This snapshot (typically much smaller than the original image) could
>> be stored in the local (zone-local) Glance server with a call to POST
>> /images. When pushing this snapshot image to the local Glance server,
>> we would set the parent ID to http://glance.example.com/12345.
>> 
>> Let's say at some later time, the user wanted to restore from this
>> backup. The virtualization layer that implemented the restore call
>> would need to stream the backup image from the local Glance server. In
>> doing so, it would use the glance client class' get_image() method.
>> When calling this method, the glance client would first return the
>> snapshot image piece. Noticing the image had a parent ID, it would
>> continue to stream the golden image from the global image Glance
>> server in-line, essentially enabling us to store only the small diff
>> of the snapshot locally while streaming the bulk of the image master
>> from the global Glance server.
>> 
>> I'll let Rick elaborate on the above and correct any mistakes I made
>> in my description. :)
>> 
>> -jay
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>