Open Stack

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/205d9488/attachment.html>