Uma Arquitetura de Gerenciamento de Desempenho Pr-ativo Distribudo Usando Tecnologia Ativa

Edmundo Lopes Cecilio

Dissertao de Mestrado Luci Pirmez, D.Sc., COPPE/UFRJ, Brasil, 1996 Luiz Fernando Rust da Costa Carmo, Dr. UPS, Frana, 1995

Instituto de Matemtica / Ncleo de Computao Eletrnica Universidade Federal do Rio de Janeiro Rio de Janeiro, Dezembro de 2002

ii

Uma Arquitetura de Gerenciamento de Desempenho Pr-ativo Distribudo Usando Tecnologia Ativa

Edmundo Lopes Cecilio

Dissertao submetida ao corpo docente do Ncleo de Computao e Eletrnica / Instituto de Matemtica da Universidade Federal do Rio de Janeiro UFRJ, como parte dos requisitos necessrios obteno do grau de Mestre em Cincias em Informtica.

Aprovada por:

________________________________________________ Profa. Luci Pirmez - Orientadora D. Sc., COPPE/UFRJ ________________________________________________ Prof. Luiz Fernando Rust da Costa Carmo - Orientador Dr., UPS, France ________________________________________________ Membro da banca

________________________________________________ Membro da banca

iii Rio de Janeiro RJ Dezembro de 2002

FICHA CATALOGRFICA

CECILIO, EDMUNDO LOPES. Uma Arquitetura de Gerenciamento de Desempenho Pr-ativo Distribudo Usando Tecnologia Ativa, [Rio de Janeiro], 2002. xii, 93 p., 29,7 cm (IM/NCE/UFRJ, MSc., Informtica, 2002) Dissertao (Mestrado) - Universidade Federal do Rio de Janeiro, IM/NCE 1. Gerenciamento pr-ativo 2. Gerncia de Redes 3. Gerenciamento Distribudo 4. Tecnologia Ativa I. IM/NCE/UFRJ II. Ttulo ( srie )

iv

A Joo Alberto Neves e Ana Maria Moura, que motivaram e viabilizaram o meu retorno ao Mestrado Aos meus amigos da PUC, Srgio, Luiz Fernando, Guido, Rogrio, Dbora, Rodrigo, entre outros, por terem me iniciado neste caminho e por terem me dado a oportunidade de trilhar nele nos ltimos cinco anos Aos professores do Departamento de Engenharia de Sistemas do Instituto Militar de Engenharia que demonstraram ter infinita pacincia com as ausncias do seu coordenador de graduao A todos os meus alunos que, por vezes, deixaram de ter o algo mais que sempre me caracterizou e que eles merecem Aos meu amigos Ana Paula, Reinaldo, Renata, Flvia, Werner, Coelho, Alexandre, Noel, Roberta, Leonardo, que sempre estiveram disposio em qualquer momento Aos meus familiares, que toleraram pacificamente e com compreenso os meus afastamentos das funes de pai, marido e filho Aos meus orientadores, Luci e Rust, que, sempre que foi preciso, tiveram pacincia, mostraram o caminho para a realizao desta dissertao e disponibilizaram os meios necessrios

Resumo

CECILIO, Edmundo Lopes. Uma Arquitetura de Gerenciamento de Desempenho Pr-ativo Distribudo Usando Tecnologia Ativa. Orientadores: Luci Pirmez e Luiz Fernando Rust da Costa Carmo. Rio de Janeiro. UFRJ/IM/NCE, 2002. Diss.

A garantia de nveis de qualidade de servio especficos depende fundamentalmente da presena de um mecanismo de gerenciamento preciso, eficiente e rpido, no s dos recursos da rede como tambm dos servios de comunicao (fim a fim), das estaes e das aplicaes. Esse mecanismo deve ser de fcil atualizao e flexvel o suficiente para a implantao de novas funcionalidades com a devida rapidez alm de, preferencialmente, ser independente de plataforma. Outra caracterstica desejvel que seja pr-ativo, de forma a permitir que sejam executadas aes com o objetivo de se tentar reverter quedas nos nveis de QoS ou, caso isso seja impossvel, minimizar os prejuzos para os usurios. O gerenciamento de desempenho, em particular, de vital importncia, pois quem deve monitorar a situao da rede no que diz respeito ao desempenho dos servios que esto sendo prestados e indicar quando e porque os nveis desejados de QoS no esto sendo alcanados. A tecnologia ativa redes ativas e agentes mveis vem sendo considerada em recentes pesquisas para o provimento da flexibilidade e distribuio necessrias a prxima gerao de futuros sistemas de gerenciamento. Esta dissertao apresenta uma proposta de arquitetura de gerenciamento de desempenho que, alm de usar tecnologia ativa, prativa. O trabalho proposto baseado na arquitetura de gerenciamento distribuda ativa AGAD, que foi desenvolvida no NCE/UFRJ. O prottipo que foi implementado tinha como objetivo investigar a viabilidade de se implementar um sistema de gerenciamento de desempenho pr-ativo em tempo real usando um paradigma de mobilidade de cdigo baseado em Java, o Code. Foram realizados trs tipos de testes com o prottipo que disponibilizaram dados referentes ao desempenho do seu funcionamento. Esses dados permitiram que fossem feitas anlises das vantagens e desvantagens da arquitetura que proposta nesta dissertao.

vi

Abstract

CECILIO, Edmundo Lopes. A Pro-Active and Distribbuted Performance Management Architecture Using Active Technology. Advisors: Luci Pirmez and Luiz Fernando Rust da Costa Carmo. Rio de Janeiro. UFRJ/IM/NCE, 2002. Diss.

Only a precise, efficient and rapid management mechanism will be able to guarantee the specific quality of service levels overseeing a network's resources, workstations and applications as well as its (end-to-end) communications services. This mechanism must have the capacity to be easily updated and yet be flexible enough to promptly assimilate the introduction of new functionalities, besides being, yet, platform independent. Another desirable characteristic is to be proactive, to allow actions to be executed to try to reverse QoS falling or, if this turn to be impossible, to minimize user perception of the QoS failure. Performance Management is of vital importance as it is responsible for both monitoring network status as regards services being offered and indicating when and why desired QoS levels have not been achieved. Recent research has shown that Active Technology active networks and mobile agents offers the flexibility and distribution assets required for management systems of the future. This work proposes an architecture of Performance Management that, in addition to utilizing active technology, is also proactive. This proposal is based on an Active, Distributed Management Architecture (AGAD) developed at the Ncleo de Computao Eletrnica (NCE) of the Federal University of Rio de Janeiro (UFRJ). The goal of the prototype was to investigate the viability of implementing a real time pro-active performance system running on a Java-based mobile agent paradigm Code. Three kinds of tests were executed and data were collected about the performance of the prototype. These data allowed the advantages and disadvantages of the proposed architecture to be analyzed.

vii

Lista de Siglas e Abreviaturas

AGAD ANEP ANTS ATM BCD BCN BGC BICD BIG BIT BTpG CANES CMIP CORBA DAN DARPA DCOM GD GDD GDPA GM ID MIB MPEG MPLS NCE NMF NMS OSI OSPF QoP RIP RMI RMON RPC RSVP RTCP RTP SLA SNMP Arquitetura de Gerenciamento Ativa e Distribuda Active Network Protocol Active Node Transfer System Asynchronous Transfer Mode Base de Cdigos Base de Conhecimento Base Geral de Cdigos Base de Informaes de Componentes de Domnio Base de Informaes Gerenciais Base de Informaes Temporrias Base de Topologia Geral Composable Active Networks Elements Common Management Information Protocol Common Object Request Broker Architecure Distributes code caching for Active Networks Defense Advanced Research Projects Agency Distibuted Component Object Mode Gerente de Domnio Gerente de Desempenho de Domnio Gerenciamento de Desempenho Pr-ativo Gerente Mor Inspetor de Desempenho Management Information Base Motion Picture Expert Group Multiprotocol Label Switching Ncleo de COmputao e Eletrnica Network Management Frum Network Management System Open Systems Interconnection Open Shortest Path First Quality of Presentation Routing Information Protocol Remote Method Invocation Remote Monitoring Remote Procedure Call Reservation Protocol Real Time Control Protocol Real Time Protocol Service Layer Agreement Simple Network Management Protocol

viii

Lista de Figuras
Figura 1 - Gerenciamento pr-ativo x gerenciamento reativo ---------------------------------------------10 Figura 2 - Arquitetura de um n de comutao ativo --------------------------------------------------------11 Figura 3 - O Sistema de gerenciamento de desempenho ----------------------------------------------------19 Figura 4 - Viso geral da AGAD ----------------------------------------------------------------------------------21 Figura 5 - Implementao do Inspetor ---------------------------------------------------------------------------23 Figura 6 - Elementos cujo desempenho gerenciado--------------------------------------------------------25 Figura 7 - Exemplo de parmetro monitorado -----------------------------------------------------------------28 Figura 8 - 50 observaes para teste -----------------------------------------------------------------------------29 Figura 9 - Componentes de gerenciamento de desempenho dos Gerentes -----------------------------33 Figura 10 - Inspetor de Desempenho e Especialista de Desempenho -----------------------------------33 Figura 11 - Ciclo de vida do Gerente de Desempenho Mor------------------------------------------------34 Figura 12 - Ciclo de vida do Gerente de Desempenho de Domnio --------------------------------------38 Figura 14 - Formato das mensagens do protocolo de comunicao da AGAD -----------------------41 Figura 15 - Camadas de processamento existentes na arquitetura sendo proposta -------------------42 Figura 16 - Rede IP com comutao de rtulos em nvel de enlace -------------------------------------44 Figura 17 - Modelo conceitual do prottipo --------------------------------------------------------------------54 Figura 18 - Diagrama de Seqncia Iniciar monitoramento de parmetro de controle -------------55 Figura 19 - Diagrama de Seqncia de Monitorao e de ao com o uso de Especialista --------56 Figura 20 - Diagrama de Classes do prottipo-----------------------------------------------------------------57 Figura 21 - Diagrama da classe do Inspetor de Desempenho ----------------------------------------------59 Figura 22 - Pseudo-cdigo de um Inspetor de Desempenho -----------------------------------------------60 Figura 23 - Esquema simplificado da interao Insp. de Desempenho Ger. de Desempenho --66 Figura 24 - Topologia da rede utilizada para obteno do comportamento da variao do retardo
-----------------------------------------------------------------------------------------------------------------------70

Figura 25 Amostra da variao do retardo que foi utilizada no teste----------------------------------71 Figura 26 Alarmes gerados na amostra de variao de retardo -----------------------------------------73 Figura 27 - Etapas entre a deciso de envio de Alarme de Tendncia e incio de execuo do Especialista -------------------------------------------------------------------------------------------------------75 Figura 28 - Etapas entre a deciso de envio de Alarme e incio da ao por uma aplicao ------77 Figura 29 - Primeira seqncia de amostras selecionadas para anlise ---------------------------------80 Figura 30 Segunda seqncia de amostras selecionadas para anlise ---------------------------------80

ix

Lista de Tabelas
Tabela 1 - Plataformas de hardware utilizadas nos testes isolados ................................................ 63 Tabela 2 Execuo completa de um lao de monitorao com envio de alarme ....................... 65 Tabela 3 - Resultados do teste com reinicializao e Especialista de 1 KB .................................. 67 Tabela 4 - Resultados do teste sem reinicializao do sistema e Especialista de 1 KB ............... 68 Tabela 5 - Resultados do teste com reinicializao do sistema e Especialista de 10 KB ............. 69 Tabela 6 - Resultados da interao entre Insp. de Desempenho e o Ger. de Desempenho .......... 75 Tabela 7 Detalhamento das etapas apresentadas na Figura 27 .................................................... 76 Tabela 8 - Estatsticas consideradas relevantes no terceiro teste ................................................... 81

Sumrio
Lista de Siglas e Abreviaturas --------------------------------------------------------------------------------------vii Lista de Figuras -------------------------------------------------------------------------------------------------------viii Lista de Tabelas -------------------------------------------------------------------------------------------------------- ix Sumrio --------------------------------------------------------------------------------------------------------------- x

Captulo 1 - Introduo ----------------------------------------------------------------------------------------------- 1 1.1. Gerenciamento de desempenho pr-ativo e tecnologia ativa -------------------------------------------- 2 1.2. Objetivos e organizao da dissertao--------------------------------------------------------------------- 3 1.3. Organizao da dissertao ----------------------------------------------------------------------------------- 3 Captulo 2 - Conceitos bsicos --------------------------------------------------------------------------------------- 5 2.1. Gerenciamento de redes centralizado versus distribudo------------------------------------------------- 5 2.2. Gerenciamento de desempenho ------------------------------------------------------------------------------ 7 2.3. Gerenciamento pr-ativo-------------------------------------------------------------------------------------- 9 2.4. Tecnologia ativa -----------------------------------------------------------------------------------------------10 2.4.1. Redes ativas -----------------------------------------------------------------------------------------------11 2.4.2. Redes programveis -------------------------------------------------------------------------------------12 2.4.3. Agentes mveis -------------------------------------------------------------------------------------------13 2.4.4. Agentes mveis versus Redes ativas-------------------------------------------------------------------15 2.5. Tecnologia ativa no gerenciamento de redes--------------------------------------------------------------16 2.5.1. Gerenciamento distribudo com tecnologia ativa ---------------------------------------------------16 2.5.2. Gerenciamento de desempenho com tecnologia ativa----------------------------------------------17 2.6. Resumo do captulo -------------------------------------------------------------------------------------------18 Captulo 3 - Gerenciamento de desempenho pr-ativo -------------------------------------------------------19 3.1. Arquitetura AGAD--------------------------------------------------------------------------------------------21 3.1.1. Gerente Mor-----------------------------------------------------------------------------------------------22 3.1.2. Gerente de Domnio -------------------------------------------------------------------------------------22 3.1.3. Inspetor ----------------------------------------------------------------------------------------------------23 3.1.4. Especialista -----------------------------------------------------------------------------------------------24 3.1.5. Guardio---------------------------------------------------------------------------------------------------24 3.1.6. Comunicao entre os elementos da AGAD ---------------------------------------------------------24 3.2. Arquitetura de gerenciamento de desempenho pr-ativa -----------------------------------------------25 3.2.1. Monitorao ----------------------------------------------------------------------------------------------27 3.2.2. Comunicao ---------------------------------------------------------------------------------------------31

xi
3.2.3. Aes -------------------------------------------------------------------------------------------------------31 3.2.4. Relatrios--------------------------------------------------------------------------------------------------32 3.3. Elementos integrantes da arquitetura-----------------------------------------------------------------------32 3.3.1. Gerente de Desempenho Mor --------------------------------------------------------------------------34 3.3.2. Gerente de Desempenho de Domnio -----------------------------------------------------------------35 3.3.3. Inspetor de Desempenho --------------------------------------------------------------------------------38 3.3.4. Especialista de Desempenho ---------------------------------------------------------------------------40 3.3.5. Protocolo de comunicao para o gerenciamento de desempenho ------------------------------40 3.3.6. O desempenho do gerenciamento de desempenho pr-ativo --------------------------------------41 3.4. Aplicaes do gerenciamento de desempenho pr-ativo------------------------------------------------42 3.4.1. Adaptao em aplicaes -------------------------------------------------------------------------------42 3.4.2. Mudana de rotas em servios de comunicao ----------------------------------------------------43 3.4.3. Utilizao de recursos em estao de trabalho -----------------------------------------------------44 3.4.4. Alterao de poltica de escalonamento de pacotes em ns de comutao ---------------------45 3.4.5. Alterao de protocolos em enlaces de comunicaes ---------------------------------------------45 3.5. Trabalhos relacionados ---------------------------------------------------------------------------------------46 3.6. Resumo do captulo -------------------------------------------------------------------------------------------47 Captulo 4 - Ambiente e implementao -------------------------------------------------------------------------49 4.1. Ambiente de desenvolvimento ------------------------------------------------------------------------------49 4.1.1. Infra-estrutura de mobilidade--------------------------------------------------------------------------49 4.1.2. Interface de programao de aplicaes de Gerenciamento--------------------------------------50 4.2. Implementao realizada-------------------------------------------------------------------------------------51 4.2.1. Casos de Uso do prottipo------------------------------------------------------------------------------51 4.2.2. Modelo Conceitual do prottipo -----------------------------------------------------------------------54 4.2.3. Diagramas de Seqncia do prottipo----------------------------------------------------------------54 4.2.4. Hierarquia de Classes do prottipo -------------------------------------------------------------------56 4.2.5. Implementao do Inspetor de Desempenho---------------------------------------------------------58 4.2.6. Consideraes sobre a implementao ---------------------------------------------------------------60 4.3. Resumo do captulo -------------------------------------------------------------------------------------------61 Captulo 5 - Testes e anlise dos resultados obtidos -----------------------------------------------------------62 5.1. Metodologia de testes-----------------------------------------------------------------------------------------62 5.2. Testes realizados e resultados obtidos ---------------------------------------------------------------------62 5.2.1. Testes do Inspetor de Desempenho isolado ----------------------------------------------------------62 5.2.2. Testes de desencadeamento de ao via Especialista ----------------------------------------------65 5.2.3. Monitoramento do parmetro de controle retardo -------------------------------------------------69

xii
5.3. Anlise dos resultados ----------------------------------------------------------------------------------------74 5.3.1. Inspetor de Desempenho isolado ----------------------------------------------------------------------74 5.3.2. Interao entre Inspetor de Desempenho e Gerente de Desempenho de Domnio ------------75 5.3.3. Execuo do Inspetor de Desempenho em massa de dados real ---------------------------------78 5.3.4. Consideraes sobre os resultados--------------------------------------------------------------------82 5.4. Resumo do captulo -------------------------------------------------------------------------------------------83 Captulo 6 - Concluses e trabalhos futuros --------------------------------------------------------------------84 6.1. Consideraes sobre a arquitetura proposta---------------------------------------------------------------84 6.2. Trabalhos futuros----------------------------------------------------------------------------------------------86 6.3. Consideraes finais ------------------------------------------------------------------------------------------87 Referncias --------------------------------------------------------------------------------------------------------------88

Captulo 1 - Introduo
A abrangncia da Internet ou, de forma mais genrica, das redes baseadas na arquitetura TCP/IP, aumentou significativamente. Essas redes devero, em breve, assumir o papel de principal infraestrutura de comunicao, que ainda da rede telefnica convencional. A tecnologia utilizada na implementao dessas redes - hardware e protocolos tero, no entanto, que evoluir, uma vez que essas redes, no futuro, devero oferecer suporte a complexos servios com requisitos de qualidade de servio (QoS Quality of Service1) diferentes e especficos para cada tipo de aplicao. O desempenho das redes baseadas em TCP/IP, em sua configurao atual, , em geral, aqum do desejado, em funo do servio prestado ser apenas de melhor esforo. No h priorizaes no encaminhamento de pacotes e nem h um mecanismo de controle de admisso de fluxos, alm de haver redundncias em algumas camadas de protocolo ao longo da rede, entre outros fatores. O desempenho diretamente dependente da presena de um sistema de gerenciamento, que o responsvel pela monitorao do estado da rede e pela comunicao de anormalidades. Ainda que existentes e variados, os mecanismos de gerenciamento de desempenho que esto em uso atualmente, caracterizam-se por uma excessiva centralizao no processamento, com grande troca de dados via rede, alm de serem meramente reativos, ou seja, emitem notificaes somente aps a ocorrncia de falhas. Alm do gerenciamento de desempenho insatisfatrio, o que se tem, no somente na Internet, mas nas redes de comunicao atuais em geral, a dificuldade na instalao de novos padres, de novas tecnologias e de novos servios. O ciclo de vida para a produo e implementao de novas funcionalidades muito longo, podendo se estender por mais de uma dcada. A implementao das funcionalidades necessrias s novas redes vai requerer uma infra-estrutura mais flexvel com a finalidade de se reduzir o prazo desse longo ciclo de vida. A seguir, ser apresentada uma viso geral de um mecanismo de gerenciamento de desempenho que vem ao encontro dessas necessidades que foram citadas nos pargrafos anteriores. Em seguida, sero apresentados os objetivos e a organizao dessa dissertao.

O termo QoS denomina o efeito coletivo provocado pelo conjunto das caractersticas quantitativas e qualitativas

de um servio oferecido por um sistema que necessrio para alcanar a funcionalidade requisitada pelas aplicaes [16].

2 1.1. Gerenciamento de desempenho pr-ativo e tecnologia ativa A garantia de nveis de servio especficos depende fundamentalmente da presena de um mecanismo de gerenciamento preciso, eficiente e rpido. O gerenciamento de desempenho, em particular, de vital importncia, pois ele quem deve monitorar a situao da rede no que diz respeito ao desempenho dos servios que esto sendo prestados e indicar quando e porque os nveis desejados de qualidade no esto sendo alcanados. desejvel ainda que o gerenciamento, particularmente de desempenho, seja pr-ativo, de forma que aes sejam desencadeadas antecipadamente, com o objetivo de se tentar evitar ou, pelo menos, minimizar as conseqncias das falhas ou degradaes que venham a ocorrer nos servios que esto sendo prestados aos usurios. O gerenciamento no deve se limitar apenas rede. As prprias estaes e as aplicaes que esto nas extremidades de um servio de comunicaes, devem ser gerenciadas. Um desempenho deficiente nessas estaes pode ser responsvel pela degradao da QoS. O mesmo pode ser dito em relao aos servios (fim a fim) prestados pelas redes e s aplicaes. O gerenciamento deve estender-se tambm a eles. O cenrio de uma aplicao multimdia distribuda pode ser utilizado como exemplo para a ilustrao do que esperado de um sistema de gerenciamento de desempenho pr-ativo que se estenda at alm dos domnios da rede. A adaptabilidade das aplicaes em relao QoS disponvel uma funcionalidade que vem sendo pesquisada como uma forma de se manter a qualidade de percepo (QoP2) do usurio na apresentao de um documento multimdia [27][28], ainda que os nveis de QoS venham a ser diminudos. A interao entre o sistema de gerenciamento de desempenho e este tipo de aplicao propicia a possibilidade de que as adaptaes sejam adiantadas, minimizando o tempo de interrupo da apresentao do documento multimdia para o usurio, no caso da ocorrncia de uma falha de QoS. Esse adiantamento da adaptao pode ser realizado tanto de forma reativa, ou seja, aps a ocorrncia de uma falha de QoS, quanto de forma pr-ativa. Nesse ltimo caso, o objetivo da adaptao seria reduzir as exigncias de QoS do servio de comunicaes quando da deteco por um sistema de gerenciamento de desempenho pr-ativo de uma tendncia de que venha a ocorrer uma degradao da QoS. Essas adaptaes de carter pr-ativo podem at mesmo evitar que a falha de QoS venha, de fato, a ocorrer.

A QoP corresponde a uma medida que engloba no apenas a satisfao do usurio com respeito a um servio pres-

tado por um sistema multimdia distribudo, mas tambm, potencialidade do usurio perceber, sintetizar e analisar os contedos informacionais de uma apresentao [26].

3 O mecanismo de gerenciamento de desempenho, a exemplo do que ocorre com as prprias redes, deve ser tambm de fcil atualizao e flexvel o suficiente para a implementao de novas funcionalidades com a devida rapidez. De preferncia, esse mecanismo deve ser tambm independente de plataforma. A tecnologia ativa, que compreende o uso das redes ativas e dos agentes mveis tem se mostrado como a tecnologia mais adequada ao provimento desta flexibilidade, uma vez que permitem o carregamento, remoto, de programas nos diversos elementos da rede e nas estaes. Alm da flexibilidade disponibilizada pelo uso dessa tecnologia, ela tambm viabiliza a presena de capacidades locais de processamento nos elementos gerenciados, fato que pode tornar mais dinmicas as aes oriundas no gerenciamento e reduzir o trfego na rede. 1.2. Objetivos e organizao da dissertao O objetivo dessa dissertao apresentar uma proposta de arquitetura de gerenciamento de desempenho pr-ativa e distribuda que se utilize da tecnologia ativa3. O gerenciamento de desempenho proposto no limitado apenas rede. Ele se estende no somente aos servios de comunicao que so prestados pela rede e mas tambm s aplicaes e s estaes. A arquitetura proposta baseada na Arquitetura de Gerenciamento Ativa Distribuda (AGAD) [19] que est em desenvolvimento no NCE da UFRJ. Foi implementado um prottipo da arquitetura que teve como objetivo a investigao da viabilidade, das vantagens e das desvantagens do gerenciamento pr-ativo distribudo baseado em tecnologia ativa, usando, em particular, no caso do prottipo, os agentes mveis. Os testes que foram realizados com o prottipo esto relacionados a uma aplicao multimdia distribuda que est em desenvolvimento no NCE, o ServiMdia [27][28]. 1.3. Organizao da dissertao Alm dessa introduo, a dissertao est organizada em mais cinco captulos. O captulo 2 descreve os conceitos bsicos sobre os quais a proposta de arquitetura est baseada, como gerenciamento centralizado x distribudo, gerenciamento de desempenho, redes ativas e agentes mveis e o uso de agentes mveis e redes ativas no gerenciamento distribudo. O captulo 3 apresenta a proposta de arquitetura de gerenciamento pr-ativo distribuda que o foco deste trabalho. So detalhados os elementos da arquitetura e o funcionamento da mesma explicado. So tambm descritos os possveis cenrios onde a utilizao de um sistema de gerenciamento de desempenho pr-ativo seria vantajosa. Os trabalhos relacionados so discutidos ao final deste captulo. O
3

Tecnologia ativa engloba, nesse trabalho, conforme ser explicado posteriormente, as tecnologias de redes ativas e

agentes mveis.

4 captulo seguinte descreve o ambiente de desenvolvimento que foi utilizado e apresenta, de forma detalhada, o prottipo que foi implementado. O captulo 5 apresenta os testes que foram realizados com o prottipo, os seus resultados, e uma anlise desses resultados, discorrendo sobre as vantagens e as desvantagens da arquitetura proposta que puderam ser deduzidos a partir desses resultados. O ltimo captulo apresenta as concluses da dissertao e sugere trabalhos futuros decorrentes do que foi proposto.

Captulo 2 - Conceitos bsicos

Nesse captulo sero apresentados os conceitos bsicos que so necessrios para o correto entendimento da arquitetura de gerenciamento de desempenho pr-ativo distribudo usando tecnologia ativa que est sendo proposta nesta dissertao. A primeira seo compara as abordagens de gerenciamento centralizado e distribudo, apresentando as vantagens do segundo sobre o primeiro. As principais formas de implementao do gerenciamento distribudo so resumidas. A seo 2.2 descreve, j inserida no contexto do gerenciamento distribudo, a rea funcional de gerenciamento de desempenho. A importncia do gerenciamento de desempenho para o transporte de trfegos multimdia destacada. Os requisitos, a abrangncia, os problemas e os parmetros a serem monitorados e controlados por um sistema de gerenciamento de desempenho so tambm descritos. O paradigma de gerenciamento prativo e as vantagens de sua utilizao so apresentados na seo 2.3. A seo seguinte, Tecnologia ativa, apresenta as caractersticas dos paradigmas de redes ativas e de agentes mveis. As vantagens e desvantagens dessas abordagens so tambm discutidas. A seo 2.5 trata da integrao de tecnologia ativa no gerenciamento distribudo de redes, em particular, no gerenciamento de desempenho. Por fim, na ltima seo, um resumo do captulo apresentado. 2.1. Gerenciamento de redes centralizado versus distribudo A abordagem clssica de gerenciamento centralizada que utilizada, por exemplo, nas implementaes iniciais das arquiteturas SNMP [51] e CMIP [37][4] baseada em um paradigma cliente-servidor, onde este ltimo, instalado em um elemento da rede, na forma de um agente, sofre pollings freqentes para que envie dados a uma estao de gerenciamento (a NMS Network Management Station), que nesse caso faz o papel de cliente. A NMS constri ento uma viso do estado da rede e gera Alarmes quando problemas so detectados. Normalmente, a interveno do operador ou administrador da rede requerida. A NMS pode tambm enviar comandos aos agentes para que estes desencadeiem aes visando resolver esses problemas. A funcionalidade dessas aes, no entanto, limitada ou demorada. Situaes de exceo podem ser configuradas nos agentes para que estes enviem, por iniciativa prpria, avisos NMS como, por exemplo, as traps. Essa abordagem gera um grande trfego na rede, que, na maioria das vezes, aps ser analisado, serve apenas para deduzir-se que a situao normal. Esse grande trfego no s pode prejudicar o desempenho da rede como tambm pode fazer com que o tempo decorrido entre a deteco de uma situao anormal e a interveno apropriada para resolv-la seja muito grande, podendo torn-la at mesmo intil. medida que o nmero de elementos gerenciados cresce, a comple-

