Open Stack

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20160808/e7f0b265/attachment.sig>