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
