Gerenciamento Baseado em Políticas para Redes de Dimensões Nacionais no Ambiente QAME

Transcrição

1 Gerenciamento Baseado em Políticas para Redes de Dimensões Nacionais no Ambiente QAME Clarissa Cassales Marquezan 1, Iara Machado 2, Leandro Rodrigues 2, Lisandro Zambenedetti Granville 1, Ricardo Vianna 1, Rodrigo Sanger Alves 1 1 Instituto de Informática Universidade Federal do Rio Grande do Sul (UFRGS) Av. Bento Gonçalves, Porto Alegre, RS {clarissa,granville,rvianna,sanger}@inf.ufrgs.br 2 Rede Nacional de Ensino e Pesquisa (RNP) Estrada Dona Castorina, Rio de Janeiro, RJ {iara, leandro}@rnp.br Abstract. -Based Network Management (PBNM) has been around for years. It promises to control the behavior of systems using high-level policy definitions. However, in some environments, PBNM may fail if the environment characteristics are not considered. In this paper we present the development and deployment of a PBNM system created for the Brazilian National Research Network (RNP). The system, named QAME (QoS-Aware Management Environment), uses technologies that we believe to be more appropriate for a country-wide backbone, such as Web Services. The contribution of our work is to show that PBNM can indeed be a solution for QoS management even in hostile environments such as the Internet. Resumo. O gerenciamento de redes baseado em políticas (PBNM - Based Network Management) permite controlar o comportamento de sistemas através da definição de políticas em alto nível. Entretanto, em alguns ambientes, o PBNM poderá falhar se as características de tal ambiente não forem consideradas adequadamente. Neste artigo é apresentado o desenvolvimento de um sistema PBNM criado para a Rede Nacional de Ensino e Pesquisa (RNP). O sistema, chamado QAME (QoS-Aware Management Environment), usa tecnologias que acredita-se serem mais apropriadas para um backbone de dimensões nacionais, tais como Web Services. A contribuição deste trabalho reside no fato de mostrar que o PBNM pode realmente vir a se tornar uma solução para gerenciamento de QoS mesmo operando em ambientes hostis, como a Internet. 1. Introdução Gerenciamento de redes baseado em políticas (PBNM - -Based Network Management) [Sloman 1994] é um conceito atualmente aceito e largamente reconhecido pela comunidade de gerenciamento de redes. Porém, as ferramentas para PBNM disponíveis freqüentemente falham em aplicar o gerenciamento baseado em políticas em ambientes hostis, como a Internet. Uma das razões para este insucesso vem do fato de organismos de padronização definirem modelos de informação e protocolos

2 para PBNM que não são aplicáveis em tais ambientes hostis. Entretanto, acreditamos que o PBNM pode, de fato, ser aplicado no gerenciamento de redes heterogêneas e de dimensões nacionais. Para tanto, é necessário que o desenvolvimento de ferramentas PBNM considere o ambiente onde se espera que elas sejam executadas. A Rede Nacional de Ensino e Pesquisa (RNP) [RNP 2004] opera um backbone de dimensão nacional e apóia grupos de trabalho para desenvolver serviços inovadores para tal backbone. Nesse contexto, este artigo apresenta o suporte PBNM desenvolvido pelo Grupo de Trabalho em Configurações de Redes da RNP (GT-Config) [GT- CONFIG 2004]. Tal suporte é implementado utilizando padrões abertos como Web Services, LDAP e SNMP. A principal contribuição deste trabalho é mostrar que o uso de PBNM não está restrito a ambientes controlados e de pequeno porte, mas também pode ser aplicado em redes de dimensões nacionais e heterogêneas. 2. Gerenciamento Baseado em Políticas e Web Services Para o desenvolvimento do sistema apresentado nesse trabalho, duas tecnologias desempenharam um papel determinante: PBNM, como já citado, e Web Services (WS). O objetivo do gerenciamento baseado em políticas é expressar o comportamento desejado de um sistema através da definição de políticas [Westerinen et al. 2001]. Embora as políticas possam ser utilizadas para controlar diversos sistemas, as redes de computadores são, provavelmente, o exemplo mais expressivo do uso do PBNM. A implementação do sistema desenvolvido pelo GT-Config baseou-se na arquitetura PBNM definida pelo IETF (Internet Engineering Task Force) [Halpern and Ellesson 2004], pois acredita-se que ela tenha o potencial para ser mais largamente adotada. Essa arquitetura, ilustrada na Figura 1, é composta por quatro componentes principais: ferramenta de políticas, repositório de políticas, policy decision point (PDP) e policy enforcement point (PEP). Ferramenta de políticas Repositório Repositório de de políticas políticas Decision Decision Point Point Decision Decision Point Point Decision Decision Point Point Enforcement Points Figura 1 Arquitetura tradicional PBNM do IETF A ferramenta de políticas é o front-end do administrador, a partir da qual ele define e edita as políticas de gerenciamento que serão armazenadas no repositório de políticas para uso futuro. Para que uma política seja aplicada, a ferramenta sinaliza os PDPs, indicando que eles devem consultar, junto ao repositório de políticas, as informações referentes à política em questão. Cada PDP fará então uma tradução da política para os comandos de configuração que serão aplicados no PEP (ex.: interfaces de rede, disciplinas de fila, etc.). Como repositório de políticas, o IETF sugere o uso de LDAP (Lightweight Directory Access Protocol) [Whal et. al. 1997]. Entre os protocolos utilizados para configurar os PEPs, podemos citar; CLI/TELNET (Command Line Interface), SNMP

