Homologação de Ambiente HA para SIGs UFRN

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO
GRANDE DO NORTE
EDMILSON PEREIRA DA COSTA JÚNIOR
HOMOLOGAÇÃO DE AMBIENTE DE ALTA DISPONIBILIDADE PARA OS
SISTEMAS SIG DA UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE
Natal-RN
2014

Monografia apresentada à Banca Examinadora do
Trabalho de Conclusão do Curso de Tecnologia
em Redes de Computadores, em cumprimento às
exigências legais como requisito parcial à
obtenção do título de Tecnólogo em Redes de
Computadores.
Orientador: Msc. Francisco Sales de Lima Filho
Natal-RN
2014

Monografia apresentada à Banca Examinadora do
Trabalho de Conclusão do Curso de Tecnologia
em Redes de Computadores, em cumprimento às
exigências legais como requisito parcial à
obtenção do título de Tecnólogo em Redes de
Computadores.
Trabalho de conclusão de curso avaliado em 18 de março de 2014 pela banca
examinadora composta pelos seguintes membros:
Prof. MSc. Francisco Sales de Lima Filho (Orientador) DIATINF/IFRN
Prof. MSc. Aluizio Ferreira da Rocha Neto (Externo) SINFO/UFRN
Prof. MSc. Teobaldo Adelino Dantas de Medeiros (Interno) DIATINF/IFRN

Dedico esse trabalho ao meu falecido avô
Damião Pereira por ter sido um homem firme e
de princípios, que me ajudou até seu último dia
de vida. Sua honra e coragem me servirão de
exemplo e jamais serão esquecidas.

AGRADECIMENTOS
Agradeço a todos os professores do Instituto Federal de Educação, Ciência e
Tecnologia do Rio Grande do Norte (IFRN) que colaboraram no meu processo de
aprendizado e desenvolvimento profissional.
Agradeço a toda minha família e amigos pelo apoio e dedicação que tanto
contribuíram para minha formação, me apoiando e incentivando de qualquer forma
disponível.
Agradeço a minha noiva Viviane Mayara pelo amor, paciência e incentivo diário
ao longo de todo o curso.
Agradeço aos tantos amigos que formei ao longo do curso, o convívio com vocês
tornou a jornada mais divertida e enriquecedora, que os laços aqui criados
permaneçam vivos.
Agradeço a toda a Superintendência de Informática da Universidade Federal do
Rio Grande do Norte pela contribuição em minha formação profissional e
disponibilização dos recursos necessários para realização desse trabalho, em especial
aos amigos Bruno Anacleto e Júlio Lima que me auxiliaram em quesitos relativos à
virtualização e funcionamento do ambiente.
Agradeço ao meu orientador Sales Filho que sempre esteve disponível, me
direcionando na produção do trabalho com sua experiência e conhecimento.

RESUMO
A disponibilidade de sistemas críticos ao funcionamento de instituições como a
Universidade Federal do Rio Grande do Norte (UFRN) configura prioridade crítica para
a implementação de mecanismos que possibilitem a alta disponibilidade de serviços. A
evolução da informatização de processos bem como de sua adoção pelos diferentes
setores da universidade tornou imperativo demandar esforços na implantação de
técnicas que objetivem a criação de um ambiente de produção redundante e escalável.
O objetivo essencial deste trabalho é simular, em ambiente virtual voltado para
homologação, a infraestrutura de produção dos Sistemas Integrados de Gestão (SIG)
da universidade, implementando e homologando mecanismos de alta disponibilidade
para eliminação de pontos únicos de falha.
Palavras-chave: Informatização. Sistemas críticos. Homologação. Alta disponibilidade.

ABSTRACT
The availability of critical systems to the operation of institutions such as the
Federal University of Rio Grande do Norte (UFRN) configures critical priority for the
implementation of mechanisms that enable high availability of services. The evolution of
the computerization process and its adoption by different sectors of the university
became imperative demand efforts in the implementation of techniques that aim to
create a production environment redundant and scalable. The main goal of this work is
to simulate, in a virtual environment geared toward homologation, the production
infrastructure of the university Integrated Management Systems (SIG), ratifying and
implementing high availability mechanisms to eliminate single points of failure.
Key Words: Informatization. Critical systems. Homologation. High availability.

LISTA DE ILUSTRAÇÕES
FIGURA 1 - MODELO DE OPERAÇÃO DO AMBIENTE DE PRODUÇÃO CONTENDO DOIS SERVIDORES
DE BANCO DE DADOS, VÁRIOS SERVIDORES DE APLICAÇÃO E UM BALANCEADOR. 14
FIGURA 2 - RELACIONAMENTO DOS SISTEMAS SIG E SUAS FUNCIONALIDADES. 21
FIGURA 3 - NOVO MODELO COM APLICAÇÃO CENTRALIZADA EM UM SERVIDOR WEB. 22
FIGURA 4 - BALANCEAMENTO DE REQUISIÇÕES EXECUTADO PELO APACHE E MOD_JK. 24
FIGURA 5 - REPLICAÇÃO NATIVA DO POSTGRESQL BASEADA NA TRANSFERÊNCIA DE ARQUIVOS
WAL. 26
FIGURA 6 - LISTAGEM DE HOSTS DO AMBIENTE VIRTUAL MONITORADOS PELO ZABBIX. 31
FIGURA 7 - TOPOLOGIA DO AMBIENTE VIRTUAL PROPOSTO UTILIZANDO CLUSTER NA CAMADA DE
BALANCEAMENTO E REPLICAÇÃO ENTRE OS SERVIDORES DE BANCO DE DADOS. 33
FIGURA 8 - TESTE DE ACESSO AO SIGAA DURANTE PROCEDIMENTO DE FAILOVER DO
BALANCEADOR. 41
FIGURA 9 - TESTE DE ACESSO AO SIGAA DURANTE PROCEDIMENTO DE FAILBACK DO
BALANCEADOR. 42
FIGURA 10 - MEMBROS DO GRUPO DE BALANCEAMENTO ACADEMICOLB NO JKSTATUS. 42
FIGURA 11 - MEMBROS DO GRUPO DE BALANCEAMENTO ADMINISTRATIVOLB NO JKSTATUS. 43
FIGURA 12 - TESTE DE ACESSO AO SIGAA DURANTE O PROCEDIMENTO DE FAILOVER DO
SERVIDOR DE BANCO DE DADOS. 43
FIGURA 13 - TELA DO JMETER COM ROTEIRO PARA TESTE DE CARGA NO SIPAC. 45
FIGURA 14 - GRÁFICO DO LOAD AVERAGE DA CPU PARA O SERVIDOR HABDSISTEMAS1. 46
FIGURA 15 - GRÁFICO DA MEMÓRIA RAM PARA O SERVIDOR HABDSISTEMAS1. 46
FIGURA 16 - GRÁFICO DO LOAD AVERAGE DA CPU PARA O SERVIDOR HASISTEMAS1. 47
FIGURA 17 - GRÁFICO DA MEMÓRIA HEAP PARA A INSTÂNCIA HASISTEMAS1I2. 47
FIGURA 18 - GRÁFICO DE UTILIZAÇÃO DE THREADS DO APACHE PARA O SERVIDOR
HABALANCER1. 48
FIGURA 19 - GRÁFICO DE VALORES MÉDIOS DO TEMPO DECORRIDO ENTRE A REQUISIÇÃO E O
DOWNLOAD COMPLETO DE CADA PÁGINA FEITA AO SIPAC. 49
FIGURA 20 - GRÁFICO DE VALORES MÉDIOS DO TEMPO DECORRIDO ENTRE A REQUISIÇÃO E O
DOWNLOAD COMPLETO DE CADA PÁGINA FEITA AO SIGAA. 49
FIGURA 21 - RESULTADO DO PRIMEIRO ESCANEAMENTO POR VULNERABILIDADES NOS
SERVIDORES DO AMBIENTE. 50
FIGURA 22 - RESULTADO DO SEGUNDO ESCANEAMENTO APÓS CORREÇÃO DE FALHAS. 51

LISTA DE QUADROS
QUADRO 1 - SERVIDORES E SUA FUNÇÃO NO AMBIENTE. 32
QUADRO 2 - CONFIGURAÇÃO DOS SERVIDORES DO AMBIENTE PROPOSTO 32
QUADRO 3 - CONFIGURAÇÕES DE INSTÂNCIAS DO JBOSS 37

LISTA DE ABREVIATURAS E SIGLAS
IFRN Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande
do Norte
UFRN Universidade Federal do Rio Grande do Norte
SIG Sistemas Institucionais Integrados de Gestão
SGBD Sistema Gerenciador de Banco de dados
JEE Java Platform, Enterprise Edition
JVM Java Virtual Machine
HTTP Hypertext Transfer Protocol
AJP Apache JServ Protocol
WAL Write Ahead Log
CVSS Common Vulnerability Scoring System

SUMÁRIO
1. INTRODUÇÃO 12
1.1. PROBLEMA DE PESQUISA 12
1.2. OBJETIVOS 14
1.3. OBJETIVOS ESPECÍFICOS 14
1.4. ESTRUTURA DO TRABALHO 15
2. FUNDAMENTAÇÃO TEÓRICA 16
2.1. HOMOLOGAÇÃO 16
2.1.1. HOMOLOGAÇÃO FUNCIONAL 16
2.1.2. HOMOLOGAÇÃO NÃO FUNCIONAL 16
2.2. VIRTUALIZAÇÃO 17
2.2.1. TECNOLOGIA DE VIRTUALIZAÇÃO 17
2.2.2. MOTIVAÇÃO PARA O USO DA VIRTUALIZAÇÃO 17
2.3. ALTA DISPONIBILIDADE DE SISTEMAS 18
2.3.1. PROCEDIMENTO DE FAILOVER E FAILBACK 18
2.4. BALANCEAMENTO DE CARGA 19
2.5. SOFTWARE LIVRE 20
2.5.1. SISTEMA OPERACIONAL GNU/LINUX 20
2.6. SISTEMAS DE INFORMAÇÃO GERENCIAL DA UFRN 21
2.7. SERVIDORES DE APLICAÇÃO 22
2.7.1. JBOSS 23
2.7.2. APACHE 23
2.7.2.1. Balanceamento de carga com Apache + Mod_jk 23
2.8. SERVIDORES DE BANCO DE DADOS 25
2.8.1. SISTEMA GERENCIADOR DE BANCO DE DADOS POSTGRESQL 25
2.8.1.1. Replicação nativa do PostgreSQL 25
2.9. FERRAMENTAS PARA CONFIGURAÇÃO DE ALTA DISPONIBILIDADE 28
2.9.1. HEARTBEAT 28
2.9.2. CSYNC2 28
2.10. FERRAMENTAS PARA HOMOLOGAÇÃO DE SISTEMAS 29
2.10.1. APACHE JMETER 29
2.10.2. OPENVAS 29
2.10.3. ZABBIX 30

