UNIVERSIDADE CATÓLICA DE GOIÁS
DEPARTAMENTO DE COMPUTAÇÃO
GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
GERÊNCIA DE REDES DE COMPUTADORES
EM UM AMBIENTE CORPORATIVO REAL
RICARDO FERREIRA FERNANDES
WISBLER DA SILVA FARIAS
JUNHO
2007
i
UNIVERSIDADE CATÓLICA DE GOIÁS
DEPARTAMENTO DE COMPUTAÇÃO
GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
GERÊNCIA DE REDES DE COMPUTADORES
EM UM AMBIENTE CORPORATIVO REAL
Trabalho
de
Projeto
Final
de
Curso
II
apresentado por Ricardo Ferreira Fernandes e
Wisbler da Silva Farias à Universidade Católica
de Goiás, para obtenção do Título de Bacharel
em Ciência da Computação, orientado pela
professora Dra. Solange da Silva.
ii
GERÊNCIA DE REDES DE COMPUTADORES
EM UM AMBIENTE CORPORATIVO REAL
RICARDO FERREIRA FERNANDES
WISBLER DA SILVA FARIAS
Trabalho de Projeto Final de Curso II apresentado por Ricardo Ferreira Fernandes e
Wisbler da Silva Farias à Universidade Católica de Goiás, como requisito parcial para
obtenção do Título de Bacharel em Ciência da Computação.
Professora Solange da Silva, Dra.
Professor Olegário Correa da Silva Neto, Dr.
Orientadora
Coordenador de Projeto Final de Curso
iii
DEDICATÓRIA (EPÍGRAFE)
“Nenhum homem nem nenhuma nação podem existir sem uma idéia sublime. E no
mundo existe uma única idéia sublime - nomeadamente, a idéia da imortalidade da alma do
homem - pois todas as outras idéias "sublimes" de vida, que dão vida ao homem, são meras
derivações desta única idéia.”
Dostoievski, Fiodor
iv
AGRADECIMENTOS
Agradeço a todos que contribuíram direta ou indiretamente para a realização deste
trabalho. Primeiramente a Deus, que me fortalece e está presente em todos os momentos de
minha vida. Agradeço também aos meus familiares e à minha namorada, que com muita
dedicação e incentivo, me ajudaram nos momentos em que me encontrava cheio de
obrigações. Em especial, à minha orientadora, Profa. Dra. Solange da Silva pelo incentivo,
apoio e por sua cumplicidade e comprometimento no desenvolvimento deste trabalho.
Ricardo Ferreira Fernandes
Agradeço primeiramente a Deus pela vida que me destes, ao meu pai pela vida que
me proporciona, a minha irmã por, acima de tudo, suportar meus momentos de nervosismo.
A minha tão querida mãe, que já não se encontra fisicamente em nossa presença,
mas que vive eternamente em meu coração, todos os seus predicados, amor, carinho,
compaixão, caridade, cumplicidade, compreensão, dedicação, entrega, generosidade,
honestidade, integridade e outras palavras do gênero, podem ser resumidos em uma única
palavra: mãe!
A minha Orientadora Dra. Solange da Silva, por seu apoio, dedicação, paciência,
sugestões e amizade.
Difícil agradecer a todos que me são caros nessa vida citando seus nomes sem me
esquecer de pelo menos uma dúzia de meus estimados amigos, que mesmo que não deram
uma contribuição direta nesse trabalho, muito me ajudaram com o que têm de mais valioso, a
amizade, dedicação, carinho, apoio, momentos em que compartilhamos felicidades e
dividimos as dificuldades.
Wisbler da Silva Farias
v
RESUMO
Este trabalho, tem o objetivo principal de, além de efetuar um estudo teórico sobre o
protocolo de gerência de redes de computadores SNMP (Simple Network Management
Protocol), o de implementar uma solução prática de gerenciamento de redes de computadores
na EMBRAPA Arroz e Feijão (Empresa Brasileira de Pesquisa Agropecuária), utilizando uma
ferramenta de custo gratuito, sob a licença General Public License (GPL). Após o estudo das
ferramentas disponíveis no mercado e análise do levantamento de requisitos da empresa, a
solução implantada foi a ferramenta ZABBIX.
Palavras chave: SNMP, dispositivos gerenciados, MIB, gerenciamento de redes de
computadores, ZABBIX.
vi
ABSTRACT
This work, has the primary objective of, besides occur an abstract study about the
computer web management protocol Simple Network Management Protocol) , to implement a
custom solution of a computer web services management in EMBRAPA Rice and Beans
(Empresa Brasileira de Pesquisa Agropecuária) using a free cost tool, under the General
Public License (GPL). After the study of the available tools on market and analysis of the
survey of the company requirements, the introduced chosen solution use the ZABBIX.
Keywords: SNMP, managed devices, MIB, Network Management, ZABBIX.
vii
GERÊNCIA DE REDES DE
COMPUTADORES EM UM AMBIENTE CORPORATIVO REAL
SUMÁRIO
LISTA DE FIGURAS ........................................................................................................XI
LISTA DE TABELAS ..................................................................................................... XII
LISTA DE ABREVIATURAS E SIGLAS .....................................................................XIII
LISTA DE ABREVIATURAS E SIGLAS .....................................................................XIII
CAPÍTULO I ....................................................................................................................... 1
INTRODUÇÃO.................................................................................................................... 1
CAPÍTULO II ...................................................................................................................... 4
FUNDAMENTOS SOBRE GERENCIAMENTO DE REDES.......................................... 4
2.1 INTRODUÇÃO ........................................................................................................ 4
2.2 VISÃO GERAL SOBRE GERENCIAMENTO DE REDES................................... 4
2.3 PROTOCOLO SNMP .............................................................................................. 7
2.4 BASE DE DADOS MIB.......................................................................................... 13
2.4.1 Tipos de Objetos de uma MIB.......................................................................... 15
2.4.2 Estrutura Lógica da MIB................................................................................. 17
2.4.3 Exemplo dos Grupos da MIB II....................................................................... 19
2.4.3.1. Grupo System............................................................................................ 19
2.4.3.2. Grupo Interfaces ....................................................................................... 20
2.4.3.3. Grupo IP ................................................................................................... 20
2.4.3.4. Grupo ICMP ............................................................................................. 20
2.4.3.5. Grupo TCP ............................................................................................... 21
2.4.3.6. Grupo UDP............................................................................................... 21
2.4.3.7. Grupo SNMP ............................................................................................ 21
2.4.4 Compilador de MIBs........................................................................................ 22
viii
2.5 FERRAMENTAS PARA O GERENCIAMENTO DE REDES ............................ 23
2.5.1 NAGIOS .......................................................................................................... 23
2.5.2 OpenNMS ........................................................................................................ 27
2.5.3 ZABBIX ........................................................................................................... 28
2.5.4 Comparação entre as principais ferramentas de gerenciamento ..................... 30
CAPÍTULO III .................................................................................................................. 32
ANÁLISE DE REQUISITOS ............................................................................................ 32
3.1 INTRODUÇÃO ...................................................................................................... 32
3.2 SITUAÇÃO ATUAL DA REDE DE COMPUTADORES .................................... 32
3.2.1 Especificação Técnica do Escritório Técnico .................................................. 34
3.2.2 Especificação do Setor de Serviços Auxiliares (SSA) ...................................... 37
3.2.3 Especificação da Administração (ADM) / Chefia ............................................ 38
3.2.4 Especificação da Área de Comunicação Empresarial (ACE) .......................... 38
3.2.5 Especificação da ADM/Biblioteca ................................................................... 39
3.2.6 Especificação do Banco Ativo de Germoplasa (BAG) ..................................... 39
3.2.7 Especificação da Casa de vegetação ................................................................ 39
3.2.8 Especificação do Laboratório de Mecanização................................................ 39
3.2.9 Especificação do Setor de Máquinas e Implementos Agrícolas (SMI) ............ 39
3.2.10
Especificação do Galpão.............................................................................. 39
3.2.11
Especificação da Garagem........................................................................... 40
3.2.12
Especificação da Criação de Insetos ............................................................ 40
3.2.13
Especificação dos Alojamentos .................................................................... 40
3.2.14
Especificação técnica dos equipamentos de rede ......................................... 40
3.2.14.1 Switch tipo I.............................................................................................. 40
3.2.14.2 Switch tipo III ........................................................................................... 42
3.2.14.3 Módulo 1000/BaseLX............................................................................... 42
3.2.14.4 Módulo Planet SGSW-A1LX ................................................................... 42
3.2.14.5 Transceiver 100BaseFX/100BaseTX ........................................................ 42
3.2.14.6 Placa de rede 1000BaseT .......................................................................... 42
3.2.14.7 Patch Panel 24 portas ............................................................................... 43
3.2.14.8 Patch Panel 48 portas ............................................................................... 43
3.2.14.9 Rack 10U .................................................................................................. 43
ix
3.2.14.10 Rack 12U .................................................................................................. 43
3.2.14.11 Switch KVM (Keyboard, video, mouse) .................................................... 44
3.2.14.12 Cabo KVM – 5m....................................................................................... 44
3.2.14.13 Cabo KVM – 3m....................................................................................... 44
3.2.14.14 Adaptador PS/2 para teclado e mouse SUN ............................................... 44
3.2.15
Especificação dos cabos e conectores .......................................................... 44
3.2.15.1 Tomadas RJ-45 tipo Puch Down ............................................................... 45
3.2.15.2 Conectores RJ-45 Macho .......................................................................... 45
3.2.15.3 Cabo UTP ................................................................................................. 45
3.2.15.4 Cabos de comutação no Patch Panel (Patch Cable UTP)........................... 45
3.2.15.5 Conectores ópticos .................................................................................... 45
3.2.15.6 Cabo de fibra óptica .................................................................................. 46
3.2.15.7 Cabos de comutação no distribuidor óptico (Patch Cable óptico) .............. 46
3.3 LEVANTAMENTO DE REQUISITOS................................................................... 47
3.4 PROPOSTA DE SOLUÇÃO .................................................................................... 47
3.4.1. Protótipo da Proposta de Solução ...................................................................... 47
CAPÍTULO IV................................................................................................................... 49
ZABBIX.............................................................................................................................. 49
4.1 INTRODUÇÃO ...................................................................................................... 49
4.2 CARACTERÍSTICAS DO ZABBIX ..................................................................... 49
4.3 COMPONENTES DA FERRAMENTA ................................................................ 50
4.3.1 Servidor ZABBIX .............................................................................................. 51
4.3.2 Agente ZABBIX................................................................................................. 51
4.3.3 Interface WEB .................................................................................................. 51
4.4 REQUISITOS......................................................................................................... 52
4.4.1 Requisitos de Hardware.................................................................................... 52
4.4.2 Requisitos de Software...................................................................................... 53
4.5 MONITORAMENTO DE DESEMPENHO.......................................................... 55
4.6 MECANISMO DE ALERTA ................................................................................. 56
4.7 VERIFICAÇÃO DE INTEGRIDADE DE ARQUIVOS ....................................... 57
4.8 SERVIÇOS DE AUDITORIA................................................................................ 58
4.9 GERAÇÃO DE GRÁFICOS.................................................................................. 59
x
4.10 CAPACIDADE DE PLANEJAMENTO................................................................ 60
4.11 ACORDO DE NÍVEL DE SERVIÇO – SLA ......................................................... 61
4.12 CRIAÇÃO DE GRUPOS E MODELOS DE CONFIGURAÇÃO......................... 61
4.13 EXECUÇÃO DE COMANDOS REMOTOS......................................................... 62
CAPÍTULO V .................................................................................................................... 64
INSTALAÇÃO DO SISTEMA DE GERÊNCIA DE REDES DE COMPUTADORES
ZABBIX NA EMBRAPA ARROZ E FEIJÃO ................................................................. 64
5.1 INTRODUÇÃO ........................................................................................................ 64
5.2 INSTALAÇÃO DO ZABBIX ................................................................................... 64
5.2.1 Configuração do Banco de dados ........................................................................ 65
5.2.2 Configuração do ZABBIX .................................................................................... 66
5.3 O ZABBIX EM OPERAÇÃO NA EMPRESA......................................................... 66
5.4 AVALIAÇÃO DO ZABBIX EM OPERAÇÃO NA EMPRESA ............................. 67
CAPÍTULO VI................................................................................................................... 68
CONCLUSÃO.................................................................................................................... 68
REFERÊNCIAS BIBLIOGRÁFICAS .............................................................................. 70
BIBLIOGRAFIA SUGERIDA .......................................................................................... 72
xi
LISTA DE FIGURAS
Figura 2.1 - A estrutura de gerenciamento de rede [Flint, 1997]. ............................................ 5
Figura 2.2 - Localização do Protocolo SNMP no TCP/IP [Messias, 2005].............................. 9
Figura 2.3 - Formato de mensagem SNMP [Messias, 2005] ................................................. 13
Figura 2.4 - Árvore MIB [Messias, 2005]............................................................................. 18
Figura 2.5 - MIB II [Messias, 2005]. .................................................................................... 19
Figura 2.6 – Tela principal do NAGIOS (traduzida para o português) [NAGIOS, 2006]....... 25
Figura 2.7 – Tela do gerenciamento de falhas de serviços [NAGIOS, 2006]......................... 26
Figura 2.8 – Tela principal do OpenNMS [OpenNMS, 2006]............................................... 27
Figura 2.9 – Tela do ZABBIX: Estrutura da rede [ZABBIX, 2006]. ..................................... 30
Figura 3.1 – Ilustração da estrutura de firewall utilizando uma rede DMZ............................ 33
Figura 3.2 – Antena de rádio da EMBRAPA Arroz e Feijão................................................. 34
Figura 3.3 – Ala A ............................................................................................................... 35
Figura 3.4 – Ala B................................................................................................................ 35
Figura 3.5 – Ala C................................................................................................................ 36
Figura 3.6 – Rack Ala D ...................................................................................................... 37
Figura 3.7 – Switches internos (SSA)................................................................................... 38
Figura 3.8 – Fibras Ópticas .................................................................................................. 46
Figura 3.9 – Protótipo da solução ......................................................................................... 48
Figura 4.1 – Interface web do ZABBIX ............................................................................... 52
Figura 4.2 – Monitoramento do host GERENTE. ................................................................. 56
Figura 4.3 – Monitoramento – Alertas.................................................................................. 57
Figura 4.4 – Monitoramento de alterações no arquivo /etc/passwd ....................................... 58
Figura 4.5 – Configuração – Auditoria ................................................................................. 59
Figura 4.6 – Monitoramento – gráficos: Espaço livre no ponto de montagem/do GERENTE 60
Figura 4.7 – Monitoramento – Serviços IT ........................................................................... 61
Figura 4.8 – Configuração de grupos e modelos de configuração ......................................... 62
Figura 4.9 – Configuração – Ações ...................................................................................... 63
Figura 5.1 – Divisão dos pré-requisitos ................................................................................ 65
xii
LISTA DE TABELAS
Tabela 2.1 - Grupos da MIB II [Messias, 2005].................................................................... 19
Tabela 2.2 - Comparação entre as ferramentas de gerenciamento mais atuais ....................... 31
Tabela 4.1 – Requisitos de Hardware [ZABBIX,2006]......................................................... 53
xiii
LISTA DE ABREVIATURAS E SIGLAS
ACE - Área de Comunicação Empresarial
ACL - Access Control List
ADM – Administração
API - Application Program Interface
ARP - Address Resolution Protocol
ASCII - American Standard Code for Information Interchange
ASN 1 - Abstract Syntax Notation One
BAG - Banco Ativo de Germoplasma
BOOTP - Bootstrap Protocol
CCITT - Consultative Committee for International Telegraph and Telephone
DHCP - Dynamic Host Configuration Protocol
DMZ – De-Militarized Zone – Zona Desmilitarizada
DNS – Domain Name Service
DSCP - Differentiated Services Code Point
EMBRAPA Arroz e Feijão - Empresa Brasileira de Pesquisa Agropecuária/Centro Nacional de
Pesquisa de Arroz e Feijão
FTP – File Transfer Protocol
GBIC - Gigabit Interface Converter
GPL - General Public License - Licença Pública Geral
GUI – Graphic User Interface
HTTP - Hypertext Transfer Protocol
HTTPS - Hypertext Transfer Protocol Security
IAB - International Activities Board
IBM - International Business Machines
ICMP - Internet Control Message Protocol
IEEE - Institute of Electrical and Electronics Engineers
IP - Internet Protocol
IPX - Internetwork Packet Exchange
ISO - International Organization for Standardization
ITU-T – International Telecommunication Union - Telecommunications
xiv
KVM - Keyboard, Video, Mouse
LAN - Local Area Network
LDAP - Lightweight Directory Access Protocol
MAC - Message Authentication Code
MIB - Management Information Base
MRTG - Multi Router Traffic Grapher
MSTP - Multiple Spanning Tree Protocol
NAGIOS - NAGIOS Ain't Gonna Insist On Sainthood
NAT - Network Address Translation
NFS - Networking File System
NIS - Network Information Service
NMS - Network Management Station
OSI - Open Systems Interconnection
PCI - Peripheral Component Interconnect
PCMCIA - Personal Computer Memory Card International Association
PDU – Protocol Description Unit
PHP – Hypertext Preprocessor
PING - Packet Internet Group
POP - Post Office Protocol
QoS – Qualidade de Serviços
RADIUS - Remote Authentication Dial-In User Service
RFC – Request For Comments
RIP - Routing Information Protocol
RJ45 - Registered Jack 45
RMON - Remote Monitoring
RNP – Rede Nacional de Ensino e Pesquisa
RRDTool - Round Robin Database Tool
RSTP - Rapid Spanning Tree Protocol
SLA – Service Level Agreement
SMI - Setor de Máquinas e Implementos Agrícolas
SMS - Short Message Service
SMTP - Simple Mail Transfer Protocol
SNA - System Network Architecture
xv
SNMP - Simple Network Management Protocol
SO – Sistema Operacional
SQL - Structured Query Language
SSA - Setor de Serviços Auxiliares
SSH - Secure Shell
SSL - Secure Sockets Layer
STP - Spanning Tree Protocol
TCP - Transmission Control Protocol
TFTP - Trivial File Transfer Protocol
UDP - User Datagram Protocol
UFG – Universidade Feral de Goiás
UTP - Unshielded Twisted Pair
VLAN - Virtual Local Area Network
VPN - Virtual Private Network
WWW – World Wide Web
GERÊNCIA DE REDES DE COMPUTADORES
EM UM AMBIENTE CORPORATIVO REAL
CAPÍTULO I
INTRODUÇÃO
Atualmente, um número cada vez maior de negócios baseia seus serviços em
recursos de informações, telecomunicações e Internet. Com isso, independente do tamanho de
uma rede de computadores, ela precisa ser gerenciada e administrada, a fim de garantir que
suas aplicações de redes estejam disponíveis por tempo integral, consumindo um mínimo de
recursos físico, humano e estrutural [Flint, 1997].
Administradores de redes de computadores gerenciam várias informações, de forma
a manter todos os serviços em pleno funcionamento para o usuário dessa rede. No entanto,
existem problemas que o administrador não consegue identificar devido ao grande número de
serviços, trazendo transtornos ao usuário.
Segundo [Carvalho, 1997], os sistemas de gerenciamento de redes devem prover
mecanismos que permitam gerenciar, consultar, contabilizar, organizar e até planejar a
utilização de recursos durante as comunicações realizadas dentro do ambiente OSI (Open
Systems Interconnection). A atuação de tais sistemas deve, então, englobar cinco áreas
funcionais:
• gerenciamento de falhas – permitem detectar, isolar e corrigir situações de erro;
• gerenciamento de contabilização – permite determinar o índice de utilização de
recursos e associar a ele tarifas e custos;
• gerenciamento de configuração – possibilita obter informações, supervisionar e
exercer controle sobre a configuração dos componentes de rede;
• gerenciamento
de
desempenho
–
inclui
mecanismos
de
avaliação
do
1
comportamento dos recursos gerenciados e da eficiência das atividades de
comunicação;
• gerenciamento de segurança – permite gerenciar o emprego de mecanismos de
segurança referente ao controle de acesso, autenticação, criptografia entre outros
[Carvalho, 1997].
Assim, surgiu a necessidade de utilizar sistemas capazes de auxiliar o gerenciamento
do funcionamento desses serviços de redes de computadores, de forma que notifique ao
administrador da rede o tipo de problema que está acontecendo e em qual tipo de serviço, para
que este tome as devidas providências, de forma que afete o mínimo possível o usuário,
tomando decisões eficientes, de forma a manter o funcionamento normal da rede.
Este trabalho, tem o objetivo principal, além do estudo teórico, de implementar um
sistema prático de gerenciamento de rede de computadores em uma empresa real, no caso, a
EMBRAPA Arroz e Feijão (Empresa Brasileira de Pesquisa Agropecuária/Centro Nacional de
Pesquisa de Arroz e feijão); após o estudo teórico dos sistemas disponíveis e mais atuais do
mercado nessa área, verificou-se métodos bastante eficientes para notificar os administradores
da rede sobre falhas de serviços de rede e hardware, facilitando a análise das falhas mais
constantes dos serviços e suas correções, de forma a propor a solução mais adequada para a
empresa citada.
Conforme as pesquisas efetuadas, no mercado atual, são encontrados diversos
programas capazes de fazer esse tipo de gerenciamento, tais como:
•
Soluções proprietárias: o Software WhatUp ($ 1.495,00), o Software
BigBrother ($ 2.500,00 + $ 100,00 por cliente gerenciado) e o OpenView
($ 40.000,00);
•
Soluções de Software Livre: NAGIOS, ZABBIX e OpenNMS, todos
disponibilizados de forma gratuita sob a licença GPL (General Public License)
[Machado, 2006].
Como a empresa EMBRAPA Arroz e Feijão exigiu uma solução com software livre,
ou seja, de custo gratuito, o foco desse trabalho será o de realizar um estudo dessas
ferramentas disponíveis no mercado, buscando aquela que melhor se adequar à realidade da
rede de computadores da empresa.
2
Este trabalho está estruturado da seguinte forma:
O Capítulo 2 apresenta uma visão geral sobre o tema de gerenciamento de serviços
em uma rede de computadores, trazendo seu histórico, desde seu início até o momento atual.
Além disso, apresenta a visão geral de algumas dos principais softwares livres existentes que
podem atender as exigências da empresa para a implantação da ferramenta de gerenciamento
de redes de computadores, levantando os seus principais pontos positivos e negativos.
O Capítulo 3 traz um levantamento e análise de requisitos in loco, apresentando a
situação atual da rede de computadores da empresa EMBRAPA Arroz e Feijão, os problemas
enfrentados e uma proposta de solução (protótipo) que auxilie no gerenciamento dos serviços
disponíveis dessa rede. Além disso, é apresentada uma proposta de solução com a ferramenta
que poderá corresponder às necessidades da EMBRAPA Arroz e Feijão.
O Capítulo 4 apresenta uma visão geral da ferramenta ZABBIX, que é uma das mais
robustas, em se tratando de software livre para a gerencia de rede de computadores, a qual
possui características que possibilita o gerenciamento de dispositivos que possuam o
protocolo SNMP (Simple Network Management Protocol), suporta a maioria dos Sistemas
Operacionais (Unix, Windows e Novell), interface Web, banco de dados MYSQL e
PostgreSQL e geração de gráficos em tempo real.
O Capítulo 5 trata da instalação da solução proposta para o sistema de
gerenciamento de redes de computadores ZABBIX na empresa EMBRAPA Arroz e Feijão.
Finalmente, o capítulo 6 traz as conclusões gerais do trabalho.
3
CAPÍTULO II
FUNDAMENTOS SOBRE GERENCIAMENTO DE REDES
2.1 INTRODUÇÃO
Este capítulo traz uma visão geral sobre gerenciamento de serviços em uma rede de
computadores
baseado
no
modelo
de
referência
TCP/IP
(Transmission
Control
Protocol/Internet Protocol), trazendo seu histórico até o momento atual. Além disso,
apresenta a visão geral de algumas das principais ferramentas disponíveis no mercado,
priorizando as soluções de software livre.
A seção 2.2 trata dos fundamentos básicos sobre gerenciamento de serviços. A seção
2.3 diz respeito ao funcionamento e características do Protocolo SNMP (Simple Network
Management Protocol). A seção 2.4 apresenta as MIBs (Management Information Base), suas
categorias, os tipos de objetos utilizados em sua estrutura, sua árvore hierárquica com a
representação de cada nó, como as informações ficam armazenadas em sua base de dados
seguindo um padrão para que o compilador MIB possa acessar essas informações e tratá-las.
A seção 2.5 mostra o funcionamento de algumas ferramentas livres para o gerenciamento de
redes, mostrando uma visão geral do NAGIOS, OpenNMS e do ZABBIX.
2.2 VISÃO GERAL SOBRE GERENCIAMENTO DE REDES
Atualmente os sistemas de redes de computadores comerciais existentes estão se
tornando extremamente complexos. Partindo de algumas poucas redes locais isoladas, esses
sistemas se expandiram em LAN’s (Local Area Network) que operam ao longo de
corporações inteiras. Roteadores conectam LAN’s a escritórios remotos e redes de alcance
4
mundial se tornam cada vez mais presentes. Gerenciar e fazer manutenção desses sistemas,
para não mencionar problemas isolados, pode ser um desafio.
Entre as atividades básicas do gerenciamento de redes, estão a detecção e correção
de falhas, em um tempo mínimo, e o estabelecimento de procedimentos para a previsão de
problemas futuros.
O gerenciamento de redes é composto pelo hardware que constitui a rede, o qual
inclui as estações de trabalho, servidores, placas de rede, roteadores, pontes e hubs. Os
fabricantes desses dispositivos os construíram com capacidades de gerenciamento de rede, a
fim de se saber remotamente sobre seu estado e permitir que eles nos alertem quando ocorre
certo tipo de evento. Os sistemas de gerenciamento de rede empregam um software,
implementado em um host da rede, que controla e administra os dispositivos dessa rede. Para
se gerenciar um serviço de rede, apenas esses recursos não são suficientes. Todas as
ferramentas de gerenciamento de redes que serão apresentadas neste trabalho são grátis, com
a licença GLP [Flint, 1997].
Segundo [Flint, 1997], o gerenciamento de rede é dividido em quatro categorias,
conforme apresentado na figura 2.1:
Figura 2.1 - A estrutura de gerenciamento de rede [Flint, 1997].
• Nós de gerenciamento – são os dispositivos que se quer gerenciar, o qual
possuem um software ou firmware que detecta o estado do dispositivo
gerenciado.
• Estação de gerenciamento de rede (gerente) – dispositivo centralizado que
comunica e apresenta o estado dos agentes nos nós gerenciados, geralmente é
5
uma estação de trabalho dedicada (UNIX ou DOS/Windows) que executa algum
software de gerenciamento de rede.
• Protocolo de gerenciamento de rede – usado pela estação de gerenciamento de
rede e pelos agentes para trocar informações de gerenciamento.
• MIB (Management Information Base) – base de dados onde ficam armazenadas
as informações dos dispositivos gerenciados.
Muitos fabricantes, SynOptics, Cisco e outros, produzem equipamentos gerenciáveis
pelo protocolo SNMP, que é um conjunto de funcionalidades que permitem a consulta remota
de variáveis da MIB de um dispositivo SNMP, que por sua vez pode gerar alarmes no console
de gerenciamento (gerente).
Ao projetar e estabelecer a infra-estrutura de gerenciamento de rede é necessário se
levar em consideração dois axiomas [Flint, 1997]:
1. O tráfego devido às informações de gerenciamento não deve aumentar
significativamente o tráfego da rede.
2. O agente de protocolo no dispositivo gerenciado não deve aumentar
significativamente o resultado de processamento a ponto de prejudicar a função
principal daquele dispositivo.
Atualmente existe uma grande diversidade de ambientes de rede, podendo se
encontrar tanto um mainframe IBM (International Business Machines) com uma rede SNA
(System Network Architecture), que é a arquitetura proprietária da IBM, como uma rede local
com ambiente Linux. Diante de tal heterogeneidade, a dificuldade de se projetar um
gerenciamento de rede pode ser grande, o qual podem ser resolvidos padrozinando as
informações provenientes dos dispositivos gerenciados utilizando, por exemplo, o protocolo
SNMP [Flint, 1997] e [Messias, 2005].
Segundo [Carvalho, 1997], as atividades de gerenciamento de redes são divididas
em cinco áreas funcionais denominadas: Gerenciamento de Falhas, Gerenciamento de
Configuração,
Gerenciamento
de
Desempenho,
Gerenciamento
de
Segurança
e
Gerenciamento de Contabilização. Estas áreas funcionais constituem processos de aplicação
de gerenciamento que utilizam os serviços oferecidos pela camada de aplicação do Modelo
OSI (Open Systems Interconnection).
Cada uma das áreas funcionais, dentro de seu escopo, buscam resolver problemas
6
relativos a falhas de componentes, configuração da rede, níveis de desempenho alcançados
pela rede, segurança e contabilização de sua utilização.
A área de Gerenciamento de Falhas busca isolar e corrigir operações anormais do
ambiente OSI. Sua principal função é investigar a ocorrência de falhas, identificar falhas,
realizar seqüências de testes para fins de diagnósticos e corrigir falhas.
O Gerenciamento de Contabilização oferece funções que possibilitam determinar o
custo associado à utilização dos recursos da rede, e inclui funções que permitem determinar
quais recursos e quanto desses recursos está sendo utilizado.
O Gerenciamento de Configuração tem como função controlar as condições do
ambiente de comunicação do sistema aberto, identificando mudanças significativas e
modelando a configuração dos recursos físicos e lógicos da rede.
O Gerenciamento de Desempenho oferece funções para medir, gerenciar, avaliar e
relatar os níveis de desempenho alcançados pela rede. Tais informações podem ser utilizadas
para fins de planejamento e controle da qualidade de serviços da rede.
A área funcional de Gerenciamento de Segurança apresenta três categorias de
atividades – gerenciamento de segurança do sistema, gerenciamento dos serviços de
segurança e gerenciamento dos mecanismos de segurança – e inclui funções que buscam
garantir a política de segurança definida para a rede [Carvalho, 1997].
2.3 PROTOCOLO SNMP
O protocolo SNMP foi projetado para permitir a comunicação entre os agentes e os
gerentes. Essa comunicação possui basicamente duas funções: uma de obtenção dos valores
dos objetos (função GET) e outra de alteração desses valores (função SET) que pode ser
usada para disparar remotamente a execução de operações nos recursos associados aos objetos
gerenciados (como uma reinicialização). É ainda previsto um mecanismo de notificação de
alterações nos objetos da MIB (TRAP). Tal estrutura torna um protocolo simples, flexível e
estável, pois mantém um formato básico fixo, mesmo que novos objetos sejam
implementados ou mesmo que novas operações sejam definidas, o que poderá ser feito
utilizando as operações básicas [Messias, 2005].
O SNMP é implementado usando uma abordagem cliente/servidor assíncrona, para
que o tráfico do gerenciamento de rede seja mínimo [Flint, 1997]. É um protocolo da camada
7
de aplicação, como mostrado na Figura 2.2, que usou primeiramente UDP/IP para se
comunicar através da rede interna [Harnedy, 1997].
A console de gerenciamento SNMP é um programa executado em um PC ou estação
de trabalho UNIX que reúne informações gerenciais fornecidas pelos agentes SNMP. Os
agentes SNMP são componentes sofisticados de comunicação de rede, como pontes,
roteadores e concentradores de fiação. Os agentes enviam informações gerenciais à console
no formato MIB. MIB é um padrão que define o tipo das informações que o agente deve
reunir e como elas devem ser armazenadas. Existem duas MIBs padrão – a MIB I e a MIB II.
Elas definem determinadas variáveis de informação que toda console SNMP deve monitorar
[Rigney, 1996].
A principal vantagem do SNMP está no fato de ele ser um padrão e de um agente
SNMP de determinado fornecedor comunicar com uma console de gerenciamento SNMP de
outro fornecedor. Um problema está nao fato de as MIBs padrão I e II estarem limitadas ao
volume de informações que obtêm do seu componente de rede, fazendo com que os diversos
fornecedores adotem os padrões de diferentes maneiras. Para aumentar a funcionalidade e
melhorar o gerenciamento, os fornecedores de SNMP criam suas próprias MIBs (MIB
privada) para reunirem mais informações sobre o hardware. No entanto, convém notar que, se
a console de gerenciamento não reconhecer a MIB privada, não poderá reunir as informações
necessárias [Rigney, 1996].
Segundo [Rigney, 1996], a maioria das consoles de gerenciamento SNMP oferece
um compilador MIB, capaz de obter o conteúdo da MIB privada de um fornecedor. O
compilador permite que a console de gerenciamento reúna informações específicas sobre o
hardware desse fornecedor. De modo geral, o SNMP é o que mais se assemelha a um padrão
universal de gerenciamento, mas não deve-se pressupor que toda console de gerenciamento
conseguirá se comunicar com o agente de gerenciamento SNMP.
O SNMP é a estrutura de gerência de redes mais utilizada atualmente. Fornece uma
estrutura básica para a administração, autenticação, autorização, controle de acesso e das
políticas de privacidade que podem ser alcançadas com a gerência de redes.
Segundo [Harnedy, 1997], os principais desenvolvedores do SNMP versão 1 (RFCs
SNMP) são Jeffrey, Mark Fedor, Martin Schoffstall, e James Davin e os escritores do SNMP
versão 1. Marshal Rose e Keith McCloghrie também fizeram muitas contribuições,
escreveram o SMI RFC e editaram a MIB-I e a MIB-II RFCs. Os princípios para a versão 2
são o exemplo de Jeffrey, Keith McCloghrie, Marshall Rosa e Steven Waldbusser.
8
As execuções da versão 1 do SNMP apareceram primeiramente em 1988. O SNMP
v2 que propôs padrões foi publicado originalmente em abril 1993, mas modificado
extremamente pelas propostas de esboço apresentadas em Janeiro 1996.
Os processos que implementam as funções de gerenciamento da Internet atuam
como agentes ou gerentes. Assim sendo, os agentes coletam as informações relevantes para o
gerenciamento de rede junto aos objetos gerenciados. O gerente processa as informações
recolhidas pelos agentes, com o objetivo de detectar falhas no funcionamento dos
componentes da rede, para que os sistemas de gerenciamento de redes possam tomar as
devidas providências, com o objetivo de corrigir as falhas decorridas [Flint, 1997] e [Soares,
1995].
As informações sobre os objetos gerenciados são armazenadas na MIB, que contém
informações sobre o funcionamento dos hosts, gateways, e processos que executam os
protocolos de comunicação (IP, TCP, ARP etc) [Soares, 1995].
SNMP
HTTP
UDP
TCP
SMTP
......
IP
Protocolo dependente da Rede
Figura 2.2 - Localização do Protocolo SNMP no TCP/IP [Messias, 2005]
A estação de gerenciamento SNMP é uma coleção de aplicações e uma base de
dados que controlam um grupo de agentes. Composta por quatro componentes, sendo uma
interface para o usuário (agente), aplicações de gerenciamento (gerente), uma base de dados,
um dispositivo SNMP (canal de transporte/ligação entre gerente e agente).
A interface do usuário permite ao administrador da rede mandar comandos de
gerenciamento e receber do agente as respostas solicitadas ou não. Tal interface poderia ser
em formato texto ou em algum tipo de interface gráfica para o usuário GUI (Graphic User
Interface).
As aplicações de gerenciamento operam na análise e processamento da informação
de gerenciamento de rede obtida do agente. A base de dados, ou variáveis de interesse,
contém todos os nomes, configurações, desempenhos, topologia e dados examinados da rede.
A base de dados é separada em categorias que incluem a MIB, a base de dados do elemento
de rede e a base de dados da aplicação de gerenciamento [Messias, 2005].
9
2.3.1 Agentes
No modelo de gerenciamento SNMP, hosts, bridges, roteadores, hubs, etc, devem
possuir agentes SNMP para que possam ser gerenciados pela estação de gerenciamento NMS
(Network Management Station) através do gerente SNMP. O agente responde a requisições da
estação de gerenciamento, que pode ser o envio de informações de gerência ou ações sobre as
variáveis do dispositivo onde está.
O funcionamento desta estrutura só é possível graças ao acesso direto à MIB que o
agente possui, pois todas as informações de gerência encontram-se lá. Ao receber uma
mensagem SNMP do gerente, o agente identifica que operação está sendo requisitada e
qual(is) a(s) variável(is) relacionada(s), e a partir daí executa a operação sobre a MIB. Em
seguida, monta uma nova mensagem de resposta, que será enviada ao gerente.
É concedido ao agente um certo poder de decisão, cabendo a ele, a partir da análise
do contexto da MIB, decidir se é ou não necessário enviar o trap ao gerente. Esse poder de
decisão é concedido ao agente para que em certas situações, como quando da inicialização do
sistema, traps desnecessários não sejam trafegados pela rede, o que, em se tratando de
dezenas de agentes, poderia interferir no desempenho global da rede [Messias, 2005].
2.3.2 Gerente
A interface entre as aplicações de gerência correntes no NMS e os agentes
espalhados pelos dispositivos da rede é o gerente. Cabe ao gerente enviar comandos aos
agentes, solicitando informações sobre variáveis de um objeto gerenciado ou modificando o
valor de determinada variável.
Os gerentes então processam estas informações colhidas pelos agentes e as repassam
à aplicação que as requisitou. A comunicação entre o gerente e as aplicações é possível
através da utilização das API (Application Program Interface) do gerente SNMP pelo
sistema.
A API é um conjunto de funções que fazem o intermédio na execução de comandos
entre um programa e outro, de forma a simplificar a um programa o acesso a funções de outro
programa e que, no caso do SNMP, fazem o intermédio das execuções entre uma aplicação de
gerência e o gerente SNMP.
10
Cabe também ao gerente encaminhar à aplicação de gerência os traps que
porventura sejam enviados pelos agentes. Assim, o software de gerência terá conhecimento da
presença de um novo equipamento na rede ou do mau funcionamento de algum dos
dispositivos da rede [Messias, 2005].
2.3.3 Operações SNMP
No gerenciamento SNMP, segundo [Messias, 2005], existem várias operações para a
comunicação entre os gerentes e agentes SNMP para obter informações dos dispositivos
gerenciados.
• Get - o gerente SNMP envia o comando Get a um determinado agente toda vez que
necessita recuperar uma informação de gerenciamento específica do objeto
gerenciado pelo agente. Estas informações encontram-se na forma básica de
variáveis, que por sua vez, estão na MIB do elemento de rede gerenciado.
• Set - a operação Set requisita a um determinado agente a atribuição/alteração do
valor de determinada(s) variável(is) de uma MIB. Alguns desenvolvedores, por
exemplo, acreditam que este comando não deve retornar um Response. Já outros
acham que a operação Set deve retornar alguma indicação de que a operação foi
efetuada. Porém o mais correto seria que, após cada operação Set sobre uma
variável, uma operação Get fosse efetuada sobre a mesma variável a fim de
assegurar que a operação Set foi efetuada.
• Trap - a operação Trap difere de todas as outras. Ela é utilizada por um agente
SNMP para notificar de forma assíncrona a um gerente algum evento extraordinário
que tenha ocorrido no objeto gerenciado. Diversos questionamentos são feitos
quanto a esta operação. Talvez o maior deles seja sobre a escolha dos eventos que
devem realmente ser notificados ao gerente. Embora seja quase unânime que o
gerente deve ser informado de alguns eventos significativos, muitos fornecedores de
produtos que implementam o SNMP trazem Traps específicos, muitos deles
desnecessários. Outro importante questionamento é como um agente pode ter certeza
de que o gerente o recebeu, visto que a operação Trap não gera um Response, o que
pode ocorrer quando, por exemplo, a máquina estiver perdendo pacotes. Isso não é
fácil de solucionar. Uma possibilidade seria o agente gerar tantos Traps quanto
necessário até que o gerente seja informado do evento. Essa solução, no entanto,
11
aumentaria o tráfego na rede, afetando o seu desempenho.
• Responses - como já descrito, sempre que um agente recebe um comando Get,
GetNext ou Set ele tenta executar a operação associada e, conseguindo ou não,
constrói uma outra mensagem que é enviada ao emissor da requisição. Esta
mensagem é a GetResponse. Das operações SNMP, apenas o Trap não gera um
Response [Messias, 2005].
2.3.4 Funcionamento do Protocolo SNMP
O SNMP realiza um processo de autenticação para permitir, ou não, o acesso de
clientes aos objetos gerenciados. Essa autenticação, para o SNMP versão 3, é realizada
através da verificação da comunidade, para confirmar se ela é, ou não, daquela rede, e uma
senha agregada a essa comunidade. Ao invés de apresentar muitos comandos como outros
protocolos, ele possui apenas um pequeno conjunto de operações, com funções básicas de
busca/alteração.
O SNMP foi está baseado apenas em estações de gerenciamento de rede e elementos
da rede. As estações de gerenciamento da rede são responsáveis por rodar aplicações de
gerenciamento que monitorem e controlem os elementos da rede, que podem ser hubs
inteligentes, roteadores e pontes, entre outros.
Cada máquina gerenciada é vista como um conjunto de variáveis que representam
informações referentes ao seu estado atual, estas informações ficam disponíveis ao gerente
através de consulta e podem ser alteradas por ele. Cada máquina gerenciada pelo SNMP deve
possuir um agente e uma base de informações MIB.
É um protocolo que permite a um administrador inspecionar ou alterar variáveis em
um elemento de rede a partir de uma estação de gerenciamento remota.
Todo o gerenciamento SNMP é realizado pelo sistema de gerenciamento de rede. As
estações de gerenciamento acessam os elementos de rede para obter a informação desejada ou
para mudar uma variável. Nesse caso estará sendo realizada uma operação de polling.
O agente é um componente que pode ser implementado em hardware ou em
software. O que ele realiza na verdade é coletar dados de um dispositivo e armazená-los na
MIB.
No SNMP, as informações são trocadas entre os gerentes e agentes na forma de
mensagens. Cada mensagem possui duas partes, um cabeçalho e uma PDU (Protocol Data
12
Unit). O formato geral de uma mensagem SNMP pode ser visualizado na Figura 2.3.
Version
Community
PDU SNMP
Mensagem SNMP
PDU-type
Request-id
0
0
Variable-bindings
Get PDU, Set PDU
PDU-type
Request-id
Variable-bindings
Response PDU
TimePDU-type
Enterprise
Agent-addr
Generic-trap
Specific-trap
stamp
Variable-bindings
...
NomeN
ValorN
Trap PDU
Nome1
Valor1
Nome2
Valor2
Variable-bindings
Figura 2.3 - Formato de mensagem SNMP [Messias, 2005]
• version - Indica a versão do protocolo SNMP utilizado.
• community - O nome de comunidade atua como uma senha para autenticar a
mensagem SNMP.
• PDU SNMP - É a unidade de dados de protocolo, PDU, utilizada pelo SNMP.
Contém os dados referentes à operação desejada (Get, Set, etc) [Messias, 2005].
2.4 BASE DE DADOS MIB
A MIB é o conjunto dos objetos acessados pelo SNMP, que procura abranger todas
as informações necessárias para a gerência da rede. O conjunto de todos os objetos SNMP é
coletivamente conhecido como MIB.
Um dos fatores mais importantes em sistema de gerenciamento de uma rede é a
forma como as informações sobre os elementos de rede estão armazenadas. Tais informações
precisam estar disponíveis segundo um determinado padrão para que possam ser reconhecidas
e utilizadas por qualquer aplicação.
Os objetos são imagens virtuais dos elementos básicos que se quer gerenciar. Um
objeto gerenciado é a visão abstrata de um recurso real do sistema. Assim, todos os recursos
13
da rede que devem ser gerenciados são modelados, e as estruturas dos dados resultantes são os
objetos gerenciados [Messias, 2005].
Segundo [Messias, 2005], até o presente momento, foram definidos, basicamente,
quatro tipos de MIBs que são: a MIB I, a MIB II, a MIB experimental e a MIB privada,
descritas a seguir:
• MIB I - As MIBs do tipo I fornecem informações gerais sobre os elementos da
rede, sem levar em conta as características específicas dos equipamentos.
• MIB II ou MIB Padrão - é considerada uma evolução da MIB I, fornece 21
informações gerais de gerenciamento sobre um determinado equipamento
gerenciado. É possível através das MIBs I e II obter informações como tipo e
status da interface (Ethernet, FDDI, ATM), número de pacotes transmitidos,
número de pacotes com erro, endereço IP das rotas, etc. Possui um conjunto de
objetos bem definidos, conhecidos e aceitos pelos grupos e padrões Internet;
• MIB Experimental – são aquelas em que seus componentes (objetos) estão em
fase de desenvolvimento e teste. Em geral, as MIBs experimentais fornecem
características mais específicas sobre a tecnologia dos meios de transmissão e
equipamentos empregados. Estas MIBs podem conter informações específicas
sobre outros elementos da rede e gerenciamento de dispositivos que são
considerados importantes.
• MIB Privada - As MIBs privadas ou proprietárias foram elaboradas com o
objetivo de atuar sobre um equipamento em específico, possibilitando que detalhes
característicos do mesmo possam ser obtidos. Desta forma, é possível obter
informações sobre colisões, configuração, swap de portas, e muitas outras, de um
roteador. Também é possível fazer testes, reinicializar ou desabilitar uma ou mais
portas do roteador através das MIBs privadas.
No modelo SNMP, os recursos de uma rede são representados como objetos. Cada
objeto é, essencialmente, uma variável que representa um aspecto do dispositivo gerenciado.
Todos os objetos (variáveis) são armazenados na MIB.
14
2.4.1 Tipos de Objetos de uma MIB
Segundo [Messias, 2005], os objetos da MIB têm um tipo específico de valores. O
SNMP define vários tipos primitivos, como se segue:
• Tipo de Objetos de Texto - Define-se o tipo DisplayString que pode conter
informação textual arbitrária (normalmente para um máximo de 256 caracteres). O
texto deve conter somente caracteres de impressão. Exemplos deste tipo de objeto
incluem valores sysDescr e ifDescr. Este tipo de objeto é bastante utilizado nas
MIB.
• Tipo de Objetos Contadores - Define-se o tipo Counter que é um valor numérico
que só pode aumentar. Este é o tipo mais comum de objeto de SNMP na MIB
padrão e inclui objetos como ipInReceives, ipOutRequests, e snmpInPkts.
Contadores ultrapassam o valor máximo da variável, mas nunca podem ser
negativos.
• Tipo de Objetos de Medida - Define-se o tipo Gauge que é um valor numérico o
qual pode aumentar ou pode diminuir. Este tipo é encontrado em apenas algumas
localizações dentro da MIB padrão. Exemplos deste tipo de objeto incluem o
objeto tcpCurrEstab.
• Tipo de Objetos Inteiros - Define-se o tipo Integer que pode conter valores
positivos ou negativos. Este valor normalmente é fornecido por valores de tipo
Counter ou Gauge, mas às vezes é expresso em MIB de equipamentos de
fabricantes.
• Tipo de Objetos Enumerados - Define-se um tipo Enumerated Value que associa
um campo textual com um valor numérico. Este tipo é bastante comum na MIB
padrão e inclui objetos como ifAdminStatus, cujo valores enumerados, são up(1),
down(2), e testing(3). Geralmente os valores enumerados são formatados da
seguinte forma: nome (número).
15
• Tipo de Objetos Tempo - Define-se um tipo TimeTicks que representa um tempo
decorrido. Este tempo sempre tem uma resolução de um centésimo de segundo, até
mesmo quando esta resolução não é usada. Administradores de rede
freqüentemente formatam este valor de tempo como HH:MM:SS para exibição.
Por exemplo, o valor sysUp-Time indica o tempo decorrido desde que um
dispositivo foi reiniciado.
• Tipo de Objetos Object - Define-se um tipo Object que pode conter o
identificador para outro objeto SNMP. Se o objeto nomeado é compilado na MIB,
o nome geralmente é apresentado com o mesmo nome no objeto SNMP. Um
exemplo deste tipo de objeto é a variável sysObjectID da MIB.
• Tipo de Objetos Endereço IP - Define-se um tipo IP address, que contém o
endereço IP de um dispositivo de rede. Este tipo de objeto é exibido
freqüentemente como um endereço IP convencional. Exemplos deste tipo de
objeto incluem ipRouteDest, ipRouteNextHop e ipRouteMask.
• Tipo de Objetos Endereço Físico - Define-se um tipo Physical address, que
contém o endereço físico de um dispositivo de rede. Gerentes exibem
freqüentemente este tipo de objeto como uma sucessão de valores hexadecimal,
precedidos pela palavra-chave hex:, separados através de dois pontos. Exemplos
deste tipo de objeto incluem o objeto ifPhysAddress.
• Tipo de Objetos String - Define-se um tipo String, que contém uma cadeia de
caracteres arbitrários. Quando a cadeia de caracteres contém só caracteres ASCII
(American Standard Code for Information Interchange), os gerentes exibem este
valor como uma string de texto. Caso contrário, gerentes exibem este tipo como
uma sucessão de valores hexadecimal, precedidos pela palavra-chave hex:, e
separados através de dois pontos. Este tipo de valor é incomum, mas
ocasionalmente encontrado em MIB proprietárias.
• Tipo de Objetos Tabela - O tipo Table é um objeto que contém entradas da
tabela. Este tipo de objeto sempre é um nome intermediário que contém um
16
diretório de Entrada e que contém vários objetos da tabela.
• Tipo de Objetos Auxiliares - O tipo Branch é um objeto que contém tipos
adicionais, tabelas, ou qualquer tipo de objeto listado anteriormente.
2.4.2 Estrutura Lógica da MIB
A árvore hierárquica, mostrada na figura 2.4, definida pela ISO, representa a
estrutura lógica da MIB, mostra o identificador e o nome de cada objeto [Messias, 2005]:
O nó raiz da árvore MIB não possui rótulo, mas possui pelo menos três subníveis,
sendo eles:
• Nó 0 - administrado pela CCITT (Consultative Committe for International
Telegraph and Telephone), atualmente ITU-T (International Telecommunication
Union - Telecommunications);
• Nó 1 - que é administrado pela ISO;
• Nó 2 - que é administrado em conjunto pela CCITT e pela ISO. Sob o nó ISO fica
o nó que pode ser utilizado por outras instituições: o org (3), abaixo dele fica o
DOD (6), que pertence ao departamento de defesa dos EUA. O Departamento de
Defesa dos EUA alocou um sub-nó para a comunidade Internet, que é
administrado pela IAB (International Activities Board) e abaixo deste nó tem-se,
entre outros, os nós: management, experimental e private. Sob o nó management
ficam as informações de gerenciamento, é sob este nó que está o nó da MIB II.
Sob o nó experimental estão as MIBs experimentais. Sob o nó private fica o nó
enterprises e sob este nó ficam os nós das indústrias de equipamentos.
17
Figura 2.4 - Árvore MIB [Messias, 2005].
Como exemplo de um objeto, pode-se citar o ipInReceives pertencente ao grupo IP:
• ipInReceives Object Type
• Object Identifier: 1.3.6.1.2.1.4.3
• Access: read-only
• Syntax: Counter32
• Description: O número total de datagramas que chegam às interfaces, incluindo
aqueles com erro.
Conforme se observa na figura 2.5, a MIB II é organizada a partir do nó mgmt
(management). Abaixo da subárvore MIB II estão os objetos usados para obter informações
específicas dos dispositivos da rede. Esses objetos estão divididos em 10 grupos, os quais
estão listados na tabela 2.1.
18
ISO.ORG.DOD.INTERNET.MGMT
(1.3.6.1.2)
MIB II (1)
System (1)
AT (3)
IP (4)
ICMP (5)
TCP (6)
UDP (7)
EGP (8)
SNMP (11)
Transmissão (10)
Interfaces (2)
Figura 2.5 - MIB II [Messias, 2005].
GRUPO
INFORMAÇÃO
System (1)
Informações básicas do sistema
Interfaces (2)
Interfaces de rede
AT (3)
Tradução de endereços
IP (4)
Protocolo IP
ICMP (5)
Protocolo ICMP
TCP (6)
Protocolo TCP
UDP (7)
Protocolo UDP
EGP (8)
Protocolo EGP
Transmissão (10)
Meios de transmissão
SNMP (11)
Protocolo SNMP
Tabela 2.1 - Grupos da MIB II [Messias, 2005].
2.4.3 Exemplo dos Grupos da MIB II
Conforme [Messias, 2005], alguns dos objetos pertencentes aos grupos da MIB II,
tais como: Grupo System, Grupo Interfaces, Grupo IP, Grupo ICMP, Grupo TCP, Grupo UDP
e Grupo SNMP são descritos a seguir.
2.4.3.1.
Grupo System
Este grupo é identificado pela MIB através do código 1.3.6.1.2.1.1, e sua função é de
19
definir uma lista de objetos pertencentes à operação do sistema, como o tempo de
funcionamento, contato e nome do sistema:
• sysDescr (1.3.6.1.2.1.1.1): Descrição textual da unidade. Podem-se incluir o nome
e a versão do hardware, sistema operacional e o programa de rede;
• sysUpTime (1.3.6.1.2.1.1.3): Tempo decorrido (em milhares de segundos) desde a
última reinicialização do gerenciamento do sistema na rede;
• sysContact (1.3.6.1.2.1.1.4): Texto de identificação do gerente da máquina
gerenciada e como contatá-lo.
2.4.3.2.
Grupo Interfaces
Este grupo é identificado pela MIB através do código 1.3.6.1.2.1.2, e sua função é de
rastrear o status de cada interface em uma entidade gerenciada. O grupo interfaces gerencia as
interfaces em funcionamento ou inativas e rastreia aspectos, como octetos enviados e
recebidos, erros e eliminações. Utiliza os seguintes comandos:
• ifNumber (1.3.6.1.2.1.2.1): Número de interfaces de rede (não importando seu
atual estado) presentes neste sistema;
• ifOperStatus (1.3.6.1.2.1.2.2.1.8): Estado atual da interface;
• ifInOctets (1.3.6.1.2.1.2.2.1.10): Número total de octetos recebidos pela interface.
2.4.3.3.
Grupo IP
Este grupo é identificado pela MIB através do código 1.3.6.1.2.1.4, e sua função é de
rastrear os diversos aspectos do IP, incluindo o roteamento do IP. Utiliza os seguintes
comandos:
• ipForwarding (1.3.6.1.2.1.4.1): Indica se esta entidade é um gateway;
• ipInReceives (1.3.6.1.2.1.4.3): Número total de datagramas recebidos pelas
interfaces, incluindo os recebidos com erro;
• ipInHdrErrors (1.3.6.1.2.1.4.4): Número de datagramas que foram recebidos e
descartados devido a erros no cabeçalho IP.
2.4.3.4.
Grupo ICMP
Este grupo é identificado pela MIB através do código 1.3.6.1.2.1.5, e sua função é de
20
rastrear aspectos como erros do ICMP. Utiliza os seguintes comandos:
• icmpInMsgs (1.3.6.1.2.1.5.1): Número total de mensagens ICMP recebidas por
esta entidade. Incluindo aquelas com erros.
• icmpOutMsgs (1.3.6.1.2.1.5.14): Número total de mensagens ICMP enviadas por
esta entidade. Incluindo aquelas com erros.
2.4.3.5.
Grupo TCP
Este grupo é identificado pela MIB através do código 1.3.6.1.2.1.6, e sua função é de
rastrear entre outros aspectos, o estado das conexões TCP (como closed, listen, sysSent, etc).
Utiliza os seguintes comandos:
• tcpMaxConn (1.3.6.2.1.6.4): Número máximo de conexões TCP que esta entidade
pode suportar.
• tcpCurrentEstab (1.3.6.2.1.6.9): Número de conexões TCP que estão como
estabelecidas ou à espera de fechamento.
• tcpRetransSegs (1.3.6.2.1.6.12): Número total de segmentos retransmitidos.
2.4.3.6.
Grupo UDP
Este grupo é identificado pela MIB através do código 1.3.6.1.2.1.7, e sua função é de
rastrear dados estatísticos do UDP. Utiliza os seguintes comandos:
• udpInDatagrams (1.3.6.1.2.1.7.1): Número total de datagramas UDP entregues aos
usuários UDP.
• udpNoPorts (1.3.6.1.2.1.7.2): Número total de datagramas UDP recebidos para os
quais não existia aplicação na referida porta.
• udpLocalPort (1.3.6.1.2.1.7.5.1.2): Número da porta do usuário UDP local.
2.4.3.7.
Grupo SNMP
Este grupo é identificado pela MIB através do código 1.3.6.1.2.1.11, e sua função é
de avaliar o tráfego SNMP. Utiliza os seguintes comandos:
• snmpInPkts (1.3.6.1.2.1.11.1): Número total de mensagens recebidas pela entidade
SNMP.
• snmpOutPkts (1.3.6.1.2.1.11.2): Número total de mensagens enviadas pela
21
entidade SNMP.
• snmpInTotalReqVars (1.3.6.1.2.1.11.13): Número total de objetos da MIB que
foram resgatados pela entidade SNMP.
2.4.4 Compilador de MIBs
Um compilador de MIBs é um programa script, em uma linguagem qualquer, que
percorre um arquivo contendo uma MIB e gera um esqueleto em C contendo um arquivo
header que pode ser usado como base para a implementação do modulo, que depois de
editado é recompilado, permitindo que o agente SNMP suporte a nova MIB. Possibilitando
fazer com que as informações sobre os objetos gerenciados das MIBs privadas ou de novas
MIBs que sejam padronizadas estejam disponíveis para uma aplicação de gerenciamento
existente.
Uma MIB pode ser compilada por um compilador de MIBs de forma que as
informações presentes na MIB estejam disponíveis para aplicações como MIB browsers e
graphers. São aplicações simples que obtém toda a sua capacidade de gerenciamento através
da análise de uma MIB, sem intervenção humana [Messias, 2005].
A entrada para um compilador de MIBs é uma coleção de módulos de MIBs escritos
em um subconjunto da linguagem ASN.1 (Abstract Syntax Notation One). Estes módulos
contêm definições de objetos gerenciados que correspondem às informações sobre os
dispositivos da rede que podem ser manipulados através do protocolo SNMP. Os
compiladores de MIBs podem gerar várias representações das definições dos objetos
gerenciados contidos nas MIBs usadas como entrada. Estas representações podem ser
processadas mais facilmente pelos agentes e aplicações de gerenciamento do que a
representação ASN.1.
Algumas destas representações são declarações de estruturas de dados em
linguagens de programação de alto nível, como C, que podem ser compiladas e ligadas em
uma aplicação de gerenciamento ou agente. Outras são arquivos de dados contendo
representações das definições dos objetos gerenciados que podem ser lidas para a memória
por uma aplicação de gerenciamento ou agente em tempo de execução. Em alguns casos, o
compilador de MIBs gera um código de saída que auxilia na implementação das MIBs de
entrada. Por exemplo, um compilador de MIBs pode gerar esqueletos de rotinas para a
22
recuperação ou alteração do valor de um objeto gerenciado, ou rotinas para a geração de
Trap-PDUs (Protocol Description Unit) específicas [Messias, 2005].
A habilidade de reconhecer as descrições presentes em uma MIB mecanicamente é
muito atraente, principalmente para os fabricantes de aplicações genéricas, pois estas podem
cobrir uma grande variedade de agentes de MIBs. Com o grande número de MIBs
padronizadas e MIBs proprietárias disponíveis atualmente, os compiladores de MIBs reduzem
o esforço dos fornecedores para manterem suas aplicações atualizadas.
Atualmente os programas de gerenciamento apenas se limitam a coletar e exibir
informações sobre os elementos da rede sem, entretanto, analisá-las. Assim, o papel de
compreender o estado atual da rede e de encontrar soluções para os problemas cabe ao
administrador dessa rede. Esse aspecto dificulta muito a compreensão de MIBs desconhecidas
relativas a um dispositivo desconhecido [Messias, 2005].
2.5FERRAMENTAS PARA O GERENCIAMENTO DE REDES
Atualmente existem diversas ferramentas capazes de fazer esse tipo de
gerenciamento como, por exemplo, NAGIOS, ZABBIX e OpenNMS. Que serão apresentadas
nesse trabalho, mostrando uma visão geral de cada uma dessas ferramentas, por se tratar de
soluções com softwares livres, gratuitos, sob a licença GPL ou Licença Pública Geral,
possuindo muitos recursos.
2.5.1 NAGIOS
NAGIOS é um software de gerenciamento de rede, de código aberto e licenciado
pelo sistema GPL, com uma interface web amigável, conforme ilustrado na figura 2.6. Pode
gerenciar tanto hosts quanto serviços conforme mostra a figura 2.7, alertando-o quando
ocorrerem problemas e também quando os problemas forem resolvidos.
O NAGIOS foi criado em 14 de Março de 1999, originalmente sob o nome de
Netsaint (NetSaint Network Monitor). Foi escrito e é atualmente mantido por Ethan Galstad.
Por ser de código aberto, conta com um grande número de desenvolvedores, espalhados por
todo planeta, o que lhe possibilita manter e atualizar os plugins oficiais e não-oficiais (não
homologados). Dentre os principais colaboradores estão: Karl DeBisschop, Felipe Almeida,
23
Subhendu Ghosh, Ton Voon e Stanley Hopcroft, entre outros [NAGIOS,2006].
Essa ferramenta possui muitos recursos, tais como:
•
Gerencia serviços de rede (SMTP, POP3, HTTP, NNTP, ICMP, SNMP)
•
Gerencia recursos de computadores ou equipamentos de rede (carga do
processador, uso de disco, logs do sistema) na maioria dos sistemas operacionais
com suporte a rede, mesmo o Microsoft Windows com o plugin NRPE_NT.
•
Gerenciamento remoto suportado através de túneis encriptados SSH ou SSL.
•
Desenvolvimento simples de plugins que permite aos usuários facilmente criar
seus próprios modos de gerenciamento dependendo de suas necessidades, usando a
ferramenta de desenvolvimento de sua escolha (Bash, C, Perl, Python, PHP, C#,
etc.).
•
Checagem dos serviços paralelizados, ou seja, se você tiver muitos ítens
gerenciados não há risco de alguns deles não serem checados por falta de tempo.
•
Capacidade de definir a rede hierarquicamente definindo equipamentos "pai",
permitindo distinção dos equipamentos que estão indisponíveis daqueles que estão
inalcançáveis.
•
Capacidade de notificar quando um serviço ou equipamento apresenta problemas e
quando o problema é resolvido (via e-mail, pager, SMS, ou qualquer outro meio
definido pelo usuário por plugin).
•
Capacidade de definir tratadores de eventos que executam tarefas em situações
pré-determinadas ou para a resolução pró-ativa de problemas.
•
Rotação automática de log.
•
Suporte para implementação de gerenciamento redundante.
•
Excelente interface web para visualização do atual status da rede, notificações,
histórico de problemas, arquivos de log, etc [wikipedia, 2006].
O NAGIOS faz uso de tratadores de eventos para corrigir e resolver
24
automaticamente um problema como reiniciar o servidor web, caso ele não esteja
respondendo, gerencia carga em processador, uso de disco ou memória, possibilita
desenvolvimento de plugins customizados, possui interface web para visualizar todo o
processo de gerenciamento. Tratadores de eventos são uma série de ações pré-determinadas
que serão tomadas em caso de falhas. Quando o NAGIOS detecta uma falha em algum
cliente, ele segue uma lista de ações a serem tomadas, que vão de uma simples mensagem de
texto até mesmo, em casos mais graves, reinicialização do servidor.
Os plugins são extensões do browser, fornecidas pelo fabricante ou empresas
parceiras que fornecem recursos adicionais (por exemplo, de multimídia), facilitando a
visualização de textos, som, vídeo, etc. e maior interação com o usuário. Nesse caso, serão
para atribuir novas funções à ferramenta que não possua em sua configuração anterior.
Figura 2.6 – Tela principal do NAGIOS (traduzida para o português) [NAGIOS, 2006]
O NAGIOS pode ser executado em sistemas operacionais Unix e a visualização
gráfica pela web mais interessante é o Servidor de web Apache [Apache, 2006], conforme
observa-se na figura 2.6, pode-se restringir o acesso por IP, configuração de períodos de
tempo onde se pode determinar o horário de funcionamento da secretaria ou do suporte, por
25
exemplo, capaz de fazer agrupamento dos computadores em grupos específicos e gerenciar
serviços específicos nos grupos.
É possível, no gerenciamento, fazer a distinção se o problema está ocorrendo porque
o serviço está inoperante, se simplesmente, o computador parou de funcionar, conforme
observa-se na figura 2.7, Caso não haja resposta do funcionamento do serviço é enviado uma
mensagem ICMP (Internet Control Message Protocol) para o computador para saber se o
mesmo está ativo.
No caso em que existem roteadores ou firewall, entre o cliente remoto e o gerente de
gerenciamento, será feita uma análise pela árvore de dependência até chegar ao topo, ou até
um dos nós pai responder à mensagem ICMP. O NAGIOS descobrirá se o problema é com a
rede (computer UNREACHABLE), com o serviço do computador checado, e até mesmo se o
problema está nos roteadores.
Figura 2.7 – Tela do gerenciamento de falhas de serviços [NAGIOS, 2006]
Diversas formas de notificação podem ser utilizadas pelo NAGIOS como e-mail,
pager, celular, PopUp e alertas sonoros [Machado, 2006].
26
2.5.2 OpenNMS
O OpenNMS é uma ferramenta de software livre, escrita em Java. Essa ferramenta
suporta apenas Sistemas Operacionais Unix, tais como: RedHat, Mandrake, Solaris, Debian e
Suse.
A ferramenta OpenNMS possui um projeto de rede voltado principalmente para a
camada de aplicação HTTP (Hypertext Transfer Protocol), FTP (File Transfer Protocol),
DNS (Domain Name Service), POP (Post Office Protocol) e SMTP (Simple Mail Transfer
Protocol), mas suporta também outros serviços tais como bancos de dados: Oracle,
SQLServer, MySQL e PostgreSQL.
A tela principal, conforme mostra a figura 2.8, apresenta a interface com o usuário
que pode ser feita via web, possibilitando o acesso de qualquer ponto da rede ou fora dela,
para o acompanhamento do estado dos serviços, interface da rede, disponibilidade dos
serviços, gráficos de desempenho e informações de equipamentos. Pode-se ainda realizar
algumas configurações, tais como: a criação/alteração/exclusão de usuários e grupos,
notificações, processos de escalada, habilitar/desabilitar o gerenciamento de serviços e
interfaces, definir os serviços a serem gerenciados e solicitar a emissão de relatórios.
Figura 2.8 – Tela principal do OpenNMS [OpenNMS, 2006]
A necessidade de desabilitar o gerenciamento dos serviços na rede se justifica,
devido a manutenções que estejam sendo realizadas na rede, realização de aplicações que são
incomuns de serem realizadas na rede (como por exemplo, migração ou atualização de
27
sistema).
Essa ferramenta possibilita que, ao se fazer uma configuração dos endereços IP da
rede, a partir dessa lista, faça uma varredura na rede buscando os serviços associados (HTTP,
FTP, DNS, POP, SMTP e etc), esse processo de varredura pode ser re-executado a cada 24hs,
ou quando o administrador da rede achar necessário.
As principais vantagens da ferramenta OpenNMS são:
•
Configurar comandos, tais como: notificações automáticas e execução de
comandos para serem executados de acordo com a ocorrência de eventos.
•
As notificações automáticas podem ocorrer por meio do envio de e-mail ou
SMS para usuários ou grupos, de acordo com as necessidades préestabelecidas pelo administrador da ferramenta.
•
É possível definir um calendário com a escala dos funcionários que estão
de plantão ou de serviço no horário em que ocorre a falha para que o
mesmo possa ser notificado.
As principais desvantagens da ferramenta OpenNMS são:
•
Por ser uma ferramenta open-source, traz a vantagem de possuir
flexibilidade de suas configurações e armazena suas informações na base
de dados SQL. No entanto, tem a desvantagem de não disponibilizar um
guia de orientação ao usuário, o que dificulta o aprendizado de suas
diversas funcionalidades. Além disso, esta solução de gerenciamento não
permite uma evolução, no que diz respeito a serviços monitorados,
reconhece apenas os serviços nativos a sua construção original [Oyama,
2002].
2.5.3 ZABBIX
O ZABBIX também é uma ferramenta de gerência de redes de computadores, de
valor gratuito. Surgiu em 2001, implementada pelo programador Alexei Vladishev.
28
Esta solução oferece características avançadas de gerenciamento, alertas e interface
gráfica bastante simplificada, o que a torna uma das mais completas ferramentas da categoria,
além de realizar as funções e operações das outras ferramentas citadas anteriormente.
O ZABBIX suporta a maioria dos Sistemas Operacionais (Unix, Windows e Novell),
suporte nativo ao SNMP, interface web, banco de dados MySQL e PostgreSQL e geração de
gráficos 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. Conforme mostrado na figura 2.9, pode-se ainda, fazer configurações
dos objetos gerenciados, execução de comandos para correção de falhas detectadas,
habilitação e desabilitação de componentes da rede.
Para a instalação do ZABBIX são necessárias, no mínimo, as seguintes ferramentas,
em termos de software: Servidor de web Apache, PHP (Hypertext Preprocessor), MYSQL ou
PostgreSQL. Em termos de hardware é necessário, no mínimo, 32 MB livres em disco rígido,
32 MB de memória principal e processador Intel Pentium® II 300 Mhz ou compatível.
É importante salientar que, a partir da versão 4.1.x, terá de ser testado sua
compatibilidade com o PHP-4 ou mesmo o PHP-5, Libnet e Net-SNMP.
O ZABBIX possui um grande potencial de evolução, sujeito à capacidade do
programador, que pode ser escrita em qualquer linguagem de programação. As notificações
das falhas no ZABBIX podem ocorrer por meio de SMS, e-mail e alertas sonoros, além de
executar comandos remotos, pré-definidos pelo administrador da ferramenta, com capacidade
de gerenciar até 5000 estações em tempo real [ZABBIX, 2006].
As vantagens do ZABBIX, frente a outros programas deste tipo, são:
Possui suporte SNMP nativo, ou seja, não precisa de um daemon de SNMP
operando na máquina para que ele mesmo funcione.
Toda a sua configuração é feita via interface web, gravando os dados no MySQL
ou PostgreSQL, tornando o mesmo mais amigável que seu concorrente direto, o
NAGIOS.
Possui portabilidade para os mais diversos sistemas operacionais da família
Unix, sendo também encontrado versões em Windows (para que se possa
gerenciar hosts Windows na rede).
Possui geração de gráficos on line, trabalhando em cima dos dados colhidos na
29
sua rede, assim, dá ao administrador a possibilidade de saber o SLA da sua rede.
As principais desvantagens do ZABBIX são:
A implementação do servidor de gerenciamento ZABBIX pode ser complexa
devido à instalação e configuração de seus pré-requisitos.
Faz muitos acessos ao banco de dados, com isso pode causar sobrecarga do link,
no caso do banco de dados estar em outro host.
Figura 2.9 – Tela do ZABBIX: Estrutura da rede [ZABBIX, 2006].
2.5.4 Comparação entre as principais ferramentas de gerenciamento
A Tabela 2.2 apresenta uma comparação entre as ferramentas de gerenciamento
pesquisadas nesse projeto, trazendo as suas principais características.
30
CARACTERÍSTICAS
FERRAMENTAS
NAGIOS
OpenNMS
ZABBIX
Sim
Sim
Sim
Sim
Não
Sim
Sim
Sim
Sim
MRTG
MRTG
RRDTool
Sim
Não
Sim
Não
Não
Sim
Permite configuração via web
Não
Sim
Sim
Possui suporte SNMP nativo (não possui
Não
Não
Sim
Software Gratuito
Realiza análise
de dependências de
serviços monitorados
Possui interface Web
Pacote para geração de gráficos dos
relatórios e mapas
Capacidade de solucionar problemas de
acordo com os alertas recebidos
Pode produzir gráficos de
tendências (previsão de problemas)
necessidade de instalar o pacote SNMP)
Tabela 2.2 - Comparação entre as ferramentas de gerenciamento mais atuais
Para um melhor entendimento da tabela, é importante conhecer os pacotes para
geração de gráficos RRDTool (Round Robin Database Tool) e MRTG (Multi Router Traffic
Grapher).
O RRDTool é uma ferramenta poderosa para gerenciamento de tráfego, que reduz
sensivelmente a carga gerada pelo gerenciamento para a exibição dos gráficos, o que
possibilita uma representação visual em tempo real do tráfego.
MRTG (Multi Router Traffic Grapher) é outra ferramenta para gerenciamento de
tráfego. Ela gera um relatório que é exibido em HTML com imagens. Foi desenvolvido
usando as linguagens de programação PERL e C. Pode ser instalado no sistema operacional
Linux ou Windows.
31
CAPÍTULO III
ANÁLISE DE REQUISITOS
3.1 INTRODUÇÃO
Este capítulo trata do levantamento e análise de requisitos, apresentando a situação
atual da rede da EMBRAPA Arroz e Feijão, os problemas atualmente enfrentados pelos
administradores da rede e uma proposta de solução (protótipo) para auxiliar na gerência de
serviços oferecidos pela empresa.
A seção 3.2 mostra a situação atual da rede de computadores da EMBRAPA Arroz e
Feijão. A seção 3.3 apresenta os problemas enfrentados atualmente a respeito de serviços de
rede. A seção 3.4 traz a proposta de solução a ser implantada na empresa.
3.2 SITUAÇÃO ATUAL DA REDE DE COMPUTADORES
A rede de computadores da empresa EMBRAPA Arroz e Feijão constitui-se de uma
rede TCP/IP, com links de fibra óptica multimodo interligando os diversos prédios da
empresa, e dentro de cada prédio, os equipamentos são interligados via cabo par trançado.
As descrições detalhadas dos equipamentos que compõem a rede, bem como os
equipamentos serão apresentadas nas seções seguintes.
Rede interna - A rede de computadores interna está dividida entre servidor DNS,
PDC, NFS e demais servidores, além dos clientes internos. O servidor DNS é uma máquina
SUN Ultra 10m. Os servidores da rede interna apresentam diferentes instalações, tais como:
FreeBSD, Linux, Plataforma Intel, Plataforma AMD64.
Os clientes da rede interna podem ter instalado um dos seguintes sistemas
32
operacionais: Windows 98, Windows 2000 e Windows XP.
Rede externa - A rede externa está dividida entre servidores para acesso público,
em uma DMZ (De-Militarized Zone) e um roteador/rádio externo. O servidor externo é uma
máquina Intel com o sistema operacional Linux instalado. O roteador/rádio é uma máquina
Intel, com o Linux e uma placa de rádio PCMCIA.
Firewall – O firewall, é uma máquina Intel Pentium III 800 MHz, com duas placas
de rede. Possui 512 MB de memória à 133 MHZ, HD (Hard Disk) de 15 GB. É através desse
servidor que se dá a interligação das duas redes, rede interna e rede externa como ilustra a
figura 3.1:
Figura 3.1 – Ilustração da estrutura de firewall utilizando uma rede DMZ
Com a instalação desse servidor filtrando os acessos de uma rede à outra, é garantido
certo nível de segurança e qualidade de serviço. A rede interna, basicamente provê serviços
para os usuários internos. O firewall, está ligado via cabo UTP/Categoria 6 diretamente ao
33
switch. O switch, por sua vez, está conectado ao roteador/rádio através de um cabo
UTP/Categoria 5.
Roteador/rádio - O roteador/rádio é uma máquina Intel, com o sistema operacional
Linux instalado e uma placa para acesso via ondas de rádio. Do roteador/rádio sai um cabo de
antena e interliga a rede da Embrapa à antena de rádio que é ilustrada na figura 3.2, por sua
vez, comunica-se com a antena de rádio do Campus II da UFG (Universidade Federal de
Goiás). Na antena da UFG está conectado, através de um cabo de antena, um roteador
conectado à RNP, disponibilizando assim, a Internet. O roteador/rádio conecta-se à RNP a
uma taxa de 8 MB para download e 4 MB para upload.
Figura 3.2 – Antena de rádio da EMBRAPA Arroz e Feijão
3.2.1 Especificação Técnica do Escritório Técnico
O Escritório Técnico é subdividido em quatro alas: A, B, C e D, contando com salas
de pesquisadores e laboratórios específicos. Nesse escritório está a sala de administração da
34
rede, juntamente com as estações e servidores, de onde se gerencia a rede interna, externa e o
firewall.
Segue as especificações técnicas dos equipamentos, conforme as respectivas Alas:
Ala A – Conforme a figura 3.3, existe um rack 12U, onde estão concentrados um
switch tipo II e dois PathPanels 24 portas/Categoria 5. Uma das portas do rack da
ala A é destinada à conexão com o rack da ala D. Um cabo UTP/Categoria 6 de 1
Gbps sai do rack da ala A e conecta-se à um cabo UTP/Categoria 5 de 100 Mbps,
que, por sua vez, conecta-se ao rack da ala D.
Figura 3.3 – Ala A
Ala B – Conforme a figura 3.4, há um rack 12U, onde estão concentrados um
switch tipo II e dois PathPanels
24 portas/Categoria 5. Uma das
portas do rack da Ala B é
destinada à conexão com o rack
da
Ala
D.
Um
cabo
UTP/Categoria 6 de 1 Gbps sai
do rack da ala B e conecta-se à
um cabo UTP/Categoria 5 de 100
Mbps, que, por sua vez, conectase ao rack da ala D.
Figura 3.4 – Ala B
35
Ala C – Na ala C, conforme mostra a figura 3.5, existe um rack 12U, onde estão
concentrados dois switches tipo II e dois PathPanels 48 portas/Categoria 5. Os
dois switches estão conectados entre si através de um cabo UTP/Categoria 6 de
1Gbps. Uma das portas do rack da ala C é destinada à conexão com o rack da ala
D. Um cabo UTP/Categoria 6 de 1 Gbps sai do rack da ala C e conecta-se a um
cabo UTP/Categoria 5 de 100 Mbps, que, por sua vez, conecta-se ao rack da ala D.
Figura 3.5 – Ala C
Ala D – Nesta Ala, conforme mostra a figura 3.6, existe um rack 40U, que
concentra um distribuidor óptico, um switch tipo I, dois módulos 1000BaseLX, 4
transceivers 100Base FX/100BaseT. Nesse rack há também um switch tipo II, um
switch tipo III, três PathPanels 24 portas/Categoria 5 e um PathPanel 24
portas/Categoria 6. Neste último PathPanel, conecta-se o cabo UTP/Categoria 5 de
100 Mbps que concentra os cabos vindos das alas A, B e C. Desse mesmo
PathPanel, sai um cabo UTP/Categoria 6 que, por sua vez, conecta-se ao firewall.
36
Figura 3.6 – Rack Ala D
3.2.2 Especificação do Setor de Serviços Auxiliares (SSA)
Equipamentos – No SSA existe um rack 24U, ilustrado na figura 3.7, onde estão
concentrados uma placa 3COM Superstack IIIc 16471 e quatro transceivers Planet
FT 801. No rack do SSA também existem dois distribuidores ópticos que estão
conectados entre si e na placa 3COM através de fibra óptica 100BaseFX. Do
primeiro distribuidor óptico saem 6 cabos de fibra óptica 100BaseFX para
conectarem-se aos equipamentos dos seguintes locais: laboratório de mecanização,
SMI, galpão, criação de insetos, casa de vegetação e distribuidor óptico da ala D.
Do segundo distribuidor óptico do SSA sai um cabo de fibra óptica 100BaseFX
para conectar-se ao transceiver localizado na garagem.
37
Figura 3.7 – Switches internos (SSA)
3.2.3 Especificação da Administração (ADM) / Chefia
Equipamentos – Na ADM existe um rack 40U, onde estão concentrados um
switch tipo II, um módulo 1000BaseLX e dois PatchPanels 24 portas/Categoria 5.
No switch da ADM está chegando uma fibra óptica 1000BaseLX, originada do
distribuidor óptico situado na ala D.
3.2.4 Especificação da Área de Comunicação Empresarial (ACE)
Equipamentos – Na ACE existe um rack 24U, onde estão concentrados dois
PatchPanels 24 portas/Categoria 5, um Planet SGSW 4802 e um módulo SGSWA1LX. No Planet da ACE está chegando uma fibra óptica 1000BaseLX, originada
do distribuidor óptico situado na ala D.
38
3.2.5 Especificação da ADM/Biblioteca
Equipamentos – Na Biblioteca existe um rack 10U, onde estão concentrados uma
placa 3COM Superstack IIIc 16471 e um transceiver Planet FT 801. No rack da
biblioteca chega uma fibra óptica 100BaseFX originada do distribuidor óptico
situado na ala D.
3.2.6 Especificação do Banco Ativo de Germoplasa (BAG)
Equipamentos – No BAG existe um rack 10U, onde estão concentrados um
Alliede AT-FH824u, um transceiver Planet FT 801 e um PatchPanel 24
portas/Categoria 5. No rack do BAG chega uma fibra óptica 100BaseFX originada
do distribuidor óptico situado na ala D.
3.2.7 Especificação da Casa de vegetação
Equipamentos – Na casa de vegetação chega uma fibra óptica 100BaseFX
originada do distribuidor óptico situado no rack do SSA.
3.2.8 Especificação do Laboratório de Mecanização
Equipamentos – No laboratório de mecanização existe um transceiver Planet FT
801. Nesse transceiver chega uma fibra óptica 100BaseFX originada do
distribuidor óptico situado no rack do SSA.
3.2.9 Especificação do Setor de Máquinas e Implementos Agrícolas (SMI)
Equipamentos – No SMI há um transceiver Planet FT 801. Nesse transceiver
chega uma fibra óptica 100BaseFX originada do distribuidor óptico situado no
rack do SSA.
3.2.10 Especificação do Galpão
Equipamentos – No galpão chega uma fibra óptica 100BaseFX originada do
distribuidor óptico situado no rack do SSA.
39
3.2.11 Especificação da Garagem
Equipamentos – Na garagem existe um transceiver Planet FT 801. Nesse
transceiver chega uma fibra óptica 100BaseFX originada do segundo distribuidor
óptico situado no rack do SSA.
3.2.12 Especificação da Criação de Insetos
Equipamentos – Na área de criação de insetos chega uma fibra óptica 100BaseFX
originada do distribuidor óptico situado no rack do SSA.
3.2.13 Especificação dos Alojamentos
Equipamentos – Nos alojamentos existe um rack 10U, onde estão concentrados
um Alliede AT-FS708 e um transceiver Planet FT 801. No rack dos alojamentos
chega uma fibra óptica 100BaseFX originada do distribuidor óptico situado na ala
D.
3.2.14 Especificação técnica dos equipamentos de rede
Atualmente, a rede de computadores da EMBRAPA Arroz e Feijão dispõe dos
seguintes equipamentos de rede:
3.2.14.1 Switch tipo I
Portas - Este switch é composto por 20 portas 10/100/1000BaseT, 4 portas GBIC
(SFP) e 1 porta serial RS-232 DB9;
Desempenho - possui capacidade de comutação de 80 Gbps e uma taxa de
forwarding de 80 Mbps;
Características da camada 2 (layer 2) – Possui negociação automática de
velocidade e modo duplex por porta (autosensing e auto-negotiation),
encaminhamento de pacotes baseado no esquema store-and-forward. O controle
de tráfego é baseado sobre IEEE 802.3x e Back-Pressure. Possui suporte ao
protocolo Spanning Tree Protocol (STP, RSTP e MSTP) e a 255 VLANs IEEE
40
802.1Q. Também suporta 6 Grupos de Trunk com até 8 Links cada. Contém
Multicast Sooping via IGMP v1 e v2 e tabela de endereços MAC com 16K;
Características da camada 3 (layer 3) - Suporta os protocolos: ARP, RIP v1 e v2 e
10 rotas estáticas;
Gerenciamento – O gerenciamento pode ser via Telnet, Web (HTTPS e HTTP),
RMON, SNMP v1,v2 e v3. Possui endereçamento IP via BOOTP e DHCP e
suporte a SNTP. Realiza Upload e Download de arquivos de configuração via
servidor TFTP;
Expansão – Faz empilhamento de até 8 equipamentos, com capacidade de 40 Gbps
de barramento e gerenciável com um único IP. Possui 1 slot de expansão para Link
de 10Gbps;
Segurança – Possui suporte aos protocolos: SSH v2 e SSL e filtragem de pacotes
com Lista de Controle de Acesso (ACL). Também suporta IEEE 802.1X e faz
autenticação via RADIUS.
3.2.14.2 Switch tipo II
Portas - Este switch é composto por 48 portas 10/100BaseT e 2 portas GBIC
(SFP);
Desempenho - possui capacidade de comutação de 12.8 Gbps;
Características da camada 2 (layer 2) – Possui negociação automática de
velocidade e modo duplex por porta (autosensing e auto-negotiation),
encaminhamento de pacotes baseado no esquema store-and-forward. O controle
de tráfego é baseado sobre IEEE 802.3x e Back-Pressure. Possui suporte ao
protocolo Spanning Tree Protocol (STP, RSTP e MSTP) e a 255 VLANs IEEE
802.1Q. Também suporta 4 Grupos de Trunk com até 8 Links cada. Contém
Multicast Sooping via IGMP v1 e v2 e tabela de endereços MAC com 8K;
Gerenciamento – O gerenciamento pode ser via Telnet, Web (HTTPS e HTTP),
RMON, SNMP v1 e v2. Possui endereçamento IP via BOOTP e DHCP e suporte a
SNTP. Realiza Upload / Download de arquivos de configuração via servidor
TFTP;
Expansão – Faz empilhamento de até 8 equipamentos, gerenciável com um único
IP;
Segurança – Possui suporte aos protocolos: SSH v2 e SSL e filtragem de pacotes
41
com Lista de Controle de Acesso (ACL). Também suporta IEEE 802.1X e faz
autenticação via RADIUS.
3.2.14.2 Switch tipo III
Portas - Este switch é composto por 12 portas 10/100BaseT;
Desempenho - possui capacidade de comutação de 3.2 Gbps;
Características da camada 2 (layer 2) – Possui negociação automática de
velocidade e modo duplex por porta (autosensing e auto-negotiation),
encaminhamento de pacotes baseado no esquema store-and-forward. Possui tabela
de endereços MAC com 2 K;
Gerenciamento – O gerenciamento pode ser via Telnet, Web (HTTPS e HTTP),
RMON, SNMP v1 e v2.
3.2.14.3 Módulo 1000/BaseLX
Características - Módulo SFP 1000BaseLX para os switchs tipo I e II. Dispõe de 1
Porta 1000BaseLX, compatível com 802.3 e conector de fibra LC.
3.2.14.4 Módulo Planet SGSW-A1LX
Características - Módulo SFP para switch Planet SGSW-4802.
3.2.14.5 Transceiver 100BaseFX/100BaseTX
Características – É compatível com 802.3 10/100Base-Tx e 100Base-Fx standart.
Possui 1 conector de fibra SC e 1 conector UTP. Dispõe de Auto-sensing para
half/full duplex, que faz a escolha entre os modos de comunicação
automaticamente, auto-negotiation para taxa de 10/100Mbps e Auto-MDIX para
Tx porta. Possui também leds indicadores para fácil gerenciamento de rede ativa.
3.2.14.6 Placa de rede 1000BaseT
Características – Possui auto-negociação 10/100/1000 Mbps e barramento interno
42
de 32-bit 33/66 MHz PCI. Dispõe de drivers para Microsoft Windows XP,
Windows-64 XP, Linux 2.2/2.4/-64 (Red Hat, Caldera, TurboLinux, SuSE). Possui
os seguintes LEDs: Link activity, 10 Mbps, 100 Mbps, 1000 Mbps.
3.2.14.7 Patch Panel 24 portas
Características – Possui 24 tomadas RJ-45 1000BaseT, IEEE 802.3, categoria 6,
no tamanho padrão de 19”, de modo a ser fixado diretamente no rack, tipo engate
rápido.
3.2.14.8 Patch Panel 48 portas
Características - Possui 48 tomadas RJ-45, 100BaseT IEEE 802.3, categoria 5e, no
tamanho padrão de 19”, de modo a ser fixado diretamente no rack, tipo engate
rápido.
3.2.14.9 Rack 10U
Características - Rack de parede, padrão 19”. Medidas (altura x profundidade x
largura) de 10U x 61 cm x 19 “ aproximadamente (1 U = 44,45 mm), porta frontal
de acrílico. Possui par de barras de fixação de acessórios, par de réguas de fixação
de equipamentos, calha com tomadas para ligação dos equipamentos e painel de
alimentação AC com disjuntor geral de proteção.
3.2.14.10 Rack 12U
Características - Rack de parede, padrão 19”. Medidas (altura x profundidade x
largura) de 12U x 61 cm x 19 “ aproximadamente (1 U = 44,45 mm), porta frontal
de acrílico. Possui par de barras de fixação de acessórios, par de réguas de fixação
de equipamentos, calha com tomadas para ligação dos equipamentos, painel de
alimentação AC com disjuntor geral de proteção.
43
3.2.14.11 Switch KVM (Keyboard, video, mouse)
Portas - Este switch é composto por 16 portas para PCs e 1 porta de Console;
Desempenho – Possui Largura de Banda de 200MHz;
Características - Utiliza mouse e teclado PS/2, seleção de PCs, sem necessidade de
instalação de software, por: OSD, Hot key e Push Botton. Possui Modo Auto Scan
para gerenciamento de PCs, resolução VGA de 1920 x 1440 e Intervalo de scan de
5 até 99 segundos. O gabinete é metálico. Dispõe de 16 LEDs indicadores on-line
e 16 LEDs de seleção. Tem a capacidade de controlar até 128 PCs, conectando-se
a outros switches KVM (stackable). A instalação é feita em rack 19.
3.2.14.12 Cabo KVM – 5m
Características - Cabo padrão PS/2, com 5m de comprimento, para conexão de
teclado, mouse e monitor em Switches KVM. Contém em cada ponta um jogo de:
1 conector de teclado PS/2 (Mini DIN 6 pinos macho), 1 conector de mouse PS/2
(Mini DIN 6 pinos macho) e 1 conector de vídeo SVGA (HDDB 15 pinos macho).
3.2.14.13 Cabo KVM – 3m
Características - Cabo padrão PS/2, com 3m de comprimento, para conexão de
teclado, mouse e monitor em Switches KVM. Contém em cada ponta um jogo de:
1 conector de teclado PS/2 (Mini DIN 6 pinos macho), 1 conector de mouse PS/2
(Mini DIN 6 pinos macho) e 1 conector de vídeo SVGA (HDDB 15 pinos macho).
3.2.14.14 Adaptador PS/2 para teclado e mouse SUN
Características - Adaptador para conectar teclado e mouse de uma estação SUN
Enterprise Ultra 10 em um switch KVM PS2, compatível com o switch Planet
KVM-1600 ou similar. Acompanhado dos cabos necessários fonte de energia com
seleção automática de tensão (110~220V).
3.2.15 Especificação dos cabos e conectores
A seguir, serão especificados os cabos e conectores utilizados na rede da
44
EMBRAPA atualmente.
3.2.15.1 Tomadas RJ-45 tipo Puch Down
Características - Conector RJ-45 100BaseT IEEE 802.3 para categoria 5e.
Conector RJ-45 1000BaseT IEEE 802.3 para categoria 6. 8 vias, com vedação
contra umidade e poeira, porta etiqueta de identificação em acrílico e travamento
interno do cabo lógico, tipo engate rápido padrão IDC.
3.2.15.2 Conectores RJ-45 Macho
Características - Conector RJ-45 100BaseT IEEE 802.3 para categoria 5e.
Conector RJ-45 1000BaseT IEEE 802.3 para categoria 6, 8 vias.
3.2.15.3 Cabo UTP
Características - Padrão 100BaseT IEEE 802.3, para categoria 5e e 1000BaseT
IEEE 802.3 para categoria 6. Par trançado não blindado UTP, 24 AWG, 4 pares,
com certificado ISO 9000 e UL.
3.2.15.4 Cabos de comutação no Patch Panel (Patch Cable UTP)
Características - Padrão 100BaseT IEEE 802.3, para categoria 5e, e 1000BaseT
IEEE 802.2 para categoria 6, 8 vias, comprimento de 1 m. Dois conectores RJ-45
macho um em cada extremidade com capa protetora do conector contra esforço
mecânico.
3.2.15.5 Conectores ópticos
Características - Conector ótico SC tipo light crimp, para conectorização sem uso
de cola ou epóxi.
45
3.2.15.6 Cabo de fibra óptica
Características - Totalmente dielétrico, com fibras multimodo revestidas em
acrílico de material termoplástico. Interior do tubo preenchido por um composto
para evitar a penetração de umidade e garantir maior resistência mecânica,
inclusive protegendo contra ataque de roedores. Possui certificado ISO 9000 e UL.
3.2.15.7 Cabos de comutação no distribuidor óptico (Patch Cable óptico)
Características – Cabo construído com 1 cordão ótico flexível e dois conectores
óticos SC, tipo light crimp, comprimento de 1,5m.
Figura 3.8 – Fibras Ópticas
A rede interna possui um servidores internos e clientes internos, todos inteligados
por switches.
A rede externa possui um servidores para acessos externos e um roteador a rádio que
se conecta ao roteador a rádio da UFG, que por sua vez conecta-se ao roteador da RNP, o
provedor de acesso à internet.
A rede externa chama-se assim por se uma rede derivada do IP válido da
EMBRAPA Arroz e Feijão, enquanto que a rede interna não possui IP válido. O gateway
entre as redes é um servidor que faz a função de firewall e NAT.
46
3.3 LEVANTAMENTO DE REQUISITOS
Nas entrevistas efetuada na empresa, conforme Anexos B e C, foram abordados
diversos pontos relevantes para a elaboração desse projeto:
O sistema de gerência de rede de computadores deve ser grátis e compatível com o
sistema operacional FreeBSD;
Atualmente a rede de computadores não dispõe de qualquer sistema de gerência;
Os administradores da rede não possuem conhecimento a respeito de qualquer
sistema de gerencia de redes de computadores;
A rede possui vários serviços que são considerados críticos pelos administradores
e que necessitam de uma atenção especial. Os que foram citados como críticos
para o funcionamento da rede são: internet, e-mail, servidor de rede (Samba) e
LDAP;
A maioria dos problemas que causam interrupção, dos serviços da rede de
computadores, são resolvidos simplesmente reiniciando o serviço afetado.
3.4 PROPOSTA DE SOLUÇÃO
Após a realização da análise dos pontos positivos e negativos de cada ferramenta de
gerência de redes no capítulo II, conclui-se que a ferramenta ZABBIX é mais adequada para
as necessidades específicas do projeto a ser implementado na EMBRAPA Arroz e Feijão,
devido à sua compatibilidade com o FreeBSD, servidor de banco de dados MySQL e servidor
web Apache, existentes na rede de computadores atual, portanto, o protótipo será baseado
nesses servidores.
3.4.1. Protótipo da Proposta de Solução
Inicialmente será instalado um protótipo “piloto” dessa solução e serão efetuados
exaustivos testes e análises da ferramenta ZABBIX, simulando o ambiente de rede da
empresa. Uma vez comprovada a eficácia dessa ferramenta, com simulações de interrupção de
serviços de todos os tipos, ela poderá ser instalada e configurada de acordo com as
47
necessidades reais da empresa. A Figura 3.9 ilustra a proposta de solução a ser implantada na
empresa EMBRAPA Arroz e Feijão.
Esse protótipo será construído com recursos dos próprios autores desse protótipo.
Sendo que o servidor de monitoramento deverá ser um notebook da marca Toshiba, com um
processador AMD K6 II de 300Mhz, disco rígido de 4 GB, 64MB de memória principal. O
outro computador que será usado no protótipo será um computador HP Vectra, com um
processador Intel Pentium II 350Mhz, disco rígido de 6 GB, 320MB de memória principal,
ele será usado para simular os serviços de rede de computadores e também completa os
requisitos de software necessários para o funcionamento do sistema de gerência ZABBIX, tais
como: banco de dados, servidor web com suporte a PHP e PHP GD.
Figura 3.9 – Protótipo da solução
O protótipo foi projetado assim para reproduzir o ambiente de rede da empresa,
utilizando o mínimo de recursos, tornando-se menos oneroso em termos de hardware, e
necessitando de menos tempo para ser implementado.
48
CAPÍTULO IV
ZABBIX
4.1 INTRODUÇÃO
Este capítulo trata da ferramenta de gerência de redes de computadores, denominada
de ZABBIX, a qual foi escolhida, dentre as outras estudadas, para ser implementada na
EMBRAPA Arroz e Feijão, por ser adequada ao seu projeto.
A seção 4.2 traz as principais características da ferramenta ZABBIX. A seção 4.3
apresenta a estruturação da ferramenta ZABBIX. A seção 4.4 apresenta os requisitos de
software e hardware necessários para a implementação da ferramenta ZABBIX. A seção 4.5
apresenta o monitoramento de desempenho dos recursos de hardware. A seção 4.6 traz os
principais mecanismos de alertas suportados pela ferramenta. A seção 4.7 mostra a facilidade
da verificação de integridade de arquivos. A seção 4.8 mostra os benefícios dos serviços de
auditoria disponível na ferramenta. A seção 4.9 traz detalhes da geração de gráficos. A
capacidade de planejamento é apresentada na seção 4.10. A seção 4.11 define o que é acordo
de nível de serviço e mostra onde ele é aplicado na ferramenta ZABBIX. A seção 4.12 traz a
criação de grupos e modelos de configuração na ferramenta ZABBIX. Por fim, a seção 4.13
traz a possibilidade da execução de comandos remotos nos agentes gerenciados.
4.2 CARACTERÍSTICAS DO ZABBIX
O ZABBIX é uma ferramenta de gerência de redes de computadores que surgiu em
2001, desenvolvida pelo programador Alexei Vladishev. É capaz de fazer monitoramento
simples de serviços sem a utilização de agentes para isso. Permite criar configurações
49
customizadas para se adequar as necessidades de qualquer rede de computadores, o que
possibilita monitorar toda a infraestrutura de uma rede bem como suas aplicações [ZABBIX,
2006].
Esta solução é uma das mais completas ferramentas da categoria, pois oferece
características avançadas de gerenciamento, alertas e interface gráfica bastante simplificada.
As principais vantagens do ZABBIX é a capacidade monitorar, também, serviços de
hosts (memória, espaço em disco, carga de processamento, temperatura, etc.). Possui a
capacidade de gerenciar dispositivos que possuam o protocolo SNMP, suporta a maioria dos
Sistemas Operacionais (Unix, Windows, AIX, Novell e etc.), acesso a todas as configurações
via web, banco de dados MySQL, PostgreSQL e ORACLE, além da geração de gráficos em
tempo real. Em sua interface web é possível fazer o acompanhamento do desempenho
completo da rede e dos dispositivos gerenciados, verificando e monitorando o status dos
servidores, roteadores e conexões [ZABBIX, 2006].
No entanto, essa ferramenta apresenta algumas desvantagens, tais como, a
complexidade de instalação e configuração dos pré-requisitos necessários pra a
implementação do servidor de gerenciamento ZABBIX. O gerente faz muitos acessos ao
banco de dados, aumentando o tráfego da rede e a carga de processamento do servidor, o que
pode causar sobrecarga do link, no caso do banco de dados estar hospedado em outro host.
O ZABBIX suporta tanto o mecanismos de polling quanto o de trapping. Polling é a
comunicação do tipo “requisição/resposta”, onde o gerente faz a requisição e o agente
responde essa requisição. Trapping é a ação do próprio agente fazer a notificação ao gerente
quando uma condição anormal ocorre no sistema gerenciado. As traps são enviadas de modo
assíncrono, não aguardam uma consulta por parte do gerente. Ao se fazer uso do mecanismo
de trapping, ocorre uma significativa diminuição no número das mensagens trocadas entre
gerente e agente [Oyama, 2002], [Bianchini, 2003], [Oliveira, 2002].
4.3 COMPONENTES DA FERRAMENTA
O sistema de gerenciamento ZABBIX é composto por um software agente (cliente)
e um gerente (servidor). Essa arquitetura cliente-servidor facilita checagens ativas, ou seja,
permite que o agente presente no cliente possa enviar dados para o gerente sem que o mesmo
tenha solicitado. Com isso se tem menos trafego na rede.
50
4.3.1 Servidor ZABBIX
A parte principal do sistema de gerenciamento ZABBIX está no gerente. Ele é o
repositório central das informações, nele ficam contidas as configurações e informações
coletadas a partir do monitoramento de seus agentes. O servidor ZABBIX é responsável por
gerar os alertas a partir dos dados obtidos do monitoramento e notificar os administradores do
sistema toda vez que um determinado evento ocorra em um sistema monitorado [ZABBIX,
2006].
4.3.2 Agente ZABBIX
O ZABBIX possui um software que é instalado no dispositivo gerenciado para
monitorar recursos locais, aplicações e arquivos de configuração ou de logs. Este agente irá
coletar informações operacionais do sistema e informar esses dados ao servidor. Em caso de
condições anormais encontradas (tais como HD cheio ou alta carga de processamento), o
servidor ZABBIX pode imediatamente solicitar que o agente presente no dispositivo tome
uma ação para tentar corrigir a falha e alerta ao administrador que uma falha foi identificada.
Em dispositivos que não permitem que se instalem softwares, como impressoras,
nobreaks, hubs e roteadores, pode-se fazer o monitoramento usando checagens simples ou o
protocolo SNMP [ZABBIX, 2006].
4.3.3 Interface WEB
Para facilitar o gerenciamento dos dados coletados, criação de gráficos, mapas e
configurações. O ZABBIX oferece uma interface web onde, praticamente, toda configuração
que o gerente necessita para administrar a ferramenta se encontra. A interface web permite
que o gerente, ou qualquer outro usuário autorizado, acesse o ZABBIX de qualquer ponto da
rede ou internet, dependendo de sua estrutura disponível.
Para se ter acesso a interface web, é necessário que antes crie e configure os usuários
para acessá-la. Inicialmente apenas os usuários Admin e guest estão aptos a acessar o
sistema. No primeiro login, é recomendado que o gerente crie uma senha para o usuário
Admin e habilite os demais usuários para acessarem a ferramenta. A figura 4.1 mostra o
layout da interface web do ZABBIX. Pelo fato da interface ser desenvolvida em PHP e
51
HTML, ela pode ser customizada de acordo com as necessidades de cada ambiente [ZABBIX,
2006].
Figura 4.1 – Interface web do ZABBIX
4.4 REQUISITOS
Devido ao grande número de recursos e facilidades disponíveis na ferramenta de
gerenciamento ZABBIX, ele necessita de uma serie de serviços adicionais e bom suporte de
hardware para suprir todas as suas necessidades e garantir que o sistema funcione de forma
eficiente. Poder fornecer um bom histórico das informações coletadas, fornecerem uma
interface amigável e de possibilidade de acesso remoto [ZABBIX, 2006].
4.4.1 Requisitos de Hardware
A definição do servidor que terá o papel de gerente nesse sistema é que irá
determinar quais os recursos de hardware necessários para se implementar essa ferramenta e
seus requisitos. Por exemplo, se em uma rede bem estruturada, cada serviço provido aos
usuários fica hospedado em um servidor diferente, os recursos necessário para implementar o
52
ZABBIX serão mínimos. Pode se também configurar todos os serviços que o ZABBIX irá
utilizar em um mesmo servidor, com isso se ganha em disponibilidade e quando houver falha
em um servidor que hospede um serviço essencial para o funcionamento da ferramenta, o
sistema de gerenciamento não fica comprometido pela falha. Por isso que essa definição de
requisitos de hardware é bastante relativa.
Não se pode definir que uma determinada quantidade de memória ou de clock de
processador seja suficiente para implementar essa ferramenta em qualquer rede de
computadores, devido a infinidade de itens que podem ser monitorados. Outro ponto que se
deve ficar atento é quanto a quantidade de dispositivos, itens e intervalos entre as checagens,
porque elas podem gerar muito tráfego na rede e consumir muitos recursos dos dispositivos
gerenciados, tornando o gerenciamento caro e ineficiente [ZABBIX, 2006].
Seguindo a própria documentação do ZABBIX, pode se fazer uma ligeira
classificação de possíveis configurações de hardware necessárias, conforme ilustrado na
tabela 4.1:
Porte do
Plataforma
Processador
Gerenciamento
do gerente
(Intel)
Pequeno
Linux
Ubuntu
350MHz
Linux
Médio
Ubuntu 64
2400MHz
bits
Linux
Grande
Ubuntu 64
bits
Memória
256MB
Banco de
Dados
MySQL
MyISAM
2048MB
MySQL
(2GB)
InnoDB
Dual Core
4096MB
6400MHz
(4GB)
Quantidade de
Dispositivos
monitorados
20
500
MySQL
InnoDB Ou
>1000
PostgreSQL
Tabela 4.1 – Requisitos de Hardware [ZABBIX,2006]
4.4.2 Requisitos de Software
Diferentemente dos requisitos de hardware necessários para a implementação da
ferramenta de gerenciamento ZABBIX, os recursos de software são bem específicos.
Basicamente o ZABBIX, como a maioria das ferramentas concorrentes, necessita de um
banco de dados para guardar as informações coletadas, um servidor web bem configurado e
53
com suas respectivas dependências, para prover o acesso ao console da ferramenta, a
ferramenta Net-SNMP ou UCD-SNMP bem como algumas bibliotecas.
Nesta seção será apresentado cada pré-requisito com sua versão mínima para o
funcionamento da ferramenta atualmente.
Softwares necessários para a implementação do sistema de gerenciamento ZABBIX
versão 1.1.7:
•
Servidor Web: Apache versão 1.3.12 ou superior;
•
Linguagem PHP: PHP 4.3 ou superior (PHP 5 também é suportado) ;
•
Módulos do PHP:
o PHP-GD;
o PHP-BCMath;
o PHP-MySQL, PHP-PostgreSQL, PHP-SQLora8 ou PHP-SQLite3.
•
Servidor de banco de Dados:
o MySQL versão 3.22 ou superior;
o Oracle versão 9.2.0.4 ou superior;
o PostgreSQL versão 7.0.2 ou superior;
o QLite versão 3.3.5 ou superior.
•
Ferramenta FPing;
O sistema de gerenciamento ZABBIX suporta uma grande variedade de sistemas
operacionais, tanto como estações clientes quanto centrais de gerenciamento. O ZABBIX,
quanto gerente, foi testado nos seguintes sistemas operacionais [ZABBIX, 2006]:
•
AIX
•
FreeBSD
•
HP-UX
•
Linux
•
Mac OS/X
•
OpenBSD
•
SCO Open Server
•
Solaris
54
Os desenvolvedores da ferramenta de gerenciamento ZABBIX, disponibilizam
versões do cliente (agente) compiladas para os seguintes sistemas operacionais [ZABBIX,
2006]:
•
Debian;
•
FreeBSD;
•
HP-UX;
•
Linux SuSE;
•
Solaris 9;
•
OpenBSD;
•
Tru64/OSF1;
•
Ubuntu Linux;
•
Windows.
4.5 MONITORAMENTO DE DESEMPENHO
Uma das características mais importantes do ZABBIX é o monitoramento de
desempenho dos dispositivos de hardware. Ele é capaz de monitorar a quantidade de memória
utilizada e livre do sistema, quantidade de processos em atividade, utilização da CPU,
utilização da memória SWAP e atividades de leitura e escrita no disco rígido do sistema
monitorado.
A partir destes dados coletados, o ZABBIX é capaz de gerar gráficos de tendências,
que auxiliará os administradores da rede de computadores a tomarem decisões futuras, tais
como aumentar a capacidade de processamento de um servidor ou aumentar quantidade de
memória, por exemplo. Outro ponto forte no monitoramento de desempenho é ter dados
suficientes para saber se os recursos de hardware são os corretos para determinada aplicação.
Podendo assim distribuir melhor os recursos de hardware.
Estes são alguns dos inúmeros itens que o ZABBIX é capaz de monitorar, conforme
ilustra a figura 4.2:
55
Figura 4.2 – Monitoramento do host GERENTE.
4.6 MECANISMO DE ALERTA
Mecanismos de alertas é a forma como o sistema ZABBIX irá notificar os
administradores quando ocorrer algum evento que mereça uma atenção especial. O sistema
ZABBIX dispõem de várias formas de fazer isso, as maneiras mais comuns são enviando um
e-mail para os administradores, exibindo alertas visuais no console da ferramenta, mensagens
para celulares e até mesmo alertas sonoros. Também é possível utilizar softwares externos
para fazer as notificações. A figura 4.3 ilustra o recebimento de 4 (quatro) alertas no console
da ferramenta:
56
Figura 4.3 – Monitoramento – Alertas
O primeiro alerta informa que o espaço em disco rígido está inferior a 1GB e o
segundo que a memória RAM disponível esta baixa, ambos referentes ao host denominado
GERENTE. Os dois últimos alertas são referentes ao Servidor FTP e Servidor de E-mail
respectivamente [ZABBIX, 2006].
4.7 VERIFICAÇÃO DE INTEGRIDADE DE ARQUIVOS
O monitoramento de arquivos do ZABBIX é mais voltado para alterações no
conteúdo do arquivo. O ZABBIX faz isso gerando um código rash do arquivo, usando um
algoritmo de criptografia, em um determinado comento e comparando esse código com o
gerado no momento da monitoração, se esses códigos não coincidirem ele assume que ouve
uma alteração no arquivo. Isso é bastante útil para saber se ouve alguma alteração de
configuração. Com ele é possível ate mesmo monitorar um fórum na internet, por exemplo,
para se saber se alguém postou alguma informação nova fórum. A seguir é representado na
57
figura 4.4 a configuração do monitoramento do arquivos de usuários do Unix.
Figura 4.4 – Monitoramento de alterações no arquivo /etc/passwd
4.8 SERVIÇOS DE AUDITORIA
Todas as alterações feitas nas configurações do ZABBIX são armazenadas em banco
de dados. Através dessas informações, é possível saber quem fez uma alteração na
configuração do ZABBIX e também o dia, horário e até mesmo qual alteração foi feita
conforme ilustrado na figura 4.5. Isso é bastante útil no caso de haver alguma falha de
configuração, porque permite descobrir quem a e quando realizou esta configuração,
facilitando identificar e corrigir esta falha com rapidez e mais precisão [ZABBIX, 2006].
58
Figura 4.5 – Configuração – Auditoria
4.9 GERAÇÃO DE GRÁFICOS
A partir dos dados coletados no monitoramento, o ZABBIX gera, automaticamente,
gráfico com esses dados. De forma que facilita bastante a visualização dos recursos utilizados
e alterações estados de itens monitorados.
É possível se acompanha o nível de utilização de uma unidade de armazenamento,
utilização de memória, desempenho de processadores e uma infinidade de itens.
Os gráficos gerados pelo ZABBIX podem ser customizados de acordo com as
necessidades do cliente e ficam disponíveis por um tempo também pré-determinado na
configuração da estação de gerenciamento.
O gráfico da figura 4.6, mostra o histórico de ocupação de disco do host GERENTE
[ZABBIX, 2006].
59
Figura 4.6 – Monitoramento – gráficos: Espaço livre no ponto de montagem/do GERENTE
4.10 CAPACIDADE DE PLANEJAMENTO
Com a observação dos dados coletados através do monitoramento e dos
gráficos obtidos, o administrador pode acompanhar os níveis de utilização de todos os
recursos de sua rede. Com isso o administrador da rede de computadores pode planejar uma
atualização de um hardware que não esteja suportando, de maneira eficiente, a carga que esta
sendo imposta a ele. Devido a essa facilidade disponível no ZABBIX, o gerente possui uma
clara visão para necessidades futuras e pode acompanhar melhor o crescimento de sua rede de
computadores [Bonomo, 2006].
60
4.11 ACORDO DE NÍVEL DE SERVIÇO – SLA
Com o ZABBIX se podem monitorar serviços em nível de contrato, conhecidos
como SLA (Service Level Agreement). SLA é um acordo escrito, feito entre o provedor de
serviços e o cliente que define certos padrões de disponibilidade de serviços entre outros itens.
A figura 4.7 mostra um exemplo de SLA atual do serviço chamado “Contrato”
[ZABBIX, 2006]:
Figura 4.7 – Monitoramento – Serviços IT
A partir do SLA obtido do monitoramento, é possível saber se o provedor do serviço
está ou não cumprindo com sua parte do contrato. Podem se configurar alertas para informar
ao administrador do sistema se o valor atual esta que esta sendo fornecido está de acordo com
o contrato [ZABBIX, 2006].
4.12 CRIAÇÃO DE GRUPOS E MODELOS DE CONFIGURAÇÃO
Quando se deseja usar um sistema de gerenciamento de computadores para uma
grande quantidade de dispositivos, é muito útil criar modelos de configuração para tornar
mais eficiente o processo de configuração dos dispositivos. Com o ZABBIX é possível criar
grupos de configuração de acordo com as necessidades de cada ambiente. Dessa forma, é
criada uma configuração modelo e a mesma é usada para todos os dispositivos semelhantes.
61
Após definir os grupos, podem-se determinar quais grupos ganharam atenção
especial durante o gerenciamento. Com o ZABBIX você define quais grupos de dispositivos
gerenciados apareceram no console do operador do sistema, com isso fica mais fácil
monitorar os alertar recebidos e mudanças de estados.
A figura 4.8 mostra os modelos de configuração presentes na configuração original
da ferramenta, (apenas o modelo “Embrapa” não está presente na configuração original)
[ZABBIX, 2006]:
Figura 4.8 – Configuração de grupos e modelos de configuração
4.13 EXECUÇÃO DE COMANDOS REMOTOS
A facilidade para se executar um comando em um dispositivo remoto, eleva o
gerenciamento a um nível de poder para corrigir falhas no momento em que elas ocorrem.
Dessa maneira, o gerenciamento passa do simples monitoramento para o gerenciamento
propriamente dito.
O ZABBIX também permite que os administradores da ferramenta executem Shell
scripts e até mesmo programas remotamente, permitindo que se tenham mais opções do que
62
somente reiniciar um serviço com problema.
Os comandos executados remotamente através da ferramenta ZABBIX são
executados através de uma conta de usuário local definida no momento da instalação do
cliente no dispositivo gerenciado. Com isso, se garante que apenas os comandos definidos que
esse usuário tenha acesso sejam executados. A configuração dessa facilidade é bastante
simples, porém deve ser usada com muito cuidado para não prejudicar todo o sistema por
causa de uma falha menor que comprometeria apenas um serviço isolado.
Um simples exemplo disso é o travamento do serviço do servido Web Apache, na
maioria dos casos um simples restart consegue reativar o serviço de volta ao seu
funcionamento. A figura 4.9 mostra uma ação criada para solucionar esse problema
[ZABBIX, 2006].
Figura 4.9 – Configuração – Ações
A possibilidade de execução de comandos remotos, por parte da ferramenta de
gerenciamento, no dispositivo gerenciado, é a função que torna a ferramenta de
gerenciamento ZABBIX superior, se comparada com a maioria das ferramentas disponíveis
[ZABBIX, 2006].
63
CAPÍTULO V
INSTALAÇÃO DO SISTEMA DE GERÊNCIA DE REDES DE
COMPUTADORES ZABBIX NA EMBRAPA Arroz e Feijão
5.1 INTRODUÇÃO
Neste capítulo é abordado a instalação da solução proposta para o sistema de
gerenciamento de redes de computadores ZABBIX na empresa EMBRAPA Arroz e Feijão.
A seção 5.2 traz detalhes sobre a instalação do ZABBIX e detalhes da configuração
dos pré-requisitos. A seção 5.3 trata da pós-instalação e do processo de implementação da
solução. A seção 5.4 apresenta uma breve avaliação a respeito da ferramenta.
5.2 INSTALAÇÃO DO ZABBIX
A instalação da solução proposta para o sistema de gerenciamento de redes de
computadores ZABBIX na EMBRAPA Arroz e Feijão foi efetuada sob a supervisão técnica
dos administradores da rede da empresa, que realizaram toda interação com os servidores,
uma vez que a rede estava em produção, e qualquer interrupção nos serviços providos pelos
servidores, poderia influir no funcionamento da rede.
Tendo em vista que todos os pré-requisitos necessários para a instalação do
ZABBIX já estavam disponíveis, iniciou-se a instalação do ZABBIX. Para maiores detalhes e
informações sobre comandos e configuração do ZABBIX, consulte o Anexo D.
Durante a instalação dessa ferramenta, percebeu-se que a versão disponível no
sistema de instalação do sistema operacional era a versão 1.1.4 e a versão atual da ferramenta
é a 1.1.7. Visando garantir a integridade dos serviços disponíveis no servidor que hospedará a
64
ferramenta, o administrador da rede decidiu por não atualizar a versão, deixando esta
atividade para ser feita em outra ocasião.
A figura 5.1 ilustra a divisão dos pré-requisitos necessários para a implementação da
ferramenta nos servidores da rede de computadores da Embrapa Arroz e Feijão:
Figura 5.1 – Divisão dos pré-requisitos
Após toda instalação e configuração da ferramenta, o administrador da rede
iniciou a criação e a inserção dos dados iniciais no servidor de banco de dados, para o
funcionamento do sistema de gerenciamento.
5.2.1 Configuração do Banco de dados
A empresa fez a opção por utilizar um servidor de banco de dados diferente ao qual
hospedará a ferramenta ZABBIX, pois o número de agentes e itens monitorados não seria
alto, nesta fase inicial. Assim, nem o tráfego da rede e nem o processamento local do servidor
ficaram comprometidos pelo gerenciamento, não aumentando o tráfego da rede. O servidor
eleito para hospedar o banco de dados do ZABBIX foi máquina denominada de CARAJAS,
por já prover um servidor de banco de dados MySQL.
No momento da configuração, quando o administrador da rede iniciou a inserção dos
dados iniciais no banco de dados recém criado, denominado de “ZABBIX”, surgiram alguns
problemas. Foi constatado que havia erros nos scripts fornecidos junto com a distribuição do
ZABBIX. Como solução, foram feitas algumas alterações nos scripts.
65
Foi utilizada uma ferramenta gráfica, denominada SQLyog, para acessar o servidor
de banco de dados, criar as tabelas e inserir os dados iniciais, diferentemente do instruído no
manual de instalação, com intuito de tornar mais rápida essa etapa da implementação,
conforme apresentado no Anexo D.
5.2.2 Configuração do ZABBIX
Após a criação e configuração do banco de dados, instalou-se a versão 1.1.4 do
Servidor ZABBIX e do Agente ZABBIX no servidor “TALENTO”, host responsável por
hospedar o servidor web da empresa. Esse servidor, já estava com todos os outros prérequisitos necessários para o funcionamento do ZABBIX, por isso sua instalação foi rápida e
sem complicações.
O Servidor ZABBIX foi instalado, configurado de acordo com o manual de
instalação, disponível no Anexo D. A pasta com o conteúdo da interface web (PHP) do
ZABBIX, foi disponibilizada no servidor web, para que o ZABBIX possa ser acessado
remotamente de qualquer host da rede da EMBRAPA Arroz e Feijão. Futuramente, pode-se
disponibilizar acesso a interface web para a Internet, conforme necessidade da empresa.
Instalou-se inicialmente a versão 1.1.4 do ZABBIX com intenção de atualizá-lo para
a versão 1.1.7, no entanto não foi possível devido à necessidade de se fazer a atualização de
toda a árvore de softwares do sistema operacional. Esta atualização não poderia ser realizada
devido a incompatibilidades, conforme foi informado pela equipe de informática da empresa,
com as versões mais recentes do PHP com alguns aplicativos contidos na rede de
computadores.
5.3 O ZABBIX EM OPERAÇÃO NA EMPRESA
Inicialmente, apenas o servidor TALENTO, equipamento que hospeda o ZABBIX,
foi configurado como cliente da ferramenta. Está dessa forma para demonstrar que a
ferramenta está funcionando, e que, de fato, que não comprometeria o processamento do
servidor.
66
Após coletar alguns dados, a partir do monitoramento através da ferramenta
ZABBIX, com a finalidade de comprovar o perfeito funcionamento das funcionalidades da
ferramenta, foi passado o controle da ferramenta para o administrador da rede, para que o
mesmo venha a instalar o agente e ativar o monitoramento dos demais servidores, no
momento oportuno.
5.4 AVALIAÇÃO DO ZABBIX EM OPERAÇÃO NA EMPRESA
O sistema de gerenciamento encontra-se instalado, em perfeito funcionamento na
empresa, devido a outras prioridades, o mesmo será efetivamente utilizado posteriormente, no
anexo E, o responsável técnico da empresa faz a sua avaliação do trabalho efetuado.
Com a realização desse trabalho foi possível constatar a importância que tem para o
administrador de uma rede de computadores ter pleno controle das atividades que ocorrem na
rede, possibilitando o monitoramento, em tempo real, dos serviços ativos, a fim de agilizar
tomadas de decisões, melhorar o desempenho da rede e facilitar o trabalho do administrador
de redes.
A implementação da ferramenta de gerenciamento de redes de computadores
ZABBIX, irá possibilitar a equipe de informática da empresa detectar, diagnosticar e corrigir
falhas de forma que afete o mínimo possível o usuário e consumindo o mínimo de recursos
físicos e humanos.
67
CAPÍTULO VI
CONCLUSÃO
O gerenciamento de uma rede de computadores vai muito além de gerenciar o
funcionamento do servidor e o tráfego da rede. Cada uma das áreas funcionais, dentro de seu
escopo, busca resolver problemas relativos às falhas de componentes, configuração da rede,
níveis de desempenho alcançados pela rede, segurança e contabilização de sua utilização.
As atividades de gerenciamento de redes são divididas em cinco áreas funcionais de
gerenciamento, denominadas: Gerenciamento de Falhas, Gerenciamento de Configuração,
Gerenciamento de Desempenho, Gerenciamento de Segurança e Gerenciamento de
Contabilização. Estas áreas funcionais constituem processos de aplicação de gerenciamento
que utilizam os serviços oferecidos pela camada de aplicação do Modelo OSI.
Conforme as pesquisas realizadas neste trabalho, verificou-se que existem diversas
ferramentas disponíveis, de custo gratuito, capazes de fazer o gerenciamento de serviços de
redes, tais como: NAGIOS, ZABBIX e OpenNMS, todos softwares livres sob a licença GPL.
Após analisar essas ferramentas, a que se mostrou mais adequada para gerenciar a
rede de computadores da EMBRAPA Arroz e Feijão foi a ferramenta ZABBIX, porque ela
tem pacotes nativos no FreeBSD, que é o sistema operacional do servidor que irá abrigar o
sistema de gerenciamento. Além disso, é capaz de atender todas as necessidades impostas pela
gerência da empresa, além de ser uma ferramenta bastante atual e em constante
desenvolvimento.
Uma grande dificuldade enfrentada para a implantação do protótipo na empresa, foi
o fato de não haver dispositivos de hardware, na empresa, para a realização de testes, portanto
toda a etapa de pesquisa e desenvolvimento do protótipo foi realizado em dispositivos fora da
empresa, o que aumentou ainda mais o tempo até que a ferramenta realmente fosse
efetivamente utilizada na rede de produção do ambiente corporativo real da empresa.
A rede de computadores da EMBRAPA Arroz e Feijão é muito bem estruturada,
contando com hosts específicos que abrigam o firewall, servidor de e-mail, servidor FTP,
68
servidor web, servidor de banco de dados e a DMZ, por esse motivo todas as etapas de
configuração, instalação do gerente e dos agentes ZABBIX, criação de usuários e de tabelas
necessárias para a utilização da ferramenta, foram realizadas pela equipe que administra a
rede de computadores da EMBRAPA Arroz e Feijão.
O gerente ZABBIX foi instalado no host “TALENTO”, que abriga o servidor web
da empresa, onde foi instalado também o agente ZABBIX para que possa gerenciar o host
onde esta instalado. A interface PHP do ZABBIX foi copiada para o mesmo local onde estão
hospedadas as páginas web validas da empresa, para que o ZABBIX possa ser acessado
remotamente via web de fora da empresa. As tabelas onde serão armazenadas as informações
recolhidas junto aos dispositivos gerenciados foram hospedadas no servidor de banco de
dados da empresa.
Os hosts que se pretende gerenciar, a principio, são os da rede local, servidor FTP,
servidor de banco de dados, servidor web, servidor de e-mail e o servidor de arquivos.
Com a realização desse trabalho foi possível constatar a importância que tem para o
administrador de uma rede de computadores ter pleno controle das atividades que ocorrem na
rede, possibilitando o monitoramento, em tempo real, dos serviços ativos, afim de agilizar
tomadas de decisões, melhorar o desempenho da rede e facilitar o trabalho do administrador
de redes.
A implementação da ferramenta de gerenciamento de redes de computadores
ZABBIX, irá possibilitar a equipe de informática da empresa detectar, diagnosticar e corrigir
falhas de forma que afete o mínimo possível o usuário e consumindo o mínimo de recursos
físicos e humanos.
Após a conclusão de todo trabalho, teórico e pratico, toda equipe envolvida no
processo de pesquisa, elaboração e implementação do projeto, obteve conhecimentos
necessários para planejar e implementar essa e outras ferramentas de gerência de rede de
computadores em qualquer ambiente, seja corporativo ou acadêmica.
Para a continuidade deste projeto, sugere-se para trabalhos futuros a associação de
softwares que agreguem características que não são nativas do ZABBIX, tais como:
•
Programa que disponibilize uma forma eficiente de se obter o inventário de
software e hardware de todos os equipamentos da rede de computadores;
•
Criar mecanismos de auto-descobrimento de serviços e dispositivos
conectados na rede de computadores.
69
REFERÊNCIAS BIBLIOGRÁFICAS
[Bianchini, 2003] Bianchini , Calebe de P., Almeida, Eduardo S. de, Fontes, Diogo S.,
Andrade, Rossana M. de C.; Um Padrão para Gerenciamento de Redes, São Paulo,
Departamento de Computação – Universidade Anhembi Morumbi (UAM), 2003.
[Bonomo, 2006] Bonomo, E., Gerenciamento e Monitoração de Redes de Computadores
Utilizando-Se ZABBIX, Lavras, Minas Gerais, 2006. Monografia de Pós-Graduação “Lato
Sensu” apresentada ao Departamento de Ciência da Computação para obtenção do título de
Especialista em “Administração em Redes Linux”.
[Carvalho, 1997] Carvalho, T. C. M. B., Arquiteturas de Redes de Computadores OSI e
TCP/IP, São Paulo, Editora MAKRON Books, 2ª Edição, 1997.
[Flint, 1997] Flint, M. A. et al, Desvendando o TCP/IP, Rio de Janeiro, Editora Campus, 1997.
[Harnedy, 1997] Harnedy, Sean, Total SNMP: Exproring the Simple Network Management
Protocol, second Edition, Prentice Hall PTR, 1997.
[Machado, 2006] Machado, L. H., Gerência Remota de Recursos Usando o NAGIOS,
disponível em http://leonardomachado.googlepages.com/, acessado em 15/07/2006.
[Messias, 2005] Messias, J. A. S., Construção de Agentes SNMP em Ambientes Linux,
Lavras, Minas Gerais, 2005. Monografia de Pós-Graduação “Lato Sensu” apresentada ao
Departamento de Ciência da Computação para obtenção do título de Especialista em
“Administração em Redes Linux”.
[NAGIOS, 2006] Site oficial da ferramenta NAGIOS, disponível em www.nagios.org, site
oficial, acessado em 15/07/2006.
70
[Oliveira, 2002] Oliveira, Célia Cristina F. de; Vaz, Karla Regina Inácio; Meira, Luciene
Viana de R.; Silva, Patrícia Cruz; Gerenciamento de Redes de Computadores – SNMP e
RMON, 2002.
[Otsuka, 1996] Otsuka, Joice Lee, site da Universidade Federal do Rio Grande do Sul,
disponível em http://penta.ufrgs.br/gr952/trab1/2capa.html, 15/08/2006.
[Oyama, 2002] Oyama, C. S. O, OpenNMS uma visão geral, disponível em
http://www.rnp.br/_arquivo/sci/2002/openNMS.pdf, acessado em 15/07/2006.
[Rigney, 1996] Rigney, Steve, Planejamento e Gerenciamento de Redes Seu consultor pessoal,
editora Campus, 1996.
[Soares, 1995] Soares, L. G., Lemos, G. e Colcher, S., Redes de Computadores, Rio de janeiro,
Editora Campus, 2ª Edição, 1995.
[ZABBIX, 2006] Site oficial da ferramenta ZABBIX, disponível em www.ZABBIX.com,
acessado em 15/07/2006.
71
BIBLIOGRAFIA SUGERIDA
http://penta.ufrgs.br/gr952/trab1/2capa.html, acessado em 15/03/2007.
http://www.inf.pucminas.br/prof/fatima/, acessado em 20/03/2007.
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/snmp.htm,
acessado
em
10/03/2007.
http://www.apache.org/, acessado em 20/03/2007.
http://www.postgresql.org/, acessado em 15/03/2007.
http://www.php.net/, acessado em 15/03/2007.
http://net-snmp.sourceforge.net/, acessado em 15/03/2007.
72