YouTube Facebook Twitter
Apostilas Artigos Tutoriais Aulas Vídeos Blog Ferramentas de Rede Fórum Downloads Colabore Fale Conosco
» tutoriais
:: Conceitos Básicos de Gerenciamento de Redes

José Mauricio dos Santos Pinheiro em 17/07/2006

 

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.

    :: ( 2ª Parte ) ::
    Custos de uma Rede


    Imprima

    © www.projetoderedes.com.br - Termos e Condições de Uso