GT Medições (GT-Med) Proposta

Transcrição

1 GT Medições (GT-Med) Proposta José Augusto Suruagy Monteiro (a ser criada) IMPA, 11 de Agosto de RNP

2 GT-Med Roteiro Contexto Atividades de Medição do GT-QoS Atividades de Medição do GT-QoS2 O Ambiente E2E pipes Módulos de Software Atividades Propostas Observatório da RNP Ambiente de Monitoração de SLA para Redes

4 GT-Medições Contexto As atividades deste GT dão continuidade aos experimentos de medição realizados dentro do contexto dos GTs QoS (2002/3), GT-QoS2 (2003/4) e dos projetos IQoM e GigaIQoM. Contamos com a sinergia de diversas instituições, participantes destes projetos, dentre as quais podemos citar a UFRGS, FURG, UFSC, UFPR (apenas projeto IQoM) Fundação CPqD, Intel Research Cambridge e, UFF.

5 GT-Medições Contexto GT-QoS ( ): Infra-estrutura de medições de fluxo baseada no Netflow GT-QoS2 ( ): Análise dos Dados Coletados pelo Netflow Medições Passivas com Placa de Captura Medições Ativas com a Plataforma AMP Medições Ativas com a Plataforma OWAMP GT-Med ( ): Implantação do Ambiente pipes Observatório da RNP implantação de um ambiente de monitoramento das SLAs (se tivermos fôlego!)

6 GT-QoS: Infra-estrutura de Medições Cisco Netflow na RNP2 Arquitetura É interessante os coletores estarem na mesma rede dos ciscos Fluxos Coletores Servidor principal Fluxos Coletores Ciscos em cada Maquinas coletoras Servidor concentra POP com locais recebem os todos os fluxos. Netflow ativo. fluxos em pacotes UDP Atualmente no Nuperc Apresentação dos GTs através IMPA, do 11 pacote de flowtools. Agosto de 2004 (Salvador). Dados que podem ser apresentados de forma gráfica ou disponibilizados por ftp para os grupos de interesse.

7 GT-QoS2: Pilotos de Medição Medições Passivas com Placa de Captura Cenário dos Experimentos:

8 GT-QoS2: Pilotos de Medição Medições Ativas com a Plataforma AMP O AMP (Active Measurement Project) é um projeto de medição ativa desenvolvido pelo NLANR (National Laboratory for Applied Network Research) Realiza medições de atraso de ida e volta, perda de pacotes, topologia e vazão (sob demanda).

9 GT-QoS2: Pilotos de Medição OWAMP porta TCP 4822 portas UDPs aleatórias > 1024 Testes em qualquer um dos sentidos Pode-se alterar o tamanho dos pacotes Patch para marcar os pacotes com diferentes classes

10 Tendência Disponibilização dos dados de medições para diversas plataformas através do uso de Web services. Finalidades: Obtenção de informações da rede, num formato padrão para usuários finais e aplicações. Interoperação com outras infra-estruturas de medições, tais como as das redes Abilene, Géant e da futura rede CLARA.

12 GT-Medições O Ambiente E2E pipes (End-to-End Performance Initiative Performance Environment System)

13 Internet2 E2E pipes Goals Enable end-users & network operators to: determine E2E performance capabilities locate E2E problems contact the right person to get an E2E problem resolved. Enable remote initiation of partial path performance tests Make partial path performance data publicly available Interoperable with other performance measurement frameworks 8/10/2004 3

14 Sample pipes Deployment Regularly Scheduled Tests On-Demand Tests Result Collection Network Backbone Test Data Backbone Node Regional Node Regional Node Network Backbone Backbone Node Backbone Node Regional Node Regional Test Data Application Domain Test Data 8/10/2004 5

15 pipes Deployment In Progress Abilene US Govt. Labs US Universities GEANT APAN Israel Italy Poland 8/10/2004 7

16 E2E pipes Módulos de Software

17 E2E pipes Módulos de Software (Armazenamento) Armazenamento dos dados resultantes das medições realizadas pelas diversas ferramentas através da utilização de um sistema de gerenciamento de banco de dados (SGBD).

18 E2E pipes Módulos de Software (Testes) Funcionalidades encontradas nas ferramentas de medição, instalados nos pontos de medição de desempenho (PMD), realizando os testes e coletando as medidas de interesse.

19 E2E pipes Módulos de Software (Agendamento) Visa permitir que os testes de medição da rede possam ser realizados a partir de uma programação previamente estabelecida pelos administradores da rede e/ou pelos usuários.

20 E2E pipes Módulos de Software (Autorização) Mecanismos de autenticação e autorização de acesso Serão realizadas de forma distribuída para cada domínio de medição através de modelos de confiança como o Shibboleth.

21 E2E pipes Módulos de Software (Interface) Disponibilização dos dados armazenados. Faz uso de Serviços Web. Esquema padrão baseado no trabalho do NMWG (GGF). Pretende ainda criar mecanismos de publicação e descoberta automática dos recursos disponibilizados pelas ferramentas

22 E2E pipes Módulos de Software (Detecção) Ferramentas que visam detectar problemas de desempenho a partir do acesso aos dados das medições Apresentação dos resultados num formato amigável sobretudo ao usuário leigo.

