Cómo funcionan las cookies con equilibradores de carga sin persistencia

Tenemos una aplicación Drupal que usa sso para iniciar sesión en los usuarios.

Estamos usando balanceadores de carga clásicos (ELB) de AWS, AWS nos dice que no hay persistencia de sesión en el ELB.

Lo que intento descubrir es cómo funcionan las cookies sin persistencia en los equilibradores de carga clásicos.

example.com DNS apunta al ELB. Hay 2 servidores en el grupo Servidor1 y Servidor2

Lo que queremos que suceda es que si un usuario llega a su página de inicio al http://example.com/user/12345/decir en el servidor 1, si aún no ha iniciado sesión, se lo redirige a la página sso http://example.com/user/login/sso, inicia sesión automáticamente y recibe una cookie SESS<hexnumber>y luego se lo redirige ahttp://example.com/user/12345/

No podemos agregar ningún servidor de sesiones (redis), lo que garantiza que permanecerán en el servidor 1 para ambos redireccionamientos.

Que yo sepa con cada visita a 'example.com', el usuario podría terminar en el servidor 1 o en el servidor 2.

Mi pregunta:

Si obtienen la cookie en el servidor1 y luego son redirigidos al servidor2, ¿cómo sabrá el servidor2 que una cookie ya está asignada a ese usuario en el servidor1?

Parece que me estoy pensando en círculos. Cuando trabajamos en este tipo de configuración en el pasado usando LBs sin persistencia de sesión, usamos un servidor redis para mantener las sesiones y cada solicitud miraría el servidor redis para la información de la sesión.

Se establece una cookie en el navegador, no en un servidor. Está restringido a un dominio y, opcionalmente, a una ruta específica en la URL, por lo que siempre que el mismo dominio acceda a ambos servidores, la cookie estará allí.

Si una cookie apunta a una sesión, entonces es necesario que tanto el servidor1 como el servidor2 tengan acceso a esa sesión de alguna manera. Si las sesiones no se pueden compartir entre los servidores, entonces debe obligar a un usuario a persistir en un servidor específico. Esto se puede lograr fácilmente con DNS y un poco de magia de reescritura de URL:

• www.example.com apunta a ambos servidores.
• www1.example.com apunta solo al servidor1
• www2.example.com apunta solo a server2

Usando un conjunto de reglas de reescritura simples (ish) y una cookie, el usuario puede ser bloqueado a un servidor en particular, asegurando que su sesión persista.

Aquí hay algunos detalles más.

DNS:

• example.com A 1.1.1.1, A 2.2.2.2
• www.example.com CNAME example.com
• www1.example.com A 1.1.1.1
• www2.example.com A 2.2.2.2

Reescribir reglas:

• cookie de persistencia: "backend"
• conexión inicial: "backend" no definido, establezca "backend" en www1 o www2, según el servidor que haya respondido y redirija a ese servidor. La cookie debe establecerse en el dominio "example.com", de esta manera se cargará en www1 y www2
• Si se define "backend", asegúrese de que su valor coincida con la instancia del servidor y redirija si es necesario.
• Asegúrese de que la cookie de sesión esté definida en el nombre de dominio completo del servidor, es decir, www1.example.com o www2.example.com

La lógica de reescritura se definirá en el propio servidor web. Todos los servidores web modernos tienen lenguajes de reescritura muy característicos que son totalmente capaces de implementar esta funcionalidad.

Si no puede usar una base de datos de administración de sesiones como Elasticache Redis (Redis por sesiones no debería costar más de $ 15 por mes), la siguiente mejor opción es habilitar sesiones fijas en el ELB;

https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html

Esto obligará a los usuarios a ir al mismo nodo de fondo durante la sesión. Una "cookie generada por el equilibrador de carga" con una vida útil de 900 segundos debería ser lo suficientemente buena, pero puede modificarla.