Você está na página 1de 106

Universidade Federal de Santa Catarina Departamento de Informática e Estatística – INE Pós-graduação em Ciência da Computação – CPGCC

Administração e Gerência de Redes de Computadores

Mateus Casanova Pereira

Professor: Carlos Westphall

Florianópolis

2001

2

RESUMO

4

ABSTRACT

4

1 INTRODUÇÃO

5

1.1 Motivação

5

1.2 Gerência de Redes de computadores

5

1.2.1 Principais Arquiteturas para Gerenciamento de Redes

6

1.2.2 Protocolos de Gerenciamento

6

1.3 Áreas Funcionais de Gerenciamento de Redes

8

1.4 Axiomas de Gerenciamento de Redes

11

1.5 Conclusões do Capítulo

11

2 AMBIENTE DE GERENCIAMENTO ESCOLHIDO

12

2.1 Estrutura organizacional

12

2.2 Regimento ESIN/NAPI

13

2.3 Recursos Humanos

16

2.4 Especificação e Implementação de um Sistema de Gerenciamento

16

2.4.1 Sistema de Gerenciamento de Redes

16

2.4.2 Escolha do Servidor - Gerente

17

2.4.3 Sistemas Operacionais da Rede

17

2.4.4 Monitoramento e Controle

18

2.4.4.1 Monitoramento de Tráfego

18

2.4.4.2 Controle

18

2.4.5

Alarmes e Acrônicos

18

2.5 Análise de Hardware e Software

19

2.5.1 Gerente

 

24

2.5.2 Agente

24

2.5.3 Implementando o SNMP

24

2.5.3.1 Windows NT/2000/9x

24

2.5.3.2 Linux

 

26

2.5.3.3 Traps (Linux e Windows NT)

31

 

2.5.3.3.1 SNMPTRAP

31

2.5.3.3.2 SNMPTRAPD

32

2.5.3.4

Switchs e roteadores

33

 

2.5.3.4.1

Traps nos Switch e Roteadores

33

2.5.4

As Operações de Traps

34

2.6 Conclusões do Capítulo

3 SOFTWARES DE GERENCIAMENTO

34

36

3.1 Plataforma de Gerenciamento

36

3.2 Softwares de Gerenciamento

37

3.2.1

WhatsUP

39

3.2.1.1

Instalação de um servidor WEB

49

3.2.2 MIB Master

58

3.2.3 MRTG

62

3.3 Arquitetura Funcional do Ambiente de Gerenciamento

63

3.4 Conclusões do Capítulo

63

3

4.1 Gerenciamento de Nível de Serviço – SLM

64

4.2 Coexistência entre SLA e QoS

65

4.3 Abrangência de SLAs nas Empresas

65

4.4 Requisitos

66

No anexo 5 temos uma média das repostas dos usuários. A pesquisa foi realizada com base

na resposta de 30 usuários

69

4.5

Fundamentos para Análise e Medição

70

4.5.1 Cargas de Trabalho

70

4.5.2 Utilização do recurso

70

4.5.3 Parâmetros para Gerenciamento

71

4.5.3.1

Categorização dos Parâmetros

71

4.5.3.1.1 Parâmetros Independentes do Serviço e Tecnologia

71

4.5.3.1.2 Parâmetros Dependentes da Tecnologia

72

4.5.3.2

Parâmetros mais Comuns em Redes IP

72

4.5.3.2.1

Avaliação dos Parâmetros Disponibilidade e Performance

73

4.5.3.2.1.1 Disponibilidade

73

4.5.3.2.1.2 Disponibilidade via SNMP

74

4.5.3.2.1.3 Disponibilidade via Ping – Alcançabilidade

75

4.5.3.3 Largura de Banda Utilizada

75

4.5.3.4 Erros por Interface

75

4.5.3.5 Necessidades do Mercado

76

4.5.3.6 Periodicidade da Emissão dos Relatórios de SLA

77

4.5.3.7 Ações baseadas em limites atingidos – thresholds: o controle efetivo do SLA

78

4.5.3.8 Metodologia de Medição

78

4.5.3.8.1 Obtenção dos Dados

79

4.5.3.8.2 Automatização da Coleta de Dados

79

4.5.3.9

Variáveis monitoradas no SLA

79

4.5.3.9.1 Metas de Tempo de Resposta

87

4.5.3.9.2 Disponibilidade do Serviço/Servidores (Manutenção Programada)

94

4.6 Aplicação da Metodologia de Medição de Dados

94

4.6.1

Relatórios – Análise dos Dados Coletados

94

4.6.1.1

Métricas Não Atingidas no SLA

95

4.6.1.1.1 Ambiente Napi

95

4.6.1.1.2 Ambiente POP

97

4.7 Proposta do SLA

98

4.8 Conclusões do Capítulo

100

5 CONCLUSÕES E PERSPECTIVAS FUTURAS

5.1 Conclusões

101

102

6 BIBLIOGRAFIA

103

ANEXOS

106

4

RESUMO

Com a utilização de redes de computadores em diversas organizações e a extensão contínua dessas, o gerenciamento de redes tornou-se indispensável. O gerenciamento de redes envolve o monitoramento (supervisão) e o controle de recursos distribuídos em redes. Em essência o gerenciamento de redes visa garantir uma certa qualidade de serviços a usuários de redes. Sendo assim, este trabalho apresenta os principais conceitos e terminologias de gerenciamento de redes, bem como uma proposta de gerenciamento com a utilização dos acordos de nível de serviço, SLA – Service Level Agreement. O Ambiente de rede será constituído, de um ambiente LAN (Local Area Network) formado pela Universidade Católica de Pelotas – UCPel (POP UCPel e NAPI). Outro aspecto importante do presente trabalho, foi a tentativa de utilização de sistemas de domínio público. Isto vem ao encontro com uma tendência e esforço mundial pela utilização e validação deste tipo de software. Neste trabalho pode-se observar alguns dos principais softwares condizentes com esta diretriz.

ABSTRACT

With the use of nets of computers in several organizations and the continuous extension of those, the administration of nets became indispensable. The administration of nets involves the monitoramento (supervision) and the control of resources distributed in nets. In essence the administration of nets seeks to guarantee a certain quality of services to users of nets. Being like this, this work presents the main concepts and terminologies of administration of nets, as well as an administration proposal with the use of the Service Level Agreements, SLA. The net Atmosphere will be constituted, of an atmosphere LAN (Local Área Network) formed by the Catholic University of Pelotas- UCPel (POP UCPel and NAPI). Another important aspect of the present work, was the attempt of use of systems of public domain. This comes to the encounter with a tendency and world effort for the use and validation of this software type. In this work it can be observed some of the principal suitable softwares with this guideline.

1

INTRODUÇÃO

5

Neste capítulo, apresenta-se uma visão geral dos principais conceitos de gerenciamento de redes de computadores, bem como as duas principais arquiteturas de gerenciamento de redes. O âmbito deste trabalho deteve-se nas necessidades de Gerenciamento de Nível de Serviço, mais especificamente nos Acordos de Nível de Serviço (SLA). Dentre os esforços existentes para um correto funcionamento das redes, encontram-se os trabalhos desenvolvidos junto ao Internet Engineering Task Force – IETF pelo Application MIB Working Group, o qual é responsável pela definição de um conjunto de objetos gerenciáveis para o monitoramento e controle de aplicações distribuídas. Esses objetos gerenciáveis deverão fornecer, especialmente, informações sobre a configuração, falha, desempenho, contabilização e segurança dos elementos gerenciados. E são justamente as informações coletadas destes elementos gerenciáveis e que demonstram a qualidade (ou não) dos serviços de rede que passaram a ser cobrados pelos usuários destes serviços. Com a profissionalização da prestação de serviços de rede, um Acordo de Nível de Serviço (Service Level Agreement SLA) passou a ser definido entre o prestador dos serviços de rede e o usuário da rede. Este SLA deve garantir uma qualidade mínima constante levando-se em consideração vários parâmetros de qualidade.

1.1 Motivação

Em decorrência das vantagens que as redes de computadores oferecem, o número

e a extensão dessas estão em expansão contínua. À medida que as redes crescem em

escala e extensão, dois fatores vão ficando mais evidentes: as redes, juntamente com seus recursos e aplicações, tornam-se cada vez mais indispensáveis para as organizações que as utilizam, e uma maior possibilidade de ocorrerem problemas, o que pode levar as redes a um estado de inoperância ou a níveis inaceitáveis de desempenho. A fim de garantir uma certa qualidade dos serviços a seus usuários, é que as redes de computadores devem ser gerenciadas. Este gerenciamento envolve o monitoramento

e o controle de recursos distribuídos em redes. Em essência, o gerenciamento de redes

busca assegurar que sistemas de informação, disponíveis em redes, estejam operacionais

e eficazes a todo instante. No entanto, o gerenciamento de redes de computadores é por si só complexo. Na proporção que as redes tornam-se maiores (extensão), complexas (tecnologia) e heterogêneas (plataformas de hardware e software distintas), tornam o gerenciamento em sí mais complexo ainda. Consequentemente o gerenciamento não pode ser realizado somente pelo esforço humano. A complexidade do gerenciamento de redes impõe o uso de soluções automatizadas de gerenciamento de redes.

1.2 Gerência de Redes de computadores

As facilidades providas pelas redes tendem a estimular o crescimento das mesmas, demandando necessidades de manutenção e planejamento futuro. Em um ambiente com poucas máquinas conectadas em rede, uma única pessoa é capaz de gerenciá-las. Mas, considerando um ambiente onde a rede esteja distribuída entre várias salas, ou até mesmo prédios distintos, a manutenção torna-se onerosa consumindo

6

tempo e recursos. Em redes de longa distância, a tarefa de gerenciamento é inerentemente mais complexa e indispensável, uma vez que cobre uma área geográfica extensa e envolve um grande número de equipamentos e usuários dependentes de seus serviços. Além disso tudo, com a grande utilização e a heterogenidade das redes de computadores, tem havido a necessidade de um esquema que ofereça soluções de gerenciamento de redes coerentes e estruturadas, permitindo o monitoramento e o controle de equipamentos compatíveis ou não. Devido esta busca, dois tipos de gerenciamento já existentes se destacam como padrões, são eles OSI e TCP/IP [2].

1.2.1 Principais Arquiteturas para Gerenciamento de Redes