23 E2E pipes Atividades Propostas (Armazenamento) Estudo inicial dos dados coletados; Elaboração de modelo de dados compatível com as necessidades das aplicações de análise; Definição de um banco de dados, implementando as principais tabelas, relacionamentos, restrições de integridades e procedimentos armazenados; Adaptação das ferramentas conforme o SGBD utilizado (mysql ou ROOT) para possibilitar a interação entre os mesmos; Criação de programas/scripts de manipulação dos dados armazenados.

24 E2E pipes Atividades Propostas (Testes) Ferramentas de Medição: GT-QoS 1 e 2: Netflow, NeTraMet, AMP, OWAMP, Thrulay. Extensão para testes do OWAMP, BWCTL (Iperf) e Thrulay com o IPv6. Inicialmente em laboratório e posteriormente no backbone.

25 E2E pipes Atividades Propostas (Agendamento) Esta atividade está prevista no escopo do projeto GigaIQoM, de modo que pretendemos aqui apenas colaborar com este esforço complementar de modo a no futuro termos também esta funcionalidade implementada no nosso ambiente.

26 E2E pipes Atividades Propostas (Autorização) O Shibboleth consiste em um modelo de confiança no qual cada instituição (no nosso caso, domínio de medição) é responsável por autenticar os seus usuários. Para a realização desta atividade espera-se contar com os resultados obtidos pelo atual GT- Diretórios.

27 E2E pipes Atividades Propostas (Interface) Criação de Serviços Web para: Configuração do NeTraMet através de interfaces mais amigáveis. Interação com o pacote flowtools (dados do Netflow)

28 E2E pipes Configuração do NeTraMet através de Serviços Web

29 Dissertação de Mestrado de Leobino O protótipo e a sua relação com o pipes SFM3 Interface Roteador Ponto de Medição Componente de OWAMP Desempenho Coletor OWAMP IPERF IPERF Ponto de Traceroute Traceroute Medição de Desempenho Componente OWAMP, IPERF, Traceroue Coletor Fluxos, SNMP Interface Roteador Ponto de Medição de Desempenho Componente Coletor Interface Roteador Fluxos, SNMP Fluxos, SNMP BD Dados de Fluxos BD IPERF PERF BD OWAMP PERF BD Traceroute PERF BD SNMP PERF Componente de BD Serviços Web SaManTa Pacote de visualização

30 Dissertação de Mestrado de Leobino Implementação do Coletor Resumo das tecnologias utilizadas Apache Axis, tomcat, pacote flow-tools, scripts perl.

31 Dissertação de Mestrado de Leobino Implementação componente de BD Resumo das tecnologias utilizadas Apache Axis, tomcat, mysql, DAO.

32 E2E pipes Atividades Propostas (Detecção) Avaliações de Ferramentas tais como: I2Detective (IPerf e Multicast Beacon) Advisor (NLANR)

34 Observatório da RNP Dados que potencialmente serão disponibilizados Tráfego total agregado de dados; Dados da evolução do tráfego total agregado de dados; Mapa de tempo (atualizado periodicamente de acordo com a utilização dos diversos enlaces do backbone); Atraso unidirecional (baseado nas medidas do OWAMP e nos dados já disponíveis atualmente em Vazão (baseado nos dados obtidos com o BWCTL e o Thrulay); Análise dos dados de fluxo obtidos com o Netflow ou Netramet; Estatísticas de Multicast (obtidas com a ferramenta Multicast Beacon do NLANR).

35 Observatório da RNP Mapas em Árvore Site gera arquivo Visualização pelo TreeMaps

36 Observatório da RNP

38 Ambiente de Monitoração de SLA para Redes Desenvolvimento e Implantação A ferramenta nsla, foi desenvolvida inicialmente para atender às necessidade do PoP-SC e NDP/UFSC Visa administrar e monitorar a infra-estrutura de rede LAN, WAN e serviços de rede. Módulos: o agente autômato e a interface web de configuração e exibição de relatórios Agente Autômato coleta parâmetros de: Disponibilidade: através de ICMP ou usando a MIB RTT da CISCO para dispositivos, e através de captura do atributo ifoperstatus da interface. São também coletados dados de tempo de resposta e de alcançabilidade para os dispositivos; Taxa de erros: através da captura do atributo de erros em uma interface utilizando SNMP.

39 Ambiente de Monitoração de SLA para Redes Interface Web

40 Ambiente de Monitoração de SLA para Redes Etapas Previstas Etapa 1 Adequação da ferramenta existente para utilização em um piloto no Backbone da RNP [meses 1 a 3]; Etapa 2 Implantação da ferramenta para monitorar o SLA da RNP [meses 3 a 5]; Etapa 3 Seleção de métricas e desenvolvimento de funções para permitir a celebração de SLA baseados em diferenciação de serviços bem como sua monitoração [meses 3 a 6]. Etapa 4 Seleção de novas métricas de interesse e desenvolvimento de função no sistema para implementação de acordos e relatórios baseadas nessas métricas [meses 7 a 9]. Etapa 5 - Desenvolvimento de Web Services para recuperar os relatórios de SLA [meses 10 a 12].

41 GT-Med Perguntas?