MONOGRAFIA - ESTUDO DE VIABILIDADE DE SERVIDORES EM CLUSTER PARA ALTA DISPONIBILIDADE DE SERVIDORES EM CLUSTER

INSTITUTO FEDERAL DE EDUCAÇÃO, CIENCIA E TECNOLOGIA DO PIAUÍ.
PRÓ-REITORIA DE ENSINO
CURSO DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

ESTUDO DE VIABILIDADE DE SERVIDORES EM CLUSTER PARA ALTA
DISPONIBILIDADE EM SISTEMAS WEB JAVA

ADRIEL LUCAS DA SILVA VIANA

TERESINA/PI
OUTUBRO/2012


DISPONIBILIDADE EM SISTEMAS WEB JAVA

Monografia apresentada ao Instituto
Federal de Educação, Ciência e
Tecnologia do Piauí com requisito à
obtenção do título de Tecnólogo em
Análise e Desenvolvimento de Sistemas,
sob a orientação do Prof. MSc. Adalton
de Sena Almeida

TERESINA/PI
OUTUBRO/2012


DISPONIBILIDADE EM SISTEMAS WEB JAVA.

Monografia aprovada pelo Instituto Federal de Educação Ciência e Tecnologia do Piauí
como requisito à obtenção do título Tecnólogo em Análise e Desenvolvimento de
Sistemas.

Teresina, 05 de Novembro de 2012

Msc. Adalton Sena de Almeida
Orientador

Rogério da Silva Batista
2º Membro

Rogério da Silva
3º Membro

AGRADECIMENTOS

A Deus, por ter me dado forças para lutar, ter me proporcionado muitas vitórias e ter me
guardado do mal e da aparência do mesmo.
À minha família que sempre torceu por mim, acreditando sempre no meu potencial. Em
especial meu pai Egilson Viana e minha mãe Shyrlei Viana que sempre tiveram a certeza da
minha conquista.
A minha noiva Sara Raquel, fonte de inspiração, que esteve sempre comigo com o seu amor,
carinho, atenção e compreensão.
Aos amigos de trabalho, da igreja e do IFPI, que me deram total apoio durante a minha
caminhada rumo à vitória.
Aos meus professores que mostraram o caminho que eu deveria seguir e me incentivaram a
nunca desistir e sempre lutar.
A todos, muito obrigado.

Resumo

A disponibilização de serviços e informações na Internet está cada vez mais ampla, como por
exemplo, transações bancárias, comercio eletrônico, redes sociais, jogos interativos, etc. Esse
aumento se deu graças ao número crescente de usuários na Internet que por sua vez gerava um
aumento do trafego de dados na web. Os servidores web precisam está preparados para
atender a esta demanda que está cada vez mais crescente. Este trabalho apresenta uma solução
que prover uma alta disponibilidade de sistemas web java com a utilização de cluster de
servidores e balanceamento de carga. No decorrer deste trabalho será mostrada toda a
arquitetura do cluster e a sua configuração com a utilização do servidor web Tomcat. No
banco de dados será mostrada replicação master-slave utilizando o Mysql como SGBD, pois
pretende-se garantir a alta disponibilidade dos dados. O objetivo deste estudo é explicar como
prover a alta disponibilidade de sistemas web a um baixo custo de hardware e de software,
uma vez que será utilizado software livre para realização deste projeto.
Palavras-Chaves
Balanceamento de Carga, Cluster de Servidores, Replicação de dados, Mysql, Tomcat.

Abstract

The availability of services and information on the Internet is increasingly broad, as for
example banking transactions, e-commerce, social networking, interactive games, etc. This
increase was through the increasing number of users on the Internet which in turn generated
an increase in web traffic data. Web servers need to be prepared to meet this growing demand.
This paper presents a solution that seeks to provide a high availability of systems web java
using server cluster and load balancing. In this work will be displayed throughout the
architecture and configuration of the cluster using the Tomcat server. In the database will
show master-slave replication using MySQL as DBMS, because it is intended ensure the high
data availability. The objective of this study is to explain how to provide high availability web
systems at a low cost of hardware and software, since free software is used to carry out this
project.
Keywords
Load Balancing, Cluster of Servers, Data Replication, MySQL, Tomcat.

LISTA DE FIGURAS

Figura 1: Cenário proposto neste projeto
Figura 2: Replicação de sessões
Figura 3: Funcionamento do Tomcat-Cluster
Figura 4: Trecho de configuração do cluster no arquivo server.xml
Figura 5: Balanceamento de Carga
Figura 6: Funcionamento do Forwad Proxy
Figura 7: Funcionamento do Reverse Proxy
Figura 8: Virtual Host
Figura 9: Funcionamento da Replicação
Figura 10: Saida do comando SHOW SLAVE STATUSG;
Figura 11: Threads de replicação
Figura 12: Threads de E/S e Thread SQL
Figura 13: Resultado do teste no cluster com o probe
Figura 14: Volume de tráfego (bytes) no cluster
Figura 15: Uso da CPU no cluster
Figura 16: Volume de dados (bytes) no TomcatA
Figura 17: Uso de CPU TomcatA

LISTA DE TABELAS

Tabela 1: Configuração para identificar os nós no cluster

SUMÁRIO

1 – INTRODUÇÃO .......................................................................................................................................10

1.1– MOTIVAÇÃO .......................................................................................................................................... 10
1.2 – JUSTIFICATIVA ..................................................................................................................................... 11
1.3 – OBJETIVOS ............................................................................................................................................. 11
1.3.1– OBJETIVO GERAL .......................................................................................................................... 11
1.3.2 – OBJETIVOS ESPECÍFICOS............................................................................................................ 12

2 - REFERÊNCIAL TEÓRICO ....................................................................................................................13

2.1 - TOMCAT .................................................................................................................................................. 13
2.2 -APACHE ................................................................................................................................................... 13
2.3 - MYSQL..................................................................................................................................................... 14
2.4 - TOLERÂNCIA A FALHAS ..................................................................................................................... 14
2.5 - ALTA DISPONIBILIDADE ..................................................................................................................... 15
2.6 - SISTEMAS DISTRIBUÍDOS ................................................................................................................... 16
2.7 - BALANCEAMENTO DE CARGA .......................................................................................................... 16
2.8 - REPLICAÇÃO .......................................................................................................................................... 17
2.9 - CLUSTER ................................................................................................................................................. 17
2.10 - TRABALHOS RELACIONADOS ......................................................................................................... 18

3 - PROPOSTA DE UM AMBIENTE DE ALTA-DISPONIBILIDADE .....................................................19

3.1 - CENÁRIO ................................................................................................................................................. 19
3.1.1 - Informações sobre o ambiente utilizado ............................................................................................ 20
3.2 – TOMCAT-CLUSTER .............................................................................................................................. 21
3.2.1 - Requisitos .......................................................................................................................................... 22
3.2.2 – Arquitetura ........................................................................................................................................ 23
3.2.3 – Funcionamento ................................................................................................................................. 23
3.2.4 - Configuração ..................................................................................................................................... 25
3.3 – CONFIGURAÇÃO DO BALANCEADOR DE CARGA ........................................................................ 27
3.3.1. – O Módulo mod_proxy ...................................................................................................................... 28
3.3.2. – O Módulo mod_proxy_balancer ...................................................................................................... 30
3.3.4 – Configuração..................................................................................................................................... 31
3.4 - REPLICAÇÃO NO MYSQL .................................................................................................................... 34
3.4.1 – Funcionamento ................................................................................................................................. 34
3.4.2 – Configuração..................................................................................................................................... 36