A exemplo do que ocorre com os demais temas da área de redes, as diferentes possibilidades para o gerenciamento, organizadas na forma de arquiteturas de gerenciamento, são especificadas e propostas por organismos de padronização. Representado pelo CCITT (atual ITU-T), o mundo das telecomunicações iniciou em 1985 a definição de um sistema básico de gerenciamento para a indústria do setor [14]. Juntamente com a definição de um conjunto de informações de gerenciamento, a expressão Telecommunications Management Network - TMN, foi estabelecida para designar a arquitetura de gerenciamento para a indústria de telecomunicações. Durante a década de 80 os principais fornecedores de equipamentos e serviços de rede, dentre eles: IBM, DEC e AT&T, tentaram impor seus padrões para o gerenciamento. Embora eficientes, dentro do escopo de produtos de cada fabricante, uma solução universal e padronizada tornava-se cada vez mais necessária. A ISO, em 1989 adicionou ao modelo de referência OSI de sete camadas, um esquema básico da arquitetura de gerenciamento de rede. Uma série de documentos, denominados como série X.700, resultantes do trabalho cooperativo entre a ISO e o CCITT, destina-se a criar condições para o desenvolvimento de produtos de gerenciamento de redes de computadores e sistemas de comunicações heterogêneos. Com a especificação do Simple Network Management Protocol - SNMP, efetuada na sua primeira versão (SNMPv1) em 1988 pela IETF, iniciou-se o processo de padronização do principal modelo utilizado no gerenciamento de redes, mais especificamente, redes que adotam a pilha de protocolos TCP/IP. Funcionalidades de gerenciamento vem sendo cada vez mais incorporadas em diferentes dispositivos de rede, assumindo total conformidade com a versão 1 e 2 do SNMP. No final de 1997 foi iniciado o processo de aprovação do SNMPv3 junto a IETF. A nova versão, dentre outros aspectos, visa ampliar as funções de gerenciamento existentes no modelo, tratando questões de segurança [14].

1.2.2 Protocolos de Gerenciamento

Os agentes se comunicam com os gerentes através de um protocolo de gerenciamento de redes a nível de aplicações, que utiliza a arquitetura de comunicação da rede. Protocolos de gerenciamento de redes descrevem um formato para o envio de informações de gerenciamento. Para que seja possível a comunicação entre um gerente e um agente, é necessário que ambos compartilhem o mesmo esquema conceitual de informações. O gerente deve ter, então uma visão conceitual dos elementos gerenciados que o agente interage [21]. Informações úteis para o monitoramento de redes são coletadas e armazenadas

7

por agentes e disponibilizadas para um ou mais gerentes. São utilizadas duas técnicas para disponibilizar tais informações: polling e event report (relato de eventos ou notificações). Polling: é uma interação do tipo pergunta– reposta entre gerente e agente. É utilizada para se obter periodicamente informações armazenadas nas MIBs associadas aos agentes pelos gerentes. Relato de Eventos: é uma interação em que agentes enviam informações a gerentes. O gerente aguarda até que tais informações cheguem. Atualmente quando se fala em gerenciamento de redes, dois protocolos se destacam:

SNMP: Simple Network Management Protocol.

CMIP: Common Management Information Service Over TCP. Uma das diferenças fundamentais entre os dois protocolos é o fato do primeiro ser baseado no modelo de gerenciamento Internet. Já o segundo é baseado no modelo de gerenciamento OSI.

Além destas diferenças algumas outras são [3]:

O CMIP possui uma quantidade bem menor de produtos que o implementam;

O CMIP possui uma quantidade maior de operações, permitindo uma maior versatilidade no controle exercido sobre os elementos da rede (por exemplo, as operações CREATE e DELETE permitem que objetos sejam criados e eliminados dinamicamente); O CMIP é mais rico, apresentando uma melhor qualidade de informação; Uma implementação CMIP tende a ser mais lenta e maior, uma vez que requer maior capacidade de processamento e memória. Sabendo-se agora as diferenças básicas entre estes dois protocolos, sabe-se que atualmente vários produtos têm surgido com a finalidade de gerenciar a rede, quase que em sua totalidade baseados no padrão SNMP e CMIP. O sucesso do SNMP baseia-se no fato de ter sido ele o primeiro protocolo de gerenciamento não proprietário, público, fácil de ser implementado e que possibilita o gerenciamento efetivo de ambientes heterogêneos. Geralmente, estes produtos de gerenciamento de redes incorporam funções gráficas para o operador de centro de controle. No gerenciamento SNMP, é adicionado um componente ao hardware (ou software) que estará sendo controlado que recebe o nome de agente. Este agente é encarregado de coletar os dados dos dispositivos e armazená-los em uma estrutura padrão. Além desta base de dados, normalmente é desenvolvido um software aplicativo com a habilidade de sumarizar estas informações e exibi-las nas estações encarregadas das tarefas de monitorar a rede. Basicamente, são definidas quatro tipos de MIBs: MIB I, MIB II, MIB experimental e MIB privada. Os pioneiros na implantação dos protocolos SNMP foram os fornecedores de gateways, bridges e roteadores. Normalmente, o fornecedor desenvolve o agente SNMP e posteriormente desenvolve uma interface para a estação gerente da rede. As implementações básicas do SNMP permitem monitorar e isolar falhas, já as aplicações mais sofisticadas permitem gerenciar o desempenho e a configuração da rede. Estas aplicações, em geral, incorporam menus e alarmes para facilitar a interação com o profisional que está gerenciando a rede. O esquema dos produtos desenvolvidos com o protocolo SNMP são um pouco diferentes dos produtos que utilizam o protocolo CMIP. Os fornecedores de produtos que utilizam o protocolo CMIP pressupõem que os fabricantes possuam algum tipo de

8

gerenciamento em seus equipamentos, portanto estas informações podem ser disponibilizadas para um integrador via protocolo CMIP. O conceito de integrador foi definido em três níveis: o mais baixo, que contém os agentes e os elementos

gerenciadores, o intermediário, que consiste em elementos do sistema de gerenciamento, e finalmente o nível mais alto, que consiste no integrador dos sistemas de gerenciamento. Produtos como o NetView da IBM, Accumaster da AT& T, Allink da Nynex e o SunNet Manager da Sun Microsiytems, dentre outros, são exemplos deste tipo de implementação.

A dificuldade maior para uma aplicação integradora é que os fornecedores não

tem as mesmas variáveis de gerenciamento e tão pouco as mesmas operações em seus servidores de objetos.

A escolha entre um ou outro protocolo de gerenciamento deve recair sobre o tipo

de rede e dos produtos a ela agregados, sendo que podem ser mesclados os dois protocolos.

O SNMP e seu Internet Standard Network Management Framework são

adequados a agentes simples e fáceis de implementar, enquanto o CMIP e o seu framework Network Management Forum Release 1.0 são adequados para agentes com um ou mais servidores de objetos dentro da modalidade cliente-servidor orientado para objeto, dentre os quais incluem-se o RPC. Resumindo-se poderia-se dizer que:

SNMP - Gerenciamento na família de protocolos TCP/IP

O protocolo SNMP é apresentado como a primeira solução para gerenciamento

de redes baseadas, inicialmente, em TCP/IP. Será evidenciada a sua simplicidade e seus conceitos.

CMIP - Gerenciamento no Protocolo OSI

O padrão de gerenciamento proposto para o modelo OSI possui características

bastante mais robustas em relação ao SNMP. Por conta deste fato o protocolo de gerenciamento (CMIP) e os serviços oferecidos (CMIS) também apresentam maior complexidade. Ilustrando esta colocação, a arquitetura de gerência do modelo OSI é dividida em áreas funcionais bem caracterizadas.

1.3 Áreas Funcionais de Gerenciamento de Redes

A arquitetura de gerenciamento OSI define cinco áreas funcionais para prover

as necessidades do usuário no gerenciamento de suas redes:

Gerenciamento de Configuração;

Gerenciamento de Desempenho;

Gerenciamento de Falhas;

Gerenciamento de Segurança;

Gerenciamento de Contabilização.

Muitas vezes as áreas funcionais possuem funções de gerenciamento que se sobrepõem, isto é, são utilizadas não somente em uma, mas até mesmo em várias áreas de gerenciamento, apesar de terem finalidades diferentes em cada uma. Por outro lado, algumas funções servem de suporte para as funções das outras áreas.

Gerenciamento de Falhas

A gerência de falhas tem a responsabilidade de monitorar os estados dos

recursos, dar manutenção a cada um dos objetos gerenciados, e tomar decisões para

9

restabelecer as unidades do sistema que venham a dar problemas.

As informações que são coletadas sobre os vários recursos da rede podem ser

usadas em conjunto com um mapa desta rede, para indicar quais elementos estão funcionando, quais estão em mau funcionamento, e quais não estão funcionando. Opcionalmente, pode-se gerar um registro das ocorrências na rede, um

diagnóstico das falhas ocorridas e uma relação dos resultados deste diagnóstico com as ações posteriores a serem tomadas para o reparo dos objetos que geraram as falhas.

O ideal é que as falhas que possam vir a ocorrer em um sistema sejam detectadas

antes que os efeitos significativos decorrentes desta falha sejam percebidos. Pode-se conseguir este ideal através do monitoramento das taxas de erros do sistema, e da evolução do nível de severidade gerado pelos alarmes (função de relatório de alarme), que permitem a emissão das notificações de alarme ao gerente, que pode definir as ações necessárias para corrigir o problema e evitar as situações mais críticas.

Gerenciamento de Contabilidade

O gerenciamento de contabilidade possibilita estabelecer-se taxas a serem

utilizadas pelos recursos no ambiente OSI e os custos a serem identificados na utilização daqueles recursos. Outras considerações incluem informações dos custos dos usuários e recursos gastos, estipulando limites e incorporando informações de tarifas em todo o processo de contabilidade. No mundo de hoje, contabilidade significa tratar com pessoas usando os reais recursos de rede com despesas de operação real. Exemplos desses custos incluem uso do espaço em disco e dados armazenados, despesas de telecomunicação para acesso a dados remotos e taxas de envio de e-mail. Pode-se também usar o gerenciamento de contabilidade para determinar se a utilização dos recursos da rede estam aumentando com o crescimento, o que deve indicar a necessidade de adições e reajustamentos num futuro próximo

Gerenciamento de Configuração