6 xidade, os requisitos de poder de computao da estao de gerenciamento e de consumo de banda da rede gerenciada tambm aumentam. Ainda, em redes com grande abrangncia geogrfica, a NMS pode estar distante dos elementos gerenciados e, conseqentemente, os retardos na comunicao para o envio de dados e comandos podem ser excessivamente grandes. Abordagens alternativas distribudas para o gerenciamento vm sendo pesquisada nos ltimos anos. Desde o trabalho de Yemini [17], sobre gerenciamento distribudo por delegao, at o uso de agentes mveis [10], diversas so as opes sendo pesquisadas ou j em uso comercial para a implementao da distribuio no gerenciamento. As abordagens mais simplificadas dividem a rede em domnios hierrquicos de gerenciamento, cada qual com sua NMS. Atividades de monitoramento e certas capacitadas de filtragem so delegadas aos prprios elementos gerenciados, que enviam apenas Alarmes ou relatrios resumidos s NMS. Exemplos dessas abordagens so as funes de monitoramento de mtricas [29] e sumarizao [54] do modelo OSI de gerenciamento e RMON no modelo SNMP [51]. Essas abordagens, no entanto, apesar de reduzirem o trfego na rede e o tempo entre a deteco de uma anomalia e a emisso do correspondente alarme ou ao, no oferecem flexibilidades para atualizao ou troca de softwares de forma rpida. Opes mais avanadas de gerenciamento distribudo utilizam-se de paradigmas de objetos distribudos como CORBA [31]e Java-RMI [32] ou da chamada remota de procedimentos (RPC) [33]. O uso desse paradigma, embora vantajoso sob os pontos de vista de projeto e de reuso, abstrai-se dos detalhes de implementao. Exemplos como CORBA, DCOM e RMI so muito teis no projeto e construo de sistemas distribudos, mas escondem os verdadeiros custos de suas implementaes. O tamanho e a complexidade da infra-estrutura que tem que estar instalada na plataforma normalmente so grandes. Como resultado, o uso dos recursos da rede pode se dar de forma ineficiente, principalmente no que diz respeito ao consumo de capacidade de transmisso dos enlaces, dada a (possvel) grande quantidade de dados a ser trocada entre os objetos. Outra desvantagem dessas abordagens que no oferecem o suporte a ambientes verdadeiramente distribudos, onde agentes (softwares) podem se comunicar com vizinhos para se encarregarem, em conjunto, de executar tarefas de forma distribuda e eficiente. As pesquisas mais avanadas para a distribuio do gerenciamento usam o que chamado de tecnologia ativa [10]. Essa tecnologia integra as pesquisas atuais em redes ativas, redes programveis e em agentes mveis, que sero descritas na prxima seo. De forma resumida, pode-se dizer que programas podem ser instalados em ns de comutao da rede que oferecem suporte a execuo de programas ou em estaes. Esses programas so dotados de certa capacidade de

7 processamento, sendo capazes de agir localmente com o objetivo de resolver problemas ou consolidar informaes de gerenciamento. Dessa forma, alm de reduzirem o trfego na rede e a demora para o desencadeamento de aes de gerenciamento, a atualizao desses programas pode ser realizada de forma flexvel e rpida. Essa abordagem no deve ser confundida com aquelas que pregam a distribuio de objetos. Com o uso de tecnologia ativa, programas inteiros, autnomos, e no apenas procedimentos ou objetos so instalados nos elementos a serem gerenciados, alm de poderem migrar. 2.2. Gerenciamento de desempenho O conjunto de servios disponveis via Internet e ser cada vez mais variado. Durante muitos anos eles resumiam-se a aplicaes do tipo Telnet, FTP, Usenet e e-mail. Esse conjunto vem sendo aumentado com aplicaes como WWW, transaes financeiras, educao distncia, transmisso de fluxos de udio e vdeo via multicast isoladamente ou sincronizados, com interatividade em tempo real ou no, computao distribuda e acesso a bancos de dados distribudos. Estudos do desempenho4 da Internet em sua configurao atual mostram [3], no entanto, que h muitos usurios insatisfeitos. O servio de entrega de pacotes baseado apenas no melhor esforo faz com que ainda seja impossvel garantir os nveis desejveis de QoS [3]. A tecnologia da futura Internet ter que transportar trfegos que podero ser agrupados em diferentes classes de servio5. O trfego de cada classe ter suas caractersticas e seus requisitos de QoS especficos. A garantia de QoS est diretamente relacionada ao gerenciamento de desempenho, que uma das cinco reas funcionais de gerenciamento segundo classificao do Frum de Gerenciamento de redes (NMF Network Management Forum) [2]. O correto gerenciamento do desempenho viabiliza ao administrador ou operador da rede gerenci-la de forma a prover nveis diferenciados de QoS ou, pelo menos, descobrir que no est sendo possvel atingi-los. O gerenciamento de desempenho tambm trs vantagem financeira, uma vez que, quanto maior for a capacidade de medir, analisar e garantir certos nveis de QoS; acordos de nveis de servio (SLA Service Level Agreement) mais estritos podero ser negociados, gerando maior receita. O gerenciamento de desempenho visa atingir dois objetivos conflitantes, a garantia de QoS para os usurios (aplicaes) e a obteno de um alto grau de multiplexao no uso da rede [1]. Ele deve prover funes para medir, monitorar, avaliar e gerar informaes sobre os nveis de de-

Segundo Ferreira [15], desempenho o conjunto de caractersticas ou de possibilidades de atuao de um sistema. Classes de servio implicam que servios podem ser categorizados em classes separadas, que podem ser gerencia-

das individualmente .

8 sempenho alcanados pela rede. Essas informaes devem ser utilizadas principalmente com duas finalidades. A primeira a gerao de estatsticas peridicas que venham a ajudar no planejamento de capacidade da rede, enquanto que a segunda indicar a ocorrncia de desrespeitos aos nveis de QoS desejados. Nesse ltimo caso, controles dos recursos da rede e/ou das aplicaes devem ser acionados com o objetivo de melhorar a QoS que est sendo prestada aos usurios [2]. Exemplos desses controles podem ser alteraes de roteamento, realocao de buffers e a adaptao dos trfegos, entre outras. O provimento de servios com QoS consistente e confivel tem sido associado a mecanismos como escalonamento com reserva de certa capacidade de processamento, classificao de trfego em classes de servio e sinalizao para a reserva tanto de banda quanto de buffers, entre outros. No entanto, mais do que isso necessrio. Mecanismos de gerenciamento de desempenho que ajudem na seleo de rotas atravs da escolha de enlaces de acordo com as suas capacidades e da obteno de mtricas precisas de roteamento podem fazer mais pela obteno do desempenho esperado pelo usurio do que complexos mecanismos como Weighted Fair Queueing, RSVP e tarifao diferenciada. Mesmo que esses complexos mecanismos tornem-se disponveis em carter geral, ainda sero necessrias ferramentas para a administrao e gerenciamento do desempenho da rede atravs do ajuste de parmetros como agregao e pesos de cada classe de servio [3]. Isso requer um conhecimento praticamente instantneo da situao dos enlaces da rede. O gerenciamento de desempenho no deve se limitar apenas rede. Os sistemas de computao ligados a ela tambm devem ter seu desempenho gerenciado com a finalidade de se identificar degradaes que sejam neles originadas. Um servidor com pouca capacidade de processamentopara a tarefa que deve executar, por exemplo, pode impedir que certo nvel de QoS seja atingido. Os principais requisitos para a execuo do gerenciamento de desempenho propriamente dito so, ento, aumentar o mnimo possvel o trfego na rede e disponibilizar informaes sobre o desrespeito aos nveis de servio desejados o mais rapidamente possvel. As aplicaes de gerenciamento atuais concentram-se basicamente na divulgao do estado da rede em vez de localizar e desencadear aes para que problemas de desempenho sejam resolvidos. A prxima gerao de aplicaes de gerenciamento de desempenho dever tratar de aspectos como descobrimento automtico de topologia, monitorao (via coleta e anlise de dados), simulaes rpidas, planejamento de capacidade, configurao de roteadores e comutadores e a realizao de diagnstico de falhas [3].

9 Os desafios na implementao de gerenciamento de desempenho so integrao, escalabilidade e flexibilidade. A integrao possui trs componentes: a necessidade de se coletar dados de diferentes origens, analis-los e alimentar com os dados obtidos as aplicaes de gerenciamento do proprietrio da rede. necessrio trabalhar por toda a rede e em suas bordas em diferentes camadas de diferentes fornecedores e realizar a correlao das informaes colhidas. Na escalabilidade h duas dimenses a serem consideradas, o nmero de usurios e o tamanho (fsico) da rede. Quanto maiores forem, maior ser o trfego gerado pelo gerenciamento de desempenho e maiores sero os retardos. A flexibilidade significa que os elementos gerenciados e as aplicaes que tratam do gerenciamento devem ser configurveis e adaptveis para que possam prestar diferentes servios e atender a diferentes objetivos de desempenho. Pode-se dizer que o trabalho do gerenciamento de desempenho resume-se, ento, na monitorao e no controle, mediante aes, de parmetros de QoS. Estes so expressos em unidades diferentes nas diferentes camadas de processamento. Aplicaes tm parmetros em funo de seus objetivos, como por exemplo, um nmero de quadros de imagem por segundo, enquanto recursos ou elementos de rede definem parmetros de acordo com a sua natureza, como, por exemplo, para um enlace de comunicaes, uma taxa em bits por segundo. Chatterjee [12] prope uma taxonomia para os parmetros de QoS. 2.3. Gerenciamento pr-ativo A quase totalidade das abordagens de gerenciamento reativa, ou seja, trata da coleta de dados sobre o funcionamento da rede e dos servios e, no mximo, da indicao da ocorrncia de problemas. Tem sido pesquisada, ultimamente, a abordagem pr-ativa6 de gerenciamento [23][24]. O gerenciamento de redes pr-ativo tem por objetivo principal identificar problemas na rede antes que alguma degradao ou falha de QoS nos servios que esto sendo prestados venha a ocorrer. Algumas reas funcionais, como configurao e contabilizao, so inerentemente reativas. J as reas de gerenciamento de desempenho, de falhas e de segurana podem ser mais eficientes caso o gerenciamento seja realizado de forma pr-ativa. A Figura 1 apresenta uma viso esquemtica do relacionamento entre as reas funcionais, o estado da rede e o tipo de gerenciamento predominante para cada rea.

Pr: a favor. Ativo: que exerce ao, que age, funciona, trabalha, se move, est apto a agir, com rapidez,

prontido, atuante, enrgico.

10
Estado da rede: Tipo de Gerenciamento: reas funcionais de Gerenciamento: NORMAL PR-ATIVO Desempenho DEGRADADO REATIVO Configurao Contabilizao

Tempo

Falhas Segurana Ocorrncia de problema ou evento

Figura 1 - Gerenciamento pr-ativo x gerenciamento reativo

No gerenciamento pr-ativo, o comportamento da rede deve ser constantemente monitorado para que estatsticas sejam coletadas. Anlises dessas estatsticas permitem que sejam identificados sintomas indicadores de que um ou mais problemas podem vir a acontecer. Podem ser utilizadas, nessas anlises, simulaes rpidas, extrapolaes ou tcnicas de inteligncia artificial, com o objetivo de se precisar ou estimar o momento quando determinado problema ou evento vai ocorrer [24]. As operaes que tm que ser realizadas nessas anlises podem vir a consumir grande processamento. Esse tem sido o fator limitante do emprego de tcnicas pr-ativas no gerenciamento de redes. A distribuio do processamento de gerenciamento, juntamente com a flexibilidade oferecida pelo uso de tecnologia ativa, aliados ao aumento da capacidade de processamento disponvel no hardware podem viabilizar o gerenciamento pr-ativo. Uma possvel soluo a colocao de uma capacidade de processamento (destinada ao gerenciamento) limitada nos elementos a serem gerenciados e uma maior capacidade de processamento em estaes destinadas a esse fim, prximas queles elementos. 2.4. Tecnologia ativa A partir de 1995, aps as primeiras publicaes originadas em pesquisa financiada pela DARPA, a distribuio do controle e a programabilidade dos ns de uma rede passaram a ser investigadas com grande seriedade com o objetivo de se disponibilizar uma maior flexibilidade tanto no gerenciamento quanto na disponibilizao rpida de novos servios em redes de comunicao [18]. Trs so os paradigmas sendo considerados para a implementao dessa distribuio: redes ativas, redes programveis e agentes mveis. Os trs paradigmas oferecem o suporte a modelos que utilizam recursos computacionais no interior e/ou nas bordas da rede para a execuo de software sob demanda. Desta forma, novos tipos de aplicaes de controle e de gerenciamento podem ser implementadas. Esses paradigmas tm sido postos prova, na sua maioria, implementados via CORBA ou Java. Embora os conceitos desses trs paradigmas tenham sido originados em diferentes comunidades de pesquisas visando resolver diferentes problemas, eles co-

11 meam a se superpor em termos de foco e aplicabilidade, fato que est popularizando o termo tecnologia ativa para as referncias a um ou mais desses paradigmas em conjunto [10].
2.4.1. Redes ativas

Uma rede ativa uma rede onde os ns intermedirios (roteadores, comutadores, gateways, etc), que so chamados de ns ativos, em vez de realizarem apenas a entrega de dados, podem realizar computaes, normalmente, mas no apenas, em prol da entrega de dados. Os fluxos de dados podem ento transportar programas (cdigos) e dados. Nem todos os ns da rede precisam ser ativos. Quando esse for o caso, deve haver o tunelamento entre dois ns ativos adjacentes, a exemplo do que ocorre no MBone. Cada n ativo composto por um hardware, por um sistema operacional, por um ou mais ambientes de execuo e por aplicaes ativas, conforme pode ser observado na Figura 2.
Aplicaes ativas Ambientes de Execuo AE 1 AE 2 IPv4

Sistema Operacional Hardware

Figura 2 - Arquitetura de um n de comutao ativo

O sistema operacional o responsvel pela alocao e escalonamento dos recursos do n, como, por exemplo, ciclos de CPU e capacidades de memria e armazenamento. Os ambientes de execuo implementam mquinas virtuais que executam as aplicaes (ativas) que, por sua vez, tratam os fluxos de pacotes. A capacidade de processamento dos ambientes de execuo pode variar entre completamente genrica, ou seja, capaz de executar qualquer programa, at especializada em uma nica tarefa, como, por exemplo, encaminhar pacotes baseado em cabealhos do protocolo IPv4. Os usurios obtm servios fim a fim de uma rede ativa atravs de aplicaes ativas que so executadas nas mquinas virtuais (uma em cada n ativo da rota) providas pelos ambientes de execuo. Duas abordagens de implementao de redes ativas esto sendo pesquisadas: integrada e discreta. Na abordagem integrada, os cdigos que implementam as aplicaes ativas so encapsulados nos prprios pacotes do fluxo que devem ser por elas processados. Nesse caso, a aplicao ativa instalada imediatamente, na hora de sua utilizao. Os pacotes ativos referentes a essa abordagem so chamados de cpsulas. Exemplos de projetos que utilizam essa abordagem so IP Option, ANEP [35] e Smart Packets [13]. Na abordagem discreta, os programas no so integrados aos dados. Os pacotes ativos transportam apenas identificadores das aplicaes ativas (ou rotinas

12 das mesmas) que devem neles ser executadas. Nesse caso, as aplicaes ativas so instaladas por um esquema de transferncia de cdigo sob demanda a partir de servidores ou mesmo de outros ns ativos7. Essa abordagem, embora trate os ns da rede como comutadores programveis, no pode ser confundida com a tecnologia de redes programveis, onde a programao do n realizada via operaes de gerenciamento, por um administrador, conforme ser visto na prxima seo. Exemplos de projetos que se utilizam da abordagem discreta so ANTS, CANES e DAN [18]. Alguns projetos como SwitchWare e NetScript empregam uma combinao das duas abordagens [11]. O paradigma das redes ativas oferece grandes vantagens, como eficincia no uso da capacidade de transmisso da rede, rpida instalao de novos protocolos e a tambm rpida disponibilizao de flexibilidades como, por exemplo, a atualizao de um determinado processamento em um n de comutao. Assim, essas redes podem acompanhar a rpida evoluo das tecnologias de comunicao de dados mediante a introduo de novos servios sem que os longos processos de padronizao de protocolos e de formato de pacote e desenvolvimento de plataformas especficas (hardware e software) tenham que ser esperados. A tecnologia de redes ativas possui, em contrapartida, algumas desvantagens. A primeira delas a questo da segurana [11]. Esquemas de autenticao tm que ser implementados de forma a impedir que cdigos no autorizados sejam colocados em funcionamento em ns ativos. A proteo de um n ativo contra erros em tempo de execuo tambm um fator a ser considerado [11]. Dependendo das funcionalidades que forem disponibilizadas para as linguagens a serem utilizadas para a implementao dos cdigos, o correto funcionamento de um n ativo pode ser comprometido por problemas como entrada em lao infinito, bloqueio indevido de processo ou consumo excessivo de memria. Outra desvantagem significativa, que pode vir a ser minimizada com a constante evoluo da capacidade de processamento do hardware computacional, a queda no desempenho inerente ao uso de cdigos interpretados ou mesmo parcialmente interpretados. A exigncia de autenticaes para a execuo de cdigos tambm contribui para a queda no desempenho das aplicaes ativas de um n ativo.
2.4.2. Redes programveis

A tecnologia de redes programveis prev a disponibilizao de interfaces abertas de programao nos elementos da rede. Com o uso dessas interfaces, a rede pode ser considerada um grande

Normalmente, o cdigo obtido do n ativo anterior da rota do fluxo em questo.

13 computador, que pode ser programado para que novos servios, sinalizaes e controles sejam rapidamente implementados [39]. A programao que prevista nessa tecnologia no dinmica como aquela que est disponvel na tecnologia de redes ativas. Aqui a programao desencadeada atravs de operaes de gerenciamento, realizadas por um administrador ou operador, e no pelos prprios pacotes de um fluxo. Essa tecnologia, no que diz respeito ao gerenciamento, pode oferecer vantagens apenas para a atualizao de NMS ou de agentes de gerenciamento fixos. O dinamismo do gerenciamento, no sentido de que so necessrias capacidades diversas de processamento em momentos e locais diversos, requer mais do que apenas interfaces abertas de programao.
2.4.3. Agentes mveis

Tendncias atuais deixam claro que a complexidade do software continuar a crescer dramaticamente nas prximas dcadas. A natureza cada vez mais dinmica e distribuda das aplicaes e de seus dados requerem que os sistemas de aplicao no somente respondam s requisies por informaes mas que tambm, de forma inteligente, comuniquem-se, antecipem, adaptem e busquem formas de ajudar os usurios. Esses sistemas devem no s auxiliar a coordenao entre humanos, mas tambm devem cooperar entre si. Em resposta a esses requisitos, os esforos de pesquisadores de diversas reas, como inteligncia artificial, robtica e computao distribuda, entre outras, comeam a convergir para o desenvolvimento de agentes de software [7]. A abordagem para comunicao em ambientes de software mais utilizada na prtica ainda a chamada remota de procedimentos (RPC Remote Procedure Call), que foi concebida nos anos 70. Cada mensagem transferida pela rede inclui os argumentos para a execuo do procedimento ou resultados da execuo do mesmo. Nesse caso, os computadores que se comunicam combinam previamente quais so os procedimentos que podem ser chamados e quais so as mensagens que devem ser trocadas. Os procedimentos propriamente ditos so internos ao sistema onde executam e fixos. A interao via RPC requer comunicao constante entre cliente e servidor. A execuo do procedimento dita sncrona, pois s acontece por estmulo do software que o chamou remotamente. O trfego gerado grande e a atualizao dos procedimentos difcil, por estes serem fixos, requerendo novas instalaes manuais e troca de componentes. Alm de RPC, outras tecnologias para comunicao em ambientes de software, ainda que tambm baseadas no paradigma cliente-servidor, so CORBA e Java-RMI. Uma alternativa para a chamada remota de procedimentos a programao remota. Nesse caso, deve ser combinada previamente entre os sistemas de computao apenas a linguagem que ser

14 utilizada. Um agente de software ento enviado ao sistema que deve servir como servidor em algum processamento. Essa abordagem dispensa a interao constante entre cliente e servidor. Outra abordagem o uso de agentes. Um agente uma entidade computacional que age ou tem o poder e a autoridade de agir ou representar outra entidade. Em particular, espera-se que um agente de software execute uma tarefa especfica para a qual tenha sido designado. Para isso, ele atua de forma contnua e autnoma, tanto pr-ativa quanto reativa, tem capacidade de aprender e cooperar e dispensa constante interveno ou orientao, em um ambiente particular, possivelmente habitado por outros agentes e processos [5] [7]. A execuo do agente dita assncrona, uma vez que no depende exclusivamente de estmulos de outro software, como no caso da RPC. Uma grande vantagem quantitativa e ttica dessa abordagem o seu melhor desempenho, pois dados podem ser analisados e aes podem ser desencadeadas localmente. Quanto menor for a capacidade de transmisso de dados da rede e menor for a sua disponibilidade, maior ser a vantagem. Isto particularmente til quando da presena de redes de acesso com baixas taxas e/ou sem conexes permanentes. Outra grande vantagem, qualitativa e estratgica, a possibilidade de configurao e adaptao. A manuteno tambm facilitada, pois o agente pode ser sempre o mais atualizado possvel, uma vez que o mesmo enviado somente quando necessrio. Muito da pesquisa a respeito dos aspectos de inteligncia de agentes de software advm da inteligncia artificial (IA) distribuda. Esta uma extenso de idias derivadas da IA que se aplicam a sistemas multi-agentes. Em vez de uma nica muito grande e complexa aplicao que codifica toda a inteligncia de um sistema, um certo nmero de agentes so envolvidos em um esforo colaborativo para a resoluo de problemas. Isto no implica que o sistema grande seja meramente dividido em partes menores. Agentes que tratam de problemas especficos, interligados por um sistema de comunicao, podem trocar pontos de vista e colaborarem para a produo de estratgias para a resoluo de problemas. Esse paradigma chamado de resoluo distribuda de problemas. A abordagem baseada em agentes difere da abordagem cliente-servidor no sentido de que no h uma clara distino em quem o cliente e quem o servidor. Todos os agentes participam da computao de acordo com os papis para eles designados [5]. Agentes mveis so caracterizados pela sua habilidade de moverem-se entre diferentes localidades via redes locais (LAN) ou geograficamente distribudas (WAN). A tecnologia de agentes mveis oferece tambm o suporte ao encapsulamento de protocolos o que bom para a implementao de redes ativas.

15 Os agentes mveis viabilizam a transformao das redes atuais em plataformas programveis remotamente. As principais vantagens no uso de agentes mveis em comparao com a abordagem cliente-servidor podem assim ser resumidas: [5] eficincia, economia de espao, reduo do trfego, interao assncrona e em tempo real, robustez, operao em ambientes heterogneos, extensibilidade em tempo real e fcil atualizao. Para se fazer uso de agentes mveis, um sistema de comunicao, bem como os sistemas de computao, tm que incorporar um framework de mobilidade. Este vai prover as facilidades que vo oferecer o suporte aos modelos de ciclo de vida, computacional, de segurana, de comunicao e de navegao dos agentes [5]. Em contraste, a atualizao de um agente local um processo bem mais longo [5] do que o envio de dados coletados ou um resumo dos mesmos. H tambm que se considerar o impacto a ser causado no desempenho da rede pela transferncia dos prprios agentes mveis. O desempenho do gerenciamento de redes baseado em agentes mveis , de maneira geral, superior quele do SNMP, exceto em casos onde o nmero de elementos gerenciados pequeno ou quando o tamanho do agente, que relacionado a sua funcionalidade, for grande. Maiores detalhes sobre essa comparao podem ser obtidos em [34]. Adicionalmente, agentes no controlados podem inundar a rede e tomar parte significativa dos recursos. Sob o ponto de vista da segurana, nem todos, humanos ou aplicaes, devem ser capazes de poder injetar agentes na rede.
2.4.4. Agentes mveis versus Redes ativas

A tecnologia de redes ativas mais genrica do que a tecnologia de agentes mveis em termos de encapsulamento de protocolos, configurao e instalao de servios e manuteno. A fundamental diferena entre as duas tecnologias que redes ativas usam o conceito de processamento na camada de rede, ou seja, voltado para o encaminhamento de pacotes, enquanto agentes mveis executam como sistemas de aplicao. Sistemas baseados em agentes mveis so projetados para a construo de um ambiente de computao distribudo e interligado por um sistema de comunicao, enquanto o propsito das redes ativas disponibilizar e tornar mais eficientes facilidades no sistema de comunicao. No entanto, pode se considerar que os programas (cdigos) transportados em cpsulas das redes ativas so agentes mveis. Da mesma forma, um elemento de rede que seja capaz de executar um agente mvel pode ser considerado um n ativo [14]. Agentes mveis podem migrar baseados em decises autnomas, alm de poderem tambm gerar processos filhos ou threads para tratarem de problemas especficos. Essas funcionalidades

16 no esto previstas nas redes ativas. Por fim, agentes podem trocar mensagens entre si, algo tambm no previsto nas redes ativas [10]. No plano de gerenciamento, pode-se considerar que as funcionalidades a serem executadas esto, principalmente, no nvel das aplicaes, uma vez que o gerenciamento no tem como objetivo principal tratar diretamente da entrega de pacotes. Sendo assim, mais aconselhvel, no que diz respeito a frameworks8 de gerenciamento, empregar-se o termo tecnologia ativa, pois tanto redes ativas quanto agentes mveis podem ser utilizados. 2.5. Tecnologia ativa no gerenciamento de redes Nesta sub-seo sero integrados os conceitos bsicos apresentados no captulo com o objetivo de se formar a base conceitual sobre a qual a arquitetura proposta nesse trabalho construda.
2.5.1. Gerenciamento distribudo com tecnologia ativa

A implementao do gerenciamento distribudo com o uso de tecnologia ativa vem sendo muito pesquisada nos ltimos anos. Os elementos da rede que devem ser gerenciados, tanto ns de comutao quanto estaes, podem receber softwares9 para que tarefas especficas sejam executadas localmente. O simples polling via rede em busca apenas de dados pode ser praticamente abolido. Os elementos da rede e as estaes podem ser providos apenas de funcionalidades bsicas no que diz respeito obteno de informaes de gerenciamento. Capacidades genricas e especficas podem ser providas via softwares enviados a esses elementos. O comportamento desses softwares e o seu nvel de especializao podem ser modificados a qualquer momento. A flexibilidade das aplicaes de gerenciamento enorme nesse caso, uma vez que os elementos da rede podem ser configurados para atividades de gerenciamento de acordo com as necessidades do momento, sem as restries do longo processo de padronizao, desenvolvimento e implementao de novas funcionalidades que j foi citado. As atualizaes de regras para a tomada de decises, de limites para desencadeamento de aes ou de um protocolo de gerenciamento, por exemplo, poderiam ser feitas mediante simples atualizaes dos softwares em questo. O mesmo se aplica a mudanas de polticas e incluso de novos servios de gerenciamento. Alm da facilidade de atualizao de funcionalidades, esses softwares podem ser providos de capacidades avanadas no que diz respeito ao processamento das informaes de gerenciamen8