4. – TESTES E RESULTADOS ....................................................................................................................40

4.1 – RESULTADO DOS TESTES NO BALANCEADOR DE CARGA E NO CLUSTER DE TOMCAT ..... 40
4.2 – RESULTADO DOS TESTES NA REPLICAÇÃO DE DADOS COM MYSQL ..................................... 41
4.3 – RESULTADOS DOS TESTES DE PERFOMANCE ............................................................................... 41

5 – CONCLUSÃO .........................................................................................................................................44

6 – REFERÊNCIAS BIBLIOGRÁFICAS ....................................................................................................45

10

1 – INTRODUÇÃO

Este trabalho foi realizado na empresa Infoway Tecnologia e Gestão em Saúde,
situada na cidade de Teresina-PI, como um estudo e testes utilizando ferramentas livres para
prover alta disponibilidade dos sistemas desenvolvidos pela própria empresa, onde se
pretende implantar esta solução na reestruturação do data center a partir da aquisição de novos
servidores. Uma das mudanças que ocorrerá nesta reforma será na hospedagem das
aplicações, onde serão configuradas e testadas soluções em cluster, balanceamento de carga
dos acessos e replicação de dados.
Para configurar todo este ambiente de alta disponibilidade será utilizada as
seguintes tecnologias: duas instancias do servidor web Tomcat visto que as aplicações
desenvolvidas pela Infoway utilizam a linguagem de programação java, o apache um
completo servidor web com várias funcionalidades e duas instancias do SGBD (Sistema de
Gerenciamento de Banco de Dados) MySQL.
Os Tomcat’s irão trabalhar em cluster replicando suas sessões entre si de modo
que se um Tomcat parar a aplicação continua disponível, pois a sessão já está replicada. O
apache atuará como um balanceador de carga dos acessos à aplicação garantindo que um só
servidor não fique sobrecarregado de acessos. No MySQL, existirá uma política replicação de
dados denominada master-slave, ou seja, terá um banco de dados denominado máster, onde
todas os dados serão armazenados, este por sua vez replicará os dados para outro banco de
dados denominado de slave, caso o máster falhe o slave assume a posição de master
garantindo a alta disponibilidade dos dados.
Mais adiante serão descritas sobre as tecnologias e conceitos, a utilização e
configuração de cada ferramenta na construção deste ambiente e ao final do mesmo será feito
a descrição dos testes realizados com este ambiente e as devidas considerações finais sobre o
trabalho realizado.

1.1– MOTIVAÇÃO

Como foi dito anteriormente este trabalho foi realizado como um estudo e
testes utilizando ferramentas livres para prover alta disponibilidade dos sistemas web
desenvolvidos na Infoway. Este estudo se deu devido a vários problemas que vinham

11

acontecendo na infraestrutura da empresa tanto a nível de hardware quanto a nível de
software, tais problemas são estes: indisponibilidade de aplicações em alguns momentos
devidos a pouco espaço de memória física no servidor e consequentemente pouco espaço na
memória destinado para o Tomcat, falha no hardware, podendo causar perda de dados e
atrasos nas atividades dos usuários que utilizam os sistemas ocasionando uma insatisfação por
parte do usuário e clientes.
Além dos problemas informados, a principal motivação para este estudo é gerar
maior satisfação para usuário, pois se pretende deixar o sistema sempre disponível, fazer
atualizações no sistema sem ter que parar o mesmo para realizar esta operação de modo que
isto fique transparente para o usuário final.

1.2 – JUSTIFICATIVA

Devido à deficiência quanto à disponibilidade de algumas aplicações web java,
foi observado que em vários momentos determinadas requisições carregavam uma grande
massa de dados que ocasionava falta de espaço na memória destinada ao Tomcat que por sua
vez parava de funcionar fazendo com que a aplicação ficasse indisponível. Outro problema
observado foi que qualquer falha de hardware, como por exemplo, falha de um disco rígido, o
sistema além de indisponibilizar acesso aos dados armazenados, corria um risco de serem
perdidos.
Este trabalho propõe a resolver todos estes problemas, que foram descritos
acima, implementando uma solução de cluster de servidores web com balanceamento de carga
e replicação de banco de dados.

1.3 – OBJETIVOS

Os objetivos gerais e específicos serão mostrados a seguir.

1.3.1– OBJETIVO GERAL

12

O presente trabalho pretende construir um ambiente de servidores em cluster
com o uso de ferramentas livres de modo que tenha sistemas web com alta disponibilidade em
um baixo custo.

1.3.2 – OBJETIVOS ESPECÍFICOS

• Configurar dois servidores Tomcat’s para funcionarem em cluster.
• Configurar o apache para fazer o balanceamento de carga utilizando o
mod_proxy e o mod_proxy_balancer.
• Configurar o SGBD Mysql para fazer replicação master-slave.
• Testar a disponibilidade e a performance de uma aplicação web java no
ambiente configurado.

13

2 - REFERÊNCIAL TEÓRICO

2.1 - TOMCAT

O Tomcat é um software livre e open source que atua como um servidor web
ou pode funcionar junto a um servidor web como Apache ou ISS. O Tomcat surgiu dentro do
conceituado projeto Apache Jakarta e que teve apoio oficial da Sun Microsystem como
implementação de referencia para aplicações Java Servlet e Java Server Pages. Atualmente o
Tomcat tem seu próprio projeto de desenvolvimento independente dentro da Apache Software
Fundation (APS) (TOMCAT, 2011).
Técnicamente o Tomcat é um container web da plataforma Java Entreprise
Edition (JEE) e que abrange as tecnologias servlet e jsp, incluindo as tecnologias de apoio
relacionadas como Realms e segurança, JNDI Resources e JDBC Data Sources
(GONÇALVES, 2006).

2.2 -APACHE

O apache é um servidor web HTTP com código livre mundialmente utilizado.
Foi inicialmente desenvolvido na NCSA (National Center of Supercomputing Applications),
por Rob McCool. Após a saída de Rob McCool da NCSA, o apache passou a ser
desenvolvido por um grupo de pessoas espalhadas no mundo todo (APACHE, 2011). O
apache é extremamente configurável, robusto e de alto desempenho.
Abaixo está algumas características que fazem desse servidor web o preferido
entre os administradores de sistemas (RIBEIRO, 2005):
• Possui suporte a scripts CGI usando linguagens como Perl, PHP, Shell Script,
ASP, etc.
• Autenticação requerendo um nome de usuário e senha válidos para acesso a
alguma página/sub-diretório/arquivo. Suporte à autorização de acesso, podendo
ser especificadas restrições de acesso separadamente para cada
endereço/arquivo/diretório acessado no servidor;

14

• Suporte a virtual hosting, por nome ou endereço ip: é possível servir dois ou
mais páginas com endereços/portas diferentes através do mesmo processo, ou
usar mais de um processo para controlar mais de um endereço.
• Suporte a servidor proxy, FTP e http, com limite de acesso, caching (todas
configuráveis). Suporte a redirecionamentos baseados em URLs para
endereços internos.
• Suporte a criptografia via SSL, certificados digitais;
• Negociação de conteúdo, permitindo a exibição da página web no idioma
requisitado pelo cliente.
• Suporte a tipos mime.
• Personalização de logs.

2.3 - MYSQL

