<div dir="ltr">Sorry I should've been a little more verbose in my previous answers.<div><br></div><div>I don't have anything implemented yet. I'm only looking at designing the solutions. All slideware so far :-). </div>
<div><br></div><div>We develop a filesystem backed by object stores including Openstack Swift. We'd like to work with or without Keystone. Some customers we have use their own auth mechanisms (that are based off Swiftauth). Yes, we could make it mandatory to use Keystone if it comes to it. But wanted to know of options if someone doesn't have (or doesn't want to) use Keystone.</div>
<div><br></div><div>My conclusion was largely to categorize the options; hence I said that it had to be some sort of DNS resolution or using multiple endpoints. You point out that using load balancers with region specific affinities could be another approach. This is great because as far as possible, we'd like to use a single endpoint. We don't deploy our software on the object store itself. We can only make recommendations (best practices) about what to do when using our filesystem. We can mention some of these options to potential customers.</div>
<div><br></div><div>Thanks for all your inputs folks.</div><div><br></div><div>-Shri</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 24, 2014 at 1:55 PM, Adam Lawson <span dir="ltr"><<a href="mailto:alawson@aqorn.com" target="_blank">alawson@aqorn.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">We did load balancers in each logical region with affinity set on the proxies per region. We use Keystone and I'm curious why you aren't but that's not the end-all, just curious. You can control replication behavior after storage policies are implemented (Juno or pre-Juno) but what you want to do is definitely possible.<div>
<br></div><div>Following up on my friend Kuo's question, what <i>is</i> your auth method?</div><div><br></div><div>FYI, you have a myriad of options (not just two), but it seems you're seeking public DNS approaches as opposed to deploying your own front-end?</div>
</div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><div><font><div style="font-family:arial;font-size:small"><b><i><br>Adam Lawson</i></b></div><div><font><font color="#666666" size="1"><div style="font-family:arial;font-size:small">
AQORN, Inc.</div><div style="font-family:arial;font-size:small">427 North Tatnall Street</div><div style="font-family:arial;font-size:small">Ste. 58461</div><div style="font-family:arial;font-size:small">Wilmington, Delaware 19801-2230</div>
<div style="font-family:arial;font-size:small">Toll-free: (844) 4-AQORN-NOW ext. 702</div><div style="font-family:arial;font-size:small">Int'l: <a href="tel:%2B1-302-268-6914%20ext.%20702" value="+13022686914" target="_blank">+1-302-268-6914 ext. 702</a></div>
</font></font><span style="color:rgb(102,102,102);font-family:arial;font-size:small">Cell: <a href="tel:%2B1-916-990-1226" value="+19169901226" target="_blank">+1-916-990-1226</a></span></div>
</font></div><div style="font-family:arial;font-size:small"><img src="http://www.aqorn.com/images/logo.png" width="96" height="39"><br></div></div></div><div><div class="h5">
<br><br><div class="gmail_quote">On Tue, Jun 24, 2014 at 12:36 PM, Shrinand Javadekar <span dir="ltr"><<a href="mailto:shrinand@maginatics.com" target="_blank">shrinand@maginatics.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So I believe, there are largely two options:<br>
<br>
1) DNS Magic<br>
2) Separate endpoints for separate regions.<br>
<br>
Thanks everyone!<br>
<div><div><br>
On Mon, Jun 23, 2014 at 8:58 PM, Michael Gale <<a href="mailto:gale.michael@gmail.com" target="_blank">gale.michael@gmail.com</a>> wrote:<br>
> One more thing, do you read:<br>
> <a href="https://swiftstack.com/blog/2012/09/16/globally-distributed-openstack-swift-cluster/" target="_blank">https://swiftstack.com/blog/2012/09/16/globally-distributed-openstack-swift-cluster/</a><br>
><br>
><br>
> On Mon, Jun 23, 2014 at 9:57 PM, Michael Gale <<a href="mailto:gale.michael@gmail.com" target="_blank">gale.michael@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Hello,<br>
>><br>
>> How are you planning to replicate data between regions? You said you<br>
>> don't want container-sync.<br>
>><br>
>> Also Swift offers read affinity and write affinity, I believe this is<br>
>> setup on the Swift proxy. The affinity settings allow the proxy servers to<br>
>> restrict read and write requests to local resources. The proxy server<br>
>> endpoints are usually handled out by keystone.<br>
>><br>
>> If you are not using keystone then if it up to you to choose a service<br>
>> discovery method:<br>
>><br>
>> Geo-DNS<br>
>> Anycast IP address<br>
>> Unique DNS name per location<br>
>> etc<br>
>><br>
>> Michael<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> On Mon, Jun 23, 2014 at 9:29 PM, Shrinand Javadekar<br>
>> <<a href="mailto:shrinand@maginatics.com" target="_blank">shrinand@maginatics.com</a>> wrote:<br>
>>><br>
>>> I don't plan to use Keystone at all.<br>
>>><br>
>>> On Mon, Jun 23, 2014 at 8:13 PM, Kuo Hugo <<a href="mailto:tonytkdk@gmail.com" target="_blank">tonytkdk@gmail.com</a>> wrote:<br>
>>> > Do you plan to have two keystone servers in each region or single<br>
>>> > keystone<br>
>>> > server for both east/west coast Swift proxy?<br>
>>> ><br>
>>> > 1. Geo-DNS + single Swift region endpoint in keystone<br>
>>> > 2. Geo-DNS for Keystone servers and each Keystone server returns the<br>
>>> > local<br>
>>> > Swift endpoint.<br>
>>> > 3. Let user to switch which region of Swift endpoint would they like to<br>
>>> > use.<br>
>>> ><br>
>>> ><br>
>>> > Hope it help<br>
>>> ><br>
>>> ><br>
>>> > 2014-06-24 8:38 GMT+08:00 Shrinand Javadekar <<a href="mailto:shrinand@maginatics.com" target="_blank">shrinand@maginatics.com</a>>:<br>
>>> >><br>
>>> >> Hi,<br>
>>> >><br>
>>> >> I am trying to understand the notion of "regions" in Swift. To start<br>
>>> >> with, it's kinda confusing that the notion of "region" in Keystone is<br>
>>> >> not exactly the same as that of Swift. So I could authenticate with<br>
>>> >> Keystone, get a Swift endpoint for a region (Keystone's notion of a<br>
>>> >> region) and write/read data. That could then possibly translate to<br>
>>> >> data writes/reads from another region (Swift's notion of a region).<br>
>>> >><br>
>>> >> So, as per the example in [1], let's say I have two regions: SF and<br>
>>> >> NYC. I would like the have clients write to the most local region. How<br>
>>> >> do I achieve this? I am *not* looking to use container-sync.<br>
>>> >><br>
>>> >> I had a quick word about this on the #openstack-swift irc channel.<br>
>>> >> Asking over email for better clarity and more details. I believe the<br>
>>> >> way to go about this would be:<br>
>>> >><br>
>>> >> (1) Have two Swift proxy servers in each region. Configure DNS such<br>
>>> >> that the domain name of the Swift proxy server resolves to the<br>
>>> >> "closest" node.<br>
>>> >><br>
>>> >> Each of these proxy servers will be configured with read/write<br>
>>> >> affinity to object servers in its region.<br>
>>> >><br>
>>> >> This is great because it means I only have to use one endpoint.<br>
>>> >><br>
>>> >> (2) Have two Swift proxy servers in each region with separate IPs.<br>
>>> >> Inform clients about the closest endpoints and let clients write to<br>
>>> >> the correct proxy servers. If they make a mistake, data can still get<br>
>>> >> written to the in-correct node.<br>
>>> >><br>
>>> >> Any other way? Is there a way to query the available regions (say a<br>
>>> >> latency test) and use the one which is fastest to reach?<br>
>>> >><br>
>>> >> Thanks in advance.<br>
>>> >> -Shri<br>
>>> >><br>
>>> >> _______________________________________________<br>
>>> >> Mailing list:<br>
>>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
>>> >> Post to : <a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a><br>
>>> >> Unsubscribe :<br>
>>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
>>> ><br>
>>> ><br>
>>><br>
>>> _______________________________________________<br>
>>> Mailing list:<br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
>>> Post to : <a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a><br>
>>> Unsubscribe :<br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>><br>
>> “We, the unwilling, led by the unknowing, are doing the impossible for the<br>
>> ungrateful. We have done so much, for so long, with so little, we are now<br>
>> qualified to do anything with nothing.”<br>
>><br>
>> ― Konstantin Josef Jireček<br>
><br>
><br>
><br>
><br>
> --<br>
><br>
> “We, the unwilling, led by the unknowing, are doing the impossible for the<br>
> ungrateful. We have done so much, for so long, with so little, we are now<br>
> qualified to do anything with nothing.”<br>
><br>
> ― Konstantin Josef Jireček<br>
<br>
_______________________________________________<br>
Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
Post to : <a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a><br>
Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div><br></div>