Meta-Gerência de Agentes Procuradores Usando SNMP

Meta-Gerência de Agentes Procuradores Usando SNMP Jordan Janeiro, Anderson Oliveira da Silva, Sérgio Colcher Departamento de Informática – PUC-Rio Rua Marquês de São Vicente 225 – Rio de Janeiro – RJ – Brazil [email protected], {oliveira,colcher}@inf.puc-rio.br

Abstract. Following the assumptions that: (i) the SNMP protocol is a widely accepted and used protocol and (ii) many equipments, from different types and sizes, adopt some form of mechanism that allows their monitoring or even their management in a broader sense, this work presents a solution that allows the integration of these equipments in an environment that can be managed through the SNMP protocol. The solution is based on proxy agents that can be downloaded to device controllers at runtime in order to allow monitoring and control. The management of the agents themselves (loaded and executed in the various controllers) is also administered by configuration management mechanisms (also using SNMP protocol). This scheme is what we called metamanagement. Extensibility is provided by the use of eXtensible Agents, where sub-agents can be dynamically registered along with a master-agent. Resumo. Partindo-se das premissas que: (i) o protocolo SNMP é um protocolo amplamente utilizado para gerência de redes e (ii) uma série de equipamentos de diferentes tipos e portes, desde eletrodomésticos até PDAs, adotam hoje mecanismos próprios que, de uma forma ou de outra, permitem algum tipo de monitoramento ou até mesmo gerência de uma forma mais ampla, o objetivo desse trabalho é apresentar uma solução para permitir a integração desses equipamentos em um ambiente no qual é possível a gerência por meio do protocolo SNMP. A solução apresentada propõe a utilização de agentes procuradores, artefatos de software, enviados em tempo de execução para controladores de dispositivos para permitir o monitoramento e controle. A gerência dos próprios agentes procuradores instalados e executados nos diversos controladores também é administrada por mecanismos de gerência baseados no SNMP, configurando o que aqui se denominou meta-gerência. A base para a implementação e implantação dos agentes procuradores será a utilização dos chamados agentes extensíveis, onde sub-agentes são definidos de forma a permitir a extensão das funcionalidades de um outro agente préexistente (o agente mestre).

1. Introdução Redes de comunicação têm se tornado cada vez mais complexas. Dentre os motivos do aumento dessa complexidade está o desenvolvimento da capacidade para prover cada vez mais serviços e comportar cada vez mais usuários [Black 1995]. Tornou-se necessário desenvolver mecanismos eficientes de gerenciamento, importantes para monitorar constantemente o desempenho de uma rede e obter informações que possam

auxiliar no controle de sua estabilidade e disponibilidade de recursos, além de permitir seu planejamento e expansão. Atender às necessidades de gerenciamento de uma forma adhoc, sem o suporte de padrões, poderia levar a uma situação de complexidade intratável já que haveriam tantos protocolos quantos fossem os equipamentos de diferentes fabricantes. Surgiram, então, protocolos como o SNMP e o CMIP, cujo objetivo foi exatamente o de serem adotados pelos diversos fabricantes como padrões, facilitando a tarefa de gerenciar os diversos dispositivos pela unificação de conceitos e mecanismos de uma forma geral. Não obstante, uma série de equipamentos de diferentes tipos e portes, desde eletrodomésticos até PDAs, surgiram adotando mecanismos próprios para permitir algum tipo de monitoramento ou até mesmo gerência de uma forma mais ampla. O objetivo desse trabalho é apresentar uma solução para permitir a integração desses equipamentos em um ambiente no qual é possível a gerência por meio do protocolo SNMP. A solução apresentada propõe a utilização de agentes procuradores, artefatos de software enviados em tempo de execução para controladores de dispositivos. A gerência dos próprios agentes procuradores instalados e executados nos diversos controladores também é administrada por mecanismos de gerência baseados no próprio SNMP, configurando o que aqui se denominou meta-gerência. Um cenário de uso para a plataforma desenvolvida neste trabalho é a sua aplicação no que tem sido comumente citado como ambientes de casas inteligentes [Alves 2003]. Nesse tipo de ambiente, os diversos elementos comuns presentes em uma residência, como persianas, aparelhos de ar-condicionado e geladeiras, assumem o papel de entidades com capacidade de processamento integradas em um ambiente de rede para prover diversas tarefas do cotidiano de maneira automatizada, sob o controle de uma central. Exemplos de tarefas são: a abertura de uma persiana de um cômodo da casa em uma determinada hora, o acionamento ou desligamento de um aparelho de arcondicionado, ou, ainda, a emissão de pedidos de compra de produtos que estão em falta em uma geladeira. Cada um dos elementos de uma casa inteligente, quando projetado, é programado para executar uma série restrita de tarefas ou fornecer um conjunto específico de informações que podem ser utilizadas por um controlador. Portanto, para que as tarefas possam ser acionadas, fabricantes devem implementar em seus dispositivos uma interface para que os mesmos possam ser controlados ou monitorados por uma central que toma as decisões das tarefas a serem acionadas. Com a plataforma desenvolvida neste trabalho, torna-se possível efetuar esse controle ou gerência através da interface SNMP, desde que todas as interfaces dos dispositivos da casa estejam disponíveis ao programador, permitindo que possam ser codificados agentes específicos capazes de se comunicar com os dispositivos e compreender a interface SNMP. Tornase também possível, com o auxílio do modelo de meta-gerência aqui proposto, efetuar a instalação dinâmica, em tempo de execução, desses agentes de forma a permitir a gerência via SNMP.

