openstack team mailing list archive

[David Hadas <davidh@xxxxxxxxxxxxxxxxxx>]

This discussion of geo-distributed Swift is of great interest to us as 
well. Yet, based on our analysis, the proposed ring of ring seem to not 
meet a basic requirement that we see.

One of the basic disadvantages (and advantages) of the consistent 
hashing at the core of the Swift Ring concept is that it takes control 
over the placement of objects. As long as one considers a fairly unified 
cluster - and does not care which object is placed where in that 
cluster, consistent hashing does a great job.

However, in the case of geo-distributed Swift, many customers do care 
and need control over the placement decision - hence making the use of 
consistent hashing to decide where an object should be placed will not 
do. We actually believe that placement decisions can be made in 
the resolution of containers - not individual objects. Hence, container 
sync seems like a reasonable starting point.

We plan to contribute improvements to container sync, making it a more 
attractive, scalable, and easier to use replication mechanism such that 
it can serve as a basis of a placement aware system controlling where 
replicas reside in a geo-distributed Swift. It would be great if the the 
community align on the need to offer control over placement, between geo 
distributed sites, but if this is not the case, we need to find a way 
to accommodate the different requirements without complicating the design.

Regards,
David Hadas

--
DH



Regards,
David Hadas
IBM Research Labs, Haifa