Como os cookies funcionam com balanceadores de carga sem persistência

Temos um aplicativo Drupal que usa sso para fazer logon dos usuários.

Estamos usando os balanceadores de carga clássicos (ELB) da AWS, a AWS está nos dizendo que não há persistência de sessão no ELB.

O que estou tentando descobrir é como os cookies funcionam com não persistência nos balanceadores de carga clássicos.

O DNS example.com está apontado para o ELB. Existem 2 servidores no pool Server1 e Server2

O que queremos que aconteça é que, se um usuário acessar sua página inicial, http://example.com/user/12345/digamos no servidor 1, se ainda não estiver logado, será redirecionado para a página sso http://example.com/user/login/sso, fará login automaticamente e obterá um cookie SESS<hexnumber>e, em seguida, redirecionará de volta parahttp://example.com/user/12345/

Não temos permissão para adicionar nenhum servidor de sessões (redis), qual é a garantia de que eles permanecerão no servidor 1 para ambos os redirecionamentos.

Que eu saiba, a cada ocorrência de 'example.com', o usuário pode terminar no servidor 1 ou no servidor 2.

Minha pergunta:

Se eles obtiverem o cookie no servidor1 e depois forem redirecionados para o servidor2, como o servidor2 saberá que um cookie já está atribuído a esse usuário no servidor1?

Eu pareço estar me pensando em círculos. Ao trabalhar com esse tipo de configuração no passado usando LBs sem persistência de sessão, usamos um servidor redis para manter as sessões e cada solicitação examinaria o servidor redis para obter as informações da sessão.

Um cookie é definido no navegador, não em um servidor. Ele é restrito a um domínio e, opcionalmente, a um caminho específico na URL, desde que os dois servidores sejam acessados ​​pelo mesmo domínio, o cookie estará lá.

Se um cookie aponta para uma sessão, é necessário que o servidor1 e o servidor2 tenham acesso a essa sessão de alguma forma. Se as sessões não puderem ser compartilhadas entre os servidores, você precisará forçar um usuário a persistir em um servidor específico. Isso pode ser facilmente realizado com DNS e um pouco de magia de reescrita de URL:

• www.example.com aponta para os dois servidores.
• www1.example.com aponta apenas para server1
• www2.example.com aponta apenas para server2

Usando um conjunto de regras simples de reescrita (ish) e um cookie, o usuário pode ser bloqueado em um servidor específico, garantindo que a sessão persista.

Aqui estão mais alguns detalhes.

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

Regras de reescrita:

• cookie de persistência: "back-end"
• conexão inicial: "back-end" não definido, defina "back-end" como www1 ou www2, dependendo do servidor que respondeu e redirecione para esse servidor. O cookie deve estar definido no domínio "example.com", desta forma, será carregado nos sites www1 e www2
• Se "back-end" for definido, verifique se seu valor corresponde à instância do servidor e redirecione, se necessário.
• Verifique se o cookie da sessão está definido no nome de domínio completo do servidor - ou seja, www1.example.com ou www2.example.com

A lógica de reescrita deve ser definida no próprio servidor da web. Todos os servidores web modernos possuem linguagens de reescrita muito úteis, totalmente capazes de implementar essa funcionalidade.

Se você não puder usar um banco de dados de gerenciamento de sessões como o Elasticache Redis (o Redis apenas para sessões não deve custar mais de US $ 15 por mês), a próxima melhor opção é ativar sessões permanentes no ELB;

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

Isso forçará os usuários a irem ao mesmo nó de back-end ao longo da sessão. Um "cookie gerado pelo balanceador de carga" com uma vida útil de 900 segundos deve ser bom o suficiente, mas você pode ajustar isso.