[Openstack] [Swift] Allowing clients to write to separate regions

Adam Lawson alawson at aqorn.com
Tue Jun 24 20:55:18 UTC 2014


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 <
shrinand at 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.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
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140624/59133194/attachment.html>


More information about the Openstack mailing list