2. Ferramentas e Conceitos Básicos Alguns dos conceitos aplicados no decorrer do desenvolvimento deste trabalho, bem como ferramentas e tecnologias de suporte à implementação da plataforma, encontramse descritas nesta seção.

2.1. Agentes Procuradores Para o cenário de aplicação apresentado na seção 1, a plataforma proposta permite que subagentes sejam desenvolvidos para cada dispositivo de forma a implementar o conceito de agentes procuradores (agentes proxy), ilustrado na Figura 1. O agente procurador é um agente que é capaz de se comunicar por intermédio dos protocolos usados nos dois lados da comunicação. Seu objetivo é transformar as mensagens de um protocolo em mensagens equivalentes a do outro protocolo [Stallings 1997]. A ferramenta implementada permite que novos agentes, associados a novos dispositivos, possam ser integrados dinamicamente ao ambiente. Estação Gerente Processo Gerente

Agente Proxy

Dispositivo Proxied

Função de Mapeamento

Processo Agente

Processo Agente

IP

IP

Arquitetura de Protocolos utilizada pelo dispositivo proxied

Protocolos de Rede

Protocolos de Rede

Protocolos de Rede

SNMP

SNMP

UDP

UDP

Interrede

Arquitetura de Protocolos utilizada pelo dispositivo proxied Protocolos de Rede

Rede

Figura 1 – Arquitetura de um Agente Procurador

2.2. Agentes Extensíveis Se uma nova funcionalidade deve ser monitorada em um dispositivo, é necessário adicionar o objeto correspondente na base de informações gerenciais e adicionar o monitoramento da variável no agente que implementa a MIB em questão. Nessa situação, surge um empecilho: toda vez que uma nova funcionalidade precisa ser monitorada, deve-se retirar o agente do estado de execução, implementar a nova funcionalidade e colocá-lo novamente no estado de execução. O protocolo denominado AgentX surgiu para permitir o monitoramento de novos objetos em um agente sem que o mesmo seja retirado de execução, acoplando, em tempo de execução, os novos módulos que implementam novas variáveis. Para que a facilidade da extensibilidade de agentes se tornasse uma realidade, foi necessário definir um conjunto de especificações denominadas AgentX Framework [Daniele 2000]. Esse conjunto de especificações é composto, basicamente, por três tipos de entidades: o agente mestre, o subagente e o protocolo de comunicação entre essas duas entidades – o protocolo AgentX propriamente dito. O agente mestre é uma entidade que envia e recebe mensagens SNMP, possui tipicamente pouco ou nenhum acesso às informações de gerenciamento e é responsável pelo controle de acesso aos nós da árvore que representa a MIB. Subagentes são entidades que estão conectadas diretamente ao agente mestre, portanto não recebem diretamente mensagens SNMP. Mensagens SNMP são processadas pelo agente mestre e solicitações especifícas são enviadas aos subagentes (por intermédio do protocolo AgentX) para realizar as tarefas. Subagentes, no entanto, são, em última análise, responsáveis pela manipulação das informações de gerenciamento.

