Gestão de Redes LAN/WAN com OpenView NNMpaginas.fe.up.pt/~ee00107/relatorio.pdf · 2005-07-08 · Seminário ou Trabalho de Fim de Curso do 2º semestre do 5º ano da Licenciatura

Gestão de Redes LAN/WAN com OpenView NNM

Relatório de Estágio

Dinis Alexandre M. Félix

Real Seguros SA. Orientador:

Prof. Raul Oliveira

Julho 2005

I

De forma a garantir a salvaguarda dos interesses da empresa, requisita-se a confidencialidade deste documento pelo período de três anos.


II

Resumo

Num mundo competitivo como o actual, as empresas precisam

de poder oferecer aos seus clientes serviços com uma certa

qualidade, sob pena de perderem clientes para empresas

concorrentes.

A necessidade de oferecer uma certa qualidade nos serviços

torna-se mais premente com o crescimento explosivo da Internet

e a utilização generalizada de novos serviços baseados em

aplicações sobre esta rede, tais como o comércio electrónico, voz

sobre IP, e aplicações multimédia.

O trabalho desenvolvido teve como objectivo identificar e

estudar as normas, mecanismos, políticas e aplicações a utilizar

na gestão de uma infra-estrutura informática.

Com a consciência de que uma gestão efectiva terá de ser

baseada no conhecimento profundo dos mecanismos de gestão,

das tecnologias envolvidas e da configuração da infra-estrutura

da instituição, o estudo descrito ao longo deste relatório teve por

base estes propósitos.

O estudo efectuado terminou com a implementação prática de

um sistema de gestão adequado a uma infra-estrutura informática

empresarial. Desta implementação serão apresentados alguns

resultados que mostrarão a necessidade e vantagens de utilizar

um sistema de gestão na infra-estrutura estudada.


III

Abstract

In a competitive world as the current one, the companies need to

be able to offer to their customers services with a certain quality,

because the risk of losing customers for competing companies.

The necessity to offer a certain quality in the services becomes

more pressing with the explosive growth of the Internet and the

generalized use of new services based on it, such as the

electronic commerce, voice over IP, and multimedia

applications.

The developed work had the purpose of identifying and studying

the norms, mechanisms, politics and applications to use in the

management of a computer infrastructure. With the conscience

of that an effective management is based on the deep knowledge

of the mechanisms of management, the involved technologies

and the configuration of the infrastructure of the institution, the

study described on this report had for base these intentions.

The study ended with the practical implementation of an

adequate system of management to a computer infrastructure.

Of this implementation some results will be presented and will

show the necessity and advantages of use a system of

management in the studied infrastructure.


IV

Índice

1. Introdução........................................................................................................................... 1

1.1 Enquadramento do Projecto ....................................................................................... 1

1.2 Objectivos................................................................................................................... 1

1.3 Estrutura do relatório.................................................................................................. 2

2. Gestão de Redes ................................................................................................................. 4

2.1 Componentes básicos de um sistema de gestão ......................................................... 8

2.2 Protocolo SNMP ........................................................................................................ 9

2.3 MIB - Management Information Base ..................................................................... 12

2.4 Arquitecturas de Gestão ........................................................................................... 17

3. O OpenView NNM .......................................................................................................... 21

3.1 Funcionamento do software ..................................................................................... 22

3.2 Bases de dados ......................................................................................................... 23

3.3 Mapas ....................................................................................................................... 24

3.4 Eventos ..................................................................................................................... 26

3.5 Alarmes .................................................................................................................... 28

3.6 Correlação de eventos .............................................................................................. 29

3.7 Recolha de dados...................................................................................................... 30

3.8 Interface WEB.......................................................................................................... 32

3.9 Acesso ao NNM ....................................................................................................... 34

4. Arquitectura de rede e serviços ........................................................................................ 35

4.1 Descrição do funcionamento da Real Seguros ......................................................... 35

4.2 Requisitos ................................................................................................................. 43


V

5. Gestão efectuada .............................................................................................................. 47

5.1 Instalação do Openview ........................................................................................... 47

5.2 Primeira descoberta da rede ..................................................................................... 48

5.3 Configuração dos mapas .......................................................................................... 50

5.4 Instalação final ......................................................................................................... 58

5.5 Recolha de dados e configuração de eventos ........................................................... 61

6. Conclusões ....................................................................................................................... 68

6.1 Trabalho futuro......................................................................................................... 69


VI

Índice de figuras

figura 2.1 – modelo OSI............................................................................................................. 5

figura 2.2 – comparação dos modelos ........................................................................................ 7

figura 2.3 – elementos básicos de um sistema de gestão ........................................................... 8

figura 2.4 – Protocolo SNMP................................................................................................... 10

figura 2.5 – tipo de operações SNMP ...................................................................................... 11

figura 2.6 – estrutura lógica da MIB ........................................................................................ 14

figura 2.7– MIB II .................................................................................................................... 15

figura 2.8 – identificador do objecto da MIB........................................................................... 16

figura 2.9 – arquitectura de gestão distribuída hierárquica ...................................................... 19

figura 2.10 – arquitectura de gestão distribuída cooperante..................................................... 20

figura 3.1 – mapa do OpenView .............................................................................................. 23

figura 3.2 – submapas............................................................................................................... 24

figura 3.3 – mapas e submapas................................................................................................. 25

figura 3.4 – alterações visíveis no mapa do OpenView ........................................................... 25

figura 3.5 – janela de configuração dos intervalos de Polling no OpenView .......................... 26

figura 3.6 – configuração de eventos 1 .................................................................................... 27

figura 3.7 – configuração de eventos 2 .................................................................................... 27

figura 3.8 – alarm browser ....................................................................................................... 28

figura 3.9 – alarm categories .................................................................................................... 28

figura 3.10 – correlação de eventos.......................................................................................... 29

figura 3.11 – MIB Expression .................................................................................................. 31

figura 3.12 – Data Collection & Thresholds ............................................................................ 31

figura 3.13 – configuração dos limites ..................................................................................... 32

figura 3.14 – imagem de uma mapa através da interface WEB ............................................... 33

figura 3.15 – imagem do Alarm Browser através da interface WEB....................................... 33

figura 3.16 – formas de acesso ao NNM.................................................................................. 34


VII

figura 4.1 – esquema físico da rede da Real Seguros............................................................... 36

figura 4.2 – esquema lógico da VLAN de voz......................................................................... 38

figura 4.3 – esquema de servidores .......................................................................................... 39

figura 4.4 – esquema da ligação aos pisos da Sede.................................................................. 40

figura 4.5 – delegação sem telefonia IP ................................................................................... 40

figura 4.6 – delegação com telefonia IP................................................................................... 41

figura 5.1 – mapa da rede ......................................................................................................... 48

figura 5.2 – descoberta inicial da rede de dados ...................................................................... 49

figura 5.3 – mapa da rede de dados configurado...................................................................... 50

figura 5.4 – ligação dos servidores ao switch........................................................................... 51

figura 5.5 – segmento 5 ............................................................................................................ 52

figura 5.6 – interfaces de um router de uma delegação............................................................ 53

figura 5.7 – tipos de delegações ............................................................................................... 54

figura 5.8 – configuração dos intervalos de polling ................................................................. 57

figura 5.9 – MIB Browser ........................................................................................................ 60

figura 5.10 – Data Colection .................................................................................................... 62

figura 5.11 – configuração de um evento para envio de e-mail ............................................... 64

figura 5.12 – mapa do router de uma delegação ...................................................................... 65

figura 5.13 – alarmes de backup............................................................................................... 66

figura 5.14 – utilização das interfaces de backup..................................................................... 66


1

1. Introdução

A utilização das tecnologias de informação e da Internet para os mais variados fins, e nas

mais diversas áreas, criou novos problemas de gestão das infra-estruturas de informática.

A gestão de redes foi evoluindo e deparando-se com novos desafios, como o controlo de

qualidade de serviço, diferenciação de tráfego e o suporte de serviços a que as actuais redes de

dados têm sido sujeitas, tendo sempre como objectivos tornar eficientes e efectivos os

recursos de informática para a empresa em geral e para os utilizadores em particular.

Face a todas as questões expostas a gestão de uma infra-estrutura de informática é, com

certeza, uma tarefa complexa, estando dependente não só dos meios tecnológicos existentes,

mas também e sobretudo, da implementação de políticas concertadas que estabeleçam as

regras básicas de funcionamento da infra-estrutura.

1.1 Enquadramento do Projecto Este relatório descreve o projecto de estágio realizado no âmbito da disciplina Projecto,

Seminário ou Trabalho de Fim de Curso do 2º semestre do 5º ano da Licenciatura em

Engenharia Electrotécnica e de Computadores.

O estágio curricular foi realizado no período compreendido entre Março e Julho de 2005, na

empresa Real Seguros SA, tendo estado integrado durante esse período no Departamento de

Sistemas de Informação - DSI.

1.2 Objectivos O projecto realizado teve como objectivo a implementação de um sistema de gestão de redes

da infra-estrutura informática da Real Seguros SA.

Relativamente à linha de trabalho seguida, existiu uma primeira fase de estudo, ao que se

seguiu uma abordagem teórica do problema e levantamento de requisitos da empresa.


2

De um modo geral, o sistema de gestão deve permitir minimizar as consequências do

aparecimento de problemas na infra-estrutura de fornecimento de serviços; realizar as funções

de detecção, isolamento e reparação de problemas na rede; analisar tempos de falha e verificar

o cumprimento dos níveis de serviço predefinidos e obter relatórios sobre a infra-estrutura da

rede informática.

Para dar resposta a estes requisitos foi desenvolvido um sistema de gestão centralizado,

baseado no software de gestão da Hewlett Packard, OpenView Network Node Manager.

Como não existia até ao momento nenhuma ferramenta de gestão, a implementação do

sistema de gestão foi desde a instalação do programa até á configuração adequada do mesmo,

de forma a permitir uma gestão simples e eficaz.

O NNM é uma ferramenta de gestão que faz a supervisão de infra-estruturas informáticas. É

uma das soluções mais utilizadas na gestão de redes e uma das suas principais características

é a capacidade de descoberta automática da topologia da rede e dos equipamentos que a

constituem. Após a descoberta, o NNM permite uma visualização gráfica da rede através de

mapas de topologia onde é mostrado o estado actual dos equipamentos e dos segmentos de

rede.

Para desenvolver um projecto deste tipo, foi necessário adquirir um conhecimento básico de

toda a rede e dos elementos que a compõem, e sobretudo identificar os vários processos

estabelecidos na identificação e resolução de falhas na rede.

1.3 Estrutura do relatório Este trabalho está estruturado em 6 capítulos dos quais, o primeiro é composto por esta

introdução ao trabalho.

No segundo capítulo, pretende-se explicar a teoria sobre gestão de redes que serve de base ao

trabalho efectuado.

No terceiro capítulo é apresentada uma descrição do software utilizado na implementação do

sistema de gestão de redes na empresa.


3

No quarto capítulo temos a descrição do funcionamento da empresa Real Seguros SA, da sua

infra-estrutura informática e dos serviços fornecidos.

Finalmente no quinto capítulo é feita uma descrição de todo o processo de implementação do

sistema de gestão.

O sexto e último capítulo contém as conclusões deste trabalho e apresenta perspectivas de

desenvolvimentos futuros.


4

2. Gestão de Redes

A gestão encontra-se, conceptualmente, divida em áreas funcionais, que podem ou não estar

todas incluídas num mesmo sistema de gestão. As áreas funcionais, propostas pela ISO

(International Organization for Standardization) são:

• A gestão de falhas – inclui a detecção, isolamento e correcção de funcionamentos

anormais. As falhas são condições anormais que conduzem a que os sistemas não

