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" <[email protected]> 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 >> <[email protected]> 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 : [email protected] >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