O SGBD Mysql é um servidor e gerenciador de banco de dados relacional,
projetado inicialmente para trabalhar com aplicações de pequeno e médio porte e que utiliza a
linguagem SQL como interface. O Mysql teve origem quando os desenvolvedores David
Axmark, Allan Larsson e Michael “Monty” Widenius, na década de 90, precisaram de uma
interface SQL compatível com as rotinas ISAM que utilizavam em suas aplicações e tabelas.
Em um primeiro momento, tentaram utilizar a API Mysql, contudo a API não era tão rápida
quanto eles precisavam, pois utilizavam rotinas de baixo nível (MILANI, 2007).
Este SGBD está sendo utilizado neste trabalho, pois ele possui várias
vantagens, dentre as quais são:
• É um dos SGBD’S mais utilizados no mundo;
• A replicação é feita de forma simples e completa
• Interface gráficas de fácil utilização;
• Portabilidade;
• Facilidade de uso

2.4 - TOLERÂNCIA A FALHAS

15

Sistemas computacionais falham ocasionalmente. Quando uma falha ocorre, os
serviços podem produzir resultados incorretos, podem parar antes de completar o seu
processamento ou até mesmo não responder as requisições vinda dos clientes.
Um sistema computacional tolerante a falhas permite que um servidor contorne
falhas de todos os tipos (incluindo falhas de hardware e de software) mantendo assim o
trabalho de responder as requisições dos clientes de forma transparente, sem que o cliente
saiba que alguma falha tenha acontecido (COSTA, 2008).
Dentre as técnicas utilizadas para o tratamento de falhas podemos citar
(CORREIA, 2005):
• Detecção de falhas: alguns tipos de falhas podem ser detectados. Outros, entretanto,
são mais difíceis de detectar como, por exemplo, um servidor na Internet que tenha
“quebrado”. O desafio é manter o sistema funcionando na presença de falhas que não
possam ser detectadas, mas que podem ser suspeitas.
• Mascaramento de falhas: algumas falhas podem ser escondidas ou pode ser possível
diminuir os seus danos. Uma mensagem pode ser retransmitida em caso de perda, por
exemplo.
• Recuperação de falhas: envolve o desenvolvimento de sistemas capazes de armazenas
os estados de dados permanentes, possibilitando a recuperação dos mesmos após uma
falha ou então retroceder o sistema a um estado consistente (rollback).
• Tolerância a falhas e Redundância: serviços podem se tornar tolerantes a falhas
utilizando componentes redundantes (replicas). O desenvolvimento de técnicas para a
manutenção dos dados atualizados nas replicas sem perda excessiva de desempenho é
um desafio.

2.5 - ALTA DISPONIBILIDADE

Um sistema de alta disponibilidade é aquele que utiliza mecanismos de
detecção, recuperação e mascaramento de falhas, visando manter o funcionamento dos
serviços durante o máximo de tempo possível.
Segundo Costa (2008), em sua monografia intitulada “Uma solução com uso de
ferramentas livres para sistemas web de alta disponibilidade” diz que um serviço que está

16

sempre ativo, sempre disponível, sempre atendendo às requisições e que pode servir a uma
grande quantidade de carga concorrentemente é chamado de altamente disponível. Um
sistema de alta disponibilidade deve ser tolerante a falhas caso contrário o sistema ficará
indisponível.
Como falhas são inevitáveis em ambientes computacionais, são utilizadas
técnicas para garantir a disponibilidade dos recursos de sistemas críticos, mesmo na presença
de falhas. Estas técnicas podem ser tanto em nível de hardware quanto de software. Em
hardware, procura-se utilizar redundância e equipamentos, para que um componente em falha
seja compensado por outro. Já em software, clusters são desenvolvidos com configurações
que permitem atingir comportamento similar em nível de hardware: a falha de um servidor é
compensada pela migração dos recursos comprometidos para o outro servidor operante
(PEREIRA, 2004).

2.6 - SISTEMAS DISTRIBUÍDOS

Sistemas distribuídos é o termo utilizado para definir componentes de hardware
ou software, que localizados em computadores interligados em rede, se comunicam e
coordenam suas ações apenas enviando mensagens entre si. Esta definição é bastante simples
e abrange toda a gama de sistemas nos quais computadores interligados em rede podem ser
distribuídos de maneira útil. (SIMOMURA, 2009).
Um aspecto importante dos sistemas distribuídos é o compartilhamento de
recursos, os aplicativos clientes invocam operações em recursos que frequentemente estão em
outro servidor (COLOURIS et AL, 2007).

2.7 - BALANCEAMENTO DE CARGA

Quando as requisições chegam a sistemas distribuídos, elas necessitam de um
mecanismo que possa distribuir as requisições de modo que um servidor não fique
sobrecarregado ao receber mais requisições que outro. Um serviço de balanceamento de carga
é capaz de encaminhar requisições dentro de um cluster, garantindo a utilização nivelada de
todos os recursos computacionais (COSTA, 2008).

17

Os sistemas de cluster baseado em balanceamento de carga integram seus
servidores para que todas as requisições provenientes dos clientes sejam distribuídas de
maneira equilibrada entre estes. Os sistemas não trabalham junto em um único processo, mas
redirecionando as requisições de forma independente, assim que chegam baseados em um
escalonador e um algoritmo próprio.

2.8 - REPLICAÇÃO

Uma técnica de tolerância a falhas é replicação, uma redundância útil utilizada
para garantir a disponibilidade do sistema de forma que se uma das réplicas produzidas
falharem, e remanescentes poderão continuar a prover o serviço. Essa técnica é utilizada para
melhorar serviços e as motivações para seu uso são a melhoria do desempenho de um serviço,
aumento da sua disponibilidade e tornar um serviço tolerante a falhas (SILBERSCHATZ,
2001).
A replicação induz ao problema de consistência de réplicas: quando um objeto
é alterado, suas réplicas também precisam ser atualizadas, para manter um estado distribuído
consistente (PASIN, 2003, p.44). Para satisfazer essa consistências, um protocolo de
replicação precisa obedecer às seguintes propriedades (GUERRAOUI, 1997, p.69 citado por
PAZIN, 2003, p.44):
• Ordem: operações de atualização concorrentes, enviadas por diferentes clientes,
devem ser executadas na mesma ordem por réplicas distintas;
• Atomicidade: quando uma réplica realiza uma operação de atualização, todas as
demais réplicas também devem realizar esta operação.
Quando se utiliza um serviço que provém replicação alguns requisitos devem
ser levados em consideração no que diz respeito ao cliente. Este deve acessar um dado
replicado da mesma forma que acessaria o original, ou seja, sem perceber qualquer tipo de
mudança, mantendo-se a consistência dos dados replicados garantindo que mesmo após a
ocorrência de falhas as replicas possam prover o serviço a partir do estado em que o
componente primário se encontrava (FRANIVAM, 2011).

2.9 - CLUSTER

18

Um cluster é um conjunto de dois ou mais servidores que trabalham juntos, de
forma transparente, para servirem requisições aos clientes. O objetivo do cluster neste é
prover alta disponibilidade para os clientes dentro da rede (COSTA, 2008).
Segundo DEITEL et AL (2005, p.538) existem três tipos de clusters:
• Cluster de alto desempenho: todos os nós do cluster são usados para
executar trabalho;
• Cluster de alta disponibilidade: alguns servidores realização trabalho
enquanto outros servem como reserva (backup). Se um dos servidores
falhar, os nós de reservar começarão a executar e assumir
imediatamente os trabalhos que estavam em execução nos servidores
que falharem sem interromper o serviço
• Cluster de balanceamento de carga: um nó funciona como um
balanceador de carga para distribuir carga a um conjunto de servidores
de modo que todo hardware seja utilizado eficientemente.
Em geral, a utilização de clusters existe para facilitar o uso da alta
disponibilidade e/ou tolerância a falhas. Balanceamento de carga e replicação dos estados das
sessões são dois elementos muito importantes do cluster neste projeto.