cumpram os seus objectivos operacionais, podendo ser persistentes ou transitórias. As

falhas manifestam-se como eventos particulares (por exemplo erros) na operação dos

sistemas. A gestão de falhas também inclui as funções necessárias para manter e

examinar registos de erros, aceitar e actuar perante mensagens de erro, executar testes

de diagnóstico, isolar e corrigir falhas.

• A gestão de configuração é o conjunto de funções de gestão que permite identificar,

ligar, iniciar, desligar, mudar a configuração, e obter informação sobre mudanças de

configuração de objectos geridos.

• A gestão de contabilização permite identificar custos e atribuir tarifas à utilização de

recursos. A gestão de contabilização também inclui funções para informar os

utilizadores dos custos ocorridos e dos recursos consumidos, para estabelecer limites

de contabilização, e associar planos de tarifas aos recursos.

• A gestão de desempenho permite avaliar o comportamento dos recursos e a eficiência

das actividades de comunicação. A gestão de desempenho também inclui funções para

recolher informação estatística, manter e examinar registos do estado do sistema,

determinar o desempenho do sistema sob condições naturais e artificiais, e modificar o

modo de operação do sistema com o objectivo de realizar tarefas de gestão de

desempenho.

• A gestão de segurança tem como objectivo suportar a aplicação de políticas de

segurança através de meios tais como a criação, destruição e controlo de serviços e

mecanismos de segurança, a distribuição de informação relevante de segurança, e o

relato de eventos relacionados com segurança.


5

Embora esta divisão tenha sido criada no âmbito da ISO (International Organization for

Standardization), tem uma grande aceitação por parte de vendedores de sistemas de gestão de

redes (tanto normalizados, como não normalizados).

As áreas funcionais são endereçadas pelos dois modelos de gestão, o modelo OSI e o modelo

TCP/IP, que protagonizam a referência na actual gestão das infra-estruturas de comunicações.

Modelo OSI

O modelo de referência Open Systems Interconnection (OSI), definido pela International

Organization for Standardization (ISO), deve a sua importância ao facto de ter sido

desenvolvido por um organismo internacional de normalização, constituindo assim, uma

referência na adopção de normas relativas a redes de comunicações.

A utilização do modelo OSI assume maior importância nas redes de telecomunicações. Nas

redes de dados, a referência a este modelo dificilmente é encontrada. No entanto, tem

constituído uma boa base de trabalho para as tecnologias emergentes.

O modelo de referência OSI encontra-se subdividido em 7 camadas distintas, das quais

algumas se aplicam, com maior ou menor extensão a toda a Internet. Estas camadas isolam,

para as camadas superiores, os pormenores de implementação das camadas inferiores, o que

facilita o desenvolvimento a vários níveis.

figura 2.1 – modelo OSI


6

As várias camadas, representadas na Figura 2.1 são:

• Camada física: Esta camada é responsável pelo funcionamento transparente do

transporte dos bits através dos vários meios físicos (cobre, fibra óptica, rádio, etc.),

sendo ainda responsável pelos processos de codificação e modulação.

• Camada lógica: Pode ser dividida em duas sub-camadas, a camada de acesso ao meio

de transmissão, responsável pelo acesso dos vários participantes na comunicação, ao

mesmo meio físico partilhado.

A segunda sub-camada, a Logical Link Layer (LLC), assume, quando existe, as

funções de controlo de erros e agrupamento de bits em mensagens.

• Camada de rede: Esta camada é responsável pelo encaminhamento das ligações

lógicas, fazendo parte dela os mecanismos de comutação e encaminhamento da

informação.

• Camada de transporte: providencia, a dois sistemas terminais, uma interface

independente da camada de rede, permitindo-lhes requisitar determinados parâmetros

da rede, tais como: taxa de transmissão, taxa de erros, atraso,... O estabelecimento de

ligações orientadas ao pacote e à conexão também é efectuado neste nível.

• Camada de sessão: estabelece, estrutura e controla as sessões, providenciando para os

níveis superiores mecanismos de controlo e configuração dessas sessões, que têm

carácter temporário.

• Camada de apresentação: garante, para as aplicações, uma linguagem de diálogo

única e normalizada. Isto significa que as partes envolvidas dialogam num

determinado contexto e representam os dados segundo um mesmo formato. No sentido

lato, este nível é responsável por garantir a mesma interpretação da informação.

• A camada de aplicação: sendo responsável pela interface com o utilizador, contém as

aplicações propriamente ditas e deve ser totalmente independente das camadas

inferiores.

Este modelo é, no entanto, bastante mais complexo que o modelo TCP/IP.


7

Modelo TCP/IP

A arquitectura protocolar TCP/IP possui, neste momento, uma posição dominante no mercado

das redes de comunicações de dados, sendo o modelo utilizado na Internet.

Por detrás desta conjuntura esteve um organismo de normalização aberto, o Internet

Engineering Task Force (IETF), constituído por representantes de várias entidades e empresas

do sector, que fomentaram e fomentam o debate público, através de Request for Comments

(RFC) e aprovaram as normas aplicáveis nas redes IP.

A descrição do modelo Internet pode ser feita, por comparação com o modelo OSI, através da

figura 2.2.

figura 2.2 – comparação dos modelos

Esta figura mostra a comparação entre o modelo OSI e TCP/IP. É possível observar que o

modelo utilizado na Internet é mais simples.

Nesta figura é possível também ver alguns dos protocolos utilizados em cada camada do

modelo, apresentando diferentes facilidades e mecanismos que respondem às diferentes

solicitações de serviço efectuadas pelas camadas superiores.


8

2.1 Componentes básicos de um sistema de gestão Os sistemas de gestão variam conforme a rede que gerem, mas todos deverão seguir uma

linha de arquitectura comum. Existem assim, cinco componentes básicos que estão presentes

em todos os sistemas de gestão de redes: uma estação de gestão, um gestor, um ou mais

agentes de gestão, uma ou mais Management Information Base (MIB), e um protocolo de

gestão.

figura 2.3 – elementos básicos de um sistema de gestão

Estação de Gestão

Uma estação de gestão fornece a plataforma onde reside o gestor. Essa plataforma é

constituída por um sistema operativo, que corre as aplicações do gestor, e por uma aplicação

de interface com o utilizador.

Gestor

O Gestor é a implementação das operações de gestão de rede que monitorizam e controlam os

elementos de rede.

O Gestor fica responsável pelo monitoramento, relatórios e decisões na ocorrência de

problemas.


9

Agente

Um agente é a interface para um elemento da rede, responsável por efectuar as operações de

gestão requeridas pelo gestor. Um agente e um gestor podem coexistir no mesmo sistema.

As funções principais de um agente são:

• Atender às requisições enviadas pelo gestor;�

• Enviar automaticamente informações de gestão ao gestor, quando previamente

programado;�

�

MIB

A MIB é uma base de dados, que contém toda a informação relevante ao gestor, acerca do

elemento de rede que está a ser gerido. Um elemento de rede, como por exemplo um switch, é

representado por uma série de atributos, como cartas, linhas, serviços, etc. Todos estes

atributos constituem a MIB, que pode ser vista como um vocabulário comum ao agente e ao

gestor, utilizado por ambos para troca de informações.

Protocolo de Gestão

É um elemento chave de um sistema de gestão de redes, e define os procedimentos e a

estrutura usada pelo gestor e pelo agente para troca de informação de gestão.

No início da década de 80 o protocolo Simple Network Management Protocol – SNMP

começou a ser desenvolvido pelo Internet Engineering Task Force – IETF, com o objectivo de

disponibilizar uma forma simples e prática de gerir equipamentos numa rede de

computadores. Actualmente as pesquisas na área de gestão de redes têm como objectivo obter

da rede o seu rendimento máximo.

2.2 Protocolo SNMP O SNMP – Simple Network Management Protocol é um protocolo de gestão definido a nível

de aplicação, é utilizado para obter informações de agentes SNMP espalhados numa rede

baseada na pilha de protocolos TCP/IP.


10

Os dados são obtidos através de requisições de um gestor a um ou mais agentes utilizando os

serviços do protocolo de transporte UDP – User Datagram Protocol para enviar e receber

suas mensagens através da rede como podemos ver na figura 2.4.

Entre as variáveis que podem ser requisitadas utilizam-se as MIBs.

figura 2.4 – Protocolo SNMP

A gestão da rede através do SNMP permite o acompanhamento simples e fácil do estado, em

tempo real, da rede, podendo ser utilizado para gerir diferentes tipos de sistemas.

Os comandos são limitados e baseados no mecanismo de busca/alteração. Neste mecanismo

estão disponíveis as operações de alteração de um valor de um objecto e também de obtenção

dos valores de um objecto e suas variações.

A utilização de um número limitado de operações torna o protocolo de fácil implementação,

simples, estável e flexível. Também reduz o tráfego de mensagens de gestão através da rede e

permite a introdução de novas características.

O funcionamento do SNMP é baseado em dois dispositivos o agente e o gestor. Cada objecto

gerido (servidor, router, switch ou qualquer dispositivo que contenha um agente SNMP) é

visto pelo gestor como um conjunto de variáveis que representam informações referentes ao

seu estado actual, estas informações ficam disponíveis ao gestor através de consulta e podem

ser alteradas por ele. Cada dispositivo gerido pelo SNMP deve possuir um agente e uma base

de informações MIB.


11

Operações do Protocolo SNMP

Existem duas operações básicas (SET e GET) e suas derivações (GET-NEXT, TRAP).

• A operação SET é utilizada para alterar o valor da variável; o gestor solicita que o

agente faça uma alteração no valor da variável;�

• A operação GET é utilizada para ler o valor da variável; o gestor solicita que o agente

obtenha o valor da variável;�

• A operação de GET-NEXT é utilizada para ler o valor da próxima variável; o gestor

fornece o nome de uma variável e o cliente obtém o valor e o nome da próxima

variável; também é utilizado para obter valores e nomes de variáveis de uma tabela de

tamanho desconhecido;�

• A operação TRAP é utilizada para comunicar um evento; o agente comunica ao gestor

o acontecimento de um evento, previamente determinado. �

figura 2.5 – tipo de operações SNMP�

�

�

O software do agente SNMP utiliza a porta 161 para receber os pedidos SNMP por parte da

aplicação do Gestor. As Traps, por sua vez, são mensagens não solicitadas enviadas por um

equipamento para o Gestor utilizando a porta 162.


12

São sete tipos básicos de trap determinados:

• coldStart: a entidade que a envia foi reinicializada, indicando que a configuração do

agente ou a implementação pode ter sido alterada;�

• warmStart: a entidade que a envia foi reinicializada, porém a configuração do agente e

a implementação não foram alteradas;�

• linkDown: um dos links do equipamento está em baixo;�

• linkUp: um dos links do equipamento foi activado;�

• authenticationFailure: o agente recebeu uma mensagem SNMP do gestor que não foi

autenticada;�

• egpNeighborLoss: um par EGP parou;�

• enterpriseSpecific: indica a ocorrência de uma operação TRAP não básica.�

Segurança

Alguns mecanismos limitados de segurança permitem controlar o acesso por SNMP a um

equipamento através do uso de Comunidades – community names. O administrador pode e

deve atribuir uma comunidade ao agente SNMP ou ao gestor de um equipamento. Desta

forma, uma aplicação de gestão de rede, apenas poderá ter acesso à informação de gestão de

um equipamento se souber a comunidade configurada nesse equipamento. Existem dois tipos

de comunidades que podem ser configuradas: comunidade de leitura – que permite obter os

valores dos objectos SNMP e comunidade de escrita – que permite alterar esses valores.

2.3 MIB - Management Information Base Antes de definir o que é uma MIB, é importante entender o conceito de objectos geridos. Um

objecto gerido é a visão abstracta de um recurso real do sistema. Assim, todos os recursos da

