Comitê Técnico de Monitoramento de redesMonitoramento de Redes As redes não são imunes a falhas...

MONITORAMENTO DE REDES:

O SERVIÇO MONIPÊ E SUA

EXTENSÃO EM REDES

METROPOLITANAS

José Augusto Suruagy Monteiro

Agenda

Monitoramento de Redes

Estratégias e Ferramentas

O perfSONAR

O Serviço MonIPÊ

Extensão em Redes Metropolitanas

19/09/2011 Monitoramento de Redes (WTR 2011 - Salvador)

2

Monitoramento de Redes

As redes não são imunes a falhas

O TCP ajusta-se a falhas na rede, procura ser justo

com todos os usuários

Aumento da expectativa dos usuários:

Redes de alta velocidade (ReMeSSA, Rede Ipê, conexões

internacionais)

Aplicações científicas e culturais:

LHC, CineGrid

Como identificar a causa e localização de eventuais

problemas de desempenho?


3

Estratégia (1/2)

Encontrar uma solução para os problemas de rede pode ser

dividida em dois passos distintos:

Uso de Ferramentas de Diagnóstico para localizar os problemas

Ferramentas que medem o desempenho ativamente (ex. latência, largura de

banda disponível)

Ferramentas que observam o desempenho de forma passiva (ex., contadores

de erros)

Monitoramento Regular para identificar o funcionamento normal

(baseline) e gerar alertas quando cair as expectativas.

Uso de ferramentas de diagnóstico de uma forma estruturada

Visualizações e alarmes para analisar os dados coletados


4

Estratégia (2/2)

Incorporação de uma destas técnicas deve ser:

Ubíqua, ex. a solução funciona melhor se estiver

disponível em todas as redes envolvidas

Uniforme (ex. federada) ao apresentar as informações

de recursos e domínios diferentes


5

Métricas de Interesse

Atraso de ida e volta (RTT – Round Trip Time)

Perdas de ida e volta

Utilização

Atraso em um sentido (One way delay)

Variação do atraso em um sentido (jitter)

Perdas em um sentido

Reordenação de Pacotes

Largura de banda alcançável (TCP, UDP)

MOS (Mean Opinion Score)

Fluxos (volume de pacotes, bytes, tipo de protocolo)


6

Ferramentas

Ping:

Atraso de ida e volta

(RTT – Round Trip Time)

Perdas de ida e volta

SNMP:

Utilização

Iperf/BWCTL:

Largura de banda

alcançável (TCP, UDP)

OWAMP:

Atraso em um sentido

(One way delay)

Variação do atraso em

um sentido (jitter)


Reordenação de Pacotes

Netflow/Sflow

Fluxos (volume de

pacotes, bytes, tipo de

protocolo)

19/09/2011

7

Monitoramento de Redes (WTR 2011 - Salvador)

Comunicação através de Múltiplos

Domínios

NREN NREN

RNP NREN

NREN

Géant

Internet2

ESNet

Clara

...

...

.

.

.

O Problema

Desenvolvedor

da Aplicação

Administrador

do Sistema

Administrador

da LAN

Rede do

Campus

PoP PoP

Backbone

Rede do

Campus

Administrador

da LAN

Administrador

do Sistema

Desenvolvedor

da Aplicação

Como você resolve um

problema no meio do caminho?

Todo mundo diz que está tudo

funcionando bem!

Ei, isto não está

funcionando

direito!

O computador

está

funcionando

bem!

Fale com os outros

Está tudo

OK

Ninguém mais

está reclamando

A rede está com baixa utilização

Todas as luzes

estão verdes

Não estamos vendo

nada errado!

Parece ok!

Outros estão

chegando bem

O problema não é nosso

Possível Solução


10

Análise e

Visualização

Infra-estrutura

de Medições

Coleta de

Dados Ferramentas

de Medição

Análise e

Visualização

Infra-estrutura de

Medições

API

API

Monitoração Multidomínio

Muitas organizações realizam monitoração e diagnóstico de

suas próprias redes

Monitoração SNMP através de ferramentas comuns (ex., MRTG, Cacti)

Monitoração corporativa (ex. Nagios)

Redes são cada vez mais um esforço que envolve diversos

domínios

Colaborações internacionais são comuns em diversas áreas (ex., ciência,

artes e humanidades)

