<div dir="ltr"><span id="goog_1644131972"></span><span id="goog_1644131973"></span><a href="/"></a>Motonobu-san,<div><br></div><div style>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.</div>

<div style><br></div><div style>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 <a href="https://blueprints.launchpad.net/swift/+spec/dedicated-replication-network">dedicated replication network</a> feature adds variety that I'll try to describe.</div>

<div style><br></div><div style>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.</div>

<div style><br></div><div style>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.</div>

<div style><br></div><div style>So, we will have 2 'levels' of regions proximity which affect proxy-server behavior:</div><div style>* connected 'replication' networks -- in this case proxy-server can only read from 'local' region's storage servers</div>

<div style>* connected 'storage' and 'replication' networks -- in this case proxy-server can read from both 'local' and 'foreign' region</div><div style><br></div><div style>I supppose, the proximity level or type should be a configuration value.</div>

<div style><br></div><div style>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.</div>

<div style><br></div><div style>--</div><div style>Best regards,</div><div style>Oleg Gelbukh</div><div style>Sr. IT engineer,</div><div style>Mirantis Inc.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">

On Fri, Jan 25, 2013 at 5:29 PM, Motonobu Ichimura <span dir="ltr"><<a href="mailto:motonobu@gmail.com" target="_blank">motonobu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div><div><div>Hi, Oleg-san<br><br></div>Thank you for your feedback. <br>We'll check your new design.<br><br></div>Our idea is adding concept of  distance among regions so that Swift proxy can sort nodes by proximity and have<br>


</div><div>more flexibility rather than distinguish "local" and "remote" regions, I think. <br></div><div><br></div><div>so, discussion points are<br><br></div><div>1. Can this idea be acceptable?<br>

</div>
<div>2. Can we assume that region number has some rules to calcurate proximity?<br><br></div><div>Any suggestions would be greatly appriciated.<br></div><div><br>--<br></div><div>Best Regards,<br></div><div>Motonobu "famao" Ichimura<br>


<br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">2013/1/25 Oleg Gelbukh <span dir="ltr"><<a href="mailto:ogelbukh@mirantis.com" target="_blank">ogelbukh@mirantis.com</a>></span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Yuzawa,<div><br></div><div>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:</div>




<div><a href="https://docs.google.com/document/d/1ZfP7712PebhitNM_VuOUL1DV5gXEEbHZOBkwyX8PBE4/edit" target="_blank">https://docs.google.com/document/d/1ZfP7712PebhitNM_VuOUL1DV5gXEEbHZOBkwyX8PBE4/edit</a><br></div><div><br>


</div>

<div>--</div><div>Best regards,<br>Oleg</div><div>Mirantis, Inc.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div>On Fri, Jan 25, 2013 at 1:36 PM, YUZAWA Takahiko <span dir="ltr"><<a href="mailto:yuzawataka@intellilink.co.jp" target="_blank">yuzawataka@intellilink.co.jp</a>></span> wrote:<br>




</div><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
I have an interest in geo-distributed cluster of Swift, such as those<br>
told in the following bluenotes.<br>
<br>
 <a href="https://blueprints.launchpad.net/swift/+spec/proxy-affinity" target="_blank">https://blueprints.launchpad.net/swift/+spec/proxy-affinity</a><br>
 <a href="https://blueprints.launchpad.net/swift/+spec/region-tier" target="_blank">https://blueprints.launchpad.net/swift/+spec/region-tier</a><br>
<br>
And I wrote a design note about geo-distributed Swift.<br>
<br>
 <a href="https://docs.google.com/document/d/1E-kCL4Z1JLO9nHm8y7k-U2xozm1QWvTztlEQH0l76Qg/edit" target="_blank">https://docs.google.com/document/d/1E-kCL4Z1JLO9nHm8y7k-U2xozm1QWvTztlEQH0l76Qg/edit</a><br>
<br>
This note is based on an implemantation of multi-site Swift in Colony<br>
project.<br>
<br>
 <a href="http://www.slideshare.net/famao/colony-foropenstacksummit" target="_blank">http://www.slideshare.net/famao/colony-foropenstacksummit</a><br>
<br>
Please give me your comments.<br>
<br>
--<br>
Best regards,<br>
YUZAWA Takahiko<br>
NTTDATA INTELLILINK<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div></div><br></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>