monografia p2pmon final
TRANSCRIPT
Faculdade de Informática e Administração PaulistaBacharelado em Sistemas de Informação
FIAP
P2PMON: Um Sistema de monitoramento de servidores de rede baseado em comunicação P2P
Geraldo Augusto de Oliveira Netto – RM 60173
São Paulo2010
Faculdade de Informática e Administração PaulistaBacharelado em Sistemas de Informação
FIAP
P2PMON: Um Sistema de monitoramento de servidores de rede baseado em comunicação P2P
Monografia apresentada à Faculdade de Informática e Administração Paulista para obtenção do grau de bacharel em Sistemas de Informação.
Orientador: Prof. Dr. César da Costa Coorientador: Prof. Msc. Alexander Luz Sperandio
São Paulo2010
II
Este trabalho é dedicado à todas as pessoas
que passaram, estão passando e passarão pela
minha vida. Sem vocês, eu seria nada!
III
AGRADECIMENTOS
A 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;
IV
RESUMO
Atualmente (2010) a grande complexidade dos ambientes computacionais
tornam a tarefa dos administradores de sistemas e de redes difíceis. Esta
complexidade requer que o administrador utilize muitas ferramentas de software para
conseguir manter o ambiente sem falhas. Com o uso de sistemas de monitoramento,
este cenário torna-se mais complexo. A complexidade das tarefas dos
administradores também aumenta, já que cada ambiente de monitoramento, muitas
vezes, requer uma nova ferramenta específica para o ambiente.
Este trabalho propõe o desenvolvimento de um sistema de monitoramento de
servidores 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 que
tornaram a ferramenta P2PMON viável.
Uma avaliação da solução proposta é realizada em ambiente de testes. Os
resultados são apresentados em comparativos de tempo e utilização de rede para as
estratégias apresentadas. Além disso, um teste de escalabilidade é executado para
mostrar o comportamento da solução proposta.
Palavras-chave: redes, sistemas distribuídos, cliente-servidor, P2P, monitoramento
V
ABSTRACT
Currently (2010) the great complexity of computing environments make the
task of network and system administrators difficult. This complexity requires the
administrator to use many software tools in order to keep the environment without
failure. Through the use of monitoring systems, this scenario becomes more
complex. The complexity of the tasks of network and system administrators also
increase, once each monitored environment usually requires a new specific tool for
the environment.
This thesis proposes the development of a server monitoring system based on
a non-hierarchical communication architecture called Peer-to-Peer (P2P). The
monitoring tool developed is called herein P2PMON.
Along this thesis it is presented the components and strategies that make the
tool 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 the
strategies presented. In addition, a scalability test is performed to show the behavior
of the proposed solution.
Key words: networks, distributed systems, client-server, P2P, monitoring
VI
LISTA DE ILUSTRAÇÕES E GRÁFICOS
Figura 01 – Organização em árvore da SMI...............................................................18
Figura 02 – Ciclo de vida de um processo (máquina de estados finitos)....................20
Figura 03 – Grafo regular a esquerda e grafo completo a direita...............................25
Figura 04 – Árvore da dependabilidade......................................................................28
Figura 05 – Tipos de falhas de um sistema.................................................................29
Figura 06 – Configuração 1 para 1 assimétrica..........................................................29
Figura 07 – Configuração n para 1 assimétrica..........................................................30
Figura 08 – Configuração 1 para 1 simétrica..............................................................31
Figura 09 – Configuração round-robin com 4 servidores...........................................31
Figura 10 – Arquitetura do P2PMON e P2PMONWEB.............................................32
Figura 11 – Máquina de estados finitos do P2PMON................................................35
Figura 12 – P2PMON (P2P) x HQ Hyperic (cliente-servidor)...................................35
Figura 13 – Arquitetura do padrão de projeto MVC...................................................40
Figura 14 – Diagrama de Caso de Uso do P2PMON..................................................41
Figura 15 – Diagrama de Caso de Uso do P2PMONWEB.........................................42
Figura 16 – Modelo do banco de dados parte 1..........................................................42
Figura 17 – Modelo do banco de dados parte 2..........................................................43
Gráfico 01 – Porcentagem de CPU utilizada e RAM utilizada no P2PMON.............45
Gráfico 02 – Porcentagem de CPU utilizada e RAM utilizada no HQ Hyperic
agent/server.................................................................................................................45
VII
LISTA DE FÓRMULAS E TABELAS
Fórmula (1) – Taxa de reuso de classes......................................................................39
Tabela 01 – Contagem de saltos por tipo de técnica...................................................27
Tabela 02 – Comparação entre os dados gerados pelo P2PMON e HQ Hyperic
agent/server.................................................................................................................46
Tabela 03 – Requisitos de software, facilidade de instalação e características...........46
VIII
LISTA DE ABREVIATURAS E SIGLAS
AES Advanced Encryption Standard
ARM Advanced RISC Machine
ASN.1 Abstract Syntax Notation 1
BNF Backus-Naur Form
CAN Content Addressable Network
CSV Comma Separated values
CUPS Common Unix Printing System
DAO Data Access Object
DDOS Distributed Denial Of Service
DHCP Dynamic Host Configuration Protocol
DHT Distributed Hash Table
DNS Domain Name System
DoD Department of Defence
DOS Denial Of Service
DTO Data Transfer Object
GCJ GNU Compiler for Java
GNU GNU is Not Unix
GoF Gang of Four
GPL General Public License
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
IBM International Business Machines
IETF Internet Engineering Task Force
IIS Internet Information Services
IPC InterProcess Communication
IPMI Intelligent Platform Management Interface
ISO International Organization for Standardization
ITIL Information Technology Infrastructure Library
ITU International Telecommunication Union
IX
JDBC Java DataBase Connectivity
JDK Java Development Kit
JNI Java Native Interface
JSON JavaScript Object Notation
JSP JavaServer Pages
JvisualVM Java visual Virtual Machine
JVM Java Virtual Machine
MAC ADDRESS Media Access Control Address
MER Modelo Entidade-Relacionamento
MIB Management Information Base
MIPS Microprocessor without Interlocked Pipeline Stages
MITM Man In The Middle Attack
MTBF Mean Time Between Failure
MTRG Multi Router Traffic Grapher
MVC Model View Controller
NRPE Nagios Remote Plugin Executor
NSCA Nagios Service Check Acceptor
ODBC Open DataBase Connectivity
OID Object IDentifier
OPENNMS OPEN Network Management System
ORG Organization
OSI Open System Interconnection
P2P Peer-to-Peer
P2PMON Peer-to-Peer MONitor
POP3 Post Office Protocol versão 3
POSIX Portable Operating System Interface for uniX
RAM Random Access Memory
RFC Request For Comments
RSA Rivest, Shamir and Adleman
SHA-1 Secure Hash Algorithm 1
SLA Service Level Agreement
SMI Structure of Managed Information
X
SMTP Simple Mail Transfer Protocol
SNMP Simple Network Management Protocol
SQL Structured Query Language
TCP Transmission Control Protocol
TI Tecnologia da Informação
TO Transfer Object
UDP User Datagram Protocol
UML Unified Modelling Language
VO Value Object
XML Extensible Markup Language
XOR eXclusive OR
YUI Yahoo! User Interface
XI
SUMÁRIORESUMO...................................................................................................................IV
ABSTRACT................................................................................................................V
LISTA DE ILUSTRAÇÕES E GRÁFICOS...........................................................VI
LISTA DE FÓRMULAS E TABELAS..................................................................VII
LISTA DE ABREVIATURAS E SIGLAS...........................................................VIII
CAPÍTULO 1 – INTRODUÇÃO.............................................................................13
1.1 INTRODUÇÃO....................................................................................................13
1.2 CONTEXTUALIZAÇÃO.....................................................................................13
1.3 OBJETIVOS.........................................................................................................14
1.4 JUSTIFICATIVA..................................................................................................14
1.5 ORGANIZAÇÃO DO TRABALHO....................................................................15
CAPÍTULO 2 – REVISÃO BIBLIOGRÁFICA....................................................16
2.1 PROTOCOLO.......................................................................................................16
2.1.1 O Protocolo SNMP...........................................................................................16
2.2 PROCESSOS E THREADS.................................................................................20
2.3 SISTEMAS DISTRIBUÍDOS..............................................................................21
2.3.1 Sistemas Cliente-Servidor...............................................................................23
2.3.2 Sistemas Peer-to-Peer (P2P)............................................................................24
2.4 MÉTODOS DE ALTA DISPONIBILIDADE E TOLERÂNCIA A FALHAS.....27
CAPÍTULO 3 – MATERIAIS E MÉTODOS.........................................................32
3.1 SOLUÇÃO PROPOSTA......................................................................................32
3.2 COMPONENTE DE SOFTWARE UTILIZADOS..............................................36
3.3 HARDWARE UTILIZADOS...............................................................................38
3.4 TÉCNICAS DE ENGENHARIA DE SOFTWARE UTILIZADAS....................39
3.5 AMBIENTE DE TESTES.....................................................................................44
CAPÍTULO 4 – RESULTADOS E DISCUSSÕES................................................45
CAPÍTULO 5 – CONCLUSÕES.............................................................................49
5.1 CONSIDERAÇÕES FINAIS................................................................................49
5.2 CONCLUSÕES....................................................................................................49
5.2 TRABALHOS FUTUROS...................................................................................50
XII
BIBLIOGRAFIA.......................................................................................................52
APÊNDICE A – MANUAL DO P2PMON..............................................................55
13
CAPÍTULO 1 – INTRODUÇÃO
Neste capítulo são abordadas a introdução, a contextualização, os objetivos, as
dificuldades encontradas e por fim, a organização do trabalho. Tais tópicos visam a
contextualização para, portanto, facilitam a compreenssão das linhas gerais deste trabalho.
1.1 Introdução
Através do processo de monitoramento, processo este que consiste na obtenção de
informações sobre os elementos de um sistema computacional, as atuais soluções de
monitoramento de servidores (2010), apesar de permitirem aos administradores de ambientes
computacionais (administradores de redes e de sistemas) o gerenciamento de infra-estruturas
de tecnologia da informação mais robustas e flexíveis, implicam na quebra dos processos de
monitoramento empregados por sistemas de monitoramento populares, como, por exemplo, o
Nagios e Zabbix, já que trabalham utilizando o paradigma cliente-servidor e portanto, podem
apresentar dificuldade para lidar com as necessidades do ambiente computacional em
constante adaptação e crescente demanda.
Isto ocorre porque sistemas como esses possuem uma lista fixa de servidores para
contatar quando monitoram os serviços de um ambiente de rede, qualquer migração de um
servidor ou substituição de um hardware defeituoso gera problemas no sistema de
monitoramento sem prévia preparação (estratégia) contingencial. Diferente da solução
proposta, P2PMON que utiliza o paradigma Peer-to-Peer (P2P).
1.2 Contextualização
Com os atuais sistemas de monitoramento (2010), os administradores de redes e
sistemas precisam ajustar manualmente as ferramentas de monitoramento disponíveis para
refletir a situação atual do ambiente. Entretanto, a quantidade de equipamento e serviços sob
sua 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 natural
dos novos ambientes computacionais.
Por causa das características dos sistemas cliente-servidor, que são utilizados nos
14
atuais sistemas de monitoramento (2010), são verificadas algumas dificuldades como: (i)
escalabilidade; (ii) alta disponibilidade; (iii) tolerância a falha. Sendo que usualmente
implementa-se métodos de alta disponibilidade e tolerância a falhas para contornar essas
dificuldades. (Marcus et al; 2000)
Com a abordagem Peer-to-Peer (P2P), as dificuldades em escalabilidade, alta
disponibilidade, tolerância a falha e mesmo segurança são reduzidas com um custo de projeto
de 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 na
comunicação e por fim, dando flexibilidade ao software. (Coulouris et al, 2007)
1.3 Objetivos
Este trabalho tem como objetivo principal desenvolver um sistema de monitoramento
de 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 estas
informações e alcançar escalabilidade, alta disponibilidade, tolerância a falha e segurança, de
forma transparente aos administradores de ambientes computacionais.
1.4 Justificativa
Redes Peer-to-Peer (P2P) tem como característica a escalabilidade, alta
disponibilidade, tolerância a falha e segurança distribuída de forma pervasiva pela rede e de
forma 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 redes
baseadas no modelo cliente-servidor, justamente pelo fato de cada host ter o seu papel
claramente delimitado, características como escalabilidade, alta disponibilidade, tolerância a
falha 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, o
sistema de monitoramento proposto é mais robusto em termos de escalabilidade, alta
disponibilidade, tolerância a falha e segurança. Além disso, através da utilização da linguagem
de programação Java, também é obtida outra vantagem, a alta capacidade de portabilidade,
permitindo que diversos sistemas operacionais possam fazer uso do P2PMON.
15
1.5 Organização do trabalho
O trabalho está dividido em 5 capítulos:
▪ Capítulo 2 apresenta os fundamentos sobre redes de computadores, protocolos
de comunicação e processos. Também são apresentadas as características de
sistemas distribuídos e redes Peer-to-Peer.
▪ Capítulo 3 mostra a solução proposta para o monitoramento de servidores
denominada P2PMON, seus componentes empregados, bem como as
diferentes estratégias utilizando estes componentes.
▪ Capítulo 4 apresenta detalhes e resultados da implementação da solução
proposta 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.
16
CAPÍTULO 2 – REVISÃO BIBLIOGRÁFICA
Neste capítulo são abordados os conceitos e estratégias fundamentais para o correto
entendimento deste trabalho.
2.1 Protocolo
Um protocolo é uma especificação de regras e formatos para a realização da
comunicação entre sistemas. (Stallings, William, 2000) Desta forma, são definidos métodos
de troca de mensagens entre hosts (qualquer computador de qualquer porte conectado a uma
rede). 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 e
por isso, a troca de uma parte da arquitetura do protocolo requer a reimplementação do
protocolo todo. Enquanto, em protocolos estruturados, a arquitetura é baseada em camadas
que 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 ou
hierárquia entre os hosts, como, por exemplo, em um sistema Peer-to-Peer (P2P). Enquanto
nos protocolos assimétricos, há a definição clara de papéis ou hierarquia, como no caso dos
sistemas cliente-servidor e desta forma, a comunicação tem um ciclo bem estabelecido.
2.1.1 O Protocolo SNMP
O 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).
17
O SNMP é um conjunto de especificações que tem por objetivo, oferecer um
framework para o monitoramento de redes (tanto hardware, quanto software) através dos
protocolos TCP e UDP nas portas 161 e 162 (Carvalho, 1993). O protocolo SNMP é composto
por três itens (adaptado de Stallings, 2000):
▪ Dispositivo gerenciado
▪ Agente SNMP
▪ Sistema de monitoramento de redes ou gerente SNMP
O dispositivo gerenciado é o hardware no qual o Agente SNMP é executado. O Agente
SNMP é o software no qual disponibiliza o estado do dispositivo gerenciado através do
protocolo SNMP, sendo que há dois tipos de agente SNMP: (i) sistemas com agente SNMP
standalone; (ii) sistemas sem agente SNMP standalone, também chamados de agentless.
Os agentes SNMP standalone são os sistemas tradicionais onde um software que
implementa uma, duas ou as três versões do protocolo SNMP é instalado a parte, já os
sistemas sem agente SNMP (agentless) dependem do sistema operacional fornecer o suporte
nativo 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 uma
interface amigável ao administrador de redes para visualizar os dados previamente coletados
pelos agentes SNMP.
Para o funcionamento do Agente SNMP e do Sistema de monitoramento de redes, há o
SMI (Structure of Management Information) que é responsável pela organização lógica em
forma de árvore dos dados do agente SNMP.
Cada item (“folha”) dentro desta árvore (figura 01) é chamada de MIB (Management
Information 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 de
monitoramento de redes sobre algum problema de um agente SNMP em tempo real, já que o
protocolo 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 um
objeto da MIB. Por exemplo, a seqüência 1.3.6.1.4.1 representa a árvore padronizada
iso.org.dod.internet.private.enterprise.
18
Figura 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.1
desenvolvidos pela ISO e ITU e são baseadas na Forma Normal de Backus Naur (do inglês
Backus-Naur Form – BNF) que permite estruturar uma gramática livre de contexto, dando
assim, 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 monitoramento
ou gerenciamento de rede. (Carvalho, 1993)
Assim como o protocolo SNMP, também existem padrões para se estruturar o
gerenciamento de rede. O modelo de referência OSI propõe cinco áreas funcionais para os
sistemas de monitoramento de redes: (i) gerenciamento de falhas; (ii) gerenciamento de
19
configuraçã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, propor
correção para as possíveis falhas e faltas do ambiente em monitoramento. O gerenciamento de
configuração tem o objetivo de controlar os ativos da TI na forma de inventário. Assim, pode
dimensionar com mais precisão o ambiente monitorado, além de oferecer possíveis
perspectivas de planos de capacidade futuros. O gerenciamento de desempenho tem o objetivo
de coletar métricas para dimensionar o desempenho dos serviços no ambiente monitorado. O
gerenciamento de segurança tem o objetivo de monitorar e controlar os mecanismos de
segurança no ambiente monitorado. O gerenciamento de contabilização tem o objetivo de
contabilizar, principalmente de forma financeira todo o serviço de monitoramento do
ambiente. Desta forma, é possível, por exemplo, ajustar o SLA (Service Level Agreement).
Em (Miller, 1997) são abordados de forma mais aprofundada a arquitetura dos
sistemas de monitoramento de redes. Usualmente, estes sistemas trabalham com dois ou mais
protocolos, o já conhecido SNMP e um ou mais protocolos que poder ser utilizados para
funções diferentes, como trocar mensagens vindas dos coletores de dados ou executar
comandos remotamente.
Por exemplo, o sistema de monitoramento Nagios (Nagios, 2007), trabalha com o
protocolo SNMP e com outros dois protocolos sendo que cada protocolo tem um objetivo
específico, o NSCA (Nagios Service Check Acceptor) que é um protocolo de coleta de dados e
atua em nível de aplicação (camada sete do modelo de referência OSI) além de trabalhar na
porta 5667 e o NRPE (Nagios Remote Plugin Executor) que é um protocolo para execução de
comandos remotamente e também é um protocolo de aplicação (camada sete do modelo de
referência OSI) e trabalha na porta 5666.
Outros sistemas de monitoramento como o HQ Hyperic (HQ Hyperic, 2010), sistema
de monitoramento cliente-servidor, desenvolvido em Java e comparado com o P2PMON no
capítulo 3, utilizam cinco protocolos, o protocolo HTTP na porta 7080, o protocolo HTTPS na
porta 7443, o protocolo JNP na porta 2099, o protocolo Mbean na porta 9093, o protocolo do
agente HQ Hyperic na porta 2144 e ainda o protocolo do banco de dados PostgreSQL na porta
9432. 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ão
3306, sendo possível a utilização de outro banco de dados mediante configuração.
20
2.2 Processos e Threads
Um software é uma entidade estática que usualmente está alocada em algum
dispositivo 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) Todo
processo é composto por quatro partes: (i) área de código; (ii) área de dados; (iii) status do
processo; (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 de
dados contém o conjunto de dados trabalhos pela área de código, parte destes dados podem
vir da interação com o usuário do software ou de um arquivo, por exemplo. O status do
processo é 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, 7th ed.)
Um processo no estado “novo” ocorre quando o processo acabou de ser carregado para
a memória principal e entrou para a fila de processos do sistema operacional, o que não
necessariamente significa entrar para o estado “pronto” ou “executando” imediatamente. Um
processo no estado “executando” ocorre quando o processo ganha timeslice (tempo para
execução) do escalonador do sistema operacional e efetivamente entra em execução. Um
processo 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 ser
executado. Um processo no estado “finalizado” ocorre quando o processo é finalizado.
Uma das formas de paralelismo em processos ocorre através das threads. Uma thread
Novo Finalizado
Pronto Executando
Esperando
21
é um fluxo de execução, uma seqüência de instruções passíveis de escalonamento. Uma
thread consiste em quatro partes: (i) identificador da thread (Thread ID); (ii) contador do
programa (Program Counter – PC); (iii) registros; (iv) pilha.
Processos que se utilizam de várias threads para criar paralelismo são denominados
multithreaded e podem conter centenas de threads, como no caso do servidor WEB (protocolo
HTTP) Apache. (Apache Foundation, 2010) Processos que não utilizam threads são
denominados single threaded, por que a área de código de um processo também é uma thread
denominada thread primária.
Há três modelos de threads: o modelo M para 1, o modelo 1 para 1 e o modelo M para
N. (Silberchartz; Galvin; Gagne, 2007)
O modelo de threads M para 1 mapeia muitas threads em espaço de usuário para uma
thread em espaço de kernel. Isto implica em possível menor desempenho, já que uma thread
em espaço de usuário pode bloquear as demais threads. Já o modelo de threads 1 para 1
mapeia apenas uma thread em espaço de usuário para uma thread em espaço de kernel. Isto
implica em mais desempenho e paralelismo ao custo de uma sobrecarga cada vez que uma
thread em espaço de kernel é criada. E finalmente, o modelo de threads M para N mapeia M
threads em espaço de usuário para N ou menos threads em espaço de kernel, criando um
modelo de threads misto entre M para 1 e 1 para 1. Isto implica em mais desempenho que o
modelo de threads m para um, porém, menos desempenho que o modelo de threads 1 para 1 e
menos 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 de
threads 1 para 1, enquanto a Java Virtual Machine (JVM) utiliza o mesmo modelo de thread
disponível nativamente no sistema operacional subjacente.
2.3 Sistemas Distribuídos
Um sistema distribuído é aquele no qual os componentes localizados em computadores
interligados 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 de
computadores independentes que são utilizados conjuntamente para executar uma tarefa ou
serviço. Os sistemas distribuídos, em geral, são criados para atender a necessidade de
distribuição e compartilhamento de recursos, custo, desempenho, escalabilidade,
22
confiabilidade e segurança. (Heiser; Kuz, 2010) Além disso, há outras características
desejáveis para o sistema distribuído como a transparência, a interoperabilidade e a
portabilidade.
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 de
software, entre outros. Ainda sobre distribuição e compartilhamento de recursos, uma técnica
muito utilizada é a replicação (cópia) de dados. Os dois tipos de replicações relevantes para o
presente 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 oportunista
no 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 a
propagação de atualizações. (Date, 2004) A replicação síncrona faz a propagação de dados de
forma síncrona, assim, para cada dado manipulado seja inserido, alterado ou removido, o
sistema deve ser capaz de sincronizar imediatamente os hosts ainda não sincronizados e por
isso, podem ocorrer problemas de desempenho já que é inconveniente sincronizar os dados a
todo instante, diferente da abordagem assíncrona. A transparência diz respeito a facilidade de
se 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 aumentar
desempenho e disponibilidade;
▪ Concorrência: recursos são disponibilizados de forma adequada para evitar os
problemas relacionados a concorrência na utilização dos mesmo;
▪ Tolerância a falha: o sistema é capaz de ocultar e tratar a falha procurando
evitar qualquer impacto na utilização do mesmo pelos usuários finais;
O middleware é uma camada de software que faz interface entre dois ou mais
softwares permitindo assim, a transparência de manipulação de dados sem afetar a API. De
acordo com (Coulouris et al, 2007), os sistemas distribuídos tem as seguintes dificuldades
para sua correta implementação: (i) transparência (concorrência, falha, acesso, localização,
23
migraçã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ção
de sistemas heterogêneos. Este mecanismo pode ser implementado de várias formas, seja pela
divisão do software em camadas, seja pela utilização de protocolos e etc. A portabilidade é a
capacidade 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 de
hardware diferentes como ARM, MIPS, x86, entre outras e softwares diferentes como
Microsoft Windows, GNU/Linux, Oracle Solaris e etc. Ainda há duas formas de comunicação
para 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-Servidor
Sistemas cliente-servidor são caracterizados pela comunicação hierárquica onde há um
cliente, software que solicita algum tipo de recurso e um servidor, software que atende as
solicitações dos clientes. Assim, o usuário final tem o processamento da interface gráfica no
cliente e o gerenciamento e armazenamento de dados no servidor. Dependendo da aplicação e
do software usado, todo o processamento de dados podem ocorrer no servidor ou ser dividido
entre o cliente e o servidor. Os softwares servidores aceitam requisições dos softwares
clientes, fazem o processamento e retornam o resultado para os softwares clientes. O cliente
eventualmente 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;
24
No Processamento baseado em host, todo o processamento é feito no host central, que
neste caso é tipicamente aplicados aos ambientes com mainframes. No processamento
baseado em servidor, normalmente é configurado um ambiente onde o cliente tem uma
interface gráfica para acessar os recursos, mas praticamente todo o processamento é feito no
servidor (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 e
servidor.
2.3.2 Sistemas Peer-to-Peer (P2P)
Sistemas Peer-to-Peer (P2P) são caracterizados pela estrutura não hierárquica como
citado anteriormente (item 2.3). Sendo assim, para alcançar tal objetivo, qualquer sistema P2P
deve ser cliente e servidor ao mesmo tempo e por isso, o host se torna autônomo. Esta
configuração de software onde cliente e servidor estão no mesmo software é denominada
servente. (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 a
rede ganha um número de identificação único e em conjunto com outras características
especificadas pelo desenvolvedor de cada modelo de rede P2P, como agrupamento de hosts
por 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
25
de entrada e saída de hosts na rede, denominada churn, é minimizada no intuito de não
dificultar 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 si
diretamente. O controle distribuído ocorre por que todo host é uma entidade autônoma, onde o
controle é totalmente granular, ou seja, cada host tem as mesmas capacidades e o controle
pode ser feito individualmente para cada host da rede P2P. O compartilhamento é outra
característica inerente aos sistemas P2P, já que todos os hosts cooperam mutuamente para o
sistema 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 sistema
todo se torna escalável. O desempenho de um sistema baseado em redes P2P está intimamente
relacionado com a escalabilidade e é condicionada a forma na qual a ligação (topologia) entre
os hosts é feita. Idealmente, um sistema P2P deveria ter seus hosts dispostos na forma de um
grafo (conjunto de objetos interconectados, neste caso, um conjunto de computadores
interconectados pela rede) misto com partes de um grafo completo ou grafo regular (figura
03) e um grafo totalmente aleatório em forma de anel (Oram, 2001), desta forma, são evitadas
as 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 que
possam impactar na estabilidade da rede P2P.
Figura 03 – Grafo regular a esquerda e grafo completo a direita
Ainda sobre a resiliência, foram detectadas as seguintes vulnerabilidades em sistemas
Grafo regular(grau 1, 4 nós)
Grafo completo (k5)
26
P2P (Endle; Khan, 2006): (i) Distributed Denial Of Service (DDOS); (ii) Man in the Middle
Attack (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 tentam
acessar o mesmo servidor ao mesmo tempo, procurando assim derrubar o servidor e por isso
se chama Denial Of Service (Negação de serviço). Ressalta-se que apesar deste tipo de
comportamento ser considerado uma forma de ataque, em aplicações de grande porte, como
um grande portal na web, detectar este tipo de ataque é difícil, já que não há uma diferença
clara entre o ataque e uma sobrecarga sazonal devido a outras situações. O Man in the Middle
Attack (MITM) é um tipo de ataque onde alguém intercepta os dados de dois ou mais hosts se
mantendo 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 da
rede P2P procuram se utilizar ao máximo da rede P2P sem cooperar com o resto da rede. O
ataque 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 da
rede. O ataque Eclipse é outro ataque típico de redes P2P. Nele, o atacante procura fragmentar
a 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 software
baseado em redes P2P a ser utilizado em larga escala. A segunda geração de sistemas P2P
surgiu com a chegada dos softwares Kazaa, Gnutella e Freenet. A terceira geração de sistemas
P2P é caracterizada pela verificação formal das redes P2P através da modelagem por grafos e
a criação do conceito de DHT (Distributed Hash Table ou Tabela de Hash Distribuídas) e
também pelo desenvolvimento de middlewares na forma redes de sobreposição – overlay
networks. 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ão
estruturados e Sistemas P2P estruturados. Os sistemas P2P não estruturados não tem uma
arquitetura padrão de comunicação e comumente envolvem técnicas que criam uma solução
híbrida onde parte da comunicação entre hosts é Peer-to-Peer (comunicação simétrica) e outra
parte é cliente-servidor (comunicação assimétrica). Sendo que os hosts que fazem a parte
servidor desta comunicação cliente-servidor, são denominados superpeers. Nos sistemas
estruturados, há o que é considerado o estado da arte em termos de redes P2P denominado
DHT (Distributed Hash Table ou Tabelas de Hash Distribuídas). O Objetivo das DHTs é
27
procurar organizar a configuração da rede de forma ótima em termos de distribuição de hosts
atravé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) de
rede. A sobreposição (overlay network) é uma rede virtual que funciona sobre outra rede
qualquer e pode ser gerenciada independentemente, nas DHT, a sobreposição é uma
característica da rede e provê meios para facilitar a busca, o roteamento e a distribuição de
recursos. A sobreposição pode ser criada de vários modos, o sistema P2P CAN – Content
Adrressable Network se utiliza do plano cartesiano, já o Chrod e o Pastry, utilizam um modelo
baseado em grafos regulares em forma de anel e o Kademlia utiliza o “ou exclusivo”. Outros
middlewares 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 a
eficiência em termos de busca de dados e encaminhamento de mensagens entre hosts através
da 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ários
XOR (Kademlia) 7,7 8
Anel (Chrod) 7,4 7
Árvore (Tapestry) 7,7 8
Híbrida 7,7 8
2.4 Métodos de Alta Disponibilidade e Tolerância a falhas
A Alta disponibilidade procura minimizar a interrupção de serviços, enquanto a
tolerância a falhas procura contornar falhas através de uma série de conceitos e técnicas que
tem 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 denominada
dependabilidade. Dependabilidade é a propriedade do sistema que integra atributos como
confiabilidade, disponibilidade, segurança, sobrevivência e manutenção. Ainda de acordo com
Avizienis et al (2001), há a árvore da dependabilidade que prevê os atributos (attributes), os
meios (means) e ameaças (threats), como disposta na figura 04.
28
Os atributos (attributes) são características desejáveis em um sistema distribuído. São
previstos 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; a
confiabilidade diz respeito a continuidade do serviço de forma correta; a segurança diz
respeito as conseqüências catastróficas aos usuários e ao ambiente; a confidencialidade diz
respeito a proteção de informações; a integridade diz respeito ao estado do sistema, de forma
que o mesmo, não seja alterado; a manutenção diz respeito a capacidade de correção e
possí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 a
falta está relacionada a entrega correta do serviço mesmo em caso de falta; a remoção de falta
diz respeito a redução do número ou severidade de faltas; a previsão de falta diz respeito a
estimativa 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 diz
respeito as situações que causam erro. O erro diz respeito a situações de não conformidade do
objetivo 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) falhas
relacionadas a conseqüências no ambiente (figura 05).
Figura 04 – Árvore da dependabilidade
(Fonte: Fundamental Concepts of Computer System Dependability, 2001)
29
Figura 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 atributos
propostos 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 para
sistemas P2P de larga escala.
Há dois tipos de configurações para alta disponibilidade e confiabilidade, as
configuraçõ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 algum
servidor 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 ou
mais servidores caiem, o heartbeat coloca os servidores que estavam em standby em
produçã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. 1st ed)
ServidorEm
Standby
Heartbeat
Rede
ServidorPrimário
30
Na configuração 1 para 1 assimétrica, conforme ilustrado na figura 06, o servidor
primário recebe todas as conexões da rede e o servidor em standby somente entra em
produção quando o servidor em standby detecta através do heartbeat que o servidor primário
parou de funcionar de alguma forma.
Na configuração n para 1 assimétrica apresentada na figura 07, há dois ou mais
servidores em produção enquanto um está em standby, todos os servidores em produção se
comunicam com o servidor em standby através do heartbeat, assim, quando qualquer um dos
n 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. 1st ed)
Na configuração 1 para 1 simétrica, ilustrada na figura 08, o servidor primário divide a
carga com o servidor secundário, estabelecendo um mecanismo de balanceamento de carga
entre os servidores.
Servidorem
Standby
Heartbeat
Rede
Servidor1
Servidor2
Servidor3
Heartbeat
Heartbeat
31
Figura 08 – Configuração 1 para 1 simétrica
(Fonte: Blueprints for High Availability. 1st ed)
Na configuração round-robin de n servidores apresentada com quatro servidores na
figura 09, as requisições da rede são distribuídas uma por vez para cada um dos quatro
servidores.
Figura 09 – Configuração round-robin com 4 servidores
(Fonte: Blueprints for High Availability. 1st ed)
ServidorSecundário
Heartbeat
Rede
ServidorPrimário
Servidor2
Heartbeat
Rede
Servidor1
Servidor3
HeartbeatServidor4
Heartbeat Heartbeat
32
CAPÍTULO 3 – MATERIAIS E MÉTODOS
Neste 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 estes
componentes.
3.1 Solução proposta
A solução P2PMON é composta por quatro softwares: P2PMON, o P2PMONWEB e
os coletores de dados para os sistemas operacionais Microsoft Windows e GNU/Linux.
O P2PMON é a parte do software que efetivamente implementa o monitoramento de
servidores utilizando a rede P2P não estruturada. Sendo que os coletores de dados para os
sistemas operacionais Microsoft Windows e GNU/Linux fazem a coleta de dados para o
P2PMON. Já o P2PMONWEB é a parte do software que fornece a interface WEB. A
arquitetura da solução P2PMON completa é demonstrada na figura 10.
Figura 10 – Arquitetura do P2PMON e P2PMONWEB
O P2PMON é composto pelos seguintes componentes: Coleta de Dados, Socket
Cliente, Serviço e Bando de Dados.
A coleta de Dados é executada através de uma thread lançada a cada x segundos, onde
x é um valor configurado no arquivo de propriedades config.txt.
Bancode
Dados
Interface WEBJSP + Servlet + YUI
P2PMONWEB
Serviço→ DB2JSON→ Coleta de Dados
P2PMON
Serviço→ DB2JSON→ Coleta de Dados
P2PMON
33
Após a coleta de dados, os mesmos são armazenados no banco de dados. Até o
momento, os seguintes coletores de dados estão implementados (coletores de dados que foram
criados 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ço
em 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á em
execuçã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ão
está 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á em
execução ou não está instalado (somente GNU/Linux)
▪ Rsync – verifica se o sistema de sincronização de dados está em execução, não
está em execução ou não está instalado
▪ DHCP – verifica se o servidor DHCP nativo do Microsoft Windows Server
está em execução, não está em execução ou não está instalado (somente
Microsoft 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 Microsoft
Windows)
▪ IIS – verifica se o software de gerenciamento do servidor web IIS – Internet
Information System está em execução, não está em execução ou não está
instalado (somente Microsoft Windows)
34
▪ POP3 – verifica se o servidor pop3 (e-mail) nativo do Microsoft Windows
Server está em execução, não está em execução ou não está instalado (somente
Microsoft Windows)
▪ SMTP – verifica se o servidor SMTP (e-mail) nativo do Microsoft Windows
Server está em execução, não está em execução ou não está instalado (somente
Microsoft Windows)
▪ SNMP – verifica se o servidor SNMP nativo do Microsoft Windows Server
está em execução, não está em execução ou não está instalado (somente
Microsoft Windows)
▪ Terminal Service – verifica se o servidor Terminal Service nativo do Microsoft
Windows 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ário
para iniciar, parar ou verificar o status do P2PMON.
O gerenciamento de serviço é baseado no mesmo conceito de serviço advindos dos
sistemas UNIX, onde cada serviço (software que provê algum tipo de recurso de forma
ininterrupta) são iniciados pelos comandos start, stop e status. Seguindo a mesma filosofia de
trabalho, 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 que
facilitam a integração entre o P2PMON e o sistema operacional Microsoft Windows e
GNU/Linux, também estão em desenvolvimento scripts wrapper para outros sistemas
operacionais como IBM AIX, Oracle Solaris e FreeBSD). O Banco de dados é um
componente independendo o P2PMON que é responsável pela persistência de dados através
das 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) que
disponibiliza de forma amigável os dados coletados do P2PMON e a lista de
problemas/incidentes em cada servidor cadastrado bem como alguns detalhes dos recursos
destes servidores.
A seguir, são demonstras a máquina de estados finitos do P2PMON (figura 11) e a
rede do P2PMON (P2P) em comparação com a rede do HQ Hyperic (cliente-servidor) (figura
35
12). 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és
dos comandos start, stop, status e help (ou nulo que também exibe a tela de ajuda na linha de
comando). Mesmo em caso de erro, o comportamento do P2PMON é conhecido por se tratar
de uma transição de estado planejada, neste caso, o P2PMON lança a exceção, vai para o
estado stop e finalmente, é finalizado.
Figura 11 – Máquina de estados finitos do P2PMON
Figura 12 – P2PMON (P2P) x HQ Hyperic (cliente-servidor)
Na figura 12 é demonstrado um comparativo da topologia de rede P2P do P2PMON
P2PMON (P2P) HQ Hyperic (cliente-servidor)
36
(esquerda) com a topologia de rede cliente-servidor do HQ Hyperic (direita). Esta figura
mostra claramente que o modelo cliente-servidor sobrecarrega o nó central, enquanto, na
topologia proposta pelo P2PMON baseada em P2P, os nós distribuem a carga entre eles e
ainda podem repassar para um nó central, sendo que nesta situação seria interessante repassar
estes dados coletados para algum sistema de gerenciamento de chamados como o Open
Trouble Ticket System (http://otrs.org/).
3.2 Componentes de Software Utilizados
Foram utilizados os seguintes componentes de softwares para o desenvolvimento deste
trabalho:
• 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 Hyperic
O sistema operacional GNU/Linux (Kubuntu 10.04) foi escolhido para demonstrar as
possibilidades em termos de portabilidade dos softwares P2PMON, P2PMONWEB. Vale
adicionar que, devido às semelhanças técnicas entre o sistema operacional GNU/Linux e
37
outros sistemas operacionais totalmente aderentes ao padrão Portable Operating System
Interface for uniX (POSIX), os softwares P2PMON, P2PMONWEB e os coletores de dados
para o sistema operacional GNU/Linux devem funcionar sem qualquer problema, necessitam
de ajustes mínimos (path para os binários e o acesso ao PID) para funcionar adequadamente
em qualquer outro sistema totalmente aderente ao padrão POSIX.
O sistema operacional Microsoft Windows Server 2003 foi escolhido por que é o
sistema operacional mais utilizado mesmo em nível de servidores. (ZDNET, 2010) O Java
Development 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 pacote
padrã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 sistema
operacional Microsoft Windows e pelo fato de ser desenvolvido pela própria Microsoft, o
ambiente Visual Basic 6 permite fácil utilização e integração dos recursos do sistema
operacional Microsoft Windows e por isso, o Visual Basic 6 é utilizado para desenvolver os
coletores de dados para o sistema operacional Microsoft Windows.
O Shell Script é uma linguagem scripting que se utiliza dos próprios comandos
fornecidos pelo sistema operacional para resolver problemas. No caso do presente projeto,
foram desenvolvidos shell scripts para realizar a coleta de dados no sistema operacional
GNU/Linux (distribuição Kubuntu 10.04).
O Netbeans 6.9.1 é um ambiente de desenvolvimento de software que facilita o
desenvolvimento de softwares na linguagem de programação Java e, portanto, a ferramenta
foi utilizada para o desenvolvimento dos softwares P2PMON e P2PMONWEB.
O banco de dados MySQL foi escolhido pela facilidade e simplicidade, além de ter
uma grande base de usuários corporativos e desenvolvedores. Mais uma vez, ressalta-se que
os scripts desenvolvidos para o modelo do banco de dados podem ser carregados em outros
bancos de dados como Microsoft SQL Server ou Oracle Enterprise 11g, sendo necessárias
poucas modificações nos scripts SQL.
O Servlet é uma extensão da linguagem Java desenvolvida especificamente para
trabalhar com a WEB através do protocolo HTTP, permitindo assim, o desenvolvimento de
aplicações WEB dinâmicas. O JSP é uma extensão do Servlet que facilita o desenvolvimento
de aplicações WEB dinâmicas utilizando programação explícita Java dentro de páginas
HTML. Os Servlets e JSPs foram utilizados para desenvolver a aplicação WEB
38
P2PMONWEB que fornece um meio amigável para o monitoramento online de servidores.
O framework YUI foi utilizado em conjunto com JSP e Servlets para o
desenvolvimento da página web porque tem diversos componentes prontos para uso, testados
em 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 as
implementações do Servlet e JSP rodam, permitindo assim, que aplicações WEB dinâmicas
sejam desenvolvidas na linguagem Java. (Apache Foundation, 2010)
O Git é um software para controle de versões de software e está sendo utilizado em
conjunto com a plataforma de desenvolvimento colaborativo GitHUB, para o gerenciamento
de versões de software, permitindo um controle preciso do código-fonte produzido dos
softwares P2PMON, P2PMONWEB e coletores de dados para os sistemas operacionais
GNU/Linux e Microsoft Windows. (Git, 2010)
O Wireshark é um analisador de pacotes de rede livre (GNU GPL) e foi utilizado para
investigar 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 para
softwares desenvolvidos exclusivamente em Java. A JvisualVM faz parte do JDK 1.6 da SUN
O 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 de
monitoramento real, utilizado em larga escala, além disso, outra característica importante é o
fato 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.1
Sistemas cliente-servidor). (Hyperic, 2010)
3.3 Hardwares utilizados
Para o desenvolvimento e testes da ferramenta de monitoramento P2PMON, a
interface WEB P2PMONWEB e coletores de dados para os sistemas operacionais Microsoft
Windows e GNU/Linux utilizaram-se três microcomputadores com as seguintes
configuraçõ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,
39
distribuiçã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/100mbps
Sendo que o microcomputador com o processador AMD Phenom foi utilizado para o
desenvolvimento dos softwares P2PMON, P2PMONWEB e os coletores de dados para o
sistema operacional GNU/Linux, enquanto o microcomputador com o processador Intel
Pentium 4 foi utilizado para o desenvolvimento dos coletores de dados para o sistema
operacional Microsoft Windows Server 2003.
3.4 Técnicas de engenharia de software utilizadas
Os quatro softwares gerados pelo presente trabalho (P2PMON, P2PMONWEB,
coletores de dados para o sistema operacional Microsoft Windows e GNU/Linux), foram
desenvolvidos de forma incremental (Pressman, 2006) e todo código gerado foi gerenciado
pelo sistema de controle de versões GIT. Como os componentes de softwares P2PMON e
P2PMONWEB foram desenvolvidos na linguagem Java, foi possível reutilizar diversas
classes. Assim, através da taxa de reuso de classes, fórmula (1), obtêm-se a porcentagem de
reuso das classes desenvolvidas para os softwares P2PMON e P2PMONWEB:
(1)
Fórmula (1) – Taxa de reuso de classes
Sendo que, a quantidade de classes em comum é a quantidade de classes
compartilhadas entre os softwares P2PMON e P2PMONWEB, 100 representa o espaço
amostral total (100%) e a quantidade total de classes representa a quantidade de classes que
perfazem 100%.
Além disso, todo o projeto está disponível no site http://exdev.sourceforge.net sob a
licença GNU GPL, que permite a redistribuição do software desde que toda e qualquer
modificaçã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
40
No intuito de melhorar a qualidade do software, foram utilizados alguns padrões de
projetos (do inglês design patterns). Os padrões de projetos são mecanismos conhecidos e
bem testados para resolver determinados problemas. Sua origem vem da arquitetura, através
dos 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 feito
pelo GoF (Gang of Four), um grupo de quatro pesquisadores em desenvolvimento de
software que escreveram o livro Design Patterns: Elements of Reusable Object-Oriented
Software. Há diversos tipos de padrões de projetos, entre os principais estão os padrões
criacionais, os padrões estruturais e os padrões comportamentais
Os 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 ou
objetos e finalmente, os padrões de projetos comportamentais dizem respeito a forma como
classes ou objetos interagem e distribuem responsabilidades. (Gamma et al, 1994)
Para o presente projeto, foram utilizados os padrões de projetos Model View
Controller – MVC, Data Access Object – DAO, Transfer Object – TO.
O padrão de projeto MVC (figura 13) é utilizado para separa o software em três
camadas 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, desta
forma, o processo de alteração das interfaces do software é bastante facilitado já que assim, as
três partes do software podem ser modificadas de forma independes sem afetar ou quebrar o
comportamento 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)
41
O padrão de projeto Data Access Object – DAO é utilizado para abstrair e encapsular
o 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 o
que implica em melhor desacoplamento de componentes de software e portanto, facilitando
consideravelmente o reuso de componentes. O padrão de projeto DAO é utilizado no
P2PMON 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 Data
Transfer Object – DTO é utilizado para facilitar a manipulação de dados em objetos. Desta
forma, 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 ou
escrita, permitindo assim que haja uma economia de chamadas ao objeto, já que ao invés de
chamar os métodos getters e setters ou acessar a propriedade diretamente, apenas uma
chamada é feita para acessar o objeto. (SDN, 2010) Na figura 14 é apresentado o diagrama de
caso de uso (UML) para o P2PMON, contendo cinco processos (atividades) do software
P2PMON, sendo que iniciar P2PMON, parar P2PMON, obter status P2PMON, obter ajuda
P2PMON estão relacionados com o ciclo de vida do P2PMON conforme a figura 11.
Figura 14 – Diagrama de Caso de Uso do P2PMON
Em seguida, na figura 15, apresenta-se o diagrama de caso de uso do software
P2PMONWEB, contendo oito processos (atividades). Todas estão relacionadas com a
utilização da interface WEB.
42
Figura 15 – Diagrama de Caso de Uso do P2PMONWEB
Nas figuras 16 e 17, é demonstrado o Modelo Entidade-Relacionamento utilizado para
a solução P2PMON e desenvolvido pelo MySQL Workbench.
Figura 16 – Modelo do banco de dados parte 1
Fig
ura
16 –
Mod
elo
do b
anco
de
dado
s pa
rte
1
43
Figura 17 – Modelo do banco de dados parte 2
Fig
ura
17 –
Mod
elo
do b
anco
de
dado
s pa
rte
2
44
3.5 Ambiente de testes
Para o ambiente de teste, foram utilizados os sistemas de monitoramento de servidores
P2PMON e HQ Hyperic. Ambos os sistemas de monitoramento foram testado utilizando suas
configurações padrões. No caso do sistema de monitoramento HQ Hyperic foi instalado tanto
o agente HQ Hyperic quanto o gerente (server) HQ Hyperic na mesma máquina por que esta
seria 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 AMD
Phenom 9500 Quad-Core, 8Gb de RAM, 500Gb de disco rígido, GNU/Linux, distribuição
Kubuntu 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 o
filtro tcp.port eq 7080 or tcp.port eq 7443 or tcp.port eq 2099 or tcp.port eq 9093 or tcp.port
eq 9432 or tcp.port eq 2144 para o HQ Hyperic agent e server e com o filtro tcp.port eq 3306
para o P2PMON por uma hora e meia de forma ininterrupta afim de se projetar a utilização
média de rede e possivelmente extrair um comportamento de ambos os sistemas de
monitoramento. Também foram coletados dados sobre a utilização de CPU e de RAM tanto
para o P2PMON quanto para o agente e o gerente HQ Hyperic através software JvisualVM
incluso no próprio JDK.
Tanto a utilização de CPU e RAM quanto o consumo de banda de rede são
fundamentais em termos de teste porque em uma rede monitorada, uma parte considerável da
banda de rede, de CPU e RAM pode ser utilizada de forma ineficiente se o sistema de
monitoramento 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 de
dados de todos os hosts em monitoramento. Um tempo inferior a cinco minutos pode gerar
um consumo ineficiente de banda de rede, CPU e RAM, enquanto um tempo superior a dez
minutos pode ser tarde demais para a detecção de problemas. Para os testes, foram utilizados
cinco minutos entre cada coleta de dados.
45
CAPÍTULO 4 – RESULTADOS E DISCUSSÕES
Neste capítulo apresentam-se dados coletados via Wireshark (analisador de pacotes de
rede) e JvisualVM (monitor de processos da JVM). Constatou-se que o P2PMON utiliza em
média 14 megabytes de RAM e 0.2% de utilização de CPU durante uma hora e meia hora de
coleta de dados via JvisualVM (gráfico 01).
Gráfico 01 – Porcentagem de CPU utilizada e RAM utilizada no P2PMON
No grafico 02, pode-se constatar que o Hyperic server (gerente, superior esquerdo e
superior 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) tem
consumo 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/server
A tabela 02 demonstra os dados coletados através do software Wireshark.
46
Tabela 02 – Comparação entre os dados gerados pelo P2PMON e HQ Hyperic agent/server
Total Capturado P2PMON Hyperic agent/server
Pacotes 242236 74990 85646
Média pacotes/s 33,66 10,809 11,91
Média tamanho pacote 344,88 461,285 186,34
Média bytes/s 11607,3 4986,19 2219,42
Média Mbit/s 0,09 0,040 0,018
Constatou-se que o P2PMON utiliza mais banda de rede que o Hyperic agent e
Hyperic server juntos. Sobre o fato dos dados do Hyperic agent e Hyperic server estarem
juntos, esta foi uma decisão tomada para procurar igualar as condições do teste uma vez que o
P2PMON enquanto software é agente e gerente ao mesmo tempo enquanto o HQ Hyperic tem
agente e servidor (gerente) separados.
Também avaliou-se a facilidade de instalação e os requisitos de software necessário
para 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ísticas
P2PMON Hyperic agent Hyperic server
Tamanho do arquivo de
instalação em Mb2,6 129 399
Quantidade de comandos para
instalação2 3 3
Parâmetros no arquivo de
configuração13 23 17
Banco de dadosQualquer um com
driver JDBC-
Qualquer um com
driver JDBC
Suporte para plugins Não Sim Sim
Linguagem de programação dos
coletores de dadosQualquer uma
Java e C/C++
(JNI)-
Constatou-se que o P2PMON é muito mais econômico em utilização de CPU e RAM
se comparado com o HQ Hyperic sendo o P2PMON consome aproximadamente 9,33 vezes
47
menos 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 HQ
Hyperic agent e server juntos e que mesmo que se o P2PMONWEB fosse incluído, a carga
gerada pelo servidor de aplicação Apache Tomcat 6, o consumo de RAM é de
aproximadamente 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 gera
menos pacotes de rede, mas com mais dados que o HQ Hyperic agent e server. A diferença da
quantidade de pacotes entre o P2PMON e o HQ Hyperic é de 10,656 pacotes. Já a diferença
da média de pacotes por segundo é de 1,10. A diferença de tamanho entre os pacotes é de
274,945. A diferença da média de bytes por segundo é de 2766,77. A diferença da média de
megabits 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 uma
análise nos arquivos de instalação do HQ Hyperic agent e server constatou-se que o HQ
Hyperic agent e server tem tamanho maior por que vem com diversos outros softwares como
o 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 de
configuração são dois itens importantes no processo de instalação e configuração, já que
quanto mais complexo ou quanto mais parâmetros, a possibilidade de o usuário configurar de
forma incorreta aumenta, além de dificultar a instalação em larga escala (por exemplo, instalar
8.000 instâncias do P2PMON é mais rápido e mais simples que instalar 8.000 instâncias do
HQ 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 pelos
softwares P2PMON e HQ Hyperic agent e server. Em ambos os casos, o driver JDBC
determina que banco de dados será utilizado mediante prévia configuração. Sendo importante
colocar que o P2PMON utiliza por padrão o banco de dados MySQL enquanto o HQ Hyperic
utiliza por padrão o banco de dados PostgreSQL.
O quesito suporte para plugins diz respeito a formas de estender o software através do
baixo acoplamento entre o núcleo e as outras partes do software. Neste quesito, até o
momento, o P2PMON não oferece este recurso embora haja uma proposta de trabalho futuro
48
para implementação de uma arquitetura de plugins. Já o HQ Hyperic agent e server suportam
uma arquitetura de plugins, facilitando a agregação de novos recursos tanto ao HQ Hyperic
agent quanto ao HQ Hyperic server.
Finalmente, o item linguagem de programação dos coletores de dados diz respeito a
possibilidade de criação de coletores de dados em outras linguagens de programação. Neste
quesito, o P2PMON é novamente vantajoso por não tem restrições na utilização da linguagem
facilitando de forma considerável o desenvolvimento de novos coletores de dados. Já o HQ
Hyperic é restrito ao Java e C ou C++ porque trabalha exclusivamente com a JNI (Java Native
Interface), recurso que permite o Java ter acesso ao sistema operacional através de uma
espécie de mapeamento de API entre as linguagens C ou C++ e o Java.
49
CAPÍTULO 5 – CONCLUSÕES
Este capítulo apresenta as conclusões observadas no presente trabalho, além de se
demonstrar possíveis linhas futuras de pesquisa no intuito de aperfeiçoar a ferramenta de
monitoramento P2PMON e seus componentes.
5.1 Considerações finais
A partir dos resultados obtidos neste capítulo, pode-se concluir que o P2PMON é mais
eficiente que o HQ Hyperic em grande parte dos requisitos, exceto no requisito utilização de
rede e da arquitetura de plugins. Também deve-se constatar que os softwares HQ Hyperic
agent e HQ Hyperic server são tecnicamente mais maduros que o P2PMON e este pode ser
uma 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á a
sugestão de comunicação por threshold (item 5.2, trabalhos futuros) e a diminuição de
instâncias de conexão com o banco de dados, sendo possível implementá-la através do design
pattern Singleton. Assim, seria possível ter um ganho em termos de economia de banda de
rede sensível. E ainda há possibilidade de economia de RAM através de otimizações nos
parâmetros do garbage collector e da utilização do JDK GNU GCJ que se mostrou mais
eficiente que o JDK oficial da SUN.
5.2 Conclusões
Demonstrou-se possível, desenvolver um Sistema de Monitoramento de Servidores
baseado na arquitetura de comunicação não hierárquica Peer-to-Peer (P2P), a partir da
ferramenta de software P2PMON e seus componentes, também foi possível esboçar a
eficiência da solução proposta através de testes realizados em ambiente real e resultados
satisfatórios obtidos.
Naturalmente, há diversas possibilidades de otimização (trabalhos futuros), mas de
forma geral o Sistema de Monitoramento P2PMON está de acordo com a proposta original de
fornecer uma solução de monitoramento que seja capaz de remover o servidor central,
50
també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 um
servidor exclusivo como ocorria nas soluções cliente-servidor tradicional, oferecendo recursos
de forma reativa e proativa para correção de falhas em ambientes computacionais e minimizar
o MTBF da infraestrutura.
5.2 Trabalhos futuros
Dentre 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é-programada
A otimização de desempenho pode se dar através da utilização de outros JDKs, entre
eles, 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 em
equipamentos como roteadores, switches, firewalls e mesmo servidores que tenham o agente
SNMP e as MIBs configuradas corretamente. De fato, o protocolo SNMP é um padrão
adotado 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 que
manipulam os dados gerados pelos coletores de dados.
O threshold é um recurso que permite que sejam pré-programados os limites inferiores
e superiores para um recurso monitorado, por exemplo, o coletor de dados da RAM/swap
poderia ser configurado para emitir um alerta quando houver muita memória disponível o que
51
poderia 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ão
houver memória disponível, já que sistemas operacionais podem matar um ou mais serviços
para liberar RAM e swap.
A comunicação por threshold é uma forma de otimização da comunicação entre os
hosts, por que o P2PMON emitiria alerta somente se algum host tivesse algum problema ou o
usuá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 para
quando algum threshold (limite) for atingido, seja o threshold inferior ou superior, uma ação
automática é executada no intuito de recuperar o sistema.
52
BIBLIOGRAFIA
MARCUS, EVAN; STERN, HAL. Blueprints for High Availability. 1st ed. 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. 6th ed. Prentice Hall, New
Jersey, 2000.
CARVALHO, TERESA C. DE M. DE BRITO. Gerenciamento de Redes – Uma abordagem
de sistemas abertos. 1ª ed. Makron Books, São Paulo, 1993.
MILLER, MARK A. Managing internetworks with SNMP. 2nd ed. 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 de
2010.
TANENBAUM S., ANDREW. Sistemas Operacionais Modernos. 2ª ed. Pearson Prentice
Hall, 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. Operating
System Concepts with Java. 7th ed. 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.
53
STALLINGS, WILLIAM. Operating Systems. 3rd ed. Prentice Hall, New Jersey, 1998.
RENAUD, PAUL. Introdução aos Sistemas Cliente/Servidor. 2ª ed. IBPI Press, Rio de
Janeiro, 1994.
BUFORD, JOHN F.; YU, HEATHER; LUA, KEONG. P2P Networking and Applications. 1st
ed. 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 Look
at 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ível
em: 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=pdf
Acesso 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/6424
Acesso 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 outubro
de 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: 11
de outubro de 2010.
WIRESHARK. Wireshark. Disponível em: http://www.wireshark.org/ Acesso em: 11 de
outubro de 2010.
HYPERIC. HQ Hyperic. Disponível em: http://www.hyperic.com/ Acesso em: 11 de outubro
de 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
54
Patterns). 1ª ed. Alta Books, Rio de Janeiro, 2005.
GAMMA, ERIC; HELM, RICHARD; JOHNSON, RALPH; VLISSIDES, JOHN. Design
Patterns Elements o Reusable Object-Oriented Software.1st ed. 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: 11
de 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.
55
APÊNDICE A – MANUAL DO P2PMON
O P2PMON é um sistema de monitoramento de servidores baseado em redes p2p.
A.1 Requerimento de software
Para a instalação do P2PMON e do P2PMONWEB são necessários os seguintes
softwares:
Máquina virtual do Java – Java Runtime Environment (JRE) versão >= 1.5
Banco de dados (preferencialmente o MySQL) versão >= 5.0
Apache Tomcat versão >= 6.0.29
A.2 Requerimento de hardware
Para a instalação do P2PMON e do P2PMONWEB, além dos requisitos necessários
para a instalação da JRE, do MySQL e do Tomcat, é recomendável pelo menos 256
megabytes de RAM e pelo menos 1 gigabyte de espaço livre em disco.
A.3 Configuração do Banco de dados
O modelo do banco de dados foi desenvolvido utilizando o software MySQL
Workbench. Para facilitar a migração para outros bancos de dados, toda a modelagem foi
desenvolvida 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ção
config.txt.
O MySQL em distribuições GNU/Linux precisa de alguns ajustes:
1 – a linha bind-address deve ser comentada no arquivo my.cnf
de bind-address = 127.0.0.1 para #bind-address 127.0.0.1
56
2 – os usuários devem ter acesso permitido através da execução da linha abaixo no
console do MySQL:
GRANT ALL PRIVILEGES ON *.* TO 'USERNAME'@'%' WITH GRANT
OPTION;
Mais informações em http://dev.mysql.com/doc/refman/5.1/en/adding-users.html
3 – a porta padrão (3306) deve estar aberta no firewall
Feito os 3 passos anteriores, é necessário executar o script de criação das tabelas do
P2PMON, o arquivo p2pmondbm-data.sql (data indica a data da última versão disponível do
script, no momento é a versão 20101127-1) e em seguida, é necessário executar o script para a
carga 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.txt
O arquivo de configuração config.txt é um arquivo de propriedades que guarda os
dados na forma de um hash(par chave=valor). Este arquivo deve ser colocado no diretório
onde o arquivo p2pmon.jar está. A seguir é mostrado um exemplo de configuração do arquivo
config.txt
# Configuração do P2PMON
# WebURL → configuração do IP do P2PMONWEB
#utilize none quando o P2PMONWEB for local
WebURL=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 none
PeerHost=none
# O intervalo entre as coletas de dados em segundos
57
IntervalDC=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 dados
DbURL=jdbc:mysql://localhost:3306/
# A senha do bando de dados
DbPwd=debian
# O esquema do banco de dados
DbSchem=p2pmon
# O usuário do banco de dados
DbUser=root
# O usuário do P2PMONWEB
Username=admin
# A senha do P2PMONWEB
Userpassword=admin
# O MAC Address da máquina a ser instalada
Macaddr=00:26:18:05:5f:09
# O path onde os arquivos no formato JSON devem ser criados
JSonPath=/home/netto/Desktop/p2pmon-web/build/web
A.5 Os coletores de dados
Os coletores de dados são pequenos softwares que coletam dados de um sistema. Todo
coletor 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 operacional
O gerenciamento de serviço implementado no P2PMON permite o controle do
P2PMON através dos comandos start (iniciar P2PMON), stop (parar P2PMON), status (obter
status do P2PMON) e help (ajuda).
Para iniciar o P2PMON através da linha de comando:
java -jar p2pmon.jar start
58
Para parar o P2PMON:
java -jar p2pmon.jar stop
Para obter o status do P2PMON:
java -jar p2pmon.jar status
Para obter ajuda do P2PMON:
java -jar p2pmon.jar help
Assim, é possível integrar o sistema de monitoramento do P2PMON em background
sem a necessidade de interação com o usuário e de forma transparente ao sistema operacional.
A.7 Configurando o P2PMONWEB
Para a utilização do P2PMONWEB é necessário instalar o servidor de aplicações Java
Apache Tomcat, versão 6.0.29 ou maior e configurar o arquivo p2pmonweb.xml
A.8 Configuração do arquivo p2pmonweb.xml
Para o correto funcionamento do P2PMONWEB é necessário colocar o arquivo
p2pmonewb.xml dentro do diretório conf que está dentro do diretório do Apache Tomcat. A
seguir, é 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 P2PMONWEB
O 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 P2PMONWEB
da seguinte forma: http://localhost/p2pmonweb
A.9 Utilizando o P2PMONWEB
Para a visualização dos dados coletados pelo P2PMON, o usuário deve acessar a
59
interface WEB P2PMONWEB. A seguir, são apresentadas explicações sobre as telas do
P2PMONWEB 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 de
usuário (username) e a senha (password). Para o primeiro login deve- se utilizar o nome de
usuário admin e a senha admin. Assim, e possível ter acesso à interface principal e
posteriormente 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 de
processamento (loadavg), deletar host (deletehost).
A figura 03 (tela de adição de hosts) permite adicionar hosts e requer os seguintes
dados: nome do servidor (hostname), IP, MAC Address, o sistema operacional é
automaticamente atualizado quando o sistema de coleta de dados é executado pela primeira
vez após adicionar o host.
A figura 04 (tela de detalhes dos discos rígidos) mostra os detalhes dos discos rígidos
dos 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 (mount
pt), 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 Swap
dos 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 os
serviç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ão
multiplataforma como o servidor WEB Apache HTTP, o banco de dados MySQL e Oracle
Express (OracleXE).
A figura 08 (tela de detalhes de servições monitorados no Microsoft Windows) mostra
os 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 interface
gráfica terminal Service).
60
A 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 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 atualizar usuário (can update user),
permissão para deletar usuário (can delete user), atualizar usuário (update user), deletar
usuário (delete user).
A figura 10 (tela de adição de usuários) permite adicionar usuários e requer os
seguintes 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 atualizar
usuá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, apresentando
os 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 (update
location) e deletar local (delete location).
E finalmente, na figura 12 (tela de adição de locais) permite adicionar locais e requer
os 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).
61
Fig
ura
01 –
Tel
a de
logi
n
62
Fig
ura
02 –
Lis
ta d
e ho
sts
63
Fig
ura
03 –
Adi
ção
de h
osts
64
Fig
ura
04 –
Det
alhe
s do
dis
co r
ígid
o
65
Fig
ura
05 –
Det
alhe
s da
RA
M/S
wap
66
Fig
ura
06 –
Sta
tus
dos
serv
iços
mon
itor
ados
de
um s
ervi
dor
GN
U/L
inux
67
Fig
ura
07 –
Sta
tus
dos
serv
iços
mul
tipl
ataf
orm
a
68
Fig
ura
08 –
Sta
tus
dos
serv
iços
mon
itor
ados
de
um s
ervi
dor
Mic
roso
ft W
indo
ws
69
Fig
ura
09 –
Lis
ta d
e us
uári
os
70
Fig
ura
10 –
Adi
ção
de u
suár
ios
71
Fig
ura
11 –
Lis
ta d
e L
ocai
s
72
Fig
ura
12 –
Adi
ção
de L
ocai
s