Pico de interesse no desenvolvimento e uso de redes de pesquisa e de

ensino

Monitoração e diagnósticos deve se tornar também um esforço

que envolve diversos domínios


11

perfSONAR

19/09/2011

12


perfSONAR

01/06/2011 1a. Reunião Presencial do CT-Mon - Campo Grande

13

PERFormance Service Oriented Network monitoring

ARchitecture

O perfSONAR é um ambiente de monitoração de

desempenho multidomínio, que define um conjunto

de padrões de protocolos para o compartilhamento

de dados entre sistemas de medições e

monitoração.

O que é perfSONAR?

Uma colaboração

Operadores de redes de produção focados em projetar e construir ferramentas

que eles instalarão e usarão em suas redes para prover capacidades de

monitoração e diagnóstico para eles mesmo e para as suas comunidades de

usuários.

Uma arquitetura e conjunto de protocolos de comunicação

Arquitetura de Serviços Web

Protocolos definidos no Open Grid Forum

Grupo de Trabalho em Medições de Redes (NM-WG)

Grupo de Trabalho de Controle de Medições de Redes (NMC-WG)

Diversas implementações de software interoperáveis

perfSONAR-MDM e perfSONAR-PS

Uma infraestrutura de Monitoração instalada.


14

Primórdios do perfSONAR

perfSONAR se originou de discussões entre a Iniciativa de Desempenho

Fim-a-Fim (E2Epi) da Internet2, e o projeto Géant2 em Setembro de 2004.

Membros do NM-WG do OGF (na época GGF) serviram de guia na

codificação dos dados de medições de rede.

Parceiros de redes adicionais, incluindo a Esnet e a RNP forneceram

recursos de desenvolvimento assim como serviram como implantadores

iniciais (early adopters).

A primeira versão de software com a marca perfSONAR foi

disponibilizada em Julho de 2006.

Todo o código perfSONAR é aberto

Todos os produtos que desejam ser rotulados como compatíveis como

perfSONAR devem estabelecer a sua compatibilidade com os padrões

públicos do OGF


15

pS: Visão Geral da Arquitetura

Middleware de medições de rede interoperável

projetado como uma Arquitetura Orientada a

Serviços (SOA):

Cada componente é modular

Todos são baseados em Serviços Web

O arcabouço global do perfSONAR assim como suas

instalações individuais são descentralizadas

Todas as ferramentas do perfSONAR são controladas

localmente


16


O perfSONAR integra:

Ferramentas de monitoração de rede e arquivos com os

resultados das medições

Manipulação dos dados

Serviços de Informação

Descoberta

Topologia

Autenticação e autorização


17


O conceito chave do perfSONAR é que cada entidade realiza

um serviço

Cada serviço provê um conjunto limitado de serviços, ex, coleta de

medições entre dois pontos arbitrários ou gerenciando o registro e

localização de serviços distribuídos

O serviço é uma entidade autocontida e provê funcionalidades por si só

assim como quando instalada com o restante do arcabouço

Os serviços interagem através de diálogos do protocolo

Formatos padrão das mensagens

Padrões de diálogo padronizados


18


Uma coleção de serviços perfSONAR dentro de um

domínio é uma instalação

A instalação do perfSONAR pode ser realizada “a la

carte”, ou através de uma solução completa

Os serviços se federam com os demais, localmente e

globalmente

Os serviços são projetados para descobrir automaticamente

a presença de outros componentes perfSONAR

Os clientes são projetados levando em conta este

paradigma distribuído


19

Arquitetura do perfSONAR


20

Pontos de

Medição

Serviços de Dados

Arquivos de

Medição

Transformações

Configuração

Serviços

Auth(n/z)

Infraestrutura

Serviços de Informação

Topologia

Descoberta

Análise/Visualização

Interfaces

Gráficas do

Usuário

Páginas

Web

Alarmes

NOC

01/06/2011 1a. Reunião Presencial do CT-Mon - Campo Grande 21

Onde posso obter mais informações

sobre o domínio B/IP d,e,f e o

domínio A/IP a,b,c?

Cliente

Rede A Rede B

hLS A hLS B MA A MA B

a b

c d

e f