3. DESENVOLVIMENTO DO PROJETO 32
3.1. DESCRIÇÃO DO AMBIENTE 32
3.2. FERRAMENTAS 34
3.3. OPERAÇÃO 34
3.3.1. SERVIDORES DE BANCO DE DADOS 35
3.3.1.1. Procedimento de failover 35
3.3.1.2. Procedimento de failback 36
3.3.2. SERVIDORES DE APLICAÇÃO 37
3.3.3. SERVIDORES DE BALANCEAMENTO 38
3.3.3.1. Alta disponibilidade com Heartbeat 38
3.3.3.2. Tratamento de sessões 39
3.4. RESULTADOS 40
3.4.1. HOMOLOGAÇÃO DE MECANISMOS DE ALTA DISPONIBILIDADE 40
3.4.1.1. Primeiro experimento – Falha do servidor primário de balanceamento 41
3.4.1.2. Segundo experimento – Retorno do servidor primário de balanceamento 41
3.4.1.3. Terceiro experimento – Tolerância à falha do servidor de aplicação 42
3.4.1.4. Quarto experimento – Tolerância à falha do servidor de banco de dados 43
3.4.2. HOMOLOGAÇÃO DO AMBIENTE COM TESTE DE CARGA 44
3.4.3. HOMOLOGAÇÃO DO AMBIENTE QUANTO A QUESITOS DE SEGURANÇA 49
4. CONSIDERAÇÕES FINAIS 52
4.1. CONCLUSÃO 52
4.2. SUGESTÕES E RECOMENDAÇÕES 53
REFERÊNCIAS 54
APÊNDICE A – SCRIPT PARA SINCRONIZAÇÃO INICIAL DOS BANCOS DE
DADOS MESTRE – ESCRAVO. 56
APÊNDICE B – SCRIPT AUXILIAR DO PROCESSO DE FAILOVER ENTRE
SERVIDORES DE BANCO DE DADOS. 57
APÊNDICE C – SCRIPT AUXILIAR DO PROCESSO DE FAILBACK ENTRE
SERVIDORES DE BANCO DE DADOS. 58

12
1. INTRODUÇÃO
Ao longo das últimas décadas acompanhamos a larga mudança no modo como
o trabalho é desempenhado em suas diversas categorias e classes, parte significativa
dessa mudança se deve ao desenvolvimento tecnológico que ganha força a partir da
redução dos custos relacionados aos microcomputadores e a popularização da
internet. Atualmente, parte significativa das tarefas realizadas no trabalho envolve
direta ou indiretamente a presença de um sistema de computador.
Como consequência dessa estreita dependência entre o trabalho e os sistemas
de computadores, mecanismos devem ser empregados para assegurar que os
sistemas tenham alta disponibilidade.
Para Universidade Federal do Rio Grande do Norte (UFRN), o desenvolvimento
destes sistemas vem ao encontro de uma meta da administração que se denomina “A
informática como Atividade Meio”. Ou seja, utilizar a informatização no dia a dia da
instituição. Tal medida resultou numa série de sistemas que buscam integrar e
informatizar procedimentos, substituindo os sistemas legados utilizados até então.
Dentre os sistemas desenvolvidos, os mais relevantes são o Sistema Integrado
de Gestão de Atividades Acadêmicas (SIGAA), o Sistema Integrado de Gestão de
Patrimônio, Administração e Contratos (SIPAC) e o Sistema Integrado de Gestão e
Recursos Humanos (SIGRH) que iniciaram sua operação em meados de 2006 e 2007.
Resultante do esforço e investimento no desenvolvimento de sistemas surgiu a
necessidade de ampliação da infraestrutura de Tecnologia da Informação (TI) para
comportar a nova demanda. Como a criação de um datacenter utilizando servidores no
formato Blade1
e adoção de virtualização. No entanto, observa-se no ambiente de
produção dos sistemas da UFRN, uma carência quanto à utilização de mecanismos de
alta disponibilidade, pois a baixa redundância das camadas do ambiente expõe os
sistemas ao risco de indisponibilidade, resultando em transtornos para seus usuários.
1.1. PROBLEMA DE PESQUISA
Com o crescimento dos sistemas da universidade bem como da população de
usuários, observou-se uma crescente demanda por recursos de software e hardware,
que culminou na criação de um ambiente em camadas contendo servidores com papeis
1
Formato de alta densidade para hardware, empacotando servidores, storages e switches em um
mesmo chassis.

13
bem definidos. Sumariamente, o ambiente deve conter três tipos básicos de servidores
para operar, servidores de banco de dados, servidores de aplicação e servidores de
balanceamento de carga.
Atualmente, o ambiente de produção da universidade é composto por dois
servidores de banco de dados, nos quais é instalado o Sistema Gerenciador de Banco
de Dados (SGBD) PostgreSQL, sendo um destes, responsável pelos bancos
acadêmicos e outro pelos bancos administrativos. Os servidores de aplicação operam
com o JBoss, configurados de modo que cada servidor de aplicação possua duas
instâncias com sistemas distintos em cada uma delas, provendo redundância dos
sistemas. Finalmente, o ambiente possui um servidor com função de balanceamento
utilizando o serviço WEB Apache com o módulo JK (mod_jk) para balanceamento de
carga entre instâncias do JBoss.
A estrutura descrita acima apresenta boa escalabilidade, permitindo a adição de
novas instâncias de aplicação para atender novas porções de trabalho, no entanto, é
importante observar que o ambiente descrito apresenta dois pontos de falha que
colocam toda a estrutura em risco de indisponibilidade.
O primeiro e mais crítico ponto de falha é a falta de redundância dos servidores
de banco de dados, que possuem bancos distintos entre si, mas apresentam
dependência em nível de sistema, fazendo-se necessário a presença de todos os
bancos para que os sistemas funcionem corretamente. Essa estrutura carece de
mecanismos de alta disponibilidade que permitam redundância e consistência de
dados. Atualmente os backups são executados automaticamente cinco vezes ao dia,
em horários estratégicos de baixa utilização. Em uma situação hipotética na qual um
banco de dados seja corrompido, seria necessário recuperar o banco a partir do último
backup realizado, implicando na perda dos dados gerados após a execução deste.
O segundo ponto de falha é o servidor de balanceamento dos sistemas, que tal
como os servidores de banco de dados, não apresenta redundância, em uma situação
hipotética de falha no sistema operacional ou sistema de arquivos, por exemplo, seria
necessário configurar um novo servidor para assumir seu lugar.
A Figura 1 retrata o modo de operação desta topologia, formada por um servidor
de balanceamento não redundante, servidores de aplicação que podem ser
adicionados quando necessário e dois servidores de banco de dados não redundantes.

14
Figura 1 - Modelo de operação do ambiente de produção contendo dois servidores de
banco de dados, vários servidores de aplicação e um balanceador.
Fonte: Elaborado pelo autor (2014)
É importante salientar que durante as situações hipotéticas apresentadas, os
sistemas ficariam indisponíveis por períodos que podem variar de diversos minutos até
algumas horas, implicando na alteração da rotina de praticamente todos os setores do
campus, uma vez que a execução das diversas tarefas estaria comprometida.
1.2. OBJETIVOS
Este trabalho tem como finalidade homologar mecanismos de alta
disponibilidade para o serviço de balanceamento de carga e banco de dados em um
ambiente proposto de homologação, configurando-o analogamente ao ambiente de
produção da UFRN. Esse ambiente proposto deverá ser capaz de recuperar de
incidentes que ocasionem a indisponibilidade dos sistemas. Espera-se ao fim desta
pesquisa, homologar segundo requisitos de segurança e testes de carga o ambiente
proposto, eliminando os pontos críticos de falha descritos na seção 1.1.
1.3. OBJETIVOS ESPECÍFICOS
Uma série de atividades específicas precisam ser executadas a fim de atingir os
objetivos descritos:

15
a. Desenvolver ambiente de homologação composto por máquinas virtuais em
topologia similar ao ambiente de produção da UFRN;
b. Configurar replicação nativa do PostgreSQL para todos os bancos dos
sistemas;
c. Implementar mecanismo de failover manual para os bancos de dados;
d. Configurar Heartbeat no servidor de balanceamento com mecanismos de
failover e failback automáticos;
e. Simular cenários de teste que possibilitem a comprovação dos mecanismos
de alta disponibilidade empregados;
f. Homologar o ambiente quanto aos quesitos de segurança;
g. Homologar o ambiente quanto aos quesitos de carga de trabalho.
1.4. ESTRUTURA DO TRABALHO
Este trabalho foi desenvolvido em quatro capítulos, descritos brevemente abaixo:
a. Capítulo 1: Apresenta a introdução do trabalho, apontando agentes
motivadores para realização da pesquisa e listando os objetivos almejados;
b. Capítulo 2: Descreve a fundamentação teórica necessária para o completo
entendimento do trabalho. Abordando conceitos importantes sobre alta disponibilidade
de sistemas, balanceamento de carga, software livre e ferramentas utilizadas;
c. Capítulo 3: Trata do desenvolvimento do trabalho, descrevendo o ambiente de
homologação. Apresenta experimentos em cenários controlados e resultados obtidos
com a implementação dos mecanismos de alta disponibilidade. Por fim, demonstra os
resultados relativos aos testes de carga de trabalho e segurança.
d. Capítulo 4: Apresenta as considerações finais do trabalho e opções de
pesquisa para trabalhos futuros.

16
2. FUNDAMENTAÇÃO TEÓRICA
Neste capítulo serão descritos aspectos teóricos necessários para o completo
entendimento do trabalho.
2.1. HOMOLOGAÇÃO
A homologação de sistemas é uma importante etapa do desenvolvimento do
software que busca assegurar que a aplicação atenda as necessidades do negócio.
Naturalmente, falhas encontradas mais cedo no processo de desenvolvimento são
menos custosas de solucionar, nesse sentido, o teste da aplicação é fundamental para
garantir que o sistema atenda as necessidades.
2.1.1. Homologação funcional
Os testes funcionais são baseados nas funções que o sistema foi projetado para
realizar. Suas funções são testadas e seu comportamento é analisado em busca de
possíveis bugs, essa analise está presente em todas as fases do projeto, de modo a
garantir que as funções realizem as tarefas para as quais foram desenvolvidas.
2.1.2. Homologação não funcional
Por sua vez, os testes não funcionais tratam de aspectos como usabilidade,
flexibilidade, desempenho e segurança da aplicação. Para este tipo de homologação,
geralmente são utilizadas ferramentas distintas das ferramentas utilizadas para testes
funcionais.
Testes não funcionais frequentemente estão ligados ao desempenho da
aplicação, que de modo mais especifico, depende de requisitos como confiabilidade e
escalabilidade. Em contraste a homologação funcional que estabelece o funcionamento
do software, o teste não funcional verifica se o software continua funcionando
corretamente mesmo em situações adversas, como a entrada de dados inválidos, ou a
utilização massiva do software. Nesse sentido, a homologação não funcional apresenta
um caráter mais amplo, que testa não só o software, mas o próprio ambiente no qual
este foi configurado. (SAMRA, 2013)

