Clusters Web com Tomcat: Distribuição de Carga e Alta Disponibilidade

Esse artigo faz parte da revista Java Magazine edição 29. Clique aqui para ler todos os artigos desta edição

Clique aqui para ler esse artigo em PDF.

Java Livre

Clusters Web com Tomcat

Distribuição de Carga e Alta Disponibilidade

Aprenda a configurar vários servidores Tomcat como um cluster, de modo a atender mais usuários e ocultar deles panes em algum dos servidores

Fernando Lozano

Cluster é um dos termos mais usados em toda a informática, identificando qualquer configuração com vários computadores com o objetivo de fornecer maior capacidade bruta de trabalho, e algum nível de tolerância à falhas. Neste artigo estamos interessados em um tipo bem específico de cluster – voltado a aplicações web J2EE.

Os exemplos serão apresentados utilizando o Tomcat 5 (5.5.x ou 5.0.x), mas todos os conceitos serão válidos para outros containers web, livres e proprietários. Não fará diferença usar o J2SE 1.4.2 ou 5.0, desde que seja utilizada a versão do Tomcat correspondente ao seu Java (5.0.x com o J2SE 1.4.x; 5.5 com o J2SE 5.0).

E o melhor: suas aplicações web, se desenvolvidas conforme as recomendações do J2EE e algumas boas práticas, não vão precisar sofrer qualquer modificação para se adequarem às configurações de cluster apresentadas. No entanto, muitas aplicações ainda são desenvolvidas sem seguir essas recomendações, podendo não funcionar corretamente num cluster (também podendo apresentar problemas em outras situações).

Para mais informações sobre a forma “correta” de desenvolver aplicações web J2EE, consulte o quadro “Desenvolvendo para clusters”. Para conhecer alguns conceitos de clusters e a terminologia relacionada usada nesse artigo consulte o quadro “Conceitos de clusters web etc.”.

Este artigo assume que que o leitor já tem algum conhecimento prévio da instalação e configuração do Tomcat e do Apache, além de conhecimento de desenvolvimento de aplicações web. A instalação do Tomcat e Apache foi abordada antes nesta mesma coluna, na edição nº 6, e no artigo de Gabriel Esteves na edição nº 8. Fundamentos do desenvolvimento de aplicações web com o Tomcat, incluindo o uso de suas aplicações administrativas, foram apresentados nesta coluna nas edições nº 18, 19 e 20.

Preparação

A configuração será feita em duas etapas. Primeiro será criado um cluster que fornece apenas maior escalabilidade, dividindo a carga de trabalho entre vários servidores Tomcat. Depois será demonstrado como fornecer também tolerância a falhas, permitindo que um nó assuma de forma transparente os usuários que eram atendidos por outro nó que falhou.

Para que seja possível testar o ambiente de cluster, simulando vários usuários, o leitor irá necessitar de pelo menos dois navegadores web instalados em seu computador. Por exemplo, o Firefox e o Internet Explorer (IE) no Windows; ou um Firefox e um Konqueror no Linux.

Embora o ambiente de produção preferencial para clusters Tomcat sejam servidores Unix e Linux, a configuração é independente do sistema operacional. Particularmente, o leitor também poderá seguir os exemplos em qualquer versão do Windows a partir da 98.

Apenas a instalação do servidor web que atuará como balanceador será diferente em cada plataforma. Para os detalhes, consulte os quadros “Instalação do Apache e mod_jk em Linux”, “Instalação do Apache e mod_jk em Windows” e “Instalação do IIS com mod_jk no Windows”

Clusters Tomcat + Apache

Um cluster web é constituído por um balanceador de carga, que o usuário “enxerga” como sendo o servidor web que responde ao seu navegador, e um conjunto de servidores web (ou de containers web) que são efetivamente os nós do cluster.

Para balanceador, optamos pelo Servidor Web Apache 2.0. O quadro “Clusters web no J2EE” apresenta mais detalhes sobre a configuração genérica desse cluster e os seus requisitos. Neste artigo estamos focando numa implementação específica, aplicável em muitas situações típicas, utilizando os recursos do Tomcat.

A Figura 1 apresenta a arquitetura física do cluster que será construído. Um único servidor Apache, rodando o módulo mod_jk, atua como balanceador de carga para duas instâncias do Tomcat. Para construir a configuração deste artigo, será necessário, portanto, instalar um Apache e duas cópias do Tomcat em diretórios diferentes. Usuários Windows podem usar a versão do Apache nativa para seus sistemas.

Módulos e conectores

O mod_jk é um módulo de extensão para o Apache e outros servidores web, que permite sua integração a um container web Tomcat. Ele é baseado no protocolo AJP (Apache Java Protocol), que permite a um servidor web obter várias informações de gerenciamento do container. Apesar do AJP não ser parte oficial da plataforma J2EE, ele é um padrão de mercado, sendo utilizado por vários outros containers e extensões de servidores web.

