On 08/06/16 10:50, Mark Kirkwood wrote:
On 08/06/16 07:06, Pete Zaitcev wrote:
The proxies are load balanced behind Haproxy (which I'm guessing is
causing the 404 - see below)
HAproxy is often troublesome, but I don't expect it is at fault in
this instance. The logs that you quoted show that the proxy-server
returned the 404. Do proxies happen to talk to separate memcached
instances by any chance?
Yeah - good point, each proxy has its own memcache.
Following up this point,
I can reproduce this issue by putting haproxy in front of some
development proxies I have running as VMs on my workstation (easier to
amend config in this case):
So I have 2 Swift proxies, each using itself as a memcache server (e.g
proxy 192.168.122.21), other one (192.168.122.24) defined similarly:
$ cat /etc/swift/proxy-server.conf
...
[filter:cache]
use = egg:swift#memcache
memcache_servers = 192.168.122.21:11211
changing this servers line to include the other proxy's memcache too
(e.g proxy 192.168.122.21 again):
$ cat /etc/swift/proxy-server.conf
...
[filter:cache]
use = egg:swift#memcache
memcache_servers = 192.168.122.21:11211,192.168.122.24:11211
I no longer see any 404s with my test. Reading the install docs (a bit
more carefully this time it seems), I see that they are leaning us
towards doing that - am I understanding that correctly?
regards
Mark
_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
