Home

Especificação de um Framework baseado em Componentes de

1. Figura 4 34 Exemplo 3 parte I 94 R3 monitor gHisterese1 gHisterese2 gAlarmest gLog pede grupolG fornece grupolG gt envia dados monitorados envia dados monitorados envia evento falha envia evento falha envia evento falh Figura 4 34 Exemplo 3 parte II 95 Cap tulo 5 Uma Proposta de Implementa o No cap tulo 4 especificamos um framework CO para a ger ncia de falhas Vimos como utilizar os componentes classes e interfaces especificados aproveitando toda a reusabilidade fornecida n o s em termos de implementa o mas tamb m em termos de an lise e de projeto Neste cap tulo os componentes vistos no cap tulo anterior s o mais detalhadamente descritos Na se o 5 1 discutimos o projeto interno dos componentes b sicos do framework Destacamos ent o aspectos internos de implementa o que tornam o framework capaz de executar conforme as caracter sticas gerais e espec ficas de cada aplica o de ger ncia de falhas como a utiliza o de padr es de projeto Gamma et al 1994 e a utiliza o de caracter sticas da linguagem de programa o Java utilizada para especifica o dos componentes Na se o 5 2 outras considera es
2. 2 1 2 Um GeradorDeAlarmes para gerar alarmes diante da ocorr ncia do evento que indica um potencial congestionamento no roteador R GeradorDeAlarmes implements EventoFalhaListener Serializable Implementando a interface EventoFalhaListener public void processaEventoFalha EventoFalhaEvent ef GeradorDeEventoFalha fonte ef getFonte Envia uma mensagem indicando a ocorr ncia da falha UL instancia enviaMensagem fonte get contatoResponsavel 2 2 Instancia o e configura o de componentes 2 2 1 Dois componentes ElementoGerenciadoSnmp para representar cada um dos servidores S e S2 86 S nome sl ufpb br endIp 150 165 75 172 nomeResponsavel Administrador contatoResponsavel admin dsc ufpb br prioridade prioridadeMedia S2 nome s2 ufpb br endIp 150 165 75 173 nomeResponsavel Administrador contatoResponsavel admin dsc ufpb br prioridade prioridadeMedia 2 2 2 Um GrupoInfoGerencia para agregar a informa o grupoIG a ser fornecida por S1 grupoIG addInfoGerencia InfoGerenciaSnmp Quant ConexoesAbertas tcpCurrEstab 2 2 3 Um GrupoInfoGerencia para agregar a informa o grupoIG gt a ser fornecida por S2 grupolG addInfoGerencia InfoGerenciaSnmp TaxaDe Trafego tcpOutSegs 2 2 4 Dois componentes Monitor monitor e monitor um para controlar a frequ ncia
3. Ev entoFalhaEv ent WoetFonte ESgetPrioridade ESsetPrioridade ESgetTimeStamp ESsetTimeStamp gera l GeradorDeEventoFalha WorioridadeAlta prioridadeMedia BorioridadeBaixa ev entoFalhaListeners WScriaEv entoFalha ee Ev entoFalhaListener remov eEv entoFalhaListener 4 4 envia MonitorEvent i E entoFalha 4 lt lt Interface gt gt w MonitorListener GeradorDeEv entoF alhaComHisterese Ev alorLimiar EprocessaDadosMonitorados BW alorRearm WoetLimiar R ESsetLimiar A QoetRearm Mo setRearm EBgetValorAtingido EBsetValorAtingido SgetNomeEv entoRearm EBsetNomeEventoRearm ESgetDescricaoEv entoRearm etDescricaoEv entoRearm ESgetPrioridadeEv entoRearm 8 setPrioridadeEv entoRearm ES eriticaOcorrenciaEv entoF alha q Figura 5 1 Diagrama de classes parte II EStostring ESgeiNome SsetNome ESgetResponsav el etResponsav el jet ContatoResponsav el EBsetContatoResponsav el ESgetDescricao ESsetDescricao etPrioridade e Prioridade etOrigem Eo EBgetDataUltimaOcorrencia EsetDataUltimaOcorrencia envia EventoFalhaEv ent lt lt lInterface gt gt EventoFalhaListener EprocessaEv entoFalha LOI TrapEvent rapLinkUp rapLinkDown rapColdStart rapWarmStart rapFalhaDe Autenticacao rapEs
4. Uma outra API de ger ncia escrita em C e similar ao SNMP Manager API pode ser encontrada em Mellquist 1997 22 String nomeHost String anjinho dsc ufpb br int porta 8085 Cria um objeto SnmpPeer para representar o agente remoto SnmpPeer roteadorA new SnmpPeer nomeHost porta Cria par metros para associar com o agente remoto Neste caso as comunidades de leitura e escrita est o sendo especificadas SnmpParameters params new SnmpParameters public private Configura o agente remoto de acordo com os par metros especificados RoteadorA setSnmpParam params Figura 3 3 Instanciando e configurando um agente SNMP Na figura 3 4 a aplica o instancia e configura uma sess o SNMP sess o atrav s da qual requisi es SNMP ser o feitas get por exemplo Um agente default roteadorA pode ser especificado de modo que requisi es feitas durante a sess o sem especificar um agente destino sejam enviadas para este agente Cada sess o pode ter seu comportamento configurado de acordo com um conjunto de op es Atrav s do m todo setPduFixedOnError por exemplo caso uma resposta requisi o contenha um erro devido obten o do valor de uma vari vel a vari vel com problema removida da lista de vari veis requisitadas lista e a requisi o automaticamente reenviada ao agente A aplica o usa a sess o criada e faz uma requisi o SnmpGet no modo
5. 3 2 9Um GeradorDeAlarmesHisterese gAlarmes para notificar sobre a ocorr ncia do congestionamento em R e um GeradorDeAlarmes gAlarmes para notificar sobre problemas nas interfaces dos roteadores vide exemplo 2 3 2 10 Um GeradorDeLogs glog para registrar as ocorr ncias descritas 3 3 Interconex o dos componentes 3 3 1 Associamos o ElementoGerenciadoSnmp R3 e o GrupoInfo Gerencia grupoIG ao Monitor monitor informando ao monitor qual informa o de ger ncia ele deve obter e de onde 3 3 2 Associamos os componentes ElementoGerenciadoSnmp R1 R2 e R3 ao ReceptorDeTrapsSnmp receptorDeTraps 92 3 3 3 Associamos os componentes GeradorLinkDown gLinkDonws gLinkDown2 e gLinkDown3 ao ReceptorDeTrapsSnmp receptorDeTraps para que eles verifiquem a ocorr ncia de problemas em cada um dos roteadores 3 3 4 Associamos os componentes GeradorDeEventoFalhaCom Histerese gHisteresel e gHisterese2 ao Monitor monitor para que gHisteresel e gHisterese2 obtenham o resultado da monitora o realizada pelo monitor 3 3 5 Associamos o Monitor monitor ao GeradorDeEventoFalha ComHisterese gHisteresel para que o monitor se auto reconfigure no momento em que uma indica o de congestionamento seja verificada 3 3 6 Associamos o CorrelatorDeEventoFalhaSupressao correlator ao GeradorLinkDown gLinkDown para que ele correlacione o eventos gerados por gLi
6. 13 respectivamente Outras classes e interfaces entretanto como as classes MonitorEvent Monitor e ReceptorDeTraps e as interfaces MonitorListener e Trap Listener possuem algumas caracter sticas importantes para o funcionamento interno do framework e portanto devem ser vistas mais detalhadamente Estas classes abstratas implementam a maioria dos m todos especificados pelas interfaces ElementoGerenciado e InfoGerencia de modo que ao inv s de implementar estas interfaces por inteiro o programador pode simplesmente estender as classes adaptadoras redefinindo apenas os m todos necess rios 98 5 1 1 Classes e Interfaces de Uso Interno Conforme lista a tabela 5 1 outras classes e interfaces at ent o n o citadas foram especificadas Trata se de classes e interfaces de uso interno do framework que servem para implementar parte da sua funcionalidade interna e que consegiientemente n o podem ser diretamente utilizadas pelo programador o caso das classes GeradorDeEventoFalha e MonitorEvent e das interfaces MonitorListenere TrapListener A classe GeradorDeEventoFalha uma superclasse da qual os geradores de eventos que identificam falhas na rede herdam todos os m todos e atributos Entretanto a sua funcionalidade reutilizada no momento em que o programador da aplica o estende uma de suas subclasses GeradorDeEventoFalhaLimiar ou GeradorDeEventoFalha Trap Novos componentes n
7. Adicionalmente uma proposta de implementa o fornecida 1 2 Escopo e Relev ncia Dentro dos objetivos propostos este trabalho apresenta como as aplica es de ger ncia podem ser desenvolvidas com base em diversas APIs e linguagens atualmente dispon veis Este estudo serve de base para caracterizar um n vel de abstra o mais adequado ao desenvolvimento de aplica es de ger ncia o qual n o fornecido pelas linguagens e APIs estudadas mas que deve ser fornecido pela solu o proposta a fim de atingir seu objetivo principal isto facilitar o desenvolvimento de aplica es de ger ncia de redes Por entender que a ger ncia de redes uma rea muito abrangente que envolve a realiza o de muitas tarefas em cada uma de suas sub reas funcionais julgamos necess rio delimitar melhor o dom nio do problema a fim de obter melhores resultados N o parece fact vel ter um nico framework que permita configurar a seguran a da rede e ao mesmo tempo identificar e corrigir as poss veis falhas que tenham ocorrido Um framework atende s necessidades de um conjunto bem definido de aplica es inseridas num dom nio de problema bem particular e a sua funcionalidade e aplicabilidade dependem da captura do comportamento gen rico compartilhado pelas diferentes aplica es que o utilizam Landin amp Niklasson 1998 Assim quanto mais bem delimitado o dom nio do problema mais bem caracterizadas as aplica es que dele f
8. nome LinkDown origem Ro prioridade prioridadeMedia gLinkDowns nome LinkDown origem Rs prioridade prioridade Alta 3 2 4 Um GrupoInfoGerencia para agregar a informa o grupoIG a ser fornecida por Rs grupoIG addInfoGerencia InfoGerenciaSnmp Pacotes DescartadosOut ipOutDiscards 3 2 5 Um MonitorInteligente monitor para controlar a frequ ncia de monitora o de Rs monitor periodo 1800s 91 3 2 6 Um componente GeradorDeEventoFalhaComHisterese gHisterese para verificar uma indica o de congestionamento em R e a partir do qual o MonitorInteligente monitor controlar sua frequ ncia de monitora o gHisterese nome IndicacaoDeCongestionamento origem Rs prioridade prioridadeMedia nomeEventoRearm SituacaoNormal prioridadeEventoRearm prioridadeBaixa rearm x limiar y gig grupolG 3 2 7 Um componente GeradorDeEventoFalhaComHisterese gHisterese para verificar o congestionamento em R3 a partir da informa o obtida do MonitorInteligente monitor gHisterese nome Congestionamento origem Rs prioridade prioridadeAlta nomeEventoRearm SituacaoNormal prioridadeEventoRearm prioridadeBaixa rearm x limiar z gig grupoIG 3 2 8 Um CorrelatorDeEventoFalhaSupressao correlator para correlacionar os eventos recebidos de Ro correlator contador 2 intervaloDeTempo 1800s
9. o associados a um protocolo de ger ncia particular e n o conta com as abstra es necess rias para que possa se concentrar na solu o desejada Sendo assim uma solu o que permita ao programador de aplica es de ger ncia se concentrar na obten o da funcionalidade b sica de sua aplica o deve fornecer abstra es de mais alto n vel que escondam do programador determinados aspectos de programa o com os quais ele realmente n o deve se preocupar e que representem conseqiientemente mecanismos mais elaborados para a realiza o de tarefas de ger ncia Trata se por exemplo de prover uma coleta autom tica de informa o de ger ncia na rede para fornecer mecanismos mais apropriados para a identifica o e diagn stico de falhas no caso espec fico da ger ncia de falhas ou mecanismos mais apropriados para a implementa o de pol ticas de seguran a no caso espec fico da ger ncia de seguran a Com isto espera se tornar o desenvolvimento de aplica es de ger ncia de redes uma tarefa mais simples e mais r pida 1 1 Objetivos da Disserta o Este trabalho tem como objetivo principal especificar uma solu o que facilite o desenvolvimento de aplica es de ger ncia de falhas em redes de computadores ao elevar o n vel de abstra o fornecido Em particular a solu o consiste de um framework baseado em componentes de software reutiliz veis ou simplesmente um framework CO Component Oriented
10. 2 2 1 O Padr o de Ger ncia Internet 2 O principal objetivo deste padr o de ger ncia reduzir ao m nimo o impacto causado pelas atividades de ger ncia nos elementos gerenciados Se a atividade de ger ncia n o compromete o desempenho dos dispositivos da rede ent o todos os dispositivos devem ser gerenci veis caso contr rio os fabricantes de roteadores switches modems e dispositivos em geral podem optar por n o implementar esta funcionalidade Portanto o processamento de ger ncia realizado nos agentes estritamente limitado Em contrapartida as esta es de ger ncia s o m quinas dedicadas a esta tarefa realizando fun es de ger ncia bem mais especializadas Segundo este padr o agentes s o vistos como cole es de vari veis escalares armazenadas numa base de dados virtual e todas as fun es de ger ncia se resumem monitora o e controle dos valores destas vari veis A informa o de ger ncia mantida por cada agente vari veis escalares definida atrav s do par SMI MIB Structure of Management Information Management Information Base A SMI Rose amp McCloghrie 1990b especifica regras para nomear cada vari vel uma sintaxe para descrever sua estrutura e regras para codific la Em particular vari veis s o descritas atrav s de um subconjunto da nota o ASN 1 Abstract Syntax Notation One ISO IEC 8824 1987 e codificadas atrav s de um conjunto b sico de regras chamado BER
11. es normalmente conhecido como gerente Em geral h apenas uma esta o de ger ncia por rede gerenciada Elemento gerenciado qualquer dispositivo da rede que possa ser gerenciado tais como hospedeiros roteadores switches interfaces de rede etc al m do software instalado no sistema O software presente nestes dispositivos respons vel por processar e responder os comandos de ger ncia enviados pela esta o de ger ncia chama se agente Protocolo de ger ncia usado pela esta o de ger ncia e demais elementos gerenciados para efetuar a troca de informa o de ger ncia Define opera es de monitora o READ e opera es de controle WRITE Informa o de ger ncia descreve o estado da rede A figura 2 1 mostra uma rede onde h uma esta o de ger ncia gerente e v rios elementos gerenciados ou agentes roteadores esta es de trabalho hubs switches impressora e computadores A troca de informa o de ger ncia feita atrav s da rede de acordo com determinado protocolo de ger ncia Para implementar a arquitetura descrita pela figura 2 1 e com o objetivo de obter uma ger ncia verdadeiramente integrada diferentes padr es surgiram ao longo do tempo A aten o est voltada para a estrutura o conte do e a manipula o da informa o de ger ncia Imagine por exemplo se a sintaxe e a sem ntica dos dados obtidos de cada elemento gerenciado dependesse do fabricante de cada dispositivo Con
12. ACTION desabilitaServidorRedundante Figura 3 11 Defini o de um evento ass ncrono Para modelar a funcionalidade da aplica o devem se definir estados de execu o atrav s do construtor STATE Um estado definido como uma cole o de eventos Quando uma aplica o est em determinado estado de execu o os componentes de monitora o de todos os eventos que constituem aquele estado est o ativos Sim es et al 1994 Se a falha correspondente a qualquer um dos eventos ativos ocorrer a a o associada quela falha executada e a aplica o passa para um novo estado Veja o exemplo a seguir E Opera oNormal EVENT ServidorForaDoAr NEW STATE EsperandoCorre o EsperandoCorre o EVENT ServidorOk NEW STATE Opera oNormal EVENT ServidorForaDoAr NEW STATE EsperandoCorre o Figura 3 12 Defini o de estados de execu o De acordo com a figura acima a aplica o monitora a ocorr ncia de uma falha estado Opera oNormal evento ServidorForaDoAr Uma vez que ela tenha ocorrido a aplica o deve habilitar um outro servidor que substituir o servidor com problemas ACTION corrigeFalha evento ServidorForaDoAr Neste momento a aplica o vai para o estado EsperandoCorre o onde deve esperar at que a falha seja efetivamente corrigida Quando ent o o servidor principal voltar ao seu estado de opera o nor
13. Event Correlation Services engine e para receberem os eventos de interesse aplica es devem se cadastrar no subsistema e especificar uma das tr s fontes de eventos poss veis a saber RAW a aplica o recebe todos os eventos recebidos pelo subsistema de eventos exceto aqueles oriundos do ECS CORR a aplica o recebe os eventos oriundos de um m dulo ECS espec fico ALL a aplica o recebe todos os eventos oriundos do subsistema de eventos e do ECS Tamb m poss vel obter a informa o de ger ncia armazenada no banco de dados do pr prio OpenView em vez de buscar informa o diretamente no agente Neste caso uma outra API a OVW API OpenView Windows API Hewlett Packard 1998b pode ser utilizada Trata se de uma API de mais alto n vel atrav s da qual poss vel entre outras coisas manipular objetos do banco de dados do OpenView Objetos mantidos no banco de dados podem ser lidos e escritos e novos objetos podem ser criados A informa o mantida coletada automaticamente e qualquer aplica o pode ter acesso a esta informa o 26 Ao utilizar a fun o OVsnmpEvent Open as aplica es podem estabelecer uma sess o de comunica o direta com o subsistema de eventos para enviar e receber eventos SNMP Filtros podem ser aplicados a fim de reduzir o n mero de eventos recebidos Um outro aspecto importante a considerar com rela o a esta API a ger ncia de mem ria Aqui as estru
14. J R A Simple Network Management Protocol Request for Comments 1157 DDN Network Information Center SRI International May 1990 Case et al 1993 Case J D McCloghrie K Rose M T Waldbusser S Introduction to version 2 of the Internet standard Network Management Framework Request for Comments 1441 SNMP Research Inc Hughes LAN Systems Inc Dover Beach Consulting Inc Carnegie Mellon University April 1993 Case et al 1998 Case J F Mundy R Partain D Stewart B Introduction to Version 3 of the Internet standard Network Management Framework Internet draft June 1998 DMTF 1998 DMTF Distributed Management Task Force DMTF Desktop Management Interface Specification Version 2 0 April 1998 D Souza amp Wills 1999 D Souza D F Wills A C Objects Components and Frameworks with UML The Catalysis Approach Addison Wesley 1999 Duarte 1997 Duarte Jr E P SNMP based Fault Tolerant Network Monitoring Depto de Inform tica Universidade Federal do Paran Relat rio T cnico May 1997 Ezhilchelvan 1994 Ezhilchelvan P D Dependability of Computer Systems Department of Computing Science University of Newcastle upon Tyne England 1994 Flanagan 1997 Flanagan D Java in a Nutshell A Desktop Quick Reference Second Edition O Reilly amp Associates May 1997 Fowler amp Scott 1998 Fowler M Scott K UML Distilled Applying the Standard Object Mod
15. Outros trabalhos ainda s o necess rios de modo a incluir outras caracter sticas na solu o proposta inclusive para melhorar o atendimento a alguns requisitos levantados Em primeiro lugar preciso especificar novos componentes para o gerenciamento de alarmes e de hist ricos logs de modo a permitir um melhor tratamento das falhas identificadas A especifica o atual n o detalha nenhum componente que possa ser diretamente utilizado pelo programador para estes fins A integra o com sistemas de trouble ticketing tamb m deve ser possibilitada para que o requisito F8 identificado na se o 4 1 seja devidamente atendido Em seguida para permitir utilizar algoritmos de correla o de eventos mais elaborados preciso incluir informa o sobre a topologia da rede no framework De fato muitos algoritmos se baseiam nos relacionamentos existentes entre as entidades gerenciadas da rede para identificar e diagnosticar falhas O framework possui alguns componentes que implementam algoritmos mais simples mas isto pode n o ser suficiente Deve ser investigada inclusive a possibilidade de integra o entre o framework e outras ferramentas de 110 descobrimento autom tico de topologia capazes de fornecer a informa o que o framework precisa sobre a configura o f sica e l gica da rede Em termos de configurabilidade outros pontos podem ser destacados A saber Toda a interface gr fica de utiliza o do framework d
16. SNMP SET LOG TICKET EXECUTE AGENT SE Especifica um conjunto de agentes sobre o qual as opera es SNMA ser o executadas TRAP Define um filtro para a gera o de eventos ass ncronos CONDITION Descreve uma situa o de falha na rede STATE Permite modelar a funcionalidade da aplica o como uma m quina de estados finita Tabela 3 2 Construtores SNMA Ent o suponha que se deseje monitorar dois servidores S e Sz Para isto necess rio especificar o conjunto formado por estes dois servidores como a seguir AGENT SET servidores S So Uma falha ter ocorrido se a taxa de erros de uma das interfaces de um dos servidores for maior que 40 do tr fego que passa atrav s dela E poss vel descrever este cen rio da seguinte maneira CONDITION InterfaceDefeituosa ifOutErrors ifOutErrors 1 gt ifOutPkts ifOutPkts 1 0 4 Figura 3 9 Defini o de uma condi o de falha 29 Condi es como esta podem ser utilizadas para definir eventos s ncronos atrav s do construtor POLLED EVENT cada construtor tem um conjunto de campos que o caracteriza A condi o avaliada de acordo com um intervalo de tempo POLL PERIOD e uma vez satisfeita uma a o PROCEDURE a ser executada em resposta ocorr ncia do evento pode ser especificada Na figura abaixo o evento s ncrono ServidorForaDoAr foi d
17. de Inform tica Universidade Federal de Minas Gerais 1997 Meira amp Lages 1998 Meira D M Lages N A C SIS Um Sistema Integrado de Supervis o para Telecomunica es Relat rio T cnico TELEMIG UFMG 88 Depto de Inform tica Universidade Federal de Minas Gerais Belo Horizonte Brasil Setembro 1988 Mellquist 1997 Mellquist P E SVMP An Object Oriented Approach to Developing Network Management Applications Prentice Hall 1997 Oates 1995 Oates T Fault Identification in Computer Networks A Review and a New Approach Computer Science Technical Report 95 113 University of Massachusetts 1995 Raman amp Raman 1999 Raman L G Raman L Fundamentals of Telecommunications Network Management IEEE Series on Network Management IEEE March 1999 Rational 1999 Rational Company A Rational Approach to Software Development using Rational Rose 4 0 White Paper 1999 On line http www rational com products rose prodinfo whitepapers Rofail amp Shohoud 1999 Rofail A Shohoud Y Mastering COM and COM Fourth Edition Sybex 1999 Rose 1990 Rose M T The Simple Book An Introduction to Management of TCP IP based Networks Prentice Hall 1990 Rose amp McCloghrie 1990a Rose M T McCloghrie K Management Information Base Network Management of TCP IP based Internets Request for Comments 1156 DDN Network Information Center SRI International May 1990 116 Ro
18. ficas como mecanismos mais elaborados para a identifica o de falhas no caso da ger ncia de falhas Neste cap tulo apresentamos alguns exemplos de como aplica es de ger ncia de redes podem ser desenvolvidas com base nas APIs e linguagens supracitadas Nas se es 3 1 3 2 3 3 e 3 4 apresentamos trechos de c digo que exemplificam como programadores podem construir suas aplica es de acordo com as caracter sticas que cada API ou linguagem possui Na se o 3 5 comparamos as APIs e linguagens apresentadas e ao caracterizarmos o n vel de abstra o adequado ao desenvolvimento de aplica es de ger ncia de falhas conclu mos que nenhuma das APIs ou linguagens vistas suficientemente capaz de fornec lo 3 1 A Linguagem de Comandos Tcl A linguagem de comandos Tcl Tool Command Language tem uma API para o SNMP conforme descrito pela figura 3 1 O comando snmp session permite abrir uma sess o estabelecer um contexto atrav s da qual requisi es SNMP ser o realizadas Cada sess o pode ser configurada de acordo com um conjunto de op es como o endere o do agente com o qual a sess o ser estabelecida Os comandos configure e cget podem ser utilizados para modificar e obter respectivamente a configura o corrente de uma sess o seja s uma sess o snmp snmp session lt options gt s configure lt options gt s cget lt option gt s get lt vbl gt lt callback gt s getnext lt vbl gt l
19. o podem ser criados a partir de uma extens o direta da classe GeradorDeEventoFalha por dois motivos Esta classe n o possui o m todo abstrato verificaOcorrenciaEvento Falha e consegiientemente n o obriga o programador a redefini lo no momento da constru o do novo componente O framework por sua vez exige precisa que isto seja feito para que ele possa identificar falhas na rede a partir da utiliza o de componentes criados pelo pr prio programador A classe GeradorDeEventoFalha n o por si s consumidora de eventos isto n o implementa nenhuma interface com este fim e assim n o obt m a informa o de ger ncia necess ria para a avalia o da ocorr ncia de falhas As rela es fonte consumidor a serem herdadas pelos novos componentes constru dos s s o bem identificadas a partir das subclasses GeradorDe EventoFalhaLimiar e GeradorDeEventoFalhaTrap ou seja a classe GeradorDeEventoFalhaLimiar consumidora do Monitor e a classe 2 GeradorDeEventoFalhaTrap consumidora do ReceptorDeTraps A constru o de novos componentes a partir destas subclasses que faz com que os novos componentes criados sejam por heran a consumidores de eventos dos tipos de fontes apropriadas Sendo assim do ponto de vista do programador apenas os componentes semiprontos GeradorDeEventoFalhaLimiar e GeradorDeEventoFalhaTrap podem ser 99 utilizados A classe GeradorDeEventoF
20. seriedade na orienta o pela qualidade das discuss es e pelo empenho Ao Prof Pedro S rgio Nicolletti pelo inestim vel apoio Ao meu noivo Vinicius pelo fundamental incentivo pelo inestim vel apoio pela paci ncia e pelo carinho Aos colegas de mestrado em especial a Erica L via e Andr a Aos professores e funcion rios Obrigada por estarem por perto e me fazerem lembrar que eu jamais estive sozinha iv Conte do 1 Introdu o 1 1 Objetivos da Disserta o 1 2 Escopo e Relev ncia 1 3 Estrutura da Disserta o 2 A Ger ncia de Redes de Computadores 2 1 Areas Funcionais da Ger ncia de Redes 2 2 Um Modelo de Ger ncia 2 2 1 O Padr o de Ger ncia Internet 8 2 3 A Ger ncia de Falhas 2 3 1 A Correla o de Eventos 2 3 2 Arquitetura Geral de uma Aplica o de Ger ncia de Falhas 3 APIs e Linguagens para a Implementa o de Aplica es de Ger ncia de Redes 3 1 A Linguagem de Comandos Tcl 3 2 A API de Ger ncia Java 3 3 A API SNMP do Open View 3 4 A Nota o SNMA 3 5 Uma An lise das Solu es Apresentadas 4 Um Framework para a Ger ncia de Falhas 4 1 Requisitos da Solu o 4 2 O Projeto Arquitetural 4 2 1 Framework e Componentes 4 2 2 Fontes e Consumidores de Eventos 11 14 16 19 20 22 24 28 32 36 37 45 45 49 4 3 Os Componentes B sicos do Framework 4 3 1 Descrevendo a Rede Gerenciada
21. 21 Figura 4 22 Figura 4 23 Figura 4 24 Figura 4 25 Figura 4 26 Figura 4 27 Figura 4 28 Figura 4 29 Figura 4 30 Figura 4 31 Figura 4 32 Figura 4 33 Figura 4 34 Figura 4 34 GeradorAltaPerdaDePacotes 65 GeradorAltaTaxaDeTrafegol 66 GeradorAltaTaxaDeTrafego2 66 Mecanismo de histerese 67 GeradorDeEventoFalhaComHisterese 68 CorrelatorDeEventoFalha um componente para tratamento de falhas 69 Componentes para a correla o de eventos 69 CorrelatorDeEventoFalhaCompressao 70 CorrelatorDeEventoFalhaSupressao 70 CorrelatorDeEventoFalhaCMP 71 CorrelatorDeEventoFalha 72 CorrelatorTemporal 73 GeradorDeAlarmes 73 ElementoGerenciado InfoGerenciae ReceptorDeTraps 75 Gerando novos tipos de eventos 77 Interconex es poss veis entre os componentes do framework 82 Exemplo 1 85 Exemplo 2 88 Exemplo 3 parte 1 94 Exemplo 3 parte IT 95 Figura 5 1 Diagrama de classes parte I 105 Figura 5 1 Diagrama de classes parte II 106 Figura 5 1 Diagrama de classes parte III 107 Figura 5 1 Diagrama de classes parte IV 108 Figura A 1 Diferen a no fluxo de controle entre frameworks e bibliotecas de classes 121 126 Figura B 1 BeanBox viii Cap tulo 1 Introdu o Nos ltimos anos as redes de computadores t m experimentado um crescimento vertiginoso A integra o de m ltiplas tecnologias e o crescente n mero de usu rios que passaram a
22. Basic Enconding Rules ISO IEC 8825 1987 Em outras palavras a SMI define um esquema para a base de dados mantida por cada elemento gerenciado da rede Rose 1990 Esta base de dados tem um nome bem determinado e se chama MIB Management Information Base Um m dulo MIB Rose amp McCloghrie 1990a define uma cole o de vari veis relacionadas A MIB padr o atual ou MIB II Rose amp McCloghrie 1991 por exemplo cont m 190 vari veis que descrevem em conjunto a informa o de ger ncia que deve ser mantida por cada elemento gerenciado que suporte a pilha de protocolos TCP IP Fabricantes podem definir seus pr prios m dulos MIB agrupando a informa o associada a uma tecnologia espec fica Ao implementar uma MIB um agente est definindo qual informa o de ger ncia ele cont m Para tornar mais claras as id ias contidas nos par grafos anteriores considere a vari vel abaixo definida para a MIB II Esta vari vel indica a quantidade de tempo em cent simos de segundos desde a ltima vez em que o elemento gerenciado foi reinicializado sysUpTime SYNTAX TimeTicks ACCESS read only STATUS mandatory system 3 A sintaxe da defini o acima n o confundir com o campo SYNTAX especificada pela SMI a qual requer que cada vari vel tenha um nome sysUpTime e um tipo SYNTAX Neste caso a sintaxe indica que esta vari vel possui um valor escalar do tipo TimeTicks Tal valor pode ser apenas lido pel
23. Cl e interfaces IL que podem ser diretamente utilizadas pelo programador Cada componente por sua vez definido em termos de suas pr prias classes e interfaces e componentes semiprontos permitem ter seu comportamento modificado atrav s de uma de suas classes por exemplo extens o da classe cl do componente CS Framework Componente semi pronto CS Componente semi pronto CS Figura 4 2 Componentes classes e interfaces do framework CO 48 Assim para adicionar funcionalidade ao framework o programador pode utilizar componentes semiprontos que agrupam suas pr prias classes e interfaces bem como outras classes e interfaces fornecidas pelo framework Cada componente semipronto pode ser visto como um subframework que permite modificar n o s o seu comportamento interno mas o comportamento do framework como um todo Com base na arquitetura apresentada poss vel identificar dois tipos de usu rios que utilizar o o framework em momentos diferentes h o programador de novos componentes aquele que constr i componentes ao identificar novas necessidades durante o desenvolvimento de determinada aplica o e h o projetista de aplica es aquele que constr i a aplica o visualmente instanciando configurando e interconectando os componentes dispon veis O primeiro tipo de usu rio ou programador de novos componentes certamente deve ter um maior conhecimento em termos de ger ncia de redes
24. Figura 3 7 A estrutura de dados OVsnmpPdu Programadores ainda podem utilizar outros subsistemas que comp em o OpenView como aquele que facilita o registro de ocorr ncias logging e outros voltados para a correla o de eventos O OpenView portanto fornece meios mais eficientes para identificar diagnosticar e tratar registrar as falhas ocorridas Na maioria das vezes basta utilizar algumas dezenas entre as centenas de fun es que comp em as APIs dispon veis 3 4 A Nota o SNMA A SNMA Specification of Network Management Applications Sim es et al 1994 uma nota o de alto n vel para a especifica o de aplica es de ger ncia de redes Diferentemente das outras solu es apresentadas a SNMA uma linguagem que busca prover as abstra es necess rias para que o programador possa se concentrar na solu o desejada enquanto n o precisa se preocupar com detalhes ligados a protocolos de comunica o A nota o SNMA tem duas caracter sticas b sicas Ela prov meios de alto n vel para representar a informa o de ger ncia Tal representa o esconde o processo usado para obter esta informa o e detalhes relacionados opera es do protocolo de comunica o por exemplo Ela suporta meios para definir e manipular abstra es de alto n vel como eventos e a es Para representar a informa o de ger ncia a SNMA define e utiliza uma sintaxe pr pria conforme descrito pela figura abaix
25. InfoGerencia k etTrapDaRede Nok eterminaTipoDeT rap ome String escricao String rioridadeBaixa rioridadeMedia rioridadeAlta k Nok nome String etNome responsavel String tNome ontatoResponsavel String etDescricao rioridade int tDescricao etinteiro etNome etDouble tNome etString etResponsavel tResponsavel 74 etContatoResponsavel tContatoResponsavel etPrioridade tPrioridade etGrupolnfoGerencia x Figura 4 29 Element oGerenciado InfoGerencia e ReceptorDeTraps A interface ElementoGerenciado descreve qualquer tipo de entidade gerenciada n o possuindo caracter sticas que estejam diretamente associadas a um modelo de ger ncia espec fico atrav s do m todo getGrupoInfoGerencia que a informa o de ger ncia requisitada fornecida e aqui portanto que os detalhes do protocolo de ger ncia devem ser embutidos O componente ElementoGerenciadoSnmp por exemplo implementa esta interface acrescentando ao componente criado o endere o IP atrav s do qual poss vel localizar o agente SNMP representado conforme visto na se o 4 3 1 A interface InfoGerencia descreve uma unidade de informa o de ger ncia gen rica Um GrupoInfoGerencia agrupa componentes deste tipo e n o componentes InfoGerenciaSnmp conforme dito anteriormente de modo que um mesmo GrupoInfoGerencia pode conter difere
26. Rede 3 Pol ticas Filtros com Limiar Eventos na Rede Correla o de Eventos Filtro de agrupamento Problemas na Rede Gerando Alarmes Filtro de Prioridade E 2 Topologia Alarmes Priorizados Notifica o de Alarmes FAX REGISTRO DE OCORRENCIAS TROUBLE TICKETS MAPA Esta o de ger ncia Figura 2 4 Arquitetura geral de uma aplica o de ger ncia de falhas Assim a figura 2 4 descreve o comportamento gen rico de uma aplica o de ger ncia de falhas Quanto mais eficientes os mecanismos empregados para identifica o diagn stico e corre o de falhas mais eficiente o gerenciamento da rede A caracteriza o deste comportamento ser importante para a identifica o dos requisitos de uma solu o que 17 visa facilitar o desenvolvimento de aplica es de ger ncia de falhas Tal solu o ser descrita no cap tulo 4 18 Cap tulo 3 APIs e Linguagens para a Implementa o de Aplica es de Ger ncia de Redes Com a evolu o da ger ncia de redes uma grande variedade de ferramentas e aplica es de ger ncia tem sido desenvolvida Em cada uma das cinco reas funcionais descritas na se o 2 1 aplica es realizam as tarefas descritas de modo a atender s necessidades espec ficas de cada sistema segundo pol ticas de ger ncia adequadas Para tanto elas se utilizam dos protocolos de ger ncia dispon veis tal como o SNMP no caso do padr o de ger ncia Intern
27. componente cadastrado para que tais componentes possam tratar a informa o recebida Ent o uma vez que os componentes estejam cadastrados s classes ativas Monitor e ReceptorDeTraps e uma vez que estas classes sejam ativadas a rede passar a ser permanentemente monitorada n o faltando a informa o necess ria para que outros componentes possam realizar sua fun o Uma outra classe chamada FwGF a classe respons vel por inicializar as classes ativas instanciadas dando in cio execu o da aplica o de acordo com a configura o feita visualmente pelo usu rio do framework Com isso a rede passa a ser efetivamente gerenciada conforme a configura o realizada 5 2 Ferramentas para a Composi o de Aplica es Uma vez que os componentes sejam implementados e estejam finalmente dispon veis para uso a aplica o pode ser composta visualmente Em outras palavras os componentes podem ser instanciados e interconectados atrav s de um ambiente gr fico para que a partir da o framework possa executar de acordo com uma configura o espec fica Sendo assim a primeira ferramenta de suporte necess ria para que uma aplica o seja constru da com base em componentes um editor gr fico Um editor gr fico para os componentes especificados deve permitir configurar as propriedades de cada componente instanciado e interconectar os componentes instanciados Algumas ferramentas como o BeanBox
28. componentes respons veis pela gera o de alarmes atualiza o de registros de ocorr ncia 68 logs ou correla o de eventos devem se associar aos geradores de eventos previamente configurados para que uma vez ocorrido determinado tipo de evento eles possam tomar conhecimento do fato e realizar as a es cab veis automaticamente Assim sendo poss vel automatizar tarefas em resposta aos eventos ocorridos conforme requisito F5 Na figura 4 21 um componente respons vel por fazer a correla o de eventos est associado a um gerador de eventos para que possa fazer a correla o com base na informa o recebida Qualquer componente respons vel pelo tratamento de falhas pode se associar a qualquer tipo de gerador de eventos GeradorDeEventoFalhaLimiar GeradorDe EventoFalhaTrap ou GeradorDeEventoFalhaComHisterese a fim de obter a informa o de interesse envia EventoFalhaEvent gera GeradorDeEventoFalhaLimiar EventoFalhaEvent CorrelatorDeEventoFalha 1 Figura 4 21 Corre latorDeEventoFalha um componente para tratamento de falhas O framework fornece tr s componentes que podem ser diretamente utilizados para fazer correla o de eventos em atendimento ao requisito F4 CorrelatorDeEvento FalhaCompressao CorrelatorDeEventoFalhaSupressao e CorrelatorDe EventoFalhaCMP Estes componentes s o apresentados na figura 4 22 Eles impl
29. da falha descrita o GeradorDeEventos Gs deve se cadastrar no Monitor M declarando o seu interesse em receber a informa o de ger ncia decorrente da monitora o a falha ser identificada a partir da an lise da informa o recebida Al m disso o GeradorDeAlarmes Ga deve se cadastrar no Gz declarando o seu interesse em ser notificado sempre que a falha ocorrer para assim poder notificar o operador da rede O fluxo de execu o descrito pela figura 4 5 reflete esta situa o evento cont m informa o evento descreve a de ger ncia falha ocorrida Figura 4 5 Fluxo de eventos Monitor GeradorDeEventos GeradorDeAlarmes Al m disso poss vel definir fluxos arbitr rios de execu o de acordo com as necessidades a serem atendidas por cada aplica o Conforme descrito na se o 4 1 deve ser poss vel realizar diferentes a es em resposta ocorr ncia de um nico evento requisito F6 ou modificar o processo de monitora o diante da ocorr ncia de um evento No primeiro caso situa o A figura 4 6 os diferentes componentes A Az As que realizam cada uma das a es necess rias est o cadastrados no mesmo GeradorDeEventos Gs e o Gg ent o repassa o evento gerado para todos eles requisito F6 satisfeito No segundo caso situa o B figura 4 6 o Monitor M est cadastrado no GeradorDeEventos Gs e Gs est cadastrado 51 em M M recebe o evento cuja gera o resultou da an
30. de agilizar o diagn stico de falhas Suponha por exemplo que ocorra uma parti o na rede devido a uma falha num dos roteadores ou qualquer outro equipamento de interconex o Muitos outros dispositivos ficar o inacess veis a partir da esta o de ger ncia e a propaga o desta falha poder levar ocorr ncia de in meros eventos derivados de um s roteador inoperante Conhecendo a topologia da rede e sabendo quais os dispositivos inacess veis a aplica o poderia gerar um nico alarme em torno do qual os eventos ocorridos nestes dispositivos estariam associados falha no roteador Isto n o s reduziria a quantidade de alarmes gerados como facilitaria o diagn stico do problema H diversos tipos de correla o dentre os quais podemos citar Meira 1997 Contagem consiste em gerar um novo evento cada vez que o n mero de ocorr ncias de um determinado tipo de evento ultrapassar um limiar previamente estabelecido Compress o consiste em detectar m ltiplas ocorr ncias de um mesmo evento num dado intervalo de tempo substituindo os eventos correspondentes por um nico evento possivelmente indicando quantas vezes o evento ocorreu durante o intervalo de tempo considerado Supress o consiste em detectar se um mesmo evento ocorreu determinado n mero de vezes k dentro de um intervalo de tempo substituindo os k eventos ocorridos por um nico evento t o logo k seja atingido Filtragem consiste em s
31. de melhorar a configurabilidade da aplica o a partir dos componentes dispon veis em atendimento ao requisito F9 Para isto seria necess ria a defini o de m dulos de pol tica de ger ncia que agrupassem os componentes necess rios para a realiza o de determinada tarefa instanciando os e interconectando os de forma autom tica em tempo de constru o visual da aplica o O programador instanciaria um destes m dulos em vez de componentes isolados Por exemplo seria extremamente til que houvesse um m dulo de configura o para identifica o de falhas na rede Isto poderia 111 incluir a instancia o autom tica de um componente do tipo Elemento Gerenciado um Monitor um GeradorDeEventoFalha e um EventoFalhaListener j devidamente interconectados O programador configuraria o m dulo como um todo reutilizando toda a funcionalidade resultante da combina o dos componentes pertencentes ao m dulo de configura o No caso do terceiro item supracitado a quest o vai al m de melhorar a configurabilidade da aplica o e consiste em evoluir um pouco mais em termos de processo de desenvolvimento para que se possa identificar as formas adequadas de agrupar os componentes at agora dispon veis Ao fornecer supercomponentes que naturalmente prov em um grau de reusabilidade ainda maior que aquele fornecido por componentes isolados o programador pode construir sua aplica o sem precisar saber como component
32. disso preciso configurar o evento que ser gerado no caso do limiar ser atingido nome descricao prioridade bem como o evento que ser gerado no caso do valor de rearm ser atingido nomeEventoRearm descricaoEventoRearm e prioridadeEventoRearm Finalmente preciso associar o GeradorDeEventoFalhaComHisterese ao Monitor que obt m a informa o da ger ncia a ser analisada O m todo getValor Atingido tamb m est dispon vel permitindo saber qual dos valores foi atingido Limiar ou rearm ou seja qual dos valores levou gera o do novo evento O framework portanto identifica falhas na rede atrav s de componentes criados pelo pr prio programador e atrav s da utiliza o de componentes do tipo GeradorDeEvento FalhaComHisterese Resta tratar as falhas identificadas a fim de fazer com que a rede volte ao seu estado de funcionamento normal o mais r pido poss vel O framework fornece alguns componentes para tratamento de falhas mas tamb m permite que o programador defina seus pr prios componentes como veremos a seguir 4 3 4 Tratando as Falhas Identificadas Conforme visto na se o anterior geradores de eventos identificam falhas na rede ao gerarem eventos do tipo EventoFalhaEvent Os eventos gerados descrevem as falhas ocorridas Para que estas falhas possam ser tratadas componentes devem se associar aos geradores de eventos adequados a fim de obter a informa o necess ria Em outras palavras
33. e deve ter um conhecimento b sico sobre a linguagem de programa o utilizada para implementar e estender os componentes semiprontos No caso em que seja necess rio implementar outras interfaces e ou estender outras classes especificadas pelo framework uma experi ncia maior necess ria Al m disso o programador de novos componentes tem o compromisso de construir componentes gen ricos e reutiliz veis que podem ser utilizados toda vez que a mesma necessidade seja identificada Cada componente criado seja ele atrav s de um componente semipronto seja ele atrav s de outras classes e interfaces pode ser utilizado pelas diversas aplica es que devem atender a uma necessidade comum O projetista de aplica es por sua vez pode utilizar o framework num n vel de abstra o mais alto Ele deve compor a aplica o final ao reutilizar os componentes dispon veis manipulando estes componentes graficamente 4 2 2 Fontes e Consumidores de Eventos Definida a arquitetura externa da solu o preciso definir a sua arquitetura interna isto deve se identificar os componentes do framework que devem estar dispon veis para que o programador possa construir sua aplica o e deve se definir uma forma de interconect los Em outras palavras deve se definir como o comportamento gen rico de uma 49 aplica o de ger ncia de falhas representado pela figura 2 4 e sujeito aos requisitos Fl a F8 ser capturado pelo fra
34. em v rias requisi es Desta forma opera es de ger ncia se baseiam em grupos que re nem v rias unidades de informa o para permitir recuperar de uma nica vez o m ximo de informa o de ger ncia poss vel H portanto componentes do tipo GrupoInfoGerencia que agrupam componentes do tipo InfoGerenciaSnmp Para especificar qual informa o de ger ncia um determinado ElementoGerenciadoSnmp deve fornecer o programador instancia v rios componentes InfoGerenciaSnmp e os agrupa num GrupoInfoGerencia de maneira que o ElementoGerenciadoSnmp possa fornecer o grupo requisitado As APIs vistas no cap tulo 3 tamb m empregam a mesma id ia 55 4 3 2 Monitorando a Rede Com os tr s componentes vistos at agora poss vel identificar as entidades SNMP da rede que devem ser gerenciadas ElementoGerenciadoSnmp e qual informa o de ger ncia GrupoInfoGerencia deve ser fornecida por cada uma delas Para controlar a frequ ncia com que tais entidades devem fornecer a informa o requisitada um outro componente foi especificado Trata se do Monitor mostrado na figura 4 9 Monitor ig GrupolnfoGerencia g ElementoGerenciado eriodo int Figura 4 9 Monitor O Monitor o componente respons vel pela realiza o de monitora o s ncrona requisito F1 Um Monitor pede ao ElementoGerenciado ao qual ele est associado ElementoGerenciado uma interface implementad
35. fornece informa o de ger ncia e atrav s dele que a aplica o obt m a informa o necess ria para identificar falhas na rede Os par metros de configura o de cada requisi o de ger ncia a ser realizada por determinado Element oGerenciadoSnmp como o timeout da requisi o ou o numero de tentativas que devem ser feitas at que a requisi o execute adequadamente s o especificados atrav s do componente ConfiguradorDeRequisicaoSnmp Este componente deve ser associado a um ElementoGerenciadoSnmp para que a configura o feita atrav s dele seja utilizada Se nenhum configurador for instanciado e associado ao ELementoGerenciadoSnmp uma configura o default utilizada Para determinar qual informa o deve ser fornecida pelo ElementoGerenciado Snmp os componentes InfoGerenciaSnmp e GrupoInfoGerencia foram especificados Vide figura 4 8 InfoGerenciaSnmp nome String escricao String id String GrupolnfoGerencia EBnome String Reinocem m etinteiro o etinfoGerencia etQuantinfoGerencia etString No cap tulo 5 fornecemos uma descri o mais detalhada de cada componente Nesta se o destacamos apenas os aspectos de maior relev ncia do ponto de vista do usu rio que vai compor a aplica o visualmente 54 Figura 4 8 Grupo InfoGerencia e InfoGerenciaSnmp De acordo com a figura acima um GrupoInfoGerenci
36. inoperante pode representar uma falha Entretanto outras vezes uma falha pode resultar da an lise de diferentes vari veis inclusive vari veis mantidas por diferentes agentes Considere os exemplos abaixo 1 Suponha que seja necess rio monitorar um determinada interface i do roteador R A falha interface i do roteador R est com defeitos poderia resultar da verifica o de que o n mero de pacotes descartados vari vel MIB i fOutDiscards ultrapassou determinado valor v e o n mero de erros vari vel MIB ifOutErrors apresentados por tal interface ultrapassou um outro valor v2 2 Suponha agora que seja necess rio identificar um congestionamento em R e que R d acesso a dois servidores multim dia distintos S4 e S2 A falha congestionamento em R impossibilitando a comunica o de S e S2 com seus clientes remotos poderia resultar da verifica o de que a soma do tr fego gerado por S e S gt ultrapassou determinado valor Sendo assim deve ser poss vel definir eventos que descrevam estas situa es ao analisar v rias vari veis de um ou mais agentes em torno de um ou v rios limiares Para isto preciso ter o acesso devido informa o de ger ncia necess ria F4 Deve ser poss vel fazer correla o de eventos Uma vez que os eventos tenham ocorrido deve ser poss vel correlacion los observando a rela o de depend ncia que possa existir entre eles Isto permitir reduzi
37. interconectados a qualquer um dos componentes inicialmente citados a fim de correlacionar ou tratar os eventos deles recebidos Um CorrelatorDeEventoFalha gera um novo evento toda vez que a falha verificada por ele falha esta resultante da correla o realizada ocorrer de modo que componentes do tipo EventoFalhaListener tamb m podem ser a ele interconectados A figura 4 31 mostra as rela es descritas As setas n o hachuradas representam o envio de um evento para os componentes cadastrados 80 De acordo com a figura 4 31 os componentes Monitor e ReceptorDeTraps s o fontes de eventos e repassam a informa o colhida na rede para outros componentes o componente Monitor guarda uma refer ncia para um componente do tipo Elemento Gerenciado ao qual pedir um GrupoInfoGerencia com determinada freqii ncia Os componentes GeradorDeEventoFalhaLimiar GeradorDeEventoFalhaTrap GeradorDeEventoFalhaComHisterese e CorrelatorDeEventoFalha s o componentes processadores que consomem os eventos recebidos e produzem novos eventos Componentes do tipo EventoFalhaListener s o consumidores de eventos que d o o tratamento adequado s falhas identificadas Componentes prontos 81 I 1 4 Componentes semi prontos mT 1 Figura 4 31 Interconex es poss veis entre os componentes do framework Portanto assim que os componentes podem ser int
38. listados na se o anterior especificamos um framework baseado em componentes de software reutiliz veis Nesta se o consideramos que o leitor tem um conhecimento b sico sobre os principais conceitos envolvidos ou seja frameworks e componentes de software Se este n o for o caso recomendamos a leitura pr via dos ap ndices A e B onde fornecida uma vis o geral sobre tais conceitos na ordem em que foram citados Este conhecimento pr vio essencial para o bom entendimento e f cil leitura do que se segue Feito isto vejamos como os conceitos envolvidos podem ser utilizados para atender aos requisitos levantados 4 2 1 Framework e Componentes A fim de encontrar uma solu o adequada reconsidere os requisitos listados Primeiramente de acordo com os requisitos NF4 e NF6 a solu o deve permitir o desenvolvimento r pido de aplica es de ger ncia de falhas em quest o de horas ao exigir o m nimo de programa o e ao fornecer abstra es facilmente utiliz veis Para isto um alto grau de reusabilidade deve ser fornecido permitindo ao programador concentrar seus esfor os na obten o da funcionalidade espec fica de sua aplica o Seria poss vel portanto fornecer uma biblioteca de classes mas a reutiliza o de c digo obtida atrav s da utiliza o de bibliotecas de classes em geral pode n o ser suficiente 45 A experi ncia comprova que durante o processo de desenvolvimento normal de qualquer produto de
39. monitores uma estrutura de dados pr pria mantida de modo a organizar e disponibilizar a informa o recebida dos diferentes monitores esta informa o atualizada atrav s do m todo proces saDadosMonitorados Um outro m todo template resulta da implementa o da interface EventoFalha Listener pela classe CorrelatorDeEventoFalha Ao implementar esta interface a classe CorrelatorDeEventoFalha torna o m todo processaEventoFalha um m todo do tipo final que simplesmente executa o m todo correlaciona definido pelo 101 programador Os novos componentes criados a partir da extens o desta classe podem ser ent o automaticamente conectados a qualquer tipo de gerador de evento subclasses de GeradorDeEventoFalha j que por heran a eles tamb m implementam a interface EventoFalhaListener podendo receber os eventos de interesse para a correla o a ser realizada Outros componentes criados diretamente a partir da implementa o desta interface entretanto podem devem redefinir o m todo processaEventoFalha incluindo nele qualquer a o cab vel a ser realizada diante da ocorr ncia de determinado tipo de falha 5 1 2 Classes Ativas Outras duas classes devem ser destacadas Trata se das classes ativas Monitor e ReceptorDeTraps Estas classes implementam a interface Java java io Runnable abastecendo o framework com a informa o de ger ncia necess ria para que os eventos sejam trocados entre
40. na se o 4 2 e conforme j exemplificado na se o anterior quando a interface EventoFalhaListener foi apresentada Nesta se o vejamos como utilizar outras interfaces para fornecer o suporte a diferentes modelos de ger ncia Para construir uma determinada aplica o preciso em algum momento tratar caracter sticas espec ficas de um ou de v rios modelos de ger ncia Por exemplo no modelo Internet deve se especificar um endere o IP para cada entidade gerenciada agente SNMP envolvido e um identificador espec fico para cada unidade de informa o de ger ncia vari vel MIB que deve ser obtida pela aplica o Al m disso preciso um ReceptorDeTraps que reconhe a cada trap SNMP recebido e o mapeie para um modelo comum especificado pelo framework traps do tipo TrapEvent Cada modelo de ger ncia tem suas caracter sticas pr prias O framework fornece os componentes ElementoGerenciadoSnmp InfoGerenciaSnmp e ReceptorDeTrapsSnmp fornecendo suporte default ao SNMP conforme requisito NF2 mas tamb m permite a partir das interfaces ElementoGerenciado e InfoGerencia e do componente semipronto ReceptorDe Traps que novos componentes possam ser constru dos para descrever caracter sticas particulares de outros modelos de ger ncia A figura 4 29 mostra as interfaces e o componente semipronto citados lt lt Interface gt gt lt lt Interface gt gt ReceptorDeTraps ElementoGerenciado
41. ncia com diferentes frequ ncias pode se associar v rios monitores mesma entidade gerenciada A figura 4 10 descreve ambas as situa es lt lt Interface gt gt monitora Monitor lt lt Interface gt gt ElementoGerenciado ElementoGerenciado fornece informa o a Monitor 1 1 1 E Figura 4 10 Rela es Monitor ElementoGerenciado e ElementoGerenciado Monitor Ent o se cada inst ncia de um ElementoGerenciado controlada por seu s pr prio s monitor es as diferentes inst ncias de um ElementoGerenciado que em geral existem numa mesma aplica o podem fornecer informa o de ger ncia independentemente umas das outras e inclusive de forma concorrente Em decorr ncia disto poss vel monitorar v rias entidades da rede paralelamente melhorando o desempenho da aplica o e refor ando se o atendimento ao requisito NFS Para fazer monitora o assincrona ainda conforme requisito F1 o framework fornece um outro componente chamado ReceptorDeTrapsSnmp Este componente recebe os traps SNMP gerados pelos agentes da rede gerenciada sendo suficiente para tanto instanci lo Nenhuma configura o precisa ser feita ReceptorDeTraps Snmp taps Figura 4 11 ReceptorDeTrapsSnmp At agora portanto h duas fontes de eventos respons veis pela monitora o da rede Monitor e ReceptorDeTrapsSnmp Os e
42. ncia de falhas O projeto do framework apresentado ao longo das se es seguintes Na se o 4 2 apresentamos um projeto arquitetural que define as arquiteturas interna e externa do framework e com base nesta arquitetura caracterizamos dois perfis de usu rios que utilizar o o framework em momentos distintos o programador de novos componentes e o projetista de aplica es Na se o 4 3 descrevemos os componentes b sicos do framework detalhando a arquitetura interna definida na se o anterior Na se o 4 4 s o fornecidos alguns exemplos de aplica es constru das com base na especifica o apresentada As caracter sticas do framework portanto s o apresentadas gradativamente ao longo do cap tulo medida em que vamos atendendo aos requisitos levantados No final da se o 4 3 fornecido um resumo que re ne as caracter sticas gerais da solu o proposta e que destaca como os requisitos listados foram atendidos 4 1 Requisitos da Solu o Uma vez que seja necess rio propor uma solu o para qualquer problema a primeira coisa a se fazer entender bem o problema S para citar o fil sofo John Dewey um problema bem formulado j est em parte resolvido Assim deve se antes de mais nada identificar os requisitos da solu o Mais especificamente falando deve se identificar os requisitos que uma vez atendidos caracterizar o a solu o que fornece o n vel de abstra o adequado para o
43. os componentes interconectados O fluxo de execu o interno do framework portanto come a com a ativa o destas classes Como fontes de eventos as classe Monitor e ReceptorDeTraps possuem juntamente com a classe GeradorDeEventoFalha os m todos necess rios para a ger ncia dos componentes nelas cadastrados A saber Classe Monitor addMonitorListener removeMonitorListener e disparaProcessaDadosMonitorados Classe ReceptorDeTraps addTrapListener removeTrap ListeneredisparaProcessaTrap Classe GeradorDeEventoFalha addEventoFalhaListener removeEventoFalhaListener edisparaProcessakventoFalha Os m todos addMonitorListener addTrapListener e addEvento FalhaListener efetuam o cadastro de componentes interessados em receber os novos eventos gerados os m todos removeMonitorListener removeTrapListener e removeEventoFalhaListener cancelam o cadastro de componentes previamente cadastrados e os m todos disparaProcessaDadosMonitorados dispara ProcessaTrap e disparaProcessaEventoFalha enviam cada novo evento gerado para todos os componentes cadastrados O envio de um novo evento consiste em executar o 102 m todo da interface implementada por cada componente cadastrado repassando o evento gerado Assim o Monitor executa o m todo processaDadosMonitorados o ReceptorDeTraps executa o m todo processaTrap e o GeradorDeEvento Falha executa o m todo processaEventoFalha de cada
44. processaDadosMonitorados interface MonitorListener e processaTrap interface TrapListener que o framework 1 trata a informa o de ger ncia resultante da monitora o realizada 2 executa o m todo verificaOcorrenciaEventoFalha e 3 gera novos eventos quando as falhas observadas ocorrem O programador portanto deve apenas reutilizar a funcionalidade embutida no framework Para que este algoritmo n o seja modificado o que interferiria no fluxo de execu o interno do framework os m todos processaDadosMonitorados e processaTrap s o do tipo final M todos Java do tipo final n o podem ser redefinidos nas subclasses que os herdam de modo que neste caso a implementa o feita pelo framework pode ser apenas reutilizada Os m todos processaDadosMonitorados e processaTrap portanto s o m todos template padr o de projeto Template Method Gamma et al 1994 que uma vez escritos n o podem ser modificados Contudo eles executam outros m todos definidos pelo pr prio usu rio do framework dentro de seu fluxo de controle no caso o m todo verificaOcorrenciaEventoFalha possuindo al m de partes fixas partes vari veis atrav s das quais alguma funcionalidade particular pode ser adicionada tamb m dentro destes m todos template que estruturas de dados internas necess rias para o funcionamento dos componentes s o atualizadas No caso do GeradorDeEventoFalhaLimiar que pode receber informa o de diferentes
45. s ncrono ou no modo ass ncrono A fun o OVsnmpBlockingSend por exemplo s ncrona enquanto a fun o OVsnmpSend ass ncrona No segundo caso uma fun o de retorno callback deve ser especificada a fim de tratar a resposta recebida um apontador para a fun o de retorno especificado no momento de abertura da sess o Confira na figura abaixo 25 Abre sess o SNMP com o agente remoto specifica uma fun o de retorno sessao OvsnmpOpen 150 165 75 21 applCb Cria a mensagem SNMP a ser enviada pdu OvsnmpCreatePdu GET_REQ MSG OvsnmpAddVarBind pdu sysUpTime 0 Envia uma requisi o assincrona req OvsnmpSend session pdu Figura 3 6 Envio de uma requisi o no modo assincrono De acordo com a figura 3 6 uma sess o SNMP estabelecida com o agente cujo endere o IP 150 165 75 21 Uma mensagem pdu criada para a obten o GET REQ MSG do valor de sysUpTime A requisi o reg feita atrav s da fun o Ovnsmpsend e a resposta recebida atrav s do par metro app1Cb Para tratar eventos ass ncronos SNMP ou simplesmente traps as aplica es podem utilizar o subsistema de eventos do OpenView Este subsistema repassa os eventos recebidos para as aplica es interessadas entre os quais est o os traps SNMP Como parte deste subsistema h m dulos que oferecem servi os de correla o de eventos ECS
46. software as fases de an lise descri o do problema e de projeto descri o da solu o s o as mais importantes e consomem a maior parte do tempo Landin amp Niklasson 1998 durante estas etapas que as principais decis es s o tomadas arquitetura da solu o e escolha de tecnologias por exemplo e os erros cometidos podem custar muito caro um problema mal entendido n o pode ser bem resolvido e uma solu o mal pensada jamais resolver o problema em quest o em outras palavras jamais atender s necessidades do usu rio Sendo assim poss vel concluir que para reduzir efetivamente o tempo gasto durante o desenvolvimento de uma aplica o preciso fornecer n o s reutiliza o de c digo mas tamb m de an lise e de projeto de modo a reutilizar o conhecimento empregado e as principais decis es tomadas durante estas etapas Em outras palavras deve se fornecer um framework para a ger ncia de falhas Frameworks s o solu es quase prontas que maximizam a reusabilidade fornecida ao permitir reutiliza o de an lise projeto implementa o e testes Eles capturam o que h de comum entre v rias aplica es de um dom nio de problema bem delimitado e podem ter seu comportamento modificado e ou estendido de modo a acomodar caracter sticas espec ficas das aplica es que o utilizam Landin amp Niklasson 1998 Assim um framework determina a arquitetura das aplica es constru das com base nele ao captur
47. tamb m s o feitas sobre ferramentas de suporte necess rias para a composi o de aplica es 5 1 O Projeto Interno dos Componentes B sicos do Framework Na se o 4 2 quando o projeto arquitetural do framework CO foi definido foi sugerida a utiliza o de uma linguagem de programa o orientada a objetos para implementa o de cada componente De fato como o leitor pode conferir a partir dos exemplos fornecidos no cap tulo 4 a linguagem Java foi utilizada Para construir componentes de acordo com esta linguagem algumas regras devem ser observadas conforme descrito pelo ap ndice B Cada componente definido como um conjunto de classes interfaces e outros recursos arquivos de configura o figuras etc de modo que segundo o projeto arquitetural apresentado no cap tulo 4 deve se estender classes e redefinir m todos para adicionar funcionalidade a um componente semipronto fornecido pelo framework 96 Sendo assim embora o programador possa utilizar componentes no momento da configura o visual da aplica o em termos de implementa o o framework consiste de classes e interfaces que ao serem agrupadas formam os componentes especificados Estas classes e interfaces est o nos diagramas UML da figura 5 1 presente no final desta se o e est o devidamente especificados de acordo com a linguagem Java em http www dsc ufpb br raissa doc frame html A tabela 5 1 mostra como estas classes e int
48. tipo de falha Para identificar um tipo de falha espec fico entretanto n o basta instanciar e configurar um gerador do tipo GeradorDeEventoFalhaLimiar ou GeradorDe EventoFalhaTrap Antes disso o programador deve definir o m todo verifica OcorrenciaEventoFalha para analisar a informa o recebida do Monitor no caso de um GeradorDeEventoFalhaLimiar ou do ReceptorDeTrapsSnmp no caso de um GeradorDeEventoFalhaTrap Trata se portanto dos dois primeiros componentes semiprontos fornecidos pelo framework Considere o exemplo a seguir Suponha que seja necess rio verificar se a taxa de erros de um roteador R ultrapassou determinado valor Para isto um novo componente pode ser constru do a partir do GeradorDeEventoFalhaLimiar ao definir o m todo verificaOcorrenciaEventoFalha conforme descrito pela figura 4 13 os trechos de c digo apresentados a partir de agora est o escritos na linguagem Java Cria o do componente GeradorAltaTaxaDeErros public GeradorAltaTaxaDeErros extends GeradorDeEventoFalhaLimiar implements Serializable public boolean verificaOcorrenciaEventoFalha ElementoGerenciado egs Retorna true se a TaxaDeErros de R egs 0 for maior que o valor do limiar cujo nome TaxaDeErros return get InfoGerenciaDaOrigem TaxaDeErros egs 0 getDouble gt Double parseDouble getLimiares TaxaDeErros getValor Figu
49. vel definir express es de alto n vel calculadas a partir das vari veis de ger ncia mantidas nos agentes Por exemplo para definir o evento congestionamento no roteador R descrito anteriormente no requisito funcional de n mero 3 seria necess ria a seguinte express o TaxaDeTr fegoEmS TaxaDeTr fegoEmS gt Limiar os valores acima utilizados s o obtidos a partir de vari veis MIB adequadas por exemplo A solu o deve permitir definir e utilizar express es deste tipo em qualquer lugar em que a an lise da informa o de ger ncia colhida nos agentes se fizer necess ria NF3 4 A ger ncia de mem ria deve ser feita automaticamente A aloca o e a libera o das estruturas de dados necess rias para a realiza o das opera es de ger ncia n o devem ser de responsabilidade do programador Obviamente que ao configurar sua aplica o ele ter que especificar o que deve ser instanciado mas ele n o ter que se preocupar em como isto ser feito NF4 Deve haver abstra es de alto n vel facilmente utiliz veis e extens veis que atendam aos requisitos funcionais anteriormente listados facilitando a implementa o da funcionalidade da aplica o N o deve ser necess rio portanto manipular estruturas de dados complexas nem utilizar caracter sticas de uma linguagem particular que exijam consider vel experi ncia do programador no momento de utilizar ou estender as abstra es dispon v
50. 52 53 4 3 2 Monitorando a Rede 56 4 3 3 Identificando Falhas na Rede 58 4 3 4 Tratando as Falhas Identificadas 68 74 4 3 5 Fornecendo o Suporte a V rios Modelos de Ger ncia 4 3 6 Modificando os Eventos Produzidos pelos Componentes do Framework 4 3 7 Resumo 76 77 4 4 Exemplos de Aplica es 83 96 5 Uma Proposta de Implementa o 5 1 O Projeto Interno dos Componentes B sicos do Framework 5 1 1 Classes e Interfaces de Uso Interno 96 99 5 1 2 Classes Ativas 102 5 2 Ferramentas para a Composi o de Aplica es 6 Conclus es 103 109 6 1 Trabalhos Futuros Ap ndice A Frameworks 110 119 A 1 O que um Framework Ap ndice B Componentes de Software Reutiliz veis 120 123 B 1 Caracter sticas Gerais B 2 Construindo Componentes em Java Ap ndice C A Nota o UML 124 125 128 Gloss rio 130 vi ndice de Figuras Figura 2 1 Vis o f sica da rede gerenciada Figura 2 2 Primitivas de comunica o SNMP Figura 2 3 Tarefas b sicas da ger ncia de falhas Figura 2 4 Arquitetura geral de uma aplica o de ger ncia de falhas Figura 3 1 API SNMP Tcl Figura 3 2 Script para a obten o de valores em agentes SNMP Figura 3 3 Instanciando e configurando um agente SNMP Figura 3 4 Instanciando uma requisi o no modo s ncrono Figura 3 5 Ab
51. 79 Instanciar e configurar componentes para correla o de eventos qualquer componente derivado de CorrelatorDeEventoFalha inclusive componentes previamente criados pelo pr prio programador durante a etapa 1 Instanciar e configurar outros componentes do tipo EventoFalhaListener respons veis pelo tratamento de falhas e constru dos durante a etapa 1 Uma vez instanciados e configurados os componentes devem ser interconectados de acordo com o modelo fonte consumidor Cada componente gera seus pr prios eventos e determina quais tipos de componentes podem se cadastrar junto a ele para obterem a informa o produzida A saber Um Monitor gera um novo evento toda vez que novos dados s o recebidos atrav s da rede Um GeradorDeEventoFalhaLimiar e um GeradorDe EventoFalhaComHisterese podem ser a ele interconectados para receberem esta informa o a qual ser utilizada para verificar a ocorr ncia de falhas Um ReceptorDeTraps gera um novo evento toda vez que um trap SNMP for recebido Um GeradorDeEventoFalhaTrap pode ser a ele interconectado de modo a verificar a ocorr ncia de falhas com base no tipo dos traps recebidos Geradores de eventos do tipo GeradorDeEventoFalhaLimiar GeradorDeEventoFalhaTrap e GeradorDeEventoFalhaCom Histerese geram um novo evento toda vez que a falha verificada por eles ocorrer Um CorrelatorDeEventoFalha e componentes do tipo EventoFalhaListener podem ser
52. 999 H muito tempo que a id ia de maximizar a reutiliza o de coisas prontas utilizada Sistemas eletr nicos e produtos manufaturados por exemplo s o constru dos com base em componentes pr fabricados que podem ser prontamente interconectados Um conjunto bem escolhido de componentes pode ter muitas possibilidades de configura o e os produtos finais podem ser fabricados de forma mais r pida e mais confi vel Nos ltimos anos a mesma coisa tem acontecido na produ o de software e o que se observa que muitas aplica es s o agora constru das com base em frameworks diversos ou resultam da fus o de aplica es existentes poss vel por exemplo utilizar software de prateleira como um pacote de calend rio um processador de textos e uma planilha e reunir esses componentes heterog neos usando scripts de modo a resolver um problema particular de determinado dom nio de problema Componentes de software representam um importante passo no sentido de sistematizar a produ o de software ao prover reusabilidade num alto n vel de abstra o e inclusive atrav s da utiliza o apropriada de t cnicas de orienta o a objetos Padr es como CORBA Common Object Request Broker Architecture Siegel 1996 e COM Component Object Model Rofail amp Shohoud 1999 permitem conectar componentes constru dos em diferentes linguagens e plataformas e APIs como JavaBeans Sun Microsystems 1999 permitem desen
53. DeTrafegol public GeradorAltaTaxaDeTr fegol extends GeradorDeEventoFalhaLimiar implements Serializable public boolean verificaOcorrenciaEventoFalha ElementoGerenciado egs Retorna true se a soma da quantidade de conex es TCP abertas em egs 0 e egs 1 for maior que o limiar ConexoesAbertas return get InfoGerenciaDaOrigem QuantConexoesAbertas egs 0 getInteiro getInfoGerenciaDaOrigem QuantConexoesAbertas egs 1 getInteiro gt Double parseDouble getLimiares ConexoesAbertas getValor 65 Figura 4 17 GeradorAltaTaxaDeTrafegol E finalmente o programador pode configurar quantos limiares sejam necess rios para o GeradorDeEventoFalhaLimiar em quest o sendo poss vel analisar v rias unidades de informa o de ger ncia em torno de um mesmo limiar exemplos acima ou analisar cada unidade de informa o separadamente utilizando v rios limiares como mostrado no exemplo da figura 4 18 Desta maneira poss vel definir situa es de falha semanticamente mais ricas conforme o requisito F3 e assim elevar tamb m a sem ntica dos eventos EventoFalhaEvent que podem ser gerados Cada nova situa o de falha a ser analisada pode resultar na constru o de um novo componente e assim que o programador adiciona funcionalidade ao framework determinando as falhas que devem ser identificadas Ao ser poss vel definir express es de alto n vel para a an lise da
54. Especifica o de um Framework baseado em Componentes de Software Reutiliz veis para Aplica es de Ger ncia de Falhas em Redes de Computadores Raissa Dantas Freire Disserta o submetida Coordena o do Curso de P s Gradua o em Inform tica da Universidade Federal da Para ba Campus II como parte dos requisitos necess rios para obten o do grau de Mestre em Inform tica rea de Concentra o Redes de Computadores Jacques Philippe Sauv orientador Campina Grande Para ba Brasil Raissa Dantas Freire Abril de 2000 FREIRE Raissa Dantas F866E Especifica o de um Framework baseado em Componentes de Software Reutiliz veis para Aplica es de Ger ncia de Falhas em Redes de Computadores Disserta o de Mestrado Universidade Federal da Para ba Centro de Ci ncias e Tecnologia Coordena o de P s Gradua o em Inform tica Campina Grande Para ba Abril de 2000 133p IL Orientador Jacques Philippe Sauv 1 Redes de Computadores 2 Ger ncia de Redes 3 Frameworks e Componentes de Software Reutiliz veis CDU 621 391 Resumo Neste trabalho especificamos um framework baseado em componentes de software reutiliz veis com o objetivo de facilitar o desenvolvimento de aplica es de ger ncia de falhas em redes de computadores Diferentemente de outras propostas buscamos fornecer um n vel de abstra o mais adequado ao desenvolvimento deste tipo de aplica es
55. Systems Interconnection Specification of Abstract Syntax Notation One ASN 1 International Organization for Standardization International Standard 8824 December 1987 ISO IEC 8825 1987 Information Processing Systems Open Systems Interconnection Specification of Basic Encoding Rules for Abstract Notation One ASN 1 International Organization for Standardization International Standard 8825 December 1987 Ierusalimschy et al 1996 Ierusalimschy R Figueiredo L Celes W Lua An Extensible Language Software Practice and Experience 26 6 1996 114 Jakobson amp Weissman 1993 Jakobson G Weissman M D Alarm Correlation IEEE Network 7 6 52 59 November 1993 Johnson amp Roberts 1998 Johnson R E Roberts D Evolving Frameworks A Pattern Language for Developing Object Oriented Frameworks University of Illinois 1998 Johnson amp Foote 1991 Johnson R E Foote B Designing Reusable Classes Journal of Object Oriented Programming June July 1991 Johnson amp Russo 1991 Johnson R E Russo V F Reusing Object Oriented Designs University of Illinois 1991 Lajoie amp Keller 1994 Lajoie R Keller R K Design and Reuse in Object Oriented Frameworks Patterns Contracts and Motifs in Concert Proceedings of the 62nd Congress of the Association Canadienne Francaise pour l Avancement des Sciences Montreal Canada May 1994 Landin amp Niklasson 1998 Landi
56. a um agregado de componentes do tipo InfoGerenciaSnmp Cada InfoGerenciaSnmp por sua vez representa uma vari vel MIB mantida pelo agente monitorado e possui tr s propriedades principais 1 um nome que o identifica univocamente dentro do grupo ao qual pertence TaxaDeErros por exemplo 2 um oid que corresponde ao identificador espec fico da vari vel MIB representada i fInErrors por exemplo 3 um valor que dever ser retornado pelo ElementoGerenciadoSnmp e que pode ser acessado atrav s dos m todos get getString Inteiro get Double e Opera es de ger ncia se baseiam nestes grupos de maneira que ao inv s de fornecer uma nica vari vel MIB InfoGerenciaSnmp um ElementoGerenciadoSnmp pode fornecer um grupo GrupoInfoGerencia que re ne v rias destas vari veis Mas por que agrupar componentes InfoGerenciaSnmp em um componente GrupoInfoGerencia Segundo o requisito NF5 deve ser poss vel monitorar centenas de entidades gerenciadas em poucos minutos Para conseguir isto uma das coisas que pode ser feita reduzir o n mero de requisi es realizadas atrav s da rede De fato de acordo com Tanenbaum 1998 para melhorar a efici ncia de aplica es distribu das preciso reduzir o n mero de requisi es que devem ser feitas sendo prefer vel recuperar muita informa o em uma nica requisi o a recuperar pouca informa o
57. a de falhas em redes de computadores Trata se de um framework baseado em componentes de software reutiliz veis um framework CO que busca fornecer um n vel de abstra o mais elevado para a realiza o das tarefas de ger ncia de falhas Vimos que outras APIs e linguagens dispon veis para o desenvolvimento de aplica es de ger ncia exigem consider vel experi ncia de programa o por parte do programador de aplica es e que consegiientemente n o oferecem abstra es de mais alto n vel para realizar as tarefas associadas ger ncia de redes de uma maneira mais simples e mais r pida Assim ao levantar os requisitos que caracterizam um n vel de abstra o mais adequado fomos capazes de especificar o projeto de uma solu o que visa fornecer mecanismos mais elaborados para identifica o e diagn stico de falhas Diante dos requisitos levantados propomos um framework CO que fornece n o s reutiliza o de c digo mas tamb m reutiliza o de an lise e de projeto e que al m disso permite a constru o visual de aplica es Um framework CO torna poss vel a reutiliza o de an lise ao descrever os componentes importantes que est o diretamente relacionados ao dom nio do problema e as rela es entre estes componentes o projeto reutilizado medida em que a arquitetura do pr prio framework captura as principais decis es de projeto associadas ao dom nio do problema ele cont m algoritmos abstrato
58. a esta o de ger ncia como indicado pelo campo ACCESS e deve estar presente em qualquer implementa o da MIB II como indicado pelo campo STATUS A especifica o desta vari vel e de outras 189 constitui a MIB II Para efetuar a troca de informa o de ger ncia agentes e gerentes se comunicam atrav s do protocolo SNMP Simple Network Management Protocol Case et al 1990 o qual define cinco primitivas b sicas de comunica o get get next set get response e trap Estas opera es est o ilustradas na figura abaixo get get next E E Essa get response get response set erente agente erente trap agente 8 8 8 get response Figura 2 2 Primitivas de comunica o SNMP As opera es set e get permitem que o gerente possa respectivamente modificar e obter o valor de uma vari vel MIB presente num agente A opera o get next permite recuperar a vari vel seguinte ao identificador de vari vel que lhe passado de forma que poss vel percorrer uma MIB e recuperar iterativa e sequencialmente a informa o mantida pelo agente a partir das respostas obtidas com sucessivas requisi es get next til para por exemplo recuperar valores de tabelas com tamanho desconhecido A primitiva get response cont m a resposta a uma requisi o SNMP ou simplesmente o resultado da opera o no caso de uma requisi o do tipo set As opera es set get e get next s o opera es atrav s das qua
59. a por um Elemento GerenciadoSnmp e ser descrita mais adiante na se o 4 3 5 para que forne a a informa o descrita por um GrupoInfoGerencia de acordo com uma periodicidade configurada pelo programador da aplica o periodo Em outras palavras se um Monitor M est associado a um ElementoGerenciado eg se ele est interessado em obter o GrupoInfoGerencia gig deste eg e se possui um periodo de 300 segundos significa que M pedir gig a eg a cada 5 minutos O ElementoGerenciado cuida de todos os detalhes para que a informa o requisitada possa ser efetivamente recuperada atrav s da rede e retornada para o Monitor de maneira que o programador n o precise se preocupar com a abertura de sess es ou o envio de requisi es get SNMP por exemplo Tudo feito automaticamente pelo framework em atendimento ao requisito NF3 sendo transparentes para o programador os detalhes de mais baixo n vel diretamente relacionados ao protocolo de ger ncia utilizado Para coletar informa o de ger ncia nas entidades gerenciadas o programador s precisa instanciar e configurar os componentes necess rios Uma inst ncia do componente Monitor pode ser associada a uma nica entidade gerenciada ElementoGerenciado de modo que um Monitor obt m informa o de 56 ger ncia GrupoInfoGerencia de uma nica entidade da rede Por outro lado para fazer com que uma mesma entidade forne a diferentes grupos de informa o de ger
60. aDoAr o que pode n o ser interessante Deste modo componentes do tipo CorrelatorDeEventoFalhaCMP podem ser 70 utilizados para que esta repeti o de eventos seja evitada Configura se ent o a data em que as atividades de manuten o de um equipamento E ter o in cio inicioIntTempo e a data prevista para o t rmino de tais atividades fimInt Tempo Al m disso associa se o CorrelatorDeEventoFalhaCMP ao gerador que gera eventos do tipo Equipamento ForaDoAr e cuja origem do evento gerado seja igual a E O componente gerar um nico evento durante este intervalo de tempo suprimindo os demais Confira na figura abaixo e foi recebido ap s inicioIntTempo e consegiientemente foi repassado Os demais eventos e en foram recebidos ap s e e antes de fimInt Tempo sendo desconsiderados ei GeradorEquipamentoForaDoAr gt CorrelatorDeEventoFalhaCMP gt En Figura 4 25 CorrelatorDeEventoFalhaCMP O algoritmo implementado pelo componente CorrelatorDeEventoFalhaCMP portanto uma varia o do algoritmo de compress o e consiste em gerar um novo evento t o logo a primeira ocorr ncia de determinado evento seja detectada dentro do intervalo de tempo considerado As demais ocorr ncias deste mesmo evento durante este per odo de observa o s o simplesmente ignoradas Ele pode ser utilizado em diversas situa es mas por ser
61. acter sticas de um bean via padr es de projeto Para que este mecanismo de introspec o funcione programadores de beans devem seguir conven es de nomea o algumas vezes conhecidas como padr es de projeto JavaBeans Flanagan 1998 Ent o para cada bean a ser escrito as regras b sicas abaixo devem ser observadas 126 1 Propriedade deve se escrever um par de m todos de acesso Y get lt X gt e set lt X gt Y para definir uma propriedade com nome X e tipo Y 2 Evento para cada evento E que um bean deve enviar para os demais componentes cadastrados deve se escrever um par de m todos add lt E gt Listener Elistener e remove lt E gt Listener Elistener e definir as assinaturas dos m todos que a interface ELi stener deve suportar 3 M todo qualquer m todo com qualquer nome pode ser definido Tamb m poss vel implementar beans sem seguir regras de nomea o s que neste caso o bean deve fornecer explicitamente informa o sobre suas propriedades m todos e eventos atrav s da interface BeanInfo Java beans Detalhes n o ser o discutidos aqui Uma vez que os beans sejam configurados eles devem ser salvos afinal este o resultado da etapa de composi o de aplica es Desta maneira beans s o persistentes e Java prov uma forma muito simples de se ter isto Um mecanismo autom tico de serializa o atrav s do qual determinada configura o de beans pode ser salva e recuper
62. ada em outro momento pode ser utilizado Tudo que o bean deve fazer implementar a interface java io Serializable Normalmente a ferramenta visual salva e restaura determinada configura o atrav s de comandos de menu Componentes Java compilados s o empacotados em arquivos do tipo JAR Estes arquivos incluem as classes que implementam os servi os dos componentes as classes adicionais que fornecem informa o expl cita sobre propriedades m todos e eventos do bean e qualquer informa o adicional Para que um bean seja utilizado atrav s de uma ferramenta gr fica ent o ele deve ser empacotado num arquivo do tipo JAR juntamente com todas as classes e arquivos que ele requer Em resumo beans podem ser configurados s o persistentes e podem ser visualmente manipulados A linguagem Java suporta o conceito de componentes atrav s da API JavaBeans e de outros mecanismos gen ricos como reflex o e serializa o Programadores avan ados constr em componentes com base no suporte fornecido e estes componentes s o utilizados para compor aplica es atrav s de um ambiente gr fico A API JavaBeans faz parte do JDK1 1 e qualquer ferramenta compat vel com ele suporta implicitamente os conceitos e caracter sticas envolvidos 127 Ap ndice A Nota o UML A ferramenta Rational Rose Rational 1999 foi utilizada para a constru o dos gr ficos utilizados neste trabalho Trata se de uma ferramenta CASE para especi
63. ades de aplica es pertencentes a um dom nio de problema espec fico Com base nas defini es acima pode se concluir que um framework determina a arquitetura das aplica es constru das com base nele As decis es de projeto comuns s aplica es pertencentes a determinado dom nio de problema s o capturadas de forma que o programador possa se concentrar nas particularidades de sua aplica o O dom nio de problema precisa ent o ser bem delimitado e bem caracterizado para que as generalidades possam ser devidamente capturadas Quando se utiliza um framework bem projetado e bem documentado conseqiientemente an lise projeto e c digo podem ser reutilizados 120 Para configurar o framework o programador pode estender classes abstratas redefinindo os m todos necess rios O framework se encarrega de chamar os novos m todos definidos de modo que ao contr rio de bibliotecas de classes onde a aplica o faz refer ncia s classes dispon veis o framework quem chama o c digo escrito pelo programador Veja a figura A 1 Landin amp Niklasson 1998 aplica o Framework chamada aplica o Biblioteca de classes Figura A 1 Diferen a no fluxo de controle entre frameworks e bibliotecas de classes Com a utiliza o de frameworks aproveitam se n o s as decis es de projeto normalmente tomadas por especialistas no dom nio de problema para o qual o framework foi desenvolvido mas
64. alcan ar este objetivo Na tabela 3 3 comparamos as APIs e a nota o SNMA apresentadas listando suas principais caracter sticas oes 29 O n vel de abstra o desejado seria descrito pela seq ncia de respostas sim Nenhuma API entre todas as estudadas portanto capaz de fornec lo Contudo elas podem representar o ponto de partida para que solu es com melhor n vel de abstra o sejam implementadas APIs e Tcl LuaMan SNMP Manager API SNMA OVSNMP Linguagens SNMP Perl SNMP Caracter sticas Detalhes do protocolo de comunica o para a coleta de informa o de ger ncia s o N o N o Sim N o escondidos do programador Fornece abstra es de alto n vel para atender a necessidades de N o N o Sim N o ger ncia espec ficas Fornece abstra es reutiliz veis e f 7 Nao Nao Nao Nao facilmente extensiveis Mecanismos mais elaborados para o tratamento das falhas ocorridas N o N o N o Sim Independ ncia do protocolo de N o N o N o N o comunica o Tabela 3 3 Algumas APIs de ger ncia e suas caracter sticas 34 Embora uma lista completa de requisitos para uma solu o ideal seja apresentada apenas no pr ximo cap tulo o nosso trabalho prop e uma solu o para a ger ncia de falhas com uma finalidade b sica fornecer um n vel de abstra o mais adequado ao desenvolvimento de aplica es de ger ncia de falhas Ao
65. alha serve apenas para concentrar algumas das caracter sticas comuns s suas subclasses A classe MonitorEvent e as interfaces MonitorListener e Trap Listener por sua vez juntamente com as classes TrapEvent e EventoFalhaEvent e com a interface EventoFalhaListener determinam as associa es que podem ser estabelecidas entre os componentes do framework viabilizando a implementa o do modelo de execu o baseado em fontes e consumidores de eventos conforme descrito pela figura 4 31 A classe MonitorEvent representa os eventos gerados pelo componente Monitor os quais cont m conseqiientemente os resultados das monitora es realizadas Para receber eventos deste tipo um componente deve implementar a interface MonitorListener e deve se cadastrar na inst ncia do Monitor que fornece os eventos de interesse Assim sendo as classes GeradorDeEventoFalhaLimiar e Gerador DeEventoFalhaComHisterese implementam a interface MonitorListener de modo que componentes deste tipo possam ser conectados a componentes do tipo Monitor recebendo a informa o necess ria identifica o de falhas na rede Analogamente para receber os eventos que descrevem os traps gerados na rede isto eventos do tipo TrapEvent um componente deve implementar a interface TrapListener e deve se cadastrar na inst ncia do ReceptorDeTraps respons vel pela monitora o ass ncrona da rede A classe GeradorDeEventoFalhaTrap ent o imple
66. alho est em reunir conceitos pertinentes ger ncia de falhas e propor mecanismos para facilitar o desenvolvimento deste tipo de aplica o Assim ele serve como ponto de partida para a implementa o de solu es de ger ncia que busquem efetivamente atender s necessidades do programador de aplica es de ger ncia de falhas 1 3 Estrutura da Disserta o No cap tulo 2 apresentamos alguns conceitos relacionados ger ncia de redes e em particular ger ncia de falhas O leitor bem familiarizado com esta rea de conhecimento pode iniciar sua leitura a partir do cap tulo seguinte No cap tulo 3 apresentamos diversas APIs e linguagens voltadas especificamente para a ger ncia de redes e exemplificamos como as aplica es podem ser desenvolvidas com base no n vel de abstra o fornecido Comparamos as solu es apresentadas e conclu mos ent o que tal nivel de abstra o n o se mostra adequado para o desenvolvimento de aplica es espec ficas de ger ncia de falhas No cap tulo 4 especificamos um framework baseado em componentes de software reutiliz veis para a ger ncia de falhas Levantamos seus requisitos e identificamos suas caracter sticas no sentido de atender aos requisitos levantados No cap tulo 5 fornecemos uma proposta de implementa o particular Discutimos alguns aspectos de implementa o importantes segundo a utiliza o de padr es de projeto Gamma et al 1994 e de caracter
67. ar as decis es de projeto que s o comuns ao dom nio de problema no qual a aplica o est inserida permitindo ao programador se concentrar nas particularidades de sua aplica o Deve se fornecer um framework que capture o comportamento gen rico apresentado por aplica es de ger ncia de falhas e que permita reutilizar a arquitetura resultante para gerenciar falhas na rede Conforme explicado no ap ndice A frameworks s o geralmente implementados atrav s da orienta o a objetos OO Desta forma pode se definir um framework como um conjunto de classes concretas e abstratas que cooperam entre si fornecendo um projeto reutiliz vel para uma classe espec fica de software Gamma et al 1994 Para construir uma aplica o com base num framework OO deve se estender as classes abstratas fornecidas introduzindo as especificidades da aplica o e o resto fica a cargo do framework que de fato tem o controle sobre a funcionalidade da aplica o desenvolvida Entretanto de modo a permitir a constru o visual da aplica o ainda conforme requisito NF6 facilitando ainda mais a constru o de aplica es de ger ncia de falhas deve 46 se ter n o um framework OO mas um framework CO Component Oriented isto um framework baseado em componentes de software reutiliz veis D Souza amp Wills 1999 Ao utilizar componentes poss vel construir a aplica o atrav s de um ambiente gr fico ao configurar e inte
68. ar seu cadastro junto a uma determinada fonte dinamicamente sem alterar a fonte ou qualquer outro consumidor j cadastrado A figura 4 3 descreve a situa o em que A consumidor dos eventos gerados por B Adicionalmente B tamb m deve enviar os eventos gerados para C A se cadastra em B C se cadastra em B B envia evento para A B envia evento para C Figura 4 3 Fonte B e consumidores de eventos A e C Um mesmo componente ainda pode ser ao mesmo tempo fonte e consumidor de eventos componente processador de modo que qualquer fluxo de execu o resultante da associa o entre os componentes do framework pode ser genericamente descrito pela figura abaixo Nesta figura h um componente fonte F um componente consumidor C e um 50 P se cadastra em F C se cadastra em P componente processador P Este ltimo componente consumidor de eventos de F e fonte de eventos para C simultaneamente DO y F envia evento para P ES P envia evento para C Figura 4 4 Modelo geral de execu o Segue um exemplo pr tico da utiliza o deste modelo Suponha que haja um componente respons vel por fazer monitora o s ncrona Monitor M outro respons vel por verificar a ocorr ncia da falha espec fica interface do roteador R com defeitos GeradorDeEventos Gs e outro respons vel por gerar um alarme quando a falha ocorrer GeradorDeAlarmes Ga Para que o operador da rede seja notificado sobre a ocorr ncia
69. as propriedades poss vel configurar cada uma das entidades da rede com as quais a 7 Neste cap tulo utilizamos uma classe UML para representar um componente por falta de um s mbolo mais apropriado A lingu ElementoGerenciadoSnmp tro tipo de ling ConfiguradorDeRequisicaoSnmp grama o n o nome String nome String fornecem suporte ni sresponsavel String nentes de softw timeout int numero Retransmissoes int omunidade String p em de uma ontatoResponsavel String prioridade int endlp String simbologia mais ade verdade confor nponente pode ser formado n o s al m de outros Os componentes ElementoGerenciadoSnmp InfoGerenciaSnmp e ReceptorDeTrapsSnmp cuidam de caracter sticas espec ficas do SNMP Mais a seguir para satisfazer o requisito NF1 veremos como a independ ncia de protocolo de ger ncia pode ser conseguida 53 aplica o deve estabelecer algum tipo de comunica o Em todas as figuras apresentadas nesta se o cada propriedade tem dois m todos de acesso que permitem obter get e atualizar set o seu valor Figura 4 7 ElementoGerenciadoSnmp Cada ElementoGerenciadoSnmp identificado atrav s de um nome o qual consequentemente deve ser nico para cada ElementoGerenciadoSnmp instanciado pela aplica o Al m disso ele possui um endere o IP endIp que permite localizar o agente SNMP representado Este tipo de componente
70. azem parte e melhor pode ser a identifica o deste comportamento comum que deve ser embutido no framework Escolhemos ent o a ger ncia N o h uma boa tradu o para o termo framework quando se fala em desenvolvimento de software Segundo dicion rios da l ngua inglesa framework significa estrutura palavra bastante gen rica que n o exprime o significado particular que gostar amos de destacar Sendo assim preferimos n o traduzi lo mas optamos por usar uma defini o semanticamente mais completa um framework um conjunto de classes no sentido de orienta o a objetos coesas que colaboram entre si para compor um projeto reutiliz vel para uma classe espec fica de software Gamma et al 1994 No nosso caso este projeto descrito em termos de componentes de software reutiliz veis Um estudo sobre frameworks pode ser encontrado em Landin amp Niklasson 1998 e uma vis o geral sobre o assunto fornecida no ap ndice A de falhas por ser esta uma das reas mais importantes da ger ncia de redes Identificamos os requisitos funcionais da solu o tendo em vista as aplica es de ger ncia de falhas Para atender aos requisitos levantados especificamos um framework CO conforme j foi antecipado Os conceitos envolvidos se baseiam por excel ncia na utiliza o de t cnicas de orienta o a objetos e toda a especifica o fornecida serve de base para implementa es futuras A import ncia do trab
71. campo ACCESS read write Destas 30 20 descrevem informa o sobre roteamento grupo IP da MIB II e servem basicamente para indicar as rotas e as m tricas a serem utilizadas A configura o de rotas por sua vez depende normalmente de outros protocolos espec ficos de forma que altera es feitas nestas vari veis n o surtir o os efeitos desejados De fato a configura o de dispositivos raramente feita atrav s de protocolos de ger ncia de redes e sendo assim parece aceit vel dispensar o comando set em nosso contexto espec fico haja vista que para identificar e diagnosticar falhas necess rio e suficiente recuperar ler os valores das vari veis de interesse Requisitos n o funcionais NF1 A solu o deve ser independente de protocolo de ger ncia A solu o deve ser suficientemente flex vel a ponto de acomodar qualquer modelo de ger ncia potencialmente suportado Al m disso ela deve permitir a interopera o entre os diferentes modelos para que seja poss vel construir 42 aplica es capazes de gerenciar simultaneamente diferentes agentes independentemente do modelo de ger ncia que eles suportam NF2 A solu o deve fornecer por default suporte ao SNMP em todas as suas vers es SNMPv1 SNMPv2C e SNMPyv3 Embora seja independente de protocolo de ger ncia a solu o deve fornecer o suporte default ao SNMP NF3 Os detalhes de baixo n vel diretamente relacionados com o protocolo d
72. ctar se um mesmo evento ocorreu determinado n mero de vezes k dentro de um intervalo de tempo substituindo os k eventos ocorridos por um nico evento t o logo k seja atingido Sendo assim para utilizar o CorrelatorDeEventoFalhaSupressao necess rio configurar n o s o per odo de observa o intervaloDeTempo mas tamb m o valor de k contador ou seja o n mero m ximo de vezes que o evento pode ocorrer antes que um novo evento seja gerado Al m disso preciso associ lo ao gerador de eventos que verifica a ocorr ncia do evento a ser correlacionado Na figura 4 24 por exemplo o CorrelatorDeEventoFalhaSupressao possui um contador igual a 3 unidades e um intervaloDeTempo igual a 30 minutos Ele gerar um novo evento es t o logo receba tr s eventos e e 3 de GeradorAltaTaxaDeErros neste intervalo de tempo GeradorAltaTaxaDeErros g CorrelatorDeEventoFalhaSupressao e C2 E sy gt es Figura 4 24 CorrelatorDeEventoFalhaSupressao O algoritmo CMP por sua vez consiste em evitar a repeti o de eventos decorrentes de atividades de manuten o realizadas em equipamentos da rede De fato equipamentos da rede que precisam de algum tipo de manuten o podem ficar temporariamente inacess veis ser o desligados ou simplesmente desconectados da rede e isto pode levar ocorr ncia de m ltiplos eventos do tipo EquipamentoFor
73. da do Monitor monitor gHisterese nome TaxaDeErrosAlta origem R prioridade prioridadeAlta nomeEventoRearm TaxaDeErrosOk prioridadeEvent oRearm prioridadeBaixa rearm x limiar y gig grupoIG 1 2 5 Um GeradorDeAlarmesHisterese gAlarmes para notificar sobre uma alta taxa de erros em R 1 3 Interconex o dos componentes H outras propriedades que o leitor pode conferir em http www dsc ufpb br raissa doc frame html 84 1 3 1 Associamos o ElementoGerenciadoSnmp R e o GrupolInfo Gerencia grupoIG ao Monitor monitor informando ao monitor qual informa o de ger ncia ele deve obter e de onde 1 3 2 Associamos o GeradorDeEventoFalhaComHisterese gHisterese ao Monitor monitor para que gHisterese possa obter o resultado da monitora o feita pelo monitor 1 3 3 Associamos o GeradorDeAlarmesHisterese gAlarmes ao GeradorDeEventoFalhaComHisterese gHisterese para que toda vez que a falha verificada por gHi sterese ocorrer isto toda vez que a taxa de erros ultrapassar o limiar configurado um alarme seja disparado O diagrama de seqii ncia da figura 4 32 mostra o fluxo de eventos resultante da associa es descritas R monitor gHisterese gAlarmes pede giga R lt fornece gi gig gt envia dados monitorados envia evento falha Figu
74. de configura o etc Em geral para realizar a coleta de dados programadores ainda precisam conhecer e manipular estruturas de dados complexas tratar erros de comunica o decorrentes da opera o do protocolo de ger ncia utilizado tornar expl cita a realiza o de opera es de ger ncia enfim tratar de aspectos de baixo n vel que n o est o diretamente associados funcionalidade espec fica de sua aplica o Por mais importante necess ria e complexa que seja a coleta de dados n o ger ncia de redes mas apenas um pr requisito para essa ger ncia e sendo assim programadores gerentes e operadores de redes n o gostariam nem deveriam gastar muito esfor o aqui mas gostariam de contar com outros recursos e mecanismos mais diretamente voltados a atender a necessidades de ger ncia espec ficas como o tratamento de falhas ou a defini o de pol ticas de seguran a Nesse sentido as APIs dispon veis n o fornecem uma interface mais inteligente capaz de prover maior reusabilidade e consegiientemente maior produtividade A SNMA por sua vez representa algum ganho com rela o s demais APIs apresentadas e citadas Para obter informa o de ger ncia por exemplo o programador n o 32 precisa se preocupar com detalhes do protocolo de ger ncia utilizado Al m disso a SNMA foi a nica que se preocupou em seu projeto em identificar e prover abstra es de mais alto n vel ao considerar as necessida
75. de falha na rede F3 O primeiro objetivo de uma aplica o de ger ncia de falhas identificar as falhas ocorridas na rede Para isto preciso antes de tudo definir os eventos que as descrevem pois a partir da verifica o da ocorr ncia destes eventos que torna se poss vel detectar automaticamente as falhas ocorridas A defini o de eventos se baseia na an lise da informa o de ger ncia colhida nos agentes da rede tal informa o obtida atrav s de monitora o s ncrona ou ass ncrona deve estar dispon vel Dizemos que um evento ocorreu quando a condi o que o define for satisfeita Por exemplo o evento rota inacess vel ocorrer se uma alta taxa de perda de pacotes for observada na interface do roteador que d acesso a esta rota Limiares s o comumente utilizados para definir estas condi es refletindo as pol ticas de ger ncia a serem aplicadas para atender necessidades espec ficas Usando a informa o de ger ncia dispon vel deve ser poss vel definir eventos que descrevam situa es de falha semanticamente mais ricas Muitas vezes a detec o de uma falha defini o de um evento trivial no sentido em que ela resulta da an lise de uma nica vari vel de ger ncia em torno de um nico limiar ou valor de refer ncia Por exemplo o fato de que o estado de opera o de determinada interface foi modificado vari vel MIB 38 ifOperStatus DOWN indicando que ela esta
76. de forma que o programador possa concentrar seus esfor os na implementa o da funcionalidade b sica de sua aplica o tendo em vista as abstra es fornecidas Consideramos em especial a identifica o dos recursos e facilidades que devem estar dispon veis e apresentamos adicionalmente uma proposta de implementa o particular Abstract This dissertation presents a component based framework The objective is to ease the development of fault management applications for computer networks Differently from other approaches the proposed solution provides an appropriate level of abstraction for the development of this type of application and enables the application developer to concentrate on the desired solutions rather than on low level details We identify and characterize the necessary abstractions and present a particular implementation approach li Ser mestre n o significa apenas obter resultados mas significa sobretudo trilhar os caminhos que levam at eles com conhecimento t cnico e senso cr tico iii Agradecimentos Gostaria de agradecer primeiramente a Deus pela possibilidade de realizar este trabalho Nos momentos mais dif ceis senti me amparada no seu amor A minha m e Evani pelo apoio e compreens o Se cheguei at aqui grande parte da culpa dela Seus exemplos de for a e coragem sempre me nortear o Ao meu orientador Prof Jacques pela confian a e paci ncia Obrigada pela
77. de monitora o de S e outro para controlar a frequ ncia de monitora o de S232 monitor periodo 300s monitor periodo 300s 2 2 5 Um GeradorTaxaDeTrafegoAlta gTrafegoAlto para verificar o congestionamento em R a partir da informa o obtida dos monitores monitor emonitor gTrafegoAlto nome TaxaDeTrafegoAlta origem R prioridade prioridadeAlta limiares QuantConexoesAbertas 15 CTaxaDeTrafego 500K 2 2 6 Um GeradorDeAlarmes gAlarmes para notificar o operador da rede sobre o congestionamento em R 2 3 Interconex o dos componentes 87 2 3 1 Associamos o ElementoGerenciadoSnmp S e o GrupolInfo Gerencia grupoIG ao Monitor monitor informando ao monitor qual informa o de ger ncia ele deve obter e de onde 2 3 2 Associamos o ElementoGerenciadoSnmp S2 e o GrupolInfo Gerencia grupoIG ao Monitor monitor informando ao monitor qual informa o de ger ncia ele deve obter e de onde 2 3 3 Associamos o GeradorTaxaDeTrafegoAlta gTrafegoAlto aos monitores monitor e monitor para que gTrafegoAlto possa obter o resultado da monitora o feita por ambos Sik monitori S2 monitor2 gTrafegoAlto gAlarmes pede grupolG1 a st fornece grupolG1 pede grupolG2 fornece grupolG2 envia dados dados monitora
78. des espec ficas de sub reas da ger ncia de redes Entretanto ela n o se mostra uma nota o suficientemente flex vel e reutiliz vel Primeiramente a SNMA uma linguagem totalmente nova e ao definir uma sintaxe pr pria novos interpretadores e compiladores tiveram que ser implementados Para simplificar esta tarefa apenas os seguintes comandos essenciais de fluxo de controle podem ser utilizados IF THEN ELSE GOTO e RETURN e o programador deve se satisfazer com isto N o parece conveniente portanto especificar uma linguagem totalmente nova mas deve se utilizar uma das linguagens hospedeiras dispon veis adicionando lhe as facilidades necess rias As abstra es construtores dispon veis tamb m n o podem ser estendidas ou modificadas para acomodar necessidades espec ficas de uma aplica o particular Os construtores possuem um conjunto de campos invari vel e o m ximo que o programador pode fazer omitir um ou mais campos opcionais conforme necess rio N o h a possibilidade de acrescentar campos caracterizando melhor uma situa o espec fica Um construtor POLLED EVENT por exemplo jamais poderia ter um campo que descrevesse a prioridade do evento permitindo que filtros pudessem ser definidos com base nesta caracter stica Tamb m n o h como se ter acesso aos campos dos construtores para modificar o comportamento da aplica o em tempo de execu o Por exemplo n o h c
79. desenvolvimento de aplica es de ger ncia de falhas A partir do estudo de alguns exemplos de aplica es de ger ncia de falhas e com base no exposto na se o 3 5 onde foi caracterizado o n vel de abstra o desejado seguem 38 lt nn Pe e5 abaixo os requisitos funcionais e os requisitos nao funcionais a serem atendidos 5 Sead y o e m y e Requisitos funcionais s o aqueles requisitos que devem ser atendidos para prover a funcionalidade da solu o Requisitos n o funcionais especificam outras restri es impostas solu o como aquelas relacionadas com a ado o de padr es e integra o com outros sistemas pol ticas externas custos desempenho portabilidade etc 37 Requisitos funcionais F1 Deve ser poss vel fazer monitora o s ncrona e monitora o ass ncrona A tarefa de monitora o consiste em obter efetivamente a informa o de ger ncia mantida pelos agentes da rede eventos s o definidos com base nesta informa o Para isto necess rio realizar dois tipos de monitora o s ncrona e ass ncrona No primeiro caso a aplica o gerente deve buscar periodicamente a informa o nos agentes gerenciados tal periodicidade ou freqii ncia deve ser facilmente configur vel No segundo caso necess rio preparar se para receber a qualquer momento a informa o enviada pelos agentes traps SNMP por exemplo F2 Deve ser poss vel descrever situa es
80. dor pode ter acesso informa o contida no GrupoInfo Gerencia fornecido por qualquer uma das entidades monitoradas Retorna verdadeiro true se a condi o analisada for satisfeita isto se a falha verificada ocorreu No caso de um GeradorDeEventoFalhaTrap o m todo verifica OcorrenciaEventoFalha TrapEvent trap recebe o trap trap enviado pelo ReceptorDeTrapsSnmp O programador pode ent o ter acesso informa o contida no trap para verificar a ocorr ncia de um evento retornando verdadeiro true no caso em que a falha verificada tenha realmente ocorrido Um TrapEvent possui um tipo uma origem uma data que indica o instante em que o trap ocorreu timeStamp e a informa o de ger ncia gig enviada pela pr pria entidade geradora do trap a origem A figura 4 15 apresenta um TrapEvent com todas as suas propriedades e m todos de obten o dos valores citados TrapEvent trapLinkUp trapLinkDown trapEspecifico gera trapColdStart aa trapWarm Start a trapFalhaDeAutenticacao 1 envia TrapEvent rigemDoTrap ElementoGerenciado ipoDeTrap int imeStamp Date ig GrupolnfoGerencia GeradorDeEventoFalha 62 ReceptorDeT rapsSnmp getOrigemDoTrap getTipoDoT rap getTimeStamp atRinal Figura 4 15 TrapEvent Assim para avaliar a ocorr ncia de falhas o programador pode utilizar a informa o GrupoIn
81. dos envia dados monitorados envia evento falha Figura 4 33 Exemplo 2 2 3 4 Associamos o GeradorDeAlarmes gAlarmes ao GeradorTaxaDe TrafegoAlta gTrafegoAlto para que toda vez que a falha verificada por gTrafegoAlto ocorrer ou seja toda vez que a taxa de tr fego ultrapassar o limiar configurado um alarme seja disparado 88 O diagrama de seqii ncia da figura 4 33 mostra o fluxo de eventos resultante da associa es descritas Exemplo 3 Deseja se monitorar os roteadores de uma rede Rj Ro Rs O operador da rede deve ser notificado sempre que uma das interfaces de cada roteador estiver com problemas down mas o operador s deve saber se houve problema em R caso este problema seja observado mais de uma vez na ltima meia hora Quando a taxa de pacotes descartados por Rs atingir determinado valor deve se monitor lo mais frequentemente a fim de que se possa identificar um congestionamento o mais r pido poss vel T o logo a situa o se normalize deve se voltar freqii ncia de monitora o normal x Deve se notificar o operador da rede quando houver um congestionamento em R3 Deve se registrar cada uma das ocorr ncias acima 3 1 Constru o de novos componentes 3 1 1 Um GeradorLinkl Down para verificar se o trap recebido do tipo linkDown GeradorLinkDown extends GeradorDel EventoFalhaTra
82. e ger ncia utilizado devem ser transparentes para o programador Neste sentido enumeramos os seguintes t picos NF3 1 Deve ser transparente para o programador de aplica es o uso das primitivas de comunica o de baixo n vel como get ou get next bem como o estabelecimento de sess es de ger ncia O programador est apenas interessado em utilizar a informa o de ger ncia e n o em como recuper la NF3 2 Devem ser fornecidos mecanismos autom ticos de recupera o de erros decorrentes da utiliza o do protocolo de ger ncia utilizado No protocolo SNMP um erro do tipo tooBig por exemplo o qual indica que uma resposta a uma requisi o SNMP muito grande para ser enviada num nico pacote de informa o nada tem a ver com a funcionalidade implementada pela aplica o e consegiientemente deve ser tratado de maneira tal que o programador nem tome conhecimento de sua ocorr ncia se a resposta realmente maior que o tamanho m ximo do pacote de informa o que pode ser enviado ent o que a requisi o seja automaticamente refeita quebrada em sub requisi es de maneira a contornar o problema Al m disso quando uma auto recupera o n o puder ser feita a aplica o deve ser devidamente notificada Algumas APIs j fornecem op es para recupera o autom tica de erros SNMP o caso do m todo setPduFixedOnError da API de ger ncia Java vista na se o 3 2 43 NF3 3 Deve ser poss
83. e gerar este novo tipo de evento conforme descrito pela figura abaixo Cria o de um novo tipo de evento public EventoFalhaNovo extends EventoFalhaEvent Niveis de prioridade adicionais public static final prioridadeMuitoAlta 400 public static final prioridadeMuitoBaixa 50 76 Construtor public EventoFalhaNovo super Cria o do gerador que gera eventos do tipo EventoFalhaNovo public GeradorEventoFalhaNovo extends GeradorDeEventoFalhaLimiar implements Serializable Redefine o m todo criaEventoFalha de modo a gerar o novo tipo de evento public EventoFalhaEvent criaEventoFalha return new EventoFalhaNovo public boolean verificaOcorrenciaEventoFalha ElementoGerenciado egs Figura 4 30 Gerando novos tipos de eventos O GeradorEventoFalhaNovo passa a gerar o novo tipo de evento EventoFalhaNovo conforme especificado pelo m todo criaEventoFalha e assim a aplica o pode manipular a informa o adicional de forma conveniente Tamb m poss vel modificar o tipo de trap repassado por componentes do tipo ReceptorDeTraps Para isto deve se estender a classe TrapEvent e deve se fazer com que o ReceptorDeTraps repasse o novo tipo de trap especificado TrapEvent portanto uma classe que pode ser utilizada para fazer com que o framework possa reconhecer traps definidos pelo p
84. e o trap recebido foi gerado por R e se tem o tipo 1inkDown especificado atrav s do m todo verificaOcorrenciaEventoFalha portanto que o programador da aplica o descreve situa es de falha na rede em conformidade com o requisito F2 tamb m neste momento que ele precisa realmente programar ou seja escrever trechos de c digo de modo a construir novos componentes para identifica o de falhas conforme as necessidades da aplica o O framework especifica os par metros de entrada e os m todos que podem ser utilizados para que o m todo verificaOcorrenciaEvento Falha possa ser definido 61 Par metros de entrada O programador tem acesso informa o de ger ncia enviada pelo Monitor ou pelo ReceptorDeTrapsSnmp atrav s dos par metros de entrada do m todo verifica0OcorrenciaEventoFalha No caso de um GeradorDeEventoFalhaLimiar o m todo verifica OcorrenciakventoFalha ElementoGerenciado egs recebe a cole o de entidades gerenciadas egs de onde o GeradorDeEvento FalhaLimiar obt m informa o isto a cole o de entidades gerenciadas monitoradas pelos monitores com os quais o GeradorDeEventoFalhaLimiar est associado A partir da o programador pode ter acesso informa o contida no GrupoInfoGerencia fornecido por cada uma delas Para a situa o em que o mesmo GeradorDeEventoFalhaLimiar esteja associado a v rios monitores o portanto o programa
85. ecess rios atrav s de um modelo de execu o simples e flex vel para que da coopera o entre os 52 componentes interconectados obtenha se a funcionalidade de cada aplica o Resta saber ent o 1 Quais s o os componentes que o framework deve fornecer 2 Quais componentes podem ser simplesmente configurados e quais podem ser completados de forma a originar novos componentes conforme necess rio 3 Quais classes e interfaces adicionais devem estar dispon veis 4 Como os componentes instanciados podem ser interconectados isto quem produz e quem consome eventos Mais uma vez tendo em vista os requisitos listados na se o 4 1 poss vel identificar os componentes classes e interfaces a serem fornecidos pelo framework bem como as rela es que podem ser estabelecidas entre os componentes instanciados Tudo isto ser descrito a partir de agora 4 3 1 Descrevendo a Rede Gerenciada Antes de qualquer coisa o framework deve permitir configurar o ambiente a ser gerenciado Em outras palavras para construir qualquer aplica o de ger ncia necess rio descrever quais entidades da rede roteadores switches esta es de trabalho etc devem ser gerenciadas e qual a informa o de interesse Para isto tr s componentes foram especificados ElementoGerenciadoSnmp InfoGerenciaSnmp e GrupoInfoGerencia A figura abaixo mostra o componente ElementoGerenciadoSnmp Atrav s de su
86. efinido ED EVENT ServidorForaDoAr CONDITION InterfaceDefeituosa PO L PERIOD 15 15 minutos ACTION corrigeFalha AGE INT SET servidores SN EDURE corrigeFalha LOG Falha no servidor hit_location P SET desligaInterface ifAdminStatus DOWN E CUTE habilitaServidorRedundante De acordo com Defeituosa avaliada a Figura 3 10 Defini o de um evento s ncrono a figura acima o evento ocorrer se condi o Interface cada 15 minutos for satisfeita O procedimento corrigeFalha gera um registro que identifica onde ocorreu a falha Ghit location altera o estado da interface para DOWN e executa um programa externo habilitaServidorRedundante o qual deve substituir o ser Analogamente vidor com problemas por um outro servidor poss vel definir um evento ass ncrono conforme descrito pela figura 3 11 O evento ServidorOk ocorrer se a interface de um dos Servidores voltar ao seu estado de opera o normal TRAP KIND InterfaceOk Neste caso executa se um outro programa externo desabilitaServidorRedundante que deve fazer com que o servidor gerador do trap 1 nterfaceOk volte opera o normal desabilitando o servidor redundante que estava em seu lugar TRAP InterfaceOk ORIGIN Servidores TYPE linkUp TRAP EVENT ServidorOk TRAP KIND InterfaceOk
87. eis Desta forma escrever uma aplica o pequena que monitore algumas situa es de falha espec ficas em dezenas de agentes n o deve custar mais de 1 hora de trabalho NFS Deve ser poss vel monitorar centenas de agentes em poucos minutos Trata se aqui de uma quest o de desempenho A aplica o n o deve sofrer os efeitos de uma monitora o lenta em decorr ncia da quantidade de agentes que devem ser monitorados e da quantidade de informa o que deve ser obtida NF6 A solu o deve exigir o m nimo de programa o 44 Idealmente deve ser poss vel construir a aplica o visualmente NF7 A solu o deve fornecer portabilidade A aplica o de ger ncia resultante deve ser facilmente transport vel para os principais ambientes operacionais em uso Windows NT e UNIX Estes s o portanto os requisitos b sicos que devem ser atendidos de modo a satisfazer as necessidades do programador de aplica es de ger ncia de falhas Certamente uma solu o final exige uma lista de requisitos mais completa que considere por exemplo outros aspectos relacionados a desempenho ou seguran a Neste trabalho entretanto concentramo nos nos requisitos listados na certeza de que o atendimento a tais requisitos j caracterizam bem a solu o a ser fornecida A partir da pr xima se o apresentada uma solu o que atende a tais requisitos de forma conveniente 4 2 O Projeto Arquitetural Para atender aos requisitos
88. el para que se possa resolver o problema eficazmente e assim curar os poss veis efeitos causados O diagn stico de falhas tamb m envolve a correla o de eventos para fornecer melhores resultados Por fim a tarefa de corre o consiste em formular a es corretivas que possam restabelecer o estado da rede para um estado normal livre de falhas A es podem ser sugeridas de forma autom tica e outras aplica es normalmente conhecidas como aplica es de trouble ticketing ou aplica es de acompanhamento de ocorr ncias podem ser utilizadas para controlar o processo de resolu o de problemas Defini o 4 Um ticket um registro que descreve o tempo de vida de um problema Sistemas de acompanhamento de ocorr ncias podem ajudar durante o processo de corre o de falhas Enquanto o problema n o efetivamente resolvido as a es realizadas s o registradas num ticket que pode inclusive trafegar atrav s da rede permitindo sincronismo e uma maior integra o entre as pessoas envolvidas na resolu o de determinado problema Madruga amp Tarouco 1994 O ticket aberto t o logo o problema seja identificado e s fechado quando o problema resolvido guardando todo o hist rico do tempo de vida do problema Uma descri o do problema as a es corretivas aplicadas as pessoas e empresas envolvidas e o tempo de resolu o do problema s o algumas das informa es mantidas Sistema
89. elecionar determinado evento com base em par metros previamente configurados A origem do evento por exemplo pode servir como par metro de filtragem Relacionamento Temporal a correla o depende da ordem ou do tempo em que os eventos ocorrem H ainda muitos m todos e algoritmos Algumas dessas abordagens s o probabilistas outras utilizam paradigmas tradicionais da Intelig ncia Artificial Uma descri o mais detalhada para abordagens como correla o baseada em regras correla o por 15 codifica o ou correla o distribu da bem como uma compara o entre as abordagens existentes podem ser encontradas em Meira 1997 A escolha do tipo de correla o a ser realizada e da abordagem a ser adotada vai depender do objetivo da correla o o qual pode ser simplesmente a redu o de informa o enviada ao gerente ou algo mais elaborado como a localiza o e o diagn stico de falhas A correla o de eventos pode ser aplicada a qualquer uma das cinco reas funcionais de ger ncia mas a maioria das aplica es que a utilizam encontradas na literatura t m a funcionalidade espec fica de ger ncia de falhas Na verdade em qualquer rea onde o volume de informa es envolvido muito grande a correla o de eventos pode ser til 2 3 2 Arquitetura Geral de uma Aplica o de Ger ncia de Falhas Aplica es de ger ncia de falhas distintas t m suas particularidades mas a fim de prover sua funcio
90. eling Language Addison Wesley 1998 113 Gamma et al 1994 Gamma E Helm R Johnson R Vlissides J Design Patterns Elements of Reusable Object Oriented Software Addison Wesley 1994 Gibson et al 1996 Gibson J Terplan K Huntington Lee HP Open View A Manager s Guide McGraw Hill 1996 Gosselin 1999 Gosselin C A Tool made in Perl using the HP OpenView SNMPvlI API On line http www info ugam ca gosselin programm htm Govoni 1999 Govoni J Java Application Frameworks John Wiley amp Sons 1999 Hewlett Packard 1998a Hewlett Packard Company SNMP Developer s Guide Edition 1 November 1998 Hewlett Packard 1998b Hewlett Packard Company HP OpenView Windows Developer s Guide Edition 1 November 1998 Houck et al 1995 Houck K Calo S Finkel A Towards a Practical Alarm Correlation System In IFIP TEEE International Symposium on Integrated Network Management IV ISINM 95 1995 pp 226 237 ILOG 1999 ILOG Corporate Information Company ILOG TGF Powerful Framework for Network and Service Management User Interfaces White Paper 1999 On line http www ilog com products tgf ISO IEC 7498 1984 Information Processing Systems Open Systems Interconnection Basic Reference Model International Organization for Standardization and International Electrotechnical Committee International Standard 7498 1984 ISO IEC 8824 1987 Information Processing Systems Open
91. em desenvolver unidades de software gen ricas e extens veis Projetistas devem prever a utiliza o futura do software a ser produzido e devem incluir os requisitos previstos no projeto corrente Tradicionalmente isto tem sido feito atrav s de bibliotecas de fun es procedurais espec ficas de um determinado dom nio de problema ou atrav s de bibliotecas de classes reutiliz veis O problema que se torna dif cil prover um comportamento padr o e introduzir conhecimento sobre o dom nio do problema numa biblioteca Landin amp Niklasson 1998 Uma biblioteca como estas cont m pequenos m dulos funcionais a partir dos quais o programador deve construir uma determinada aplica o e desenvolver uma aplica o com base em pequenos m dulos exige que a comunica o entre os diferentes m dulos utilizados ainda seja definida Estes problemas podem ser aliviados atrav s da utiliza o de frameworks O programador n o precisa saber como ou quando chamar cada fun o o framework faz isto para ele Diz se portanto que frameworks se baseiam no Hollywood Principle Don t call us we ll call you A comunica o entre os m dulos funcionais do framework j est 119 internamente definida e o programador n o precisa se preocupar com isto Lajoie amp Keller 1994 Geralmente um framework consiste de um conjunto de classes e poderia ent o ser considerado uma biblioteca de classes Isto n o inteiram
92. ementam os algoritmos de correla o conhecidos respectivamente como compress o supress o e controle de manuten o programada CMP CorrelatorDeEventoFalhaCompressao CorrelatorDeEventoFalhaSupressao CorrelatorDeEventoFalhaCMP EBintervaloDeTempo long ontador int EHiniciolntTempo Date E long Es Date EBgeiQuantOcorrencias Figura 4 22 Componentes para a correla o de eventos O algoritmo de compress o conforme descrito na se o 2 3 1 consiste em detectar m ltiplas ocorr ncias de um mesmo evento em um dado intervalo de tempo substituindo os eventos ocorridos por um nico evento possivelmente indicando quantas vezes o evento ocorreu durante o per odo de observa o Para utilizar o componente CorrelatorDe EventoFalhaCompressao basta configurar este per odo de observa o intervaloDe Tempo e associ lo ao gerador que verifica a ocorr ncia do evento a ser considerado Na 69 figura abaixo por exemplo o CorrelatorDeEventoFalhaCompressao comprime os eventos ey n recebidos de GeradorLinkDown durante 30 minutos intervaloDe Tempo 30min gerando um nico evento es ao final deste intervalo de tempo el GeradorLink Down gt CorrelatorDeEventoFalhaCompressao s Cn Figura 4 23 CorrelatorDeEventoFalhaCompressao O algoritmo de supress o tamb m descrito na se o 2 3 1 consiste em dete
93. ente verdade desde que numa biblioteca de classes cada classe vista individualmente e a maioria das classes num framework s o dependentes umas das outras n o tendo utilidade fora deste contexto Assim frameworks prov em reusabilidade num nivel mais alto de abstra o a partir da funcionalidade resultante da combina o intera o de suas classes fornecendo al m de reutiliza o de c digo reutiliza o de an lise e de projeto Aplica es podem ser desenvolvidas ao utilizar o framework como ponto de partida sendo poss vel e necess rio escrever pequenos trechos de c digo para modificar ou estender o comportamento do framework AJ O que um Framework Atualmente o conceito de framework est intimamente ligado orienta o a objetos Frameworks s o implementados atrav s de linguagens orientadas a objetos principalmente porque elas suportam os conceitos de heran a polimorfismo e binding din mico Os detalhes associados a cada um destes conceitos n o ser o descritos aqui mas s o estas as caracter sticas que viabilizam o desenvolvimento de frameworks Frameworks OO s o definidos de duas maneiras similares em Johnson amp Foote 1991 e Johnson amp Russo 1991 Um framework um conjunto de classes que captura um projeto abstrato para solu es de uma fam lia de problemas relacionados e Um framework um conjunto de objetos que colaboram entre si para assumir um conjunto de responsabilid
94. er ncia de redes ISO IEC 7498 1984 quais sejam configura o desempenho falhas seguran a e contabilidade Tudo isto define um ramo mercadol gico particular voltado para a ger ncia de redes e uma ampla rea de pesquisa Muitas aplica es e algumas plataformas de ger ncia est o dispon veis e podem ser utilizadas para diversas finalidades que v o desde a configura o de equipamentos da rede at uma an lise de desempenho ou a contabiliza o de gastos de recursos Por outro lado para desenvolver aplica es de ger ncia espec ficas que atendam a requisitos particulares de um determinado contexto outras APIs Application Programming Interfaces e linguagens podem ser utilizadas o caso por exemplo do JMX Java Management Extensions Sun Microsystems 1999 o qual define uma API para o desenvolvimento de aplica es de ger ncia em Java e da OVSNMP Hewlett Packard 1998a uma API de ger ncia fornecida pela plataforma de ger ncia OpenView da Hewlett Packard O fato que o desenvolvimento de aplica es especializadas n o tem sido uma tarefa f cil Com o n vel de abstra o fornecido pelas APIs e linguagens dispon veis o programador gerentes e operadores da rede precisa estar envolvido com aspectos de programa o que n o est o necessariamente associados ao dom nio do problema modelado Tipicamente ele precisa ter um bom entendimento sobre estruturas de dados complexas ou sobre detalhes de comunica
95. erconectados Qualquer grafo pode ser estabelecido desde que sejam observados os tipos de componentes envolvidos O programador estabelece as rela es visualmente de modo a configurar o fluxo de controle a ser executado pela sua aplica o Finalmente ao instanciar configurar e interconectar os componentes conforme especificado tem se uma aplica o de ger ncia de falhas constru da com base no framework proposto A tabela abaixo ainda resume como os requisitos inicialmente levantados foram atendidos pela solu o proposta Os requisitos F8 e F9 ser o comentados no cap tulo 6 Requisito Caracter stica da solu o Componentes Monitor e ReceptorDeTrapsSnmp respectivamente Componentes GeradorDeEventoFalhaLimiar GeradorDeEventoFalhaTrap e GeradorDeEventoFalhaComHisterese EN possibilidade de interconectar um GeradorDeEventoFalhaLimiar a diferentes monitores para que ele tenha a informa o necess ria para avaliar a ocorr ncia da falha Componente CorrelatorDeEventoFalha e varia es F5 F6 Modelo de interconex o de componentes baseado em fontes e consumidores de eventos Configura o visual dos componentes O framework se baseia apenas na obten o de informa o de ger ncia Componentes ElementoGerenciadoSnmp InfoGerenciaSnmp e ReceptorDeTrapsSnmp Interfaces ElementoGerenciado e InfoGerencia NF3 3 1 3 2 Framework cuida dos detalhes associados a um protocolo de ger ncia es
96. erfaces s o agrupadas para que cada componente possa desempenhar sua fun o espec fica Eventos que produz o LN ConfiguradorDe CosfiguradoDeRequisicao Interfaces Eventos que consome Componente Elemento ElementoGerenciado Adapter ElementoGerenciado GerenciadoSnmp ElementoGerenciadoSnmp InfoGerenciaSnmp InfoGerenciaAdapter InfoGerenciaSnmp RequisicaoSnmp ConfiguradorDeRequisicao Snmp Monitor Monitor MonitorEvent ReceptorDeTraps a a Snmp ReceptorDeTrapsSnmp GeradorDeEvento GeradorDeEventoFalha GeradorDeEventoFalhaLimiar GeradorDeEventoFalha GeradorDeEventoFalha FalhaLimiar GeradorDeEvento FalhaComHisterese ComHisterese GeradorDeEvento GeradorDeEventoFalha FalhaTrap GeradorDeEventoFalhaTrap CorrelatorDe CorrelatorDeEventoFalha EventoFalha CorrelatorDeEventoFalha Contador Contador CorrelatorDe CorrelatorDeEventoFalha EventoFalha CorrelatorDeEventoFalha Supressor Supressor CorrelatorDe CorrelatorDeEventoFalha EventoFalhaCMP CorrelatorDe MonitorListener MonitorEvent EventoFalha Event MonitorEvent EventoFalha Event TrapListener TrapEvent EventoFalha Event MonitorListener EventoFalhaListener EventoFalha EventoFalha Event Event EventoFalhaListener EventoFalha EventoFalha Event Event EventoFalhaListener EventoFalha EventoFalha Event Event 97 Tabela 5 1 As classes e interfaces de cada componente Cada componente po
97. ertura de uma sess o e prepara o de uma mensagem SNMP Figura 3 6 Envio de uma requisi o no modo ass ncrono Figura 3 7 A estrutura de dados OVsnmpPdu Figura 3 8 Defini o de um objeto de alto n vel Figura 3 9 Defini o de uma condi o de falha Figura 3 10 Defini o de um evento s ncrono Figura 3 11 Defini o de um evento ass ncrono Figura 3 12 Defini o de estados de execu o Figura 3 13 Diagrama de estados Figura 4 1 Construindo uma aplica o com base num framework CO Figura 4 2 Componentes classes e interfaces do framework CO Figura 4 3 Fonte B e consumidores de eventos A e C Figura 4 4 Modelo geral de execu o Figura 4 5 Fluxo de eventos Monitor GeradorDeEventos GeradorDeAlarmes Figura 4 6 Exemplos de fluxos de eventos Figura 4 7 ElementoGerenciadoSnmp Figura 4 8 GrupoInfoGerenciae InfoGerenciaSnmp Figura 4 9 Monitor Figura 4 10 Rela es Monitor ElementoGerenciadoe ElementoGerenciado Monitor Figura 4 11 ReceptorDeTrapsSnmp Figura 4 12 GeradorDeEventoFalhaLimiare GeradorDeEventoFalhaTrap Figura 4 13 GeradorAltaTaxaDeErros Figura 4 14 GeradorLinkDown Figura 4 15 TrapEvent 10 12 17 20 21 23 24 25 26 28 28 29 30 31 31 32 48 48 50 51 51 52 54 55 56 57 57 59 60 61 63 vil Figura 4 16 Figura 4 17 Figura 4 18 Figura 4 19 Figura 4 20 Figura 4
98. es individuais s o interconectados e sem precisar saber como eles realizam suas tarefas espec ficas Isto eleva ainda mais o n vel de abstra o fornecido em Johnson amp Roberts 1998 um framework que fornece este n vel de abstra o chamado um black box framework tornando a utiliza o do framework ainda mais simples Tamb m deve se investigar melhor a independ ncia do framework proposto com rela o aos diferentes padr es de ger ncia utilizados principalmente no que diz respeito ao modelo de dados empregado por cada padr o O padr o de ger ncia OSI por exemplo utiliza um modelo de dados orientado a objetos enquanto o padr o de ger ncia Internet utiliza um modelo de dados baseado em vari veis escalares Deve se averiguar como acomodar melhor as caracter sticas pr prias de cada padr o haja vista que este trabalho est fundamentalmente voltado para o padr o de ger ncia Internet Por fim a solu o proposta deve ser implementada e tamb m deve ser estendida para permitir realizar uma ger ncia de redes distribu da Isto tornar a solu o mais escal vel adequando a s grandes redes de computadores atualmente utilizadas 112 Bibliografia Beck amp Gamma 1998 Beck K Gamma E Test Infected Programmers Love Writing Tests 1998 On line http www dsc ufpb br jacques cursos 1999 1 apoo material testing junit htm Case et al 1990 Case J D Fedor M S Schoffstall M L Davin
99. especialmente til para o caso em que citamos este algoritmo conhecido como correla o de controle de manuten o programada ou simplesmente CMP Do exposto acima observe que componentes que fazem correla o de eventos s o tamb m geradores de eventos Eles recebem os eventos gerados por geradores do tipo GeradorDeEventoFalhaLimiar GeradorDeEventoFalhaTrap e GeradorDe EventoFalhaComHisterese mas tamb m geram seus pr prios eventos como resultado da correla o realizada identificando novos tipos de falhas as figuras 4 23 4 24 e 4 25 exemplificam este fato Desta maneira qualquer outro componente respons vel por tratar as falhas identificadas na rede um componente respons vel por gerar alarmes por exemplo que possa ser associado a um GeradorDeEventoFalhaLimiar GeradorDeEvento FalhaTrap ou GeradorDeEventoFalhaComHisterese pode ser tamb m associado a qualquer um dos componentes que fazem correla o de eventos Na verdade um 71 componente deste tipo tamb m um gerador de eventos que gera eventos do tipo EventoFalhaEvent e possui al m das propriedades associadas ao algoritmo de correla o implementado as propriedades que caracterizam o evento a ser gerado conforme descrito pela figura 4 26 Figura 4 26 CorrelatorDeEventoFalha Para utilizar outros tipos de correla o o programador pode construir novos componentes a partir do CorrelatorDeEventoFalha introduz
100. et O desenvolvimento de aplica es de ger ncia entretanto n o tem sido uma tarefa f cil Plataformas de ger ncia fornecem APIs Application Programming Interfaces para o desenvolvimento de aplica es de ger ncia Tipicamente uma linguagem como C ou C utilizada para construir uma aplica o sob medida para um determinado contexto Esta solu o entretanto exige consider vel experi ncia de programa o j que fazer ger ncia de redes atrav s da linguagem C por exemplo requer um bom entendimento de estruturas de dados complexas at mesmo para a realiza o de tarefas simples Opcionalmente outras APIs e linguagens mais especificamente voltadas para a ger ncia de redes exemplos podem ser encontrados em Lima 1998 Sch nwalder amp Langend rfer 1995 Leinen 1999 Mellquist 1997 Sun Microsystems 1999 Hewlett Packard 1998a e Sim es et al 1994 podem ser utilizadas Mesmo assim como veremos adiante programadores ainda precisam estar envolvidos com detalhes de programa o que n o est o necessariamente associados ao dom nio do problema modelado o que sugere que tais APIs e linguagens n o fornecem um n vel de abstra o adequado ao desenvolvimento de aplica es de ger ncia espec ficas De um modo geral elas fornecem uma interface para realiza o de opera es SNMP mas deixam de fornecer abstra es de mais alto n vel que 19 atendam a necessidades de ger ncia espec
101. eve ser definida Isto inclui a especifica o e a implementa o de uma ferramenta visual para manipula o de componentes conforme discutido na se o 5 2 bem como a especifica o e a implementa o de uma interface gr fica atrav s da qual a atividade resultante da execu o do framework possa ser acompanhada um mapa onde se pode visualizar o estado da rede por exemplo Neste ltimo caso deve se investigar a possibilidade de integra o entre o framework proposto neste trabalho e outros frameworks especialmente desenvolvidos para a implementa o de interfaces gr ficas Um exemplo deste ltimo tipo de framework pode ser encontrado em ILOG 1999 Apenas as classes que implementam os servi os oferecidos pelos componentes foram especificadas Falta definir as classes relacionadas configura o de cada componente e que portanto determinam como cada componente deve ser manipulado por uma ferramenta visual Isto consiste em especificar os editores de propriedades especiais que cada componente requer e as classes que cont m informa o adicional sobre as caracter sticas de cada componente como as propriedades e m todos que ele suporta refer ncias a editores de propriedades especiais arquivos da dados que ele utiliza etc No caso particular da linguagem Java trata se de utilizar a API JavaBeans Sun Microsystems 1999 para definir como cada componente deve ser configurado Devem ser investigadas formas alternativas
102. faces e componente apresentados na figura 4 29 mant m se o framework independente de protocolo de ger ncia em atendimento ao requisito NF1 A interopera o entre os diferentes modelos de ger ncia garantida sendo poss vel construir uma aplica o capaz de gerenciar simultaneamente diferentes entidades da rede independentemente do modelo de ger ncia que elas suportam 4 3 6 Modificando os Eventos Produzidos pelos Componentes do Framework O framework ainda permite modificar os eventos trocados entre alguns componentes instanciados Por exemplo poss vel modificar os eventos EventoFalhaEvent que podem ser gerados pelos geradores de eventos GeradorDeEventoFalhaLimiar GeradorDeEventoFalhaTrap e GeradorDeEventoFalhaComHisterese e pelo CorrelatorDeEventoFalha Para isto pode se acrescentar novas propriedades e m todos classe EventoFalhaEvent incluindo a informa o adicional necess ria e assim definindo uma nova classe para descri o dos eventos gerados por estes componentes Deve se conseqiientemente modificar o m todo criaEventoFalha do gerador de eventos correspondente para fazer com que o gerador passe a gerar o novo tipo de evento A figura 4 30 mostra um exemplo em que isto pode ser til Suponha que seja necess rio gerar eventos que possuam outros n veis de prioridade al m daqueles n veis suportados por default prioridadeAlta prioridadeMedia e prioridade Baixa poss vel definir
103. fica o de modelos UML Unified Modeling Language A nota o que segue portanto est associada aos recursos que a ferramenta oferece e difere ligeiramente da nota o encontrada em algumas refer ncias bibliogr ficas como em Rumbaugh et al 1999a e Fowler amp Scott 1999 Apenas os s mbolos utilizados s o destacados Classe Associa o Nome da Classe Classe A papel de A papel de B Classe B Watributos EBm todos Cardinalidades 1 Classe exatamente 1 Classe abstrata Nome da Classe Classe EBatributos muitos 0 ou mais Sm todos 0 1 Classe opcional 0 ou 1 Atributos e m todos Nome da Classe Classe EB constante muitos 1 ou EBatributo p blico mais atributo protegido EBatributo privado Agrega o EBm todo p blico SR m todo protegido classe composta classe constituinte Em todo privado 128 Generaliza o Superclasse Subclasse A Subclasse B Interfaces Nome da Classe f lt lt lnterface gt gt implementa EBatributos e ER gt Nome da Interface EBm todos EBm todos Diagrama de Seqii ncia Objet
104. foGerencia fornecida pelas entidades monitoradas da rede Elemento GerenciadoSnmp ou os traps TrapEvent enviados pelo ReceptorDeTrapsSnmp Vejamos como poss vel ter acesso a esta informa o M todos Alguns m todos podem ser utilizados para manipular a informa o de ger ncia dispon vel No caso de um GeradorDeEventoFalhaLimiar os m todos s o os seguintes 1 GeradorDeEventoFalhaLimiar getInfoGerenciaDaOrigem String nomelg String nomeEg retoma uma unidade de informa o de ger ncia InfoGerencia contida no GrupolInfo Gerencia fornecido por uma determinada entidade gerenciada ElementoGerenciado A unidade a ser retornada tem seu nome igual a nomeIg e a entidade gerenciada que fornece esta informa o tem seu nome igual a nomeEg E poss vel ter acesso a qualquer unidade de informa o de um GrupoInfoGerencia fornecido por qualquer entidade gerenciada que faz parte de egs 2 InfoGerencia getInteiro InfoGerencia getDouble e InfoGerencia getString retorna um valor inteiro um valor double e um valor st ring respectivamente conforme o valor da unidade de informa o de ger ncia 3 GeradorDeEventoFalhaLimiar getLimiares String nome retorna o limiar que tem o nome especificado nome Um limiar um outro componente do tipo Limiar que possui um nome e um valor 63 4 Limiar getValor retorna o valor do l
105. foco do nosso trabalho 2 1 Areas Funcionais da Ger ncia de Redes A ger ncia de redes envolve a realiza o de um grande n mero de atividades agrupadas em cinco reas funcionais distintas segundo o modelo OSI Open System Interconnection definido pela ISO International Standards Organization ISO IEC 7498 1984 a saber Ger ncia de configura o respons vel pela manuten o e monitora o da estrutura f sica e l gica da rede Trata da inicializa o altera o e coleta de informa o de configura o presente na rede atrav s da troca de informa o com os elementos gerenciados e da atua o sobre esses elementos Tamb m inclui a adi o e remo o de elementos gerenciados Ger ncia de desempenho prov a avalia o permanente da utiliza o dos recursos da rede com base nos dados coletados e estat sticas de desempenho Inclui planejamento de capacidade onde se faz uma avalia o pr via da necessidade de recursos para evitar problemas futuros causados pela sobrecarga dos recursos dispon veis Ger ncia de falhas inclui identifica o diagn stico e corre o de falhas Ger ncia de seguran a tem como objetivo controlar o acesso aos recursos da rede atrav s do uso de t cnicas de autentica o e pol ticas de autoriza o Ger ncia de contabilidade visa identificar o consumo de recursos da rede provendo inclusive a habilidade para cobrar pela utiliza o de tais recursos Esta divi
106. ifica o callback Ss get sysUpTime 0 if SE noError set d lindex lindex SV 0 2 puts SS cget address Mt Sd 6S destroy snmp wait Figura 3 2 Script para a obten o de valores em agentes SNMP No exemplo acima deseja se obter o valor de sysUpTime das dez primeiras m quinas da rede Uma opera o get enviada no modo ass ncrono em cada sess o estabelecida a fim de recuperar o valor de sysUpTime de cada uma das m quinas Ao tratar cada resposta recebida verifica se primeiramente se ocorreu algum erro usando a sequ ncia E caso n o haja erro o endere o do agente e o valor de sysUpTime s o escritos na sa da padr o antes que a sess o recuperada atrav s da sequ ncia S seja finalizada 21 Uma API de ger ncia bastante similar LuaMan Lima 1998 foi desenvolvida na PUC Rio Pontif cia Universidade Cat lica Rio de Janeiro RJ para a linguagem de extens o Lua Ierusalimschy et al 1996 LuaMan uma biblioteca especificamente voltada para a ger ncia de redes que fornece basicamente os mesmos recursos fornecidos pela API SNMP do Tcl A linguagem interpretada Perl tamb m fornece uma API de ger ncia muito semelhante Leinen 1999 com as mesmas opera es e caracter sticas b sicas Exemplos de aplica es e sistemas desenvolvidos em Tcl LuaMan e Perl podem ser encontrados respectivamente em Sch nw lder amp Langendorfer 1996 Lima et al 1998 e Le
107. ificado A ger ncia de falhas consiste em detectar alguma anormalidade no comportamento padr o do sistema a fim de que a es corretivas possam ser apropriadamente aplicadas Oates 1995 Para tanto as tarefas b sicas descritas na figura abaixo devem ser realizadas Detec o de Falhas Coleta de dados Correla o de eventos Corre o de Falhas p Trouble Ticketing Figura 2 3 Tarefas b sicas da ger ncia de falhas Gera o de Alarmes Diagn stico de Falhas A primeira de todas as tarefas consiste em identificar um desvio no comportamento do sistema detectando que uma falha ocorreu Para isto necess rio fazer a coleta de dados nos elementos gerenciados a fim de monitorar indicadores da presen a de falhas na rede taxas de erro atrasos de transmiss o etc A detec o de falhas tamb m envolve a correla o de eventos ocorridos na rede a qual ser descrita mais adiante e a gera o de alarmes Defini o 2 Um evento um momento interessante de atividade na rede o cruzamento de um limiar por exemplo indicando que a taxa de erros ultrapassou determinado valor Neste contexto um evento descreve uma falha 2 Defini o 3 Um alarme um evento que ser levado ao conhecimento do operador da rede atrav s de algum mecanismo de notifica o 12 A tarefa de diagn stico consiste em identificar a causa e a localiza o de uma falha Um diagn stico preciso indispens v
108. imiar No caso de um GeradorDeEventoFalhaTrap os m todos utilizados seguem abaixo l TrapEvent getTipoDoTrap retorna o tipo do trap recebido Pode ser um entre os seis seguintes valores etrapLinkUp indica que o estado de opera o da interface de rede mudou de down para up isto indica que a interface est em seu estado de opera o normal etrapLinkDown indica que o estado de opera o da interface de rede mudou de up para down isto indica que a interface est inoperante etrapColdStart indica que o agente est se re inicializando e pode ser que a informa o de ger ncia dispon vel seja alterada etrapWarmStart indica que o agente est se reinicializando mas a informa o de ger ncia dispon vel n o ser alterada etrapFalhaDeAutenticacao indica que houve falha de autentica o de uma requisi o de ger ncia ou seja uma requisi o recebida n o continha a informa o de autentica o correta para que fosse devidamente atendida etrapEspecifico indica outro evento de interesse pode conter por exemplo informa o associada a uma tecnologia particular TrapEvent getOrigemDoTrap retorna a entidade gerenciada ElementoGerenciado que gerou o trap TrapEvent getTimeStamp retorna o instante de tempo em que o trap foi gerado TrapEvent getGig retorna a informa o de ger ncia Grupo InfoGerencia contida no t
109. indo seus pr prios algoritmos de correla o atrav s do m todo correlaciona Ent o assim como novos geradores de eventos podem ser constru dos ao definir o m todo verificaOcorrencia EventoFalha novos componentes para correla o de eventos podem ser constru dos ao definir o m todo correlaciona Este m todo recebe como par metro de entrada os eventos enviados pelo s gerador es de eventos com o s qual is o CorrelatorDeEventoFalha est associado e retorna verdadeiro true se o princ pio de correla o utilizado for satisfeito A figura abaixo exemplifica a cria o de um novo componente para correla o de eventos Cria o de um novo correlator de eventos public CorrelatorTemporal extends CorrelatorDeEventoFalha implements Serializable public void correlaciona EventoFalhaEvent ef Inclui algoritmo de correla o aqui Figura 4 27 CorrelatorTemporal Para tratar as falhas identificadas o programador ainda pode construir novos componentes ao implementar uma interface fornecida pelo framework chamada EventoFalhaListener Esta interface possui um nico m todo processaEvento Falha atrav s do qual o programador pode determinar o tratamento adequado para as falhas identificadas conforme suas necessidades A figura 4 28 exemplifica a utiliza o da interface EventoFalhaListener Cria o de um gerador de alarmes public GeradorDeAlarmes implements EventoFalhaLis
110. inen 1999 3 2 A API de Ger ncia Java A Sun Microsystems possui uma API de ger ncia denominada Snmp Manager API Sun Microsystems 1999 baseada na linguagem Java Ela consiste de um conjunto de classes que simplificam o desenvolvimento de aplica es para gerenciar agentes SNMP H quatro classes b sicas SnmpPeer SnmpParameters SnmpSession e SnmpRequest As classes SnmpPeer e SnmpParameters descrevem o agente com o qual a aplica o gerente deseja se comunicar A figura 3 3 mostra a instancia o e configura o de um agente SNMP A classe SnmpSession representa o contexto para as conex es abertas entre o gerente e um ou mais agentes Ela implementa os m todos atrav s dos quais os diferentes tipos de requisi es SNMP podem ser realizados S o eles snmpGet snmpGetNext snmpSet e snmpGetBulk Adicionalmente est o dispon veis as opera es snmpGetPoll snmpGetNextPoll e snmpWalkUntil Com snmpGetPoll e snmpGetNextPoll uma monitora o peri dica pode ser realizada no agente de acordo com um par metro da opera o que especifica um intervalo de tempo A opera o automaticamente realizada segundo esta periodicidade retornando uma lista de vari veis conforme requisitado Com snmpWalkUntil a MIB percorrida at que determinada condi o seja satisfeita e o conjunto de vari veis lido retornado Cada opera o SNMP realizada durante a sess o representada por um objeto do tipo SnmpRequest
111. informa o de ger ncia fornecida pela entidades da rede atende se tamb m ao requisito NF3 3 Cria o do componente GeradorAltaTaxaDeTrafego2 public GeradorAltaTaxaDeTr fego2 extends GeradorDeEventoFalhaLimiar implements Serializable public boolean verificaOcorrenciaEventoFalha ElementoGerenciado egs Retorna true se a quantidade de conex es TCP abertas em egs 0 for maior que o limiar ConexoesAbertas a quantidade de pacotes que chegam tamb m a egs 0 for maior que o limiar TaxaDeTrafego return get InfoGerenciaDaOrigem QuantConexoesAbertas egs 0 getInteiro gt Int parseInt getLimiares ConexoesAbertas getValor amp amp getInfoGerenciaDaOrigem PacotesIn egs 0 getDouble gt Double parseDouble getLimiares TaxaDeTrafego getValor Figura 4 18 GeradorAltaTaxaDeTrafego2 66 Embora o programador possa se sentir vontade para escrever qualquer condi o de ocorr ncia de falha a ser verificada muitas vezes esta condi o se baseia num mecanismo de histerese De acordo com este mecanismo dois valores s o utilizados um limiar cujo cruzamento indicar a ocorr ncia de uma falha e um valor de reposicionamento rearm cujo cruzamento indicar a situa o contr ria isto uma situa o livre de falhas A gera o de eventos ou identifica o de falhas baseia se na an lise de determinada informa o de ger ncia em torno deste dois valo
112. is o gerente requisita e o agente responde com a informa o solicitada Um erro tamb m pode ser 10 retornado no caso em que a opera o n o seja bem sucedida A opera o trap por sua vez permite que o pr prio agente envie informa o ao gerente em resposta a um evento ocorrido como o cruzamento de um limiar previamente estabelecido sem que tenha havido requisi o pr via O SNMP um protocolo muito utilizado e atualmente h tr s vers es dispon veis Sua primeira vers o SNMPv1 Case et al 1990 foi descrita nesta se o e ainda bastante utilizada A vers o seguinte SNMPv2 Case et al 1993 trouxe alguns melhoramentos para o protocolo dentre as quais podemos citar a defini o de duas novas opera es get bulk e inform A opera o get bulk permite recuperar grandes quantidades de informa o de uma s vez de forma que o que anteriormente seria feito com v rias requisi es get next por exemplo possa ser feito com uma nica requisi o get bulk a opera o inform facilita a comunica o entre esta es de ger ncia distintas O SNMPv3 Case et al 1998 por sua vez preocupou se especialmente com seguran a e de fato muito se tem feito no sentido de incluir e melhorar aspectos de seguran a no SNMP para garantir a autenticidade e a integridade das opera es de ger ncia realizadas atrav s deste protocolo A princ pio seguran a era muito fracamente fornecida Enfim o padr
113. isparado uma indica o deve aparecer sobre o equipamento que o representa na interface gr fica 1 1 Constru o de novos componentes 1 1 1 Um GeradorDeAlarmesHisterese para gerar alarmes diante da ocorr ncia do evento que indica alta taxa de erros na interface do roteador R GeradorDeAlarmesHisterese implements EventoFalhaListener Serializable Implementando a interface EventoFalhaListener public void processaEventoFalha EventoFalhaEvent ef GeradorDeEventoFalha fonte ef getFonte Muda interface indicando a ocorr ncia da falha if fonte getValorAtingido fonte valorLimiar 83 UI instancia mudalor fonte getOrigem fonte get prioridade 1 2 Instancia o e configura o de componentes 1 2 1 Um ElementoGerenciadoSnmp para representar o roteador a ser gerenciado R R nome rt dsc ufpb br endIp 150 165 75 171 nomeResponsavel Administrador contatoResponsavel admin dsc ufpb br prioridade prioridadeAlta 13 1 2 2 Um GrupoInfoGerencia grupoIG para agregar a informa o a ser fornecida por R grupoIG addInfoGerencia InfoGerenciaSnmp TaxaDeErros ifInErrors 1 2 3 Um Monitor monitor para controlar a freqii ncia de monitora o de R monitor periodo 1800s 1 2 4 Um GeradorDeEventoFalhaComHisterese gHisterese para verificar a taxa de erros de R a partir da informa o obti
114. lder 1997 Sch nwalder J Scotty Tcl Extensions for Network Management Applications 1997 On line http wwwsnmp cs utwente nl schoenw scotty Siegel 1996 Siegel J Corba Fundamentals and Programming John Wiley amp Sons 1996 Sim es et al 1994 Sim es P A F Brites A C S C Leit o P M C Monteiro E H S Fernandes F P L B A High Level Notation for the Specification of Network Management Applications University of Coimbra Portugal May 1994 Sloman 1994 Sloman M Network and Distributed Systems Management Addison Wesley 1994 117 Sun Microsystems 1999 Sun Microsystems Inc Java Management Extensions SNMP Manager API August 1999 Draft 2 0 Tanenbaum 1998 Tanenbaum A S Modern Operating Systems Prentice Hall 1998 118 Ap ndice A Frameworks O foco a reutiliza o de an lise e projeto e n o a reutiliza o de c digo Gamma et al 1994 2 A reusabilidade de software reconhecida como uma importante maneira de aumentar a produtividade no processo de desenvolvimento de software A id ia n o desenvolver nada do que j existe mas apenas reutilizar Isto diminui o tempo de desenvolvimento e permite a constru o de produtos de software mais robustos o que primordialmente necess rio j que softwares cada vez mais complexos precisam ser desenvolvidos num espa o de tempo cada vez menor Produzir software reutiliz vel implica
115. lise da informa o de ger ncia que ele pr prio forneceu e ent o pode modificar seu comportamento de forma conveniente Situa o A 1 2 3 envio da falha Situa o B 1 envio de informa o de ger ncia 2 envio da falha identificada com base na an lise da identificada informa o obtida de M Figura 4 6 Exemplos de fluxos de eventos Na verdade qualquer grafo pode ser constru do para representar as intera es estabelecidas entre os componentes envolvidos desde que sejam obedecidas algumas regras de interconex o de componentes como ser descrito na se o a seguir Ao interconectar os componentes de forma adequada poss vel definir um comportamento espec fico reutilizando a arquitetura imposta pelo framework Enfim ao combinar framework componentes e um modelo de execu o baseado em fontes e consumidores de eventos atende se arquiteturalmente falando aos requisitos destacados Na se o seguinte detalhamos os componentes b sicos do framework destacando o atendimento a outros requisitos n o mencionados nesta se o 4 3 Os Componentes B sicos do Framework Como vimos a solu o consiste de um framework CO que fornece componentes atrav s dos quais aplica es de ger ncia de falhas podem ser desenvolvidas Para desenvolver cada aplica o o programador pode 1 construir novos componentes 2 configurar visualmente os componentes dispon veis e 3 interconectar os componentes n
116. m comportamento espec fico a periodicidade de monitora o por exemplo deve ser um par metro ajust vel de modo que se possa determinar com que freqii ncia a aplica o deve buscar a informa o de ger ncia nos agentes A solu o deve permitir atuar convenientemente sobre tais par metros para que se possa inclusive modificar o comportamento da aplica o em tempo de execu o Conforme exemplificado na se o 3 5 poss vel que seja necess rio modificar o processo de monitora o haja vista a ocorr ncia de um determinado evento ao detectar que determinado evento ocorreu deveria ser poss vel mudar a fregii ncia de monitora o A solu o deve permitir que isto seja feito F8 Deve ser poss vel fazer trouble ticketing F9 Aplica es de trouble ticketing s o muito utilizadas no contexto da ger ncia de falhas Uma vez que um problema n o possa ser imediatamente resolvido a corre o de um problema pode envolver fabricantes ou pessoas mais capacitadas o que em geral leva tempo o operador da rede deve poder abrir um ticket mantendo um hist rico de resolu o do problema origem data de ocorr ncia data de resolu o a es realizadas respons vel etc ou a pr pria solu o de ger ncia deve poder abri lo automaticamente dispensando a interven o manual do operador A solu o portanto deve fornecer meios atrav s dos quais seja poss vel definir e gerenciar tickets bem como de
117. mal estado EsperandoCorre o evento ServidorOk a aplica o vai para o estado Opera oNormal Estas atividades correspondem figura abaixo ServidorForaDoAr DS Esperando Corre o Opera o Normal ServidorFora ServidorOk DoAr 31 Figura 3 13 Diagrama de estados 2 H ainda vari veis especiais que podem ser utilizadas como o caso de hit_location que indica o endere o do agente onde a ltima falha foi detectada current state que indica o nome do estado corrente e ESNMP error que indica o c digo do ltimo erro SNMP detectado Estas vari veis podem ser muito teis e o programador pode utiliz las para definir objetos de alto n vel e a es conforme foi exemplificado nas figuras 3 8 e 3 10 3 5 Uma An lise das Solu es Apresentadas Do exposto nas se es anteriores verificamos que todas as APIs fornecem os recursos b sicos para realiza o de coleta de informa o na rede tarefa indispens vel para que a ger ncia de redes possa ser feita O estabelecimento expl cito de sess es SNMP e a chamada de primitivas de comunica o de baixo n vel s o aspectos que est o diretamente associados a esta tarefa Entretanto embora as APIs dispon veis forne am um n vel de abstra o mais alto para a realiza o de opera es SNMP elas n o fornecem as abstra es necess rias para que o programador possa se concentrar na solu o desejada ger ncia de falhas ger ncia
118. menta a interface TrapListener para que componentes deste tipo possam ser conectados a um ReceptorDeTraps e consequentemente possam identificar falhas com base nos traps recebidos A implementa o das interfaces MonitorListener e TrapListener contudo n o tarefa do programador que constr i novos componentes do tipo GeradorDeEvento FalhaLimiar ou GeradorDeEventoFalhaTrap Conforme dito estas interfaces s o implementadas internamente pelas classes GeradorDeEventoFalhaLimiar e GeradorDeEventoFalhaTrap de modo que os novos componentes criados a partir da extens o destas classes se tornam por heran a consumidores de eventos do tipo MonitorEvent e TrapEvent respectivamente Ent o conforme vimos no cap tulo 4 para construir novos componentes para identifica o de falhas basta estender as classes GeradorDeEventoFalhaLimiar e GeradorDeEventoFalhaTrap redefinindo o 100 m todo verifica0OcorrenciaEventoFalha Feito isto o novo componente criado j pode ser instanciado configurado e conectado a componentes do tipo Monitor ou ReceptorDeTraps para receberem a informa o de cuja an lise ser o identificadas as falhas na rede Esta implementa o interna das interfaces MonitorListener e TrapListener a P4 ec Z A 1 n o s parece confort vel para o programador mas tamb m permite que o framework implemente parte de sua pr pria funcionalidade atrav s dos m todos
119. mework De um modo geral aplica es de ger ncia de falhas realizam monitora o nos agentes a fim de obter a informa o de ger ncia de interesse analisam esta informa o a fim de identificar falhas na rede e uma vez verificada a ocorr ncia de uma falha as a es cab veis devem ser realizadas de modo a resolver o problema Com base nisto foram identificados os componentes b sicos do framework respons veis pela realiza o de cada uma destas etapas detalharemos estes componentes na pr xima se o e a fim de embutir este comportamento no framework um modelo de execu o configur vel baseado em fontes e consumidores de eventos foi adotado Tal modelo tamb m conhecido como o padr o de projeto Observer Gamma et al 1994 define como interconectar os componentes utilizados durante a constru o da aplica o De acordo com este modelo de execu o todo componente um gerador potencial de eventos Um evento neste contexto qualquer resultado decorrente da a o de um componente n o representando apenas falhas Se o componente A est interessado no evento gerado por outro componente B A deve se cadastrar em B declarando seu interesse em receber tal evento B por sua vez compromete se a enviar os eventos gerados para A e todos os demais componentes cadastrados O acoplamento entre fontes e consumidores m nimo de modo que eles podem ser reutilizados separadamente Um consumidor pode se cadastrar ou cancel
120. n N Niklasson A Development of Object Oriented Frameworks Department of Communication Systems Lund Institute of Technology Sweden 1998 Larman 1998 Larman C Applying UML and Patterns An Introduction to Object Oriented Analysis and Design Prentice Hall 1998 Leinen 1999 Leinen S SNMP Support for Perl 5 1999 On line http www switch ch misc leinen snmp perl index html Lima et al 1998 Lima M E Moura A L Ishikawa E Rodriguez N Aplica es de Ger ncia Extens veis XVI Simp sio Brasileiro de Redes de Computadores SBRC pp 125 143 Rio de Janeiro Brasil Maio 1998 Lima 1998 Lima M E LuaMan Uma Plataforma para Desenvolvimento de Aplica es de Gerenciamento Extens veis Disserta o de Mestrado Depto de Inform tica PUC Rio de Janeiro Janeiro 1998 Madruga amp Tarouco 1994 Madruga E L Tarouco L M R Fault Management Tools for a Cooperative and Descentralized Network Operations Environment IEEE Journal on Selected Areas in Communications Vol 12 No 6 pp 1121 1130 August 1994 115 Meira amp Nogueira 1997 Meira D M Nogueira J M S M todos e Algoritmos para Correla o de Alarmes em Redes de Telecomunica es Simp sio Brasileiro de Redes de Computadores 1997 pp 79 98 S o Carlos SP Brasil Maio 1997 Meira 1997 Meira D M Um Sistema para Correla o de Alarmes em Redes de Telecomunica es Tese de Doutorado Depto
121. nalidade b sica todas elas apresentam o comportamento descrito pela figura 2 4 Gibson et al 1996 De acordo com a figura de um lado est o os agentes ou elementos gerenciados do outro est a aplica o gerente Para realizar a sua tarefa de ger ncia a aplica o depende da informa o colhida nos agentes e a obten o desta informa o feita de duas formas sincronamente a aplica o periodicamente requisita informa o ao agente e este responde com a informa o solicitada e assincronamente os pr prios agentes enviam informa o para aplica o em resposta ocorr ncia de um evento sem requisi o pr via A informa o recebida passa por filtros geralmente baseados em limiares definidos de acordo com pol ticas de ger ncia adequadas Indicadores de falhas como taxas de erros s o analisados a fim de que a ocorr ncia de eventos na rede possa ser identificada Eventos podem ser correlacionados informa es sobre a topologia da rede podem ser teis e finalmente identificadas as falhas alarmes devem ser gerados Os alarmes podem ainda ser priorizados e notificados de v rias formas via correio eletr nico via interface gr fica etc A prioridade de um alarme indica a gravidade da falha por ele notificada Adicionalmente o registro de ocorr ncias pode ser feito gera o de logs 16 Informa es N o Informa es Solicitadas Solicitadas Atividade na
122. ncia Editores que permitam interconectar fontes e consumidores de eventos tamb m s o necess rios Al m disso o programador deve poder utilizar um banco de dados de topologia que armazene a configura o da rede a ser gerenciada ou seja a configura o dos componentes do tipo ElementoGerenciado que devem ser instanciados Isto facilita a constru o de novas aplica es de ger ncia para a mesma configura o de rede e implica em possibilitar a integra o entre o editor gr fico e o banco de dados de topologia onde a informa o de interesse est armazenada este banco de dados poderia ser atualizado pelo programador ou atrav s de ferramentas de descobrimento autom tico de topologia Assim pelo menos duas ferramentas b sicas de suporte composi o de aplica es devem estar dispon veis um editor gr fico e um banco de dados de topologia da rede Uma vez que a configura o seja conclu da aproveitando todas as facilidades que tais ferramentas oferecem o framework deve ser ativado para que a rede possa ser devidamente gerenciada reutilizando toda a funcionalidade nele embutida 104 SOI ElementoGerenciadoAdapter A ElementoGerenciadoSnmp etEnIP tEndlP utiliza a lt lt Interface gt gt ElementoGerenciado Bok E Nok prioridadeAlta prioridadeMedia BS prioridadeBaixa etNome setNome ES getPrioridade se
123. nkDowna 3 3 7 Associamos o GeradorDeAlarmesHisterese gAlarmes ao GeradorDeEventoFalhaComHisterese gHisterese para que toda vez que houver um congestionamento em Rs um alarme seja disparado 3 3 8 Associamos o GeradorDeAlarmes gAlarmes aos componentes Gerador LinkDown gLinkDown e glLinkDowns e ao CorrelatorDeEventoFalhaSupressao correlator para que o gAlarmes gere um alarme toda vez que ocorrer problemas nas interfaces de R1 R2 Ra 3 3 9 Associamos 0 GeradorDeLogs glog aos geradores de eventos gHisterese ghLinkDown gLinkDowns e ao correlator para que sejam registradas as devidas ocorr ncias estes componentes foram duplicados na figura abaixo apenas para facilitar o entendimento da figura 93 O diagrama de segii ncia da figura 4 34 mostra o fluxo de eventos resultante das associa es descritas A diagrama foi divido em duas partes por quest o de espa o receptor LinkDown1 gLinkDown2 gLinkDown3 correlator gAlarmes2 gLog DeTraps envia trap gt envia trap gt envia trap envia evento falha envia evento falha envia ev ento falha gt envia evento falha gt envia evento falha gt envia evento falha gt envia evento falha gt
124. ntes unidades de informa o de ger ncia referentes a diferentes modelos de ger ncia simultaneamente O componente InfoGerenciaSnmp implementa a interface InfoGerencia e possui um identificador adicional oid que se refere ao identificador espec fico de cada vari vel MIB ifInErrors por exemplo Um ReceptorDeTraps possui dois m todos que devem ser redefinidos para tratar caracter sticas espec ficas do modelo de ger ncia considerado O m todo get TrapDaRede respons vel por tratar cada trap recebido e a partir da gerar traps do tipo TrapEvent o m todo determinaTipoDeTrap mapeia os tipos de traps conforme definidos pelo modelo de ger ncia considerado para um dos tipos de traps reconhecidos pelo framework TrapEvent linkDown TrapEvent linkUp TrapEvent trapEspecifico e outros Ent o um ReceptorDeTrapsSnmp por exemplo redefine estes dois m todos para tratar os traps SNMP recebidos e a partir da informa o neles contida gerar os eventos 75 que outros componentes do framework s o capazes de reconhecer isto traps do tipo TrapEvent Sendo assim ao construir uma aplica o de ger ncia baseada em SNMP instanciamos e configuramos os componentes ElementoGerenciadoSnmp InfoGerenciaSnmp e ReceptorDeTrapsSnmp Para tratar caracter sticas de outros protocolos outros componentes podem ser constru dos e uma vez obedecidas as regras estabelecidas pelas inter
125. o ifInOctets ifInOctets 1 fpollInterval Figura 3 8 Defini o de um objeto de alto nivel Na express o acima um objeto de alto n vel foi definido com base na taxa de octetos recebida por uma determinada interface de um dos agentes da rede Se considerarmos que um mesmo agente pode ter v rias interfaces e que opera es SNMA se baseiam em conjuntos de 28 agentes a express o acima significa a taxa de octetos recebida por cada interface de cada agente presente num conjunto de agentes espec fico A vari vel ifInOctets 1 representa o valor de ifInOctets obtido na pen ltima monitora o feita ifInOctets representa o valor de ifInOctets obtido na monitora o corrente e PollInterval significa o intervalo de tempo entre duas monitora es consecutivas O programador portanto especifica a express o acima mas n o precisa se preocupar com as opera es de ger ncia realizadas para que tal informa o seja obtida Para atender a necessidades de ger ncia espec ficas a SNMA tamb m define uma sintaxe pr pria atrav s da qual busca fornecer o n vel de abstra o desejado Para atender a necessidades da ger ncia de falhas por exemplo a SNMA fornece os construtores descritos na tabela abaixo POLLED EVENT Descreve um evento s ncrono TRAP EVENT Descreve um evento ass ncrono Descreve um conjunto de a es SNMA a serem executadas em resposta ocorr ncia de uma falha por exemplo
126. o F5 Deve ser poss vel automatizar tarefas em resposta aos eventos ocorridos preciso tratar as falhas ocorridas na rede sejam elas resultantes de uma correla o ou n o Neste sentido o maior grau de automa o poss vel deve ser fornecido idealmente dispensando a interven o humana Mecanismos para supervis o e notifica o de alarmes e facilidades para a gera o de registros de ocorr ncias devem ser fornecidos F6 Deve ser poss vel realizar diferentes a es em resposta ocorr ncia de um nico evento Algumas vezes a ocorr ncia de um nico evento pode disparar diversas a es Por exemplo ao detectar que o tr fego que passa por uma das interfaces de um roteador ultrapassou determinado valor pode ser necess rio 1 obter informa o sobre esta interface mais frequentemente modificando o processo de monitora o 2 gerar um alarme notificando o operador da rede sobre a ocorr ncia do evento e 3 registrar a ocorr ncia numa base de dados atualizando o hist rico sobre os eventos ocorridos A solu o deve permitir que todas estas a es sejam realizadas em resposta ocorr ncia do mesmo evento 40 F7 Deve ser fornecido um controle m ximo sobre o comportamento da aplica o atrav s da parametriza o e ou configura o dos elementos que implementam sua funcionalidade Ao construir qualquer aplica o ou sistema par metros devem ser devidamente ajustados a fim de caracterizar u
127. o A Objeto B Objeto C Classe A Classe B Classe C mensagem de A para B mensagem de B para C mensagem de C para A lt 129 Gloss rio API ASN 1 BER CMP CO CORBA COM DMI DMTF ECS ISO ITU T JMX JDK MIB OO OSI OVSNMP SMI SNMA SNMP SNMPv1 SNMPv2 SNMPv3 Tcl TCP TMN Application Programming Interface Abstract Syntax Notation One Basic Enconding Rules Controle de Manuten o Programada Component Oriented Common Object Request Broker Architecture Component Object Model Desktop Management Interface Distributed Management Task Force Event Correlation Services engine Internet Protocol International Standards Organization International Telecommunications Union Java Management Extensions Java Development Kit Management Information Base Orienta o a Objetos Open System Interconnection OpenView SNMP Structure of Management Information Specification of Network Management Applications Simple Network Management Protocol Simple Network Management Protocol version 1 Simple Network Management Protocol version 2 Simple Network Management Protocol version 3 Tool Command Language Transmission Control Protocol Telecommunications Management Network 130 UML Unified Modeling Language 131
128. o de ger ncia Internet assim como outros padr es de ger ncia fornece um mecanismo particular para especificar e manipular a informa o de ger ncia presente na rede Aplica es de ger ncia s o desenvolvidas com base nestes padr es 2 3 A Ger ncia de Falhas Como vimos na se o 2 1 muitas s o as tarefas de ger ncia a serem realizadas Medidas de ger ncia eficazes em cada uma das cinco reas configura o desempenho falhas seguran a e contabilidade s o importantes para manter a rede funcionando sob controle Entretanto uma das reas mais importantes da ger ncia de redes a ger ncia de falhas Na presen a de falhas todo o funcionamento da rede pode ser comprometido e um grande preju zo pode ser contabilizado Em termos pr ticos a parada de uma rede por um curto espa o de tempo pode custar milhares de d lares Empresas dependem cada vez mais das redes de computadores que utilizam e se mostram cada vez mais dispostas a investir em mecanismos que forne am um alto grau de confiabilidade e disponibilidade rede Ent o 11 quanto mais eficiente o gerenciamento de falhas mais eficiente ser o gerenciamento da rede como um todo Defini o 1 No contexto da ger ncia de redes uma falha ou uma falta definida como uma causa de um mau funcionamento Falhas s o respons veis por dificultar ou impedir o funcionamento normal de um sistema Neste trabalho os termos falha e falta t m o mesmo sign
129. o h indica o de congestionamento Frequ ncia m xima public static final periodoMinimo 900 Implementando a interface EventoFalhaListener public void processaEventoFalha EventoFalhakvent ef Se n o h indica o de congestionamento utiliza per odo de monitora o normal Caso contr rio utiliza o periodoMinimo aumentando a freqii ncia if ef get Fonte getNome SituacaoNormal setPeriodo periodoNormal else setPeriodo peridoMinimo 3 2 Instancia o e configura o de componentes 90 3 2 1 Tr s componentes ElementoGerenciadoSnmp para representar cada um dos roteadores Rj R2 e Rs Ri nome rtl dsc ufpb br endIp 150 165 75 171 nome Responsavel Administrador contatoResponsavel admin dsc ufpb br prioridade prioridadeAlta R2 nome rt2 dsc ufpb br endIp 150 165 75 170 nomeResponsavel Administrador contatoResponsavel admin dsc ufpb br prioridade prioridadeMedia Rs nome rt3 dsc ufpb br endIp 150 165 75 169 nomeResponsavel Administrador contatoResponsavel admin dsc ufpb br prioridade prioridadeAlta 3 2 2 Um ReceptorDeTrapsSnmp receptorDeTraps para receber os traps gerados na rede 3 2 3 Tr s componentes GeradorLinkDown gLinkDown gLinkDown e gLinkDowns um por roteador gLinkDown nome LinkDown origem Rj prioridade prioridade Alta gLinkDown
130. o necess rio P1 P2 ao framework construindo novos componentes CNI CN2 a partir dos componentes semiprontos fornecidos Uma vez que os componentes necess rios aplica o estejam dispon veis o programador pode simplesmente instanci los atrav s de um ambiente gr fico configurando suas propriedades e interconectando os ij 12 conforme necess rio Framework CO Framework CO CP1 CP2 CP3 CS E 1 0 framework e seus componentes 2 O programador adiciona funcionalidade P Componentes prontos CP Componentes completando componentes semiprontos semiprontos CSi Editor gr fico Framework CO Figura 4 1 Construindo uma aplica o com base num framework CO No caso em que se utilize uma linguagem OO para implementa o dos componentes a constru o de novos componentes resulta da extens o de classes ou da redefini o de m todos que definem os componentes semiprontos fornecidos pelo framework como veremos em detalhes na se o 4 3 Entretanto o framework ainda pode fornecer outras classes e interfaces no caso de se utilizar a linguagem Java por exemplo para permitir a constru o de componentes novos resultantes da extens o destas classes ou da implementa o das interfaces fornecidas Veja a figura 4 2 Nela o framework visto como um conjunto n o s de componentes prontos e semiprontos CP e CS respectivamente mas como um conjunto que possui al m de componentes outras classes
131. odo s ncrono ou ass ncrono O modo de opera o determinado pelos par metros passados s requisi es realizadas no exemplo anterior se tiv ssemos passado um objeto espec fico em vez de null no momento em que a requisi o feita a aplica o n o ficaria esperando pela resposta mas esta ltima seria enviada para o objeto especificado atrav s de um callback O SNMP Manager API tamb m fornece recursos para a manipula o de eventos ass ncronos traps e permite implementar seguran a ou utilizar criptografia durante a realiza o das opera es 3 3 A API SNMP do Open View Conforme dito anteriormente plataformas de ger ncia tamb m fornecem APIs para o desenvolvimento de aplica es de ger ncia o caso da OVSNMP OpenView SNMP Hewlett Packard 1998a a API SNMP de ger ncia do OpenView plataforma de ger ncia da Hewlett Packard A API OVSNMP est dispon vel em C e C e fornece suporte ao SNMPv1 e SNMPv2 a aplica es constru das para o OpenView Um exemplo de aplica o desenvolvida com base nesta API pode ser encontrado em Gosselin 1999 Assim como nos exemplos vistos anteriormente a OVSNMP tamb m se baseia no conceito de sess es configur veis atrav s das quais requisi es podem ser feitas Mensagens 24 SNMP s o enviadas atrav s da sess o estabelecida com o agente remoto As estruturas de dados b sicas que podem ser utilizadas est o listadas na tabela abaixo Nome da Estr
132. ogramming Sendo assim o uso de componentes traz mudan as no processo de desenvolvimento exigindo uma nova postura do programador de aplica es que simplesmente ter que selecionar componentes e configur los conforme exige determinada situa o A composi o da aplica o o foco e n o sua implementa o A implementa o por sua vez est embutida nos componentes utilizados B 2 Construindo Componentes em Java Quem j usou Delphi ou Visual Basic para desenvolver aplica es j familiar com a no o de um bean A id ia a mesma a linguagem de programa o diferente Um bean um componente de software escrito em Java Mais especificamente um bean um componente de software reutiliz vel que pode ser visualmente manipulado atrav s de uma ferramenta gr fica A API utilizada para a constru o de componentes de software em Java chama se JavaBeans java beans Um bean pode ser composto de v rias classes cujas interfaces externas s o descritas atrav s de suas propriedades de seus m todos e dos eventos gerados Propriedades s o atributos de objetos que podem ser lidos e atualizados atrav s de m todos de acesso Elas podem ser modificadas em tempo de composi o e representam os atributos de estado e de comportamento atrav s dos quais beans podem ser configurados M todos s o os servi os que o cliente pode utilizar 125 Eventos representam mudan as de estado que s o exteri
133. omo alterar o intervalo de monitora o POLL PERIOD de um evento espec fico para permitir que diante de determinada situa o tal evento possa ser mais rapidamente detectado a partir de uma monitora o mais frequente O m ximo que se pode fazer controlar o fluxo de execu o mudan a de estados com base na ocorr ncia de eventos pr configurados Al m disso nenhuma API dispon vel exceto a OVSNMP fornece mecanismos mais elaborados para o tratamento das falhas ocorridas N o h facilidades para fazer correla o de eventos nenhuma informa o sobre a topologia da rede gerenciada est dispon vel por exemplo nem supervis o dos alarmes gerados defini o de filtros de prioridade e mecanismos de notifica o Tamb m n o h facilidades para fazer gerenciamento de tickets O m ximo que a SNMA permite definir uma a o do tipo TICKET atrav s da qual podemos especificar um arquivo onde os tickets previamente configurados ser o registrados 33 N o h como manipular os v rios tickets possivelmente abertos ou gerenci los de uma forma mais eficiente Outrossim nenhuma API permite a interopera o de protocolos de ger ncia diferentes Todas elas pelo menos em suas vers es atuais implementam exclusivamente o SNMP e assim n o poss vel ter uma mesma aplica o que possa monitorar um agente SNMP e um agente DMI por exemplo Seria til ter uma API independente de protocolo que permitisse
134. orizadas para o ambiente onde o bean est inserido E atrav s da troca de eventos que os beans se comunicam uns com os outros Propriedades e m todos representam os servi os oferecidos pelo bean Eventos representam notifica es geradas diante de uma mudan a de estado N o h nenhuma maneira de representar explicitamente os servi os usados pelo componente ali s as linguagens t m se concentrado apenas em especificar os servi os oferecidos por componentes e n o os servi os usados Tipicamente uma ferramenta visual para a manipula o de beans cont m o conjunto de beans que o programador da aplica o pode instanciar e configurar Ele deve arrastar o bean para uma rea central e configur lo atrav s de um editor de propriedades A figura B 1 mostra uma ferramenta chamada BeanBox ToolBox iiel El ES BeanBox FE Properties Jug E3 EvantMonitor File Edt View InfoBus Help seilyBean e background LA ooo 5 E 125 e animationRate TickTock E Voter 4 4 foreground ChangeReporter EE ane Molecule E 9 name P LA QuoteMonitor A SPP errr errr rrr rrr rr font Abede JDBC SELECT SorterBean Figura B 1 BeanBox Ferramentas visuais como o BeanBox descobrem as propriedades e m todos de um bean e os eventos por ele tratados atrav s de um mecanismo conhecido como introspec o Isto feito atrav s da API de reflex o Java java lang reflect que permite descobrir car
135. p implements Serializable public boolean verificaOcorrencial lha TrapEvent trap EventoFa Verifica o tipo de trap return trap getTipodeTrap trap l LinkDown 3 1 2 Um Gerador DeLogs para registrar as ocorr ncias de falhas GeradorDeLogs implements EventoFalhaListener Serializable Implementando a interface EventoFalhaListener public void processal Even toFalha EventoFalhaEvent ef Registra ocorr ncia da falha Ul instancia logEvento ef 89 3 1 3 Um GeradorDeAlarmesHisterese para gerar alarmes diante da ocorr ncia de um congestionamento no roteador R GeradorDeAlarmesHisterese implements EventoFalhaListener Serializable Implementando a interface EventoFalhaListener public void processaEventoFalha EventoFalhaEvent ef GeradorDeEventoFalha fonte ef getFonte Envia uma mensagem indicando a ocorr ncia da falha if fonte getValorAtingido fonte valorLimiar UI instancia enviaMensagem fonte get contatoResponsavel 3 1 4 Um MonitorInteligente que sabe se auto reconfigurar com base no tipo de evento recebido MonitorInteligent xtends Monitor implements EventoFalhaListener O per odo de monitora o quando n o h indica o de congestionamento Fregi ncia m nima public static final periodoNormal 1800 O per odo de monitora o quand
136. pec fico atrav s de seus componentes O programador s precisa configurar os componentes devidamente NF3 3 3 M todo verificaOcorrenciaEventoFalha dos componentes GeradorDeEvento 82 Po FalhaLimiar e GeradorDeEventoFalhaTrap NF3 3 4 Instancia o gr fica dos componentes Utiliza o de componentes para implementar a funcionalidade da aplica o Combina o de framework e componentes Utiliza o da linguagem Java para especifica o e posterior implementa o dos componentes Tabela 4 2 Requisitos e caracter sticas da solu o proposta NF5 Componentes do tipo GrupoInfoGerencia e monitora o paralela das entidades E gerenciadas da rede 4 4 Exemplos de Aplica es Nesta se o s o apresentados tr s exemplos de aplica es constru das com base nos componentes do framework S o mostrados tr s diferentes cen rios em que os componentes especificados s o apropriadamente configurados e interconectados a fim de que se gerencie a rede conforme necess rio Em cada exemplo s o destacadas as tr s etapas a serem realizadas durante a constru o de uma aplica o constru o de novos componentes instancia o e configura o dos componentes necess rios e interconex o dos componentes instanciados Exemplo 1 Deseja se monitorar um roteador R a fim de se identificar se a taxa de erros de uma de suas interfaces ultrapassou determinado valor Em caso positivo um alarme deve ser d
137. pecifica es testes documenta o e tudo o mais que um pacote de software pode conter Em termos de implementa o e ainda segundo D Souza amp Wills 1999 componentes a t m interfaces expl citas e bem definidas para os servi os que oferece b t m interfaces expl citas e bem definidas para os servi os que requer e c podem ser conectados a outros componentes talvez ap s a configura o de algumas propriedades sem modificar os componentes em si Um componente consiste tipicamente de v rias classes c digo bin rio defini es de interfaces e outros recursos que s o usados para a sua configura o arquivos de dados contendo formul rios par metros imagens etc 124 A utiliza o de componentes deve permitir que todo ou quase todo o trabalho seja feito pela composi o de peda os existentes Isso significa que no processo de desenvolvimento de software novas etapas podem surgir como o caso da etapa de composi o de aplica es que consiste em juntar componentes para obter a funcionalidade de cada aplica o A composi o pode ser feita por terceiros que nem ao menos t m acesso a detalhes de implementa o do componente A configura o de componentes feita atrav s da modifica o de seus atributos Attribute Programming e para isso ferramentas de composi o de aplica es ou simplesmente ferramentas visuais como Delphi ou Visual Basic s o frequentemente utilizadas Visual Pr
138. pecifico etOrigemDoTrap tOrigemDoTrap etTipoDoTrap tTipoDoTrap etTimeStamp tTimeStamp etGig tGig ReceptorDeTraps EBtrapListeners gera eterminaTipoDeT rap etTrapDaRede envia TrapEvent lt lt Interface gt gt TrapListener criaTrapEvent addTrapListener removeTrapListener isparaProcessaT rap run A a a ReceptorDeTrapsSnmp Figura 5 1 Diagrama de classes parte II EBprocessaTrap A T GeradorDeEventoFalhaTrap QverificaOcorrenciaEventoFalha GeradorDeEventoFalha 801 Ev entoFalhaEv ent gera Deer envia Ev entoFalhaEv ent 1 A lt lt Interface gt gt CorrelatorDeEventoFalha EventoFalhalisten r deusa EBprocessaEventoFalha 7 AS CorrelatorDeEv entoFalhaCompressao CorrelatorDeEv entoFalhaSupressao CorrelatorDeEv entoFalhaC MP Eno aloDeTempo etInterv aloDeTempo EBostContador etContador etInterv aloDeTempo etInterv aloDeTempo EBoetiniciolntTempo setIniciolntTempo ad ES setFimintTempo Figura 5 1 Diagrama de classes parte IV Cap tulo 6 Conclus es Neste trabalho especificamos uma solu o cujo principal objetivo facilitar o desenvolvimento de aplica es de ger nci
139. prover os mecanismos b sicos e necess rios para atender s necessidades deste tipo de aplica o e ao dispensar o programador de detalhes que n o est o diretamente associados ao dom nio do problema o programador pode finalmente concentrar se na obten o da funcionalidade b sica de sua aplica o No cap tulo seguinte a especifica o da solu o proposta descrita em detalhes 35 Cap tulo 4 Um Framework para a Ger ncia de Falhas Como vimos no cap tulo anterior as APIs atualmente utilizadas para a implementa o de aplica es de ger ncia n o fornecem o n vel de abstra o adequado de modo a facilitar efetivamente o trabalho do programador De um modo geral programadores precisam ter uma boa experi ncia de programa o para atingir os seus objetivos no que diz respeito ao desenvolvimento de aplica es de ger ncia de redes A pergunta que surge ent o como prover este n vel de abstra o Em nosso caso particular a pergunta adequada seria o que devemos prover para satisfazer as necessidades do programador de aplica es de ger ncia de falhas o nosso usu rio Neste cap tulo descrevemos a especifica o de uma solu o que busca fornecer um n vel de abstra o mais adequado ao desenvolvimento de aplica es de ger ncia de falhas Trata se de um framework baseado em componentes de software reutiliz veis para a ger ncia de falhas O desenvolvimento de um framework se baseia nas etapa
140. r prio programador 4 3 7 Resumo Conforme apresentado durante todo o cap tulo 4 o framework fornece um conjunto b sico de componentes a partir do qual aplica es de ger ncia de falhas podem ser desenvolvidas De um modo geral tr s etapas devem ser realizadas para construir cada aplica o 1 constru o de novos componentes para acomodar as novas necessidades identificadas durante a especifica o da aplica o esta etapa nem sempre necess ria desde que os componentes a serem utilizados j estejam dispon veis 77 2 instancia o e configura o visual de componentes fornecidos pelo framework e de componentes criados pelo pr prio programador e 3 interconex o tamb m visual dos componentes instanciados para que do fluxo de eventos resultante cada componente envolvido possa realizar sua tarefa apropriadamente Foram apresentados quais tipos de componentes podem ser constru dos e quais tipos podem ser diretamente instanciados e configurados A tabela 4 1 lista todos os componentes apresentados Componente Descri o ElementoGerenciadoSnmp Utilizado para representar as entidades SNMP a serem gerenciadas Implementa a interface ElementoGerenciado e fornece componentes do tipo GrupoInfoGerencia InfoGerenciaSnmp Utilizado para representar vari veis MIB Implementa a interface InfoGerencia GrupoInfoGerencia Agrupa componentes do tipo InfoGerencia representando grupos de info
141. r a quantidade de informa o apresentada ao operador da rede ao mesmo tempo em que acrescentar valor sem ntico aos eventos gerados Por exemplo saber que uma determinada interface de um roteador foi desligada vari vel MIB ifAdminStatus DOWN pode n o representar uma falha mas saber que esta mesma interface foi desligada tr s vezes no intervalo de uma hora pode representar uma situa o de interesse Neste caso n o s se reduz o n mero de eventos de 3 para 1 como tamb m se acrescenta significado ao 39 evento resultante Analogamente descobrir que um conjunto de agentes tornou se inacess vel pode n o ter qualquer relev ncia diante do fato de que o roteador atrav s do qual se tem acesso a eles tamb m est inoperante Neste caso os primeiros eventos gerados devem levar conclus o de problemas no roteador permitindo resolver o problema de forma mais eficaz A solu o portanto deve fornecer meios para que a correla o possa ser feita pois a partir do momento em que poss vel considerar apenas a informa o de verdadeira relev ncia adicionando lhe valor torna se poss vel fazer diagn sticos mais precisos e conseqiientemente um gerenciamento de falhas mais eficiente Entre outras coisas a solu o deve fornecer informa o sobre a topologia da rede para que se possa tirar conclus es sobre a influ ncia que alguns eventos exercem sobre outros como no caso do ltimo exemplo descrit
142. ra 4 13 GeradorAltaTaxaDeErros 10 Todo componente em Java tamb m chamado JavaBean deve implementar a interface java io Serializable Para maiores detalhes consulte o ap ndice B 60 Constru do o novo componente pode se instanci lo configur lo e associ lo ao Monitor que fornece a informa o de ger ncia a ser utilizada para verificar a ocorr ncia da falha isto o valor da taxa de erros de R Toda vez que o Monitor fornecer tal informa o o GeradorAltaTaxaDeErros verifica se a falha em quest o ocorreu Analogamente podemos criar um outro componente GeradorLinkDown a partir do GeradorDeEventoFalhaTrap para verificar se uma das interfaces de R est inoperante Definimos o m todo verificaOcorrenciaEventoFalha como a seguir Cria o do componente GeradorLinkDown public GeradorLinkDown extends GeradorDeEventoFalhaTrap implements Serializable public boolean verificaOcorrenciaEventoFalha TrapEvent trap Retorna true se o trap recebido do tipo linkDown O framework verifica automaticamente se a origem do trap recebido igual a a R propriedade origem do GeradorLinkDown return trap getTipoDeTrap trap linkDown Figura 4 14 GeradorLinkDown Constru do o novo componente pode se instanci lo configur lo e associ lo ao ReceptorDeTrapsSnmp de maneira que o novo componente possa receber os traps gerados na rede e ent o verificar s
143. ra 4 32 Exemplo 1 Exemplo 2 Deseja se prever um congestionamento no roteador R da rede Suponha que existam dois servidores S e S2 S tem normalmente muitas aplica es tr fego em rajada executando de forma concorrente as quais acessam um servidor remoto e S2 um servidor 85 multim dia que gera um alto tr fego na rede O grande n mero de conex es abertas em S aliado grande largura de banda consumida por S2 leva eventualmente a taxas inaceit veis de perda de pacotes no roteador R Deseja se portanto monitorar S e S gt para que se possa identificar o congestionamento antes que ele ocorra e assim realizar uma ger ncia pr ativa 2 1 Constru o de novos componentes 2 1 1 Um GeradorTaxaDeTrafegoAlta para avaliar o n mero de conex es abertas em S e o tr fego gerado por S2 public void GeradorTaxaDeTrafegoAlta extends GeradorDeEventoFalhaLimiar implements Serializable public boolean verificaOcorrenciaEventoFalha ElementoGerenciado egs Verifica se o n mero de conex es TCP abertas em S o tr fego gerado por S ultrapassam seus respectivos limiares Retorna true em caso positivo return get InfoGerenciaDaOrigem QuantConexoesAbertas egs 0 gt Int parseInt getLimiares QuantConexoesAbertas getValor amp amp getInfoGerenciaDaOrigem TaxaDeTrafego egs 1 gt Double parseDouble getLimiares TaxaDeTrafego getValor
144. rap recebido Observe portanto a flexibilidade que o framework fornece para que o programador possa definir suas condi es de ocorr ncia de falhas especialmente no caso de um 64 GeradorDeEventoFalhaLimiar Primeiramente o programador tem dispon vel todo o GrupoInfoGerencia de cada ElementoGerenciado monitorado pelos monitores com os quais o GeradorDeEventoFalhaLimiar est associado Isto permite definir condi es onde v rias unidades de informa o de ger ncia podem ser utilizadas conforme mostra a figura 4 16 Cria o do componente GeradorAltaPerdaDePacotes public GeradorAltaPerdaDePacotes extends GeradorDeEventoFalhaLimiar implements Serializable public boolean verificaOcorrenciaEventoFalha ElementoGerenciado egs Retorna true se a quantidade total de pacotes descartados por egs 1 for maior que o valor do limiar TaxaDeErros return get InfoGerenciaDaOrigem PacotesDescartadosIn egs 0 getDouble getInfoGerenciaDaOrigem PacotesDescartadosOut egs 1 getDouble gt Double parseDouble getLimiares TaxaDeErros getValor Figura 4 16 GeradorAltaPerdaDePacotes Depois se o GeradorDeEventoFalhaLimiar estiver realmente associado a v rios monitores o programador pode definir condi es de ocorr ncia de falhas ao analisar a informa o oriunda de diferentes entidades da rede Por exemplo Cria o do componente GeradorAltaTaxa
145. rconectar os componentes dispon veis Num framework CO analogamente ao que ocorre com objetos no caso de um framework OO cada componente implementa uma parte bem definida da funcionalidade geral do framework e da coopera o entre os componentes utilizados obt m se a funcionalidade da aplica o Para permitir tratar caracter sticas espec ficas de cada aplica o entretanto em vez de fornecer simplesmente classes abstratas que podem ser devidamente estendidas o que ocorre no caso de um framework OO um framework CO fornece componentes que podem ser visualmente configurados Al m disso ele pode fornecer componentes semiprontos a partir dos quais novos componentes podem ser criados Cada novo componente criado passa a fazer parte do framework e uma vez dispon vel pode ser tamb m configurado atrav s de um ambiente gr fico permitindo finalmente a constru o visual da aplica o A figura 4 1 mostra este processo Na figura 4 1 tem se um framework CO que possui seus pr prios componentes CP1 CP2 CP3 e que fornece componentes semiprontos CS1 CS2 a partir dos quais o programador pode construir novos componentes medida em que uma nova aplica o constru da necessidades particulares podem ser identificadas por exemplo a necessidade de verificar a ocorr ncia de uma determinada falha Neste momento para fazer com que o framework atenda s novas necessidades identificadas o programador pode acrescentar o c dig
146. res contribuem para esta situa o Houck et al 1995 um dispositivo pode indicar v rias ocorr ncias de um mesmo evento em decorr ncia de uma nica falha a falha pode ser intrinsecamente intermitente o que implica na ocorr ncia de um evento a cada nova ocorr ncia da falha a falha de um componente pode resultar na ocorr ncia de um evento a cada vez que se invoca o servi o prestado por esse componente uma nica falha pode ser detectada por m ltiplos componentes da rede cada um deles constatando a ocorr ncia de um evento a falha de um dado componente pode afetar diversos outros componentes causando a propaga o da falha Para contornar estes problemas levando informa o verdadeiramente til ao operador da rede aplica es de ger ncia de falhas fazem uso da correla o de eventos Defini o A correla o de eventos consiste na interpreta o conceitual de m ltiplos eventos levando atribui o de um novo significado aos eventos originais Jakobson amp Weissman 1993 A correla o de eventos geralmente tem como objetivo reduzir a quantidade de alarmes transferidos aos operadores do sistema de ger ncia de rede ao aumentar o conte do sem ntico dos eventos resultantes 14 A possibilidade de reduzir a quantidade de informa o gerada respeitando a propriedade de depend ncia que existe entre os eventos ocorridos faz da correla o de eventos um importante conceito no sentido
147. res O primeiro evento gerado apenas quando o limiar atingido pela primeira vez Outro evento s gerado quando o evento gerado anteriormente resultou do cruzamento do valor utilizado na dire o oposta A figura 4 19 mostra este mecanismo em a o O primeiro evento e1 resultou do cruzamento do limiar l o segundo evento e2 resultou do cruzamento do valor de reposicionamento r o terceiro evento e3 resultou novamente do cruzamento de 1 quando o valor de reposicionamento foi atingido pelo menos uma vez e assim sucessivamente 1 e e3 representam os eventos gerados Nas situa es A e B s o observados um limiar m ximo e um limiar m nimo respectivamente Situa o A Situa o B i es z es Figura 4 19 Mecanismo de histerese Sendo assim o framework fornece um componente pronto muito til que implementa um mecanismo de histerese para identifica o de falhas Este componente se chama GeradorDeEventoFalhaComHisterese e pode ser visto na figura 4 20 Ele gera dois tipos de eventos diferentes de acordo com o valor atingido GeradorDeEventoFalhaComHisterese prioridadeBaixa prioridadeMedia prioridadeAlta alorLimiar 67 alorRearm nome String omeEventoRearm String escricao String escricaoEventoRearm String Figura 4 20 GeradorDeEventoFalhaComHisterese Para utilizar um GeradorDeEventoFalhaComHisterese deve se configurar os valores do limiar e do rearm Al m
148. rma o de ger ncia utilizados pela aplica o Monitor Respons vel pela monitora o s ncrona Controla a frequ ncia com que um Element oGerenciado deve fornecer determinada informa o Gera eventos que cont m o resultado da monitora o realizada GrupoInfoGerencia ReceptorDeTrapsSnmp Respons vel pela monitora o ass ncrona Recebe todos os traps SNMP gerados na rede repassando traps do tipo TrapEvent Constru do a partir do componente ReceptorDeTraps GeradorDeEventoFalhaLimiar Gera eventos identifica falhas do tipo EventoFalhaEvent com base em limiares pr configurados O programador deve completar este componente para determinar o tipo de falha a ser identificado GeradorDeEventoFalhaTrap Gera eventos identifica falhas do tipo EventoFalhaEvent com base no tipo de trap recebido O programador deve completar este componente para determinar o tipo de falha a ser identificado GeradorDeEventoFalhaComHisterese Gera eventos identifica falhas do tipo 78 EventoFalhaEvent com base num mecanismo de histerese CorrelatorDeEventoFalha Faz correla o de eventos identificando novos tipos de falhas ao gerar eventos do tipo EventoFalhaEvent Implementa a interface EventoFalhaListener H tr s componentes que implementam diferentes tipos de correla o CorrelatorDeEventoFalhaCompressao CorrelatorDeEventoFalhaS
149. s ncrono para obter o valor da vari vel sysUpTime Ela tamb m estabelece um limite de tempo 10 segundos at o qual a resposta esperada Instancia sess o com o nome dado SnmpSession sessao new SnmpSession Sess o atual Usa o agente roteadorA como agente default sessao setDefaultPeer roteadoraA 3 a Ea Die Se 5 r E Contunidades s o utilizadas para prover seguran a e h tipicamente dois tipos de comunidades uma para cada permiss o de acesso leitura e escrita Para que o gerente tenha acesso informa o presente no agente ele deve conhdcer o nome da comunidade conforme especificado pelo agente Tal par metro utilizado para autentica o Especifica as op es de sess o desejadas sessao snmpOptions setPduFixedOnError false Constr i a lista de vari veis a ser recuperada SnmpVarbindList lista new SnmpVarbindList lista de vari veis Prepara uma lista de vari veis para obten o do valor da vari vel sysUpTime lista addVariable sysUpTime 0 Cria uma requisi o no modo ass ncrono par metro de callback null para obten o do valor desejado SnmpRequest request sessao snmpGet null lista Envia a requisi o e espera por no m ximo 10 seg boolean fim request waitForCompletion 10000 Figura 3 4 Instanciando uma requisi o no modo s ncrono Assim como no Tcl opera es podem ser realizadas no m
150. s o das atividades de ger ncia em reas funcionais distintas facilita a modulariza o de projeto e a implementa o de solu es de ger ncia mas vale salientar que para se ter um gerenciamento eficaz necess ria a integra o entre as diversas reas Na verdade uma falha pode causar redu o no desempenho da rede um erro de configura o pode causar preju zo para a seguran a uma viola o de seguran a pode comprometer a contabiliza o dos recursos utilizados e em qualquer uma destas situa es a es corretivas ou ajustes sobre a configura o do sistema podem ser necess rios Gerenciar uma rede portanto consiste em tratar aspectos em cada uma das cinco reas levando se em conta a depend ncia que possa existir entre elas Plataformas de ger ncia como HP OpenView da Hewlett Packard NetView da IBM e SunNetManager da Sun Microsystems fornecem uma s rie de facilidades para realiza o destas tarefas e s o muitas vezes utilizadas Al m disso outras aplica es inclusive baseadas em web Sauv 1999 s o desenvolvidas a fim de atender a necessidades de ger ncia espec ficas 2 2 Um Modelo de Ger ncia O desenvolvimento de aplica es de ger ncia se baseia numa arquitetura gen rica que possui quatro componentes a saber Esta o de ger ncia hospedeiro onde aplica es de ger ncia s o executadas para monitorar e controlar os elementos gerenciados O software composto por estas aplica
151. s b sicas de qualquer processo de desenvolvimento de um produto de software Rumbaugh et al 1999b levantamento de requisitos an lise do dom nio do problema projeto da solu o implementa o e testes Contudo vale salientar que algumas metodologias especialmente voltadas para o desenvolvimento de frameworks Landin amp Niklasson 1998 Johnson amp Roberts 1998 destacam um importante aspecto as tr s primeiras etapas do processo de desenvolvimento se baseiam em exemplos de aplica es que mais tarde poder o ser desenvolvidas com base no framework resultante ou seja os requisitos e funcionalidade do framework s o identificados a partir das caracter sticas e requisitos comuns aos diversos exemplos de aplica es considerados As tr s primeiras etapas foram realizadas para especifica o do framework proposto neste trabalho e a linguagem de modelagem UML Unified Modeling Language Rumbaugh et al 1999a foi utilizada 36 Na se o 4 1 apresentamos o levantamento de requisitos realizado a partir do estudo e da an lise de algumas aplica es de ger ncia de falhas Os requisitos comuns aos exemplos considerados se transformaram em requisitos do framework e al m disso s o identificados outros requisitos que caracterizam o n vel de abstra o a ser fornecido A an lise do dom nio do problema j foi sucintamente apresentada na se o 2 3 2 quando caracterizamos o comportamento gen rico de uma aplica o de ger
152. s de acompanhamento de ocorr ncias portanto prov em uma base de dados com informa o sobre o processo de resolu o dos eventuais problemas identificados na rede Todos os esfor os envidados no sentido de resolver determinado problema s o registrados para que esta informa o possa ser til futuramente nos casos em que o mesmo problema volte a ocorrer ou problemas similares sejam detectados A corre o de falhas tamb m se baseia na notifica o sobre as falhas ocorridas a qual pode ser feita visualmente atrav s de uma interface gr fica que indica o que est funcionando com que estado via mensagem eletr nica pager etc Isto tamb m envolve a realiza o de registros de ocorr ncias logging 13 2 3 1 A Correla o de Eventos O principal requisito para se fazer uma ger ncia de falhas de forma integrada o fornecimento da informa o sobre o funcionamento da rede em um centro de ger ncia esta o de ger ncia em tempo real Meira 1997 As anormalidades que ocorrem durante a opera o da rede provocam a gera o de alarmes indicando o estado da rede Com o crescimento das redes entretanto a quantidade de alarmes gerados pode ser muito grande em decorr ncia da quantidade de eventos ocorridos e isto fatalmente tornar o processamento individual de cada um destes alarmes invi vel e humanamente imposs vel Al m disso muitos dos alarmes recebidos n o cont m informa o original e diversos fato
153. s e define as interfaces e restri es que uma implementa o deve satisfazer o c digo pode ser reutilizado uma vez que um novo componente criado pelo usu rio pode herdar toda a implementa o do componente 109 semipronto do qual ele derivado e os componentes dispon veis podem ser graficamente manipulados atrav s de uma ferramenta de composi o visual de aplica es Com tudo isso o programador pode se concentrar nas particularidades de sua aplica o enquanto conta com o alto grau de reusabilidade fornecido Ao especificar a solu o identificamos os principais componentes do framework e definimos a forma de interconect los Definimos tamb m como o programador pode construir novos componentes para modificar e ou estender o comportamento do framework Enfim ao propor um framework CO para o desenvolvimento de aplica es de ger ncia de falhas vimos que poss vel elevar o n vel de abstra o fornecido facilitando o desenvolvimento deste tipo de aplica o A arquitetura proposta e as abstra es especificadas atendem aos requisitos listados de modo que arquiteturalmente falando alcan amos os objetivos propostos de forma satisfat ria 6 1 Trabalhos Futuros A conclus o deste trabalho nos permite identificar alguns encaminhamentos futuros no sentido de aperfei oar e estender a especifica o de um framework baseado em componentes de software reutiliz veis para aplica es de ger ncia de falhas
154. screve esta situa o De acordo com a figura um GeradorDeEventoFalhaLimiar pode estar associado n o s a um mas a v rios monitores de maneira que possa receber informa o de diferentes entidades gerenciadas O GeradorDeEventoFalhaTrap por sua vez recebe os traps gerados por qualquer entidade gerenciada da rede atrav s do mesmo ReceptorDeTrapsSnmp Monitor ReceptorDeTrapsSnmp envia dados 1 monitorados eus trap GeradorDeEventoFalhaLimiar GeradorDeEventoFalhaTrap Bs prioridadeBaixa WS prioridadeBaixa IGS prioridadeMedia Bs prioridadeMedia Bs prioridadeAlta ES prioridadeAlta nome String escricao String esponsavel String ontatoResponsavel String nome String escricao String responsavel String EBcontatoResponsavel String rioridade int prioridade int ataUltimaOcorrencia Date ataUltimaOcorrencia Date EBorigem ElementoGerenciado EBorigem ElementoGerenciado EBlimiares Limiar riaEventoFalha oString erificaOcorrenciaEventoFalha gera 1 1 gera 58 EScriaEventoFalha EStoString ESverificaOcorrenciaEventoFalha m EventoFalhaEvent EXtonte GeradorDeEventoFalha Figura 4 12 GeradorDeEventoFalhaLimiar e GeradorDeEventoFalhaTrap Os geradores de eventos GeradorDeEventoFalhaLimiar e GeradorDe EventoFalhaTrap possuem v rias propriedades que podem
155. se amp McCloghrie 1990b Rose M T McCloghrie K Structure and Identification of Management Information for TCP IP based Internets Request for Comments 1155 DDN Network Information Center SRI International May 1990 Rose amp McCloghrie 1991 Rose M T McCloghrie K Management Information Base for Network Management of TCP IP based Internets MIB II Request for Comments 1213 Hughes LAN Systems Inc Performance Systems International March 1991 Rose amp McCloghrie 1995 Rose M T McCloghrie K How to Manage Your Network Using SNMP The Network Management Practicum Prentice Hall 1995 Rumbaugh et al 1999a Rumbaugh J Booch G Jacobson I The Unified Modeling Language Reference Manual Addison Wesley 1999 Rumbaugh ef al 1999b Rumbaugh J Booch G Jacobson I The Unified Software Development Process Addison Wesley 1999 Sauv 1999 Sauv J P WebManager A Web Based Network Management Application LANOMS Latin American Network Operations and Management Symposium Rio de Janeiro Brasil Dezembro 1999 Sch nw lder amp Langendorfer 1996 Sch nwalder J Langend rfer H How to Keep Track of Your Network Configuration Technical University of Braunschweig Germany November 1993 Sch nw lder amp Langendorfer 1995 Sch nwalder J Langend rfer H Tcl Extensions for Network Management In Proceedings 3rs Tcl Tk Workshop Toronto Canada 1995 Sch nw
156. ser configuradas pelo programador e que servir o para caracterizar os eventos a serem gerados S o elas nome um nome que identifica o tipo de falha descrita pelo evento gerado por exemplo AltaTaxaDeErros Utilizado por um componente que esteja associado a v rios destes geradores e deseje identificar qual o evento recebido num determinado instante descricao uma descri o complementar sobre o tipo de falha descrito pelo evento gerado por exemplo Alta taxa de erros devido a problemas na interface do equipamento Pode ser til no momento da gera o de logs e at mesmo para a gera o de alarmes constituindo parte do conte do da notifica o a ser enviada ao operador da rede origem a entidade da rede onde a falha ocorreu prioridade indica a gravidade da falha descrita pelo evento gerado e consegiientemente a urg ncia com que o problema deve ser resolvido Por default pode assumir os seguintes valores prioridadeAlta prioridadeMediaeprioridadeBaixa responsavel o nome da pessoa que deve ser especialmente notificada sobre a ocorr ncia da falha descrita pelo evento gerado contatoResponsavel uma informa o e mail telefone etc para contato com o responsavel 59 O GeradorDeEventoFalhaLimiar ainda possui a propriedade limiares que representa os limiares a serem utilizados para verifica o da ocorr ncia de falhas Enfim cada gerador configurado identifica um determinado
157. siderando a heterogeneidade de tecnologias e a quantidade de fabricantes das atuais redes obter uma vis o geral do estado da rede com base na informa o colhida seria uma tarefa terrivelmente complexa Ent o para permitir uma melhor integra o entre as diferentes tecnologias no que diz respeito ger ncia de redes v rios padr es foram propostos de modo a especificar a estrutura e o conte do da informa o de ger ncia que deve ser mantida por dispositivos de rede espec ficos independentemente do fabricante read response x gt impressora esta o de esta o de roteador roteador Esta o de Ger ncia trabalho trabalho gerente Figura 2 1 Vis o f sica da rede gerenciada Como exemplos de padr es de ger ncia podemos citar o padr o OSI definido pela ISO ISO IEC 7498 1984 o padr o DMI Desktop Management Interface DMTF 1998 liderado pela Microsoft o padr o TMN Telecommunications Management Network Raman amp Raman 1999 desenvolvido pela ITU T International Telecommunications Union para o gerenciamento de redes de telecomunica es e o padr o Internet Case et al 1990 Dentre todos o padr o Internet o mais utilizado e sem a pretens o de esgotar o assunto mas com a inten o de fornecer uma vis o geral ele ser apresentado com mais detalhes a seguir
158. ssui pelo menos uma classe cujo nome igual ao componente ao qual pertence e cuja responsabilidade implementar a funcionalidade b sica do componente do qual faz parte Para isto esta classe pode estender outras classes pode implementar algumas interfaces e pode ainda ser estendida no caso de um componente semipronto Assim a classe ElementoGerenciadoSnmp estende a classe Elemento GerenciadoAdapter e respons vel por fornecer informa o de ger ncia SNMP a classe Monitor respons vel por fazer a monitora o s ncrona da rede gerando eventos do tipo MonitorEvent a classe GeradorDeEventoFalhaLimiar herda todos os m todos e atributos da classe GeradorDeEventoFalha implementa a interface MonitorListener gera eventos do tipo EventoFalhaEvent e ainda deve ser estendida lembre se que o componente GeradorDeEventoFalhaLimiar um componente semipronto para que de acordo com a funcionalidade adicionada ela possa finalmente verificar a ocorr ncia de falhas segundo os limiares pr configurados e assim por diante Algumas das novas classes at ent o n o mencionadas s o resultados de generaliza es feitas como o caso da classe GeradorDeEventoFalha Outras classes como ElementoGerenciadoAdapter e InfoGerenciaAdapter s o simplesmente classes de adapta o padr o de projeto Adapter Gamma et al 1994 que facilitam a implementa o das interfaces ElementoGerenciado e InfoGerencia
159. sticas da linguagem Java No cap tulo 6 apresentamos as conclus es e trabalhos futuros Cap tulo 2 A Ger ncia de Redes de Computadores Gerenciar uma rede de computadores consiste em supervisionar e controlar o seu funcionamento para que ela satisfa a as necessidades dos seus usu rios Sloman 1994 Uma ger ncia eficaz pode implicar em significativo acr scimo na produtividade da rede atrav s da melhor utiliza o dos recursos dispon veis Consequentemente uma melhoria na ger ncia da rede pode trazer como resultados a melhoria na qualidade dos servi os do ponto de vista dos usu rios e a redu o nos custos de opera o e manuten o da rede Meira amp Lages 1998 No caso das atuais redes que tornam se cada vez maiores e heterog neas esta uma tarefa indispens vel Neste cap tulo fornecemos uma vis o geral sobre a ger ncia de redes ao apresentar um conjunto de conceitos b sicos sobre o assunto A se o 2 1 descreve as atividades de ger ncia agrupadas em reas funcionais distintas A se o 2 2 apresenta um modelo gen rico para solu es de ger ncia e exemplifica uma implementa o deste modelo atrav s do padr o de ger ncia Internet n o pretendemos apresentar a descri o detalhada deste padr o de ger ncia mas apenas o suficiente para o bom entendimento e f cil leitura dos cap tulos seguintes A se o 2 3 apresenta e estabelece conceitos relacionados especialmente ger ncia de falhas
160. t callback gt s getbulk lt nr gt lt mr gt lt vbl gt lt callback gt s set lt vbl gt lt callback gt Ss inform lt trapOid gt lt vbl gt lt callback gt s trap lt trapOid gt lt vbl gt s bind lt notification gt lt script gt Ss wait lt id gt Ss walk lt var gt lt vbl gt lt body gt Ss destroy snmp wait Figura 3 1 API SNMP Tcl 20 Todas as opera es SNMP get getnext getbulk set informe trap podem ser realizadas no modo s ncrono ou no modo ass ncrono No modo s ncrono a aplica o fica bloqueada esperando pela resposta requisi o feita Uma lista de vari veis de ger ncia ou um erro s o retornados No modo ass ncrono a aplica o n o fica bloqueada mas especifica um par metro de retorno callback que ser associado requisi o enviada A resposta ent o ser recebida atrav s deste par metro O resultado da opera o e o estado da informa o retornada s o obtidos no c digo atrav s de sequ ncias iniciadas com o s mbolo Adicionalmente a op o wait faz com que o programa script espere at que todas as requisi es estabelecidas durante seu fluxo de execu o sejam processadas A figura 3 2 mostra um exemplo de c digo escrito com base nesta API de ger ncia proc obtemSysUpTime endRede for set i 1 i lt 10 incr i 1 abre uma sess o s set s snmp session address SendRede i faz a requisi o e espec
161. tPrioridade etStatus ESsetConfiguradorDeRequisicao ESgetGrupolntoGerencia ESgetConfiguradorDeRequisicao ConfiguradorDeRequisicaoSnmp ESgetComunidade ESsetcomunidade ConfiguradorDeRequisicao WgetNome ESsetNome etTimeout setT imeout ESgetNumeroRetransmissoes ES setNumeroRetransmissoes fornece 1 GrupolnfoGerencia etNome tNome SaddinfoGerencia etInfoGerencia etQuantInfoGerencia EgetNome InfoGerenciaSnmp lt lt Interface gt gt InfoGerencia k Nok tNome etDescricao tDescricao ESgetStatus A InfoGerenciaAdapter EBgetoidy EBsetoia Figura 5 1 Diagrama de classes parte I 901 lt lt Interface gt gt ElementoGerenciado fornece informa o de ger ncia MonitorEv ent WeetF onte Limiar WoetNome setNome etDescricao gera 1 setDescricao Meia etValor EBmonitorListeners Msetvaloro run SaddMonitorListener ESremov eMonitorListener EEBais paraProcessaDados Monitorados em etPeriodo E Periodo GeradorDeEventoFalhaLimiar WcetEg Einf oDisponiv el EBseteg ESoetcig EBgetintoGerenciaDaOrigem ESsetGig BXverificaOcorrenciaEv entoF alha
162. tamb m reduzem se os custos com manuten o e testes Quando v rias aplica es s o desenvolvidas com base no mesmo framework apenas o framework em si e o c digo que diferente para as diversas aplica es deve ser mantido Isto tamb m significa que mudan as t m que ser feitas num nico lugar garantindo consist ncia Al m disso todos os testes feitos no framework s o reutilizados pelas diversas aplica es que o utilizam A maximiza o da reusabilidade tem seu nus De fato desenvolver um framework mais dif cil do que construir aplica es isoladas ou m dulos de bibliotecas j que a arquitetura do framework tem que ser definida assim como a intera o entre os m dulos internos Johnson amp Foote 1991 Apesar disso muitos frameworks t m sido desenvolvidos pois na rela o custo benef cio h uma proporcionalidade que em geral observa se e que no 121 final das contas compensa Um exemplo de framework pode ser encontrado em Beck amp Gamma 1998 Trata se de um framework para teste de unidade em Java 122 Ap ndice B Componentes de Software Reutiliz veis Se voc busca melhoramentos consider veis em termos de produtividade de software uma das coisas mais importantes a serem feitas parar de escrever aplica es do princ pio toda vez que voc inicia um novo projeto Em vez disso voc deve constru las usando componentes de software que j existem D Souza amp Wills 1
163. tener Serializablef public void processaEventoFalha EventoFalhaEvent ef Inclui tratamento de falhas aqui Figura 4 28 GeradorDeAlarmes Qualquer novo componente que implemente esta interface pode ser conectado a qualquer tipo de gerador de eventos GeradorDeEventoFalhaLimiar GeradorDe EventoFalhaTrap e GeradorDeEventoFalhaComHisterese ou a um CorrelatorDeEventoFalha a fim de que possa ser informado sobre a ocorr ncia das falhas a serem tratadas Um componente respons vel pela gera o de alarmes conforme descrito na figura 4 28 ou um componente respons vel pelo registro de ocorr ncias s o exemplos de componentes que poderiam implement la HT embre se que al m de componentes semiprontos o framework tamb m especifica interfaces e classes que podem ser utilizadas para construir novos componentes 73 4 3 5 Fornecendo o Suporte a V rios Modelos de Ger ncia At agora vimos como construir novos componentes a partir de componentes semiprontos escrevendo m todos que o pr prio framework determina Para construir um novo gerador de eventos baseado em limiares GeradorDeEventoFalhaLimiar por exemplo basta escrever o m todo verificaOcorrenciaEventoFalha para construir um novo componente para correla o de eventos basta escrever o m todo correlaciona Entretanto tamb m poss vel utilizar interfaces adicionais fornecidas pelo framework conforme vimos
164. turas de dados utilizadas para a realiza o de opera es SNMP n o s precisam ser alocadas como ocorre com as outras APIs apresentadas mas tamb m precisam ser explicitamente liberadas Linguagens como C ou C n o possuem garbage collection mecanismo atrav s do qual o espa o de mem ria previamente alocado e em desuso automaticamente liberado e neste caso toda a libera o de mem ria deve ser feita explicitamente pela pr pria aplica o De acordo com a tabela 3 1 estruturas de dados s o criadas e liberadas atrav s de fun es espec ficas OVsnmpOpen OVsnmpF ree etc Al m disso outras estruturas precisam ser alocadas dinamicamente Considere a estrutura OVsnmpPdu por exemplo descrita pela figura 3 7 Ela possui alguns campos que s o espec ficos de determinado tipo de mensagem trap por exemplo Neste caso estes campos devem ser alocados dinamicamente sendo de responsabilidade do programador realizar esta tarefa atrav s de fun es da API como OVsnmpMalloc OvsnmpCalloc OVsnmpRealloc e OVsnmpFree A manipula o das estruturas de dados dispon veis portanto torna se bem mais complexa OVsnmpPdu OVsnmpVarBin OVsnmpVarBin endere o proxVari vel proxVari vel tipoRequisi o idVari vel idVari vel vari veis IdNotifica o Espec ficos de mensagens trap SNMPv2 e inform tipoEspecifico Espec ficos de mensagens trap SNMPv1 endAgente Espec ficos de mensagens trap SNMPvl e trap ES ae oe
165. upressao e CorrelatorDeEventoFalhaCMP Tabela 4 1 Os componentes do framework Com base nestes tipos de componentes segue abaixo uma lista de passos que podem ser seguidos para que se possa construir determinada aplica o Instanciar e configurar componentes do tipo ElementoGerenciado para representar as entidades da rede roteadores switches esta es de trabalho etc a serem gerenciadas Instanciar e configurar componentes do tipo GrupoInfoGerencia para descrever os grupos de informa o de ger ncia InfoGerencia a serem fornecidos por cada Element oGerenciado Instanciar e configurar componentes do tipo Monitor para controlar com que frequ ncia cada ElementoGerenciado deve fornecer informa o de ger ncia GrupoInfoGerencia Instanciar um componente do tipo ReceptorDeTraps para receber os traps gerados na rede Instanciar e configurar geradores de eventos do tipo GeradorDeEventoFalha Limiar e GeradorDeEventoFalhaTrap para determinar quais tipos de falhas devem ser identificadas pelo framework Neste caso os componentes instanciados consistem dos novos componentes constru dos pelo pr prio programador durante a etapa 1 descrita no in cio desta se o Instanciar e configurar geradores de eventos do tipo GeradorDeEventoFalha ComHisterese para identificar falhas com base no mecanismo de histerese prontamente dispon vel a partir da utiliza o deste componente
166. utilizar estas redes para diversas finalidades n o s estenderam a sua aplicabilidade como tamb m as tornaram mais complexas Ao mesmo tempo passou se a exigir um n vel de qualidade cada vez melhor para o servi o fornecido Ezhilchelvan 1991 Sistemas grandes complexos e heterog neos e que lidam com grandes volumes de informa o precisam ser supervisionados e controlados a fim de que as necessidades dos usu rios possam ser atendidas a contento Num momento em que as redes se tornam cada vez mais importantes para as empresas deixando de ser infra estrutura de comunica o dispens vel para se tornarem ferramentas cruciais ao desenvolvimento empresarial necess rio fazer com que a rede opere eficientemente livre de falhas e com isso garantir que as necessidades dos seus usu rios sejam adequadamente supridas Sendo assim importante automatizar e melhorar cada vez mais o processo de ger ncia de redes de computadores a fim de manter a rede funcionando bem e de acordo com as suas especifica es durante a maior parte do tempo Com efeito h muito que as tradicionais t cnicas de gerenciamento ad hoc tais como ping teste de conectividade entre dois dispositivos e traceroute an lise da rota estabelecida entre dois dispositivos n o s o escal veis e o fato que um verdadeiro arsenal de ferramentas e mecanismos de ger ncia tem sido desenvolvido para realizar tarefas em cada uma das cinco reas funcionais da g
167. utura de Descri o Dados OvsnmpSession Obtida atrav s de uma chamada a OvsnmpOpen esta estrutura identifica uma sess o SNMP particular Usada como um par metro para muitas outras fun es Criada por OvsnmpOpen e liberada pela fun o OvsnmpF ree OvsnmpPdu Cont m uma mensagem SNMP Inclui informa o sobre o tipo de mensagem get getNext getBulk set trap ou inform assim como sobre os dados nela contidos Criada por OvsnmpCreatePdu e liberada por OvsnmpF reePdu OvsnmpVarBind Elementos de uma lista de vari veis Cada elemento da lista cont m o identificador de uma vari vel MIB e o seu valor Faz parte da estrutura OvsnmpPdu Criada por OvsnmpAddVarBind e liberada por OvsnmpFreePdu Tabela 3 1 Estruturas de dados b sicas da API OVSNMP Com base nisto poss vel ter o trecho de c digo apresentado na figura 3 5 todos os exemplos fornecidos est o escritos em C Uma sess o SNMP estabelecida com o agente identificado pelo nome anjinho dsc ufpb br e uma mensagem pdu criada com uma lista de vari veis vazia Abre sess o SNMP com o agente anjinho dsc ufpb br sessao OvsnmpOpen anjinho dsc ufpb br Cria a mensagem SNMP a ser enviada pdu OvsnmpCreatePdu Adiciona uma lista de vari veis vazia ao pdu OvsnmpAddNullVarBind Figura 3 5 Abertura de uma sess o e prepara o de uma mensagem SNMP Requisi es podem ser feitas no modo
168. ve fornecer a informa o e mecanismos necess rios para que tickets possam ser automaticamente abertos Deve ser poss vel reaplicar uma determinada configura o do ambiente gerenciado sempre que necess rio Para que a ger ncia de falhas possa ser realizada necess rio antes de tudo descrever o ambiente gerenciado Em outras palavras necess rio definir quais 41 agentes da rede devem ser gerenciados e qual informa o de ger ncia deve ser observada em cada agente Muitas vezes a mesma configura o se repete em aplica es distintas por exemplo v rias aplica es poderiam estar interessadas em monitorar um roteador com uma quantidade x de interfaces sendo necess rio obter a taxa de tr fego que passa atrav s de cada uma delas para identificar problemas de congestionamento A solu o deve fornecer portanto mecanismos que permitam reaplicar uma determinada configura o sempre que necess rio F10 N o necess rio permitir a modifica o das vari veis de ger ncia mantidas pelos agentes da rede No protocolo SNMP o comando set permite modificar o valor de algumas vari veis MIB Entretanto al m de causar potenciais problemas de seguran a em seu projeto inicial o SNMP n o se preocupou devidamente com seguran a aceit vel dispensar a sua utiliza o para o prop sito da ger ncia de falhas Das 190 vari veis presentes na MIB II padr o apenas 30 podem ser modificadas
169. ventos gerados pelo Monitor cont m a informa o de ger ncia buscada nos elementos gerenciados da rede de acordo com o per odo de monitora o determinado Os eventos gerados pelo ReceptorDeTrapsSnmp cont m os traps gerados na rede de forma ass ncrona Os eventos gerados s o utilizados para identifica o de falhas como ser mostrado a seguir 57 4 3 3 Identificando Falhas na Rede Uma vez que o Monitor e o ReceptorDeTrapsSnmp tenham colhido a informa o de ger ncia de interesse presente nas entidades gerenciadas da rede a aplica o pode finalmente come ar sua tarefa de ger ncia de falhas propriamente dita ou seja ela passa a analisar a informa o colhida a fim de identificar a ocorr ncia de falhas na rede Isto pode ser feito atrav s de dois componentes GeradorDeEventoFalhaLimiar e GeradorDe EventoFalhaTrap O GeradorDeEventoFalhaLimiar gera eventos para indicar a ocorr ncia de falhas ao comparar a informa o colhida pelo Monitor com limiares pr configurados O GeradorDeEventoFalhaTrap gera eventos ao avaliar o tipo dos traps recebidos do ReceptorDeTrapsSnmp Ent o Monitor e ReceptorDeTrapsSnmp repassam a informa o colhida na rede para o GeradorDeEventoFalhaLimiar e o GeradorDe EventoFalhaTrap respectivamente e estes dois ltimos geram os eventos Evento FalhaEvent que descrevem as falhas ocorridas na rede ao analisar a informa o recebida A figura 4 12 de
170. vide ap ndice B permitem que isto seja feito Entretanto um editor mais apropriado e especialmente projetado para os componentes especificados deve ser utilizado Primeiramente o editor deve fornecer um editor especial para propriedades do tipo Map Map uma interface do JDK Java Development Kit 1 2 que mapeia chaves nomes por exemplo para valores TreeMap e HashMap s o exemplos de implementa es desta interface Isto se faz necess rio j que componentes do tipo GrupoInfoGerencia devem 103 ser implementados internamente atrav s de estruturas deste tipo vide http www dsc ufpb br raissa doc frame html e sendo assim tal editor indispens vel para que se possa adicionar unidades de informa o de ger ncia InfoGerencia a um grupo de informa o qualquer Ferramentas como o BeanBox fornecem apenas editores para propriedades com tipos nativos da linguagem suportada Depois o editor gr fico deve fornecer editores especiais para simplificar a interconex o dos componentes Tais editores devem conhecer a sem ntica dos componentes a serem interconectados para que as associa es feitas pelo programador possam ser entendidas e validadas Por exemplo necess rio fornecer um editor que permita associar a inst ncia de um ElementoGerenciado a uma inst ncia de um Monitor de modo que o Monitor passe a controlar a freqii ncia com que o ElementoGerenciado deve fornecer determinada informa o de ger
171. volver componentes de acordo com as caracter sticas de determinado tipo de 123 linguagem de programa o Ferramentas gr ficas ajudam o programador a compor aplica es ao permitir a configura o e conex o dos componentes necess rios aplica o de forma visual Neste ap ndice s o destacadas algumas defini es e as caracter sticas gen ricas de um componente de software Em particular apresentado como a linguagem Java pode ser utilizada para desenvolver componentes B 1 Caracter sticas Gerais H muitas defini es para um componente Segundo D Souza amp Wills 1999 um componente um pacote coeso de artefatos de software e uma unidade de entrega delivery unit que pode ser desenvolvido de forma independente e que pode ser conectado a outros componentes para construir algo maior De acordo com esta defini o s o exemplos de componentes usar um framework de aloca o de recursos para modelar problemas que variam da aloca o de salas para semin rios at o escalonamento de tempo de m quina para a produ o de lotes de pe as numa f brica usar constru es pr definidas de uma linguagem de programa o numa infinidade de contextos TORGA tog take A mene usar um framework de classes e interfaces para construir componentes que ser o utilizados para construir diversas aplica es de ger ncia de falhas Um componente cont m c digo execut vel c digo fonte es

Especificação de um Framework baseado em Componentes de

Contents

Download Pdf Manuals

Related Search

Related Contents

Especifica&ccedil;&atilde;o de um Framework baseado em Componentes de

Contents

Download Pdf Manuals

Related Search

Related Contents

Especificação de um Framework baseado em Componentes de