tomcat replicação de sessão sem multicast

Question

Estou planejando usar 2 servidores raiz dedicados alugados em um provedor de hospedagem. essas máquinas será executado tomcat 6 em um cluster. Se eu quiser adicionar máquinas adicionais mais tarde -., é improvável que eles serão acessíveis com multicast, porque eles vão estar localizados em diferentes sub-redes

É possível executar tomcat sem multicast? todos os tutoriais para tomcat 6 clusters incluem batimento cardíaco multicast. Existem alternativas para SimpleTcpCluster?

ou outras alternativas mais adequadas a esta situação?

Answer 1

Com nenhum controle sobre a distância entre os dois servidores (eles podem estar em dois datacenters diferentes) e nenhuma linha inter-server-de comunicação dedicado, eu prefiro executá-los através de DNS round-robin ou um balanceador de carga que redireciona clientes para tanto www1.yourdomain.xxx ou www2.yourdomain.xxx e alça de servidor de comunicação com cuidado.

Se os servidores são fortemente comunicar uns com os outros que você pode nem olhar para mudar sua arquitetura, otimizar o inferno fora de seu aplicativo para "encaixar" em um servidor (pelo menos por um tempo) ou ir para hospedagem dedicada com controle sobre a localização, distância e cabeamento de seus servidores. Caso contrário, sua inter-server-comunicação, batimentos cardíacos etc. usaria o mesmo canal que os clientes que estão se comunicando com ele (por exemplo, o mesmo segmento de rede), que pode retardar todos para baixo.

Se você está realmente esperando que muita carga Suponho que há pelo menos algum dinheiro envolvido, não? Use-o com sabedoria e usar suas habilidades de configuração para os problemas mais difíceis do que a criação de clusters distribuídos sem nenhum controle ou linhas dedicadas.

Answer 2

Ao ver o comentário para a questão depois de ter dado a minha outra resposta que eu estou intrigado sobre o que sua pergunta é ... É sobre a replicação da sessão? comunicação do cluster? Poderia ser melhor para indicar o seu problema em vez de sua solução planejada que tem problemas em si.

Eu irei expor alguns problemas possíveis, juntamente com respostas rápidas:

O aplicativo não é CPU / RAM intensiva

• Perfil-lo, otimizá-lo, tente novamente
• comprar um maior / melhor servidor

Seu pedido é a largura de banda intensiva

• usando o agrupamento cheapo você mencionou na sua pergunta provavelmente vai piorar a situação, como o mesmo (camuflada) canal é utilizado para a inter-server-comunicação como para a comunicação cliente-servidor
• Você pode ser capaz de separar diferentes tipos de largura de banda por exemplo por ter conteúdo dinâmico servido a partir de um servidor diferente do conteúdo estático: Não há necessidade de inter-server-comunicação aqui

Seu pedido é o armazenamento intensivo

• obter um servidor maior
• ir para hospedagem dedicada e se encaixam em tantos discos giratórios como você precisa
• ver se outros modelos (como amazonas de armazenamento S3) pode funcionar para você)

O aplicativo é provável que seja slashdotted

• determinar qual dos fatores acima (ou outros) está determinando os limites de sua aplicação, correção.

Você só precisa de replicação de sessão?

Interface
• Tomcats SessionManager é pequeno e pode ser facilmente implementado / estendeu-se. Usá-lo para qualquer replicação de sessão você gosta. Veja a StandardManager documentação e implementação para mais informações

Mais ideias

• olhada configurações mais flexíveis como EC2 (Amazon), ofertas googles ou outras configurações de Cloud Computing. Fazer uso de sua própria nuvem de armazenamento e inter-server-Comunicação-instalações. Tenha cuidado para não depender muito sobre esta infra-estrutura.

Eu certamente ter esquecido alguma coisa, mas isso pode fornecer algum ponto de partida. Seja mais concreto sobre a natureza do seu problema subjacente para obter melhores respostas:)

Answer 3

Eu estou tentando implantar o Yale Central Authentication Server (CAS) e eu gostaria de agrupar-lo para redundância, porque esta é uma parte crítica da infra-estrutura. CAS exige que a sessão de ser replicado, porque depois de um utilizador inicia sessão em aplicação A e navega para aplicação B que participa no single-sign-on domínio, aplicação B envia uma solicitação ao CAS para determinar se o usuário tem um 'bilhete' ativa . Como não há dispositivo para indicar a aplicação B ao qual nó ele deve dirigir-se para validar o bilhete, todos os bilhetes ativos em um nó deve ser replicada para todos os nós do cluster. Em outras palavras, a viscosidade da sessão não é uma solução aqui, porque a aplicação B, ao validar o bilhete no cookie do usuário, não tem conhecimento do sessionId da sessão original no aplicativo A durante o qual o usuário logado.

Assim, CAS exige que a sessão de ser replicado em todos os nós. A exigência de que o multicasting suporte de rede adiciona uma quantidade não trivial de sobrecarga, e faz com que esta abordagem um pouco mais pesado para implantar. Eu testei este projeto no Google Code:

http://code.google.com/p/memcached-session-manager

que parece muito útil e simples de implementar (pelo menos em um sistema operacional linux), mas infelizmente só prevê failover sessão, e não é uma solução de replicação de sessão.

Answer 4

Basta usar http://code.google.com/p/memcached-session -manager / . Ele funciona muito bem. Nós estamos usando isso há anos para essa configuração com 20 servidores Tomcat compartilhar sessões. Você pode ter um ou dois servidores memcached para lidar com a replicação de sessão.