GT-ATER: Aceleração do Transporte de Dados com o Emprego de Redes de Circuitos Dinâmicos

Transcrição

1 GT-ATER: Aceleração do Transporte de Dados com o Emprego de Redes de Circuitos Dinâmicos RT2 - Proposta do protótipo Sand Luz Corrêa Kleber Vieira Cardoso 15/03/2013

2 1. Introdução Este relatório apresenta a arquitetura projetada para o serviço ATER. Esta arquitetura é resultado do trabalho desenvolvido entre novembro de 2012 a fevereiro de Neste documento são especificadas a arquitetura projetada para o protótipo do serviço e as principais mensagens que compõem o protocolo de comunicação dos componentes desta arquitetura. Também são definidos os requisitos de software e hardware necessários para a implantação do serviço, bem como o planejamento dos testes necessários para validar o protótipo a ser desenvolvido. Este documento conclui com um cronograma de implantação e testes. 2. Visão Geral O GT-ATER tem como propósito a implementação de um serviço de transporte de grandes volumes de dados através de circuitos dinâmicos, os quais são criados automaticamente a partir de regras para identificação do perfil do tráfego. Nesse sentido, é objetivo do serviço enviar através de circuito dinâmico, criado sob demanda, o tráfego que combina com as regras definidas. O tráfego restante é enviado pela rede IP convencional. As regras para identificação do perfil do tráfego podem ser definidas pelos clientes do sistema, inicialmente usuários de instituições que tenham necessidade de realizar transporte confiável de grandes fluxos de dados, como também por administradores pertencentes à equipe de operação da RNP. A Figura 1 descreve as principais atividades dos dois tipos de usuários (cliente e administrador) do GT-ATER. Figura1: Usuários do serviço ATER Um dos propósitos deste GT é a implementação de um protótipo do serviço proposto. A Tabela 1 resume as funcionalidades que serão implementadas neste protótipo. 2

3 Funcionalidades Gerência de regras Filtragem e Encaminhamento Transparente de Pacotes Coleta de Estatística Integração com o Serviço Experimental (SE) Cipó Autenticação e Autorização Descrição O serviço proposto permitirá a criação e manutenção de regras de identificação de perfil de tráfego de forma simples e amigável O serviço proposto se encarregará da aplicação das regras definidas pelo usuário e se responsabilizará pelo tratamento transparente do tráfego nas extremidades de um circuito dinâmico. O serviço proposto permitirá a coleta de estatísticas para auxiliar o administrador em tomadas de decisão envolvendo a criação e manutenção de regras. O serviço proposto deverá comunicar com o SE-CIPÓ para a criação de circuitos dinâmicos. O serviço proposto será acessado e manipulado apenas por entidades autenticadas e que possuem privilégio apropriado. Tabela 1: Funcionalidades principais do serviço ATER Para atender os requisitos de funcionalidades listados na Tabela 1, o protótipo do serviço considera dois tipos de equipamentos. O primeiro, denominado RACE (Rule Applier and Circuit Endpoint), é um equipamento intermediário responsável por interceptar o tráfego do usuário, analisar seu perfil e, caso necessário, desviá-lo para que seja transferido pelo circuito dinâmico. Portanto, neste equipamento, ocorre a aplicação das regras para idenficação do perfil do tráfego e também a configuração e o estabelecimento da conectividade entre as extremidades dos circuitos dinâmicos. Cada extremidade do circuito deve estar conectada a um RACE. O segundo tipo de equipamento, denominado CORE (Circuit Operation and Rule Establishment), funciona como uma máquina servidora, hospedando o núcleo do serviço, ou seja, autenticação e autorização, gerenciamento de regras, armazenamento do resumo das estatísticas de tráfego, comunicação com o serviço de circuitos dinâmicos da RNP e o controle remoto dos RACEs. A Figura 2 apresenta a visão geral da disposição destes equipamentos no protótipo. A descrição detalhada dessa arquitetura é apresentada na Seção 3, enquanto que a Seção 4 detalha os requisitos de hardware desses equipamentos. 3