17
2.2. VIRTUALIZAÇÃO
É um mecanismo que permite o compartilhamento de recursos de uma máquina
para dois ou mais sistemas operacionais distintos e isolados. Atualmente a
virtualização da infraestrutura de TI vem ganhando espaço e se consolidando por ser
uma tecnologia que permite a redução de custos com o melhor aproveitamento de
recursos de hardware, escalabilidade, confiança e disponibilidade.
2.2.1. Tecnologia de virtualização
Basicamente, existem três tipos de tecnologias de virtualização: virtualização ao
nível do sistema operacional, servidores virtuais e para-virtualização ao nível da
máquina virtual. Segundo Henrique Lopes (2012):
O primeiro modelo é conseguido com o servidor a correr um único kernel
e através deste é feito o controlo dos SO dos servidores virtuais. Basicamente
são criados contentores isolados ou partições num único servidor físico, sendo
que as instâncias de SO correm independentemente das outras partições. Um
exemplo claro deste modelo é o SUN Solaris Zones.
O segundo modelo (servidores virtuais) baseado em servidores x86
assenta o hyper-visor, ou seja, a camada que coordena as operações dos
recursos físicos (processamento, interfaces de rede, disco) com os servidores
virtuais, sendo que existe uma máscara da camada física proporcionando uma
abstração dos SO que correm em cada servidor virtual. O exemplo mais
conhecido dentro deste modelo é o VMWare ESX, que foi a tecnologia
escolhida para o estudo da infraestrutura computacional devido á sua aceitação
de mercado (líder mundial na virtualização de servidores).
O último modelo tem semelhanças com o modelo de servidores
virtuais, no entanto, existe uma modificação no SO de cada servidor virtual
para permitir que estes corram corretamente. Um exemplo no mercado é o
Citrix Xen. (LOPES, 2012)
2.2.2. Motivação para o uso da virtualização
A motivação para implementação de virtualização decorre dos pontos negativos
associados à infraestrutura clássica, que impõe uma série de desafios, tais como:
a. Alto custo e ineficiência na gestão;
b. Subutilização de recursos físicos;
c. Menor eficiência energética, arrefecimento e espaço no centro de dados;
d. Complexidade de implementação de mecanismos de alta disponibilidade;
e. Elasticidade e adaptabilidade comprometida;
f. Custo geral elevado de toda a solução implementada.
A virtualização surge como solução para estas limitações, permitindo a criação e
gerenciamento de uma infraestrutura montada em máquinas virtuais, que podem com
certa facilidade receber atualizações de hardware e software adequando-se melhor às

18
funções que desempenham, resultando em uma infraestrutura mais adaptável e
escalável.
2.3. ALTA DISPONIBILIDADE DE SISTEMAS
Define-se como um conjunto de mecanismos que objetivam impedir interrupções
indesejadas, tornando-os tolerantes a falhas. Tais mecanismos podem ser
implementados em software e hardware redundantes, especializados em detecção,
recuperação e mascaramento de eventuais falhas. Costumeiramente, sistemas de alta
disponibilidade são configurados em modo cluster e sua definição está vinculada à
existência de um grupo de nós como servidores ou sistemas que visam à distribuição
de trabalho e redundância.
Segundo Bernard Golden (2008), empresas que necessitam de aplicativos como
elemento fundamental para execução de seu negócio não devem centralizar a
execução dos mesmos em um único servidor, pois este se torna um ponto único de
falha e caso alguma interrupção aconteça podem ser necessários minutos ou até
mesmo semanas para reestabelecer os serviços, dependendo da complexidade de
arquitetura e disponibilidade de hardware. Manter um sistema redundante para
aplicativos de função crítica exige grande quantidade de máquinas extras, gerando um
grande custo operacional e utilização ineficiente de hardware. (GOLDEN, 2008)
A redundância pode ser classificada de acordo com a quantidade de
equipamentos ou sistemas que estão prontos para assumir a função do equipamento
no momento em que ele falhe. O requisito de redundância pode assumir os seguintes
valores:
a. “N” para uma infraestrutura sem redundância;
b. “N+1” para uma infraestrutura com redundância em um dos equipamentos ou
sistemas;
c. “N+2” para uma infraestrutura com duas redundâncias;
d. “2N” para uma infraestrutura de redundância completa, ou seja, para cada
equipamento ou sistema, existe outro adicional;
2.3.1. Procedimento de failover e failback
Segundo Kopper (2005) “Um sistema de alta disponibilidade não possui pontos
únicos de falha. Um ponto único de falha é um componente do sistema que após falhar
faz com que todo o sistema falhe.”.

19
Failover é o ato de executar a mudança de contexto em um sistema redundante
no qual um sistema ou serviço defeituoso é substituído por outro saudável a fim de
impedir a indisponibilidade ou reduzir seu impacto. Apesar de costumeiramente ocorrer
automaticamente em ambientes de alto desempenho, pode ser feito manualmente em
determinadas situações quando o esforço de implantação de um mecanismo
automatizado não se justifica ou quando as tecnologias empregadas não permitam
essa possibilidade.
Como cita Riggs e Krosing (2010) “Failover é o chaveamento forçado de um nó
mestre para um nó standby devido a ocorrência de falha do mestre. Então, nesse caso,
não há nenhuma ação a ser executada no mestre, presumindo que ele não esteja mais
lá.”.
Uma vez que o mestre seja substituído, é natural que o mesmo seja consertado
e posto novamente para assumir o papel de outrora, este procedimento é normalmente
chamado de failback e sua execução tende a reconfigurar o ambiente para o modo
como estava antes da execução do failover.
2.4. BALANCEAMENTO DE CARGA
É um mecanismo que objetiva a distribuição de porções equivalentes de trabalho
entre os nós de um cluster. Em sistemas distribuídos, cada tarefa é repassada a um nó
de acordo com parâmetros predefinidos que buscam manter cada nó com um nível
equivalente de trabalho. Um algoritmo simples e muito utilizado para escalonar
processos é o Round Robin:
Existem muitos algoritmos de escalonamento de CPU diferentes, dentre estes,
Round Robin (RR) é o mais antigo, o algoritmo de escalonamento mais simples
e mais amplamente utilizado. É adicionado para alternar entre os processos.
Uma pequena unidade de tempo é usada pelo Round Robin que é chamada de
quantum (TQ) ou porção de tempo (TS). O escalonador de CPU percorre a fila
alocando a CPU para cada processo um intervalo de tempo de até 1 TQ. Se
um novo processo surge, então é adicionado ao final da fila circular. O
escalonador de CPU escolhe o primeiro processo da fila, define um cronometro
para interromper o processo após um TQ e o despacha. Após TQ expirar, a
CPU retoma o processo e o adiciona ao final da fila circular. Se o processo
terminar antes do final do tempo atribuído, o próprio processo retoma a CPU
voluntariamente. (PANDA e BHOI, 2012)

20
2.5. SOFTWARE LIVRE
O nascimento do movimento do Software Livre remonta à década de 80 quando
Richard Stallman ainda trabalhava para o MIT2
, onde teve experiências negativas com
a empresa Xerox que se recusou a distribuir o código fonte do driver defeituoso de uma
impressora a laser. Tal acontecimento aliado à comercialização do Unix3
corroborou
para a criação do projeto GNU4
, um sistema operacional seguindo os padrões do Unix,
mas totalmente livre. Ocasionando consecutivamente a criação da Free Software
Foundation (FSF) que objetivava a criação de um mecanismo legal de garantia para
que os direitos de copiar, distribuir e modificar software fossem resguardados.
Este mecanismo legal foi alcançado com a criação da licença GPL5
, como cita
João Eriberto (2006), Richard Stallman definiu que o software livre deve proporcionar:
a. Liberdade de executar o software, para qualquer propósito;
b. Liberdade de estudar como o software funciona e adaptá-lo às suas
necessidades, sendo o acesso ao código-fonte um pré-requisito para este aspecto;
c. Liberdade de distribuir cópias de forma que você possa ajudar ao seu
próximo;
d. Liberdade de melhorar o software e liberar os seus aperfeiçoamentos, de
modo que toda a comunidade se beneficie. Novamente, aqui o acesso ao código-fonte
é um pré-requisito.
2.5.1. Sistema operacional GNU/Linux
Desenvolvido e idealizado por Linus Torvalds, o GNU/Linux é tido como o mais
bem sucedido projeto de software livre, alcançando estações de trabalho, servidores e
outros equipamentos de rede. Segundo Bely Silva (2012):
Baseado no Minix, idealizado por Andrews Tanenbaum, o Linux absorveu
algumas características UNIX, como a capacidade de multitarefa,
multiprocessamento, uso de encadeamentos no kernel (kernel threading),
preempção do kernel, suporte a aplicações multi-encadeadas (multithreaded
application support) e a sistema de arquivos baseado em VFS (Virtual File
System). (SILVA JÚNIOR, 2012)
Atualmente existe uma gama de distribuições GNU/Linux, tanto para propósito
2
Massachusetts Institute of Technology
3
UNIX - Unix é um sistema operacional, multitarefa e multiusuário originalmente criado por Ken
Thompson, Dennis Ritchie, Douglas McIlroy e Peter Weiner, que trabalhavam nos Laboratórios Bell da
AT&T.
4
Acrônimo recursivo GNU is Not Unix
5
Licença GPL – A Licença Pública Geral do GNU é frequentemente chamada abreviadamente de GNU
GPL e é utilizada pela maioria dos programas do GNU assim como muitos outros programas de software
livre que não são parte do Projeto GNU.

21
geral voltado para usuários domésticos como distribuições especificas para utilização
em ambientes de alto desempenho.
Como resultado de todo o empenho personificado por Richard Stallman, Linus
Torvalds e toda a comunidade da FSF, atualmente existem numerosas soluções de
código aberto para os mais distintos propósitos.
2.6. SISTEMAS DE INFORMAÇÃO GERENCIAL DA UFRN
Com a expansão da Universidade Federal do Rio Grande do Norte por todo o
estado, surgiu a necessidade de aperfeiçoar os sistemas internos de gestão. Até então,
não havia integração entre os sistemas utilizados para fins acadêmicos e
administrativos. A Superintendência de Informática vislumbrou a possibilidade de criar
um conjunto de aplicações que suprisse a necessidade da instituição. Resultando na
disponibilização da primeira versão do Sistema Integrado de Gestão de Atividades
Acadêmicas (SIGAA) em 2007, do Sistema Integrado de Patrimônio (SIPAC) e
finalmente o Sistema Integrado para Gestão de Recursos Humanos (SIGRH). (LINS,
2014)
Ao longo do tempo uma série de outros sistemas foi desenvolvida em torno
desses, configurando a organização de sistemas apresentada na Figura 2.
Figura 2 - Relacionamento dos sistemas SIG e suas funcionalidades.
Fonte: Wikisistemas (2013)

22
O relacionamento presente na Figura 2 resulta na formação de todo um
ecossistema em torno dos sistemas da universidade que estão interligados aos
serviços governamentais de integração tais como o Sistema Integrado de
Administração Financeira (SIAFI) e o Sistema Integrado de Administração de Recursos
Humanos (SIAPE). Como abordado nas próximas seções, todo esse ecossistema
necessita de um conjunto de servidores de aplicação e banco de dados para funcionar.
2.7. SERVIDORES DE APLICAÇÃO
A partir do desenvolvimento da Internet, acompanhamos uma mudança
crescente no modelo de execução das aplicações, sistemas que outrora eram
desenvolvidos e instalados localmente em áreas de trabalho, foram substituídos por
aplicações WEB disponíveis através de um navegador. Essa alteração retirou da
estação de trabalho parte da necessidade por recursos de hardware, reduzindo custos
relativos à atualização, pois neste novo modelo o processamento das aplicações está
concentrado no lado servidor. A Figura 3 representa a interação entre os usuários e a
aplicação WEB, essa estrutura apresenta ainda a presença de outra entidade, o
servidor de bancos de dados, que será abordado na próxima seção.
Figura 3 - Novo modelo com aplicação centralizada em um servidor WEB.
Resultante da criação do novo modelo, surgiu a necessidade de implementar
servidores responsáveis pelo papel de prover infraestrutura, serviços e ferramentas.