3 [Waldbusser et. al. 2004] e COPS (Common Open Service) [Durham et. al. 2000]. A comunicação entre a ferramenta de políticas e os PDPs não é padronizada, e nem mesmo sugerida pelo IETF, ficando a cargo de cada desenvolvedor a decisão sobre qual protocolo utilizar. Considerando uma rede de dimensões nacionais, como a operada pela RNP, tal comunicação foi implementada via Web Services (WS) [Curbera et. al. 2002]. A tecnologia de WS vem ganhando cada vez mais atenção pela comunidade de gerenciamento de redes. Uma das características principais dos WS é que eles são baseados em protocolos da Internet (ex.: HTTP e SMTP). Isso os torna adequados para serem adotados como ferramenta de integração para aplicações Web. Embora a arquitetura completa de WS inclua componentes para suportar diversas operações (ex.: publicação e descoberta de WS), neste trabalho foi feito um uso simples de WS, onde um cliente invoca um servidor solicitando a execução de alguma operação. No sistema desenvolvido, WS são essenciais porque eles provêem a comunicação entre a ferramenta de políticas e os PDPs, mesmo que o ambiente entre eles seja a Internet. Dessa forma, pode se ter PBNM instalando-se PDPs em segmentos remotos de rede normalmente protegidos por firewalls, conforme mostrado na Figura 2, caracterizando exatamente o cenário dos PoPs (Point of Presence) da RNP. Firewall Internet Firewall Decision Decision Point Point PEP Protocolo de Web Services (ex.: SOAP/HTTP) Protocolo de Gerenciamento (ex.: SNMP) Figura 2 Uso de WS para transpor firewalls de rede Pode-se argumentar que usar WS para transpor firewalls de rede não é uma solução elegante, adequada ou segura. Mas comparando-se WS com abordagens tradicionais de gerenciamento (ex.: SNMP) é possível observar que o seu emprego é uma solução prática e viável. Obviamente, o uso de WS pode falhar se firewalls forem configurados para bloquear o tráfego HTTP endereçado ao PDP, mas administradores de rede tendem a permitir o tráfego HTTP mais facilmente do que o tráfego SNMP. 3. Arquitetura do Sistema A arquitetura da ferramenta desenvolvida foi definida através da união do sistema PBNM e de WS. A Figura 3 ilustra os módulos que compõem a arquitetura. De forma geral, o sistema pode ser dividido em dois componentes principais: a ferramenta de políticas (que suporta edição de políticas, manipulação de PDPs e PEPs e aplicação de políticas), e o PDP. Por sua vez, o PDP é composto por uma parte genérica, responsável por receber e avaliar as condições das políticas, e uma parte específica, responsável pela tradução de políticas de alto nível em ações de configuração para um determinado PEP alvo A Ferramenta de Políticas A ferramenta de políticas é utilizada pelo administrador para solicitar as ações descritas a seguir, que são executadas por módulos internos à ferramenta.

