Open Stack

Caitlin,

These concerns are absolutely valid. Thanks for pointing this out.

Multi-region replicator is a next item in our roadmap, and its design is
not finalized yet. We agree with you that local and foreign replicas should
be handled differently. One of options we're considering for foreign
replicator is a variant of this design with region-specific modifications:
http://wiki.openstack.org/Swift-Improved-Object-Replicator

--
Best regards,
Oleg Gelbukh
Sr. IT engineer,
Mirnatis, Inc.


On Fri, Jan 25, 2013 at 10:12 PM, Caitlin Bestler <
Caitlin.Bestler at nexenta.com> wrote:

> These blueprints and documents are focused almost entirely on how the
> Swift Proxy creates objects.
>
> I think the more critical issue for Swift objects is how Objects are
> replicated in a multi-region environment
> when a copy becomes unavailable.
>
> The cold hard fact here is that inter-region replication is considerably
> more expensive than intra-region
> replication. If you're doing a multi-region cloud obviously you have to do
> both, but I am skeptical that
> a single algorithm can support both with nothing more than a "distance"
> metric.
>
> Some serious questions to apply to any design proposal:
>
> * Is each region supposed to be self-sufficient, in that get requests can
> be fulfilled by a copy within that
>     region even if the links to other regions are temporarily down?
> * What is the tolerance for "eventual consistency" when dealing with
> continental distinces and TBs of new
>     content potentially being created each day?
> * What happens if the same object is updated concurrently in two different
> regions?
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20130125/5349603e/attachment.html>