Embora seja comum dizer que o Tomcat é um container web, esta afirmação não é muito precisa. O container web em si, chamado Catalina, é apenas um dos componentes que formam o Tomcat. Outros componentes são o compilador de páginas JSP, chamado Jasper (sem relação com o JasperReports), os vários conectores que gerenciam conexões de redes, e vários projetos do Jakarta Commons, como o DBCP para pools de conexões JDBC.

No lado do Tomcat, deve ser configurado e ativado o conector Jk, que recebe requisições AJP. Este conector é parte da instalação padrão do Tomcat desde suas primeiras versões. Com o conector Jk ativo, seria possível desligar a funcionalidade de servidor web embutida no Tomcat, fornecida pelo conector Coyote, porém é recomendável manter este conector para que seja possível acessar aplicações administrativas (Manager e Admin) em cada nó Tomcat de forma independente. O conector Coyote também nos permite validar o funcionamento individual de cada nó do cluster, e assim isolar problemas de configuração do balanceador.

Portas TCP e pacotes multicast

Será utilizado um único computador para montar o cluster, de modo que todos os leitores possam experimentar as configurações indicadas e validar suas aplicações. Por isso, temos que atribuir portas TCP diferentes para cada instalação do Tomcat. Será utilizado o endereço de loopback do TCP/IP (127.0.0.1). Assim o computador do leitor não necessitará estar ligado a uma rede.

Cada nó do cluster anuncia sua presença aos demais utilizando pacotes multicast. Um pacote multicast é endereçado a um subconjunto dos computadores presentes em rede local. Ele é diferente de pacotes unicast, endereçados a um único computador e de pacotes broadcast, endereçados a todos os computadores na rede. O uso do multicast facilita muito a manutenção do cluster, pois torna desnecessário se ter em cada nó uma lista dos endereços e portas dos demais nós. Além disso, com o uso de pacotes multicast, é consumida menos largura de banda do que se forem utilizados pacotes unicast ou broadcast.

O uso do multicast pode exigir configurações especiais do seu sistema operacional ou dos seus equipamentos de rede (switches e roteadores). Para leitores que venham a testar a configuração em Linux, recomendamos a consulta ao quadro “IP Multicast no Linux”.

Replicação de sessões

A replicação de sessões HTTP é a “alma” do cluster, pois é ela que permite que um nó do cluster assuma os usuários que estavam sendo atendidos por outro nó que falhou. Ela é realizada por conexões TCP diretas entre cada par de nós. Versões do Tomcat anteriores à 5.0 não traziam o suporte a esse recurso, que tinha de ser fornecido por um software externo como um servidor de aplicações JBoss usando o Tomcat como container. Várias soluções eram baseadas em bancos de dados relacionais ou mesmo arquivos compartilhados em rede para realizar a replicação das sessões.

Diferentemente da maioria dos produtos de terceiros[1], a replicação nativa do Tomcat é baseada em memória, não em armazenamento em disco ou em banco de dados. Além de ser mais leve e rápida, isso elimina um potencial ponto de falha no ambiente – afinal se o banco de dados utilizado para a replicação cair, morre o cluster. Mas nada impediria o uso dessas soluções com o Tomcat.

É possível acrescentar ou remover nós ao cluster a qualquer momento. Ao entrar no cluster, um novo nó detecta os demais pelos multicasts e requisita uma cópia inicial do estado de todas as sessões HTTP, antes de passar a aceitar requisições. Já se um nó cair (ou for desligado do cluster). Os demais nós também irão perceber que um deles não está mais enviando os multicasts (ou então que ele não responde na conexão de replicação) e irão parar de replicar com este nó. O balanceador também irá perceber que o nó falho não mais responde, e parar de encaminhar requisições a ele.

Para o balanceador, o acréscimo de um novo nó é igual à inicialização do cluster. Afinal, os vários nós não são inicializados exatamente ao mesmo tempo, então obrigatoriamente o cluster passa seus primeiros segundos de vida com apenas um nó, depois entra o segundo nó, e assim por diante.

Entretanto, a configuração do balanceador em geral tem que relacionar todos os nós que poderiam possivelmente fazem parte do cluster, então acrescentar um nó realmente novo exigiria atualizar a configuração do balanceador. Neste sentido, o Apache é uma boa opção, pois sua reinicialização é bem rápida, e em sistemas Linux ele pode ser reconfigurado sem reinicialização. Durante esta reinicialização ou reconfiguração há uma possibilidade remota de se perder algumas requisições de usuários, mas pode ser ignorada, pois não é maior do que a chance de se perder uma requisição devido ao congestionamento na própria rede.

Clusters para balanceamento de carga