23
Atualmente existe uma gama de soluções e tecnologias, tais como o Apache,
WebSphere da IBM ou o JBoss baseado na plataforma Java Platform, Enterprise
Edition (JEE).
2.7.1. JBoss
O JBoss é um servidor de aplicação de código aberto baseado na plataforma
Java Platform, Enterprise Edition (JEE) que provê um ambiente completo para
execução de aplicações Java. Gerenciando recursos como conexões com bancos de
dados, autenticação e recursos de hardware, possibilitando que estes sejam abstraídos
pela aplicação. O JBoss faz com que o desenvolvimento tenha maior enfoque nas
necessidades de negócio.
O JBoss é escrito em Java e pode ser executado em qualquer plataforma que
seja compatível com a Java Virtual Machine (JVM), como resume Gleydson Lima:
Um código compilado para uma JVM não necessita passar por recompilações
para ser executado em outra plataforma. A compilação é feita apenas uma vez
e o código então pode ser executado em todas as plataformas. Essa
compilação é feita em um formato intermediário denominado bytecodes. Esses
bytecodes representam um código binário pré-compilado preparado para
interpretação. O binário é então interpretado para cada plataforma alvo através
da JVM. (LIMA, 2007)
2.7.2. Apache
O Web Apache é um servidor HTTP de código aberto que “desde abril de 1996
tornou-se o serviço HTTP mais popular do mundo” (Apache HTTP Server Project,
2014). Tendo como características sua capacidade de expansão por meio de módulos,
além da reconhecida estabilidade e segurança. Habitualmente é configurado para
provimento de páginas estáticas, no entanto, com a utilização de módulos pode servir
um ambiente completo de aplicação, sendo a combinação de PHP e MySQL sua
implementação mais reconhecida.
Para este projeto o Apache em conjunto com o mod_jk desempenha a função de
balanceamento de carga entre as instâncias do JBoss.
2.7.2.1. Balanceamento de carga com Apache + Mod_jk
O servidor Web Apache possibilita a configuração do balanceamento de carga
para servidores de aplicação baseados na plataforma JEE, como o JBoss e o Tomcat a
partir do módulo JK.

24
Este módulo executa o escalonamento das requisições utilizando o algoritmo
Weighted Round Robin, que diferentemente do algoritmo tradicional, executa a
distribuição ponderada de requisições de acordo com valores previamente definidos. O
parâmetro lbfactor armazena um número inteiro indicando a porção relativa de trabalho
que o nó irá tratar, este valor deve ser calculado de acordo com o potencial de trabalho
do servidor, permitindo que servidores de maior capacidade tenham peso maior na
distribuição. A Figura 4 almeja simular o comportamento do servidor de balanceamento
em relação aos servidores balanceados.
Figura 4 - Balanceamento de requisições executado pelo Apache e Mod_jk.
O gerenciamento das instâncias do JBoss é feito a partir do conector AJP6
,
executando periodicamente uma checagem da “saúde” das instâncias, que resulta na
remoção do balanceamento caso não esteja operando corretamente. O balanceamento
deste módulo é baseado em grupos de balanceamento e contextos. Por exemplo, na
URL https://sistemas.ufrn.br/sipac, o contexto /sipac será interpretado pelo mod_jk, de
modo a dirigir a requisição para alguma instância pertencente ao grupo de
balanceamento associado ao contexto.
Como todos os usuários acessam os sistemas a partir do servidor de
balanceamento, as configurações padrão do Apache podem não ser suficientes mesmo
em um ambiente de pequeno porte. Visando a aumentar a capacidade de conexões
com os sistemas, configurou-se então o módulo prefork. O Apache prefork opera com
um grupo inicial de processos que ao receber um número maior de requisições, cria
6
Apache JServ Protocol: Protocolo para comunicação de um servidor WEB através de um servidor de
aplicação.

25
novos processos para trata-los. Deste modo o número de processos do Apache cresce
e decresce de acordo com a carga de trabalho. (SHOAIB, 2008)
2.8. SERVIDORES DE BANCO DE DADOS
Um servidor de banco de dados é um servidor dedicado à tarefa de
armazenamento de informações de uma empresa ou sistema por meio de um Sistema
Gerenciador de Banco de Dados.
Segundo Abraham Silberschatz (2007), um Sistema Gerenciador de Banco de
Dados (SGBD) é formado por um conjunto de dados associados a um conjunto de
programas para acesso a esses dados. Seu principal objetivo é proporcionar um
ambiente tanto conveniente quanto eficiente para a recuperação e armazenamento das
informações do banco de dados.
O mercado dispõe de diversas soluções de SGBDs portadas para diferentes
propósitos e plataformas, como o Oracle Database e o MySQL recentemente adquirido
pela Oracle, SQL Server da Microsoft, além do MariaDB e PostgreSQL, ambos de
código aberto.
2.8.1. Sistema Gerenciador de Banco de Dados PostgreSQL
Segundo Riggs e Krosing (2010) o PostgreSQL é um sistema de banco de
dados objeto-relacional de código aberto, o que significa que não são necessárias
licenças para instalar, utilizar ou distribuir. O PostgreSQL é reconhecido como um dos
bancos de dados com maior capacidade de se manter disponível requerendo pouco
esforço para manutenção. No geral, representa uma solução de baixo custo que
agrega uma gama de recursos avançados que foram adicionados ao longo de mais de
20 anos de desenvolvimento e aprimoramento.
Dentre as funcionalidades desenvolvidas de maior interesse para esse projeto
está a capacidade nativa de replicação, presente desde a sua versão 8.0, recebendo
atualizações e novas funcionalidades desde então, de modo a alcançar na versão 9.0
reconhecimento, sendo largamente adotada por diversas empresas, demonstrando
estabilidade, simplicidade e robustez. (RIGGS e KROSING, 2010)
2.8.1.1. Replicação nativa do PostgreSQL
O mecanismo de replicação do PostgreSQL possui dois modos de operação que
funcionam baseados no compartilhamento de arquivos Write Ahead Log (WAL). Para

26
Gregory Smith os WAL consistem em uma série de arquivos de 16 megabytes escritos
no subdiretório pg_xlog do PostgreSQL com o intuito de manter a integridade do banco.
Cada alteração no banco é gravada primeiramente em arquivos WAL. Quando a
transação é efetuada, o comportamento padrão é forçar a gravação do arquivo WAL no
disco. Caso o PostgreSQL falhe, os arquivos WAL serão lidos para retornar o banco ao
momento anterior à última transação confirmada. (SMITH, 2010)
Quando a replicação está habilitada, os arquivos WAL do próprio master são
enviados para o slave que irá utilizá-los para manter-se atualizado. A Figura 5
representa o cenário descrito.
Figura 5 - Replicação nativa do PostgreSQL baseada na transferência de arquivos
WAL.
O primeiro modo de operação caracteriza-se da simples transferência dos
transaction logs (WAL) criados no mestre para o escravo, que em seguida irá lê-los, de
modo que as alterações executadas no mestre sejam replicadas para o escravo, por
isso, este método é geralmente chamado de File-based log-shiping replication
(replicação baseada na transferência de arquivos de log), que apesar de ser
assíncrono, apresenta um período relativamente pequeno de sincronização e pouco
overhead, uma vez que pouco esforço é necessário para trafegar os arquivos pela
rede. No entanto, a replicação deste modo pode apresentar desempenho insatisfatório
em determinados ambientes que necessitem de maior integridade de dados entre os
nós.
O segundo modo de replicação, Streaming Log Replication está estável desde a
versão 9.0. Possibilita que o servidor escravo seja atualizado mais rapidamente, de
modo que geralmente a diferença entre mestre e escravo seja de apenas alguns

27
milissegundos. Este modelo de replicação, apesar de também ser baseado na
transferência de arquivos WAL, é caracterizado pela presença de dois processos, o
walsender no mestre e o walreceiver no escravo. Juntos possibilitam que fragmentos
de arquivos WAL que ainda não completaram 16 megabytes sejam trafegados através
de um canal TCP. Essa abordagem objetivou diluir a situação problemática em que o
escravo permanece esperando alterações que foram executadas no mestre, mas não
puderam ser replicadas pelo fato de o arquivo WAL não ter atingido o tamanho
completo. (BOSZORMENYI e SCHONIG, 2013)
Faz-se necessário frisar o fato de que a replicação do PostgreSQL não
obrigatoriamente precisa operar com apenas um dos dois mecanismos supracitados,
podendo inclusive utilizar os dois simultaneamente, como adotado neste trabalho.
Nesse cenário o mecanismo de transferência de arquivos entrará em operação
quando o servidor slave estiver significativamente desatualizado em relação ao master.
Por exemplo, quando houver permanecido indisponível por um período suficiente para
geração de novos arquivos WAL. Em contra partida a replicação por streaming entrará
em ação na condição natural de constantes alterações no master, resultando em um
menor atraso para sincronização dos dados.
Relacionado ao comportamento de cada PostgreSQL, o nó mestre precisará
armazenar uma quantidade maior de informações sobre cada transação executada. O
parâmetro wal_level configurado no arquivo postgresql.conf dita qual será o nível de
informação armazenada nos transaction logs e pode assumir três configurações:
minimal, archive ou hot_standby.
Por padrão configurado como minimal, armazena somente informações
necessárias para recuperação do serviço em caso de crash ou desligamento forçado. A
segunda opção archive possibilita a replicação de dados. Para tal, além dos dados
informados anteriormente, adicionará a capacidade de replicação em outros servidores.
A terceira opção de configuração, hot_standby, permite que os dados replicados nos
nós escravos sejam disponibilizados para acesso somente leitura.
Na estrutura exposta, o nó escravo permanece no estado de recuperação
contínua, replicando as transações executadas no mestre. Consequentemente,
qualquer operação que envolva escrita será executada no mestre, resguardando aos
nós escravos somente a capacidade de leitura de dados.

28
2.9. FERRAMENTAS PARA CONFIGURAÇÃO DE ALTA DISPONIBILIDADE
2.9.1. Heartbeat
É um projeto de código aberto voltado para implementação de alta
disponibilidade de serviços, criando uma infraestrutura em cluster que possibilita a
configuração de redundância de componentes.
A configuração do Heartbeat prevê a presença de pelo menos dois nós, o
primeiro ou mestre é o natural responsável pelos recursos, o segundo atua como um
servidor de backup que permanece monitorando o status do mestre a partir de
heartbeats. Heartbeats são pacotes de 150 bytes de comprimento que indicam quem
está responsável pelo recurso e controla quem deve assumir caso algum problema
aconteça. A troca de mensagens de controle permite que os procedimentos de failover
e failback sejam possíveis. (KOPPER, 2005)
Para que o failover seja executado, é necessário que o servidor slave assuma o
endereço IP do master. Isso ocorre a partir da criação de um alias na interface do
servidor de backup, que na maioria das distribuições GNU/Linux resulta na criação de
uma interface virtual eth0:0. Este procedimento é chamado pelo Heartbeat de IP
Address Takeover (IPAT). Após a transferência de endereço IP, alguns segundos são
necessários até que o roteador ou servidores conectados a ele atualizem sua tabela
ARP com o novo endereço MAC para o IP. Até que este processo ocorra, os serviços
permanecem indisponíveis.
2.9.2. Csync2
Trata-se de uma ferramenta de replicação assíncrona de arquivos que não exige
a criação de uma conexão persistente entre os nós. Segundo Wolf (2013), “O método
de replicação assíncrona é ideal para arquivos que não são alterados com tanta
frequência, além disso, os algoritmos utilizados são muito mais simples do que
utilizados pelo método síncrono, logo, menos susceptíveis a erros.”.
O funcionamento do csync2 é relativamente parecido com o do rsync. No
entanto, apresenta maior capacidade de configuração, assumindo o modelo de cluster
para diretórios ou arquivos entre diversos nós. Possibilita a execução de backups e
versionamento de arquivos alterados. Mas tal como o rsync, é um programa em nível
de usuário que não depende de um daemon para operar, bastando executá-lo para