4 Figura 2: Visão geral do serviço ATER 3. Arquitetura Detalhada A Figura 3 ilustra a arquitetura considerada para o protótipo. principais elementos dessa arquitetura. A seguir, são descritos os Figura 3: Arquitetura detalhada do serviço ATER CORE_Web Este módulo de software é instanciado no CORE e consiste em um sistema Web através do qual clientes podem criar regras para identificação do perfil de tráfego, visualizar suas regras criadas e consultar estatísticas coletadas sobre estas regras. Este módulo é também acessado pelos administradores, que utilizam o sistema para gerenciar 4

5 usuários, manter regras, monitorar estatísticas de tráfego, controlar remotamente os RACES e configurar/manter o próprio serviço. Este módulo está sendo desenvolvido usando a linguagem PHP. Banco de Dados (DB) Esta é a base de dados do sistema, hospedada no CORE, onde estão armazenados os dados dos usuários e seus privilégios, os dados das regras definidas pelos usuários, os dados dos circuitos criados para atender os diferentes perfis de tráfego, as estatísticas coletadas pelo serviço, os dados relacionados aos RACEs (localização, conexões, estado, etc), além de outros dados de configuração do próprio serviço. Esta base de dados será mantida no PostgreSQL. CORE_Main Este módulo é o núcleo do serviço de gerenciamento de regras instanciado no CORE, sendo formado por dois componentes principais. O primeiro, denominado Circuit_Manager, é responsável por coordenar os RACES em duas atividades: 1) aplicação de uma regra definida pelo usuário e 2) estabelecimento da conectividade entre as extremidades dos circuitos dinâmicos. O segundo componente, denominado RACE_Checker, é um daemon que verifica, periodicamente, o estado dos RACES e atualiza a base de dados com a informação mais recente. CORE_OSCARS_Driver Camada de software instanciada no CORE, responsável pela integração com o SE-CIPÓ. Essa camada é implementada na linguagem Java e funciona como um driver ou uma ponte de comunicação entre o CORE_Main, desenvolvido em PHP, e o serviço de reserva de circuito dinâmico do OSCARS, implementado em Java. RACE_Daemon A parte inicial da comunicação através de circuitos dinâmicos consiste em interceptar o tráfego que não deve seguir através da rede de pacotes convencional e reinjetá-lo no caminho definido pelo circuito dinâmico. O RACE_Daemon é um módulo de software instanciado no RACE, responsável pela lógica de filtragem e encaminhamento transparente desses pacotes. Para interceptação do tráfego, será utilizada uma solução nativa do núcleo do sistema operacional Linux, conhecida como Netfilter, em conjunto com Linux bridge. Para a reinjeção dos pacotes dentro do circuito dinâmico e sua correspondente remoção na outra extremidade do circuito, será usada a API de raw sockets, em linguagem C. RACE_Client e CORE_Client Camada de software que implementa a comunicação entre o CORE e os RACEs. Como exemplo dessa comunicação, pode-se citar a invocação do RACE_Client pelo CORE_Main para comunicar com o RACE_Daemon e aplicar uma regra no RACE. Analogamente, quando um tráfego casa com uma regra, o RACE_Daemon invoca o CORE_Client e solicita ao CORE_Main a criação do circuito dinâmico. A base da comunicação entre CORE e RACES segue um modelo de execução remota sobre um canal seguro. Assim, a comunicação no sentido RACE para CORE é implementada usando libssh2, enquanto a comunicação no sentido CORE para RACE é implementada usando um wrapper dessa biblioteca para clientes PHP. A Seção 4 apresenta as principais mensagens que compõem o protocolo de comunicação dos componentes do serviço ATER. Além dos módulos de software descritos acima, o serviço ATER é composto também por um módulo de coleta de dados estatísticos. A coleta das estatísticas deve ser realizada onde o tráfego flui, ou seja, nos RACEs e, então, encaminhada para o ponto central de operação do serviço, ou seja, para o CORE. A partir do CORE, as estatísticas poderão então ser consultadas e analisadas. Para implementar a coleta distribuída e a persistência centralizada das estatísticas, será usada a ferramenta OML. Como mencionado no relatório 5