2.10 - TRABALHOS RELACIONADOS

Segundo Costa (Costa, 2008), este propõe uma solução de clusters de
servidores web utilizando o apache como balanceador de carga e os Tomcat’s trabalhando em
clusters, o mesmo aplicou esta solução no site do Tribunal de Justiça do Estado do Piauí.
Franivam (Franivam, 2011) propõe uma técnica de tolerância a falhas para o
sistema Jazida, um sistema de indexação e busca de documentos de texto e imagem. O
sistema Jazida funciona baseado em cluster e neste sistem foi desenvolvida uma política de
tolerância a falhas onde existe um componente chamado Cluster Service que envia
notificações para cada data node verificando se algum node está inacessível e o mesmo elege
outro para assumir o node que está inacessível.

19

3 - PROPOSTA DE UM AMBIENTE DE ALTA-DISPONIBILIDADE

3.1 - CENÁRIO

O cenário utilizado para a criação do ambiente de alta disponibilidade utiliza a
versão 6.0.35 do Tomcat, o apache 2.2 e o Mysql 5.0.95. Atualmente um dos maiores
sistemas desenvolvidos pela empresa está hospedado em um determinado servidor e as
demais aplicações menores estão hospedados em outro servidor, caso ocorresse alguma falha
de hardware ou software em algum desses servidores, o sistema ficaria indisponível até que o
problema seja resolvido, podendo acarretar também a perda de dados em caso de falha nos
arquivos de banco de dados.
Para construção deste cenário será feito uma duplicação da hospedagem da
aplicação onde dois Tomcat’s ficam em servidores distintos que respondem ao mesmo tempo
as requisições vinda dos usuários.
O apache ficará responsável por fazer o balanceamento de carga das
requisições, realizando um controle sobre o acesso aos Tomcat’s, assim parte das requisições
vai para um Tomcat e parte das requisições vai para outro, garantindo que nenhum Tomcat
fique sobrecarregado quanto ao número de requisições. Caso um Tomcat pare de funcionar o
apache encaminha os acessos para outro Tomcat que estiver ativo.
Para garantir que os dados não sejam perdidos, se ocorrer alguma falha de
hardware ou software, será implementado uma política de replicação do banco de dados do
sistema onde temos um banco principal, chamado de master, que replica os dados para o
banco secundário, chamado de slave. Se o master falhar, rapidamente o slave é posto em
produção passando a ser banco de dados master.
Assim temos uma solução que garante a disponibilidade do sistema e dos
dados. A Figura 1 representa o cenário proposto neste projeto.

20

Figura 1: Cenário proposto neste projeto

Neste projeto as requisições vinda do usuário vão para o balanceador de carga
com o endereço, http://192.168.56.102/orbis e o mesmo desviará as requisições para os dois
servidores web http://192.168.56.102:8081/orbis e http://192.168.56.103:8082/orbis. Estes endereços
mencionados anteriormente respondem pela aplicação web chamada orbis, esta aplicação será
utilizada nos testes para a construção do ambiente que foi mencionado anteriormente. Existe
também um servidor de banco de dados master e outro servidor de servidor de banco de dados
slave onde este armazenará a réplica dos dados do master.

3.1.1 - Informações sobre o ambiente utilizado

O ambiente para implementação do projeto será utilizado em duas máquinas
virtuais onde as características estão descritas abaixo:
• Servidor 1:

21

o Ip: 192.168.56.102;
o Sistema Operacional: CentOS 5.8 x86_64;
o Nome do Host: master;
o Memória RAM: 1 GB;
o Aplicativos:
Balanceador de carga, com apache;
TomcatA;
Banco de dados Mysql denominado máster;
• Servidor 2:
o Ip: 192.168.56.103;
o Sistema Operacional: CentOS 5.8 x86_64;
o Nome do Host: slave;
o Memória RAM: 1GB;
o Aplicativos:
TomcatB;
Banco de dados Mysql denominado slave;

3.2 – TOMCAT-CLUSTER

O cenário deste projeto hospedará uma aplicação desenvolvida em Java. Neste
ambiente dois Tomcat’s estarão replicando as suas sessões abertas em cada nó do cluster,
assim cada nó irá conter suas próprias sessões e atributos e as sessões abertas dos demais nós
do cluster, como mostra a Figura 2.

Figura 2: Replicação de sessões

22

O tomcat-cluster permite que se um nó falhe, as requisições vinda dos clientes
para este nós sejam desviadas para um nó ativo sem que o usuário perceba, pois sua sessão
continuará ativa nos demais nós do cluster.

3.2.1 - Requisitos

Para realizar a replicações das sessões entre os nós do cluster alguns pontos
devem ser verificados:
• Todos os atributos das sessões devem implementar java.io.Serializable;
• Habilitar o elemento cluster do arquivo server.xml dentro de cada Tomcat;
• Habilitar o elemento Valve (ReplicationValve) no arquivo server.xml;
• Ter no arquivo web.xml o atributo <distributable/> ou definir uma propriedade na
configuração do contexto da aplicação no arquivo server.xml com <Context
distributable=”true”>;
• Definir um nome diferente para o atributo jvmRoute no arquivo server.xml como
<Engine name=”Catalina” jvmRoute=”node01” >;
• Configurar o balanceador de carga com a opção stcky session ativa, para manter as
requisições vindas de um mesmo usuário do sistema indo para um mesmo nó do
cluster. (Tomcat)
Na versão utilizada neste projeto, o Tomcat realiza uma replicação de sessão
todos-para-todos. O algoritmo utilizado tem uma eficiência melhor em cluster de pequeno
porte, pois em grandes cluster a quantidade de informações trafegadas entre os nós seria
enorme e isso afetaria o desempenho da aplicação. A solução para este problema é fazer a
divisão de um cluster de grande em vários grupos de cluster menores utilizando endereços de
multicast diferentes para cada cluster menor.
Vale lembrar que a replicação de sessão é apenas uma característica entre
várias características do cluster de Tomcat. Outra característica importante é que não é
necessário realizar uma instalação ou atualização de uma aplicação em todos os nós do
cluster, isto é feito em apenas um dos nós, que automaticamente, esta tarefa será realizada nos
demais componentes do cluster.

23

3.2.2 – Arquitetura

O cluster de tomcat utiliza quatro componentes: Receiver, Sender,
Membership, Valve e Deployer.
O Receiver é responsável por receber conexões vindas de outros nós do cluster,
para que com isso, seja feita as trocas de sessões entre eles utilizando-se de uma porta TCP
definida durante a configuração do cluster. O Tomcat fica escutando nesta porta aguardando o
envio de sessões vindo de outros nós (APACHE, 2011).
O Sender é o componente responsável pelo envio das sessões para outro
Tomcat. Ele se conecta ao Receiver de outro Tomcat e envia suas sessões.
O Membership é o responsável por, através de pacotes de multicast, realizar a
parceria entre os nós. Com esse componente, os nós são inseridos e removidos do cluster.
O Valve é o componente responsável por detectar quando uma requisição foi
completada e a partir disto a replicação desta sessão ocorra e a resposta enviada ao usuário.
O Deployer é responsável por deixar automática a gerencia das aplicações no
cluster. Se o administrador do servidor desejar hospedar uma nova aplicação no cluster, não é
necessário que seja feita a instalação da aplicação em todos os nós, pois ao se inserir a nova
aplicação, o Deployer fará a cópia desta aplicação para todos os outros nós do cluster. Isso
também vale para as atualizações e remoções de aplicações.

3.2.3 – Funcionamento

