Uma Solução Baseada em Web Services para o Gerenciamento de Coletores NetFlow Distribuídos

Transcrição

1 Uma Solução Baseada em Web Services para o Gerenciamento de Coletores NetFlow Distribuídos Diego M. da Rosa, Evandro D. V. Pereira, Lisandro Z. Granville, Maria Janilce B. Almeida, Liane Margarida R. Tarouco Universidade Federal do Rio Grande do Sul - UFRGS Instituto de Informática Bloco IV Bairro Agronomia Caixa Postal , CEP: Porto Alegre RS {diegoro, edvpereira, granville, janilce, liane}@inf.ufrgs.br Abstract. NetFlow is a solution for network metering based on the capture of flow descriptors issued by network devices, such as routers and switches. In larger networks, such as backbones, it is not rare to be forced to use several collectors in order to retrieve the global flow distribution. This paper presents a Web Services-based solution for the management of NetFlow collectors distributed along different administrative domains. The objective is, not only collect and co-relate the data captured by collectors, but also to control, through configuration operations, the process of data capturing and storage executed within collectors. Resumo. NetFlow é uma solução para medição de rede baseada na captura de descritores de fluxo transmitidos por dispositivos, como roteadores e switches. Em redes de grandes dimensões, como num backbone, não é raro ter de se utilizar vários coletores NetFlow. Este artigo apresenta uma solução baseada em Web Services para o gerenciamento de coletores NetFlow espalhados ao longo de vários domínios administrativos diferentes. O objetivo é, não apenas coletar e correlacionar os dados capturados pelos coletores, mas também controlar, através de operações de configuração, o modo como os coletores de uma rede executam a captura e armazenam os dados recuperados. 1. Introdução No gerenciamento de redes, a medição é uma das tarefas mais importantes porque permite aos administradores compreender o uso e o comportamento da infra-estrutura de comunicação. Existem diversas soluções para medição de redes, sendo que os sistemas que permitem a análise de redes locais internas aos domínios administrativos são sistemas mais maduros e estáveis. Por outro lado, os sistemas para medição de enlaces de longa distância, por exemplo, enlaces que interligam POPs de um grande backbone, são soluções mais recentes e que ainda podem evoluir consideravelmente. Um modelo comum e amplamente aceito para medições utiliza coletores de tráfegos em pontos críticos da rede. Os coletores recebem as informações relativas aos fluxos de equipamentos (tipicamente roteadores) e processam essas informações que são então analisadas pelos administradores. Ferramentas gráficas ajudam muito nesse processo, e é comum se encontrar nas soluções a exibição das informações processadas através de gráficos históricos em páginas Web.