4 Edição de políticas. Possibilita a criação, a modificação e a remoção de políticas. Esse módulo realiza as operações acessando o repositório de políticas LDAP externo. Cadastro de PEPs. Os dispositivos alvos, assim como seus PEPs, precisam ser registrados no sistema para serem gerenciados. Atualmente, são suportados roteadores Cisco com IOS superior a Cadastro de PDPs. No sistema implementado, PDPs são PCs rodando WS. Esses dispositivos também necessitam ser registrados junto à ferramenta de políticas, a fim de serem usados no processo de aplicação de políticas. Associação entre PDP e PEP. Cada PEP deve ser controlado por um único PDP, enquanto um mesmo PDP é capaz de controlar diversos PEPs. Cada associação PDP/PEP precisa ser igualmente registrada na ferramenta de políticas. Isso permite à ferramenta selecionar o PDP apropriado para aplicar uma política em um PEP. Aplicação de políticas. Para aplicar uma política, o administrador seleciona a política desejada e o PEP alvo. Então, a ferramenta entrega a política para o PDP apropriado. A ação de aplicar uma política também cria uma associação entre a mesma e o PEP alvo. Edição e definição de políticas Associação PDP x PEP Associação PEP x Política Cadastro de PEPs Cadastro de PDPs Ferramenta de políticas Associações LDAP Aplicação de políticas via Web Services Controle de transferência de políticas Controle interno do PDP Repositório PDP Genérico Adaptação e Aplicação de Políticas PDP Específico Figura 3 Arquitetura do sistema 3.2. O PDP ( Decision Point) Em um PDP, o processo para aplicar uma política começa na camada de Controle de transferência de políticas. Um WS residente nessa camada recebe um identificador de política e informações do PEP no qual a política será aplicada. Baseado no identificador da política, o WS pesquisa o diretório LDAP e copia a política para seu repositório local, associando-a com o PEP a ser configurado. Além disso, esse WS é capaz de fornecer informações relacionadas: às políticas aplicadas em cada PEP; a cada PEP disponível para ser configurado; e aos logs das operações realizadas pelo PDP. Ele também é capaz de remover uma política, mesmo que ela não esteja expirada. A Figura 4 ilustra como os elementos e camadas estão organizados na arquitetura do PDP. A partir do momento que uma política é armazenada no repositório local, o Gerenciador do PDP realiza, periodicamente, avaliações das políticas do seu repositório. Os componentes referentes a questões temporais e ações de QoS das políticas são avaliados pelos módulos Avaliação de Agendamentos e Avaliação de QoS,

