[Openstack] [Swift] Allowing clients to write to separate regions
Shrinand Javadekar
shrinand at maginatics.com
Tue Jun 24 19:36:25 UTC 2014
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.michael at 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.michael at 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
>> <shrinand at maginatics.com> wrote:
>>>
>>> I don't plan to use Keystone at all.
>>>
>>> On Mon, Jun 23, 2014 at 8:13 PM, Kuo Hugo <tonytkdk at 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 <shrinand at 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 at 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 at 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
More information about the Openstack
mailing list