2 Duas dificuldades inter-relacionadas surgem nesse contexto. Inicialmente, é comum que a máquina que hospeda o coletor de dados também acumule a função de processar, analisar e gerar relatórios e gráficos a partir das informações de medição. Um segundo problema, mais grave na nossa opinião, é a inexistência de um sistema que seja capaz de, centralizadamente, controlar e coordenar um conjunto de coletores: atualmente cada coletor acaba sendo manipulado individualmente. Os principais motivos para esta situação são: - Normalmente os administradores estão interessados apenas no tráfego de seu próprio domínio administrativo, sem se importar com o tráfego em outros domínios. Portanto, coletores externos não são acessados; - Ainda que houvesse interesse, por questões de segurança, os administradores preferem inibir o acesso aos coletores a partir de usuários ou aplicações externos aos domínios administrativos que contêm os coletores; - Não existe uma interface de comunicação padronizada ou amplamente aceita no acesso aos coletores (ainda que não existissem restrições de segurança). Na maioria dos casos, a situação atual descrita é mais que suficiente para que os administradores entendam o comportamento de suas redes internas. Entretanto, existem cenários onde um ambiente de medições distribuído ao longo de vários domínios administrativos se faz necessário. Por exemplo, um operador de backbone pode desejar entender o tráfego corrente através do acesso a coletores espalhados nos POPs. Nesse caso, existe a necessidade de uma medição hierárquica onde o operador do backbone deve ter direito de acesso aos coletores localizados nos POPs. Existem ainda situações nas quais coletores precisam colaborar entre si em uma estrutura plana de medições, sem hierarquia. Por exemplo, para a medição do tráfego gerado por um Grid computacional que se espalha ao longo de diversos domínios administrativos, os coletores precisam colaborar entre si para que o tráfego gerado pelo Grid possa ser determinado. Dessa forma, acreditamos que os sistemas para medições ainda precisam incorporar as seguintes características: - Os coletores devem possuir uma interface de comunicação bem definida de forma que se possa gerenciar cada coletor, além de se recuperar as informações coletadas; - A comunicação com os coletores deve ser possível na Internet, onde mensagens de comunicação deverão cruzar domínios administrativos diferentes até chegaram aos coletores alvo; - Um software gerente de coletores deve ter a capacidade de, remotamente, controlar coletores espalhados ao longo de diversos domínios administrativos diferentes. Neste artigo, é apresentada a investigação prática destas questões através da implementação de um sistema para gerência de coletores distribuídos. Os coletores gerenciados são baseados na solução de medição NetFlow [Cisco 1999], e a comunicação entre o sistema de gerência e os coletores é realizada através das tecnologias de Web Services [Francisco et al 2002]. O cenário hipotético de estudo é baseado no backbone da RNP [RNP 2003], por ser uma rede que necessita de medições distribuídas ao longo de seus POPs, mas que não possui um sistema central para gerência dessa infra-estrutura de medições.

3 O restante deste artigo está dividido da seguinte forma. A Seção 2 apresenta a solução para medições NetFlow, bem como os principais aspectos relativos às tecnologias de Web Services. A Seção 3 apresenta a arquitetura geral do sistema para gerência de coletores NetFlow, enquanto a Seção 4 aborda os aspectos práticos de implementação de tal solução. Finalmente, o artigo é finalizado na Seção 5, na qual as conclusões e trabalhos futuros são apresentados. 2. NetFlow e Web Services Nesta seção são apresentadas as tecnologias relacionadas a Web Services e a solução de medição NetFlow. Os Web Services permitem a comunicação entre os coletores e o sistema de gerência dos mesmos, enquanto o NetFlow é utilizado para a coleta das informações dos fluxos de interesse Intercomunicação de Aplicações via Web Services Além do tradicional uso da World Wide Web para troca de dados, ela vem sendo utilizada também para a comunicação entre aplicações. As interfaces de programação disponibilizadas para o acesso de aplicações remotas são chamadas, genericamente, de Web Services. Os Web Services permitem que uma aplicação troque dados ou envie mensagens a outras aplicações utilizando uma infra-estrutura baseada em protocolos Web, tais como HTTP e SMTP. Por esse motivo, Web Services vêm sendo utilizados para a comunicação entre aplicações hospedadas em estações que se encontram em diferentes domínios administrativos, já que outras formas de comunicação (e.g. Java RMI, CORBA ou DCOM) seriam normalmente barradas por firewalls. Uma das implementações mais importantes de Web Services é aquela baseada no protocolo SOAP (Simple Object Access Protocol) [Sahai et al 2002], que por sua vez, é baseado na linguagem de descrição de dados XML. O SOAP define uma forma de comunicação entre aplicações muito semelhante ao RPC (Remote Procedure Call), entretanto com a capacidade de trafegar por domínios administrativos diferentes. O SOAP basicamente encapsula uma chamada de procedimento estruturada em XML em uma requisição HTTP e retorna o resultado da execução. Tanto a chamada do procedimento e os dados passados como parâmetros como o valor de retorno são estruturados também de forma textual através de XML. Dentre as implementações do protocolo SOAP destacam-se a ApacheSOAP [Apache 2003] da Apache Foundation e o NuSOAP [Ayala 2003] da NuSphere Corporation. A primeira trata-se de uma implementação em linguagem Java e a segunda em PHP. Uma outra característica importante dos Web Services é sua facilidade de desenvolvimento (se comparada a outras tecnologias com os mesmos propósitos). Alguns autores argumentam que a facilidade no uso de Web Services é tão grande que pode até mesmo levar a uma revolução na área de gerenciamento de redes, no lugar de uma suposta natural evolução [Schönwälder et al 2003] A Infra-estrutura NetFlow A infra-estrutura NetFlow define uma forma simples e escalável de amostragem de fluxos de dados trafegando por dispositivos de rede como roteadores e switches. Essa infra-estrutura está baseada na noção de fluxo e permite a medição, identificação e análise dos tráfegos em uma rede de computadores. Inicialmente implementada pela Cisco [Cisco 1999], a infra-estrutura NetFlow está atualmente servindo de base para a

