我最近有机会将Web应用程序从使用Nginx代理“loadbalancer”移动到F5负载均衡器.不幸的是,在迁移期间,很明显memcached会话存储需要从Nginx代理服务器移动到“某处”.我的想法是,我应该将memcached放在所有3个Web服务器(位于池中的F5后面的服务器)上,并使用PHP-memcache或PHP-memcached来保存会话.这是麻烦:
我已经尝试了PHP-memcache和PHP-memcached,如果其中一台服务器发生故障,它们都无法正常运行.我的最新尝试是使用此配置:
memcached 2.2.0版配置设置:
session.save_handler = memcached session.save_path = "172.29.104.13:11211,172.29.104.14:11211"
除了extension = memcached.so之外,我在memcached.ini中没有什么特别之处.
在服务器1和2上都进行了这种配置(我暂时删除了3个以进行测试),我将JMeter指向F5 VIP并启动流量.我可以在两个系统上看到memcached.log(守护进程),但没有花时间去破译,开始运行.
然后,如果我停止其中一个memcached守护进程,流量开始失败并返回
session_start():写入锁定失败
由留下的memcached留下.
在一天结束时,我的目标很简单 – 我需要能够a)不在单个服务器上运行memcached(单点故障),并且集群需要能够适应池成员的故障.
我也试过PHP-memcache但它也失败了.对于PHP-memcache,配置如下所示:
带有配置设置的memcache 3.0.8版(测试版):
session.save_handler = memcache session.save_path = "tcp://172.29.104.13:11211,tcp://172.29.104.14:11211"
在memcache.ini中:
extension=memcache.so [memcache] memcache.dbpath="/var/lib/memcache" memcache.maxreclevel=0 memcache.maxfiles=0 memcache.archivememlim=0 memcache.maxfilesize=0 memcache.maxratio=0 memcache.hash_strategy=consistent memcache.allow_failover=1 memcache.session_redundancy=2
这里的错误只是无效的会话令牌(暗示我剩下的服务器实际上没有存储会话令牌,这意味着保存会话的复制没有激活).
我没有考虑将会话持久性放回到F5上,但作为最后的手段,我可以这样做,并且尝试连接到丢失的成员的客户端将不得不重新进行身份验证.
让客户端在cookie中存储会话状态要简单得多.这意味着在所有服务器端都没有会话存储,只有几微秒的cpu使用率才能解密.验证cookie.由于cpu是数据中心中最丰富的资源,因此该方案的性能远远优于从memcached或任何其他服务器会话存储中查找.
对于一个实现,请参见https://github.com/ascorbic/php-stateless-cookies,还有许多其他实现.请注意,会话数据应加密,但必须通过HMAC或AEAD密码进行身份验证.除非你是密码学家,否则不要自己编写这段代码;使用经过严格审查的cryoto库.