Open Stack

Motonobu-san,

The concept of 'distance' between regions used to determine where to go for
replica if 'local' one is missing seems interesting, but definitely needs
some additional thinking on our side. Our design does not assume that
reigon ID is meaningful number, however, that 'distance' semantics can be
added easily enough.

However, before I think about the semantic of distance, it's occured to me
that we have variants of how regions can be connected. The dedicated
replication network<https://blueprints.launchpad.net/swift/+spec/dedicated-replication-network>feature
adds variety that I'll try to describe.

Basically we have 3 networks in Swift cluster: 'public' network, connecting
proxy servers to the world (or to the load-balancer or firewall, which is
more likely), 'storage' network, connecting proxy servers to storage
servers, and 'management' network. 'Storage' network usually use private IP
addresses. Obviously, we need to connect storage networks of 2 regions
(clusters) if we want proxy-servers to be able to read objects from foreign
regions. It seems to be a bad idea to use globally routed IP range for
'storage' network, so we'll likely need a VPN between two 'storage'
networks in two clusters.

With dedicated 'replication' network, we only need connection between
storage servers on the 'replication' network to get the proxy-server
behavior you propose (write locally and let replication move objects to
foreign region destinations). However, if we want proxies to read from
foreign regions, we still need to connect 'storage' networks.

So, we will have 2 'levels' of regions proximity which affect proxy-server
behavior:
* connected 'replication' networks -- in this case proxy-server can only
read from 'local' region's storage servers
* connected 'storage' and 'replication' networks -- in this case
proxy-server can read from both 'local' and 'foreign' region

I supppose, the proximity level or type should be a configuration value.

Sorry for dumping this in such confusing way, I hope to prepare a proper
proposal early in the next week with couple of diagrams for clearer
explanation. Please, correct me if I'm getting something wrong.

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


On Fri, Jan 25, 2013 at 5:29 PM, Motonobu Ichimura <motonobu at gmail.com>wrote:

> Hi, Oleg-san
>
> Thank you for your feedback.
> We'll check your new design.
>
> Our idea is adding concept of  distance among regions so that Swift proxy
> can sort nodes by proximity and have
> more flexibility rather than distinguish "local" and "remote" regions, I
> think.
>
> so, discussion points are
>
> 1. Can this idea be acceptable?
>  2. Can we assume that region number has some rules to calcurate
> proximity?
>
> Any suggestions would be greatly appriciated.
>
> --
> Best Regards,
> Motonobu "famao" Ichimura
>
>
>
> 2013/1/25 Oleg Gelbukh <ogelbukh at mirantis.com>
>
>> Yuzawa,
>>
>> Please note that we've updated the proposal of the region tier in ring,
>> based on feedback from the community. This version assumes that the
>> 'Region' value is a number, which correlates with your proposal. New
>> version of the region tier design can be found here:
>>
>> https://docs.google.com/document/d/1ZfP7712PebhitNM_VuOUL1DV5gXEEbHZOBkwyX8PBE4/edit
>>
>>  --
>> Best regards,
>> Oleg
>> Mirantis, Inc.
>>
>>
>> On Fri, Jan 25, 2013 at 1:36 PM, YUZAWA Takahiko <
>> yuzawataka at intellilink.co.jp> wrote:
>>
>>> Hello,
>>>
>>> I have an interest in geo-distributed cluster of Swift, such as those
>>> told in the following bluenotes.
>>>
>>>  https://blueprints.launchpad.net/swift/+spec/proxy-affinity
>>>  https://blueprints.launchpad.net/swift/+spec/region-tier
>>>
>>> And I wrote a design note about geo-distributed Swift.
>>>
>>>
>>> https://docs.google.com/document/d/1E-kCL4Z1JLO9nHm8y7k-U2xozm1QWvTztlEQH0l76Qg/edit
>>>
>>> This note is based on an implemantation of multi-site Swift in Colony
>>> project.
>>>
>>>  http://www.slideshare.net/famao/colony-foropenstacksummit
>>>
>>> Please give me your comments.
>>>
>>> --
>>> Best regards,
>>> YUZAWA Takahiko
>>> NTTDATA INTELLILINK
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> 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/3921d9af/attachment.html>