4 definição do padrão IPFIX (Internet Protocol Flow Information export) [Sadasivan and Brownlee 2003] no IETF (Internet Engineering Task Force). Diz-se que um equipamento de rede possui suporte a NetFlow quando este está habilitado a identificar um fluxo de dados entre duas máquinas, e exportar as informações referentes a esse fluxo para uma estação coletora. A arquitetura geral do NetFlow é apresentada na figura 1. Datagramas NetFlow Equipamentos (roteadores, switches) Datagramas NetFlow Coletores Aplicações Figura 1. Arquitetura NetFlow Os equipamentos de rede com NetFlow habilitado exportam para as estações coletoras (ou coletores) datagramas contendo informações relativas aos fluxos capturados. Os coletores, por sua vez, são encarregados de receber, armazenar e disponibilizar os dados para aplicações que realizarão a análise dos mesmos. Do ponto de vista de um equipamento NetFlow, um fluxo é definido como uma seqüência unidirecional de pacotes trafegando de um ponto a outro na rede. Os pontos fonte e destino de um fluxo são identificados pelos endereços IP e pelo número de porta do protocolo de nível de transporte. O campo TOS (Type of Service) do cabeçalho IP e o identificador de interface de entrada também são utilizados pelo NetFlow para identificar univocamente os fluxos. Um equipamento com NetFlow habilitado utiliza também uma série de critérios para definir se um pacote pertence a um fluxo já existente ou se tal pacote deve dar início à descrição de um novo fluxo. O equipamento NetFlow agrupa os fluxos encerrados e os exporta através de datagramas UDP chamados de NetFlow Export Datagrams. O cabeçalho desses datagramas apresenta informações como identificador de versão do NetFlow, quantidade de fluxos no pacote e número de seqüência. Logo após o cabeçalho, segue uma seqüência de entradas contendo as informações relativas a cada fluxo. Cada entrada contém informações como endereço IP fonte e destino, porta fonte e destino, número de pacotes do fluxo, número de bytes do fluxo, e protocolo utilizado. Os coletores recebem os datagramas NetFlow através de um processo coletor de fluxo. Tal processo coletor captura os pacotes NetFlow e armazena as informações contidas nos mesmos de modo que estas possam ser pós-processadas. Entre as ferramentas atualmente disponíveis para implantação de coletores destacam-se: o NetFlow FlowCollector da própria Cisco [Cisco 2003b], o cflowd [Sabatino 1998] pertencente ao pacote de aplicativos de mesmo nome, e o flow-capture pertencente ao pacote de aplicativos Flow-Tools [Fullmen and Roming 2000]. O cflowd e o flow-

