Open Stack

Sorry I should've been a little more verbose in my previous answers.

I don't have anything implemented yet. I'm only looking at designing the
solutions. All slideware so far :-).

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.

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.

Thanks for all your inputs folks.

-Shri




On Tue, Jun 24, 2014 at 1:55 PM, Adam Lawson <alawson at aqorn.com> wrote:

> 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/20f43016/attachment.html>