29
iniciar a sincronização. Desse modo, para que ocorra continuamente, deve-se adicionar
seu comando de execução no crontab7
do Linux.
2.10. FERRAMENTAS PARA HOMOLOGAÇÃO DE SISTEMAS
A homologação de sistemas é o procedimento que objetiva assegurar que as
aplicações atinjam critérios de qualidade e funcionamento necessários para atender as
necessidades do negócio. Para que a homologação se torne válida são necessários
testes para avaliar a aplicação e o ambiente quanto a requisitos mínimos de
funcionamento e segurança.
2.10.1. Apache JMeter
O JMeter é um software de código aberto desenvolvido pela Apache Software
Foundation para realização de testes de estresse em aplicações WEB. Lançado em
1998, o JMeter se tornou uma ferramenta madura, robusta e confiável que permite a
simulação de vários usuários simultâneos. Um único computador equipado com um
processador de 2,2 GHz e 8 GB de memória RAM é na maioria das vezes capaz de
simular de 250 a 450 usuários simultâneos, auxiliando a delimitação de gargalos,
evidenciando as rotinas de menor desempenho da aplicação. (ERINLE, 2013)
O JMeter suporta diferentes testes de performance incluindo HTTP, HTTPS,
LDAP, mail, database. Além disso, a ferramenta facilita a criação de roteiros de testes
com a criação de um proxy8
que em conjunto com um gravador possibilita a gravação
automática das páginas e objetos requisitados à aplicação, facilitando o processo de
automatização de testes.
2.10.2. OpenVAS
O OpenVAS ou Sistema Aberto de Avaliação de Vulnerabilidades é um
framework utilizado para buscar vulnerabilidades de um alvo, seu projeto é derivado do
Nessus9
que oferta um conjunto de atualizações completamente gratuito.
A ferramenta executa uma varredura no alvo buscando uma numerosa
quantidade de vulnerabilidades, possibilitando a configuração de testes personalizados
para diferentes sistemas operacionais e gerando relatórios ao final da varredura. Ao
7
Agendador de tarefas presente em distribuições GNU/Linux.
8
Servidor intermediário que atende requisições de um cliente repassando seus dados ao serviço
destinado.
9
Ferramenta profissional para diagnóstico de rede em que existem possíveis vulnerabilidades de
segurança.

30
final dos testes cada vulnerabilidade detectada é exibida e classificada a partir de um
Common Vulnerability Scoring System (CVSS). O CVSS é um método padrão e
universal de classificar vulnerabilidades de TI de 0 a 10. Números maiores determinam
vulnerabilidades mais críticas. (PRITCHETT e SMET, 2012)
Adicionalmente, cada vulnerabilidade encontrada é acompanhada de uma
explanação simplificada sobre o problema e lista uma série de endereços que vão
desde a explicação da vulnerabilidade até a resolução da mesma.
2.10.3. Zabbix
O Zabbix é uma ferramenta aberta de monitoramento que suporta um grande
conjunto de mecanismos de monitoramento, tais como SNMP, IPMI, JMX10
, possuindo
um agente que pode ser instalado em diferentes sistemas operacionais, possibilitando
nativamente o monitoramento de diversos objetos por meio de chaves, além de
possibilitar a execução de scripts.
Em citação Rihards Olups (2010) descreve: “O Zabbix oferece muitas maneiras
de monitorar diferentes aspectos da infraestrutura de TI e, na verdade, quase tudo que
se poderia querer ligar a ele. Pode ser caracterizado como um sistema de
monitoramento parcialmente distribuído com gerenciamento centralizado.”
O papel do Zabbix neste trabalho é monitorar os servidores do ambiente
utilizando seu próprio agente e as instâncias do JBoss a partir da interface JMX. O
monitoramento dos recursos do ambiente é parte fundamental para análise dos testes
de homologação. A Figura 6 apresenta a listagem dos hosts monitorados pelo Zabbix.
10
O Java Management Extensions fornece ferramentas para gerenciamento de monitoramento de
aplicações, objetos de sistema, dispositivos e redes orientadas a serviço.

31
Figura 6 - Listagem de hosts do ambiente virtual monitorados pelo Zabbix.
Fonte: Adaptado da ferramenta Zabbix (2014)

32
3. DESENVOLVIMENTO DO PROJETO
Para teste e homologação dos mecanismos de alta disponibilidade dos quais
trata este trabalho, propôs-se uma estrutura formada por dois grupos de três máquinas
virtuais, respectivamente, um servidor de banco de dados, um servidor de aplicação e
um servidor para o balanceamento de carga.
O intuito de formação desses dois grupos é manter a redundância de requisito
“2N”, de modo que para cada servidor do grupo principal exista outro pronto para
assumir sua função.
3.1. DESCRIÇÃO DO AMBIENTE
Cada par de servidores pode ser interpretado como uma camada distinta,
formando respectivamente, camada de balanceamento, camada de aplicação e
camada de banco de dados. A Quadro 1 lista os grupos e seus membros informando
seus papeis dentro do grupo.
Quadro 1 - Servidores e sua função no ambiente.
Servidor Grupo Função
habalancer1 Grupo
primário
Servidor primário de balanceamento
hasistemas1 Servidor de aplicação
habdsistemas1 Servidor de banco de dados mestre
habalancer2 Grupo
secundário
Servidor secundário de balanceamento
hasistemas2 Servidor de aplicação
habdsistemas2 Servidor de banco de dados escravo
Os servidores descritos receberam recursos de hardware compatíveis com a
função que irão desempenhar, tal como no ambiente de produção da universidade,
ressaltando-se a maior necessidade de memória e processamento nos servidores de
aplicação, além de disco e memória para os servidores de banco de dados. Essa
configuração encontra-se exposta na Quadro 2.

33
Quadro 2 - Configuração dos servidores do ambiente proposto
Servidor Endereço IP CPU Memória Disco
habalancer1 10.3.226.30 2 x Intel Xeon
2.67GHz
2 GB 20 GB a
7.000 RPMhabalancer2 10.3.226.31
hasistemas1 10.3.226.32 4 x Intel Xeon
2.67GHz
8 GB 20 GB a
7.000 RPMhasistemas2 10.3.226.33
habdsistemas1 10.3.226.34 4 x Intel Xeon
2.67GHz
4 GB 320 GB a
7.000 RPMhabdsistemas2 10.3.226.35
A Figura 7 retrata a topologia de configuração das máquinas virtuais do
ambiente. A divisão em camadas, além de seguir a lógica de operação do ambiente,
objetiva à modularização, facilitando procedimentos de atualização e manutenção.
Adicionalmente, a utilização de máquinas virtuais possibilita o maior controle sobre a
utilização dos recursos, tornando o ambiente mais escalável com a adição de mais
recursos de hardware de acordo com a demanda requisitada.
Figura 7 - Topologia do ambiente virtual proposto utilizando cluster na camada de
balanceamento e replicação entre os servidores de banco de dados.

34
Neste cenário as requisições dos clientes são enviadas para o endereço do
cluster que está inicialmente associado ao servidor habalancer1. No entanto, se por
algum motivo este fique indisponível, o failover executado pelo Heartbeat fará com que
as requisições sejam tratadas por habalancer2. Independentemente do servidor
responsável pelo balanceamento, este será feito para as instâncias de aplicação
disponíveis em hasistemas1 e hasistemas2. Finalmente, as instâncias de aplicação
acessam os bancos a partir do servidor habdsistemas1, restando o habdsistemas2
para replicação dos bancos e eventual failover manual, caso o servidor primário de
banco apresente problema.
3.2. FERRAMENTAS
Todos os servidores do ambiente foram configurados com o sistema operacional
Ubuntu Server 12.04.3 LTS, essa titulação é data para versões do Ubuntu que
garantem o suporte e acesso aos repositórios por cinco anos a partir da data de
lançamento, é formada como sendo a versão mais estável e segura da distribuição e
por isso só é lançada a cada dois anos. Sua utilização possibilita a formação de um
ambiente estável e seguro. Além do sistema operacional, os servidores foram
configurados com os softwares necessários para desempenho de seus papeis, segue a
lista de softwares e suas versões:
a. Apache 2.2.22
b. Módulo Apache JK 1.2.32
c. Heartbeat 3.0.5
d. Csync2 1.34
e. PostgreSQL 9.3.0
f. Jboss 4.2.2
3.3. OPERAÇÃO
A operação do ambiente está de acordo com sua disposição em camadas. No
momento em que um usuário acessa algum dos sistemas, o servidor de
balanceamento irá repassar as requisições para alguma das instâncias de aplicação
disponíveis. Esta operação é feita de acordo com o algoritmo e grupo de
balanceamento ao qual o sistema requisitado pertence. A instância por sua vez, acessa
o banco de dados para ler e adicionar informações de acordo com as necessidades do
usuário e do sistema.

35
No entanto, como descrito anteriormente neste trabalho, este modelo está
susceptível ao risco de indisponibilidade. Retomando as duas situações hipotéticas
apresentadas na seção 1.2, a primeira de falha no servidor de balanceamento e a
segunda de falha no servidor de banco de dados, toda a infraestrutura montada estaria
comprometida.
Visando coibir esse tipo de incidente limitando seu impacto e buscando a
capacidade de tolerância a falhas, prepararam-se estratégias e mecanismos de
recuperação permitindo que a infraestrutura torne-se novamente operante em um curto
período de tempo.
As seções a seguir descrevem o funcionamento do ambiente e dos mecanismos
de alta disponibilidade implantados.
3.3.1. Servidores de banco de dados
A camada de banco de dados apresenta um modo de operação distinto em
relação ao exposto sobre o funcionamento do ambiente no campus universitário.
Apesar de também ser composto por dois servidores, no caso habdsistemas1 e
habdsistemas2, preferiu-se adotar uma estrutura focada na redundância dos dados, no
lugar da escalabilidade por entender que o primeiro apresenta um teor mais crítico para
o ambiente, uma vez que a falta de recursos de hardware não caracteriza um problema
em médio prazo.
No lugar de separar os bancos nos dois servidores de acordo com seu escopo
(acadêmico ou administrativo), adotou-se a medida de reunir todos os bancos utilizados
pelos sistemas em uma única máquina, habdsistemas1 e replicar seus dados
continuamente para habdsistemas2 utilizando os mecanismos de replicação nativa do
PostgreSQL. Essa estrutura é caracterizada pelo formato mestre – escravo, que resulta
da configuração de habdsistemas1 como nó mestre e habdsistemas2 como nó escravo.
3.3.1.1. Procedimento de failover
Ter todos os bancos replicados em um servidor compatível em termos de
sistema operacional e hardware possibilita a redundância completa do servidor de
banco de dados. Deste modo, caso o servidor mestre fique indisponível, o servidor
escravo pode ser promovido ao estado de mestre, passando a aceitar escrita e
assumindo o lugar do mestre perante os sistemas.