5 respectivamente. Se uma política torna-se válida, ou seja, os requisitos temporais e de QoS tornam-se verdadeiros e expressos de uma maneira correta, o Gerenciador do PDP registra isso no repositório e sinaliza a camada de Adaptação de Políticas. Informações sobre a política e o PEP Transfer Manager (Web service) Avaliação de Agendamentos Avaliação de QoS Gerenciador do PDP Repositório PDP Genérico Adaptação de Políticas Aplicação de Políticas PDP Específico Ações de Configuração PEP Figura 4 Arquitetura do PDP A camada de Adaptação de Políticas obtém as informações da política armazenada no repositório e as traduz para ações de configuração que são entendidas pelos PEPs. A seguir, a camada Aplicação de Políticas é acionada e a política é efetivamente carregada para o dispositivo. A transferência ocorre de diferentes maneiras, dependendo das capacidades do dispositivo. Por exemplo, pode-se usar SNMP e TFTP, para sinalizar e transferir um arquivo de configuração gerado pela camada de Adaptação de Políticas, ou então utilizar comandos remotos para realizar as ações de configuração. O Gerenciador do PDP e as camadas Adaptação de Políticas e Aplicação de Políticas foram implementados como scripts PHP. 4. A Interface com o Usuário no QAME A ferramenta para políticas foi desenvolvida como um módulo do ambiente QAME. Esse ambiente é constituído por mapas de redes que apresentam os dispositivos que formam o segmento de rede em questão. Nessa seção serão apresentadas as ações que os usuários executam para interagir com a ferramenta de políticas desenvolvida. Inicialmente é preciso configurar o ambiente para suportar os elementos do sistema PBNM, ou seja, é preciso definir os dispositivos que vão atuar como PDPs e PEPs, e cadastrar as políticas que poderão ser aplicadas nos dispositivos. Somente após essas etapas de configuração e definição é que uma política pode ser aplicada nos dispositivos do ambiente QAME Cadastro de PEPs e PDPs e suas Associações No ambiente QAME, cada dispositivo possui capacidades associadas a ele. Uma capacidade representa uma funcionalidade presente no dispositivo. Existem duas capacidades relacionadas com PBNM no QAME: PDP e PEP. Para transformar um dispositivo do mapa de rede em um PDP é preciso cadastrá-lo com tal capacidade. Além disso, um dispositivo PDP deve ser configurado para informar qual tipo de PDP específico ele implementa (ex.: PDP para dispositivos

6 Cisco, IBM ou AltQ). Para registrar um dispositivo como PEP é preciso cadastrá-lo com a capacidade PEP e em seguida definir o dispositivo PDP que o controlará Criação e Definição de Políticas O uso de uma linguagem específica para criação de políticas obriga os usuários a aprenderem uma nova linguagem. Para evitar tal problema, foram implementadas interfaces gráficas para a definição de políticas e seus componentes: ações, fluxos e agendamentos. Os elementos que podem ser usados nesses componentes pertencem aos modelos PCIM [Moore et. al. 2001] e PCIMe [Moore 2003] definidos pelo IETF. Na definição de uma ação (action) é possível especificar uma reserva de banda, o valor do campo DS do cabeçalho IP (DSCP) para implementar serviços diferenciados, associar uma prioridade e definir diferentes níveis de descarte de pacotes. Em uma definição de fluxo (flow), é possível construir filtros usando: endereço IP origem e destino, porta origem e destino, protocolo de transporte (TCP, UDP, ICMP) e DSCP. Além disso, máscaras de rede e faixas de IP e de portas também são aceitas. Para a definição de um agendamento (schedule), é possível especificar: mês, dia do mês, dia da semana, período do dia e tempo de validade da política. O QAME possui uma interface para definição de políticas que agrupa ações, fluxos e agendamentos (Figura 5), possibilitando, assim, o reuso desses componentes. Para facilitar tal processo, o QAME adicionalmente possui um assistente (wizard). Figura 5 Criação de uma política Após a criação de uma política, o usuário pode visualizar como a tradução da mesma será feita em um PDP específico. Essa característica ajuda o operador a verificar se a configuração final, a ser aplicada em um dispositivo alvo, está adequada Aplicação de Políticas O QAME disponibiliza uma interface simplificada para a aplicação de políticas. Essa interface é responsável pela aplicação e remoção de políticas e por informar quais políticas estão aplicadas em cada interface de rede de um dispositivo específico. Para aplicar uma política em um dispositivo, o usuário deve escolher a política a ser aplicada, a interface de rede (PEP) do dispositivo alvo e a direção na qual a política