A terceira e última entidade é o protocolo de comunicação entre as duas entidades anteriores, o AgentX. Esse protocolo não deve ser confundido com o SNMP apesar da semelhança sintática entre os dois, já que, semanticamente, eles são bastante diferentes. A troca de mensagens via AgentX entre um agente mestre e um subagente deve ser invisível aos olhos da entidade SNMP que representa um gerente. Do ponto de vista de um gerente, um agente extensível se comporta exatamente como um agente qualquer. 2.3. NET-SNMP Para o desenvolvimento da solução proposta neste trabalho, foi utilizado um pacote que oferece suporte ao desenvolvimento de agentes SNMP: o NET-SNMP [NET-SNMP 2005], cuja implementação foi iniciada em um projeto na Universidade de CarnegieMellon. O NET-SNMP possui diversos utilitários, dentre eles: geradores de códigos para agentes, scripts para configuração de ambiente, suporte para agentes extensíveis, suporte a módulos dinamicamente carregáveis, ferramentas de gerenciamento, exemplos de MIBs e suporte a traps. A ferramenta oferece suporte aos protocolos SNMPv1, SNMPv2c e SNMPv3, além do protocolo para agentes extensíveis AgentX [NET-SNMP 2005]. 2.3.1. Geração de Código Para o desenvolvimento de agentes SNMP, o pacote NET-SNMP oferece uma ferramenta para a geração de código para a linguagem C, chamada mib2c, que faz a geração de código da estrutura do agente a partir de uma MIB já definida. O código gerado por esse utilitário disponibiliza funções que resolvem grande parte dos problemas relacionados à comunicação com os gerentes, além de fornecer uma forma estruturada de iniciação de agentes, de registro do OID do novo módulo gerado na árvore de OIDs das MIBs existentes e funções para tratamento de requisições de um gerente. O código gerado pela mib2c corresponde a uma estrutura semi-pronta, permeada de lacunas que deverão ser posteriormente preenchidas com o código personalizado de forma a tornar o agente realmente funcional. A ferramenta mib2c foi construída usando a linguagem de programação PERL e possui diversos utilitários (scripts) para geração de código dos agentes SNMP. Portanto, é fundamental que o ambiente gerador de agentes tenha suporte a essa linguagem. Para que o código desejado seja gerado com sucesso, deve ser informado ao utilitário um dos seguintes arquivos de configuração: o mib2c.scalar.conf, o mib2c.create-dataset.conf, o mib2c.array-user.conf e o mib2c.iterate.conf. O arquivo de configuração para a geração de tabelas através do mib2c utilizado nesse trabalho é o iterate (mib2c.iterate.conf). O código gerado por esse script consiste de uma tabela que é mantida fora da área de memória do agente, podendo estar mapeada em uma estrutura de dados qualquer, desde um vetor de n posições até um modelo de dados mantido em um banco de dados. Esse tipo de tabela, no entanto, exige a iteração sobre a estrutura de armazenamento que representa a tabela para que uma determinada linha possa ser localizada quando for solicitada por um gerente.

3. Meta-Gerência de Agentes Procuradores Usando SNMP A meta-gerência, conforme entendida neste trabalho, consiste em utilizar uma plataforma onde um gerente, através da interface SNMP, é capaz de gerenciar o código dos subagentes procuradores, que serão usados para permitir a comunicação entre o gerente e o dispositivo gerenciado (Figura 2). Essa plataforma é implementada, por um agente especial, desenvolvido segundo o esquema da meta-gerência aqui proposto, denominado meta-agente.

Figura 2 – Arquitetura da Meta-Gerência

O meta-agente é um subagente SNMP especial que implementa uma MIB desenvolvida neste trabalho, denominada META-MGT-MIB. Sua principal função é permitir o gerenciamento da configuração dos subagentes procuradores que, logo que entram em execução, se registram automaticamente junto ao agente mestre disponível no controlador. Esse controlador oferece o ambiente necessário para o funcionamento do agente mestre e dos subagentes, incluindo o meta-agente. Em particular, neste trabalho, é exigido que o controlador disponibilize as bibliotecas do pacote NET-SNMP para a correta execução dos agentes. É importante ressaltar que o controlador não precisa ser único. Pode-se ter diversos controladores, de forma que cada um seja responsável por um grupo determinado de dispositivos. Em um caso extremo, pode haver um controlador para cada dispositivo a ser gerenciado. Devido à extensibilidade oferecida pelo protocolo AgentX, utilizado entre o agente mestre e os subagentes, é possível manter o controle da inserção e retirada, em tempo de execução, de subagentes que, nesse caso, representam as interfaces de comunicação com os dispositivos. 3.1. META-MGT-MIB Para oferecer o serviço de meta-gerência, foi necessário definir uma MIB especial: a META-MGT-MIB. Essa MIB é composta por três tabelas: codeTable, agentTable e eventTable, que, conjuntamente, compõem toda a estrutura do meta-agente.