36
Devido à complexidade envolvida na mudança de contexto durante a promoção
de um nó PostgreSQL slave em master o procedimento de failover é
caracteristicamente manual, no entanto, pode ser auxiliado por meio de shellscripts,
que na prática irão retirar o servidor escravo do modo de recuperação contínua.
Um script simples que executa o procedimento de failover foi adicionado ao
APÊNDICE A. Basicamente, ele precisa executar as seguintes ações:
a. Assumir o endereço IP do master, no caso, 10.3.226.32;
b. Retirar serviço PostgreSQL do modo de recuperação continua, permitindo que
o mesmo seja capaz de receber e tratar qualquer operação;
Notavelmente, para que o procedimento seja bem sucedido deve-se garantir que
o servidor master esteja realmente indisponível ou que não esteja utilizando o mesmo
endereço IP de antes, uma vez que isso poderia ocasionar conflitos na camada de
enlace da pilha TCP/IP. Se duas interfaces de rede possuírem o mesmo endereço IP,
não se pode garantir para qual delas o switch irá chavear os quadros vindos dos
servidores de aplicação, resultando na lentidão da comunicação ou mesmo na
indisponibilidade total do serviço.
3.3.1.2. Procedimento de failback
Sobre o mecanismo de failback, o PostgreSQL apresenta uma situação crítica,
uma vez que não existe de fato uma ferramenta de failback. Como nessa citação
atribuída a Riggs e Krosing (2010) “Uma vez que o standby tornou-se mestre ele não
pode voltar a ser standby novamente. Assim com a replicação de log, não há uma
operação de failback explícita. Esta é uma situação surpreendente para muitas
pessoas, apesar de ser rápida de contornar.”.
Nesse sentido, para contornar o problema e tornar habdsistemas1 mestre
novamente, deve-se executar o mesmo procedimento necessário para iniciar a
replicação dos dados. O que na prática, significa desligar o serviço no nó
habdsistemas2, sincronizar todos os seus dados para o nó mestre com o auxílio de
alguma ferramenta de sincronização de arquivos, como o próprio rsync e finalmente
reiniciá-los. Este comportamento resulta na indisponibilidade do serviço, e se faz
necessária para que nenhum dado seja perdido. Por esse motivo, é importante que
seja planejada com cautela e executada em um horário de baixa utilização.

37
Novamente, um shellscript11
pode ser utilizado para auxiliar o procedimento. Um
exemplo de script que execute essa função foi colocado no APÊNDICE B.
Basicamente, o procedimento de failback é composto pelos seguintes passos:
a. Devolver o endereço IP do master, no caso, 10.3.226.32;
b. Parar serviço PostgreSQL;
c. Reconfigurar arquivos para recuperação contínua;
d. Sincronizar bases de dados com habdsistemas1;
3.3.2. Servidores de aplicação
No que toca à camada de aplicação, não foram executadas alterações
significativas em relação ao atual ambiente da UFRN. No entanto, faz-se necessário
explicar seu funcionamento almejando o entendimento completo da operação do
cenário. A camada de aplicação assim como as demais, está representada por dois
servidores: hasistemas1 e hasistemas2, que possuem cada um, duas instâncias do
JBoss, uma operando com a porta 8080 HTTP e porta 8009 AJP e outra com as portas
8081 HTTP e 18009 AJP, ficando a primeira com os sistemas acadêmicos e a segunda
com os sistemas administrativos. De modo mais amplo, essa abordagem facilita a
redundância dos sistemas garantindo que cada servidor possa responder por todos os
sistemas.
Consequentemente, a divisão em dois grupos para sistemas administrativos e
acadêmicos, possibilita a manutenção eficiente dos sistemas. Por estarem separados,
pode-se, por exemplo, atualizar um dos grupos, sem que isso prejudique o outro e vice
versa. Para descrição dos grupos de balanceamento e seus respectivos membros,
consulte a Quadro 3.
Quadro 3 - Configurações de instâncias do JBoss
Servidor Instância Porta HTTP Porta AJP Grupo de
balanceamento
hasistemas1 hasistemas1i1 8080 8009 academicolb
hasistemas1i2 8081 18009 administrativolb
hasistemas2 hasistemas2i1 8080 8009 academicolb
hasistemas2i2 8081 18009 administrativolb
11
É uma linguagem de script usada em vários sistemas operacionais. É geralmente associada aos
interpretadores de distribuições GNU/Linux como o bash.

38
Além das configurações descritas, buscando a utilização eficiente de memória
pelas JVMs, foi feita a configuração dos parâmetros que reservam o tamanho de
memória Heap e PermGen. A primeira armazena os objetos instanciados, a segunda
armazena classes e metadados. Levando-se em consideração que cada servidor de
aplicação possui 8 GB de memória RAM e seu propósito é exclusivamente manter duas
instâncias do JBoss em funcionamento, foram reservados 3000 MB para a memória
heap e 400 MB para memória permgen de cada instância, resguardando
aproximadamente 1200 MB para o sistema operacional. Essa configuração permite que
um número maior de usuários possa ser atendido por uma única instância.
3.3.3. Servidores de balanceamento
O balanceamento de carga realizado pelo Apache com módulo JK aumenta a
escalabilidade de aplicações Java, pois possibilita a criação de um ambiente em cluster
contendo diversas instâncias de aplicação, consequentemente, aumentando a
redundância, escalabilidade e disponibilidade do sistema.
3.3.3.1. Alta disponibilidade com Heartbeat
O cluster configurado dispõe de dois nós, habalancer1 e habalancer2, atuando
respectivamente como servidor de balanceamento primário e servidor de backup ou
balanceamento secundário. O primeiro está configurado com o endereço IP
10.3.226.30 e o segundo 10.3.226.31, ambas configuradas na interface eth0 de cada
host, que é utilizada tanto para comunicação habitual dos servidores como para
comunicação do Heartbeat.
Essa configuração permite a execução dos procedimentos de failover e failback
automáticos. Para tal, é criada uma interface virtual eth0:0 com o endereço 10.3.226.59
no nó responsável pelo serviço. Inicialmente essa interface estará presente somente no
nó mestre, mas caso esse venha a falhar, será feita a promoção do servidor escravo,
ficando este responsável pelo endereço IP do cluster e do Apache. Esse
comportamento garante que o serviço mantenha-se disponível o máximo possível.
Nesse modelo de configuração, o failback é executado instantaneamente no momento
em que o nó mestre é detectado como ativo.
A operação do cluster Heartbeat presume que os nós estejam sincronizados,
caso contrário os serviços poderão não funcionar adequadamente, o que nesse
cenário, implica no funcionamento do balanceamento. O referido ambiente apresenta

39
pouca necessidade de sincronização, afinal só se faz necessário manter sincronizados
os arquivos de configuração do Apache e o diretório /var/www, que são modificados
esporadicamente.
Para suprir as necessidades do cenário quanto à sincronização de dados entre
os nós utilizou-se a solução de sincronização assíncrona do csync2 que provê a
capacidade de sincronização bidirecional entre servidores. O servidor habalancer1 foi
configurado para executar o csync2 e sincronizar seus diretórios /etc/apache e
/var/www a cada dois minutos.
3.3.3.2. Tratamento de sessões
Frente aos procedimentos descritos, faz-se importante discutir a respeito do
gerenciamento das sessões dos usuários. O que acontece com elas durante tais
procedimentos e qual a experiência do usuário?
O balanceamento do Apache com o mod_jk não armazena o estado da conexão
do usuário. O gerenciamento de sessão é feito a partir de cookies. No momento em
que um usuário tenta acessar algum dos sistemas, o apache verifica no grupo de
balanceamento uma instância disponível, de acordo com seu algoritmo de
escalonamento. No momento da criação da conexão entre o navegador do usuário e a
instância do sistema um cookie é gerado.
Basicamente, o cookie contém um identificador informando a qual instância
aquela conexão pertence, desse modo, o mecanismo de balanceamento sabe a qual
instância entregar a requisição do usuário sem precisar armazenar dados localmente.
Esse mecanismo possibilita que o balanceador seja trocado sem que os usuários
percam a referência de suas sessões. É importante frisar, no entanto, que essas
conexões ficaram momentaneamente inoperantes, durante o failover completo do
balanceador.
Outra questão importante para esta discussão é que os sistemas não permitem
o compartilhamento de sessão entre as instâncias e por isso cada usuário fica preso à
instância a qual se conectou inicialmente. Para que o balanceador não tente fazer o
balanceamento de uma sessão para outra instância, é necessário configurar o mod_jk
para não fazê-lo, e isso implica na configuração do parâmetro sticky_session para
‘True’.
Esse comportamento resulta em certas implicações para o funcionamento do
ambiente, inicialmente se resolve o problema de sessão expirada gerada pelo

40
balanceamento indevido de uma sessão. Mas como consequência, caso uma instância
fique indisponível, todo o conjunto de usuários que a estiver utilizando perderá sua
conexão com o sistema e também seu trabalho que ainda não foi salvo, uma vez que
suas sessões estavam presentes somente nesta. Novamente, vale discernir nesse
ponto que as outras instâncias continuariam operando normalmente, mas com o tempo
receberiam uma carga maior de trabalho, uma vez que um dos nós ficou indisponível e
foi retirado do balanceamento.
3.4. RESULTADOS
Como consequência do esforço desempenhado na otimização do ambiente no
que tange aos mecanismos de alta disponibilidade, acompanha-se um aumento
significativo na capacidade de recuperação frente a incidentes. Aumentando a
segurança e reduzindo o downtime12
dos sistemas, especialmente quanto à
implementação de redundância nos servidores de bancos de dados, que como
explanado anteriormente, representa um dos dois pontos críticos de falha.
Além disso, o mecanismo de balanceamento de carga permite a melhor
distribuição de trabalho entre os nós do cluster, caso algum desses nós venha a falhar,
será automaticamente retirado do balanceamento.
Além das características de alta disponibilidade adquiridas em nível de serviço,
evidenciam-se as vantagens de se ter o ambiente montado em máquinas virtuais, que
possibilitam a resposta facilitada a uma serie de problemas comuns à utilização de
máquinas físicas, como o provisionamento de recursos de hardware e rede sob
demanda, adição de novas máquinas ao cluster, realização de backup e
consequentemente, otimização de custos relacionados à alimentação, climatização,
rede e espaço.
3.4.1. Homologação de mecanismos de alta disponibilidade
Nesta seção serão apresentados os resultados alcançados com a
implementação dos mecanismos de alta disponibilidade adotados. Com o objetivo de
atestar a capacidade de recuperação após a ocorrência de falha, foram realizadas
simulações de falha em cada camada do ambiente.
12
Indisponibilidade de sistemas

41
Para acompanhamento da disponibilidade dos sistemas utilizou-se a ferramenta
JMeter, desenvolvida para testes de desempenho em sistemas da plataforma Java.
3.4.1.1. Primeiro experimento – Falha do servidor primário de balanceamento
Para simulação de falha, removeu-se o servidor habalancer1 da rede, resultando
na ativação da solução Heartbeat no servidor habalancer2, que prontamente classificou
o referido servidor como inoperante e assumiu seu papel, resultando em um curto
período de downtime.
A Figura 8 apresentada abaixo lista as requisições feitas à página do sistema
durante a operação de failover, pode-se atestar que o servidor de balanceamento
secundário levou aproximadamente 35 segundos para assumir o balanceamento. Este
teste foi repetido mais duas vezes, gerando períodos de indisponibilidade de
aproximadamente 35 e 40 segundos, respectivamente.
Figura 8 - Teste de acesso ao SIGAA durante procedimento de failover do balanceador.
Fonte: Adaptado a partir da ferramenta JMeter (2014)
As amostras de oito a catorze retornaram falha durante o período em que o
balanceador secundário classificou o balanceador primário como indisponível e
assumiu seu papel.
3.4.1.2. Segundo experimento – Retorno do servidor primário de balanceamento
Para este experimento, adicionou-se novamente o servidor habalancer1 na rede,
gerando a troca de heartbeats que culminou na execução do procedimento de failback,
reconfigurando o ambiente ao modo como estava anteriormente à falha. Percebe-se na
Figura 9 um período de indisponibilidade de aproximadamente 45 segundos.