6 RT1, a OML é composta por potencialmente 3 componentes: cliente (biblioteca que oferece uma interface para coleta e medição), servidor (recebe as coletas enviadas pelos clientes OML e as armazena em uma base de dados) e proxy (funciona como um armazenamento temporário e limitado de medidas). A Figura 4 ilustra esses 3 componentes no contexto do serviço ATER. Figura 4: Coleta de dados estatísticos no serviço ATER 4. Protocolo de Comunicação No serviço ATER, regras para identificação do perfil do tráfego são criadas e, possivelmente, removidas por clientes e administradores. Durante seu ciclo de vida, uma regra pode passar por diferentes estados. Quando uma regra é criada e aplicada nos RACEs de origem e destino, ela inicia no estado INACTIVE. A regra permanece neste estado até que ocorra o casamento de um tráfego com o perfil definido pela regra e o circuito dinâmico seja estabelecido entre os RACEs. Neste momento, a regra muda para o estado ACTIVE. No estado MONITORING, nenhum circuito é estabelecido entre os RACEs de origem e destino. Neste caso, quando ocorre um casamento entre o tráfego e o perfil definido pela regra, apenas as estatísticas associadas à regra são atualizadas. Finalmente, uma regra entra no estado TEMPORARY_MONITORING quando os RACEs de origem ou destino não estão disponíveis. A Figura 5 ilustra os estados pelos quais passa uma regra no serviço ATER, bem como os eventos que causam as mudanças de estado. Em geral, as mudanças são ocasionadas por trocas de mensagens entre os componentes do serviço. A seguir, são descritas algumas dessas mensagens. 6

7 Figura 5: Estados de um regra 4.1 Mensagem setrule Esta mensagem é enviada pelo CORE para os RACEs (de origem e destino do circuito a ser criado) sempre que uma regra de identificação de perfil de tráfego é criada pelo cliente ou administrador. A Figura 5 ilustra a sequência de trocas de mensagem envolvendo uma operação setrule. Figura 5: Mensagem setrule Na Figura 5, TRAD se refere a regras no estado ACTIVE e MONITORING. Regras do tipo INACTIVE e TEMPORARY_MONITORING podem ser aplicadas de maneira independente a RACEs de origem ou destino. Se, por algum tipo de falha, não for possível ativar a regra no RACE de origem, o RACE destino deve configurar sua regra como TEMPORARY_MONITORING. No entanto, uma regra pode permanecer no estado TEMPORARY_MONITORING no máximo durante uma fatia de tempo de um circuito. Após esse prazo, o RACE deve retorná-la ao estado INACTIVE. 7

8 4.2 Mensagem setrulematch Esta mensagem é enviada por um RACE para o CORE sempre que ocorrer um casamento do tráfego com um perfil definido por uma regra e ainda não existir um circuito dinâmico para tratar o tráfego. A Figura 6 ilustra a sequência de trocas de mensagem envolvendo uma operação setrulematch. Figura 6: Mensagem setrulematch Nos RACEs (origem e destino), a regra fica temporariamente no estado INACTIVE antes do primeiro pacote e passa para MONITORING, logo após o envio de setrulematch. A regra permanece em MONITORING até o circuito ser efetivamente ativado. Esse comportamento é esperado tanto para mensagens setrulematch de criação (NEW) quanto de renovação (MODIFY) de circuitos dinâmicos. Em geral, espera-se que a mensagem setrulematch seja enviada pelo RACE de origem. No entanto, é possível que ela venha também do RACE destino. Essa diferença não tem impacto no protocolo conforme ilustrado. Caso ocorra algum erro na criação do circuito dinâmico proveniente de falhas no OSCARS ou em outro componente do SE-CIPÓ, o usuário é notificado. No entanto, se o OSCARS retornar uma mensagem de pendência (pending), o CORE enviará mensagens do tipo getcircuit para o CORE_OSCARS_Driver, inquerindo sobre o estado do circuito. Após um número determinado de tentativas, se o circuito não foi criado, o CORE notifica os RACEs e cancela a operação. Caso ocorra alguma falha no RACE origem que impossibilite a criação do circuito, o RACE destino é notificado. 4.3 Mensagem getstatus Esta mensagem é enviada pelo CORE para os RACEs periodicamente, como o intuito de inquerir a disponibilidade dos RACEs. A Figura 7 ilustra a sequência de trocas de mensagem envolvendo uma operação getstatus. 8