5 capture se destacam pelo fato de serem distribuídos sob licença de software livre e por adotarem a mesma formatação no armazenamento dos dados coletados. Os dados capturados pelos processos coletores de fluxo são então analisados por aplicações de análise dos fluxos. Entre os tipos de aplicações mais comuns pode-se citar: ferramentas de medição de consumo de banda e cobrança diferenciada, ferramentas para análise e planejamento de redes e ferramentas para monitoração de redes e proteção contra ataques. A aplicação implementada pela Cisco para a visualização e análise dos fluxos é o Network Data Analyzer [Cisco 2003a]. Outro aplicativo desenvolvido para esse fim, o FlowScan [Plonka 2000], permite o armazenamento em RRDs (Round Robin Databases) [Oetiker 2003] de informações específicas extraídas dos arquivos de fluxos bem como a geração de gráficos sob demanda a partir dessas informações. O FlowScan opera sobre o formato de arquivo comum aos aplicativos cflowd e flow-capture. Normalmente, o FlowScan é executado na mesma estação do processo coletor, processando os arquivos com os dados coletados e gerando bases de dados com informações específicas. As informações contidas nesses bancos de dados podem ser definidas através de módulos escritos para operar em conjunto com o FlowScan. Um dos módulos mais utilizados é o CUFlow [Andersen 2003], o qual permite a geração de RRDs contendo informações específicas sobre diferentes protocolos de transporte, serviços, TOS, entre outros. As informações processadas pelo FlowScan em conjunto com o CUFlow podem ser configuradas através de um arquivo de configuração do CUFlow, chamado CUFlow.cf, e acessadas através da ferramenta de criação, edição e leitura de RRDs: o RRDTool [Oetiker 2003] Coletores, Gerenciamento e Domínios Administrativos Distintos Como visto anteriormente, existe uma razoável diversidade de ferramentas para a implementação de soluções de medição baseadas em NetFlow. O que se observa na prática, entretanto, é que as soluções implantadas atualmente preocupam-se com operações de medição internas a um domínio administrativo. Em certas situações, como apresentado na introdução, medições internas aos domínios podem não ser suficientes. Na tentativa de implementação de uma solução de medições capaz de utilizar dados de coletores diversos, três principais dificuldades são encontradas: (a) Cada coletor de interesse pode ter uma configuração totalmente diversa dos outros coletores, o que dificulta a agregação de dados; (b) Mesmo que todos os coletores de interesse venham a ter a mesma configuração, não existe uma ferramenta capaz de eficientemente agregar e apresentar os resultados das medições; (c) Por fim, mesmo que uma ferramenta central fosse eficiente na agregação e apresentação de dados de medições, a comunicação com os coletores pode não ser possível visto que os mesmos estão distribuídos ao longo de diversos domínios administrativos. Estas dificuldades indicam que uma solução para medições ao longo de vários domínios administrativos deve: utilizar um protocolo capaz de percorrer domínios administrativos diferentes (para resolver a questão c), recuperar dados de forma distribuída e gerar dados agregados mais ricos (para revolver a questão b) e controlar a configuração dos coletores remotamente (para resolver a questão a). As seções a seguir apresentam a arquitetura e implementação de um sistema para medições distribuídas baseado nessas premissas.