Frameworks so arquiteturas semi-prontas reutilizveis. No s os componentes de um sistema, mas tambm as

decises de projeto a ele associadas so reutilizados.

9

Esses softwares podem ser agentes mveis ou aplicaes ativas.

17 to. Os tempos de deteco de problemas e de restabelecimento do funcionamento normal do elemento gerenciado podem ento ser bastante reduzidos, uma vez que o software de gerenciamento est sendo executado localmente. Pela mesma razo, a utilizao da capacidade de transmisso dos enlaces da rede para fins de gerenciamento pode ser significativamente reduzida, pois o trfego de gerenciamento menor. Granularidades mais finas para monitorao e controle dos parmetros de QoS podem tambm ser utilizadas. Apenas um mnimo de informaes, como relatrios de ocorrncias e estatsticas, precisam ser enviadas para as NMS. Alm de agir diretamente no gerenciamento de elementos, softwares podem estar executando nos ns de comutao da rede tambm com a finalidade de filtrar e fundir as informaes destinadas s NMS, reduzindo ainda mais o trfego referente ao gerenciamento. A possibilidade de se enviar programas para serem executados automaticamente nos elementos gerenciados trs, associada a si, os riscos de tal funcionalidade ser utilizada de forma mal intencionada. imperativo, portanto, a presena de um mecanismo de segurana eficaz e eficiente. Os requisitos de um mecanismo desse tipo so discutidos por Reiser [38].
2.5.2. Gerenciamento de desempenho com tecnologia ativa

Certos aspectos na monitorao do desempenho de redes, servios e aplicaes, especialmente quando medidas de tempo esto envolvidas, so difceis de serem considerados na abordagem centralizada de gerenciamento. O retardo gerado pela transmisso dos dados pela rede torna a preciso de medidas questionvel [5]. O envio de um software com capacidade de processamento, como um agente mvel ou uma aplicao ativa, em vez do uso de polling via rede permite a anlise local do elemento a ser gerenciado. Dessa forma, no h retardos da rede envolvidos pelo menos na fase de monitoramento do desempenho. Softwares locais podem, por intermdio de clculos sobre valores armazenados temporariamente, calcular a tendncia de comportamento de certos parmetros. Notificaes so ento enviadas NMS quando limites dessa tendncia forem ultrapassados. O processamento realizado localmente por esses agentes ou aplicaes, no entanto, no pode ser excessivo em relao capacidade de processamento disponvel no elemento gerenciado em questo. O paradigma de mobilidade pode ser utilizado, por exemplo, para a busca da causa de uma queda de desempenho ao longo de uma rota. Um agente se desloca a partir de uma extremidade de um servio de comunicao at a outra, de n de comutao em n de comutao, colhendo informaes sobre o desempenho nos enlaces que formam a rota. Ao final dessa busca, pode ser precisado onde e porque est ocorrendo uma queda no desempenho.

18 A capacidade de processamento local que pode ser instalada nos elementos gerenciados com o emprego das redes ativas e o paradigma de mobilidade viabilizam uma distribuio no gerenciamento que possibilita ao mesmo ser pr-ativo. 2.6. Resumo do captulo Este captulo apresentou os conceitos bsicos sobre os quais a arquitetura de gerenciamento de desempenho pr-ativo que o assunto dessa dissertao construda. Inicialmente foi discutida a mudana do paradigma de gerenciamento centralizado para distribudo. Foi ento definido o gerenciamento de desempenho pr-ativo. Em seguida, foram apresentadas as caractersticas, vantagens e limitaes das redes ativas, programveis e dos agentes mveis. Ainda nesta subseo foram comparadas as redes ativas com os agentes mveis, que, juntas, compem a tecnologia ativa. Finalmente, esses conceitos bsicos foram integrados para que fossem apresentadas as vantagens do gerenciamento distribudo, em particular, do gerenciamento de desempenho, usando tecnologia ativa.

19

Captulo 3 - Gerenciamento de desempenho pr-ativo

O gerenciamento de desempenho de redes, servios, estaes e aplicaes pode ter seus objetivos reunidos em duas diretrizes, que so conflitantes entre si: (i) viabilizar o provimento dos nveis adequados de QoS que atendam s necessidades dos usurios e (ii) definir estratgias de alocao de recursos que maximizem a utilizao desses elementos gerenciados, oferecendo benefcios, particularmente, aos provedores de redes e dos servios. As atividades e os mecanismos que so necessrios para a busca ao atendimento a esses objetivos podem ser organizados, de acordo com proposta de Pacifici [25], no modelo10 apresentado na Figura 3.
Operador ou Administrador
Interao

Sistema de Gerenciamento de Desempenho

Controle Monitorao

Sistema de Controle de Trfego em Tempo Real Recursos Computacionais Recursos de Comunicao

Figura 3 - O Sistema de gerenciamento de desempenho

O Sistema de controle de trfego em tempo real regula a competio pelos recursos disponveis nas estaes e nos ns de comutao em tempo real. Um mecanismo de roteamento, por exemplo, faz parte desse Sistema de controle. O Sistema de gerenciamento de desempenho controla a operao do Sistema de controle de trfego em tempo real, enquanto o Operador ou Administrador supervisiona toda as atividades, interferindo quando e onde for necessrio. As interaes entre os dois sistemas se do tanto de forma assncrona, em diferentes escalas de tempo, quanto de forma sncrona, quando assim for necessrio. J a interao entre o sistema de gerenciamento de desempenho e o operador se d sempre de forma assncrona. O controle de trfego em tempo real realizado por uma coleo de mecanismos, cada um com uma tarefa especfica, que atua nos diversos elementos gerenciados, que operam tambm de forma assncrona entre si. Exemplos de controles realizados por esses mecanismos so: gerenciamento de armazenamento temporrio em memria, de escalonamento de processos ou threads no processador de uma estao ou de um n de comutao; de controle de fluxo, de roteamento

10

Considera-se que as aplicaes esto includas em Recursos Computacionais.

20 e/ou re-roteamento, de controle de admisso, entre outros. A operao desses mecanismos pode ser sintonizada atravs de parmetros de controle associados a cada um dos mecanismos. O estado da rede, dos servios, das aplicaes e das estaes formado e pode ser obtido a partir da unio, composio e interpretao desses parmetros. O Sistema de gerenciamento de desempenho executa a sua tarefa monitorando os valores desses parmetros e executando aes de controle, alterando o estado dos elementos gerenciados, tambm por intermdio desses parmetros. O operador monitora esse estado atravs de abstraes dinmicas visuais apresentadas em uma interface grfica e exerce o controle atravs da manipulao de parmetros de gerenciamento de desempenho. A arquitetura proposta neste trabalho baseada no modelo de sistema de gerenciamento de desempenho proposto por Pacifici [25], que foi apresentado na Figura 3. Adicionalmente, o paradigma de tecnologia ativa usado, tendo como base a Arquitetura de Gerenciamento de Rede Ativa Distribuda (AGAD) [19], que foi desenvolvida no NCE da UFRJ. O Sistema de gerenciamento de desempenho proposto pr-ativo porque monitora os parmetros desejados do Sistema de controle de trfego em tempo real para detectar tendncia de queda no desempenho dos mesmos que possam levar ocorrncia de falhas de QoS. Falhas de QoS causam impacto nos servios que esto sendo prestados aos usurios como, por exemplo, a interrupo de um fluxo de vdeo que esteja sendo exibido. Um vez que sejam detectadas as tendncias de queda no desempenho, aes so desencadeadas para que seja tentada a reverso dessa tendncia ou, caso isso seja impossvel, pelo menos a reduo das conseqncias para o usurio. Essas aes se materializam na forma de ajustes nos parmetros de controle do Sistema de controle de trfego em tempo real. O comportamento do retardo em um servio de comunicao pode ser utilizado como exemplo. Um mecanismo integrante do Sistema de controle de trfego em tempo real, que est fora do escopo desse trabalho, disponibiliza informaes sobre o parmetro de controle retardo. O Sistema de gerenciamento de desempenho pr-ativo monitora a tendncia de comportamento desse parmetro atravs de sua variao e estima, mediante extrapolao, que a ultrapassagem do seu limite mximo, e a conseqente falha de QoS, ocorrer em determinado instante, caso aquela tendncia se mantenha. Aes so ento desencadeadas automaticamente, via agentes mveis, aplicaes ativas ou outros meios, para que seja pelo menos tentada a reverso da tendncia que foi detectada. Um exemplo dessas aes poderia ser a alterao de uma ou mais rotas em uma rede. As aes desencadeadas pelo Sistema de gerenciamento de desempenho podem no ser suficientes para que seja evitada uma falha de QoS. Nesse caso, aes podem ser desencadeadas junto

21 aos usurios dos servios de comunicaes, ou seja, as aplicaes, para que as adaptaes cabveis possam ser realizadas de forma a, pelo menos, se tentar evitar a queda na QoP percebida pelo usurio. Nesse caso, como as adaptaes certamente reduziro os nveis de QoS exigidos, pode ser possvel at que a falha de QoS prevista no venha a acontecer e que o prejuzo para quem assiste a um vdeo, por exemplo, se limite apenas mudana de resoluo espacial do mesmo. A caracterstica pr-ativa da arquitetura de gerenciamento de desempenho ora proposta quem viabiliza que as adaptaes possam vir a ser desencadeadas, se no totalmente, pelo menos parcialmente antes da ocorrncia de falhas de QoS. Este captulo est organizado em cinco sees alm de um resumo ao seu final. A prxima seo apresenta um resumo da AGAD, sobre a qual um sistema baseado na arquitetura sendo proposta deve ser executado. A seo 3.2 descreve a Arquitetura de gerenciamento de desempenho prativo propriamente dita, apresentando a sua organizao, seus elementos e o seu funcionamento. A seo seguinte descreve, em detalhes, os elementos da arquitetura e como os mesmos funcionam. A seo 3.4 descreve casos onde o emprego do gerenciamento de desempenho pr-ativo pode ser vantajoso e a seo 3.5 posiciona a arquitetura sendo proposta em relao aos trabalhos existentes na rea, tecendo comparaes. 3.1. Arquitetura AGAD A Arquitetura de Gerenciamento Ativa Distribuda (AGAD) [19] tem por objetivo prover uma infra-estrutura baseada em tecnologia ativa que permita o gerenciamento distribudo das redes, servios, estaes e aplicaes de um ou vrios sistemas autnomos. A Figura 4 apresenta uma viso geral da AGAD, cujo funcionamento ser resumido em seguida.
GD Domnio I I
A A A A

GM

I E I E
A

GM: GD: I: E: G:

Gerente Mor Gerente de Domnio Inspetor Especialista Guardio

A A

Comunicao Roteador Ativo Roteador-Comutador Ativo Roteador Legado

Figura 4 - Viso geral da AGAD

22 Os principais elementos da AGAD so: (i) Gerentes Mor (GM), (ii) Gerentes de Domnio (GD), (iii) Inspetores, (iv) Especialistas e (v) Guardies. A comunicao entre esses elementos realizada por um protocolo prprio. A seguir sero descritas as funcionalidades bsicas de cada um desses elementos.
3.1.1. Gerente Mor

O GM implementado de forma fixa, em uma estao de trabalho, e oferece uma interface grfica para um administrador ou operador. O GM o responsvel pelo gerenciamento de um conjunto de domnios, via Gerentes de Domnio. Informaes de gerenciamento consolidadas do conjunto de domnios so disponibilizadas pelo GM. Para tal, ele possui, em seu cdigo, diferentes componentes de software que tratam das diferentes reas funcionais de gerenciamento. O GM utiliza-se de trs bases de dados: a Base Geral de Cdigos (BGC), a Base de Informaes de Gerncia (BIG) e a Base de Topologia Geral (BTpG). A BGC contm os cdigos dos demais componentes da AGAD. A BIG armazena informaes consolidadas sobre o gerenciamento dos domnios (recebidas de cada GD) e a BTpG contm informaes sobre as topologias dos domnios gerenciados pelo GM. O GM cria os GD e os envia para seus respectivos domnios. O funcionamento desses GD passa ento a ser monitorado via mensagens do tipo keep alive e a integridade, no s dos GD, como dos demais elementos da AGAD, passa a ser monitorada pelos guardies. Na inicializao do gerenciamento ou em caso de falha de um guardio j existente, o GM cria Guardies e os envia aos seus GD para que cumpram tarefas relativas ao monitoramento da integridade dos mesmos. Dependendo da quantidade de domnios gerenciados, pode haver mais de um GM.
3.1.2. Gerente de Domnio

Um domnio equivale a um conjunto de elementos a serem gerenciados sob uma mesma autoridade administrativa. Da mesma forma que o GM, o GD tambm disponibiliza uma interface grfica para o administrador do sistema, com as mesmas funcionalidades da interface do GM. O GD responsvel pelo gerenciamento de seu domnio, que inclui a disponibilizao de informaes de gerenciamento de nvel domnio e o desencadeamento de aes, quando necessrias, para a reverso de alguma situao desfavorvel ou para, pelo menos, a minimizao dos efeitos dessa situao. Para isso, so mantidas na GD quatro bases de informaes: a Base de Topologia do Domnio (BTpD), a Base de Cdigos de Domnio (BCD), a Base de Conhecimento, (BCN) e a Base de Informaes dos Componentes do Domnio (BICD). O GD cria e envia Inspetores e Especialistas aos elementos do domnio que devem ser gerenciados. As informaes de gerenciamento (consolidadas) recebidas dos Inspetores so armazenadas

23 na BICD e, aps a anlise e classificao das mesmas, de acordo com o que estiver prescrito na BCN, Especialistas podem ser criados pelo GD para que sejam enviados para onde forem necessrios para a realizao de tarefas especializadas relativas ao gerenciamento. A anlise e classificao podem se utilizar de tcnicas de IA, da a presena da BCN. Alm da interao com Inspetores e Especialistas, o GD tambm emite, aps consolidaes, relatrios com informaes de gerenciamento sobre o seu Domnio. Quando necessrio, informaes relevantes so enviadas ao GM.
3.1.3. Inspetor

Os Inspetores devero realizar, de fato, as tarefas relativas ao monitoramento no gerenciamento dos elementos do domnio. So eles os responsveis pela obteno, local, dos dados referentes s funcionalidades que so gerenciadas, ou seja, a monitorao dos parmetros de controle do Sistema de controle de trfego em tempo real, conforme apresentado na Figura 4. A obteno desses dados feita com o uso das facilidades disponveis localmente, desde acesso direto s MIB at o uso de agentes proxy (explicados posteriormente). Os dados podem ento sofrer um processamento local, simplificado o suficiente para no sobrecarregar o elemento gerenciado em questo, realizado pelo prprio Inspetor, para que apenas um mnimo de informaes sejam enviadas, via rede, ao GD. O processamento local tem por objetivo realizar desde a filtragem de informaes irrelevantes at a fuso de informaes relevantes diferentes em uma mesma mensagem a ser enviada ao GD. Alm dessa operao assncrona em relao ao GD, o Inspetor tambm pode operar de forma sncrona, atendendo a pedidos especficos daquele Gerente. O Inspetor implementado segundo a organizao que apresentada, de forma esquemtica, na Figura 5.
Espaos para outros componentes Componente especfico j Instalado

Inspetor
Funes Bsicas

Sistema de controle de trfego em tempo real

Agente Legado

Agente Proxy

Comunicaes

Figura 5 - Implementao do Inspetor

O bloco comunicaes refere-se s facilidades de comunicao de dados do sistema operacional do elemento gerenciado que hospeda o Inspetor. Agentes proxies tm por finalidade disponibilizar uma interface padro com o Inspetor e, ao mesmo tempo, interagir com uma tecnologia

24 proprietria. Agentes legados so aqueles diretamente acessveis, via interfaces bem definidas, como por exemplo, uma MIB. A implementao do Inspetor configurvel dinamicamente, de forma a permitir que as diferentes reas funcionais de gerenciamento sejam tratadas independentemente, de acordo tanto com a natureza do elemento a ser gerenciado quanto com as intenes do administrador do domnio. possvel tambm a atualizao do cdigo dos componentes em tempo de execuo. As funes bsicas tratam de tarefas referentes ao funcionamento do Inspetor em si e de tarefas comuns s reas funcionais de gerenciamento, como, por exemplo, a comunicao com o GD e a interao com um Guardio.
3.1.4. Especialista

Uma vez que os Inspetores detectem situaes que exijam aes ou mesmo anlises mais especializadas, agentes Especialistas devem ser empregados. Para estes no h uma organizao configurvel dinamicamente semelhante quela do Inspetor. Eles so softwares autnomos, com funes bem definidas. Os Especialistas apropriados so enviados pelo GD ao elemento gerenciado em questo ou a outros elementos com um objetivo bem definido, para o qual foram programados. Exemplos de aes que podem ser realizadas por Especialistas so: a alterao de polticas de escalonamento, reconfigurao de utilizao de memria, interagir com uma aplicao adaptativa, etc. Um Especialista pode at mesmo ser implementado na forma de uma mensagem para sinalizar a necessidade de que seja desencadeada uma adaptao em nvel aplicao ou um re-roteamento.
3.1.5. Guardio

O Guardio tem como objetivo verificar se os demais componentes da AGAD esto funcionando corretamente e se os cdigos dos mesmos esto ntegros, ou seja, se no foram alterados inadvertida ou intencionalmente. Cada um dos elementos da AGAD implementa uma interface para interao com o Guardio, onde h o suporte para funcionalidades como autenticao, autorizao, controle de execuo e verificao.
3.1.6. Comunicao entre os elementos da AGAD

A comunicao entre os elementos da AGAD se d por intermdio de um protocolo prprio, de nvel aplicao. Essa comunicao serve tanto para a troca de mensagens quanto para a mobilidade de cdigo. Diversas so as opes para a mobilidade de cdigo, caracterstica que ser apresentada com maiores detalhes no captulo referente ao ambiente de desenvolvimento e implementao.

25 3.2. Arquitetura de gerenciamento de desempenho pr-ativa A arquitetura de gerenciamento de desempenho pr-ativa proposta nesse trabalho tem por objetivo realizar o gerenciamento de desempenho relacionado aos elementos apresentados na Figura 6.
Aplicao
A A A A

Aplicao

Estao N de Comutao Enlace de Comunicao Servio de Comunicao

Figura 6 - Elementos cujo desempenho gerenciado

Sero descritos, a seguir, os parmetros11 de controle relevantes para o gerenciamento de desempenho relativo a cada um desses elementos. O tempo de resposta relevante para uma aplicao. Esse o tempo decorrido entre o recebimento, pela aplicao, de uma solicitao e a disponibilizao de uma resposta. A estao, que composta por um hardware e um sistema operacional, deve ter a capacidade de processamento, a quantidade de memria disponvel, e o tamanho da fila de sada gerenciados. No caso do servio de comunicao, so relevantes o retardo, a variao do retardo, a taxa de erros, a taxa de perdas e a vazo. Os aspectos a terem seu desempenho gerenciados em um n de comutao so os mesmos de uma estao, exceto pela presena de vrias filas de sada. Em um enlace de comunicaes so importantes a utilizao, a taxa de erros e a taxa de perdas. Alm desses parmetros considerados relevantes, o Sistema de controle de trfego em tempo real pode disponibilizar outros parmetros para monitorao e controle, como, por exemplo, a taxa de colises de um canal de comunicao compartilhado ou a taxa de broadcasts por unidade de tempo. Conforme j foi mencionado, a associao destes parmetros de controle com o elemento gerenciado de responsabilidade dos mecanismos do Sistema de controle de trfego em tempo real, que est fora do escopo desse trabalho. Ao Sistema de gerenciamento de desempenho s cabe a monitorao (obteno do valores) e o controle (determinao de valores, quando possvel e necessrio) desses parmetros.

11

Esses parmetros de controle so utilizados para que sejam definidos nveis de QoS.

26 O gerenciamento de desempenho12 , tradicionalmente, realizado atravs da monitorao dos valores momentneos dos parmetros de controle, citados no pargrafo anterior, em relao aos limites mnimos e/ou mximos da faixa de valores tolerveis para o elemento gerenciado em questo. Nas abordagens tradicionais de gerenciamento, o desrespeito a esses limites leva gerao de Alarmes (como as Traps do SNMP, por exemplo) que, por sua vez, devero desencadear, normalmente, apenas sinalizaes por parte de uma aplicao de gerenciamento ao administrador da rede. As desvantagens desse modelo centralizado, mencionadas na Seo 2.1, devem-se centralizao excessiva no processamento das informaes sobre aqueles parmetros e, adicionalmente, ao fato de que as aes so desencadeadas para tentar se reverter um quadro desfavorvel em relao ao desempenho somente aps o desrespeito aos limites, ou seja, aps a ocorrncia de uma falha de QoS. A utilizao de tecnologia ativa e a disponibilidade de mecanismos de adaptao, associadas capacidade de processamento cada vez mais poderosa do hardware computacional presente tanto em estaes quanto em ns de comutao, torna possvel a explorao do monitoramento das tendncias de comportamento dos parmetros de controle de desempenho dos elementos apresentados na Figura 6. A tecnologia ativa viabiliza no somente a presena de agentes13 de gerenciamento dotados de inteligncia e capacidade de processamento para monitorar as tendncias localmente, bem como tambm viabiliza o envio de agentes (mveis) ou aplicaes ativas para a realizao de aes onde as mesmas forem necessrias, quando assim for desejado e vivel. As aplicaes adaptativas, por sua vez, aps o recebimento de informaes sobre as tendncias de desempenho dos parmetros que lhes so relevantes, como tempo de resposta, retardo, variao do retardo, taxas de perdas e de erros, podem comear a desencadear o processo de adaptao e, se for o caso, abrir novas sesses de um servio de comunicaes. Quando estas adaptaes forem de fato necessrias, o tempo perdido com as mesmas que percebido pelo usurio ser menor, pois parte das tarefas j foram realizadas. Essas aes, normalmente no so desencadeadas de forma automtica nas abordagens tradicionais de gerenciamento, onde no utilizada tecnologia ativa. Uma aplicao adaptativa que exibe um fluxo de vdeo pode ser utilizada como exemplo. Normalmente, a adaptao realizada aps a ocorrncia de uma falha de QoS. Isso implica na per-

12

Deste ponto em diante, nesta dissertao, o termo Gerenciamento de desempenho faz aluso, na realidade, ao Sis-

tema de gerenciamento de desempenho, de acordo com o que foi mostrado na Figura 3.

13

Nesse caso, o significado de agente de gerenciamento, conforme previsto pelo IETF para o SNMP [51].

27 cepo, pelo usurio, da ocorrncia da falha, na forma de uma paralizao do fluxo de vdeo, at que uma nova mdia seja apresentada. Usando o gerenciamento pr-ativo, pode ser possvel o adiantamento da adaptao, tendo como base as tendncias de comportamento dos valores dos parmetros de QoS, para que a queda de qualidade de percepo do usurio quando da ocorrncia de uma falha de QoS seja minimizada. A seguir sero descritas as quatro atividades que so realizadas pelo gerenciamento de desempenho pr-ativo que est sendo proposto, juntamente com o(s) momento(s) de seu desencadeamento. 1. Monitorao dos parmetros de controle do elemento gerenciado: realizada continuamente, com freqncia configurvel para cada parmetro, para detectar as tendncias de variao dos mesmos. 2. Comunicao com o Gerente de Desempenho de Domnio e, quando for o caso, com o elemento gerenciado: realizada quando for necessria, sendo causada pela deteco de uma tendncia de que venha a ocorrer uma falha de QoS. As condies para que uma tendncia seja caracterizada tambm so configurveis. 3. Ao automtica ou manual junto aos elementos gerenciados: realizada quando ordenada. 4. Emisso de relatrios sobre o gerenciamento de desempenho: realizada periodicamente, com freqncia configurvel, ou quando ordenada.
3.2.1. Monitorao

A monitorao realizada pelo componente (de software) de gerenciamento de desempenho pr-ativo instalado no Inspetor associado ao elemento a ser gerenciado. Esse componente de software de Inspetor ser tratado, deste ponto em diante, como Inspetor de Desempenho (ID), embora, de fato, seja implementado na forma de um componente de software do verdadeiro Inspetor, de acordo com o que previsto pela AGAD. Durante a monitorao so coletados dados das fontes disponveis, (como MIBs, informaes obtidas do RTCP, de agentes proxy do sistema operacional da estao ou do n de comutao, ou das prprias aplicaes), sobre os parmetros de controle que devem ser monitorados. A interface que existe entre o Inspetor de Desempenho e o elemento gerenciado, que a interface entre o Sistema de gerenciamento de desempenho e o Sistema de controle de trfego em tempo real do modelo apresentado na Figura 3, ser detalhada na Seo 3.3.

28 A partir desses que foram dados coletados so calculadas as variaes dos parmetros que devem ser monitorados ao longo do tempo, para que sejam detectadas as tendncias dessas variaes. As variaes so ento utilizadas para que, mediante extrapolaes, sejam calculados os instantes de tempo quando, caso as tendncias se mantenham, limites mnimos ou mximos venham a ser desrespeitados. Em funo do tempo disponvel at que, de fato, as falhas de QoS ocorram, diferentes aes podem ser desencadeadas. Essas extrapolaes so calculadas nos Gerentes de Domnio. O Inspetor de Desempenho trata apenas da obteno dos dados, do clculo das variaes ocorridas nos mesmos e do envio dessas variaes, quando necessrias e j consolidadas, ao Gerente de Desempenho de Domnio. Visando um melhor entendimento do funcionamento do Inspetor de Desempenho, ser usado como exemplo a monitorao de um parmetro que expressa a disponibilidade de um recurso, que expressa (e obtida) em valores percentuais. O Inspetor de Desempenho estar preocupado, ento, com a diminuio desta disponibilidade. A Figura 7 apresenta uma escala representando: a faixa de valores na qual o parmetro pode variar (0 a 100%), um valor que o limite mnimo para o envio de Alarmes (80%) e trs observaes obtidas na monitorao (n, n+1 e n+k) pelo Inspetor de Desempenho. S sero enviados Alarmes de Tendncia caso a variao calculada a partir das observaes assim exigir (ser explicado a seguir), desde que o valor da observao que levou necessidade de enviar o Alarme seja igual ou menor do que valor limite. Em caso contrrio, todas as informaes so calculadas e armazenadas, mas o Alarme de Tendncia no enviado.
100% Teto para a variao acumulada Variao em 1 intervalo Variao acumulada 0%
Figura 7 - Exemplo de parmetro monitorado

80%

Valor limite Observao n Observao n+1 Observao n+k

Dois limites mximos devem ser estabelecidos para a variao: o valor mximo para uma variao em um nico intervalo, ou seja, entre duas observaes consecutivas (n e n+1 na figura), e o valor mximo para a variao acumulada desde o ltimo Alarme que foi enviado, (na figura, entre n e n+k), independentemente do nmero de observaes (k, no caso do exemplo). O valor da observao n da figura o valor de referncia (chamado de teto) para clculo da variao acumulada. Esse teto pode ser o maior de dois valores: da ltima observao que motivou o envio

29 de um Alarme de Tendncia ou de uma observao posterior, cujo valor tenha sido maior do que aquela que motivou o envio do Alarme. Cabe destacar que no exemplo que est sendo analisado, maior significa melhor, uma vez que o parmetro monitorado representa disponibilidade. No caso do segundo valor para o teto (observao posterior j citada), como uma observao posterior veio a ser maior (melhor, portanto) do que aquela que motivou o envio de um Alarme, ela passa a ser considerada como o teto para o clculo da variao acumulada. Visando ilustrar o que est sendo explicado, ser utilizada uma amostra de teste com 50 observaes. Os dois tipos de variaes que levam ao desencadeamento de um Alarme de Tendncia (ser maior do que a variao mxima tolerada em um intervalo ou ser maior do que a variao mxima acumulada tolerada) e o comportamento do teto (bola cheia) da variao acumulada esto ilustrados na Figura 8. O parmetro utilizado como exemplo ainda o mesmo da Figura 7, ou seja, a disponibilidade de um recurso. Nesse caso, o valor mximo tolerado para a variao em um intervalo entre duas observaes consecutivas de 10% e o valor mximo para a variao acumulada de 12%. O valor limite (mnimo) para envio de Alarmes aquele que j foi citado, 80%.
100
99