O objetivo da gerência de configuração é o de permitir a preparação, a iniciação,

a partida, a operação contínua e a posterior suspensão dos serviços de interconexão entre os sistemas abertos, tendo então, a função de manutenção e monitoramento da

estrutura física e lógica de uma rede, incluindo a verificação da existência dos componentes e a verificação da interconectividade entre estes componentes.

A gerência de configuração é portanto correspondente a um conjunto de

facilidades que permitem controlar os objetos gerenciados, indentificá-los, coletar e

disponibilizar dados sobre estes objetos para as seguintes funções [4]:

Atribuição de valores iniciais aos parâmetros de um sistema aberto;

Início e encerramento das operações sobre os objetos gerenciados;

Alteração da configuração do sistema aberto;

Associação de nomes a conjuntos de objetos gerenciados.

Gerenciamento de Desempenho

Na gerência de desempenho tem-se a possibilidade de avaliar-se o comportamento dos recursos num ambiente de gerenciamento OSI para verificar se este comportamento é eficiente, ou seja, preocupa-se com o desempenho corrente da rede,

10

através de parâmetros estatísticos como atrasos, vazão, disponibilidade e o número de retransmissões realizadas.

O gerenciamento de desempenho é um conjunto de funções responsáveis por

garantirem que não ocorram insuficiências de recursos quando sua utilização se aproximar da capacidade total do sistema. Para atingir estes objetivos, deve-se monitorar as taxas de utilização dos recursos, as taxas em que estes recursos são pedidos e as taxas em que os pedidos a um recurso são rejeitados. Para cada tipo de monitoramento, define-se um valor máximo aceitável (threshold), um valor de alerta, e um valor em que se remove a situação de alerta.

Definem-se três modelos para atender aos requisitos de monitoramento de uso dos recursos do sistema:

Modelo de Utilização: Provê o monitoramento do uso instantâneo de um recurso. Modelo de Taxa de Rejeição: Provê a monitoramento da rejeição de um pedido

de um serviço.

Modelo de Taxa de Pedido de Recursos: Provê a monitoramento dos pedidos do uso de recursos.

Gerenciamento de Segurança

O objetivo do gerenciamento de segurança é o de dar subsídios à aplicações de

políticas de segurança, que são os aspectos essências para que uma rede baseada no modelo OSI seja operada corretamente, protegendo os objetos gerenciados e o sistema de acessos indevidos. Deve-se providenciar um alarme ao gerente da rede sempre que se detectarem eventos relativos a segurança do sistema. As informações de gerenciamento de segurança são armazenadas numa MIB especial a qual deve dar apoio as três categorias de atividades de gerenciamento de segurança existentes. Esta MIB é chamada de SMIB (Security Management Information Base).

Com base nestas cinco áreas descritas acima pode-se chegar ao seguinte diagrama:

eas descritas acima pode-se chegar ao seguinte diagrama: Figura 1. Mensagens num Protocolo de Gerenciamento –

Figura 1. Mensagens num Protocolo de Gerenciamento – Fonte: [4].

Onde:

O gerente pode efetuar a solicitação de um dado ao agente e a resposta a este

pedido pode ser enviada pelo agente. Há também a possibilidade de notificação do gerente pelo agente em caso de alguma anomalia na rede. As linhas tracejadas representam operações opcionais (que eventualmente podem nem ser utilizadas), que são a escrita de atributos e a leitura destes pelo gerente.

11

Embora esta classificação tenha sido desenvolvida para ambientes de rede OSI (modelo de sete camadas), esta forma de organizar o gerenciamento da rede tem sido amplamente aceita por fabricantes de sistemas de gerenciamento, podendo e devendo ser adotada no escopo do gerenciamento do modelo Internet, foco principal deste trabalho.

1.4 Axiomas de Gerenciamento de Redes

Existem dois axiomas que devem ser levados em conta quando se está projetando e estabelecendo um ambiente de gerenciamento de redes [19]:

O tráfego, devido às informações de gerenciamento, não deve aumentar significativamente o tráfego da rede; 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.

1.5 Conclusões do Capítulo

Neste capítulo foram descritos os principais conceitos relacionados ao gerenciamento de redes de computadores, bem como as principais arquiteturas de gerenciamento de redes. Estes itens são de vital importância para o entendimento de outros assuntos que serão descritos ao longo do trabalho. Apesar de apresentarem objetos distintos, as áreas funcionais propostas pela ISO, relacionam-se no sentido de que informações geradas em uma determinada área podem ser utilizadas como suporte para decisões em outras áreas [21]. Uma detecção de falha em um dos componentes da rede, pode por exemplo, ocasionar uma reconfiguração da rede.

12

2 AMBIENTE DE GERENCIAMENTO ESCOLHIDO

O local/ambiente de gerenciamento escolhido situa-se na Universidade Católica

de Pelotas – UCPel. A UCPel está sediada em Pelotas, importante eixo rodoviário de

ligação com os países da Bacia do Prata e centro de convergência da malha rodoviária do Cone Sul. A cidade localiza-se a cerca de 250 km ao sul de Porto Alegre, às margens da Lagoa dos Patos e próxima ao porto marítimo de Rio Grande, ponto de escoamento da produção agrícola e industrial da Região. Dentro da UCPel, escolheu-se dois ambientes de gerenciamento, sendo eles:

POP UCPel e o NAPI – Núcleo de Apoio a Projetos de Informática.

O POP UCPel é o nó da Rede Tchê instalado na UCPel, responsável pelo

provimento de serviços Internet.

O Núcleo de Apoio a Projetos de Informática – NAPI, tem como objetivo apoiar

projetos da Escola de Informática, bem como seus executores, dando-lhes suporte técnico e administrativo, através de infra-estrutura e pessoal de apoio adequado.

A infra-estrututa laboratorial da Escola de Informática-ESIN compreende um

conjunto de nove salas, utilizadas para atividades de ensino, de pesquisa e de extensão.

Dessas, sete destinam-se prioritariamente ao ensino e a extensão, abrigando em média 15 computadores. Duas salas são dedicadas exclusivamente para projetos de pesquisa e de graduação. Dentre os equipamentos pertencentes à infra-estrutura laboratorial da ESIN, encontram-se 20 sevidores (PC's, Power PC, RS-6000 e SPARC) com Sistemas Operacionais disponibilizados 250 PCs com processadores de DX4 100 MHz até Pentium III 800 MHz.

O ambiente de rede local é interligado a Internet via backbone da RNP (Rede

Nacional de Pesquisa) com conectividade de 1 Mbps. Sob a responsabilidade da Escola de Informática funciona o Ponto de Presença da Rede TCHÊ, provendo serviços de acesso discado e dedicado para outras Instituições de Ensino e de Pesquisa. Usuários da UCPel (alunos, funcionários e professores) dispõem de 36 linhas para acesso remoto (conexão dial-up via circuitos analógicos e digitais).

Mais informações a respeito da entidade gerenciada, bem como dos ambientes, podem ser obtidas nas URLs:

http://www.ucpel.tche.br

http://esin.ucpel.tche.br Sendo assim neste capítulo serão apresentadas as características dos ambientes de gerenciamento escolhidos para realização do trabalho, suas finalidades, configurações de hardware e software, a topologia da rede, bem como os recursos humanos para suporte a área de Tecnologia de Informações da rede UCPel.

2.1 Estrutura organizacional

13

13 Figura 2. Estrutura Organizacional. 2.2 Regimento ESIN/NAPI Do Objetivo Capítulo I Artigo 10 - O

Figura 2. Estrutura Organizacional.

2.2 Regimento ESIN/NAPI

Do Objetivo

Capítulo I

Artigo 10 - O Núcleo de Apoio a Projetos de Informática (NAPI) é um órgão vinculado à Escola de Informática (ESIN) da Universidade Católica de Pelotas.

Artigo 20 - O objetivo do NAPI é apoiar projetos da ESIN, bem como seus executores, dando-lhes suporte técnico e administrativo, mediante infra-estrutura e pessoal de apoio adequado.

Capítulo II

Da Composição

Artigo 30 - O NAPI é formado por seus membros, um Conselho Coordenador e um Coordenador.

Artigo 40 - São membros do NAPI:

i) alunos de cursos de pós-graduação da ESIN;

ii) professores de cursos de pós-graduação da ESIN;

iii) alunos vinculados aos Projetos de Graduação dos cursos da ESIN;

iv) alunos vinculados a Projetos de Pesquisa e Extensão da ESIN;

v) professores com projetos aprovados no NAPI, durante o período de execução do

projeto;

14

Artigo 50 - O Conselho Coordenador do NAPI é constituído pelos seguintes membros:

i) Coordenador do Projeto de Graduação em Análise de Sistemas (PGAS),

representando os professores orientadores do PGAS;

ii) Coordenador do Projeto de Graduação em Ciência da Computação (PGCC),

representando os professores orientadores do PGCC;

iii) Coordenador dos Cursos de Pós-Graduação da ESIN, representando os professores

dos cursos de pós-graduação da ESIN;

iv) 3 representantes dos professores vinculados a projetos de pesquisa e extensão do

NAPI;

v) 1 representante dos alunos dos cursos de pós-graduação da ESIN;

vi) 1 representante dos alunos vinculados a projetos de pesquisa e extensão da ESIN;

vii) 1 representante dos alunos vinculados a projetos de graduação da ESIN.

§ 10 - Os membros do Conselho serão escolhidos pelos respectivos grupos que representam, por um período de 2 anos.

§ 20 - No caso de não haver cursos de pós-graduação, ficarão vagas as cadeiras no Conselho dos respectivos representantes de alunos e professores desses cursos.

§ 30 - No caso de falta ou vacância de algum membro do Conselho, este poderá ser substituído por outro, escolhido pelo respectivo grupo a quem representa.

Artigo 60 - A administração do NAPI é feita pelo Coordenador que é escolhido pelo Conselho Coordenador, pelo período de 2 anos, podendo ser reconduzido por mais um período de igual duração.

Parágrafo único - Em caso de vacância será indicado, pelo Conselho Coordenador do NAPI, outro Coordenador para completar o período

Das Atribuições

Capítulo III

Artigo 70 - Compete ao Conselho Coordenador:

i) escolher, destituir e assessorar o Coordenador do NAPI;

ii) avaliar o andamento dos Projetos do NAPI;

