Introdução
Estatisticamente,
enquanto 30% dos custos de uma rede estão diretamente
associados à aquisição de hardware, os 70% restantes
dizem respeito à manutenção e ao suporte dessa rede.
O gerenciamento de
uma rede torna-se uma atividade que contribui decisivamente
para o funcionamento contínuo dos sistemas, garantindo
que a qualidade dos serviços oferecidos mantenha-se
em níveis satisfatórios pelo maior tempo possível.
Alguns exemplos de recursos oferecidos pelas ferramentas
de gerenciamento de redes são:
-
Interoperabilidade
das redes;
-
Alertas de problemas;
-
Aviso antecipado
de problemas;
-
Captura automática
de dados;
-
Gráficos de utilização
de hosts em tempo real;
-
Gráficos de eventos
da rede.
Conceitos Básicos
Existem alguns conceitos
básicos que são comuns a qualquer sistema de gerenciamento,
são eles:
Objeto gerenciado:
Qualquer objeto passível de ser monitorado numa rede
para verificar certos parâmetros de funcionamento.
Podem ser dispositivos lógicos (software) ou físicos
(hardware);
Agente:
Elemento responsável pela coleta de informações dos
objetos gerenciados, enviando-as ao gerente e executando
comandos determinados por ele, baseados em tais informações;
Gerente:
É quem concentra as informações passadas pelo agente
e envia comandos de gerenciamento a este para serem
executados sobre os objetos gerenciados;
MIB (Management
Information Base): É a estrutura
de dados básica de um sistema de gerenciamento. Consiste
basicamente numa tabela onde se encontram os dados
relevantes ao gerenciamento de um sistema. Seu formato
é definido pela SMI (Structure of Management Information),
que é descrita na linguagem ASN.1 (Abstract Syntax
Notation One).
Figura 1 - Exemplo de sistema de gerenciamento
Um agente se reporta
a um gerente através de um protocolo de gerenciamento
e passa para este os dados constantes na sua MIB,
de acordo com as requisições do gerente.
Figura 2 - Arquitetura de um Sistema
de Gerenciamento
O Agente Proxy da
figura é o agente responsável pelo monitoramento remoto,
guardando na sua MIB os dados referentes a todos os
dispositivos sob sua responsabilidade. Ele é utilizado
para eliminar a necessidade de um agente para cada
objeto gerenciado. A MIB do gerente aqui apresentada
nada mais é do que um resumo das MIB's dos Agentes
subordinados.
Objetivos do Gerenciamento
de Redes
Gerenciar consiste basicamente em
monitorar, detectar falhas e, eventualmente, tomar determinadas
medidas corretivas. A figura seguinte mostra o funcionamento
de um protocolo de gerenciamento.
Figura 3 - Mensagens num Protocolo
de Gerenciamento
O gerente pode efetuar
a solicitação de um dado e a resposta a este pedido
pode ser enviada pelo agente. Há também a possibilidade
de notificação do gerente pelo agente em caso de alguma
anomalia na rede. As linhas tracejadas representam
operações opcionais e que eventualmente podem nem
ser utilizadas, que são a escrita de atributos e a
leitura destes pelo gerente.
Com estes objetivos
em mente, podemos enumerar as cinco áreas de gerenciamento
propostas pelo ITU-T:
-
Configuração:
Esta área se preocupa com a interconexão dos dispositivos
gerenciados;
-
Falhas: Tem por
objetivo garantir um funcionamento contínuo da
rede e seus serviços;
-
Desempenho: Tenta
garantir a eficiência da rede, segundo parâmetros
especificados;
-
Segurança: Busca
garantir a segurança de informações sigilosas
em tráfego na rede;
-
Contabilidade:
Determina o custo de utilização da rede e seus
recursos.
Protocolos de Gerenciamento
de Redes
Criado pelos mesmos grupos que desenvolveram
o TCP/IP e o SNMP, o RMON é um padrão IETF de gerenciamento
de redes cuja sigla representa Remote Network Monitoring
MIB. Primeiramente foi desenvolvido o padrão SNMP
e, posteriormente, o padrão RMON.
O Protocolo SNMP
O Simple Network
Management Protocol (SNMP), é um protocolo de
gerenciamento simples. O SNMP não é capaz de definir
um problema em uma rede e nem sua gravidade. Também
não fornece recursos para uma investigação das causas
desse problema. A única informação que se tem através
de um alerta SNMP é que existe um problema em um ponto
qualquer da rede.
Os alertas do SNMP
padrão notificam um problema somente quando ele já
atingiu uma condição extrema suficiente a ponto de
comprometer a comunicação na rede como um todo. Já
o diagnóstico do problema é uma tarefa do administrador
da rede. Assim, o SNMP é simplesmente um alerta para
uma condição extrema da rede.
O comitê do IETF decidiu
que, para promover uma maior e melhor expansão das
tecnologias de rede, era necessário um padrão de gerenciamento
de redes mais sofisticado. Desenvolveu-se então o
RMON.
SNMPv.1
O protocolo SNMP foi
inicialmente idealizado em 1989. Sua arquitetura é
baseada no modelo Internet para redes e sua localização
é equivalente à da camada aplicação no modelo OSI.
A camada inferior
na pilha de protocolos é a UDP (User Datagram Protocol),
que é protocolo de transporte padrão da Internet com
serviço do tipo datagrama. A pilha de protocolos do
SNMP é mostrada na figura seguinte.
Figura 4 - Pilha de Protocolos do
SNMP
Sua operação é bastante
simples, sendo as mensagens (primitivas de serviço)
utilizadas por ele as citadas a seguir:
a) Get (Request,
Next Request, Response): Trata-se do pedido do
gerente para ler os dados de gerenciamento da MIB
do agente. A Get Request faz o pedido inicial pelo
gerente, a Response envia os dados para o gerente
e a Next Request pede outro trecho da tabela seqüencialmente.
b) Set (Request):
Serve para alteração de dados da MIB. O gerente recebe
um pedido de Set Request para alterar determinado
dado.
c) Trap: É
um informe dado ao gerente de que algo de anormal
está acontecendo no sistema, tem funcionamento semelhante
a um alarme.
Na figura seguinte
é mostrado como é feita a troca de mensagens entre
gerente e agente:
Figura 5 - Modelo de Serviço do SNMPv.1
Existem, entretanto,
alguns problemas derivados da simplicidade de implementação
do protocolo SNMPv.1. Primeiramente o Trap SNMP não
é confirmado. Em virtude disto, o agente até pode
enviar a mensagem de Trap ao gerente, mas não saberá
se ele a recebeu, podendo esta mensagem ser perdida
na rede e a anomalia presente na rede eventualmente
nem ser corrigida.
Outro problema é a
limitação da rede a ser gerenciada. Isto ocorre em
virtude do "polling". Além disto, a autenticação
do protocolo é deficiente, uma vez que ela é baseada
nas chamadas comunidades (community based). Alguns
dados do protocolo circulantes na rede podem ser lidas
por pessoas estranhas ao sistema.
Outro fato é que o
SNMPv.1 não suporta a busca em tabelas, permitindo
apenas a existência de um gerente por sistema e que
não se pode criar ou excluir objetos dentro do sistema,
com este protocolo.
RFC 1271
A RFC (Request For
Comments) 1271 enumera os seguintes objetivos para
RMON:
-
Operação off-line;
-
Monitoração preemptiva;
-
Detecção e reportagem
de problemas;
-
Diminuição do
tráfego de informações de gerenciamento entre
o sistema de gerenciamento e o segmento remoto,
com a adição do conceito de "interesse dos
dados";
-
Múltiplos gerentes,
possibilitando o controle de tráfego de vários
segmentos de rede a partir de um ponto central.
Padrão RMON - RFC
1757
Revisões da especificação
original do RMON foram publicadas como o RFC 1757
e tais revisões fazem uso de algumas convenções da
MIB para o SNMPv2.
A RFC 1757 define
o padrão RMON de gerenciamento. Segundo a RFC, o RMON
não é uma pilha de protocolos, nem mesmo um protocolo
por si só. Trata-se de uma extensão de MIB (Management
Information Base), para ser utilizada com protocolos
de gerenciamento de redes em aplicações para a internet,
baseadas no TCP/IP.
Os principais avanços
introduzidos pelo padrão RMON foram o Controle de
Monitoramento Remoto, Múltiplos Gerentes e o Gerenciamento
de Tabelas
Controle de Monitoramento
Remoto - A RMON MIB contém
características que possibilitam o controle efetivo
da estação de gerenciamento. Estas características
podem ser agrupadas em duas categorias:
Configuração:
tabelas de controle e tabelas de dados;
Invocação
de uma ação: um objeto é utilizado para representar
um comando e uma invocação de uma ação pode ser
solicitada, modificando o valor de um objeto.
Múltiplos Gerentes
- Na arquitetura RMON,
agentes podem estar sujeitos ao gerenciamento de muitas
estações gerentes. No caso de um agente RMON ser compartilhado,
alguns problemas podem surgir:
Requisições
concorrentes;
Captura
de um recurso por um determinado gerente por um
longo período de tempo;
Recursos
podem ser atribuídos para um gerente que deu pane
antes de liberar o recurso.
Para tentar solucionar
tais problemas, uma combinação de requisitos deve
ser utilizada:
Inclusão de um campo
de dono para cada linha da tabela de controle;
Reconhecimento da
não necessidade de utilização de um recurso;
Possibilidade de
negociação de um recurso entre gerentes;
A possibilidade
de um operador cancelar reservas de recursos;
Durante uma reinicialização,
um gerente poder liberar recursos.
Gerenciamento
de Tabelas - A especificação
RMON inclui convenções textuais e regras mais claras
e disciplinadas para a adição e remoção de linhas.
O padrão RMON foi
desenvolvido no intuito de resolver questões que outros
protocolos de gerenciamento não eram capazes. Com
base nestas questões, a RFC 1757 define objetivos
gerenciais que o padrão RMON deve observar:
Operação Off-line
- Existem situações em
que uma estação de gerenciamento não está em contato
contínuo com seus dispositivos de gerenciamento remoto.
Isto pode ocorrer como conseqüência de projeto, para
reduzir os custos de comunicação, ou mesmo por falha
da rede, quando a comunicação entre a estação de gerenciamento
e monitor, fica comprometida em sua qualidade. A MIB
RMON permite que um monitor seja configurado para
realizar suas atividades de diagnóstico e coleta de
dados estatísticos continuamente, mesmo quando a comunicação
com a estação de gerenciamento seja impossível ou
ineficiente. O monitor poderá então se comunicar como
a estação de gerenciamento quando uma condição excepcional
ocorrer. Mesmo em circunstâncias em que a comunicação
entre monitor e estação de gerenciamento não é contínua,
as informações de falha, desempenho e configuração
podem ser acumuladas de forma continua e transmitidas
à estação de gerenciamento conveniente e eficientemente
quando necessário.
Monitoramento
Proativo – Devido aos recursos
disponíveis no monitor, é normalmente desejável e
potencialmente útil que ele execute rotinas de diagnóstico
de forma contínua e que acumule os dados de desempenho
da rede. O monitor estará sempre disponível no início
de uma falha; assim, ele poderá notificar a estação
de gerenciamento da falha, assim como armazenar informações
estatísticas a seu respeito. Esta informação estatística
poderá ser analisada pela estação de gerenciamento
numa tentativa de diagnosticar as causas do problema.
Detecção e Notificação
de Problemas - O monitor
pode ser configurado para reconhecer condições de
erro e verificar as mesmas continuamente. Na ocorrência
de uma destas condições, o evento pode ser registrado
e as estações de gerenciamento notificadas de várias
formas.
Valor Agregado
aos Dados - Considerando
o fato de que os dispositivos de gerenciamento remoto
representam recursos dedicados exclusivamente a funções
de gerenciamento e considerando também que os mesmos
localizam-se diretamente nas porções monitoradas da
rede, pode-se dizer que estes dispositivos permitem
a agregação de valor aos dados coletados. Por exemplo,
indicando quais os hosts que geram a maior
quantidade de tráfego ou erros, um dispositivo pode
oferecer (à estação de gerenciamento) informações
preciosas para a resolução de toda uma classe de problemas.
Gerenciamento
Múltiplo - Uma organização
pode ter mais de uma estação de gerenciamento para
as várias unidades da empresa, para funções distintas,
ou como tentativa de proporcionar recuperação em caso
de falha (crash recovery). Como tais ambientes
são comuns na prática, um dispositivo de gerenciamento
de rede remoto deverá ser capaz de lidar com múltiplas
estações de gerenciamento concorrendo para a utilização
de seus recursos.
Dessa maneira, o RMON
tornou-se um padrão por volta de 1990. As principais
características que se buscaram para o RMON foram:
-
Interoperabilidade
independente de fabricante;
-
Capacidade de
fornecer informações precisas sobre as causas
de falha no funcionamento normal da rede, assim
como da severidade dessa falha;
-
Oferecer ferramentas
adequadas para diagnóstico da rede.
Além destas características,
o padrão deveria oferecer um mecanismo proativo para
alertar o administrador dos eventuais problemas da
rede, além de métodos automáticos capazes de coletar
dados a respeito desses problemas.
|