90
90

95 91 90 85 84 85 82 84 80 75 78 77 79 80 81 80 81 75 76 72 73 68 60 55 57 50

80 70 60

65 64 60 58 56 57

50 40 30 20 10

AVI
54 53 50 48 45 44 49 50 40 39 36

61

AVA

AVI

AVA
41 37 33

AVA AVI

AVA

AVA

15

AVI
0 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49

AVI: Alarme por variao em 1 intervalo AVA: Alarme por variao acumulada

Observaes
Valores Teto

Figura 8 - 50 observaes para teste

O teto (inicialmente coincidente com o valor da primeira observao) aumentado de acordo com o aumento dos valores das observaes de 1 at 4. Nas observaes 3 e 5 o valor da observao decresce, mas o teto mantido, pois ele a referncia para o clculo da variao acumulada. Na observao 6 a variao acumulada chega a -14 (85% 99%), excedendo o limite que foi configurado, que de 12%. Um Alarme de Tendncia deveria ento ser enviado. Nesse caso, isso no ocorrer, pois o valor da observao 6 (85%), que motivou o Alarme, ainda superior

30 ao limite estabelecido para o envio de Alarmes, que de 80%. O teto para clculo de variao acumulada ento atualizado para o valor da observao 6. Na observao 11 (60 %, variando 20%, referentes a ltima observao, que foi de 80%) tanto o limite para a variao acumulada (12%) quanto o limite para a variao em um intervalo foram ultrapassados (10%), o que levar ao envio de um Alarme de Tendncia, j que o limite mnimo para o envio de alarmes, que 80%, tambm foi desrespeitado. Entre as observaes 11 e 18 (valores 60% e 48%, respectivamente) o valor para a variao acumulada igualado, o que levar ao envio de um Alarme. Deve-se notar que o valor da observao 14 (57%), embora tenha aumentado em relao observao anterior (56%), no causa atualizao do valor do teto, pois no maior do que o valor do teto no momento, que de 60%. Pode-se concluir que o valor do teto s reduzido quando do envio de Alarme. J o aumento do valor do teto ocorre sempre que uma observao apresentar valor superior ao valor atual do teto. No caso do parmetro de controle associar melhor desempenho a menores valores numricos das observaes e pior desempenho a maiores valores numricos, tudo que foi explicado anteriormente continuar sendo vlido, sendo necessria apenas a inverso do sentido do eixo de referncia. Esse seria o caso se o parmetro representasse o percentual de utilizao de um recurso em vez do percentual de disponibilidade que foi usado como exemplo. As informaes que so necessrias para o clculo de variaes e para a tomada de deciso a respeito do envio ou no de um Alarme de Tendncia devem ser mantidas em memria principal, visando uma minimizao do tempo de acesso s mesmas. Memria secundria deve ser utilizada apenas para o registro perene dessas e outras informaes que so julgadas necessrias, at que as mesmas sejam enviadas ao Gerente de Domnio. O acesso memria secundria no deve inviabilizar o respeito ao intervalo entre obtenes consecutivas das observaes dos valores do parmetro monitorado. Essa freqncia de monitorao do parmetro de controle em questo limitada pelo tempo de execuo do Inspetor de Desempenho, que deve realizar o que foi descrito nesse exemplo cada vez que for obtida uma nova observao do valor do parmetro. Alm dos Alarmes de Tendncia, o Inspetor de Desempenho armazena e envia, periodicamente, para o Gerente de Desempenho de Domnio, informaes sobre o parmetro de controle monitorado que venham a servir para o planejamento de capacidade. Os Alarmes de Tendncia podem ser tambm enviados a outras aplicaes alm do Gerente de Desempenho de Domnio, desde que o Inspetor de Desempenho seja assim configurado.

31
3.2.2. Comunicao

A comunicao desencadeada pelo Inspetor de Desempenho visa atingir trs objetivos: (i) transmitir para o Gerente de Desempenho de Domnio as informaes que devem ser armazenadas para fins de emisso de relatrios e de planejamento de capacidade, (ii) enviar ao Gerente de Desempenho de Domnio Alarmes de Tendncias, (iii) enviar s aplicaes que assim o desejarem, os Alarmes de Tendncia sobre os parmetros monitorados. Essa comunicao realizada, no caso (i), atravs da interface existente entre o Inspetor de Desempenho e o Inspetor propriamente dito. No caso (ii), a comunicao feita diretamente entre o Inspetor de Desempenho e o Gerente de Desempenho de Domnio. No caso (iii), a comunicao realizada diretamente entre o Inspetor de Desempenho e as aplicaes. A Figura 10 apresenta essas interfaces de forma esquemtica. Essa comunicao produz o menor trfego possvel na rede, sendo desencadeada apenas quando for necessria. Ela consiste apenas no envio de cdigos e valores de parmetros, alm da identificao do Inspetor de Desempenho que as originou. O detalhamento dessa comunicao ser feito tambm na Seo 3.3.
3.2.3. Aes

As aes referentes ao gerenciamento de desempenho so realizadas por Especialistas de Desempenho. A seguir so citadas possveis aes que podem ser realizadas por Especialistas nos elementos gerenciados. Aplicaes: podem ser avisadas da tendncia de queda no desempenho de servios de comunicao e da prpria estao. Nesse caso, a ao do Especialista a realizao de uma comunicao. As aes propriamente ditas que so necessrias, como, por exemplo, adaptaes, devem ser desencadeadas pelas prprias aplicaes. Estao: redimensionamento de espaos para armazenamento temporrio, alterao de prioridades e/ou de polticas de escalonamento e encerramento ou ativao de processos e/ou threads. Servio de comunicaes: renegociao de parmetros de QoS e mudanas de rotas. Ns de comutao: as mesmas previstas para uma estao e a alterao da poltica de escalonamento de pacotes nas filas de sada.

32 Enlace de comunicaes: este elemento no pode ser objeto, diretamente, de nenhuma ao. No entanto, alteraes nos algoritmos de deteco e correo de erros podem ser feitas, com o objetivo de se melhorar o desempenho de um enlace. A descrio detalhada do Especialista de Desempenho, da sua composio e o seu funcionamento, bem como a interface entre os Especialistas e os elementos gerenciados que devem sofrer essas aes, ser feita na Seo 3.3.4.
3.2.4. Relatrios

Dois tipos de relatrios so disponibilizados: Relatrios de Estado e Relatrios para Planejamento de Capacidade. O primeiro tipo, Relatrio de Estado, consolida e apresenta as ltimas informaes disponveis relativas ao desempenho dos elementos desejados, individualmente ou em conjunto. O segundo tipo, Relatrio para Planejamento de Capacidade, consolida informaes relativas ao desempenho ao longo de um perodo de tempo, que pode ser definido pelo operador ou administrador. Uma interface grfica presente nos Gerentes Mor e de Domnio disponibiliza as interaes que so necessrias para a emisso desses relatrios. O detalhamento e a implementao desses relatrios foram deixados fora do escopo deste trabalho. 3.3. Elementos integrantes da arquitetura Nesta seo, sero apresentados de forma detalhada os elementos da Arquitetura de Gerenciamento de Desempenho Pr-ativo, incluindo o objetivo de cada um, os seus relacionamentos com os demais elementos da AGAD e os seus ciclos de vida. A Figura 9 apresenta (sem usar uma notao especfica) os relacionamentos dos componentes da Arquitetura de Desempenho Pr-ativo14 do Gerente Mor e do Gerente de Domnio com os seus respectivos Gerentes. Esses componentes so denominados Gerente de Desempenho Mor e Gerente de Desempenho de Domnio. As interfaces entre esses componentes de software e os seus respectivos Gerentes da AGAD so tambm apresentadas.

14

Deste ponto em diante ser empregado apenas o termo Desempenho. O significado desse termo, no contexto des-

se trabalho , no entanto, o de Desempenho Pr-ativo.

33

Interfaces

Gerente Mor

Gerente de Domnio Componente de Desempenho de Gerente de Domnio

Legenda: Legenda:
BIG: Base de Informaes de Gerncia BTpG: Base de Topologia Geral BTpG: BTpD: Base de Topologia de Domnio BTpD: BCD: Base de Cdigos de Domnio BCN: Base de Conhecimento BICD: Base de Informaes dos Componentes de Domnio

Componente de Desempenho de Gerente Mor

BIG

BTpG

BTpD

BCD

BCN

BICD

Figura 9 - Componentes de gerenciamento de desempenho dos Gerentes

A Figura 10 apresenta os relacionamentos do componente de software que trata do gerenciamento de desempenho (ou Inspetor de Desempenho) com o Inspetor (da AGAD) e com o elemento gerenciado. tambm apresentado o relacionamento do Especialista de Desempenho com o elemento no qual sero desencadeadas aes. As interfaces tambm esto assinaladas.
Interface com Inspetor

Inspetor Interface com as Aplicaes

Componente de Desempenho de Inspetor

Especialista de Desempenho

Monitorao Base de Informaes Temporrias Elemento Gerenciado

Controle Elemento a sofrer aes

Figura 10 - Inspetor de Desempenho e Especialista de Desempenho

O termo componente que empregado nesta e nas prximas sub-sees refere-se a componente de software, que a forma pela qual so implementados os componentes da arquitetura de desempenho pr-ativo junto aos seus respectivos hospedeiros da AGAD. As interfaces mostradas nessas duas figuras se do em nvel aplicao, luz da orientao a objetos e do desenvolvimento de software orientado a componentes [22], que viabiliza a atualizao de cdigo em tempo de execuo. A interao entre o Inspetor de Desempenho e elemento gerenciado, bem como entre Especialista de Desempenho e esse mesmo elemento, pode se dar de forma direta, atravs a obteno e/ou a determinao de valores dos parmetros de controle do Sistema de controle de trfego em tempo real, ou de forma indireta, por intermdio de elementos integrantes deste ltimo sistema. Nesse ltimo caso, conforme j foi citado, a ao do Especialista pode se resumir apenas a uma notificao.

34
3.3.1. Gerente de Desempenho Mor

Esse componente de software do Gerente Mor trata do armazenamento de informaes e da disponibilizao de dados para a emisso de relatrios referentes ao gerenciamento de um conjunto de domnios. As informaes so recebidas dos Gerentes de Desempenho de Domnio via facilidades de comunicao da AGAD e armazenadas na BIG. O operador ou administrador do Gerente Mor pode ento, via interface grfica para interao com esse Gerente, ordenar a emisso de relatrios, que podem ser dos dois tipos j citados: relatrios sobre o estado do conjunto de domnios no que diz respeito ao desempenho ou relatrios para o planejamento de capacidade do conjunto de domnios. O funcionamento do Gerente de Desempenho Mor pode ser entendido atravs do estudo do seu ciclo de vida, que est ilustrado na Figura 11: 1. O Gerente de Desempenho Mor deve ser iniciado pelo Gerente Mor, quando o operador ou administrador optar pela realizao do gerenciamento de desempenho. 2. Quando o gerenciamento de desempenho de domnio for desejado e, conseqentemente, ordenado, obter o cdigo do Gerente de Desempenho de Domnio da BGCdigos. 3. Enviar o cdigo do Gerente de Desempenho de Domnio para o Gerente de Domnio do elemento da rede onde o mesmo ser executado. 4. Trocar informaes com os Gerentes de Desempenho de Domnio atravs das facilidades de comunicaes da AGAD 5. Armazenar as informaes relevantes na BIG. 6. Verificar, periodicamente, se os Gerentes de Domnio esto ativos. 7. Quando ordenado, apresentar relatrios de estado ou para o planejamento de capacidade ou ainda qualquer outra informao solicitada.
3
Gerente Mor
threads

4 5
GDD

Gerente de Domnio
threads

1
GD Mor

2 BGC

6 BIG

Infra-estrutura de Mobilidade Infra-

Estao do Gerente Mor

Rede de um Domnio

Estao de um Gerente de Domno

Figura 11 - Ciclo de vida do Gerente de Desempenho Mor

35
3.3.2. Gerente de Desempenho de Domnio

Esse componente de software do Gerente de Domnio executado para que os oito objetivos citados a seguir sejam atingidos: (i) Enviar, quando ordenado, os Inspetores de Desempenho para os elementos a serem gerenciados. O Gerente de Desempenho de Domnio recupera da BCD o cdigo dos Inspetores de Desempenho que devem ser enviados aos elementos a serem gerenciados, de acordo com o que foi determinado pelo operador e/ou administrador. Em seguida, esse cdigo enviado ao elemento em questo, via a infra-estrutura de mobilidade da AGAD. (ii) Armazenar, aps consolidar, as informaes relativas ao gerenciamento de desempenho do domnio do qual faz parte, na BICD. Essas so as informaes que so recebidas dos Inspetores de Desempenho. A consolidao trata de minimizar as informaes a serem, de fato, registradas. Informaes decorrentes da execuo de outras tarefas pelo prprio Gerente de Desempenho de Domnio e pelos Especialistas tambm so armazenadas na BICD. (iii) Realizar anlises e extrapolaes, a partir de informaes sobre tendncias de comportamento do desempenho obtidas dos Inspetores de Desempenho. Essas anlises e extrapolaes so realizadas a partir das informaes monitoradas e enviadas pelos Inspetores de Desempenho sobre as tendncias de comportamento dos parmetros de controle do Sistema de controle de trfego em tempo real. O Inspetor de Desempenho, por poder estar instalado em equipamentos com pouca capacidade de processamento disponvel, trata apenas da obteno dos valores de momento dos parmetros de controle e do clculo da variao do valor desses parmetros. As variaes podem ser enviadas ao Gerente de Desempenho de Domnio de duas formas, de acordo com configurao determinada por esse mesmo Gerente: na forma de Alarmes de Tendncia (diretamente do Inspetor de Esempenho ao Gerente de Desempenho de Domnio) ou individualmente (via AGAD). Esse ltimo caso contempla a necessidade de que as prprias variaes sejam armazenadas ou processadas pelo Gerente de Desempenho de Domnio. Nesse caso a exigncia de capacidade de transmisso de dados da rede ser maior. O Gerente de Desempenho de Domnio, ao receber essas variaes (diretamente ou em na forma de um Alarme) analisa-as e realiza um clculo de extrapolao com o objetivo de determinar quando a variao em questo poder causar uma falha de QoS, ou seja, quando um limite m-

36 ximo ou mnimo para aquele parmetro em questo ser ultrapassado. Um exemplo desse limite pode ser um valor de retardo que, se atingido, leve ao esvaziamento de um buffer de recepo, gerando uma interrupo no fluxo de vdeo que est sendo apresentado. Essa anlise e a extrapolao podem se utilizar desde um simples ajuste de curva at avanadas tcnicas de IA, como exemplificado em [24]. O comportamento do desempenho do parmetro em questo que j conhecido tambm levado em considerao na extrapolao, de forma que fatores como, por exemplo, a distribuio do trfego na rede (baseline) ou do volume de transaes de uma determinada aplicao ao longo das horas do dia, que j so conhecidas, sejam computados nas estimativas. (iv) Decidir, de acordo com a anlise e as extrapolaes realizadas, se necessrio o envio de Especialistas e para quais elementos gerenciados os mesmos devem ser enviados. O tempo disponvel at a ocorrncia de falhas de QoS, o parmetro em questo e o tipo de elemento gerenciado so levados em conta para o Gerente de Desempenho de Domnio decidir se o caso enviar um ou mais Especialistas de Desempenho e para quais elementos gerenciados os mesmos devem ser enviados. A Base de Conhecimento (BCN) consultada para que essas decises sejam tomadas. No caso de uma adaptao [27], por exemplo, dois Especialistas podem ser enviados, um para o servidor e outro para o cliente, para que as respectivas partes da adaptao sejam desencadeadas. No caso de mudana de rotas, um nico Especialista, na forma de agente mvel, pode percorrer a nova rota alterando tabelas. Tcnicas de Inteligncia Artificial podem ser utilizadas tambm na escolha dos Especialistas e de seus destinos. (v) Enviar Especialistas de Desempenho.

Caso seja concludo, pela anlise da extrapolao, que Especialistas devem ser enviados e para onde devem ser enviados, o Gerente de Desempenho de Domnio deve obter, junto BCD, os cdigos dos Especialistas de Desempenho em questo para que eles sejam enviados aos elementos onde vo ser executados. A infra-estrutura de mobilidade da AGAD utilizada para esse envio. (vi) Enviar informaes consolidadas ao Gerente de Desempenho Mor. Resumos de todas as informaes que so armazenadas na BICD so enviados ao Gerente de Desempenho Mor, via AGAD. Esse envio pode ser configurado por aquele Gerente para ser realizado com uma determinada freqncia, condicionalmente ou a pedido.

37 (vii) Emitir os relatrios que forem solicitados. Da mesma forma que o Gerente de Desempenho Mor, o Gerente de Desempenho de Domnio disponibiliza os dados necessrios para a emisso dos Relatrios de Estado e para Planejamento de Capacidade que forem solicitados. Para que esses sete objetivos descritos anteriormente sejam alcanados, o funcionamento do Gerente de Desempenho de Domnio o que est descrito a seguir em seu ciclo de vida e est ilustrado na Figura 12: 1. Ser iniciado pelo Gerente de Domnio. 2. Obter, junto BCD, os cdigos dos Inspetores de Desempenho que forem necessrios para o gerenciamento de desempenho dos elementos que forem determinados pelo operador e/ou administrador. 3. Enviar os Inspetores de Desempenho aos elementos selecionados pelo administrador da rede, via AGAD. 4. Receber dos Inspetores de Desempenho via AGAD informaes relativas ao gerenciamento de desempenho do domnio e armazen-las, de forma consolidada, na BICD e enviar aos mesmos, tambm via AGAD, comandos e configuraes, se necessrio. 5. Receber Alarmes de Tendncias de comportamento dos parmetros de controle gerenciados dos Inspetores de Desempenho. 6. Analisar os Alarmes e realizar extrapolaes, consultando a BCN, e decidir quais as aes que devem ser desencadeadas para que seja tentada a reverso das tendncias. 7. Quando necessrio, escolher Especialistas que devem ser enviados e decidir para onde envi-los. Recuperar o cdigo dos Especialistas da BCD e envi-los via AGAD. 8. Quando ordenado, apresentar Relatrios de Estado ou para Planejamento de Capacidade, consultando as bases de dados que forem necessrias. No caso ilustrado na Figura 12, o Especialista foi enviado para o mesmo elemento gerenciado onde est sendo executado o Inspetor de Desempenho, o que no obrigatrio.

38

Gerente de Domnio

3
threads

1
GDD

5 8
Especialista

Inspetor Desemp
threads

2,7 BCD

6 BCN

Infra-estrutura de Mobilidade Infra-

Estao de um Gerente de Domnio

Rede de um Domnio

Elemento Gerenciado

Figura 12 - Ciclo de vida do Gerente de Desempenho de Domnio

3.3.3. Inspetor de Desempenho

O Inspetor de Desempenho executado em cada elemento da rede que tem algum parmetro de controle cujo desempenho deva ser monitorado e o operador assim o desejar. Os objetivos do Inspetor de Desempenho podem ser assim resumidos: (i) Monitorar os valores dos parmetros de controle do Sistema de controle de trfego em tempo real. A monitorao consiste na obteno peridica dos valores de momento dos parmetros de controle que foram determinados para que o seu desempenho seja gerenciado. As obtenes desses valores a partir de parmetros diferentes realizada de forma assncrona entre si, pois cada elemento e cada parmetro possui a escala de tempo mais apropriada para o seu gerenciamento. Os parmetros de controle do Sistema de controle de trfego em tempo real que so monitorados podem ter seus valores obtidos de diferentes formas. MIBs podem ser acessadas diretamente pelo Inspetor de Desempenho, via SNMP, valores referentes aos parmetros de um servio de comunicaes que se utilize dos protocolos RTP/RTCP para sua implementao podem ser obtidos a partir da aplicao que usa o servio e, quando no houver a possibilidade de acesso direto a esses valores, agentes proxies podem ser utilizados. Esses agentes proxies comunicam-se com a facilidade disponvel no elemento em questo e passam os valores desejados ao Inspetor de Desempenho, quando solicitado. (ii) Calcular as tendncias de variao dos valores dos parmetros.

O Inspetor de Desempenho, por ser implementado na forma de uma aplicao ativa ou de um agente mvel, poderia at mesmo realizar complexas computaes. No entanto, o mesmo no pode consumir uma quantidade significativa de capacidade de processamento do sistema

39 que o hospeda, especialmente quando este for um equipamento de rede, como um roteador, um comutador, uma ponte ou at mesmo um repetidor. Com a evoluo da tecnologia utilizada nos enlaces de comunicaes, o desempenho desses equipamentos de rede tende a ser tornar crtico para um bom desempenho do sistema de comunicao. Dessa forma, o processamento realizado pelo Inspetor de Desempenho, conforme j foi detalhado na seo 3.2.1, trata apenas da realizao do clculo da variao dos valores dos parmetros gerenciados a partir de valores consecutivos desses parmetros, bem como da comparao do resultado desse clculo com limites configurveis. O armazenamento das informaes que so necessrias execuo do Inspetor de Desempenho (clculo de variaes e comparaes), que no grande, feito em memria voltil, na Base de Informaes Temporrias BIT visando ter-se uma maior rapidez no acesso s mesmas. Todas as operaes e valores calculados pelo Inspetor de Desempenho so registrados, para serem usados na emisso de relatrios, em memria secundria, na Base de Informaes Permanentes BIP. (iii) Comunicar-se com o Gerente de Desempenho de Domnio ou com aplicaes para o envio de Alarmes de Tendncia ou de variaes. A comunicao com o Gerente de Desempenho de Domnio realizada por intermdio do Inspetor propriamente dito (da AGAD) ou diretamente ao Gerente de Desempenho de Domnio. Para a comunicao via AGAD, o Inspetor de Desempenho utiliza para isso a interface que foi mostrada na Figura 10. Essa comunicao consiste no envio, pelo Inspetor de Desempenho, das variaes na freqncia que for ordenada e tambm do recebimento de comandos sobre quais os parmetros a monitorar e quais os limites de variao a serem observados para esses parmetros. Os fragmentos de cdigo que atualizam os componentes do Inspetor de Desempenho so recebidos via AGAD. J no caso do envio de Alarmes de Tendncia, os mesmos so enviados diretamente ao Gerente de Desempenho, da forma que ser explicada na seo referente implementao. Esses trs objetivos so atingidos durante o ciclo de vida de um Inspetor de Desempenho, que descrito a seguir: 1. Ser iniciado pelo Inspetor (da AGAD). 2. Aguardar o recebimento das mensagens do Inspetor (da AGAD) que especificam os elementos e desses, quais os parmetros, a freqncia de observao, bem como os limites, que devem ter o desempenho monitorado.

40 3. Monitorar os parmetros de controle dos elementos que foram selecionados para terem o seu desempenho gerenciado, obtendo valores, calculando variaes, comparando-as com limites e, em seguida, armazenando-as na BIT. 4. Enviar para o Gerente de Desempenho de Domnio, via AGAD e na freqncia ordenada, informaes sobre as variaes dos valores dos parmetros de controle. 5. Enviar Alarmes de Tendncia referentes s tendncias que ultrapassaram seus limites ao Gerente de Desempenho de Domnio.
3.3.4. Especialista de Desempenho

O Especialista um software autnomo, que tem por objetivo realizar uma nica ao e enviar um relatrio ao Gerente de Desempenho de Domnio. O seu cdigo deve ter o menor tamanho possvel, para que o retardo relativo a sua transferncia no seja significativo. O cdigo do Especialista deve tambm ser desenvolvido especificamente para a tarefa para a qual foi projetado, podendo at ser dependente de plataforma, ou seja, enviado j na forma de cdigo executvel. A ao a ser realizada pode exigir que o Especialista seja um agente mvel, com mobilidade fraca ou forte [40], ou ainda que seja simplesmente enviado e executado, deixando de existir aps o envio de relatrio sobre a ao, sem as caractersticas de um agente mvel. Os objetivos do Especialista so descritos a seguir: (i) Desencadear as aes comandadas pelo Gerente de Desempenho de Domnio. O Especialista enviado a um elemento gerenciado via infra-estrutura de mobilidade e deve ser imediatamente instanciado para executar a ao para a qual foi projetado. (ii) Enviar relatrio das aes realizadas ao Gerente de Desempenho de Domnio. Toda ao realizada por um Especialista gera o envio de uma comunicao ao Gerente de Desempenho de Domnio relatando o resultado da mesma. No caso do Especialista ser um agente mvel, a comunicao pode se dar apenas ao final do caminho percorrido pelo mesmo, caso a ao assim o exija, ou, em caso contrrio, ao final de cada ao realizada. Aps envio do relatrio, ao Gerente de Desempenho de Domnio, o Especialista pode migrar ou se encerrar.
3.3.5. Protocolo de comunicao para o gerenciamento de desempenho

A comunicao que ocorre entre os elementos relacionados ao gerenciamento de desempenho se limita a apenas duas situaes: (i) entre o Gerente de Desempenho de Domnio e o Inspetor de Desempenho, e (ii) entre o Especialista e o Gerente de Desempenho de Domnio.

41 O formato das mensagens est apresentado na Figura 13. Esse formato de mensagem uma extenso do formato previsto na AGAD [19]. Os tamanhos dos campos esto mostrados em caracteres (bytes).
Mensagem Parte fixa Parte varivel Elementos de informao 1 char 4 1 1 char 1 Varivel

....
Contedo do elemento de informao Tipo do elemento de informao Nmero de elementos de informao

Tipo da mensagem Endereo da origem Tipo do elemento da origem

Figura 13 - Formato das mensagens do protocolo de comunicao da AGAD

O campo Tipo do Elemento da origem informa se a mensagem oriunda de um Gerente de Desempenho de Domnio, Inspetor de Desempenho ou Especialista. Cada mensagem pode ser composta por quantos Elementos de Informao forem necessrios. Cada elemento de informao transporta uma informao especfica, sendo que a sua composio varivel. O primeiro campo indica qual o elemento de informao e os demais transportam as informaes propriamente ditas. Os elementos que no forem reconhecidos por uma verso de cdigo so ignorados. Maiores detalhes sobre os campos do protocolo podem ser encontrados em [19].
3.3.6. O desempenho do gerenciamento de desempenho pr-ativo

esperado que a utilizao de linguagens como Java, bem como a presena de uma infraestrutura de mobilidade baseada tambm nessa linguagem, venham a causar impactos no desempenho da arquitetura de gerenciamento de desempenho que proposta nesse trabalho. No entanto, uma vez que a evoluo da capacidade de processamento constante e o desenvolvimento de processadores que executam Java ou linguagens similares est cada vez mais prximo de se tornar uma realidade prtica [47], [48], a pesquisa de tal abordagem de gerenciamento de desempenho justificada. Um detalhamento das camadas de processamento que podem existir na implementao da arquitetura que proposta nesse trabalho apresentado na Figura 14. Nem sempre, no entanto, todas as camadas sero necessariamente utilizadas. Quando o cdigo do Especialista, por exemplo, estiver disponvel em linguagem compilada para a plataforma na qual o mesmo dever agir, algumas camadas de processamento no sero utilizadas no momento da execuo desse Especialista.

42

Elemento (Thread) Thread)

API Infra-estrutura InfraSNMP de mobilidade Mtodos da API Java JVM Mtodos nativos Sistema operacional Hardware

Figura 14 - Camadas de processamento existentes na arquitetura sendo proposta

O elemento da Figura 14 simboliza qualquer componente da arquitetura de gerenciamento de desempenho: Gerente, inspetor ou Especialista. Algumas medies sobre o desempenho do funcionamento da arquitetura usando essas camadas de processamento sero apresentadas no captulo referente aos testes e anlise dos resultados, quando ento poder-se- ter uma idia do impacto causado pela presena das mesmas. 3.4. Aplicaes do gerenciamento de desempenho pr-ativo Nesta seo sero apresentadas algumas possveis aplicaes da arquitetura de gerenciamento de desempenho pr-ativo no gerenciamento dos diversos elementos citados na Figura 6, ou seja, aplicaes, servios de comunicao, estaes de trabalho, ns de comutao e enlaces de comunicaes. Sero tambm discutidas as vantagens e desvantagens de seu uso.
3.4.1. Adaptao em aplicaes

