Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Homologação de ambiente de alta disponibilidade para os sistemas SIG da UFRN

929 views

Published on

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 SIG da universidade, implementando e homologando mecanismos de alta disponibilidade para eliminação de pontos únicos de falha.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Homologação de ambiente de alta disponibilidade para os sistemas SIG da UFRN

  1. 1. 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
  2. 2. 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 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
  3. 3. 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 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
  4. 4. 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.
  5. 5. 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.
  6. 6. 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.
  7. 7. 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.
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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.
  14. 14. 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.
  15. 15. 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:
  16. 16. 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.
  17. 17. 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)
  18. 18. 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
  19. 19. 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.”.
  20. 20. 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)
  21. 21. 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.
  22. 22. 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)
  23. 23. 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. Fonte: Elaborado pelo autor (2014) Resultante da criação do novo modelo, surgiu a necessidade de implementar servidores responsáveis pelo papel de prover infraestrutura, serviços e ferramentas.
  24. 24. 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.
  25. 25. 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. Fonte: Elaborado pelo autor (2014) 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.
  26. 26. 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
  27. 27. 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. Fonte: Elaborado pelo autor (2014) 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
  28. 28. 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.
  29. 29. 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
  30. 30. 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.
  31. 31. 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.
  32. 32. 31 Figura 6 - Listagem de hosts do ambiente virtual monitorados pelo Zabbix. Fonte: Adaptado da ferramenta Zabbix (2014)
  33. 33. 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 Fonte: Elaborado pelo autor (2014) 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.
  34. 34. 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 Fonte: Elaborado pelo autor (2014) 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. Fonte: Elaborado pelo autor (2014)
  35. 35. 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.
  36. 36. 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.
  37. 37. 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.
  38. 38. 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 Fonte: Elaborado pelo autor (2014) 11 É uma linguagem de script usada em vários sistemas operacionais. É geralmente associada aos interpretadores de distribuições GNU/Linux como o bash.
  39. 39. 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
  40. 40. 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
  41. 41. 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
  42. 42. 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.
  43. 43. 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. Fonte: Adaptado a partir da ferramenta JMeter (2014) 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)
  44. 44. 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. Fonte: Adaptado a partir da ferramenta JMeter (2014)
  45. 45. 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:
  46. 46. 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. Fonte: Adaptado a partir da ferramenta JMeter (2014) 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.
  47. 47. 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. Fonte: Adaptado a partir da ferramenta Zabbix (2014) 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
  48. 48. 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. Fonte: Adaptado a partir da ferramenta Zabbix (2014) Figura 17 - Gráfico da memória heap para a instância hasistemas1i2. Fonte: Adaptado a partir da ferramenta Zabbix (2014) 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.
  49. 49. 48 Figura 18 - Gráfico de utilização de threads do Apache para o servidor habalancer1. Fonte: Adaptado a partir da ferramenta Zabbix (2014) 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.
  50. 50. 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. Fonte: Adaptado a partir da ferramenta JMeter (2014) 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. Fonte: Adaptado a partir da ferramenta JMeter (2014) 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
  51. 51. 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.
  52. 52. 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)
  53. 53. 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
  54. 54. 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.
  55. 55. 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.
  56. 56. 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.
  57. 57. 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
  58. 58. 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 # Inicia modo backup #$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
  59. 59. 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 # Inicia modo backup 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
  60. 60. 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

×