Para entender como um cluster funciona a Figura 3 mostra todo o processo de
replicação de sessão de um cluster composto por um Tomcat A e um Tomcat B que recebe
requisições no decorrer do tempo.

24

Figura 3: Funcionamento do Tomcat-Cluster

Na imagem acima o Tomcat A inicializa utilizando uma sequencia padrão de
inicialização. Se o web.xml da aplicação conter o elemento distributable, o Tomcat requisita à
classe Cluster (no caso atual a classe SimpleTcpCluster) a criação de um gerenciador para o
contexto replicado, a partir deste momento o cluster é ativado e o Tomcat irá criar um
DeltaManager para o contexto, ao invés de um StandardManager. A classe cluster, através de
uma comunicação multcast inicializará um Membership Service e um Replication Service
utilizando TCP Unicast.
Quando o Tomcat B inicializa, este segue a mesma sequencia do Tomcat A,
com uma pequena diferença: o cluster é inicializado e então haverá uma parceria entre os
servidores onde cada instancia de Tomcat irá periodicamente enviar um ping multicast
contendo seu IP e sua porta TCP utilizadas na replicação, se não foi recebido nenhum ping
vindo de um determinado nó durante um tempo limite, este nó é considerado morto. O
Tomcat B requisita os estados de sessão do Tomcat A e este só responderá ao pedido assim
que o Tomcat B finalizar sua inicialização ficando pronto para receber as conexões vinda dos
usuários.

25

O Tomcat A recebe a primeira requisição, uma sessão S1 será criada e esta é
tratada da mesma forma que uma requisição sem replicação de sessão. A replicação acontece
depois que a resposta está pronta e a partir dai o ReplicationValve irá interceptar a resposta
antes de ser enviada para o usuário. Uma vez que é feita a replicação de sessão, a resposta é
enviada ao usuário. Quando o Tomcat A falhar o B recebe uma notificação de que o mesmo
foi excluído do cluster, fazendo com que o Tomcat B remova o A da lista de participantes do
cluster, as sessões não serão replicadas e o balanceador irá desviar as requisições destinadas
para o Tomcat A.
Quando o Tomcat A reinicializa, este recebe uma requisição e uma instrução
de finalização da sessão S1. Quando o pedido de fim de sessão é recebido, o Tomcat A
invalida aquela sessão e o mesmo enviará uma mensagem de sessão S1 expirou para o Tomcat
B e o mesmo invalidará a sessão S1. Neste caso, somente o status de sessão S1 que é
replicado. O Tomcat B recebe uma nova requisição e uma nova sessão S2 é criada seguindo o
mesmo processo de replicação de sessão descrito acima.
Todo o processo de replicação ocorre utilizando conexões TCP. Uma vez que
um ping multicast é recebido, o nó de origem do ping é adicionado ao cluster. Utilizando as
informações vinda da comunicação multicast, os nós estabelecem conexões TCP para, através
destas, realizar a replicação das sessões. O propósito da utilização do protocolo TCP, é que
ele garante a entrega dos pacotes e realiza controle de fluxo. Assim fica garantida a entrega
das mensagens de replicação.

3.2.4 - Configuração

Para preparar os Tomcat’s para o cluster, é realizada a edição do arquivo de
configuração server.xml, localizado no diretório conf do Tomcat, A Figura 4 mostra o trecho
de configuração do cluster.

26

Figura 4: Trecho de configuração do cluster no arquivo server.xml

Este trecho já vem padrão da versão do Tomcat, segue abaixo a Tabela 1 onde
foi realizada a configuração nos referidos servidores para identificar os nós do cluster.

Tomcat A Tomcat B
<Membership...> <Membership...>
address=”228.0.0.4” address=”228.0.0.4”
port=”45564” port=”45564”
<Receiver...> <Receiver...>
address=”192.168.56.102” address=”192.168.56.103”
port=”4000” port=”4001”
Tabela 1: Configuração para identificar os nós no cluster

27

Em ambos os Tomcat’s temos as tag’s Membership e Receiver com os seus
respectivos endereços e portas. No Membership o endereço de multcast é o 228.0.0.4 e a porta
utilizada para envios dos pings de multicast é a 4556. No Receiver temos o endereço que
indica o ip de cada servidor. No Tomcat A o ip é 192.168.56.102 e a porta 4000 utilizados
para receber conexões do servidor http://192.168.56.103:8082/orbis. No Tomcat B temos o ip
192.168.56.103 e a porta 4001 utilizados para receber as conexões vinda do servidor
http://192.168.56.102:8081/orbis.
Após estas configurações têm-se dois servidores Tomcat configurados para
trabalhar em cluster e realizar a replicação das sessões.

3.3 – CONFIGURAÇÃO DO BALANCEADOR DE CARGA

Como já foi dito anteriormente o apache ficará responsável em realizar o
balanceamento de carga entre os dois Tomcat’s. Este receberá as requisições vinda dos
usuários e o mesmo enviará as requisições para cada Tomcat de acordo com o número de
requisições.
Neste projeto foram desenvolvidas várias funcionalidades para o servidor
apache, uma delas é a de se trabalhar como um servidor Proxy recebendo as requisições dos
usuarios, fazendo a comunicação com o servidor de destino e passando a resposta de volta
para os usuarios. Esta funcionalidade só é possível através do módulo mod_proxy do apache.
Junto ao mod_proxy, tem-se outro módulo chamado de mod_proxy_balancer,
este permite que seja feito um balanceamento de carga entre vários servidores web, como
mostra a Figura 5.

28

Figura 5: Balanceamento de Carga

O site www.siteexemplo.com sendo o balanceador de carga receberá as
requisições e repassará essas requisições para os servidores web onde realmente está
hospedada a aplicação. Com o mod_proxy_balancer é possível definir qual servidor irá
receber a maior quantidade de conexões, garantindo que um servidor com um desempenho
maior receba mais requisições que um servidor com um desempenho menor.

3.3.1. – O Módulo mod_proxy

Este módulo transforma o apache em um proxy/gateway, com ele o apache
passa a trabalhar como um proxy ftp, http e ssl (APACHE, 2011).
O apache, como proxy, pode ser configurado em dois modos: Foward e
Reverse. Um Foward Proxy é um servidor intermediário que fica entre o cliente e o servidor
de origem. Para que um cliente requisite uma página web, ele envia uma requisição para o
servidor Proxy que requisita o conteúdo pedido ao servidor de destino e retorna a resposta ao

29

cliente. O cliente deve ser configurado para utilizar o Foward Proxy para poder navegar na
web. É comum se utilizar o Forward Proxy como provedor de acesso a internet para redes. A
Figura 6 mostra um exemplo de funcionamento do Forward proxy.

Figura 6: Funcionamento do Forwad Proxy

O Forward Proxy é ativado utilizando a diretiva “ProxyRequests On”. Devido
o Forward Proxy prover acesso a sites através de um servidor e de esconder a verdadeira
origem do acesso, é importante que seu administrador limite o acesso a somente aqueles
usuários que forem autorizados.
Um Reverse Proxy, ao contrário do Forward Proxy, aparece ao usuário como
um servidor web comum. Não é necessária nenhuma configuração no cliente, o usuário faz
requisições normais ao Reverse Proxy. O Reverse Proxy então decide para onde enviar estas
requisições e retorna o conteúdo da resposta ao cliente. A Figura 7 mostra um exemplo de
funcionamento do Reverse Proxy.

30

Figura 7: Funcionamento do Reverse Proxy

