INSTITUTO FEDERAL DE EDUCAO, CIENCIA E TECNOLOGIA DO PIAU.

PR-REITORIA DE ENSINO CURSO DE TECNOLOGIA EM ANLISE 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

ADRIEL LUCAS DA SILVA VIANA

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

Monografia apresentada ao Instituto Federal de Educao, Cincia e

Tecnologia do Piau com requisito obteno do ttulo de Tecnlogo em Anlise e Desenvolvimento de Sistemas, sob a orientao do Prof. MSc. Adalton de Sena Almeida

TERESINA/PI OUTUBRO/2012

ADRIEL LUCAS DA SILVA VIANA

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

Monografia aprovada pelo Instituto Federal de Educao Cincia e Tecnologia do Piau como requisito obteno do ttulo Tecnlogo em Anlise e Desenvolvimento de Sistemas.

Teresina, 05 de Novembro de 2012

Msc. Adalton Sena de Almeida Orientador

Rogrio da Silva Batista 2 Membro

Rogrio da Silva 3 Membro

AGRADECIMENTOS

A Deus, por ter me dado foras para lutar, ter me proporcionado muitas vitrias e ter me guardado do mal e da aparncia do mesmo. minha famlia que sempre torceu por mim, acreditando sempre no meu potencial. Em especial meu pai Egilson Viana e minha me Shyrlei Viana que sempre tiveram a certeza da minha conquista. A minha noiva Sara Raquel, fonte de inspirao, que esteve sempre comigo com o seu amor, carinho, ateno e compreenso. Aos amigos de trabalho, da igreja e do IFPI, que me deram total apoio durante a minha caminhada rumo vitria. 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 disponibilizao de servios e informaes na Internet est cada vez mais ampla, como por exemplo, transaes bancrias, comercio eletrnico, redes sociais, jogos interativos, etc. Esse aumento se deu graas ao nmero crescente de usurios 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 soluo que prover uma alta disponibilidade de sistemas web java com a utilizao de cluster de servidores e balanceamento de carga. No decorrer deste trabalho ser mostrada toda a arquitetura do cluster e a sua configurao com a utilizao do servidor web Tomcat. No banco de dados ser mostrada replicao 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 realizao deste projeto. Palavras-Chaves Balanceamento de Carga, Cluster de Servidores, Replicao 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: Cenrio proposto neste projeto Figura 2: Replicao de sesses Figura 3: Funcionamento do Tomcat-Cluster Figura 4: Trecho de configurao 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 Replicao Figura 10: Saida do comando SHOW SLAVE STATUS\G; Figura 11: Threads de replicao Figura 12: Threads de E/S e Thread SQL Figura 13: Resultado do teste no cluster com o probe Figura 14: Volume de trfego (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: Configurao para identificar os ns no cluster

SUMRIO
1 INTRODUO .......................................................................................................................................10 1.1 MOTIVAO .......................................................................................................................................... 10 1.2 JUSTIFICATIVA ..................................................................................................................................... 11 1.3 OBJETIVOS ............................................................................................................................................. 11 1.3.1 OBJETIVO GERAL .......................................................................................................................... 11 1.3.2 OBJETIVOS ESPECFICOS............................................................................................................ 12 2 - REFERNCIAL TERICO ....................................................................................................................13 2.1 - TOMCAT .................................................................................................................................................. 13 2.2 -APACHE ................................................................................................................................................... 13 2.3 - MYSQL..................................................................................................................................................... 14 2.4 - TOLERNCIA A FALHAS ..................................................................................................................... 14 2.5 - ALTA DISPONIBILIDADE ..................................................................................................................... 15 2.6 - SISTEMAS DISTRIBUDOS ................................................................................................................... 16 2.7 - BALANCEAMENTO DE CARGA .......................................................................................................... 16 2.8 - REPLICAO .......................................................................................................................................... 17 2.9 - CLUSTER ................................................................................................................................................. 17 2.10 - TRABALHOS RELACIONADOS ......................................................................................................... 18 3 - PROPOSTA DE UM AMBIENTE DE ALTA-DISPONIBILIDADE .....................................................19 3.1 - CENRIO ................................................................................................................................................. 19 3.1.1 - Informaes 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 - Configurao ..................................................................................................................................... 25 3.3 CONFIGURAO DO BALANCEADOR DE CARGA ........................................................................ 27 3.3.1. O Mdulo mod_proxy ...................................................................................................................... 28 3.3.2. O Mdulo mod_proxy_balancer ...................................................................................................... 30 3.3.4 Configurao..................................................................................................................................... 31 3.4 - REPLICAO NO MYSQL .................................................................................................................... 34 3.4.1 Funcionamento ................................................................................................................................. 34 3.4.2 Configurao..................................................................................................................................... 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 REPLICAO DE DADOS COM MYSQL ..................................... 41 4.3 RESULTADOS DOS TESTES DE PERFOMANCE ............................................................................... 41 5 CONCLUSO .........................................................................................................................................44 6 REFERNCIAS BIBLIOGRFICAS ....................................................................................................45

10

1 INTRODUO

Este trabalho foi realizado na empresa Infoway Tecnologia e Gesto em Sade, situada na cidade de Teresina-PI, como um estudo e testes utilizando ferramentas livres para prover alta disponibilidade dos sistemas desenvolvidos pela prpria empresa, onde se pretende implantar esta soluo na reestruturao do data center a partir da aquisio de novos servidores. Uma das mudanas que ocorrer nesta reforma ser na hospedagem das aplicaes, onde sero configuradas e testadas solues em cluster, balanceamento de carga dos acessos e replicao de dados. Para configurar todo este ambiente de alta disponibilidade ser utilizada as seguintes tecnologias: duas instancias do servidor web Tomcat visto que as aplicaes desenvolvidas pela Infoway utilizam a linguagem de programao java, o apache um completo servidor web com vrias funcionalidades e duas instancias do SGBD (Sistema de Gerenciamento de Banco de Dados) MySQL. Os Tomcats iro trabalhar em cluster replicando suas sesses entre si de modo que se um Tomcat parar a aplicao continua disponvel, pois a sesso j est replicada. O apache atuar como um balanceador de carga dos acessos aplicao garantindo que um s servidor no fique sobrecarregado de acessos. No MySQL, existir uma poltica replicao de dados denominada master-slave, ou seja, ter um banco de dados denominado mster, onde todas os dados sero armazenados, este por sua vez replicar os dados para outro banco de dados denominado de slave, caso o mster falhe o slave assume a posio de master garantindo a alta disponibilidade dos dados. Mais adiante sero descritas sobre as tecnologias e conceitos, a utilizao e configurao de cada ferramenta na construo deste ambiente e ao final do mesmo ser feito a descrio dos testes realizados com este ambiente e as devidas consideraes finais sobre o trabalho realizado.

1.1 MOTIVAO 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 vrios problemas que vinham

11

acontecendo na infraestrutura da empresa tanto a nvel de hardware quanto a nvel de software, tais problemas so estes: indisponibilidade de aplicaes em alguns momentos devidos a pouco espao de memria fsica no servidor e consequentemente pouco espao na memria destinado para o Tomcat, falha no hardware, podendo causar perda de dados e atrasos nas atividades dos usurios que utilizam os sistemas ocasionando uma insatisfao por parte do usurio e clientes. Alm dos problemas informados, a principal motivao para este estudo gerar maior satisfao para usurio, pois se pretende deixar o sistema sempre disponvel, fazer atualizaes no sistema sem ter que parar o mesmo para realizar esta operao de modo que isto fique transparente para o usurio final.

1.2 JUSTIFICATIVA Devido deficincia quanto disponibilidade de algumas aplicaes web java, foi observado que em vrios momentos determinadas requisies carregavam uma grande massa de dados que ocasionava falta de espao na memria destinada ao Tomcat que por sua vez parava de funcionar fazendo com que a aplicao ficasse indisponvel. Outro problema observado foi que qualquer falha de hardware, como por exemplo, falha de um disco rgido, o sistema alm de indisponibilizar acesso aos dados armazenados, corria um risco de serem perdidos. Este trabalho prope a resolver todos estes problemas, que foram descritos acima, implementando uma soluo de cluster de servidores web com balanceamento de carga e replicao de banco de dados.

1.3 OBJETIVOS Os objetivos gerais e especficos sero 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 ESPECFICOS

Configurar dois servidores Tomcats 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 replicao master-slave. Testar a disponibilidade e a performance de uma aplicao web java no

ambiente configurado.

13

2 - REFERNCIAL TERICO

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 implementao de referencia para aplicaes Java Servlet e Java Server Pages. Atualmente o Tomcat tem seu prprio projeto de desenvolvimento independente dentro da Apache Software Fundation (APS) (TOMCAT, 2011). Tcnicamente 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 segurana, JNDI Resources e JDBC Data Sources (GONALVES, 2006).

2.2 -APACHE

O apache um servidor web HTTP com cdigo livre mundialmente utilizado. Foi inicialmente desenvolvido na NCSA (National Center of Supercomputing Applications), por Rob McCool. Aps a sada 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 configurvel, robusto e de alto desempenho. Abaixo est algumas caractersticas 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. Autenticao requerendo um nome de usurio e senha vlidos para acesso a alguma pgina/sub-diretrio/arquivo. Suporte autorizao de acesso, podendo ser especificadas restries de acesso separadamente para cada

endereo/arquivo/diretrio acessado no servidor;

14

Suporte a virtual hosting, por nome ou endereo ip: possvel servir dois ou mais pginas com endereos/portas diferentes atravs do mesmo processo, ou usar mais de um processo para controlar mais de um endereo.

Suporte a servidor proxy, FTP e http, com limite de acesso, caching (todas configurveis). Suporte a redirecionamentos baseados em URLs para endereos internos.

2.3 - MYSQL

Suporte a criptografia via SSL, certificados digitais; Negociao de contedo, permitindo a exibio da pgina web no idioma requisitado pelo cliente. Suporte a tipos mime. Personalizao de logs.

O SGBD Mysql um servidor e gerenciador de banco de dados relacional, projetado inicialmente para trabalhar com aplicaes de pequeno e mdio 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 dcada de 90, precisaram de uma interface SQL compatvel com as rotinas ISAM que utilizavam em suas aplicaes e tabelas. Em um primeiro momento, tentaram utilizar a API Mysql, contudo a API no era to rpida quanto eles precisavam, pois utilizavam rotinas de baixo nvel (MILANI, 2007). Este SGBD est sendo utilizado neste trabalho, pois ele possui vrias vantagens, dentre as quais so: um dos SGBDS mais utilizados no mundo; A replicao feita de forma simples e completa Interface grficas de fcil utilizao; Portabilidade; Facilidade de uso

2.4 - TOLERNCIA A FALHAS

15

Sistemas computacionais falham ocasionalmente. Quando uma falha ocorre, os servios podem produzir resultados incorretos, podem parar antes de completar o seu processamento ou at mesmo no responder as requisies 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 requisies dos clientes de forma transparente, sem que o cliente saiba que alguma falha tenha acontecido (COSTA, 2008). Dentre as tcnicas utilizadas para o tratamento de falhas podemos citar (CORREIA, 2005): Deteco de falhas: alguns tipos de falhas podem ser detectados. Outros, entretanto, so mais difceis de detectar como, por exemplo, um servidor na Internet que tenha quebrado. O desafio manter o sistema funcionando na presena de falhas que no possam ser detectadas, mas que podem ser suspeitas. Mascaramento de falhas: algumas falhas podem ser escondidas ou pode ser possvel diminuir os seus danos. Uma mensagem pode ser retransmitida em caso de perda, por exemplo. Recuperao de falhas: envolve o desenvolvimento de sistemas capazes de armazenas os estados de dados permanentes, possibilitando a recuperao dos mesmos aps uma falha ou ento retroceder o sistema a um estado consistente (rollback). Tolerncia a falhas e Redundncia: servios podem se tornar tolerantes a falhas utilizando componentes redundantes (replicas). O desenvolvimento de tcnicas para a manuteno 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 deteco, recuperao e mascaramento de falhas, visando manter o funcionamento dos servios durante o mximo de tempo possvel. Segundo Costa (2008), em sua monografia intitulada Uma soluo com uso de ferramentas livres para sistemas web de alta disponibilidade diz que um servio que est

16

sempre ativo, sempre disponvel, sempre atendendo s requisies e que pode servir a uma grande quantidade de carga concorrentemente chamado de altamente disponvel. Um sistema de alta disponibilidade deve ser tolerante a falhas caso contrrio o sistema ficar indisponvel. Como falhas so inevitveis em ambientes computacionais, so utilizadas tcnicas para garantir a disponibilidade dos recursos de sistemas crticos, mesmo na presena de falhas. Estas tcnicas podem ser tanto em nvel de hardware quanto de software. Em hardware, procura-se utilizar redundncia e equipamentos, para que um componente em falha seja compensado por outro. J em software, clusters so desenvolvidos com configuraes que permitem atingir comportamento similar em nvel de hardware: a falha de um servidor compensada pela migrao dos recursos comprometidos para o outro servidor operante (PEREIRA, 2004).

2.6 - SISTEMAS DISTRIBUDOS

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

2.7 - BALANCEAMENTO DE CARGA

Quando as requisies chegam a sistemas distribudos, elas necessitam de um mecanismo que possa distribuir as requisies de modo que um servidor no fique sobrecarregado ao receber mais requisies que outro. Um servio de balanceamento de carga capaz de encaminhar requisies dentro de um cluster, garantindo a utilizao 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 requisies provenientes dos clientes sejam distribudas de maneira equilibrada entre estes. Os sistemas no trabalham junto em um nico processo, mas redirecionando as requisies de forma independente, assim que chegam baseados em um escalonador e um algoritmo prprio.

2.8 - REPLICAO

Uma tcnica de tolerncia a falhas replicao, uma redundncia til utilizada para garantir a disponibilidade do sistema de forma que se uma das rplicas produzidas falharem, e remanescentes podero continuar a prover o servio. Essa tcnica utilizada para melhorar servios e as motivaes para seu uso so a melhoria do desempenho de um servio, aumento da sua disponibilidade e tornar um servio tolerante a falhas (SILBERSCHATZ, 2001). A replicao induz ao problema de consistncia de rplicas: quando um objeto alterado, suas rplicas tambm precisam ser atualizadas, para manter um estado distribudo consistente (PASIN, 2003, p.44). Para satisfazer essa consistncias, um protocolo de replicao precisa obedecer s seguintes propriedades (GUERRAOUI, 1997, p.69 citado por PAZIN, 2003, p.44): Ordem: operaes de atualizao concorrentes, enviadas por diferentes clientes, devem ser executadas na mesma ordem por rplicas distintas; Atomicidade: quando uma rplica realiza uma operao de atualizao, todas as demais rplicas tambm devem realizar esta operao. Quando se utiliza um servio que provm replicao alguns requisitos devem ser levados em considerao 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 mudana, mantendo-se a consistncia dos dados replicados garantindo que mesmo aps a ocorrncia de falhas as replicas possam prover o servio a partir do estado em que o componente primrio 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 requisies 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 trs tipos de clusters: Cluster de alto desempenho: todos os ns do cluster so usados para executar trabalho; Cluster de alta disponibilidade: alguns servidores realizao trabalho enquanto outros servem como reserva (backup). Se um dos servidores falhar, os ns de reservar comearo a executar e assumir imediatamente os trabalhos que estavam em execuo nos servidores que falharem sem interromper o servio 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 utilizao de clusters existe para facilitar o uso da alta disponibilidade e/ou tolerncia a falhas. Balanceamento de carga e replicao dos estados das sesses so dois elementos muito importantes do cluster neste projeto.

2.10 - TRABALHOS RELACIONADOS

Segundo Costa (Costa, 2008), este prope uma soluo de clusters de servidores web utilizando o apache como balanceador de carga e os Tomcats trabalhando em clusters, o mesmo aplicou esta soluo no site do Tribunal de Justia do Estado do Piau. Franivam (Franivam, 2011) prope uma tcnica de tolerncia a falhas para o sistema Jazida, um sistema de indexao e busca de documentos de texto e imagem. O sistema Jazida funciona baseado em cluster e neste sistem foi desenvolvida uma poltica de tolerncia a falhas onde existe um componente chamado Cluster Service que envia notificaes para cada data node verificando se algum node est inacessvel e o mesmo elege outro para assumir o node que est inacessvel.

19

3 - PROPOSTA DE UM AMBIENTE DE ALTA-DISPONIBILIDADE

3.1 - CENRIO

O cenrio utilizado para a criao do ambiente de alta disponibilidade utiliza a verso 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 aplicaes menores esto hospedados em outro servidor, caso ocorresse alguma falha de hardware ou software em algum desses servidores, o sistema ficaria indisponvel at que o problema seja resolvido, podendo acarretar tambm a perda de dados em caso de falha nos arquivos de banco de dados. Para construo deste cenrio ser feito uma duplicao da hospedagem da aplicao onde dois Tomcats ficam em servidores distintos que respondem ao mesmo tempo as requisies vinda dos usurios. O apache ficar responsvel por fazer o balanceamento de carga das requisies, realizando um controle sobre o acesso aos Tomcats, assim parte das requisies vai para um Tomcat e parte das requisies vai para outro, garantindo que nenhum Tomcat fique sobrecarregado quanto ao nmero de requisies. Caso um Tomcat pare de funcionar o apache encaminha os acessos para outro Tomcat que estiver ativo. Para garantir que os dados no sejam perdidos, se ocorrer alguma falha de hardware ou software, ser implementado uma poltica de replicao do banco de dados do sistema onde temos um banco principal, chamado de master, que replica os dados para o banco secundrio, chamado de slave. Se o master falhar, rapidamente o slave posto em produo passando a ser banco de dados master. Assim temos uma soluo que garante a disponibilidade do sistema e dos dados. A Figura 1 representa o cenrio proposto neste projeto.

20

Figura 1: Cenrio proposto neste projeto

Neste projeto as requisies vinda do usurio vo para o balanceador de carga com o endereo, http://192.168.56.102/orbis e o mesmo desviar as requisies para os dois servidores web http://192.168.56.102:8081/orbis e http://192.168.56.103:8082/orbis. Estes endereos
mencionados anteriormente respondem pela aplicao web chamada orbis, esta aplicao ser utilizada nos testes para a construo do ambiente que foi mencionado anteriormente.

Existe

tambm um servidor de banco de dados master e outro servidor de servidor de banco de dados slave onde este armazenar a rplica dos dados do master.

3.1.1 - Informaes sobre o ambiente utilizado O ambiente para implementao do projeto ser utilizado em duas mquinas virtuais onde as caractersticas esto descritas abaixo: Servidor 1:

21

o o o o o

Ip: 192.168.56.102; Sistema Operacional: CentOS 5.8 x86_64; Nome do Host: master; Memria RAM: 1 GB; Aplicativos: Balanceador de carga, com apache; TomcatA; Banco de dados Mysql denominado mster;

Servidor 2: o o o o o Ip: 192.168.56.103; Sistema Operacional: CentOS 5.8 x86_64; Nome do Host: slave; Memria RAM: 1GB; Aplicativos: TomcatB; Banco de dados Mysql denominado slave;

3.2 TOMCAT-CLUSTER

O cenrio deste projeto hospedar uma aplicao desenvolvida em Java. Neste ambiente dois Tomcats estaro replicando as suas sesses abertas em cada n do cluster, assim cada n ir conter suas prprias sesses e atributos e as sesses abertas dos demais ns do cluster, como mostra a Figura 2.

Figura 2: Replicao de sesses

22

O tomcat-cluster permite que se um n falhe, as requisies vinda dos clientes para este ns sejam desviadas para um n ativo sem que o usurio perceba, pois sua sesso continuar ativa nos demais ns do cluster.

3.2.1 - Requisitos

Para realizar a replicaes das sesses entre os ns do cluster alguns pontos devem ser verificados: Todos os atributos das sesses 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 configurao do contexto da aplicao 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 opo stcky session ativa, para manter as requisies vindas de um mesmo usurio do sistema indo para um mesmo n do cluster. (Tomcat) Na verso utilizada neste projeto, o Tomcat realiza uma replicao de sesso todos-para-todos. O algoritmo utilizado tem uma eficincia melhor em cluster de pequeno porte, pois em grandes cluster a quantidade de informaes trafegadas entre os ns seria enorme e isso afetaria o desempenho da aplicao. A soluo para este problema fazer a diviso de um cluster de grande em vrios grupos de cluster menores utilizando endereos de multicast diferentes para cada cluster menor. Vale lembrar que a replicao de sesso apenas uma caracterstica entre vrias caractersticas do cluster de Tomcat. Outra caracterstica importante que no necessrio realizar uma instalao ou atualizao de uma aplicao em todos os ns do cluster, isto feito em apenas um dos ns, 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 responsvel por receber conexes vindas de outros ns do cluster, para que com isso, seja feita as trocas de sesses entre eles utilizando-se de uma porta TCP definida durante a configurao do cluster. O Tomcat fica escutando nesta porta aguardando o envio de sesses vindo de outros ns (APACHE, 2011). O Sender o componente responsvel pelo envio das sesses para outro Tomcat. Ele se conecta ao Receiver de outro Tomcat e envia suas sesses. O Membership o responsvel por, atravs de pacotes de multicast, realizar a parceria entre os ns. Com esse componente, os ns so inseridos e removidos do cluster. O Valve o componente responsvel por detectar quando uma requisio foi completada e a partir disto a replicao desta sesso ocorra e a resposta enviada ao usurio. O Deployer responsvel por deixar automtica a gerencia das aplicaes no cluster. Se o administrador do servidor desejar hospedar uma nova aplicao no cluster, no necessrio que seja feita a instalao da aplicao em todos os ns, pois ao se inserir a nova aplicao, o Deployer far a cpia desta aplicao para todos os outros ns do cluster. Isso tambm vale para as atualizaes e remoes de aplicaes.

3.2.3 Funcionamento

Para entender como um cluster funciona a Figura 3 mostra todo o processo de replicao de sesso de um cluster composto por um Tomcat A e um Tomcat B que recebe requisies no decorrer do tempo.

24

Figura 3: Funcionamento do Tomcat-Cluster

Na imagem acima o Tomcat A inicializa utilizando uma sequencia padro de inicializao. Se o web.xml da aplicao conter o elemento distributable, o Tomcat requisita classe Cluster (no caso atual a classe SimpleTcpCluster) a criao 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 invs de um StandardManager. A classe cluster, atravs de uma comunicao 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 diferena: o cluster inicializado e ento 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 replicao, se no foi recebido nenhum ping vindo de um determinado n durante um tempo limite, este n considerado morto. O Tomcat B requisita os estados de sesso do Tomcat A e este s responder ao pedido assim que o Tomcat B finalizar sua inicializao ficando pronto para receber as conexes vinda dos usurios.

25

O Tomcat A recebe a primeira requisio, uma sesso S1 ser criada e esta tratada da mesma forma que uma requisio sem replicao de sesso. A replicao acontece depois que a resposta est pronta e a partir dai o ReplicationValve ir interceptar a resposta antes de ser enviada para o usurio. Uma vez que feita a replicao de sesso, a resposta enviada ao usurio. Quando o Tomcat A falhar o B recebe uma notificao de que o mesmo foi excludo do cluster, fazendo com que o Tomcat B remova o A da lista de participantes do cluster, as sesses no sero replicadas e o balanceador ir desviar as requisies destinadas para o Tomcat A. Quando o Tomcat A reinicializa, este recebe uma requisio e uma instruo de finalizao da sesso S1. Quando o pedido de fim de sesso recebido, o Tomcat A invalida aquela sesso e o mesmo enviar uma mensagem de sesso S1 expirou para o Tomcat B e o mesmo invalidar a sesso S1. Neste caso, somente o status de sesso S1 que replicado. O Tomcat B recebe uma nova requisio e uma nova sesso S2 criada seguindo o mesmo processo de replicao de sesso descrito acima. Todo o processo de replicao ocorre utilizando conexes TCP. Uma vez que um ping multicast recebido, o n de origem do ping adicionado ao cluster. Utilizando as informaes vinda da comunicao multicast, os ns estabelecem conexes TCP para, atravs destas, realizar a replicao das sesses. O propsito da utilizao do protocolo TCP, que ele garante a entrega dos pacotes e realiza controle de fluxo. Assim fica garantida a entrega das mensagens de replicao.

3.2.4 - Configurao

Para preparar os Tomcats para o cluster, realizada a edio do arquivo de configurao server.xml, localizado no diretrio conf do Tomcat, A Figura 4 mostra o trecho de configurao do cluster.

26

Figura 4: Trecho de configurao do cluster no arquivo server.xml

Este trecho j vem padro da verso do Tomcat, segue abaixo a Tabela 1 onde foi realizada a configurao nos referidos servidores para identificar os ns do cluster.

Tomcat A <Membership...> address=228.0.0.4 port=45564 <Receiver...> address=192.168.56.102 port=4000 <Receiver...> <Membership...>

Tomcat B

address=228.0.0.4 port=45564

address=192.168.56.103 port=4001

Tabela 1: Configurao para identificar os ns no cluster

27

Em ambos os Tomcats temos as tags Membership e Receiver com os seus respectivos endereos e portas. No Membership o endereo de multcast o 228.0.0.4 e a porta utilizada para envios dos pings de multicast a 4556. No Receiver temos o endereo que indica o ip de cada servidor. No Tomcat A o ip 192.168.56.102 e a porta 4000 utilizados para receber conexes 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 conexes vinda do servidor http://192.168.56.102:8081/orbis. Aps estas configuraes tm-se dois servidores Tomcat configurados para trabalhar em cluster e realizar a replicao das sesses.

3.3 CONFIGURAO DO BALANCEADOR DE CARGA

Como j foi dito anteriormente o apache ficar responsvel em realizar o balanceamento de carga entre os dois Tomcats. Este receber as requisies vinda dos usurios e o mesmo enviar as requisies para cada Tomcat de acordo com o nmero de requisies. Neste projeto foram desenvolvidas vrias funcionalidades para o servidor apache, uma delas a de se trabalhar como um servidor Proxy recebendo as requisies dos usuarios, fazendo a comunicao com o servidor de destino e passando a resposta de volta para os usuarios. Esta funcionalidade s possvel atravs do mdulo mod_proxy do apache. Junto ao mod_proxy, tem-se outro mdulo chamado de mod_proxy_balancer, este permite que seja feito um balanceamento de carga entre vrios 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 requisies e repassar essas requisies para os servidores web onde realmente est hospedada a aplicao. Com o mod_proxy_balancer possvel definir qual servidor ir receber a maior quantidade de conexes, garantindo que um servidor com um desempenho maior receba mais requisies que um servidor com um desempenho menor.

3.3.1. O Mdulo mod_proxy

Este mdulo 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 intermedirio que fica entre o cliente e o servidor de origem. Para que um cliente requisite uma pgina web, ele envia uma requisio para o servidor Proxy que requisita o contedo 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 atravs de um servidor e de esconder a verdadeira origem do acesso, importante que seu administrador limite o acesso a somente aqueles usurios que forem autorizados. Um Reverse Proxy, ao contrrio do Forward Proxy, aparece ao usurio como um servidor web comum. No necessria nenhuma configurao no cliente, o usurio faz requisies normais ao Reverse Proxy. O Reverse Proxy ento decide para onde enviar estas requisies e retorna o contedo 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 usurios acessem servidores que se encontram atrs de firewalls. O Reverse Proxy pode tambm ser utilizado como balanceador de carga entre vrios servidores finais ou para prover um cache para servidores finais mais lentos. Um Reverse Proxy ativado utilizando a diretiva ProxyPass.

3.3.2. O Mdulo mod_proxy_balancer

Este mdulo simplesmente prov um servio de balanceamento de carga para protocolos HTTP, FTP e AJP13. Sua utilizao depende do uso do mod_proxy (APACHE, 2011). Atualmente existem dois mtodos de balanceamento de carga, por quantidade de requisies e outro que leva em conta a quantidade de informaes 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 configurao do mod_proxy para que todo acesso ao contexto /test seja feito atravs do balanceador de carga balancer.

3.3.4 Configurao

A instalao do apache feita durante a instalao do CentOS do servidor, no momento da instalao, foi marcada a opo de instalar os pacotes para servidores web, contendo o apache e vrios outros recursos, como suporte a php e vrios mdulos incluindo o mod_proxy e o mod_proxy_balancer. A partir do cenrio descrito no inicio deste projeto, temos a Figura 8 que mostra o trecho do arquivo de configurao do apache, httpd.conf:

32

Figura 8: Virtual Host

A figura acima mostra a configurao de um virtual host que ser responsvel pelo recebimento das requisies destinadas ao endereo http://192.168.56.102/orbis A opo ServerName determina o nome do virtual host, neste caso 192.168.56.102. Em ProxyRequest off, dizemos ao apache que no ser utilizado como um servidor proxy ou um Reverse Proxy, no atendendo a requisies de sites diferentes do sistema. Na linha abaixo:

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

dito ao apache que qualquer requisio destinada ao contexto /orbis dentro do sistema, ser utilizado o balanceador de carga para atender as demandas. Com a opo stickysession=JSESSIONID, o apache ir direcionar os pedidos de uma mesma sesso para o servidor. A opo nofailover=Off, determina que os membros pertencentes ao balanceador de carga tm a capacidade de superar uma falha de um dos membros, com isso, se for detectado um membro inativo, o apache ir desviar todas as requisies antes enviadas a este membro, para um outro membro. As opes abaixo so diretrizes para corrigir as respostas vinda dos servidores balanceados, baseando-se na requisio 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 so descritas a configurao onde declarado o balanceador de carga e os seus membros com suas devidas caractersticas 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 configurao 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 opo loadfactor determina qual carga cada membro receber em relao 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 opo ProxySet lbmethod determinar para o balanceador o tipo de balanceamento de carga ser utilizado. Pode ser utilizado o mtodo de balanceamento por quantidade de requisies com lbmethod=byrequests onde tem-se que cada requisio ir para servidores diferentes, ou pode utilizar pela quantidade de trfego 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 requisio que carregar uma grande quantidade de bytes para um servidor as prximas requisies de sesses diferentes sero destinadas para os demais membros do balanceamento at que este fique liberado para receber as prximas requisies. O mtodo mais recomendado o bytraffic, porm no se aplica neste projeto, pois alm de ser uma aplicao de teste, esta no ainda uma aplicao de pequeno porte e por este motivo utilizado o mtodo byrequests. Com esta configurao, temos um servidor Apache realizando o balanceamento de carga em dois Tomcats no sistema orbis.

34

3.4 - REPLICAO NO MYSQL

A replicao de dados permitir que, no caso de um servidor X falhar, com uma pequena mudana de no endereamento dos ips dos servidores Mysql o sistema possa voltar a funcionar em tempo hbil, e o mais importante sem perda de dados. Assim, os principais objetivos de se utilizar a replicao de dados neste projeto so: 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

recuperao dos dados perdidos atravs de backups Um bom sistema de replicao de dados uma tcnica valiosa para ajudar com os backups, porm no 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 replicao de dados feita de forma assncrona, no necessrio que um servidor slave fique continuamente conectado ao master. Ela funciona atravs do uso de um mecanismo de log binrio. Em resumo, a replicao e um simples processo de trs partes (SCHWARTZ et al 2009): 1. 2. 3. O master registra alterao aos seus dados no seu log binrio. O slave copia os eventos de log binrio do master para o seu relay log. O slave repete os eventos no seu relay log, aplicando as alteraes nos seus

prprios dados. A Figura 9 mostra todo esse processo de replicao.

35

Figura 9: Funcionamento da Replicao

A primeira parte do processo log binrio no master. Antes de cada transao que atualiza dados no master, este registra as alteraes no seu log binrio. No prximo passo, o slave copia o log binrio do master para o seu prprio disco rgido, chamado de relay log. Para copiar o log binrio, o slave inicia uma worker thread (tarefa), chamada de thread I/O. A thread de I/O abre uma conexo 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 binrio. 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 so repetidos atualizando os dados no servidor slave, atravs da thread SQL, para combinarem com os do master. E assim todos os eventos ocorridos das bases de dados do master sero executados nas bases de dados do slave. Inicialmente, para a criao da replicao, deve ser feito um backup das bases que sero replicadas no master. Aps ter sido gerado o backup, a criao do log binrio deve ser habilitada e assim todos os comandos executados no master ficaro gravados neste log. O backup ser restaurado em cada servidor slave. No possvel configurar o master para que ele grave somente certos comandos. Fica a cargo do slave decidir quais comandos ele dever executar localmente. No slave so configuradas quais bases de dados ou tabelas sero replicadas. Durante a leitura e

36

execuo do log, o slave guarda o log lido e a posio do ultimo comando executado. Com isso, possvel que diferentes slaves executem diferentes partes do mesmo log. Cada servidor que participa da replicao, master e slaves, devem ter uma identificao nica atravs da opo server-id. Os slaves devem ser informados do nome do host ou ip do servidor master, nome do log e quais bases de dados sero replicadas.

3.4.2 Configurao

A configurao do servidor master e do servidor slave foi feita atravs da edio do arquivo my.cnf que fica dentro do diretrio /etc/ no servidor. A seguir so mostrados todos os passos para a configurao do servidor para realizar replicao. Como falado anteriormente, deve ser feita um backup da base de dados do servidor master. Em seguida necessrio ativar a gerao do log binrio no servidor master, lembrando que a aplicao deve est parada pois uma atualizao na base sem a gerao do log haver falta de sincronismo do contedo das bases de dados nos servidores em questo. A opo no arquivo my.cnf que habilita a gerao do log binrio :

log-bin = mysql-bin

Para identificar o servidor master utiliza-se a opo descrita abaixo:

server-id = 1

Depois de realizado a insero destas opes no arquivo de configurao do mysql, este deve ser reiniciado para aplicar as alteraes. Para acontecer replicao, o servidor slave far uma conexo com o servidor master, para que isso seja possvel, deve-se criar um usrio com permisses de replicao na base de dados que ser replicada. Segue abaixo as informaes dos servidores: Base de dados replicada: orbis Ip do servidor slave: 192.168.56.102 Nome do usurio: replica Senha: replica

37

Com base nessas informaes, 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 permisso de replicao para o usurio replica em todas as tabelas do banco orbis com o ip do servidor slave 192.168.56.103. O prximo passo restaurar a base de dados que vai ser replicada, que anteriormente foi realiado o backup no servidor slave. Em seguida necessrio editar o arquivo my.cnf e adcionar as seguintes opes:

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

As duas opes, log-bin e server-id segue a mesma definio das opes configurada servidor master. Foi adicionado duas opes de configurao adicionais:

relay_log que serve para especificar a localizao e o nome do relay-log, e log_slave_updates, que diz para o slave logar os eventos replicados para o seu prprio log binrio. Depois de editado o arquivo de configurao do Mysql, necessrio informar ao servidor slave como conecta-se ao servidor master e comear a repetir seus logs binrios. Para isso utilizado a expresso CHANGE MASTER TO. Esta expresso permite que se aponte o slave a um master diferente sem parar o servidor. Neste projeto foi utilizado a seguinte expresso bsica, 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 opo MASTER_HOST, define o endereo do servidor master, as opes MASTER_USER e MASTER_PASSWORD definem o usurio e senha que possui a permisso de replicao. MASTER_LOG_FILE o nome do primeiro log binrio que foi gerado e por fim a opo MASTER_LOG_POS configurado em 0 pois este o inicio do log. Os servidores de banco de dados esto configurados para realizarem replicao porm ainda no possvel que o servidor slave realize replicao, pois os processos do slave no esto rodando. Para iniciar a replicao, preciso executar o comando abaixo: mysql> START SLAVE; Para ter a confirmao de que a replicao esta realmente funcionando, o comando SHOW SLAVE STATUS mostra toda a configurao do servidor slave, a Figura 10 mostra o resultado desse comando:

Figura 10: Saida do comando SHOW SLAVE STATUS\G;

O parmetro Slave_IO_State mostra o estado da replicao, que est funcionando perfeitamente, outros dois parmetros importantes so Slave_IO_State e Slave_IO_Running que mostram que os processos de replicao esto rodando. possvel verificar as threads de replicao na lista de processos no master e no slave. A Figura 11 mostra no master uma conexo criada pela thread de E/S do slave:

39

Figura 11: Threads de replicao

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 replicao entre dois servidores de banco de dados esto funcionando perfeitamente de acordo com o que foi proposto.

4. TESTES E RESULTADOS

Aps, realizado toda a configurao dos servidores, foram executados vrios testes com o objetivo de verificar se todos os elementos do projeto esto funcionando corretamente. Foram executado tambm, testes de performance, afim de identificar se a soluo de cluster de servidores alm de proporcionar alta disponibilidade, ela tambm aumenta a performance do sistema. Para realizao dos testes, foi utilizado o Psi Probe, uma ferramenta open source serve para analisar e gerar grficos e relatrios sobre o funcionamento dos Tomcats, o jMeter, uma ferramenta, tambm opensource, utilizada para realizao 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 atravs 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 aplicao 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 Tomcats e verificar a aplicao continua disponvel. Foi realizado esse teste e conforme o planejado, a aplicao continuou disponvel e logo foi reativado o Tomcat e o mesmo recebeu as sesses que estavam sendo replicada, garantindo o principal objetivo deste projeto. Com o balanceamento de carga do apache, atravs do segundo teste no cluster, foi confirmado que a configurao realizada estava funcionando de acordo com o planejado, pois as requisies destinadas para o servidor desativado foram redirecionadas para o outro servidor que estava ativo. Mesmo com os dois servidores ativos, verificou-se tambm que, cada requisio vinda de navegadores diferentes o apache redirecionava para cada Tomcat, garantindo ento que nenhum servidor ficasse sobrecarregado de requisies.

4.2 RESULTADO DOS TESTES NA REPLICAO DE DADOS COM MYSQL

O primeiro teste realizado primeiramente foi execuo do comando SHOW SLAVE STATUS\G que foi mencionado anteriormente. Esse comando mostra o estado atual da replicao e o resultado foi mostrado na sesso 3.4.2. Outro teste realizado foi atualizao no banco master e conferindo no banco slave se a alterao foi replicada. Realizado todos os testes verificou-se que a replicao est funcionando de acordo com o que foi proposto.

4.3 RESULTADOS DOS TESTES DE PERFOMANCE Para realizao tos testes de perfomance, foi utilizado a ferramenta jMeter que foi mencionado anteriormente. Com esta ferramenta, foi possvel realizar testes de performance a fim de identificar se esta soluo configurada tambm 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 usurios simulando um acesso ao sistema cadastrando um usurio, onde este acesso era capturado atravs do servidor proxy do prprio jMeter; 2 etapa: O jMeter capturou os acessos do usurio do sistema dentro de um cluster de Tomcat;

42

3 etapa: Tambm foi testado atravs do jMeter, onde o mesmo capturou os mesmos acessos do teste anterior, porm 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 simulao de 100 usurios realizando cadastro no sistema foi gerado mais de 34 mil sesses e estas foram replicadas entre os Tomcats. A Figura 14 mostra o resultado do teste realizado na segunda etapa:

Figura 14: Volume de trfego (bytes) no cluster

Na Figura 14 podemos observar atravs do grfico gerado pelo probe, que no intervalo entre 22 horas e 22 horas e 20 minutos, a execuo do teste com jMeter gerou um volume de trafego 15.000.000 Bytes. Outro resultado desse teste mostrado atravs 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 trfego (bytes) no Tomcat A

44

Atravs 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. Atravs destas comparaes de resultados podemos, concluir que esta soluo tambm garante a alta performance dos sistemas.

5 CONCLUSO

O desenvolvimento desse projeto com os testes realizados pode-se perceber a eficcia da utilizao das ferramentas e tcnicas 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, tambm funcionou de forma satisfatria e com um bom desempenho. E por ultimo a replicao de banco de dados MySQL que funcionou e cumpriu o seu dever como foi esperado. Podemos concluir que tudo que foi proposto, foi alcanado desde a proposta de alta disponibilidade at alta performance. Podemos concluir tambm que este ambiente no gera um alto custo com software, pois se faz o uso de software livre, apenas investimento em hardware quando necessrio.

45

6 REFERNCIAS BIBLIOGRFICAS

APACHE. The Apache Software Foundation Foundation Project. Disponvel em:

http://apache.org/foundation/ Acessado em: 15 de outubro de 2011.

COSTA, Davi Tavares. Uma soluo com uso de ferramentas livres para sistemas web de alta disponibilidade, 2008 45p. Monografia Departamento de Informtica e Estatstica, Bacharelado em Cincia da Computao, 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. So Paulo: Prentice-Hall, 2005. Cap. 18, p.527-556.

FRANIVAM, I. S. Costa. Uma poltica de Tolerncia a Falhas para o Sistema Jazida, 2011 37 p. Monografia Tecnologia em Anlise e Desenvolvimento de Sistemas, Instituto Federal do Piau.

GONALVES, Edson.; Tomcat Guia Rpido do Administrador, 2006 243p. Editora Cincia 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 Comunicao de Grupo, 2003. 127f. Tese de Doutorado submetida avaliao, como requisito parcial para obteno do grau de Doutor em Cincia 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 Comunicao de Grupo, 2003. 127f. Tese de Doutorado submetida avaliao, como requisito parcial para obteno do grau de Doutor em Cincia da Computado, Universidade Federal do Rio Grande do Sul, Porto Alegre 2003.

PEREIRA, N. A.; Servios de Pertinncia para Clusters de Alta Disponibilidade, Dissertao de Mestrado em Cincia da Computao, USP. 2004

RIBEIRO, Leandro. Linux Estudo geral sobre Apache 21/11/2005. Disponvel 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 OReilly Media. 712p. Cap 8, p 285-336.

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

SIMOMURA,

Bruno

Celio.

Sistemas

Distribudos

24/06/2009.

Disponvel

em:

http://www.artigonal.com/ti-artigos/sistemas-distribuidos-991878.html Acessado em: 07/01/2011.

TOMCAT.

Apache

Tomcat

6.0

Documentation

Index.

Disponvel

em:

http://tomcat.apache.org/tomcat-6.0-doc/index.html Acessado em: 15/10/2011.