A codeTable (tabela de códigos) é a tabela responsável por armazenar códigos de agentes. Nessa tabela, poderão ser definidas ações relacionadas ao código, como: download, instalação e desinstalação. O campo responsável por armazenar a identificação associada a essa ação é o campo codeAction, que pode assumir os valores none, download, install e uninstall. A agentTable (tabela de agentes) controla as instâncias de execução de um agente. Cada uma de suas entradas referencia uma entrada da tabela de códigos e representa uma instância de execução dessa entrada. Na tabela de agentes, os controles são totalmente voltados para operações que correspondem ao início ou a interrupção da execução de um agente. A identificação de cada um desses estados é armazenada no campo agentExecControl, que pode assumir os seguintes valores: none, on e off. A eventTable (tabela de eventos) é a tabela na qual se define um evento para cada uma das ações disponíveis, tanto da tabela de código (download, instalação e desinstalação) como da tabela de agentes (execução e interrupção). Durante a criação de um evento, o gerente poderá especificar a mensagem que o evento deverá emitir, armazenando-a no campo eventDescription, assim como o tipo de evento que será disparado, de acordo com uma das opções: (i) uma notificação, (ii) um log ou (iii) uma notificação e um log. O campo que armazena a identificação do tipo de evento que pode ser disparado é o campo eventType, que pode assumir os seguintes valores: none, log, trap e log/trap. Tanto a tabela de códigos como a de agentes possuem campos que monitoram ações específicas como, por exemplo, sucesso no download ou falha na execução. Esses campos são responsáveis por armazenar índices de eventos que foram definidos e que serão disparados quando a ação que cada um deles monitora for executada. Por exemplo, um gerente poderá criar um evento de notificação com a mensagem “Download Completo!” e fazer com que o índice desse evento seja armazenado no campo que monitora o sucesso de um download. Assim, quando um código for transferido com sucesso, uma notificação com a mensagem estipulada será enviada ao gerente. Dessa maneira, fica mais fácil para o gerente tomar conhecimento do sucesso ou falha de execução de cada uma das ações solicitadas. Além dos objetos definidos na META-MGT-MIB, foi necessário utilizar alguns objetos que já se encontram definidos na MIB RMON. Um desses objetos é o EntryStatus, que é o responsável por controlar os estados de criação de uma entrada de uma tabela. O outro objeto usado é uma tabela, denominada logTable. Sua principal função é guardar o histórico das ações executadas por um agente. 3.2. Meta-Agente O meta-agente é a principal entidade do modelo de meta-gerência, já que com ele é possível tornar operacional o objetivo do modelo: gerenciar, dinamicamente, a configuração dos códigos de agentes através de uma única interface (SNMP). Com o uso desse agente, um gerente será capaz de carregar o código de um agente em um controlador de dispositivos, instalá-lo, desinstalá-lo, iniciar ou interromper sua execução dinamicamente. Todas essas ações são possíveis graças à arquitetura de meta-gerência e suas tabelas, definidas na META-MGT-MIB. A seguir serão descritas as estratégias utilizadas para manter a consistência entre as tabelas do modelo que permitem a metagerência.