a,b,c : Rede A, MA A Obtenha utilização dos enlaces d,e,f Tome Obtenha utilização dos enlaces a,b,c

Tome

Gráfico útil gLS

LS A, LS B

d,e,f : Rede B, MA B

Onde está a utilização dos

enlaces para- IPs d,e,f?


Uma implantação do perfSONAR pode incluir qualquer

combinação de serviços

É necessária uma instância do Serviço de Descoberta (LS) para

compartilhar informações

É possível qualquer combinação de serviços de dados e ferramentas de

análise e visualização

Os serviços do perfSONAR automaticamente se federam de

forma global

O serviço de descoberta (LS) se comunica com um grupo confederado

de serviços de diretório (ex. o Serviço de Descoberta Global – gLS)

A descoberta global é possível através de APIs


22


O perfSONAR é mais efetivo quando todos os

trechos de um caminho são monitorados

A depuração do desempenho de rede deve ser

realizado fim-a-fim

A falta de informação para domínios específicos

podem atrasar ou impedir o processo de depuração


23

pS: Exemplo de Caso de Uso

O perfSONAR deve ser usado

para diagnosticar um problema

de desempenho fim-a-fim

O usuário está tentando “baixar”

um recurso remoto

O recurso e o usuário estão

separados por uma certa distância

Assumimos que ambos estão

conectados a redes de alta

velocidade

A operação não corre como

planejado, por onde começar?


24


Ferramentas simples como

traceroute podem ser usadas

para identificar o caminho

percorrido

Pode haver um problema de

desempenho em qualquer trecho

O problema pode ser algo que

consigamos consertar, mas é mais

provável que não seja


25


Cada segmento do caminho é

controlado por um domínio

diferente

Cada domínio possui pessoal de

rede que poderão ajudar a

corrigir o problema, mas como

contatá-los?

Tudo o que realmente queremos

é alguma informação sobre o

desempenho


26


Cada domínio disponibilizou

dados de medições através do

perfSONAR

O usuário foi capaz de

descobrir isto automaticamente

Ferramentas automatizadas

como visualizadores e

analisadores podem ser

alimentados por estes dados da

rede


27


No final o problema é isolado

baseado em testes.

O usuário pode contatar o

domínio em questão para

perguntar sobre este problema

de desempenho

Quando tiver sido consertado a

transferência pode transcorrer

como desejado


28

pS: Quem está envolvido?

O Consórcio perfSONAR é uma colaboração entre

ESnet (Energy Sciences Network)

Géant (Rede pan-Europeia)

Internet2 (Consórcio americano de redes avançadas)

RNP

Há dois esforços independentes de desenvolvimento de

software compatível com o perfSONAR

perfSONAR-MDM

perfSONAR-PS

Cada projeto trabalha com um plano de desenvolvimento

individual e trabalha com o consórcio para avançar o

desenvolvimento do protocolo e garantir compatibilidade 19/09/2011 Monitoramento de Redes (WTR 2011 - Salvador)

29

perfSONAR-MDM


30

Desenvolvido no escopo do projeto GÉANT

Escrito basicamente em Java foi projetado para

servir como a solução de monitoração para o

projeto LHC (Large Hadron Collider).

Disponível em pacotes Debian ou RPM

https://forge.geant.net/forge/display/perfsonar/Home

https://forge.geant.net/forge/display/perfsonar/Home

Componentes do

perfSONAR-MDM 3.3


31

RRD Measurement Archive

SQL Measurement Archive

SSH/Telnet Measurement Point

Lookup Service

Authentication Service and Authorization Service

OPPD (previously called BWCTL) Measurement

Point)

E2EMon Measurement Point

HADES


32

Versões Mais Antigas do MDM


33

1.0 – Julho 2006

2.0 – Maio 2007

2.1 – Agosto 2007

2.2 – Dezembro 2007

3.0 – Maio 2008

3.1 – Janeiro 2009

3.2 – Julho 2009 (para LHCOPN)

perfSONAR-PS


34

http://psps.perfsonar.net/

Desenvolvido em colaboração entre:

ESnet, Fermilab, Georgia Tech, Indiana University, Internet2, SLAC, The University of Delaware

Escritos em Perl disponível para instalação independente ou através do Performance Toolkit (pS-PT).

http://psps.perfsonar.net/

pS-PT


35