9 Figura 7: Mensagem getstatus A cada cinco mensagens getstatus com sucesso, o banco de dados é atualizado com a informação de que o RACE está operante (disponível). Quando o CORE identifica que um RACE inoperante se torna disponível, após atualizar o banco de dados, ele deve verificar com quem esse RACE tem regra no estado TEMPORARY_MONITORING. Cada um dos RACEs que fazem par com o RACE operante deve ser contactado para mudar a regra para o estado ACTIVE. O intuito é tornar os RACEs operacionais mais rapidamente. 4.4 Mensagem notifystatus Esta mensagem é enviada pelo CORE para os RACEs com o intuito de divulgar o estado do CORE. Esta mensagem é enviada sempre o CORE passa por uma mudança de estado, como por exemplo, em função de uma manutenção. A Figura 8 ilustra a sequência de trocas de mensagem envolvendo uma operação notifystatus. 9

10 Figura 8: Mensagem notifystatus 5. Requisitos de hardware e Software A maior parte dos testes do protótipo do serviço ATER foi planejada para ser realizada em laboratório, conforme descrito no Relatório RP1. Apenas o estudo de caso foi planejado para ser executado sobre a rede da RNP. Na Seção 6, referente ao plano de testes, será apresentada uma versão modificada no estudo de caso que se baseia em uma abordagem mais controlada dos testes e, portanto, mais factível na rede da RNP. Nesta seção, vamos descrever os requisitos de hardware e software para testes tanto no laboratório quanto na RNP. O hardware necessário para os testes no laboratório compreende máquinas do GT e dois equipamentos adicionais fornecidos por nosso grupo de pesquisa. Os testes em laboratório serão de 2 tipos: virtualizado e emulado. No cenário virtualizado, todos os componentes, inclusive os RACEs serão máquinas virtuais (VMs). No cenário emulado, é usado o OSCARS com uma topologia recente da rede CIPO usando PSS em modo simulado (stub). Adicionalmente, uma parte da topologia será emulada com auxílio do Netem. A Tabela 2 apresenta os requisitos dos equipamentos a serem utilizados nos testes em laboratório e as funções que esses equipamentos exercerão. Requisitos Servidor de rack: 2 sockets para processadores Intel Xeon E5-24 e capacidade para 4 discos rígidos Hot Plug de 3.5"; Intel Xeon E de 4 núcleos, 2.20 GHz (sem Turbo Boost), 10 MB de cache, QPI Link de 6.4 GT/s; 1066 MHz de frequência máxima de memória, TDP de 80 Watts; Cenário virtualizado: Funções executar as VMs dos RACEs (com todas as suas funções); executar as VMs do CORE (com todas as suas funções); executar a VM do OSCARS. Cenário emulado: 10

