Charles William Biesseki

Prévia do material em texto

UNIVERSIDADE FEDERAL DE MATO GROSSO
INSTITUTO DE COMPUTAÇÃO
COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM
CIÊNCIA DA COMPUTAÇÃO
RELATÓRIO DE ESTÁGIO SUPERVISIONADO
IMPLANTAÇÃO DE FERRAMENTA PARA
MONITORAMENTO DE ATIVOS DE REDE
BASEADO NO PROTOCOLO SNMP PARA O
HOSPITAL UNIVERSITÁRIO JÚLIO MÜLLER
CHARLES WILLIAM BIESSEKI
CUIABÁ - MT
2016
UNIVERSIDADE FEDERAL DE MATO GROSSO
INSTITUTO DE COMPUTAÇÃO
COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM
CIÊNCIA DA COMPUTAÇÃO
RELATÓRIO DE ESTÁGIO SUPERVISIONADO
IMPLANTAÇÃO DE FERRAMENTA PARA
MONITORAMENTO DE ATIVOS DE REDE
BASEADO NO PROTOCOLO SNMP PARA O
HOSPITAL UNIVERSITÁRIO JÚLIO MÜLLER
CHARLES WILLIAM BIESSEKI
Orientador: Prof. Dr. Roberto Benedito de Oliveira Pereira
Relatório de estágio apresentado ao Curso de
Ciência da Computação, do Instituto de Com-
putação da Universidade Federal de Mato
Grosso, como requisito para obtenção do tí-
tulo de Bacharel em Ciência da Computação
CUIABÁ - MT
2016
UNIVERSIDADE FEDERAL DE MATO GROSSO
INSTITUTO DE COMPUTAÇÃO
COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM
CIÊNCIA DA COMPUTAÇÃO
CERTIFICADO DE APROVAÇÃO
Título: RELATÓRIO DE ESTÁGIO SUPERVISIONADO
IMPLANTAÇÃO DE FERRAMENTA PARA MONITORAMENTO
DE ATIVOS DE REDE BASEADO NO PROTOCOLO SNMP
PARA O HOSPITAL UNIVERSITÁRIO JÚLIO MÜLLER
Autor: Charles William Biesseki
Trabalho aprovado em 28 de setembro de 2016.
Comissão examinadora:
Prof. Dr. Roberto Benedito de
Oliveira Pereira
Instituto de Computação - UFMT
Orientador
Leonardo Luiz Braun
HUJM/SGPTI
Supervisor
Prof. Ms. Nilton Hideki Takagi
Instituto de Computação - UFMT
Coordenador de Estágio
Krum Sacarov Softov
Sócio-proprietário RKLogic
Convidado
Aos meus pais, meu irmão, minha namorada,
e a todos que acreditaram em mim e sempre
apoiaram minhas escolhas.
AGRADECIMENTOS
Agradeço a Deus.
Agradeço aos meus pais, Josiane I. B. Vieira e Vilson L. Biesseki, que
nunca mediram esforços para me apoiar em todas minhas escolhas.
Agradeço ao meu irmão, Richard Biesseki, por sempre estar ao meu lado.
Agradeço à minha namorada, Érika Tomaz, por ser minha parceira incon-
dicional.
Agradeço ao meu orientador e professor Dr. Roberto B. O. Pereira, pela
disposição e paciência em me orientar durante a realização deste trabalho.
Agradeço a todos os professores do Instituto de Computação da UFMT
que tive o prazer de ser aluno, foram fundamentais na minha formação.
Agradeço meu amigo Krum S. Softov, por não medir esforços em participar
da banca examinadora e por ter sido um grande exemplo pra mim.
Agradeço meu amigo Édipo A. S. Palha, por ter proporcionado a comuni-
cação com Setor de Técnologia do Hospital Júlio Muller onde foi possível realizar
este trabalho.
Agradeço a todos meus amigos que conheci durante a vida acadêmica,
amigos para vida toda.
Agradeço a todos da equipe do SGPTI do Hospital Universitário Júlio
Müller, pelo extraordinário ambiente que me proporcionaram, sendo fundamentais
na minha formação profissional. Em especial ao meu supervisor Leonardo L. Braun
pela oportunidade oferecida à mim, por ser um profissional excepcional e grande
pessoa, e também ao Helton C. L. Godoy, Analista de Redes do HUJM, por todo
conhecimento passado e apoio na realização deste trabalho.
A todos que de alguma forma contribuíram com minha formação acadê-
mica e profissional.
RESUMO
O estágio supervisionado foi realizado no Setor de Gestão de Processos e Tecnologia
da Informação (SGPTI) do Hospital Universitário Júlio Müller (HUJM) situado na
Rua Luís Philipe Pereira Leite, Bairro Alvorada, Cuiabá – MT.
O objetivo desse trabalho é implantar uma solução para o monitoramento de ativos
de rede do HUJM utilizando o protocolo SNMP, buscando mais agilidade na detecção
de interrupções de funcionamento e de possíveis anomalias.
O desenvolvimento desta solução foi feito em etapas, sendo elas: revisão de literatura,
levantamento de materiais, métodos e técnicas para obter a melhor solução.
Após levantamento de requisitos e entrevistas com a equipe do SGPTI foi definida
a ferramenta de monitoramento Zabbix. A implantação desta solução foi composta
por dois ambientes: Ambiente de Testes e Ambiente de Produção. O ambiente de
testes foi feito em máquinas virtuais no próprio computador pessoal e o ambiente
de produção ocorreu em uma máquina virtual localizada no servidor de produção.
As configurações primeiramente foram feitas em ambiente de testes, realizando os
ajustes necessários e posteriormente após os resultados esperados, então foi feita a
migração da configuração para o ambiente de produção.
Após os testes e resultados obtidos foi possível concluir que a ferramenta atendeu
os requisitos levantados, alcançando o objetivo deste trabalho, monitorando todos
os ativos do HUJM, trazendo maior controle sobre interrupções, incidentes, falhas
que venham a ocorrer nos ativos de rede, também emitindo alertas de incidentes na
interface do Zabbix e via e-mail, dando maior conforto a equipe do SGPTI. Também
foi definido um Acordo de Nível de Serviço (SLA), para efeito de registro e estatísticas
sobre a disponibilidade dos ativos de rede, facilitando a detecção de instabilidade
nos ativos de rede.
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . 1
2 REVISÃO DA LITERATURA . . . . . . . . . . . . . . . . 4
2.1 Redes de Computadores . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Modelo de referência ISO OSI . . . . . . . . . . . . . . . . . . . 5
2.3 Modelo de referência TCP/IP . . . . . . . . . . . . . . . . . . . 8
2.4 Protocolo UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Gerenciamento de rede e o Protocolo SNMP . . . . . . . . . . 11
2.5.1 Arquitetura do SNMP . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5.2 PDUs e Mensagem SNMP . . . . . . . . . . . . . . . . . . . . . . . 13
2.5.3 SMI e MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5.4 Nomeando OIDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.5 Definindo OIDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5.6 Versões do SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5.7 SNMPv2c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6 Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6.1 Cacti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6.2 Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6.3 PRTG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6.4 Zabbix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3 MATERIAIS, TÉCNICAS E MÉTODOS . . . . . . . . . . 25
3.1 Local do experimento . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Infraestrutura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.1 Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Levantamento de Requisitos . . . . . . . . . . . . . . . . . . . . 29
3.4 Ferramentas utilizadas . . . . . . . . . . . . . . . . . . . . . . . . 30
3.5 Configuração da máquina virtual . . . . . . . . . . . . . . . . . . 30
3.6 Cenários de Testes . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.6.1 Cenário 1 - Monitoramento de todos os ativos de rede . . . . . . . . 31
3.6.2 Cenário 2 - Alerta de Desastre . . . . . . . . . . . . . . . . . . . . . 32
3.6.3 Cenário 3 - SLA Aceitável . . . . . . . . . . . . . . . . . . . . . . . 33
4 RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . 34
4.1 Cenário 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2 Cenário 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.1 Cenário 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5 CONCLUSÕES . . . . . . . . . . . . . . . . . . . . . . . . 465.1 Dificuldades encontradas . . . . . . . . . . . . . . . . . . . . . . 47
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . 48
A TUTORIAL INSTALAÇÃO DO ZABBIX 3.0.4 NO UBUNTU
16.04 COM MYSQL . . . . . . . . . . . . . . . . . . . . . 50
A.1 Instalando e configurando as dependências . . . . . . . . . . . . 50
A.2 Criando o banco de dados no MySQL . . . . . . . . . . . . . . . 51
A.3 Configurando o PHP . . . . . . . . . . . . . . . . . . . . . . . . . 51
A.3.1 Instalando o Zabbix . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
A.4 Populando o banco de dados no MySQL . . . . . . . . . . . . . 52
A.5 Compilando o Zabbix . . . . . . . . . . . . . . . . . . . . . . . . 53
A.6 Configurando o Zabbix . . . . . . . . . . . . . . . . . . . . . . . . 53
A.6.1 Script de inicialização do Zabbix . . . . . . . . . . . . . . . . . . . . 54
A.7 Acessando a interface web do Zabbix . . . . . . . . . . . . . . . 57
LISTA DE ILUSTRAÇÕES
Figura 1 – Modelo de Referência OSI (TANENBAUM, 2003) . . . . . . . . . 6
Figura 2 – Comparativo modelo ISO OSI com modelo TCP/IP Adaptado de:
(TANENBAUM, 2003) . . . . . . . . . . . . . . . . . . . . . . . . 9
Figura 3 – Cabeçalho UDP (KUROSE; ROSS, 2010) . . . . . . . . . . . . . 10
Figura 4 – Principais componentes da arquitetura SNMP (KUROSE; ROSS,
2010) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Figura 5 – PDUs do SNMPv1 (DEO, 2012) . . . . . . . . . . . . . . . . . . . 14
Figura 6 – Estrutura da mensagem SNMP (DEO, 2012) . . . . . . . . . . . . 15
Figura 7 – Troca de mensagens SNMP (FILHO, 2012) . . . . . . . . . . . . . 16
Figura 8 – Parte da estrutura hierárquica das variáveis de gerência - Árvore
MIB (RIZO, 2011) . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Figura 9 – Visão geral dos Switches . . . . . . . . . . . . . . . . . . . . . . . 26
Figura 10 – Visão externa do CDC . . . . . . . . . . . . . . . . . . . . . . . . 26
Figura 11 – Estrutra Interna (No-break de grande porte) . . . . . . . . . . . . 27
Figura 12 – Estrutura Interna (Extintor e Servidores) . . . . . . . . . . . . . . 27
Figura 13 – Estrutura Interna (Raque com patch-panels) . . . . . . . . . . . . 28
Figura 14 – Gerador elétrico dedicado ao CDC . . . . . . . . . . . . . . . . . 28
Figura 15 – Imagem ilustrativa do servidor utilizado . . . . . . . . . . . . . . 29
Figura 16 – Sumário da máquina virtual no vSphere . . . . . . . . . . . . . . 30
Figura 17 – Configuração da Trigger de Desastre . . . . . . . . . . . . . . . . 32
Figura 18 – Ação para envio de alertas via e-mail . . . . . . . . . . . . . . . . 33
Figura 19 – SLA Aceitável para o SWITCH GEP SW-13 . . . . . . . . . . 33
Figura 20 – Mapa com panorama geral dos ativos de rede . . . . . . . . . . . 34
Figura 21 – Mapa com panorama das impressoras . . . . . . . . . . . . . . . . 35
Figura 22 – Mapa com panorama dos relógios de ponto . . . . . . . . . . . . . 36
Figura 23 – Mapa com panorama dos servidores . . . . . . . . . . . . . . . . . 36
Figura 24 – Mapa com panorama do servidor IBM VMWARE 10 . . . . . . . 37
Figura 25 – Mapa com panorama do servidor IBM VMWARE 20 . . . . . . . 37
Figura 26 – Mapa com panorama do servidor IBM VMWARE 30 . . . . . . . 38
Figura 27 – Aba Eventos com incidentes ocorridos . . . . . . . . . . . . . . . 39
Figura 28 – Informações das ações . . . . . . . . . . . . . . . . . . . . . . . . 39
Figura 29 – Alerta de desastre recebido via e-mail . . . . . . . . . . . . . . . 40
Figura 30 – Alerta de recuperação recebido via e-mail . . . . . . . . . . . . . 40
Figura 31 – Panorama de SLAs de todos os Switches . . . . . . . . . . . . . . 41
Figura 32 – Panorama de SLAs de todas máquinas virtuais . . . . . . . . . . 42
Figura 33 – Panorama de SLA do Firewall . . . . . . . . . . . . . . . . . . . . 43
Figura 34 – Panorama de SLAs de todas as impressoras . . . . . . . . . . . . 44
Figura 35 – SLA da Impressora da Prescrição da Clínica Cirúrgica . . . . . . 45
Figura 36 – SLA da Impressora da Oftalmologia . . . . . . . . . . . . . . . . . 45
Figura 37 – Panorama de SLAs de todos os Relógio de ponto . . . . . . . . . 45
Figura 38 – Clique no botão Next step . . . . . . . . . . . . . . . . . . . . . 57
Figura 39 – Cheque as dependências do Zabbix. Se estiver tudo certo, clique
em Next step . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Figura 40 – Informe o tipo da base de dados, o usuário e a senha. Se estiver
ok, clique em Next step . . . . . . . . . . . . . . . . . . . . . . . 58
Figura 41 – Informe o IP do servidor Zabbix e a porta em que ele será executado
(padrão 10051). Em Name coloque um nome para o servidor Zabbix.
Depois clique em Next step . . . . . . . . . . . . . . . . . . . . 59
Figura 42 – Configurações Ok, clique em Next step . . . . . . . . . . . . . . 59
Figura 43 – Pronto! Zabbix instalado. . . . . . . . . . . . . . . . . . . . . . . 60
Figura 44 – Tela de acesso web, logue com usuário Admin e senha zabbix . 60
LISTA DE TABELAS
Tabela 1 – Estrutura Geral PDUs SNMP . . . . . . . . . . . . . . . . . . . . 14
Tabela 2 – Funções GetRequest, GetNextRequest e SetRequest . . . . . . . . 14
Tabela 3 – Função GetResponse . . . . . . . . . . . . . . . . . . . . . . . . . 14
Tabela 4 – Função Trap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Tabela 5 – Objetos gerenciados no grupo system da MIB-2 (KUROSE; ROSS,
2010) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Tabela 6 – Tipos de dados SMIv1 (FILHO, 2012) . . . . . . . . . . . . . . . 20
Tabela 7 – Novos tipos de dados SMIv2 (FILHO, 2012) . . . . . . . . . . . . 20
Tabela 8 – Operações básicas SNMPv1 (DEO, 2012) . . . . . . . . . . . . . 21
Tabela 9 – Operações básicas SNMPv2 (DEO, 2012) . . . . . . . . . . . . . 21
Tabela 10 – Operações básicas SNMPv3 (DEO, 2012) . . . . . . . . . . . . . 21
LISTA DE ABREVIATURAS E SIGLAS
ASN Notação de Sintaxe Abstrata
BER Regras Básicas de Codificação
CDC Centro de Dados em Container
CFTV Circuito Fechado de Televisão
DNS Sistema de Nomes de Domínios
DVR Gravador de Vídeo Digital
FTP Protocolo de Transferência de Arquivos
GNU Licença Pública Geral
HTTP Protocolo de Transferência de Hipertexto
HUJM Hospital Universitário Júlio Müller
ICMP Protocolo de Controle de Mensagens da Internet
ID Identificador
IETF Grupo de Trabalho em Engenharia da Internet
IMAP Protocolo de Acesso a Mensagem da Internet
IP Protocolo de Internet
ISO Organização Internacional de Padronização
ISP Fornecedor de acesso à internet
MIB Base de Informações de Gerenciamento
OID Identificadores de Objeto
OSI Sistema Aberto de Interconexão
PDU Unidade de Dados de Protocolo
POP3 Protocolo dos Correios
RFC Pedido para Comentários
SGBD Sistema de Gerenciamento de Banco de Dados
SGMP Protocolo de Monitoramento de Gateway Simples
SGPTI Setor de Gestão de Processos e Tecnologia da Informação
SLA Acordo de Nível de Serviço
SMI Estrutura de Informações de Gerenciamento
SMS Serviço de Mensagens Curtas
SMTP Protocolo de Transferência de Correio Simples
SNMP Protocolo Simples de Gerência de Rede
TCP Protocolo de controle de transmissão
TELNET Protocolo de Terminal Virtual de Rede
UDP Protocolo de Data-grama do Usuário
VLAN Rede Local Virtual
UFMT Universidade Federal de Mato Grosso
WMI Instrumentação de Gerenciamento do Windows
CAPÍTULO 1
INTRODUÇÃO
O Setor de Gestão de Processos e Tecnologia da Informação (SGPTI) do
Hospital Universitário Júlio Müller (HUJM) atualmente enfrenta uma trajetória de
inovação e evolução tecnológica, buscando o aperfeiçoamento das rotinas afrontadas
no dia a dia de trabalho e na ampliação da informatização de processos assistenciais
no âmbito hospitalar.
Pela lógica de mercado, o hospital que incorpora tecnologias, aperfeiçoa
seus processos de gestão e desenvolve melhor seus serviços, diferenciando-se dos demais devido à modernização de seus processos (FEUERWER-
KER; CECÍLIO, 2007).
Após a implantação do software Aplicativo de Gestão para Hospitais
Universitários (AGHU) que faz parte do Programa Nacional de Reestruturação dos
Hospitais Universitários Federais (REHUF), do Ministério da Educação, foi possível
que todas as consultas ambulatoriais, prescrições médicas e da enfermagem fossem
realizadas com o auxílio do computador. Os exames laboratoriais, também dependem
dos sistemas para sua realização, e necessitam de rápida identificação de desastres,
pois são efetuados exames de urgência das Unidades de Terapia Intensiva Adulto
e Neonatal. Esses processos, juntamente a gestão administrativa/assistencial que
Capítulo 1. Introdução 2
também depende de sistemas, exige que a equipe de Tecnologia da Informação esteja
apta para a identificação de desastres, pois qualquer interrupção nestes sistemas, pode
gerar prejuízos irreparáveis à saúde dos pacientes, como por exemplo, desorganizar
os processos de medicação, ocasionando o atraso na medicação dos pacientes.
O HUJM conta com uma alta rotatividade de pacientes, atendendo a
população Cuiabana e também pacientes de cidades do interior de Mato Grosso que
se deslocam até a capital. Passam pelo hospital em média 300 mil pacientes por mês,
efetuando cerca de 8,8 mil consultas, e um quadro médio mensal de 362 internações
(Fonte: Intranet HUJM). Ficando evidente a importância de automatizar e aperfeiçoar
os serviços e processos, almejando atender os pacientes de forma confortável e também
facilitar a rotina dos servidores e funcionários dessa instituição.
Pensando nesse cenário a tecnologia tem grande importância para todos
os setores hospitalares, e para que todas essas ferramentas possam comunicar-se
entre si, é preciso contar com uma rede de computadores que possa fornecer toda
essa comunicação e interligação entre tecnologias de forma estável e confiável. Hoje o
HUJM conta com uma infraestrutura de rede de computadores que tem uma gama
de ativos de rede como, servidores, switches, relógios de registro de ponto, estações
de vídeo conferência, o CFTV (Circuito Fechado de Televisão) com câmeras de
segurança e gravadores DVR (Gravador de Vídeo Digital), impressoras, entre outros
dispositivos que comumente se conectam a rede de computadores. Hoje apenas alguns
dispositivos classificados como dispositivos críticos são monitorados.
Com base nesse cenário, foi identificado a necessidade do monitoramento
em tempo real de todos os ativos de rede presentes no HUJM. Dessa forma, o
problema que esse trabalho visa solucionar é como monitorar os ativos de redes em
tempo real utilizando um protocolo padrão para gerenciamento dos dispositivos em
redes IP, conhecido como SNMP (Simple Network Management Protocol - Protocolo
Simples de Gerência de Rede).
O protocolo SNMP é um protocolo para monitoramento e gerenciamento
de redes que pode trabalhar com dispositivos e serviços de diversos modelos e fa-
bricantes. Devido a capacidade de monitoramento do protocolo SNMP que pode
monitorar informações de seus componentes físicos, como uso do processador, me-
mória, interfaces de rede, e também informações sobre o sistema operacional do
dispositivo, o protocolo em questão é o mais adequado ao cenário, usufruindo de
ferramentas presentes no mercado.
Com base no problema levantado e a possível solução apontada. Este
trabalho tem como objetivo geral a implantação de uma solução com base no protocolo
SNMP, para prover o monitoramento de ativos de rede do HUJM, buscando mais
Capítulo 1. Introdução 3
agilidade na detecção de interrupções de funcionamento e na detecção de possíveis
anomalias de software e hardware.
Os objetivos específicos deste trabalho consistem em:
• Realizar um levantamento de requisitos;
• Elencar ferramentas a serem utilizadas de acordo com os requisitos;
• Mapear os dispositivos de rede;
• Configurar ferramenta escolhida para monitoramento dos ativos de rede;
• Realizar testes;
• Avaliar e homologar a solução junto ao HUJM.
Este trabalho está organizado em capítulos, o primeiro capítulo conta
com uma breve introdução a este trabalho, o segundo capítulo aborda uma revisão
de literatura, contendo conceitos teóricos relativos ao trabalho. No terceiro capítulo é
abordado os materiais, as técnicas e os métodos utilizados na solução, com descrição
de equipamentos, cenários e configurações. No quarto capítulo são apresentados
os resultados dos cenários de testes com capturas de tela do sistema. No quinto e
último capítulo é apresentado uma conclusão abordando uma análise do trabalho
desenvolvido e seus resultados, contendo também uma seção com as dificuldades
encontradas durante o trabalho.
CAPÍTULO 2
REVISÃO DA LITERATURA
2.1 Redes de Computadores
Uma rede de computadores é basicamente um conjunto de computadores
conectados por meio de um sistema de comunicação composto por um conjunto de pro-
tocolos em comum para compartilhar recursos e informações entre sí (TANENBAUM,
2003).
A Internet continua a crescer, com cada vez mais dispositivos conectados,
podendo ser o maior sistema de engenharia no planeta, de acordo com o seguinte
trecho:
”A Internet de hoje é provavelmente o maior sistema de engenharia já
criado pela humanidade, com centenas de computadores conectados, links
de comunicação e comutadores; centenas de milhares de usuários que se
conectam esporadicamente por meio de telefones celulares e PDAs; e dis-
positivos como sensores, webcams, console para jogos, quadros de imagens,
e até mesmo máquinas de lavar sendo conectadas á Internet.”(KUROSE;
ROSS, 2010).
Capítulo 2. Revisão da Literatura 5
Em aplicações comerciais em que o cenário traz uma quantidade repre-
sentativa de computadores e outros dispositivos, segundo Tanenbaum (2003), tem-se
o conceito de compartilhamento de recursos, com o objetivo de tornar todos os
programas, equipamentos e dados ao alcance de todas as estações conectadas à rede,
dando o poder de extrair e correlacionar informações sobre a empresa.
Mais importante que compartilhar os recursos físicos, seja compartilhar
informações:
”Porém, talvez mais importante que compartilhar recursos físicos como
impressoras, scanners e gravadores de CDs, seja compartilhar informações.
Toda empresa de grande e médio porte e muitas empresas pequenas tem
uma dependência vital de informações computadorizadas. A maioria das
empresas tem registros de clientes, estoques, contas a receber, extratos
financeiros, informações sobre impostos e muitas outras informações
on-line” (TANENBAUM, 2003).
Para haver uma comunicação simplificada e padrão entre essa gama de
dispositivos de rede, foi criado então um modelo de referência para que todos os
fabricantes e desenvolvedores seguissem os mesmos conceitos, esse modelo é chamado
de OSI, que será abordado na próxima seção.
2.2 Modelo de referência ISO OSI
Segundo Tanenbaum (2003) esse modelo é baseado na proposta desenvol-
vida pela ISO (International Standards Organization - Organização Internacional de
Padronização), como um primeiro passo em direção à padronização internacional de
protocolos empregados nas diversas camadas. Ele trata de interconexão de sistemas
abertos, ou seja, sistemas que estão abertos à comunicação com outros sistemas.
Segundo Kurose e Ross (2010) o modelo OSI (Open Systems Intercon-
nection - Sistema aberto de Interconexão) tomou forma quando os protocolos da
Internet estavam em amadurecimento; e eram um dos muitos conjuntos de protocolos
em desenvolvimento; na verdade, os inventores do modelo OSI original provavelmente
não tinham a Internet em mente ao criá-lo.
O modelo de referência OSI pode ser visto na Figura 1:
Capítulo 2. Revisão da Literatura 6
Figura 1 – Modelo de Referência OSI (TANENBAUM, 2003)
O modelo OSI é composto por sete camadas descritas a seguir:
1. Camada física
Acamada física trata da transmissão bit a bit por um canal de comunicação. O
projeto da rede deve garantir que, quando um lado enviar um bit 1, o outro lado
o receberá como um bit 1, não como um bit 0. Levantando as questões mais
comuns, como a voltagem a ser usada para a representação do bit, o tempo que
o bit deve durar, o fato de a transmissão poder ser ou não realizada nos dois
sentidos simultaneamente, a forma como a conexão inicial será estabelecida e
de que maneira ela será encerrada quando ambos os lados tiverem terminado,
e ainda quantos pinos o conector de rede terá e qual será a finalidade de cada
pino (TANENBAUM, 2003).
2. Camada de enlace de dados
A principal tarefa da camada de enlace de dados é transformar um canal de
transmissão bruta em uma linha que pareça livre de erros de transmissão não
detectados para a camada de rede. Para executar essa tarefa, o transmissor
Capítulo 2. Revisão da Literatura 7
divide os dados de entrada em quadros de dados e transmite sequencialmente.
Se o serviço for confiável, o receptor confirmará a recepção correta de cada
quadro, enviando de volta um quadro de confirmação.
Também tem como função regular o fluxo de dados, impedindo que um trans-
missor rápido envie uma quantidade excessiva de dados a um receptor lento,
utilizando de mecanismos que informe ao transmissor quanto espaço o buffer do
receptor tem no momento. Muitas vezes, esse controle de fluxo e o tratamento
de erros estão integrados (TANENBAUM, 2003).
3. Camada de rede
A camada de rede controla a operação da sub-rede. Determinando a maneira
como os pacotes são roteados da origem até o destino. As rotas podem se
basear em tabelas estáticas, que raramente são alteradas. Elas também podem
ser determinadas no inicio de cada conversação; por exemplo, uma sessão
de terminal (como um logon em uma máquina remota). Também podem ser
altamente dinâmicas, sendo determinadas para cada pacote, com o objetivo de
balancear a carga atual da rede (TANENBAUM, 2003).
4. Camada de transporte
Tem como função básica aceitar dados da camada acima dela, dividi-los em
unidades menores caso necessário, repassar essas unidades à camada de rede e
assegurar que todos os fragmentos chegarão corretamente à outra extremidade.
Tudo isso feito com eficiência e de forma que as camadas superiores fiquem
isoladas das inevitáveis mudanças na tecnologia de hardware.
A camada de transporte também determina que tipo de serviço deve ser
fornecido à camada de sessão. O tipo de conexão de transporte mais popular é
um canal ponto a ponto livre de erros que entrega mensagens na ordem em
que eles foram enviados. Outros tipos possíveis de serviço de transporte são
as mensagens isoladas sem nenhuma garantia relativa à ordem de entrega e à
distribuição de mensagens para muitos destinos. Essa camada é uma verdadeira
camada fim a fim, que liga a origem ao destino. Em outras palavras, quando um
programa de máquina de origem mantém uma conversação com um programa
semelhante instalado na máquina de destino (TANENBAUM, 2003).
5. Camada de sessão
A camada de sessão permite que os usuários de diferentes máquinas estabeleçam
sessões entre eles. Uma sessão oferece diversos serviços, inclusive o controle
de diálogo (mantendo o controle de quem deve transmitir em cada momento),
Capítulo 2. Revisão da Literatura 8
o gerenciamento de símbolos (impedindo que duas partes tentem executar
a mesma operação crítica ao mesmo tempo) e a sincronização (realizando
verificações periódicas em transmissões longas para permitir que elas continuem
a partir do ponto em que estavam ao ocorrer uma falha) (TANENBAUM,
2003).
6. Camada de apresentação
A camada de apresentação está relacionada à sintaxe e à semântica das informa-
ções transmitidas. Para tornar possível a comunicação entre computadores com
diferentes representações de dados, as estruturas de dados a serem transmitidas
podem ser definidas de maneira abstrata, com uma codificação padrão para ser
usada durante a conexão (TANENBAUM, 2003).
7. Camada de aplicação
A razão de ser de uma rede de computadores são as aplicações, se não fosse
as aplicações não haveria necessidade de projetar protocolos de rede para
suportá-las (KUROSE; ROSS, 2010).
A camada de aplicação1 é responsável por prover serviços para aplicações
de modo a separar a existência de comunicação em rede entre processos de
diferentes computadores.
No desenvolvimento de aplicação de rede é importante que a aplicação rode em
sistemas finais diferentes e se comuniquem entre si pela rede, é onde entra a
camada de aplicação, que tem como intuito retirar a necessidade de comunicação
direta com os elementos do núcleo de rede, facilitando o desenvolvimento da
aplicação, sem ter a preocupação com camadas mais baixas (KUROSE; ROSS,
2010).
Resumindo, o modelo OSI tem como finalidade padronizar a forma com
que os protocolos trabalham, utilizando o conceito de camadas onde cada camada
tem sua tarefa específica fornecendo serviços às camadas vizinhas.
2.3 Modelo de referência TCP/IP
Com a necessidade de conectar diversas redes de modo uniforme, foi
criado o modelo de referência TCP/IP, que tem como semelhança ao modelo OSI o
conceito de camadas, onde cada camada tem sua tarefa específica e fornece vários
serviços de modo transparente para as camadas vizinhas (TANENBAUM, 2003).
1 Wikipédia: <https://pt.wikipedia.org/wiki/Camada_de_aplicaç~ao>
Capítulo 2. Revisão da Literatura 9
O modelo TCP/IP contém quatro camadas e pode ser visto na Figura 2:
Figura 2 – Comparativo modelo ISO OSI com modelo TCP/IP Adaptado de: (TA-
NENBAUM, 2003)
O modelo TCP/IP é composto por quatro camadas, descritas a seguir:
1. Camada de aplicação
No modelo TCP/IP a camada de Aplicação engloba também as camadas de
Apresentação e Sessão do modelo ISO OSI, demonstrando uma simplificação
onde a aplicação se responsabiliza por essas partes. A camada de aplicação
contém todos os protocolos de nível mais alto. Dentre eles estão o TELNET
(Network Virtual Terminal Protocol - Protocolo de Terminal Virtual de Rede),
o FTP (File Transfer Protocol - Protocolo de Transferência de Arquivos),
SMTP (Simple Mail Transfer Protocol - Protocolo de Transferência de Correio
Simples), SNMP (Simple Network Management Protocol - Protocolo Simples
de Gerência de Rede), entre outros (TANENBAUM, 2003).
2. Camada de Transporte
Segundo Kurose e Ross (2010) a camada de transporte tem papel fundamental
para fornecer serviços de comunicação diretamente aos processos de aplicação
que rodam em hospedeiros diferentes. Essa camada contém como seus principais
protocolos, o UDP (User Datagram Protocol - Protocolo de Datagrama do
Usuário) e o TCP (Transmission Control Protocol - Protocolo de Controle de
Transmissão).
3. Camada de Inter-redes
Essa camada define um formato de pacote oficial chamado de protocolo IP
(Internet Protocol - Protocolo de Internet).E tem como tarefa entregar pacotes
Capítulo 2. Revisão da Literatura 10
IP onde sejam necessários. Faz o roteamento de pacotes visando evitar o
congestionamento que é uma questão importante nessa camada. Demonstrando
bastante semelhança com a camada de rede do modelo OSI (TANENBAUM,
2003).
4. Host rede
A camada Host rede permite que endereços IP sejam mapeados para endereços
de hardware e encapsular pacotes IP em quadros. Sua principal tarefa é trans-
formar os data-gramas IP em quadros de bits que serão enviados ao hospedeiro
de destino (GHEORGHE, 2006).
Em suma o modelo TCP/IP tem como finalidade padronizar a comu-
nicação no conceito de camadas, mas de forma simplificada e flexível, possui uma
arquitetura de rede aberta, sendo capaz de adaptar as aplicações com requisitos
divergentes (TANENBAUM, 2003).
2.4 Protocolo UDP
Descrito na [RFC768] (POSTEL; PROTOCOL, 1980) o UDP oferece
um meio para as aplicações enviarem conjuntos de bytes sem que seja necessário
estabeleceruma conexão.
O UDP transmite segmentos com cabeçalho de 8 bytes, seguido pela carga
útil, com as portas das máquinas de origem e destino. O cabeçalho pode ser visto na
Figura 3:
Figura 3 – Cabeçalho UDP (KUROSE; ROSS, 2010)
Segundo Kurose e Ross (2010) UDP não realiza controle de fluxo, controle
de erros ou retransmissão após a recepção de um segmento incorreto. Ele fornece
uma interface para o protocolo IP com o recurso adicional de multiplexação de vários
processos que utilizam as portas.
Capítulo 2. Revisão da Literatura 11
É um serviço não orientado para conexão, ou seja, não tem uma fase inicial
de apresentação como no protocolo TCP, onde é estabelecido uma ”tubulação” entre
dois processos. Como o UDP não tem uma ”tubulação”, quando um processo quer
enviar um conjunto de bytes a outro, o processo remetente deve anexar o endereço do
processo destinatário para cada conjunto de bytes que o processo remetente enviar.
O UDP é um modelo de serviço não confiável orientado para mensagem,
no sentido de que faz o melhor esforço para entregar o conjunto de bytes ao destino,
não dando nenhuma garantia de que um ”pacote” alcançará seu destino.
2.5 Gerenciamento de rede e o Protocolo SNMP
Em um contexto histórico (KUROSE; ROSS, 2010) o SNMP (Simple
Network Management Protocol - Protocolo Simples de Gerenciamento de Rede) tem
como raiz o protocolo SGMP (Simple Gateway Monitoring Protocol - Protocolo
de Monitoramento de Gateway Simples) [RFC 1028] (DAVIN et al., 1987) que foi
projetado por um grupo de pesquisadores, usuários e administradores universitários
de rede, que com suas experiências foi possível projetar, implementar o SNMP 1.0
publicado em 1991 e especificado na [RFC 1067] (CASE et al., 1988), evoluindo para
a versão SNMPv1 [RFC 1157] (CASE et al., 1990), posteriormente para a versão
SNMPv2 [RFC 1901] (CASE et al., 1996) e SNMPv3 [RFC 2571] (HARRINGTON;
PRESUHN; WIJNEN, 1999).
Apesar de seu nome SNMP sugerir a simplicidade, o gerenciamento de
rede na Internet é muito mais que apenas um protocolo para transportar dados de
gerenciamento entre uma entidade gerenciadora e seus agentes, sendo mais complexo
que a palavra ”simples” possa sugerir (KUROSE; ROSS, 2010).
Segundo Filho (2012) o SNMP é um protocolo relativamente simples e
robusto, porém suficientemente poderoso para resolver os difíceis problemas apresen-
tados quando se deseja gerenciar redes heterogêneas.
Os recursos gerenciados necessitam de pouco processamento nas tarefas de
gerenciamento. Tarefas complexas de processamento e armazenamento de dados são
de responsabilidade do sistema gerenciador. É um protocolo não orientado a conexão:
não requer ação prévia nem posterior ao envio de mensagens, fazendo com que não
haja nenhuma garantia de que as mensagens do protocolo chegarão ao destino.
O SNMP é um protocolo da camada de aplicação que tem como objetivo
principal coletar informações de dispositivos gerenciáveis, utiliza o protocolo UDP
para enviar suas mensagens através da rede IP (DEO, 2012).
Capítulo 2. Revisão da Literatura 12
A estrutura de gerenciamento definida por Kurose e Ross (2010), é cons-
tituída das seguintes questões:
1. Definições dos objetos de gerenciamento de rede, conhecidos como objetos MIB
(Management Information Base - Base de informações de Gerenciamento).
Na estrutura de Gerenciamento de Padrão da Internet, as informações de
gerenciamento são representadas como uma coletânea de objetos gerenciados
que, juntos, formam um banco virtual de informações virtuais conhecido como
MIB.
Um objeto MIB pode ser um contador, tal como o número de data-gramas
IP descartados em um roteador devido a erros em cabeçalhos de data-gramas
IP ou o número de erros de detecção de portadora em uma placa de interface
Ethernet; um conjunto de informações descritivas, como a versão de software
que está sendo executado em um servidor DNS (Domain Name System - Sistema
de Nomes de Domínios); informações de estado do dispositivo; informações
específicas sobre protocolos. Assim, os objetos MIB definem as informações de
gerenciamento mantidas por um dispositivo gerenciado.
2. Uma linguagem de definição de dados, conhecida como SMI (Structure of
Management Information - Estrutura de Informações de Gerenciamento).
Linguagem que define os tipos de dados, um modelo de objeto e regras para
escrever e revisar informações de gerenciamento. Objetos MIB são especificados
nessa linguagem de definição de dados. Em nossa analogia humana, a SMI é
usada para definir os detalhes do formato das informações que serão trocadas,
assegurando a sintaxe e a semântica de dados.
3. Um protocolo, SNMP.
Protocolo utilizado para a transmissão de informações e comandos entre a
entidade gerenciadora e um agente que os executa no dispositivo de rede
gerenciado.
2.5.1 Arquitetura do SNMP
Segundo Kurose e Ross (2010) essa arquitetura de gerenciamento é modu-
lar, com uma linguagem de definição de dados e de MIB independente de protocolo e
um protocolo independente de MIB. Com a modularidade do projeto SNMP, permitiu
que ele evoluísse mediante as três importantes revisões, cada um com as três partes
mostradas anteriormente.
Capítulo 2. Revisão da Literatura 13
Há três componentes principais em uma arquitetura de gerenciamento
de rede. Uma entidade gerenciadora que realiza ações que monitoram e controlam
os dispositivos gerenciados, os dispositivos gerenciados que são ativos de rede como,
servidores, switches, impressoras, entre outros e os agentes de gerenciamento, sendo
responsáveis pela execução das funções de gerenciamento da rede, requisitadas pela
entidade gerenciadora.
O protocolo SNMP é usado para transportar a informação de geren-
ciamento entre a entidade gerenciadora e os agentes existentes nos dispositivos
gerenciados (KUROSE; ROSS, 2010).
Como pode ser visto na Figura 4:
Figura 4 – Principais componentes da arquitetura SNMP (KUROSE; ROSS, 2010)
O SNMP faz parte da camada de aplicação, com interações sem conexão e
mensagens via protocolo UDP, utiliza as portas 161 e 162 e seu pacotes tem tamanho
variável (DEO, 2012).
2.5.2 PDUs e Mensagem SNMP
O SNMP é um protocolo orientado a pacotes, esses pacotes identificam
uma série de informações, como versão do protocolo, tipo de operação e códigos
Capítulo 2. Revisão da Literatura 14
de erro, que são chamados de PDU (Protocol Data Unit - Unidade de Dados de
Protocolo) (DEO, 2012).
As PDUs do SNMPv1 podem ser vistas na Figura 5
Figura 5 – PDUs do SNMPv1 (DEO, 2012)
As PDUs do SNMP possuem um formato padrão em sua estrutura, esse
formato pode ser visto na Tabela 1:
Tabela 1 – Estrutura Geral PDUs SNMP
0
Conjunto de
Dispositivos
Gerenciáveis
Comandos e Respostas do SNMP
Version community SNMP PDU
Se tratando das funções temos formatos baseados na estrutura geral que
serão mostrados a seguir.
Para as funçõesGetRequest[0],GetNextRequest[1] e SetRequest[3]
são os seguintes formatos descritos na Tabela 2:
Tabela 2 – Funções GetRequest, GetNextRequest e SetRequest
0, 1, 3 Número dasolicitação 0 0
Lista de variáveis
da MIB solicitadas
PDU Type request id error-status error-index variables
Para a função GetResponse[2] é composto pelo seguinte formato des-
crito na Tabela 3:
Tabela 3 – Função GetResponse
2 Número dasolicitação
erro
(se houver)
complemento
(se houver)
Lista de variáveis
da MIB enviadas
PDU Type request id error-status error-index variables
Capítulo 2. Revisão da Literatura 15
E para função Trap[4] seu formato é descrito na Tabela 4 :
Tabela 4 – Função Trap
4
Tipo
do
Objeto
Endereço
do
Agente
Tipo
de
Trap
genérico
Tipo
de
Trap
específico
Hora
do
Trap
Lista
de
variáveis
da
MIB
relacionadas
PDU
Type enterprise
agent-
addr
generic-
trap
specific-
trap
time-
trap variables
A mensagem SNMP possui tamanho variável,limitada a 484 bytes e é
composta pelos campos: Tamanho (2 bytes), Versão do Protocolo (1 byte), a String
da Comunidade (no máximo 128 bytes), Cabeçalho da PDU e o Corpo da PDU
(restante para 484 bytes). Essa estrutura pode ser vista na Figura 6
Figura 6 – Estrutura da mensagem SNMP (DEO, 2012)
Durante a comunicação entre as entidades são trocadas várias mensagens,
essa troca de mensagens pode ser vista na Figura 7:
Capítulo 2. Revisão da Literatura 16
Figura 7 – Troca de mensagens SNMP (FILHO, 2012)
2.5.3 SMI e MIB
A SMI (Structure of Management Information - Estrutura de Informações
de Gerenciamento) é a linguagem usada para definir as informações de gerenciamento
presentes em um dispositivo gerenciado de rede. É a linguagem que assegura que a
sintaxe e a semântica dos dados de gerenciamento de rede sejam bem definidas sem
ambiguidades (KUROSE; ROSS, 2010).
Segundo DEO (2012) a SMI é composta dos seguintes elementos:
1. Identificação
Nomes dos objetos gerenciados: Referenciados através dos OIDs (Object IDen-
tifiers - Identificadores de objeto) que podem ser numéricos ou simbólicos.
• Exemplo numérico:
1 1 . 3 . 6 . 1 . 2 . 1 . 1 . 1 . 0
• Exemplo simbólico:
1 i s o . org . dod . i n t e r n e t .mgmt . mib−2. system . sysDescr . 0
2. Tipo e sintaxe
Sintaxe dos dados: Seguindos os padrões ASN.1 (Abstract Syntax Notation 1 -
Notação de sintaxe abstrata 1).
A ASN.1 é uma linguagem de descrição de dados, definida em formato texto
não ambíguo, que permite definir o modelo de dados com formato independente
de máquina.
Capítulo 2. Revisão da Literatura 17
3. Sintaxe de transferência
Seguindo as regras da BER (Basic Encoding Rules - Regras básicas de codifica-
ção). O método BER define o modo de codificação e decodificação de qualquer
estrutura que seja definida usando ASN.1 para transmissão.
Esses objetos gerenciados são agrupados em uma espécie de base virtual
conhecida como MIB (Management Information Base - Base de Informações de
Gerenciamento) segundo (KUROSE; ROSS, 2010) pode ser imaginada como um
banco virtual de informações que guarda esses objetos gerenciados cujos valores,
coletivamente, refletem o “estado“ atual da rede. Esses valores podem ser consultados
e/ou definidos por uma entidade gerenciadora por meio do envio de mensagens SNMP
ao agente que está rodando em um dispositivo gerenciado em nome da entidade
gerenciadora.
Na Figura 8 pode ser observado a estrutura de nomeação de objetos da
ISO e também a forma de identificação:
Figura 8 – Parte da estrutura hierárquica das variáveis de gerência - Árvore MIB
(RIZO, 2011)
A padronização de módulos MIB é feita pela IETF (Internet Engineering
Task Force - Grupo de trabalho em engenharia da Internet) um grupo auto-organizado,
cujo os membros contribuem para a engenharia e tecnologias de internet, é o principal
órgão envolvido no desenvolvimento de especificações para os padrões da Internet
(RFC 3160) (HARRIS, 2001).
Capítulo 2. Revisão da Literatura 18
Os objetos gerenciados que se encontram no nó system contém informações
gerais do dispositivo que podem ser vistos na Tabela 5:
Tabela 5 – Objetos gerenciados no grupo system da MIB-2 (KUROSE; ROSS, 2010)
Identificador
de objeto Nome Tipo Descrição
1.3.6.1.2.1.1.1 sysDescr OCTETSTRING
"Nome completo e identificação
da versão do tipo de hardware do
sistema, do sistema operacional
do software e do software de rede."
1.3.6.1.2.1.1.2 sysObjectID OBJECTIDENTIFIER
ID atribuído pelo fabricante do
objeto que "fornecem um meio fácil
e não ambíguo para determinar
’que tipo de caixa’ está sendo
gerenciada."
1.3.6.1.2.1.1.3 sysUpTime TimeTicks
"O tempo (em centésimos de
segundo) desde que a porção de
gerenciamento de rede do sistema
foi reiniciado pela última vez."
1.3.6.1.2.1.1.4 sysContact OCTET STRING
"A pessoa de contato para esse nó
gerenciado, juntamente com a
informação sobre como contatá-la."
1.3.6.1.2.1.1.5 sysName OCTET STRING
"Um nome atribuído administrati-
vamente para esse nó gerenciado.
Por convenção, esse é o nome de
domínio totalmente qualificado
do nó."
1.3.6.1.2.1.1.6 sysLocation OCTET STRING "A localização física do nó."
1.3.6.1.2.1.1.7 sysServices Integer32
Um valor codificado que indica
o conjunto de serviços disponível
no nó: aplicações físicas (por exem-
plo, um repetidor), de enlace/sub-
rede (por exemplo, ponte), de Inter-
net (por exemplo, gateway IP), fim
a fim (exemplo, hospedeiro).
2.5.4 Nomeando OIDs
Os objetos gerenciados são organizados em forma hierárquica como uma
árvore, onde é composto por uma série de inteiros nos nós da árvore e separados por
pontos. Outra forma mais amigável e legível ao administrador é, utilizar os próprios
rótulos textuais de cada nó também separados por pontos (FILHO, 2012).
Como pode ser visto na Figura 8 abaixo da raiz cada nó possui um rótulo
e um número. Por exemplo, o nó com rótulo ”org” e número 3.
Capítulo 2. Revisão da Literatura 19
Cada objeto então tem o seu OID formado através do caminho entre a
raiz e o objeto desejado, por exemplo, um objeto que tem OID igual a:
1 i s o . org . dod . i n t e r n e t .mgmt . mib−2. system . sysDescr
Esse OID identifica um objeto simples que possua apenas uma única
instância, formando então o nome simbólico:
1 i s o . org . dod . i n t e r n e t .mgmt . mib−2. system . sysDescr . 0
Dando destaque ao final 0 que define a instância do objeto.
De forma numérica seria:
1 1 . 3 . 6 . 1 . 2 . 1 . 1 . 1 . 0
Muitos objetos terão várias instâncias, como dispositivos de rede que
possuam várias interfaces, sendo então definido um número final diferente para cada
interface.
Como exemplo, esse OID:
1 i s o . org . dod . i n t e r n e t .mgmt . mib−2. i n t e r f a c e s . i f t a b l e . i fEnt ry . i f I nOc t e t s
Esse OID representa o número de bytes recebidos em uma interface de
rede, aplicando isso em um dispositivo que tenha 4 interfaces de rede, uma instância
para cada interface:
1 Interface 1
2 i s o . org . dod . i n t e r n e t .mgmt . mib−2. i n t e r f a c e s . i f t a b l e . i fEnt ry . i f I nOc t e t s . 0
3
4 Interface 2
5 i s o . org . dod . i n t e r n e t .mgmt . mib−2. i n t e r f a c e s . i f t a b l e . i fEnt ry . i f I nOc t e t s . 1
6
7 Interface 3
8 i s o . org . dod . i n t e r n e t .mgmt . mib−2. i n t e r f a c e s . i f t a b l e . i fEnt ry . i f I nOc t e t s . 2
9
10 Interface 4
11 i s o . org . dod . i n t e r n e t .mgmt . mib−2. i n t e r f a c e s . i f t a b l e . i fEnt ry . i f I nOc t e t s . 3
Com um número final diferente para cada instância do objeto, neste caso
representado por cada interface de rede.
Capítulo 2. Revisão da Literatura 20
2.5.5 Definindo OIDs
A SMIv1 define vários tipos de dados para o gerenciamento dos dispositivos
de rede através dos padrões ASN.1, de maneira a definir que tipo de informação um
objeto gerenciado pode conter.
Tabela 6 – Tipos de dados SMIv1 (FILHO, 2012)
TIPO DE DADO DEFINIÇÃO
Integer Usado para representar números inteiros.
Octet String Armazena uma sequência de bytes. Dele se derivam três subtipos:DisplayString, OctetBitString e PhysAddress.
Counter Representa um contador que unicamente pode incrementar seu valore ao chegar em seu valor máximo, volta a zero.
Object Identifier Usado para representar os identificadores dos objetos, isto é, a posiçãode um objeto dentro da árvore da MIB.
Null Representa a ausência de um valor. Atualmente não é utilizado noSNMP.
Sequence É uma estrutura de dados, ou seja, uma lista ordenada de tipos dedados diferentes.
Sequence of É uma lista ordenada de tipos de dados iguais. É parecido com otipo "SEQUENCE", exceto que todos os tipos têm de ser iguais.
IpAddress Representa um endereço Ipv4 de 32 bits.
NetworkAddress O mesmo que “IpAddress”, mas pode representar tipos deendereços de redes diferentes.
GaugePode incrementar ou decrementar, mas nunca pode excederseu valor máximo.
TimeTicks É um tipo de dados usado para medir tempos.
Opaque Permite que qualquer outra codificação ASN.1 possa sercolocada em um Octect String.
A SMIv2 adiciona outros tipos de dados novos e algumas alterações
Os novos tipos de dados da SMIv2 são:
Tabela 7 – Novos tipos de dados SMIv2 (FILHO, 2012)
TIPO DE DADO DEFINIÇÃO
Integer32 Idêntico ao INTEGER.
Counter32 Idêntico a Counter.
Gauge32 Idêntico ao Gauge.
Unsigned32 Representa valores decimais no intervalo de 0 a 232 – 1.
Counter64 Semelhante ao Counter32, mas o valor máximo é 264.
BITS Uma lista de bits não negativos.
Capítulo 2. Revisão da Literatura 21
2.5.6 Versões do SNMP
Como já foi dito na seção 2.5, o protocolo SNMP é composto por 3 versões
principais, o SNMPv1, SNMPv2 e SNMPv3 cada um com suas operações básicas
que podem ser vistas a seguir:
1. SNMPv1
Operações básicas:
Tabela 8 – Operações básicas SNMPv1 (DEO, 2012)
Trap Usado para adquirir o valor de umaou mais instâncias de um objeto de um agente.
GetNext Usado para adquirir o valor do próximo objetoem uma tabela ou lista.
Set Usado para atribuir um valor a um objeto no agente.
2. SNMPv2
Operações básicas:
Tabela 9 – Operações básicas SNMPv2 (DEO, 2012)
Trap
Mensagem não solicitada, enviada por um
agente para informar sobre um evento
significante
Get Bulk Usado para adquirir eficientementegrandes blocos de dados.
Inform
Permite que a entidade gerenciadora envie
traps para outra entidade gerenciadora e
receba respostas desses traps.
3. SNMPv3
Tabela 10 – Operações básicas SNMPv3 (DEO, 2012)
USM Modelo de segurança baseada em usuários.
VACM Modelo de controle de acesso baseado em visões.
Configuração dinâmica
de agentes SNMP
Configura dinamicamente o agente SNMP,
via comando, conta objetos MIB que representam configuração
de agente, permite adição, exclusão, modificação local e remoto.
Conforme definido no levantamento de requisitos, foi escolhido a versão
SNMPv2c que é uma variante do SNMPv2 para a implantação no cenário do HUJM,
Capítulo 2. Revisão da Literatura 22
pela incompatibilidade com a versão 3 em alguns dos ativos de rede presentes no
local.
Na próxima seção será abordado com maior detalhamento essa versão.
2.5.7 SNMPv2c
O modelo mais comumente utilizado é o SNMPv2 e SNMPv2c, o v2c é
baseado no conceito de comunidade (DEO, 2012).
O conceito de comunidade pode ser entendido como uma forma de auten-
ticação, como se fosse uma senha, onde pode-se definir títulos como combinações de
siglas, palavras ou como desejar, aumentando o grau de segurança.
Esse modelo tem como padrão as Comunidades:
Public com permissão apenas de leitura, Private com permissão para
gravação e Personalizado com nome e permissão definida pela pessoa responsável.
Apesar de todas as mensagens SNMP serem autenticadas com a comu-
nidade, é um sistema frágil. Alguns dispositivos tem suporte para definir o IP do
gerente melhorando a segurança (DEO, 2012).
Segundo Filho (2012) o SNMPv2 surgiu para suprir algumas deficiências
do SNMPv1 , implementando além das cinco funções básicas conforme a Figura 5-
getrequest, get-next-request, set-request, response e snmpV2-trap
(as funções getresponse e trap tiveram seus nomes modificados, respecti-
vamente para response e snmpV2-trap) - outras novas funções foram adicionadas:
1. Get-bulk-request: acesso a grandes blocos de informações na MIB;
2. Inform-request: permite que um gerente envie informações relevantes direta-
mente a outros gerentes.
Dentre as novidades do SNMPv2, destacam-se:
O Gerenciamento de redes descentralizadas, que permite existir mais
de uma estação gerenciadora e troca de informações entre elas, possibilidade de
transferência de grandes blocos de informação, introdução de contadores de 64 bits,
podendo monitorar variáveis que atingem rapidamente os limites de contadores de
32 bits e melhoria no tratamento de erros das variáveis, determinando o estado de
sucesso ou erro da operação para cada variável da PDU e não mais para a PDU
inteira, não sacrificando toda a PDU, preenchendo o campo que ocorreu o problema
com código de erro. (FILHO, 2012)
Capítulo 2. Revisão da Literatura 23
2.6 Ferramentas
2.6.1 Cacti
Cacti2 é uma solução completa de software livre para monitoramento de
ativos de rede e geração de gráficos de rede. Proporciona um poller rápido, avançados
templates gráficos, múltiplos métodos de aquisição de dados inclusive via protocolo
SNMP. Trabalha com RRDTool (Round Robin Database Tool - Base de dados round-
robin) que é responsável por armazenar os dados escolhidos e gerar gráficos, banco
de dados MySQL, linguagem PHP e servidor Apache Server.
2.6.2 Nagios
Nagios3 é um sistema de monitoramento Open Souce que permite mo-
nitorar toda a infraestrutura de redes, suporta vários métodos/protocolos para
monitoramento dos ativos de rede como SNMP, ICMP, HTTP, SMTP, e outros.
Conta também com alertas em casos de falha e é disponível gratuitamente para as
organizações que não necessitem de suporte para sua implementação.
2.6.3 PRTG
O PRTG4 é um sistema de monitoramento de ativos que trabalha com
licenciamentos, conta com pacotes com quantidade de sensores, o menor pacote é o
PRTG 500 composto por 500 sensores, durante 12 meses, no valor de US$ 1,600.00,
todos os pacotes contam com suporte 24h. Usa uma interface intuitiva, é possível
administrar o sistema, instalar sensores, cofigurar relatórios e avaliar os resultados
obtidos. É possível gerar relatórios e conceder acesso aos colegas e clientes aos
gráficos e tabelas com dados em tempo real. Suporta os seguintes métodos para
monitoramento: (SNMP, WMI, Packet Sniffing, NetFlow, jFlow e sFlow).
2.6.4 Zabbix
Zabbix5 é uma ferramenta moderna para Monitoramento de Ativos de
Rede, Open Source e multiplataforma, livre de custos de licenciamento, pois sua
licença é a GPLv2 (GNU General Public License - Licença Pública Geral). Pode ser
instalado nas mais conhecidas distribuições Linux do mercado (Ubuntu, Debian, BSDs,
CentOs e outros). Diferente de todas as ferramentas de monitoramento comerciais
2 <http://www.cacti.net/>
3 <https://www.nagios.org/>
4 <https://www.br.paessler.com/prtg>
5 <https://www.zabbix.com/>
Capítulo 2. Revisão da Literatura 24
que são caras e exigem conhecimentos avançados para utilizá-las, o Zabbix é intuitivo,
tem uma comunidade grande de apoiadores com muito material de apoio e não exige
um conhecimento avançado (HORST; PIRES; DÉO, 2015).
Todos os relatórios, gráficos e estatísticas, bem como os parâmetros de
configuração, são acessados através de uma ferramenta Web que é o front-end do
produto. Utiliza um Sistema de Gerenciamento de Banco de Dados (SGBD) para
armazenamento dos dados de coletas e configurações. Tem suporte a várias bases de
dados: MySQL/Mariadb, PostgreSQL, SQLite, Oracle e IBM DB2.
Suporta vários protocolos para o monitoramento dos ativos: SNMP, ICMP,
HTTP, POP3, IMAP, e outros. Conta com agente próprio para coleta de dados,
que tem suporte a várias plataformas como: Linux, Solaris, HP-UX, AIX, FreeBSD,
OpenBSD, NetBSD, Mac OS X, Windows, e outros, tanto 32 quanto 64 bits.
Conta com o conceito de Trigger (Gatilho), termo que remete a banco
de dados, nomenclatura adotada para a execução automatizada de procedimentos
sempre que um evento acontecer, ou determinada condição for alcançada, podendo
ser entendida como uma marca-d’água, ou seja, são as condições que demarcam
quando um evento é um incidente e então faça o disparo de alertas(HORST; PIRES;
DÉO, 2015).
Os alertas podem ser recebidos através de várias formas de comunica-
ção como: SMS, E-mail, Jabber. Também entrega possibilidade de criar scripts
personalizados.
CAPÍTULO 3
MATERIAIS, TÉCNICAS E MÉTODOS
3.1 Local do experimento
O estágio supervisionado foi realizadono Setor de Gestão de Processos e
Tecnologia da Informação (SGPTI) do Hospital Universitário Júlio Müller (HUJM)
situado na Rua Luís Philipe Pereira Leite, Bairro Alvorada, Cuiabá - MT.
3.2 Infraestrutura
O Cabeamento é semi-estruturado, com algumas partes utilizando cabea-
mento de classe 5E para distribuição, classe 6E entre patch-panels e switches, e entre
alguns nós que ficam em prédios distintos também é utilizado fibras óticas com tipo
de transmissão de luz multimodo1. A topologia geral é na forma de estrela estendida
onde o nó central fica dentro de um CDC (Containerized Data Center - Centro de
Dados em Container)2 e os distribuidores nos prédios adjacentes do Hospital.
1 Fibra que transmite vários feixes de luz com o mesmo comprimento de onda
<http://goo.gl/FsrTxD>.
2 Conceito de construção modular utilizando Containers Marítimos.
Capítulo 3. Materiais, Técnicas e Métodos 26
Na Figura 9 pode ser visto a topologia dos Switches.
Figura 9 – Visão geral dos Switches
Na Figura 10 o CDC pode ser visto de fora.
Figura 10 – Visão externa do CDC
Capítulo 3. Materiais, Técnicas e Métodos 27
Na Figura 11 pode ser visto parte interna do CDC com visão para o
no-break de grande porte.
(a) No-break fechado (b) No-break aberto
Figura 11 – Estrutra Interna (No-break de grande porte)
Na Figura 12 pode ser visto o sistema de combate a incêndios e alguns
servidores alocados em um raque.
(a) Sistema de segurança em
caso de incêndios
(b) Alguns servidores no ra-
que
Figura 12 – Estrutura Interna (Extintor e Servidores)
Capítulo 3. Materiais, Técnicas e Métodos 28
Na Figura 13 é possível visualizar os patch-panels que interligam toda a
rede do hospital.
(a) Patch-panels vista frontal (b) Patch-panels vista traseira
Figura 13 – Estrutura Interna (Raque com patch-panels)
Na Figura 14 pode ser visto o Gerador elétrico dedicado ao CDC que gera
alta disponibilidade ao CDC.
Figura 14 – Gerador elétrico dedicado ao CDC
Capítulo 3. Materiais, Técnicas e Métodos 29
3.2.1 Servidor
O Servidor utilizado para a hospedagem das máquinas virtuais é um
”IBM System x3650 M3” com processador Intel(R) Xeon(R) CPU X5650 @ 2.67GHz,
com 64GB de memória RAM, 8 Discos Rígidos de 600GB cada um, em RAID3 5,
subtraindo um disco para paridade e outro reserva, totaliza aproximadamente 3,26TB
para uso. O sistema de gestão das máquinas virtuais é o VMware ESXi 5.5.04.
Na Figura 15 pode ser visto a aparência física do servidor em questão.
Figura 15 – Imagem ilustrativa do servidor utilizado3
3.3 Levantamento de Requisitos
O levantamento de requisitos foi realizado por meio de uma entrevista
informal com o Supervisor do estágio e gestor do SGPTI Leonardo Luiz Braun acom-
panhado do Analista de Redes Helton Carlos Lima Godoy, onde foram identificados
as seguintes necessidades: Aplicar uma solução para monitorar os ativos de rede
presentes, composto pelos seguintes dispositivos: Switches, Servidores, Impressoras e
Relógios de Ponto.
Também foram levantadas algumas restrições como: Utilizar de ferramen-
tas gratuitas visando o custo-benefício, utilizar uma máquina virtual em um dos
servidores de virtualização como servidor hospedeiro da ferramenta e sigilo sobre
informações da rede do Hospital, omitindo IPs, logins, senhas, ou qualquer informação
que venha a ser sensível.
3 Redundant Array of Independent Disks - Matriz Redundante de Discos Independentes
<http://www.infowester.com/raid.php>
4 <https://www.vmware.com/support/vsphere5/doc/vsphere-esx-vcenter-server-55-release-notes.
html>
3 <https://lenovopress.com/tips0805-system-x3650-m3>
Capítulo 3. Materiais, Técnicas e Métodos 30
3.4 Ferramentas utilizadas
Após o levantamento de requisitos e leitura sobre as ferramentas, foi
definido a utilização da ferramenta de monitoramento Zabbix, por ser uma ferramenta
gratuita, conhecida entre a comunidade, conta com conteúdo vasto na internet,
consolidada, diversos recursos, esteticamente bonita e atende todos os requisitos
levantados.
3.5 Configuração da máquina virtual
Foi utilizado o VMware vSphere Client que é o gerenciador das máqui-
nas virtuais neste servidor. A máquina virtual foi configurada com as seguintes
configurações:
• 2GB de memória RAM;
• 40GB de armazenamento;
• 2 núcleos do processador;
• 1 Interface de rede Gigabit.
Na Figura 16 é possível visualizar o sumário da máquina virtual criada no vSphere.
Figura 16 – Sumário da máquina virtual no vSphere
Para instalação do Zabbix essa máquina virtual foi preparada com Sistema
Operacional Ubuntu Server 16.04, após a máquina preparada o Zabbix foi instalado
Capítulo 3. Materiais, Técnicas e Métodos 31
seguindo os passos descritos no Anexo A para a instalação e configuração inicial do
Zabbix versão 3.0.4.
3.6 Cenários de Testes
A implantação dessa solução foi composta por dois ambientes: Ambiente
de Testes e Ambiente de Produção.
Os ambientes de testes foi feito em máquinas virtuais no próprio com-
putador pessoal e o ambiente de produção ocorreu na máquina virtual descrita na
Seção 3.5.
O processo aconteceu da seguinte forma, as configurações primeiramente
foram feitas em ambiente de testes realizando os devidos ajustes e posteriormente
após os resultados obtidos, a configuração era então feita no ambiente de produção.
3.6.1 Cenário 1 - Monitoramento de todos os ativos de rede
O monitoramento de todos os ativos de rede foi composto por 151 dispo-
sitivos internos, dentre eles 1 Firewall, 39 Switches, 32 Máquinas Virtuais, 8 Relógios
de Ponto e 71 Impressoras, contando também com 4 dispositivos externos.
Todos os dispositivos internos estão em VLANs distintas conforme sua
categoria, e o Servidor Zabbix em uma VLAN sem restrição a todas as outras.
O monitoramento dos Switches, Máquinas Virtuais e Impressoras, foi feito
via SNMP na versão 2c, enquanto os Relógios de Ponto e Dispositivos Externos via
ICMP, e do Firewall utilizando o próprio agente do Zabbix.
Nos dispostivos externos 3 deles são Fornecedores de acesso à internet,
conhecidos pela sigla ISP (Internet Service Provider), onde cada um desses 3 ativos
se trata de dispositivos que exercem o encontro entre duas redes, também conhecidos
como dispositivos de borda ou switches de borda. São 3 Links de internet distin-
tos para maior disponibilidade, havendo a necessidade do monitoramento desses
dispositivos para maior controle sobre a disponibilidade desses ISPs.
O quarto dispositivo externo se trata da EBSERH Sede (Empresa Brasi-
leira de Serviços Hospitalares) onde são mantidas diversas bases de dados e sistemas
integrados com o HUJM, levantando a necessidade de monitorar possíveis interrup-
ções.
Capítulo 3. Materiais, Técnicas e Métodos 32
3.6.2 Cenário 2 - Alerta de Desastre
Os incidentes em que um ativo de rede permaneça por mais de cinco
minutos sem atualização de seu estado pode ser um indicio de falha no mesmo, ou
falha na rede, gerando então um alerta de incidente com severidade de desastre, com
aviso visual no Zabbix e também o envio de um e-mail com o aviso desse incidente.
Esse procedimento foi então configurado da seguinte forma:
Criou-se uma Trigger (Gatilho) utilizando o item sysUpTime que regis-
tra o tempo de atividade do dispositivo, com a seguinte configuração:
1 {NOME_DO_HOST: sysUpTime . nodata (5m)}=1
Essa trigger faz a verificação no item sysUpTime, se este item perma-
necer por 5 minutos sem alterações sinalizando uma possível falta de comunicação
ou falha no dispositivo, será então disparado um alerta de cor vermelha com status
Incidente conforme a Figura 17, para o dispositivo, nesse caso chamado de SWITCH
GEP SW-13:
Figura 17 – Configuração da Trigger de Desastre
Apartir dessa trigger foi criado uma Ação de envio de e-mails, que faz
o envio desse alerta via e-mail para os usuários definidos, podendo também definir
sobre quaisgrupos de hosts essa ação pode acontecer, como pode ser visto na Figura
18 onde foi definido os grupos Switches e Virtual machines.
Capítulo 3. Materiais, Técnicas e Métodos 33
Figura 18 – Ação para envio de alertas via e-mail
3.6.3 Cenário 3 - SLA Aceitável
Se tratando de um ambiente extremamente crítico como o do Hospital onde
qualquer problema na infraestrutura de redes pode ocasionar problemas irreparáveis
para os pacientes, foi então definido um Acordo de Nível de Serviço (SLA - Service
Level Agreement) para os ativos de rede, com um nível minimo aceitável sobre o
tempo que os ativos de rede permaneçam em incidentes.
Foi definido para cada Ativo de rede, um SLA aceitável de 99,9% para os
grupos de Switches, Servidores, Relógios de Ponto e Firewalls, que contabiliza entre
40 à 50 minutos por mês, e 45,83% para o grupo de Impressoras que contabiliza entre
6 à 7 horas por dia, simbolizando o horário comercial.
Na Figura 19, pode ser visto o SLA criado para o SWITCH GEP
SW-13.
Figura 19 – SLA Aceitável para o SWITCH GEP SW-13
CAPÍTULO 4
RESULTADOS
4.1 Cenário 1
Para o monitoramento de todos os ativos de rede foram criados mapas com
representações visuais desses ativos para uma melhor visualização e entendimento
da estrutura de redes. Na Figura 20 pode ser visto um mapa customizado com o
panorama geral dos dispositivos monitorados no Zabbix, alguns dos itens são grupos
de ativos, como os itens: Impressoras, Relógios de Ponto, Servidores Hipervisores,
Switches, e os dispositivos externos com suas respectivas nomenclaturas adotadas.
Figura 20 – Mapa com panorama geral dos ativos de rede
Capítulo 4. Resultados 35
É possível observar círculos vermelhos em alguns itens simbolizando
incidentes, esses incidentes foram configurados conforme a trigger definida na seção
3.6.2.
Também foi criado mapas específicos para cada grupo de ativos de rede,
com o intuito de entregar uma melhor visualização detalhada dos ativos de rede.
Na Figura 21 pode ser visto um panorama de todas as 71 impressoras
monitoradas, todas com nomenclatura conforme o setor em que está localizada, é
possível ver 6 impressoras com incidentes, que provavelmente estariam desligadas
pelo horário do dia.
Figura 21 – Mapa com panorama das impressoras
Capítulo 4. Resultados 36
O grupo de relógios de ponto pode ser visto Figura na 22, os ícones foram
customizados com a imagem do modelo do relógio utilizado, todos com nomenclaturas
conforme a localização deles no hospital, com seus respectivos estados OK sinalizando
o funcionamento normal.
Figura 22 – Mapa com panorama dos relógios de ponto
As máquinas virtuais foram separadas em 3 mapas distintos, um mapa
para cada servidor físico, na Figura 23 pode ser visto um mapa com os 3 servidores
com alertas de incidente em 2 deles, como são grupos, esses incidentes demonstram
que em alguma máquina virtual localizada dentro de algum desses servidores ocorreu
um incidente e não no servidor inteiro.
Figura 23 – Mapa com panorama dos servidores
Capítulo 4. Resultados 37
O Servidor IBM VMWARE 10 pode ser visto na Figura 24 com suas
respectivas máquinas virtuais, com 2 incidentes que também foram representados na
Figura 23. Essas duas máquinas virtuais com incidentes no momento da captura de
tela estavam desligadas, por isso a falta de comunicação.
Figura 24 – Mapa com panorama do servidor IBM VMWARE 10
No Servidor IBM VMWARE 20 as máquinas virtuais estão todas com o
estado OK, sinalizando funcionamento normal, conforme pode ser visto na Figura
25.
Figura 25 – Mapa com panorama do servidor IBM VMWARE 20
Capítulo 4. Resultados 38
O Servidor IBM VMWARE 30 e suas máquinas virtuais em estados
variados, com 2 delas em momento de incidente, com circulo vermelho simbolizando
Incidente com severidade Desastre e com circulo amarelo, simbolizando Incidente de
severidade média o ocasionado por uma trigger que verifica a porcentagem de uso
pelos processos e dispara quando passa de 75% de uso, conforme pode ser visto na
Figura 26.
Figura 26 – Mapa com panorama do servidor IBM VMWARE 30
Capítulo 4. Resultados 39
4.2 Cenário 2
Os Alertas de incidentes com severidade desastre podem ser vistos na
tela de eventos (Monitoramento > Eventos) Figura 27, com informações de horário,
descrição sobre o evento, o estado desse evento que pode ser Incidente ou OK, a
severidade que neste caso é Desastre com fundo vermelho pra Incidente e Desastre
com fundo verde para OK, tempo de duração do evento tanto para OK quanto para
Incidente, o reconhecimento que é um recurso onde é possível deixar uma nota de
explicação sobre tal evento, e por fim a coluna ações que funciona como um contador,
contando as ações que foram executadas por evento, verificando a primeira linha onde
foram executadas 4 ações, essas ações significam 4 envios de e-mail, um para cada
usuário definido. Também apartir de um clique em cima desse contador, é possível
visualizar as ações executadas para cada evento de incidente como pode ser visto na
Figura 28.
Figura 27 – Aba Eventos com incidentes ocorridos
Figura 28 – Informações das ações
Capítulo 4. Resultados 40
Os e-mails enviados podem ser vistos nas Figuras 29 e 30, a estrutura
foi customizada deixando apenas as informações relevantes ao cenário, que são as
seguintes: uma descrição sobre o incidente juntamente com o nome do ativo de rede,
o estado desse incidente, a severidade e o estado da trigger que disparou essas ação e
um ID do evento para registro.
Figura 29 – Alerta de desastre recebido via e-mail
Figura 30 – Alerta de recuperação recebido via e-mail
Capítulo 4. Resultados 41
4.2.1 Cenário 3
Os Acordos de nível de serviço (SLA) foram feitos individualmente para
cada ativo de rede, como pode ser visto na Figura 31 onde o grupo de Switches
foi definido com SLA aceitável de 99,9% e dentro de um período de 4 dias, todos
Switches mantiveram 100% de atividade.
Figura 31 – Panorama de SLAs de todos os Switches
As máquinas virtuais em sua maioria mantiveram dentro do SLA aceitável
de 99,9% durante o período de amostragem, apenas 3 delas ficaram abaixo, pelo
Capítulo 4. Resultados 42
motivo de estarem desligadas para manutenção, não ocorrendo coleta de dados. O
panorama das máquinas virtuais pode ser visto na Figura 32:
Figura 32 – Panorama de SLAs de todas máquinas virtuais
Capítulo 4. Resultados 43
O SLA do Firewall também foi calculado conforme a Figura 33, obtendo
uma taxa de 100% de atividade mantendo-se dentro da faixa aceitável de 99,9%
definida no cenário.
Figura 33 – Panorama de SLA do Firewall
No grupo de Impressoras foi possível notar vários SLAs abaixo do aceitável,
pelo motivo de que em alguns setores os funcionários desligam a impressora quando
não está em uso, não sendo possível a coleta de dados, gerando então incidentes. Na
Figura 34 pode ser visto um panorama do grupo das impressoras.
Capítulo 4. Resultados 44
Figura 34 – Panorama de SLAs de todas as impressoras
Capítulo 4. Resultados 45
Na Figura 35 a Impressora da Prescrição da Clínica Cirúrgica, com estado
OK pois no momento dessa captura de tela ela estava ativa. Também é possível ver
que seu SLA está no limite aceitável.
Figura 35 – SLA da Impressora da Prescrição da Clínica Cirúrgica
Já na Figura a Impressora da Oftalmologia aparece com Estado de
Desastre, ou seja, no momento da captura de tela ela está desligada, porém seu SLA
está dentro do aceitável.
Figura 36 – SLA da Impressora da Oftalmologia
Nos relógios de ponto foi observado um SLA muito baixo, foi identificado
então que dois deles ficaram quase 3 dias desligados conforme a Figura 37. Como foi
durante o final de semana não teve grande impacto, mas deve ser observado.
Figura 37 – Panorama de SLAs de todos os Relógio de ponto
É interessante ressaltar, que com o SLA também é possível perceberpossíveis instabilidades em locais/setores, pois a nomenclatura dos ativos de rede
conta com as siglas dos locais/setores.
CAPÍTULO 5
CONCLUSÕES
O ambiente hospitalar é um cenário crítico, qualquer interrupção pode
gerar consequências irreparáveis, e como foi dito na introdução, a tecnologia é parte
integrante e fundamental em todos os setores hospitalares e tende a estar cada vez
mais presente, gerando uma necessidade de monitorar toda a infraestrutura de redes
efetuando a prevenção de incidentes.
Através de um levantamento de requisitos via entrevistas informais com
o supervisor do estágio e gestor do SGPTI Leonardo Luiz Braun acompanhado do
analista de redes Helton Carlos Lima Godoy, foi levantado o problema e as possíveis
soluções na qual foi escolhido o Zabbix, que melhor atendeu as necessidades.
Com a implantação do gerenciamento de ativos de rede utilizando a
ferramenta Zabbix via protocolo SNMP, foi possível suprir todas as necessidades
levantadas, monitorando toda a infraestrutura de redes de computadores presente no
HUJM em tempo real, alcançando o objetivo geral deste trabalho.
O período de testes foi imprescindível para observar todo o potencial que
a ferramenta Zabbix poderia oferecer, se mostrando totalmente capaz de atender o
cenário, com total estabilidade em todos os testes efetuados.
Através dos resultados obtidos a avaliação da solução foi satisfatória,
como dito anteriormente, foi possível atender a todas as necessidades propostas,
Capítulo 5. Conclusões 47
podendo ser levada para ambiente de produção efetuando a homologação junto ao
HUJM.
É interessante ressaltar o consumo de banda que foi gerado por esse
monitoramento, um consumo baixíssimo mantendo uma média de entrada 187.4kbps
e saída 62,23kbps para os 151 ativos de rede, demonstrando a viabilidade dessa
solução.
Durante todo o trabalho o aprendizado foi imenso, tendo contato com
vários sistemas e dispositivos de diversas marcas e tecnologias proporcionando colocar
em prática vários conceitos vistos no decorrer da graduação.
5.1 Dificuldades encontradas
No incio do desenvolvimento foi preciso mapear os ativos de rede, princi-
palmente os switches, para adiciona-los de forma estruturada e também para montar
os mapas, foi preciso então verificar as VLANs em cada porta de cada switch, gerando
uma certa dificuldade por nunca ter tido contato, gastando um bom tempo nisso,
mas também serviu como aprendizado sendo possível adquirir uma boa noção sobre
VLANs e Switchs gerenciáveis.
Outra dificuldade encontrada foi na configuração do SLA (Acordo de nível
de serviço), que foi preciso configurar os ativos de rede um a um, nomeando, setando
a trigger e porcentagem aceitável, demandando bastante trabalho. A configuração das
ações de alertas via e-mail também foi problemática, primeiramente para entender a
forma como funcionava a configuração das ações, depois na configuração do e-mail
utilizado para envio dos alertas. Em um dos testes, chegou a enviar mais de 900
e-mails de alertas, "inundando"a caixa de entrada de teste.
48
REFERÊNCIAS
CASE, J. et al. RFC 1067: Simple Network Management Protocol. [S.l.], 1988. 11
CASE, J. et al. RFC 1157: Simple network management protocol (SNMP). [S.l.],
1990. 11
CASE, J. et al. RFC 1901: Introduction to Community-based SNMPv2. [S.l.], 1996.
11
DAVIN, J. et al. RFC 1028: Simple gateway monitoring protocol. [S.l.], 1987. 11
DEO, A. L. B. Apostila Gerenciamento de redes com SNMP. [S.l.]: Agência para
Formação Profissional da Unicamp, 2012. vii, ix, 11, 13, 14, 15, 16, 21, 22
FEUERWERKER, L. C. M.; CECÍLIO, L. C. d. O. O hospital e a formação em
saúde: desafios atuais. Ciência & Saúde Coletiva, ABRASCO-Associação Brasileira
de Saúde Coletiva, 2007. 1
FILHO, O. P. Gerenciamento e monitoramento de redes ii: Análise de desempenho.
p. 28, 2012. vii, ix, 11, 16, 18, 20, 22
GHEORGHE, L. Designing and Implementing Linux Firewalls with QoS using
netfilter, iproute2, NAT and l7-filter. [S.l.]: Packt Publishing Ltd, 2006. 10
HARRINGTON, D.; PRESUHN, R.; WIJNEN, B. RFC 2571: An Architecture for
Describing SNMP Management Frameworks. [S.l.], 1999. 11
HARRIS, S. The tao of IETF: A novice’s guide to the internet engineering task
force (RFC 3160, FYI 17). 2001. 17
HORST, A.; PIRES, A.; DÉO, A. De a a zabbix. São Paulo: Novatec Editora, 2015.
24
Referências 49
KUROSE, J. F.; ROSS, K. W. Redes de Computadores e a Internet: Uma abordagem
top-down. Trad. 5 ed. São Paulo: Pearson, 2010. vii, ix, 4, 5, 8, 9, 10, 11, 12, 13, 16,
17, 18
POSTEL, J.; PROTOCOL, U. D. Rfc 768. User datagram protocol, 28August, p. 1–3,
1980. 10
RIZO, E. H. MIB – Management Information Base (Base de Informação
de Gerenciamento). 2011. <http://www.eduardorizo.com.br/2011/10/24/
mib-management-information-base-base-de-informacao-de-gerenciamento/>.
Acessado em: 02/08/16. vii, 17
TANENBAUM, A. S. Redes de Computadores. trad. 4 ed. Rio de Janeiro: Elsevier,
2003. vii, 4, 5, 6, 7, 8, 9, 10
50
ANEXO A
TUTORIAL INSTALAÇÃO DO ZABBIX
3.0.4 NO UBUNTU 16.04 COM MYSQL
Este material foi adaptado apartir do Tutorial ”Tutorial de Instalação
do Zabbix 3.x no Debian e Ubuntu com MySQL ou PostgreSQL”1 criado por Aécio
dos Santos Pires e publicado no site Zabbixbrasil.org2 licenciado sob uma licença
Creative Commons3 Atribuição-NãoComercial 4.0 Internacional.
A seguinte instalação se refere ao Zabbix 3.0.4 em Ambiente GNU/Linux
Ubuntu Server 16.04 com Java e Banco de dados MySQL.
A.1 Instalando e configurando as dependências
Instalação feita via terminal com os seguintes comandos:
1 $ sudo su
2 # apt update
1 <http://zabbixbrasil.org/files/Tutorial_de_instalacao_do_Zabbix_3_debian_ubuntu_
mysql_postgres_v2.pdf>
2 <http://zabbixbrasil.org/>
3 <https://br.creativecommons.org/>
ANEXO A. Tutorial Instalação do Zabbix 3.0.4 no Ubuntu 16.04 com MySQL 51
3 # apt -y install build-essential snmp vim libssh2-1-dev
libssh2-1 libopenipmidev libsnmp-dev wget libcurl4-gnutls-
dev fping libxml2 libxml2-dev curl libcurl3-gnutls libcurl3-
gnutls-dev libiksemel-dev libiksemel-utils libiksemel3
4 # apt -y install python-software-properties
5 # add-apt-repository -y ppa:webupd8team/java
6 # add-apt-repository -y ppa:ondrej/php
7 # apt update
8 # apt -y install oracle-java8-installer oracle-java8-set-default
9 # apt install -y apache2 php5.6 php5.6-mysql libapache2-
mod-php5.6 php5.6-gd php5.6-bcmath php5.6-mbstring
php5.6-xml php-net-socket libpq5 libpq-dev mysql-server
mysql-client libmysqld-dev
A.2 Criando o banco de dados no MySQL
Criação do banco de dados zabbix e o usuário zabbix que acessará o
banco.
Criar uma senha para o usuário Zabbix acessar o banco.
10 # mysql -u root -p
11 # mysql> create database zabbix character set utf8;
12 # mysql> GRANT ALL PRIVILEGES ON *.* TO zab-
bix@localhost IDENTIFIED BY ”SUA SENHA” WITH
GRANT OPTION;
14 # mysql> quit
A.3 Configurando o PHP
15 PHP_FILE=/etc/php/5.6/apache2/php.ini
Editar o arquivo de configuração do PHP com os seguintes parâmetros:
ANEXO A. Tutorial Instalação do Zabbix 3.0.4 no Ubuntu 16.04 com MySQL 52
16 date.timezone = ”America/SuaCidade”
max_execution_time = 300
max_input_time = 300
post_max_size - 16m
always_populate_raw_post_data = -1
Reiniciar o Apache para aplicar as configurações realizadas.
17 # service apache2 restart
A.3.1 Instalando o Zabbix
Crie no sistema operacional, o usuário a ser usado pelo Zabbix com o
seguinte comando:
18 # adduser zabbix
A versão utilizada no momento da elaboração deste anexo é a 3.0.4, use
os comandos abaixo para obter o pacote de instalação do Zabbix, salvar no diretório
/tmp e descompactar o pacote.
19 # cd /tmp
20 # wget http://downloads.sourceforge.net/projects/zabbix
/files/ZABBIX%20Latest%20Stable/3.0.4/zabbix-
3.0.4.tar.gz
21 # tar xzvf zabbix-3.0.4.tar.gz22 # chmod -R +x zabbix-3.0.4
A.4 Populando o banco de dados no MySQL
Execute os comandos abaixo para popular o banco no MySQL:
23 # cat zabbix-3.0.4/database/mysql/schema.sql | mysql -u
zabbix -p<password> zabbix
24 # cat zabbix-3.0.4/database/mysql/images.sql | mysql -u
zabbix -p<password> zabbix
25 # cat zabbix-3.0.4/database/mysql/data.sql | mysql -u
zabbix -p<password> zabbix
A senha deve estar junto à opção ”-p”, se houver um espaço em branco
entre eles, o comando não vai funcionar.
ANEXO A. Tutorial Instalação do Zabbix 3.0.4 no Ubuntu 16.04 com MySQL 53
A.5 Compilando o Zabbix
26 # cd zabbix-3.0.4
27 # ./configure –enable-server –enable-agent –enable-java
–with-mysql –with-net-snmp –with-jabber=/user – with-
libcurl=/usr/bin/curl-config –with-ssh2 –with-openipmi –
with-libxml2
28 # make install
28 # cd -
A.6 Configurando o Zabbix
Edite o arquivo
29 # /usr/local/etc/zabbix_agentd.conf
conforme o quadro a seguir:
30 PidFile=/tmp/zabbix_agentd.pid
LogFile=/tmp/zabbix_agentd.log
LogFileSize=2
DebugLevel=3
Server=127.0.0.1
ListenPort=10050
Hostname=informe o nome exato do host, do jeito que
aparece no terminal antes dos símbolos ”$”,”#”
Timeout=3
Edite o arquivo
31 # /usr/local/etc/zabbix_server.conf
conforme o quadro a seguir:
ANEXO A. Tutorial Instalação do Zabbix 3.0.4 no Ubuntu 16.04 com MySQL 54
32 ListenPort=10051
LogFile=/tmp/zabbix_server.log
LogFileSize=2
PidFile=/tmp/zabbix_server.pid
DBHost=localhost
DBName=zabbix
DBPassword=senha do zabbix para acessar o banco de da-
dos
StartIPMIPollers=1
StartDiscoverers=5
Timeout=3
FpingLocation=/usr/bin/fping
Copie os arquivos de front-end do Zabbix para o diretório /var/www/html/-
zabbix, executando os comandos a seguir:
33 # mkdir /var/www/html/zabbix
34 # cp -R /tmp/zabbix-3.0.4/frontends/php/* /var/www/html/zabbix/
35 # chown -R www-data /var/www/html/zabbix
Reinicie o Apache para carregar os novos arquivos do Zabbix
36 # service apache2 restart
A.6.1 Script de inicialização do Zabbix
Coloque o Zabbix para iniciar automaticamente, no boot do sistema
operacional, criando os scripts abaixo.
Crie o arquivo /etc/init.d/zabbix_server e adicione o conteúdo a
seguir:
ANEXO A. Tutorial Instalação do Zabbix 3.0.4 no Ubuntu 16.04 com MySQL 55
37 #!/bin/sh
#
# Zabbix daemon start/stop script.
#
# Written by Alexei Vladishv <ale-
xei.vladishev@zabbix.com>.
NAME=zabbix_server
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/home/zabbix/bin
DAEMON=/usr/local/sbin/$NAME
DESC=”Zabbix server daemon”
PID=/tmp/$NAME.pid
test -f $DAEMON || exit 0
set -e
case ”$1” in
start)
echo”Starting $DESC:$NAME”
start-stop-daemon –oknodo –start –pidfile $PID \
–exec $DAEMON
;;
stop)
echo ”Stopping $DESC: $NAME”
start-stop-daemon –oknodo –stop –pidfile $PID \
–exec $DAEMON
;;
restart|force-reload)
$0 stop
sleep 3
$0 start
;;
*)
N=/etc/init.d/$NAME
echo ”Usage: $N start|stop|restart|force-reload”>&2
exit 1
;;
esac
exit 0
ANEXO A. Tutorial Instalação do Zabbix 3.0.4 no Ubuntu 16.04 com MySQL 56
Crie o arquivo /etc/init.d/zabbix_agentd e adicione o conteúdo a
seguir:
38 #!/bin/sh
# Zabbix daemon start/stop script.
# Written by Alexei Vladishv <ale-
xei.vladishev@zabbix.com>.
NAME=zabbix_agentd
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/home/zabbix/bin
DAEMON=/usr/local/sbin/$NAME
DESC=”Zabbix agent daemon”
PID=/tmp/$NAME.pid
test -f $DAEMON || exit 0
set -e
case ”$1” in
start)
echo”Starting $DESC:$NAME”
start-stop-daemon –oknodo –start –pidfile $PID \
–exec $DAEMON
;;
stop)
echo ”Stopping $DESC: $NAME”
start-stop-daemon –oknodo –stop –pidfile $PID \
–exec $DAEMON
;;
restart|force-reload)
$0 stop
sleep 3
$0 start
;;
*)
N=/etc/init.d/$NAME
echo ”Usage: $N start|stop|restart|force-reload”>&2
exit 1
;;
esac
exit 0
ANEXO A. Tutorial Instalação do Zabbix 3.0.4 no Ubuntu 16.04 com MySQL 57
Torne os arquivos executáveis com o comando:
39 # chmod +x /etc/init.d/zabbix_server /etc/init.d/zabbix_agentd
Execute os scripts:
40 # /etc/init.d/zabbix_server start
41 # /etc/init.d/zabbix_agentd start
Habilite os scripts para serem executados quando o comuputador for
ligado
42 # update-rc.d -f zabbix_server defaults
43 # update-rc.d -f zabbix_agentd defaults
A.7 Acessando a interface web do Zabbix
Usando um navegador acesse o Zabbix no endereço <http://ip-do-servidor/
zabbix> e siga as recomendações nas legendas das figuras a seguir:
Figura 38 – Clique no botão Next step
Caso contrário, reveja os passos anteriores para encontrar o problema.
Instalação finalizada.
ANEXO A. Tutorial Instalação do Zabbix 3.0.4 no Ubuntu 16.04 com MySQL 58
Figura 39 – Cheque as dependências do Zabbix. Se estiver tudo certo, clique em
Next step
Figura 40 – Informe o tipo da base de dados, o usuário e a senha. Se estiver ok,
clique em Next step
ANEXO A. Tutorial Instalação do Zabbix 3.0.4 no Ubuntu 16.04 com MySQL 59
Figura 41 – Informe o IP do servidor Zabbix e a porta em que ele será executado
(padrão 10051). Em Name coloque um nome para o servidor Zabbix.
Depois clique em Next step
Figura 42 – Configurações Ok, clique em Next step
ANEXO A. Tutorial Instalação do Zabbix 3.0.4 no Ubuntu 16.04 com MySQL 60
Figura 43 – Pronto! Zabbix instalado.
Figura 44 – Tela de acesso web, logue com usuário Admin e senha zabbix
	Folha de aprovação
	Dedicatória
	Agradecimentos
	Resumo
	Sumário
	Lista de ilustrações
	Lista de tabelas
	Lista de abreviaturas e siglas
	Introdução
	Revisão da Literatura
	Redes de Computadores
	Modelo de referência ISO OSI
	Modelo de referência TCP/IP
	Protocolo UDP
	Gerenciamento de rede e o Protocolo SNMP
	Arquitetura do SNMP
	PDUs e Mensagem SNMP
	SMI e MIB
	Nomeando OIDs
	Definindo OIDs
	Versões do SNMP
	SNMPv2c
	Ferramentas
	Cacti
	Nagios
	PRTG
	Zabbix
	Materiais, Técnicas e Métodos
	Local do experimento
	Infraestrutura
	Servidor
	Levantamento de Requisitos
	Ferramentas utilizadas
	Configuração da máquina virtual
	Cenários de Testes
	Cenário 1 - Monitoramento de todos os ativos de rede
	Cenário 2 - Alerta de Desastre
	Cenário 3 - SLA Aceitável
	Resultados
	Cenário 1
	Cenário 2
	Cenário 3
	Conclusões
	Dificuldades encontradas
	Referências
	Tutorial Instalação do Zabbix 3.0.4 no Ubuntu 16.04 com MySQL
	Instalando e configurando as dependências
	Criando o banco de dados no MySQL
	Configurando o PHP
	Instalando o Zabbix
	Populando o banco de dados no MySQL
	Compilando o Zabbix
	Configurando o Zabbix
	Script de inicialização do Zabbix
	Acessando a interface web do Zabbix