rede que devem ser geridos são modelados e as estruturas dos dados resultantes são os

objectos geridos. Estes objectos podem ter permissões para serem lidos ou alterados, sendo

que cada leitura representará o estado real do recurso e, cada alteração também será reflectida

no próprio recurso.


13

Dessa forma, a MIB é o conjunto dos objectos geridos, que procura abranger todas as

informações necessárias para a gerência da rede.

O RFC - Request For Comment 1066 apresentou a primeira versão da MIB, a MIB I. Este

padrão explicou e definiu a base de informação necessária para monitorar e controlar redes

baseadas na pilha de protocolos TCP/IP. A evolução aconteceu com o RFC 1213 que propôs

uma segunda MIB, a MIB II.

Basicamente são definidos três tipos de MIBs: MIB II, MIB experimental, MIB privada:

• A MIB II, que é considerada uma evolução da MIB I, fornece informações gerais de

gestão sobre um determinado equipamento gerido. Através das MIB II podemos obter

informações como: número de pacotes transmitidos, estado da interface, entre outras.

• A MIB experimental é aquela em que seus componentes (objectos) estão em fase de

desenvolvimento e teste, em geral, eles fornecem características mais específicas sobre

a tecnologia dos meios de transmissão e equipamentos.

• MIB privada é aquela em que seus componentes fornecem informações específicas

dos equipamentos geridos, como configuração, colisões e também é possível

reinicializar uma ou mais portas de um router.

Construção

As regras de construção das estruturas da MIB são descritas através da SMI - Structure of

Management Information. A estrutura de informações de gestão SMI é um conjunto de

documentos que definem:

• Forma de identificação e agrupamento das informações;�

• Sintaxes permitidas;�

• Tipos de dados permitidos.�

�

Os objectos de uma MIB são especificados de acordo com a ASN.1 - Abstract Syntax

Notation One. A notação sintáctica abstracta é uma forma de descrição abstracta dos dados

com o objectivo de não se levar em consideração a estrutura e restrições do equipamento no

qual está sendo implementada. Para cada objecto são definidos: nome, identificador, sintaxe,

definição e acesso.


14

As instâncias do objecto são chamadas variáveis.

• O Object Name é o nome do objecto e é composto por uma string de texto curto;

• O Object Identifier é o identificador do objecto, formado por números que são

separados por pontos;

• A Sintax, sintaxe do objecto, descreve o formato, ou valor da informação. Pode ser:

o uma sintaxe do tipo simples que pode ser um inteiro, uma string de octetos, um

Object Identifier ou nulo;�

o pode ser também uma sintaxe de aplicação podendo ser um endereço de rede,

um contador, uma medida ou um intervalo de tempo;�

• A definição é uma descrição textual do objecto;

• O acesso é o tipo de controlo que se pode ter sobre o objecto, podendo ser: somente

leitura, leitura e escrita ou não acessível.

Estrutura

A árvore hierárquica da figura 2.6 foi definida pela ISO e representa a estrutura lógica da

MIB, mostra o identificador e o nome de cada objecto.

figura 2.6 – estrutura lógica da MIB


15

O nó raiz da árvore não possui rótulo mas possui pelo menos três sub níveis, sendo eles:

• O nó 0 que é administrado pela Consultative Committe for International Telegraph

and Telephone - CCITT;

• O nó 1 que é administrado pela International Organization for Standartization - ISO;

• O nó 2 que é administrado em conjunto pela CCITT e pela ISO.

Sob o nó ISO fica o nó que pode ser utilizado por outras instituições: o org (3), abaixo dele

fica o dod (6) que pertence ao departamento de defesa dos EUA. O departamento de defesa

dos EUA criou um sub-nó para a comunidade Internet, que é administrado pela International

Activities Board - IAB e abaixo deste nó temos, entre outros, os nós: management,

experimental, private.

• Sob o nó management ficam as informações de gestão, é sob este nó que está o nó da

MIB II.

• Sob o nó experimental estão as MIBs experimentais.

• Sob o nó private fica o nó enterprises e sob este nó ficam os nós das indústrias de

equipamentos.

MIB II

Abaixo da sub árvore MIB II estão os objectos usados para obter informações específicas dos

dispositivos da rede. Esses objectos estão divididos em 10 grupos, como se pode ver no

esquema seguinte:

figura 2.7- MIB II


16

Por exemplo, o grupo System contém um objecto chamado sysDescr, que contém a descrição

do equipamento. Neste caso, o objecto sysDescr possui o seguinte identificador:

figura 2.8 – identificador do objecto da MIB

Exemplos de Objectos da MIB II

Alguns dos objectos pertencentes aos grupos da MIB II são:

Grupo System (1.3.6.1.2.1.1)

� �sysDescr (1.3.6.1.2.1.1.1): Descrição textual da unidade. Pode incluir o nome e a versão

do hardware, sistema operacional e o programa de rede.�

� �sysUpTime (1.3.6.1.2.1.1.3): Tempo decorrido (em milhares de segundos) desde a última

reinicialização da gestão do sistema na rede.�

Grupo Interfaces (1.3.6.1.2.1.2)

� �ifNumber (1.3.6.1.2.1.2.1): Número de interfaces de rede (não importando seu actual

estado) presentes neste sistema.�

� �ifOperStatus (1.3.6.1.2.1.2.2.1.8): Estado actual da interface.�

Grupo IP (1.3.6.1.2.1.4)

� �ipForwarding (1.3.6.1.2.1.4.1): Indica se esta entidade é um gateway.�

� �ipInReceives (1.3.6.1.2.1.4.3): Número total de datagramas recebidos pelas interfaces,

incluindo os recebidos com erro.�

Grupo ICMP (1.3.6.1.2.1.5)

� �icmpInMsgs (1.3.6.1.2.1.5.1): Número total de mensagens ICMP recebidas por esta

entidade. Incluindo aquelas com erros.

Grupo TCP (1.3.6.1.2.1.6)

� �tcpMaxConn(1.3.6.2.1.6.4): Número máximo de conexões TCP que esta entidade pode

suportar.�


17

� �tcpCurrentEstab (1.3.6.2.1.6.9): Número de conexões TCP que estão como estabelecidas

ou a espera de terminar.�

Grupo UDP (1.3.6.1.2.1.7)

� �udpInDatagrams (1.3.6.1.2.1.7.1): Número total de datagramas UDP entregues aos

usuários UDP.�

� �udpLocalPort (1.3.6.1.2.1.7.5.1.2): Número da porta do usuário UDP local.�

Grupo SNMP (1.3.6.1.2.1.11)

� �snmpInPkts (1.3.6.1.2.1.11.1): Número total de mensagens recebidas pela entidade

SNMP.�

� �snmpOutPkts (1.3.6.1.2.1.11.2): Número total de mensagens enviadas pela entidade

SNMP.

2.4 Arquitecturas de Gestão A arquitectura de gestão define a estrutura das entidades que realizam a gestão da rede e os

seus métodos de comunicação.

Existem dois modelos principais para definir as arquitecturas de gestão, o centralizado e o

distribuído, tendo este último vários tipos.

Arquitecturas Centralizadas

Uma arquitectura centralizada possui uma única estação de gestão e uma colecção de agentes

locais a cada equipamento gerido. Esta estação tem a aplicação de gestão que concentra todas

as capacidades de processamento. Os agentes locais de cada equipamento limitam-se a

permitir recolher dados ou enviar traps, no caso de se utilizar o protocolo SNMP. Desta

forma, uma arquitectura centralizada tem a vantagem de ser simples, mas proporciona uma

baixa flexibilidade e uma reduzida possibilidade de reconfiguração. Além disso, este tipo de

solução não é viável para redes muito grandes, e gera congestão na zona da rede próxima da

estação de gestão.


18

Arquitecturas Distribuídas

Certas tarefas de gestão precisam de controlo e processamento distribuídos. Exemplos são

aplicações que necessitem de respostas rápidas baseadas em informação local e aplicações

que manipulem grandes quantidades de informação para.

A distribuição também melhora a escalabilidade e a tolerância a falhas dos sistemas de gestão.

No entanto, a distribuição exige uma maior complexidade dos agentes nos equipamentos.

A necessidade de estar perto da informação e a frequência de polling (consultas aos agentes)

pode obrigar a que os cálculos sejam realizados localmente aos agentes, correspondendo a

uma arquitectura distribuída.

Se a capacidade disponível na rede face à quantidade de informação a transferir for grande,

pode-se recorrer a uma solução centralizada. Caso se tenha uma ligação de baixo débito, tem

de se optar por uma solução de gestão distribuída, com processamento junto dos

equipamentos.

Finalmente, aplicações que necessitem de interacções frequentes, ou com transferência de

estruturas de dados complexas, scripts, ou mesmo executáveis, também têm vantagem numa

solução distribuída.

A forma mais simples de descentralização é a monitorização remota proporcionada por

sondas RMON (Remote Network Monitoring). Estas sondas analisam o tráfego num segmento

de rede, podendo realizar autonomamente um conjunto predefinido de estudos que podem ser

configurados remotamente.

Adicionalmente, é possível configurar a sonda para gerar o envio de uma notificação para o

gestor, quando uma situação particular é detectada.

A gestão distribuída é baseada na delegação de tarefas a outras entidades. A gestão por

delegação (Management by Delegation) consiste no envio de programas de gestão para

agentes onde executam tarefas de gestão.

Para suportar gestão distribuída, as arquitecturas distribuídas onde as aplicações de gestão se

sustentam podem ser divididas em dois tipos:

• arquitecturas hierárquicas

• arquitecturas cooperantes.


19

Uma arquitectura hierárquica de gestão é caracterizada por uma árvore de gestores:

• No nível de topo é executada a aplicação de gestão que normalmente delega tarefas

nos níveis inferiores, podendo em casos excepcionais actuar directamente sobre os

agentes;

• Os gestores de nível intermédio recebem as aplicações delegadas, e têm

responsabilidade de executar tarefas de gestão sobre os níveis inferiores, sob controlo

do nível superior;

• Finalmente, os agentes no nível inferior apenas contêm os objectos geridos sobre os

quais são executadas as tarefas de gestão.

A figura 2.9 exemplifica uma arquitectura distribuída hierárquica

figura 2.9 – arquitectura de gestão distribuída hierárquica

Nas arquitecturas cooperantes, os agentes normalmente trabalham por objectivos de gestão,

tendo autonomia para cooperar com os outros agentes para atingir esses objectivos. A estação

de gestão injecta um programa na rede que percorre vários nós, recolhendo e processando a

informação, podendo voltar à estação gestora com o resultado pretendido.

A cooperação pode não se limitar a um itinerário de uma entidade activa, sendo possível

combinar processamento local nos vários nós com comunicação entre eles.


20

figura 2.10 - arquitectura de gestão distribuída cooperante

É possível combinar arquitecturas hierárquicas e cooperantes, embora em muitos casos a

cooperação se restrinja aos níveis hierárquicos superiores, mantendo-se inalterados os agentes

nos equipamentos.

Pensa-se que no futuro as arquitecturas de gestão de redes e sistemas serão cada vez mais

distribuídas e flexíveis. Assim, uma arquitectura de gestão deve poder adaptar-se

dinamicamente, tanto a diferentes topologias de rede, como a diferentes necessidades de

processamento de tarefas de gestão.


21

3. O OpenView NNM

A Hewllet Packard possui uma das mais vastas gamas de produtos relacionados com gestão,

quer de redes, quer de sistemas e serviços. Desse grupo de produtos, o Network Node

Manager (NNM) da família OpenView, é a plataforma mais divulgada e utilizada no contexto

de gestão de redes. Esta plataforma é desenvolvida para várias configurações de hardware e