Aplicaes adaptativas vm sendo pesquisadas [27], [28] com o intuito de que as mesmas venham a manter um certo nvel de QoP de uma dada apresentao, ainda que com declnio da QoS disponvel, principalmente na rede, mas tambm nos servidores, conforme ser melhor detalhado na seo 3.4.3. No caso de aplicaes multimdia distribudas, a adaptao envolve processamento tanto no cliente quanto no servidor de uma apresentao. No caso de uma mesma mdia estar disponvel em diversas verses, com diferentes exigncias de trfego e de processamento, suficiente que o servidor detecte uma falha de QoS para realizar a troca (adaptao) de verso da mdia em questo. No caso de no haver uma verso menos exigente de QoS da mdia para a qual ocorreu a falha de QoS, tanto o cliente quanto o servidor tm que realizar processamento na adaptao. O cliente tem que reestruturar a apresentao de forma a exigir outras mdias em substituio quelas que falharam, mas mantendo a coerncia da apresentao que estava sendo realizada.

43 Aps essa reestruturao, o servidor ou os servidores das mdias da apresentao em questo tm que ser acionados para que passem a fornec-las quele cliente. O gerenciamento de desempenho pr-ativo nesse caso pode monitorar as tendncias de comportamento dos parmetros de QoS dos fluxos das mdias da apresentao e enviar Alarmes de Tendncia caso as mesmas ultrapassem certos limites. O Gerente de Desempenho de Domnio envia Especialistas tanto para o cliente quanto para o servidor, para que os respectivos processamentos necessrios adaptao possam ser adiantados. As conseqncias desse adiantamento podem ser, no pior caso, um ganho de tempo na prpria execuo da adaptao, minimizando o tempo de interrupo da mdia em questo, caso a falha da mesma venha de fato a ocorrer. No melhor caso, a adaptao pode ser realizada com um mnimo de prejuzo para a apresentao, sem que venha a ocorrer uma falha de QoS. Os usurios perceberiam apenas, por exemplo, a troca de verso da mdia, com a ocorrncia de uma interrupo mnima. Uma abordagem alternativa o envio dos Alarmes de Tendncia diretamente s aplicaes, com o objetivo de se poupar o tempo referente ao processamento de anlise e classificao no Gerente de Desempenho de Domnio.
3.4.2. Mudana de rotas em servios de comunicao

As redes IP podem obter proveito das facilidades de comutao baseada em rtulos [49] disponvel em tecnologias de nvel de enlace, como ATM e Frame Relay, ou mesmo em tecnologias de acesso mltiplo e compartilhado como Ethernet, atravs do uso de um shim header [50]. Circuitos virtuais so criados em nvel de enlace e os pacotes IP so ento encaminhados apenas com base nas informaes dos rtulos, sem que seja necessrio o processamento em nvel de rede em cada n de comutao. MPLS [45] um exemplo de tecnologia que se utiliza dessa tcnica, que ilustrada na Figura 15. A atualizao dos circuitos virtuais em nvel de enlace no MPLS feita, normalmente, com base nas informaes de controle de nvel IP, ou seja, nas informaes oriundas dos protocolos de roteamento, como RIP, RIP-II, OSPF e BGP, entre outros [50]. A freqncia dessa atualizao a mesma da troca de informaes desses protocolos, ou seja, na ordem de 30 segundos ou superior.

44
Tabela da porta 2 de A Rtulo de Porta de Rtulo de entrada Sada sada ... ... ... 35 6 49 2

C
3 5 49 6 33 6 4 7 7 8 1

Tabela da porta 4 de B Rtulo de Porta de Rtulo de entrada sada Sada ... ... ... 49 7 33 3

A 4

35

Rede baseada em comutao de rtulos

Figura 15 - Rede IP com comutao de rtulos em nvel de enlace

Um sistema de gerenciamento de desempenho pr-ativo pode, ao detectar a tendncia da ocorrncia de uma falha de QoS em um determinado fluxo, desencadear, via um Especialista, a atualizao das tabelas de rtulos dos roteadores-comutadores de forma que uma nova rota seja criada para aquele fluxo. Nesse caso, o Especialista poderia ser um agente mvel para percorrer a rota de um circuito virtual. Usando ainda a Figura 15 como referncia, um agente poderia percorrer o caminho A-C-D e alterar as tabelas de rtulos desses roteadores-comutadores para que um novo circuito virtual fosse criado e passasse a ser a rota para o fluxo de dados existente entre as duas estaes. O Especialista tem que ser enviado para fazer este trabalho j de posse da nova rota para a qual o circuito virtual ser criado. Isso exige que o Gerente de Desempenho de Domnio tenha conhecimento das rotas de seu domnio. Tal funcionalidade tem que ser obtida do Sistema de controle de trfego em tempo real, de acordo com o que foi apresentado no incio deste captulo. O tratamento individualizado de fluxos se caracteriza por ser uma soluo pouco escalvel. requerida ento uma poltica de gerenciamento que limite a quantidade desses tratamentos individualizados. Em nvel domnio, no entanto, podem ser escolhidos apenas aqueles fluxos que so crticos e para os quais se justifique esse tipo de tratamento.
3.4.3. Utilizao de recursos em estao de trabalho

Os sistemas de gerenciamento atuais concentram a maior parte de seus esforos na monitorao e controle das redes. As estaes, no entanto, quer sejam clientes ou servidoras, podem ser responsveis por falhas de QoS. Basta um servidor de vdeo atender a uma quantidade de solicitaes de envio de fluxos que exceda sua capacidade de processamento e/ou de memria para que ocorram uma ou mais falhas de QoS, que certamente sero percebidas pelos clientes. necessrio ento o gerenciamento do desempenho tambm das estaes, principalmente daquelas que hospedam servidores.

45 O gerenciamento de desempenho pr-ativo pode realizar o monitoramento dos valores dos parmetros capacidade de CPU e de memria utilizada (via MIB ou atravs de chamadas ao sistema) e quando estes valores excederem limite configurado pelo Gerente de Desempenho de Domnio, um Alarme de Tendncia enviado quele Gerente. Este ento pode enviar um Especialista que, de acordo com o tipo de estao, analise os processos e/ou threads em execuo e encerre aqueles que no sejam essenciais. As aplicaes crticas podem tambm ser avisadas para que passem a realizar um controle de admisso mais estrito, limitando a aceitao de novos pedidos de fornecimento de fluxos. Esse trabalho exige Especialistas dedicados para cada tipo de estao, de forma que sejam conhecidos quais processos e/ou threads so essenciais ou crticos. No entanto, no mbito de um nico domnio, no se espera que exista uma quantidade grande de estaes que executem aplicaes crticas ao ponto de tornar o gerenciamento pr-ativo em um problema intratvel.
3.4.4. Alterao de poltica de escalonamento de pacotes em ns de comutao

As mesmas monitoraes e aes referentes s estaes so aplicveis tambm para os ns de comutao pois, em termos de hardware e software, so similares s estaes, talvez apenas menos genricos. No caso da utilizao de tecnologia ativa em ns de comutao, por exemplo, a monitorao da capacidade de processamento e/ou de memria disponvel pode vir a ser crticas, pois diversos agentes mveis Inspetores de Desempenho, Especialistas ou outros tipos de agentes podem estar sobrecarregando o n at mesmo sem serem necessrios, prejudicando a atividade principal em questo, que de encaminhar ou rotear pacotes. Adicionalmente em relao s estaes, em um n de comutao (roteador, comutador ou ambos), congestionamentos nos enlaces de sada podem previstos atravs do monitoramento das suas filas de sada. Nesse caso, a alterao da poltica de escalonamento de pacotes no atendimento das filas de sada uma das aes possveis de serem desencadeadas com o objetivo de se evitar a ocorrncia de falhas de QoS nos fluxos afetados por essas filas. Outra possvel ao a implementao de diferentes polticas de descarte seletivo de pacotes, em funo da variao da quantidade de pacotes nas filas e/ou da variao do tempo de espera dos pacotes nas filas. As polticas utilizadas com esses fins, tanto para o escalonamento quanto para o descarte, so, normalmente, definidas por configurao manual feita nos roteadores e/ou comutadores, sendo, portanto, estticas.
3.4.5. Alterao de protocolos em enlaces de comunicaes

Em nvel enlace de comunicaes, uma possvel aplicao do gerenciamento de desempenho pr-ativo a monitorao da taxa de erros no meio fsico que utilizado por aquele enlace. Em

46 funo da variao das taxas de erros e de perdas, monitorada por um Inspetor de Desempenho, pode ser feita a modificao dos algoritmos de deteco e correo de erros que esto sendo utilizados. Um retardo adicional seria introduzido, porm, a forma tradicional de se lidar com erros acontecidos no nvel fsico, pelo menos em tecnologias de comutao rpida de pacotes, como ATM e Frame Relay, quase sempre a deteco e/ou correo de erros fim a fim, o que, certamente, impe um retardo maior no servio de comunicaes que est sendo prestado, caso ocorram erros, pois sero necessrias retransmisses. Uma outra aplicao do gerenciamento de desempenho pr-ativo em nvel enlace de comunicaes a alterao, de acordo com as variaes detectadas por um Inspetor de Desempenho, do tipo de servio que deve ser implementado por um protocolo de nvel 2, ou mesmo a alterao do protocolo a ser utilizado. A troca de um servio sem conexo e sem reconhecimento por um servio sem conexo e com reconhecimento, por exemplo, pode ser feita, caso estejam ocorrendo colises fora da banda em um meio fsico compartilhado baseado em Ethernet. 3.5. Trabalhos relacionados A distribuio do processamento, transferindo parte do processamentos do servidor de gerenciamento, como nas abordagens CMIP e SNMP, para prximo aos dados necessrios ao gerenciamento, ou seja, para os prprios elementos a serem gerenciados, tm sido pesquisada desde o surgimento de abordagens padronizadas de gerenciamento. O trabalho de Yemini [17] destacou o conceito pela primeira vez. A primeira gerao de sistemas de gerenciamento distribudo utilizava basicamente o paradigma cliente-servidor. A segunda gerao usa RPC ou a distribuio esttica de objetos, como CORBA e Java RMI para a distribuio das tarefas. As pesquisas atuais, configurando uma terceira gerao, concentram-se no emprego de tecnologia ativa para a implementao da distribuio no gerenciamento [4]. A maioria dos trabalhos que foram publicados usam tecnologia ativa, porm, no implementam o gerenciamento pr-ativo. O trabalho consultado que emprega uma abordagem pr-ativa no se utiliza de tecnologia ativa. Smart Packets [13] utiliza o paradigma de redes ativas. Um protocolo especfico utilizado, o Active Network Protocol (ANEP), para a transferncia do programas que no podem exceder 1 KB. A proteo ao n ativo forte, tendo sido implementada uma linguagem de alto nvel, Sprocket, que no dispe de ponteiros, no realiza o acesso a arquivos e nem faz gerenciamento de memria, que so aes potencialmente problemticas. Um programa em Sprocket compilado em outra linguagem, Spanner, com o objetivo de minimizar o tamanho do programa a ser transmitido na rede. Um ambiente de execuo capaz de executar programas Spanner est pre-

47 sente em cada n ativo. Um esquema de segurana realiza a autenticao dos programas a serem executados nos ns ativos. O paradigma de mobilidade no utilizado. A arquitetura Active Distributed Management (ADM) [10] organizada em trs camadas: gerenciamento de processos, bsica de operao e ferramentas de gerenciamento. A primeira o ambiente de execuo, provendo as funcionalidades de redes ativas e de mobilidade, disponibilizando funes para criao, remoo, interrupo, continuao, duplicao, movimentao, comunicao, servios de diretrio e de segurana. A camada de bsica de operao disponibiliza padres de navegao para os fragmentos de cdigo ativo (da terceira camada) que de fato realizam tarefas de gerenciamento. Na terceira camada so implementadas as funes relativas ao gerenciamento propriamente dito, na forma das aplicaes ativas. A linguagem utilizada Java. O projeto MIAMI [1] implementa o gerenciamento de desempenho com o uso de trs agentes, dois estticos e um mvel. O primeiro, esttico, realiza a interface entre o gerenciamento de desempenho e o sistema de gerenciamento. Este agente, quando ordenado, cria um agente mvel e o envia a um elemento de rede para que execute tarefas de monitoramento e de consolidao localmente. Um terceiro agente, esttico, serve como agente proxy, realizando a interface entre o agente mvel e o elemento a ser gerenciado. O agente mvel envia informaes consolidadas ao primeiro agente esttico periodicamente ou assincronamente, quando limites configurados para parmetros de desempenho forem ultrapassados. A linguagem utilizada tambm Java. Francheschi [24] investigou o gerenciamento pr-ativo utilizando tcnicas de inteligncia artificial para a gerao de alarmes. Um mdulo (equivalente a um agente de gerenciamento SNMP) pr-ativo carregado no elemento gerenciado contendo um servio de verificao que se utiliza de IA. Este servio obtm valores dos parmetros gerenciados via RMON, compara-os com dados do baseline do elemento gerenciado e, aps verific-los, se for o caso, emite alarmes de tendncia 3.6. Resumo do captulo Esse captulo diferenciou, inicialmente, o sistema de gerenciamento de desempenho, do sistema de controle de trfego em tempo real. O primeiro sistema apenas monitora e determina aes sobre os parmetros de controle do trfego que so, de fato, controlados pelo segundo sistema. Na seo seguinte, a arquitetura AGAD, sobre a qual o sistema proposto executado, resumida. Em seguida, apresentada a arquitetura de um sistema de gerenciamento de desempenho pr-ativo que engloba no s a rede, como tambm servios, aplicaes e estaes de trabalho. Na seo seguinte, so detalhados os elementos integrantes do sistema e o seu funcionamento.

48 As possibilidades de aplicao da arquitetura proposta no gerenciamento de aplicaes, servios de comunicao, ns de comutao, estaes e enlaces so tambm discutidas. Por fim, os trabalhos relacionados so comentados.

49

Captulo 4 - Ambiente e implementao

Nesse captulo ser detalhado o ambiente de desenvolvimento que foi escolhido, bem como as razes que levaram a sua escolha e as vantagens e desvantagens decorrentes do seu uso. Tambm ser detalhada a implementao de um prottipo da arquitetura de Gerenciamento de Desempenho Pr-Ativo (GDPA) composto de um Gerente de Desempenho de Domnio, um Inspetor de Desempenho e um Especialista de Desempenho que foram utilizados para a realizao dos testes que sero descritos no prximo captulo. 4.1. Ambiente de desenvolvimento O ambiente de desenvolvimento que foi escolhido tem como plataformas computadores pessoais (PC) com sistema operacional aberto Linux da distribuio de verso 7.2 da Red Hat [46] com kernel 2.4.7-10 e como linguagem de programao, Java (JDK) [32], em sua verso 1.3.1 . Essa infra-estrutura foi escolhida por utilizar softwares gratuitos e baseados em Java, que independente de plataforma. Por terem sido utilizadas plataformas com diferentes capacidades de processamento e configuraes de hardware, as mesmas sero detalhadas no captulo referente aos testes que foram realizados. O sistema de gerenciamento de desempenho pr-ativo integra-se AGAD, conforme j foi citado, e esta tambm se utiliza do mesmo ambiente de desenvolvimento. A infra-estrutura de rede era baseada em Fast Ethernet compartilhada. Em alguns testes, conforme ser explicado no prximo captulo, foram usados segmentos Ethernet de 10 Mbps. A tecnologia de rede foi escolhida de forma que representasse a tecnologia mais disponvel atualmente. A seguir sero apresentadas a infra-estrutura de mobilidade utilizada, o Code [41], e a interface usada para programao de aplicaes em Java para a implementao de gerenciamento baseada no padro SNMPv1 [43].
4.1.1. Infra-estrutura de mobilidade

A infra-estrutura utilizada o Code [41], que prov a mobilidade fraca, segundo a taxonomia de mobilidade de cdigo de Fuggeta [40]. O ambiente da infra-estrutura baseado na presena de servidores, denominados Servers, sendo executados sobre mquinas virtuais Java (JVM) em cada plataforma. Um Server um ambiente computacional para threads mveis, que quando migram mantm seu estado referente aos dados, mas no seus estados de execuo, da a mobilidade implementada ser classificada como fraca. As operaes bsicas disponibilizadas pelos

50 Servers so a criao remota de threads, a cpia de threads e a relocao tanto de um conjunto de classes quanto do fechamento de uma classe, ou seja, a prpria classe e todas que so por ela invocadas. A execuo do cdigo que enviado pode se dar de forma sncrona ou assncrona e com a execuo imediata, na chegada do cdigo, ou no (retardada). Essa infra-estrutura de mobilidade implementada sobre a JVM na forma de uma camada simples, que no requer processamento adicional significativo em relao mquina virtual. A unidade de migrao um grupo, que um conjunto de classes e objetos. Classes individuais ou o fechamento de uma classe podem ser adicionadas a um grupo. O uso do fechamento de uma classe faz com que no seja mais necessria nenhuma busca plataforma de origem. As threads geradas a partir de classes recebidas so mantidas em um espao de classes privado, de forma a se evitar conflitos de nomes com outras classes locais. possvel, no entanto, publicar-se classes em um espao de classe compartilhado associado ao Server, de forma que as mesmas possam ser acessadas por outras classes do prprio Server ou de Servers remotos. A programao com o Code realizada utilizando-se trs nveis de abstrao: o ncleo, composto pelas classes Group e ClassSpace e pelas interfaces GroupHandler e Mobile; o nvel intermedirio, formado pela classe MuServer e o nvel do usurio, que formado pelas abstraes que foram implementadas pelo programador. A programao em nvel de usurio feita usandose as primitivas disponveis no nvel intermedirio, que poupa o programador de usar as primitivas de mais baixo nvel de abstrao que esto presentes no ncleo. O Code foi escolhido como infra-estrutura de mobilidade em funo da baixa complexidade no seu uso, da sua simplicidade por exigir poucos processos e poucas threads em execuo e, principalmente, da fina granularidade disponibilizada para a mobilidade de cdigo, alm de ser gratuito. possvel se enviar desde um simples objeto at o fechamento de uma classe.
4.1.2. Interface de programao de aplicaes de Gerenciamento

Foi utilizada uma interface para programao de aplicaes em Java, para implementao de gerenciamento baseada no padro SNMPv1, da empresa AdventNet, em sua verso 3.3 [43]. O daemon SNMP que foi usado aquele instalado pelo Red Hat 7.2, que do pacote UCD-SNMP v4.2.1-7 [44]. Essa API foi escolhida por ser gratuita e oferecer um alto grau de encapsulamento, em Java, dos detalhes referentes interao com agentes SNMP.

51 4.2. Implementao realizada A apresentao da implementao que foi realizada ser feita com o auxlio da Unified Model Language (UML) [42], para que sejam descritos os principais casos de uso, o modelo conceitual, os diagramas de seqncia e a hierarquia de classes do prottipo. O enfoque da implementao, conforme ser visto na prxima seo, referente aos testes realizados, foi sobre o Inspetor de Desempenho. A principal razo para a adoo desse enfoque foi o desejo de se investigar a viabilidade de se realizar tarefas de gerenciamento com fina granularidade de tempo utilizando-se uma linguagem de alto nvel e parcialmente interpretada, como Java, juntamente com uma infra-estrutura de mobilidade, tambm baseada em Java. O prottipo implementado composto por trs componentes de software, um Gerente de Desempenho de Domnio, um Inspetor de Desempenho e um Especialista de Desempenho. Conforme j foi citado, foi deixada fora do escopo dessa dissertao a explorao de tcnicas de anlise dos dados obtidos do Inspetor de Desempenho que feita pelo Gerente de Desempenho de Domnio, bem como da anlise e extrapolao de variaes originadas nos Alarmes por este ltimo elemento para a seleo de Especialistas. O Gerente de Desempenho de Domnio implementado trata somente da recepo de um alarme e do envio de um Especialista prdeterminado. J o Inspetor de Desempenho que foi implementado totalmente funcional, realizando tudo que foi previsto na Seo 3.2.1. A utilizao do prottipo (daquelas que foram citadas na seo 3.4) escolhida para a realizao dos testes, descritos no prximo captulo, o gerenciamento de desempenho que realizado em benefcio de uma aplicao adaptativa, que o ServiMdia [28]. Nesse caso, o parmetro mais relevante a ter o seu desempenho gerenciado o retardo entre a transmisso, pelo servidor, e a recepo, pelo cliente, dos pacotes que contm o vdeo e o udio de uma apresentao multimdia. Assim, o prottipo implementado trata do monitoramento deste parmetro de controle, o retardo. Quanto ao desencadeamento de aes, duas opes so consideradas: a tradicional, onde o envio do Alarme de Tendncia feito para o Gerente de Desempenho de Domnio e uma alternativa, onde o Alarme enviado diretamente aplicao.
4.2.1. Casos de Uso do prottipo

Os requisitos exigidos do prottipo que foi implementado podem ser entendidos com o auxlio dos Casos de Uso [42] apresentados a seguir, que mostram os principais processos implementados. Cabe destacar que os atores dos casos de uso so sempre entidades externas ao prottipo, como, por exemplo, o Gerente Mor, o Gerente de Domnio, o Inspetor, todos da AGAD. Caso de Uso: Iniciar a monitorao de um parmetro de controle.

52 - Atores: Gerente de Domnio (iniciador) e Inspetor. - Finalidade do Caso de Uso: Capturar a inicializao de um Inspetor de Desempenho para o monitoramento de um parmetro de controle. - Viso geral: O Gerente de Domnio inicia o Gerente de Desempenho de Domnio e, de acordo com a configurao determinada pelo administrador da rede, envia um Inspetor de Desempenho a um elemento gerenciado para monitorar o retardo de um fluxo de vdeo recebido por um cliente ServiMdia. O elemento gerenciado j deve possuir um Inspetor (da AGAD) em execuo. - Seqncia de eventos:
Ao do ator 1. O gerenciador do sistema determina o parmetro de controle a ser monitorado, identifica o elemento gerenciado onde esse parmetro ser monitorado e determina os limites das variaes para o envio de Alarmes de Tendncia que foram descritos na seo 3.2.1, a freqncia de monitoramento e para quem devem ser enviados os Alarmes. Resposta do prottipo 2. O Gerente de Desempenho de Domnio iniciado, recupera o cdigo do Inspetor de Desempenho apropriado e inicializa (ou atualiza, caso j tenham sido inicializadas) as Bases de Informaes que so necessrias ao gerenciamento de desempenho, BCD, BCN e BICD.

4. O Inspetor recebe o Inspetor de Desempenho e o instancia.

3. O Inspetor de Desempenho, configurado com os valores j citados no evento 1, enviado para o Inspetor do elemento gerenciado em questo, via infra-estrutura de mobilidade. 5. Inspetor de Desempenho inicia a sua execuo, registrando seus mtodos no Inspetor e apresentando-se aplicao adaptativa para a qual monitorar o retardo. 6. Inspetor de Desempenho inicia, se for necessrio, o proxy do parmetro de controle para poder obter valores do mesmo. 7. Inspetor de Desempenho inicia o monitoramento do parmetro retardo.

Caso de Uso: Monitorar um parmetro de controle. - Atores: Sistema operacional (iniciador) e parmetro retardo do sistema de controle. - Finalidade do Caso de Uso: Capturar o monitoramento do comportamento do retardo. - Viso geral: Obter o valor do retardo com a freqncia configurada, calculando a sua variao e, de acordo com os limites pr-determinados, decidir pelo envio de um Alarme de Tendncia. - Seqncia de eventos:

53

Ao do ator 1. Sistema operacional desbloqueia o Inspetor de Desempenho, aps um intervalo de tempo equivalente freqncia configurada para a monitorao do retardo.

Resposta do prottipo 2. Inspetor de Desempenho obtm valor atual do parmetro retardo.

3. A variao desde a ltima observao feita calculada e armazenada na Base de Informaes Temporrias. 4. O valor da variao comparado com o valor mximo da mesma que permitida entre duas observaes consecutivas. tomada a deciso de se enviar ou no um Alarme de Tendncia. 5. A variao acumulada calculada e comparada com o seu valor mximo que permitido. tomada a deciso de se enviar ou no um Alarme de Tendncia. 6. O valor do retardo comparado com o limite mnimo a partir do qual devem ser desencadeados Alarmes. Se havia sido decidido o envio de um Alarme de Tendncia, o mesmo enviado. 7. As informaes necessrias so armazenadas na Base de Informaes Permanentes.

Caso de Uso: Desencadear ao com o uso de Especialista de Desempenho. - Atores: Retardo, Gerente de Domnio (iniciador), Inspetor. - Finalidade do Caso de Uso: Capturar o tratamento de um Alarme de Tendncia com o uso de um Especialista de Desempenho. - Viso geral: O Gerente de Domnio, aps anlise do Alarme de Tendncia recebido recupera e envia o Especialista apropriado ao elemento gerenciado. - Seqncia de eventos:
Ao do ator 1. Sistema operacional desbloqueia o Inspetor de Desempenho, aps um intervalo de tempo equivalente freqncia configurada para a monitorao do retardo. Resposta do prottipo 2. Inspetor de Desempenho realiza o que est previsto nos eventos 2 a 7 no caso de uso anterior, enviando o Alarme de Tendncia ao Gerente de Desempenho de Domnio. 3. O Gerente de Desempenho de Domnio recebe um Alarme de Tendncia e o analisa, escolhendo o Especialista apropriado e decidindo para qual elemento gerenciado envi-lo.

4. Gerente de Desempenho de Domnio recupera o cdigo do Especialista selecionado e, via infra-estrutura de mobilidade, o envia ao elemento gerenciado. 5. O Inspetor (da AGAD) do elemento gerenciado recebe o cdigo do Especialista e o instancia.

6. O Especialista inicia a sua execuo.

Caso de Uso: Enviar Alarme de Tendncia diretamente aplicao.

54 - Atores: Retardo, Aplicao Adaptativa. - Finalidade do Caso de Uso: capturar a comunicao Aplicao Adaptativa da ocorrncia de um Alarme de Tendncia de variao do retardo. - Viso geral: O Inspetor de Desempenho comunica, diretamente Aplicao, a ocorrncia do Alarme de Tendncia. - Seqncia de eventos:
Ao do ator 1. Sistema operacional desbloqueia o Inspetor de Desempenho, aps um intervalo de tempo equivalente freqncia configurada para a monitorao do retardo. Resposta do prottipo 2. Inspetor de Desempenho realiza o que est previsto nos eventos 2 a 7 no caso de Monitorar Parmetro de Controle, sem enviar o Alarme de Tendncia ao Gerente de Desempenho de Domnio. 3. Inspetor de Desempenho comunica Aplicao, diretamente, a ocorrncia do Alarme de Tendncia, passando o valor do retardo bem como a variao eu foi excedida e causou o Alarme.

4.2.2. Modelo Conceitual do prottipo

Os principais objetos do prottipo, as suas associaes e os seus principais atributos podem ser visualizados no Modelo conceitual [42] que apresentado na Figura 16.
Gerente de Domnio
Cdigos de EspeEspecialistas

Especialista Envia 1
Destino Instancia Ao a ser realizarealiza1..* 1..* da

Inspetor 1 1

1 Inicia 1 Gerente de Domnio de Desempenho

Informaes sobre Inspetores de Desempenho

Iniciado Alarme de Tendncia Analisa 1

Timestamp Valor da observaobserva1..* 1..* o Variao

1 Inspetor de Desempenho Envia

Limite para envio de alarmes 1 Limites mximos 1 para a variao Ordem monitorar Informaes temtemporrias Informaes perpermanentes

Parmetro de Controle Monitora 1

Freqncia de observao

1..*

Extrapola

Recebe 1 Aplicao Adaptativa 1

