Open Stack

Hello John,

Thanks for your answers, it really helped me understand some aspects from
swift. We decided to move forward with our PoC.

One additional question regarding Keystone and Swift. We want that the local
users in the same DC hits the local endpoint. In a failure case it should be
possible to hit another endpoint from another DC as well. 
As far as I know Keystone when you have multiple endpoint from the same
service it just provides the one from the top of the list. Should the swift
proxy in a region also be separate endpoint in a different region in
Keystone. So the decision which endpoint to use is by providing the region
to keystone?

Eg. 5 regions in Swift equals 5 regions in keystone for the swift service?

I did some more research and found that the mamcache service used by swift
also saves the auth token.

Thanks in advance!

Cheers
Chris

-----Original Message-----
From: John Dickinson [mailto:me at not.mn] 
Sent: Tuesday, August 09, 2016 00:41
To: Chris <contact at progbau.de>
Cc: Openstack <openstack at lists.openstack.org>
Subject: Re: [Openstack] Swift new starter questions (PoC)

Great to hear that you're looking at Swift. Answers inline...


--John



On 8 Aug 2016, at 7:56, Chris wrote:

> Hello,
>
> We are currently playing with swift and try to find out if it would be
useful for our needs. We would use the latest mitaka release. It would be a
multi-region deployment in around 4-5 different countries/DCs with a total
size of 5 TB and millions of small files. Worst case RTT between two
locations would be 400ms. I came across some questions I want to ask.
>
> 1) As far as I understood Swift returns a 200 OK if the majority of
replicas are written. Is it possible to change this ratio?

For replicas, "quorum" is defined as ((R DIV 2) + 1) when R is odd and (R
DIV 2) when R is even, where "R" is the replica count. For example, for 3
replicas, the quorum is 2. For 4 replicas, the quorum is 2.

It's not possible to change the quorum size, but it is possible to change
the replica count.

> 2) Does the write affinity now includes containers and accounts? Saw a
presentation from the Symantic guys on the Openstack summit where this topic
came up. And the acces time spikes if this information are transferred from
the WAN.

This sounds accurate and is the current state of the system. It's also one
of the known ways the community would like to improve the global cluster
story.

> 2a) If not does it make sense to do some kind of warm up and get the
container and account information saved in memcache for faster access?
Anybody experience at this approach?

That sounds like a fantastic idea.

Note that it's a very good idea to have a separate memcache pool for each
region instead of one pool across all regions.

> 3) Lets say we have 5 regions and a replication factor of 3. When we use
write affinity 12 copies would be written in a local cluster and then in the
background replicated to the other regions? Isn't there a better way and
avoid unnecessary local writes if they would be transferred away anyway?

With 5 regions and 3 replicas, on write the data would be written to 3
locations in the region that received the request. Later (asynchronously)
the replicas would be written to the correct "primary" locations. With 5
regions and 3 replicas, it could mean that the "local" region will not have
any of the primary locations.

> 4) What will happen if the WAN connection to a DC fails is there an option
to not create a another replication in other DCs just because the WAN is of
fore some minutes?

You are describing Swift's normal behavior. A WAN (or even LAN) failure will
not trigger automatic replication (a drive failing, however, will trigger
it).

Basically, Swift treats the inability to connect to another server as an
availability issue instead of a durability issue. Replication is only
automatically triggered for durability issues.

> 5) In a Swift multi region deployment is it possible to have local
Keystone services in every region/DC or does all authentication need to come
from the same keytone machine?

I think this would be possible, but I'm not sure if it's advisable.

Because any Swift endpoint in the cluster can handle any request to the
cluster, this means that you'd be responsible for "locking" a client to a
particular endpoint. That is, you don't want UserA in Region1 to try to do
requests to Region2, because Region2 will have different auth set up and
therefore the request would likely fail.

For simplicity, I'd recommend starting with one global auth endpoint and
local memcache pools in each Swift region. I'll leave it up to you to
determine if you want one global VIP for every region or if you want to
expose different endpoints for each region in the cluster.

FWIW, I don't think either way is "right". In my opinion, it sounds easier
to manage local caching instead of managing the client locking to a region.

>
> Any help and ideas appreciated!
>
> Cheers
> Chris
>
> _______________________________________________
> 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