GT Medições (GT-Med) Proposta

(1)

GT Medições (GT-Med)

Proposta

José Augusto Suruagy Monteiro

www.nuperc.unifacs.br/gtmed

(a ser criada)

IMPA, 11 de Agosto de 2004

(2)

Apresentação dos GTs – IMPA, 11 de Agosto de 2004

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

(3)

Roteiro

• Contexto

(4)

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)

Contexto

• GT-QoS (2002-2003):

– Infra-estrutura de medições de fluxo baseada no Netflow

• GT-QoS2 (2003-2004):

– 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 (2004-2005):

– Implantação do Ambiente piPEs – “Observatório da RNP”

– implantação de um ambiente de monitoramento das SLAs (se tivermos fôlego!)

(6)

É interessante os coletores estarem na mesma rede dos ciscos

Arquitetura

Ciscos em cada POP com Netflow ativo. Coletores Coletores Fluxos Fluxos Maquinas coletoras locais recebem os

fluxos em pacotes UDP através do pacote flow-tools. Servidor principal Servidor concentra todos os fluxos. Atualmente no Nuperc (Salvador).

Dados que podem ser apresentados de forma gráfica ou disponibilizados por ftp para os grupos de interesse.

Cisco Netflow na RNP2

(7)

Medições Passivas com Placa de Captura

• Cenário dos Experimentos:

(8)

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).

GT-QoS2: Pilotos de Medição

(9)

OWAMP

GT-QoS2: Pilotos de Medição

porta TCP 4822

portas UDPs aleatórias > 1024 •Testes em qualquer um dos sentidos

•Pode-se alterar o tamanho dos pacotes

(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.

(11)

Roteiro

• Contexto

(12)

O Ambiente E2E piPEs (End-to-End Performance Initiative

Performance Environment System)

(13)

Apresentação dos GTs – IMPA, 11 de Agosto de 2004 8/10/2004 3

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

(14)

Sample piPEs Deployment

Regional Node Regional Node Network Backbone Test Data Regional Node Regional Test Data Application Domain Test Data Regularly Scheduled Tests On-Demand Tests Result Collection Backbone Node Backbone Node Backbone Node Network Backbone

(15)

piPEs Deployment

Italy Poland Israel In Progress Abilene US Govt. Labs US Universities GEANT APAN

(16)

Módulos de Software

(17)

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).

E2E piPEs

(18)

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.

E2E piPEs

(19)

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)

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.

E2E piPEs

(21)

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

E2E piPEs

(22)

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.

E2E piPEs

(23)

Atividades Propostas

(Armazenamento)

E2E piPEs

• 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

(24)

Atividades Propostas

(Testes)

E2E piPEs

• 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)

Atividades Propostas

(Agendamento)

E2E piPEs

• 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)

Atividades Propostas

(Autorização)

E2E piPEs

• 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)

Atividades Propostas

(Interface)

E2E piPEs

• Criação de Serviços Web para:

– Configuração do NeTraMet através de interfaces mais amigáveis.

– Interação com o pacote flow-tools (dados do Netflow)

(28)

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

(29)

SFM3

O protótipo e a sua relação com o piPEs

Ponto de Medição de Desempenho Ponto de Medição de Desempenho Ponto de Medição de Desempenho OWAMP IPERF Traceroute OWAMP IPERF Traceroute OWAMP, IPERF, Traceroue

Interface Roteador Interface Roteador Interface Roteador Fluxos, SNMP Fluxos, SNMP Fluxos, SNMP BD Dados de Fluxos BD IPERF PERF BD OWAMP PERF BD Traceroute PERF BD SNMP PERF Serviços Web Pacote de visualização Componente Coletor Componente Coletor Componente Coletor Componente de BD SaManTa

(30)

Implementação do Coletor

• Resumo das tecnologias utilizadas

– Apache Axis, tomcat, pacote flow-tools, scripts perl.

(31)

Apresentação dos GTs – IMPA, 11 de Agosto de 2004 Implementação componente de BD • Resumo das tecnologias utilizadas

– Apache Axis, tomcat, mySQL, DAO.

(32)

Atividades Propostas

(Detecção)

E2E piPEs

• Avaliações de Ferramentas tais como:

– I2Detective (IPerf e Multicast Beacon)

(33)

Roteiro

• Contexto

(34)

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 http://www.amp.ufsc.br/owamp/);

• 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)

Mapas em Árvore

Observatório da RNP

Site gera arquivo Visualização pelo TreeMaps

(36)

Observatório da RNP

(37)

Roteiro

• Contexto

(38)

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)

Interface Web

(40)

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)