7 deve atuar (input ou output). Então, a política é transferida para o PDP que controla o PEP. Para remover políticas, o usuário escolhe as políticas e executa a opção Remove. A Figura 6 ilustra a interface de aplicação de políticas. Figura 6 Interface de aplicação de políticas do QAME As operações de aplicação e remoção de políticas são armazenadas em um sistema de logs. O QAME permite a visualização dos logs individuais de cada PEP ou de todos os PEPs controlados por um PDP. O sistema de logs, além de registrar as operações realizadas no QAME pelos usuários através da interface, também registra as ações reais de configuração efetuadas pelo PDP quando um agendamento torna-se ativo ou inativo Testes do Sistema no Contexto da RNP A rede da RNP possui um ponto de presença (PoP) em cada estado brasileiro. A operação dos equipamentos que compõem a infra-estrutura de acesso ao backbone da RNP nos PoPs é feita a partir de uma política de operação conjunta entre a equipe do Centro de Engenharia e Operações da RNP e a equipe técnica local dos PoPs. Os testes do sistema QAME foram realizados em dois PoPs da RNP. Em cada um deles, foi utilizado um roteador Cisco dedicado aos testes, localizado no domínio administrativo do PoP. Também foi instalado um PDP em cada um desses PoPs, para a configuração do roteador a partir da aplicação das políticas de QoS definidas pelos usuários no sistema. O repositório LDAP permitiu o compartilhamento das políticas entre os PDPs. O objetivo desse programa de testes foi colher dados junto aos administradores de redes dos PoPs em relação ao uso do sistema. Para tanto, foi criado um roteiro de execução dos testes, disponível via Web, composto por explicações sobre o QAME, instruções sobre as experiências a serem realizadas e formulários para avaliação. 5. Conclusões Neste artigo foi apresentado o suporte a PBNM implementado no sistema QAME, como parte dos esforços para implantar PBNM no backbone da RNP. O suporte a políticas no QAME foi implementado utilizando PHP, enquanto a interface com o usuário foi aperfeiçoada através de mapas de rede implementados com tecnologia Flash.

8 O feedback recebido dos operadores dos PoPs da RNP permitiu a identificação de algumas considerações que validam o sistema desenvolvido. A possibilidade de agendamento da aplicação de políticas nos dispositivos e a visualização das políticas aplicadas foram qualidades destacadas pelos operadores que realizaram os testes. Além disso, pode-se dizer preliminarmente que o LDAP demonstrou real potencial para permitir o compartilhamento de políticas entre diferentes usuários do sistema. Alguns trabalhos futuros foram identificados. O primeiro ponto está relacionado com a melhora da interface gráfica. Baseado no feedback dos usuários do sistema notou-se que existem alguns aspectos que poderiam ser melhor expressos na interface. Por exemplo, os componentes de um fluxo, no momento da sua definição, poderiam ser apresentados de uma maneira gráfica. Um segundo item a ser trabalhado é o aumento do número de tipos de PDPs suportados pelo sistema. Atualmente, existe suporte para configurar dispositivos Cisco. Pretende-se suportar roteadores Extreme e IBM. Além disso, pretende-se fornecer soluções relacionadas ao cenário distribuído, no qual o sistema desenvolvido está localizado. É interessante desenvolver um sistema capaz de suportar a definição de uma política por um administrador de mais alto nível e distribuí-la automaticamente ao longo dos domínios administrativos de mais baixo nível. Essa abordagem é chamada PBNM hierárquico. Referências Curbera, F. et. al. (2002) Unraveling the Web Services Web: An Introduction to SOAP, WSDL, and UDDI. IEEE Internet Computing, Vol. 6, n. 2, pp 86-93, Abril. Durham et. al., (2000) The COPS (Common Open Service) Protocol, RFC 2748, IETF, Janeiro. GT-CONFIG (2004) Grupo de Trabalho em Configuração de Redes - RNP, Dezembro. Halpern, J. and Ellesson E. (2004) Framework (policy) IETF Working Group. Disponível em: < Moore, B. (2003) Core Information Model (PCIM) Extensions, RFC 3460, IETF, Janeiro. Moore, B., Ellesson, E., Strassner, J. and Westerinen, A. (2001) Core Information Model Version 1 Specification, RFC 3060, IETF, Fevereiro. RNP (2004) Rede Nacional de Ensino e Pesquisa, Dezembro. Sloman, M. (1994) Driven Management For Distributed Systems, Plenum Press Journal of Network and Systems Management, Vol. 2, pp , Dezembro. Waldbusser, S., Saperia, J. and Hongal, T. (2004) Based Management MIB darf-ietfsnmpconf-pm-15 (Work-in-progress), Draft, IETF. Westerinen A. et al. (2001) Terminology for -Based Management, RFC 3198, IETF, Novembro. Whal, M., Howes, T. and Kille, S. (1997) Lightweight Directory Access Protocol (v3), RFC 2251, IETF, Dezembro.