também para funcionar na maioria dos sistemas operativos (HP-UX, SUN OS, Solaris,

Windows NT).

A liderança no mercado e um reconhecimento internacional fazem do o Network Node

Manager uma das melhores soluções na área da gestão.

O NNM possui, como uma das suas mais valias, uma componente gráfica que se organiza em

diferentes símbolos e cores, possibilitando através de uma inspecção visual, identificar

problemas na rede.

Um elemento também essencial na plataforma de gestão é a existência de uma base de dados

central. O NNM oferece a possibilidade de utilizar a sua própria base de dados embebida ou

utilizar outras soluções mais frequentes, como é o caso do Oracle ou do Microsoft SQL.

Uma outra aposta por parte da HP é a disponibilização de uma interface WEB baseada em

JAVA para as suas aplicações de gestão, o que possibilita o acesso a partir de qualquer ponto

da rede à aplicação de gestão.

Em relação às áreas funcionais de gestão de redes, o OpenView NNM dedica-se à gestão de

falhas e problemas, à gestão de desempenho e à gestão de configurações e alterações.

Na gestão de falhas e problemas o NNM possibilita:

• a descoberta automática dos objectos da rede e da sua topologia;

• monitorização constante dos interfaces de equipamentos e o envio de alertas;

• gestão de todos os objectos que implementem SNMP ou suportem IP;

• monitorização das MIBs standard e dos vários fabricantes;

• definição de alarmes em função de valores limite predefinidos;


22

• filtragem e correlação dos alarmes de forma a simplificar o problema;

• armazenamento dos alarmes e eventos para futura análise.

A nível da gestão de desempenho, o NNM permite:

• a colecção e armazenamento dos eventos e valores estatísticos;

• diagnóstico e prevenção de problemas através da análise dos dados recolhidos;

• tratamento dos dados por aplicações à medida.

Na gestão de configurações e alterações, o NNM permite guardar a configuração dos

equipamentos de interligação e manter um registo das mudanças de equipamentos na rede.

3.1 Funcionamento do software O NNM recolhe e organiza constantemente informação da rede, apresentando graficamente

uma representação desta.

Uma das principais características é a capacidade de descoberta automática dos dispositivos

da rede e da forma como se interligam. A descoberta automática dos dispositivos é baseada

numa combinação dos protocolos SNMP e ICMP, transmitidos sobre UDP para encontrar

todos os nós da rede. Tem como princípio de funcionamento a ”interrogação” das tabelas

ARP e dos equipamentos da rede através dos agentes SNMP.

A informação recolhida sobre os nós descobertos é armazenada nas bases de dados do NNM e

é utilizada automaticamente para gerar mapas de topologia da rede.

Quando algum elemento da rede não é descoberto automaticamente o OpenView NNM

permite adicioná-lo, desde que ele possua um endereço IP, através de outros métodos não

automáticos, como a criação de ficheiros com os endereços que se pretende adicionar.

O NNM oferece também a possibilidade de criar um ficheiro com endereços, ou gama de

endereços IP de dispositivos que não queremos que sejam descobertos ou utilizar filtros, de

forma a que apenas um determinado tipo de objectos da rede seja encontrado.


23

Na figura 3.1 está a apresentação de um mapa do OpenView. Este é um exemplo de um

segmento da rede, representado num mapa do OpenView, em que se pode observar um switch

na zona central onde se ligam routers e servidores.

figura 3.1 – mapa do OpenView

3.2 Bases de dados Toda a informação recolhida pelo NNM, nomeadamente mapas e eventos, é armazenada

numa base de dados interna, que pode ser subdividida em cinco bases diferentes:

• objectos – guarda as propriedades de cada objecto gerido;

• topologia – guarda registos das últimas alterações na rede;

• mapas – regista as propriedades dos mapas e a forma como estão organizados;

• eventos – lista eventos recebidos;

• estatística – guarda a informação recolhida das MIBs.


24

No entanto esta base de dados apenas pode ser manipulada pelo NNM. È por isso que existe a

possibilidade de exportação da informação para bases de dados relacionais, dos quais são

exemplos MsSQL e Oracle, ou então a própria base de dados SQL do OpenView. Estas bases

de dados (data warehouses) permitem o armazenamento da informação da rede para posterior

análise. O OpenView possui ferramentas que criam relatórios com base nesta informação, no

entanto é possível utilizar outros softwares dedicados à análise de dados.

3.3 Mapas Os mapas permitem observar diversas perspectivas da rede que pretendemos gerir, o que

facilita muito a gestão, além disso podemos configurá-los de forma a representarem a nossa

rede o melhor possível, pois a descoberta inicial automática nem sempre é a melhor

representação para as nossas necessidades.

Os mapas são representações gráficas dos objectos que constituem a rede e são formados por

submapas organizados hierarquicamente. Na realidade, na interface gráfica do OpenView

NNM nunca se vê um mapa directamente, o que se observa é um ou mais submapas que

representam os objectos geridos. Os objectos são representados nos submapas por símbolos e

podem ser representados em mais do que um mapa ou submapa, como mostra a figura 3.2

figura 3.2 - submapas


25

Resumindo, um submapa é uma visão particular de um mapa e juntamente com os símbolos

representam a interface gráfica do OpenView. A figura 3.3 é um esquema do que foi

explicado anteriormente e representa um mapa. Como podemos observar, o que se vê

concretamente são vários submapas com diversos objectos.

figura 3.3 – mapas e submapas

Quando ocorre uma alteração num objecto, por exemplo, quando um servidor é desligado,

essa alteração é visível no mapa através da alteração da cor do símbolo que o representa. Na

figura 3.4 podemos observar a alteração que ocorreu no mapa quando o servidor s002it2 foi

desligado.

figura 3.4 – alterações visíveis no mapa do OpenView


26

A capacidade de manter um mapa actualizado é um dos pontos fortes do NNM. O método

utilizado para manter a informação actualizada baseia-se no teste regular (polling interval) do

estado de cada dispositivo, que é feito através de ICMP pings.

Para obter um nível máximo de eficácia sem sacrificar em demasia a largura de banda

disponível é possível definir frequências de teste diferenciadas consoante a importância dos

diversos dispositivos a gerir. Na prática, o Polling Interval define, aproximadamente, o tempo

necessário para o sistema de gestão detectar uma anomalia.

figura 3.5 - janela de configuração dos intervalos de Polling no OpenView

3.4 Eventos O conceito de evento é fundamental na compreensão e aproveitamento total das

funcionalidades proporcionadas pelo Network Node Manager. A gestão com base em eventos

permite efectuar com eficácia, gestão por excepção, ou seja, efectuar acções de gestão

baseadas na ocorrência de uma situação considerada excepcional.

Um evento pode ser gerado por uma trap (enviada por um agente SNMP de um elemento da

rede) ou então pelo próprio NNM . O NNM possui eventos previamente configurados que são

gerados quando ocorrem alterações na rede, por exemplo, quando uma interface de um router

fica inactiva, o NNM verifica essa inactividade ao executar o polling e consequentemente

gera um evento do tipo Link Down, mesmo que o router em questão não esteja configurado

para enviar traps.


27

Com o NNM é possível configurar eventos, criar novos eventos e correlacioná-los.

A função Event Configuration permite controlar a forma como o NNM faz o tratamento dos

eventos, assim como criar novos eventos. De entre as diversas possibilidades de configuração,

as seguintes são as mais importantes:

• Decidir quais os eventos que são colocados no alarm browser e em que categoria;

• Personalizar a mensagem de alarme, assim como escolher a importância deste, como

podemos ver na figura 3.6;

• Executar uma acção automática quando o evento for gerado, como por exemplo enviar

um e-mail ou activar um alerta sonoro, como podemos ver na figura 3.7

figura 3.6 - configuração de eventos 1

figura 3.7 - configuração de eventos 2


28

3.5 Alarmes Os eventos gerados podem ser colocados no Alarm Browser, que faz parte da interface do

NNM, como podemos observar na figura 3.8.

figura 3.8 – alarm browser

O Alarm Browser mostra informação sobre o evento ocorrido, o dispositivo que o gerou, a

interface (se for caso disso), a hora a que ocorreu, a importância do alarme (severity) e os

eventos correlacionados.

O Alarm Browser está dividido em 6 categorias:

• Error alarms;

• Threshold alarms; ;

• Status alarms;

• Configuration alarms;

• Application alarms;

• Problem Diagnosis alarms;

Figura 3.9 – alarm categories


29

As principais vantagens do Alarm Browser são:

• a possibilidade de dividir os alarmes em categorias;

• filtrar os alarmes mostrados de diversas formas (por dispositivo, por exemplo), para

entender melhor a informação disponibilizada;

• eliminar os alarmes da lista quando for desejado (após resolver o problema, por

exemplo);

• executar acções adicionais predefinidas (por exemplo, imprimir um alarme).

3.6 Correlação de eventos Outra das funções do Network Node Manager é a possibilidade de correlacionar eventos. A

correlação de eventos, é uma das funções fulcrais da gestão de falhas. Tem como objectivo

relacionar diferentes eventos, de forma a eliminar redundâncias, facilitando a determinação da

origem do problema.

O sistema de correlação é como um agente de decisão, que visualiza a infra-estrutura de rede

e os diversos eventos como um todo, e não de forma isolada.

A figura 3.10 mostra uma das formas de correlacionar dois eventos isolados, cuja informação

é bastante mais útil sendo possível determinar que um evento B surgiu como consequência

lógica de um evento A.

figura 3.10 – correlação de eventos


30

Como se vê pela figura 3.10, um sistema com correlação de eventos, permite relacionar pares

de eventos UP/DOWN de um mesmo Elemento de Rede. Enquanto que do lado esquerdo, não

temos mais que um registo sequencial dos diversos eventos que vão surgindo, do lado direito,

os eventos do mesmo equipamento são agrupados, formando registos de início/fim de avaria.

Deste modo, os eventos deixam de ter o significado de um acontecimento isolado, e passam a

ser relacionáveis entre si.

Este sistema de correlação reduz drasticamente o número de alarmes colocados no Alarm

Browser e facilita muito a análise destes.

O NNM utiliza 2 estratégias diferentes para redução de eventos, são elas:

• Duplicação de alarmes

Alarmes idênticos não são todos expostos no Alarm Browser, em vez disso apenas o

último é mostrado. É possível controlar quais os eventos que são abrangidos por esta

correlação.

• ECS Correlation

Os eventos são analisados à medida que vão chegando ao Alarm Browser e vão sendo

relacionados, de forma a encontrarem a causa do problema, por exemplo quando

chegam vários eventos do tipo interface down do mesmo dispositivo e depois chega

um evento do tipo node down desse mesmo dispositivo, apenas o último é colocado no

Alarm Browser, enquanto que os outros são correlacionados a este.

Existem várias formas, previamente definidas, para correlacionar eventos, mas

também é possível modificá-las e adicionar novas estratégias.

3.7 Recolha de dados O NNM possui uma função (Data Collection & Thresholds) que permite recolher informação

sobre os elementos da rede que são monitorizados e têm agente SNMP.

A informação é retirada dos objectos da MIB, através do protocolo SNMP. Como tal é

necessário compreender bem as MIBs suportadas por cada elemento que queremos monitorar

e o que representam.


31

O OpenView NNM oferece também a possibilidade de configurar expressões a partir dos

objectos das MIBs, assim, é possível extrair informação mais adequada ás nossas

necessidades. Um exemplo de expressão de MIBs é a taxa de utilização, que utiliza vários

objectos da MIB para extrair um único valor.

figura 3.11 – MIB Expression

A função Data Collection & Thresholds permite-nos escolher qual ou quais os elementos da

rede que vamos monitorar, qual o intervalo com que o vamos fazer e quais as interfaces

(instances), como está exemplificado na figura 3.12.

