Embed Size (px)
Citation preview
CENTRO FEDERAL DE EDUCAÇÃO TECNOLÓGICA DO PARANÁ Curso de Pós-Graduação em Engenharia Elétrica e Informática Industrial
DISSERTAÇÃO apresentada ao CEFET-PR para obtenção do título de
MESTRE EM CIÊNCIAS
por
ARMANDO RECH FILHO
ESTUDOS PARA IMPLANTAÇÃO DE UMA GERÊNCIA DE REDE CORPORATIVA UTILIZANDO ARQUITETURA DE PROTOCOLOS
ABERTOS
Banca Examinadora:
Presidente e Orientador Prof. Dr. MANOEL CAMILLO DE OLIVEIRA PENNA CEFET-PR Examinadores: Prof. Dra. LIANE MARGARIDA ROCKENBACH TAROUCO UFRGS Prof. Dr. ROBERT CARLISLE BURNET CEFET-PR Prof. M.Sc. ELIANE LÚCIA BODANESE (Suplente) CEFET-PR
Curitiba, 19 de junho de 1996
ARMANDO RECH FILHO
ESTUDOS PARA IMPLANTAÇÃO DE UMA GERÊNCIA DE REDE CORPORATIVA UTILIZANDO ARQUITETURA DE PROTOCOLOS
ABERTOS
Dissertação apresentada ao Curso de Pós-Graduação em Engenharia Elétrica e Informática Industrial do Centro Federal de Educação Tecnológica do Paraná como requisito parcial para obtenção do título de “Mestre em Ciências” - Área de Concentração: Telemática. Orientador: Prof. Dr. Manoel Camillo de Oliveira Penna
Curitiba 1996
i
CATALOGAÇÃO NA FONTE
Rech Filho, Armando, 1949- Estudos para implantação de uma gerência de rede corporativa utilizando arquitetura de protocolos aber tos / Armando Rech Filho. - Curitiba : CEFET-PR, 1996. 147 p. ; il. ; 30 cm. Dissertação de mestrado ( Curso de Pós-Gradua ção em Informática Industrial ) 1. Gerência de rede. 2. Objeto gerenciado. 3. Agente. 4. Gerente. I. Título.
ii
AGRADECIMENTOS
A Deus pela inspiração de voltar à Escola depois de 20 longos anos da formatura em Engenharia Elétrica, dedicados à convivência com o mundo dos computadores e das tecnologias envolvidas. À Luiza, André, Alexandre e Gisele, por suportarem as intermináveis horas de abandono do convívio do lar e do cumprimento das obrigações de marido e de pai. À Companhia de Informática do Paraná - Celepar pelo programa de incentivo à educação na busca da melhoria da qualidade dos serviços do Estado para o cidadão. Aos amigos que constituem a ainda pequena comunidade de estudiosos e profissionais em Gerência de Rede no Brasil pelo apoio na discussão das idéias e no garimpo das informações.
iii
SUMÁRIO
1 Introdução.............................................................................................................. 1
2 Gerência de Rede de Computadores ..................................................................... 6
2.1 Elementos Gerenciáveis em uma Rede ......................................................... 6
2.2 Gerência de Elementos Heterogêneos .......................................................... 9
2.3 Conceitos de Gerente, Agente e MIB ........................................................... 12
2.4 Áreas Funcionais de Gerência ...................................................................... 15
2.5 A Rede Integrada do Governo do Estado do Paraná .................................... 17
3 Estudo Conceitual das Bases de Informação de Gerência .................................... 21
3.1 MIB CMIS/CMIP ......................................................................................... 26
3.2 Exemplo de Definição de uma MIB CMIS/CMIP ........................................ 31
3.3 MIB SNMP ................................................................................................... 35
3.4 Exemplo de Definição de uma MIB SNMP ................................................. 41
4 Estudo Conceitual dos Protocolos de Gerência .................................................... 45
4.1 Protocolos do Modelo de Referência OSI .................................................... 45
4.2 Protocolos do Ambiente TCP/IP ................................................................... 52
5 Determinação da Arquitetura de Gerência ........................................................... 55
iv
6 Especificação dos Requisitos de Informação ....................................................... 62
6.1 Requisitos de Informação por Área de Gerência .......................................... 64
6.1.1 Gerência de Falhas ............................................................................... 65
6.1.2 Gerência de Configuração .................................................................... 66
6.1.3 Gerência de Desempenho ..................................................................... 68
6.1.4 Gerência de Segurança ......................................................................... 70
6.1.5 Gerência de Contabilização .................................................................. 71
6.2 Modelo de Informação por Elemento de Rede ............................................. 73
7 Implantação do Modelo de Informação ................................................................ 85
7.1 Gerenciamento das Aplicações ..................................................................... 87
7.2 Gerência dos Servidores de Bases de Dados ................................................ 97
7.3 Gerenciamento dos Sistemas de Processamento ........................................... 100
7.4 Gerenciamento dos Roteadores ..................................................................... 109
...............................................................................................................................
7.5 Gerenciamento dos Comutadores de Pacotes ............................................... 112
7.6 Gerenciamento dos Canais de Comunicação ................................................ 114
7.7 Gerenciamento dos Concentradores de Redes Locais .................................. 115
8 Conclusões............................................................................................................. 122
Bibliografia ............................................................................................................... 125
Anexo 1 - Descrição Formal das MIBs Propostas .................................................... 132
v
LISTA DE ABREVIATURAS
ACSE: Association Control Service Element
API: Application Program Interface
ASN.1: Abstract Syntax Notation One
ATM: Asynchronous Transfer Mode
CICS: Costumer Information Control System.
CMIP: Common Management Information Protocol
CMIS: Common Management Information Services
CMISE: Common Management Information Service Element
DN: Distinguished Names
DPI: SNMP Distributed Program Interface
EGP: External Gateway Protocol
eSNMP: Extensible SNMP Interface
FTAM: File Transfer Access and Management
GDMO: Guidelines for the Definitions of Managed Objects
vi
IAB: Internet Activities Board
IANA: Internet Assigned Numbers Authority
ICMP: Internet Message Control Protocol
IEEE: Institute of Electrical and Electronics Engineers
IETF: Internet Engineering Task Force
IP: Internet Protocol
IPC: Inter Process Communication
ISO: International Organization for Standardization
ITU-T: International Telecommunication Union-Telecommunication
MIB: Management Information Base
MIT: Management Information Tree
MTA: Message Transfer Agent
NMF: Network Management Forum
NSAP: Network Service Access Point
OID: Object Identifier
OIW: OSI Implementors Workgroup
vii
OSI: Open Systems Interconnection
PDU: Protocol Data Unit
RDN: Relative Distiguished Names
RM-OSI: Open Systems Interconnection-Reference Model
RMON: Remote Network Monitoring
ROSE: Remote Operations Service Element
SMASE: System Management Application Service Element
SMDS: Switched Multimegabit Data Services
SMF: System Management Functions
SMI: Structure of Management Information
SMUX: SNMP Multiplexing Protocol
SNA: System Network Architecture
SNMP: Simple Network Management Protocol
TCP: Transmission Control Protocol
TMN: Telecommunications Management Network
TP: Transaction Processing
viii
TP4-OSI: Transport Protocol Class 4.
UDP: User Datagram Protocol
ix
LISTA DE ILUSTRAÇÕES
Figura 2.1 Elementos Gerenciáveis em uma Rede de Computadores .................. 7
Figura 2.2 Estrutura de Padrões de Gerência no RM-OSI ................................... 11
Figura 2.3 Estrutura de Padrões de Gerência no Ambiente de Protocolos TCP/IP 11
Figura 2.4 Modelo de Sistema de Gerência .......................................................... 13
Figura 2.5 Áreas Funcionais no Sistema de Gerência de Rede ............................. 17
Figura 2.6 Esquema da Rede Integrada do Governo do Estado do Paraná .......... 19
Figura 3.1 Exemplo de um Elemento de Rede Gerenciável ................................. 22
Figura 3.2 Árvore de Registro de Objetos ............................................................ 23
Figura 3.3 Exemplo de uma MIT ......................................................................... 31
Quadro 3.1 Exemplo de Definição de Objetos para MIB CMIS/CMIP ................. 33
Quadro 3.2 Exemplo de Definição de Objetos para MIB SNMP ........................... 42
Quadro 5.1 Critérios para Determinação da Arquitetura de Gerência .................... 60
Figura 6.1 Abordagem para Especificação dos Requisitos de Informação ........... 63
Quadro 6.1 Modelo de Informação para Aplicações ............................................. 75
Quadro 6.2 Modelo de Informação para Servidores de Bases de Dados .............. 76
Quadro 6.3 Modelo de Informação para Sistemas de Processamento ................... 77
Quadro 6.4 Modelo de Informação para Roteadores ............................................. 79
Quadro 6.5 Modelo de Informação para Comutadores de Pacotes ....................... 81
x
Quadro 6.6 Modelo de Informação para Canais de Comunicação ......................... 83
Quadro 6.7 Modelo de Informação para Concentradores de Redes Locais ............ 84
Figura 7.1 Esquema para Gerenciamento dos Comutadores X.25 ....................... 114
xi
RESUMO
A quantidade e a heterogeneidade de componentes são responsáveis pelo aumento evolutivo da complexidade das redes de computadores corporativas, as quais assumem importância estratégica cada vez maior para o sucesso das organizações na divisão do mercado. Estes fatores impõem a necessidade do gerenciamento completo da rede da corporação em uma arquitetura de protocolos abertos.
A análise das arquiteturas disponíveis, a definição dos protocolos de gerência a serem utilizados e a descrição de um modelo básico de informação para atender aos requisitos de gerência, precedem uma pesquisa no mercado para demonstrar que os elementos atualmente encontrados nas redes corporativas permitem a implantação de um sistema de gerência aberto. Pelo estudo das implementações dos agentes em cada tipo de elemento de rede, constata-se que a viabilidade pressupõe, no entanto, desenvolvimento complementar de agentes gerenciáveis para sistemas de processamento, gerenciadores de bases de dados e aplicações.
O modelo de gerência proposto, desenvolvido com base na Rede Integrada de Comunicação de Dados e Serviços do Governo do Estado do Paraná, pode ser utilizado para rede de computadores corporativa de qualquer tipo de empresa.
PALAVRAS-CHAVE
Gerência de Rede/ MIB/ Objeto Gerenciado/ Agente/ Gerente/ SNMP/ CMIS/ CMIP
xii
ABSTRACT
The quantity and the heterogeneity of the components are responsible for the increasingly complexity of the corporate computer networks, which take on more and more strategical importance for the companies success in the market share. Those issues establish the need of a complete management for the corporate network by using an open protocols architecture.
The analysis of the available architectures, the definition of the management protocols to be used and the description of a basic information model for meeting the management requirements, precede a market investigation in order to prove that the existing elements in the corporate networks, nowadays, make possible the implementation of an open management system. By the study of the agents implementation in the various network elements, the conclusion is that the accomplishment is reached, however, with additional development of managed agents for the processing systems, data base management systems and applications.
The proposed management model, whose development was based on the Data Communications and Services Integrated Network of the Government of the Parana State, can be applied to corporate computers network of any kind of business company.
KEY-WORDS
Network Management/ MIB/ Managed Object/ Agent/ Manager/ SNMP/ CMIS/ CMIP
1
1 INTRODUÇÃO
As estratégias de negócios das corporações são suportadas de maneira cada vez mais intensa pela tecnologia da informação, como forma de alcançar diferencial competitivo para assegurar participação no mercado de acordo com seus objetivos. E uma das características mais marcantes da tecnologia da informação, é o processo de grandes transformações por que passa ao longo dos tempos. Estas transformações ocorrem com uma velocidade cada vez maior, diminuindo drasticamente os espaços de tempo para que uma organização atualize os seus recursos tecnológicos para o tratamento da informação, de forma a disponibilizá-la, no momento adequado, para o tomador de decisão.
Até o final dos anos 70, a tecnologia existente impunha às organizações a utilização de um modelo centralizado, baseado em computadores e sistemas de arquitetura proprietárias. A informação era gerada e acessada com o uso de terminais, sem qualquer inteligência local, interligados aos sistemas centrais através de redes de teleprocessamento. Este modelo tornava a administração dos sistemas uma tarefa não muito difícil, porque, estando toda a inteligência do sistema residindo em um, ou em poucos locais, os problemas que ocorriam na rede de terminais eram facilmente diagnosticados e corrigidos. Por outro lado, sendo as arquiteturas de rede proprietárias de um único fabricante, havia um tratamento homogêneo para os problemas, restringindo o leque de soluções, o que simplificava a gerência da rede.
A década de 80 marcou pelo início de uma profunda transformação na forma da obtenção, do processamento e da disponibilização da informação. Em lugar dos grandes computadores centrais começaram a ser utilizados computadores de menor porte, e de tecnologias diferentes, distribuídos lógica ou geograficamente pela organização. Para cada tipo de aplicação, passa a ser escolhida a tecnologia de hardware, de ambiente operacional e de software que melhor atenda aos requisitos de desempenho e custo. Estes diversos computadores interconectam-se na corporação, para a integração da informação, exigindo um grande número de dispositivos com
2
características e finalidades diversas, constituindo uma rede heterogênea, caracterizada pela agregação das diferentes tecnologias.
A organização da informática através do uso de redes de computadores distribuídos, estruturada a partir de ambientes operacionais heterogêneos, cresce rapidamente nas organizações, resultando no crescimento da complexidade para a gerência do ambiente integrado. A rede de teleprocessamento cede seu lugar à rede de computadores. Em lugar de um, ou de poucos, agora são muitos os locais onde residem equipamentos inteligentes para processamento e armazenamento de informações. Como consequência, os problemas não convergem mais para um ponto único, e sim distribuem-se espacialmente por toda a rede. Em lugar de um ambiente homogêneo, onde os ambientes operacionais e os protocolos utilizados são os mesmos em toda a rede, surgem múltiplos tipos de ambientes operacionais e múltiplos protocolos de rede, cada um com suas características próprias e com uma forma particular de tratar e transportar a informação.
Outro aspecto importante a considerar no contexto da evolução das redes de computadores, é o aumento do número de elementos de diferentes características e tecnologias que surgem para a formação de uma rede. Incluem-se processadores com suas aplicações, moduladores de sinal, elementos de interligação de processadores em rede local e remota, tais como concentradores de cabeamento, comutadores, roteadores, dentre outros. Estes elementos precisam ser gerenciados de forma integrada, para que a rede corporativa possua qualidade de serviço, disponibilidade de acesso, tempo de resposta e custos compatíveis com a capacidade e com as necessidades da organização.
Manter o controle integrado de todos os componentes de uma rede de computadores, através da qual os sistemas de informação são interconectados, é hoje de importância estratégica para o sucesso das organizações. A proposta deste trabalho é definir um modelo de informação e avaliar a possibilidade de implantá-lo, para que a gerência de uma rede corporativa possa ser realizada de forma integrada, com uma abrangência que vai desde a camada física de interconexão dos equipamentos até as aplicações. Pretende-se que o trabalho resultante, que será desenvolvido tendo como base a Rede Integrada de Comunicação de Dados e Serviços do Governo do Estado do
3
Paraná, possa ser utilizado para qualquer rede corporativa, independente do tipo de organização, seja pública ou privada.
Para atingir os objetivos serão apresentados em primeiro plano os conceitos básicos de gerência de rede em sistemas abertos. Estes conceitos são resumidos a partir das normas e da boa literatura disponível sobre o assunto, que inclue [CAR92] [LEI93] [STA93A] [TAN92] e outras obras, referenciadas ao longo do trabalho para utilização na necessidade de aprofundamento. Após a apresentação dos conceitos, desenvolve-se um modelo de informação de gerência e estuda-se as condições de sua implantação em função da realidade do mercado produtor de elementos de rede. É importante salientar que esta dissertação concentra-se nos aspectos técnicos e de instrumental para implantação de uma gerência de rede, não entrando na discussão dos aspectos organizacionais, tema igualmente importante para ser desenvolvido em trabalhos futuros.
O capítulo 2 conceitua gerência de rede, descrevendo os elementos que podem compor uma rede de computadores, mostrando a heterogeneidade existente entre eles e as dificuldades existentes para sua integração. Por esta razão é defendida a necessidade de uma gerência baseada em sistemas abertos, considerando a adoção dos padrões definidos pela ISO-International Organization for Standardization através do Modelo de Referência OSI, RM-OSI-Open Systems Interconnection Reference Model, e pelo IAB-Internet Activities Board para o Ambiente de Protocolos TCP/IP-Transmission Control Protocol/Internet Protocol. Conceitos de gerente, agente e MIB-Management Information Base, comuns às arquiteturas abertas de gerência de rede são apresentados. Após a descrição das áreas funcionais de gerência, sob as quais as informações sobre cada elemento de rede podem ser organizadas, conforme proposto no RM-OSI, é apresentada uma visão conceitual da Rede Integrada de Comunicação de Dados e Serviços do Governo do Estado do Paraná, que será objeto de laboratório para o desenvolvimento do trabalho.
O capítulo 3 é dedicado ao estudo conceitual da MIB, instrumento que representa as estruturas de informação que são trocadas entre agentes e gerentes no sistema de gerência de rede. Analisa-se a metodologia para descrição dos objetos que as compõem e como elas são utilizadas nas arquiteturas CMIS/CMIP-Common
4
Management Information Services/Common Management Information Protocol, definida para o RM-OSI, e SNMP-Simple Network Management Protocol, do Ambiente de Protocolos TCP/IP, incluindo-se as referências às MIBs já padronizadas.
Uma abordagem dos protocolos de gerência de rede em sistemas abertos complementa, no capítulo 4, a apresentação dos conceitos utilizados ao longo do trabalho. São descritos os serviços e protocolos das arquiteturas CMIS/CMIP e SNMP. Com base nos conceitos teóricos apresentados até então e no estudo do mercado produtor dos elementos de rede, o qual é apresentado nos capítulos posteriores, o capítulo 5 estabelece e justifica a escolha dos protocolos da arquitetura SNMP para a gerência da rede corporativa do Governo do Estado do Paraná, em sua primeira etapa de implantação. Esta definição é determinante para o desenvolvimento do trabalho nos capítulos seguintes.
Os capítulos 6 e 7 apresentam as principais contribuições desta dissertação. Com base na vivência prática, obtida na gestão da rede corporativa do Governo do Estado do Paraná, são especificados no capítulo 6 os requisitos de informação para atender às necessidades de uma gerência de rede corporativa. As informações são identificadas sob a ótica das cinco áreas funcionais de gerência do RM-OSI apresentadas no capítulo 2, restringindo-se, no entanto, a aplicação do modelo às áreas de configuração, de falhas e de desempenho, colocando fora do escopo as áreas de segurança e contabilização. Com base nos requisitos é proposto um modelo básico de informação, contendo o projeto de uma MIB mínima que cada elemento de rede deve implementar para atender aos objetivos de uma gerência integrada de rede.
O capítulo 7 estuda as condições para implementação do modelo de informação desejável, na arquitetura SNMP, com base na avaliação de pesquisa realizada junto ao mercado produtor. Mostra-se, para cada tipo de elemento de rede definido para a Rede Integrada, como as MIBs que encontram-se atualmente disponíveis nos equipamentos e sistemas, atendem aos requisitos especificados no modelo. Considerando-se que no estágio atual do mercado nem todas as informações apontadas no modelo básico são implementadas, propõe-se o preenchimento das lacunas
5
através do desenvolvimento de novas MIBs ou da extensão das MIBs atualmente existentes.
O capítulo 8 apresenta as conclusões mostrando a viabilidade da implantação de uma gerência de rede corporativa em sistemas abertos em todas as camadas da rede. Resume a situação encontrada no mercado, comentando aspectos do processo evolutivo que deve caracterizar a implantação de um sistema de gerência.
É importante salientar que não faz parte do escopo deste trabalho o estudo para escolha das plataformas sobre as quais o sistema de gerência deve ser implementado. Este assunto é complexo e deve ser considerado para estudos futuros pois, em se tratando de sistemas abertos, existem diversas alternativas de plataformas de gerência no mercado para implantação em uma rede corporativa. A existência ou não de MIB em um determinado elemento de rede, por sua vez, é fator determinante para viabilizar o seu gerenciamento.
A proposta do modelo de informação a ser gerenciado na rede corporativa, o estudo da viabilidade de sua implantação através das MIBs disponíveis nos produtos do mercado, a proposta de desenvolvimento das complementações necessárias e a demonstração da viabilidade de implementação de um sistema de gerência de rede corporativa utilizando uma arquitetura de protocolos abertos, constituem-se nas principais contribuições da dissertação. Nas Referências Bibliográficas são relacionados os endereços eletrônicos na Internet onde podem ser localizadas as descrições das MIBs analisadas ou citadas ao longo do texto.
6
2 GERÊNCIA DE REDE DE COMPUTADORES
A implementação de uma gerência de rede de computadores provê mecanismos para que uma corporação mantenha sob controle, e de forma integrada, os recursos que compõem a sua infra-estrutura tecnológica para o tratamento da informação. Compreende a administração, operação, monitoração, resolução de problemas, dentre outras atividades necessárias para a manutenção de uma rede com qualidade de serviços adequada aos objetivos dos sistemas de informação. Uma rede deve propiciar os tempos de resposta requeridos para cada aplicação, alta disponibilidade e custos compatíveis com os serviços oferecidos. Considerando a importância vital de uma rede corporativa para suportar os sistemas de informação, as organizações investem altas quantidades de recursos financeiros, humanos e materiais, que precisam ser gerenciados com eficiência.
A atividade de gerência aumenta de complexidade na proporção em que cresce a quantidade de ambientes de processamento que integram a rede, o número de diferentes tecnologias de sistemas operacionais e protocolos de rede e a diversidade de elementos que são necessários para interconectar todos estes ambientes. Acrescente-se que com a rápida evolução da tecnologia de redes, aumenta a frequência com que surgem novos elementos, ou a evolução dos elementos existentes, os quais precisam ser incorporados à rede corporativa, constituindo-se em novos objetos a serem gerenciados.
2.1 ELEMENTOS GERENCIÁVEIS EM UMA REDE
A figura 2.1 mostra esquematicamente a composição de uma rede de computadores corporativa, apontando os principais elementos que podem ser gerenciados. Estes elementos serão nominados e conceituados de forma sintética na sequência, sendo referenciados ao longo do trabalho quando da definição dos objetos a serem gerenciados na rede. Os elementos apresentados compõem um sub-conjunto do universo de tipos de elementos gerenciáveis que podem existir em uma rede
7
corporativa, e foram escolhidos com a finalidade de delimitar o escopo de análise definido para este trabalho. Representam os recursos mais significativos e que serão objeto de tratamento preferencial na implantação do sistema de gerência da Rede Integrada de Comunicação de Dados e Serviços do Governo do Estado do Paraná. Uma vez cumprida a primeira etapa, a inclusão de novos tipos de elementos gerenciáveis deverá seguir a mesma abordagem.
roteador
concentrador RedeLocal
roteador
concentradorRedeLocal
roteador
concentrador RedeLocal
canal
canalcomutador
comutador
comutador
X.25
canalcanal
canal
canal
sistemas de processamento
servidores de bases de dados
aplicações
Figura 2.1 - Elementos Gerenciáveis em uma Rede de Computadores
Aplicação: conjunto de programas que operam em um sistema de processamento, com a finalidade de tratamento da informação, podendo ser classificados em sistemas de uso genérico ou específico. Dentre os genéricos incluem-se correio eletrônico e automação
8
de escritórios, serviço de diretório, servidor WWW, dentre outros. Como sistemas de informação específicos para os processos organizacionais do usuário podem ser exemplificados conta corrente bancária, registros de veículos e motoristas, controle acadêmico, administração de recursos humanos, financeira e de materiais, dentre outros.
Servidor de bases de dados: são aplicações que atendem a uma linha específica de serviços que é o provimento de dados para suporte, concorrentemente, à múltiplos sistemas de informação da organização, onde incluem-se produtos de mercado como Oracle, Sybase, Informix, Adabas ou outros. Possuindo características bem determinadas, comuns a todos os produtos do mercado, e pela importância significativa no contexto, são destacados e tratados como um elemento de rede específico.
Sistema de processamento: componentes de hardware e software necessários ao processamento dos sistemas de informação incluindo, entre outros, processadores, memórias, unidades de armazenamento, unidades de apresentação de informação, sistemas operacionais e protocolos de transporte de rede. Como exemplo podem ser citados microcomputadores com sistema operacional Windows, computadores Risc com sistema operacional Unix ou Windows/NT , computadores de arquitetura proprietária como IBM série 900 com sistema operacional MVS, servidores de rede local como Netware ou Windows/NT. Estes diversos sistemas podem interoperar em uma rede através de protocolos de transporte de rede do tipo TCP ou TP4-OSI Transport Protocol Class 4, por exemplo.
Roteador: equipamento utilizado para interconexão de redes entre si, em ambiente de rede local ou remota, com tratamento de endereços e protocolos da camada de rede, permitindo que pacotes de dados de uma rede sejam endereçados para qualquer outra. Os roteadores normalmente implementam diversos protocolos de camada três a serem roteados, seja em padrões abertos como o X.25 do RM-OSI e o IP do Ambiente de Protocolos TCP/IP, ou proprietários como o IPX das redes Netware, Appletalk da Apple, dentre outros.
Comutador de pacotes: equipamento para estabelecimento de rotas e direcionamento de pacotes de dados em uma rede comutada, trabalhando com pacotes de tamanho variável, como no caso de redes X.25 e Frame-Relay, ou com células de tamanho fixo,
9
como no caso das redes ATM-Asynchronous Transfer Mode ou SMDS-Switched Multimegabit Data Services.
Canal de comunicação: elemento de ligação entre duas redes, ou sistemas de processamento, localizados em ambientes remotos, através de um meio que pode ser constituído de cabo metálico comum de telefonia, fibra ótica, sistema rádio-digital, satélite, ou outros meios. Um canal inclui, além do meio físico, os elementos necessários para a interligação dos equipamentos, como modems ou dispositivos equivalentes.
Concentrador de rede local: meio para interconexão dos sistemas de processamento em um ambiente local. Denominação genérica utilizada neste trabalho para equipamentos do tipo hub ou concentrador de hubs, utilizados para compor fisicamente os barramentos no caso das redes locais do tipo Ethernet, ou os anéis, para as redes do tipo Token-Ring, por exemplo. Considerando que a maioria das redes locais distribuídas pelo Estado são de dimensões pequenas, com até 50 equipamentos e normalmente um servidor, o uso de equipamentos do tipo switch ou bridge para segmentação de barramentos em uma mesma rede é muito pequeno e, por isto, não serão incluídos neste estudo.
2.2 GERÊNCIA DE ELEMENTOS HETEROGÊNEOS
Os elementos dos tipos acima descritos são combinados para a montagem de uma rede de computadores, por onde trafegam dados e informações de uma corporação, ou de um conjunto de corporações, no caso de uma rede global. Cada um destes tipos de elementos de rede, possui uma característica operacional própria, sendo construído com os recursos de tecnologia mais apropriados para o seu perfeito funcionamento, seja software ou hardware. Um elemento do tipo roteador, por exemplo, é funcionalmente bem diferente de um concentrador de barramento e mais diferente ainda de um sistema de processamento. Além disso, dentro de um mesmo tipo, aplicam-se diferentes linguagens e protocolos funcionais, como nos casos de um sistema de processamento, onde um sistema Windows/NT é completamente diferente de um sistema Unix e de um sistema IBM/MVS, por exemplo. Da mesma forma, roteadores
10
podem implementar características funcionais, recursos e protocolos de gerenciamento proprietários que são diferentes de um fabricante para outro.
A rede corporativa precisa ser vista através da totalidade dos seus elementos integrados para que sua eficiência e desempenho sejam maximizados, não sendo efetiva a gerência de partes da rede, desconexas das demais partes. A utilização de protocolos proprietários obriga a existência de estações de gerência específicas para cada elemento de rede e o conhecimento de diversos sistemas de gerência pelo pessoal envolvido. Isto, além de aumentar os custos, não permite integrar as informações de gerência dos diversos elementos.
A solução para possibilitar a gerência integrada dos elementos de diferentes tecnologias e de diferentes fabricantes em uma rede, passa pela utilização de uma arquitetura de gerência de rede em sistemas abertos. Uma arquitetura aberta tem como finalidade a especificação de um conjunto de protocolos padronizados que são implantados em cada um dos elementos da rede. Com isso, um mesmo sistema de gerência pode coletar e tratar informações de maneira uniforme e consistente e executar operações sobre um determinado elemento na rede, não importando o seu tipo ou seu fabricante. Novos elementos podem ser incorporados também a qualquer momento.
Existem atualmente duas arquiteturas para interconexão de redes em sistemas abertos padronizadas, disputando um espaço no mercado para implementação em redes corporativas, analisadas e discutidas em [CAR94]: tanto o Modelo de Referência OSI [ITU-X200] [HEB92] [ROS90] [TAN92], quanto o Ambiente de Protocolos TCP/IP [RFC791] [RFC793] [COM91], possuem em suas definições os respectivos conjuntos de protocolos abertos para implantação de sistemas de gerência de rede, que são apresentados de forma resumida nos capítulos 3 e 4 e comparados no capítulo 5. São respectivamente as arquiteturas de gerência CMIS/CMIP e SNMP, cujos conjuntos de padrões básicos são mostrados nas Figuras 2.2 e 2.3, respectivamente. Como os números das recomendações ITU são costumeiramente mais utilizados no mercado em relação às normas ISO equivalentes, as referências ao longo deste trabalho citarão as recomendações ITU. Na arquitetura SNMP os padrões são documentados nas RFCs-Request For Comments emitidas e controladas pelo IAB.
11
Visão Geral de Gerência de Rede
Funções de Gerência
Protocolos de Operações de Gerência
Modelo de Informação de Gerência
ITU X.700 (ISO 7498-4) / ITU X.701 (ISO 10040) - System Management Overview
ITU X.73n ITU X.74n (ISO 10164-n) - System Management Functions
ITU X710 (ISO 9595) - Common Management Information Service Definition
ITU X711 (ISO 9596) - Common Management Information Protocol Specification
ITU X.720 (ISO 10165-1)Management
Information Model
ITU X.721 (ISO 10165-2) Definition of Management
Information
ITU X.722 (ISO 10165-4)Guidelines for the
Definition of ManagedObjects
Figura 2.2 - Estrutura de Padrões de Gerência no RM-OSI
Protocolos de Operações de Gerência Modelo de Informação de Gerência
RFC 1157 - Simple Network Management Protocol
RFC 1155 - Structure of Management Information
RFC 1215 - A Convention for Definining Traps
RFC 1212 - Concise Management Information Base Definitions
MIBs Padronizadas
RFC 1213 - Management Information Base 2
RFC 1441 - Introduction to SNMPv2
RFC 1905 - Protocol Operations for SNMPv2
RFC 1908 - Coexistence Between SNMP and SNMPv2
RFC 1902 - Structure of Management Information for SNMPv2
RFC 1447 - Party MIB for SNMPv2RFC 1451 - Manager to Manager MIB for SNMPv2RFC 1907 - Management Information Base for SNMPv2
RFC nnnn - Outras MIBs Padrão
Figura 2.3 - Estrutura de Padrões de Gerência no Ambiente de Protocolos TCP/IP
12
2.3 CONCEITOS DE GERENTE, AGENTE E MIB
As duas arquiteturas de gerência de rede em sistemas abertos introduzem os conceitos de gerente e agente [ITU-X700] [RFC1157] [TAN92], os quais trocam informações entre si a respeito dos objetos gerenciados, através dos protocolos específicos de cada arquitetura e de uma estrutura de dados denominada MIB. Esta relação entre gerente, agente e MIB, elementos estes conceituados na sequência, é mostrada esquematicamente na Figura 2.4.
Gerente: processo de aplicação implantado em um sistema de processamento com a finalidade de coletar informações dos agentes espalhados pela rede e tratá-las no seu conjunto para análise e apresentação visando a solução de problemas ou tomadas de decisão. Ao gerente cabe também o envio de operações para serem realizadas pelos agentes sobre os elementos gerenciados. Pode existir um ou mais sistemas que implementam processos gerente em uma rede, operando de forma integrada, consistindo em um sistema de gerência.
Agente: processo de aplicação que é implementado em cada elemento de rede, que tem como finalidade prover uma interface com o elemento a ser gerenciado para coletar as informações relativas ao seu funcionamento no mundo real. Estas informações do mundo real são transformadas em uma estrutura de informação, denominada MIB, que modela o comportamento do elemento de rede do ponto de vista do sistema de gerência. O código de um agente é constituído de pelo menos três funções: um núcleo para implementação e tratamento dos protocolos de gerência, um módulo de interface com o elemento de rede para coleta das informações e um módulo para montagem e disponibilização da estrutura de informação definida para o elemento.
MIB: na comunicação entre um agente e um gerente, as informações são passadas através de uma estrutura de dados conhecida como MIB, descrita em detalhes no capítulo 3, que tem como finalidade descrever os objetos gerenciáveis em uma rede. Esta estrutura de dados através da qual os agentes tornam disponíveis as informações de gerência que serão lidas e/ou modificadas pelo gerente, é uma estrutura conceitual e se constitue na visão que o gerente possui dos objetos gerenciáveis do elemento de rede.
13
GERENTE AGENTE
MIBREQUISIÇÕES
NOTIFICAÇÕES
OBJETOS DO MUNDO REAL
GERENTE AGENTE - MIB
ELEMENTO DE REDESISTEMA DE GERÊNCIA
Figura 2.4 - Modelo de Sistema de Gerência
Na interface entre gerente e agente mostrada na Figura 2.4, são realizadas as operações de gerência, utilizando-se de protocolos estabelecidos na arquitetura. O gerente requisita ao agente a execução de operações, como por exemplo a leitura ou a modificação de atributos da MIB do elemento de rede. O agente, por sua vez, emite notificações para o gerente informando sobre a ocorrência de condições excepcionais no respectivo elemento de rede.
Na interface entre o agente e os objetos do mundo real que compõem o elemento de rede, a estrutura conceitual da MIB pode ser populada de três formas básicas: na primeira forma o agente executa operações de polling sobre o recurso físico gerenciado, com frequência definida, para ler o conteúdo das suas informações e as armazena fisicamente na estrutura da MIB em um determinado meio; a segunda forma é a invocação do agente pelo recurso físico sempre que houver qualquer alteração em seu comportamento para atualização das informações armazenadas na MIB como no caso anterior; na terceira forma não é mantida nenhuma estrutura de dados do elemento de rede, ou seja, a MIB não existe fisicamente, pois o agente efetua a leitura das informações diretamente sobre o recurso no momento em que recebe uma requisição do gerente. A forma de implementação depende de cada tipo de elemento de rede, das suas
14
capacidades, do desempenho esperado para o elemento em sua função principal, do desempenho esperado para o sistema de gerência, e de outros fatores que possam influenciar o desempenho da rede.
Existem casos onde o elemento de rede a ser gerenciado não possui capacidade de processamento e armazenamento suficientes para comportar o código e as camadas de protocolos requeridas para implantação de um agente. Para tornar viável a gerência destes elementos, onde enquadram-se modems, controladores programáveis e outros equipamentos, foi criado o conceito de proxy-agent. Estes agentes são instalados em um equipamento fora do elemento de rede gerenciável, a ele interconectado para coletar as suas informações de modo a enviá-las para o sistema de gerência.
Citando alguns exemplos de interação entre gerente e agente em uma rede:
• o gerente requisita uma operação para ligar ou desligar um equipamento na rede, a qual é interpretada pelo agente, que interage com o respectivo equipamento e fazendo com que este execute os procedimentos físicos para cumprir com a solicitação;
• um agente implantado em um determinado roteador na rede monitora constantemente o tráfego em todas as suas portas de comunicação e quando uma delas excede o limite pré-estabelecido, emite uma notificação para o gerente;
• o gerente envia uma requisição para um sistema de processamento com o objetivo de verificar se uma determinada aplicação está ativa, ocasião em que o agente que monitora constantemente as aplicações informa o seu estado operacional;
15
2.4 ÁREAS FUNCIONAIS DE GERÊNCIA
Um sistema para gerência de uma rede corporativa pode ser organizado nas cinco áreas funcionais abaixo descritas, conforme é recomendado pelo Modelo de Referência OSI [ITU-X700] e abordado em detalhes em [LEI93]. Conforme ilustra esquematicamente a Figura 2.5, as MIBs dos elementos de redes são estruturadas com um conjunto de informações para atender às diversas áreas funcionais, as quais são implementadas através de funções no sistema de gerência.
Gerência de Falhas: é uma das tarefas mais importantes do processo de gerência, permitindo a localização de problemas na rede, que ocorrem por falha em um dos equipamentos ou dispositivos. Em uma visão mais simplista, o sistema de gerência deve no mínimo apontar a falha, porém o ideal é que ele esteja preparado para também isolar a causa e corrigir de maneira automática o problema, de forma definitiva ou por solução de contorno. É o caso, por exemplo, de falha em um canal de comunicação, onde o sistema de gerência pode estabelecer uma nova comunicação entre os dois pontos através de um canal alternativo, sem que precise haver intervenção humana no processo. As informações obtidas através das gerências de configuração e de desempenho devem ser utilizadas de forma pró-ativa para evitar falhas previsíveis.
Gerência de Configuração: as redes de computadores podem atingir milhares de equipamentos e dispositivos dispersos por vários locais físicos diferentes em uma organização, muitos deles envolvidos em mudanças frequentes de localização. Para a gerência da rede é fundamental que sejam conhecidas a localização de cada equipamento ou dispositivo, suas especificações técnicas e configurações, os responsáveis pela manutenção ou correção de problemas, dentre outras informações. O sistema de gerência deve prover meios para uma coleta automática de informações na rede, de forma a manter o inventário sempre atualizado, permitindo não somente o registro, como também a modificação de configuração em dispositivos onde isto seja possível. Deve prover também meios para ativar/desativar elementos de rede, alterar seus parâmetros, dentre outras atividades concernentes.
Gerência de Desempenho: os elementos que compõem uma rede precisam ser monitorados de forma constante com a finalidade de avaliar o seu comportamento e
16
compará-lo com o comportamento esperado em conformidade com suas especificações técnicas. Este procedimento tem como objetivo principal ajustar a operação dos diversos elementos de forma a manter o nível de serviço acordado com os usuários da rede. Tem como objetivo promover ações para antecipar-se a problemas que venham a ocorrer pela degradação crescente dos tempos de resposta, motivado por problemas ou por saturação de capacidade dos equipamentos ou dispositivos na rede. O sistema deve prover o estabelecimento de limiares de comportamento permitidos para cada elemento, de forma que sejam emitidas notificações para motivar uma ação quando estes valores forem atingidos. Outra função importante para a gerência de desempenho é a capacidade do sistema para execução de simulações de carga para medir previamente o grau de comprometimento do nível de serviço em função de uma expansão de uso, como é o caso da implantação de uma nova aplicação ou de uma nova quantidade de equipamentos na rede.
Gerência de Segurança: uma rede de computadores de uma organização somente deve ser acessada por pessoas ou aplicações que possuam a devida autorização. As informações sensíveis para o negócio da corporação devem ser mantidas de forma segura, prevenindo-se contra os acessos indevidos, seja para leitura ou para alteração da informação. Os procedimentos de uma gerência de segurança devem incluir a identificação dos pontos de acesso em uma rede, definição dos procedimentos de segurança e, principalmente, manter estes pontos seguros, informando inclusive as tentativas de ataque para uma ação preventiva. Estão inseridos neste contexto os procedimentos de autenticação dos usuários para acesso aos sistemas de processamento, a implementação de Firewalls, as técnicas de criptografia para o transporte da informação, a geração e manutenção de cópias de segurança dos arquivos dentre outros.
Gerência de Contabilização: registra as informações sobre a utilização dos recursos da rede com o objetivo de quantificá-los para efeito de distribuição de custos, de tarifação, de planejamento de capacidade e planejamento de crescimento da rede, de verificação de má utilização dos recursos, de estabelecimento e verificação de cotas de utilização e outros objetivos.
17
SISTEMA DE GERÊNCIA
FALHAS CONFIGURAÇÃO DESEMPENHO SEGURANÇA CONTABILIZAÇÃO
PROTOCOLOS DE GERÊNCIA
MIB
ELEMENTO GERENCIÁVEL
Figura 2.5 - Áreas Funcionais no Sistema de Gerência de Rede
2.5 A REDE INTEGRADA DO GOVERNO DO ESTADO DO PARANÁ
A complexidade de gerenciamento de uma rede de computadores corporativa, composta por equipamentos heterogêneos, de diversas tecnologias e diversos fabricantes, pode ser compreendida a partir de exemplo prático a ser utilizado como laboratório neste trabalho: a Rede Integrada de Comunicação de Dados e Serviços do Governo do Estado do Paraná.
A Rede Integrada, como pode ser denominada abreviadamente, foi concebida obedecendo aos conceitos de sistemas abertos, e está sendo implantada para prover a integração dos sistemas computacionais de todos os órgãos da administração estadual. Visa disponibilizar informações para modernização dos processos administrativos na busca de uma qualidade crescente na prestação dos serviços à sociedade paranaense.
18
Tendo seus primeiros sistemas de informação sido implantados na década de 60 e os primeiros terminais de acesso remoto instalados no final da década de 70, prevalece até hoje uma grande estrutura de sistemas centralizados. Estes sistemas são baseados nos computadores de grande porte da Companhia de Informática do Paraná-Celepar e acessados por uma rede de aproximadamente três mil terminais de vídeo. O sistema de processamento, IBM-MVS, assim como o sistema gerenciador dos bancos de dados, ADABAS, caracterizam-se pela centralização e pela arquitetura proprietária.
Com o avanço da tecnologia para o tratamento da informação, o Estado optou pela distribuição das atividades de informática, passando a dotar os órgãos da administração estadual de sistemas de processamento inteligentes. Em sua maioria operam em microcomputadores interconectados em redes locais com sistemas operacionais Netware e Windows/NT, incluindo algumas instalações baseadas em sistemas UNIX. Estima-se que até o final de 1996 estejam implantados 250 instalações desta natureza nos diversos órgãos do Estado, abrangendo capital e interior.
A rede de teleprocessamento, então centralizada e apoiada sobre protocolos proprietários e homogêneos, evolue na década de 90 para uma rede de computadores distribuída e com protocolos heterogêneos, para suportar as novas demandas. Atualmente co-existem uma rede de terminais em protocolos proprietários SNA e uma rede de comutação de pacotes em protocolos abertos ITU-X.25, que foi implantada para possibilitar a troca direta de informações entre os vários sistemas computacionais dos órgãos do Estado, independentemente da tecnologia utilizada em cada órgão. A Rede X.25 cobre todo o interior do estado e a capital, transportando os dados das aplicações cliente-servidor em protocolo TCP/IP e os dados das aplicações centralizadas para os terminais através do encapsulamento dos protocolos da rede proprietária SNA. Na capital a maioria das conexões são ponto-a-ponto roteadas na Celepar. Até o final do ano de 1996 será implantada uma rede de alta velocidade na capital, inicialmente na região do Centro Cívico, em tecnologia de comutação de células ATM. A Figura 2.6 tem como objetivo mostrar uma visão esquemática de toda a rede, incluindo já a futura rede ATM, em que pese esta não seja objeto de tratamento neste estudo.
19
Figura 2.6 - Esquema da Rede Integrada do Governo do Estado do Paraná
Uma série de serviços serão prestados pela Rede Integrada, agregando valor à infra-estrutura de interconexão entre os ambientes informatizados do Estado. Os
IBM-MVS ADABAS RISC-AIX
SYBASE
CELEPAR
BASES DE INFORMAÇÃO CORREIO/AUTOMAÇÃO INTERNET X.400 DIRETÓRIO GERÊNCIA DE REDE
Londrina
Cascavel
Maringá
Curitiba
PontaGrossa
X.25
ORGÃOS CAPITAL
ATMWindows/NT
NetwareWindows/NT
Windows/NT
Netware
ORGÃOS INTERIORWindows/NTNetware /
20
serviços já implantados incluem: acesso aos sistemas de informação centralizados na modalidade de terminal; acesso aos sistemas de informação distribuídos na modalidade cliente-servidor; serviço de correio eletrônico e automação de escritório; acesso à informações na Internet; acesso à rede X.400; acesso à informação através de unidades de resposta audível. Estão planejados para um futuro próximo um serviço de diretório para a rede, serviços de gerência da rede, vídeo conferência, dentre outros.
Os detalhes dos elementos que compõem a Rede Integrada são apresentados no capítulo 7, no estudo das MIBs existentes para implantação em cada um dos seus elementos, onde constata-se que a implantação de um sistema de gerência de rede em padrões abertos é mandatório para se conseguir uma gerência integrada. E esta, é maneira de garantir qualidade no acesso aos serviços e às informações disponíveis na rede pois, na medida em que disponibiliza uma visão global de todos os elementos da rede, permite ações preventivas na detecção e maior rapidez na solução dos problemas.
A qualidade no acesso à informação e aos serviços ofertados na rede, contribui para o aumento da produtividade da administração pública e da qualidade do serviço prestado pelo Governo à sociedade. Por esta razão, a gerência integrada da Rede, implementada em arquitetura de protocolos abertos, está colocada no conjunto das altas prioridades no segmento de informática no Governo do Estado.
21
3 ESTUDO CONCEITUAL DAS BASES DE INFORMAÇÃO DE GERÊNCIA
A MIB-Management Information Base é o elemento de ligação entre agentes e gerentes em um sistema de gerência, representando as estruturas de dados através das quais as informações são passadas entre eles. A MIB constitui-se de uma coleção estruturada de objetos, formando a base para as informações de gerência, que precisa estar implementada em cada elemento para que este possa ser gerenciável na rede. É um modelo de interface que define como um objeto do mundo real é representado abstratamente, de forma a se tornar visível para o gerente. A descrição formal de uma MIB é efetuada, tanto no RM-OSI como no Ambiente de Protocolos TCP/IP, utilizando-se a sintaxe abstrata ASN.1-Abstract Syntax Notation One especificada pela norma [ISO8824] e estudada em [HEB92] [STA93] [TAN92].
Em sua definição conceitual [ITU-X700] [RFC1155] [CAR92] [STA93A] a MIB é o conjunto de objetos gerenciados em um sistema aberto. A implementação da MIB é distribuída pelos elementos gerenciados na rede, onde cada elemento disponibiliza através do respectivo agente o modelo de informação que o descreve. Tanto no RM-OSI quanto no Ambiente de Protocolos TCP/IP não é estabelecida a abrangência da MIB, se esta deve ser considerada de uma forma global para o sistema de gerência como um todo e cada elemento implementa uma parte da MIB, ou, se a MIB deve ser considerada para cada elemento de rede e o sistema de gerência implementa um conjunto de MIBs. Nas RFCs que padronizam as MIBs para implementação em sistema de gerência no Ambiente de Protocolos TCP/IP são encontradas referências à MIB por elemento de rede ou mesmo por recurso existente no elemento, como por exemplo MIB de hosts, MIB de aplicações. Este conceito é o adotado ao longo da dissertação.
A Figura 3.1 exemplifica a MIB em um sistema de gerência, utilizando um elemento de rede gerenciável do tipo roteador. O roteador é um equipamento complexo que tem como finalidade receber fluxos de dados em uma porta e destiná-los a outras portas de acordo com uma informação de endereçamento e um algoritmo de roteamento.
22
Possue uma estrutura de processador e memória, instalados em um barramento interno onde também são ligadas as interfaces de acesso às suas portas.
Existem muitas informações que podem ser prestadas por um roteador para o seu gerenciamento em uma rede, porém, por se tratar de um exemplo didático, apenas um pequeno conjunto destas informações foi selecionado para compor a MIB, a qual está descrita em linguagem formal nos Quadros 3.1 e 3.2:
• informações do roteador: a sua marca, o nome que o identifica na rede, o estado operacional do equipamento, a quantidade de portas instaladas e a capacidade de roteamento em pacotes por segundo;
• informações de cada porta instalada: a sua identificação, o tipo de interface, o endereço de rede associado à porta, o estado operacional da porta, a velocidade configurada e o tráfego médio efetivo medido na porta.
SISTEMA DE GERÊNCIA
MIB ROTEADOR
P1
P2
Pn
marca nome estado capac # portas ...
identificação tipo endereço estado velocidade tráfego ...
Figura 3.1 - Exemplo de um Elemento de Rede Gerenciável
As definições dos objetos componentes da MIB são registradas na árvore de registro de nomes de objetos definida pela norma ASN.1 [ISO8824]. Além dos objetos utilizados pelo sistema de gerência, são também registrados nesta árvore outros tipos de objetos para finalidades diversas, como por exemplo normas, recomendações, instituições, dentre outros. A árvore de registro é ilustrada na Figura 3.2.
23
(0) ccitt administrada pela ITU-T (0) recommendation recomendações da ITU-T (1) question grupos de trabalho (2) administration administradoras de sistemas de telecomunicações (3) network-operator operadoras de telecomunicações (4) itu-identified-operator membros do Telecommunication Standardization Bureau (1) iso administrada pela ISO (0) standard padrões internacionais da ISO (1) member-body membros participantes da ISO (3) identified-organization organizações registradas (6) dod Departamento de Defesa USA (1) internet Internet Activites Board (1) directory uso futuro com X.500 (2) mgmt MIBs aprovadas pelo IAB (1) mib-2 objetos da MIB-2 (3) experimental MIBs experimentais (4) privates MIBs de objetos proprietários (1) enterprises empresas registradas (6)snmpv2 especificações para SNMPv2 (1)snmpDomains domínios no SNMPv2 (2)proxies proxies no SNMPv2 (3)modules MIBs IAB para SNMPv2 (2) joint-iso-ccitt administrada em conjunto pela ISO e ITU-T (9) ms família de padrões para sistemas de gerência OSI (0)smo visão geral do sistema de gerência - ISO 10040 (1) cmip protocolos CMIP - ISO 9596 (2) function funções do sistema de gerência - ISO 10164 (3) smi estrutura de informação de gerência - ISO 10165 (2) part2 definição de informação de gerência - ISO 10165/2 (13) network-layer gerência da camada de rede - ISO 10733 (14) transport-layer gerência da camada de transporte - ISO 10737
Figura 3.2 - Árvore de Registro de Objetos
24
Um objeto é registrado na árvore através de um identificador denominado OID-Object Identifier, que é um tipo ASN.1. É formado por uma sequência de identificadores e/ou valores, cada um identificando a posição relativa do objeto em cada ramo da árvore. A leitura é efetuada no sentido da raiz para a folha. Alguns exemplos de nomeação de objetos que aparecem registrados na árvore mostrada na Figura 3.2 são:
• Objeto raíz para classes de objetos padronizadas para gerência CMIS/CMIP em conformidade com as recomendações [ITU-X721], as quais correspondem a parte de número 2 do SMI-Structure of Management Information da norma ISO - 10165/2:
smi2MObjectClass OBJECT IDENTIFIER ::= {joint-iso-ccitt ms smi smi2 3} ou smi2MObjectClass OBJECT IDENTIFIER ::= {2 9 3 2 3}
• Uma das classes de objetos definida no âmbito da recomendação [ITU-X721]:
alarmRecord OBJECT IDENTIFIER ::= {smi2MObjectClass 1} ou alarmRecord OBJECT IDENTIFIER ::= {2 9 3 2 3 1}
• Objeto raíz para registro dos objetos de gerência SNMP [RFC1155]: internet OBJECT IDENTIFIER ::= {iso identified-organization dod 1} ou internet OBJECT IDENTIFIER ::= {1 3 6 1}
• Objeto raíz para registro dos grupos de objetos MIB-2 [RFC1213]: mib-2 OBJECT IDENTIFIER ::= {internet mgmt 1} ou mib-2 OBJECT IDENTIFIER ::= {1 3 6 1 2 1}
• Objeto que identifica e localiza na árvore o grupo da MIB-2 que descreve os objetos gerenciáveis das interfaces de comunicação de elementos de rede [RFC1213]: interfaces OBJECT IDENTIFIER ::= {mib-2 2} ou interfaces OBJECT IDENTIFIER ::= {1 3 6 1 2 1 2}
25
• Objeto que identifica e localiza na árvore as descrições dos objetos gerenciáveis da versão 2 do SNMP [RFC1902]: snmpv2 OBJECT IDENTIFIER ::= {internet 6} ou snmpv2 OBJECT IDENTIFIER ::= {1 3 6 1 6}
Como pode ser percebido nestes exemplos, uma vez que o objeto tenha sido identificado pelo seu nome em uma posição qualquer na árvore, os seus descendentes podem ser identificados pelo conjunto constituído pela sequência de nomes dos ramos a partir do respectivo objeto já nomeado, não havendo necessidade de voltar aos nomes a partir da raíz da árvore. Já na sequência de números é necessária toda a identificação desde a raíz. Na implementação dos protocolos os objetos gerenciáveis são representados nas PDUs-Protocol Data Unit, que transportam as operações de gerência, pela sequência dos números de cada ramo da árvore, separados por pontos. Neste caso por exemplo, o primeiro objeto do grupo interfaces da MIB-2 no SNMP terá a sequência numérica 1.3.6.1.2.1.2.1 como valor do OID.
Na árvore de objetos SNMP identificada por internet existe uma sub-árvore muito utilizada, a private {internet 4}, que é reservada para o registro de MIBs proprietárias de um determinado fabricante, que queira torná-las públicas, de forma a interoperar com sistemas de outros fabricantes. Neste ramo, existe atualmente uma única divisão denominada enterprises {private 1}. Cada empresa interessada identifica-se na IANA- Internet Assigned Numbers Authority e recebe um número para ser usado como objeto raíz das MIBs de todos os seus elementos de rede, garantindo-se com isto unicidade de nomenclatura para seus objetos ao longo de uma MIB global no sistema de gerência. Alguns exemplos destes OIDs: lotus {enterprises 334}, ibm {enterprises 2}, cisco {enterprises 9}. Considerando a necessidade de desenvolvimento de MIBs proprietárias para descrever objetos da Rede Integrada do Estado, conforme abordado no capítulo 7, a Celepar está registrada na IANA sendo identificada no sistema de gerência SNMP como celepar {enterprises 1661}. Assim todos os objetos proprietários da Rede Integrada do Estado terão como prefixo de OID a sequência 1.3.6.1.4.1.1661.
26
Para os sistemas de gerência implementados em conformidade com o RM-OSI, através da arquitetura CMIS/CMIP, são utilizadas as três sub-árvores de registro:
• os objetos definidos e padronizados em conjunto pelas entidades ISO e ITU [ITU-X721], os quais são objetos de suporte para as especificações das MIBs que modelam o comportamento dos elementos de rede, estão registrados na árvore joint-iso-ccitt sob o ramo identificado pelo objeto cujo prefixo é 2.9.3.2;
• os objetos definidos por outras organizações interessadas, sejam estes padronizados ou mesmo proprietários, são registrados na sub-árvore iso no ramo identified-organization, utilizando o prefixo 1.3.X, onde X identifica a organização responsável. Alguns exemplos de organização são o consórcio NMF-Network Management Forum e o OIW-OSI Implementors Workgroup. Os registros de empresas que pretendem definir MIBs proprietárias devem ser efetuados junto de acordo com a norma ISO6523. Como a curto prazo não serão desenvolvidas MIBs CMIS/CMIP proprietárias para implantação na Rede Integrada do Estado, o registro da oganização Celepar nesta árvore não foi inserida no contexto deste trabalho;
• os objetos definidos pela ITU-T para o sistema de gerência na arquitetura TMN-Telecommunication Management Network são registrados na sub-árvore ccitt sob o ramo recommendation.
3.1 MIB CMIS/CMIP
A estruturação das informações de gerência para representação da MIB no Modelo de Referência OSI implementa de forma intensiva os conceitos de orientação a objetos. Cada tipo de elemento de rede a ser gerenciado é representado de forma abstrata como uma classe de objetos, e cada recurso de um determinado tipo existente num dado momento na rede, é uma instância da respectiva classe. Todos os dados e operações de gerência aplicáveis ao recurso são encapsulados no objeto correspondente.
27
O acesso ao recurso para efeito de gerenciamento é efetuado através do objeto, ocorrendo por meio de mensagens transmitidas utilizando as PDUs do protocolo CMIP.
O modelo de informação de gerência [ITU-X720] [STA93A] define como as classes de objetos são especificadas de forma a representar os recursos dos elementos de rede a serem gerenciados e como eles se relacionam hierarquicamente entre si no sistema de gerência. Os componentes utilizados para a especificação de uma classe de objetos são:
Atributos: descreve os atributos do objeto visíveis em sua interface, que são os dados característicos do elemento de rede disponíveis para o sistema. Os atributos possuem um tipo e um valor, podendo ser de um tipo simples, por exemplo inteiro, real, boleano, string de caracteres, ou de um tipo composto a partir de tipos simples como definido na norma ASN.1. Os atributos podem ser organizados em grupos de forma que uma referência ao grupo abranja todos os atributos do mesmo.
Operações: define as operações de gerência CMIS, que são apresentadas no capítulo 4, que podem ser executadas sobre os objetos da classe.
Comportamento: descreve as reações exibidas pelos objetos diante de cada operação CMIS executada sobre o objeto. É uma informação com finalidade de documentação usada para se conhecer a semântica de atributos, operações e notificações, as respostas para as operações de gerência, as circunstâncias sob as quais as notificações são emitidas, dentre outros.
Notificações: especifica as notificações que podem ser emitidas pelos agentes utilizando-se a operação Event-Report do CMIS, quando ocorrerem situações que afetam o objeto gerenciado. As notificações podem ser enviadas do agente para o gerente ou então para um log diretamente, conforme a situação.
Pacotes: um conjunto de atributos, operações, comportamentos e notificações que são utilizados de forma comum em diversas classes, podem ser definidos e registrados separadamente como pacotes. Na construção de uma classe de objetos, quando um
28
destes conjuntos for identificado como mandatório, ele pode ser incluído através da simples especificação do nome do pacote.
Pacotes Condicionais: constitui-se de um conjunto de atributos, operações, notificações e comportamentos, definidos e registrados separadamente, que são opcionais para uma classe, onde a presença ou não no objeto gerenciado depende da ocorrência de condições previstas.
Hierarquia de Herança: relaciona duas classes de objeto, a primeira identificada como superior, da qual a segunda herda a totalidade das suas definições. Esta facilidade permite a construção de classes básicas para serem re-utilizadas na definição de novas classes por um processo de especialização. Uma nova classe pode ser construída a partir de várias outras, no conceito de herança múltipla.
Alomorfismo: permite utilizar um objeto de uma classe como se ele fosse membro de uma outra classe. O objeto deve ter um comportamento compatível com o comportamento definido para a sua classe alomórfica. Este conceito pode ser usado por exemplo nos casos de evolução de uma MIB, onde o sistema de gerência pode operar com uma nova versão da MIB como se esta fosse ainda a antiga, até que o mesmo esteja preparado para operar efetivamente sobre a nova MIB.
Uma classe de objetos é definida através de um conjunto de templates,
seguindo os modelos padronizados em [ITU-X722] e estudados em [HEB92] [TAN92], que formam a GDMO-Guidelines for the Definition of Managed Objects. Atualmente existem os seguintes templates padronizados: Managed Object Class (3), Package (4), Parameter (5), Name Binding (6), Attribute (7), Attribute Group (8), Action (9) e Notification (10). Os números entre parênteses identificam os ramos da árvore {joint-iso-ccitt ms smi part2} onde as definições dos elementos padronizados obtidos a partir do uso destes templates [ITU-X721] são registradas, como por exemplo:
smi2NameBinding OBJECT IDENTIFIER ::= {joint-iso-ccitt ms smi smi2 6} logRecord-log OBJECT IDENTIFIER ::= {smi2NameBinding 3}
29
smi2Package OBJECT IDENTIFIER ::= {joint-iso-ccitt ms smi smi2 4} dailyScheduling OBJECT IDENTIFIER ::= {smi2Package 25}
A recomendação [ITU-X721] define uma série de classes e outros elementos, padronizados em conjunto pela ISO e ITU-T, para uso genérico em sistemas de gerência. Estas definições têm como finalidade servir de suporte para o desenvolvimento de novas classes através do processo de herança, até chegar ao nível de especialização suficiente para implementação nos elementos de rede. Diferentemente do que ocorre na gerência SNMP, analisada adiante, não existem na arquitetura CMIS/CMIP definições padronizadas de objetos gerenciados para utilização direta pelos elementos que compõem uma rede corporativa.
As instituições interessadas em certos segmentos de mercado é que se preocupam na definição de classes padronizadas mais próximas ao nível de implementação. Um exemplo é o das especificações das classes de objetos para utilização pelos elementos de rede na arquitetura TMN, as quais foram desenvolvidas pela ITU-T para o gerenciamento específico de redes de telecomunicações. Estas classes fazem parte das recomendações [ITU-M3100], registradas na sub-árvore identificada como m3100ObjectClass {ccitt recommendation m gnm informationModel 3}, as quais possuem um grau de especialização já bastante próximo aos níveis de implementação dos equipamentos de rede. Dentre elas podem ser citadas como exemplo as classes equipment {m3100ObjectClass 32} e circuitSubgroup {m3100ObjectClass 23}.
Em um sistema de gerência CMIS/CMIP os objetos de uma determinada classe são instanciados suportando todos os atributos, operações, comportamentos e notificações mandatórios e, dependendo da situação, também os condicionais, em conformidade com as especificações da respectiva classe. A instanciação dos objetos em um agente obedece uma estrutura hierárquica no sistema seguindo uma outra árvore, denominada MIT-Management Information Tree, ou Árvore de Nomeação de Gerência, a qual reflete a estrutura de nomes dos objetos na MIB. Para cada nível da MIT são definidas as classes de objetos gerenciáveis e os atributos que distinguem as diversas instâncias dos objetos dentro da classe, os quais são denominados RDN-Relative
30
Distiguished Name. Os nomes pelos quais os objetos serão encontrados univocamente dentro da árvore de nomeação são denominados DN-Distiguished Name. Os DNs são formados pelo encadeamento dos RDNs de cada nível da árvore de nomeação, desde a raíz até o nível em que se encontra o objeto.
A Figura 3.3 ilustra como poderia ser nomeada a parte da MIT referente a um roteador como o da Figura 3.1 instalado em uma rede. Neste exemplo, além da classe rede que é o primeiro nível da MIT, existem duas classes de objetos para os equipamentos: a classe denominada roteador que descreve o equipamento como um todo, e classe denominada porta que descreve o comportamento das portas de comunicação do roteador. Estas duas classes são definidas no Quadro 3.1, no item 3.2.
A montagem da MIT é realizada a partir da definição de uma relação existente entre instâncias de objetos gerenciados, que pode ocorrer entre objetos de uma mesma classe ou de classes diferentes, seguindo uma especificação denominada name binding. O atributo denominado nameBinding, que contém o nome da relação definida através de um template GDMO, é definido na classe top, sendo portanto mandatório para todas as classes de objetos. Este atributo é utilizado pela operação create quando da instanciação do objeto, para estabelecer uma ligação na árvore de nomeação, ligação esta que é desfeita pela operação delete, que retira uma instância do objeto da árvore. A árvore de objetos instanciados em uma MIB é portanto dinâmica.
Como pode ser constatado, na arquitetura CMIS/CMIP existem três árvores distintas e independentes:
• árvore de registro para definições de elementos padronizados que são utilizados na definição das classes de objetos;
• árvore de hierarquia de herança para mostrar como as definições de classes de objetos são derivadas de outras classes;
31
• árvore de nomeação dos objetos que reflete a estrutura da MIB, referenciando de forma não ambígua os objetos contidos em um agente.
classe = routernome = rt1
classe = porta ident = p1
classe = porta ident = p2
classe = porta ident = pn
classe = rede idRede = r1
OBJETOS RDN DN
rede r1 {r1}roteador rt1 {r1, rt1}porta 1 p1 {r1, rt1, p1}porta 2 p2 {r1, rt1, p2}porta 3 pn {r1, rt1, pn}
Figura 3.3 - Exemplo de uma MIT
3.2 EXEMPLO DE DEFINIÇÃO DE UMA MIB CMIS/CMIP
Um exemplo de definição de uma MIB CMIS/CMIP é apresentado no Quadro 3.1, mostrando a utilização dos templates GDMO para a construção das classes de objetos e das ligações entre as classes presentes em um elemento de rede. O exemplo utiliza a descrição didática simplificada do roteador mostrado na Figura 3.1. Os componentes da descrição das classes de objetos poderiam ter sido definidos no próprio corpo da definição das classes, mas foram definidos separadamente para mostrar o uso de objetos registrados. O atributos nameBinding e objectClass não aparecem na
32
descrição das classes porque são atributos da classe top, sendo herdados, portanto, por todas as classes de objetos gerenciáveis. A hierarquia de classes utilizada neste exemplo é a seguinte:
top {smi2ObjectClass 14} -- classe genérica para todos objetos gerenciáveis definida na recomendação [ITU-X721] elementoRede {classe 1} -- classe genérica que descreve os elementos de rede da organização, herdando as definições da classe top router {classe 2} -- especialização da classe elementoRede para descrever equipamentos do tipo roteador porta {classe 3} -- classe utilizada para descrever portas para os vários tipos de equipamentos de comunicação, herdando as definições da classe top
Os registros das definições dos elementos na árvore da ISO é especificado partindo dos registros prévios dos seguintes OIDs:
empresa OBJECT IDENTIFIER ::= {iso identified-organization # } classe OBJECT IDENTIFIER::= {empresa 3} pacote OBJECT IDENTIFIER::= {empresa 4} ligação OBJECT IDENTIFIER::= {empresa 6} atributo OBJECT IDENTIFIER::= {empresa 7} notificação OBJECT IDENTIFIER::= {empresa 10}
33
Quadro 3.1 - Exemplo de Definição de Objetos para MIB CMIS/CMIP RouterMib DEFINITIONS ::= BEGIN IMPORTS ... EXPORTS ... elementoRede MANAGED OBJECT CLASS DERIVED FROM top; CHARACTERIZED BY descrElem; REGISTERED AS {classe 1}; descrElem PACKAGE BEHAVIOUR descrição BEHAVIOUR DEFINED AS “este pacote destina-se a descrever as informações comuns a todos os elementos de rede”; ATTRIBUTES marca GET, nome GET-SET, estado GET-SET; NOTIFICATION mudançaEstado; REGISTERED AS {pacote 1}; router MANAGED OBJECT CLASS DERIVED FROM elementoRede; CHARACTERIZED BY descrRouter; REGISTERED AS {classe 2}; descrRouter PACKAGE BEHAVIOUR descrição BEHAVIOUR DEFINED AS “este pacote destina-se a descrever as características específicas dos elementos de rede do tipo roteador”; ATTRIBUTES numPortas GET, capacidadePPS GET; REGISTERED AS {pacote 2}; porta MANAGED OBJECT CLASS DERIVED FROM top; CHARACTERIZED BY portaBásica; CONDITIONAL PACKAGE portaLocal PRESENT IF “ a porta destina-se a interconexão em uma rede local”; REGISTERED AS {classe 3};
34
Quadro 3.1 - (cont.) portaBásica PACKAGE BEHAVIOUR comportamentoPorta BEHAVIOUR DEFINED AS “descrição dos atributos comuns a uma porta em qualquer elemento de rede. O agente deve informar quando mudar seu estado operacional ou o percentual de tráfego exceder a 60% da velocidade nominal”; ATTRIBUTES ident GET, tipoPorta GET, endereçoRede GET-SET, estado GET-SET, velocidade GET-SET, tráfegoMédio GET; NOTIFICATION mudançaEstado, altoTráfego; REGISTERED AS {pacote 3}; portaLocal PACKAGE ATTRIBUTES macAddress GET; REGISTERED AS {pacote 4}; mudançaEstado NOTIFICATION MODE NON-CONFIRMED; WITH INFORMATION SYNTAX BOOLEAN {(0) inativa, (1) ativa}; REGISTERED AS {notificação 1}; altoTráfego NOTIFICATION MODE NON-CONFIRMED; WITH INFORMATION SYNTAX INTEGER; REGISTERED AS {notificação 2}; marca ATTRIBUTE WITH ATTRIBUTE SYNTAX OCTET STRING; REGISTERED AS {atributo 1}; nome ATTRIBUTE WITH ATTRIBUTE SYNTAX OCTET STRING; REGISTERED AS {atributo 2}; numPortas ATTRIBUTE WITH ATTRIBUTE SYNTAX INTEGER; REGISTERED AS {atributo 3}; capacidadePPS ATTRIBUTE WITH ATTRIBUTE SYNTAX INTEGER; REGISTERED AS {atributo 4}; ident ATTRIBUTE WITH ATTRIBUTE SYNTAX INTEGER; REGISTERED AS {atributo 5};
35
Quadro 3.1 - (Cont.) TipoPorta ATTRIBUTE WITH ATTRIBUTE SYNTAX INTEGER; REGISTERED AS {atributo 6}; endereçoRede ATTRIBUTE WITH ATTRIBUTE SYNTAX OCTET STRING; REGISTERED AS {atributo 7}; estado ATTRIBUTE WITH ATTRIBUTE SYNTAX BOOLEAN; REGISTERED AS {atributo 8}; velocidade ATTRIBUTE WITH ATTRIBUTE SYNTAX INTEGER; REGISTERED AS {atributo 9}; tráfegoMédio ATTRIBUTE WITH ATTRIBUTE SYNTAX INTEGER; REGISTERED AS {atributo 10}; macAddress ATTRIBUTE WITH ATTRIBUTE SYNTAX OCTET STRING; REGISTERED AS {atributo 11}; roteador-portas NAME BINDING SUBORDINATE OBJECT CLASS porta; NAMED BY SUPERIOR OBJECT CLASS roteador; WHIT ATTRIBUTE identificação; REGISTERED AS {ligação 1}; END
3.3 MIB SNMP
No Ambiente de Protocolos TCP/IP o modelo de informação de gerência é mais simples que no Modelo de Referência OSI. A construção das MIBs obedece as especificações contidas nos documentos denominados SMI que foram padronizados em [RFC1155] e [RFC1212] para a versão 1 do SNMP e, mais recentemente, em
36
[RFC1902] para o SNMPv2. Estas especificações impõem um alto grau de simplicidade na descrição das MIBs para tornar o processo de gerência de fácil implementação.
Nesta arquitetura não se aplicam todos os conceitos de orientação a objetos encontrado no RM-OSI. A unidade básica de acesso em uma MIB SNMP é representada por um atributo simples, que é denominado objeto, definido por um tipo e pelas operações que podem ser realizadas sobre ele. No RM-OSI, visto anteriormente, a unidade básica de acesso é uma classe de objeto, definida por um conjunto de atributos e de operações, razão pela qual, para efeito de comparação, pode se dizer que um objeto SNMP possui o mesmo significado de um atributo de uma classe de objetos CMIS/CMIP.
Embora não exista a definição de classes, os objetos das MIBs SNMP são organizados em grupos que representam uma determinada funcionalidade de um elemento de rede, podendo em cada grupo existir tabelas de objetos limitadas no máximo a duas dimensões. Estes grupos, também para efeito de comparação, possuem significado semelhante ao de uma classe de objetos do RM-OSI. Não se aplicam também os conceitos de herança embora o re-uso de definições de objetos previamente realizadas seja possível a partir de exportação e importação entre módulos existentes nas normas ASN.1.
A definição de objetos gerenciáveis para composição das MIBs SNMP utiliza a linguagem ASN.1 através da macro denominada OBJECT-TYPE especificada em [RFC1155] [RFC1212] para a versão 1 e modificada em [RFC1902] para o SNMPv2. São os seguintes os componentes da estrutura da macro OBJECT-TYPE:
Sintaxe: sintaxe abstrata que define o tipo do objeto. Justificado na filosofia da simplicidade de implementação, é utilizado apenas o sub-conjunto dos tipos padrão da norma ASN.1 constituído de: integer, octet string, object identifier, null e sequence. São definidos na SMI tipos específicos para a aplicação de gerência SNMP que são: ipaddress, endereço de rede, counter, inteiro que vai até um máximo e volta a zero, gauge, inteiro que pode aumentar e diminuir porém não aumenta além de um valor máximo, timeticks, que conta o tempo em centésimos de segundos a partir de uma
37
referência inicial especificada, e opaque, que representa um tipo arbitrário qualquer. No SNMPv2 acrescenta o tipo ASN.1 bit string, um novo tipo para endereçamento NSAP-Network Service Access Point, além de novos tipos gauge e counter com 64 bits.
Acesso: define a maneira como uma instância do objeto pode ser acessada através do SNMP, existindo como opções: somente leitura, somente gravação, leitura/gravação e não acessível, onde o objeto não pode ser lido nem gravado, como é o caso das tabelas de objetos, por exemplo. No SNMPv2 o tipo de acesso somente gravação foi eliminado, acrescentando-se um novo tipo para leitura e criação, este associado com criação e eliminação de linhas em tabelas .
Status: determina se um objeto é mandatório ou opcional na implementação de um agente. Existem outras duas situações de status, uma delas denominada deprecated, que indica que o objeto será removido da MIB na próxima versão e outra denominada obsolete que indica que os agentes já não precisam mais implementar este objeto, permanecendo na MIB apenas para utilização dos objetos já existentes. Na versão 2 os status opcional e mandatório foram substituídos por um único status denominado corrente.
Descrição: definição da semântica do objeto, contendo as informações necessárias para a compreensão do objeto descrito, possuindo apenas valor documentacional.
Referência: elemento opcional que contém uma informação para estabelecer uma relação entre o objeto em pauta e um outro objeto qualquer definido em outra MIB, também com valor documentacional.
Índice: nos casos das tabelas bidimensionais de objetos, onde cada linha representa uma instância do recurso gerenciado, o índice identifica a linha e consequentemente a instância do objeto correspondente àquele recurso.
Valor Default: elemento opcional que define valores iniciais para uma instância de objeto quando valores específicos não forem informados quando da instanciação.
38
Identificação de Objeto: nome pelo qual o objeto será registrado na árvore de registro da ISO e pelo qual será identificado e acessado pelo sistema de gerência.
A árvore de instanciação dos objetos gerenciáveis SNMP em um agente na
rede segue a própria árvore de registro de objetos. Quando o objeto é um simples atributo, a instância é identificada pelo valor zero acrescido ao OID. Quando um objeto pertence a uma entrada de uma tabela, a diferenciação entre instâncias do mesmo objeto ocorre através do valor do índice definido na descrição da tabela, o qual é acrescido ao OID do objeto. A árvore de objetos instanciados em uma MIB no ambiente TCP/IP é portanto estática e determinada quando da definição da respectiva MIB. Na versão 1 do SNMP a instanciação de uma linha de tabela somente pode ser efetuada pelo agente, o que foi modificado no SNMPv2 para permitir que o gerente possa criar e eliminar linhas em uma tabela no agente.
O acesso somente é permitido para objetos que sejam folha na árvore da MIB. Isto significa dizer que nenhum objeto representado por uma tabela pode ser acessado pela referência à tabela ou a uma das suas entradas, mas apenas através de cada um dos seus componentes individualmente. O mesmo ocorre com o acesso aos grupos de objetos. Para minimizar os problemas causados pelo overhead de tráfego excessivo ocasionado pelo acesso individual a cada objeto folha em uma MIB, o SNMP permite que múltiplos objetos possam ser relacionados em uma operação, de forma a serem transportados em uma mesma PDU, porém limitando-se o escopo a uma única linha no caso de uma tabela. No SNMPv2, como citado no capítulo seguinte, a implementação da operação get-bulk permite recuperar em uma única operação diversas linhas de uma tabela, melhorando a eficiência do sistema.
Na arquitetura SNMP, diferentemente do enfoque adotado na arquitetura CMIS/CMIP, é definida em [RFC 1213] uma MIB básica padrão para gerência a qual foi denominada MIB-2. Esta MIB é composta por objetos que representam abstratamente um conjunto de funcionalidades que são encontradas nos diversos elementos de rede, possuindo portanto característica de uso geral e de aplicação direta. São os seguintes os grupos definidos para a MIB-2 básica, que encontram-se detalhados em [STA93A] e [ROS95]:
39
system {mib-2 1} - informações gerais sobre o sistema gerenciado no qual o agente está implementado;
interfaces {mib-2 2} - informações genéricas sobre as interfaces físicas do sistema com a rede ou sub-rede na qual está conectado, incluindo informações e estatísticas sobre os eventos que ocorrem em cada interface;
adrressTranslation {mib-2 3} - tabelas de tradução de endereços que permitem mapear de forma uni-direcional os endereços de rede IP para endereços internos da sub-rede, como por exemplo para endereços MAC em redes locais. Seu status é deprecated pois estas informações devem passar para o respectivo grupo de cada protocolo de rede, pela necessidade de mapeamento bi-direcional e na relação de um para vários;
ip {mib-2 4} - informações relevantes para a operação dos protocolos IP nos elementos de rede, incluindo os endereços IP para cada interface física, as tabelas de roteamento além de outras informações para avaliação de desempenho e de falhas;
icmp {mib-2 5} - diversos contadores para disponibilização de informações sobre os vários tipos de mensagens enviadas e recebidas pelo ICMP-Internet Control Management Protocol;
tcp {mib-2 6} - informações a respeito das conexões de transporte ativas mantidas pelo protocolo TCP em um elemento de rede, incluindo tabela com os endereços de rede e número das portas locais e remotas para cada conexão, com seus respectivos status, além de uma série de estatísticas e informações a respeito da operação do protocolo;
udp {mib-2 7} - informações a respeito de datagramas enviados e recebidos através do protocolo de transporte UDP, incluindo uma tabela que indica os endereços IP e as portas locais para o elemento de rede;
egp {mib-2 8} - informações sobre a operação de um EGP-External Gateway Protocol em um elemento de rede, incluindo além das informações sobre mensagens recebidas e enviadas, uma tabela identificando cada um dos gateways vizinhos por ele conhecidos;
transmission {mib-2 10} - criado como raíz para novos grupos de objetos que devem ser definidos para modelar informações sobre os meios de transmissão para cada tipo de interface de um elemento de rede. A RFC 1213 não possui nenhum objeto implantado neste grupo, os quais devem ser especificados em RFCs próprias para cada tipo de interface.
40
snmp {mib-2 11} - informações quantitativas sobre as mensagens trocadas entre gerente e agente em um sistema de gerência de rede implementado no Ambiente de Protocolos TCP/IP.
Por ser uma MIB básica definida com um conjunto limitado de objetos, a
MIB-2 original [RFC1213] tem sido extendida com novos grupos de objetos através de RFCs específicas, como é o caso da MIB RMON-Remote Network Monitoring [RFC1757], identificada por rmon {mib-2 16}, para o gerenciamento remoto de tráfego em sub-redes sem a necessidade da existência de um agente SNMP em cada estação da sub-rede. A tabela ipForwardingTable [RFC1354] complementa o grupo ip {ip 24}. Vários grupos de objetos para interfaces específicas são alocados sob o grupo transmission, com uma RFC para cada tipo, como é o caso das interfaces Ethernet [RFC1398] identificada por dot3 {transmission 7}, X.25-LAPB [RFC1381] identificado por lapb {transmission 16}, dentre outras. A [RFC1573] é um outro exemplo de MIB identificada na árvore por ifMIB {mib-2 31}, que tem como objetivo definir uma nova estrutura para susbtituir o grupo interfaces da MIB-2, acrescentando novas tabelas de objetos.
A MIB-2 original e suas extensões, definidas para a versão 1 do SNMP, podem ser empregadas de forma transparente por um gerente que implemente SNMPv2, pois este pode gerenciar concorrentemente agentes que implementem MIBs em ambas as versões, conforme regras estabelecidas em [RFC1908]. Três MIBs foram definidas especificamente para a estruturação do SNMPv2, as quais estão alocadas na árvore de objetos sob o identificador snmpModules { internet snmpv2 (6) 1}:
snmpMIB {snmpModules 1} - a MIB do SNMPv2 foi especificada em [RFC1907] e redefine os grupos system {mib-2 1} e snmp {mib-2 11}, adaptando-os para as facilidades da versão 2, assim como redefine também os traps padrão. Implementa um objeto para coordenação dos comandos set requeridos ao mesmo tempo por vários gerentes sobre um mesmo objeto e, ainda, define os grupos de objetos que devem estar presentes nos agentes para verificação de conformidade com os padrões.
snmpM2M {snmpModules 2} - denominada Manager-to-Manager, esta MIB [RFC1451] tem como objetivo modelar a troca de informações entre dois gerentes
41
SNMPv2 em um mesmo sistema, quando da implementação de gerência distribuída. É composta por dois grupos: alarme, especificando os objetos a serem monitorados e seus valores limite, e eventos, descrevendo os eventos associados aos alarmes.
partyMIB {snmpModules 3}: definida em [RFC1447], a MIB denominada Party modela os objetos concernentes aos aspectos de administração e segurança, sendo composta por três grupos: identificação e autenticação dos parceiros no sistema, definição dos contextos do sistema onde os parceiros estão inseridos e definição de acessos e privilégios para os parceiros sobre os objetos gerenciados.
3.4 EXEMPLO DE DEFINIÇÃO DE UMA MIB SNMP
O mesmo elemento de rede, do tipo roteador, utilizado para exemplificar no Quadro 3.1 a definição das classes de objeto para comporem a MIB CMIS/CMIP, é agora utilizado para mostrar através do Quadro 3.2, na página seguinte, a aplicação das macros OBJECT-TYPE e TRAP-TYPE na definição de uma MIB proprietária SNMP.
A comparação entre as arquiteturas de gerência CMIS/CMIP e SNMP é realizada no capítulo 5 com o objetivo de definir os protocolos a serem utilizados para gerência de uma rede corporativa.
42
Quadro 3.2 - Exemplo de Definição de Objetos para MIB SNMP Mib-Router DEFINITIONS ::= BEGIN IMPORTS ... EXPORTS ... router OBJECT IDENTIFIER ::= {enterprises empresa 1} marca OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION “Marca e modelo e fabricante do roteador” ::= {router 1} nome OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-write STATUS mandatory DESCRIPTION “Nome atribuído para o equipamento na rede” ::= {router 2} numPortas OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION “Número de portas presentes” ::= {router 3} estado OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION “Estado operacional do roteador” ::= {router 4} capacidadePPS OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION “Capacidade de roteamento em pacotes por segundo” ::= {router 5} portaTable OBJECT-TYPE SYNTAX SEQUENCE OF DescriçãoPorta ACCESS not-accessibile STATUS mandatory DESCRIPTION “Tabela onde cada linha descreve uma porta do roteador” ::= {router 6}
43
Quadro 3.2 - (Cont.) portaEntry OBJECT-TYPE SYNTAX DescriçãoPorta ACCESS not-accessible STATUS mandatory DESCRIPTION “Informações a respeito de cada porta do roteador” INDEX identificação ::= {portaTable 1} DescriçãoPorta ::= SEQUENCE { identificação INTEGER, tipo BOOLEAN, endereçoRede OCTET STRING, estadoOperacional BOOLEAN, velocidade INTEGER, tráfegoMédio INTEGER macAddress OCTET STRING} ident OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION “Número da porta do roteador” ::= {portaEntry 1} tipo OBJECT-TYPE SYNTAX INTEIRO ACCESS read-only STATUS mandatory DESCRIPTION “Identifica o tipo de interface da porta” ::= {portaEntry 2} endereçoRede OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-write STATUS mandatory DESCRIPTION “Endereço de rede associado à porta” ::= {portaEntry 3} estadoOperacional OBJECT-TYPE SYNTAX BOOLEAN ACCESS read-write STATUS mandatory DESCRIPTION “Porta ativa ou inativa” ::= {portaEntry 4} velocidade OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION “Velocidade em Kbps para a qual a porta foi configurada” ::= {portaEntry 5}
44
Quadro 3.2 - (Cont.) tráfegoMédio OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION “Tráfego médio em Kbps calculado a cada 10 minutos” ::= {portaEntry 6} macAddress OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-write STATUS optional DESCRIPTION “Endereço MAC da porta em caso de porta para rede local” ::= {portaEntry 7} excessoTrafego TRAP-TYPE ENTERPRISE empresa VARIABLES {local, identificação, velocidade, trafegoMedio} DESCRIPTION “Informa que a capacidade de tráfego na porta especificada é superior a 60% da capacidade nominal” ::= 1 END
45
4 ESTUDO CONCEITUAL DOS PROTOCOLOS DE GERÊNCIA
Nas arquiteturas de gerência de rede em sistemas abertos, os protocolos de gerência definem estruturas de mensagens padronizadas para a comunicação entre os gerentes e os agentes. Define também as operações que os gerentes podem executar sobre os agentes instalados na rede e as notificações que os agentes podem emitir para os gerentes. Trabalham sobre as estruturas de dados representadas pelas MIB que modela o comportamento dos elementos da rede. Os protocolos CMIS/CMIP e SNMP apresentam funcionalidades bastante diferentes entre si, as quais são abordadas na forma de uma visão geral neste capítulo.
O conjunto formado pelos padrões para especificação de MIB, visto no capítulo anterior, e pelos protocolos de gerência analizados neste capítulo, constituem-se na arquitetura de gerência a ser adotada para a administração e o controle das operações da rede corporativa.
4.1 PROTOCOLOS DO MODELO DE REFERÊNCIA OSI
O Modelo de Referência OSI implementa uma gerência de rede pautado no princípio do balanceamento da carga de trabalho entre o gerente e o agente, com a comunicação podendo ser estabelecida por iniciativa de ambos os lados. O gerente emite solicitações de operação para serem executadas pelos agentes, solicita ou altera informações dos agentes, ativa ou desativa instâncias de classes de objetos. O agente por sua vez, emite notificações para o gerente assincronamente, sem que este tenha que efetuar qualquer solicitação, a partir do momento que certas condições pré-estabelecidas sejam encontradas em um determinado elemento da rede. É por natureza um sistema distribuído, podendo um elemento específico na rede execer o papel de agente e ao mesmo tempo o de gerente. O modelo básico de gerência OSI é estabelecido pelas recomendações X.700 e X.701 da ITU-T e respectivas normas ISO 7498/4 e ISO 10040
46
[ITU-X700] [ITU-X701] e estudado em [HEB92] [CAR92] [STA93] [STA93A] [TAN92].
Os elementos descritos na sequência definem a estrutura do sistema de gerência na camada de aplicação do RM-OSI, a qual precisa estar presente, acompanhada das demais camadas de protocolos do modelo, em todos os elementos da rede que são gerenciados pelo sistema.
ACSE-Association Control Service Element: elemento de serviço de uso genérico da camada de aplicação do modelo OSI [ISO8649] [TAN92] [HEB92], responsável pelo estabelecimento da associação entre os processos de gerência na rede em um sistema. A gerência no modelo OSI é implantada de modo orientado à conexão, ou seja antes que seja iniciado o fluxo de informações é estabelecida uma conexão entre os dois processos.
ROSE-Remote Operations Service Element: elemento de serviço de uso genérico da camada de aplicação do modelo OSI [ISO9072] [TAN92] [HEB92], responsável pela execução de operações remotas na comunicação entre dois sistemas. A comunicação entre dois processos de gerência que foram associados através do ACSE é realizada através da invocação da execução de operações remotas providas pelo ROSE.
SMASE-System Management Application Service Element: enquanto o ACSE e o ROSE são elementos de serviço de uso genérico para qualquer aplicação OSI, o SMASE é um elemento de serviço de uso específico da camada de aplicação de gerência. Implementa um conjunto de funções requeridas por um serviço de gerência, denominadas SMF-System Management Functions, as quais podem ser escolhidas e combinadas para a montagem do sistema de gerência, de acordo com as necessidades da organização. Existem atualmente 13 funções atualmente padronizadas pelas normas ISO e recomendações ITU-T, detalhadas em [STA93] [STA93A] [CAR93], que são as seguintes:
Gerência de Objeto [ITU-X730]: como todo o processo de gerência no modelo OSI é baseado no conceito de objeto, esta função é a mais importante do conjunto, pois normatiza a execução de todos os serviços definidos pelo CMIS. Envolve a criação e
47
deleção de objetos, execução de operações sobre objetos, leitura e alteração de atributos, e emissão de notificações de eventos.
Gerência de Estado [ITU-X731]: define as representações de estado de um objeto gerenciado, e suas mudanças, tornando visível para o sistema a sua disponibilidade num dado momento. Considera aspectos de estar ou não fisicamente instalado e em operação, de estar ou não em uso e de aceitar ou não outros usuários adicionais, e ainda, de permitir ou restringir o seu uso pelo sistema de gerência.
Atributos para Representação de Relacionamentos [ITU-X732]: modela e identifica os tipos de relacionamentos que podem existir entre objetos representando partes diferentes de um sistema. Torna possível o monitoramento destas relações de forma a identificar como a operação de um objeto gerenciado afeta a operação de outros objetos. Por exemplo, um objeto pode ser automaticamente ativado em caso de falha de um outro objeto.
Notificação de Alarme [ITU-X733]: define como os alarmes são encaminhados ao gerente quando um agente detecta uma condição específica do objeto gerenciado, informando tipo de problema, causa provável e grau de severidade, de forma que o gerente possa atuar sobre as condições operacionais da rede. São definidas cinco categorias básicas de alarme, compreendendo erro de comunicação entre dois pontos, degradação da qualidade de serviço de um objeto, falha de processamento no objeto gerenciado, falha de equipamento e problema ambiental onde está alocado o objeto.
Gerenciamento de Notificação de Eventos [ITU-X734]: especifica como devem ser emitidas as notificações de eventos e de que forma estas notificações devem ser gerenciadas, incluindo a seleção dos eventos e a sua distribuição para tratamento por gerentes específicos. Define uma classe de objeto gerenciado denominada eventForwardingDiscriminator, a qual especifica os critérios de seleção e distribuição e a periodicidade em que as notificações de eventos de quaisquer objetos devem ser transmitidas para o seu destino.
Controle de Log [ITU-X735]: descreve um modelo para efetuar e controlar o registro sequencial dos eventos notificados e de outras informações de gerência,
48
criando um repositório de informações para uso posterior, obedecendo a critérios de seleção e a uma programação pré-estabelecida. Cada log é um objeto gerenciado que pertence à classe denominada log. Cada registro do log é também definido com um objeto gerenciado pertencente à classe logRecord.
Notificação de Alarme de Segurança [ITU-X736]: define de que maneira as notificações de alarme devem ser enviados para o gerente, quando ocorrer com um determinado objeto gerenciado uma situação que coloque em risco a segurança da rede. Compreende as áreas de violação de integridade por modificação ilegal de conteúdos de informação, violação operacional de um recurso lógico onde um serviço não pode ser acessado por indisponibilidade ou mau funcionamento, violação de um recurso físico por intromissão, violação dos serviços ou mecanismos de segurança pela detecção de ataques ou tentativas de ataque contra estes, e por último, violação de tempo pelo fato de um evento ocorrer fora de seu período permitido.
Registro para Auditoria de Segurança [ITU-X740]: é uma extensão do conceito de controle de log aplicado especificamente para registro de eventos relevantes relacionados com a segurança. Objetiva permitir a análise posterior dos fatos ocorridos para verificar eventuais ataques não detectados no momento de sua ocorrência e avaliar o grau de confiabilidade do sistema de segurança.
Objetos e Atributos para Controle de Acesso [ITU-X741]: modela o controle de acesso às informações e às operações de gerência, especificando objetos e atributos a serem associados com os objetos protegidos, de forma a permitir ou negar o acesso a estes objetos de acordo com as políticas de controle de acesso estabelecidas. Alguns usuários podem possuir permissão para leitura e modificação de atributos, alguns apenas para leitura, enquanto outros podem ser proibidos até de estabelecer conexão com o sistema de gerência. É também necessário evitar que notificações sejam enviadas para destinatários não autorizados e que entidades não autorizadas tenham acesso às operações de gerência.
Monitoração de Carga de Trabalho [ITU-X739]: padroniza as medições utilizadas para a monitoração do uso de recursos, definindo objetos gerenciados que emitem notificações baseadas em medidores para avaliar a performance da rede e conhecer o nível de demanda pelos recursos. Define os objetos gerenciados de medição, as
49
notificações que podem ser emitidas por estes objetos, além das operações de início, término, suspensão e retomada da monitoração, assim como as modificações dos parâmetros de monitoração.
Medidas para Contabilização [ITU-X742]: define um modelo para objetos medidores de contabilização do uso de recursos em uma rede, especificando os serviços para recuperação de informações, notificações, registros de uso, incluindo os critérios de seleção para coleta de informações.
Gerenciamento de Testes [ITU-X745]: suporta o controle remoto da execução de testes de diagnóstico e confiabilidade sobre um determinado recurso da rede, de acordo com uma programação estabelecida. Além das especificações dos objetos de teste, o modelo define as operações de início, término, suspensão e retomada.
Sumarização [ITU-X738]: estabelece um padrão para amostragem, agregação e sumarização de valores de atributos de instâncias de um objeto específico ao longo do tempo, ou de um conjunto de instâncias de diferentes objetos num dado momento, definidos a critério do gerente. Define objetos e atributos que indicam quais objetos e atributos farão parte da sumarização, os procedimentos de amostragem e de apresentação dos resultados, os algoritmos a serem utilizados para sumarizar e as operações de início e término das atividades. Define uma classe de objetos denominada scanner, da qual derivam as classes específicas de sumarização.
Outras: novas funções são definidas em um processo evolutivo à medida que a comunidade requer. Existem atualmente grupos trabalhando em padronização de funções como Gerenciamento de Software, Gerenciamento de Tempo, Gerenciamento de Performance, Definição de Classes de Objetos para Diagnóstico e Confiabilidade, dentre outros.
CMISE-Common Management Information Service Element: elemento de serviço de uso específico de gerência que implanta os padrões denominados CMIS-Common Management Information Services [ITU-X710]. Estes padrões definem as operações a serem invocadas pelos processos de gerência implantados nos elementos da rede, com a finalidade de realizar as funções acima descritas para o SMASE. O CMISE utiliza o
50
protocolo CMIP-Common Management Information Protocol [ITU-X711] na comunicação entre dois processos de gerência, o qual define como devem ser montadas as PDUs-Protocol Data Units para a troca de informações que será realizada através do ROSE. Os serviços atualmente padronizados pelo CMIS são:
Create: todos os objetos gerenciados no modelo OSI pertencem a uma classe de objetos previamente definida. A operação create é utilizada pelo gerente para criar uma nova instância de uma classe de objeto na MIB em um determinado agente residente em um elemento da rede. No momento da instanciação, o objeto específico é alocado em sua posição hierárquica na árvore de objetos, quando é assinalado um identificador para acesso, e são atribuidos os valores iniciais aos seus atributos.
Delete: elimina instâncias de objetos da MIB, podendo ser um único objeto ou um conjunto de objetos de uma sub-árvore, neste último caso definindo-se o objeto base e os parâmetros de escopo e filtro para determinação dos objetos a serem eliminados.
Get: permite ao gerente solicitar informações sobre objetos da MIB para um determinado agente, podendo ser um único ou múltiplos objetos, utilizando os recursos de filtro e escopo. Para cada objeto solicitado serão informados os valores de um, mais de um ou de todos os atributos do objeto, de acordo com os parâmetros de serviço.
Cancel-Get: cancela uma operação Get em andamento, nos casos onde o gerente detecte uma necessidade de interromper uma pesquisa, por já ter obtido as informações necessárias, pela pesquisa ser considerada muito longa para o resultado que se quer obter ou por outras razões.
Set: provê modificações de valores de um ou mais atributos pertencentes a um ou mais objetos gerenciados na MIB, usando também os recursos de escopo e filtro para acesso aos objetos na sub-árvore.
Action: possibilita ao gerente solicitar a um agente a execução de uma operação sobre um objeto gerenciado, que tenha sido especificada na definição da classe daquele objeto.
51
Event-Report: é o único dos serviços do CMIS que é iniciado pelo agente, sendo utilizado para enviar ao gerente uma notificação sobre a ocorrência de um determinado evento em um objeto gerenciado, quando uma determinada condição for satisfeita.
As funções e os serviços aqui apresentados de forma suscinta são
estudados com detalhes em [CAR92] e [STA93A]. Além do ROSE para a execução de operações remotas entre dois elementos de rede, o modelo prevê ainda, em algumas situações, a prestação dos serviços de intercâmbio de informações através de dois outros elementos de serviço de aplicação: o FTAM-File Transfer Access and Management, quando o volume de dados a ser transmitido é muito grande e a transmissão precisa ser controlada e o TP-Transaction Processing, nos casos onde existem muitos elementos de rede envolvidos em uma operação e se torna necessário executar os procedimentos remotos de forma coordenada. O TP implementa o controle de processos transacionais com conceito de atomicidade de operação, onde, todas as operações de uma transação são executadas com sucesso ou as já executadas são canceladas quando uma delas falhar.
Como o acesso à instâncias de objetos da MIB no modelo de gerência OSI, alocados na estrutura hierárquica representada pela MIT, pode ser efetuado por um único comando para toda uma árvore a partir da sua raíz, três recursos importantes são implementados para otimizar os procedimentos:
Escopo: define quais partes de uma sub-árvore de nomeação da MIB, serão objeto de seleção para execução dos serviços CMIS. Pode ser apenas o objeto base, todos os objetos do n-ésimo nível subordinado ao objeto base na sub-árvore, todos os objetos da sub-árvore compreendida entre o objeto base e o n-ésimo nível a partir deste, ou então todos os objetos da sub-árvore inteira desde o objeto base até as folhas.
Filtro: para os objetos selecionados pelo escopo podem ser aplicadas ainda comparações para verificar se atributos escolhidos satisfazem determinadas condições para que o objeto seja retornado ao gerente a partir de uma solicitação.
52
Sincronização: especifica como as operações serão executadas, podendo ser na base do melhor esforço, onde as operações são executadas independente umas das outras, ou então de forma sincronizada, quando todas as operações serão primeiramente verificadas para saber se podem ser executadas. No último caso, se uma delas não pode, nenhuma será executada, no conceito de atomicidade.
4.2 PROTOCOLOS DO AMBIENTE TCP/IP
O ambiente TCP/IP define um sistema de gerência mais simplificado do que o modelo padronizado pelo RM-OSI. É implementado como um processo de aplicação do Ambiente de Protocolos TCP/IP, utilizando o SNMP-Simple Network Management Protocol, descrito em [RFC1157] e estudado com detalhes em [ROS90A] [STA93A]. É por natureza um sistema centrado no gerente, com o agente possuindo uma função passiva: o gerente consulta cada um dos agentes ativos para verificar quem tem informações a enviar, conceito este conhecido como polling. O envio de notificações do agente para o gerente em caso de ocorrência de eventos excepcionais é eftuado de forma simples, praticamente informando a ocorrência, sem maiores informações.
Não existe uma estruturação de camada de aplicação no Ambiente de Protocolos TCP/IP como ocorre no modelo OSI. As funcionalidades de um processo de aplicação são implementadas acessando diretamente as primitivas da camada de transporte TCP-Transmission Control Protocol, no caso de serviços com conexão, ou UDP-User Datagram Protocol para serviços sem conexão. Para gerência SNMP foi definida a utilização do protocolo sem conexão UDP para simplificar a implementação. Não existe também uma estruturação de funções de gerência como no SMF, sendo apenas definido o processo de acesso às informações da MIB, que são tratadas de acordo com o sistema de gerência de cada fabricante.
O SNMP é um protocolo muito simples, que implementa apenas as seguintes operações de gerência:
53
Get: permite ao gerente solicitar ao agente o valor de um ou mais objetos na rede, devendo ser especificados todos os respectivos OIDs no parâmetro de serviço. Uma variante desta operação é o Get-Next, utilizado para efetuar uma pesquisa sequencial sobre os objetos da MIB, a qual é realizada em ordem lexicográfica, ou seja, na ordem em que os objetos foram definidos na árvore de registro.
Set: o gerente envia ao agente uma solicitação para que este proceda modificação do valor de um determinado objeto gerenciado.
Trap: com o objetivo de reduzir o consumo de recursos na rede proveniente das operações de polling do gerente sobre os agentes, quando um agente detecta alguma condição específica, este envia uma PDU com a informação sobre o elemento de rede, incluindo uma lista de objetos com seus respectivos valores. Existe um conjunto de traps padronizados para apontar as ocorrências: ColdStart, WarmStart, LinkDown, LinkUp, AuthenticationFailure, EgpNeighborLoss, EnterpriseSpecific. Além destas situações, cada fabricante possui em suas extensões da MIB um conjunto de traps proprietários para seus equipamentos, definidos conforme o padrão estabelecido pela [RFC1215].
Um sistema de gerência SNMP é organizado de forma que um determinado
agente pode ser acessado por vários gerentes distribuídos pela rede corporativa. Para que o agente possa controlar o acesso às suas informações, de forma que este somente seja permitido para os gerentes autorizados, é introduzido na PDU que transporta uma operação de gerência o parâmetro denominado community. Este parâmetro tem o significado de uma password sendo a autenticação efetuada de forma simples apenas por comparação do valor recebido na PDU com o definido pelo agente, para comprovar a autorização de acesso por aquele gerente. Não existem no escopo da definição dos protocolos SNMP outros mecanismos de segurança de acesso às informações de gerência.
A evolução do SNMP para sua versão 2 surgiu em decorrência do aumento da complexidade das redes e, consequentemente das necessidades de melhorar os procedimetos de gerência e de segurança, trazendo uma série de novas definições que incrementam significativamente as funcionalidades disponíveis na versão original
54
[STA93A]. Especificado inicialmente em 1994 e revisado recentemente em 1996,possui as definições dos protocolos de gerência documentadas em [RFC1441] [RFC1905] e os procedimentos de convivência com o SNMP versão 1 em uma mesma rede descritos em [RFC1908]. As mudanças significativas em relação à versão original são:
gerência distribuída: de forma semelhante ao definido para a arquitetura CMIS/CMIP o SNMPv2 implementa a gerência distribuída, permitindo a configuração de diversos gerentes na rede, cuja comunicação entre eles é realizada através da MIB denominada M2M de acordo com as especificações da [RFC1451].
segurança de acesso aos objetos: a Party MIB [RFC1447] especifica o modelo de informação e os procedimentos de segurança utilizados para proteger as informações dos objetos de gerenciáveis na rede contra acessos não autorizados. Esta nova funcionalidade preenche uma lacuna considerável da versão 1, que limita uso do modelo em gerência de rede corporativa onde as informações são muito sensíveis;
instanciação de objetos: realizada exclusivamente pelo agente na versão 1 passa a ser possível através do gerente na versão 2;
novas operações de gerência: para melhorar as funcionalidades e otimizar o acesso às informações de gerência dos objetos na rede foram definidas duas novas operações, detalhadas em [STA93A]:
Get-Bulk: para leitura de grandes blocos de dados em uma só operação, por exemplo objetos pertencentes a múltiplas linhas de uma tabela, objetivando diminuir a troca de PDUs entre os agentes e os gerentes, funcionando como um get-next expandido.
Inform: para comunicação de informações de gerência entre dois gerentes no processo de gerência distribuída.
A [RFC1902] que descreve a SMI do SNMPv2 implementa uma nova macro ASN.1, denominada NOTIFICATION-TYPE, a qual é utilizada para descrever a estrutura de informação a ser enviada em uma operação trap ou inform.
55
5 DETERMINAÇÃO DA ARQUITETURA DE GERÊNCIA
Conhecidas as arquiteturas de gerência de rede em sistemas abertos, um passo necessário no planejamento de implantação de um sistema de gerência em uma rede corporativa é a escolha da arquitetura de protocolos que vai ser utilizada. A avaliação das funcionalidades definidas para cada arquitetura deve ser realizada em paralelo com a análise das condições práticas que o mercado oferece para a respectiva implementação, levando em consideração aspectos de abrangência da rede e de horizonte de tempo desejado pela corporação.
A comparação entre as arquiteturas de gerência de rede em sistemas abertos, detalhada abaixo e sumarizada no Quadro 5.1, leva à constatação de que uma gerência implementada com a arquitetura de protocolos CMIS/CMIP incorpora uma série de facilidades que não são encontradas na SNMP, pois oferecem um conjunto complexo de funcionalidades para a realização dos serviços. A arquitetura SNMP por sua vez foi concebida com o objetivo de implementar um conjunto mínimo de funcionalidades, como o próprio nome sugere, “simple...”, impondo restrições para facilitar a sua implantação em todos os elementos de rede.
Analisando sob a perspectiva técnica e dos recursos disponíveis, algumas comparações podem ser realizadas, cujo aprofundamento pode ser obtido através das referências citadas nos capítulos 3 e 4:
Orientação a Objetos: a arquitetura CMIS/CMIP implementa de forma completa um modelo orientado a objeto, com definição de classes de objetos, encapsulando os atributos do objeto e as operações que sobre ele podem ser realizadas. Utiliza o conceito de herança de classes, o que permite modelar classes de objetos a partir de refinamentos sucessivos ou especialização de classes já definidas. Na arquitetura SNMP este conceito é simplificado: cada objeto é um simples atributo definido por um tipo e pelas operações, get e set, podendo ser definidas tabelas bi-dimensionais de objetos, mas o acesso é sempre efetuado referenciando individualmente o objeto. Os objetos SNMP são organizados na MIB em grupos voltados para funcionalidades específicas.
56
Re-uso de objetos: a arquitetura SNMP possibilita o re-uso de definições somente através das operações de export/import definidas na ASN.1 [ISO8824], uma vez que não implementa o conceito de herança de classes.
Acesso aos objetos: um objeto é acessado na arquitetura CMIS/CMIP através de uma operação especificando-se a sua classe e respectivas instâncias desejadas, sendo retornado o conjunto total de atributos ou os escolhidos para cada instância. Podem ser acessadas e transportadas em uma única PDU sub-árvores inteiras da MIT, ou a própria MIT completa. Na arquitetura SNMP uma operação de acesso é realizada especificando-se individualmente todos os objetos individualmente, não sendo permitido o acesso a um grupo de objetos e nem mesmo uma entrada de uma tabela. No caso de tabelas, uma PDU somente transporta objetos de uma única linha, restrição que desaparece no SNMPv2.
Instanciação de objetos: na arquitetura CMIS/CMIP é realizada tanto pelo agente como pelo gerente a partir da classe do objeto e efetuada de forma dinâmica constituindo a MIT. Na arquitetura SNMP a árvore de instâncias dos objetos é a mesma árvore de registro dos objetos. A instância de um objeto unitário confunde-se com o próprio objeto; quando os objetos são agrupados em tabelas, os índices da entrada na tabela são utilizados para diferenciar as instâncias de um mesmo objeto. Na versão 1 apenas o agente pode instanciar um objeto enquanto que na versão 2 a instanciação passa a ser permitida também a partir do gerente.
Segurança de acesso: a arquitetura CMIS/CMIP define mecanismos de segurança, que asseguram o acesso aos objetos gerenciados e aos recursos de gerenciamento apenas para usuários autorizados. No SNMP a proteção contra acesso é muito vulnerável, implantada apenas através do parâmetro community, que é uma espécie de senha que trafega junto na PDU. Este é um dos problemas da arquitetura que motivou o desenvolvimento do SNMP versão 2.
Gerência distribuída: a gerência CMIS/CMIP foi concebida de forma a possibilitar a existência de diversos gerentes integrados, podendo ser distribuídas as funções de gerência por região da rede ou por especialização, de acordo com a conveniência do sistema, sem perder a visão do todo. Na arquitetura SNMP a gerência é centralizada, podendo existir diversos gerentes, que não se integram, permitindo apenas uma
57
distribuição da gerência por segmentos da rede. O SNMPv2 já implementa conceitos de distribuição.
Notificações de eventos: CMIS/CMIP implanta um sistema complexo de notificações de ocorrência de eventos descrevendo-as através de objetos que contém as informações necessárias para sua análise, além de um esquema de direcionamento para gerentes especializados para seu tratamento no sistema. Na arquitetura SNMP o conceito é mais simples, tendo sido padronizado um conjunto mínimo de eventos genéricos para serem emitidos pelo agente. Os agentes que implementam MIBs proprietárias definem também seus próprios traps para notificação de eventos específicos. A versão 2 do SNMP define uma nova macro para melhorar as especificações do problema no caso de uma notificação de evento.
Funções de gerência: na SNMP são definidos apenas os protocolos para serem utilizados na construção das funções de gerência, cujas definições não fazem parte do escopo da arquitetura, ficando o desenvolvimento no interesse de cada implementador. Na CMIS/CMIP as SMFs especificam uma série de funções que podem ser implantadas de forma padronizada pelos sistemas de gerência.
Complexidade de implementação: CMIP/CMIS é uma arquitetura muito complexa, onde a implementação das facilidades requerem um investimento muito grande, tanto em recursos de desenvolvimento de produto como em recursos de equipamentos, pela necessidade de implementar as sete camadas do modelo para a construção de um agente. O SNMP implementando apenas operações básicas de leitura/modificação de objetos e notificações, utilizando-se do protocolo de transporte UDP, o que torna a construção de um agente bastante simples e requer poucos recursos do equipamento a ser gerenciado.
Existência de MIB padrão: na arquitetura CMIS/CMIP um pequeno grupo de classes de objetos está definido atualmente de forma padrão pela ISO e ITU para serem utilizadas na construção de novas classes para compor a MIB de um sistema. A nível de aplicação para elementos de rede, classes mais especializadas são padronizadas por entidades interessadas em determinados segmentos como é o caso da ITU-T para a arquitetura TMN. Na arquitetura SNMP o enfoque é mais prático pois, já no conjunto de RFCs que implementam a arquitetura, existem definições de vários grupos de objetos
58
para gerenciar funcionalidades específicas comuns a diversos elementos de rede, cuja implementação é direta. Estas definições têm sido estendidas de forma contínua surgindo novos grupos de objetos na medida em que a demanda os requerem.
As comparações aqui apresentadas, alcançadas através da análise realizada
para cada modelo, demonstram que a implantação da arquitetura CMIS/CMIP especificada no Modelo de Referência OSI seria o ideal para um sistema de gerência de rede corporativa, pois está estruturada de forma a permitir um crescimento em termos de funcionalidades e de complexidade, que não se encontra na arquitetura SNMP definida para o Ambiente de Protocolos TCP/IP.
Para avaliar a viabilidade da implementação de um sistema de gerência em arquitetuta de protocolos abertos, foi realizada uma pesquisa com amostras dos tipos de elementos de rede definidos no capítulo 2. As amostras foram escolhidas no universo dos elementos existentes na Rede Integrada de Comunicação de Dados e Serviços do Governo do Estado do Paraná, para a qual este trabalho se constitue em proposta de implementação. A constatatação é que existe uma larga implementação de agentes SNMP nos vários tipos de elementos de rede analisados, como pode ser verificado no capítulo 7, ao contrário da arquitetura CMIS/CMIP, para a qual não foram encontrados, no escopo desta pesquisa, agentes que implementem seus protocolos e respectiva MIB.
Esta realidade, encontrada no mercado produtor de bens e serviços de informática, decorre da necessidade de implementação de sistemas de gerência nas redes corporativas, que crescem a cada dia, levando a riscos de perda de controle tanto a nível qualitativo quanto econômico. Nesta linha, o que se pode concluir, é que não existe espaço no momento atual, e futuro de curto prazo para a viabilização de uma gerência CMIS/CMIP sobre todo o escopo de elementos de uma rede corporativa. A colocação do termo momento atual é utilizada para defender uma posição de que a arquitetura CMIS/CMIP não está descartada definitivamente do mercado como solução para a gerência de redes corporativas. Ela deve se justificar com o crescimento da complexidade funcional dos elementos de rede e vai se tornar viável com o crescimento numa proporção maior ainda da capacidade de processamento e de memória dos equipamentos e sistemas. A adoção da arquitetura OSI para o gerenciamento integrado
59
das redes de telecomunicações, na arquitetura TMN, é um caso real de implementação que reforça esta posição. Em redes corporativas de uma forma geral, a sua implantação pode ser factível, a médio prazo, no gerenciamento de aplicações, servidores de bases de dados e sistemas de processamento, pois os recursos computacionais dos equipamentos onde devem rodar os respectivos agentes já são hoje compatíveis.
A opção pela arquitetura SNMP para a primeira etapa do projeto de gerência da Rede Integrada de Comunicação de Dados e Serviços do Estado é uma definição pragmática para viabilizar a sua implantação a curto prazo, e é justificada pelas seguintes razões básicas:
simplicidade do modelo: o modelo de informação de gerência proposto para os elementos de rede é simples e não requer mecanismos complexos para sua definição e implantação; além disso, a quantidade de tipos de elementos de rede presentes em uma rede corporativa é pequena;
disponibilidade: os elementos de rede utilizados atualmente disponibilizam os recursos necessários para viabilizar a implantação imediata no nível de equipamentos, até a camada dos roteadores e comutadores. O desenvolvimento de agentes CMIS/CMIP pelo usuário para estes equipamentos é inviável, pois mesmo na hipótese da existência de recursos suficientes nos equipamentos a sua implantação não é possível pelo fato do software dos mesmos serem fechados e de domínio do fabricante. Além dos objetos padronizados na MIB SNMP, constata-se no capítulo 7 a existência de um grande número de objetos proprietários providos pelos fabricantes dos elementos de rede;
desenvolvimento: para as camadas superiores, a nível de sistema, em alguns casos a implementação é direta e em outros haverá a necessidade de desenvolver ou estender agentes para uma gerência na forma proposta pelo modelo. Mesmo que o desenvolvimento de agentes CMIS/CMIP para este nível seja tecnicamente viável, o esforço para preenchimento das lacunas existentes nos agentes SNMP do mercado requer a disponibilização de recursos humanos quantitativamente e qualitativamente muito menor, além de um tempo mais curto para implantação.
60
evolução: a migração em um futuro próximo para a versão 2 do SNMP, na medida em que o mercado começe a implementar mais acentuadamente a MIB neste padrão, é facilitada pela sua convivência com a versão 1 em uma mesma rede [RFC1908], possibilitando um primeiro ganho qualitativo no processo de gerência;
rapidez de implantação: pela simplicidade dos protocolos, facilidade de desenvolvimento e de extensão de agentes, disponibilidade de implantação de agentes no mercado, dentre outros fatores, um sistema de gerência SNMP pode ser rapidamente implantado na rede corporativa.
Quadro 5.1 - Critérios para Determinação da Arquitetura de Gerência CRITÉRIO CMIS/CMIP SNMP Orientação à Objeto completa restrita Re-uso de Definições classes/pacotes import ASN.1 Acesso aos Objetos classe unitário Instanciação dinâmica estática Segurança sim restrita Gerência Distribuída sim não Notificações sim restrita Funções de Gerência sim não Complexidade complexa simples MIBs Padronizadas não sim Disponibilidade no Mercado não sim Desenvolvimento de Agentes complexo simples
61
Ainda que a especificação das funcionalidades e dos requisitos para escolha de plataformas para exercerem o papel de gerentes no sistema não faça parte do escopo deste trabalho, constituindo-se em assunto proposto no capítulo 8 para estudos futuros, há um aspecto que é importante considerar. Muitos fabricantes disponibilizam hoje no mercado plataformas para implantação de sistemas de gerência, com maiores ou menores facilidades, para atender aos mais variados tipos de demanda em função do porte da rede e dos objetivos de gerência estabelecidos pela organização. A plataforma de gerência a ser implementada em uma rede corporativa não deve se restringir ao SNMP versão 1, mas sim, permitir a gerência integrada de elementos de rede que implementem agentes SNMP, SNMPv2 e CMIS/CMIP. É o que vai ocorrer no caso da Rede Integrada do Governo do Estado, para possibilitar a evolução gradual do processo de gerência em função do crescimento da complexidade da rede, protegendo os investimentos realizados em cada etapa.
62
6 ESPECIFICAÇÃO DOS REQUISITOS DE INFORMAÇÃO
O projeto para implementação de um sistema de gerência de rede corporativa em uma organização deve ser desenvolvido de forma a atingir os objetivos estabelecidos para o negócio da organização, buscando um equilíbrio entre as funcionalidades e os investimentos necessários para sua disponibilização. Devido ao grau de dependência cada vez maior dos sistemas de informação para o sucesso das organizações, a qualidade dos serviços oferecidos pela organização está na proporção direta da quantidade e qualidade das informações disponíveis no sistema de gerência da rede que suporta os respectivos sistemas.
Os padrões de gerência de rede em sistemas abertos, como abordados anteriormente, especificam os protocolos para a comunicação entre gerente e agente, as regras para estruturação da MIB, além das MIBs SNMP já padronizadas para implementação nos elementos de rede. Estes elementos fornecem os insumos básicos para estruturação de um sistema de gerência corporativo. A elaboração do projeto deve considerar como primeira tarefa a identificação do conjunto mínimo de informações que, utilizadas de forma integrada, permitam conhecer a cada instante o comportamento da rede da organização.
A abordagem adotada neste trabalho, ilustrada na Figura 6.1, para definição da estrutura de informação, compreende a identificação das informações a respeito de cada tipo de elemento de rede a ser gerenciado, realizada sob a ótica das cinco áreas de gerência abordadas no capítulo 2: Falhas, Configuração, Desempenho, Segurança e Contabilização. Para cada uma destas áreas são definidas as informações que precisam ser disponibilizadas em cada um dos tipos de elementos de rede definidos também no capítulo 2: Aplicações, Servidores de bases de dados, Sistemas de processamento, Roteadores, Comutadores de pacotes, Canais de comunicação e Concentradores de redes locais.
63
FALHAS CONFIGURAÇÃO PERFORMANCE SEGURANÇA CONTABILIZAÇÃO
APLICAÇÃO
SERVIDOR BASES DADOS
SISTEMA PROCESSAMENTO
ROTEADOR
COMUTADOR
CANAL
CONCENTRADOR LAN
ÁREAS DE GERÊNCIA ELEMENTOS DE REDE
Figura 6.1 - Abordagem para Especificação dos Requisitos de Informação
Embora as discussões sobre o papel organizacional do serviço de gerência de rede na corporação não façam parte do contexto deste trabalho, é importante salientar que ele influencia sobremaneira a definição do modelo de informação que comporá o sistema. Por esta razão, está relacionado no capítulo 8 como uma das recomendações para estudos futuros. Existem organizações onde o serviço de gerência possui a missão de identificação centralizada do comportamento dos elementos da rede, com uma ação de suporte de primeiro nível e encaminhamento das ações especializadas para áreas específicas ou para o suporte local. Para este enfoque, adotado na gerência da Rede Integrada do Governo do Estado do Paraná, é que foi proposto o nível de informação de gerência deste trabalho, onde informações mais detalhadas, se necessárias, devem ser buscadas pela equipe especializada. No entanto, se a gerência centralizada da rede possuir como papel a resolução de todos os níveis de problemas, o modelo deve possuir um grau de detalhamento mais aprofundado.
A definição do modelo de informação para gerência deve também considerar que o transporte das informações entre os gerentes e os agentes vai gerar um overhead de tráfego na rede. Os canais por onde trafegam as informações das aplicações da rede corporativa são os mesmos por onde trafegam as informações de gerência. Informações de gerência que não tragam consigo um valor agregado, que contribua para
64
a qualidade da rede, devem ser evitadas sob pena de comprometer a performance da rede ou de agregar custos desnecessários.
6.1 REQUISITOS DE INFORMAÇÃO POR ÁREA DE GERÊNCIA
As informações necessárias para um sistema de gerência relacionadas para cada elemento de rede, classificadas pelas cinco áreas de gerência, foram definidas sem a preocupação da existência ou não de MIB no mercado que as implemente. Não levou-se em consideração também a viabilidade de seu desenvolvimento e implementação, o que é estudado no capítulo 7. Com isto não se impôs qualquer limitante no desenho do modelo, que poderia surgir baseado em premissas de dificuldades ou de impossibilidades. O modelo reflete, portanto, uma necessidade real levantada para a gerência da Rede Integrada de Comunicação de Dados e Serviços do Estado do Paraná, e que serve de base para a elaboração de projetos semelhantes em qualquer organização.
Os requisitos de informação que foram definidos para cada cada área funcional de gerência foram obtidos a partir da convergência de duas linhas: um estudo sobre a natureza das informações a serem tratadas em cada uma das áreas definidas no RM-OSI, apresentada no capítulo 2, e uma reflexão sobre as necessidades percebidas através da experiência vivenciada na administração da Rede Integrada do Estado, que há anos é realizada pela Celepar. A primeira não define um modelo de informação mas conceitua os resultados a serem atingidos, organizando o raciocínio, enquanto a segunda resulta em informações que são tratadas no cotidiano dos problemas e soluções. O modelo de informação proposto é um modelo básico, conforme as premissas apresentadas no item anterior, compreendendo um mínimo de recursos necessários para o início de um processo de gerência integrada de uma rede corporativa. Deve evoluir e ser expandido com o tempo e com os resultados obtidos a partir da sua implantação. Dependendo dos objetivos da organização para o qual se esteja elaborando um modelo de informação de gerência, este pode iniciar já forma mais complexa.
65
Um outro aspecto importante a considerar no projeto, é que o modelo deve prover informações que permitam uma gerência pró-ativa sobre os diversos elementos, de forma que a gerência de rede centralizada tenha condições de atuar sobre um determinado problema antes que este aconteça. Informações sobre alterações no comportamento de um elemento, emitidas por uma gerência de configuração ou de desempenho, por exemplo, podem identificar com antecedência que uma falha pode acontecer em futuro próximo.
6.1.1 GERÊNCIA DE FALHAS
O resultado final que uma organização espera da gerência de falhas é o conhecimento da disponibilidade operacional para os usuários da rede, de um determinado serviço no sistema de processamento no qual foi implantado. Diante da informação que um serviço está indisponível, no momento exato em que ocorra esta indisponibilidade, o serviço pode ser imediatamente restabelecido, minimizando os impactos para os seus usuários. Com esta finalidade, o agente associado a cada um dos elementos de rede deve prover a informação do estado operacional de seus objetos gerenciados quando solicitada pelo gerente ou então de forma espontânea, através da emissão de um alarme imediato para notificação ao gerente. Nos casos de uma indisponibilidade total do elemento na rede o agente se torna inacessível e nestas situações o gerente obtém a informação de falha após sucessivas operações de polling não respondidas pelo agente. Ressalte-se que a falha é a última situação desejada e que o sistema deve trabalhar sempre de forma pró-ativa para evitá-la.
No nível do agente, o que precisa estar contido na MIB é a identificação do elemento e o estado operacional dos objetos gerenciados. No entanto, para uma efetiva gerência de falhas é importante que o sistema de gerência tenha capacidade para manter informações do tipo: data, hora e motivo da ocorrência da indisponibilidade, previsão para o restabelecimento, data e hora do retorno à condição operacional. Estas informações, as quais devem ser armazenadas em um log para análises posteriores, devem ser em parte providas por elemento humano, pois o agente não tem condições de informar. As falhas para os elemento de rede podem ser identificadas da seguinte forma:
66
aplicação e servidor de bases de dados: estado operacional do elemento, nos casos onde o agente esteja imbutido na aplicação ou no servidor de bases de dados, ou então através de notificação pelo agente, se este residir no sistema de processamento de forma isolada do elemento de rede;
sistema de processamento: estado operacional do sistema de processamento; não há como emitir notificação pelo agente em caso de falha no sistema;
roteador, comutador de pacotes e concentrador de rede local: estado operacional do respectivo elemento de rede para falha geral; para as portas, estado operacional da porta ou notificação pelo agente do elemento de rede;
canal de comunicação: notificação pelos agentes dos roteadores ou comutadores que são interconectados pelo canal.
6.1.2 GERÊNCIA DE CONFIGURAÇÃO
As informações que os agentes devem disponibilizar no âmbito de gerência de configuração, devem permitir que o sistema de gerência conheça a localização, as capacidades, as configurações, o estado operacional e outras características de cada elemento ativo na rede. A cada instante pode ser elaborado pelo sistema de gerência, e de forma automática, um mapa da rede ou de parte dela.
Um conjunto mínimo de informações que são comuns a todos os elementos é composto por: descrição do elemento na rede com identificação, marca, modelo, característica principal, localização física, configuração, estado operacional, responsável pelo elemento na rede. Para cada elemento de rede são definidas outras informações de acordo com as características individuais a saber:
67
aplicação: último start, capacidade de conexões concorrentes, identificação das suas transações, outras aplicações locais ou remotas das quais depende para o seu funcionamento, sistema ou negócio ao qual pertence; outras informações adicionais definidas em função das características particulares e dos serviços oferecidos pela aplicação;
servidor de bases de dados: último start, capacidade de conexões concorrentes; para cada base de dados: capacidade de armazenamento alocada;
sistema de processamento: último start, endereço de rede, quantidade de usuários e de processos que podem existir concorrentemente, capacidade de memória principal, capacidade do sistema de armazenamento, capacidade do sistema de processamento, relação e características das filas de impressão do sistema, estado dos protocolos de rede;
roteador: endereço de rede, estado administrativo, capacidade de roteamento em pacotes/segundo, quantidade de slots disponíveis e instalados, quantidade de portas instaladas, lista de protocolos de rede roteáveis, tabela de rotas e, para cada porta: estado operacional e administrativo, endereços de rede, tipo da interface física, velocidade, protocolo de enlace, número máximo de circuitos virtuais X.25 configurados;
comutador de pacotes: endereço de rede, estado administrativo, capacidade de comutação em pacotes/segundo, quantidade de slots disponíveis e instalados, quantidade de portas instaladas, tabela de rotas e, para cada porta: estado operacional e administrativo, endereço de rede, tipo da interface física, velocidade, número máximo de de circuitos virtuais X.25 configurados;
canal de comunicação: protocolo de enlace, capacidade de tráfego em bits/segundo;
concentrador de rede local: endereço de rede, estado administrativo, quantidade de slots existentes e instalados, quantidade de portas existentes e instaladas e, para cada porta: endereço MAC, protocolo de enlace, tipo da interface física, estado operacional e administrativo.
68
6.1.3 GERÊNCIA DE DESEMPENHO
As informações para gerência de desempenho são diferentes para cada elemento de rede, pois cada um tem um conjunto de indicadores definidos em função das suas características operacionais. Cada indicador deve possuir uma definição dos valores limites, ou thresholds, a partir dos quais podem ser emitidos alarmes de notificação imediatos para o gerente. Estes valores devem ser determinados em função da capacidade de cada elemento de rede e dos níveis de utilização a partir dos quais o desempenho começa a comprometer a qualidade do serviço.
As informações de desempenho coletadas pelo gerente junto ao agente, além de propiciar a tomada de ações imediatas pelos administradores da rede, devem ser armazenadas com a informação de data e hora da amostragem. A finalidade é realizar análises de desempenho da rede e da disponibilidade dos seus elementos, identificação de segmentos críticos, planejamento de ampliações e outras ações. As informações mínimas por elemento de rede, a serem obtidas por intervalo de tempo a ser definido em função da precisão desejada, são as seguintes:
aplicação: conexões concorrentes ativas, média de conexões por segundo, quantidade de conexões rejeitadas; por transação: conexões concorrentes ativas, tempo médio de resposta, média de transações por segundo, quantidade de conexões rejeitadas, quantidade de transações não concluídas e outras informações individualizadas para cada serviço prestado;
servidor de bases de dados: conexões concorrentes ativas, média de conexões por segundo, quantidade de conexões rejeitadas, quantidade de transações não concluídas; por base de dados: conexões concorrentes ativas, tempo médio de resposta para as transações, média de transações por segundo, média de conexões por segundo, quantidade de acessos negados, não concluídas, quantidade e percentual de utilização da capacidade de armazenamento alocada;
sistema de processamento: quantidadade de processos e de usuários simultâneos, cargas de processos rejeitadas por falta de recursos, quantidade de acessos negados,
69
média de memória virtual utilizada e relação virtual/real, índice médio de paginação de memória, quantidade e percentual de área utilizada no sistema de armazenamento, percentual médio de utilização do processador, tempo médio de acesso a discos; lista de processos em execução com identificação, estado e uso do processador e de memória; quantidade de serviços nas filas de impressão e lista dos serviços com respectivos status;
roteador: quantidade média de pacotes roteados por segundo, quantidade de pacotes errados classificados por tipo de erro como CRC, alinhamento de quadro, tamanho etc., quantidade de portas ativas; a nível de porta: quantidade de circuitos virtuais X.25 ativos, quantidade de circuitos virtuais por endereço de destino, quantidade média de pacotes e de octetos trafegados por segundo, quantidade de pacotes errados classificados também por tipo de erro;
comutador de pacotes: quantidade média de pacotes comutados por segundo, quantidade de pacotes errados classificados por tipo de erro como CRC, alinhamento de quadro, tamanho etc., quantidade de portas ativas, a nível de porta: quantidade de circuitos virtuais X.25 ativos; quantidade de circuitos virtuais por endereço de destino, quantidade média de pacotes e octetos trafegados por segundo, quantidade de pacotes errados classificados também por tipo de erro;
canal de comunicação: utilização média em bits/segundo e percentual de utilização em relação à capacidade nominal;
concentrador de rede local: quantidade de portas ativas, quantidade de pacotes e de octetos trafegados no barramento, taxa de colisão de pacotes, quantidade de pacotes errados classificados por tipo de erro como CRC, alinhamento de quadro, tamanho etc.; em cada porta: quantidade de tráfego em pacotes e em octetos, quantidade de pacotes errados classificados também por tipo de erro.
70
6.1.4 GERÊNCIA DE SEGURANÇA
A principal tarefa da gerência de segurança é cuidar de aspectos relativos à proteção da rede contra o uso de informações por aplicações ou por indivíduos não autorizados. Cada elemento de rede deve oferecer um tipo de proteção de acordo com os serviços que presta. Os agentes dos elementos gerenciados devem disponibilizar informações em suas MIBs com a finalidade de possibilitar a implementação e o acompanhamento dos níveis de proteção da segurança da rede e averiguar a sua efetividade. Estas informações devem incluir as listas de usuários ou de aplicações autorizadas e suas respectivas senhas para acesso ao elemento como um todo ou parte dele, as quais devem trafegar criptografadas na rede. Um alarme em tempo real deve ser emitido para notificação ao sistema de gerência sempre que uma tentativa de acesso não autorizado for identificada em um elemento de rede com proteção de acesso, os quais devem ser armazenados em um log do gerente para análise posterior. Estes logs que são objeto de tratamento através das plataformas de gerência, cujo estudo é uma das propostas de continuidade sugerida no capítulo 8, devem ser devidamente protegidos, como por exemplo, transferindo-se para outras máquinas diferentes da que coleta e armazena inicialmente as informações.
Com a escolha dos protocolos de gerência recaindo sobre a arquitetura SNMP, a implementação de gerência de segurança fica comprometida. Por esta razão a proposta de implementação nas MIBs de objetos destinados à gerência de segurança não foi incluída no escopo deste trabalho, o qual tem como objetivo viabilizar a curto prazo a implantação do sistema de gerência na Rede Integrada do Estado. Como visto anteriormente, o grau de proteção oferecido pela arquitetura dos protocolos SNMP quanto ao acesso não autorizado às informações de gerência transportadas em uma rede é muito primário e, por isto, não é recomendável que informações sensíveis circulem pela rede.
Com protocolos mais elaborados, como a própria evolução do SNMP para sua versão 2 e os definidos para a arquitetura CMIS/CMIP, que estarão presentes nos produtos de mercado no futuro, a gerência de segurança em protocolos abertos poderá ser factível. Estas arquiteturas implementam sistemas de criptografia de mensagens e de
71
autenticação de usuários que possibilitam uma operação segura. Uma constatação ao analisar as MIBs proprietárias no capítulo 7, é que os fabricantes não disponibilizam acesso às informações de segurança em seus elementos de rede através da MIB SNMP.
Estes argumentos levam à proposição de utilizar os sistemas proprietários de cada elemento de rede para a implementação da gerência de segurança. Tanto a concessão dos privilégios de acesso quanto o controle sobre as tentativas de acesso não autorizados devem ser realizadas, na fase inicial de implantação do sistema, pelos administradores locais responsáveis pelo respectivo elemento de rede.
O único aspecto tratado com respeito a segurança neste trabalho é a informação prestada pelos agentes das aplicações, servidores de bases de dados e sistemas de processamento quanto às tentativas de acesso não autorizadas que foram identificadas pelo sistema de gerência proprietário do elemento de rede. Mantém-se na MIB os valores quantitativos de acessos negados, sendo as identificações dos usuários com tentativa frustrada de conexão remetidas como notificação para um log no sistema.
6.1.5 GERÊNCIA DE CONTABILIZAÇÃO
A gerência de contabilização tem como objetivo subsidiar a administração de uma organização com informações a respeito do consumo dos recursos pelos usuários da sua rede. As informações relevantes para contabilização de recursos devem incluir no mínimo:
aplicação: identificação do serviço da aplicação com a quantidade de unidades de serviço realizadas, contabilizadas a nível de usuário;
servidor de bases de dados: identificação da aplicação e do serviço da aplicação, contabilizando a quantidade de transações realizadas por usuário; quantidade de
72
armazenamento por arquivo do servidor e respectiva quantidade de acessos por aplicação e por usuário;
sistema de processamento: identificação da aplicação e do serviço da aplicação, informando por usuário a quantidade de unidades de processamento, memória, acesso a disco e páginas impressas;
roteador, comutador de pacotes, canal de comunicação e concentrador de rede local: quantidade de tráfego em octetos, identificado por endereço de origem de destino por serviço da aplicação e por usuário;
As informações de contabilização são utilizadas em períodos pontuais de
tempo, normalmente em periodicidade semanal ou mensal, para acompanhamento de uso de recursos ou para cobrança de serviços realizados. As informações não precisam portanto estar à disposição dos gerentes da rede no tempo em que elas ocorrem, e sim as ocorrências devem ser registradas e armazenadas cumulativamente até o ponto em que são recuperadas para utilização. Os volumes de informações, dependendo das características do elemento de rede, do seu grau de utilização e da necessidade de detalhamento, tendem a requerer áreas de armazenamento muito grandes.
Os elementos de rede são disponibilizados com sistemas de contabilização proprietários e implantados de forma compulsória, onde são armazenadas todas as informações de utilização. A utilização de um sistema paralelo de contabilização, implantado através de uma MIB para recuperação por protocolos SNMP acarretaria em uma redundância de armazenamento desnecessária e prejudicial ao sistema. Existe um outro ônus que é o da transferência dos altos volumes de informações do agente para o gerente através dos canais de comunicação da rede.
Estas considerações levam a uma proposta de não implementar no estágio atual uma gerência de contabilização em protocolos abertos. A proposta é que cada elemento da rede realize a sua contabilização de forma proprietária. Em períodos de tempo determinados pela administração, as informações são coletadas e remetidas para
73
apropriação através dos meios mais adequados para cada caso, normalmente não utilizando recursos da rede ou de seus servidores para realização da tarefa. Com esta decisão as MIBs propostas neste trabalho não consideram os objetos que sejam utilizados exclusivamente para fins de contabilização, e, consequentemente, as informações de contabilização não seriam acessadas a partir do sistema de gerência.
6.2 MODELO DE INFORMAÇÃO POR ELEMENTO DE REDE
As informações necessárias para implementação de cada área de gerência, acima definidas, são agrupadas agora por elemento de rede, com a finalidade de estabelecer o conjunto mínimo de informações que deve ser disponibilizado pelos agentes instalados em cada elemento de rede. Este conjunto de informações constitui-se no que é denominado neste trabalho de uma MIB mínima para cada elemento.
Nos casos onde existem agentes com suas MIBs implementadas com um conjunto de informações maior do que exige a MIB mínima, esta representa então a visão restritiva que o gerente deve possuir do elemento de rede. O objetivo é manter o menor tráfego de informações de gerência possível que atenda aos aspectos essenciais para o controle da rede corporativa. Nos elementos onde não exista agente implementado ou o conjunto de informações é menor que o requerido, a MIB mínima define os objetos que precisarão ser implementados.
A MIB mínima é o ponto de partida proposto para implementação de um sistema de gerência, o qual deve crescer de forma evolutiva no tempo. As suas definições foram pautadas nas necessidades atuais constatadas para o gerenciamento global da Rede Integrada de Comunicação de Dados e Serviços do Governo do Estado do Paraná. Na medida em que o uso das informações começe a trazer resultados para a melhoria dos serviços na rede, certamente novas informações começarão a se tornar necessárias para o refinamento do sistema. Por se tratar de um sistema aberto de gerência, novos objetos podem ser incorporados a qualquer momento no sistema.
74
A metodologia para definição de objetos tanto na arquitetura CMIS/CMIP quanto na SNMP preconiza a utilização da notação ASN.1-Abstract Syntax Notation 1 [ISO 8824], através do uso de macros desenvolvidas para cada arquitetura conforme estudado anteriormente. A opção escolhida para a documentação do modelo de informação proposto foi seguir a mesma notação ASN.1, porém utilizando uma forma simplificada de representação.
O objetivo da simplificação é dar mais clareza às definições e proporcionar uma melhor visualização da estrutura de informação, uma vez que as representações formais padronizadas são mais complexas como visto nos exemplos mostrados anteriormente. Por outro lado a documentação do modelo proposto será utilizada apenas para mapear as informações por elemento de rede para verificação da existência de MIBs no mercado e definir os objetos a serem complementados. Para a efetiva implementação serão utilizados os objetos encontrados na MIB dos elementos de rede, os quais já possuem as suas definições formais. Somente foram realizadas as definições formais, de acordo com os padrões da SMI, para os objetos que serão desenvolvidos como extensão das MIBs, os quais estão documentados no Anexo 1.
Os modelos de informação propostos para as MIBs mínimas de cada elemento de rede são os apresentados nos Quadros 6.1 a 6.7.
75
Quadro 6.1 - Modelo de Informação para Aplicações APLICAÇÃO-MIB DEFINITIONS ::= BEGIN Aplicação ::= SEQUENCE { sistema IA5String, marca IA5String, modelo IA5String, descrição IA5String, nome IA5String, versão IA5String, local IA5String, respons IA5String, últimoStart UTCTime, estadoOper INTEGER, conexMax INTEGER, conexAtivas INTEGER, conexRealiz INTEGER, conexRejeit INTEGER, conexNeg INTEGER, usuários SEQUENCE OF IA5String} Transações ::= SEQUENCE OF SEQUENCE { nome IA5String, conexAtivas INTEGER, conexRealiz INTEGER, conexNeg INTEGER, transRealiz INTEGER, tempoRespTr INTEGER, transAbort INTEGER} DependeAp ::= SEQUENCE OF SEQUENCE { aplicação IA5String, endRede IA5String} OutrasInfo ::= -- definidas de acordo com as características particulares de cada -- aplicação e da necessidade de gerência. END
76
Quadro 6.2 - Modelo de Informação para Servidores de Bases de Dados SERVIDOR-BD-MIB DEFINITIONS ::= BEGIN Servidor ::= SEQUENCE { marca IA5String, modelo IA5String, descrição IA5String, nome IA5String, versão IA5String, local IA5String, respons IA5String, últimoStart UTCTime, estadoOper INTEGER, conexMax INTEGER, conexAtivas INTEGER, conexRealiz INTEGER, conexRejeit INTEGER, conexNeg INTEGER, transAbort INTEGER} BaseDados ::= SEQUENCE OF SEQUENCE { nome IA5String, conexAtivas INTEGER, conexRealiz INTEGER, acessosNeg INTEGER, transRealiz INTEGER, tempoRespTr INTEGER, mbDiscoAloc INTEGER, mbDiscoUso INTEGER} END
77
Quadro 6.3 - Modelo de Informação para Sistemas de Processamento SISTEMA-PROCESSAMENTO-MIB DEFINITIONS ::= BEGIN Sistema ::= SEQUENCE { marcaHw IA5String, modeloHw IA5String, descriçãoHw IA5String, marcaSop IA5String, modeloSop IA5String, descriçãoSop IA5String, nome IA5String, local IA5String, endRede IA5String, respons IA5String, ultimoStart UTCTime, estadoOper INTEGER, estProtRede INTEGER, capacProcess INTEGER, maxUsuConc INTEGER, maxProcConc INTEGER, memóriaRam INTEGER, mbDiscoInst INTEGER, mbDiscoAloc INTEGER, percProcess INTEGER, memoriaVirt INTEGER, indicePagin INTEGER, procRejeit INTEGER, acessosNeg INTEGER, tmpAcesDsk SEQUENCE { idDisco INTEGER, tmpAcesso INTEGER}} Processos ::= SEQUENCE { quantProc INTEGER, quantUsuários INTEGER, listaProcess SEQUENCE OF SEQUENCE { idProc IA5String, estadoOper INTEGER, usoProcess INTEGER, usoMemor INTEGER}} Cont.
78
Quadro 6.3 - (Cont.) Impressão ::= SEQUENCE OF SEQUENCE { nomeFila IA5String, descrImpress IA5String, quantServFila INTEGER, estadoOper INTEGER, listaServicos SEQUENCE OF SEQUENCE { nome IA5string, propriet IA5String, estadoOperINTEGER}} END
79
Quadro 6.4 - Modelo de Informação para Roteadores ROTEADOR-MIB DEFINITIONS ::= BEGIN Roteador::= SEQUENCE { marca IA5String, modelo IA5String, descrição IA5String, nome IA5String, local IA5String, respons IA5String, estadoAdm INTEGER, estadoOper INTEGER, capacRoteam INTEGER, protocRede IA5String, slots INTEGER, slotsInstal INTEGER, portasInstal INTEGER, portas Ativas INTEGER, pactRoteados INTEGER, pactErros SEQUENCE OF SEQUENCE { tipoErro INTEGER, pacotes INTEGER}} Portas ::= SEQUENCE OF SEQUENCE { numeroPorta INTEGER, enderIP IA5String, enderX25 IA5String, protocEnlace IA5String, estadoAdm INTEGER, estadoOper INTEGER, interfaceFis IA5String, velocPorta INTEGER, circVirtInst INTEGER, circVirtAtivos INTEGER, listaCircVirt SEQUENCE OF SEQUENCE { dteDest IA5String, qtdCircVirt INTEGER}, octetosTraf INTEGER, pactRoteados INTEGER, pactErros SEQUENCE OF SEQUENCE { tipoErro INTEGER, pacotes INTEGER}} Cont. Quadro 6.4 - (Cont.)
80
Rotas ::= SEQUENCE OF SEQUENCE { endDestino IA5String, metrica INTEGER, protocRoteam INTEGER, numeroPorta INTEGER} END
81
Quadro 6.5 - Modelo de Informação para Comutadores de Pacotes COMUTADOR-MIB DEFINITIONS ::= BEGIN Comutador::= SEQUENCE { marca IA5String, modelo IA5String, descrição IA5String, nome IA5String, local IA5String, respons IA5String, estadoAdm INTEGER, estadoOper INTEGER, capacComut INTEGER, slots INTEGER, slotsInstal INTEGER, portasInstal INTEGER, portas Ativas INTEGER, pactComut INTEGER, pactErros SEQUENCE OF SEQUENCE { tipoErro INTEGER, pacotes INTEGER}} Portas ::= SEQUENCE OF SEQUENCE { numeroPorta INTEGER, enderX25 IA5String, estadoAdm INTEGER, estadoOper INTEGER, interfaceFis IA5String, velocPorta INTEGER, circVirtInst INTEGER, circVirtAtivos INTEGER, listaCircVirt SEQUENCE { dteDest IA5String, qteCircVir INTEGER}, octetosTraf INTEGER, pactComut INTEGER, pactErros SEQUENCE OF SEQUENCE { tipoErro INTEGER, pacotes INTEGER}} Cont.
82
Quadro 6.5 - (Cont.) Rotas ::= SEQUENCE OF SEQUENCE { endDestino IA5String, metrica INTEGER, numeroPorta INTEGER} END
83
Quadro 6.6 - Modelo de Informação para Canais de Comunicação CANAL-MIB DEFINITIONS ::= BEGIN -- como os modems atualmente existentes na rede integrada não possuem agentes para -- gerenciamento SNMP, a gerência do comportamento dos canais de comunicação -- deverá ser realizada através dos agentes dos comutadores de pacotes e dos -- roteadores que são interligados através dos mesmos. Nesta linha não foi -- desenvolvida a definição de uma MIB específica para o canal. END
84
Quadro 6.7 - Modelo de Informação para Concentradores de Redes Locais CONCENTRADOR-RL-MIB DEFINITIONS ::= BEGIN Concentrador::= SEQUENCE { marca IA5String, modelo IA5String, descrição IA5String, nome IA5string, local IA5String, endRede IA5String, respons IA5String, estadoAdm INTEGER, estadoOper INTEGER, slots INTEGER, slotsInstal INTEGER, portas INTEGER, portasInstal INTEGER, portasAtivas INTEGER, octetosTraf INTEGER, pactTraf INTEGER, pactColis INTEGER, pactErros SEQUENCE OF SEQUENCE { tipoErro INTEGER, pacotes INTEGER}} Portas ::= SEQUENCE OF SEQUENCE { numeroPorta INTEGER, enderMAC IA5String, protEnlace IA5String, estadoAdm INTEGER, estadoOper INTEGER, interfaceFis IA5String, velocPorta INTEGER, octetosTraf INTEGER, pactTraf INTEGER, pactErros SEQUENCE OF SEQUENCE { tipoErro INTEGER, pacotes INTEGER}} END
85
7 IMPLANTAÇÃO DO MODELO DE INFORMAÇÃO
Conhecido o modelo de informação que atende as necessidades do sistema de gerência da rede corporativa da organização, o passo seguinte é realizar uma avaliação de mercado para os elementos de rede escolhidos para serem gerenciados. Esta pesquisa determina de que forma os produtos existentes implementam objetos gerenciáveis e como estes atendem as especificações. Muitos elementos podem não implementar todas as informações requeridas pelo sistema, gerando a necessidade de definição de novas MIBs ou extensão das atualmente existentes.
A avaliação da disponibidade de MIBs no mercado para atender aos requisitos do modelo de informação deve ser realizada em função dos elementos de rede existentes ou planejados para implantação na rede corporativa em estudo. Para efeito deste trabalho são tomados, em cada categoria, apenas os principais elementos da Rede Integrada de Comunicação de Dados e Serviços do Governo do Estado do Paraná como amostra para pesquisa. Além de ser uma rede conhecida e sobre a qual os conceitos podem ser facilmente aplicados, a escolha desta rede como laboratório deve-se ao fato dela possuir uma grande dimensão, considerando-se os apectos de distribuição de ambientes computacionais, a diversificação de elementos de rede e a diversificação de tecnologias e de fabricantes para cada tipo de elemento. Desta forma, a experiência prática conseguida durante o desenvolvimento do trabalho, poderá ser aplicada a qualquer tipo de rede corporativa, seja de organizações públicas ou privadas, adaptando-se os pontos específicos para os casos particulares de cada corporação. Os elementos envolvidos são de natureza semelhante e os conceitos a serem aplicados são os mesmos.
Os agentes de três dos elementos de rede definidos no escopo deste trabalho possuem como característica comum o fato de estarem processando no mesmo ambiente operacional ou seja, em um sistema de processamento. São os agentes que fornecem as informações de gerência para as aplicações, para os servidores de bases de dados e para o próprio sistema de processamento. Por definição [RFC1157], as PDUs de operação de gerência SNMP são enviadas para a UDP de número 161 do agente,
86
enquanto este envia para a porta 162 do gerente os traps. Isto implica em que o agente seja um processo único em um sistema de processamento. Como elementos de rede diferentes em um mesmo sistema tratam de informações de natureza diferentes, podendo pertencer também a fabricantes diferentes, a incorporação de novos objetos a um agente monolítico é tarefa inviável. Por esta razão foi adotado o conceito de multiplexação do agente em sub-agentes.
Cada sistema de processamento implanta um agente principal, que é o responsável pela comunicação com o sistema de gerência, implementando os protocolos SNMP. Este agente opera como um prestador de serviços para os sub-agentes, os quais possuem a responsabilidade de instrumentar as MIBs específicas para o qual foram desenhados, interfaceando com os elementos de rede gerenciados. O termo instrumentar a MIB é aqui utilizado com o significado de preencher as informações da MIB. O agente principal recebe todas as requisições de informações de gerência que são destinadas àquele sistema de processamento e repassa-as para os sub-agentes responsáveis pelo respectivo provimento. Uma vez obtido o resultado da pesquisa, o sub-agente repassa-o para o agente principal, que encarrega-se de enviar a resposta ao sistema de gerência. Da mesma forma, o agente principal deve encaminhar para o sistema de gerência os traps emitidos por um determinado sub-agente. Mais adiante, na análise das MIBs dos elementos de rede, são abordados aspectos de implantação destes conceitos.
Existem esforços de padronização para a forma de integração de sub-agentes em um sistema, documentados em diversas RFCs: o SMUX-SNMP Multiplexing Protocol [RFC1227] que é o mais antigo, o DPI-SNMP Distributed Program Interface [RFC1592] e, atualmente em grupo de estudos, o denominado AgentX, com um protótipo já definido denominado eSNMP-Extensible SNMP Interface. Sistemas como Windows/NT e Netware, por exemplo, implantam um conjunto de APIs-Application Program Interface proprietárias para a multiplexação do agente em sub-agentes. Como nenhum destes padrões firmou-se no mercado, alguns fabricantes estão desenvolvendo agentes monolíticos para responder em outras portas UDP diferentes da 161, a serem configuradas no sistema de gerência, o que ocorre fora das especificações padrão.
87
As MIBs citadas e analisadas neste trabalho representam uma posição bem definida no tempo. Esta consideração é importante para advertir que o uso futuro das informações aqui apresentadas deve ser efetuado com a devida avaliação das suas evoluções, pois as MIBs proprietárias sofrem atualizações consideráveis a cada mudança de versão do software do elemento de rede que as implementa, assim como as MIBs padronizadas são obsoletadas e editadas com novos números de RFC em seus refinamentos.
Outro aspecto a considerar é que este trabalho não possui a pretensão de aprofundar o estudo das MIBs citadas mas sim, apenas verificar a existência dos objetos necessários para atender à implantação do modelo de informação de gerência proposto no capítulo 6. Com isto, o estudo do potencial de gerenciamento empregando as MIBs padrão e proprietárias disponíveis nos elementos de rede do mercado foge do escopo deste trabalho.
Para o gerenciamento da Rede Integrada a partir do modelo de informação definido no capítulo anterior, será proposto o desenvolvimento de algumas MIBs proprietárias ou extensões proprietárias de MIBs existentes nos elementos de rede. Por uma política da Celepar, deverá ser explorada ao máximo a possibilidade de utilização de agentes através de produtos existentes no mercado, trabalhando-se no desenvolvimento interno apenas dos recursos que não forem encontrados. Nos textos deste capítulo será mostrada a estrutura de informação das MIBs definidas, sendo que a sua descrição formal, conforme o SMI da arquitetura de protocolos SNMP [RFC1155] [RFC1212], será apresentada no Anexo 1. As MIBs propostas tiveram suas sintaxes verificadas pelo serviço de compilação de MIBs, disponível através do envio do módulo através de correio eletrônico para o endereço [email protected].
7.1 GERENCIAMENTO DAS APLICAÇÕES
O gerenciamento de aplicações em padrões abertos é uma disciplina muito nova. Por muito tempo as preocupações e os esforços de desenvolvimento de gerência
88
têm sido concentradas sobre os equipamentos que interconectam os diversos sistemas de processamento e, por esta razão, pouco se encontra atualmente no mercado fornecedor de bens e serviços de informática sobre gerência de aplicações. Aplicações e softwares de uma maneira geral são mais complexos para serem gerenciados e contém um número maior de variáveis que impactam no seu comportamento. Por outro lado, os problemas de hardware são mais previsíveis, o que torna as implementações de gerência mais simples. Outro aspecto interessante nesta análise é que cada aplicação possui características muito peculiares o que torna muito difícil uma modelagem padrão para gerência, facilitando o surgimento de gerências proprietárias.
Não obstante as dificuldades, a gerência das aplicações em uma rede é de extrema importância e precisa começar a ser implementada em padrões abertos pelo menos em alguns aspectos essenciais. É fundamental em uma rede corporativa o conhecimento do estado operacional das aplicações, os parâmetros de configuração, o desempenho das suas transações, a interdependência com outras aplicações locais ou remotas, dentre outras. Este conjunto de informações permite aos operadores da rede um conjunto de ações capaz de resolver uma grande parte dos problemas, aumentando a disponibilidade das aplicações para os usuários. Um dos problemas críticos em uma rede é a necessidade de instalação remota de softwares em estações de trabalho e respectivo controle de versões, uma disciplina ainda não desenvolvida a nível de protocolos de sistemas abertos.
Da MIB-2 original [RFC1213] apenas o grupo systems {mib-2 1} fornece alguns poucos objetos para descrever aplicações. Outra MIB que fornece alguns objetos para gerenciamento de aplicações em rede é a application {mib-2 27} [RFC1565] mas ambas somadas não atendem aos requisitos do modelo apresentado neste trabalho, o qual especifica um mínimo de informações para a gerência das aplicações. A MIB application, proposta em 1994, possui dois grupos:
applTable {application 1} - nome e versão da aplicação, último start, estado operacional, data da última modificação, associações inbound e outbound atuais e acumuladas, associações rejeitadas;
89
assocTable {application 2} - para cada associação de uma aplicação, informa a aplicação remota correspondente, o protocolo utilizado, o tipo da associação e a duração.
A ausência de uma MIB padrão, com pelo menos o conjunto básico de informações, contribui efetivamente para a pobre situação do gerenciamento de aplicações em rede em sistemas abertos no mercado. A partir do desenvolvimento de um protótipo por engenheiros do Bellcore [WEI95] o IETF-Internet Engineering Task Force criou no final de 1995 um grupo de trabalho para desenvolvimento de uma proposta de uma MIB padrão para aplicações. Hoje existem dois esforços para o estabelecimento dos padrões: a MIB a ser proposta ao IETF e a MIB do Bellcore {enterprises 148}.
A MIB que deverá ser proposta neste primeiro semestre de 1996 ao IETF [MIB-IET] é uma primeira tentativa de expandir as condições de gerência através de uma única MIB para todas as aplicações em um sistema de processamento, de forma que não seja necessário coletar qualquer informação com a aplicação. Pode ser considerada uma extensão especializada da MIB host {MIB-2 25} analisada mais adiante, pois todas as informações serão obtidas a partir do sistema operacional. A decisão do grupo de trabalho visa uma implementação mais rápida pois não depende de modificar aplicações para fornecimento dos objetos para a MIB. É a seguinte a sua estrutura atual, devendo ser refinada até a sua apresentação ao IETF, que deverá ser registrada como um dos grupos da MIB-2 a ser denominado sysApplMIB, onde os objetos serão alocados na árvore sysApplObjects {sysApplMIB 1}:
sysApplInstalled {sysApplObjects 1} - tabela de aplicações instaladas em um sistema de processamento: identificação do produto, versão e fabricante, data da instalação, localização no diretório do sistema, nome do executável de carga da aplicação; tabela de elementos que compõem a aplicação: identificação do elemento, tipo executável ou não, data da instalação, tamanho, diretório onde está alocado;
sysApplRun {sysApplObjects 2} - tabela de aplicações rodando no sistema de processamento: estado operacional, data e hora de início e de término, pois a idéia desta MIB é manter o registro das últimas execuções da aplicação; tabela de elementos da aplicação rodando no sistema: identificação do processo, índice para MIB host {mib-2
90
25}, data e hora de início e de término, estado operacional, parâmetros de inicialização, tipo de aplicação, tempo de processador consumido, quantidade de memória alocada, número de conexões TCP utilizadas.
A proposta do Bellcore [MIB-BEL], em uso naquele laboratório, é bem mais completa exigindo a instrumentação da MIB pela aplicação, pois o nível de informação necessário ao povoamento da MIB não pode ser fornecido pelo sistema operacional. Esta MIB deve ser proposta oportunamente ao IETF como extensão da atual proposta, assim que esta for aprovada. Está definida através do identificador de objeto experimental {bellcore requirements (1) camn (8) 10} e possui a seguinte estrutura:
busFuncTable {experimental 1} - nome e descrição das funções do negócio da organização sob as quais as aplicações são agrupadas, data de implantação e responsável;
distAppTable {experimental 2} - aplicações configuradas para rodar no sistema de processamento: nome, versão, descrição, fabricante, data de instalação, responsável, estado operacional, identificação de outra aplicação na qual esteja contida;
iuTable {experimental 3} - unidades de software que compõem as aplicações instaladas: nome, versão, fabricante, número de série, data de instalação, nome do arquivo onde reside e respectivo tamanho, linguagem, sistema operacional onde roda;
cuTable {experimental 4} - instâncias de unidades instaladas de software para rodar no sistema: nome, versão, descrição, estado operacional, responsáveis pela configuração e pela operação, data da última carga;
procTable {experimental 5} - instâncias de unidades executáveis, ou processos ativos em um sistema de processamento: nome do processo, data e hora de início e término, estado operacional;
rProcTable {experimental 6} - unidades executáveis que compõem uma unidade de software configurada: nome do executável, diretório de localização, endereço IP de onde está localizado na rede, data instalação;
91
mboxTable {experimental 7} - filas de IPC-Inter Process Communication existentes no sistema de processamento, para prover comunicação entre aplicações distribuídas, contendo nome e status da fila;
fileTable {experimental 8} - arquivos contidos em uma unidade de software configurada: nome, tipo e descrição;
btaTable {experimental 9} - mapeamento entre as funções de negócio e as aplicações: descrição do mapeamento, responsável, data e hora da implantação;
atcuTable {experimental 10} - mapeamento entre as aplicações e unidades de software configuradas: endereços de rede da aplicação e unidades configuradas;
cutcuTable {experimental 11} - mapeamento entre duas unidades de software configuradas que mantêm relação de dependência entre si: tipo de associação, endereço de rede para localização da segunda unidade, tipo da associação;
ptmTable {experimental 12} - mapeamento entre processos e filas de IPC;
ptfTable {experimental 13} - mapeamento entre arquivos abertos e processos em execução;
ptpTable {experimental 15} - associação existente entre dois processos em execução: porta do processo local, endereço de rede e porta do processo remoto, tipo de assosciação, data e hora da associação;
iProcTable {experimental 16} - executáveis instalados em um sistema de processamento contendo nome, descrição, diretório onde está localizado no sistema, data de instalação, índice para as unidades de software à qual pertence.
A proposta do Bellcore é bastante complexa cobrindo praticamente todos
os apectos de uma aplicação desde sua instalação, seu processamento e ainda mantendo por um período de tempo às informações sobre as aplicações cujo processamento tenha encerrado. No entanto, não mostra indicadores de desempenho das transações da aplicação. A proposta ao IETF, por sua vez, é de uma MIB muito básica, que praticamente trata da configuração da aplicação enquanto instalada e reporta o seu estado operacional em fase de execução no sistema de processamento.
92
Analisado o cenário exposto, a proposta deste trabalho é a definição de uma MIB proprietária para a Rede Integrada, conforme o modelo descrito no capítulo 6. Aquela estrutura de informação deverá ser implantada de forma comum a todas as aplicações que, pela sua importância na rede, venham a ser gerenciadas. Para cada aplicação que precise gerenciar objetos não existentes na MIB comum, adotar-se-á a filosofia dominante na arquitetura SNMP, de desenvolver uma extensão da MIB comum para o agente da aplicação. Isto é possível para um dos tipos de aplicações existentes na rede corporativa, que são as que implementam os sistemas de informação do Estado. Como nestes casos o desenvolvimento é realizado pelas respectivas equipes, é possível desenhar uma MIB e incorporar um agente para sua disponibilização. A MIB proprietária genérica para as aplicações desenvolvidas no âmbito da Rede Integrada será registrada na árvore proprietária com a identificação aplicacao {celepar 10} e terá a estrutura de objetos abaixo, cuja descrição formal encontra-se no Anexo 1:
sistema {aplicacao 1} -- sistema ou negócio ao qual pertence marca {aplicacao 2} -- marca/fabricante modelo {aplicacao 3} -- modelo descricao {aplicacao 4} -- descrição textual da aplicação nomeApl {aplicacao 5} -- nome da aplicação para o sistema versao {aplicacao 6} -- versão em utilização local {aplicacao 7} -- nome do local onde roda responsavel {aplicacao 8} -- responsável no local ultimoStart {aplicacao 9} -- data e hora de último início de execução estadoOperacional {aplicacao 10} -- estado operacional conexApMaximas{aplicacao 11} -- número máximo conexões simultâneas conexApAtivas {aplicacao 12} -- número conexões ativas no momento conexApRealizadas {aplicacao 13} -- total de conexões realizadas conexApRejeitadas {aplicacao 14} -- total de conexões não efetivadas conexApNegadas {aplicacao 15} -- tentativas de conexão não autorizadas usuarioTable {aplicacao 16} -- tabela de usuários conectados usuarioEntry {usuarioTable 1} usuarioAtivo {usuarioEntry 1} -- identificação do usuário transacaoTable {aplicacao 17} -- tabela de transações da aplicação transacaoEntry {transacaoTable 1}
93
nomeTr {transacaoEntry 1} -- nome da transação conexTrAtivas {transacaoEntry 2} -- conexões ativas no momento conexTrRealizadas {transacaoEntry 3} -- total de conexões realizadas conexTrNegadas {transacaoEntry 4} -- tentativas de conexão não autorizadas quantTransacoes {transacaoEntry 5} -- total de transações executadas tempoRespTr {transacaoEntry 6} -- tempo de resposta médio da transação transacoesAbortadas {transacaoEntry 7} -- quantidade de transações abortadas parceiraTable {aplicacao 18} -- aplicações parceiras na rede parceiraEntry {parceiraTable 1} aplicPar {parceiraEntry 1} -- nome da aplicação parceira enderecoRede {parceiraEntry 2} -- endereço de rede onde roda
Para um outro segmento, o que inclui as aplicações caracterizadas por pacotes de software adquiridos no mercado, não é possível incorporar agentes, pois os códigos das mesmas não são disponibilizados pelo fornecedor. Neste caso, para a Rede Integrada do Estado, o gerenciamento será realizado apenas para as aplicações atuais que possuirem agentes que implementem MIB SNMP. A existência de condições de gerenciamento passará a ser requisito obrigatório nas aquisições futuras, desde que exista alternativa de mercado.
Na sequência são mostradas duas propostas visando a implementação de gerenciamento SNMP para aplicações, sendo uma para sistema de informação desenvolvido pela Celepar e uma para pacote de software adquirido no mercado. A próxima etapa será a definição de prioridades de implantação, pois existe uma série de aplicações importantes na Rede Integrada que devem passar a ser gerenciadas a partir da experiência com estes dois modelos iniciais.
SISTEMA DE INFORMAÇÃO DE VEÍCULOS DO DETRAN
Como colocado acima, cada aplicação importante na Rede Integrada deve implementar um MIB proprietária padrão no Estado e extensões com características particulares da aplicação, se for o caso. A aplicação que faz parte da amostra deste
94
trabalho é o Sistema de Informação de Veículos do Detran. Esta aplicação, desenvolvida na arquitetura cliente-servidor, será implantada ainda em 1996 em 75 municípios do estado. Em cada um destes locais será implantado um módulo da aplicação em um sistema de processamento Windows/NT, com o módulo servidor respondendo no sistema de processamento RISC/AIX da Celepar, através da rede X.25. Nas estações de trabalho Windows de cada rede local estarão rodando as aplicações de interface com o usuário.
Serão gerenciados todos os módulos da aplicação no sistema Windows/NT e o módulo no servidor central RISC/AIX, não sendo implantado gerenciamento nas estações de trabalho por razões como as expostas mais adiante na análise dos sistemas de processamento. Para esta finalidade, a MIB aplicacao {celepar 10} acima descrita para a parte comum das aplicações da Rede Integrada satisfaz as necessidades iniciais de gerenciamento do Sistema de Informação de Veículos do Detran, de forma que não será necessário desenvolver uma extensão particular. Estas necessidades foram validadas junto à equipe de desenvolvimento do referido sistema.
SERVIÇO DE CORREIO ELETRÔNICO E AUTOMAÇÃO DE ESCRITÓRIOS
Um dos serviços importantes está sendo implantado na Rede Integrada de Comunicação de Dados e Serviços do Estado é o de Correio Eletrônico e Automação de Escritórios. Ele tem como objetivo agilizar o processo de comunicação entre os órgãos do governo, automatizando os processos da administração estadual em busca da eficiência dos serviços. Para implantação deste sistema foi adotada a estratégia de distribuição de servidores em 90 ambientes informatizados dos diversos órgãos na capital e interior do estado, totalizando 3.600 caixas postais. Nesta filosofia, a maior parte do tráfego para comunicação entre usuários ocorre na própria rede local do órgão, utilizando-se da rede de longa distância apenas para a comunicação entre usuários de órgãos diferentes. O sistema adotado para o correio eletrônico e automação de escritórios no Estado foi o Lotus Notes. O objetivo é o gerenciamento de todos os 90 servidores espalhados pela rede, não entrando também no mérito do gerenciamento das partes client que rodam nas estações de trabalho dos usuários.
95
Analisando as necessidades de informações de gerência para o sistema de correio eletrônico e automação de escritórios, em comparação com as informações da MIB aplicacao {celepar 10} constata-se que desta parte comum não há necessidade das informações do grupo dependeTable {aplicação 18}, porque cada servidor é autônomo em seu sistema de processamento na rede. O grupo transacaoTable {aplicação 17} também não faz sentido uma vez que a transação é única, ou seja recebimento e envio de mensagens e operando no conceito de armazena-envia. Por outro lado, existe a necessidade de objetos específicos para o gerenciamento de uma aplicação de correio eletrônico distribuído que são: nome do servidor, portas de acesso e respectivos protocolos de rede e estados operacionais, data e hora da última réplica do livro de endereços na rede, número de mensagens recebidas e enviadas pelo servidor; número de mensagens acumuladas no servidor, número de mensagens na fila para envio, área em disco alocada e utilizada.
Para gerenciamento de sistemas de correio eletrônico existe uma MIB [RFC1566] bastante simples, proposta como padrão em 1994, identificada pelo grupo de objetos denominado mta {mib-2 28}. Esta MIB complementa a MIB application {mib-2 27} para descrever aspectos específicos dos MTA-Message Transfer Agent em termos de quantidade de mensagens e de volumes de octetos recebidos, armazenados e enviados por servidor.
A aplicação Lotus Notes não utiliza estes padrões. Possui um sistema proprietário de gerenciamento dos seus servidores denominado Notes View, que disponibiliza ao mesmo tempo um agente SNMP com uma MIB proprietária [MIB-NTS]. A Lotus possui diversas MIBs proprietárias específicas para cada aplicação, identificadas na árvore da ISO pelo objeto lotus {enterprises 334}, sendo a MIB do Lotus Notes identificada pelo objeto notes {lotus 72}. Os OID dos objetos gerenciáveis do Notes possuem portanto o prefixo 1.3.6.1.4.1.334.72. Os grupos que interessam ao nosso modelo estão alocados nas sub-árvores:
lnInfo {notes 1}
lnStats {lnInfo 1 }
96
lnMail {lnStats 4} - quantidade de mensagens recebidas e enviadas, quantidade de mensagens na fila para entrega local e para envio para outros servidores;
lnServer {lnStats 6}
lnServerTask {lnServer 1} - estado operacional dos diversos processos que compõem o servidor;
lnServerInfo {lnServer 2} - nome do servidor, versão do Notes, sistema operacional, data e hora de início de execução, administrador do sistema;
lnServerStats {lnSever 3} - número de usuários ativos no momento; total de transações efetuadas e abortadas, número máximo de usuários concorrente já atingido;
lnComm {lnStats 7} - número de conexões rejeitadas por excesso de usuários; por porta: número máximo de usuários simultâneos, número de usuários atualmente conectados, estatísticas de pacotes corretos e com erros;
lnDatabase {lnStats 10} - tamanho das áreas alocadas para armazenamento do Notes e respectivas áreas já utilizadas;
lnReplication {lnInfo 2} - histórico das replicações: servidor com o qual replicou, data e hora do início e término da réplica,
lnControl {notes 2} - estado operacional do servidor, lista dos 10 últimos traps enviados.
Analisando a MIB proprietária pode ser constatado que a grande maioria
das informações desejadas para o gerenciamento do Lotus Notes está presente permitindo uma boa visão do comportamento dos servidores de correio. Dentre as necessidades identificada não foram encontradas a quantidade de acesso rejeitados por falta de autorização, o protocolo de rede em cada porta de acesso, o número de mensagens armazenadas no servidor e a lista dos usuários ativos em um dado momento. Estas adições serão sugeridas à Lotus para incorporação em novas versões.
97
7.2 GERENCIAMENTO DOS SERVIDORES DE BASES DE DADOS
Os Servidores de Bases de Dados são aplicações que possuem características específicas, prestando serviços às aplicações dos sistemas de informação corporativos. Da mesma forma que nas aplicações convencionais, pouco trabalho tem sido realizado pelo mercado em termos de disponibilização de padrões de gerência em sistemas abertos. Todos os produtos de mercado implementam uma gerência proprietária com um grande conjunto de informações destinadas aos administradores das bases de dados de uma organização, a quem compete o trabalho de gestão das bases de dados corporativas. Do ponto de vista da gerência de rede, a quantidade e o grau de detalhamento das informações de gerência é diferente do requerido pela administração das bases de dados, bastando um modelo simples que permita perceber os impactos do comportamento do Servidor de Bases de Dados no desempenho das aplicações na rede. Na filosofia de trabalho da Celepar, gerência de rede e administração de bases de dados são grupos distintos organizacionalmente.
A primeira MIB padrão para gerenciamento de servidores de bases de dados [RFC1697], proposta recentemente em 1994, define um conjunto de objetos para gerenciamento de servidores de bases de dados relacionais, estando identificada pelo objeto rdbmsMIB {mib-2 39}. Objetos adicionais necessários para o gerenciamento de servidores de bases de dados são encontrados na MIB application {mib-2 27} [RFC1565]. A estrutura da rdbmsMIB possui nove tabelas que estão alocadas sob um único grupo denominado rdbmsObjects {rdbmsMIB 1}:
rdbmsDbTable {rdbmsObjects 1} - descrição das bases de dados instaladas em um sistema de processamento, contendo objetos para identificar os nomes dos produtos e respectivos fabricantes, o responsável pela base de dados, o OID do número de registro na árvore enterprises da ISO para a MIB proprietária da base de dados, se esta existir;
rdbmsDbInfoTable {rdbmsObjects 2} - relação das bases de dados abertas em um dado momento em um sistema de processamento, descrevendo para cada uma o nome e a versão do servidor que a mantém, o tamanho de área alocada e utilizada e data do último backup;
98
rdbmsDbParamTable {rdbmsObjects 3} - tabela com os parâmetros de configuração de cada base de dados contendo basicamente o nome de cada parâmetro e seu conteúdo atual, além de uma descrição do parâmetro, assim como um OID para o caso de existir uma descrição externa para o mesmo;
rdbmsDbLimitedResourceTable {rdbmsObjects 4} - limitadores de utilização de recursos das bases de dados, contendo o nome do limitador e seu valor limite, os valores atual e máximo atingido, bem como a quantidade de vezes em que ocorreram tentativas de extrapolar o valor limite;
rdbmsSrvTable {rdbmsObjects 5} - descrição dos servidores de acesso instalados em um sistema de processamento, contendo as mesmas informações da rdbmsDbTable, porém a nível de servidor; um servidor pode acessar diversas bases de dados, assim como uma base de dados pode ser acessada por diversos servidores;
rdbmsSrvInfoTable {rdbmsObjects 6} - relação dos servidores ativos em um dado instante, reportando o número de transações realizadas, quantidades de operações de leitura e gravação realizadas nas bases de dados, número máximo de associações possíveis e maior valor atingido; informações como a quantidade de associações atuais, estado operacional, associações rejeitadas, são obtidas da tabela applTable citada acima;
rdbmsSrvParamTable {rdbmsObjects 7} - parâmetros de configuração de cada servidor, com informações nos mesmos moldes da rdbmsDbParamTable;
rdbmsSrvLimitedResourceTable {rdbmsObjects 8} - limitadores de recursos dos servidores com informações da mesma natureza da rdbmsDbLimitedResourceTable;
rdbmsRelTable {rdbmsObjects 9} - relação entre bases de dados e respectivos servidores de acesso ativos em um sistema de processamento em um dado momento, contendo o status da relação e sua duração.
A rdbmsMIB atende muito bem as necessidades do modelo para descrever
o comportamento dos servidores de bases de dados no que diz respeito ao servidor de acesso em si. Como um servidor acessa várias bases de dados não são encontrados objetos para informar sobre as atividades de acesso realizadas sobre cada uma das bases de dados. Tendo em vista a não existência de MIBs proprietárias para estes elementos, é
99
proposto o desenvolvimento de um sub-agente para complementar a referida MIB o qual será identificado por rdbmsMIBExt {celepar 2}, prefixo 1.3.6.1.4.1.1661.2, com a estrutura mostrada a seguir e descrita formalmente no Anexo 1:
servidorTable {rdbmsMIBExt 1} -- complementa a rdbmsSrvInfoTable servidorEntry {servidorTable 1} conexoesNegadas {servidorEntry 1} -- contador de acessos não autorizados transaçõesAbortadas {servidorEntry 2} -- contador de transações abortadas baseDadosTable {rdbmsMIBExt 2} -- complementa a rdbmsDbInfoTable baseDadosEntry {baseDadosTable 1} conexoesAtivas {baseDadosEntry 1} -- conexões ativas no momento conexoesRealizadas {baseDadosEntry 2} -- contador de conexões atendidas conexoesNegadas {baseDadosEntry 3} -- contador de acessos não autorizados tempoRespTr {baseDadosEntry 4} -- tempo médio resposta para transacões quantTransacoes {baseDadosEntry 5} -- contador de transações realizadas
Os dois principais servidores de bases de dados existentes na Rede Integrada são ADABAS e o SYBASE cujas condições para implementação de gerenciamento SNMP são analisadas na sequência.
ADABAS
Este servidor de bases de dados roda nos sistemas de processamento IBM-MVS que fazem parte do parque de computadores centrais da Celepar, está implementado desde 1981 e é atualmente responsável pela disponibilização de praticamete todas as bases de dados existentes para suportar os sistemas de informações corporativos do Governo do Estado. Pela sua arquitetura de armazenamento e de acesso ser constituída por tabelas, possui características muito semelhantes às dos sistemas relacionais, podendo ser utilizada uma MIB como a descrita acima para o seu gerenciamento, efetuadas eventuais adaptações conceituais necessárias.
100
O fabricante do ADABAS, a empresa Software AG {enterprises 1028}, disponibiliza atualmente um sistema proprietário de gerência mas não possui um agente para fornecer informações nos padrões SNMP. Como o gerenciamento do ADABAS é de extrema importância pela quantidade de aplicações para as quais é servidor, a proposta é o desenvolvimento de um agente para rodar no sistema de processamento IBM-MVS. Este agente será construído de forma a interfacear com o programa núcleo do Adabas e capturar as informações para disponibilizá-las na forma da estrutura de dados das MIBs rdbmsMIB e rdbmsMIBExt.
SYBASE
O servidor de bases de dados SYBASE encontra-se implementado nos servidores centrais RISC-AIX da Celepar desde 1995, para suporte às novas aplicações corporativas do Estado que são desenvolvidas na tecnologia cliente-servidor. Existem implementações também em alguns órgãos da administração estadual, em servidores para aplicações departamentais nas respectivas redes locais.
O fabricante do SYBASE, a empresa SYBASE Inc. {enterprises 897}, possui um agente SNMP que implementa as MIBs rdbmsMIB [RFC1697] e application [RFC1565] descritas anteriormente. Para este servidor de bases de dados a proposta é desenvolver um sub-agente do agente nativo do sistema operacional AIX para disponibilizar a rdbmsMIBExt {celepar 2}.
7.3 GERENCIAMENTO DOS SISTEMAS DE PROCESSAMENTO
Os sistemas de processamento constituem-se na base operacional para as aplicações que disponibilizam aos usuários os sistemas de informação corporativos em uma rede de computadores. De uma maneira geral qualquer sistema possui o seu gerenciamento proprietário para o sistema operacional e para os dispositivos de
101
hardware, os quais manipulam normalmente uma grande quantidade de informações que permitem os seus administradores controlar todos os recursos disponíveis.
O importante para a gerência da rede não é o conhecimento da totalidade das variáveis envolvidas em um sistema de processamento, pois da mesma forma que abordado para os Servidores de Bases de Dados, esta é uma atribuição dos administradores do sistema. O ideal é selecionar um pequeno número delas, como as descritas no modelo de informação proposto, que possam ser úteis para o gerente da rede, objetivando conhecer constantemente o comportamento do sistema de processamento, informar aos usuários da rede sobre problemas e tratar preventivamente junto aos respectivos administradores o desenvolvimento de ações no sentido de evitar ou minimizar impactos dos seus problemas sobre os usuários na rede.
O primeiro esforço para padronização de uma gerência de sistema de processamento em protocolos SNMP foi o desenvolvimento em 1991 de uma MIB para gerência de sistemas operacionais Unix [MIB-UNX], que se encontra alocada na árvore de MIBs proprietárias da ISO sob o grupo de objetos denominado unix {enterprises 4}, cujo prefixo para os OIDs é 1.3.6.1.2.1.4. Com o desenvolvimento desta MIB definiu-se também o padrão SMUX para possibilitar a multiplexação de agentes no sistema com a finalidade de permitir a implementação de novos objetos gerenciáveis para elementos de rede que residam no sistema. A estrutura da MIB unix é a seguinte:
mbuf {unix 2} - quantidade de mbufs alocados e disponíveis, por tipo, e número de requisições que tiveram problemas de alocação por falta de espaço;
smux {unix 4} - tabela dos sub-agentes SMUX implantados no sistema, denominados peers, identificados pelos respectivos OIDs, e tabela contendo os OIDs dos prefixos das árvores das MIBs disponibilizadas pelos sub-agentes. Ambas tabelas contém também o status do referido objeto;
netstat {unix 5} - extende as tabelas tcp {mib-2 6} e udp {mib-2 7}, para gerenciar a fila de octetos de entrada e saída em cada protocolo e a tabela ip {mib-2 4}, para informar o número de conexões TCP e UDP em cada rota do sistema, e outras informações sobre roteamento;
102
print {unix 6} - tabela das filas de impressoras com os respectivos tamanhos correntes e, para cada fila, a tabela das tarefas com as respectivas descrição, identificação do usuário e posição na fila;
users {unix 7} - tabela de usuários e de grupos de usuários no sistema, com respectivas descrição, identificação, senha criptografada e outras informações, e tabela de relação usuário-grupo.
A MIB unix não atende ao modelo proposto, pois deixa de implementar a maioria das informações necessárias para que o administrador da rede tenha uma visão geral sobre o comportamento de um sistema UNIX, principalmente na gerência dos processos e do sistema de armazenamento. Além disso, a sua aplicação é restrita aos sistemas UNIX, quando na rede corporativa existem outros tipos de sistemas de processamento a serem gerenciados.
Para utilização em qualquer tipo de sistema de processamento, foi desenvolvida uma nova MIB [RFC1514] denominada Host Resources MIB, proposta em 1993, a qual é identificada pelo grupo de objetos host {mib-2 25}, prefixo de OID 1.3.6.1.2.1.25. A definição desta MIB determina a utilização dos grupos system {mib-2 1} e interfaces {mib-2 2} para complementar as informações padronizadas a respeito dos sistemas de processamento. Sua estrutura é a seguinte:
hrSystem {host 1} - informações gerais sobre o sistema de processamento, contendo a data/hora de início de operação e a atual, a identificação do dispositivo de carga e os parâmetros de inicialização do sistema, número de processos máximo possíveis e atual, número de usuários ativos. Outras informacões obtidas do grupo system {mib-2 1} são o nome e a descrição do sistema, sua localização e o responsável;
hrStorage {host 2} - descreve as unidades de armazenamento do sistema com um objeto para representar a quantidade de memória principal e uma tabela com uma entrada para cada dispositivo, a qual contém em essência o seu tipo identificado por um OID, sua descrição, unidade de alocação, área total formatada e área utilizada, contador de falhas de alocação por falta de espaço;
103
hrDevice {host 3} - tabela de dispositivos conectados ao sistema de processamento, que possui uma parte comum que identifica o seu tipo através de um OID, descrição, identificação, status e contador de erros. Para cada instância desta tabela, em função do tipo do dispositivo, existe uma complementação com objetos específicos: para processadores são identificados o firmware e o percentual médio de ocupação; para interfaces de rede é identificado o índice que aponta para a respectiva instância no grupo interfaces {mib-2 2}; para impressoras a tabela é aumentada com o seu status e identificação de erros; para os discos existem três tabelas que adicionam objetos para identificar tipo de acesso permitido, tipo de mídia e capacidade, as partições de discos com respectivos tamanhos e indicação de qual sistema de arquivo a contém e por fim os sistemas de arquivos com os respectivos nomes, tipo do sistema, tipo de acesso permitido, data do último backup;
hrSWRun {host 4} - lista dos processos em execução no sistema, incluindo a identificação e a descrição de cada programa, o diretório de onde foi carregado, parâmetros de carga, tipo de programa, status;
hrSWRunPerf {host 5} - performance dos programas em execução contemplando para cada um os valores de utilização de processador e de memória principal do sistema;
hrSWInstalled {host 6} - programas instalados no sistema contendo o nome e a descrição, tipo de programa e data de instalação.
A MIB host possui um conjunto já bem mais completo para o gerenciamento de sistemas de processamento, que somado às MIBs system {mib-2 1}, para complementar as informações básicas do sistema, interfaces {mib-2 2}, ip {mib-2 4}, tcp {mib-2 6} e udp {mib-2 7}, estas três últimas para informações do estado dos protocolos de rede, atendem em grande percentual o modelo proposto no capítulo 6.
A proposta para uso em todos os tipos de sistemas de processamento na Rede Integrada é a utilização de um agente que implemente a MIB host acompanhado de um sub-agente que será desenvolvido para implementar uma extensão proprietária daquela MIB. Esta extensão será identificada na árvore de objetos proprietários por hostExt {celepar 1}, prefixo raíz 1.3.6.1.4.1.1661.1, possui a estrutura definida abaixo e sua descrição formal documentada no Anexo 1:
104
processos {hostExt 1} -- complementação dos objetos de processos memoriaVirtual {processos 1} -- memória virtual utilizada indicePaginacao {processos 2} -- índice de paginação de memória procRejeitados {processos 3} -- processos rejeitados por falta de recursos acessosNegados {processos 4} -- tentativas de acesso não autorizados tmpAcesTable {processos 5} -- tabela de tempos de acesso a discos no sistema tmpAcesEntry {tmpAcesTable 1} tempoAcesso {tmpAcesEntry 1} -- tempo médio efetivo de acesso ao disco filasImpressao {hostExt 2} -- filas de impressão do sistema filasImprTable {filasImpressao 1} -- tabela das filas de impressão filasImprEntry {filasImprTable 1} nomeFila {filasImprEntry 1} -- nome da fila estadoOper {filasImprEntry 2} -- estado operacional da fila impressora {filasImprEntry 3} -- descrição da impressora que atende a fila quantServImp {filasImprEntry 4} -- quantidade de serviços em espera servImpTable {filasImpressao 2} -- tabela dos serviços nas filas de impressão servImpEntry {servImpTable 1} nomeServImp {servImpEntry 1} -- nome do serviço de impressão proprietario {servImpEntry 2} -- identificação do processo proprietário estadoOper {servImpEntry 3} -- estado operacional do serviço
Na sequência são analisadas as condições de implementação dos agentes com a MIB host e a extensão proprietária acima definida para o gerenciamento dos sistemas de processamento que existem atualmente implantados nos diversos órgãos da administração estadual, interconectados para troca de informações na Rede Integrada.
IBM-MVS
O sistema de processamento IBM-MVS atende atualmente a maioria dos sistemas de informação da administração estadual. São centenas de sistemas, alguns de grande porte com acesso a partir de centenas de terminais, além de uma série de processos de características de processamento do tipo batch, onde grandes volumes de
105
dados precisam ser tratados sequencialmente. Neste sistema as bases de dados são gerenciadas pelo Adabas e as transações acessadas para acesso pelos teminais são implantadas através do monitor de transações CICS-Costumer Information Control System. Este monitor deve ser uma das primeiras aplicações a serem estudadas na sequência para implantação no sistema de gerência da Rede Integrada.
O agente SNMP do sistema IBM-MVS foi desenvolvido utilizando o padrão DPI para a multiplexação de agente em sub-agentes, padrão este que foi inclusive proposto pela própria IBM. Na versão oferecida com o sistema operacional MVS-XA que é o caso do sistema da Celepar, o agente implementa a MIB-2 original [RFC1213] e uma MIB proprietária para atuar como proxy-agent de um equipamento de comunicação denominado IBM3172, que não faz parte do escopo deste trabalho. Nenhuma MIB de terceiros foi encontrada até o momento para prover o gerenciamento do sistema MVS.
Dada a importância deste sistema em função da quantidade de aplicações que nele rodam, e ainda que, para algumas delas serão futuramente desenvolvidos agentes para gerenciamento, a proposta é desenvolver um sub-agente para implantar a MIB host e a extensão proprietária hostExt, usando o conjunto de primitivas DPI fornecido com o SNMP do sistema IBM-MVS.
RISC-AIX
A Celepar possui um parque de sistemas de processamento UNIX em complementação ao parque de sistemas MVS, operando basicamente como servidores para aplicações desenvolvidas na filosofia cliente-servidor. Em alguns órgãos do Estado encontram-se também servidores UNIX para as redes locais, em um número pequeno que não excede uma dezena. A maioria deles, inclusive os da Celepar, são equipamentos RISC-6000 da IBM, suportados pelo sistema operacional AIX, razão pela qual suas MIBs foram escolhidas para análise neste trabalho.
O sistema operacional AIX da IBM implementa, da mesma forma que o IBM-MVS, o padrão DPI para multiplexação de agentes. Para gerenciamento do
106
sistema de processamento a única MIB fornecida com o agente SNMP é a MIB-2 original e a MIB unix. Para prover objetos que permitam um gerenciamento mais efetivo do sistema AIX, existe pelo menos um fabricante no mercado, a Empire Technology Inc. identificada na árvore por empiretech {enterprises 546}, que fornece um agente para gerenciamento de sistemas UNIX implementando a MIB host, além de uma extensão proprietária que não é revelada publicamente. Como estará disponível para o sistema RISC-AIX ao longo deste ano, este agente, até o momento o único encontrado no mercado, é a alternativa escolhida para implantação do gerenciamento destes sistemas, a menos que alternativas mais interessantes surjam até o momento da implantação. Este agente é do tipo que roda de forma autônoma no sistema recebendo as requisições de operações de gerência em uma porta diferente da porta 161, o que, segundo o fabricante, é suportado pela maioria dos sistemas de gerência no mercado.
O desenvolvimento do sub-agente para implementação da extensão proprietária hostExt será realizado utilizando as APIs fornecidas pela IBM e implementado como sub-agente do agente nativo do sistema. Caso a extensão da MIB empiretech implemente os objetos equivalentes aos da extensão proprietária da Celepar, este sub-agente não será desenvolvido.
Windows/NT
Os sistemas de processamento Windows/NT têm experimentando um crescimento muito grande na Rede Integrada do Estado, no segmento de servidores para redes locais, somando-se aos servidores Netware e Unix. O fenômeno de crescimento de mercado a nível mundial reflete-se no Estado, pois a maioria das novas instalações em processo de implementação na Rede estão utilizando o Windows/NT como servidor. Por isto deve ser dada importância significativa à exploração das capacidades de gerenciamento deste sistema.
O agente principal SNMP desenvolvido para o sistema Windows/NT, com a finalidade de multiplexar diversos sub-agentes para o sistema de gerência, não possui instrumentação para qualquer MIB, sendo constituído apenas do processo de comunicação SNMP com o sistema de gerência. Os sub-agentes é que implementam as
107
MIBs comunicando-se com o agente pricipal através de um conjunto de APIs proprietárias que são fornecidas com o kit de desenvolvimento do sistema. Para cada elemento de rede residente em um servidor Windows/NT que se deseje gerenciar pode então ser desenvolvido um sub-agente para tratamento da respectiva MIB.
São fornecidos atualmente com o agente principal sub-agentes para tratamento da MIB-2 e de outros de serviços não contemplados no escopo deste trabalho, como por exemplo, para o gerenciamento do sistema Lan Manager. As MIBs proprietárias estão alocadas na sub-árvore microsoft {enterprises 311}. Não existe um sub-agente com MIB para a gerência do sistema de processamento Windows/NT fornecida com o agente principal. O encaminhamento a ser dado para este sistema é o mesmo do sistema RISC-AIX, pois a Empire deve portar para o sistema Window/NT, ainda este ano, o mesmo agente disponibilizado para os sistemas Unix. Vale também aqui a alternativa de surgimento em um futuro próximo de algum agente alternativo que seja mais adequado.
Netware
O Netware é um sistema largamente utilizado como servidor para redes locais na Rede Integrada, existindo perto de uma centena de sistemas atualmente implantados, tendo no entanto o seu crescimento contido a partir do surgimento do Windows/NT. Pelo tamanho do parque atual, é importante que seus recursos sejam também incorporados ao sistema de gerência SNMP.
O agente fornecido com o sistema já implementa a MIB host {mib-2 25} conforme a [RFC1514], uma extensão proprietária desta MIB e ainda uma MIB proprietária completa para gerenciamento dos servidores Netware [MIB-NET]. A Novell está registrada na árvore da ISO pelo identificador novell {enterprises 23}, prefixo de OID 1.3.6.1.4.1.23, com a descrição de suas MIBs alocada no ramo identificado por mibDoc {novell 2}. A extensão proprietária da MIB host, denominada nwHostExtensions {mibDoc 27} disponibiliza informações concernetes ao nível físico tais como discos, interfaces, e alguns objetos para identificação de impressoras, não sendo suficiente para cobrir o modelo proposto para a extensão hostExt {celepar 1}.
108
A MIB proprietária para gerenciamento do servidor Netware, denominada nwServer {mibDoc 28}, possui diversos grupos de objetos. Como a opção adotada será a MIB host, apenas serão utilizados da MIB proprietária os objetos para o gerenciamento das filas de impressão, que estão alocados sob o grupo nwQueue {nwServer 4} que é constituído por:
nwQueueTable {nwqueue 2} - identificação das tabelas de filas do Netware, incluindo as de impressão, contendo o nome, estado, quantidade de serviços;
nwQueueJobTable {nwqueue 3} - lista dos serviços em cada fila identificando o nome, posição na fila, tamanho, usuário;
nwQueueServerTable {nwQueue 4} - lista dos servidores das filas com respectivos nome e estado operacional.
Com a utilização da MIB proprietária da Novell para gerenciamento das filas de impressão, a construção do agente para a extensão hostExt fica simplificada, pois este coletará apenas as informações sobre processos rodando no sistema.
O agente principal pode ser multiplexado para permitir a incorporação de sub-agentes para instrumentação de MIBs para as aplicações que serão gerenciadas nos sistemas Netware. A comunicação entre o agente principal e os sub-agentes é realizada também através do uso de APIs proprietárias fornecidas com kit de desenvolvimento do sistema ManageWise, que é o sistema proprietário de gerência do Netware e que disponibiliza em paralelo as MIBs propritárias SNMP.
Windows
Equipamentos com processadores do tipo Intel 386/486/Pentium com ambiente operacional Windows constituem-se nos sistemas de processamento para as milhares de estações de trabalho que interconectam-se através das diversas redes locais espalhadas pelos órgãos da administração estadual.
109
Em relação aos sistemas de processamento, o modelo de gerência proposto neste trabalho concentra seus objetivos nos sistemas servidores acima estudados, porque o desempenho deles impacta o desempenho dos sistemas de informação na Rede Integrada. Cada um destes servidores pode atender conexões de um número muito grande de estações de trabalho espalhadas pela rede. Já as estações de trabalho impactam apenas o desenvolvimento dos serviços localmente no órgão, e o seu comportamento é observado diretamente pelo usuário, que pode acionar os serviços de suporte operacional local para a correção de problemas.
Por estas razões, e pelo fato do SNMP não implementar gerência distribuída, o que congestionaria os canais de comunicação, neste modelo inicial de gerência não está sendo cogitada a implementação de agentes para gerenciamento de estações de trabalho individuais. Futuramente, quando os conceitos de work-group forem mais disseminados, onde qualquer estação de trabalho pode ser um servidor para outras estações de trabalho, locais ou remotas, será necessário definir um grupo de objetos a ser gerenciado em cada estação de trabalho. O desenvolvimento dos procedimentos de gerência para estações de trabalho é uma das atividades do Desktop Management Task Force do IETF.
7.4 GERENCIAMENTO DOS ROTEADORES
Os roteadores utilizados na interconexão das sub-redes dos órgãos da administração estadual possuem capacidade de roteamento para múltiplos protocolos de rede. Por suas características de padrão aberto, o IP foi o protocolo escolhido para roteamento na Rede Integrada. A interconexão entre duas sub-redes pode ser efetuada diretamente ponto-a-ponto ou então através da rede X.25, encapsulando o protocolo IP dentro dos protocolos X.25, em conformidade com a [RFC1226].
Existem atualmente dois tipos de roteadores implantados no Estado. Os roteadores classificados como do tipo interno são utilizados para a interconexão das redes locais com servidores Netware ou Windows/NT à Rede Integrada. São compostos
110
por uma placa para comunicação síncrona e por um software de roteamento, residentes em um dos servidores da rede local, o qual assume também a função de roteador. Exemplos deste tipo são os produtos EICON, escolhidos como amostra neste trabalho por repesentarem a grande maioria das instalações, e o produto denominado Netware Multiprotocol Router.
O outro tipo de roteadores, classificados como externos, possui utilização para a interconexão de qualquer tipo de rede local, independente do seu sistema operacional, porque diferentemente dos tipos anteriores estes roteadores são conectados diretamente ao barramento da rede local. A escolha dos rotedores CISCO para análise neste trabalho é devido ao fato de que praticamente todos os roteadores externos atualmente existentes na rede são desta marca.
EICON
Para as redes locais Netware a EICON possui um produto denominado InterConnect Server e para as redes Windows/NT um produto denominado WAN Services. Por serem elementos cujos módulos de software para roteamento são executados no servidor Netware ou Windows/NT, os produtos incorporam um sub-agente SNMP, para tratamento das MIBs que modelam os serviços de roteamento. O sub-agente EICON relaciona-se com o sistema de gerência através do agente SNMP do respectivo sistema operacional do servidor de rede, no conceito de multiplexação de agente, na forma abordada anteriormente.
O sub-agente da EICON implementa algumas MIBs padronizadas dentre as quais: MIB-2 [RFC1213], X.25-LAPB [RFC1381], X.25-PLP [RFC1382]. Além disso possui uma MIB proprietária para extender o gerenciamento a um número maior de objetos. A MIB proprietária da EICON está registrada na árvore da ISO sob a raiz identificada pelo objeto eicon {enterprises 434}, possuindo como prefixo dos seus OID a sequência 1.3.6.1.4.1.434. Dentre os grupos que compõem a MIB proprietária [MIB-EIC], são os seguintes os que possuem objetos que complementam o modelo proposto:
111
server {mibv2 1} - informações do servidor: estado operacional, versão do agente, réplica do grupo system {mib-2 1} e interfaces {mib-2 2};
card {mibv2 2} - placas de interface de comunicação: quantidade de placas e para cada placa: tipo, nome, estado operacional, número de portas, versão de software e hardware;
port { mibv2 3} - portas de comunicação: nome, estado operacional, placa, protocolo de enlace;
router {mibv2 8} - número de portas, portas usadas, pacotes e bits roteados total e por tipo de protocolo de rede, pacotes com erros por tipo; para cada porta: protocolo de rede, vazão de dados, endereço X.25 e IP, pacotes e bits roteados total e por tipo de protocolo de rede, pacotes errados classificados por tipo de erro;
CISCO
A CISCO implementa em seus roteadores uma série de MIBs padronizadas dentre elas e que interessam a este trabalho: MIB-2 [RFC1213], X.25-LAPB [RFC1381], X.25-Packet Level [RFC1382], Ethernet-like [RFC1398]. Para estender a lista de objetos cobertos pelas MIB padrão, a CISCO implementa uma MIB proprietária [MIB-CIS] cujas definições estão alocadas na árvore da ISO identificada pelo objeto denominado cisco {enterprises 9}. Assim os objetos gerenciados proprietários dos roteadores da CISCO têm como prefixo em seus OIDs a sequência 1.3.6.1.4.1.9. Dentre os grupos de objetos existentes na MIB proprietária, os citados na sequência, alocados na sub-árvore local {cisco 2}, descrevem extensões proprietárias para os grupos da MIB-2:
lsystem {local 1} - estende as descrições do sistema e acrescenta objetos para gerenciamento da utilização do processador, memória e buffers, gerenciamento das configurações do equipamento e de rede e ainda da placa de monitoração de ambiente elétrico e térmico do hardware;
linterfaces {local 2} - extensão das descrições das interfaces, contabilização dos erros classificados por tipo, contabilização dos pacotes por tipo de protocolo de rede roteado, quantidades de colisões e outras;
112
lip {local 4} - matriz de endereços IP de origem e destino realizando contabilidade de tráfego e controle de utilização das rotas estabelecidas;
O modelo básico de gerência de roteadores proposto neste trabalho pode
ser atendido pelas MIBs disponíveis nos equipamentos existentes no mercado. Refinamentos futuros do modelo são possíveis, pois constata-se que os equipamentos posuem MIB com uma grande quantidade de objetos e este número cresce a cada nova versão de software. Para exemplificar a abundância de objetos disponíveis para gerência de roteadores pode ser citado o caso da MIB proprietária da antiga Wellfleet [MIB-WEL], atual Bay Networks, um dos maiores fabricantes mundiais de roteadores, que possui algo próximo a 3.500 objetos.
Objetos de características muito específicas que não estejam descritos nas MIBs não podem, entretanto, ser incorporados aos roteadores pelo usuário. O agente que disponibiliza a MIB faz parte do software básico do equipamento, não estando seu código fonte disponível para modificações. Também não existe divulgada pelos fabricantes a possibilidade de instalação de sub-agentes para extensão das respectivas MIBs.
7.5 GERENCIAMENTO DOS COMUTADORES DE PACOTES
A comunicação de longa distância para interconexão entre os sistemas de processamento na Rede Integrada está implementada na modalidade de comutação de pacotes com base nos protocolos aderentes à recomendação ITU-X.25. Os comutadores X.25 atualmente instalados são do modelo PCP fabricados pela Telematics, compondo a Rede Pacpar da Telepar. O Estado contratou uma parcela desta rede formando uma rede virtual privativa, para uso como infra-estrutura para a sua rede corporativa, cujas portas de comutadores alocadas serão gerenciadas pelo sistema da Celepar. Como não existe uma perspectiva de modificação da estrutura de equipamentos de comutação de pacotes da rede a curto prazo, foi analisado, para efeitos deste trabalho, apenas este modelo de equipamento.
113
A gerência dos comutadores de rede PCP X.25 é realizada por meio de um sistema proprietário da Telematics denominado INF-Interactive Network Facilities, de forma que seu sistema de gerência pode visualizar e controlar todos os comutadores interligados na rede X.25. Como este sistema é bastante complexo e a incorporação de um agente SNMP comprometeria o desempenho dos comutadores para os serviços aos quais se destina executar, o fabricante optou pelo desenvolvimento de um proxy agent, instalado em um comutador do mesmo tipo especialmente configurado para esta finalidade.
Este comutador, conforme mostrado na Figura 7.1, exerce a função de gerência proprietária para toda a rede de comutadores interligados. Paralelamente, um agente SNMP nele instalado coleta as informações de gerência através do seu protocolo próprio e mapea-as para uma MIB SNMP proprietária [MIB-TEL], identificada na árvore de objetos da ISO por telematics {enterprises 230}. O agente implementa também parte dos objetos da MIB-2 original e as MIBs RS-232-Like [RFC1659] e X.25-Packet Level [RFC1382]. A MIB proprietária, cuja descrição formal não foi fornecida pelo fabricante, distribui seus objetos pelos grupos abaixo descritos, sob a sub-árvore identificada pelo objeto tmxX25 {telematics tmxPCP(2) tmxPCPv1(1) 2}, cujo prefixo raíz 1.3.6.4.1.230.2.1.2:
statistics - estatísticas do protocolo X.25 nível 1 e nível 2 linkConfiguration - configuração de enlaces logicalChannel - configuração e alocação de canais lógicos routeTables - tabelas de rotas callRegistration - informações de registro de chamadas callRedirection - configurações de redirecionamento de chamadas huntGroups - configuração e informações de membros de agrupamentos de endereços cug - configurações dos grupos fechados de usuários nua - configurações dos endereços de usuários da rede nui - configurações das identificações de usuários da rede
114
comutador Londrina comutador
Maringá
comutador Cascavel
comutador Curitiba
comutadorP. Grossa
Rede X.25proxyagent
gerente
SNMP
INF
Figura 7.1 - Esquema de Gerenciamento dos Comutadores X.25
Embora não tenha sido fornecida a descrição formal da MIB, a documentação informa que a MIB SNMP implementa todos os objetos disponíveis no sistema de gerenciamento proprietário do comutador. Desta forma, é bastante provável que o agente forneça todos os objetos necessários para atendimento ao modelo proposto no capítulo 6. Não existem meios para que o usuário possa estender a MIB proprietária da Telematics através da incorporação de novos objetos que eventualmente sejam necessários, pelo fato do agente fazer parte do software básico do sistema.
7.6 GERENCIAMENTO DOS CANAIS DE COMUNICAÇÃO
Os canais de comunicação são elementos de rede responsáveis pela interconexão de ambientes remotos de processamento. São constituídos por equipamentos do tipo modem, ou de transmissores óticos no caso de uso de fibra ótica, colocados nas dependências do usuário, e de meios físicos de telecomunicações para
115
interligá-los. Na Rede Integrada, os canais de comunicação interligam, via modem, os comutadores de pacotes entre si, roteadores aos comutadores de pacotes na rede X.25 e roteadores entre si nos circuitos ponto-a-ponto.
Os modems atualmente existentes na composição dos canais de comunicação utilizados na Rede Integrada não implementam agentes para gerenciamento SNMP. A gerência dos canais de comunicação deverá ser realizada através dos agentes implementados nos comutadores de pacotes e nos roteadores que são interligados através dos mesmos. As informações devem ser coletadas pelo gerente a partir das MIBs que modelam as interfaces de comunicação dos dois elementos de rede instalados nas pontas do canal de comunicação. São encontradas nos comutadores e roteadores do mercado, dentre outras, as MIBs interfaces {mib-2 2} [RFC1213], ifMIB {mib-2 31} [RFC1573], rs-232 {mib-2 33} [RFC1659] e MIBs proprietárias, que disponibilizam os objetos necessários para atender ao modelo proposto.
7.7 GERENCIAMENTO DOS CONCENTRADORES DE REDES LOCAIS
A Rede Integrada possui atualmente uma centena de redes locais em operação nos diversos órgãos da administração, interconectadas através de roteadores à rede de longa distância X.25. Esta parte do trabalho analisa a gerência da rede local apenas sob o aspecto das interconexões dos servidores e das estações de trabalho em cada ambiente, pois o gerenciamento dos sistemas operacionais de rede e das aplicações já foi abordado nas partes anteriores.
As interconexões físicas na rede local no Estado são realizadas por um sistema de cabeamento estruturado, de modo que todos os equipamentos são interconectados às interfaces de um equipamento concentrador de cabeamento. Dependendo do porte da rede local este concentrador pode ser apenas um hub ou conjunto de hubs interconectados em cascata, ou um concentrador de hubs implantado em um chassis.
116
A maioria das redes locais implantadas na Rede Integrada são de dimensões pequenas, até 50 equipamentos um servidor, e operam com padrão de interface do tipo ethernet, com protocolo CSMA-CD-Carrier Sense Multiple Access-Collision Detection. Com isto, praticamente inexistem elementos de rede do tipo switch ou bridge, normalmente utilizados para isolamento de tráfego e compatibilização de protocolos de enlace entre segmentos de rede. Por esta razão a análise de suas MIBs não fazem parte do escopo deste trabalho.
Estruturando as redes locais desta forma, a gerência do barramento pode ser efetuada a partir do seu concentrador, através da incorporação de um módulo de gerenciamento, onde residem os agentes e a MIB que modela o concentrador. É importante salientar, e isto ocorre na Rede Integrada onde existem configurações de pequeno porte, que muitos dos equipamentos mais simples do mercado não os possuem, não sendo possível desta forma o seu gerenciamento. Nestes casos terão que ser feitas substituições dos concentradores onde se justifique que a rede local deva ser gerenciada.
Com a perspectiva da gerência do barramento ser realizada pelo concentrador, não é necessário que as milhares de estações de trabalho existentes nas redes locais distribuídas pela rede corporativa possuam agentes SNMP. As informações de gerência são capturadas localmente pelo agente do concentrador ao analisar o barramento, organizadas em uma MIB e disponibilizadas de forma sumarizada para o gerente SNMP. Com isto evita-se um tráfego muito grande na rede de longa distância, normalmente de baixa velocidade, o que ocorreria se cada estação da rede local transmitisse as suas informações diretamente ao sistema de gerência centralizado
Para gerenciamento dos concentradores de rede local e de suas portas existe uma MIB padrão denominada Repeater MIB [RFC1516] identificada pelo grupo de objetos snmpDot3RptrMgt {mib-2 22}, estruturada em três grupos:
rptrBasicPackage {snmpDot3RptrMgt 1} - número máximo de grupos de portas possíveis no concentrador; para cada grupo de portas: descrição, estado operacional, quantidade de portas; para cada porta: o estado operacional;
117
rptrMonitorPackage {snmpDot3RptrMgt 2} - número de colisões no barramento; para cada grupo de portas: contadores de octetos, contadores de pacotes válidos e errados; para cada porta: contadores de octetos, contadores de pacotes válidos e errados classificados por tipo de erro;
rptrAddrTrackPackage {snmpDot3RptrMgt 3} - identificação do endereço que enviou pacote para uma determinada porta.
Com o objetivo de gerenciar de forma mais eficiente o desempenho do tráfego nos barramentos das redes locais foi desenvolvida e padronizada uma MIB denominada RMON-Remote Network Monitoring [RFC1757] [STA93A]. A definição desta MIB foi realizada em decorrência das informações do grupos interfaces [RFC1213] [RFC1573] e snmpDot3RptrMgt [RFC1516] da MIB-2 serem limitadas, não possibilitando uma visão global do conjunto dos equipamentos interconectados na rede local.
Um agente RMON realiza a leitura de todos os pacotes que passam pelo barramento, independente do endereço de destino, e captura as informações para a constituição da sua MIB SNMP, que é identificada na árvore de registro pelo objeto rmon {mib-2 16} e constituída por nove grupos:
statistics {rmon 1} - estatísticas básicas a respeito dos pacotes trafegados, pacotes com erros e colisões ocorridas no barramento da rede local; na [RFC1757] existe somente um sub-grupo denominado ehterStatsTable {statistics 1} devendo ser criados grupos para novas interfaces no futuro, como por exemplo token ring;
history {rmon 2} - enquanto o grupo de estatísticas apresenta uma situação pontual do tráfego, este grupo mantém uma tabela com dados históricos obtidos em intervalos de amostragem pré-definidos, contendo praticamente os mesmos objetos do grupo anterior. É dividido atualmente em dois outros grupos o historyControlTable {history 1} que define os parâmetros para as estatísticas e o etherHistoryTable {history 2}, que armazena as estatísticas para redes ethernet. No futuro devem ser criados novos sub-grupos para outros tipos de redes;
118
alarm {rmon 3} - definição do conjunto de valores limites de performance por objeto gerenciado na rede, denominados thresholds, a partir dos quais são gerados os alarmes;
hosts {rmon 4} - tráfego de entrada e saída individualizado por sistema de processamento interconectado à rede;
hostTopN {rmon 5} - tabela atualizada em períodos de tempo pré-estabelecidos que classifica os sistemas de processamento interconectados à rede por ordem de maior utilização de recursos. Existem diversos recursos que podem ser escolhidos para monitorar;
matrix {rmon 6} - matriz de análise de tráfego cruzado entre pares de sistemas de processamento na rede, a qual pode ser indexada por ordem de endereço MAC de origem ou de destino;
filter {rmon 7} - definição das condições a serem observadas para que um determinado pacote seja selecionado pelo monitor, com testes por conteúdo do pacote ou por seu status.
capture {rmon 8} - tabela para armazenamento dos pacotes quando uma condição estabelecida nas definições do filtro for satisfeita;
event {rmon 9} - descrição dos eventos associados aos alarmes definidos no respectivo grupo, podendo ser do tipo que origina um trap SNMP ou uma ação de log.
Existe uma diversidade de equipamentos do tipo concentrador de redes locais implantados na Rede Integrada. Como amostra para este trabalho foram escolhidos para análise das MIBs existentes os concentradores da Cabletron e da antiga Synoptics, agora Bay Networks. Estes são os modelos encontrados em maior quantidade e estão presentes nas redes locais de maior porte no Estado.
CABLETRON
A Cabletron possui uma linha de concentradores modular baseada em um chassis em cujos slots são alocados módulos específicos para realizar as diversas funções às quais o equipamento se destina. O agente SNMP implementa a MIB-2
119
original [RFC1213], a MIB Repeater [RFC1516] e a RMON [RFC1757]. Além disso implementa uma MIB proprietária [MIB-CTR], identificada na árvore de registro pelo objeto cabletron {enterprises 52}, possuindo os seus objetos o prefixo 1.3.6.1.4.1.52.
A árvore proprietária é bastante extensa e constituída por diversos grupos, sendo que alguns destes grupos possuem objetos definidos de forma redundante, aplicando-se cada grupo a certos tipos de equipamentos ou versões diferentes de sofware para um mesmo equipamento. Os objetos que complementam o modelo proposto estão alocados nos seguintes grupos:
ctPhysical { cabletron mibs(4) ctron(1) 1 }
repeaterRev4 {ctPhysical 1} - concentrador: nome, número de portas total e ativadas, quantidade de pacotes trafegados, quantidade de pacotes errados classificados por tipo de erro, quantidade de octetos trafegados, quantidade de colisões, quantidade de pacotes classificados por tamanho e por protocolo de rede, mapa de ocupação dos slots, definição de thresholds para emissão de alarme referente a excesso de tráfego, de erros e de colisões; para cada port group: nome, número de portas total e conectadas, estatísticas de tráfego e definições de alarmes com as mesmas informações acima; para cada porta: tipo, nome, indicação do port group, indicativo de instalada, estado operacional, estatísticas de tráfego e definição de alarmes com as mesmas informações acima;
chassis {ctPhysical 2} - chassis: identificação e caraterísticas, número de slots, tabela descritiva dos componentes inseridos no chassis, tabela descritiva dos slots, tabela das MIBs existentes para gerenciamento dos diversos componentes;
device {ctPhysical 5} - dispositivo de gerência: endereço IP, data e hora atual;
ctResource {ctPhysical 12} - processador em cada slot: tipo, velocidade, memória;
commom {cabletron commsDevice(1) 1}
commonRev1 {common 1} - dispositivo de gerência do concentrador: tipo, nome, endereço IP, data e hora corrente, endereço MAC;
120
repeater {cabletron commsDevice(1) 2}
repeaterRev1 {repeater 1} - concentrador: tipo, número de slots total e ocupados, número de portas total e ativadas, quantidade de pacotes trafegados, quantidade de pacotes errados classificados por tipo de erro, quantidade de octetos trafegados, quantidade de colisões no barramento, mapa de ocupação dos slots; definição de thresholds para alarme de excesso de tráfego, de erros e de colisões a nível de porta, de placa e de concentrador;
repeaterRev2 {repeater 2} - placa de portas: tipo e nome, número de portas total e conectadas, quantidade de pacotes trafegados, quantidade de pacotes errados classificados por tipo de erro, quantidade de octetos trafegados, quantidade de colisões; para cada porta: tipo do conector, indicativo de instalada, estado operacional, estatísticas de tráfego com as mesmas informações acima.
SYNOPTICS
Os concentradores da Synoptics possuem características de modularidade semelhantes aos da Cabletron. O seu agente SNMP implementa também as MIBs padrão MIB-2, Repeater, RMON e ainda uma MIB proprietária [MIB-SYN], identificada na árvore de registro pelo objeto synoptics {enterprises 45}, possuindo os seus objetos o prefixo 1.3.6.1.4.1.45. Dentre os existentes na árvore da Synoptics os seguintes grupos possuem objetos para completar o atendimento ao modelo proposto, alocados na sub-árvore products {synoptics 1}:
s3SnmpAgent {products 2} - descrição do agente implantado no concentrador: tipo, versão de software e hardware, slot onde reside, versão de MIB suportada, taxa de ocupação do processador, capacidade de memória, estado operacional do software e do hardware;
s3Series3000 {products 3}
s3000Chassis {s3Series3000 1} - chassis: tipo, tipo e versão do backplane, mapa de slots e respectivos tipos; para cada placa: tipo, versão, estado operacional;
121
s3000Ethernet - pacotes corretos trafegados e respectiva quantidade de octetos, quantidade de colisões, quantidade de pacotes errados classificados por tipo de erro, a nível de porta, de placa e do concentrador; endereço MAC de cada porta;
Os concentradores analisados permitem implantar o modelo proposto, pois contêm o conjunto de objetos suficiente para o atendimento de uma necessidade básica de gerência. Além disso, os objetos da MIB rmon somados aos objetos das MIBs proprietária constituem um conjunto grande de objetos para serem incorporados ao sistema de gerência nas evoluções futura, ou mesmo para análise local de problemas. Da mesma forma que outros equipamentos, os agentes são parte integrante do software do básico dos concentradores, e não possuem seus códigos fonte abertos aos usuários, não sendo possibilitado ao usuário incorporar às MIBs proprietárias novos objetos que sejam do seu interesse.
122
8 CONCLUSÕES
O desenvolvimento desta dissertação demonstra a viabilidade de implementação de um sistema de gerenciamento para uma rede corporativa baseado em padrões abertos, utilizando-se a arquitetura de protocolos de gerenciamento SNMP, parte integrante do Ambiente de Protocolos TCP/IP. Já para a arquitetura CMIS/CMIP do RM-OSI, arquiteturalmente uma solução mais avançada, a mesma consideração não é válida, pois existem óbices de ordem tecnológica para implementação de seus protocolos em elementos de rede de pequeno porte. Além disso percebe-se uma absoluta falta de investimento no mercado produtor para incorporação destes protocolos nos elementos de rede que têm capacidade para suportá-los, como por exemplo nos sistemas de processamento, que possuem cada vez mais performance e a um custo cada vez menor.
Constata-se entretanto, que a implantação de um sistema de gerência de uma rede em protocolos SNMP não é uma tarefa trivial e direta, simplesmente agregando objetos gerenciáveis à rede para serem acessados por uma estação de gerenciamento. A pesquisa realizada neste trabalho demonstra que as MIBs padrão estabelecidas no âmbito do IAB e implementadas nos elementos de rede não atendem a todas as necessidades de informação, pela sua simplicidade de definição. Nesta lacuna surge a necessidade dos fabricantes, até para conseguir um diferencial competitivo para seus produtos, desenvolverem extensões proprietárias destas MIBs, para melhor gerenciar seus equipamentos ou sistemas. Isto foi largamente encontrado em todas as linhas de produtos analisadas neste trabalho.
Os sistemas de gerência precisam estar equipados com ferramentas capazes de incorporar as MIBs proprietárias, dos diversos fabricantes e diversos tipos de elementos de rede, para possibilitar o acesso aos seus objetos. Neste conceito, as MIBs proprietárias propostas e documentadas para serem desenvolvidas pela Celepar para uso no âmbito restrito da Rede Integrada poderão ser acessadas por qualquer sistema de gerência que implemente protocolos SNMP. Isto é possível em virtude destas MIBs terem sido desenvolvidas em conformidade com as definições e procedimentos padrão estabelecidos pelas RFCs da SMI, apresentadas ao longo da dissertação.
123
A análise da disponibilidade de MIBs SNMP implantadas nos tipos de elementos de rede pesquisados, apresenta uma característica interessante. Nos equipamentos que implementam serviços até a camada 3 do RM-OSI, ou seja a camada de rede, existe uma abundância significativa de MIBs sejam elas padrão ou proprietárias. Analisando-se as camadas superiores, de transporte até aplicação encontra-se um divisor bem marcante pois as MIBs existentes são bem mais simplificadas, a grande maioria delas foram propostas há não mais que três anos e, ainda, pouco encontradas nos elementos de rede do mercado. No primeiro caso, existe um conjunto de objetos bem além do que precisa efetivamente ser gerenciado, enquanto que no segundo caso o conjunto está muito aquém do que a complexidade dos problemas em uma rede exigem.
Isto mostra que a preocupação dos desenvolvedores das tecnologias de gerência sempre foram mais voltadas para os apectos de infra-estrutura, deixando de lado por muitos anos aspectos relevantes da gerência dos sistemas e das aplicações, que são os responsáveis, afinal, pela disponibilização das informações e razão da existência das próprias redes. Espera-se que este trabalho, com sua proposta que demonstra a viabilidade de uma visão global de gerência em todas as camadas de uma rede, acrescente como contribuição, alguns ingredientes de motivação para que os gestores de redes corporativas encarem este desafio na busca de um desenvolvimento maior do mercado para a gerência de sistemas e aplicações. Os conceitos desenvolvidos e os resultados obtidos podem ser aplicados a qualquer tipo de organização, pois a natureza dos elementos envolvidos em qualquer rede corporativa é a mesma.
A gerência da rede corporativa deve ser encarado pelas organizações como um processo evolutivo, iniciando por uma tecnologia mais simples de protocolos de gerência e de especificação das estruturas de informação. A escolha do conjunto de objetos a serem gerenciados não deve ser inicialmente muito grande, porém deve cobrir os elementos em todas as camadas da rede, desde a camada física até a de aplicação. Na proporção em que os resultados se apresentam, demandas por novas informações passam a ser geradas, aumentando a complexidade do sistema e exigindo que recursos mais poderosos sejam agregados ao sistema.
124
Este trabalho concentrou-se no estudo do modelo de informação e de sua implementação através dos agentes, e respectivas MIBs, incorporados aos elementos de rede. Estudos futuros podem ser desenvolvidos em outros segmentos do tema de Gerência de Rede, sendo sugeridos:
• validação dos estudos realizados neste trabalho através da execução da implementação da gerência sobre os elementos escolhidos e na forma proposta, com análise dos resultados e levantamento dos benefícios reais obtidos pelo Governo do Estado;
• especificação de critérios para escolha de plataformas para sistema gerenciador de rede corporativa, de forma a suportar uma implementação em processo evolutivo, iniciando com um modelo simples e com possibilidade de crescimento para sistemas mais complexos, garantindo a preservação dos investimentos já realizados quando a complexidade da gerência da rede corporativa exigir saltos tecnológicos;
• definição dos papéis organizacionais para estruturação de uma área de gerência de rede eficiente em uma corporação;
• desenvolvimento formal do modelo de informação e implementação de um agente para gerência de uma aplicação utilizando arquitetura de protocolos CMIS/CMIP;
• estudos de performance comparativa das arquiteturas de protocolos CMIS/CMIP e SNMP;
• desenvolvimento de funções de gerência inteligentes, agregando conceitos de sistemas especialistas e inteligência artificial, de forma que o sistema possa identificar problemas e resolvê-los sem a intervenção humana, ou minimizando-a.
125
BIBLIOGRAFIA
[CAR92] CARVALHO, Tereza Cristina M. B. et all, "Gerência de Redes - Uma Abordagem de Sistemas Abertos", Makron, 1992.
[CAR94] CARVALHO, Tereza Cristina M. B. et all, "Arquiteturas de Redes de Computadores OSI e TCP/IP", Makron, 1994.
[COM91] COMMER, Douglas E., “Internetworking with TCP/IP”, Prentice-Hall, 1991.
[HEB92] HEBRAWI, Baha, “OSI Upper Layers Standards and Practices”, McGraw-Hill, 1992.
[ISO8649] ISO-IEC 8648, "Information Processing Systems - Open Systems Interconnection - Service Definition of the Association Control Service Element", 1988.
[ISO8824] ISO-IEC 8824, "Information Processing Systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1)", 1990.
[ISO9072] ISO-IEC 9072, "Information Processing Systems - Open Systems Interconnection - Service Definition of the Remote Operations Service Element", 1989.
[ITU-M3100] International Telecommunications Union, “M.3100 - Generic Network Information Model”, 1994.
[ITU-X200] International Telecommunications Union, “X.200 - Information Processing Systems - Open Systems Interconnection - Basic Reference Model (ISO-IEC 7498)", 1988.
[ITU-X700] International Telecommunications Union, "X.700 - Information Processing Systems - Open Systems Interconnection - Basic Reference Model Part 4 - Management Framework (ISO-IEC 7498-4)", 1989.
126
[ITU-X701] International Telecommunications Union, "X.701 - Information Technology - Open Systems Interconnection - System Management Overview (ISO-IEC 10040)”, 1991.
[ITU-X710] International Telecommunications Union, "X.710 - Information Technology - Open Systems Interconnection - Common Management Information Service Definition (ISO-IEC 9595)”, 1991.
[ITU-X711] International Telecommunications Union, "X.711 - Information Technology - Open Systems Interconnection - Common Management Information Protocol Specification (ISO-IEC 9596)”, 1990.
[ITU-X720] International Telecommunications Union, "X.720 - Information Technology - Open Systems Interconnection - System Management - Management Information Model (ISO-IEC 10165-1)”, 1991.
[ITU-X721] International Telecommunications Union, "X.721 - Information Technology - Open Systems Interconnection - System Management - Definition of Management Information (ISO-IEC 10165-2)”, 1991.
[ITU-X722] International Telecommunications Union, "X.722 - Information Technology - Open Systems Interconnection - System Management - Guidelines for the Definition of Managed Objects (ISO-IEC 10165-4)”, 1991.
[ITU-X730] International Telecommunications Union, "X.730 - Information Technology - Open Systems Interconnection - System Management - Object Management Function (ISO-IEC 10164-1)”, 1991.
[ITU-X731] International Telecommunications Union, "X.731 - Information Technology - Open Systems Interconnection - System Management - State Management Function (ISO-IEC 10164-2)”, 1991.
[ITU-X732] International Telecommunications Union, "X.732 - Information Technology - Open Systems Interconnection - System Management - Attributes for Representing Relationships (ISO-IEC 10164-3)”, 1991.
127
[ITU-X733] International Telecommunications Union, "X.733 - Information Technology - Open Systems Interconnection - System Management - Alarm Reporting Function (ISO-IEC 10164-4)”, 1991.
[ITU-X734] International Telecommunications Union, "X.734 - Information Technology - Open Systems Interconnection - System Management - Event Report Management Function (ISO-IEC 10164-5)”, 1991.
[ITU-X735] International Telecommunications Union, "X.735 - Information Technology - Open Systems Interconnection - System Management - Log Control Function (ISO-IEC 10164-6)”, 1991.
[ITU-X736] International Telecommunications Union, "X.736 - Information Technology - Open Systems Interconnection - System Management - Security Alarm Reporting Function (ISO-IEC 10164-7)”, 1991.
[ITU-X738] International Telecommunications Union, "X.738 - Information Technology - Open Systems Interconnection - System Management - Summarization Function (ISO-IEC 10164-13)”, 1992.
[ITU-X739] International Telecommunications Union, "X.739 - Information Technology - Open Systems Interconnection - System Management - Workload Monitoring Function (ISO-IEC 10164-11)”, 1992.
[ITU-X740] International Telecommunications Union, "X.740 - Information Technology - Open Systems Interconnection - System Management - Security Audit Trail Function (ISO-IEC 10164-8)”, 1992.
[ITU-X741] International Telecommunications Union, "X.741 - Information Technology - Open Systems Interconnection - System Management - Objects and Attributes for Access Control (ISO-IEC 10164-9)”, 1993.
[ITU-X742] International Telecommunications Union, "X.742 - Information Technology - Open Systems Interconnection - System Management - Accounting Meter Function (ISO-IEC 10164-10)”, 1992.
[ITU-X745] International Telecommunications Union, "X.745 - Information Technology - Open Systems Interconnection - System Management - Test Management Function (ISO-IEC 10164-12)”, 1992.
128
[LEI93] LEINWAND, Allan & FANG, Karen, “Network Management - A Practical Perspective”, Addison Wesley, 1993.
[MIB-BEL] BELLCORE, “Distributed Application MIB Definition”, FTP=ftp.emi-summit.com.
[MIB-IET] IETF Network Management Area - Application MIB Workgroup, “System Application MIB”, FTP=ftp.emi-summit.com.
[MIB-CIS] CISCO, “MIBs para Gerenciamento de Equipamentos Cisco”, FTP=ftp.cisco.com.
[MIB-CTR] CABLETRON, “MIBs para Gerenciamento de Equipamentos Cabletron”, FTP=ftp.cabletron.com.
[MIB-EIC] EICON, “MIBs para Gerenciamento de Roteadores EICON”, FTP=192.219.28.79.
[MIB-NET] NOVELL, “MIBs para Gerenciamento de Sistemas Netware”, Documentação do Sistema ManageWise.
[MIB-NTS] LOTUS, “MIBs para Gerenciamento SNPM do Lotus Notes”, Documentação do Sistema Notes View.
[MIB-SYN] SYNOPTICS, “MIB para Gerenciamento de Equipamentos Synoptics”, FTP=venera.isi.edu.
[MIB-TEL] TELEMATICS, “Telematics Information Bulletin - SNMP”, Documentação dos Equipamentos.
[MIB-UNX] ROSE, Marshall & SKLOWER, Keith, “BSD UNIX MIB”, FTP=venera.isi.edu, 1991.
[MIB-WEL] WELLFLEET, “MIB para Gerenciamento de Equipamentos WellFleet”, FTP=venera.isi.edu.
[RFC791] POSTEL, Jonathan, "Internet Protocol", Request for Comments 791, FTP=ds2.internic.net, 1981.
129
[RFC793] POSTEL, Jonathan, "Transmission Control Protocol", Request for Comments 793, FTP=ds2.internic.net, 1981.
[RFC1155] McCLOGHRIE, Keith & ROSE, Marshall, "Structure and Identification of Management Information for TCP/IP-based Internets", Request for Comments 1155, FTP=ds2.internic.net,1990.
[RFC1157] CASE, Jeffrey et all, "A Simple Network Management Protocol - SNMP", Request for Comments 1157, FTP=ds2.internic.net, 1990.
[RFC1212] ROSE, Marshall & McCLOGHRIE, Keith, “Concise MIB Definitions”, Request for Comments 1212, FTP=ds2.internic.net, 1991.
[RFC1213] ROSE, Marshall & McCLOGHRIE, Keith, "Management Information Base for Network Management of TCP/IP-based Internets - MIB II", Request for Comments 1213, FTP=ds2.internic.net, 1991.
[RFC1215] ROSE, Marshall, "A Convention for Defining Traps for Use with the SNMP", Request for Comments 1215, FTP=ds2.internic.net, 1991.
[RFC1226] KANTOR, B., "Internet Protocol Encapsulation of AX.25 Frames", Request for Comments 1226, FTP=ds2.internic.net, 1991.
[RFC1227] ROSE, Marshall, " SNMP MUX Protocol and MIB ", Request for Comments 1227, FTP=ds2.internic.net, 1991.
[RFC1354] BAKER, Fred, "The IP Forwarding Table MIB", Request for Comments 1354, FTP=ds2.internic.net, 1992.
[RFC1381] THROOP, D. & BAKER, Fred, “SNMP MIB Extension for X.25 LAPB”, Request for Comments 1381, FTP=ds2.internic.net, 1992.
[RFC1382] THROOP, D., “SNMP MIB Extension for X25 Packet Layer”, Request for Comments 1382, FTP=ds2.internic.net, 1992.
[RFC1398] KASTENHOLZ, Fank, “Definitions of Managed Objects for the Ethernet-like Interface Types”, Request For Comments 1398, FTP=ds2.internic.net, 1993.
130
[RFC1441] CASE, Jeffrey et all, "Introduction to Version 2 of Internet-standard Network Management Framework”, Request for Comments 1441, FTP=ds2.internic.net, 1993.
[RFC1447] CASE, Jeffrey & GALVIN. J, "SNMPv2 Party MIB”, Request for Comments 1447, FTP=ds2.internic.net, 1993.
[RFC1451] CASE, Jeffrey et all, "Manager to Manager MIB", Request for Comments 1451, FTP=ds2.internic.net, 1993.
[RFC1514] GRILLO, Pete & WALDBUSSER, Steven, “Host Resources MIB”, Request For Comments 1514, FTP=ds2.internic.net, 1993.
[RFC1565] KILLE, Steve & FREED, Ned, “Network Services Monitoring MIB”, Request For Comments 1565, FTP=ds2.internic.net, 1994.
[RFC1566] KILLE, Steve & FREED, Ned, “Mail Monitoring MIB”, Request For Comments 1566, FTP=ds2.internic.net, 1994.
[RFC1573] McCLOGHRIE, Keith & KASTENHOLZ, Frank, “Evolution of the Interfaces Group of MIB-2”, Request for Comments 1573, FTP=ds2.internic.net, 1994.
[RFC1592] WIJNEN, B. et all, "Simple Network Management Protocol Distributed Protocol Interface Version 2.0", Request for Comments 1592, FTP=ds2.internic.net, 1994.
[RFC1659] STEWART B., "Definitions of Managed Objects for RS-232-like Hardware Devices using SMIv2", Request For Comments 1659, 1994.
[RFC1697] BROWER, David et all, "Relational Database Management System (RDBMS) Management Information Base Using SMIv2", Request For Comments 1697, FTP=ds2.internic.net, 1994.
[RFC1757] WALDBUSSER, Steven, “Remote Network Monitoring Management Information Base” Request for Comments 1757, FTP=ds2.internic.net, 1995.
[RFC1902] CASE, Jeffrey et all, " Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", Request for Comments 1902, FTP=ds2.internic.net, 1996.
131
[RFC1905] CASE, Jeffrey et all, " Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", Request for Comments 1905, FTP=ds2.internic.net, 1996.
[RFC1907] CASE, Jeffrey et all, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)”, Request for Comments 1907, FTP=ds2.internic.net, 1996.
[RFC1908] CASE, Jeffrey et all, "Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework", Request for Comments 1908, FTP=ds2.internic.net, 1996.
[ROS90] ROSE, Marshall T., "The Open Book - A Practical Perspective on OSI", Prentice Hall Inc., 1990.
[ROS90A] ROSE, Marshall T., "The Simple Book - An Introduction to Management of TCP/IP-based Internets", Prentice Hall Inc., 1990.
[ROS95] ROSE, Marshall T. & McCLOGHERIE Keith, "How to Manage your Network Using SNMP”, Prentice Hall Inc., 1995.
[STA93] STALLINGS, William, “Network Management”, IEEE Computer Society Press, 1993.
[STA93A] STALLINGS, William, “SNMP, SNMPv2 and CMIP - The Practical Guide to Network Management Standards”, Addison Wesley, 1993.
[TAN92] TANG, Adrian & SCOGGINS, Sophia, "Open Networking with OSI", Prentice Hall Inc., 1992.
[WEI95] WEINSTOCK, Jon & STURM,Rick, “Application MIB: Taming the Software Beast”, Data Communications, novembro/1995, pg.85-92
132
ANEXO 1 - DESCRIÇÃO FORMAL DAS MIBs PROPOSTAS
MIB APLICAÇÃO MIB-APLICACAO DEFINITIONS ::= BEGIN IMPORTS OBJECT-TYPE FROM RFC-1212 enterprises FROM RFC1155-SMI DisplayString FROM RFC1213-MIB Counter, Gauge, IpAddress FROM RFC1155-SMI; DateAndTime ::= OCTET STRING (SIZE (8 | 11)) -- A date-time specification for the local time of day. -- This data type is intended to provide a consistent -- method of reporting date information. -- -- field octets contents range -- _____ ______ ________ _____ -- 1 1-2 year 0..65536 (in network byte order) -- 2 3 month 1..12 -- 3 4 day 1..31 -- 4 5 hour 0..23 -- 5 6 minutes 0..59 -- 6 7 seconds 0..60 (use 60 for leap-second) -- 7 8 deci-seconds 0..9 celepar OBJECT IDENTIFIER ::= { enterprises 1661} -- MIB para aplicacoes na Rede Integrada aplicacao OBJECT IDENTIFIER ::= {celepar 10} sistema OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "sistema ou negocio ao qual pertence" ::= {aplicacao 1} marca OBJECT-TYPE
133
SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "marca/fabricante " ::= {aplicacao 2} modelo OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "modelo" ::= {aplicacao 3} descricao OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "descricao textual da aplicacao" ::= {aplicacao 4} nomeApl OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "nome da aplicacao para o sistema " ::= {aplicacao 5}
versao OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "versão em utilizacao" ::={aplicacao 6}
local OBJECT-TYPE SYNTAX DisplayString ACCESS read-write STATUS mandatory DESCRIPTION "nome do local onde roda " ::={aplicacao 7}
responsavel OBJECT-TYPE SYNTAX DisplayString ACCESS read-write STATUS mandatory DESCRIPTION "responsavel no local " ::={aplicacao 8} ultimoStart OBJECT-TYPE
134
SYNTAX DateAndTime ACCESS read-only STATUS mandatory DESCRIPTION "data e hora do ultimo inicio de execucao" ::={aplicacao 9} estadoOperacional OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "estado operacional" ::={aplicacao 10} conexApMaximas OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "numero maximo conexoes simultaneas " ::={aplicacao 11} conexApAtivas OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "numero conexoes ativas no momento " ::={aplicacao 12} conexApRealizadas OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "total de conexoes realizadas " ::={aplicacao 13}
conexApRejeitadas OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "total de conexoes nao efetivadas " ::={aplicacao 14}
conexApNegadas OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "tentativas de conexao nao autorizadas " ::={aplicacao 15} usuarioTable OBJECT-TYPE
135
SYNTAX SEQUENCE OF UsuarioEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "tabela de usuários conectados " ::= {aplicacao 16} usuarioEntry OBJECT-TYPE SYNTAX UsuarioEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "descricao das linhas da tabela de usuarios " INDEX {usuarioAtivo} ::={usuarioTable 1} UsuarioEntry ::= SEQUENCE { usuarioAtivo DisplayString} usuarioAtivo OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "identificacao do usuario " ::={usuarioEntry 1}
transacaoTable OBJECT-TYPE SYNTAX SEQUENCE OF TransacaoEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "tabela de transacoes da aplicacao" ::={aplicacao 17}
transacaoEntry OBJECT-TYPE SYNTAX TransacaoEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "descricao das linhas da tabela de transacoes " INDEX {nomeTr} ::={transacaoTable 1}
TransacaoEntry ::= SEQUENCE { nomeTr DisplayString, conexTrAtivas Gauge, conexTrRealizadas Counter, conexTrNegadas Counter, quantTransacoes Counter, tempoRespTr INTEGER, transacoesAbortadas Counter} nomeTr OBJECT-TYPE
136
SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "nome da transaçao " ::={transacaoEntry 1} conexTrAtivas OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "conexoes ativas no momento " ::={transacaoEntry 2} conexTrRealizadas OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "total de conexoes realizadas " ::={transacaoEntry 3} conexTrNegadas OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "tentativas de conexao nao autorizadas " ::={transacaoEntry 4}
quantTransacoes OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "total de transacoes executadas " ::={transacaoEntry 5}
tempoRespTr OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "tempo de resposta medio da transacao em decimos de segundo" ::={transacaoEntry 6}
transacoesAbortadas OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "total de transacoes nao concluidas" ::={transacaoEntry 7} parceiraTable OBJECT-TYPE
137
SYNTAX SEQUENCE OF ParceiraEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "aplicacoes parceiras na rede " ::={aplicacao 18} parceiraEntry OBJECT-TYPE SYNTAX ParceiraEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "descricao das linhas da tabela de aplicacoes parceiras" INDEX {aplicacao} ::={parceiraTable 1} ParceiraEntry ::= SEQUENCE { aplicPar DisplayString, enderecoRede IpAddress} aplicPar OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "nome da aplicaçao" ::={parceiraEntry 1} enderecoRede OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION "endereco de rede onde roda " ::={parceiraEntry 2} END
138
COMPILAÇÃO DA MIB APLICAÇÃO
To: [email protected] Subject: Re: Compile MIB Date: Mon, 10 Jun 1996 15:36:24 -0700 From: tsunami <[email protected]> % mosy /tmp/mib17981.my mosy 7.2 #166 (yukinojo) of Wed Feb 7 12:12:42 PST 1996 MIB-APLICACAO types: DateAndTime MIB-APLICACAO identifiers: celepar aplicacao MIB-APLICACAO objects: sistema marca modelo descricao nomeApl versao local responsavel ultimoStart estadoOperacional conexApMaximas conexApAtivas conexApRealizadas conexApRejeitadas conexApNegadas usuarioTable usuarioEntry MIB-APLICACAO types: UsuarioEntry MIB-APLICACAO objects: usuarioAtivo transacaoTable transacaoEntry MIB-APLICACAO types: TransacaoEntry MIB-APLICACAO objects: nomeTr conexTrAtivas conexTrRealizadas conexTrNegadas quantTransacoes tempoRespTr transacoesAbortadas parceiraTable parceiraEntry MIB-APLICACAO types: ParceiraEntry MIB-APLICACAO objects: aplicPar enderecoRede % mold -d -f /tmp/mib17981a.defs mold: 52 definitions written to stdout # No errors were detected in your MIB
139
EXTENSÃO DA MIB RDBMS [RFC1697] RDBMS-MIB-EXT DEFINITIONS ::= BEGIN IMPORTS OBJECT-TYPE FROM RFC-1212 enterprises FROM RFC1155-SMI DisplayString FROM RFC1213-MIB Counter, Gauge, IpAddress FROM RFC1155-SMI rdbmsDbIndex FROM RDBMS-MIB applIndex FROM APPLICATION-MIB; celepar OBJECT IDENTIFIER ::= { enterprises 1661} -- Extensao da rdbmsMIB (RFC1697) para os SGBDs da Rede Integrada rdbmsMIBExt OBJECT IDENTIFIER ::= {celepar 2} servidorTable OBJECT-TYPE SYNTAX SEQUENCE OF ServidorEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "complementa a rdbmsSrvInfoTable " ::={rdbmsMIBExt 1} servidorEntry OBJECT-TYPE SYNTAX ServidorEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "descricao das entradas da extensao da tabela de servidores" INDEX {applIndex} ::={servidorTable 1} ServidorEntry ::= SEQUENCE { conexSrNegadas Counter, transacoesAbortadas Counter} conexSrNegadas OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "contador de acessos nao autorizados " ::={servidorEntry 1}
140
transacoesAbortadas OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "total de transacoes nao concluidas" ::={servidorEntry 2} baseDadosTable OBJECT-TYPE SYNTAX SEQUENCE OF BaseDadosEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "complementa a rdbmsDbInfoTable " ::={rdbmsMIBExt 2} baseDadosEntry OBJECT-TYPE SYNTAX BaseDadosEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "descricao das entradas da tabela de bases de dados " INDEX {rdbmsDbIndex} ::={baseDadosTable 1} BaseDadosEntry ::= SEQUENCE { conexBdAtivas Gauge, conexBdEfetuadas Counter, conexBdNegadas Counter, tempoRespTr Integer, quantTransacoes Counter} conexBdAtivas OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "conexoes ativas no momento" ::={baseDadosEntry 1} conexBdRealizadas OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "contador de conexoes atendidas " ::={baseDadosEntry 2}
141
conexBdNegadas OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "contador de acessos nao autorizados " ::={baseDadosEntry 3} tempoRespTr OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "tempo medio resposta para transacoes em decimos de segundo " ::={baseDadosEntry 4} quantTransacoes OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "contador de transacoes realizadas " ::={baseDadosEntry 5} END
142
COMPILAÇÃO DA EXTENSÃO DA MIB RDBMS To: [email protected] Subject: Re: Compile MIB Date: Tue, 18 Jun 1996 12:17:29 -0700 From: tsunami <[email protected]> % mosy /tmp/mib3238.my mosy 7.2 #166 (yukinojo) of Wed Feb 7 12:12:42 PST 1996 RDBMS-MIB-EXT identifiers: celepar rdbmsMIBExt RDBMS-MIB-EXT objects: servidorTable servidorEntry RDBMS-MIB-EXT types: ServidorEntry RDBMS-MIB-EXT objects: conexSrNegadas transacoesAbortadas baseDadosTable baseDadosEntry RDBMS-MIB-EXT types: BaseDadosEntry RDBMS-MIB-EXT objects: conexBdAtivas conexBdRealizadas conexBdNegadas tempoRespTr quantTransacoes % mold -d -f /tmp/mib3238a.defs mold: 32 definitions written to stdout # No errors were detected in your MIB
143
EXTENSÃO DA MIB HOST RESOURCES [RFC1514]
HOST-MIB-EXT DEFINITIONS ::= BEGIN IMPORTS OBJECT-TYPE FROM RFC-1212 enterprises FROM RFC1155-SMI DisplayString FROM RFC1213-MIB Counter, Gauge, IpAddress FROM RFC1155-SMI hrStorageIndex FROM HOST-RESOURCES-MIB; celepar OBJECT IDENTIFIER ::= { enterprises 1661} -- Extensao da Host Resources MIB (RFC1514) para os Hosts da Rede Integrada hostExt OBJECT IDENTIFIER ::= {celepar 1} processos OBJECT IDENTIFIER ::= {hostExt 1} memoriaVirtual OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "memoria virtual utilizada " ::={processos 1} indicePaginacao OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "indice de paginacao de memoria " ::={processos 2} procRejeitados OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "processos rejeitados por falta de recursos " ::={processos 3}
144
tmpAcesTable OBJECT-TYPE SYNTAX SEQUENCE OF TmpAcesEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "tabela de tempos de acesso a discos no sistema " ::={processos 4} tmpAcesEntry OBJECT-TYPE SYNTAX TmpAcesEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "descricao das entradas da tabela de tempos de acesso a disco" INDEX {hrStorageIndex} ::={tmpAcesTable 1} TmpAcesEntry ::= SEQUENCE { tempoAcesso INTEGER} tempoAcesso OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "tempo medio efetivo de acesso ao disco em milisegundos " ::={tmpAcesEntry 1} filasImpressao OBJECT IDENTIFIER ::= {hostExt 2} filasImprTable OBJECT-TYPE SYNTAX SEQUENCE OF FilasImprEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "tabela das filas de impressao do sistema de processamento" ::= {filasImpressao 1} filasImprEntry OBJECT-TYPE SYNTAX FilasImprEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "descricao das linhas da tabela de filas de impressao" INDEX {nomeFila} ::= {filasImprTable 1} FilasImprEntry ::= SEQUENCE { nomeFila DisplayString, estadoOper INTEGER, impressora DisplayString, quantServImp Gauge}
145
nomeFila OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "nome da fila " ::={filasImprEntry 1} estadoOper OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "estado operacional da fila " ::={filasImprEntry 2} impressora OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "descricao da impressora que atende a fila" ::={filasImprEntry 3} quantServImp OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "quantidade de servicos em espera " ::={filasImprEntry 4} servImpTable OBJECT-TYPE SYNTAX SEQUENCE OF ServImpEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "tabela dos servicos nas filas de impressao" ::={filasImpressao 2} servImpEntry OBJECT-TYPE SYNTAX ServImpEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "descricao das entradas da tabela de servicos na fila" INDEX {nomeFila, nomeServImp} ::={servImpTable 1} ServImpEntry ::= SEQUENCE { nomeServImp DisplayString, proprietario DisplayString, estadoOperImp INTEGER}
146
nomeServImp OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "nome do servico de impressao " ::={servImpEntry 1} proprietario OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "identificacao do processo proprietario " ::={servImpEntry 2} estadoOperImp OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "estado operacional do servico " ::={servImpEntry 3} END
147
COMPILAÇÃO DA EXTENSÃO DA MIB HOST RESOURCES To: [email protected] Subject: Re: Compile MIB Date: Tue, 18 Jun 1996 13:27:30 -0700 From: tsunami <[email protected]> % mosy /tmp/mib4110.my mosy 7.2 #166 (yukinojo) of Wed Feb 7 12:12:42 PST 1996 HOST-MIB-EXT identifiers: celepar hostExt processos HOST-MIB-EXT objects: memoriaVirtual indicePaginacao procRejeitados tmpAcesTable tmpAcesEntry HOST-MIB-EXT types: TmpAcesEntry HOST-MIB-EXT objects: tempoAcesso HOST-MIB-EXT identifiers: filasImpressao HOST-MIB-EXT objects: filasImprTable filasImprEntry HOST-MIB-EXT types: FilasImprEntry HOST-MIB-EXT objects: nomeFila estadoOper impressora quantServImp servImpTable servImpEntry HOST-MIB-EXT types: ServImpEntry HOST-MIB-EXT objects: nomeServImp proprietario estadoOperImp % mold -d -f /tmp/mib4110a.defs mold: 40 definitions written to stdout # No errors were detected in your MIB