11 Sistema com 2 processadores instalados; 32GB (2x 16GB) de memória DDR MHz, Dual Rank x4; Fontes redundantes hot plug 550W; Configuração dos discos em RAID 10; 4 discos rígidos SATA de 1 TB, 7.2k RPM, Hot Plug de 3.5"; Pelos menos 4 (quatro) interfaces Gigabit Ethernet 1000Base-T RJ-45, sendo pelo menos duas interfaces integradas e com suporte a Wake on Lan e o 802.1Q VLAN tagging. Switch com 24 portas RJ-45 10/100/1000 e 4 portas SFP combo: 24 portas 10/100/1000BASE-T com auto-speed e auto-polarity; 4 portas 1000BASE-X SFP (compartilhadas com 4 portas 10/100/1000BASE-T); 1 porta serial para gerência local; Mínimo de 88 Gbps de capacidade agregada de switching; Mínimo de 65 Mpps em capacidade de encaminhamento; Suporte a jumbo frames de até 9216 bytes; Suporte a 4096 VLANs; port-based VLAN; MAC-based VLAN, Q-in-Q; Possibilidade de limitação de banda; Implementar espelhamento de portas local em modo many-to-one e também one- to-many. executar as VMs do CORE, ou seja, realizar todas as funções do CORE: gerência de usuários, gerência de regras, gerência de circuitos, gerência de RACEs, armazenamento centralizado das estatísticas; executar a VM do OSCARS No cenário emulado, a principal função é oferecer conectividade entre todos os componentes: CORE, RACEs e clientes. 2 computadores desktop: 3rd Gen Intel Core i Processor (8MB, 3.4GHz); 8GB (2x 4GB), 1600MHz DDR3; 2x HDs 500GB, 6 Gb/s, SATA 3, 16MB de cache; 3 interfaces de rede Gigabit Ethernet do tipo PCIe x1 e com suporte aos padrões IEEE 802.3z, IEEE 802.3x Flow Control, IEEE 802.1p e IEEE 802.1Q VLANs. Basicamente, todas as funções de um RACE, a saber: encaminhamento transparente; interceptação e injeção de pacotes (para permitir a comunicação através dos circuitos dinâmicos); coleta de estatísticas e envio para o CORE. 1 computador desktop: 3rd Gen Intel Core i Processor (8MB, 3.4GHz); 8GB (2x 4GB), 1600MHz DDR3; 2x HDs 500GB, 6 Gb/s, SATA 3, 16MB de cache; Emulação de atrasos e perdas em enlaces de longa distância. 11

12 3 interfaces de rede Gigabit Ethernet do tipo PCIe x1 e com suporte aos padrões IEEE 802.3z, IEEE 802.3x Flow Control, IEEE 802.1p e IEEE 802.1Q VLANs. 2 computadores desktop: 3rd Gen Intel Core i Processor (Quad Core, 6MB, 3.20GHz); 4GB (2x 2GB), 1600MHz DDR3; HD 500GB, 6 Gb/s, SATA 3, 16MB de cache; 2 interfaces de rede Gigabit Ethernet do tipo PCIe x1 e com suporte aos padrões IEEE 802.3z, IEEE 802.3x Flow Control, IEEE 802.1p e IEEE 802.1Q VLANs Representação dos clientes nas bordas dos circuitos dinâmicos. Os equipamentos serão utilizados para gerar carga e auxiliar na mensuração do desempenho do serviço. Tabela 2: Requisitos de hardware - testes em laboratório O hardware necessário para os testes na RNP compreende basicamente máquinas do GT e um equipamento adicional fornecido por nosso grupo de pesquisa. Em relação à rede de produção, a única exigência é que os equipamentos precisam estar conectados à rede CIPÓ diretamente, pois necessitam ter acesso ao serviço de circuitos dinâmicos. A Tabela 3 apresenta os requisitos dos equipamentos que serão utilizados nos testes na RNP, as funções que eles exercerão e onde eles estarão localizados. Requisitos Funções Localização Servidor de rack: Basicamente, todas as funções do CORE, a saber: Instituto de Informática 2 sockets para gerência de usuários; processadores Intel gerência de regras; Xeon E5-24 e gerência de circuitos; capacidade para 4 gerência de RACEs; discos rígidos Hot Plug armazenamento centralizado de 3.5"; das estatísticas. Intel Xeon E de 4 núcleos, 2.20 GHz (sem Turbo Boost), 10 MB de cache, QPI Link de 6.4 GT/s; 1066 MHz de frequência máxima de memória, TDP de 80 Watts; Sistema com 2 processadores instalados; 32GB (2x 16GB) de memória DDR MHz, Dual Rank x4; Fontes redundantes hot plug 550W; Configuração dos 12

