Como a aderência da sessão é alcançada em vários servidores da Web?

Quantos servidores web o StackOverflow / ServerFault possui?

Se a resposta for 'mais de um', será que ele atinge a aderência da sessão durante a pesquisa de DNS?

Sites grandes podem ter "carga balanceada" em várias máquinas. Em muitas configurações com balanceamento de carga, um usuário pode acessar qualquer uma das máquinas de back-end durante uma sessão. Por esse motivo, existem vários métodos para permitir que muitas máquinas compartilhem sessões do usuário.

O método escolhido dependerá do estilo de balanceamento de carga empregado, bem como da disponibilidade / capacidade de armazenamento de back-end:

Informações da sessão armazenadas apenas em cookies : as informações da sessão (não apenas um identificador de sessão) são armazenadas no cookie de um usuário. Por exemplo, o cookie do usuário pode conter o conteúdo de sua cesta de compras. Para impedir que os usuários adulterem os dados da sessão, um HMAC pode ser fornecido junto com o cookie. Este método é provavelmente o menos adequado para a maioria das aplicações:

• Não é necessário armazenamento de back-end
• O usuário não precisa acessar a mesma máquina todas as vezes, para que o balanceamento de carga DNS possa ser empregado
• Não há latência associada à recuperação das informações da sessão de uma máquina de banco de dados (pois elas são fornecidas com a solicitação HTTP). Útil se o seu site tiver carga balanceada por máquinas em diferentes continentes.
• A quantidade de dados que pode ser armazenada na sessão é limitada (pelo limite de tamanho do cookie 4K)
• A criptografia deve ser empregada se um usuário não conseguir ver o conteúdo de sua sessão
• O HMAC (ou similar) deve ser empregado para impedir a violação dos dados da sessão pelo usuário
• Como os dados da sessão não estão armazenados no servidor, é mais difícil para os desenvolvedores depurarem

O balanceador de carga sempre direciona o usuário para a mesma máquina : muitos balanceadores de carga podem definir seu próprio cookie de sessão, indicando de qual máquina backend o usuário está solicitando e direcioná-los para essa máquina no futuro. Como o usuário sempre é direcionado para a mesma máquina, o compartilhamento de sessões entre várias máquinas não é necessário. Isso pode ser bom em algumas situações:

• O tratamento de sessões de um aplicativo existente pode não precisar ser alterado para tornar-se consciente de várias máquinas
• Nenhum sistema de banco de dados compartilhado (ou similar) é necessário para armazenar sessões, possivelmente aumentando a confiabilidade, mas com o custo da complexidade
• Uma máquina de back-end desativada derrubará todas as sessões de usuário iniciadas nela.
• Colocar as máquinas fora de serviço é mais difícil. Usuários com sessões em uma máquina a serem retiradas para manutenção devem ter permissão para concluir suas tarefas antes que a máquina seja desligada. Para suportar isso, os balanceadores de carga da Web podem ter um recurso para "drenar" solicitações para uma determinada máquina de back-end.

Banco de dados back-end compartilhado ou armazenamento de chave / valor : as informações da sessão são armazenadas em um banco de dados back-end, ao qual todos os servidores da web têm acesso para consultar e atualizar. O navegador do usuário armazena um cookie contendo um identificador (como o ID da sessão), apontando para as informações da sessão. Este é provavelmente o método mais limpo dos três:

• O usuário nunca precisa ser exposto às informações da sessão armazenada.
• O usuário não precisa acessar a mesma máquina todas as vezes, para que o balanceamento de carga DNS possa ser empregado
• Uma desvantagem é o gargalo que pode ser colocado em qualquer sistema de armazenamento de back-end empregado.
• As informações da sessão podem expirar e fazer backup de forma consistente.

No geral, os aplicativos da web mais dinâmicos executam várias consultas ao banco de dados ou solicitações de armazenamento de chave / valor, portanto, o banco de dados ou o armazenamento de chave / valor é o local de armazenamento lógico dos dados da sessão.

Se sua pergunta é como manter sessões em vários servidores Web front-end, a resposta é geralmente usar um banco de dados centralizado. Em vez de confiar nas instâncias do servidor da web para rastrear arquivos de sessão nos sistemas de arquivos locais, você escreveria os IDs e os dados da sessão em um banco de dados central, e todos os servidores da web recuperariam os dados a partir daí.

Usar nemcached parece ser uma boa solução, não mencionada por @David Pashley

Isso significa ter uma instância remota do memcached compartilhada por todos os servidores e usar a extensão PECL do memcache que fornece seu próprio manipulador de sessões.

Requer apenas a alteração de dois parâmetros na configuração do php!

Aqui está um bom tutorial http://www.dotdeb.org/2008/08/25/storing-your-php-sessions-using-memcached/

IIRC, no DotNetRocks # 440 disseram um período de servidor. Não sei se esse ainda é o caso.

Edit: Na verdade, era Hanselminutes # 134 . Desculpe.

Você pode definir um cookie.

Você pode calcular um hash do IP remoto (em seus hosts remotos numerados ímpares mais simples, vá para o servidor A, os hosts numerados pares vão para o servidor B).

Parece que você também pode fazê-lo através de alguns valores que permanecem no sistema de origem se você estiver usando um túnel ssl.

Normalmente, cada um dos mecanismos acima requer um servidor "proxy reverso" ou um balanceador de carga de algum tipo. Esse balanceador de carga aceita o tráfego e o direciona para o servidor que inicialmente teve a sessão, com base em um dos critérios acima.

Não sei, no entanto, o que você quer dizer com "pesquisa de DNS"

a) Você pode armazenar informações da sessão no cookie do usuário. Consulte os cookies protegidos sem estado, que não armazenam dados no lado do servidor, mas preservam o estado da sessão http://www.cl.cam.ac.uk/~sjm217/papers/protocols08cookies.pdf . b) Você pode alterar o armazenamento de back-end da sessão para banco de dados ou cache de memórias. Para eliminar um único ponto de falha, você pode definir a replicação do banco de dados ou vários nós armazenados em cache. Observe que esse memcached é recomendado em configurações em que perder o estado do usuário na sessão não é um grande erro e não o deixa muito infeliz. Nos casos em que a preservação do estado é vital, use bancos de dados. Tanto o PHP quanto o Django e o Rails permitem ao desenvolvedor escrever back-end de sessão personalizado.