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.
Following up on my friend Kuo's question, what *is* your auth method? 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? *Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 702 Int'l: +1-302-268-6914 ext. 702 Cell: +1-916-990-1226 On Tue, Jun 24, 2014 at 12:36 PM, Shrinand Javadekar < shrin...@maginatics.com> wrote: > So I believe, there are largely two options: > > 1) DNS Magic > 2) Separate endpoints for separate regions. > > Thanks everyone! > > On Mon, Jun 23, 2014 at 8:58 PM, Michael Gale <gale.mich...@gmail.com> > wrote: > > One more thing, do you read: > > > https://swiftstack.com/blog/2012/09/16/globally-distributed-openstack-swift-cluster/ > > > > > > On Mon, Jun 23, 2014 at 9:57 PM, Michael Gale <gale.mich...@gmail.com> > > wrote: > >> > >> Hello, > >> > >> How are you planning to replicate data between regions? You said you > >> don't want container-sync. > >> > >> Also Swift offers read affinity and write affinity, I believe this is > >> setup on the Swift proxy. The affinity settings allow the proxy servers > to > >> restrict read and write requests to local resources. The proxy server > >> endpoints are usually handled out by keystone. > >> > >> If you are not using keystone then if it up to you to choose a service > >> discovery method: > >> > >> Geo-DNS > >> Anycast IP address > >> Unique DNS name per location > >> etc > >> > >> Michael > >> > >> > >> > >> > >> > >> On Mon, Jun 23, 2014 at 9:29 PM, Shrinand Javadekar > >> <shrin...@maginatics.com> wrote: > >>> > >>> I don't plan to use Keystone at all. > >>> > >>> On Mon, Jun 23, 2014 at 8:13 PM, Kuo Hugo <tonyt...@gmail.com> wrote: > >>> > Do you plan to have two keystone servers in each region or single > >>> > keystone > >>> > server for both east/west coast Swift proxy? > >>> > > >>> > 1. Geo-DNS + single Swift region endpoint in keystone > >>> > 2. Geo-DNS for Keystone servers and each Keystone server returns the > >>> > local > >>> > Swift endpoint. > >>> > 3. Let user to switch which region of Swift endpoint would they like > to > >>> > use. > >>> > > >>> > > >>> > Hope it help > >>> > > >>> > > >>> > 2014-06-24 8:38 GMT+08:00 Shrinand Javadekar < > shrin...@maginatics.com>: > >>> >> > >>> >> Hi, > >>> >> > >>> >> I am trying to understand the notion of "regions" in Swift. To start > >>> >> with, it's kinda confusing that the notion of "region" in Keystone > is > >>> >> not exactly the same as that of Swift. So I could authenticate with > >>> >> Keystone, get a Swift endpoint for a region (Keystone's notion of a > >>> >> region) and write/read data. That could then possibly translate to > >>> >> data writes/reads from another region (Swift's notion of a region). > >>> >> > >>> >> So, as per the example in [1], let's say I have two regions: SF and > >>> >> NYC. I would like the have clients write to the most local region. > How > >>> >> do I achieve this? I am *not* looking to use container-sync. > >>> >> > >>> >> I had a quick word about this on the #openstack-swift irc channel. > >>> >> Asking over email for better clarity and more details. I believe the > >>> >> way to go about this would be: > >>> >> > >>> >> (1) Have two Swift proxy servers in each region. Configure DNS such > >>> >> that the domain name of the Swift proxy server resolves to the > >>> >> "closest" node. > >>> >> > >>> >> Each of these proxy servers will be configured with read/write > >>> >> affinity to object servers in its region. > >>> >> > >>> >> This is great because it means I only have to use one endpoint. > >>> >> > >>> >> (2) Have two Swift proxy servers in each region with separate IPs. > >>> >> Inform clients about the closest endpoints and let clients write to > >>> >> the correct proxy servers. If they make a mistake, data can still > get > >>> >> written to the in-correct node. > >>> >> > >>> >> Any other way? Is there a way to query the available regions (say a > >>> >> latency test) and use the one which is fastest to reach? > >>> >> > >>> >> Thanks in advance. > >>> >> -Shri > >>> >> > >>> >> _______________________________________________ > >>> >> Mailing list: > >>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > >>> >> Post to : openstack@lists.openstack.org > >>> >> Unsubscribe : > >>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > >>> > > >>> > > >>> > >>> _______________________________________________ > >>> Mailing list: > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > >>> Post to : openstack@lists.openstack.org > >>> Unsubscribe : > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > >> > >> > >> > >> > >> -- > >> > >> “We, the unwilling, led by the unknowing, are doing the impossible for > the > >> ungrateful. We have done so much, for so long, with so little, we are > now > >> qualified to do anything with nothing.” > >> > >> ― Konstantin Josef Jireček > > > > > > > > > > -- > > > > “We, the unwilling, led by the unknowing, are doing the impossible for > the > > ungrateful. We have done so much, for so long, with so little, we are now > > qualified to do anything with nothing.” > > > > ― Konstantin Josef Jireček > > _______________________________________________ > Mailing list: > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