No caso das tabelas implementadas pelo meta-agente, a integridade referencial ocorre entre a tabela de códigos e a tabela de agentes, de forma que a segunda é dependente da primeira. Em outras palavras, não é possível haver uma instância de um agente sem que o mesmo referencie um código. Assim, caso o gerente exclua um código da tabela de códigos, imediatamente, todos os agentes associados a esse código devem ser interrompidos e as respectivas entradas da tabela de agentes devem ser excluídas. Cabe também mencionar que, para minimizar o efeito negativo que haveria caso uma execução necessitasse de um campo que não estivesse preenchido, o meta-agente exige que o gerente preencha todos os campos associados a essa ação antes de iniciá-la. 3.3. O Processo de Meta-Gerência O principal foco da arquitetura da meta-gerência é estabelecer uma plataforma comum onde gerentes possam administrar códigos de agentes de forma dinâmica. A vantagem dessa administração é permitir que o processo para manter dispositivos gerenciáveis seja facilitado. Para oferecer ainda mais facilidades, o protocolo para permitir o gerenciamento do código é o mesmo protocolo que permite o gerenciamento de dispositivos, o SNMP. O modelo optou por utilizar o SNMP como protocolo de gerenciamento de códigos, pelo fato dele ser bastante conhecido por administradores de redes e pelo fato de já ter sido padronizado como um protocolo de gerenciamento. Mesmo que o dispositivo da rede seja gerenciado por um outro protocolo de gerenciamento qualquer, o modelo da meta-gerência ainda pode ser utilizado, pois se utiliza do conceito de agentes procuradores para mapear mensagens entre os protocolos envolvidos. A primeira tarefa que um gerente deve cumprir para que um novo subagente procurador entre em execução é tornar disponível o código desse agente no controlador em que ele deverá ser executado. Para isso, o meta-agente possibilita que o código de um subagente qualquer, identificado por uma URI, seja tranferido dinamicamente. A tabela ligada a esse processo de download é a codeTable. Os campos exigidos, nesse caso, são: codeURI, que representa a identificação do recurso (que, para efeito de implementação, utilizou-se um endereço da localidade – URL); codeDownloadEventSuccess, que representa o evento, definido pelo gerente, a ser disparado caso o download do subagente desejado tenha ocorrido com sucesso; e codeDownloadEventFailure, que representa o evento, definido pelo gerente, que deve ser disparado caso o download do subagente desejado tenha falhado. O código do subagente será armazenado em um repositório no qual estarão os códigos de todos os subagentes controlados pelo meta-agente. Após a obtenção do código de um subagente, o gerente deve instalar o código transferido, facilidade que também é oferecida pelo meta-agente. Da mesma forma que no processo de download, para que a instalação do código do subagente ocorra, alguns campos da tabela de códigos devem ser obrigatoriamente preenchidos. São eles: codeInstallCommand, que permite ao gerente especificar o comando de instalação do código do subagente; codeInstallEventSuccess, que representa o evento, definido pelo gerente, que deve ser disparado caso a instalação do subagente desejado tenha ocorrido com sucesso; e codeInstallEventFailure, que representa o evento, definido pelo gerente, que deve ser disparado caso a instalação do subagente desejado tenha falhado. É, portanto, de inteira responsabilidade do gerente fornecer o comando (string) de

instalação do código de um subagente. Presume-se que os utilitários de instalação utilizados estão disponíveis no controlador que armazena o meta-agente. A partir do momento que ocorre a instalação do código de um subagente, o meta-agente disponibiliza ao gerente a possibilidade de criação de uma entrada na tabela de agentes, permitindo que uma instância de execução do código desse subagente possa ser criada. Da mesma forma que é permitida a instalação do código de subagentes, também é implementado, no meta-agente, o processo de desinstalação de códigos. Esse processo é muito similar ao de instalação, pressupondo o preenchimento de alguns campos da tabela de códigos, como: codeUninstallCommand, que permite ao gerente especificar o comando de desinstalação do código do subagente; codeUninstallEventSuccess, que representa o evento que deve ser disparado caso a desinstalação do subagente desejado tenha ocorrido com sucesso; e codeUninstallEventFailure, que representa o evento que deve ser disparado caso a desinstalação do subagente desejado tenha falhado. Dessa forma, também fica sendo da responsabilidade do gerente especificar o comando (string) de desinstalação de um subagente utilizando o campo codeUninstallCommand. Por manter implementada a integridade referencial entre as tabelas de códigos e de agentes, caso o código de um subagente seja desinstalado e hajam instâncias de execução do mesmo, é tarefa do meta-agente interromper imediatamente a execução das instâncias, excluí-las da tabela de agentes e desinstalar o código especificado. Além das ações relacionadas ao código, o meta-agente possibilita o controle de ações relacionadas às instâncias de execução. Essas ações se referem tanto ao início da execução de um agente como a interrupção de sua execução. Quanto ao início da execução de um agente, é necessário que o gerente preencha campos tanto da tabela de agentes como da tabela de códigos. Na tabela de códigos é exigido apenas um campo, o codeExecCommand que se destina a armazenar o nome do agente instalado. Já na tabela de agentes, é necessário o preenchimento dos seguintes campos: agentExecArgs, que representa os argumentos que devem ser passados quando a execução de um agente for iniciada; agentTurnOnSuccessEventIndex, que representa o evento que deve ser disparado caso o início da execução de um subagente ocorra com sucesso; e agentTurnOnFailureEventIndex, que representa o evento que deve ser disparado caso o início da execução de um subagente falhe. Para que ocorra a interrupção da execução de uma instância, é necessário que mais alguns campos da tabela de agentes sejam preenchidos. Eles são: agentTurnOffSuccessEventIndex, que representa o evento que deve ser disparado caso o término da execução de um subagente ocorra com sucesso e agentTurnOffFailureEventIndex, que representa o evento que deve ser disparado caso o término da execução de um subagente falhe. Para permitir que novos recursos sejam gerenciados, são agregados dinamicamente ao agente mestre novos subagentes. Subagentes e agente mestre utilizam o protocolo AgentX para permitir que sua comunicação seja mantida e para permitir que esses novos subagentes sejam registrados. Portanto, quando um subagente é executado com sucesso, uma das primeiras medidas que ele deve tomar é registrar-se junto ao agente mestre para se incorporar ao agregado de agentes do qual ele fará parte. Quanto ao papel de execução que o meta-agente assume, é importante ressaltar que ele foi desenvolvido também como um subagente. Dessa forma, caso haja a

