[Openstack] [Swift] GET request nodes and handoffs

Shrinand Javadekar shrinand at maginatics.com
Wed Jul 13 23:18:35 UTC 2016


I see that this can be related to error_suppression_limit and
error_suppression_interval.

When the GET request is sent, if that node had previously seen errors
>= error_suppression_limit, then for the next
error_suppression_interval seconds, this node would not be used.
Instead, some other node (handoff node) will be considered for
servicing the GET request. This handoff node may not have the data and
therefore may return a 404.

As always, I guess this works fine when there are 3 or more copies of
the data. Probability of all the primary nodes being error_limited
being low.

-Shri

On Wed, Jul 13, 2016 at 12:18 PM, Shrinand Javadekar
<shrinand at maginatics.com> wrote:
> Hi,
>
> I am trying to understand the mechanism used by Swift to determine
> which storage node to send a GET request to.
>
> I have a single node setup with 4 disks: r1, r2, r3 and r4. For a
> given container and object-name, the swift-get-nodes -a output shows
> the following:
>
> Server:Port Device 127.0.0.1:6000 r2
> Server:Port Device 127.0.0.1:6000 r4  [Handoff]
> Server:Port Device 127.0.0.1:6000 r3  [Handoff]
> Server:Port Device 127.0.0.1:6000 r1  [Handoff]
>
> I confirmed that the object got written into r2 correctly.
>
> However, sometimes, when I read the object, the request is first sent
> for the handoff nodes. Below is an except of the log that shows that
> the request was sent to r3 and r1 which returned 404. Then, when the
> user/client tried again, the request was sent correctly to r2 which
> correctly returned HTTP 200.
>
> http://pastie.org/private/rap4w6gkgcor8gt4wkqoa
>
> Clients/users are going to have limited retries. So, if the situation
> that happened in the first case happens multiple times, clients will
> believe that the data is lost, right?
>
> What causes GET requests to directly be sent to handoff nodes without
> being sent to the primary node first?
>
> Thanks in advance.
> -Shri




More information about the Openstack mailing list