Open Stack

Hi David-san, Oleg-san

Now we have several approaches for geo-distributed Swift: ring of rings, 
extended container-sync.
So we would like to clarify our idea. That is to provide geo-distributed 
cluster on based the basic concepts of Swift.

The basic concepts of Swift that we think is following.
* single namespace
* autonomous objects dispersion

Therefore we had not basically touched the backend where objects are 
stored actually (except performance improvement). We have aimed to 
provide geo-distributed Swift by extend proxy-server. Also modification 
of code would be less.

We have concerned that adding abilities ad hoc for geo-distributed 
cluster might make difficult to operate systems,  and make difficult to 
hold the scalability of system.

Any suggestions would be appreciated.

Thank you.

-- 
Best regards,
YUZAWA Takahiko
NTTDATA INTELLILINK

(2013/03/06 15:09), David Hadas wrote:
> (Resending as the prev had a wrong Subject and was not continuing the
> discussion thread - hopefully this will do better :)
>
> 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 thedesign.
>
> Regards,
> David Hadas
>
> --
> DH
>
>
>
> Regards,
> David Hadas
> IBM Research Labs, Haifa
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>