intenção de utilizá-lo em um ambiente no qual o agente mestre já esteja em execução (e não possa ser interrompido), ele poderá ser registrado dinamicamente.

4. Implementação O meta-agente foi desenvolvido usando a linguagem C, de acordo com o especificado pela ferramenta NET-SNMP, descrita na Seção 3.3. O meta-agente é composto por cinco módulos: o módulo que trata do controle da tabela de agentes, o módulo que trata da tabela de códigos, o módulo que trata a tabela de eventos, o módulo que trata da tabela de logs e um módulo muito importante de suporte, que mantém todas as estruturas em memória e fornece funções para a manipulação da mesma, permitindo que as funcionalidades atribuídas ao agente tornem-se realmente funcionais. Também é tarefa desse módulo implementar todas as ações relacionadas ao código de um agente (download, instalação e desinstalação) e às instâncias de execução do agente (execução e interrupção de execução). A estrutura básica dos quatro primeiros módulos foram geradas pelo utilitário mib2c, a partir do arquivo de configuração mib2c.iterate.conf. Quando um módulo é gerado pelo utilitário (mib2c), são gerados apenas: as estruturas de suas funções (busca, registro e tratamento de um objeto) e o código de inicialização do agente (registro do OID que representa o objeto, registro das funções de busca e tratamento, o campo que representa o índice da tabela e um arquivo de definições – contendo uma enumeração dos objetos da tabela que foram gerados). Portanto, fica a cargo do programador completar o código gerado, realizando as seguintes tarefas: (i) definir a estrutura de dados que irá representar a tabela, bem como as funções que irão manipulá-la; (ii) programar as funções de busca (de entradas), que foram geradas pelo utilitário; (iii) programar a função para tratar de um objeto quando ele for encontrado; (iv) definir as ações que o agente deve tomar quando uma operação de get é solicitada e (v) definir as ações que devem ser executadas quando uma operação de set é solicitada. Para gerar o meta-agente, é necessário agregar todos os módulos implementados pelo programador e compilá-los usando algumas diretivas e arquivos-cabeçalho fornecidos pela ferramenta NET-SNMP para que todo o código gerado pela ferramenta esteja operante. Logo após esse processo, será gerado o arquivo executável que representa o meta-agente e que estará pronto para execução.

5. Trabalhos Relacionados Em [Goldszmidt 1998] é apresentado o Delegated Agents, que exibe algumas características semelhantes ao modelo de meta-gerência aqui apresentado. O trabalho propõe um modelo para descentralizar e automatizar tarefas de gerenciamento de uma rede, que, geralmente, estão centralizadas em uma entidade de gerência. A esse modelo dá-se o nome de Management by Delegation (MbD). O MbD se baseia no princípio de que há aplicações de gerenciamento inteligentes que automatizam o processo de monitoramento, análise de dados e ações de controle relacionadas a um dispositivo de uma rede. A idéia dessas aplicações é permanecer coletando dados de um dispositivo e analisando-os. Caso esses dados apresentem alguma condição específica programada, ações de controle serão geradas nos dispositivos monitorados. Para permitir o MbD, o trabalho propõe que sejam enviadas, através da rede, partes de uma aplicação de gerenciamento aos dispositivos da rede que se deseja