42
Novamente, o experimento foi executado mais duas vezes, ambos gerando downtimes
de aproximadamente 50 segundos.
Figura 9 - Teste de acesso ao SIGAA durante procedimento de failback do
balanceador.
3.4.1.3. Terceiro experimento – Tolerância à falha do servidor de aplicação
O terceiro experimento consiste na desativação das duas instâncias do JBoss do
servidor hasistemas1, esperando que o mod_jk identifique o problema e retire as duas
instâncias do balanceamento, que, no entanto, deve manter todos os sistemas ativos,
uma vez que as instâncias de hasistemas2 ainda estarão ativas. As figuras 07 e 08
foram retiradas da página jkstatus de monitoramento do mod_jk, que possibilita o
acompanhamento do estado das instâncias e das configurações do balanceamento.
A Figura 10 apresenta as instâncias participantes do grupo de balanceamento
responsável pelo SIGAA. Pode-se constatar que foi detectado o problema com
instância habdsistemas1i1, habdsistemas2i1, no entanto, permanece ativa.
Figura 10 - Membros do grupo de balanceamento academicolb no jkstatus.
Fonte: Adaptado a partir da página jkstatus (2014)

43
O comportamento equivalente pode ser constatado na Figura 11 que apresenta
as informações relativas ao grupo de balanceamento dos sistemas administrativos.
Figura 11 - Membros do grupo de balanceamento administrativolb no jkstatus.
Fonte: Adaptado a partir da página jkstatus (2014)
3.4.1.4. Quarto experimento – Tolerância à falha do servidor de banco de dados
Para este experimento, desligou-se o servidor habdsistemas1 e em seguida deu-
se início ao processo de promoção do PostgreSQL em habdsistemas2, fazendo-o
entrar no modo read/write. Simultaneamente foi adicionada a interface eth0:0 com o
endereço 10.3.226.32 anteriormente configurado para habdsistemas1. Passados
alguns segundos, habdsistemas2 passou a responder as requisições dos sistemas,
ocasionando o retorno dos mesmos. Na Figura 12, observa-se que os sistemas ficaram
off-line por cerca de 40 segundos após o início dos procedimentos de recuperação,
voltando ao serviço normal quando finalizado o procedimento de failover.
O procedimento de failover do servidor de banco de dados por ser
caracteristicamente manual pode resultar em longos períodos de indisponibilidade.
Ainda no cenário controlado exposto, foram realizados dois testes adicionais,
resultando em tempos de aproximadamente 45 e 50 segundos.
Figura 12 - Teste de acesso ao SIGAA durante o procedimento de failover do servidor
de banco de dados.

44
3.4.2. Homologação do ambiente com teste de carga
Nesta seção serão apresentados os resultados alcançados com o teste de carga
que objetiva medir a capacidade total dos sistemas para o ambiente proposto.
Para o teste de carga foi produzido um roteiro de requisições a diferentes
páginas dos sistemas SIGAA e SIPAC. Buscando simular o comportamento de um
usuário que naturalmente ao entrar no sistema, solicita páginas e leva certo tempo para
leitura de seu conteúdo, retornando para o menu inicial em seguida e que por fim,
fecha sua sessão após algumas dessas interações. Nesse sentido, foram adicionados
períodos de 8 segundos entre as páginas requisitadas, resultando em uma média de 60
segundos para o procedimento completo em ambos os sistemas.
Este roteiro foi inserido na ferramenta JMeter para automatizar o processo,
possibilitando a criação de um grupo configurável de usuários. Bem como o
acompanhamento do teste. Adicionalmente, para acompanhamento dos recursos dos
servidores do ambiente foi utilizada a solução Zabbix para monitorar os recursos mais
importantes à análise do ambiente.
Diversos testes de carga foram executados com valores inicialmente baixos de
usuários, sendo incrementado em 20 a cada novo teste. Delimitando um número de
usuários que acessando simultaneamente o SIGAA e o SIPAC, apresentassem
experiência satisfatória. Os valores alcançados foram respectivamente 80 usuários
para o SIGAA e 120 usuários para o SIPAC. Valores suficientes para levar ao limite a
utilização dos recursos do ambiente. Nesse sentido, valores pouco maiores
demonstraram resultados negativos, ocasionando a negação de serviço.
A Figura 13 apresenta a tela da ferramenta configurada para os devidos testes
ao SIPAC, onde no espaço lateral esquerdo encontram-se os objetos necessários para
realização do teste e o controlador de gravação, que contém o roteiro de cada página a
ser requisitada. Na parte central da ferramenta, observa-se a configuração dos
parâmetros de criação do grupo de usuários. Neste teste, configurou-se para 120 o
número de usuários virtuais e para 480 segundos o tempo de inicialização. Em
conjunto, esses parâmetros ditam o intervalo reservado entre a criação de um usuário e
outro de acordo com a fórmula:

45
Como resultado, um novo usuário virtual é criado a cada 4 segundos. Todo o ciclo se
repete por 12 vezes, mantendo o número total de usuários em atividade por tempo
suficiente para obtenção dos resultados.
Figura 13 - Tela do JMeter com roteiro para teste de carga no SIPAC.
Como informado anteriormente, o Zabbix executou o acompanhamento do
ambiente durante todo o teste de carga, gerando vários gráficos sobre a utilização dos
recursos e gravando o impacto causado. A análise dos gráficos permite a definição de
possíveis gargalos na estrutura.
Para o servidor de banco de dados habdsistemas1 foi solicitado um grande
conjunto de operações que resultou no alto consumo de memória e processamento,
como pode ser constatado nos gráficos presentes na Figura 14 e Figura 15 adaptadas
do Zabbix. É notável a mudança de padrão dos dados em ambos os gráficos.
Adicionalmente, percebeu-se lentidão no acesso à máquina, e foi constatado que a
mesma estava fazendo uso significativo da memória swap, uma vez que a memória
RAM disponível não foi suficiente para a demanda exigida pelo PostgreSQL.

46
Figura 14 - Gráfico do Load Average da CPU para o servidor habdsistemas1.
Fonte: Adaptado a partir da ferramenta Zabbix (2014)
Como listado junto ao nome do gráfico, o período apresentado é de uma hora. O
teste, no entanto, foi executado por cerca de vinte e cinco minutos. O motivo para isso
é que o Zabbix utiliza o valor de uma hora como sendo o período mínimo para exibição
dos dados de gráficos.
Figura 15 - Gráfico da memória RAM para o servidor habdsistemas1.
Para o servidor de aplicação hasistemas1 acompanhou-se um grande
crescimento da utilização do processador e da memória heap das JVMs vinculadas aos
processos do JBoss. O gráfico para utilização de CPU foi adicionado à Figura 16, e o
gráfico de utilização de memória heap para a instância hasistemas1i1 que pode ser
consultado na Figura 17 - Gráfico da memória heap para a instância hasistemas1i2.. O

47
mesmo comportamento foi constatado para o servidor hasistemas2 e suas instâncias.
No entanto, seus gráficos não foram anexados a este trabalho para não torná-lo
desnecessariamente extenso.
Figura 16 - Gráfico do Load Average da CPU para o servidor hasistemas1.
Figura 17 - Gráfico da memória heap para a instância hasistemas1i2.
Finalmente, tal como esperado, habalancer1 pouco sofreu durante o teste de
carga, apresentado trafego de entrada de 30 Mbps, além de pequena acentuação do
processamento e memória. Este comportamento é esperado uma vez que o servidor de
balanceamento somente repassa as requisições aos nós do cluster. No entanto, pôde-
se acompanhar um crescimento expressivo no número de threads do Apache. Tal
comportamento foi novamente capturado pelo Zabbix e está expresso no gráfico da
Figura 18.

48
Figura 18 - Gráfico de utilização de threads do Apache para o servidor habalancer1.
Conclusivamente é seguro apontar, de acordo com as experiências realizadas,
bem como dos resultados apresentados, que a falta de memória é maior responsável
pela queda de desempenho do ambiente. Limitando que o mesmo seja capaz de servir
um número maior de usuários. Como dito anteriormente, o servidor de banco de dados
fez uso do swap, o que corroborou para o aumento da carga de processamento, o
tornando o principal fator limitante do teste. Analogamente, os servidores de aplicação
também obtiveram grandes taxas de utilização de memória, principalmente da memória
heap das instâncias do JBoss, ocasionando a execução das rotinas de garbage
collection da JVM e reduzindo o desempenho dos sistemas.
Ao fim dos testes de carga para o SIGAA e SIPAC foram criados gráficos pelo
JMeter contendo os valores médios do tempo decorrido entre a requisição e o
download completo de cada página, seus gráficos de barra estão expressos na Figura
19 e
Pode-se constatar a partir da análise destas que a operação de login foi o que
levou mais tempo para ser executado em ambos os sistemas.
Figura 20.

49
Figura 19 - Gráfico de valores médios do tempo decorrido entre a requisição e o
download completo de cada página feita ao SIPAC.
Pode-se constatar a partir da análise destas que a operação de login foi o que
levou mais tempo para ser executado em ambos os sistemas.
Figura 20 - Gráfico de valores médios do tempo decorrido entre a requisição e o
download completo de cada página feita ao SIGAA.
3.4.3. Homologação do ambiente quanto a quesitos de segurança
Além de homologar o ambiente de acordo com os quesitos de carga e operação,
é imprescindível homologá-lo também quanto à segurança. É sabido que um

50
computador conectado à rede está à mercê de uma série de ataques. Servidores e
serviços, especialmente, sofrem maior risco, uma vez que são comumente alvo de
ataques. Diariamente novos bugs são descobertos, expondo vulnerabilidades mesmo
em servidores bem configurados e atualizados.
Para realizar a varredura por vulnerabilidades nas máquinas do ambiente foi
utilizado outro computador independente com a distribuição GNU/Linux Kali instalada.
A partir deste foi feita a configuração e execução da ferramenta OpenVAS para
escaneamento das máquinas. Ao final do teste foi apresentado uma série de resultados
que podem ser conferidos na Figura 21.
Em cada um dos servidores foi encontrado uma vulnerabilidade. Para os
servidores de balanceamento, com CVSS de 4.3 a diretiva FileETag do Apache
possibilita a partir dos cabeçalhos de resposta que informações sensíveis sejam
expostas, facilitando um possível ataque direcionado à versão do sistema operacional e
ao Apache. Para os servidores de banco de dados, com CVSS de 9.0 uma entrada
erroneamente configurada no arquivo pg_hba.conf possibilitava o acesso do usuário
postgres ao banco sem que fosse solicitada a senha. Finalmente, para os servidores de
aplicações, com CVSS 7.5 foram encontradas vulnerabilidades graves na versão
utilizada do JBoss.
Figura 21 - Resultado do primeiro escaneamento por vulnerabilidades nos servidores
do ambiente.
Fonte: Adaptado a partir da ferramenta OpenVAS (2014)
Após a constatação da existência de vulnerabilidades seguiu-se a tentativa de
eliminação das mesmas. A resolução dos problemas de segurança no que tange aos
servidores de banco de dados foi a simples adição da obrigatoriedade de utilização do
mecanismo de autenticação que utiliza o algoritmo de hash md5 para a senha. Para os
servidores de balanceamento, foi igualmente simples, bastando desativar a diretiva
FileETag.