6 3. Arquitetura para Gerenciamento de Coletores Distribuídos A arquitetura para gerenciamento de coletores ao longo de domínios administrativos diferentes é apresentada na Figura 2 abaixo. Coletor Sistema de captura e armazenamento Web Services Estação de gerenciamento Coletor Internet Aplicação de Gerenciamento Servidor Web Sistema de captura e armazenamento Web Services Figura 2. Arquitetura do sistema de gerência de coletores Os equipamentos de redes e os coletores associados estão dispostos em domínios administrativos diferentes, representados na figura por nuvens. Da mesma forma, uma estação de gerenciamento que controla os coletores pode se encontrar em um domínio administrativo diferente dos domínios onde se encontram os coletores. Por fim, assumese que Internet é o elemento intermediário que interconecta coletores e estação de gerenciamento Coletores Os coletores são formados, internamente, por três elementos principais: sistema de captura e armazenamento, bases de dados para armazenamento das informações coletadas, e Web Services. O sistema de captura e armazenamento é composto por um conjunto de aplicações menores responsável pela captura dos datagramas NetFlow exportados pelos equipamentos de rede. Os dados coletados são armazenados em bases de dados de modo que possam ser acessados posteriormente. Os dados armazenados são disponibilizados pelos coletores através dos Web Services. Assim, os Web Services apresentam um ponto de acesso a aplicações remotas, de forma que estas possam recuperar os dados capturados em cada um dos coletores da arquitetura. A forma como os dados capturados são armazenados nos bancos, e quais os dados importantes que serão efetivamente salvos são informações determinadas a partir de um processo de configuração do sistema de captura e armazenamento. Essa configuração exige, em uma solução convencional, a intervenção local no coletor e a edição de arquivos de configuração. Na arquitetura proposta, entretanto, os Web Services, além de exportarem os dados capturados como mostrado anteriormente, também fornecem interfaces para configuração do sistema de captura e armazenamento. Dessa forma, os Web Services internos aos coletores permitem tanto o controle remoto de tais coletores como a recuperação das informações capturadas pelo sistema de captura e armazenamento.

7 3.2. Estação de gerenciamento A estação de gerenciamento é composta por uma aplicação de gerenciamento e por um servidor Web. A aplicação de gerenciamento implementa um ponto único de controle dos coletores, o que permite proceder com o gerenciamento de diversos coletores em domínios administrativos diferentes de forma integrada. A aplicação de gerenciamento também implementa um ponto único de análise dos dados de medição porque é capaz de recuperar dados capturados por coletores espalhados ao longo de domínios administrativos diferentes. O controle dos coletores é possível porque a aplicação de gerenciamento comunica-se com os Web Services disponibilizados pelos mesmos. Da mesma forma, a recuperação dos dados capturados pelos coletores é possível porque os Web Services possuem interfaces que exportam tais informações. A disponibilização das funcionalidades da aplicação de gerenciamento se dá através do servidor Web interno. Isso permite que vários administradores possam acessar o sistema de gerenciamento de coletores remotamente, através de HTTP, o que é uma vantagem bem estabelecida e comprovada na área de gerência de redes [Martin- Flatin and Anerousis 2001]. 4. Implementação A arquitetura apresentada anteriormente pode ser implementada através da combinação de algumas tecnologias. Nessa seção, é apresenta uma implementação que utiliza as tecnologias do NetFlow nos coletores e Web Services para comunicação com uma estação de gerenciamento baseada na Web. O sistema de gerenciamento implementado possui as seguintes características: - Permite a visualização e a alteração dos diversos parâmetros de configuração de um coletor. Além disso, a alteração de parâmetros pode ser realizada também para um conjunto de coletores ao mesmo tempo. Para auxiliar no gerenciamento de configuração, o sistema possui também uma funcionalidade para comparação de configurações de coletores diferentes; - Permite a recuperação dos dados capturados por cada coletor gerenciado. Além disso, permite a visualização de tais dados através de gráficos comparativos. - Permite o envio de comandos aos coletores de forma a executar aplicativos do pacote Flow-Tools, tais como o flow-filter e o flow-stat. Essa funcionalidade permite à estação de gerenciamento solicitar, por demanda, informações mais específicas sobre os dados capturados. Coletor Flow-Tools CUFlow.cf Web Services exec.php Flow-capture FlowScan/ CUFlow config.php retrieve.php Servidor Web Apache de Arquivos de de fluxos RRD CUGrapher.pl Figura 3. Arquitetura interna dos coletores