monitorar, ao invés de trazer dados desse dispositivo para aplicações centrais de gerenciamento. Para efetuar tal procedimento, há a necessidade de carregar e executar dinamicamente os trechos da aplicação de gerenciamento, portanto, são utilizadas entidades presentes na tecnologia Delegated Agent. Essas entidades são: elastic server (servidor elástico), delegated agent(agente delegado) e delegation protocol (protocolo de delegação). O servidor elástico é uma entidade que é representada por um processo multithread. Nesse processo, tanto o código como o estado podem ser modificados, extendidos e/ou contraídos durante a execução. Nessa última situação, é criado um ambiente no qual é possível permitir a tradução e a ligação dinâmica de uma outra entidade do modelo, o agente delegado, ao servidor elástico. Além dessas características, é através do servidor elástico que: (i) é fornecido um ambiente de execução multithread, (ii) é permitido o controle remoto de agentes e a comunicação entre agente e entre processos e agentes. O agente delegado é a entidade que representa um trecho da aplicação de gerenciamento, permitindo que uma determinada função de gerenciamento seja automatizada. Esse trecho de código pode ser instanciado dinamicamente junto ao servidor elástico, que se encontra em uma localidade remota, agregando-se a ele e aumentando o número de funções de gerenciamento automatizadas desse agregado. O protocolo de delegação é a entidade usada para permitir que agentes delegados sejam despachados para o servidor elástico remoto e que suas execuções sejam controladas por ele. A principal ação fornecida pelo protocolo é a capacidade de efetuar transferência do código dos agentes delegados para o servidor elástico. Algumas ações são oferecidas por essa entidade em relação à execução do código de agentes delegados, são elas: instanciação, suspensão, continuação, interrupção de execução e remoção de agentes delegados. Outro trabalho que apresenta similaridades com o modelo de meta-gerência, é o apresentado em [Gavalas 1999]. Nele, propõe-se distribuir operações de gerenciamento e mover a inteligência dessas operações para o mais próximo possível dos recursos gerenciados. Uma primeira tentativa com esse mesmo objetivo foi o Management by Delegation (MbD) apresentado em [Goldszmidt 1998]. Porém alternativas para distribuir o gerenciamento usando a tecnologia de agentes móveis tem se demonstrado bastante interessantes. Nesse novo modelo foi desenvolvido uma aplicação de gerenciamento para coordenar as políticas de monitoramento e controlar os elementos da rede. Para evitar o impacto do tráfego de informações pela rede, agentes móveis (MA), que migram seqüêncialmente entre dispositivos gerenciados, dotados de um certo tipo de inteligência, executam alguns tipos de processamento local,. transferindo apenas informações relevantes para os gerentes, evitando assim aumento demasiado no tráfego de informações. Quando um MA é enviado a um host para obter determinadas informações, é necessário que haja uma entidade exercendo o processo de procuração entre o protocolo de gerenciamento do dispositivo e o MA. Essa entidade é o mobile agent server (MAS). Para permitir a geração do código de agentes móveis dinamicamente, foi desenvolvida uma outra entidade denominada mobile agente generator (MAG).

