Open Stack

Caitlin,

Thanks for your quick response, so ther isnt any way, if a request come
inside DATACENTER 1 and the random mechanism of swift tells to search for
the object on the DATACENTER 2, is no way to avoid it.
What about container sync ?

Regards

On Tue, Dec 6, 2011 at 3:49 PM, Caitlin Bestler <Caitlin.Bestler at nexenta.com
> wrote:

>  Lendro Reox asked:****
>
>
>
> > We're replicating our datacenter in another location (something like
> Amazons east and west coast) , thinking about our applications and****
>
> > our use of Swift, is there any way that we can set up weights for our
> datanodes so if a request enter via for example DATACENTER 1 ,****
>
> >  then we want the main copy of the data being written on a datanode on
> the SAME datacenter o read from the same datacenter, so****
>
> > when we want to read it and comes from a proxy node of the same
> datacenter we dont add delay of the latency between the two datacenters.
> > The moto is "if a request to write or read enters via DATACENTER 1 then
> is served via proxynodes/datanodes located on DATACENTER 1",
> > then the replicas gets copied across zones over both datacenters.****
>
> > Routing the request to especific proxy nodes is easy, but dont know if
> swift has a way to manage this internally too for the datanodes ****
>
> ** **
>
> I don’t see how you would accomplish that with the current Swift
> infrastructure.****
>
> ** **
>
> An object is hashed to a partition, and the ring determines where replicas
> of that partition are stored.****
>
> ** **
>
> What you seem to be suggesting is that when an object is created in region
> X that it should be assigned to partition that is primarily stored in
> region X,****
>
> While if the same object had been created in region Y it would be assigned
> to a partition that is primary stored in region Y.****
>
> ** **
>
> The problem is that “where this object was first created” is not a
> contributor to the hash algorithm, nor could it be since there is no way
> for someone****
>
> trying to get that object to know where it was first created.****
>
> ** **
>
> What I think you are looking for is a solution where you have **two**
> rings, DATACENTER-WEST and DATACENTER-EAST. Both of these rings would have
> ****
>
> an adequate number of replicas to function independently, but would
> asynchronously update each other to provide eventual consistency.****
>
> ** **
>
> That would use more disk space, but avoids making all updates wait for the
> data to be updated at each site.****
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20111206/3024befe/attachment.html>