1 Registra-se Registra-

Figura 16 - Modelo conceitual do prottipo

4.2.3. Diagramas de Seqncia do prottipo

Os Diagramas de Seqncia apresentados a seguir descrevem as interaes que ocorrem entre os objetos do prottipo. O primeiro diagrama (Figura 17) ilustra o incio do gerenciamento de de-

55 sempenho. A seqncia de mensagens trocadas na monitorao do parmetro de controle, juntamente com o uso de um Especialista para o desencadeamento de aes est apresentada no segundo diagrama (Figura 18). O envio do Alarme de Tendncia diretamente para a aplicao adaptativa pode ser deduzido com facilidade a partir deste ltimo diagrama e, portanto, no ser apresentado.
:GerenteDomnio
New :GerenteDomnio [Ordem do Gerenciador] DeDesempenho RecupereInspetorDeDesempenho( Limites, Freqncia ) RecupereInspetorDeDesempenho( EnvieInspetorDeDesempenho( ) EnvieInspetorDeDesempenho( Recuperar Cdigo( ) ExecuteInspetorDeDesempenho( ) ExecuteInspetorDeDesempenho( New [NoHCdigo InspDesempenho] InspDesempenho]

:Inspetor

:AplicaoAdapt ativa

:InspetorDeDeInspetorDeDesempenho

RegistrarMtodos Atualizveis( ) Registrar-se ( ) Registrar-

Figura 17 - Diagrama de Seqncia Iniciar monitoramento de parmetro de controle

O objeto ProxyParmetroControle do diagrama apresentado a seguir quem realiza a interao com o sistema de controle em tempo real para a obteno do valor do parmetro no momento desejado. No prottipo implementado, esse objeto instanciado a partir da API de gerenciamento SNMP que utilizada para a obteno de valores de variveis de MIB.

56
:InspetorDeDeInspetorDeDesempenho :ProxyParmetro Controle

:GerenteDomnio

:Inspetor

FornecerValor ( ) Valor Calcular Variaes( ) Analisar Alarme( ) Recuperar Especialista( ) RecupereEspecialista( ) RecupereEspecialista( EnvieEspecialista( ) EnvieEspecialista( ExecuteEspecialista( ) ExecuteEspecialista( New [NoHCdigo Especialista] [LimiteExcedido] LimiteExcedido]

:Especialista

ArmazeneRelatrioAo( ) ArmazeneRelatrioAo(

X
Figura 18 - Diagrama de Seqncia de Monitorao e de ao com o uso de Especialista

4.2.4. Hierarquia de Classes do prottipo

Sero apresentadas de forma mais detalhada, conforme pode ser observado na Figura 19, apenas as classes do prottipo que foi implementado. As classes da AGAD que so relevantes ao entendimento do prottipo so tambm mostradas, porm, sem maiores detalhes.

57
MuServer
... ...

RS:ResourceServer 1 RS:ResourceServer ... ... 1 1 1 1 1 InspetorBsico ... ... 1..N Inspetor (abstract) abstract) ... Registrar( ) TtratarMsgGD( ) TtratarMsgGD( Monitorar( ) Finalizar( ) Finalizar( EnviarMensagem( ) EnviarMensagem(

1 ... ...

ResourceServer

1 GerDomnioBsico ... ...

1 GerDom (abstract) abstract) ... ClassifEspecialista( ) ClassifEspecialista( EnviarEspecialista( ) EnviarEspecialista( Finalizar( ) TratarMsgnsp( ) TratarMsgnsp( TratarMsgGDB( ) TratarMsgGDB( EnviarMsgACK( ) EnviarMsgACK(

InspDesemp
... DeterminarLimites( ) DeterminarLimites( ObterInform( ) ObterInform( IniciarMonitorao( ) IniciarMonitorao( EnviarMsgUrgente( ) EnviarMsgUrgente( 1 1 1 1

GerDomDesemp
... InciciarGerDesemp( ) InciciarGerDesemp( FinalizarGerDesemp( ) FinalizarGerDesemp( ObterInform( ) ObterInform( 1 0 .. N

SNMPGet
... Configura( ) ObterValor( ) ObterValor(

ProxyGet (Abstract) Abstract)

... Configurar( ) ObterValor( ) ObterValor( Finalizar( )

EspecialistaDesemp
... Configurar( ) Agir( ) Finalizar( )

ObterRetardo
...

EspecialistaDesemp
... ...

Figura 19 - Diagrama de Classes do prottipo

Apenas a classe do principal elemento do prottipo, o Inspetor de Desempenho, ter os seus mtodos descritos com maiores detalhes. Classe InspDesemp: o Mtodo Registrar: herdado da AGAD. Registra a instncia da classe junto ao Inspetor (da AGAD) para fins de atualizao de cdigo. o Mtodo TratarMsgGD: herdado da AGAD. Realiza o tratamento das mensagens que so recebidas do Gerente de Desempenho Mor via AGAD. o Mtodo Monitorar: herdado da AGAD. Implementa o lao de monitorao do Inspetor de Desempenho, cujo funcionamento foi explicado na seo 3.2.1. O pseudo-cdigo deste mtodo est apresentado na prxima seo (4.2.5). A monitorao, de fato, no iniciada quando este mtodo chamado. Outro mtodo usado com essa finalidade.

58 o Mtodo Finalizar: herdado da AGAD. Permite a finalizao da instncia da classe, quer seja por encerramento das atividades do Inspetor de Desempenho ou para que o mesmo seja atualizado. o Mtodo EnviarMensagem: herdado da AGAD. Permite o envio de mensagens no urgentes. Essas mensagens so enviadas com o uso das facilidades de comunicao da AGAD. o Mtodo DeterminarLimites: Permite a determinao dos limites que podem ser configurados no Inspetor de Desempenho. Os limites, que so os parmetros do mtodo, so aqueles explicados na seo 3.2.1. Esse mtodo pode ser usado durante a execuo do Inspetor para que os valores dos limites sejam alterados. o Mtodo IniciarMonitorao: Permite o desencadeamento e a interrupo do lao de monitorao. o Mtodo ObterInform: Permite que as informaes referentes monitorao, ou seja, os valores dos parmetros ao longo do tempo, as variaes dos mesmos e os alarmes que foram enviados e as estampas de tempo sejam recuperadas pelo Gerente de Desempenho de Domnio. o Mtodo EnviarMsgUrgente: Permite o envio de mensagens diretamente ao Gerente de Desempenho de Domnio. usado para o envio de Alarmes de Tendncia.
4.2.5. Implementao do Inspetor de Desempenho

As diferentes monitoraes que devem ser realizadas por um Inspetor de Desempenho em um determinado elemento gerenciado devem ser implementadas em diferentes threads, de forma a simplificar os controles dos tempos de intervalo entre a obteno de observaes consecutivas dos valores dos parmetros de controle. Isso significa que deve haver uma thread para o monitoramento de cada parmetro de controle. Estas devem ser as threads de maior prioridade do Inspetor de Desempenho. Tarefas como armazenamento de dados em memria secundria e envio de mensagens de rotina podem ser realizadas por threads de menor prioridade. As diferentes threads do Inspetor de Desempenho que realizam o monitoramento dos diferentes parmetros de controle devem ter seu cdigo desenvolvido especificamente para o comportamento do parmetro em questo, visando minimizar o seu tempo de execuo. O exemplo j apresentado na seo 3.2.1 continuar a ser usado nesta seo, para visualizao da implementao do prottipo.

59 Os parmetros passados para o construtor do Inspetor de Desempenho incluem aqueles que foram explicados na seo 3.2.1, (i) o limite mnimo para o envio de Alarmes (ThresholdValue), (ii) a variao mxima tolerada em um intervalo entre medies sucessivas (MaxOneSleepVariationLimit) e (iii) a variao acumulada mxima tolerada (MaxAccumulatedVariationLimit) e acrescenta outros valores relevantes: (iv) o intervalo a ser aguardado entre a obteno de dois valores consecutivos do parmetro monitorado (SleepInterval) e (v) uma ordem para que seja determinado se o Inspetor de Desempenho j deve iniciar sua execuo realizando a monitorao (BeginMonitoring). O diagrama da classe Inspetor de Desempenho apresentada na Figura 20.
class PerformanceInspector extends Thread { public PerformanceInspector ( String Name, int ThresholdValue, int MaxOneSleepVariationLimit, int MaxAccumulatedVariationLimit, int SleepInterval, boolean BeginMonitoring ) public void BeginMonitor ( boolean ToMonitor ) public void SetLImits ( int Value, int Value, int Value, int Value ) public void Finalize ( void ) public String[ ] GetInfo ( int InfoType ) private void SendTendencyAlarm( String Alarm ) private Register( ) public void run ( ) }

Figura 20 - Diagrama da classe do Inspetor de Desempenho

Os diversos mtodos permitem que a execuo do Inspetor de Desempenho seja controlada e configurada pelo Gerente de Desempenho de Domnio. A parada ou a retomada da monitorao podem ser comandadas pelo mtodo ToMonitor. Os limites citados no pargrafo anterior podem ser alterados com o uso do mtodo SetLimits. A execuo do Inspetor de Desempenho pode ser encerrada com o uso do mtodo Finalize. Essa parada usada quando do encerramento das atividades do Inspetor de Desempenho em questo ou quando da substituio do seu cdigo por uma nova verso. O Gerente de Desempenho de Domnio pode solicitar qualquer tipo de informao adicional, cuja obteno foi previamente programada no Inspetor de Desempenho, com o uso do mtodo GetInfo. A implementao do Inspetor de Desempenho do exemplo j citado, ou seja, o cdigo presente no mtodo run do diagrama de classe apresentado na Figura 20, apresentada na forma de pseudo-cdigo na Figura 21. As variveis iniciadas com Priv so atualizadas pelo mtodo SetLimits, e so elas quem armazenam, de forma privativa, os limites que eu podem ser configurados para a monitorao. O tempo gasto na execuo de um lao de monitorao descontado do intervalo que deve ser aguardado para a realizao do prximo lao. Esse tempo pode envolver o acesso a dispositivos

60 cujo acesso seja bem mais demorado do que o processamento realizado na CPU, como, por exemplo, o acesso a MIBs e/ou a dispositivos de memria secundria. Adicionalmente, todas as informaes relevantes para posterior utilizao em aplicaes que venham a analisar o desempenho do parmetro monitorado so armazenadas: o nmero da observao, o valor obtido, a variao e o tipo de alarme que foi desencadeado. Uma vez que o cdigo do Inspetor de Desempenho desenvolvido especificamente para o parmetro que por ele monitorado, o tempo de acesso ao dispositivo de armazenamento pode ser bem conhecido, de forma que o intervalo entre observaes possa ser precisamente programado.
// controls first loop execution: no variation need to be calculated Beginning = true LoopCount = 1 // PrivToMonito controls starting and stopping of monitoring while ( PrivToMonitor ) InitialTime = get system time of the beginning of the loop AlarmSent = null Get UpdatedValue for monitored parameter if ( Beginning ) // starts reference values because its the first time loop runs LastValue = UpdatedValue UpdatedVariation = 0 CeilingValue = UpdatedValue Beginning = false else // calculates variation UpdatedVariation = LastValue UpdatedValue // verifies if ceiling value has to be changed if ( UpdatedValue > CeilingValue ) CeilingValue = UpdatedValue else // verifies if new value is worts than last value if ( UpdatedValue < LastValue ) // verifies if variation is greater than limit for 1 interval if ( UpdatedVariation >= PrivMaxOneSleepVariatiLimit ) CeilingValue = UpdatedValue // verifies if threshold to send alarm was reached if ( UpdatedValue < PrivThresholdValue ) AlarmSent = max one sleep limit exceeded sends tendency alarm else // verifies if variation is greater than limit of acumm var if ( (CeilingValue - UpdatedValue) >= PrivMaxVariationLimit ) CeilingValue = UpdatedValue // verifies if threshold to send alarm was reached if ( UpdatedValue < PrivThresholdValue ) AlarmSent = max accumulated variation exceeded Sends tendency alarm LastValue = UpdatedValue stores LoopCount, UpdatedValue, UpdatedVariation, AlarmSent FinalTime = get system time LoopTime = FinalTime - InitTime if ( LoopTime < PrivSleepInterv ) Thread.sleep( PrivSleepInterv - LoopTime ) if ( ContinuesRunning == null ) PrivToMonitor = false LoopCount++

Figura 21 - Pseudo-cdigo de um Inspetor de Desempenho

4.2.6. Consideraes sobre a implementao

A implementao do prottipo contempla todas as facilidades previstas na AGAD [19], das quais, as principais so a utilizao da programao multithreading e a possibilidade de atualizao de componentes de software em tempo real.

61 O Inspetor de Desempenho implementado na forma de thread, sendo que uma thread deve ser didicada monitorao de cada parmetro de controle. A comunicao do Inspetor de Desempenho com o Gerente de Desempenho de Domnio para o envio de Alarmes de Tendncia se d via socket, diretamente, e realizada, no Inspetor de Desempenho, por intermdio de uma thread dedicada a essa funo, que chamada, de forma sincronizada, pela thread que realiza a monitorao. Tal soluo se faz necessria porque podem existir mais de uma thread de monitorao, quando houver mais de um parmetro a ser monitorado no mesmo elemento gerenciado. A atualizao de componentes em tempo real implementada de forma que seja possvel o envio, a partir do Gerente de Desempenho de Domnio, um novo cdigo para um mtodo ou para uma classe que estejam sendo executados (intanciados). Para isso, h um mtodo denominado Registrador em cada elemento da AGAD que implementa (por ocasio da instanciao) a Interface para cada mtodo presente no elemento. O novo cdigo, ao ser recebido pelo Server, tratar de comandar o encerramento oportuno do objeto a ser substitudo e se registrar, assumindo ento o lugar do objeto substitudo. 4.3. Resumo do captulo Neste captulo foram apresentados o ambiente de desenvolvimento utilizado e a implementao do prottipo que foi realizada. O ambiente todo baseado tanto em softwares gratuitos quanto na linguagem Java. A infra-estrutura de mobilidade e a interface de programao de aplicaes de gerenciamento que foram utilizadas tambm so baseadas na linguagem Java. O prottipo implementado consistiu de um Gerente de Desempenho de Domnio, um Inspetor de Desempenho e um Especialista. A implementao do prottipo foi realizada com o uso da anlise e projeto orientados a objeto e os diagramas referentes ao desenvolvimento foram apresentados via UML.

62

Captulo 5 - Testes e anlise dos resultados obtidos

Os testes realizados tinham como cenrio de referncia um domnio (da AGAD) onde executada uma aplicao multimdia distribuda como o ServiMdia [28]. Este cenrio representa a utilizao do gerenciamento de desempenho pr-ativo que foi descrita na seo 3.4.1, ou seja, no gerenciamento de aplicaes. O objetivo geral dos testes determinar se o desempenho de um sistema de gerenciamento prativo baseado em uma linguagem interpretada viabiliza tanto a monitorao de parmetros de QoS em tempo real, quanto o desencadeamento de aes que venham a, prever e, at, se possvel, evitar a ocorrncia de falhas de QoS e/ou minimizar os seus efeitos para a QoP. Inicialmente, na seo 5.1, ser descrita a metodologia que foi utilizada na realizao dos testes. Na seo 5.2 sero descritos os testes que foram realizados com o prottipo, os objetivos desses testes e os resultados obtidos. Esses resultados sero analisados na seo 5.3. Por fim, na seo 5.4 sero apresentadas as consideraes finais do captulo. 5.1. Metodologia de testes Os testes consistiram, quando necessrio, na execuo de cinco rodadas do evento em questo, cada uma delas com pelo menos trinta experincias, para cada plataforma considerada. Foram calculados, para cada rodada, a mdia, o desvio padro, o intervalo de confiana de 95% e grau de ajuste distribuio normal, expresso percentualmente e calculado pelo teste Qui-quadrado [52]. Tal teste foi realizado com o auxlio do software Satistica [55] e teve por finalidade verificar se os valores coletados eram suficientes, tanto em quantidade quanto em disperso, para que a mdia obtida fosse considerada vlida. tambm calculada a mdia das cinco mdias (das rodadas) para cada plataforma em questo. Esse valor ser utilizado na anlise dos resultados como uma forma de se associar uma nica medida, por plataforma, para cada teste. 5.2. Testes realizados e resultados obtidos Foram realizados trs tipos de testes com o prottipo de Gerenciamento de Desempenho PrAtivo que foi implementado: (i) execuo isolada do Inspetor de Desempenho com o envio de Alarmes, (ii) desencadeamento de uma ao por um Especialista aps o envio de um Alarme de Tendncia pelo Inspetor de Desempenho e (iii) monitoramento do parmetro de controle retardo ao longo de um intervalo de tempo em uma rede real.
5.2.1. Testes do Inspetor de Desempenho isolado

O objetivo especfico do primeiro tipo de teste a obteno de dados referentes ao desempenho do funcionamento do prprio Inspetor de Desempenho em plataformas com diferentes capacida-

63 des de processamento. Com esses dados pode-se inferir qual a freqncia mxima de monitoramento de parmetros de controle que pode ser utilizada e qual a capacidade de processamento necessria para essa monitorao. Esse teste consistiu na determinao de quanto tempo leva a execuo de um lao completo de monitoramento pelo Inspetor de Desempenho. As plataformas que foram utilizadas esto apresentadas na Tabela 1.
Tabela 1 - Plataformas de hardware utilizadas nos testes isolados Plataforma
1 2

CPU
AMD K6-II AMD Athlon

Clock (MHz)
475 1333

Cache (KBytes)
64 256

RAM (MBytes)
128 256

Em todas as experincias foi colocado em execuo, em nvel usurio, apenas o processo referente ao Inspetor de Desempenho. Uma vez que a utilizao (daquelas sugeridas na Seo 3.4) escolhida para que o gerenciamento aqui proposto fosse testado o trabalho em prol de uma aplicao multimdia distribuda, onde bem provvel a utilizao de um ambiente grfico para a interface com o usurio, o ambiente de rea de trabalho (KDE) foi deixado em execuo em todos os testes. A funcionalidade de garbage collection do Java no teve a sua configurao alterada. A execuo do lao de monitoramento do Inspetor de Desempenho deve ser feita da forma mais rpida possvel, de forma que no s seja permitida uma maior freqncia de monitoramento, como tambm seja consumida pouca capacidade de processamento do elemento gerenciado onde o Inspetor de Desempenho executado. Uma execuo tpica do lao de monitoramento envolve as seguintes fases: Obteno de uma observao do valor do parmetro monitorado. Essa observao pode ser obtida de trs formas: (i) diretamente do sistema operacional, (ii) diretamente de uma aplicao, como o caso quando se usa RTCP, ou, ainda, (iii) de daemons do sistema operacional cujo acesso se d via pilha de protocolos, como no caso de um agente SNMP. A terceira opo foi a utilizada neste teste. Execuo de um trecho de programa com clculos e comparaes simples, cujo pseudocdigo foi apresentado na Figura 21. Envio de um Alarme de Tendncia, caso seja necessrio, via pilha de protocolos do sistema operacional.

64 Armazenamento em memria secundria do valor da observao; da variao da mesma em relao ao valor da observao anterior; de uma estampa de tempo e do tipo de alarme que foi enviado. O lao de monitoramento que foi testado foi programado para representar o pior caso em termos de tempo de execuo, pois vai desde a obteno do valor da observao do parmetro monitorado a partir de um agente SNMP at o envio de um Alarme de Tendncia e o conseqente armazenamento de dados em memria secundria. A obteno do valor da observao via SNMP uma das formas mais demoradas de se faz-lo, pois envolve o preparo de uma PDU de requisio e a transmisso da mesma via UDP, com a participao do sistema operacional. A resposta tambm recebida via UDP. Uma chamada ao sistema operacional ou uma interao direta com uma aplicao certamente levaria menos tempo. Foram configurados valores para os limites (descritos na Seo 3.2.1) que levaram, neste teste, ocorrncia de Alarmes em todas as experincias de cada rodada. Os resultados obtidos esto apresentados na Tabela 2. Cabe destacar que, em funo dos valores observados na execuo do teste na pior plataforma serem prximo a 10 ms, optou-se por medir o tempo, em cada experincia, para a realizao de 200 laos e dividir o valor encontrado por 200 para se chegar ao valor apresentado na tabela. Em uma primeira realizao do teste de cinco rodadas com trinta experincias na plataforma Athlon de 1,3 MHz, ao se tentar realizar o ajuste dos resultados obtidos curva normal pelo teste do Qui-quadrado, no se obteve sucesso, uma vez que o desvio padro era demasiadamente grande. O teste foi ento repetido com 41 experincias, quando ento foi possvel o ajuste, conforme pode ser observado pelos valores do coeficiente de ajuste normal apresentados na Tabela 2. J no caso da plataforma AMD K6 de 475 MHz, obteve-se o ajuste com apenas trinta experincias, por isso, o teste no foi repetido. A primeira experincia de cada rodada de cada teste sempre apresenta um valor excessivamente alto em relao s experincias posteriores. Tal fato se deve s instanciaes de objetos e do carregamento de variveis em memria que so realizados pela mquina virtual Java quando do incio da execuo dos programas. Uma vez que o principal objetivo deste teste a obteno de dados referentes execuo do Inspetor de Desempenho, ou seja, j inicializado, os valores dessas primeiras experincias, embora apresentados, sero omitidos tanto dos clculos da mdia, do desvio padro e do intervalo de confiana de cada rodada.

65

Tabela 2 Execuo completa de um lao de monitorao com envio de alarme

AMD K6 475 MHz 2 3 4 14,74 12,94 16,34 10,07 9,97 10,09 9,97 10,02 9,97 10,02 10,02 9,97 9,97 10,01 10,02 10,02 9,97 10,02 10,02 10,02 10,02 10,01 10,02 9,97 10,02 9,97 10,02 10,03 10,02 10,02 10,02 10,02 10,02 9,97 9,97 10,02 10,02 9,97 9,97 9,97 10,02 10,02 10,02 9,97 9,97 10,02 10,02 10,02 9,97 10,02 10,07 10,02 9,97 10,02 10,77 10,77 10,98 10,02 10,02 10,02 10,01 9,97 10,02 10,02 9,97 10,02 9,97 10,02 10,37 10,02 10,02 10,02 9,97 10,02 10,02 10,02 9,97 10,02 9,97 10,02 10,02 10,02 9,97 10,02 9,97 10,02 9,97 10,02 10,02 10,02 9,97 10,02 10,02 ---------------------------------10,03 10,03 10,06 10,04 99,99 99,99 100,0 0,14 0,14 0,19 0,05 0,05 0,07 Athlon 1,3 MHz 2 3 4 2,17 2,83 6,23 0,07 0,92 0,27 0,07 1,12 0,42 0,07 1,92 0,77 0,27 1,17 0,07 0,32 2,02 0,07 0,92 2,57 0,62 0,07 1,98 0,22 0,07 0,82 0,52 0,07 1,87 0,12 0,17 2,93 1,32 0,07 1,97 0,87 0,62 1,17 1,82 0,27 0,92 0,42 0,42 0,82 1,57 0,62 1,17 0,27 0,07 1,27 0,72 0,27 0,77 0,82 0,27 1,47 0,17 0,17 1,12 0,97 0,07 1,07 0,47 0,07 0,97 0,82 0,12 1,52 1,82 0,07 2,67 3,63 0,22 2,17 0,24 0,07 1,77 9,43 0,07 2,93 12,39 0,07 1,17 8,68 3,18 2,38 9,23 3,32 1,67 10,23 3,13 2,02 13,99 1,52 2,62 1,44 0,22 3,17 2,49 0,32 2,93 0,88 0,12 4,83 2,99 0,12 7,63 3,29 0,07 7,03 2,93 0,07 7,28 3,98 0,07 5,98 1,58 0,12 2,07 3,29 0,07 0,82 4,24 0,27 2,83 0,27 0,49 2,33 2,83 1,32 100,0 99,9 100,0 0,88 1,77 3,63 0,27 0,55 1,12

Rodadas 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 Mdia da rodada Mdia da plataforma Grau ajuste normal (%) Desvio padro Int. de confiana de 95%

1 13,20 10,02 10,02 9,97 10,01 10,02 10,02 9,97 10,02 10,02 10,02 10,02 10,01 10,02 10,02 10,01 9,97 9,97 10,77 10,02 9,97 9,97 10,02 10,02 9,97 10,02 10,02 10,02 9,97 9,97 10,02 -----------10,03 99,99 0,14 0,05

5 16,04 9,97 9,98 10,07 10,02 10,02 9,97 10,02 10,02 10,12 10,02 10,02 10,02 10,02 10,02 9,97 10,02 9,97 10,77 9,97 10,02 10,02 10,02 9,97 10,17 10,22 10,02 9,97 10,02 9,97 9,97 -----------10,04 99,99 0,15 0,05

1 3,63 0,13 0,08 0,18 0,30 0,23 0,58 0,08 0,88 0,18 4,08 1,13 0,18 1,33 0,23 0,83 1,93 0,33 0,43 0,93 0,28 0,03 0,18 0,18 0,03 0,03 0,78 1,43 0,28 0,24 0,69 0,49 1,04 1,64 0,59 0,29 0,45 1,04 0,19 0,04 0,04 0,13 0,67 100,0 0,87 0,27

5 4,28 0,12 0,42 0,17 0,52 0,12 0,07 0,07 0,07 1,07 0,22 0,07 0,92 0,07 0,07 0,22 0,07 0,07 0,07 0,07 0,07 0,07 0,07 0,07 0,07 0,17 0,07 0,17 0,32 0,07 0,27 0,12 0,22 0,17 0,07 0,17 0,07 0,12 0,07 0,12 0,17 0,17 0,28 100,0 0,67 0,21

Obs: tempos em milissegundos

5.2.2. Testes de desencadeamento de ao via Especialista

O objetivo especfico desse teste a obteno de dados referentes ao desempenho da interao do Inspetor de Desempenho com o Gerente de Desempenho de Domnio utilizando-se no s do ambiente Java como tambm de uma infra-estrutura de mobilidade, alm da prpria rede. Com esses dados pode se saber qual a latncia mnima que deve ser esperada do sistema de gerenciamento pr-ativo. Essa latncia tem que ser considerada para a escolha das aes que devem ser desencadeadas pelos Especialistas.

66 Estes testes foram realizados a partir da execuo do Inspetor de Desempenho e do Gerente de Desempenho sendo executados em estaes diferentes, sendo ambas plataformas AMD K6-II de 500 Mhz, com 256 MB de memria RAM e 128 KB de memria cache, interligadas via rede. O Gerente Mor iniciava todo o processo, a partir de uma terceira estao, cuja plataforma era a mesma. Um esquema simplificado do teste, onde so mostradas as infra-estruturas que so utilizadas, apresentado na Figura 22.
Especialista

Inspetor de Desempenho Alarme de Tendncia Cdigo do Especialista Server Adventnet JVM 1.3 Linux Red Hat 7.2 Pentium ...

Gerente de Domnio Dom

Server

JVM 1.3

Ethernet 100 Mbps

Linux Red Hat 7.2 Pentium ...

Figura 22 - Esquema simplificado da interao Insp. de Desempenho Ger. de Desempenho

Dois foram os tempos medidos nos testes: (i) o tempo total, desde a deciso, pelo Inspetor de Desempenho, do envio de um Alarme de Tendncia, at o fim da instanciao de um Especialista, na mesma estao do Inspetor de Desempenho, e (ii) o tempo entre o recebimento do Alarme pelo Gerente de Desempenho de Domnio e o envio do cdigo do Especialista. O tempo desse teste ii est inserido no tempo do teste i e deve-se anlise do Alarme recebido, ao processamento da infra-estrutura de mobilidade e recuperao e envio do cdigo do Especialista. O envio do Especialista de Desempenho pode necessitar de mais do que uma nica transmisso via rede, diferentemente do que est sendo sugerido pela Figura 22. O Gerente de Desempenho do Domnio envia primeiro uma notificao com o Uniform Resource Locator (URL) que identifica o cdigo (do Especialista) que deve ser carregado na estao do Inspetor de Desempenho. O class loader do Server, na estao do Inspetor de Desempenho, ao receber essa notificao, verifica se o cdigo que deve ser enviado j est presente nos espaos de classes locais. Caso no esteja, o mesmo pedido para o Server do Gerente de Desempenho de Domnio, que ento o envia. Uma situao alternativa, menos demorada, aquela onde o cdigo de um Especialista j esteja presente no elemento gerenciado. Nesse caso, no ser necessria a transferncia do cdigo, reduzindo a latncia at o incio de sua execuo. Caso um Especialista venha a ser executado com freqncia, poucas dessas transferncias sero necessrias. Essa a situao que tem a

67 maior probabilidade de acontecer, pois no esperado que o cdigo dos Especialistas seja atualizado com freqncia. Ambas as situaes foram testadas. Foram realizados ento trs subtestes de desencadeamento da ao via Especialistas. No primeiro subteste, todo o sistema foi reiniciado antes de cada uma das trinta experincias, para que o cdigo do Especialista fosse sempre transferido. Esse cdigo consistia de um arquivo de bytecodes com 1483 bytes. Os tempos obtidos, (i) total, e (ii) de processamento no Gerente de Desempenho de Domnio, esto apresentados na Tabela 3.
Tabela 3 - Resultados do teste com reinicializao e Especialista de 1 KB
Tempos: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 Mdia Grau ajuste normal (%) Desvio padro Int de conf 95% (i) 137 159 133 132 148 137 131 134 161 139 137 135 133 138 135 140 133 132 134 140 134 133 131 133 132 133 139 133 135 133 136,80 99,99 7,24 2,59 (ii) 12 8 9 10 14 14 9 11 11 16 14 12 10 15 11 13 10 9 10 16 10 10 8 9 9 9 15 9 11 9 11,10 95,27 2,43 0,87

Obs: tempos em milissegundos

O segundo subteste consistiu do mesmo experimento, no entanto, o sistema no foi reinicializado. Nesse caso, o cdigo do Especialista (o mesmo do subteste anterior, de 1 KB) permanecia em memria cache, evitando a transmisso do pedido para o seu envio e a transferncia do seu prprio bytecode, exceto na primeira execuo. Os tempos obtidos, (i) total, e (ii) de processamento no Gerente de Desempenho de Domnio, esto apresentados na Tabela 4.

68

Tabela 4 - Resultados do teste sem reinicializao do sistema e Especialista de 1 KB

Tempos: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 Mdia Grau ajuste normal (%) Desvio padro Int de conf 95% (i) 38 40 37 37 40 42 51 41 44 46 63 37 43 49 41 41 38 38 40 41 43 38 45 39 38 41 47 43 47 39 42,23 95,48 5,39 1,93 (ii) 8 6 13 5 8 9 9 9 12 15 6 7 10 9 10 9 8 7 8 10 12 14 8 8 8 13 9 9 8 12 9,30 99,79 2,42 0,87

Obs: tempos em milissegundos

O terceiro subteste realizado consistia na repetio do primeiro teste (com reinicializao) porm, com o cdigo de Especialista tendo, em bytecodes, 10488 bytes. O objetivo desse teste era verificar qual a conseqncia no aumento do tempo total do experimento com um Especialista 10 vezes maior. Os resultados obtidos esto apresentados na Tabela 5.

69

Tabela 5 - Resultados do teste com reinicializao do sistema e Especialista de 10 KB

Tempos: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 Mdia Grau ajuste normal (%) Desvio padro Int de conf 95% (i) 433 438 430 433 436 436 431 435 427 457 429 428 433 434 427 434 427 438 429 435 431 430 426 434 430 430 434 434 448 435 433,40 95,30 6,27 2,24 (ii) 9 14 10 13 10 13 14 9 11 10 12 9 12 11 9 7 12 10 8 12 8 9 14 7 14 10 13 12 13 11 10,87 2,13 0,76

Obs: tempos em milissegundos

5.2.3. Monitoramento do parmetro de controle retardo

O terceiro teste tem como objetivo especfico realizar o monitoramento do parmetro de controle retardo em uma aplicao executada em um ambiente real e verificar quando e por que so gerados Alarmes de Tendncia. A anlise dos resultados desse teste permite a inferncia de concluses a respeito no s da eficcia do gerenciamento pr-ativo na previso de falhas de QoS como tambm sobre o tempo disponvel para o desencadeamento de aes, ou seja, o tempo que sobrar entre a instanciao do Especialista at a (possvel) ocorrncia da falha de QoS. Esse ser o tempo que o Especialista ter para desencadear suas aes ou para a aplicao realizar adaptaes. Esse teste consistiu na execuo do Inspetor de Desempenho sobre um conjunto de valores observados do parmetro de controle retardo, que foram obtidos ao longo de um intervalo de duas horas, durante o pico de utilizao, em um dia normal de trabalho, da rede do Instituto Militar de Engenharia (IME). O prdio do IME, que uma faculdade de Engenharia com 11 cursos de gra-

70 duao organizados em 7 departamentos de ensino independentes, coberto por uma rede com cerca de 45 segmentos, todos baseados em Ethernet, e 500 estaes de trabalho. Esse um cenrio tpico no s para a utilizao de uma aplicao multimdia distribuda como o ServiMdia, como tambm para um domnio de gerenciamento distribudo conforme o que revisto pela AGAD. A topologia da rede, detalhada apenas em seus pontos relevantes para o teste que foi realizado, est apresentada na Figura 23.
Comutador de Nvel 2 Comutador de Nvel 3 Trfego cujo retardo foi medido no teste Cliente + 100 estaes Hub Comutador de Nvel 2 10 Mbps + 15 estaes + 150 estaes + 120 estaes Hub Servidor Comutador Roteador de Nvel 2 Rede Rede Rio Rio + 10 estaes

100 Mbps

Figura 23 - Topologia da rede utilizada para obteno do comportamento da variao do retardo

Cabe destacar que atualmente, no s na rede do IME, mas tambm na maioria das redes, mesmo de faculdades e universidades, ainda no so utilizadas aplicaes multimdia distribudas. Visando obter maior realismo na obteno dos dados referentes ao retardo, foi inserida a transmisso de um fluxo de vdeo codificado em MPEG-1, com duas horas de durao e com taxa de 400 Kbps, do servidor para o cliente. Os dados referentes ao retardo foram obtidos com o uso de uma aplicao cliente-servidor tambm programada em Java, para que o retardo equivalente ao processamento da JVM fosse considerado. O cliente enviava pacotes UDP a cada cinco segundos para o servidor, que os enviava de volta. O retardo ento era medido e dividido pela metade. A medio do retardo foi realizada durante trs dias consecutivos, sendo ento selecionada uma amostra tpica com vrios picos de retardo e considervel variao, conforme pode ser observado na Figura 24.

71

Retardos (amostras 1 a 360) 140 120 Retardo em m s 100 80 60 40 20 0 1 11 21 31 41 51 61 71 81 91 101 111 121 131 141 151 161 171 181 191 201 211 221 231 241 251 261 271 281 291 301 311 321 331 341 351

Retardos (amostras 361 a 720) 140 120 R etardo em m s 100 80 60 40 20 0 1 11 21 31 41 51 61 71 81 91 101 111 121 131 141 151 161 171 181 191 201 211 221 231 241 251 261 271 281 291 301 311 321 331 341 351 361

Figura 24 Amostra da variao do retardo que foi utilizada no teste

72 O Inspetor de Desempenho foi ento executado sobre essa amostra, para que, quando fosse o caso, Alarmes de Tendncia fossem detectados. Os seguintes valores foram considerados como limites para a configurao do Inspetor de Desempenho: 65 ms como limite mnimo do retardo a partir do qual Alarmes devem ser gerados, 35 ms como variao mxima entre duas observaes consecutivas; 40 ms como variao mxima acumulada.

Foi considerado que se o retardo chegasse a 90 ms ocorreria uma falha de QoS. Cabe destacar que a lgica de escolha destes valores no trivial e depende de fatores como, por exemplo, o tamanho dos buffers de recepo das aplicaes multimdia e da freqncia com a qual se pretende realizar a monitorao do retardo. Uma vez que o foco dessa proposta focada no mecanismo de gerenciamento de desempenho propriamente dito, esse problema foi deixado fora do escopo da mesma e ser apontado como um dos possveis trabalhos. Os Alarmes que foram detectados na amostra de variao do retardo da Figura 24 e os Alarmes de Tendncia que foram detectados esto apresentados no grfico da Figura 25. Os tringulos representam os Alarmes, sendo que, quando na ordenada 15, o alarme foi gerado por desrespeito ao limite mximo de variao para duas amostras consecutivas (35 ms) e, quando na ordenada 8, o alarme foi gerado por desrespeito variao mxima acumulada (40 ms). Todos os valores do retardo (Ret, na tabela) de cada amostra (Am, na tabela) e os Alarmes (Al, na tabela) que foram gerados a partir da execuo do Inspetor de Desempenho, esto apresentados no Anexo A.

73

Retardos (amostras 1 a 360)

140 120

R e ta rd o e m m s

100 80 60 40 20 0

11

21

31

41

51

61

71

81

91

101

111

121

131

141

151

161 171

181

191

201 211

221

231

241

251

261

271

281

291

301

311

321

331

341

351

Retardos

Alarmes

Retardos (amostras 1 a 360)

160 140

Limite para ocorrncia de falha de QoS

R e ta rd o e m m s

120 100 80 60 40 20 0

11

21

31

41

51

61

71

81

91

101

111

121

131

141

151

161 171

181

191

201 211

221

231

241

251

261

271

281

291

301

311

321

331

341

351

Retardos

Alarmes

Figura 25 Alarmes gerados na amostra de variao de retardo

74 5.3. Anlise dos resultados Nesta seo sero analisados, inicialmente, os resultados de cada um dos testes separadamente. Em seguida, sero realizadas consideraes sobre os testes como um todo. Em ambos os casos, as anlises sero feitas com o objetivo de se analisar a eficincia, a eficcia, a viabilidade e as limitaes do gerenciamento de desempenho pr-ativo que proposto nesta dissertao.
5.3.1. Inspetor de Desempenho isolado

A necessidade de se executar o Inspetor de Desempenho com alta freqncia, dependendo do parmetro de QoS que se deseja monitorar, impe o conhecimento de quanto tempo leva a execuo completa de um lao do mesmo. Essa execuo completa envolve, alm dos clculos referentes aos valores dos limites mximos (ou mnimos) tolerados, o acesso a outros processos, quer sejam do sistema operacional, para a obteno de referncias de tempo, quer sejam de outras aplicaes, como, por exemplo, um agente SNMP sendo executado na mesma mquina. Adicionalmente, o registro dos clculos referentes quela iterao devem ser armazenados, normalmente, em unidades de disco. Conforme pode ser observado na Tabela 2, o tempo de execuo completo do Inspetor de Desempenho varia, na plataforma mais fraca, de 9,97 at 10,77 milissegundos, incluindo o envio de um alarme e o armazenamento de dados. Caso seja necessrio, possvel se diminuir ainda mais o tempo de execuo de um lao do Inspetor de Desempenho, atravs da utilizao de threads de menor prioridade para a realizao de tarefas relativas ao registro de dados em disco. Ainda, dependendo do parmetro a ser monitorado, a forma de obteno do valor do mesmo pode colaborar para a melhora do desempenho do Inspetor de Desempenho, uma vez que no caso testado, essa obteno envolvia o acesso a uma MIB, via agente SNMP. O esquema de garbage collection da JVM tambm pode ser alterado, atravs de cuidadosa programao do Inspetor de Desempenho, de forma a diminuir o tempo de execuo desse ltimo. Em funo do desempenho apresentado, pode-se afirmar que vivel a utilizao de um Inspetor de Desempenho programado em Java para a monitorao de valores de parmetros de QoS em temp real. A determinao da freqncia de monitorao do Inspetor de Desempenho dever ser limitada apenas pelo tipo do parmetro que se deseja monitorar e no pela capacidade de processamento do elemento gerenciado, caso essa seja parecida ou superior quela da pior plataforma testada. Cabe destacar que a plataforma que apresentou o pior resultado possua capacidade de processamento que era quase insuficiente para a reproduo do vdeo que foi transmitido durante a captura dos valores do retardo. Na plataforma 2 (Athlon 1,3 GHz), o tempo de execuo do lao

75 do Inspetor de Desempenho caiu para menos do que 2 milissegundos, algo que permitiria, caso o tempo de execuo do Inspetor de Desempenho fosse o nico fator limitante, uma freqncia de monitorao do parmetro em questo de at cerca de 30 Hz (30 observaes por segundo).
5.3.2. Interao entre Inspetor de Desempenho e Gerente de Desempenho de Domnio

O teste compreendeu a medio do intervalo de tempo decorrente desde a tomada de deciso, pelo Inspetor de Desempenho, aps o clculo da variao do valor observado do parmetro em questo em relao observao anterior, de enviar um Alarme de Tendncia at o final da instanciao de um Especialista nesse mesmo elemento gerenciado. Esse intervalo de tempo decomposto nos processamentos e transmisses mostrados na Figura 26.
i ii Inspetor de Desempenho iii iv Rd Gerente de Desempenho de Domnio
Recepo Anlise Preparo da do alarme do alarme Notificao

vi vii viii ix x xi Inspetor Inspetor Rd de Des. Rd Gerente Rd de Des. Des. Des.

Busca ao Espec. Envio do Cdigo Instanciao do Espec.

Clculo das Preparo do Variaes Alarme

Obteno Deciso de Envio do da envio de Alarme ao observao um alarme Gerente de Desempenho Domnio

Envio da Notificao

Pedido do cdigo do Especialista

Envio do cdigo do Especialista

Incio do desencadeadesencadeamento de ao pelo Especialista

Figura 26 - Etapas entre a deciso de envio de Alarme de Tendncia e incio de execuo do Especialista

O detalhamento das etapas mostradas nesta figura, com a descrio de cada processamento e de cada transmisso, apresentado na Tabela 7. Os eventos numerados de i a xi na figura so usados como referncia. Os resultados que foram obtidos na execuo desse teste podem ser resumidos de acordo com o que est apresentado na Tabela 6.
Tabela 6 - Resultados da interao entre Insp. de Desempenho e o Ger. de Desempenho Com reinicializao para cada experimento, Especialista de 1 KB Tempo total, entre os eventos (ii) e (xi). Tempo total, entre os eventos (iv) e (v). Sem reinicializao para cada experimento, Especialista de 1 KB Com reinicializao para cada experimento, Especialista de 10 KB

136,8 ms 11,1 ms

42,23 ms 9,30 ms

433,4 ms 11,57 ms

O tempo de anlise do Alarme de Tendncia no Gerente de Desempenho de Domnio pode ser grande, em funo da complexidade das tcnicas que forem empregadas para a sua realizao. No entanto, o Gerente de Domnio (e, conseqentemente, o Gerente de Desempenho de Domnio) pode ser instalado em uma estao com elevada capacidade de processamento, de forma que esse tempo de processamento venha a ser reduzido.

76
Tabela 7 Detalhamento das etapas apresentadas na Figura 26 Evento i. Obteno de uma observao do parmetro de controle. ii. Deciso por envio de um Alarme de Tendncia (incio da medio). iii. Envio do alarme via socket iv. Recepo do alarme pela estao do Gerente de Desempenho de Domnio (GDD). v. Envio da notificao ao elemento gerenciado. No caso testado, este elemento aquele onde est sendo executado Inspetor de Desempenho. vi. Recepo da notificao no elemento gerenciado. vii. Envio do pedido do cdigo estao do GDD. viii. Recepo do pedido de envio do cdigo do Especialista. ix. Envio do cdigo estao do Inspetor de Desempenho (ID). x. Recepo do cdigo na estao do ID. xi. Instanciao do cdigo do Especialista (fim da medio). Processamento relacionado ao evento Clculo das variaes em um intervalo de tempo e acumulada. Comparao do valor da observao e das variaes com os limites configurados. Preparo do Alarme para transmisso via Server. Propagao via rede. Recepo do alarme pelo sistema operacional, processamento pelo Server e entrega do alarme ao GDD. O GDD analisa o alarme e decide qual o Especialista que deve ser enviado e para qual elemento gerenciado. A notificao que envia a URL referente ao cdigo do Especialista ento preparada.

Propagao via rede.

Recepo da notificao pelo sistema operacional e processamento pelo Server, buscando o cdigo do Especialista em seus espaos de classe. No caso testado, por ser a primeira vez que esse Especialista ser executado nesse elemento gerenciado, seu cdigo no ser encontrado. Um pedido do cdigo ento preparado pelo Server. Propagao via rede. Recepo do pedido pelo sistema operacional, entrega do mesmo ao Server, que recupera o cdigo e o prepara para ser enviado. Propagao via rede. Recepo do cdigo pelo sistema operacional, entrega do mesmo ao Server que far o carregamento do mesmo. Execuo da ao para a qual o Especialista foi programado.

A distribuio dos valores do retardo na rede ao longo do dia pode ser razoavelmente bem conhecida atravs da consulta a um baseline atualizado da rede. Dessa forma, pode-se no s configurar o tipo de anlise a ser feito no Gerente de Desempenho de Domnio, como tambm determinar-se aes diferentes (Especialistas diferentes) de acordo com os retardos esperado para o momento. O retardo da rede, medido em paralelo com a execuo dos testes, atravs de execues do programa Ping, no excedeu 0,4 ms. Esse valor pode aumentar expressivamente, principalmente quando o afastamento entre o Inspetor de Desempenho e o Gerente for grande ou existir um grande nmero de ns de comutao entre os mesmos. Os valores de retardo coletados para a realizao do terceiro teste, onde o pior caso foi de 120 ms, podem ser usados como referncia. Nesse caso, os retardos obtidos no teste analisado nesta seo seriam aumentados em cerca de 480 ms, devido s quatro transmisses via rede que seriam necessrias para a recuperao do cdigo do Especialista.

77 O tamanho do Especialista a ser transmitido deve tambm ser considerado. Os testes mostraram que a transmisso do cdigo de um Especialista de 10 KB levou triplicao do tempo total do experimento em relao a um Especialista de 1 KB. Tal fato se deve ao processamento dos protocolos da arquitetura TCP/IP e das camadas de Enlace e Fsica para a transferncia desse cdigo. O TCP foi utilizado na camada de Transporte. Com Especialista de 1 KB, dois segmentos TCP foram utilizados, enquanto que no segundo caso, com Especialista de 10 KB, nove segmentos foram utilizados. No entanto, no esperado que os Especialistas tenham cdigos grandes, uma vez que os mesmos so desenvolvidos especificamente para as aes que devem realizar, sendo que essas aes devem envolver, conforme j foi citado, a simples alterao de um valor em uma tabela, a entrega de uma mensagem a uma aplicao ou a realizao de uma chamada ao sistema operacional. Nesses casos, dificilmente o cdigo do Especialista alcanaria os 10 KB. O tempo para o incio de uma ao seria drasticamente reduzido, conforme pode-se deduzir com a anlise da Figura 27, caso o Inspetor de Desempenho venha a enviar o Alarme de Tendncia, por exemplo, diretamente a uma aplicao adaptativa. Em relao ao retardo na rede, dois casos podem ocorrer, Inspetor de Desempenho e Aplicao na mesma estao ou em estaes diferentes. O caso ilustrado na Figura 27, pode ser considerado o melhor, uma vez que o Inspetor de Desempenho e a Aplicao encontram-se sendo executados na mesma estao. Caso estivessem em estaes diferentes, o retardo referente a apenas uma transmisso via rede deveria ser considerado.
i ii Inspetor
Clculo das Preparo do Adaptao Variaes Alarme Obteno Deciso de Envio do da envio de Alarme observao um alarme Aplicao Adaptativa

iii

Figura 27 - Etapas entre a deciso de envio de Alarme e incio da ao por uma aplicao

Em funo do que foi apresentado nos pargrafos anteriores desta seo, levando-se em conta todos os piores casos, ou seja, um Especialista com 10 KB, a ausncia do mesmo em cache e um retardo de 120 ms na rede, pode-se considerar que o tempo para que um Especialista inicie a execuo de uma ao no deve ultrapassar cerca de 433 (subteste 3) + 480 ms (4 retardos da rede), ou seja, 913 ms, mais o tempo levado na anlise do alarme no Gerente de Desempenho de Domnio. Ainda, nesse pior caso, deve ser considerado o tempo necessrio execuo do Espe-

78 cialista propriamente dito, embora esta deva ser, certamente, bastante rpida, em funo da natureza das aes que, normalmente, sero desencadeadas. O tempo total que pode decorrer entre a deciso de envio de um Alarme de Tendncia e o trmino da ao pelo Especialista deve ser, ento, limitado a cerca de, pouco menos de um segundo. No cenrio de aplicao do gerenciamento de desempenho que est sendo explorado, em prol do ServiMdia, a melhor opo seria o envio do Alarme de Tendncia diretamente ao cliente que est executando uma apresentao multimdia. Nesse caso, o tempo decorrido entre a deteco de uma variao que venha a gerar um alarme e o recebimento do mesmo pelo cliente bastante pequeno. Num pior caso, se o parmetro monitorado (o retardo) fosse obtido via SNMP, esse tempo consistiria de 10 ms (tempo de execuo do lao de monitorao pelo Inspetor de Desempenho, do primeiro teste) mais o tempo necessrio para o desencadeamento da comunicao entre o Inspetor de Desempenho e o cliente ServiMdia, que desprezvel, se ambos estiverem na mesma estao. Nesse mesmo cenrio, o Alarme de Tendncia poderia ser enviado tambm ao Servidor ServiMdia para que esse iniciasse os preparativos para a realizao de uma adaptao. Nesse caso, o tempo entre a deteco da variao que gerar o alarme e a recepo do alarme pelo Servidor do ServiMdia incluiria ainda um tempo de propagao pela rede.
5.3.3. Execuo do Inspetor de Desempenho em massa de dados real

A eficcia do sistema de Gerenciamento de Desempenho Pr-ativo proporcional taxa de acertos de suas previses. Pode ser considerado como um acerto o envio de um Alarme de Tendncia quando da deteco de uma variao que, se continuar, venha a causar a ocorrncia de uma falha de QoS. O envio de um alarme, dependendo da anlise do mesmo pelo Gerente de Desempenho de Domnio, pode gerar o envio de Especialistas para a realizao de aes. Caso a variao a partir da qual tenha sido gerado esse alarme no continue e, portanto, a falha de QoS no venha a ocorrer, as aes desencadeadas pelos Especialistas tero sido inteis. Esse alarme ser chamado de alarme falso. A Figura 28 apresenta uma primeira seqncia de amostras (da 9 a 39 na seqncia original) que foi selecionada como exemplo para anlise. Na Figura 28, podem ser vistos casos onde as aes dos Especialistas teriam sido inteis, como ocorre nas amostras 5, 13 e 20. A linha horizontal de ordenada 90 representa o limite do retardo para a ocorrncia de falha de QoS que foi utilizado nos testes. J na segunda seqncia de amostras exemplo, que est apresentada na Figura 29 e representa as amostras 310 a 359 da seqncia original, h Alarmes que podem ser considerados acertos, co-

79 mo os Alarmes das amostras 20, 31, 41 e 59. Nos casos das amostras 37 e 49, os Alarmes tambm foram considerados falsos. A freqncia de monitorao do retardo era de 12 Hz, ou seja, o perodo entre a obteno de cada amostra de 5 segundos. Isso significa que, no caso de um acerto como na amostra 20, as aes dos Especialistas teriam cerca de 5 segundos para que, por exemplo, fossem desencadeadas adaptaes no ServiMdia, antes que ocorresse a falha de QoS que levaria a uma falha de QoP. Esse tempo mais do que suficiente para a execuo das adptaes, que levam, no mximo, cerca de 2 segundos [27]. A situao definida acima como acerto pode ser estendida para o caso no qual o Alarme de Tendncia desencadeie aes que venham a evitar, ou at mesmo reduzir a valores tolerveis, a ocorrncia de uma falha de QoP, ainda que a falha de QoS que foi prevista ocorra.

80

Retardos (amostras 9 a 39 da seqncia original)

100

Retardo em ms

80 65 55 35 25 15 5 15 0 65

80 55 40 30 30 25 30 20 20

80 60 40 20 0

75 65 65 65 40 20 20 20 25 30

11

13

15

17 Alarmes

19

21

23

25

27

29

Retardos

Figura 28 - Primeira seqncia de amostras selecionadas para anlise

Limite para ocorrncia de falha de QoS

Retardos (amostras 310 a 359 da seqncia original)

140 120 100 80 60 40 20 0

Retardo em ms

110 95 80 65 30

105 110110105 75

110 95 90 75 60 55 65 60 55 90

105 100

115 110110

125 105105 110 75 45 15 50 85

115 95 70 35 75 85 65 95

105 100 75 45 85 85

25

10

11

13

15

17

19

21

23

25

27

29

31

33

35

37

39

41

43

45

47

49

Retardos

Alarmes

Figura 29 Segunda seqncia de amostras selecionadas para anlise

81

Excetuando-se as situaes onde a variao do retardo tal, que ao mesmo tempo que ultrapasse o limite para a variao acumulada e o limite para a variao em um intervalo entre duas observaes consecutivas, venha a ultrapassar o prprio limite para a ocorrncia de falha de QoS, caso que ocorre na amostra 6 da Figura 29, as falhas de QoS so precedidas de Alarmes de Tendncia que foram enviados em observaes anteriores. Ao longo das 720 amostras (apresentadas no Anexo A) usadas nesse teste equivalentes a duas horas de coleta do retardo, ocorreram 127 falhas de QoS (para o limite de 90 ms). Na realidade, por 127 vezes o retardo ultrapassou 90 ms. No caso da aplicao em questo, um fluxo de vdeo, a pouca variao do retardo, mesmo que com um alto valor absoluto (do retardo) no causa, necessariamente, falha de QoS. O que causa falha o esvaziamento do buffer de recepo do cliente e isso ocorre quando o retardo varia bruscamente, aumentando. Isso significa que nem todas essas 127 amostras de retardo maiores do que 90 ms causaro falhas de QoS para a aplicao. Considerando que a apenas a primeira amostra que ultrapassa 90 ms de uma seqncia de amostras superiores a 90 ms, causa falha, 49 dessas 127 amostras poderiam, de fato, ter causado falha de QoS. Destas 49 amostras que esto sendo consideradas como falhas nesse teste, 15, por serem causadas por variaes grandes dentro de um nico intervalo, no foram precedidas de Alarmes de Tendncia. O Alarme, nessas amostras, foi desencadeado no mesmo momento que ocorreu a falha. Esse poderiam ser considerados Alarmes inteis. Em outras 8 amostras no foram gerados alarmes antes ou sequer na prpria amostra. Isso se deveu ao fato do retardo estar alto, prximo ao limite para a deteco de falhas, variando abaixo e acima do limite, porm sem variar mais do que 35 ou 40 ms, que so os limites configurados como variaes mximas toleradas. Do total de falhas consideradas, que de 51, 24 das mesmas foram precedidas de Alarmes com antecedncias entre 5 e 20 segundos. Do total de alarmes que foram gerados, que de 76, 24 dos mesmos foram Alarmes falsos, ou seja, no houve falha de QoS em at 20 segundos aps os mesmos. As estatsticas sobre esse teste que foram consideradas mais relevantes esto apresentadas de forma resumida na Tabela 8.
Tabela 8 - Estatsticas consideradas relevantes no terceiro teste
Fato Quantidade de amostras em 2h Falhas (Amostras que ultrapassaram 90 ms) Falhas no precedidas de outra falha Falhas precedidas de alarme Alarmes gerados 5 s antes da falha Alarmes gerados 10 s antes da falha Alarmes gerados 15 s antes da falha Alarmes gerados 20 s antes da falha Alarmes gerados no momento da falha Falhas no precedidas por alarmes Quantidade 720 127 49 24 10 7 5 2 15 8

Percentual 100 % (Referncia) 49,0 % 20,4 % 14,3 % 10,2 % 4% 30,6 % 16,3 %

82 Essas anlises foram feitas a partir da determinao, inicialmente, feita de forma arbitrria, dos limites para ocorrncia de falhas, para envio de Alarmes e para as variaes mximas toleradas. Aps a obteno dos primeiros resultados deste teste, esses valores limite foram variados, tambm de forma arbitrria, para que fossem exploradas as possibilidades e limitaes do sistema proposto nesse trabalho. A determinao precisa destes limites , conforme j foi citado, complexa e deve envolver um conhecimento do baseline da rede, de forma a se reduzir a ocorrncia de Alarmes falsos e se evitar transincias nas aes. Neste teste, no houve o desencadeamento de aes. Sendo assim, no possvel analisar a conseqncia das mesmas, como, por exemplo, adaptaes, no comportamento do retardo. possvel que as prprias aes venham a reduzir o trfego na rede e, conseqentemente, o retardo diminua ou, ainda, venham a alterar as exigncias de QoS (por causa das adaptaes) de forma que o limite do retardo que venha a causar uma falha seja aumentado. Um exemplo desta ltima situao seria a diminuio da resoluo de um fluxo de vdeo, que levaria a um aproveitamento diferente dos buffers do cliente de forma que um maior retardo fosse tolerado. Outra conseqncia da falta do desencadeamento de aes a impossibilidade de se avaliar o grau de transincia que pode vir a ocorrer por causa das mesmas. Um exemplo dessa transincia seria a realizao de adaptaes freqentes pelas aplicaes, fato que, sem dvida, prejudicaria a QoP percebida pelo usurio.
5.3.4. Consideraes sobre os resultados

Os resultados obtidos nos testes que foram realizados indicam que a realizao de gerenciamento pr-ativo utilizando-se no s de uma linguagem interpretada, porm, totalmente independente de plataforma, mas tambm de uma infra-estrutura de mobilidade, vivel. O mecanismo principal, o Inspetor de Desempenho, apresentou um baixo tempo de execuo, ainda que interpretada, e o tempo entre a deteco de uma variao e a execuo de uma ao tambm pequeno. A evoluo do hardware computacional s vir a melhorar o desempenho dessa execuo. Algumas limitaes de um sistema de gerenciamento desse tipo j podem ser visualizadas. A possibilidade de ocorrer a reduo da exigncia de QoS, com possveis perdas para os usurios, sem que, de fato, falhas de QoS venham a ocorrer, por conta do envio de um alarme falso, uma dessas limitaes. A transincia nas aes devido necessidade de se monitorar muitos parmetros de controle tambm uma limitao dessa proposta. A escalabilidade dessa proposta pode ser questionada, caso o nmero de elementos a serem gerenciados ou a freqncia do envio de Alarmes sejam grandes. No entanto, espera-se que apenas

83 aquelas aplicaes que so crticas sejam as escolhidas para serem gerenciadas de forma prativa. A escolha dos parmetros de controle que devem ser monitorados e a sua freqncia tambm deve ser feita de forma cuidadosa. Apenas aqueles que so relevantes para a garantia de QoS devem escolhidos. A determinao da quantidade de elementos gerenciados em um domnio tambm deve ser cuidadosamente considerada, para evitar que o Gerente de Desempenho de Domnio seja sobrecarregado de Alarmes. 5.4. Resumo do captulo Este captulo apresentou, inicialmente, a metodologia que foi utilizada para a realizao dos testes. Na seo seguinte, foram apresentados os testes realizados e os resultados obtidos, sem que os mesmos fossem analisados. Os testes compreenderam a execuo do Inspetor de Desempenho isolada, a interao entre o Inspetor de Desempenho e o Gerente de Desempenho de Domnio para o envio de Especialistas e execuo do Inspetor de Desempenho em uma amostra de observaes do retardo em uma rede real. Na terceira seo os resultados foram analisados, com o objetivo de que fossem avaliadas a eficincia, a eficcia, as vantagens e as limitaes da proposta.

84

Captulo 6 - Concluses e trabalhos futuros

A primeira seo deste captulo apresenta algumas consideraes sobre a arquitetura, resumindo-a e apontando as suas principais vantagens e limitaes. Os resultados obtidos a partir da implementao do prottipo so tambm considerados. A seo seguinte discorre sobre os trabalhos futuros que podem ser realizados a partir da arquitetura de gerenciamento de desempenho pr-ativo. Por fim, na seo 6.3, so apresentadas as consideraes finais do trabaho. 6.1. Consideraes sobre a arquitetura proposta A arquitetura que proposta nesta dissertao tem como objetivo realizar o gerenciamento de desempenho pr-ativo (GDPA). Ela foi desenvolvida tendo como base a AGAD [19], que uma arquitetura de gerenciamento distribuda que se utiliza de tecnologia ativa. Os principais componentes da arquitetura so um Gerente de Desempenho de Domnio, que o responsvel pelo gerenciamento de desempenho em um domnio, um Inspetor de Desempenho, que quem realiza a monitorao de parmetros de um sistema de controle, calculando a variao dos valores dos mesmos e enviando Alarmes de Tendncia quando essas variaes ultrapassam limites configurados; e de Especialistas, que so enviados pelo Gerente de Desempenho de Domnio aos elementos gerenciados para desencadearem aes com o objetivo de minimizar as conseqncias ou evitar a ocorrncia da possvel falha de QoS alertada pelo Alarme de Tendncia. O GDPA utiliza-se da tecnologia ativa para que capacidades de processamento local sejam instaladas nos elementos a serem gerenciados, reduzindo assim o trfego na rede. Esse trfego limitado apenas a Alarmes, cdigos de Especialistas e pequenas mensagens. A tecnologia ativa viabiliza ainda que essas capacidades de processamento local, em particular do Inspetor de Desempenho e do Gerente de Desempenho de Domnio, possam ser atualizadas ou substitudas sem que seja necessria a espera de longos processos de padronizao. Uma flexibilidade do GDPA ser independente de plataforma, por ser inteiramente programado em linguagem Java. O seu desenvolvimento utiliza-se do que previsto no desenvolvimento de software orientado a componentes. Esta funcionalidade, aliada ao uso de Java e da tecnologia ativa viabiliza a possibilidade de que os diversos componentes de software da arquitetura possam ter o seu cdigo substitudo em tempo real, respeitando-se apenas restries momentneas de sincronizao de forma a se evitar inconsistncias nos atributos, variveis e mtodos que esto sendo executados.

85 O emprego de um sistema que utilize a arquitetura de GDPA no se limita apenas ao gerenciamento dos elementos da rede. Foram citados casos onde a utilizao do sistema, em razo de suas caractersticas, pode trazer benefcios para os usurios atravs da economia de recursos e da reduo do trfego na rede. Esses casos estendem a abrangncia do gerenciamento para aplicaes, servios de comunicao, ns de comutao e enlaces de comunicao. Visando obter dados referentes ao desempenho que mostrassem a viabilidade de um sistema de gerenciamento pr-ativo programado em Java, foi implementado um prottipo que inclua o Gerente de Desempenho de Domnio, o Inspetor de Desempenho e dois Especialistas. O desenvolvimento desse prottipo foi realizado de acordo com o que prev a anlise orientada a objetos. Foram apresentados os casos de uso, o modelo conceitual, os diagramas de seqncia e a hierarquia de classes da anlise e da implementao. O prottipo explorou apenas um dos paradigmas disponveis na tecnologia ativa, os agentes mveis. Utilizando-se o prottipo, trs tipos de testes foram realizados: (i) execuo isolada do Inspetor de Desempenho, (ii) interao entre o Inspetor de Desempenho e o Gerente de Desempenho de Domnio o tratamento de Alarmes de Tendncia, e (iii) execuo do Inspetor de Desempenho em uma amostra com a variao do retardo em uma rede real. Os resultados obtidos nos testes permitiram a constatao de que, mesmo com o uso de uma linguagem interpretada, como Java, e de uma infra-estrutura de mobilidade, j vivel, com as capacidades de processamento disponveis nos dias de hoje, o gerenciamento de desempenho prativo de forma eficiente. Esses resultados omitiram o tempo necessrio anlise do Alarme de Tendncia pelo Gerente de Desempenho de Domnio, que, em funo das tcnicas que forem utilizadas (como, por exemplo, Inteligncia Artificial), pode vir a ser significativo. Nesse caso, uma estao com maior capacidade de processamento seria necessria. Os resultados que amparam a afirmao de viabilidade do gerenciamento de desempenho pr-ativo so aqueles detalhados na seo 5.2, que podem assim ser resumidos: a execuo lao de monitorao do Inspetor de Desempenho dura, em um AMD K6 de 475 MHz, cerca de 10 milissegundos. J em um AMD Athlon de 1,3 GHz, esse tempo cai para menos de 2 milissegundos. o tempo de reao, entre a deteco de uma variao que, caso continue, causar uma falha de QoS, e a instanciao de um Especialista para a realizao de uma ao , no pior caso, quando usadas estaes AMD K6 II de 500 MHz e uma rede cujo retardo seja de 120 milissegundos, menor do que 1 segundo.

86 atravs da precisa configurao dos valores limites para a variao de um parmetro a ser monitorado, a eficcia do sistema na previso de falhas de QoS pode ser grande, prevendo uma grande parte das mesmas, por intermdio dos alarmes que so acertos, ou seja, que, de fato, prevm falhas de QoS. O envio do Alarme de Tendncia diretamente s aplicaes interessadas no comportamento do parmetro de controle que monitorado foi considerado como uma forma de se diminuir o retardo para o incio do desencadeamento de aes com vistas a minimizar os efeitos da falha de QoS que pode acontecer, uma vez que, nesse caso, no existiria a interao entre o Inspetor de Desempenho e o Gerente de Desempenho de Domnio. Esses valores permitem a inferncia de que, com o aumento da capacidade de processamento disponvel no hardware computacional e da taxa de transferncia da rede, a eficincia da arquitetura ser bem maior, pois sero ainda menores o consumo de tempo de CPU e o retardo na rede. Assim, a freqncia de monitoramento dos parmetros, bem como o nmero destes que podem ser monitorados, podero ser maiores. As principais limitaes que j podem ser visualizadas para o emprego da arquitetura so a transincia no desencadeamento de aes quando a variao do parmetro monitorado oscilar com grande amplitude; e a ocorrncia de Alarmes falsos, quando houver variaes grandes. A eficcia pode ser melhorada e o efeito das limitaes citadas pode ser diminudo com a cuidadosa escolha dos limites a serem monitorados, problema que foi deixado fora do escopo desta dissertao. 6.2. Trabalhos futuros A anlise do Alarme de Tendncia pelo Gerente de Desempenho de Domnio e a determinao dos valores limites para a configurao do Inspetor de Desempenho podem ser apontados como os principais trabalhos futuros. A anlise do alarme deve, ao mesmo tempo, ser rpida, e levar em considerao o mximo de informaes possvel para que seja eficaz no tempo que ainda estiver disponvel at a provvel falha de QoS. O conhecimento do baseline da rede essencial. O uso de tcnicas de Inteligncia Artificial j foi considerado [24] e pode aumentar a eficcia dessa anlise atravs do aprendizado ao longo do prprio funcionamento do gerenciamento de desempenho pr-ativo. A determinao dos valores limite importante para que se tente minimizar a ocorrncia de Alarmes falsos. O baseline da rede tambm ser necessrio para essa determinao. Um conhecimento, ou possvel configurao, dos buffers disponveis nas estaes ou outros elementos ge-

87 renciados e das capacidades de processamento disponveis, poder ajudar no clculo desses limites. A anlise da influncia da oscilao na variao do parmetro monitorado no desencadeamento de aes tambm dever ser considerada na determinao desses limites ou mesmo impor um novo limite, como, por exemplo, um nmero mximo de desencadeamento de aes por certo intervalo de tempo. Outro trabalho que necessrio a anlise do desempenho do Gerente de Desempenho no tratamento de um nmero grande de Alarmes de Tendncia em um pequeno intervalo de tempo. A extenso do uso do gerenciamento pr-ativo em outras reas funcionais de gerenciamento como, por exemplo, segurana e falhas, tambm pode ser considerado um trabalho futuro relacionado arquitetura que proposta nesta dissertao. O uso da tecnologia ativa, seja das redes ativas ou dos agentes mveis, sempre dever estar subordinado a condies severas de segurana, uma vez que o envio e a execuo automticos de programas para ns de comutao e estaes o objetivo desta tecnologia. O gerenciamento de desempenho pr-ativo que proposto nesse trabalho prev ainda a atualizao dos componentes de software da arquitetura em tempo de execuo. , portanto, um trabalho futuro, a definio de um modelo de segurana que permita que as funcionalidades previstas na arquitetura sejam desencadeadas sem riscos para os tanto para proprietrios das redes e estaes quanto para os usurios. 6.3. Consideraes finais O trabalho integrou reas de conhecimento novas na computao e que esto sendo utilizadas em muitas pesquisas, como agentes mveis, Java na independncia de plataforma e distribuio de processamento, com a finalidade de realizar o gerenciamento de desempenho pr-ativo em tempo real. O prottipo implementado mostrou que a construo de um sistema baseado na arquitetura j pode ser considerada vivel e tambm que, com os aumentos da capacidade de processamento e da necessidade por garantias de QoS, um melhor aproveitamento dos recursos da rede e melhores nveis de servios podem ser prestados aos usurios com o uso da arquitetura.

88

Referncias
[1] Bohoris, C., Pavlou, G., Cruickshank, H., Using Mobile Agentes fos Network Performance Management, IEEE/IFIP Network Operations and Management Symposium (NOMS00), Honolulu, Hawaii, 2000. [2] BRISA (Sociedade Brasileira para Interconexo de Sistemas Abertos), Arquiteturas de Redes de Computadores OSI e TCP/IP, Makron Books, 1994. [3] Keshav, S. e Sharma, R., Achieving Quality of Service through Network Performance Management, Proceedings of Network and Operating System Support for Digital Audio and Video, Cambridge, 1998 . [4] Rubinstein, M.G., Duarte, O.C.M. e Pujolle, G., Evaluating the Performance of Mobile Agents in Network Management, Proceedings of IEEE Global Telecommunications Conference, 1999. [5] Bieszczad, A., Pagurek, B. e White, T., Mobile Agents for Network Management, IEEE Communication Surveys, Fourth Quarter, 1999. [6] [7] Huston, G., Internet Performance Survival Guide, Wiley Computer Publishing, 2000. Bradshaw, J. et al, Software Agents, AAAI Press / The MIT Press, Menlo Park, California, 1997. [8] Raz, D. e Shavitt, Y., Active Networks for Efficient Distributed Network Management, IEEE Communications Magazine, Maro de 2000. [9] Bush, S. F., Active Virtual Network Management Protocol, 13th Workshop on Parallel and Distributed Simulation (PADS99), maio de 1999. [10] Kawamura, R. e Stadler, R., Active Distributed Management for IP Networks, IEEE Communications Magazine, Abril de 2000. [11] Psounis, K., Active Networks: Applications, Security, Safety and Architectures, IEEE Communications Surveys, Abril de 1999. [12] Sabata, B, Chatterjee, S., Davis, M. Sydir, J. J. e Lawrence, T. F., Taxonomy for QoS Specifications, WORDS97, Newport Beach, California, 1997. [13] Schwartz, B., Jackson, A.W., Strayer, T., Zhou, W., Rockwell, D. e Partridge, C., Smart Packets: Applying Active Networks to Network Management, ACM Transactions on Computer Systems, Fevereiro de 2000.

89 [14] Hu, C., Chen, W., A Mobile Agent-based Active network Architecture, International Conference on Parallel and Distributed Systemas, ICPADS00, IEEE, 2000. [15] Ferreira, A.B.H., Dicionrio Bsico da Lngua Portuguesa, Folha de So Paulo, 1995. [16] Gomes, A.T.A., Um Framework para Proviso de QoS em Ambientes Genricos de Processamento e Comunicao, Dissertao de mestrado, Departamento de Informtica, PUCRio, Rio de Janeiro, 1999. [17] Goldszmidt, G. e Yemini, Y., Distributed Management by Delegation, 15a conferncia internacional sobre sistemas de computao distribudos, 1995. [18] Tennenhouse, D.L. et al, A Survey of Active Network Research, IEEE Communications Magazine, janeiro de 1997. [19] Dumont, A.P.M., Arquitetura de Gerenciamento de Rede Ativa Distribuda, Dissertao de Mestrado, NCE-UFRJ, outubro de 2002. [20] Wheterall, D.J., Active Network Vision and Reality: Lessons from a Capsule-based system, 17o Simpsio em Princpios de Sistemas Operacionais da ACM, SOSP99, dezembro de 1999. [21] Object Management Group (OMG), Unified Modeling Language Specification (draft), v 1.4, fevereiro de 2001. [22] Brown, A. e Wallnau, K.C., The Cuurent State of CBSE, IEEE Software Magazine, outubro de 199Acum. [23] Data Communications, Proactive LAN Management, Data Communications Magazine, maro de 1993. [24] Franceschi, A.S.M., Rocha, M.A., Weber, H.L. e Westphall, C.B., Proactive Network Management Using Remote Monitoring and Artificial Intelligence Techniques, Proceedings of the 2nd IEEE Symposium and Communications (ISCC97), junho de 1997. [25] Pacifici, G. e Stadler, R., An Architecture for Performance Management of Multimedia Networks, Proceedings of the IFIP/IEEE International Symposium on Integrated Network Management, maio de 1995. [26] Ghinea, G., Thomas, J.P., Fish, R.S. Quality of Perception to Quality of Service Mapping Using a Dynamically Reconfigurable Communication System, IEEE Global Telecommunications Conference, Rio de Janeiro, Brazil, 1999.

90 [27] Gomes, R.L., Autoria e Apresentao de Documentos Multimdia Adaptativos em Redes, Dissertao de Mestrado, NCE/IM/UFRJ, 2001. [28] Cunha, E.C., Uma Estratgia de Criao e Apresentao de Documentos Multimdia Adaptativos em Rede, Dissertao de Mestrado, NCE/IM/UFRJ, 2000. [29] ITU-T, Rec X.739, Information Technology Open Systems Interconnection, Systems Management Functions Metric Objects and Attributes, ITU-T, 1992.
[30]

Martin-Flatin, J.P., Znaty, S. e Hubaux, J.P., A Survey of Distributed Enterprise Network and Systems Management, Journal of Network and Systems Management, 1999.

[31] Object Management Group, The Common Object Request Broker: Architecture amd Specification (CORBA), Verso 2.0, 1995. [32] Deitel, H.M. e Deitel, P. J.. Java, How to Program, Ed. Prentice Hall, quarta edio, 2001. [33] Stevens, W.R., Unix Networking Programming, Ed. Prentice Hall, segunda edio, 1998. [34] Rubinstein, M.G., Duarte, O.C.M., Evaluating Tradeoffs of Mobile Agents in Network Management, Networking and Information Systems Journal, 1999. [35] Wetherall, D.J. e Tennenhouse, , D.L., Tha Active IP Option, Telemedia Networks and Systems Group, Laboratoty for Computer Science, Massachusetts Institute of Technology, 1996. [36] Alexander, S. et al, Active Network Encapsulation Protocol, RFC draft, Julho de 1997. [37] Sluman, C., A Tutorial on OSI Management, Computer Networks Magazine, Vol 17, nos 4 e 5, outubro de 1989. [38] Reiser, H. e Voigt, G., Security Requirements for Management Systems using Mobile Agents, Proceedings of the Fifth Symposium on Computers and Communications: ISCC, Antibes, Frnaa, 2000, p.160-165. [39] Vicente, J. e Campbell, A.T., Genesis: Toward Programmable Virtual Networking, Workshop on Open Signaling for ATM, Internet and Mobile Networks, OPENSIG 98, Outubro de 1998. [40] Fuggeta, A., Picco, G.P. e Vigna, G., Understanding Code Mobility, IEEE Transactions on Software Engineering, IEEE, maio de 1998. [41] Picco, G.P., Code: A Lightweight and Flexible Mobile Code Toolkit, Proceedings of the 2nd International Workshop on Mobile Agents 98, September de 1998.

91 [42] Larman, C., Applying UML and Patterns, Ed, Prentice Hall, primeira edio, 1997. [43] AdventNet, SNMPv1, v2 and V3 Java API, disponvel em http://www.adventnet.com, AdventNet, 2002. [44] Hardaker, W., NET-SNMP Project, disponvel em http://www.net-snmp.org/, Carnegie Mellon University, 2002. [45] Davie, B. S. e Rekhter, Y., MPLS: Technology and Applications, Ed Morgan Kaufmann Publishers, Primeira edio, 2001. [46] Ball, B. Red Hat Linux 7.2 Unleashed, Ed Sams, Primeira edio, 2001. [47] El-Kharashi, M. W., ElGuibaly, F. e Li, K. F., Quantitative Analysis for Java Microprocessor Architectural Requirements:Instruction Set Design, Workshop on Hardware Support for Objects And Microarchitectures for Java (no ICCD'99), Texas, 1999. [48] Ploog, H. et all, A Two Step Approach in the Development of a Java Silicon Machine (JSM) for Small Embedded Systems, Workshop on Hardware Support for Objects And Microarchitectures for Java (no ICCD'99), Texas, 1999. [49] Black, D. P., Building Switched Networks, Ed Addison Wesley Longman, 1999. [50] Rekhter, Y. e Davie, B., MPLS Technology and Applications, Ed Academic Press & Morgan Kaufmann, 2000. [51] Schmidt, K. J. e Maura, D., SNMP Essencial, Ed Campus, 2001. [52] Montgomery, D. C. e Runger, G. C., Applied Statistics and Probability for Engineers, Ed John Wiley & sons, segunda edio, 1999. [53] Sun Microsystems, Java 2 Platform, Standard edition, v 1.3.1, disponvel em http://java.sun.com, Sun Microsystems, 2002. [54] ITU-T, Rec X.739, Information Technology Open Systems Interconnection, Systems Management Functions Summarization Function, ITU-T, 1992. [55] StatSoft, Statistica v5, disponvel em http://www.statsoft.com/, 2001.

92

Anexo A Valores referentes ao terceiro teste

Am 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 Ret 20 5 40 110 25 65 35 25 5 15 80 55 65 15 0 30 30 65 80 25 40 55 20 20 30 75 65 20 20 65 65 20 25 40 30 70 0 0 0 0 0 25 80 95 60 55 10 0 5 15 20 55 75 80 85 90 105 95 35 30 20 5 65 75 60 80 90 10 75 105 Al No No No Int No No No No No No Int No No No No No No No No No No No No No No Int No No No No No No No No No No No No No No No No Int No No No No No No No No No No No No No Acum No No No No No No No No No No No No No Am 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 Ret 35 10 60 95 5 40 60 10 45 10 65 30 30 40 55 95 80 55 35 75 70 90 85 60 30 85 70 75 95 55 75 65 60 20 30 45 55 45 45 45 25 20 30 30 55 65 50 20 50 55 55 20 25 100 15 15 25 20 5 5 15 20 5 35 15 65 30 30 35 10 Al 15 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 15 0 0 0 15 0 0 0 0 0 15 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 15 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Am 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 Ret 95 80 55 35 75 70 90 85 60 30 65 70 75 95 55 65 90 95 110 115 75 0 50 65 85 0 5 0 0 0 0 20 90 15 55 10 25 0 25 20 0 0 0 0 0 0 0 0 15 0 30 35 0 0 55 0 0 0 25 0 0 35 40 45 50 65 80 60 60 85 Al 0 0 15 0 0 0 15 0 0 0 0 0 0 8 0 0 0 0 0 8 0 0 0 0 0 0 8 0 0 0 0 0 0 0 15 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 8 0 Am 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 Ret 105 110 100 95 100 85 80 95 0 0 15 0 0 0 35 0 0 35 0 0 75 10 0 0 25 75 65 60 20 30 45 55 45 45 45 25 20 30 30 55 65 50 20 50 55 55 20 25 100 15 15 25 20 5 5 15 20 5 35 15 0 0 45 100 50 55 75 0 0 0 Al 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 15 0 0 0 0 15 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 15 0 0 0 0 0 0 0 0 0 0 0 0 0 0 15 0 0 0 0 0 0 Am 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 Ret 45 20 0 0 5 65 0 0 0 15 45 60 90 80 85 55 40 65 70 85 90 110 25 15 35 60 75 95 110 80 30 65 105 110 110 105 75 95 110 90 60 55 10 55 65 60 75 90 105 100 115 110 110 125 45 15 50 75 85 105 105 110 115 95 70 25 35 75 45 20 Al 0 0 0 0 0 0 0 0 0 0 0 0 0 0 8 0 0 0 0 0 0 8 0 0 0 0 0 0 8 0 0 0 0 0 15 0 0 0 0 0 0 0 0 0 0 0 0 0 8 0 0 0 8 0 0 0 0 0 0 8 0 0 0 0 8 0 0 0 0 15 Am 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 Ret 95 105 100 75 45 85 85 90 90 25 55 80 45 50 10 30 70 90 105 100 110 125 125 115 100 20 5 15 25 40 35 60 85 90 105 110 100 75 50 15 50 65 115 120 90 85 100 105 110 105 60 120 80 40 75 105 115 120 110 120 105 65 35 65 75 90 65 100 90 95 Al 0 0 0 8 0 0 0 15 0 0 0 0 0 8 0 0 0 0 15 0 0 0 8 0 0 0 0 0 0 0 0 0 0 0 8 0 0 0 0 0 0 0 0 0 15 0 0 0 0 0 0 0 0 15 0 0 15 0 8 0 0 0 0 0 0 0 8 0 0 15

93

Anexo A (cont) Valores referentes ao terceiro teste

Am 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 Ret 85 100 85 110 90 35 55 65 70 65 10 40 55 15 60 0 0 0 10 0 0 15 0 0 5 0 10 0 0 20 15 10 0 0 90 30 20 45 75 85 105 115 125 0 60 75 60 55 60 45 35 55 70 85 90 75 95 90 0 0 0 65 85 95 60 55 20 45 95 115 Al 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 15 0 0 0 8 0 0 8 0 0 0 8 0 0 0 0 0 0 0 8 0 0 0 0 0 0 0 0 8 0 0 0 0 0 15 0 Am 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 Ret 120 125 120 135 110 120 125 95 75 90 110 115 125 95 75 40 70 0 0 10 15 40 35 55 75 40 70 0 0 10 75 110 95 100 115 110 115 105 0 0 0 35 80 95 60 55 10 0 5 0 55 65 0 60 0 10 50 75 110 125 120 110 95 90 95 110 85 80 85 55 Al 0 0 0 8 0 0 0 0 0 0 0 8 0 0 0 0 0 0 0 0 0 0 0 0 8 0 0 0 0 0 15 15 0 0 0 0 0 0 0 0 0 0 15 0 0 0 0 0 0 0 0 0 0 0 0 0 0 8 15 0 0 0 0 0 0 0 0 0 0 0 Am 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 Ret 40 35 75 60 75 85 35 75 80 60 35 60 85 45 40 60 10 0 0 20 65 80 75 90 110 75 60 50 35 45 55 70 85 95 100 110 25 65 30 30 40 55 95 80 55 35 75 70 85 85 60 30 75 70 75 85 55 70 65 60 20 30 45 55 45 45 45 25 20 30 Al 0 0 15 0 0 0 0 15 0 0 0 0 8 0 0 0 0 0 0 0 0 8 0 0 0 0 0 0 0 0 0 0 8 0 0 0 0 0 0 0 0 0 15 0 0 0 15 0 0 0 0 0 15 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Am 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 Ret 30 55 65 85 110 115 125 120 95 90 85 90 95 115 110 105 95 85 80 95 75 80 90 95 115 120 0 30 45 65 75 80 0 0 0 0 0 0 0 0 0 5 0 0 45 75 50 55 75 65 70 85 95 100 85 75 45 50 65 45 40 50 0 0 0 5 0 0 0 0 Al 0 0 0 8 0 0 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 8 0 0 0 0 0 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 8 0 0 0 0 0 0 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Am 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 Ret 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5 0 Al 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

94