8 4.1. Implementação do sistema de coleta e armazenamento O sistema de coleta e armazenamento é implementado através de uma estrutura composta pelo mesmo conjunto de ferramentas encontrado nos coletores NetFlow espalhados ao longo do backbone da RNP. Essa estrutura utiliza o aplicativo flowcapture, do pacote Flow-Tools, para a captura dos pacotes NetFlow e para a geração de arquivos contendo os dados sobre os fluxos coletados. Outros aplicativos do pacote Flow-Tools são utilizados para a pesquisa em tais arquivos de fluxos e para visualização de estatísticas simples em formato texto. Assim, os pacotes NetFlow gerados nos equipamentos de rede são recebidos no coletor pelo flow-capture que gera arquivos contendo dados sobre os fluxos observados. Os arquivos com as informações dos fluxos são processados para gerar bancos de dados RRD com informações mais ricas. O aplicativo FlowScan, em conjunto com o módulo CUFlow, lê os arquivos gerados pelo flow-capture e gera tais bancos RRD. O número de bancos RRD, e os dados que cada um armazena são configurados através do arquivo CUFlow.cf. Esse arquivo determina como o CUFlow deve operar de forma a gerar bancos adequados de acordo com as necessidades de análise de cada rede Implementação dos Web Services Os Web Services disponibilizados pelos coletores são os elementos mais importantes da arquitetura, porque é através deles que a estação de gerenciamento tem acesso às informações de configuração e aos dados capturados por cada coletor. Os Web Services foram implementados em PHP utilizando o pacote nusoap [Ayala 2003]. Três grupos de Web Services permitem o gerenciamento e recuperação de dados de um coletor (indicados na figura 3 pelos itens exec.php, config.php e retrieve.php). O uso de PHP e nusoap na implementação do Web Services se deve principalmente pelo fato de que PHP é amplamente suportado em conjunto com Apache. Além disso, PHP é uma linguagem de scripts para Web de fácil utilização, o que permite o rápido desenvolvimento e fácil manutenção dos Web Services. Os Web Services de execução (exec.php) consistem em um único procedimento, o qual permite a execução de uma aplicação do pacote Flow-Tools. A saída da execução é passada de volta ao cliente para ser posteriormente interpretada. Essa funcionalidade é útil quando tarefas de manutenção do Flow-Tools se fazem necessárias, e uma intervenção direta nas aplicações do pacote acaba sendo inevitável. Os Web Services de configuração (config.php), por sua vez, permitem a configuração do processo de geração de bancos RRD. Tal configuração se dá pela leitura e manipulação do arquivo CUFlow.cf. Como alterações nesse arquivo não são imediatamente adotadas pelo FlowScan e CUFlow, o Web Service também interage com esses elementos de forma a reinicializá-los para que o arquivo de configuração seja lido novamente, e as novas configurações passem a ser utilizadas. Entre outros procedimentos pertencentes a esse grupo, estão GetConfig e SetConfig. O primeiro permite ao cliente ler os dados do arquivo de configuração, enquanto o segundo atualiza tal arquivo com configurações novas. Por fim, os Web Services de coleta (retrieve.php) disponibilizam procedimentos que recebem uma série de parâmetros descrevendo os dados requisitados e retorna um vetor contendo os dados obtidos das bases de dados. A tarefa de ler os RRDs é realizada através das ferramentas do RRDTool.

9 4.3. Aplicação de Gerenciamento A estação de gerenciamento, como visto anteriormente, abriga uma aplicação baseada na Web. A aplicação é desenvolvida em PHP e acessa os Web Services nos coletores também utilizando o pacote nusoap. Sendo disponibilizada através de um servidor Web, vários administradores podem acessá-la simultaneamente a partir de diferentes estações. Na tela inicial o usuário é requisitado a entrar com seu nome e senha previamente cadastrados. Depois de realizada a verificação dos dados, é apresentada uma lista dos coletores cadastrados (figura 4). Tal lista pode também ser acessada através da opção View Collectors do menu da ferramenta. Figura 4. Lista de coletores cadastrados O item Configuration possui dois sub-itens: Compare e Apply, os quais levam a telas onde o usuário pode visualizar, comparar e aplicar novas configurações nos coletores cadastrados (figura 5). O sub-item Compare permite que o usuário preencha uma tela com os parâmetros de configuração desejados ou com os parâmetros atuais de algum dos coletores cadastrados e compare essa configuração com a de algum outro coletor. Como saída, essa operação gera um relatório, indicando se as configurações são diferentes e, caso positivo, quais parâmetros são diferentes. Essa opção é útil em situações em que o gerente deseja verificar se um coletor está corretamente configurado ou se dois ou mais coletores estão com configurações semelhantes. Figura 5. Gerenciamento de configurações