Reverse Proxy é comumente utilizado para permitir que usuários acessem
servidores que se encontram atrás de firewall’s. O Reverse Proxy pode também ser utilizado
como balanceador de carga entre vários servidores finais ou para prover um cache para
servidores finais mais lentos. Um Reverse Proxy é ativado utilizando a diretiva ProxyPass.

3.3.2. – O Módulo mod_proxy_balancer

Este módulo simplesmente provê um serviço de balanceamento de carga para
protocolos HTTP, FTP e AJP13. Sua utilização depende do uso do mod_proxy (APACHE,
2011). Atualmente existem dois métodos de balanceamento de carga, por quantidade de
requisições e outro que leva em conta a quantidade de informações trafegada para cada
servidor.

31

Aqui um exemplo de como pode ser configurado um balanceador de carga no
apache:

<Proxy balancer://balancer>
BalancerMember http://192.168.1.3:8080
BalancerMember http://192.168.1.4:8081
</Proxy>
ProxyPass /test balancer://balancer/

Neste exemplo tem-se um balanceador chamado de balancer contendo dois
elementos, http://192.168.1.3:8080 e http://192.168.1.4:8081. Na linha “ProxyPass /test
balancer://balancer” é feita a configuração do mod_proxy para que todo acesso ao contexto
/test seja feito através do balanceador de carga balancer.

3.3.4 – Configuração

A instalação do apache é feita durante a instalação do CentOS do servidor, no
momento da instalação, foi marcada a opção de instalar os pacotes para servidores web,
contendo o apache e vários outros recursos, como suporte a php e vários módulos incluindo o
mod_proxy e o mod_proxy_balancer.
A partir do cenário descrito no inicio deste projeto, temos a Figura 8 que
mostra o trecho do arquivo de configuração do apache, httpd.conf:

32

Figura 8: Virtual Host

A figura acima mostra a configuração de um virtual host que será responsável
pelo recebimento das requisições destinadas ao endereço http://192.168.56.102/orbis
A opção ServerName determina o nome do virtual host, neste caso
192.168.56.102. Em ProxyRequest off, dizemos ao apache que não será utilizado como um
servidor proxy ou um Reverse Proxy, não atendendo a requisições de sites diferentes do
sistema.
Na linha abaixo:

ProxyPass /orbis balancer://balancer/sticksession=JSESSIONID no failover=Off

É dito ao apache que qualquer requisição destinada ao contexto /orbis dentro
do sistema, será utilizado o balanceador de carga para atender as demandas.
Com a opção stickysession=JSESSIONID, o apache irá direcionar os pedidos
de uma mesma sessão para o servidor. A opção nofailover=Off, determina que os membros
pertencentes ao balanceador de carga têm a capacidade de superar uma falha de um dos
membros, com isso, se for detectado um membro inativo, o apache irá desviar todas as
requisições antes enviadas a este membro, para um outro membro.
As opções abaixo são diretrizes para corrigir as respostas vinda dos servidores
balanceados, baseando-se na requisição original vinda do cliente.

33

ProxyPassReverse /orbis http://192.168.56.102:8081/orbis
ProxyPassReverse /orbis http://192.168.56.103:8082/orbis

Nas linhas seguintes são descritas a configuração onde é declarado o
balanceador de carga e os seus membros com suas devidas características como nome da rota
e fator de carga.

<Proxy balancer://balancer>
BalancerMember http://192.168.56.102:8081/orbis route=node01 loadfactor=1
BalancerMember http://192.168.56.103:8082/orbis route=node02 loadfactor=1
</Proxy>

Esta configuração declara para o balanceador que no cluster tem dois membros,
o http://192.168.56.102:8081/orbis e o http://192.168.56.103:8082/orbis. A opção loadfactor
determina qual carga cada membro receberá em relação aos demais membros, como por
exemplo, se um membro estiver com loadfactor igual a 1 e o outro membro estiver com
loadfactor igual a 2, este ultimo irá receber uma carga duas vezes maior que o primeiro.
A opção ProxySet lbmethod determinará para o balanceador o tipo de
balanceamento de carga será utilizado. Pode ser utilizado o método de balanceamento por
quantidade de requisições com lbmethod=byrequests onde tem-se que cada requisição irá para
servidores diferentes, ou pode utilizar pela quantidade de tráfego com lbmethod=bytraffic,
onde os membros sendo acessados por links diferentes a carga de cada membro deverá ser
definida de acordo com a largura de banda do seu link, ou seja, se uma requisição que
carregar uma grande quantidade de bytes para um servidor as próximas requisições de sessões
diferentes serão destinadas para os demais membros do balanceamento até que este fique
liberado para receber as próximas requisições. O método mais recomendado é o bytraffic,
porém não se aplica neste projeto, pois além de ser uma aplicação de teste, esta não ainda é
uma aplicação de pequeno porte e por este motivo utilizado o método byrequests.
Com esta configuração, temos um servidor Apache realizando o balanceamento
de carga em dois Tomcat’s no sistema orbis.

34

3.4 - REPLICAÇÃO NO MYSQL

A replicação de dados permitirá que, no caso de um servidor X falhar, com
uma pequena mudança de no endereçamento dos ip’s dos servidores Mysql o sistema possa
voltar a funcionar em tempo hábil, e o mais importante sem perda de dados.
Assim, os principais objetivos de se utilizar a replicação de dados neste projeto
são:
• Evitar perda de dados em caso de falhas de hardware ou software;
• Evitar que o sistema fique por muito tempo fora do ar aguardando uma
recuperação dos dados perdidos através de backups
Um bom sistema de replicação de dados é uma técnica valiosa para ajudar com
os backups, porém não substitui uma boa politica de backup, pois qualquer comando errado
executado no servidor X será executado no servidor Y, inclusive um “drop database”. Sempre
deve ser feito backup.

3.4.1 – Funcionamento

A replicação de dados é feita de forma assíncrona, não é necessário que um
servidor slave fique continuamente conectado ao master. Ela funciona através do uso de um
mecanismo de log binário. Em resumo, a replicação e um simples processo de três partes
(SCHWARTZ et al 2009):
1. O master registra alteração aos seus dados no seu log binário.
2. O slave copia os eventos de log binário do master para o seu relay log.
3. O slave repete os eventos no seu relay log, aplicando as alterações nos seus
próprios dados.
A Figura 9 mostra todo esse processo de replicação.

35

Figura 9: Funcionamento da Replicação

A primeira parte do processo é log binário no master. Antes de cada transação
que atualiza dados no master, este registra as alterações no seu log binário. No próximo passo,
o slave copia o log binário do master para o seu próprio disco rígido, chamado de relay log.
Para copiar o log binário, o slave inicia uma worker thread (tarefa), chamada
de thread I/O. A thread de I/O abre uma conexão do cliente ao master e inicia um processo de
esvaziamento de binlog. O processo de esvaziamento de binlog lê o evento a partir do log
binário. A thread de I/O escreve os eventos no relay log do escravo.
Na ultima parte do processo, os eventos copiados para o relay log são repetidos
atualizando os dados no servidor slave, através da thread SQL, para combinarem com os do
master. E assim todos os eventos ocorridos das bases de dados do master serão executados nas
bases de dados do slave.
Inicialmente, para a criação da replicação, deve ser feito um backup das bases
que serão replicadas no master. Após ter sido gerado o backup, a criação do log binário deve
ser habilitada e assim todos os comandos executados no master ficarão gravados neste log. O
backup será restaurado em cada servidor slave.
Não é possível configurar o master para que ele grave somente certos
comandos. Fica a cargo do slave decidir quais comandos ele deverá executar localmente. No
slave são configuradas quais bases de dados ou tabelas serão replicadas. Durante a leitura e

