Como os cookies funcionam com balenciadores de carga não persistentes

Question

Temos um aplicativo do Drupal que usa o sso para registrar usuários.

Estamos usando 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.

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

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

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

Para meu conhecimento, a cada hit de 'example.com', o usuário pode acabar no servidor 1 ou no servidor 2.

Minha pergunta:

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

Parece que estou 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 de redis para as informações da sessão.

    

Answer 1

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. Portanto, contanto que os dois servidores sejam acessados pelo mesmo domínio, o cookie estará lá.

Se um cookie apontar para uma sessão, então é necessário que tanto o servidor1 quanto 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 mágica 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 de reconfiguração simples (ish) e um cookie, o usuário pode ser bloqueado para um determinado servidor, garantindo que a sessão dele persista.

Aqui estão mais alguns detalhes.

DNS:

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

Reescreva as regras:

• cookie de persistência: "backend"
• conexão inicial: "backend" não definido, defina "backend" para www1 ou www2, dependendo de qual servidor respondeu e redirecionou para esse servidor. O cookie deve ser definido para o domínio "example.com", desta forma, será carregado em www1 e www2
• Se "backend" estiver definido, assegure-se de que seu valor corresponda à instância do servidor e redirecione, se necessário.
• Verifique se o cookie da sessão está definido no nome completo do domínio do servidor - ou seja, www1.example.com ou www2.example.com

A lógica de reescrita deve ser definida no próprio servidor web. Todos os servidores web modernos possuem linguagens de reescrita com muitos recursos que são totalmente capazes de implementar essa funcionalidade.

    

Answer 2

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

link

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