<div>
                    Interesting.  I haven’t seen that happen before, and have setup memcached in a similar fashion as you.  The memcached client consistently hashes each key across your set of active memcached servers.  So killing memcached on server x, should only result in failures for data stored on server x.  However, the client should account for this and rehash.
                </div><div><br></div><div>It sounds to me like another component is causing you grief, and the editing of memcached servers + restart clears it up.  Instead of taking down the entire system, have you tried stopping memcached on a single server, and verify the delay is still present?</div>
                <div></div>
                 
                <p style="color: #A0A0A8;">On Thursday, August 14, 2014 at 9:30 AM, Joe Topjian wrote:</p>
                <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
                    <span><div><div><div dir="ltr">Hi Abel,<div><br></div><div>I'm petty confident that the delays are coming from the the openstack server components. For example, Keystone. So when a client tries to authenticate, Keystone is not marking a memcached server as dead and will continue to try it and time out. At least that was my impression when I tested removing the dead node from the config files.</div>
<div><br></div><div>I fully agree about everything going back to normal after a short time. If the timeout delay didn't exist, I'd still try to implement some sort of replication just because, as an end-user, being randomly logged out is really annoying.</div>
<div><br></div><div>Thanks,</div><div>Joe</div></div><div><br><br><div>On Thu, Aug 14, 2014 at 10:23 AM, Abel Lopez <span dir="ltr"><<a href="mailto:alopgeek@gmail.com" target="_blank">alopgeek@gmail.com</a>></span> wrote:<br><blockquote type="cite"><div>I played with this in the lab for a little bit, it didn’t seem to be a huge deal.<br>
My setup was three ‘controller’ nodes each running Multi-master Percona DB, rabbit-ha cluster, and memcached. Killing DB, no worries as it’s behind LB, killing rabbit? Usually not a problem especially after 3.2.x. Memcached? I noticed a brief period of invalid tokens, but within a few seconds, everything goes back to normal. I think the client software has a built-in retry when auth fails, or at least that was the observation. This was on Havana 1<br>

<div><div><br>
On Aug 14, 2014, at 9:09 AM, Joe Topjian <<a href="mailto:joe@topjian.net">joe@topjian.net</a>> wrote:<br>
<br>
> Hello,<br>
><br>
> I have an OpenStack cloud with two HA cloud controllers. Each controller runs the standard controller components: glance, keystone, nova minus compute and network, cinder, horizon, mysql, rabbitmq, and memcached.<br>

><br>
> Everything except memcached is accessed through haproxy and everything is working great (well, rabbit can be finicky ... I might post about that if it continues).<br>
><br>
> The problem I currently have is how to effectively work with memcached in this environment. Since all components are load balanced, they need access to the same memcached servers. That's solved by the ability to specify multiple memcached servers in the various openstack config files.<br>

><br>
> But if I take a server down for maintenance, I notice a 2-3 second delay in all requests. I've confirmed it's memcached by editing the list of memcached servers in the config files and the delay goes away.<br>

><br>
> I'm wondering how people deploy memcached in environments like this? Are you using some type of memcached replication between servers? Or if a memcached server goes offline are you reconfiguring OpenStack to remove the offline memcached server?<br>

><br>
> Thanks,<br>
> Joe<br>
</div></div><div><div>> _______________________________________________<br>
> OpenStack-operators mailing list<br>
> <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br>
</div></div></div></blockquote></div><br></div>
</div><div><div>_______________________________________________</div><div>OpenStack-operators mailing list</div><div><a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a></div><div><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a></div></div></div></span>
                 
                 
                 
                 
                </blockquote>
                 
                <div>
                    <br>
                </div>