13 discos em RAID 10; 4 discos rígidos SATA de 1 TB, 7.2k RPM, Hot Plug de 3.5"; Pelos menos 4 (quatro) interfaces Gigabit Ethernet 1000Base-T RJ-45, sendo pelo menos duas interfaces integradas e com suporte a Wake on Lan e o 802.1Q VLAN tagging. Switch com as características descritas na Tabela 1 e interfaces GBIC com as seguintes características: Compatível com Gigabit Ethernet 1.25 Gbps; Conector LC para fibra monomodo; Plug & Play e Hot- Swap; Full-duplex; Deve suportar fibra monomodo com comprimento de onda de 1310nm; Compatibilidade com fibra óptica monomodo de 9µm de diâmetro; Compatível com o padrão SFP (Multi- Source Agreement); Compatível com o padrão IEEE802.3z 1000BASE-X; Alcance em fibra óptica monomodo de 10km. 1 computador desktop: 3rd Gen Intel Core i Processor (8MB, 3.4GHz); 8GB (2x 4GB), 1600MHz DDR3; 2x HDs 500GB, 6 Gb/s, SATA 3, 16MB de cache; 3 interfaces de rede Gigabit Ethernet do tipo PCIe x1 e com suporte aos padrões IEEE 802.3z, IEEE 802.3x Flow Control, IEEE 802.1p e IEEE 802.1Q VLANs. Conectividade entre o laboratório de pesquisa e o PoP-GO Basicamente, todas as funções de um RACE, a saber: encaminhamento transparente; interceptação e injeção de pacotes (para permitir a comunicação através dos circuitos dinâmicos); coleta de estatísticas e envio para o CORE. Instituto de Informática e UFGNet PoP-GO 13

14 1 computador desktop: 3rd Gen Intel Core i Processor (8MB, 3.4GHz); 8GB (2x 4GB), 1600MHz DDR3; 2x HDs 500GB, 6 Gb/s, SATA 3, 16MB de cache; 3 interfaces de rede Gigabit Ethernet do tipo PCIe x1 e com suporte aos padrões IEEE 802.3z, IEEE 802.3x Flow Control, IEEE 802.1p e IEEE 802.1Q VLANs. 1 computador desktop: 3rd Gen Intel Core i Processor (8MB, 3.4GHz); 8GB (2x 4GB), 1600MHz DDR3; 2x HDs 500GB, 6 Gb/s, SATA 3, 16MB de cache; 3 interfaces de rede Gigabit Ethernet do tipo PCIe x1 e com suporte aos padrões IEEE 802.3z, IEEE 802.3x Flow Control, IEEE 802.1p e IEEE 802.1Q VLANs. 1 computador desktop: 3rd Gen Intel Core i Processor (Quad Core, 6MB, 3.20GHz); 4GB (2x 2GB), 1600MHz DDR3; HD 500GB, 6 Gb/s, SATA 3, 16MB de cache; 2 interfaces de rede Gigabit Ethernet do tipo PCIe x1 e com suporte aos padrões IEEE 802.3z, IEEE 802.3x Flow Control, IEEE 802.1p e IEEE 802.1Q VLANs Basicamente, todas as funções de um RACE, a saber: encaminhamento transparente; interceptação e injeção de pacotes (para permitir a comunicação através dos circuitos dinâmicos); coleta de estatísticas e envio para o CORE Representação de uma instituição cliente ligada ao serviço CIPÓ. Esse equipamento será utilizado para gerar carga e auxiliar na mensuração do desempenho do serviço. Representação de uma instituição cliente ligada ao serviço CIPÓ. Esse equipamento será utilizado para gerar carga e auxiliar na mensuração do desempenho do serviço. Outro PoP Outro PoP Instituto de Informática 14