figura 3.12 - Data Collection & Thresholds

Relativamente á informação recolhida pode-se escolher as seguintes hipóteses:

• Armazenar e não verificar thresholds

• Armazenar e verificar thresholds

• Não armazenar e verificar thresholds


32

No caso de pretendermos verificar limites para a informação recolhida – thresholds, podemos

escolher um valor fixo, ou um valor estatístico, ou seja, o OpenView verifica um valor que

seja muito diferente dos valores recolhidos até ao momento.

È possível configurar também valores de rearm, que funcionam de forma contrária ao

threshold, para detectar quando a informação recolhida voltou ao “normal”.

Uma das vantagens desta verificação, é poder desencadear eventos quando estes limites são

ultrapassados. Estes eventos podem ser os predefinidos pelo NNM ou então ser

personalizados pelo utilizador. Assim é possível receber o tipo de alarme que desejamos

quando um determinado limite é ultrapassado.

figura 3.13 – configuração dos limites

3.8 Interface WEB O NNM permite o acesso, através de um browser WEB, a uma interface, em que podemos

aceder a grande parte das aplicações. No entanto esta interface está mais vocacionada para a

consulta de mapas e eventos, pois o resto das aplicações são um pouco limitadas.


33

A interface do NNM é baseada em JAVA e constituída por um conjunto de applets que

interagem com os módulos correspondentes na estação gestora. A instalação e a configuração

são feitas automaticamente, com a instalação do NNM.

Nas figuras 2.14 e 2.15, podemos observar a imagem de um mapa e do Alarm Browser

através da interface gráfica.

figura 3.14 – imagem de uma mapa através da interface WEB

figura 3.15 – imagem do Alarm Browser através da interface WEB


34

3.9 Acesso ao NNM O acesso à estação gestora pode ser efectuado remotamente eliminando a necessidade de se

estar em frente da consola e permitindo que vários utilizadores acedam à aplicação

simultaneamente, a partir de qualquer ponto da rede.

Os vários acessos são:

• o acesso através da interface WEB disponibilizada pelo NNM, existindo a hipótese de

restringir o acesso através da criação de utilizadores;

• o acesso através de uma consola remota que necessita de instalação na estação do

utilizador;

• o acesso através de uma consola do Terminal Server que apenas requer a presença do

cliente Terminal Server.

figura 3.16 – formas de acesso ao NNM


35

4. Arquitectura de rede e serviços

A utilização de uma ferramenta de gestão de redes implica começar com uma ideia clara do

funcionamento da empresa e da própria rede. Assim, foi necessário um levantamento da

situação da rede, do seu esquema e dos serviços que são utilizados.

4.1 Descrição do funcionamento da Real Seguros A Real Seguros possui uma rede informática que abrange todo o país desde a sua sede

localizada na cidade do Porto até às delegações espalhadas por todo o país.

A infra-estrutura informática da empresa tem sofrido constantes evoluções de modo a

acompanhar o desenvolvimento das novas tecnologias.

A evolução aconteceu a vários níveis, tanto na dimensão da rede, como nas tecnologias

implementadas, meios de transmissão e nos equipamentos de comutação e encaminhamento.

É de destacar a utilização da tecnologia VoIP ( voz sobre IP) dentro da rede interna e telefonia

IP em grande parte das delegações, assim como os equipamentos Cisco Systems que permitem

a integração destes serviços.

A Direcção de Sistemas de Informação – DSI da Real Seguros está localizada no 3ºpiso do

edifício da sede e é o ponto central da infra-estrutura informática. Neste departamento estão

situados todos os servidores, assim como os equipamentos de encaminhamento IP. Também é

neste local que trabalha toda a equipa responsável pela a rede informática.

Sede

Tentando apresentar uma perspectiva geral, a infra-estrutura da sede é constituída por cerca de

200 computadores, distribuídos pelos 5 pisos, e cerca de 25 servidores todos no 3ºpiso, na

DSI.


36

Ao nível das comunicações, a Real possui 3 redes de classe C para comunicação interna. As

redes locais encontram-se interligadas por uma infra-estrutura Ethernet com ligações de

100Mbps para computadores e de 1Gbps para a maioria dos servidores ou outros casos

excepcionais.

As comunicações com o exterior são asseguradas por uma linha ATM de 32Mbps que se

divide em 24Mbps para ligação à VPN e 8Mbps para acesso à Internet.

Sobre esta infra-estrutura são suportados todos os serviços disponibilizados na Real Seguros,

destacando-se: o correio electrónico, o WWW, o DHCP, a autenticação de utilizadores, a

partilha de ficheiros, a voz sobre IP (VoIP) e o acesso à Internet e ao portal de Intranet.

A figura 4.1 representa um esquema físico da rede local na sede da empresa.

figura 4.1 – esquema físico da rede da Real Seguros


37

Como podemos observar na imagem, o acesso ao exterior é realizado por duas colectoras

iguais que trabalham em redundância, de forma a não haver falhas e balancear o tráfego. Estes

equipamentos são routers 3725 da Cisco Systems.

As comunicações com o exterior são divididas nas colectoras, de forma a separar o tráfego da

Internet do tráfego da VPN.

O tráfego da Internet é encaminhado para um outro router da Cisco Systems, o router_intenet

na figura, que posteriormente o encaminha para a Firewall, PIX.

A firewall tem uma ligação a um switch onde estão ligados três servidores, um dos quais é o

servidor da página WEB da Real Seguros, esta é a zona desmilitarizada da rede – DMZ.

A outra ligação da PIX é ao switch 4506B, onde está ligado o servidor de Internet - Proxy.

Todo o acesso à Internet dentro da empresa é feito através deste Proxy.

O tráfego da VPN é encaminhado directamente das colectoras para o switch 4506B.

Existe também um encaminhamento do tráfego interno para a rede do BPN – Banco

Português de Negócios, o equipamento que faz esta ligação é um router Motorola Vanguard

de nome REAL, como se pode ver na figura 4.1.

A infra-estrutura da rede possui ainda três equipamentos que mantêm o serviço de voz sobre

IP – VoIP activo.

Uma gateway de voz Cisco que está ligada á central telefónica da empresa e dois gatkeepers

Cisco que contêm as tabelas de endereçamento das comunicações de voz. Apesar de estes

equipamentos estarem directamente ligados ao switch 4506B, o tráfego de voz está separado

do tráfego de dados, pois o switch faz a divisão em duas VLANs.

A figura 4.2 mostra um esquema da VLAN de voz. Como podemos reparar, as colectoras

também fazem parte desta VLAN, assim como os switches dos pisos 0 e 3, onde existem

telefones IP.


38

figura 4.2 - esquema lógico da VLAN de voz

O switch 4506B é um ponto fundamental na infra-estrutura da rede, pois é onde passa a maior

parte do tráfego interno da rede.

Quase todos os servidores estão ligados directamente ao 4506B por uma ligação Ethernet de

1Gbps, no entanto, os servidores que possuem duas interfaces na placa de rede têm a segunda

interface ligada ao switch 4506A, como podemos ver na figura 4.3 como servidores do tipo 1,

os servidores que apenas têm uma interface estão descritos como tipo 2. Apenas um servidor

está ligado exclusivamente ao 4506A.

Existe ainda um segmento com três servidores que não estão ligados directamente ao 4506B,

mas sim por intermédio de outro switch.


39

figura 4.3 – esquema de servidores

Esta não é a melhor solução para uma correcta configuração da infra-estrutura. Está em vista

para o futuro uma configuração diferente, em que os dois switches funcionem em redundância

de forma a evitar ao máximo as falhas possíveis. No entanto, este é um assunto que não será

abordado neste relatório, visto que foge ao âmbito do mesmo. O projecto de gestão foi

realizado de forma a atender ás necessidades da infra-estrutura actual da rede.

O 4506B é também o ponto de ligação dos switches Cisco 3500. Estes estão divididos, um por

cada piso e a cada um deles estão ligados os computadores pessoais de cada utilizador da Real

Seguros na sede. Esta ligação, no entanto, não é directa, pode existir um ou mais switches a

assegurar esta conexão, como está exemplificado na figura 4.4.


40

figura 4.4 – esquema da ligação aos pisos da Sede

Delegações

Existem dois tipos de configuração de rede nas delegações, conforme estas possuam, ou não,

telefonia IP. Existe também um caso particular da delegação de Lisboa que, devido à sua

dimensão, têm uma infra-estrutura diferente, no entanto também possui telefonia IP.

A figura seguinte esquematiza a rede de uma delegação sem telefonia IP.

figura 4.5 – delegação sem telefonia IP


41

As delegações têm um router Cisco 1700 responsável pelo encaminhamento do tráfego da

delegação para a VPN e vice-versa.

A ligação é efectuada através de uma linha frame relay de 256Kbps, no entanto existe

também uma acesso básico RDIS de backup que apenas funciona no caso de falha da linha

frame relay. Esta linha apenas assegura a ligação á VPN, o acesso á Internet é possível, mas

através do proxy da sede.

Os computadores estão ligados a um switch Cisco 2900 que está ligado ao router. Estas

ligações são Ethernet de 100Mbps.

Os telefones utilizados são analógicos e estão ligados à central telefónica e a uma placa EFXS

do router.

A figura 4.6 esquematiza a rede de uma delegação com telefonia IP.

figura 4.6 – delegação com telefonia IP


42

A telefonia IP é um serviço que permite ás delegações que utilizam telefones IP, realizarem

chamadas para o exterior.

Os telefones IP estão preparados para utilizarem a tecnologia VoIP, esta tecnologia estabelece

ligações de voz através do protocolo IP, ou seja, de uma forma semelhante ás comunicações

dos computadores. A utilização de telefones IP nas delegações permite realizar chamadas para

a sede (e entre delegações) utilizando a linha de comunicação de dados, o que significa

telefonar a custo zero.

Como podemos observar na figura, este tipo de delegações difere do anterior precisamente

pela razão de utilizar telefones IP.

Neste caso, o telefone, como é um equipamento IP, está ligado directamente ao switch, como

os computadores. O tráfego do telefone e dos computadores não se mistura neste switch

devido á sua configuração com duas VLANs, uma de voz e outra de dados.

Para ser possível comunicar com o exterior através do telefone IP, estas delegações possuem,

além da linha de backup, mais dois acessos básicos RDIS que permitem estabelecer quatro

chamadas em simultâneo, duas por cada acesso.

O acesso à VPN, tal como nas delegações sem telefonia IP, é assegurado por uma linha frame

relay de 256Kbps.

A delegação de Lisboa, que é um caso particular destas delegações, difere do esquema

representado no facto de utilizar um acesso primário RDIS e não dois acessos básicos.

Também, devido à sua dimensão, o tráfego gerado é muito maior, o que obriga à utilização de

uma linha de 1,544Mbps para ligação à VPN.


43

4.2 Requisitos Após o estudo da rede e do funcionamento da empresa, fez-se um levantamento das

necessidades ao nível da gestão.

De um modo geral, as necessidades da empresa são:

• minimizar as consequências do aparecimento de problemas na infra-estrutura de

fornecimento de serviços;

• realizar as funções de detecção, isolamento e reparação de problemas na rede;

• analisar tempos de falha e verificar o cumprimento dos níveis de serviço predefinidos;

• obter relatórios sobre a infra-estrutura da rede informática.

Até ao momento, não existia na empresa nenhum sistema de gestão implementado. As falhas

e problemas na infra-estrutura eram detectadas á medida que os utilizadores encontravam

problemas no fornecimento de serviços.

Com este sistema, as falhas nem sempre são detectadas, ou são detectadas tarde, pois a equipa

de Sistemas de Informação tem de esperar por um aviso de algum utilizador para proceder á

resolução de problemas, o que significa perda na qualidade de serviço disponibilizado.