51
No entanto, por limitações da arquitetura dos sistemas que está portada para
esta versão do JBoss não foi possível executar a atualização do mesmo. Uma
possibilidade de atenuação do problema envolvendo o JBoss é a desativação de sua
respectiva porta HTTP, obrigando que qualquer sistema seja acessado através do
servidor de balanceamento, passando a utilizar somente a interface AJP para
comunicar-se com a instância.
Uma nova varredura foi executada nos hosts do ambiente após as alterações,
constatando-se na Figura 22 que os servidores de balanceamento e banco de dados
não apresentaram vulnerabilidades. Apesar de ainda possuir uma thread classificada
como Low para os servidores de balanceamento, o CVSS atribuído as mesmas é de 0,
servindo apenas de informativo sobre o Apache.
Figura 22 - Resultado do segundo escaneamento após correção de falhas.
Fonte: Adaptado a partir da ferramenta OpenVAS (2014)

52
4. CONSIDERAÇÕES FINAIS
Ao longo deste trabalho foi realizado um conjunto de atividades em vista do
objetivo maior de redução de riscos relativos à indisponibilidade dos sistemas SIG da
Universidade Federal do Rio Grande do Norte. O desenvolvimento de sua pesquisa
revelou a capacidade de utilização de novas tecnologias de software que possibilitem a
formação de um ambiente de produção mais escalável e disponível.
4.1. CONCLUSÃO
Neste trabalho foram estudados mecanismos de alta disponibilidade em software
livre para implementação em um ambiente proposto para homologação similarmente
configurado ao ambiente de produção da UFRN. Como exposto na seção de
resultados, foi comprovada uma melhora significativa por meio de testes e simulações
na infraestrutura de servidores e serviços, reduzindo o risco de indisponibilidade
prolongada com a eliminação dos pontos críticos de falha detectados.
A futura configuração dos mesmos mecanismos no ambiente de produção da
universidade resultará em um significativo ganho de segurança, uma vez que os dados
dos usuários dos sistemas serão replicados constantemente, eliminando a situação em
que horas de dados seriam perdidas por motivo de um crash em um dos bancos,
seguida da recuperação por meio de backups.
O desenvolvimento do trabalho propiciou a formação de uma série de
perspectivas de implantação de tecnologias. Os mecanismos implementados de
recuperação de incidentes, mesmo quando manuais, representam um grande avanço
para a infraestrutura exposta na seção 1.1 uma vez que atualmente, tais incidentes
resultariam na indisponibilidade completa dos sistemas. Adicionalmente, o modelo de
configuração empregado facilita procedimentos de manutenção, possibilitando a
atualização isolada dos sistemas em seus respectivos grupos de balanceamento.
Quanto a rotinas de backup, podem ser configuradas para correr sobre o
servidor de banco de dados secundário, retirando do primário o processamento
necessário para sua execução, que atualmente é um agente limitador para a realização
de backups.
Por fim, o próprio método de homologação não funcional utilizado pode ser
empregado para os diversos ambientes de software existentes na UFRN, corroborando

53
para uma melhor sincronia dos recursos utilizados para servir as demandas existentes
e aumento da segurança de todo o ambiente global.
4.2. SUGESTÕES E RECOMENDAÇÕES
Apesar do esforço desempenhado na produção deste trabalho, restou uma série
de possibilidades para motivar trabalhos futuros, por exemplo, a implementação do
PGPOOL para configuração de balanceamento de carga e recuperação automática
para os servidores de banco de dados. Como também a configuração de
balanceamento de carga para o próprio balanceador dos sistemas, fazendo uso de
tecnologias tais como o Corosync e o Pacemaker utilizados no trabalho de Bely Silva
para ampliar a capacidade do proxy Squid utilizando o modelo cluster.

54
REFERÊNCIAS
ABRAHAM SILBERSCHATZ, H. F. K. S. S. Introdução. In: ______ Sistema de Banco
de dados. 3. ed. São Paulo: Pearson Education, 2007. p. 778.
APACHE HTTP Server Project, 2014. Disponivel em: <http://httpd.apache.org/>.
Acesso em: 16 abr. 2014.
BOSZORMENYI, Z.; SCHONIG, H. J. PostgreSQL Replication. Birmingham: Packt
Publishing, 2013.
ERINLE, B. Performance Testing with JMeter 2.9. Birmingham: Packt Publishing,
2013.
GOLDEN, B. Virtualization for Dummies. Indianapolis: Wiley Publishing, Inc., 2008.
KOPPER, K. The Linux Enterprise Cluster. San Francisco: [s.n.], 2005.
LIMA, G. D. A. F. Análise de desempenho de sistemas distribuídos de grande
porte na plataforma Java. Universidade Federal do Rio Grande do Norte. Natal, p. 91.
2007.
LINS, C. L. A. C. Sistemas Institucionais Integrados de Gestão - SIG. Wiki Sistemas,
2014. Disponivel em: <http://info.ufrn.br/wikisistemas/doku.php>. Acesso em: 4 Março
2014.
LOPES, H. M. A. Estudo e Planejamento de uma infraestrutura computacional.
Instituto Superior de Engenharia de Lisboa. Lisboa, p. 122. 2012.
MOTA FILHO, J. E. Descobrindo o Linux. São Paulo: Novatec, 2006.
OLUPS, R. Zabbix 1.8 Network Monitoring. Birmingham: [s.n.], 2010.
PANDA, S. K.; BHOI, S. K. An Effective Round Robin Algorithm using. National
Institute of Technology, Rourkela. [S.l.], p. 9. 2012.
PRITCHETT, W.; SMET, D. D. BackTrack 5 CookBook. [S.l.]: [s.n.], 2012.
RIGGS, S.; KROSING, H. PostgreSQL 9 Administration Cookbook. Birmingham:
Packt Publishing Ltd, 2010.
SAMRA, H. S. Study on Non Functional Software Testing. International Journal of
Computers & Technology, 2013.
SHOAIB, Y. Performance Measurement and Analytic Modeling of a WEB
Application. University of Toronto. Toronto. 2008.

55
SILVA JÚNIOR, B. Implementação de solução de alta disponibilidade para proxy
http utilizando ferramentas livre. Natal: [s.n.], 2012.
SMITH, G. PostgreSQL 9.0 High Performance. Birmingham: Packt Publishing, 2010.
WOLF, C. Cluster synchronization with Csync2. LINBIT. [S.l.], p. 11. 2013.

56
APÊNDICE A – SCRIPT PARA SINCRONIZAÇÃO INICIAL DOS BANCOS DE
DADOS MESTRE – ESCRAVO.
#!/bin/bash
PGBIN=/usr/local/postgresql-9.3.0/bin
PGDATA_SRC=/data/pgdata
PGDATA_DST=/data/pgdata
SLAVE=habdsistemas2
# Inicia modo backup
echo "$(date +%H:%M): Iniciando backup..."
su postgres -c "$PGBIN/psql -c "select
pg_start_backup('base backup for log shipping')""
if [ $? -eq 0 ];then
# Executa rsync
echo "$(date +%H:%M): Sincronizando arquivos..."
su postgres -c "rsync -cva -e'ssh -lpostgres -p2222' --
inplace --delete-excluded --partial --exclude=*pg_xlog* --
exclude=*postgresql.conf* --exclude=*pg_hba.conf*
--exclude=*serverlog* --exclude=*archive* --
exclude=*recovery.conf* $PGDATA_SRC/* $SLAVE:$PGDATA_DST/"
# Terminando backup
echo "$(date +%H:%M): Finalizando backup..."
su postgres -c "$PGBIN/psql -c "select pg_stop_backup(),
current_timestamp""
else
echo "ERROR"
exit 1
fi
exit 0

57
APÊNDICE B – SCRIPT AUXILIAR DO PROCESSO DE FAILOVER ENTRE
SERVIDORES DE BANCO DE DADOS.
#!/bin/bash
IP_MASTER=10.3.226.32
SUB_NET=255.255.252.0
#$PGBIN/psql -c ""
echo "** ATENCAO** "
echo "Este script executara as seguintes acoes:"
echo "1- Retirara o Postgresql do modo recovery"
echo "2- Adicionara uma interface virtual com endereco
$IP_MASTER"
echo -n "Deseja continua? (s/n) "
read OPCAO
if [ "$OPCAO" == "s" ];then
echo "Promovendo PostgreSQL..."
touch /tmp/postgresql.trigger.5432
echo "Adicionando interface..."
ifconfig eth0:0 $IP_MASTER netmask $SUB_NET up
else
echo "Saindo..."
exit 1
fi
exit 0

58
APÊNDICE C – SCRIPT AUXILIAR DO PROCESSO DE FAILBACK ENTRE
SERVIDORES DE BANCO DE DADOS.
#!/bin/bash
MASTER=habdsistemas1
PGBIN=/usr/local/postgresql-9.3.0/bin
PGDATA_SRC=/data/pgdata
PGDATA_DST=/data/pgdata
echo "** ATENCAO ** "
echo "Digite 1 para despromover o Postgresql"
echo "Digite 2 para sincronizar os dados com o master"
echo "Digite 3 para cancelar"
echo -n "Opcao: "
read OPCAO
if [ "$OPCAO" == "1" ];then
echo "Este script executara as seguintes acoes:"
echo "1- Terminara o processo do postgresql"
echo "2- Devolvera o endereco do master"
echo "3- Reconfigurara o modo de recuperacao continua"
echo ""
echo "Parando processo do postgresql..."
/etc/init.d/postgresql stop
echo "Removendo interface..."
ifconfig eth0:0 down
echo "Despromovendo PostgreSQL.."
rm /tmp/postgresql.trigger.5432
mv /data/pgdata/recovery.done /data/pgdata/recovery.conf

59
elif [ "$OPCAO" == "2" ];then
echo "** ATENCAO **"
echo "Para que o procedimento funcione corretamente se faz
necessario que o servidor master esteja ativo e que o postgresql
esteja parado"
echo -n "Deseja continuar? (s/n): "
read CONT
if [ "$CONT" == "s" ];then
echo "Sincronizando dados com o master"
# OBS: Na sincronizacao entre slave e master deve-se manter o
diretorio pg_xlog para que os checkpoints possam ser lidos
su postgres -c "rsync -cva -e'ssh -lpostgres -p2222' --
inplace --partial --delete-excluded --exclude=*postgresql.conf*
--exclude=*pg_hba.conf* --exclude=*serverlog* --
exclude=*archive* --exclude=*recovery.conf* $PGDATA_SRC/*
$MASTER:$PGDATA_DST/"
else
echo "Saindo..."
exit 1
fi
else
echo "Saindo..."
exit 1
fi
exit

Homologação de Ambiente HA para SIGs UFRN

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (16)

Semelhante a Homologação de Ambiente HA para SIGs UFRN

Semelhante a Homologação de Ambiente HA para SIGs UFRN (20)

Homologação de Ambiente HA para SIGs UFRN