10 Já o sub-item Apply permite que o gerente aplique uma nova configuração a um ou mais coletores. Seu funcionamento é semelhante ao item Compare. Primeiramente, o administrador define a configuração que deseja aplicar nos coletores, tendo a opção de escolher a configuração de algum coletor como base. Após, o administrador escolhe uma lista de coletores sobre os quais deseja aplicar a nova configuração. Por fim, a configuração é carregada sobre os coletores selecionados. O item Flow Statistics possui dois sub-itens: View, que permite a visualização de gráficos e relatórios contendo dados coletados junto a diferentes coletores; e Statistics Correlation, que permite ao usuário correlacionar os dados. Esse último tem maior relevância, pois nele é possível comparar o tráfego de diversos coletores através de correlações. Figura 6. Correlação da utilização de protocolos em três roteadores

11 Para realizar uma consulta de forma que um gráfico seja apresentado, o usuário escolhe o tipo de consulta, quais coletores serão analisados e o intervalo de datas e de horários. Um exemplo de consulta é mostrado na figura 6, onde é escolhida a consulta de percentual de utilização de protocolos que rodam sobre o IP, nos pacotes que passam pelos roteadores com endereços IP , e , no dia 11/11/2003 em um intervalo de 25 minutos (8h05min às 8h30min). Cada gráfico mostra o percentual de utilização de cada protocolo, em relação à soma do tráfego desse mesmo protocolo nos três roteadores escolhidos. Para um melhor entendimento, pode-se analisar o tráfego de pacotes ICMP na figura. Quase 80% do tráfego de pacotes ICMP passa pelo segundo roteador ( ), enquanto pelos outros dois roteadores passa apenas cerca de 11% cada. Dependendo da situação, esses dados poderiam demonstrar uma situação anormal e uma investigação mais detalhada poderia ser realizada. Finalmente, tem-se o item Flow Tools, que permite a execução remota de aplicativos do pacote Flow-Tools, como se o usuário estivesse digitando uma linha de comando diretamente no prompt de um coletor. Por mais automatização que se venha a alcançar com o sistema de gerenciamento de coletores, inevitavelmente irão existir situações nas quais uma execução direta de uma linha de comando no coletor se faz necessária. Entretanto, disponibilizar acesso externo à execução de comandos nos coletores pode introduzir um ponto de insegurança. No caso da ferramenta, a segurança deve ser obtida junto ao script exec.php que implementa o Web Service capaz de executar uma linha de comando e retornar a respectiva resposta. A questão de segurança dos próprios Web Services é assunto de pesquisa intensa atualmente, sendo que não existe uma solução padrão ainda. 5. Conclusões e Trabalhos Futuros Este artigo apresentou uma solução baseada em Web Services para o gerenciamento de coletores NetFlow localizados ao longo de diversos domínios administrativos. No processo de desenvolvimento do sistema, ficou clara a facilidade de comunicação conseguida com os Web Services, já que as mensagens SOAP facilmente atravessam domínios administrativos diferentes ao utilizar HTTP ou HTTPS. Além da facilidade de comunicação, o uso de Web Services também introduziu uma grande facilidade de implementação: outros sistemas anteriormente desenvolvidos para gerenciamento de configuração baseados em SNMP, por exemplo, eram sistemas mais complexos de serem codificados. A facilidade de uso está ligada à qualidade da API utilizada, mas mesmo com a API SNMP mais intuitiva, o programador ainda tinha de entender o protocolo de gerenciamento, enquanto que com o uso de Web Services as APIs fornecem um mecanismo de RPC em alto nível, que acaba sendo mais simples pois não exige do programador o entendimento de um protocolo de gerenciamento. Das funcionalidades implementadas no sistema, a que trouxe maior agilidade foi a de configuração. Além de permitir uma configuração remota dos coletores, a funcionalidade de configuração agiliza essa atividade porque a interface gráfica desenvolvida permite uma edição mais rápida dos parâmetros de configuração dos coletores, se comparado ao processo tradicional que envolve a edição do arquivo texto CUFlow.cf. Além disso, a possibilidade de comparação entre configurações de coletores diferentes, bem como a funcionalidade para se implantar uma mesma configuração em diversos coletores facilita muito a manutenção dos mesmos. A maior contribuição do sistema, entretanto, vem do fato de se poder analisar dados capturados por coletores diferentes de uma forma centralizada. A correlação de

