[Openstack] [openstack][swift] Question about Swift consistency and concurrent requests

John Dickinson me at not.mn
Mon Feb 22 16:04:01 UTC 2016


inline

On 22 Feb 2016, at 5:06, Kévin Bernard-Allies wrote:

> Hello,
>
> I've some questions about the handling of concurrent requests by Swift.
> Any help would be great:)
>
>
> If I understand correctly, a PUT request on swift-proxy will be transmitted to at least half the storage nodes plus one, before returning the response.

Correct. And because I've heard it wrongly many time before, I'll note that these requests happen concurrently (it's NOT store-and-forward).

> A subsequent GET request should have an updated version (because it also make the GET request to several storage nodes ?), but the listing is not immediately up-to-date.

Correct that that listing might not be immediately up-to-date. The subsequent GET should have an updated version because the placement locations are relatively stable.

Read-your-writes consistency is as dependent on hardware and tuning as much as the software itself. That being said, with Swift' default config options and "normal" hardware choices, Swift offers very very good out-of-the-box read-your-write consistency. However, Swift' does not provide read-your-overwrites consistency. That is, a read after an overwrite of existing data (i.e. same object name) may provide the older version of the data or the newer version of the data. Normally, this will only happen as a result of internal cluster hardware failure or capacity adjustment.

A very simple (and common) way to avoid any reads of older versions of objects in Swift is to use unique names to write data.

Note that in no case will the application get corrupted data (part of v1 and part of v2). In all cases, the client will get back the newer or older version.

>
> Now, I wonder what happens when two PUT requests with 'If-Match' headers are executed at the same time.
> The 'If' header is active, and one of the two requests is rejected ? Or the header is ignored, and the request with the last timestamp wins ?

Note that Swift only supports "If-Match: *" for PUTs (i.e. only PUT if some data already exists). You cannot specify "only PUT if this particular content exists".

However, the final question is a simple one. Yes, Swift resolves concurrent writes with a last-timestamp-wins strategy. The timestamp is determined by the Swift proxy server handling the request, and it is created when the request starts. Note that this implies the need to keep Swift proxy servers in sync, eg with something like NTP.

At some point (in any system) "at the same time" will get below the resolution of the system. So what happens when you have two writes to Swift that happen so close to each other that they are within the time resolution of the system? At this point, the resolution is not defined. One of them will probably become the only version stored, but there's no deterministic way to know which one will.

Swift's timestamp resolution is decimillisecond (5 decimal places to the right of the decimal). Why? Because "floating point". See https://gist.github.com/notmyname/3fffa234f602f8b8e616.

>
>
> I search a way to ensure I can't lose a version of the files without noticing it.

There are a couple of strategies. Operationally, make sure you keep proxies in sync and monitor that. From the application perspective, you can use unique names for writes.


--John




> I'll take any idea.
>
>
> Thanks all!
> -- 
> Kévin Bernard-Allies
>
> _______________________________________________
> 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/20160222/97122841/attachment.sig>


More information about the Openstack mailing list