iii) decidir pela aprovação ou não dos projetos de ensino, pesquisa e extensão da ESIN;

iv) avaliar e decidir pela aprovação ou não dos participantes dos projetos do NAPI;

v) avaliar e regular a conduta dos membros e dos Projetos do NAPI;

vi) definir e coordenar a política de projetos de ensino, pesquisa e extensão da ESIN.

Artigo 80 - São atribuições do Coordenador:

i) representar o NAPI, seus projetos e seus interesses perante a comunidade beneficiária;

ii) zelar pelo bom andamento dos projetos do NAPI e atividades de seus membros;

iii) tratar dos convênios (planejamento, definição, estabelecimento, controle e avaliação)

de projetos do NAPI com a comunidade beneficiária;

iv) seguir as recomendações e diretrizes estabelecidas pelo Conselho do NAPI;

v) zelar pelas políticas do NAPI;

15

vii) divulgar as ações e contribuições do NAPI; viii) relatar ao Conselho do NAPI o cumprimento dos objetivos, o andamento dos projetos, bem como obstáculos e necessidades para o bom andamento dos projetos; ix) administrar os recursos materiais e humanos do NAPI.

Capítulo IV

Da Comunidade Beneficiária do NAPI

Artigo 90 - A comunidade beneficiária é formada por pessoas físicas ou jurídicas que são ou possam vir a ser beneficiadas pelos projetos do NAPI.

Paragráfo único - Incluem-se na comunidade beneficiária, pessoas internas ou externas à UCPel.

Capítulo V

Do Uso dos Recursos do NAPI

Artigo 10 - É de exclusiva utilização pelos membros do NAPI, dos recursos materiais e humanos de que o núcleo dispõe, seguindo políticas estabelecidas.

§ 1º - Podem ser admitidas exceções desde que devidamente aprovadas pelo Conselho do NAPI

§ 2º - Cabe ao Conselho Coordenador do NAPI decir a política de uso dos recursos

materiais do NAPI e as diretrizes de ação dos recursos humanos alocados ao Núcleo.

Artigo 11 - Independentemente da origem, todos os recursos recebidos pelo NAPI são por ele administrados.

Dos Projetos do NAPI

Capítulo VI

Artigo 12 - Os projetos de ensino, pesquisa e extensão da ESIN devem ser avaliados e, se aprovados incorporados e supervisionados pelo Conselho Coordenador do NAPI.

Artigo 13 - Os convênios relativos aos projetos do NAPI com a comunidade beneficiária devem ser avaliados pelo Conselho Coordenador do NAPI

Capítulo VII

Das Disposições Gerais e Transitórias

Artigo 14 - Os casos omissos serão resolvidos pelo Conselho Coordenador.

Artigo 15 - O presente Regimento entra em vigor na data de sua aprovação pelo Conselho Universitário.

16

2.3 Recursos Humanos

Atualmente a UCPel possui um total de 20 servidores ativos em seu quadro. A Gerência de Tecnologia de Informação (GTI), possui duas coordenadorias em sua estrutura de suporte às atividades de informática (POP-UCPel e CI – Centro de Informática), contando com um total de 14 pessoas.

Função

Número de Funcionários

Coord. Sistemas

01

Coord. Redes

02

Coord. Suporte

03

Analista de Sistemas

02

Bolsista

06

Tabela 1. Recursos Humanos UCPel.

2.4

Especificação e Implementação de um Sistema de Gerenciamento

2.4.1

Sistema de Gerenciamento de Redes

Um Sistema de Gerenciamento de Redes (SGR), pode ser visto como um “centro

de gerenciamento”. Este centro nada mais é do que uma coleção de ferramentas que possibilitam monitorar e controlar redes. Em arquiteturas de SGRs, pelo menos um dos computadores na rede é designado como estação de gerenciamento (no escopo deste trabalho a máquina destinada a esta tarefa foi a Mercúrio (IP: 200.132.45.44), que será descrita mais adiante). Estas estações caracterizam-se por executar uma interface homem – máquina e por executarem parte das aplicações de gerenciamento que desempenham o papel de gerente. A interface homem – máquina permite que usuários autorizados do SGR (administradores), através de aplicações de gerenciamento, obtenham informações da rede. Pode-se ter ainda dois esquemas de gerenciamento [3]:

Gerenciamento Centralizado;

Gerenciamento Distribuído.

No primeiro, os gerentes residem somente na estação de gerenciamento. Já no segundo, os gerentes residem em múltiplos componentes (nós) da rede. Os agentes podem residir tanto em computadores Workstations, Servidores, quanto em dispositivos mais “distintos”, como hubs, bridges, roteadores e switchs. Em uma associação de gerenciamento, o componente da rede que implementa o gerente é denominado sistema gerente e o componente que implementa o agente é denominado sistema gerenciado. A figura abaixo ilustra os conceitos de sistema gerente e sistema gerenciado. Caso o gerente e o agente de uma associação residam em um mesmo componente, este é ao mesmo tempo um sistema gerente e gerenciado.

Sistema Gerente

Gerente
Gerente

17

Sistema Gerenciado

Notificações

r e n t e Gerente 17 Sistema Gerenciado Notificações Agente MIB Operações de Gerenciamento Objetos
Agente MIB
Agente
MIB
e Gerente 17 Sistema Gerenciado Notificações Agente MIB Operações de Gerenciamento Objetos gerenciados Figura

Operações de

Gerenciamento

Objetos gerenciados

Figura 3.Sistema Gerente e Sistema Gerenciado - [16]-Utilização Parcial.

2.4.2 Escolha do Servidor - Gerente

Atualmente na hora da escolha de um servidor, pode-se optar por usar um processador CISC, como por exemplo um Pentium, ou por um processador RISC, como por exemplo o PowerPC/PowerMac. O servidor escolhido deve ser capaz de lidar com todas as solicitações que todas as estações de trabalho conectadas a ele o fizerem. Se existir algumas estações de trabalho fazendo solicitações ao servidor, mas o servidor não tiver “velocidade” suficiente para atender em tempo adequado, então seu servidor tornará lento seu ambiente de rede. No contexto do trabalho, foi escolhida para servidor/gerente a máquina Mercurio. As características desta, pode-se observar logo abaixo:

Mercurio

Processador

Pentium 350 MHz

Memória

64 Mb

HD

4 Gb

Sistema Operacional

Windows 2000 Server Inglês e Linux Conectiva 6.

IP

200.132.45.44

Serviços

FTP, HTTP, SNMP, SMTP, POP3, Telnet

Tabela 2. Servidor Gerente.

2.4.3 Sistemas Operacionais da Rede

Após a escolha do ambiente de rede, deve-se escolher o tipo de sistema operacional que melhor se ajuste as necessidades em questão. Será preciso um sistema operacional Cliente/Servidor, como Linux, Windows NT/2000, Novell, AIX, etc. Neste caso, como pode ser visto na tabela 2, tem-se dois Sistemas Operacionais:

Linux e Windows 2000. Optou-se por utilizar o Sistema Operacional Windows 2000 pela maior compatibilidade de softwares de gerenciamento encontrados, conforma será descrito no capítulo 3.

18

2.4.4 Monitoramento e Controle

O gerenciamento de redes envolve o monitoramento e controle dos recursos da

rede. Monitoramento: é a observação, análise do estado e comportamento dos recursos físicos ou lógicos da rede. As funções de monitoramento podem ser baseadas em read (processos de leitura). Controle: é a alteração dos componentes físicos ou lógicos da rede. As funções de controle podem ser baseadas em write (processos de escrita).

Informações de Monitoramento

(processos de escrita). Informações de Monitoramento Funções de Controle REDE Figura 4. Noção de

Funções de Controle

REDE
REDE

Figura 4. Noção de Monitoramento e Controle.

2.4.4.1 Monitoramento de Tráfego

O monitoramento é uma função de gerenciamento da rede destinada a

observação e análise do estado e comportamento dos dispositivos gerenciados. Um usuário, ao utilizar um software gerente para verificar o estado operacional (up ou

down) de uma ou mais interfaces de rede, está efetuando uma função de monitoramento.

Os responsáveis pela resolução de problemas na rede, podem utilizar dois tipos

de sistemas de monitoramento de tráfego. Os softwares para monitoração de meios físicos, os quais obtêm dados estatísticos a partir de um hub de fiação centralizado e

permitem o controle total das conexões estabelecidas pelos servidores e estações – clientes da rede. Os analisadores de protocolo de rede, que capturam os pacotes de dados transmitidos através da rede e os decodificam.

2.4.4.2 Controle

O controle é uma função de gerenciamento da rede destinada a alteração de parâmetros de gerenciamento que acarretam ações junto aos dispositivos gerenciados. Um usuário, ao utilizar um software gerente para desabilitar o funcionamento temporário de uma determinada interface de rede, está executando uma função de controle.

2.4.5 Alarmes e Acrônicos

Todo o setor de gerenciamento e controle de rede possui dois fatores em comum:

19

a adoção de alarmes e a utilização de inúmeros acrônimos.

O uso de alarmes significa que se instrui o software a chamar a atenção do

administrador quando há ocorrência de algum evento anormal. Os pacotes de gerenciamento e controle de rede oferecem respostas para as situações de alarme que variam de um registro silencioso do evento no histórico, bips internos, símbolos coloridos intermitentes na tela durante o envio de mensagens para impressora, Pager, e-mail e até mesmo o envio de traps

2.5 Análise de Hardware e Software

Como já citado anteriormente o ambiente de gerenciamneto será constituído pela UCPel, mais precisamente pelo POP UCPel e o NAPI desta instituição. Nestes ambientes de gerenciamento, foi escolhido um total de 16 equipamentos. Destes 7 localizados no NAP e 9 no POP- UCPel.

A seguir observa-se a descrição destes dispositivos:

Equipamentos do NAP I– UCPel

Onça:

MrBurns: **

Processador: 166 Mhz

Processador: 166 Mhz

Memória: 64 Mb

Memória: 32 Mb

Hd: 4Gb

Hd: 3Gb

Sistema Operacional: Windows 98 SE

Sistema Operacional: Windows 95

Fabricantes: Infomer

Fabricante: IBM

IP: 200.132.45.19

IP: 200.132.45.177

Dominio: Planeta

Dominio: Planeta

Grupo de Projeto: Rede Tchê

Grupo de Projeto: Rede Acadêmica

Servidor de Impressão

