[openstack-dev] Question -- whu does object data always go to a single swift node?

Snider, Tim Tim.Snider at netapp.com
Wed Jul 10 19:56:02 UTC 2013


Here's a novice question.
My stack has 2 swift nodes. As expect curl commands addressed to the controller node to get auth and url information bounce between the 2 swift nodes as expected.
However object data always ends up on the 2nd (.209) swift node even when the curl command is addressed to the 1st node (.208).
I've confirmed thru "ls -lR /srv/|wc" on both nodes.
What is causing this behavior :
      configuration option / setting on the controller node? If so what?
     Malformed curl command for the put?
     Pilot error?
(I probably vote for the last one :) ) .
I'd like to understand this behavior.
Thanks

Painful details below:

Connection info for node 2:
curl -v  -H 'X-Storage-User: test:tester' -H 'X-Storage-Pass: testing' http://192.168.10.189:8080/auth/v1.0
* About to connect() to 192.168.10.189 port 8080 (#0)
*   Trying 192.168.10.189... connected
> GET /auth/v1.0 HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: 192.168.10.189:8080
> Accept: */*
> X-Storage-User: test:tester
> X-Storage-Pass: testing
>
< HTTP/1.1 200 OK
< X-Storage-Url: http://192.168.10.209:8080/v1/AUTH_test
< X-Storage-Token: AUTH_tkb285072ed44848e7807434ae121c3105
< X-Auth-Token: AUTH_tkb285072ed44848e7807434ae121c3105
< X-Trans-Id: tx839599572bd44156b332545811732dd8
< Content-Length: 0
< Date: Wed, 10 Jul 2013 19:34:39 GMT
<
* Connection #0 to host 192.168.10.189 left intact
* Closing connection #0

Connection info for node 1:
root at controller21:~/ssbench-0.2.16# curl -v  -H 'X-Storage-User: test:tester' -H 'X-Storage-Pass: testing' http://192.168.10.189:8080/auth/v1.0
* About to connect() to 192.168.10.189 port 8080 (#0)
*   Trying 192.168.10.189... connected
> GET /auth/v1.0 HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: 192.168.10.189:8080
> Accept: */*
> X-Storage-User: test:tester
> X-Storage-Pass: testing
>
< HTTP/1.1 200 OK
< X-Storage-Url: http://192.168.10.208:8080/v1/AUTH_test
< X-Storage-Token: AUTH_tkb285072ed44848e7807434ae121c3105
< X-Auth-Token: AUTH_tkb285072ed44848e7807434ae121c3105
< X-Trans-Id: tx4e41ed42e3ce4df8b8398a0290c761c3
< Content-Length: 0
< Date: Wed, 10 Jul 2013 19:34:57 GMT
<
* Connection #0 to host 192.168.10.189 left intact
* Closing connection #0

PUT command to node 2:
root at controller21:~/ssbench-0.2.16# curl -v -X PUT -T "/x"  -H 'X-Auth-Token: AUTH_tkb285072ed44848e7807434ae121c3105'  http://192.168.10.209:8080/v1/AUTH_test/container1/xxaa
* About to connect() to 192.168.10.209 port 8080 (#0)
*   Trying 192.168.10.209... connected
> PUT /v1/AUTH_test/container1/xxaa HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: 192.168.10.209:8080
> Accept: */*
> X-Auth-Token: AUTH_tkb285072ed44848e7807434ae121c3105
> Content-Length: 121290
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
* We are completely uploaded and fine
< HTTP/1.1 201 Created
< Content-Length: 118
< Content-Type: text/html; charset=UTF-8
< Etag: 662585fdfb794ff483fe4e59229270b2
< Last-Modified: Wed, 10 Jul 2013 19:47:56 GMT
< X-Trans-Id: txe7d9485971824e4abf87b1e64d591e78
< Date: Wed, 10 Jul 2013 19:47:56 GMT
<
<html>
<head>
  <title>201 Created</title>
</head>
<body>
  <h1>201 Created</h1>
  <br /><br />


</body>
* Connection #0 to host 192.168.10.209 left intact
* Closing connection #0
</html>root at controller21:~/ssbench-0.2.16#<mailto:root at controller21:~/ssbench-0.2.16#>

PUT command to node 1:
root at controller21:~/ssbench-0.2.16# curl -v -X PUT -T "/x"  -H 'X-Auth-Token: AUTH_tkb285072ed44848e7807434ae121c3105'  http://192.168.10.208:8080/v1/AUTH_test/container1/xxaa
* About to connect() to 192.168.10.208 port 8080 (#0)
*   Trying 192.168.10.208... connected
> PUT /v1/AUTH_test/container1/xxaa HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: 192.168.10.208:8080
> Accept: */*
> X-Auth-Token: AUTH_tkb285072ed44848e7807434ae121c3105
> Content-Length: 121290
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
* We are completely uploaded and fine
< HTTP/1.1 201 Created
< Content-Length: 118
< Content-Type: text/html; charset=UTF-8
< Etag: 662585fdfb794ff483fe4e59229270b2
< Last-Modified: Wed, 10 Jul 2013 19:48:07 GMT
< X-Trans-Id: tx9df884333d5b472996780167d76f380e
< Date: Wed, 10 Jul 2013 19:48:07 GMT
<
<html>
<head>
  <title>201 Created</title>
</head>
<body>
  <h1>201 Created</h1>
  <br /><br />



</body>
* Connection #0 to host 192.168.10.208 left intact


Node 1 Evidence for no objects stored:
root at swift21:~# ls -lR /srv/|wc
    114     339    2031
root at swift21:~# ls -lR /srv/|wc
    114     339    2031

Node 2 gets all the objects:
root at swift22:/srv# ls -lR /srv/|wc
108988  418269 3537920
root at swift22:/srv#
root at swift22:/srv# ls -lR /srv/|wc
109030  418431 3539291






Thanks,
Tim

Timothy Snider
Strategic Planning & Architecture - Advanced Development
NetApp
316-636-8736 Direct Phone
316-213-0223 Mobile Phone
tim.snider at netapp.com
netapp.com<http://www.netapp.com/?ref_source=eSig>
 [Description: http://media.netapp.com/images/netapp-logo-sig-5.gif]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130710/976b7777/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2568 bytes
Desc: image001.gif
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130710/976b7777/attachment-0001.gif>


More information about the OpenStack-dev mailing list