perfSONAR Performance Toolkit (pS-PT)

Versão atual: 3.2

LiveCD ou Net-Install baseado no CentOS 5.5

Fácil de instalar

Boot com o CD de Instalação – funciona como a instalação de

qualquer distribuição Linux

http://psps.perfsonar.net/toolkit/

Interface Web Amigável

https://pspt.nuperc.unifacs.br




36

Serviços incluídos no perfSONAR-PS


37

SNMP Measurement Archive

perfSONAR-BUOY

perfAdmin GUI

Lookup Service

Topology Service

Status Measurement Archive

PingER Services

PingER GUI

LS Registration Daemon

pS-PT


38

Obtenção de diversos tipos de métricas/dados

Vazão

Atraso

Ping

Utilização SNMP

Gráficos do Cacti com informações de performance do

host

Agendamento de testes

Vazão, Atraso unidirecional e ping

pS: Quem está adotando?

O perfSONAR está ganhando visibilidade como uma solução de

monitoração interoperável e extensível

A sua adoção tem progredido nas seguintes áreas:

Redes de ensino e pesquisa incluindo redes dorsais, regionais, e pontos de troca

Universidades a nível internacional

Laboratórios e agências federais nos Estados Unidos

Organizações Científicas Virtuais, em particular o projeto LHC

Interesse recente também por parte de:

Parceiros redes internacionais de ensino e pesquisa pontos de troca de tráfego

Provedores comerciais nos Estados Unidos

Fabricantes de hardware


39

www.monipe.rnp.br e

wiki.monipe.rnp.br

O Serviço MonIPÊ

19/09/2011

40


http://www.monipe.rnp.br/

wiki.monipe.rnp.br

wiki.monipe.rnp.br

http://www.ufsc.br/

O Serviço MonIPÊ

Baseado na infraestrutura perfSONAR

Serviços Centrais:

1 MA (PHP-SQL-MA)

1 LS (Serviço de descoberta)

1 AS (Serviço de autenticação)

Serviços Locais:

27 MPs instalados (CLMP em cada PoP da rede Ipê da RNP)

Clientes de visualização:

1 CACTISonar (Agendamento / gerenciamento / geração de gráficos e

testes)

ICE e perfSONARUI (para usuários finais e solicitação de testes sob

demanda)

Ferramenta de Geração Relatórios


41

Infraestrutura do MonIPÊ


42

Classificação dos Testes

Testes Regulares

Realizados periodicamente

Configuração fixa

Utiliza a malha de medição e parâmetros “fixos”

Utilizado para simulação do comportamento de aplicações

Análise de tendências da rede

Testes sob Demanda

Usuários autorizados

Utilizado para certificação de enlaces entre PoPs e instituições

Obtenção de resultados em tempo real

Usuários em geral

Utilizado para medição da última milha


43

Testes regulares

Ambiente de medições

CACTISonar, perfSONAR CL-MP e perfSONAR MA

Ferramentas e Métricas

OWAMP

Medição do atraso em um sentido


Cálculo da variação do atraso

Cálculo do MOS

Outras métricas derivadas

BWCTL

Largura de banda alcançável em TCP

Largura de banda alcançável em UDP

Outras métricas derivadas


44

Testes Regulares com OWAMP

• Parâmetros de medição – OWAMP (Full Mesh)‏

– O propósito da malha de medição (full mesh) é ter uma visão geral do estado da

rede identificando individualmente o estado da comunicação entre todos os PoPs

– Periodicidade

• De 5 em 5 minutos

– Pacotes de teste: 10 pacotes por fluxo de teste

– Tamanho do pacote: 42 Bytes

• 20 Bytes: IP

• 8 Bytes: UDP

• 14 Bytes: Payload

– Intervalo entre pacotes de teste: 10 pacotes por segundo

– Largura de banda para medição: ~3,36Kbps por fluxo

– Impacto na rede: Desprezível


45


Simulação de fluxo de voz – g.711 • O objetivo desta medição periódica é obter indicadores de desempenho da rede na

presença de tráfego de voz utilizando o codec g.711

• Protocolo: UDP

• Periodicidade:

– De 60 em 60 minutos

• Duração do teste: 3 minutos

• PPS: 50

• Tamanho do pacote: 200 Bytes