Vênus:

Pantera:

Processador: 166 Mhz

Processador: 300 Mhz - Celeron

Memória: 32 Mb

Memória: 32 Mb

Hd: 3Gb

Hd: 3Gb

Sistema Operacional: Windows 98 SE

Sistema Operacional: Windows 98 SE

WebCam: Intel

WebCam: Creative

Fabricante: IBM

Fabricante: IBM

IP: 200.132.45.39

IP: 200.132.45.64

Dominio: Planeta

Dominio: Planeta

Grupo de Projeto: Rede Acadêmica

Grupo de Projeto: Arca

Tigre:

Leão: **

Processador: 300 Mhz - Celeron

Processador: 300 Mhz - Celeron

Memória: 32 Mb

Memória: 32 Mb

Hd: 3Gb

Hd: 3Gb

Sistema Operacional: Windows 98 SE

Sistema Operacional: Linux Mandrak

Fabricante: IBM

8.0

IP: 200.132.45.52

Fabricante: IBM

Dominio: Planeta

IP: 200.132.45.51

Grupo de Projeto: Arca

Dominio: Planeta

Grupo de Projeto: Arca

20

 

Serviços Oferecidos: MySQl, PostGres, FTP, HTTP

EAD: **

 

Cobra:

Processador: K6 II 333 Mhz

Processador: 300 Mhz - Celeron

Memória: 64Mb

Memória: 32 Mb

Hd: 5.1

Hd: 3Gb

Sistema Operacional: Windows NT - Server 4 Inglês

Sistema Operacional: Windows 98 SE

Fabricantes: IBM

Fabricantes: Yoshi

IP: 200.132.45.53

IP: 200.132.45.36

Dominio: Planeta

Grupo de Projeto: Arca

Grupo de Projeto: Arca

Serviços Suportados: Servidor de Bot

Corvo:

Halley: **

Processador: 300 Mhz - Celeron

Processador: 300 Mhz - Celeron

Memória: 32 Mb

Memória: 32 Mb

Hd: 3Gb

Hd: 3Gb e 6Gb

Sistema Operacional: Windows 98 SE

Sistema Operacional: Windows NT - Server 4 Inglês

Fabricantes: IBM

IP: 200.132.45.49

Fabricantes: IBM

Dominio: Planeta

IP: 200.132.45.46

Grupo de Projeto: Arca

Dominio: Aulanet

Grupo de Projeto: CSAEA

Serviços Oferecidos: Aulanet

Serviços Suportados: Mail (SMTP e POP3), HTTP, IRC (Chat)

Netline:

Mercurio: **

Processador: 300 Mhz - Celeron

Processador: 350 Mhz

Memória: 32 Mb

Memória: 64 Mb

Hd: 2 e 3 Gb

Hd: 4 Gb

Sistema Operacional: Windows 98 SE

Sistema Operacional: Windows 2000 Server e Conectiva Linux 6.0

WebCam: Intel

Fabricantes: IBM

Fabricantes: SB Infornatica

Zip Drive Externo

Zip Drive Interno

IP: 200.132.45.34

Placa de Video com captura e saída para TV

Dominio: Planeta

Grupo de Projeto: Rede Tchê

IP: 200.132.45.44

Dominio: Aulanet

Grupo de Projeto: Rede Tchê

Terra:

Parks: **

Processador: 333 Mhz

Processador: 166Mhz

Memória: 256 Mb

Memória: 64Mb

Hd: 2 Scassi (2.1 Gb e 3.2 Gb)

Hd: 4.1 GB scassi

Sistema Operacional: Windows 98 SE

Sistema Operacional: Linux Mandrake

Fabricantes: SB Infornatica

 

7.1

Placa de Video com captura e saída para TV - ATI

Fabricantes: Byte On

Fita Dat

IP: 200.132.45.45

IP: 200.132.45.43

21

Dominio: Planeta

Grupo de Projeto: Rede Tchê

 

Grupo de Projeto: Rede Tchê

Serviços

Oferecidos:

Chat,

Ferramentas

de

Gerenciamento

de

Redes Serviços Suportados: FTP, HTTP, MySQL, SNMP, Mail (SMTP e POP3), Telnet

Hub 3COM Superstack II PS Hub 40: **

Impressora HP Lazer Jet 5M: **

 

24 Portas

IP: 200.132.45.55

IP: 200.132.45.50

 

Tabela 3. Equipamentos do NAP – UCPel.

** Dispositivos mais importantes do ambiente de gerenciamento NAPI. Os demais apenas serão incluídos no SLA como “simples dispositivos”, não existindo nenhuma métrica para estes, a não ser a disponibilidade operacional dos mesmos. O motivo da não inclusão destes dispositivos no contrato deve-se ao fato de estas serem apenas estações de trabalho dos usuários. O servidor Halley é onde está instalado o AulaNet, um software destinado a Educação a Distância, desenvolvido com base no CGI Lua. Atualmente utilizam o AulaNet 12 cursos, incluindo disciplinas da área de informática, administração e física. O número de usuários cadastrados no AulaNet está em torno de 410. No Anexo 1, pode-se observar o diagrama do NAPI.

Dispositivos do POP – UCPel

Atlas:

Processador: Pentium III– 800 MHz;

Memória: 256 Mb;

Hd: SCSI 20 Gb;

Sistema Operacional: Linux Mandrake 8.0;

IP: 200.17.82.34;

Servidor:

E-mail

dos

usuários;

usuários,

Autenticação:

roteamento

dos

laboratórios,

Samba: nos laboratórios;

TACACS da conexão remota;

Home dos usuários;

autenticação

dos

Serviços: FTP,HTTP, Mail (SMTP e POP3), IMAP4, Telnet.

Triton:

Processador: Pentium 166 MHz;

Memória: 64 Mb;

Sistema Operacional: Linux Mandrake 7.0;

IP: 200.132.45.56;

Servidor: Projeto de pesquisa.

Hercules:

Processador: Risc RS 6000;

Sistema Operacional: AIX 4.3.2;

22

IP:

200.132.45.54;

Serviço: Squid.

Noe:

Processador: Risc RS 6000;

Sistema Operacional: AIX 4.3.2;

IP:

200.132.45.31;

Servidor: Projeto de pesquisa;

Serviços: FTP, HTTP, Mail (SMTP e POP3), SNMP, Echo Server, Time Server;

Comunidade de leitura: public.

Amadeus:

Processador: Pentium 200 MHz Pro;

Memória: 128 Mb;

Hd: 8 Gb SCSI;

Sistema Operacional: Linux Mandrake 7.0;

IP:

200.132.45.55;

Serviço: Servidor WEB;

Tabela 4. Dispositivos do POP–UCPel.

No Anexo 2, pode-se observar o diagrama do POP-UCPel.

O POP-UCPel, representado no anexo 2, além destas 5 máquinas possui ainda 1 roteador, 2 Switchs e um bastidor com modens da PARKS.

O roteador, router02.ucpel.tche.br (200.17.82.62) – Cisco 2511- é o

equipamento mais externo e é responsável pela conexão da UCPel com a UFRGS. O

Link entre as duas instituições é de 2 Mb. Sua comunidade de leitura é a tango-samba.

Os Switchs presentes no POP – UCPel são onde estão ligados os servidores e

demais hosts da ESIN. No Switch 3Com 1100 - Super Stack II (200.132.45.254), estão ligados os laboratórios (1-5), a recepção do laboratório, a sala do POP-UCPel, o NAPI IV e os servidores Noe e Atlas. Sua comunidade de leitura é a public. Neste ainda rodam

serviços como Telnet, SNMP e HTTP. Na figura abaixo pode-se observar o que está sendo ligado a cada porta do

Switch.

P1: Laboratório 1

23

P3: Laboratório 3

P5: Laboratório 5

P2: Laboratório 2 P4: Laboratório 4 P6: Recepção do Laboratório P10: Sala do POP P13:
P2: Laboratório 2
P4: Laboratório 4
P6: Recepção do Laboratório
P10: Sala do POP
P13: Teste
P24: Atlas

P11: Napi IV

P23: Noe

Figura 5. Portas do Switch 3COM.

No Switch Cisco Catalyst 1900 – Backbone (200.17.82.60), estão ligados os servidores Triton, Hercules, Amadeus, Atlas e os routers 01,02,03,04. Sua comunidade é a public. Neste ainda rodam serviços como Telnet e SNMP. Na figura abaixo pode-se observar o que está sendo ligado a cada porta do

Switch.

P9: Triton

P13: Hercules
P13: Hercules

P21: Router01

. P 9 : T r i t o n P13: Hercules P21: Router01 P5 :

P5: Amadeus

P6: Atlas

P18: Router03

P27: Router04

P20: Router02

Figura 6. Portas do Switch CISCO.

Um detalhe importante com relação ao servidor Atlas, é que este realiza o papel de bridge entre os dois Switch (3COM e Cisco).

2.5.1 Gerente

24

O gerente compreende um tipo de software que permite a obtenção e o envio de

informações de gerenciamento junto aos mecanismos gerenciados, mediante comunicação com um ou mais agentes. As informações de gerenciamento podem ser

obtidas com o uso de requisições efetuadas pelo gerente ao agente, como também, mediante envio automático disparado pelo agente a um determinado gerente. Tipicamente um gerente está presente em uma estação de gerenciamento de rede

O gerente foi instalado na máquina Mercurio, já descrita na seção 2.4.2. Para

desempenhar esta função de gerente, foram escolhidos os softwares WhatsUp, MIB Master e MRTG (em conjunto com o pacote UCD-SNMP). Estes serão descritos no capítulo 3.

2.5.2 Agente

O agente compreende um tipo de software presente junto aos dispositivos gerenciados. A função principal de um agente compreende o atendimento das requisições enviadas por um software gerente e o envio automático de informações de gerenciamento ao gerente, indicando a ocorrência de um evento previamente programado. Também compete ao agente efetuar a interface entre os diferentes mecanismos usados na instrumentação das funcionalidades de gerenciamento inseridas em um determinado dispositivo gerenciado. Nos Roteadores, HUBS e Switchs (que possuem capacidade de serem gerenciados) o agente vem “pré-pronto” para ser utilizado. Basta habilitarmos e configurá-lo. Já em estações de trabalho/servidores, como Linux, Aix, Windows NT/9x/2000, devemos instalá-lo, configurá-lo e habilitá-lo.

