[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