36

execução do log, o slave guarda o log lido e a posição do ultimo comando executado. Com
isso, é possível que diferentes slaves executem diferentes partes do mesmo log.
Cada servidor que participa da replicação, master e slaves, devem ter uma
identificação única através da opção server-id. Os slaves devem ser informados do nome do
host ou ip do servidor master, nome do log e quais bases de dados serão replicadas.

3.4.2 – Configuração

A configuração do servidor master e do servidor slave foi feita através da
edição do arquivo my.cnf que fica dentro do diretório “/etc/” no servidor. A seguir são
mostrados todos os passos para a configuração do servidor para realizar replicação.
Como falado anteriormente, deve ser feita um backup da base de dados do
servidor master. Em seguida é necessário ativar a geração do log binário no servidor master,
lembrando que a aplicação deve está parada pois uma atualização na base sem a geração do
log haverá falta de sincronismo do conteúdo das bases de dados nos servidores em questão.
A opção no arquivo my.cnf que habilita a geração do log binário é:

log-bin = mysql-bin

Para identificar o servidor master utiliza-se a opção descrita abaixo:

server-id = 1

Depois de realizado a inserção destas opções no arquivo de configuração do
mysql, este deve ser reiniciado para aplicar as alterações.
Para acontecer à replicação, o servidor slave fará uma conexão com o servidor
master, para que isso seja possível, deve-se criar um usário com permissões de replicação na
base de dados que será replicada. Segue abaixo as informações dos servidores:
• Base de dados replicada: orbis
• Ip do servidor slave: 192.168.56.102
• Nome do usuário: replica
• Senha: replica

37

Com base nessas informações, deve-se execultar os seguintes comandos para
configura o mysql com slave:

GRANT REPLICATION SLAVE ON orbis.* TO ‘replica’@’192.168.56.103’
IDENTIFIED BY ‘replica’;

Aqui, será adicionada permissão de replicação para o usuário replica em todas
as tabelas do banco orbis com o ip do servidor slave 192.168.56.103. O próximo passo é
restaurar a base de dados que vai ser replicada, que anteriormente foi realiado o backup no
servidor slave. Em seguida é necessário editar o arquivo my.cnf e adcionar as seguintes
opções:

log-bin = mysql-bin
server-id = 2
relay_log = mysql-relay-bin
log_slave_update = 1

As duas opções, log-bin e server-id segue a mesma definição das opções
configurada servidor master. Foi adicionado duas opções de configuração adicionais:
relay_log que serve para especificar a localização e o nome do relay-log, e
log_slave_updates, que diz para o slave logar os eventos replicados para o seu próprio log
binário.
Depois de editado o arquivo de configuração do Mysql, é necessário informar
ao servidor slave como conecta-se ao servidor master e começar a repetir seus logs binários.
Para isso é utilizado a expressão “CHANGE MASTER TO”. Esta expressão permite que se
aponte o slave a um master diferente sem parar o servidor. Neste projeto foi utilizado a
seguinte expressão básica, que foi executado no servidor slave;

CHANGE MASTER TO MASTER_HOST='192.168.56.102',
MASTER_USER='replica', MASTER_PASSWORD='replica',
MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=0;

38

Aqui a opção MASTER_HOST, define o endereço do servidor master, as
opções MASTER_USER e MASTER_PASSWORD definem o usuário e senha que possui a
permissão de replicação. MASTER_LOG_FILE é o nome do primeiro log binário que foi
gerado e por fim a opção MASTER_LOG_POS é configurado em 0 pois este é o inicio do
log.
Os servidores de banco de dados estão configurados para realizarem replicação
porém ainda não é possível que o servidor slave realize replicação, pois os processos do slave
não estão rodando. Para iniciar a replicação, é preciso executar o comando abaixo:
mysql> START SLAVE;
Para ter a confirmação de que a replicação esta realmente funcionando, o
comando SHOW SLAVE STATUS mostra toda a configuração do servidor slave, a Figura
10 mostra o resultado desse comando:

Figura 10: Saida do comando SHOW SLAVE STATUSG;

O parâmetro Slave_IO_State mostra o estado da replicação, que está
funcionando perfeitamente, outros dois parâmetros importantes são Slave_IO_State e
Slave_IO_Running que mostram que os processos de replicação estão rodando.
É possível verificar as threads de replicação na lista de processos no master e
no slave. A Figura 11 mostra no master uma conexão criada pela thread de E/S do slave:

39

Figura 11: Threads de replicação

No slave, a Figura 12 mostra duas treads, uma é a thread de E/S, e a outra é a
thread SQL:

Figura 12: Threads de E/S e Thread SQL

40

E com isso pode-se observar que a replicação entre dois servidores de banco de
dados estão funcionando perfeitamente de acordo com o que foi proposto.

4. – TESTES E RESULTADOS

Após, realizado toda a configuração dos servidores, foram executados vários
testes com o objetivo de verificar se todos os elementos do projeto estão funcionando
corretamente. Foram executado também, testes de performance, afim de identificar se a
solução de cluster de servidores além de proporcionar alta disponibilidade, ela também
aumenta a performance do sistema.
Para realização dos testes, foi utilizado o Psi Probe, uma ferramenta open
source serve para analisar e gerar gráficos e relatórios sobre o funcionamento dos Tomcat’s, o
jMeter, uma ferramenta, também opensource, utilizada para realização de testes de
perfomance, estress e carga

4.1 – RESULTADO DOS TESTES NO BALANCEADOR DE CARGA E NO
CLUSTER DE TOMCAT

Primeiramente foram realizados testes a fim de verificar se cada Tomcat está
trabalhando em cluster. Os testes no cluster foram executados de duas formas, a Figura 13
mostra através da ferramenta probe o resultado da primeira forma de teste no cluster:

Figura 13: Resultado do teste no cluster com o probe

A figura acima mostra, verdadeiramente, que a aplicação “orbis” esta
funcionando de acordo com o planejado. A mesma figura mostra o resultado do probe em um

41

Tomcat, que por sua vez possui o mesmo resultado no outro Tomcat. A segunda forma de
teste seria desativando um dos Tomcat’s e verificar a aplicação continua disponível. Foi
realizado esse teste e conforme o planejado, a aplicação continuou disponível e logo foi
reativado o Tomcat e o mesmo recebeu as sessões que estavam sendo replicada, garantindo o
principal objetivo deste projeto.
Com o balanceamento de carga do apache, através do segundo teste no cluster,
foi confirmado que a configuração realizada estava funcionando de acordo com o planejado,
pois as requisições destinadas para o servidor desativado foram redirecionadas para o outro
servidor que estava ativo. Mesmo com os dois servidores ativos, verificou-se também que,
cada requisição vinda de navegadores diferentes o apache redirecionava para cada Tomcat,
garantindo então que nenhum servidor ficasse sobrecarregado de requisições.

4.2 – RESULTADO DOS TESTES NA REPLICAÇÃO DE DADOS COM MYSQL

O primeiro teste realizado primeiramente foi execução do comando “SHOW
SLAVE STATUSG” que foi mencionado anteriormente. Esse comando mostra o estado atual
da replicação e o resultado foi mostrado na sessão 3.4.2.
Outro teste realizado foi atualização no banco master e conferindo no banco
slave se a alteração foi replicada. Realizado todos os testes verificou-se que a replicação está
funcionando de acordo com o que foi proposto.

4.3 – RESULTADOS DOS TESTES DE PERFOMANCE

