Your SlideShare is downloading. ×
MONOGRAFIA - ESTUDO DE VIABILIDADE DE SERVIDORES EM CLUSTER PARA ALTA DISPONIBILIDADE DE SERVIDORES EM CLUSTER
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

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

1,876
views

Published on

Monografia apresentada ao Instituto …

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


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,876
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
77
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. INSTITUTO FEDERAL DE EDUCAÇÃO, CIENCIA E TECNOLOGIA DO PIAUÍ. PRÓ-REITORIA DE ENSINOCURSO 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
  • 2. ADRIEL LUCAS DA SILVA VIANAESTUDO DE VIABILIDADE DE SERVIDORES EM CLUSTER PARA ALTA 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
  • 3. 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 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
  • 4. AGRADECIMENTOSA Deus, por ter me dado forças para lutar, ter me proporcionado muitas vitórias e ter meguardado do mal e da aparência do mesmo.À minha família que sempre torceu por mim, acreditando sempre no meu potencial. Emespecial meu pai Egilson Viana e minha mãe Shyrlei Viana que sempre tiveram a certeza daminha 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 minhacaminhada rumo à vitória.Aos meus professores que mostraram o caminho que eu deveria seguir e me incentivaram anunca desistir e sempre lutar.A todos, muito obrigado.
  • 5. ResumoA disponibilização de serviços e informações na Internet está cada vez mais ampla, como porexemplo, transações bancárias, comercio eletrônico, redes sociais, jogos interativos, etc. Esseaumento se deu graças ao número crescente de usuários na Internet que por sua vez gerava umaumento do trafego de dados na web. Os servidores web precisam está preparados paraatender a esta demanda que está cada vez mais crescente. Este trabalho apresenta uma soluçãoque prover uma alta disponibilidade de sistemas web java com a utilização de cluster deservidores e balanceamento de carga. No decorrer deste trabalho será mostrada toda aarquitetura do cluster e a sua configuração com a utilização do servidor web Tomcat. Nobanco de dados será mostrada replicação master-slave utilizando o Mysql como SGBD, poispretende-se garantir a alta disponibilidade dos dados. O objetivo deste estudo é explicar comoprover 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-ChavesBalanceamento de Carga, Cluster de Servidores, Replicação de dados, Mysql, Tomcat.
  • 6. AbstractThe availability of services and information on the Internet is increasingly broad, as forexample banking transactions, e-commerce, social networking, interactive games, etc. Thisincrease was through the increasing number of users on the Internet which in turn generatedan 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 javausing server cluster and load balancing. In this work will be displayed throughout thearchitecture and configuration of the cluster using the Tomcat server. In the database willshow master-slave replication using MySQL as DBMS, because it is intended ensure the highdata availability. The objective of this study is to explain how to provide high availability websystems at a low cost of hardware and software, since free software is used to carry out thisproject.KeywordsLoad Balancing, Cluster of Servers, Data Replication, MySQL, Tomcat.
  • 7. LISTA DE FIGURASFigura 1: Cenário proposto neste projetoFigura 2: Replicação de sessõesFigura 3: Funcionamento do Tomcat-ClusterFigura 4: Trecho de configuração do cluster no arquivo server.xmlFigura 5: Balanceamento de CargaFigura 6: Funcionamento do Forwad ProxyFigura 7: Funcionamento do Reverse ProxyFigura 8: Virtual HostFigura 9: Funcionamento da ReplicaçãoFigura 10: Saida do comando SHOW SLAVE STATUSG;Figura 11: Threads de replicaçãoFigura 12: Threads de E/S e Thread SQLFigura 13: Resultado do teste no cluster com o probeFigura 14: Volume de tráfego (bytes) no clusterFigura 15: Uso da CPU no clusterFigura 16: Volume de dados (bytes) no TomcatAFigura 17: Uso de CPU TomcatA
  • 8. LISTA DE TABELASTabela 1: Configuração para identificar os nós no cluster
  • 9. SUMÁRIO1 – 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............................................................................................................ 122 - 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 ......................................................................................................... 183 - 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..................................................................................................................................... 364. – 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 ............................................................................... 415 – CONCLUSÃO .........................................................................................................................................446 – REFERÊNCIAS BIBLIOGRÁFICAS ....................................................................................................45
  • 10. 101 – 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 paraprover alta disponibilidade dos sistemas desenvolvidos pela própria empresa, onde sepretende implantar esta solução na reestruturação do data center a partir da aquisição de novosservidores. Uma das mudanças que ocorrerá nesta reforma será na hospedagem dasaplicações, onde serão configuradas e testadas soluções em cluster, balanceamento de cargados acessos e replicação de dados. Para configurar todo este ambiente de alta disponibilidade será utilizada asseguintes tecnologias: duas instancias do servidor web Tomcat visto que as aplicaçõesdesenvolvidas pela Infoway utilizam a linguagem de programação java, o apache umcompleto servidor web com várias funcionalidades e duas instancias do SGBD (Sistema deGerenciamento de Banco de Dados) MySQL. Os Tomcat’s irão trabalhar em cluster replicando suas sessões entre si de modoque se um Tomcat parar a aplicação continua disponível, pois a sessão já está replicada. Oapache 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 dedados denominada master-slave, ou seja, terá um banco de dados denominado máster, ondetodas os dados serão armazenados, este por sua vez replicará os dados para outro banco dedados denominado de slave, caso o máster falhe o slave assume a posição de mastergarantindo a alta disponibilidade dos dados. Mais adiante serão descritas sobre as tecnologias e conceitos, a utilização econfiguração de cada ferramenta na construção deste ambiente e ao final do mesmo será feitoa descrição dos testes realizados com este ambiente e as devidas considerações finais sobre otrabalho realizado.1.1– MOTIVAÇÃO Como foi dito anteriormente este trabalho foi realizado como um estudo etestes utilizando ferramentas livres para prover alta disponibilidade dos sistemas webdesenvolvidos na Infoway. Este estudo se deu devido a vários problemas que vinham
  • 11. 11acontecendo na infraestrutura da empresa tanto a nível de hardware quanto a nível desoftware, tais problemas são estes: indisponibilidade de aplicações em alguns momentosdevidos a pouco espaço de memória física no servidor e consequentemente pouco espaço namemória destinado para o Tomcat, falha no hardware, podendo causar perda de dados eatrasos nas atividades dos usuários que utilizam os sistemas ocasionando uma insatisfação porparte do usuário e clientes. Além dos problemas informados, a principal motivação para este estudo é gerarmaior satisfação para usuário, pois se pretende deixar o sistema sempre disponível, fazeratualizações no sistema sem ter que parar o mesmo para realizar esta operação de modo queisto 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 grandemassa de dados que ocasionava falta de espaço na memória destinada ao Tomcat que por suavez parava de funcionar fazendo com que a aplicação ficasse indisponível. Outro problemaobservado foi que qualquer falha de hardware, como por exemplo, falha de um disco rígido, osistema além de indisponibilizar acesso aos dados armazenados, corria um risco de seremperdidos. Este trabalho propõe a resolver todos estes problemas, que foram descritosacima, implementando uma solução de cluster de servidores web com balanceamento de cargae 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. 12 O presente trabalho pretende construir um ambiente de servidores em clustercom o uso de ferramentas livres de modo que tenha sistemas web com alta disponibilidade emum 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. 132 - REFERÊNCIAL TEÓRICO2.1 - TOMCAT O Tomcat é um software livre e open source que atua como um servidor webou pode funcionar junto a um servidor web como Apache ou ISS. O Tomcat surgiu dentro doconceituado projeto Apache Jakarta e que teve apoio oficial da Sun Microsystem comoimplementação de referencia para aplicações Java Servlet e Java Server Pages. Atualmente oTomcat tem seu próprio projeto de desenvolvimento independente dentro da Apache SoftwareFundation (APS) (TOMCAT, 2011). Técnicamente o Tomcat é um container web da plataforma Java EntrepriseEdition (JEE) e que abrange as tecnologias servlet e jsp, incluindo as tecnologias de apoiorelacionadas 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 serdesenvolvido por um grupo de pessoas espalhadas no mundo todo (APACHE, 2011). Oapache é extremamente configurável, robusto e de alto desempenho. Abaixo está algumas características que fazem desse servidor web o preferidoentre 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. 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 alinguagem SQL como interface. O Mysql teve origem quando os desenvolvedores DavidAxmark, Allan Larsson e Michael “Monty” Widenius, na década de 90, precisaram de umainterface 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ápidaquanto eles precisavam, pois utilizavam rotinas de baixo nível (MILANI, 2007). Este SGBD está sendo utilizado neste trabalho, pois ele possui váriasvantagens, 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 uso2.4 - TOLERÂNCIA A FALHAS
  • 15. 15 Sistemas computacionais falham ocasionalmente. Quando uma falha ocorre, osserviços podem produzir resultados incorretos, podem parar antes de completar o seuprocessamento ou até mesmo não responder as requisições vinda dos clientes. Um sistema computacional tolerante a falhas permite que um servidor contornefalhas de todos os tipos (incluindo falhas de hardware e de software) mantendo assim otrabalho de responder as requisições dos clientes de forma transparente, sem que o clientesaiba 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 dedetecção, recuperação e mascaramento de falhas, visando manter o funcionamento dosserviços durante o máximo de tempo possível. Segundo Costa (2008), em sua monografia intitulada “Uma solução com uso deferramentas livres para sistemas web de alta disponibilidade” diz que um serviço que está
  • 16. 16sempre ativo, sempre disponível, sempre atendendo às requisições e que pode servir a umagrande quantidade de carga concorrentemente é chamado de altamente disponível. Umsistema 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 utilizadastécnicas para garantir a disponibilidade dos recursos de sistemas críticos, mesmo na presençade falhas. Estas técnicas podem ser tanto em nível de hardware quanto de software. Emhardware, procura-se utilizar redundância e equipamentos, para que um componente em falhaseja compensado por outro. Já em software, clusters são desenvolvidos com configuraçõesque 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 hardwareou software, que localizados em computadores interligados em rede, se comunicam ecoordenam suas ações apenas enviando mensagens entre si. Esta definição é bastante simplese abrange toda a gama de sistemas nos quais computadores interligados em rede podem serdistribuídos de maneira útil. (SIMOMURA, 2009). Um aspecto importante dos sistemas distribuídos é o compartilhamento derecursos, os aplicativos clientes invocam operações em recursos que frequentemente estão emoutro servidor (COLOURIS et AL, 2007).2.7 - BALANCEAMENTO DE CARGA Quando as requisições chegam a sistemas distribuídos, elas necessitam de ummecanismo que possa distribuir as requisições de modo que um servidor não fiquesobrecarregado 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 detodos os recursos computacionais (COSTA, 2008).
  • 17. 17 Os sistemas de cluster baseado em balanceamento de carga integram seusservidores para que todas as requisições provenientes dos clientes sejam distribuídas demaneira equilibrada entre estes. Os sistemas não trabalham junto em um único processo, masredirecionando as requisições de forma independente, assim que chegam baseados em umescalonador e um algoritmo próprio.2.8 - REPLICAÇÃO Uma técnica de tolerância a falhas é replicação, uma redundância útil utilizadapara garantir a disponibilidade do sistema de forma que se uma das réplicas produzidasfalharem, e remanescentes poderão continuar a prover o serviço. Essa técnica é utilizada paramelhorar 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ídoconsistente (PASIN, 2003, p.44). Para satisfazer essa consistências, um protocolo dereplicação precisa obedecer às seguintes propriedades (GUERRAOUI, 1997, p.69 citado porPAZIN, 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 devemser levados em consideração no que diz respeito ao cliente. Este deve acessar um dadoreplicado da mesma forma que acessaria o original, ou seja, sem perceber qualquer tipo demudança, mantendo-se a consistência dos dados replicados garantindo que mesmo após aocorrência de falhas as replicas possam prover o serviço a partir do estado em que ocomponente primário se encontrava (FRANIVAM, 2011).2.9 - CLUSTER
  • 18. 18 Um cluster é um conjunto de dois ou mais servidores que trabalham juntos, deforma 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 altadisponibilidade e/ou tolerância a falhas. Balanceamento de carga e replicação dos estados dassessõ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 deservidores web utilizando o apache como balanceador de carga e os Tomcat’s trabalhando emclusters, 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 osistema Jazida, um sistema de indexação e busca de documentos de texto e imagem. Osistema Jazida funciona baseado em cluster e neste sistem foi desenvolvida uma política detolerância a falhas onde existe um componente chamado Cluster Service que envianotificações para cada data node verificando se algum node está inacessível e o mesmo elegeoutro para assumir o node que está inacessível.
  • 19. 193 - PROPOSTA DE UM AMBIENTE DE ALTA-DISPONIBILIDADE3.1 - CENÁRIO O cenário utilizado para a criação do ambiente de alta disponibilidade utiliza aversão 6.0.35 do Tomcat, o apache 2.2 e o Mysql 5.0.95. Atualmente um dos maioressistemas desenvolvidos pela empresa está hospedado em um determinado servidor e asdemais aplicações menores estão hospedados em outro servidor, caso ocorresse alguma falhade hardware ou software em algum desses servidores, o sistema ficaria indisponível até que oproblema seja resolvido, podendo acarretar também a perda de dados em caso de falha nosarquivos de banco de dados. Para construção deste cenário será feito uma duplicação da hospedagem daaplicação onde dois Tomcat’s ficam em servidores distintos que respondem ao mesmo tempoas requisições vinda dos usuários. O apache ficará responsável por fazer o balanceamento de carga dasrequisições, realizando um controle sobre o acesso aos Tomcat’s, assim parte das requisiçõesvai para um Tomcat e parte das requisições vai para outro, garantindo que nenhum Tomcatfique sobrecarregado quanto ao número de requisições. Caso um Tomcat pare de funcionar oapache encaminha os acessos para outro Tomcat que estiver ativo. Para garantir que os dados não sejam perdidos, se ocorrer alguma falha dehardware ou software, será implementado uma política de replicação do banco de dados dosistema onde temos um banco principal, chamado de master, que replica os dados para obanco secundário, chamado de slave. Se o master falhar, rapidamente o slave é posto emprodução passando a ser banco de dados master. Assim temos uma solução que garante a disponibilidade do sistema e dosdados. A Figura 1 representa o cenário proposto neste projeto.
  • 20. 20 Figura 1: Cenário proposto neste projeto Neste projeto as requisições vinda do usuário vão para o balanceador de cargacom o endereço, http://192.168.56.102/orbis e o mesmo desviará as requisições para os doisservidores web http://192.168.56.102:8081/orbis e http://192.168.56.103:8082/orbis. Estes endereçosmencionados 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. Existetambém um servidor de banco de dados master e outro servidor de servidor de banco de dadosslave 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áquinasvirtuais onde as características estão descritas abaixo: • Servidor 1:
  • 21. 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. Nesteambiente 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ósdo cluster, como mostra a Figura 2. Figura 2: Replicação de sessões
  • 22. 22 O tomcat-cluster permite que se um nó falhe, as requisições vinda dos clientespara este nós sejam desviadas para um nó ativo sem que o usuário perceba, pois sua sessãocontinuará 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 pontosdevem 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ãotodos-para-todos. O algoritmo utilizado tem uma eficiência melhor em cluster de pequenoporte, pois em grandes cluster a quantidade de informações trafegadas entre os nós seriaenorme e isso afetaria o desempenho da aplicação. A solução para este problema é fazer adivisão de um cluster de grande em vários grupos de cluster menores utilizando endereços demulticast diferentes para cada cluster menor. Vale lembrar que a replicação de sessão é apenas uma característica entrevá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 docluster, isto é feito em apenas um dos nós, que automaticamente, esta tarefa será realizada nosdemais componentes do cluster.
  • 23. 233.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 TCPdefinida durante a configuração do cluster. O Tomcat fica escutando nesta porta aguardando oenvio de sessões vindo de outros nós (APACHE, 2011). O Sender é o componente responsável pelo envio das sessões para outroTomcat. 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 aparceria 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 foicompletada 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 nocluster. 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 novaaplicação, o Deployer fará a cópia desta aplicação para todos os outros nós do cluster. Issotambé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 dereplicação de sessão de um cluster composto por um Tomcat A e um Tomcat B que receberequisições no decorrer do tempo.
  • 24. 24 Figura 3: Funcionamento do Tomcat-Cluster Na imagem acima o Tomcat A inicializa utilizando uma sequencia padrão deinicializaçã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 ocontexto replicado, a partir deste momento o cluster é ativado e o Tomcat irá criar umDeltaManager para o contexto, ao invés de um StandardManager. A classe cluster, através deuma comunicação multcast inicializará um Membership Service e um Replication Serviceutilizando 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 osservidores onde cada instancia de Tomcat irá periodicamente enviar um ping multicastcontendo seu IP e sua porta TCP utilizadas na replicação, se não foi recebido nenhum pingvindo de um determinado nó durante um tempo limite, este nó é considerado morto. OTomcat B requisita os estados de sessão do Tomcat A e este só responderá ao pedido assimque o Tomcat B finalizar sua inicialização ficando pronto para receber as conexões vinda dosusuários.
  • 25. 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 acontecedepois que a resposta está pronta e a partir dai o ReplicationValve irá interceptar a respostaantes 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 mesmofoi excluído do cluster, fazendo com que o Tomcat B remova o A da lista de participantes docluster, as sessões não serão replicadas e o balanceador irá desviar as requisições destinadaspara o Tomcat A. Quando o Tomcat A reinicializa, este recebe uma requisição e uma instruçãode finalização da sessão S1. Quando o pedido de fim de sessão é recebido, o Tomcat Ainvalida aquela sessão e o mesmo enviará uma mensagem de sessão S1 expirou para o TomcatB 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 omesmo processo de replicação de sessão descrito acima. Todo o processo de replicação ocorre utilizando conexões TCP. Uma vez queum ping multicast é recebido, o nó de origem do ping é adicionado ao cluster. Utilizando asinformações vinda da comunicação multicast, os nós estabelecem conexões TCP para, atravésdestas, realizar a replicação das sessões. O propósito da utilização do protocolo TCP, é queele garante a entrega dos pacotes e realiza controle de fluxo. Assim fica garantida a entregadas mensagens de replicação.3.2.4 - Configuração Para preparar os Tomcat’s para o cluster, é realizada a edição do arquivo deconfiguração server.xml, localizado no diretório conf do Tomcat, A Figura 4 mostra o trechode configuração do cluster.
  • 26. 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 ondefoi 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. 27 Em ambos os Tomcat’s temos as tag’s Membership e Receiver com os seusrespectivos endereços e portas. No Membership o endereço de multcast é o 228.0.0.4 e a portautilizada para envios dos pings de multicast é a 4556. No Receiver temos o endereço queindica o ip de cada servidor. No Tomcat A o ip é 192.168.56.102 e a porta 4000 utilizadospara receber conexões do servidor http://192.168.56.103:8082/orbis. No Tomcat B temos o ip192.168.56.103 e a porta 4001 utilizados para receber as conexões vinda do servidorhttp://192.168.56.102:8081/orbis. Após estas configurações têm-se dois servidores Tomcat configurados paratrabalhar 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 obalanceamento de carga entre os dois Tomcat’s. Este receberá as requisições vinda dosusuários e o mesmo enviará as requisições para cada Tomcat de acordo com o número derequisições. Neste projeto foram desenvolvidas várias funcionalidades para o servidorapache, uma delas é a de se trabalhar como um servidor Proxy recebendo as requisições dosusuarios, fazendo a comunicação com o servidor de destino e passando a resposta de voltapara 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, comomostra a Figura 5.
  • 28. 28 Figura 5: Balanceamento de Carga O site www.siteexemplo.com sendo o balanceador de carga receberá asrequisiçõ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 desempenhomaior 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 apachepassa a trabalhar como um proxy ftp, http e ssl (APACHE, 2011). O apache, como proxy, pode ser configurado em dois modos: Foward eReverse. Um Foward Proxy é um servidor intermediário que fica entre o cliente e o servidorde origem. Para que um cliente requisite uma página web, ele envia uma requisição para oservidor Proxy que requisita o conteúdo pedido ao servidor de destino e retorna a resposta ao
  • 29. 29cliente. O cliente deve ser configurado para utilizar o Foward Proxy para poder navegar naweb. É comum se utilizar o Forward Proxy como provedor de acesso a internet para redes. AFigura 6 mostra um exemplo de funcionamento do Forward proxy. Figura 6: Funcionamento do Forwad Proxy O Forward Proxy é ativado utilizando a diretiva “ProxyRequests On”. Devidoo Forward Proxy prover acesso a sites através de um servidor e de esconder a verdadeiraorigem do acesso, é importante que seu administrador limite o acesso a somente aquelesusuários que forem autorizados. Um Reverse Proxy, ao contrário do Forward Proxy, aparece ao usuário comoum servidor web comum. Não é necessária nenhuma configuração no cliente, o usuário fazrequisições normais ao Reverse Proxy. O Reverse Proxy então decide para onde enviar estasrequisições e retorna o conteúdo da resposta ao cliente. A Figura 7 mostra um exemplo defuncionamento do Reverse Proxy.
  • 30. 30 Figura 7: Funcionamento do Reverse Proxy Reverse Proxy é comumente utilizado para permitir que usuários acessemservidores que se encontram atrás de firewall’s. O Reverse Proxy pode também ser utilizadocomo balanceador de carga entre vários servidores finais ou para prover um cache paraservidores 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 paraprotocolos 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 derequisições e outro que leva em conta a quantidade de informações trafegada para cadaservidor.
  • 31. 31 Aqui um exemplo de como pode ser configurado um balanceador de carga noapache:<Proxy balancer://balancer>BalancerMember http://192.168.1.3:8080BalancerMember http://192.168.1.4:8081</Proxy>ProxyPass /test balancer://balancer/ Neste exemplo tem-se um balanceador chamado de balancer contendo doiselementos, http://192.168.1.3:8080 e http://192.168.1.4:8081. Na linha “ProxyPass /testbalancer://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, nomomento 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 omod_proxy e o mod_proxy_balancer. A partir do cenário descrito no inicio deste projeto, temos a Figura 8 quemostra o trecho do arquivo de configuração do apache, httpd.conf:
  • 32. 32 Figura 8: Virtual Host A figura acima mostra a configuração de um virtual host que será responsávelpelo 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 caso192.168.56.102. Em ProxyRequest off, dizemos ao apache que não será utilizado como umservidor proxy ou um Reverse Proxy, não atendendo a requisições de sites diferentes dosistema. Na linha abaixo: ProxyPass /orbis balancer://balancer/sticksession=JSESSIONID no failover=Off É dito ao apache que qualquer requisição destinada ao contexto /orbis dentrodo sistema, será utilizado o balanceador de carga para atender as demandas. Com a opção stickysession=JSESSIONID, o apache irá direcionar os pedidosde uma mesma sessão para o servidor. A opção nofailover=Off, determina que os membrospertencentes ao balanceador de carga têm a capacidade de superar uma falha de um dosmembros, com isso, se for detectado um membro inativo, o apache irá desviar todas asrequisições antes enviadas a este membro, para um outro membro. As opções abaixo são diretrizes para corrigir as respostas vinda dos servidoresbalanceados, baseando-se na requisição original vinda do cliente.
  • 33. 33ProxyPassReverse /orbis http://192.168.56.102:8081/orbisProxyPassReverse /orbis http://192.168.56.103:8082/orbis Nas linhas seguintes são descritas a configuração onde é declarado obalanceador de carga e os seus membros com suas devidas características como nome da rotae 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 loadfactordetermina qual carga cada membro receberá em relação aos demais membros, como porexemplo, se um membro estiver com loadfactor igual a 1 e o outro membro estiver comloadfactor 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 debalanceamento de carga será utilizado. Pode ser utilizado o método de balanceamento porquantidade de requisições com lbmethod=byrequests onde tem-se que cada requisição irá paraservidores 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á serdefinida de acordo com a largura de banda do seu link, ou seja, se uma requisição quecarregar uma grande quantidade de bytes para um servidor as próximas requisições de sessõesdiferentes serão destinadas para os demais membros do balanceamento até que este fiqueliberado 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 balanceamentode carga em dois Tomcat’s no sistema orbis.
  • 34. 343.4 - REPLICAÇÃO NO MYSQL A replicação de dados permitirá que, no caso de um servidor X falhar, comuma pequena mudança de no endereçamento dos ip’s dos servidores Mysql o sistema possavoltar 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 projetosã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 comos backups, porém não substitui uma boa politica de backup, pois qualquer comando erradoexecutado no servidor X será executado no servidor Y, inclusive um “drop database”. Sempredeve ser feito backup.3.4.1 – Funcionamento A replicação de dados é feita de forma assíncrona, não é necessário que umservidor slave fique continuamente conectado ao master. Ela funciona através do uso de ummecanismo 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. 35 Figura 9: Funcionamento da Replicação A primeira parte do processo é log binário no master. Antes de cada transaçãoque 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), chamadade thread I/O. A thread de I/O abre uma conexão do cliente ao master e inicia um processo deesvaziamento de binlog. O processo de esvaziamento de binlog lê o evento a partir do logbiná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 repetidosatualizando os dados no servidor slave, através da thread SQL, para combinarem com os domaster. E assim todos os eventos ocorridos das bases de dados do master serão executados nasbases de dados do slave. Inicialmente, para a criação da replicação, deve ser feito um backup das basesque serão replicadas no master. Após ter sido gerado o backup, a criação do log binário deveser habilitada e assim todos os comandos executados no master ficarão gravados neste log. Obackup será restaurado em cada servidor slave. Não é possível configurar o master para que ele grave somente certoscomandos. Fica a cargo do slave decidir quais comandos ele deverá executar localmente. Noslave são configuradas quais bases de dados ou tabelas serão replicadas. Durante a leitura e
  • 36. 36execução do log, o slave guarda o log lido e a posição do ultimo comando executado. Comisso, é possível que diferentes slaves executem diferentes partes do mesmo log. Cada servidor que participa da replicação, master e slaves, devem ter umaidentificação única através da opção server-id. Os slaves devem ser informados do nome dohost 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 daedição do arquivo my.cnf que fica dentro do diretório “/etc/” no servidor. A seguir sãomostrados 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 doservidor 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 dolog 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 domysql, este deve ser reiniciado para aplicar as alterações. Para acontecer à replicação, o servidor slave fará uma conexão com o servidormaster, para que isso seja possível, deve-se criar um usário com permissões de replicação nabase 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. 37 Com base nessas informações, deve-se execultar os seguintes comandos paraconfigura 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 todasas 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 noservidor slave. Em seguida é necessário editar o arquivo my.cnf e adcionar as seguintesopçõ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çõesconfigurada 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, elog_slave_updates, que diz para o slave logar os eventos replicados para o seu próprio logbinário. Depois de editado o arquivo de configuração do Mysql, é necessário informarao 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 seaponte o slave a um master diferente sem parar o servidor. Neste projeto foi utilizado aseguinte 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. 38 Aqui a opção MASTER_HOST, define o endereço do servidor master, asopções MASTER_USER e MASTER_PASSWORD definem o usuário e senha que possui apermissão de replicação. MASTER_LOG_FILE é o nome do primeiro log binário que foigerado e por fim a opção MASTER_LOG_POS é configurado em 0 pois este é o inicio dolog. Os servidores de banco de dados estão configurados para realizarem replicaçãoporém ainda não é possível que o servidor slave realize replicação, pois os processos do slavenã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, ocomando SHOW SLAVE STATUS mostra toda a configuração do servidor slave, a Figura10 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 eSlave_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 eno slave. A Figura 11 mostra no master uma conexão criada pela thread de E/S do slave:
  • 39. 39 Figura 11: Threads de replicação No slave, a Figura 12 mostra duas treads, uma é a thread de E/S, e a outra é athread SQL: Figura 12: Threads de E/S e Thread SQL
  • 40. 40 E com isso pode-se observar que a replicação entre dois servidores de banco dedados 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áriostestes com o objetivo de verificar se todos os elementos do projeto estão funcionandocorretamente. Foram executado também, testes de performance, afim de identificar se asolução de cluster de servidores além de proporcionar alta disponibilidade, ela tambémaumenta a performance do sistema. Para realização dos testes, foi utilizado o Psi Probe, uma ferramenta opensource serve para analisar e gerar gráficos e relatórios sobre o funcionamento dos Tomcat’s, ojMeter, uma ferramenta, também opensource, utilizada para realização de testes deperfomance, estress e carga4.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 13mostra 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” estafuncionando de acordo com o planejado. A mesma figura mostra o resultado do probe em um
  • 41. 41Tomcat, que por sua vez possui o mesmo resultado no outro Tomcat. A segunda forma deteste seria desativando um dos Tomcat’s e verificar a aplicação continua disponível. Foirealizado esse teste e conforme o planejado, a aplicação continuou disponível e logo foireativado o Tomcat e o mesmo recebeu as sessões que estavam sendo replicada, garantindo oprincipal 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 outroservidor 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 “SHOWSLAVE STATUSG” que foi mencionado anteriormente. Esse comando mostra o estado atualda 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 bancoslave 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 quefoi mencionado anteriormente. Com esta ferramenta, foi possível realizar testes deperformance 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. 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 asimulação de 100 usuários realizando cadastro no sistema foi gerado mais de 34 mil sessões eestas foram replicadas entre os Tomcat’s. A Figura 14 mostra o resultado do teste realizadona 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 intervaloentre 22 horas e 22 horas e 20 minutos, a execução do teste com jMeter gerou um volume de trafego15.000.000 Bytes. Outro resultado desse teste é mostrado através da Figura 15:
  • 43. 43 Figura 15: Uso da CPU no cluster De acordo com o que é mostrado na Figura 15, podemos perceber que nomesmo intervalo mencionado anteriormente, os testes do jMeter consumiram 12,5 % doprocessamento no servidor. Os mesmos testes executados no cluster foram executados em cada Tomcat. AFigura 16 mostra primeiro resultado do teste: Figura 16: Volume de tráfego (bytes) no Tomcat A
  • 44. 44 Através da Figura 16, podemos perceber que no intervalo das 22:40 horas às23:00 horas o volume de trafego aumentou consideravelmente atingindo um valor de75.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 processamentoaumentou 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émgarante a alta performance dos sistemas.5 – CONCLUSÃO O desenvolvimento desse projeto com os testes realizados pode-se perceber aeficácia da utilização das ferramentas e técnicas apresentadas. Ocorreu realmente o que foiprevisto e o que foi desejado. O balanceador de carga utilizando o Servidor Web Apachefuncionou conforme o esperado. O Cluster de Tomcat, também funcionou de formasatisfatória e com um bom desempenho. E por ultimo a replicação de banco de dados MySQLque funcionou e cumpriu o seu dever como foi esperado. Podemos concluir que tudo que foi proposto, foi alcançado desde a proposta dealta disponibilidade até alta performance. Podemos concluir também que este ambiente nãogera um alto custo com software, pois se faz o uso de software livre, apenas investimento emhardware quando necessário.
  • 45. 456 – REFERÊNCIAS BIBLIOGRÁFICASAPACHE. 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 dealta 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.edBookman 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, InstitutoFederal do Piauí.GONÇALVES, Edson.; Tomcat – Guia Rápido do Administrador, 2006 243p. EditoraCiência Moderna.GUERRAOUI, R,; SHIPER, A. Software-Based replication for fault tolerance. Citato porPASIN, M. Replicas para Alta disponibilidade em Arquiteturas Orientadas aComponentes com Suporte de Comunicação de Grupo, 2003. 127f. Tese de Doutoradosubmetida à avaliação, como requisito parcial para obtenção do grau de Doutor em Ciência daComputado, Universidade Federal do Rio Grande do Sul, Porto Alegre 2003.MILANI, André. MySQL: Guia do Programador, 2007 400p. Editora NOVATEC. Cap 1, p22-33
  • 46. 46PASIN, M. Replicas para Alta disponibilidade em Arquiteturas Orientadas aComponentes com Suporte de Comunicação de Grupo, 2003. 127f. Tese de Doutoradosubmetida à avaliação, como requisito parcial para obtenção do grau de Doutor em Ciência daComputado, 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. 2004RIBEIRO, 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 de2011.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 eAplicaçõ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.