Em relação aos serviços contratados, nomeadamente a ligação da sede ao exterior, assim

como cada uma das ligações frame relay das delegações, não era possível verificar se

cumpriam os níveis de serviço predefinidos.

Também não havia forma de gerar relatórios sobre o comportamento da rede e da

disponibilidade dos equipamentos, assim como era impossível saber o comportamento destes

ao nível de desempenho.

Sendo assim, antes de iniciar a implementação do sistema de gestão, procedeu-se á listagem

do que era necessário gerir e quais os requisitos da empresa.


44

O sistema de gestão deve permitir:

• obter uma visualização simples e correcta de todos os equipamentos críticos,

nomeadamente servidores, routers e alguns switches e verificar alterações nos

equipamentos por simples inspecção visual;

• obter informação sobre o tempo em que cada equipamento esteve operacional, assim

como o desempenho, nomeadamente a nível de memória, CPU, espaço em disco...

• observar o tráfego nas ligações mais críticas, assim como taxas de erro e colisões;

• verificar o estado de alguns serviços fornecidos;

• registar todos os eventos ocorridos na rede numa base de dados, assim como organizar

esta informação de forma a ser analisada;

• receber alertas quando alguma situação mais crítica ocorra.

Além destas necessidades gerais, existem alguns casos específicos que devem ser tratados

com atenção, são eles:

• O desempenho das duas colectoras e do router REAL, devido ao facto de

representarem a ligação da sede ao exterior. Neste caso é fundamental:

o a análise contínua do tráfego, taxas de erro e percentagem de utilização nas

interfaces mais críticas, assim como definir limites para detectar situações

anormais;

o a verificação da utilização do CPU e da memória;

• O desempenho dos dois switches 4506, devido ao facto de serem o ponto de ligação de

todos os servidores, sendo assim deve-se:

o analisar as ligações aos servidores;

o as ligações aos pisos;

o verificar o estado das fontes de alimentação e outros indicadores de

desempenho;

• O estado dos equipamentos da rede de voz, nomeadamente a gateway de voz e as

gatekeepers, pois são elas que asseguram o serviço VoIP, não só na sede, mas também

nas delegações. No caso da gateway, é importante verificar a utilização do CPU e

receber um alerta quando ultrapassar um certo limite.


45

• As ligações dos servidores mais importantes, assim como a análise do estado de

alguns dos serviços fornecidos, são de destacar:

o Os servidores de e-mail;

o O proxy de acesso á Internet que também é servidor DHCP;

o Os servidores do portal de Intranet;

o O servidor de gestão documental – GisDoc;

Requisitos na rede WAN

Apesar de estes requisitos da rede na sede serem muito importantes, a maior necessidade

encontra-se ao nível das delegações, estas representam o ponto mais crítico na gestão da rede,

principalmente por não utilizarem uma tecnologia tão avançada como a utilizada na sede.

Como já foi explicado anteriormente, a ligação de uma delegação ao exterior é feita por uma

linha de 256Kbps, que facilmente pode atingir o limite de tráfego, sendo assim, torna-se

necessário:

• verificar a utilização desta linha a qualquer momento;

• recolher informação sobre o tráfego e utilização para posterior análise e verificação

dos níveis de serviço predefinidos;

• definir limites e gerar alertas para situações anormais;

Quando a linha frame relay fica inactiva por qualquer razão, o acesso RDIS de backup é

activado automaticamente de forma a não haver quebra de comunicação. Se este sistema de

backup funcionar correctamente, os utilizadores na delegação não detectam qualquer

anormalidade e, como tal, a equipa responsável não sabe que a delegação está a funcionar

com o acesso básico de backup. Esta ligação activa representa um custo adicional para a

empresa.

Neste caso, é importante o sistema de gestão implementado:

• monitorizar constantemente as interfaces de backup e gerar um alerta quando estas

forem activadas;

• registar o período de tempo em que a linha esteve activa e verificar a utilização desta

para confirmar se o nível predefinido com a operadora está a ser cumprido.


46

É claro que também é necessário saber se a linha Ehternet que liga o router ao switch da

delegação está activa, no entanto, não é normal haver falha nesta ligação.

Nas delegações com telefonia IP torna-se necessária, além do que foi dito em cima, a

monitorização do estado dos acesso básicos RDIS para voz, porque no caso de falharem deixa

de ser possível a comunicação por telefone, da delegação para o exterior.

Após o levantamento de todas as necessidades da empresa, tanto ao nível da sede como nas

delegações, foi possível iniciar o processo de gestão.


47

5. Gestão efectuada

Este capítulo descreve de forma detalhada, todo o trabalho realizado ao longo dos quatro

meses de estágio na Real Seguros.

Apenas a primeira fase do estágio não será descrita neste capítulo. Esta fase consistiu no

estudo de toda a teoria necessária para a realização deste projecto e na realização de testes

com o OpenView NNM. Após a conclusão desta fase, o projecto seguiu a seguinte ordem:

1. Instalação do Openview

2. Ligação á rede local para descoberta automática da mesma

3. Configuração dos mapas

4. Instalação final

5. Recolha de dados e configuração de eventos

5.1 Instalação do Openview O OpenView NNM foi instalado na primeira fase do projecto num PC:

• Pentuium 4, 2Ghz e 512MB de RAM

• Sistema Operativo Windows XP com o service pack 2

o Internet Information Server

o Agent SNMP

o Internet Explorer 6.0

o Java Plug-In 1.5.1

A versão do OpenView NNM utilizada neste projecto foi a 7.5 com limite para 250 nós

monitorizados.

Devido ao facto de a licença ter limite para nós monitorizados, a gestão da rede incidiu nos

nós fundamentais, o que implica ter um domínio de gestão relativamente pequeno. Neste caso,

a arquitectura de gestão implementada deve ser centralizada, por isso apenas se utilizou uma

estação gestora.


48

5.2 Primeira descoberta da rede Após a configuração da estação gestora, procedeu-se á ligação desta á rede local para a

descoberta automática da rede.

O OpenView tem a opção de descobrir todos os nós IP automaticamente, esta opção foi

activada, mas antes disso foi criado um ficheiro netmon.noDiscover que continha os

endereços IP dos nós que não se pretendia encontrar.

Numa primeira fase desta descoberta da rede, a gama de endereços das delegações foram

colocados neste ficheiro, de forma a fazer a descoberta gradualmente. Também se excluiu da

descoberta o maior número de computadores pessoais, endereços DHCP e impressoras, pois a

gestão destes equipamentos não era um objectivo deste projecto.

A figura 5.1 é uma imagem retirada de uma submapa do OpenView após a descoberta inicial

da rede.

figura 5.1 – mapa da rede


49

Esta imagem foi alterada de forma a não mostrar os endereços das redes. Assim, as redes de

classe C, utilizadas na Real Seguros, estão designadas como rede 1, 2 e 3. Sendo a rede 1 a

rede de voz, a rede 2 é a principal rede de dados e a rede 3 serve de apoio á rede 2 e não tem

importância relevante para a gestão com o OpenView, porque a maioria dos endereços desta

rede pertencem a computadores e impressoras.

Resumindo, a gestão efectuada irá incidir principalmente na rede 2 e um pouco na rede 1.

Analisando a figura 5.1, podemos verificar que a descoberta inicial permitiu ver, além das

redes internas, os equipamentos de encaminhamento, nomeadamente as duas colectoras que

fazem o acesso ao exterior e o router, de nome REAL, que faz a ligação á rede do BPN.

As redes representadas a vermelho com ligação aos routers são redes externas e foram

descobertas pelo OpenView devido ao facto de constarem nas tabelas de endereçamento e as

interfaces externas pertencerem a estas redes.

A nível das redes internas da empresa, a descoberta inicial não gerou mapas com uma boa

representação, como podemos observar na figura 5.2.

figura 5.2 – descoberta inicial da rede de dados


50

Esta imagem retirada do submapa da rede 2, apesar de mostrar todos os servidores, assim

como a estação gestora, D7, não é uma apresentação adequada para uma gestão correcta, pois

todos os elementos desta rede estão representados no mesmo segmento, o que não permite

observar o esquema real da rede. Além disso, nem todos os servidores tinham o agente SNMP

configurado, esta situação pode verificar-se no mapa pelos objectos que são representados

apenas por um quadrado verde sem o desenho de um PC.

Também podemos verificar que os switches 4506A e 4506B não foram encontrados, o que se

deve ao facto de não terem, no momento da descoberta, um endereço IP atribuído.

Os switches 4506A e 4506B, como foi explicado no capítulo anterior, são fundamentais para a

gestão da rede, sendo assim foi necessário atribuir-lhes um endereço IP e configurar o agente

SNMP, para poderem ser geridos pelo OpenView.

5.3 Configuração dos mapas Após serem feitas as alterações na rede. Adicionou-se manualmente á base de dados do

OpenView NNM, os endereços IP dos dois switches, 4506A e 4506B. As alterações no

submapa da rede 2 foram imediatas e permitiram configurar o mapa de forma a representar a

rede o mais semelhante possível com os esquemas apresentados no capítulo anterior.

A figura 5.3 mostra o novo submapa da rede 2.

figura 5.3 – mapa da rede de dados configurado


51

Neste novo submapa já é possível observar os dois switches e os servidores já se encontram

divididos em segmentos. Assim, no segmento 27 (em cima) encontram-se os servidores que

têm uma ligação directa ao switch 4506B, localizado no centro do mapa; no segmento 5 (à

direita) encontram-se os 3 servidores que estão ligados por intermédio de outro switch e no

segmento 29 (em baixo) encontra-se apenas o único servidor que está ligado exclusivamente

ao switch 4506A, localizado por baixo do 4506B no mapa.

A figura 5.4 representa o segmento 27.

figura 5.4 – ligação dos servidores ao switch

Este submapa é fundamental para a gestão de servidores. A partir dele, é possível saber a que

interface do switch está ligado cada servidor e através de uma simples inspecção visual

podemos saber se os servidores estão operacionais, pois quando um deles é desligado, a cor é

alterada.


52

Como os servidores estão todos identificados, é fácil aplicar as operações que pretendemos ao

servidor que queremos, como por exemplo, a recolha de informação ou a apresentação de

dados já recolhidos.

O segmento 29 tem um submapa semelhante a este, com a diferença do switch central ser o

4506A e não o 4506B, além disso o número de servidores é menor.

Quanto ao segmento 5, os 3 servidores são apresentados no mesmo segmento mas o switch ao

qual estão ligados não está representado, optou-se por não atribuir um endereço IP a este

equipamento, pois está prevista uma reestruturação em que esta configuração será alterada e

sendo assim a apresentação dos servidores, como está representada na figura 5.5, considerou-

se suficiente para a gestão dos mesmos.

figura 5.5 – segmento 5

Após a configuração dos mapas na sede, procedeu-se á segunda fase da descoberta da rede, ou

seja a rede WAN composta pelas diferentes delegações. O endereço IP do router de cada

delegação foi adicionado ao mapa para que o OpenView descobrisse o resto dos

equipamentos da delegação.


53

No entanto, optou-se por monitorizar toda a delegação apenas a partir do router, pois a

licença para o número de nós monitorizados é limitada.

O submapa de cada router tem todas as interfaces importantes e é possível retirar toda a

informação necessária para a gestão. Na realidade, o problema encontrado foi o excesso de

interfaces apresentados no submapa, como podemos observar na figura 5.6.

figura 5.6 – interfaces de um router de uma delegação

A figura 5.6 mostra o submapa do router de Famalicão, que é um exemplo de uma delegação

com telefonia IP. Deste grande conjunto de interfaces, foi necessário decidir quais os que

deviam ser mostrados e quais os que deviam ser “escondidos”.