15 Tabela 3: Requisitos de hardware - testes na RNP Conforme descrito na Tabela 3, dois equipamentos serão enviados para algum PoP da RNP que já faça parte efetivamente da rede CIPÓ, ou seja, que ofereça o serviço de circuitos dinâmicos através do OSCARS. A escolha do PoP será definida com o auxílio dos parceiros do projeto e da RNP, em especial a equipe que gerencia a rede CIPÓ. Todo o software do protótipo do serviço ATER será baseado em ferramentas de código aberto e no sistema operacional Linux. A Tabela 4 apresenta os principais requisitos de software do protótipo e suas funções básicas. Requisitos Sistema Operacional Linux - distribuição Debian Sistemas de virtualização XEN e VirtualBox Ebtables OML + Ruby Banco de dados Postgres Funções Plataforma básica de todos os componentes do serviço: CORE e RACEs. Criação de VMs do CORE e, no cenário virtualizado, também dos RACEs. Encaminhamento transparente de pacotes e filtragem. Coleta distribuída e centralização das estatísticas. Persistência de diversas informações do serviço: usuário, regras, logs do CORE, estatísticas, etc. Tabela 4: Requisitos de software O VirtualBox será usado apenas na avaliação de partes do protótipo, sobretudo em suas versões iniciais. Posteriormente, deve ser substituído pelo sistema XEN. 6. Plano de Teste Os testes em laboratório foram divididos em dois grupos: 1) avaliação de funcionalidades e desempenho básico e 2) desempenho avançado. Os testes para avaliação de funcionalidades e desempenho básico serão realizados no ambiente virtualizado, enquanto os testes para avaliação de desempenho avançado serão realizados no ambiente emulado. Os testes na RNP visam avaliar as funcionalidades e o desempenho em geral do serviço ATER em um cenário real. Essa seção foi dividida em duas subseções, uma para abordar os testes em laboratório e outra para os testes na RNP. 6.1 Plano de testes em laboratório A Figura 9 ilustra a topologia do ambiente virtualizado. A seguir são apresentados os testes realizados no ambiente virtualizado. 15

16 Figura 9: Topologia do ambiente virtualizado Testes de funcionalidades e desempenho básico Nome Componentes envolvidos Descrição Resultados esperados Criação de regra Módulo Web, Módulo de Encaminhamento e Filtragem, Canal Seguro Esse teste consiste em um usuário criar uma regra através da interface Web do serviço ATER. Após a criação, a regra é enviada para os RACEs, os quais deverão aguardar a chegada do primeiro pacote para solicitar a criação de um circuito dinâmico. O usuário deve poder listar a regra criada, visualizando seu estado. Nos RACEs, deve ser possível visualizar uma nova regra na tabela do ebtables. Tanto CORE quanto RACEs também registram em seus logs de operação a criação da regra. Nome Operação de regra efetiva no ambiente virtual Componentes envolvidos Módulo de Criação de Circuitos, Módulo de Encaminhamento e Filtragem, Canal Seguro Descrição Este teste consiste em enviar tráfego que combine com uma regra efetiva. Quando um RACE detecta o primeiro pacote que combina com uma regra efetiva, ele entra em contato com o CORE para solicitar a criação de um circuito dinâmico. Resultados esperados Após a criação do circuito, será possível observar um caminho fim-a-fim com menos roteadores. O atraso fim-afim também deve ser reduzido. A criação do circuito dinâmico é registrada em log pelo CORE. Vale lembrar que o OSCARS utilizado nesse teste emprega uma topologia simulada sem falhas. Nome Componentes envolvidos Descrição Resultados esperados Operação de regra de monitoramento no ambiente virtual Módulo de Encaminhamento e Filtragem, Coleta de Estatística, Canal Seguro Este teste consiste em enviar tráfego que combine com uma regra de monitoramento. Os pacotes que combinam devem ser contabilizados e as estatísticas referentes devem ser enviadas para o CORE. As estatísticas referentes ao fluxo transmitido devem estar disponíveis no banco de dados do CORE. A Figura 10 ilustra a topologia do ambiente emulado. 16