– 20 Bytes – cabeçalho IP

– 8 Bytes – UDP

– 12 Bytes – RTP

– 160 Bytes - Payload

– Consumo de banda: 80Kbps por fluxo

– Impacto na rede: Baixo


46


Simulação de fluxo de voz – g.729 • O objetivo desta medição periódica é obter indicadores de desempenho da rede na

presença de tráfego de voz utilizando o codec g.729.

• Protocolo: UDP

• Periodicidade:

– De 30 em 30 minutos

• Duração do teste: 3 minutos

• PPS: 50

• Tamanho do pacote: 60 Bytes

– 20 Bytes – cabeçalho IP

– 8 Bytes – UDP

– 12 Bytes – RTP

– 28 Bytes - Payload

• Consumo de banda: 24 Kbps

• Impacto na rede: Baixo


47

Testes Regulares com BWCTL

Parâmetros de medição BWCTL – Medição TCP • Esta medição tem como objetivo identificar a largura de banda alcançável entre dois

pontos finais.

• Periodicidade

• De 60 em 60 minutos

• Duração do teste

– 10 segundos

• Tamanho da janela TCP

– Otimizada pelo BDP

• Consumo de banda: Deve utilizar toda a banda disponível até o limite da

capacidade da interface

• Impacto na rede:

– Baixo

– Semelhante a um FTP


48

Visualização dos Resultados


49



50


Transição do Backbone 2,5 para 10Gbps


51


Transição do Backbone 2,5 para 10Gbps


52


Medição de vazão entre DF e RJ


53

Testes sob Demanda

As medições sob demanda são utilizadas para

avaliar instantaneamente o estado da rede.

O objetivo deste tipo de medição é permitir aos

usuários autorizados realizarem medições não

contempladas pelas medições regulares.

Este tipo de medição tem como objetivo descobrir a

capacidade de um enlace ou uma conexão fim-a-fim

em escoar um determinado tipo de tráfego.

Avaliar com mais profundidade um problema de

desempenho na rede.


54

Testes sob Demanda

Certificação de enlaces em tempo real (UDP)

Ambiente

ICE, perfSONAR/CL-MP

Ferramenta:

BWCTL - UDP

Finalidade

Certificação de desempenho/capacidade de enlaces

Tipo de usuário

Usuários autorizados

Parâmetros de medição

Largura de banda: Configurável

Tamanho do pacote: 1500 Bytes

Largura de banda para medição: Configurável

Impacto na rede: Pode ser Alto


55

Desempenho da Primeira Milha

Ambiente de medição

Network Diagnostic Tool (NDT) - Servidores

Cliente WEB na estação do usuário final

Métricas

Largura de banda alcançável em TCP

Parâmetros de medição

Duração

10 segundos – cliente para servidor

10 segundos – servidor para cliente

Consumo de banda

Deve utilizar toda a banda disponível até o limite da capacidade da interface de menor capacidade

Impacto na rede:

Baixo

Semelhante a um FTP


56



57

http://www.monipe.rnp.br/mapa_ndt_rnp.html



58

Dados de Fluxos: NFSEN

NFSEN (flows.monipe.rnp.br/monipe/nfsen)

Interface de visualização de dados coletados com

Netflow/Sflow

Implantado no MonIPÊ

Recebendo dados replicados de servidor da RNP

Dados de 22 PoPs

AL, BA, CE, DF, ES, GO, MA, MG, MS, MT, PA, PB, PE, PI, PR, RJ,

RN, RO, RS, SC, SE, SP

Gera gráficos e relatórios customizados

Dados anonimizados

Alta capacidade de personalização


59



60



61

Exemplo de relatório (Top 10 AS de Destino) gerado com a ferramenta NFSEN

Extensão em Redes Metro

19/09/2011

62


Extensão do serviço

Redes Estaduais, Metropolitanas, Instituições

Usuárias

É preciso ubiquidade, não basta instalar pontos de

medição no backbone da Rede Ipê

Sugestão: uso do pS-PT


63

Obrigado!

19/09/2011

64


Comitê Técnico de Monitoramento de redesMonitoramento de Redes As redes não são imunes a falhas...

Documents

Transcript of Comitê Técnico de Monitoramento de redesMonitoramento de Redes As redes não são imunes a falhas...