UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
UNMS: PLATAFORMA UNIFICADA PARA O GERENCIAMENTO DE
REDES
Área de Redes de Computadores
por
Axel Krieger Neto
Fabrício Bortoluzzi, M.Sc.
Orientador
Itajaí (SC), fevereiro de 2009
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
UNMS: PLATAFORMA UNIFICADA PARA O GERENCIAMENTO DE
REDES
Área de Redes de Computadores
por
Axel Krieger Neto
Relatório apresentado à Banca Examinadora do
Trabalho de Conclusão do Curso de Ciência da
Computação para análise e aprovação.
Orientador: Fabrício Bortoluzzi, M.Sc.
Itajaí (SC), fevereiro de 2009
AGRADECIMENTOS
Agradeço a:
•
Meu pai por seu apoio e compreensão, essenciais para a conclusão deste curso.
•
Minha mãe pelo grande incentivo dado durante toda a vida estudantil.
•
Orientador Fabrício Bortoluzzi que foi bastante requisitado por sugestões e criticas
durante todo o projeto.
•
Ademir Goulart professor que me demonstrou pela primeira vez, o funcionamento de
softwares de gerência de redes e que despertou a curiosidade sobre o assunto.
•
Francis Benito Odisi por autorizar a utilização de componentes de desenvolvimento
gráfico e de acesso a banco de dados, ambos de sua autoria.
•
Todos os colegas do curso de Ciência da Computação sem os quais muitos
conhecimentos deixariam de ser aprendidos.
ii
SUMÁRIO
LISTA DE ABREVIATURAS................................................................... v
LISTA DE FIGURAS................................................................................vi
LISTA DE TABELAS .............................................................................viii
RESUMO....................................................................................................ix
ABSTRACT................................................................................................. x
1 INTRODUÇÃO ...................................................................................... 1
1.1 PROBLEMATIZAÇÃO................................................................................... 2
1.1.1 Formulação do Problema .............................................................................. 2
1.1.2 Solução Proposta ............................................................................................ 3
1.2 OBJETIVOS ..................................................................................................... 4
1.2.1 Objetivo Geral................................................................................................ 4
1.2.2 Objetivos Específicos...................................................................................... 4
1.3 METODOLOGIA............................................................................................. 4
1.4 ESTRUTURA DO TRABALHO ..................................................................... 5
2 FUNDAMENTAÇÃO TEÓRICA ........................................................ 6
2.1 .NET FRAMEWORK E PROJETO MONO .................................................. 6
2.1.1 .NET Framework ........................................................................................... 6
2.1.2 Projeto Mono.................................................................................................. 9
2.2 MODELOS, ARQUITETURAS E PROTOCOLOS DE GERÊNCIA........ 12
2.2.1 Conceitos....................................................................................................... 12
2.2.2 FCAPS: Fault, Configuration, Accounting, Performance and Security ... 14
2.2.3 CMIP/CMISE............................................................................................... 15
2.2.4 SNMP............................................................................................................ 17
2.3 SOFTWARES DE MONITORAMENTO..................................................... 27
2.3.1 Nagios............................................................................................................ 27
2.3.2 Cacti .............................................................................................................. 33
2.3.3 Tabela comparativa de softwares de gerência de redes ............................. 38
3 PROJETO ............................................................................................. 40
3.1 REQUISITOS FUNCIONAIS, NÃO FUNCIONAIS E REGRAS DE
NEGÓCIO .............................................................................................................. 41
3.1.1 Motor ............................................................................................................ 42
3.1.2 Interface com o usuário ............................................................................... 43
3.2 DIAGRAMAS DE CASO DE USO ............................................................... 44
3.2.1 Motor ............................................................................................................ 44
3.2.2 Interface com o usuário ............................................................................... 45
3.3 DIAGRAMAS DE CLASSE .......................................................................... 60
3.3.1 Motor ............................................................................................................ 61
iii
3.3.2 Interface........................................................................................................ 62
3.4 DIAGRAMA ENTIDADE-RELACIONAL .................................................. 63
4 Desenvolvimento................................................................................... 64
4.1 CLASSE DE MANIPULAÇÃO DE DADOS DO PROTOCOLO SNMP... 65
4.1.1 Padrão TLV.................................................................................................. 66
4.1.2 Codificação/Decodificação BER .................................................................. 67
4.1.3 A biblioteca de classes resultante ................................................................ 68
4.2 O MOTOR DO UNMS................................................................................... 70
4.2.1 Checando através de ICMP......................................................................... 71
4.2.2 Checando serviços ........................................................................................ 72
4.2.3 Checando os OIDs........................................................................................ 72
4.3 DESENVOLVIMENTO DA INTERFACE .................................................. 73
4.3.1 Construção de gráficos na plataforma .NET .............................................. 74
4.3.2 Exibindo hosts no Google Earth.................................................................. 76
4.3.3 Desenvolvimento da auto-descoberta de dispositivos................................. 78
4.4 TESTES DO UNMS ....................................................................................... 79
4.4.1 Processo de testes da biblioteca de acesso SNMP ....................................... 79
4.4.2 Testes da ferramenta.................................................................................... 80
5 CONCLUSÕES .................................................................................... 83
REFERÊNCIAS BIBLIOGRÁFICAS ................................................... 85
iv
LISTA DE ABREVIATURAS
API
ASN.1
BCL
BER
CLR
CMIP
CMIS
CMISE
CMOT
EGP
FCAPS
GPL
ICMP
IETF
IL
ISO
ITU
ITU-T
JIT
LPP
MIB
NGWS
NMS
OID
OSI
PDU
RFC
SGBD
SMI
SNMP
TCC
TLV
TMN
UNIVALI
UNMS
XML
Application Programming Interface
Abstract Syntax Notation One
Base Class Library
Basic Encoding Rules
Common Language Runtime
Common Management Interface Protocol
Common Management Information Service
Common Management Information Service Element
Common Management over TCP/IP
Exterior Gateway Protocol
Fault, Configuration, Accounting, Performance and Security
General Public License
Internet Control Message Protocol
Internet Engineering Task Force
Intermediate Language
International Standards Organization
International Telecommunication Union
ITU Telecommunication Standardization Sector
Just in Time Compilation
Lightweight Presentation Protocol
Management Information Base
Next Generation Windows Services
Network Management System
Object Identifier
Open Systems Interconnection
Protocol Data Unit
Release For Comments
Sistema Gerenciador de Banco de Dados
Structure of Managed Information
Simple Network Management Protocol
Trabalho de Conclusão de Curso
Type, Length and Value
Telecommunications Management Networks
Universidade do Vale do Itajaí
Unified Network Management System
Extensible Markup Language
v
LISTA DE FIGURAS
Figura 1. A Arquitetura .NET. .........................................................................................................8
Figura 2. Tratamento de arquivos para sistemas multi-plataforma....................................................9
Figura 3. GTK# no Linux. .............................................................................................................10
Figura 4. GTK# no Windows.........................................................................................................10
Figura 5. Código fonte para detecção de plataforma.......................................................................11
Figura 6. Resultado da detecção do sistema operacional no Linux. ................................................11
Figura 7. Resultado da detecção do sistema operacional no Windows XP. .....................................11
Figura 8. Status do desenvolvimento do namespace System. ..........................................................12
Figura 9. MIB do ambiente de gerenciamento Internet...................................................................13
Figura 10. Sistema de gerenciamento baseado em CMIP/CMIS.....................................................16
Figura 11. Relação entre o NMS e o Agente. .................................................................................18
Figura 12. A árvore de objetos da SMIv1.......................................................................................20
Figura 13. Primeiras linhas de uma MIB........................................................................................20
Figura 14. Formato da declaração de objetos gerenciáveis. ............................................................21
Figura 15. Definição de objetos gerenciáveis. ................................................................................21
Figura 16. Definição da Sequence IfEntry......................................................................................22
Figura 17. SMIv2 e novos ramos. ..................................................................................................22
Figura 18. Definição de objetos gerenciáveis na SMIv2.................................................................23
Figura 19. MIB-II. .........................................................................................................................25
Figura 20. Tela inicial do Nagios. ..................................................................................................30
Figura 21. Detalhes dos hosts. .......................................................................................................31
Figura 22. Detalhes dos serviços....................................................................................................32
Figura 23. Recurso “Mapa da Rede”..............................................................................................33
Figura 24. Tela inicial do Cacti......................................................................................................34
Figura 25. Cadastro e/ou alteração de um dispositivo de rede no Cacti...........................................37
Figura 26. Visualizando gráficos no Cacti......................................................................................38
Figura 27. Exemplo de uso. ...........................................................................................................40
Figura 28. Modelo em camadas. ....................................................................................................41
Figura 29. Diagrama de casos de uso do Motor..............................................................................44
Figura 30. Diagrama de casos de uso da interface. .........................................................................45
Figura 31. Interface de login. .........................................................................................................46
Figura 32. Interface principal do cadastro de hosts.........................................................................48
Figura 33. Interface de configuração de monitoramento.................................................................49
Figura 34. Interface de cadastro de serviços...................................................................................51
Figura 35. Interface de cadastro de usuários...................................................................................52
Figura 36. Interface de visualização de estados de hosts. ...............................................................53
Figura 37. Interface de visualização de estados dos serviços dos hosts. ..........................................54
Figura 38. Interface de visualização da topologia da rede...............................................................55
Figura 39. Interface para a chamada da visualização de hosts no Google Earth. .............................56
Figura 40. Visualização de gráficos. ..............................................................................................57
Figura 41. Visualização de eventos................................................................................................58
Figura 42. Detectando hosts...........................................................................................................60
Figura 43. Diagrama de classes do motor.......................................................................................61
Figura 44. Diagrama Entidade-Relacional......................................................................................63
Figura 45. Formato de desenvolvimento. .......................................................................................65
Figura 46. Datagrama SNMP.........................................................................................................66
vi
Figura 47. Espaço community do SNMP. ......................................................................................66
Figura 48. Valor binário de sete em sete bits..................................................................................68
Figura 49. Resultado da codificação BER. .....................................................................................68
Figura 50. Métodos da classe de codificação/decodificação BER...................................................68
Figura 51. Métodos da classe de Snmp. .........................................................................................69
Figura 52. Métodos e atributos da classe SnmpData.......................................................................70
Figura 53. Métodos da classe ICMP. .............................................................................................71
Figura 54. Exemplo de uso para o .Net Charting e seu logotipo. ....................................................74
Figura 55. .Net Charting no Visual Studio. ....................................................................................74
Figura 56. .Net Charting e gráfico de barras...................................................................................75
Figura 57. Exemplo de uso do .Net Charting..................................................................................75
Figura 58. Exemplo de KML. ........................................................................................................77
Figura 59. Google Earth exibindo os hosts.....................................................................................78
Figura 60. Wireshark detectando os datagramas SNMP. ................................................................79
Figura 61. Comparando o datagrama correto (linha superior) e o incorreto (linha inferior).............80
Figura 62. O gráfico construído corretamente para medir a carga de processamento de um host. ...82
vii
LISTA DE TABELAS
Tabela 1. Tipos de dados SMIv1....................................................................................................19
Tabela 2. Novos tipos de dados da SMIv2 .....................................................................................23
Tabela 3. Aprimoramentos na definição de objetos. .......................................................................23
Tabela 4. Novos termos .................................................................................................................24
Tabela 5. Explicação dos ramos da MIB-II ....................................................................................25
Tabela 6. Tipos de traps.................................................................................................................27
Tabela 7. Lista dos principais plugins do Nagios ...........................................................................28
Tabela 8. Arquivos padrões de configuração do Nagios .................................................................29
Tabela 9. Tabela comparativa de softwares de gerência de redes....................................................39
Tabela 10. Bibliotecas SNMP pesquisadas.....................................................................................66
Tabela 11. Tipos de dado do protocolo SNMP utilizado no padrão TLV........................................67
Tabela 12. Dados sobre o segundo teste.........................................................................................81
viii
RESUMO
KRIEGER NETO, Axel. UNMS: Plataforma Unificada para Gerenciamento de Redes. Itajaí,
2008. 98 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro de
Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2009.
Com a expansão das redes de computadores, tornou-se necessária a utilização de softwares que
monitorem seus recursos. A necessidade de gerenciamento otimizado resultou em vários padrões,
arquiteturas e protocolos de gerência além de softwares de monitoramento de estados e grafadores.
Neste trabalho é demonstrado o processo de desenvolvimento do UNMS, um software de
monitoramento de redes construído para a plataforma .NET e que une estes dois principais recursos.
O estudo e compreensão do SNMP no nível de seus datagramas durante este processo bem como as
regras básicas de codificação e o TLV foram documentados neste TCC. O resultado deste processo
é um software de código aberto, com um motor que se torna multi-plataforma se utilizado junto
com o projeto Mono.
Palavras-chave: Gerência de Redes. Monitoramento de Redes. NMS. Plataforma .NET. SNMP.
TLV. Regras básicas de codificação. Projeto Mono.
ix
ABSTRACT
Expansion of computer networks has made it necessary to use software to monitor netwoirking
resources. The need for optimal management resulted in several standards, architectures and
protocols in addition to the monitoring softwares of state diagrams and graphers. This work
demonstrates the development process of UNMS, a network monitoring software built for the .NET
plataform and that unites those two main resources. The study and understanding at datagram level
of SNMP during this process such as the basic encoding rules and TLV were documented in this
paper. The result of this process is an open-source software, with a multi-plataform engine using
Mono Project.
Keywords: Network Management. Network Monitoring. NMS. .NET Plataform. SNMP. TLV. Baisc
Encoding Rules. Mono Project.
x
1 INTRODUÇÃO
As redes de computadores se tornaram presentes na maioria das organizações modernas.
Poucas áreas, em um período tão curto, apresentaram tantas revoluções tecnológicas quanto as
Redes de Computadores (TANENBAUM, 2003).
O uso e a dependência da Internet como instrumento de agilidade para os negócios faz com
que as Redes de Computadores sejam altamente utilizadas. O número de sistemas que necessitam
desta tecnologia vem aumentando significativamente, tornando necessária a existência de rotinas
que monitoram os diversos equipamentos que compõem a rede, como roteadores, switches, access
points, computadores, etc., garantindo que os dispositivos não estejam apenas funcionando, mas
também operando de forma otimizada. Para este propósito, foram criados protocolos de gerência de
redes como o SNMP (Simple Network Management Protocol – Protocolo Simples de Gerência de
Redes) e o CMIP (Common Management Information Protocol – Protocolo de Gerência de
Informações Comuns). O processo de monitoramento é considerado uma parte do processo de
gerenciamento de rede.
Gerenciamento de rede inclui o oferecimento, a integração e a coordenação de hardware,
software e humanos, para monitorar, testar, consultar, configurar, analisar, avaliar e
controlar os recursos da rede, e de elementos, para satisfazer às exigências operacionais, de
desempenho e de qualidade de serviço em tempo real a um custo razoável (SAYDAM,
1996).
O protocolo SNMP é o padrão de facto para a obtenção de tais indicadores (MAURO;
SCHMIDT, 2001, tradução nossa) sendo, portanto, o protocolo adotado para a construção do
UNMS.
A tarefa de se encontrar um único software que trate todas as necessidades de gerenciamento
não é trivial e geralmente frustra o administrador, já que dificilmente se encontra algum software
que, ao mesmo tempo em que monitora os recursos, faz gráficos de carga e produz alertas. Além
disso, os softwares de gerenciamento costumam ser de difícil configuração, já que a maioria é
configurada através de arquivos de texto, que em muitos casos são muito complexos. Também
existem os softwares de difícil utilização, obrigando o administrador da rede a estudar dezenas de
linhas de comando para se extrair um mínimo de informação.
Atualmente, existem vários softwares que monitoram a rede em utilização, como por
exemplo, o Nagios (NAGIOS, 2008) e o Cacti (CACTI, 2008). Vários administradores de rede
utilizam os dois em conjunto. O Nagios monitora os recursos da rede e emite alertas mediante
estados indesejados. Já o Cacti grafa a carga e/ou utilização de recursos. Neste cenário, ocorre a
dificuldade de configurar, já que ambos são manipulados em ambientes distintos, fazendo-se
necessário o cadastro dos equipamentos duas vezes, ou mais, se o administrador considerar
necessárias outras ferramentas de apoio à gestão da infra-estrutura, gerando redundância de dados
entre outros problemas.
Neste trabalho, é demonstrada a construção de um software chamado UNMS (Unified
Network Management System – Sistema de Gerenciamento de Redes Unificado), cujo objetivo é de
tratar a dependência de mais de um software de gerencia de redes evitando as redundâncias
descritas.
Destaca-se o estudo em mais baixo nível do protocolo SNMP. Isto foi necessário devido a
falta de bibliotecas nativas do .NET que tratam deste protocolo.
1.1 PROBLEMATIZAÇÃO
A problematização do presente trabalho será abordada através da:
•
Formulação do problema; e
•
Solução Proposta.
1.1.1 Formulação do Problema
Pode-se considerar que existe, atualmente, uma grande dependência da Internet como
ferramenta do dia-a-dia, resultando em um alto grau de uso de redes de computadores. Devido a
este crescimento, houve a necessidade da criação de sistemas que monitoram e gerenciam todos os
dispositivos de rede.
Os sistemas atuais que monitoram a rede foram criados para solucionar parte dos problemas.
Uns simplesmente monitoram os estados dos hosts, emitindo alertas ou apenas exibindo
informações sobre eles. Outros ainda exibem informações de serviços de rede como um servidor
Web por exemplo. Ainda existem sistemas que constroem gráficos de utilização de recursos, que
permitem ao administrador de rede, visualizar as informações de um modo mais fácil e amigável,
podendo resultar em tomadas de decisão mais eficientes e corretas.
2
Devido a existência de vários tipos de sistemas de monitoramento de redes, existe também a
necessidade de possuir mais de um, com a finalidade de garantir um alto grau de controle sobre a
rede. Ao utilizar vários sistemas de monitoramento o administrador da rede é forçado a configurar
cada um individualmente, podendo resultar em inconsistências.
Além disso, existem casos em que sistema é de difícil utilização, sendo apenas executado
usando linhas de comando na maioria das vezes bastante extensas. Outros ainda são de difícil
configuração, sendo ajustados por vários arquivos de texto, obrigando o administrador a estudá-los
exaustivamente antes que consiga algum tipo de resultado.
Analisando pelo lado do desenvolvedor de softwares, existe também uma ausência de
bibliotecas de classes, que fazem com que a utilização do protocolo SNMP seja mais simples. A
existência de bibliotecas que atinjam esta necessidade fará com que o desenvolvedor se preocupa
mais com a lógica de negócio e reduzindo o tempo de construção de softwares.
1.1.2 Solução Proposta
Neste trabalho foi construída uma ferramenta de gerência de redes de computadores que é
fácil de utilizar, configurar e instalar. Além disto, o motor desta ferramenta é compatível com vários
sistemas operacionais diferentes. O envio de alertas da ferramenta é limitado à exibição destes na
tela e ao envio de emails.
A solução sanou problemas das soluções similares analisadas. As soluções de
monitoramento estudadas foram o Nagios (NAGIOS, 2008) e Cacti (CACTI, 2008).
O motor do UNMS foi construído utilizando o projeto Mono, uma implementação de código
aberto da plataforma .NET, que permite aos programadores criarem e executarem aplicações em
vários sistemas operacionais como Linux, Mac OS X e o Windows. A linguagem que foi adotada
para a construção da ferramenta é a C# e o SGBD (Sistema de Gerenciamento de Banco de Dados)
será o PostgreSQL. Já a interface foi construída ignorando aspectos de compatibilidade com o
projeto Mono.
Buscando facilitar a utilização do SNMP na plataforma .NET bem como o correto
funcionamento do motor, foi construído uma biblioteca de classes própria. Esta contém uma classe
principal que manipula as informações do protocolo através de métodos estáticos, tornando seu uso
direto e objetivo.
3
1.2 OBJETIVOS
Os objetivos do trabalho são compostos pelo objetivo geral e por cinco objetivos
específicos.
1.2.1 Objetivo Geral
O objetivo geral deste trabalho é especificar e produzir um software de gerência para redes
de computadores com interface gráfica local que contemple as tarefas de mapas de estado e
grafagem de objetos, endereçando as principais dificuldades encontradas no uso dos softwares de
mesmo propósito disponíveis para uso.
1.2.2 Objetivos Específicos
Os objetivos específicos deste projeto de pesquisa são:
•
Listar as principais características de softwares de gerência de redes de código aberto;
•
Compreender a especificação .NET implementada através do projeto de código-fonte
aberto Mono;
•
Especificar e construir o UNMS;
•
Testar e validar o comportamento do UNMS aplicando-o em uma infra-estrutura de
rede; e
•
Documentar o desenvolvimento e os resultados do sistema.
1.3 Metodologia
A realização da primeira parte do trabalho de conclusão de curso seguiu duas etapas
principais: estudo e projeto.
A primeira parte do trabalho teve como objeto de estudo a plataforma .NET e o projeto
Mono. Além disso, foram estudadas as arquiteturas, protocolos e conceitos relacionados à gerência
de redes, necessários para compreender como construir a solução proposta. Também, foram
estudados outros aplicativos de gerência de redes, através dos quais foi possível enumerar vários
recursos interessantes. Todos os estudos foram realizados utilizando a Internet e livros, e os
resultados foram descritos na seção de Fundamentação Teórica.
4
A etapa de projeto teve como objetivo modelar o sistema através da construção de
diagramas de caso de uso, classe e entidade-relacional. Os recursos mais importantes enumerados,
ainda na etapa anterior, foram considerados na elaboração do projeto.
A etapa de desenvolvimento foi a que englobou a criação das bibliotecas básicas e a
construção do motor e da interface. Além disso, foram realizados estudos adicionais e mais
aprofundados, necessários para a construção de alguns recursos.
1.4 Estrutura do trabalho
A estrutura deste trabalho é composta por quatro seções principais: Introdução,
Fundamentação Teórica, Projeto, Desenvolvimento e Conclusão.
A Introdução aborda o trabalho como um todo, explicando o problema, mostrando os
objetivos a serem alcançados e a solução proposta.
A seção de Fundamentação Teórica aborda os assuntos necessários para construir a solução
proposta. São demonstradas as principais arquiteturas e conceitos existentes na área de gerência de
redes bem como a plataforma em que se deseja programar a solução, o Mono, traçando um
comparativo simplificado entre este e a implementação de referência da Microsoft.
A terceira seção aborda o projeto de software, que descreve os requisitos funcionais,
requisitos não funcionais e as regras de negócio. Os diagramas do projeto escolhidos para esta
solução são exibidos e explicados, bem como a importância de contemplá-los em um projeto de
software.
A seção de Desenvolvimento aborda os principais aspectos a serem descritos durante a
construção de toda a solução proposta. A criação de bibliotecas, estudos mais aprofundados e testes
são documentados nesta sessão.
A última etapa exibe as conclusões tiradas sobre este trabalho de conclusão de curso.
5
2 FUNDAMENTAÇÃO TEÓRICA
A fundamentação teórica deste trabalho irá abordar os seguintes temas: (i) .NET Framework
e Projeto Mono; (ii) protocolos, arquiteturas e conceitos de gerência de redes; (iii) protocolo de
gerência de rede SNMP; (iv) descrição das ferramentas de monitoramento de código aberto.
2.1 .NET Framework e Projeto Mono
Nas seções seguintes, serão exibidos os estudos do .NET Framework e uma implementação
alternativa e de código aberto, o Projeto Mono.
2.1.1 .NET Framework
.NET é a plataforma criada pela Microsoft no final dos anos 90 utilizando o nome NGWS
(Next Generation Windows Services – Nova Geração de Serviços Windows), entretanto, foi no ano
2000 que a Microsoft liberou a primeira versão beta do .NET 1.0. O .NET fornece uma nova API
(Application Programming Interface – Interface de Programação de Aplicativos), com novas
funcionalidades, novas ferramentas para a construção de aplicações para o Microsoft Windows e
Web, novos componentes e novos serviços (TEMPLEMAN; VITTER, 2002, tradução nossa).
Uma nova API se tornou necessária para aplicações Windows, pelo fato de que sua API foi
escrita em C e cresceu com o passar dos anos. Atualmente, a API do Windows possui milhares de
rotinas e vários problemas, já que os novos recursos da API foram adicionados pouco a pouco e
com pouca organização. O fato de que a API do Windows seja construída em C acaba dificultando
o desenvolvimento em outras linguagens, inclusive em linguagens mais modernas orientadas a
objetos (IBIDEM).
Várias linguagens podem ser utilizadas para se desenvolver na plataforma .NET, entres as
quais o C#, Visual Basic .NET e J# se destacam. As aplicações desenvolvidas com essas linguagens
são compiladas para o IL (Intermediate Language – Linguagem Intermediária), que se assemelha ao
bytecode do Java. Isto significa que ao se desenvolver usando Visual Basic.NET, C# ou qualquer
outra linguagem suportada, a aplicação será compilada para a mesma linguagem, a IL.
Com a aplicação já compilada para a IL, é necessário um mecanismo para executá-la. Este
mecanismo é o CLR (Common Language Runtime - Linguagem Comum de Tempo de Execução).
O CLR dispõe de vários recursos como, JIT (Just in Time Compilation – Compilação em tempo de
execução), responsável por traduzir o IL em código nativo, Garbage Collection (coleta de lixo),
políticas de segurança e serviços de depuração. Com estes recursos, o CLR se situa entre o sistema
operacional e a aplicação, provendo a segurança e controlando o acesso à memória, permitindo
acesso transparente aos serviços do sistema operacional.
A plataforma .NET possui sua própria biblioteca de classes (BCL - Base Class Library).
Conforme Templeman e Viter (2002, tradução nossa), a BCL não é especifica para uma única
linguagem, podendo ser utilizada por qualquer linguagem que será compilada para a IL. Além
disso, a BCL é orientada à objetos, disponibilizando suas funcionalidades através de um grande
número de classes organizadas em vários namespaces1.
A BCL fornece ao desenvolvedor os seguintes itens:
•
Definição de tipos básicos como int, char, entre outros.
•
Tipos de coleção genéricos como vetores, listas, pilhas, tabelas hash, enumeradores e
filas.
•
As classes podem definir suas exceções usando a BCL, sendo possível gerar uma
exceção usando C# e tratá-la usando VB.NET.
•
Classes para tratamento do console, arquivos, entrada e saída, sockets, etc.
•
Classes para desenvolver interfaces gráficas, desenhos em duas dimensões, tratamento
de imagens e impressão.
•
Serialização de objetos, um modo de salvar os objetos que estão na memória em um
arquivo XML ou binário. Também possibilita carregar os objetos de um arquivo.
•
Classes que implementam e gerenciam segurança.
•
Classes para construção de aplicações distribuídas e sistemas Web.
•
Classes para lidar com XML.
•
Utilização de recursos do Sistema Operacional como threads (processos), timers, etc.
1 Namespaces são utilizados para organizar classes.
7
O recurso de compilação Just in Time da arquitetura .NET permite que o código IL seja
portável e eficiente. A eficiência é garantida quando o código IL é compilado para o código nativo
em tempo de execução. Neste modo, a compilação ocorre quando o método é executado pela
primeira vez, e nas suas execuções seguintes, ele já executará o código nativo. Outro modo de
funcionamento do JIT é a compilação em tempo de instalação. Além disso, segundo Templeman e
Vitter (2002, tradução nossa), a plataforma .NET será portável assim que a IL seja suportada em
outros sistemas operacionais.
O recurso de Garbage Collection (coleta de lixo), é um recurso bastante útil presente na
plataforma .NET. Ele elimina problemas presentes em linguagens como o C, na qual os
programadores tem que desalocar manualmente a memória. O gerenciamento manual de memória
pode gerar grandes problemas. Caso o programador esqueça de desalocar a memória ou a desaloque
mais de uma vez, o programa poderá gerar erros. (TEMPLEMAN; VITTER, 2002, tradução nossa).
A disposição dos itens da arquitetura .NET são exibidos na Figura 1.
Figura 1. A Arquitetura .NET.
Fonte: Templeman e Vitter (2002).
Uma alternativa aos desenvolvedores .NET é o projeto de código aberto Mono. Ele suporta
praticamente as mesmas linguagens que o .NET Framework suporta e, pode ser executado em
vários Sistemas Operacionais baseados em Unix, além de Mac OS X e o próprio Windows.
8
2.1.2 Projeto Mono
Mono é uma implementação multi-plataforma e de código aberto do .NET Framework.
Neste projeto, o principal compilador é destinado à linguagem C#, já que esta foi desenvolvida
especialmente pela Microsoft no .NET Framework. Entretanto, conforme Bornstein e Dumbill
(2004, tradução nossa), existem compiladores para o Mono com outras linguagens como Java, C,
Basic e Cobol.
A CLR (Common Language Runtime - Linguagem Comum de Tempo de Execução) faz
parte do projeto, garantindo que a aplicação rode de modo seguro, evitando travamentos,
desperdícios de memória e garantindo um alto desempenho. As vantagens do Just In Time Compiler
já mencionadas, também estão presentes no projeto Mono.
Assim como na plataforma .NET, no Mono uma aplicação é compilada para a IL
(Intermediate Language – Linguagem Intermediária). Isto garante a portabilidade da aplicação, já
que o Mono pode ser instalado nos sistemas operacionais Linux, Solaris, Mac OS X, Windows e
Unix (MONO, 2008, tradução nossa).
Para executar o mesmo software em sistemas operacionais diferentes, algumas práticas
devem ser adotadas, já que nem todos eles foram criados da mesma forma (BORNSTEIN;
DUMBILL, 2004 tradução nossa). A primeira delas trata da diferença no caractere separador de
diretórios quando se está trabalhando com arquivos. A Figura 2 demonstra estas diferenças.
String directory = “tmp”;
String filename = “thefile”;
//Modo incorreto
String filePath = directory + “/” + filename;
//Modo correto 1
String filePath = System.IO.Path.Combine(directory, filename);
//Modo correto 2
String filePath = directory + System.IO.Path.DirectorySeparatorChar + filename;
Figura 2. Tratamento de arquivos para sistemas multi-plataforma.
Fonte: Adaptado de Bornstein e Dumbill (2004).
No mesmo contexto de arquivos, ainda existem problemas ao se trabalhar com o diretório raiz. No
sistema operacional linux, existe apenas um diretório raiz o /. No Windows, podem existir vários
diretórios sendo diferenciados por letras (C:\, D:\, ...). Para contornar este problema, pode-se utilizar
o método System.IO.Directory.GetLogicalDrives(), que retornará uma ou mais Strings contendo os
9
diretórios raízes do sistema operacional. Além disto, deve-se ressaltar que alguns sistemas
operacionais são sensíveis à caixa (como o Linux) e outros não (como o Windows).
Outro problema é a definição de qual módulo de interface gráfica (GUI) utilizar. Para o
Mono, pode-se utilizar os módulos GTK#, Qt#, System.Windows.Forms entre outros. Cada um
deles é recomendado para diferentes sistemas operacionais e/ou ambientes gráficos. O GTK# é
principalmente destinado para ser utilizado no Gnome além de ter boa compatibilidade com o
Windows de 32 bits, demonstrado pelas Figura 3 e Figura 4 (SCHÖNIG; GESCHWINDE, 2003,
tradução nossa). Já o System.Windows.Forms é o mais recomendável para o uso no Windows, e é
compatível com as versões x86 do linux (BORNSTEIN; DUMBILL, 2004, tradução nossa).
Figura 3. GTK# no Linux.
Figura 4. GTK# no Windows.
Outro ponto crítico é quando se trata das configurações de cada aplicação desenvolvida. Em
aplicativos para Windows, na maioria das vezes, as aplicações guardam suas configurações no
registro, não presente em outros sistemas operacionais. Portanto, não se pode desenvolver
10
aplicações que utilizam o registro do Windows, caso o objetivo a ser alcançado seja a portabilidade
do aplicativo (IBIDEM).
Existem outros tipos de compatibilidades e para lidar com elas faz-se necessário uma
codificação específica para cada plataforma. A detecção de diferentes plataformas através do código
fonte é demonstrada pela Figura 5. Utilizando o atributo VersionString, é possível utilizar if ou
switch-case para separar códigos de diferentes sistemas operacionais.
using System;
using System.Diagnostics;
namespace soDetection
{
class MainClass
{
public static void Main(string[] args)
{
OperatingSystem os = Environment.OSVersion;
Console.WriteLine(os.VersionString);
}
}
}
Figura 5. Código fonte para detecção de plataforma.
Fonte: Adaptado de Bornstein e Dumbill (2004).
Os resultados da execução do código da Figura 5 são exibidos pelas Figura 6 para o sistema
operacional Linux e Figura 7 para o Windows XP Service Pack 3.
Figura 6. Resultado da detecção do sistema operacional no Linux.
Figura 7. Resultado da detecção do
sistema operacional no Windows XP.
11
Mono é uma boa alternativa para os desenvolvedores, entretanto, ele não possui todas as
classes do .NET Framework disponíveis. A Figura 8 mostra os estados das partes do namespace
System, o maior e mais utilizado.
Figura 8. Status do desenvolvimento do namespace System.
Fonte: Mono (2008).
2.2 Modelos, arquiteturas e protocolos de gerência
Atualmente existem várias arquiteturas, modelos e protocolos de monitoramento de redes
propostos por várias organizações em todo o mundo. Uns são utilizados em larga escala enquanto
outros não passam de conceitos. As arquiteturas, modelos e protocolos de gerência direcionados às
redes de dados serão mostrados nos sub-tópicos seguintes.
2.2.1 Conceitos
O ambiente de gerenciamento OSI (Open Systems Interconnection – Interconexão de
Sistemas Abertos) de redes possui os conceitos de Gerente, Agentes e Objetos Gerenciados. O
Gerente possui a capacidade de receber notificações, informações e realizar ações de controle sobre
12
os Objetos Gerenciados. Um objeto gerenciável é qualquer recurso que está sujeito a ações de
gerenciamento, como uma conexão, uma interface de rede ethernet ou uma porta de roteador, etc. O
Agente executa operações de gerenciamento sobre os objetos gerenciados, como desligar a interface
11 do switch ou solicitar a quantidade de octetos que trafegaram na referida porta. Neste ambiente,
aplica-se o protocolo CMIP (TAROUCO et al, 1993).
No ambiente de gerenciamento das redes interligadas à Internet, aplica-se o protocolo
SNMP (Simple Network Management Protocol – Protocolo Simples de Gerencia de Redes). Este
ambiente é bastante semelhante ao de gerenciamento OSI, pois a maioria dos conceitos abordados é
comum a ambos. Entretanto, a organização da árvore de objetos gerenciados é diferente (IBIDEM).
A MIB (Managed Information Base – Base de Informações Gerenciais) é um conjunto de
objetos gerenciados. Seu conceito é empregado tanto no padrão OSI quanto no Internet (IBIDEM).
A organização de objetos na MIB é feita seguindo um conjunto de regras definidos na SMI
(Structure of Managed Information – Estrutura de Informações Gerenciais). O acesso aos dados dos
objetos é feito utilizando a notação ISO ASN.1 (Abstract Syntax Notation, One- Notação de Sintaxe
Abstrata, Um). Para identificar um objeto, utiliza-se o OID (Object Identifier – Identificador de
Objeto) que são números separados por pontos. A Figura 9 ilustra o início da árvore do ambiente de
gerenciamento Internet (MAURO; SCHMIDT, 2001, tradução nossa).
Figura 9. MIB do ambiente de gerenciamento Internet.
Fonte: Adaptado de TAROUCO et al (1993) e MAURO e
SCHMIDT (2001).
13
Para o Objeto “Management”, o OID resultante seria .1.3.6.1.2. Todo objeto gerenciável
deste modelo iniciará com o identificador exemplificado. Segundo Mauro e Schmidt (2001,
tradução nossa), “O Nó Raiz não possui qualquer nome ou número”. A descrição da SMI Internet
será aprofundada adiante.
Neste sub-seção, foram explicados os conceitos necessários para o entendimento dos subseções seguintes.
2.2.2 FCAPS: Fault, Configuration, Accounting, Performance and Security
FCAPS é um modelo de gerência de redes definido por ITU-T que era direcionado a área de
telecomunicações. A ISO (International Standards Organization – Organização de Padrões
Internacionais) foi a entidade responsável por aplicar a FCAPS em redes de dados. Este modelo
divide a gerência em cinco áreas funcionais (NETWORKDICTIONARY, 2008a, tradução nossa):
•
Fault Management (gerência de falhas): serve para detectar, criar registros, notificar os
usuários e até consertar possíveis erros fazendo com que a rede continue funcionando.
Ao ocorrer um erro, uma mensagem o gerente de rede pode ser avisado, através de um
protocolo de gerência de redes como o SNMP.
•
Configuration Management (gerência de configurações): serve para monitorar a rede, as
configurações do sistema, além das várias versões de hardware e software. A
importância deste item aumenta conforme o tamanho da rede.
•
Accouting Management (gerência de contas): a medição da utilização da rede pode ser
monitorada de forma individual ou por grupo. Além disto, pode-se detectar se a rede está
sendo utilizada para o propósito correto. Alguns dos itens que podem ser monitorados
são: uso de CPU, link e disco. Para este propósito, um protocolo bastante utilizado é o
RADIUS.
•
Performance Management (gerência de desempenho): as variáveis que compõem a
medição do desempenho de uma rede são a vazão (throughput) da rede, os tempos de
resposta e a taxa de utilização da rede. Este item trata justamente desta medição.
•
Security Management (gerência de segurança): este item trata da segurança da rede,
garantindo que as informações que trafegam nela sejam acessadas apenas por pessoas
autorizadas, além de evitar que a rede sofra algum tipo de ataque.
14
O modelo FCAPS é uma extensão de um framework conceitual de gerencia de redes
chamado TMN (Telecommunications Management Networks – Gerência de Redes de
Telecomunicações), no qual também se identificam as mesmas cinco áreas de funcionais de
gerenciamento, com pequenas alterações (IBIDEM).
O objetivo do TMN é:
...prover uma estrutura organizada para interconectar vários tipos de Sistemas de Suporte à
Operação e equipamentos de telecomunicações para a troca de informações de
gerenciamento de interfaces padronizadas que incluem a definição de protocolos e
mensagens (TAROUCO et al, 1993).
O FCAPS define várias regras que abordam os principais aspectos da gerência de redes.
Outra abordagem que mescla diversos aspectos das práticas de gerência apresentadas é o CMIP.
2.2.3 CMIP/CMISE
CMIP (Common Management Information Protocol – Protocolo de Gerência de
Informações Comuns) que é um protocolo da ISO (International Standards Organization –
Organização Internacional de Padrões) e é utilizado em conjunto com o CMIS (Common
Management Information Services – Serviço de Gerência de Informações Comuns). Este padrão em
conjunto com o padrão SNMP são os mais importantes (Networkdictionary, 2008a, tradução nossa).
Conforme Kurose e Ross (2007), o CMIP foi projetado para ser independente de produtos ou
fabricantes específicos e inicialmente era concorrente do protocolo SNMP.
Tanto CMIP quanto CMISE também são utilizados na arquitetura CMOT (Common
Management over TCP/IP – Gerenciamento comum sobre TCP/IP) (TAROUCO et al, 1993) ou
(CMIP over TCP/IP – CMIP sobre TCP/IP) (MILLER, 1997, tradução nossa). O CMOT é baseado
na estrutura de gerenciamento OSI e nos modelos, serviços e protocolos desenvolvidos pela OSI
para gerenciamento de redes (TAROUCO et al, 1993).
Conforme o Networkdictionary (2008b, tradução nossa), o CMIS define um sistema de
gerência de redes, já o CMIP supre a necessidade da existência de uma interface que provê funções
que podem ser utilizadas tanto por protocolos de gerência de redes que estão conformes com a ISO
e até por protocolos customizados.
CMIP utiliza o mecanismo de transporte orientado à conexão já que utiliza o protocolo TCP.
Isto pode ser considerado uma desvantagem, já que se um dispositivo de rede estiver com
15
problemas, o software de gerência só poderá receber dados do dispositivo após efetuar uma conexão
com este. Apesar disso, este protocolo possui embutido um sistema de segurança que suporta
controle de acesso, autorização e gravação de registros. Quando aplicado na arquitetura CMOT, o
CMIP pode ser utilizado com o protocolo LPP (Lightweight Presentation Protocol – Protocolo de
Apresentação Simples). Neste caso, devido o uso do LPP, o CMIP poderá rodar tanto no protocolo
TCP quanto no UDP, conforme em Tarouco et al (1993):
O CMOT deixa a escolha de TCP ou UDP para a aplicação de gerenciamento. Os sistemas
dentro de um ambiente de LAN (Local Area Network – Rede local) são melhor servidos
pela escolha do UDP, enquanto os sistemas em um ambiente WAN (Wide Area Network –
Rede de longa distância) deveriam escolher TCP.
O protocolo CMIP de modo algum especifica o software de gerenciamento, apenas define
como será a comunicação entre agentes e o software (Networkdictionary, 2008b, tradução nossa).
Este esquema de comunicação é mostrado na Figura 10.
Figura 10. Sistema de gerenciamento baseado em CMIP/CMIS.
Fonte: Adaptado de Networkdictionary (2008b).
Conforme Networkdictionary (2008b, tradução nossa), o CMIP possui vantagens quando
comparado ao SNMP:
16
•
CMIP além de obter informações, pode realizar tarefas, o que é impossível no SNMP.
•
Possui segurança embutida.
•
Provê recursos poderosos que permitem aplicações gerenciais de realizarem mais tarefas
com uma única requisição.
•
Em redes em condições incomuns, ele gerará relatórios melhores.
O acesso de informações gerenciais em objetos gerenciáveis é feito através do CMISE
(Common Management Information Service Element – Elemento do Serviço de Gerência de
Informações Comuns), o qual utiliza o CMIP para requisitar informações (TAROUCO et al, 1993).
Por último, é revisado o SNMP, protocolo para a gerência que se consolidou com o advento
da Internet.
2.2.4 SNMP
O SNMP (Simple Network Management Protocol – Protocolo Simples para o
Gerenciamento de Redes) é um protocolo de gerência de redes. Foi introduzido em 1988 para suprir
uma necessidade crescente de gerenciamento de dispositivos que utilizam o protocolo IP (Internet
Protocol) como roteadores, switches, modems, access points, etc. Seu coração é um conjunto
simples de operações que permite aos softwares de gerência relatarem os dados de dispositivos de
rede suportados. Por exemplo, pode-se utilizar SNMP para desligar uma interface de um roteador
ou checar a velocidade da interface Ethernet. SNMP pode ainda monitorar a temperatura de um
switch e até gerar um alerta se esta ficar muito alta (MAURO; SCHMIDT, 2001, tradução nossa).
Existem atualmente três versões do protocolo SNMP (IBIDEM):
•
SNMP versão 1 (SNMPv1): é a versão definida pelo RFC 1157 (RFC 1157, 1989),
padrão da IETF (Internet Engineering Task Force – Força Tarefa de Engenharia da
Internet). A segurança desta versão é baseada em comunidades, que nada mais são do
que senhas. Pode-se definir uma comunidade com acessos de somente leitura para
acessar apenas informações ou leitura e escrita que podem alterar configurações. Uma
terceira comunidade é chamada de trap.
•
SNMP versão 2 (SNMPv2): esta versão é chamada tecnicamente de SNMPv2c. É
definida pelos RFC 1905 (RFC 1905, 1996), RFC 1906 (RFC 1906, 1996) e RFC 1907
17
(RFC 1907, 1996). Segundo a IETF, ainda encontra-se em estado experimental,
entretanto, alguns fabricantes de equipamentos de rede já estão disponibilizando
equipamentos de rede com suporte desta versão.
•
SNMP versão 3 (SNMPv3): ainda em estado experimental, a SNMPv3 terá vários
recursos novos como uma autenticação mais segura e comunicação privada entre
entidades gerenciadas. A versão é definida pelos RFC da versão 2 e os RFC 2571 (RFC
2571, 1999), RFC 2572 (RFC 2572, 1999), RFC 2573 (RFC 2573, 1999), RFC 2574
(RFC 2574, 1999) e RFC 2575 (RFC 2575, 1999).
O protocolo SNMP não é orientado a conexões como o CMIP, já que utiliza o protocolo
UDP (User Datagram Protocol – Protocolo de Datagrama do Usuário). Isto significa que o SNMP
possui um desempenho superior, já que não existe um overhead (sobrecarga) da conexão. Além
disso, o UDP não possui timeouts, este é programado diretamente no software de gerenciamento.
2.2.4.1 Gerenciadores e Agentes
O protocolo SNMP aplica os conceitos de gerente e agente (MILLER, 1997, tradução
nossa). O Gerenciador, também conhecido como NMS (Network Management Station – Estação de
Gerenciamento da Rede) se comunica com os agentes através de requisições chamadas polling
(teste e resposta). O Agente pode alertar o NMS quando utiliza os traps, que funcionam como
gatilhos que são disparados caso alguma condição seja alcançada (MAURO; SCHMIDT, 2001,
tradução nossa).
A Figura 11 mostra a relação entre o NMS e o Agente. Apesar de que a figura demonstre
ações de forma separada, o NMS pode realizar o polling e receber traps ao mesmo tempo.
Figura 11. Relação entre o NMS e o Agente.
Fonte: Adaptado de Mauro e Schmidt (2001).
18
Assim como os agentes e o NMS, o conhecimento sobre a SMI e suas versões é primordial
para o entendimento do protocolo SNMP.
2.2.4.2 SMIv1
Cada versão do protocolo SNMP possui uma versão de SMI. Na SMI versão 1, a definição
de Objetos Gerenciáveis é composta por três itens:
1. Nome: é o que identifica o objeto gerenciável. Este item pode ser um nome ou o OID
(Object Identifier).
2. Tipo e sintaxe: O tipo do objeto é definido usando a sintaxe ASN.1. É um modo de
definir como os dados serão transmitidos entre gerenciadores e agentes. Os tipos de
objetos são parecidos com os da linguagem C. A Tabela 1 exibe os principais tipos.
3. Encoding (Codificação): Uma instância de um objeto gerenciado é codificada numa
string de octetos usando BER (Basic Encoding Rules – Regras Básicas de Codificação).
Tabela 1. Tipos de dados SMIv1
Tipo de dado
Integer
Octect String
Counter
Object Identifier
Sequence
Sequence of
IP Address
Gauge
TimeTicks
Descrição
É um número inteiro de 32 bits, bastante utilizado para dados enumerados.
Para enumeração, o 0 não é considerado.
É uma string (seqüência de caracteres) de octetos, usado para transmissão
de texto ou identificação física de uma interface de rede.
É um valor de 32 bits com o valor mínimo zero e o máximo igual a 232-1.
Quando o valor máximo é atingido, ele volta para zero e recomeça. É
utilizado para contagem de qualquer item, como quantidade de erros numa
interface de redes ou octetos que trafegaram nesta interface. É um valor que
sofre incrementação, sendo que uma decrementação ocorre apenas em casos
de erros. Quando o agente é reiniciado, os dados do tipo Counter recebem
zero.
O OID é definido por números decimais separados por pontos.
Define uma lista de vários tipos de dados com sintaxe ASN.1, parecendo
uma tabela.
Define um objeto gerenciável feito com o tipo Sequence.
É um valor de 32 bits que representa um IP versão 4. Ambas as SMIv1 e
SMIv2 não possuem suporte ao IP versão 6.
É um valor de 32 bits com o valor mínimo zero e o máximo igual a 232-1.
Diferente do Counter, este tipo pode decrementar normalmente. A
velocidade de uma interface de um roteador é medida com Gauge.
É um valor de 32 bits com o valor mínimo zero e o máximo igual a 232-1.
Este tipo mede o tempo em centenas de segundos. O uptime (tempo ligado)
de um dispositivo é medido com este tipo.
Fonte: Adaptado de Mauro e Schmidt (2001).
19
Como já mencionado, os objetos gerenciáveis estão dispostos na SMI numa estrutura em
árvore. É através desta árvore que se define o Object Identifier (identificador do objeto). A árvore
SMI com suas partes mais importantes é demonstrada na Figura 12.
Figura 12. A árvore de objetos da SMIv1.
Fonte: Adaptado de Mauro e Schmidt (2001).
2.2.4.3 MIB do SMIv1
Uma MIB é definida usando a sintaxe ASN.1. Conforme Mauro e Schmidt (2001), “É muito
importante que se saiba ler e entender uma MIB já que em alguns casos pode ser necessário
implantar uma ou parte dela”. Na Figura 13 é demonstrado o código de uma versão de uma MIB.
Os comentários são iniciados por -- .
RFC1213-MIB DEFINITIONS ::= BEGIN
IMPORTS
mgmt, NetworkAddress, IpAddress, Counter, Gauge,
TimeTicks
FROM RFC1155-SMI
OBJECT-TYPE
FROM RFC 1212;
mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }
Figura 13. Primeiras linhas de uma MIB.
Fonte: Mauro e Schmidt (2001).
As primeiras linhas de uma MIB foram apresentadas na Figura 13. Na primeira linha,
define-se o nome da MIB, que no caso é “RFC1213-MIB” (RFC 1213 – 1991). A sessão IMPORTS,
permite que sejam importados tipos de dados e OIDs de outras MIBs. No caso acima, foram
importados tipos de dados da RFC 1155 (RFC 1155, 1990) SMI (SMIv1), que incluem:
20
•
mgmt;
•
NetworkAddress;
•
IpAddress;
•
Counter;
•
Gauge; e
•
TimeTicks.
Além disso, foi importado o Object Type RFC 1212 (RFC 1212, 1991), o qual define a
maneira de como a MIB foi escrita. A última linha da Figura 13 define o início dos OIDs dos
objetos gerenciáveis. Por ser mgmt, o OID equivalente é 1.3.6.1.2. Após a sessão de IMPORTS,
parte-se então para a definição dos objetos gerenciáveis (IBIDEM), que seguem o formato
demonstrado pela Figura 14.
<nome> OBJECT-TYPE
SYNTAX <tipo de dado>
ACCESS <pode ser read-only, read-write, write-only, ou not-accessible>
STATUS <mandatory, optional, ou obsolete>
DESCRIPTION
"Descrição textual do objeto gerenciável."
::= { <Um OID único do objeto gerenciável.> }
Figura 14. Formato da declaração de objetos gerenciáveis.
Fonte: Mauro e Schmidt (2001).
Para exemplificar a definição de objetos gerenciáveis, utilizou-se o ifTable, que nada mais é
que uma lista de interfaces de rede num dispositivo gerenciável.
ifTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A list of interface entries. The number of entries is given by
the value of ifNumber."
::= { interfaces 2 }
Figura 15. Definição de objetos gerenciáveis.
Fonte: Mauro e Schmidt (2001).
A sintaxe deste objeto é SEQUENCE OF IfEntry, que é uma tabela que possui colunas que
são definidas pela IfEntry. O objeto está marcado como inacessível, portanto, não é possível fazer
com que o agente consulte este objeto. Seu status é mandatory (obrigatório) significando que o
agente precisa implementar este objeto para ser compatível com os padrões da especificação MIB21
II. O campo Description (descrição) descreve o que é este objeto. Na última linha da Figura 15,
define-se o OID, que é 1.3.6.1.2.1.2.2 ou iso.org.dod.internet.mgmt.interfaces.2. Na Figura 16, é
demonstrado um trecho da definição da Sequence IfEntry.
IfEntry ::=
SEQUENCE {
ifIndex
INTEGER,
ifDescr
DisplayString,
ifType
INTEGER,
ifMtu
INTEGER,
(...)
ifSpecific
OBJECT IDENTIFIER
}
Figura 16. Definição da Sequence IfEntry.
Fonte: Mauro e Schmidt (2001).
Na definição da Sequence nota-se que seu nome começa com letra maiúscula, diferente de
quando se define um objeto gerenciável. Como uma Sequence se parece com uma tabela, nesta
esperamos encontrar todos os tipos descritos em sua definição. A adição de novos registros também
pode ser feita pelo NMS (MAURO; SCHMIDT, 2001, tradução nossa).
2.2.4.4 SMIv2 e sua MIB
A SMIv2 adiciona novos itens à arvore de objetos gerenciáveis além de mais tipos de dados.
A principal novidade é o ramo snmpV2, que possui o OID 1.3.6.1.6.3.1.1.. A Figura 17 exibe a
SMIv2.
Figura 17. SMIv2 e novos ramos.
Fonte: Mauro e Schmidt (2001).
22
Os novos tipos de dados incluídos na SMIv2 estão na Tabela 2.
Tabela 2. Novos tipos de dados da SMIv2
Tipo de dado
Integer32
Counter32
Gauge32
Unsigned32
Counter64
BITS
Descrição
Mesmo que Integer (inteiro).
Mesmo que Counter (contador).
Mesmo que Gauge.
Representa um valor decimal que vai de 0 até 232-1.
Similar
ao
Counter32,
entretanto
seu
valor
máximo
é
18.446.744.073.709.551.615. Sendo seu valor máximo bem alto, este tipo se
torna ideal para contadores que podem ser reiniciados antes do tempo
desejado.
Uma enumeração de bits não negativos.
Fonte: Adaptado de Mauro e Schmidt (2001).
Na SMIv2 também houve mudanças na especificação dos objetos gerenciáveis através da
adição de novos campos adicionais. Estes campos permitem que os objetos sejam descritos de
melhor maneira. A nova estrutura de descrição de objetos segue o modelo exibido na Figura 18.
<nome> OBJECT-TYPE
SYNTAX <tipo de dado>
UnitsParts <Opcional, veja descrição na Tabela 3>
MAX-ACCESS <Opcional>
STATUS <Ver descrição na Tabela 3>
DESCRIPTION
"Descrição textual deste objeto gerenciável."
AUGMENTS { <nome da tabela> }
::= { <O OID que representa este objeto.> }
Figura 18. Definição de objetos gerenciáveis na SMIv2.
Fonte: Mauro e Schmidt (2001).
Cada trecho dos aprimoramentos demonstrados na Figura 18, é descrito na Tabela 3.
Tabela 3. Aprimoramentos na definição de objetos.
Aprimoramento
UnitsParts
MAX-ACCESS
STATUS
Descrição
Uma descrição textual da unidade usada (segundos, milisegundos).
É um aprimoramento do ACCESS da SMIv1 (que também pode ser
utilizado nesta versão). A diferença, são os novos valores suportados:
read-only (somente leitura), read-write (leitura e escrita), read-create
(leitura e criação), not-accessible (não acessível) e accessible-for-notify
(acessível para notificação).
Esta clausula foi extendida para permitir os valores current, obsolete e
deprecated. O valor current tem o mesmo significado que mandatory da
SMIv1.
23
Augments
É utilizado em casos em que é importante adicionar uma ou mais
colunas novas a uma tabela. Esta clausula necessita que seja
especificado o nome da tabela que terá colunas adicionadas.
Fonte: Adaptado de Mauro e Schmidt (2001).
Na SMIv2 também são introduzidos novas convenções textuais, termos que fazem com que
o objeto gerenciável seja declarado de um modo mais abstrato. Os novos termos são definidos na
RFC 2579 (RFC 2579, 1999). A Tabela 4 apresenta esses termos.
Tabela 4. Novos termos
Convenção Textual
DisplayString
PhysAddress
MacAddress
TruthValue
TestAndIncr
AutonomousType
VariablePointer
RowPointer
RowStatus
TimeStamp
TimeInterval
DateAndTime
StorageType
TDomain
TAddress
Descrição
É uma seqüência de caracteres NVT ASCII, e não pode ultrapassar
255 caracteres.
Endereço físico ou da camada de enlace representado por uma cadeia
de octetos.
É o endereço MAC da interface de rede, definido por seis octetos,
sendo que o bit menos significante é o primeiro.
É um tipo booleano que recebe true (verdadeiro) ou false (falso).
Utilizado para evitar problemas quando duas estações de
gerenciamento modificam um único valor ao mesmo tempo.
É um OID utilizado para definir um novo ramo na árvore da MIB.
É um ponteiro para uma instância qualquer de um objeto gerenciável.
Este ponteiro contém o OID da instância.
É um ponteiro para uma tupla de uma tabela.
Usado para gerenciar a inserção e exclusão de tuplas numa tabela,
garantindo a integridade desta tabela. RowStatus pode receber os
valores active(1)(ativo), notInService(2)(fora de serviço),
notReady(3)(fora de prontidão), createAndGo(4)(criar e continuar),
createAndWait(5)(criar e esperar) e destroy(6)(destruir).
Mede o tempo que passou desde que o dispositivo foi ligado até o
momento de alguma ocorrência.
Mede um período de tempo em centenas de segundos, podendo
receber valores de 0 até 2147483647.
É um Octect String utilizado para representar a data e o horário.
Define o tipo de memória que o agente está utilizando. Os valores
possíveis são other(1), volatile(2), nonVolatile(3), permanent(4) e
readOnly(5).
Fornece o tipo de serviço de transporte.
Fornece o endereço do tipo de transporte. Seu tamanho pode ser de 1
até 255 octetos.
Fonte: Adaptado de Mauro e Schmidt (2001).
24
2.2.4.5 MIB-II
MIB-II é um importante grupo de gerenciamento, porque todos os dispositivos que suportam
SNMP também suportam este grupo (MAURO; SCHMIDT, 2001, tradução nossa). MIB-II é um
ramo da árvore SMI, o qual deriva do nó mgmt(2). A Figura 19 demonstra graficamente o ramo
MIB-II.
Figura 19. MIB-II.
Fonte: Adaptado de Mauro e Schmidt (2001).
A Tabela 5 explica brevemente cada item desta sub-árvore.
Tabela 5. Explicação dos ramos da MIB-II
Ramo
System
OID
1.3.6.1.2.1.1
Interfaces
1.3.6.1.2.1.2
At
1.3.6.1.2.1.3
Ip
1.3.6.1.2.1.4
Icmp
1.3.6.1.2.1.5
Tcp
Udp
1.3.6.1.2.1.6
1.3.6.1.2.1.7
Egp
1.3.6.1.2.1.8
Descrição
Alguns dos itens mais importantes deste são o uptime do
sistema, contato do administrador e o nome do sistema.
Possui informações sobre o estado de cada interface de rede
como, octetos enviados, octetos recebidos, se está ligada ou
desligada, etc.
Este ramo só existe para manter a compatibilidade com
versões mais antigas de algumas aplicações. Este ramo trata de
tradução de endereços.
Possui várias informações sobre vários aspectos do protocolo
IP, incluindo roteamento.
Possui informações sobre o ICMP, como erros e descarte de
pacotes.
Rastreia, entre outros itens, o estado de uma conexão TCP.
Com ele é possível construir estatísticas sobre o protocolo
UDP, contendo informações como a quantidade de pacotes
que entraram e saíram.
Possui dados sobre o protocolo EGP (Exterior Gateway
Protocol – Protocolo de gateway externo).
25
transmission
1.3.6.1.2.1.10
Snmp
1.3.6.1.2.1.11
Este ramo é raramente utilizado, sendo que é utilizado em
MIBs de dispositivos mais específicos.
Possui dados sobre o protocolo SNMP no dispositivo que está
sendo gerenciado, como a quantidade de pacotes SNMP
enviados e recebidos, traps, etc.
Fonte: Adaptado de Mauro e Schmidt (2001).
2.2.4.6 Operações do protocolo SNMP
No protocolo SNMP e em suas versões, existem as seguintes operações ou PDU’s (Protocol
Data Unit – Unidade de Dados do Protocolo) (MILLER, 1997, tradução nossa): get, get-next, getbulk, set, get-response, trap, notification, inform, report (MAURO; SCHMIDT, 2001, tradução
nossa). Algumas das principais operações são descritas a seguir.
Operação get
Esta operação é iniciada apenas pelo NMS e ocorre quando este necessita de alguma
informação do dispositivo que está sendo gerenciado. Ao fazer a requisição o OID do objeto é
passado como um parâmetro. Em casos em que o dispositivo está com sobrecarga de
processamento, é possível que o dispositivo descarte o pacote (MAURO; SCHMIDT, 2001,
tradução nossa). Esta operação está disponível em todas as versões do SNMP. A resposta do agente
é adquirida utilizando a operação get-response (MILLER, 1997, tradução nossa).
Operação get-next
Esta operação tem o seu funcionamento semelhante ao da operação get. Entretanto, esta
operação é utilizada para receber um grupo de informações. A operação get-next navega na árvore
utilizando a técnica top-down (MAURO; SCHMIDT, 2001, tradução nossa).
Operação get-bulk
Esta operação está disponível apenas nas versões 2 e 3 do SNMP (IBIDEM). get-bulk
permite que o NMS requisite um grande número de dados de um objeto gerenciável. É uma
operação que também se assemelha a operação get. Entretanto, a operação get gera erros ao
requisitar um grande número de dados em casos em que o dispositivo esteja muito ocupado. Mas no
caso do get-bulk, segundo MILLER (1997, tradução nossa) e MAURO e SCHMIDT (2001,
tradução nossa), a operação evita este erro, retornando dados incompletos.
26
Operação set
A operação set está disponível em todas as versões do SNMP. Esta é utilizada para alterar o
valor de um objeto gerenciável ou criar uma nova tupla em uma tabela, dependendo é claro, das
permissões (MILLER, 1997, tradução nossa).
Traps
Trap é a maneira utilizada pelo agente de comunicar o NMS de um evento ocorrido. O
agente possui configurado quem é o destinatário destas traps, sendo que geralmente é configurado o
IP do NMS (MAURO; SCHMIDT, 2001, tradução nossa). Existem seis tipos genéricos de traps,
conforme a Tabela 6.
Tabela 6. Tipos de traps
Tipo
coldStart(0)
warmStart(1)
linkDown(2)
linkUp(3)
authenticationFailure(4)
egpNeighborLoss(5)
enterpriseSpecific(6)
Descrição
Indica que o agente foi reiniciado. Todos os objetos gerenciáveis do
tipo Counter e Gauge são zerados.
Indica que o agente se reiniciou. Neste caso nenhum objeto
gerenciável é alterado.
É enviado caso alguma interface do dispositivo foi desconectada ou
desligada.
É enviado caso alguma interface do dispositivo foi conectada ou
ligou.
Indica que alguém tentou fazer alguma requisição ao agente e ele
negou devido a uma falha de autenticação.
Indica a perda de conexão com um vizinho que utiliza o protocolo
EGP.
Esta trap é configurada ou especificada de acordo com o fabricante
do dispositivo. Nestes casos, o NMS necessita decodificar a trap.
Fonte: Adaptado de Mauro e Schmidt (2001).
2.3 Softwares de monitoramento
Os sistemas de monitoramento descritos nesta seção servirão como fonte de requisitos para a
construção de um novo sistema. Os softwares escolhidos são: Nagios (NAGIOS, 2008) e Cacti
(CACTI, 2008), que são bastante utilizados atualmente.
2.3.1 Nagios
Nagios (NAGIOS, 2008) é um software de monitoramento de hosts e de serviços, construído
para informar o administrador de problemas antes que estes sejam detectados pelo usuário final. Foi
27
desenvolvido inicialmente para rodar em Linux, mas atualmente ele roda em qualquer sistema
baseado em Unix. Para realizar os mais diversos tipos de monitoramento, Nagios faz uso de plugins,
que são específicos para cada tipo de monitoramento. O daemon (espécie de serviço) do Nagios
ativa estes plugins para que eles coletem as informações necessárias e assim as retorna para ele.
O Nagios utiliza plugins para realizar o monitoramento sendo, portanto, um software
bastante flexível, já que o administrador pode construir facilmente plugins específicos para um dado
tipo de aplicação. Aplicações já conhecidas e bastante utilizadas já possuem plugins construídos
(BURGESS, 2005, tradução nossa). A Tabela 7 possui uma lista dos principais plugins.
Tabela 7. Lista dos principais plugins do Nagios
Plugin
check_http
check_dns
check_dhcp
check_disk
check_dummy
check_imap
check_mysql
check_mysql_query
check_nntp
check_procs
Descrição
Este plugin testa os serviços de HTTP (Hypertext Transfer Protocol
– Protocolo de transferência de hipertexto) em um host específico.
Ele suporta o HTTP assim como o HTTPS (Hypertext Transfer
Protocol Secure – Protocolo de transferência de hipertexto seguro).
Além disto, ele pode consultar redirecionamentos, buscar por
expressões regulares, medir o tempo de conexão e verificar se algum
certificado está para expirar.
Este faz uso do software nslookup (já disponível em grande parte
dos Sistemas Operacionais) para verificar se o servidor DNS
(Domain Name Server – Servidor de Nomes de Domínios)
especificado pode traduzir o domínio para um endereço IP.
Utilizado para testar a disponibilidade de um dado servidor DHCP
(Dynamic Host Configuration Protocol – Protocolo de Configuração
Dinâmica de Hosts).
Utilizado para verificar a quantidade de espaço em disco disponível.
Ele pode gerar um alerta caso o valor crítico (configurável) seja
alcançado.
Ao invés de verificar o estado de um serviço, este plugin retorna
valores estipulados pelo administrador.
Faz a verificação de uma conexão IMAP (Internet Message Access
Protocol – Protocolo de Acesso para Mensagens da Internet).
Faz um teste de conexão com um banco de dados MySQL.
Um plugin para teste de banco de dados MySQL mais elaborado.
Este executa uma consulta no banco de dados, e o valor retornado é
comparado com o valor aceitável configurado, podendo emitir
alertas caso o valor aceitável seja ultrapassado.
Faz um teste de conexão com um host que possui NNTP (Network
News Transfer Protocol – Protocolo de Transferência de Notícias
pela Rede).
Faz uma checagem de todos os processos em um host e pode gerar
avisos e alertas críticos caso alguma métrica esteja fora dos
parâmetros configurados.
28
check_ping
check_smtp
check_tcp
check_udp
check_nt
Faz o uso de ICMP (Internet Control Message Protocol – Protocol
de Mensagens de Controle da Internet) para construir estatísticas de
conexão com um determinado host.
Este plugin simplesmente tentará abrir uma conexão com um
servidor SMTP (Simple Mail Transfer Protocol - Protocolo de
Simples Transferência de Emails).
Faz um teste de uma conexão de TCP (Transfer Control Protocol –
Protocolo de Controle de Transferência) qualquer com um
determinado host.
Semelhante ao check_tcp, mas testa com o protocolo UDP (User
Datagram Protocol – Protocolo Livre de Datagrama).
Este plugin coleta uma informação específica do serviço NSClient
rodando em hosts que estão rodando com Windows
NT/2000/XP/2003. A informação que se deseja é um parâmetro a
ser passado.
Com os plugins necessários instalados, pode-se então iniciar o monitoramento. É possível
instalar o Nagios já pré-configurado, de modo que ele já monitore a máquina em que está rodando e
o seu gateway. Nagios é configurado utilizando arquivos texto, e os arquivos padrões são exibidos
na Tabela 8.
Tabela 8. Arquivos padrões de configuração do Nagios
Arquivo
nagios.cfg
checkcommands.cfg
misccommands.cfg
timeperiods.cfg
cgi.cfg
contacts.cfg
contactgroups.cfg
hosts.cfg
hostgroups.cfg
Descrição
Contém configurações básicas como formato da data e hora. Por padrão,
este arquivo já vem configurado corretamente, bastando alteração de
poucos parâmetros.
Neste arquivo existem informações sobre os plugins e como eles serão
utilizados.
É o arquivo que contém diversos tipos de comandos que podem ser
executados, incluindo a configuração do comando de envio de alertas (por
celular, email, etc).
Neste arquivo é especificado quando o Nagios executará as verificações.
Contém as permissões dos usuários que acessarão as informações do
Nagios.
Este arquivo contém as definições de contatos para alertas e avisos.
Neste arquivo é possível construir grupos, especificando quais os contatos
fazem partes de cada grupo.
Este arquivo possui a lista e o modo de como os hosts serão monitorados.
Neste arquivo, cada host pode possuir especificado um endereço IP, um
apelido, o seu nome, os comandos de checagem, etc.
Neste arquivo é possível construir grupos de hosts, facilitando o
monitoramento.
Com o Nagios configurado, pode-se então verificar os dados coletados. Para isto, basta
acessar a página do Nagios, que possui um endereço configurado na instalação, fornecendo o
29
usuário e senha, também configurados no processo de instalação. A Figura 20 mostra a tela inicial
do Nagios.
Figura 20. Tela inicial do Nagios.
Fonte: Nagios (2008).
30
Para visualizar o estado dos serviços, seleciona-se a opção Service Details (Detalhes dos
Serviços). A tela que surgirá apresenta os hosts com seus respectivos serviços e estados. Além
disso, é exibida uma descrição detalhada do estado do serviço. A Figura 21 demonstra esta tela.
Figura 21. Detalhes dos hosts.
Fonte: Nagios (2008).
31
Para visualizar o estado dos hosts, é acessada a opção Host Detail (Detalhe do Host). Nesta
tela são exibidos todos os hosts com o respectivo estado e informações. A Figura 22 demonstra esta
tela.
Figura 22. Detalhes dos serviços.
Fonte: Nagios (2008).
Outro recurso interessante do Nagios é a exibição do Mapa da Rede (Network Map). Ele
consiste em exibir a topologia da rede graficamente, mostrando os computadores, roteadores, entre
outros hosts. Além disso, ele pode exibir qual Sistema Operacional o host está rodando, caso este
esteja especificado no arquivo “hosts.cfg”. A Figura 23 demonstra este recurso.
32
Figura 23. Recurso “Mapa da Rede”.
Fonte: Nagios (2008).
O Nagios possui vários recursos poderosos, entretanto, ele não possui nenhuma forma de
construção de gráficos. Grande parte dos administradores de rede vem adotando o Cacti como um
software adicional para a produção destes gráficos.
2.3.2 Cacti
Cacti (CACTI, 2008) é uma interface completa para o RRDtool (Round Robin Database
Tool – Ferramenta para Bancos de Dados Round Robin), coletando todas as informações
necessárias para construir gráficos e as gravando em uma base no banco de dados MySQL. Ele é
totalmente construído com a linguagem PHP. As configurações são todas feitas na interface Web do
Cacti e estas são também armazenadas no banco de dados MySQL.
33
O RRDtool é um padrão industrial OpenSource (código aberto) de alto desempenho para
armazenamento de informações e gráficos que representam dados temporais. Esta ferramenta pode
ser utilizada em conjunto com as linguagens PHP, Python, Perl, Ruby e TCL (OETIKER, 2008,
tradução nossa).
Para iniciar o uso do Cacti, basta acessar a URL na qual ele se encontra. Deve-se fornecer o
usuário “admin” e a senha “admin”, sendo que a senha deve ser alterada no primeiro acesso. A tela
inicial é demonstrada na Figura 24.
Figura 24. Tela inicial do Cacti.
Fonte: Cacti (2008).
Na parte superior da tela, o Cacti apresenta duas opções: console (gerência de configurações) e
graphs (gráficos). A tela inicial iniciará com a opção console já selecionada, e nesta opção é
possível cadastrar, alterar ou excluir algum dispositivo e/ou gráfico.
34
A tela de cadastro e alteração de dispositivos de rede do Cacti é demonstrada na Figura 25.
Os campos a serem preenchidos são descritos a seguir, sendo que parte deles já é preenchida com
valores padrão.
•
Description (descrição): deve ser preenchido com alguma informação útil sobre o
dispositivo.
•
Hostname (nome do host): deve ser preenchido com o nome do dispositivo de rede ou
seu endereço IP.
•
Host Template (modelo do host): deve-se selecionar em qual modelo o host se enquadra.
Os modelos já incluídos no Cacti são: Cisco Router (Roteador da marca Cisco), Generic
SNMP-enabled Host (Host genérico com SNMP ativo), Karlnet Wireless Bridge (Ponte
de rede sem-fio da marca Karlnet), Local Linux Machine (Máquina Local com sistema
operacional Linux), Netware 4/5 Server (Servidor Netware versão 4 ou 5), ucd/net
SNMP Host, Windows 2000/XP Host.
•
Notes (notas): neste campo é possível cadastrar informações sobre o dispositivo já que é
um campo bastante grande.
•
Disable Host (inativar host): este campo é selecionado caso deseja-se que o dispositivo
não seja verificado pelo Cacti.
•
Downed Device Detection (Detecção de dispositivos desconectados/desligados): o modo
de como é feita a detecção do dispositivo na rede. Pode ser selecionado por Ping ou
desativar a detecção.
•
Ping Method (método do ping): é o modo de como o ping será executado caso a opção
Downed Device Detection esteja marcada como ping. Pode-se executar o ICMP Ping,
TCP Ping e UDP Ping.
•
Ping Port (porta para o ping): seleciona-se a porta para a qual o ping irá “disparar”.
Somente em casos de TCP Ping e UDP Ping.
•
Ping timeout (tempo limite para resposta do ping): a métrica deste campo é em milisegundos.
•
Ping Retry Count (número de tentativas de ping): é informada a quantidade máxima de
vezes em que é tentada a realização do ping.
35
•
SNMP Version (versão SNMP): neste campo pode-se selecionar entre as versões 1, 2 ou
3 do protocolo SNMP. Dependendo da versão selecionada, os campos seguintes se
alteram. Para exemplificar, foi selecionada a versão 2.
•
SNMP Community (Comunidade SNMP): é preenchido o nome da comunidade SNMP
que foi configurada no agente do dispositivo. Já que o Cacti apenas coleta informações
dos dispositivos, uma comunidade com privilégios de apenas leitura é o suficiente.
•
SNMP port (porta do SNMP): este campo é preenchido o número da porta em que o
agente SNMP do dispositivo está “escutando”.
•
SNMP timeout (tempo limite do SNMP): preenchido com o tempo máximo de espera
pela resposta de uma requisição SNMP. O valor é em mili-segundos.
•
Maximum OID’s per Get Request (quantidade máxima de OIDs por requisição): é
informada a quantidade máxima de OIDs que uma operação SNMP do tipo get pode
retornar.
36
Figura 25. Cadastro e/ou alteração de um dispositivo de rede no Cacti.
Fonte: Cacti (2008).
Depois de preenchidos os campos, basta acionar o botão Create (criar) e o dispositivo é
cadastrado no banco de dados e então passa a ser monitorado.
Para visualizar os gráficos gerados pelo Cacti, basta selecionar a opção graphs no topo da
tela. A Figura 26 mostra esta visualização, exibindo apenas um gráfico, entretanto basta utilizar a
rolagem para mostrar os outros gráficos. No topo da tela existe um modo de montar o gráfico de
acordo com um período especificado. Inicialmente, o Cacti já preenche esses valores que exibem os
gráficos com base em dados das últimas 24 horas. No lado esquerdo da tela, é possível selecionar o
37
dispositivo que se deseja visualizar os gráficos (neste caso existe apenas um). Abaixo de cada
gráfico, o Cacti apresenta estatísticas.
Figura 26. Visualizando gráficos no Cacti.
Fonte: Cacti (2008).
Com o Cacti e o Nagios analisados, parte-se então para a criação de uma tabela com os
recursos destes softwares, contendo o que a solução proposta também irá possuir.
2.3.3 Tabela comparativa de softwares de gerência de redes
Na Tabela 9, é exibida uma tabela comparativa, mostrando os recursos mais importantes
disponíveis em cada um dos softwares de gerência de redes estudados e os recursos que foram
implementados na solução proposta.
38
Tabela 9. Tabela comparativa de softwares de gerência de redes
Recurso
Exibe o estado de
hosts
Exibe o estado de
serviços
Construção de gráficos
de uso de hosts e
serviços
Exibe a topologia da
rede
Exibe os hosts
distribuídos
geograficamente
Suporte ao SNMP
Suporte ao CMIP
Plataforma
Alerta por
Nagios
Sim
Cacti
Não
Solução Proposta
Sim
Sim
Não
Sim
Não
Sim
Sim
Sim
Não
Sim
Não
Não
Sim
Sim
Não
Web
Email, ...
Sim
Não
Web
Não possui
Sim
Não
Desktop
Email
39
3 PROJETO
Nesta sessão estão descritas as modelagens das duas aplicações propostas: Motor e Interface
do usuário. A modelagem utilizará a UML (Unified Modeling Language – Linguagem de
Modelagem Unificada), pois de acordo com Alhir (1998, tradução nossa), é uma linguagem de
modelagem visual pronta para usar extensível, simples, escalável, independente de linguagem e de
processo de desenvolvimento.
O produto final gerado por este trabalho é formado de um motor de coleta e interpretação
dos dados de estado dos hosts monitorados e por uma interface gráfica que processa e exibe as
informações em um formato adequando para o administrador da rede de computadores. Um
exemplo do funcionamento da solução é exibido pela Figura 27. Dependendo da infra-estrutura da
rede, é possível rodar a interface no mesmo computador que está rodando o motor.
Figura 27. Exemplo de uso.
Já o modelo em camadas é exibido Figura 28.
Figura 28. Modelo em camadas.
Host é qualquer dispositivo de rede gerenciável por SNMP. Ele normalmente executa dentro
de um sistema operacional (ex: Microsoft Windows, GNU/Linux, Cisco IOS) ou ainda em
firmwares 2que implementam o protocolo.
Motor implementa o software de tratamento de eventos propriamente dito. As principais
funções do motor do UNMS são: gravar ocorrências (log), enviar alertas, realizar o polling, além de
diversas outras menos perceptíveis pelos demais elementos.
Já a Interface oferece interação do motor com o ser humano. Nela estão contempladas todas
as rotinas de manipulação do motor, tais como cadastros, eventos, relatórios, gráficos e outros.
3.1 Requisitos Funcionais, Não Funcionais e Regras de Negócio
A descrição dos Requisitos Funcionais, Não Funcionais e as Regras de Negócio são
primordiais para a construção de qualquer software, pois descrevem o que e como será criado.
Motor e interface são descritos separadamente.
2
Software embutido em aparelhos eletrônicos, tais como modems, roteadores e switches, entre outros.
41
3.1.1 Motor
O motor será a aplicação responsável por coletar as informações dos hosts e serviços da rede
e armazená-las. Os requisitos funcionais identificados estão descritos a seguir:
•
RF01: O motor deve coletar as informações disponíveis de um host através do
protocolo SNMP.
•
RF02: O motor deve gravar as informações coletadas num banco de dados.
•
RF03: O motor deve realizar monitoramento por ICMP Echo/Reply em todos os
hosts cadastrados.
•
RF04: O motor deve possuir um mecanismo de auto-detecção de hosts na LAN.
Os requisitos não funcionais identificados estão a seguir. A categorização dos itens está
entre parênteses.
•
RNF01: O motor deve ser construído utilizando a linguagem de programação C#.
(implementação)
•
RNF02: O motor deve utilizar o SGDB PostgreSQL 8.2. (implementação)
•
RNF03: O motor deverá ser construído utilizando a plataforma Mono.
(implementação)
•
RNF04: O motor deve ser compatível com as versões 1 e 2 do protocolo SNMP.
(conformidade)
•
RNF05: O motor não deverá apresentar interface gráfica. (usabilidade)
•
RNF06: O motor será concebido como software livre, licenciado nos termos da
licença GPLv2 (General Public License 2- Licença Pública Geral) (GNU, 2008).
As regras de negócio identificadas estão a seguir:
•
RN01: Caso não haja configurações avançadas de um dado host, o motor irá
monitorá-lo com o uso ICMP-ECHO / ICMP-REPLY.
42
•
RN02: O motor não trata da configuração de traps nos dispositivos de rede.
3.1.2 Interface com o usuário
A interface com o usuário será a aplicação responsável por exibir os dados coletados na tela
bem como permitir a configuração do sistema. Os requisitos funcionais identificados são os
seguintes:
•
RF01: A interface deve permitir o cadastro de hosts.
•
RF02: A interface deve permitir o cadastro de serviços que serão monitorados.
•
RF03: A interface deve exibir a localização dos hosts cadastrados utilizando o
mecanismo do Google Earth.
•
RF04: A interface deve exibir uma tela de monitoramento que liste todos os hosts e
seu estado.
•
RF05: A interface deve exibir uma tela de monitoramento que liste todos os serviços
por host com o respectivo estado e descrição.
•
RF06: A interface deve permitir o cadastro de usuários.
•
RF07: A interface deve exibir a topologia da rede.
•
RF08: A interface deve exibir registros de eventos (logs).
•
RF09: A interface deve exibir graficamente, o histórico da taxa de uso dos itens
selecionados de cada host.
•
RF10: O sistema deve permitir que o usuário cadastre grupos de hosts.
•
RF11: A interface deve permitir ao usuário iniciar o recurso de auto-detecção da rede
o qual se encontra no motor.
•
RF12: A interface deve permitir a visualização do histórico de eventos de um host.
Os requisitos não funcionais identificados para a construção do software estão listados
abaixo. As categorias de cada requisito estão entre parênteses.
43
•
RNF01: A interface deve ser desenvolvida utilizando a linguagem de programação
Visual C#. (implementação)
•
RNF02: O Sistema de Gerenciamento de Banco de Dados que será utilizado é o
PostgreSQL. (implementação)
•
RNF03: A interface será concebida como software livre, licenciado nos termos da
licença GPLv2 (General Public License 2- Licença Pública Geral) (GNU, 2008).
As regras de negócio identificadas são as seguintes:
•
RN01: Cada serviço cadastrado deve estar com relacionado com um host
previamente cadastrado.
•
RN02: Cada item que está sendo grafado deve estar relacionado com um host
previamente cadastrado.
3.2 Diagramas de Caso de Uso
Os diagramas de caso de uso são importantes no projeto de qualquer sistema, pois de acordo
com Alhir (1998, tradução nossa), eles contêm os atores que representam os usuários do sistema,
incluindo os usuários humanos e outros sistemas, além de representar as funcionalidades ou
serviços providos pelo sistema para o usuário.
3.2.1 Motor
O diagrama de caso de uso construído para o Motor da aplicação é exibido na Figura 29.
Figura 29. Diagrama de casos de uso do
Motor.
44
3.2.2 Interface com o usuário
Já os diagramas de caso de uso para a interface são exibidos na Figura 30.
Figura 30. Diagrama de casos de uso da interface.
A descrição dos casos de uso da interface é feita a seguir.
3.2.2.1 UC01 – Efetuar login
Este caso de é responsável por efetuar o login no sistema.
Relações
•
RF06: A interface deve permitir o cadastro de usuários.
Condições
•
Pré-condição: Ter um usuário já cadastrado.
•
Pós-condição: Um usuário está autenticado no sistema.
Cenários
Faz o login {Principal}
45
1. Ao abrir o sistema, o usuário informa o seu nome de usuário e a senha (Figura 31).
2. Sistema verifica se o usuário e senha estão corretos.
3. O sistema fecha a tela de login e abre a tela principal.
Usuário e/ou senha inválidos {Exceção}
Se no passo 2 o usuário e/ou senha estiverem errados ou usuário não existe
2.1. O sistema exibe uma tela com a mensagem “Usuário e/ou senha inválidos”
Figura 31. Interface de login.
3.2.2.2 UC02 – Cadastra um host
Este caso de uso trata do cadastramento de hosts no sistema.
Relações
•
RF01: A interface deve permitir o cadastro de hosts.
•
RF10: O sistema deve permitir que o usuário cadastre grupos de hosts.
Condições
•
Pré-condição: Um usuário autenticado no sistema.
•
Pré-condição: Um tipo de host deve estar cadastrado.
•
Pré-condição: Um grupo de host deve estar cadastrado.
•
Pós-condição: Um host está cadastrado.
•
Pós-condição: O host cadastrado, se ativo, começa a ser monitorado.
46
Cenários
Cadastra o host {Principal}
1.
O usuário abre a interface de cadastro de hosts (Figura 32).
2.
O usuário informa os dados do novo host.
3.
O usuário clica em “Salvar”, ou no botão com um ícone de disquete.
Altera um host {Alternativo}
Se no passo 2 o usuário quiser alterar um host:
2.1. O usuário clica no ícone de lupa na parte superior e seleciona o host a ser alterado.
2.2. O usuário altera os dados do host.
2.3. O usuário clica em salvar.
Exlcui um host {Alternativo}
Se no passo 2 o usuário quiser excluir um host:
2.1. O usuário clica no ícone de lupa na parte superior e seleciona o host a ser alterado.
2.2. O usuário clica em Excluir ou no botão com um desenho de X.
2.3. Uma janela é exibida pedindo a confirmação da exclusão.
47
Figura 32. Interface principal do cadastro de
hosts.
48
Altera a Forma de Monitoramento {Alternativo}
Se no passo 2 o usuário quiser alterar ou configurar um modo de monitoramento diferente:
2.1. O usuário clica no botão “Monitoramento”.
2.2. O usuário altera os dados na interface que irá surgir conforme necessário (Figura
33).
2.3. O usuário clica em OK.
Figura 33. Interface de configuração de
monitoramento.
3.2.2.3 UC03 – Cadastra um serviço
Este caso de uso trata do cadastro de serviços que podem ser monitorados.
Relações
•
RF02: A interface deve permitir o cadastro de serviços que serão monitorados.
Condições
•
Pré-condição: Um host deve estar cadastrado.
•
Pós-condição: Um serviço está cadastrado.
Cenários
49
Cadastra o Serviço {Principal}
1. O usuário abre a interface de cadastro de hosts e clica em Serviços (Figura 34).
2. O usuário preenche os dados sobre o serviço.
3. O usuário clica em “Salvar”.
Altera um serviço {Alternativo}
Se no passo 2 o usuário quiser alterar um serviço:
2.1. O usuário seleciona o serviço na lista.
2.2. O usuário altera os dados do serviço conforme necessário (Figura 34).
2.3. O usuário clica em Salvar.
2.4. Caso as operações na janela foram finalizadas, o usuário clica em OK.
Exclui um serviço {Alternativo}
Se no passo 2 o usuário quiser excluir um serviço:
2.1. O usuário seleciona o serviço na lista.
2.3. O usuário clica em Remover.
2.4. Caso as operações na janela foram finalizadas, o usuário clica em OK.
50
Figura 34. Interface de cadastro de serviços.
3.2.2.4 UC04 – Cadastra um usuário
Este caso de uso trata do cadastro de um usuário que poderá utilizar o sistema de
monitoramento.
Relações
•
RF06: A interface deve permitir o cadastro de usuários.
Condições
•
Pré-condição: Um usuário autenticado no sistema.
•
Pós-condição: Um novo usuário foi cadastrado, alterado ou excluído no sistema.
Cenários
Cadastra o usuário {Principal}
1. O usuário abre a interface de cadastro de usuários (Figura 35).
2. O usuário informa os dados do novo usuário.
3. O usuário clica em “Salvar”.
51
Altera um usuário {Alternativo}
Se no passo 2 o usuário quiser alterar os dados de um usuário:
2.1. O usuário faz uma busca clicando no botão com desenho de uma lupa.
2.2. O usuário seleciona o usuário a ser alterado.
2.3. O usuário altera os dados do usuário selecionado.
2.4. O usuário clica em “Salvar”.
Exclui um usuário {Alternativo}
Se no passo 2 o usuário quiser alterar os dados de um usuário:
2.1 O usuário faz uma busca clicando no botão com desenho de uma lupa.
2.2. O usuário seleciona o usuário a ser excluído.
2.3. O usuário clica em “Excluir”.
2.4. Uma janela é exibida pedindo a confirmação da exclusão.
Figura 35. Interface de cadastro de usuários.
3.2.2.5 UC05 – Visualiza o estado dos hosts
Este caso de uso corresponde à visualização dos estados dos hosts cadastrados.
52
Relações
•
RF04: A interface deve exibir uma tela de monitoramento que liste todos os hosts e
seu estado atual.
Condições
•
Pré-condição: O usuário deve estar autenticado no sistema.
•
Pré-condição: Um host deve estar cadastrado no sistema.
Cenários
Visualização de Estados de Hosts{Principal}
1. O usuário abre a interface de visualização de estados de hosts (Figura 36).
2. O usuário pode selecionar o Grupo ou tipo de hosts para filtrar quais hosts devem ser
exibidos na lista.
Figura 36. Interface de visualização de estados de hosts.
3.2.2.6 UC06 – Visualiza os estados dos serviços dos hosts
Este caso de uso corresponde à visualização dos estados dos serviços de hosts cadastrados.
53
Relações
•
RF05: A interface deve exibir uma tela de monitoramento que liste todos os serviços
por host com o respectivo estado e descrição.
Condições
•
Pré-condição: O usuário deve estar autenticado no sistema.
•
Pré-condição: Um host deve estar cadastrado no sistema.
•
Pré-condição: Um serviço deve estar cadastrado.
Cenários
Visualização de Estados de Serviços dos Hosts {Principal}
1. O usuário abre a interface de visualização de estados de hosts (Figura 37).
2. O usuário pode selecionar o Grupo de hosts para filtrar quais serviços dos hosts
devem ser exibidos na lista.
Figura 37. Interface de visualização de estados dos serviços dos hosts.
54
3.2.2.7 UC07 – Visualiza a topologia lógica da rede
Este caso de uso corresponde à visualização da topologia lógica da rede.
Relações
•
RF07: A interface deve exibir a topologia lógica da rede.
Condições
•
Pré-condição: O usuário deve estar autenticado no sistema.
•
Pré-condição: Um host deve estar cadastrado no sistema.
Cenários
Visualização da Topologia Lógica da Rede {Principal}
1. O usuário abre a interface de visualização da topologia lógica da rede (Figura 38).
Figura 38. Interface de visualização da topologia da rede.
55
3.2.2.8 UC08 - Visualiza os hosts geograficamente no Google Earth
Este caso de uso corresponde à visualização dos hosts utilizando o mecanismo do Google
Earth.
Relações
•
RF03: A interface deve exibir a localização dos hosts cadastrados utilizando o
mecanismo do Google Earth.
Condições
•
Pré-condição: O usuário deve estar autenticado no sistema.
•
Pré-condição: Um host deve estar cadastrado no sistema.
Cenários
Visualização geográfica de hosts {Principal}
1. O usuário abre a interface de visualização do posicionamento geográfico dos hosts
(Figura 39).
2. O software Google Earth, se instalado, irá exibir os hosts cadastrados.
Figura 39. Interface para a chamada da
visualização de hosts no Google Earth.
56
3.2.2.9 UC10 – Visualiza gráficos de uso
Este caso de uso corresponde a visualização de gráficos de utilização e/ou carga de recursos
dos hosts.
Relações
•
RF09: A interface deve exibir graficamente, o histórico da taxa de uso dos itens
selecionados de cada host.
Condições
•
Pré-condição: O usuário deve estar autenticado no sistema.
•
Pré-condição: Um host deve estar cadastrado no sistema.
Cenários
Visualização de gráficos {Principal}
1. O usuário abre a tela de exibição de gráficos (Figura 40).
2. O usuário seleciona qual host, monitor e o período de visualização.
3. O usuário clica no botão Visualizar.
Figura 40. Visualização de gráficos.
57
3.2.2.10 UC11 – Visualiza registros de eventos
Este caso de uso corresponde a visualização de registros (logs).
Relações
•
RF08: A interface deve exibir registros de eventos (logs).
Condições
•
Pré-condição: O usuário deve estar autenticado no sistema.
Cenários
Visualização de registro de eventos {Principal}
1. O usuário abre a tela de exibição de eventos (Figura 41).
Figura 41. Visualização de eventos.
58
3.2.2.11 UC12 – Cadastro automático de hosts
Este caso de uso corresponde a auto-detecção de hosts na rede.
Relações
•
RF11: A interface deve permitir ao usuário iniciar o recurso de auto-detecção da
rede.
Condições
•
Pré-condição: O usuário deve estar autenticado no sistema.
•
Pós-condição: Um ou mais hosts foram adicionados no sistema.
Cenários
Detecção de hosts {Principal}
1. O usuário abre a tela de detecção de hosts (Figura 42).
2. O usuário seleciona o método de detecção.
3. O usuário clica em “Iniciar”.
4. Uma barra de progresso indica o andamento da detecção.
5. Ao final do processo, o usuário selecione os hosts a serem adicionados e clica em
salvar.
59
Figura 42. Detectando hosts.
3.3 Diagramas de Classe
De acordo com Booch, Rumbaugh e Jacobson (2005, tradução nossa), “Os diagramas de
classes são os diagramas encontrados com maior freqüência na modelagem de sistemas orientados a
objetos. Um diagrama de classes mostra um conjunto de classes, interfaces e colaborações e seus
relacionamentos”. As classes, de acordo com Alhir (1998, tradução nossa), são entidades que
possuem atributos, operações e associações. As associações representam o relacionamento entre
duas ou mais classes que possuem em comum, algumas características.
Para o correto entendimento do funcionamento e construção dos módulos, os diagramas de
classes são exibidos nas sessões seguintes.
60
3.3.1 Motor
A Figura 43 exibe o diagrama de classes do motor.
Figura 43. Diagrama de classes do motor.
A descrição de cada classe é exibida a seguir:
•
Host: Esta classe corresponde a um host;
•
HostService: Esta classe corresponde a um serviço que se encontra num host;
•
ServiceType: Esta classe representa um tipo de serviço;
•
DateTimePeriod: É uma classe simples que possui dois atributos que definem um
intervalo de tempo. Ela está ligada à classe Host, pois define quais intervalos de tempo
este não será monitorado;
•
HostData: Classe que guarda qualquer tipo de dado relacionado à um host. Normalmente
será preenchida por dados da MIB do host;
•
Trap: Classe representa uma trap recebida pelo motor. Esta ligada a um Host pois este
pode possuir várias traps;
•
Group: Representa um grupo de hosts;
•
User: corresponde à um usuário do sistema;
61
•
StateAlert: classe que contém dados sobre em qual situação pode se emitir um alerta
devido uma trap;
•
MonitoringType: é um enumerator que identifica qual é o tipo de monitoramento de um
host; e
•
Engine: classe responsável por todas as operações do motor.
3.3.2 Interface
O diagrama de classes da interface é semelhante ao diagrama do motor, sendo que apenas a
classe Engine não está presente.
62
3.4 Diagrama Entidade-Relacional
O diagrama entidade-relacional, apesar de não ser padrão UML, ele é importante, pois
define a estrutura do banco de dados. O diagrama resultante para este projeto é exibido pela Figura
44.
Figura 44. Diagrama Entidade-Relacional.
63
4 DESENVOLVIMENTO
A programação do UNMS empregou as seguintes ferramentas:
•
Microsoft Visual Studio 2005
•
Banco de dados PostgreSQL 8.3
•
pgAdmin III
•
MonoDevelop 1.0
Ao utilizar o Visual Studio 2005 (VISUALSTUDIO, 2008) com a linguagem de
programação C#, foi utilizada uma biblioteca de conexão com o banco de dados que visa facilitar o
uso do nPgSQL (POSTGRESQL, 2008). A utilização de ODBC foi descartada pelo fato de oferecer
desempenho inferior se comparado com uma conexão direta com o banco de dados.
Foi utilizado o padrão DAO (Data Access Object) de desenvolvimento. Este padrão permite
que ocorra a separação da lógica de negócio da parte que faz o tratamento do acesso aos dados
persistidos (BUSHMANN; HENNEY; SCHMIDT, 2007, tradução nossa).
Com base neste padrão, uma maneira um pouco diferente de desenvolvimento foi adotada.
Para garantir uma boa modularidade, optou-se por desenvolver estes itens da seguinte forma:
1. Um Project que possui as classes entidade (beans) e persistência;
2. Um Project que possui as classes de visão.
A Figura 45 demonstra no Visual Studio como foi abordado o padrão de desenvolvimento DAO. O
Project Hosts apresenta, entre outros, a classe Bean (Host) e a classe DAO (HostDAO).
64
Figura 45. Formato de desenvolvimento.
Portanto, para cada entidade do sistema, haverá dois Projects em uma Solution do Visual Studio.
Isto garante que implementações e correções futuras sejam facilitadas. Além disso, este formato
permite que tanto o motor quanto a interface utilizem os mesmos Projects de beans e DAO. Além
disso, o HostDAO foi utilizado para acesso a bases SNMP no host.
Antes de aprofundar o desenvolvimento dos recursos mais importantes do motor e da
interface, é necessário entender o processo da criação da Classe de manipulação de dados do
protocolo SNMP.
4.1 Classe de manipulação de dados do protocolo SNMP
Para desenvolver um software que possa se comunicar através de SNMP com os dispositivos
de rede, foi necessário pesquisar bibliotecas que fornecessem os recursos necessários para isto, já
que o .NET Framework não possui tal recurso. Entretanto, com o objetivo de adquirir um
conhecimento mais aprofundado sobre o assunto, foi decidido que uma biblioteca própria fosse
construída, resultando em mais assuntos a serem revisados. O estudo bibliotecas já existentes
ajudaram a compreender melhor o protocolo. A lista de bibliotecas estudadas é exibida pela Tabela
10.
65
Tabela 10. Bibliotecas SNMP pesquisadas
Biblioteca
An SNMP Library for .NET
Framework (CROWE, 2005)
SNMP Library
(CODEPROJECT, 2008)
Descrição
Esta biblioteca é bastante completa, mas complexa. Possui
métodos de tradução de OIDs para descrição e vice-versa.
Possui métodos simples de utilização. Por outro lado,
necessita de instância de alguns objetos que a torna confusa.
Além disso, ela é carente em alguns recursos que são
necessários para este projeto.
Para construir uma biblioteca de acessos SNMP, inicialmente foram necessários estudos
sobre o funcionamento de mais baixo nível do protocolo. O entendimento da estrutura do datagrama
SNMP, exibida pela Figura 46, foi primordial para a construção da biblioteca.
Figura 46. Datagrama SNMP.
Fonte: Adaptado de Bruey (2008).
Conforme o estudo e o desenvolvimento ocorriam através de observações no diagrama, o
padrão TLV (Type, Length, Value – Tipo, Tamanho e Valor) e a codificação BER (Basic Encoding
Rules – Regras de Básicas de Codificação) foram descobertos:
4.1.1 Padrão TLV
Um datagrama SNMP tem sua estrutura básica construída utilizando o padrão TLV (Type,
Length, Value – Tipo, Tamanho e Valor) (JAMHOUR, 2008). O pacote é extremamente organizado
através deste padrão, de modo que cada parte e sub-parte são separadas, especificadas e
dimensionadas de acordo com o valor e tipo. A Figura 47 demonstra o campo community de um
datagrama SNMP. Na Figura 46 (Datagrama SNMP), ele seria inserido inteiramente no local
correspondente, seguindo este padrão.
Figura 47. Espaço community do
SNMP.
66
O campo “tipo” é um valor numérico que corresponde a um tipo de dado disponível no
ASN.1 (IBIDEM). A lista de tipos de dados e seu valor numérico são demonstrados na Tabela 11.
Tabela 11. Tipos de dado do protocolo SNMP utilizado no padrão TLV.
Identificador
Boolean
Integer
UInt32
BitString
OctetString
ObjectIdentifier
Null
Sequence
Counter32
Counter64
Gauge
TimeTicks
IPAddress
Opaque
NetAddress
Valor
0x01
0x02
0x47
0x03
0x04
0x06
0x05
0x30
0x41
0x46
0x42
0x43
0x40
0x44
0x45
Fonte: Adaptado de CodeProject (2008).
O campo “tamanho” é um valor numérico de significa a quantidade de bytes que o campo
“valor” possui.
4.1.2 Codificação/Decodificação BER
A codificação/decodificação BER (Basic Encoding Rules – Regras Básicas de Codificação)
é o sistema adotado para codificação dos dados para transferência do datagrama SNMP pela rede
(JAMHOUR, 2008).
O BER aplicado ao SNMP é utilizado em casos em que certamente algum valor ocupará
mais de um byte. Seu funcionamento consiste em marcar com 1 o bit mais à esquerda de um byte
para indicar que existe mais bytes a serem lidos para a decodificação da mensagem. Caso o bit mais
à esquerda do byte seja 0, quer dizer que este é o último byte a ser lido.
Para exemplificar, um OID deverá ser convertido em um vetor de bytes, para que ele seja
incorporado ao pacote SNMP. O OID utilizado é 1.3.6.1756.3.1. O valor 1756 é o ponto em que
será necessário aplicar a codificação.
67
Inicialmente, converte-se 1756 para binário: 11011011100 (para facilitar a leitura, em
hexadecimal, o seu valor é 0x6DC). A seguir, é necessário separar o valor de sete em sete bits,
conforme a Figura 48.
1101
1011100
Figura 48. Valor binário de sete em
sete bits.
A seguir, os valores separados devem ser completados para todos terem oito bits. Ao serem
completados, são marcados os bits mais a esquerda conforme a regra de codificação BER. O
resultado é exibido na Figura 49. Os valores grifados são os bits de indicação.
10001101
01011100
Figura 49. Resultado da codificação
BER.
4.1.3 A biblioteca de classes resultante
As pesquisas realizadas bem como a compreensão dos novos conceitos resultaram na
biblioteca de acesso a dados do protocolo SNMP, batizada de “libSNMP”. Esta possui enumerators,
classes com métodos de codificação/decodificação BER e classe com métodos para manipulação de
dados do SNMP.
A classe de codificação BER possui apenas dois métodos, exibidos pela Figura 50. Ambos
os métodos trabalham com um vetor de bytes (byte[]) e um valor inteiro de 32 bits sem sinal
(UInt32).
Public static byte[] Encode(UInt32 source);
Public static UInt32 Decode(byte[] source);
Figura 50. Métodos da classe de codificação/decodificação BER
A principal classe desta biblioteca é a “Snmp”. Esta possui métodos estáticos, responsáveis
por consultar os objetos gerenciáveis de dispositivos de rede e retornar os resultados. Além disto,
existem também outros métodos que auxiliam no desenvolvimento. A Figura 51 exibe a lista de
métodos públicos existentes.
68
Public static SnmpData Request(SnmpVersion ver, string community, SnmpOp op, string oid, string
host);
public static SnmpData RequestTextual(SnmpVersion ver, string community, SnmpOp op, string
textualDesc, string host);
public static SnmpDataList RequestWalk(SnmpVersion ver, string community, string startOid, string
host);
public static string TranslateToDescr(string oid);
public static string TranslateToOid(string textualDescr);
public static string GetDeviceDescription(DeviceType dt, int deviceIndex, string host, string
community);
Figura 51. Métodos da classe de Snmp.
O método Request é o método responsável por realizar uma operação sobre algum valor
correspondente ao OID informado. O tipo da operação é passada por parâmetro através de um
enumerator. A versão do protocolo também é selecionada por um enumerator.
O método RequestTextual é semelhante ao Request, mas a operação é realizada passando a
descrição textual do OID. Dentro do método ocorre uma operação de tradução da descrição em um
OID, já que em um pacote SNMP não suporta operações utilizando-se a descrição textual.
O RequestWalk utiliza-se de uma operação do SNMP, o get-next. Através disto, é possível
navegar na árvore de OIDs e resgatar vários dados através de um único método. A operação getnext não possui critério de parada, ou seja, é necessário um controle no próprio método de
requisição. Para isto, utilizou-se um laço infinito que realizaria um break caso o próximo OID não
comece com OID fornecido como parâmetro. Isto foi possível através do método
String.StartsWith().
Os métodos TranslateToDescr e TranslateToOid são os responsáveis pela conversão de um
OID para sua descrição e vice-versa. Esta operação é possível, pois existe uma tabela em memória
que possui os principais OIDs e suas respectivas descrições.
O método GetDeviceDescription é utilizado principalmente para consultar qual o nome de
um dispositivo de rede ou disco, baseado em uma análise simples do OID passado por parâmetro.
O conceito de TLV não exige uma classe ou métodos para seu tratamento. Isto ocorre pelo
fato de que este conceito seja utilizado diretamente na construção e decodificação do pacote SNMP.
Portanto, o TLV está embutido em todos os métodos do tipo Request presentes na libSNMP.
69
Cada método do Request retorna um tipo SnmpData ou um SnmpDataList. O SnmpDataList
é uma lista de SnmpData que contém métodos de exibição de dados para o console, métodos de
adição diferenciados e de consulta. A definição da classe SnmpData é exibida pela Figura 52 .
public SnmpDataType Type;
public object Value;
public string Oid;
public string Description;
public string DescriptionWithIndex;
public override string ToString();
Figura 52. Métodos e atributos da classe SnmpData.
Um SnmpDataType é selecionado em um enumerator conforme o pacote de resposta de
algum Request. O atributo Value possui o valor recebido pela resposta e é do tipo object, pois este
tipo pode guardar qualquer tipo de informação, podendo ser um tipo básico como int ou uma String
por exemplo. Description e DecriptionWithIndex retornam uma descrição do dado, de acordo com a
tabela em memória previamente citada. O método ToString() foi construído para que o objeto
SnmpData possa ser exibido de maneira mais clara.
Nesta mesma biblioteca, existe uma classe privada chamada mib2. Esta contém um objeto
DataTable no qual é possível carregar dados em memória e realizar SELECT, como se fosse num
banco de dados que suporte SQL. Neste objeto, existem vários registros que representam os OIDs e
suas descrições textuais. O objetivo desta classe, portanto, é de possibilitar traduções de OIDs para
sua descrição e vice-versa.
4.2 O motor do UNMS
O motor do UNMS é o responsável pela realização de todas as verificações de hosts e
serviços cadastrados. Sua estrutura é composta por dois mecanismos:
•
Mecanismo de escalonamento; e
•
Mecanismo de verificação de hosts e serviços.
O mecanismo de escalonamento se assemelha ao escalonador de processos de um Sistema
Operacional. No caso do UNMS, o objetivo é verificar quais hosts serão checados na próxima
iteração de verificações do motor. A cada chamada desse mecanismo, o tempo que falta para a
70
próxima checagem é recalculado levando-se em conta o tempo atual e o tempo da última
verificação. Os hosts selecionados são adicionados na lista de hosts a serem checados.
O mecanismo de verificação de hosts e serviços é acionado pelo método Start(). Sua
primeira ação é escalonar os hosts, verificando quais devem ser checados. No motor, segue-se a
seguinte ordem de verificação:
1. Teste de host através do ICMP Echo/Reply (Ping);
2. Checagem de serviços; e
3. Verificação dos OIDs através de SNMP.
A cada verificação realizada, os dados de cada item verificado são atualizados para visualização
através da interface.
O motor foi todo construído e testado no Visual Studio da Microsoft. Entretanto, devido este
ser construído como aplicação console, sua compatibilidade com o Mono não foi comprometida.
4.2.1 Checando através de ICMP
O protocolo ICMP é outro caso em que o .NET Framework não fornece os métodos
necessários. Para realizar operações com ICMP, foi utilizada a biblioteca Advanced Ping Program
(JAVA2S, 2008).
Esta biblioteca foi de grande utilidade, mas por outro lado foram necessárias
implementações e adaptações. O objetivo foi de padronizar e facilitar o uso da biblioteca. Para as
alterações, o sniffer WireShark (WIRESHARK, 2008) foi bastante utilizado. O resultado final foi
uma classe que possui cinco métodos públicos, exibidos pela Figura 53.
public static List<IPAddress> BroacastICMP(string broadCastIp);
public static int Ping(string ipAddress);
public static int PingHostName(string hostname);
public static List<IPAddress> TraceRoute(string targeIpAddress, int hops);
public static List<IPAddress> TraceRouteHostName(string targeHostName, int hops);
Figura 53. Métodos da classe ICMP.
O método BroadcastICMP retorna a lista de IPs que responderam ao ICMP Echo disparado para um
endereço de broadcast. Ping retorna um inteiro com o tempo de resposta de um host em
71
milissegundos. O PingHostName funciona como o método Ping, mas passando um nome de host.
Os métodos TraceRoute e TraceRouteHostName retornam uma lista de IPs que fazem parte da rota
até o host informado, sendo que o número máximo de passos é informado como parâmetro.
A verificação por ICMP ocorre em todos os hosts escalonados para uma determinada
iteração, independente do seu tipo de monitoramento. Neste caso, os hosts são atualizados quanto
ao resultado obtido pelo ICMP Echo/Reply e em casos de problema, um registro é criado no log.
4.2.2 Checando serviços
Este recurso do motor é o responsável pela verificação de serviços de um determinado host
de uma porta TCP. Para sua checagem, foi elaborado um método que recebe o nome do host e a
porta, retornando um valor em milissegundos correspondente ao tempo de resposta do serviço.
Inicialmente, é armazenado o horário de início da verificação. Então, um Socket TCP é
instanciado com o objetivo de se conectar a porta do host informado. Após a conexão, já ocorre a
desconexão e o cálculo do tempo que a operação levou é retornado. Caso ocorra um erro de
conexão é retornado o valor 9999. O tempo limite para verificação de cada porta é de 1 segundo (ou
1000 milissegundos).
O sistema de registro de eventos para os serviços é igual ao processo de verificação por
ICMP. O tempo de resposta da última medição é armazenado e em casos de erro um registro no log
é adicionado.
4.2.3 Checando os OIDs
Cada OID cadastrado para um host é verificado a cada iteração para qual o host foi
escalonado. Para a checagem, foi utilizado o método Snmp.Request, disponível na biblioteca
construída durante o TCC-2.
Diferente dos outros dois métodos de verificação, o sistema de verificação SNMP armazena
os dados adicionando-os na tabela e não alterando os já existentes. Isto é necessário para a criação
dos gráficos. Por outro lado, segue a mesma regra em que caso algum erro seja encontrado, um
registro é criado na tabela de log.
72
4.3 Desenvolvimento da Interface
A interface do UNMS é a responsável pela exibição dos dados registrados pelo motor de
uma maneira amigável ao usuário. Em sua construção, foi proposto um sistema multi-plataforma e o
Gtk# seria o sistema de interface gráfica a ser utilizado.
Com o MonoDevelop (MONODEVELOP, 2008), é possível construir aplicações multiplataforma para a plataforma .NET com interface gráfica Gtk# e outras. Esta ferramenta é
relativamente nova, e a ausência de recursos como break-points, watches entre outros, se tornou um
fator decisivo. O resultado foi o abandono desta ferramenta durante o desenvolvimento da interface
e o Visual Studio da Microsoft foi utilizado.
Espera-se, que com o avanço do projeto Mono, ferramentas gratuitas como o MonoDevelop
se tornem mais completas. Como o UNMS foi construído de forma modular, seria possível reutilizar as DLLs construídas no desenvolvimento de uma interface multi-plataforma.
Todas as telas de cadastro do sistema foram construídas utilizando a herança de formulários.
Este recurso está disponível no Windows Forms e busca o reaproveitamento do código. Isto ocorre
ao construir uma interface básica e seus métodos e então criar um novo Form o qual irá herdar desta
interface. O resultado no sistema são interfaces padronizadas e com uma lista pronta de todos os
métodos a serem implementados. Os componentes do Form “pai” são exibidos na interface de
desenvolvimento em um modo de somente leitura.
73
4.3.1 Construção de gráficos na plataforma .NET
Para a construção de gráficos em .NET, foi necessário a utilização de uma biblioteca não
pertencente
ao
.NET
Framework.
Para
este
TCC,
foi
utilizado
o
.Net
Charting
(DOTNETCHARTING, 2008), um componente pago. Apesar disso, ele pode ser utilizado
gratuitamente. Sem o licenciamento, ele exibe um logotipo no gráfico, conforme a Figura 54.
Figura 54. Exemplo de uso para o .Net Charting e seu logotipo.
.Net Charting é integrado com o Microsoft Visual Studio através de sua adição na lista de
componentes, conforme a Figura 55.
Figura 55. .Net Charting no Visual Studio.
O componente é utilizado ao arrastá-lo ao formulário Windows. Seu posicionamento e
dimensões são ajustados, e então se codifica o gráfico. É possível também, utilizá-lo na construção
74
de páginas em ASP.NET. No Windows, as escalas são ajustadas conforme as dimensões do
formulário sem necessidade da criação de código adicional.
A seguir, na Figura 56, é exibido um exemplo de gráfico de barras construído com o .Net
Charting.
Figura 56. .Net Charting e gráfico de barras.
No UNMS, os gráficos são de linha. A Figura 57 apresenta um trecho de codificação
comentado, exemplificando o uso do .Net Charting.
chart1.Series = new Series(); //Inicia nova série
chart1.Type = ChartType.Scatter; //O gráfico é de linha
chart1.SeriesCollection.Clear(); //A coleção de Series é apagada
chart1.Title = String.Empty; //O título do gráfico é branco
chart1.TitleBox = new Box(); //Re-inicia a caixa do título do gráfico
chart1.XAxis.Scale = dotnetCHARTING.WinForms.Scale.Time; //A escala do eixo X é por tempo
chart1.XAxis.TimeInterval = TimeInterval.Minute; //A escala é em minutos
chart1.XAxis.FormatString = "HH:mm"; //O formato de exibição de dados do eixo X é Horas:Minutos
chart1.XAxis.Name = "Tempo"; //O título para o eixo X é tempo
chart1.YAxis.Name = "% Carga"; //O título do eixo Y é % Carga
//Inserindo valores no gráfico
Element el; //Declaro um elemento no gráfico
//Laço de repetição que possui um objetos que contêm uma data e um Double
foreach (KeyValuePair<DateTime, Double> kvp in ls)
{
el = new Element(); //Instância de um novo elemento
el.YValue = kvp.Value;
el.XDateTime = kvp.Key;
chart1.Series.AddElements(el); //Insere o novo elemento no gráfico
}
chart1.SeriesCollection.Add(); //Insere a coleção de dados no gráfico
chart1.SeriesCollection[0].DefaultElement.Color = Color.Green; //A linha do gráfico é verde
//Não é desejado que cada valor possua um marcador individual
chart1.SeriesCollection[0].DefaultElement.Marker.Visible = false;
Figura 57. Exemplo de uso do .Net Charting.
75
4.3.2 Exibindo hosts no Google Earth
A tarefa de se criar um mecanismo que exibe os hosts no Google Earth foi bastante
desafiadora. Após várias pesquisas, foi encontrado um método, o qual consiste na criação de
arquivos KML (Keyhole Markup Language – Linguagem de Marcação Keyhole).
O arquivo KML é um XML que possui as informações necessárias para se desenhar marcos
em um software como o Google Earth. Sua estrutura é facilmente descoberta ao criar um marco no
próprio Google Earth e depois utilizar a opção “Salvar meus lugares”.
Com o KML gerado pelo Google Earth em mãos, o passo seguinte foi codificar uma classe
que possui métodos que criam um KML a partir de dados geográficos. A biblioteca resultante
possui duas classes: Location (Localização) e KmlGen (Gerador do KML).
A classe Location possui apenas três atributos que identificam um local: nome, latitude e
longitude.
A classe KmlGen possui uma lista de Location. Com a lista contendo as localizações, podese acionar o método CreateKml, fornecendo o caminho onde será criado o Kml.
Para efeitos de teste, um arquivo KML foi gerado a partir do software Google Earth. Sua
extensão foi alterada para XML e o arquivo foi aberto para exibição no Internet Explorer. Por parte
do KmlGen, foi adotado o mesmo procedimento. Então, com os dois XML sendo exibidos lado a
lado foi possível constatar as diferenças e então corrigi-las. O arquivo que demonstra o KML
gerado pela ferramenta é exibido Figura 58. Vale ressaltar o grau de precisão da latitude e
longitude.
76
<?xml version="1.0" encoding="UTF-8" ?>
- <kml xmlns="http://earth.google.com/kml/2.2">
- <Document>
<name>Casa.kml</name>
- <Style id="sn_ylw-pushpin">
- <IconStyle>
<scale>1.1</scale>
- <Icon>
<href>http://maps.google.com/mapfiles/kml/pushpin/ylw-pushpin.png</href>
</Icon>
<hotSpot x="20" y="2" xunits="pixels" yunits="pixels" />
</IconStyle>
</Style>
- <Style id="sh_ylw-pushpin">
- <IconStyle>
<scale>1.3</scale>
- <Icon>
<href>http://maps.google.com/mapfiles/kml/pushpin/ylw-pushpin.png</href>
</Icon>
<hotSpot x="20" y="2" xunits="pixels" yunits="pixels" />
</IconStyle>
</Style>
- <StyleMap id="msn_ylw-pushpin">
- <Pair>
<key>normal</key>
<styleUrl>#sn_ylw-pushpin</styleUrl>
</Pair>
- <Pair>
<key>highlight</key>
<styleUrl>#sh_ylw-pushpin</styleUrl>
</Pair>
</StyleMap>
- <Placemark>
<name>Casa</name>
- <LookAt>
<longitude>-48.91114504933488</longitude>
<latitude>-27.09442286390817</latitude>
<altitude>0</altitude>
<range>158.9999911670838</range>
<tilt>0</tilt>
<heading>0.1669381198608628</heading>
<altitudeMode>relativeToGround</altitudeMode>
</LookAt>
<styleUrl>#msn_ylw-pushpin</styleUrl>
- <Point>
<coordinates>-48.91131727570033,-27.09449447216344,0</coordinates>
</Point>
</Placemark>
</Document>
</kml>
Figura 58. Exemplo de KML.
O Google Earth exibe os hosts através dos marcadores amarelos, que é o modo descrito pelo
KML gerado. A maneira de como o software exibe os hosts é exibida pela Figura 59.
77
Figura 59. Google Earth exibindo os hosts.
Com a biblioteca concluída, foi adicionado ao menu a opção de exibição dos hosts no
Google Earth. Esta opção gera o Kml e inicia o Google Earth o passando como parâmetro.
4.3.3 Desenvolvimento da auto-descoberta de dispositivos
A auto-descoberta tem como objetivo de detectar todos os hosts presentes na mesma subrede de onde a interface está sendo executada. Através do protocolo ICMP, o qual utiliza a mesma
biblioteca descrita em “Checando através de ICMP”, o mecanismo de detecção pode funcionar de
duas maneiras conforme o desejo do usuário:
•
Descoberta por broadcast; e
•
Teste de IP por IP.
O sistema de descoberta por broadcast consiste em disparar o ICMP Echo (Ping) para o
endereço de broadcast da sub-rede. Desta forma, todos os hosts presentes irão responder com um
Reply e seus IPs serão armazenados em uma lista.
O modo de teste de IP por IP funciona através de um laço de repetição que dispara o ICMP
Echo individualmente para cada IP que está na sub-rede. Todos os hosts que responderem a
requisição serão armazenados em uma lista.
Com a lista de hosts presentes na lista, é possível selecionar quais os hosts que se deseja
adicionar ao UNMS. Hosts já cadastrados não são exibidos nesta tela evitando duplicidade.
78
4.4 Testes do UNMS
Foram realizados experimentos durante todo o processo de desenvolvimento do UNMS. Os
testes foram realizados no Laboratório de Redes da UNIVALI. Estes testes foram feitos à medida
que o aplicativo foi se tornando cada vez mais complexo. Além disso, testes de funcionamento
gerais foram executados.
4.4.1 Processo de testes da biblioteca de acesso SNMP
Devido à alta complexidade no processo de codificação de biblioteca de classes SNMP, uma
plataforma de testes foi montada de forma a facilitar a construção desta biblioteca. Os testes foram
realizados no Laboratório de Redes da UNIVALI, utilizando a infra-estrutura presente além dos
softwares VMWare (VMWARE, 2008) e Wireshark.
No VMWare, foi instalado uma máquina virtual com o Sistema Operacional Linux e
distribuição Ubuntu 7.04 (UBUNTU, 2008). Com o sistema operacional Windows rodando de
forma nativa no computador, comparava-se o funcionamento dos utilitários presentes no Linux
como snmpwalk e snmpget com os métodos presentes na biblioteca, até então em desenvolvimento.
Com a utilização do Wireshark, foi possível perceber os erros cometidos no processo. A Figura 60,
exibe o caso em que o sniffer detectou erros na construção do datagrama SNMP pela biblioteca e
exibe também um datagrama construído corretamente, construído pelo utilitário snmpget.
Figura 60. Wireshark detectando os datagramas SNMP.
É possível observar na Figura 60 os pacotes 3 e 4, sendo respectivamente, a requisição e uma
resposta, ambos corretos. No pacote 17, observa-se uma requisição inválida, esta realizada pela
biblioteca.
Para que esta biblioteca funcione corretamente, algumas classe auxiliares também foram
testadas. A classe de codificação/decodificação BER sofreu uma série de testes. Vários valores
maiores que 255 foram processados por esta classe de modo a detectar possíveis erros.
79
No próprio Wireshark, foi possível observar problemas através da análise do hexadecimal
correspondente ao pacote capturado. Tal comparação foi feita colando-se o hexadecimal dos
datagramas correto e incorreto no bloco de notas, conforme a Figura 61.
Figura 61. Comparando o datagrama correto
(linha superior) e o incorreto (linha inferior).
Vale destacar que o hexadecimal desnecessário já é descartado, selecionando a parte que trata de
SNMP no próprio Wireshark. Dados aleatórios como o identificador da requisição SNMP, que é
identificável analisando o datagrama também foram desconsiderados. Na Figura 61, a linha superior
representa parte do datagrama correto e a inferior o incorreto. Ao observar as diferenças existentes,
as devidas correções foram realizadas.
4.4.2 Testes da ferramenta
Com as bibliotecas necessárias já concluídas, e o desenvolvimento do aplicativo em
andamento, os testes foram iniciados. Entretanto, destacam-se os dois principais testes realizados no
Laboratório de Redes da UNIVALI.
O primeiro teste foi realizado quando a interface era uma mera ferramenta de validação dos
dados coletados pelo motor. Neste caso, foi possível observar alguns pequenos erros de coleta e que
o motor não atualizava a lista de hosts de forma adequada. Neste cenário, foram elaboradas
modificações no escalonador de hosts de modo que este coletasse os novos hosts automaticamente a
cada iteração. Deste modo, tanto a interface quanto o motor estariam trabalhando com dados
atualizados. Neste mesmo teste, foi verificado como seria o funcionamento do motor no Linux,
executando através da plataforma Mono. Como esperado, não houve problemas.
Neste mesmo teste, buscou-se avaliar o mecanismo responsável por exibir os OIDs que
podem ser utilizados para construir gráficos. Possíveis erros podiam ocorrer na coleta em hosts que
executavam sistemas operacionais diferentes do Windows, devido a possíveis vícios no
desenvolvimento para este sistema operacional. Entretanto, tais erros não apareceram o que
comprovou mais uma vez o bom funcionamento da biblioteca construída bem como a grande
utilidade do protocolo SNMP e a MIB-II.
80
O segundo teste foi realizado para verificar possíveis erros. Este teste foi realizado também
no Laboratório de Redes da UNIVALI no qual a ferramenta rodou durante uma hora e meia. Neste
cenário, nenhum host ou serviço foi alterado ou adicionado, sendo o principal foco o motor do
aplicativo. Com monitoramentos realizados periodicamente no gerenciador de tarefas do Windows,
foram observadas as porcentagens de consumo de processador, memória e do adaptador de rede. A
Tabela 12 exibe de forma resumida os resultados deste segundo teste.
Tabela 12. Dados sobre o segundo teste
Dado
Porcentagem de uso do processador pelo
processo motor
Memória utilizada pelo processo
Porcentagem de uso da rede
Hosts monitorados por ICMP
Hosts monitorados por SNMP
Serviços monitorados
Período de polling
Valor
4% (valor máximo)
Mínimo: 11 Mb
Máximo: 40 Mb
Mínimo: 0,02%
Máximo: 03%
17
03
10
30 segundos para todos os hosts
Neste mesmo teste, foram executados os testes de detecção de hosts. Na infra-estrutura de
redes em que se encontra o Laboratório de Redes da UNIVALI, a máscara de rede utilizada é a
255.255.254.0, o que permite a presença de 510 IPs para hosts, 1 IP identificador da rede e 1 IP de
broadcast. Com o teste desta funcionalidade sendo realizado após as 20h, foram detectados 458
hosts através da detecção IP por IP. O processo de detecção por broadcast, de forma estranha,
acabou não detectando host algum. Entretanto, verificou-se no Wireshark que IPs de classe A
(10.0.0.0) estavam respondendo ao pedido sendo que IPs de classe C (200.169.60.0) eram
esperados. Estes IPs foram descartados.
Além disso, buscou-se detectar possíveis erros durante a coleta de dados SNMP para
construção de gráficos. Esperava-se que possíveis erros pudessem surgir quando a coleta ocorresse
em hosts que executassem em Linux, semelhante ao caso já descrito. Felizmente, estes erros não
apareceram e o gráfico de carga de processador de um host com Linux foi construído com sucesso,
conforme demonstrado na Figura 62.
81
Figura 62. O gráfico construído corretamente
para medir a carga de processamento de um
host.
Para validar o mecanismo de criação de gráficos, o motor foi iniciado com o host Linux sem
processamento algum. Após um pequeno período, foi iniciado o aplicativo “top” o qual comprovou
que o computador estava com baixa porcentagem de processamento. Para simular um
processamento maior, o aplicativo top foi reiniciado, mas com uma taxa de atualização de dados em
0,01 (a linha de comando utilizada foi: top –d 0.01), o que fez com que o uso do processador pelo
próprio aplicativo aumentasse para cerca de 10%.
82
5 CONCLUSÕES
Este trabalho de conclusão de curso demonstrou o processo de construção de um software de
monitoramento de redes, o UNMS. A utilização em conjunto de vários conceitos, arquiteturas e
componentes resultou em um aplicativo potencialmente útil para os gerentes de redes de
computadores.
A engenharia de software para o UNMS permitiu estudar as diversas facetas necessárias
para a concepção do produto final. A discussão do formato final das interfaces, dos elementos que
são realmente necessários e úteis foi bastante discutida durante a banca de TCC-I. Vários
comentários de visitantes e dos avaliadores agregaram recursos adicionais valiosos, como o sistema
de auto-detecção de hosts na rede. Vários itens foram discutidos novamente com o orientador e
puderam ser melhorados.
Durante o processo de criação do software, foram encontradas várias dificuldades em se
desenvolver um software na plataforma Mono. A principal dificuldade foi em utilizar o
MonoDevelop, a principal IDE do Mono. Vários recursos valiosos ao desenvolvedor estão ausentes
nesta ferramenta o que inviabilizou o desenvolvimento nesta plataforma.
Ao descartar a utilização do Mono, utilizou-se o Visual Studio 2005 da Microsoft. Neste
cenário, optou-se por manter o motor do UNMS multi-plataforma, obedecendo às regras de
desenvolvimento necessárias para atingir este objetivo. Por outro lado, interface gráfica do UNMS
não atendeu a esta questão, pois alguns componentes visuais importantes, presentes no Windows
Forms, não existem para o Gtk#.
Ainda sobre a interface gráfica do UNMS, vale destacar o uso de KML para exibição de
pontos geográficos no Google Earth. Tal recurso demonstra grande flexibilidade podendo ser
utilizado para várias finalidades.
Para realizar o desenvolvimento do motor, foi necessário o estudo mais aprofundado sobre o
protocolo SNMP. O conhecimento em Sockets adquirido com o decorrer do curso finalmente foi
colocado em prática pelo autor deste TCC. A construção de uma biblioteca própria para tratamento
da comunicação SNMP demonstrou ser a parte mais prazerosa e desafiante de todo o processo de
construção do UNMS. Além disso, ressalta-se a importância de um software sniffer como o
83
Wireshark, essencial na criação de um software que utiliza Sockets. Nesta etapa vale destacar que
existe uma grande escassez de material sobre SNMP destinado aos desenvolvedores de software.
O recurso de recebimento de traps, que seria desenvolvido segundo o projeto inicial, acabou
não sendo realizado. Entretanto acredita-se que tal operação seja pouco necessária, pois o UNMS
realiza um monitoramento ativo através do polling que oferece recursos aparentemente similares em
seu modo final de operação.
A gerência de redes é uma área com ampla quantidade de elementos que podem ser
monitorados, implementados e sugeridos. Durante conversas com o orientador e visitantes do TCCI, pode-se correlacionar vários aspectos que poderiam ser abordados em trabalhos futuros: 1)
compatibilidade com MIBs específicas; 2) coleta de dados do syslog; 3) implementação em outros
idiomas; 4) interface mais detalhada; 5) estudos sobre escalabilidade; 6) sistema detalhado para
inventário da informática e 6) incrementos no sistema de localização geográfica.
84
REFERÊNCIAS BIBLIOGRÁFICAS
ALHIR, Siman Si. UML in a nutshell. Sebastopol: O’Reilly, 1998.
BOOCH, G., RUMBAUGH, J., JACOBSON, I. The unified modeling language user guide. 2.ed.
Boston: Addison-Wesley, 2005.
BORNSTEIN, Niel. M.; DUMBILL Edd. Mono: a developer’s notebook. EUA: O’Reilly, 2004.
BRUEY, Douglas. SNMP: Simple? Network Management Protocol. Disponível em:
<http://www.rane.com/note161.html>. Acesso em: 25 ago 2008.
BURGESS, Chris. The nagios book. Disponível em: <http://www.nagiosbook.org>. Acesso em: 13
maio 2008.
BUSHMANN, F.; HENNEY, K.; SCHMIDT, D.C. Pattern-oriented software architecture: on
patterns and patterns languages. Indianapolis: Willey Publishing, 2007. 5v.
CACTI. CACTI: the complete RRDTool-based Graphing Solution. Disponível em:
<http://www.cacti.net>. Acesso em: 14 maio 2008.
DOTNETCHARTING. ASP.NET chart and charting for .NET. Disponível em:
<http://www.dotnetcharting.com>. Acesso em: 20 out 2008.
GNU. The GNU General Public License. Disponível em:
<http://www.gnu.org/licenses/gpl.html/>. Acesso em: 29 maio 2008.
KUROSE, James F.; ROSS, Keith W. Redes de computadores e a internet. 3. ed. São Paulo:
Pearson Addison Wesley, 2006.
JAVA2S. Advanced ping program. Disponível em:
<http://www.java2s.com/Code/CSharp/Network/AdvancedPingProgram.htm>. Acesso em: 15 out
2008.
JAMHOUR, Edgard. Gerência de Redes (SNMP). Disponível em:
<http://www.ppgia.pucpr.br/~jamhour/Pessoal/Mestrado/TARC/LDAP.ppt>. Acesso em: 10 set
2008.
MAURO, Douglas; SCHMIDT, Kevin. Essential SNMP. EUA: O'Reilly, 2001.
MILLER, Mark A. Managing internetworks with SNMP. 2. ed. EUA: M & T Books, 1997.
MONO. Main page - mono. Disponível em: <http://www.mono-project.com>. Acesso em: 23 maio
2008.
MONODEVELOP. Main Page – MonoDevelop. Disponível em: <http://www.monodevelop.com>.
Acesso em: 12 set 2008.
NAGIOS. Nagios: home. Disponível em: <http://www.nagios.org>. Acesso em: 13 maio 2008.
NETWORKDICTIONARY. FCAPS: network management functional model. 2008a. Disponível
em: <http://www.networkdictionary.com/networking/FCAPS.php>. Acesso em: 01 abr. 2008.
NETWORKDICTIONARY. ISO CMIP: common management information protocol. 2008b.
Disponível em: <http://www.networkdictionary.com/protocols/cmip.php>. Acesso em: 01 abr.
2008.
OETIKER, Tobias. RRDTool: about RRDtool. Disponível em: <http://oss.oetiker.ch/rrdtool/>.
Acesso em: 14 maio 2008.
RFC 1157. Simple Network Management Protocol (SNMP). 1990. Disponível em:
<http://www.ietf.org/rfc/rfc1157.txt>. Acesso em: 01 abr 2008.
RFC 1157. Simple Network Management Protocol (SNMP). 1990. Disponível em:
<http://www.ietf.org/rfc/rfc1157.txt>. Acesso em: 01 abr 2008.
RFC 1212. Management Information Base for Network Management of TCP/IP-based
internets:MIB-II. 1991. Disponível em: <http://www.ietf.org/rfc/rfc1213.txt>. Acesso em: 01 abr
2008.
RFC 1213. Management Information Base for Network Management of TCP/IP-based
internets:MIB-II. 1991. Disponível em: <http://www.ietf.org/rfc/rfc1213.txt>. Acesso em: 01 abr
2008.
RFC 1905. Protocol operations for version 2 of the Simple Network Management Protocol
(SNMPv2). 1996. Disponível em: <http://www.ietf.org/rfc/rfc1905.txt>. Acesso em: 01 abr 2008.
RFC 1906. Transport mappings for version 2 of the Simple Network Management Protocol
(SNMPv2). 1996. Disponível em: <http://www.ietf.org/rfc/rfc1906.txt>. Acesso em: 01 abr 2008.
RFC 1907. Management Information Base for Version 2 of the Simple Network Management
Protocol (SNMPv2). 1996. Disponível em: <http://www.ietf.org/rfc/rfc1907.txt>. Acesso em: 01
abr 2008.
RFC 2571. An architecture for describing SNMP management frameworks. 1999. Disponível
em: <http://www.ietf.org/rfc/rfc2571.txt>. Acesso em: 01 abr 2008.
RFC 2572. Message processing and dispatching for the Simple Network Management Protocol
(SNMP). 1999. Disponível em: <http://www.ietf.org/rfc/rfc2572.txt>. Acesso em: 01 abr 2008.
RFC 2573. SNMP Applications. 1999. Disponível em: <http://www.ietf.org/rfc/rfc2573.txt>.
Acesso em: 01 abr 2008.
RFC 2574. User-based Security Model (USM) for version 3 of the Simple Network
Management Protocol (SNMPv3). 1999. Disponível em: <http://www.ietf.org/rfc/rfc2574.txt>.
Acesso em: 01 abr 2008.
RFC 2575. View-based Access Control Model (VACM) for the Simple Network Management
Protocol (SNMP). 1999. Disponível em: <http://www.ietf.org/rfc/rfc2575.txt>. Acesso em: 01 abr
2008.
86
RFC 2579. Textual conventions for SMIv2. 1999. Disponível em:
<http://www.ietf.org/rfc/rfc2579.txt>. Acesso em: 01 abr 2008.
SCHÖNIG, Hans-Jücrgen; GESCHWINDE, Ewald. Mono kick start. EUA: Sams Publishing,
2003.
TANENBAUM, Andrew S. Redes de computadores. 4. ed. Rio de Janeiro: Campus, 2001.
TAROUCO et al. Gerenciamento de redes: uma abordagem de Sistemas Abertos. Itaim-Bibi:
Makron Books, 1993.
TEMPLEMAN, Julian; VITTER, David. Visual Studio .NET – the .NET Framework black
book. EUA: The Coriolis Group, 2002.
TURTSCHI, Adrian; WERRY, Jason; HACK Greg. C# .NET guia do desenvolvedor. 2 ed. Rio de
Janeiro: Alta Books, 2004.
UBUNTU. Ubuntu Home Page | Ubuntu. Disponível em: <http://www.ubuntu.com>. Acesso em:
01 ago 2008.
VISUAL STUDIO. Sistema de desenvolvimento Visual Studio. Disponível em:
<http://msdn.microsoft.com/pt-br/vstudio/products/default.aspx>. Acesso em: 01 nov 2008.
VMWARE. VMware: Virtualization via Hypervisor, Virtual Machine and Server Consolidation –
Vmware. Disponível em: <http://www.vmware.com>. Acesso em 01 ago 2008.
WIRESHARK. Wireshark: Go-deep. Disponível em: <http://www.wireshark.org>. Acesso em: 10
ago 2008.
87