Para realização tos testes de perfomance, foi utilizado a ferramenta jMeter que
foi mencionado anteriormente. Com esta ferramenta, foi possível realizar testes de
performance a fim de identificar se esta solução configurada também prover alta performance.
As etapas de teste se deram da seguinte forma:
• 1ª etapa: No jMeter foi criado um plano de teste e nesse plano foi configurado um
grupo de 100 usuários simulando um acesso ao sistema cadastrando um usuário, onde
este acesso era capturado através do servidor proxy do próprio jMeter;
• 2ª etapa: O jMeter capturou os acessos do usuário do sistema dentro de um cluster de
Tomcat;

42

• 3ª etapa: Também foi testado através do jMeter, onde o mesmo capturou os mesmos
acessos do teste anterior, porém em cada servidor.
• 4ª etapa: comparar os resultados obtidos em ambos os servidores.
Os testes do jMeter consistiam num cadastro realizado no sistema. Com a
simulação de 100 usuários realizando cadastro no sistema foi gerado mais de 34 mil sessões e
estas foram replicadas entre os Tomcat’s. A Figura 14 mostra o resultado do teste realizado
na segunda etapa:

Figura 14: Volume de tráfego (bytes) no cluster

Na Figura 14 podemos observar através do gráfico gerado pelo probe, que no intervalo
entre 22 horas e 22 horas e 20 minutos, a execução do teste com jMeter gerou um volume de trafego
15.000.000 Bytes.
Outro resultado desse teste é mostrado através da Figura 15:

43

Figura 15: Uso da CPU no cluster

De acordo com o que é mostrado na Figura 15, podemos perceber que no
mesmo intervalo mencionado anteriormente, os testes do jMeter consumiram 12,5 % do
processamento no servidor.
Os mesmos testes executados no cluster foram executados em cada Tomcat. A
Figura 16 mostra primeiro resultado do teste:

Figura 16: Volume de tráfego (bytes) no Tomcat A

44

Através da Figura 16, podemos perceber que no intervalo das 22:40 horas às
23:00 horas o volume de trafego aumentou consideravelmente atingindo um valor de
75.000.000 Bytes. A Figura 17 mostra outro resultado:

Figura 17: Uso de CPU no TomcatA

Com a Figura 17 podemos perceber que o percentual de processamento
aumentou bastante comparado ao teste da segunda etapa, atingindo a 55% do processador.
Através destas comparações de resultados podemos, concluir que esta solução também
garante a alta performance dos sistemas.

5 – CONCLUSÃO

O desenvolvimento desse projeto com os testes realizados pode-se perceber a
eficácia da utilização das ferramentas e técnicas apresentadas. Ocorreu realmente o que foi
previsto e o que foi desejado. O balanceador de carga utilizando o Servidor Web Apache
funcionou conforme o esperado. O Cluster de Tomcat, também funcionou de forma
satisfatória e com um bom desempenho. E por ultimo a replicação de banco de dados MySQL
que funcionou e cumpriu o seu dever como foi esperado.
Podemos concluir que tudo que foi proposto, foi alcançado desde a proposta de
alta disponibilidade até alta performance. Podemos concluir também que este ambiente não
gera um alto custo com software, pois se faz o uso de software livre, apenas investimento em
hardware quando necessário.

45

6 – REFERÊNCIAS BIBLIOGRÁFICAS

APACHE. The Apache Software Foundation – Foundation Project. Disponível em:
http://apache.org/foundation/ Acessado em: 15 de outubro de 2011.

COSTA, Davi Tavares. Uma solução com uso de ferramentas livres para sistemas web de
alta disponibilidade, 2008 45p. Monografia – Departamento de Informática e Estatística,
Bacharelado em Ciência da Computação, Universidade Federal do Piauí.

COULOURIS, George, DOLLIMORE, Jean, KINDBERG, Tim.; Sistemas Distribuidos, 4.ed
Bookman Companhia, 2007.

DEITEL, H. M.; DEITEL, P.J.; CHOFFNES, D.R.; Sistemas Operacionais, 3.ed. São Paulo:
Prentice-Hall, 2005. Cap. 18, p.527-556.

FRANIVAM, I. S. Costa. Uma política de Tolerância a Falhas para o Sistema Jazida,
2011 37 p. Monografia – Tecnologia em Análise e Desenvolvimento de Sistemas, Instituto
Federal do Piauí.

GONÇALVES, Edson.; Tomcat – Guia Rápido do Administrador, 2006 243p. Editora
Ciência Moderna.

GUERRAOUI, R,; SHIPER, A. Software-Based replication for fault tolerance. Citato por
PASIN, M. Replicas para Alta disponibilidade em Arquiteturas Orientadas a
Componentes com Suporte de Comunicação de Grupo, 2003. 127f. Tese de Doutorado
submetida à avaliação, como requisito parcial para obtenção do grau de Doutor em Ciência da
Computado, Universidade Federal do Rio Grande do Sul, Porto Alegre 2003.

MILANI, André. MySQL: Guia do Programador, 2007 400p. Editora NOVATEC. Cap 1, p
22-33

46

PASIN, M. Replicas para Alta disponibilidade em Arquiteturas Orientadas a
Componentes com Suporte de Comunicação de Grupo, 2003. 127f. Tese de Doutorado
submetida à avaliação, como requisito parcial para obtenção do grau de Doutor em Ciência da
Computado, Universidade Federal do Rio Grande do Sul, Porto Alegre 2003.

PEREIRA, N. A.; Serviços de Pertinência para Clusters de Alta Disponibilidade,
Dissertação de Mestrado em Ciência da Computação, USP. 2004

RIBEIRO, Leandro. Linux – Estudo geral sobre Apache – 21/11/2005. Disponível em:
http://imasters.com.br/artigo/3697/linux/estudo-geral-sobre-apache Acessado em: 15 de outubro de
2011.

SCHWARTZ, Baron.; ZAITSEV, Peter.; TKACHENKO, Vadim.; ZAWODNY, Jeremy D.;
LENTZ, Arjen; BALLING, Derek J. High Performance MySQL Optimization, Backups,
Replication and More. 2009 O’Reilly Media. 712p. Cap 8, p 285-336.

SILBERSCHATZ , A.; GALVIN, P.; GAGNE, G. Sistemas Operacionais: Conceitos e
Aplicações. Rio de Janeiro: Campus, 2001. Cap.14, p.382 -397.

SIMOMURA, Bruno Celio. Sistemas Distribuídos 24/06/2009. Disponível em:
http://www.artigonal.com/ti-artigos/sistemas-distribuidos-991878.html Acessado em: 07/01/2011.

TOMCAT. Apache Tomcat 6.0 – Documentation Index. Disponível em:
http://tomcat.apache.org/tomcat-6.0-doc/index.html Acessado em: 15/10/2011.

MONOGRAFIA - ESTUDO DE VIABILIDADE DE SERVIDORES EM CLUSTER PARA ALTA DISPONIBILIDADE DE SERVIDORES EM CLUSTER

Recommandé

Recommandé

Contenu connexe

Similaire à MONOGRAFIA - ESTUDO DE VIABILIDADE DE SERVIDORES EM CLUSTER PARA ALTA DISPONIBILIDADE DE SERVIDORES EM CLUSTER

Similaire à MONOGRAFIA - ESTUDO DE VIABILIDADE DE SERVIDORES EM CLUSTER PARA ALTA DISPONIBILIDADE DE SERVIDORES EM CLUSTER (20)

Plus de Adriel Viana

Plus de Adriel Viana (7)

MONOGRAFIA - ESTUDO DE VIABILIDADE DE SERVIDORES EM CLUSTER PARA ALTA DISPONIBILIDADE DE SERVIDORES EM CLUSTER