Como vimos no capítulo anterior, as delegações possuem todas uma ligação frame relay á

VPN e um acesso básico RDIS para backup, além disso existe também uma ligação Ethernet

ao switch local. As delegações com telefonia IP possuem ainda mais dois acessos básicos

RDIS para as comunicações de voz.


54

Os mapas foram tratados de forma a apresentarem apenas esta informação essencial. O

resultado é exemplificado na figura 5.7, em que se apresenta uma delegação com telefonia IP

– Pombal e outra sem telefonia IP – Bragança.

figura 5.7 – tipos de delegações

Nestes submapas, podemos ver na delegação com telefonia IP, á esquerda:

• A ligação á VPN através das interfaces Se0/0 e Se0/0.17, que representam a interface

física e lógica, respectivamente;

• A ligação á rede local através da interface Fa0/0.10, VLAN DADOS e VLAN VOZ;

• O acesso básico RDIS de backup através das interfaces BR1/0, BR1/0:1 e BR1/0:2,

que representam a interface física e as duas interfaces de dados, respectivamente;

• Os dois acessos básicos RDIS para comunicações de voz através das interfaces BR2/0,

BR2/0:1, BR2/0:2 e BR2/1, BR2/1:1, BR2/1:2.

A delegação sem telefonia IP, á direita, difere da anterior pelo facto de não ter as interfaces

que representam os acessos básicos e também não existe a divisão em duas VLANs, pois

como não existem telefones IP, não há comunicações de voz sobre IP – VoIP.


55

Neste caso, podemos observar:

• A ligação á VPN através das interfaces de nome LIGAÇÃO Á PT e CIRCUITO, que

representam a interface física e lógica, respectivamente;

• A ligação á rede local através da interface com esse nome;

• O acesso básico de backup através das interfaces BR1/0, BR1/0:1 e BR1/0:2;

A configuração destes submapas foi feita após a consulta á Portugal Telecom. Existem alguns

pormenores aos quais se deve ter atenção.

Como podemos observar na figura, existem duas interfaces a representar a ligação frame

relay, são elas a interface física e lógica, é importante a ligação lógica estar representada neste

submapa porque, segundo a PT, o facto de o router indicar que a interface física está activa

não significa que na realidade a ligação esteja funcional, por essa razão a monitorização deve

ser feita na interface lógica. A interface física não deixa de ser apresentada no mapa para

verificar algum problema que não possa ser observado na interface lógica.

Em relação ao acesso básico de backup, mais uma vez a PT indicou que a monitorização não

deve ser feita na interface física, mas sim nas interfaces lógicas. Como podemos observar na

imagem, a interface física, pela sua cor, está no estado unmanaged, ou seja, não está a ser

monitorizada, no entanto as duas lógicas estão. Caso estas alterem a sua cor para verde,

significa que a linha de backup está activa.

Por último, resta explicar a representação dos acessos básicos de voz. Neste caso, não se

optou por monitorar as interfaces lógicas, pois elas activam e desactivam de cada vez que uma

chamada é estabelecida e desligada. Este cenário iria causar a geração de muitos eventos e

muitas alterações no mapa, o que não seria positivo para uma gestão simples. Sendo assim,

apenas a interface física é monitorizada, o que é suficiente para verificar falhas nestes acessos

básicos RDIS.


56

Mapa final

Após o ajuste de todos os submapas obteve-se o mapa default final. Neste mapa é de destacar

a apresentação de:

• Um submapa com os routers de todas as delegações e os respectivos submapas

correctamente configurados

• Um submapa com o esquema da ligação da rede na sede, onde podemos verificar as

ligações ao exterior com as colectoras e o router REAL, assim como as ligações ás

três redes de classe C.

• Um submapa para a rede 1, rede de voz, com a apresentação dos equipamentos que

asseguram o serviço VoIP

• Um submapa da rede 2, rede de dados principal, com o switch 4506B destacado e os

servidores divididos em segmentos.

A partir do mapa default foram criados mais dois mapas mais específicos, visto que o mapa

default apresenta toda a rede LAN e WAN.

O segundo mapa criado foi um mapa estritamente dedicado a routers, assim ao abrir o mapa

serão imediatamente apresentados todos os routers das delegações, organizados e com

etiquetas de forma a ser fácil encontrar aquele que pretendemos. Existe outro submapa que

apresenta, por sua vez, todos os equipamentos de encaminhamento da sede.

Este mapa não pretende representar ligações, apenas os equipamentos para análise dos

mesmos, visto que a partir da análise de um router podemos verificar todas as suas ligações,

como foi explicado anteriormente.

O terceiro mapa foi criado para apresentar os servidores, no entanto, neste mapa não se exclui

as ligações, pois é importante verificar onde se ligam os servidores, por isso, neste mapa

também encontramos os switches 4506A e 4506B.


57

Polling interval

Como foi explicado no capítulo 3. OpenView NNM, um dos pontos fortes do software é a

capacidade manter os mapas actualizados. O método utilizado para manter a informação

actualizada baseia-se no teste regular (polling interval) do estado de cada dispositivo que é

feito através de ICMP pings.

Este intervalo de verificação pode ser configurado de uma forma geral ou especificamente,

como podemos observar na figura 5.8

Figura 5.8 – configuração dos intervalos de polling

O intervalo utilizado para a generalidade dos nós foi de 1 minuto e aplica-se a nós que não

tenham community name configurado.

Na opção IP Wildcards, foi colocada a gama de endereços dos routers das delegações e o

community name, que é comum a todos estes equipamentos. Foi utilizado também o intervalo

de 1 minuto.

Na opção Specific Nodes, colocou-se os endereços dos equipamentos restantes, atribuindo um

intervalo conforme a necessidade de o manter actualizado e definiu-se o community name de

cada um.


58

5.4 Instalação final Após a configuração dos mapas e preparação do OpenView para recolha de informação,

passou-se á instalação definitiva do software num servidor Compaq Proliant 530 com:

• Processador Pentium III 1266Mhz;

• 1,5Gb RAM;

• Sistema Operativo Windows 2000 Server com service pack 4 e:

o Internet Information Server

o Agent SNMP

o Internet Explorer 6.0

o Java Plug-In 1.5.1

Depois da preparação do servidor, procedeu-se à instalação do OpenView NNM. Desta vez

não se procedeu á descoberta automática da rede, como tal esta opção foi desligada e o mapa

configurado na antiga estação gestora foi transferido para a actual. Para tal foi necessária a

migração da base de dados do PC para o servidor.

Além dos mapas, todas as configurações efectuadas até ao momento foram igualmente

transferidas, podendo continuar assim o trabalho realizado.

Data Warehouse

Como foi explicado no capítulo 3, o NNM permite a utilização de bases de dados externas.

Após a instalação no servidor optou-se por utilizar uma base de dados externa, o SQL da

Microsoft. O armazenamento dos dados recolhidos pela estação gestora, para posterior

análise, irá permitir um melhor trabalho de planificação e estruturação da rede e facilitar o

acesso à informação por vários meios. Tendo em vista os objectivos enumerados, foi criada

uma base de dados num servidor Microsoft SQL, a qual é acedida através de um driver

ODBC implementado na estação gestora e que irá constituir o armazém de dados do NNM.

Depois de criado o ODBC, a criação do armazém de dados é feito pelo NNM, através do

comando: “ovdwconfig.ovpl –rdb OVSQL -load –type msSqlSrvr”.


59

Este comando cria várias tabelas, que podem ser divididas em três grupos distintos:

• Topologia: este conjunto é constituído por 9 tabelas que contém toda a informação

sobre características, topologia, ligações e interfaces dos objectos que representam os

equipamentos da infra-estrutura;

• Eventos: ao grupo dos eventos correspondem 10 tabelas com informação, sobre todos

os eventos gerados pelo NNM, os objectos que estiveram na sua origem, a data e

outras variáveis associadas;

• Estatísticas: as 8 tabelas deste grupo armazenam as estatísticas recolhidas pelas

colecções do NNM, sobre os objectos nelas configurados.

Depois de criadas as tabelas que constituem o armazém de dados, a sua actualização poderá

ser efectuada por um de dois modos, automático ou manual. De raiz, o NNM efectua a

exportação dos dados estatísticos duas vezes por dia (00H40 e 12H40), sendo a exportação

dos restantes dados dependente do gestor.

A informação que requererá mais cuidado será a relativa aos eventos, uma vez que a base de

dados tem um tamanho fixo, sendo rescritos os eventos mais antigos.

MIBs

Assentando a base da comunicação do NNM sobre o SNMP, é necessário conhecer as MIBs

normalizadas e as que são implementadas pelos fabricantes, de modo a ser perceptível a

informação armazenada pelo NNM na sua base de dados de eventos.

Antes de iniciar o processo seguinte, foi necessário algum tempo dedicado à pesquisa de

documentos sobre os equipamentos e as MIBs suportadas por estes. O universo de MIBs

suportadas por cada objecto gerido é muito grande, por esta razão, limitou-se um pouco a

pesquisa apenas ás MIBs que ajudam a satisfazer os requisitos definidos.

No sentido de facilitar o manuseamento das MIBs, existe uma função que possibilita carregar

e descarregar MIBs da base de dados permitindo para ser possível através do MibBrowser, a

visualização e navegação pela estrutura de informação disponibilizada pelos agentes SNMP

implementados nos equipamentos. A figura 5.9 mostra o MibBrowser e a interface de

carregamento das MIBs.


60

Figura 5.9 – MIB Browser

Como foi explicado no capítulo 2, existem três tipos de MIBs, a MIB II, a MIB experimental

e a MIB privada:

• A MIB II fornece informações gerais de gestão sobre um determinado equipamento

gerido. Ao instalar o NNM, esta MIB já contém a maioria dos componentes para a

recolha de informação básica, como: número de pacotes transmitidos, estado da

interface, entre outras.

No entanto, tiveram que ser carregadas outros componentes desta MIB para extrair

toda a informação desejada.

• A MIB experimental é aquela em que seus componentes (objectos) estão em fase de

desenvolvimento e teste. Esta MIB não foi utilizada neste projecto.

• MIB privada é aquela em que seus componentes fornecem informações específicas

dos equipamentos geridos, como configuração, colisões e também é possível

reinicializar uma ou mais portas de um router.

Nenhuma MIB privada é carregada com a instalação do OpenView, por isso, foi

necessário pesquisar e carregar estas MIBs, são de destacar as MIBs Cisco, Microsoft

e Motorola.


61

O carregamento das MIBs serviu para concluir a instalação final do OpenView NNM, no

entanto, é importante referir que a qualquer momento pode-se carregar mais MIBs,

dependendo das necessidades que houver no futuro e das informações que sejam precisas.

5.5 Recolha de dados e configuração de eventos No capítulo anterior foram definidos vários requisitos aos quais o NNM devia dar resposta. A

configuração dos mapas descrita anteriormente, assim como a criação de um armazém de

dados SQL e o carregamento de MIBs cumpre uma grande parte desses requisitos, nesta

altura do projecto já era possível:

• Uma visualização simples e correcta de todos os equipamentos e do estado em que se

encontram, assim como as suas ligações;

• Explorar a MIB Browser de cada objecto gerido, para retirar a informação pretendida;

• Receber eventos no alarm browser enviados pelos objectos ou gerados pelo próprio

OpenView sobre as mudanças de estado dos equipamentos e das suas interfaces.

• Exportar informação de eventos e de topologia para a base de dados externa e gerar

relatórios;

No entanto, existem requisitos que são mais específicos e implicam a recolha contínua de

informação, por exemplo a análise de tráfego e de performance. Esta informação não é

recolhida automaticamente quando se criam os mapas.

Como foi explicado no capítulo 3, o NNM possui uma função que permite recolher dados

sobre os elementos da rede que são monitorizados e têm agente SNMP. Esta informação é

