Хранилище сессий PHP в отказоустойчивом пуле Memcached

Недавно у меня была возможность переместить веб-приложение с использования "loadbalancer" прокси-сервера Nginx на loadbalancer F5. К сожалению, во время этой миграции стало ясно, что memcached хранилище сессий необходимо было перенести с прокси-сервера Nginx куда-нибудь. Я думаю, что я должен поставить memcached на всех 3 веб-серверах (серверах, которые находятся за 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"

У меня нет ничего особенного в memcached.ini Кроме как extension=memcached.so,

С этой конфигурацией на сервере 1 и 2 (я временно удалил 3 для тестирования), я указываю JMeter на F5 VIP и запускаю трафик. я могу видеть memcached.log (демон) в обеих системах, хотя они не потратили время на расшифровку, начните работать.

Тогда, если я остановлю один из memcached демоны, трафик начинает падать, и мое возвращение

session_start(): Write of lock failed

посредством memcached это осталось осталось.

В конце дня моя цель проста - мне нужно уметь а) не бегать 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:

расширение =memcache.so
[Memcache]
memcache.dbpath="/ Var/ Библиотека / Memcache"
memcache.maxreclevel=0
memcache.maxfiles=0
memcache.archivememlim=0
memcache.maxfilesize=0
memcache.maxratio=0
memcache.hash_strategy= последовательный
memcache.allow_failover=1
memcache.session_redundancy=2

Ошибка здесь - просто недопустимый токен сеанса (это означает, что на сервере, который оставался, токен сеанса фактически не сохранен, то есть репликация сохранения сеанса не была активной).

Я не смотрел на то, чтобы вернуть F5 к персистентности сеанса, хотя в качестве последнего средства я мог бы это сделать, и клиентам, пытающимся подключиться к потерянному участнику, пришлось бы повторно пройти аутентификацию.