A arquitetura do modelo apresentado funciona da seguinte forma: quando um gerente deseja obter informações de gerenciamento de um dispositivo, é criado um MA para tal tarefa. Nesse MA podem ser especificadas informações dos objetos que se desejam monitorar bem como os hosts por onde o agente deve passar. Esse agente é recebido pela entidade MAS que atua exercendo todo o serviço de instrumentação, usando, por exemplo, o protocolo SNMP. Todas as informações são processadas pelo agente e apenas as informações relevantes são armazenadas. Comparando o modelo distribuído, o MbD e o modelo da meta-gerência aqui proposto, pode-se perceber que, tanto a entidade MAS, como o agente delegado e o subagente procurador exercem tarefas similares, ou seja, interagem diretamente com o dispositivo gerenciado. Porém, há uma grande vantagem da meta-gerência em relação ao MbD e ao modelo de agentes móveis: o meta-agente usa o próprio protocolo SNMP como um protocolo para gerenciamento dos códigos dos agentes, enquanto os outros dois modelos usam protocolos proprietários para essas tarefas. Assim, qualquer gerente SNMP legado pode fazer uso da meta-gerência para controlar dispositivos que não são gerenciáveis via SNMP. Quanto aos tipos de ações disponíveis, a meta-gerência se iguala ao MbD, pois ambos prevêm operações como: download, instalação, desisntalação, execução e interrupção da execução de agentes. Já no trabalho dos agentes móveis, essas operações não são disponibilizadas pois os códigos dos agentes são gerados dinamicamente na linguagem de programação Java e são enviados para seguirem um itinerário préprogramado de dispositivos, ou seja, o controle e a interrupção de itinerários é muito mais complexo. Por fim, ao contrário dos outros modelos, a meta-gerência não consome recursos dos dispositivos gerenciados, ou seja, não exige que esses dispositivos disponibilizem recursos para execução de processos localmente. Na meta-gerência, os agentes procuradores são executados no controlador, que disponibiliza os recursos necessários para estender a gerência dos dispositivos. Dessa forma, mesmo que o dispositivo disponha de poucos recursos, ainda assim, sua gerência pode ser estendida.

6. Conclusões Este trabalho apresentou o modelo da meta-gerência, cujo objetivo é permitir o gerenciamento da configuração de subagentes através do protocolo SNMP. O foco do modelo é a proposta de estabelecer uma plataforma completa, representada pelo metaagente, que encapsula todo o processo de ativação de um agente, desde sua obtenção até sua execução. Com o modelo de meta-gerência, é possível utilizar um único protocolo (SNMP) para gerenciar tanto o código de agentes quanto informações monitoradas pelos mesmos. A possibilidade de usar o SNMP para gerenciar quaisquer dispositivos, mesmo que eles implementem outros protocolos de gerenciamento, se deve ao fato de o modelo prever um agente intermediário. Esse agente executa o serviço de procuração entre o protocolo de gerenciamento do dispositivo e o SNMP, desde que a interface de gerenciamento do mesmo seja disponibilizada para o desenvolvimento de um subagente procurador específico.

Outra facilidade que o modelo oferece é permitir que o código que estende a gerência de um dispositivo se acople ao agente já existente dinamicamente, sem interromper o serviço de monitoramento. Também é importante ressaltar que o SNMP, nesse modelo, tanto é utilizado para permitir o gerenciamento dos dispositivos que ele controla, como para administrar o código dos agentes procuradores que se comunicam com os dispositivos. Assim, qualquer gerente SNMP legado pode fazer uso da meta-gerência para controlar dispositivos que não são gerenciáveis via SNMP. Conforme o comparativo feito na seção de trabalhos relacionados, ao contrário de outros modelos, a meta-gerência não consome recursos dos dispositivos gerenciados, ou seja, não exige que esses dispositivos disponibilizem recursos para execução de processos localmente. Na meta-gerência, os agentes procuradores são executados no controlador, que disponibiliza os recursos necessários para estender a gerência dos dispositivos. Dessa forma, mesmo que o dispositivo disponha de poucos recursos, ainda assim, sua gerência pode ser estendida.

Referências Alves, J., Mota, J., (2003) “Casas Inteligentes”, Centro Atlântico, Lda., 2003. Black, U., Network Management Standards – SNMP, CMIP, TMN, MIBs, and Object Libraries. Second Edition. McGraw-Hill Series on Computer Communications. 1995. Daniele, M., Wijnen, B. (2000) “Agent Extensibility (AgentX) Protocol”, RFC2741, January 2000. Goldszmidt, G., Yemini, Y. (1998) “Delegated Agents for Network Management”, IEEE Communications Magazine, Volume 36, no. 3, pp 66-70, March 1998. Gavalas, D., Greenwood, D., Ghanbari, M., O’Mahony, M. (1999) “An Infrastructure for Distributed and Dynamic Network Management based on Mobile Agent Technology”, IEEE International Conference on Communications. ICC '99, pp 13621366, June 1999. NET-SNMP, (2005) “NET-SNMP Package”, http://www.net-snmp.com. Consultado em 23 de dezembro de 2005. Stallings, W., SNMP, SNMPv2 and RMON – Practical Network Management, Second Edition. Addison-Wesley. 1997.