Embed Size (px)
Citation preview
CENTRO UNIVERSITÁRIO UNIVATES
CURSO DE SISTEMAS DE INFORMAÇÃO
PROJETO DE GERENCIAMENTO DE UNIDADES
GEOGRAFICAMENTE DISTRIBUÍDAS
A PARTIR DE UM NÓ CENTRAL
Flávio André Johann
Lajeado, dezembro de 2013
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Flávio André Johann
PROJETO DE GERENCIAMENTO DE UNIDADES
GEOGRAFICAMENTE DISTRIBUÍDAS
A PARTIR DE UM NÓ CENTRAL
Monografia apresentada na disciplina de
Trabalho de Conclusão de Curso – Etapa II,
do curso de Sistemas de Informação, do
Centro Universitário UNIVATES, como parte
da exigência para a obtenção do título de
Bacharel em Sistemas de Informação.
Orientador: Prof. Ms. Luis Antônio
Schneiders
Lajeado, dezembro de 2013
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Flávio André Johann
PROJETO DE GERENCIAMENTO DE UNIDADES
GEOGRAFICAMENTE DISTRIBUÍDAS
A PARTIR DE UM NÓ CENTRAL
A banca examinadora abaixo aprova a Monografia apresentada na disciplina de Trabalho
de Conclusão de Curso – Etapa II, na linha de formação específica em Sistemas de
Informação, do Centro Universitário Univates, como parte da exigência para a obtenção
do grau de Bacharel em Sistemas de Informação:
Prof. Ms. Luis Antônio Schneiders - orientador
Centro Universitário UNIVATES.
Prof. Esp. Edson Moacir Ahlert, UNIVATES
Centro Universitário UNIVATES
Prof. Ms. Marcus Vinícius Lazzari
Centro Universitário UNIVATES
Lajeado, 06 de dezembro de 2013
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
DEDICATÓRIA
Dedico...
A Flávio Ardi Johann e Ritta Bottega Johann, meus pais e mestres desde o
ínicio da minha existência, por tudo que me ensinaram e pelo apoio que sempre me
deram para que fosse possível trilhar os caminhos de minha formação pessoal e
profissional. Dedico também a minha namorada, Júlia Tresoldi, e a toda a sua
família, pelo carinho, atenção, compreensão e ajuda nos momentos de dificuldade.
Dedico esta obra também aos entusiastas e aficcionados pelo Zabbix, a Vinício
Zanchettin, que despertou o meu interesse por este software, a Luciano Alves e
toda a equipe da Unirede de Porto Alegre pelo tratamento diferenciado e
excepcional treinamento prestado. A Eduardo Johann e toda a equipe da
Costaneira, pelos ensinamentos diários e credibilidade disposta neste projeto.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
AGRADECIMENTOS
Agradeço ao meu orientador, prof. Ms. Luís Antônio Schneiders pelo tempo
dedicado para auxiliar-me na redação e organização desta monografia. Aos demais
integrantes do corpo docente do CCTEC pelo excelente trabalho desempenhado ao
longo dos anos, contribuindo não só para a formação acadêmica como também
humanitária de seus discentes. A Ana Paula Ferreira Antunes pelo auxílio na edição
final das imagens e a todos os meus amigos, companheiros e colegas por
compartilharem comigo momentos inesquecíveis desta vida.
Gratidão eterna!
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
RESUMO
Com a expansão da Internet e da tecnologia, tornou-se imprescindível o uso de mecanismos para o controle e gerenciamento das infraestruturas de redes de computadores e dos sistemas que armazenam informações. Assim, essa monografia visa apresentar um projeto que permita controlar e monitorar ativos em unidades geograficamente distribuídas a partir de um nó central. Desse modo, estima-se que um administrador de redes possa identificar e prevenir possíveis pontos críticos de falhas na rede de forma proativa, tendo um maior controle sobre os ativos monitorados, podendo dimensionar melhor as tecnologias utilizadas e planejar futuras expansões, caso seja necessário. Para tanto, foi proposto o estudo da infraestrutura de redes na empresa Costaneira S/A, com sede na cidade de Lajeado-RS, e filiais distribuídas em todo o Estado. A metodologia desse estudo envolveu conceituar os princípios e protocolos utilizados para o gerenciamento de redes, descrever o cenário da empresa sugerida, analisar e comparar algumas das soluções de software livre mais utilizadas nessa área de pesquisa, implantar a solução que melhor se adaptou ao ambiente da empresa, avaliar e discutir os resultados obtidos, propondo melhorias. Palavras-chave: Gerenciamento de redes. Protocolos de gerenciamento de redes.
Software de gerenciamento de redes. Zabbix.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
ABSTRACT
With the expansion of Internet and technology, it became essential to use mechanisms for the control and management of the infrastructure of computer networks and systems that store information. Therefore, this monograph aims to present a project that allows control and monitor assets in geographically units distributed from a central node. Because of that, it is estimated that a network administrator can identify and prevent potential critical points of network failures proactively taking greater control over the assets monitored and can dimension better the technologies used and to plan future expansion if needed. Therefore, it was proposed to study the network infrastructure in Costaneira S/A company, with headquarters in Lajeado – RS and branches distributed throughout the state. The methodology of this study involved conceptualizing the principles and protocols used for network management, describe the scenario of the suggested company, analyze and compare some of the open source solutions commonly used in this area of search, deploy the solution best adapted to the environment company, evaluate and discuss the results and propose improvements.
Keywords: Network management. Network management protocols. Network management software. Zabbix.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
LISTA DE FIGURAS
Figura 1 - Modelo de gerenciamento de redes .......................................................... 24
Figura 2 - Áreas-chave de um gerenciamento de redes .......................................... 25
Figura 3 - Modelo de gerenciamento centralizado .................................................... 32
Figura 4 - Modelo de gerenciamento distribuído. ...................................................... 32
Figura 5 - Interação entre o gerente e um agente ..................................................... 35
Figura 6 - Árvore MIB ................................................................................................ 36
Figura 7 - Configurações do serviço SNMP em um ambiente Windows 7. ............... 38
Figura 8 - Arquitetura de gerenciamento de redes utilizando o protocolo SNMP. ..... 39
Figura 9 - Arquitetura de gerenciamento SNMP ........................................................ 42
Figura 10 - Formato SNMP ....................................................................................... 43
Figura 11 - Formato da mensagem de Requisições do SNMP. ................................ 46
Figura 12 - Formato da mensagem de resposta. ...................................................... 46
Figura 13 - Formato de mensagem de Trap no SNMPv1. ......................................... 47
Figura 14 - Sequência do PDU SNMP. ..................................................................... 48
Figura 15 - Arquitetura SNMPv2. .............................................................................. 50
Figura 16 - Formato de mensagem PDU do SNMPv2. ............................................. 51
Figura 17 - Evolução do SNMP. ................................................................................ 54
Figura 18 - Arquitetura de uma entidade SNMPv3 .................................................... 55
Figura 19 - Formato de mensagem SNMPv3 ............................................................ 56
Figura 20 - Imagem de um gráfico gerado pelo MRTG. ............................................ 60
Figura 21 - Imagem de um gráfico gerado pelo RRDTool ......................................... 61
Figura 22 - Informações de host no NTop ................................................................. 62
Figura 23 - Tela do software Nagios ......................................................................... 64
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Figura 24 - Tela de gráficos do software Cacti .......................................................... 65
Figura 25 - Interface do OpenNMS ........................................................................... 66
Figura 26 - Interface do Pandora FMS ...................................................................... 67
Figura 27 - Interface do Zabbix ................................................................................. 69
Figura 28 - Interface do Zenoss ................................................................................ 70
Figura 29 - Cenário da administração central da Costaneira .................................... 76
Figura 30 - Cenário das filiais da Costaneira ............................................................ 77
Figura 31 - Tipos de abordagens do Zabbix .............................................................. 80
Figura 32 - Diagrama de operação do Zabbix utilizando proxies .............................. 81
Figura 33 - Componentes do Zabbix Server ............................................................. 82
Figura 34 - Fluxograma de operação do Zabbix........................................................ 83
Figura 35 - Modelo proposto de implantação do Zabbix ........................................... 85
Figura 36 - Tela de templates personalizados........................................................... 88
Figura 37 - Regra de auto busca para descoberta de interfaces de rede ................. 89
Figura 38 - Monitoramento JMX na empresa Costaneira .......................................... 90
Figura 39 - Monitoramento do banco de dados PostgreSQL .................................... 91
Figura 40 - Tela de ações do Zabbix ......................................................................... 92
Figura 41 - Tela de status do Zabbix ......................................................................... 94
Figura 42 - Gráfico de porcentagem de processos de coleta de dados ocupados no
Zabbix ....................................................................................................................... 97
Figura 43 - Fila de itens a serem atualizados por proxy usando configurações padrão
.................................................................................................................................. 97
Figura 44 - Fila de itens a serem atualizados por proxy após ajustes de
configurações ............................................................................................................ 98
Figura 45 - Gráfico de performance do servidor Zabbix ............................................ 98
Figura 46 - Comparativo de tráfego de rede na interface do Zabbix antes e depois de
sua implantação ........................................................................................................ 99
Figura 47 - Comparativo de tráfego de rede na interface da VPN na administração
central antes e depois da implantação do Zabbix ................................................... 100
Figura 48 - Comparativo de tráfego de rede antes e depois da implantação do Zabbix
na interface do Zabbix Proxy em uma filial remota .................................................. 100
Figura 49 - Comparativo de tráfego de rede antes e depois da implantação do Zabbix
na interface da VPN em uma filial remota ............................................................... 101
Figura 50 - Consumo de CPU e memória do Zabbix ............................................... 102
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Figura 51 - Consumo de CPU e memória do Zabbix Prox. ..................................... 102
Figura 52 - Consumo de CPU do servidor Zabbix sem monitoramento x com
monitoramento ........................................................................................................ 103
Figura 53 - Consumo de CPU do Zabbix Proxy sem monitoramento x com
monitoramento ........................................................................................................ 104
Figura 54 - Gráfico de tráfego de rede do link ADSL de uma filial remota .............. 105
Figura 55 - Tela contendo gráficos de tráfego de rede em todas as interfaces de um
servidor ................................................................................................................... 105
Figura 56 - Mapa contendo elementos de um grupo de host .................................. 106
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
LISTA DE QUADROS
Quadro 1 - Definição e objetivos das técnicas de polling e event-reporting. ............. 29
Quadro 2 - Descrição dos controles de segurança e configuração. .......................... 29
Quadro 3 - Tipos de objetos da MIB. ......................................................................... 36
Quadro 4 - Controles suportados de uma MIB. ......................................................... 37
Quadro 5 - Mensagens SNMP .................................................................................. 43
Quadro 6 - Tipos e descrições de PDUs ................................................................... 51
Quadro 7 - Códigos de erros do SNMPv2 ................................................................. 52
Quadro 8 - Componentes do protocolo SNMPv3 ...................................................... 54
Quadro 9 - Campos utilizados em uma mensagem SNMPv3 ................................... 56
Quadro 10 - Comparativo entre softwares de Gerenciamento .................................. 71
Quadro 11 - Informações dos links na administração da Costaneira ........................ 74
Quadro 12 - Informações dos links nas filiais da Costaneira ..................................... 77
Quadro 13 - Equipamentos gerenciados x risco ao negócio ..................................... 78
Quadro 14 - Equipamentos a serem monitorados ..................................................... 79
Quadro 15 - Comparativo entre monitoramento em node e monitoramento baseado
em proxy do Zabbix ................................................................................................... 80
Quadro 16 - Parâmetros alterados no arquivo de configuração do Zabbix Server .... 86
Quadro 17 - Parâmetros alterados no arquivo de configuração do Zabbix Proxy ..... 87
Quadro 18 - Parâmetros alterados no arquivo de configuração dos agentes Zabbix 87
Quadro 19 - Fórmula para estimar o espaço em disco do Zabbix ............................. 94
Quadro 21 - Comparativo de ativos e serviços monitorados antes e depois da
implantação do Zabbix ............................................................................................ 107
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
LISTA DE ABREVIATURAS
ASN.1 Abstract Syntax Notation One
CMOT Common Management Information Protocol Over Tcp/IP
CPU Central Processing Unit
GPL General Public License
HMP Host Monitoring Protocol
HTML HyperText Markup Language
IP Internet Protocol
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
ISO International Organization for Standarization
JMX Java Management Extensions
JSON Javascript Object Notation
LAN Local Area Network
LDAP Lightweight Directory Access Protocol
MIB Management Information Base
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
MRTG Multi Router Traffic Grapher
NMP Network Management Protocol
OID Object Identifier
OSI Open Systems Interconnection
PDU Protocol Data Unit
RFC Request for Comments
RMON Remote Network Monitoring
RRDTOOL Round Robin Database Tool
ICMP Internet Control Message Protocol
SLA Service-Level Agreement
SGMP Simple Gateway Monitoring Protocol
SMI Structure of Management Information
SNMP Simple Network Management Protocol
SMS Short Message Service
TI Tecnologia da Informação
TCP Transmission Control Protocol
UDP User Datagram Protocol
USM User-based Security Model
VACM View-based Access Control Mode
VPN Virtual Private Network
XMPP Extensible Messaging and Presence Protocol
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
SUMÁRIO
1 INTRODUÇÃO ....................................................................................................... 17 1.1 Motivação ........................................................................................................... 19 1.2 Objetivos ............................................................................................................ 21
1.2.1 Objetivos Gerais ............................................................................................. 21
1.2.2 Objetivos Específicos .................................................................................... 21
1.3 Descrição dos Capítulos ................................................................................... 22
2 CONCEITOS BÁSICOS DE GERÊNCIA DE REDES ............................................ 23
2.1 A importância do gerenciamento de redes ..................................................... 23 2.2 Áreas de gerenciamento ................................................................................... 25 2.2.1 Gerenciamento de Configuração .................................................................. 25
2.2.2 Gerenciamento de Contabilidade ................................................................. 26
2.2.3 Gerenciamento de Desempenho ................................................................... 26
2.2.4 Gerenciamento de Falhas .............................................................................. 26
2.2.5 Gerenciamento de Segurança ....................................................................... 27
2.3 Monitoramento e controle da rede ................................................................... 28
2.3.1 Monitoramento ............................................................................................... 28
2.3.2 Controle de Rede ............................................................................................ 29
2.4 Arquitetura do Gerenciamento de Redes ........................................................ 30 2.4.1 Estação de gerenciamento ............................................................................ 30
2.4.1.1 Gerenciamento centralizado ...................................................................... 31
2.4.1.2 Gerenciamento distribuído ......................................................................... 32
2.4.2 Agentes coletores .......................................................................................... 33
2.4.3 Management Information Base (MIB) ........................................................... 34
2.4.3.1 Tipos de objetos da MIB ............................................................................. 36
2.4.3.2 Controle de acesso aos valores da MIB .................................................... 37
3 PROTOCOLO SNMP ............................................................................................. 39 3.1 Structure of Management Information (SMI) ................................................... 40 3.2 Protocolo SNMPv1 ............................................................................................ 41 3.2.1 Arquitetura do protocolo SNMPv1 ................................................................ 41
3.2.2 Formato da mensagem SNMPv1 ................................................................... 43
3.2.3 Transmissão de uma mensagem SNMPv1 ................................................... 44
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
3.2.4 Recepção de uma mensagem SNMPv1 ........................................................ 44
3.2.5 Variable bindings do protocolo SNMPv1 ..................................................... 45
3.2.6 GetRequest PDU do protocolo SNMPv1 ....................................................... 45
3.2.7 GetNextRequest PDU do protocolo SNMPv1 ............................................... 46
3.2.8 SetRequest PDU do protocolo SNMPv1 ....................................................... 47
3.2.9 Trap PDU do protocolo SNMPv1 ................................................................... 47
3.2.10 Limitações do protocolo SNMPv1............................................................... 48
3.3 Protocolo SNMPv2 ............................................................................................ 49
3.3.1 Arquitetura do protocolo SNMPv2 ................................................................ 49
3.3.2 Formato da mensagem do protocolo SNMPv2 ............................................ 51
3.3.3 Limitações do protocolo SNMPv2 ................................................................ 53
3.4 Protocolo SNMPv3 ............................................................................................ 53 3.4.1 Arquitetura do protocolo SNMPv3 ................................................................ 54
3.4.2 Formato da mensagem do protocolo SNMPv3 ............................................ 55
3.4.3 Segurança e controle de acesso do protocolo SNMPv3 ............................. 57
4 FERRAMENTAS DE GERENCIAMENTO E MONITORAMENTO DE REDES ..... 59 4.1 MRTG .................................................................................................................. 60
4.2 RRDTool ............................................................................................................. 60 4.3 NTOP .................................................................................................................. 61
4.4 Nagios ................................................................................................................ 62 4.5 Cacti.................................................................................................................... 65 4.6 OpenNMS ........................................................................................................... 66
4.7 Pandora FMS ..................................................................................................... 67 4.8 Zabbix ................................................................................................................. 67
4.9 Zenoss ................................................................................................................ 69 4.10 Comparativo entre as ferramentas de gerenciamento ................................. 71 4.11 Análise dos resultados obtidos ..................................................................... 71
5 PROPOSTA ........................................................................................................... 73 5.1 Caracterização da empresa .............................................................................. 73
5.1.1 Infraestrutura de TI ......................................................................................... 74
5.1.2 Administração Central ................................................................................... 74
5.1.3 Centro de Distribuição ................................................................................... 76
5.1.4 Filiais ............................................................................................................... 76
5.1.5 Análise do ambiente....................................................................................... 78
5.2 Modelo de implantação do Zabbix ................................................................... 79
5.3 Componentes do Zabbix ................................................................................... 82 5.4 Fluxo de operação do Zabbix ........................................................................... 83
5.5 Cenário proposto .............................................................................................. 84 5.6 Uso de templates personalizados .................................................................... 88
5.7 Uso de regras de auto busca ........................................................................... 89 5.8 Monitoramento de aplicações Java ................................................................. 90 5.9 Monitoramento do banco de dados PostgreSQL ........................................... 91
5.10 Monitoramento proativo ................................................................................. 92 6 RESULTADOS OBTIDOS ..................................................................................... 93 6.1 Equipamentos monitorados ............................................................................. 93
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
6.2 Cálculo para estimativa do banco de dados Zabbix ...................................... 94 6.3 Performance ...................................................................................................... 96 6.4 Consumo de banda de rede ............................................................................. 98 6.5 Consumo de CPU e memória ......................................................................... 101 6.7 Formas de análise dos itens coletados ......................................................... 105
6.8 Comparativo de ativos monitorados antes e depois da implantação do Zabbix ..................................................................................................................... 106 7 CONSIDERAÇÕES FINAIS ................................................................................. 108 7.1 Trabalhos Futuros ........................................................................................... 110
REFERÊNCIAS ....................................................................................................... 111
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
17
1 INTRODUÇÃO
O surgimento das redes de computadores, em meados da década de 60,
marcou o início de uma era digital, na qual a informação tornaria-se um bem
intangível extremamente valioso não somente para a competitividade econômica,
como também para aspectos sociais, culturais, governamentais, entre outros. Neste
período inicial, as redes de computadores eram limitadas apenas para o uso militar
ou universidades. Pelo fato de serem relativamente simples e pequenas, com
poucos nós e distribuídas localmente, a necessidade de gerenciamento era mínima,
podendo ser efetuada de forma centralizada.
Alguns protocolos de gerenciamento foram inicialmente implementados na
década de 70, como o Internet Control Message Protocol (ICMP), que possibilitava a
troca de mensagens entre roteadores e hosts, permitindo que houvesse uma
interação entre ambas as partes, a fim de monitorar o status da comunicação por
meio de mensagens de echo/echo reply (STALLINGS, 1999).
A partir da década de 80, com a expansão do Transmission Control Protocol
over Internet Protocol(TCP/IP), as redes de computadores passaram a ser mais
difundidas, e, com isso, aumentou a necessidade de mecanismos para o
gerenciamento das mesmas. Alguns protocolos surgiram nessa época como o Host
Monitoring Protocol (HMP), Simple Gateway Monitoring Protocol (SGMP), que mais
tarde foi substituído pelo Simple Network Management Protocol (SNMP) e o
Common Management Information Protocol Over Tcp/IP (CMOT) (STALLINGS,
1999).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
18
Desde então, as redes de computadores tornaram-se extremamente
complexas. É possível interligar dispositivos dos mais diversos tipos e funções como
smartphones, câmeras de vigilância, impressoras, notebooks, servidores, entre
outros, não apenas limitando-os em áreas locais, como também geograficamente
distribuídas, inclusive entre continentes.
Alguns aspectos comuns que afetam a infraestrutura de Tecnologia da
Informação (TI) nas organizações e podem acarretar algum tipo de perda, seja
financeira ou de informação, são a contaminação por vírus, a indisponibilidade de
algum serviço como o acesso à Internet, hardware com defeito, queda de luz, entre
outros.
Com isso, cinco áreas de gerência de redes foram definidas pela
International Organization for Standardization/International Electrotechnical
Comission (ISO/IEC 10040,1998), são elas:
a) gerenciamento de configuração;
b) gerenciamento de contabilidade;
c) gerenciamento de desempenho;
d) gerenciamento de falhas;
e) gerenciamento de segurança.
Essas áreas provêm medidas que devem ser tomadas para um melhor
gerenciamento da área de redes, favorecendo, assim, a qualidade e disponibilidade
dos serviços aos quais estão relacionados.
Ao passo que uma rede se torna geograficamente distante, sua complexidade
em relação à infraestrutura e o gerenciamento aumenta de tal forma que é
imprescindível utilizar algum mecanismo automatizado para auxiliar no seu controle
e monitoramento. É nesse ponto que muitas soluções em forma de software
surgiram e muitas delas utilizam características semelhantes que visam, no mínimo:
a) monitoramento distribuído com um gerenciamento centralizado: Toda a
informação de um host monitorado é coletada através de um software agente
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
19
(remoto, local ou móvel) e armazenada em uma estação de gerenciamento,
sendo possível visualizar as informações através de um browser, utilizando o
modelo Web-based;
b) proatividade: os agentes monitores devem ter a capacidade de prever
situações adversas baseadas em eventos, estatísticas, entre outros, e,
através disso, executarem alguma ação visando alertar, amenizar e/ou corrigir
o problema;
c) eficiência e disponibilidade: a arquitetura de um software de gerenciamento
deve otimizar ao máximo o uso dos recursos computacionais, de forma que o
mesmo possa garantir disponibilidade adequada aos serviços geridos com o
máximo de eficiência;
d) integração e customização: capacidade de integração com outros serviços e
possibilidade de customizar novas funcionalidades;
e) segurança: controle de acesso e permissões para executar determinadas
ações.
Logo, busca-se atingir cada vez mais níveis de maturidade quanto à
governança de TI, melhorando o serviço prestado, garantindo a disponibilidade,
aumentando a eficiência e alinhando os requisitos de TI com os requisitos do
negócio, agregando valor ao mesmo.
1.1 Motivação
Para quem trabalha na área de administração de redes ou entende da
importância de manter os ativos em condições de propiciar uma disponibilidade de
serviço aos seus utilizadores, sabe dos riscos expostos ao negócio quando ele está
defeituoso ou indisponível.
Na empresa Costaneira, a infraestrutura de redes de computadores está
distribuída entre nove filiais, mais o prédio da administração e o centro de
distribuição. As ferramentas utilizadas para o gerenciamento e monitoramento da
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
20
rede mostram-se ineficientes, pois atendem a uma pequena parcela do que poderia
ser gerenciado. Dessa forma, quando algum problema surge, muitas vezes sua
identificação demora a ser detectada e consequentemente corrigida, acarretando em
problemas de indisponibilidade de serviços que são essenciais para a empresa.
Por causa de limitações tecnológicas na época em que foi iniciado o
desenvolvimento do sistema de gestão interno da empresa, em meados de 2005,
houve a necessidade de utilizar servidores fisicamente alocados em cada uma das
filiais, contendo uma cópia do banco de dados principal que, através de um sistema
complexo de replicação, pudesse garantir a consistência das informações ali
contidas para todas as empresas afiliadas. Portanto, a disponibilidade do link de
Internet na empresa é imprescindível para que este processo funcione de forma
satisfatória, evitando possíveis problemas de inconsistência e perda de dados. Vale
ressaltar, também, que diversos setores da empresa são prejudicados quando não é
possível acessar a Internet - como a área de vendas - por não poderem emitir notas
fiscais eletrônicas, solicitar liberações de crédito, entre outros fatores.
Outra questão que merece relevância é o gerenciamento dos servidores
localizados em cada uma das filiais. Pelo fato de os usuários utilizarem terminais thin
client, todas as informações pertinentes a eles estão armazenadas no servidor local,
além, como já mencionado, do banco de dados da aplicação e arquivos de projetos
de móveis específicos para cada cliente. Caso aconteça algum problema com o
servidor em uma filial que não possa ser corrigido remotamente, provavelmente
determinará o deslocamento de um integrante da equipe de suporte até aquela filial,
para avaliar e buscar uma solução. Durante esse período, a ameaça gerou um
grande risco de a loja ficar parada em termos de acesso aos sistemas,
impossibilitando ou dificultando as vendas e, consequentemente, trazendo
problemas ao negócio.
Utilizar um software que possa gerenciar todos os nós da rede, mesmo estes
estando em locais geograficamente distribuídos, armazenando e apresentando as
informações obtidas em um nó central, de forma que o gerenciamento torne-se
eficiente e eficaz, é o principal estímulo desse trabalho, bem como uma grande
motivação da área de TI da empresa Costaneira. Dessa forma, o adminsitrador de
redes poderá dispor de uma ferramenta completa de gerenciamento, capaz de
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
21
monitorar, prevenir, detectar e/ou corrigir determinadas falhas que, do ponto de vista
do negócio, podem acarretar perdas significativas.
1.2 Objetivos
1.2.1 Objetivos Gerais
O objetivo desse trabalho é apresentar uma proposta de gerenciamento de
unidades geograficamente distribuídas a partir de um nó central, atendendo aos
conceitos teóricos e padrões de arquitetura necessários para obter o grau de
excelência na área de gerenciamento de redes.
1.2.2 Objetivos Específicos
No que toca aos objetivos específicos, pretende-se demonstrar que é possível
implantar uma solução definitiva para o problema de gerenciamento de ativos e
serviços de rede, de forma eficiente, utilizando poucos recursos computacionais e de
comunicação de dados, e que seja passível de monitorar qualquer equipamento ou
serviço, de forma proativa, sem a necessidade de investimentos em software
proprietário.
Para que isso seja satisfeito, será necessário compreender metodologias,
protocolos e conceitos envolvidos no monitoramento de redes, bem como o
planejamento de estratégias para o controle e gerenciamento das mesmas.
Assim, espera-se não só melhorar a qualidade e disponibilidade dos serviços
de TI do ambiente monitorado, reduzindo as taxas de incidentes, como também
poder analisar padrões para melhorar o desempenho dos diversos componentes que
englobam a infraestrutura de TI, e verificar tendências para planejar futuras
expansões, contribuindo para o sucesso do negócio como um todo.
Também é esperado que essa proposta seja útil a todos que estejam
buscando algum software que os auxiliem na gerência de suas redes, de forma que
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
22
possam concentrar seus esforços em melhorias para a infraestrutura das mesmas,
e, ao mesmo tempo, terem a capacidade de identificar, prevenir e remediar
determinados problemas comuns às redes de computadores, de forma centralizada,
mesmo apresentando um cenário distribuído.
1.3 Descrição dos Capítulos
O presente trabalho está estruturado da seguinte forma: no Capítulo 2 é feita
uma introdução sobre os conceitos básicos da gerência de redes, as áreas
funcionais de gerenciamento, definição de monitoramento e controle e uma breve
introdução à arquitetura de gerência de redes. No Capítulo 3 é contextualizado o
protocolo de gerenciamento de redes, o SNMP, em suas três versões: SNMPv1,
SNMPv2 e SNMPv3. Já no Capítulo 4 são apresentadas algumas ferramentas em
nível de software, que auxiliam no gerenciamento de redes. Também é feito um
comparativo entre essas ferramentas e uma análise dos resultados obtidos. O
Capítulo 5 é destinado a abordar a proposta de implantação do software Zabbix na
empresa analisada, verificando o cenário de TI da mesma, itens com maior
necessidade de gerenciamento, entre outros fatores. No Capítulo 6 discute-se os
resultados obtidos com a implantação do software referido, fazendo uma análise do
cenário antes e depois de sua implementação e o impacto que o mesmo causou na
rede da empresa.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
23
2 CONCEITOS BÁSICOS DE GERÊNCIA DE REDES
Uma rede de computadores pode ser definida como um meio de interligar
recursos físicos e lógicos entre dois ou mais computadores. Tais recursos podem
ser o compartilhamento de uma impressora, arquivos, unidades de discos, entre
outros. Por existirem inúmeros dispositivos capacitados para interligarem-se em
ambientes tanto homogêneos como heterogêneos, e pelo crescimento das redes de
computadores, existe a necessidade de gerenciar todos esses recursos.
Esse capítulo apresenta os conceitos envolvidos na gerência de redes,
mostrando na seção 2.1 a sua importância em um cenário organizacional. Já a
seção 2.2 descreve as áreas funcionais envolvidas no gerenciamento de acordo com
a ISO/IEC 10040 (1998). A seção 2.3 caracteriza o monitoramento e controle de
rede e a seção 2.4 caracteriza a arquitetura envolvida no gerenciamento da mesma.
2.1 A importância do gerenciamento de redes
O papel fundamental da gerência de redes de computadores é controlar o seu
uso a fim de garantir um funcionamento adequado aos seus usuários (SANTOS,
2004). Maximizar a eficiência e a produtividade da mesma pode se tornar uma tarefa
difícil, uma vez que se tem cenários cada vez mais complexos, aglomerando
inúmeros ativos, tanto físicos (hardware) como lógicos (software), em pontos
distribuídos da rede. Por esta razão, o profissional responsável pela administração
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
24
da rede de computadores, em uma organização, deve dispor de formas
automatizadas para monitorar e controlar a parte física e a parte lógica da rede.
Ter um software de gerenciamento é essencial, porém, é necessário que o
administrador conheça bem cada item que deseja monitorar e o que este representa
em um contexto geral da rede (SPECIALSKI, [2002]). Caso ele não tenha muito
conhecimento, provavelmente deixará de obter os melhores resultados, uma vez que
são inúmeros os padrões e as características envolvidas nos objetos gerenciados.
De acordo com Carvalho e Brisa (1993), um esquema de gerenciamento deve
conter algumas características, tais como:
a) gerenciamento da rede como parte integral dela mesma;
b) conter todas as informações sobre a rede, estatísticas, eventos, entre outros
devem dispor de um meio centralizado de visualização, de modo que seja
facilmente compreendido através de gráficos, por exemplo;
c) haver mecanismos de prioridades sobre mensagens de controle de rede
quanto a outros tipos de tráfego;
d) ter mecanismos de segurança e detecção de acesso não autorizado;
e) conter em um banco de dados as informações referentes aos componentes
da rede e seus usuários;
f) o funcionamento dos processos referentes ao gerenciamento, independente
do meio de transmissão;
g) a implementação de forma simples e flexível de qualquer alteração na rede.
Figura 1 - Modelo de gerenciamento de redes
Fonte: Santos et al. (2003, p. 122).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
25
2.2 Áreas de gerenciamento
Segundo disposto pela ISO/IEC 10040 apud Azevedo ([2009?], texto digital)
“o gerenciamento de redes provê mecanismos para monitoração, controle e
coordenação de recursos em um ambiente OSI e define padrões do protocolo OSI
para troca de informações entre estes recursos”. Através deste entendimento, foram
estabelecidas cinco áreas da gerência de redes que possuem necessidade de
gerenciamento: configuração, contabilidade, desempenho, falhas e segurança
(Figura 2). Cada uma destas áreas será analisada a seguir.
Figura 2 - Áreas-chave de um gerenciamento de redes
Fonte: Bonomo (2006, p. 7).
2.2.1 Gerenciamento de Configuração
Essa área é responsável por todas as mudanças relacionadas à estrutura
física e lógica da rede. Ela efetua a descoberta de elementos, coleta as suas
informações de configuração, adiciona, mantém e atualiza os mesmos, além de
descobrir interconectividade entre os objetos gerenciados. Também é responsável
por manter um inventário atualizado, registrando informações de configurações,
gerando eventos e relatórios, quando necessário, uma vez que todos os itens
gerenciados iniciam e terminam nessa etapa (SPECIALSKI, [2002]).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
26
2.2.2 Gerenciamento de Contabilidade
O gerenciamento de contabilidade é utilizado para analisar, mensurar e limitar
os recursos da rede por usuários ou grupo de usuários, garantindo, assim, a sua
utilização de forma correta, ou seja, sem abuso de privilégios de acessos ou
consumo exagerado desses recursos por parte dos usuários. São efetuadas coletas
de utilização da rede para conhecer o perfil dos usuários, fornecendo detalhes
suficientes para planejar o crescimento da mesma. O gerente de redes pode ainda
limitar o uso de certos recursos por usuários e/ou grupos de usuários quando
verificar o abuso por parte destes de seus privilégios.
2.2.3 Gerenciamento de Desempenho
Consiste em analisar, monitorar e planejar a capacidade da rede de acordo
com o seu desempenho. É útil, pois mantém a qualidade do serviço, utilizando
indicadores de desempenho que analisam, entre outros fatores, a existência de
gargalos, se o tráfego é excessivo, ou se o nível de capacidade de utilização é
aceitável (SPECIALSKI, [2002]).
Com isso é possível prevenir situações adversas antes que estas causem
problemas para o usuário final, efetuando as devidas correções de forma proativa,
ou ainda, indicando a necessidade de futuras expansões da rede.
2.2.4 Gerenciamento de Falhas
Esse gerenciamento fica a cargo de notificar, isolar e consertar falhas que
ocasionam prejuízos ou indisponibilidade do fluxo normal da rede. Segundo
Specialski ([2002], p. 3) “uma falha normalmente é causada por operações
incorretas ou um número excessivo de erros”. Quando isso ocorre, caso não seja
gerenciado, dependendo do nível da falha, poderá gerar indisponibilidade de
serviços que podem ser cruciais para o negócio de uma empresa, acarretando,
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
27
assim, prejuízos financeiros a esta. Por isso, quando uma falha ocorrer, é necessário
possuir um mecanismo que propicie (SPECIALSKI, [2002]):
a) determinar a origem da falha;
b) isolar a falha, deixando a rede funcional (sem interferências);
c) reorganizar a rede de modo que o impacto do componente que falhou seja
mínimo para a estrutura geral;
d) providenciar o reparo ou a troca do elemento que acarretou a falha,
restaurando, assim, seu estado anterior.
É interessante utilizar elementos redundantes, tanto para equipamentos
quanto para rotas de comunicação, pois isso gera um impacto minimizado quando
ocorre uma falha, gerando certo nível de tolerância a falhas (SPECIALSKI, [2002]).
2.2.5 Gerenciamento de Segurança
De acordo com Carvalho e Brisa (1993), o gerenciamento de segurança
assegura os dados da rede desde a proteção de senhas, utilizando a criptografia,
até a obrigatoriedade de alteração periódica das mesmas. Dessa forma, informações
pertinentes aos usuários devem ser acessadas somente por quem estiver
autorizado.
Segundo Specialski ([2002]), o gerenciamento de segurança trata de
questões como:
a) gerar, distribuir e armazenar chaves de criptografia;
b) manter e distribuir senhas e mecanismos de controle de acesso;
c) monitorar e controlar o acesso aos nodos da rede e suas informações;
d) coletar, armazenar e examinar logs de auditoria e segurança, permitindo
ativar/desativar estas atividades.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
28
2.3 Monitoramento e controle da rede
Para que se tenha um ambiente de rede gerenciável, deve-se destacar duas
categorias: monitoramento e controle da rede. Conforme Specialski ([2002]), o
monitoramento da rede é uma função de “leitura”, pois esta tem como finalidade
observar e analisar o estado e configuração da rede. Já o controle da rede, por
englobar tarefas como alterações de valores de algum parâmetro ou executar
determinada ação, é considerado uma função de “escrita”. Abaixo serão descritas
algumas funções pertinentes a cada uma destas categorias.
2.3.1 Monitoramento
Consoante Stallings (1999), as informações disponíveis para monitoramento
de rede podem ser classificadas em três categorias:
a) estática: informações geralmente pouco ou nada modificadas. Informa a
configuração atual e os elementos que estão envolvidos nessa configuração,
tal como número de portas de um switch ou roteador;
b) dinâmica: provê informações relacionadas com eventos na rede como, por
exemplo, a transmissão de um pacote na rede;
c) estatística: normalmente derivada de informações dinâmicas, possibilitando a
verificação de estatísticas sobre determinado item, tal como a média de
pacotes transmitidos por unidade de tempo provinda de algum sistema.
Também são utilizadas duas técnicas para disponibilizar as informações
vindas dos agentes para o gerente. Essas técnicas são chamadas de polling e
event-reporting e seus conceitos estão definidos conforme o Quadro a seguir:
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
29
Quadro 1 - Definição e objetivos das técnicas de polling e event-reporting.
TÉCNICA DESCRIÇÃO OBJETIVOS
Polling Gerente solicita alguma
informação (pesquisa, estrutura,
variável, etc) da MIB de um
agente e este responde com as
informações pertinentes.
- Aprendizado sobre configuração de algum
item gerenciado;
- Informação sobre condição de algum item
gerenciado;
- Informações periódicas para melhor
detalhamento de alguma área crítica.
Event-
reporting
Agente gera relatórios periódicos
e envia para o gerente. Gerente
fica apenas aguardando as
informações recebidas.
- Relatório sobre estado atual de um agente;
- Relatório sobre algum evento importante ou
não habitual;
- Detectar problemas assim que ocorrerem.
Fonte: Adaptado pelo autor com base em Stallings (1999, p. 27 a 29).
2.3.2 Controle de Rede
A área de controle de redes está diretamente ligada à questão de modificação
de parâmetros de variáveis e execução de ações em um sistema gerenciado. De
acordo com as cinco áreas do gerenciamento de redes (configuração,
contabilização, desempenho, falhas e segurança) definidas pela ISO/IEC 10040
(1998), o controle de redes está voltado mais ao gerenciamento de configuração e
segurança, enquanto o monitoramento de redes está direcionado aos outros
elementos restantes.
Os aspectos mais relevantes sobre gerência de configuração e de segurança,
conforme Specialski ([2002]), são descritos conforme segue (Quadro 2):
Quadro 2 - Descrição dos controles de segurança e configuração.
CONTROLE FUNÇÃO
Configuração - Definir informações de configuração para os recursos e seus atributos sujeitos ao
gerenciamento;
- Atribuir, modificar e examinar valores de parâmetros;
- Definir, modificar e examinar a relação entre recursos/componentes da rede;
- Iniciar/Parar as operações de rede;
- Relatório de status de configuração.
CONTINUA
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
30
CONCLUSÃO
CONTROLE FUNÇÃO
Segurança - Manter a informação segura;
- Controlar o acesso aos recursos;
- Controlar o processo de criptografia.
Fonte: Specialski ([2002], p. 6).
Quanto ao controle de segurança, vale ressaltar que as principais ameaças
relacionadas à segurança vêm de aspectos como interrupção, interceptação,
modificação e mascaramento. Com isso, os objetivos principais da segurança em
redes é manter a confidencialidade, integridade e disponibilidade de seus serviços
(STALLINGS, 1999).
2.4 Arquitetura do Gerenciamento de Redes
Em conformidade com Stallings (1999), para gerenciar uma rede que usa o
protocolo TCP/IP é necessário especificar os seguintes elementos:
a) estação de gerenciamento ou gerente;
b) agentes coletores;
c) Management Information Base (MIB);
d) protocolo de gerenciamento de redes (SNMP).
As próximas subseções destinam-se a descrever cada um destes elementos.
2.4.1 Estação de gerenciamento
Um gerente SNMP capta as informações fornecidas pelos seus agentes
através das MIB’s e serve como modelo de interação homem-máquina, através de
uma interface, via aplicação, possibilitando que o administrador da rede possa
visualizar, monitorar e controlar os elementos gerenciados em uma rede de
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
31
computadores. Ele pode ser instalado tanto em um servidor dedicado, como em um
compartilhado, e aborda alguns itens que são necessários para um gerenciamento
mínimo, como:
a) possuir meios para a gestão de análise de dados como gráficos e mapas,
recuperação de falhas, log de eventos, entre outros;
b) ter uma interface na qual o administrador possa monitorar e controlar a rede;
c) ter capacidade de transformar os requisitos do administrador em informações
úteis para o monitoramento e controle efetivo dos elementos na rede;
d) conter um banco de dados para armazenar as informações extraídas dos
objetos gerenciados (STALLINGS, 1999).
Em um ambiente onde há necessidade de gerenciamento, pode-se classificar
o uso dos gerentes de duas formas: centralizado e distribuído.
2.4.1.1 Gerenciamento centralizado
Quando utilizada a gerência centralizada, todo o fluxo de controle e
monitoramento da rede é estabelecido em uma única estação, ou seja, pode ser
usado um servidor dedicado, por exemplo, que será responsável pela interação
entre os objetos gerenciados (elementos da rede), o gerente (aplicação) e a pessoa
responsável pela administração da rede (interface). Esse tipo de arquitetura é
normalmente indicado para redes de menor porte, por não necessitar de muita
complexidade.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
32
Figura 3 - Modelo de gerenciamento centralizado
Fonte: Do autor.
2.4.1.2 Gerenciamento distribuído
Já na gerência distribuída, o controle é feito de forma descentralizada, sendo
este dividido em domínios de gerência, onde cada domínio é controlado por um
gerente. Esse gerente é responsável por coletar as informações e tomar as decisões
pertinentes ao seu domínio, e, dentro de um escopo global, existe um gerente
principal que recebe as informações vindas de todos os seus subgerentes,
formando, assim, uma hierarquia entre domínios. Esse modelo é mais difundido nas
redes que se encontram geograficamente distantes (WALSH, 2008) e possuem
equipes de suporte em cada nó gerenciado.
Figura 4 - Modelo de gerenciamento distribuído.
Fonte: Do autor.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
33
2.4.2 Agentes coletores
Todos os dispositivos de uma rede que podem ser gerenciados como
roteadores, servidores, switches, estações de trabalho, entre outros, para que seja
satisfeita essa necessidade de gestão, devem possuir agentes SNMP em nível de
software, que são responsáveis por todas as informações trocadas entre as
estações de gerenciamento e os elementos gerenciados.
De acordo com Stallings (1999), a ligação entre um gerente e seus agentes é
estabelecida pelo protocolo Network Management Protocol (NMP), e, ao utilizar uma
rede TCP/IP, a troca de mensagens entre os dois é feita pelo protocolo SNMP, que
inclui algumas operações principais aplicáveis às MIBs:
a) get: provê que o gerente possa recuperar valores dos objetos no agente;
b) getNext: tem o mesmo princípio do get, porém, é utilizado para capturar
valores de variáveis em tabelas da MIB onde o tamanho é desconhecido.
Assim, é necessário utilizar um comando getNext inicial com o nome da
tabela para capturar o seu primeiro valor e ir repetindo o comando sempre
com a resposta do anterior para continuar a sequência, até chegar ao final,
recuperando todos os valores;
c) response: permite ao agente responder alguma requisição vinda do gerente.
Após receber qualquer operação SNMP, exceto o trap, o agente executa essa
operação, e, obtendo ou não sucesso, envia uma mensagem de resposta ao
gerente (MELLO, 2000);
d) set: permite que a estação de gerenciamento defina o valor dos objetos no
agente;
e) trap: permite que um agente possa notificar a estação de gerenciamento de
eventos significativos (STALLINGS, 1999).
A aplicação gerente solicita alguma informação (get) ou envia uma mensagem
contendo uma ação (set), que deve ser tomada para o agente, e este, através do
protocolo SNMP, se encarrega de validar, interpretar e responder às devidas
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
34
requisições de forma que o processamento pode ser assíncrono, ou seja, as
informações retornadas pelo agente podem não ter sido solicitadas pelo gerente,
porém, caso o agente assumir que é algo crítico (trap), a informação é transmitida.
A priori, um agente não deve originar mensagens SNMP, mas apenas
respondê-las. Todavia, há casos em que um agente necessita realizar alguma
interceptação direta no dispositivo gerenciado, por algum motivo de segurança,
forçando-o a realizar um evento. Esse evento gera um alarme no agente, que se
encarrega de executar alguma tarefa crítica, como reinicializar ou desligar um
sistema, por exemplo, e agindo, assim, de modo proativo.
Para que haja uma maior segurança na comunicação entre gerente e
agentes, existe a possibilidade de criar comunidades SNMP, nas quais são
explicitamente definidos quais hosts pertencerão ao grupo e somente trocarão
informações os agentes e estações de gerenciamento pertencentes a determinada
comunidade.
2.4.3 Management Information Base (MIB)
Para que um gerente e agente consigam trocar informações sobre os
elementos gerenciados na rede é necessário que haja um padrão de nomenclatura
para cada objeto. Dessa forma, através do protocolo SNMP, é possível interagir com
os mesmos.
De acordo com Comer (2007), o protocolo SNMP descreve de forma
detalhada apenas o formato da mensagem e a codificação desta; outro padrão é
utilizado para especificar as variáveis MIB, juntamente com a definição das
operações de carga e armazenamento em cada variável.
Já para Specialski ([2002]), uma MIB situada em um agente deve conter
informações sobre a configuração e comportamento do mesmo, bem como
parâmetros que possibilitem controlar alguma operação no nodo do agente. Da
mesma forma, a MIB inserida no gerente também possui as informações da sua
localização, entretanto, necessita ter informações sobre os agentes que fazem parte
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
35
de seu domínio. A Figura 5 simboliza a interação entre um gerente e um agente,
com suas respectivas MIBs.
Figura 5 - Interação entre o gerente e um agente
Fonte: Rocha e Serradourada (2008, p. 10).
A versão inicial da MIB foi designada através do documento Request For
Comments (RFC) 1066 (MCCLOGHRIE; ROSE, 1988) e passou por um processo
de evolução, sendo substituída pela MIB II, definida pelo RFC 1213 (MCCLOGHRIE;
ROSE, 1991).
Uma MIB obedece a uma regra de nomenclatura chamada Abstract Syntax
Notation One (ASN.1) e a sua estrutura é descrita através de uma Structure of
Management Information (SMI). Com esse modelo é possível representar,
armazenar e transferir informações de gerenciamento, bem como criar novas MIBs.
Quanto aos objetos de uma MIB, estes são organizados em um formato de
árvore hierárquica e não possuem limites de expansão, tornando esse tipo de
arquitetura flexível a mudanças. Cada objeto também possui um identificador Object
Identifier (OID). Este OID nada mais é do que uma sequência de inteiros que serve
para identificar a posição do objeto inserido na árvore da MIB. Para deixar mais claro
essa questão, a Figura 6 mostra uma árvore MIB e seus objetos. Caso seja
necessário resgatar a posição de um objeto do tipo icmp, por exemplo, este seria
referenciado por iso.org.dod.internet.mgmt.Icmp e seu valor seria 1.3.6.1.2.5.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
36
Figura 6 - Árvore MIB
Fonte: Do autor, adaptado de Gta.ufrj (2004, texto digital).
2.4.3.1 Tipos de objetos da MIB
Conforme Mello (2000), uma MIB possui alguns tipos primitivos de valores
para os objetos, dentre eles:
Quadro 3 - Tipos de objetos da MIB.
TIPO NOME DESCRIÇÃO
Texto Display String Texto puro de no máximo 256 caracteres
Contador Counter Valor numérico maior que zero que só pode
ser incrementado.
Medida Gauer Valor numérico que pode aumentar e diminuir.
Inteiro Integer Valor inteiro positivo ou negativo.
Enumerados Enumerated Value Associa um campo texto a um valor numérico.
Tempo Time Tricks Tempo decorrido.
Objeto Object Contém um identificador para outro objeto da
MIB.
CONTINUA
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
37
CONCLUSÃO
TIPO NOME DESCRIÇÃO
Endereço IP IP address Endereço IP de algum dispositivo da rede.
Endereço Físico Physical address Endereço físico de um dispositivo da rede.
String String Cadeia de caracteres arbitrários
Tabela Table Entradas da tabela MIB.
Auxiliar Branch Tipos adicionais.
Fonte: Do autor, adaptado de Mello (2000).
2.4.3.2 Controle de acesso aos valores da MIB
Para que se tenha maior segurança para o acesso a valores de uma MIB
foram definidas algumas diretivas de controle para serem suportadas por ela. Tais
diretivas estão descritas no quadro abaixo (WALSH, 2008):
Quadro 4 - Controles suportados de uma MIB.
Fonte: Walsh (2008).
Outra forma de obter mais segurança é a utilização de comunidades. Assim,
antes de qualquer interação com algum objeto da MIB, deve-se primeiro informar o
nome comunitário do SNMP. Essa diretiva é configurada pelo próprio administrador
da rede e garante que somente aquela comunidade cadastrada terá acesso aos
objetos da MIB em questão (MELLO, 2000). Um exemplo disso está na Figura 7, na
qual é apresentada uma tela de propriedades do serviço SNMP em um ambiente
com sistema operacional Windows 7. É possível notar as configurações de controle
de acesso, como a criação das comunidades e diretivas das mesmas.
CONTROLE SUPORTADO
Apenas leitura Sim
Leitura e escrita Sim
Não acessível Sim
Acessível para notificação Sim
Leitura e criação Sim
Apenas escrita Não
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
38
Figura 7 - Configurações do serviço SNMP em um ambiente Windows 7.
Fonte: Do autor.
O próximo capítulo será destinado a uma apresentação básica do protocolo
de gerenciamento de redes, chamado Simple Network Management Protocol
(SNMP) e a diferenciar as suas versões.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
39
3 PROTOCOLO SNMP
O SNMP é o protocolo padrão utilizado para administração de redes
(COMER, 2007) e atualmente está na sua versão 3. Segundo o RFC 1157 (CASE et
al., 1990), o SNMP deve especificar a forma como um gerente e os agentes devem
se comunicar, de acordo com uma codificação de mensagem específica nomeada
ASN.1. A (Figura 8), esboça a arquitetura de uma rede gerenciada utilizando o
procotolo SNMP.
Figura 8 - Arquitetura de gerenciamento de redes utilizando o protocolo SNMP.
Fonte: Salvo ([2011?], texto digital).
Em sua proposta inicial, o SNMP utilizava essas duas características
(Stallings,1999):
a) Structure of Management Information (SMI): estrutura única para gestão da
informação;
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
40
b) MIB: Estrutura global ou esquema global para o banco de dados de objetos.
Por utilizar o modelo TCP/IP no lugar do modelo Open Systems
Interconnection (OSI), o SNMP tornou-se muito difundido, fato este comprovado pela
grande implementação deste protocolo nos equipamentos de rede modernos. Desde
a sua criação, o SNMP tem sofrido melhorias quanto à segurança, funcionalidades,
entre outros, chegando a ser especificadas novas versões do protocolo, como a
versão 2 e 3 (SNMPv2 e SNMPv3, respectivamente), e também extensões
adicionais às MIBs, como o Remote Network Monitoring (RMON), versão 1 e 2, que
visa monitoramento remoto baseado em fluxo e não somente em dispositivos.
(MURRAY;STALVIG, 2008).
A seção 3.1 apresenta uma definição ao SMI. Já a seção 3.2 mostrará o
princípio de funcionamento do protocolo SNMPv1, sua arquitetura, o formato de
envio das mensagens, bem como métodos de transmissão e recebimento das
mesmas e suas limitações. A seção 3.3 introduz o protocolo SNMPv2 e as melhorias
que este apresenta em relação ao seu antecessor e suas limitações. A seção 3.4 é
destinada a apresentar a terceira versão do protocolo SNMP, o SNMPv3, com uma
breve descrição das melhorias implementadas, principalmente no que se refere à
segurança.
3.1 Structure of Management Information (SMI)
Uma SMI, ou estrutura de informação de gerenciamento, está especificada
pelo documento RFC 1155 (MCCLOGHRIE; ROSE, 1990) e define um modelo de
como uma MIB deve ser definida e construída. A SMI é responsável por identificar
os tipos de dados contidos em uma MIB e especificar como os recursos desta são
representados e nomeados. A filosofia da SMI é encorajar a simplicidade e
extensibilidade dentro da MIB, o que gera um contraste quanto à tentativa de utilizá-
la no modelo OSI, pois este é extremamente complexo. Para fornecer uma maneira
padronizada de representar a informação de gestão, a SMI deve fazer o seguinte:
a) oferecer uma forma padronizada de definir a estrutura de uma MIB;
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
41
b) utilizar uma técnica padronizada para definição de objetos individuais, como
sintaxe e o valor de cada objeto;
c) padronizar a codificação dos valores de objetos.
3.2 Protocolo SNMPv1
Os estudos abordados até esta seção sobre gerenciamento de redes nos dão
uma visão geral do que, na prática, é o protocolo SNMP. Dentre os seus objetivos
destacam-se (SPECIALSKI, [2002]):
a) minimizar o número e complexidade das funções de gerenciamento;
b) possuir flexibilidade para futuras extensões;
c) ser independente de arquitetura e mecanismos dos dispositivos gerenciados.
Para Rocha e Serradourada (2008, p. 22), a definição do protocolo SNMP é a
seguinte:
O SNMP é um protocolo de gerência definido no nível de aplicação, e
utilizado para obter informações de servidores SNMP. Os dados são obtidos
através de requisições de um gerente a um ou mais agentes utilizando os
serviços do protocolo de transporte UDP (User Datagram Protocol).
3.2.1 Arquitetura do protocolo SNMPv1
O gerenciamento por SNMP é baseado no conceito de arquitetura
cliente/servidor. Uma aplicação de gerenciamento contendo um software gerente é
instalada em uma máquina tornando-se assim o servidor. O gerente pode efetuar
duas operações básicas de gerenciamento: get e set (operam na porta 161 através
do protocolo UDP). Essas operações fazem uma comunicação com cada dispositivo
que será gerenciado, efetuando um polling, ou seja, requisitando algum tipo de
informação sobre o seu estado naquele instante. Tais dispositivos (clientes)
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
42
possuem um software agente instalado, sendo responsável por interpretar as
requisições via SNMP-get ou SNMP-set (o get corresponde a algum tipo de
pesquisa e o set uma alteração no parâmetro de alguma variável do objeto
gerenciado), consultar uma base que detém todas as informações referentes ao
objeto gerenciado (MIB), e retornar ao servidor uma mensagem SNMP (get-
response) contendo o valor da informação solicitada pelo gerente.
O software agente pode, igualmente, gerar notificações, também conhecidas
como traps (opera na porta 162 através do protocolo UDP), sem que o gerente tenha
solicitado, quando alguma situação anormal esteja acontecendo. A aplicação
gerente recebe este alerta e o administrador da rede pode analisá-lo como bem
entender. Esta arquitetura pode ser mais bem exemplificada abaixo (Figura 9).
Figura 9 - Arquitetura de gerenciamento SNMP
Fonte: Filho (2009, texto digital).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
43
3.2.2 Formato da mensagem SNMPv1
O SNMP é um protocolo orientado a pacotes, sendo que cada pacote é
denominado Protocol Data Unit (PDU), possuindo uma estrutura que contém
cabeçalho, dados e informações de verificação do pacote (FILHO, 2009). Para
Stallings (1999), as mensagens SNMP são utilizadas para efetuar a troca de
informação entre a estação de gerenciamento e os agentes.
Cada mensagem possui o número da versão do protocolo SNMP, a
comunidade utilizada para intermediação entre o gerente e o agente e um dos cinco
tipos de operações do protocolo (getRequest, getNextRequest, setRequest,
getResponse, trap), conforme ilustrado na Figura 10.
Figura 10 - Formato SNMP
Fonte: Stallings (1999).
Quadro 5 - Mensagens SNMP
CAMPO DESCRIÇÃO
Version Versão do SNMP.
community Nome da comunidade SNMP.
request-id Identificador único dos pedidos tratados.
error-status Indica alguma exceção quanto ao comportamento do pedido. Gera valores como: noError(0); tooBig (1); noSuchName(2); badValue(3); readOnly(4) e genErr(5).
error-index Provê informação adicional quando um erro ocorre, desde que o status dele seja diferente de 0.
variablebindings Lista de nomes de variáveis e seus valores correspondentes.
Enterprise Tipo de trap de produção de objeto.
agent-addr Endereço do trap de produção de objeto.
generic-trap Tipos genéricos de valores trapsão: coldStart(0); warmStart(1); linkDown(2); linkUp(3); authentication-Failure(4); egpNeighborLoss(5) e enterprise-specific(6).
CONTINUA
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
44
CONCLUSÃO
CAMPO DESCRIÇÃO
specific-trap Código de trap específico.
time-stamp Tempo decorrido entre a última inicialização da entidade de rede com a produção de trap; contém os valores de sysUpTime.
Fonte: Barreto (2008, p. 15).
3.2.3 Transmissão de uma mensagem SNMPv1
De acordo com o RFC 1157 (CASE et al., 1990) e Stallings (1999), uma
mensagem SNMP é transmitida da seguinte forma:
Uma estrutura ASN.1 é utilizada para montar o PDU. O PDU é encaminhado
para um serviço de autenticação, juntamente com o endereço de origem e destino e
à comunidade da qual faz parte. Este serviço de autenticação se encarrega de gerar
uma transformação como criptografia ou inclusão de algum código de autenticação e
retorna o resultado. A entidade que será a transmissora do pacote constrói a
mensagem que é constituída por campos contendo a versão do protocolo, nome da
comunidade e o resultado da etapa anterior. Através da codificação ASN.1, um novo
objeto é representado e passado ao serviço de transporte.
3.2.4 Recepção de uma mensagem SNMPv1
Quanto à recepção de uma mensagem SNMP, segundo Barreto (2008), esta
ocorre da seguinte forma:
O receptor analisa a sintaxe da mensagem, procurando inconformidades.
Caso contenha, descarta a mensagem. Verifica o número da versão, e ,caso haja
algum erro de combinação, descarta a mensagem. A entidade receptora do
protocolo informa o nome de usuário (comunidade), a PDU da mensagem, e a
origem e o destino do endereço de transporte para que seja efetuada uma
autenticação. Essa autenticação é feita da seguinte forma: se houver falha de
autenticação, a mensagem é descartada, sinalizando o receptor SNMP, que, por sua
vez, gera um trap. Caso a autenticação seja validada com sucesso, um PDU
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
45
adequado à estrutura é gerado. O PDU é processado, e, caso o receptor SNMP
obtiver falha na combinação da PDU, a mesma é descartada.
3.2.5 Variable bindings do protocolo SNMPv1
Uma variable binding é um campo da mensagem PDU, responsável por
implementar múltiplas trocas entre objetos gerenciados. Com ela é possível enviar
em uma única mensagem, operações do tipo get, set, trap. Dessa forma, se a
aplicação gerente necessita receber os valores de todos os objetos escalares em um
grupo particular de um agente, pode enviar esta única mensagem, solicitando todos
os valores e obtendo uma resposta única, listando todos os valores (STALLINGS,
1999). Através dessa técnica, pode-se reduzir consideravelmente a carga de
comunicações de gerenciamento de rede.
3.2.6 GetRequest PDU do protocolo SNMPv1
Uma operação do tipo GetRequest PDU, provém de um gerente, solicitando
algo a um agente. Para que isso seja possível, a PDU deve conter os seguintes
campos (Figura 11):
a) tipo PDU: indica o tipo da PDU, no caso, um GetRequest;
b) request-id: É um valor único que identifique a requisição em questão. Deve
possibilitar a detecção de PDUs duplicadas;
c) variablebindings: Contém uma lista de objetos que serão requisitados
(STALLINGS,1999).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
46
Figura 11 - Formato da mensagem de Requisições do SNMP.
Fonte: Rocha (2011, texto digital).
No lado do agente, a resposta a um GetRequest será dada por um
GetResponse utilizando o mesmo request-id. Isso torna esta operação atômica, ou
seja, todos os valores de objetos solicitados são respondidos ou nenhum. Caso um
erro seja reportado, este retorna para o gerente através de um campo error-status,
contido no GetResponse PDU. A entidade de resposta também pode indexar um
objeto que contenha erro, usando o campo error-index e enviar a informação para a
estação de gerenciamento (Figura 12).
Figura 12 - Formato da mensagem de resposta.
Fonte: Rocha (2011, texto digital).
3.2.7 GetNextRequest PDU do protocolo SNMPv1
O GetNextRequest PDU utiliza os princípios do GetRequest, possuindo o
mesmo formato e troca de mensagem. A única diferença é que, enquanto um
GetRequest possui em sua variablebindings uma referência a um objeto, obtendo o
seu valor através do agente, no GetNextRequest este valor é dado pelo próximo
objeto existente na árvore de sua MIB. Com isso, é possível descobrir e percorrer
estruturas de uma MIB, na qual o tamanho das tabelas ou o formato é desconhecido
(ROCHA, 2011).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
47
3.2.8 SetRequest PDU do protocolo SNMPv1
Nas operações do tipo SetRequest PDU, sua principal função, se acordo com
Barreto (2008), é alterar valores de variáveis do objeto de gerenciamento, utilizando
assim, a mesma estrutura de um GetRequest ou GetNextRequest. O campo
variablebindings recebe a lista dos valores de objetos que serão alterados. No
agente, a resposta é feita utilizando o mesmo formato de mensagem de um
GetResponse, contendo, também, o mesmo request-id informado (ROCHA, 2011). O
SetRequest também pode ser usado para adicionar ou eliminar linhas, como afirma
Barreto (2008).
3.2.9 Trap PDU do protocolo SNMPv1
Informa um alerta de evento provindo de um agente para um gerente, de
forma que essa interação seja assíncrona, ou seja, não possui uma ordem
cronológica de acontecimento.
Algumas notificações mais comuns são:
a) cold e warm start: reinicialização de um agente recorrente ou não de alguma
falha;
b) link down ou up: Falha ou retorno de algum link identificado no campo
variablebindings (ROCHA, 2011);
c) authentication failure: Informa que houve falha na autenticação de alguma
mensagem.
Figura 13 - Formato de mensagem de Trap no SNMPv1.
Fonte: Rocha (2011).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
48
Figura 14 - Sequência do PDU SNMP.
Fonte: Barreto (2008, p. 17).
3.2.10 Limitações do protocolo SNMPv1
O SNMP, mesmo sendo o protocolo mais utilizado na gerência de redes,
possui algumas limitações, dentre outras, determinadas por Stallings (1999). São
elas:
a) desempenho limitado em grandes redes devido a performance da técnica de
polling, onde sempre é necessário enviar um pacote para obter de volta outro
pacote de informações.
b) mensagens críticas de trap podem não ser entregues e não ocorre uma
garantia da sua entrega por usar UDP/IP.
c) autenticação simples para o padrão básico SNMP.
d) não suporta comunicação entre gerentes. Não há como uma rede gerenciada,
aprender sobre os dispositivos de outra rede gerenciada.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
49
3.3 Protocolo SNMPv2
A segunda versão do Protocolo SNMP surgiu das limitações encontradas na
versão original, principalmente quanto à questão de segurança, que praticamente
não existia na versão 1. Porém, na prática, houve muita controvérsia por parte da
equipe de desenvolvimento, quanto a este quesito, fazendo com que o seu
mecanismo de segurança permanecesse o mesmo da primeira versão. Mesmo
assim, outras funcionalidades foram implantadas em sua arquitetura como, por
exemplo, novas operações que permitem a transferência de grandes blocos de
dados (bulk), maior padronização estrutural da PDU, melhor detalhamento dos
códigos de erros, possibilidade de interação entre entidades gerentes, suporte a
multiprotocolos na camada de transporte, entre outros (SPECIALSKI, [2002]).
A complexidade do protocolo aumentou consideravelmente e, por causa
disso, não houve uma ampla aceitação (SPECIALSKI, [2002]). Os documentos
RFC’s, que descrevem essa nova versão, vão do RFC 1901 a 1908 (CASE et al.,
1996), o que, de fato, mostra o tamanho da complexidade desta extensão do SNMP,
pois a sua versão original era contida em apenas um RFC, o 1157 (CASE et al.,
1990).
3.3.1 Arquitetura do protocolo SNMPv2
Enquanto que o SNMPv1 possui dois tipos de interação para acessar valores
de objetos gerenciados, o SNMPv2 pode utilizar três. São eles (Figura 15):
a) gerente-agente ou request-response: ocorre quando um gerente envia uma
requisição a um agente e este o responde (presente no SNMPv1);
b) gerente-gerente: uma entidade gerente solicita uma informação à outra
entidade gerente, que por sua vez retorna o pedido. Funciona como um
request-response, porém é efetuado entre gerentes (presente somente no
SNMPv2);
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
50
c) agente-gerente não confirmado ou trap: Esta interação ocorre quando um
agente envia uma mensagem não solicitada, de forma assíncrona, para um
gerente sem que este retorne nada (presente no SNMPv1).
Figura 15 - Arquitetura SNMPv2.
Fonte: SpeciaIski ([2002], p. 30).
No SNMPv2 foram incluídas duas novas PDU’s para operações do protocolo,
GetBulkRequest PDU e InformationRequest PDU. A primeira trata de recuperar
grandes blocos de dados, de forma eficiente, como linhas de tabelas, eliminando,
assim, uma das principais limitações da primeira versão. Já a segunda operação, é
utilizada na troca de mensagens entre gerentes SNMP, onde um gerente informa a
outro informações contidas na sua MIB, permitindo, assim, o gerenciamento
distribuído. Quando o destinatário recebe a mensagem gera um Response PDU
para o remetente, contendo a mesma informação recebida (Quadro 6).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
51
Quadro 6 - Tipos e descrições de PDUs
VALOR DO TIPO DE PDU
TIPO DE PDU DESCRIÇÃO
0 GetRequest Retorna o valor de uma instância da variável.
1 GetNextRequest Retorna o valor da variável sucessora lexográfica.
2 Response Retorna o resultado de uma operação.
3 SetRequest Atribui valor a uma variável.
4 Trap (obsoleto) Não usado. Era o antigo Trap do SNMPv1.
5 GetBulkRequest Permite a recuperação de grande quantidade de dados, normalmente o conteúdo de tabelas.
6 InformRequest Permite que um gerente envie informações para outro gerente.
7 Trapv2 Envia sinalizações de eventos.
8 Report Usado para comunicação interna do protocolo para relatar erros excepcionais ocorridos durante o processamento das requisições.
Fonte: Fassi ([2008?], texto digital).
3.3.2 Formato da mensagem do protocolo SNMPv2
O formato estrutural da PDU (Figura 16) também foi agrupado, tornando-se,
assim, mais padronizado. Inclusive as mensagens de trap, que no SNMPv1
continham uma PDU exclusiva, na versão 2 foi modificada para se enquadrar ao
restante das operações. Com isso houve um aumento de eficiência e performance
durante a troca de mensagens entre as entidades (SPECIALSKI, [2002]).
Figura 16 - Formato de mensagem PDU do SNMPv2.
Fonte: Barreto (2008, p.22).
Quanto aos códigos de erros, o SNMPv2 possibilitou novas informações,
permitindo que houvesse uma análise mais apurada dos problemas ocorridos nas
trocas de mensagens. O Quadro 7 informa uma lista de todos códigos de erros
possíveis, bem como sua descrição, conforme Fassi ([2008?]).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
52
Quadro 7 - Códigos de erros do SNMPv2
Fonte: Do autor, adaptado de Fassi ([2008?], texto digital).
De acordo com Spescialski ([2002]), o SNMPv2, através da RFC 1906 (CASE,
et al., 1996), pode atuar não somente através de transmissão sobre o UDP, como
também é possível especificar outros protocolos de transporte. Exemplos disso são
os protocolos OSI (RFC 1418), appletalk (RFC 1419) e o Internetwork Packet
Exchange (IPX) (RFC 1420).
Valor do Código de Erro Código de Erro Descrição
0 noError Nenhum erro ocorrido.
1 tooBig
O tamanho do PDU Response muito grande para ser
transmitido.
2 noSuchName O nome do objeto requisitado não foi encontrado.
3 badValue Valor incorreto.
4 readOnly
Impossibilidade de alterar o valor de uma variável pois a
mesma é somente leitura.
5 genErr Erro desconhecido.
6 noAccess Sem acesso ao objeto por motivos de segurança.
7 wrongType Tipo de dado do objeto é incorreto.
8 wrongLength Tamanho do objeto incorreto.
9 wrongEncoding O valor codificado é inconsistente com o tipo do objeto.
10 wrongValue Valor da variável inválido.
11 noCreation Variável especificada não existe ou não pode ser criada.
12 inconsistentValue
Condição temporária de inconsistência no valor do
objeto.
13 resourceUnavailable
Alocação de recursos indisponíveis no momento de
atribuir valor a uma variável.
14 commitFailed Falha na atribuição de valores de uma variável.
15 undoFailed
Impossibilita desfazer atribuições de variáveis após
ocorrência de uma falha.
16 authorizationError Erro de autorização.
17 notWritable Variável não pode ser modificada.
18 inconsistentName
o nome da variável é inconsistente e não pode ser criada
nestas circunstâncias.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
53
3.3.3 Limitações do protocolo SNMPv2
Apesar de possuir vantagens sobre a primeira versão do SNMP, o SNMPv2
apresenta algumas limitações mencionadas abaixo:
a) dificuldade de implementação devido a grande complexidade;
b) muitas variações do protocolo, como por exemplo, SNMPv2c, SNMPv2u e
SNMPv2* (as duas últimas foram destinadas a melhorias de segurança
porém na prática não são utilizadas);
c) baixa aceitação pela comunidade de gerência.
3.4 Protocolo SNMPv3
Como o SNMPv2 não conseguiu trazer as melhorias de segurança propostas,
houve a necessidade destas serem inclusas ao protocolo, fazendo com que
surgisse, em meados de 1999, a terceira versão do SNMP, o SNMPv3.
Basicamente, o SNMPv3 utiliza os mesmos mecanismos das troca de mensagem
PDU do SNMPv2, porém, sua estrutura geral é diferente das outras versões do
protocolo.
Dentre as melhorias implementadas, pode-se destacar a inclusão de um
modelo de segurança baseado em usuários, chamado User-based Security Model
(USM), e um modelo de controle de acesso baseado em visão, o View-based
Access Control Model (VACM). Também vale ressaltar a inclusão de módulos na
arquitetura que permitem a integração com as versões anteriores do protocolo
(SPECIALSKI, [2002]). Esta seção não irá se aprofundar nessa versão do protocolo,
limitando-se a abordar, de forma geral, o seu funcionamento. A Figura 17 mostra a
evolução do protocolo SNMP.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
54
Figura 17 - Evolução do SNMP.
Fonte: Helcio; Iguatemi (2009, texto digital).
3.4.1 Arquitetura do protocolo SNMPv3
Através da RFC 2571 (HARRINGTON et al., 1999), definiu-se o conceito de
entidades SNMP, onde cada entidade pode interagir com outra, atuando, assim,
como agente, gerente ou ambos. Tais entidades possuem módulos que se
comunicam entre si para dispor algum serviço, como afirma Fassi ([2008?]).
Uma entidade SNMPv3 (Figura 18) pode ser definida pelos componentes
abaixo (SPECIALSKI, [2002]):
Quadro 8 - Componentes do protocolo SNMPv3
COMPONENTE DESCRIÇÃO
Dispatcher gerenciador de tráfego, permitindo suporte concorrente a múltiplas versões de mensagens SNMP
subsistema de processamento de mensagens
prepara mensagens para transmissão e extrai dados de mensagens recebidas
subsistema de segurança provê mecanismos de autenticação e privacidade. Pode conter vários modelos de segurança
subsistema de controle de acesso checa as diretivas de acesso que uma aplicação terá direito
CONTINUA
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
55
CONCLUSÃO
COMPONENTE DESCRIÇÃO
gerador de comandos responsável por inicializar as PDUs SNMP (get, getNext, getBulk, setRequest) e processar as resposta provindas de uma requisição
respondedor de comandos
responsável por receber as PDUs SNMP, executar alguma operação definida pelo protocolo usando o controle de acesso e criar a mensagem de resposta que será encaminhada
originador de notificação
origina as mensagens de trap/inform baseado em eventos e condições monitoradas. Responsável também por determinar qual será o destino da mensagem, a versão do SNMP que será usada e quais serão os mecanismos de segurança utilizados
receptor de notificação responde as requisições de notificação referentes ao PDU inform
encaminhador de proxy Serve para repassar as mensagens SNMP. É de uso opcional.
Fonte: Specialski ([2002, p. 33]).
Figura 18 - Arquitetura de uma entidade SNMPv3
Fonte: Do autor.
3.4.2 Formato da mensagem do protocolo SNMPv3
O formato da mensagem SNMPv3 é mostrado na (Figura 19) e possui uma
estrutura baseada em módulos, sendo que a parte escura representa a área
utilizada pelo susbsistema de processamento de mensagem. Os campos utilizados
em uma mensagem SNMPv3 são descritos no Quadro abaixo, conforme Barreto
(2008) e Karing (2002):
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
56
Quadro 9 - Campos utilizados em uma mensagem SNMPv3
CAMPO DESCRIÇÃO
msgVersion versão SNMP utilizada na mensagem
msgID identificador único usado entre duas entidades SNMP e pelo processador de mensagens.
msgMaxSize tamanho máximo das mensagens. Medido em octetos.
msgFlags
representa um octeto contendo três flags nos três últimos bits significativos. Tais flags são: reportableFlag, privFlag, authFlag. A primeira é utilizada somente quando uma porção PDU de uma mensagem não pode ser decodificada. Já a privFlag e authFlag são elementos de segurança usados para o processo de criptografia e autenticação, respectivamente
msgSecurityModel
indica qual modelo de segurança foi usado pelo remetente ao preparar e mensagem e, com isso, qual modelo de segurança deve ser usado pelo destinatário para processar a mensagem. Alguns valores aceitos incluem: “1” para SNMPv1, “2” para SNMPv2c e “3” para USM.
msgSecurityParameters representa um octeto que contém informações geradas pelo subsistema de segurança da entidade SNMP que enviou a mensagem e processado pelo subsistema de segurança da entidade receptora.
contextEngineID identificador único da entidade SNMP. É representado por um octeto.
contextName octeto que identifica de forma única um contexto a um motor de contexto associado.
PDU SNMPv2 a PDU utilizada segue os mesmos padrões da versão 2 do protocolo.
Fonte: Do autor, adaptado de Barreto (2008) e Karing (2002).
Figura 19 - Formato de mensagem SNMPv3
Fonte: Karing (2002, p.51).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
57
3.4.3 Segurança e controle de acesso do protocolo SNMPv3
Segundo Walsh (2008), no modelo SNMPv3 é definida a autenticação de
usuários, através da qual cada um possui seu nome de usuário e senha. Tanto as
entidades gerentes como os agentes possuem as suas chaves de segurança e têm
seus usuários válidos, juntamente com uma chave secreta única, definida para cada
usuário. Quando uma entidade envia uma mensagem SNMPv3, a chave secreta de
seu utilizador é usada para criar um hash da mensagem, e este valor é inserido na
mesma. Caso a entidade receptora consiga recriar esse hash através de sua chave
secreta compartilhada, então a mensagem é autenticada e provém de um usuário
válido.
As mensagens de traps também são enviadas a partir de usuários válidos e
as entidades agentes podem ser configuradas para exercer um controle mais
detalhado sobre a transmissão destes traps para os gerentes.
Esse tipo de modelo é conhecido como modelo de segurança baseado em
usuários (USM), e garante que as mensagens enviadas de forma atemporal não
sejam atrasadas ou reproduzidas por quem não pertence ao grupo autenticado.
As entidades SNMP, que atuam como agentes, podem ser configuradas para
controlar quem pode acessar e o que pode ser acessado dentre os objetos
pertencentes à MIB por elas gerenciada (WALSH, 2008). Nas versões anteriores do
SNMP, esse quesito era gerenciado através do conceito de nomes de comunidade.
Já no SNMPv3, segundo Specialski ([2002], p. 35), “o controle de acesso tornou-se
muito mais seguro e flexível pela introdução do modelo de controle de acesso
baseado em visão (VACM – View-based Access Control Model)”. Por exemplo, um
usuário = Supervisor de Operações pode acessar os dados críticos de leitura e
escrita de controle, enquanto o usuário = Manutenção de planta pode acessar
somente os dados específicos com permissão de apenas leitura (WALSH, 2008).
De acordo com Specialski ([2002]), o SNMPv3 é projetado para prover
segurança contra as seguintes ameaças:
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
58
a) modificação da informação: uma entidade poderia alterar uma mensagem em
trânsito que tivesse sido gerada por alguma entidade autorizada;
b) masquerade: uma entidade possuir o privilégio de entidade autorizada,
mesmo não sendo autorizada;
c) modificação da cadeia de mensagem: uma mensagem SNMP está sujeita a
ser reordenada, atrasada ou repetida pelo fato de o protocolo ter sido
projetado a operar sobre um protocolo não orientado à conexão (UDP);
d) descoberta: através da observação de troca de mensagens entre gerentes e
agentes, uma entidade poderia descobrir valores de objetos gerenciados e
assim, alterá-los.
Mesmo assim, ainda existem limitações quanto à segurança como nas
seguintes ameaças:
a) negação de Serviço (Denial of Service – DoS): ocorre quanto um atacante
consegue impossibilitar o serviço de troca de mensagens entre gerente e
agente;
b) análise de tráfego: observação do comportamento de tráfego entre gerente e
agente.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
59
4 FERRAMENTAS DE GERENCIAMENTO E MONITORAMENTO DE
REDES
A fim de atingir um maior número de elementos gerenciados, torna-se viável
fazer uso de uma ferramenta capaz de auxiliar, de forma eficaz, toda a parte de
gerenciamento e monitoramento de redes. Essa ferramenta deve, no mínimo, ser
capaz de prover uma interface única ao usuário e demonstrar informações em tempo
real sobre os objetos gerenciados, de forma clara, para que seja efetuada uma
análise correta do ambiente gerenciado. A partir disso, esse Capítulo tem como
objetivo analisar alguns sistemas baseados em software livre utilizados para efetuar
o gerenciamento e monitoramento de redes de computadores.
Na seção 4.1 e 4.2 serão introduzidas algumas das principais soluções em
software para geração de gráficos de estado, o MRTG e o RRDTOOL,
respectivamente, sendo que os mesmos mostram-se como precursores das atuais
soluções de sistemas para gerenciamento. Já na seção 4.3 será abordada a
ferramenta NTOP, um analisador e monitorador de tráfego de rede. As seções 4.4,
4.5, 4.6, 4.7, 4.8 e 4.9 informam um breve resumo e características principais das
ferramentas Nagios, Cacti, OpenNMS, Pandora FMS, Zabbix e Zenoss, nessa
ordem. Na seção 4.10 será apresentado um quadro comparativo entre as
ferramentas estudadas, e na seção 4.11 será mostrada a análise dos resultados
comparativos referente aos tipos de software propostos.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
60
4.1 MRTG
O Multi Router Traffic Grapher (MRTG) é um software escrito em perl e
funciona em Unix/Linux, bem como nos sistemas Windows e até mesmo Netware.
Além disso, é software livre, licenciado sob a GNU General Public License (GPL)
(MRTG, 2013).
O desenvolvimento dessa ferramenta foi originalmente iniciado em 1994 e sua
proposta principal é monitorar o tráfego de rede, baseado em páginas HyperText
Markup Language (HTML), que mostram, através de imagens gráficas, o estado em
tempo real deste tráfego.
Essa ferramenta utiliza agentes SNMP ou scripts personalizados para coletar
as informações e expor em forma de gráficos (Figura 20), desde que o software ou
hardware monitorado tenham suporte a isso (MRTG, 2013).
Figura 20 - Imagem de um gráfico gerado pelo MRTG.
Fonte: MRTG (2013).
4.2 RRDTool
O Round Robin Database (RRDTool) originou-se a partir do MRTG e utiliza o
algoritmo de Round Robin para gerar uma base de dados em séries temporais com
valores numéricos, contendo informações sobre estado de diversos elementos como
temperatura, carga de Central Processing Unit (CPU), uso de memória e disco,
estado da rede, entre outros. É possível coletar dados vindos de agentes SNMP e
gerar diversos tipos de gráficos (Figura 21) para monitorar a informação (RRDTOOL,
2013).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
61
Figura 21 - Imagem de um gráfico gerado pelo RRDTool
Fonte: RRDTool (2013).
4.3 NTOP
A principal característica do NTOP é poder monitorar a utilização dos recursos
de rede de computadores como tráfego e consumo de banda, por exemplo (NTOP,
2013). As informações são mostradas de forma clara através de uma página web
(Figura 22), onde é possível verificar todas as conexões estabelecidas dentro da
rede interna, identificando o host através de seu endereço IP e outros protocolos
envolvidos na conexão.
Com essa ferramenta é possível avaliar de forma bem ampla como o estado
da rede está se comportando em determinado momento, possibilitando ao
administrador de redes observar anomalias e solucionar eventuais problemas em
sua rede.
O NTOP também possui suporte a múltiplas plataformas como UNIX, LINUX e
Windows. Como foi projetado para ser uma aplicação ao nível de kernel, ele visa
utilizar poucos recursos de processador e memória. Por ser uma ferramenta simples
e com uma análise bem completa do estado da rede, tem-se como um software
bastante útil para redes locais, nesse quesito.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
62
Figura 22 - Informações de host no NTop
Fonte: NTOP (2013).
4.4 Nagios
O Nagios é um dos mais conhecidos sistemas de gerenciamento de rede, de
código aberto e licenciado pelo sistema GPL. Com ele é possível gerenciar tanto
equipamentos de hardware (switch, roteadores, servidores, estações de trabalho,
etc), como serviços funcionais a nível de software em uma rede. Também possui
mecanismos de alerta quanto à descoberta de problemas na rede e/ou resolução
dos mesmos.
Esse software foi originalmente desenvolvido por Ethan Galstad, em 1999,
sob o nome de NetSaint, e, em 2001, teve seu nome alterado e registrado para
Nagios (Nagios Ain't Gonna Insist On Sainthood), por ter sido acusado de utilizar o
mesmo nome, na época, de uma outra marca. Em 2007, Ethan fundou a Nagios
Enterprises, que é atualmente a patrocinadora oficial do projeto e possui, além da
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
63
versão comunitária, uma versão comercial que conta com um suporte mais
específico e algumas características inicialmente não disponíveis na versão
comunitária (NAGIOS, 2013).
Em consonância com o site oficial do projeto (NAGIOS, 2013) serão listadas
algumas características desta ferramenta, tais como:
a) monitoramento de serviços de rede, tais como: SMTP, POP3, HTTP, ICMP,
SMNP, entre outros;
b) monitoramento da infraestrutura de hardware (uso de memória, carga da
CPU, espaço em discos, log de sistema, etc);
c) detecção de problemas antes que estes ocorram;
d) alertas instantâneos ao surgimento de problemas;
e) compartilhamento de informações de disponibilidade entre as partes
interessadas;
f) detecção de falhas de segurança;
g) informações pertinentes para expansão e/ou atualização da TI;
h) redução de perdas de tempo de inatividade e de negócios.
Com o Nagios é possível, ainda, desenvolver plug-ins em diferentes
linguagens para determinadas tarefas. Sua comunidade já disponibilizou uma série
deles para auxiliar no gerenciamento de redes.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
64
Figura 23 - Tela do software Nagios
Fonte: Nagios (2013).
Algumas desvantagens desta ferramenta serão listadas a seguir:
a) possui uma versão paga com mais recursos que a gratuita;
b) configuração pouco intuitiva;
c) não há suporte nativo para plataforma Windows sendo necessário utilizar plug-
ins de terceiros;
d) interface Web sem recursos para configurações do próprio sistema, sendo
necessário alterar arquivos de configuração;
e) curva de aprendizado elevada por causa de sua complexidade;
f) algumas informações são apresentadas de forma confusa, acarretando em
dificuldades para identificar determinados problemas;
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
65
4.5 Cacti
O Cacti é um software baseado em RRDTool e possui uma interface Web,
juntamente com uma base de dados em MySql, que armazena as informações para
posteriormente criar gráficos para melhor visualização dos usuários.
É permitido também criar scripts para obter informações reais sobre o estado
de algum item da rede como, por exemplo, o tempo de ping para um host, que são
armazenados e mantidos em intervalos de tempo (CACTI, 2013).
Basicamente a função do Cacti é gerar gráficos sobre o estado da rede para
análise e acompanhamento da mesma, não possuindo recursos nativos para
monitoramento proativo ou distribuído.
Figura 24 - Tela de gráficos do software Cacti
Fonte: Cacti (2013).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
66
4.6 OpenNMS
O OpenNMS é um conceituado software livre de gerenciamento de redes,
sendo desenvolvido desde 2002 e possui algumas características importantes
citadas abaixo (OPENNMS, 2013):
a) permite descobertas automáticas, manuais ou ambas de dispositivos na rede;
b) serve como repositório central para o fluxo da rede;
c) possibilidade de gerar alertas e avisos sobre determinados eventos;
d) possui uma boa manutenção de acordos de serviços (SLA);
e) permite geração de relatórios detalhados sobre disponibilidade dos serviços,
entre outros;
f) possibilidade de integração com outros sistemas;
g) geração de gráficos para análise e acompanhamento.
Através de uma interface Web (Figura 25), é possível monitorar diversos
equipamentos de rede, porém, sua documentação é mínima, fato este que torna
difícil entender e utilizar todos os seus recursos.
Figura 25 - Interface do OpenNMS
Fonte: OpenNMS (2013).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
67
4.7 Pandora FMS
Pandora FMS é uma aplicação para o gerenciamento de redes, desenvolvida
desde 2005 pela empresa Ártica ST, e apresenta uma série de recursos, como
monitoramento de diversos dispositivos de rede, interface web amigável, alerta de
eventos por e-mail ou SMS, suporte a SNMP nativo, entre outros. Este software
possui duas versões, uma comercial com amplos recursos e suporte especializado,
e outra gratuita, sob licença GPL2, possuindo uma série de limitações quanto a
recursos nativos (PANDORA, 2013).
Figura 26 - Interface do Pandora FMS
Fonte: Pandora (2013).
4.8 Zabbix
Desenvolvido desde 2001, inicialmente por Alexei Vladishev e atualmente
pela Zabbix SIA, o Zabbix caracteriza-se por ser um software de monitoramento e
gerenciamento de redes completo, sendo que o mesmo possui apenas uma versão,
sob licença GPL2, o que torna todo seu desenvolvimento focado em software livre.
Graças a isso, o Zabbix é constantemente revisado e atualizado pela equipe de
desenvolvimento e sua comunidade.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
68
O Zabbix suporta diversos sistemas operacionais (Unix, Windows, etc), têm
nativamente suporte ao protocolo SNMP, uma interface web centralizada, utiliza
banco de dados (MySql, PostgreSQL, Oracle entre outros) e é capaz de gerar
gráficos para diversas situações em tempo real. Em sua interface web é possível
fazer o acompanhamento do desempenho completo da rede e dos dispositivos
gerenciados, o status dos servidores, roteadores e conexões, afirmam Rocha e
Serradourada (2008).
Abaixo serão listadas algumas características do Zabbix segundo
especificações no site oficial (ZABBIX, 2013):
a) o Zabbix é liberado sob a licença GPL2, portanto, é livre para uso comercial e
não comercial. Com isso, o melhor do Zabbix é disponível a todos;
b) possibilidade de monitorar servidores, dispositivos de rede e aplicações,
reunindo estatísticas precisas e dados de desempenho;
c) recurso de agentes Zabbix, SNMP ou outro tipo, para monitorar desempenho
de CPU, memória, espaço em disco, processos, entre outros. Estes agentes
são disponíveis em plataformas Linux, UNIX e Windows;
d) capacidade de personalização, integração e coleta de dados em qualquer
ambiente, através de criação de scripts em shell, Perl, Python, ou qualquer
outra linguagem;
e) suporte a múltiplos banco de dados como MySql, PostgreSQL, Oracle, etc;
f) monitoramento distribuído através do uso de proxies ou nodes;
g) alta disponibilidade através de mecanismos de controle de buffer de dados
eficiente;
h) suporte nativo a IPv4 e IPv6;
i) possibilidade de configurar mensagens via e-mail, SMS ou Jabber (protocolo
XMPP) para cada evento;
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
69
j) permite executar ações remotamente para corrigir algum problema, como
reiniciar um serviço crítico, por exemplo,
k) interface Web simples e intuitiva (Figura 27).
Figura 27 - Interface do Zabbix
Fonte: Zabbix (2013).
4.9 Zenoss
O Zenoss existe desde 2005, com o objetivo de garantir a larga escala dos
serviços de TI em ambientes operacionais (ZENOSS, 2013). Esse software age
como uma ferramenta de análise de impacto e gestão de eventos, bem como
otimização e gestão de recursos de toda infraestrutura de TI, tanto física, como
virtual, e em nuvem (ZENOSS, 2013). Sua arquitetura é modular, o que agrega
maiores possibilidades de atribuir novas funcionalidades. De acordo com o site
oficial, a filosofia deste software baseia-se, entre outros conceitos:
a) permitir uma plataforma única para monitoramento, análises profundas e
correções automáticas de serviços de TI;
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
70
b) simplicidade através de modularidade onde existe uma customização rápida e
perda de complexidade, sempre que possível;
c) maximizar a inteligência com rotinas automatizadas que permitem troca de
informação em tempo real;
d) escalabilidade através de distribuição horizontal;
e) colaborativo através de código aberto;
f) alinhamento da área de TI com o negócio.
Apesar de ser um software distribuído sob licença GPL2, o Zenoss também
possui a sua versão paga, mediante a qual pode-se contar com mais recursos e
suporte especializado. Também é possível utilizar um recurso chamado Zenpack,
que é útil para incorporar extensões ao Zenoss, permitindo, assim, a criação de
módulos customizados. Quanto à sua interface, esta é bastante intuitiva e
organizada, como mostra a figura abaixo.
Figura 28 - Interface do Zenoss
Fonte: Zenoss (2013).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
71
4.10 Comparativo entre as ferramentas de gerenciamento
O Quadro 10 mostra uma comparação entre os softwares de gerenciamento
livres apresentados até então, baseado em suas respectivas documentações
oficiais, juntamente com Rocha e Serradourada (2008).
Quadro 10 - Comparativo entre softwares de Gerenciamento
Fonte: Do autor, baseado em Cacti (2013), Nagios (2013), Ntop (2013), OpenNMS (2013), Pandora
FMS (2013), Zabbix (2013), Zenoss (2013) e Rocha e Serradourada (2008).
4.11 Análise dos resultados obtidos
De acordo com o Quadro 10 é possível observar que dois software se
destacam quanto ao preenchimento dos requisitos: o OpenNMS e o Zabbix. Os
outros possuem limitações, ou por não prover a funcionalidade, ou por estar
disponível apenas na versão paga. O diferencial destes dois software é que o
desenvolvimento de ambos é totalmente baseado na versão gratuita, concentrando
todos os esforços dos desenvolvedores e da comunidade em melhorá-los para
Cacti Nagios* Ntop OpenNMS PandoraFMS* Zabbix Zenoss*
VERSÃO 0.8.8b 4.0.1 1.0 1.10 5.0 2.0.8 4
Monitoramento distribuído Sim Sim Não Sim Sim Sim Sim
Software livre (Licença GPL ou GPL2) Sim Sim Sim Sim Sim Sim Sim
Suporte SNMP nativo Sim Não Não Sim Sim Sim Não
Suporte a agentes nativos Não Não Não Sim Sim Sim Não
Agentes em multiplataformas Não Sim Não Sim Sim Sim Sim
Suporte a agentes SNMP Sim Sim Não Sim Sim Sim Sim
Interface Web customizável Sim Sim Sim Sim Sim Sim Sim
Suporte a múltiplos banco de dados Não Não Não Sim Sim Sim Sim
Versão em português Não Não Não Não Não Sim Não
Documentação em português Não Não Não Não Não Sim Não
Permite extensões (plugins) Sim Sim Sim Sim Sim Sim Sim
Possui inventário nativo Não Não Não Sim Não Sim Sim
Controle de acesso e permissões Sim Sim Não Sim Sim Sim Sim
Descobrimento automático de hosts Sim Sim Sim Sim Sim Sim Sim
Mensagens de alerta nativas (E-mail, SMS, etc) Não Sim Não Sim Sim Sim Sim
Geração de mapas de rede nativo Não Sim Não Sim Sim Sim Sim
Geração de gráficos online Sim Sim Sim Sim Sim Sim Sim
Gerenciamento centralizado e/ou distribuído Sim Sim Sim Sim Sim Sim Sim
Executa ações remotamente Não Sim Não Sim Sim Sim Sim
Configuração simples Não Não Sim Não Não Sim Sim
Autenticação LDAP nativa Sim Não Não Sim Não Sim Não
Monitoramento de aplicações WEB Sim SIm Não Sim Sim Sim Sim
Suporte a agentes JMX Não SIm Não Sim Sim Sim Sim
Suporte a descobertas de baixo nivel Não Não Não Sim Não Sim Sim
Auditoria Não Não Não Não Sim Sim Sim
Versão mobile Sim Sim Sim Sim Sim Sim Sim
*Algumas funcionalidades estão disponíveis apenas na versão paga.
SOFTWARE
CARACTERÍSTICAS
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
72
disponibilizá-los livremente. Já os outros softwares, ou não possuem algumas
funcionalidades importantes, ou estas só estão disponíveis em sua versão paga.
O Zabbix, por ser simples de configurar e visualmente bastante atraente, além
de possuir muitos recursos, uma comunidade bastante ativa, inclusive
disponibilizando tradução e documentação para o português, mostrou-se mais
adequado aos critérios da empresa analisada, justificando assim, sua escolha como
ferramenta de gerenciamento de redes.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
73
5 PROPOSTA
O presente Capítulo abordará um estudo de caso na empresa Costaneira,
apresentando na seção 5.1 uma breve caracterização do ramo de negócio, bem
como a descrição da infraestrutura de TI e uma análise do ambiente a ser
monitorado na empresa. As seções 5.2, 5.3 e 5.4 serão destinadas a apresentar o
modelo de implantação, componentes e fluxo de operação do Zabbix,
respectivamente. Já a seção 5.5 descreve o cenário proposto para a implantação do
sistema. Na seção 5.6 será introduzido o uso dos templates personalizados para
uma melhor organização e manutenção dos itens coletados. A seção 5.7 trata sobre
a utilização das regras de auto busca do Zabbix, enquanto que as seções 5.8 e 5.9
abordam sobre o monitoramento de aplicações Java e o banco de dados
PostgreSQL. O monitoramento proativo será o tema da seção 5.10 e mostra como
executar ações automáticas para mitigar impactos causados por determinados
incidentes.
5.1 Caracterização da empresa
A Costaneira surgiu em 1º de agosto de 1949, como um pequeno negócio de
material de construção. Hoje é uma empresa especializada em materiais de
acabamento e na linha de móveis planejados. Com nove lojas localizadas em pontos
estratégicos, dispondo de show rooms modernos e atualizados, além de uma série
de serviços exclusivos para seus clientes. A empresa possui um dos maiores
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
74
estoques de cerâmicas do Rio Grande do Sul, centralizado na cidade de Lajeado,
juntamente com a administração da empresa (COSTANEIRA, 2013).
5.1.1 Infraestrutura de TI
A infraestrutura de TI da Empresa Costaneira possui duas variantes: o prédio
da administração e o centro de distribuição central, ambos localizados em Lajeado, e
as suas filiais, uma também situada nessa cidade, e outras oito localizadas em
diferentes pontos do Rio Grande do Sul. Abaixo será descrito como funciona cada
um destes pontos.
5.1.2 Administração Central
É o ponto-chave de toda a rede da Costaneira. É onde se encontra o servidor
que armazena o principal banco de dados utilizado pelo sistema de gestão da
empresa, o sistema de replicação responsável por distribuir as informações do
banco de dados para os servidores das filiais, o serviço de Virtual Private Network
(VPN), para conectar as filiais através de um canal seguro de comunicação, entre
outros serviços essenciais para o funcionamento do negócio como um todo.
Para que seja possível se comunicar com as filiais de modo que o link de
Internet esteja disponível na maior parte do tempo, a empresa adotou a estratégia
de contratar três links de redundância, que seguem descritos abaixo (Quadro 11).
Quadro 11 - Informações dos links na administração da Costaneira
LINK RÁDIO
Dados de Vazão 117 Mb (suportada pelo equipamento)
Intensidade do Sinal -63 dBm
Noise Floor -88 dBm (Ruído)
Transmit CCQ 96%
TX/RX Rate 117 Mbps / 117 Mbps
Distância 0,1 milhas (0,2 km)
Utilidade Em situações normais, este link é usado de forma exclusiva para conexões de VPN com as filiais.
CONTINUA
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
75
CONCLUSÃO
LINK FIBRA ÓPTICA
Distância até 20 km
Perda até 0,36 dB por Km
Download 6,68 Mbps
Upload 0,82 Mbps
Utilidade Salvo exceções, este link é apenas utilizado para navegação e outros serviços que acessam a Internet.
LINK MODEM 3G
Download 5Mbps
Upload 1Mbps
Utilidade É utilizado somente se ambos os links principais estiverem inativos e apenas para serviços cruciais como replicação do banco de dados ou emissão de notas.
Fonte: Do autor.
Conforme a Figura 29, um roteador wireless é utilizado para receber os três
links, sendo que uma parte do sinal será destinada à comunicação com a filial
localizada a cinquenta metros de distância do prédio da administração e a outra
parte será usada para a comunicação interna e o depósito central. O servidor central
é responsável por organizar as rotas, estabelecer os túneis VPN e definir as regras
de firewall utilizadas na empresa. Também possui algumas máquinas virtuais
utilizadas para serviços, como o acesso dos usuários através dos terminais thin
client.
Outro servidor de semelhante porte é utilizado como backup e possui uma
cópia de todos os serviços e configurações usadas no servidor principal, mantendo
uma redundância em caso de falhas. Para interligar os demais equipamentos na
rede, tais como computadores, impressoras, thin client, notebooks, usa-se um
switch.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
76
Figura 29 - Cenário da administração central da Costaneira
Fonte: Do autor.
5.1.3 Centro de Distribuição
A interligação da administração central com o prédio do centro de distribuição
é feita através de fibra óptica, utilizando um conversor de mídia conectado em cada
extremidade, através de um switch. No depósito, os ativos conectados ao switch vão
desde um servidor simples para impressão e backup, até terminais thin client,
impressora de rede e um computador.
5.1.4 Filiais
O esquema utilizado nas filiais é o mesmo relatado no Quadro 12. Todas
possuem dois links de Internet de redundância: um ADSL e outro via modem 3G.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
77
Quadro 12 - Informações dos links nas filiais da Costaneira
LINK ADSL Dado Downstream Upstream SNR Margin 8.5 dB 9.0 dB Line Attenuation 10.7 db 4.6 dB Data Rate 17661 kbps 1127 kbps ES 32 10 SES 0 0 UAS 63 63 Utilidade Link principal da filial
LINK MODEM 3G Download 5Mbps Upload 1Mbps Utilidade É utilizado como link de backup.
Fonte: Do autor.
Um roteador wireless semelhante ao encontrado na administração recebe o
sinal vindo do modem ADSL, disponibilizado pela operadora, e repassa para o
servidor da filial. Este possui as regras de firewall, rotas, VPN, cópia do banco de
dados, máquinas virtuais de aplicações, entre outros serviços utilizados na filial. Um
switch é usado para disponibilizar o acesso à rede para os demais ativos, como
impressoras, notebooks, computadores, relógio-ponto, thin client, etc.
Figura 30 - Cenário das filiais da Costaneira
Fonte: Do autor.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
78
5.1.5 Análise do ambiente
Para buscar uma solução que resolvesse o problema do gerenciamento de
ativos de rede na empresa Costaneira, demonstrando, assim, o estado da arte
nessa questão, foi estabelecido um modelo de cenário que envolvesse os principais
elementos a serem gerenciados tanto na administração central, quanto nas filiais
geograficamente distribuídas. Inicialmente houve a necessidade de identificar quais
seriam os equipamentos que representariam mais perigo ao negócio em caso de
falhas ou indisponibilidade, sendo eles taxados como prioritários quanto ao seu
gerenciamento. O Quadro 13 aborda os elementos gerenciados e seu grau de risco
quanto a ameaças:
Quadro 13 - Equipamentos gerenciados x risco ao negócio
EQUIPAMENTO RISCO
Servidores Alto
Máquinas Virtuais Médio
Thin Client Baixo
Impressora de Rede Médio
Roteador Wireless Alto
Switch Alto
Microcomputador do caixa Médio
Notebook de projetos Médio
Fonte: do autor.
A partir dessa análise buscou-se identificar quais equipamentos seriam
passíveis de monitoramento, utilizando agentes do Zabbix, e quais teriam suporte ao
protocolo SNMP (Quadro 14). A grande dificuldade encontrada nessa etapa foi
conseguir monitorar os roteadores, pois na empresa é utilizado o mesmo modelo de
equipamento em todas as filiais e na administração central. Esse ativo é um TP-
LINK MR 3420 v1.2 e não dispõe de suporte SNMP em seu firmware original. Para
tanto, foi necessário instalar outro firmware, o Openwrt v12.09, que é compatível
com esse aparelho, possibilitando, assim, a instalação de um agente Zabbix no
mesmo.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
79
Quadro 14 - Equipamentos a serem monitorados
Fonte: Do autor.
5.2 Modelo de implantação do Zabbix
O Zabbix dispõe de três tipos de abordagens quanto à sua implantação
(Figura 31):
a) padrão: um servidor Zabbix responsável por executar todas as funções de
monitoramento através de seus agentes;
b) monitoramento baseado em proxy: um servidor Zabbix em um ponto central
da rede e um ou mais proxies distribuídos entre as unidades de negócio;
c) monitoramento distribuído: um servidor Zabbix por unidade de negócio
(node), tornando a configuração complexa e independente, exigindo uma
maior manutenção.
Equipamento
Arquitetura
(bits) CPU Disco Fornecedor
Interfaces
de Rede Memória Modelo
Sistema
Operacional
Tipo de
Monitoramento
Máquina Virtual 64 100 Gb Oracle 1 - eth0 10 Gb
VirtualBox
4.2
Linux Debian
6.0.7
Agente Zabbix v.
2.0.8
Microcomputador 32
80 Gb
SATA Dell 1 - eth0 2 Gb Optiplex
Windows XP
Professional
Agente Zabbix v.
2.0.8
Notebook 64 Intel i7
320 Gb
SATA Dell
2 - eth0,
wlan0 4 Gb Vostro
Windows 7
Professional
Agente Zabbix v.
2.0.8
Servidor Backup 64
Quad-Core
AMD
Opteron
2.8Ghz
600 Gb
SCSI Dell
4 - eth0,
eth1, eth2,
tun0 16 Gb PowerEdge
Linux Debian
6.0.7
Servidor Zabbix
v. 2.0.8 +
agente Zabbix
v. 2.0.8
Servidor Filial 64
Quad-Core
AMD
Opteron
2.1Ghz
150 Gb
SCSI Dell
2 - eth0,
tun0 8 Gb PowerEdge
Linux Debian
6.0.7
Proxy Zabbix v.
2.0.8 + agente
Zabbix v. 2.0.8
Servidor Produção 64
Intel Xeon
2.4 Ghz
600 Gb
SCSI Dell
4 - eth0,
eth1, eth2,
tun0 32 Gb PowerEdge
Linux Debian
6.0.7
Proxy Zabbix v.
2.0.8 + agente
Zabbix v. 2.0.8
Switch - - - D-link
48 portas
10/100 + 4
portas
10/100/100
0 - DES-1252 - SNMP v2c
Thin Client 32 1 - eth0 128 Mb
Linux Debian
6.0.7
Agente Zabbix v.
2.0.8
Roteador Wireless - - - TP-link
4 Lan, 1
Wan e 1
Wlan MR-3420 Openwrt 12.09
Agente Zabbix v.
2.0.8
Impressora de Rede - - - Brother 1 - eth0 -
MFC-
8890DW - SNMP v2c
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
80
Figura 31 - Tipos de abordagens do Zabbix
Fonte: Alves (2013).
Pelo fato de necessitar a instalação de um servidor Zabbix em cada unidade
de negócio a ser monitorada, mantendo também um banco de dados dedicado em
cada uma delas, consumindo mais recursos de rede e hardware, o modelo baseado
em node não se mostrou viável para ser implantado na empresa. Dessa forma, a
escolha por utilizar o modelo de monitoramento baseado em proxy deu-se em razão
de o mesmo ser de fácil implantação e manutenção, necessitando de poucos
recursos computacionais, nos quais as informações referentes aos hosts
monitorados são coletadas pelo proxy que armazena em buffer esses dados, e,
através de uma única conexão TCP, envia todas as informações armazenadas de
um certo período ao servidor Zabbix. O Quadro 15 mostra um pequeno comparativo
entre as duas abordagens citadas acima, quanto às suas características mais
relevantes.
Quadro 15 - Comparativo entre monitoramento em node e monitoramento baseado
em proxy do Zabbix
Característica Node Proxy
Utiliza poucos recursos computacionais Não Sim
Possui interface gráfica Sim Não
Trabalha de forma independente Sim Sim
Fácil manutenção Não Sim
Criação automática do BD Não Sim
Administração local Sim Não
Configuração centralizada Sim Sim
Permite enviar alertas Sim Não
Fonte: Zabbix (2013).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
81
Quanto à utilização de proxies, vale ressaltar, também, que o Zabbix possui
dois modos de operação: ativo e passivo. Originalmente, o Zabbix proxy só operava
no modo ativo, no qual toda a conexão com o servidor partia do proxy. Isso resolvia
o problema quando o ambiente a ser monitorado possuía um firewall restritivo que
impossibilitava uma conexão externa do servidor Zabbix ao proxy. Assim, um proxy
era instalado em algum equipamento na rede interna a ser monitorada, ficando
encarregado de coletar as informações dos agentes locais e enviar em uma única
conexão TCP todos os dados para o servidor Zabbix remoto.
Após a versão 1.8.3 do Zabbix foi implementada a funcionalidade do proxy
para também poder agir de modo passivo. Desse modo, o servidor Zabbix conecta
ao proxy, enviando as configurações de coleta. Depois de certo período, o servidor
conecta novamente para recuperar as informações coletadas do proxy. O Zabbix
proxy, por sua vez, atua como se fosse um servidor Zabbix para o agente,
permitindo que o mesmo interaja tanto no modo passivo como no modo ativo. A
Figura 32 mostra um diagrama de funcionamento do Zabbix Server com os modos
de operação do Zabbix Proxy e os agentes coletores.
Figura 32 - Diagrama de operação do Zabbix utilizando proxies
Fonte: Do autor, adaptado de Alves (2013).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
82
5.3 Componentes do Zabbix
Os componentes do Zabbix Server apresentam-se conforme a Figura 33. As
informações relacionadas às configurações de hosts monitorados são sincronizadas
com o banco de dados pelo configuration syncer, que atualiza o Configuration Cache
com as configurações de coletas e envia ao proxy ou agente em determinado
período estes valores. Assim, o Zabbix proxy/agente interpreta os valores que tem
que coletar e recupera essas informações dos hosts monitorados, encaminhando-as
para o servidor Zabbix. Quando o Zabbix server recebe os valores, estes ficam
armazenadas em um History & Trends cache. De tempos em tempos o history
syncer faz a sincronização das informações com o banco de dados do Zabbix. Outro
componente importante é o housekeeper, que é um processo executado
periodicamente e responsável por remover informações desatualizadas e excluídas
por usuários do banco de dados do Zabbix. Quando algum evento gera um incidente
ou o banco de dados apresenta algum problema como indisponibilidade, o mesmo é
informado ao usuário pelo Zabbix, através da interface web, pelo componente
alerter.
Figura 33 - Componentes do Zabbix Server
Fonte: Alves (2013).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
83
5.4 Fluxo de operação do Zabbix
O Zabbix utiliza um fluxo de operação conforme a Figura 34 e será abordado
abaixo:
a) host: qualquer dispositivo que possua um endereço IP. Ex. servidor;
b) item: fonte de coleta no host monitorado. Ex. espaço em disco;
c) trigger (gatilho): expressão lógica utilizada para representar o estado de um
sistema. Ex. {host:icmpping.count(1800,0)}>5 – host está inacessível;
d) evento: quando uma trigger ou uma ação são disparadas, é gerado um evento
para a visualização do estado atual do host monitorado. Ex. trigger de host
inacessível disparada, gera um evento de incidente;
e) ação: quando uma condição estabelecida for satisfeita, a mesma efetua uma
operação que caracteriza uma ação;
f) operação: operação executada quando uma ação acontece. Ex. envio de e-
mail para o administrador.
Figura 34 - Fluxograma de operação do Zabbix
Fonte: Do autor, adaptado de Alves (2013).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
84
5.5 Cenário proposto
O cenário proposto para a empresa visou englobar os principais
equipamentos a serem monitorados quanto à sua relevância a falhas e problemas
que gerassem algum prejuízo ao negócio. A Figura 35 mostra o esquema de
implantação do Zabbix utilizado no cenário da empresa.
Na administração central foi instalado o servidor Zabbix em sua versão 2.0.8,
utilizando o banco de dados PostgreSQL v 8.4, este escolhido por ser o mesmo
banco que comporta o sistema de gestão da empresa, havendo um maior
conhecimento sobre o mesmo pela equipe de TI. O equipamento utilizado para a
instalação foi o servidor de backup da empresa (Quadro 14), pois o mesmo dispõe
de muitos recursos computacionais e possui pouca carga atribuída, sendo o
hardware ideal no âmbito da empresa para a instalação do servidor Zabbix, do
banco de dados e do frontend web.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
85
Figura 35 - Modelo proposto de implantação do Zabbix
Fonte: Do autor.
Buscando um melhor ajuste nas configurações do servidor Zabbix, alguns
parâmetros foram alterados no arquivo de configuração, conforme o Quadro 16.
Através de testes e análises chegou-se a esta configuração, a qual mostrou-se
eficiente, conforme será discutido no Capítulo 6.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
86
Quadro 16 - Parâmetros alterados no arquivo de configuração do Zabbix Server
Fonte: Do autor.
Para amenizar a carga do servidor Zabbix foi instalado um proxy operando de
modo ativo em cada unidade de negócio, inclusive na própria administração. A
decisão de utilizar o modo ativo do proxy ao invés do modo passivo se deu pelo fato
de aquele executar apenas uma conexão com o servidor, reduzindo a comunicação
e o tráfego entre o servidor e o proxy.
Nas filiais, o Zabbix proxy foi instalado no servidor, tendo em vista que ele
permanece sempre ligado, podendo, assim, monitorar os ativos a qualquer
momento, mesmo não havendo expediente. Para cada proxy foi ajustado alguns
parâmetros em seu arquivo de configuração, como mostra o Quadro 17, a seguir:
Parâmetro Valor Padrão Valor Ajustado Descrição
ListenPort 10051 10052 Porta de escuta para o trapper
LogFile - <caminho_para_log> Nome do arquivo de log
LogFileSize 1 100 Tamanho máximo do log em Mb
DBName - zabbix Nome do banco de dados
DBUser - zabbix Usuário do banco de dados
DBPassword - <senha_do_banco> Senha do banco de dados
StartPollersUnreachable 1 2
Número de instâncias de pollers para
hosts inacessíveis
StartTrappers 5 8 Número de instâncias de trappers
StartPingers 1 5 Número de instâncias de pingers
StartDiscoverers 1 5
Número de instâncias para
discoverers
StartHTTPPollers 1 0
Número de instâncias de pollers
HTTP
JavaGateway - <ip_do_servidor_java_gateway> Endereço do Zabbix Java gateway
JavaGatewayPort 10052 10053 Porta de escuta do java gateway
StartJavaPollers - 2 Número de instâncias de java poller
LogSlowQueries 0 100
Tempo de consulta ao banco de
dados antes de ser registrada
Configuração do servidor Zabbix
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
87
Quadro 17 - Parâmetros alterados no arquivo de configuração do Zabbix Proxy
Fonte: Do autor.
Os agentes Zabbix foram instalados em cada equipamento que possuía
suporte a instalação do mesmo como servidores, thin client, roteadores,
microcomputadores e notebook’s. Estes também tiveram algumas modificações em
seus arquivos de configuração (Quadro 18).
Quadro 18 - Parâmetros alterados no arquivo de configuração dos agentes Zabbix
Fonte: Do autor.
Parâmetro Valor Padrão Valor Ajustado Descrição
Server - <ip_do_zabbix_server>
IP ou hostname do servidor zabbix
para enviar dados de configuração ao
proxy
ServerPort 10051 10052
Porta de escuta do servidor para
trappers
Hostname - <nome_do_proxy>
Nome do proxy. Deve ser o mesmo
nome cadastrado no frontend
ListenPort 10051 10052 Porta de escuta para o trapper
LogFile - <caminho_para_log> Nome do arquivo de log
LogFileSize 1 100 Tamanho máximo do log em Mb
ProxyLocalBuffer 0 1
Mantem os dados coletados por N
horas mesmo se já houve
sincronização com o servidor
ProxyOfflineBuffer 0 6
Mantem os dados por N horas em
buffer interno caso o servidor Zabbix
esteja inacessível
ConfigFrequency 3600 900
Tempo de espera (segundos) para
recuperar dados de configuração do
servidor
DataSenderFrequency 1 5
Proxy envia dados coletados ao
servidor em N segundos
StartPingers 1 3 Número de instâncias de pingers
StartDiscoverers 1 3
Número de instâncias para
discoverers
JavaGateway - <ip_do_servidor_java_gateway> Endereço do Zabbix Java gateway
JavaGatewayPort 10052 10053 Porta de escuta do java gateway
StartJavaPollers - 1 Número de instâncias de java poller
LogSlowQueries 0 100
Tempo de consulta ao banco de
dados antes de ser registrada
Configuração dos proxies Zabbix
Parâmetro Valor Padrão Valor Ajustado Descrição
ListenPort 10051 10052 Porta de escuta para o trapper
LogFile - <caminho_para_log> Nome do arquivo de log
LogFileSize 1 100 Tamanho máximo do log em Mb
EnableRemoteCommands - 1
Habilita execução de comandos
remotos
LogRemoteCommands - 1
Habilita log de avisos para comandos
remotos
Server - <ip_do_proxy_vinculado>
Lista de IP ou hostname dos
servidores Zabbix ou proxies para
checagens passivas
StartAgents 3 5
Número de instâncias para
checagens passivas
ServerActive - <ip:porta – proxy vinculado>
Lista de IP ou hostname dos
servidores Zabbix ou proxies para
checagens ativas
UserParameter - <chave>,<comando shell> Comandos definidos pelo usuário
Configuração dos agentes Zabbix
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
88
5.6 Uso de templates personalizados
Uma característica do Zabbix é a possibilidade de criar templates para a
organização dos elementos monitorados. Através dos templates é possível definir
um modelo de regras de coleta, incluindo itens, triggers, telas, gráficos, regras de
auto busca, entre outros, sendo utilizáveis em qualquer host, de forma única ou
combinado com outros templates.
Para o cenário proposto na empresa Costaneira, utilizou-se a criação de
diversos templates personalizados (Figura 36), um para cada tipo de monitoração.
Por exemplo, todas as regras pertinentes a informações de placas de rede como
tráfego de entrada e saída, tempo de resposta de pacotes ICMP, enfim, foram
agrupadas em um único template e todos os hosts monitorados possuem
associação a esse template. Dessa forma, ao alterar alguma regra neste template,
todos os hosts vinculados a ele serão atualizados também, simplificando o
gerenciamento e manutenção.
Figura 36 - Tela de templates personalizados
Fonte: Do autor.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
89
5.7 Uso de regras de auto busca
O Zabbix dispõe de uma maneira de criar automaticamente itens, triggers e
gráficos para diferentes tipos de elementos gerenciados. Tal característica chama-se
Low Level Discovery (LLD), e, por padrão, na versão 2.0, suporta três tipos de
descoberta de itens: descoberta de sistemas de arquivos, descoberta de interfaces
de rede e descoberta de SNMP OID’s, sendo possível também utilizar regras
customizadas com scripts, utilizando a sintaxe do protocolo JSON (ZABBIX, 2013).
Para o caso da empresa Costaneira, foram utilizados alguns desses recursos
de auto busca. Um exemplo foi a criação da regra de descoberta chamada “Network
interfaces” (Figura 37 - A), utilizada para criar automaticamente os itens que
possibilitariam a monitoração, como tráfego de entrada (Figura 37 – B) das portas de
um switch. Como esse equipamento possui 53 interfaces de rede, sendo monitorado
de cada interface o tráfego de entrada e saída, haveria a necessidade de incluir
manualmente 106 itens para este host. Utilizando o LLD, esses itens foram criados
automaticamente (Figura 37 – C).
Figura 37 - Regra de auto busca para descoberta de interfaces de rede
Fonte: Do autor.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
90
5.8 Monitoramento de aplicações Java
A partir da versão 2.0 do Zabbix foi introduzida a funcionalidade de
monitoramento de aplicações Java através do protocolo Java Management
Extension (JMX). Utilizando um deamon chamado Zabbix Java Gateway, o Zabbix
consulta algum contador JMX do host monitorado de forma remota. Não há
necessidade de instalar nenhum software adicional na aplicação que será
monitorada, mas apenas deve-se iniciá-la utilizando a opção a seguir: “- D
com.sun.management.jmxremote”, para que seja possível coletar as informações de
monitoramento da interface JMX e atribuí-la ao host monitorado no Zabbix (Figura
38 – A).
Na empresa Costaneira, o sistema de gestão é desenvolvido em Java,
portanto, possibilitar o monitoramento dessa aplicação torna-se bastante útil para
estabelecer métricas e verificar possíveis gargalos na aplicação. A Figura 38 – B
representa um item que está sendo monitorado em um host da empresa em que
utiliza a interface JMX para coletar valores referentes às threads da aplicação Java.
Já a Figura 38 – C mostra um gráfico de utilização dessas threads conforme os
valores coletados.
Figura 38 - Monitoramento JMX na empresa Costaneira
Fonte: Do autor.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
91
5.9 Monitoramento do banco de dados PostgreSQL
Antes da implantação do Zabbix, a empresa analisada não possuía nenhuma
forma automatizada de monitoramento do banco de dados, sendo que para coletar
alguma métrica do mesmo era necessário fazer uma consulta manual ao banco de
dados para recuperar a informação. Através do Zabbix e scripts desenvolvidos em
shell script foi criado um template exclusivo para coletar informações provindas do
banco de dados PostgreSQL, incluindo desde itens de estatísticas gerais
relacionados a checkpoints, buffers alocados, informações de lock, número de
transações de commit, número de transações de rollback, como métricas específicas
de cada banco de dados, utilizando, para isso, uma regra de auto busca (Figura 39 –
A) para criar automaticamente os itens pertinentes a cada banco e as informações
que serão coletadas dos mesmos (Figura 39 – B).
Assim, torna-se possível estabelecer um padrão de comportamento do banco
de dados, quanto ao seu crescimento e desempenho, podendo dimensionar de
forma adequada os seus recursos para otimizá-lo de acordo com as necessidades
da empresa.
Figura 39 - Monitoramento do banco de dados PostgreSQL
Fonte: Do autor.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
92
5.10 Monitoramento proativo
Para propiciar um ambiente de monitoramento proativo, ou seja, antecipar-se
aos problemas para que fosse possível resolvê-los antes que os mesmos
causassem prejuízos ao negócio, definiram-se no Zabbix algumas ações para
determinados eventos caracterizados como incidentes. A Figura 40 mostra um
exemplo de tela de ações pré-definidas que visa enviar e-mail ao administrador
quando for gerado um evento do tipo “INCIDENTE” com severidade maior ou igual a
“Alta” em alguns grupos de host. Outra forma de ação gerada foi a de executar um
comando remoto no host monitorado, como, por exemplo, reiniciar o serviço de
LightWeight Directory Access Protocol (LDAP) quando alguma trigger do template
LDAP gerasse um evento do tipo “INCIDENTE” e o ele possuísse severidade maior
ou igual a “Média”.
Figura 40 - Tela de ações do Zabbix
Fonte: Do autor.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
93
6 RESULTADOS OBTIDOS
Esse capítulo discutirá os resultados obtidos com a implantação do Zabbix na
empresa Costaneira e qual foi o impacto do mesmo quanto à utilização dos recursos
de rede e computacionais que esse software consome. Na seção 6.1 é feita uma
análise dos equipamentos monitorados após a implantação do Zabbix. A seção 6.3
faz uma projeção do tamanho em disco necessário para o banco de dados do
Zabbix. A análise de performance do Zabbix será abordada na seção 6.4. Já as
seções 6.5 e 6.6 fazem uma avaliação do consumo de banda de rede, CPU e
memória, respectivamente. Já na seção 6.7 serão abordadas algumas formas de
visualização dos dados coletados, utilizando gráficos, mapas e telas para uma
melhor compreensão do estado da rede monitorada. A seção 6.8 encerra este
capítulo trazendo um comparativo do monitoramento antes e depois da implantação
do Zabbix na empresa estudada.
6.1 Equipamentos monitorados
Ao término da etapa de implantação do Zabbix na empresa Costaneira, foram
inclusos 85 hosts, dentre esles, 47 ativamente monitorados e 7 não monitorados,
divididos em 31 templates personalizados para cada grupo de monitoramento
(Figura 41).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
94
Desse montante de hosts cadastrados estão sendo monitorados mais de
2.600 itens a uma taxa de 14,92 valores armazenados no banco de dados do Zabbix
a cada segundo. Esses valores são úteis para analisar o desempenho e projetar
uma estimativa do tamanho necessário para o banco de dados do Zabbix. A seguir
será abordado como foram mensuradas essas métricas, para estimar o espaço
necessário para o banco de dados do Zabbix e otimizar a performance do mesmo.
Figura 41 - Tela de status do Zabbix
Fonte: Do autor.
6.2 Cálculo para estimativa do banco de dados Zabbix Segundo o Zabbix (2013), o tamanho do banco de dados da aplicação pode
ser definido seguindo a seguinte fórmula (Quadro 19): Espaço em disco =
Configurações do Zabbix + Histórico + Estatísticas + Eventos.
Quadro 19 - Fórmula para estimar o espaço em disco do Zabbix
PARÂMETRO FÓRMULA PARA CALCULAR O ESPAÇO
EM DISCO NECESSÁRIO (BYTES)
Configurações do Zabbix Valor fixo. Normalmente 10Mb ou menos.
Tabela de Histórico
dias*(itens/intervalo de coleta)*24*3600*bytes onde, itens: número de itens dias: número de dias para manter histórico intervalo de coleta: tempo médio de intervalo de coleta de itens bytes: número de bytes necessários para manter um único valor - depende de banco de dados, normalmente 50 bytes.
Tabela de Estatísticas
dias*(itens/3600)*24*3600*bytes itens : número de itens dias : número de dias para manter histórico bytes : número de bytes necessários para manter uma única estatística - depende de banco de dados, normalmente 128 bytes.
CONTINUA
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
95
CONCLUSÃO
PARÂMETRO FÓRMULA PARA CALCULAR O ESPAÇO
EM DISCO NECESSÁRIO (BYTES)
Tabela de Eventos
dias*eventos*24*3600*bytes eventos : número de eventos por segundo. No pior caso, será 1. dias : número de dias para manter histórico bytes : número de bytes necessários para manter uma única estatística - depende de banco de dados, normalmente 130 bytes.
Fonte: Zabbix (2013).
Para a empresa Costaneira, o número de dias definidos para armazenar o
histórico de cada item, em média, ficou em 10 dias, pois se verificou que não haveria
necessidade de manter em histórico os valores da forma como eles foram coletados,
já que esses mesmos valores estariam também armazenados na tabela de
estatísticas em forma de gráficos, podendo ali ser consultados. Por sua vez, a tabela
de estatísticas armazenará os valores, em média, por dois anos, sendo, assim,
possível determinar quais foram as mudanças de um ano para outro. O intervalo
médio de coleta ficou em aproximadamente 175 segundos, um valor considerado
aceitável, por não gerar vazão de coletas desnecessárias em um período de tempo
muito curto, e nem manter as coletas ociosas com intervalos muito distantes.
O número de itens coletados atualmente representa mais de 50% do total de
itens que serão monitorados, pois já engloba os ativos com maior risco ao negócio
como todos os servidores e serviços essenciais para a empresa. Projetando um
cenário pessimista no qual o número de itens atuais (2.602) representariam apenas
25% do total de itens monitorados, esse valor passaria a ser cerca de 10.400 itens
monitorados.
Levando em consideração essas informações, o Quadro 17 mostra o cálculo
executado para dimensionar o espaço em disco necessário para o Banco de dados
do Zabbix.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
96
Quadro 20 - Cálculo para estimativa do tamanho do banco de dados do Zabbix
Fonte: do autor.
Através dessa projeção foi possível verificar que, mesmo prevendo um
cenário pessimista, o espaço em disco necessário para o banco de dados do Zabbix
(31,75 Gb) ocuparia apenas 5,29% do espaço em disco total (600 Gb) do servidor
em que foi instalado (Quadro 14). Também fica evidente que o espaço em disco não
cresce de forma exponencial ao quadruplicar o número de itens coletados, sendo
viável ter milhares de itens de coleta, desde que haja um dimensionamento
adequado de intervalo de coleta e dias em que os dados permanecerão na tabela de
histórico.
6.3 Performance
O Zabbix dispõe de itens internos que possibilitam a coleta de informações
quanto à sua performance. Esses valores são de extrema importância para
identificar problemas de desempenho da aplicação, à medida que o ambiente
monitorado expande. Assim, pequenos ajustes nos arquivos de configuração do
Zabbix podem melhorar a execução do fluxo de dados, e, consequentemente, o seu
funcionamento adequado.
Na empresa Costaneira houve a necessidade de alterar o arquivo de
configuração do servidor Zabbix (Quadro 16), pois os valores padrões estavam se
mostrando ineficientes à medida que o ambiente monitorado crescia (Figura 42).
Processos como trapper, discovery e proxy poller chegaram a atingir picos de cem
por cento ocupados, o que acarretou em atraso de coletas e perda de desempenho
do servidor Zabbix.
Estimado atual Previsão
Configurações do Zabbix Fixo 10485760 10485760
Tabela de Histórico
dias*(itens/intervalo de coleta)*24*3600*bytes
10*(2602/175)*24*3600*50 - Estimado Atual
10*(10400/175)*24*3600*50 - Previsão642322285,7 2567314286
Tabela de Estatísticas
365*(itens/3600)*24*3600*bytes (2 anos)
2*365*(2602/3600)*24*3600*128 - Estimado Atual
2*365*(10400/3600)*24*3600*128 - Previsão 5835141120 23322624000
Tabela de Eventos2*365*eventos*24*3600*bytes (2 anos)
2*365*24*3600*130 8199360000 8199360000
Total (Bytes)Configurações Zabbix + Histórico + Estatísticas +
Eventos 14687309166 34099784046
Total (Gb) 13.67 31.75
Valores (Bytes) - 2 AnosFórmula para calcular o espaço em disco
necessário (Bytes)Parâmetro
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
97
Figura 42 - Gráfico de porcentagem de processos de coleta de dados ocupados no
Zabbix
Fonte: Do autor.
Outra funcionalidade do Zabbix que permitiu compreender como o fluxo de
coletas estava se comportando foi a tela de fila de itens a serem atualizados. A
Figura 43 aborda essa tela, usando a configuração padrão do Zabbix. É possível
observar que existe uma série de itens que estavam a mais de 10 minutos sem
serem atualizados, podendo ser um indicativo de que o servidor Zabbix necessitava
de ajustes em suas configurações.
Figura 43 - Fila de itens a serem atualizados por proxy usando configurações padrão
Fonte: Do autor.
O comportamento normal do Zabbix é atualizar os itens em poucos segundos,
deixando a fila de itens a serem atualizados entre 5 a 30 segundos de espera.
Valores acima disso podem indicar problemas de desempenho do servidor Zabbix,
devido à má configuração ou fatores como indisponibilidade do host monitorado,
intervalo de coleta muito longo, entre outros. A Figura 44 mostra a mesma tela após
os ajustes nas configurações e revisão de itens monitorados.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
98
Figura 44 - Fila de itens a serem atualizados por proxy após ajustes de
configurações
Fonte: Do autor.
A Figura 45 mostra um gráfico gerado no Zabbix que informa a sua
performance quanto aos itens processados por segundo e a fila de itens a serem
atualizados. Quando essa fila estiver maior que o número de itens processados
pode haver um problema de desempenho.
Figura 45 - Gráfico de performance do servidor Zabbix
Fonte: Do autor.
6.4 Consumo de banda de rede
Para analisar o impacto causado pelo Zabbix na rede da empresa Costaneira,
mediu-se o tráfego de rede antes e depois da implantação do mesmo. Para isso, foi
utilizado o MRTG, já que este era o software que a empresa usava antes da
instalação do Zabbix para medição de tráfego de rede. O período abrangido por esta
análise foi de dois meses.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
99
A metodologia aplicada para esse diagnóstico consistiu em medir o tráfego de
rede na interface em que o servidor Zabbix foi instalado (Figura 46) e na interface do
servidor da VPN na administração central (Figura 47), para medir tanto o tráfego
interno, como o tráfego entre a administração e as filiais. Já em uma filial remota,
também foi medido o tráfego na interface do servidor em que o Zabbix proxy foi
instalado (Figura 48), bem como na interface da VPN (Figura 49), para observar se
haveria algum impacto significativo na rede entre as filiais e a administração após a
implantação do Zabbix.
Os dados coletados foram distribuídos em dois gráficos: um com valores
correspondentes a um dia de coleta, com média de intervalo de cinco minutos, e
outro representando uma semana de coleta, com média de trinta minutos.
Na interface de rede do servidor Zabbix (Figura 46) o tráfego de entrada
aumentou cerca de 0,1%, enquanto o tráfego de saída teve um aumento de 0,4%
em média diária e semanal.
Figura 46 - Comparativo de tráfego de rede na interface do Zabbix antes e depois de
sua implantação
Fonte: Do autor.
Quando analisado o comparativo entre o tráfego gerado na interface da VPN
na administração central (Figura 47), houve, em média, um aumento de 0,1% no
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
100
tráfego de entrada e saída para valores diários e semanais, exceto para o tráfego de
saída, que obteve o mesmo percentual em ambos os casos para coletas semanais.
Figura 47 - Comparativo de tráfego de rede na interface da VPN na administração
central antes e depois da implantação do Zabbix
Fonte: Do autor.
Já em uma filial remota, o comparativo entre o tráfego de entrada e saída na
interface em que o Zabbix Proxy foi instalado (Figura 48) não mostrou nenhuma
variação em seu percentual que pudesse justificar um aumento de tráfego de rede.
Figura 48 - Comparativo de tráfego de rede antes e depois da implantação do Zabbix
na interface do Zabbix Proxy em uma filial remota
Fonte: Do autor.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
101
O mesmo ocorreu com a interface da VPN na filial remota (Figura 49) aonde a
média de tráfego de entrada diária e semanal é praticamente nula, enquanto que o
tráfego de saída totaliza cerca de 0,1% do limite de banda disponível.
Figura 49 - Comparativo de tráfego de rede antes e depois da implantação do Zabbix
na interface da VPN em uma filial remota
Fonte: Do autor.
Pode-se observar que, em todos os casos analisados, a diferença, em média,
tanto do tráfego de entrada como o de saída, antes e depois da implantação do
Zabbix, oscilaram muito pouco, com tendência a equivalência, o que, de fato, provou
que, com a implantação do Zabbix, não houve nenhum tipo de perda significativa
quanto ao desempenho de rede, uma vez que ele se mostrou muito eficiente nesse
ponto.
6.5 Consumo de CPU e memória
Para a medição de consumo de CPU e memória provocado pela implantação
do Zabbix foi instalado o utilitário atop na máquina aonde o servidor Zabbix foi
instalado e também no servidor de uma filial remota que possuía o monitoramento
baseado em proxy. A Figura 50 representa a saída do comando atop no servidor em
que o Zabbix foi instalado. Segundo as informações ali contidas, existem 31
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
102
processos do zabbix_server rodando, consumindo 0% de CPU e cerca de 172,6 Mb
de memória. Já para o agente instalado no mesmo servidor, há 2 processos em
execução utilizando 2876Kb de memória e 0% de CPU.
Figura 50 - Consumo de CPU e memória do Zabbix
Fonte: Do autor.
Na Figura 51, mostra-se o consumo de CPU e memória do Zabbix Proxy
instalado em uma filial remota. Os valores retornados correspondem a 11 processos
rodando, utilizando 23332 Kb de memória e consumindo 0% de CPU para o
processo zabbix_proxy, enquanto que o processo zabbix_agentd possui apenas
uma instância com 520 Kb de memória utilizada a uma carga de 0% de CPU.
Figura 51 - Consumo de CPU e memória do Zabbix Prox.
Fonte: Do autor.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
103
Através desses valores constatou-se que tanto o servidor Zabbix, como o
proxy e os agentes instalados, consomem poucos recursos de CPU e memória, não
impactando de forma notável no desempenho dos servidores ao qual estão
instalados.
Outra forma utilizada para a verificação do consumo de CPU do Zabbix
consistiu em analisar o gráfico de consumo de CPU gerado pelo próprio Zabbix, no
seu servidor (Figura 52) e no servidor de uma filial remota (Figura 53), quando o
ambiente estava todo monitorado e quando todos os monitoramentos foram
desativados, exceto o de consumo de CPU nesses servidores.
Figura 52 - Consumo de CPU do servidor Zabbix sem monitoramento x com
monitoramento
Fonte: Do autor.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
104
Figura 53 - Consumo de CPU do Zabbix Proxy sem monitoramento x com
monitoramento
Fonte: Do autor.
Os valores correspondem a 1 hora de coleta e representam claramente que
não há nenhuma diferença significativa de consumo de CPU em ambas as
situações, tanto no servidor do Zabbix, como no proxy remoto. Mesmo analisando
esses valores por mais tempo, o gráfico tende a seguir esse padrão, pois a
arquitetura do Zabbix foi desenvolvida para que não houvesse nenhum tipo de
gargalo na aplicação que impactasse no desempenho do servidor em que o mesmo
estivesse instalado quando as configurações estivessem otimizadas.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
105
6.7 Formas de análise dos itens coletados
O Zabbix disponibiliza algumas formas para melhorar a visualização dos itens
coletados como, por exemplo, a utilização de gráficos, telas e mapas
personalizados.
A Figura 54 mostra um gráfico representando o tráfego de entrada e saída de
rede na interface do modem que recebe o link ADSL em uma filial remota da
Costaneira.
Figura 54 - Gráfico de tráfego de rede do link ADSL de uma filial remota
Fonte: Do autor.
Já abaixo, mostra uma tela do tráfego de entrada e saída de dados em todas
as interfaces de rede do servidor de produção, na administração central da empresa.
Figura 55 - Tela contendo gráficos de tráfego de rede em todas as interfaces de um
servidor
Fonte: Do autor.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
106
Os mapas auxiliam na visualização do estado de seus elementos como um
todo. Através dessa funcionalidade, podem-se visualizar elementos e grupos de
host, triggers, imagens ou outros mapas. A Figura 56 aponta um mapa criado a partir
de um grupo de hosts chamado “Servidores” que engloba todos os servidores físicos
da empresa, distribuídos em cada unidade de negócio. Observa-se que alguns
servidores estão circulados, o que indica que um incidente ocorreu naquele host,
portanto, o administrador dispõe de uma forma de visualização mais ampla do
ambiente gerenciado para monitorar o estado da mesma.
Figura 56 - Mapa contendo elementos de um grupo de host
Fonte: Do autor.
Através dessas formas de análise, é possível compreender o fluxo de dados
dos itens coletados, correlacionar problemas, descobrir quando determinado
comportamento começou a surgir ou quando algo pode se tornar um problema.
6.8 Comparativo de ativos monitorados antes e depois da implantação do
Zabbix
O Quadro 21 mostra uma comparação quanto ao monitoramento antes e
depois da implantação do Zabbix entre alguns ativos da empresa Costaneira, tanto a
nível de software, como de hardware, quanto ao seu nível de gerenciamento.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
107
Quadro 21 - Comparativo de ativos e serviços monitorados antes e depois da
implantação do Zabbix
Fonte: Do autor.
Após a implantação do Zabbix houve um ganho notável quanto ao
monitoramento dos ativos e serviços de rede na empresa abordada, uma vez que o
ambiente praticamente não era monitorado e passou a ter capacidade para
monitorar milhares de itens provindos das unidades geograficamente distribuídas, a
partir de um único ponto de gerenciamento, sem causar impactos significativos
quanto ao desempenho da rede como um todo.
Nome Tipo Monitoramento Monitoramento Tipo de monitoramento
Servidores Hardware Parcial Sim Memória, Disco, tráfego de rede, CPU, disponibilidade
Switch Hardware Não Sim Disponibilidade, tráfego de rede
Roteadores Hardware Não Sim Disponibilidade, tráfego de rede
Impressoras Hardware Não Sim Contadores, disponibilidade
Thin Client Hardware Não Sim Memória, Disco, tráfego de rede, CPU, disponibilidade
MicrocomputadoresHardware Não Sim Memória, Disco, tráfego de rede, CPU, disponibilidade
Notebook Hardware Não Sim Memória, Disco, tráfego de rede, CPU, disponibilidade
Nobreak Hardware Não Sim Status, disponibilidade, informações gerais
Postgresql Software Não Sim Disponibilidade, estatísticas do banco, consultas
Tomcat Software Não Sim
Disponibilidade, informação de sessões ativas,
contextos, threads, memória
LDAP Software Parcial Sim Disponibilidade, status da replicação
Zimbra Software Não Em implementação
Disponibilidade, status dos serviços envolvidos
(amavis, smtp, ldap, etc)
Logs diversos Software Não Sim
Informações de erros, status de backup, informações
diversas, etc
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
108
7 CONSIDERAÇÕES FINAIS
A presente monografia teve como objetivo elaborar um projeto de
gerenciamento de unidades geograficamente distribuídas, a partir de um nó central,
utilizando, para isso, uma empresa real que apresentasse um ambiente conforme o
proposto. Para isso, foi elaborado um estudo quanto aos conceitos de
gerenciamento de redes e protocolos envolvidos, bem como analisado diversas
aplicações que possibilitavam o gerenciamento dos ativos. Após, foi feito um
comparativo desses sistemas, que resultou na escolha do Zabbix, por ser o software
que melhor se enquadrou com as necessidades da empresa.
Antes da implantação do Zabbix foi analisado o cenário da empresa
Costaneira, tanto na administração central como em suas filiais, identificando os
equipamentos e serviços que causariam mais impacto ao negócio em caso de
indisponibilidade dos mesmos. Em seguida, buscou-se propor um cenário de
implantação do Zabbix, empregando, para isso, o recurso de monitoramento
baseado em proxy, para coletar as informações de ativos como servidores e
roteadores, bem como terminais thin client, impressoras e computadores.
Durante a implantação do Zabbix foi desenvolvido templates personalizados
para a empresa, facilitando, dessa forma, o gerenciamento e manutenção dos itens
monitorados. Também foram criadas regras de descoberta para incluir
automaticamente itens de monitoramento, utilizando, para isso, o Zabbix, em
conjunto com scripts desenvolvidos em shell. Algumas dessas regras foram usadas
para a descoberta de: interfaces de rede, SNMP OID's, banco de dados, sistemas de
arquivo e dispositivos RAID.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
109
Outro tipo de monitoração empregada foi a de aplicações Java, nativo no
Zabbix desde sua versão 2.0, já que o sistema de gestão da empresa é escrito
nessa linguagem. Com isso, tornou-se possível acompanhar e estabelecer um
padrão de comportamento da aplicação e estipular métricas para melhorar o
desempenho e corrigir possíveis falhas.
Após a implantação do Zabbix, apresentou-se uma análise do impacto que o
mesmo causou na rede da empresa Costaneira, quanto à performance, tráfego de
rede, consumo de CPU e memória. Também foi apresentado um cálculo para
estipular o espaço em disco necessário para o banco de dados utilizado pelo Zabbix.
Essa análise demonstrou que o Zabbix atendeu bem às expectativas, consumindo o
mínimo de recursos computacionais, mesmo projetando expansões no cenário.
Sendo assim, foi possível monitorar cerca de 2.600 itens, distribuídos em
aproximadamente 50 hosts entre as unidades das filiais e a administração central,
com previsão para monitorar em torno de 5.000 itens ao final de toda a implantação.
Por fim, através desse trabalho foi possível usar e aplicar os conhecimentos
adquiridos durante o curso, desde os conceitos técnicos envolvidos como arquitetura
de sistemas, protocolos e comunicação de dados, até questões de análise de
requisitos, gerencia de projetos, segurança da informação, entre outros. Também foi
possível aplicar esses conhecimentos em um ambiente corporativo, trazendo
benefícios para a empresa abordada e empregando um modelo que propiciou o
gerenciamento de redes de forma proativa, em vez de gerenciamento reativo, que
era a abordagem utilizada na empresa antes da implantação do Zabbix, e que se
mostrava ineficiente e em desconformidade com os padrões estabelecidos para a
área de gerenciamento de redes.
Diante de tudo o que foi elaborado nessa monografia, espera-se que esse
trabalho possa servir de base para outros indivíduos ou empresas que tenham
dificuldades em questões de gerenciamento dos ativos e estejam buscando uma
solução eficiente, sem custos, e que atenda às suas necessidades de
gerenciamento de forma satisfatória.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
110
7.1 Trabalhos Futuros
Como trabalhos futuros para a continuidade desse projeto pretende-se a
realização das seguintes atividades:
a) concluir a instalação e configuração dos agentes em todos os hosts que serão
monitorados pelo Zabbix;
b) melhorar o monitoramento do banco de dados da aplicação de gestão da
empresa, através de inclusão de consultas específicas para verificar o
desempenho, assim como analisar formas de melhorar o monitoramento da
replicação do banco de dados;
c) verificar junto à equipe de desenvolvimento mais formas de monitorar o
sistema de gestão da empresa, como a inclusão de monitoramento web, para
verificar o comportamento, tempo de resposta, entre outros, da aplicação
web, em diferentes navegadores, por exemplo;
d) complementar o monitoramento do servidor de e-mail Zimbra com estatísticas
de desempenho, monitoração dos e-mails filtrados, descartados, entre outros;
e) buscar melhorias quanto ao sistema de inventário do Zabbix, proporcionando
inclusão de informações mais úteis ao ambiente da empresa;
f) reavaliar as triggers e alertas para atender de forma plena todos os itens
monitorados, sem gerar falsos positivos;
g) incluir monitoramento de câmeras de segurança que estão sendo instaladas
em todas as unidades de negócio da empresa.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
111
REFERÊNCIAS
ALVES, Luciano. Treinamento Zabbix Certified Specialist. 2013. _______. Treinamento Zabbix for Large Environments. 2013. AZEVEDO, Douglas José Peixoto de. Gerenciamento na Arquitetura OSI. [2009?]. Disponível em:<http://www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=181>.Acesso em: 07 ago. 2013. BARRETO, Grasieli. Ferramentas de Gerência de Redes. 2008. Monografia (Especialização) – Curso de Ciência da Computação, Universidade Estadual de Londrina. Disponível em: < http://pt.scribd.com/doc/49558732/PDU-VER>. Acesso em: 15 mai. 2013. BONOMO, Elsey. Gerenciamento e Monitoração de Redes de Computadores utilizando-se Zabbix. 2006. Monografia (Pós Graduação) – Curso de Ciências da Computação, Universidade Federal de Lavras. Disponível em:<http://www.ginux.ufla.br/files/mono-EsleyBonomo.pdf>. Acesso em: 13 abr. 2013. CACTI. Cacti site oficial. 2013. Disponível em: <http://www.cacti.net/>. Acesso em: 02 jun. 2013. CARVALHO, Tereza Cristina Melo de Brito; BRISA; Sociedade Brasileira para Interconexão de Sistemas Abertos. Gerenciamento de redes: uma abordagem de sistemas abertos. 1 ed. São Paulo: Makron Books, 1993. CASE, J.; FEDOR, M.; SCHOFFSTALL, M.;DAVIN, J. Request For Comments 1157. A Simple Network Management Protocol (SNMP). 1990. Disponível em: <http://www.ietf.org/rfc/rfc1157.txt>. Acesso em: 05 mai. 2013. CASE, J.; MCCLOGHRIE, K.; ROSE, M.; WALDBUSSER, S. Request For Comments 1901. Introduction to Community-based SNMPv2. 1996. Disponível em: <http://www.ietf.org/rfc/rfc1901.txt>. Acesso em: 10 mai. 2013. _______. Request For Comments 1902. Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2). 1996. Disponível em: <http://www.ietf.org/rfc/rfc1902.txt>. Acesso em: 10 mai. 2013. _______. Request For Comments 1903. Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2). 1996. Disponível em: <http://www.ietf.org/rfc/rfc1903.txt>. Acesso em: 10 mai. 2013.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
112
_______. Request For Comments 1904. Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2). 1996. Disponível em: <http://www.ietf.org/rfc/rfc1904.txt>. Acesso em: 10 mai. 2013. _______. Request For Comments 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: 10 mai. 2013. _______. Request For Comments 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: 10 mai. 2013. _______. Request For Comments 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: 10 mai. 2013. _______. Request For Comments 1908. Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework. 1996. Disponível em: <http://www.ietf.org/rfc/rfc1908.txt>. Acesso em: 10 mai. 2013. COMER, Douglas E. Redes de Computadores e Internet. 4 ed. São Paulo:Bookman, 2007. COSTANEIRA, Web Site. Costaneira site oficial. 2013. Disponível em: <http://www.costaneira.com.br>. Acesso em: 14 abr. 2013. FASSI. Fassi site oficial. [2008?]. Disponível em: <http://www.fassi.eti.br/artigos/gerencia-de-redes/comparativo-entre-as-versoes-do-snmp>. Acesso em: 28 mai. 2013. FILHO, Humber Bernal. Tutoriais Banda Larga. Simple Network Management Protocol (SNMP). 2009. Disponível em: <http://www.teleco.com.br/tutoriais/tutorialsnmp/default.asp>. Acesso em: 25 mai. 2013. GTA.UFRJ. Protocolo SNMP. 2004. Apostila. Disponível em: <http://www.gta.ufrj.br/grad/04_1/snmp/mib.htm>. Acesso em: 23 abr. 2013. HARRINGTON, D.; PRESUHN, R.; WIJNEN, B. Request For Comments 2571. An Architecture for Describing SNMP Management Frameworks. 1999. Disponível em: <http://www.ietf.org/rfc/rfc2571.txt>. Acesso em: 10 mai. 2013. HELCIO,Wagner; IGUATEMI,Eduardo. Gerência de Redes de Computadores-SNMPv3. 2009. Disponível em: <http://www2.ufersa.edu.br/portal/view/uploads/setores/110/arquivos/Gerencia%20de%20Redes/gerSnmpv3.pdf>. Acesso em: 15 mai. 2013. ISO/IEC 10040, Web Site. ISO/IEC 10040. 1998.Disponível em: <http://webstore.iec.ch/preview/info_isoiec10040%7Bed2.0%7Den.pdf>. Acesso em:07 mai. 2013.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
113
KARING, Anderson. Protótipo de um Sistema de Monitoramento de desempenho de redes de computadores baseado no protocolo SNMPV3. Blumenau. 2002. Monografia (Graduação) – Curso de Ciências da Computação, Universidade Regional de Blumenau. Disponível em: <http://www.inf.furb.br/~pericas/orientacoes/SNMPv32002.pdf>. Acesso em: 02 jun. 2013. MCCLOGHRIE, K.; ROSE, M. Request For Comments 1066. Management Information Base for Network Management of TCP/IP-based internets. 1988. Disponível em: <http://www.ietf.org/rfc/rfc1066.txt>. Acesso em: 03 mai. 2013. _______. Request For Comments 1155. Structure and Identification of Management Information for TCP/IP-based Internets. 1990. Disponível em: <http://www.ietf.org/rfc/rfc1155.txt>. Acesso em: 03 mai. 2013. _______. Request For Comments 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: 03 mai. 2013. MELLO, Jorge Lucas de. Protótipo de um agente SNMP para uma rede local utilizando a plataforma JDMK. Blumenau, 2000. Monografia (Graduação) – Curso de Ciências da Computação, Universidade Regional de Blumenau. Disponível em: <http://www.inf.furb.br/~pericas/orientacoes/JDMK2000.pdf>. Acesso em: 18 mai.2013. MRTG. MRTG site oficial. 2013. Disponível em: <http://oss.oetiker.ch/mrtg/>. Acesso em: 02 jun. 2013. MURRAY, Peter; STALVIG, Paul. SNMP: Simplified. F5 White Paper. 2008. Disponível em: <http://www.f5.com/pdf/white-papers/snmp-simplified-wp.pdf>. Acesso em: 10 mai. 2013. NAGIOS. Nagios site oficial. 2013. Disponível em: <http://www.nagios.org/>. Acesso em: 03 jun. 2013. NTOP. NTOP site oficial. 2013. Disponível em: <http://www.ntop.org/>. Acesso em: 03 jun. 2013. OpenNMS. OpenNMS site oficial. 2013 Disponível em: <http://www.opennms.org/>. Acesso em: 05 jun. 2013. PANDORA FMS. Pandora FMS site oficial. 2013. Disponível em: <http://pandorafms.org/>. Acesso em: 04 jun. 2013. ROCHA, Carlos Gustavo A. da. SNMPv1. 2006. Disponível em: <http://datinf.cefetrn.br/lib/exe/fetch.php?media=corpodocente:carlosrocha:gerencia_redes:6-snmpv1.pdf>. Acesso em: 21 mai. 2013.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
114
_______. SNMPv3. 2006. Disponível em: <http://dietinf.ifrn.edu.br/lib/exe/fetch.php?media=corpodocente:carlosrocha:gerencia_redes:9-snmpv3.pdf>. Acesso em: 23 mai. 2013. ROCHA, Ivandro José de Freitas; SERRADOURADA, Marcel Oliveira. Gerência de redes de computadores utilizando o Zabbix: um estudo de caso. Universidade Católica de Goiás, 2008. Monografia. Disponível em:<http://aldeia3.computacao.net/greenstone/collect/trabalho/index/assoc/HASHd0ca.dir/doc.pdf>. Acesso em: jun. 2013. RRDTool. RRDTool site oficial. Disponível em: <http://oss.oetiker.ch/rrdtool/>. Acesso em: 01 jun. 2013. SALVO, Rodrigo. SNMP – Introdução. 2013. Disponível em: <http://www.ti-redes.com/gerenciamento/snmp/intro/>. Acesso em: 03 mai. 2013. SANTOS, Eduardo Erlê dos Santos; KOCH, Fernando Luiz; ASSUNÇÃO, Marcos Dias de; WESTPHALL, Carlos Becker. Agentes Coletores na Gerência de Redes de Computadores. 2003. Disponível em: <http://www.inf.furb.br/seminco/2003/artigos/anaisSeminco2003.pdf>. Acesso em: 05 mai. 2013. SANTOS, Fábio José Augusto dos. Sistema de Gerenciamento de Redes baseado em conhecimento. 2004. Monografia (Pós-graduação) – Curso de Ciências da Computação, Universidade Federal de Lavras. Disponível em: <http://www.ginux.ufla.br/files/mono-FabioSantos.pdf>. Acesso em: 05 jun. 2013. SPECIALSKI, Elizabeth Sueli. Gerência de Redes de Computadores e de Telecomunicações. Florianópolis: Universidade Federal de Santa Catarina – Departamento de Informática e de Estatística. [2002]. Apostila. Disponível em: <http://home.furb.br/fabio/redes2/pub/ApostilaGerencia.doc>. Acesso em: 05 jun. 2013. STALLINGS, William. SNMP, SNMPv2, SNMPv3 and RMON 1 and 2. 3 ed. Troy:Addison-Wesley, 1999. WALSH, Larry. SNMP MIB Handbook. 1 ed. Stanwood: Wyndham Press, 2008. ZABBIX. Zabbix site oficial. 2013. Disponível em: <http://www.zabbix.com/>. Acesso em: 03 jun. 2013. ZENOSS. Zenoss site oficial. 2013. Disponível em: <http://www.zenoss.com/>. Acesso em: 04 jun. 2013.