2.5.3 Implementando o SNMP

Como implementar o protocolo SNMP é uma questão encontrada por muitos administradores de rede. Para a configuração completa do SNMP, além dos parâmetros de rede (IP do agente, máscara da rede) essenciais para o funcionamento do mesmo, pode-se também alterar os parâmetros referentes às permissões das operações (community de leitura e community de leitura/escrita). Estes parâmetros possuem como definição default as strings public” e “private“. O endereço IP do gerente que receberá os traps também é importante que seja configurado para que não haja perda de informações. Além disso, por questões de segurança, pode-se alteradar o status das operações SNMP SET. A configuração default deste parâmetro é habilitada.

A configuração do SNMP foi feita no servidor utilizado para o gerenciamento,

bem como nos dispositivos que serão gerenciados – servidores/estações de trabalho

Linux, Windows NT/2000/9x, roteadores, hubs e switchs. Abaixo estão os passos para instalação do SNMP no Windows NT/2000/9x, em seguida os passos para instalação no Linux.

2.5.3.1 Windows NT/2000/9x

Servidores e Workstation Windows NT implementam o protocolo SNMP por um agente que permite um gerenciamento remoto e centralizado de: Servidores NT, Workstations NT, Servidores NT baseados em WIN, Servidores NT baseados em DHCP

25

e Servidores NT baseados em IIS. Servidores e Workstations NT provêem o serviço SNMP como a estrutura necessária para o gerenciamento de redes, mas não provêm um programa gerente SNMP [31]. Existem muitas utilidades no gerente SNMP disponíveis com o servidor NT e no

kit de recursos para Workstations, além de outros programas de gerenciamento de redes de melhor acabamento que podem ser obtidos através Microsoft ou por terceiros.

O servidor SMS (Microsoft System Server) fornece suporte para o gerenciamento

SNMP. Outros programas de gerenciamento de redes, assim como Hewlett Packard

Open View, IBM LAN NetView e NMC para Windows NT , além de outos podem ser obtidos de terceiros.

A instalação do protocolo SNMP no Windows NT não apresenta muito mistério,

basta obedecer os seguintes passos: Primeiramente acessa-se o Painel de Controle, Rede. Na guia Serviços, adiciona-se o serviço SNMP. Algumas informações como contato, localização, comunidade leitura e escrita, entre outras serão requisitadas. Será então requerido o CD de instalação do Windows NT.

O segundo passo é acessar novamente ao Painel de Controle, Serviços. Localiza-se os serviços: SNMP e SNMP Trap Service. Configura-se estes serviços para serem inicializados automaticamente. Reinicializa-se o computador e o SNMP já estará habilitado. Após a instalação do SNMP, um grupo de arquivos é criado. Entre eles:

Dhcpmib.dll: MIB para DHCP. Este só é criado quando o servidor DHCP é instalado no computador que roda o servidor Windows NT.

Inetmib1.dll: dll para a MIB II.

Lmmib2.dll: dll para gerentes de redes LANs.

Mgmtapi.dll: Gerente SNMP para Windows NT , que lista para o gerente e manda e recebe requisições dos agentes.

Mib.bin: Instalado com o serviço SNMP e usado no gerenciamento de API.

Mgmtapi.dll: Relaciona os nomes dos objetos com suas OIDS.

Snmp.exe: Serviço do agente SNMP, o agente master, que aceita as requisições do gerente, repassa estas requisições para as dlls apropriadas para o processamento. Snmptrap.exe: Recebe pedidos SNMP dos agentes e repassa para a API gerente do SNMP no console de gerenciamento. Um processo em backgraund snmptrap.exe é iniciado somente após a API gerente receber a autorização. Winsmib.dll: dll para MIBs WINS, disponíveis somente quando o servidor WINS é instalado no computador que roda o Windows NT Server.

No Windows NT toda a configuração do agente ocorre de forma gráfica. Na

primeira guia, agente, configura-se o Contact e Location. Além disso pode-se assinalar as informações de serviço que deveriam refletir os serviços de rede providos por este computador, no qual esta sendo instalado o agente.

A próxima guia, traps, permite configurar o nome da comunidade e o IP da

máquina que receberá as traps. Na terceira e última guia, segurança, configura-se as comunidades do agente e pode-se estipular de quais dispositivos este receberá requisições.

26

26 Figura 7. SNMP Agente – Windows NT . Figura 8 . SNMP Traps– Windows NT.

Figura 7. SNMP Agente – Windows NT.

26 Figura 7. SNMP Agente – Windows NT . Figura 8 . SNMP Traps– Windows NT.

Figura 8. SNMP Traps– Windows NT.

– Windows NT . Figura 8 . SNMP Traps– Windows NT. Pode- se necessário. ter tantas
– Windows NT . Figura 8 . SNMP Traps– Windows NT. Pode- se necessário. ter tantas

Pode-se

necessário.

ter

tantas

Figura 9. SNMP Security – Windows NT.

2.5.3.2

Linux

comunidades

quanto

o

O Linux possui um pacote chamado UCD – SNMP, atualmente na versão 4.12, o qual é uma implementação do CMU – SNMP. Este pacote suporta SNMPv1, SNMPv2 e SNMPv3, e apresenta uma série de ferramentas de gerência utilizáveis através de linha de comando. Para instalar o UCD -SNMP, basta obedecer aos passos listados abaixo:

1) Utiliza-se o comando abaixo, caso seja um arquivo binário:

% tar –xvzf nome do arquivo Note que este comando irá extrair os arquivos binários, manuais e outros. 2) Após entra-se no diretório descompactado e executa-se o comando ./configure, onde

27

serão pedidas algumas informações relacionadas a utilização do mesmo, como local onde ficarão os logs, contato, localização, etc. A seguir executa-se o comando make (make all, make install, make configure), para compilá-lo. 3) Se ao invés de um arquivo binário, for um RPM, utiliza-se:

% rpm –i nome do arquivo Após a instalação (pelo primeiro ou pelo segundo modo) acrescenta-se uma entrada em /etc/rc.local para ativar o agente que rodará em background:

% /usr/sbin/snmpd -f ; echo 'snmpd' Um teste rápido pode ser feito, depois da ativação do agente, executando a chamada:

% snmpwalk localhost public system

Configurando o snmpd.conf:

Para interagir com SNMPv1, quase nada precisa ser configurado. No arquivo snmpd.conf é possível personalizar o nome da comunidade, a pessoa responsável pelo

dispositivo, sua localização e nome do sistema. Na primeira versão do SNMP, somente dois tipos de comunidades são possíveis; public e private, sendo que este último pode assumir qualquer nome personalizado pelo gerente da rede. A está comunidade pode ser atribuído direitos de leitura e/ou escrita. No diretório SNMPD, estão os arquivos de configuração importantes (para fazer uso da segunda versão do protocolo) como o acl.conf e o view.conf, além do próprio snmpd.conf. Para fazer alguma alteração válida no snmpd.conf esta só deverá ser feita no diretório /usr/share/snmp/snmpd.conf. Party.conf: Define-se endereços IPs, chaves de autenticações e privacidade dos grupos;

View.conf: Define as sub-árvores da MIB;

Context.conf: Define a visão da MIB ou proxy relationship para cada contexto;

Acl.conf: Associa dois grupos com um contexto e um conjunto de privilégios.

No arquivo snmpd.conf, localizado no ditetório /etc/snmp/snmpd.conf, relaliza- se quase todas as configurações para um completo funcionamento do SNMP. Quando o agente começar a rodar, vai ser no diretório acima que o agente ira procurar as configurações para o seu correto funcionamento. Um fator importante é com relação aos seguintes diretórios e seus respectivos arquivos:

/usr/share/snmp/snmp.conf Configuração comum para o agente e aplicação. Este normalmente é criado no diretório /etc/snmp/snmpd.conf, e deve ser movido ou copiado para este caminho (/usr/share/snmp/snmp.conf), pois é neste diretório que o agente snmpd procura as configurações no momento da inicialização. /usr/share/snmp/snmpd.local.conf Configura o agente. Este arquivo é opcional e só é usado para configurar as porções extensíveis do agente, os valores das comunidades. Por padrão a primeira comunidade (a comunidade public) possui acesso somente de leitura e a segunda comunidade (private por padrão) possui acesso restrito.

/usr/share/snmp/mibs Neste diretório é onde se encontram alguns arquivos texto para implementação de MIBs no agente. /var/ucd-snmp

28

Neste diretório, estão os arquivos relativos ao monitoramento do agente, como por exemplo logs. /etc/rc.d/ Neste diretório ficam os links para os aplicativos que devem ser inicializados na hora do boot do host. /etc/snmp Neste diretório dica o arquivo snmpd.conf, o qual é o arquivo de configuração do

SNMP.

/usr/doc/ucd-snmp-4.1.1

Neste diretório estão os arquivos de ajuda, a documentação propriamente dita do

SNMP.

snmpcheck, readme.snmpv3, entre outros. /usr/bin Neste diretório estam os arquivo executáveis, como por exemplo, snmpd e snmptrapd. usr/man

Aqui

encontram-se

os

arquivos

como:

agent.txt,

example.conf,

readme,

Neste diretório encontram-se os manuais em formato bz do SNMP.

A seguir é feito um relato de algumas configurações do arquivo snmpd.conf, onde as

linhas que começam com #, são apenas comentários.

######################################################################

# Access Control

######################################################################

Aqui definem-se as comunidades de leitura e escrita. Por default a comunidade de leitura é a public.

O snmpd.conf libera apenas o acesso as variáveis da categoria sistema (system), ou seja,

todas as outras categorias como ip, tcp, udp, estão bloqueadas. Para se liberar o acesso a

estas informações deve-se alterar o arquivo snmpd.conf como a seguir:

# context sec.model sec.level prefix read write not access mygroup "" any noauth 0 mib2 none none #access admin "" any noauth 0 mib2 system none access public "" any noauth 0 all none none access local "" any noauth 0 all all all

Acima pode-se observar na quarta linha a palavra all, access public "" any noauth 0 -- >>all<<- none none No arquivo original, neste campo estava a palavra system. Apenas as variáveis da categoria MIB Sistema estavam liberadas para acesso, então trocado para all liberou-se todas as categorias da MIB. Abaixo tem-se um exemplo dos passos para configurar esta etapa. Note que caso queira-