12 informações de medição provenientes de diversos coletores permite uma compreensão mais rápida e mais precisa do comportamento da rede. Visando uma melhor caracterização da solução, seria interessante uma avaliação da carga de rede gerada pela introdução dos Web Services. Mecanismos mais avançados para permitir ao administrador definir correlações extras dos dados também poderiam ser investigados. Por fim, é necessária a realização de uma avaliação de desempenho dos coletores quando da existência de Web Services de gerenciamento internos. Referências Andersen, J. (2003) CUFlow (Homepage), Available at (2003) acis/networks/advanced/cuflow/cuflow.html. Apache Project (2003) Apache SOAP, Ayala D. (2003) NuSOAP, Cisco Systems (1999) NetFlow Services and Applications (White Paper), available at (2003): Cisco Systems (2003a) Cisco Network Data Anylizer (Homepage), available at (2003) Cisco Systems (2003b) NetFlow FlowCollector (Homepage), available at (2003) Francisco, C., Matthew, D., Rania, K., William, N., Nirmal, M., and Sanjiva, W. (2002) Unraveling the Web Services Web: An Introduction to SOAP, WSDL, and UDDI, In: IEEE Internet Computing, Vol. 6, March/April 2002, p Fullmer, M., and Roming, S. (2000) The OSU Flow-tools Package and Cisco NetFlow Logs, In: Proceedings of the USENIX Fourteenth System Administration Conference (LISA XIV), New Orleans, LA, December 2000, p Martin-Flatin, J.P., and Anerousis, N. (2001) Web-Based Management (guest editorial), In: Journal of Network and System Management (JNSM) - Special Issue on Web-Based Management, Vol. 9, No. 1, March Oetiker, T. (2003) RRDTool, Plonka, D. (2000) FlowScan: A Network Traffic Flow Reporting and Visualization Tool, In: Proceedings of the USENIX Fourteenth System Administration Conference (LISA XIV), New Orleans, LA, December 2000, p RNP (2003) Rede Nacional de Ensino e Pesquisa, Sabatino, R. (1998) Traffic Accounting using Netflow and Cflowd, In: Fourth International Symposium on Interworking, Ottawa, Canada, July Sadasivan, G., and Brownlee, N. (2003) Architecture Model for IP Flow Information Export, Internet Engineering Task Force (IETF), October 2003 (work in progress). Sahai, A., Machiraju, V., Ouyang, J., and Wurster, K. (2002) "Message Tracking in SOAP-based Web Services", In: Proceedings of the IEEE/IFIP Network Operations and Management Symposium (NOMS), Firenze, Italy, April 2002, p Schönwälder, J., Pras, A. and Martin-Flatin, J. P. (2003) On the Future of Internet Management Technologies, In: IEEE Communications Magazine, Vol. 41, No. 10, October 2003, p