17 Testes de desempenho avançado Figura 10: Topologia do ambiente emulado Nome Componentes envolvidos Descrição Resultados esperados Vazão através de circuito dinâmico emulado Módulo Web, Módulo de Criação de Circuitos, Módulo de Encaminhamento e Filtragem, Coleta de Estatística, Canal Seguro Este teste consiste em transmitir um arquivo grande utilizando o TCP. Inicialmente, a transferência será realizada através do caminho que representa a rede convencional, ou seja, tem maior atraso e mais perdas. Posteriormente, é incluída uma regra e a transferência é repetida através do circuito dinâmico emulado. O caminho com menor atraso e menos perdas deve permitir que a transferência ocorra em menor tempo. 6.2 Plano de testes na RNP A Figura 11 ilustra a topologia da RNP. Inicialmente, apenas o PoP-GO está definido, o restante será escolhido posteriormente. Para explorar melhor o potencial do protótipo do serviço ATER, é interessante que o caminho pelo qual os circuitos dinâmicos passarão envolva cinco PoPs ou mais. Assim, é possível observar os "atalhos" criados pelos circuitos e, provavelmente, o impacto no desempenho. Figura 11: Topologia real 17

18 Nome Operação de regra efetiva no ambiente real Componentes envolvidos Módulo de Criação de Circuitos, Módulo de Encaminhamento e Filtragem, Canal Seguro Descrição Este teste é equivalente ao realizado em ambiente virtual, porém ele utiliza o OSCARS que opera na rede CIPÓ. Resultados esperados Após a criação do circuito, será possível observar um caminho fim-a-fim com menos roteadores. O atraso fim-afim também deve ser reduzido. A criação do circuito dinâmico é registrada em log pelo CORE. Vale lembrar que o OSCARS utilizado nesse teste emprega uma topologia simulada sem falhas. Nome Componentes envolvidos Descrição Resultados esperados Vazão através de circuito dinâmico real Módulo Web, Módulo de Criação de Circuitos, Módulo de Encaminhamento e Filtragem, Coleta de Estatística, Canal Seguro Este teste é equivalente ao realizado em ambiente virtual/emulado, porém utiliza a rede CIPÓ. O caminho com menor atraso e menos perdas deve permitir que a transferência ocorra em menor tempo. 7. Cronograma de implantação e testes O cronograma de implantação e testes segue o planejamento definido no relatório RP1. A única alteração diz respeito Atividade 10: Estudo de caso, a qual propomos que seja realizada apenas com equipamentos do GT. Essa abordagem minimiza riscos na avaliação do protótipo e evita potenciais interrupções no ambiente de produção dos usuários. A proposta dessa abordagem também se baseia nas dificuldades em garantir a conectividade necessária para a realização dos testes, uma vez que a própria rede CIPÓ ainda se encontra em fase experimental e não está implantada em todo o backbone da RNP. Conforme o relatório RP1, as atividades relacionadas à implantação e testes do protótipo são: Atividade 3: Implementação e testes do software do RACE o Data de início: 01/02/2013 o Data de término: 31/07/2013 o Descrição: Nesta atividade serão implementados os componentes de software do RACE. Também será implantada a infraestrutura de testes em laboratório conforme definido na atividade de projeto do software. Concomitantemente à implementação, serão realizados testes de validação e desempenho do software do RACE. Atividade 7: Implementação e testes do software do CORE o Data de início: 01/02/2013 o Data de término: 31/07/2013 o Descrição: Nesta atividade serão implementados os componentes de software 18

19 do CORE. Também será implantada a infraestrutura de testes em laboratório conforme definido na atividade de projeto do software. Concomitantemente à implementação, serão realizados testes de validação do software do Servidor. Atividade 9: Teste de integração o Data de início: 01/03/2013 o Data de término: 30/09/2013 o Descrição: Esta atividade consiste na realização de testes de integração das duas partes principais do GT-ATER: RACE e CORE. Esta atividade tem início após as primeiras versões operacionais do RACE e do CORE estarem disponíveis e vão até o fim do projeto. Atividade 10: Estudo de caso o Data de início: 15/08/2013 o Data de término: 15/10/2013 o Descrição: Nesta atividade, o serviço do GT-ATER será testado sobre a rede do Serviço Experimental CIPÓ da RNP. Além do PoP-GO, os equipamentos do GT serão implantados em um outro PoP para a realização dos testes. Um desses equipamentos será utilizado como RACE e o outro representará uma instituição cliente. 19