se utilizar este exemplo, deve-se apenas modificar a COMUNIDADE para uma nova. O

nome pode ser qualquer um, por exemplo, algo que reflita a rede local do endereço e espaço onde este se encontra. Por padrão o SNMP responde a comunidade public, para acesso apenas de leitura. Pode- se modificar este nome bem como o da comunidade de escrita por qualquer nome desejado.

 

29

#Modelo default VACM

 

com2sec

public

default

public

group

public

v1

public

group

public

v2c

public

group

public

usm

public

view

all

included

.1

access

public

""

any noauth

exact

all none none

#A comunidade public tem acesso apenas de leitura no snmpd

#Primeiro mapeia-se o nome da comunidade public para um nome seguro:

#

sec.name

source

community

com2sec

notConfigUser

default

public

com2sec

me

localhost

private

###

# Segundo, mapeia-se a segurança dos nomes para dentro dos nomes dos

#grupos:

#

groupName

securityModel

securityName

group

notConfigGroup

any

notConfigUser

group

mygroup

any

me

# Também adiciona-se um usuário “inicial”

#para todo agente snmpv3) para o grupo:

(um usuário snmpv3 configurado

#

groupName

securityModel

securityName

group

notConfigGroup

any

initial

###

# Terceiro, cria-se uma visão para deixar o grupo ter direitos de:

#name

incl/excl

subtree

mask(optional)

view

systemview

included

system

view

systemview

included

interfaces.ifTable.ifEntry.ifOutOctets

view

systemview

included

interfaces.ifTable.ifEntry.ifInOctets

view

all

included

.1

###

#

#systemview:

Finalmente,

concede-se

ao

grupo

acesso

de

somente

leitura

para

o

#

group

context

sec.model

sec.level

prefix read

write

notif

access

notConfigGroup

""

any

noauth

0

systemview none

none

access mygroup

""

any

noauth

0

all

all

none

#Este é um exemplo de configuração com base nos tópicos acima:

#Deve-se mudar o "símbolo da comunidade" abaixo para um outro nome. Uma #dica, é um nome conhecido em seu local de trabalho ou na sua rede.

##

sec.name

source

community

#

com2sec

local

localhost

COMMUNITY

30

#

com2sec

mynetwork

NETWORK/24

COMMUNITY

##

group.name

sec.model

sec.name

#

group

MyRWGroup

any

local

#

group

MyROGroup

any

mynetwork

#

#

group

MyRWGroup

any

otherv3user

##

incl/excl subtree

mask

#

view all

included .1

80

##

-or just the mib2 tree-

#

view mib2

included

.iso.org.dod.internet.mgmt.mib-2 fc

##

context

sec.model

sec.level

prefix

read

write notif

#access MyROGroup

""

any

noauth

0

all

none

none

#access MyRWGroup ""

any

noauth

0

all

all

all

###################################################################### # System contact information ###################################################################### Aqui define-se o sysContact e o sysLocation. syslocation NAPI II / UCPel (edit /etc/snmp/snmpd.conf) syscontact Mateus(mateus@saturno.ucpel.tche.br)

Após o comando - snmpwalk -v 1 localhost public system obteria-se os seguintes dados:

system.sysDescr.0 = 3Com SuperStack II PS Hub 40, SW Version 1.14 system.sysObjectID.0 = OID: enterprises.43.10.27.4.1 system.sysUpTime.0 = Timeticks: (77683032) 8 days, 23:47:10.32 system.sysContact.0 = Mateus(mateus@saturno.ucpel.tche.br) system.sysName.0 = HUB 3COM system.sysLocation.0 = NAPI II / UCPel system.sysServices.0 = 1

Depois de devidamente configurado, o daemon snmpd, este deve ser inicializado, e sempre que a máquina onde este foi instalado for inicializada, este daemon também deve ser reinicializá-do (/etc/rc/d/init.d/snmpd start). Mais informações sobre estes e outros parametros de configuração podem ser obtidas no arquivo snmpd.conf(5).bz localizado no diretório /usr/man/man5/. Nas seguintes e-mails, pode-se consultar uma série de dicas dos mais variados assuntos relacionados ao SNMP:

ucd-snmp-announce@ucd-snmp.ucdavis.edu Para anúncios - Subscreva ucd-snmp-anunciar-request@ucd-snmp.ucdavis.edu ucd-snmp@ucd-snmp.ucdavis.edu Para discussões de uso do protocolo- Subscreva a ucd-snmp-request@ucd- snmp.ucdavis.edu ucd-snmp-coders@ucd-snmp.ucdavis.edu

31

Para discussões de desenvolvimento - Subscreva a ucd-snmp-coders-request@ucd- snmp.ucdavis.edu

2.5.3.3 Traps (Linux e Windows NT)

Abaixo serão descritos o SNMPTRAP e SNMPTRAPD nos respectivos sistemas operacionais – Linux e Windows NT.

2.5.3.3.1

SNMPTRAP

É uma aplicação SNMP que forma e envia mensagens SNMP TRAPS a um host.

Sintaxe:

snmptrap host community trap-type specific-type device-description [-a agent-addr]

Onde:

host: representa a entidade a ser consultada. Pode ser informada tanto pelo nome ou endereço IP;

community: especifica o nome da comunidade para a transação no sistema remoto. Caso nenhuma comunidade seja passada, será utilizada como community default a public;

trap-type e specific-type: são inteiros que especificam o tipo de mensagens trap

a serem enviadas;

device-description: é uma descrição textual do dispositivo que está enviando a

trap, para ser usado como valor de uma variável system.sysDescr.0 enviada na lista de variáveis desta mensagem; -a agent-addr: pode ser usado para mudar o endereço para onde a trap reporta. De outro modo, o endereço da máquina de envio é utilizado.

Exemplo:

snmptrap -p 164 -v1 200.132.45.44 public 1.3.6.1.4.1.3.1.1 saturno 6 0''

Este comando enviará uma trap do tipo enterpriseSpecific. Pode-se observar isto pelo valor 6, que como poderá ser observado logo abaixo define este tipo de trap.

Os tipos de traps “padrão” definidas pelo SNMP são:

0 (coldStart): significa que a entidade de protocolo de envio se auto reinicializa

de modo que a configuração do agente ou a implementação da entidade do protocolo possa ser alterada; 1 (warmStart): significa que a entidade de protocolo de envio se auto reinicializa

de modo que nem a configuração do agente nem a implementação da entidade de protocolo é alterada; 2 (linkDown): significa que a entidade de protocolo de envio reconhece uma falha em um dos links de comunicação representados na configuração do agente; 3 (linkUp): significa que a entidade de protocolo de envio reconhece que um link de comunicação representado na configuração do agente voltou a estar ativo; 4 (authenticationFailure): significa que a entidade de protocolo é o endereço de uma mensagem de protocolo que não está apropriadamente autenticada. Enquanto as implementações do SNMP devem ser capazes de gerar esta trap, devem também ser capazes de suprimir a emissão dos mesmos via uma

32

mecanismos específico de implementação; 5 (egpNeighborLoss): significa que um vizinho EGP para o qual a entidade de protocolo de envio, era um parceiro EGP, foi marcada como "down" e o relacionamento de parceria não existe mais; 6 (enterpriseSpecific): significa que a entidade de protocolo de envio reconhece que algum evento enterprise-específico ocorreu.

Caso queira-se modificar a porta de envio da trap, basta modificá-la no comando do agente, snmptrap -p 164 -v1 200.132.45.44 public 1.3.6.1.4.1.3.1.1 saturno 6 0 ''.

Por default esta porta é a 162. No gerente, que irá receber estas traps, a porta também deve ser a mesma (snmptrapd – p 164).

O campo specific-trap identifica a trap particular que ocorreu. Adicionando-se "-

d" à lista de argumentos fará com que a aplicação faça um dump dos pacotes enviados e recebidos.

2.5.3.3.2

SNMPTRAPD

É uma aplicação SNMP que recebe e loga mensagens snmp traps enviadas à

porta SNMP-TRAP (162) na máquina local. Este deve estar sempre rodando no gerente, de forma a possibilitar o recebimento das traps .

Sintaxe:

snmptrapd [-p] Onde:

[-p] é a porta em que o daemon snmp ira rodar.

As mensagens têm o seguinte formato:

jul 8 22:39:52 suffern snmptrapd: 128.2.13.41:

Cold Start (0) Uptime:

8 days, 14:35:46

Deve ser executada como root de modo que a porta UDP 162 (caso seja esta) possa ser aberta. Um exemplo de trap recebida pelo gerente (de um agente com a seguinte sintaxe de trap : snmptrap –v1 200.132.45.44 public 1.3.6.1.4.1.3.1.1 parks 1 0 ‘’) seria:

jul 6 08:09:51 mercurio snmptrapd[952]: 200.132.45.43: Link Up Trap (0) Uptime:

0:36:57.27, interfaces.ifTable.ifEntry.ifIndex.1 = 1

Com o comando snmptrapd –c confFile, o arquivo de configuração snmptrapd.conf é gerado no diretório /usr/share/snmp/snmptrapd.conf, forçando o agente a ler o mesmo.

O Windows NT, não provê um programa gerente SNMP. Sendo assim, ele apenas

recebe os pedidos SNMP, e repassa para uma API gerente no console de gerenciamento. Para uma estação Windowsn NT, receber tais traps, este deve utilizar um software gerente, como por exemplo, MIB Master, capaz de receber as traps enviadas pelos agentes. Para uma estação Linux, receber as traps, ela pode utilizar um software gerente,

33

como por exemplo, MIB Master, capaz de receber as traps enviadas pelos agentes ou ainda pode-se observar as traps enviadas no arquivo syslog, localizado no diterório /var/log/syslog:

tail /var/log/syslog Pode-se direcionar as traps geradas pelos agentes para um outro arquivo que não seja o syslog. Para isto basta redirecionar as traps do syslog para outro arquivo qualquer, adicionando as seguintes linhas no arquivo /etc/syslog.conf:

local0.*

/var/log/nome-do-arquivo-desejado.xxx

Exemplos de traps enviadas pelos agentes:

A seguir pode-se observar uma série de exemplos de traps enviadas pelos agentes ao gerente.

Exempos:

snmptrap -p 164 -v1 200.132.45.44 public 1.3.6.1.4.1.3.1.1 parks 6 0 '' snmptrap -p 164 -v1 200.132.45.44 public 1.3.6.1.4.1.3.1.1 parks 6 1 ''

snmptrap -p 164 -v1 200.132.45.44 public 1.3.6.1.4.1.3.1.1 noe 6 0 '' snmptrap -p 164 -v1 200.132.45.44 public 1.3.6.1.4.1.3.1.1 noe 6 1 ''

snmptrap -p 164 -v1 200.132.45.44 public 1.3.6.1.4.1.3.1.1 jaguarao 6 0 '' snmptrap -p 164 -v1 200.132.45.44 public 1.3.6.1.4.1.3.1.1 jaguarao 6 1 ''

snmptrap -p 164 -v1 200.132.45.44 public 1.3.6.1.4.1.3.1.1 stvitoria6 0 '' snmptrap -p 164 -v1 200.132.45.44 public 1.3.6.1.4.1.3.1.1 stvitoria6 1 ''

snmptrap -p 164 -v1 200.132.45.44 public 1.3.6.1.4.1.3.1.1 slourenco 6 0 '' snmptrap -p 164 -v1 200.132.45.44 public 1.3.6.1.4.1.3.1.1 slourenco 6 1 ''

No Anexo 4, podese observar uma série de traps enviadas pelos agentes ao gerente.

2.5.3.4 Switchs e roteadores

Nos servidores Linux e Windows NT configurou-se apenas um tipo de trap, a chamada enterpriseSpecific. Os Roteadores e Switchs possuem diferentes tipos de traps. Sendo assim, convencionou-se um padrão, configurando os mesmos tipos de traps nos diferentes roteadores e switchs. As traps configuradas foram: coldStart, linkDown/Up, por serem padrões em todos os dispositivos em questão.

2.5.3.4.1 Traps nos Switch e Roteadores

Resumidamente poderia-se dizer que as traps configuradas nos switchs e roteadores foram as seguintes:

Cold Start

34

[2]Coldstart: Switch Cisco Catalyst 1900

[2]Coldstart: Switch 3COM 1100 – Super Stack II

[1]Coldstart: Roteador Cisco 2511

Link UP

[4]LinkUP: Switch Cisco Catalyst 1900

[4]LinkUP: Switch 3COM 1100 – Super Stack

[3]LinkUP: Roteador Cisco 2511

LinkDown

[3]LinkDown: Switch Cisco Catalyst 1900

[3]LinkDown: Switch 3COM 1100 – Super Stack II

[2]LinkDown: Roteador Cisco 2511

No Anexo 4, podese observar uma série de traps enviadas pelos agentes ao gerente. Tanto switchs quanto roteadores, possuem a capacidade de receberem traps, contudo, devido ao fato do gerente em questão não ser nem um roteador nem um switch, e sim servidores Windows NT e Linux, este tema não foi abordado.

2.5.4 As Operações de Traps

O controle dos eventos extraordinários de um agente é feito através de

operações de “traps”. A questão é: “qual a melhor maneira de um agente enviar uma

trap a seu agente de rede sem que a rede fique sobrecarregada? ”[32]. A operação de trap é definida quanto ao momento de ser enviada e qual o tipo de trap enviar. Apesar de ser necessário que o gerente da rede esteja sempre pronto para receber uma trap, nem sempre isso é possível, devido ao fato de este poder estar executando outras tarefas.

Se vários eventos extraordinários ocorrem, uma porção da banda passante da

rede estará ocupada com informações de eventos extraordinários o que pode ser

prejudicial ao tráfego normal de dados, violando assim, um dos axiomas de rede.

As traps definidas neste contexto já foram explicitadas anteriormente.

Uma alternativa de trap seria a baseada em “polling”, ou seja, o gerente da rede periodicamente, verifica cada agente sobre sua situação.

Vantagem: Mantém a figura centralizadora do gerente de rede [21];

Desvantagem: Determina o espaço ideal entre uma verificação e outra. Sendo assim se o intervalo for muito pequeno a rede pode ser sobrecarregada com informações inúteis. Uma solução para este problema, seria utilizar um polling orientado à interrupção, ou seja quando ocorrer um evento extraordinário, o nodo gerenciado envia

uma trap única e simples ao gerente. Assim o tráfego na rede é minimizado pois o gerente passa a ser responsável por iniciar a interrupção entre ele e o agente para determinar a natureza do problema, liberando o agente do processamento maior.

2.6 Conclusões do Capítulo

Neste capítulo foram descritos os principais conceitos relacionados ao ambiente de gerenciamento em questão, bem como os procedimentos para a instalação e/ou habilitação do SNMP nos agentes. Um fato que constatou-se é a “fraquesa” do agente para Windows (Win9x/NT).

35

Normalmente, eles apenas oferecem suporte a MIB-II, padrão. Não foi possível achar nenhum agente mais "caprichado", com suporte a HostMIB, a qual é uma MIB poderosa para hosts, porque dela podem-se obter informações sobre um Servidor Web e outros serviços instalados. Infelizmentte a Microsoft não dá muito valor ao SMNP, e prefere utilizar seus próprios métodos de gerenciamento.

36

3 SOFTWARES DE GERENCIAMENTO

O crescimento exponêncial do número de equipamentos interconectados através

de redes de computadores tem resultado em enormes dificuldades para os administradores das redes. O contínuo crescimento em número e diversidade dos

componentes das redes tem tornado a atividade de gerenciamento de redes cada vez mais complexa [2].

O principal objetivo das ferramentas/softwares de gerenciamento é auxiliar o

gerente de uma rede no monitoramento e detecção de problemas. Existem basicamente quatro tipos de ferramentas: ferramentas a nível físico, que detectam problemas a nível de cabos e conexões de hardware, tais como cabos abertos e mau funcionamento em hardware de conexão; monitores de rede, que se conectam as redes (um por segmento), monitorando o tráfego. Através do exame de infomações a nível de pacotes, o monitor consegue compilar estatísticas referentes a utilização das redes, tipos de pacotes, número de pacotes enviados e recebidos por cada nó da rede, pacotes com erros e outras variáveis importantes; analisadores de rede, que auxiliam no rastreamento e correção de problemas encontrados nas redes. Para isso apresentam caracteristicas sofisticadas para análise do tráfego na rede, captura e decodificação de pacotes e transmissão de pacotes em tempo real; sistemas de gerenciamento de redes integrados (SGRI), os quais permitem o monitoramento e controle de uma rede inteira a partir de um ponto central. Esses sistemas apresentam interface gráfica com o usuário, seguem o modelo gerente-agente e realizam gerenciamento de falha, performance, configuração, segurança e contabilização.

3.1 Plataforma de Gerenciamento

Uma plataforma de Gerenciamento pode executar várias aplicações de gerência. Uma poderia se especializar em gerência de falhas, outra na gerência de desempenho, etc. Porém, deve-se lembrar que estas várias aplicações terão muitas coisas em comum. Todas devem por exemplo, saber a topologia da rede, todas devem ter mecanismos de conversa com agentes através do protocolo de gerência, todas devem ter formas simples de apresentar informação gráfica ao usuário, etc. Uma plataforma de Gerência é um software especial que possui as seguintes características:

Contém toda a funcionalidade comum a várias aplicações de gerência. Isso inclui algoritmos de auto-descobrimento de topologia, um editores gráficos de topologias, uma base de dados de tecnologia, rotinas de acesso a MIB dos agentes utilizando o protocolo de gerência, armazenamento dos valores recebidos dos agentes numa base de dados, etc. Contém uma aplicação simples de gerência que permite, pelo menos, visualizar graficamente a evolução com o tempo dos valores das variáveis dos agentes. Este tipo de aplicação chama-se MIB Browser. Contém uma API (Application Programming Interface) que permite que várias aplicações especiais sejam construídas e inserídas na plataforma lançando mão de todos os recursos oferecidos pela plataforma. Apresenta uma interface amigável com o usuário, permitindo que qualquer usuário interaja sem necessidade de treinamento, preferencialmente baseada na WEB. Livre de plataforma, podendo assim gerenciar qualquer dispositivo independente

da plataforma.

37

Monitoramento do tráfego em um agente através de gráfico. Através, destes gráficos podem ser feitos levantamentos do perfil do táfego, verificando a performance do equipamento e o tráfego total em um agente SNMP. Este último fator é dado em relação a taxa total de bytes que um agente recebe ou transmite durante um ciclo de leitura (Polling). Esta taxa é obtida pela diferença entre a leitura atual dos valores dos objetos da MIB e a leitura ocorrida no ciclo anterior. Todos estes fatores foram levados em conta na análise/escolha do(s) software(s) de gerênciamento, a serem utilizados neste trabalho.

3.2 Softwares de Gerenciamento

Nesta seção é realizada uma análise de vários softwares para gerenciamento de redes, com o uso do protocolo SNMP. Existe um número impressionante de ferramentas destinadas à gerência de rede e administração remota. Algumas ferramentas incluem análise do tráfego da rede, segurança de rede, monitoramento, configuração, etc.

A solução típica para a gerência de redes é a utilização de Plataformas de

Gerenciamento “Fechadas”, as também chamadas ferramentas de software comerciais de gerenciamento. Entretanto, além dos custos elevados envolvidos neste tipo de solução, por envolver hardware, sistema operacional e finalmente a própria plataforma tem-se ainda agravantes como dificuldade na instalação e uma curva de aprendizado muito grande por parte dos usuários, exigindo grande especialização.

Com base nos conceitos vistos nos capítulos anteriores, realizou-se uma análise de vários softwares capazes de gerenciar dispositivos em redes de computadores através da obtenção de estatísticas de utilização, status da operação, condições de erro, diagnóstico, etc., com diferentes funcionalidades de gerenciamento de redes, priorizando sempre aquelas chamadas Plataformas de Gerenciamento “Aberto”. Analizou-se 36 softwares. Após uma análise detalhada de cada um destes softwares, chegou-se aos softwares que seriam utilizados para o gerenciamento em questão.

WhatsUP;

MIB Master;

MRTG.

O propósito inicial, era a utilização de um único software, o WhatsUP, mas

devido as carências apresentadas por tal, houve a necessidade de se mesclar outros softwares para o complementarem. A seguir está uma relação de alguns dos softwares testados com suas descrições. Logo após é realizada uma descrição do(s) software(s) escolhido(s) para a continuação do trabalho.

38

   

CARACTERÍSTICAS