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.

Monografia P2PMON final

1,222 views

Published on

  • Be the first to comment

  • Be the first to like this

Monografia P2PMON final

  1. 1. Faculdade de Informática e Administração PaulistaBacharelado em Sistemas de InformaçãoFIAPP2PMON: Um Sistema de monitoramento de servidores derede baseado em comunicação P2PGeraldo Augusto de Oliveira Netto – RM 60173São Paulo2010
  2. 2. Faculdade de Informática e Administração PaulistaBacharelado em Sistemas de InformaçãoFIAPP2PMON: Um Sistema de monitoramento de servidores derede baseado em comunicação P2PMonografia apresentada à Faculdade deInformática e Administração Paulistapara obtenção do grau de bacharel emSistemas de Informação.Orientador: Prof. Dr. César da CostaCoorientador: Prof. Msc. AlexanderLuz SperandioSão Paulo2010
  3. 3. IIEste trabalho é dedicado à todas as pessoasque passaram, estão passando e passarão pelaminha vida. Sem vocês, eu seria nada!
  4. 4. IIIAGRADECIMENTOSA minha família, em especial, minha mãe;A Juli;Ao meu valoroso amigo, Dom Venturini de Matos;A todos os professores, em especial, os professores:Alex, César da Costa, Drudi,Goya, Gustavo, José do Carmo Rodrigues,Nivaldo e Willian Peixoto.Senhores, ASNF;Aos meus amigos do 4SIA (turma 2009), Wesley, Flávio e Otávio;
  5. 5. IVRESUMOAtualmente (2010) a grande complexidade dos ambientes computacionaistornam a tarefa dos administradores de sistemas e de redes difíceis. Estacomplexidade requer que o administrador utilize muitas ferramentas de software paraconseguir manter o ambiente sem falhas. Com o uso de sistemas de monitoramento,este cenário torna-se mais complexo. A complexidade das tarefas dosadministradores também aumenta, já que cada ambiente de monitoramento, muitasvezes, requer uma nova ferramenta específica para o ambiente.Este trabalho propõe o desenvolvimento de um sistema de monitoramento deservidores baseado em arquitetura de comunicação não hierárquica chamada Peer-to-Peer ( P2P). A ferramenta de monitoramento desenvolvida foi chamada de P2PMON.Ao decorrer do trabalho serão apresentados os componentes e estratégias quetornaram a ferramenta P2PMON viável.Uma avaliação da solução proposta é realizada em ambiente de testes. Osresultados são apresentados em comparativos de tempo e utilização de rede para asestratégias apresentadas. Além disso, um teste de escalabilidade é executado paramostrar o comportamento da solução proposta.Palavras-chave: redes, sistemas distribuídos, cliente-servidor, P2P, monitoramento
  6. 6. VABSTRACTCurrently (2010) the great complexity of computing environments make thetask of network and system administrators difficult. This complexity requires theadministrator to use many software tools in order to keep the environment withoutfailure. Through the use of monitoring systems, this scenario becomes morecomplex. The complexity of the tasks of network and system administrators alsoincrease, once each monitored environment usually requires a new specific tool forthe environment.This thesis proposes the development of a server monitoring system based ona non-hierarchical communication architecture called Peer-to-Peer (P2P). Themonitoring tool developed is called herein P2PMON.Along this thesis it is presented the components and strategies that make thetool P2PMON viable.An evaluation of the proposed solution is performed in a test environment.The results are presented in comparative time and network utilization for thestrategies presented. In addition, a scalability test is performed to show the behaviorof the proposed solution.Key words: networks, distributed systems, client-server, P2P, monitoring
  7. 7. VILISTA DE ILUSTRAÇÕES E GRÁFICOSFigura 01 – Organização em árvore da SMI...............................................................18Figura 02 – Ciclo de vida de um processo (máquina de estados finitos)....................20Figura 03 – Grafo regular a esquerda e grafo completo a direita...............................25Figura 04 – Árvore da dependabilidade......................................................................28Figura 05 – Tipos de falhas de um sistema.................................................................29Figura 06 – Configuração 1 para 1 assimétrica..........................................................29Figura 07 – Configuração n para 1 assimétrica..........................................................30Figura 08 – Configuração 1 para 1 simétrica..............................................................31Figura 09 – Configuração round-robin com 4 servidores...........................................31Figura 10 – Arquitetura do P2PMON e P2PMONWEB.............................................32Figura 11 – Máquina de estados finitos do P2PMON................................................35Figura 12 – P2PMON (P2P) x HQ Hyperic (cliente-servidor)...................................35Figura 13 – Arquitetura do padrão de projeto MVC...................................................40Figura 14 – Diagrama de Caso de Uso do P2PMON..................................................41Figura 15 – Diagrama de Caso de Uso do P2PMONWEB.........................................42Figura 16 – Modelo do banco de dados parte 1..........................................................42Figura 17 – Modelo do banco de dados parte 2..........................................................43Gráfico 01 – Porcentagem de CPU utilizada e RAM utilizada no P2PMON.............45Gráfico 02 – Porcentagem de CPU utilizada e RAM utilizada no HQ Hypericagent/server.................................................................................................................45
  8. 8. VIILISTA DE FÓRMULAS E TABELASFórmula (1) – Taxa de reuso de classes......................................................................39Tabela 01 – Contagem de saltos por tipo de técnica...................................................27Tabela 02 – Comparação entre os dados gerados pelo P2PMON e HQ Hypericagent/server.................................................................................................................46Tabela 03 – Requisitos de software, facilidade de instalação e características...........46
  9. 9. VIIILISTA DE ABREVIATURAS E SIGLASAES Advanced Encryption StandardARM Advanced RISC MachineASN.1 Abstract Syntax Notation 1BNF Backus-Naur FormCAN Content Addressable NetworkCSV Comma Separated valuesCUPS Common Unix Printing SystemDAO Data Access ObjectDDOS Distributed Denial Of ServiceDHCP Dynamic Host Configuration ProtocolDHT Distributed Hash TableDNS Domain Name SystemDoD Department of DefenceDOS Denial Of ServiceDTO Data Transfer ObjectGCJ GNU Compiler for JavaGNU GNU is Not UnixGoF Gang of FourGPL General Public LicenseHTML HyperText Markup LanguageHTTP HyperText Transfer ProtocolIBM International Business MachinesIETF Internet Engineering Task ForceIIS Internet Information ServicesIPC InterProcess CommunicationIPMI Intelligent Platform Management InterfaceISO International Organization for StandardizationITIL Information Technology Infrastructure LibraryITU International Telecommunication Union
  10. 10. IXJDBC Java DataBase ConnectivityJDK Java Development KitJNI Java Native InterfaceJSON JavaScript Object NotationJSP JavaServer PagesJvisualVM Java visual Virtual MachineJVM Java Virtual MachineMAC ADDRESS Media Access Control AddressMER Modelo Entidade-RelacionamentoMIB Management Information BaseMIPS Microprocessor without Interlocked Pipeline StagesMITM Man In The Middle AttackMTBF Mean Time Between FailureMTRG Multi Router Traffic GrapherMVC Model View ControllerNRPE Nagios Remote Plugin ExecutorNSCA Nagios Service Check AcceptorODBC Open DataBase ConnectivityOID Object IDentifierOPENNMS OPEN Network Management SystemORG OrganizationOSI Open System InterconnectionP2P Peer-to-PeerP2PMON Peer-to-Peer MONitorPOP3 Post Office Protocol versão 3POSIX Portable Operating System Interface for uniXRAM Random Access MemoryRFC Request For CommentsRSA Rivest, Shamir and AdlemanSHA-1 Secure Hash Algorithm 1SLA Service Level AgreementSMI Structure of Managed Information
  11. 11. XSMTP Simple Mail Transfer ProtocolSNMP Simple Network Management ProtocolSQL Structured Query LanguageTCP Transmission Control ProtocolTI Tecnologia da InformaçãoTO Transfer ObjectUDP User Datagram ProtocolUML Unified Modelling LanguageVO Value ObjectXML Extensible Markup LanguageXOR eXclusive ORYUI Yahoo! User Interface
  12. 12. XISUMÁRIORESUMO...................................................................................................................IVABSTRACT................................................................................................................VLISTA DE ILUSTRAÇÕES E GRÁFICOS...........................................................VILISTA DE FÓRMULAS E TABELAS..................................................................VIILISTA DE ABREVIATURAS E SIGLAS...........................................................VIIICAPÍTULO 1 – INTRODUÇÃO.............................................................................131.1 INTRODUÇÃO....................................................................................................131.2 CONTEXTUALIZAÇÃO.....................................................................................131.3 OBJETIVOS.........................................................................................................141.4 JUSTIFICATIVA..................................................................................................141.5 ORGANIZAÇÃO DO TRABALHO....................................................................15CAPÍTULO 2 – REVISÃO BIBLIOGRÁFICA....................................................162.1 PROTOCOLO.......................................................................................................162.1.1 O Protocolo SNMP...........................................................................................162.2 PROCESSOS E THREADS.................................................................................202.3 SISTEMAS DISTRIBUÍDOS..............................................................................212.3.1 Sistemas Cliente-Servidor...............................................................................232.3.2 Sistemas Peer-to-Peer (P2P)............................................................................242.4 MÉTODOS DE ALTA DISPONIBILIDADE E TOLERÂNCIAA FALHAS.....27CAPÍTULO 3 – MATERIAIS E MÉTODOS.........................................................323.1 SOLUÇÃO PROPOSTA......................................................................................323.2 COMPONENTE DE SOFTWARE UTILIZADOS..............................................363.3 HARDWARE UTILIZADOS...............................................................................383.4 TÉCNICAS DE ENGENHARIA DE SOFTWARE UTILIZADAS....................393.5 AMBIENTE DE TESTES.....................................................................................44CAPÍTULO 4 – RESULTADOS E DISCUSSÕES................................................45CAPÍTULO 5 – CONCLUSÕES.............................................................................495.1 CONSIDERAÇÕES FINAIS................................................................................495.2 CONCLUSÕES....................................................................................................495.2 TRABALHOS FUTUROS...................................................................................50
  13. 13. XIIBIBLIOGRAFIA.......................................................................................................52APÊNDICE A – MANUAL DO P2PMON..............................................................55
  14. 14. 13CAPÍTULO 1 – INTRODUÇÃONeste capítulo são abordadas a introdução, a contextualização, os objetivos, asdificuldades encontradas e por fim, a organização do trabalho. Tais tópicos visam acontextualização para, portanto, facilitam a compreenssão das linhas gerais deste trabalho.1.1 IntroduçãoAtravés do processo de monitoramento, processo este que consiste na obtenção deinformações sobre os elementos de um sistema computacional, as atuais soluções demonitoramento de servidores (2010), apesar de permitirem aos administradores de ambientescomputacionais (administradores de redes e de sistemas) o gerenciamento de infra-estruturasde tecnologia da informação mais robustas e flexíveis, implicam na quebra dos processos demonitoramento empregados por sistemas de monitoramento populares, como, por exemplo, oNagios e Zabbix, já que trabalham utilizando o paradigma cliente-servidor e portanto, podemapresentar dificuldade para lidar com as necessidades do ambiente computacional emconstante adaptação e crescente demanda.Isto ocorre porque sistemas como esses possuem uma lista fixa de servidores paracontatar quando monitoram os serviços de um ambiente de rede, qualquer migração de umservidor ou substituição de um hardware defeituoso gera problemas no sistema demonitoramento sem prévia preparação (estratégia) contingencial. Diferente da soluçãoproposta, P2PMON que utiliza o paradigma Peer-to-Peer (P2P).1.2 ContextualizaçãoCom os atuais sistemas de monitoramento (2010), os administradores de redes esistemas precisam ajustar manualmente as ferramentas de monitoramento disponíveis pararefletir a situação atual do ambiente. Entretanto, a quantidade de equipamento e serviços sobsua responsabilidade não permite que uma estratégia deste tipo seja adotada. Assim,adaptações nas ferramentas de monitoramento são necessárias para tratar a dinâmica naturaldos novos ambientes computacionais.Por causa das características dos sistemas cliente-servidor, que são utilizados nos
  15. 15. 14atuais sistemas de monitoramento (2010), são verificadas algumas dificuldades como: (i)escalabilidade; (ii) alta disponibilidade; (iii) tolerância a falha. Sendo que usualmenteimplementa-se métodos de alta disponibilidade e tolerância a falhas para contornar essasdificuldades. (Marcus et al; 2000)Com a abordagem Peer-to-Peer (P2P), as dificuldades em escalabilidade, altadisponibilidade, tolerância a falha e mesmo segurança são reduzidas com um custo de projetode software mais complexo, em virtude de ser necessário implementar tanto a parte cliente,quanto a parte servidor no mesmo software, eliminando desta forma, a hierarquia nacomunicação e por fim, dando flexibilidade ao software. (Coulouris et al, 2007)1.3 ObjetivosEste trabalho tem como objetivo principal desenvolver um sistema de monitoramentode servidores, baseado em uma arquitetura de comunicação chamada Peer-to-Peer (P2P).Também tem como objetivo desenvolver técnicas para coletar, armazenar, disponibilizar estasinformações e alcançar escalabilidade, alta disponibilidade, tolerância a falha e segurança, deforma transparente aos administradores de ambientes computacionais.1.4 JustificativaRedes Peer-to-Peer (P2P) tem como característica a escalabilidade, altadisponibilidade, tolerância a falha e segurança distribuída de forma pervasiva pela rede e deforma inerente, por que como cada host (servidor interconectado pela rede) é autônomo,podendo fazer tanto o papel de cliente quanto o de servidor ao mesmo tempo. Enquanto redesbaseadas no modelo cliente-servidor, justamente pelo fato de cada host ter o seu papelclaramente delimitado, características como escalabilidade, alta disponibilidade, tolerância afalha e segurança não são inerentes ao modelo cliente-servidor.Desta forma, o trabalho proposto se mostra vantajoso, já que através de redes P2P, osistema de monitoramento proposto é mais robusto em termos de escalabilidade, altadisponibilidade, tolerância a falha e segurança. Além disso, através da utilização da linguagemde programação Java, também é obtida outra vantagem, a alta capacidade de portabilidade,permitindo que diversos sistemas operacionais possam fazer uso do P2PMON.
  16. 16. 151.5 Organização do trabalhoO trabalho está dividido em 5 capítulos:▪ Capítulo 2 apresenta os fundamentos sobre redes de computadores, protocolosde comunicação e processos. Também são apresentadas as características desistemas distribuídos e redes Peer-to-Peer.▪ Capítulo 3 mostra a solução proposta para o monitoramento de servidoresdenominada P2PMON, seus componentes empregados, bem como asdiferentes estratégias utilizando estes componentes.▪ Capítulo 4 apresenta detalhes e resultados da implementação da soluçãoproposta em um ambiente de testes.▪ Capítulo 5 apresenta as considerações finais e comentários sobre o trabalho.Também são apresentadas propostas para trabalhos futuros.
  17. 17. 16CAPÍTULO 2 – REVISÃO BIBLIOGRÁFICANeste capítulo são abordados os conceitos e estratégias fundamentais para o corretoentendimento deste trabalho.2.1 ProtocoloUm protocolo é uma especificação de regras e formatos para a realização dacomunicação entre sistemas. (Stallings, William, 2000) Desta forma, são definidos métodosde troca de mensagens entre hosts (qualquer computador de qualquer porte conectado a umarede). De acordo com Stallings, os protocolos podem ser:▪ Direto/Indireto;▪ Monolítico/Estruturado;▪ Simétrico/Assimétrico;Os protocolos são diretos quando os hosts podem se comunicar diretamente, enquanto,nos protocolos indiretos, os hosts dependem de outras conexões físicas para se comunicarem.Os protocolos são monolíticos quando a arquitetura dos pacotes são fortemente acopladas epor isso, a troca de uma parte da arquitetura do protocolo requer a reimplementação doprotocolo todo. Enquanto, em protocolos estruturados, a arquitetura é baseada em camadasque podem ser muito facilmente modificadas como no modelo de referência OSI.Os protocolos são simétricos quando há uma comunicação onde não há papéis ouhierárquia entre os hosts, como, por exemplo, em um sistema Peer-to-Peer (P2P). Enquantonos protocolos assimétricos, há a definição clara de papéis ou hierarquia, como no caso dossistemas cliente-servidor e desta forma, a comunicação tem um ciclo bem estabelecido.2.1.1 O Protocolo SNMPO protocolo SNMP (Simple Netwrok Management Protocol), foi criado pelo IETF(Internet Engineering Task Force) através das RFCs (Request For Comments) 1065, 1066,1067 (versão 1), 1441, 1452 (versão 2) e 1157, 3411 e 3418 (versão 3).
  18. 18. 17O SNMP é um conjunto de especificações que tem por objetivo, oferecer umframework para o monitoramento de redes (tanto hardware, quanto software) através dosprotocolos TCP e UDP nas portas 161 e 162 (Carvalho, 1993). O protocolo SNMP é compostopor três itens (adaptado de Stallings, 2000):▪ Dispositivo gerenciado▪ Agente SNMP▪ Sistema de monitoramento de redes ou gerente SNMPO dispositivo gerenciado é o hardware no qual o Agente SNMP é executado. O AgenteSNMP é o software no qual disponibiliza o estado do dispositivo gerenciado através doprotocolo SNMP, sendo que há dois tipos de agente SNMP: (i) sistemas com agente SNMPstandalone; (ii) sistemas sem agente SNMP standalone, também chamados de agentless.Os agentes SNMP standalone são os sistemas tradicionais onde um software queimplementa uma, duas ou as três versões do protocolo SNMP é instalado a parte, já ossistemas sem agente SNMP (agentless) dependem do sistema operacional fornecer o suportenativo e embutido ao protocolo SNMP para fazer o papel de agente SNMP.O Sistema de monitoramento de redes ou gerente SNMP é o software que oferece umainterface amigável ao administrador de redes para visualizar os dados previamente coletadospelos agentes SNMP.Para o funcionamento do Agente SNMP e do Sistema de monitoramento de redes, há oSMI (Structure of Management Information) que é responsável pela organização lógica emforma de árvore dos dados do agente SNMP.Cada item (“folha”) dentro desta árvore (figura 01) é chamada de MIB (ManagementInformation Base). A MIB é um ou mais itens da SMI e através da MIB é possível consultar(métodos get e getnext), modificar (método set) ou notificar (método trap) o sistema demonitoramento de redes sobre algum problema de um agente SNMP em tempo real, já que oprotocolo SNMP atua na camada de aplicação (camada 7 do modelo de referência OSI),funcionando assim, através da troca de mensagens.Para acessar as MIBs, utiliza-se o OID que é uma sequência numérica e representa umobjeto da MIB. Por exemplo, a seqüência 1.3.6.1.4.1 representa a árvore padronizadaiso.org.dod.internet.private.enterprise.
  19. 19. 18Figura 01 – Organização em árvore da SMI(Fonte: http://support.3com.com/infodeli/tools/netmgt/tncsunix/product/091500/c15snmp1.gif)As informações contidas nas MIBs são descritas seguindo o padrão ASN.1desenvolvidos pela ISO e ITU e são baseadas na Forma Normal de Backus Naur (do inglêsBackus-Naur Form – BNF) que permite estruturar uma gramática livre de contexto, dandoassim, mais flexibilidade para a descrição das MIBs. O agrupamento de agentes SNMP(standalone ou agentless) e sistemas de monitoramento de redes ou gerente SNMP em umaúnica rede, com o objetivo de monitorar os ativos de Tecnologia da Informação (TI) édenominado comunidade SNMP. Desta forma, estabelece-se um ambiente de monitoramentoou gerenciamento de rede. (Carvalho, 1993)Assim como o protocolo SNMP, também existem padrões para se estruturar ogerenciamento de rede. O modelo de referência OSI propõe cinco áreas funcionais para ossistemas de monitoramento de redes: (i) gerenciamento de falhas; (ii) gerenciamento de
  20. 20. 19configuração; (iii) gerenciamento de desempenho; (iv) gerenciamento de segurança; (v)gerenciamento de contabilização. (Carvalho, 1993)O gerenciamento de falhas tem o objetivo de detectar, isolar e se possível, proporcorreção para as possíveis falhas e faltas do ambiente em monitoramento. O gerenciamento deconfiguração tem o objetivo de controlar os ativos da TI na forma de inventário. Assim, podedimensionar com mais precisão o ambiente monitorado, além de oferecer possíveisperspectivas de planos de capacidade futuros. O gerenciamento de desempenho tem o objetivode coletar métricas para dimensionar o desempenho dos serviços no ambiente monitorado. Ogerenciamento de segurança tem o objetivo de monitorar e controlar os mecanismos desegurança no ambiente monitorado. O gerenciamento de contabilização tem o objetivo decontabilizar, principalmente de forma financeira todo o serviço de monitoramento doambiente. Desta forma, é possível, por exemplo, ajustar o SLA (Service Level Agreement).Em (Miller, 1997) são abordados de forma mais aprofundada a arquitetura dossistemas de monitoramento de redes. Usualmente, estes sistemas trabalham com dois ou maisprotocolos, o já conhecido SNMP e um ou mais protocolos que poder ser utilizados parafunções diferentes, como trocar mensagens vindas dos coletores de dados ou executarcomandos remotamente.Por exemplo, o sistema de monitoramento Nagios (Nagios, 2007), trabalha com oprotocolo SNMP e com outros dois protocolos sendo que cada protocolo tem um objetivoespecífico, o NSCA (Nagios Service Check Acceptor) que é um protocolo de coleta de dados eatua em nível de aplicação (camada sete do modelo de referência OSI) além de trabalhar naporta 5667 e o NRPE (Nagios Remote Plugin Executor) que é um protocolo para execução decomandos remotamente e também é um protocolo de aplicação (camada sete do modelo dereferência OSI) e trabalha na porta 5666.Outros sistemas de monitoramento como o HQ Hyperic (HQ Hyperic, 2010), sistemade monitoramento cliente-servidor, desenvolvido em Java e comparado com o P2PMON nocapítulo 3, utilizam cinco protocolos, o protocolo HTTP na porta 7080, o protocolo HTTPS naporta 7443, o protocolo JNP na porta 2099, o protocolo Mbean na porta 9093, o protocolo doagente HQ Hyperic na porta 2144 e ainda o protocolo do banco de dados PostgreSQL na porta9432. O P2PMON se utiliza única e exclusivamente do protocolo do próprio banco de dados,na configuração padrão, utiliza-se o protocolo do banco de dados MySQL na porta padrão3306, sendo possível a utilização de outro banco de dados mediante configuração.
  21. 21. 202.2 Processos e ThreadsUm software é uma entidade estática que usualmente está alocada em algumdispositivo de memória secundária como discos rígidos, entre outros, enquanto um processo, éuma entidade dinâmica, ou seja, é a execução de um programa. (Tanenbaum, 2003) Todoprocesso é composto por quatro partes: (i) área de código; (ii) área de dados; (iii) status doprocesso; (iv) recursos requeridos para o processo.A área de código contém todo código a ser executado (fluxo de execução). A área dedados contém o conjunto de dados trabalhos pela área de código, parte destes dados podemvir da interação com o usuário do software ou de um arquivo, por exemplo. O status doprocesso é a variável que armazena o status do processo que pode ser novo, executando,esperando, pronto e finalizado, como ilustra a figura 02.Figura 02 – Ciclo de vida de um processo (máquina de estados finitos)(Fonte: Operating System Concepts with Java, 7thed.)Um processo no estado “novo” ocorre quando o processo acabou de ser carregado paraa memória principal e entrou para a fila de processos do sistema operacional, o que nãonecessariamente significa entrar para o estado “pronto” ou “executando” imediatamente. Umprocesso no estado “executando” ocorre quando o processo ganha timeslice (tempo paraexecução) do escalonador do sistema operacional e efetivamente entra em execução. Umprocesso no estado “esperando” ocorre quando o processo necessita de algum recurso que estábloqueado. Um processo no estado “pronto” ocorre quando o processo está pronto para serexecutado. Um processo no estado “finalizado” ocorre quando o processo é finalizado.Uma das formas de paralelismo em processos ocorre através das threads. Uma threadNovo FinalizadoPronto ExecutandoEsperando
  22. 22. 21é um fluxo de execução, uma seqüência de instruções passíveis de escalonamento. Umathread consiste em quatro partes: (i) identificador da thread (Thread ID); (ii) contador doprograma (Program Counter – PC); (iii) registros; (iv) pilha.Processos que se utilizam de várias threads para criar paralelismo são denominadosmultithreaded e podem conter centenas de threads, como no caso do servidor WEB (protocoloHTTP) Apache. (Apache Foundation, 2010) Processos que não utilizam threads sãodenominados single threaded, por que a área de código de um processo também é uma threaddenominada thread primária.Há três modelos de threads: o modelo M para 1, o modelo 1 para 1 e o modelo M paraN. (Silberchartz; Galvin; Gagne, 2007)O modelo de threads M para 1 mapeia muitas threads em espaço de usuário para umathread em espaço de kernel. Isto implica em possível menor desempenho, já que uma threadem espaço de usuário pode bloquear as demais threads. Já o modelo de threads 1 para 1mapeia apenas uma thread em espaço de usuário para uma thread em espaço de kernel. Istoimplica em mais desempenho e paralelismo ao custo de uma sobrecarga cada vez que umathread em espaço de kernel é criada. E finalmente, o modelo de threads M para N mapeia Mthreads em espaço de usuário para N ou menos threads em espaço de kernel, criando ummodelo de threads misto entre M para 1 e 1 para 1. Isto implica em mais desempenho que omodelo de threads m para um, porém, menos desempenho que o modelo de threads 1 para 1 emenos sobrecarga que o modelo 1 para 1, mas, mais sobrecarga que o modelo M para 1.Os sistemas operacionais GNU/Linux e Microsoft Windows utilizam o modelo dethreads 1 para 1, enquanto a Java Virtual Machine (JVM) utiliza o mesmo modelo de threaddisponível nativamente no sistema operacional subjacente.2.3 Sistemas DistribuídosUm sistema distribuído é aquele no qual os componentes localizados em computadoresinterligados em rede se comunicam e coordenam suas ações apenas passando mensagens.(Coulouris et al, 2007)Já para Tanenbaum e Steen (2008), um sistema distribuído é uma coleção decomputadores independentes que são utilizados conjuntamente para executar uma tarefa ouserviço. Os sistemas distribuídos, em geral, são criados para atender a necessidade dedistribuição e compartilhamento de recursos, custo, desempenho, escalabilidade,
  23. 23. 22confiabilidade e segurança. (Heiser; Kuz, 2010) Além disso, há outras característicasdesejáveis para o sistema distribuído como a transparência, a interoperabilidade e aportabilidade.A distribuição e o compartilhamento de recursos pode ser aplicada de várias formas,como através do acesso remoto a um sistema de arquivos ou através da paralelização desoftware, entre outros. Ainda sobre distribuição e compartilhamento de recursos, uma técnicamuito utilizada é a replicação (cópia) de dados. Os dois tipos de replicações relevantes para opresente trabalho são a replicação síncrona e a replicação assíncrona.A replicação assíncrona faz a propagação de dados de forma assíncrona e oportunistano sentido de apenas sincronizar os dados quando o sistema tiver baixa demanda, desta forma,evita a perda de desempenho para a maioria dos casos, embora possa ser complicado manter apropagação de atualizações. (Date, 2004) A replicação síncrona faz a propagação de dados deforma síncrona, assim, para cada dado manipulado seja inserido, alterado ou removido, osistema deve ser capaz de sincronizar imediatamente os hosts ainda não sincronizados e porisso, podem ocorrer problemas de desempenho já que é inconveniente sincronizar os dados atodo instante, diferente da abordagem assíncrona. A transparência diz respeito a facilidade dese utilizar o sistema distribuído de acordo com os seguintes critérios (Coulouris et al, 2007):▪ Acesso: recursos locais ou remotos são acessados da mesma forma;▪ Localização: recursos podem ser acessados sem se conhecer onde estão;▪ Migração: recursos podem ser movidos sem afetar o sistema;▪ Replicação: recursos são duplicados sem se conhecer, no intuito de aumentardesempenho e disponibilidade;▪ Concorrência: recursos são disponibilizados de forma adequada para evitar osproblemas relacionados a concorrência na utilização dos mesmo;▪ Tolerância a falha: o sistema é capaz de ocultar e tratar a falha procurandoevitar qualquer impacto na utilização do mesmo pelos usuários finais;O middleware é uma camada de software que faz interface entre dois ou maissoftwares permitindo assim, a transparência de manipulação de dados sem afetar a API. Deacordo com (Coulouris et al, 2007), os sistemas distribuídos tem as seguintes dificuldadespara sua correta implementação: (i) transparência (concorrência, falha, acesso, localização,
  24. 24. 23migração, replicação); (ii) escalabilidade (tamanho, geografia, administração); (iii)dependabilidade; (iv) desempenho; (v) flexibilidade (extensibilidade, abertura,interoperabilidade).A interoperabilidade é o mecanismo que busca criar meios para facilitar a integraçãode sistemas heterogêneos. Este mecanismo pode ser implementado de várias formas, seja peladivisão do software em camadas, seja pela utilização de protocolos e etc. A portabilidade é acapacidade que o sistema distribuído tem de se adaptar aos diversos ambientes heterogêneos.Isto é, permitir que o sistema distribuído seja capaz de ser executado em arquiteturas dehardware diferentes como ARM, MIPS, x86, entre outras e softwares diferentes comoMicrosoft Windows, GNU/Linux, Oracle Solaris e etc. Ainda há duas formas de comunicaçãopara sistemas distribuídos: sistemas hierárquicos (cliente-servidor) e sistemas não-hierárquico(Peer-to-Peer ou P2P). Ambas estão relacionados com a forma como o sistema distribuído éestruturado em termos de comunicação e responsabilidades ou papéis.2.3.1 Sistemas Cliente-ServidorSistemas cliente-servidor são caracterizados pela comunicação hierárquica onde há umcliente, software que solicita algum tipo de recurso e um servidor, software que atende assolicitações dos clientes. Assim, o usuário final tem o processamento da interface gráfica nocliente e o gerenciamento e armazenamento de dados no servidor. Dependendo da aplicação edo software usado, todo o processamento de dados podem ocorrer no servidor ou ser divididoentre o cliente e o servidor. Os softwares servidores aceitam requisições dos softwaresclientes, fazem o processamento e retornam o resultado para os softwares clientes. O clienteeventualmente pode manipular os dados e finalmente apresentar os resultados ao usuário final.(Stallings, 1998; Renaud, 1994)Para Stallings (1998), há 4 tipos de sistemas cliente-servidor:▪ Processamento baseado em host central;▪ Processamento baseado em servidor;▪ Processamento baseado em cliente;▪ Processamento cooperativo;
  25. 25. 24No Processamento baseado em host, todo o processamento é feito no host central, queneste caso é tipicamente aplicados aos ambientes com mainframes. No processamentobaseado em servidor, normalmente é configurado um ambiente onde o cliente tem umainterface gráfica para acessar os recursos, mas praticamente todo o processamento é feito noservidor (que não seja um mainframe). No processamento baseado em cliente, o ambiente éjustamente o oposto do processamento baseado em servidor, ou seja, todo o processamento éfeito no cliente. No processamento cooperativo, o processamento é distribuído entre cliente eservidor.2.3.2 Sistemas Peer-to-Peer (P2P)Sistemas Peer-to-Peer (P2P) são caracterizados pela estrutura não hierárquica comocitado anteriormente (item 2.3). Sendo assim, para alcançar tal objetivo, qualquer sistema P2Pdeve ser cliente e servidor ao mesmo tempo e por isso, o host se torna autônomo. Estaconfiguração de software onde cliente e servidor estão no mesmo software é denominadaservente. (Tanenbaum; Steen, 2007) Sistemas P2P tem as seguintes características gerais(Buford et al. 2009):▪ Auto-organização▪ Comunicação simétrica▪ Controle distribuídos▪ Compartilhamento de recursos▪ Escalabilidade▪ Resiliência (tolerância a falha)A auto-organização ocorre através da forma como as redes P2P são projetadas.Geralmente, independente de uma rede P2P ser estruturada ou não, todo host que se conecta arede ganha um número de identificação único e em conjunto com outras característicasespecificadas pelo desenvolvedor de cada modelo de rede P2P, como agrupamento de hostspor menor distância e outros parâmetros do tipo que em conjunto estabelecem a auto-organização de uma rede P2P. Também através da auto-organização da rede P2P, a dinâmica
  26. 26. 25de entrada e saída de hosts na rede, denominada churn, é minimizada no intuito de nãodificultar os mecanismos de tolerância a falhas e escalabilidade. A comunicação simétrica épredominante nas redes P2P por que os hosts de uma rede P2P trocam mensagens entre sidiretamente. O controle distribuído ocorre por que todo host é uma entidade autônoma, onde ocontrole é totalmente granular, ou seja, cada host tem as mesmas capacidades e o controlepode ser feito individualmente para cada host da rede P2P. O compartilhamento é outracaracterística inerente aos sistemas P2P, já que todos os hosts cooperam mutuamente para osistema doando processamento, disponibilizando arquivos e etc. A escalabilidade também é,em realidade, uma característica derivada do compartilhamento de recursos e da auto-organização, uma vez que todos os hosts da rede colaboram com o sistema e assim, o sistematodo se torna escalável. O desempenho de um sistema baseado em redes P2P está intimamenterelacionado com a escalabilidade e é condicionada a forma na qual a ligação (topologia) entreos hosts é feita. Idealmente, um sistema P2P deveria ter seus hosts dispostos na forma de umgrafo (conjunto de objetos interconectados, neste caso, um conjunto de computadoresinterconectados pela rede) misto com partes de um grafo completo ou grafo regular (figura03) e um grafo totalmente aleatório em forma de anel (Oram, 2001), desta forma, são evitadasas dificuldades de busca (seja ela qual for, largura ou profundidade), de roteamento e o churn(dinâmica de entrada e saída de hosts de uma rede P2P). A resiliência ou tolerância a falhas(abordada com mais profundidade no item 2.4) é uma conseqüência derivada da auto-organização e do controle distribuído das redes P2P e procura diminuir todas as causas quepossam impactar na estabilidade da rede P2P.Figura 03 – Grafo regular a esquerda e grafo completo a direitaAinda sobre a resiliência, foram detectadas as seguintes vulnerabilidades em sistemasGrafo regular(grau 1, 4 nós)Grafo completo (k5)
  27. 27. 26P2P (Endle; Khan, 2006): (i) Distributed Denial Of Service (DDOS); (ii) Man in the MiddleAttack (MITM); (iii) ataque Racional; (iv) ataque Sibila (Sybil Attack); (v) ataque Eclipse.O Distributed Denial Of Service (DDOS) é um tipo de ataque onde vários hosts tentamacessar o mesmo servidor ao mesmo tempo, procurando assim derrubar o servidor e por issose chama Denial Of Service (Negação de serviço). Ressalta-se que apesar deste tipo decomportamento ser considerado uma forma de ataque, em aplicações de grande porte, comoum grande portal na web, detectar este tipo de ataque é difícil, já que não há uma diferençaclara entre o ataque e uma sobrecarga sazonal devido a outras situações. O Man in the MiddleAttack (MITM) é um tipo de ataque onde alguém intercepta os dados de dois ou mais hosts semantendo invisível. Desta forma, os dados coletados podem ser utilizados para diversos fins.O Ataque Racional é um ataque particular das redes P2P. Neste ataque, os participantes darede P2P procuram se utilizar ao máximo da rede P2P sem cooperar com o resto da rede. Oataque Sibila, do inglês Sybil attack, é também um tipo de ataque particular das redes P2P.Neste ataque, o atacante forja a identidade de N outros hosts, procurando ganhar uma parte darede. O ataque Eclipse é outro ataque típico de redes P2P. Nele, o atacante procura fragmentara rede em duas partes e controlar a troca de mensagens entre os lados.A perspectiva histórica das redes P2P tem três fases (gerações) até o momento (2010),como segue. A primeira geração de sistemas P2P surgiu com o Napster, primeiro softwarebaseado em redes P2P a ser utilizado em larga escala. A segunda geração de sistemas P2Psurgiu com a chegada dos softwares Kazaa, Gnutella e Freenet. A terceira geração de sistemasP2P é caracterizada pela verificação formal das redes P2P através da modelagem por grafos ea criação do conceito de DHT (Distributed Hash Table ou Tabela de Hash Distribuídas) etambém pelo desenvolvimento de middlewares na forma redes de sobreposição – overlaynetworks. Seus principais expoentes são os middlewares Pastry, Chrod, CAN e Kademlia.Os sistemas P2P estão classificados em duas formas de organização: Sistemas P2P nãoestruturados e Sistemas P2P estruturados. Os sistemas P2P não estruturados não tem umaarquitetura padrão de comunicação e comumente envolvem técnicas que criam uma soluçãohíbrida onde parte da comunicação entre hosts é Peer-to-Peer (comunicação simétrica) e outraparte é cliente-servidor (comunicação assimétrica). Sendo que os hosts que fazem a parteservidor desta comunicação cliente-servidor, são denominados superpeers. Nos sistemasestruturados, há o que é considerado o estado da arte em termos de redes P2P denominadoDHT (Distributed Hash Table ou Tabelas de Hash Distribuídas). O Objetivo das DHTs é
  28. 28. 27procurar organizar a configuração da rede de forma ótima em termos de distribuição de hostsatravés da modelagem de grafos e outros métodos matemáticos para alcançar a confiabilidade,a escalabilidade, a tolerância a falhas, o balanceamento de carga e a sobreposição (overlay) derede. A sobreposição (overlay network) é uma rede virtual que funciona sobre outra redequalquer e pode ser gerenciada independentemente, nas DHT, a sobreposição é umacaracterística da rede e provê meios para facilitar a busca, o roteamento e a distribuição derecursos. A sobreposição pode ser criada de vários modos, o sistema P2P CAN – ContentAdrressable Network se utiliza do plano cartesiano, já o Chrod e o Pastry, utilizam um modelobaseado em grafos regulares em forma de anel e o Kademlia utiliza o “ou exclusivo”. Outrosmiddlewares P2P se utilizam das mais variadas técnicas que vão desde o anel (grafo regular),até modelagens híbridas (dois ou mais modelos misturados). Na tabela 01, é demonstrada aeficiência em termos de busca de dados e encaminhamento de mensagens entre hosts atravésda contagem de saltos pelo tipo de técnica.Tabela 01 – Contagem de saltos por tipo de técnica(Fonte: Distributed Hash Tables in P2P Systems – A literary survey)Tipo de roteamento Média de salto (hop) Saltos intermediáriosXOR (Kademlia) 7,7 8Anel (Chrod) 7,4 7Árvore (Tapestry) 7,7 8Híbrida 7,7 82.4 Métodos de Alta Disponibilidade e Tolerância a falhasA Alta disponibilidade procura minimizar a interrupção de serviços, enquanto atolerância a falhas procura contornar falhas através de uma série de conceitos e técnicas quetem o intuído de minimizar o downtime e por conseguinte, melhorar a alta disponibilidade.Ambos os termos fazem parte de um conjunto de conceitos e práticas denominadadependabilidade. Dependabilidade é a propriedade do sistema que integra atributos comoconfiabilidade, disponibilidade, segurança, sobrevivência e manutenção. Ainda de acordo comAvizienis et al (2001), há a árvore da dependabilidade que prevê os atributos (attributes), osmeios (means) e ameaças (threats), como disposta na figura 04.
  29. 29. 28Os atributos (attributes) são características desejáveis em um sistema distribuído. Sãoprevistos os seguintes atributos: (i) disponibilidade; (ii) confiabilidade; (iii) segurança; (iv)confidencialidade; (v) integridade (vi) manutenção.A disponibilidade diz respeito a prontidão do serviço de forma correta; aconfiabilidade diz respeito a continuidade do serviço de forma correta; a segurança dizrespeito as conseqüências catastróficas aos usuários e ao ambiente; a confidencialidade dizrespeito a proteção de informações; a integridade diz respeito ao estado do sistema, de formaque o mesmo, não seja alterado; a manutenção diz respeito a capacidade de correção epossível modificação do sistema mediante novas regras de negócios.Os meios (means) abordam quatro itens: (i) prevenção de falta; (ii) tolerância a falta;(iii) remoção de falta; (iv) previsão de falta.A prevenção de falta diz respeito a ocorrência ou introdução de faltas; a tolerância afalta está relacionada a entrega correta do serviço mesmo em caso de falta; a remoção de faltadiz respeito a redução do número ou severidade de faltas; a previsão de falta diz respeito aestimativa de quando e como o sistema pode falhar (MTBF);As ameaças cobrem três áreas: (i) as faltas; (ii) os erros; (iii) as falhas. A falta dizrespeito as situações que causam erro. O erro diz respeito a situações de não conformidade doobjetivo em relação ao software; A falha diz respeito a uma causa de erro.Novamente, de acordo com Avizienis et al (2001), há os seguintes tipos de falhas: (i)falhas de domínio; (ii) falhas relacionada a percepção de dois ou mais usuários; (iii) falhasrelacionadas a conseqüências no ambiente (figura 05).Figura 04 – Árvore da dependabilidade(Fonte: Fundamental Concepts of Computer System Dependability, 2001)
  30. 30. 29Figura 05 – Tipos de falhas de um sistema(Fonte: Fundamental Concepts of Computer System Dependability, 2001)Para evitar todas estas possíveis falhas, faltas e erros, deve-se explorar os seis atributospropostos na árvore da dependabilidade.A seguir, são apresentadas diversas configurações propostas em (Marcus; Stern, 2000)para alcançar a disponibilidade e confiabilidade, duas das características mais relevantes parasistemas P2P de larga escala.Há dois tipos de configurações para alta disponibilidade e confiabilidade, asconfigurações assimétricas, onde um ou mais hosts servem o ambiente de produção, enquanto,um ou mais hosts estão em standby (estado de espera para entrar em operação quando algumservidor cair), já na configuração simétrica, os hosts sempre trabalham em conjunto, ou seja,há uma distribuição de carga entre os hosts. Além das configurações assimétricas e simétricas,o software denominado heartbeat que troca mensagens entre os servidores e assim que um oumais servidores caiem, o heartbeat coloca os servidores que estavam em standby emprodução. A seguir, são apresentadas algumas das configurações mais utilizadas (Marcus;Stern, 2000).Figura 06 – Configuração 1 para 1 assimétrica(Fonte: Blueprints for High Availability. 1sted)ServidorEmStandbyHeartbeatRedeServidorPrimário
  31. 31. 30Na configuração 1 para 1 assimétrica, conforme ilustrado na figura 06, o servidorprimário recebe todas as conexões da rede e o servidor em standby somente entra emprodução quando o servidor em standby detecta através do heartbeat que o servidor primárioparou de funcionar de alguma forma.Na configuração n para 1 assimétrica apresentada na figura 07, há dois ou maisservidores em produção enquanto um está em standby, todos os servidores em produção secomunicam com o servidor em standby através do heartbeat, assim, quando qualquer um dosn servidores parar, o servidor em standby entra em produção no lugar do servidor que parou.Figura 07 – Configuração n para 1 assimétrica(Fonte: Blueprints for High Availability. 1sted)Na configuração 1 para 1 simétrica, ilustrada na figura 08, o servidor primário divide acarga com o servidor secundário, estabelecendo um mecanismo de balanceamento de cargaentre os servidores.ServidoremStandbyHeartbeatRedeServidor1Servidor2Servidor3HeartbeatHeartbeat
  32. 32. 31Figura 08 – Configuração 1 para 1 simétrica(Fonte: Blueprints for High Availability. 1sted)Na configuração round-robin de n servidores apresentada com quatro servidores nafigura 09, as requisições da rede são distribuídas uma por vez para cada um dos quatroservidores.Figura 09 – Configuração round-robin com 4 servidores(Fonte: Blueprints for High Availability. 1sted)ServidorSecundárioHeartbeatRedeServidorPrimárioServidor2HeartbeatRedeServidor1Servidor3HeartbeatServidor4Heartbeat Heartbeat
  33. 33. 32CAPÍTULO 3 – MATERIAIS E MÉTODOSNeste capítulo é mostrada a solução proposta para o monitoramento de servidores,seus componentes de software empregados, bem como o cenário estratégias utilizando estescomponentes.3.1 Solução propostaA solução P2PMON é composta por quatro softwares: P2PMON, o P2PMONWEB eos coletores de dados para os sistemas operacionais Microsoft Windows e GNU/Linux.O P2PMON é a parte do software que efetivamente implementa o monitoramento deservidores utilizando a rede P2P não estruturada. Sendo que os coletores de dados para ossistemas operacionais Microsoft Windows e GNU/Linux fazem a coleta de dados para oP2PMON. Já o P2PMONWEB é a parte do software que fornece a interface WEB. Aarquitetura da solução P2PMON completa é demonstrada na figura 10.Figura 10 – Arquitetura do P2PMON e P2PMONWEBO P2PMON é composto pelos seguintes componentes: Coleta de Dados, SocketCliente, Serviço e Bando de Dados.A coleta de Dados é executada através de uma thread lançada a cada x segundos, ondex é um valor configurado no arquivo de propriedades config.txt.BancodeDadosInterface WEBJSP + Servlet + YUIP2PMONWEBServiço→ DB2JSON→ Coleta de DadosP2PMONServiço→ DB2JSON→ Coleta de DadosP2PMON
  34. 34. 33Após a coleta de dados, os mesmos são armazenados no banco de dados. Até omomento, os seguintes coletores de dados estão implementados (coletores de dados que foramcriados tendo como critério a lista de serviços embutidos por padrão no sistema operacional):▪ Processo – carga de CPU▪ RAM/swap – quantidade de RAM/swap livre e utilizada▪ Disco – localização física do disco, ponto de montagem, quantidade de espaçoem disco livre/ocupada▪ ApacheHTTP – verifica se o servidor web apache está em execução, não estáem execução ou não está instalado▪ MySQL – verifica se o servidor de banco de dados MySQL está em execução,não está em execução ou não está instalado▪ Oracle-xe – verifica se o servidor de banco de dados Oracle Express está emexecução, não está em execução ou não está instalado▪ Cron – verifica se o sistema de agendamento de tarefas está em execução, nãoestá em execução ou não está instalado (somente GNU/Linux)▪ CUPS – verifica se o servidor de impressão CUPS está em execução, não estáem execução ou não está instalado (somente GNU/Linux)▪ Postfix – verifica se o servidor de e-mail Postfix está em execução, não está emexecução ou não está instalado (somente GNU/Linux)▪ Rsync – verifica se o sistema de sincronização de dados está em execução, nãoestá em execução ou não está instalado▪ DHCP – verifica se o servidor DHCP nativo do Microsoft Windows Serverestá em execução, não está em execução ou não está instalado (somenteMicrosoft Windows)▪ DNS – verifica se o servidor DNS nativo do Microsoft Windows Server estáem execução, não está em execução ou não está instalado (somente MicrosoftWindows)▪ IIS – verifica se o software de gerenciamento do servidor web IIS – InternetInformation System está em execução, não está em execução ou não estáinstalado (somente Microsoft Windows)
  35. 35. 34▪ POP3 – verifica se o servidor pop3 (e-mail) nativo do Microsoft WindowsServer está em execução, não está em execução ou não está instalado (somenteMicrosoft Windows)▪ SMTP – verifica se o servidor SMTP (e-mail) nativo do Microsoft WindowsServer está em execução, não está em execução ou não está instalado (somenteMicrosoft Windows)▪ SNMP – verifica se o servidor SNMP nativo do Microsoft Windows Serverestá em execução, não está em execução ou não está instalado (somenteMicrosoft Windows)▪ Terminal Service – verifica se o servidor Terminal Service nativo do MicrosoftWindows Server está em execução, não está em execução ou não está instalado(somente Microsoft Windows)O Gerenciamento de Serviço é uma thread que monitora possíveis ações do usuáriopara iniciar, parar ou verificar o status do P2PMON.O gerenciamento de serviço é baseado no mesmo conceito de serviço advindos dossistemas UNIX, onde cada serviço (software que provê algum tipo de recurso de formaininterrupta) são iniciados pelos comandos start, stop e status. Seguindo a mesma filosofia detrabalho, o P2PMON portanto, funciona da mesma forma utilizando os parâmetros start, stop,status e help. É importante ressaltar que também estão disponíveis alguns scripts wrapper quefacilitam a integração entre o P2PMON e o sistema operacional Microsoft Windows eGNU/Linux, também estão em desenvolvimento scripts wrapper para outros sistemasoperacionais como IBM AIX, Oracle Solaris e FreeBSD). O Banco de dados é umcomponente independendo o P2PMON que é responsável pela persistência de dados atravésdas operações de inserção, atualização, consulta e remoção de dados gerados pelo P2PMON(estereótipo <<CRUD>> da UML).O P2PMONWEB é composto pela interface WEB (YUI + JSP + Servlet) quedisponibiliza de forma amigável os dados coletados do P2PMON e a lista deproblemas/incidentes em cada servidor cadastrado bem como alguns detalhes dos recursosdestes servidores.A seguir, são demonstras a máquina de estados finitos do P2PMON (figura 11) e arede do P2PMON (P2P) em comparação com a rede do HQ Hyperic (cliente-servidor) (figura
  36. 36. 3512). A máquina de estados finitos demonstra que o P2PMON é baseado na idéia de serviço,sendo possível controlar o P2PMON em tempo de execução (software em execução) atravésdos comandos start, stop, status e help (ou nulo que também exibe a tela de ajuda na linha decomando). Mesmo em caso de erro, o comportamento do P2PMON é conhecido por se tratarde uma transição de estado planejada, neste caso, o P2PMON lança a exceção, vai para oestado stop e finalmente, é finalizado.Figura 11 – Máquina de estados finitos do P2PMONFigura 12 – P2PMON (P2P) x HQ Hyperic (cliente-servidor)Na figura 12 é demonstrado um comparativo da topologia de rede P2P do P2PMONP2PMON (P2P) HQ Hyperic (cliente-servidor)
  37. 37. 36(esquerda) com a topologia de rede cliente-servidor do HQ Hyperic (direita). Esta figuramostra claramente que o modelo cliente-servidor sobrecarrega o nó central, enquanto, natopologia proposta pelo P2PMON baseada em P2P, os nós distribuem a carga entre eles eainda podem repassar para um nó central, sendo que nesta situação seria interessante repassarestes dados coletados para algum sistema de gerenciamento de chamados como o OpenTrouble Ticket System (http://otrs.org/).3.2 Componentes de Software UtilizadosForam utilizados os seguintes componentes de softwares para o desenvolvimento destetrabalho:• Sistema operacional GNU/Linux, distribuição Kubuntu 10.04• Sistema operacional Microsoft Windows Server 2003• Java Development Kit (JDK) 1.6• Visual Basic 6• Shell Script• O ambiente de desenvolvimento Netbeans 6.9.1• Ferramenta de modelagem de banco de dados MySQL WorkBench• Banco de dados MySQL• Java Server Pages (JSP) e Servlets• Framework Yahoo! User Interface (YUI) 2.8• Servidor de aplicações Web Tomcat 6• Sistema de controle de versão Git• Sistema de captura de pacotes de rede Wireshark• Sistema de monitoramento de processos da JVM• Sistema de monitoramento de servidores HQ HypericO sistema operacional GNU/Linux (Kubuntu 10.04) foi escolhido para demonstrar aspossibilidades em termos de portabilidade dos softwares P2PMON, P2PMONWEB. Valeadicionar que, devido às semelhanças técnicas entre o sistema operacional GNU/Linux e
  38. 38. 37outros sistemas operacionais totalmente aderentes ao padrão Portable Operating SystemInterface for uniX (POSIX), os softwares P2PMON, P2PMONWEB e os coletores de dadospara o sistema operacional GNU/Linux devem funcionar sem qualquer problema, necessitamde ajustes mínimos (path para os binários e o acesso ao PID) para funcionar adequadamenteem qualquer outro sistema totalmente aderente ao padrão POSIX.O sistema operacional Microsoft Windows Server 2003 foi escolhido por que é osistema operacional mais utilizado mesmo em nível de servidores. (ZDNET, 2010) O JavaDevelopment Kit 1.6 (JDK 1.6) e portanto, a linguagem Java é utilizada pela sua portabilidade(filosofia Write Once, Run Anywhere), extensão (diversos recursos disponíveis no pacotepadrão), orientação a objetos, além da utilização em larga escala (TIOBE, 2010).O Visual Basic 6 é um ambiente de desenvolvimento de software para o sistemaoperacional Microsoft Windows e pelo fato de ser desenvolvido pela própria Microsoft, oambiente Visual Basic 6 permite fácil utilização e integração dos recursos do sistemaoperacional Microsoft Windows e por isso, o Visual Basic 6 é utilizado para desenvolver oscoletores de dados para o sistema operacional Microsoft Windows.O Shell Script é uma linguagem scripting que se utiliza dos próprios comandosfornecidos pelo sistema operacional para resolver problemas. No caso do presente projeto,foram desenvolvidos shell scripts para realizar a coleta de dados no sistema operacionalGNU/Linux (distribuição Kubuntu 10.04).O Netbeans 6.9.1 é um ambiente de desenvolvimento de software que facilita odesenvolvimento de softwares na linguagem de programação Java e, portanto, a ferramentafoi utilizada para o desenvolvimento dos softwares P2PMON e P2PMONWEB.O banco de dados MySQL foi escolhido pela facilidade e simplicidade, além de teruma grande base de usuários corporativos e desenvolvedores. Mais uma vez, ressalta-se queos scripts desenvolvidos para o modelo do banco de dados podem ser carregados em outrosbancos de dados como Microsoft SQL Server ou Oracle Enterprise 11g, sendo necessáriaspoucas modificações nos scripts SQL.O Servlet é uma extensão da linguagem Java desenvolvida especificamente paratrabalhar com a WEB através do protocolo HTTP, permitindo assim, o desenvolvimento deaplicações WEB dinâmicas. O JSP é uma extensão do Servlet que facilita o desenvolvimentode aplicações WEB dinâmicas utilizando programação explícita Java dentro de páginasHTML. Os Servlets e JSPs foram utilizados para desenvolver a aplicação WEB
  39. 39. 38P2PMONWEB que fornece um meio amigável para o monitoramento online de servidores.O framework YUI foi utilizado em conjunto com JSP e Servlets para odesenvolvimento da página web porque tem diversos componentes prontos para uso, testadosem larga escala (já que o próprio Yahoo o utiliza) e também por ser software livre (YUI2,2006).O servidor de aplicação Apache Tomcat 6 é uma plataforma na qual asimplementações do Servlet e JSP rodam, permitindo assim, que aplicações WEB dinâmicassejam desenvolvidas na linguagem Java. (Apache Foundation, 2010)O Git é um software para controle de versões de software e está sendo utilizado emconjunto com a plataforma de desenvolvimento colaborativo GitHUB, para o gerenciamentode versões de software, permitindo um controle preciso do código-fonte produzido dossoftwares P2PMON, P2PMONWEB e coletores de dados para os sistemas operacionaisGNU/Linux e Microsoft Windows. (Git, 2010)O Wireshark é um analisador de pacotes de rede livre (GNU GPL) e foi utilizado parainvestigar a utilização de banda dos softwares P2PMON e HQ Hyperic. (Wireshark, 2010)O JvisualVM é uma ferramenta que monitora a utilização de recursos do sistema parasoftwares desenvolvidos exclusivamente em Java. A JvisualVM faz parte do JDK 1.6 da SUNO HQ Hyperic é um sistema de monitoramento de servidores livre (licença GNU GPL,a mesma do P2PMON) e foi utilizado para dar alguma referência de um sistema demonitoramento real, utilizado em larga escala, além disso, outra característica importante é ofato de o HQ Hyperic ser desenvolvido em Java, da mesma forma que o P2PMON. Éimportante considerar que o HQ Hyperic é baseado no conceito de cliente-servidor (item 2.3.1Sistemas cliente-servidor). (Hyperic, 2010)3.3 Hardwares utilizadosPara o desenvolvimento e testes da ferramenta de monitoramento P2PMON, ainterface WEB P2PMONWEB e coletores de dados para os sistemas operacionais MicrosoftWindows e GNU/Linux utilizaram-se três microcomputadores com as seguintesconfigurações:▪ Intel Pentium 4, 1Gb de RAM, 100Gb de disco rígido, Windows Server 2003▪ Intel Pentium Core 2 duo, 4Gb de RAM, 640Gb de disco rígido, GNU/Linux,
  40. 40. 39distribuição Linux Mint e Windows Server 2003▪ AMD Phenom 9500 Quad-Core, 8Gb de RAM, 500Gb de disco rígido,GNU/Linux, distribuição Kubuntu 10.04▪ Hub D-link DES-1008D de 8 portas, 10/100mbpsSendo que o microcomputador com o processador AMD Phenom foi utilizado para odesenvolvimento dos softwares P2PMON, P2PMONWEB e os coletores de dados para osistema operacional GNU/Linux, enquanto o microcomputador com o processador IntelPentium 4 foi utilizado para o desenvolvimento dos coletores de dados para o sistemaoperacional Microsoft Windows Server 2003.3.4 Técnicas de engenharia de software utilizadasOs quatro softwares gerados pelo presente trabalho (P2PMON, P2PMONWEB,coletores de dados para o sistema operacional Microsoft Windows e GNU/Linux), foramdesenvolvidos de forma incremental (Pressman, 2006) e todo código gerado foi gerenciadopelo sistema de controle de versões GIT. Como os componentes de softwares P2PMON eP2PMONWEB foram desenvolvidos na linguagem Java, foi possível reutilizar diversasclasses. Assim, através da taxa de reuso de classes, fórmula (1), obtêm-se a porcentagem dereuso das classes desenvolvidas para os softwares P2PMON e P2PMONWEB:(1)Fórmula (1) – Taxa de reuso de classesSendo que, a quantidade de classes em comum é a quantidade de classescompartilhadas entre os softwares P2PMON e P2PMONWEB, 100 representa o espaçoamostral total (100%) e a quantidade total de classes representa a quantidade de classes queperfazem 100%.Além disso, todo o projeto está disponível no site http://exdev.sourceforge.net sob alicença GNU GPL, que permite a redistribuição do software desde que toda e qualquermodificação seja livre também (siga a licença GNU GPL).% reuso=quantidade de classesem comum∗100quantidade total de classes% reuso=30∗10037% reuso≈81.01
  41. 41. 40No intuito de melhorar a qualidade do software, foram utilizados alguns padrões deprojetos (do inglês design patterns). Os padrões de projetos são mecanismos conhecidos ebem testados para resolver determinados problemas. Sua origem vem da arquitetura, atravésdos livros The timeless way of building e A pattern language. (Freeman; Freeman, 2005)O trabalho que efetivamente popularizou o conceito de padrões de projetos foi feitopelo GoF (Gang of Four), um grupo de quatro pesquisadores em desenvolvimento desoftware que escreveram o livro Design Patterns: Elements of Reusable Object-OrientedSoftware. Há diversos tipos de padrões de projetos, entre os principais estão os padrõescriacionais, os padrões estruturais e os padrões comportamentaisOs padrões de projetos criacionais dizem respeito ao processo de criação de objetos, jáos padrões de projetos estruturais dizem respeito ao processo de composição de classes ouobjetos e finalmente, os padrões de projetos comportamentais dizem respeito a forma comoclasses ou objetos interagem e distribuem responsabilidades. (Gamma et al, 1994)Para o presente projeto, foram utilizados os padrões de projetos Model ViewController – MVC, Data Access Object – DAO, Transfer Object – TO.O padrão de projeto MVC (figura 13) é utilizado para separa o software em trêscamadas principais: (i) Model, onde estão a modelagem e manipulação de dados; (ii) View,onde está a visualização do software; (iii) Controller, que coordena o fluxo do software, destaforma, o processo de alteração das interfaces do software é bastante facilitado já que assim, astrês partes do software podem ser modificadas de forma independes sem afetar ou quebrar ocomportamento das duas outras camadas. (Basham; Sierra; Bates, 2005)Figura 13 – Arquitetura do padrão de projeto MVC(Fonte: http://www.geekmantra.com/staticcontent/contentimages/Intro-to-MVC-Struts3.gif)
  42. 42. 41O padrão de projeto Data Access Object – DAO é utilizado para abstrair e encapsularo acesso e manipulação do banco de dados. Assim, o software tem um mecanismo claro,simplificado e separado (camada) para acessar os dados sem necessitar de muitos detalhes oque implica em melhor desacoplamento de componentes de software e portanto, facilitandoconsideravelmente o reuso de componentes. O padrão de projeto DAO é utilizado noP2PMON e no P2PMONWEB para acessar e manipular o banco de dados. (SDN, 2010)O padrão de projeto Transfer Object – TO ou Value Object – VO ou ainda DataTransfer Object – DTO é utilizado para facilitar a manipulação de dados em objetos. Destaforma, ao invés de se acessar diretamente a propriedade ou utilizar os métodos acessórios(getters e setters), o objeto é totalmente populado e então disponibilizado para leitura ouescrita, permitindo assim que haja uma economia de chamadas ao objeto, já que ao invés dechamar os métodos getters e setters ou acessar a propriedade diretamente, apenas umachamada é feita para acessar o objeto. (SDN, 2010) Na figura 14 é apresentado o diagrama decaso de uso (UML) para o P2PMON, contendo cinco processos (atividades) do softwareP2PMON, sendo que iniciar P2PMON, parar P2PMON, obter status P2PMON, obter ajudaP2PMON estão relacionados com o ciclo de vida do P2PMON conforme a figura 11.Figura 14 – Diagrama de Caso de Uso do P2PMONEm seguida, na figura 15, apresenta-se o diagrama de caso de uso do softwareP2PMONWEB, contendo oito processos (atividades). Todas estão relacionadas com autilização da interface WEB.
  43. 43. 42Figura 15 – Diagrama de Caso de Uso do P2PMONWEBNas figuras 16 e 17, é demonstrado o Modelo Entidade-Relacionamento utilizado paraa solução P2PMON e desenvolvido pelo MySQL Workbench.Figura 16 – Modelo do banco de dados parte 1Figura16–Modelodobancodedadosparte1
  44. 44. 43Figura 17 – Modelo do banco de dados parte 2Figura17–Modelodobancodedadosparte2
  45. 45. 443.5 Ambiente de testesPara o ambiente de teste, foram utilizados os sistemas de monitoramento de servidoresP2PMON e HQ Hyperic. Ambos os sistemas de monitoramento foram testado utilizando suasconfigurações padrões. No caso do sistema de monitoramento HQ Hyperic foi instalado tantoo agente HQ Hyperic quanto o gerente (server) HQ Hyperic na mesma máquina por que estaseria uma forma de igualar diferenças entre o P2PMON (P2P, servente) e o HQ Hyperic(cliente-servidor).A configuração do microcomputador utilizado para a coleta de dados foi AMDPhenom 9500 Quad-Core, 8Gb de RAM, 500Gb de disco rígido, GNU/Linux, distribuiçãoKubuntu 10.04 (descrito no item 3.2.2 Hardwares utilizados).A coleta de dados da rede foi feita pelo analisador de pacotes de rede Wireshark com ofiltro tcp.port eq 7080 or tcp.port eq 7443 or tcp.port eq 2099 or tcp.port eq 9093 or tcp.porteq 9432 or tcp.port eq 2144 para o HQ Hyperic agent e server e com o filtro tcp.port eq 3306para o P2PMON por uma hora e meia de forma ininterrupta afim de se projetar a utilizaçãomédia de rede e possivelmente extrair um comportamento de ambos os sistemas demonitoramento. Também foram coletados dados sobre a utilização de CPU e de RAM tantopara o P2PMON quanto para o agente e o gerente HQ Hyperic através software JvisualVMincluso no próprio JDK.Tanto a utilização de CPU e RAM quanto o consumo de banda de rede sãofundamentais em termos de teste porque em uma rede monitorada, uma parte considerável dabanda de rede, de CPU e RAM pode ser utilizada de forma ineficiente se o sistema demonitoramento não tiver o ajuste adequado do intervalo de coleta de dados.Estima-se que entre cinco e dez minutos seja um tempo razoável para fazer a coleta dedados de todos os hosts em monitoramento. Um tempo inferior a cinco minutos pode gerarum consumo ineficiente de banda de rede, CPU e RAM, enquanto um tempo superior a dezminutos pode ser tarde demais para a detecção de problemas. Para os testes, foram utilizadoscinco minutos entre cada coleta de dados.
  46. 46. 45CAPÍTULO 4 – RESULTADOS E DISCUSSÕESNeste capítulo apresentam-se dados coletados via Wireshark (analisador de pacotes derede) e JvisualVM (monitor de processos da JVM). Constatou-se que o P2PMON utiliza emmédia 14 megabytes de RAM e 0.2% de utilização de CPU durante uma hora e meia hora decoleta de dados via JvisualVM (gráfico 01).Gráfico 01 – Porcentagem de CPU utilizada e RAM utilizada no P2PMONNo grafico 02, pode-se constatar que o Hyperic server (gerente, superior esquerdo esuperior direito) tem consumo médio de 125 megabytes de RAM e utiliza 0.4% de CPU.Ainda neste gráfico, o Hyperic agent (agente, inferior esquerdo e inferior direito) temconsumo médio de 25 megabytes e utiliza 0.9% de CPU.Gráfico 02 – Porcentagem de CPU utilizada e RAM utilizada no HQ Hyperic agent/serverA tabela 02 demonstra os dados coletados através do software Wireshark.
  47. 47. 46Tabela 02 – Comparação entre os dados gerados pelo P2PMON e HQ Hyperic agent/serverTotal Capturado P2PMON Hyperic agent/serverPacotes 242236 74990 85646Média pacotes/s 33,66 10,809 11,91Média tamanho pacote 344,88 461,285 186,34Média bytes/s 11607,3 4986,19 2219,42Média Mbit/s 0,09 0,040 0,018Constatou-se que o P2PMON utiliza mais banda de rede que o Hyperic agent eHyperic server juntos. Sobre o fato dos dados do Hyperic agent e Hyperic server estaremjuntos, esta foi uma decisão tomada para procurar igualar as condições do teste uma vez que oP2PMON enquanto software é agente e gerente ao mesmo tempo enquanto o HQ Hyperic temagente e servidor (gerente) separados.Também avaliou-se a facilidade de instalação e os requisitos de software necessáriopara a instalação tanto do P2PMON quanto do HQ Hyperic agent e server. A tabela a seguir(tabela 03) aponta alguns dados desta investigação.Tabela 03 – Requisitos de software, facilidade de instalação e característicasP2PMON Hyperic agent Hyperic serverTamanho do arquivo deinstalação em Mb2,6 129 399Quantidade de comandos parainstalação2 3 3Parâmetros no arquivo deconfiguração13 23 17Banco de dadosQualquer um comdriver JDBC-Qualquer um comdriver JDBCSuporte para plugins Não Sim SimLinguagem de programação doscoletores de dadosQualquer umaJava e C/C++(JNI)-Constatou-se que o P2PMON é muito mais econômico em utilização de CPU e RAMse comparado com o HQ Hyperic sendo o P2PMON consome aproximadamente 9,33 vezes
  48. 48. 47menos RAM e aproximadamente 5,4 vezes menos CPU que o HQ Hyperic agent e server.Mais uma deve-se reiterar que o P2PMON é funcionalmente equivalente ao HQHyperic agent e server juntos e que mesmo que se o P2PMONWEB fosse incluído, a cargagerada pelo servidor de aplicação Apache Tomcat 6, o consumo de RAM é deaproximadamente 25 megabytes não é tão alto quanto o HQ Hyperic server.De acordo com os dados coletados pelo Wireshark, constatou-se que o P2PMON geramenos pacotes de rede, mas com mais dados que o HQ Hyperic agent e server. A diferença daquantidade de pacotes entre o P2PMON e o HQ Hyperic é de 10,656 pacotes. Já a diferençada média de pacotes por segundo é de 1,10. A diferença de tamanho entre os pacotes é de274,945. A diferença da média de bytes por segundo é de 2766,77. A diferença da média demegabits por segundo é de 0,022.Nos requisitos de software, facilidade de instalação e características, observa-se que háuma grande diferença no arquivo de instalação que no P2PMON é de apenas 2,6 Mb,enquanto no HQ Hyperic agent é de 129 Mb e no HQ Hyperic server é de 399 Mb. Após umaanálise nos arquivos de instalação do HQ Hyperic agent e server constatou-se que o HQHyperic agent e server tem tamanho maior por que vem com diversos outros softwares comoo JBoss, a JRE (máquina virtual do Java) e o PostgreSQL embutidos na instalação.A quantidade de comandos utilizado para a instalação e os parâmetros no arquivo deconfiguração são dois itens importantes no processo de instalação e configuração, já quequanto mais complexo ou quanto mais parâmetros, a possibilidade de o usuário configurar deforma incorreta aumenta, além de dificultar a instalação em larga escala (por exemplo, instalar8.000 instâncias do P2PMON é mais rápido e mais simples que instalar 8.000 instâncias doHQ Hyperic para o mesmo ambiente). Foi verificado que em ambas as categorias, o P2PMONé mais vantajoso, demonstrando simplicidade o processo de instalação e configuração.O item banco de dados aborda quais bancos de dados podem ser utilizados pelossoftwares P2PMON e HQ Hyperic agent e server. Em ambos os casos, o driver JDBCdetermina que banco de dados será utilizado mediante prévia configuração. Sendo importantecolocar que o P2PMON utiliza por padrão o banco de dados MySQL enquanto o HQ Hypericutiliza por padrão o banco de dados PostgreSQL.O quesito suporte para plugins diz respeito a formas de estender o software através dobaixo acoplamento entre o núcleo e as outras partes do software. Neste quesito, até omomento, o P2PMON não oferece este recurso embora haja uma proposta de trabalho futuro
  49. 49. 48para implementação de uma arquitetura de plugins. Já o HQ Hyperic agent e server suportamuma arquitetura de plugins, facilitando a agregação de novos recursos tanto ao HQ Hypericagent quanto ao HQ Hyperic server.Finalmente, o item linguagem de programação dos coletores de dados diz respeito apossibilidade de criação de coletores de dados em outras linguagens de programação. Nestequesito, o P2PMON é novamente vantajoso por não tem restrições na utilização da linguagemfacilitando de forma considerável o desenvolvimento de novos coletores de dados. Já o HQHyperic é restrito ao Java e C ou C++ porque trabalha exclusivamente com a JNI (Java NativeInterface), recurso que permite o Java ter acesso ao sistema operacional através de umaespécie de mapeamento de API entre as linguagens C ou C++ e o Java.
  50. 50. 49CAPÍTULO 5 – CONCLUSÕESEste capítulo apresenta as conclusões observadas no presente trabalho, além de sedemonstrar possíveis linhas futuras de pesquisa no intuito de aperfeiçoar a ferramenta demonitoramento P2PMON e seus componentes.5.1 Considerações finaisA partir dos resultados obtidos neste capítulo, pode-se concluir que o P2PMON é maiseficiente que o HQ Hyperic em grande parte dos requisitos, exceto no requisito utilização derede e da arquitetura de plugins. Também deve-se constatar que os softwares HQ Hypericagent e HQ Hyperic server são tecnicamente mais maduros que o P2PMON e este pode seruma explicação para a sobrecarga de RAM e CPU do HQ Hyperic mediante o P2PMON.Também através da análise feita com o software Wireshark, observou-se que ainda hámargem para grandes otimizações na forma de comunicação do P2PMON, entre elas está asugestão de comunicação por threshold (item 5.2, trabalhos futuros) e a diminuição deinstâncias de conexão com o banco de dados, sendo possível implementá-la através do designpattern Singleton. Assim, seria possível ter um ganho em termos de economia de banda derede sensível. E ainda há possibilidade de economia de RAM através de otimizações nosparâmetros do garbage collector e da utilização do JDK GNU GCJ que se mostrou maiseficiente que o JDK oficial da SUN.5.2 ConclusõesDemonstrou-se possível, desenvolver um Sistema de Monitoramento de Servidoresbaseado na arquitetura de comunicação não hierárquica Peer-to-Peer (P2P), a partir daferramenta de software P2PMON e seus componentes, também foi possível esboçar aeficiência da solução proposta através de testes realizados em ambiente real e resultadossatisfatórios obtidos.Naturalmente, há diversas possibilidades de otimização (trabalhos futuros), mas deforma geral o Sistema de Monitoramento P2PMON está de acordo com a proposta original defornecer uma solução de monitoramento que seja capaz de remover o servidor central,
  51. 51. 50também chamado gerente e distribuir o processamento entre os servidores em monitoramento.Desta forma, podem-se diminuir os custos, uma vez que não é necessário manter umservidor exclusivo como ocorria nas soluções cliente-servidor tradicional, oferecendo recursosde forma reativa e proativa para correção de falhas em ambientes computacionais e minimizaro MTBF da infraestrutura.5.2 Trabalhos futurosDentre as linhas de pesquisas futuras, mostram-se úteis as seguintes:• Otimização de desempenho utilizando outros JDKs e técnicas de paralelismo• Suporte ao protocolo SNMP• Suporte para plugins• Suporte para thresholds• Comunicação por threshold• Suporte para ação automática pré-programadaA otimização de desempenho pode se dar através da utilização de outros JDKs, entreeles, o GNU GCJ – Gnu Compiler for Java que possui técnicas de otimização pós-bytecode(GCJ, 2009). Já no paralelismo, é possível criar uma thread para cada coletor de dados,permitindo assim, mais paralelismo na execução da coleta de dados que na solução atual éserial.O suporte ao protocolo SNMP traria a possibilidade de coleta de dados emequipamentos como roteadores, switches, firewalls e mesmo servidores que tenham o agenteSNMP e as MIBs configuradas corretamente. De fato, o protocolo SNMP é um padrãoadotado em grande parte das soluções de monitoramento de redes.O suporte para plugins traria uma grande flexibilidade para o P2PMON. Na realidade,algumas partes do código já são desacopladas. Ainda falta desacoplar as classes Java quemanipulam os dados gerados pelos coletores de dados.O threshold é um recurso que permite que sejam pré-programados os limites inferiorese superiores para um recurso monitorado, por exemplo, o coletor de dados da RAM/swappoderia ser configurado para emitir um alerta quando houver muita memória disponível o que
  52. 52. 51poderia significar dizer que um serviço no servidor não entrou em produção por algum motivo(má configuração, falha na instalação e etc) e também poderia emitir um alerta quando nãohouver memória disponível, já que sistemas operacionais podem matar um ou mais serviçospara liberar RAM e swap.A comunicação por threshold é uma forma de otimização da comunicação entre oshosts, por que o P2PMON emitiria alerta somente se algum host tivesse algum problema ou ousuário (administrador de sistemas) forçasse a atualização dos dados.O suporte para ação automática pré-programada é um recurso correlato ao threshold.Com a ação automática pré-programada seria possível configurar o coletor de dados paraquando algum threshold (limite) for atingido, seja o threshold inferior ou superior, uma açãoautomática é executada no intuito de recuperar o sistema.
  53. 53. 52BIBLIOGRAFIAMARCUS, EVAN; STERN, HAL. Blueprints for High Availability. 1sted. John Wiley &Sons, New York, 2000.COULOURIS, GEORGE; DOLLIMORE, JEAN; KINDBERD, TIM. Sistemas Distribuídos:Conceitos e projeto. 4ª ed. Bookman, São Paulo, 2007.STALLINGS, WILLIAM. Data and Computer Communications. 6thed. Prentice Hall, NewJersey, 2000.CARVALHO, TERESA C. DE M. DE BRITO. Gerenciamento de Redes – Uma abordagemde sistemas abertos. 1ª ed. Makron Books, São Paulo, 1993.MILLER, MARK A. Managing internetworks with SNMP. 2nded. M & T Books, Foster City,1997.NAGIOS, Nagios 3.x Documentation. 2007. Disponível em:http://nagios.sourceforge.net/docs/3_0/toc.html Acesso em: 28 de outubro de 2010.HQ Hyperic, Spring Source Hyperic QuickStart Installation. 2010. Disponível em:http://support.hyperic.com/display/DOC/QuickStart+Installation Acesso em: 28 de outubro de2010.TANENBAUM S., ANDREW. Sistemas Operacionais Modernos. 2ª ed. Pearson PrenticeHall, São Paulo, 2003.APACHE FOUNDATION. Worker – Apache HTTP. 2010. Disponível em:http://httpd.apache.org/docs/2.0/mod/worker.html Acesso em: 11 de outubro de 2010.APACHE FOUNDATION. Apache Tomcat. 2010. Disponível em: http://tomcat.apache.org/Acesso em: 11 de outubro de 2010.SILBERCHARTZ, ABRAHAM; GALVIN, PETER BAER; GAGNE, GREG. OperatingSystem Concepts with Java. 7thed. John Wiley & Sons. 2007.TANENBAUM, ANDREW S.; STEEN, MAARTEN VAN. Sistemas Distribuídos –princípios e paradigmas. 2ª ed. Pearson Prentice Hall, São Paulo, 2007.HEISER, GERNOT; KUZ, IHOR. Distributed Systems Lectures. Disponível em:http://www.cse.unsw.edu.au/~cs9243/lectures/ Acesso em: 11 de outubro de 2010.DATE, Christopher J. Introdução a Sistemas de BANCOS de DADOS. 8ª ed. Editora Campus,Rio de Janeiro, 2004.
  54. 54. 53STALLINGS, WILLIAM. Operating Systems. 3rded. Prentice Hall, New Jersey, 1998.RENAUD, PAUL. Introdução aos Sistemas Cliente/Servidor. 2ª ed. IBPI Press, Rio deJaneiro, 1994.BUFORD, JOHN F.; YU, HEATHER; LUA, KEONG. P2P Networking and Applications. 1sted. Morgan Kaufmann, Burlington, 2009.ORAM, ANDY. Peer-to-Peer: O poder transformador das redes ponto a ponto. 1ª ed.Berkeley, São Paulo, 2001.ENGLE, MARLING; KHAN, JAVED I. Vulnerabilities of P2P Systems and a Critical Lookat their Solutions. Disponível em: http://www.medianet.kent.edu/techreports/TR2006-11-01-p2pvuln-EK.pdf Acesso em: 11 de outubro de 2010.TANNER, TIMO. Distributed Hash Tables in P2P Systems – A literary survey. Disponívelem: http://www.tml.tkk.fi/Publications/C/18/tanner.pdf Acesso em: 11 de outubro de 2010.AVIZIENIS, ALGIRDAS; LAPRIE, JEAN-CLAUDE; RANDELL, BRIAN, 2001.Fundamental Concepts of Computer System Dependability. Disponível em:http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88.7354&rep=rep1&type=pdfAcesso em: 11 de outubro de 2010.ZDNET. IDC: Windows Server still rules the server roost. Disponível em:http://www.zdnet.com/blog/microsoft/idc-windows-server-still-rules-the-server-roost/6424Acesso em: 11 de outubro de 2010.TIOBE. TIOBE Programming Community Index for October 2010. Disponível em:http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html Acesso em: 11 de outubrode 2010.YUI 2. Yahoo! User Interface Library 2. Disponível em: http://developer.yahoo.com/yui/2/Acesso em: 11 de outubro de 2010.GIT. GIT – Fast Version Control System. Disponível em: http://git-scm.com/ Acesso em: 11de outubro de 2010.WIRESHARK. Wireshark. Disponível em: http://www.wireshark.org/ Acesso em: 11 deoutubro de 2010.HYPERIC. HQ Hyperic. Disponível em: http://www.hyperic.com/ Acesso em: 11 de outubrode 2010.PRESSMAN, ROGER S.. Engenharia de Software. 6ª ed. Mc Graw Hill, São Paulo, 2006.FREEMAN, ERIC; FREEMAN, ELISABETH. Use a Cabeça! Padrões de Projetos (Design
  55. 55. 54Patterns). 1ª ed. Alta Books, Rio de Janeiro, 2005.GAMMA, ERIC; HELM, RICHARD; JOHNSON, RALPH; VLISSIDES, JOHN. DesignPatterns Elements o Reusable Object-Oriented Software.1sted. Addison Wesley, Indianapolis,1995.BATES, BEART; SIERRA, KATHY; BASHAM, BRYAN. Use a Cabeça! Servlets e JSP. 1ªed. Alta Books, Rio de Janeior, 2005.SUN DEVELOPER NETWORK. Core J2EE Patterns – Data Access Object. Disponível em:http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html Acesso em:11 de outubro de 2010.SUN DEVELOPER NETWORK. Core J2EE Patterns – Transfer Object. Disponível em:http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html Acesso em: 11de outubro de 2010.GCJ. The GNU Compiler for java – GNU Project – Free Software Foundation (FSF).Disponível em: http://gcc.gnu.org/java/ Acesso em: 11 de outubro de 2010.
  56. 56. 55APÊNDICE A – MANUAL DO P2PMONO P2PMON é um sistema de monitoramento de servidores baseado em redes p2p.A.1 Requerimento de softwarePara a instalação do P2PMON e do P2PMONWEB são necessários os seguintessoftwares:Máquina virtual do Java – Java Runtime Environment (JRE) versão >= 1.5Banco de dados (preferencialmente o MySQL) versão >= 5.0Apache Tomcat versão >= 6.0.29A.2 Requerimento de hardwarePara a instalação do P2PMON e do P2PMONWEB, além dos requisitos necessáriospara a instalação da JRE, do MySQL e do Tomcat, é recomendável pelo menos 256megabytes de RAM e pelo menos 1 gigabyte de espaço livre em disco.A.3 Configuração do Banco de dadosO modelo do banco de dados foi desenvolvido utilizando o software MySQLWorkbench. Para facilitar a migração para outros bancos de dados, toda a modelagem foidesenvolvida utilizando quatro tipos de dados: bit, date, integer e varchar.Os conectores para os bancos de dados Microsoft SQL Server, MySQL, PostgreSQL jáestão inclusos no P2PMON, bastando apenas a configuração no arquivo de configuraçãoconfig.txt.O MySQL em distribuições GNU/Linux precisa de alguns ajustes:1 – a linha bind-address deve ser comentada no arquivo my.cnfde bind-address = 127.0.0.1 para #bind-address 127.0.0.1
  57. 57. 562 – os usuários devem ter acesso permitido através da execução da linha abaixo noconsole do MySQL:GRANT ALL PRIVILEGES ON *.* TO USERNAME@% WITH GRANTOPTION;Mais informações em http://dev.mysql.com/doc/refman/5.1/en/adding-users.html3 – a porta padrão (3306) deve estar aberta no firewallFeito os 3 passos anteriores, é necessário executar o script de criação das tabelas doP2PMON, o arquivo p2pmondbm-data.sql (data indica a data da última versão disponível doscript, no momento é a versão 20101127-1) e em seguida, é necessário executar o script para acarga de dados inicial, o script p2pmondbm-data-load.sql (novamente, data indica a data daúltima versão disponível do script, que atualmente é a versão 20101128-1).Feito isso, a configuração do banco de dados está finalizada.A.4 O arquivo de configuração config.txtO arquivo de configuração config.txt é um arquivo de propriedades que guarda osdados na forma de um hash(par chave=valor). Este arquivo deve ser colocado no diretórioonde o arquivo p2pmon.jar está. A seguir é mostrado um exemplo de configuração do arquivoconfig.txt# Configuração do P2PMON# WebURL → configuração do IP do P2PMONWEB#utilize none quando o P2PMONWEB for localWebURL=127.0.0.1# path do gather, o script que executa os coletores de dados# no linux: gatherpath=/path/para/p2pmon/dc/gather.sh# no windows: gatherpath="c://path//para//p2pmon//dc//gather.bat"# perceba as aspas duplas “ para paths com espaço e a // ao invés de ou GatherPath=/home/netto/Desktop/p2pmon/dc/gather.sh# IP do host que receberá as mensagens, pode ser nonePeerHost=none# O intervalo entre as coletas de dados em segundos
  58. 58. 57IntervalDC=5# O driver de conexão com o banco de dados, neste caso o MySQL (padrão)DbDriver=com.mysql.jdbc.Driver# A URL de acesso ao banco de dadosDbURL=jdbc:mysql://localhost:3306/# A senha do bando de dadosDbPwd=debian# O esquema do banco de dadosDbSchem=p2pmon# O usuário do banco de dadosDbUser=root# O usuário do P2PMONWEBUsername=admin# A senha do P2PMONWEBUserpassword=admin# O MAC Address da máquina a ser instaladaMacaddr=00:26:18:05:5f:09# O path onde os arquivos no formato JSON devem ser criadosJSonPath=/home/netto/Desktop/p2pmon-web/build/webA.5 Os coletores de dadosOs coletores de dados são pequenos softwares que coletam dados de um sistema. Todocoletor de dados deve ser colocado no diretório dc dentro do diretório onde está o p2pmon.jar.A.6 Utilizando o serviço P2PMON no sistema operacionalO gerenciamento de serviço implementado no P2PMON permite o controle doP2PMON através dos comandos start (iniciar P2PMON), stop (parar P2PMON), status (obterstatus do P2PMON) e help (ajuda).Para iniciar o P2PMON através da linha de comando:java -jar p2pmon.jar start
  59. 59. 58Para parar o P2PMON:java -jar p2pmon.jar stopPara obter o status do P2PMON:java -jar p2pmon.jar statusPara obter ajuda do P2PMON:java -jar p2pmon.jar helpAssim, é possível integrar o sistema de monitoramento do P2PMON em backgroundsem a necessidade de interação com o usuário e de forma transparente ao sistema operacional.A.7 Configurando o P2PMONWEBPara a utilização do P2PMONWEB é necessário instalar o servidor de aplicações JavaApache Tomcat, versão 6.0.29 ou maior e configurar o arquivo p2pmonweb.xmlA.8 Configuração do arquivo p2pmonweb.xmlPara o correto funcionamento do P2PMONWEB é necessário colocar o arquivop2pmonewb.xml dentro do diretório conf que está dentro do diretório do Apache Tomcat. Aseguir, é mostrado um exemplo de configuração do arquivo p2pmonweb.xml<?xml version="1.0" encoding="UTF-8"?><!-- O atributo docBase=”” deve ser ajustado para o path do P2PMONWEBO atributo path=”” não deve ser modificado --><Context antiJARLocking="true" docBase="/home/netto/Desktop/p2pmon-web/build/web"path="/p2pmonweb"/>Utilizando o path=”/p2pmonweb” significa que o usuário acessará o P2PMONWEBda seguinte forma: http://localhost/p2pmonwebA.9 Utilizando o P2PMONWEBPara a visualização dos dados coletados pelo P2PMON, o usuário deve acessar a
  60. 60. 59interface WEB P2PMONWEB. A seguir, são apresentadas explicações sobre as telas doP2PMONWEB e em seguida são apresentadas as 12 telas que compõe o P2PMONWEB.A figura 01 (tela de login) mostra o login, onde o usuário deve digitar o nome deusuário (username) e a senha (password). Para o primeiro login deve- se utilizar o nome deusuário admin e a senha admin. Assim, e possível ter acesso à interface principal eposteriormente adicionar novos usuários.A figura 02 (tela de lista de hosts) mostra a lista de hosts (servidores monitorados),apresentando os seguintes dados: nome do servidor (hostname), IP, local (location, ex:datacenter), usuário (user), sistema operacional (OS), processador (processor), carga média deprocessamento (loadavg), deletar host (deletehost).A figura 03 (tela de adição de hosts) permite adicionar hosts e requer os seguintesdados: nome do servidor (hostname), IP, MAC Address, o sistema operacional éautomaticamente atualizado quando o sistema de coleta de dados é executado pela primeiravez após adicionar o host.A figura 04 (tela de detalhes dos discos rígidos) mostra os detalhes dos discos rígidosdos servidores monitorados. São exibidos os seguintes dados: nome do servidor (hostname),Sistema operacional (OS), localização física do disco (device), ponto de montagem (mountpt), espaço total (total disk) e livre do disco rígido (free disk), data (date).A figura 05 (tela de detalhes da RAM e Swap) mostra os detalhes da RAM e do Swapdos servidores monitorados. São exibidos os seguintes dados: nome do servidor (hostname),sistema operacional (OS), quantidade de RAM total (total RAM) e livre (free RAM),quantidade de Swap total (total Swap) e livre (free Swap), data (date).A figura 06 (tela de detalhes de serviços monitorados no GNU/Linux) mostra osserviços monitorados exclusivamente em servidores GNU/Linux (Cron, CUPS, Postfix,Rsync), além do nome do servidor (hostname) e sistema operacional (OS).A figura 07 (tela de detalhes de serviços multiplataforma) mostra os serviços que sãomultiplataforma como o servidor WEB Apache HTTP, o banco de dados MySQL e OracleExpress (OracleXE).A figura 08 (tela de detalhes de servições monitorados no Microsoft Windows) mostraos serviços monitorados exclusivamente em servidores Microsoft Windows (servidor DHCP,servidor WEB IIS, servidor de e-mail POP3, servidor de e-mail SMTP, servidor de interfacegráfica terminal Service).
  61. 61. 60A figura 09 (tela de lista de usuários) mostra a lista de usuários cadastrados,apresentando os seguinte dados: nome de usuário (user), local (location), permissão paraadicionar host (can add host), permissão para deletar host (can delete host), permissão paraadicionar usuário (can add user), permissão para atualizar usuário (can update user),permissão para deletar usuário (can delete user), atualizar usuário (update user), deletarusuário (delete user).A figura 10 (tela de adição de usuários) permite adicionar usuários e requer osseguintes dados: nome de usuário (username), senha (password) e confirmação de senha(confirm password), permissão para adicionar host (can add host), permissão para deletar host(can delete host), permissão para adicionar usuário (can add user), permissão para atualizarusuário (can update user), permissão para deletar usuário (can delete user).A figura 11 (tela de lista de locais) mostra a lista de locais cadastrados, apresentandoos seguintes dados: nome do local (location), endereço (address), código postal (postal code),cidade (city), país (country), número para contato (contact no), atualizar local (updatelocation) e deletar local (delete location).E finalmente, na figura 12 (tela de adição de locais) permite adicionar locais e requeros seguintes dados: nome do local (location), endereço (address), código postal (postal code),cidade (city), país (country) e número para contato (contact no).
  62. 62. 61Figura01–Teladelogin
  63. 63. 62Figura02–Listadehosts
  64. 64. 63Figura03–Adiçãodehosts
  65. 65. 64Figura04–Detalhesdodiscorígido
  66. 66. 65Figura05–DetalhesdaRAM/Swap
  67. 67. 66Figura06–StatusdosserviçosmonitoradosdeumservidorGNU/Linux
  68. 68. 67Figura07–Statusdosserviçosmultiplataforma
  69. 69. 68Figura08–StatusdosserviçosmonitoradosdeumservidorMicrosoftWindows
  70. 70. 69Figura09–Listadeusuários
  71. 71. 70Figura10–Adiçãodeusuários
  72. 72. 71Figura11–ListadeLocais
  73. 73. 72Figura12–AdiçãodeLocais

×