retirada dos objectos da MIB.

A figura 5.10 exemplifica o procedimento utilizado para a recolha de dados.

Ao abrir a função Data Collection & Thresholds, aparece uma janela inicial, representada no

ponto1. Aí é possível escolher uma nova recolha de dados ou alterar as existentes, ao iniciar

uma nova recolha, a janela 2 – MIB Browser é aberta.


62

Depois de escolher o objecto da MIB que pretendemos, passamos ao ponto 3 onde é possível

configurar a recolha de informação, escolhendo qual ou quais os elementos da rede que vamos

monitorizar, qual o intervalo com que o vamos fazer e quais as interfaces.

figura 5.10 – Data Colection

Nos requisitos definidos no capítulo anterior, a análise da performance dos equipamentos foi

referida para as colectoras, switches e gateway de voz. Estes equipamentos são todos do

fabricante Cisco. Após pesquisar a MIB da Cisco no MIBbrowser, foram encontrados os

objectos que indicavam a ocupação do CPU e a memória livre.


63

Iniciou-se uma recolha de dados para cada um dos objectos da MIB, com intervalo de cinco

minutos para todos os equipamentos.

No caso da gateway de voz, foi definido um limite de 70% para a ocupação do CPU, de forma

a receber um alarme quando este limite for ultrapassado.

Em relação ás colectoras, foi configurado um processo de recolha de dados sobre a utilização

das interfaces de ligação á VPN e de ligação ao switch 4506B, assim como as taxas de erro.

Neste caso não foram definidos limites, pois é necessário analisar os dados recolhidos durante

algum tempo de forma a saber o que pode ser uma situação anormal.

Existem objectos da MIB II que indicam o tráfego e os erros numa interface em número de

bits por segundo. No entanto, para recolher informação sobre utilização e taxas de erro foi

necessário utilizar expressões – MIB Expressions. Devido ao facto de estas expressões já

estarem definidas pelo OpenView, o processo para a escolha é semelhante á escolha de um

objecto da MIB no MIB Browser.

Nos switches 4506A e 4506B também se configurou a recolha de informação sobre tráfego e

taxas de erro nas interfaces de ligação aos servidores e aos switches dos pisos.

Estes equipamentos possuem, cada um, duas fontes de alimentação redundantes. Para detectar

falhas a este nível, foi monitorizado o estado de cada uma através de um objecto da MIB da

Cisco.

O OpenView não é um software dedicado á gestão de servidores, no entanto foram carregadas

algumas MIBs que possibilitam verificar alguns serviços. Por exemplo, na MIB da Microsoft

podemos encontrar um objecto que nos indica informação sobre o servidor DHCP. Assim

iniciou-se uma recolha de informação sobre o número de endereços DHCP disponíveis na

rede e definiu-se um limite que gera um evento, de forma a receber avisos quando existem

poucos endereços disponíveis.


64

Este evento foi configurado de forma a ser colocado no Alarm Browser, mas também para

executar um comando que envia um e-mail para o responsável pelo servidor, como podemos

ver na figura 5.11.

Figura 5.11 – configuração de um evento para envio de e-mail

O envio de correio electrónico não é intrínseco ao NNM, sendo necessário recorrer a

aplicações de terceiros que permitam, através de uma linha de comando, enviar uma

mensagem configurada para os responsáveis pelo equipamento em questão com os elementos

relativos ao evento.

A aplicação escolhida dá pelo nome de BLAT, ideal pela sua simplicidade e flexibilidade para

enviar e-mails personalizados através do serviço de mail da Real Seguros.

Delegações

Como foi referido no capítulo 4, as maiores necessidades de gestão na empresa encontram-se

na rede externa á Sede.

O estado dos equipamentos e das interfaces é monitorizado a partir do momento em que se

criam os mapas, como já foi referido. Sendo assim, nesta altura já era possível verificar o

estado de cada interface e receber alertas no caso de alterações.


65

No entanto, pretendia-se uma monitorização personalizada das interfaces de backup, de forma

a poder gerar eventos configurados para serem colocados no Alarm Browser com a

mensagem backup activo e enviar um e-mail com esta informação.

Para cumprir este requisito iniciou-se uma recolha do objecto da MIB II que indica o estado

operacional das interfaces. O estado da interface é dado por um valor numérico, em que o

estado activo corresponde ao valor 1 e o estado inactivo ao valor 2. Sendo assim a recolha foi

configurada para uma das interfaces lógicas de backup com intervalos de um minuto e foi

definido um limite que gera um evento quando o valor for menor que 2, ou seja a interface

está activa. Também foi definido um valor de rearm que gera um evento com a mensagem

backup desligado, quando o valor for maior ou igual a 2, ou seja quando a interface se

desliga.

As interfaces de backup estão representadas a azul, na figura 5.12.

Figura 5.12 – mapa do router de uma delegação

O resultado pode ser observado na figura 5.14 que mostra uma imagem do Alarm Browser

com os alarmes recebidos.


66

Figura 5.13 – alarmes de backup

Apenas se verificou o estado de uma das interfaces de backup, porque o sistema de backup

activa inicialmente um dos dois canais e o segundo canal só deve ser activado no caso do

primeiro ultrapassar 30% de utilização.

Para verificar se este sistema de backup funciona de acordo com o predefinido com a

operadora de telecomunicações, foi feita uma recolha da utilização das interfaces de backup

numa altura em que estas se activaram.

O resultado desta recolha pode ser visto no gráfico da figura 5.13.

Figura 5.14 – utilização das interfaces de backup


67

Neste gráfico, a primeira interface de backup está representada com a cor rosa e a segunda

com a cor azul.

Como podemos observar, a segunda interface só é activada quando a primeira ultrapassa os

30% de utilização, no entanto não volta a desligar quando o tráfego na primeira interface

diminui. Este é um assunto que deverá ser discutido com a operadora, pois significa um custo

adicional e provavelmente desnecessário para a Real Seguros.

Devido ao facto das ligações das delegações á VPN terem uma largura de banda relativa baixa, foi importante também recolher informação sobre a utilização da linha. Assim torna-se possível posteriormente analisar a variação do tráfego e verificar se os níveis de serviço predefinidos estão a ser cumpridos.


68

6. Conclusões

A gestão é uma área muito abrangente, na qual existem inúmeras soluções e tecnologias que

respondem aos mais diversos requisitos. O presente trabalho restringiu-se apenas ao estudo de

mecanismos e soluções de gestão de redes, tendo ficado de fora muitas outras áreas que

importa cuidar nas actuais infra-estruturas de informática.

São várias as conclusões a retirar deste trabalho, importando mencionar que a gestão não

depende apenas do estudo e implementação de plataformas de gestão, mas é em grande parte

constituída por um conhecimento profundo das tecnologias envolvidas e da organização física

e lógica da infra-estrutura, complementada com muito tempo e dedicação na análise e

exploração das várias situações que ocorrem ao longo do tempo.

Os objectivos que definiram o desenvolvimento do estágio foram cumpridos na generalidade,

tendo sido implementada uma plataforma de gestão que permite gerir todos os equipamentos

críticos na infra-estrutura da empresa, sendo possível uma visualização de um esquema da

rede, que por si só, possibilita detectar e reparar problemas.

O sistema de gestão está preparado para receber múltiplos eventos que denunciam o

comportamento da rede, assim como guardá-los num armazém de dados externo ao

OpenView para posteriormente gerar relatórios que permitam analisar tempos de falha,

tráfego nas ligações, utilização de largura de banda, performance dos equipamentos e falhas

de serviços.

Foram também personalizados alguns eventos que permitem alertar os responsáveis pela rede

com o envio automático de um e-mail. Esta solução foi adoptada para situações que devem

ser conhecidas o mais rapidamente possível.

O estudo e implementação aqui efectuados, poderão servir como base para a constituição de

uma plataforma de gestão a aplicar numa infra-estrutura com os mesmo requisitos da Real

Seguros.


69

Este trabalho serviu, entre muitas outras coisas, para adquirir e solidificar conhecimentos na

área da gestão de redes. Em complemento foram adquiridos conhecimentos que permitem,

agora, encarar a gestão com outra perspectiva, valorizando muitos outros factores para além

da plataforma de gestão.

6.1 Trabalho futuro O estágio realizado e descrito neste relatório não pretendeu ser um projecto “fechado”. Após o

fim do estágio pretende-se que o sistema de gestão continue a funcionar como foi planeado,

mas que esteja sempre em permanente evolução, de forma a acompanhar as mudanças na

infra-estrutura informática da empresa e estar sempre adequado ás necessidades da mesma.

Um dos objectivos deste estágio consistiu também na implementação do sistema de forma a

ser flexível e fácil de alterar pelos elementos da equipa de Sistemas de Informação.

Todo o estágio foi realizado com o apoio da equipa de Sistemas de Informação de forma a

compreender o funcionamento e as necessidades da rede. No entanto, a fase final do projecto

foi acompanhada com mais pormenor por um elemento da equipa, que ficará responsável no

futuro pelo sistema implementado.

Este acompanhamento teve como objectivo a passagem de conhecimentos sobre a ferramenta

de gestão, assim como a explicação de todo o trabalho realizado, de forma a poder dar um

seguimento no futuro.

Apesar de os requisitos terem sido cumpridos, de uma forma geral, existe muito trabalho que ainda pode ser realizado, no entanto exigirá algum tempo de análise do funcionamento actual do sistema de gestão.

Sendo assim, recomenda-se:

• A criação de múltiplos relatórios com base na informação recolhida para analisar o comportamento da rede e consequentemente conhecer novas necessidades;

• A exploração da documentação sobre as MIB dos equipamentos e dos serviços, de forma a conhecer novos indicadores de desempenho dos mesmos;

• A constante actualização dos mapas, á medida que a rede da empresa for sendo alterada;

• A integração das bases de dados do OpenView no sistema de backup da empresa.


70

Referências

William Stallings, “SNMP, SNMPv2, SNMPv3, and RMON 1 and 2 Third Edition”, Addison

Wesley, 1999.

Rose, Marshall T. "The Simple Book : An Introduction to Internet Management", 1994

Hewlett Packard, “Managing Your Network”, Hewlett Packard, Fev. 2000.

Hewlett Packard, “Reporting and Data Analysis”, Hewlett Packard, Fev. 2000.

Hewlett Packard, “Migration Guide”, Hewlett Packard, Fev. 2000.

Hewlett Packard, “Correlation Composer's Guide”, Hewlett Packard, Fev. 2000.

Hewlett Packard, “SNMP Developer's Guide”, Hewlett Packard , Fev. 2000.

Cisco Systems: [Em Linha]

Disponível em http://www.cisco.com/

[Consultado em 06/07/2005]

HP OpenView: [Em Linha]

Disponível em http://www.openview.hp.com/


OV Network Node Manager Forum: [Em Linha]

Disponível em http://forums1.itrc.hp.com/


Essential SNMP: [Em Linha]

Disponível em http://www.unix.org.ua/orelly/networking_2ndEd/snmp/index.htm



71

The Simpleweb - MIBS: [Em Linha]

Disponível em http://wwwsnmp.cs.utwente.nl/


Somix - All MIBs: [Em Linha]

Disponível em http://www.somix.com/support/mib_resources.php


Assure MIBs: [Em Linha]

Disponível em http://www.assure24.com/databases/


Tek-Tips OpenView Ops and NNM Forum: [Em Linha]

Disponível em http://www.tek-tips.com/threadminder.cfm?pid=20


Notorious NNM Notes: [Em Linha]

Disponível em http://www.ifost.org.au/Documents/NNM.pdf


Blat Homepage: [Em Linha]

Disponível em http://www.blat.net/


SNMPlink: [Em Linha]

Disponível em http://www.snmplink.org/
