Transferir como ODP, PPTX
Carregado porMauro Tapajós
Gerência de Redes - 1.Introdução e Conceitos de Gerência de Redes
O documento discute conceitos fundamentais de gerenciamento de redes, incluindo necessidades de gerenciamento, áreas funcionais de gerenciamento, arquiteturas de gerenciamento e informações de gerenciamento. Também aborda o crescimento das redes, protocolos SNMP e MIBs, e conceitos como objetos gerenciáveis, classes, encapsulamento e relacionamentos entre objetos.
Gerência de Redes - 1.Introdução e Conceitos de Gerência de Redes
- 1. Sumário Conceitos emGerência de Redes Necessidades de Gerenciamento
- 2.
- 3. Arquiteturas de GerenciamentoInformação de Gerência Como é estruturada
- 4.
- 5. SMI – Estruturada Informação de Gerenciamento
- 6. MIB's – ManagementeInformation Base
- 7.
- 8. Contexto Atual deRedes de Computadores Crescimento das redes e número de equipamentos e de diversidade de tecnologias
- 9.
- 10. Explosão de equipamentosdos vários fabricantes que estão no mercado
- 11. Incrível diversidade desistemas de gerenciamento proprietários que não permitem interoperabilidade entre si
- 12. Atividades Comuns deGerenciamento Monitoramento
- 13.
- 14. O que éGerenciamento de Redes e Serviços?
- 15. O que gerenciar?Equipamentos de Rede
- 16. Aplicações e Serviçosde Rede
- 17.
- 18.
- 19.
- 20. Áreas Funcionais deGerenciamento (segundo o modelo OSI) Gerenciamento de Falhas
- 21.
- 22.
- 23.
- 24.
- 25. Áreas Funcionais deGerenciamento (segundo o modelo OSI) Gerenciamento de Falhas
- 26.
- 27.
- 28.
Notas do Editor
- #3 Resultados: Custos maiores com redes (pessoal qualificado, serviços especializados, software proprietário do fabricante, etc) Dificuldade em manter tudo isso em operação Como gerenciar tudo isso? Que atividades estão envolvidas no gerenciamento de redes de computadores?
- #4 Gerenciamento significa ter o controle e poder agir en função de informações coletadas que mostram situações determinadas. Por exemplo: um link de dados pode apresentar muito atraso. Uma ação possível seria rerotear o tráfego para outro link. Dentre as atividades comuns no gerenciamento de redes, estão: Registrar a ocorrência de eventos Estabelecer critérios para o disparo de alarmes Detectar e diagnosticar a ocorrência de falhas Conhecer e controlar alterações nos equipamentos Acompanhar o desempenho da rede e dos serviços de rede Garantir a segurança Contabilizar recursos
- #5 Para o caso de redes de computadores e ambientes de TI, uma alternativa é usar a própria infra-estrutura existente para atingir os elementos de rede ou pontos definidos da rede, na busca por informações e no disparo de ações sobre estes equipamentos. Outra opção seria montar uma rede paralela à rede existente e que tivesse interseções nos pontos de interesse. Além da necessidade de rede, existirá a necessidade de reconhecer, manipular e tratar toda esta informação obtida. Aplicações de gerenciamento serão aplicações que tratam dados.
- #6 No âmbito de redes, várias são as possibilidades de equipamentos ou itens que se pode monitorar a controlar. Num nível mais baixo se tem a figura do elemento de rede (equipamento). Num nível maior se observa as redes como um todo (como serviços). Praticamente qualquer coisa que tenha presença de rede pode ser gerenciada para permitir a exata noção de realidade do item na rede em questão.
- #7 As área definidas pelo modelo OSI de gerenciamento são uma referência às atividades e focos possíveis dentro de uma solução de gerenciamento. Por exemplo, uma solução pode estar visando tratar e monitorar a segurança de uma rede, e com isso foca sua coleta de informações neste sentido. Itens como número de acessos, tentativas de login, serviços de rede acessados, são informações úteis caso o objetivo seja gerenciamento de segurança. Outros itens como número de quedas de um link ou taxa de erros numa LAN não são tão importantes, como seriam para gerenciamento de performance. Gerenciamento de FALHAS: Assegura operação contínua Detecta, isola e registra o problema Registra as ocorrências Executa testes de diagnóstico Realiza a investigação do ocorrido Comportamento proativo (preferível) ou reativo
- #8 Gerenciamento de DESEMPENHO: Controla o “comportamento” dos recursos de rede Avalia as atividades de comunicação sendo oferecidas na rede Monitora a operação diária da rede Localiza pontos críticos no sistema Registra dados de operação Auxilia funções de planejamento e análise Gerenciamento de CONFIGURAÇÃO: A rede é um sistema dinâmico que sempre está se alterando Manutenção da estrutura física e lógica da rede Acompanhar o ciclo de vida do componente e sua configuração Identificar componentes num nível apropriado e suas relações (topologia) Monitorar cada componente, documentando as trocas que devem manter os requisitos básicos estabelecidos Manter registros dos status de cada componente – topologia e dispositivos Executar alterações na configuração do sistema visando isolar falhas, aliviar situações críticas ou atender necessidades de usuários
- #9 Gerenciamento de SEGURANÇA: Cuida dos mecanismos e procedimentos de proteção Cria, apaga e controla os serviços e mecanismos de segurança Trata da distribuição da informação relacionada com segurança e seus eventos Mantém registros de eventos relativos à segurança Suporta e garante a a política de segurança adotada Gerenciamento de CONTABILIZAÇÃO: Controla recursos Permite que tarifas sejam aplicadas aos recursos de rede (discos compartilhados, banda, arquivamento remoto, serviços de telecomunicações, e-mails, etc) Viabiliza a identificação de custos para a rede e seus recursos Mantém limites de consumo Efetua a melhor distribuição de recursos e alimenta trabalhos de planejamento
- #10 Uma aplicação de gerenciamento irá atingir os elementos de rede e entidades através da própria rede. Isto cria uma preocupação com o quanto a solução de gerenciamento irá pesar sobre a própria rede que se quer gerenciar. A aplicação de gerenciamento poderá visualizar níveis de conectividade e trabalhar em qualquer um deles: 1. Nível de Conectividade local (tecnologia de rede) 2. Nível de Interconexão 3. Nível de Conectividade Lógica (aplicação)
- #11 Uma aplicação de gerência nada mais é uma aplicação de trata dados. Estes dados deverão obedecer determinada estrutura para que seja possível criar soluções de gerenciamento que atuem sobre os mais diversos ambientes de rede. Um protocolo de gerência é normalmente um protocolo de nível de aplicação (possui especificidade). Ele terá seu design formulado para atender as demandas de comunicação entre as entidades que serão definidas na arquitetura de gerenciamento.
- #12 As duas arquiteturas clássicas são a baseada no modelo SNMP, derivada dos padrões Internet/TCP-IP e a arquitetura OSI de gerenciamento, derivada dos padrões de sistemas abertos OSI.
- #13 Numa arquitetura de gerenciamento clássica, temos a figura de uma entidade que obtém a informação de outra entidade que está sendo gerenciada. A interação possível entre estas é traduzida em mensagens de protocolo do tipo request-reply , mensagens de ações diretas ou ainda en mensagens assíncronas (para alarmes, por exemplo).
- #14 No gerenciamento de redes é muito comum a figura de gerentes e agentes. Gerentes: entidade responsável em coletar as informações e disparar ações. Atuam sobre os agentes. Agregam inteligência ao sistema podendo realizar tarefas mais complexas como gerar relatórios para o usuário. Agentes: entidade localizada perto (ou parte) do item sendo gerenciado (como um equipamento) e responde às solicitações do gerente via rede. Permitem o acesso às informações de gerenciamento localizadas localmente e as mantém um reflexo da realidade do equipamento. Os protocolos de gerenciamento permitem ao gerente disparar comandos para o agente através da rede, como qualquer outra aplicação de rede. Por isso, os protocolos de gerenciamento normalmente são protocolos de camada 7. Eles são específicos para a atividade de gerenciamento e implementados em aplicações de gerenciamento.
- #15 Que informação é interessante para o gerenciamento? Dependerá do equipamento e contexto de rede onde ele estiver. Mesmo assim, muitas das informações de gerenciamento relacionadas podem ser assumidas. Por exemplo: uma informação sempre útil de um equipamento como um roteador é sua tabela de roteamento. Com isso, existirão sempre bases de dados de informações comuns na maior parte das atividades. Uma estrutura de informação de gerenciamento é necessária para gerenciar a massa de informações associadas às complexas redes multi-fabricantes que existem. Uma nomenclatura deve ser definida para descrever estas informações. Procedimentos de acesso e alteração das informações devem ser definidos.
- #16 Uma MIB é uma base de dados composta de objetos gerenciados. É implementada localmente nos dispositivos gerenciados. É oferecido o acesso remoto e possíveis alterações, segundo as regras definidas pelo modelo/protocolo de gerenciamento. A idéia é que a MIB seja um reflexo da realidade sendo gerenciada. Um objetos gerenciável é uma abstração que modela e representa um item de informação que se quer gerenciar. Ele tem: Nome Atributos Um conjunto de operações que podem ser executadas sobre ele Os objetos, seu nome, sua descrição, suas características e as possíveis operações sobre eles estarão configuradas na MIB. Uma MIB é dividida em módulos e grupos de objetos relacionados.
- #17 O tratamento e modelagem de informação de gerenciamento normalmente aborda uma estratégia baseada en objetos. Por isso é importante recordar estes conceitos. A abstração de objetos permite o modelamento de quase tudo, assim os objetos representarão a realidade que está acontecendo. Variáveis da MIB: uma instância individual de um objeto gerenciado. Templates (modelos) são usados para se definir os objetos. As implementações devem seguir as informações descritas nos templates para uniforminzar a compreensão e manipulação da informação. Exemplo: se um fabricante armazena e trata o endereço IP de um equipamento como tipo “string” e outro como “inteiro long”, as aplicações que irão coletar e tratar estas informações podem estar trabalhando como tipos de dados incompatíveis.
- #18 É a árvore hierárquica de registro que serve para a classificação de objetos de redes, criando a estrutura de informação que contém todos os objetos existentes. Para evitar a duplicidade de nomes diante de um esquema de nomenclatura dinâmico que cresce muito a cada dia, se adotou uma árvore de nomes para servir como regra ao se determinar nomes para os objetos das MIB's. Os objetos gerenciados comumente usados em gerenciamento estarão abaixo do ramo: iso.org.DoD.internet - 1.3.6.1
- #19 Um objeto é identificado por uma sequência de números inteiros separados por pontos, onde cada número é um ramo na árvore hierárquica. Por exemplo, para o grupo system acima :1.3.6.1.2.1.1.1 O grupo system possui informações que descrevem o sistema. Exemplo de objeto: o que contém a descrição textual do sistema é chamado sysDescr e possui identificador 1.3.6.1.2.1.1.1, pois está dentro do grupo system.
- #20 Num nível mais alto, a SMI é usada para se criar um módulo de informação (um pacote de informações relevantes usadas pelo gerenciamento com SNMP). Em resumo, a SMI é usada para se criar módulos de MIB. A SMI para arquitetura TCP/IP (SNMP) define: Como os módulos de MIB são definidos O subconjunto do padrão ASN.1 usado com SNMP Como todas as construções ASN.1 deverão ser serializadas para envio pela rede Definição do formato dos identificadores de objetos na árvore MIB para gerenciamento Internet A definição e descrição dos objetos gerenciados SNMP A codificação destes objetos para transmissão na rede é feita pelas regras BER A SMI é particular para uma determinada arquitetura de gerenciamento de rede.
- #21 A descrição da MIB formaliza sua estrutura, cada objeto que ela contém e suas características. É necessária uma definição textual da MIB de forma a padronizá-la e permitir que seja implementada por outros fabricantes e desenvolvedores. As variáveis nas MIB são descritas por um subconjunto de facilidades de uma linguagem de descrição de dados chamada ASN.1 (Abstract Sintax Notation). A linguagem ASN.1 é um padrão ISO (8824). Para maiores informações: A Layman's Guide to a Subset of ASN.1, BER, and DER: http://www.umich.edu/~x509/ssleay/layman.html Wikipedia: http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One Introduction to ASN.1: http://asn1.elibel.tm.fr/introduction/index.htm
- #22 SYNTAX - Tipo de dado ASN.1, existem várias opções, como: Básico: INTEGER, OCTET STRING, OBJECT IDENTIFIER e NULL Application-wide: IpAddress, Network Address, Counter, Gauge, Opaque e Timeticks Simply-constructed: list e table ACCESS - Modo de acesso: read-only, read-write, write-only e not-acessible STATUS: mandatory, optional e obsolete DESCRIPTION - Nome textual: nome em caracteres para tornar a identificação do objeto mais legível
- #23 Identificam de maneira única dados a enviar, independente de plataforma. Traduzem cada item de dados em triplas denominadas TLV (Tag, Length, Value): Tag (etiqueta): especifica o tipo do dado Length (comprimento): é o comprimento do dado Value (valor): é o dado propriamente dito Por que usar regras padronizadas? Novas regras de codificação sempre introduzem novos bugs e impedem extensões compatíveis com o que já havia sido padronizado. As aplicações que usam as novas regras tardarão mais a serem desenvolvidas e não terão a mesma gama de ferramentas de desenvolvimento que já existe e estarão mais sujeitas à problemas de codificação. As novas aplicações podem sofrer com diferenças de implementações ainda não amadurecidas por testes. O custo em lançar aplicações que utilizem um conjunto novo de regras de codificação é maior do que o custo em se lançar aplicações que já utilizem regras em uso.
- #24 Um tipo (tag) pode ser representado por 1 ou vários bytes. As classes possíveis para uma tag são: universal – tipos genéricos para uso com vários protocolos. Por exemplo: INTEGER. application – específico para um tipo de aplicação. Por exemplo: IpAdress, que é usada somente no contexto de redes TCP/IP. context-specific – o tipo está contido em outro tipo maior. private – permite que ASN.1 seja usado com tipos proprietários. Para não limitar os números de ramos na árvore, foi criada uma maneira de representar números realmente grandes. Se o número for menor que 127 ele é codificado num único byte. Se for maior, ele é codificado em vários bytes de acordo com a figura acima. Um tipo de dado muito comum em gerenciamento é OBJECT IDENTIFIER. Sua codificação não é óbvia: os primeiros 2 dígitos, x.y, devem ser codificados num único número através da fórmula 40x+y em decimal e depois para hexadecimal. No caso de 1.3 (x=1, y=3) => 43 em decimal resulta em 2B em hexadecimal.
- #25 Exemplos de tipos primitivos: INTEGER, ENUMERATED, OCTET STRING, OBJECT INDENTIFIER, NULL, BOOLEAN, BIT STRING, REAL, counter, gauge, TimeTicks, IpAddress, NetworkAddress, Integer32, Counter32, Gauge32, Counter64, UInteger32, etc. IpAddress (OCTET STRING de tamanho 4) Counter (unsigned 32-bit integer) Gauge (unsigned 32-bit integer) TimeTicks (unsigned 32-bit integer) Opaque (tipos não uados em SNMPv1) Outros: DateAndTime, DisplayString, MacAddress, PhysAddress, TimeInterval, TimeStamp, TruthValue, VariablePointer – todos são textual conventions usados como tipos de dados Exemplos de tipos contruídos (a partir de tipos primitivos): SEQUENCE, SEQUENCE OF, SET, SET OF, CHOICE, etc
- #26 Veja no exemplo, como as regras BER determinam uma única serialização para os conjunto de dados a ser transmitido. Mesmo a troca de dados entre aplicações em plataformas diferentes não corre o risco de ter incoerências na compreensão das informações. Por exemplo: um mainframe e um dispositivo móvel.
- #27 Decodifique: 02 01 11 = 40 04 80 01 01 01 = 04 06 70 75 62 6C 69 63 = 05 00 = Codifique: 1.3.6.1.1.4.134.129 = string – "metrorede" =
- #29 Artigo: Capacity and Performance Management: Best Practices White Paper. Cisco Systems. http://www.cisco.com/en/US/tech/tk869/tk769/tech_white_papers_list.html . Visitado em 11/12/2006. Artigo: Change Management: Best Practices White Paper. Cisco Systems. http://www.cisco.com/en/US/tech/tk869/tk769/tech_white_papers_list.html . Visitado em 11/12/2006. Artigo: Service Level Management: Best Practices White Paper. Cisco Systems. http://www.cisco.com/en/US/tech/tk869/tk769/tech_white_papers_list.html . Visitado em 11/12/2006. Artigo: SNMP White Paper: http://www.snmp.com/snmpv3/v3white.html Artigo: Basking in Glory-SNMPv3. Dan Backman. http://www.networkcomputing.com/915/915f1.html . Visitado em 11/12/2006 Artigo SNMPv3. William Stallings. http://www.comsoc.org/livepubs/surveys/public/4q98issue/stallings.html. Visitado em 11/12/2006.