Pregunta Almacenamiento de sesión PHP en grupo de Memcached tolerante a fallos


Recientemente tuve la oportunidad de mover una aplicación web de usar un proxy de Nginx "loadbalancer" a un F5 loadbalancer. Desafortunadamente durante esa migración quedó claro que la memcached almacenamiento de sesión necesario para pasar del servidor proxy Nginx a "algún lugar". Mi pensamiento es que debo poner. memcached en los 3 servidores web (los servidores que se encuentran detrás del F5 en un grupo) y usan php-memcache o php-memcached para guardar sesiones. Aquí está el problema:

He probado los dos php-memcache y php-memcached y ninguno de los dos puede comportarse correctamente si uno de los servidores falla. Mi último intento fue con esta configuración:

memcached versión 2.2.0 con los ajustes de configuración:

session.save_handler = memcached
session.save_path = "172.29.104.13:11211,172.29.104.14:11211"

No tengo nada especial en memcached.ini otro que extension=memcached.so.

Con esta configuración tanto en el servidor 1 como en el 2 (eliminé 3 temporalmente para probar), apunto JMeter al F5 VIP e inicio el tráfico. puedo ver memcached.log (el demonio) en ambos sistemas, aunque no ha dedicado tiempo a descifrar, comience a ejecutarse.

Entonces si paro uno de los memcached Demonios, el tráfico comienza a fallar y mi regreso es

session_start(): Write of lock failed 

por el memcached Eso queda restante.

Al final del día mi objetivo es simple: necesito poder a) no correr memcached en un solo servidor (punto único de falla), y el clúster debe ser resistente a una falla de un miembro del grupo.

También he intentado php-memcache pero también falla por php-memcache La configuración se ve así:

memcache versión 3.0.8 (beta) con los ajustes de configuración:

 
session.save_handler = memcache
session.save_path = "tcp: //172.29.104.13: 11211, tcp: //172.29.104.14: 11211"

y en memcache.ini:

extensión = 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 = consistente
memcache.allow_failover = 1
memcache.session_redundancy = 2

El error aquí es simplemente un token de sesión no válido (lo que me indica que el servidor restante no tenía el token de sesión realmente almacenado, lo que significa que la replicación de guardar la sesión no estaba activa).

No he pensado en volver a poner la persistencia de sesión en el F5, aunque como último recurso podría hacerlo, y los clientes que intenten conectarse con el miembro perdido tendrían que volver a autenticarse.


5
2017-08-15 16:26


origen




Respuestas:


Es mucho más sencillo que los clientes almacenen el estado de sesión para usted en las cookies. Esto significa que no hay almacenamiento de sesiones en todo el lado del servidor, solo unos pocos microsegundos de uso de la CPU para descifrar y verificar la cookie. Como la CPU es, con mucho, el recurso más abundante en un centro de datos, este esquema funcionará mucho mejor que una búsqueda desde memcached o cualquier otro almacenamiento de sesión de servidor.

Ver https://github.com/ascorbic/php-stateless-cookies Para una implementación, hay muchos otros dando vueltas. Tenga en cuenta que los datos de la sesión deben estar encriptados pero debe ser autenticado a través de HMAC o un cifrado AEAD. No escriba este código usted mismo a menos que sea un criptógrafo; utilizar una biblioteca cryoto bien vetada.

Facebook utiliza esta técnica para que cualquier servidor pueda responder a cualquier solicitud del usuario, incluso si la sesión del usuario se inició en otro centro de datos.


0
2017-08-15 16:50



Nuevamente, gracias por la sugerencia, pero no es práctico cambiar el método de autenticación para la aplicación. Ya hay varios clientes (es decir, demonios) que tendrían que comenzar a extraer información de cookies y devolverla, etc. - Joe